Re: [PATCH v4 3/5] irqchip: Add DT binding doc for the virtual irq demuxer chip

[Mark Rutland]

On Wed, Feb 11, 2015 at 01:38:59PM +0000, Alexandre Belloni wrote:
> On 11/02/2015 at 12:36:56 +0000, Mark Rutland wrote :
> > > Actually, that was one of the requirements expressed by Thomas (Thomas,
> > > correct me if I'm wrong).
> > > The point was to force shared irq users to explicitly specify that they
> > > are mixing !IRQF_NO_SUSPEND and IRQF_NO_SUSPEND because they have no
> > > other choice.
> > > 
> > > With your patch, there's no way to inform users that they are
> > > erroneously setting the IRQF_NO_SUSPEND flag on one of their shared
> > > interrupt.
> > 
> > Sure, but even with the demux that's still the case (because it pretends
> > that this mismatch is a HW property rather than a property of the set of
> > drivers sharing the interrupt).
> > 
> > Whether there's a demux node in the DTB is entirely separate from
> > whether the drivers can actually handle the situation.
> > 
> > So if we need a warning in the presence of mismatch and action masking,
> > we need the exact same warning with the demux.
> > 
> 
> Actually, we only care about removing the warning. It is effectively the
> HW that forces us to do so. So we would be completely happy with a new
> flag to silence the warning as we know what we are doing (I think that
> has already been suggested).

Sure.

Given that the warning is there to tell you that the _drivers_ aren't
using the interrupt in a consistent manner, I don't see how introducing
a new fake device in the DT solves that. It simply masks some irqactions
at a different level of the SW stack from my patch, completely
independently of the drivers.

So whether or not the warning is necessary is orthogonal to whether or
not this patch is reasonable. If it's not necessary, neither patch needs
it. If it is necessary, it's also necessary for the demux.

> > The presence of a demux implies the DTB author believes they have solved
> > the problem with the demux, not necessarily that they have considered
> > the situation and updated drivers appropriately. Relying on the demux to
> > imply that everything is fine only gives us the illusion that everything
> > is fine.
> > 
> 
> Whatever the solution, it could be used as a workaround the warning as
> this is exactly what we need for our platform.

Let's hope we can get this patch into shape quickly then :)

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/