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
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
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
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 =
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 =
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
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
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
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
>
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
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
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
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
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
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
>>
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
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
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
>
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
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
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
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
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
> 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
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
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
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
> 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
28 matches
Mail list logo