LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com> To: sathyanarayanan.kuppuswamy@linux.intel.com Cc: a.zummo@towertech.it, x86@kernel.org, wim@iguana.be, mingo@redhat.com, alexandre.belloni@free-electrons.com, qipeng.zha@intel.com, hpa@zytor.com, dvhart@infradead.org, tglx@linutronix.de, lee.jones@linaro.org, andy@infradead.org, souvik.k.chakravarty@intel.com, linux-rtc@vger.kernel.org, linux-watchdog@vger.kernel.org, linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org, sathyaosid@gmail.com Subject: Re: [RFC v8 4/7] platform: x86: Add generic Intel IPC driver Date: Thu, 23 Nov 2017 15:29:16 +0200 [thread overview] Message-ID: <20171123132916.GE17418@kuha.fi.intel.com> (raw) In-Reply-To: <5c66498c110e52343d810db9c281fe72d0d299cc.1509268570.git.sathyanarayanan.kuppuswamy@linux.intel.com> Hi, On Sun, Oct 29, 2017 at 02:49:57AM -0700, sathyanarayanan.kuppuswamy@linux.intel.com wrote: > +/** > + * devm_intel_ipc_dev_create() - Create IPC device > + * @dev : IPC parent device. > + * @devname : Name of the IPC device. > + * @cfg : IPC device configuration. > + * @ops : IPC device ops. > + * > + * Resource managed API to create IPC device with > + * given configuration. > + * > + * Return : IPC device pointer or ERR_PTR(error code). > + */ > +struct intel_ipc_dev *devm_intel_ipc_dev_create(struct device *dev, > + const char *devname, > + struct intel_ipc_dev_cfg *cfg, > + struct intel_ipc_dev_ops *ops) > +{ > + struct intel_ipc_dev **ptr, *ipc_dev; > + int ret; > + > + if (!dev && !devname && !cfg) > + return ERR_PTR(-EINVAL); > + > + if (intel_ipc_dev_get(devname)) { > + dev_err(dev, "IPC device %s already exist\n", devname); > + return ERR_PTR(-EINVAL); > + } > + > + ptr = devres_alloc(devm_intel_ipc_dev_release, sizeof(*ptr), > + GFP_KERNEL); > + if (!ptr) > + return ERR_PTR(-ENOMEM); > + > + ipc_dev = kzalloc(sizeof(*ipc_dev), GFP_KERNEL); > + if (!ipc_dev) { > + ret = -ENOMEM; > + goto err_dev_create; > + } > + > + ipc_dev->dev.class = &intel_ipc_class; > + ipc_dev->dev.parent = dev; > + ipc_dev->dev.groups = ipc_dev_groups; > + ipc_dev->cfg = cfg; > + ipc_dev->ops = ops; > + > + mutex_init(&ipc_dev->lock); > + init_completion(&ipc_dev->cmd_complete); > + dev_set_drvdata(&ipc_dev->dev, ipc_dev); > + dev_set_name(&ipc_dev->dev, devname); > + device_initialize(&ipc_dev->dev); > + > + ret = device_add(&ipc_dev->dev); > + if (ret < 0) { > + dev_err(&ipc_dev->dev, "%s device create failed\n", > + __func__); > + ret = -ENODEV; > + goto err_dev_add; > + } > + > + if (ipc_dev->cfg->mode == IPC_DEV_MODE_IRQ) { > + if (devm_request_irq(&ipc_dev->dev, > + ipc_dev->cfg->irq, > + ipc_dev_irq_handler, > + ipc_dev->cfg->irqflags, > + dev_name(&ipc_dev->dev), > + ipc_dev)) { > + dev_err(&ipc_dev->dev, > + "Failed to request irq\n"); > + goto err_irq_request; > + } > + } That looks really wrong to me. This is the class driver, so why are you handling the interrupts of the devices in it? You are clearly making assumption that the interrupt will always be used only for command completion, but that may not be the case. No assumptions. Just define completion callbacks, and let the drivers handle the actual interrupts. > + *ptr = ipc_dev; > + > + devres_add(dev, ptr); > + return ipc_dev; > + > +err_irq_request: > + device_del(&ipc_dev->dev); > +err_dev_add: > + kfree(ipc_dev); > +err_dev_create: > + devres_free(ptr); > + return ERR_PTR(ret); > +} > +EXPORT_SYMBOL_GPL(devm_intel_ipc_dev_create); > + > +static int __init intel_ipc_init(void) > +{ > + ipc_channel_lock_init(); > + return class_register(&intel_ipc_class); > +} > + > +static void __exit intel_ipc_exit(void) > +{ > + class_unregister(&intel_ipc_class); > +} > +subsys_initcall(intel_ipc_init); > +module_exit(intel_ipc_exit); > + > +MODULE_LICENSE("GPL v2"); > +MODULE_AUTHOR("Kuppuswamy Sathyanarayanan<sathyanarayanan.kuppuswamy@linux.intel.com>"); > +MODULE_DESCRIPTION("Intel IPC device class driver"); To be honest, creating an extra logical device for the IPC hosts, and the entire class, all feel unnecessarily complex to me. The goal of this patch should be possible to achieve in a much simpler and flexible way. IMO this patch needs to be redesigned. Thanks, -- heikki
next prev parent reply other threads:[~2017-11-23 13:35 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-10-29 9:49 [RFC v8 0/7] SCU/PMC/PUNIT Inter-Processor Communication(IPC) driver cleanup sathyanarayanan.kuppuswamy 2017-10-29 9:49 ` [RFC v8 1/7] platform/x86: intel_punit_ipc: Fix resource ioremap warning sathyanarayanan.kuppuswamy 2017-11-03 12:13 ` Andy Shevchenko 2017-10-29 9:49 ` [RFC v8 2/7] platform/x86: intel_pmc_ipc: Use MFD framework to create dependent devices sathyanarayanan.kuppuswamy 2017-11-23 11:49 ` Heikki Krogerus 2017-11-23 17:08 ` Guenter Roeck 2018-01-21 4:42 ` sathya 2017-10-29 9:49 ` [RFC v8 3/7] platform/x86: intel_pmc_ipc: Use regmap calls for GCR updates sathyanarayanan.kuppuswamy 2017-11-23 12:29 ` Heikki Krogerus 2017-10-29 9:49 ` [RFC v8 4/7] platform: x86: Add generic Intel IPC driver sathyanarayanan.kuppuswamy 2017-11-23 13:29 ` Heikki Krogerus [this message] 2018-01-21 4:59 ` sathya 2017-10-29 9:49 ` [RFC v8 5/7] platform/x86: intel_punit_ipc: Use generic intel ipc device calls sathyanarayanan.kuppuswamy 2017-10-29 9:49 ` [RFC v8 6/7] platform/x86: intel_pmc_ipc: Use generic Intel IPC " sathyanarayanan.kuppuswamy 2017-10-29 9:50 ` [RFC v8 7/7] platform/x86: intel_scu_ipc: " sathyanarayanan.kuppuswamy 2017-11-23 13:56 ` [RFC v8 0/7] SCU/PMC/PUNIT Inter-Processor Communication(IPC) driver cleanup Heikki Krogerus
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20171123132916.GE17418@kuha.fi.intel.com \ --to=heikki.krogerus@linux.intel.com \ --cc=a.zummo@towertech.it \ --cc=alexandre.belloni@free-electrons.com \ --cc=andy@infradead.org \ --cc=dvhart@infradead.org \ --cc=hpa@zytor.com \ --cc=lee.jones@linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-rtc@vger.kernel.org \ --cc=linux-watchdog@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=platform-driver-x86@vger.kernel.org \ --cc=qipeng.zha@intel.com \ --cc=sathyanarayanan.kuppuswamy@linux.intel.com \ --cc=sathyaosid@gmail.com \ --cc=souvik.k.chakravarty@intel.com \ --cc=tglx@linutronix.de \ --cc=wim@iguana.be \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).