2017-05-30 18:21 GMT+09:00 Kunihiko Hayashi [off-list ref]:

quoted

quoted

+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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html