[1] https://gcdnb.pbrd.co/images/0a1zYBFZXZVb.png > > I am not a big fan of describing register bits in DT, +1 > but for the other > SYSC users you list above, syscon+regmap seems to be a valid solution. > For USB and PCIe control, the situation is different. I more liked the > approach with "reset IDs" you had in v1, as it abstracts the DT > description from the register bits, +1 > and the USB and PCIe reset bits use > a different polarity (on RZ/G3S). If future SoC integration changes > the polarity, you have to handle that in the consumer (USB or PCIe) > driver, too. That's true. The idea of this implementation was that the consumer would know what they need to set for themselves on the SYSC side. > Unfortunately such "reset IDs" are only suitable for > use with the reset or pmdomain frameworks, which didn't survive the > earlier discussions. > > One other option would be to let SYSC expose regulators? We can try, but we can hit the wall again, as the PWRRDY signal is not a regulator either. From the internal HW discussion is an indicator (software controlled) that the power to the USB PHY is ready. > While that would work for USB and PCIe control, we would still need > syscon+regmap for the other bits. That is true. > > So the more I think about it, the more I like your (clever) solution... > >> Along with it, add the syscon to the compatible list as it will be >> requested by the consumer drivers. The syscon was added to the rest of >> system controller variants as these are similar with RZ/G3S and can >> benefit from the implementation proposed in this series. >> >> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@xxxxxxxxxxxxxx> > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
