* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
From: Michael S. Tsirkin @ 2019-09-11 12:08 UTC (permalink / raw)
To: Michal Hocko
Cc: Yang Zhang, Pankaj Gupta, kvm list, David Hildenbrand,
Catalin Marinas, Alexander Duyck, lcapitulino, linux-mm,
Alexander Duyck, will, Andrea Arcangeli, virtio-dev, Rik van Riel,
Matthew Wilcox, Wang, Wei W, ying.huang, Konrad Rzeszutek Wilk,
Dan Williams, linux-arm-kernel, Oscar Salvador,
Nitesh Narayan Lal, Dave Hansen, LKML, Paolo Bonzini,
Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <20190911113619.GP4023@dhcp22.suse.cz>
On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> [...]
> > We don't put any limitations on the allocator other then that it needs to
> > clean up the metadata on allocation, and that it cannot allocate a page
> > that is in the process of being reported since we pulled it from the
> > free_list. If the page is a "Reported" page then it decrements the
> > reported_pages count for the free_area and makes sure the page doesn't
> > exist in the "Boundary" array pointer value, if it does it moves the
> > "Boundary" since it is pulling the page.
>
> This is still a non-trivial limitation on the page allocation from an
> external code IMHO. I cannot give any explicit reason why an ordering on
> the free list might matter (well except for page shuffling which uses it
> to make physical memory pattern allocation more random) but the
> architecture seems hacky and dubious to be honest. It shoulds like the
> whole interface has been developed around a very particular and single
> purpose optimization.
>
> I remember that there was an attempt to report free memory that provided
> a callback mechanism [1], which was much less intrusive to the internals
> of the allocator yet it should provide a similar functionality. Did you
> see that approach? How does this compares to it? Or am I completely off
> when comparing them?
>
> [1] mostly likely not the latest version of the patchset
> http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
>
> --
> Michal Hocko
> SUSE Labs
Linus nacked that one. He thinks invoking callbacks with lots of
internal mm locks is too fragile.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
From: Michal Hocko @ 2019-09-11 12:19 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Yang Zhang, Pankaj Gupta, kvm list, David Hildenbrand,
Catalin Marinas, Alexander Duyck, lcapitulino, linux-mm,
Alexander Duyck, will, Andrea Arcangeli, virtio-dev, Rik van Riel,
Matthew Wilcox, Wang, Wei W, ying.huang, Konrad Rzeszutek Wilk,
Dan Williams, linux-arm-kernel, Oscar Salvador,
Nitesh Narayan Lal, Dave Hansen, LKML, Paolo Bonzini,
Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <20190911080804-mutt-send-email-mst@kernel.org>
On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
> > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > [...]
> > > We don't put any limitations on the allocator other then that it needs to
> > > clean up the metadata on allocation, and that it cannot allocate a page
> > > that is in the process of being reported since we pulled it from the
> > > free_list. If the page is a "Reported" page then it decrements the
> > > reported_pages count for the free_area and makes sure the page doesn't
> > > exist in the "Boundary" array pointer value, if it does it moves the
> > > "Boundary" since it is pulling the page.
> >
> > This is still a non-trivial limitation on the page allocation from an
> > external code IMHO. I cannot give any explicit reason why an ordering on
> > the free list might matter (well except for page shuffling which uses it
> > to make physical memory pattern allocation more random) but the
> > architecture seems hacky and dubious to be honest. It shoulds like the
> > whole interface has been developed around a very particular and single
> > purpose optimization.
> >
> > I remember that there was an attempt to report free memory that provided
> > a callback mechanism [1], which was much less intrusive to the internals
> > of the allocator yet it should provide a similar functionality. Did you
> > see that approach? How does this compares to it? Or am I completely off
> > when comparing them?
> >
> > [1] mostly likely not the latest version of the patchset
> > http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
>
> Linus nacked that one. He thinks invoking callbacks with lots of
> internal mm locks is too fragile.
I would be really curious how much he would be happy about injecting
other restrictions on the allocator like this patch proposes. This is
more intrusive as it has a higher maintenance cost longterm IMHO.
--
Michal Hocko
SUSE Labs
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/6] phy: meson-g12a-usb3-pcie: Add support for PCIe mode
From: Andrew Murray @ 2019-09-11 12:19 UTC (permalink / raw)
To: Neil Armstrong
Cc: lorenzo.pieralisi, khilman, linux-pci, linux-kernel, kishon, repk,
maz, bhelgaas, linux-amlogic, yue.wang, linux-arm-kernel
In-Reply-To: <1567950178-4466-5-git-send-email-narmstrong@baylibre.com>
On Sun, Sep 08, 2019 at 01:42:56PM +0000, Neil Armstrong wrote:
> This adds extended PCIe PHY functions for the Amlogic G12A
> USB3+PCIE Combo PHY to support reset, power_on and power_off for
> PCIe exclusively.
>
> With these callbacks, we can handle all the needed operations of the
> Amlogic PCIe controller driver.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../phy/amlogic/phy-meson-g12a-usb3-pcie.c | 70 ++++++++++++++++---
> 1 file changed, 61 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c b/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
> index ac322d643c7a..08e322789e59 100644
> --- a/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
> +++ b/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
> @@ -50,6 +50,8 @@
> #define PHY_R5_PHY_CR_ACK BIT(16)
> #define PHY_R5_PHY_BS_OUT BIT(17)
>
> +#define PCIE_RESET_DELAY 500
> +
> struct phy_g12a_usb3_pcie_priv {
> struct regmap *regmap;
> struct regmap *regmap_cr;
> @@ -196,6 +198,10 @@ static int phy_g12a_usb3_init(struct phy *phy)
> struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
> int data, ret;
>
> + ret = reset_control_reset(priv->reset);
> + if (ret)
> + return ret;
> +
Right, so we've moved this to apply to USB only, thus assuming PCI will
call .reset for its reset (why the asymmetry?).
Thanks,
Andrew Murray
> /* Switch PHY to USB3 */
> /* TODO figure out how to handle when PCIe was set in the bootloader */
> regmap_update_bits(priv->regmap, PHY_R0,
> @@ -272,24 +278,64 @@ static int phy_g12a_usb3_init(struct phy *phy)
> return 0;
> }
>
> -static int phy_g12a_usb3_pcie_init(struct phy *phy)
> +static int phy_g12a_usb3_pcie_power_on(struct phy *phy)
> +{
> + struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
> +
> + if (priv->mode == PHY_TYPE_USB3)
> + return 0;
> +
> + regmap_update_bits(priv->regmap, PHY_R0,
> + PHY_R0_PCIE_POWER_STATE,
> + FIELD_PREP(PHY_R0_PCIE_POWER_STATE, 0x1c));
> +
> + return 0;
> +}
> +
> +static int phy_g12a_usb3_pcie_power_off(struct phy *phy)
> +{
> + struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
> +
> + if (priv->mode == PHY_TYPE_USB3)
> + return 0;
> +
> + regmap_update_bits(priv->regmap, PHY_R0,
> + PHY_R0_PCIE_POWER_STATE,
> + FIELD_PREP(PHY_R0_PCIE_POWER_STATE, 0x1d));
> +
> + return 0;
> +}
> +
> +static int phy_g12a_usb3_pcie_reset(struct phy *phy)
> {
> struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
> int ret;
>
> - ret = reset_control_reset(priv->reset);
> + if (priv->mode == PHY_TYPE_USB3)
> + return 0;
> +
> + ret = reset_control_assert(priv->reset);
> if (ret)
> return ret;
>
> + udelay(PCIE_RESET_DELAY);
> +
> + ret = reset_control_deassert(priv->reset);
> + if (ret)
> + return ret;
> +
> + udelay(PCIE_RESET_DELAY);
> +
> + return 0;
> +}
> +
> +static int phy_g12a_usb3_pcie_init(struct phy *phy)
> +{
> + struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
> +
> if (priv->mode == PHY_TYPE_USB3)
> return phy_g12a_usb3_init(phy);
>
> - /* Power UP PCIE */
> - /* TODO figure out when the bootloader has set USB3 mode before */
> - regmap_update_bits(priv->regmap, PHY_R0,
> - PHY_R0_PCIE_POWER_STATE,
> - FIELD_PREP(PHY_R0_PCIE_POWER_STATE, 0x1c));
> -
> return 0;
> }
>
> @@ -297,7 +343,10 @@ static int phy_g12a_usb3_pcie_exit(struct phy *phy)
> {
> struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
>
> - return reset_control_reset(priv->reset);
> + if (priv->mode == PHY_TYPE_USB3)
> + return reset_control_reset(priv->reset);
> +
> + return 0;
> }
>
> static struct phy *phy_g12a_usb3_pcie_xlate(struct device *dev,
> @@ -326,6 +375,9 @@ static struct phy *phy_g12a_usb3_pcie_xlate(struct device *dev,
> static const struct phy_ops phy_g12a_usb3_pcie_ops = {
> .init = phy_g12a_usb3_pcie_init,
> .exit = phy_g12a_usb3_pcie_exit,
> + .power_on = phy_g12a_usb3_pcie_power_on,
> + .power_off = phy_g12a_usb3_pcie_power_off,
> + .reset = phy_g12a_usb3_pcie_reset,
> .owner = THIS_MODULE,
> };
>
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] clk: at91: select parent if main oscillator or bypass is enabled
From: Alexandre Belloni @ 2019-09-11 12:21 UTC (permalink / raw)
To: Eugen.Hristev
Cc: sboyd, mturquette, linux-kernel, Ludovic.Desroches, linux-clk,
linux-arm-kernel
In-Reply-To: <1568042692-11784-2-git-send-email-eugen.hristev@microchip.com>
On 09/09/2019 15:30:34+0000, Eugen.Hristev@microchip.com wrote:
> From: Eugen Hristev <eugen.hristev@microchip.com>
>
> Selecting the right parent for the main clock is done using only
> main oscillator enabled bit.
> In case we have this oscillator bypassed by an external signal (no driving
> on the XOUT line), we still use external clock, but with BYPASS bit set.
> So, in this case we must select the same parent as before.
> Create a macro that will select the right parent considering both bits from
> the MOR register.
> Use this macro when looking for the right parent.
>
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> drivers/clk/at91/clk-main.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/at91/clk-main.c b/drivers/clk/at91/clk-main.c
> index ebe9b99..87083b3 100644
> --- a/drivers/clk/at91/clk-main.c
> +++ b/drivers/clk/at91/clk-main.c
> @@ -21,6 +21,10 @@
>
> #define MOR_KEY_MASK (0xff << 16)
>
> +#define clk_main_parent_select(s) (((s) & \
> + (AT91_PMC_MOSCEN | \
> + AT91_PMC_OSCBYPASS)) ? 1 : 0)
> +
> struct clk_main_osc {
> struct clk_hw hw;
> struct regmap *regmap;
> @@ -113,7 +117,7 @@ static int clk_main_osc_is_prepared(struct clk_hw *hw)
>
> regmap_read(regmap, AT91_PMC_SR, &status);
>
> - return (status & AT91_PMC_MOSCS) && (tmp & AT91_PMC_MOSCEN);
> + return (status & AT91_PMC_MOSCS) && clk_main_parent_select(tmp);
> }
>
> static const struct clk_ops main_osc_ops = {
> @@ -450,7 +454,7 @@ static u8 clk_sam9x5_main_get_parent(struct clk_hw *hw)
>
> regmap_read(clkmain->regmap, AT91_CKGR_MOR, &status);
>
> - return status & AT91_PMC_MOSCEN ? 1 : 0;
> + return clk_main_parent_select(status);
> }
>
> static const struct clk_ops sam9x5_main_ops = {
> @@ -492,7 +496,7 @@ at91_clk_register_sam9x5_main(struct regmap *regmap,
> clkmain->hw.init = &init;
> clkmain->regmap = regmap;
> regmap_read(clkmain->regmap, AT91_CKGR_MOR, &status);
> - clkmain->parent = status & AT91_PMC_MOSCEN ? 1 : 0;
> + clkmain->parent = clk_main_parent_select(status);
>
> hw = &clkmain->hw;
> ret = clk_hw_register(NULL, &clkmain->hw);
> --
> 2.7.4
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: pci: amlogic,meson-pcie: Add G12A bindings
From: Andrew Murray @ 2019-09-11 12:22 UTC (permalink / raw)
To: Neil Armstrong
Cc: devicetree, lorenzo.pieralisi, khilman, linux-pci, linux-kernel,
kishon, repk, maz, bhelgaas, linux-amlogic, yue.wang,
linux-arm-kernel
In-Reply-To: <1567950178-4466-2-git-send-email-narmstrong@baylibre.com>
On Sun, Sep 08, 2019 at 01:42:53PM +0000, Neil Armstrong wrote:
> Add PCIE bindings for the Amlogic G12A SoC, the support is the same
> but the PHY is shared with USB3 to control the differential lines.
>
> Thus this adds a phy phandle to control the PHY, and sets invalid
> MIPI clock as optional for G12A.
Perhaps reword to "Thus this adds a phy phandle to control the PHY,
and only requires a MIPI clock for AXG SoC Family".
Thanks,
Andrew Murray
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../devicetree/bindings/pci/amlogic,meson-pcie.txt | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
> index efa2c8b9b85a..84fdc422792e 100644
> --- a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
> @@ -9,13 +9,16 @@ Additional properties are described here:
>
> Required properties:
> - compatible:
> - should contain "amlogic,axg-pcie" to identify the core.
> + should contain :
> + - "amlogic,axg-pcie" for AXG SoC Family
> + - "amlogic,g12a-pcie" for G12A SoC Family
> + to identify the core.
> - reg:
> should contain the configuration address space.
> - reg-names: Must be
> - "elbi" External local bus interface registers
> - "cfg" Meson specific registers
> - - "phy" Meson PCIE PHY registers
> + - "phy" Meson PCIE PHY registers for AXG SoC Family
> - "config" PCIe configuration space
> - reset-gpios: The GPIO to generate PCIe PERST# assert and deassert signal.
> - clocks: Must contain an entry for each entry in clock-names.
> @@ -23,12 +26,13 @@ Required properties:
> - "pclk" PCIe GEN 100M PLL clock
> - "port" PCIe_x(A or B) RC clock gate
> - "general" PCIe Phy clock
> - - "mipi" PCIe_x(A or B) 100M ref clock gate
> + - "mipi" PCIe_x(A or B) 100M ref clock gate for AXG SoC Family
> - resets: phandle to the reset lines.
> - reset-names: must contain "phy" "port" and "apb"
> - - "phy" Share PHY reset
> + - "phy" Share PHY reset for AXG SoC Family
> - "port" Port A or B reset
> - "apb" Share APB reset
> +- phys: should contain a phandle to the shared phy for G12A SoC Family
> - device_type:
> should be "pci". As specified in designware-pcie.txt
>
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
From: Michal Hocko @ 2019-09-11 12:25 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Yang Zhang, Pankaj Gupta, kvm list, David Hildenbrand,
Catalin Marinas, Alexander Duyck, lcapitulino, linux-mm,
Alexander Duyck, will, Andrea Arcangeli, virtio-dev, Rik van Riel,
Matthew Wilcox, Wang, Wei W, ying.huang, Konrad Rzeszutek Wilk,
Dan Williams, linux-arm-kernel, Oscar Salvador,
Nitesh Narayan Lal, Dave Hansen, LKML, Paolo Bonzini,
Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <20190911121941.GU4023@dhcp22.suse.cz>
On Wed 11-09-19 14:19:41, Michal Hocko wrote:
> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
> > On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
> > > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > > [...]
> > > > We don't put any limitations on the allocator other then that it needs to
> > > > clean up the metadata on allocation, and that it cannot allocate a page
> > > > that is in the process of being reported since we pulled it from the
> > > > free_list. If the page is a "Reported" page then it decrements the
> > > > reported_pages count for the free_area and makes sure the page doesn't
> > > > exist in the "Boundary" array pointer value, if it does it moves the
> > > > "Boundary" since it is pulling the page.
> > >
> > > This is still a non-trivial limitation on the page allocation from an
> > > external code IMHO. I cannot give any explicit reason why an ordering on
> > > the free list might matter (well except for page shuffling which uses it
> > > to make physical memory pattern allocation more random) but the
> > > architecture seems hacky and dubious to be honest. It shoulds like the
> > > whole interface has been developed around a very particular and single
> > > purpose optimization.
> > >
> > > I remember that there was an attempt to report free memory that provided
> > > a callback mechanism [1], which was much less intrusive to the internals
> > > of the allocator yet it should provide a similar functionality. Did you
> > > see that approach? How does this compares to it? Or am I completely off
> > > when comparing them?
> > >
> > > [1] mostly likely not the latest version of the patchset
> > > http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
> >
> > Linus nacked that one. He thinks invoking callbacks with lots of
> > internal mm locks is too fragile.
>
> I would be really curious how much he would be happy about injecting
> other restrictions on the allocator like this patch proposes. This is
> more intrusive as it has a higher maintenance cost longterm IMHO.
Btw. I do agree that callbacks with internal mm locks are not great
either. We do have a model for that in mmu_notifiers and it is something
I do consider PITA, on the other hand it is mostly sleepable part of the
interface which makes it the real pain. The above callback mechanism was
explicitly documented with restrictions and that the context is
essentially atomic with no access to particular struct pages and no
expensive operations possible. So in the end I've considered it
acceptably painful. Not that I want to override Linus' nack but if
virtualization usecases really require some form of reporting and no
other way to do that push people to invent even more interesting
approaches then we should simply give them/you something reasonable
and least intrusive to our internals.
--
Michal Hocko
SUSE Labs
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/6] dt-bindings: pci: amlogic,meson-pcie: Add G12A bindings
From: Neil Armstrong @ 2019-09-11 12:30 UTC (permalink / raw)
To: Andrew Murray
Cc: devicetree, lorenzo.pieralisi, khilman, linux-pci, linux-kernel,
kishon, repk, maz, bhelgaas, linux-amlogic, yue.wang,
linux-arm-kernel
In-Reply-To: <20190911122250.GT9720@e119886-lin.cambridge.arm.com>
Hi Andrew,
On 11/09/2019 14:22, Andrew Murray wrote:
> On Sun, Sep 08, 2019 at 01:42:53PM +0000, Neil Armstrong wrote:
>> Add PCIE bindings for the Amlogic G12A SoC, the support is the same
>> but the PHY is shared with USB3 to control the differential lines.
>>
>> Thus this adds a phy phandle to control the PHY, and sets invalid
>> MIPI clock as optional for G12A.
>
> Perhaps reword to "Thus this adds a phy phandle to control the PHY,
> and only requires a MIPI clock for AXG SoC Family".
Sure, thanks,
Neil
>
> Thanks,
>
> Andrew Murray
>
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> .../devicetree/bindings/pci/amlogic,meson-pcie.txt | 12 ++++++++----
>> 1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
>> index efa2c8b9b85a..84fdc422792e 100644
>> --- a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
>> +++ b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
>> @@ -9,13 +9,16 @@ Additional properties are described here:
>>
>> Required properties:
>> - compatible:
>> - should contain "amlogic,axg-pcie" to identify the core.
>> + should contain :
>> + - "amlogic,axg-pcie" for AXG SoC Family
>> + - "amlogic,g12a-pcie" for G12A SoC Family
>> + to identify the core.
>> - reg:
>> should contain the configuration address space.
>> - reg-names: Must be
>> - "elbi" External local bus interface registers
>> - "cfg" Meson specific registers
>> - - "phy" Meson PCIE PHY registers
>> + - "phy" Meson PCIE PHY registers for AXG SoC Family
>> - "config" PCIe configuration space
>> - reset-gpios: The GPIO to generate PCIe PERST# assert and deassert signal.
>> - clocks: Must contain an entry for each entry in clock-names.
>> @@ -23,12 +26,13 @@ Required properties:
>> - "pclk" PCIe GEN 100M PLL clock
>> - "port" PCIe_x(A or B) RC clock gate
>> - "general" PCIe Phy clock
>> - - "mipi" PCIe_x(A or B) 100M ref clock gate
>> + - "mipi" PCIe_x(A or B) 100M ref clock gate for AXG SoC Family
>> - resets: phandle to the reset lines.
>> - reset-names: must contain "phy" "port" and "apb"
>> - - "phy" Share PHY reset
>> + - "phy" Share PHY reset for AXG SoC Family
>> - "port" Port A or B reset
>> - "apb" Share APB reset
>> +- phys: should contain a phandle to the shared phy for G12A SoC Family
>> - device_type:
>> should be "pci". As specified in designware-pcie.txt
>>
>> --
>> 2.17.1
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/6] PCI: amlogic: meson: Add support for G12A
From: Neil Armstrong @ 2019-09-11 12:39 UTC (permalink / raw)
To: Andrew Murray
Cc: lorenzo.pieralisi, khilman, linux-pci, linux-kernel, kishon, repk,
maz, bhelgaas, linux-amlogic, yue.wang, linux-arm-kernel
In-Reply-To: <20190911113633.GR9720@e119886-lin.cambridge.arm.com>
Hi Andrew,
On 11/09/2019 13:36, Andrew Murray wrote:
> On Sun, Sep 08, 2019 at 01:42:55PM +0000, Neil Armstrong wrote:
>> Add support for the Amlogic G12A SoC using a separate shared PHY.
>>
>> This adds support for fetching a PHY phandle and call the PHY init,
>> reset and power on/off calls instead of writing in the PHY register or
>> toggling the PHY reset line.
>>
>> The MIPI clock is also made optional since it is used for setting up
>
> Is it worth indicating here that the MIPI clock is *only required* for
> the G12A (or controllers with a shared phy)? It's still required for
> AXG. It's not optional for G12A - it's ignored.
Indeed it's ignored, I'll reword it.
>
>> the PHY reference clock chared with the DSI controller on AXG.
>
> s/chared/shared/
Ack
>
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> drivers/pci/controller/dwc/pci-meson.c | 101 ++++++++++++++++++++-----
>> 1 file changed, 84 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/pci/controller/dwc/pci-meson.c b/drivers/pci/controller/dwc/pci-meson.c
>> index ab79990798f8..3fadad381762 100644
>> --- a/drivers/pci/controller/dwc/pci-meson.c
>> +++ b/drivers/pci/controller/dwc/pci-meson.c
>> @@ -16,6 +16,7 @@
>> #include <linux/reset.h>
>> #include <linux/resource.h>
>> #include <linux/types.h>
>> +#include <linux/phy/phy.h>
>>
>> #include "pcie-designware.h"
>>
>> @@ -96,12 +97,18 @@ struct meson_pcie_rc_reset {
>> struct reset_control *apb;
>> };
>>
>> +struct meson_pcie_param {
>> + bool has_shared_phy;
>> +};
>> +
>> struct meson_pcie {
>> struct dw_pcie pci;
>> struct meson_pcie_mem_res mem_res;
>> struct meson_pcie_clk_res clk_res;
>> struct meson_pcie_rc_reset mrst;
>> struct gpio_desc *reset_gpio;
>> + struct phy *phy;
>> + const struct meson_pcie_param *param;
>> };
>>
>> static struct reset_control *meson_pcie_get_reset(struct meson_pcie *mp,
>> @@ -123,10 +130,12 @@ static int meson_pcie_get_resets(struct meson_pcie *mp)
>> {
>> struct meson_pcie_rc_reset *mrst = &mp->mrst;
>>
>> - mrst->phy = meson_pcie_get_reset(mp, "phy", PCIE_SHARED_RESET);
>> - if (IS_ERR(mrst->phy))
>> - return PTR_ERR(mrst->phy);
>> - reset_control_deassert(mrst->phy);
>> + if (!mp->param->has_shared_phy) {
>> + mrst->phy = meson_pcie_get_reset(mp, "phy", PCIE_SHARED_RESET);
>> + if (IS_ERR(mrst->phy))
>> + return PTR_ERR(mrst->phy);
>> + reset_control_deassert(mrst->phy);
>> + }
>>
>> mrst->port = meson_pcie_get_reset(mp, "port", PCIE_NORMAL_RESET);
>> if (IS_ERR(mrst->port))
>> @@ -180,6 +189,9 @@ static int meson_pcie_get_mems(struct platform_device *pdev,
>> if (IS_ERR(mp->mem_res.cfg_base))
>> return PTR_ERR(mp->mem_res.cfg_base);
>>
>> + if (mp->param->has_shared_phy)
>> + return 0;
>> +
>
> It may be more consistent if, rather than returning here, you wrapped
> the following 3 lines by the if statement.
ok
>
>> /* Meson SoC has two PCI controllers use same phy register*/
>
> I guess this comment should now be updated to refer to AXG?
Indeed
>
>> mp->mem_res.phy_base = meson_pcie_get_mem_shared(pdev, mp, "phy");
>> if (IS_ERR(mp->mem_res.phy_base))
>> @@ -188,19 +200,33 @@ static int meson_pcie_get_mems(struct platform_device *pdev,
>> return 0;
>> }
>>
>> -static void meson_pcie_power_on(struct meson_pcie *mp)
>> +static int meson_pcie_power_on(struct meson_pcie *mp)
>> {
>> - writel(MESON_PCIE_PHY_POWERUP, mp->mem_res.phy_base);
>> + int ret = 0;
>> +
>> + if (mp->param->has_shared_phy)
>> + ret = phy_power_on(mp->phy);
>
> I haven't seen any phy_[init/exit] calls, should there be any?
There is no _init() needed, but indeed we should still call them even it's
a no-op.
>
>> + else
>> + writel(MESON_PCIE_PHY_POWERUP, mp->mem_res.phy_base);
>> +
>> + return ret;
>> }
>>
>> -static void meson_pcie_reset(struct meson_pcie *mp)
>> +static int meson_pcie_reset(struct meson_pcie *mp)
>> {
>> struct meson_pcie_rc_reset *mrst = &mp->mrst;
>> -
>> - reset_control_assert(mrst->phy);
>> - udelay(PCIE_RESET_DELAY);
>> - reset_control_deassert(mrst->phy);
>> - udelay(PCIE_RESET_DELAY);
>> + int ret = 0;
>> +
>> + if (mp->param->has_shared_phy) {
>> + ret = phy_reset(mp->phy);
>> + if (ret)
>> + return ret;
>> + } else {
>> + reset_control_assert(mrst->phy);
>> + udelay(PCIE_RESET_DELAY);
>> + reset_control_deassert(mrst->phy);
>> + udelay(PCIE_RESET_DELAY);
>> + }
>>
>> reset_control_assert(mrst->port);
>> reset_control_assert(mrst->apb);
>> @@ -208,6 +234,8 @@ static void meson_pcie_reset(struct meson_pcie *mp)
>> reset_control_deassert(mrst->port);
>> reset_control_deassert(mrst->apb);
>> udelay(PCIE_RESET_DELAY);
>> +
>> + return 0;
>> }
>>
>> static inline struct clk *meson_pcie_probe_clock(struct device *dev,
>> @@ -250,9 +278,11 @@ static int meson_pcie_probe_clocks(struct meson_pcie *mp)
>> if (IS_ERR(res->port_clk))
>> return PTR_ERR(res->port_clk);
>>
>> - res->mipi_gate = meson_pcie_probe_clock(dev, "mipi", 0);
>> - if (IS_ERR(res->mipi_gate))
>> - return PTR_ERR(res->mipi_gate);
>> + if (!mp->param->has_shared_phy) {
>> + res->mipi_gate = meson_pcie_probe_clock(dev, "mipi", 0);
>> + if (IS_ERR(res->mipi_gate))
>> + return PTR_ERR(res->mipi_gate);
>> + }
>>
>> res->general_clk = meson_pcie_probe_clock(dev, "general", 0);
>> if (IS_ERR(res->general_clk))
>> @@ -524,6 +554,7 @@ static const struct dw_pcie_ops dw_pcie_ops = {
>>
>> static int meson_pcie_probe(struct platform_device *pdev)
>> {
>> + const struct meson_pcie_param *match_data;
>> struct device *dev = &pdev->dev;
>> struct dw_pcie *pci;
>> struct meson_pcie *mp;
>> @@ -537,6 +568,20 @@ static int meson_pcie_probe(struct platform_device *pdev)
>> pci->dev = dev;
>> pci->ops = &dw_pcie_ops;
>>
>> + match_data = of_device_get_match_data(dev);
>> + if (!match_data) {
>> + dev_err(dev, "failed to get match data\n");
>> + return -ENODEV;
>> + }
>> + mp->param = match_data;
>> +
>> + if (mp->param->has_shared_phy) {
>> + mp->phy = devm_phy_get(dev, "pcie");
>> + if (IS_ERR(mp->phy)) {
>> + return PTR_ERR(mp->phy);
>> + }
>> + }
>> +
>> mp->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
>> if (IS_ERR(mp->reset_gpio)) {
>> dev_err(dev, "get reset gpio failed\n");
>> @@ -555,8 +600,17 @@ static int meson_pcie_probe(struct platform_device *pdev)
>> return ret;
>> }
>>
>> - meson_pcie_power_on(mp);
>> - meson_pcie_reset(mp);
>> + ret = meson_pcie_power_on(mp);
>> + if (ret) {
>> + dev_err(dev, "phy power on failed, %d\n", ret);
>> + return ret;
>> + }
>> +
>> + ret = meson_pcie_reset(mp);
>> + if (ret) {
>> + dev_err(dev, "reset failed, %d\n", ret);
>> + return ret;
>> + }
>>
>> ret = meson_pcie_probe_clocks(mp);
>> if (ret) {
>> @@ -575,9 +629,22 @@ static int meson_pcie_probe(struct platform_device *pdev)
>> return 0;
>> }
>>
>> +static struct meson_pcie_param meson_pcie_axg_param = {
>> + .has_shared_phy = false,
>> +};
>> +
>> +static struct meson_pcie_param meson_pcie_g12a_param = {
>> + .has_shared_phy = true,
>> +};
>> +
>> static const struct of_device_id meson_pcie_of_match[] = {
>> {
>> .compatible = "amlogic,axg-pcie",
>> + .data = &meson_pcie_axg_param,
>> + },
>> + {
>> + .compatible = "amlogic,g12a-pcie",
>> + .data = &meson_pcie_g12a_param,
>
> Here, we hard-code knowledge about the SOCs regarding if they have shared phys
> or not. I guess the alternative would have been to assume there is a shared
> phy if the DT has a phandle for it. I.e. instead of mp->param->has_shared_phy
> everywhere you could test for mp->phy. Though I guess at least with the
> current approach you guard against bad DTs, this seems OK.
I could split with if(mp->phy) and .needs_mipi_clk, but overall it would
be the same, and I wouldn't know how to react if we forget the PHY in g12a DT
since we wouldn't have the PHY register memory zone.
On G12A, the PHY is mandatory unlike AXG.
And finally this MIPI clock is part of the PHY ref clock, so I think
it's fine to wrap it in the .has_shared_phy knowledge.
Thanks for the review,
Neil
>
> Thanks,
>
> Andrew Murray
>
>> },
>> {},
>> };
>> --
>> 2.17.1
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
From: David Hildenbrand @ 2019-09-11 12:42 UTC (permalink / raw)
To: Michal Hocko, Michael S. Tsirkin
Cc: Yang Zhang, Pankaj Gupta, kvm list, Catalin Marinas,
Alexander Duyck, lcapitulino, linux-mm, Alexander Duyck, will,
Andrea Arcangeli, virtio-dev, Rik van Riel, Matthew Wilcox,
Wang, Wei W, ying.huang, Konrad Rzeszutek Wilk, Dan Williams,
linux-arm-kernel, Oscar Salvador, Nitesh Narayan Lal, Dave Hansen,
LKML, Paolo Bonzini, Andrew Morton, Fengguang Wu,
Kirill A. Shutemov
In-Reply-To: <20190911122526.GV4023@dhcp22.suse.cz>
On 11.09.19 14:25, Michal Hocko wrote:
> On Wed 11-09-19 14:19:41, Michal Hocko wrote:
>> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
>>> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
>>>> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
>>>> [...]
>>>>> We don't put any limitations on the allocator other then that it needs to
>>>>> clean up the metadata on allocation, and that it cannot allocate a page
>>>>> that is in the process of being reported since we pulled it from the
>>>>> free_list. If the page is a "Reported" page then it decrements the
>>>>> reported_pages count for the free_area and makes sure the page doesn't
>>>>> exist in the "Boundary" array pointer value, if it does it moves the
>>>>> "Boundary" since it is pulling the page.
>>>>
>>>> This is still a non-trivial limitation on the page allocation from an
>>>> external code IMHO. I cannot give any explicit reason why an ordering on
>>>> the free list might matter (well except for page shuffling which uses it
>>>> to make physical memory pattern allocation more random) but the
>>>> architecture seems hacky and dubious to be honest. It shoulds like the
>>>> whole interface has been developed around a very particular and single
>>>> purpose optimization.
>>>>
>>>> I remember that there was an attempt to report free memory that provided
>>>> a callback mechanism [1], which was much less intrusive to the internals
>>>> of the allocator yet it should provide a similar functionality. Did you
>>>> see that approach? How does this compares to it? Or am I completely off
>>>> when comparing them?
>>>>
>>>> [1] mostly likely not the latest version of the patchset
>>>> http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
>>>
>>> Linus nacked that one. He thinks invoking callbacks with lots of
>>> internal mm locks is too fragile.
>>
>> I would be really curious how much he would be happy about injecting
>> other restrictions on the allocator like this patch proposes. This is
>> more intrusive as it has a higher maintenance cost longterm IMHO.
>
> Btw. I do agree that callbacks with internal mm locks are not great
> either. We do have a model for that in mmu_notifiers and it is something
> I do consider PITA, on the other hand it is mostly sleepable part of the
> interface which makes it the real pain. The above callback mechanism was
> explicitly documented with restrictions and that the context is
> essentially atomic with no access to particular struct pages and no
> expensive operations possible. So in the end I've considered it
> acceptably painful. Not that I want to override Linus' nack but if
> virtualization usecases really require some form of reporting and no
> other way to do that push people to invent even more interesting
> approaches then we should simply give them/you something reasonable
> and least intrusive to our internals.
>
The issue with "[PATCH v14 4/5] mm: support reporting free page blocks"
is that it cannot really handle the use case we have here if I am not
wrong. While a page is getting processed by the hypervisor (e.g.
MADV_DONTNEED), it must not get reused.
"Some page blocks may
leave the free list after zone->lock is released, so it is the caller's
responsibility to either detect or prevent the use of such pages."
If I'm not wrong, this only made sense to speed up migration in the
hypervisor, where you can deal with false positives differently.
--
Thanks,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/6] phy: meson-g12a-usb3-pcie: Add support for PCIe mode
From: Neil Armstrong @ 2019-09-11 12:45 UTC (permalink / raw)
To: Andrew Murray
Cc: lorenzo.pieralisi, khilman, linux-pci, linux-kernel, kishon, repk,
maz, bhelgaas, linux-amlogic, yue.wang, linux-arm-kernel
In-Reply-To: <20190911121954.GS9720@e119886-lin.cambridge.arm.com>
On 11/09/2019 14:19, Andrew Murray wrote:
> On Sun, Sep 08, 2019 at 01:42:56PM +0000, Neil Armstrong wrote:
>> This adds extended PCIe PHY functions for the Amlogic G12A
>> USB3+PCIE Combo PHY to support reset, power_on and power_off for
>> PCIe exclusively.
>>
>> With these callbacks, we can handle all the needed operations of the
>> Amlogic PCIe controller driver.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> .../phy/amlogic/phy-meson-g12a-usb3-pcie.c | 70 ++++++++++++++++---
>> 1 file changed, 61 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c b/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
>> index ac322d643c7a..08e322789e59 100644
>> --- a/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
>> +++ b/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
>> @@ -50,6 +50,8 @@
>> #define PHY_R5_PHY_CR_ACK BIT(16)
>> #define PHY_R5_PHY_BS_OUT BIT(17)
>>
>> +#define PCIE_RESET_DELAY 500
>> +
>> struct phy_g12a_usb3_pcie_priv {
>> struct regmap *regmap;
>> struct regmap *regmap_cr;
>> @@ -196,6 +198,10 @@ static int phy_g12a_usb3_init(struct phy *phy)
>> struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
>> int data, ret;
>>
>> + ret = reset_control_reset(priv->reset);
>> + if (ret)
>> + return ret;
>> +
>
> Right, so we've moved this to apply to USB only, thus assuming PCI will
> call .reset for its reset (why the asymmetry?).
Exact, there is no power_on/power_off when USB3 mode is used, and vendor
always reset the PHY before switching to USB3, but for PCIe, it seems the
reset and the power_on must be done separately with the PCIe controller init
and reset in the middle.
I would prefer symmetry aswell :-/
Neil
>
> Thanks,
>
> Andrew Murray
>
>> /* Switch PHY to USB3 */
>> /* TODO figure out how to handle when PCIe was set in the bootloader */
>> regmap_update_bits(priv->regmap, PHY_R0,
>> @@ -272,24 +278,64 @@ static int phy_g12a_usb3_init(struct phy *phy)
>> return 0;
>> }
>>
>> -static int phy_g12a_usb3_pcie_init(struct phy *phy)
>> +static int phy_g12a_usb3_pcie_power_on(struct phy *phy)
>> +{
>> + struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
>> +
>> + if (priv->mode == PHY_TYPE_USB3)
>> + return 0;
>> +
>> + regmap_update_bits(priv->regmap, PHY_R0,
>> + PHY_R0_PCIE_POWER_STATE,
>> + FIELD_PREP(PHY_R0_PCIE_POWER_STATE, 0x1c));
>> +
>> + return 0;
>> +}
>> +
>> +static int phy_g12a_usb3_pcie_power_off(struct phy *phy)
>> +{
>> + struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
>> +
>> + if (priv->mode == PHY_TYPE_USB3)
>> + return 0;
>> +
>> + regmap_update_bits(priv->regmap, PHY_R0,
>> + PHY_R0_PCIE_POWER_STATE,
>> + FIELD_PREP(PHY_R0_PCIE_POWER_STATE, 0x1d));
>> +
>> + return 0;
>> +}
>> +
>> +static int phy_g12a_usb3_pcie_reset(struct phy *phy)
>> {
>> struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
>> int ret;
>>
>> - ret = reset_control_reset(priv->reset);
>> + if (priv->mode == PHY_TYPE_USB3)
>> + return 0;
>> +
>> + ret = reset_control_assert(priv->reset);
>> if (ret)
>> return ret;
>>
>> + udelay(PCIE_RESET_DELAY);
>> +
>> + ret = reset_control_deassert(priv->reset);
>> + if (ret)
>> + return ret;
>> +
>> + udelay(PCIE_RESET_DELAY);
>> +
>> + return 0;
>> +}
>> +
>> +static int phy_g12a_usb3_pcie_init(struct phy *phy)
>> +{
>> + struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
>> +
>> if (priv->mode == PHY_TYPE_USB3)
>> return phy_g12a_usb3_init(phy);
>>
>> - /* Power UP PCIE */
>> - /* TODO figure out when the bootloader has set USB3 mode before */
>> - regmap_update_bits(priv->regmap, PHY_R0,
>> - PHY_R0_PCIE_POWER_STATE,
>> - FIELD_PREP(PHY_R0_PCIE_POWER_STATE, 0x1c));
>> -
>> return 0;
>> }
>>
>> @@ -297,7 +343,10 @@ static int phy_g12a_usb3_pcie_exit(struct phy *phy)
>> {
>> struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
>>
>> - return reset_control_reset(priv->reset);
>> + if (priv->mode == PHY_TYPE_USB3)
>> + return reset_control_reset(priv->reset);
>> +
>> + return 0;
>> }
>>
>> static struct phy *phy_g12a_usb3_pcie_xlate(struct device *dev,
>> @@ -326,6 +375,9 @@ static struct phy *phy_g12a_usb3_pcie_xlate(struct device *dev,
>> static const struct phy_ops phy_g12a_usb3_pcie_ops = {
>> .init = phy_g12a_usb3_pcie_init,
>> .exit = phy_g12a_usb3_pcie_exit,
>> + .power_on = phy_g12a_usb3_pcie_power_on,
>> + .power_off = phy_g12a_usb3_pcie_power_off,
>> + .reset = phy_g12a_usb3_pcie_reset,
>> .owner = THIS_MODULE,
>> };
>>
>> --
>> 2.17.1
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 6/6] arm64: dts: khadas-vim3: add commented support for PCIe
From: Andrew Murray @ 2019-09-11 12:50 UTC (permalink / raw)
To: Neil Armstrong
Cc: lorenzo.pieralisi, khilman, linux-pci, linux-kernel, kishon, repk,
maz, bhelgaas, linux-amlogic, yue.wang, linux-arm-kernel
In-Reply-To: <1567950178-4466-7-git-send-email-narmstrong@baylibre.com>
On Sun, Sep 08, 2019 at 01:42:58PM +0000, Neil Armstrong wrote:
> The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
> lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
> an USB3.0 Type A connector and a M.2 Key M slot.
> The PHY driving these differential lines is shared between
> the USB3.0 controller and the PCIe Controller, thus only
> a single controller can use it.
>
> The needed DT configuration when the MCU is configured to mux
> the PCIe/USB3.0 differential lines to the M.2 Key M slot is
> added commented and may uncommented to disable USB3.0 from the
*and may be*
> USB Complex and enable the PCIe controller.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../amlogic/meson-g12b-a311d-khadas-vim3.dts | 22 +++++++++++++++++++
> .../amlogic/meson-g12b-s922x-khadas-vim3.dts | 22 +++++++++++++++++++
> .../boot/dts/amlogic/meson-khadas-vim3.dtsi | 4 ++++
> .../dts/amlogic/meson-sm1-khadas-vim3l.dts | 22 +++++++++++++++++++
> 4 files changed, 70 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
> index 3a6a1e0c1e32..0577b1435cbb 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
> @@ -14,3 +14,25 @@
> / {
> compatible = "khadas,vim3", "amlogic,a311d", "amlogic,g12b";
> };
> +
> +/*
> + * The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
> + * lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
> + * an USB3.0 Type A connector and a M.2 Key M slot.
> + * The PHY driving these differential lines is shared between
> + * the USB3.0 controller and the PCIe Controller, thus only
> + * a single controller can use it.
> + * If the MCU is configured to mux the PCIe/USB3.0 differential lines
> + * to the M.2 Key M slot, uncomment the following block to disable
> + * USB3.0 from the USB Complex and enable the PCIe controller.
> + */
> +/*
> +&pcie {
> + status = "okay";
> +};
> +
> +&usb {
> + phys = <&usb2_phy0>, <&usb2_phy1>;
> + phy-names = "usb2-phy0", "usb2-phy1";
> +};
I assume there is no way other way to determine from the hardware which way
the mux is set?
Otherwise phy_g12a_usb3_pcie_xlate could determine the hardware mode, and
reject the phy instance with the wrong mode. Thus resulting in either the
PCI or USB to fail their probe. And avoiding the need to modify the DT on
boot.
Thanks,
Andrew Murray
> + */
> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts
> index b73deb282120..1ef5c2f04f67 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts
> @@ -14,3 +14,25 @@
> / {
> compatible = "khadas,vim3", "amlogic,s922x", "amlogic,g12b";
> };
> +
> +/*
> + * The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
> + * lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
> + * an USB3.0 Type A connector and a M.2 Key M slot.
> + * The PHY driving these differential lines is shared between
> + * the USB3.0 controller and the PCIe Controller, thus only
> + * a single controller can use it.
> + * If the MCU is configured to mux the PCIe/USB3.0 differential lines
> + * to the M.2 Key M slot, uncomment the following block to disable
> + * USB3.0 from the USB Complex and enable the PCIe controller.
> + */
> +/*
> +&pcie {
> + status = "okay";
> +};
> +
> +&usb {
> + phys = <&usb2_phy0>, <&usb2_phy1>;
> + phy-names = "usb2-phy0", "usb2-phy1";
> +};
> + */
> diff --git a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
> index 8647da7d6609..eac5720dc15f 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
> @@ -246,6 +246,10 @@
> linux,rc-map-name = "rc-khadas";
> };
>
> +&pcie {
> + reset-gpios = <&gpio GPIOA_8 GPIO_ACTIVE_LOW>;
> +};
> +
> &pwm_ef {
> status = "okay";
> pinctrl-0 = <&pwm_e_pins>;
> diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts b/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
> index 5233bd7cacfb..d9c7cbedce53 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
> @@ -68,3 +68,25 @@
> clock-names = "clkin1";
> status = "okay";
> };
> +
> +/*
> + * The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
> + * lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
> + * an USB3.0 Type A connector and a M.2 Key M slot.
> + * The PHY driving these differential lines is shared between
> + * the USB3.0 controller and the PCIe Controller, thus only
> + * a single controller can use it.
> + * If the MCU is configured to mux the PCIe/USB3.0 differential lines
> + * to the M.2 Key M slot, uncomment the following block to disable
> + * USB3.0 from the USB Complex and enable the PCIe controller.
> + */
> +/*
> +&pcie {
> + status = "okay";
> +};
> +
> +&usb {
> + phys = <&usb2_phy0>, <&usb2_phy1>;
> + phy-names = "usb2-phy0", "usb2-phy1";
> +};
> + */
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
From: Michal Hocko @ 2019-09-11 12:54 UTC (permalink / raw)
To: David Hildenbrand
Cc: Yang Zhang, Pankaj Gupta, kvm list, Michael S. Tsirkin,
Catalin Marinas, Alexander Duyck, lcapitulino, linux-mm,
Alexander Duyck, will, Andrea Arcangeli, virtio-dev, Rik van Riel,
Matthew Wilcox, Wang, Wei W, ying.huang, Konrad Rzeszutek Wilk,
Dan Williams, linux-arm-kernel, Oscar Salvador,
Nitesh Narayan Lal, Dave Hansen, LKML, Paolo Bonzini,
Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <4748a572-57b3-31da-0dde-30138e550c3a@redhat.com>
On Wed 11-09-19 14:42:41, David Hildenbrand wrote:
> On 11.09.19 14:25, Michal Hocko wrote:
> > On Wed 11-09-19 14:19:41, Michal Hocko wrote:
> >> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
> >>> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
> >>>> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> >>>> [...]
> >>>>> We don't put any limitations on the allocator other then that it needs to
> >>>>> clean up the metadata on allocation, and that it cannot allocate a page
> >>>>> that is in the process of being reported since we pulled it from the
> >>>>> free_list. If the page is a "Reported" page then it decrements the
> >>>>> reported_pages count for the free_area and makes sure the page doesn't
> >>>>> exist in the "Boundary" array pointer value, if it does it moves the
> >>>>> "Boundary" since it is pulling the page.
> >>>>
> >>>> This is still a non-trivial limitation on the page allocation from an
> >>>> external code IMHO. I cannot give any explicit reason why an ordering on
> >>>> the free list might matter (well except for page shuffling which uses it
> >>>> to make physical memory pattern allocation more random) but the
> >>>> architecture seems hacky and dubious to be honest. It shoulds like the
> >>>> whole interface has been developed around a very particular and single
> >>>> purpose optimization.
> >>>>
> >>>> I remember that there was an attempt to report free memory that provided
> >>>> a callback mechanism [1], which was much less intrusive to the internals
> >>>> of the allocator yet it should provide a similar functionality. Did you
> >>>> see that approach? How does this compares to it? Or am I completely off
> >>>> when comparing them?
> >>>>
> >>>> [1] mostly likely not the latest version of the patchset
> >>>> http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
> >>>
> >>> Linus nacked that one. He thinks invoking callbacks with lots of
> >>> internal mm locks is too fragile.
> >>
> >> I would be really curious how much he would be happy about injecting
> >> other restrictions on the allocator like this patch proposes. This is
> >> more intrusive as it has a higher maintenance cost longterm IMHO.
> >
> > Btw. I do agree that callbacks with internal mm locks are not great
> > either. We do have a model for that in mmu_notifiers and it is something
> > I do consider PITA, on the other hand it is mostly sleepable part of the
> > interface which makes it the real pain. The above callback mechanism was
> > explicitly documented with restrictions and that the context is
> > essentially atomic with no access to particular struct pages and no
> > expensive operations possible. So in the end I've considered it
> > acceptably painful. Not that I want to override Linus' nack but if
> > virtualization usecases really require some form of reporting and no
> > other way to do that push people to invent even more interesting
> > approaches then we should simply give them/you something reasonable
> > and least intrusive to our internals.
> >
>
> The issue with "[PATCH v14 4/5] mm: support reporting free page blocks"
> is that it cannot really handle the use case we have here if I am not
> wrong. While a page is getting processed by the hypervisor (e.g.
> MADV_DONTNEED), it must not get reused.
What prevents to use the callback to get a list of pfn ranges to work on
and then use something like start_isolate_page_range on the collected
pfn ranges to make sure nobody steals pages from under your feet, do
your thing and drop the isolated state afterwards.
I am saying somethig like because you wouldn't really want a generic
has_unmovable_pages but rather
if (!page_ref_count(page)) {
if (PageBuddy(page))
iter += (1 << page_order(page)) - 1;
continue;
}
subset of it.
--
Michal Hocko
SUSE Labs
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
From: Nitesh Narayan Lal @ 2019-09-11 12:55 UTC (permalink / raw)
To: David Hildenbrand, Michal Hocko, Michael S. Tsirkin
Cc: Yang Zhang, Pankaj Gupta, kvm list, Catalin Marinas,
Alexander Duyck, lcapitulino, linux-mm, Alexander Duyck, will,
Andrea Arcangeli, virtio-dev, Rik van Riel, Matthew Wilcox,
Wang, Wei W, ying.huang, Konrad Rzeszutek Wilk, Dan Williams,
linux-arm-kernel, Oscar Salvador, Dave Hansen, LKML,
Paolo Bonzini, Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <4748a572-57b3-31da-0dde-30138e550c3a@redhat.com>
On 9/11/19 8:42 AM, David Hildenbrand wrote:
> On 11.09.19 14:25, Michal Hocko wrote:
>> On Wed 11-09-19 14:19:41, Michal Hocko wrote:
>>> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
>>>> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
>>>>> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
>>>>> [...]
>>>>>> We don't put any limitations on the allocator other then that it needs to
>>>>>> clean up the metadata on allocation, and that it cannot allocate a page
>>>>>> that is in the process of being reported since we pulled it from the
>>>>>> free_list. If the page is a "Reported" page then it decrements the
>>>>>> reported_pages count for the free_area and makes sure the page doesn't
>>>>>> exist in the "Boundary" array pointer value, if it does it moves the
>>>>>> "Boundary" since it is pulling the page.
>>>>> This is still a non-trivial limitation on the page allocation from an
>>>>> external code IMHO. I cannot give any explicit reason why an ordering on
>>>>> the free list might matter (well except for page shuffling which uses it
>>>>> to make physical memory pattern allocation more random) but the
>>>>> architecture seems hacky and dubious to be honest. It shoulds like the
>>>>> whole interface has been developed around a very particular and single
>>>>> purpose optimization.
>>>>>
>>>>> I remember that there was an attempt to report free memory that provided
>>>>> a callback mechanism [1], which was much less intrusive to the internals
>>>>> of the allocator yet it should provide a similar functionality. Did you
>>>>> see that approach? How does this compares to it? Or am I completely off
>>>>> when comparing them?
>>>>>
>>>>> [1] mostly likely not the latest version of the patchset
>>>>> http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
>>>> Linus nacked that one. He thinks invoking callbacks with lots of
>>>> internal mm locks is too fragile.
>>> I would be really curious how much he would be happy about injecting
>>> other restrictions on the allocator like this patch proposes. This is
>>> more intrusive as it has a higher maintenance cost longterm IMHO.
>> Btw. I do agree that callbacks with internal mm locks are not great
>> either. We do have a model for that in mmu_notifiers and it is something
>> I do consider PITA, on the other hand it is mostly sleepable part of the
>> interface which makes it the real pain. The above callback mechanism was
>> explicitly documented with restrictions and that the context is
>> essentially atomic with no access to particular struct pages and no
>> expensive operations possible. So in the end I've considered it
>> acceptably painful. Not that I want to override Linus' nack but if
>> virtualization usecases really require some form of reporting and no
>> other way to do that push people to invent even more interesting
>> approaches then we should simply give them/you something reasonable
>> and least intrusive to our internals.
>>
> The issue with "[PATCH v14 4/5] mm: support reporting free page blocks"
> is that it cannot really handle the use case we have here if I am not
> wrong. While a page is getting processed by the hypervisor (e.g.
> MADV_DONTNEED), it must not get reused.
>
> "Some page blocks may
> leave the free list after zone->lock is released, so it is the caller's
> responsibility to either detect or prevent the use of such pages."
>
> If I'm not wrong, this only made sense to speed up migration in the
> hypervisor, where you can deal with false positives differently.
Another difference between the two approaches is the origin from where
the reporting request is getting generated. (If I remember correctly)
In Alexander's series or in my series [1], VM is able to report pages
dynamically without any requirement of host intervention.
[1] https://lkml.org/lkml/2019/8/12/593
--
Thanks
Nitesh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/6] PCI: amlogic: meson: Add support for G12A
From: Andrew Murray @ 2019-09-11 12:58 UTC (permalink / raw)
To: Neil Armstrong
Cc: lorenzo.pieralisi, khilman, linux-pci, linux-kernel, kishon, repk,
maz, bhelgaas, linux-amlogic, yue.wang, linux-arm-kernel
In-Reply-To: <bb5794e7-44c6-c889-b555-21c531003548@baylibre.com>
On Wed, Sep 11, 2019 at 02:39:42PM +0200, Neil Armstrong wrote:
> Hi Andrew,
>
> On 11/09/2019 13:36, Andrew Murray wrote:
> > On Sun, Sep 08, 2019 at 01:42:55PM +0000, Neil Armstrong wrote:
> >> Add support for the Amlogic G12A SoC using a separate shared PHY.
> >>
> >> This adds support for fetching a PHY phandle and call the PHY init,
> >> reset and power on/off calls instead of writing in the PHY register or
> >> toggling the PHY reset line.
> >>
> >> The MIPI clock is also made optional since it is used for setting up
> >
> > Is it worth indicating here that the MIPI clock is *only required* for
> > the G12A (or controllers with a shared phy)? It's still required for
> > AXG. It's not optional for G12A - it's ignored.
>
> Indeed it's ignored, I'll reword it.
>
> >
> >> the PHY reference clock chared with the DSI controller on AXG.
> >
> > s/chared/shared/
>
> Ack
>
> >
> >>
> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> >> ---
> >> drivers/pci/controller/dwc/pci-meson.c | 101 ++++++++++++++++++++-----
> >> 1 file changed, 84 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/drivers/pci/controller/dwc/pci-meson.c b/drivers/pci/controller/dwc/pci-meson.c
> >> index ab79990798f8..3fadad381762 100644
> >> --- a/drivers/pci/controller/dwc/pci-meson.c
> >> +++ b/drivers/pci/controller/dwc/pci-meson.c
> >> @@ -16,6 +16,7 @@
> >> #include <linux/reset.h>
> >> #include <linux/resource.h>
> >> #include <linux/types.h>
> >> +#include <linux/phy/phy.h>
> >>
> >> #include "pcie-designware.h"
> >>
> >> @@ -96,12 +97,18 @@ struct meson_pcie_rc_reset {
> >> struct reset_control *apb;
> >> };
> >>
> >> +struct meson_pcie_param {
> >> + bool has_shared_phy;
> >> +};
> >> +
> >> struct meson_pcie {
> >> struct dw_pcie pci;
> >> struct meson_pcie_mem_res mem_res;
> >> struct meson_pcie_clk_res clk_res;
> >> struct meson_pcie_rc_reset mrst;
> >> struct gpio_desc *reset_gpio;
> >> + struct phy *phy;
> >> + const struct meson_pcie_param *param;
> >> };
> >>
> >> static struct reset_control *meson_pcie_get_reset(struct meson_pcie *mp,
> >> @@ -123,10 +130,12 @@ static int meson_pcie_get_resets(struct meson_pcie *mp)
> >> {
> >> struct meson_pcie_rc_reset *mrst = &mp->mrst;
> >>
> >> - mrst->phy = meson_pcie_get_reset(mp, "phy", PCIE_SHARED_RESET);
> >> - if (IS_ERR(mrst->phy))
> >> - return PTR_ERR(mrst->phy);
> >> - reset_control_deassert(mrst->phy);
> >> + if (!mp->param->has_shared_phy) {
> >> + mrst->phy = meson_pcie_get_reset(mp, "phy", PCIE_SHARED_RESET);
> >> + if (IS_ERR(mrst->phy))
> >> + return PTR_ERR(mrst->phy);
> >> + reset_control_deassert(mrst->phy);
> >> + }
> >>
> >> mrst->port = meson_pcie_get_reset(mp, "port", PCIE_NORMAL_RESET);
> >> if (IS_ERR(mrst->port))
> >> @@ -180,6 +189,9 @@ static int meson_pcie_get_mems(struct platform_device *pdev,
> >> if (IS_ERR(mp->mem_res.cfg_base))
> >> return PTR_ERR(mp->mem_res.cfg_base);
> >>
> >> + if (mp->param->has_shared_phy)
> >> + return 0;
> >> +
> >
> > It may be more consistent if, rather than returning here, you wrapped
> > the following 3 lines by the if statement.
>
> ok
>
> >
> >> /* Meson SoC has two PCI controllers use same phy register*/
> >
> > I guess this comment should now be updated to refer to AXG?
>
> Indeed
>
> >
> >> mp->mem_res.phy_base = meson_pcie_get_mem_shared(pdev, mp, "phy");
> >> if (IS_ERR(mp->mem_res.phy_base))
> >> @@ -188,19 +200,33 @@ static int meson_pcie_get_mems(struct platform_device *pdev,
> >> return 0;
> >> }
> >>
> >> -static void meson_pcie_power_on(struct meson_pcie *mp)
> >> +static int meson_pcie_power_on(struct meson_pcie *mp)
> >> {
> >> - writel(MESON_PCIE_PHY_POWERUP, mp->mem_res.phy_base);
> >> + int ret = 0;
> >> +
> >> + if (mp->param->has_shared_phy)
> >> + ret = phy_power_on(mp->phy);
> >
> > I haven't seen any phy_[init/exit] calls, should there be any?
>
> There is no _init() needed, but indeed we should still call them even it's
> a no-op.
Yes - and that makes it easier for someone to modify the phy driver and not
have to worry that there may be users that don't call init.
>
> >
> >> + else
> >> + writel(MESON_PCIE_PHY_POWERUP, mp->mem_res.phy_base);
> >> +
> >> + return ret;
> >> }
> >>
> >> -static void meson_pcie_reset(struct meson_pcie *mp)
> >> +static int meson_pcie_reset(struct meson_pcie *mp)
> >> {
> >> struct meson_pcie_rc_reset *mrst = &mp->mrst;
> >> -
> >> - reset_control_assert(mrst->phy);
> >> - udelay(PCIE_RESET_DELAY);
> >> - reset_control_deassert(mrst->phy);
> >> - udelay(PCIE_RESET_DELAY);
> >> + int ret = 0;
> >> +
> >> + if (mp->param->has_shared_phy) {
> >> + ret = phy_reset(mp->phy);
> >> + if (ret)
> >> + return ret;
> >> + } else {
> >> + reset_control_assert(mrst->phy);
> >> + udelay(PCIE_RESET_DELAY);
> >> + reset_control_deassert(mrst->phy);
> >> + udelay(PCIE_RESET_DELAY);
> >> + }
> >>
> >> reset_control_assert(mrst->port);
> >> reset_control_assert(mrst->apb);
> >> @@ -208,6 +234,8 @@ static void meson_pcie_reset(struct meson_pcie *mp)
> >> reset_control_deassert(mrst->port);
> >> reset_control_deassert(mrst->apb);
> >> udelay(PCIE_RESET_DELAY);
> >> +
> >> + return 0;
> >> }
> >>
> >> static inline struct clk *meson_pcie_probe_clock(struct device *dev,
> >> @@ -250,9 +278,11 @@ static int meson_pcie_probe_clocks(struct meson_pcie *mp)
> >> if (IS_ERR(res->port_clk))
> >> return PTR_ERR(res->port_clk);
> >>
> >> - res->mipi_gate = meson_pcie_probe_clock(dev, "mipi", 0);
> >> - if (IS_ERR(res->mipi_gate))
> >> - return PTR_ERR(res->mipi_gate);
> >> + if (!mp->param->has_shared_phy) {
> >> + res->mipi_gate = meson_pcie_probe_clock(dev, "mipi", 0);
> >> + if (IS_ERR(res->mipi_gate))
> >> + return PTR_ERR(res->mipi_gate);
> >> + }
> >>
> >> res->general_clk = meson_pcie_probe_clock(dev, "general", 0);
> >> if (IS_ERR(res->general_clk))
> >> @@ -524,6 +554,7 @@ static const struct dw_pcie_ops dw_pcie_ops = {
> >>
> >> static int meson_pcie_probe(struct platform_device *pdev)
> >> {
> >> + const struct meson_pcie_param *match_data;
> >> struct device *dev = &pdev->dev;
> >> struct dw_pcie *pci;
> >> struct meson_pcie *mp;
> >> @@ -537,6 +568,20 @@ static int meson_pcie_probe(struct platform_device *pdev)
> >> pci->dev = dev;
> >> pci->ops = &dw_pcie_ops;
> >>
> >> + match_data = of_device_get_match_data(dev);
> >> + if (!match_data) {
> >> + dev_err(dev, "failed to get match data\n");
> >> + return -ENODEV;
> >> + }
> >> + mp->param = match_data;
> >> +
> >> + if (mp->param->has_shared_phy) {
> >> + mp->phy = devm_phy_get(dev, "pcie");
> >> + if (IS_ERR(mp->phy)) {
> >> + return PTR_ERR(mp->phy);
> >> + }
> >> + }
> >> +
> >> mp->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> >> if (IS_ERR(mp->reset_gpio)) {
> >> dev_err(dev, "get reset gpio failed\n");
> >> @@ -555,8 +600,17 @@ static int meson_pcie_probe(struct platform_device *pdev)
> >> return ret;
> >> }
> >>
> >> - meson_pcie_power_on(mp);
> >> - meson_pcie_reset(mp);
> >> + ret = meson_pcie_power_on(mp);
> >> + if (ret) {
> >> + dev_err(dev, "phy power on failed, %d\n", ret);
> >> + return ret;
> >> + }
> >> +
> >> + ret = meson_pcie_reset(mp);
> >> + if (ret) {
> >> + dev_err(dev, "reset failed, %d\n", ret);
> >> + return ret;
> >> + }
> >>
> >> ret = meson_pcie_probe_clocks(mp);
> >> if (ret) {
> >> @@ -575,9 +629,22 @@ static int meson_pcie_probe(struct platform_device *pdev)
> >> return 0;
> >> }
> >>
> >> +static struct meson_pcie_param meson_pcie_axg_param = {
> >> + .has_shared_phy = false,
> >> +};
> >> +
> >> +static struct meson_pcie_param meson_pcie_g12a_param = {
> >> + .has_shared_phy = true,
> >> +};
> >> +
> >> static const struct of_device_id meson_pcie_of_match[] = {
> >> {
> >> .compatible = "amlogic,axg-pcie",
> >> + .data = &meson_pcie_axg_param,
> >> + },
> >> + {
> >> + .compatible = "amlogic,g12a-pcie",
> >> + .data = &meson_pcie_g12a_param,
> >
> > Here, we hard-code knowledge about the SOCs regarding if they have shared phys
> > or not. I guess the alternative would have been to assume there is a shared
> > phy if the DT has a phandle for it. I.e. instead of mp->param->has_shared_phy
> > everywhere you could test for mp->phy. Though I guess at least with the
> > current approach you guard against bad DTs, this seems OK.
>
> I could split with if(mp->phy) and .needs_mipi_clk, but overall it would
> be the same, and I wouldn't know how to react if we forget the PHY in g12a DT
> since we wouldn't have the PHY register memory zone.
> On G12A, the PHY is mandatory unlike AXG.
Indeed.
>
> And finally this MIPI clock is part of the PHY ref clock, so I think
> it's fine to wrap it in the .has_shared_phy knowledge.
I feel like the naming of "mipi" is unfortunate as ideally it'd be something
like "ref" or similar. Especially if another SoC uses meson PCI, without a
shared phy but with a reference clock that isn't MIPI. But I don't think
anyone wants to change the existing bindings.
I think your current approach is robust, I have no objections.
>
> Thanks for the review,
Thanks,
Andrew Murray
> Neil
>
> >
> > Thanks,
> >
> > Andrew Murray
> >
> >> },
> >> {},
> >> };
> >> --
> >> 2.17.1
> >>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 6/6] arm64: dts: khadas-vim3: add commented support for PCIe
From: Neil Armstrong @ 2019-09-11 12:58 UTC (permalink / raw)
To: Andrew Murray
Cc: lorenzo.pieralisi, khilman, linux-pci, linux-kernel, kishon, repk,
maz, bhelgaas, linux-amlogic, yue.wang, linux-arm-kernel
In-Reply-To: <20190911125035.GU9720@e119886-lin.cambridge.arm.com>
On 11/09/2019 14:50, Andrew Murray wrote:
> On Sun, Sep 08, 2019 at 01:42:58PM +0000, Neil Armstrong wrote:
>> The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
>> lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
>> an USB3.0 Type A connector and a M.2 Key M slot.
>> The PHY driving these differential lines is shared between
>> the USB3.0 controller and the PCIe Controller, thus only
>> a single controller can use it.
>>
>> The needed DT configuration when the MCU is configured to mux
>> the PCIe/USB3.0 differential lines to the M.2 Key M slot is
>> added commented and may uncommented to disable USB3.0 from the
>
> *and may be*
>
>> USB Complex and enable the PCIe controller.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> .../amlogic/meson-g12b-a311d-khadas-vim3.dts | 22 +++++++++++++++++++
>> .../amlogic/meson-g12b-s922x-khadas-vim3.dts | 22 +++++++++++++++++++
>> .../boot/dts/amlogic/meson-khadas-vim3.dtsi | 4 ++++
>> .../dts/amlogic/meson-sm1-khadas-vim3l.dts | 22 +++++++++++++++++++
>> 4 files changed, 70 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
>> index 3a6a1e0c1e32..0577b1435cbb 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
>> @@ -14,3 +14,25 @@
>> / {
>> compatible = "khadas,vim3", "amlogic,a311d", "amlogic,g12b";
>> };
>> +
>> +/*
>> + * The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
>> + * lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
>> + * an USB3.0 Type A connector and a M.2 Key M slot.
>> + * The PHY driving these differential lines is shared between
>> + * the USB3.0 controller and the PCIe Controller, thus only
>> + * a single controller can use it.
>> + * If the MCU is configured to mux the PCIe/USB3.0 differential lines
>> + * to the M.2 Key M slot, uncomment the following block to disable
>> + * USB3.0 from the USB Complex and enable the PCIe controller.
>> + */
>> +/*
>> +&pcie {
>> + status = "okay";
>> +};
>> +
>> +&usb {
>> + phys = <&usb2_phy0>, <&usb2_phy1>;
>> + phy-names = "usb2-phy0", "usb2-phy1";
>> +};
>
> I assume there is no way other way to determine from the hardware which way
> the mux is set?
No, it would be simpler :-/ The MUX is on-board and the MCU drives the MUX selection.
You can look at the https://dl.khadas.com/Hardware/VIM3/Schematic/VIM3_V11_Sch.pdf
The PCIE_EN signal is driven by the STM8S MCU.
>
> Otherwise phy_g12a_usb3_pcie_xlate could determine the hardware mode, and
> reject the phy instance with the wrong mode. Thus resulting in either the
> PCI or USB to fail their probe. And avoiding the need to modify the DT on
> boot.
Yep, it would have been simpler this way. Maybe a board vendor will set a gpio ?
who knows, but for actual boards it's static or with 0ohm resistors, and for the
VIM3 we only know by asking the MCU.
Maybe we could add a fake PHY as a MCU MFD subdevice, wrapping calls to the
right PHY. But for now the MCU has no upstream driver anyway.
Neil
>
> Thanks,
>
> Andrew Murray
>
>> + */
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts
>> index b73deb282120..1ef5c2f04f67 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts
>> @@ -14,3 +14,25 @@
>> / {
>> compatible = "khadas,vim3", "amlogic,s922x", "amlogic,g12b";
>> };
>> +
>> +/*
>> + * The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
>> + * lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
>> + * an USB3.0 Type A connector and a M.2 Key M slot.
>> + * The PHY driving these differential lines is shared between
>> + * the USB3.0 controller and the PCIe Controller, thus only
>> + * a single controller can use it.
>> + * If the MCU is configured to mux the PCIe/USB3.0 differential lines
>> + * to the M.2 Key M slot, uncomment the following block to disable
>> + * USB3.0 from the USB Complex and enable the PCIe controller.
>> + */
>> +/*
>> +&pcie {
>> + status = "okay";
>> +};
>> +
>> +&usb {
>> + phys = <&usb2_phy0>, <&usb2_phy1>;
>> + phy-names = "usb2-phy0", "usb2-phy1";
>> +};
>> + */
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
>> index 8647da7d6609..eac5720dc15f 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
>> @@ -246,6 +246,10 @@
>> linux,rc-map-name = "rc-khadas";
>> };
>>
>> +&pcie {
>> + reset-gpios = <&gpio GPIOA_8 GPIO_ACTIVE_LOW>;
>> +};
>> +
>> &pwm_ef {
>> status = "okay";
>> pinctrl-0 = <&pwm_e_pins>;
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts b/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
>> index 5233bd7cacfb..d9c7cbedce53 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
>> +++ b/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
>> @@ -68,3 +68,25 @@
>> clock-names = "clkin1";
>> status = "okay";
>> };
>> +
>> +/*
>> + * The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
>> + * lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
>> + * an USB3.0 Type A connector and a M.2 Key M slot.
>> + * The PHY driving these differential lines is shared between
>> + * the USB3.0 controller and the PCIe Controller, thus only
>> + * a single controller can use it.
>> + * If the MCU is configured to mux the PCIe/USB3.0 differential lines
>> + * to the M.2 Key M slot, uncomment the following block to disable
>> + * USB3.0 from the USB Complex and enable the PCIe controller.
>> + */
>> +/*
>> +&pcie {
>> + status = "okay";
>> +};
>> +
>> +&usb {
>> + phys = <&usb2_phy0>, <&usb2_phy1>;
>> + phy-names = "usb2-phy0", "usb2-phy1";
>> +};
>> + */
>> --
>> 2.17.1
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/6] phy: meson-g12a-usb3-pcie: Add support for PCIe mode
From: Andrew Murray @ 2019-09-11 12:59 UTC (permalink / raw)
To: Neil Armstrong
Cc: lorenzo.pieralisi, khilman, linux-pci, linux-kernel, kishon, repk,
maz, bhelgaas, linux-amlogic, yue.wang, linux-arm-kernel
In-Reply-To: <e4249d3a-9a98-c596-01ae-2917ffd78f17@baylibre.com>
On Wed, Sep 11, 2019 at 02:45:23PM +0200, Neil Armstrong wrote:
> On 11/09/2019 14:19, Andrew Murray wrote:
> > On Sun, Sep 08, 2019 at 01:42:56PM +0000, Neil Armstrong wrote:
> >> This adds extended PCIe PHY functions for the Amlogic G12A
> >> USB3+PCIE Combo PHY to support reset, power_on and power_off for
> >> PCIe exclusively.
> >>
> >> With these callbacks, we can handle all the needed operations of the
> >> Amlogic PCIe controller driver.
> >>
> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> >> ---
> >> .../phy/amlogic/phy-meson-g12a-usb3-pcie.c | 70 ++++++++++++++++---
> >> 1 file changed, 61 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c b/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
> >> index ac322d643c7a..08e322789e59 100644
> >> --- a/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
> >> +++ b/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
> >> @@ -50,6 +50,8 @@
> >> #define PHY_R5_PHY_CR_ACK BIT(16)
> >> #define PHY_R5_PHY_BS_OUT BIT(17)
> >>
> >> +#define PCIE_RESET_DELAY 500
> >> +
> >> struct phy_g12a_usb3_pcie_priv {
> >> struct regmap *regmap;
> >> struct regmap *regmap_cr;
> >> @@ -196,6 +198,10 @@ static int phy_g12a_usb3_init(struct phy *phy)
> >> struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
> >> int data, ret;
> >>
> >> + ret = reset_control_reset(priv->reset);
> >> + if (ret)
> >> + return ret;
> >> +
> >
> > Right, so we've moved this to apply to USB only, thus assuming PCI will
> > call .reset for its reset (why the asymmetry?).
>
> Exact, there is no power_on/power_off when USB3 mode is used, and vendor
> always reset the PHY before switching to USB3, but for PCIe, it seems the
> reset and the power_on must be done separately with the PCIe controller init
> and reset in the middle.
>
> I would prefer symmetry aswell :-/
OK.
Thanks,
Andrew Murray
>
> Neil
>
> >
> > Thanks,
> >
> > Andrew Murray
> >
> >> /* Switch PHY to USB3 */
> >> /* TODO figure out how to handle when PCIe was set in the bootloader */
> >> regmap_update_bits(priv->regmap, PHY_R0,
> >> @@ -272,24 +278,64 @@ static int phy_g12a_usb3_init(struct phy *phy)
> >> return 0;
> >> }
> >>
> >> -static int phy_g12a_usb3_pcie_init(struct phy *phy)
> >> +static int phy_g12a_usb3_pcie_power_on(struct phy *phy)
> >> +{
> >> + struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
> >> +
> >> + if (priv->mode == PHY_TYPE_USB3)
> >> + return 0;
> >> +
> >> + regmap_update_bits(priv->regmap, PHY_R0,
> >> + PHY_R0_PCIE_POWER_STATE,
> >> + FIELD_PREP(PHY_R0_PCIE_POWER_STATE, 0x1c));
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static int phy_g12a_usb3_pcie_power_off(struct phy *phy)
> >> +{
> >> + struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
> >> +
> >> + if (priv->mode == PHY_TYPE_USB3)
> >> + return 0;
> >> +
> >> + regmap_update_bits(priv->regmap, PHY_R0,
> >> + PHY_R0_PCIE_POWER_STATE,
> >> + FIELD_PREP(PHY_R0_PCIE_POWER_STATE, 0x1d));
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static int phy_g12a_usb3_pcie_reset(struct phy *phy)
> >> {
> >> struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
> >> int ret;
> >>
> >> - ret = reset_control_reset(priv->reset);
> >> + if (priv->mode == PHY_TYPE_USB3)
> >> + return 0;
> >> +
> >> + ret = reset_control_assert(priv->reset);
> >> if (ret)
> >> return ret;
> >>
> >> + udelay(PCIE_RESET_DELAY);
> >> +
> >> + ret = reset_control_deassert(priv->reset);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + udelay(PCIE_RESET_DELAY);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static int phy_g12a_usb3_pcie_init(struct phy *phy)
> >> +{
> >> + struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
> >> +
> >> if (priv->mode == PHY_TYPE_USB3)
> >> return phy_g12a_usb3_init(phy);
> >>
> >> - /* Power UP PCIE */
> >> - /* TODO figure out when the bootloader has set USB3 mode before */
> >> - regmap_update_bits(priv->regmap, PHY_R0,
> >> - PHY_R0_PCIE_POWER_STATE,
> >> - FIELD_PREP(PHY_R0_PCIE_POWER_STATE, 0x1c));
> >> -
> >> return 0;
> >> }
> >>
> >> @@ -297,7 +343,10 @@ static int phy_g12a_usb3_pcie_exit(struct phy *phy)
> >> {
> >> struct phy_g12a_usb3_pcie_priv *priv = phy_get_drvdata(phy);
> >>
> >> - return reset_control_reset(priv->reset);
> >> + if (priv->mode == PHY_TYPE_USB3)
> >> + return reset_control_reset(priv->reset);
> >> +
> >> + return 0;
> >> }
> >>
> >> static struct phy *phy_g12a_usb3_pcie_xlate(struct device *dev,
> >> @@ -326,6 +375,9 @@ static struct phy *phy_g12a_usb3_pcie_xlate(struct device *dev,
> >> static const struct phy_ops phy_g12a_usb3_pcie_ops = {
> >> .init = phy_g12a_usb3_pcie_init,
> >> .exit = phy_g12a_usb3_pcie_exit,
> >> + .power_on = phy_g12a_usb3_pcie_power_on,
> >> + .power_off = phy_g12a_usb3_pcie_power_off,
> >> + .reset = phy_g12a_usb3_pcie_reset,
> >> .owner = THIS_MODULE,
> >> };
> >>
> >> --
> >> 2.17.1
> >>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4] mm/kasan: dump alloc and free stack for page allocator
From: Walter Wu @ 2019-09-11 13:01 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov,
Matthias Brugger, Andrew Morton, Martin Schwidefsky,
Andrey Konovalov, Qian Cai, Vlastimil Babka, Arnd Bergmann
Cc: Walter Wu, wsd_upstream, linux-kernel, kasan-dev, linux-mm,
linux-mediatek, linux-arm-kernel
This patch is KASAN's report adds the alloc/free stack for page allocator
in order to help programmer to see memory corruption caused by the page.
By default, KASAN doesn't record alloc or free stack for page allocator.
It is difficult to fix up the page use-after-free or double-free issue.
We add the following changing:
1) KASAN enable PAGE_OWNER by default to get the alloc stack of the page.
2) Add new feature option to get the free stack of the page.
The new feature KASAN_DUMP_PAGE depends on DEBUG_PAGEALLOC, it will help
to record free stack of the page, it is very helpful for solving the page
use-after-free or double-free issue.
When KASAN_DUMP_PAGE is enabled then KASAN's report will show the last
alloc and free stack of the page, it should be:
BUG: KASAN: use-after-free in kmalloc_pagealloc_uaf+0x70/0x80
Write of size 1 at addr ffffffc0d60e4000 by task cat/115
...
prep_new_page+0x1c8/0x218
get_page_from_freelist+0x1ba0/0x28d0
__alloc_pages_nodemask+0x1d4/0x1978
kmalloc_order+0x28/0x58
kmalloc_order_trace+0x28/0xe0
kmalloc_pagealloc_uaf+0x2c/0x80
page last free stack trace:
__free_pages_ok+0x116c/0x1630
__free_pages+0x50/0x78
kfree+0x1c4/0x250
kmalloc_pagealloc_uaf+0x38/0x80
Changes since v1:
- slim page_owner and move it into kasan
- enable the feature by default
Changes since v2:
- enable PAGE_OWNER by default
- use DEBUG_PAGEALLOC to get page information
Changes since v3:
- correct typo
cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
cc: Vlastimil Babka <vbabka@suse.cz>
cc: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
---
lib/Kconfig.kasan | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index 4fafba1a923b..a3683e952b10 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -41,6 +41,7 @@ config KASAN_GENERIC
select SLUB_DEBUG if SLUB
select CONSTRUCTORS
select STACKDEPOT
+ select PAGE_OWNER
help
Enables generic KASAN mode.
Supported in both GCC and Clang. With GCC it requires version 4.9.2
@@ -63,6 +64,7 @@ config KASAN_SW_TAGS
select SLUB_DEBUG if SLUB
select CONSTRUCTORS
select STACKDEPOT
+ select PAGE_OWNER
help
Enables software tag-based KASAN mode.
This mode requires Top Byte Ignore support by the CPU and therefore
@@ -135,6 +137,19 @@ config KASAN_S390_4_LEVEL_PAGING
to 3TB of RAM with KASan enabled). This options allows to force
4-level paging instead.
+config KASAN_DUMP_PAGE
+ bool "Dump the last allocation and freeing stack of the page"
+ depends on KASAN
+ select DEBUG_PAGEALLOC
+ help
+ By default, KASAN enable PAGE_OWNER only to record alloc stack
+ for page allocator. It is difficult to fix up page use-after-free
+ or double-free issue.
+ The feature depends on DEBUG_PAGEALLOC, it will extra record
+ free stack of the page. It is very helpful for solving the page
+ use-after-free or double-free issue.
+ The feature will have a small memory overhead.
+
config TEST_KASAN
tristate "Module for testing KASAN for bug detection"
depends on m && KASAN
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
From: David Hildenbrand @ 2019-09-11 13:03 UTC (permalink / raw)
To: Michal Hocko
Cc: Yang Zhang, Pankaj Gupta, kvm list, Michael S. Tsirkin,
Catalin Marinas, Alexander Duyck, lcapitulino, linux-mm,
Alexander Duyck, will, Andrea Arcangeli, virtio-dev, Rik van Riel,
Matthew Wilcox, Wang, Wei W, ying.huang, Konrad Rzeszutek Wilk,
Dan Williams, linux-arm-kernel, Oscar Salvador,
Nitesh Narayan Lal, Dave Hansen, LKML, Paolo Bonzini,
Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <20190911125413.GY4023@dhcp22.suse.cz>
On 11.09.19 14:54, Michal Hocko wrote:
> On Wed 11-09-19 14:42:41, David Hildenbrand wrote:
>> On 11.09.19 14:25, Michal Hocko wrote:
>>> On Wed 11-09-19 14:19:41, Michal Hocko wrote:
>>>> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
>>>>> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
>>>>>> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
>>>>>> [...]
>>>>>>> We don't put any limitations on the allocator other then that it needs to
>>>>>>> clean up the metadata on allocation, and that it cannot allocate a page
>>>>>>> that is in the process of being reported since we pulled it from the
>>>>>>> free_list. If the page is a "Reported" page then it decrements the
>>>>>>> reported_pages count for the free_area and makes sure the page doesn't
>>>>>>> exist in the "Boundary" array pointer value, if it does it moves the
>>>>>>> "Boundary" since it is pulling the page.
>>>>>>
>>>>>> This is still a non-trivial limitation on the page allocation from an
>>>>>> external code IMHO. I cannot give any explicit reason why an ordering on
>>>>>> the free list might matter (well except for page shuffling which uses it
>>>>>> to make physical memory pattern allocation more random) but the
>>>>>> architecture seems hacky and dubious to be honest. It shoulds like the
>>>>>> whole interface has been developed around a very particular and single
>>>>>> purpose optimization.
>>>>>>
>>>>>> I remember that there was an attempt to report free memory that provided
>>>>>> a callback mechanism [1], which was much less intrusive to the internals
>>>>>> of the allocator yet it should provide a similar functionality. Did you
>>>>>> see that approach? How does this compares to it? Or am I completely off
>>>>>> when comparing them?
>>>>>>
>>>>>> [1] mostly likely not the latest version of the patchset
>>>>>> http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
>>>>>
>>>>> Linus nacked that one. He thinks invoking callbacks with lots of
>>>>> internal mm locks is too fragile.
>>>>
>>>> I would be really curious how much he would be happy about injecting
>>>> other restrictions on the allocator like this patch proposes. This is
>>>> more intrusive as it has a higher maintenance cost longterm IMHO.
>>>
>>> Btw. I do agree that callbacks with internal mm locks are not great
>>> either. We do have a model for that in mmu_notifiers and it is something
>>> I do consider PITA, on the other hand it is mostly sleepable part of the
>>> interface which makes it the real pain. The above callback mechanism was
>>> explicitly documented with restrictions and that the context is
>>> essentially atomic with no access to particular struct pages and no
>>> expensive operations possible. So in the end I've considered it
>>> acceptably painful. Not that I want to override Linus' nack but if
>>> virtualization usecases really require some form of reporting and no
>>> other way to do that push people to invent even more interesting
>>> approaches then we should simply give them/you something reasonable
>>> and least intrusive to our internals.
>>>
>>
>> The issue with "[PATCH v14 4/5] mm: support reporting free page blocks"
>> is that it cannot really handle the use case we have here if I am not
>> wrong. While a page is getting processed by the hypervisor (e.g.
>> MADV_DONTNEED), it must not get reused.
>
> What prevents to use the callback to get a list of pfn ranges to work on
> and then use something like start_isolate_page_range on the collected
> pfn ranges to make sure nobody steals pages from under your feet, do
> your thing and drop the isolated state afterwards.
>
> I am saying somethig like because you wouldn't really want a generic
> has_unmovable_pages but rather
> if (!page_ref_count(page)) {
> if (PageBuddy(page))
> iter += (1 << page_order(page)) - 1;
> continue;
> }
> subset of it.
>
Something slightly similar is being performed by Nitesh's patch set. On
every free of a certain granularity, he records it in the bitmap. These
bits are "hints of free pages".
A thread then walks over the bitmap and tries to allocate the "hints".
If the pages were already reused, the bit is silently cleared.
Instead of allocating/freeing, we could only try to isolate the
pageblock, then test if free. (One of the usual issues to work around is
MAX_ORDER-1 crossing pageblocks, that might need special care)
I think you should have a look at the rough idea of Nitesh's patch set
to see if something like that is going into a better direction. The
bitmap part is in place to do bulk reporting and avoid duplicate reports.
I think main points we want (and what I am missing from callback idea
being discussed) are
1. Do bulk reporting only when a certain threshold is reached
2. Report only bigger granularities (especially, avoid THP splits in the
hypervisor - >= 2MB proofed to be effective)
3. Avoid reporting what has just been reported.
4. Continuously report, not the "one time report everything" approach.
--
Thanks,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 6/6] arm64: dts: khadas-vim3: add commented support for PCIe
From: Andrew Murray @ 2019-09-11 13:11 UTC (permalink / raw)
To: Neil Armstrong
Cc: lorenzo.pieralisi, khilman, linux-pci, linux-kernel, kishon, repk,
maz, bhelgaas, linux-amlogic, yue.wang, linux-arm-kernel
In-Reply-To: <bf7b735d-e682-52db-ea8c-4ccd786f0ed9@baylibre.com>
On Wed, Sep 11, 2019 at 02:58:18PM +0200, Neil Armstrong wrote:
> On 11/09/2019 14:50, Andrew Murray wrote:
> > On Sun, Sep 08, 2019 at 01:42:58PM +0000, Neil Armstrong wrote:
> >> The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
> >> lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
> >> an USB3.0 Type A connector and a M.2 Key M slot.
> >> The PHY driving these differential lines is shared between
> >> the USB3.0 controller and the PCIe Controller, thus only
> >> a single controller can use it.
> >>
> >> The needed DT configuration when the MCU is configured to mux
> >> the PCIe/USB3.0 differential lines to the M.2 Key M slot is
> >> added commented and may uncommented to disable USB3.0 from the
> >
> > *and may be*
> >
> >> USB Complex and enable the PCIe controller.
> >>
> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> >> ---
> >> .../amlogic/meson-g12b-a311d-khadas-vim3.dts | 22 +++++++++++++++++++
> >> .../amlogic/meson-g12b-s922x-khadas-vim3.dts | 22 +++++++++++++++++++
> >> .../boot/dts/amlogic/meson-khadas-vim3.dtsi | 4 ++++
> >> .../dts/amlogic/meson-sm1-khadas-vim3l.dts | 22 +++++++++++++++++++
> >> 4 files changed, 70 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
> >> index 3a6a1e0c1e32..0577b1435cbb 100644
> >> --- a/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
> >> +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-a311d-khadas-vim3.dts
> >> @@ -14,3 +14,25 @@
> >> / {
> >> compatible = "khadas,vim3", "amlogic,a311d", "amlogic,g12b";
> >> };
> >> +
> >> +/*
> >> + * The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
> >> + * lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
> >> + * an USB3.0 Type A connector and a M.2 Key M slot.
> >> + * The PHY driving these differential lines is shared between
> >> + * the USB3.0 controller and the PCIe Controller, thus only
> >> + * a single controller can use it.
> >> + * If the MCU is configured to mux the PCIe/USB3.0 differential lines
> >> + * to the M.2 Key M slot, uncomment the following block to disable
> >> + * USB3.0 from the USB Complex and enable the PCIe controller.
> >> + */
> >> +/*
> >> +&pcie {
> >> + status = "okay";
> >> +};
> >> +
> >> +&usb {
> >> + phys = <&usb2_phy0>, <&usb2_phy1>;
> >> + phy-names = "usb2-phy0", "usb2-phy1";
> >> +};
> >
> > I assume there is no way other way to determine from the hardware which way
> > the mux is set?
>
> No, it would be simpler :-/ The MUX is on-board and the MCU drives the MUX selection.
>
> You can look at the https://dl.khadas.com/Hardware/VIM3/Schematic/VIM3_V11_Sch.pdf
> The PCIE_EN signal is driven by the STM8S MCU.
Ah I see.
>
> >
> > Otherwise phy_g12a_usb3_pcie_xlate could determine the hardware mode, and
> > reject the phy instance with the wrong mode. Thus resulting in either the
> > PCI or USB to fail their probe. And avoiding the need to modify the DT on
> > boot.
>
> Yep, it would have been simpler this way. Maybe a board vendor will set a gpio ?
> who knows, but for actual boards it's static or with 0ohm resistors, and for the
> VIM3 we only know by asking the MCU.
>
> Maybe we could add a fake PHY as a MCU MFD subdevice, wrapping calls to the
> right PHY. But for now the MCU has no upstream driver anyway.
OK
Thanks,
Andrew Murray
>
> Neil
>
> >
> > Thanks,
> >
> > Andrew Murray
> >
> >> + */
> >> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts b/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts
> >> index b73deb282120..1ef5c2f04f67 100644
> >> --- a/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts
> >> +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-s922x-khadas-vim3.dts
> >> @@ -14,3 +14,25 @@
> >> / {
> >> compatible = "khadas,vim3", "amlogic,s922x", "amlogic,g12b";
> >> };
> >> +
> >> +/*
> >> + * The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
> >> + * lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
> >> + * an USB3.0 Type A connector and a M.2 Key M slot.
> >> + * The PHY driving these differential lines is shared between
> >> + * the USB3.0 controller and the PCIe Controller, thus only
> >> + * a single controller can use it.
> >> + * If the MCU is configured to mux the PCIe/USB3.0 differential lines
> >> + * to the M.2 Key M slot, uncomment the following block to disable
> >> + * USB3.0 from the USB Complex and enable the PCIe controller.
> >> + */
> >> +/*
> >> +&pcie {
> >> + status = "okay";
> >> +};
> >> +
> >> +&usb {
> >> + phys = <&usb2_phy0>, <&usb2_phy1>;
> >> + phy-names = "usb2-phy0", "usb2-phy1";
> >> +};
> >> + */
> >> diff --git a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
> >> index 8647da7d6609..eac5720dc15f 100644
> >> --- a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
> >> +++ b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3.dtsi
> >> @@ -246,6 +246,10 @@
> >> linux,rc-map-name = "rc-khadas";
> >> };
> >>
> >> +&pcie {
> >> + reset-gpios = <&gpio GPIOA_8 GPIO_ACTIVE_LOW>;
> >> +};
> >> +
> >> &pwm_ef {
> >> status = "okay";
> >> pinctrl-0 = <&pwm_e_pins>;
> >> diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts b/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
> >> index 5233bd7cacfb..d9c7cbedce53 100644
> >> --- a/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
> >> +++ b/arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts
> >> @@ -68,3 +68,25 @@
> >> clock-names = "clkin1";
> >> status = "okay";
> >> };
> >> +
> >> +/*
> >> + * The VIM3 on-board MCU can mux the PCIe/USB3.0 shared differential
> >> + * lines using a FUSB340TMX USB 3.1 SuperSpeed Data Switch between
> >> + * an USB3.0 Type A connector and a M.2 Key M slot.
> >> + * The PHY driving these differential lines is shared between
> >> + * the USB3.0 controller and the PCIe Controller, thus only
> >> + * a single controller can use it.
> >> + * If the MCU is configured to mux the PCIe/USB3.0 differential lines
> >> + * to the M.2 Key M slot, uncomment the following block to disable
> >> + * USB3.0 from the USB Complex and enable the PCIe controller.
> >> + */
> >> +/*
> >> +&pcie {
> >> + status = "okay";
> >> +};
> >> +
> >> +&usb {
> >> + phys = <&usb2_phy0>, <&usb2_phy1>;
> >> + phy-names = "usb2-phy0", "usb2-phy1";
> >> +};
> >> + */
> >> --
> >> 2.17.1
> >>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
From: Michal Hocko @ 2019-09-11 13:20 UTC (permalink / raw)
To: David Hildenbrand
Cc: Yang Zhang, Pankaj Gupta, kvm list, Michael S. Tsirkin,
Catalin Marinas, Alexander Duyck, lcapitulino, linux-mm,
Alexander Duyck, will, Andrea Arcangeli, virtio-dev, Rik van Riel,
Matthew Wilcox, Wang, Wei W, ying.huang, Konrad Rzeszutek Wilk,
Dan Williams, linux-arm-kernel, Oscar Salvador,
Nitesh Narayan Lal, Dave Hansen, LKML, Paolo Bonzini,
Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <736594d6-b9ae-ddb9-2b96-85648728ef33@redhat.com>
On Wed 11-09-19 15:03:39, David Hildenbrand wrote:
> On 11.09.19 14:54, Michal Hocko wrote:
> > On Wed 11-09-19 14:42:41, David Hildenbrand wrote:
> >> On 11.09.19 14:25, Michal Hocko wrote:
> >>> On Wed 11-09-19 14:19:41, Michal Hocko wrote:
> >>>> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
> >>>>> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
> >>>>>> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> >>>>>> [...]
> >>>>>>> We don't put any limitations on the allocator other then that it needs to
> >>>>>>> clean up the metadata on allocation, and that it cannot allocate a page
> >>>>>>> that is in the process of being reported since we pulled it from the
> >>>>>>> free_list. If the page is a "Reported" page then it decrements the
> >>>>>>> reported_pages count for the free_area and makes sure the page doesn't
> >>>>>>> exist in the "Boundary" array pointer value, if it does it moves the
> >>>>>>> "Boundary" since it is pulling the page.
> >>>>>>
> >>>>>> This is still a non-trivial limitation on the page allocation from an
> >>>>>> external code IMHO. I cannot give any explicit reason why an ordering on
> >>>>>> the free list might matter (well except for page shuffling which uses it
> >>>>>> to make physical memory pattern allocation more random) but the
> >>>>>> architecture seems hacky and dubious to be honest. It shoulds like the
> >>>>>> whole interface has been developed around a very particular and single
> >>>>>> purpose optimization.
> >>>>>>
> >>>>>> I remember that there was an attempt to report free memory that provided
> >>>>>> a callback mechanism [1], which was much less intrusive to the internals
> >>>>>> of the allocator yet it should provide a similar functionality. Did you
> >>>>>> see that approach? How does this compares to it? Or am I completely off
> >>>>>> when comparing them?
> >>>>>>
> >>>>>> [1] mostly likely not the latest version of the patchset
> >>>>>> http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
> >>>>>
> >>>>> Linus nacked that one. He thinks invoking callbacks with lots of
> >>>>> internal mm locks is too fragile.
> >>>>
> >>>> I would be really curious how much he would be happy about injecting
> >>>> other restrictions on the allocator like this patch proposes. This is
> >>>> more intrusive as it has a higher maintenance cost longterm IMHO.
> >>>
> >>> Btw. I do agree that callbacks with internal mm locks are not great
> >>> either. We do have a model for that in mmu_notifiers and it is something
> >>> I do consider PITA, on the other hand it is mostly sleepable part of the
> >>> interface which makes it the real pain. The above callback mechanism was
> >>> explicitly documented with restrictions and that the context is
> >>> essentially atomic with no access to particular struct pages and no
> >>> expensive operations possible. So in the end I've considered it
> >>> acceptably painful. Not that I want to override Linus' nack but if
> >>> virtualization usecases really require some form of reporting and no
> >>> other way to do that push people to invent even more interesting
> >>> approaches then we should simply give them/you something reasonable
> >>> and least intrusive to our internals.
> >>>
> >>
> >> The issue with "[PATCH v14 4/5] mm: support reporting free page blocks"
> >> is that it cannot really handle the use case we have here if I am not
> >> wrong. While a page is getting processed by the hypervisor (e.g.
> >> MADV_DONTNEED), it must not get reused.
> >
> > What prevents to use the callback to get a list of pfn ranges to work on
> > and then use something like start_isolate_page_range on the collected
> > pfn ranges to make sure nobody steals pages from under your feet, do
> > your thing and drop the isolated state afterwards.
> >
> > I am saying somethig like because you wouldn't really want a generic
> > has_unmovable_pages but rather
> > if (!page_ref_count(page)) {
> > if (PageBuddy(page))
> > iter += (1 << page_order(page)) - 1;
> > continue;
> > }
> > subset of it.
> >
>
> Something slightly similar is being performed by Nitesh's patch set. On
> every free of a certain granularity, he records it in the bitmap. These
> bits are "hints of free pages".
>
> A thread then walks over the bitmap and tries to allocate the "hints".
> If the pages were already reused, the bit is silently cleared.
>
> Instead of allocating/freeing, we could only try to isolate the
> pageblock, then test if free. (One of the usual issues to work around is
> MAX_ORDER-1 crossing pageblocks, that might need special care)
OK, cool that I have reinvented the wheel ;). Allocation is indeed not
necessary as long as pages are isolated because nobody will allocate
them.
> I think you should have a look at the rough idea of Nitesh's patch set
> to see if something like that is going into a better direction. The
> bitmap part is in place to do bulk reporting and avoid duplicate reports.
Let's see how much time I can find for that in my endless inbox whack a mole.
> I think main points we want (and what I am missing from callback idea
> being discussed) are
> 1. Do bulk reporting only when a certain threshold is reached
Is a time based approach too coarse?
> 2. Report only bigger granularities (especially, avoid THP splits in the
> hypervisor - >= 2MB proofed to be effective)
the callback has supported order based scan in some of its iteration.
> 3. Avoid reporting what has just been reported.
Is the overhead of checking a pfn range in a bitmask that much of an
overhead to really care?
> 4. Continuously report, not the "one time report everything" approach.
So you mean the allocator reporting this rather than an external code to
poll right? I do not know, how much this is nice to have than must have?
--
Michal Hocko
SUSE Labs
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
From: Nitesh Narayan Lal @ 2019-09-11 13:19 UTC (permalink / raw)
To: Michal Hocko, David Hildenbrand
Cc: Yang Zhang, Pankaj Gupta, kvm list, Michael S. Tsirkin,
Catalin Marinas, Alexander Duyck, lcapitulino, linux-mm,
Alexander Duyck, will, Andrea Arcangeli, virtio-dev, Rik van Riel,
Matthew Wilcox, Wang, Wei W, ying.huang, Konrad Rzeszutek Wilk,
Dan Williams, linux-arm-kernel, Oscar Salvador, Dave Hansen, LKML,
Paolo Bonzini, Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <20190911125413.GY4023@dhcp22.suse.cz>
On 9/11/19 8:54 AM, Michal Hocko wrote:
> On Wed 11-09-19 14:42:41, David Hildenbrand wrote:
>> On 11.09.19 14:25, Michal Hocko wrote:
>>> On Wed 11-09-19 14:19:41, Michal Hocko wrote:
>>>> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
>>>>> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
>>>>>> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
>>>>>> [...]
>>>>>>> We don't put any limitations on the allocator other then that it needs to
>>>>>>> clean up the metadata on allocation, and that it cannot allocate a page
>>>>>>> that is in the process of being reported since we pulled it from the
>>>>>>> free_list. If the page is a "Reported" page then it decrements the
>>>>>>> reported_pages count for the free_area and makes sure the page doesn't
>>>>>>> exist in the "Boundary" array pointer value, if it does it moves the
>>>>>>> "Boundary" since it is pulling the page.
>>>>>> This is still a non-trivial limitation on the page allocation from an
>>>>>> external code IMHO. I cannot give any explicit reason why an ordering on
>>>>>> the free list might matter (well except for page shuffling which uses it
>>>>>> to make physical memory pattern allocation more random) but the
>>>>>> architecture seems hacky and dubious to be honest. It shoulds like the
>>>>>> whole interface has been developed around a very particular and single
>>>>>> purpose optimization.
>>>>>>
>>>>>> I remember that there was an attempt to report free memory that provided
>>>>>> a callback mechanism [1], which was much less intrusive to the internals
>>>>>> of the allocator yet it should provide a similar functionality. Did you
>>>>>> see that approach? How does this compares to it? Or am I completely off
>>>>>> when comparing them?
>>>>>>
>>>>>> [1] mostly likely not the latest version of the patchset
>>>>>> http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
>>>>> Linus nacked that one. He thinks invoking callbacks with lots of
>>>>> internal mm locks is too fragile.
>>>> I would be really curious how much he would be happy about injecting
>>>> other restrictions on the allocator like this patch proposes. This is
>>>> more intrusive as it has a higher maintenance cost longterm IMHO.
>>> Btw. I do agree that callbacks with internal mm locks are not great
>>> either. We do have a model for that in mmu_notifiers and it is something
>>> I do consider PITA, on the other hand it is mostly sleepable part of the
>>> interface which makes it the real pain. The above callback mechanism was
>>> explicitly documented with restrictions and that the context is
>>> essentially atomic with no access to particular struct pages and no
>>> expensive operations possible. So in the end I've considered it
>>> acceptably painful. Not that I want to override Linus' nack but if
>>> virtualization usecases really require some form of reporting and no
>>> other way to do that push people to invent even more interesting
>>> approaches then we should simply give them/you something reasonable
>>> and least intrusive to our internals.
>>>
>> The issue with "[PATCH v14 4/5] mm: support reporting free page blocks"
>> is that it cannot really handle the use case we have here if I am not
>> wrong. While a page is getting processed by the hypervisor (e.g.
>> MADV_DONTNEED), it must not get reused.
> What prevents to use the callback to get a list of pfn ranges to work on
> and then use something like start_isolate_page_range on the collected
> pfn ranges to make sure nobody steals pages from under your feet, do
> your thing and drop the isolated state afterwards.
>
In my series, I am doing something similar.
- Track (MAX_ORDER - 2) free pages in bitmap maintained on a per-zone
basis.
- Use __isolate_free_page on the pages marked in the bitmap and are
still free.
- Report chunks of 16 isolated pages to the hypervisor.
- Return them back to the buddy once the request is processed.
> I am saying somethig like because you wouldn't really want a generic
> has_unmovable_pages but rather
> if (!page_ref_count(page)) {
> if (PageBuddy(page))
> iter += (1 << page_order(page)) - 1;
> continue;
> }
> subset of it.
--
Thanks
Nitesh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* offline CPUs shown in sysfs core_siblings mask
From: Brice Goglin @ 2019-09-11 13:23 UTC (permalink / raw)
To: linux-arm-kernel
Hello
We have a report from a user of hwloc/lstopo on ThunderX2 that complains
that offline CPUs are shown in sysfs cpu core_siblings files.
$ cat sys/devices/system/cpu/*/topology/core_siblings
000000,0fffffff
000000,0fffffff
000000,0fffffff
000000,0fffffff
ffffff,f0000000
ffffff,f0000000
ffffff,f0000000
ffffff,f0000000
Only 8 online logicial CPUs, but 56 are shown in these masks. This is on
RHEL7 with a kernel 4.14.0-115.2.2.el7a.aarch64 but I couldn't find any
significant change in Linux git.
On x86, only online CPUs are shown, you would get:
$ cat sys/devices/system/cpu/*/topology/core_siblings
000000,0000000f
000000,0000000f
000000,0000000f
000000,0000000f
000000,f0000000
000000,f0000000
000000,f0000000
000000,f0000000
I guess thread_siblings has the same behavior but I couldn't test it.
Do you ever plan to align the ARM behavior with x86? I couldn't find
anything in the doc stating whether offline CPUs are supposed to be
shown there, but it would be nice to have the same behavior across
different architectures. I couldn't find any such code for POWER either.
Brice
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/4] gpio: of: Make of_get_named_gpiod_flags() private
From: Linus Walleij @ 2019-09-11 13:45 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org,
Bartosz Golaszewski, Rob Herring, Frank Rowand, Linux ARM
In-Reply-To: <20190906084539.21838-2-geert+renesas@glider.be>
On Fri, Sep 6, 2019 at 9:45 AM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Since commit f626d6dfb7098525 ("gpio: of: Break out OF-only code"),
> there are no more users of of_get_named_gpiod_flags() outside
> gpiolib-of.c.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Patch applied.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/4] gpio: of: Make of_gpio_simple_xlate() private
From: Linus Walleij @ 2019-09-11 13:46 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org,
Bartosz Golaszewski, Rob Herring, Frank Rowand, Linux ARM
In-Reply-To: <20190906084539.21838-3-geert+renesas@glider.be>
On Fri, Sep 6, 2019 at 9:45 AM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Since commit 9a95e8d25a140ba9 ("gpio: remove etraxfs driver"), there are
> no more users of of_gpio_simple_xlate() outside gpiolib-of.c.
> All GPIO drivers that need it now rely on of_gpiochip_add() setting it
> up as the default translate function.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Patch applied.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] gpio: of: Switch to EXPORT_SYMBOL_GPL()
From: Linus Walleij @ 2019-09-11 13:47 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org,
Bartosz Golaszewski, Rob Herring, Frank Rowand, Linux ARM
In-Reply-To: <20190906084539.21838-4-geert+renesas@glider.be>
On Fri, Sep 6, 2019 at 9:45 AM Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> All exported functions provide genuine Linux-specific functionality.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Patch applied.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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