John Crispin's commit 576c618cf659 ("watchdog: add MT7621 watchdog
support") was included in today's linux-next (ie, next 20150204). I
noticed because a script I use to check linux-next spotted a problem
with it.
That commit adds an (optional) dependency on the Kconfig symbol
SOC_MT7621. But there's no symbol SOC_MT7621 in linux-next yet.
(Note that there currently are two checks for CONFIG_SOC_MT7621 in
arch/mips/ralink/early_printk.c. I mentioned these checks in
https://lkml.org/lkml/2014/10/27/218 and in
https://lkml.org/lkml/2015/1/12/302 . John never replied to these
messages. Since I haven't received replies on other, more serious issues
in over three months I assume John has disappeared.)
Is SOC_MT7621 still being worked on?
Paul Bolle
On 04/02/2015 11:13, Paul Bolle wrote:
> messages. Since I haven't received replies on other, more serious
> issues in over three months I assume John has disappeared.)
into thin air, *pooff*
> Is SOC_MT7621 still being worked on?
yes we dropped the series as it collided with the gic rework that
chromiun.org was working on. i hope to push it during the next merge
window. the 1004k support has just been flaky till now as there was
never any real silicon to test it on. the chromium people really did a
good job at making the gic code nicer.
quite an impressive Cc list you have there
John
On Wed, 2015-02-04 at 11:19 +0100, John Crispin wrote:
> On 04/02/2015 11:13, Paul Bolle wrote:
> > Is SOC_MT7621 still being worked on?
>
> yes we dropped the series as it collided with the gic rework that
> chromiun.org was working on. i hope to push it during the next merge
> window. the 1004k support has just been flaky till now as there was
> never any real silicon to test it on. the chromium people really did a
> good job at making the gic code nicer.
Thanks for explaining this. Unless SOC_MT7621 takes a long time to land
in linux-next I won't be bothering you again about this. (I think I'll
use "by the end of the v3.20 series" as a definition of a long time.)
> quite an impressive Cc list you have there
Yes, that's the way it works with problems that span two (or more)
subsystems (in this case watchdog and MIPS). Actually, much longer CC
lists are used regularly on lkml.
Thanks!
Paul Bolle
On 04/02/2015 12:04, Paul Bolle wrote:
> On Wed, 2015-02-04 at 11:19 +0100, John Crispin wrote:
>> On 04/02/2015 11:13, Paul Bolle wrote:
>>> Is SOC_MT7621 still being worked on?
>>
>> yes we dropped the series as it collided with the gic rework that
>> chromiun.org was working on. i hope to push it during the next merge
>> window. the 1004k support has just been flaky till now as there was
>> never any real silicon to test it on. the chromium people really did a
>> good job at making the gic code nicer.
>
> Thanks for explaining this. Unless SOC_MT7621 takes a long time to land
> in linux-next I won't be bothering you again about this. (I think I'll
> use "by the end of the v3.20 series" as a definition of a long time.)
>
>> quite an impressive Cc list you have there
>
> Yes, that's the way it works with problems that span two (or more)
> subsystems (in this case watchdog and MIPS). Actually, much longer CC
> lists are used regularly on lkml.
>
> Thanks!
>
>
> Paul Bolle
>
i think wim should just drop it and we leave it in openwrt with the
other 1/2 million patches that we have. i prefer to upstream the stuff
without feeling pressured to hurry up, that kills the fun.
@Wim, can you drop the patch please ?
John
John Crispin schreef op wo 04-02-2015 om 12:10 [+0100]:
> i think wim should just drop it and we leave it in openwrt with the
> other 1/2 million patches that we have. i prefer to upstream the stuff
> without feeling pressured to hurry up, that kills the fun.
Once code is mainlined you'll get fixes written for you, updates done
for you, etc. But you'll also get pointed at defects that require you to
fix them yourself, or see the code removed eventually.
> @Wim, can you drop the patch please ?
Why should Wim drop more than the
|| SOC_MT7621
snippet?
Paul Bolle
On 02/04/2015 04:22 AM, Paul Bolle wrote:
> John Crispin schreef op wo 04-02-2015 om 12:10 [+0100]:
>> i think wim should just drop it and we leave it in openwrt with the
>> other 1/2 million patches that we have. i prefer to upstream the stuff
>> without feeling pressured to hurry up, that kills the fun.
>
> Once code is mainlined you'll get fixes written for you, updates done
> for you, etc. But you'll also get pointed at defects that require you to
> fix them yourself, or see the code removed eventually.
>
>> @Wim, can you drop the patch please ?
>
> Why should Wim drop more than the
> || SOC_MT7621
>
> snippet?
>
Question is if the driver works with MT7620 as advertised. Either case
it would be odd if the driver advertises itself as MT7621 but only works
for MT7620, so I think it should be dropped entirely for now.
Wim, should I possibly ask Stephen to include my watchdog-next branch
in his -next builds ? This would help us catching such problems earlier.
Thanks,
Guenter
On 04/02/2015 14:59, Guenter Roeck wrote:
> On 02/04/2015 04:22 AM, Paul Bolle wrote:
>> John Crispin schreef op wo 04-02-2015 om 12:10 [+0100]:
>>> i think wim should just drop it and we leave it in openwrt with the
>>> other 1/2 million patches that we have. i prefer to upstream the stuff
>>> without feeling pressured to hurry up, that kills the fun.
>>
>> Once code is mainlined you'll get fixes written for you, updates done
>> for you, etc. But you'll also get pointed at defects that require you to
>> fix them yourself, or see the code removed eventually.
>>
>>> @Wim, can you drop the patch please ?
>>
>> Why should Wim drop more than the
>> || SOC_MT7621
>>
>> snippet?
>>
>
> Question is if the driver works with MT7620 as advertised. Either case
> it would be odd if the driver advertises itself as MT7621 but only works
> for MT7620, so I think it should be dropped entirely for now.
>
> Wim, should I possibly ask Stephen to include my watchdog-next branch
> in his -next builds ? This would help us catching such problems earlier.
>
> Thanks,
> Guenter
>
>
>
it wont work on mt7620 but on mt7628 which is a subtype on mt7620. both
share the soc_mt7620.c inside arch/mips/ralink/ we rely on runtime
detection between the 2 and on the dts loading the correct driver.
mt7620 and mt7628 are both hidden behind the SOC_MT7620 symbol. the
depends on SOC_MT7620 part is correct and working. but i agree, just
drop it, i will simply carry it around with us in openwrt. one driver
more wont make a difference.
John