Re: [linux-sunxi] Re: [PATCH 1/2] Initial support for Allwinner'sSecurity ID fuses

From: Oliver Schinagl
Date: Tue Jul 30 2013 - 09:26:24 EST

Hey Greg!

On 20-07-13 01:49, Greg KH wrote:
On Fri, Jul 19, 2013 at 11:42:11AM +0200, Maxime Ripard wrote:
On Wed, Jul 17, 2013 at 09:17:58AM -0700, Greg KH wrote:
On Wed, Jul 17, 2013 at 01:46:50PM +0200, Maxime Ripard wrote:
On Mon, Jul 15, 2013 at 11:41:07PM -0700, Greg KH wrote:
On Mon, Jul 15, 2013 at 11:16:19PM +0200, Oliver Schinagl wrote:
So using these new patches for binary attributes, how can I pass data
between my driver and the sysfs files using a platform_driver? Or are
other 'hacks' needed and using the .groups attribute from
platform_driver->device_driver->groups is really the wrong approach.

I did ask around and still haven't figured it out so far, so I do
apologize if you feel I'm wasting your precious time.
How is the platform device not the same thing that was passed to your
probe function?
One thing I don't get here is why it should be set in the
platform_driver structure. From my understanding of the device model,
and since what Oliver is trying to do is exposing a few bytes of memory
to sysfs, shouldn't the sysfs file be attached to the device instead?
It will be created by the driver core for any device attached to the
driver automatically.

I mean, here, the sysfs file will be created under something like
.../drivers/sunxi-sid/eeprom. What happens when you have several
instances of that driver loaded? I'd expect it to have several sysfs
files created, one for each instance. So to me, it should be in the
device structure, not the driver one.
You can't have multiple drivers with the same name loaded (or the same
module loaded multiple times.) You can have multiple devices for a
single driver, which is what we do all the time.
Yes, I know that, and it's actually my point.
With the current oliver's code he pasted earlier in this thread:

# find /sys/ -name eeprom

While I'd expect the eeprom file to be located in
/sys/bus/platform/devices/X.eeprom/eeprom like it used to be in the v4,
since it's an instance-specific content.
Oh crap. You are totally right. That's why we added the new device
create call, to allow this to work properly.

Right now you are getting the kobject of the driver, not the device, in
the callback, which is not what you want (sure, if you only have once
instance, you can work around it, but don't it's the driver core's fault
for not giving you the correct api...)

Let me go look at how I can make this work "easier", give me a few days.
Not wanting to be rude, but it has been a little more then a few days, any progress? Just want to know what I have to modify my driver to so it can go into the next merge window :)


greg k-h

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at