RE: [PATCH] wan: time_before()
Hi, Yes, a usleep(10) would be just fine. Regards Kevin -Original Message- From: David Miller [mailto:da...@davemloft.net] Sent: 26 May 2014 05:41 To: j...@perches.com Cc: manuel.schoell...@gmx.de; Kevin Curtis; net...@vger.kernel.org; linux-kernel@vger.kernel.org; kernel-janit...@vger.kernel.org Subject: Re: [PATCH] wan: time_before() From: Joe Perches Date: Sun, 25 May 2014 10:58:52 -0700 > On Sun, 2014-05-25 at 19:32 +0200, Manuel Schölling wrote: >> To be future-proof and for better readability the time comparisons >> are modified to use time_before() instead of plain, error-prone math. > > Sensible change, but it seems these should be > udelay(some_constant) instead of a a rather variable time wait based > on a system/config defined jiffies. Agreed, this code probably wants udelay(10) or something like that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] wan: time_before()
From: Joe Perches Date: Sun, 25 May 2014 10:58:52 -0700 > On Sun, 2014-05-25 at 19:32 +0200, Manuel Schölling wrote: >> To be future-proof and for better readability the time comparisons are >> modified to use time_before() instead of plain, error-prone math. > > Sensible change, but it seems these should be > udelay(some_constant) instead of a a rather > variable time wait based on a system/config > defined jiffies. Agreed, this code probably wants udelay(10) or something like that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] wan: time_before()
On Sun, 2014-05-25 at 19:32 +0200, Manuel Schölling wrote: > To be future-proof and for better readability the time comparisons are > modified to use time_before() instead of plain, error-prone math. Sensible change, but it seems these should be udelay(some_constant) instead of a a rather variable time wait based on a system/config defined jiffies. Kevin? > diff --git a/drivers/net/wan/farsync.c b/drivers/net/wan/farsync.c [] > @@ -697,14 +697,14 @@ fst_cpureset(struct fst_card_info *card) >* We are delaying here to allow the 9054 to reset itself >*/ > j = jiffies + 1; > - while (jiffies < j) > + while (time_before(jiffies, j)) > /* Do nothing */ ; > outw(0x240f, card->pci_conf + CNTRL_9054 + 2); > /* >* We are delaying here to allow the 9054 to reload its eeprom >*/ > j = jiffies + 1; > - while (jiffies < j) > + while (time_before(jiffies, j)) > /* Do nothing */ ; > outw(0x040f, card->pci_conf + CNTRL_9054 + 2); > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] wan: time_before()
To be future-proof and for better readability the time comparisons are modified to use time_before() instead of plain, error-prone math. Signed-off-by: Manuel Schölling --- drivers/net/wan/farsync.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wan/farsync.c b/drivers/net/wan/farsync.c index bcfff0d..d007f60 100644 --- a/drivers/net/wan/farsync.c +++ b/drivers/net/wan/farsync.c @@ -697,14 +697,14 @@ fst_cpureset(struct fst_card_info *card) * We are delaying here to allow the 9054 to reset itself */ j = jiffies + 1; - while (jiffies < j) + while (time_before(jiffies, j)) /* Do nothing */ ; outw(0x240f, card->pci_conf + CNTRL_9054 + 2); /* * We are delaying here to allow the 9054 to reload its eeprom */ j = jiffies + 1; - while (jiffies < j) + while (time_before(jiffies, j)) /* Do nothing */ ; outw(0x040f, card->pci_conf + CNTRL_9054 + 2); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/