LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* watchdog: SOC_MT7621?
@ 2015-02-04 10:13 Paul Bolle
  2015-02-04 10:19 ` John Crispin
  0 siblings, 1 reply; 7+ messages in thread
From: Paul Bolle @ 2015-02-04 10:13 UTC (permalink / raw)
  To: Wim Van Sebroeck, Ralf Baechle
  Cc: Valentin Rothberg, Guenter Roeck, linux-watchdog, linux-mips,
	linux-kernel

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: watchdog: SOC_MT7621?
  2015-02-04 10:13 watchdog: SOC_MT7621? Paul Bolle
@ 2015-02-04 10:19 ` John Crispin
  2015-02-04 11:04   ` Paul Bolle
  0 siblings, 1 reply; 7+ messages in thread
From: John Crispin @ 2015-02-04 10:19 UTC (permalink / raw)
  To: Paul Bolle, Wim Van Sebroeck, Ralf Baechle
  Cc: Valentin Rothberg, Guenter Roeck, linux-watchdog, linux-mips,
	linux-kernel



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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: watchdog: SOC_MT7621?
  2015-02-04 10:19 ` John Crispin
@ 2015-02-04 11:04   ` Paul Bolle
  2015-02-04 11:10     ` John Crispin
  0 siblings, 1 reply; 7+ messages in thread
From: Paul Bolle @ 2015-02-04 11:04 UTC (permalink / raw)
  To: John Crispin
  Cc: Wim Van Sebroeck, Ralf Baechle, Valentin Rothberg, Guenter Roeck,
	linux-watchdog, linux-mips, linux-kernel

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: watchdog: SOC_MT7621?
  2015-02-04 11:04   ` Paul Bolle
@ 2015-02-04 11:10     ` John Crispin
  2015-02-04 12:22       ` Paul Bolle
  0 siblings, 1 reply; 7+ messages in thread
From: John Crispin @ 2015-02-04 11:10 UTC (permalink / raw)
  To: Paul Bolle
  Cc: Wim Van Sebroeck, Ralf Baechle, Valentin Rothberg, Guenter Roeck,
	linux-watchdog, linux-mips, linux-kernel



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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: watchdog: SOC_MT7621?
  2015-02-04 11:10     ` John Crispin
@ 2015-02-04 12:22       ` Paul Bolle
  2015-02-04 13:59         ` Guenter Roeck
  0 siblings, 1 reply; 7+ messages in thread
From: Paul Bolle @ 2015-02-04 12:22 UTC (permalink / raw)
  To: John Crispin
  Cc: Wim Van Sebroeck, Ralf Baechle, Valentin Rothberg, Guenter Roeck,
	linux-watchdog, linux-mips, linux-kernel

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: watchdog: SOC_MT7621?
  2015-02-04 12:22       ` Paul Bolle
@ 2015-02-04 13:59         ` Guenter Roeck
  2015-02-04 14:14           ` John Crispin
  0 siblings, 1 reply; 7+ messages in thread
From: Guenter Roeck @ 2015-02-04 13:59 UTC (permalink / raw)
  To: Paul Bolle, John Crispin
  Cc: Wim Van Sebroeck, Ralf Baechle, Valentin Rothberg,
	linux-watchdog, linux-mips, linux-kernel

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: watchdog: SOC_MT7621?
  2015-02-04 13:59         ` Guenter Roeck
@ 2015-02-04 14:14           ` John Crispin
  0 siblings, 0 replies; 7+ messages in thread
From: John Crispin @ 2015-02-04 14:14 UTC (permalink / raw)
  To: Guenter Roeck, Paul Bolle, John Crispin
  Cc: Wim Van Sebroeck, Ralf Baechle, Valentin Rothberg,
	linux-watchdog, linux-mips, linux-kernel



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

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2015-02-04 14:14 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-04 10:13 watchdog: SOC_MT7621? Paul Bolle
2015-02-04 10:19 ` John Crispin
2015-02-04 11:04   ` Paul Bolle
2015-02-04 11:10     ` John Crispin
2015-02-04 12:22       ` Paul Bolle
2015-02-04 13:59         ` Guenter Roeck
2015-02-04 14:14           ` John Crispin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).