[PATCH 1/2] dt-bindings: reset: document Broadcom's BCM4908 USB reset binding

From: Rafał Miłecki Document binding of block responsible for initializing USB controllers (OHCI, EHCI, XHCI). Signed-off-by: Rafał Miłecki --- .../reset/brcm,bcm4908-usb-reset.yaml | 60 +++ 1 file changed, 60 insertions(+) create mode 100644 Documentation

[PATCH 2/2] reset: bcm4908-usb: add driver for BCM4908 USB reset controller

From: Rafał Miłecki This controller is responsible for OHCI, EHCI, XHCI and PHYs setup that has to be handled in the proper order. One unusual thing about this controller is that is provides access to the MDIO bus. There are two registers (in the middle of block space) responsible

[PATCH 1/2] dt-bindings: phy: Add binding for BCM4908 USB PHYs

From: Rafał Miłecki BCM4908 SoCs have USB 2.0 PHY and USB 3.0 PHY attached to the MDIO bus. Those bindings allow describing them. Signed-off-by: Rafał Miłecki --- .../bindings/phy/bcm4908-usb-phy.yaml | 52 +++ 1 file changed, 52 insertions(+) create mode 100644

[PATCH 2/2] phy: phy-bcm4908-usb: Add drivers for USB PHYs

From: Rafał Miłecki This driver initializes BCM4908 USB PHYs so USB can be utilized. Signed-off-by: Rafał Miłecki --- drivers/phy/broadcom/Kconfig | 9 ++ drivers/phy/broadcom/Makefile | 1 + drivers/phy/broadcom/phy-bcm4908-usb.c | 204 + 3

Re: [PATCH] dt-bindings: phy: bcm-ns-usb3-phy: convert to yaml

