* Re: [PATCH 3/8] ARM: dts: armada-388-clearfog: Utilize new DSA binding
From: Florian Fainelli @ 2017-01-04 17:27 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Rob Herring, Mark Rutland,
Russell King,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <87shoyeo2j.fsf-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On 01/04/2017 09:23 AM, Gregory CLEMENT wrote:
> Hi Florian,
>
> On lun., janv. 02 2017, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net:
>> dsa: Document new binding"). The legacy binding node is kept included, but is
>> marked disabled.
>>
>
> I tested this patch on mvebu/dt (I needed to reduce the context to apply
> the patch due to the changes made by Russell King on this file). I also
> set the status of the old binding to "disable" (instead of "okay").
Yes, that needs fixing, thanks for mentioning that.
>
> It seems to work with the limited test did:
> ifconfig eth1 up
> udhcpc -i lan1
> iperf -c mylaptop
>
> (same for lan4)
>
> However is there a way to be sure that the new binding is used?
The best way is probably to make sure that your switch device appears
parented to the MDIO bus driver under /sys/class/mdio_bus/*mvmdio*.
Alternatively, if you see a message like:
DSA: switch 0 0 parsed
in your dmesg, that would also be indicative of using the new binding
and corresponding code.
Thanks a lot for trying that out!
--
Florian
--
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 1/8] ARM: dts: armada-370-rd: Utilize new DSA binding
From: Florian Fainelli @ 2017-01-04 17:30 UTC (permalink / raw)
To: Andrew Lunn
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/, Jason Cooper,
Gregory Clement, Sebastian Hesselbarth, Rob Herring, Mark Rutland,
Russell King,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20170103163609.GE32450-g2DYL2Zd6BY@public.gmane.org>
On 01/03/2017 08:36 AM, Andrew Lunn wrote:
>> +
>> + switch: switch@10 {
>> + compatible = "marvell,mv88e6085";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <16>;
>
> Hummm, a device tree question. switch@10, reg = <16>. Is there an
> implicit understanding that the 10 is hex?
Most (if not all?) unit addresses are hexadecimal, which is why this was
chosen here, but I really don't mind changing that.
--
Florian
--
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 3/8] ARM: dts: armada-388-clearfog: Utilize new DSA binding
From: Vivien Didelot @ 2017-01-04 17:38 UTC (permalink / raw)
To: Florian Fainelli, Gregory CLEMENT
Cc: linux-arm-kernel, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Rob Herring, Mark Rutland, Russell King,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <5a40436a-ebad-8a94-c5c5-546ba33ba545@gmail.com>
Hi Florian, All,
Florian Fainelli <f.fainelli@gmail.com> writes:
>> However is there a way to be sure that the new binding is used?
>
> The best way is probably to make sure that your switch device appears
> parented to the MDIO bus driver under /sys/class/mdio_bus/*mvmdio*.
> Alternatively, if you see a message like:
>
> DSA: switch 0 0 parsed
>
> in your dmesg, that would also be indicative of using the new binding
> and corresponding code.
That makes me think that we should either remove, or use different
values for the version described in net/dsa/dsa.c:
char dsa_driver_version[] = "0.1";
Today this is absolutely useless and erroneous.
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH 3/8] ARM: dts: armada-388-clearfog: Utilize new DSA binding
From: Andrew Lunn @ 2017-01-04 17:42 UTC (permalink / raw)
To: Vivien Didelot
Cc: Florian Fainelli, Gregory CLEMENT, linux-arm-kernel, Jason Cooper,
Sebastian Hesselbarth, Rob Herring, Mark Rutland, Russell King,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <87fuky7mjt.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
> That makes me think that we should either remove, or use different
> values for the version described in net/dsa/dsa.c:
>
> char dsa_driver_version[] = "0.1";
>
> Today this is absolutely useless and erroneous.
I think it has been useless for over 9 years.
Feel free to remove it.
Andrew
^ permalink raw reply
* Re: [PATCH 3/8] ARM: dts: armada-388-clearfog: Utilize new DSA binding
From: Vivien Didelot @ 2017-01-04 17:48 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, Gregory CLEMENT, linux-arm-kernel, Jason Cooper,
Sebastian Hesselbarth, Rob Herring, Mark Rutland, Russell King,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20170104174248.GG5517@lunn.ch>
Hi Andrew,
Andrew Lunn <andrew@lunn.ch> writes:
>> That makes me think that we should either remove, or use different
>> values for the version described in net/dsa/dsa.c:
>>
>> char dsa_driver_version[] = "0.1";
>>
>> Today this is absolutely useless and erroneous.
>
> I think it has been useless for over 9 years.
Do we want to get rid of it, or do we want to have a string version per
DSA implementation? (old vs. new bindings).
I don't like the actual way to distinguish between the two (grep'ing
dmesg as Florian shown). Maybe a pr_info in dsa2.c would be enough to
inform about DSA "v2". What do you guys prefer?
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH V2 4/5] PCI: exynos: support the using PHY generic framework
From: Krzysztof Kozlowski @ 2017-01-04 17:50 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-5-jh80.chung@samsung.com>
On Wed, Jan 04, 2017 at 09:34:34PM +0900, 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.
This needs improvements. How about:
"Switch the pci-exynos driver to generic PHY framework. At the same time
backward compatibility is preserved: warning will be printed for old
DTB.
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
>
> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
> ---
> 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 v4 1/4] mtd: spi-nor: add memory controllers for the Aspeed AST2500 SoC
From: Boris Brezillon @ 2017-01-04 17:50 UTC (permalink / raw)
To: Cyrille Pitchen
Cc: Cédric Le Goater, Cyrille Pitchen,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Richard Weinberger,
Marek Vasut, Rob Herring, Joel Stanley, Brian Norris,
David Woodhouse
In-Reply-To: <4c5cf674-06f9-ad6b-05bf-a1d39aaa7ed5-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
Cyrille, Cédric,
On Wed, 4 Jan 2017 15:52:07 +0100
Cyrille Pitchen <cyrille.pitchen-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org> wrote:
> >
> >> Anyway, since the review is done now, on my side I won't ask you to remove
> >> or split the support of the 'Command' mode in a separated patch.
> >> I let you do as you want, if it help you to introduce some part of the
> >> support of this 'Command' mode now even if not completed yet, no problem on
> >> my side :)
> >>
> >> I was just giving you some pieces of advice for the next time if you want
> >> to speed up the review of another patch introducing new features.
> >>
> >> However, I will just ask you one more version handling the dummy cycles
> >> properly as it would help us for the global maintenance of the spi-nor
> >> subsystem. This is the only mandatory modification I ask you, after that I
> >> think it would be ok for me and since Marek has already reviewed your
> >> driver, it would be ready to be merged into the spi-nor tree.
> >
> > Sending a v5 which should address your comments.
> >
> > I have removed the label property and will start a new thread in the
> > topic. Any hints on which binding we could add this label prop ?
> >
>
> Here I will provide just few thoughts about this new DT property. I don't
> pretend this is what should be done. I still think other mtd maintainers
> should be involved to discuss this topic.
>
> First the DT property name "label" sounds good to me: it is consistent with
> "label" DT property used to name mtd partitions. However, I don't think it
> should be documented in jedec,spi-nor.txt but *maybe* in partition.txt as
> the purpose of this new DT property seems very close to the "label"
> property of partition nodes: let's think about some hard-disk device
> (/dev/sda) and its partition devices (/dev/sdaX).
Hm, partition.txt may not be appropriate here. We're not documenting
the MTD partition binding, but the MTD device one. Maybe we should
create mtd.txt and put all generic MTD dev properties here.
>
> Besides, the concept of this memory label is not limited to SPI NOR but
> could also apply to NAND memories or any other MTD handled memories.
Definitely. Actually I think I'll need that for the Atmel NAND
controller driver rework I'm currently working on, to keep mtdparts
parser happy even after changing the NAND device naming scheme.
> Hence the DT property might be handled by drivers/mtd/ofpart.c instead of
> being handled by spi-nor.c or by each SPI NOR memory controller driver.
Actually, that could be done at the mtdcore level in
mtd_set_dev_defaults() [1].
>
> Finally, I guess we should take time to discuss and all agree what should
> be done precisely before introducing a new DT property because one general
> rule with DTB files is that users should be able to update their kernel
> image (zImage, uImage, ...) without changing their DTB: device trees should
> be backward compatible. Hence if we make a wrong choice today, we are
> likely to have to live with it and keep supporting that bad choice.
Rob already acked the patch, so, if all MTD maintainers agree that this
new property is acceptable, we should be fine ;-).
>
> Anyway, maybe you could describe a little bit your use case; what you
> intend to do with this label from you userspace application.
Here is mine: I want the mtdparts parser to work correctly with
existing bootloaders even after changing the NAND device naming scheme
to allow one NAND controller to expose multiple devices.
Current naming scheme: NAND device name is always atmel_nand
New naming sheme: atmel-nand.%d where %d is replaced by the CS line
number the NAND device is connected too.
Also note that it's easier to refer to a flash device by it's purpose
(like System-firmware in Cedric's example) rather than the controller
CS line this device is connected to.
Regards,
Boris
[1]http://code.bulix.org/p019ah-107877
--
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: Krzysztof Kozlowski @ 2017-01-04 17:52 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-3-jh80.chung@samsung.com>
On Wed, Jan 04, 2017 at 09:34:32PM +0900, 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.
I have troubles understanding this. Please, work on the commit message.
For the code itself:
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
... but commit message is really important to understand why/what was
done.
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
* 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
* [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
* [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 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 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
* 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
* 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 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
* 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 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 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] 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] 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 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 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
* [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
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