Skip to contentSkip to conversation

(dynamic sysfs callbacks) device attribute callbacks - take 2

PATCH In review Yani Ioannou 2 participants 6 messages May 17, 2005 – May 18, 2005

lore
Share & tools
lore
#0 lore raw

PATCH 1/15 (dynamic sysfs callbacks) device attribute callbacks - take 2

Hi,

The following patches implement dynamic sysfs callbacks for device_attribute, and provide a possible standard sensor attribute macro for the majority of the i2c sensor chip/hwmon drivers. Finally a patch against adm1026 shows how the patch can be used to reduce the footprint and clean up an existing driver.

The new form of dynamic sysfs callback simply passes a reference to the device_attribute struct, instead of a void *, along the lines of the suggestion by Russell King (see
http://lkml.org/lkml/2005/5/14/116). Embedding the device_attribute struct in a custom struct one can use a macro based on container_of to access the custom attribute specific data.

Although functionally as capable as the void *, this solution I feel is better in that it rids of some error-prone casting, and the resulting code seems generally cleaner and easier to understand, there is also no need for the extra void * member in the base sysfs attribute. On the other hand a bit more work is required to implement this on a grand scale, and in many cases a new attribute struct might have to be defined for a driver, along with any convenience macros. My example patch implements a new attribute struct sensor_device_attribute that should be reusable by the majority of i2c chip drivers (as suggested by Greg).

Thanks,
Yani

#1 lore raw
Quoted 7 lines · Yani Ioannou

Hi,

The following patches implement dynamic sysfs callbacks for device_attribute, and provide a possible standard sensor attribute macro for the majority of the i2c sensor chip/hwmon drivers. Finally a patch against adm1026 shows how the patch can be used to reduce the footprint and clean up an existing driver.

<snip>

Ok, I think I got all of these patches applied properly (hint, don't label your intro message as 1/15, it should be 0/14, with 14 different patches, that threw me off for a bit.) I've also included your i2c driver patch for the adm1026 driver only. All of these patches are now in my tree and can be found on kernel.org in the place where my patchscripts notified you. If you could verify them I would appreciate it (I also added a few patches for stuff that was in my tree only, like new i2c drivers and some usb and pci sysfs stuff to make them build properly.) All of this should show up in the next -mm release too.

Thanks a lot for sticking with this process, I really appreciate it. Now you can get back to actually fixing up the i2c drivers you wanted to, which was what you wanted to do in the first place :)

thanks again,

greg k-h

#2 lore raw

Hi Greg,

Quoted 9 lines · Greg KH

Ok, I think I got all of these patches applied properly (hint, don't label your intro message as 1/15, it should be 0/14, with 14 different patches, that threw me off for a bit.) I've also included your i2c driver patch for the adm1026 driver only. All of these patches are now in my tree and can be found on kernel.org in the place where my patchscripts notified you. If you could verify them I would appreciate it (I also added a few patches for stuff that was in my tree only, like new i2c drivers and some usb and pci sysfs stuff to make them build properly.) All of this should show up in the next -mm release too.

Thanks a lot! Sorry about the incorrect numbering, first time I've done an intro. I'll have to send you a patch against the differences between 2.6.12-rc4 and 2.6.12-rc4-mm2 so we don't run into a huge amount of trouble when they merge...

A quick glance through everything looks fine, but I'll do a proper check tomorrow using your git tree.

Quoted 3 lines

Thanks a lot for sticking with this process, I really appreciate it. Now you can get back to actually fixing up the i2c drivers you wanted to, which was what you wanted to do in the first place :)

Yes it will be good to get back to my own area for a bit, maybe even finally get bmcsensors into a state where it can be accepted :-), however it has been a nice break and I can see other areas that could benefit from things along the line of this patch so I might yet intrude upon the rest of the kernel again ;-).

Thanks,
Yani

#3 lore raw
Quoted 13 lines · Yani Ioannou

Hi Greg,

Quoted 9 lines · Greg KH

Ok, I think I got all of these patches applied properly (hint, don't label your intro message as 1/15, it should be 0/14, with 14 different patches, that threw me off for a bit.) I've also included your i2c driver patch for the adm1026 driver only. All of these patches are now in my tree and can be found on kernel.org in the place where my patchscripts notified you. If you could verify them I would appreciate it (I also added a few patches for stuff that was in my tree only, like new i2c drivers and some usb and pci sysfs stuff to make them build properly.) All of this should show up in the next -mm release too.

Quoted 4 lines

Thanks a lot! Sorry about the incorrect numbering, first time I've done an intro. I'll have to send you a patch against the differences between 2.6.12-rc4 and 2.6.12-rc4-mm2 so we don't run into a huge amount of trouble when they merge...

That would be good.

Quoted 2 lines

A quick glance through everything looks fine, but I'll do a proper check tomorrow using your git tree.

I don't have a git tree for stuff that is not ready to be sent to Linus at that moment. I'm using quilt to stage stuff and have them be sucked into the -mm releases. It's easier that way for me right now.

thanks,

greg k-h

#4 lore raw
Quoted 5 lines · Greg KH
Quoted 1 line · Yani Ioannou

Hi Greg,

I don't have a git tree for stuff that is not ready to be sent to Linus at that moment. I'm using quilt to stage stuff and have them be sucked into the -mm releases. It's easier that way for me right now.

Yes I just realized my mistake, OK I'll try the patches against -mm2 along with a patch to update all the added device callbacks/differences and make sure nothing goes horribly wrong with it tomorrow. BTW I sent a patch against it87.c to lm_sensors so Jean could test things (apparently adm1026 hasn't got many users).

Thanks again,
Yani

#5 lore raw
Quoted 2 lines · Yani Ioannou

BTW I sent a patch against it87.c to lm_sensors so Jean could test things (apparently adm1026 hasn't got many users).

Yes, I was going to wait until I got a "ack" from him before applying that patch.

thanks,

greg k-h