Re: [PATCH 1/4] thermal: uniphier: add UniPhier thermal driver

[Masahiro Yamada]

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

>> > +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@ea0000 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