Re: [PATCH 1/2] firmware: include drivers/firmware/Kconfig unconditionally

On Tue, Sep 28, 2021 at 10:37 AM Charles Keepax
[off-list ref] wrote:

Thanks for looking at this for us. I don't think we are greatly
attached to drivers/firmware as a location. Essentially, what we
have is some firmware parsing code that needs to be shared across
several devices, previously this was just in the sound subsystem as
all our parts were audio. We are going to shortly be upstreaming
some non-audio parts that use the same firmware infrastructure
and it didn't seem very sensible to have them including bits of
the audio subsystem.

I guess the question might be where else would said code go?
drivers/firmware seemed most obvious, all the other locations
I can think of don't really make sense. Can't really put it a bus
like spi/i2c etc. because we have parts on many buses. Can't
really put it in a functional subsystem (audio/input etc.) since
the whole idea was to try and get some independence from that so
we don't have parts including subsystems they don't use. Could
maybe put it in MFD, but no hard guarantee every part using it
will be an MFD device and I am fairly confident Lee will feel it
isn't MFD code as it doesn't relate to managing multiple devices.
Only other option I can think of would be to make some sort of
drivers/dsp or maybe drivers/cs_dsp, but not clear to me that is
obviously better than using drivers/firmware.

Other DSPs use the drivers/remoteproc/ subsystem, but that
is more for general-purpose DSPs that can load application
specific firmware rather than loading a single firmware blob
as you'd normally do with the request_firmware() style interface.

Not sure if that fits what you do. Can you point to a high-level
description of what this DSP does besides audio, and how
flexible it is? That might help find the right place for this.

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel