Re: Grafting old platform drivers onto a new DT kernel

2016-02-03 Thread Sebastian Frias
Hi Marc, Marc Zyngier arm.com> writes: > > Both ethernet and sdhci driver call platform_get_irq(pdev, 0); > > but the eth driver is DT, so calls of_irq_get() while sdhci is > > legacy, so calls platform_get_resource() -- IIUC. > > > > How do I specify a "hwirq" instead of a "Linux index"? and

Re: Grafting old platform drivers onto a new DT kernel

2016-02-03 Thread Sebastian Frias
Hi Marc, Marc Zyngier arm.com> writes: > > Both ethernet and sdhci driver call platform_get_irq(pdev, 0); > > but the eth driver is DT, so calls of_irq_get() while sdhci is > > legacy, so calls platform_get_resource() -- IIUC. > > > > How do I specify a "hwirq" instead of a "Linux index"? and

Re: Grafting old platform drivers onto a new DT kernel

2015-11-10 Thread Arnd Bergmann
On Tuesday 10 November 2015 13:44:48 Mason wrote: > On 09/11/2015 18:13, Måns Rullgård wrote: > > > Add something like this: > > > > static const struct of_device_id tangox_sdio_dt_ids[] = { > > { .compatible = "sigma,tangox-sdio" }, > > { } > > }; > > > > static struct

Re: Grafting old platform drivers onto a new DT kernel

2015-11-10 Thread Mason
On 09/11/2015 18:13, Måns Rullgård wrote: > Add something like this: > > static const struct of_device_id tangox_sdio_dt_ids[] = { > { .compatible = "sigma,tangox-sdio" }, > { } > }; > > static struct platform_driver tangox_platform_sdio0 = { > .probe =

Re: Grafting old platform drivers onto a new DT kernel

2015-11-10 Thread Mason
On 09/11/2015 18:13, Måns Rullgård wrote: > Add something like this: > > static const struct of_device_id tangox_sdio_dt_ids[] = { > { .compatible = "sigma,tangox-sdio" }, > { } > }; > > static struct platform_driver tangox_platform_sdio0 = { > .probe =

Re: Grafting old platform drivers onto a new DT kernel

2015-11-10 Thread Arnd Bergmann
On Tuesday 10 November 2015 13:44:48 Mason wrote: > On 09/11/2015 18:13, Måns Rullgård wrote: > > > Add something like this: > > > > static const struct of_device_id tangox_sdio_dt_ids[] = { > > { .compatible = "sigma,tangox-sdio" }, > > { } > > }; > > > > static struct

Re: Grafting old platform drivers onto a new DT kernel

2015-11-09 Thread Måns Rullgård
Mason writes: > On 09/11/2015 17:12, Måns Rullgård wrote: > >> Mason writes: >> >>> On 09/11/2015 16:40, Måns Rullgård wrote: >>> The simplest solution for you is probably to add a quick and dirty DT binding to the old driver. If it doesn't use any driver-specific platform data

Re: Grafting old platform drivers onto a new DT kernel

2015-11-09 Thread Mason
On 09/11/2015 17:12, Måns Rullgård wrote: > Mason writes: > >> On 09/11/2015 16:40, Måns Rullgård wrote: >> >>> The simplest solution for you is probably to add a quick and dirty DT >>> binding to the old driver. If it doesn't use any driver-specific >>> platform data struct, you only need to

Re: Grafting old platform drivers onto a new DT kernel

2015-11-09 Thread Russell King - ARM Linux
On Mon, Nov 09, 2015 at 04:15:03PM +0100, Mason wrote: > I tried compiling an ancient SDHCI driver on a v4.2 system. It crashes > all over init because several host->ops functions are required, but the > old driver does not define them: > .reset > .set_clock > .set_bus_width > .set_uhs_signaling >

Re: Grafting old platform drivers onto a new DT kernel

2015-11-09 Thread Måns Rullgård
Mason writes: > On 09/11/2015 16:40, Måns Rullgård wrote: > >> The simplest solution for you is probably to add a quick and dirty DT >> binding to the old driver. If it doesn't use any driver-specific >> platform data struct, you only need to set .of_match_table in the >> struct

Re: Grafting old platform drivers onto a new DT kernel

2015-11-09 Thread Mason
On 09/11/2015 16:40, Måns Rullgård wrote: > The simplest solution for you is probably to add a quick and dirty DT > binding to the old driver. If it doesn't use any driver-specific > platform data struct, you only need to set .of_match_table in the > struct platform_driver. If there is a

Re: Grafting old platform drivers onto a new DT kernel

2015-11-09 Thread Måns Rullgård
Mason writes: > On 05/11/2015 16:42, Javier Martinez Canillas wrote: >> Hello, >> >> On Thu, Nov 5, 2015 at 12:15 PM, Andrew Lunn wrote: Since I don't have time to rewrite the drivers at the moment, I'm wondering if it's possible to "graft" old drivers (they're using the platform

Re: Grafting old platform drivers onto a new DT kernel

2015-11-09 Thread Marc Zyngier
On 09/11/15 15:15, Mason wrote: > On 05/11/2015 16:42, Javier Martinez Canillas wrote: >> Hello, >> >> On Thu, Nov 5, 2015 at 12:15 PM, Andrew Lunn wrote: Since I don't have time to rewrite the drivers at the moment, I'm wondering if it's possible to "graft" old drivers (they're using

Re: Grafting old platform drivers onto a new DT kernel

2015-11-09 Thread Mason
On 05/11/2015 16:42, Javier Martinez Canillas wrote: > Hello, > > On Thu, Nov 5, 2015 at 12:15 PM, Andrew Lunn wrote: >>> Since I don't have time to rewrite the drivers at the moment, I'm wondering >>> if it's possible to "graft" old drivers (they're using the platform API, no >>> trace of DT

Re: Grafting old platform drivers onto a new DT kernel

2015-11-09 Thread Måns Rullgård
Mason writes: > On 09/11/2015 16:40, Måns Rullgård wrote: > >> The simplest solution for you is probably to add a quick and dirty DT >> binding to the old driver. If it doesn't use any driver-specific >> platform data struct, you only need to set .of_match_table in the >>

Re: Grafting old platform drivers onto a new DT kernel

2015-11-09 Thread Måns Rullgård
Mason writes: > On 05/11/2015 16:42, Javier Martinez Canillas wrote: >> Hello, >> >> On Thu, Nov 5, 2015 at 12:15 PM, Andrew Lunn wrote: Since I don't have time to rewrite the drivers at the moment, I'm wondering if it's possible to "graft" old

Re: Grafting old platform drivers onto a new DT kernel

2015-11-09 Thread Mason
On 05/11/2015 16:42, Javier Martinez Canillas wrote: > Hello, > > On Thu, Nov 5, 2015 at 12:15 PM, Andrew Lunn wrote: >>> Since I don't have time to rewrite the drivers at the moment, I'm wondering >>> if it's possible to "graft" old drivers (they're using the platform API, no

Re: Grafting old platform drivers onto a new DT kernel

2015-11-09 Thread Russell King - ARM Linux
On Mon, Nov 09, 2015 at 04:15:03PM +0100, Mason wrote: > I tried compiling an ancient SDHCI driver on a v4.2 system. It crashes > all over init because several host->ops functions are required, but the > old driver does not define them: > .reset > .set_clock > .set_bus_width > .set_uhs_signaling >

Re: Grafting old platform drivers onto a new DT kernel

2015-11-09 Thread Mason
On 09/11/2015 17:12, Måns Rullgård wrote: > Mason writes: > >> On 09/11/2015 16:40, Måns Rullgård wrote: >> >>> The simplest solution for you is probably to add a quick and dirty DT >>> binding to the old driver. If it doesn't use any driver-specific >>> platform data struct, you only need to

Re: Grafting old platform drivers onto a new DT kernel

2015-11-09 Thread Marc Zyngier
On 09/11/15 15:15, Mason wrote: > On 05/11/2015 16:42, Javier Martinez Canillas wrote: >> Hello, >> >> On Thu, Nov 5, 2015 at 12:15 PM, Andrew Lunn wrote: Since I don't have time to rewrite the drivers at the moment, I'm wondering if it's possible to "graft" old drivers

Re: Grafting old platform drivers onto a new DT kernel

2015-11-09 Thread Mason
On 09/11/2015 16:40, Måns Rullgård wrote: > The simplest solution for you is probably to add a quick and dirty DT > binding to the old driver. If it doesn't use any driver-specific > platform data struct, you only need to set .of_match_table in the > struct platform_driver. If there is a

Re: Grafting old platform drivers onto a new DT kernel

2015-11-09 Thread Måns Rullgård
Mason writes: > On 09/11/2015 17:12, Måns Rullgård wrote: > >> Mason writes: >> >>> On 09/11/2015 16:40, Måns Rullgård wrote: >>> The simplest solution for you is probably to add a quick and dirty DT binding to the old driver. If it doesn't use any driver-specific

Re: Grafting old platform drivers onto a new DT kernel

2015-11-05 Thread Javier Martinez Canillas
Hello, On Thu, Nov 5, 2015 at 12:15 PM, Andrew Lunn wrote: >> Since I don't have time to rewrite the drivers at the moment, I'm wondering >> if it's possible to "graft" old drivers (they're using the platform API, no >> trace of DT support) onto my small base? > > Platform drivers are still

Re: Grafting old platform drivers onto a new DT kernel

2015-11-05 Thread Andrew Lunn
> Since I don't have time to rewrite the drivers at the moment, I'm wondering > if it's possible to "graft" old drivers (they're using the platform API, no > trace of DT support) onto my small base? Platform drivers are still usable with DT systems. We used that fact when converting platform

