Re: UIO and Fedora 13 (kernel 33.6)

[Armin Steinhoff <armin@steinhoff.de>]

Hi,

many thanks for your support ... I have in the meantime a working version.
Would you please implement your advices into the misleading examples of 
UIO ?

Cheers

--Armin



Hans J. Koch wrote:
> On Wed, Sep 01, 2010 at 09:31:39AM +0200, Armin Steinhoff wrote:
>> Small correction ... I don't mean the "initial platform_data" but
>> the initial resource data of the platform driver.
>>
>> --Armin
>>
>>
>>    Hans J. Koch wrote:
>>> After a successfull uio_register_device() there is both a /dev/uioX
>>> and a directory /sys/class/uio/uioX/.
>> In the attachment is an updated version of uio_jand.
>>
>> The module uio_jand.ko can be inserted and removed,  no messages
>> visible by dmesg, no kernel oops, no dev/uio*  and no class entries
>> available.
>>
>> There are only entries of uio_jand in /sys/module,
>> /sys/bus/platform/drivers and /sys/uio/holders ... I'm really
>> confused =:-/
>>
>> It's completely unclear how to write the initial platform_data of
>> the platform device in the example uio_smx.c :
>>
>>       regs = platform_get_resource(dev, IORESOURCE_MEM, 0);
>>       if (!regs) {
>>           dev_err(&dev->dev, "No memory resource specified\n");
>>           goto out_free;
>>
>> Same issue in uio_platform_genirq ...
> You only seem to be working on x86 ... ;-)
>
> If you register a platform driver, you also need to register a platform
> device with the same name, otherwise your driver's probe() function will
> never be called. In struct platform_device you can also specify an array
> of resources (e.g. memory, interrupts) which can be queried by the driver
> in the way you quoted above.
>
> The ARM architecture (for example) uses a specific board support file for
> each board that sets up (among other things) these platform devices.
> (See arch/arm/mach-xxx/board-yyy.c for examples)
>
> Other archs like PowerPC use the OpenFirmware/DeviceTree interface to set up
> such board specific things. On x86, there's no real solution yet since all
> such boards used to be more or less "PC compatible". Platform devices exist
> only in low level arch code, all special devices (or those added by the user)
> announce themselves as PCI devices, are controllable from userspace
> (e.g. I2C, SPI) or have another interface that allows auto probing (e.g. USB).
>
> The first version of your driver did the right thing by using
> platform_device_register_simple() and driver_register(). That avoids the
> need for a separate file which calls platform_device_register().
>
> So, go back to your first version, and fix the real bugs.
>
> Thanks,
> Hans
>
>