Re: [PATCH 3/5 v2] Staging: cxt1e1: Fix line length over 80 characters in hwprobe.c

DaeSeok Youn writes: >>> - * match with board's first found interface, otherwise this >>> is first >>> - * found >>> + * match with board's first found interface, otherwise this is >>> + * fisrt found >>^ >> I wonder wha

Re: [PATCH 3/5 v2] Staging: cxt1e1: Fix line length over 80 characters in hwprobe.c

Daeseok Youn writes: > clean up checkpatch.pl warnings: > WARNING: Line length over 80 characters This warning should be long gone IMHO. It does more harm than good. > unsigned char *ucp = (unsigned char *) &hi->mfg_info.data; > > pr_info("eeprom[00]: %02x %02x %

[PATCH] CNS3xxx: Fix PCIe early iotable_init().

Signed-off-by: Krzysztof Hałasa --- a/arch/arm/mach-cns3xxx/cns3420vb.c +++ b/arch/arm/mach-cns3xxx/cns3420vb.c @@ -240,7 +240,7 @@ static void __init cns3420_map_io(void) { cns3xxx_map_io(); iotable_init(cns3420_io_desc, ARRAY_SIZE(cns3420_io_desc

[ARM] CNS3xxx: 3 regressions identified in v3.14-rc4+

Hello, Linux version 3.14.0-rc4+ (current tip, no extra patches), CPU is Cavium Econa CNS3420, board is Gateworks Laguna GW2388-4 (masqueraded as CNS3420VB). Issue #1 ### kernel BUG at mm/vmalloc.c:1132! PC is at vm_area_add_early+0x20/0x84 LR is

Re: Regression (ARM) arch/arm/mm/init.c doesn't build without CONFIG_ARM_PATCH_PHYS_VIRT.

Russell King - ARM Linux writes: > Okay, reverted. Thanks. -- Krzysztof Halasa Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@v

Re: Regression (ARM) arch/arm/mm/init.c doesn't build without CONFIG_ARM_PATCH_PHYS_VIRT.

Santosh Shilimkar writes: > I am afraid you didn't understood what the fix is if you say above. > arm_dma_limit is broken without this fix for LPAE machines with > memory starting 4 GB physical boundary. I wonder what CONFIG_ARM_PATCH_PHYS_VIRT and CONFIG_ZONE_DMA do they use? Of course, CONFIG

Re: [PATCH REPOST] ARM: Fix regression in IXP4xx network drivers DMA masks.

masks. Now, devices will have 32-bit default DMA masks (0x) as per DMA API. Signed-off-by: Krzysztof Hałasa diff --git a/arch/arm/mach-ixp4xx/common-pci.c b/arch/arm/mach-ixp4xx/common-pci.c index 6d6bde3..cefb80b 100644 --- a/arch/arm/mach-ixp4xx/common-pci.c +++ b/arch/arm/mach-ixp4xx

Re: Regression (ARM) arch/arm/mm/init.c doesn't build without CONFIG_ARM_PATCH_PHYS_VIRT.

Russell, Santosh, the unneeded commit causing regression is still in place. Please try to compile an ARM kernel without CONFIG_ARM_PATCH_PHYS_VIRT and with CONFIG_ZONE_DMA and see for yourself, if you don't believe me. Please be aware that this commit fixes nothing, its only function is causing t

Re: [PATCH 2/2] sched_clock: Disable seqlock lockdep usage in sched_clock

John Stultz writes: > Unforunately the seqlock lockdep enablmenet can't be used > in sched_clock, since the lockdep infrastructure eventually > calls into sched_clock, which causes a deadlock. > > Thus, this patch changes all generic sched_clock usage > to use the raw_* methods. These two patche

Re: v3.13-rc6+ regression (ARM board)

Linus Torvalds writes: > --- a/kernel/time/sched_clock.c > +++ b/kernel/time/sched_clock.c > @@ -36,6 +36,7 @@ core_param(irqtime, irqtime, int, 0400); > >static struct clock_data cd = { > .mult = NSEC_PER_SEC / HZ, > + .seq = SEQCNT_ZERO(cd.seq), >}; > >stat

Re: v3.13-rc6+ regression (ARM board)

Hello Uwe, >> >> There seems to be a regression in v3.13-rc6+ (up to current tip = >> >> 71ce176ee6ed1735b9a1160a5704a915d13849b1). >> >> >> >> Board is Gateworks Cambria, CPU Intel IXP435 ARM big endian, gcc 4.7.3. >> >> The board boots correctly and works (shell mostly, and SSHD) for about >> >>

Re: v3.13-rc6+ regression (ARM board)

>> There seems to be a regression in v3.13-rc6+ (up to current tip = >> 71ce176ee6ed1735b9a1160a5704a915d13849b1). >> >> Board is Gateworks Cambria, CPU Intel IXP435 ARM big endian, gcc 4.7.3. >> The board boots correctly and works (shell mostly, and SSHD) for about >> 50 seconds. After 52-54 secon

[PATCH REPOST] ARM: Fix regression in IXP4xx network drivers DMA masks.

default DMA masks (0x) as per DMA API. Signed-off-by: Krzysztof Hałasa diff --git a/arch/arm/mach-ixp4xx/common-pci.c b/arch/arm/mach-ixp4xx/common-pci.c index 6d6bde3..cefb80b 100644 --- a/arch/arm/mach-ixp4xx/common-pci.c +++ b/arch/arm/mach-ixp4xx/common-pci.c @@ -316,32 +316,6 @@ static

Re: Regression (ARM) arch/arm/mm/init.c doesn't build without CONFIG_ARM_PATCH_PHYS_VIRT.

Russell King - ARM Linux writes: > On Tue, Dec 31, 2013 at 12:20:56PM +0100, Krzysztof Hałasa wrote: >> arch/arm/mm/init.c: In function 'setup_dma_zone': >> arch/arm/mm/init.c:232:19: error: '__pv_phys_offset' undeclared (first use >> in this functi

Regression (ARM) arch/arm/mm/init.c doesn't build without CONFIG_ARM_PATCH_PHYS_VIRT.

arch/arm/mm/init.c: In function 'setup_dma_zone': arch/arm/mm/init.c:232:19: error: '__pv_phys_offset' undeclared (first use in this function) Reverting the following commit fixes it: commit 787b0d5c1ca7ff24feb6f92e4c7f4410ee7d81a8 Author: Santosh Shilimkar Date: Mon Dec 2 20:29:12 2013 +0100

[ARM] Fix kernel compile error: drivers/crypto/ixp4xx_crypto.c.

drivers/crypto/ixp4xx_crypto.c: In function 'ixp_module_init': drivers/crypto/ixp4xx_crypto.c:1419:2: error: 'dev' undeclared (first use in this function) Now builds. Not tested on real hw. Signed-off-by: Krzysztof Hałasa --- a/drivers/crypto/ixp4xx_crypto.c

v3.13-rc6+ regression (ARM board)

Hi, There seems to be a regression in v3.13-rc6+ (up to current tip = 71ce176ee6ed1735b9a1160a5704a915d13849b1). Board is Gateworks Cambria, CPU Intel IXP435 ARM big endian, gcc 4.7.3. The board boots correctly and works (shell mostly, and SSHD) for about 50 seconds. After 52-54 seconds, it froze

Re: DMA masks

Russell King - ARM Linux writes: > No. If dma_mask is NULL, then dma_set_mask() will return -EIO no matter > what. If dma_mask is non-NULL, dma_set_mask() will succeed if the mask > is supported by the hardware. For example, on x86: > and this is the same pattern we implement on ARM. So, a v

Re: DMA masks

Russell King - ARM Linux writes: >> struct device { >> ... >> >> u64 *dma_mask; /* dma mask (if dma'able device) */ >> ^^ > > "If dma-able device" gives a clue. It is now the case that t

Re: 3.4.10 N_GSM tty_io WARNING and lockup

Alan Cox writes: >> I'm trying to use GSM tty line discipline. Basically >> >> echo AT+CMUX=0 > /dev/ttyS0 >> >> set termios (speed etc.) >> int ldisc = N_GSM0710; >> ioctl(fd, TIOCSETD, &ldisc); > > Baffled at this point. If you set some other ldisc instead (eg PPP) can > you reproduce it the

3.4.10 N_GSM tty_io WARNING and lockup

Hi, I'm trying to use GSM tty line discipline. Basically echo AT+CMUX=0 > /dev/ttyS0 set termios (speed etc.) int ldisc = N_GSM0710; ioctl(fd, TIOCSETD, &ldisc); ... The ioctl first fails with EIO (probably due to inactive DCD line) in tty_set_ldisc(): if (test_bit(TTY_HUPPED, &tty->f

<    1   2