[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZA9Me2d9IsoYGifp@kroah.com>
Date: Mon, 13 Mar 2023 17:16:59 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: VaibhaavRam.TL@...rochip.com
Cc: arnd@...db.de, Kumaravel.Thiagarajan@...rochip.com,
linux-kernel@...r.kernel.org, UNGLinuxDriver@...rochip.com,
Tharunkumar.Pasumarthi@...rochip.com
Subject: Re: [PATCH v7 char-misc-next] misc: microchip: pci1xxxx: Add
OTP/EEPROM driver for the pci1xxxx switch
On Mon, Mar 13, 2023 at 04:01:15PM +0000, VaibhaavRam.TL@...rochip.com wrote:
> > Again, default group will handle this automatically, you should never
> > need to call a sysfs_*() call from a driver. Otherwise something is usually very wrong.
>
> Are you recommending similar to this snippet?
>
> static struct bin_attribute *pci1xxxx_bin_attributes[] = {
> &pci1xxxx_otp_attr,
> &pci1xxxx_eeprom_attr
> NULL,
> };
>
> static const struct attribute_group pci1xxxx_bin_attributes_group = {
> .bin_attrs = pci1xxxx_bin_attributes,
> };
> ..
> ..
> auxiliary_device.device.attribute_group = pci1xxxx_bin_attributes_group
Yes.
> This creates sysfs for both EEPROM and OTP at once and handles for its removal, right?
> But, In this case, I have to check whether EEPROM is responsive and only then create sysfs for it.
>
> Can you please provide some guidance, on how to handle this situation without using sysfs_*().
Use the "is_visible" callback in your group to tell the driver core if
the specific attribute needs to be created or not.
thanks,
greg k-h
Powered by blists - more mailing lists