Grafting old platform drivers onto a new DT kernel

2015-11-05 Thread Mason
Hello, My company provides a 3.4 kernel for an ARM-based SoC (there's also a 2.6.32 stashed somewhere for customers refusing to upgrade) along with drivers of dubious quality written over the past decade. I was tasked to release a new kernel, and took the opportunity to perform a massive

Grafting old platform drivers onto a new DT kernel

2015-11-05 Thread Mason
Hello, My company provides a 3.4 kernel for an ARM-based SoC (there's also a 2.6.32 stashed somewhere for customers refusing to upgrade) along with drivers of dubious quality written over the past decade. I was tasked to release a new kernel, and took the opportunity to perform a massive

Re: Grafting old platform drivers onto a new DT kernel

2015-11-05 Thread Javier Martinez Canillas
Hello, On Thu, Nov 5, 2015 at 12:15 PM, Andrew Lunn wrote: >> Since I don't have time to rewrite the drivers at the moment, I'm wondering >> if it's possible to "graft" old drivers (they're using the platform API, no >> trace of DT support) onto my small base? > > Platform

Re: Grafting old platform drivers onto a new DT kernel

2015-11-05 Thread Andrew Lunn
> Since I don't have time to rewrite the drivers at the moment, I'm wondering > if it's possible to "graft" old drivers (they're using the platform API, no > trace of DT support) onto my small base? Platform drivers are still usable with DT systems. We used that fact when converting platform