On 30.11.2020 16:58, Rafał Miłecki wrote: On 30.11.2020 16:43, Vinod Koul wrote: On 16-11-20, 08:46, Rafał Miłecki wrote: From: Rafał Miłecki 1. Change syntax from txt to yaml 2. Drop "Driver for" from the title 3. Drop "reg = <0x0>;" from example (noticed by dt

Re: [PATCH] dt-bindings: phy: bcm-ns-usb3-phy: convert to yaml

On 30.11.2020 16:43, Vinod Koul wrote: On 16-11-20, 08:46, Rafał Miłecki wrote: From: Rafał Miłecki 1. Change syntax from txt to yaml 2. Drop "Driver for" from the title 3. Drop "reg = <0x0>;" from example (noticed by dt_binding_check) 4. Specify license Signed-of

[PATCH 2/2] reset: simple: add BCM4908 MISC PCIe reset controller support

From: Rafał Miłecki It's a trivial reset controller. One register with bit per PCIe core. Signed-off-by: Rafał Miłecki --- drivers/reset/Kconfig| 2 +- drivers/reset/reset-simple.c | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/reset/Kconfig b/drivers

[PATCH 1/2] dt-bindings: reset: document Broadcom's BCM4908 PCIe reset binding

From: Rafał Miłecki BCM4908 was built using older PCIe hardware block that requires using external reset block controlling PERST# signals. Signed-off-by: Rafał Miłecki --- .../reset/brcm,bcm4908-misc-pcie-reset.yaml | 39 +++ 1 file changed, 39 insertions(+) create mode

Re: [PATCH] phy: phy-bcm-ns-usb3: drop support for deprecated DT binding

On Thu, 19 Nov 2020 at 07:27, Vinod Koul wrote: > > On 13-11-20, 12:34, Rafał Miłecki wrote: > > From: Rafał Miłecki > > > > Initially this PHY driver was implementing MDIO access on its own. It > > was caused by lack of proper hardware design understanding. &g

Re: [PATCH] phy: phy-bcm-ns-usb3: drop support for deprecated DT binding

On Thu, 19 Nov 2020 at 07:27, Vinod Koul wrote: > On 13-11-20, 12:34, Rafał Miłecki wrote: > > From: Rafał Miłecki > > > > Initially this PHY driver was implementing MDIO access on its own. It > > was caused by lack of proper hardware design understanding. >

[PATCH] dt-bindings: phy: bcm-ns-usb2-phy: convert to yaml

From: Rafał Miłecki 1. Convert from txt to yaml 2. Drop "Driver for" from the title 3. Document "#phy-cells" 4. Fix example node name (noticed by dt_binding_check) 5. Add #include to example (noticed by dt_binding_check) 6. Specify license Signed-off-by: Rafał Miłecki ---

[PATCH] dt-bindings: phy: bcm-ns-usb3-phy: convert to yaml

From: Rafał Miłecki 1. Change syntax from txt to yaml 2. Drop "Driver for" from the title 3. Drop "reg = <0x0>;" from example (noticed by dt_binding_check) 4. Specify license Signed-off-by: Rafał Miłecki --- I think this should go through linux-phy tree. Kishon, Vino

[PATCH] phy: phy-bcm-ns-usb3: drop support for deprecated DT binding

From: Rafał Miłecki Initially this PHY driver was implementing MDIO access on its own. It was caused by lack of proper hardware design understanding. It has been changed back in 2017. DT bindings were changed and driver was updated to use MDIO layer. It should be really safe now to drop

Re: [PATCH v2 05/10] ARM: dts: BCM5301X: Provide defaults ports container node

be fixed: 'ports' is a required property 'ethernet-ports' is a required property From schema: Documentation/devicetree/bindings/net/dsa/b53.yaml Signed-off-by: Florian Fainelli Nice! Acked-by: Rafał Miłecki

Re: [PATCH v2 04/10] ARM: dts: BCM5301X: Add a default compatible for switch node

On 12.11.2020 05:50, Florian Fainelli wrote: Provide a default compatible string which is based on the 53011 SRAB compatible by default. The 4709 and 47094 default to the 53012 SRAB compatible. (...) Signed-off-by: Florian Fainelli Looks good, thanks! Acked-by: Rafał Miłecki

Re: [PATCH 04/10] ARM: dts: BCM5301X: Add a default compatible for switch node

On 10.11.2020 04:31, Florian Fainelli wrote: Provide a default compatible string which is based on the 53010 SRAB compatible, this allows us to have sane defaults and silences the following warnings: arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dt.yaml: ethernet-switch@18007000: compatible: 'oneOf'

Re: [PATCH 05/10] ARM: dts: BCM5301X: Provide defaults ports container node

On 11.11.2020 02:48, Florian Fainelli wrote: On 11/10/2020 2:13 PM, Florian Fainelli wrote: On 11/10/20 2:12 PM, Vladimir Oltean wrote: On Mon, Nov 09, 2020 at 07:31:08PM -0800, Florian Fainelli wrote: Provide an empty 'ports' container node with the correct #address-cells and #size-cells

Re: [PATCH 05/10] ARM: dts: BCM5301X: Provide defaults ports container node

10.11.2020 04:31, Florian Fainelli wrote: Provide an empty 'ports' container node with the correct #address-cells and #size-cells properties. This silences the following warning: arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dt.yaml: ethernet-switch@18007000: 'oneOf' conditional failed, one must be

Re: [PATCH v2] ARM: dts: BCM5301X: Linksys EA9500 add fixed partitions

On 01.11.2020 21:08, Vivek Unune wrote: This router has dual paritions to store trx firmware image and dual partitions for nvram. The second one in each of these cases acts as a backup store. I'm quite sure CFE is supposed to flash new firmware to the backup partition and then mark it as main

Re: [PATCH v2 1/2] ARM: dts: BCM5301X: pinctrl - use correct driver and define mdio pins

r of chipset specific binding and not a driver. Change looks OK, thanks for handling that! Acked-by: Rafał Miłecki

Re: [PATCH] MIPS: BCM47XX: Remove the needless check with the 1074K

U support explicitly.") > Signed-off-by: Wei Li Acked-by: Rafał Miłecki

Re: [PATCH] ARM: dts: BCM5301X: Fix pin controller node

On 19.08.2020 06:23, Florian Fainelli wrote: The pin controller resources start at 0xc0 from the CRU base which is at 0x100 from th DMU base, for a final address of 0x1800_c1c0, whereas we are currently off by 0x100. The resource size of the CRU is also incorrect and should end at 0x248 bytes

Re: [PATCH] ARM: dts: BCM5301X: Fix pin controller node

On Wed, 19 Aug 2020 at 06:23, Florian Fainelli wrote: > The pin controller resources start at 0xc0 from the CRU base which is at > 0x100 from th DMU base, for a final address of 0x1800_c1c0, whereas we > are currently off by 0x100. The resource size of the CRU is also > incorrect and should end

Re: [PATCH 26/30] net: wireless: broadcom: b43: phy_common: Demote non-conformant kerneldoc header

On Fri, 14 Aug 2020 at 13:41, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/net/wireless/broadcom/b43/phy_common.c:467: warning: Function > parameter or member 'work' not described in 'b43_phy_txpower_adjust_work' Why you can't document @work instead? Should

Re: [PATCH] SONICS SILICON BACKPLANE DRIVER (SSB): Replace HTTP links with HTTPS ones

On Thu, 9 Jul 2020 at 08:30, Alexander A. Klimov wrote: > Rationale: > Reduces attack surface on kernel devs opening the links for MITM > as HTTPS traffic is much harder to manipulate. > > Deterministic algorithm: > For each file: > If not .svg: > For each line: > If doesn't contain

Re: [PATCH RFC] cfg80211: add new command for reporting wiphy crashes

On 26.09.2019 13:55, Johannes Berg wrote: On Thu, 2019-09-26 at 13:52 +0200, Rafał Miłecki wrote: Indeed my main concert is AP mode. I'm afraid that cfg80211 doesn't cache all settings, consider e.g. nl80211_start_ap(). It builds struct cfg80211_ap_settings using info from nl80211 message

Re: [PATCH RFC] cfg80211: add new command for reporting wiphy crashes

On 20.09.2019 16:01, Jouni Malinen wrote: On Fri, Sep 20, 2019 at 03:37:08PM +0200, Rafał Miłecki wrote: Hardware or firmware instability may result in unusable wiphy. In such cases usually a hardware reset is needed. To allow a full recovery kernel has to indicate problem to the user space

Re: [PATCH RFC] cfg80211: add new command for reporting wiphy crashes

Resending from my subscribed e-mail On 20.09.2019 16:01, Jouni Malinen wrote: > On Fri, Sep 20, 2019 at 03:37:08PM +0200, Rafał Miłecki wrote: >> Hardware or firmware instability may result in unusable wiphy. In such >> cases usually a hardware reset is needed. To allow a full rec

[PATCH RFC] cfg80211: add new command for reporting wiphy crashes

From: Rafał Miłecki Hardware or firmware instability may result in unusable wiphy. In such cases usually a hardware reset is needed. To allow a full recovery kernel has to indicate problem to the user space. This new nl80211 command lets user space known wiphy has crashed and has been just

Re: [PATCH] bcma: fix incorrect update of BCMA_CORE_PCI_MDIO_DATA

On Thu, 22 Aug 2019 at 18:11, Colin Ian King wrote: > On 22/08/2019 17:03, Larry Finger wrote: > > On 8/22/19 8:35 AM, Colin King wrote: > >> From: Colin Ian King > >> > >> An earlier commit re-worked the setting of the bitmask and is now > >> assigning v with some bit flags rather than bitwise

ARM router NAT performance affected by random/unrelated commits

Hi, I work on home routers based on Broadcom's Northstar SoCs. Those devices have ARM Cortex-A9 and most of them are dual-core. As for home routers, my main concern is network performance. That CPU isn't powerful enough to handle gigabit traffic so all kind of optimizations do matter. I noticed

Re: [PATCH v2] brcmfmac: fix typos in code comments

On 2019-05-20 14:28, Weitao Hou wrote: fix lengh to length Signed-off-by: Weitao Hou --- - fix prefix Nice, thanks!

Re: [PATCH] wireless: fix typos in code comments

On 2019-05-19 05:22, Weitao Hou wrote: fix lengh to length Signed-off-by: Weitao Hou --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Please use: git log --oneline drivers/net/wireless/broadcom/brcm80211/brcmfmac/ to see how

Re: [PATCH] ARM: dts: BCM5301X: Change Ethernet switch management port

On 13.02.2019 05:25, Florian Fainelli wrote: BCM5301X has 3 Ethernet controllers: GMAC0, 1, 2 which map to ports 5, 7 and 8 respectively of the internal switch. Future changes will turn on management mode in the Ethernet switch driver (b53) which will require us to use port 8. Signed-off-by:

[PATCH V2 2/2] phy: bcm-ns-usb2: support updated DT binding with the CRU syscon

From: Rafał Miłecki This adds support for the "syscon-cru" DT property which simply requires using regmap to access CRU registers. The old binding has been deprecated and stays as a fallback method. Signed-off-by: Rafał Miłecki --- V2: Add bcm_ns_usb2_(read|wr

[PATCH V2 1/2] dt-bindings: bcm-ns-usb2-phy: rework binding to use CRU syscon

From: Rafał Miłecki USB 2.0 PHY is a hardware block that happens to use two registers from the CRU block to setup a single PLL. It's not part of the CRU or DMU and so its binding shouldn't cover the whole DMU. The correct way of handling this is to reference CRU block node using a syscon

[PATCH 1/2] dt-bindings: bcm-ns-usb2-phy: rework binding to use CRU syscon

From: Rafał Miłecki USB 2.0 PHY is a hardware block that happens to use two registers from the CRU block to setup a single PLL. It's not part of the CRU or DMU and so its binding shouldn't cover the whole DMU. The correct way of handling this is to reference CRU block node using a syscon

[PATCH 2/2] phy: bcm-ns-usb2: support updated DT binding with the CRU syscon

From: Rafał Miłecki This adds support for the "syscon-cru" DT property which simply requires using regmap to access CRU registers. The old binding has been deprecated and stays as a fallback method. Signed-off-by: Rafał Miłecki --- drivers/phy/broadcom/phy-bcm-ns-u

Re: [PATCH mips-fixes] MIPS: BCM47XX: Setup struct device for the SoC

On 2019-01-02 16:50, Hauke Mehrtens wrote: On 1/2/19 1:51 PM, Rafał Miłecki wrote: From: Rafał Miłecki So far we never had any device registered for the SoC. This resulted in some small issues that we kept ignoring like: 1) Not working GPIOLIB_IRQCHIP (gpiochip_irqchip_add_key() failing) 2

[PATCH V2 mips-fixes] MIPS: BCM47XX: Setup struct device for the SoC

From: Rafał Miłecki So far we never had any device registered for the SoC. This resulted in some small issues that we kept ignoring like: 1) Not working GPIOLIB_IRQCHIP (gpiochip_irqchip_add_key() failing) 2) Lack of proper tree in the /sys/devices/ 3) mips_dma_alloc_coherent() silently handling

