Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1444254 > unrolled thread

Re: [RESEND PATCH 05/14] eeprom: at24: hide the read/write loop behind a macro

Started byWolfram Sang <wsa@the-dreams.de>
First post2016-07-15 14:30 +0200
Last post2016-07-17 20:10 +0200
Articles 6 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RESEND PATCH 05/14] eeprom: at24: hide the read/write loop  behind a macro Wolfram Sang <wsa@the-dreams.de> - 2016-07-15 14:30 +0200
    Re: [RESEND PATCH 05/14] eeprom: at24: hide the read/write loop  behind a macro Bartosz Golaszewski <bgolaszewski@baylibre.com> - 2016-07-15 15:00 +0200
      Re: [RESEND PATCH 05/14] eeprom: at24: hide the read/write loop  behind a macro Wolfram Sang <wsa@the-dreams.de> - 2016-07-15 17:10 +0200
        Re: [RESEND PATCH 05/14] eeprom: at24: hide the read/write loop  behind a macro Wolfram Sang <wsa@the-dreams.de> - 2016-07-16 07:00 +0200
          Re: [RESEND PATCH 05/14] eeprom: at24: hide the read/write loop  behind a macro Bartosz Golaszewski <bgolaszewski@baylibre.com> - 2016-07-16 21:30 +0200
            Re: [RESEND PATCH 05/14] eeprom: at24: hide the read/write loop  behind a macro Wolfram Sang <wsa@the-dreams.de> - 2016-07-17 20:10 +0200

#1444254 — Re: [RESEND PATCH 05/14] eeprom: at24: hide the read/write loop behind a macro

FromWolfram Sang <wsa@the-dreams.de>
Date2016-07-15 14:30 +0200
SubjectRe: [RESEND PATCH 05/14] eeprom: at24: hide the read/write loop behind a macro
Message-ID<rVapH-6QL-9@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

> +/*
> + * Both reads and writes fail if the previous write didn't complete yet. This
> + * macro loops a few times waiting at least long enough for one entire page
> + * write to work.
> + *
> + * It takes two parameters: a variable in which the future timeout in jiffies
> + * will be stored and a temporary variable holding the time of the last
> + * iteration of processing the request. Both should be unsigned integers
> + * holding at least 32 bits.
> + */
> +#define loop_until_timeout(tout, op_time)				\
> +	for (tout = jiffies + msecs_to_jiffies(write_timeout),		\
> +		op_time = jiffies;					\
> +	     time_before(op_time, tout);				\
> +	     usleep_range(1000, 1500), op_time = jiffies)

There is one subtle change coming with this change: the do-while loop is
guaranteed to run at least once while the for-loop doesn't.

[toc] | [next] | [standalone]

#1444285

FromBartosz Golaszewski <bgolaszewski@baylibre.com>
Date2016-07-15 15:00 +0200
Message-ID<rVaSL-70X-41@gated-at.bofh.it>
In reply to#1444254
2016-07-15 14:24 GMT+02:00 Wolfram Sang <wsa@the-dreams.de>:
>> +/*
>> + * Both reads and writes fail if the previous write didn't complete yet. This
>> + * macro loops a few times waiting at least long enough for one entire page
>> + * write to work.
>> + *
>> + * It takes two parameters: a variable in which the future timeout in jiffies
>> + * will be stored and a temporary variable holding the time of the last
>> + * iteration of processing the request. Both should be unsigned integers
>> + * holding at least 32 bits.
>> + */
>> +#define loop_until_timeout(tout, op_time)                            \
>> +     for (tout = jiffies + msecs_to_jiffies(write_timeout),          \
>> +             op_time = jiffies;                                      \
>> +          time_before(op_time, tout);                                \
>> +          usleep_range(1000, 1500), op_time = jiffies)
>
> There is one subtle change coming with this change: the do-while loop is
> guaranteed to run at least once while the for-loop doesn't.
>

While it's technically possible, it will never happen as long as
write_timeout is set to some sensible value.

