mpc52xx bestcomm patches.

mpc52xx bestcomm patches.

[Grant Likely]

Paulus, how do you feel about merging these changes?

This is Sylvain's series of bestcomm patches.

http://patchwork.ozlabs.org/linuxppc/patch?id=13488
http://patchwork.ozlabs.org/linuxppc/patch?id=13489
http://patchwork.ozlabs.org/linuxppc/patch?id=13490
http://patchwork.ozlabs.org/linuxppc/patch?id=13491
http://patchwork.ozlabs.org/linuxppc/patch?id=13492
http://patchwork.ozlabs.org/linuxppc/patch?id=13493
http://patchwork.ozlabs.org/linuxppc/patch?id=13494

There are still a few minor issues to be resolved, but Sylvain is
suffering from a severe lack of time and this series has been stalled
for a long time because of it.  Domen and others have been working on
drivers which use bestcomm, but they can neither get their drivers
included nor address the issues in this series because of it.

Personally, I think it will be better to just merge it now and allow
others to address the remaining comments.  It's not like this is a
change to an old device that could be risky.

/me thinks about somebody saying at some time "The perfect is the
enemy of the good"  :-)

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: mpc52xx bestcomm patches.

[Kumar Gala]

On Oct 12, 2007, at 1:30 PM, Grant Likely wrote:

> Paulus, how do you feel about merging these changes?
>
> This is Sylvain's series of bestcomm patches.
>
> http://patchwork.ozlabs.org/linuxppc/patch?id=13488
> http://patchwork.ozlabs.org/linuxppc/patch?id=13489
> http://patchwork.ozlabs.org/linuxppc/patch?id=13490
> http://patchwork.ozlabs.org/linuxppc/patch?id=13491
> http://patchwork.ozlabs.org/linuxppc/patch?id=13492
> http://patchwork.ozlabs.org/linuxppc/patch?id=13493
> http://patchwork.ozlabs.org/linuxppc/patch?id=13494
>
> There are still a few minor issues to be resolved, but Sylvain is
> suffering from a severe lack of time and this series has been stalled
> for a long time because of it.  Domen and others have been working on
> drivers which use bestcomm, but they can neither get their drivers
> included nor address the issues in this series because of it.
>
> Personally, I think it will be better to just merge it now and allow
> others to address the remaining comments.  It's not like this is a
> change to an old device that could be risky.

I'm against this getting merged w/o addressing some of the long  
standing comments I've made:

http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036224.html
http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042632.html
http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042633.html

Additionally I think ALL new "libraries" like this should come with  
kerneldoc.

- k

Re: mpc52xx bestcomm patches.

[Grant Likely]

On 10/12/07, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Oct 12, 2007, at 1:30 PM, Grant Likely wrote:
>
> > Paulus, how do you feel about merging these changes?
> >
> > This is Sylvain's series of bestcomm patches.
> >
> > http://patchwork.ozlabs.org/linuxppc/patch?id=13488
> > http://patchwork.ozlabs.org/linuxppc/patch?id=13489
> > http://patchwork.ozlabs.org/linuxppc/patch?id=13490
> > http://patchwork.ozlabs.org/linuxppc/patch?id=13491
> > http://patchwork.ozlabs.org/linuxppc/patch?id=13492
> > http://patchwork.ozlabs.org/linuxppc/patch?id=13493
> > http://patchwork.ozlabs.org/linuxppc/patch?id=13494
> >
> > There are still a few minor issues to be resolved, but Sylvain is
> > suffering from a severe lack of time and this series has been stalled
> > for a long time because of it.  Domen and others have been working on
> > drivers which use bestcomm, but they can neither get their drivers
> > included nor address the issues in this series because of it.
> >
> > Personally, I think it will be better to just merge it now and allow
> > others to address the remaining comments.  It's not like this is a
> > change to an old device that could be risky.
>
> I'm against this getting merged w/o addressing some of the long
> standing comments I've made:
>
> http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036224.html
> http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042632.html
> http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042633.html
>
> Additionally I think ALL new "libraries" like this should come with
> kerneldoc.

The problem is that bestcomm is completely stalled on Sylvain.  He's
done good work, but he isn't able to put in the effort for the last
push to get it fixed and in.  But until that happens, nobody else will
step in to add patches on top of it to fix it up.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: mpc52xx bestcomm patches.

[Kumar Gala]

On Oct 12, 2007, at 1:54 PM, Grant Likely wrote:

