On Monday 11 February 2013 16:48:12 Samuel Ortiz wrote:
>
> > If so, how do you know which transport to use?
> Through the mei_bus_client ops. Device drivers get a mei_bus_client pointer
> from their probe routine and the ops pointers there (If any) are set by
> whoever creates the device. In the
On Friday 08 February 2013, David Sterba wrote:
> On Mon, Feb 04, 2013 at 09:55:50PM +0000, Arnd Bergmann wrote:
> > On Saturday 02 February 2013, Chris Mason wrote:
> >
> > I've done a full backup of all data now, without any further Ooops
> > m
On Monday 11 February 2013, Alexander Shiyan wrote:
> The driver can be used in various subsystems and therefore should not
> be unloaded when it is defined in the kernel configuration, so remove
> support for unloading it.
>
> Signed-off-by: Alexander Shiyan
Can you describe a scenario where th
chal Simek
Acked-by: Arnd Bergmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Tuesday 12 February 2013, Michal Simek wrote:
> > In particular, ARM can run both big- and little-endian even though
> > big-endian is rarely used, so you need to know the endianess for
> > the device you are talking to rather than assume that it knows
> > what the CPU does at the time.
>
> For
On Tuesday 12 February 2013, Benjamin Herrenschmidt wrote:
> It depends how the ARM core operates vs. IO when switched between BE and
> LE, does it keep the same lines doing byte 0 or does it keep the MSB/LSB
> in the same place (and thus changes which lanes contain byte 0) ?
IIRC it changed betwe
On Tuesday 12 February 2013, Alexander Shiyan wrote:
> > On Monday 11 February 2013, Alexander Shiyan wrote:
> > > The driver can be used in various subsystems and therefore should not
> > > be unloaded when it is defined in the kernel configuration, so remove
> > > support for unloading it.
> > >
On Tuesday 12 February 2013, Stephen Rothwell wrote:
> Today's linux-next merge of the arm-soc tree got conflicts in
> drivers/clocksource/Makefile and drivers/clocksource/Kconfig between
> commit 3fedb0674fbc ("metag: Time keeping") from the metag tree and
> commits 8a4da6e36c58 ("arm: arch_timer:
On Tuesday 12 February 2013, Hiroshi Doyu wrote:
> > >>> static void __init paz00_init(void)
> > >>> @@ -129,6 +128,9 @@ static void __init tegra_dt_init_late(void)
> > >>>
> > >>> tegra_init_late();
> > >>>
> > >>> + if (IS_ENABLED(CONFIG_PCI) && IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC))
> > >>
On Tuesday 12 February 2013, Michal Simek wrote:
> ok but still there should be well defined how to do it. Let's say
> generic Kconfig option.
You cannot solve it in a generic way, since every device has different
needs. In a single SoC, you may have one device that only ever exists
with little-en
On Tuesday 12 February 2013, Paul Mundt wrote:
> > While I do get the point... I chatted with Grant about it and
> > I want to talk to some toolchain people about this to see if
> > pointers containing potential error codes can somehow be
> > "flagged" by the compiler so we can enforce error checki
On Tuesday 12 February 2013, Michal Simek wrote:
> But on Microblaze LE is necessary to use different datain/out_le16
> functions as below
> which are also not compatible with Microblaze and PPC BE.
>
> diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c
> index bbad046..8dd192c 100644
On Tuesday 12 February 2013, Stephen Warren wrote:
> > I don't think that's going to help any link issues, so I'd drop it and
> > keep this function simple.
>
> As explained in the above, a complier will drop unnecessary functions
> automatically with this IS_ENABLED(), which
On Tuesday 12 February 2013, Thomas Petazzoni wrote:
> The pcim_*() functions are used by the libata-sff subsystem, and this
> subsystem is used for many SATA drivers on ARM platforms that do not
> necessarily have I/O ports.
>
> Signed-off-by: Thomas Petazzoni
> Cc: Paul Gortmaker
> Cc: Jesse B
On Tuesday 12 February 2013, Stephen Warren wrote:
> I believe U-Boot enabled -ffunction-sections -fdata-sections or similar
> (recently?) to get this kind of behaviour. I wonder why the kernel
> didn't need that. Perhaps -O2 is more aggressive (within a file at
> least) than I thought.
-ffunction
On Tuesday 12 February 2013, Thomas Petazzoni wrote:
> > Any driver that requires a
> > linear mapping of I/O ports to __iomem pointers must depend
> > CONFIG_HAS_IOPORT with the current definition of that symbol (as
> > mentioned before, we should really rename that to
> > CONFIG_HAS_IOPORT_MAP).
On Tuesday 12 February 2013, gre...@linuxfoundation.org wrote:
> >
> > > Please let's find something that makes both hw and Linux happy
> > I still believe it makes sense to use mei_device for what we add to the MEI
> > bus. I'd be fine with mei_bus_device as well, but that would somehow look
> >
On Friday 21 February 2014 17:31:27 Alistair Popple wrote:
>
> +config MMC_SDHCI_OF_476GTR
> + tristate "SDHCI OF support for the IBM PPC476GTR SoC"
> + depends on MMC_SDHCI_PLTFM
> + depends on PPC_OF
> + help
> + This selects the Secure Digital Host Controller Interface (
On Friday 21 February 2014 17:31:29 Alistair Popple wrote:
>
> +static const struct of_device_id ohci_of_match[] = {
> + { .compatible = "usb-ohci", },
> + {},
> +};
> +
> static const struct platform_device_id ohci_platform_table[] = {
> { "ohci-platform", 0 },
> { }
On Friday 21 February 2014 11:48:03 Mark Rutland wrote:
> > +
> > + np = of_find_compatible_node(NULL, NULL, "ibm,usb-ohci-440epx");
> > + if (np != NULL) {
> > + /* claim we really affected by usb23 erratum */
> > + if (!of_address_to_resource(np, 0, &res))
On Friday 21 February 2014 17:31:33 Alistair Popple wrote:
>
> + HSTA0: hsta@31e {
> + compatible = "ibm,476gtr-hsta-msi", "ibm,hsta-msi";
> + reg = <0x310 0x000e 0x0 0xf0>;
> + interrupt-parent = <&MPIC>;
> +
On Friday 21 February 2014 16:50:02 Sylwester Nawrocki wrote:
> config PHY_EXYNOS_DP_VIDEO
> tristate "EXYNOS SoC series Display Port PHY driver"
> depends on OF
> + depends on ARCH_EXYNOS || COMPILE_TEST
> + default y
> select GENERIC_PHY
> help
>
Tha
On Friday 21 February 2014 16:51:07 Michal Simek wrote:
> > |
> > | if (res->flags & IORESOURCE_CACHEABLE)
> > | dest_ptr = devm_ioremap(dev, res->start, size);
> > | else
> > | dest_ptr = devm_ioremap_nocache(dev, res->start, size);
>
> I have read it just not sur
On Friday 21 February 2014 17:25:04 Sylwester Nawrocki wrote:
>
> Hmm, good point, I will modify it that way.
>
> For patch 1/2 I guess it should be:
>
> "default ARCH_S5PV210 || ARCH_EXYNOS"
>
> or rather
>
> "default y if ARCH_S5PV210 || ARCH_EXYNOS" ?
Right. I'd probably use the first synt
On Friday 21 February 2014 17:50:44 Sylwester Nawrocki wrote:
> On 21/02/14 17:41, Arnd Bergmann wrote:
> > On Friday 21 February 2014 17:25:04 Sylwester Nawrocki wrote:
> >> >
> >> > Hmm, good point, I will modify it that way.
> >> &g
On Friday 21 February 2014, Benjamin Herrenschmidt wrote:
> On Fri, 2014-02-21 at 15:33 +0100, Arnd Bergmann wrote:
>
> > > @@ -242,8 +264,10 @@
> > > ranges = <0x0200 0x 0x8000 0x0110
>
On Saturday 22 February 2014, Josh Triplett wrote:
> When !CONFIG_BUG, WARN_ON and family become simple passthroughs of their
> condition argument; however, WARN_ON_ONCE and family still have
> conditions and a boolean to detect one-time invocation, even though the
> warning they'd emit doesn't exi
On Monday 24 February 2014 00:44:37 Josh Triplett wrote:
>
> I agree that allowing BUG() to become a no-op seems suboptimal, if only
> because of the resulting warnings and mis-optimizations. However, I
> think the overhead could be cut down massively, such that BUG() just
> compiles down to a on
---
irqchip: VIC: export vic_init_cascaded
vic_init_cascaded is called by integrator impd1 code that can
be a loadable module, so the function has to be exported.
Signed-off-by: Arnd Bergmann
diff --git a/drivers/irqchip/irq-vic.c b/drivers/irqchip/irq-vic.c
index 6002942..fd2c980 100644
--- a/dri
Hi Magnus,
I noticed during randconfig testing that you enabled DMABOUNCE for the
pci-rcar-gen2 driver as posted in this patch https://lkml.org/lkml/2014/2/5/30
I didn't see the original post unfortunately, but I fear we have to
revert it and come up with a better solution, as your approach seems
On Monday 24 February 2014 12:09:11 David Howells wrote:
> Josh Triplett wrote:
>
> > > This means we actually want BUG() to end with __builtin_unreachable()
> > > as in the CONFIG_BUG=y case, and also ensure it actually is
> > > unreachable. As I have shown in [1], the there is a small overhead
On Monday 24 February 2014 13:16:05 One Thousand Gnomes wrote:
>
> While I agree defining it as do {} while(1); would be a lot smarter,
> simply making it required that a platform provides an implementation of
> BUG() would be even better.
But how do we get there? The majority of architectures d
s single caller.
>
> Signed-off-by: Geert Uytterhoeven
Acked-by: Arnd Bergmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.ht
On Tuesday 25 February 2014, Magnus Damm wrote:
> On Mon, Feb 24, 2014 at 8:00 PM, Arnd Bergmann wrote:
> > * The window base and size in the driver should not be hardcoded, as
> > this is likely not a device specific property but rather an artifact of
> > how it
On Tuesday 25 February 2014, Heiko Stübner wrote:
> Some SoCs need parts of their sram for special purposes. So while being part
> of the peripheral, it should not be part of the genpool controlling the sram.
>
> Therefore add the option to define reserved regions as subnodes of the
> sram-node si
On Tuesday 25 February 2014, Magnus Damm wrote:
> And the DMABOUNCE code does not support HIGHMEM, so because of that
> the block layer BOUNCE is also used.
Ah, I misunderstood this part previously. I understand better what's
going on now, but this also enforces the impression that both BOUNCE
and
On Monday 24 February 2014, Linus Walleij wrote:
> >
> > irqchip: VIC: export vic_init_cascaded
> >
> > vic_init_cascaded is called by integrator impd1 code that can
> > be a loadable module, so the function has to be exported.
> >
> > Signed-off-by: A
On Tuesday 25 February 2014, Kumar Gala wrote:
> The following changes since commit cf1e8f0cd665e2a9966d2bee4e11ecc0938ff166:
>
>ARM: qcom: Rename various msm prefixed functions to qcom (2014-02-06
> 16:20:41 -0600)
>
> are available in the git repository at:
>
>git://git.kernel.org/pub
On Monday 10 February 2014, Thierry Reding wrote:
> On Fri, Jan 24, 2014 at 08:54:16AM +0100, Sascha Hauer wrote:
> > Thierry as PWM maintainer has agreed to take this patch. Would be nice
> > to get some Acks from affected architectures. Russell, Ralf?
>
> No replies for over two weeks and this
On Tuesday 25 February 2014, Christian Daudt wrote:
> Can you please pull the patches below. Note that if you wanto to
> absolutely reduce this to the bone, you can drop the last patch in the
> series titled "pinctrl: Rename Broadcom Capri pinctrl binding". That
> is the documentation fixup, so the
On Friday 07 February 2014, Hans Verkuil wrote:
> On 01/17/2014 11:51 AM, Hans Verkuil wrote:
> >> diff --git a/drivers/media/platform/arv.c b/drivers/media/platform/arv.c
> >> index e346d32d..32f6d70 100644
> >> --- a/drivers/media/platform/arv.c
> >> +++ b/drivers/media/platform/arv.c
> >> @@ -3
On Friday 17 January 2014, Hans Verkuil wrote:
> On 01/02/2014 01:07 PM, Arnd Bergmann wrote:
> > sleep_on and its variants are broken and going away soon. This changes
> > the omap vout driver to use interruptible_sleep_on_timeout instead,
>
> I assume you mean wait_event_
On Monday 17 February 2014 15:54:19 Grant Likely wrote:
> On Wed, 12 Feb 2014 11:20:00 -0700, Jason Gunthorpe
> wrote:
> > On Wed, Feb 12, 2014 at 12:45:54PM -0500, Jason Cooper wrote:
> >
> > > The bootloader would then load this file into ram, and pass the
> > > address/size to the kernel eith
ld go through subsystem maintainer
trees, since we want to start reusing the symbol as soon as possible.
Acked-by: Arnd Bergmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wednesday 12 February 2014, Takahiro Akashi wrote:
> > If I build a large "randconfig" kernel or "allyesconfig", the kernel image
> > size exceeds 32MB, which means I can no longer link callers with a 26
> > bit signed immediate argument like the "bl _mcount" here. For any other
> > function cal
On Wednesday 12 February 2014, Takahiro Akashi wrote:
> Thank you for your comment.
> I'm afraid that I can't do so because how compat syscall numbers
> are named varies from arch to arch. __NR_compat_read is used
> only on arm64, while __NR_ia32_read on x86. On other archs,
> __NR_read is common t
On Wednesday 12 February 2014, Arnd Bergmann wrote:
>
> On Wednesday 12 February 2014, Takahiro Akashi wrote:
> > Thank you for your comment.
> > I'm afraid that I can't do so because how compat syscall numbers
> > are named varies from arch to arch. __NR_com
On Wednesday 12 February 2014, Laura Abbott wrote:
> This is an RFC to seed the random number pool earlier when using devicetree.
> The big issue this is trying to solve is the fact that the stack canary for
> ARM tends to be the same across bootups of the same device. This is because
> the random
g with TI_DAVINCI_EMAC.
>
> Signed-off-by: David Howells
> cc: Russell King
> cc: linux-arm-ker...@lists.infradead.org
Acked-by: Arnd Bergmann
I've added this to my randconfig builder, will let you know when unexpected
bugs show up (probably won't).
Arnd
--
On Wednesday 12 February 2014 12:45:54 Jason Cooper wrote:
> I brought this up at last weeks devicetree irc meeting. My goal is to
> provide early randomness for kaslr on ARM. Currently, my idea is modify
> the init script to save an additional random seed from /dev/urandom to
> /boot/random-seed
On Wednesday 12 February 2014 13:45:21 Jason Cooper wrote:
> On Wed, Feb 12, 2014 at 07:17:41PM +0100, Arnd Bergmann wrote:
> > On Wednesday 12 February 2014 12:45:54 Jason Cooper wrote:
> > > I brought this up at last weeks devicetree irc meeting. My goal is to
> > > p
On Thursday 13 February 2014 17:57:41 Jingoo Han wrote:
> I want to use 'drivers/pci/host/pcie-designware.c' for both arm32
> and arm64, without any code changes. However, it looks impossible.
It is impossible at the moment, and I agree we have to fix that.
> I made 'drivers/pci/host/pcie-designw
On Thursday 13 February 2014 11:53:27 Russell King - ARM Linux wrote:
> On Thu, Feb 13, 2014 at 12:27:05PM +0100, Arnd Bergmann wrote:
> > I would rather get rid of struct hw_pci for architecture independent
> > drivers and add a different registration method on arm32 that is
>
On Friday 14 February 2014 15:54:38 Jisheng Zhang wrote:
> Hi all,
>
> The writel/readl is too expensive especially on Cortex A9 w/ outer L2 cache.
> This
> introduce i2c read/write error on Marvell Berlin SoCs when there are L2 cache
> maintenance operations at the same time.
>
> In our interna
On Friday 14 February 2014, Linus Walleij wrote:
> On Thu, Feb 13, 2014 at 2:17 PM, Lee Jones wrote:
> >> wrote:
> >>
> >> > The DBx500 and ABx500 should be getting their IRQs from the
> >> > device tree and nowhere else. Get rid of all the static assignments
> >> > everywhere, delete it from the
On Wednesday 12 February 2014, Courtney Cavin wrote:
> On Tue, Feb 11, 2014 at 09:35:01AM +0100, Arnd Bergmann wrote:
> > On Monday 10 February 2014 16:23:48 Courtney Cavin wrote:
> Then again, I think that the context management stuff is the exception as
> well,
> and I thi
On Friday 17 January 2014, Hanjun Guo wrote:
> +++ b/arch/arm64/pci/Makefile
> @@ -0,0 +1 @@
> +obj-y += pci.o
> diff --git a/arch/arm64/pci/pci.c b/arch/arm64/pci/pci.c
> new file mode 100644
> index 000..4e46790
> --- /dev/null
> +++ b/arch/arm64/pci/pci.c
> @@ -0,0 +1,33 @@
>
On Friday 17 January 2014, Hanjun Guo wrote:
>
> +/*
> + * Local interrupt controller address,
> + * GIC cpu interface base address on ARM/ARM64
> + */
> +static u64 acpi_lapic_addr __initdata;
If it's cpu local, don't you need more than one address to support SMP?
Also, the variable appears to
On Friday 17 January 2014, Hanjun Guo wrote:
>
> From: Amit Daniel Kachhap
>
> This macro does the same job as CLOCKSOURCE_OF_DECLARE. The device
> name from the ACPI timer table is matched with all the registered
> timer controllers and matching initialisation routine is invoked.
I wouldn't an
On Friday 17 January 2014, Hanjun Guo wrote:
> +/* Parked Address in ACPI GIC structure */
> +static u64 parked_address[NR_CPUS];
Please use the per_cpu infrastructure rather than NR_CPUS long arrays.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
On Friday 17 January 2014, Hans Verkuil wrote:
> > @@ -323,25 +324,32 @@ static ssize_t cadet_read(struct file *file, char
> > __user *data, size_t count, lo
> > struct cadet *dev = video_drvdata(file);
> > unsigned char readbuf[RDS_BUFFER];
> > int i = 0;
> > + DEFINE_WAIT(w
e UC-7112-LX hardware. The remaining two can be
> used in a future audio driver or client application.
>
> Signed-off-by: Jonas Jensen
> ---
Acked-by: Arnd Bergmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@v
On Friday 17 January 2014, Jonas Jensen wrote:
> Add SDHCI driver for MOXA ART SoCs.
>
> Signed-off-by: Jonas Jensen
I think this should be renamed to something other than SDHCI, since that
implies a specific register layout and would use the sdhci.c driver.
Maybe moxart-mmc?
> diff --git a/Do
On Friday 17 January 2014, Tanmay Inamdar wrote:
> On Wed, Jan 15, 2014 at 4:39 AM, Arnd Bergmann wrote:
> > On Wednesday 15 January 2014, Tanmay Inamdar wrote:
> >> This patch adds the AppliedMicro X-Gene SOC PCIe controller driver.
> >> X-Gene PCIe controller suppo
On Thursday 16 January 2014, Srikanth Thokala wrote:
> @@ -0,0 +1,71 @@
> +Xilinx AXI VDMA engine, it does transfers between memory and video devices.
> +It can be configured to have one channel or two channels. If configured
> +as two channels, one is to transmit to the video device and another is
On Friday 17 January 2014, Chen-Yu Tsai wrote:
> diff --git a/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
> b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
> new file mode 100644
> index 000..8a07ea4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rfkill/rfkil
On Wednesday 15 January 2014, Feng Kan wrote:
> +static int __init xgene_reboot_init(void)
> {
> arm_pm_restart = xgene_restart;
> return 0;
> }
> device_initcall(xgene_reboot_init);
This won't work on a generic kernel, since you unconditionally set the
pm_restart function to yo
On Thursday 16 January 2014, Mark Brown wrote:
> On Thu, Jan 16, 2014 at 12:19:00PM +0100, Arnd Bergmann wrote:
>
> > 1. Other platforms also require the syscon driver to be active before
> > the regular device driver probing starts. Michal Simek has the same
> > issue
On Friday 17 January 2014, Marc Carino wrote:
> + serial@f0406b00 {
> + compatible = "ns16550a";
> + reg = <0x00 0xf0406b00 0x00 0x20>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <0 75 0x4>;
> +
On Friday 17 January 2014, Chen-Yu Tsai wrote:
> On Sat, Jan 18, 2014 at 12:47 AM, Arnd Bergmann wrote:
> > On Friday 17 January 2014, Chen-Yu Tsai wrote:
> >> diff --git a/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
> >> b/Documentation/devicetree/bind
On Monday 20 January 2014 16:08:01 Hanjun Guo wrote:
> >> diff --git a/drivers/acpi/plat/arm-core.c b/drivers/acpi/plat/arm-core.c
> >> index 3c8521d..1835b21 100644
> >> --- a/drivers/acpi/plat/arm-core.c
> >> +++ b/drivers/acpi/plat/arm-core.c
> >> @@ -100,6 +100,25 @@ int acpi_gsi_to_irq(u32 gsi
On Monday 20 January 2014, Srikanth Thokala wrote:
> On Fri, Jan 17, 2014 at 9:43 PM, Arnd Bergmann wrote:
> > On Thursday 16 January 2014, Srikanth Thokala wrote:
> > I also assume that some of the properties should just go away:
> >
> > * xlnx,device-id should be the
On Monday 20 January 2014, Srikanth Thokala wrote:
> >
> >> > * data width should be a property of the slave driver that is configured
> >> > through dma_slave_config(), unless you can have dma engines that only
> >> > support certain a width.
> >>
> >> Yes, this VDMA engine soft IP support onl
On Monday 20 January 2014, Hanjun Guo wrote:
> >> acpi_register_ioapic()/acpi_unregister_ioapic() will be used for IOAPIC
> >> hotplug and GIC distributor is something like IOAPIC on x86, so I think
> >> these two functions can be reserved for future use.
> > But GIC is not hotplugged, is it? It st
On Tuesday 21 January 2014, Linus Walleij wrote:
> On Tue, Jan 21, 2014 at 4:11 AM, Alexandre Courbot wrote:
> > On Sat, Jan 18, 2014 at 8:11 AM, Linus Walleij
> > wrote:
> >
> > I agree that's how it should be be done with the current API if your
> > driver can obtain GPIOs from both ACPI and D
On Tuesday 21 January 2014, Alexandre Courbot wrote:
> >> As discussed earlier in this thread I'm not sure the con_id is
> >> suitable for labelling GPIOs. It'd be better to have a proper name
> >> specified in DT/ACPI instead.
> >
> > +1
>
> I wonder why you guys prefer to have the name defined i
On Tuesday 21 January 2014 16:22:23 Paul Gortmaker wrote:
>
> Note that direct use of __initcall is discouraged, vs. one
> of the priority categorized subgroups. As __initcall gets
> mapped onto device_initcall, our use of subsys_initcall (which
> seems to make sense for netfilter code) will thus
On Wednesday 22 January 2014 11:46:16 Mark Rutland wrote:
> On Mon, Jan 20, 2014 at 09:08:32AM +, Hanjun Guo wrote:
> > On 2014-1-17 22:21, Arnd Bergmann wrote:
> > > On Friday 17 January 2014, Hanjun Guo wrote:
> > >>
> > >> From: Amit Daniel Kachh
On Wednesday 22 January 2014 15:17:49 Mark Rutland wrote:
> Except for the fact that some timers / clocksources that we already have
> in 32-bit land will likely be reused in 64-bit SoC designs. People will
> want to use the same driver for both 32-bit and 64-bit kernels, and thus
> we need CLOCKSO
On Wednesday 29 January 2014 13:41:59 Linus Walleij wrote:
> On Tue, Jan 28, 2014 at 10:05 PM, Arnd Bergmann wrote:
>
> > Commit 7b85b867b9904 "ARM: plat-iop: instantiate GPIO from platform
> > device" nicely cleaned up the gpio register access for iop, but
> &
On Wednesday 29 January 2014, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Wednesday 29 January 2014 02:56 AM, Arnd Bergmann wrote:
> > On Tuesday 28 January 2014, Kishon Vijay Abraham I wrote:
> >>> I have a common set of registers, which need to be programmed
> >
On Wednesday 29 January 2014, Pratyush Anand wrote:
> On Wed, Jan 29, 2014 at 01:41:56PM +0800, Kishon Vijay Abraham I wrote:
> > >
> > > I would instead recommend making the mode of the PHY device the
> > > argument to the phy handle in DT, so that the sata node uses
> > >
> > > phys = <&phyA
On Tuesday 28 January 2014 12:16:56 Russell King - ARM Linux wrote:
> On Tue, Jan 28, 2014 at 01:08:47PM +0100, Arnd Bergmann wrote:
>
> On balance, I think the virtual channel approach makes client drivers
> more elegant and simpler, and makes the DMA engine API easier to use,
On Friday 24 January 2014 15:16:32 Marc C wrote:
>
> > What's wrong with having a system clock unit binding, that the kernel
> > can decompose as appropriate?
>
> From what I understand, the arm-soc maintainers want to reduce (and perhaps
> even
> eliminate) these board-specific constructs, and
On Monday 27 January 2014, Tanmay Inamdar wrote:
> On Sat, Jan 25, 2014 at 12:11 PM, Arnd Bergmann wrote:
> > On Friday 24 January 2014 13:28:22 Tanmay Inamdar wrote:
> >> On Thu, Jan 16, 2014 at 5:10 PM, Tanmay Inamdar wrote:
> >> > On Wed, Jan 15, 2014 at
On Thursday 30 January 2014, Pratyush Anand wrote:
> On Thu, Jan 30, 2014 at 07:43:37PM +0800, Kishon Vijay Abraham I wrote:
> > Hi,
> >
> > On Thursday 30 January 2014 04:18 PM, Mohit Kumar wrote:
> > > From: Pratyush Anand
> > >
> > > PCIe RC drivers are initialized with subsys_initcall. Few P
On Friday 24 January 2014, Tanmay Inamdar wrote:
> + pcie3: pcie@1f50 {
> + reg-names = "csr", "cfg";
> + ranges = <0x0100 0x0 0x 0xa0 0x
> 0x0 0x0001 /* mem */
> + 0x0200 0x0
On Friday 24 January 2014, Tanmay Inamdar wrote:
> +static void xgene_pcie_fixup_bridge(struct pci_dev *dev)
> +{
> + int i;
> +
> + /* Hide the PCI host BARs from the kernel as their content doesn't
> + * fit well in the resource management
> + */
> + for (i = 0; i < DEVICE_
On Friday 24 January 2014, Tanmay Inamdar wrote:
> This patch adds support for AppliedMicro X-Gene PCIe host controller. The
> driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint
> cards.
>
> X-Gene PCIe controller driver has depedency on the pcie arch support for
> arm64. Th
On Thursday 30 January 2014, Tanmay Inamdar wrote:
> >
> > When you repost, please make sure you fix whatever problem is
> > preventing your email from appearing on the vger mailing lists. I
> > won't apply things that haven't appeared on the linux-pci list,
> > because that list is the opportunit
On Tuesday 28 January 2014, Ravi Patel wrote:
> On Tue, Jan 14, 2014 at 7:15 AM, Arnd Bergmann wrote:
-
> > For the DT binding, I would suggest using something along the lines of
> > what we have for clocks, pinctrl and dmaengine. OMAP doesn't use this
> > (yet), but n
On Thursday 30 January 2014, Ian Campbell wrote:
> mach-virt has existed for a while but it is not written down what it actually
> consists of. Although it seems a bit unusual to document a binding for an
> entire platform since mach-virt is entirely virtual it is helpful to have
> something to ref
On Thursday 30 January 2014, Patrice CHOTARD wrote:
> From: Alexandre TORGUE
>
> This patch adds support to STiD127 SoC.
> The main adaptation is the L2 cache way size compare to STiH41x SoCs.
>
> Signed-off-by: alexandre torgue
> Signed-off-by: Patrice Chotard
> ---
> arch/arm/mach-sti/board
On Thursday 30 January 2014, Arnd Bergmann wrote:
> On Thursday 30 January 2014, Patrice CHOTARD wrote:
> > From: Alexandre TORGUE
> >
> > This patch adds support to STiD127 SoC.
> > The main adaptation is the L2 cache way size compare to STiH41x SoCs.
> >
&g
On Friday 31 January 2014, Pratyush Anand wrote:
> > Having the PHY driver get initialized after the PCI root driver should
> > also work, but it requires correct handling of -EPROBE_DEFER: if phy_get
>
> I had issue with phy-core driver getting initialized after pcie rc
> driver. I found a kernel
On Thursday 30 January 2014, Kumar Gala wrote:
> Introduce a new mach-qcom that will support SoCs that intend to be
> multiplatform compatiable while keeping mach-msm to legacy SoC/board
> support that will not transition over to multiplatform.
>
> As part of this, we move support for MSM8X60, MSM
On Friday 31 January 2014 13:25:25 Kumar Gala wrote:
> > The hotplug.c change sticks out as something that isn't just a move
> > of code to another place, but deletion of unused code. It would
> > be nice to split that out into a separate change, possibly together
> > with the trivial board.c and s
On Friday 31 January 2014, srinivas kandagatla wrote:
> > Sorry if I missed the initial review, but can you explain
> > why this is needed to start with?
>
> On ST SoCs the default value for L2 AUX_CTRL register is 0x0, so we set
> the way-size explicit here.
Unfortunately, we keep going back an
On Friday 31 January 2014, Michal Simek wrote:
> +Optional properties:
> +- clock-frequency : Frequency of clock in Hz
> +- xlnx,wdt-enable-once : 0 - Watchdog can be restarted
> + 1 - Watchdog can be enabled just once
> +- xlnx,wdt-interval: Watchdog timeout interv
On Monday 03 February 2014 16:13:47 Michal Simek wrote:
> Intention wasn't to fix binding but document current one
> which is in mainline for a long time.
Ok, I see.
> Apart of this - yes, wdt-enable-once is nowayout and wdt-interval should be
> timeout
> is seconds, and clock-frequency should g
1301 - 1400 of 5573 matches
Mail list logo
