From: Greg KH <gregkh@linuxfoundation.org>
To: Murali Nalajala <mnalajal@codeaurora.org>
Cc: rafael@kernel.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org, bjorn.andersson@linaro.org
Subject: Re: [PATCH] base: soc: Export soc_device_to_device API
Date: Thu, 19 Sep 2019 23:32:03 +0200 [thread overview]
Message-ID: <20190919213203.GA395325@kroah.com> (raw)
In-Reply-To: <1568927624-13682-1-git-send-email-mnalajal@codeaurora.org>
On Thu, Sep 19, 2019 at 02:13:44PM -0700, Murali Nalajala wrote:
> If the soc drivers want to add custom sysfs entries it needs to
> access "dev" field in "struct soc_device". This can be achieved
> by "soc_device_to_device" API. Soc drivers which are built as a
> module they need above API to be exported. Otherwise one can
> observe compilation issues.
>
> Signed-off-by: Murali Nalajala <mnalajal@codeaurora.org>
> ---
> drivers/base/soc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/base/soc.c b/drivers/base/soc.c
> index 7c0c5ca..4ad52f6 100644
> --- a/drivers/base/soc.c
> +++ b/drivers/base/soc.c
> @@ -41,6 +41,7 @@ struct device *soc_device_to_device(struct soc_device *soc_dev)
> {
> return &soc_dev->dev;
> }
> +EXPORT_SYMBOL_GPL(soc_device_to_device);
>
> static umode_t soc_attribute_mode(struct kobject *kobj,
> struct attribute *attr,
What in-kernel driver needs this?
Is linux-next breaking without this?
We don't export things unless we have a user of the export.
Also, adding "custom" sysfs attributes is almost always not the correct
thing to do at all. The driver should be doing it, by setting up the
attribute group properly so that the driver core can do it automatically
for it.
No driver should be doing individual add/remove of sysfs files. If it
does so, it is almost guaranteed to be doing it incorrectly and racing
userspace.
And yes, there's loads of in-kernel examples of doing this wrong, I've
been working on fixing that up, look at the patches now in Linus's tree
for platform and USB drivers that do this as examples of how to do it
right.
thanks,
greg k-h
next prev parent reply other threads:[~2019-09-19 21:32 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-19 21:13 [PATCH] base: soc: Export soc_device_to_device API Murali Nalajala
2019-09-19 21:32 ` Greg KH [this message]
2019-09-19 21:53 ` Bjorn Andersson
2019-09-19 21:58 ` Greg KH
2019-09-19 22:14 ` Bjorn Andersson
2019-09-19 22:25 ` Greg KH
2019-09-19 22:40 ` Bjorn Andersson
2019-09-19 22:45 ` Greg KH
2019-09-19 23:39 ` mnalajal
2019-09-20 3:36 ` Bjorn Andersson
2019-09-20 6:10 ` Greg KH
2019-09-23 21:35 ` mnalajal
2019-09-24 4:50 ` Greg KH
2019-09-26 14:33 ` mnalajal
2019-09-27 5:46 ` Greg KH
2019-09-19 22:27 ` mnalajal
2019-09-19 22:46 ` Greg KH
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=20190919213203.GA395325@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=bjorn.andersson@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mnalajal@codeaurora.org \
--cc=rafael@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: link
Be 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