linux-kernel - Re: [J-core] [PATCH v5 00/22] sh: LANDISK and R2Dplus convert to device tree

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: <20180507144306.GG1392@brightrain.aerifal.cx>
Date:   Mon, 7 May 2018 10:43:06 -0400
From:   Rich Felker <dalias@...c.org>
To:     Rob Landley <rob@...dley.net>
Cc:     John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        linux-sh@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [J-core] [PATCH v5 00/22] sh: LANDISK and R2Dplus convert to
 device tree

On Mon, May 07, 2018 at 08:40:35AM -0500, Rob Landley wrote:
> On 05/07/2018 06:00 AM, John Paul Adrian Glaubitz wrote:
> > I have been able to boot my own kernel on my USL-5P device, but
> > I could never get it to detect the IDE controller. Do I need
> > an additional patch for that?
> 
> On a related note, is there a list of boards anywhere? I'm working on a 7760
> system at $DAYJOB, Rich has a landisk which according to
> https://www.openbsd.org/landisk.html is an SH7751R, and Sato-san says that
> QEMU's -r2d emulates that too? ("RTS7751R2Dplus is QEMU-SH4 target. So easy
> trying.")
> 
> What other boards do we need to covert to device tree? arch/sh/boards has 15 C
> files and 19 subdirectories, but I dunno the status of any of them...

I think asking "what we need to convert" is at least slightly
mis-framed. Once the basics for device tree support are in place
(basically patches 06-09), which boards are supported by device tree
is mostly a matter of (1) whether the hardware drivers you want to use
have bindings and use modern kernel interfaces, and (2) someone
writing the dts files.

Unless there's strong objection, I'd be happy with just doing a survey
of device drivers used on currently supported boards, making sure they
all nominally support device tree, then removing the old board file
framework and waiting to see user response. If we take this path it
should likely happen in a release not planned for LTS so there's time
to add appropriate driver fixes and dts files before the next LTS
release.

I don't mind holding off a little bit on removal of the legacy board
file support if it's hard to get enough hardware working right away
with device tree, but I do want to move towards getting rid of it as
soon as we can, since it's a large volume of code cutting into my
ability to have a good maintainer-level understanding of the arch/sh
tree and has a lot of crufty, unmaintained parallel infrastructure
duplicating stuff that can be done in cleaner and more modern ways
(see the threads on early platform device stuff, rtc drivers, etc.).

Rich