[PATCH mips-fixes] MIPS: BCM47XX: Setup struct device for the SoC

From: Rafał Miłecki So far we never had any device registered for the SoC. This resulted in some small issues that we kept ignoring like: 1) Not working GPIOLIB_IRQCHIP (gpiochip_irqchip_add_key() failing) 2) Lack of proper tree in the /sys/devices/ 3) mips_dma_alloc_coherent() silently handling

Re: Problem with late AMD microcode reload/feedback

On Sun, 16 Dec 2018 at 11:44, Borislav Petkov wrote: > On Sun, Dec 16, 2018 at 11:26:29AM +0100, Rafał Miłecki wrote: > > Debugging CPU errors. > > I told you that this issue is being worked on and there will be a fix > of sorts at some point. Don't try any funky busin

Re: Problem with late AMD microcode reload/feedback

On Sun, 16 Dec 2018 at 11:06, Borislav Petkov wrote: > > For my hack tests I'd like to replace my 0x0810100b with a 0x08101007. > > Why would you even want to downgrade the microcode?! Debugging CPU errors. I have two notebooks: 1) HP EliteBook 745 G5 with Ryzen 5 PRO 2500U It runs 1.03.01 BIOS

Re: Problem with late AMD microcode reload/feedback

On 16.12.2018 01:05, Borislav Petkov wrote: On Sun, Dec 16, 2018 at 12:46:05AM +0100, Rafał Miłecki wrote: [19.736770] microcode: [find_equiv_id] sig:8458000 That's your CPU's family/model/stepping: 0x0810f10 [19.736772] microcode: [find_equiv_id] equiv_table->installed_cpu:8392

