Re: [PATCH] i2c: exynos5: Preserve high speed master code
On Wed, Feb 17, 2021 at 09:07:47AM +0100, Krzysztof Kozlowski wrote: > On Tue, Feb 16, 2021 at 11:09:33PM +0100, Marten Lindahl wrote: > > > Any reason why not "|= MASTER_ID(i2c->adap.nr)" here instead of more > > > expensive IO read? It's quite important because your current code will > > > bitwise-or old I2C slave address with a new one... This should break > > > during tests with multiple I2C slave devices, shouldn't it? > > > > > > > You are correct. It is better to use the macro instead, and yes, > > safer too. I only have one device that supports high speed i2c, but > > I get your point. It could potentially break. > > > > > On which HW did you test it? > > > > I used an Artpec development board as master and INA230EVM board > > as slave. > > Artpec development board with? What SoC? The ARTPEC-line of SoC:s are Axis Communications own ASICs, in the latest iteration it's a Cortex-53 and includes instances of the exynos5 HSI2C ip. > Best regards, > Krzysztof /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH] arm: remove unneeded semicolon
On Tue, Feb 02, 2021 at 03:02:37AM +0100, Yang Li wrote: > Eliminate the following coccicheck warning: > ./arch/arm/mach-artpec/board-artpec6.c:42:2-3: Unneeded semicolon > > Reported-by: Abaci Robot > Signed-off-by: Yang Li Reviewed-by: Jesper Nilsson > --- > arch/arm/mach-artpec/board-artpec6.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-artpec/board-artpec6.c > b/arch/arm/mach-artpec/board-artpec6.c > index d3cf3e8..c27e7bb 100644 > --- a/arch/arm/mach-artpec/board-artpec6.c > +++ b/arch/arm/mach-artpec/board-artpec6.c > @@ -39,7 +39,7 @@ static void __init artpec6_init_machine(void) >*/ > regmap_write(regmap, ARTPEC6_DMACFG_REGNUM, >ARTPEC6_DMACFG_UARTS_BURST); > - }; > + } > } > > static void artpec6_l2c310_write_sec(unsigned long val, unsigned reg) > -- > 1.8.3.1 > /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH] arm: remove unneeded semicolon in board-artpec6.c
On Tue, Apr 28, 2020 at 08:32:13AM +0200, Jason Yan wrote: > Fix the following coccicheck warning: > > arch/arm/mach-artpec/board-artpec6.c:42:2-3: Unneeded semicolon Acked-by: Jesper Nilsson > Signed-off-by: Jason Yan > --- > arch/arm/mach-artpec/board-artpec6.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-artpec/board-artpec6.c > b/arch/arm/mach-artpec/board-artpec6.c > index d3cf3e8603e8..c27e7bbcd7bc 100644 > --- a/arch/arm/mach-artpec/board-artpec6.c > +++ b/arch/arm/mach-artpec/board-artpec6.c > @@ -39,7 +39,7 @@ static void __init artpec6_init_machine(void) >*/ > regmap_write(regmap, ARTPEC6_DMACFG_REGNUM, >ARTPEC6_DMACFG_UARTS_BURST); > - }; > + } > } > > static void artpec6_l2c310_write_sec(unsigned long val, unsigned reg) > -- > 2.21.1 > /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH -next 27/30] pinctrl: artpec6: use devm_platform_ioremap_resource() to simplify code
On Thu, Oct 17, 2019 at 02:26:37PM +0200, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Signed-off-by: YueHaibing
Acked-by: Jesper Nilsson
> ---
> drivers/pinctrl/pinctrl-artpec6.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-artpec6.c
> b/drivers/pinctrl/pinctrl-artpec6.c
> index e3239cf..986e04a 100644
> --- a/drivers/pinctrl/pinctrl-artpec6.c
> +++ b/drivers/pinctrl/pinctrl-artpec6.c
> @@ -936,7 +936,6 @@ static void artpec6_pmx_reset(struct artpec6_pmx *pmx)
> static int artpec6_pmx_probe(struct platform_device *pdev)
> {
> struct artpec6_pmx *pmx;
> - struct resource *res;
>
> pmx = devm_kzalloc(>dev, sizeof(*pmx), GFP_KERNEL);
> if (!pmx)
> @@ -944,8 +943,7 @@ static int artpec6_pmx_probe(struct platform_device *pdev)
>
> pmx->dev = >dev;
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - pmx->base = devm_ioremap_resource(>dev, res);
> + pmx->base = devm_platform_ioremap_resource(pdev, 0);
>
> if (IS_ERR(pmx->base))
> return PTR_ERR(pmx->base);
> --
> 2.7.4
>
>
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH -next] pinctrl: artpec6: Make two functions static
On Mon, Apr 08, 2019 at 11:01:10AM -0700, Nathan Chancellor wrote: > On Thu, Mar 21, 2019 at 11:09:09PM +0800, Yue Haibing wrote: > > From: YueHaibing > > -void artpec6_pmx_disable(struct pinctrl_dev *pctldev, unsigned int > > function, > > -unsigned int group) > > +static void artpec6_pmx_disable(struct pinctrl_dev *pctldev, > > + unsigned int function, > > + unsigned int group) > > On arm32 allyesconfig: > > drivers/pinctrl/pinctrl-artpec6.c:706:13: error: unused function > 'artpec6_pmx_disable' [-Werror,-Wunused-function] > > This is the second time you've introduced an unused function warning by > making a function static[1], could you please be a little more vigilant > in your clean ups in the future? > > [1]: > https://lore.kernel.org/lkml/20190327050126.12064-1-natechancel...@gmail.com/ > > Linus/Jesper/Lars, should this function just be deleted? I'd be happy to > send a patch doing so if that's the right course of action. Yes, that function is unused and can be dropped. > Thanks, > Nathan /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH -next] pinctrl: artpec6: Make two functions static
On Thu, Mar 21, 2019 at 11:09:09PM +0800, Yue Haibing wrote:
> From: YueHaibing
>
> Fix sparse warnings:
>
> drivers/pinctrl/pinctrl-artpec6.c:691:5: warning:
> symbol 'artpec6_pmx_enable' was not declared. Should it be static?
> drivers/pinctrl/pinctrl-artpec6.c:705:6: warning:
> symbol 'artpec6_pmx_disable' was not declared. Should it be static?
>
> Signed-off-by: YueHaibing
Acked-by: Jesper Nilsson
> ---
> drivers/pinctrl/pinctrl-artpec6.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-artpec6.c
> b/drivers/pinctrl/pinctrl-artpec6.c
> index d89dc43..e836850 100644
> --- a/drivers/pinctrl/pinctrl-artpec6.c
> +++ b/drivers/pinctrl/pinctrl-artpec6.c
> @@ -688,8 +688,9 @@ static void artpec6_pmx_select_func(struct pinctrl_dev
> *pctldev,
> }
> }
>
> -int artpec6_pmx_enable(struct pinctrl_dev *pctldev, unsigned int function,
> -unsigned int group)
> +static int artpec6_pmx_enable(struct pinctrl_dev *pctldev,
> + unsigned int function,
> + unsigned int group)
> {
> struct artpec6_pmx *pmx = pinctrl_dev_get_drvdata(pctldev);
>
> @@ -702,8 +703,9 @@ int artpec6_pmx_enable(struct pinctrl_dev *pctldev,
> unsigned int function,
> return 0;
> }
>
> -void artpec6_pmx_disable(struct pinctrl_dev *pctldev, unsigned int function,
> - unsigned int group)
> +static void artpec6_pmx_disable(struct pinctrl_dev *pctldev,
> + unsigned int function,
> + unsigned int group)
> {
> struct artpec6_pmx *pmx = pinctrl_dev_get_drvdata(pctldev);
>
> --
> 2.7.0
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
[PATCH] PCI: dwc: artpec6: Add reset-gpios for PERST# control
Some devices need an optional external gpio for controlling
the PERST# signal to bring up for example a PCIe switch
after a soft reset.
Without this, some boards (the ARTPEC-6 master devboard)
would not get the PCIe link back after a soft reset.
Signed-off-by: Jesper Nilsson <jesper.nils...@axis.com>
---
.../devicetree/bindings/pci/axis,artpec6-pcie.txt| 4
drivers/pci/dwc/pcie-artpec6.c | 20 +++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pci/axis,artpec6-pcie.txt
b/Documentation/devicetree/bindings/pci/axis,artpec6-pcie.txt
index 979dc7b6cfe8..810bd461e81c 100644
--- a/Documentation/devicetree/bindings/pci/axis,artpec6-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/axis,artpec6-pcie.txt
@@ -21,6 +21,10 @@ and thus inherits all the common properties defined in
designware-pcie.txt.
- axis,syscon-pcie: A phandle pointing to the ARTPEC-6 system controller,
used to enable and control the Synopsys IP.
+Optional properties:
+
+- reset-gpios: GPIO to generate PCIe PERST# assert and deassert signal.
+
Example:
pcie@f805 {
diff --git a/drivers/pci/dwc/pcie-artpec6.c b/drivers/pci/dwc/pcie-artpec6.c
index 93b3df9ed1b5..1eada6d1a381 100644
--- a/drivers/pci/dwc/pcie-artpec6.c
+++ b/drivers/pci/dwc/pcie-artpec6.c
@@ -19,6 +19,8 @@
#include
#include
#include
+#include
+#include
#include "pcie-designware.h"
@@ -35,6 +37,7 @@ struct artpec6_pcie {
void __iomem*phy_base; /* DT phy */
enum artpec_pcie_variants variant;
enum dw_pcie_device_mode mode;
+ struct gpio_desc*reset;
};
struct artpec_pcie_of_data {
@@ -350,6 +353,13 @@ static void artpec6_pcie_deassert_core_reset(struct
artpec6_pcie *artpec6_pcie)
}
artpec6_pcie_writel(artpec6_pcie, PCIECFG, val);
usleep_range(100, 200);
+
+ /* Some boards don't have PCIe reset hardwired, use a GPIO insted. */
+ if (artpec6_pcie->reset) {
+ gpiod_set_value_cansleep(artpec6_pcie->reset, 1);
+ msleep(100);
+ gpiod_set_value_cansleep(artpec6_pcie->reset, 0);
+ }
}
static void artpec6_pcie_enable_interrupts(struct artpec6_pcie *artpec6_pcie)
@@ -513,6 +523,7 @@ static int artpec6_pcie_probe(struct platform_device *pdev)
const struct artpec_pcie_of_data *data;
enum artpec_pcie_variants variant;
enum dw_pcie_device_mode mode;
+ struct device_node *node = dev->of_node;
match = of_match_device(artpec6_pcie_of_match, dev);
if (!match)
@@ -548,11 +559,18 @@ static int artpec6_pcie_probe(struct platform_device
*pdev)
return PTR_ERR(artpec6_pcie->phy_base);
artpec6_pcie->regmap =
- syscon_regmap_lookup_by_phandle(dev->of_node,
+ syscon_regmap_lookup_by_phandle(node,
"axis,syscon-pcie");
if (IS_ERR(artpec6_pcie->regmap))
return PTR_ERR(artpec6_pcie->regmap);
+ artpec6_pcie->reset = devm_gpiod_get_optional(dev, "reset",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(artpec6_pcie->reset)) {
+ dev_err(dev, "Failed to request reset gpio\n");
+ return PTR_ERR(artpec6_pcie->reset);
+ }
+
platform_set_drvdata(pdev, artpec6_pcie);
switch (artpec6_pcie->mode) {
--
2.1.4
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
[PATCH] PCI: dwc: artpec6: Add reset-gpios for PERST# control
Some devices need an optional external gpio for controlling
the PERST# signal to bring up for example a PCIe switch
after a soft reset.
Without this, some boards (the ARTPEC-6 master devboard)
would not get the PCIe link back after a soft reset.
Signed-off-by: Jesper Nilsson
---
.../devicetree/bindings/pci/axis,artpec6-pcie.txt| 4
drivers/pci/dwc/pcie-artpec6.c | 20 +++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pci/axis,artpec6-pcie.txt
b/Documentation/devicetree/bindings/pci/axis,artpec6-pcie.txt
index 979dc7b6cfe8..810bd461e81c 100644
--- a/Documentation/devicetree/bindings/pci/axis,artpec6-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/axis,artpec6-pcie.txt
@@ -21,6 +21,10 @@ and thus inherits all the common properties defined in
designware-pcie.txt.
- axis,syscon-pcie: A phandle pointing to the ARTPEC-6 system controller,
used to enable and control the Synopsys IP.
+Optional properties:
+
+- reset-gpios: GPIO to generate PCIe PERST# assert and deassert signal.
+
Example:
pcie@f805 {
diff --git a/drivers/pci/dwc/pcie-artpec6.c b/drivers/pci/dwc/pcie-artpec6.c
index 93b3df9ed1b5..1eada6d1a381 100644
--- a/drivers/pci/dwc/pcie-artpec6.c
+++ b/drivers/pci/dwc/pcie-artpec6.c
@@ -19,6 +19,8 @@
#include
#include
#include
+#include
+#include
#include "pcie-designware.h"
@@ -35,6 +37,7 @@ struct artpec6_pcie {
void __iomem*phy_base; /* DT phy */
enum artpec_pcie_variants variant;
enum dw_pcie_device_mode mode;
+ struct gpio_desc*reset;
};
struct artpec_pcie_of_data {
@@ -350,6 +353,13 @@ static void artpec6_pcie_deassert_core_reset(struct
artpec6_pcie *artpec6_pcie)
}
artpec6_pcie_writel(artpec6_pcie, PCIECFG, val);
usleep_range(100, 200);
+
+ /* Some boards don't have PCIe reset hardwired, use a GPIO insted. */
+ if (artpec6_pcie->reset) {
+ gpiod_set_value_cansleep(artpec6_pcie->reset, 1);
+ msleep(100);
+ gpiod_set_value_cansleep(artpec6_pcie->reset, 0);
+ }
}
static void artpec6_pcie_enable_interrupts(struct artpec6_pcie *artpec6_pcie)
@@ -513,6 +523,7 @@ static int artpec6_pcie_probe(struct platform_device *pdev)
const struct artpec_pcie_of_data *data;
enum artpec_pcie_variants variant;
enum dw_pcie_device_mode mode;
+ struct device_node *node = dev->of_node;
match = of_match_device(artpec6_pcie_of_match, dev);
if (!match)
@@ -548,11 +559,18 @@ static int artpec6_pcie_probe(struct platform_device
*pdev)
return PTR_ERR(artpec6_pcie->phy_base);
artpec6_pcie->regmap =
- syscon_regmap_lookup_by_phandle(dev->of_node,
+ syscon_regmap_lookup_by_phandle(node,
"axis,syscon-pcie");
if (IS_ERR(artpec6_pcie->regmap))
return PTR_ERR(artpec6_pcie->regmap);
+ artpec6_pcie->reset = devm_gpiod_get_optional(dev, "reset",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(artpec6_pcie->reset)) {
+ dev_err(dev, "Failed to request reset gpio\n");
+ return PTR_ERR(artpec6_pcie->reset);
+ }
+
platform_set_drvdata(pdev, artpec6_pcie);
switch (artpec6_pcie->mode) {
--
2.1.4
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH 23/47] cpufreq: remove cris specific drivers
On Wed, Mar 14, 2018 at 04:35:36PM +0100, Arnd Bergmann wrote: > The cris architecture is getting removed, including the artpec3 > and etraxfs SoCs, so these cpufreq drivers are now unused. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> Acked-by: Jesper Nilsson <jesper.nils...@axis.com> > --- > drivers/cpufreq/Makefile | 2 - > drivers/cpufreq/cris-artpec3-cpufreq.c | 93 > -- > drivers/cpufreq/cris-etraxfs-cpufreq.c | 92 - > 3 files changed, 187 deletions(-) > delete mode 100644 drivers/cpufreq/cris-artpec3-cpufreq.c > delete mode 100644 drivers/cpufreq/cris-etraxfs-cpufreq.c > > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile > index 2e4495cf9aa8..8d24ade3bd02 100644 > --- a/drivers/cpufreq/Makefile > +++ b/drivers/cpufreq/Makefile > @@ -102,8 +102,6 @@ obj-$(CONFIG_POWERNV_CPUFREQ) += > powernv-cpufreq.o > > ## > # Other platform drivers > obj-$(CONFIG_BMIPS_CPUFREQ) += bmips-cpufreq.o > -obj-$(CONFIG_CRIS_MACH_ARTPEC3) += cris-artpec3-cpufreq.o > -obj-$(CONFIG_ETRAXFS)+= cris-etraxfs-cpufreq.o > obj-$(CONFIG_IA64_ACPI_CPUFREQ) += ia64-acpi-cpufreq.o > obj-$(CONFIG_LOONGSON2_CPUFREQ) += loongson2_cpufreq.o > obj-$(CONFIG_LOONGSON1_CPUFREQ) += loongson1-cpufreq.o > diff --git a/drivers/cpufreq/cris-artpec3-cpufreq.c > b/drivers/cpufreq/cris-artpec3-cpufreq.c > deleted file mode 100644 > index 455b4fb78cba.. > diff --git a/drivers/cpufreq/cris-etraxfs-cpufreq.c > b/drivers/cpufreq/cris-etraxfs-cpufreq.c > deleted file mode 100644 > index 4c4b5dd685e3.. > -- > 2.9.0 /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH 23/47] cpufreq: remove cris specific drivers
On Wed, Mar 14, 2018 at 04:35:36PM +0100, Arnd Bergmann wrote: > The cris architecture is getting removed, including the artpec3 > and etraxfs SoCs, so these cpufreq drivers are now unused. > > Signed-off-by: Arnd Bergmann Acked-by: Jesper Nilsson > --- > drivers/cpufreq/Makefile | 2 - > drivers/cpufreq/cris-artpec3-cpufreq.c | 93 > -- > drivers/cpufreq/cris-etraxfs-cpufreq.c | 92 - > 3 files changed, 187 deletions(-) > delete mode 100644 drivers/cpufreq/cris-artpec3-cpufreq.c > delete mode 100644 drivers/cpufreq/cris-etraxfs-cpufreq.c > > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile > index 2e4495cf9aa8..8d24ade3bd02 100644 > --- a/drivers/cpufreq/Makefile > +++ b/drivers/cpufreq/Makefile > @@ -102,8 +102,6 @@ obj-$(CONFIG_POWERNV_CPUFREQ) += > powernv-cpufreq.o > > ## > # Other platform drivers > obj-$(CONFIG_BMIPS_CPUFREQ) += bmips-cpufreq.o > -obj-$(CONFIG_CRIS_MACH_ARTPEC3) += cris-artpec3-cpufreq.o > -obj-$(CONFIG_ETRAXFS)+= cris-etraxfs-cpufreq.o > obj-$(CONFIG_IA64_ACPI_CPUFREQ) += ia64-acpi-cpufreq.o > obj-$(CONFIG_LOONGSON2_CPUFREQ) += loongson2_cpufreq.o > obj-$(CONFIG_LOONGSON1_CPUFREQ) += loongson1-cpufreq.o > diff --git a/drivers/cpufreq/cris-artpec3-cpufreq.c > b/drivers/cpufreq/cris-artpec3-cpufreq.c > deleted file mode 100644 > index 455b4fb78cba.. > diff --git a/drivers/cpufreq/cris-etraxfs-cpufreq.c > b/drivers/cpufreq/cris-etraxfs-cpufreq.c > deleted file mode 100644 > index 4c4b5dd685e3.. > -- > 2.9.0 /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH 05/47] net: remove cris etrax ethernet driver
On Wed, Mar 14, 2018 at 04:35:18PM +0100, Arnd Bergmann wrote: > The cris architecture is getting removed, so we don't need the > ethernet driver any more either. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> Acked-by: Jesper Nilsson <jesper.nils...@axis.com> > --- > drivers/net/Makefile |1 - > drivers/net/cris/Makefile |1 - > drivers/net/cris/eth_v10.c | 1742 > > 3 files changed, 1744 deletions(-) > delete mode 100644 drivers/net/cris/Makefile > delete mode 100644 drivers/net/cris/eth_v10.c > > diff --git a/drivers/net/Makefile b/drivers/net/Makefile > index 04c3b747812c..91e67e375dd4 100644 > --- a/drivers/net/Makefile > +++ b/drivers/net/Makefile > @@ -40,7 +40,6 @@ obj-$(CONFIG_ARCNET) += arcnet/ > obj-$(CONFIG_DEV_APPLETALK) += appletalk/ > obj-$(CONFIG_CAIF) += caif/ > obj-$(CONFIG_CAN) += can/ > -obj-$(CONFIG_ETRAX_ETHERNET) += cris/ > obj-$(CONFIG_NET_DSA) += dsa/ > obj-$(CONFIG_ETHERNET) += ethernet/ > obj-$(CONFIG_FDDI) += fddi/ > diff --git a/drivers/net/cris/Makefile b/drivers/net/cris/Makefile > deleted file mode 100644 > index b4e8932227b6.. > diff --git a/drivers/net/cris/eth_v10.c b/drivers/net/cris/eth_v10.c > deleted file mode 100644 > index 8b1a859f5140.. > -- > 2.9.0 /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH 05/47] net: remove cris etrax ethernet driver
On Wed, Mar 14, 2018 at 04:35:18PM +0100, Arnd Bergmann wrote: > The cris architecture is getting removed, so we don't need the > ethernet driver any more either. > > Signed-off-by: Arnd Bergmann Acked-by: Jesper Nilsson > --- > drivers/net/Makefile |1 - > drivers/net/cris/Makefile |1 - > drivers/net/cris/eth_v10.c | 1742 > > 3 files changed, 1744 deletions(-) > delete mode 100644 drivers/net/cris/Makefile > delete mode 100644 drivers/net/cris/eth_v10.c > > diff --git a/drivers/net/Makefile b/drivers/net/Makefile > index 04c3b747812c..91e67e375dd4 100644 > --- a/drivers/net/Makefile > +++ b/drivers/net/Makefile > @@ -40,7 +40,6 @@ obj-$(CONFIG_ARCNET) += arcnet/ > obj-$(CONFIG_DEV_APPLETALK) += appletalk/ > obj-$(CONFIG_CAIF) += caif/ > obj-$(CONFIG_CAN) += can/ > -obj-$(CONFIG_ETRAX_ETHERNET) += cris/ > obj-$(CONFIG_NET_DSA) += dsa/ > obj-$(CONFIG_ETHERNET) += ethernet/ > obj-$(CONFIG_FDDI) += fddi/ > diff --git a/drivers/net/cris/Makefile b/drivers/net/cris/Makefile > deleted file mode 100644 > index b4e8932227b6.. > diff --git a/drivers/net/cris/eth_v10.c b/drivers/net/cris/eth_v10.c > deleted file mode 100644 > index 8b1a859f5140.. > -- > 2.9.0 /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH 40/47] serial: remove cris/etrax uart drivers
On Wed, Mar 14, 2018 at 04:35:53PM +0100, Arnd Bergmann wrote: > The cris architecture is getting removed, so we don't need the > uart driver any more. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> Acked-by: Jesper Nilsson <jesper.nils...@axis.com> > --- > .../bindings/serial/axis,etraxfs-uart.txt | 22 - > drivers/tty/serial/Kconfig | 11 - > drivers/tty/serial/Makefile|2 - > drivers/tty/serial/crisv10.c | 4248 > > drivers/tty/serial/crisv10.h | 133 - > drivers/tty/serial/etraxfs-uart.c | 960 - > 6 files changed, 5376 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/serial/axis,etraxfs-uart.txt > delete mode 100644 drivers/tty/serial/crisv10.c > delete mode 100644 drivers/tty/serial/crisv10.h > delete mode 100644 drivers/tty/serial/etraxfs-uart.c > > diff --git a/Documentation/devicetree/bindings/serial/axis,etraxfs-uart.txt > b/Documentation/devicetree/bindings/serial/axis,etraxfs-uart.txt > deleted file mode 100644 > index 048c3818c826.. > diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig > index 3682fd3e960c..f6e09326042d 100644 > --- a/drivers/tty/serial/Kconfig > +++ b/drivers/tty/serial/Kconfig > @@ -1114,17 +1114,6 @@ config SERIAL_VT8500_CONSOLE > depends on SERIAL_VT8500=y > select SERIAL_CORE_CONSOLE > > -config SERIAL_ETRAXFS > - bool "ETRAX FS serial port support" > - depends on ETRAX_ARCH_V32 && OF > - select SERIAL_CORE > - select SERIAL_MCTRL_GPIO if GPIOLIB > - > -config SERIAL_ETRAXFS_CONSOLE > - bool "ETRAX FS serial console support" > - depends on SERIAL_ETRAXFS > - select SERIAL_CORE_CONSOLE > - > config SERIAL_NETX > tristate "NetX serial port support" > depends on ARCH_NETX > diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile > index 842d185d697e..c21835dc16b2 100644 > --- a/drivers/tty/serial/Makefile > +++ b/drivers/tty/serial/Makefile > @@ -51,8 +51,6 @@ obj-$(CONFIG_SERIAL_M32R_SIO) += m32r_sio.o > obj-$(CONFIG_SERIAL_MPSC) += mpsc.o > obj-$(CONFIG_SERIAL_MESON) += meson_uart.o > obj-$(CONFIG_SERIAL_SB1250_DUART) += sb1250-duart.o > -obj-$(CONFIG_ETRAX_SERIAL) += crisv10.o > -obj-$(CONFIG_SERIAL_ETRAXFS) += etraxfs-uart.o > obj-$(CONFIG_SERIAL_SCCNXP) += sccnxp.o > obj-$(CONFIG_SERIAL_SC16IS7XX_CORE) += sc16is7xx.o > obj-$(CONFIG_SERIAL_JSM) += jsm/ > diff --git a/drivers/tty/serial/crisv10.c b/drivers/tty/serial/crisv10.c > deleted file mode 100644 > index c9458a033e3c.. > diff --git a/drivers/tty/serial/crisv10.h b/drivers/tty/serial/crisv10.h > deleted file mode 100644 > index 79ba2bc95d3d.. > diff --git a/drivers/tty/serial/etraxfs-uart.c > b/drivers/tty/serial/etraxfs-uart.c > deleted file mode 100644 > index 24bf6bfb29b4.. > -- > 2.9.0 /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH 40/47] serial: remove cris/etrax uart drivers
On Wed, Mar 14, 2018 at 04:35:53PM +0100, Arnd Bergmann wrote: > The cris architecture is getting removed, so we don't need the > uart driver any more. > > Signed-off-by: Arnd Bergmann Acked-by: Jesper Nilsson > --- > .../bindings/serial/axis,etraxfs-uart.txt | 22 - > drivers/tty/serial/Kconfig | 11 - > drivers/tty/serial/Makefile|2 - > drivers/tty/serial/crisv10.c | 4248 > > drivers/tty/serial/crisv10.h | 133 - > drivers/tty/serial/etraxfs-uart.c | 960 - > 6 files changed, 5376 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/serial/axis,etraxfs-uart.txt > delete mode 100644 drivers/tty/serial/crisv10.c > delete mode 100644 drivers/tty/serial/crisv10.h > delete mode 100644 drivers/tty/serial/etraxfs-uart.c > > diff --git a/Documentation/devicetree/bindings/serial/axis,etraxfs-uart.txt > b/Documentation/devicetree/bindings/serial/axis,etraxfs-uart.txt > deleted file mode 100644 > index 048c3818c826.. > diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig > index 3682fd3e960c..f6e09326042d 100644 > --- a/drivers/tty/serial/Kconfig > +++ b/drivers/tty/serial/Kconfig > @@ -1114,17 +1114,6 @@ config SERIAL_VT8500_CONSOLE > depends on SERIAL_VT8500=y > select SERIAL_CORE_CONSOLE > > -config SERIAL_ETRAXFS > - bool "ETRAX FS serial port support" > - depends on ETRAX_ARCH_V32 && OF > - select SERIAL_CORE > - select SERIAL_MCTRL_GPIO if GPIOLIB > - > -config SERIAL_ETRAXFS_CONSOLE > - bool "ETRAX FS serial console support" > - depends on SERIAL_ETRAXFS > - select SERIAL_CORE_CONSOLE > - > config SERIAL_NETX > tristate "NetX serial port support" > depends on ARCH_NETX > diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile > index 842d185d697e..c21835dc16b2 100644 > --- a/drivers/tty/serial/Makefile > +++ b/drivers/tty/serial/Makefile > @@ -51,8 +51,6 @@ obj-$(CONFIG_SERIAL_M32R_SIO) += m32r_sio.o > obj-$(CONFIG_SERIAL_MPSC) += mpsc.o > obj-$(CONFIG_SERIAL_MESON) += meson_uart.o > obj-$(CONFIG_SERIAL_SB1250_DUART) += sb1250-duart.o > -obj-$(CONFIG_ETRAX_SERIAL) += crisv10.o > -obj-$(CONFIG_SERIAL_ETRAXFS) += etraxfs-uart.o > obj-$(CONFIG_SERIAL_SCCNXP) += sccnxp.o > obj-$(CONFIG_SERIAL_SC16IS7XX_CORE) += sc16is7xx.o > obj-$(CONFIG_SERIAL_JSM) += jsm/ > diff --git a/drivers/tty/serial/crisv10.c b/drivers/tty/serial/crisv10.c > deleted file mode 100644 > index c9458a033e3c.. > diff --git a/drivers/tty/serial/crisv10.h b/drivers/tty/serial/crisv10.h > deleted file mode 100644 > index 79ba2bc95d3d..0000 > diff --git a/drivers/tty/serial/etraxfs-uart.c > b/drivers/tty/serial/etraxfs-uart.c > deleted file mode 100644 > index 24bf6bfb29b4.. > -- > 2.9.0 /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [GIT PULL] CRIS: Drop support for the CRIS-port
On Mon, Mar 12, 2018 at 09:21:25PM +0100, Arnd Bergmann wrote: > On Sun, Mar 11, 2018 at 12:05 PM, Jesper Nilsson > <jesper.nils...@axis.com> wrote: > > Hi Arnd, > > > > As promised, pull the below tag for the removal of the CRIS-port. > > There are still a few references to the CRIS port left, and they > > can be grouped into two categories: > > > > - Examples or references to the CRIS port as provenance. > > These I believe can be left as is. > > > > - The workarounds for CRIS not having "unpacked" structs. > > When I looked at it 10 years ago, CRIS was the only port > > that needed explicit alignment of some structs, > > due to pointers being valid at any byte offset in CRIS, > > which would wreak havoc with code that assumed that the > > lower bits of a pointer are free to use as flags. > > I'm leaving these in until we can say that no newer > > port has the same problem. > > > > Best regards, > > Hi Jesper, > > Thanks for the patch! I had done a slightly different approach, but > am merging your changes into my tree now. I already have separate > patches for each driver subsystem, so I'll keep my versions, having > already made sure that your changes were identical. > > For Documentation/features and the Kconfig files that have lists > of architectures, I also have separate patches that do the changes > for all architectures, to avoid touching those files (up to) eight times > for one trivial change each. I could redo those, but since your patch > conflicts with David Howell's patch for mn10300, it's easier to keep > what I already have. > > This leaves basically the removal of arch/cris along with the MAINTAINER > file update. I'm keeping the patch I did, but change the author and > changelog text to what you sent, with my Signed-off-by and a list > of my modifications) added below. > > Hope that works for you. Yeah, no problem, and thanks. > Arnd /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [GIT PULL] CRIS: Drop support for the CRIS-port
On Mon, Mar 12, 2018 at 09:21:25PM +0100, Arnd Bergmann wrote: > On Sun, Mar 11, 2018 at 12:05 PM, Jesper Nilsson > wrote: > > Hi Arnd, > > > > As promised, pull the below tag for the removal of the CRIS-port. > > There are still a few references to the CRIS port left, and they > > can be grouped into two categories: > > > > - Examples or references to the CRIS port as provenance. > > These I believe can be left as is. > > > > - The workarounds for CRIS not having "unpacked" structs. > > When I looked at it 10 years ago, CRIS was the only port > > that needed explicit alignment of some structs, > > due to pointers being valid at any byte offset in CRIS, > > which would wreak havoc with code that assumed that the > > lower bits of a pointer are free to use as flags. > > I'm leaving these in until we can say that no newer > > port has the same problem. > > > > Best regards, > > Hi Jesper, > > Thanks for the patch! I had done a slightly different approach, but > am merging your changes into my tree now. I already have separate > patches for each driver subsystem, so I'll keep my versions, having > already made sure that your changes were identical. > > For Documentation/features and the Kconfig files that have lists > of architectures, I also have separate patches that do the changes > for all architectures, to avoid touching those files (up to) eight times > for one trivial change each. I could redo those, but since your patch > conflicts with David Howell's patch for mn10300, it's easier to keep > what I already have. > > This leaves basically the removal of arch/cris along with the MAINTAINER > file update. I'm keeping the patch I did, but change the author and > changelog text to what you sent, with my Signed-off-by and a list > of my modifications) added below. > > Hope that works for you. Yeah, no problem, and thanks. > Arnd /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [GIT PULL] CRIS: Drop support for the CRIS-port
On Mon, Mar 12, 2018 at 01:13:44AM +1100, Stephen Rothwell wrote: > Hi Jesper, > > On Sun, 11 Mar 2018 12:05:51 +0100 Jesper Nilsson <jesper.nils...@axis.com> > wrote: > > > > As promised, pull the below tag for the removal of the CRIS-port. > > I guess the easiest thing for me to do is just remove the cris tree > from linux-next at this point? Yeah, that's probably the way to go. > Cheers, > Stephen Rothwell /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [GIT PULL] CRIS: Drop support for the CRIS-port
On Mon, Mar 12, 2018 at 01:13:44AM +1100, Stephen Rothwell wrote: > Hi Jesper, > > On Sun, 11 Mar 2018 12:05:51 +0100 Jesper Nilsson > wrote: > > > > As promised, pull the below tag for the removal of the CRIS-port. > > I guess the easiest thing for me to do is just remove the cris tree > from linux-next at this point? Yeah, that's probably the way to go. > Cheers, > Stephen Rothwell /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
[GIT PULL] CRIS: Drop support for the CRIS-port
Hi Arnd, As promised, pull the below tag for the removal of the CRIS-port. There are still a few references to the CRIS port left, and they can be grouped into two categories: - Examples or references to the CRIS port as provenance. These I believe can be left as is. - The workarounds for CRIS not having "unpacked" structs. When I looked at it 10 years ago, CRIS was the only port that needed explicit alignment of some structs, due to pointers being valid at any byte offset in CRIS, which would wreak havoc with code that assumed that the lower bits of a pointer are free to use as flags. I'm leaving these in until we can say that no newer port has the same problem. Best regards, /Jesper The following changes since commit 1b88accf6a659c46d5c8e68912896f112bf882bb: Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost (2018-03-07 17:49:33 -0800) are available in the Git repository at: ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/jesper/cris.git tags/cris-eol for you to fetch changes up to 657adcf3a431293cd86a6f9d5dd5dbf9378b63f9: CRIS: Drop support for the CRIS port (2018-03-11 11:16:55 +0100) Drop support for the CRIS-port -------- Jesper Nilsson (1): CRIS: Drop support for the CRIS port Documentation/00-INDEX |2 - Documentation/admin-guide/README.rst |2 +- Documentation/cris/README | 195 - Documentation/devicetree/bindings/cris/axis.txt|9 - Documentation/devicetree/bindings/cris/boards.txt |8 - .../devicetree/bindings/gpio/gpio-etraxfs.txt | 22 - .../interrupt-controller/axis,crisv32-intc.txt | 23 - .../bindings/serial/axis,etraxfs-uart.txt | 22 - .../features/core/BPF-JIT/arch-support.txt |1 - .../core/generic-idle-thread/arch-support.txt |1 - .../features/core/jump-labels/arch-support.txt |1 - .../features/core/tracehook/arch-support.txt |1 - .../features/debug/KASAN/arch-support.txt |1 - .../debug/gcov-profile-all/arch-support.txt|1 - Documentation/features/debug/kgdb/arch-support.txt |1 - .../debug/kprobes-on-ftrace/arch-support.txt |1 - .../features/debug/kprobes/arch-support.txt|1 - .../features/debug/kretprobes/arch-support.txt |1 - .../features/debug/optprobes/arch-support.txt |1 - .../features/debug/stackprotector/arch-support.txt |1 - .../features/debug/uprobes/arch-support.txt|1 - .../debug/user-ret-profiler/arch-support.txt |1 - .../features/io/dma-api-debug/arch-support.txt |1 - .../features/io/dma-contiguous/arch-support.txt|1 - .../features/io/sg-chain/arch-support.txt |1 - .../features/lib/strncasecmp/arch-support.txt |1 - .../locking/cmpxchg-local/arch-support.txt |1 - .../features/locking/lockdep/arch-support.txt |1 - .../locking/queued-rwlocks/arch-support.txt|1 - .../locking/queued-spinlocks/arch-support.txt |1 - .../locking/rwsem-optimized/arch-support.txt |1 - .../features/perf/kprobes-event/arch-support.txt |1 - .../features/perf/perf-regs/arch-support.txt |1 - .../features/perf/perf-stackdump/arch-support.txt |1 - .../sched/membarrier-sync-core/arch-support.txt|1 - .../features/sched/numa-balancing/arch-support.txt |1 - .../seccomp/seccomp-filter/arch-support.txt|1 - .../time/arch-tick-broadcast/arch-support.txt |1 - .../features/time/clockevents/arch-support.txt |1 - .../time/context-tracking/arch-support.txt |1 - .../features/time/irq-time-acct/arch-support.txt |1 - .../time/modern-timekeeping/arch-support.txt |1 - .../features/time/virt-cpuacct/arch-support.txt|1 - .../features/vm/ELF-ASLR/arch-support.txt |1 - .../features/vm/PG_uncached/arch-support.txt |1 - Documentation/features/vm/THP/arch-support.txt |1 - Documentation/features/vm/TLB/arch-support.txt |1 - .../features/vm/huge-vmap/arch-support.txt |1 - .../features/vm/ioremap_prot/arch-support.txt |1 - .../features/vm/numa-memblock/arch-support.txt |1 - .../features/vm/pte_special/arch-support.txt |1 - MAINTAINERS| 10 - arch/cris/Kconfig | 595 -- arch/cris/Kconfig.debug| 41 - arch/cris/Makefile | 104 - arch/cris/arch-v10/Kconfig | 399 -- arch/cris/arch-v10/README.mm | 244 - arch/cris/arch-v10/drivers/Kconfig
[GIT PULL] CRIS: Drop support for the CRIS-port
Hi Arnd, As promised, pull the below tag for the removal of the CRIS-port. There are still a few references to the CRIS port left, and they can be grouped into two categories: - Examples or references to the CRIS port as provenance. These I believe can be left as is. - The workarounds for CRIS not having "unpacked" structs. When I looked at it 10 years ago, CRIS was the only port that needed explicit alignment of some structs, due to pointers being valid at any byte offset in CRIS, which would wreak havoc with code that assumed that the lower bits of a pointer are free to use as flags. I'm leaving these in until we can say that no newer port has the same problem. Best regards, /Jesper The following changes since commit 1b88accf6a659c46d5c8e68912896f112bf882bb: Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost (2018-03-07 17:49:33 -0800) are available in the Git repository at: ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/jesper/cris.git tags/cris-eol for you to fetch changes up to 657adcf3a431293cd86a6f9d5dd5dbf9378b63f9: CRIS: Drop support for the CRIS port (2018-03-11 11:16:55 +0100) Drop support for the CRIS-port -------- Jesper Nilsson (1): CRIS: Drop support for the CRIS port Documentation/00-INDEX |2 - Documentation/admin-guide/README.rst |2 +- Documentation/cris/README | 195 - Documentation/devicetree/bindings/cris/axis.txt|9 - Documentation/devicetree/bindings/cris/boards.txt |8 - .../devicetree/bindings/gpio/gpio-etraxfs.txt | 22 - .../interrupt-controller/axis,crisv32-intc.txt | 23 - .../bindings/serial/axis,etraxfs-uart.txt | 22 - .../features/core/BPF-JIT/arch-support.txt |1 - .../core/generic-idle-thread/arch-support.txt |1 - .../features/core/jump-labels/arch-support.txt |1 - .../features/core/tracehook/arch-support.txt |1 - .../features/debug/KASAN/arch-support.txt |1 - .../debug/gcov-profile-all/arch-support.txt|1 - Documentation/features/debug/kgdb/arch-support.txt |1 - .../debug/kprobes-on-ftrace/arch-support.txt |1 - .../features/debug/kprobes/arch-support.txt|1 - .../features/debug/kretprobes/arch-support.txt |1 - .../features/debug/optprobes/arch-support.txt |1 - .../features/debug/stackprotector/arch-support.txt |1 - .../features/debug/uprobes/arch-support.txt|1 - .../debug/user-ret-profiler/arch-support.txt |1 - .../features/io/dma-api-debug/arch-support.txt |1 - .../features/io/dma-contiguous/arch-support.txt|1 - .../features/io/sg-chain/arch-support.txt |1 - .../features/lib/strncasecmp/arch-support.txt |1 - .../locking/cmpxchg-local/arch-support.txt |1 - .../features/locking/lockdep/arch-support.txt |1 - .../locking/queued-rwlocks/arch-support.txt|1 - .../locking/queued-spinlocks/arch-support.txt |1 - .../locking/rwsem-optimized/arch-support.txt |1 - .../features/perf/kprobes-event/arch-support.txt |1 - .../features/perf/perf-regs/arch-support.txt |1 - .../features/perf/perf-stackdump/arch-support.txt |1 - .../sched/membarrier-sync-core/arch-support.txt|1 - .../features/sched/numa-balancing/arch-support.txt |1 - .../seccomp/seccomp-filter/arch-support.txt|1 - .../time/arch-tick-broadcast/arch-support.txt |1 - .../features/time/clockevents/arch-support.txt |1 - .../time/context-tracking/arch-support.txt |1 - .../features/time/irq-time-acct/arch-support.txt |1 - .../time/modern-timekeeping/arch-support.txt |1 - .../features/time/virt-cpuacct/arch-support.txt|1 - .../features/vm/ELF-ASLR/arch-support.txt |1 - .../features/vm/PG_uncached/arch-support.txt |1 - Documentation/features/vm/THP/arch-support.txt |1 - Documentation/features/vm/TLB/arch-support.txt |1 - .../features/vm/huge-vmap/arch-support.txt |1 - .../features/vm/ioremap_prot/arch-support.txt |1 - .../features/vm/numa-memblock/arch-support.txt |1 - .../features/vm/pte_special/arch-support.txt |1 - MAINTAINERS| 10 - arch/cris/Kconfig | 595 -- arch/cris/Kconfig.debug| 41 - arch/cris/Makefile | 104 - arch/cris/arch-v10/Kconfig | 399 -- arch/cris/arch-v10/README.mm | 244 - arch/cris/arch-v10/drivers/Kconfig
Re: CRIS port status, was: [PATCH] dump_stack: convert generic dump_stack into a weak symbol
On Wed, Mar 07, 2018 at 03:09:27PM +0100, Arnd Bergmann wrote: > On Wed, Mar 7, 2018 at 2:40 PM, Sergey Senozhatsky > <sergey.senozhat...@gmail.com> wrote: > > On (03/07/18 13:48), Arnd Bergmann wrote: > > [..] > >> > > >> > I can easily stop building blackfin - and, if the intention is to > >> > remove it, there is not much point in wasting resources building it any > >> > anyway. > >> > >> Right. At the moment, the plan is to remove metag, score, unicore32, > >> m32r, frv and blackfin. If you are building any more of those, you can > >> stop that as well. > >> > >> The fate of tile and mn10300 is still open, but I suspect they won't > >> last long either. > > > > That's a huge list. > > > > I heard that CRIS is having some problems as well: > > https://lkml.org/lkml/2018/1/11/403 > > Interesting. I thought I looked at cris when I made the list and found that > it was still (semi-)regularly updated, so I assumed it was still needed. Yeah, I've tried to keep it chugging along, but as I mentioned in that thread, time and working hardware are running low. I've not heard of anyone using real CRIS-hardware with mainline releases for a couple of years now (except me :-) > Jesper/Mikael: If you are considering to drop the port, I think it > would make sense to do it at the same time as the others, so feel > free to send me a removal pull request for 4.17 that I'll merge with > the other removal patches, or I can offer to remove it myself. I'm having mixed feelings, but I think it's time for Linux to drop the CRIS-port. I'll prepare some patches for you in the CRIS-tree. > Obviously if your plans have changed in the meantime and you > prefer to keep it for a while longer, just let me know and I'll document > the state in the tag description for the arch removal for future reference. > > If we remove cris, it's probably also appropriate to ask the question > about microblaze: Michal, I know your work on microblaze linux has > been winding down over the years as the user base shrinks (just > like for all others above). Should we keep it for a few more years for > the remaining users, or is it time to let go? I would guess we still > have active users on modern kernels, but that's what I thought > about cris as well ;-) > > Arnd /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: CRIS port status, was: [PATCH] dump_stack: convert generic dump_stack into a weak symbol
On Wed, Mar 07, 2018 at 03:09:27PM +0100, Arnd Bergmann wrote: > On Wed, Mar 7, 2018 at 2:40 PM, Sergey Senozhatsky > wrote: > > On (03/07/18 13:48), Arnd Bergmann wrote: > > [..] > >> > > >> > I can easily stop building blackfin - and, if the intention is to > >> > remove it, there is not much point in wasting resources building it any > >> > anyway. > >> > >> Right. At the moment, the plan is to remove metag, score, unicore32, > >> m32r, frv and blackfin. If you are building any more of those, you can > >> stop that as well. > >> > >> The fate of tile and mn10300 is still open, but I suspect they won't > >> last long either. > > > > That's a huge list. > > > > I heard that CRIS is having some problems as well: > > https://lkml.org/lkml/2018/1/11/403 > > Interesting. I thought I looked at cris when I made the list and found that > it was still (semi-)regularly updated, so I assumed it was still needed. Yeah, I've tried to keep it chugging along, but as I mentioned in that thread, time and working hardware are running low. I've not heard of anyone using real CRIS-hardware with mainline releases for a couple of years now (except me :-) > Jesper/Mikael: If you are considering to drop the port, I think it > would make sense to do it at the same time as the others, so feel > free to send me a removal pull request for 4.17 that I'll merge with > the other removal patches, or I can offer to remove it myself. I'm having mixed feelings, but I think it's time for Linux to drop the CRIS-port. I'll prepare some patches for you in the CRIS-tree. > Obviously if your plans have changed in the meantime and you > prefer to keep it for a while longer, just let me know and I'll document > the state in the tag description for the arch removal for future reference. > > If we remove cris, it's probably also appropriate to ask the question > about microblaze: Michal, I know your work on microblaze linux has > been winding down over the years as the user base shrinks (just > like for all others above). Should we keep it for a few more years for > the remaining users, or is it time to let go? I would guess we still > have active users on modern kernels, but that's what I thought > about cris as well ;-) > > Arnd /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
[GIT PULL] CRIS urgent fixes for 4.16
Hi Linus, Please pull the below tag for an urgent fix for build problems in the CRIS-port. The following changes since commit e237f98a9c134c3d600353f21e07db915516875b: Merge tag 'xfs-4.16-merge-5' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux (2018-02-05 13:35:56 -0800) are available in the Git repository at: ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/jesper/cris.git tags/cris-for-4.16-urgent for you to fetch changes up to 6e0377212c4e45d7350cff018f6a95633937c031: CRIS: Restore mistakenly cleared kernel Makefile (2018-02-08 11:12:10 +0100) CRIS urgent breakage fix for 4.16 The main Makefile for the CRIS port was overzealously scrubbed in 4.15-rc3, breaking the build for all CRIS SoCs. Jesper Nilsson (1): CRIS: Restore mistakenly cleared kernel Makefile arch/cris/kernel/Makefile | 17 + 1 file changed, 17 insertions(+) /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
[GIT PULL] CRIS urgent fixes for 4.16
Hi Linus, Please pull the below tag for an urgent fix for build problems in the CRIS-port. The following changes since commit e237f98a9c134c3d600353f21e07db915516875b: Merge tag 'xfs-4.16-merge-5' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux (2018-02-05 13:35:56 -0800) are available in the Git repository at: ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/jesper/cris.git tags/cris-for-4.16-urgent for you to fetch changes up to 6e0377212c4e45d7350cff018f6a95633937c031: CRIS: Restore mistakenly cleared kernel Makefile (2018-02-08 11:12:10 +0100) CRIS urgent breakage fix for 4.16 The main Makefile for the CRIS port was overzealously scrubbed in 4.15-rc3, breaking the build for all CRIS SoCs. Jesper Nilsson (1): CRIS: Restore mistakenly cleared kernel Makefile arch/cris/kernel/Makefile | 17 + 1 file changed, 17 insertions(+) /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
[GIT PULL] CRIS for 4.16
Hi Linus! Please pull the below for the only change I had in the CRIS tree for 4.16. It looks as there was som breakage in 4.15-rc3 for CRIS, which I'll send as a separate pull-request based on 4.15 asap. The following changes since commit bebc6082da0a9f5d47a1ea2edc099bf671058bd4: Linux 4.14 (2017-11-12 10:46:13 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris.git tags/cris-for-4.16 for you to fetch changes up to fd989db807a00d552ebf29d8ffb20c2ef04742da: cris: Fix conflicting types for _etext, _edata, _end (2018-01-13 22:42:09 +0100) CRIS port changes for 4.16 Includes only a small fix for some conflicting symbols, aligning CRIS with other platforms. Sergey Senozhatsky (1): cris: Fix conflicting types for _etext, _edata, _end arch/cris/kernel/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
[GIT PULL] CRIS for 4.16
Hi Linus! Please pull the below for the only change I had in the CRIS tree for 4.16. It looks as there was som breakage in 4.15-rc3 for CRIS, which I'll send as a separate pull-request based on 4.15 asap. The following changes since commit bebc6082da0a9f5d47a1ea2edc099bf671058bd4: Linux 4.14 (2017-11-12 10:46:13 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris.git tags/cris-for-4.16 for you to fetch changes up to fd989db807a00d552ebf29d8ffb20c2ef04742da: cris: Fix conflicting types for _etext, _edata, _end (2018-01-13 22:42:09 +0100) CRIS port changes for 4.16 Includes only a small fix for some conflicting symbols, aligning CRIS with other platforms. Sergey Senozhatsky (1): cris: Fix conflicting types for _etext, _edata, _end arch/cris/kernel/setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH] cris: Fix conflicting types for _etext, _edata, _end
On Thu, Jan 11, 2018 at 11:12:51PM +0900, Sergey Senozhatsky wrote:
> On (01/05/18 11:47), Sergey Senozhatsky wrote:
> > Include asm/sections.h header which contains the correct
> > types for _etext, _edata and _end - char arrays.
> >
> > Signed-off-by: Sergey Senozhatsky <sergey.senozhat...@gmail.com>
>
> Mikael, Jesper,
>
> any opinions?
This looks sane, and I can take it in the CRIS tree,
allthough I'm currently pondering the future of the CRIS port,
lack of time and active hardware are increasing problems.
> -ss
/Jesper
> > ---
> > arch/cris/kernel/setup.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/cris/kernel/setup.c b/arch/cris/kernel/setup.c
> > index 524d47501a23..1b61a7207afb 100644
> > --- a/arch/cris/kernel/setup.c
> > +++ b/arch/cris/kernel/setup.c
> > @@ -24,6 +24,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > /*
> > * Setup options
> > @@ -31,7 +32,6 @@
> > struct screen_info screen_info;
> >
> > extern int root_mountflags;
> > -extern char _etext, _edata, _end;
> >
> > char __initdata cris_command_line[COMMAND_LINE_SIZE] = { 0, };
> >
> > --
> > 2.15.1
> >
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH] cris: Fix conflicting types for _etext, _edata, _end
On Thu, Jan 11, 2018 at 11:12:51PM +0900, Sergey Senozhatsky wrote:
> On (01/05/18 11:47), Sergey Senozhatsky wrote:
> > Include asm/sections.h header which contains the correct
> > types for _etext, _edata and _end - char arrays.
> >
> > Signed-off-by: Sergey Senozhatsky
>
> Mikael, Jesper,
>
> any opinions?
This looks sane, and I can take it in the CRIS tree,
allthough I'm currently pondering the future of the CRIS port,
lack of time and active hardware are increasing problems.
> -ss
/Jesper
> > ---
> > arch/cris/kernel/setup.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/cris/kernel/setup.c b/arch/cris/kernel/setup.c
> > index 524d47501a23..1b61a7207afb 100644
> > --- a/arch/cris/kernel/setup.c
> > +++ b/arch/cris/kernel/setup.c
> > @@ -24,6 +24,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > /*
> > * Setup options
> > @@ -31,7 +32,6 @@
> > struct screen_info screen_info;
> >
> > extern int root_mountflags;
> > -extern char _etext, _edata, _end;
> >
> > char __initdata cris_command_line[COMMAND_LINE_SIZE] = { 0, };
> >
> > --
> > 2.15.1
> >
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH 05/67] dma-mapping: replace PCI_DMA_BUS_IS_PHYS with a flag in struct dma_map_ops
On Fri, Dec 29, 2017 at 09:18:09AM +0100, Christoph Hellwig wrote: > The current PCI_DMA_BUS_IS_PHYS decided if a dma implementation is bound > by the dma mask in the device because it directly maps to a physical > address range (modulo an offset in the device), or if it is virtualized > by an iommu and can map any address (that includes virtual iommus like > swiotlb). The problem with this scheme is that it is per-architecture and > not per dma_ops instance, and we are growing more and more setups that > have multiple different dma operations in use on a single system, for > which this scheme can't provide a correct answer. Depending on the > architecture that means we either get a false positive or false negative > at the moment. > > This patch instead extents the is_phys flag in struct dma_map_ops that > is currently only used by a few architectures to be used tree wide. > > Note that this means that we now need a struct device parent in the > Scsi_Host or netdevice. Every modern driver has these, but there might > still be a few outdated legacy drivers out there, which now won't make > an intelligent decision. > > Signed-off-by: Christoph Hellwig <h...@lst.de> For the CRIS part: Acked-by: Jesper Nilsson <jesper.nils...@axis.com> > --- > arch/cris/arch-v32/drivers/pci/dma.c | 1 + > arch/cris/include/asm/pci.h | 6 -- /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH 05/67] dma-mapping: replace PCI_DMA_BUS_IS_PHYS with a flag in struct dma_map_ops
On Fri, Dec 29, 2017 at 09:18:09AM +0100, Christoph Hellwig wrote: > The current PCI_DMA_BUS_IS_PHYS decided if a dma implementation is bound > by the dma mask in the device because it directly maps to a physical > address range (modulo an offset in the device), or if it is virtualized > by an iommu and can map any address (that includes virtual iommus like > swiotlb). The problem with this scheme is that it is per-architecture and > not per dma_ops instance, and we are growing more and more setups that > have multiple different dma operations in use on a single system, for > which this scheme can't provide a correct answer. Depending on the > architecture that means we either get a false positive or false negative > at the moment. > > This patch instead extents the is_phys flag in struct dma_map_ops that > is currently only used by a few architectures to be used tree wide. > > Note that this means that we now need a struct device parent in the > Scsi_Host or netdevice. Every modern driver has these, but there might > still be a few outdated legacy drivers out there, which now won't make > an intelligent decision. > > Signed-off-by: Christoph Hellwig For the CRIS part: Acked-by: Jesper Nilsson > --- > arch/cris/arch-v32/drivers/pci/dma.c | 1 + > arch/cris/include/asm/pci.h | 6 -- /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH 22/67] dma-mapping: clear harmful GFP_* flags in common code
On Fri, Dec 29, 2017 at 09:18:26AM +0100, Christoph Hellwig wrote: > Life the code from x86 so that we behave consistently. In the future we > should probably warn if any of these is set. > > Signed-off-by: Christoph Hellwig <h...@lst.de> Acked-by: Jesper Nilsson <jesper.nils...@axis.com> > --- > arch/cris/arch-v32/drivers/pci/dma.c | 3 --- /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH 22/67] dma-mapping: clear harmful GFP_* flags in common code
On Fri, Dec 29, 2017 at 09:18:26AM +0100, Christoph Hellwig wrote:
> Life the code from x86 so that we behave consistently. In the future we
> should probably warn if any of these is set.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Jesper Nilsson
> ---
> arch/cris/arch-v32/drivers/pci/dma.c | 3 ---
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH 34/67] cris: use dma-direct
On Fri, Dec 29, 2017 at 09:18:38AM +0100, Christoph Hellwig wrote: > cris currently has an incomplete direct mapping dma_map_ops implementation > is PCI support is enabled. Replace it with the fully feature generic > dma-direct implementation. > > Signed-off-by: Christoph Hellwig <h...@lst.de> For CRIS: Acked-by: Jesper Nilsson <jesper.nils...@axis.com> > --- > arch/cris/Kconfig | 4 ++ > arch/cris/arch-v32/drivers/pci/Makefile | 2 +- > arch/cris/arch-v32/drivers/pci/dma.c| 78 > - > arch/cris/include/asm/Kbuild| 1 + > arch/cris/include/asm/dma-mapping.h | 20 - > 5 files changed, 6 insertions(+), 99 deletions(-) > delete mode 100644 arch/cris/arch-v32/drivers/pci/dma.c > delete mode 100644 arch/cris/include/asm/dma-mapping.h > /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH 34/67] cris: use dma-direct
On Fri, Dec 29, 2017 at 09:18:38AM +0100, Christoph Hellwig wrote: > cris currently has an incomplete direct mapping dma_map_ops implementation > is PCI support is enabled. Replace it with the fully feature generic > dma-direct implementation. > > Signed-off-by: Christoph Hellwig For CRIS: Acked-by: Jesper Nilsson > --- > arch/cris/Kconfig | 4 ++ > arch/cris/arch-v32/drivers/pci/Makefile | 2 +- > arch/cris/arch-v32/drivers/pci/dma.c| 78 > - > arch/cris/include/asm/Kbuild| 1 + > arch/cris/include/asm/dma-mapping.h | 20 - > 5 files changed, 6 insertions(+), 99 deletions(-) > delete mode 100644 arch/cris/arch-v32/drivers/pci/dma.c > delete mode 100644 arch/cris/include/asm/dma-mapping.h > /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH 01/25] arm: artpec: dts: Remove leading 0x and 0s from bindings notation
On Fri, Dec 15, 2017 at 01:46:21PM +0100, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading
> "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e
> "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e
> "s/@0+\(.*\) {/@\1 {/g" {} +^C
>
> For simplicity, two sed expressions were used to solve each warnings
> separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This will solve as a side effect warning:
>
> Warning (simple_bus_reg): Node /XXX@ simple-bus unit address format
> error, expected ""
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x
> from bindings notation")
>
> Reported-by: David Daney <dda...@caviumnetworks.com>
> Suggested-by: Rob Herring <r...@kernel.org>
> Signed-off-by: Mathieu Malaterre <ma...@debian.org>
Acked-by: Jesper Nilsson <jesper.nils...@axis.com>
> ---
> arch/arm/boot/dts/artpec6.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/artpec6.dtsi b/arch/arm/boot/dts/artpec6.dtsi
> index 2ed11773048d..71e0e75e986b 100644
> --- a/arch/arm/boot/dts/artpec6.dtsi
> +++ b/arch/arm/boot/dts/artpec6.dtsi
> @@ -98,7 +98,7 @@
> clock-frequency = <12500>;
> };
>
> - clkctrl: clkctrl@0xf800 {
> + clkctrl: clkctrl@f800 {
> #clock-cells = <1>;
> compatible = "axis,artpec6-clkctrl";
> reg = <0xf800 0x48>;
> --
> 2.11.0
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH 01/25] arm: artpec: dts: Remove leading 0x and 0s from bindings notation
On Fri, Dec 15, 2017 at 01:46:21PM +0100, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading
> "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e
> "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e
> "s/@0+\(.*\) {/@\1 {/g" {} +^C
>
> For simplicity, two sed expressions were used to solve each warnings
> separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This will solve as a side effect warning:
>
> Warning (simple_bus_reg): Node /XXX@ simple-bus unit address format
> error, expected ""
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x
> from bindings notation")
>
> Reported-by: David Daney
> Suggested-by: Rob Herring
> Signed-off-by: Mathieu Malaterre
Acked-by: Jesper Nilsson
> ---
> arch/arm/boot/dts/artpec6.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/artpec6.dtsi b/arch/arm/boot/dts/artpec6.dtsi
> index 2ed11773048d..71e0e75e986b 100644
> --- a/arch/arm/boot/dts/artpec6.dtsi
> +++ b/arch/arm/boot/dts/artpec6.dtsi
> @@ -98,7 +98,7 @@
> clock-frequency = <12500>;
> };
>
> - clkctrl: clkctrl@0xf800 {
> + clkctrl: clkctrl@f800 {
> #clock-cells = <1>;
> compatible = "axis,artpec6-clkctrl";
> reg = <0xf800 0x48>;
> --
> 2.11.0
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH] arm: dts: Remove leading 0x and 0s from bindings notation
On Thu, Dec 14, 2017 at 05:53:48PM +0100, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading
> "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -E -i -e
> "s/@0x([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" -e "s/@0+([0-9a-fA-F\.]+)\s?\{/@\L\1
> \{/g" {} +
>
> For simplicity, two sed expressions were used to solve each warnings
> separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x
> from bindings notation")
>
> Reported-by: David Daney <dda...@caviumnetworks.com>
> Suggested-by: Rob Herring <r...@kernel.org>
> Signed-off-by: Mathieu Malaterre <ma...@debian.org>
> ---
> arch/arm/boot/dts/artpec6.dtsi| 2 +-
Acked-by: Jesper Nilsson <jesper.nils...@axis.com>
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH] arm: dts: Remove leading 0x and 0s from bindings notation
On Thu, Dec 14, 2017 at 05:53:48PM +0100, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading
> "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -E -i -e
> "s/@0x([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" -e "s/@0+([0-9a-fA-F\.]+)\s?\{/@\L\1
> \{/g" {} +
>
> For simplicity, two sed expressions were used to solve each warnings
> separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x
> from bindings notation")
>
> Reported-by: David Daney
> Suggested-by: Rob Herring
> Signed-off-by: Mathieu Malaterre
> ---
> arch/arm/boot/dts/artpec6.dtsi| 2 +-
Acked-by: Jesper Nilsson
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: mm/percpu.c: use smarter memory allocation for struct pcpu_alloc_info (crisv32 hang)
On Mon, Nov 27, 2017 at 03:51:04PM -0500, Nicolas Pitre wrote:
> On Mon, 27 Nov 2017, Tejun Heo wrote:
>
> > Hello,
> >
> > On Mon, Nov 27, 2017 at 03:31:52PM -0500, Nicolas Pitre wrote:
> > > So IMHO I don't think reverting the commit is the right thing to do.
> > > That commit is clearly not at fault here.
> >
> > It's not about the blame. We just want to avoid breaking boot in a
> > way which is difficult to debug. Once cris is fixed, we can re-apply
> > the patch.
>
> In that case I suggest the following instead. No point penalizing
> everyone for a single architecture's fault. And this will serve as a
> visible reminder to the cris people that they need to clean up.
>
> - >8
> Subject: percpu: hack to let the CRIS architecture to boot until they clean up
>
> Commit 438a506180 ("percpu: don't forget to free the temporary struct
> pcpu_alloc_info") uncovered a problem on the CRIS architecture where
> the bootmem allocator is initialized with virtual addresses. Given it
> has:
>
> #define __va(x) ((void *)((unsigned long)(x) | 0x8000))
>
> then things just work out because the end result is the same whether you
> give this a physical or a virtual address.
>
> Untill you call memblock_free_early(__pa(address)) that is, because
> values from __pa() don't match with the virtual addresses stuffed in the
> bootmem allocator anymore.
>
> Avoid freeing the temporary pcpu_alloc_info memory on that architecture
> until they fix things up to let the kernel boot like it did before.
>
> Signed-off-by: Nicolas Pitre <n...@linaro.org>
>
> diff --git a/mm/percpu.c b/mm/percpu.c
> index 79e3549cab..50e7fdf840 100644
> --- a/mm/percpu.c
> +++ b/mm/percpu.c
> @@ -2719,7 +2719,11 @@ void __init setup_per_cpu_areas(void)
>
> if (pcpu_setup_first_chunk(ai, fc) < 0)
> panic("Failed to initialize percpu areas.");
> +#ifdef CONFIG_CRIS
> +#warning "the CRIS architecture has physical and virtual addresses confused"
> +#else
> pcpu_free_alloc_info(ai);
> +#endif
> }
>
> #endif /* CONFIG_SMP */
Works for me, and thanks.
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: mm/percpu.c: use smarter memory allocation for struct pcpu_alloc_info (crisv32 hang)
On Mon, Nov 27, 2017 at 03:51:04PM -0500, Nicolas Pitre wrote:
> On Mon, 27 Nov 2017, Tejun Heo wrote:
>
> > Hello,
> >
> > On Mon, Nov 27, 2017 at 03:31:52PM -0500, Nicolas Pitre wrote:
> > > So IMHO I don't think reverting the commit is the right thing to do.
> > > That commit is clearly not at fault here.
> >
> > It's not about the blame. We just want to avoid breaking boot in a
> > way which is difficult to debug. Once cris is fixed, we can re-apply
> > the patch.
>
> In that case I suggest the following instead. No point penalizing
> everyone for a single architecture's fault. And this will serve as a
> visible reminder to the cris people that they need to clean up.
>
> - >8
> Subject: percpu: hack to let the CRIS architecture to boot until they clean up
>
> Commit 438a506180 ("percpu: don't forget to free the temporary struct
> pcpu_alloc_info") uncovered a problem on the CRIS architecture where
> the bootmem allocator is initialized with virtual addresses. Given it
> has:
>
> #define __va(x) ((void *)((unsigned long)(x) | 0x8000))
>
> then things just work out because the end result is the same whether you
> give this a physical or a virtual address.
>
> Untill you call memblock_free_early(__pa(address)) that is, because
> values from __pa() don't match with the virtual addresses stuffed in the
> bootmem allocator anymore.
>
> Avoid freeing the temporary pcpu_alloc_info memory on that architecture
> until they fix things up to let the kernel boot like it did before.
>
> Signed-off-by: Nicolas Pitre
>
> diff --git a/mm/percpu.c b/mm/percpu.c
> index 79e3549cab..50e7fdf840 100644
> --- a/mm/percpu.c
> +++ b/mm/percpu.c
> @@ -2719,7 +2719,11 @@ void __init setup_per_cpu_areas(void)
>
> if (pcpu_setup_first_chunk(ai, fc) < 0)
> panic("Failed to initialize percpu areas.");
> +#ifdef CONFIG_CRIS
> +#warning "the CRIS architecture has physical and virtual addresses confused"
> +#else
> pcpu_free_alloc_info(ai);
> +#endif
> }
>
> #endif /* CONFIG_SMP */
Works for me, and thanks.
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: mm/percpu.c: use smarter memory allocation for struct pcpu_alloc_info (crisv32 hang)
On Wed, Nov 22, 2017 at 03:17:00PM -0500, Nicolas Pitre wrote: > On Wed, 22 Nov 2017, Jesper Nilsson wrote: > > > On Mon, Nov 20, 2017 at 10:50:46PM -0500, Nicolas Pitre wrote: > > > On Mon, 20 Nov 2017, Guenter Roeck wrote: > > > > On Mon, Nov 20, 2017 at 07:28:21PM -0500, Nicolas Pitre wrote: > > > > > On Mon, 20 Nov 2017, Guenter Roeck wrote: > > > > > > > > > > > bdata->node_min_pfn=6 PFN_PHYS(bdata->node_min_pfn)=c000 > > > > > > start_off=536000 region=c0536000 > > > > > > > > > > If PFN_PHYS(bdata->node_min_pfn)=c000 and > > > > > region=c0536000 that means phys_to_virt() is a no-op. > > > > > > > > > No, it is |= 0x8000 > > > > > > Then the bootmem registration looks very fishy. If you have: > > > > > > > I think the problem is the 0x6 in bdata->node_min_pfn. It is shifted > > > > left by PFN_PHYS, making it 0xc000, which in my understanding is > > > > a virtual address. > > > > > > Exact. > > > > > > #define __pa(x) ((unsigned long)(x) & 0x7fff) > > > #define __va(x) ((void *)((unsigned long)(x) | > > > 0x8000)) > > > > > > With that, the only possible physical address range you may have is > > > 0x4000 - 0x7fff, and it better start at 0x4000. If that's > > > not where your RAM is then something is wrong. > > > > > > This is in fact a very bad idea to define __va() and __pa() using > > > bitwise operations as this hides mistakes like defining physical RAM > > > address at 0xc000. Instead, it should look like: > > > > > > #define __pa(x) ((unsigned long)(x) - 0x8000) > > > #define __va(x) ((void *)((unsigned long)(x) + > > > 0x8000)) > > > > > > This way, bad physical RAM address definitions will be caught > > > immediately. > > > > > > > That doesn't seem to be easy to fix. It seems there is a mixup of > > > > physical > > > > and virtual addresses in the architecture. > > > > > > Well... I don't think there is much else to say other than this needs > > > fixing. > > > > The memory map for the ETRAX FS has the SDRAM mapped at both > > 0x4000-0x7fff > > and 0xc000-0x, and the difference is cached and non-cached. > > That is actively (ab)used in the port, unfortunately, allthough I'm > > uncertain if this is the problem in this case. > > It certainly is a problem. If your cached RAM is physically mapped at > 0xc000 and you want it to be virtually mapped at 0xc000 then you > should have: > > #define __pa(x) ((unsigned long)(x)) > #define __va(x) ((void *)(x)) > > i.e. no translation. Sorry, it's the other way around, cached memory is at 0x4000 and non-cached is at 0xc000, so the translation is right, even if as you pointed out earlier, it should be performed differently. > For non-cached RAM access, there are specific > interfaces for that. For example, you could have dma_alloc_coherent() > take advantage of the fact that memory with the top bit cleared becomes > uncached. But __pa() is the wrong interface for obtaining uncached > memory. > > Nicolas /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: mm/percpu.c: use smarter memory allocation for struct pcpu_alloc_info (crisv32 hang)
On Wed, Nov 22, 2017 at 03:17:00PM -0500, Nicolas Pitre wrote: > On Wed, 22 Nov 2017, Jesper Nilsson wrote: > > > On Mon, Nov 20, 2017 at 10:50:46PM -0500, Nicolas Pitre wrote: > > > On Mon, 20 Nov 2017, Guenter Roeck wrote: > > > > On Mon, Nov 20, 2017 at 07:28:21PM -0500, Nicolas Pitre wrote: > > > > > On Mon, 20 Nov 2017, Guenter Roeck wrote: > > > > > > > > > > > bdata->node_min_pfn=6 PFN_PHYS(bdata->node_min_pfn)=c000 > > > > > > start_off=536000 region=c0536000 > > > > > > > > > > If PFN_PHYS(bdata->node_min_pfn)=c000 and > > > > > region=c0536000 that means phys_to_virt() is a no-op. > > > > > > > > > No, it is |= 0x8000 > > > > > > Then the bootmem registration looks very fishy. If you have: > > > > > > > I think the problem is the 0x6 in bdata->node_min_pfn. It is shifted > > > > left by PFN_PHYS, making it 0xc000, which in my understanding is > > > > a virtual address. > > > > > > Exact. > > > > > > #define __pa(x) ((unsigned long)(x) & 0x7fff) > > > #define __va(x) ((void *)((unsigned long)(x) | > > > 0x8000)) > > > > > > With that, the only possible physical address range you may have is > > > 0x4000 - 0x7fff, and it better start at 0x4000. If that's > > > not where your RAM is then something is wrong. > > > > > > This is in fact a very bad idea to define __va() and __pa() using > > > bitwise operations as this hides mistakes like defining physical RAM > > > address at 0xc000. Instead, it should look like: > > > > > > #define __pa(x) ((unsigned long)(x) - 0x8000) > > > #define __va(x) ((void *)((unsigned long)(x) + > > > 0x8000)) > > > > > > This way, bad physical RAM address definitions will be caught > > > immediately. > > > > > > > That doesn't seem to be easy to fix. It seems there is a mixup of > > > > physical > > > > and virtual addresses in the architecture. > > > > > > Well... I don't think there is much else to say other than this needs > > > fixing. > > > > The memory map for the ETRAX FS has the SDRAM mapped at both > > 0x4000-0x7fff > > and 0xc000-0x, and the difference is cached and non-cached. > > That is actively (ab)used in the port, unfortunately, allthough I'm > > uncertain if this is the problem in this case. > > It certainly is a problem. If your cached RAM is physically mapped at > 0xc000 and you want it to be virtually mapped at 0xc000 then you > should have: > > #define __pa(x) ((unsigned long)(x)) > #define __va(x) ((void *)(x)) > > i.e. no translation. Sorry, it's the other way around, cached memory is at 0x4000 and non-cached is at 0xc000, so the translation is right, even if as you pointed out earlier, it should be performed differently. > For non-cached RAM access, there are specific > interfaces for that. For example, you could have dma_alloc_coherent() > take advantage of the fact that memory with the top bit cleared becomes > uncached. But __pa() is the wrong interface for obtaining uncached > memory. > > Nicolas /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: mm/percpu.c: use smarter memory allocation for struct pcpu_alloc_info (crisv32 hang)
On Mon, Nov 20, 2017 at 10:50:46PM -0500, Nicolas Pitre wrote: > On Mon, 20 Nov 2017, Guenter Roeck wrote: > > On Mon, Nov 20, 2017 at 07:28:21PM -0500, Nicolas Pitre wrote: > > > On Mon, 20 Nov 2017, Guenter Roeck wrote: > > > > > > > bdata->node_min_pfn=6 PFN_PHYS(bdata->node_min_pfn)=c000 > > > > start_off=536000 region=c0536000 > > > > > > If PFN_PHYS(bdata->node_min_pfn)=c000 and > > > region=c0536000 that means phys_to_virt() is a no-op. > > > > > No, it is |= 0x8000 > > Then the bootmem registration looks very fishy. If you have: > > > I think the problem is the 0x6 in bdata->node_min_pfn. It is shifted > > left by PFN_PHYS, making it 0xc000, which in my understanding is > > a virtual address. > > Exact. > > #define __pa(x) ((unsigned long)(x) & 0x7fff) > #define __va(x) ((void *)((unsigned long)(x) | 0x8000)) > > With that, the only possible physical address range you may have is > 0x4000 - 0x7fff, and it better start at 0x4000. If that's > not where your RAM is then something is wrong. > > This is in fact a very bad idea to define __va() and __pa() using > bitwise operations as this hides mistakes like defining physical RAM > address at 0xc000. Instead, it should look like: > > #define __pa(x) ((unsigned long)(x) - 0x8000) > #define __va(x) ((void *)((unsigned long)(x) + 0x8000)) > > This way, bad physical RAM address definitions will be caught > immediately. > > > That doesn't seem to be easy to fix. It seems there is a mixup of physical > > and virtual addresses in the architecture. > > Well... I don't think there is much else to say other than this needs > fixing. The memory map for the ETRAX FS has the SDRAM mapped at both 0x4000-0x7fff and 0xc000-0x, and the difference is cached and non-cached. That is actively (ab)used in the port, unfortunately, allthough I'm uncertain if this is the problem in this case. I get the same behaviour in my QEMU, but I've not been able to make sense of anything yet... > Nicolas /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: mm/percpu.c: use smarter memory allocation for struct pcpu_alloc_info (crisv32 hang)
On Mon, Nov 20, 2017 at 10:50:46PM -0500, Nicolas Pitre wrote: > On Mon, 20 Nov 2017, Guenter Roeck wrote: > > On Mon, Nov 20, 2017 at 07:28:21PM -0500, Nicolas Pitre wrote: > > > On Mon, 20 Nov 2017, Guenter Roeck wrote: > > > > > > > bdata->node_min_pfn=6 PFN_PHYS(bdata->node_min_pfn)=c000 > > > > start_off=536000 region=c0536000 > > > > > > If PFN_PHYS(bdata->node_min_pfn)=c000 and > > > region=c0536000 that means phys_to_virt() is a no-op. > > > > > No, it is |= 0x8000 > > Then the bootmem registration looks very fishy. If you have: > > > I think the problem is the 0x6 in bdata->node_min_pfn. It is shifted > > left by PFN_PHYS, making it 0xc000, which in my understanding is > > a virtual address. > > Exact. > > #define __pa(x) ((unsigned long)(x) & 0x7fff) > #define __va(x) ((void *)((unsigned long)(x) | 0x8000)) > > With that, the only possible physical address range you may have is > 0x4000 - 0x7fff, and it better start at 0x4000. If that's > not where your RAM is then something is wrong. > > This is in fact a very bad idea to define __va() and __pa() using > bitwise operations as this hides mistakes like defining physical RAM > address at 0xc000. Instead, it should look like: > > #define __pa(x) ((unsigned long)(x) - 0x8000) > #define __va(x) ((void *)((unsigned long)(x) + 0x8000)) > > This way, bad physical RAM address definitions will be caught > immediately. > > > That doesn't seem to be easy to fix. It seems there is a mixup of physical > > and virtual addresses in the architecture. > > Well... I don't think there is much else to say other than this needs > fixing. The memory map for the ETRAX FS has the SDRAM mapped at both 0x4000-0x7fff and 0xc000-0x, and the difference is cached and non-cached. That is actively (ab)used in the port, unfortunately, allthough I'm uncertain if this is the problem in this case. I get the same behaviour in my QEMU, but I've not been able to make sense of anything yet... > Nicolas /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH 07/34] cpufreq: cris: remove calls to cpufreq_notify_transition()
On Fri, Aug 16, 2013 at 04:25:04AM +0200, Viresh Kumar wrote:
> Most of the drivers do following in their ->target_index() routines:
>
> struct cpufreq_freqs freqs;
> freqs.old = old freq...
> freqs.new = new freq...
>
> cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
>
> /* Change rate here */
>
> cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
>
> This is replicated over all cpufreq drivers today and there doesn't exists a
> good enough reason why this shouldn't be moved to cpufreq core instead.
>
> Earlier patches have added support in cpufreq core to do cpufreq notification
> on
> frequency change, this one removes it from this driver.
>
> Some related minor cleanups are also done along with it.
>
Acked-by: Jesper Nilsson <jesper.nils...@axis.com>
> Cc: Mikael Starvik <star...@axis.com>
> Cc: linux-cris-ker...@axis.com
> Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
> ---
> drivers/cpufreq/cris-artpec3-cpufreq.c | 8
> drivers/cpufreq/cris-etraxfs-cpufreq.c | 8
> 2 files changed, 16 deletions(-)
>
> diff --git a/drivers/cpufreq/cris-artpec3-cpufreq.c
> b/drivers/cpufreq/cris-artpec3-cpufreq.c
> index dace19d..e31e1e5 100644
> --- a/drivers/cpufreq/cris-artpec3-cpufreq.c
> +++ b/drivers/cpufreq/cris-artpec3-cpufreq.c
> @@ -29,15 +29,9 @@ static unsigned int cris_freq_get_cpu_frequency(unsigned
> int cpu)
>
> static int cris_freq_target(struct cpufreq_policy *policy, unsigned int
> state)
> {
> - struct cpufreq_freqs freqs;
> reg_clkgen_rw_clk_ctrl clk_ctrl;
> clk_ctrl = REG_RD(clkgen, regi_clkgen, rw_clk_ctrl);
>
> - freqs.old = cris_freq_get_cpu_frequency(policy->cpu);
> - freqs.new = cris_freq_table[state].frequency;
> -
> - cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
> -
> local_irq_disable();
>
> /* Even though we may be SMP they will share the same clock
> @@ -50,8 +44,6 @@ static int cris_freq_target(struct cpufreq_policy *policy,
> unsigned int state)
>
> local_irq_enable();
>
> - cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
> -
> return 0;
> }
>
> diff --git a/drivers/cpufreq/cris-etraxfs-cpufreq.c
> b/drivers/cpufreq/cris-etraxfs-cpufreq.c
> index 4d40d9df..9d577d0 100644
> --- a/drivers/cpufreq/cris-etraxfs-cpufreq.c
> +++ b/drivers/cpufreq/cris-etraxfs-cpufreq.c
> @@ -29,15 +29,9 @@ static unsigned int cris_freq_get_cpu_frequency(unsigned
> int cpu)
>
> static int cris_freq_target(struct cpufreq_policy *policy, unsigned int
> state)
> {
> - struct cpufreq_freqs freqs;
> reg_config_rw_clk_ctrl clk_ctrl;
> clk_ctrl = REG_RD(config, regi_config, rw_clk_ctrl);
>
> - freqs.old = cris_freq_get_cpu_frequency(policy->cpu);
> - freqs.new = cris_freq_table[state].frequency;
> -
> - cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
> -
> local_irq_disable();
>
> /* Even though we may be SMP they will share the same clock
> @@ -50,8 +44,6 @@ static int cris_freq_target(struct cpufreq_policy *policy,
> unsigned int state)
>
> local_irq_enable();
>
> - cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
> -
> return 0;
> }
>
> --
> 1.7.12.rc2.18.g61b472e
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH 07/34] cpufreq: cris: remove calls to cpufreq_notify_transition()
On Fri, Aug 16, 2013 at 04:25:04AM +0200, Viresh Kumar wrote:
> Most of the drivers do following in their ->target_index() routines:
>
> struct cpufreq_freqs freqs;
> freqs.old = old freq...
> freqs.new = new freq...
>
> cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
>
> /* Change rate here */
>
> cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
>
> This is replicated over all cpufreq drivers today and there doesn't exists a
> good enough reason why this shouldn't be moved to cpufreq core instead.
>
> Earlier patches have added support in cpufreq core to do cpufreq notification
> on
> frequency change, this one removes it from this driver.
>
> Some related minor cleanups are also done along with it.
>
Acked-by: Jesper Nilsson
> Cc: Mikael Starvik
> Cc: linux-cris-ker...@axis.com
> Signed-off-by: Viresh Kumar
> ---
> drivers/cpufreq/cris-artpec3-cpufreq.c | 8
> drivers/cpufreq/cris-etraxfs-cpufreq.c | 8
> 2 files changed, 16 deletions(-)
>
> diff --git a/drivers/cpufreq/cris-artpec3-cpufreq.c
> b/drivers/cpufreq/cris-artpec3-cpufreq.c
> index dace19d..e31e1e5 100644
> --- a/drivers/cpufreq/cris-artpec3-cpufreq.c
> +++ b/drivers/cpufreq/cris-artpec3-cpufreq.c
> @@ -29,15 +29,9 @@ static unsigned int cris_freq_get_cpu_frequency(unsigned
> int cpu)
>
> static int cris_freq_target(struct cpufreq_policy *policy, unsigned int
> state)
> {
> - struct cpufreq_freqs freqs;
> reg_clkgen_rw_clk_ctrl clk_ctrl;
> clk_ctrl = REG_RD(clkgen, regi_clkgen, rw_clk_ctrl);
>
> - freqs.old = cris_freq_get_cpu_frequency(policy->cpu);
> - freqs.new = cris_freq_table[state].frequency;
> -
> - cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
> -
> local_irq_disable();
>
> /* Even though we may be SMP they will share the same clock
> @@ -50,8 +44,6 @@ static int cris_freq_target(struct cpufreq_policy *policy,
> unsigned int state)
>
> local_irq_enable();
>
> - cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
> -
> return 0;
> }
>
> diff --git a/drivers/cpufreq/cris-etraxfs-cpufreq.c
> b/drivers/cpufreq/cris-etraxfs-cpufreq.c
> index 4d40d9df..9d577d0 100644
> --- a/drivers/cpufreq/cris-etraxfs-cpufreq.c
> +++ b/drivers/cpufreq/cris-etraxfs-cpufreq.c
> @@ -29,15 +29,9 @@ static unsigned int cris_freq_get_cpu_frequency(unsigned
> int cpu)
>
> static int cris_freq_target(struct cpufreq_policy *policy, unsigned int
> state)
> {
> - struct cpufreq_freqs freqs;
> reg_config_rw_clk_ctrl clk_ctrl;
> clk_ctrl = REG_RD(config, regi_config, rw_clk_ctrl);
>
> - freqs.old = cris_freq_get_cpu_frequency(policy->cpu);
> - freqs.new = cris_freq_table[state].frequency;
> -
> - cpufreq_notify_transition(policy, , CPUFREQ_PRECHANGE);
> -
> local_irq_disable();
>
> /* Even though we may be SMP they will share the same clock
> @@ -50,8 +44,6 @@ static int cris_freq_target(struct cpufreq_policy *policy,
> unsigned int state)
>
> local_irq_enable();
>
> - cpufreq_notify_transition(policy, , CPUFREQ_POSTCHANGE);
> -
> return 0;
> }
>
> --
> 1.7.12.rc2.18.g61b472e
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH -tip v9 3/5] cris: mark _stext and _end as char-arrays, not single char
On Wed, Aug 16, 2017 at 08:01:33PM +0900, Masami Hiramatsu wrote:
> On Thu, 3 Aug 2017 11:37:15 +0900
> Masami Hiramatsu <mhira...@kernel.org> wrote:
>
> > diff --git a/arch/cris/kernel/traps.c b/arch/cris/kernel/traps.c
> > index a01636a12a6e..d98131c45bb5 100644
> > --- a/arch/cris/kernel/traps.c
> > +++ b/arch/cris/kernel/traps.c
> > @@ -42,7 +42,7 @@ void (*nmi_handler)(struct pt_regs *);
> > void show_trace(unsigned long *stack)
> > {
> > unsigned long addr, module_start, module_end;
> > - extern char _stext, _etext;
> > + extern char _stext[], _etext[];
> > int i;
> >
> > pr_err("\nCall Trace: ");
> > @@ -69,8 +69,8 @@ void show_trace(unsigned long *stack)
> > * down the cause of the crash will be able to figure
> > * out the call path that was taken.
> > */
> > - if (((addr >= (unsigned long)&_stext) &&
> > -(addr <= (unsigned long)&_etext)) ||
> > + if (((addr >= (unsigned long)_stext) &&
> > +(addr <= (unsigned long)_etext)) ||
> > ((addr >= module_start) && (addr <= module_end))) {
>
> BTW, I would like to ask cris people, this seems to check over 1 byte,
> since _etext and module_end will be placed at the next byte of the real
> address area.
> As same as other arch, Should it be
>
> (addr < (unsigned long)_etext)
>
> or are there any other reason?
As far as I can tell, this is non-intentional.
> Thank you,
> Masami Hiramatsu <mhira...@kernel.org>
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH -tip v9 3/5] cris: mark _stext and _end as char-arrays, not single char
On Thu, Aug 03, 2017 at 11:37:15AM +0900, Masami Hiramatsu wrote:
> Mark _stext and _end as character arrays instead of single
> character, as same as include/asm-generic/sections.h does.
Looks good.
Acked-by: Jesper Nilsson <jesper.nils...@axis.com>
> Signed-off-by: Masami Hiramatsu <mhira...@kernel.org>
> ---
> arch/cris/arch-v32/mach-a3/arbiter.c |4 ++--
> arch/cris/arch-v32/mach-fs/arbiter.c |4 ++--
> arch/cris/kernel/traps.c |6 +++---
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/cris/arch-v32/mach-a3/arbiter.c
> b/arch/cris/arch-v32/mach-a3/arbiter.c
> index ab5c421a4de8..735a9b0abdb8 100644
> --- a/arch/cris/arch-v32/mach-a3/arbiter.c
> +++ b/arch/cris/arch-v32/mach-a3/arbiter.c
> @@ -227,7 +227,7 @@ static void crisv32_arbiter_config(int arbiter, int
> region, int unused_slots)
> }
> }
>
> -extern char _stext, _etext;
> +extern char _stext[], _etext[];
>
> static void crisv32_arbiter_init(void)
> {
> @@ -265,7 +265,7 @@ static void crisv32_arbiter_init(void)
>
> #ifndef CONFIG_ETRAX_KGDB
> /* Global watch for writes to kernel text segment. */
> - crisv32_arbiter_watch(virt_to_phys(&_stext), &_etext - &_stext,
> + crisv32_arbiter_watch(virt_to_phys(_stext), _etext - _stext,
> MARB_CLIENTS(arbiter_all_clients, arbiter_bar_all_clients),
> arbiter_all_write, NULL);
> #endif
> diff --git a/arch/cris/arch-v32/mach-fs/arbiter.c
> b/arch/cris/arch-v32/mach-fs/arbiter.c
> index c97f4d8120f9..047c70bdbb23 100644
> --- a/arch/cris/arch-v32/mach-fs/arbiter.c
> +++ b/arch/cris/arch-v32/mach-fs/arbiter.c
> @@ -158,7 +158,7 @@ static void crisv32_arbiter_config(int region, int
> unused_slots)
> }
> }
>
> -extern char _stext, _etext;
> +extern char _stext[], _etext[];
>
> static void crisv32_arbiter_init(void)
> {
> @@ -190,7 +190,7 @@ static void crisv32_arbiter_init(void)
>
> #ifndef CONFIG_ETRAX_KGDB
> /* Global watch for writes to kernel text segment. */
> - crisv32_arbiter_watch(virt_to_phys(&_stext), &_etext - &_stext,
> + crisv32_arbiter_watch(virt_to_phys(_stext), _etext - _stext,
> arbiter_all_clients, arbiter_all_write, NULL);
> #endif
> }
> diff --git a/arch/cris/kernel/traps.c b/arch/cris/kernel/traps.c
> index a01636a12a6e..d98131c45bb5 100644
> --- a/arch/cris/kernel/traps.c
> +++ b/arch/cris/kernel/traps.c
> @@ -42,7 +42,7 @@ void (*nmi_handler)(struct pt_regs *);
> void show_trace(unsigned long *stack)
> {
> unsigned long addr, module_start, module_end;
> - extern char _stext, _etext;
> + extern char _stext[], _etext[];
> int i;
>
> pr_err("\nCall Trace: ");
> @@ -69,8 +69,8 @@ void show_trace(unsigned long *stack)
>* down the cause of the crash will be able to figure
>* out the call path that was taken.
>*/
> - if (((addr >= (unsigned long)&_stext) &&
> - (addr <= (unsigned long)&_etext)) ||
> + if (((addr >= (unsigned long)_stext) &&
> + (addr <= (unsigned long)_etext)) ||
> ((addr >= module_start) && (addr <= module_end))) {
> #ifdef CONFIG_KALLSYMS
> print_ip_sym(addr);
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH -tip v9 3/5] cris: mark _stext and _end as char-arrays, not single char
On Wed, Aug 16, 2017 at 08:01:33PM +0900, Masami Hiramatsu wrote:
> On Thu, 3 Aug 2017 11:37:15 +0900
> Masami Hiramatsu wrote:
>
> > diff --git a/arch/cris/kernel/traps.c b/arch/cris/kernel/traps.c
> > index a01636a12a6e..d98131c45bb5 100644
> > --- a/arch/cris/kernel/traps.c
> > +++ b/arch/cris/kernel/traps.c
> > @@ -42,7 +42,7 @@ void (*nmi_handler)(struct pt_regs *);
> > void show_trace(unsigned long *stack)
> > {
> > unsigned long addr, module_start, module_end;
> > - extern char _stext, _etext;
> > + extern char _stext[], _etext[];
> > int i;
> >
> > pr_err("\nCall Trace: ");
> > @@ -69,8 +69,8 @@ void show_trace(unsigned long *stack)
> > * down the cause of the crash will be able to figure
> > * out the call path that was taken.
> > */
> > - if (((addr >= (unsigned long)&_stext) &&
> > -(addr <= (unsigned long)&_etext)) ||
> > + if (((addr >= (unsigned long)_stext) &&
> > +(addr <= (unsigned long)_etext)) ||
> > ((addr >= module_start) && (addr <= module_end))) {
>
> BTW, I would like to ask cris people, this seems to check over 1 byte,
> since _etext and module_end will be placed at the next byte of the real
> address area.
> As same as other arch, Should it be
>
> (addr < (unsigned long)_etext)
>
> or are there any other reason?
As far as I can tell, this is non-intentional.
> Thank you,
> Masami Hiramatsu
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH -tip v9 3/5] cris: mark _stext and _end as char-arrays, not single char
On Thu, Aug 03, 2017 at 11:37:15AM +0900, Masami Hiramatsu wrote:
> Mark _stext and _end as character arrays instead of single
> character, as same as include/asm-generic/sections.h does.
Looks good.
Acked-by: Jesper Nilsson
> Signed-off-by: Masami Hiramatsu
> ---
> arch/cris/arch-v32/mach-a3/arbiter.c |4 ++--
> arch/cris/arch-v32/mach-fs/arbiter.c |4 ++--
> arch/cris/kernel/traps.c |6 +++---
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/cris/arch-v32/mach-a3/arbiter.c
> b/arch/cris/arch-v32/mach-a3/arbiter.c
> index ab5c421a4de8..735a9b0abdb8 100644
> --- a/arch/cris/arch-v32/mach-a3/arbiter.c
> +++ b/arch/cris/arch-v32/mach-a3/arbiter.c
> @@ -227,7 +227,7 @@ static void crisv32_arbiter_config(int arbiter, int
> region, int unused_slots)
> }
> }
>
> -extern char _stext, _etext;
> +extern char _stext[], _etext[];
>
> static void crisv32_arbiter_init(void)
> {
> @@ -265,7 +265,7 @@ static void crisv32_arbiter_init(void)
>
> #ifndef CONFIG_ETRAX_KGDB
> /* Global watch for writes to kernel text segment. */
> - crisv32_arbiter_watch(virt_to_phys(&_stext), &_etext - &_stext,
> + crisv32_arbiter_watch(virt_to_phys(_stext), _etext - _stext,
> MARB_CLIENTS(arbiter_all_clients, arbiter_bar_all_clients),
> arbiter_all_write, NULL);
> #endif
> diff --git a/arch/cris/arch-v32/mach-fs/arbiter.c
> b/arch/cris/arch-v32/mach-fs/arbiter.c
> index c97f4d8120f9..047c70bdbb23 100644
> --- a/arch/cris/arch-v32/mach-fs/arbiter.c
> +++ b/arch/cris/arch-v32/mach-fs/arbiter.c
> @@ -158,7 +158,7 @@ static void crisv32_arbiter_config(int region, int
> unused_slots)
> }
> }
>
> -extern char _stext, _etext;
> +extern char _stext[], _etext[];
>
> static void crisv32_arbiter_init(void)
> {
> @@ -190,7 +190,7 @@ static void crisv32_arbiter_init(void)
>
> #ifndef CONFIG_ETRAX_KGDB
> /* Global watch for writes to kernel text segment. */
> - crisv32_arbiter_watch(virt_to_phys(&_stext), &_etext - &_stext,
> + crisv32_arbiter_watch(virt_to_phys(_stext), _etext - _stext,
> arbiter_all_clients, arbiter_all_write, NULL);
> #endif
> }
> diff --git a/arch/cris/kernel/traps.c b/arch/cris/kernel/traps.c
> index a01636a12a6e..d98131c45bb5 100644
> --- a/arch/cris/kernel/traps.c
> +++ b/arch/cris/kernel/traps.c
> @@ -42,7 +42,7 @@ void (*nmi_handler)(struct pt_regs *);
> void show_trace(unsigned long *stack)
> {
> unsigned long addr, module_start, module_end;
> - extern char _stext, _etext;
> + extern char _stext[], _etext[];
> int i;
>
> pr_err("\nCall Trace: ");
> @@ -69,8 +69,8 @@ void show_trace(unsigned long *stack)
>* down the cause of the crash will be able to figure
>* out the call path that was taken.
>*/
> - if (((addr >= (unsigned long)&_stext) &&
> - (addr <= (unsigned long)&_etext)) ||
> + if (((addr >= (unsigned long)_stext) &&
> + (addr <= (unsigned long)_etext)) ||
> ((addr >= module_start) && (addr <= module_end))) {
> #ifdef CONFIG_KALLSYMS
> print_ip_sym(addr);
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [RFC][PATCH] UBI: Make MTD_UBI_FASTMAP non-experimental
Hi Richard, I'm still worried about this failure case, do we really believe that the flash could fail in such a way that the fastmap is corrupted in an undetectable way? If we do detect corruption we should be no worse off than earlier since we should ignore the fastmap, IIRC. Could you please elaborate on the problem you were thinking about? Right now I'm hesitant to use fastmap in any production code, even if it works with my current hardware, since there is no guarantee that the flash chips won't get replaced with a second source option down the line... /Jesper On Mon, Apr 03, 2017 at 01:17:36PM +0200, Jesper Nilsson wrote: > Hi Richard, > > On Thu, Mar 30, 2017 at 11:29:15PM +0200, Richard Weinberger wrote: > > Jesper, > > > > Am 30.03.2017 um 19:39 schrieb Jesper Nilsson: > > >> So we should document this with a big fat warning and set fastmap to > > >> default=n ? > > > > > > Does this sound reasonable? > > > > > > Note that this feature makes UBI less robust, since Fastmap does not scan > > > the full flash, which might lead to problems on misbehaving NAND chips. > > > Only enable this if the speedup in attach is really important and > > > > I'm not a native English speaker, but shouldn't this be > > "...if speedup of the attach time is important ..." > > > > > you can be sure that the NAND works as expected. > > > > Looks fine! > > As you saw I resent the patch with this formulation added. > > However, after thinking about it (and with input from some coworkers), > could we pinpoint the failure case a bit more here? > > What is the exact problem behaviour on NAND chips that we're > worried about, and in which case will UBI be less robust if > we don't scan the full flash? > > My first reaction was that this was a natural conclusion, > but if the NAND flash is failing, we should either be in the > case that the FASTMAP is corrupted or that the original data > is corrupted. Both should be found by current implementation. > Or am I missing additional failure cases here? > > I getting a bit worried about using the feature at all, > even if it seems to work right now... > > > Thanks, > > //richard > > /^JN - Jesper Nilsson > -- >Jesper Nilsson -- jesper.nils...@axis.com /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [RFC][PATCH] UBI: Make MTD_UBI_FASTMAP non-experimental
Hi Richard, I'm still worried about this failure case, do we really believe that the flash could fail in such a way that the fastmap is corrupted in an undetectable way? If we do detect corruption we should be no worse off than earlier since we should ignore the fastmap, IIRC. Could you please elaborate on the problem you were thinking about? Right now I'm hesitant to use fastmap in any production code, even if it works with my current hardware, since there is no guarantee that the flash chips won't get replaced with a second source option down the line... /Jesper On Mon, Apr 03, 2017 at 01:17:36PM +0200, Jesper Nilsson wrote: > Hi Richard, > > On Thu, Mar 30, 2017 at 11:29:15PM +0200, Richard Weinberger wrote: > > Jesper, > > > > Am 30.03.2017 um 19:39 schrieb Jesper Nilsson: > > >> So we should document this with a big fat warning and set fastmap to > > >> default=n ? > > > > > > Does this sound reasonable? > > > > > > Note that this feature makes UBI less robust, since Fastmap does not scan > > > the full flash, which might lead to problems on misbehaving NAND chips. > > > Only enable this if the speedup in attach is really important and > > > > I'm not a native English speaker, but shouldn't this be > > "...if speedup of the attach time is important ..." > > > > > you can be sure that the NAND works as expected. > > > > Looks fine! > > As you saw I resent the patch with this formulation added. > > However, after thinking about it (and with input from some coworkers), > could we pinpoint the failure case a bit more here? > > What is the exact problem behaviour on NAND chips that we're > worried about, and in which case will UBI be less robust if > we don't scan the full flash? > > My first reaction was that this was a natural conclusion, > but if the NAND flash is failing, we should either be in the > case that the FASTMAP is corrupted or that the original data > is corrupted. Both should be found by current implementation. > Or am I missing additional failure cases here? > > I getting a bit worried about using the feature at all, > even if it seems to work right now... > > > Thanks, > > //richard > > /^JN - Jesper Nilsson > -- >Jesper Nilsson -- jesper.nils...@axis.com /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH] pinctrl: make artpec6 explicitly non-modular
On Wed, Apr 19, 2017 at 03:59:05PM -0400, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
>
> drivers/pinctrl/Kconfig:config PINCTRL_ARTPEC6
> drivers/pinctrl/Kconfig:bool "Axis ARTPEC-6 pin controller driver"
>
> ...meaning that it currently is not being built as a module by anyone.
>
> Lets remove the modular code that is essentially orphaned, so that
> when reading the driver there is no doubt it is builtin-only.
>
> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
>
> We also delete the MODULE_LICENSE tag etc. since all that information
> is already contained at the top of the file in the comments.
Agreed, building as module is useless for this
central pin controller.
Acked-by: Jesper Nilsson <jesper.nils...@axis.com>
> Cc: Lars Persson <lars.pers...@axis.com>
> Cc: Niklas Cassel <niklas.cas...@axis.com>
> Cc: Linus Walleij <linus.wall...@linaro.org>
> Cc: linux-arm-ker...@axis.com
> Cc: linux-g...@vger.kernel.org
> Signed-off-by: Paul Gortmaker <paul.gortma...@windriver.com>
> ---
> drivers/pinctrl/pinctrl-artpec6.c | 12
> 1 file changed, 12 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-artpec6.c
> b/drivers/pinctrl/pinctrl-artpec6.c
> index b5a2eff7ae3d..2886e77fbcf0 100644
> --- a/drivers/pinctrl/pinctrl-artpec6.c
> +++ b/drivers/pinctrl/pinctrl-artpec6.c
> @@ -12,7 +12,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -979,14 +978,3 @@ static int __init artpec6_pmx_init(void)
> return platform_driver_register(_pmx_driver);
> }
> arch_initcall(artpec6_pmx_init);
> -
> -static void __exit artpec6_pmx_exit(void)
> -{
> - platform_driver_unregister(_pmx_driver);
> -}
> -module_exit(artpec6_pmx_exit);
> -
> -MODULE_AUTHOR("Chris Paterson <chris.pater...@linux.pieboy.co.uk>");
> -MODULE_DESCRIPTION("Axis ARTPEC-6 pin control driver");
> -MODULE_LICENSE("GPL v2");
> -MODULE_DEVICE_TABLE(of, artpec6_pinctrl_match);
> --
> 2.11.0
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH] pinctrl: make artpec6 explicitly non-modular
On Wed, Apr 19, 2017 at 03:59:05PM -0400, Paul Gortmaker wrote:
> The Kconfig currently controlling compilation of this code is:
>
> drivers/pinctrl/Kconfig:config PINCTRL_ARTPEC6
> drivers/pinctrl/Kconfig:bool "Axis ARTPEC-6 pin controller driver"
>
> ...meaning that it currently is not being built as a module by anyone.
>
> Lets remove the modular code that is essentially orphaned, so that
> when reading the driver there is no doubt it is builtin-only.
>
> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
>
> We also delete the MODULE_LICENSE tag etc. since all that information
> is already contained at the top of the file in the comments.
Agreed, building as module is useless for this
central pin controller.
Acked-by: Jesper Nilsson
> Cc: Lars Persson
> Cc: Niklas Cassel
> Cc: Linus Walleij
> Cc: linux-arm-ker...@axis.com
> Cc: linux-g...@vger.kernel.org
> Signed-off-by: Paul Gortmaker
> ---
> drivers/pinctrl/pinctrl-artpec6.c | 12
> 1 file changed, 12 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-artpec6.c
> b/drivers/pinctrl/pinctrl-artpec6.c
> index b5a2eff7ae3d..2886e77fbcf0 100644
> --- a/drivers/pinctrl/pinctrl-artpec6.c
> +++ b/drivers/pinctrl/pinctrl-artpec6.c
> @@ -12,7 +12,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -979,14 +978,3 @@ static int __init artpec6_pmx_init(void)
> return platform_driver_register(_pmx_driver);
> }
> arch_initcall(artpec6_pmx_init);
> -
> -static void __exit artpec6_pmx_exit(void)
> -{
> - platform_driver_unregister(_pmx_driver);
> -}
> -module_exit(artpec6_pmx_exit);
> -
> -MODULE_AUTHOR("Chris Paterson ");
> -MODULE_DESCRIPTION("Axis ARTPEC-6 pin control driver");
> -MODULE_LICENSE("GPL v2");
> -MODULE_DEVICE_TABLE(of, artpec6_pinctrl_match);
> --
> 2.11.0
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH v2 12/27] cris: Use generic pci_mmap_resource_range()
On Wed, Apr 12, 2017 at 01:26:01PM +0100, David Woodhouse wrote:
> From: David Woodhouse <d...@amazon.co.uk>
>
> Signed-off-by: David Woodhouse <d...@amazon.co.uk>
For the CRIS part:
Acked-by: Jesper Nilsson <jesper.nils...@axis.com>
> ---
> arch/cris/arch-v32/drivers/pci/bios.c | 23 ---
> arch/cris/include/asm/pci.h | 1 +
> 2 files changed, 1 insertion(+), 23 deletions(-)
>
> diff --git a/arch/cris/arch-v32/drivers/pci/bios.c
> b/arch/cris/arch-v32/drivers/pci/bios.c
> index a589686d..394c2a73 100644
> --- a/arch/cris/arch-v32/drivers/pci/bios.c
> +++ b/arch/cris/arch-v32/drivers/pci/bios.c
> @@ -14,29 +14,6 @@ void pcibios_set_master(struct pci_dev *dev)
> pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat);
> }
>
> -int pci_mmap_page_range(struct pci_dev *dev, int bar,
> - struct vm_area_struct *vma,
> - enum pci_mmap_state mmap_state, int write_combine)
> -{
> - unsigned long prot;
> -
> - /* Leave vm_pgoff as-is, the PCI space address is the physical
> - * address on this platform.
> - */
> - prot = pgprot_val(vma->vm_page_prot);
> - vma->vm_page_prot = __pgprot(prot);
> -
> - /* Write-combine setting is ignored, it is changed via the mtrr
> - * interfaces on this platform.
> - */
> - if (remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
> - vma->vm_end - vma->vm_start,
> - vma->vm_page_prot))
> - return -EAGAIN;
> -
> - return 0;
> -}
> -
> resource_size_t
> pcibios_align_resource(void *data, const struct resource *res,
> resource_size_t size, resource_size_t align)
> diff --git a/arch/cris/include/asm/pci.h b/arch/cris/include/asm/pci.h
> index 65198cb..6e50533 100644
> --- a/arch/cris/include/asm/pci.h
> +++ b/arch/cris/include/asm/pci.h
> @@ -42,6 +42,7 @@ struct pci_dev;
> #define PCI_DMA_BUS_IS_PHYS (1)
>
> #define HAVE_PCI_MMAP
> +#define ARCH_GENERIC_PCI_MMAP_RESOURCE
>
> #endif /* __KERNEL__ */
>
> --
> 2.9.3
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH v2 12/27] cris: Use generic pci_mmap_resource_range()
On Wed, Apr 12, 2017 at 01:26:01PM +0100, David Woodhouse wrote:
> From: David Woodhouse
>
> Signed-off-by: David Woodhouse
For the CRIS part:
Acked-by: Jesper Nilsson
> ---
> arch/cris/arch-v32/drivers/pci/bios.c | 23 ---
> arch/cris/include/asm/pci.h | 1 +
> 2 files changed, 1 insertion(+), 23 deletions(-)
>
> diff --git a/arch/cris/arch-v32/drivers/pci/bios.c
> b/arch/cris/arch-v32/drivers/pci/bios.c
> index a589686d..394c2a73 100644
> --- a/arch/cris/arch-v32/drivers/pci/bios.c
> +++ b/arch/cris/arch-v32/drivers/pci/bios.c
> @@ -14,29 +14,6 @@ void pcibios_set_master(struct pci_dev *dev)
> pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat);
> }
>
> -int pci_mmap_page_range(struct pci_dev *dev, int bar,
> - struct vm_area_struct *vma,
> - enum pci_mmap_state mmap_state, int write_combine)
> -{
> - unsigned long prot;
> -
> - /* Leave vm_pgoff as-is, the PCI space address is the physical
> - * address on this platform.
> - */
> - prot = pgprot_val(vma->vm_page_prot);
> - vma->vm_page_prot = __pgprot(prot);
> -
> - /* Write-combine setting is ignored, it is changed via the mtrr
> - * interfaces on this platform.
> - */
> - if (remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
> - vma->vm_end - vma->vm_start,
> - vma->vm_page_prot))
> - return -EAGAIN;
> -
> - return 0;
> -}
> -
> resource_size_t
> pcibios_align_resource(void *data, const struct resource *res,
> resource_size_t size, resource_size_t align)
> diff --git a/arch/cris/include/asm/pci.h b/arch/cris/include/asm/pci.h
> index 65198cb..6e50533 100644
> --- a/arch/cris/include/asm/pci.h
> +++ b/arch/cris/include/asm/pci.h
> @@ -42,6 +42,7 @@ struct pci_dev;
> #define PCI_DMA_BUS_IS_PHYS (1)
>
> #define HAVE_PCI_MMAP
> +#define ARCH_GENERIC_PCI_MMAP_RESOURCE
>
> #endif /* __KERNEL__ */
>
> --
> 2.9.3
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH v3 08/32] cris: include default ioremap_nopost() implementation
On Tue, Apr 11, 2017 at 01:28:48PM +0100, Lorenzo Pieralisi wrote: > The PCI specifications (Rev 3.0, 3.2.5 "Transaction Ordering and Posting") > mandate non-posted configuration transactions. As further highlighted in > the PCIe specifications (4.0 - Rev0.3, "Ordering Considerations for the > Enhanced Configuration Access Mechanism"), through ECAM and > ECAM-derivative configuration mechanism, the memory mapped transactions > from the host CPU into Configuration Requests on the PCI express fabric > may create ordering problems for software because writes to memory > address are typically posted transactions (unless the architecture can > enforce through virtual address mapping non-posted write transactions > behaviour) but writes to Configuration Space are not posted on the PCI > express fabric. > > Include the asm-generic ioremap_nopost() implementation (currently > falling back to ioremap_nocache()) to provide a non-posted writes > ioremap interface to kernel subsystems. > > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieral...@arm.com> > Cc: Niklas Cassel <n...@flawful.org> > Cc: Bjorn Helgaas <bhelg...@google.com> For the CRIS-part: Acked-by: Jesper Nilsson <jesper.nils...@axis.com> /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH v3 08/32] cris: include default ioremap_nopost() implementation
On Tue, Apr 11, 2017 at 01:28:48PM +0100, Lorenzo Pieralisi wrote: > The PCI specifications (Rev 3.0, 3.2.5 "Transaction Ordering and Posting") > mandate non-posted configuration transactions. As further highlighted in > the PCIe specifications (4.0 - Rev0.3, "Ordering Considerations for the > Enhanced Configuration Access Mechanism"), through ECAM and > ECAM-derivative configuration mechanism, the memory mapped transactions > from the host CPU into Configuration Requests on the PCI express fabric > may create ordering problems for software because writes to memory > address are typically posted transactions (unless the architecture can > enforce through virtual address mapping non-posted write transactions > behaviour) but writes to Configuration Space are not posted on the PCI > express fabric. > > Include the asm-generic ioremap_nopost() implementation (currently > falling back to ioremap_nocache()) to provide a non-posted writes > ioremap interface to kernel subsystems. > > Signed-off-by: Lorenzo Pieralisi > Cc: Niklas Cassel > Cc: Bjorn Helgaas For the CRIS-part: Acked-by: Jesper Nilsson /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH v2] cris: remove unused wp_works_ok macro
On Wed, Apr 05, 2017 at 09:24:35PM +0200, Mathias Krause wrote: > It had no use since it's introduction in v2.4.1.2. Get rid of it. > > Cc: Mikael Starvik <star...@axis.com> > Signed-off-by: Mathias Krause <mini...@googlemail.com> > Acked-by: Jesper Nilsson <jesper.nils...@axis.com> > --- > Same patch as v1 but as the tip folks took only the x86 parts, I think, > this one should go through the CRIS tree. Allright, I'll take it through the CRIS tree. Thanks, > Cheers, > Mathias /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH v2] cris: remove unused wp_works_ok macro
On Wed, Apr 05, 2017 at 09:24:35PM +0200, Mathias Krause wrote: > It had no use since it's introduction in v2.4.1.2. Get rid of it. > > Cc: Mikael Starvik > Signed-off-by: Mathias Krause > Acked-by: Jesper Nilsson > --- > Same patch as v1 but as the tip folks took only the x86 parts, I think, > this one should go through the CRIS tree. Allright, I'll take it through the CRIS tree. Thanks, > Cheers, > Mathias /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
[PATCH 2/3 v2] pinctrl: Add pincontrol driver for ARTPEC-6 SoC
Add pinctrl driver support for the Axis ARTPEC-6 SoC.
There are only some pins that actually have different
functions available, but all can control bias (pull-up/-down)
and drive strength.
Code originally written by Chris Paterson.
Signed-off-by: Jesper Nilsson <jesper.nils...@axis.com>
---
Changes since v1:
- Get rid of the artpec-6 pinctrl header
- Replace the register arrays with a function that maps
from pin number to the register offset.
- Cleanup duplicate information in artpec6_pin_groups array
MAINTAINERS | 1 +
drivers/pinctrl/Kconfig | 11 +
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/pinctrl-artpec6.c | 992 ++
4 files changed, 1005 insertions(+)
create mode 100644 drivers/pinctrl/pinctrl-artpec6.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 7563bd6fdfbe..d2b2449c3f4f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1088,6 +1088,7 @@ L:linux-arm-ker...@axis.com
F: arch/arm/mach-artpec
F: arch/arm/boot/dts/artpec6*
F: drivers/clk/axis
+F: drivers/pinctrl/pinctrl-artpec*
F: Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
ARM/ASPEED MACHINE SUPPORT
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 8f8c2af45781..37af5e3029d5 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -41,6 +41,17 @@ config PINCTRL_ADI2
future processors. This option is selected automatically when specific
machine and arch are selected to build.
+config PINCTRL_ARTPEC6
+bool "Axis ARTPEC-6 pin controller driver"
+depends on MACH_ARTPEC6
+select PINMUX
+select GENERIC_PINCONF
+help
+ This is the driver for the Axis ARTPEC-6 pin controller. This driver
+ supports pin function multiplexing as well as pin bias and drive
+ strength configuration. Device tree integration instructions can be
+ found in
Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
+
config PINCTRL_AS3722
tristate "Pinctrl and GPIO driver for ams AS3722 PMIC"
depends on MFD_AS3722 && GPIOLIB
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index a251f439626f..5fc3c1ddd86f 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_PINCONF) += pinconf.o
obj-$(CONFIG_OF) += devicetree.o
obj-$(CONFIG_GENERIC_PINCONF) += pinconf-generic.o
obj-$(CONFIG_PINCTRL_ADI2) += pinctrl-adi2.o
+obj-$(CONFIG_PINCTRL_ARTPEC6) += pinctrl-artpec6.o
obj-$(CONFIG_PINCTRL_AS3722) += pinctrl-as3722.o
obj-$(CONFIG_PINCTRL_BF54x)+= pinctrl-adi2-bf54x.o
obj-$(CONFIG_PINCTRL_BF60x)+= pinctrl-adi2-bf60x.o
diff --git a/drivers/pinctrl/pinctrl-artpec6.c
b/drivers/pinctrl/pinctrl-artpec6.c
new file mode 100644
index ..b5a2eff7ae3d
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-artpec6.c
@@ -0,0 +1,992 @@
+/*
+ * Driver for the Axis ARTPEC-6 pin controller
+ *
+ * Author: Chris Paterson <chris.pater...@linux.pieboy.co.uk>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "core.h"
+#include "pinconf.h"
+#include "pinctrl-utils.h"
+
+#define ARTPEC6_LAST_PIN 97 /* 97 pins in pinmux */
+#define ARTPEC6_MAX_MUXABLE35 /* Last pin with muxable function */
+
+/* Pinmux control register bit definitions */
+#define ARTPEC6_PINMUX_UDC0_MASK 0x0001
+#define ARTPEC6_PINMUX_UDC0_SHIFT 0
+#define ARTPEC6_PINMUX_UDC1_MASK 0x0002
+#define ARTPEC6_PINMUX_UDC1_SHIFT 1
+#define ARTPEC6_PINMUX_DRV_MASK0x0060
+#define ARTPEC6_PINMUX_DRV_SHIFT 5
+#define ARTPEC6_PINMUX_SEL_MASK0x3000
+#define ARTPEC6_PINMUX_SEL_SHIFT 12
+
+/* Pinmux configurations */
+#define ARTPEC6_CONFIG_0 0
+#define ARTPEC6_CONFIG_1 1
+#define ARTPEC6_CONFIG_2 2
+#define ARTPEC6_CONFIG_3 3
+
+/* Pin drive strength options */
+#define ARTPEC6_DRIVE_4mA 4
+#define ARTPEC6_DRIVE_4mA_SET 0
+#define ARTPEC6_DRIVE_6mA 6
+#define ARTPEC6_DRIVE_6mA_SET 1
+#define ARTPEC6_DRIVE_8mA 8
+#define ARTPEC6_DRIVE_8mA_SET 2
+#define ARTPEC6_DRIVE_9mA 9
+#define ARTPEC6_DRIVE_9mA_SET 3
+
+struct artpec6_pmx {
+ struct device *dev;
+ struct pinctrl_dev *pctl;
+ void __iomem*base;
+ struct pinctrl_pin_desc *pins;
+ unsigned intnum
[PATCH 2/3 v2] pinctrl: Add pincontrol driver for ARTPEC-6 SoC
Add pinctrl driver support for the Axis ARTPEC-6 SoC.
There are only some pins that actually have different
functions available, but all can control bias (pull-up/-down)
and drive strength.
Code originally written by Chris Paterson.
Signed-off-by: Jesper Nilsson
---
Changes since v1:
- Get rid of the artpec-6 pinctrl header
- Replace the register arrays with a function that maps
from pin number to the register offset.
- Cleanup duplicate information in artpec6_pin_groups array
MAINTAINERS | 1 +
drivers/pinctrl/Kconfig | 11 +
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/pinctrl-artpec6.c | 992 ++
4 files changed, 1005 insertions(+)
create mode 100644 drivers/pinctrl/pinctrl-artpec6.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 7563bd6fdfbe..d2b2449c3f4f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1088,6 +1088,7 @@ L:linux-arm-ker...@axis.com
F: arch/arm/mach-artpec
F: arch/arm/boot/dts/artpec6*
F: drivers/clk/axis
+F: drivers/pinctrl/pinctrl-artpec*
F: Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
ARM/ASPEED MACHINE SUPPORT
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 8f8c2af45781..37af5e3029d5 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -41,6 +41,17 @@ config PINCTRL_ADI2
future processors. This option is selected automatically when specific
machine and arch are selected to build.
+config PINCTRL_ARTPEC6
+bool "Axis ARTPEC-6 pin controller driver"
+depends on MACH_ARTPEC6
+select PINMUX
+select GENERIC_PINCONF
+help
+ This is the driver for the Axis ARTPEC-6 pin controller. This driver
+ supports pin function multiplexing as well as pin bias and drive
+ strength configuration. Device tree integration instructions can be
+ found in
Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
+
config PINCTRL_AS3722
tristate "Pinctrl and GPIO driver for ams AS3722 PMIC"
depends on MFD_AS3722 && GPIOLIB
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index a251f439626f..5fc3c1ddd86f 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_PINCONF) += pinconf.o
obj-$(CONFIG_OF) += devicetree.o
obj-$(CONFIG_GENERIC_PINCONF) += pinconf-generic.o
obj-$(CONFIG_PINCTRL_ADI2) += pinctrl-adi2.o
+obj-$(CONFIG_PINCTRL_ARTPEC6) += pinctrl-artpec6.o
obj-$(CONFIG_PINCTRL_AS3722) += pinctrl-as3722.o
obj-$(CONFIG_PINCTRL_BF54x)+= pinctrl-adi2-bf54x.o
obj-$(CONFIG_PINCTRL_BF60x)+= pinctrl-adi2-bf60x.o
diff --git a/drivers/pinctrl/pinctrl-artpec6.c
b/drivers/pinctrl/pinctrl-artpec6.c
new file mode 100644
index ..b5a2eff7ae3d
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-artpec6.c
@@ -0,0 +1,992 @@
+/*
+ * Driver for the Axis ARTPEC-6 pin controller
+ *
+ * Author: Chris Paterson
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "core.h"
+#include "pinconf.h"
+#include "pinctrl-utils.h"
+
+#define ARTPEC6_LAST_PIN 97 /* 97 pins in pinmux */
+#define ARTPEC6_MAX_MUXABLE35 /* Last pin with muxable function */
+
+/* Pinmux control register bit definitions */
+#define ARTPEC6_PINMUX_UDC0_MASK 0x0001
+#define ARTPEC6_PINMUX_UDC0_SHIFT 0
+#define ARTPEC6_PINMUX_UDC1_MASK 0x0002
+#define ARTPEC6_PINMUX_UDC1_SHIFT 1
+#define ARTPEC6_PINMUX_DRV_MASK0x0060
+#define ARTPEC6_PINMUX_DRV_SHIFT 5
+#define ARTPEC6_PINMUX_SEL_MASK0x3000
+#define ARTPEC6_PINMUX_SEL_SHIFT 12
+
+/* Pinmux configurations */
+#define ARTPEC6_CONFIG_0 0
+#define ARTPEC6_CONFIG_1 1
+#define ARTPEC6_CONFIG_2 2
+#define ARTPEC6_CONFIG_3 3
+
+/* Pin drive strength options */
+#define ARTPEC6_DRIVE_4mA 4
+#define ARTPEC6_DRIVE_4mA_SET 0
+#define ARTPEC6_DRIVE_6mA 6
+#define ARTPEC6_DRIVE_6mA_SET 1
+#define ARTPEC6_DRIVE_8mA 8
+#define ARTPEC6_DRIVE_8mA_SET 2
+#define ARTPEC6_DRIVE_9mA 9
+#define ARTPEC6_DRIVE_9mA_SET 3
+
+struct artpec6_pmx {
+ struct device *dev;
+ struct pinctrl_dev *pctl;
+ void __iomem*base;
+ struct pinctrl_pin_desc *pins;
+ unsigned intnum_pins;
+ const struct artpec6_pin_group *pin_groups;
+
Re: [RFC][PATCH] UBI: Make MTD_UBI_FASTMAP non-experimental
Hi Richard, On Thu, Mar 30, 2017 at 11:29:15PM +0200, Richard Weinberger wrote: > Jesper, > > Am 30.03.2017 um 19:39 schrieb Jesper Nilsson: > >> So we should document this with a big fat warning and set fastmap to > >> default=n ? > > > > Does this sound reasonable? > > > > Note that this feature makes UBI less robust, since Fastmap does not scan > > the full flash, which might lead to problems on misbehaving NAND chips. > > Only enable this if the speedup in attach is really important and > > I'm not a native English speaker, but shouldn't this be > "...if speedup of the attach time is important ..." > > > you can be sure that the NAND works as expected. > > Looks fine! As you saw I resent the patch with this formulation added. However, after thinking about it (and with input from some coworkers), could we pinpoint the failure case a bit more here? What is the exact problem behaviour on NAND chips that we're worried about, and in which case will UBI be less robust if we don't scan the full flash? My first reaction was that this was a natural conclusion, but if the NAND flash is failing, we should either be in the case that the FASTMAP is corrupted or that the original data is corrupted. Both should be found by current implementation. Or am I missing additional failure cases here? I getting a bit worried about using the feature at all, even if it seems to work right now... > Thanks, > //richard /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [RFC][PATCH] UBI: Make MTD_UBI_FASTMAP non-experimental
Hi Richard, On Thu, Mar 30, 2017 at 11:29:15PM +0200, Richard Weinberger wrote: > Jesper, > > Am 30.03.2017 um 19:39 schrieb Jesper Nilsson: > >> So we should document this with a big fat warning and set fastmap to > >> default=n ? > > > > Does this sound reasonable? > > > > Note that this feature makes UBI less robust, since Fastmap does not scan > > the full flash, which might lead to problems on misbehaving NAND chips. > > Only enable this if the speedup in attach is really important and > > I'm not a native English speaker, but shouldn't this be > "...if speedup of the attach time is important ..." > > > you can be sure that the NAND works as expected. > > Looks fine! As you saw I resent the patch with this formulation added. However, after thinking about it (and with input from some coworkers), could we pinpoint the failure case a bit more here? What is the exact problem behaviour on NAND chips that we're worried about, and in which case will UBI be less robust if we don't scan the full flash? My first reaction was that this was a natural conclusion, but if the NAND flash is failing, we should either be in the case that the FASTMAP is corrupted or that the original data is corrupted. Both should be found by current implementation. Or am I missing additional failure cases here? I getting a bit worried about using the feature at all, even if it seems to work right now... > Thanks, > //richard /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
[PATCH v2] UBI: Make MTD_UBI_FASTMAP non-experimental
MTD_UBI_FASTMAP has been set as experimental since it was merged back in 2012. There hasn't been much change in the format, so we can consider the feature stable and start being careful about breaking the format. (This is somewhat of a pre-requisite for anyone actually using the feature in the real world and depending on it) Drop the experimental note and the warning text about the on-flash format not being finalized, but add a brief warning that Fastmap actually makes UBI less robust. Signed-off-by: Jesper Nilsson <jesper.nils...@axis.com> --- Changes in v2: - Add warning that Fastmap making UBI less robust drivers/mtd/ubi/Kconfig | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig index f0855ce08ed9..8912943b7142 100644 --- a/drivers/mtd/ubi/Kconfig +++ b/drivers/mtd/ubi/Kconfig @@ -57,12 +57,9 @@ config MTD_UBI_BEB_LIMIT Leave the default value if unsure. config MTD_UBI_FASTMAP - bool "UBI Fastmap (Experimental feature)" + bool "UBI Fastmap" default n help - Important: this feature is experimental so far and the on-flash - format for fastmap may change in the next kernel versions - Fastmap is a mechanism which allows attaching an UBI device in nearly constant time. Instead of scanning the whole MTD device it only has to locate a checkpoint (called fastmap) on the device. @@ -74,6 +71,10 @@ config MTD_UBI_FASTMAP images are still usable with UBI implementations without fastmap support. On typical flash devices the whole fastmap fits into one PEB. UBI will reserve PEBs to hold two fastmaps. + Note that this feature makes UBI less robust, since Fastmap does not scan + the full flash, which might lead to problems on misbehaving NAND chips. + Only enable this if speedup of the attach time is really important + and you can be sure that the NAND works as expected. If in doubt, say "N". -- 2.1.4 /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
[PATCH v2] UBI: Make MTD_UBI_FASTMAP non-experimental
MTD_UBI_FASTMAP has been set as experimental since it was merged back in 2012. There hasn't been much change in the format, so we can consider the feature stable and start being careful about breaking the format. (This is somewhat of a pre-requisite for anyone actually using the feature in the real world and depending on it) Drop the experimental note and the warning text about the on-flash format not being finalized, but add a brief warning that Fastmap actually makes UBI less robust. Signed-off-by: Jesper Nilsson --- Changes in v2: - Add warning that Fastmap making UBI less robust drivers/mtd/ubi/Kconfig | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig index f0855ce08ed9..8912943b7142 100644 --- a/drivers/mtd/ubi/Kconfig +++ b/drivers/mtd/ubi/Kconfig @@ -57,12 +57,9 @@ config MTD_UBI_BEB_LIMIT Leave the default value if unsure. config MTD_UBI_FASTMAP - bool "UBI Fastmap (Experimental feature)" + bool "UBI Fastmap" default n help - Important: this feature is experimental so far and the on-flash - format for fastmap may change in the next kernel versions - Fastmap is a mechanism which allows attaching an UBI device in nearly constant time. Instead of scanning the whole MTD device it only has to locate a checkpoint (called fastmap) on the device. @@ -74,6 +71,10 @@ config MTD_UBI_FASTMAP images are still usable with UBI implementations without fastmap support. On typical flash devices the whole fastmap fits into one PEB. UBI will reserve PEBs to hold two fastmaps. + Note that this feature makes UBI less robust, since Fastmap does not scan + the full flash, which might lead to problems on misbehaving NAND chips. + Only enable this if speedup of the attach time is really important + and you can be sure that the NAND works as expected. If in doubt, say "N". -- 2.1.4 /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [RFC][PATCH] UBI: Make MTD_UBI_FASTMAP non-experimental
Hi Richard, Marek, On Thu, Mar 30, 2017 at 12:01:41PM +0200, Marek Vasut wrote: > On 03/29/2017 10:04 PM, Richard Weinberger wrote: > > Jesper, > > > > Am 29.03.2017 um 17:38 schrieb Jesper Nilsson: > >> MTD_UBI_FASTMAP has been set as experimental since it > >> was merged back in 2012. > >> > >> There hasn't been much change in the format, > >> so we can consider the feature stable and start > >> being careful about breaking the format. > >> (This is somewhat of a pre-requisite for anyone actually > >> using the feature in the real world and depending on it) > >> > >> Drop the experimental note and the warning text about > >> the on-flash format not being finalized. > > > > I fully agree, we can drop this note. But we have to add another > > one. > > While Fastmap is a nice feature to speed-up the attach time it > > comes with a cost. It makes UBI less robust. I saw issues > > on NAND chips which misbehaved slightly where UBI was able to > > recover when using a full scan but not when Fastmap was used. > > The UBI full scan code is paranoid and can sort out problems > > very early, with Fastmap enabled you lose this valuable property. > > > > So, users should enable Fastmap only when they absolutely need > > a very fast attach time and be very sure that the NAND works as > > expected. > > So we should document this with a big fat warning and set fastmap to > default=n ? Does this sound reasonable? Note that this feature makes UBI less robust, since Fastmap does not scan the full flash, which might lead to problems on misbehaving NAND chips. Only enable this if the speedup in attach is really important and you can be sure that the NAND works as expected. > Best regards, > Marek Vasut /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [RFC][PATCH] UBI: Make MTD_UBI_FASTMAP non-experimental
Hi Richard, Marek, On Thu, Mar 30, 2017 at 12:01:41PM +0200, Marek Vasut wrote: > On 03/29/2017 10:04 PM, Richard Weinberger wrote: > > Jesper, > > > > Am 29.03.2017 um 17:38 schrieb Jesper Nilsson: > >> MTD_UBI_FASTMAP has been set as experimental since it > >> was merged back in 2012. > >> > >> There hasn't been much change in the format, > >> so we can consider the feature stable and start > >> being careful about breaking the format. > >> (This is somewhat of a pre-requisite for anyone actually > >> using the feature in the real world and depending on it) > >> > >> Drop the experimental note and the warning text about > >> the on-flash format not being finalized. > > > > I fully agree, we can drop this note. But we have to add another > > one. > > While Fastmap is a nice feature to speed-up the attach time it > > comes with a cost. It makes UBI less robust. I saw issues > > on NAND chips which misbehaved slightly where UBI was able to > > recover when using a full scan but not when Fastmap was used. > > The UBI full scan code is paranoid and can sort out problems > > very early, with Fastmap enabled you lose this valuable property. > > > > So, users should enable Fastmap only when they absolutely need > > a very fast attach time and be very sure that the NAND works as > > expected. > > So we should document this with a big fat warning and set fastmap to > default=n ? Does this sound reasonable? Note that this feature makes UBI less robust, since Fastmap does not scan the full flash, which might lead to problems on misbehaving NAND chips. Only enable this if the speedup in attach is really important and you can be sure that the NAND works as expected. > Best regards, > Marek Vasut /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH 2/3] pinctrl: Add pincontrol driver for ARTPEC-6 SoC
On Thu, Mar 30, 2017 at 02:07:33PM +0200, Linus Walleij wrote:
> On Thu, Mar 30, 2017 at 1:33 PM, Jesper Nilsson <jesper.nils...@axis.com>
> wrote:
>
> > Add pinctrl driver support for the Axis ARTPEC-6 SoC.
> > There are only some pins that actually have different
> > functions available, but all can control bias (pull-up/-down)
> > and drive strength.
> > Code originally written by Chris Paterson.
> >
> > Signed-off-by: Jesper Nilsson <jesper.nils...@axis.com>
>
> Very good start, but look at this:
>
> > +#define ARTPEC6_PINMUX_P0_0_CTRL 0x000
> > +#define ARTPEC6_PINMUX_P0_1_CTRL 0x004
> > +#define ARTPEC6_PINMUX_P0_2_CTRL 0x008
> > +#define ARTPEC6_PINMUX_P0_3_CTRL 0x00C
> > +#define ARTPEC6_PINMUX_P0_4_CTRL 0x010
> > +#define ARTPEC6_PINMUX_P0_5_CTRL 0x014
> > +#define ARTPEC6_PINMUX_P0_6_CTRL 0x018
> > +#define ARTPEC6_PINMUX_P0_7_CTRL 0x01C
> > +#define ARTPEC6_PINMUX_P0_8_CTRL 0x020
> > +#define ARTPEC6_PINMUX_P0_9_CTRL 0x024
> > +#define ARTPEC6_PINMUX_P0_10_CTRL 0x028
> > +#define ARTPEC6_PINMUX_P0_11_CTRL 0x02C
> > +#define ARTPEC6_PINMUX_P0_12_CTRL 0x030
> > +#define ARTPEC6_PINMUX_P0_13_CTRL 0x034
> > +#define ARTPEC6_PINMUX_P0_14_CTRL 0x038
> > +#define ARTPEC6_PINMUX_P0_15_CTRL 0x03C
>
> It's pretty clear that the stride is always 4 bytes is it not.
Agreed.
> > +static const unsigned int pin_regs[] = {
> > + ARTPEC6_PINMUX_P0_0_CTRL, /* Pin 0 */
> > + ARTPEC6_PINMUX_P0_1_CTRL,
> > + ARTPEC6_PINMUX_P0_2_CTRL,
> > + ARTPEC6_PINMUX_P0_3_CTRL,
> > + ARTPEC6_PINMUX_P0_4_CTRL,
> > + ARTPEC6_PINMUX_P0_5_CTRL,
> > + ARTPEC6_PINMUX_P0_6_CTRL,
> > + ARTPEC6_PINMUX_P0_7_CTRL,
> > + ARTPEC6_PINMUX_P0_8_CTRL,
> > + ARTPEC6_PINMUX_P0_9_CTRL,
> > + ARTPEC6_PINMUX_P0_10_CTRL,
> > + ARTPEC6_PINMUX_P0_11_CTRL,
> > + ARTPEC6_PINMUX_P0_12_CTRL,
> > + ARTPEC6_PINMUX_P0_13_CTRL,
> > + ARTPEC6_PINMUX_P0_14_CTRL,
> > + ARTPEC6_PINMUX_P0_15_CTRL,
>
> The oceans of redundant information are rising ;)
>
> > +static const unsigned int uart0_regs0[] = {
> > + ARTPEC6_PINMUX_P1_0_CTRL,
> > + ARTPEC6_PINMUX_P1_1_CTRL,
> > + ARTPEC6_PINMUX_P1_2_CTRL,
> > + ARTPEC6_PINMUX_P1_3_CTRL,
> > + ARTPEC6_PINMUX_P1_4_CTRL,
> > + ARTPEC6_PINMUX_P1_5_CTRL,
> > + ARTPEC6_PINMUX_P1_6_CTRL,
> > + ARTPEC6_PINMUX_P1_7_CTRL,
> > + ARTPEC6_PINMUX_P1_8_CTRL,
> > + ARTPEC6_PINMUX_P1_9_CTRL,
> > +};
>
> And rising.
:-)
> > + {
> > + .name = "uart0grp0",
> > + .pins = uart0_pins0,
> > + .num_pins = ARRAY_SIZE(uart0_pins0),
> > + .reg_offsets = uart0_regs0,
> > + .num_regs = ARRAY_SIZE(uart0_regs0),
> > + .config = ARTPEC6_CONFIG_1,
> > + },
>
> So what if the struct artpec6_pin_group...
>
> > +struct artpec6_pin_group {
> > + const char *name;
> > + const unsigned int *pins;
> > + const unsigned int num_pins;
> > + const unsigned int *reg_offsets;
> > + const unsigned int num_regs;
> > + unsigned char config;
> > +};
>
> Instead of reg_offsets had reg_offset_base, and you just
> calculate it with base + pin * 4 when you need it?
Yes, that would be much clearer.
> I also highly suspect that num_pins and num_regs above
> are exactly the same number in all cases, correct? You
> probably only need num_pins.
Agreed.
> > +static struct artpec6_pmx_func artpec6_pmx_functions[] = {
>
> Needs const
>
> > +static void artpec6_pmx_select_func(struct pinctrl_dev *pctldev,
> > + unsigned int function, unsigned int
> > group,
> > + bool enable)
> > +{
> > + unsigned int regval, val;
> > + int i;
> > + const unsigned int *pmx_regs;
> > + struct artpec6_pmx *pmx = pinctrl_dev_get_drvdata(pctldev);
> > +
> > + pmx_regs = artpec6_pin_groups[group].reg_offsets;
> > +
> > + for (i = 0; i < artpec6_pin_groups[group].num_regs; i++) {
> > + /* Ports 4-8 do not have a SEL field and are always
> > selected */
> > + if (pmx_regs[i] >= ARTPEC6_PINMUX_P4_0_CTRL)
> > + conti
Re: [PATCH 2/3] pinctrl: Add pincontrol driver for ARTPEC-6 SoC
On Thu, Mar 30, 2017 at 02:07:33PM +0200, Linus Walleij wrote:
> On Thu, Mar 30, 2017 at 1:33 PM, Jesper Nilsson
> wrote:
>
> > Add pinctrl driver support for the Axis ARTPEC-6 SoC.
> > There are only some pins that actually have different
> > functions available, but all can control bias (pull-up/-down)
> > and drive strength.
> > Code originally written by Chris Paterson.
> >
> > Signed-off-by: Jesper Nilsson
>
> Very good start, but look at this:
>
> > +#define ARTPEC6_PINMUX_P0_0_CTRL 0x000
> > +#define ARTPEC6_PINMUX_P0_1_CTRL 0x004
> > +#define ARTPEC6_PINMUX_P0_2_CTRL 0x008
> > +#define ARTPEC6_PINMUX_P0_3_CTRL 0x00C
> > +#define ARTPEC6_PINMUX_P0_4_CTRL 0x010
> > +#define ARTPEC6_PINMUX_P0_5_CTRL 0x014
> > +#define ARTPEC6_PINMUX_P0_6_CTRL 0x018
> > +#define ARTPEC6_PINMUX_P0_7_CTRL 0x01C
> > +#define ARTPEC6_PINMUX_P0_8_CTRL 0x020
> > +#define ARTPEC6_PINMUX_P0_9_CTRL 0x024
> > +#define ARTPEC6_PINMUX_P0_10_CTRL 0x028
> > +#define ARTPEC6_PINMUX_P0_11_CTRL 0x02C
> > +#define ARTPEC6_PINMUX_P0_12_CTRL 0x030
> > +#define ARTPEC6_PINMUX_P0_13_CTRL 0x034
> > +#define ARTPEC6_PINMUX_P0_14_CTRL 0x038
> > +#define ARTPEC6_PINMUX_P0_15_CTRL 0x03C
>
> It's pretty clear that the stride is always 4 bytes is it not.
Agreed.
> > +static const unsigned int pin_regs[] = {
> > + ARTPEC6_PINMUX_P0_0_CTRL, /* Pin 0 */
> > + ARTPEC6_PINMUX_P0_1_CTRL,
> > + ARTPEC6_PINMUX_P0_2_CTRL,
> > + ARTPEC6_PINMUX_P0_3_CTRL,
> > + ARTPEC6_PINMUX_P0_4_CTRL,
> > + ARTPEC6_PINMUX_P0_5_CTRL,
> > + ARTPEC6_PINMUX_P0_6_CTRL,
> > + ARTPEC6_PINMUX_P0_7_CTRL,
> > + ARTPEC6_PINMUX_P0_8_CTRL,
> > + ARTPEC6_PINMUX_P0_9_CTRL,
> > + ARTPEC6_PINMUX_P0_10_CTRL,
> > + ARTPEC6_PINMUX_P0_11_CTRL,
> > + ARTPEC6_PINMUX_P0_12_CTRL,
> > + ARTPEC6_PINMUX_P0_13_CTRL,
> > + ARTPEC6_PINMUX_P0_14_CTRL,
> > + ARTPEC6_PINMUX_P0_15_CTRL,
>
> The oceans of redundant information are rising ;)
>
> > +static const unsigned int uart0_regs0[] = {
> > + ARTPEC6_PINMUX_P1_0_CTRL,
> > + ARTPEC6_PINMUX_P1_1_CTRL,
> > + ARTPEC6_PINMUX_P1_2_CTRL,
> > + ARTPEC6_PINMUX_P1_3_CTRL,
> > + ARTPEC6_PINMUX_P1_4_CTRL,
> > + ARTPEC6_PINMUX_P1_5_CTRL,
> > + ARTPEC6_PINMUX_P1_6_CTRL,
> > + ARTPEC6_PINMUX_P1_7_CTRL,
> > + ARTPEC6_PINMUX_P1_8_CTRL,
> > + ARTPEC6_PINMUX_P1_9_CTRL,
> > +};
>
> And rising.
:-)
> > + {
> > + .name = "uart0grp0",
> > + .pins = uart0_pins0,
> > + .num_pins = ARRAY_SIZE(uart0_pins0),
> > + .reg_offsets = uart0_regs0,
> > + .num_regs = ARRAY_SIZE(uart0_regs0),
> > + .config = ARTPEC6_CONFIG_1,
> > + },
>
> So what if the struct artpec6_pin_group...
>
> > +struct artpec6_pin_group {
> > + const char *name;
> > + const unsigned int *pins;
> > + const unsigned int num_pins;
> > + const unsigned int *reg_offsets;
> > + const unsigned int num_regs;
> > + unsigned char config;
> > +};
>
> Instead of reg_offsets had reg_offset_base, and you just
> calculate it with base + pin * 4 when you need it?
Yes, that would be much clearer.
> I also highly suspect that num_pins and num_regs above
> are exactly the same number in all cases, correct? You
> probably only need num_pins.
Agreed.
> > +static struct artpec6_pmx_func artpec6_pmx_functions[] = {
>
> Needs const
>
> > +static void artpec6_pmx_select_func(struct pinctrl_dev *pctldev,
> > + unsigned int function, unsigned int
> > group,
> > + bool enable)
> > +{
> > + unsigned int regval, val;
> > + int i;
> > + const unsigned int *pmx_regs;
> > + struct artpec6_pmx *pmx = pinctrl_dev_get_drvdata(pctldev);
> > +
> > + pmx_regs = artpec6_pin_groups[group].reg_offsets;
> > +
> > + for (i = 0; i < artpec6_pin_groups[group].num_regs; i++) {
> > + /* Ports 4-8 do not have a SEL field and are always
> > selected */
> > + if (pmx_regs[i] >= ARTPEC6_PINMUX_P4_0_CTRL)
> > + continue;
> > +
> > + if (!strcmp(artpec6_pmx_get_fname(pctldev,
[PATCH 3/3] ARM: dts: ARTPEC-6: Add pinctrl configuration
Enable the pinctrl driver for ARTPEC-6 in the artpec6.dtsi
with all main pinmux functions.
Add pinctrl information to the relevant (uart) nodes.
Signed-off-by: Jesper Nilsson <jesper.nils...@axis.com>
---
arch/arm/boot/dts/artpec6.dtsi | 87 ++
1 file changed, 87 insertions(+)
diff --git a/arch/arm/boot/dts/artpec6.dtsi b/arch/arm/boot/dts/artpec6.dtsi
index 767cbe8..471eaee 100644
--- a/arch/arm/boot/dts/artpec6.dtsi
+++ b/arch/arm/boot/dts/artpec6.dtsi
@@ -181,6 +181,85 @@
status = "disabled";
};
+ pinctrl: pinctrl@f801d000 {
+ compatible = "axis,artpec6-pinctrl";
+ reg = <0xf801d000 0x400>;
+
+ pinctrl_uart0: uart0grp {
+ function = "uart0";
+ groups = "uart0grp1";
+ bias-pull-up;
+ };
+ pinctrl_uart1: uart1grp {
+ function = "uart1";
+ groups = "uart1grp0";
+ bias-pull-up;
+ };
+ pinctrl_uart2: uart2grp {
+ function = "uart2";
+ groups = "uart2grp1";
+ bias-pull-up;
+ };
+ pinctrl_uart3: uart3grp {
+ function = "uart3";
+ groups = "uart3grp0";
+ bias-pull-up;
+ };
+ pinctrl_uart4: uart4grp {
+ function = "uart4";
+ groups = "uart4grp0";
+ bias-pull-up;
+ };
+ pinctrl_uart5: uart5grp {
+ function = "uart5";
+ groups = "uart5grp0";
+ bias-pull-up;
+ };
+ pinctrl_i2c1: i2c1grp {
+ function = "i2c1";
+ groups = "i2c1grp0";
+ bias-pull-up;
+ };
+ pinctrl_i2c2: i2c2grp {
+ function = "i2c2";
+ groups = "i2c2grp0";
+ bias-pull-up;
+ };
+ pinctrl_i2c3: i2c3grp {
+ function = "i2c3";
+ groups = "i2c3grp0";
+ bias-pull-up;
+ };
+ pinctrl_i2s0: i2s0grp {
+ function = "i2s0";
+ groups = "i2s0grp0";
+ bias-pull-up;
+ };
+ pinctrl_i2s1: i2s1grp {
+ function = "i2s1";
+ groups = "i2s1grp0";
+ bias-pull-up;
+ };
+ pinctrl_spi0: spi0grp {
+ function = "spi0";
+ groups = "spi0grp0";
+ bias-pull-up;
+ };
+ pinctrl_spi1: spi1grp {
+ function = "spi1";
+ groups = "spi1grp0";
+ bias-pull-up;
+ };
+ pinctrl_sdio0: sdio0grp {
+ function = "sdio0";
+ groups = "sdio0grp0";
+ };
+ pinctrl_sdio1: sdio1grp {
+ function = "sdio1";
+ groups = "sdio1grp0";
+ };
+ };
+
amba@0 {
compatible = "simple-bus";
#address-cells = <0x1>;
@@ -214,6 +293,8 @@
clocks = < ARTPEC6_CLK_UART_REFCLK>,
< ARTPEC6_CLK_UART_PCLK>;
clock-names = "uart_clk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart0>;
status = "disabled";
};
uart1: serial@f8037000 {
@@ -223,6 +304,8 @@
clocks = < ARTPEC6_CLK_UART_REFCLK>,
< ARTPEC6_CLK_UART_PCLK>;
clock-names = "uart_clk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart1>;
status = "disabled";
};
uart2: serial@f8038000 {
@@ -232,6 +315,8 @@
clocks = < ARTPEC6_CLK_UART_REFCLK>,
< ARTPEC6_CLK_UART_PCLK>;
cl
[PATCH 3/3] ARM: dts: ARTPEC-6: Add pinctrl configuration
Enable the pinctrl driver for ARTPEC-6 in the artpec6.dtsi
with all main pinmux functions.
Add pinctrl information to the relevant (uart) nodes.
Signed-off-by: Jesper Nilsson
---
arch/arm/boot/dts/artpec6.dtsi | 87 ++
1 file changed, 87 insertions(+)
diff --git a/arch/arm/boot/dts/artpec6.dtsi b/arch/arm/boot/dts/artpec6.dtsi
index 767cbe8..471eaee 100644
--- a/arch/arm/boot/dts/artpec6.dtsi
+++ b/arch/arm/boot/dts/artpec6.dtsi
@@ -181,6 +181,85 @@
status = "disabled";
};
+ pinctrl: pinctrl@f801d000 {
+ compatible = "axis,artpec6-pinctrl";
+ reg = <0xf801d000 0x400>;
+
+ pinctrl_uart0: uart0grp {
+ function = "uart0";
+ groups = "uart0grp1";
+ bias-pull-up;
+ };
+ pinctrl_uart1: uart1grp {
+ function = "uart1";
+ groups = "uart1grp0";
+ bias-pull-up;
+ };
+ pinctrl_uart2: uart2grp {
+ function = "uart2";
+ groups = "uart2grp1";
+ bias-pull-up;
+ };
+ pinctrl_uart3: uart3grp {
+ function = "uart3";
+ groups = "uart3grp0";
+ bias-pull-up;
+ };
+ pinctrl_uart4: uart4grp {
+ function = "uart4";
+ groups = "uart4grp0";
+ bias-pull-up;
+ };
+ pinctrl_uart5: uart5grp {
+ function = "uart5";
+ groups = "uart5grp0";
+ bias-pull-up;
+ };
+ pinctrl_i2c1: i2c1grp {
+ function = "i2c1";
+ groups = "i2c1grp0";
+ bias-pull-up;
+ };
+ pinctrl_i2c2: i2c2grp {
+ function = "i2c2";
+ groups = "i2c2grp0";
+ bias-pull-up;
+ };
+ pinctrl_i2c3: i2c3grp {
+ function = "i2c3";
+ groups = "i2c3grp0";
+ bias-pull-up;
+ };
+ pinctrl_i2s0: i2s0grp {
+ function = "i2s0";
+ groups = "i2s0grp0";
+ bias-pull-up;
+ };
+ pinctrl_i2s1: i2s1grp {
+ function = "i2s1";
+ groups = "i2s1grp0";
+ bias-pull-up;
+ };
+ pinctrl_spi0: spi0grp {
+ function = "spi0";
+ groups = "spi0grp0";
+ bias-pull-up;
+ };
+ pinctrl_spi1: spi1grp {
+ function = "spi1";
+ groups = "spi1grp0";
+ bias-pull-up;
+ };
+ pinctrl_sdio0: sdio0grp {
+ function = "sdio0";
+ groups = "sdio0grp0";
+ };
+ pinctrl_sdio1: sdio1grp {
+ function = "sdio1";
+ groups = "sdio1grp0";
+ };
+ };
+
amba@0 {
compatible = "simple-bus";
#address-cells = <0x1>;
@@ -214,6 +293,8 @@
clocks = < ARTPEC6_CLK_UART_REFCLK>,
< ARTPEC6_CLK_UART_PCLK>;
clock-names = "uart_clk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart0>;
status = "disabled";
};
uart1: serial@f8037000 {
@@ -223,6 +304,8 @@
clocks = < ARTPEC6_CLK_UART_REFCLK>,
< ARTPEC6_CLK_UART_PCLK>;
clock-names = "uart_clk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart1>;
status = "disabled";
};
uart2: serial@f8038000 {
@@ -232,6 +315,8 @@
clocks = < ARTPEC6_CLK_UART_REFCLK>,
< ARTPEC6_CLK_UART_PCLK>;
clock-names = "
[PATCH 2/3] pinctrl: Add pincontrol driver for ARTPEC-6 SoC
Add pinctrl driver support for the Axis ARTPEC-6 SoC.
There are only some pins that actually have different
functions available, but all can control bias (pull-up/-down)
and drive strength.
Code originally written by Chris Paterson.
Signed-off-by: Jesper Nilsson <jesper.nils...@axis.com>
---
MAINTAINERS |1 +
drivers/pinctrl/Kconfig | 11 +
drivers/pinctrl/Makefile |1 +
drivers/pinctrl/pinctrl-artpec6.c | 1279 +
drivers/pinctrl/pinctrl-artpec6.h | 151 +
5 files changed, 1443 insertions(+)
create mode 100644 drivers/pinctrl/pinctrl-artpec6.c
create mode 100644 drivers/pinctrl/pinctrl-artpec6.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 7563bd6..d2b2449 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1088,6 +1088,7 @@ L:linux-arm-ker...@axis.com
F: arch/arm/mach-artpec
F: arch/arm/boot/dts/artpec6*
F: drivers/clk/axis
+F: drivers/pinctrl/pinctrl-artpec*
F: Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
ARM/ASPEED MACHINE SUPPORT
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 8f8c2af..37af5e3 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -41,6 +41,17 @@ config PINCTRL_ADI2
future processors. This option is selected automatically when specific
machine and arch are selected to build.
+config PINCTRL_ARTPEC6
+bool "Axis ARTPEC-6 pin controller driver"
+depends on MACH_ARTPEC6
+select PINMUX
+select GENERIC_PINCONF
+help
+ This is the driver for the Axis ARTPEC-6 pin controller. This driver
+ supports pin function multiplexing as well as pin bias and drive
+ strength configuration. Device tree integration instructions can be
+ found in
Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
+
config PINCTRL_AS3722
tristate "Pinctrl and GPIO driver for ams AS3722 PMIC"
depends on MFD_AS3722 && GPIOLIB
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index a251f43..193dbba 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_PINCONF) += pinconf.o
obj-$(CONFIG_OF) += devicetree.o
obj-$(CONFIG_GENERIC_PINCONF) += pinconf-generic.o
obj-$(CONFIG_PINCTRL_ADI2) += pinctrl-adi2.o
+obj-$(CONFIG_PINCTRL_ARTPEC6) += pinctrl-artpec6.o
obj-$(CONFIG_PINCTRL_AS3722) += pinctrl-as3722.o
obj-$(CONFIG_PINCTRL_BF54x)+= pinctrl-adi2-bf54x.o
obj-$(CONFIG_PINCTRL_BF60x)+= pinctrl-adi2-bf60x.o
diff --git a/drivers/pinctrl/pinctrl-artpec6.c
b/drivers/pinctrl/pinctrl-artpec6.c
new file mode 100644
index 000..ff80c8a
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-artpec6.c
@@ -0,0 +1,1279 @@
+/*
+ * Driver for the Axis ARTPEC-6 pin controller
+ *
+ * Author: Chris Paterson <chris.pater...@linux.pieboy.co.uk>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "core.h"
+#include "pinconf.h"
+#include "pinctrl-utils.h"
+#include "pinctrl-artpec6.h"
+
+struct artpec6_pmx {
+ struct device *dev;
+ struct pinctrl_dev *pctl;
+ void __iomem *base;
+ struct pinctrl_pin_desc *pins;
+ unsigned int num_pins;
+ struct artpec6_pin_group *pin_groups;
+ unsigned int num_pin_groups;
+ struct artpec6_pmx_func *functions;
+ unsigned int num_functions;
+};
+
+struct artpec6_pin_group {
+ const char *name;
+ const unsigned int *pins;
+ const unsigned int num_pins;
+ const unsigned int *reg_offsets;
+ const unsigned int num_regs;
+ unsigned char config;
+};
+
+struct artpec6_pmx_func {
+ const char *name;
+ const char * const *groups;
+ const unsigned int num_groups;
+};
+
+/* pins */
+static struct pinctrl_pin_desc artpec6_pins[] = {
+ PINCTRL_PIN(0, "GPIO0"),
+ PINCTRL_PIN(1, "GPIO1"),
+ PINCTRL_PIN(2, "GPIO2"),
+ PINCTRL_PIN(3, "GPIO3"),
+ PINCTRL_PIN(4, "GPIO4"),
+ PINCTRL_PIN(5, "GPIO5"),
+ PINCTRL_PIN(6, "GPIO6"),
+ PINCTRL_PIN(7, "GPIO7"),
+ PINCTRL_PIN(8, "GPIO8"),
+ PINCTRL_PIN(9, "GPIO9"),
+ PINCTRL_PIN(10, "GPIO10"),
+ PINCTRL_PIN(11, "GPIO11"),
+ PINCTRL_PIN(12, "GPIO12"),
+ PINCTRL_PIN(13, "GPIO13"),
+ PIN
[PATCH 2/3] pinctrl: Add pincontrol driver for ARTPEC-6 SoC
Add pinctrl driver support for the Axis ARTPEC-6 SoC.
There are only some pins that actually have different
functions available, but all can control bias (pull-up/-down)
and drive strength.
Code originally written by Chris Paterson.
Signed-off-by: Jesper Nilsson
---
MAINTAINERS |1 +
drivers/pinctrl/Kconfig | 11 +
drivers/pinctrl/Makefile |1 +
drivers/pinctrl/pinctrl-artpec6.c | 1279 +
drivers/pinctrl/pinctrl-artpec6.h | 151 +
5 files changed, 1443 insertions(+)
create mode 100644 drivers/pinctrl/pinctrl-artpec6.c
create mode 100644 drivers/pinctrl/pinctrl-artpec6.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 7563bd6..d2b2449 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1088,6 +1088,7 @@ L:linux-arm-ker...@axis.com
F: arch/arm/mach-artpec
F: arch/arm/boot/dts/artpec6*
F: drivers/clk/axis
+F: drivers/pinctrl/pinctrl-artpec*
F: Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
ARM/ASPEED MACHINE SUPPORT
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 8f8c2af..37af5e3 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -41,6 +41,17 @@ config PINCTRL_ADI2
future processors. This option is selected automatically when specific
machine and arch are selected to build.
+config PINCTRL_ARTPEC6
+bool "Axis ARTPEC-6 pin controller driver"
+depends on MACH_ARTPEC6
+select PINMUX
+select GENERIC_PINCONF
+help
+ This is the driver for the Axis ARTPEC-6 pin controller. This driver
+ supports pin function multiplexing as well as pin bias and drive
+ strength configuration. Device tree integration instructions can be
+ found in
Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
+
config PINCTRL_AS3722
tristate "Pinctrl and GPIO driver for ams AS3722 PMIC"
depends on MFD_AS3722 && GPIOLIB
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index a251f43..193dbba 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_PINCONF) += pinconf.o
obj-$(CONFIG_OF) += devicetree.o
obj-$(CONFIG_GENERIC_PINCONF) += pinconf-generic.o
obj-$(CONFIG_PINCTRL_ADI2) += pinctrl-adi2.o
+obj-$(CONFIG_PINCTRL_ARTPEC6) += pinctrl-artpec6.o
obj-$(CONFIG_PINCTRL_AS3722) += pinctrl-as3722.o
obj-$(CONFIG_PINCTRL_BF54x)+= pinctrl-adi2-bf54x.o
obj-$(CONFIG_PINCTRL_BF60x)+= pinctrl-adi2-bf60x.o
diff --git a/drivers/pinctrl/pinctrl-artpec6.c
b/drivers/pinctrl/pinctrl-artpec6.c
new file mode 100644
index 000..ff80c8a
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-artpec6.c
@@ -0,0 +1,1279 @@
+/*
+ * Driver for the Axis ARTPEC-6 pin controller
+ *
+ * Author: Chris Paterson
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "core.h"
+#include "pinconf.h"
+#include "pinctrl-utils.h"
+#include "pinctrl-artpec6.h"
+
+struct artpec6_pmx {
+ struct device *dev;
+ struct pinctrl_dev *pctl;
+ void __iomem *base;
+ struct pinctrl_pin_desc *pins;
+ unsigned int num_pins;
+ struct artpec6_pin_group *pin_groups;
+ unsigned int num_pin_groups;
+ struct artpec6_pmx_func *functions;
+ unsigned int num_functions;
+};
+
+struct artpec6_pin_group {
+ const char *name;
+ const unsigned int *pins;
+ const unsigned int num_pins;
+ const unsigned int *reg_offsets;
+ const unsigned int num_regs;
+ unsigned char config;
+};
+
+struct artpec6_pmx_func {
+ const char *name;
+ const char * const *groups;
+ const unsigned int num_groups;
+};
+
+/* pins */
+static struct pinctrl_pin_desc artpec6_pins[] = {
+ PINCTRL_PIN(0, "GPIO0"),
+ PINCTRL_PIN(1, "GPIO1"),
+ PINCTRL_PIN(2, "GPIO2"),
+ PINCTRL_PIN(3, "GPIO3"),
+ PINCTRL_PIN(4, "GPIO4"),
+ PINCTRL_PIN(5, "GPIO5"),
+ PINCTRL_PIN(6, "GPIO6"),
+ PINCTRL_PIN(7, "GPIO7"),
+ PINCTRL_PIN(8, "GPIO8"),
+ PINCTRL_PIN(9, "GPIO9"),
+ PINCTRL_PIN(10, "GPIO10"),
+ PINCTRL_PIN(11, "GPIO11"),
+ PINCTRL_PIN(12, "GPIO12"),
+ PINCTRL_PIN(13, "GPIO13"),
+ PINCTRL_PIN(14, "GPIO14"),
+ PINCTRL_PIN(15, "GPIO15"),
+
[PATCH 1/3] pinctrl: Add bindings for ARTPEC-6 pinmux
Add the bindings for the pinmux functions in the
ARTPEC-6 SoC, including bias and drive strength.
Signed-off-by: Jesper Nilsson <jesper.nils...@axis.com>
---
.../bindings/pinctrl/axis,artpec6-pinctrl.txt | 85 ++
MAINTAINERS| 1 +
2 files changed, 86 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
new file mode 100644
index 000..47284f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
@@ -0,0 +1,85 @@
+Axis ARTPEC-6 Pin Controller
+
+Required properties:
+- compatible: "axis,artpec6-pinctrl".
+- reg: Should contain the register physical address and length for the pin
+ controller.
+
+A pinctrl node should contain at least one subnode representing the pinctrl
+groups available on the machine. Each subnode will list the mux function
+required and what pin group it will use. Each subnode will also configure the
+drive strength and bias pullup of the pin group. If either of these options is
+not set, its actual value will be unspecified.
+
+
+Required subnode-properties:
+- function: Function to mux.
+- groups: Name of the pin group to use for the function above.
+
+ Available functions and groups (function: group0, group1...):
+ gpio: cpuclkoutgrp0, udlclkoutgrp0, i2c1grp0, i2c2grp0,
+ i2c3grp0, i2s0grp0, i2s1grp0, i2srefclkgrp0, spi0grp0,
+ spi1grp0, pciedebuggrp0, uart0grp0, uart0grp1, uart1grp0,
+ uart2grp0, uart2grp1, uart3grp0, uart4grp0, uart5grp0
+ cpuclkout: cpuclkoutgrp0
+ udlclkout: udlclkoutgrp0
+ i2c1: i2c1grp0
+ i2c2: i2c2grp0
+ i2c3: i2c3grp0
+ i2s0: i2s0grp0
+ i2s1: i2s1grp0
+ i2srefclk: i2srefclkgrp0
+ spi0: spi0grp0
+ spi1: spi1grp0
+ pciedebug: pciedebuggrp0
+ uart0: uart0grp0, uart0grp1
+ uart1: uart1grp0
+ uart2: uart2grp0, uart2grp1
+ uart3: uart3grp0
+ uart4: uart4grp0
+ uart5: uart5grp0
+ nand: nandgrp0
+ sdio0: sdio0grp0
+ sdio1: sdio1grp0
+ ethernet: ethernetgrp0
+
+
+Optional subnode-properties (see pinctrl-bindings.txt):
+- drive-strength: 4, 6, 8, 9 mA. For SD and NAND pins, this is for 3.3V VCCQ3.
+- bias-pull-up
+- bias-disable
+
+Examples:
+pinctrl@f801d000 {
+ compatible = "axis,artpec6-pinctrl";
+ reg = <0xf801d000 0x400>;
+
+ pinctrl_uart0: uart0grp {
+ function = "uart0";
+ groups = "uart0grp0";
+ drive-strength = <4>;
+ bias-pull-up;
+ };
+ pinctrl_uart3: uart3grp {
+ function = "uart3";
+ groups = "uart3grp0";
+ };
+};
+uart0: uart@f8036000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0xf8036000 0x1000>;
+ interrupts = <0 104 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <>, <_pclk>;
+ clock-names = "uart_clk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart0>;
+};
+uart3: uart@f8039000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0xf8039000 0x1000>;
+ interrupts = <0 128 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <>, <_pclk>;
+ clock-names = "uart_clk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart3>;
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 1b0a87f..7563bd6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1088,6 +1088,7 @@ L:linux-arm-ker...@axis.com
F: arch/arm/mach-artpec
F: arch/arm/boot/dts/artpec6*
F: drivers/clk/axis
+F: Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
ARM/ASPEED MACHINE SUPPORT
M: Joel Stanley <j...@jms.id.au>
--
2.1.4
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
[PATCH 1/3] pinctrl: Add bindings for ARTPEC-6 pinmux
Add the bindings for the pinmux functions in the
ARTPEC-6 SoC, including bias and drive strength.
Signed-off-by: Jesper Nilsson
---
.../bindings/pinctrl/axis,artpec6-pinctrl.txt | 85 ++
MAINTAINERS| 1 +
2 files changed, 86 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
new file mode 100644
index 000..47284f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
@@ -0,0 +1,85 @@
+Axis ARTPEC-6 Pin Controller
+
+Required properties:
+- compatible: "axis,artpec6-pinctrl".
+- reg: Should contain the register physical address and length for the pin
+ controller.
+
+A pinctrl node should contain at least one subnode representing the pinctrl
+groups available on the machine. Each subnode will list the mux function
+required and what pin group it will use. Each subnode will also configure the
+drive strength and bias pullup of the pin group. If either of these options is
+not set, its actual value will be unspecified.
+
+
+Required subnode-properties:
+- function: Function to mux.
+- groups: Name of the pin group to use for the function above.
+
+ Available functions and groups (function: group0, group1...):
+ gpio: cpuclkoutgrp0, udlclkoutgrp0, i2c1grp0, i2c2grp0,
+ i2c3grp0, i2s0grp0, i2s1grp0, i2srefclkgrp0, spi0grp0,
+ spi1grp0, pciedebuggrp0, uart0grp0, uart0grp1, uart1grp0,
+ uart2grp0, uart2grp1, uart3grp0, uart4grp0, uart5grp0
+ cpuclkout: cpuclkoutgrp0
+ udlclkout: udlclkoutgrp0
+ i2c1: i2c1grp0
+ i2c2: i2c2grp0
+ i2c3: i2c3grp0
+ i2s0: i2s0grp0
+ i2s1: i2s1grp0
+ i2srefclk: i2srefclkgrp0
+ spi0: spi0grp0
+ spi1: spi1grp0
+ pciedebug: pciedebuggrp0
+ uart0: uart0grp0, uart0grp1
+ uart1: uart1grp0
+ uart2: uart2grp0, uart2grp1
+ uart3: uart3grp0
+ uart4: uart4grp0
+ uart5: uart5grp0
+ nand: nandgrp0
+ sdio0: sdio0grp0
+ sdio1: sdio1grp0
+ ethernet: ethernetgrp0
+
+
+Optional subnode-properties (see pinctrl-bindings.txt):
+- drive-strength: 4, 6, 8, 9 mA. For SD and NAND pins, this is for 3.3V VCCQ3.
+- bias-pull-up
+- bias-disable
+
+Examples:
+pinctrl@f801d000 {
+ compatible = "axis,artpec6-pinctrl";
+ reg = <0xf801d000 0x400>;
+
+ pinctrl_uart0: uart0grp {
+ function = "uart0";
+ groups = "uart0grp0";
+ drive-strength = <4>;
+ bias-pull-up;
+ };
+ pinctrl_uart3: uart3grp {
+ function = "uart3";
+ groups = "uart3grp0";
+ };
+};
+uart0: uart@f8036000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0xf8036000 0x1000>;
+ interrupts = <0 104 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <>, <_pclk>;
+ clock-names = "uart_clk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart0>;
+};
+uart3: uart@f8039000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0xf8039000 0x1000>;
+ interrupts = <0 128 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <>, <_pclk>;
+ clock-names = "uart_clk", "apb_pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart3>;
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 1b0a87f..7563bd6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1088,6 +1088,7 @@ L:linux-arm-ker...@axis.com
F: arch/arm/mach-artpec
F: arch/arm/boot/dts/artpec6*
F: drivers/clk/axis
+F: Documentation/devicetree/bindings/pinctrl/axis,artpec6-pinctrl.txt
ARM/ASPEED MACHINE SUPPORT
M: Joel Stanley
--
2.1.4
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
[RFC][PATCH] UBI: Make MTD_UBI_FASTMAP non-experimental
MTD_UBI_FASTMAP has been set as experimental since it was merged back in 2012. There hasn't been much change in the format, so we can consider the feature stable and start being careful about breaking the format. (This is somewhat of a pre-requisite for anyone actually using the feature in the real world and depending on it) Drop the experimental note and the warning text about the on-flash format not being finalized. Signed-off-by: Jesper Nilsson <jesper.nils...@axis.com> --- drivers/mtd/ubi/Kconfig | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig index f0855ce..019e261 100644 --- a/drivers/mtd/ubi/Kconfig +++ b/drivers/mtd/ubi/Kconfig @@ -57,12 +57,9 @@ config MTD_UBI_BEB_LIMIT Leave the default value if unsure. config MTD_UBI_FASTMAP - bool "UBI Fastmap (Experimental feature)" + bool "UBI Fastmap" default n help - Important: this feature is experimental so far and the on-flash - format for fastmap may change in the next kernel versions - Fastmap is a mechanism which allows attaching an UBI device in nearly constant time. Instead of scanning the whole MTD device it only has to locate a checkpoint (called fastmap) on the device. -- 2.1.4 /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
[RFC][PATCH] UBI: Make MTD_UBI_FASTMAP non-experimental
MTD_UBI_FASTMAP has been set as experimental since it
was merged back in 2012.
There hasn't been much change in the format,
so we can consider the feature stable and start
being careful about breaking the format.
(This is somewhat of a pre-requisite for anyone actually
using the feature in the real world and depending on it)
Drop the experimental note and the warning text about
the on-flash format not being finalized.
Signed-off-by: Jesper Nilsson
---
drivers/mtd/ubi/Kconfig | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig
index f0855ce..019e261 100644
--- a/drivers/mtd/ubi/Kconfig
+++ b/drivers/mtd/ubi/Kconfig
@@ -57,12 +57,9 @@ config MTD_UBI_BEB_LIMIT
Leave the default value if unsure.
config MTD_UBI_FASTMAP
- bool "UBI Fastmap (Experimental feature)"
+ bool "UBI Fastmap"
default n
help
- Important: this feature is experimental so far and the on-flash
- format for fastmap may change in the next kernel versions
-
Fastmap is a mechanism which allows attaching an UBI device
in nearly constant time. Instead of scanning the whole MTD device it
only has to locate a checkpoint (called fastmap) on the device.
--
2.1.4
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
[PATCH] ubifs: Don't block RENAME_WHITEOUT flag in rename
The test does not allow the valid flag RENAME_WHITEOUT
and in fact, the calling function of do_rename already tests
the flags, so the test is unnecessary, allowing us to drop
it completely.
With this patch RENAME_WHITEOUT for overlayfs on ubifs works
as intended.
Signed-off-by: Jesper Nilsson <jesper.nils...@axis.com>
---
fs/ubifs/dir.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
index 30825d88..01ab543 100644
--- a/fs/ubifs/dir.c
+++ b/fs/ubifs/dir.c
@@ -1316,9 +1316,6 @@ static int do_rename(struct inode *old_dir, struct dentry
*old_dentry,
unsigned int uninitialized_var(saved_nlink);
struct fscrypt_name old_nm, new_nm;
- if (flags & ~RENAME_NOREPLACE)
- return -EINVAL;
-
/*
* Budget request settings: deletion direntry, new direntry, removing
* the old inode, and changing old and new parent directory inodes.
--
2.1.4
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
[PATCH] ubifs: Don't block RENAME_WHITEOUT flag in rename
The test does not allow the valid flag RENAME_WHITEOUT and in fact, the calling function of do_rename already tests the flags, so the test is unnecessary, allowing us to drop it completely. With this patch RENAME_WHITEOUT for overlayfs on ubifs works as intended. Signed-off-by: Jesper Nilsson --- fs/ubifs/dir.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c index 30825d88..01ab543 100644 --- a/fs/ubifs/dir.c +++ b/fs/ubifs/dir.c @@ -1316,9 +1316,6 @@ static int do_rename(struct inode *old_dir, struct dentry *old_dentry, unsigned int uninitialized_var(saved_nlink); struct fscrypt_name old_nm, new_nm; - if (flags & ~RENAME_NOREPLACE) - return -EINVAL; - /* * Budget request settings: deletion direntry, new direntry, removing * the old inode, and changing old and new parent directory inodes. -- 2.1.4 /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH 11/17] cris: Use generic pci_mmap_resource_range()
On Wed, Mar 22, 2017 at 01:25:25PM +, David Woodhouse wrote:
> From: David Woodhouse <d...@amazon.co.uk>
Acked-by: Jesper Nilsson <jesper.nils...@axis.com>
> Signed-off-by: David Woodhouse <d...@amazon.co.uk>
> ---
> arch/cris/arch-v32/drivers/pci/bios.c | 23 ---
> arch/cris/include/asm/pci.h | 1 +
> 2 files changed, 1 insertion(+), 23 deletions(-)
>
> diff --git a/arch/cris/arch-v32/drivers/pci/bios.c
> b/arch/cris/arch-v32/drivers/pci/bios.c
> index a589686d..394c2a73 100644
> --- a/arch/cris/arch-v32/drivers/pci/bios.c
> +++ b/arch/cris/arch-v32/drivers/pci/bios.c
> @@ -14,29 +14,6 @@ void pcibios_set_master(struct pci_dev *dev)
> pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat);
> }
>
> -int pci_mmap_page_range(struct pci_dev *dev, int bar,
> - struct vm_area_struct *vma,
> - enum pci_mmap_state mmap_state, int write_combine)
> -{
> - unsigned long prot;
> -
> - /* Leave vm_pgoff as-is, the PCI space address is the physical
> - * address on this platform.
> - */
> - prot = pgprot_val(vma->vm_page_prot);
> - vma->vm_page_prot = __pgprot(prot);
> -
> - /* Write-combine setting is ignored, it is changed via the mtrr
> - * interfaces on this platform.
> - */
> - if (remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
> - vma->vm_end - vma->vm_start,
> - vma->vm_page_prot))
> - return -EAGAIN;
> -
> - return 0;
> -}
> -
> resource_size_t
> pcibios_align_resource(void *data, const struct resource *res,
> resource_size_t size, resource_size_t align)
> diff --git a/arch/cris/include/asm/pci.h b/arch/cris/include/asm/pci.h
> index 65198cb..6e50533 100644
> --- a/arch/cris/include/asm/pci.h
> +++ b/arch/cris/include/asm/pci.h
> @@ -42,6 +42,7 @@ struct pci_dev;
> #define PCI_DMA_BUS_IS_PHYS (1)
>
> #define HAVE_PCI_MMAP
> +#define ARCH_GENERIC_PCI_MMAP_RESOURCE
>
> #endif /* __KERNEL__ */
>
> --
> 2.9.3
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH 11/17] cris: Use generic pci_mmap_resource_range()
On Wed, Mar 22, 2017 at 01:25:25PM +, David Woodhouse wrote:
> From: David Woodhouse
Acked-by: Jesper Nilsson
> Signed-off-by: David Woodhouse
> ---
> arch/cris/arch-v32/drivers/pci/bios.c | 23 ---
> arch/cris/include/asm/pci.h | 1 +
> 2 files changed, 1 insertion(+), 23 deletions(-)
>
> diff --git a/arch/cris/arch-v32/drivers/pci/bios.c
> b/arch/cris/arch-v32/drivers/pci/bios.c
> index a589686d..394c2a73 100644
> --- a/arch/cris/arch-v32/drivers/pci/bios.c
> +++ b/arch/cris/arch-v32/drivers/pci/bios.c
> @@ -14,29 +14,6 @@ void pcibios_set_master(struct pci_dev *dev)
> pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat);
> }
>
> -int pci_mmap_page_range(struct pci_dev *dev, int bar,
> - struct vm_area_struct *vma,
> - enum pci_mmap_state mmap_state, int write_combine)
> -{
> - unsigned long prot;
> -
> - /* Leave vm_pgoff as-is, the PCI space address is the physical
> - * address on this platform.
> - */
> - prot = pgprot_val(vma->vm_page_prot);
> - vma->vm_page_prot = __pgprot(prot);
> -
> - /* Write-combine setting is ignored, it is changed via the mtrr
> - * interfaces on this platform.
> - */
> - if (remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
> - vma->vm_end - vma->vm_start,
> - vma->vm_page_prot))
> - return -EAGAIN;
> -
> - return 0;
> -}
> -
> resource_size_t
> pcibios_align_resource(void *data, const struct resource *res,
> resource_size_t size, resource_size_t align)
> diff --git a/arch/cris/include/asm/pci.h b/arch/cris/include/asm/pci.h
> index 65198cb..6e50533 100644
> --- a/arch/cris/include/asm/pci.h
> +++ b/arch/cris/include/asm/pci.h
> @@ -42,6 +42,7 @@ struct pci_dev;
> #define PCI_DMA_BUS_IS_PHYS (1)
>
> #define HAVE_PCI_MMAP
> +#define ARCH_GENERIC_PCI_MMAP_RESOURCE
>
> #endif /* __KERNEL__ */
>
> --
> 2.9.3
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH 5/6] cris: remove unused wp_works_ok macro
On Sun, Feb 12, 2017 at 10:12:11PM +0100, Mathias Krause wrote:
> It had no use since it's introduction in v2.4.1.2. Get rid of it.
Agreed.
Acked-by: Jesper Nilsson <jesper.nils...@axis.com>
> Cc: Mikael Starvik <star...@axis.com>
> Signed-off-by: Mathias Krause <mini...@googlemail.com>
> ---
> arch/cris/include/arch-v10/arch/processor.h |3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/arch/cris/include/arch-v10/arch/processor.h
> b/arch/cris/include/arch-v10/arch/processor.h
> index 93feb2a487d8..58f75bee1d6c 100644
> --- a/arch/cris/include/arch-v10/arch/processor.h
> +++ b/arch/cris/include/arch-v10/arch/processor.h
> @@ -7,9 +7,6 @@
> */
> #define current_text_addr() ({void *pc; __asm__ ("move.d $pc,%0" : "=rm"
> (pc)); pc; })
>
> -/* CRIS has no problems with write protection */
> -#define wp_works_ok 1
> -
> /* CRIS thread_struct. this really has nothing to do with the processor
> itself, since
> * CRIS does not do any hardware task-switching, but it's here for legacy
> reasons.
> * The thread_struct here is used when task-switching using _resume defined
> in entry.S.
> --
> 1.7.10.4
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH 5/6] cris: remove unused wp_works_ok macro
On Sun, Feb 12, 2017 at 10:12:11PM +0100, Mathias Krause wrote:
> It had no use since it's introduction in v2.4.1.2. Get rid of it.
Agreed.
Acked-by: Jesper Nilsson
> Cc: Mikael Starvik
> Signed-off-by: Mathias Krause
> ---
> arch/cris/include/arch-v10/arch/processor.h |3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/arch/cris/include/arch-v10/arch/processor.h
> b/arch/cris/include/arch-v10/arch/processor.h
> index 93feb2a487d8..58f75bee1d6c 100644
> --- a/arch/cris/include/arch-v10/arch/processor.h
> +++ b/arch/cris/include/arch-v10/arch/processor.h
> @@ -7,9 +7,6 @@
> */
> #define current_text_addr() ({void *pc; __asm__ ("move.d $pc,%0" : "=rm"
> (pc)); pc; })
>
> -/* CRIS has no problems with write protection */
> -#define wp_works_ok 1
> -
> /* CRIS thread_struct. this really has nothing to do with the processor
> itself, since
> * CRIS does not do any hardware task-switching, but it's here for legacy
> reasons.
> * The thread_struct here is used when task-switching using _resume defined
> in entry.S.
> --
> 1.7.10.4
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH] cris: migrate exception table users off module.h and onto extable.h
On Tue, Jan 24, 2017 at 12:31:49PM -0500, Paul Gortmaker wrote: > This file was only including module.h for exception table related > functions. We've now separated that content out into its own file > "extable.h" so now move over to that and avoid all the extra header > content in module.h that we don't really need to compile this file. > > Reported-by: kbuild test robot <l...@intel.com> > Cc: Mikael Starvik <star...@axis.com> Acked-by: Jesper Nilsson <jesper.nils...@axis.com> > Cc: linux-cris-ker...@axis.com > Signed-off-by: Paul Gortmaker <paul.gortma...@windriver.com> > --- > > [This is to be added to the other 20 patches of this for-merge series: > https://lkml.kernel.org/r/20170122163244.11740-1-paul.gortma...@windriver.com > I didn't want to resend all 20 again just for the addition of a one liner.] Not a problem, looks good. > arch/cris/arch-v32/kernel/traps.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/cris/arch-v32/kernel/traps.c > b/arch/cris/arch-v32/kernel/traps.c > index d79666aefd71..ad6174e217c9 100644 > --- a/arch/cris/arch-v32/kernel/traps.c > +++ b/arch/cris/arch-v32/kernel/traps.c > @@ -3,7 +3,7 @@ > */ > > #include > -#include > +#include > #include > #include > #include > -- > 2.11.0 /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH] cris: migrate exception table users off module.h and onto extable.h
On Tue, Jan 24, 2017 at 12:31:49PM -0500, Paul Gortmaker wrote: > This file was only including module.h for exception table related > functions. We've now separated that content out into its own file > "extable.h" so now move over to that and avoid all the extra header > content in module.h that we don't really need to compile this file. > > Reported-by: kbuild test robot > Cc: Mikael Starvik Acked-by: Jesper Nilsson > Cc: linux-cris-ker...@axis.com > Signed-off-by: Paul Gortmaker > --- > > [This is to be added to the other 20 patches of this for-merge series: > https://lkml.kernel.org/r/20170122163244.11740-1-paul.gortma...@windriver.com > I didn't want to resend all 20 again just for the addition of a one liner.] Not a problem, looks good. > arch/cris/arch-v32/kernel/traps.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/cris/arch-v32/kernel/traps.c > b/arch/cris/arch-v32/kernel/traps.c > index d79666aefd71..ad6174e217c9 100644 > --- a/arch/cris/arch-v32/kernel/traps.c > +++ b/arch/cris/arch-v32/kernel/traps.c > @@ -3,7 +3,7 @@ > */ > > #include > -#include > +#include > #include > #include > #include > -- > 2.11.0 /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH v2 0/7] uapi: export all headers under uapi directories
On Mon, Jan 09, 2017 at 12:33:58PM +0100, Arnd Bergmann wrote: > On Friday, January 6, 2017 10:43:52 AM CET Nicolas Dichtel wrote: > > Here is the v2 of this series. The first 5 patches are just cleanup: some > > exported headers were still under a non-uapi directory. > > Since this is meant as a cleanup, I commented on this to point out a cleaner > way to do the same. > > > The patch 6 was spotted by code review: there is no in-tree user of this > > functionality. > > The last patch remove the use of header-y. Now all files under an uapi > > directory are exported. > > Very nice! > > > asm is a bit special, most of architectures export > > asm//include/uapi/asm > > only, but there is two exceptions: > > - cris which exports arch/cris/include/uapi/arch-v[10|32]; > > This is interesting, though not your problem. Maybe someone who understands > cris better can comment on this: How is the decision made about which of > the arch/user.h headers gets used? I couldn't find that in the sources, > but it appears to be based on kernel compile-time settings, which is > wrong for user space header files that should be independent of the kernel > config. I believe it's since the CRISv10 and CRISv32 are very different beasts, and that is selected via kernel config... This part of the CRIS port has been transformed a couple of times from the original layout without uapi, and there's still some legacy silliness, where some files might have been exported but never used from userspace except for some corner cases. > > - tile which exports arch/tile/include/uapi/arch. > > Because I don't know if the output of 'make headers_install_all' can be > > changed, > > I introduce subdir-y in Kbuild file. The headers_install_all target copies > > all > > asm//include/uapi/asm to usr/include/asm- but > > arch/cris/include/uapi/arch-v[10|32] and arch/tile/include/uapi/arch are not > > prefixed (they are put asis in usr/include/). If it's acceptable to modify > > the > > output of 'make headers_install_all' to export asm headers in > > usr/include/asm-/asm, then I could remove this new subdir-y and > > exports > > everything under arch//include/uapi/. > > I don't know if anyone still uses "make headers_install_all", I suspect > distros these days all use "make headers_install", so it probably > doesn't matter much. > > In case of cris, it should be easy enough to move all the contents of the > uapi/arch-*/*.h headers into the respective uapi/asm/*.h headers, they > only seem to be referenced from there. This would seem to be a reasonable change. > For tile, I suspect that would not work as the arch/*.h headers are > apparently defined as interfaces for both user space and kernel. > > > Note also that exported files for asm are a mix of files listed by: > > - include/uapi/asm-generic/Kbuild.asm; > > - arch/x86/include/uapi/asm/Kbuild; > > - arch/x86/include/asm/Kbuild. > > This complicates a lot the processing (arch/x86/include/asm/Kbuild is also > > used by scripts/Makefile.asm-generic). > > > > This series has been tested with a 'make headers_install' on x86 and a > > 'make headers_install_all'. I've checked the result of both commands. > > > > This patch is built against linus tree. I don't know if it should be > > made against antoher tree. > > The series should probably get merged through the kbuild tree, but testing > it on mainline is fine here. > > Arnd /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH v2 0/7] uapi: export all headers under uapi directories
On Mon, Jan 09, 2017 at 12:33:58PM +0100, Arnd Bergmann wrote: > On Friday, January 6, 2017 10:43:52 AM CET Nicolas Dichtel wrote: > > Here is the v2 of this series. The first 5 patches are just cleanup: some > > exported headers were still under a non-uapi directory. > > Since this is meant as a cleanup, I commented on this to point out a cleaner > way to do the same. > > > The patch 6 was spotted by code review: there is no in-tree user of this > > functionality. > > The last patch remove the use of header-y. Now all files under an uapi > > directory are exported. > > Very nice! > > > asm is a bit special, most of architectures export > > asm//include/uapi/asm > > only, but there is two exceptions: > > - cris which exports arch/cris/include/uapi/arch-v[10|32]; > > This is interesting, though not your problem. Maybe someone who understands > cris better can comment on this: How is the decision made about which of > the arch/user.h headers gets used? I couldn't find that in the sources, > but it appears to be based on kernel compile-time settings, which is > wrong for user space header files that should be independent of the kernel > config. I believe it's since the CRISv10 and CRISv32 are very different beasts, and that is selected via kernel config... This part of the CRIS port has been transformed a couple of times from the original layout without uapi, and there's still some legacy silliness, where some files might have been exported but never used from userspace except for some corner cases. > > - tile which exports arch/tile/include/uapi/arch. > > Because I don't know if the output of 'make headers_install_all' can be > > changed, > > I introduce subdir-y in Kbuild file. The headers_install_all target copies > > all > > asm//include/uapi/asm to usr/include/asm- but > > arch/cris/include/uapi/arch-v[10|32] and arch/tile/include/uapi/arch are not > > prefixed (they are put asis in usr/include/). If it's acceptable to modify > > the > > output of 'make headers_install_all' to export asm headers in > > usr/include/asm-/asm, then I could remove this new subdir-y and > > exports > > everything under arch//include/uapi/. > > I don't know if anyone still uses "make headers_install_all", I suspect > distros these days all use "make headers_install", so it probably > doesn't matter much. > > In case of cris, it should be easy enough to move all the contents of the > uapi/arch-*/*.h headers into the respective uapi/asm/*.h headers, they > only seem to be referenced from there. This would seem to be a reasonable change. > For tile, I suspect that would not work as the arch/*.h headers are > apparently defined as interfaces for both user space and kernel. > > > Note also that exported files for asm are a mix of files listed by: > > - include/uapi/asm-generic/Kbuild.asm; > > - arch/x86/include/uapi/asm/Kbuild; > > - arch/x86/include/asm/Kbuild. > > This complicates a lot the processing (arch/x86/include/asm/Kbuild is also > > used by scripts/Makefile.asm-generic). > > > > This series has been tested with a 'make headers_install' on x86 and a > > 'make headers_install_all'. I've checked the result of both commands. > > > > This patch is built against linus tree. I don't know if it should be > > made against antoher tree. > > The series should probably get merged through the kbuild tree, but testing > it on mainline is fine here. > > Arnd /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
[GIT PULL] CRIS changes for 4.10
Hi Linus, Please pull below for a trio of small cleanup patches. Thanks! The following changes since commit bc33b0ca11e3df46a4fa7639ba488c9d4911: Linux 4.9-rc4 (2016-11-05 16:23:36 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris.git tags/cris-for-4.10 for you to fetch changes up to 8f50f2a1b46a11a9a9fb46c5d8325dfc88281a76: cris: No need to append -O2 and $(LINUXINCLUDE) (2016-12-08 10:56:40 +0100) Three patches for minor issues: Guenter Roeck (1): cris: Only build flash rescue image if CONFIG_ETRAX_AXISFLASHMAP is selected Paul Bolle (1): cris: No need to append -O2 and $(LINUXINCLUDE) Paul Gortmaker (1): tty: serial: make crisv10 explicitly non-modular arch/cris/boot/compressed/Makefile |3 --- arch/cris/boot/rescue/Makefile |9 +++-- drivers/tty/serial/crisv10.c |6 ++ 3 files changed, 9 insertions(+), 9 deletions(-) Guenter Roeck (1): cris: Only build flash rescue image if CONFIG_ETRAX_AXISFLASHMAP is selected Paul Bolle (1): cris: No need to append -O2 and $(LINUXINCLUDE) Paul Gortmaker (1): tty: serial: make crisv10 explicitly non-modular arch/cris/boot/compressed/Makefile |3 --- arch/cris/boot/rescue/Makefile |9 +++-- drivers/tty/serial/crisv10.c |6 ++ 3 files changed, 9 insertions(+), 9 deletions(-) /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
[GIT PULL] CRIS changes for 4.10
Hi Linus, Please pull below for a trio of small cleanup patches. Thanks! The following changes since commit bc33b0ca11e3df46a4fa7639ba488c9d4911: Linux 4.9-rc4 (2016-11-05 16:23:36 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris.git tags/cris-for-4.10 for you to fetch changes up to 8f50f2a1b46a11a9a9fb46c5d8325dfc88281a76: cris: No need to append -O2 and $(LINUXINCLUDE) (2016-12-08 10:56:40 +0100) Three patches for minor issues: Guenter Roeck (1): cris: Only build flash rescue image if CONFIG_ETRAX_AXISFLASHMAP is selected Paul Bolle (1): cris: No need to append -O2 and $(LINUXINCLUDE) Paul Gortmaker (1): tty: serial: make crisv10 explicitly non-modular arch/cris/boot/compressed/Makefile |3 --- arch/cris/boot/rescue/Makefile |9 +++-- drivers/tty/serial/crisv10.c |6 ++ 3 files changed, 9 insertions(+), 9 deletions(-) Guenter Roeck (1): cris: Only build flash rescue image if CONFIG_ETRAX_AXISFLASHMAP is selected Paul Bolle (1): cris: No need to append -O2 and $(LINUXINCLUDE) Paul Gortmaker (1): tty: serial: make crisv10 explicitly non-modular arch/cris/boot/compressed/Makefile |3 --- arch/cris/boot/rescue/Makefile |9 +++-- drivers/tty/serial/crisv10.c |6 ++ 3 files changed, 9 insertions(+), 9 deletions(-) /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
[PATCH v2] net: phy: dp83848: Support ethernet pause frames
According to the documentation, the PHYs supported by this driver
can also support pause frames. Announce this to be so.
Tested with a TI83822I.
Acked-by: Andrew F. Davis <a...@ti.com>
Signed-off-by: Jesper Nilsson <jesper.nils...@axis.com>
---
drivers/net/phy/dp83848.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/dp83848.c b/drivers/net/phy/dp83848.c
index 800b39f..320d0dc 100644
--- a/drivers/net/phy/dp83848.c
+++ b/drivers/net/phy/dp83848.c
@@ -88,7 +88,9 @@ MODULE_DEVICE_TABLE(mdio, dp83848_tbl);
.phy_id = _id, \
.phy_id_mask= 0xfff0, \
.name = _name,\
- .features = PHY_BASIC_FEATURES, \
+ .features = (PHY_BASIC_FEATURES | \
+ SUPPORTED_Pause |\
+ SUPPORTED_Asym_Pause), \
.flags = PHY_HAS_INTERRUPT,\
\
.soft_reset = genphy_soft_reset,\
--
2.1.4
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
[PATCH v2] net: phy: dp83848: Support ethernet pause frames
According to the documentation, the PHYs supported by this driver can also support pause frames. Announce this to be so. Tested with a TI83822I. Acked-by: Andrew F. Davis Signed-off-by: Jesper Nilsson --- drivers/net/phy/dp83848.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/phy/dp83848.c b/drivers/net/phy/dp83848.c index 800b39f..320d0dc 100644 --- a/drivers/net/phy/dp83848.c +++ b/drivers/net/phy/dp83848.c @@ -88,7 +88,9 @@ MODULE_DEVICE_TABLE(mdio, dp83848_tbl); .phy_id = _id, \ .phy_id_mask= 0xfff0, \ .name = _name,\ - .features = PHY_BASIC_FEATURES, \ + .features = (PHY_BASIC_FEATURES | \ + SUPPORTED_Pause |\ + SUPPORTED_Asym_Pause), \ .flags = PHY_HAS_INTERRUPT,\ \ .soft_reset = genphy_soft_reset,\ -- 2.1.4 /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH] net: phy: dp83848: Support ethernet pause frames
On Fri, Dec 02, 2016 at 08:35:23AM -0600, Andrew F. Davis wrote: > On 12/02/2016 08:22 AM, Jesper Nilsson wrote: > > According to the documentation, the PHYs supported by this driver > > can also support pause frames. Announce this to be so. > > Tested with a TI83822I. > > > > Looks like all PHYs supported by this driver do, so: > > Acked-by: Andrew F. Davis <a...@ti.com> > > > Signed-off-by: Jesper Nilsson <jesper.nils...@axis.com> > > --- > > drivers/net/phy/dp83848.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/net/phy/dp83848.c b/drivers/net/phy/dp83848.c > > index 800b39f..6e4117f 100644 > > --- a/drivers/net/phy/dp83848.c > > +++ b/drivers/net/phy/dp83848.c > > @@ -88,7 +88,8 @@ MODULE_DEVICE_TABLE(mdio, dp83848_tbl); > > .phy_id = _id, \ > > .phy_id_mask= 0xfff0, \ > > .name = _name,\ > > - .features = PHY_BASIC_FEATURES, \ > > + .features = (PHY_BASIC_FEATURES | \ > > + SUPPORTED_Pause | SUPPORTED_Asym_Pause),\ > > Aligning these may look nicer though. Agreed, will send a v2. > > .flags = PHY_HAS_INTERRUPT, \ > > \ > > .soft_reset = genphy_soft_reset,\ > > /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [PATCH] net: phy: dp83848: Support ethernet pause frames
On Fri, Dec 02, 2016 at 08:35:23AM -0600, Andrew F. Davis wrote: > On 12/02/2016 08:22 AM, Jesper Nilsson wrote: > > According to the documentation, the PHYs supported by this driver > > can also support pause frames. Announce this to be so. > > Tested with a TI83822I. > > > > Looks like all PHYs supported by this driver do, so: > > Acked-by: Andrew F. Davis > > > Signed-off-by: Jesper Nilsson > > --- > > drivers/net/phy/dp83848.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/net/phy/dp83848.c b/drivers/net/phy/dp83848.c > > index 800b39f..6e4117f 100644 > > --- a/drivers/net/phy/dp83848.c > > +++ b/drivers/net/phy/dp83848.c > > @@ -88,7 +88,8 @@ MODULE_DEVICE_TABLE(mdio, dp83848_tbl); > > .phy_id = _id, \ > > .phy_id_mask= 0xfff0, \ > > .name = _name,\ > > - .features = PHY_BASIC_FEATURES, \ > > + .features = (PHY_BASIC_FEATURES | \ > > + SUPPORTED_Pause | SUPPORTED_Asym_Pause),\ > > Aligning these may look nicer though. Agreed, will send a v2. > > .flags = PHY_HAS_INTERRUPT, \ > > \ > > .soft_reset = genphy_soft_reset,\ > > /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
[PATCH] net: phy: dp83848: Support ethernet pause frames
According to the documentation, the PHYs supported by this driver can also support pause frames. Announce this to be so. Tested with a TI83822I. Signed-off-by: Jesper Nilsson <jesper.nils...@axis.com> --- drivers/net/phy/dp83848.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/phy/dp83848.c b/drivers/net/phy/dp83848.c index 800b39f..6e4117f 100644 --- a/drivers/net/phy/dp83848.c +++ b/drivers/net/phy/dp83848.c @@ -88,7 +88,8 @@ MODULE_DEVICE_TABLE(mdio, dp83848_tbl); .phy_id = _id, \ .phy_id_mask= 0xfff0, \ .name = _name,\ - .features = PHY_BASIC_FEATURES, \ + .features = (PHY_BASIC_FEATURES | \ + SUPPORTED_Pause | SUPPORTED_Asym_Pause),\ .flags = PHY_HAS_INTERRUPT,\ \ .soft_reset = genphy_soft_reset,\ -- 2.1.4 /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
[PATCH] net: phy: dp83848: Support ethernet pause frames
According to the documentation, the PHYs supported by this driver can also support pause frames. Announce this to be so. Tested with a TI83822I. Signed-off-by: Jesper Nilsson --- drivers/net/phy/dp83848.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/phy/dp83848.c b/drivers/net/phy/dp83848.c index 800b39f..6e4117f 100644 --- a/drivers/net/phy/dp83848.c +++ b/drivers/net/phy/dp83848.c @@ -88,7 +88,8 @@ MODULE_DEVICE_TABLE(mdio, dp83848_tbl); .phy_id = _id, \ .phy_id_mask= 0xfff0, \ .name = _name,\ - .features = PHY_BASIC_FEATURES, \ + .features = (PHY_BASIC_FEATURES | \ + SUPPORTED_Pause | SUPPORTED_Asym_Pause),\ .flags = PHY_HAS_INTERRUPT,\ \ .soft_reset = genphy_soft_reset,\ -- 2.1.4 /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [GIT PULL]: ARM ARTPEC changes for 4.10
On Mon, Nov 28, 2016 at 01:57:10PM +0100, Arnd Bergmann wrote: > On Monday, November 28, 2016 1:33:31 PM CET Jesper Nilsson wrote: > > > Hi Jesper and Niklas, > > > > > > I just found the old pull request while going through my mail backlog. > > > > > > A few things for you to remember for next time: > > > > > > - please send pull requests "To: a...@kernel.org" so we know they > > > are destined for arm-soc > > > > Ok, should we add that in the MAINTAINERS file so we can > > get it automatically from get_maintainer? > > No, we don't want to get every single patch that people submit to > platform maintainers, only the consolidated pull requests that you > send. Right, sounds reasonable, will do. > Arnd /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [GIT PULL]: ARM ARTPEC changes for 4.10
On Mon, Nov 28, 2016 at 01:57:10PM +0100, Arnd Bergmann wrote: > On Monday, November 28, 2016 1:33:31 PM CET Jesper Nilsson wrote: > > > Hi Jesper and Niklas, > > > > > > I just found the old pull request while going through my mail backlog. > > > > > > A few things for you to remember for next time: > > > > > > - please send pull requests "To: a...@kernel.org" so we know they > > > are destined for arm-soc > > > > Ok, should we add that in the MAINTAINERS file so we can > > get it automatically from get_maintainer? > > No, we don't want to get every single patch that people submit to > platform maintainers, only the consolidated pull requests that you > send. Right, sounds reasonable, will do. > Arnd /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com
Re: [GIT PULL]: ARM ARTPEC changes for 4.10
On Sat, Nov 26, 2016 at 12:16:20AM +0100, Arnd Bergmann wrote:
> On Thursday, November 10, 2016 4:09:31 PM CET Jesper Nilsson wrote:
> > Please pull the below signed tag for a trio of minor changes
> > adding PCIe for the ARM ARTPEC SoC.
> >
> > Thanks!
> >
> > /Jesper
> >
> > The following changes since commit bc33b0ca11e3df46a4fa7639ba488c9d4911:
> >
> > Linux 4.9-rc4 (2016-11-05 16:23:36 -0700)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/jesper/artpec.git
> > tags/artpec-for-4.10
> >
> > for you to fetch changes up to fa5541fc806771a108cd2a48245a229f1ba539ea:
> >
> > ARM: dts: artpec: add pcie support (2016-11-10 15:51:10 +0100)
> >
> >
> > ARTPEC changes for 4.10
> >
> >
> > Niklas Cassel (3):
> > ARM: ARTPEC-6: add select MFD_SYSCON to MACH_ARTPEC6
> > ARM: ARTPEC-6: add pcie related options
> > ARM: dts: artpec: add pcie support
> >
> >
>
> Hi Jesper and Niklas,
>
> I just found the old pull request while going through my mail backlog.
>
> A few things for you to remember for next time:
>
> - please send pull requests "To: a...@kernel.org" so we know they
> are destined for arm-soc
Ok, should we add that in the MAINTAINERS file so we can
get it automatically from get_maintainer?
> - please split up changes to the platform code from dts changes,
> defconfig changes and driver changes. Each of them gets sent
> to Linus in a separate arm-soc branch, so we have to pull them
> in separately too
>
> - For the signed tag, please put in a cleartext description of
> the branch, just like you describe each commit in its changelog
> text. The tag comment becomes the merge commit text.
Ok, will do both in the future.
> - I've looked at the three patches individually and cherry-picked
> the first into next/soc and the third into next/dt. The patch
> "ARM: ARTPEC-6: add pcie related options" is no longer needed
> after commit e13688f ("ARM: select PCI_DOMAINS config from
> ARCH_MULTIPLATFORM"), so I dropped that.
Thanks!
> Arnd
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
Re: [GIT PULL]: ARM ARTPEC changes for 4.10
On Sat, Nov 26, 2016 at 12:16:20AM +0100, Arnd Bergmann wrote:
> On Thursday, November 10, 2016 4:09:31 PM CET Jesper Nilsson wrote:
> > Please pull the below signed tag for a trio of minor changes
> > adding PCIe for the ARM ARTPEC SoC.
> >
> > Thanks!
> >
> > /Jesper
> >
> > The following changes since commit bc33b0ca11e3df46a4fa7639ba488c9d4911:
> >
> > Linux 4.9-rc4 (2016-11-05 16:23:36 -0700)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/jesper/artpec.git
> > tags/artpec-for-4.10
> >
> > for you to fetch changes up to fa5541fc806771a108cd2a48245a229f1ba539ea:
> >
> > ARM: dts: artpec: add pcie support (2016-11-10 15:51:10 +0100)
> >
> >
> > ARTPEC changes for 4.10
> >
> >
> > Niklas Cassel (3):
> > ARM: ARTPEC-6: add select MFD_SYSCON to MACH_ARTPEC6
> > ARM: ARTPEC-6: add pcie related options
> > ARM: dts: artpec: add pcie support
> >
> >
>
> Hi Jesper and Niklas,
>
> I just found the old pull request while going through my mail backlog.
>
> A few things for you to remember for next time:
>
> - please send pull requests "To: a...@kernel.org" so we know they
> are destined for arm-soc
Ok, should we add that in the MAINTAINERS file so we can
get it automatically from get_maintainer?
> - please split up changes to the platform code from dts changes,
> defconfig changes and driver changes. Each of them gets sent
> to Linus in a separate arm-soc branch, so we have to pull them
> in separately too
>
> - For the signed tag, please put in a cleartext description of
> the branch, just like you describe each commit in its changelog
> text. The tag comment becomes the merge commit text.
Ok, will do both in the future.
> - I've looked at the three patches individually and cherry-picked
> the first into next/soc and the third into next/dt. The patch
> "ARM: ARTPEC-6: add pcie related options" is no longer needed
> after commit e13688f ("ARM: select PCI_DOMAINS config from
> ARCH_MULTIPLATFORM"), so I dropped that.
Thanks!
> Arnd
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
