Re: [PULL] http://kernellabs.com/hg/~mkrufky/sms1xxx

Re: [PULL] http://kernellabs.com/hg/~mkrufky/sms1xxx

[Michael Krufky]

Mauro,

On Mon, Aug 24, 2009 at 4:32 PM, Michael Krufky<mkrufky@kernellabs.com> wrote:
> Mauro,
>
> Would you please send the final GPIO fix to Linus to fix the
> regression on the Hauppauge devices.  2.6.31 is in -rc7 now, and I
> would hate for this regression to not yet be solved before the kernel
> is released.
>
> I apologize for nagging -- I just prefer for fixes to be merged
> upstream *before* a kernel release.
>
> Thank you.
>
> Just as a reminder, the changeset that is still waiting for upstream merge is:
>
> *       sms1xxx: restore GPIO functionality for all Hauppauge devices

Just another reminder -- this is cutting it very close now.

I repeat, that this is a feature that worked in previous kernels but
is broken in 2.6.31.

I feel very concerned, considering that I posted a regression fix over
six weeks ago and it still has not made it into Linus' kernel tree.

I understand that you are a busy man -- Would it be easier for you if
I sent this patch to Linus, myself?

Please advise.

Thank you for your time.

Regards,

Michael Krufky

Re: [PULL] http://kernellabs.com/hg/~mkrufky/sms1xxx

[Mauro Carvalho Chehab]

Em Sun, 30 Aug 2009 08:53:35 -0400
Michael Krufky <mkrufky@kernellabs.com> escreveu:

> Mauro,
> 
> On Mon, Aug 24, 2009 at 4:32 PM, Michael Krufky<mkrufky@kernellabs.com> wrote:
> > Mauro,
> >
> > Would you please send the final GPIO fix to Linus to fix the
> > regression on the Hauppauge devices.  2.6.31 is in -rc7 now, and I
> > would hate for this regression to not yet be solved before the kernel
> > is released.
> >
> > I apologize for nagging -- I just prefer for fixes to be merged
> > upstream *before* a kernel release.
> >
> > Thank you.
> >
> > Just as a reminder, the changeset that is still waiting for upstream merge is:
> >
> > *       sms1xxx: restore GPIO functionality for all Hauppauge devices
> 
> Just another reminder -- this is cutting it very close now.
> 
> I repeat, that this is a feature that worked in previous kernels but
> is broken in 2.6.31.
> 
> I feel very concerned, considering that I posted a regression fix over
> six weeks ago and it still has not made it into Linus' kernel tree.

Part of the time were spent trying to reach Siano for their comments. This were
added on my queue on Aug, 19, after our unsuccessful trial of contacting them.

Unfortunately, I had a bad time having to rebase my -git trees, removing some
patches there in order to fix a conflict related to arch patches sent via
my tree.

You don't need to worry since they'll be send in time for 2.6.31.

> I understand that you are a busy man -- Would it be easier for you if
> I sent this patch to Linus, myself?

I'm currently merging the pending patches on my tree. I should be sending a
pull request upstream by the end of the day or tomorrow.

If you just send it directly, you'll break my tree, and cause troubles on the
upstream request for some other patches for 2.6.31



Cheers,
Mauro

Re: [PULL] http://kernellabs.com/hg/~mkrufky/sms1xxx

[Michael Krufky]

On Sun, Aug 30, 2009 at 6:13 PM, Mauro Carvalho
Chehab<mchehab@infradead.org> wrote:
> Em Sun, 30 Aug 2009 08:53:35 -0400
> Michael Krufky <mkrufky@kernellabs.com> escreveu:
>
>> Mauro,
>>
>> On Mon, Aug 24, 2009 at 4:32 PM, Michael Krufky<mkrufky@kernellabs.com> wrote:
>> > Mauro,
>> >
>> > Would you please send the final GPIO fix to Linus to fix the
>> > regression on the Hauppauge devices.  2.6.31 is in -rc7 now, and I
>> > would hate for this regression to not yet be solved before the kernel
>> > is released.
>> >
>> > I apologize for nagging -- I just prefer for fixes to be merged
>> > upstream *before* a kernel release.
>> >
>> > Thank you.
>> >
>> > Just as a reminder, the changeset that is still waiting for upstream merge is:
>> >
>> > *       sms1xxx: restore GPIO functionality for all Hauppauge devices
>>
>> Just another reminder -- this is cutting it very close now.
>>
>> I repeat, that this is a feature that worked in previous kernels but
>> is broken in 2.6.31.
>>
>> I feel very concerned, considering that I posted a regression fix over
>> six weeks ago and it still has not made it into Linus' kernel tree.
>
> Part of the time were spent trying to reach Siano for their comments. This were
> added on my queue on Aug, 19, after our unsuccessful trial of contacting them.
>
> Unfortunately, I had a bad time having to rebase my -git trees, removing some
> patches there in order to fix a conflict related to arch patches sent via
> my tree.
>
> You don't need to worry since they'll be send in time for 2.6.31.
>
>> I understand that you are a busy man -- Would it be easier for you if
>> I sent this patch to Linus, myself?
>
> I'm currently merging the pending patches on my tree. I should be sending a
> pull request upstream by the end of the day or tomorrow.
>
> If you just send it directly, you'll break my tree, and cause troubles on the
> upstream request for some other patches for 2.6.31

Mauro,

I see the GPIO fix in your git tree now -- Thanks for merging it.

However, I also see this changeset:

http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-2.6.git;a=commitdiff;h=31e0ad693fb4e1d1be19dbe1c4f5a1ab9978e810

