linux-kernel - Re: UIO and Fedora 13 (kernel 33.6)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 01 Sep 2010 23:40:05 +0200
From:	Armin Steinhoff <armin@...inhoff.de>
To:	"Hans J. Koch" <hjk@...utronix.de>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: UIO and Fedora 13  (kernel 33.6)


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
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/