Problem with late AMD microcode reload/feedback

Hi, I'm trying to reload AMD Ryzen Mobile (fam17h) microcode doing: echo 1 > /sys/devices/system/cpu/microcode/reload The problem is I don't get any feedback. No error for the "echo" command, no a single new line in the "dmesg". I have no idea if microcode has been reloaded or not. I did a

Re: [PATCH] leds: gpio: Drop unneeded manual of_node assignment

tering function"). Basically the code was overwriting the of_node with same value. No functional change expected. Signed-off-by: Krzysztof Kozlowski Thanks! Tested-by: Rafał Miłecki

Re: [PATCH] leds: gpio: Drop unneeded manual of_node assignment

tering function"). Basically the code was overwriting the of_node with same value. No functional change expected. Signed-off-by: Krzysztof Kozlowski Thanks! Tested-by: Rafał Miłecki

Re: [PATCH v3] mtd: spi-nor: cast to u64 to avoid uint overflows

On Wed, 28 Nov 2018 at 09:03, Huijin Park wrote: > From: "huijin.park" > > The "params->size" is defined as "u64". > And "info->sector_size" and "info->n_sectors" are defined as > unsigned int and u16. > Thus, u64 data might have strange data(loss data) if the result > overflows an unsigned int.

Re: [PATCH v3] mtd: spi-nor: cast to u64 to avoid uint overflows

On Wed, 28 Nov 2018 at 09:03, Huijin Park wrote: > From: "huijin.park" > > The "params->size" is defined as "u64". > And "info->sector_size" and "info->n_sectors" are defined as > unsigned int and u16. > Thus, u64 data might have strange data(loss data) if the result > overflows an unsigned int.

Re: [PATCH v2] ubifs: Handle re-linking of inodes correctly while recovery

list for a re-link entry > before dropping data. > > Fixes: 474b93704f32 ("ubifs: Implement O_TMPFILE") > Cc: sta...@vger.kernel.org > Cc: Russell Senior > Cc: Rafał Miłecki > Reported-by: Russell Senior > Reported-by: Rafał Miłecki > Signed-off-by: Richard Weinberger Thank you!!! Tested-by: Rafał Miłecki

Re: [PATCH v2] ubifs: Handle re-linking of inodes correctly while recovery

list for a re-link entry > before dropping data. > > Fixes: 474b93704f32 ("ubifs: Implement O_TMPFILE") > Cc: sta...@vger.kernel.org > Cc: Russell Senior > Cc: Rafał Miłecki > Reported-by: Russell Senior > Reported-by: Rafał Miłecki > Signed-off-by: Richard Weinberger Thank you!!! Tested-by: Rafał Miłecki

Re: [PATCH 3.16 151/366] MIPS: BCM47XX: Enable 74K Core ExternalSync for PCIe erratum

On Sun, 11 Nov 2018 at 21:05, Ben Hutchings wrote: > 3.16.61-rc1 review patch. If anyone has any objections, please let me know. Nack. This patch has caused a regression and had to be reverted. Please check upstream repository for a revert (search git log for 2a027b47dba6).

Re: [PATCH 3.16 151/366] MIPS: BCM47XX: Enable 74K Core ExternalSync for PCIe erratum

