[ARM ATTEND] Following discussions

[ARM ATTEND] Following discussions

[Boris BREZILLON]

Hello,

As a contributor to atmel's at91 platform (and recently allwinner's sunxi)
I'm interested in following the ARM summit.
Moreover, I'll be involved in even more ARM related developments as part
of my future job at Free Electrons.

I'm particularly interested in DT bindings discussions to both follow DT
bindings progress/status on several subsystems and learn about their
limitations.

But more generally I'm interested in knowing where Linux dev for ARM 
platforms
is heading towards:
- are there any new subsystems in the pipeline ?
- are there any planned refactor in existing subsystems (or arch code) ?
- ...

Best Regards,

Boris

[ARM ATTEND] Following discussions

[Alexandre Belloni]

Hi,

As I have been working on the i.mx28, Marvell Berlin and AT91 linux
support, I'm interested in attending the ARM summit to follow the
current status and learn about the current best practices.

I've also been doing a lot of cleanup and I would like to discuss how to
go about cleaning the style issues in the Device Trees like lists
without elements bracketed individually, magic values used instead of
macros and the likes.

Regards,

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140324/cba4d98d/attachment.sig>

[ARM ATTEND] Following discussions

[Rob Herring]

On Mon, Mar 24, 2014 at 11:06 AM, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:
> Hi,
>
> As I have been working on the i.mx28, Marvell Berlin and AT91 linux
> support, I'm interested in attending the ARM summit to follow the
> current status and learn about the current best practices.
>
> I've also been doing a lot of cleanup and I would like to discuss how to
> go about cleaning the style issues in the Device Trees like lists
> without elements bracketed individually, magic values used instead of
> macros and the likes.

The first step would be getting agreement that either of those are
really considered style issues. IMO, use of defines is purely
optional. For DT's that are pretty much static, there is little point
in going back and changing them now. Changing ALL numbers in dts files
to defines is not the direction either. Generally, numbers that come
from the h/w (addresses, irq numbers, etc.) should not be defines.
Things which are more just DT convention like irq trigger values or
clock numbers can be defines. The question to ask is does it improve
readability or just add another level of lookup when you need to know
the actual value.

Rob

[ARM ATTEND] Following discussions

[Alexandre Belloni]

On 24/03/2014 at 13:03:18 -0500, Rob Herring wrote :
> On Mon, Mar 24, 2014 at 11:06 AM, Alexandre Belloni
> <alexandre.belloni@free-electrons.com> wrote:
> > Hi,
> >
> > As I have been working on the i.mx28, Marvell Berlin and AT91 linux
> > support, I'm interested in attending the ARM summit to follow the
> > current status and learn about the current best practices.
> >
> > I've also been doing a lot of cleanup and I would like to discuss how to
> > go about cleaning the style issues in the Device Trees like lists
> > without elements bracketed individually, magic values used instead of
> > macros and the likes.
> 
> The first step would be getting agreement that either of those are
> really considered style issues. IMO, use of defines is purely
> optional. For DT's that are pretty much static, there is little point
> in going back and changing them now. Changing ALL numbers in dts files
> to defines is not the direction either. Generally, numbers that come
> from the h/w (addresses, irq numbers, etc.) should not be defines.
> Things which are more just DT convention like irq trigger values or
> clock numbers can be defines. The question to ask is does it improve
> readability or just add another level of lookup when you need to know
> the actual value.
> 

That's exactly the point of my question. Mark Rutland recently made
comment on some newly submitted device trees that were basically
structured like previous device trees. A lot of copy pasting is involved
when writing those. Another example would be how many device tree have a
"clocks" container node encompassing the clock subnodes that is useless,
non-standard and not guaranteed to probe ?
How many nodes have an unit-address without a reg ? Worse, without a
parent with #address-cells and #size-cells ?

My guess is that if you want people to stop spreading that kind of
issues, at some point in time it will be necessary to remove those from
the current DTs, unless we get that promised DT validator.

Until then, you can't expect people to read and understand the ePAPR
instead of simply reading/copying existing DTs. The code is still the
documentation in the kernel.

I truly believe that your time is valuable and has to be spent reviewing
new bindings instead of repeating over and over again the same do's and
don't.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com