Skip to content

musb: Add support for the Allwinner sunxi musb controller

Arnd Bergmann linux-arm-kernel linux-devicetree 1 version New

Get series with b4
b4 am 2227491.z0aBeXi5ZG@wuerfel

Versions newest first

  1. v1 Latest2 of 15 patches 0 repliesNew

2 of 15 patches are in this archive. The cover letter announces 15.

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
2/15phy-sun4i-usb: Add a helper function to update the iscr register+0 -011 replies
5/15musb: Do not use musb_read[b|w] / _write[b|w] wrappers in generic fifo functions+0 -04 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [PATCH 00/15] musb: Add support for the Allwinner sunxi musb controller
Quoted 4 lines · On Monday 09 March 2015 21:40:13 Hans de Goede wrote:

Hi All,

This patch set has been a while in the making, so I'm very happy to present the end result here, and I hope everyone likes it.

Awesome work!

Quoted 27 lines

Before talking about merging this there are 2 things which I would like to point out:

a) The musb controller in the sunxi SoCs uses some SRAM which needs to be mapped to the musb controller by poking some bits in the SRAM controller, just like the EMAC patches which were send a while back I've chosen to use syscon for this, actually 2 of the patches in this set come directly from the SRAM mapping patchset for the EMAC.

I know that Maxime is not 100% in favor of using syscon:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/320221.html

But I disagree with his arguments for writing a special driver for the SRAM controller:
1) syscon was specifically designed for global system control registers like this and is fine to use as long as there are no conflicts where 1 bit is of interest to multiple drivers, and there is no such conflict here
2) Maxime's other arguments seem to boil down to it would be nice / prettier to have a specific driver for this, without really proving a hard need for such a driver. But writing such a driver is going to be a lot of work, and we've a ton of other work to do, and as said there is no real need for a separate driver, syscon works fine for this.
3) I actually believe that having a specific driver for this is a bad idea, because that means inventing a whole new cross driver API for this, and getting those right is, hard, a lot of work, and even then one is still likely to get it wrong. We can avoid all this by going with the proven syscon solution.

Quoted 2 lines

Maxime, can we please have your ack for moving forward with this using syscon? (see above for my arguments why)

I'd like to understand here why we can't use the existing SRAM DT binding instead of the syscon binding.

Arnd