On Sun, 11 Nov 2018 at 21:05, Ben Hutchings wrote: > 3.16.61-rc1 review patch. If anyone has any objections, please let me know. Nack. This patch has caused a regression and had to be reverted. Please check upstream repository for a revert (search git log for 2a027b47dba6).

Re: [PATCH] ubifs: Handle re-linking of inodes correctly while recovery

list for a re-link entry > before dropping data. > > Fixes: 474b93704f32 ("ubifs: Implement O_TMPFILE") > Cc: sta...@vger.kernel.org > Reported-by: Russell Senior > Reported-by: Rafał Miłecki > Signed-off-by: Richard Weinberger Thank you Richard!!! Tested-by: Rafał Miłecki

Re: [PATCH] ubifs: Handle re-linking of inodes correctly while recovery

list for a re-link entry > before dropping data. > > Fixes: 474b93704f32 ("ubifs: Implement O_TMPFILE") > Cc: sta...@vger.kernel.org > Reported-by: Russell Senior > Reported-by: Rafał Miłecki > Signed-off-by: Richard Weinberger Thank you Richard!!! Tested-by: Rafał Miłecki

Re: [PATCH] ARM: add serial.h and set BASE_BAUD to 0

On 2018-09-21 15:59, Russell King - ARM Linux wrote: On Thu, Sep 20, 2018 at 10:13:57PM +0200, Rafał Miłecki wrote: From: Rafał Miłecki For years arm has been using serial.h from asm-generic which sets BASE_BAUD value to the (1843200 / 16). This is incorrect as: 1) This value obviously isn't

Re: [PATCH] ARM: add serial.h and set BASE_BAUD to 0

On 2018-09-21 15:59, Russell King - ARM Linux wrote: On Thu, Sep 20, 2018 at 10:13:57PM +0200, Rafał Miłecki wrote: From: Rafał Miłecki For years arm has been using serial.h from asm-generic which sets BASE_BAUD value to the (1843200 / 16). This is incorrect as: 1) This value obviously isn't

[PATCH] ARM: add serial.h and set BASE_BAUD to 0

From: Rafał Miłecki For years arm has been using serial.h from asm-generic which sets BASE_BAUD value to the (1843200 / 16). This is incorrect as: 1) This value obviously isn't correct for all devices 2) There are no device specific serial.h with CONFIG_ARCH_MULTIPLATFORM That value breaks

[PATCH] ARM: add serial.h and set BASE_BAUD to 0

From: Rafał Miłecki For years arm has been using serial.h from asm-generic which sets BASE_BAUD value to the (1843200 / 16). This is incorrect as: 1) This value obviously isn't correct for all devices 2) There are no device specific serial.h with CONFIG_ARCH_MULTIPLATFORM That value breaks

Re: [PATCH v3 2/3] dt-bindings: add bindings for mtd-concat devices

On Sat, 8 Sep 2018 at 15:14, Bernhard Frauendienst wrote: > > Document virtual mtd-concat device bindings. > > Signed-off-by: Bernhard Frauendienst > --- > .../devicetree/bindings/mtd/mtd-concat.txt| 36 +++ > 1 file changed, 36 insertions(+) > create mode 100644

Re: [PATCH v3 2/3] dt-bindings: add bindings for mtd-concat devices

On Sat, 8 Sep 2018 at 15:14, Bernhard Frauendienst wrote: > > Document virtual mtd-concat device bindings. > > Signed-off-by: Bernhard Frauendienst > --- > .../devicetree/bindings/mtd/mtd-concat.txt| 36 +++ > 1 file changed, 36 insertions(+) > create mode 100644

Re: Lockdep complaint in jffs2

On 22 May 2018 at 09:12, David Woodhouse wrote: > On Tue, 2018-05-22 at 13:17 +1000, Benjamin Herrenschmidt wrote: >> Hi David ! >> >> I noticed this on my BMC when building OpenBMC with Lockdep... >> something worth investigating/digging ? > > Hm, I have a feeling a saw a

Re: Lockdep complaint in jffs2

On 22 May 2018 at 09:12, David Woodhouse wrote: > On Tue, 2018-05-22 at 13:17 +1000, Benjamin Herrenschmidt wrote: >> Hi David ! >> >> I noticed this on my BMC when building OpenBMC with Lockdep... >> something worth investigating/digging ? > > Hm, I have a feeling a saw a patch to fix this

Re: [PATCH V2 1/2] Revert "ssb: Prevent build of PCI host features in module"

On 2018-05-12 10:01, Michael Büsch wrote: On Sat, 12 May 2018 10:50:42 +0300 Kalle Valo <kv...@codeaurora.org> wrote: Larry Finger <larry.fin...@lwfinger.net> writes: > On 05/11/2018 05:13 AM, Kalle Valo wrote: >> Rafał Miłecki <zaj...@gmail.com> writes: >> &

Re: [PATCH V2 1/2] Revert "ssb: Prevent build of PCI host features in module"

