* [PATCH v3 1/4] PM / Domains: Add generic data pointer to genpd data struct
From: Dave Gerlach @ 2017-01-04 20:55 UTC (permalink / raw)
To: Ulf Hansson, Rafael J . Wysocki, Kevin Hilman, Rob Herring
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Nishanth Menon, Dave Gerlach,
Keerthy, Russell King, Tero Kristo, Sudeep Holla,
Santosh Shilimkar, Lokesh Vutla
In-Reply-To: <20170104205536.15963-1-d-gerlach-l0cyMroinI0@public.gmane.org>
Add a void *data pointer to struct generic_pm_domain_data. Because this
exists for each device associated with a genpd it will allow us to
assign per-device data if needed on a platform for control of that
specific device.
Acked-by: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
---
include/linux/pm_domain.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 81ece61075df..73c9dba5cfcc 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -117,6 +117,7 @@ struct generic_pm_domain_data {
struct pm_domain_data base;
struct gpd_timing_data td;
struct notifier_block nb;
+ void *data;
};
#ifdef CONFIG_PM_GENERIC_DOMAINS
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 0/4] ARM: K2G: Add support for TI-SCI Generic PM Domains
From: Dave Gerlach @ 2017-01-04 20:55 UTC (permalink / raw)
To: Ulf Hansson, Rafael J . Wysocki, Kevin Hilman, Rob Herring
Cc: linux-arm-kernel, linux-kernel, linux-pm, devicetree,
Nishanth Menon, Dave Gerlach, Keerthy, Russell King, Tero Kristo,
Sudeep Holla, Santosh Shilimkar, Lokesh Vutla
Hi,
This is v3 of the series to add support for TI-SCI Generic PM Domains.
Previous versions can be found here:
v2: https://www.spinics.net/lists/kernel/msg2364612.html
v1: http://www.spinics.net/lists/arm-kernel/msg525204.html
This version is rebased on v4.10-rc2 but is the same as v2 with the
exception of patch 2 in which the devicetree binding documentation
needed to be updated to show the k2g_pds node should be a child of
the pmmc node. Apart from that, the acks provided by Ulf were added
to patches 1 and 3.
Now that the TI-SCI series has been merged [1] this series will be ready
to go in with an ack on the DT binding. Rob had raised some questions on
the necessity ti,sci-id property but I believe these were properly
addressed during the discussion of v2 so hopefully an ack is in order now.
Regards,
Dave
[1] http://www.spinics.net/lists/arm-kernel/msg536851.html
Dave Gerlach (4):
PM / Domains: Add generic data pointer to genpd data struct
dt-bindings: Add TI SCI PM Domains
soc: ti: Add ti_sci_pm_domains driver
ARM: keystone: Drop PM domain support for k2g
.../devicetree/bindings/soc/ti/sci-pm-domain.txt | 59 ++++++
MAINTAINERS | 3 +
arch/arm/mach-keystone/Kconfig | 1 +
arch/arm/mach-keystone/pm_domain.c | 4 +-
drivers/soc/ti/Kconfig | 12 ++
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/ti_sci_pm_domains.c | 198 +++++++++++++++++++++
include/dt-bindings/genpd/k2g.h | 90 ++++++++++
include/linux/pm_domain.h | 1 +
9 files changed, 368 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
create mode 100644 drivers/soc/ti/ti_sci_pm_domains.c
create mode 100644 include/dt-bindings/genpd/k2g.h
--
2.11.0
^ permalink raw reply
* Re: [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
From: Rob Herring @ 2017-01-04 20:39 UTC (permalink / raw)
To: Peter Senna Tschudin
Cc: Jiri Slaby, dri-devel, Martyn Welch, Takashi Iwai, Russell King,
Kumar Gala, Peter Senna Tschudin, Archit Taneja, Fabio Estevam,
Ian Campbell, David Miller, Mark Rutland, Russell King,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ, Mauro Carvalho Chehab,
Peter Senna Tschudin, Thierry Reding,
Greg Kroah-Hartman <gregkh@
In-Reply-To: <529b-586c3500-5-5e05b080@98620974>
On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin
<peter.senna-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org> wrote:
> Hi Rob,
>
> Thank you for the review.
>
> On 03 January, 2017 23:51 CET, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
>> On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin wrote:
>> > Devicetree bindings documentation for the GE B850v3 LVDS/DP++
>> > display bridge.
>> >
>> > Cc: Martyn Welch <martyn.welch-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
>> > Cc: Martin Donnelly <martin.donnelly-JJi787mZWgc@public.gmane.org>
>> > Cc: Javier Martinez Canillas <javier-0uQlZySMnqxg9hUCZPvPmw@public.gmane.org>
>> > Cc: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
>> > Cc: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>> > Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> > Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
>> > Signed-off-by: Peter Senna Tschudin <peter.senna-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
>> > ---
>> > There was an Acked-by from Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> for V6, but I changed
>> > the bindings to use i2c_new_secondary_device() so I removed it from the commit
>> > message.
>> >
>> > .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 39 ++++++++++++++++++++++
>>
>> Generally, bindings are not organized by vendor. Put in
>> bindings/display/bridge/... instead.
>
> Will change that.
>
>>
>> > 1 file changed, 39 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
>> > new file mode 100644
>> > index 0000000..1bc6ebf
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
>> > @@ -0,0 +1,39 @@
>> > +Driver for GE B850v3 LVDS/DP++ display bridge
>> > +
>> > +Required properties:
>> > + - compatible : should be "ge,b850v3-lvds-dp".
>>
>> Isn't '-lvds-dp' redundant? The part# should be enough.
>
> b850v3 is the name of the product, this is why the proposed name. What about, b850v3-dp2 dp2 indicating the second DP output?
Humm, b850v3 is the board name? This node should be the name of the bridge chip.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] iio: adc: Add Renesas GyroADC driver
From: Geert Uytterhoeven @ 2017-01-04 20:36 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Geert Uytterhoeven, Simon Horman
In-Reply-To: <f4bb8922-36dc-ff69-45fc-e1d9cba821ba-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Marek,
On Wed, Jan 4, 2017 at 3:27 PM, Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 01/02/2017 11:01 AM, Geert Uytterhoeven wrote:
>> On Fri, Dec 30, 2016 at 8:18 PM, Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/adc/renesas,gyroadc.txt
>>> @@ -0,0 +1,38 @@
>>> +* Renesas RCar GyroADC device driver
>>> +
>>> +Required properties:
>>> +- compatible: Should be "renesas,rcar-gyroadc" for regular GyroADC or
>>> + "renesas,rcar-gyroadc-r8a7792" for GyroADC without interrupt
>>
>> Please use "renesas,r8a7792-gyroadc" to match existing practices.
>
> Actually, that should probably be gyroadc-r8a7791 if we want to match
> the existing practice. Fixed.
No, "renesas,r8a7791-gyroadc" ("<vendor>,<family>-<block>").
>>> +static void rcar_gyroadc_hw_init(struct rcar_gyroadc *priv)
>>> +{
>>> + unsigned long clk_mhz = clk_get_rate(priv->clk) / 1000000;
>>> +
>>> + /* Stop the GyroADC. */
>>> + writel(0, priv->regs + RCAR_GYROADC_START_STOP);
>>> +
>>> + /* Disable IRQ, except on V2H. */
>>> + if (priv->model != RCAR_GYROADC_MODEL_R8A7792)
>>> + writel(0, priv->regs + RCAR_GYROADC_INTENR);
>>> +
>>> + /* Set mode and timing. */
>>> + writel(priv->mode, priv->regs + RCAR_GYROADC_MODE_SELECT);
>>> +
>>> + if (priv->mode == RCAR_GYROADC_MODE_SELECT_1_MB88101A)
>>> + writel(clk_mhz * 10, priv->regs + RCAR_GYROADC_CLOCK_LENGTH);
>>> + else if (priv->mode == RCAR_GYROADC_MODE_SELECT_2_ADCS7476)
>>> + writel(clk_mhz * 5, priv->regs + RCAR_GYROADC_CLOCK_LENGTH);
>>> + else if (priv->mode == RCAR_GYROADC_MODE_SELECT_3_MAX1162)
>>> + writel(clk_mhz * 5, priv->regs + RCAR_GYROADC_CLOCK_LENGTH);
>>> + writel(clk_mhz * 1250, priv->regs + RCAR_GYROADC_1_25MS_LENGTH);
>>> +
>>> + /*
>>> + * We can possibly turn the sampling on/off on-demand to reduce power
>>
>> And the module clock, using runtime PM (see below).
>>> +static int rcar_gyroadc_probe(struct platform_device *pdev)
>>> +{
>>
>>> + priv->fclk = devm_clk_get(dev, "fck");
>>
>> The module clock isn't used directly by this driver (you don't need
>> e.g. its rate),
>> so you can leave out all handling related to this clock iff you enable
>> runtime PM:
>>
>> pm_runtime_enable(dev);
>> pm_runtime_get_sync(dev);
>>
>> Then runtime PM will take care of enabling the module clock, as the
>> GyroADC block is part of the CPG/MSSR clock domain.
>> Doing that also means the driver keeps on working in future SoCs where
>> the GyroADC block may be located in a power area.
>
> So I won't even need the fclk phandle in DT, right ?
You still need the fclk phandle in DT, so the PM domain code can find out
which clock to use for PM.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 4/4] ARM: dts: keystone: Add "ti,da830-uart" compatible string
From: David Lechner @ 2017-01-04 20:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sekhar Nori, Santosh Shilimkar
Cc: David Lechner, Franklin S Cooper Jr, Rob Herring, Mark Rutland,
Kevin Hilman, Axel Haslam, Alexandre Bailon, Bartosz Golaszewski,
Jiri Slaby, linux-serial, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <1483561814-21953-1-git-send-email-david@lechnology.com>
The TI Keystone SoCs have extra UART registers beyond the standard 8250
registers, so we need a new compatible string to indicate this. Also, at
least one of these registers uses the full 32 bits, so we need to specify
reg-io-width in addition to reg-shift.
"ns16550a" is left in the compatible specification since it does work as
long as the bootloader configures the SoC UART power management registers.
Signed-off-by: David Lechner <david@lechnology.com>
---
v2 changes:
* This is a new patch in v2
arch/arm/boot/dts/keystone-k2g.dtsi | 2 +-
arch/arm/boot/dts/keystone-k2l.dtsi | 4 ++--
arch/arm/boot/dts/keystone.dtsi | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi b/arch/arm/boot/dts/keystone-k2g.dtsi
index 63c7cf0c..7d7b9a8 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -90,7 +90,7 @@
};
uart0: serial@02530c00 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
diff --git a/arch/arm/boot/dts/keystone-k2l.dtsi b/arch/arm/boot/dts/keystone-k2l.dtsi
index 0c5e74e..e91633f 100644
--- a/arch/arm/boot/dts/keystone-k2l.dtsi
+++ b/arch/arm/boot/dts/keystone-k2l.dtsi
@@ -35,7 +35,7 @@
/include/ "keystone-k2l-clocks.dtsi"
uart2: serial@02348400 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
@@ -45,7 +45,7 @@
};
uart3: serial@02348800 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 02708ba..9152610 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -98,7 +98,7 @@
/include/ "keystone-clocks.dtsi"
uart0: serial@02530c00 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
@@ -108,7 +108,7 @@
};
uart1: serial@02531000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
current-speed = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/4] ARM: da850: Add ti,da830-uart compatible for serial ports
From: David Lechner @ 2017-01-04 20:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sekhar Nori, Santosh Shilimkar
Cc: David Lechner, Franklin S Cooper Jr, Rob Herring, Mark Rutland,
Kevin Hilman, Axel Haslam, Alexandre Bailon, Bartosz Golaszewski,
Jiri Slaby, linux-serial, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <1483561814-21953-1-git-send-email-david@lechnology.com>
TI DA8xx/OMAPL13x/AM17xx/AM18xx SoCs have extra UART registers beyond
the standard 8250 registers, so we need a new compatible string to
indicate this. Also, at least one of these registers uses the full 32
bits, so we need to specify reg-io-width in addition to reg-shift.
"ns16550a" is left in the compatible specification since it does work
as long as the bootloader configures the SoC UART power management
registers.
Signed-off-by: David Lechner <david@lechnology.com>
---
v2 changes:
* None
arch/arm/boot/dts/da850.dtsi | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 104155d..f6cd212 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -266,22 +266,25 @@
interrupt-names = "edm3_tcerrint";
};
serial0: serial@42000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
reg = <0x42000 0x100>;
+ reg-io-width = <4>;
reg-shift = <2>;
interrupts = <25>;
status = "disabled";
};
serial1: serial@10c000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
reg = <0x10c000 0x100>;
+ reg-io-width = <4>;
reg-shift = <2>;
interrupts = <53>;
status = "disabled";
};
serial2: serial@10d000 {
- compatible = "ns16550a";
+ compatible = "ti,da830-uart", "ns16550a";
reg = <0x10d000 0x100>;
+ reg-io-width = <4>;
reg-shift = <2>;
interrupts = <61>;
status = "disabled";
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/4] serial: 8250: Add new port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx/C66x
From: David Lechner @ 2017-01-04 20:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sekhar Nori, Santosh Shilimkar
Cc: David Lechner, Franklin S Cooper Jr, Rob Herring, Mark Rutland,
Kevin Hilman, Axel Haslam, Alexandre Bailon, Bartosz Golaszewski,
Jiri Slaby, linux-serial-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1483561814-21953-1-git-send-email-david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
This adds a new UART port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx/C66x.
These SoCs have standard 8250 registers plus some extra non-standard
registers.
The UART will not function unless the non-standard Power and Emulation
Management Register (PWREMU_MGMT) is configured correctly. This is
currently handled in arch/arm/mach-davinci/serial.c for non-device-tree
boards. Making this part of the UART driver will allow UART to work on
device-tree boards as well and the mach code can eventually be removed.
Signed-off-by: David Lechner <david-nq/r/kbU++upp/zk7JDF2g@public.gmane.org>
---
v2 changes:
* Added C66x to list of SoCs
drivers/tty/serial/8250/8250_of.c | 1 +
drivers/tty/serial/8250/8250_port.c | 22 ++++++++++++++++++++++
include/uapi/linux/serial_core.h | 3 ++-
include/uapi/linux/serial_reg.h | 8 ++++++++
4 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_of.c b/drivers/tty/serial/8250/8250_of.c
index d25ab1c..5281252 100644
--- a/drivers/tty/serial/8250/8250_of.c
+++ b/drivers/tty/serial/8250/8250_of.c
@@ -332,6 +332,7 @@ static const struct of_device_id of_platform_serial_table[] = {
.data = (void *)PORT_ALTR_16550_F128, },
{ .compatible = "mrvl,mmp-uart",
.data = (void *)PORT_XSCALE, },
+ { .compatible = "ti,da830-uart", .data = (void *)PORT_DA830, },
{ /* end of list */ },
};
MODULE_DEVICE_TABLE(of, of_platform_serial_table);
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index fe4399b..61dd806 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -273,6 +273,15 @@ static const struct serial8250_config uart_config[] = {
.rxtrig_bytes = {1, 4, 8, 14},
.flags = UART_CAP_FIFO,
},
+ [PORT_DA830] = {
+ .name = "TI DA8xx/OMAPL13x/AM17xx/AM18xx/C66x",
+ .fifo_size = 16,
+ .tx_loadsz = 16,
+ .fcr = UART_FCR_DMA_SELECT | UART_FCR_ENABLE_FIFO |
+ UART_FCR_R_TRIG_10,
+ .rxtrig_bytes = {1, 4, 8, 14},
+ .flags = UART_CAP_FIFO | UART_CAP_AFE,
+ },
};
/* Uart divisor latch read */
@@ -2118,6 +2127,19 @@ int serial8250_do_startup(struct uart_port *port)
serial_port_out(port, UART_LCR, 0);
}
+ if (port->type == PORT_DA830) {
+ /* Reset the port */
+ serial_port_out(port, UART_IER, 0);
+ serial_port_out(port, UART_DA830_PWREMU_MGMT, 0);
+ mdelay(10);
+
+ /* Enable Tx, Rx and free run mode */
+ serial_port_out(port, UART_DA830_PWREMU_MGMT,
+ UART_DA830_PWREMU_MGMT_UTRST |
+ UART_DA830_PWREMU_MGMT_URRST |
+ UART_DA830_PWREMU_MGMT_FREE);
+ }
+
#ifdef CONFIG_SERIAL_8250_RSA
/*
* If this is an RSA port, see if we can kick it up to the
diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
index 99dbed8..1265918 100644
--- a/include/uapi/linux/serial_core.h
+++ b/include/uapi/linux/serial_core.h
@@ -56,7 +56,8 @@
#define PORT_ALTR_16550_F128 28 /* Altera 16550 UART with 128 FIFOs */
#define PORT_RT2880 29 /* Ralink RT2880 internal UART */
#define PORT_16550A_FSL64 30 /* Freescale 16550 UART with 64 FIFOs */
-#define PORT_MAX_8250 30 /* max port ID */
+#define PORT_DA830 31 /* TI DA8xx/OMAP13x/AM17xx/AM18xx/C66x */
+#define PORT_MAX_8250 31 /* max port ID */
/*
* ARM specific type numbers. These are not currently guaranteed
diff --git a/include/uapi/linux/serial_reg.h b/include/uapi/linux/serial_reg.h
index b4c0484..84606d8 100644
--- a/include/uapi/linux/serial_reg.h
+++ b/include/uapi/linux/serial_reg.h
@@ -327,6 +327,14 @@
#define SERIAL_RSA_BAUD_BASE (921600)
#define SERIAL_RSA_BAUD_BASE_LO (SERIAL_RSA_BAUD_BASE / 8)
+/* Extra registers for TI DA8xx/OMAP13x/AM17xx/AM18xx/C66x */
+#define UART_DA830_PWREMU_MGMT 12
+
+/* PWREMU_MGMT register bits */
+#define UART_DA830_PWREMU_MGMT_FREE (1 << 0) /* Free-running mode */
+#define UART_DA830_PWREMU_MGMT_URRST (1 << 13) /* Receiver reset/enable */
+#define UART_DA830_PWREMU_MGMT_UTRST (1 << 14) /* Transmitter reset/enable */
+
/*
* Extra serial register definitions for the internal UARTs
* in TI OMAP processors.
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 1/4] doc: DT: Add ti,da830-uart to serial/8250 bindings
From: David Lechner @ 2017-01-04 20:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sekhar Nori, Santosh Shilimkar
Cc: David Lechner, Franklin S Cooper Jr, Rob Herring, Mark Rutland,
Kevin Hilman, Axel Haslam, Alexandre Bailon, Bartosz Golaszewski,
Jiri Slaby, linux-serial, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <1483561814-21953-1-git-send-email-david@lechnology.com>
This adds the ti,da830-uart compatible string to serial 8250 UART bindings.
Signed-off-by: David Lechner <david@lechnology.com>
Acked-by: Rob Herring <robh@kernel.org>
---
v2 changes:
* picked up Acked-by:
Documentation/devicetree/bindings/serial/8250.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
index f86bb06..10276a4 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -19,6 +19,7 @@ Required properties:
- "altr,16550-FIFO128"
- "fsl,16550-FIFO64"
- "fsl,ns16550"
+ - "ti,da830-uart"
- "serial" if the port type is unknown.
- reg : offset and length of the register set for the device.
- interrupts : should contain uart interrupt.
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/4] TI DA8xx/OMAPL13x/AM17xx/AM18xx/C66x UART
From: David Lechner @ 2017-01-04 20:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sekhar Nori, Santosh Shilimkar
Cc: David Lechner, Franklin S Cooper Jr, Rob Herring, Mark Rutland,
Kevin Hilman, Axel Haslam, Alexandre Bailon, Bartosz Golaszewski,
Jiri Slaby, linux-serial-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
This series adds a new UART port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx/C66x
UART. This SoCs have a non-standard register for UART power management that
needs special handling in the UART driver.
v2 changes:
* Added references to C66x SoC in various places, which I assume is an OK
shorthand for TI Keystone processors.
* New patch for Keystone device tree. This is untested as I don't have any
Keystone boards.
David Lechner (4):
doc: DT: Add ti,da830-uart to serial/8250 bindings
serial: 8250: Add new port type for TI
DA8xx/OMAPL13x/AM17xx/AM18xx/C66x
ARM: da850: Add ti,da830-uart compatible for serial ports
ARM: dts: keystone: Add "ti,da830-uart" compatible string
Documentation/devicetree/bindings/serial/8250.txt | 1 +
arch/arm/boot/dts/da850.dtsi | 9 ++++++---
arch/arm/boot/dts/keystone-k2g.dtsi | 2 +-
arch/arm/boot/dts/keystone-k2l.dtsi | 4 ++--
arch/arm/boot/dts/keystone.dtsi | 4 ++--
drivers/tty/serial/8250/8250_of.c | 1 +
drivers/tty/serial/8250/8250_port.c | 22 ++++++++++++++++++++++
include/uapi/linux/serial_core.h | 3 ++-
include/uapi/linux/serial_reg.h | 8 ++++++++
9 files changed, 45 insertions(+), 9 deletions(-)
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2 2/5] phy: phy-exynos-pcie: Add support for Exynos PCIe phy
From: Jingoo Han @ 2017-01-04 20:21 UTC (permalink / raw)
To: 'Jaehoon Chung', linux-pci
Cc: devicetree, linux-kernel, linux-samsung-soc, bhelgaas, robh+dt,
mark.rutland, kgene, krzk, kishon, vivek.gautam, pankaj.dubey,
alim.akhtar, cpgs
In-Reply-To: <20170104123435.30740-3-jh80.chung@samsung.com>
On Wednesday, January 4, 2017 7:35 AM, Jaehoon Chung wrote:
>
> This patch supports to use Generic Phy framework for Exynos PCIe phy.
> When Exynos that supported the pcie want to use the PCIe,
> it needs to control the phy resgister.
> But it should be more complex to control in their own PCIe device drivers.
>
> Currently, there is an exynos5440 case to support the pcie.
> So this driver is based on Exynos5440 PCIe.
> In future, will support the Other exynos SoCs likes exynos5433, exynos7.
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Jingoo Han <jingoohan1@gmail.com>
Best regards,
Jingoo Han
> ---
> Changelog on V2:
> - Not include the codes relevant to pci-exynos.
> - Remove the getting child node.
>
> drivers/phy/Kconfig | 9 ++
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-exynos-pcie.c | 280
> ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 290 insertions(+)
> create mode 100644 drivers/phy/phy-exynos-pcie.c
>
^ permalink raw reply
* Re: [PATCH V6 4/3] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits
From: Arend Van Spriel @ 2017-01-04 20:07 UTC (permalink / raw)
To: Rafał Miłecki, Johannes Berg,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Rafał Miłecki
In-Reply-To: <20170104175832.25996-4-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 4-1-2017 18:58, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> There are some devices (e.g. Netgear R8000 home router) with one chipset
> model used for different radios, some of them limited to subbands. NVRAM
> entries don't contain any extra info on such limitations and firmware
> reports full list of channels to us. We need to store extra limitation
> info in DT to support such devices properly.
>
> Now there is a cfg80211 helper for reading such info use it in brcmfmac.
> This patch adds check for channel being disabled with orig_flags which
> is how this wiphy helper and wiphy_register work.
>
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> ---
> This patch should probably go through wireless-driver-next which is why
> it got weird number 4/3. I'm sending it just as a proof of concept.
> It was succesfully tested on SmartRG SR400ac with BCM43602.
>
> V4: Respect IEEE80211_CHAN_DISABLED in orig_flags
> V5: Update commit message
> V6: Call wiphy_read_of_freq_limits after brcmf_setup_wiphybands to make it work
> with helper setting "flags" instead of "orig_flags".
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index ccae3bb..a008ba5 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -5886,6 +5886,9 @@ static int brcmf_construct_chaninfo(struct brcmf_cfg80211_info *cfg,
> band->band);
> channel[index].hw_value = ch.control_ch_num;
>
> + if (channel->orig_flags & IEEE80211_CHAN_DISABLED)
> + continue;
> +
So to be clear this is still needed for subsequent calls to
brcmf_setup_wiphybands(). The subsequent calls are done from the
regulatory notifier. So I think we have an issue with this approach. Say
the device comes up with US. That would set DISABLED flags for channels
12 to 14. With a country update to PL we would want to enable channels
12 and 13, right? The orig_flags are copied from the initial flags
during wiphy_register() so it seems we will skip enabling 12 and 13. I
think we should remove the check above and call
wiphy_read_of_freq_limits() as a last step within
brcmf_setup_wiphybands(). It means it is called every time, but it
safeguards that the limits in DT are always applied.
Regards,
Arend
> /* assuming the chanspecs order is HT20,
> * HT40 upper, HT40 lower, and VHT80.
> */
> @@ -6478,7 +6481,11 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, struct brcmf_if *ifp)
> }
> }
> err = brcmf_setup_wiphybands(wiphy);
> - return err;
> + if (err)
> + return err;
> + wiphy_read_of_freq_limits(wiphy);
> +
> + return 0;
> }
>
> static s32 brcmf_config_dongle(struct brcmf_cfg80211_info *cfg)
>
^ permalink raw reply
* Re: [PATCH] of: drop duplicate headers
From: Rob Herring @ 2017-01-04 20:02 UTC (permalink / raw)
To: Geliang Tang
Cc: Pantelis Antoniou, Frank Rowand,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <2dbc4a9165d0a1e1569dc3990cbe5567fb312c74.1482593743.git.geliangtang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Sat, Dec 24, 2016 at 11:45:06PM +0800, Geliang Tang wrote:
> Drop duplicate headers string.h and of_platform.h.
>
> Signed-off-by: Geliang Tang <geliangtang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/of/overlay.c | 1 -
> drivers/of/resolver.c | 1 -
> drivers/of/unittest.c | 1 -
> 3 files changed, 3 deletions(-)
Applied, thanks.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] of: reserved_mem: set dma_ops for devices using reserved mem
From: Rob Herring @ 2017-01-04 20:02 UTC (permalink / raw)
To: Pankaj Dubey
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w, krzk-DgEjT+Ai2ygdnm+yROfE0A,
kgene-DgEjT+Ai2ygdnm+yROfE0A, Smitha T Murthy
In-Reply-To: <1482299071-22637-1-git-send-email-pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Wed, Dec 21, 2016 at 11:14:31AM +0530, Pankaj Dubey wrote:
> From: Smitha T Murthy <smitha.t-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>
> For some IPs, there may be virtual child devices created and for them its
> necessary to set the dma_ops if it's using reserved memory else it will call
> the dummy dma_ops during buffer operations for the child devices which will
> lead to memory mapping failure.
>
> Signed-off-by: Smitha T Murthy <smitha.t-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Pankaj Dubey <pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> drivers/of/of_reserved_mem.c | 4 ++++
> 1 file changed, 4 insertions(+)
Applied, thanks.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2 4/5] PCI: exynos: support the using PHY generic framework
From: Jingoo Han @ 2017-01-04 19:56 UTC (permalink / raw)
To: 'Jaehoon Chung', linux-pci
Cc: devicetree, linux-kernel, linux-samsung-soc, bhelgaas, robh+dt,
mark.rutland, kgene, krzk, kishon, vivek.gautam, pankaj.dubey,
alim.akhtar, cpgs
In-Reply-To: <20170104123435.30740-5-jh80.chung@samsung.com>
On Wednesday, January 4, 2017 7:35 AM, Jaehoon Chung wrote:
>
> This patch is for using PHY generic framework.
> To maintain backward compatibility, check whether phy is supported or
> not with 'using_phy'.
>
> And if someone use the old dt-file, display the "deprecated" message.
> But it's still working fine with it.
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
It looks good!
Acked-by: Jingoo Han <jingoohan1@gmail.com>
Best regards,
Jingoo Han
> ---
> Changelog on V2:
> - This patch is split from previous PATCH[1/4]
> - Maintain the backward compatibility
> - Adds 'using_phy' for cheching whether phy framework is used or not
> - Adds 'DEPRECATED' message for old dt-binding way
>
> drivers/pci/host/pci-exynos.c | 61 +++++++++++++++++++++++++++++++++++---
> -----
> 1 file changed, 50 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
> index feed0fd..34f2eed 100644
> --- a/drivers/pci/host/pci-exynos.c
> +++ b/drivers/pci/host/pci-exynos.c
> @@ -21,6 +21,7 @@
> #include <linux/of_gpio.h>
> #include <linux/pci.h>
> #include <linux/platform_device.h>
> +#include <linux/phy/phy.h>
> #include <linux/resource.h>
> #include <linux/signal.h>
> #include <linux/types.h>
> @@ -110,6 +111,10 @@ struct exynos_pcie {
> struct exynos_pcie_clk_res *clk_res;
> const struct exynos_pcie_ops *ops;
> int reset_gpio;
> +
> + /* For Generic PHY Framework */
> + bool using_phy;
> + struct phy *phy;
> };
>
> struct exynos_pcie_ops {
> @@ -135,6 +140,10 @@ static int exynos5440_pcie_get_mem_resources(struct
> platform_device *pdev,
> if (IS_ERR(ep->mem_res->elbi_base))
> return PTR_ERR(ep->mem_res->elbi_base);
>
> + /* If using the PHY framework, doesn't need to get other resource
> */
> + if (ep->using_phy)
> + return 0;
> +
> res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> ep->mem_res->phy_base = devm_ioremap_resource(dev, res);
> if (IS_ERR(ep->mem_res->phy_base))
> @@ -396,17 +405,28 @@ static int exynos_pcie_establish_link(struct
> exynos_pcie *exynos_pcie)
> }
>
> exynos_pcie_assert_core_reset(exynos_pcie);
> - exynos_pcie_assert_phy_reset(exynos_pcie);
> - exynos_pcie_deassert_phy_reset(exynos_pcie);
> - exynos_pcie_power_on_phy(exynos_pcie);
> - exynos_pcie_init_phy(exynos_pcie);
> -
> - /* pulse for common reset */
> - exynos_pcie_writel(exynos_pcie->mem_res->block_base, 1,
> - PCIE_PHY_COMMON_RESET);
> - udelay(500);
> - exynos_pcie_writel(exynos_pcie->mem_res->block_base, 0,
> - PCIE_PHY_COMMON_RESET);
> +
> + if (exynos_pcie->using_phy) {
> + phy_reset(exynos_pcie->phy);
> +
> + exynos_pcie_writel(exynos_pcie->mem_res->elbi_base, 1,
> + PCIE_PWR_RESET);
> +
> + phy_power_on(exynos_pcie->phy);
> + phy_init(exynos_pcie->phy);
> + } else {
> + exynos_pcie_assert_phy_reset(exynos_pcie);
> + exynos_pcie_deassert_phy_reset(exynos_pcie);
> + exynos_pcie_power_on_phy(exynos_pcie);
> + exynos_pcie_init_phy(exynos_pcie);
> +
> + /* pulse for common reset */
> + exynos_pcie_writel(exynos_pcie->mem_res->block_base, 1,
> + PCIE_PHY_COMMON_RESET);
> + udelay(500);
> + exynos_pcie_writel(exynos_pcie->mem_res->block_base, 0,
> + PCIE_PHY_COMMON_RESET);
> + }
>
> exynos_pcie_deassert_core_reset(exynos_pcie);
> dw_pcie_setup_rc(pp);
> @@ -420,6 +440,11 @@ static int exynos_pcie_establish_link(struct
> exynos_pcie *exynos_pcie)
> if (!dw_pcie_wait_for_link(pp))
> return 0;
>
> + if (exynos_pcie->using_phy) {
> + phy_power_off(exynos_pcie->phy);
> + return -ETIMEDOUT;
> + }
> +
> while (exynos_pcie_readl(exynos_pcie->mem_res->phy_base,
> PCIE_PHY_PLL_LOCKED) == 0) {
> val = exynos_pcie_readl(exynos_pcie->mem_res->block_base,
> @@ -633,6 +658,17 @@ static int __init exynos_pcie_probe(struct
> platform_device *pdev)
>
> exynos_pcie->reset_gpio = of_get_named_gpio(np, "reset-gpio", 0);
>
> + /* Assume that controller doesn't use the PHY framework */
> + exynos_pcie->using_phy = false;
> +
> + exynos_pcie->phy = devm_of_phy_get(dev, np, NULL);
> + if (IS_ERR(exynos_pcie->phy)) {
> + if (PTR_ERR(exynos_pcie->phy) == -EPROBE_DEFER)
> + return PTR_ERR(exynos_pcie->phy);
> + dev_warn(dev, "Use the 'phy' property. Current DT of pci-
> exynos was deprecated!!\n");
> + } else
> + exynos_pcie->using_phy = true;
> +
> if (exynos_pcie->ops && exynos_pcie->ops->get_mem_resources) {
> ret = exynos_pcie->ops->get_mem_resources(pdev, exynos_pcie);
> if (ret)
> @@ -657,6 +693,9 @@ static int __init exynos_pcie_probe(struct
> platform_device *pdev)
> return 0;
>
> fail_probe:
> + if (exynos_pcie->using_phy)
> + phy_exit(exynos_pcie->phy);
> +
> if (exynos_pcie->ops && exynos_pcie->ops->deinit_clk_resources)
> exynos_pcie->ops->deinit_clk_resources(exynos_pcie);
> return ret;
> --
> 2.10.2
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: document common IEEE 802.11 frequency properties
From: Arend Van Spriel @ 2017-01-04 19:53 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: Rob Herring,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Martin Blumenstingl, Felix Fietkau, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rafał Miłecki
In-Reply-To: <CACna6rxx-8499ZQKekdORF0UWQQazwGu2On1aq-fwA4oCX7pgw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 4-1-2017 15:53, Rafał Miłecki wrote:
> On 4 January 2017 at 15:32, Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
>> Rafał Miłecki <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>
>>> On 3 January 2017 at 20:55, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>>> On Wed, Dec 28, 2016 at 04:59:54PM +0100, Rafał Miłecki wrote:
>>>>> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>>>>
>>>>> This new file should be used for properties handled at higher level and
>>>>> so usable with all drivers.
>>>>
>>>> Why is this needed? Where would this data normally come from?
>>>
>>> Vendors limit choice of channels at their web user interface level. I
>>> want to do better and report proper channels directly at kernel level
>>> instead of masking them in every possible configuration tool.
>>
>> Why do vendors limit the channels? Is it because of a hardware
>> limitation (antenna does not support, or not calibrated, for a certain
>> band etc) or something else?
>
> Please review & comment on the latest version, currently V5:
> https://patchwork.kernel.org/patch/9495795/
> "This can be used to specify extra hardware limitations caused by e.g.
> used antennas or power amplifiers."
Just to be clear, it is does not need to be a hardware limitation, but
simply a way to assure that multiple wlan radios are not interfering
with each other and crank up the total bandwidth that vendors can put on
their box.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH V6 1/3] dt-bindings: document common IEEE 802.11 frequency limit property
From: Rob Herring @ 2017-01-04 19:46 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Johannes Berg, linux-wireless, Martin Blumenstingl, Felix Fietkau,
Arend van Spriel, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rafał Miłecki
In-Reply-To: <20170104175832.25996-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Jan 4, 2017 at 11:58 AM, Rafał Miłecki <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> This new file should be used for properties that apply to all wireless
> devices.
>
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> ---
> V2: Switch to a single ieee80211-freq-limit property that allows specifying
> *multiple* ranges. This resolves problem with more complex rules as pointed
> by Felx.
> Make description implementation agnostic as pointed by Arend.
> Rename node to wifi as suggested by Martin.
> V3: Use more real-life frequencies in the example.
> V5: Describe hardware design as possible use for this property
> V6: Even better property description, thanks Rob for your help!
> ---
> .../devicetree/bindings/net/wireless/ieee80211.txt | 24 ++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/ieee80211.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v4 2/5] mfd: lm3533: Support initialization from Device Tree
From: Bjorn Andersson @ 2017-01-04 19:26 UTC (permalink / raw)
To: Lee Jones
Cc: Rob Herring, Mark Rutland, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Richard Purdie,
Jacek Anaszewski, Pavel Machek, Jingoo Han, devicetree,
linux-kernel, linux-iio, linux-leds, Bjorn Andersson
In-Reply-To: <20170104115424.GH27589@dell>
On Wed 04 Jan 03:54 PST 2017, Lee Jones wrote:
> On Mon, 26 Dec 2016, Bjorn Andersson wrote:
>
> > From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> >
> > Implement support for initialization of the lm3533 driver core and
> > probing child devices from Device Tree.
> >
[..]
> > @@ -512,6 +514,11 @@ static int lm3533_device_init(struct lm3533 *lm3533)
> > lm3533_device_bl_init(lm3533);
> > lm3533_device_led_init(lm3533);
> >
> > + if (lm3533->dev->of_node) {
> > + of_platform_populate(lm3533->dev->of_node, NULL, NULL,
> > + lm3533->dev);
> > + }
>
> I think it's save to call of_platform_populate(), even if !of_node.
> It will just fail and return an error code, which you are ignoring
> anyway.
>
I thought so too, but that's apparently how you trigger probing children
of the root node. So we're stuck with a conditional.
[..]
> > static int lm3533_i2c_probe(struct i2c_client *i2c,
> > const struct i2c_device_id *id)
> > {
[..]
> >
> > + if (i2c->dev.of_node) {
>
> I'd prefer this check to be placed in lm3533_pdata_from_of_node().
>
> Just return silently if !dev->of_node.
>
I agree, will update this.
> > + ret = lm3533_pdata_from_of_node(lm3533->dev);
> > + if (ret < 0)
> > + return ret;
> > + }
> > +
> > return lm3533_device_init(lm3533);
> > }
> >
Regards,
Bjorn
^ permalink raw reply
* Applied "spi: bcm-qspi: Enable the driver on BMIPS_GENERIC" to the spi tree
From: Mark Brown @ 2017-01-04 18:37 UTC (permalink / raw)
To: Jaedon Shin; +Cc: Florian Fainelli, Mark Brown, Ralf Baechle
In-Reply-To: <20161230063001.944-2-jaedon.shin@gmail.com>
The patch
spi: bcm-qspi: Enable the driver on BMIPS_GENERIC
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 279e4af7b4bebc6a5bf2d0e5b3209f3dcea94a19 Mon Sep 17 00:00:00 2001
From: Jaedon Shin <jaedon.shin@gmail.com>
Date: Fri, 30 Dec 2016 15:30:00 +0900
Subject: [PATCH] spi: bcm-qspi: Enable the driver on BMIPS_GENERIC
The Broadcom BCM7XXX ARM and MIPS based SoCs share a similar hardware
block for SPI.
Signed-off-by: Jaedon Shin <jaedon.shin@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index ec4aa252d6e8..c982a01022ba 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -162,7 +162,8 @@ config SPI_BCM63XX_HSSPI
config SPI_BCM_QSPI
tristate "Broadcom BSPI and MSPI controller support"
- depends on ARCH_BRCMSTB || ARCH_BCM || ARCH_BCM_IPROC || COMPILE_TEST
+ depends on ARCH_BRCMSTB || ARCH_BCM || ARCH_BCM_IPROC || \
+ BMIPS_GENERIC || COMPILE_TEST
default ARCH_BCM_IPROC
help
Enables support for the Broadcom SPI flash and MSPI controller.
--
2.11.0
^ permalink raw reply related
* Re: [PATCH V2 5/5] ARM: dts: exynos5440: support the phy-pcie node for pcie
From: Jingoo Han @ 2017-01-04 18:02 UTC (permalink / raw)
To: 'Krzysztof Kozlowski', 'Jaehoon Chung'
Cc: linux-pci, devicetree, linux-kernel, linux-samsung-soc, bhelgaas,
robh+dt, mark.rutland, kgene, kishon, vivek.gautam, pankaj.dubey,
alim.akhtar, cpgs
In-Reply-To: <20170104175822.5zedyszx2phiehuv@kozik-lap>
On Wednesday, January 4, 2017 12:58 PM, Krzysztof Kozlowski wrote:
>
> On Wed, Jan 04, 2017 at 09:34:35PM +0900, Jaehoon Chung wrote:
> > Add phy-pcie node for using Exynos5440 pcie.
> > And use the reg-names as "elbi" and "config".
>
> 'and' is only for joining in compound sentences, don't start with it.
>
> > Because the getting configuratioin space address from ranges is old way.
>
> Spell-check please.
>
> > It also is helpful to distinguish more clearly.
>
> Distinguish what? Please work on the commit msg, I am not picking
> >
> > Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> > ---
> > Changelog on V2:
> > - Removes the child-node
> > - Fixes the typo
> > - Removes the unnecessary comments
> >
> > arch/arm/boot/dts/exynos5440.dtsi | 34 ++++++++++++++++++++++----------
> --
> > 1 file changed, 22 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/exynos5440.dtsi
> b/arch/arm/boot/dts/exynos5440.dtsi
> > index 2a2e570..feb074d 100644
> > --- a/arch/arm/boot/dts/exynos5440.dtsi
> > +++ b/arch/arm/boot/dts/exynos5440.dtsi
> > @@ -290,11 +290,22 @@
> > clock-names = "usbhost";
> > };
> >
> > + pcie_phy0: pcie-phy@270000 {
> > + #phy-cells = <0>;
> > + compatible = "samsung,exynos5440-pcie-phy";
> > + reg = <0x270000 0x1000>, <0x271000 0x40>;
> > + };
> > +
> > + pcie_phy1: pcie-phy@272000 {
> > + #phy-cells = <0>;
> > + compatible = "samsung,exynos5440-pcie-phy";
> > + reg = <0x272000 0x1000>, <0x271040 0x40>;
> > + };
> > +
> > pcie_0: pcie@290000 {
> > compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> > - reg = <0x290000 0x1000
> > - 0x270000 0x1000
> > - 0x271000 0x40>;
> > + reg = <0x290000 0x1000>, <0x40000000 0x1000>;
> > + reg-names = "elbi", "config";
> > interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
> > <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>,
> > <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
> > @@ -303,9 +314,9 @@
> > #address-cells = <3>;
> > #size-cells = <2>;
> > device_type = "pci";
> > - ranges = <0x00000800 0 0x40000000 0x40000000 0 0x00001000
> /* configuration space */
> > - 0x81000000 0 0 0x40001000 0 0x00010000 /*
> downstream I/O */
> > - 0x82000000 0 0x40011000 0x40011000 0 0x1ffef000>; /*
> non-prefetchable memory */
> > + phys = <&pcie_phy0>;
> > + ranges = <0x81000000 0 0 0x40001000 0 0x00010000
> > + 0x82000000 0 0x40011000 0x40011000 0 0x1ffef000>;
>
> I think the comments were useful. You can leave them.
>
> > #interrupt-cells = <1>;
> > interrupt-map-mask = <0 0 0 0>;
> > interrupt-map = <0x0 0 &gic 53>;
> > @@ -315,9 +326,8 @@
> >
> > pcie_1: pcie@2a0000 {
> > compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> > - reg = <0x2a0000 0x1000
> > - 0x272000 0x1000
> > - 0x271040 0x40>;
> > + reg = <0x2a0000 0x1000>, <0x60000000 0x1000>;
> > + reg-names = "elbi", "config";
> > interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>,
> > <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
> > <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
> > @@ -326,9 +336,9 @@
> > #address-cells = <3>;
> > #size-cells = <2>;
> > device_type = "pci";
> > - ranges = <0x00000800 0 0x60000000 0x60000000 0 0x00001000
> /* configuration space */
> > - 0x81000000 0 0 0x60001000 0 0x00010000 /*
> downstream I/O */
> > - 0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>; /*
> non-prefetchable memory */
> > + phys = <&pcie_phy1>;
> > + ranges = <0x81000000 0 0 0x60001000 0 0x00010000
> > + 0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>;
>
> I think the comments were useful. You can leave them.
I think so, too.
Please leave the comments
Best regards,
Jingoo Han
>
> This looks like depending on the changes in the driver, so I will need a
> tag or stable branch from PCIe maintainers.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* [PATCH V6 4/3] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits
From: Rafał Miłecki @ 2017-01-04 17:58 UTC (permalink / raw)
To: Johannes Berg, linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Rafał Miłecki
In-Reply-To: <20170104175832.25996-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
There are some devices (e.g. Netgear R8000 home router) with one chipset
model used for different radios, some of them limited to subbands. NVRAM
entries don't contain any extra info on such limitations and firmware
reports full list of channels to us. We need to store extra limitation
info in DT to support such devices properly.
Now there is a cfg80211 helper for reading such info use it in brcmfmac.
This patch adds check for channel being disabled with orig_flags which
is how this wiphy helper and wiphy_register work.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
This patch should probably go through wireless-driver-next which is why
it got weird number 4/3. I'm sending it just as a proof of concept.
It was succesfully tested on SmartRG SR400ac with BCM43602.
V4: Respect IEEE80211_CHAN_DISABLED in orig_flags
V5: Update commit message
V6: Call wiphy_read_of_freq_limits after brcmf_setup_wiphybands to make it work
with helper setting "flags" instead of "orig_flags".
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index ccae3bb..a008ba5 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -5886,6 +5886,9 @@ static int brcmf_construct_chaninfo(struct brcmf_cfg80211_info *cfg,
band->band);
channel[index].hw_value = ch.control_ch_num;
+ if (channel->orig_flags & IEEE80211_CHAN_DISABLED)
+ continue;
+
/* assuming the chanspecs order is HT20,
* HT40 upper, HT40 lower, and VHT80.
*/
@@ -6478,7 +6481,11 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, struct brcmf_if *ifp)
}
}
err = brcmf_setup_wiphybands(wiphy);
- return err;
+ if (err)
+ return err;
+ wiphy_read_of_freq_limits(wiphy);
+
+ return 0;
}
static s32 brcmf_config_dongle(struct brcmf_cfg80211_info *cfg)
--
2.10.1
^ permalink raw reply related
* [PATCH V6 3/3] cfg80211: support ieee80211-freq-limit DT property
From: Rafał Miłecki @ 2017-01-04 17:58 UTC (permalink / raw)
To: Johannes Berg, linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Rafał Miłecki
In-Reply-To: <20170104175832.25996-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
This patch adds a helper for reading that new property and applying
limitations of supported channels specified this way.
It is used with devices that normally support a wide wireless band but
in a given config are limited to some part of it (usually due to board
design). For example a dual-band chipset may be able to support one band
only because of used antennas.
It's also common that tri-band routers have separated radios for lower
and higher part of 5 GHz band and it may be impossible to say which is
which without a DT info.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
V2: Put main code in core.c as it isn't strictly part of regulatory - pointed
by Arend.
Update to support ieee80211-freq-limit (new property).
V3: Introduce separated wiphy_read_of_freq_limits function.
Add extra sanity checks for DT data.
Move code back to reg.c as suggested by Johannes.
V4: Move code to of.c
Use one helper called at init time (no runtime hooks)
Modify orig_flags
V5: Make wiphy_read_of_freq_limits return void as there isn't much point of
handling errors.
V6: Set IEEE80211_CHAN_DISABLED in "flags" instead of "orig_flags" as they will
be copied during wiphy_register. Also improve description & note that helper
has to be called before wiphy_register.
---
include/net/cfg80211.h | 28 ++++++++++
net/wireless/Makefile | 1 +
net/wireless/of.c | 138 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 167 insertions(+)
create mode 100644 net/wireless/of.c
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index ca2ac1c..30841a9 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -311,6 +311,34 @@ struct ieee80211_supported_band {
struct ieee80211_sta_vht_cap vht_cap;
};
+/**
+ * wiphy_read_of_freq_limits - read frequency limits from device tree
+ *
+ * @wiphy: the wireless device to get extra limits for
+ *
+ * Some devices may have extra limitations specified in DT. This may be useful
+ * for chipsets that normally support more bands but are limited due to board
+ * design (e.g. by antennas or external power amplifier).
+ *
+ * This function reads info from DT and uses it to *modify* channels (disable
+ * unavailable ones). It's usually a *bad* idea to use it in drivers with
+ * shared channel data as DT limitations are device specific. You should make
+ * sure to call it only if channels in wiphy are copied and can be modified
+ * without affecting other devices.
+ *
+ * As this function access device node it has to be called after set_wiphy_dev.
+ * It also modifies channels so they have to be set first.
+ * If using this helper, call it before wiphy_register.
+ */
+#ifdef CONFIG_OF
+void wiphy_read_of_freq_limits(struct wiphy *wiphy);
+#else /* CONFIG_OF */
+static inline void wiphy_read_of_freq_limits(struct wiphy *wiphy)
+{
+}
+#endif /* !CONFIG_OF */
+
+
/*
* Wireless hardware/device configuration structures and methods
*/
diff --git a/net/wireless/Makefile b/net/wireless/Makefile
index 4c9e39f..95b4c09 100644
--- a/net/wireless/Makefile
+++ b/net/wireless/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_WEXT_PRIV) += wext-priv.o
cfg80211-y += core.o sysfs.o radiotap.o util.o reg.o scan.o nl80211.o
cfg80211-y += mlme.o ibss.o sme.o chan.o ethtool.o mesh.o ap.o trace.o ocb.o
+cfg80211-$(CONFIG_OF) += of.o
cfg80211-$(CONFIG_CFG80211_DEBUGFS) += debugfs.o
cfg80211-$(CONFIG_CFG80211_WEXT) += wext-compat.o wext-sme.o
cfg80211-$(CONFIG_CFG80211_INTERNAL_REGDB) += regdb.o
diff --git a/net/wireless/of.c b/net/wireless/of.c
new file mode 100644
index 0000000..de221f0
--- /dev/null
+++ b/net/wireless/of.c
@@ -0,0 +1,138 @@
+/*
+ * Copyright (C) 2017 Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include <linux/of.h>
+#include <net/cfg80211.h>
+#include "core.h"
+
+static bool wiphy_freq_limits_valid_chan(struct wiphy *wiphy,
+ struct ieee80211_freq_range *freq_limits,
+ unsigned int n_freq_limits,
+ struct ieee80211_channel *chan)
+{
+ u32 bw = MHZ_TO_KHZ(20);
+ int i;
+
+ for (i = 0; i < n_freq_limits; i++) {
+ struct ieee80211_freq_range *limit = &freq_limits[i];
+
+ if (cfg80211_does_bw_fit_range(limit,
+ MHZ_TO_KHZ(chan->center_freq),
+ bw))
+ return true;
+ }
+
+ return false;
+}
+
+static void wiphy_freq_limits_apply(struct wiphy *wiphy,
+ struct ieee80211_freq_range *freq_limits,
+ unsigned int n_freq_limits)
+{
+ enum nl80211_band band;
+ int i;
+
+ if (WARN_ON(!n_freq_limits))
+ return;
+
+ for (band = 0; band < NUM_NL80211_BANDS; band++) {
+ struct ieee80211_supported_band *sband = wiphy->bands[band];
+
+ if (!sband)
+ continue;
+
+ for (i = 0; i < sband->n_channels; i++) {
+ struct ieee80211_channel *chan = &sband->channels[i];
+
+ if (chan->flags & IEEE80211_CHAN_DISABLED)
+ continue;
+
+ if (!wiphy_freq_limits_valid_chan(wiphy, freq_limits,
+ n_freq_limits,
+ chan)) {
+ pr_debug("Disabling freq %d MHz as it's out of OF limits\n",
+ chan->center_freq);
+ chan->flags |= IEEE80211_CHAN_DISABLED;
+ }
+ }
+ }
+}
+
+void wiphy_read_of_freq_limits(struct wiphy *wiphy)
+{
+ struct device *dev = wiphy_dev(wiphy);
+ struct device_node *np;
+ struct property *prop;
+ struct ieee80211_freq_range *freq_limits;
+ unsigned int n_freq_limits;
+ const __be32 *p;
+ int len, i;
+ int err = 0;
+
+ if (!dev)
+ return;
+ np = dev_of_node(dev);
+ if (!np)
+ return;
+
+ prop = of_find_property(np, "ieee80211-freq-limit", &len);
+ if (!prop)
+ return;
+
+ if (!len || len % sizeof(u32) || len / sizeof(u32) % 2) {
+ dev_err(dev, "ieee80211-freq-limit wrong format");
+ return;
+ }
+ n_freq_limits = len / sizeof(u32) / 2;
+
+ freq_limits = kcalloc(n_freq_limits, sizeof(*freq_limits), GFP_KERNEL);
+ if (!freq_limits) {
+ err = -ENOMEM;
+ goto out_kfree;
+ }
+
+ p = NULL;
+ for (i = 0; i < n_freq_limits; i++) {
+ struct ieee80211_freq_range *limit = &freq_limits[i];
+
+ p = of_prop_next_u32(prop, p, &limit->start_freq_khz);
+ if (!p) {
+ err = -EINVAL;
+ goto out_kfree;
+ }
+
+ p = of_prop_next_u32(prop, p, &limit->end_freq_khz);
+ if (!p) {
+ err = -EINVAL;
+ goto out_kfree;
+ }
+
+ if (!limit->start_freq_khz ||
+ !limit->end_freq_khz ||
+ limit->start_freq_khz >= limit->end_freq_khz) {
+ err = -EINVAL;
+ goto out_kfree;
+ }
+ }
+
+ wiphy_freq_limits_apply(wiphy, freq_limits, n_freq_limits);
+
+out_kfree:
+ kfree(freq_limits);
+ if (err)
+ dev_err(dev, "Failed to get limits: %d\n", err);
+}
+EXPORT_SYMBOL(wiphy_read_of_freq_limits);
--
2.10.1
^ permalink raw reply related
* [PATCH V6 2/3] cfg80211: move function checking range fit to util.c
From: Rafał Miłecki @ 2017-01-04 17:58 UTC (permalink / raw)
To: Johannes Berg, linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Rafał Miłecki
In-Reply-To: <20170104175832.25996-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
It is needed for another cfg80211 helper that will be out of reg.c so
move it to common util.c file and make it non-static.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
V5: Add this patch as suggested by Arend
---
net/wireless/core.h | 3 +++
net/wireless/reg.c | 27 +++++++--------------------
net/wireless/util.c | 15 +++++++++++++++
3 files changed, 25 insertions(+), 20 deletions(-)
diff --git a/net/wireless/core.h b/net/wireless/core.h
index af6e023..bc8ba6e 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -430,6 +430,9 @@ int cfg80211_change_iface(struct cfg80211_registered_device *rdev,
void cfg80211_process_rdev_events(struct cfg80211_registered_device *rdev);
void cfg80211_process_wdev_events(struct wireless_dev *wdev);
+bool cfg80211_does_bw_fit_range(const struct ieee80211_freq_range *freq_range,
+ u32 center_freq_khz, u32 bw_khz);
+
/**
* cfg80211_chandef_dfs_usable - checks if chandef is DFS usable
* @wiphy: the wiphy to validate against
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..753efcd 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -748,21 +748,6 @@ static bool is_valid_rd(const struct ieee80211_regdomain *rd)
return true;
}
-static bool reg_does_bw_fit(const struct ieee80211_freq_range *freq_range,
- u32 center_freq_khz, u32 bw_khz)
-{
- u32 start_freq_khz, end_freq_khz;
-
- start_freq_khz = center_freq_khz - (bw_khz/2);
- end_freq_khz = center_freq_khz + (bw_khz/2);
-
- if (start_freq_khz >= freq_range->start_freq_khz &&
- end_freq_khz <= freq_range->end_freq_khz)
- return true;
-
- return false;
-}
-
/**
* freq_in_rule_band - tells us if a frequency is in a frequency band
* @freq_range: frequency rule we want to query
@@ -1070,7 +1055,7 @@ freq_reg_info_regd(u32 center_freq,
if (!band_rule_found)
band_rule_found = freq_in_rule_band(fr, center_freq);
- bw_fits = reg_does_bw_fit(fr, center_freq, bw);
+ bw_fits = cfg80211_does_bw_fit_range(fr, center_freq, bw);
if (band_rule_found && bw_fits)
return rr;
@@ -1138,11 +1123,13 @@ static uint32_t reg_rule_to_chan_bw_flags(const struct ieee80211_regdomain *regd
max_bandwidth_khz = reg_get_max_bandwidth(regd, reg_rule);
/* If we get a reg_rule we can assume that at least 5Mhz fit */
- if (!reg_does_bw_fit(freq_range, MHZ_TO_KHZ(chan->center_freq),
- MHZ_TO_KHZ(10)))
+ if (!cfg80211_does_bw_fit_range(freq_range,
+ MHZ_TO_KHZ(chan->center_freq),
+ MHZ_TO_KHZ(10)))
bw_flags |= IEEE80211_CHAN_NO_10MHZ;
- if (!reg_does_bw_fit(freq_range, MHZ_TO_KHZ(chan->center_freq),
- MHZ_TO_KHZ(20)))
+ if (!cfg80211_does_bw_fit_range(freq_range,
+ MHZ_TO_KHZ(chan->center_freq),
+ MHZ_TO_KHZ(20)))
bw_flags |= IEEE80211_CHAN_NO_20MHZ;
if (max_bandwidth_khz < MHZ_TO_KHZ(10))
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 2cf7df8..62dc214 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1847,6 +1847,21 @@ void cfg80211_free_nan_func(struct cfg80211_nan_func *f)
}
EXPORT_SYMBOL(cfg80211_free_nan_func);
+bool cfg80211_does_bw_fit_range(const struct ieee80211_freq_range *freq_range,
+ u32 center_freq_khz, u32 bw_khz)
+{
+ u32 start_freq_khz, end_freq_khz;
+
+ start_freq_khz = center_freq_khz - (bw_khz / 2);
+ end_freq_khz = center_freq_khz + (bw_khz / 2);
+
+ if (start_freq_khz >= freq_range->start_freq_khz &&
+ end_freq_khz <= freq_range->end_freq_khz)
+ return true;
+
+ return false;
+}
+
/* See IEEE 802.1H for LLC/SNAP encapsulation/decapsulation */
/* Ethernet-II snap header (RFC1042 for most EtherTypes) */
const unsigned char rfc1042_header[] __aligned(2) =
--
2.10.1
^ permalink raw reply related
* [PATCH V6 1/3] dt-bindings: document common IEEE 802.11 frequency limit property
From: Rafał Miłecki @ 2017-01-04 17:58 UTC (permalink / raw)
To: Johannes Berg, linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Rafał Miłecki
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
This new file should be used for properties that apply to all wireless
devices.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
V2: Switch to a single ieee80211-freq-limit property that allows specifying
*multiple* ranges. This resolves problem with more complex rules as pointed
by Felx.
Make description implementation agnostic as pointed by Arend.
Rename node to wifi as suggested by Martin.
V3: Use more real-life frequencies in the example.
V5: Describe hardware design as possible use for this property
V6: Even better property description, thanks Rob for your help!
---
.../devicetree/bindings/net/wireless/ieee80211.txt | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/wireless/ieee80211.txt
diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.txt b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
new file mode 100644
index 0000000..f6442b1
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
@@ -0,0 +1,24 @@
+Common IEEE 802.11 properties
+
+This provides documentation of common properties that are valid for all wireless
+devices.
+
+Optional properties:
+ - ieee80211-freq-limit : list of supported frequency ranges in KHz. This can be
+ used for devices that in a given config support less channels than
+ normally. It may happen chipset supports a wide wireless band but it is
+ limited to some part of it due to used antennas or power amplifier.
+ An example case for this can be tri-band wireless router with two
+ identical chipsets used for two different 5 GHz subbands. Using them
+ incorrectly could not work or decrease performance noticeably.
+
+Example:
+
+pcie@0,0 {
+ reg = <0x0000 0 0 0 0>;
+ wifi@0,0 {
+ reg = <0x0000 0 0 0 0>;
+ ieee80211-freq-limit = <2402000 2482000>,
+ <5170000 5250000>;
+ };
+};
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH V2 5/5] ARM: dts: exynos5440: support the phy-pcie node for pcie
From: Krzysztof Kozlowski @ 2017-01-04 17:58 UTC (permalink / raw)
To: Jaehoon Chung
Cc: linux-pci, devicetree, linux-kernel, linux-samsung-soc, bhelgaas,
robh+dt, mark.rutland, kgene, krzk, kishon, jingoohan1,
vivek.gautam, pankaj.dubey, alim.akhtar, cpgs
In-Reply-To: <20170104123435.30740-6-jh80.chung@samsung.com>
On Wed, Jan 04, 2017 at 09:34:35PM +0900, Jaehoon Chung wrote:
> Add phy-pcie node for using Exynos5440 pcie.
> And use the reg-names as "elbi" and "config".
'and' is only for joining in compound sentences, don't start with it.
> Because the getting configuratioin space address from ranges is old way.
Spell-check please.
> It also is helpful to distinguish more clearly.
Distinguish what? Please work on the commit msg, I am not picking
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> ---
> Changelog on V2:
> - Removes the child-node
> - Fixes the typo
> - Removes the unnecessary comments
>
> arch/arm/boot/dts/exynos5440.dtsi | 34 ++++++++++++++++++++++------------
> 1 file changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
> index 2a2e570..feb074d 100644
> --- a/arch/arm/boot/dts/exynos5440.dtsi
> +++ b/arch/arm/boot/dts/exynos5440.dtsi
> @@ -290,11 +290,22 @@
> clock-names = "usbhost";
> };
>
> + pcie_phy0: pcie-phy@270000 {
> + #phy-cells = <0>;
> + compatible = "samsung,exynos5440-pcie-phy";
> + reg = <0x270000 0x1000>, <0x271000 0x40>;
> + };
> +
> + pcie_phy1: pcie-phy@272000 {
> + #phy-cells = <0>;
> + compatible = "samsung,exynos5440-pcie-phy";
> + reg = <0x272000 0x1000>, <0x271040 0x40>;
> + };
> +
> pcie_0: pcie@290000 {
> compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> - reg = <0x290000 0x1000
> - 0x270000 0x1000
> - 0x271000 0x40>;
> + reg = <0x290000 0x1000>, <0x40000000 0x1000>;
> + reg-names = "elbi", "config";
> interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
> @@ -303,9 +314,9 @@
> #address-cells = <3>;
> #size-cells = <2>;
> device_type = "pci";
> - ranges = <0x00000800 0 0x40000000 0x40000000 0 0x00001000 /* configuration space */
> - 0x81000000 0 0 0x40001000 0 0x00010000 /* downstream I/O */
> - 0x82000000 0 0x40011000 0x40011000 0 0x1ffef000>; /* non-prefetchable memory */
> + phys = <&pcie_phy0>;
> + ranges = <0x81000000 0 0 0x40001000 0 0x00010000
> + 0x82000000 0 0x40011000 0x40011000 0 0x1ffef000>;
I think the comments were useful. You can leave them.
> #interrupt-cells = <1>;
> interrupt-map-mask = <0 0 0 0>;
> interrupt-map = <0x0 0 &gic 53>;
> @@ -315,9 +326,8 @@
>
> pcie_1: pcie@2a0000 {
> compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> - reg = <0x2a0000 0x1000
> - 0x272000 0x1000
> - 0x271040 0x40>;
> + reg = <0x2a0000 0x1000>, <0x60000000 0x1000>;
> + reg-names = "elbi", "config";
> interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
> @@ -326,9 +336,9 @@
> #address-cells = <3>;
> #size-cells = <2>;
> device_type = "pci";
> - ranges = <0x00000800 0 0x60000000 0x60000000 0 0x00001000 /* configuration space */
> - 0x81000000 0 0 0x60001000 0 0x00010000 /* downstream I/O */
> - 0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>; /* non-prefetchable memory */
> + phys = <&pcie_phy1>;
> + ranges = <0x81000000 0 0 0x60001000 0 0x00010000
> + 0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>;
I think the comments were useful. You can leave them.
This looks like depending on the changes in the driver, so I will need a
tag or stable branch from PCIe maintainers.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: Introduce TI IOdelay configuration driver
From: Nishanth Menon @ 2017-01-04 17:57 UTC (permalink / raw)
To: Tony Lindgren, Linus Walleij
Cc: Gary Bisson, Grygorii Strashko, Mark Rutland, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA, Lokesh Vutla
In-Reply-To: <20170102221228.GH9325-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On 01/02/2017 04:12 PM, Tony Lindgren wrote:
[...]
I got the following warnings with kernel-doc:
> $ ./scripts/kernel-doc drivers/pinctrl/ti/pinctrl-ti-iodelay.c>/dev/null
> drivers/pinctrl/ti/pinctrl-ti-iodelay.c:132: warning: Excess struct/union/enum/typedef member 'name' description in 'ti_iodelay_pingroup'
> drivers/pinctrl/ti/pinctrl-ti-iodelay.c:132: warning: Excess struct/union/enum/typedef member 'map' description in 'ti_iodelay_pingroup'
> drivers/pinctrl/ti/pinctrl-ti-iodelay.c:159: warning: Excess struct/union/enum/typedef member 'names' description in 'ti_iodelay_device'
> drivers/pinctrl/ti/pinctrl-ti-iodelay.c:211: warning: No description found for parameter 'cfg'
> drivers/pinctrl/ti/pinctrl-ti-iodelay.c:211: warning: Excess function parameter 'val' description in 'ti_iodelay_pinconf_set'
> drivers/pinctrl/ti/pinctrl-ti-iodelay.c:418: warning: Cannot understand *
> on line 418 - I thought it was a doc line
Marking them below
> diff --git a/drivers/pinctrl/ti/pinctrl-ti-iodelay.c b/drivers/pinctrl/ti/pinctrl-ti-iodelay.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/pinctrl/ti/pinctrl-ti-iodelay.c
[...]
> +/**
> + * struct ti_iodelay_pingroup - Structure that describes one group
> + * @name: Name of the group
^^--> we should drop this
> + * @map: pinctrl map allocated for the group
^^--> we should drop this
> + * @cfg: configuration array for the pin (from dt)
> + * @ncfg: number of configuration values allocated
> + * @config: pinconf "Config" - currently a dummy value
> + */
> +struct ti_iodelay_pingroup {
> + struct ti_iodelay_cfg *cfg;
> + int ncfg;
> + unsigned long config;
> +};
> +
> +/**
> + * struct ti_iodelay_device - Represents information for a iodelay instance
> + * @dev: Device pointer
> + * @phys_base: Physical address base of the iodelay device
> + * @reg_base: Virtual address base of the iodelay device
> + * @regmap: Regmap for this iodelay instance
> + * @pctl: Pinctrl device
> + * @desc: pinctrl descriptor for pctl
> + * @pa: pinctrl pin wise description
> + * @names: names of the pins
^^--> we should drop this
> + * @reg_data: Register definition data for the IODelay instance
> + * @reg_init_conf_values: Initial configuration values.
> + */
> +struct ti_iodelay_device {
> + struct device *dev;
> + unsigned long phys_base;
> + void __iomem *reg_base;
> + struct regmap *regmap;
> +
> + struct pinctrl_dev *pctl;
> + struct pinctrl_desc desc;
> + struct pinctrl_pin_desc *pa;
> +
> + const struct ti_iodelay_reg_data *reg_data;
> + struct ti_iodelay_reg_values reg_init_conf_values;
> +};
> +
[...]
> +/**
> + * ti_iodelay_pinconf_set() - Configure the pin configuration
> + * @iod: iodelay device
> + * @val: Configuration value
^^ --> should be cfg ?
> + *
> + * Update the configuration register as per TRM and lockup once done.
> + * *IMPORTANT NOTE* SoC TRM does recommend doing iodelay programmation only
> + * while in Isolation. But, then, isolation also implies that every pin
> + * on the SoC (including DDR) will be isolated out. The only benefit being
> + * a glitchless configuration, However, the intent of this driver is purely
> + * to support a "glitchy" configuration where applicable.
> + *
> + * Return: 0 in case of success, else appropriate error value
> + */
> +static int ti_iodelay_pinconf_set(struct ti_iodelay_device *iod,
> + struct ti_iodelay_cfg *cfg)
[...]
> +
> +/**
> + *
Could you make this:
* ti_iodelay_node_iterator() - Iterate iodelay node
> + * @pctldev: Pin controller driver
> + * @np: Device node
> + * @pinctrl_spec: Parsed arguments from device tree
> + * @pins: Array of pins in the pin group
> + * @pin_index: Pin index in the pin array
> + * @data: Pin controller driver specific data
> + *
> + */
> +static int ti_iodelay_node_iterator(struct pinctrl_dev *pctldev,
> + struct device_node *np,
> + const struct of_phandle_args *pinctrl_spec,
> + int *pins, int pin_index, void *data)
[...]
Otherwise, the patch looks fine. Thanks for doing this.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox