linux-kernel - Re: [PATCH 2/2] ARM: bus: da8xx-mstpri: new driver

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]

Date:   Mon, 31 Oct 2016 16:01:09 +0530
From:   Sekhar Nori <nsekhar@...com>
To:     Bartosz Golaszewski <bgolaszewski@...libre.com>
CC:     Rob Herring <robh@...nel.org>, Kevin Hilman <khilman@...libre.com>,
        Michael Turquette <mturquette@...libre.com>,
        Frank Rowand <frowand.list@...il.com>,
        Mark Rutland <mark.rutland@....com>,
        Peter Ujfalusi <peter.ujfalusi@...com>,
        Russell King <linux@...linux.org.uk>,
        LKML <linux-kernel@...r.kernel.org>,
        arm-soc <linux-arm-kernel@...ts.infradead.org>,
        linux-drm <dri-devel@...ts.freedesktop.org>,
        linux-devicetree <devicetree@...r.kernel.org>,
        Jyri Sarha <jsarha@...com>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        David Airlie <airlied@...ux.ie>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>
Subject: Re: [PATCH 2/2] ARM: bus: da8xx-mstpri: new driver

On Monday 31 October 2016 03:24 PM, Bartosz Golaszewski wrote:
> 2016-10-31 10:52 GMT+01:00 Sekhar Nori <nsekhar@...com>:
>> Hi Bartosz,
>>
>> On Monday 31 October 2016 03:10 PM, Bartosz Golaszewski wrote:
>>> 2016-10-31 5:30 GMT+01:00 Rob Herring <robh@...nel.org>:
>>>> On Wed, Oct 26, 2016 at 07:35:55PM +0200, Bartosz Golaszewski wrote:
>>>>> Create the driver for the da8xx master peripheral priority
>>>>> configuration and implement support for writing to the three
>>>>> Master Priority registers on da850 SoCs.
>>>>>
>>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@...libre.com>
>>>>> ---
>>>>>  .../devicetree/bindings/bus/ti,da850-mstpri.txt    |  20 ++
>>>>>  drivers/bus/Kconfig                                |   9 +
>>>>>  drivers/bus/Makefile                               |   2 +
>>>>>  drivers/bus/da8xx-mstpri.c                         | 266 +++++++++++++++++++++
>>>>>  4 files changed, 297 insertions(+)
>>>>>  create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>>>  create mode 100644 drivers/bus/da8xx-mstpri.c
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>>> new file mode 100644
>>>>> index 0000000..225af09
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
>>>>> @@ -0,0 +1,20 @@
>>>>> +* Device tree bindings for Texas Instruments da8xx master peripheral
>>>>> +  priority driver
>>>>> +
>>>>> +DA8XX SoCs feature a set of registers allowing to change the priority of all
>>>>> +peripherals classified as masters.
>>>>> +
>>>>> +Documentation:
>>>>> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
>>>>> +
>>>>> +Required properties:
>>>>> +
>>>>> +- compatible:                "ti,da850-mstpri", "syscon" - for da850 based boards
>>>>
>>>> Drop syscon. Doesn't look like it is needed and the example doesn't
>>>> match.
>>>
>>> Hi Rob,
>>>
>>> it is needed: syscon_regmap_lookup_by_compatible() fails without it. I
>>> fixed the example instead.
>>
>> Why are master priority registers under syscon? This driver should be
>> the only entity touching them. So do we need an MFD driver?
>>
> 
> It should, but syscfg0 registers are mapped all over the place. I

Not sure what you mean by this. Yes, the sysconfig module has many
functionalities. But the registers for a given functionality are all
grouped together AFAICS (except CHIPCFGn, see below).

Pinmux registers are part of syscfg module, but don't use syscon.

In the work going on for OHCI support, chipcfg registers are being put
under a syscon node. But that makes sense, I think, because chipcfg
registers are catering to really diverse functionality like PLL and EDMA
related stuff being placed in the same register - CHIPCFG0.

> thought it would be safer to put them under syscon and Kevin agreed.

Before using syscon for the whole syscfg space, I think we need some
analysis as to where the likely races are going to be.

Thanks,
Sekhar