lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 20 Oct 2009 12:51:06 +0100 From: Mark Brown <broonie@...nsource.wolfsonmicro.com> To: Peter Ujfalusi <peter.ujfalusi@...ia.com> Cc: "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>, "sameo@...ux.intel.com" <sameo@...ux.intel.com>, "tony@...mide.com" <tony@...mide.com> Subject: Re: [PATCH 4/4] ASoC: TWL4030: Driver registration via twl4030_codec MFD On Tue, Oct 20, 2009 at 02:30:49PM +0300, Peter Ujfalusi wrote: > In patch 1, the register definitions had to be added, so that the twl4030_codec > driver knows the registers (and there could be the vibra driver placed > separately from the soc codec driver). > In patch 3, where I modify the soc codec driver to use the new method, than I > remove the definitions and use the existing header file, introduced by the first > patch. > All in all, after each patch the kernel can be builds, boots and works as > before. Sure, though I suspect patch 3 could just be split in two happily with an include. I don't really mind either way. If you are going to keep them as one patch it'd be good to call out the move in the changelog. > > You've also got the bias being brought up when the ASoC system comes up > > rather than when the driver comes up. To be honest it doesn't really > > make any difference either way, it's just slightly different to other > > drivers. > I was thinking that if you built the kernel with SND_SOC_ALL_CODECS on OMAP > platform for some reason and you don't actually use the twl4030 as audio device > -> no machine driver, which would use it, than the codec part would be off. > But yes, probably I can move the povering up to the probe function. That's a good enough reason to leave things as they are, though really if you're building SND_SOC_ALL_CODECs in a production system you're being a bit strange. > > > +MODULE_ALIAS("platform:twl4030_codec:audio"); > > Is that second colon right given... > I'm not sure about it at all either. I did not found any other 'nested MFD' > drivers around, so this is just a guess > Should it be: > +MODULE_ALIAS("platform:twl4030_codec_audio"); Yes. The aliasing makes no reference to the parents of the device, it only cares about the device name - for the purposes of module loading and driver matching it's identical to any other platform device. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists