[Bug 285054] Cubieboard broken by 9ddd516b886218af809dbf40eeda1ed388e2879c

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285054

            Bug ID: 285054
           Summary: Cubieboard broken by
                    9ddd516b886218af809dbf40eeda1ed388e2879c
           Product: Base System
           Version: 15.0-CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: [email protected]
          Reporter: [email protected]

Created attachment 257998
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=257998&action=edit
fix-and-debug-a10.patch

Hi,

Commit 9ddd516b886218af809dbf40eeda1ed388e2879c] riscv: enable allwinner RTC
broke support for the cubieboard:

...
openfirm: <Open Firmware control device>
sound_global_init: snd_unit=-1 snd_maxautovchans=16 latency=2 feeder_rate_min=1
feeder_rate_max=2016000 feeder_rate_round=25
crypto: <crypto core>
ofwbus0: <Open Firmware Device Tree>
ofw_clkbus0: <OFW clocks bus> on ofwbus0
clk_fixed0: <Fixed clock> on ofw_clkbus0
Clock: osc24M, parent: none, freq: 24000000
clk_fixed1: <Fixed clock> on ofw_clkbus0
Clock: osc32k, parent: none, freq: 32768
simplebus0: <Flattened device tree simple bus> on ofwbus0
regfix0: <Fixed Regulator> on ofwbus0
regfix1: <Fixed Regulator> on ofwbus0
regfix2: <Fixed Regulator> on ofwbus0
regfix3: <Fixed Regulator> on ofwbus0
regfix4: <Fixed Regulator> on ofwbus0
regfix5: <Fixed Regulator> on ofwbus0
rtc0: <Allwinner RTC> mem 0x1c20d00-0x1c20d1f irq 32 on simplebus0
rtc0: Using internal oscillator
panic: Duplicated clock registration: osc32k
...

Previous to this commit, the aw_rtc driver did not try to register
clocks, as the fdt rtc node for the A10 does not have
the "clock-output-names" property (sun4i-a10.dtsi).
Same for sun7i-a20.dtsi.
I can confirm this hypothesis with the patch attached.

The mentioned commit made the aw_rtc driver disregard the absence of
"clock-output-names" to always register some clocks, because the riscv
board that this commit is made to support doesn't have such property
defined and because, according to the commit message, it is fine to
hardcode that behaviour because all the device supported do have
the property (until a new one comes...).

The logic of that seems wrong to me, because it hardcodes a behaviour assuming
that the FDT may be wrong. And maybe a future board might do it like the
a10/a20 did ?

Would be possible to support the sun20i riscv in another way and to restore
support for the A10/A20?

Like maybe instead do, either:
- special casing the behaviour change only for the intended boards having a bad
fdt/dts
- or fixing the dts file
- or special-casing the a10/a20 cases (seems wrong since their dts were
fine...)
- or something else

Please let me know if I can help.


Thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.