On Thu, 12 May 2022 18:08:28 +0100, Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: > > On Tue, Apr 19, 2022 at 03:18:36PM +0100, Marc Zyngier wrote: > > This is a followup from [2]. > > > > I recently realised that the gpiolib play ugly tricks on the > > unsuspecting irq_chip structures by patching the callbacks. > > > > Not only this breaks when an irq_chip structure is made const (which > > really should be the default case), but it also forces this structure > > to be copied at nauseam for each instance of the GPIO block, which is > > a waste of memory. > > Is this brings us to the issue with IRQ chip name? > > The use case in my mind is the following: > 1) we have two or more GPIO chips that supports IRQ; > 2) the user registers two IRQs of the same (by number) pin on different chips; > 3) cat /proc/interrupt will show 'my_gpio_chip XX', where XX is the number. /proc/interrupts isn't a dumping ground for debug information. Yes, some irqchips do that, and they have been fixed by providing the irq_print_chip callback, thus ensuring that the irq_chip structure is never written to. I would have loved to simply get rid of the variable string, but this is obviously ABI, and we can't break that. > So, do I understand correct current state of affairs? > > If so, we have to fix this to have any kind of ID added to the chip name that > we can map /proc/interrupts output correctly. This is already done. That's not an excuse to add more of those though. We already have the required infrastructure in debugfs, and that's where this sort of thing should happen. M. -- Without deviation from the norm, progress is not possible.
