From: Rafał Miłecki
This helps finding the latest development code.
Signed-off-by: Rafał Miłecki
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d92f85ca831d..67317bfd46e3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6890,6 +6890,7
On 2021-04-09 05:37, Florian Fainelli wrote:
On 4/8/2021 8:08 AM, Arnd Bergmann wrote:
Greetings to all Arm platform maintainers,
I've just gone through the DT merges I've received so far and, with a
little help from Rob,
managed to run 'make dtbs_check W=1' before and after, to see what
the bad block table.
Fixes: f7e6b19bc764 ("mtd: properly check all write ioctls for permissions")
Signed-off-by: Michael Walle
Should be fine for OpenWrt tools to my best knowledge (and quick testing).
Acked-by: Rafał Miłecki
Signed-off-by: Geert Uytterhoeven
Acked-by: Rafał Miłecki
On 2021-03-16 14:38, Geert Uytterhoeven wrote:
Merely enabling CONFIG_COMPILE_TEST should not enable additional code.
To fix this, drop the automatic enabling of BCM4908_ENET.
Fixes: 4feffeadbcb2e5b1 ("net: broadcom: bcm4908enet: add BCM4908
controller driver")
Signed-off-by: Geert Uytterhoeven
On 2021-03-15 11:41, Vinod Koul wrote:
On 11-03-21, 21:31, Rafał Miłecki wrote:
Hi,
On 16.11.2020 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>;"
On 11.03.2021 11:50, Ansuel Smith wrote:
On Thu, Mar 11, 2021 at 10:32:21AM -0700, Rob Herring wrote:
On Thu, Mar 11, 2021 at 06:12:48AM +0100, Ansuel Smith wrote:
Document nvmem-cells compatible used to treat mtd partitions as a
nvmem provider.
Signed-off-by: Ansuel Smith
---
On 16.11.2020 08:46, Rafał Miłecki wrote:
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
Hi,
On 16.11.2020 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-off-by: Rafał Miłecki
---
I think th
On 10.03.2021 23:47, Ansuel Smith wrote:
On Wed, Mar 10, 2021 at 11:41:24PM +0100, Rafał Miłecki wrote:
See inline
On 10.03.2021 22:08, Ansuel Smith wrote:
Document nvmem-cells compatible used to treat mtd partitions as a
nvmem provider.
Signed-off-by: Ansuel Smith
---
.../bindings/mtd
See inline
On 10.03.2021 22:08, Ansuel Smith wrote:
Document nvmem-cells compatible used to treat mtd partitions as a
nvmem provider.
Signed-off-by: Ansuel Smith
---
.../bindings/mtd/partitions/nvmem-cells.yaml | 96 +++
1 file changed, 96 insertions(+)
create mode
On 06.03.2021 22:52, Rob Herring wrote:
On Fri, Feb 26, 2021 at 12:45:00PM +0100, Rafał Miłecki wrote:
From: Rafał Miłecki
The old binding was using whole DMU space. It was an overkill. DMU is a
big block which contains e.g. CRU which contains e.g. PLLs, PHY, pinctrl
and thermal blocks
From: Rafał Miłecki
USB bindings already allow specifying USB device hard wired to a
specific controller port but they don't allow describing port on its
own.
This fixes:
arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dt.yaml: usb@23000: port@1:
'compatible' is a required property
From
On 08.03.2021 22:37, Rafał Miłecki wrote:
On 08.03.2021 19:43, Rob Herring wrote:
On Tue, Mar 02, 2021 at 08:44:04AM +0100, Rafał Miłecki wrote:
From: Rafał Miłecki
NVRAM structure contains device data and can be accessed using MMIO.
Signed-off-by: Rafał Miłecki
---
.../bindings/firmware
On 08.03.2021 19:43, Rob Herring wrote:
On Tue, Mar 02, 2021 at 08:44:04AM +0100, Rafał Miłecki wrote:
From: Rafał Miłecki
NVRAM structure contains device data and can be accessed using MMIO.
Signed-off-by: Rafał Miłecki
---
.../bindings/firmware/brcm,nvram.yaml | 41
On 07.03.2021 18:04, Ansuel Smith wrote:
On Mon, Mar 08, 2021 at 10:48:32AM +0100, Rafał Miłecki wrote:
On 16.02.2021 22:26, Ansuel Smith wrote:
Document nvmem-partitions compatible used to treat mtd partitions as a
nvmem provider.
I'm just wondering if "nvmem-partitions" is accur
On 07.03.2021 18:04, Ansuel Smith wrote:
On Mon, Mar 08, 2021 at 10:48:32AM +0100, Rafał Miłecki wrote:
On 16.02.2021 22:26, Ansuel Smith wrote:
Document nvmem-partitions compatible used to treat mtd partitions as a
nvmem provider.
I'm just wondering if "nvmem-partitions" is accur
On 16.02.2021 22:26, Ansuel Smith wrote:
Document nvmem-partitions compatible used to treat mtd partitions as a
nvmem provider.
I'm just wondering if "nvmem-partitions" is accurate enough. Partitions
bit sounds a bit ambiguous in the mtd context.
What do you think about "mtd-nvmem-cells" or
On 05.03.2021 23:23, Rob Herring wrote:
On Wed, Mar 03, 2021 at 11:01:55AM +0100, Rafał Miłecki wrote:
[Rob: please advise]
On 16.02.2021 22:26, Ansuel Smith wrote:
Document nvmem-partitions compatible used to treat mtd partitions as a
nvmem provider.
Until now we were using "compa
From: Rafał Miłecki
Separated function was not improving code quality much (or at all).
Moreover it expected possible flash end address as argument and it was
returning NVRAM size.
The new code always operates on offsets which means less logic and less
calculations.
Signed-off-by: Rafał
From: Rafał Miłecki
This loop requires variable initialization, stop condition and post
iteration increment. It's pretty much a for loop definition.
Signed-off-by: Rafał Miłecki
---
drivers/firmware/broadcom/bcm47xx_nvram.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git
From: Rafał Miłecki
This simplifies function finding NVRAM. It doesn't directly deal with
NVRAM structure anymore and is a bit smaller.
Signed-off-by: Rafał Miłecki
---
drivers/firmware/broadcom/bcm47xx_nvram.c | 43 +--
1 file changed, 25 insertions(+), 18 deletions
From: Rafał Miłecki
This avoids duplicating code doing casting and checking for NVRAM magic.
Signed-off-by: Rafał Miłecki
---
drivers/firmware/broadcom/bcm47xx_nvram.c | 30 ++-
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/firmware/broadcom
From: Rafał Miłecki
1. Use "bcm47xx_" function name prefix for consistency
2. It takes flash start as argument so s/iobase/flash_start/
3. "off" was used for finding flash end so just call it "flash_size"
Signed-off-by: Rafał Miłecki
---
drivers/firmware
From: Rafał Miłecki
This patchset refactors driver part finding and reading NVRAM.
It been tested on BCM4706. Updated code checks the same offsets as
before. Driver still finds & copies NVRAM content.
It's a new patchset replacing previous single-patch attempt:
[PATCH V2 mips/linux
On 2021-03-06 09:00, Thomas Bogendoerfer wrote:
On Fri, Mar 05, 2021 at 12:56:55PM +0100, Rafał Miłecki wrote:
On 05.03.2021 12:47, Philippe Mathieu-Daudé wrote:
> On Fri, Mar 5, 2021 at 11:16 AM Rafał Miłecki wrote:
> > On 05.03.2021 10:58, Philippe Mathieu-Daudé wrote:
> >
Cc linux-phy@ again (after fixing recipients ML limit)
On 26.02.2021 12:45, Rafał Miłecki wrote:
From: Rafał Miłecki
Updated DT binding maps a single CRU register that is directly used for
the PHY control. Accessing common CRU reg is handled using syscon &
regmap.
The old binding has
Cc linux-phy@ again (after fixing recipients ML limit)
On 26.02.2021 12:45, Rafał Miłecki wrote:
From: Rafał Miłecki
The old binding was using whole DMU space. It was an overkill. DMU is a
big block which contains e.g. CRU which contains e.g. PLLs, PHY, pinctrl
and thermal blocks.
Rework
Cc linux-phy@ again (after fixing recipients limit)
On 26.02.2021 12:44, Rafał Miłecki wrote:
From: Rafał Miłecki
Minor example fixes:
1. Include bcm-nsp.h
2. Add address to the node name
Signed-off-by: Rafał Miłecki
---
This has been verified using dt_binding_check
---
.../bindings/phy
From: Rafał Miłecki
Broadcom's NVRAM structure contains device data and can be accessed
using I/O mapping.
Signed-off-by: Rafał Miłecki
---
V2: Use Broadcom's NVRAM specific binding. Generic "nvmem-iomap" binding
didn't make much sense. Thanks Srinivas!
---
.../devicetree/bind
From: Rafał Miłecki
This driver provides access to Broadcom's NVRAM.
Signed-off-by: Rafał Miłecki
---
V2: Applied Srinivas's suggestions:
* Simplified brcm_nvram_read
* Drop unneeded check & prints from probe
* Fixed MODULE_LICENSE
* Switched to Broadcom specific bin
Cc linux-phy@
On 26.02.2021 12:45, Rafał Miłecki wrote:
From: Rafał Miłecki
Updated DT binding maps a single CRU register that is directly used for
the PHY control. Accessing common CRU reg is handled using syscon &
regmap.
The old binding has been deprecated and stays as a fallback me
Cc linux-phy@
On 26.02.2021 12:45, Rafał Miłecki wrote:
From: Rafał Miłecki
The old binding was using whole DMU space. It was an overkill. DMU is a
big block which contains e.g. CRU which contains e.g. PLLs, PHY, pinctrl
and thermal blocks.
Rework the binding to directly use a single CRU
Cc linux-phy@
On 26.02.2021 12:44, Rafał Miłecki wrote:
From: Rafał Miłecki
Minor example fixes:
1. Include bcm-nsp.h
2. Add address to the node name
Signed-off-by: Rafał Miłecki
---
This has been verified using dt_binding_check
---
.../bindings/phy/bcm-ns-usb2-phy.txt | 21
On 05.03.2021 12:47, Philippe Mathieu-Daudé wrote:
On Fri, Mar 5, 2021 at 11:16 AM Rafał Miłecki wrote:
On 05.03.2021 10:58, Philippe Mathieu-Daudé wrote:
On Fri, Mar 5, 2021 at 6:55 AM Rafał Miłecki wrote:
From: Rafał Miłecki
1. Use meaningful variable names (e.g. "flash_
On 05.03.2021 11:33, Srinivas Kandagatla wrote:
On 05/03/2021 10:24, Rafał Miłecki wrote:
+static int iomap_read(void *context, unsigned int offset, void *val,
+ size_t bytes)
+{
+ struct iomap *priv = context;
+ u8 *src = priv->base + offset;
+ u8 *dst = val;
+ siz
Hi,
On 05.03.2021 10:58, Philippe Mathieu-Daudé wrote:
On Fri, Mar 5, 2021 at 6:55 AM Rafał Miłecki wrote:
From: Rafał Miłecki
1. Use meaningful variable names (e.g. "flash_start", "res_size" instead
of e.g. "iobase", "end")
2. Always operate
On 05.03.2021 11:02, Srinivas Kandagatla wrote:
On 04/03/2021 14:41, Rafał Miłecki wrote:
From: Rafał Miłecki
This is a generic NVMEM access method used e.g. by Broadcom for their
NVRAM on MIPS and Northstar devices.
Signed-off-by: Rafał Miłecki
---
drivers/nvmem/Kconfig | 7
On 04.03.2021 07:46, 'Wei Yongjun wrote:
From: Wei Yongjun
The sparse tool complains as follows:
drivers/mtd/parsers/ofpart_core.c:25:32: warning:
symbol 'bcm4908_partitions_quirks' was not declared. Should it be static?
This symbol is not used outside of ofpart_core.c, so this
commit
From: Rafał Miłecki
1. Use meaningful variable names (e.g. "flash_start", "res_size" instead
of e.g. "iobase", "end")
2. Always operate on "offset" instead of mix of start, end, size, etc.
3. Add helper checking for NVRAM to avoid duplicat
From: Rafał Miłecki
This is a generic NVMEM access method used e.g. by Broadcom for their
NVRAM on MIPS and Northstar devices.
Signed-off-by: Rafał Miłecki
---
drivers/nvmem/Kconfig | 7 +++
drivers/nvmem/Makefile | 2 +
drivers/nvmem/iomap.c | 99
From: Rafał Miłecki
NVMEM on some devices can be accessed using I/O mapping. For example on
Broadcom MIPS and ARM Northstar platforms NVRAM can be accessed that
way.
Signed-off-by: Rafał Miłecki
---
.../devicetree/bindings/nvmem/iomap.yaml | 29 +++
1 file changed, 29
From: Rafał Miłecki
1. Use meaningful variable names (e.g. "flash_start", "res_size" instead
of e.g. "iobase", "end")
2. Always operate on "offset" instead of mix of start, end, size, etc.
3. Add helper checking for NVRAM to avoid duplicat
On 02.03.2021 17:59, Florian Fainelli wrote:
On 3/1/21 11:44 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
Add support for platform device providing mapping resource. This allows
reading NVRAM based on DT mapping binding. It's required for devices
that boot depending on NVRAM stored setup
[Rob: please advise]
On 16.02.2021 22:26, Ansuel Smith wrote:
Document nvmem-partitions compatible used to treat mtd partitions as a
nvmem provider.
Until now we were using "compatible" string in partition node only for
parsers (looking for subpartitions). We need to think if this change can
On 16.02.2021 22:26, Ansuel Smith wrote:
Partitions that contains the nvmem-partitions compatible will register
their direct subonodes as nvmem cells and the node will be treated as a
nvmem provider.
Signed-off-by: Ansuel Smith
Tested-by: Rafał Miłecki
I applied this patch on top
On 16.02.2021 22:26, Ansuel Smith wrote:
If a partitions structure is not used, parse direct subnodes as
fixed-partitions only if a compatible is not found or is of type
fixed-partition. A parser can be used directly on the subnode and
subnodes should not be parsed as fixed-partitions by
From: Rafał Miłecki
NVRAM structure contains device data and can be accessed using MMIO.
Signed-off-by: Rafał Miłecki
---
.../bindings/firmware/brcm,nvram.yaml | 41 +++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/firmware
From: Rafał Miłecki
Add support for platform device providing mapping resource. This allows
reading NVRAM based on DT mapping binding. It's required for devices
that boot depending on NVRAM stored setup and provides early access to
NVRAM data.
Signed-off-by: Rafał Miłecki
---
bcm47xx_nvram
From: Rafał Miłecki
The old binding was using whole DMU space. It was an overkill. DMU is a
big block which contains e.g. CRU which contains e.g. PLLs, PHY, pinctrl
and thermal blocks.
Rework the binding to directly use a single CRU register that controls
USB 2.0 PHY. It's still required
From: Rafał Miłecki
Updated DT binding maps a single CRU register that is directly used for
the PHY control. Accessing common CRU reg is handled using syscon &
regmap.
The old binding has been deprecated and stays as a fallback method.
Signed-off-by: Rafał Miłecki
---
It's a reworked ver
From: Rafał Miłecki
Minor example fixes:
1. Include bcm-nsp.h
2. Add address to the node name
Signed-off-by: Rafał Miłecki
---
This has been verified using dt_binding_check
---
.../bindings/phy/bcm-ns-usb2-phy.txt | 21 ---
.../bindings/phy/brcm,ns-usb2-phy.yaml| 55
On Mon, 15 Feb 2021 at 10:37, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> Right now ofpart parser gets always compiled with the BCM4908 support.
> It's not a big issue at this point as BCM4908 partitioning support comes
> at close-to-zero cost. It may differ for possible furthe
Hi Stephen!
On 15.02.2021 02:28, Stephen Rothwell wrote:
After merging the mtd tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
ERROR: modpost: missing MODULE_LICENSE() in
drivers/mtd/parsers/bcm4908-partitions.o
ERROR: modpost: "bcm4908_partitions_post_parse"
From: Rafał Miłecki
Right now ofpart parser gets always compiled with the BCM4908 support.
It's not a big issue at this point as BCM4908 partitioning support comes
at close-to-zero cost. It may differ for possible further ofpart quirks
though.
Make BCM4908 support selectable to set a clean
From: Rafał Miłecki
This fixes:
ERROR: modpost: missing MODULE_LICENSE() in
drivers/mtd/parsers/bcm4908-partitions.o
ERROR: modpost: "bcm4908_partitions_post_parse" [drivers/mtd/parsers/ofpart.ko]
undefined!
Reported-by: Stephen Rothwell
Fixes: 09cf6ee6d21c ("mtd: parsers:
From: Rafał Miłecki
BCM4908 uses fixed partitions layout but function of some partitions may
vary. Some devices use multiple firmware partitions and those partitions
should be marked to let system discover their purpose.
Signed-off-by: Rafał Miłecki
---
V2: Use enum: [ 1, 2 ] for address
From: Rafał Miłecki
BCM4908 partitioning is based on fixed layout but allows specifying
multiple firmware partitions. It requires detecting which firmware
partition was used for booting current kernel.
To support such cases without duplicating a lot of code (without copying
most of the ofpart.c
From: Rafał Miłecki
Single partition binding is quite common and may be:
1. Used by multiple parsers
2. Extended for more specific cases
Move it to separated file to avoid code duplication.
Signed-off-by: Rafał Miłecki
Reviewed-by: Rob Herring
---
.../mtd/partitions/fixed-partitions.yaml
From: Rafał Miłecki
BCM4908 partitioning is based on fixed layout but allows specifying
multiple firmware partitions. It requires detecting which firmware
partition was used for booting current kernel.
To support such cases without duplicating a lot of code (without copying
most of the ofpart.c
From: Rafał Miłecki
BCM4908 uses fixed partitions layout but function of some partitions may
vary. Some devices use multiple firmware partitions and those partitions
should be marked to let system discover their purpose.
Signed-off-by: Rafał Miłecki
---
V2: Use enum: [ 1, 2 ] for address
From: Rafał Miłecki
Single partition binding is quite common and may be:
1. Used by multiple parsers
2. Extended for more specific cases
Move it to separated file to avoid code duplication.
Signed-off-by: Rafał Miłecki
Reviewed-by: Rob Herring
---
.../mtd/partitions/fixed-partitions.yaml
/bcm-pmb.c'.
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matches F:drivers/soc/bcm/bcm-pmb.c
Point the file entry to the right location.
Signed-off-by: Lukas Bulwahn
Thanks!
Acked-by: Rafał Miłecki
On 20.01.2021 20:58, Florian Fainelli wrote:
On 1/20/2021 11:48 AM, Florian Fainelli wrote:
On Thu, 14 Jan 2021 11:53:18 +0100, Rafał Miłecki wrote:
From: Rafał Miłecki
Some brcmstb drivers may be shared with other SoC families. E.g. the
same USB PHY block is shared by brcmstb and BCM4908
From: Rafał Miłecki
BCM4908 partitioning is based on fixed layout but allows specifying
multiple firmware partitions. It requires detecting which firmware
partition was used for booting current kernel.
To support such cases without duplicating a lot of code (without copying
most of the ofpart.c
From: Rafał Miłecki
BCM4908 uses fixed partitions layout but function of some partitions may
vary. Some devices use multiple firmware partitions and those should be
marked to let system discover their purpose.
Signed-off-by: Rafał Miłecki
---
.../partitions/brcm,bcm4908-partitions.yaml | 68
From: Rafał Miłecki
Single partition binding is quite common and may be:
1. Used by multiple parsers
2. Extended for more specific cases
Move it to separated file to avoid code duplication.
Signed-off-by: Rafał Miłecki
---
.../mtd/partitions/fixed-partitions.yaml | 33
From: Rafał Miłecki
BCM63138 has SATA controller that needs to be powered up using PMB.
Signed-off-by: Rafał Miłecki
---
Florian: this is based on your patches
ARM: dts: BCM63xx: enable SATA PHY and AHCI controller
reset: bcm63xx: Add Broadcom BCM63138 reset controller driver
I didn't test
From: Rafał Miłecki
PMB can be also found on bcm63xx chipsets. It uses difference device
addresses so a new binding is required.
Signed-off-by: Rafał Miłecki
---
Documentation/devicetree/bindings/power/brcm,bcm-pmb.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation
From: Rafał Miłecki
Some brcmstb drivers may be shared with other SoC families. E.g. the
same USB PHY block is shared by brcmstb and BCM4908.
To avoid building brcmstb common code on non-brcmstb platforms we need
stubs for:
1. brcmstb_get_family_id()
2. brcmstb_get_product_id()
(to avoid
From: Rafał Miłecki
BCM4908 uses the same PHY and may require just a slightly different
programming.
Signed-off-by: Rafał Miłecki
Acked-by: Florian Fainelli
Acked-by: Rob Herring
---
.../devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml| 5 -
1 file changed, 4 insertions(+), 1
From: Rafał Miłecki
BCM4908 seems to have slightly different registers but works when
programmed just like the STB one.
Signed-off-by: Rafał Miłecki
Acked-by: Florian Fainelli
---
V2: Update Kconfig as well
---
drivers/phy/broadcom/Kconfig| 3 ++-
drivers/phy/broadcom/phy-brcm-usb.c
From: Rafał Miłecki
Changes that require mentioning:
1. interrupt-names
Name "wakeup" was changed to the "wake". It matches example and what
Linux driver looks for in the first place
2. brcm,ipp and brcm,ioc
Both were described as booleans with 0 / 1 values. In e
From: Rafał Miłecki
BCM4908 seems to have slightly different registers but works when
programmed just like the STB one.
Signed-off-by: Rafał Miłecki
---
V2: Update Kconfig as well
---
drivers/phy/broadcom/Kconfig| 3 ++-
drivers/phy/broadcom/phy-brcm-usb.c | 4
2 files changed, 6
From: Rafał Miłecki
BCM4908 uses the same PHY and may require just a slightly different
programming.
Signed-off-by: Rafał Miłecki
Acked-by: Florian Fainelli
Acked-by: Rob Herring
---
.../devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml| 5 -
1 file changed, 4 insertions(+), 1
From: Rafał Miłecki
Changes that require mentioning:
1. interrupt-names
Name "wakeup" was changed to the "wake". It matches example and what
Linux driver looks for in the first place
2. brcm,ipp and brcm,ioc
Both were described as booleans with 0 / 1 values. In e
On 03.01.2021 17:23, Rob Herring wrote:
On Mon, Dec 21, 2020 at 06:23:37AM +0100, Rafał Miłecki wrote:
From: Rafał Miłecki
Changes that require mentioning:
1. interrupt-names
Name "wakeup" was changed to the "wake". It matches example and what
Linux driver looks fo
From: Rafał Miłecki
BCM4908 seems to have slightly different registers but works when
programmed just like the STB one.
Signed-off-by: Rafał Miłecki
---
V2: Update Kconfig as well
---
drivers/phy/broadcom/Kconfig| 3 ++-
drivers/phy/broadcom/phy-brcm-usb.c | 4
2 files changed, 6
From: Rafał Miłecki
BCM4908 uses the same PHY and may require just a slightly different
programming.
Signed-off-by: Rafał Miłecki
Acked-by: Florian Fainelli
---
.../devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml| 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
From: Rafał Miłecki
Changes that require mentioning:
1. interrupt-names
Name "wakeup" was changed to the "wake". It matches example and what
Linux driver looks for in the first place
2. brcm,ipp and brcm,ioc
Both were described as booleans with 0 / 1 values. In e
From: Rafał Miłecki
This is slightly cleaner solution that assures noone assings a wrong
function to the pointer.
Signed-off-by: Rafał Miłecki
---
drivers/phy/broadcom/phy-brcm-usb.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/broadcom/phy-brcm-usb.c
From: Rafał Miłecki
1. Use of_device_get_match_data() helper to simplify the code
2. Check for NULL as a good practice
Signed-off-by: Rafał Miłecki
---
drivers/phy/broadcom/phy-brcm-usb.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/broadcom/phy-brcm
From: Rafał Miłecki
BCM4908 seems to have slightly different registers but work when
programmed just like the STB one.
Signed-off-by: Rafał Miłecki
---
drivers/phy/broadcom/phy-brcm-usb.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/phy/broadcom/phy-brcm-usb.c
b/drivers
From: Rafał Miłecki
BCM4908 uses the same PHY and may require just slightly different
programming.
Signed-off-by: Rafał Miłecki
---
.../devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml| 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree
From: Rafał Miłecki
Changes that require mentioning:
1. interrupt-names
Name "wakeup" was changed to the "wake". It matches example and what
Linux driver looks for in the first place
2. brcm,ipp and brcm,ioc
Both were described as booleans with 0 / 1 values. In e
On 14.12.2020 18:32, Florian Fainelli wrote:
On 12/14/20 4:24 AM, Rafał Miłecki wrote:
On 11.12.2020 23:08, Florian Fainelli wrote:
On 12/11/20 1:59 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
PMB can be found on BCM4908 and many other chipsets (e.g. BCM63138).
It's needed to power
From: Rafał Miłecki
PMB originally comes from BCM63138 but can be also found on many other
chipsets (e.g. BCM4908). It's needed to power on and off SoC blocks like
PCIe, SATA, USB.
Signed-off-by: Rafał Miłecki
---
V2: Use drivers/soc/bcm/bcm63xx/
Add help to the config BCM_PMB
Drop
From: Rafał Miłecki
PMB is a hardware block used for powering SoC devices like PCIe, USB,
SATA. Initially I planned to treat it as a reset controller and Philipp
pointed out in review that PMB driver should use a power subsystem.
This is my refactored support.
***
Please note one difference
From: Rafał Miłecki
Broadcom's PMB is power controller used for disabling and enabling SoC
devices.
Signed-off-by: Rafał Miłecki
---
.../bindings/power/brcm,bcm-pmb.yaml | 50 +++
include/dt-bindings/soc/bcm-pmb.h | 11
2 files changed, 61 insertions
On 11.12.2020 23:08, Florian Fainelli wrote:
On 12/11/20 1:59 PM, Rafał Miłecki wrote:
From: Rafał Miłecki
PMB can be found on BCM4908 and many other chipsets (e.g. BCM63138).
It's needed to power on and off SoC blocks like PCIe, SATA, USB.
Signed-off-by: Rafał Miłecki
I will do a more
On 12.12.2020 04:26, Florian Fainelli wrote:
+
+static const struct bcm_pmb_pd_data bcm_pmb_bcm4908_data[] = {
+ { .name = "pcie2", .id = BCM_PMB_PCIE2, .bus = 0, .device = 2, },
+ { .name = "pcie0", .id = BCM_PMB_PCIE0, .bus = 1, .device = 14, },
+ { .name = "pcie1", .id =
On 11.12.2020 22:59, Rafał Miłecki wrote:
@@ -13,6 +13,14 @@ config BCM2835_POWER
firmware means that Linux usage of the same power domain
must be accessed using the RASPBERRYPI_POWER driver
+config BCM_PMB
+ bool "Broadcom PMB (Power Management Bus) d
On Fri, 11 Dec 2020 at 23:08, Florian Fainelli wrote:
> On 12/11/20 1:59 PM, Rafał Miłecki wrote:
> > From: Rafał Miłecki
> >
> > PMB can be found on BCM4908 and many other chipsets (e.g. BCM63138).
> > It's needed to power on and off SoC blocks like PCIe, SATA, USB.
&
From: Rafał Miłecki
Broadcom's PMB is power controller used for disabling and enabling SoC
devices.
Signed-off-by: Rafał Miłecki
---
.../bindings/power/brcm,bcm-pmb.yaml | 50 +++
include/dt-bindings/soc/bcm-pmb.h | 11
2 files changed, 61 insertions
From: Rafał Miłecki
PMB can be found on BCM4908 and many other chipsets (e.g. BCM63138).
It's needed to power on and off SoC blocks like PCIe, SATA, USB.
Signed-off-by: Rafał Miłecki
---
drivers/soc/bcm/Kconfig | 8 +
drivers/soc/bcm/Makefile | 1 +
drivers/soc/bcm/bcm-pmb.c | 335
From: Rafał Miłecki
PMB is a hardware block used for powering SoC devices like PCIe, USB,
SATA. Initially I planned to treat it as a reset controller and Philipp
pointed out in review that PMB driver should use a power subsystem.
This is my refactored support.
***
Please note one difference
On Wed, 2 Dec 2020 at 21:48, Rafał Miłecki wrote:
> 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
Please drop this patchset for now as Florian pointed
On 04.12.2020 17:38, Florian Fainelli wrote:
On 12/4/2020 1:37 AM, Rafał Miłecki wrote:
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
On 04.12.2020 17:32, Florian Fainelli wrote:
On 12/4/2020 1:37 AM, Rafał Miłecki wrote:
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
On Fri, 4 Dec 2020 at 17:13, Philipp Zabel wrote:
> On Fri, 2020-12-04 at 10:37 +0100, Rafał Miłecki wrote:
> > From: Rafał Miłecki
> >
> > This controller is responsible for OHCI, EHCI, XHCI and PHYs setup that
> > has to be handled in the proper order.
>
1 - 100 of 1227 matches
Mail list logo
