[PATCH v4 1/2] dt-bindings: sound: Add generic serial MIDI device

[Rob Herring]

On Mon, Apr 25, 2022 at 07:49:49PM -0500, Dan K wrote:
> On Mon, Apr 25, 2022 at 5:16 PM Rob Herring <robh at kernel.org> wrote:
> >
> > On Mon, Apr 25, 2022 at 02:16:02PM -0500, Daniel Kaehn wrote:
> > > Adds dt-binding for snd-serial-generic serial MIDI driver
> >
> > Bindings are for h/w and there's no such thing as generic h/w. There are
> > some exceptions but you'll have to justify why this is special.
> >
> 
> Thanks for taking the time to look at this!
> 
> Not entirely sure if you mean that I'll need to justify the existence
> / need for this binding,
> or the use of the term 'generic' -- just in case, I'll make sure to
> respond to both. Note that
> I'm justifying my reasoning for submitting the binding - but I'm
> uncertain myself if my reasoning
> is valid, as someone new to kernel development.

'Generic' is really just a red flag.

We've had generic or simple bindings before. The result tends to be a 
never ending stream of new properties to deal with every new variation 
in devices. These can be quirks for device behavior, timing for power 
control, etc.

> The intent of this binding is to signify that a serial port (namely a
> UART) is connected
> in hardware to a MIDI decoupling circuit, which then connects to some
> (any) sort of MIDI device,
> either directly to an on-board device, or via a jack/connector. In a
> sense, the MIDI device that this
> connects to is 'generic', as the identity of the device does not need
> to be known to interface with it
> over MIDI for most use cases.

Okay, maybe it is appropriate. The key part is 'most use cases'. What 
about ones that don't fit into 'most'? It's possible to do both (generic 
binding and device specific bindings), but we need to define when 
generic bindings are appropriate or not.

Do devices ever need power controls or other sideband interfaces? 
Regulators, resets, clocks? If so, you need to describe the specific 
device.

Is a jack/connector in any way standard and have signals other than UART 
(or whatever is the other side of the MIDI decoupling circuit)? We have 
bindings for standard connectors.

I don't really know anything about what this h/w looks like, so any 
pointers or examples would help. 

> I see how this is a bit of an oddball, since it's not specifically
> describing a particular hardware
> device attached to a UART (like some of the bluetooth modules are),

To follow that comparison, all/most BT modules use a standard/generic 
protocol over the serial port. But we don't have compatibles aligned to 
the protocol because the devices are more than just a serial protocol. 
They have GPIOs, regulators, clocks, etc. Furthermore, the serial 
protocols themselves can have extensions and/or quirks.


> but thought this sort of
> binding might be permissible because of things like the
> gpio-matrix-keypad binding, which doesn't
> describe specific switches, just how thoise switches are wired, and
> what GPIO they use, which is all
> that is needed to interface with them. Some MIDI devices implement
> extra low-level features like device
> multiplexing, but these aren't (to my knowledge) common, and are
> beyond what this supports.

At some point devices become simple enough to model generically.

> The reason that the corresponding driver written has the name
> 'generic' is for an entirely
> different reason. A "serial MIDI" driver already exists in the kernel,
> however, it  interfaces only with
> u16550-compatible UARTs. This driver uses the serial bus, making it
> work with 'generic' serial devices.

Bindings are separate from the kernel (though they live in the same 
repository for convenience). A 'generic' binding often appears with a 
'generic' driver. You can have specific bindings with a generic driver. 
The difference with doing that is the OS can evolve without changing the 
binding (an ABI). Maybe initially you use a generic driver until there's 
extra/custom features of the device you want to support with a custom 
driver.

Rob