On Fri, 2018-07-13 at 16:42 -0700, Randy Dunlap wrote:
> On 07/13/2018 04:37 PM, NeilBrown wrote:
>
> coding-style.rst says:
> Also, use braces when a loop contains more than a single simple
> statement:
Independently on a) would we use some macro for condition, or b) fix
macros against this kin
On 07/16/2018 01:11 AM, Andy Shevchenko wrote:
> On Fri, 2018-07-13 at 16:42 -0700, Randy Dunlap wrote:
>> On 07/13/2018 04:37 PM, NeilBrown wrote:
>
>>
>> coding-style.rst says:
>> Also, use braces when a loop contains more than a single simple
>> statement:
>
> Independently on a) would we use
On Mon, Jul 16 2018, Andy Shevchenko wrote:
> On Fri, 2018-07-13 at 16:42 -0700, Randy Dunlap wrote:
>> On 07/13/2018 04:37 PM, NeilBrown wrote:
>
>>
>> coding-style.rst says:
>> Also, use braces when a loop contains more than a single simple
>> statement:
>
> Independently on a) would we use som
On Wed, Jul 11 2018, Andrew Morton wrote:
> On Wed, 11 Jul 2018 13:51:08 +0200 Daniel Vetter wrote:
>
>> But I still have the situation that a bunch of maintainers acked this
>> and Andrew Morton defacto nacked it, which I guess means I'll keep the
>> macro in drm? The common way to go about this
On 07/13/2018 04:37 PM, NeilBrown wrote:
> On Wed, Jul 11 2018, Andrew Morton wrote:
>
>> On Wed, 11 Jul 2018 13:51:08 +0200 Daniel Vetter wrote:
>>
>>> But I still have the situation that a bunch of maintainers acked this
>>> and Andrew Morton defacto nacked it, which I guess means I'll keep the
On Thu, Jul 12, 2018 at 1:05 AM, Andrew Morton
wrote:
> On Wed, 11 Jul 2018 13:51:08 +0200 Daniel Vetter wrote:
>> But I still have the situation that a bunch of maintainers acked this
>> and Andrew Morton defacto nacked it, which I guess means I'll keep the
>> macro in drm? The common way to go
On Wed, 11 Jul 2018 13:51:08 +0200 Daniel Vetter wrote:
> But I still have the situation that a bunch of maintainers acked this
> and Andrew Morton defacto nacked it, which I guess means I'll keep the
> macro in drm? The common way to go about this seems to be to just push
> the patch series with
On Tue, Jul 10, 2018 at 12:32 PM, NeilBrown wrote:
> On Tue, Jul 10 2018, Daniel Vetter wrote:
>
>> On Mon, Jul 09, 2018 at 04:30:01PM -0700, Andrew Morton wrote:
>>> On Mon, 9 Jul 2018 18:25:09 +0200 Daniel Vetter
>>> wrote:
>>>
>>> > To avoid compilers complainig about ambigious else blocks w
On Tue, Jul 10 2018, Daniel Vetter wrote:
> On Mon, Jul 09, 2018 at 04:30:01PM -0700, Andrew Morton wrote:
>> On Mon, 9 Jul 2018 18:25:09 +0200 Daniel Vetter
>> wrote:
>>
>> > To avoid compilers complainig about ambigious else blocks when putting
>> > an if condition into a for_each macro one
On Mon, Jul 09, 2018 at 04:30:01PM -0700, Andrew Morton wrote:
> On Mon, 9 Jul 2018 18:25:09 +0200 Daniel Vetter
> wrote:
>
> > To avoid compilers complainig about ambigious else blocks when putting
> > an if condition into a for_each macro one needs to invert the
> > condition and add a dummy
On Mon, 2018-07-09 at 18:25 +0200, Daniel Vetter wrote:
> v2: Explain a bit better what this is good for, after the discussion
> with Peter Z.
Since I have not been Cc'ed to your discussion there is another
weirdness which this macro prohibits, i.e.
for_each_blah() {
} else {
...blahblah...
}
On Mon, 9 Jul 2018 18:25:09 +0200 Daniel Vetter wrote:
> To avoid compilers complainig about ambigious else blocks when putting
> an if condition into a for_each macro one needs to invert the
> condition and add a dummy else. We have a nice little convenience
> macro for that in drm headers, let
To avoid compilers complainig about ambigious else blocks when putting
an if condition into a for_each macro one needs to invert the
condition and add a dummy else. We have a nice little convenience
macro for that in drm headers, let's move it out. Subsequent patches
will roll it out to other place
13 matches
Mail list logo
