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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <775bc754-0181-6a13-d625-825bf601eb77@landley.net>
Date:   Mon, 7 May 2018 10:13:32 -0500
From:   Rob Landley <rob@...dley.net>
To:     Rich Felker <dalias@...c.org>
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 05/07/2018 09:43 AM, Rich Felker wrote:
> 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.

(3) being able to test the result on real hardware.

We can _add_ device tree support without that, but can we remove the old board
files without it?

> 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.).

The process may include a deprecation of hardware nobody has anymore, with call
for testers, for a year or so before deleting stuff. (And then the old stuff's
in git if somebody finds a board and wants to fish it out.)

Also, I'd really like QEMU support to act as a first class board. At least 256
megs of ram (so you can do native compiles on it), serial support that works
(enabling the FIFO broke it because they don't implement the '15 bits of silence
triggers a flush timer' part, so data gets stranded in the buffer until enough
comes in to fill it the rest of the way which is a pain to type at when it's a
serial console), multiple hard drives, and so on.

I'd be fine with virtio but there's no virtio devices on that target I've
noticed yet, although maybe I just haven't figured out how to enable it...

> Rich

Rob