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

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

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: 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: [PATCH] [media] tw686x-kh: Delete an unnecessary check before the function call "video_unregister_device"

SF Markus Elfring writes: > The video_unregister_device() function tests whether its argument is NULL > and then returns immediately. Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring > --- > drivers/stag

Re: Aw: BUG: Wrong dma queue handling in ixp4 driver

Hi Lino, "Lino Sanfilippo" writes: >> maybe I miss something, but the ixp4 ethernet driver seems to handle dma >> pools >> in a wrong way: In init_queues() it creates a dma pool for descriptors and >> then >> only allocates a single descriptor from this pool. The author seems to >> assume t

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

Hans Verkuil writes: > That was probably the reason for the pci_read_config_word in the reg_write > code. Try putting that back (and just that). Yes. I guess a single pci_read_config_word() would suffice. Though it would obviously be much better to identify the place in the driver which needs t

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

Andrey Utkin writes: > It happens in solo_disp_init at uploading default motion thresholds > array. > > I've got a prints trace with solo6010-fix-lockup branch > https://github.com/bluecherrydvr/linux/tree/solo6010-fix-lockup/drivers/media/pci/solo6x10 > the trace itself in jpg: > https://decent.

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

Andrey Utkin writes: > On Thu, Sep 22, 2016 at 10:51:37AM +0200, Krzysztof Hałasa wrote: >> I wonder if the following fixes the problem (completely untested). > > I have given this a run, and it still hangs. Does (only) adding the pci_read_config_word(solo_dev->pdev

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

Andrey Utkin writes: >> Does (only) adding the >> >> pci_read_config_word(solo_dev->pdev, PCI_STATUS, &val); >> >> in solo_reg_write() help? > > Yes. > I have posted a patch with this change few days ago, I thought you have > noticed it. Well, I think you haven't sent me a copy. Anyway, i

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

Andrey Utkin writes: >> Can you share some details about the machine you are experiencing the >> problems on? CPU, chipset? I'd try to see if I can recreate the problem. > > See solo.txt.gz attached. Thanks. I can see you have quite a set of video devices there. I will see what I can do with thi

Re: [PATCH] ARM: remove duplicate 'const' annotations'

ot;, > &cns3xxx_usb_ehci_pdata }, > { "intel,usb-ohci", CNS3XXX_USB_OHCI_BASE, "ohci-platform", > &cns3xxx_usb_ohci_pdata }, > { "cavium,cns3420-ahci", CNS3XXX_SATA2_BASE, "ahci", NULL }, Acked-by: Krzysztof Hałasa -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland

[PATCH] ARM i.MX: Fix a kernel panic in i2c_imx_clk_notifier_call().

