Re: regressions in linux-next?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Javier Martinez Canillas <javier@xxxxxxxxxxxx> [140424 09:33]:
> On Thu, Apr 24, 2014 at 5:42 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> > It really should not matter what the configuration data for the
> > drivers is. Both platform_data and DT data should be easily supported.
> 
> Yes, I think I expressed myself badly. I actually meant platforms that
> keep evolving vs platforms that nobody is active developing on them
> and is unlikely that will ever use the newer
> infrastructure/API/whatever that is added on the different subsystems.
> 
> In the GPIO OMAP driver example we have a lot of #ifdefery to separate
> OMAP1 and OMAP2+ code since OMAP1 does not support sparse IRQ (and
> probably never will) so it can't dynamically allocate IRQ numbers and
> I've seen similar things in other OMAP drivers.
> 
> But yes, the maintenance burden is not that much either, I was just
> thinking aloud if splitting these drivers would make sense or not.

OK. Doing the omap1 sparse IRQ conversion has been on my todo list
for quite a while. That should be quite easy to do. Sounds getting
rid of the ifdeffery in the shared drivers is a good reason to do it.

The tricky part with omap1 from multiarch point of view is the clock
framework conversion for multi arch support, at this rate it will be
years before we get there :)

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux