linux-kernel - Re: [PATCH 1/4] thermal: uniphier: add UniPhier thermal 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]

Message-ID: <CAK7LNARtQfhx+854FHZenymX4Em4LYWSWUsH2iPp4fb9D7xXHA@mail.gmail.com>
Date:   Mon, 5 Jun 2017 17:42:28 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Kunihiko Hayashi <hayashi.kunihiko@...ionext.com>
Cc:     Eduardo Valentin <edubezval@...il.com>, rui.zhang@...el.com,
        linux-pm@...r.kernel.org,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        devicetree@...r.kernel.org, masami.hiramatsu@...aro.org,
        Jassi Brar <jaswinder.singh@...aro.org>
Subject: Re: [PATCH 1/4] thermal: uniphier: add UniPhier thermal driver

2017-05-30 18:21 GMT+09:00 Kunihiko Hayashi <hayashi.kunihiko@...ionext.com>:

>> > +static const struct uniphier_tm_soc_data uniphier_pxs2_tm_data = {
>> > +   .map_base        = 0xe000,
>> > +   .block_base      = 0xe000,
>> > +   .tmod_setup_addr = 0xe904,
>> > +};
>> > +
>> > +static const struct uniphier_tm_soc_data uniphier_ld20_tm_data = {
>> > +   .map_base        = 0xe000,
>> > +   .block_base      = 0xe800,
>> > +   .tmod_setup_addr = 0xe938,
>>
>> Shouldn't these be in your device tree using the register properties?
>> I see at least the map base as possible to be done in DT.

True for simple-bus.

However, the combination of "simple-mfd" and "syscon"
seems a well established strategy when
registers are mixed/interleaved in a syscon block.

(For example, chip-control@...000 node of
arch/arm/boot/dts/berlin2.dtsi)


> I think so.
> However, the iomap of this device are included in sysctrl(simple-mfd),
> and I can't find the method to express offset from base-address of sysctrl
> on DT, instead of map_base, in resonable way.
>
> I think that mfd node has register property then the lower node of mfd,
> that is the thermal node, can't have register property.
>
> If the driver gets offset address from DT, I'll define new property
> like 'socionext,reg_offset' in the thermal node. But I'm not sure that.

socionext,uniphier-{pxs2,ld20}-thermal is an SoC-specific compatible string.
The internal-offset is included
in the HW-spec associated with the compatible.
I believe 'socionext,reg_offset' is pointless.


-- 
Best Regards
Masahiro Yamada