Signed-off-by: Krzysztof Halasa --- a/drivers/i2c/busses/i2c-imx.c +++ b/drivers/i2c/busses/i2c-imx.c @@ -510,9 +510,9 @@ static int i2c_imx_clk_notifier_call(struct notifier_block *nb, unsigned long action, void *data) { struct clk_notifier_data *nd

Re: [PATCH] ARM i.MX: Fix a kernel panic in i2c_imx_clk_notifier_call().

Hi Fabio, Fabio Estevam writes: > Please provide a commit log, giving some context to your fix. Well, I hope Lucas could add something here. I am uncertain how it was supposed to work, the ndata->clk (the pointer, not the clk pointed by it) can't be at the same time a member of imx_i2c_struct,

[PATCH] ARM i.MX: Fix a kernel panic in i2c_imx_clk_notifier_call().

90ad2cbe88c22d0215225ab9594eeead0eb24fde changed the i.MX I2C bus driver to use a notifier whenever the base clock ("ipg" - 66 MHz peripheral clock) rate changes. Unfortunately one can't use the container_of() macro this way - the first argument has to point to a member of the bigger struct (last

Re: On register r/w macros/procedures of drivers/media/pci

Andrey Utkin writes: > I am starting a work on driver for techwell tw5864 media grabber&encoder. If this is tw6864 then I have a driver mostly completed. Actually I'm using tw6869 but I think this is very similar (4 channels instead of 8 and PCI instead of PCIe). I have 6864s but haven't yet tri

Re: On register r/w macros/procedures of drivers/media/pci

Andrey Utkin writes: > Please check first digit. I mean _5_864, in your post there's 6869. Ok, I just thought it may be a typo. I can now see 5864 is a H.264 encoder, while 686x are simpler frame-grabbers only. Sorry for the noise. -- Krzysztof Halasa Research Institute for Automation and Mea

Re: [PATCH] ARM: cns3xxx: pci: avoid potential stack overflow

Arnd Bergmann writes: > The cns3xxx_pcie_hw_init function uses excessive kernel > stack space because of a hack that puts a fake struct > pci_sys_data and struct pci_bus on the stack in order to > call the generic pci_bus_read_config accessors, which causes > a warning in ARM allmodconfig builds:

[PATCH] Add PCI ID and quirk for Intersil/Techwell TW686[4589] AV capture cards.

Intersil/Techwell TW686[4589]-based video capture cards have an empty (zero) class code. Fix it. Signed-off-by: Krzysztof Hałasa --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -3662,6 +3662,26 @@ DECLARE_PCI_FIXUP_HEADER(0x1283, 0x8892, quirk_use_pcie_bridge_dma_alias

Coding style details

Hi, a simple question: which style is preferred? #define REG8_1(a0) ((const u16[8]){a0, a0 + 1, a0 + 2, a0 + 3}) vs #define REG8_1(a0) ((const u16[8]) {a0, a0 + 1, a0 + 2, a0 + 3}) ^ -- Krzysztof Halasa Industrial Research Institute for Automation and Measu

[PATCH] MEDIA PCI Kconfig ANALOG_TV -> CAMERA

eal camera in a laptop) but it at least doesn't select the TUNERs. Perhaps the following patch would make sense. Signed-off-by: Krzysztof Hałasa --- a/drivers/media/pci/Kconfig +++ b/drivers/media/pci/Kconfig @@ -11,16 +11,16 @@ if MEDIA_PCI_SUPPORT if MEDIA_CAMERA_SUPPORT comment &q

Re: Coding style details (checkpatch)

Frans Klaver writes: >> #define REG8_1(a0) ((const u16[8]){a0, a0 + 1, a0 + 2, a0 + 3}) >> >> vs >> >> #define REG8_1(a0) ((const u16[8]) {a0, a0 + 1, a0 + 2, a0 + 3}) >> ^ > > The prescribed style is to have no space between cast and castee. So, > the top opti

Re: Coding style details (checkpatch)

Frans Klaver writes: > Ah, right. One might say that this is a false positive, but that's up > to Joe or Andy I guess. > > It may be valid C code, but I think this construction is slightly > funky to begin with. > > Which file is this? A new file, not yet sent anywhere. -- Krzysztof Halasa Ind

Re: Coding style details (checkpatch)

Joe Perches writes: > How is the macro used? > #define REG8_1(a0) ((const u16[8]){a0, a0 + 1, a0 + 2, a0 + 3}) #define REG8_1(a0) ((const u16[8]){a0, a0 + 1, a0 + 2, a0 + 3, a0 + 4, a0 + 5, a0 + 6, a0 + 7}) #define REG8_2(a0) ((const u16[8]){a0, a0 + 2, a0 + 4, a0 + 6, a0 + 8, a0 + 0xA, a0 + 0

Re: [PATCH] Add PCI ID and quirk for Intersil/Techwell TW686[4589] AV capture cards.

Bjorn Helgaas writes: >> Intersil/Techwell TW686[4589]-based video capture cards have an empty >> (zero) class code. Fix it. >> > Applied to pci/misc for v4.2, with minor tweak as below to use > PCI_CLASS_MULTIMEDIA_OTHER instead of a bare number. Let me know > if you see any issues with this.

Re: Coding style details (checkpatch)

Joe Perches writes: > It might be better to use some base + index macro > as it could be smaller object code. > > Something like: > > #define REG_NO(base, multiplier, index) (base + (multiplier * index)) > > reg_write(vc->dev, REG_NO(0x10, 1, vc->ch), dma_cfg); > or > > #define VDMA_C

Re: Coding style details (checkpatch)

Joe Perches writes: > #define VDREG8(a0) ((const u16[]){\ > a0 + 0x000, a0 + 0x010, a0 +0x020, a0 + 0x030, \ > a0 + 0x100, a0 + 0x110, a0 +0x120, a0 + 0x130}) > > as "const u16[]" is a $Type but "const u16[]" is not. > > Still, as written, the code seems fragile a

Re: [PATCH] arch: arm: Kconfig: pedantic formatting

"Enrico Weigelt, metux IT consult" writes: > Formatting of Kconfig files doesn't look so pretty, so let the > Great White Handkerchief come around and clean it up. > > Signed-off-by: Enrico Weigelt, metux IT consult > --- > arch/arm/mach-ixp4xx/Kconfig | 32 ++--- Acked

Re: [v2] Old platforms: bring out your dead

Arnd, Arnd Bergmann writes: > For these I received no reply yet. Again, these will stay for the moment > unless I get a reply, but if anyone has more information, please reply > here to document the status (adding a few more people to Cc): > > * cns3xxx -- added in 2010, last fixed in 2019, prob

Re: RFC: dt-binding: media: document ON Semi AR0521 sensor bindings

ny of the regexes: 'pinctrl-[0-9]+' From schema: /usr/src/linux/imx6/Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml Thus I'm currently leaving it as is. -- Krzysztof Hałasa Sieć Badawcza Łukasiewicz Przemysłowy Instytut Automatyki i Pomiarów PIAP Al. Jerozolimskie 202, 02-486 Warszawa

Re: RFC: MEDIA: Driver for ON Semi AR0521 camera sensor

nts on the pixel clock as well (the active scanning must be as fast as possible, which means fast pixel clock, minimum possible hblank and thus long vblank). All comments are appreciated. -- Krzysztof Hałasa Sieć Badawcza Łukasiewicz Przemysłowy Instytut Automatyki i Pomiarów PIAP Al. Jerozolimskie 202, 02-486 Warszawa

Re: [PATCH -next] soc: ixp4xx: qmgr: Use DEFINE_SPINLOCK() for spinlock

_lock); > > dev_info(dev, "IXP4xx Queue Manager initialized.\n"); > return 0; -- Krzysztof Hałasa Sieć Badawcza Łukasiewicz Przemysłowy Instytut Automatyki i Pomiarów PIAP Al. Jerozolimskie 202, 02-486 Warszawa

