linux-kernel - Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for obtaining mode pin state

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: <20161031081923.GF18195@verge.net.au>
Date:   Mon, 31 Oct 2016 09:19:24 +0100
From:   Simon Horman <horms@...ge.net.au>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Magnus Damm <magnus.damm@...il.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 00/23] soc: renesas: Add R-Car RST driver for
 obtaining mode pin state

On Wed, Oct 26, 2016 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
> Hi Mike, Stephen,
> 
> On Fri, Oct 21, 2016 at 3:17 PM, Geert Uytterhoeven
> <geert+renesas@...der.be> wrote:
> > Currently the R-Car Clock Pulse Generator (CPG) drivers obtains the
> > state of the mode pins either by a call from the platform code, or
> > directly by using a hardcoded register access. This is a bit messy, and
> > creates a dependency between driver and platform code.
> >
> > This patch series converts the various Renesas R-Car clock drivers
> > and support code from reading the mode pin states using a hardcoded
> > register access to using a new minimalistic R-Car RST driver.
> >
> > All R-Car clock drivers will rely on the presence in DT of a device node
> > for the RST module.  Backwards compatibility with old DTBs is retained
> > only for R-Car Gen2, which has fallback code using its own private copy
> > of rcar_gen2_read_mode_pins().
> >
> > After this, there is still one remaining user of
> > rcar_gen2_read_mode_pins() left in platform code. A patch series to
> > remove that user has already been posted, though ("[PATCH/RFT 0/4] ARM:
> > shmobile: R-Car Gen2: Allow booting secondary CPU cores in debug mode").
> > Since v3, the other user has been removed in commit 9f5ce39ddb8f68b3
> > ("ARM: shmobile: rcar-gen2: Obtain extal frequency from DT").
> >
> > This series consists of 5 parts:
> >   A. Patches 1 and 2 add DT bindings and driver code for the R-Car RST
> >      driver,
> >   B. Patches 3-11 add device nodes for the RST modules to the R-Car DTS
> >      files,
> >   C. Patches 12-17 convert the clock drivers to call into the new R-Car
> >      RST driver,
> >   D. Patches 18-20 remove passing mode pin state to the clock drivers
> >      from the platform code,
> >   E. Patches 21-23 remove dead code from the clock drivers.
> >
> > As is usually the case with moving functionality from platform code to
> > DT, there are lots of hard dependencies:
> >   - The DT updates in Part B can be merged as soon as the DT bindings in
> >     Part A have been approved,
> >   - The clock driver updates in Part C depend functionally on the driver
> >     code in Part A, and on the DT updates in Part B,
> >   - The board code cleanups in Part D depend on the clock driver updates
> >     in Part C,
> >   - The block driver cleanups in part E depend on the board code
> >     cleanups in part D.
> >
> > Hence to maintain the required lockstep between SoC driver, clock
> > drivers, shmobile platform code, and shmobile DT, I propose to queue up
> > all patches in a single branch against v4.9-rc1, and send pull requests
> > to both Mike/Stephen (clock) and Simon (rest).
> >
> > ***
> 
> >   - Mike/Stephen/Simon/Magnus: Are you OK with the suggested merge
> >     approach above?
> 
> Is this OK for you?
> 
> I'd like to move forward with this, as this is a prerequisite for adding
> support for new SoCs (RZ/G) without adding more copies of
> rcar_gen2_read_mode_pins(), and removing that function from platform code
> for good.

This seems reasonable to me but likely the ARM SoC maintainers will want to
know about this plan before it is executed.