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]

Message-ID: <20100901185620.GA2514@local>
Date:	Wed, 1 Sep 2010 20:56:20 +0200
From:	"Hans J. Koch" <hjk@...utronix.de>
To:	Armin Steinhoff <armin@...inhoff.de>
Cc:	"Hans J. Koch" <hjk@...utronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: UIO and Fedora 13  (kernel 33.6)

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/