RFC: dt-binding: media: document ON Semi AR0521 sensor bindings

This file documents DT bindings for the AR0521 camera sensor driver. Signed-off-by: Krzysztof Halasa diff --git a/Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml b/Documentation/devicetree/bindings/media/i2c/onnn,ar0521.yaml new file mode 100644 index ..f649d4cbcb37 ---

RFC: MEDIA: Driver for ON Semi AR0521 camera sensor

Is there a reliable way to include national unicode characters in the kernel sources? For review only. This will be signed off when (if) the driver is accepted. diff --git a/MAINTAINERS b/MAINTAINERS index bfc1b86e3e73..20514c00909b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1294,6 +1294,12 @

Re: RFC: dt-binding: media: document ON Semi AR0521 sensor bindings

Laurent, Laurent Pinchart writes: >> +const: on-semi,ar0521 > > That's not the correct prefix for ON Semiconductor. See > Documentation/devicetree/bindings/vendor-prefixes.yaml. Or just the name > of this file :-) Right, just missed this one. Thanks for the comments. -- Krzysztof Halasa S

Re: RFC: MEDIA: Driver for ON Semi AR0521 camera sensor

gulators when starting streaming ? > > I forgot to mention in the review of the DT bindings that regulators > should be specified in DT. Why? The hw using this driver doesn't have capability to disable regulators. If someone produces hw with means to control power, the sw support can be trivially added. When I last checked, we didn't add driver code for functionality for which no hw support exists, did we? -- Krzysztof Hałasa Sieć Badawcza Łukasiewicz Przemysłowy Instytut Automatyki i Pomiarów PIAP Al. Jerozolimskie 202, 02-486 Warszawa

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] CNS3xxx: Fix PCIe early iotable_init().

Arnd Bergmann writes: > Patch looks good, but please add the changeset description from > your first patch. I wonder if another approach would be better. I don't like the .pfn messing and the bugs that function introduces. -- Krzysztof Halasa Research Institute for Automation and Measurements

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

