On Sun, Apr 19, 2009 at 4:01 PM, Eric Miao <eric.y.miao@xxxxxxxxx> wrote: > On Fri, Apr 17, 2009 at 6:22 PM, Mark Brown <broonie@xxxxxxxxxxxxx> wrote: >> On Fri, Apr 17, 2009 at 11:39:38AM +0200, Philipp Zabel wrote: >> >>> To me, using ssp_dev seems to be cleaner, as all the places where >>> ssp_set_scr is called, we already have an ssp_dev *ssp = priv->dev.ssp >>> set up, which allows us to call ssp_set_scr(ssp, ...) instead of >>> ssp_set_scr(&priv->dev, ...). Same for ssp_get_scr. >> >> Yeah, the combination of ssp_dev and ssp_device is icky in general and >> largely historical as a result of a partially done transition of the >> driver to ssp_device. >> > > I'm working on that clean up. A lot of historical and dependency issues > indeed. Glad to hear that. I think once SSP is cleaned up, the single USB gadget controller driver is the only problem left for kernels supporting both PXA25x/27x at the same time. > And the patch looks OK. The condition of cpu_is_pxa25x() might not > be necessary though, ssp->type == PXA25x_SSP already implies that > and is more specific. Thanks. The idea was that the compiler can remove the PXA25x_SSP branch for kernels without PXA25x support this way. I guess the savings are negligible here, but it shouldn't hurt PXA25x-only kernels either. regards Philipp _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
