linux-kernel - Re: [UIO] SMX UIO interface

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 for Android: free password hash cracker in your pocket

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

Message-Id: <59079FAE-8CF7-4E2F-B5C6-77B6A6D2B8F8@niasdigital.com>
Date:	Thu, 2 Sep 2010 21:45:37 +1000
From:	Ben Nizette <bn@...sdigital.com>
To:	Armin Steinhoff <armin@...inhoff.de>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [UIO]  SMX UIO interface


On 02/09/2010, at 8:13 PM, Armin Steinhoff wrote:

> Ben Nizette wrote:
>> On 01/09/2010, at 5:22 PM, Armin Steinhoff wrote:
>> 
>>> Hi Ben,
>>> 
>>> I have a question about the SMX UIO Interface.
>>> 
>>> In the SMX module you are reading the data of the platform resourses:
>>> 
>>>    regs = platform_get_resource(dev, IORESOURCE_MEM, 0);
>>>    if (!regs) {
>>>        dev_err(&dev->dev, "No memory resource specified\n");
>>>        goto out_free;
>>>    }
>>> 
>>> But who sets these data initially ?
>> Who ever sets up the platform device that will bind to this driver, usually the board code (eg on avr32 arch/avr32/boards/*/setup.c, ARM is somewhere under arch/arm/mach-*/ I think).
>> 
>> The board code would create an array of struct resource with the appropriate memory regions and an IRQ entry, create a struct platform_device with the right content to bind to that driver, set the platform_device .resource field to the previously created array then call platform_device_register() to kick things off.
>> 
> 
>  That means there is additionally an individual driver of the board and the UIO interface is just for open up the hardware interfaces ?

Um, sort of, I guess.. :-)

The board code isn't a driver, it's just code that gets run at startup whose job is to register all the devices on the board.  If your board only contains probe-able busses then you might not need any board code at all but if you've got busses which can't be automatically discovered then something else needs to tell the kernel what devices are where.

Maybe a good place to start would be to read up a bit more on the Linux device model and look through some example board code, you'll probably learn more than me just answering small bits like this :-)

	--Ben.

> 
>  Thanks
> 
> --Armin
> 
> 
>> 	--Ben.
>> 
>>> Cheers
>>> 
>>> --Armin
>>> 
>> 
> 
> --
> 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/

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