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

[Greg KH <gregkh@linuxfoundation.org>]

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
> /sys/bus/platform/drivers/sunxi-sid/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.

greg k-h