linux-kernel - Re: [PATCH 09/26] mfd: ab8500-debugfs: Provide a means for a user subscribe to IRQs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130128113443.GB18212@gmail.com>
Date:	Mon, 28 Jan 2013 11:34:43 +0000
From:	Lee Jones <lee.jones@...aro.org>
To:	Samuel Ortiz <sameo@...ux.intel.com>
Cc:	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	arnd@...db.de, linus.walleij@...ricsson.com
Subject: Re: [PATCH 09/26] mfd: ab8500-debugfs: Provide a means for a user
 subscribe to IRQs

On Mon, 28 Jan 2013, Samuel Ortiz wrote:

> Hi Lee,
> 
> On Mon, Jan 28, 2013 at 10:22:23AM +0000, Lee Jones wrote:
> > On Mon, 28 Jan 2013, Samuel Ortiz wrote:
> > 
> > > Hi Lee,
> > > 
> > > On Tue, Jan 15, 2013 at 12:55:49PM +0000, Lee Jones wrote:
> > > > Allow users to subscribe to and view IRQ events live from debugfs.
> > > I seem to remember that I got a similar patch some time ago for the same
> > > purpose and my answer was: Please use a UIO driver for this. There already is
> > > such driver, it's uio_pdrv_genirq. What your debugfs registration entry could
> > > do is adding a platform device for the specific interrupt number. This would
> > > avoid the irq handler registration and the sysfs entry creation, both things I
> > > believe are not very elegant and open coded. It also gives you an IRQ count
> > > implementation.
> > > Ideally, the UIO framework could be improved to support IRQ ranges (through
> > > IRQ domains) instead of the current single interrupt number.
> > > 
> > > Have you considered going through that path ?
> > 
> > I'm going to have to put this patch-set in the bin. Pulling this
> > patch, causes lots of conflicts to the remaining patches in the
> > set.
> I bet removing this one causes a lot of conflicts. I'm not saying it should
> absolutely be removed, but I'm afraid once it's upstream no one is going to
> look at improving it.

This is really not the case. I have every intention of fixing each and
every issue which are brought to my attention during the upstreaming
process of 'drivers/regulators', 'drivers/power' and 'drivers/mfd'.

All I'm doing is making a list of all the fixups and re-writes and
I'll address them on the completion of the push. Hence if you're happy
for this to go in with my promise of improvement, it would certainly
make this task a great deal easier for me.

> And to be honest, having an IRQ handler from debugfs
> code looks weird to me. I know you can put all sort of crazyness into a
> debugfs entry, but still.
>  
> > I'll start again from scratch and find another way to sync the ab* MFD
> > drivers. I might even have to do it manually i.e. throw out all
> > commit history and upstream it as my own patches pulled in from diffs.
> I don't have any problems with that.

I'm sure you don't, but it's me that's doing all the hard work. ;)

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/