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

handlers[QUEUES])(void *pdev); > static void *irq_pdevs[QUEUES]; > @@ -434,7 +434,6 @@ static int ixp4xx_qmgr_probe(struct platform_device *pdev) > } > > used_sram_bitmap[0] = 0xF; /* 4 first pages reserved for config */ > - spin_lock_init(_lock); > >

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: RFC: dt-binding: media: document ON Semi AR0521 sensor bindings

es: '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

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

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

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

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,

Re: [PATCH net v2] drivers/net/wan/hdlc_fr: Add needed_headroom for PVC devices

Xie He writes: > The HDLC device is not actually prepending any header when it is used > with this driver. When the PVC device has prepended its header and > handed over the skb to the HDLC device, the HDLC device just hands it > over to the hardware driver for transmission without prepending

Re: [PATCH net] drivers/net/wan/hdlc_cisco: Add hard_header_len

Hello Xie, Xie He writes: > This driver didn't set hard_header_len. This patch sets hard_header_len > for it according to its header_ops->create function. BTW it's 4 bytes long: struct hdlc_header { u8 address; u8 control; __be16 protocol; }__packed; OTOH

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

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

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

m, 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 exceeds our buffering window -- Krzysztof Hałasa ŁUKASIEWI

[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();

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 ++---

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

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().

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

[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

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

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

Re: [PATCH 01/12] ARM: ixp4xx: fix ioport_unmap definition

Arnd Bergmann writes: > An empty macro definition can cause unexpected behavior, in > case of the ixp4xx ioport_unmap, we get two warnings: > > drivers/net/wireless/marvell/libertas/if_cs.c: In function 'if_cs_release': > drivers/net/wireless/marvell/libertas/if_cs.c:826:3: error:

Re: [PATCH 01/12] ARM: ixp4xx: fix ioport_unmap definition

Arnd Bergmann writes: > An empty macro definition can cause unexpected behavior, in > case of the ixp4xx ioport_unmap, we get two warnings: > > drivers/net/wireless/marvell/libertas/if_cs.c: In function 'if_cs_release': > drivers/net/wireless/marvell/libertas/if_cs.c:826:3: error: suggest braces

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

m", > _usb_ehci_pdata }, > { "intel,usb-ohci", CNS3XXX_USB_OHCI_BASE, "ohci-platform", > _usb_ohci_pdata }, > { "cavium,cns3420-ahci", CNS3XXX_SATA2_BASE, "ahci", NULL }, Acked-by: Krzysztof Hałasa <khal...@piap.pl> -- Krzyszt

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

}, > { "intel,usb-ohci", CNS3XXX_USB_OHCI_BASE, "ohci-platform", > _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

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

Philipp Zabel writes: > I had already (accidentally) fixed this with 3fd8b292ae6b ("drm/imx: > ipuv3-plane: merge ipu_plane_atomic_set_base into atomic_update"). Thanks, I've merged your pza/imx-drm/next and it now works. -- Krzysztof Halasa Industrial Research

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

Philipp Zabel writes: > I had already (accidentally) fixed this with 3fd8b292ae6b ("drm/imx: > ipuv3-plane: merge ipu_plane_atomic_set_base into atomic_update"). Thanks, I've merged your pza/imx-drm/next and it now works. -- Krzysztof Halasa Industrial Research Institute for Automation and

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

miaoq...@codeaurora.org writes: >> rmmod ath9k >> modprobe ath9k >> iw dev wlan0 set type ibss >> iw phy phyX set antenna 2 > > 2 is a bad mask. We use bitmap, the valid masks are 1, 3, 7. Thanks for your response. I have two antenna connections (and a single antenna). Is it possible to select

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

miaoq...@codeaurora.org writes: >> rmmod ath9k >> modprobe ath9k >> iw dev wlan0 set type ibss >> iw phy phyX set antenna 2 > > 2 is a bad mask. We use bitmap, the valid masks are 1, 3, 7. Thanks for your response. I have two antenna connections (and a single antenna). Is it possible to select

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) > +

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; > +

[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

[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

[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

[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

Super Top USB SD card reader resets and corruption - XHCI

Hi, I came across a problem with an USB SD card reader apparently causing USB resets and corrupting data on the card. The reader in question is a very cheap: 14cd:1212 Super Top microSD card reader (SY-T18) The card is an old SDHC, 32 GB, Sandisk brand. The problems don't seem to exist now if

Super Top USB SD card reader resets and corruption - XHCI

Hi, I came across a problem with an USB SD card reader apparently causing USB resets and corrupting data on the card. The reader in question is a very cheap: 14cd:1212 Super Top microSD card reader (SY-T18) The card is an old SDHC, 32 GB, Sandisk brand. The problems don't seem to exist now if

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

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, >

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 |

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 ++- >

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

Andrey Utkin writes: > Lockup happens only on 6010. In provided log you can see that 6110 > passes just fine right before 6010. Also if 6010 PCI ID is removed from > solo6x10 driver's devices list, the freeze doesn't happen. Probably explains why I don't see lockups

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

Andrey Utkin writes: > Lockup happens only on 6010. In provided log you can see that 6110 > passes just fine right before 6010. Also if 6010 PCI ID is removed from > solo6x10 driver's devices list, the freeze doesn't happen. Probably explains why I don't see lockups :-) I will have a look. --

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

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

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, ); >> >> 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

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, ); >> >> 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, it

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

Andrey Utkin <andrey_ut...@fastmail.com> 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

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-&g

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

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

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

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

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

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

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:

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

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

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

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

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

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

t to 128/ 512 (was 128), Max Read Rq 128 pci 0001:00:00.0: Max Payload Size set to 128/ 128 (was 128), Max Read Rq 128 Signed-off-by: Krzysztof Hałasa <khal...@piap.pl> Fixes: 498a92d42596 ("ARM: cns3xxx: pci: avoid potential stack overflow") diff --git a/drivers/pci/probe.c b/

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/drivers/p

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

by: Bjorn Helgaas <bhelg...@google.com> > CC: Arnd Bergmann <a...@arndb.de> > CC: Krzysztof Hałasa <khal...@piap.pl> > --- > arch/arm/mach-cns3xxx/pcie.c | 71 > -- > 1 file changed, 41 insertions(+), 30 deletions(-) This

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

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

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

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

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

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:

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:

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

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

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

Lucas Stach writes: > Is this working with v4.4 and PCI_MSI enabled? I'm sure I've tested MSI > IRQs before enabling them in the defconfig and they have been working > for me for a long time before that. Tested with i210 on Gateworks > Ventana. MSI never worked for me on

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

Lucas Stach writes: > Is this working with v4.4 and PCI_MSI enabled? I'm sure I've tested MSI > IRQs before enabling them in the defconfig and they have been working > for me for a long time before that. Tested with i210 on Gateworks > Ventana. MSI never worked for me on Ventana. I have been

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

> OTOH, we should fix it some day, making sure the DTS files are fixed > first: > > imx6qdl-apf6dev.dtsi: reset-gpio = < 2 GPIO_ACTIVE_HIGH>; > imx6qdl-aristainetos2.dtsi: reset-gpio = < 16 GPIO_ACTIVE_HIGH>; > imx6qdl-hummingboard.dtsi: reset-gpio = < 4 0>; (I think RMK already > handles

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

> OTOH, we should fix it some day, making sure the DTS files are fixed > first: > > imx6qdl-apf6dev.dtsi: reset-gpio = < 2 GPIO_ACTIVE_HIGH>; > imx6qdl-aristainetos2.dtsi: reset-gpio = < 16 GPIO_ACTIVE_HIGH>; > imx6qdl-hummingboard.dtsi: reset-gpio = < 4 0>; (I think RMK already > handles

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

Fabio Estevam writes: > In order to keep old dtb's working we should simply ignore the GPIO > flags passed in the 'reset-gpio' property. > > That's why we need a revert. Just sent a v2, BTW. OTOH, we should fix it some day, making sure the DTS files are fixed first:

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

Fabio Estevam writes: > In order to keep old dtb's working we should simply ignore the GPIO > flags passed in the 'reset-gpio' property. > > That's why we need a revert. Just sent a v2, BTW. OTOH, we should fix it some day, making sure the DTS files are fixed first: imx6qdl-apf6dev.dtsi:

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

Tim Harvey writes: > It's not too easy to tell how many IMX6 boards incorrectly specify > their reset-gpio polarity. I don't know what the best way to determine > what boards use the IMX6 pcie host controller. Is there a dtc usage > that will display the compiled dtb's

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

Tim Harvey writes: > It's not too easy to tell how many IMX6 boards incorrectly specify > their reset-gpio polarity. I don't know what the best way to determine > what boards use the IMX6 pcie host controller. Is there a dtc usage > that will display the compiled dtb's then we grep out

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

Tim Harvey writes: > ok - I'll respond there as I agree with the patch but not the wording > of the commit (It's Gateworks 'Ventana' using IMX6 not Laguna and we > do define the polarity properly as active-low in Ventana dt's). Right, it's Ventana of course (I had been

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

Tim Harvey writes: > ok - I'll respond there as I agree with the patch but not the wording > of the commit (It's Gateworks 'Ventana' using IMX6 not Laguna and we > do define the polarity properly as active-low in Ventana dt's). Right, it's Ventana of course (I had been working with Laguna

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

f8..0x01f8 -> 0x MEM 0x0100..0x01ef -> 0x0100 imx6q-pcie 1ffc000.pcie: phy link never came up Signed-off-by: Krzysztof Hałasa <khal...@piap.pl> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c index fe60096..f17fb02 100644 --- a/drivers/pci

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

f8..0x01f8 -> 0x MEM 0x0100..0x01ef -> 0x0100 imx6q-pcie 1ffc000.pcie: phy link never came up Signed-off-by: Krzysztof Hałasa diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c index fe60096..f17fb02 100644 --- a/drivers/pci/host/pci-imx6.c +++ b/

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

Bjorn Helgaas writes: >> At least CNS3xxx doesn't boot. I haven't verified a couple of others, >> but they may be broken as well. > > Good, thanks. Also (I should have asked this before), please include a > "Fixes:" line so we know exactly when this broke and what stable

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

Bjorn Helgaas writes: >> At least CNS3xxx doesn't boot. I haven't verified a couple of others, >> but they may be broken as well. > > Good, thanks. Also (I should have asked this before), please include a > "Fixes:" line so we know exactly when this broke and what stable kernels > need the fix.

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

Hi Bjorn, Bjorn Helgaas <helg...@kernel.org> writes: > On Tue, Mar 01, 2016 at 07:07:18AM +0100, Krzysztof Hałasa wrote: >> Many ARM platforms use a wrapper: >> /* >> * Compatibility wrapper for older platforms that do not care about >> * passing the parent dev

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

Hi Bjorn, Bjorn Helgaas writes: > On Tue, Mar 01, 2016 at 07:07:18AM +0100, Krzysztof Hałasa wrote: >> Many ARM platforms use a wrapper: >> /* >> * Compatibility wrapper for older platforms that do not care about >> * passing the parent device. >> */ >

[PATCH] CNS3xxx: remove unused *_VIRT definitions

Signed-off-by: Krzysztof Hałasa <khal...@piap.pl> diff --git a/arch/arm/mach-cns3xxx/cns3xxx.h b/arch/arm/mach-cns3xxx/cns3xxx.h index a0f5b60..a642ba5 100644 --- a/arch/arm/mach-cns3xxx/cns3xxx.h +++ b/arch/arm/mach-cns3xxx/cns3xxx.h @@ -162,13 +162,11 @@ #define CNS3XXX_L2

[PATCH] CNS3xxx: remove unused *_VIRT definitions

Signed-off-by: Krzysztof Hałasa diff --git a/arch/arm/mach-cns3xxx/cns3xxx.h b/arch/arm/mach-cns3xxx/cns3xxx.h index a0f5b60..a642ba5 100644 --- a/arch/arm/mach-cns3xxx/cns3xxx.h +++ b/arch/arm/mach-cns3xxx/cns3xxx.h @@ -162,13 +162,11 @@ #define CNS3XXX_L2C_BASE

[PATCH] CNS3xxx: remove unused *_VIRT definitions

diff --git a/arch/arm/mach-cns3xxx/cns3xxx.h b/arch/arm/mach-cns3xxx/cns3xxx.h index a0f5b60..a642ba5 100644 --- a/arch/arm/mach-cns3xxx/cns3xxx.h +++ b/arch/arm/mach-cns3xxx/cns3xxx.h @@ -162,13 +162,11 @@ #define CNS3XXX_L2C_BASE 0x9200 /* L2 Cache Control */

[PATCH] CNS3xxx: remove unused *_VIRT definitions

diff --git a/arch/arm/mach-cns3xxx/cns3xxx.h b/arch/arm/mach-cns3xxx/cns3xxx.h index a0f5b60..a642ba5 100644 --- a/arch/arm/mach-cns3xxx/cns3xxx.h +++ b/arch/arm/mach-cns3xxx/cns3xxx.h @@ -162,13 +162,11 @@ #define CNS3XXX_L2C_BASE 0x9200 /* L2 Cache Control */

[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 <khal...@piap.pl> 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

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

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

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

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

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,

  1   2   3   >