On Sat, 16 Feb 2019 21:47:13 +0100 Harald Geyer <harald@xxxxxxxxx> wrote: > Torsten Duwe writes: > > I consider the whole console > > mux GPIO an U-Boot hack, and would put it into > > sun50i-a64-teres-i-u-boot.dtsi. (As a LED, see above :-) > > The thing is, one of the quite strict rules in kernel development is: > Never break userspace. That means: If we provide a way to userspace to > do something (ie switch between debug and audio), we are expected to > keep it around forever. No, that rule applies to mechanisms, not configuration. It's not a problem if a device disappears completely, especially when it's optional. For clarity's sake, imagine to drop a .dtbo on the fdt that disables or removes it, after U-Boot has set it. > > Would you care to submit a patch version without that GPIO handled? > > I think it's very useful and has the potential to be agreed upon. > > That would enable audio from the internal speakers but select debug > output on the HP jack by default. The kernel driver will use whatever the boot preset is; and a production U-Boot should set that to audio. > I would be okay with that, despite > still thinking that audio on the head phones should be the default. Yes, for production use. For kernel debugging, hack it in U-Boot. The audio driver should be the last to care. Imagine you are debugging a boot problem on the serial console and all of a sudden it stops working just because the audio driver kicks in! Should any driver ever be in control of that GPIO, it must not be audio, IMO. Torsten