This patch fixes the following BUG: > kernel BUG at mm/vmalloc.c:1132! > PC is at vm_area_add_early+0x20/0x84 > LR is at add_static_vm_early+0xc/0x60 > > The problem is cns3xxx_pcie_init() (device_initcall) calls the "early" > iotable_init(). Instead of merely calling the PCIe iotable_init() from

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

khal...@piap.pl (Krzysztof Hałasa) writes: > This patch fixes the following BUG: > >> kernel BUG at mm/vmalloc.c:1132! >> PC is at vm_area_add_early+0x20/0x84 >> LR is at add_static_vm_early+0xc/0x60 >> >> The problem is cns3xxx_pcie_init() (device_initcal

[PATCH2] CNS3xxx: Fix a WARN() related to IRQ allocation.

off-by: Krzysztof Hałasa -- 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...@vger.kernel.org More majo

[PATCH2] CNS3xxx: Fix a WARN() related to IRQ allocation.

off-by: Krzysztof Hałasa --- a/arch/arm/mach-cns3xxx/cns3420vb.c +++ b/arch/arm/mach-cns3xxx/cns3420vb.c @@ -246,7 +246,6 @@ static void __init cns3420_map_io(void) MACHINE_START(CNS3420VB, "Cavium Networks CNS3420 Validation Board") .atag_offset= 0x100, -

[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

[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

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 %

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

Arnd Bergmann writes: > Applied to next/fixes-non-critical. > > Since the problem is not new and you didn't mark the patch as 'stable', > this seems to be the right place. Let us know if you need backports > to stable kernels, also fo the other patch. Sure, BTW there is also that problem with PC

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

[PATCH] Fix unbalanced mutex in dma_pool_create().

dma_pool_create() needs to unlock the mutex in error case. The bug has been present starting with v3.16-rc1 (cc6b664a). Signed-off-by: Krzysztof Hałasa Cc: sta...@vger.kernel.org --- a/mm/dmapool.c +++ b/mm/dmapool.c @@ -174,11 +174,11 @@ struct dma_pool *dma_pool_create(const char *name

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

[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

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

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

[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: 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

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)

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: [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: 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 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.

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] Extend PCIE_BUS_PEER2PEER to set MRSS=128 to fix CNS3xxx BM DMA.

Bjorn Helgaas writes: > It looks like 498a92d42596 merely fixed a warning, at the expense of > breaking DMA on Cavium. Reverting it would bring the warning back, but > that's better than broken DMA. Perhaps we should change PCIE_BUS_PEER2PEER to also write MRRS anyway. I realize the CNS3xxx pa

Re: [PATCH] ixp4xx_hss: Delete an unnecessary check before the function call "dma_pool_destroy"

SF Markus Elfring writes: > The dma_pool_destroy() function tests whether its argument is NULL > and then returns immediately. Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > --- a/drivers/net/wan/ixp4xx_hss.c > +++ b/drivers/net/wan/i

Re: [PATCH] ixp4xx_eth: Delete an unnecessary check before the function call "dma_pool_destroy"

SF Markus Elfring writes: > The dma_pool_destroy() function tests whether its argument is NULL > and then returns immediately. Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > --- a/drivers/net/ethernet/xscale/ixp4xx_eth.c > +++ b/drive

Re: [PATCH] ARM: ixp4xx: fix read{b,w,l} return types

Arnd Bergmann writes: > On ixp4xx, the readl() function returns an 'unsigned long' output > when indirect I/O is used. This is unlike any other platform, and > it causes lots of harmless compiler warnings, such as: > > drivers/ata/libahci.c: In function 'ahci_show_host_version': > drivers/ata/lib

Re: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio

Arnd Bergmann writes: > ixp4xx is really special in that it performs hardware swapping for > internal devices based on CPU endianess but not on PCI devices. Again, IXP4xx does not perform hardware (nor any other) swapping for registers of on-chip devices. The registers are connected 1:1, bit 0 t

Re: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio

Arnd Bergmann writes: > Ok, so I guess what this means is that ixp4xx (or xscale in general) > implements its big-endian mode by adding a byteswap on its DRAM > and PCI interfaces in be32 mode, rather than by changing the behavior of > the load/store operations (as be8 mode does) or by having the

[PATCH] Fix NULL ptr dereference in pci_bus_assign_domain_nr() on ARM

without a parent. This patch fixes the NULL pointer dereference. Signed-off-by: Krzysztof Hałasa Cc: sta...@vger.kernel.org diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 602eb42..f89db3a 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -4772,8 +4772,10 @@ int

Re: [PATCH] ARM: drop unused Makefile.boot of Multiplatform SoCs

Masahiro Yamada writes: > The variable "MACHINE" is empty if CONFIG_ARCH_MULTIPLATFORM=y, > so these Makefile.boot files are never included. > > Signed-off-by: Masahiro Yamada > --- > > arch/arm/mach-cns3xxx/Makefile.boot | 3 --- Acked-by: Krzysztof Hałasa -

Re: [PATCH 1/3] ARM: ixp4xx: use normal prototype for {read,write}s{b,w,l}

her definitions of the same functions pass void pointers, > so doing the same here avoids the warnings. > > Signed-off-by: Arnd Bergmann > --- > arch/arm/mach-ixp4xx/include/mach/io.h | 23 +-- > 1 file changed, 17 insertions(+), 6 deletions(-) Acked-by:

Re: [PATCH 2/3] ARM: ixp4xx: avoid warning about ioport_map() macro argument processing

gt; around '+' in operand of '&' [-Wparentheses] > io_mem = ioport_map(ioport & ~3, NETCARD_IO_EXTENT); > > Simply adding parentheses in the macro avoids the warning > > Signed-off-by: Arnd Bergmann > --- > arch/arm/mach-ixp4xx/include/mach/io.h | 2 +-

Re: [PATCH 3/3] ARM: ixp4xx: move indirect I/O into common-pci.c

x/common-pci.c | 98 > ++ > arch/arm/mach-ixp4xx/include/mach/io.h | 95 +++----- > 2 files changed, 104 insertions(+), 89 deletions(-) Acked-by: Krzysztof Hałasa -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland

Re: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio

Arnd Bergmann writes: >> Anyway, I think readl()/writel() do the right thing: in BE mode they >> swap PCI accesses and don't swap normal registers, in LE mode nothing is >> swapped. > > This seems to be true when CONFIG_IXP4XX_INDIRECT_PCI is set, but > not otherwise. For the indirect variant, wr

Re: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio

Arnd Bergmann writes: > I consider the use of __raw_* accessors a bug, I don't think we should > ever do that because it hides how the hardware actually works, it doesn't > work with spinlocks, and it can lead to the compiler splitting up accesses > into byte sized ones (not on ARM with the curre

Re: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio

Arnd Bergmann writes: > The barriers on a spinlock synchronize between CPUs but not an external > bus, so (on some architectures) a spinlock protecting an MMIO register > does not guarantee that two CPUs doing > > spin_lock(); > __raw_writel(address); > __raw_writel(data); >

Re: [PATCH v2 01/15] arm: use of_platform_default_populate() to populate default bus

Kefeng Wang writes: > Use helper of_platform_default_populate() in linux/of_platform > when possible, instead of calling of_platform_populate() with > the default match table. > --- a/arch/arm/mach-cns3xxx/core.c > +++ b/arch/arm/mach-cns3xxx/core.c > @@ -395,8 +395,7 @@ static void __init cns3xx

Re: [PATCH 3/7] usb: gadget: pxa25x_udc: use readl/writel for mmio

Arnd Bergmann writes: > Both writes leave the CPU core within the spinlock but are not serialized > with anything else, so there is no ordering between the CPUs when they > enter the shared bus, other than having address before data. You'd > expect to see address0, data0, address1, data1, but it

Re: [PATCH 14/15] ARM: cns3xxx: don't export static symbol

Arnd Bergmann writes: > Looks good. Krzysztof, do you want to pick this up and send me a > pull request together with other patches, or should I apply this > to the arm-soc fixes directly? The latter, please. Acked-by: Krzysztof Hałasa -- Krzysztof Halasa Research Institute for A

Re: [PATCH 06/16] ARM: cns3xxx: convert PCI to use generic config accesses

Rob Herring writes: > Convert the cns3xxx PCI driver to use the generic config access functions. > > This changes accesses from __raw_readl/__raw_writel to readl/writel. > > arch/arm/mach-cns3xxx/pcie.c | 52 > +--- This looks fine: A

Re: [PATCH] net:wan:Change location of debug printk statement in the function,hss_hdlc_poll

Nicholas Krause writes: > This changes the location of the printk for montioring if the stucture pointer > desc of type structure desc has a error count due to failing in the switch > statement for checking it's status from the default switch case in this switch > to the area of the function for

Re: [PATCH 08/11] ARM: ixp4xx: fix {in,out}s{bwl} data types

Arnd Bergmann writes: > Most platforms use void pointer arguments in these functions, but > ixp4xx does not, which triggers lots of warnings in device drivers like: > > net/ethernet/8390/ne2k-pci.c: In function 'ne2k_pci_get_8390_hdr': > net/ethernet/8390/ne2k-pci.c:503:3: warning: passing argume

Re: [PATCH 4/4] ARM: remove duplicate const qualifier

Eric Engestrom writes: > I can't confirm it (haven't tried), and don't care enough to do it :] > I guess I'm just dropping the patch then. Like I said, it can't hurt to > leave them in. Actually it may hurt (a little bit) - it makes the code less readable. -- Krzysztof Halasa Industrial Resear

Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity

Lucas Stach writes: >> TW6869: PCI :04:00.0, IRQ 336, MMIO 0x110 >> TW686x :04:00.0: enabling device (0140 -> 0142) >> > I don't see whee the device even tries to use MSI IRQs. Even if the > infrastructure is enabled it opts to use legacy INTA. It only tries to use normal IRQ. > The

Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity

Tim, > So perhaps there is something else going on with the tw8689 > device/driver that is causing it to not work with MSI. We have an > avc8000 miniPCIe with tw8689 here and can test if you send me your > patches that enable tw8689 with msi. I think you can use this: http://git.linuxtv.org/hverk

Re: [PATCH] defines modified to match the 80-char rule

Mario Bambagini writes: > Defines have been written in more than one line to match the 80-character > rule. This error has been fixed 6 times in this file. > The file is fully compliant with respect to the coding rules now. Rules, maybe. But is it better, i.e., more readable? > --- a/drivers/st

Re: [PATCH] defines modified to match the 80-char rule

Joe Perches writes: > -#define LCONSOLE(mask, format, ...) CDEBUG(D_CONSOLE | (mask), format, ## > __VA_ARGS__) > -#define LCONSOLE_INFO(format, ...) CDEBUG_LIMIT(D_CONSOLE, format, ## > __VA_ARGS__) > -#define LCONSOLE_WARN(format, ...) CDEBUG_LIMIT(D_CONSOLE | D_WARNING, > format, ## __VA_

Re: [PATCH v2] ARM: cns3xxx: pci: avoid potential stack overflow

/pcie.c | 71 > + I'm ATM unable to test this change, but will do that at some point. Meanwhile, I guess there is nothing I can say against this patch. Thanks. Acked-by: Krzysztof Hałasa -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. J

Re: H264 headers generation for driver

Andrey Utkin writes: [H.264 headers] > I guess that one acceptable way is to pre-generate all headers for all > needed cases and ship them inlined; for correctness checking purpose, > it is possible to ship also a script or additional source code file > which is able to generate same headers. I

[PATCH] 802.11n IBSS: wlan0 stops receiving packets due to aggregation after sender reboot

tid_rx->head_seq_num = start_seq_num; status = WLAN_STATUS_SUCCESS; - else + } else status = WLAN_STATUS_REQUEST_DECLINED; rcu_read_unlock();

802.11n IBSS: wlan0 stops receiving packets due to aggregation after sender reboot

KERN_DEBUG "SEQ BAD: %u vs %u\n", mpdu_seq_num, head_seq_num); dev_kfree_skb(skb); goto out; - } + } else + printk(KERN_DEBUG "SEQ OK: %u vs %u\n", mpdu_seq_num, head_seq_num); /* * If frame the sequence number exceed

[PATCH] 802.11n IBSS: wlan0 stops receiving packets due to aggregation after sender reboot

rcu_read_unlock(); goto end; -- Krzysztof Hałasa ŁUKASIEWICZ Research Network Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland

Re: [PATCH 2/2] ARM: ixp4xx: include linux/mtd/platnand.h

Arnd Bergmann writes: > The platform_nand_data structure definition is required for ixdp425 > but has now moved to a new header file: > > arch/arm/mach-ixp4xx/ixdp425-setup.c:98:15: error: variable > 'ixdp425_flash_nand_data' has initializer but incomplete type > static struct platform_nand_dat

Re: [PATCH] Revert "ARM: cns3xxx: pci: avoid potential stack overflow"

Payload Size set to 128/ 128 (was 128), Max Read Rq 128 Signed-off-by: Krzysztof Hałasa Fixes: 498a92d42596 ("ARM: cns3xxx: pci: avoid potential stack overflow") diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 6d7ab9b..91713b6 100644 --- a/drivers/pci/probe.c +++ b/driv

Re: [PATCH] Revert "ARM: cns3xxx: pci: avoid potential stack overflow"

Arnd Bergmann writes: > Before that, we were always setting both mrrs and mps. As we don't know > who uses PCIE_BUS_PEER2PEER, maybe another option would be to add yet > another pcie_bus_config value for this particular quirk? It would be a safe approach. Or, maybe another non-pcie_bus_config th

Re: [PATCH] Revert "ARM: cns3xxx: pci: avoid potential stack overflow"

Arnd Bergmann writes: > I'd start by copying the relevant nodes from > arch/arm/boot/dts/arm-realview-pb11mp.dts, which is the closest > I can think of. I've put together something completely untested > below. Thanks. I will try to handle that. 3+ weeks, unfortunately. Now, what do we do with t

Re: [PATCH] Revert "ARM: cns3xxx: pci: avoid potential stack overflow"

: Arnd Bergmann > CC: Krzysztof Hałasa > --- > arch/arm/mach-cns3xxx/pcie.c | 71 > -- > 1 file changed, 41 insertions(+), 30 deletions(-) This, applied to v4.7-rc1, fixes the problem on my Laguna boards. Tested-by: Krzysztof Hałasa And

[i.MX6 DRM IPUv3] Regression 4.9-rc5: greenish screen with YUV420 video

Hi, The following GStreamer pipeline causes screen to become green with v4.9-rc4+: gst-launch-1.0 udpsrc uri=udp://239.1.2.2:5100 reuse=true caps="application/x-rtp,media=(string)video,clock-rate=(int)9,encoding-name=(string)H264" ! rtph264depay ! h264parse ! v4l2video1dec capture-io-mode=d

Re: [PATCH 01/15] net: phy: Add phy_ethtool_nway_reset

Hi, Florian Fainelli writes: > This function just calls into genphy_restart_aneg() to perform an > autonegotation restart. > > +int phy_ethtool_nway_reset(struct net_device *ndev) > +{ > + struct phy_device *phydev = ndev->phydev; > + > + if (!phydev) > + return -ENODEV; > +

[PATCH 4.9.0-rc5] AR9300 calibration problems with antenna selected

Hi, I recently tried to select a single antenna on AR9300 and it works for 30 seconds only. The subsequent calibration makes the RX signal level to drop from the usual -30/-40 dBm to -70/-80 dBm, and the transmission practically stops. With the attached patch it works, though selecting the antenn

Re: [PATCH net-next 3/6] net: use core MTU range checking in WAN drivers

Jarod Wilson writes: > - set min/max_mtu in all hdlc drivers, remove hdlc_change_mtu > - sent max_mtu in lec driver, remove lec_change_mtu > drivers/net/wan/c101.c| 1 - > drivers/net/wan/hdlc.c| 11 ++- > drivers/net/wan/hdlc_fr.c | 3 ++- > drivers/ne

Re: [PATCH v2] media: solo6x10: fix lockup by avoiding delayed register write

Andrey Utkin writes: > --- a/drivers/media/pci/solo6x10/solo6x10.h > +++ b/drivers/media/pci/solo6x10/solo6x10.h > @@ -284,7 +284,10 @@ static inline u32 solo_reg_read(struct solo_dev > *solo_dev, int reg) > static inline void solo_reg_write(struct solo_dev *solo_dev, int reg, >

  1   2   >