I believe that it is way too late in 2.6.31 to merge a changeset like
this -- Please revert that and if there is actually a Kconfig change
required, merge a more minimal change for 2.6.31 and hold off this
huge, risky change for the next merge window.

There is not enough time to fix this, if this changeset causes
additional breakage.

Thank you,

Mike Krufky

Re: [PULL] http://kernellabs.com/hg/~mkrufky/sms1xxx

[Mauro Carvalho Chehab]

Em Mon, 31 Aug 2009 07:03:18 -0400
Michael Krufky <mkrufky@kernellabs.com> escreveu:

> I see the GPIO fix in your git tree now -- Thanks for merging it.
> 
> However, I also see this changeset:
> 
> http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-2.6.git;a=commitdiff;h=31e0ad693fb4e1d1be19dbe1c4f5a1ab9978e810
> 
> I believe that it is way too late in 2.6.31 to merge a changeset like
> this -- Please revert that and if there is actually a Kconfig change
> required, merge a more minimal change for 2.6.31 and hold off this
> huge, risky change for the next merge window.
> 
> There is not enough time to fix this, if this changeset causes
> additional breakage.

This is just Kbuild changes, and it is there at linux-next for some time,
where for sure people already tried to do several different building tests.
Among some cosmetics, it removes a dead symbol (DVB_SIANO_SMS1XXX_SMS_IDS).

It is very bad to expose to the user a config option that configs nothing.

Anyway, Linus already merged the pull request. If you eventually find a bug on
it, please ping me for us to send a fix.

Cheers,
Mauro

Re: [PULL] http://kernellabs.com/hg/~mkrufky/sms1xxx

[Michael Krufky]

On Tue, Sep 1, 2009 at 9:47 AM, Mauro Carvalho
Chehab<mchehab@infradead.org> wrote:
> Em Mon, 31 Aug 2009 07:03:18 -0400
> Michael Krufky <mkrufky@kernellabs.com> escreveu:
>
>> I see the GPIO fix in your git tree now -- Thanks for merging it.
>>
>> However, I also see this changeset:
>>
>> http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-2.6.git;a=commitdiff;h=31e0ad693fb4e1d1be19dbe1c4f5a1ab9978e810
>>
>> I believe that it is way too late in 2.6.31 to merge a changeset like
>> this -- Please revert that and if there is actually a Kconfig change
>> required, merge a more minimal change for 2.6.31 and hold off this
>> huge, risky change for the next merge window.
>>
>> There is not enough time to fix this, if this changeset causes
>> additional breakage.
>
> This is just Kbuild changes, and it is there at linux-next for some time,
> where for sure people already tried to do several different building tests.
> Among some cosmetics, it removes a dead symbol (DVB_SIANO_SMS1XXX_SMS_IDS).
>
> It is very bad to expose to the user a config option that configs nothing.
>
> Anyway, Linus already merged the pull request. If you eventually find a bug on
> it, please ping me for us to send a fix.
>
> Cheers,
> Mauro
>

The Kconfig symbol names were changed, the target object has changed,
the module filename has changed.

A submenu was added, the USB support is not enabled by default.

None of the above fixed any bug, it just makes unnecessary changes
that are inappropriate this late in a kernel development cycle.

If a bug needed to be fixed, it would have been as simple as adding
the new object file for smssdio.o , and the old
DVB_SIANO_SMS1XXX_SMS_IDS section could have been removed without
changing everything.

I think this is ridiculous to slip in at the last moment, but I would
have had no complaints seeing this in the next merge window.

What is the point of a "merge window" if you let people make such
changes as this right before a kernel is released.

Maybe it all works, maybe it doesnt.  I know I personally am not going
to test this before September fifth, the day Linus plans to release
2.6.31. ..  And even if I do find a problem, how should I know that
the powers that be will act on a regression fix in a timely manner?

Apologies to the users of this driver -- I am not interested anymore.
My time is better spend working on my own code.

On the bright side, I have some really interesting stuff coming.  I
will be posting some RFC's this week that will help to alleviate some
long-standing problems within the media subsystems.  I won't stress
over Siano's driver any longer -- this gives me more time to focus on
the really cool fun stuff :-)

If the kernel's support for this driver becomes broken again, users
can just use the driver that I have posted on kernellabs.com

Cheers,

Mike

Re: [PULL] http://kernellabs.com/hg/~mkrufky/sms1xxx

[Mauro Carvalho Chehab]

Em Tue, 1 Sep 2009 11:03:14 -0400
Michael Krufky <mkrufky@kernellabs.com> escreveu:

> The Kconfig symbol names were changed, the target object has changed,
> the module filename has changed.
> 
> A submenu was added, the USB support is not enabled by default.
> 
> None of the above fixed any bug, it just makes unnecessary changes
> that are inappropriate this late in a kernel development cycle.

None of the above breaks anything, and enabling a driver by default is not good
anyway.

> If a bug needed to be fixed, it would have been as simple as adding
> the new object file for smssdio.o , and the old
> DVB_SIANO_SMS1XXX_SMS_IDS section could have been removed without
> changing everything.
> 
> I think this is ridiculous to slip in at the last moment, but I would
> have had no complaints seeing this in the next merge window.
> 
> What is the point of a "merge window" if you let people make such
> changes as this right before a kernel is released.

The patch is a bug fix and it is even older than your LED fix. The first
version were submitted before the previous merge window, and you asked for some
changes that were done accordingly. 

Since the entire Siano driver suffered major changes at the last merge window,
this patch needs to be available together with the remaining series of the
Siano series of patches, to reflect the changes that happened inside the
driver, and the inclusion of the SDIO driver.



Cheers,
Mauro