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] [day] [month] [year] [list]
Message-ID: <CACRpkdaYyoYRg+ZnK1z4n39eO2c+U0uL=Ttsa83S2e6h6=XJag@mail.gmail.com>
Date:	Thu, 1 Nov 2012 19:33:55 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Cc:	Rob Herring <robherring2@...il.com>,
	linux-arm-kernel@...ts.infradead.org,
	Thomas Gleixner <tglx@...utronix.de>, arm@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ARM: plat-versatile: move FPGA irq driver to drivers/irqchip

On Thu, Nov 1, 2012 at 10:12 AM, Thomas Petazzoni
<thomas.petazzoni@...e-electrons.com> wrote:
> On Thu, 1 Nov 2012 10:00:19 +0100, Linus Walleij wrote:
>
>> Sounds like a separate patch but surely we can do this. Is Thomas'
>> stuff on a branch somewhere that I can then rebase upon to get
>> it upstream? I was planning to get this series as such to the
>> ARM SoC maintainers soon-ish.
>
> Not at the moment. But do you want me to put that in a branch, and
> agglomerate all the related patches (posted by Rob for GIC/VIC and by
> you for the FPGA IRQ controller), and then later send a pull request to
> Arnd with those changes?

Whatever I can base on ... I would just push the stuff you consider
stable to ARM SoC as quickly as possible so we can grab it
from there and base development on it. Then each of us can
just request the ARM SoC people to pull it and state that it
is based on that branch so they need to pull it into the same
place.

> Also, again, the whole point of the initial infrastructure in
> drivers/irqchip/ was to avoid adding per-driver header files in
> include/linux/irqchip/, so there should at least be a long term plan on
> how to remove those headers file, either by moving more platforms to
> DT, or my extending the irqchip infrastructure to cover more features.

So the header in this case looks like this:

#ifndef PLAT_FPGA_IRQ_H
#define PLAT_FPGA_IRQ_H

struct device_node;
struct pt_regs;

void fpga_handle_irq(struct pt_regs *regs);
void fpga_irq_init(void __iomem *, const char *, int, int, u32,
                struct device_node *node);
int fpga_irq_of_init(struct device_node *node,
                     struct device_node *parent);

#endif

So this is the stuff that needs to be called from the machine
descriptor, nothing else.

Example:

MACHINE_START(INTEGRATOR, "ARM-Integrator")
        /* Maintainer: ARM Ltd/Deep Blue Solutions Ltd */
        .atag_offset    = 0x100,
        .reserve        = integrator_reserve,
        .map_io         = ap_map_io,
        .init_early     = ap_init_early,
        .init_irq       = ap_init_irq,
        .handle_irq     = fpga_handle_irq,
        .timer          = &ap_timer,
        .init_machine   = ap_init,
        .restart        = integrator_restart,
MACHINE_END

The .init_irq hooks above contain some other stuff apart from just
calling these directly, but the problem remains: how to cross-call
these functions from the machine start since the IRQs are needed
by say the timer and everything else.

include/linux/irqchip/bcm2835.h look exactly the same (just one
function instead of separete DT/non-DT versions) so
there isn't exactly a precedent on how to solve this in an
elegant way.

But maybe your patch set contains the silver bullet that will decouple
this and fix everything?

Then I can do a patch to convert this and the BCM2835 too
probably...

Yours,
Linus Walleij
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