On Tue, 08 Mar 2016, Kieran Bingham wrote:
> On 8 Mar 2016 11:22, "Lee Jones" wrote:
> >
> > On Mon, 12 Oct 2015, Kieran Bingham wrote:
> >
> > > Hi Wolfram,
> > >
> > > On 9 October 2015 at 22:16, Wolfram Sang wrote:
> > > >
> > > > As said to Kieran
On Tue, 08 Mar 2016, Kieran Bingham wrote:
> On 8 Mar 2016 11:22, "Lee Jones" wrote:
> >
> > On Mon, 12 Oct 2015, Kieran Bingham wrote:
> >
> > > Hi Wolfram,
> > >
> > > On 9 October 2015 at 22:16, Wolfram Sang wrote:
> > > >
> > > > As said to Kieran personally in Dublin, I want a verification
On Mon, 12 Oct 2015, Kieran Bingham wrote:
> Hi Wolfram,
>
> On 9 October 2015 at 22:16, Wolfram Sang wrote:
> >
> > As said to Kieran personally in Dublin, I want a verification that all
> > binding methods still work, especially runtime instantiation for drivers
> >
On Mon, 12 Oct 2015, Kieran Bingham wrote:
> Hi Wolfram,
>
> On 9 October 2015 at 22:16, Wolfram Sang wrote:
> >
> > As said to Kieran personally in Dublin, I want a verification that all
> > binding methods still work, especially runtime instantiation for drivers
> > without i2c_device_ids.
>
Hi Wolfram,
On 9 October 2015 at 22:16, Wolfram Sang wrote:
>
> As said to Kieran personally in Dublin, I want a verification that all
> binding methods still work, especially runtime instantiation for drivers
> without i2c_device_ids.
Ok, I should be able to find some time to look at that this
Hi Wolfram,
On 9 October 2015 at 22:16, Wolfram Sang wrote:
>
> As said to Kieran personally in Dublin, I want a verification that all
> binding methods still work, especially runtime instantiation for drivers
> without i2c_device_ids.
Ok, I should be able to find some time
As said to Kieran personally in Dublin, I want a verification that all
binding methods still work, especially runtime instantiation for drivers
without i2c_device_ids. Also, for the last patch, a verification should
be done if the drivers i2c_device_id hasn't been used meanwhile. I'd
also like to
As said to Kieran personally in Dublin, I want a verification that all
binding methods still work, especially runtime instantiation for drivers
without i2c_device_ids. Also, for the last patch, a verification should
be done if the drivers i2c_device_id hasn't been used meanwhile. I'd
also like to
On Thu, 01 Oct 2015, Wolfram Sang wrote:
>
> > > Yes but that is not true for drivers that support both OF and legacy board
> > > files. For those drivers, there will be a lot of boiler plate code
> > > duplicated
> > > that would look something like:
> > >
> > > unsigned long data;
> > >
On Thu, 01 Oct 2015, Wolfram Sang wrote:
>
> > > Yes but that is not true for drivers that support both OF and legacy board
> > > files. For those drivers, there will be a lot of boiler plate code
> > > duplicated
> > > that would look something like:
> > >
> > > unsigned long data;
> > >
Hi Wolfram,
On 1 October 2015 at 21:50, Wolfram Sang wrote:
>
>> > Yes but that is not true for drivers that support both OF and legacy board
>> > files. For those drivers, there will be a lot of boiler plate code
>> > duplicated
>> > that would look something like:
>> >
>> > unsigned long
> > Yes but that is not true for drivers that support both OF and legacy board
> > files. For those drivers, there will be a lot of boiler plate code
> > duplicated
> > that would look something like:
> >
> > unsigned long data;
> > struct of_device_id *match;
> > struct
> > Yes but that is not true for drivers that support both OF and legacy board
> > files. For those drivers, there will be a lot of boiler plate code
> > duplicated
> > that would look something like:
> >
> > unsigned long data;
> > struct of_device_id *match;
> > struct
Hi Wolfram,
On 1 October 2015 at 21:50, Wolfram Sang wrote:
>
>> > Yes but that is not true for drivers that support both OF and legacy board
>> > files. For those drivers, there will be a lot of boiler plate code
>> > duplicated
>> > that would look something like:
>> >
>>
Hello Lee,
On 09/24/2015 06:58 PM, Lee Jones wrote:
[snip]
>>
>>> Drivers will know if they either only supply an I2C or OF table, so
>>> they will know which call to use in order to obtain their
>>
>> Yes but that is not true for drivers that support both OF and legacy board
>> files. For
On Thu, 24 Sep 2015, Javier Martinez Canillas wrote:
> On 09/20/2015 06:15 AM, Lee Jones wrote:
> > On Thu, 17 Sep 2015, Javier Martinez Canillas wrote:
> >
> >> Hello,
> >>
> >> On 09/11/2015 01:55 PM, Kieran Bingham wrote:
> >>> Hi Wolfram,
> >>>
> >>> I have picked this patchset [0] up from
Hello Lee,
On 09/20/2015 06:15 AM, Lee Jones wrote:
> On Thu, 17 Sep 2015, Javier Martinez Canillas wrote:
>
>> Hello,
>>
>> On 09/11/2015 01:55 PM, Kieran Bingham wrote:
>>> Hi Wolfram,
>>>
>>> I have picked this patchset [0] up from Lee to rebase it, with an aim to
>>> get this series moving
Hello Lee,
On 09/20/2015 06:15 AM, Lee Jones wrote:
> On Thu, 17 Sep 2015, Javier Martinez Canillas wrote:
>
>> Hello,
>>
>> On 09/11/2015 01:55 PM, Kieran Bingham wrote:
>>> Hi Wolfram,
>>>
>>> I have picked this patchset [0] up from Lee to rebase it, with an aim to
>>> get this series moving
Hello Lee,
On 09/24/2015 06:58 PM, Lee Jones wrote:
[snip]
>>
>>> Drivers will know if they either only supply an I2C or OF table, so
>>> they will know which call to use in order to obtain their
>>
>> Yes but that is not true for drivers that support both OF and legacy board
>> files. For
On Thu, 24 Sep 2015, Javier Martinez Canillas wrote:
> On 09/20/2015 06:15 AM, Lee Jones wrote:
> > On Thu, 17 Sep 2015, Javier Martinez Canillas wrote:
> >
> >> Hello,
> >>
> >> On 09/11/2015 01:55 PM, Kieran Bingham wrote:
> >>> Hi Wolfram,
> >>>
> >>> I have picked this patchset [0] up from
On Thu, 17 Sep 2015, Javier Martinez Canillas wrote:
> Hello,
>
> On 09/11/2015 01:55 PM, Kieran Bingham wrote:
> > Hi Wolfram,
> >
> > I have picked this patchset [0] up from Lee to rebase it, with an aim to
> > get this series moving again.
> >
> > This resend fixes up my SoB's as
On Thu, 17 Sep 2015, Javier Martinez Canillas wrote:
> Hello,
>
> On 09/11/2015 01:55 PM, Kieran Bingham wrote:
> > Hi Wolfram,
> >
> > I have picked this patchset [0] up from Lee to rebase it, with an aim to
> > get this series moving again.
> >
> > This resend fixes up my SoB's as
Hello,
On 09/11/2015 01:55 PM, Kieran Bingham wrote:
> Hi Wolfram,
>
> I have picked this patchset [0] up from Lee to rebase it, with an aim to
> get this series moving again.
>
> This resend fixes up my SoB's as highlighted by Lee
>
> A couple of minor issues were resolved in the rebase. As
Hello,
On 09/11/2015 01:55 PM, Kieran Bingham wrote:
> Hi Wolfram,
>
> I have picked this patchset [0] up from Lee to rebase it, with an aim to
> get this series moving again.
>
> This resend fixes up my SoB's as highlighted by Lee
>
> A couple of minor issues were resolved in the rebase. As
On Fri, 11 Sep 2015, Kieran Bingham wrote:
> Hi Wolfram,
>
> I have picked this patchset [0] up from Lee to rebase it, with an aim to
> get this series moving again.
>
> This resend fixes up my SoB's as highlighted by Lee
>
> A couple of minor issues were resolved in the rebase. As it stood,
Hi Wolfram,
I have picked this patchset [0] up from Lee to rebase it, with an aim to
get this series moving again.
This resend fixes up my SoB's as highlighted by Lee
A couple of minor issues were resolved in the rebase. As it stood, Javier
proposed [1] to merge this series, and use a follow up
On Fri, 11 Sep 2015, Kieran Bingham wrote:
> Hi Wolfram,
>
> I have picked this patchset [0] up from Lee to rebase it, with an aim to
> get this series moving again.
>
> This resend fixes up my SoB's as highlighted by Lee
>
> A couple of minor issues were resolved in the rebase. As it stood,
Hi Wolfram,
I have picked this patchset [0] up from Lee to rebase it, with an aim to
get this series moving again.
This resend fixes up my SoB's as highlighted by Lee
A couple of minor issues were resolved in the rebase. As it stood, Javier
proposed [1] to merge this series, and use a follow up
28 matches
Mail list logo