| Message ID | 51E7236D.3010700@codeaurora.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 07/17, Stephen Boyd wrote: > On 07/17/13 15:53, Nicolas Pitre wrote: > > On Wed, 17 Jul 2013, Stephen Boyd wrote: > > > >> On 07/17/13 15:34, Nicolas Pitre wrote: > >>> On Wed, 17 Jul 2013, Stephen Boyd wrote: > >>> > >>>> On 07/12/13 05:10, Stephen Boyd wrote: > >>>>> On 07/12, Javi Merino wrote: > >>>>>> I agree, we should drop the check. It's annoying in uniprocessors and > >>>>>> unlikely to be found in the real world unless your gic entry in the dt > >>>>>> is wrong. > >>> And that's a likely outcome in the real world. > >>> > >>>>> Ok. How about this? > >>>> Any comments? > >>> What about this instead: > >> Unfortunately arm64 doesn't have SMP_ON_UP. > > And why does that matter? > > Because the gic driver is compiled on both arm and arm64? I suppose we > could define is_smp() to 1 on arm64 but its probably better to rely on > generic kernel things instead of arch specific functions. > > > > >> It sounds like you preferred the first patch using num_possible_cpus() > > Probably, yes. I didn't follow the early conversation though. > > This was the first patch: > > ---8<---- > > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c > index 19ceaa6..589c760 100644 > --- a/drivers/irqchip/irq-gic.c > +++ b/drivers/irqchip/irq-gic.c > @@ -368,7 +368,7 @@ static u8 gic_get_cpumask(struct gic_chip_data *gic) > break; > } > > - if (!mask) > + if (!mask && num_possible_cpus() > 1) > pr_crit("GIC CPU mask not found - kernel will fail to boot.\n"); > > return mask; Can one of these two patches be picked up?
On Thu, 22 Aug 2013, Stephen Boyd wrote: > On 07/17, Stephen Boyd wrote: > > On 07/17/13 15:53, Nicolas Pitre wrote: > > > On Wed, 17 Jul 2013, Stephen Boyd wrote: > > > > > >> On 07/17/13 15:34, Nicolas Pitre wrote: > > >>> On Wed, 17 Jul 2013, Stephen Boyd wrote: > > >>> > > >>>> On 07/12/13 05:10, Stephen Boyd wrote: > > >>>>> On 07/12, Javi Merino wrote: > > >>>>>> I agree, we should drop the check. It's annoying in uniprocessors and > > >>>>>> unlikely to be found in the real world unless your gic entry in the dt > > >>>>>> is wrong. > > >>> And that's a likely outcome in the real world. > > >>> > > >>>>> Ok. How about this? > > >>>> Any comments? > > >>> What about this instead: > > >> Unfortunately arm64 doesn't have SMP_ON_UP. > > > And why does that matter? > > > > Because the gic driver is compiled on both arm and arm64? I suppose we > > could define is_smp() to 1 on arm64 but its probably better to rely on > > generic kernel things instead of arch specific functions. > > > > > > > >> It sounds like you preferred the first patch using num_possible_cpus() > > > Probably, yes. I didn't follow the early conversation though. > > > > This was the first patch: > > > > ---8<---- > > > > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c > > index 19ceaa6..589c760 100644 > > --- a/drivers/irqchip/irq-gic.c > > +++ b/drivers/irqchip/irq-gic.c > > @@ -368,7 +368,7 @@ static u8 gic_get_cpumask(struct gic_chip_data *gic) > > break; > > } > > > > - if (!mask) > > + if (!mask && num_possible_cpus() > 1) > > pr_crit("GIC CPU mask not found - kernel will fail to boot.\n"); > > > > return mask; > > Can one of these two patches be picked up? Sure. Just send it to RMK's patch system with my ACK. Nicolas
On 08/22, Nicolas Pitre wrote: > On Thu, 22 Aug 2013, Stephen Boyd wrote: > > > On 07/17, Stephen Boyd wrote: > > > On 07/17/13 15:53, Nicolas Pitre wrote: > > > > On Wed, 17 Jul 2013, Stephen Boyd wrote: > > > > > > > >> On 07/17/13 15:34, Nicolas Pitre wrote: > > > >>> On Wed, 17 Jul 2013, Stephen Boyd wrote: > > > >>> > > > >>>> On 07/12/13 05:10, Stephen Boyd wrote: > > > >>>>> On 07/12, Javi Merino wrote: > > > >>>>>> I agree, we should drop the check. It's annoying in uniprocessors and > > > >>>>>> unlikely to be found in the real world unless your gic entry in the dt > > > >>>>>> is wrong. > > > >>> And that's a likely outcome in the real world. > > > >>> > > > >>>>> Ok. How about this? > > > >>>> Any comments? > > > >>> What about this instead: > > > >> Unfortunately arm64 doesn't have SMP_ON_UP. > > > > And why does that matter? > > > > > > Because the gic driver is compiled on both arm and arm64? I suppose we > > > could define is_smp() to 1 on arm64 but its probably better to rely on > > > generic kernel things instead of arch specific functions. > > > > > > > > > > >> It sounds like you preferred the first patch using num_possible_cpus() > > > > Probably, yes. I didn't follow the early conversation though. > > > > > > This was the first patch: > > > > > > ---8<---- > > > > > > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c > > > index 19ceaa6..589c760 100644 > > > --- a/drivers/irqchip/irq-gic.c > > > +++ b/drivers/irqchip/irq-gic.c > > > @@ -368,7 +368,7 @@ static u8 gic_get_cpumask(struct gic_chip_data *gic) > > > break; > > > } > > > > > > - if (!mask) > > > + if (!mask && num_possible_cpus() > 1) > > > pr_crit("GIC CPU mask not found - kernel will fail to boot.\n"); > > > > > > return mask; > > > > Can one of these two patches be picked up? > > Sure. Just send it to RMK's patch system with my ACK. > I'm confused on that. MAINTAINERS says this patch should go through Thomas Gleixner's irq/core branch but it looks like only arm-soc has been taking patches for the current location.
On Thu, 22 Aug 2013, Stephen Boyd wrote: > On 08/22, Nicolas Pitre wrote: > > On Thu, 22 Aug 2013, Stephen Boyd wrote: > > > > > On 07/17, Stephen Boyd wrote: > > > > On 07/17/13 15:53, Nicolas Pitre wrote: > > > > > On Wed, 17 Jul 2013, Stephen Boyd wrote: > > > > > > > > > >> On 07/17/13 15:34, Nicolas Pitre wrote: > > > > >>> On Wed, 17 Jul 2013, Stephen Boyd wrote: > > > > >>> > > > > >>>> On 07/12/13 05:10, Stephen Boyd wrote: > > > > >>>>> On 07/12, Javi Merino wrote: > > > > >>>>>> I agree, we should drop the check. It's annoying in uniprocessors and > > > > >>>>>> unlikely to be found in the real world unless your gic entry in the dt > > > > >>>>>> is wrong. > > > > >>> And that's a likely outcome in the real world. > > > > >>> > > > > >>>>> Ok. How about this? > > > > >>>> Any comments? > > > > >>> What about this instead: > > > > >> Unfortunately arm64 doesn't have SMP_ON_UP. > > > > > And why does that matter? > > > > > > > > Because the gic driver is compiled on both arm and arm64? I suppose we > > > > could define is_smp() to 1 on arm64 but its probably better to rely on > > > > generic kernel things instead of arch specific functions. > > > > > > > > > > > > > >> It sounds like you preferred the first patch using num_possible_cpus() > > > > > Probably, yes. I didn't follow the early conversation though. > > > > > > > > This was the first patch: > > > > > > > > ---8<---- > > > > > > > > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c > > > > index 19ceaa6..589c760 100644 > > > > --- a/drivers/irqchip/irq-gic.c > > > > +++ b/drivers/irqchip/irq-gic.c > > > > @@ -368,7 +368,7 @@ static u8 gic_get_cpumask(struct gic_chip_data *gic) > > > > break; > > > > } > > > > > > > > - if (!mask) > > > > + if (!mask && num_possible_cpus() > 1) > > > > pr_crit("GIC CPU mask not found - kernel will fail to boot.\n"); > > > > > > > > return mask; > > > > > > Can one of these two patches be picked up? > > > > Sure. Just send it to RMK's patch system with my ACK. > > > > I'm confused on that. MAINTAINERS says this patch should go > through Thomas Gleixner's irq/core branch but it looks like only > arm-soc has been taking patches for the current location. Blah. OK then, just send it to Thomas. Initially this code was written and committed by RMK which is why I suggested you send him the fix. Nicolas
On Fri, Aug 23, 2013 at 12:51:59AM -0400, Nicolas Pitre wrote: > Blah. OK then, just send it to Thomas. > > Initially this code was written and committed by RMK which is why I > suggested you send him the fix. It _should_, because the author of the file presumably knows how the driver is supposed to work much better than the maintainer of the subsystem. So driver authors _should_ always be involved in the handling of the patch. Unfortunately, that rarely happens, and I've given up any hope of the old kernel process(es) remaining where authors were responsible for the code they wrote. Somehow, kernel maintanence has been perversed so that subsystem maintainers get to decide whether patches to drivers that they don't have hardware for are to be applied irrespective of whether the driver author has any input to it.
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c index 19ceaa6..589c760 100644 --- a/drivers/irqchip/irq-gic.c +++ b/drivers/irqchip/irq-gic.c @@ -368,7 +368,7 @@ static u8 gic_get_cpumask(struct gic_chip_data *gic) break; } - if (!mask) + if (!mask && num_possible_cpus() > 1) pr_crit("GIC CPU mask not found - kernel will fail to boot.\n"); return mask;