From: "Dr. David Alan Gilbert"
PowerPC has a 'btext' font used for the console which is almost identical
to the shared font_sun8x16, so use it rather than duplicating the data.
They were actually identical until about a decade ago when
commit bcfbeecea11c ("drivers: console: font_: Change a g
From: "Dr. David Alan Gilbert"
PowerPC has a 'btext' font used for the console which is almost identical
to the shared font_sun8x16, so use it rather than duplicating the data.
They were actually identical until about a decade ago when
commit bcfbeecea11c ("drivers: console: font_: Change a g
From: "Dr. David Alan Gilbert"
PowerPC has a 'btext' font used for the console which is almost identical
to the shared font_sun8x16, so use it rather than duplicating the data.
They were actually identical until about a decade ago when
commit bcfbeecea11c ("drivers: console: font_: Change a g
From: "Dr. David Alan Gilbert"
PowerPC has a 'btext' font used for the console which is almost identical
to the shared font_sun8x16, so use it rather than duplicating the data.
They were actually identical until about a decade ago when
commit bcfbeecea11c ("drivers: console: font_: Change a g
From: "Dr. David Alan Gilbert"
The last function to reference module_bug_list went in 2008's
commit b9754568ef17 ("powerpc: Remove dead module_find_bug code")
but I don't think that was called since 2006's
commit 73c9ceab40b1 ("[POWERPC] Generic BUG for powerpc")
Now that the list has gone,
From: "Dr. David Alan Gilbert"
'cgr_comp' has been unused since
commit 96f413f47677 ("soc/fsl/qbman: fix issue in
qman_delete_cgr_safe()").
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
drivers/soc/fsl/qbman/qman.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/soc/fsl
| 5 -
drivers/bus/fsl-mc/fsl-mc-private.h | 6 --
drivers/bus/fsl-mc/mc-io.c| 20 ----
include/linux/fsl/mc.h| 2 --
5 files changed, 55 deletions(-)
diff --git a/drivers/bus/fsl-mc/dpmcp.c b/drivers/bus/fsl-mc/dpmcp.c
index 5fbd0dbde24a..781
From: Jagadeesh Pagadala
Remove duplicate headers which are included twice.
Signed-off-by: Jagadeesh Pagadala
---
arch/powerpc/kernel/time.c | 1 -
arch/powerpc/lib/code-patching.c | 1 -
arch/powerpc/mm/numa.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/arch/powerpc/k
From: Jagadeesh Pagadala
Code cleanup: Remove duplicate headers which are included twice.
Signed-off-by: Jagadeesh Pagadala
---
tools/testing/selftests/powerpc/mm/tlbie_test.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/testing/selftests/powerpc/mm/tlbie_test.c
b/tools/testing/se
From: Jagadeesh Pagadala
Code cleanup: Remove duplicate headers which are included twice.
Signed-off-by: Jagadeesh Pagadala
---
tools/testing/selftests/powerpc/tm/tm-poison.c | 1 -
tools/testing/selftests/powerpc/tm/tm-vmx-unavail.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/to
Hello linuxppc-dev mailing list!
I come right to the point.
My computer is a Power Mac G4 Quicksilver (original, 2001) with the a flashed
PC graphics card Nvidia 6200 AGP. It is correctly supported in Mac OS X
10.4/10.5 and it was working in Linux with the Debian kernels 3.16. I use
Debian
c.
This is my first contribution to the linux kernel ever, so I hope you will be
kind to me. I am not a programmer, but adding already supported devices was a
task even I could accomplish.
Thanks,
Andreas aka Linux User #330250
diff -Naur linux-2.6.38-rc5-git2/sound/aoa/fabrics/layout.c linux
c.
This is my first contribution to the linux kernel ever, so I hope you will be
kind to me. I am not a programmer, but adding already supported devices was a
task even I could accomplish.
Thanks,
Andreas aka Linux User #330250
---
diff -Naur linux-2.6.38-rc5-git2/sound/aoa/fabrics/layout.c
linux
c.
This is my first contribution to the linux kernel ever, so I hope you will be
kind to me. I am not a programmer, but adding already supported devices was a
task even I could accomplish.
Thanks,
Andreas aka Linux User #330250
---
diff -Naur linux-2.6.38-rc5-git2/sound/aoa/fabrics/layout.c
linux
Hello again!
Sorry for sending the patch three times. (This is the fourth...)
About the sign-off: I use the name I've been using since I started
participating. The document $LINUX/Documentation/SubmittingPatches clearly
states that one has to use real names. I'm breaking this rule, b
l 21.
PowerMac3,4 Digital Audio: Device ID 14, ??? chip
PowerMac3,5 Quicksilver: Device ID 21, TAS 3001C CODEC chip
PowerMac3,6 Mirrored Drive Doors: Device ID 22, TAS3004 CODEC chip
$LINUX/sound/aoa/codecs/tas.c driver was originally made for the TAS3004,
which I figure because only "tas 300
Hello!
First: I'm just a user. And I hope I don't cause disturbance.
I've read about this when I was setting up Linux on my Power Mac G4 MDD about
two years ago and I remember reading that the temperature might be reported
falsely. The original author reduced the limits to be o
Hello!
My hardware: Apple Power Mac G5 "Late 2005"
I've just compiled kernel 2.6.34 for Gentoo Linux.
# ACCEPT_KEYWORDS="~ppc64" emerge -1 sys-kernel/gentoo-sources-2.6.34
I tried the "KVM support for PowerPC book3s_64 processors" just to see if what
I coul
is problem with DVI?
If not, do any of you have an idea what could cause this problem and how to
fix it?
Thanks,
Andreas aka Linux User #330250
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
gt; arch/x86/kernel/pci-dma.c | 15 ++-
> arch/x86/mm/mem_encrypt_amd.c | 3 ---
> drivers/xen/swiotlb-xen.c | 4 +--
> include/linux/swiotlb.h| 15 ++-
> include/trace/events/swiotlb.h | 29 -
From: Christoph Hellwig Sent: Monday, February 28, 2022 3:31 AM
>
> On Mon, Feb 28, 2022 at 02:53:39AM +, Michael Kelley (LINUX) wrote:
> > From: Christoph Hellwig Sent: Sunday, February 27, 2022 6:31
> > AM
> > >
> > > Pass a bool to pass if swio
> arch/powerpc/platforms/pseries/svm.c | 26 +-
> include/linux/swiotlb.h | 1 +
> kernel/dma/swiotlb.c | 9 +++--
> 7 files changed, 12 insertions(+), 35 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/svm.h b/arch/po
From: Dongli Zhang Sent: Friday, March 4, 2022 10:28
AM
>
> Hi Michael,
>
> On 3/4/22 10:12 AM, Michael Kelley (LINUX) wrote:
> > From: Christoph Hellwig Sent: Tuesday, March 1, 2022 2:53 AM
> >>
> >> Power SVM wants to allocate a swiotlb buffer that is no
| 15 ++++++-----
> drivers/xen/swiotlb-xen.c | 4 +--
> include/linux/swiotlb.h| 15 ++-
> include/trace/events/swiotlb.h | 29 -
> kernel/dma/swiotlb.c | 35 ++
> 15 files changed
From: Guilherme G. Piccoli Sent: Wednesday, April 27,
2022 3:49 PM
>
> Currently the regular CPU shutdown path for ARM disables IRQs/FIQs
> in the secondary CPUs - smp_send_stop() calls ipi_cpu_stop(), which
> is responsible for that. This makes sense, since we're turning off
> such CPUs, puttin
From: Guilherme G. Piccoli Sent: Wednesday, April 27,
2022 3:49 PM
>
> Currently we have a debug infrastructure in the notifiers file, but
> it's very simple/limited. This patch extends it by:
>
> (a) Showing all registered/unregistered notifiers' callback names;
>
> (b) Adding a dynamic debug
From: Guilherme G. Piccoli Sent: Wednesday, April 27,
2022 3:49 PM
>
> Currently Hyper-V guests are among the most relevant users of the panic
> infrastructure, like panic notifiers, kmsg dumpers, etc. The reasons rely
> both in cleaning-up procedures (closing a hypervisor <-> guest connection,
g-heartbeat.c | 4 ++--
> drivers/misc/bcm-vk/bcm_vk_dev.c | 6 +++---
> drivers/misc/pvpanic/pvpanic.c | 4 ++--
> drivers/power/reset/ltc2952-poweroff.c | 4 ++--
> drivers/s390/char/zcore.c| 5 +++--
> drivers/soc/bcm/brcmstb/pm/pm-arm.c | 2 +-
>
ithout_ kdump, but this is fixed in the first patch of the series (and
> it's a bug present even before this refactor).
>
> * Notice we didn't add a sysrq for panic notifiers level - should have it?
> Alejandro proposed recently to add a sysrq f
From: Guilherme G. Piccoli Sent: Friday, April 29, 2022
1:38 PM
>
> On 29/04/2022 14:53, Michael Kelley (LINUX) wrote:
> > From: Guilherme G. Piccoli Sent: Wednesday, April 27,
> > 2022
> 3:49 PM
> >> [...]
> >> + panic_notifiers_level=
> >>
From: Guilherme G. Piccoli Sent: Friday, April 29, 2022
11:04 AM
>
> On 29/04/2022 14:30, Michael Kelley (LINUX) wrote:
> > From: Guilherme G. Piccoli Sent: Wednesday, April 27,
> > 2022
> 3:49 PM
> >> [...]
> >>
> >> @@ -2843,7 +2843,7 @
From: Guilherme G. Piccoli Sent: Friday, April 29, 2022
3:35 PM
>
> Hi Michael, first of all thanks for the great review, much appreciated.
> Some comments inline below:
>
> On 29/04/2022 14:16, Michael Kelley (LINUX) wrote:
> > [...]
> >> hypervisor I/O completio
On Fri, May 31, 2019 at 6:52 AM Michael Ellerman wrote:
>
> Sachin Sant writes:
> > Latest next fails to boot with a kernel panic on POWER9.
> >
> > [ 33.689332] Kernel panic - not syncing: stack-protector: Kernel stack is
> > corrupted in: write_irq_affinity.isra.5+0x15c/0x160
> > [ 33.6893
ks for trying. I'll have a look again with brain awake tomorrow
> >> morning.
> >
> > Morning was busy with other things, but I found what my sleepy brain
> > managed to do wrong yesterday evening.
> >
> > Let me reintegrate the pile and I'll send
Am 2017-05-04 um 12:15 schrieb Michael Ellerman:
Mathieu Malaterre writes:
Hi all,
Does this dmesg output speaks to anyone here (smp kernel):
[4.767389] [ cut here ]
[4.774668] WARNING: CPU: 0 PID: 1 at
/build/linux-dp17Ba/linux-4.9.18/arch/powerpc/lib
Am 2017-05-06 um 16:11 schrieb Linux User #330250:
Am 2017-05-04 um 12:15 schrieb Michael Ellerman:
Mathieu Malaterre writes:
Hi all,
Does this dmesg output speaks to anyone here (smp kernel):
[4.767389] [ cut here ]
[4.774668] WARNING: CPU: 0 PID: 1 at
SET_MASK_OK &&
> ret)
> - cpumask_copy(d->affinity, affinity);
> + cpumask_copy(irq_data_get_affinity_mask(d), affinity);
>
> return ret;
> }
> diff --git a/include/linux/irq.h b/include/linux/irq.h
> index 43581e166298..2eb82257
On Fri, Jan 09, 2015 at 06:21:32PM +0100, Wolfram Sang wrote:
> +static int i2c_quirk_error(struct i2c_adapter *adap, struct i2c_msg *msg,
> char *err_msg)
> +{
> + dev_err(&adap->dev, "quirk: %s (addr 0x%04x, size %u)\n", err_msg,
> msg->addr, msg->len);
> + return -EOPNOTSUPP;
> +}
So,
On Wed, May 22, 2013 at 11:25:36AM +0200, Arnd Bergmann wrote:
> Given the most commonly used functions and a couple of architectures
> I'm familiar with, these are the ones that currently call might_fault()
>
> x86-32 x86-64 arm arm64 powerpc s390generic
> copy_t
On Thu, May 23, 2013 at 10:40:29AM +0200, Geert Uytterhoeven wrote:
> On Thu, May 23, 2013 at 9:57 AM, Chen Gang wrote:
> > -config BUG
> > - bool "BUG() support" if EXPERT
> > - default y
> > - help
> > - Disabling this option eliminates support for BUG and WARN,
> > r
On Thu, May 23, 2013 at 11:39:37AM +0200, Arnd Bergmann wrote:
> On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> > > The problem is: trying to fix that will mean the result is a larger
> > > kernel than if you just do the usual arch-implemented thing of placing
> > > an defined faulting instru
On Thu, May 23, 2013 at 03:09:50AM -0700, Eric W. Biederman wrote:
> Arnd Bergmann writes:
>
> > On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> >> > The problem is: trying to fix that will mean the result is a larger
> >> > kernel than if you just do the usual arch-implemented thing of plac
On Thu, May 23, 2013 at 12:59:43PM +0200, Arnd Bergmann wrote:
> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> > So, if you want to use this, then you should update the CONFIG_BUG text
> > to include a warning to this effect:
> >
> > Warning: if CO
On Thu, May 23, 2013 at 02:09:02PM +0200, Arnd Bergmann wrote:
> On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> > This is the problem you guys are missing - unreachable() means "we lose
> > control of the CPU at this point".
>
> I'm absolute
On Fri, May 24, 2013 at 01:01:25PM -0400, Jason Cooper wrote:
> On Fri, May 24, 2013 at 01:03:25PM +0200, Linus Walleij wrote:
> > IMO: if you want to go down that road, what you really want is not
> > ever more expressible device trees, but real open firmware,
> > or ACPI or UEFI that can interpre
On Mon, Jun 10, 2013 at 01:49:22AM +0100, Grant Likely wrote:
> This is an RFC patch to convert the versatile FPGA irq controller driver
> to use generic irq chip. It builds on the series that extends the
> generic chip code to allow a linear irq domain to contain one or more
> generic irq chips so
ng (by me.)
2. The "contract" of the clk API is defined by the clk API, not by some
random implementation like the common clock API. The clk API is
maintained by myself, and is described in include/linux/clk.h
3. clk_prepare() and clk_unprepare() are functions MUST only be call
On Thu, Jul 18, 2013 at 10:20:52PM +0200, Gerhard Sittig wrote:
> + /* enable clock for the I2C peripheral (non fatal) */
> + clk = of_clk_get_by_name(node, "per");
> + if (!IS_ERR(clk)) {
> + clk_prepare_enable(clk);
> + clk_put(clk);
> + }
> +
This kind of
On Fri, Jul 03, 2015 at 08:17:09PM +0200, Luis R. Rodriguez wrote:
> The 0-day build bot detected a build issue on a patch not upstream yet that
> makes a driver use iorempa_uc(), this call is now upstream but we have no
> drivers yet using it, the patch in question makes the atyfb framebuffer
> dr
On Thu, Aug 13, 2015 at 05:04:05PM +0200, Christoph Hellwig wrote:
> diff --git a/arch/arm/include/asm/dma-mapping.h
> b/arch/arm/include/asm/dma-mapping.h
> index 2ae3424..ab521d5 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -175,21 +175,6 @@ s
On Thu, Aug 13, 2015 at 05:04:08PM +0200, Christoph Hellwig wrote:
> diff --git a/arch/arm/common/dmabounce.c b/arch/arm/common/dmabounce.c
> index 1143c4d..260f52a 100644
> --- a/arch/arm/common/dmabounce.c
> +++ b/arch/arm/common/dmabounce.c
> @@ -440,14 +440,6 @@ static void dmabounce_sync_for_d
| 48 +++-
drivers/usb/musb/tusb6010.c | 49 +++-
drivers/video/amba-clcd.c |5 ++
include/linux/amba/bus.h |2 -
include/linux/dma-mapping.h | 31 +
soun
On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote:
> Hi,
>
> On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
> > Use platform_device_register_full() for those drivers which can, to
> > avoid messing directly with DMA masks. This can only be done when
> > the driver does n
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote:
> On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote:
> > The correct way for a driver to specify the coherent DMA mask is
> > not to directly access the field in the struct device, but to use
> > dma_set_coherent_mask(). Only ar
On Fri, Sep 20, 2013 at 02:21:37AM +0100, Ben Hutchings wrote:
> On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote:
> [...]
> > -dma_set_coherent_mask() will always be able to set the same or a
> > -smaller mask as dma_set_mask(). However for the rare case that a
> > +The coherent coherent mask
On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote:
> Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
> > The DMA API requires drivers to call the appropriate dma_set_mask()
> > functions before doing any DMA mapping. Add this required call to
> > the AMBA PL08x driver
On Mon, Sep 23, 2013 at 03:55:33PM +0530, Vinod Koul wrote:
> On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
> > register_platform_device_full() can setup the DMA mask provided the
> > appropriate member is set in struct platform_device_info. So lets
> > make that be the case. This
On Mon, Sep 23, 2013 at 02:27:39PM -0400, Alan Stern wrote:
> On Thu, 19 Sep 2013, Russell King wrote:
>
> > The correct way for a driver to specify the coherent DMA mask is
> > not to directly access the field in the struct device, but to use
> > dma_set_coherent_mask(). Only arch and bus code s
On Tue, Sep 24, 2013 at 02:23:31PM -0700, Timothy Pepper wrote:
> diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c
> index 0c63562..0e7355d 100644
> --- a/arch/arm/mm/mmap.c
> +++ b/arch/arm/mm/mmap.c
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #def
On Thu, Sep 26, 2013 at 09:51:23AM +0200, Takashi Iwai wrote:
> Hi,
>
> sorry for the lat response, as I've been traveling in the last weeks.
>
> At Thu, 19 Sep 2013 22:53:02 +0100,
> Russell King wrote:
> >
> > This code sequence is unsafe in modules:
> >
> > static u64 mask = DMA_BIT_MASK(som
On Thu, Sep 26, 2013 at 10:23:08PM +0200, Rafał Miłecki wrote:
> 2013/9/19 Russell King - ARM Linux :
> > This email is only being sent to the mailing lists in question, not to
> > anyone personally. The list of individuals is far to great to do that.
> > I'm hoping n
On Thu, Oct 31, 2013 at 09:46:40AM -0200, Mauro Carvalho Chehab wrote:
> Hi Russell,
>
> Em Mon, 30 Sep 2013 13:57:47 +0200
> Hans Verkuil escreveu:
>
> > On 09/19/2013 11:44 PM, Russell King wrote:
> > > Replace the following sequence:
> > >
> > > dma_set_mask(dev, mask);
> > > dma_set_coh
On Thu, Jan 03, 2013 at 06:58:38PM -0800, Srivatsa Vaddagiri wrote:
> I also think that the
> wait_for_completion() based wait in ARM's __cpu_die() can be replaced with a
> busy-loop based one, as the wait there in general should be terminated within
> few cycles.
Why open-code this stuff when we
On Mon, Jan 14, 2013 at 06:12:40PM +0800, Peter Chen wrote:
> @@ -83,15 +84,16 @@ void fsl_udc_clk_finalize(enum fsl_udc_type devtype,
> struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
> if (devtype == IMX35_UDC) {
> unsigned int v;
> + void __i
On Thu, Feb 07, 2013 at 11:41:34AM +0530, Srivatsa S. Bhat wrote:
> On 02/07/2013 09:44 AM, Rusty Russell wrote:
> > "Srivatsa S. Bhat" writes:
> >> On 01/22/2013 01:03 PM, Srivatsa S. Bhat wrote:
> >> Avg. latency of 1 CPU offline (ms) [stop-cpu/stop-m/c
> >> latency]
> >>
> >>
On Sun, Feb 17, 2013 at 03:43:20PM +0800, Shawn Guo wrote:
> It also breaks all of_amba_device users.
>
> of_amba_device_create() --> amba_device_add() --> request_resource()
> and fails.
Presumably that's because we no longer know what the parent resource
is supposed to be?
_
D OF THE POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +tdm@16000 {
> + compatible = "fsl,tdm1.0";
> + reg = <0x16000 0x200 0x2c000 0x2000>;
> + clock-frequency = <0>;
> + tdm_tx_clk = <2048000>;
> + interrupts = <62 8 0 0>;
&
On Thu, Mar 14, 2013 at 07:08:34PM +0100, Florian Fainelli wrote:
> + if (dev->err_interrupt == NO_IRQ) {
...
> + init_waitqueue_head(&dev->smi_busy_wait);
> +
> + dev->err_interrupt = platform_get_irq(pdev, 0);
> + if (dev->err_interrupt != -ENXIO) {
...
> + } else
> +
mc/host/sdhci-sirf.c | 4 +
drivers/mmc/host/sdhci-spear.c| 5 +-
drivers/mmc/host/sdhci-tegra.c| 27 +-
drivers/mmc/host/sdhci.c | 728 +-
drivers/mmc/host/sdhci.h | 20 +-
incl
On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
> I have looked though the patches up until patch 33 and this is clearly
> a nice piece of clean-up /fixes work for sdhci. Besides my minor
> comments per patch, I don't have any objections code-review wise to
> proceed merging them.
>
>
On Thu, Apr 24, 2014 at 12:52:11PM +0200, Ulf Hansson wrote:
> On 24 April 2014 12:17, Russell King - ARM Linux
> wrote:
> > On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
> >> I have looked though the patches up until patch 33 and this is clearly
> >
On Thu, Apr 24, 2014 at 01:13:05PM +0200, Ulf Hansson wrote:
> On 24 April 2014 12:57, Russell King - ARM Linux
> wrote:
> > This is nothing new or unexpected - it was last posted back in February,
> > and I elected that it should be held off until after the las
On Fri, Apr 25, 2014 at 01:18:28PM +0200, Ulf Hansson wrote:
> On 25 April 2014 11:03, Russell King - ARM Linux
> wrote:
> > On Thu, Apr 24, 2014 at 01:13:05PM +0200, Ulf Hansson wrote:
> >> On 24 April 2014 12:57, Russell King - ARM Linux
> >> wrote:
> >&
On Wed, Apr 23, 2014 at 08:08:07PM +0100, Russell King wrote:
> @@ -1507,25 +1529,7 @@ static void sdhci_do_set_ios(struct sdhci_host *host,
> struct mmc_ios *ios)
> host->ops->set_clock(host, host->clock);
> }
>
> - if (host->ops->set_uhs_signalin
On Mon, Jun 16, 2014 at 02:17:30PM +0200, Ulf Hansson wrote:
> On 16 June 2014 12:46, Russell King - ARM Linux
> wrote:
> > On Wed, Apr 23, 2014 at 08:08:07PM +0100, Russell King wrote:
> >> @@ -1507,25 +1529,7 @@ static void sdhci_do_set_ios(struct sdhci_host
> >&
On Mon, Jun 16, 2014 at 02:17:30PM +0200, Ulf Hansson wrote:
> Anyway, we did get some folks to test the patches and was thus fairly
> confident that we could merge them. Chris asked me to try to collect
> them in a PR for him, so I did. Sorry if I managed to screw some
> things up, there were seve
On Wed, Jun 25, 2014 at 06:30:37PM +0100, Sudeep Holla wrote:
> + coherency_line_size: the minimum amount of data that gets
> transferred
So, what value to do envision this taking for a CPU where the cache
line size is 32 bytes, but each cache line has two dirty bits which
allow it to
On Thu, Jun 26, 2014 at 07:41:32PM +0100, Sudeep Holla wrote:
> Hi,
>
> On 25/06/14 23:23, Russell King - ARM Linux wrote:
>> On Wed, Jun 25, 2014 at 06:30:37PM +0100, Sudeep Holla wrote:
>>> + coherency_line_size: the minimum amount of data that gets
>&g
On Mon, Aug 11, 2014 at 10:15:50AM +0100, Pawel Moll wrote:
> On Mon, 2014-08-11 at 10:07 +0100, Ulf Hansson wrote:
> > Sorry for the delay. I suppose this make sense, but I really don't
> > know for sure.
> >
> > I guess we need some testing in linux-next, to get
On Thu, Nov 14, 2013 at 07:07:10PM +0800, Nicolin Chen wrote:
> The normal mode of SSI allows it to send/receive data to/from the first
> slot of each period. So we can use this normal mode to trick I2S signal
> by puting/getting data to/from the first slot only (the left channel)
> so as to suppor
> + dma_coerce_mask_and_coherent(&viodev->dev, DMA_BIT_MASK(64));
> }
>
> /* register with generic device framework */
> --
> 1.7.10.4
>
>
>
> ___
> linux-arm-kernel
On Wed, Nov 20, 2013 at 12:28:02PM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2013-11-19 at 16:11 +0800, Li Zhong wrote:
> > I encountered following issue:
> > [0.283035] ibmvscsi 3015: couldn't initialize event pool
> > [5.688822] ibmvscsi: probe of 3015 failed with error -1
>
On Thu, Nov 21, 2013 at 11:01:42AM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2013-11-20 at 23:23 +, Russell King - ARM Linux wrote:
> > Li Zong's patch works around the issue of a failing dma_set_mask(),
> > but as I've already said elsewhere, the real fix is to
On Wed, Jan 08, 2014 at 07:26:07PM +, Sudeep Holla wrote:
> +#if __LINUX_ARM_ARCH__ < 7 /* pre ARMv7 */
> +
> +#define MAX_CACHE_LEVEL 1 /* Only 1 level supported */
> +#define CTR_CTYPE_SHIFT 24
> +#define CTR_CTYPE_MASK (1 << CTR_CTYPE_SHIFT)
> +
On Thu, Jan 09, 2014 at 07:35:03PM +, Sudeep Holla wrote:
> I assume you referring to some particular CPUs which don't implement this.
> I could not find it as optional or IMPLEMENTATION defined in ARM ARM.
> I might be missing to find it or there may be exceptions.
> Can you please provide mor
On Mon, Jan 27, 2014 at 01:08:16AM -0500, Nicolas Pitre wrote:
> ARM and ARM64 are the only two architectures implementing
> arch_cpu_idle_prepare() simply to call local_fiq_enable().
>
> We have secondary_start_kernel() already calling local_fiq_enable() and
> this is done a second time in arch_c
On Mon, Jan 27, 2014 at 09:22:55AM +0100, Daniel Lezcano wrote:
> On 01/27/2014 07:08 AM, Nicolas Pitre wrote:
>> ARM and ARM64 are the only two architectures implementing
>> arch_cpu_idle_prepare() simply to call local_fiq_enable().
>>
>> We have secondary_start_kernel() already calling local_fiq_
On Mon, Jan 27, 2014 at 10:45:59AM -0500, Nicolas Pitre wrote:
> On Mon, 27 Jan 2014, Russell King - ARM Linux wrote:
>
> > On Mon, Jan 27, 2014 at 01:08:16AM -0500, Nicolas Pitre wrote:
> > > ARM and ARM64 are the only two architectures implementing
> > > arch_cpu
On Mon, Jan 27, 2014 at 06:12:53PM +0100, Daniel Lezcano wrote:
> On 01/27/2014 05:07 PM, Russell King - ARM Linux wrote:
>> On Mon, Jan 27, 2014 at 09:22:55AM +0100, Daniel Lezcano wrote:
>>> On 01/27/2014 07:08 AM, Nicolas Pitre wrote:
>>>> ARM and ARM64
On Thu, Feb 13, 2014 at 09:13:59PM +0800, Yijing Wang wrote:
> Replace list_for_each() + pci_bus_b() with the simpler
> list_for_each_entry().
>
> Signed-off-by: Yijing Wang
Acked-by: Russell King
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 t
+-
drivers/mmc/host/sdhci.c | 606 ++---
drivers/mmc/host/sdhci.h | 20 +-
include/linux/hardirq.h| 1 +
include/linux/interrupt.h | 1 +
include/linux/mmc/host.h | 3 +
include/linux/mmc/sdhci.h | 14
On Sat, Mar 22, 2014 at 02:31:21PM -0700, James Bottomley wrote:
> Perhaps now might be the time to ask which are the remaining
> architectures that cannot do SG chaining and then we can fix them and
> pull the whole thing out.
Not quite. You're making the assumption that we can be sure that all
On Sat, Mar 22, 2014 at 03:37:40PM -0700, James Bottomley wrote:
> On Sat, 2014-03-22 at 22:23 +, Russell King - ARM Linux wrote:
> > On Sat, Mar 22, 2014 at 02:31:21PM -0700, James Bottomley wrote:
> > > Perhaps now might be the time to ask which are the remaining
> &
On Sat, Mar 22, 2014 at 03:59:11PM -0700, James Bottomley wrote:
> On Sat, 2014-03-22 at 22:52 +, Russell King - ARM Linux wrote:
> > And I'm disagreeing with that statement which implies that it's something
> > that is an architecture wide property for an
On Mon, Jan 19, 2015 at 07:55:56PM +0100, Wolfram Sang wrote:
> Back in the days, sysfs seemed to have refcounting issues and subsystems
> needed a completion to be safe. This is not the case anymore, so I2C can
> get rid of this code. There is noone else besides I2C doing something
> like this cur
On Tue, Jan 20, 2015 at 03:01:42AM +0800, Greg Kroah-Hartman wrote:
> On Mon, Jan 19, 2015 at 07:55:56PM +0100, Wolfram Sang wrote:
> > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> > index 39d25a8cb1ad..15cc5902cf89 100644
> > --- a/drivers/i2c/i2c-core.c
> > +++ b/drivers/i2c/i2c
On Tue, Jan 20, 2015 at 03:12:56PM +0800, Greg Kroah-Hartman wrote:
> On Tue, Jan 20, 2015 at 08:05:20AM +0100, Lars-Peter Clausen wrote:
> > On 01/20/2015 02:41 AM, Greg Kroah-Hartman wrote:
> > >On Mon, Jan 19, 2015 at 11:04:27PM +, Russell King - ARM Linux wrote:
> >
On Sun, Feb 01, 2015 at 02:39:42PM +1100, Finn Thain wrote:
> I find the ARM support in drivers/char/nvram to be surprising, not to say
> questionable. The /proc/driver/nvram implementation, given
> defined(__arm__), decodes the NVRAM contents in exactly the same format as
> when defined(__i386_
On Tue, Feb 24, 2015 at 01:39:46AM -0800, Arjan van de Ven wrote:
> one of the question is if you want to serialize, or if you just want
> to label. If you take a cookie (could just be a monotonic increasing
> number) at the start of the oops and then prefix/postfix the stack
> printing with that
On Thu, Feb 26, 2015 at 02:38:15PM -0800, Andrew Morton wrote:
> diff -puN
> arch/arm64/Kconfig~fix-offset2lib-issue-for-x86-arm-powerpc-and-mips-fix
> arch/arm64/Kconfig
> --- a/arch/arm64/Kconfig~fix-offset2lib-issue-for-x86-arm-powerpc-and-mips-fix
> +++ a/arch/arm64/Kconfig
> @@ -1,4 +1,4 @@
1 - 100 of 346 matches
Mail list logo
