On Fri, Jul 19, 2013 at 11:42:11AM +0200, Maxime Ripard wrote: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 :)On Wed, Jul 17, 2013 at 09:17:58AM -0700, Greg KH wrote:Oh crap. You are totally right. That's why we added the new deviceOn Wed, Jul 17, 2013 at 01:46:50PM +0200, Maxime Ripard wrote:Yes, I know that, and it's actually my point.On Mon, Jul 15, 2013 at 11:41:07PM -0700, Greg KH wrote:It will be created by the driver core for any device attached to theOn Mon, Jul 15, 2013 at 11:16:19PM +0200, Oliver Schinagl wrote:One thing I don't get here is why it should be set in theSo using these new patches for binary attributes, how can I pass dataHow is the platform device not the same thing that was passed to your
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.
probe function?
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?
driver automatically.
I mean, here, the sysfs file will be created under something likeYou can't have multiple drivers with the same name loaded (or the same
.../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.
module loaded multiple times.) You can have multiple devices for a
single driver, which is what we do all the time.
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.
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