linux-kernel - Re: [PATCH v2 00/16] ARM: support for ICP DAS LP-8x4x (with dts)

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: <201312150153.54044.arnd@arndb.de>
Date:	Sun, 15 Dec 2013 01:53:53 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Sergei Ianovich <ynvich@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Daniel Mack <zonque@...il.com>,
	Haojian Zhuang <haojian.zhuang@...il.com>
Subject: Re: [PATCH v2 00/16] ARM: support for ICP DAS LP-8x4x (with dts)

On Saturday 14 December 2013, Sergei Ianovich wrote:
> On Sat, 2013-12-14 at 22:03 +0100, Arnd Bergmann wrote:
> > On Friday 13 December 2013, Sergei Ianovich wrote:
> > > I've also decided not to create a single mfd device for
> > > machine-specific devices. Instead each type is supported by a separate
> > > driver in respective subsystem. It was tempting to hardcode all the
> > > constants in one source file, but that requires ugly initialization.
> > > The taken way produces much cleaner code.
> > 
> > I think you should at least change the DT representation for the FPGA
> > to show one device as the actual FPGA and attach children to that,
> > multiple indirection levels if necessary.
> > 
> > I suspect that the fpga is on some external-bus port with a specific
> > chip-select, so I would model this as
> > 
> >         extbus {
> >                 compatible = "simple-bus";
> >                 #address-cells = <1>;
> >                 #size-cells = <1>;
> >                 /* bus addresses 0-0xfffff mapped to 0x17000000 */
> >                 ranges = <0 0x17000000 0x100000>;
> >                 interrupt-parent = <&fpga-irq>;
> > 
> >                 fpga-irq: irq@6 {
> >                         regs = <6 16>; /* translated addresses
> >                         ...
> >                 };
> > 
> >                 fgpa-bus {
> >                         #address-cells = <1>;
> >                         #size-cells = <1>;
> >                         ranges;
> > 
> >                         serial@...0 {
> >                                 ...
> >                         };
> >                 };
> >         };
> > 
> > I also think you don't need to make the devices quite as fine-grained
> > here but instead group things together more. I would probably indeed
> > put everything that is not on one of the slots into a common device,
> > including the irqchip.
> 
> There are basically 2 options: one-for-all mfd device and one-for-one
> device drivers.
> 
> MFD
> pros:
> * easy to add into the tree (one file)
> * easy config (one option)
> 
> Separate devices
> * easy to support devices as respective subsystems evolve
> * easy to add new feature without breaking existing ones. Eg. it may
> make sense to provide industrial IO interface on analog IO devices
> * possible to have fine-grained configuration (eg. SRAM in kernel,
> serial and slot as modules)
> * proper device tree serves as a datasheet for the machine, so anyone
> who needs to work on it will have a decent view of the internals
> 
> I believe long-term benefits of separate devices outweigh immediate
> effects of an MFD. However, I certainly don't see the big picture and
> will accept your decision. Please make one.

Unfortunately I don't have a good way to judge the tradeoffs without
understanding more about the design of the hardware. Did I understand
you right that you expect future versions of the FPGA bitstream
to implement additional features or have a different set of endpoint
devices?

If so, I would argue that anything that you consider an optional
sub-device should have its own device node in the device tree.

Also, do you have to model hardware that is connected to the FPGA
rather than being part of it?

I suspect that you may have a different understanding of the term
MFD than what I was suggesting: A typical MFD driver in Linux is
basically a container device that has some registers on its own
like a version detection or the irqchip but mainly is there to
create sub-devices that each have a subset of the available
registers. The sub-devices may or may not be describe in DT in this
case.

	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/