linux-kernel - RE: [PATCH v7 char-misc-next] misc: microchip: pci1xxxx: Add OTP/EEPROM driver for the pci1xxxx switch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <DM4PR11MB6238653CE39A429E4B10B9C497BF9@DM4PR11MB6238.namprd11.prod.outlook.com>
Date:   Wed, 15 Mar 2023 09:07:12 +0000
From:   <VaibhaavRam.TL@...rochip.com>
To:     <gregkh@...uxfoundation.org>
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


From: Greg KH <gregkh@...uxfoundation.org> 
Sent: Monday, March 13, 2023 9:47 PM
To: VaibhaavRam TL - I69105 <VaibhaavRam.TL@...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.

I have added "is_bin_visible" callback and it is working fine. Sysfs for EEPROM and OTP is created inside drivers folder

But I have used attribute group inside device_driver under auxiliary_driver structure.
as opposed to what I have mentioned previously because , struct device_driver is exposed to me instead of struct device.
Since there can be only one instance of driver for multiple devices, I cannot account for multiple instances of EEPROM/OTPs present in those devices.

Is it possible to use sysfs_create_group in this situation?

Thanks
Vaibhaav Ram