Thanks,
Bartosz

[toc] | [prev] | [next] | [standalone]

#1444358

FromWolfram Sang <wsa@the-dreams.de>
Date2016-07-15 17:10 +0200
Message-ID<rVcUx-8sw-23@gated-at.bofh.it>
In reply to#1444285

[Multipart message — attachments visible in raw view] — view raw

> >> +#define loop_until_timeout(tout, op_time)                            \
> >> +     for (tout = jiffies + msecs_to_jiffies(write_timeout),          \
> >> +             op_time = jiffies;                                      \
> >> +          time_before(op_time, tout);                                \
> >> +          usleep_range(1000, 1500), op_time = jiffies)
> >
> > There is one subtle change coming with this change: the do-while loop is
> > guaranteed to run at least once while the for-loop doesn't.
> >
> 
> While it's technically possible, it will never happen as long as
> write_timeout is set to some sensible value.

I know that. I prefer Linux to be rock-stable, though, even when
slightly misconfigured (or under extreme load for that matter). An
incremental patch would be enough, no need to resend.

[toc] | [prev] | [next] | [standalone]

#1444743

FromWolfram Sang <wsa@the-dreams.de>
Date2016-07-16 07:00 +0200
Message-ID<rVpRL-7Mr-1@gated-at.bofh.it>
In reply to#1444358

[Multipart message — attachments visible in raw view] — view raw

> > >> +#define loop_until_timeout(tout, op_time)                            \
> > >> +     for (tout = jiffies + msecs_to_jiffies(write_timeout),          \
> > >> +             op_time = jiffies;                                      \
> > >> +          time_before(op_time, tout);                                \
> > >> +          usleep_range(1000, 1500), op_time = jiffies)

What about:

#define loop_until_timeout(tout, op_time)                                \
     for (tout = jiffies + msecs_to_jiffies(write_timeout), op_time = 0; \
          op_time ? time_before(op_time, tout) : true;                   \
          usleep_range(1000, 1500), op_time = jiffies)

? Would probably need an explanation in a comment, though.

[toc] | [prev] | [next] | [standalone]

#1444902

FromBartosz Golaszewski <bgolaszewski@baylibre.com>
Date2016-07-16 21:30 +0200
Message-ID<rVDrH-7KT-1@gated-at.bofh.it>
In reply to#1444743
2016-07-16 6:56 GMT+02:00 Wolfram Sang <wsa@the-dreams.de>:
>
>> > >> +#define loop_until_timeout(tout, op_time)                            \
>> > >> +     for (tout = jiffies + msecs_to_jiffies(write_timeout),          \
>> > >> +             op_time = jiffies;                                      \
>> > >> +          time_before(op_time, tout);                                \
>> > >> +          usleep_range(1000, 1500), op_time = jiffies)
>
> What about:
>
> #define loop_until_timeout(tout, op_time)                                \
>      for (tout = jiffies + msecs_to_jiffies(write_timeout), op_time = 0; \
>           op_time ? time_before(op_time, tout) : true;                   \
>           usleep_range(1000, 1500), op_time = jiffies)
>
> ? Would probably need an explanation in a comment, though.
>

Hi Wolfram,

thanks for the suggestion, it looks good. I'm not at home right now
and don't have access to any device with which I could test it. I'll
try to send the patch tomorrow evening or Monday morning.

Best regards,
Bartosz Golaszewski

[toc] | [prev] | [next] | [standalone]

#1445066

FromWolfram Sang <wsa@the-dreams.de>
Date2016-07-17 20:10 +0200
Message-ID<rVYFQ-430-3@gated-at.bofh.it>
In reply to#1444902

[Multipart message — attachments visible in raw view] — view raw

> thanks for the suggestion, it looks good. I'm not at home right now
> and don't have access to any device with which I could test it. I'll
> try to send the patch tomorrow evening or Monday morning.

Thanks. Please make it an incremental patch because I am going to apply
the base patches right now.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web