Replying to myself, because I may or may not like having conversations
with myself :)

On Thu, Mar 19, 2015 at 10:36:40AM -0700, Brian Norris wrote:

On Thu, Mar 19, 2015 at 06:02:16PM +0100, Hans de Goede wrote:

quoted

On 19-03-15 16:53, Brian Norris wrote:

quoted

On Thu, Mar 19, 2015 at 12:10:25PM +0100, Hans de Goede wrote:

quoted

On 19-03-15 02:23, Brian Norris wrote:

quoted

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
---
Light dependency on:
  http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/331921.html
for the surrounding text.

 arch/arm/boot/dts/bcm7445.dtsi | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/bcm7445.dtsi b/arch/arm/boot/dts/bcm7445.dtsi
index 9eaeac8dce1b..7a7c4d8c2afe 100644
--- a/arch/arm/boot/dts/bcm7445.dtsi
+++ b/arch/arm/boot/dts/bcm7445.dtsi

@@ -108,6 +108,42 @@
 			brcm,int-map-mask = <0x25c>, <0x7000000>;
 			brcm,int-fwd-mask = <0x70000>;
 		};
+
+		sata at f045a000 {
+			compatible = "brcm,bcm7445-ahci", "brcm,sata3-ahci";
+			reg-names = "ahci", "top-ctrl";
+			reg = <0x45a000 0xa9c>, <0x458040 0x24>;

Why not simply drop the second register range here, and the minimal top-ctrl
poking you need in the phy driver's phy_init function ?

I agree it's a little ugly, but your recommended solution will not work.

The 'top-ctrl' register range includes several SATA functionalities,
some of which are required for the PHY and some of which are definitely
required for the SATA driver.

I see, but the phy driver is required for the SATA driver anyways,
and since the BUS_CTRL setting seems to be static it might just as
well be set by the phy driver. The phy driver also poking some
common sata glue bits like this busctrl register is not unheard of,
esp. when these glue bits are in the phy register range.

I realized I *do* still have some reservations about moving the
SATA_TOP_CTRL register range under the PHY DT binding; it's because all
arguments for it seem to rest on descriptions of how the software would
*like* to handle it. It's not at all about describing the hardware
correctly.

I still see SATA_TOP_CTRL as a register resource that belongs to the
SATA controller, not to the PHY. It just happens that it has a few
registers in it that are also for use in the PHY.

So, to best describe the *hardware*, it seems we might split top-ctrl
into 3 portions, where the middle gets assigned to a phy description,
and the first and last belong to the SATA controller description.

But to most easily describe how *software* would best handle them, we
might stick all the custom stuff (i.e., all of top-ctrl + phy) into the
PHY description.

I still think that, practically speaking, the latter should work just
fine, and it's only a theoretical concern that suggests the former.

Thoughts?

quoted

quoted

We have:

0x00   VERSION
0x04   BUS_CTRL
0x08   TP_CTRL
0x0C   PHY_CTRL_1
0x10   PHY_CTRL_2
0x14   PHY_CTRL_3
0x18   PHY_CTRL_4
0x1C   TP_OUT
0x20   CLIENT_INIT_CTRL

[snip rest]

Brian