* [GIT PULL 1/5] i.MX drivers updates for 4.16
From: Arnd Bergmann @ 2018-01-05 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514959040-9992-1-git-send-email-shawnguo@kernel.org>
On Wed, Jan 3, 2018 at 6:57 AM, Shawn Guo <shawnguo@kernel.org> wrote:
> The following changes since commit 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36:
>
> Linux 4.15-rc3 (2017-12-10 17:56:26 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-drivers-4.16
>
> for you to fetch changes up to cfabb7921ccbede2968e5049d433ba3d0e0950af:
>
> soc: imx: gpc: Add i.MX6SX PCI power domain (2017-12-26 16:26:46 +0800)
>
> ----------------------------------------------------------------
> i.MX drivers update for 4.16:
> - Update i.MX GPC driver to support PCI power domain of i.MX6SX SoC.
Pulled into next/drivers, thanks!
Arnd
^ permalink raw reply
* [GIT PULL v2 1/2] TI DaVinci SoC support updates for v4.16
From: Arnd Bergmann @ 2018-01-05 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105145248.1994-1-nsekhar@ti.com>
On Fri, Jan 5, 2018 at 3:52 PM, Sekhar Nori <nsekhar@ti.com> wrote:
> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>
> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.16/soc-v2
>
> for you to fetch changes up to 23bbeaef90ab7607d03428bbb708efe44f43c761:
>
> ARM: davinci: constify gpio_led (2018-01-05 19:28:41 +0530)
>
> ----------------------------------------------------------------
> DaVinci SoC updates consisting of non-critical bug fixes including constifying
> data structures, removal of unnecessary newlines from gpio labels and code
> simplification.
>
> Also a defconfig update for DaVinci, enabling support for USB network adaptors.
Pulled into next/soc, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 5/5] i.MX defconfig updates for 4.16
From: Arnd Bergmann @ 2018-01-05 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514959040-9992-5-git-send-email-shawnguo@kernel.org>
On Wed, Jan 3, 2018 at 6:57 AM, Shawn Guo <shawnguo@kernel.org> wrote:
> The following changes since commit 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36:
>
> Linux 4.15-rc3 (2017-12-10 17:56:26 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-defconfig-4.16
>
> for you to fetch changes up to 189114b47b1cfcc5da02db9bcafebd2042aa7ab8:
>
> ARM: imx_v6_v7_defconfig: enable CONFIG_CPU_FREQ_STAT (2017-12-26 17:04:13 +0800)
>
> ----------------------------------------------------------------
> i.MX defconfig updates for 4.16:
> - Enable CPU_FREQ_STAT for cpufreq transtion statistics support.
> - Enable SRTC driver RTC_DRV_MXC_V2 for i.MX53.
> - Turn on a few drivers useful for DART-MX6 SoM support, SERDEV
> bluetooth, SERIAL_DEV_BUS, WL18XX, and DEFAULT_ON LED Trigger.
>
> ----------------------------------------------------------------
> Dong Aisheng (1):
> ARM: imx_v6_v7_defconfig: enable CONFIG_CPU_FREQ_STAT
This commit looks a bit fishy, as it does multiple things:
- add multitouch support
- move options around in the file that did not change
- drop some options (AEABI, CMA, SOC_CAMERA_OV2640,
SERIAL_DEV_CTRL_TTYPORT) for unknown reasons.
Cleaning up is fine, but please don't mix that with functional changes.
It's also fine to add multiple options at once in one patch, but when
you use 'make savedefconfig', please check each option that
gets dropped, some options might have gained new dependencies
or got renamed but are still needed here.
Finally, it might be good to check if the newly added options should
also be added to multi_v7_defconfig.
Not pulled for now, I'd suggest you resend without the 'savedefconfig'
cleanup, we can do that in a follow-up.
Arnd
^ permalink raw reply
* [PATCH 0/5] clk: read-only dividers and rate propagation fixup
From: Jerome Brunet @ 2018-01-05 17:09 UTC (permalink / raw)
To: linux-arm-kernel
A read-only divider may also have CLK_SET_RATE_PARENT flag set, in which
case it should propagate the requested rate to its parent, taking the
read-only divider value into account.
While this is done correctly in qcom's clk-regmap-divider, it is not in
the generic divider and lpc32xx.
Other drivers using divider_round_rate are not impacted because they are
using hard-coded flags without CLK_DIVIDER_READ_ONLY, so read-only
dividers does seems to be concern for them and rate propagation should
work as expected
Jerome Brunet (5):
clk: divider: read-only divider can propagate rate change
clk: lpc32xx: read-only divider can propagate rate change
clk: divider: add divider_ro_round_rate helper
clk: lpc32xx: use divider_ro_round_rate helper
clk: qcom: use divider_ro_round_rate helper
drivers/clk/clk-divider.c | 35 +++++++++++++++++++++++++++++------
drivers/clk/nxp/clk-lpc32xx.c | 15 ++++++++-------
drivers/clk/qcom/clk-regmap-divider.c | 19 ++++++-------------
include/linux/clk-provider.h | 15 +++++++++++++++
4 files changed, 58 insertions(+), 26 deletions(-)
--
2.14.3
^ permalink raw reply
* [PATCH 1/5] clk: divider: read-only divider can propagate rate change
From: Jerome Brunet @ 2018-01-05 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105170959.17266-1-jbrunet@baylibre.com>
When a divider clock has CLK_DIVIDER_READ_ONLY set, it means that the
register shall be left un-touched, but it does not mean the clock
should stop rate propagation if CLK_SET_RATE_PARENT is set
This is properly handled in qcom clk-regmap-divider but it was not in
the generic divider
Fixes: e6d5e7d90be9 ("clk-divider: Fix READ_ONLY when divider > 1")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/clk/clk-divider.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index b49942b9fe50..a851d3e04c7f 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -348,6 +348,7 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *prate)
{
struct clk_divider *divider = to_clk_divider(hw);
+ struct clk_hw *hw_parent = clk_hw_get_parent(hw);
int bestdiv;
/* if read only, just return current value */
@@ -356,6 +357,15 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
bestdiv &= div_mask(divider->width);
bestdiv = _get_div(divider->table, bestdiv, divider->flags,
divider->width);
+
+ /* Even a read-only clock can propagate a rate change */
+ if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) {
+ if (!hw_parent)
+ return -EINVAL;
+
+ *prate = clk_hw_round_rate(hw_parent, rate * bestdiv);
+ }
+
return DIV_ROUND_UP_ULL((u64)*prate, bestdiv);
}
--
2.14.3
^ permalink raw reply related
* [PATCH 2/5] clk: lpc32xx: read-only divider can propagate rate change
From: Jerome Brunet @ 2018-01-05 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105170959.17266-1-jbrunet@baylibre.com>
When a divider clock has CLK_DIVIDER_READ_ONLY set, it means that the
register shall be left un-touched, but it does not mean the clock
should stop rate propagation if CLK_SET_RATE_PARENT is set
This properly handled in qcom clk-regmap-divider but it was not in the
lpc32xx divider
Fixes: f7c82a60ba26 ("clk: lpc32xx: add common clock framework driver")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/clk/nxp/clk-lpc32xx.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/clk/nxp/clk-lpc32xx.c b/drivers/clk/nxp/clk-lpc32xx.c
index f5d815f577e0..729333766f97 100644
--- a/drivers/clk/nxp/clk-lpc32xx.c
+++ b/drivers/clk/nxp/clk-lpc32xx.c
@@ -963,6 +963,7 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *prate)
{
struct lpc32xx_clk_div *divider = to_lpc32xx_div(hw);
+ struct clk_hw *hw_parent = clk_hw_get_parent(hw);
unsigned int bestdiv;
/* if read only, just return current value */
@@ -972,6 +973,15 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
bestdiv &= div_mask(divider->width);
bestdiv = _get_div(divider->table, bestdiv, divider->flags,
divider->width);
+
+ /* Even a read-only clock can propagate a rate change */
+ if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) {
+ if (!hw_parent)
+ return -EINVAL;
+
+ *prate = clk_hw_round_rate(hw_parent, rate * bestdiv);
+ }
+
return DIV_ROUND_UP(*prate, bestdiv);
}
--
2.14.3
^ permalink raw reply related
* [PATCH 3/5] clk: divider: add divider_ro_round_rate helper
From: Jerome Brunet @ 2018-01-05 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105170959.17266-1-jbrunet@baylibre.com>
Like divider_round_rate, a couple a of driver are doing more or less
the same operation to round the rate of the divider when it is read-only.
We can factor this code so let's provide an helper function for this
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/clk/clk-divider.c | 43 ++++++++++++++++++++++++++++---------------
include/linux/clk-provider.h | 15 +++++++++++++++
2 files changed, 43 insertions(+), 15 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index a851d3e04c7f..3eb2b27f3513 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -344,29 +344,42 @@ long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
}
EXPORT_SYMBOL_GPL(divider_round_rate_parent);
+long divider_ro_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
+ unsigned long rate, unsigned long *prate,
+ const struct clk_div_table *table, u8 width,
+ unsigned long flags, unsigned int val)
+{
+ int div;
+
+ div = _get_div(table, val, flags, width);
+
+ /* Even a read-only clock can propagate a rate change */
+ if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) {
+ if (!parent)
+ return -EINVAL;
+
+ *prate = clk_hw_round_rate(parent, rate * div);
+ }
+
+ return DIV_ROUND_UP_ULL((u64)*prate, div);
+}
+EXPORT_SYMBOL_GPL(divider_ro_round_rate_parent);
+
+
static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *prate)
{
struct clk_divider *divider = to_clk_divider(hw);
- struct clk_hw *hw_parent = clk_hw_get_parent(hw);
- int bestdiv;
+ u32 val;
/* if read only, just return current value */
if (divider->flags & CLK_DIVIDER_READ_ONLY) {
- bestdiv = clk_readl(divider->reg) >> divider->shift;
- bestdiv &= div_mask(divider->width);
- bestdiv = _get_div(divider->table, bestdiv, divider->flags,
- divider->width);
-
- /* Even a read-only clock can propagate a rate change */
- if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) {
- if (!hw_parent)
- return -EINVAL;
-
- *prate = clk_hw_round_rate(hw_parent, rate * bestdiv);
- }
+ val = clk_readl(divider->reg) >> divider->shift;
+ val &= div_mask(divider->width);
- return DIV_ROUND_UP_ULL((u64)*prate, bestdiv);
+ return divider_ro_round_rate(hw, rate, prate, divider->table,
+ divider->width, divider->flags,
+ val);
}
return divider_round_rate(hw, rate, prate, divider->table,
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 175a62a15619..eb2c3a035e98 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -417,6 +417,10 @@ long divider_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
unsigned long rate, unsigned long *prate,
const struct clk_div_table *table,
u8 width, unsigned long flags);
+long divider_ro_round_rate_parent(struct clk_hw *hw, struct clk_hw *parent,
+ unsigned long rate, unsigned long *prate,
+ const struct clk_div_table *table, u8 width,
+ unsigned long flags, unsigned int val);
int divider_get_val(unsigned long rate, unsigned long parent_rate,
const struct clk_div_table *table, u8 width,
unsigned long flags);
@@ -772,6 +776,17 @@ static inline long divider_round_rate(struct clk_hw *hw, unsigned long rate,
rate, prate, table, width, flags);
}
+static inline long divider_ro_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate,
+ const struct clk_div_table *table,
+ u8 width, unsigned long flags,
+ unsigned int val)
+{
+ return divider_ro_round_rate_parent(hw, clk_hw_get_parent(hw),
+ rate, prate, table, width, flags,
+ val);
+}
+
/*
* FIXME clock api without lock protection
*/
--
2.14.3
^ permalink raw reply related
* [PATCH 4/5] clk: lpc32xx: use divider_ro_round_rate helper
From: Jerome Brunet @ 2018-01-05 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105170959.17266-1-jbrunet@baylibre.com>
There is now an helper function to round the rate when the
divider is read-only. Let's use it
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/clk/nxp/clk-lpc32xx.c | 23 +++++++----------------
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/drivers/clk/nxp/clk-lpc32xx.c b/drivers/clk/nxp/clk-lpc32xx.c
index 729333766f97..c20285e74b8e 100644
--- a/drivers/clk/nxp/clk-lpc32xx.c
+++ b/drivers/clk/nxp/clk-lpc32xx.c
@@ -963,26 +963,17 @@ static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *prate)
{
struct lpc32xx_clk_div *divider = to_lpc32xx_div(hw);
- struct clk_hw *hw_parent = clk_hw_get_parent(hw);
- unsigned int bestdiv;
+ unsigned int val;
/* if read only, just return current value */
if (divider->flags & CLK_DIVIDER_READ_ONLY) {
- regmap_read(clk_regmap, divider->reg, &bestdiv);
- bestdiv >>= divider->shift;
- bestdiv &= div_mask(divider->width);
- bestdiv = _get_div(divider->table, bestdiv, divider->flags,
- divider->width);
-
- /* Even a read-only clock can propagate a rate change */
- if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) {
- if (!hw_parent)
- return -EINVAL;
-
- *prate = clk_hw_round_rate(hw_parent, rate * bestdiv);
- }
+ regmap_read(clk_regmap, divider->reg, &val);
+ val >>= divider->shift;
+ val &= div_mask(divider->width);
- return DIV_ROUND_UP(*prate, bestdiv);
+ return divider_ro_round_rate(hw, rate, prate, divider->table,
+ divider->width, divider->flags,
+ bestdiv);
}
return divider_round_rate(hw, rate, prate, divider->table,
--
2.14.3
^ permalink raw reply related
* [PATCH 5/5] clk: qcom: use divider_ro_round_rate helper
From: Jerome Brunet @ 2018-01-05 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105170959.17266-1-jbrunet@baylibre.com>
There is now an helper function to round the rate when the
divider is read-only. Let's use it
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/clk/qcom/clk-regmap-divider.c | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/qcom/clk-regmap-divider.c b/drivers/clk/qcom/clk-regmap-divider.c
index 4e9b8c2c8980..114e36b97255 100644
--- a/drivers/clk/qcom/clk-regmap-divider.c
+++ b/drivers/clk/qcom/clk-regmap-divider.c
@@ -28,22 +28,15 @@ static long div_round_ro_rate(struct clk_hw *hw, unsigned long rate,
{
struct clk_regmap_div *divider = to_clk_regmap_div(hw);
struct clk_regmap *clkr = ÷r->clkr;
- u32 div;
+ u32 val;
struct clk_hw *hw_parent = clk_hw_get_parent(hw);
- regmap_read(clkr->regmap, divider->reg, &div);
- div >>= divider->shift;
- div &= BIT(divider->width) - 1;
- div += 1;
-
- if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) {
- if (!hw_parent)
- return -EINVAL;
-
- *prate = clk_hw_round_rate(hw_parent, rate * div);
- }
+ regmap_read(clkr->regmap, divider->reg, &val);
+ val >>= divider->shift;
+ val &= BIT(divider->width) - 1;
- return DIV_ROUND_UP_ULL((u64)*prate, div);
+ return divider_ro_round_rate(hw, rate, prate, NULL, divider->width,
+ CLK_DIVIDER_ROUND_CLOSEST, val);
}
static long div_round_rate(struct clk_hw *hw, unsigned long rate,
--
2.14.3
^ permalink raw reply related
* [PATCH] imx6: fix pcie enumeration
From: Lorenzo Pieralisi @ 2018-01-05 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ebf30c78-b772-6214-f441-c86ae7fdba7e@ncentric.com>
On Fri, Jan 05, 2018 at 02:39:57PM +0100, Koen Vandeputte wrote:
>
>
> On 2018-01-05 13:32, Lorenzo Pieralisi wrote:
> >
> >> /* setup bus numbers */
> >> val = dw_pcie_readl_dbi
> >> val &= 0xff000000;
> >> val |= 0x00010100; <--- hardcoded today
> >> dw_pcie_writel_dbi
>
> >>I *think* I understand what's going on - the kernel takes the primary,
> >>secondary and subordinate values in the host bridge as valid in:
> >>
> >>pci_scan_bridge_extend()
> >>
> >>and given that pcibios_assign_all_busses() returns false (guess) it sets-up
> >>the bus hierarchy with a bus resource with subordinate number as read from
> >>PCI host bridge config space - which, given that it is 1 according to your
> >>explanation - this triggers the issue you reported.
> >>
> >>After commit a20c7f36bd3d the root bus resource is propagated down the
> >>hierarchy, hence the problem.
> >>
> >>So, in order to fix the issue I think the best way is to programme the
> >>root bridge in:
> >>
> >>drivers/pci/dwc/pci-designware-host.c
> >>
> >>but with the value coming from the root bus IORESOURCE_BUS resource,
> >>not hardcoding 0xff.
> >>
> >>I would kindly ask you to send logs with debug turned on in:
> >>
> >>drivers/pci/probe.c
> >>
> >>since I would like to check my understanding is correct.
> >>
> >>Please CC all dwc host maintainers since this has potential widespread
> >>impact.
> >>
> >>Thanks,
> >>Lorenzo
> Hi Lorenzo,
>
> This is exactly what I'm trying to explain:
>
> The host starts of with a (hardcoded today) subord of 1. [bits 16:23]
>
> Since commit a20c7f36bd3d, downstream devices cannot assign bus nr's
> higher than the subord of the upstream device.
> So in this case, scanning stops after the bridge as soon as bus 1 is
> assigned .. :)
There is one thing that I need to understand though. Before the commit
above, how would enumeration works given that the subordinate bus number
was set to 1 and that the kernel, AFAICS, does not overwrite it ?
Are you able to send me a log (enumeration with debugging enabled and
lspci) with the commit above reverted please ?
Thanks,
Lorenzo
> As other targets besides i.MX6 (layerscape, armada8k, ...) also use
> the same function to init PCIe, I believe those targets are also
> affected.
>
> I've tested here setting the PCI_PRIMARY_BUS register to 0x 00 ff 01
> 00? (ignored-subord-secbus-primbus), and the whole scanning works
> again.
> I fully agree that hardcoding is not the final fix, as this param
> can be defined in a DT.
>
>
> Fixing this, combined with the upstream commit exposing the error,
> fixes all following pci boot errors:
>
> ..
> [??? 0.466405] pci_bus 0000:05: [bus 05] partially hidden behind
> bridge 0000:01 [bus 01]
> ..
> [??? 0.466435] pci_bus 0000:02: busn_res: can not insert [bus 02-05]
> under [bus 01] (conflicts with (null) [bus 01])
> [??? 0.466454] pci_bus 0000:02: [bus 02-05] partially hidden behind
> bridge 0000:01 [bus 01]
> ..
>
>
> Watching the tree using lspci also shows that all primaries,
> secondaries and subords are perfectly logical as expected.
>
>
> Thanks,
>
> Koen
>
>
> Log showing the initial issue without any fixup:
>
>
> [??? 0.116673] OF: PCI: host bridge /soc/pcie at 0x01000000 ranges:
> [??? 0.116692] OF: PCI:?? No bus range found for
> /soc/pcie at 0x01000000, using [bus 00-ff]
> [??? 0.116719] OF: PCI:??? IO 0x01f80000..0x01f8ffff -> 0x00000000
> [??? 0.116739] OF: PCI:?? MEM 0x01000000..0x01efffff -> 0x01000000
> [??? 0.337752] imx6q-pcie 1ffc000.pcie: link up
> [??? 0.337771] imx6q-pcie 1ffc000.pcie: Link: Gen2 disabled
> [??? 0.337785] imx6q-pcie 1ffc000.pcie: link up
> [??? 0.337796] imx6q-pcie 1ffc000.pcie: Link up, Gen1
> [??? 0.338039] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
> [??? 0.338055] pci_bus 0000:00: root bus resource [bus 00-ff]
> [??? 0.338069] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
> [??? 0.338082] pci_bus 0000:00: root bus resource [mem
> 0x01000000-0x01efffff]
> [??? 0.338094] pci_bus 0000:00: scanning bus
> [??? 0.338127] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> [??? 0.338151] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
> [??? 0.338168] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
> [??? 0.338204] pci 0000:00:00.0: calling pci_fixup_ide_bases+0x0/0x4c
> [??? 0.338259] pci 0000:00:00.0: supports D1
> [??? 0.338267] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
> [??? 0.338276] pci 0000:00:00.0: PME# disabled
> [??? 0.338512] pci_bus 0000:00: fixups for bus
> [??? 0.338525] PCI: bus0: Fast back to back transfers disabled
> [??? 0.338541] pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 0
> [??? 0.338673] pci_bus 0000:01: scanning bus
> [??? 0.338773] pci 0000:01:00.0: [10b5:8604] type 01 class 0x060400
> [??? 0.338816] pci 0000:01:00.0: calling ventana_pciesw_early_fixup+0x0/0xa4
> [??? 0.467817] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x0001ffff]
> [??? 0.467999] pci 0000:01:00.0: calling pci_fixup_ide_bases+0x0/0x4c
> [??? 0.468467] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
> [??? 0.468491] pci 0000:01:00.0: PME# disabled
> [??? 0.468795] pci_bus 0000:01: fixups for bus
> [??? 0.468854] PCI: bus1: Fast back to back transfers disabled
> [??? 0.468877] pci 0000:01:00.0: scanning [bus 00-00] behind bridge, pass 0
> [??? 0.468886] pci 0000:01:00.0: bridge configuration invalid ([bus
> 00-00]), reconfiguring
> [??? 0.468939] pci 0000:01:00.0: scanning [bus 00-00] behind bridge, pass 1
> [??? 0.469265] pci_bus 0000:02: busn_res: can not insert [bus 02-01]
> under [bus 01] (conflicts with (null) [bus 01])
> [??? 0.469282] pci_bus 0000:02: scanning bus
> [??? 0.469554] pci_bus 0000:02: fixups for bus
> [??? 0.469559] PCI: bus2: Fast back to back transfers enabled
> [??? 0.469572] pci_bus 0000:02: bus scan returning with max=02
> [??? 0.469582] pci_bus 0000:02: busn_res: [bus 02-01] end is updated to 02
> [??? 0.469593] pci_bus 0000:02: busn_res: can not insert [bus 02]
> under [bus 01] (conflicts with (null) [bus 01])
> [??? 0.469615] pci_bus 0000:02: [bus 02] partially hidden behind
> bridge 0000:01 [bus 01]
> [??? 0.469636] pci_bus 0000:01: bus scan returning with max=02
> [??? 0.469643] pci 0000:00:00.0: bridge has subordinate 01 but max busn 02
> [??? 0.469661] pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 1
> [??? 0.469671] pci_bus 0000:00: bus scan returning with max=01
> [??? 0.469791] pci 0000:00:00.0: fixup irq: got 298
> [??? 0.469800] pci 0000:00:00.0: assigning IRQ 298
> [??? 0.469849] pci 0000:01:00.0: fixup irq: got 298
> [??? 0.469856] pci 0000:01:00.0: assigning IRQ 298
> [??? 0.469946] pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
> [??? 0.469965] pci 0000:00:00.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
> [??? 0.469980] pci 0000:00:00.0: BAR 6: assigned [mem
> 0x01200000-0x0120ffff pref]
> [??? 0.469997] pci 0000:01:00.0: BAR 0: assigned [mem 0x01100000-0x0111ffff]
> [??? 0.470026] pci 0000:01:00.0: PCI bridge to [bus 02]
> [??? 0.470108] pci 0000:00:00.0: PCI bridge to [bus 01]
> [??? 0.470121] pci 0000:00:00.0:?? bridge window [mem 0x01100000-0x011fffff]
> [??? 0.470381] pcieport 0000:00:00.0: Signaling PME through PCIe PME
> interrupt
> [??? 0.470397] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
> [??? 0.470412] pcie_pme 0000:00:00.0:pcie001: service driver pcie_pme loaded
> [??? 0.470660] pcieport 0000:01:00.0: enabling device (0140 -> 0142)
> [??? 0.470788] pcieport 0000:01:00.0: enabling bus mastering
>
>
>
> [ Node 4 | node-4 ] lspci -tv
> -[0000:00]---00.0-[01]----00.0-[02]--
> [ Node 4 | node-4 ]
>
>
>
> [ Node 4 | node-4 ] lspci -v
> 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00
> [Normal decode])
> ??? Flags: bus master, fast devsel, latency 0, IRQ 298
> ??? Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
> ??? Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> ??? I/O behind bridge: None
> ??? Memory behind bridge: 01100000-011fffff [size=1M]
> ??? Prefetchable memory behind bridge: None
> ??? [virtual] Expansion ROM at 01200000 [disabled] [size=64K]
> ??? Capabilities: [40] Power Management version 3
> ??? Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
> ??? Capabilities: [70] Express Root Port (Slot-), MSI 00
> ??? Capabilities: [100] Advanced Error Reporting
> ??? Capabilities: [140] Virtual Channel
> ??? Kernel driver in use: pcieport
> lspci: Unable to load libkmod resources: error -12
>
> 01:00.0 PCI bridge: PLX Technology, Inc. PEX 8604 4-lane, 4-Port PCI
> Express Gen 2 (5.0 GT/s) Switch (rev ba) (prog-if 00 [Normal
> decode])
> ??? Flags: bus master, fast devsel, latency 0, IRQ 298
> ??? Memory at 01100000 (32-bit, non-prefetchable) [size=128K]
> ??? Bus: primary=01, secondary=02, subordinate=02, sec-latency=0
> ??? I/O behind bridge: None
> ??? Memory behind bridge: None
> ??? Prefetchable memory behind bridge: None
> ??? Capabilities: [40] Power Management version 3
> ??? Capabilities: [48] MSI: Enable- Count=1/4 Maskable+ 64bit+
> ??? Capabilities: [68] Express Upstream Port, MSI 00
> ??? Capabilities: [a4] Subsystem: PLX Technology, Inc. PEX 8604
> 4-lane, 4-Port PCI Express Gen 2 (5.0 GT/s) Switch
> ??? Capabilities: [100] Device Serial Number ba-86-01-10-b5-df-0e-00
> ??? Capabilities: [fb4] Advanced Error Reporting
> ??? Capabilities: [138] Power Budgeting <?>
> ??? Capabilities: [148] Virtual Channel
> ??? Capabilities: [448] Vendor Specific Information: ID=0000 Rev=0
> Len=0cc <?>
> ??? Capabilities: [950] Vendor Specific Information: ID=0001 Rev=0
> Len=010 <?>
> ??? Kernel driver in use: pcieport
> [ Node 4 | node-4 ]
^ permalink raw reply
* [v2 PATCH 3/6] dt-bindings: usb: mtu3: update USB wakeup properties
From: Rob Herring @ 2018-01-05 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9ded06bb1264f2c05ba7f52ecf1619d5e595d80f.1514967463.git.chunfeng.yun@mediatek.com>
On Wed, Jan 03, 2018 at 04:53:19PM +0800, Chunfeng Yun wrote:
> Add two arguments in "mediatek,syscon-wakeup" to support multi
> wakeup glue layer between SSUSB and SPM, and use standard property
> "wakeup-source" to replace the private "mediatek,enable-wakeup"
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> Documentation/devicetree/bindings/usb/mediatek,mtu3.txt | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v7 05/10] PCI: Add support for relative addressing in quirk tables
From: Catalin Marinas @ 2018-01-05 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180102200549.22984-6-ard.biesheuvel@linaro.org>
On Tue, Jan 02, 2018 at 08:05:44PM +0000, Ard Biesheuvel wrote:
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 10684b17d0bd..b6d51b4d5ce1 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3556,9 +3556,16 @@ static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
> f->vendor == (u16) PCI_ANY_ID) &&
> (f->device == dev->device ||
> f->device == (u16) PCI_ANY_ID)) {
> - calltime = fixup_debug_start(dev, f->hook);
> - f->hook(dev);
> - fixup_debug_report(dev, calltime, f->hook);
> + void (*hook)(struct pci_dev *dev);
> +#ifdef CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
> + hook = (void *)((unsigned long)&f->hook_offset +
> + f->hook_offset);
> +#else
> + hook = f->hook;
> +#endif
More of a nitpick but I've seen this pattern in several places in your
code, maybe worth defining a macro (couldn't come up with a better
name):
#define offset_to_ptr(off) \
((void *)((unsigned long)&(off) + (off)))
--
Catalin
^ permalink raw reply
* [PATCH v5 1/2] PCI: mediatek: Clear IRQ status after IRQ dispatched to avoid reentry
From: Marc Zyngier @ 2018-01-05 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515153107.25872.57.camel@mhfsdcap03>
On 05/01/18 11:51, Honghui Zhang wrote:
> On Thu, 2018-01-04 at 19:04 +0000, Marc Zyngier wrote:
>> On 04/01/18 18:40, Lorenzo Pieralisi wrote:
>>> [+Marc]
>>>
>>> On Wed, Dec 27, 2017 at 08:59:53AM +0800, honghui.zhang at mediatek.com wrote:
>>>> From: Honghui Zhang <honghui.zhang@mediatek.com>
>>>>
>>>> There maybe a same IRQ reentry scenario after IRQ received in current
>>>> IRQ handle flow:
>>>> EP device PCIe host driver EP driver
>>>> 1. issue an IRQ
>>>> 2. received IRQ
>>>> 3. clear IRQ status
>>>> 4. dispatch IRQ
>>>> 5. clear IRQ source
>>>> The IRQ status was not successfully cleared at step 2 since the IRQ
>>>> source was not cleared yet. So the PCIe host driver may receive the
>>>> same IRQ after step 5. Then there's an IRQ reentry occurred.
>>>> Even worse, if the reentry IRQ was not an IRQ that EP driver expected,
>>>> it may not handle the IRQ. Then we may run into the infinite loop from
>>>> step 2 to step 4.
>>>> Clear the IRQ status after IRQ have been dispatched to avoid the IRQ
>>>> reentry.
>>>> This patch also fix another INTx IRQ issue by initialize the iterate
>>>> before the loop. If an INTx IRQ re-occurred while we are dispatching
>>>> the INTx IRQ, then iterate may start from PCI_NUM_INTX + INTX_SHIFT
>>>> instead of INTX_SHIFT for the second time entering the
>>>> for_each_set_bit_from() loop.
>>>
>>> This looks like two different issues that should be fixed with two
>>> patches.
>
> Ok, I split this into two patches and figure out a more reasonable
> approach by using irq_chip solution.
>
>>>
>>>> Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
>>>> Acked-by: Ryder Lee <ryder.lee@mediatek.com>
>>>> ---
>>>> drivers/pci/host/pcie-mediatek.c | 11 ++++++-----
>>>> 1 file changed, 6 insertions(+), 5 deletions(-)
>>>
>>> For the sake of uniformity, I first want to understand why this
>>> driver does not call:
>>>
>>> chained_irq_enter/exit()
>>>
>>> in the primary handler (mtk_pcie_intr_handler()).
>>>
>>> With the GIC as a primary interrupt controller we have not
>>> even figured out how current code can actually work without
>>> calling the chained_* API.
>>>
>>> I want to come up with a consistent handling of IRQ domains for
>>> all host bridges and any discrepancy should be explained.
>>
>> That's because this driver is a huge hack, see below:
>>
>>>
>>>> diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
>>>> index db93efd..fc29a9a 100644
>>>> --- a/drivers/pci/host/pcie-mediatek.c
>>>> +++ b/drivers/pci/host/pcie-mediatek.c
>>>> @@ -601,15 +601,16 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
>>
>> This function is not a chained irqchip, but an interrupt handler...
>>
>>>> struct mtk_pcie_port *port = (struct mtk_pcie_port *)data;
>>>> unsigned long status;
>>>> u32 virq;
>>>> - u32 bit = INTX_SHIFT;
>>>> + u32 bit;
>>>>
>>>> while ((status = readl(port->base + PCIE_INT_STATUS)) & INTX_MASK) {
>>>> + bit = INTX_SHIFT;
>>>> for_each_set_bit_from(bit, &status, PCI_NUM_INTX + INTX_SHIFT) {
>>>> - /* Clear the INTx */
>>>> - writel(1 << bit, port->base + PCIE_INT_STATUS);
>>>> virq = irq_find_mapping(port->irq_domain,
>>>> bit - INTX_SHIFT);
>>>> generic_handle_irq(virq);
>>
>> and nonetheless, this calls into generic_handle_irq(). That's a complete
>> violation of the interrupt layering. Maybe there is a good reason for
>> it, but I'd like to know which one.
>>
>> Which means that all of the ack/mask has to be done outside of the
>> irqchip framework too... Disgusting.
>>
>>>> + /* Clear the INTx */
>>>> + writel(1 << bit, port->base + PCIE_INT_STATUS);
>>>
>>> I think that these masking/acking should actually be done through
>>> the irq_chip hooks (see for instance pci-ftpci100.c) - that would
>>> make this kind of bugs much easier to prevent (because the IRQ
>>> layer does the sequencing for you).
>>
>> +1.
>>
>
> Thanks for your advice, I need to do some homework to have a better
> understanding of the irq_chip approach.
>
>>> Marc (CC'ed) has a more comprehensive view on this than me - I would
>>> like to get to a point where all host bridges uses a consistent
>>> approach for chained IRQ handling and I hope this bug fix can be
>>> a starting point.
>>
>> +1 again. We definitely need to come up with some form of common
>> approach for all these host drivers, and maybe turn that into a library...
>>
>
> Well, this is beyond my knowledge now, I guess I can figure out how to
> using irq_chip for the first step, then I may following this "common
> approach" after we have a solution for that?
We can help you with that at a later time indeed. the urgent thing is to
fix this driver so that it does the right thing, and we can then look at
using a common approach for a number of them.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v7 05/10] PCI: Add support for relative addressing in quirk tables
From: Ard Biesheuvel @ 2018-01-05 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105174112.jk3mvo5qwg7l4vzo@armageddon.cambridge.arm.com>
On 5 January 2018 at 17:41, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Tue, Jan 02, 2018 at 08:05:44PM +0000, Ard Biesheuvel wrote:
>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> index 10684b17d0bd..b6d51b4d5ce1 100644
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -3556,9 +3556,16 @@ static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
>> f->vendor == (u16) PCI_ANY_ID) &&
>> (f->device == dev->device ||
>> f->device == (u16) PCI_ANY_ID)) {
>> - calltime = fixup_debug_start(dev, f->hook);
>> - f->hook(dev);
>> - fixup_debug_report(dev, calltime, f->hook);
>> + void (*hook)(struct pci_dev *dev);
>> +#ifdef CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
>> + hook = (void *)((unsigned long)&f->hook_offset +
>> + f->hook_offset);
>> +#else
>> + hook = f->hook;
>> +#endif
>
> More of a nitpick but I've seen this pattern in several places in your
> code, maybe worth defining a macro (couldn't come up with a better
> name):
>
> #define offset_to_ptr(off) \
> ((void *)((unsigned long)&(off) + (off)))
>
Yeah, good point. Or even
static inline void *offset_to_ptr(const s32 *off)
{
return (void *)((unsigned long)off + *off);
}
^ permalink raw reply
* [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors
From: Catalin Marinas @ 2018-01-05 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180102200549.22984-8-ard.biesheuvel@linaro.org>
On Tue, Jan 02, 2018 at 08:05:46PM +0000, Ard Biesheuvel wrote:
> diff --git a/arch/arm/include/asm/jump_label.h b/arch/arm/include/asm/jump_label.h
> index e12d7d096fc0..7b05b404063a 100644
> --- a/arch/arm/include/asm/jump_label.h
> +++ b/arch/arm/include/asm/jump_label.h
> @@ -45,5 +45,32 @@ struct jump_entry {
> jump_label_t key;
> };
>
> +static inline jump_label_t jump_entry_code(const struct jump_entry *entry)
> +{
> + return entry->code;
> +}
> +
> +static inline struct static_key *jump_entry_key(const struct jump_entry *entry)
> +{
> + return (struct static_key *)((unsigned long)entry->key & ~1UL);
> +}
> +
> +static inline bool jump_entry_is_branch(const struct jump_entry *entry)
> +{
> + return (unsigned long)entry->key & 1UL;
> +}
> +
> +static inline bool jump_entry_is_module_init(const struct jump_entry *entry)
> +{
> + return entry->code == 0;
> +}
> +
> +static inline void jump_entry_set_module_init(struct jump_entry *entry)
> +{
> + entry->code = 0;
> +}
> +
> +#define jump_label_swap NULL
Is there any difference between these functions on any of the
architectures touched? Even with the relative offset, arm64 and x86
looked the same to me (well, I may have missed some detail).
--
Catalin
^ permalink raw reply
* [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors
From: Ard Biesheuvel @ 2018-01-05 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105175834.vqgpsme7itsdg54u@armageddon.cambridge.arm.com>
On 5 January 2018 at 17:58, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Tue, Jan 02, 2018 at 08:05:46PM +0000, Ard Biesheuvel wrote:
>> diff --git a/arch/arm/include/asm/jump_label.h b/arch/arm/include/asm/jump_label.h
>> index e12d7d096fc0..7b05b404063a 100644
>> --- a/arch/arm/include/asm/jump_label.h
>> +++ b/arch/arm/include/asm/jump_label.h
>> @@ -45,5 +45,32 @@ struct jump_entry {
>> jump_label_t key;
>> };
>>
>> +static inline jump_label_t jump_entry_code(const struct jump_entry *entry)
>> +{
>> + return entry->code;
>> +}
>> +
>> +static inline struct static_key *jump_entry_key(const struct jump_entry *entry)
>> +{
>> + return (struct static_key *)((unsigned long)entry->key & ~1UL);
>> +}
>> +
>> +static inline bool jump_entry_is_branch(const struct jump_entry *entry)
>> +{
>> + return (unsigned long)entry->key & 1UL;
>> +}
>> +
>> +static inline bool jump_entry_is_module_init(const struct jump_entry *entry)
>> +{
>> + return entry->code == 0;
>> +}
>> +
>> +static inline void jump_entry_set_module_init(struct jump_entry *entry)
>> +{
>> + entry->code = 0;
>> +}
>> +
>> +#define jump_label_swap NULL
>
> Is there any difference between these functions on any of the
> architectures touched? Even with the relative offset, arm64 and x86
> looked the same to me (well, I may have missed some detail).
>
No, the latter two are identical everywhere, and the others are the
same modulo absolute vs relative.
The issue is that the struct definition is per-arch so the accessors
should be as well. Perhaps I should introduce two variants two
asm-generic, similar to how we have different flavors of unaligned
accessors.
^ permalink raw reply
* [PATCH 2/5] clk: lpc32xx: read-only divider can propagate rate change
From: Vladimir Zapolskiy @ 2018-01-05 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105170959.17266-3-jbrunet@baylibre.com>
Hi Jerome,
On 01/05/2018 07:09 PM, Jerome Brunet wrote:
> When a divider clock has CLK_DIVIDER_READ_ONLY set, it means that the
> register shall be left un-touched, but it does not mean the clock
> should stop rate propagation if CLK_SET_RATE_PARENT is set
>
okay, the statement sounds correct, but there is no such clocks on LPC32xx,
thus I hardly can confirm that adding dead/inapplicable code is a fix.
> This properly handled in qcom clk-regmap-divider but it was not in the
> lpc32xx divider
>
> Fixes: f7c82a60ba26 ("clk: lpc32xx: add common clock framework driver")
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
I would suggest to drop two LPC32xx clock driver changes from the series.
--
With best wishes,
Vladimir
^ permalink raw reply
* [GIT PULL 1/4] soc changes for omaps for v4.16, part 2
From: Tony Lindgren @ 2018-01-05 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105065916.snklnojvp5tshpvl@localhost>
* Olof Johansson <olof@lixom.net> [180105 07:38]:
> On Fri, Dec 22, 2017 at 10:14:24AM -0800, Tony Lindgren wrote:
> > From: "Tony Lindgren" <tony@atomide.com>
> > Tony Lindgren (1):
> > ARM: OMAP2+: Drop unused legacy data for prcm_reg_id and module_bit
>
> Nice cleanup. Merged. It had a conflict with an earlier fixes branch, please
> double-check my resolution.
Thanks looks good to me.
Regards,
Tony
^ permalink raw reply
* [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors
From: Catalin Marinas @ 2018-01-05 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8zROE-TDpfbbVi3RPOr8BNcsN_s27Gr-VvMN+-eMU+Hg@mail.gmail.com>
On Fri, Jan 05, 2018 at 06:01:33PM +0000, Ard Biesheuvel wrote:
> On 5 January 2018 at 17:58, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Tue, Jan 02, 2018 at 08:05:46PM +0000, Ard Biesheuvel wrote:
> >> diff --git a/arch/arm/include/asm/jump_label.h b/arch/arm/include/asm/jump_label.h
> >> index e12d7d096fc0..7b05b404063a 100644
> >> --- a/arch/arm/include/asm/jump_label.h
> >> +++ b/arch/arm/include/asm/jump_label.h
> >> @@ -45,5 +45,32 @@ struct jump_entry {
> >> jump_label_t key;
> >> };
> >>
> >> +static inline jump_label_t jump_entry_code(const struct jump_entry *entry)
> >> +{
> >> + return entry->code;
> >> +}
> >> +
> >> +static inline struct static_key *jump_entry_key(const struct jump_entry *entry)
> >> +{
> >> + return (struct static_key *)((unsigned long)entry->key & ~1UL);
> >> +}
> >> +
> >> +static inline bool jump_entry_is_branch(const struct jump_entry *entry)
> >> +{
> >> + return (unsigned long)entry->key & 1UL;
> >> +}
> >> +
> >> +static inline bool jump_entry_is_module_init(const struct jump_entry *entry)
> >> +{
> >> + return entry->code == 0;
> >> +}
> >> +
> >> +static inline void jump_entry_set_module_init(struct jump_entry *entry)
> >> +{
> >> + entry->code = 0;
> >> +}
> >> +
> >> +#define jump_label_swap NULL
> >
> > Is there any difference between these functions on any of the
> > architectures touched? Even with the relative offset, arm64 and x86
> > looked the same to me (well, I may have missed some detail).
>
> No, the latter two are identical everywhere, and the others are the
> same modulo absolute vs relative.
>
> The issue is that the struct definition is per-arch so the accessors
> should be as well.
Up to this patch, even the jump_entry structure is the same on all
architectures (the jump_label_t type differs).
With relative offset, can you not just define jump_label_t to s32? At a
quick grep in mainline, it doesn't seem to be used outside the structure
definition.
> Perhaps I should introduce two variants two asm-generic, similar to
> how we have different flavors of unaligned accessors.
You could as well define them directly in kernel/jump_label.h or, if
used outside this file, include/linux/jump_label.h.
--
Catalin
^ permalink raw reply
* [PATCH v5 04/13] arm64: kernel: Survive corrected RAS errors notified by SError
From: James Morse @ 2018-01-05 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <43942acd-f6ff-ec58-aafb-a6f3ba40fab9@huawei.com>
Hi gengdongjiu,
On 16/12/17 02:53, gengdongjiu wrote:
>
> On 2017/12/15 23:50, James Morse wrote:
>> +asmlinkage void do_serror(struct pt_regs *regs, unsigned int esr)
>> +{
>> + nmi_enter();
>
> How about firstly let APEI kernel driver to handle it by adding patch[1]? if the handling is successful, do_serror() direct return;
> Otherwise continue check the ESR value, for example:
> if (!ghes_notify_sei())
> return;
This is where I think we will end up. Adding that could should be part of a
future firmware-first series.
We can't do it until APEI can share its in_nmi() path with multiple users. (what
happens if we take an SError while handling an NOTIFY_SEA).
I still haven't managed to get the RFC of what I think is required out.
(I need this for SDEI too),
>> +
>> + /* non-RAS errors are not containable */
>> + if (!arm64_is_ras_serror(esr) || arm64_is_fatal_ras_serror(regs, esr))
>> + arm64_serror_panic(regs, esr);
>>
>> - panic("Asynchronous SError Interrupt");
>> + nmi_exit();
>> }
Thanks,
James
^ permalink raw reply
* [PATCH v5 04/13] arm64: kernel: Survive corrected RAS errors notified by SError
From: James Morse @ 2018-01-05 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <720fa5cc-93a9-8844-c2f3-83116a724d1b@huawei.com>
Hi gengdongjiu,
On 16/12/17 04:51, gengdongjiu wrote:
> On 2017/12/16 12:08, gengdongjiu wrote:
>> On 2017/12/15 23:50, James Morse wrote:
>>> + case ESR_ELx_AET_UER: /* Uncorrected Recoverable */
>>> + /*
>>> + * The CPU can't make progress. The exception may have
>>> + * been imprecise.
>>> + */
>>> + return true;
>> For Recoverable error (UER), the error has not been silently propagated,
>> and has not been architecturally consumed by the PE, and
>> The exception is precise and PE can recover execution from the preferred return address of the exception.
>> so I do not think it should be panic here if the SError come from user space instead of coming from kernel space.
'coming from' doesn't mean an awful lot unless we know what the error is.
To repeat the earlier examples, it could be a fault in the page tables, or pages
shared between processes, e.g. the vdso data page.
I don't want this crude panic/continue to consider anything other than the ESR.
Lets keep it crude, its a stop-gap: both kernel-first and firmware-first can do
a better job - this is just some glue to hold things together until we have
one/both implemented.
[...]
> Recoverable error (UER)
> The state of the PE is Recoverable if all of the following are true:
> ? The error has not been silently propagated.
> ? The error has not been architecturally consumed by the PE. (The PE architectural state is not infected.)
> ? The exception is precise and PE can recover execution from the preferred return address of the exception, if software locates and repairs the error.
It's this bit that made me err on the side of caution/panic():
> The PE cannot make correct progress without either consuming the error or
> otherwise making the error unrecoverable. The error remains latent in the system.
Without firmware-first or kernel-first we can't know where the error is. What
should we do?:
> If software cannot locate and repair the error, either the application or the
> VM, or both, must be isolated by software.
Thanks,
James
^ permalink raw reply
* [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors
From: Ard Biesheuvel @ 2018-01-05 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105182229.pjnlq3l5hzfac4na@armageddon.cambridge.arm.com>
On 5 January 2018 at 18:22, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Fri, Jan 05, 2018 at 06:01:33PM +0000, Ard Biesheuvel wrote:
>> On 5 January 2018 at 17:58, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> > On Tue, Jan 02, 2018 at 08:05:46PM +0000, Ard Biesheuvel wrote:
>> >> diff --git a/arch/arm/include/asm/jump_label.h b/arch/arm/include/asm/jump_label.h
>> >> index e12d7d096fc0..7b05b404063a 100644
>> >> --- a/arch/arm/include/asm/jump_label.h
>> >> +++ b/arch/arm/include/asm/jump_label.h
>> >> @@ -45,5 +45,32 @@ struct jump_entry {
>> >> jump_label_t key;
>> >> };
>> >>
>> >> +static inline jump_label_t jump_entry_code(const struct jump_entry *entry)
>> >> +{
>> >> + return entry->code;
>> >> +}
>> >> +
>> >> +static inline struct static_key *jump_entry_key(const struct jump_entry *entry)
>> >> +{
>> >> + return (struct static_key *)((unsigned long)entry->key & ~1UL);
>> >> +}
>> >> +
>> >> +static inline bool jump_entry_is_branch(const struct jump_entry *entry)
>> >> +{
>> >> + return (unsigned long)entry->key & 1UL;
>> >> +}
>> >> +
>> >> +static inline bool jump_entry_is_module_init(const struct jump_entry *entry)
>> >> +{
>> >> + return entry->code == 0;
>> >> +}
>> >> +
>> >> +static inline void jump_entry_set_module_init(struct jump_entry *entry)
>> >> +{
>> >> + entry->code = 0;
>> >> +}
>> >> +
>> >> +#define jump_label_swap NULL
>> >
>> > Is there any difference between these functions on any of the
>> > architectures touched? Even with the relative offset, arm64 and x86
>> > looked the same to me (well, I may have missed some detail).
>>
>> No, the latter two are identical everywhere, and the others are the
>> same modulo absolute vs relative.
>>
>> The issue is that the struct definition is per-arch so the accessors
>> should be as well.
>
> Up to this patch, even the jump_entry structure is the same on all
> architectures (the jump_label_t type differs).
>
> With relative offset, can you not just define jump_label_t to s32? At a
> quick grep in mainline, it doesn't seem to be used outside the structure
> definition.
>
I think we can just remove jump_label_t entirely, and replace it with
unsigned long for absolute, and s32 for relative. Maybe I am missing
something, but things like
#ifdef CONFIG_X86_64
typedef u64 jump_label_t;
#else
typedef u32 jump_label_t;
#endif
seem a bit pointless to me anyway.
>> Perhaps I should introduce two variants two asm-generic, similar to
>> how we have different flavors of unaligned accessors.
>
> You could as well define them directly in kernel/jump_label.h or, if
> used outside this file, include/linux/jump_label.h.
>
Perhaps I should define a Kconfig symbol after all for relative jump
labels, and just keep everything in the same file. The question is
whether I should use CONFIG_HAVE_ARCH_PREL32_RELOCATIONS for this as
well.
^ permalink raw reply
* [v2 PATCH 5/6] dt-bindings: usb: mtk-xhci: update USB wakeup properties
From: Rob Herring @ 2018-01-05 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7c7f69a3981b5117f7c8cc14b19c3459a50403ef.1514967463.git.chunfeng.yun@mediatek.com>
On Wed, Jan 03, 2018 at 04:53:21PM +0800, Chunfeng Yun wrote:
> Add two arguments in "mediatek,syscon-wakeup" to support multi
> wakeup glue layer between SSUSB and SPM, and use standard property
> "wakeup-source" to replace the private "mediatek,wakeup-src"
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> .../devicetree/bindings/usb/mediatek,mtk-xhci.txt | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [GIT PULL 1/3] ARM: Keystone DTS for 4.16
From: santosh.shilimkar at oracle.com @ 2018-01-05 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105071233.dlgob4hufvstuwi4@localhost>
On 1/4/18 11:12 PM, Olof Johansson wrote:
> On Wed, Dec 27, 2017 at 06:07:50PM -0800, Santosh Shilimkar wrote:
>> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>>
>> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>>
>> are available in the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/keystone_dts_for_4.16
>>
>> for you to fetch changes up to 4fe85b0cdd06f8fef2631923799bdc95380badb5:
>>
>> ARM: dts: keystone-k2l-clocks: Add missing unit name to clock nodes that have regs (2017-12-16 14:36:57 -0800)
>>
>> ----------------------------------------------------------------
>> ARM: Keystone DTS update for 4.16
>>
>> - Enable GPIO bank2 for K2L
>> - Enable QSPI for K2G & K2G-EVM
>> - Enable UART1/2 for K2G & K2G-EVM
>> - Enable peripherals for K2G-ICE
>> - Fix C1 and C2 DTS warnings
>
> Merged, thanks.
>
Thanks !!
^ permalink raw reply
* [PATCH v2 1/7] drm/panel: simple: add support for Ampire AM-800480AYTZQW-00H
From: Rob Herring @ 2018-01-05 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515046345-15881-2-git-send-email-jagan@amarulasolutions.com>
On Thu, Jan 04, 2018 at 11:42:19AM +0530, Jagan Teki wrote:
> This adds support for the Ampire AM-800480AYTZQW-00H 7.0" WGA LCD,
> which can be supported by the simple panel driver.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v2:
> - Updated binding info about optional properties, node and example
>
> .../display/panel/ampire,am-800480aytzqw-00h.txt | 25 ++++++++++++++++++++
Reviewed-by: Rob Herring <robh@kernel.org>
> drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++++++++
> 2 files changed, 52 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am-800480aytzqw-00h.txt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox