On Mon, Mar 4, 2024 at 1:50 PM Curtis Malainey <cujomalainey@xxxxxxxxxx> wrote: > > On Mon, Mar 4, 2024 at 1:23 PM Mark Brown <broonie@xxxxxxxxxx> wrote: > > > > On Mon, Mar 04, 2024 at 01:14:43PM -0800, cujomalainey@xxxxxxxxxxxx wrote: > > > > > No problem, I can clean it up, I figured a good starting point would > be to just revive the original that was sent in 2018 > https://mailman.alsa-project.org/hyperkitty/list/alsa-devel@xxxxxxxxxxxxxxxx/message/26IVUCF7KMKNL7LZWAWWNFF3KB2TURSA/ > > We have been carrying this in our tree the whole time, just caught it > and figure I would try and get it up stream again So after a bunch of debugging on our 5.10 kernel it actually appears this property is useless and the system is already attaching the mclk under the clock defined in the property. Maybe someone pushed a coreboot update to fix this later which rendered this patch useless? > > > > > > > Having a firmware property for this is obviously broken for DT systems, > > this should be limited to ACPI systems if it's going to be there at all. > > It would be nicer if it were implementeded by having some ACPI specific > > code link whatever the configured clock name is to "mclk" - I don't know > > if the clock API has an equivalent to regulator_register_supply_alias() > > but that's the sort of thing I'm thinking of. > > I will take a look at this, note that it appears the original author > is no longer at AMD as the emails are bouncing. To answer this for the sake of sharing knowledge, there is a clk_add_alias API.
