linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Enric Balletbo i Serra <enric.balletbo@collabora.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: lee.jones@linaro.org, gwendal@chromium.org,
	drinkcat@chromium.org, linux-kernel@vger.kernel.org,
	groeck@chromium.org, kernel@collabora.com, bleung@chromium.org,
	Olof Johansson <olof@lixom.net>
Subject: Re: [PATCH 2/7] mfd / platform: cros_ec: move lightbar attributes to its own driver.
Date: Fri, 23 Nov 2018 12:52:55 +0100	[thread overview]
Message-ID: <2c70235f-8f10-de5f-7df5-21104fd371c4@collabora.com> (raw)
In-Reply-To: <20181122174151.GA30386@roeck-us.net>

Hi Guenter,

On 22/11/18 18:41, Guenter Roeck wrote:
> Hi Enric,
> 
> On Thu, Nov 22, 2018 at 12:33:51PM +0100, Enric Balletbo i Serra wrote:
>> The entire way how cros sysfs attibutes are created is broken.
>> cros_ec_lightbar should be its own driver and its attributes should be
>> associated with a lightbar driver not the mfd driver. In order to retain
>> the path, the lightbar attributes are attached to the cros_class.
>>
>> The patch also adds the sysfs documentation.
>>
>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>> ---
>>
> ...
>>  
>> +int cros_ec_attach_attribute_group(struct cros_ec_dev *ec,
>> +				   struct attribute_group *attrs)
>> +{
>> +	return sysfs_create_group(&ec->class_dev.kobj, attrs);
>> +}
>> +EXPORT_SYMBOL(cros_ec_attach_attribute_group);
>> +
>> +void cros_ec_detach_attribute_group(struct cros_ec_dev *ec,
>> +				    struct attribute_group *attrs)
>> +{
>> +	sysfs_remove_group(&ec->class_dev.kobj, attrs);
>> +}
>> +EXPORT_SYMBOL(cros_ec_detach_attribute_group);
>> +
> 
> Are those two functions necessary ? Why not just call sysfs_create_group
> and sysfs_remove_group directly from the calling code ?
> 

Actually we have cros_ec_dev which registers the cros_ec class, and sysfs/vbc
and lightbar using this cros_ec class. I had problems unloading the different
modules. For example, when I removed cros_ec_dev modules before
cros_ec_sysfs/cros_ec_vbc/cros_ec_lightbar I got a hang.

To solve the hang I did the easy solution that is make these drivers depend on
cros_ec_dev so you're not able to unload cros_ec_dev if first you don't unload
the sysfs/vbc/lightbar.

Thinking again about it, I don't really understand now why failed in the first
place, cros_ec_dev is the parent, so, on remove should call mfd_remove_devices
for the subdevices.

So, let me check again this and I'll back to you.

Thanks,
 Enric


> Thanks,
> Guenter
> 

  reply	other threads:[~2018-11-23 11:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-22 11:33 [PATCH 0/7] mfd / platform: cros_ec: move cros_ec sysfs attributes to its own drivers Enric Balletbo i Serra
2018-11-22 11:33 ` [PATCH 1/7] mfd: cros_ec: use devm_mfd_add_devices Enric Balletbo i Serra
2018-11-22 11:33 ` [PATCH 2/7] mfd / platform: cros_ec: move lightbar attributes to its own driver Enric Balletbo i Serra
2018-11-22 17:41   ` Guenter Roeck
2018-11-23 11:52     ` Enric Balletbo i Serra [this message]
2018-11-23 12:03       ` Guenter Roeck
2018-11-22 11:33 ` [PATCH 3/7] mfd / platform: cros_ec: move vbc " Enric Balletbo i Serra
2018-11-22 11:33 ` [PATCH 4/7] mfd / platform: cros_ec: move debugfs " Enric Balletbo i Serra
2018-11-22 18:52   ` Guenter Roeck
2018-11-22 11:33 ` [PATCH 5/7] mfd / platform: cros_ec: move device sysfs " Enric Balletbo i Serra
2018-11-22 19:09   ` Guenter Roeck
2018-11-29 11:21   ` Dan Carpenter
2018-11-29 14:43     ` Enric Balletbo i Serra
2018-11-29 14:56       ` Dan Carpenter
2018-11-22 11:33 ` [PATCH 6/7] mfd / platform: cros_ec: instantiate only if th EC has a VBC NVRAM Enric Balletbo i Serra
2018-11-22 19:14   ` Guenter Roeck
2018-11-23 10:37     ` Enric Balletbo i Serra
2018-11-22 11:33 ` [PATCH 7/7] platform/chrome: cros_ec_lightbar: instantiate only if the EC has a lightbar Enric Balletbo i Serra
2018-11-22 19:25   ` Guenter Roeck
2018-11-23 11:10     ` Enric Balletbo i Serra
2018-11-23 11:39       ` Guenter Roeck

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=2c70235f-8f10-de5f-7df5-21104fd371c4@collabora.com \
    --to=enric.balletbo@collabora.com \
    --cc=bleung@chromium.org \
    --cc=drinkcat@chromium.org \
    --cc=groeck@chromium.org \
    --cc=gwendal@chromium.org \
    --cc=kernel@collabora.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=olof@lixom.net \
    /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;
as well as URLs for NNTP newsgroup(s).