> On 10/12/07, Kumar Gala <galak@kernel.crashing.org> wrote:
>>
>> On Oct 12, 2007, at 1:30 PM, Grant Likely wrote:
>>
>>> Paulus, how do you feel about merging these changes?
>>>
>>> This is Sylvain's series of bestcomm patches.
>>>
>>> http://patchwork.ozlabs.org/linuxppc/patch?id=13488
>>> http://patchwork.ozlabs.org/linuxppc/patch?id=13489
>>> http://patchwork.ozlabs.org/linuxppc/patch?id=13490
>>> http://patchwork.ozlabs.org/linuxppc/patch?id=13491
>>> http://patchwork.ozlabs.org/linuxppc/patch?id=13492
>>> http://patchwork.ozlabs.org/linuxppc/patch?id=13493
>>> http://patchwork.ozlabs.org/linuxppc/patch?id=13494
>>>
>>> There are still a few minor issues to be resolved, but Sylvain is
>>> suffering from a severe lack of time and this series has been  
>>> stalled
>>> for a long time because of it.  Domen and others have been  
>>> working on
>>> drivers which use bestcomm, but they can neither get their drivers
>>> included nor address the issues in this series because of it.
>>>
>>> Personally, I think it will be better to just merge it now and allow
>>> others to address the remaining comments.  It's not like this is a
>>> change to an old device that could be risky.
>>
>> I'm against this getting merged w/o addressing some of the long
>> standing comments I've made:
>>
>> http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036224.html
>> http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042632.html
>> http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042633.html
>>
>> Additionally I think ALL new "libraries" like this should come with
>> kerneldoc.
>
> The problem is that bestcomm is completely stalled on Sylvain.  He's
> done good work, but he isn't able to put in the effort for the last
> push to get it fixed and in.  But until that happens, nobody else will
> step in to add patches on top of it to fix it up.

If Sylvain doesn't have the time can't someone else pick up what he's  
done and fixup the issues with it?

- k

Re: mpc52xx bestcomm patches.

[Grant Likely]

On 10/12/07, Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Oct 12, 2007, at 1:54 PM, Grant Likely wrote:
>
> > On 10/12/07, Kumar Gala <galak@kernel.crashing.org> wrote:
> >>
> >> On Oct 12, 2007, at 1:30 PM, Grant Likely wrote:
> >>
> >>> Paulus, how do you feel about merging these changes?
> >>>
> >>> This is Sylvain's series of bestcomm patches.
> >>>
> >>> http://patchwork.ozlabs.org/linuxppc/patch?id=13488
> >>> http://patchwork.ozlabs.org/linuxppc/patch?id=13489
> >>> http://patchwork.ozlabs.org/linuxppc/patch?id=13490
> >>> http://patchwork.ozlabs.org/linuxppc/patch?id=13491
> >>> http://patchwork.ozlabs.org/linuxppc/patch?id=13492
> >>> http://patchwork.ozlabs.org/linuxppc/patch?id=13493
> >>> http://patchwork.ozlabs.org/linuxppc/patch?id=13494
> >>>
> >>> There are still a few minor issues to be resolved, but Sylvain is
> >>> suffering from a severe lack of time and this series has been
> >>> stalled
> >>> for a long time because of it.  Domen and others have been
> >>> working on
> >>> drivers which use bestcomm, but they can neither get their drivers
> >>> included nor address the issues in this series because of it.
> >>>
> >>> Personally, I think it will be better to just merge it now and allow
> >>> others to address the remaining comments.  It's not like this is a
> >>> change to an old device that could be risky.
> >>
> >> I'm against this getting merged w/o addressing some of the long
> >> standing comments I've made:
> >>
> >> http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036224.html
> >> http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042632.html
> >> http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042633.html
> >>
> >> Additionally I think ALL new "libraries" like this should come with
> >> kerneldoc.
> >
> > The problem is that bestcomm is completely stalled on Sylvain.  He's
> > done good work, but he isn't able to put in the effort for the last
> > push to get it fixed and in.  But until that happens, nobody else will
> > step in to add patches on top of it to fix it up.
>
> If Sylvain doesn't have the time can't someone else pick up what he's
> done and fixup the issues with it?

As we talked about on IRC, I'm rebasing the patches now and I'll deal
with the minor issues.  There are a couple of developers actively
working on drivers which depend on bestcomm; since they are using it,
they will be able to support it too.

The code is in good shape; is well layed out and coded.  There are
developers actively using this driver in private trees.

However, that leaves the last major issue; documentation.  The
requested documentation has not been written.  However, I do not thing
this device driver should be blocked from merging over this issue.  I
think there is a better chance of it getting documented if it is
merged instead of sitting in Sylvain's queue.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: mpc52xx bestcomm patches.

[Matt Sealey]

Kumar Gala wrote:
>> The problem is that bestcomm is completely stalled on Sylvain.  He's
>> done good work, but he isn't able to put in the effort for the last
>> push to get it fixed and in.  But until that happens, nobody else will
>> step in to add patches on top of it to fix it up.
> 
> If Sylvain doesn't have the time can't someone else pick up what he's  
> done and fixup the issues with it?

I second that motion!

There are a few minor quibbles I have with Sylvain's implementation (it
seems to have ditched some perfectly sound ideas of the original API plus
additions made by bplan for using the device tree to resolve tasks, in
favour of making the API entirely driver-dependant, and Linux-dependant
(it trashes any existing device table) also it has a few "5200-specific"
features like disabling task prefetch (errata not present in 5200B onwards).

It needs some looking at. But, this can be merged in my opinion, we can
just throw it to the list right now, and take the niggles to the list
and have a discussion about it..

In the absense of one guy hammering at the code let's just get 20 people
to review it, right here, with a new submission..

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations