* [PATCH v2] at91: pmc: Fixed irq's name allocation for programmable clocks
From: Nicolas Ferre @ 2014-02-04 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391502105-24612-1-git-send-email-jjhiblot@traphandler.com>
On 04/02/2014 09:21, Jean-Jacques Hiblot :
> The name provided to request_irq() must be valid until the irq is released.
> This patch stores the name in the internal data structure.
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks. Bye,
> ---
> drivers/clk/at91/clk-programmable.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/at91/clk-programmable.c b/drivers/clk/at91/clk-programmable.c
> index 8e242c7..799b75c 100644
> --- a/drivers/clk/at91/clk-programmable.c
> +++ b/drivers/clk/at91/clk-programmable.c
> @@ -44,6 +44,7 @@ struct clk_programmable {
> u8 css;
> u8 pres;
> u8 slckmck;
> + char irq_name[11];
> const struct clk_programmable_layout *layout;
> };
>
> @@ -247,7 +248,6 @@ at91_clk_register_programmable(struct at91_pmc *pmc, unsigned int irq,
> struct clk_programmable *prog;
> struct clk *clk = NULL;
> struct clk_init_data init;
> - char irq_name[11];
>
> if (id > PROG_ID_MAX)
> return ERR_PTR(-EINVAL);
> @@ -269,9 +269,9 @@ at91_clk_register_programmable(struct at91_pmc *pmc, unsigned int irq,
> prog->irq = irq;
> init_waitqueue_head(&prog->wait);
> irq_set_status_flags(prog->irq, IRQ_NOAUTOEN);
> - snprintf(irq_name, sizeof(irq_name), "clk-prog%d", id);
> + snprintf(prog->irq_name, sizeof(prog->irq_name), "clk-prog%d", id);
> ret = request_irq(prog->irq, clk_programmable_irq_handler,
> - IRQF_TRIGGER_HIGH, irq_name, prog);
> + IRQF_TRIGGER_HIGH, prog->irq_name, prog);
> if (ret)
> return ERR_PTR(ret);
>
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] arm64: Add architecture support for PCI
From: Arnd Bergmann @ 2014-02-04 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqL+3S8w=_Fb-t0rVcq0sDiPSDM6nqn3mR2DHKw=VTffsg@mail.gmail.com>
On Monday 03 February 2014 17:07:48 Rob Herring wrote:
> On Mon, Feb 3, 2014 at 2:05 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> You might want to re-read the SBSA. Unless ARM provides an IP block or
> there is some other standard such as EHCI or AHCI, there is no generic
> implementation. You only have to go look at the Linux EHCI or AHCI
> drivers and see how meaningless and inadequate "use EHCI" is. For PCI,
> the text is so brief in the SBSA there will be no way PCI is going to
> just work given all the variations of root complexes, bridges, address
> windows, etc. we typically see on ARM platforms. I could be wrong and
> some AML magic will solve all the problems.
I don't think you need any AML, and SBSA seems to cover the PCI case
just fine, though I have to agree that the EHCI/AHCI/xHCI part is
rather ambiguous. What the existing PCI host controller drivers do is
essentially:
1. provide a config space access method
2. set up the I/O and memory address windows
3. set up clocks, PHYs etc
4. work around any deviations from the PCI standard
5. provide an MSI/MSI-X controller
For all I can tell, any SBSA compliant system should handle
those four like this:
1. config space is ECAM compliant, we only need to pass the
location in DT. (SBSA 8.1)
2. all address windows are set up by the boot loader, we only
need to know the location (IMHO this should be the
preferred way to do things regardless of SBSA).
3. any external hardware dependencies are set up statically
by the boot loader and are operational as we enter the
kernel.
4. deviations from PCI are not allowed (SBSA 8.8)
5. MSI has to be handled by GICv3 (SBSA 8.3.2)
So I definitely expect SBSA compliant systems to work fine with a
very simple generic PCI host bridge driver (which is likely what
Liviu has implemented and waiting for approval to submit).
The more important question is what systems will actually be
compliant with the above. X-Gene manages to get all five wrong,
for instance, and so would any system that reuses the existing
PCI hardware (alphabetically: exynos, imx6, mvebu, rcar-gen2,
tegra, designware), although points 2 and 3 are a question of
the boot loader, and it's possible that the designware based ones
get point 4 right.
Arnd
^ permalink raw reply
* [PATCH 1/2] clocksource: sunxi: Add new compatibles
From: Maxime Ripard @ 2014-02-04 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EFF96A.1020302@linaro.org>
Hi,
On Mon, Feb 03, 2014 at 09:17:46PM +0100, Daniel Lezcano wrote:
> On 02/03/2014 08:45 PM, Maxime Ripard wrote:
> >Hi Daniel,
> >
> >(Adding DT mailing-list in CC)
> >
> >On Mon, Feb 03, 2014 at 05:36:03PM +0100, Daniel Lezcano wrote:
> >>On 02/02/2014 02:37 PM, Maxime Ripard wrote:
> >>>The Allwinner A10 compatibles were following a slightly different compatible
> >>>patterns than the rest of the SoCs for historical reasons. Add compatibles
> >>>matching the other pattern to the timer driver for consistency, and keep the
> >>>older one for backward compatibility.
> >>
> >>Hi Maxime,
> >>
> >>is it really needed to keep the old pattern ?
> >
> >We agreed during the ARM Kernel Summit to consider the DT as a stable
> >ABI.
> >
> >While I'd be ok with removing the older ones, that also means that we
> >would break the boot of newer kernels with older DT, so yes, we
> >actually need to keep the old compatibles.
>
> Thanks for the clarification.
>
> So these old compatibles will stay there 'ad vitam aeternam', right ?
Except for what Rob told, yep, that was my feeling, but Gregory and I
seem to have a different interpretation of this rule :)
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/418b5e4f/attachment-0001.sig>
^ permalink raw reply
* [PATCH] arm64: Add architecture support for PCI
From: Arnd Bergmann @ 2014-02-04 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140203213658.GA24036@e106497-lin.cambridge.arm.com>
On Monday 03 February 2014 21:36:58 Liviu Dudau wrote:
> On Mon, Feb 03, 2014 at 08:05:56PM +0000, Arnd Bergmann wrote:
> > On Monday 03 February 2014 19:18:38 Liviu Dudau wrote:
> > > So ... defining it should mean no legacy ISA devices, right?
> >
> > I would read that comment as referring to systems that don't have
> > any I/O space. If you have PCI, you can by definition have ISA
> > compatible devices behind a bridge. A typical example would be
> > a VGA card that supports the 03c0-03df port range.
>
> But if you have PCI and don't want to support ISA do you have /dev/port? I guess yes.
Right, that is my interpretation. You could still have a tool
that tries to poke /dev/port from user space for any I/O BAR
the same way you'd use /dev/mem for memory BARs of PCI devices.
It's discouraged, but it's often the easiest solution for
a quick hack, and I'd expect tools to use this.
> > > > > #define IO_SPACE_LIMIT 0xffff
> > > >
> > > > You probably want to increase this a bit, to allow multiple host bridges
> > > > to have their own I/O space.
> > >
> > > OK, but to what size?
> >
> > 2 MB was a compromise on arm32 to allow up to 32 PCI host bridges but not
> > take up too much virtual space. On arm64 it should be at least as big.
> > Could be more than that, although I don't see a reason why it should be,
> > unless we expect to see systems with tons of host bridges, or buses
> > that exceed 64KB of I/O space.
>
> I will increase the size to 2MB for v2.
Thinking about this some more, I'd go a little higher. In case of
pci_mv, we already register a 1MB region for one logical host
(which has multiple I/O spaces behind an emulated bridge), so
going to 16MB or more would let us handle multiple 1MB windows
for some amount of future proofing.
Maybe Catalin can assign us some virtual address space to use,
with the constraints that it should be 16MB or more in an
area that doesn't require additional kernel page table pages.
> > > > > +#define ioport_map(port, nr) (PCI_IOBASE + ((port) & IO_SPACE_LIMIT))
> > > > > +#define ioport_unmap(addr)
> > > >
> > > > inline functions?
> > >
> > > Will do, thanks!
> >
> > I suppose you can actually use the generic implementation from
> > asm-generic/io.h, and fix it by using the definition you have
> > above, since it's currently broken.
>
> Not exactly broken, but it makes the assumption that your IO space starts at
> physical address zero and you have not remapped it. It does guard the
> definition with #ifndef CONFIG_GENERIC_IOMAP after all, so it does not
> expect to be generic :)
Well, I/O space never starts at physical zero in reality, so it is
broken in practice. The CONFIG_GENERIC_IOMAP option tries to solve
the problem of I/O spaces that are not memory mapped, which is
actually quite rare (x86, ia64, some rare powerpc bridges, and possibly
Alpha). The norm is that if you have I/O space, it is memory mapped
and you don't need GENERIC_IOMAP. I think most of the architectures
selecting GENERIC_IOMAP have incorrectly copied that from x86.
> > > > > diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
> > > > > new file mode 100644
> > > > > index 0000000..dd084a3
> > > > > --- /dev/null
> > > > > +++ b/arch/arm64/include/asm/pci.h
> > > > > @@ -0,0 +1,35 @@
> > > > > +#ifndef __ASM_PCI_H
> > > > > +#define __ASM_PCI_H
> > > > > +#ifdef __KERNEL__
> > > > > +
> > > > > +#include <linux/types.h>
> > > > > +#include <linux/slab.h>
> > > > > +#include <linux/dma-mapping.h>
> > > > > +
> > > > > +#include <asm/io.h>
> > > > > +#include <asm-generic/pci-bridge.h>
> > > > > +#include <asm-generic/pci-dma-compat.h>
> > > > > +
> > > > > +#define PCIBIOS_MIN_IO 0
> > > > > +#define PCIBIOS_MIN_MEM 0
> > > >
> > > > PCIBIOS_MIN_IO is normally set to 0x1000, to stay out of the ISA range.
> > >
> > > :) No ISA support! (Die ISA, die!!)
> >
> > If only it were that easy.
>
> Lets try! :)
>
> I wonder how many active devices that have an ISA slot are still supported
> by mainline kernel.
This is missing the point, but any architecture that has a PCI
slot can have an ISA device behind a bridge like this:
http://www.altera.com/products/ip/iup/pci/m-eur-pci-to-isa.html
The real reason is that a lot of PCI cards for practical reasons
expose some non-relocatable memory and I/O BARs in ISA-compatible
locations. Looking at /proc/ioports on my PC, I can spot a couple
of things that may well show up on any ARM machine:
0000-03af : PCI Bus 0000:00
02f8-02ff : serial
03c0-03df : PCI Bus 0000:40
03c0-03df : PCI Bus 0000:00
03c0-03df : vga+
03e0-0cf7 : PCI Bus 0000:00
03e8-03ef : serial
03f8-03ff : serial
0b00-0b0f : pnp 00:08
0b00-0b07 : piix4_smbus
0b20-0b3f : pnp 00:08
0b20-0b27 : piix4_smbus
0ca2-0ca3 : pnp 00:08
0ca2-0ca2 : ipmi_si
0ca3-0ca3 : ipmi_si
0cf8-0cff : PCI conf1
Nothing wrong with the above. Now, it's also possible that
someone decides to build an ARM server by using a PC south
bridge with integrated legacy PC peripherals, such as these:
0000-03af : PCI Bus 0000:00
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0064-0064 : keyboard
0070-0071 : rtc0
0080-008f : dma page reg
00a0-00a1 : pic2
00b0-00b0 : APEI ERST
00c0-00df : dma2
00f0-00ff : fpu
There is some hope that it won't happen, but these things
exist and come with a regular PCIe front-end bus in some
cases.
Finally, there is the LPC bus, which can give you additional
ISAPnP compatible devices.
> I will update PCIBIOS_MIN_xxxx to match arch/arm for v2.
Ok.
> > > > > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> > > > > new file mode 100644
> > > > > index 0000000..7b652cf
> > > > > --- /dev/null
> > > > > +++ b/arch/arm64/kernel/pci.c
> > > > > @@ -0,0 +1,112 @@
> > > >
> > > > None of this looks really arm64 specific, nor should it be. I think
> > > > we should try a little harder to move this as a default implementation
> > > > into common code, even if we start out by having all architectures
> > > > override it.
> > >
> > > Agree. This is the RFC version. I didn't dare to post a patch with fixes
> > > for all architectures. :)
> >
> > No need to change the other architectures. You can make it opt-in for
> > now and just put the code into a common location.
> >
> > An interesting question however is what the transition plan is to
> > have the code shared between arm32 and arm64: We will certainly need
> > to share at least the dw-pcie and the generic SBSA compliant pci
> > implementation.
>
> My vote would be for updating the host controllers to the new API and
> to offer the CONFIG option to choose between arch APIs. The alternative
> is to use the existing API to wrap the generic implementation.
The problem with an either/or CONFIG option is that it breaks
multiplatform support. A lot of the arm32 PCI implementations
are only used on platforms that are not multiplatform enabled
though, so we could get away by requiring all multiplatform
configurations to use the new API.
> My main concern with the existing API is the requirement to have a subsys_initcall
> in your host bridge or mach code, due to the way the initialisation is done (you
> need the DT code to probe your driver, but you cannot start the scanning of the
> PCI bus until the arch code is initialised, so it gets deferred via
> subsys_initcall when it calls pci_common_init). I bet that if one tries to
> instantiate a Tegra PCI host bridge controller on a Marvell platform things will
> break pretty quickly (random example here).
I'm not following here. All the new host controller drivers should
be platform drivers that only bind to the host devices in DT
that are present. Both mvebu and tegra use a normal "module_platform_driver"
for initialization, not a "subsys_initcall".
> > Something like this (coded in mail client, don't try to compile):
> >
> > #define IO_SPACE_PAGES (IO_SPACE_LIMIT + 1) / PAGE_SIZE)
> > static DECLARE_BITMAP(pci_iospace, IO_SPACE_PAGES);
> > unsigned long pci_ioremap_io(const struct resource *bus, const struct resource phys)
> > {
> > unsigned long start, len, virt_start;
> > int error;
> >
> > /* use logical address == bus address if possible */
> > start = bus->start / PAGE_SIZE;
> > if (start > IO_SPACE_LIMIT / PAGE_SIZE)
> > start = 0;
> >
> > /*
> > * try finding free space for the whole size first,
> > * fall back to 64K if not available
> > */
> > len = min(resource_size(bus), resource_size(phys);
> > start = bitmap_find_next_zero_area(pci_iospace, IO_SPACE_PAGES,
> > start, len / PAGE_SIZE, 0);
> > if (start == IO_SPACE_PAGES && len > SZ_64K)
> > len = SZ_64K;
> > start = 0;
> > start = bitmap_find_next_zero_area(pci_iospace, IO_SPACE_PAGES,
> > start, len / PAGE_SIZE, 0);
> > }
> >
> > /* no 64K area found */
> > if (start == IO_SPACE_PAGES)
> > return -ENOMEM;
> >
> > /* ioremap physical aperture to virtual aperture */
> > virt_start = start * PAGE_SIZE + (unsigned long)PCI_IOBASE;
> > error = ioremap_page_range(virt_start, virt_start + len,
> > phys->start, __pgprot(PROT_DEVICE_nGnRE));
> > if (error)
> > return error;
> >
> > bitmap_set(start, len / PAGE_SIZE);
> >
> > /* return io_offset */
> > return start * PAGE_SIZE - bus->start;
> > }
> > EXPORT_SYMBOL_GPL(pci_ioremap_io);
> >
> > Arnd
> >
>
> I see. I need to think how this will change the existing code. Current users
> of pci_ioremap_io ask for multiples of SZ_64K offsets regardless of the
> actual need.
Right. I guess we can support both interfaces on ARM32 for the forseeable
future (renaming the new one) and just change the existing implementation
to update the bitmap. Any cross-platform host controller driver would
have to use the new interface however.
Arnd
^ permalink raw reply
* [PATCH v2] at91: pmc: Fixed irq's name allocation for programmable clocks
From: Boris BREZILLON @ 2014-02-04 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391502105-24612-1-git-send-email-jjhiblot@traphandler.com>
Hello JJ,
Sorry for the noise (I added Mike in the CC list).
BTW, thanks for fixing this bug.
Mike, could you take this bug fix for the next 3.14 release ?
Best Regards,
Boris
On 04/02/2014 09:21, Jean-Jacques Hiblot wrote:
> The name provided to request_irq() must be valid until the irq is released.
> This patch stores the name in the internal data structure.
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Acked-by: Boris BREZILLON <b.brezillon@overkiz.com>
> ---
> drivers/clk/at91/clk-programmable.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/at91/clk-programmable.c b/drivers/clk/at91/clk-programmable.c
> index 8e242c7..799b75c 100644
> --- a/drivers/clk/at91/clk-programmable.c
> +++ b/drivers/clk/at91/clk-programmable.c
> @@ -44,6 +44,7 @@ struct clk_programmable {
> u8 css;
> u8 pres;
> u8 slckmck;
> + char irq_name[11];
> const struct clk_programmable_layout *layout;
> };
>
> @@ -247,7 +248,6 @@ at91_clk_register_programmable(struct at91_pmc *pmc, unsigned int irq,
> struct clk_programmable *prog;
> struct clk *clk = NULL;
> struct clk_init_data init;
> - char irq_name[11];
>
> if (id > PROG_ID_MAX)
> return ERR_PTR(-EINVAL);
> @@ -269,9 +269,9 @@ at91_clk_register_programmable(struct at91_pmc *pmc, unsigned int irq,
> prog->irq = irq;
> init_waitqueue_head(&prog->wait);
> irq_set_status_flags(prog->irq, IRQ_NOAUTOEN);
> - snprintf(irq_name, sizeof(irq_name), "clk-prog%d", id);
> + snprintf(prog->irq_name, sizeof(prog->irq_name), "clk-prog%d", id);
> ret = request_irq(prog->irq, clk_programmable_irq_handler,
> - IRQF_TRIGGER_HIGH, irq_name, prog);
> + IRQF_TRIGGER_HIGH, prog->irq_name, prog);
> if (ret)
> return ERR_PTR(ret);
>
^ permalink raw reply
* [PATCH 1/2] clocksource: sunxi: Add new compatibles
From: Maxime Ripard @ 2014-02-04 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJuSS1Hh8Fb26PMKBB_uKmLuiqnZJjz0zvt1Ux7P8cCzw@mail.gmail.com>
Hi Rob,
On Mon, Feb 03, 2014 at 02:11:28PM -0600, Rob Herring wrote:
> On Mon, Feb 3, 2014 at 1:45 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi Daniel,
> >
> > (Adding DT mailing-list in CC)
> >
> > On Mon, Feb 03, 2014 at 05:36:03PM +0100, Daniel Lezcano wrote:
> >> On 02/02/2014 02:37 PM, Maxime Ripard wrote:
> >> >The Allwinner A10 compatibles were following a slightly different compatible
> >> >patterns than the rest of the SoCs for historical reasons. Add compatibles
> >> >matching the other pattern to the timer driver for consistency, and keep the
> >> >older one for backward compatibility.
> >>
> >> Hi Maxime,
> >>
> >> is it really needed to keep the old pattern ?
> >
> > We agreed during the ARM Kernel Summit to consider the DT as a stable
> > ABI.
> >
> > While I'd be ok with removing the older ones, that also means that we
> > would break the boot of newer kernels with older DT, so yes, we
> > actually need to keep the old compatibles.
>
> It all depends if that would really cause problems for a given
> platform. So if Allwinner DT support is a moving target, then changing
> is probably okay. For example, if anyone using the platform is going
> to need to update their DTB to add more nodes to get various features
> anyway, then breaking it is not all that important.
We keep adding new stuff to the DT, yes, so I guess we can be
considered a moving target. Thanks for your input!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140204/b4f57920/attachment.sig>
^ permalink raw reply
* [PATCH v2] at91: pmc: Fixed irq's name allocation for programmable clocks
From: Boris BREZILLON @ 2014-02-04 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391502105-24612-1-git-send-email-jjhiblot@traphandler.com>
On 04/02/2014 09:21, Jean-Jacques Hiblot wrote:
> The name provided to request_irq() must be valid until the irq is released.
> This patch stores the name in the internal data structure.
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Acked-by: Boris BREZILLON <b.brezillon@overkiz.com>
> ---
> drivers/clk/at91/clk-programmable.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/at91/clk-programmable.c b/drivers/clk/at91/clk-programmable.c
> index 8e242c7..799b75c 100644
> --- a/drivers/clk/at91/clk-programmable.c
> +++ b/drivers/clk/at91/clk-programmable.c
> @@ -44,6 +44,7 @@ struct clk_programmable {
> u8 css;
> u8 pres;
> u8 slckmck;
> + char irq_name[11];
> const struct clk_programmable_layout *layout;
> };
>
> @@ -247,7 +248,6 @@ at91_clk_register_programmable(struct at91_pmc *pmc, unsigned int irq,
> struct clk_programmable *prog;
> struct clk *clk = NULL;
> struct clk_init_data init;
> - char irq_name[11];
>
> if (id > PROG_ID_MAX)
> return ERR_PTR(-EINVAL);
> @@ -269,9 +269,9 @@ at91_clk_register_programmable(struct at91_pmc *pmc, unsigned int irq,
> prog->irq = irq;
> init_waitqueue_head(&prog->wait);
> irq_set_status_flags(prog->irq, IRQ_NOAUTOEN);
> - snprintf(irq_name, sizeof(irq_name), "clk-prog%d", id);
> + snprintf(prog->irq_name, sizeof(prog->irq_name), "clk-prog%d", id);
> ret = request_irq(prog->irq, clk_programmable_irq_handler,
> - IRQF_TRIGGER_HIGH, irq_name, prog);
> + IRQF_TRIGGER_HIGH, prog->irq_name, prog);
> if (ret)
> return ERR_PTR(ret);
>
^ permalink raw reply
* [PATCH v2] at91: pmc: Fixed irq's name allocation for programmable clocks
From: Jean-Jacques Hiblot @ 2014-02-04 8:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391445961-20755-1-git-send-email-jjhiblot@traphandler.com>
The name provided to request_irq() must be valid until the irq is released.
This patch stores the name in the internal data structure.
Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
---
drivers/clk/at91/clk-programmable.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/at91/clk-programmable.c b/drivers/clk/at91/clk-programmable.c
index 8e242c7..799b75c 100644
--- a/drivers/clk/at91/clk-programmable.c
+++ b/drivers/clk/at91/clk-programmable.c
@@ -44,6 +44,7 @@ struct clk_programmable {
u8 css;
u8 pres;
u8 slckmck;
+ char irq_name[11];
const struct clk_programmable_layout *layout;
};
@@ -247,7 +248,6 @@ at91_clk_register_programmable(struct at91_pmc *pmc, unsigned int irq,
struct clk_programmable *prog;
struct clk *clk = NULL;
struct clk_init_data init;
- char irq_name[11];
if (id > PROG_ID_MAX)
return ERR_PTR(-EINVAL);
@@ -269,9 +269,9 @@ at91_clk_register_programmable(struct at91_pmc *pmc, unsigned int irq,
prog->irq = irq;
init_waitqueue_head(&prog->wait);
irq_set_status_flags(prog->irq, IRQ_NOAUTOEN);
- snprintf(irq_name, sizeof(irq_name), "clk-prog%d", id);
+ snprintf(prog->irq_name, sizeof(prog->irq_name), "clk-prog%d", id);
ret = request_irq(prog->irq, clk_programmable_irq_handler,
- IRQF_TRIGGER_HIGH, irq_name, prog);
+ IRQF_TRIGGER_HIGH, prog->irq_name, prog);
if (ret)
return ERR_PTR(ret);
--
1.8.5.2
^ permalink raw reply related
* [PATCH 1/2] clocksource: sunxi: Add new compatibles
From: Gregory CLEMENT @ 2014-02-04 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EFF96A.1020302@linaro.org>
Hi Daniel,
On 03/02/2014 21:17, Daniel Lezcano wrote:
> On 02/03/2014 08:45 PM, Maxime Ripard wrote:
>> Hi Daniel,
>>
>> (Adding DT mailing-list in CC)
>>
>> On Mon, Feb 03, 2014 at 05:36:03PM +0100, Daniel Lezcano wrote:
>>> On 02/02/2014 02:37 PM, Maxime Ripard wrote:
>>>> The Allwinner A10 compatibles were following a slightly different compatible
>>>> patterns than the rest of the SoCs for historical reasons. Add compatibles
>>>> matching the other pattern to the timer driver for consistency, and keep the
>>>> older one for backward compatibility.
>>>
>>> Hi Maxime,
>>>
>>> is it really needed to keep the old pattern ?
>>
>> We agreed during the ARM Kernel Summit to consider the DT as a stable
>> ABI.
>>
>> While I'd be ok with removing the older ones, that also means that we
>> would break the boot of newer kernels with older DT, so yes, we
>> actually need to keep the old compatibles.
>
> Thanks for the clarification.
>
> So these old compatibles will stay there 'ad vitam aeternam', right ?
>From what I have understood during the ARM Kernel Summit, it was
acceptable to remove them after a few release.
Gregory
>
>
>>>> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>>>> ---
>>>> Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt | 5 +++--
>>>> drivers/clocksource/sun4i_timer.c | 4 ++++
>>>> 2 files changed, 7 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
>>>> index 48aeb78..d9e35ae 100644
>>>> --- a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
>>>> +++ b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
>>>> @@ -2,7 +2,8 @@ Allwinner A1X SoCs Timer Controller
>>>>
>>>> Required properties:
>>>>
>>>> -- compatible : should be "allwinner,sun4i-timer"
>>>> +- compatible : should be "allwinner,sun4i-a10-timer"
>>>> + (Deprecated "allwinner,sun4i-timer")
>>>> - reg : Specifies base physical address and size of the registers.
>>>> - interrupts : The interrupt of the first timer
>>>> - clocks: phandle to the source clock (usually a 24 MHz fixed clock)
>>>> @@ -10,7 +11,7 @@ Required properties:
>>>> Example:
>>>>
>>>> timer {
>>>> - compatible = "allwinner,sun4i-timer";
>>>> + compatible = "allwinner,sun4i-a10-timer";
>>>> reg = <0x01c20c00 0x400>;
>>>> interrupts = <22>;
>>>> clocks = <&osc>;
>>>> diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
>>>> index bf497af..de03895 100644
>>>> --- a/drivers/clocksource/sun4i_timer.c
>>>> +++ b/drivers/clocksource/sun4i_timer.c
>>>> @@ -196,5 +196,9 @@ static void __init sun4i_timer_init(struct device_node *node)
>>>> clockevents_config_and_register(&sun4i_clockevent, rate,
>>>> TIMER_SYNC_TICKS, 0xffffffff);
>>>> }
>>>> +CLOCKSOURCE_OF_DECLARE(sun4i, "allwinner,sun4i-a10-timer",
>>>> + sun4i_timer_init);
>>>> +
>>>> +/* Deprecated */
>>>> CLOCKSOURCE_OF_DECLARE(sun4i, "allwinner,sun4i-timer",
>>>> sun4i_timer_init);
>>>>
>>>
>>>
>>> --
>>> <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
>>>
>>> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
>>> <http://twitter.com/#!/linaroorg> Twitter |
>>> <http://www.linaro.org/linaro-blog/> Blog
>>>
>>
>
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 0/8] ARM: shmobile: Conditionally select SMSC_PHY
From: Simon Horman @ 2014-02-04 6:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389084488-25984-1-git-send-email-horms+renesas@verge.net.au>
On Tue, Jan 07, 2014 at 05:48:00PM +0900, Simon Horman wrote:
> Select the SMSC_PHY if ethernet is enabled on shmbile boards
> that have an SMSC phy. This allows the SMSC-specific phy driver
> to be used rather than relying on generic phy code.
>
> Based on the renesas-devel-v3.13-rc7-20140107 tag
> of my renesas tree.
>
> Simon Horman (8):
> ARM: shmobile: ape6evm: Conditionally select SMSC_PHY
> ARM: shmobile: armadillo800eva: Conditionally select SMSC_PHY
> ARM: shmobile: bockw: Sort Kconfig node's selections
> ARM: shmobile: bockw: Conditionally select SMSC_PHY
> ARM: shmobile: kzm9d: Conditionally select SMSC_PHY
> ARM: shmobile: kzm9g: Conditionally select SMSC_PHY
> ARM: shmobile: mackerel: Conditionally select SMSC_PHY
> ARM: shmobile: marzen: Conditionally select SMSC_PHY
>
> arch/arm/mach-shmobile/Kconfig | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
To my surprise I have discovered that the bockw and kzm9g boards
do not boot using NFS root if SMSC_PHY enabled. I have dropped
the SMSC_PHY patches for those boards pending investigation.
^ permalink raw reply
* [PATCH] regulator: core: Make regulator object reflect configured voltage
From: Bjorn Andersson @ 2014-02-04 5:54 UTC (permalink / raw)
To: linux-arm-kernel
In the case when a regulator is initialized from DT with equal min and max
voltages the voltage is applied on initialization and future calls to
regulator_set_voltage fails. This behavious is different than if the regulator
is configured to be a span and therefor requires logic to handle this
difference in the consumer driver.
Eliminate this difference by populating the min_uV and max_uV of the newly
created regulator from the constraints so that calles to regulator_set_voltage
is considered no-ops and not a failure.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
---
drivers/regulator/core.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index d85f313..9c82d37 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1209,6 +1209,16 @@ static struct regulator *create_regulator(struct regulator_dev *rdev,
_regulator_is_enabled(rdev))
regulator->always_on = true;
+ /*
+ * Make the regulator reflect the configured voltage selected in
+ * machine_constraints_voltage()
+ */
+ if (rdev->constraints->apply_uV &&
+ rdev->constraints->min_uV == rdev->constraints->max_uV) {
+ regulator->min_uV = rdev->constraints->min_uV;
+ regulator->max_uV = rdev->constraints->min_uV;
+ }
+
mutex_unlock(&rdev->mutex);
return regulator;
overflow_err:
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
From: Vinod Koul @ 2014-02-04 5:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+mB=1LyX0_VVXZQ-=m3gR2RBeumLrnPTUW3j+Zm1nj7a4exHg@mail.gmail.com>
On Fri, Jan 31, 2014 at 12:22:52PM +0530, Srikanth Thokala wrote:
> >>> >> [...]
> >>> >>> +/**
> >>> >>> + * xilinx_vdma_device_control - Configure DMA channel of the device
> >>> >>> + * @dchan: DMA Channel pointer
> >>> >>> + * @cmd: DMA control command
> >>> >>> + * @arg: Channel configuration
> >>> >>> + *
> >>> >>> + * Return: '0' on success and failure value on error
> >>> >>> + */
> >>> >>> +static int xilinx_vdma_device_control(struct dma_chan *dchan,
> >>> >>> + enum dma_ctrl_cmd cmd, unsigned long arg)
> >>> >>> +{
> >>> >>> + struct xilinx_vdma_chan *chan = to_xilinx_chan(dchan);
> >>> >>> +
> >>> >>> + switch (cmd) {
> >>> >>> + case DMA_TERMINATE_ALL:
> >>> >>> + xilinx_vdma_terminate_all(chan);
> >>> >>> + return 0;
> >>> >>> + case DMA_SLAVE_CONFIG:
> >>> >>> + return xilinx_vdma_slave_config(chan,
> >>> >>> + (struct xilinx_vdma_config *)arg);
> >>> >>
> >>> >> You really shouldn't be overloading the generic API with your own semantics.
> >>> >> DMA_SLAVE_CONFIG should take a dma_slave_config and nothing else.
> >>> >
> >>> > Ok. The driver needs few additional configuration from the slave
> >>> > device like Vertical
> >>> > Size, Horizontal Size, Stride etc., for the DMA transfers, in that case do you
> >>> > suggest me to define a separate dma_ctrl_cmd like the one FSLDMA_EXTERNAL_START
> >>> > defined for Freescale drivers?
> >>>
> >>> In my opinion it is not a good idea to have driver implement a generic API,
> >>> but at the same time let the driver have custom semantics for those API
> >>> calls. It's a bit like having a gpio driver that expects 23 and 42 as the
> >>> values passed to gpio_set_value instead of 0 and 1. It completely defeats
> >>> the purpose of a generic API, namely that you are able to write generic code
> >>> that makes use of the API without having to know about which implementation
> >>> API it is talking to. The dmaengine framework provides the
> >>> dmaengine_prep_interleaved_dma() function to setup two dimensional
> >>> transfers, e.g. take a look at sirf-dma.c or imx-dma.c.
> >>
> >> The question here i think would be waht this device supports? Is the hardware
> >> capable of doing interleaved transfers, then would make sense.
> >>
> >> While we do try to get users use dma_slave_config, but there will always be
> >> someone who have specfic params. If we can generalize then we might want to add
> >> to the dma_slave_config as well
> >
> > There are many configuration parameters which are specific to IP and I
> > would like to
> > give an overview of some of parameteres here:
> >
> > 1) Park Mode ('cfg->park'): In Park mode, engine will park on frame
> > referenced by
> > 'cfg->park_frm', so user will have control on each frame in this mode.
> >
> > 2) Interrupt Coalesce ('cfg->coalesce'): Used for setting interrupt
> > threshold. This value
> > determines the number of frame buffers to process. To use this feature,
> > 'cfg->frm_cnt_en' should be set.
> >
> > 3) Frame Synchronization Source ('cfg->ext_fsync'): Can be an
> > external/internal frame
> > synchronization source. Used to synchronize one channel (MM2S/S2MM) with
> > another (S2MM/MM2S) channel.
> >
> > 4) Genlock Synchronization ('cfg->genlock'): Used to avoid mismatch rate between
> > master and slave. In master mode (cfg->master), frames are not dropped and
> > slave can drop frames to adjust to master frame rate.
> >
> > And in future, this Engine being a soft IP, we could expect some more additional
> > parameters. Isn't a good idea to have a private member in dma_slave_config for
> > sharing additional configuration between slave device and dma engine? Or a new
> > dma_ctrl_cmd like FSLDMA_EXTERNAL_START?
The idea of a generic API is that we can use it for most of the controllers. Even
if you are planning to support a family of controllers
ATM, lets not discuss the possiblity of private member and try to exhanust all
possible options. Worst case you can embed the dma_slave_config in
xilinx_dma_slave_config and retrieve it in dmac driver
--
~Vinod
^ permalink raw reply
* [PATCH] dma: mv_xor: Silence a bunch of LPAE-related warnings
From: Vinod Koul @ 2014-02-04 5:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391476403-26099-1-git-send-email-olof@lixom.net>
On Mon, Feb 03, 2014 at 05:13:23PM -0800, Olof Johansson wrote:
> Enabling some of the mvebu platforms in the multiplatform config for ARM
> enabled these drivers, which also triggered a bunch of warnings when LPAE
> is enabled (thus making phys_addr_t 64-bit).
>
> Most changes are switching printk formats, but also a bit of changes to what
> used to be array-based pointer arithmetic that could just be done with the
> address types instead.
>
> The warnings were:
>
> drivers/dma/mv_xor.c: In function 'mv_xor_tx_submit':
> drivers/dma/mv_xor.c:500:3: warning: format '%x' expects argument of type
> 'unsigned int', but argument 4 has type 'dma_addr_t' [-Wformat]
> drivers/dma/mv_xor.c: In function 'mv_xor_alloc_chan_resources':
> drivers/dma/mv_xor.c:553:13: warning: cast to pointer from integer of
> different size [-Wint-to-pointer-cast]
> drivers/dma/mv_xor.c:555:4: warning: cast from pointer to integer of
> different size [-Wpointer-to-int-cast]
> drivers/dma/mv_xor.c: In function 'mv_xor_prep_dma_memcpy':
> drivers/dma/mv_xor.c:584:2: warning: format '%x' expects argument of type
> 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat]
> drivers/dma/mv_xor.c:584:2: warning: format '%x' expects argument of type
> 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat]
> drivers/dma/mv_xor.c: In function 'mv_xor_prep_dma_xor':
> drivers/dma/mv_xor.c:628:2: warning: format '%u' expects argument of type
> 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat]
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
Acked-by: Vinod Koul <vinod.koul@intel.com>
--
~Vinod
> ---
> drivers/dma/mv_xor.c | 24 ++++++++++++------------
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
> index 53fb0c8365b0..766b68ed505c 100644
> --- a/drivers/dma/mv_xor.c
> +++ b/drivers/dma/mv_xor.c
> @@ -497,8 +497,8 @@ mv_xor_tx_submit(struct dma_async_tx_descriptor *tx)
> if (!mv_can_chain(grp_start))
> goto submit_done;
>
> - dev_dbg(mv_chan_to_devp(mv_chan), "Append to last desc %x\n",
> - old_chain_tail->async_tx.phys);
> + dev_dbg(mv_chan_to_devp(mv_chan), "Append to last desc %pa\n",
> + &old_chain_tail->async_tx.phys);
>
> /* fix up the hardware chain */
> mv_desc_set_next_desc(old_chain_tail, grp_start->async_tx.phys);
> @@ -527,7 +527,8 @@ submit_done:
> /* returns the number of allocated descriptors */
> static int mv_xor_alloc_chan_resources(struct dma_chan *chan)
> {
> - char *hw_desc;
> + void *virt_desc;
> + dma_addr_t dma_desc;
> int idx;
> struct mv_xor_chan *mv_chan = to_mv_xor_chan(chan);
> struct mv_xor_desc_slot *slot = NULL;
> @@ -542,17 +543,16 @@ static int mv_xor_alloc_chan_resources(struct dma_chan *chan)
> " %d descriptor slots", idx);
> break;
> }
> - hw_desc = (char *) mv_chan->dma_desc_pool_virt;
> - slot->hw_desc = (void *) &hw_desc[idx * MV_XOR_SLOT_SIZE];
> + virt_desc = mv_chan->dma_desc_pool_virt;
> + slot->hw_desc = virt_desc + idx * MV_XOR_SLOT_SIZE;
>
> dma_async_tx_descriptor_init(&slot->async_tx, chan);
> slot->async_tx.tx_submit = mv_xor_tx_submit;
> INIT_LIST_HEAD(&slot->chain_node);
> INIT_LIST_HEAD(&slot->slot_node);
> INIT_LIST_HEAD(&slot->tx_list);
> - hw_desc = (char *) mv_chan->dma_desc_pool;
> - slot->async_tx.phys =
> - (dma_addr_t) &hw_desc[idx * MV_XOR_SLOT_SIZE];
> + dma_desc = mv_chan->dma_desc_pool;
> + slot->async_tx.phys = dma_desc + idx * MV_XOR_SLOT_SIZE;
> slot->idx = idx++;
>
> spin_lock_bh(&mv_chan->lock);
> @@ -582,8 +582,8 @@ mv_xor_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
> int slot_cnt;
>
> dev_dbg(mv_chan_to_devp(mv_chan),
> - "%s dest: %x src %x len: %u flags: %ld\n",
> - __func__, dest, src, len, flags);
> + "%s dest: %pad src %pad len: %u flags: %ld\n",
> + __func__, &dest, &src, len, flags);
> if (unlikely(len < MV_XOR_MIN_BYTE_COUNT))
> return NULL;
>
> @@ -626,8 +626,8 @@ mv_xor_prep_dma_xor(struct dma_chan *chan, dma_addr_t dest, dma_addr_t *src,
> BUG_ON(len > MV_XOR_MAX_BYTE_COUNT);
>
> dev_dbg(mv_chan_to_devp(mv_chan),
> - "%s src_cnt: %d len: dest %x %u flags: %ld\n",
> - __func__, src_cnt, len, dest, flags);
> + "%s src_cnt: %d len: %u dest %pad flags: %ld\n",
> + __func__, src_cnt, len, &dest, flags);
>
> spin_lock_bh(&mv_chan->lock);
> slot_cnt = mv_chan_xor_slot_count(len, src_cnt);
> --
> 1.8.4.1.601.g02b3b1d
>
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
^ permalink raw reply
* [PATCH 3/3] Phytec phyFLEX-i.MX6 : Added SATA Support
From: Ashutosh singh @ 2014-02-04 4:35 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for SATA on Phytec phyFLEX-i.MX6 Quad module.
Signed-off-by: Ashutosh singh <ashutosh.s@phytec.in>
---
arch/arm/boot/dts/imx6q-phytec-pbab01.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
index 21c8b37..5607c33 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
+++ b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
@@ -25,6 +25,10 @@
status = "okay";
};
+&sata {
+ status = "okay";
+};
+
&uart4 {
status = "okay";
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/3] Phytec phyFLEX-i.MX6 : Added GPMI-NAND Support
From: Ashutosh singh @ 2014-02-04 4:35 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for GPMI-NAND on Phytec phyFLEX-i.MX6 Quad module.
Signed-off-by: Ashutosh singh <ashutosh.s@phytec.in>
---
arch/arm/boot/dts/imx6q-phytec-pbab01.dts | 4 ++++
arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi | 7 +++++++
2 files changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
index 91aecba..21c8b37 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
+++ b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
@@ -21,6 +21,10 @@
status = "okay";
};
+&gpmi {
+ status = "okay";
+};
+
&uart4 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
index fb39dae..8787101 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
@@ -176,6 +176,13 @@
status = "disabled";
};
+&gpmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpmi_nand_1>;
+ nand-on-flash-bbt;
+ status = "disabled";
+};
+
&uart4 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart4_1>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/3] Phytec phyFLEX-i.MX6 : Added USB_HOST Support
From: Ashutosh singh @ 2014-02-04 4:34 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for USB_HOST on Phytec phyFLEX-i.MX6 Quad module.
Signed-off-by: Ashutosh singh <ashutosh.s@phytec.in>
---
arch/arm/boot/dts/imx6q-phytec-pbab01.dts | 4 ++++
arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi | 15 +++++++++++++++
2 files changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
index 87c3702..91aecba 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
+++ b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
@@ -25,6 +25,10 @@
status = "okay";
};
+&usbh1 {
+ status = "okay";
+};
+
&usbotg {
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
index e682bf8..fb39dae 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
@@ -27,6 +27,15 @@
gpio = <&gpio4 15 0>;
enable-active-low;
};
+
+ reg_usb_h1_vbus: regulator at 1 {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio1 0 0>;
+ enable-active-low;
+ };
};
&ecspi3 {
@@ -144,6 +153,7 @@
MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x80000000 /* SPI NOR chipselect */
MX6QDL_PAD_DI0_PIN15__GPIO4_IO17 0x80000000 /* PMIC interrupt */
MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x80000000 /* USB_OTG_PWR_EN */
+ MX6QDL_PAD_GPIO_0__USB_H1_PWR 0x80000000 /* USB_H1_PWR_EN */
>;
};
};
@@ -172,6 +182,11 @@
status = "disabled";
};
+&usbh1 {
+ vbus-supply = <®_usb_h1_vbus>;
+ status = "disabled";
+};
+
&usbotg {
vbus-supply = <®_usb_otg_vbus>;
pinctrl-names = "default";
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2] Phytec phyFLEX-i.MX6 : Added USB_OTG Support
From: Ashutosh singh @ 2014-02-04 3:39 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds support for USB_OTG on Phytec phyFLEX-i.MX6 Quad module.
Signed-off-by: Ashutosh singh <ashutosh.s@phytec.in>
---
arch/arm/boot/dts/imx6q-phytec-pbab01.dts | 4 ++++
arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi | 18 ++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
index 7d37ec6..87c3702 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
+++ b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
@@ -25,6 +25,10 @@
status = "okay";
};
+&usbotg {
+ status = "okay";
+};
+
&usdhc2 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
index 1a3b50d..e682bf8 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
@@ -18,6 +18,15 @@
memory {
reg = <0x10000000 0x80000000>;
};
+
+ reg_usb_otg_vbus: regulator at 0 {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio4 15 0>;
+ enable-active-low;
+ };
};
&ecspi3 {
@@ -134,6 +143,7 @@
MX6QDL_PAD_EIM_D23__GPIO3_IO23 0x80000000
MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x80000000 /* SPI NOR chipselect */
MX6QDL_PAD_DI0_PIN15__GPIO4_IO17 0x80000000 /* PMIC interrupt */
+ MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x80000000 /* USB_OTG_PWR_EN */
>;
};
};
@@ -162,6 +172,14 @@
status = "disabled";
};
+&usbotg {
+ vbus-supply = <®_usb_otg_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg_1>;
+ disable-over-current;
+ status = "disabled";
+};
+
&usdhc2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usdhc2_2>;
--
1.7.9.5
^ permalink raw reply related
* a LLC sched domain bug for panda board?
From: Preeti U Murthy @ 2014-02-04 3:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKfTPtBV0cSALdVcMsnGHwQPoNCEp5CXQGg36ZAgK7kWJ6gaMQ@mail.gmail.com>
Hi Alex, Vincent,
On 02/04/2014 02:10 AM, Vincent Guittot wrote:
> Yes, it's probably worth enabling by default for all ARM arch.
>
> Vincent
>
> On 02/04/2014 12:28 AM, Vincent Guittot wrote:
>> On 3 February 2014 17:27, Vincent Guittot <vincent.guittot@linaro.org>
> wrote:
>>> Have you checked that CONFIG_SCHED_LC is set ?
>>
>> sorry it's CONFIG_SCHED_MC
>
> Thanks for reminder! no it wasn't set. Does it means
> arch/arm/configs/omap2plus_defconfig need add this config?
Hmm..ok let me think this aloud. So looks like the SMT,MC and the NUMA
sched domains are optional depending on the architecture. They are
config dependent. These domains could potentially exist on the processor
layout, but if the respective CONFIG options are not set, the scheduler
could very well ignore these levels.
What this means is that although the architecture could populate the
cpu_sibling_mask and cpu_coregroup_mask, the scheduler is not mandated
to schedule across the SMT and MC levels of the topology.
Its just the CPU sched domain which is guaranteed to be present no
matter what.
This is indeed interesting to note :) Thanks Alex for bringing up this
point :)
On PowerPC, the SCHED_MC option can never be set. Its not even optional.
On x86, it is on by default and on arm looks like its off by default.
Thanks,
Regards
Preeti U Murthy
>
>>
>>>
>>>
>>> On 3 February 2014 17:17, Alex Shi <alex.shi@linaro.org> wrote:
>>>> I just run the 3.14-rc1 kernel on panda board. The only domain for it is
>>>> 'CPU' domain, but this domain has no SD_SHARE_PKG_RESOURCES setting, it
>>>> has no sd_llc.
>>>>
>>>> Guess the right domain for this board should be MC. So is it a bug?
>>>>
>>>> ..
>>>> /proc/sys/kernel/sched_domain/cpu0/domain0/name:CPU
>>>> ..
>>>> /proc/sys/kernel/sched_domain/cpu1/domain0/name:CPU
>>>>
>>>> --
>>>> Thanks
>>>> Alex
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
>>>> the body of a message to majordomo at vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>> Please read the FAQ at http://www.tux.org/lkml/
>
> --
> Thanks
> Alex
>
^ permalink raw reply
* [PATCH v3 2/8] ARM: dts: sun7i: Add GMAC clock node to sun7i DTSI
From: Chen-Yu Tsai @ 2014-02-04 3:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140203193431.GD25625@lukather>
On Tue, Feb 4, 2014 at 3:34 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Mon, Feb 03, 2014 at 11:32:20AM +0800, Chen-Yu Tsai wrote:
>> The GMAC uses 1 of 2 sources for its transmit clock, depending on the
>> PHY interface mode. Add both sources as dummy clocks, and as parents
>> to the GMAC clock node.
>>
>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> ---
>> arch/arm/boot/dts/sun7i-a20.dtsi | 28 ++++++++++++++++++++++++++++
>> 1 file changed, 28 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
>> index 1595e9a..fc7f470 100644
>> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
>> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
>> @@ -314,6 +314,34 @@
>> };
>>
>> /*
>> + * The following two are dummy clocks, placeholders used
>> + * on gmac_tx clock. The actual frequency and availability
>> + * depends on the external PHY, operation mode and link
>> + * speed.
>> + */
>
> If it depends on the external PHY, I guess that means it also depends
> on the board, right? Or is the GMAC supposed to always have that clock
> running at 25MHz, no matter what PHY is connected to it?
What I meant in the comment is that we cannot control the actual clock
rate of the TX clock. We can only select the source, and this is what
gmac_tx clock does. It is just a clock mux. The 125MHz and 25MHz clock
rates are used by the clk_set_rate in the stmmac glue layer to do
auto-reparenting.
The board dependent factor is what _type_ of PHY it is using, i.e.
MII, GMII, or RGMII. If it's MII, the PHY should provide the clock.
If it's RGMII, the internal clock would be used. GMII is a mix of
both. The actual clock rate depends on the link speed.
I should rephrase the comment along the lines of:
The following two are dummy clocks, placeholders used in the gmac_tx
clock. The gmac driver will choose one parent depending on the PHY
interface mode, using clk_set_rate auto-reparenting.
The actual TX clock rate is not controlled by the gmac_tx clock.
Cheers
ChenYu
^ permalink raw reply
* [PATCH v3 1/8] clk: sunxi: Add Allwinner A20/A31 GMAC clock unit
From: Chen-Yu Tsai @ 2014-02-04 2:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140203193108.GC25625@lukather>
Hi,
On Tue, Feb 4, 2014 at 3:31 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Mon, Feb 03, 2014 at 11:32:19AM +0800, Chen-Yu Tsai wrote:
>> The Allwinner A20/A31 clock module controls the transmit clock source
>> and interface type of the GMAC ethernet controller. Model this as
>> a single clock for GMAC drivers to use.
>>
>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> ---
>> Documentation/devicetree/bindings/clock/sunxi.txt | 26 +++++++
>> drivers/clk/sunxi/clk-sunxi.c | 83 +++++++++++++++++++++++
>> 2 files changed, 109 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
>> index 0cf679b..f43b4c0 100644
>> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
>> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
>> @@ -37,6 +37,7 @@ Required properties:
>> "allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
>> "allwinner,sun4i-mod0-clk" - for the module 0 family of clocks
>> "allwinner,sun7i-a20-out-clk" - for the external output clocks
>> + "allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
>>
>> Required properties for all clocks:
>> - reg : shall be the control register address for the clock.
>> @@ -50,6 +51,9 @@ Required properties for all clocks:
>> If the clock module only has one output, the name shall be the
>> module name.
>>
>> +For "allwinner,sun7i-a20-gmac-clk", the parent clocks shall be fixed rate
>> +dummy clocks at 25 MHz and 125 MHz, respectively. See example.
>> +
>> Clock consumers should specify the desired clocks they use with a
>> "clocks" phandle cell. Consumers that are using a gated clock should
>> provide an additional ID in their clock property. This ID is the
>> @@ -96,3 +100,25 @@ mmc0_clk: clk at 01c20088 {
>> clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
>> clock-output-names = "mmc0";
>> };
>> +
>> +mii_phy_tx_clk: clk at 2 {
>> + #clock-cells = <0>;
>> + compatible = "fixed-clock";
>> + clock-frequency = <25000000>;
>> + clock-output-names = "mii_phy_tx";
>> +};
>> +
>> +gmac_int_tx_clk: clk at 3 {
>> + #clock-cells = <0>;
>> + compatible = "fixed-clock";
>> + clock-frequency = <125000000>;
>> + clock-output-names = "gmac_int_tx";
>> +};
>> +
>> +gmac_clk: clk at 01c20164 {
>> + #clock-cells = <0>;
>> + compatible = "allwinner,sun7i-a20-gmac-clk";
>> + reg = <0x01c20164 0x4>;
>> + clocks = <&mii_phy_tx_clk>, <&gmac_int_tx_clk>;
>
> You should also document in which order you expect the parents to
> be. Or it will probably be easier to just use clock-names here.
Is it not clear from the "Required properties" section above?
>
>> + clock-output-names = "gmac";
>> +};
>> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
>> index 736fb60..0b361d2 100644
>> --- a/drivers/clk/sunxi/clk-sunxi.c
>> +++ b/drivers/clk/sunxi/clk-sunxi.c
>> @@ -379,6 +379,89 @@ static void sun7i_a20_get_out_factors(u32 *freq, u32 parent_rate,
>>
>>
>> /**
>> + * sun7i_a20_gmac_clk_setup - Setup function for A20/A31 GMAC clock module
>> + *
>> + * This clock looks something like this
>> + * ________________________
>> + * MII TX clock from PHY >-----|___________ _________|----> to GMAC core
>> + * GMAC Int. RGMII TX clk >----|___________\__/__gate---|----> to PHY
>> + * Ext. 125MHz RGMII TX clk >--|__divider__/ |
>> + * |________________________|
>> + *
>> + * The external 125 MHz reference is optional, i.e. GMAC can use its
>> + * internal TX clock just fine. The A31 GMAC clock module does not have
>> + * the divider controls for the external reference.
>> + *
>> + * To keep it simple, let the GMAC use either the MII TX clock for MII mode,
>> + * and its internal TX clock for GMII and RGMII modes. The GMAC driver should
>> + * select the appropriate source and gate/ungate the output to the PHY.
>> + *
>> + * Only the GMAC should use this clock. Altering the clock so that it doesn't
>> + * match the GMAC's operation parameters will result in the GMAC not being
>> + * able to send traffic out. The GMAC driver should set the clock rate and
>> + * enable/disable this clock to configure the required state. The clock
>> + * driver then responds by auto-reparenting the clock.
>> + */
>> +
>> +#define SUN7I_A20_GMAC_GPIT 2
>> +#define SUN7I_A20_GMAC_MASK 0x3
>> +#define SUN7I_A20_GMAC_MAX_PARENTS 2
>> +
>> +static void __init sun7i_a20_gmac_clk_setup(struct device_node *node)
>> +{
>> + struct clk *clk;
>> + struct clk_mux *mux;
>> + struct clk_gate *gate;
>> + const char *clk_name = node->name;
>> + const char *parents[SUN7I_A20_GMAC_MAX_PARENTS];
>> + void *reg;
>> + int i = 0;
>> +
>> + /* allocate mux and gate clock structs */
>> + mux = kzalloc(sizeof(struct clk_mux), GFP_KERNEL);
>> + if (!mux)
>> + return;
>
> Newline.
>
>> + gate = kzalloc(sizeof(struct clk_gate), GFP_KERNEL);
>> + if (!gate) {
>> + kfree(mux);
>> + return;
>> + }
>> +
>> + reg = of_iomap(node, 0);
>
> You should check for the return code here.
>
>> + of_property_read_string(node, "clock-output-names", &clk_name);
>
> And here too, since you made the clock-output-names property mandatory
>
>> + while (i < SUN7I_A20_GMAC_MAX_PARENTS &&
>> + (parents[i] = of_clk_get_parent_name(node, i)) != NULL)
>
> You should check for an error here too, but if you switch to using
> clock-names, that will probably be refactored anyway.
>
>> + i++;
>> +
>> + /* set up gate and fixed rate properties */
>> + gate->reg = reg;
>> + gate->bit_idx = SUN7I_A20_GMAC_GPIT;
>> + gate->lock = &clk_lock;
>> + mux->reg = reg;
>> + mux->mask = SUN7I_A20_GMAC_MASK;
>> + mux->flags = CLK_MUX_INDEX_BIT;
>> + mux->lock = &clk_lock;
>> +
>> + clk = clk_register_composite(NULL, clk_name,
>> + parents, i,
>> + &mux->hw, &clk_mux_ops,
>> + NULL, NULL,
>> + &gate->hw, &clk_gate_ops,
>> + 0);
>> +
>> + if (!IS_ERR(clk)) {
>> + of_clk_add_provider(node, of_clk_src_simple_get, clk);
>> + clk_register_clkdev(clk, clk_name, NULL);
>> + }
>> +}
>> +CLK_OF_DECLARE(sun7i_a20_gmac, "allwinner,sun7i-a20-gmac-clk",
>> + sun7i_a20_gmac_clk_setup);
>> +
>> +
>> +
>> +/**
>> * sunxi_factors_clk_setup() - Setup function for factor clocks
>> */
>>
>> --
>> 1.9.rc1
>>
>
> It looks fine otherwise.
I'll fix the rest.
Cheers
ChenYu
^ permalink raw reply
* [RFC/RFT 1/2] ARM: mm: introduce arch hooks for dma address translation routines
From: Olof Johansson @ 2014-02-04 2:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391470107-15927-2-git-send-email-santosh.shilimkar@ti.com>
Hi,
On Mon, Feb 3, 2014 at 3:28 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> Currently arch specific DMA address translation routines can be enabled
> using only defines which makes impossible to use them in with
> multi-platform builds.
>
> Hence, introduce arch specific hooks for DMA address translations
> routines to be compatible with multi-platform builds:
> dma_addr_t (*arch_pfn_to_dma)(struct device *dev, unsigned long pfn);
> unsigned long (*arch_dma_to_pfn)(struct device *dev, dma_addr_t addr);
> void* (*arch_dma_to_virt)(struct device *dev, dma_addr_t addr);
> dma_addr_t (*arch_virt_to_dma)(struct device *dev, void *addr);
>
> In case if architecture won't use it - DMA address translation routines
> will fall-back to existing implementation.
>
> Also, modify machines omap1, ks8695, iop13xx to use new DMA hooks.
[...]
> diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
> index e701a4d..84acc46 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -55,28 +55,16 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
> * functions used internally by the DMA-mapping API to provide DMA
> * addresses. They must not be used by drivers.
> */
> -#ifndef __arch_pfn_to_dma
> -static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
> -{
> - return (dma_addr_t)__pfn_to_bus(pfn);
> -}
>
> -static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
> -{
> - return __bus_to_pfn(addr);
> -}
> +extern dma_addr_t (*__arch_pfn_to_dma)(struct device *dev, unsigned long pfn);
> +extern unsigned long (*__arch_dma_to_pfn)(struct device *dev, dma_addr_t addr);
> +extern void* (*__arch_dma_to_virt)(struct device *dev, dma_addr_t addr);
> +extern dma_addr_t (*__arch_virt_to_dma)(struct device *dev, void *addr);
I tend to prefer having these kind of function pointers grouped in a
struct instead of in the toplevel namespace like this. It allows you
to use a set_<foo>_ops() interface too instead and reduces
exposed/exported internals since only the global struct pointer has to
be exported.
>
> -static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
> -{
> - return (void *)__bus_to_virt((unsigned long)addr);
> -}
I don't actually see any in-tree users of dma_to_virt(). It can
probably be removed.
> -static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
> -{
> - return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
> -}
> +/* Keep __arch_pfn_to_dma defined as it's used by some drivers (V4L2)*/
> +#define __arch_pfn_to_dma __arch_pfn_to_dma
Ick. The v4l driver should be fixed. Marek?
[...]
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 5c43ca5..74111bf 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -39,6 +39,35 @@
>
> #include "mm.h"
>
> +static inline dma_addr_t __pfn_to_dma(struct device *dev, unsigned long pfn)
> +{
> + return (dma_addr_t)__pfn_to_bus(pfn);
> +}
> +
> +static inline unsigned long __dma_to_pfn(struct device *dev, dma_addr_t addr)
> +{
> + return __bus_to_pfn(addr);
> +}
> +
> +static inline void *__dma_to_virt(struct device *dev, dma_addr_t addr)
> +{
> + return (void *)__bus_to_virt((unsigned long)addr);
> +}
> +
> +static inline dma_addr_t __virt_to_dma(struct device *dev, void *addr)
> +{
> + return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
> +}
> +
> +dma_addr_t (*__arch_pfn_to_dma)(struct device *dev, unsigned long pfn) = __pfn_to_dma;
> +EXPORT_SYMBOL(__arch_pfn_to_dma);
> +unsigned long (*__arch_dma_to_pfn)(struct device *dev, dma_addr_t addr) = __dma_to_pfn;
> +EXPORT_SYMBOL(__arch_dma_to_pfn);
> +void* (*__arch_dma_to_virt)(struct device *dev, dma_addr_t addr) = __dma_to_virt;
> +EXPORT_SYMBOL(__arch_dma_to_virt);
> +dma_addr_t (*__arch_virt_to_dma)(struct device *dev, void *addr) = __virt_to_dma;
> +EXPORT_SYMBOL(__arch_virt_to_dma);
Independent on whether someone objects to my preference of exporting a
struct, these (or that struct pointer) should probably be
EXPORT_SYMBOL_GPL().
-Olof
^ permalink raw reply
* [PATCH] security: select correct default LSM_MMAP_MIN_ADDR on arm on arm64
From: Colin Cross @ 2014-02-04 2:15 UTC (permalink / raw)
To: linux-arm-kernel
Binaries compiled for arm may run on arm64 if CONFIG_COMPAT is
selected. Set LSM_MMAP_MIN_ADDR to 32768 if ARM64 && COMPAT to
prevent selinux failures launching 32-bit static executables that
are mapped at 0x8000.
Signed-off-by: Colin Cross <ccross@android.com>
---
security/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/Kconfig b/security/Kconfig
index e9c6ac724fef..beb86b500adf 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -103,7 +103,7 @@ config INTEL_TXT
config LSM_MMAP_MIN_ADDR
int "Low address space for LSM to protect from user allocation"
depends on SECURITY && SECURITY_SELINUX
- default 32768 if ARM
+ default 32768 if ARM || (ARM64 && COMPAT)
default 65536
help
This is the portion of low virtual memory which should be protected
--
1.9.0.rc1.175.g0b1dcb5
^ permalink raw reply related
* [PATCH v5 16/16] ARM: Remove uprobes dependency on kprobes
From: David Long @ 2014-02-04 2:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391442358.3509.19.camel@linaro1.home>
On 02/03/14 10:45, Jon Medhurst (Tixy) wrote:
> On Thu, 2014-01-23 at 15:05 -0500, David Long wrote:
>> From: "David A. Long" <dave.long@linaro.org>
>>
>> Now that arm uprobes support has been made separate from the arm kprobes code
>> the Kconfig can be changed to reflect that.
>>
>> Signed-off-by: David A. Long <dave.long@linaro.org>
>> ---
>> arch/arm/Kconfig | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index fec5a6b..9ddc4ae 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -204,7 +204,6 @@ config NEED_DMA_MAP_STATE
>> def_bool y
>>
>> config ARCH_SUPPORTS_UPROBES
>> - depends on KPROBES
>> def_bool y
>>
>> config ARCH_HAS_DMA_SET_COHERENT_MASK
>
>
> Was this patch meant to have other contents? If not, it seems a bit
> pointless as all it does is remove a line added in the previous patch,
> so should just be folded into that one.
>
That patch was added late to a much earlier rev. It should have been
merged with the previous patch before now. I have just done so.
-dl
^ permalink raw reply
* [PATCH v5 07/16] ARM: Remove use of struct kprobe from generic probes code
From: David Long @ 2014-02-04 2:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391439425.3509.16.camel@linaro1.home>
On 02/03/14 09:57, Jon Medhurst (Tixy) wrote:
> On Thu, 2014-01-23 at 15:05 -0500, David Long wrote:
>> From: "David A. Long" <dave.long@linaro.org>
>>
>> Change the generic ARM probes code to pass in the opcode and architecture-specific
>> structure separately instead of using struct kprobe, so we do not pollute
>> code being used only for uprobes or other non-kprobes instruction
>> interpretation.
>>
>> Signed-off-by: David A. Long <dave.long@linaro.org>
>> ---
>
> One minor nit-pick...
>
> [...]
>> diff --git a/arch/arm/kernel/kprobes-thumb.c b/arch/arm/kernel/kprobes-thumb.c
>> index c7ee290..cea707a 100644
>> --- a/arch/arm/kernel/kprobes-thumb.c
>> +++ b/arch/arm/kernel/kprobes-thumb.c
> [...]
>> @@ -593,7 +590,7 @@ t16_emulate_pop_pc(struct kprobe *p, struct pt_regs *regs)
>> bx_write_pc(pc, regs);
>> }
>>
>> -static enum kprobe_insn __kprobes
>> +enum kprobe_insn __kprobes
>> t16_decode_pop(kprobe_opcode_t insn, struct arch_specific_insn *asi,
>> struct decode_header *d)
>> {
>
> The above removal of 'static' appears to be an unneeded accidental
> change?
>
Yes, that got lost during editing. The change has been made.
-dl
^ permalink raw reply
* [PATCH v5 05/16] ARM: use a function table for determining instruction interpreter action
From: David Long @ 2014-02-04 2:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391437498.3509.11.camel@linaro1.home>
On 02/03/14 09:24, Jon Medhurst (Tixy) wrote:
> On Thu, 2014-01-23 at 15:05 -0500, David Long wrote:
>> From: "David A. Long" <dave.long@linaro.org>
>>
>> Make the instruction interpreter call back to semantic action functions
>> through a function pointer array provided by the invoker. The interpreter
>> decodes the instructions into groups and uses the group number to index
>> into the supplied array. kprobes and uprobes code will each supply their
>> own array of functions.
>>
>> Signed-off-by: David A. Long <dave.long@linaro.org>
>> ---
>
> [...]
>
>> --- a/arch/arm/kernel/probes.c
>> +++ b/arch/arm/kernel/probes.c
>> @@ -378,10 +378,11 @@ static const int decode_struct_sizes[NUM_DECODE_TYPES] = {
>> */
>> int __kprobes
>> kprobe_decode_insn(kprobe_opcode_t insn, struct arch_specific_insn *asi,
>> - const union decode_item *table, bool thumb)
>> + const union decode_item *table, bool thumb,
>> + const union decode_action *actions)
>> {
>> - const struct decode_header *h = (struct decode_header *)table;
>> - const struct decode_header *next;
>> + struct decode_header *h = (struct decode_header *)table;
>> + struct decode_header *next;
>
> The decode tables are fixed structures which nothing should want to
> modify, so I think the const's above should be kept. I believe that
> you've had to resort to changing them because the following typedef
> lacks a 'const' on the final argument....
>
I've made the change.
> [...]
>> diff --git a/arch/arm/kernel/probes.h b/arch/arm/kernel/probes.h
>> index c610fa9..81b6e61 100644
> [...]
>>
>> +typedef enum kprobe_insn (probes_custom_decode_t)(kprobe_opcode_t,
>> + struct arch_specific_insn *,
>> + struct decode_header *);
>> +
>
> Adding 'const' above will also have the knock on effect of requiring
> const on all the 'custom decode' functions as well.
>
I've made those numerous changes as well.
-dl
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox