linux-kernel - Re: Creating a new platform_bus inside a spi

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: <2501338.EAyTJJ482M@wuerfel>
Date:	Fri, 07 Nov 2014 18:04:35 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	DATACOM - Érico Nunes 
	<erico.nunes@...acom.ind.br>
Cc:	grant.likely@...aro.org, robh+dt@...nel.org,
	devicetree@...r.kernel.org, sameo@...ux.intel.com,
	lee.jones@...aro.org, linux-kernel@...r.kernel.org
Subject: Re: Creating a new platform_bus inside a spi_driver

On Friday 07 November 2014 14:37:26 DATACOM - Érico Nunes wrote:
> Hello Arnd and all,
> 
> On 11/07/2014 08:04 AM, Arnd Bergmann wrote:
> > On Thursday 06 November 2014 18:02:52 DATACOM - Érico Nunes wrote:
> >> The idea is that "fpga-spi" is a spi_driver which instantiates all of the
> >> "fpga-deviceN" as platform_devices, through the use of
> >> of_platform_populate(dev->of_node, NULL, NULL, dev).
> >>
> >> The visible problem we're facing with this approach is that, as the internal
> >> platform_devices have a "reg" property, of_platform_populate() eventually
> >> triggers an address translation which is apparently trying to translate the
> >> addresses of the internal platform_bus to addresses of the processor memory
> >> map.
> >> This translation is however not part of our intention, as we intend to have an
> >> internal bus with its own memory map.
> >> This fails when __of_translate_address() reaches the spi-master boundary
> >> because (as it seems to make sense) it isn't possible to translate them past
> >> that.
> >> A KERN_ERR rated message like
> >> "prom_parse: Bad cell count for /soc@...00000/spi@...0/fpga@1"
> >> is thrown by __of_translate_address() and later it is not possible to obtain
> >> the "reg" address with platform_get_resource().
> >>
> >> On this scenario, we have a few questions and, depending on the outcome of
> >> these, possibly a patch.
> >>
> >> 1. Is it possible to have an internal platform_bus with a different memory map
> >> as we intended? Or are platform_busses and platform_devices supposed to always
> >> be mapped on the processor memory map?
> > It's inconsistent. We have some code that assumes that platform devices
> > are always memory mapped, and some other code that breaks this assumption.
> 
> By this I take that the platform subsystem could be made generic so it can be
> used in both ways (mapped to processor memory map or mapped to a private memory
> map). There seems to be no strict requirement enforcing it to be processor
> memory map.
> 
> Is this correct?

It could be, but I'm sure if that is a good idea or not. It might complicate
things elsewhere, so it would at least need careful testing and consensus
among a broader group of developers.

> >> 2. If platform_bus and platform_device were actually designed to always be
> >> mappable to the processor memory map, what would be a different approach to
> >> this problem?  One alternative considered was to define a new "fpga_bus" and
> >> "fpga_device" but that seemed as an overkill approach to the problem.
> > I think the existing mfd framework should do what you need, when you call
> > mfd_add_devices() and pass a table of cells with the compatible strings
> > for your devices, it should create the platform devices you want. If not,
> > that can probably be fixed in the mfd core code.
> >
> >
> 
> Thanks for the tip, we were not aware of the purpose of this mfd framework and
> we will take a look at this framework now.
> However I'm thinking now that eventually it would fall in the same case of
> trying to translate the address of any "reg" dts property to the processor
> memory map, and fail with the same error for the SPI case.
> 
> Considering this and taking the answer to the first question, do you think a
> patch fixing the "error" report by the translation function would be
> acceptable?
> We can prepare/test that under our platform and submit it.

Please try to use the mfd approach first. There are a lot of mfd drivers
on the SPI bus, so I'd assume this works fine.

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