Re: [PATCH 2/2] Changes to existing files for 0PF FPGA board.

From: Rob Landley
Date: Sat Jun 20 2015 - 16:13:41 EST

On 06/20/2015 03:00 AM, Geert Uytterhoeven wrote:
> Hi Rob,
> On Sat, Jun 20, 2015 at 12:11 AM, Rob Landley <rob@xxxxxxxxxxx> wrote:
>> On 06/18/2015 02:36 PM, Geert Uytterhoeven wrote:
>>> On Thu, Jun 18, 2015 at 7:19 PM, Rob Landley <rob@xxxxxxxxxxx> wrote:
>>>> Changes to existing files to add 0pf j2 board support.
>>> Thanks for your patch!
>>> Like Greg already said, splitting it up in logical parts and providing useful
>>> patch descriptions would be highly appreciated.
>> I actually don't know how to split it up further. The initial port was
>> done by a series of contractors (in Russia, I think), and then I
>> inherited it to try to get something releasable. This is the smallest
>> chunk I could get to actually boot.
>> I suppose I could send you the serial driver by itself, and _then_ the
>> board, but it wouldn't compile if nothing uses it. (Similarly you can't
>> boot the board without a serial console...)
> You don't have to send in a big initial patch that actually boots.
> For new architecture/SoC/board support, just split it in logical hunks,
> and submit it in some logical order that always builds.
> E.g.:
> - SoC core support (arch/sh/),
> - Board support (arch/sh/),
> - Drivers.
> The first two should go in through akpm (sh is orphaned),
> the rest through the individual subsystem maintainers.

I'm aware sh is orphaned
( I'm trying to do
something about that.

I'm not up to maintaining an architecture myself (after the thing I walked away from kernel stuff for most of a year,
as you can see I'm a bit out of practice), but I spoke to Yoshinori Sato
(who used to maintain sh2, and only dropped it when renesas discontinued
the hardware) and he said he might be interested in returning as a

(I note that I've been regression testing and fixing sh4 in my
aboriginal linux project for several years now, although it's been
quiescent enough on the kernel side the majority of my posts about it
seem to be qemu issues, from to . Dealing
with sh2 is new to me, but it's also my day job these days. :)

>> (Now the reason _I_ thought you'd reject it had more to do with not
>> having converted it to device tree yet, and things on that level. But I
> Sh is an existing supported architecture, so DT is not a hard requirement.

Yeah, but new board... And it's the right thing to do.

> If you would have waited until after the removal of sh, it would be much
> harder :-) (cfr. h8300, but Sato-san did a great job there, with DT, CCF, ...)

Indeed he did. We had lunch with him when I was in Japan a couple weeks ago.

I've got the references I need to do this, just... lots of shoveling on
a lot of fronts to do right now. (And I mentioned like 3 other things I
already know I need to fix in the 0/2 message.)

>> wanted to get it out there so people outside $DAYJOB can test the
>> hardware. We did a linuxcon japan presentation which covered,
>> and we're getting pokes about "where can I download this", so...)
> It's great to hear there's so much interest in this! Let's hope this will
> attract more actual contributors...

The "where can I download this" is now the developer tab of by
the way. And the mailing lists are on

I'll try to submit an updated patch set in the next couple days.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at