linux-kernel - Re: [PATCH 02/11] arm: pxa27x: support ICP DAS LP-8x4x

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]

Date:	Fri, 06 Dec 2013 20:38:31 +0400
From:	Sergei Ianovich <ynvich@...il.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Eric Miao <eric.y.miao@...il.com>,
	Russell King <linux@....linux.org.uk>,
	Haojian Zhuang <haojian.zhuang@...il.com>
Subject: Re: [PATCH 02/11] arm: pxa27x: support ICP DAS LP-8x4x

On Fri, 2013-12-06 at 01:40 +0100, Arnd Bergmann wrote:
> On Sunday 01 December 2013, Sergei Ianovich wrote:
> > 
> > diff --git a/arch/arm/configs/lp8x4x_defconfig b/arch/arm/configs/lp8x4x_defconfig
> > new file mode 100644
> > index 0000000..5cd6d38
> > --- /dev/null
> > +++ b/arch/arm/configs/lp8x4x_defconfig
> > @@ -0,0 +1,2320 @@
> > +#
> > +# Automatically generated file; DO NOT EDIT.
> > +# Linux/arm 3.13.0-rc1 Kernel Configuration
> > +#
> 
> Please use 'make savedefconfig' to generate a smaller version of this file.

Done. Updated in v2.

> Ideally we want shared defconfigs where you enable multiple (or all) pxa boards
> at once and end up with a kernel that works on all of them.
> 
> For most other platforms the goal is even to have a shared defconfig across
> SoC families, but PXA is one of the exceptions that I would make because
> it is both old and rather different from even the ARM9 or Marvell Feroceon
> based SoCs.

There is probably no in point sharing this config with most other
devices on PXA2xx SoC. This device is an industrial PC. Its config needs
to be optimized for low latency even by the cost of greater power
consumption. It is not supposed to run on batteries or enter any low
power mode anyway.

> > +#define LP8X4X_FPGA_PHYS     0x17000000
> > +#define LP8X4X_FPGA_VIRT     0xf1000000
> > +#define LP8X4X_P2V(x)                IOMEM((x) - LP8X4X_FPGA_PHYS + LP8X4X_FPGA_VIRT)
> > +#define LP8X4X_V2P(x)                ((x) - LP8X4X_FPGA_VIRT + LP8X4X_FPGA_PHYS)
> 
> I would recommend defining LP8X4X_FPGA_VIRT as "(void *)0xf1000000". Ideally

Done in v2. 

> we try to avoid hardwired virtual addresses entirely and instead use platform
> device resources, but I realize that there are limits to how far you get with
> that. Please make an effort to convert as many parts of the FPGA into platform
> devices with regular resources, but know that we would not enforce this as
> strictly as we do for new platforms.
> 
> > +
> > +static struct irq_chip lp8x4x_irq_chip = {
> > +     .name                   = "FPGA",
> > +     .irq_ack                = lp8x4x_ack_irq,
> > +     .irq_mask               = lp8x4x_mask_irq,
> > +     .irq_unmask             = lp8x4x_unmask_irq,
> > +};
> 
> Please try to move the irqchip code to drivers/irqchip/.

CONFIG_IRQCHIP depends on CONFIG_OF_IRQ which in turn depends on Open
Firmware.

The device is shipped with such a flash device partition table, which
makes migration to device tree rather difficult. The partition for
U-Boot is just 256kiB. This is a high aim already. U-Boot needs to be
compiled without command line help and USB support to fit into this
size. Otherwise the main flash needs to be repartitioned.

Could it be acceptable to accept the device without device tree support?

If so, FPGA irqchip could remain in the machine source file. It is
highly unlikely, it will ever be reused. In this case all fixed virtual
address definitions could be moved to the machine source file. The file
will be the only place where LP8X4X_FPGA_VIRT is used directly.

> > +static struct platform_device lp8x4x_flash_device[] = {
> 
> static platform_device definitions are no longer the way to do this. For
> modern platforms, you'd use a device tree, but here I think it is acceptable
> (because of the PXA exception) to use a hardcoded board file.
> 
> The correct way to create the devices is using platform_device_register_data()
> or a related function that returns a dynamically allocated platform device.

Done in v2. Allocation migrated to use
platform_device_register_resndata() and
platform_device_register_simple().


--
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/