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]

Date:	Sun, 15 Dec 2013 01:55:46 +0400
From:	Sergei Ianovich <ynvich@...il.com>
To:	Arnd Bergmann <arnd@...db.de>
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 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.

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