On 2018-05-12 10:01, Michael Büsch wrote: On Sat, 12 May 2018 10:50:42 +0300 Kalle Valo wrote: Larry Finger writes: > On 05/11/2018 05:13 AM, Kalle Valo wrote: >> Rafał Miłecki writes: >> >>> On 11 May 2018 at 11:17, Rafał Miłecki wrote: [...] >>> &g

Re: [PATCH V2 1/2] Revert "ssb: Prevent build of PCI host features in module"

On 11 May 2018 at 12:13, Kalle Valo <kv...@codeaurora.org> wrote: > Rafał Miłecki <zaj...@gmail.com> writes: > >> On 11 May 2018 at 11:17, Rafał Miłecki <zaj...@gmail.com> wrote: >>> From: Rafał Miłecki <ra...@milecki.pl> >>> >>&g

Re: [PATCH V2 1/2] Revert "ssb: Prevent build of PCI host features in module"

On 11 May 2018 at 12:13, Kalle Valo wrote: > Rafał Miłecki writes: > >> On 11 May 2018 at 11:17, Rafał Miłecki wrote: >>> From: Rafał Miłecki >>> >>> This reverts commit 882164a4a928bcaa53280940436ca476e6b1db8e. >>> >>> Ab

Re: [PATCH V2 1/2] Revert "ssb: Prevent build of PCI host features in module"

On 11 May 2018 at 11:17, Rafał Miłecki <zaj...@gmail.com> wrote: > From: Rafał Miłecki <ra...@milecki.pl> > > This reverts commit 882164a4a928bcaa53280940436ca476e6b1db8e. > > Above commit added "SSB = y" dependency to the wrong symbol > SSB_DRIVER_PCICORE_P

Re: [PATCH V2 1/2] Revert "ssb: Prevent build of PCI host features in module"

On 11 May 2018 at 11:17, Rafał Miłecki wrote: > From: Rafał Miłecki > > This reverts commit 882164a4a928bcaa53280940436ca476e6b1db8e. > > Above commit added "SSB = y" dependency to the wrong symbol > SSB_DRIVER_PCICORE_POSSIBLE and prevented SSB_DRIVER_PCICORE from

[PATCH V2 1/2] Revert "ssb: Prevent build of PCI host features in module"

From: Rafał Miłecki <ra...@milecki.pl> This reverts commit 882164a4a928bcaa53280940436ca476e6b1db8e. Above commit added "SSB = y" dependency to the wrong symbol SSB_DRIVER_PCICORE_POSSIBLE and prevented SSB_DRIVER_PCICORE from being selected when needed. PCI core driver

[PATCH V2 1/2] Revert "ssb: Prevent build of PCI host features in module"

From: Rafał Miłecki This reverts commit 882164a4a928bcaa53280940436ca476e6b1db8e. Above commit added "SSB = y" dependency to the wrong symbol SSB_DRIVER_PCICORE_POSSIBLE and prevented SSB_DRIVER_PCICORE from being selected when needed. PCI core driver for core running in clien

[PATCH V2 2/2] ssb: make SSB_PCICORE_HOSTMODE depend on SSB = y

