On Fri, 29 Jul 2016 18:07:02 +0200, Vinod Koul wrote: > > On Fri, Jul 29, 2016 at 11:07:49AM +0200, Lars-Peter Clausen wrote: > > On 07/29/2016 02:30 AM, Takashi Sakamoto wrote: > > > Lars, > > > > > > On Jul 29 2016 05:33, Lars-Peter Clausen wrote: > > >> Hotplug is something that always pops up sooner or later. E.g. if someone > > >> puts a ASoC supported CODEC on a hot-pluggable device (maybe USB) we > > >> don't want to duplicate the code, but be able to reuse. > > > > > > (A bit to sidetrack) > > > > > > To me, it's unclear for devices on USB. When ALSA SoC part supports these > > > devices, what is the scenario you assumed? In short, assuming we put codes > > > to ALSA SoC part, what is the shape of the corresponding devices and links > > > of pairs of endpoints? Additionally, in this case, what codes are able to be > > > reused? > > > > Lets say you have USB stick with a small micro controller or FPGA which has > > a USB interface on one side and a I2S and I2C interface on the other side. > > The I2S and I2C are connected to a CODEC. I2S for data, I2C for control. If > > the interface is implemented in a way so that it is just a simple USB to I2C > > bridge, this means the raw I2C commands are send over the USB interface you > > can implement a I2C adapter driver for this bridge. If you have that you can > > instantiate the existing ASoC CODEC driver, which is a I2C device driver, on > > the bus registered by the adapter. > > That still seems a bit fancy hardware :) > > If we can reasonably support this, I am for it. But not making stuff > overtly complex... Yes, we don't have to overreact to a dream immediately now. We should consider whether it can be shifted to the card-level instead before worrying too much about hot-unplug of an ASoC component. Then the whole story becomes far easier. And, the suppress_bind_attrs flag I suggested is only to suppress the sysfs bind/unbind, and doesn't mean to prohibit hotplug itself via the bus driver. Takashi
