linux-kernel - Re: [RFC] [PATCH] Device Tree on ARM platform

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:  <h4o0f6-k5o.ln1@woodchuck.wormnet.eu>
Date:	Wed, 27 May 2009 22:32:33 +0100
From:	Alexander Clouter <alex@...riz.org.uk>
To:	linux-kernel@...r.kernel.org
Cc:	devicetree-discuss@...abs.org,
	linux-arm-kernel@...ts.arm.linux.org.uk
Subject:  Re: [RFC] [PATCH] Device Tree on ARM platform

In gmane.linux.kernel Grant Likely <grant.likely@...retlab.ca> wrote:
> On Wed, May 27, 2009 at 12:56 PM, Alexander Clouter <alex@...riz.org.uk> wrote:
>> In gmane.linux.kernel Grant Likely <grant.likely@...retlab.ca> wrote:
>>> On Wed, May 27, 2009 at 9:05 AM, Robert Schwebel
>>>
>>> [snipped]
>>>
>> Although I have no input of value here, I'm hoping I do not become the
>> next posterchild for "pain++".
>>
>> I'm working through redo'ing the FPGA support in the TS-7800[1] into a
>> new bus rather than just continuing the messy direction I have been
>> going to date[2].
>>
>> My current approach is that the bus handles the 'hotplug'ing of the FPGA
>> bitstream by unregistering all the devices and then when it's informed
>> the new bitstream is ready it prods all the registered drivers if any
>> devices need bringing up (obviously drivers can be modprobe'd as and
>> when).
>>
>> The 'magic' is that the FPGA code has some special value[3] that what it
>> is and the drivers (outside the platform code) have a list of FPGA magic
>> values (with a mask) that they are willing to service.  The *bus*
>> (platform code) is what installs the devices effectively and only does
>> so if the loaded driver says it can drive a particular loaded bitstream
>> (in the bus driver struct is a array of ID's it checks).
>>
>> Does this sound sane?  Is it an approach that could be ACKed one day?
>> Currently the bit that might be considered sinful is there is for some
>> of the drivers (rtc-m48t86, timeriomem-rng and plat_nand) the FPGA bus
>> 'driver' is a light wrapper around the platform device driver.  This is
>> so that the hooks still exist so the bus know what to load and unload as
>> and when.
> 
> Personally, I'd not write a separate bus.  I'd write a platform driver
> which turns around and registers more platform devices with the
> original device as the parent in the _probe routine, and unregisters
> them in _remove.  Should have the same affect with less complex code.
> However, someone with more device-model-foo may have better advice.
> 
That's a thought, but this 'bus' does not just drive platform devices, 
there are other drivers that will live outside the scope.

I have a half completed GPIO expander for the 'factory' FPGA bitstream 
that could not be done as a platform device.  The GPIO pin's also 
multiplex as an ISA (PC/104) bus and chip select's a SPI bus too.

Another driver is a DMA engine provisioned by the factory bitstream too 
as well as AVR+ADC+watchdog system too.

What would make sense for this approach would be if it was to drive 
bit's from the opencores.org website.

Because there is a mix of platform devices and 'awkward' bit's, this is 
why I was thinking about a seperate bus.

Cheers for the suggestion, it's got me thinkingthat there still has to 
be a better way :)

Cheers

-- 
Alexander Clouter
.sigmonster says: Who goeth a-borrowing goeth a-sorrowing.


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