From: Rafał Miłecki <ra...@milecki.pl> SSB_PCICORE_HOSTMODE protects MIPS specific code that calls not exported symbols pcibios_enable_device and register_pci_controller. This code is supposed to be compiled only with ssb builtin. This fixes: ERROR: "pcibios_enable_device" [dr

[PATCH V2 2/2] ssb: make SSB_PCICORE_HOSTMODE depend on SSB = y

From: Rafał Miłecki SSB_PCICORE_HOSTMODE protects MIPS specific code that calls not exported symbols pcibios_enable_device and register_pci_controller. This code is supposed to be compiled only with ssb builtin. This fixes: ERROR: "pcibios_enable_device" [drivers/ssb/ssb.ko] undefi

Re: [PATCH 4.17 2/2] ssb: make SSB_PCICORE_HOSTMODE depend on SSB = y

On 10 May 2018 at 13:26, Michael Büsch <m...@bues.ch> wrote: > On Thu, 10 May 2018 13:20:01 +0200 > Rafał Miłecki <zaj...@gmail.com> wrote: > >> On 10 May 2018 at 13:17, Michael Büsch <m...@bues.ch> wrote: >> > On Thu, 10 May 2018 13:14:01 +0200 &

Re: [PATCH 4.17 2/2] ssb: make SSB_PCICORE_HOSTMODE depend on SSB = y

On 10 May 2018 at 13:26, Michael Büsch wrote: > On Thu, 10 May 2018 13:20:01 +0200 > Rafał Miłecki wrote: > >> On 10 May 2018 at 13:17, Michael Büsch wrote: >> > On Thu, 10 May 2018 13:14:01 +0200 >> > Rafał Miłecki wrote: >> > >> >>

Re: [PATCH 4.17 2/2] ssb: make SSB_PCICORE_HOSTMODE depend on SSB = y

On 10 May 2018 at 13:17, Michael Büsch <m...@bues.ch> wrote: > On Thu, 10 May 2018 13:14:01 +0200 > Rafał Miłecki <zaj...@gmail.com> wrote: > >> From: Rafał Miłecki <ra...@milecki.pl> >> >> SSB_PCICORE_HOSTMODE protects MIPS specific code that calls

Re: [PATCH 4.17 2/2] ssb: make SSB_PCICORE_HOSTMODE depend on SSB = y

On 10 May 2018 at 13:17, Michael Büsch wrote: > On Thu, 10 May 2018 13:14:01 +0200 > Rafał Miłecki wrote: > >> From: Rafał Miłecki >> >> SSB_PCICORE_HOSTMODE protects MIPS specific code that calls not exported >> symbols pcibios_enable_device and r

[PATCH 4.17 2/2] ssb: make SSB_PCICORE_HOSTMODE depend on SSB = y

From: Rafał Miłecki <ra...@milecki.pl> SSB_PCICORE_HOSTMODE protects MIPS specific code that calls not exported symbols pcibios_enable_device and register_pci_controller. This code is supposed to be compiled only with ssb builtin. This fixes: ERROR: "pcibios_enable_device" [dr

[PATCH 4.17 2/2] ssb: make SSB_PCICORE_HOSTMODE depend on SSB = y

From: Rafał Miłecki SSB_PCICORE_HOSTMODE protects MIPS specific code that calls not exported symbols pcibios_enable_device and register_pci_controller. This code is supposed to be compiled only with ssb builtin. This fixes: ERROR: "pcibios_enable_device" [drivers/ssb/ssb.ko] undefi

[PATCH 4.17 1/2] Revert "ssb: Prevent build of PCI host features in module"

From: Rafał Miłecki <ra...@milecki.pl> This reverts commit 882164a4a928bcaa53280940436ca476e6b1db8e. Above commit added "SSB = y" dependency to the wrong symbol SSB_DRIVER_PCICORE_POSSIBLE and prevented SSB_DRIVER_PCICORE from being selected when needed. PCI core driver

[PATCH 4.17 1/2] Revert "ssb: Prevent build of PCI host features in module"

From: Rafał Miłecki This reverts commit 882164a4a928bcaa53280940436ca476e6b1db8e. Above commit added "SSB = y" dependency to the wrong symbol SSB_DRIVER_PCICORE_POSSIBLE and prevented SSB_DRIVER_PCICORE from being selected when needed. PCI core driver for core running in clien

Re: Regression caused by commit 882164a4a928

On 10 May 2018 at 12:41, Rafał Miłecki <zaj...@gmail.com> wrote: > On 7 May 2018 at 17:44, Larry Finger <larry.fin...@lwfinger.net> wrote: >> Although commit 882164a4a928 ("ssb: Prevent build of PCI host features in >> module") appeared to be harmless, it

Re: Regression caused by commit 882164a4a928

On 10 May 2018 at 12:41, Rafał Miłecki wrote: > On 7 May 2018 at 17:44, Larry Finger wrote: >> Although commit 882164a4a928 ("ssb: Prevent build of PCI host features in >> module") appeared to be harmless, it leads to complete failure of drivers >> b43. and b4

Re: Regression caused by commit 882164a4a928

On 7 May 2018 at 17:44, Larry Finger wrote: > Although commit 882164a4a928 ("ssb: Prevent build of PCI host features in > module") appeared to be harmless, it leads to complete failure of drivers > b43. and b43legacy, and likely affects b44 as well. The problem is that

Re: Regression caused by commit 882164a4a928

On 7 May 2018 at 17:44, Larry Finger wrote: > Although commit 882164a4a928 ("ssb: Prevent build of PCI host features in > module") appeared to be harmless, it leads to complete failure of drivers > b43. and b43legacy, and likely affects b44 as well. The problem is that > CONFIG_SSB_PCIHOST is

[PATCH] ARM: dts: BCM5301X: Relicense most DTS files to the GPL 2.0+ / MIT

From: Rafał Miłecki <ra...@milecki.pl> These files were created and ever touched by a group of three people only: Dan, Hauke and me. They were licensed under GNU/GPL or ISC. Introducing and discussing SPDX-License-Identifier resulted in a conclusion that ISC is a not recommended licens

[PATCH] ARM: dts: BCM5301X: Relicense most DTS files to the GPL 2.0+ / MIT

From: Rafał Miłecki These files were created and ever touched by a group of three people only: Dan, Hauke and me. They were licensed under GNU/GPL or ISC. Introducing and discussing SPDX-License-Identifier resulted in a conclusion that ISC is a not recommended license (see also a license

Re: LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

On 29 April 2018 at 07:26, Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > On Sat, Apr 28, 2018 at 11:25:17PM +0200, Rafał Miłecki wrote: >> Due to some maintainers *preferring* BSD-compatible license for DTS >> files [0], I was writing mine using ISC. I had n

Re: LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

On 29 April 2018 at 07:26, Greg Kroah-Hartman wrote: > On Sat, Apr 28, 2018 at 11:25:17PM +0200, Rafał Miłecki wrote: >> Due to some maintainers *preferring* BSD-compatible license for DTS >> files [0], I was writing mine using ISC. I had no very special reason >> for it: I

LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

Hi, Due to some maintainers *preferring* BSD-compatible license for DTS files [0], I was writing mine using ISC. I had no very special reason for it: I was choosing between BSD-2-Clause, MIT and ISC. I've chosen ISC as I read about its "removal of language deemed unnecessary". I took a moment to

LICENSES: Missing ISC text & possibly a category ("Not recommended" vs. "Preferred licenses")

Hi, Due to some maintainers *preferring* BSD-compatible license for DTS files [0], I was writing mine using ISC. I had no very special reason for it: I was choosing between BSD-2-Clause, MIT and ISC. I've chosen ISC as I read about its "removal of language deemed unnecessary". I took a moment to

Re: [PATCH] ARM: BCM5301X: Fix NAND ECC parameters for Linksys Panamera

On 28 April 2018 at 06:19, Vivek Unune <npcomplet...@gmail.com> wrote: > On Fri, Apr 27, 2018 at 10:05 AM, Vivek Unune <npcomplet...@gmail.com> wrote: >> On Wed, Apr 25, 2018 at 11:02:04AM +0200, Rafał Miłecki wrote: >>> >>> The easiest solution: ignore

Re: [PATCH] ARM: BCM5301X: Fix NAND ECC parameters for Linksys Panamera

On 28 April 2018 at 06:19, Vivek Unune wrote: > On Fri, Apr 27, 2018 at 10:05 AM, Vivek Unune wrote: >> On Wed, Apr 25, 2018 at 11:02:04AM +0200, Rafał Miłecki wrote: >>> >>> The easiest solution: ignore all these "error -74 (ECC error) while >>> readi

Re: [PATCH] ARM: BCM5301X: Fix NAND ECC parameters for Linksys Panamera

On 13.03.2018 02:02, Vivek Unune wrote: On Mon, Mar 12, 2018 at 03:52:27PM -0700, Florian Fainelli wrote: On 03/11/2018 03:03 AM, Vivek Unune wrote: Hi Rafał, On Sat, Mar 10, 2018 at 10:41:04PM +0100, Rafał Miłecki wrote: On 10 March 2018 at 18:12, Vivek Unune <npcomplet...@gmail.com>

Re: [PATCH] ARM: BCM5301X: Fix NAND ECC parameters for Linksys Panamera

On 13.03.2018 02:02, Vivek Unune wrote: On Mon, Mar 12, 2018 at 03:52:27PM -0700, Florian Fainelli wrote: On 03/11/2018 03:03 AM, Vivek Unune wrote: Hi Rafał, On Sat, Mar 10, 2018 at 10:41:04PM +0100, Rafał Miłecki wrote: On 10 March 2018 at 18:12, Vivek Unune wrote: Using BCH8 gives ecc

Re: [PATCH] ARM: BCM5301X: Fix NAND ECC parameters for Linksys Panamera

On 11 March 2018 at 11:03, Vivek Unune <npcomplet...@gmail.com> wrote: > Hi Rafał, > > On Sat, Mar 10, 2018 at 10:41:04PM +0100, Rafał Miłecki wrote: >> On 10 March 2018 at 18:12, Vivek Unune <npcomplet...@gmail.com> wrote: >> > Using BCH8 gives ecc

Re: [PATCH] ARM: BCM5301X: Fix NAND ECC parameters for Linksys Panamera

On 11 March 2018 at 11:03, Vivek Unune wrote: > Hi Rafał, > > On Sat, Mar 10, 2018 at 10:41:04PM +0100, Rafał Miłecki wrote: >> On 10 March 2018 at 18:12, Vivek Unune wrote: >> > Using BCH8 gives ecc errors and makes the router unsuable. >> > Switching to BCH1

[PATCH 1/2] MIPS: BCM47XX: Add support for Netgear WNR1000 V3

From: Rafał Miłecki <ra...@milecki.pl> This adds support for detecting this model board and registers some LEDs and buttons. There are two uncommon things regarding this device: 1) It can use two different "board_id" ID values. Unit I have uses "U12H139T00_NETGEAR"

[PATCH 1/2] MIPS: BCM47XX: Add support for Netgear WNR1000 V3

From: Rafał Miłecki This adds support for detecting this model board and registers some LEDs and buttons. There are two uncommon things regarding this device: 1) It can use two different "board_id" ID values. Unit I have uses "U12H139T00_NETGEAR" value. This magic is also

[PATCH 2/2] firmware: bcm47xx_nvram: support small (0x6000 B) NVRAM partitions

From: Rafał Miłecki <ra...@milecki.pl> Some old devices with 4 MiB flashes were using 0x1000 block size and could use smaller (0x6000 bytes) flash partition for storing NVRAM content. This adds support for reading NVRAM on Netgear WNR1000 V3. Signed-off-by: Rafał Miłecki <ra...@m

<    1   2   3   4   5   6   7   8   9   10   >