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]

Date:	Tue, 11 Nov 2014 11:07:57 +0000
From:	Grant Likely <grant.likely@...aro.org>
To:	Arnd Bergmann <arnd@...db.de>,
	DATACOM - Érico Nunes 
	<erico.nunes@...acom.ind.br>
Cc:	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 Fri, 07 Nov 2014 18:04:35 +0100
, Arnd Bergmann <arnd@...db.de>
 wrote:
> 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.

I don't think it is a good idea. I would prefer to make the behaviour of
of_platform_populate() generic so it could work for multiple bus
types rather than reusing/abusing platform_device in this way.

If the devices on the FPGA were memory mapped, it would be a different
situation, but being behind an SPI bus where the access to those devices
must always be mediated by the SPI controller, it would be better to
have a separate bus type and a separate pool of drivers for those
devices.

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