* Re: [PATCH] ARM: dts: imx6dl: SolidRun: add phy node with 100Mb/s max-speed
From: Andrew Lunn @ 2019-09-10 18:50 UTC (permalink / raw)
To: tinywrkb
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Shawn Guo, Sascha Hauer, Russell King, open list, Rob Herring,
NXP Linux Team, Pengutronix Kernel Team, Fabio Estevam,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190910155507.491230-1-tinywrkb@gmail.com>
On Tue, Sep 10, 2019 at 06:55:07PM +0300, tinywrkb wrote:
> Cubox-i Solo/DualLite carrier board has 100Mb/s magnetics while the
> Atheros AR8035 PHY on the MicroSoM v1.3 CPU module is a 1GbE PHY device.
>
> Since commit 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in
> genphy_read_status") ethernet is broken on Cubox-i Solo/DualLite devices.
Hi Tinywrkb
You emailed lots of people, but missed the PHY maintainers :-(
Are you sure this is the patch which broken it? Did you do a git
bisect.
Thanks
Andrew
_______________________________________________
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-10 18:00 UTC (permalink / raw)
To: Alexander Duyck
Cc: Yang Zhang, Pankaj Gupta, kvm list, David Hildenbrand,
Catalin Marinas, lcapitulino, linux-mm, Alexander Duyck, will,
Andrea Arcangeli, virtio-dev, Michael S. Tsirkin, Matthew Wilcox,
Wang, Wei W, ying.huang, Rik van Riel, 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: <20190910175213.GD4023@dhcp22.suse.cz>
On Tue 10-09-19 19:52:13, Michal Hocko wrote:
> On Tue 10-09-19 09:05:43, Alexander Duyck wrote:
[...]
> > All this is providing is just a report and it is optional if the
> > hypervisor will act on it or not. If the hypervisor takes some sort of
> > action on the page, then the expectation is that the hypervisor will
> > use some sort of mechanism such as a page fault to discover when the
> > page is used again.
>
> OK so the baloon driver is in charge of this metadata and the allocator
> has to live with that. Isn't that a layer violation?
Another thing that is not clear to me is how these marked pages are
different from any other free pages. All of them are unused and you are
losing your metadata as soon as the page gets allocated because the page
changes its owner and the struct page belongs to 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: Michal Hocko @ 2019-09-10 17:52 UTC (permalink / raw)
To: Alexander Duyck
Cc: Yang Zhang, Pankaj Gupta, kvm list, David Hildenbrand,
Catalin Marinas, lcapitulino, linux-mm, Alexander Duyck, will,
Andrea Arcangeli, virtio-dev, Michael S. Tsirkin, Matthew Wilcox,
Wang, Wei W, ying.huang, Rik van Riel, 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: <CAKgT0UdB4qp3vFGrYEs=FwSXKpBEQ7zo7DV55nJRO2C-KCEOrw@mail.gmail.com>
On Tue 10-09-19 09:05:43, Alexander Duyck wrote:
> On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
> > > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> wrote:
> > > >
> > > > I wanted to review "mm: Introduce Reported pages" just realize that I
> > > > have no clue on what is going on so returned to the cover and it didn't
> > > > really help much. I am completely unfamiliar with virtio so please bear
> > > > with me.
> > > >
> > > > On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
> > > > [...]
> > > > > This series provides an asynchronous means of reporting to a hypervisor
> > > > > that a guest page is no longer in use and can have the data associated
> > > > > with it dropped. To do this I have implemented functionality that allows
> > > > > for what I am referring to as unused page reporting
> > > > >
> > > > > The functionality for this is fairly simple. When enabled it will allocate
> > > > > statistics to track the number of reported pages in a given free area.
> > > > > When the number of free pages exceeds this value plus a high water value,
> > > > > currently 32, it will begin performing page reporting which consists of
> > > > > pulling pages off of free list and placing them into a scatter list. The
> > > > > scatterlist is then given to the page reporting device and it will perform
> > > > > the required action to make the pages "reported", in the case of
> > > > > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > > > > and as such they are forced out of the guest. After this they are placed
> > > > > back on the free list,
> > > >
> > > > And here I am reallly lost because "forced out of the guest" makes me
> > > > feel that those pages are no longer usable by the guest. So how come you
> > > > can add them back to the free list. I suspect understanding this part
> > > > will allow me to understand why we have to mark those pages and prevent
> > > > merging.
> > >
> > > Basically as the paragraph above mentions "forced out of the guest"
> > > really is just the hypervisor calling MADV_DONTNEED on the page in
> > > question. So the behavior is the same as any userspace application
> > > that calls MADV_DONTNEED where the contents are no longer accessible
> > > from userspace and attempting to access them will result in a fault
> > > and the page being populated with a zero fill on-demand page, or a
> > > copy of the file contents if the memory is file backed.
> >
> > As I've said I have no idea about virt so this doesn't really tell me
> > much. Does that mean that if somebody allocates such a page and tries to
> > access it then virt will handle a fault and bring it back?
>
> Actually I am probably describing too much as the MADV_DONTNEED is the
> hypervisor behavior in response to the virtio-balloon notification. A
> more thorough explanation of it can be found by just running "man
> madvise", probably best just to leave it at that since I am probably
> confusing things by describing hypervisor behavior in a kernel patch
> set.
This analogy is indeed confusing and doesn't help to build a picture.
> For the most part all the page reporting really does is provide a way
> to incrementally identify unused regions of memory in the buddy
> allocator. That in turn is used by virtio-balloon in a polling thread
> to report to the hypervisor what pages are not in use so that it can
> make a decision on what to do with the pages now that it knows they
> are unused.
So essentially you want to store metadata into free pages and control
what the allocator can do with them? Namely buddy merging if the type
doesn't match?
> All this is providing is just a report and it is optional if the
> hypervisor will act on it or not. If the hypervisor takes some sort of
> action on the page, then the expectation is that the hypervisor will
> use some sort of mechanism such as a page fault to discover when the
> page is used again.
OK so the baloon driver is in charge of this metadata and the allocator
has to live with that. Isn't that a layer violation?
--
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
* 📪 Huhu. wollte mich mal wieder bei dir melden.
From: nik_bin_nek_alwi @ 2019-09-10 13:06 UTC (permalink / raw)
To: rob herring, hsweeten, buildroot, linux arm kernel, Paul Chavent
Kannst du dir das vorstellen? http://ngblqax.Cal149.xyz/index
___
Gruß
nik_bin_nek_alwi@yahoo.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 v9 3/8] mm: Move set/get_pcppage_migratetype to mmzone.h
From: Michal Hocko @ 2019-09-10 17:45 UTC (permalink / raw)
To: Alexander Duyck
Cc: Yang Zhang, Pankaj Gupta, kvm list, David Hildenbrand,
Catalin Marinas, lcapitulino, linux-mm, Alexander Duyck, will,
Andrea Arcangeli, virtio-dev, Michael S. Tsirkin, Matthew Wilcox,
Wang, Wei W, ying.huang, Rik van Riel, 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: <CAKgT0Ud1xqhEy_LL4AfMgreP0uXrkF-fSDn=6uDXfn7Pvj5AAw@mail.gmail.com>
On Tue 10-09-19 07:46:50, Alexander Duyck wrote:
> On Tue, Sep 10, 2019 at 5:23 AM Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Sat 07-09-19 10:25:28, Alexander Duyck wrote:
> > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > >
> > > In order to support page reporting it will be necessary to store and
> > > retrieve the migratetype of a page. To enable that I am moving the set and
> > > get operations for pcppage_migratetype into the mm/internal.h header so
> > > that they can be used outside of the page_alloc.c file.
> >
> > Please describe who is the user and why does it needs this interface.
> > This is really important because migratetype is an MM internal thing and
> > external users shouldn't really care about it at all. We really do not
> > want a random code to call those, especially the set_pcppage_migratetype.
>
> I was using it to store the migratetype of the page so that I could
> find the boundary list that contained the reported page as the array
> is indexed based on page order and migratetype. However on further
> discussion I am thinking I may just use page->index directly to index
> into the boundary array. Doing that I should be able to get a very
> slight improvement in lookup time since I am not having to pull order
> and migratetype and then compute the index based on that. In addition
> it becomes much more clear as to what is going on, and if needed I
> could add debug checks to verify the page is "Reported" and that the
> "Buddy" page type is set.
Be careful though. A free page belongs to the page allocator and it is
free to reuse any fields for its purpose so using any of them nilly
willy is no go. If you need to stuff something like that then there
better be an api the allocator is aware of. My main objection is the
abuse migrate type. There might be other ways to express what you need.
Please make sure you clearly define that though.
--
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: [V2, 2/2] media: i2c: Add more sensor modes for ov8856 camera sensor
From: Andy Shevchenko @ 2019-09-10 17:44 UTC (permalink / raw)
To: dongchun.zhu
Cc: mark.rutland, devicetree, drinkcat, srv_heupstream, shengnan.wang,
tfiga, louis.kuo, sj.huang, robh+dt, linux-mediatek, sakari.ailus,
matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20190910130446.26413-3-dongchun.zhu@mediatek.com>
On Tue, Sep 10, 2019 at 09:04:46PM +0800, dongchun.zhu@mediatek.com wrote:
> From: Dongchun Zhu <dongchun.zhu@mediatek.com>
>
> This patch mainly adds two more sensor modes for OV8856 CMOS image sensor.
> That is, the resolution of 1632*1224 and 3264*2448, corresponding to the bayer order of BGGR.
> The sensor revision also differs in some OTP register.
> +static int __ov8856_power_on(struct ov8856 *ov8856)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(&ov8856->sd);
> + int ret;
> +
> + ret = clk_prepare_enable(ov8856->xvclk);
> + if (ret < 0) {
> + dev_err(&client->dev, "failed to enable xvclk\n");
> + return ret;
> + }
> +
> + gpiod_set_value_cansleep(ov8856->n_shutdn_gpio, GPIOD_OUT_LOW);
> +
> + ret = regulator_bulk_enable(OV8856_NUM_SUPPLIES, ov8856->supplies);
> + if (ret < 0) {
> + dev_err(&client->dev, "failed to enable regulators\n");
> + goto disable_clk;
> + }
> +
> + gpiod_set_value_cansleep(ov8856->n_shutdn_gpio, GPIOD_OUT_HIGH);
> +
> + usleep_range(1400, 1500);
This should be commented why this is needed and from where the requirement
comes from. Also, not, that 100us, which is only ~7%, is small margin.
Recommended one is ~20%.
> +
> + return 0;
> +
> +disable_clk:
> + clk_disable_unprepare(ov8856->xvclk);
> +
> + return ret;
> +}
> + ov8856->is_1B_revision = (val == OV8856_1B_MODULE) ? 1 : 0;
!! will give same result without using ternary operator.
> + ov8856->xvclk = devm_clk_get(&client->dev, "xvclk");
> + if (IS_ERR(ov8856->xvclk)) {
> + dev_err(&client->dev, "failed to get xvclk\n");
> + return -EINVAL;
> + }
Previously it was optional.
How did it work before and why it's not optional?
> + ov8856->n_shutdn_gpio = devm_gpiod_get(&client->dev, "reset",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(ov8856->n_shutdn_gpio)) {
> + dev_err(&client->dev, "failed to get reset-gpios\n");
> + return -EINVAL;
> + }
Ditto.
> +static const struct of_device_id ov8856_of_match[] = {
> + { .compatible = "ovti,ov8856" },
> + {},
No comma needed for terminator line.
> +};
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V2, 1/2] media: dt-bindings: media: i2c: Add bindings for ov8856
From: Andy Shevchenko @ 2019-09-10 17:37 UTC (permalink / raw)
To: dongchun.zhu
Cc: mark.rutland, devicetree, drinkcat, srv_heupstream, shengnan.wang,
tfiga, louis.kuo, sj.huang, robh+dt, linux-mediatek, sakari.ailus,
matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20190910130446.26413-2-dongchun.zhu@mediatek.com>
On Tue, Sep 10, 2019 at 09:04:45PM +0800, dongchun.zhu@mediatek.com wrote:
> From: Dongchun Zhu <dongchun.zhu@mediatek.com>
>
> This patch adds device tree bindings documentation for the ov8856 CMOS
> image sensor.
New bindings in YAML, please.
--
With Best Regards,
Andy Shevchenko
_______________________________________________
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 00/17] KVM/arm updates for 5.4
From: Paolo Bonzini @ 2019-09-10 17:09 UTC (permalink / raw)
To: Marc Zyngier, Radim Krčmář
Cc: Mark Rutland, kvm, Andre Przywara, Eric Auger, James Morse,
Zenghui Yu, Alexandru Elisei, kvmarm, linux-arm-kernel
In-Reply-To: <20190909134807.27978-1-maz@kernel.org>
On 09/09/19 15:47, Marc Zyngier wrote:
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-5.4
Pulled, thanks.
Paolo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Mainlining support for MStar ARMv7 SoCs; Where to start?
From: Daniel Palmer @ 2019-09-10 16:59 UTC (permalink / raw)
To: Chen-Yu Tsai; +Cc: Matthias Brugger, linux-arm-kernel
In-Reply-To: <CAGb2v67sT1K1_AmCZ5qpgJzPCaFvudrBoAjsXs4QatMB-bHkWg@mail.gmail.com>
Thanks for the input guys.
> > I think a shell is the minimum you should get to.
> > So my take would be to send basic DTS (and clocks, if needed) so that you can
> > boot into a shell, even using a initramfs.
>
> To expand on this, your basic DTS would likely include the CPU cores, an
> interrupt controller (GIC?), a basic timer block (ARM arch timer?), the
> UART(s), and a dummy clock for the UART(s).
Fortunately the core stuff is pretty standard; arch timer, GIC and
what seems to be a dw uart with one of the registers moved.
Interrupts for the uart actually go through another interrupt
controller that is wired to the GIC so I think in the first pass it
would be polled.
Based on your input I'm thinking a patch series that looks like this
for the first pass:
- patch to add arch/arm/mach-mstar and the bits in there
- patch for just enough of a DTS to boot a buildroot initramfs up to a shell
- patch for a basic defconfig
Thanks,
Daniel
_______________________________________________
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 net-next 0/6] net: stmmac: Improvements for -next
From: Jose Abreu @ 2019-09-10 16:50 UTC (permalink / raw)
To: Jose Abreu, netdev@vger.kernel.org
Cc: Joao Pinto, Alexandre Torgue, linux-kernel@vger.kernel.org,
David S. Miller, Maxime Coquelin, Giuseppe Cavallaro,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <cover.1568126224.git.joabreu@synopsys.com>
From: Jose Abreu <joabreu@synopsys.com>
Date: Sep/10/2019, 15:41:21 (UTC+00:00)
> Misc patches for -next. It includes:
> - Two fixes for features in -next only
> - New features support for GMAC cores (which includes GMAC4 and GMAC5)
BTW, just for reference (and because I forgot to attach it earlier),
this is the selftests output for GMAC5.10 after this patchset:
# ethtool -t ens4
The test result is PASS
The test extra info:
1. MAC Loopback 0
2. PHY Loopback 0
3. MMC Counters 0
4. EEE -95
5. Hash Filter MC 0
6. Perfect Filter UC 0
7. MC Filter 0
8. UC Filter 0
9. Flow Control 0
10. RSS -95
11. VLAN Filtering 0
12. Double VLAN Filtering 0
13. Flexible RX Parser 0
14. SA Insertion (desc) 0
15. SA Replacement (desc) 0
16. SA Insertion (reg) 0
17. SA Replacement (reg) 0
18. VLAN TX Insertion 0
19. SVLAN TX Insertion 0
20. L3 DA Filtering -95
21. L3 SA Filtering -95
22. L4 DA TCP Filtering -95
23. L4 SA TCP Filtering -95
24. L4 DA UDP Filtering -95
25. L4 SA UDP Filtering -95
26. ARP Offload 0
27. Jumbo Frame 0
28. Multichannel Jumbo 0
29. Split Header -95
---
Thanks,
Jose Miguel Abreu
_______________________________________________
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] ARM: dts: imx6dl: SolidRun: add phy node with 100Mb/s max-speed
From: Russell King - ARM Linux admin @ 2019-09-10 16:46 UTC (permalink / raw)
To: tinywrkb
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Shawn Guo, Sascha Hauer, open list, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190910155507.491230-1-tinywrkb@gmail.com>
On Tue, Sep 10, 2019 at 06:55:07PM +0300, tinywrkb wrote:
> Cubox-i Solo/DualLite carrier board has 100Mb/s magnetics while the
That statement is false, sorry. All boards support 1G.
> Atheros AR8035 PHY on the MicroSoM v1.3 CPU module is a 1GbE PHY device.
>
> Since commit 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in
> genphy_read_status") ethernet is broken on Cubox-i Solo/DualLite devices.
>
> This adds a phy node to the MicroSoM DTS and a 100Mb/s max-speed limit
> to the Cubox-i Solo/DualLite carrier DTS.
>
> Signed-off-by: tinywrkb <tinywrkb@gmail.com>
> ---
> This patch fixes ethernet on my Cubox-i2-300-D which is limited to 100Mb/s,
> afaik due to the carrier board magnetics, and was since commit 5502b218e001
> ("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")
>
> The AR8035 PHY on the CPU module reports to the driver as 1GbE capable
> via MII_BSMR's BMSR_ESTATEN status bit, the auto-negotiation sets the
> speed at 1GbE while the carrier board can't support it.
> Same behavior with the generic phy_device and the at803x drivers.
>
> While the PHY is on the CPU module board I added the max-speed limit to
> the cubox-i carrier DTS as I suspect that if the Solo or DualLite v1.3
> MicroSoM will be connected to a 1GbE capable carrier board then it would
> work correctly with 1GbE.
>
> I can confirm that this commit doesn't break networking on the my
> Cubox-i4Pro Quad (i4P-300-D) with it's 1GbE capable carrier board, and
> was tested separately with the generic phy_device and at803x drivers.
>
> arch/arm/boot/dts/imx6dl-cubox-i.dts | 4 ++++
> arch/arm/boot/dts/imx6qdl-sr-som.dtsi | 9 +++++++++
> 2 files changed, 13 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6dl-cubox-i.dts b/arch/arm/boot/dts/imx6dl-cubox-i.dts
> index 2b1b3e193f53..cfc82513c78c 100644
> --- a/arch/arm/boot/dts/imx6dl-cubox-i.dts
> +++ b/arch/arm/boot/dts/imx6dl-cubox-i.dts
> @@ -49,3 +49,7 @@
> model = "SolidRun Cubox-i Solo/DualLite";
> compatible = "solidrun,cubox-i/dl", "fsl,imx6dl";
> };
> +
> +ðphy {
> + max-speed = <100>;
> +};
> diff --git a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
> index 6d7f6b9035bc..969bc96c3f99 100644
> --- a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
> @@ -57,6 +57,15 @@
> phy-reset-duration = <2>;
> phy-reset-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>;
> status = "okay";
> + phy-handle = <ðphy>;
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + ethphy: ethernet-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
> + };
> + };
> };
>
> &iomuxc {
> --
> 2.23.0
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC] ARM: omap3: Enable HWMODS for HW Random Number Generator
From: Pali Rohár @ 2019-09-10 16:39 UTC (permalink / raw)
To: Adam Ford
Cc: Mark Rutland, devicetree, Paul Walmsley, Aaro Koskinen,
Tony Lindgren, Russell King, Linux Kernel Mailing List,
Tero Kristo, Rob Herring, Benoît Cousson, Linux-OMAP,
Adam Ford, arm-soc
In-Reply-To: <CAHCN7xLaGQMM67VC-2_G8XC7UuG4c+TbbYb4z=ibJwZsQF4YVw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1286 bytes --]
On Tuesday 10 September 2019 11:21:34 Adam Ford wrote:
> According to a note in omap_hwmod_3xxx_data.c,
>
> /*
> * Apparently the SHA/MD5 and AES accelerator IP blocks are
> * only present on some AM35xx chips, and no one knows which
> * ones. See
> * http://www.spinics.net/lists/arm-kernel/msg215466.html So
> * if you need these IP blocks on an AM35xx, try uncommenting
> * the following lines.
> */
>
> I decided to uncomment the hwmod entries, and I got the following:
>
> [ 0.263222] omap_hwmod: sham: _wait_target_ready failed: -16
> [ 0.263248] omap_hwmod: sham: cannot be enabled for reset (3)
> [ 0.265837] omap_hwmod: aes: _wait_target_ready failed: -16
> [ 0.265851] omap_hwmod: aes: cannot be enabled for reset (3)
> [ 6.208866] omap_hwmod: sham: _wait_target_ready failed: -16
> [ 6.287732] omap_hwmod: aes: _wait_target_ready failed: -16
Hi! Same errors I got in qemu-n900, but not on real N900. So I guess
those errors means that IP blocks are not present.
> Based on this, I wonder if the sham and aes modules are not present.
> If this is the case, it might explain why I cannot use the rng either.
Probably this is the reason, you do not have crypto/rng HW engine.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
From: David Hildenbrand @ 2019-09-10 16:22 UTC (permalink / raw)
To: Dr. David Alan Gilbert, Alexander Duyck
Cc: Yang Zhang, Pankaj Gupta, kvm list, Michael S. Tsirkin,
Catalin Marinas, Michal Hocko, linux-mm, Alexander Duyck, will,
Andrea Arcangeli, virtio-dev, Rik van Riel, Matthew Wilcox,
Wang, Wei W, ying.huang, Konrad Rzeszutek Wilk, Dan Williams,
lcapitulino, linux-arm-kernel, Oscar Salvador, Nitesh Narayan Lal,
Dave Hansen, LKML, Paolo Bonzini, Andrew Morton, Fengguang Wu,
Kirill A. Shutemov
In-Reply-To: <20190910161818.GF2797@work-vm>
On 10.09.19 18:18, Dr. David Alan Gilbert wrote:
> * Alexander Duyck (alexander.duyck@gmail.com) wrote:
>> On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <mhocko@kernel.org> wrote:
>>>
>>> On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
>>>> On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> wrote:
>>>>>
>>>>> I wanted to review "mm: Introduce Reported pages" just realize that I
>>>>> have no clue on what is going on so returned to the cover and it didn't
>>>>> really help much. I am completely unfamiliar with virtio so please bear
>>>>> with me.
>>>>>
>>>>> On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
>>>>> [...]
>>>>>> This series provides an asynchronous means of reporting to a hypervisor
>>>>>> that a guest page is no longer in use and can have the data associated
>>>>>> with it dropped. To do this I have implemented functionality that allows
>>>>>> for what I am referring to as unused page reporting
>>>>>>
>>>>>> The functionality for this is fairly simple. When enabled it will allocate
>>>>>> statistics to track the number of reported pages in a given free area.
>>>>>> When the number of free pages exceeds this value plus a high water value,
>>>>>> currently 32, it will begin performing page reporting which consists of
>>>>>> pulling pages off of free list and placing them into a scatter list. The
>>>>>> scatterlist is then given to the page reporting device and it will perform
>>>>>> the required action to make the pages "reported", in the case of
>>>>>> virtio-balloon this results in the pages being madvised as MADV_DONTNEED
>>>>>> and as such they are forced out of the guest. After this they are placed
>>>>>> back on the free list,
>>>>>
>>>>> And here I am reallly lost because "forced out of the guest" makes me
>>>>> feel that those pages are no longer usable by the guest. So how come you
>>>>> can add them back to the free list. I suspect understanding this part
>>>>> will allow me to understand why we have to mark those pages and prevent
>>>>> merging.
>>>>
>>>> Basically as the paragraph above mentions "forced out of the guest"
>>>> really is just the hypervisor calling MADV_DONTNEED on the page in
>>>> question. So the behavior is the same as any userspace application
>>>> that calls MADV_DONTNEED where the contents are no longer accessible
>>>> from userspace and attempting to access them will result in a fault
>>>> and the page being populated with a zero fill on-demand page, or a
>>>> copy of the file contents if the memory is file backed.
>>>
>>> As I've said I have no idea about virt so this doesn't really tell me
>>> much. Does that mean that if somebody allocates such a page and tries to
>>> access it then virt will handle a fault and bring it back?
>>
>> Actually I am probably describing too much as the MADV_DONTNEED is the
>> hypervisor behavior in response to the virtio-balloon notification. A
>> more thorough explanation of it can be found by just running "man
>> madvise", probably best just to leave it at that since I am probably
>> confusing things by describing hypervisor behavior in a kernel patch
>> set.
>>
>> For the most part all the page reporting really does is provide a way
>> to incrementally identify unused regions of memory in the buddy
>> allocator. That in turn is used by virtio-balloon in a polling thread
>> to report to the hypervisor what pages are not in use so that it can
>> make a decision on what to do with the pages now that it knows they
>> are unused.
>>
>> All this is providing is just a report and it is optional if the
>> hypervisor will act on it or not. If the hypervisor takes some sort of
>> action on the page, then the expectation is that the hypervisor will
>> use some sort of mechanism such as a page fault to discover when the
>> page is used again.
>
> OK, that's interestingly different (but OK) from some other schemes that
> hav ebeen described which *require* the guest to somehow indicate the
> page is in use before starting to use the page again.
>
virtio-balloon also has a mode where the guest would not have to
indicate to the host before re-using a page. Only
VIRTIO_BALLOON_F_MUST_TELL_HOST enforces this. So it's not completely new.
> Dave
--
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: [RFC] ARM: omap3: Enable HWMODS for HW Random Number Generator
From: Adam Ford @ 2019-09-10 16:21 UTC (permalink / raw)
To: Tony Lindgren
Cc: Mark Rutland, devicetree, Paul Walmsley, Aaro Koskinen,
Russell King, Linux Kernel Mailing List, Tero Kristo, Rob Herring,
Benoît Cousson, Pali Rohár, Linux-OMAP, Adam Ford,
arm-soc
In-Reply-To: <CAHCN7x+t-OVRE7pVM4V87_YMWpgO+_Vashfn1s5msoqC5eiwTg@mail.gmail.com>
On Tue, Sep 10, 2019 at 10:48 AM Adam Ford <aford173@gmail.com> wrote:
>
> On Mon, Sep 9, 2019 at 11:35 AM Tony Lindgren <tony@atomide.com> wrote:
> >
> > * Pali Rohár <pali.rohar@gmail.com> [190909 13:41]:
> > > On Monday 09 September 2019 08:37:09 Adam Ford wrote:
> > > > I applied this on 5.3 and it is working. I assume the same is true in for-next.
> >
> > Hmm I noticed I stopped getting RNG data after several rmmod modprobe
> > cycles, or several hd /dev/random reads. Anybody else seeing that?
> >
> > > > Do you want to submit a formal patch? I can mark it as 'tested-by'
> > > > This really helps speed up the startup sequence on boards with sshd
> > > > because it delays for nearly 80 seconds waiting for entropy without
> > > > the hwrng.
> > >
> > > Hi! When applying a patch, could you please disable this rng for n900?
> > >
> > > In omap3-n900.dts for rng should be status = "disabled" (as Tony already
> > > wrote), similarly like for aes.
> >
> > Yeah I'll post a proper patch after -rc1.
>
> FYI,
>
> By putting your node into omap34xx.dtsi and omap36xx.dtsi along with
> the following, I can get the RNG to work on an OMAP3530 and a DM3730.
>
>
> diff --git a/arch/arm/boot/dts/omap34xx-omap36xx-clocks.dtsi
> b/arch/arm/boot/dts/omap34xx-omap36xx-clocks.dtsi
> index 5e9d1afcd422..73f351e6d132 100644
> --- a/arch/arm/boot/dts/omap34xx-omap36xx-clocks.dtsi
> +++ b/arch/arm/boot/dts/omap34xx-omap36xx-clocks.dtsi
> @@ -259,7 +259,7 @@
> <&i2c1_ick>, <&uart2_ick>, <&uart1_ick>, <&gpt11_ick>,
> <&gpt10_ick>, <&mcbsp5_ick>, <&mcbsp1_ick>,
> <&omapctrl_ick>, <&aes2_ick>, <&sha12_ick>, <&icr_ick>,
> - <&des2_ick>, <&mspro_ick>, <&mailboxes_ick>,
> + <&des2_ick>, <&mspro_ick>, <&mailboxes_ick>,
> <&rng_ick>,
> <&mspro_fck>;
> };
> };
>
> I tried doing the same for am3517, but it doesn't appear to work. In
> fact, the board hangs at boot with no splat, so I assume that some
> clock isn't running and causing a hang. Figure 4-50 in the AM3517 TRM
> shows the security_l4_iclk2, so I wonder if the HW mods for AES, SHA,
> etc are doing something to enable this clock. Those HWmods are
> disabled on AM3517. I tried turning on the hwmods for them before
> without success, but I'll try it again.
According to a note in omap_hwmod_3xxx_data.c,
/*
* Apparently the SHA/MD5 and AES accelerator IP blocks are
* only present on some AM35xx chips, and no one knows which
* ones. See
* http://www.spinics.net/lists/arm-kernel/msg215466.html So
* if you need these IP blocks on an AM35xx, try uncommenting
* the following lines.
*/
I decided to uncomment the hwmod entries, and I got the following:
[ 0.263222] omap_hwmod: sham: _wait_target_ready failed: -16
[ 0.263248] omap_hwmod: sham: cannot be enabled for reset (3)
[ 0.265837] omap_hwmod: aes: _wait_target_ready failed: -16
[ 0.265851] omap_hwmod: aes: cannot be enabled for reset (3)
[ 6.208866] omap_hwmod: sham: _wait_target_ready failed: -16
[ 6.287732] omap_hwmod: aes: _wait_target_ready failed: -16
Based on this, I wonder if the sham and aes modules are not present.
If this is the case, it might explain why I cannot use the rng either.
adam
>
> adam
> >
> > Regards,
> >
> > Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
From: Dr. David Alan Gilbert @ 2019-09-10 16:18 UTC (permalink / raw)
To: Alexander Duyck
Cc: Yang Zhang, Pankaj Gupta, kvm list, David Hildenbrand,
Catalin Marinas, Michal Hocko, linux-mm, Alexander Duyck, will,
Andrea Arcangeli, virtio-dev, Michael S. Tsirkin, Matthew Wilcox,
Wang, Wei W, ying.huang, Rik van Riel, Dan Williams, lcapitulino,
linux-arm-kernel, Oscar Salvador, Nitesh Narayan Lal,
Konrad Rzeszutek Wilk, Dave Hansen, LKML, Paolo Bonzini,
Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <CAKgT0UdB4qp3vFGrYEs=FwSXKpBEQ7zo7DV55nJRO2C-KCEOrw@mail.gmail.com>
* Alexander Duyck (alexander.duyck@gmail.com) wrote:
> On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
> > > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> wrote:
> > > >
> > > > I wanted to review "mm: Introduce Reported pages" just realize that I
> > > > have no clue on what is going on so returned to the cover and it didn't
> > > > really help much. I am completely unfamiliar with virtio so please bear
> > > > with me.
> > > >
> > > > On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
> > > > [...]
> > > > > This series provides an asynchronous means of reporting to a hypervisor
> > > > > that a guest page is no longer in use and can have the data associated
> > > > > with it dropped. To do this I have implemented functionality that allows
> > > > > for what I am referring to as unused page reporting
> > > > >
> > > > > The functionality for this is fairly simple. When enabled it will allocate
> > > > > statistics to track the number of reported pages in a given free area.
> > > > > When the number of free pages exceeds this value plus a high water value,
> > > > > currently 32, it will begin performing page reporting which consists of
> > > > > pulling pages off of free list and placing them into a scatter list. The
> > > > > scatterlist is then given to the page reporting device and it will perform
> > > > > the required action to make the pages "reported", in the case of
> > > > > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > > > > and as such they are forced out of the guest. After this they are placed
> > > > > back on the free list,
> > > >
> > > > And here I am reallly lost because "forced out of the guest" makes me
> > > > feel that those pages are no longer usable by the guest. So how come you
> > > > can add them back to the free list. I suspect understanding this part
> > > > will allow me to understand why we have to mark those pages and prevent
> > > > merging.
> > >
> > > Basically as the paragraph above mentions "forced out of the guest"
> > > really is just the hypervisor calling MADV_DONTNEED on the page in
> > > question. So the behavior is the same as any userspace application
> > > that calls MADV_DONTNEED where the contents are no longer accessible
> > > from userspace and attempting to access them will result in a fault
> > > and the page being populated with a zero fill on-demand page, or a
> > > copy of the file contents if the memory is file backed.
> >
> > As I've said I have no idea about virt so this doesn't really tell me
> > much. Does that mean that if somebody allocates such a page and tries to
> > access it then virt will handle a fault and bring it back?
>
> Actually I am probably describing too much as the MADV_DONTNEED is the
> hypervisor behavior in response to the virtio-balloon notification. A
> more thorough explanation of it can be found by just running "man
> madvise", probably best just to leave it at that since I am probably
> confusing things by describing hypervisor behavior in a kernel patch
> set.
>
> For the most part all the page reporting really does is provide a way
> to incrementally identify unused regions of memory in the buddy
> allocator. That in turn is used by virtio-balloon in a polling thread
> to report to the hypervisor what pages are not in use so that it can
> make a decision on what to do with the pages now that it knows they
> are unused.
>
> All this is providing is just a report and it is optional if the
> hypervisor will act on it or not. If the hypervisor takes some sort of
> action on the page, then the expectation is that the hypervisor will
> use some sort of mechanism such as a page fault to discover when the
> page is used again.
OK, that's interestingly different (but OK) from some other schemes that
hav ebeen described which *require* the guest to somehow indicate the
page is in use before starting to use the page again.
Dave
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
_______________________________________________
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 V7 3/3] arm64/mm: Enable memory hot remove
From: Catalin Marinas @ 2019-09-10 16:17 UTC (permalink / raw)
To: Anshuman Khandual
Cc: mark.rutland, mhocko, david, linux-mm, arunks, cpandya, ira.weiny,
will, steven.price, valentin.schneider, suzuki.poulose,
Robin.Murphy, broonie, cai, ard.biesheuvel, dan.j.williams,
linux-arm-kernel, osalvador, steve.capper, logang, linux-kernel,
akpm, mgorman
In-Reply-To: <1567503958-25831-4-git-send-email-anshuman.khandual@arm.com>
On Tue, Sep 03, 2019 at 03:15:58PM +0530, Anshuman Khandual wrote:
> @@ -770,6 +1022,28 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
> void vmemmap_free(unsigned long start, unsigned long end,
> struct vmem_altmap *altmap)
> {
> +#ifdef CONFIG_MEMORY_HOTPLUG
> + /*
> + * FIXME: We should have called remove_pagetable(start, end, true).
> + * vmemmap and vmalloc virtual range might share intermediate kernel
> + * page table entries. Removing vmemmap range page table pages here
> + * can potentially conflict with a concurrent vmalloc() allocation.
> + *
> + * This is primarily because vmalloc() does not take init_mm ptl for
> + * the entire page table walk and it's modification. Instead it just
> + * takes the lock while allocating and installing page table pages
> + * via [p4d|pud|pmd|pte]_alloc(). A concurrently vanishing page table
> + * entry via memory hot remove can cause vmalloc() kernel page table
> + * walk pointers to be invalid on the fly which can cause corruption
> + * or worst, a crash.
> + *
> + * So free_empty_tables() gets called where vmalloc and vmemmap range
> + * do not overlap at any intermediate level kernel page table entry.
> + */
> + unmap_hotplug_range(start, end, true);
> + if (!vmalloc_vmemmap_overlap)
> + free_empty_tables(start, end);
> +#endif
> }
> #endif /* CONFIG_SPARSEMEM_VMEMMAP */
I wonder whether we could simply ignore the vmemmap freeing altogether,
just leave it around and not unmap it. This way, we could call
unmap_kernel_range() for removing the linear map and we save some code.
For the linear map, I think we use just above 2MB of tables for 1GB of
memory mapped (worst case with 4KB pages we need 512 pte pages). For
vmemmap we'd use slightly above 2MB for a 64GB hotplugged memory. Do we
expect such memory to be re-plugged again in the same range? If we do,
then I shouldn't even bother with removing the vmmemmap.
I don't fully understand the use-case for memory hotremove, so any
additional info would be useful to make a decision here.
--
Catalin
_______________________________________________
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] ARM: dts: imx6dl: SolidRun: add phy node with 100Mb/s max-speed
From: Baruch Siach @ 2019-09-10 16:17 UTC (permalink / raw)
To: tinywrkb
Cc: Mark Rutland, devicetree, Shawn Guo, Sascha Hauer, Russell King,
open list, Rob Herring, NXP Linux Team, Pengutronix Kernel Team,
Fabio Estevam, linux-arm-kernel
In-Reply-To: <20190910155507.491230-1-tinywrkb@gmail.com>
Hi tinywrkb,
On Tue, Sep 10, 2019 at 06:55:07PM +0300, tinywrkb wrote:
> Cubox-i Solo/DualLite carrier board has 100Mb/s magnetics while the
> Atheros AR8035 PHY on the MicroSoM v1.3 CPU module is a 1GbE PHY device.
According to the hardware designer, Rabeeh Khoury, there is not such
limitation in the Cubox-i carrier magnetics.
> Since commit 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in
> genphy_read_status") ethernet is broken on Cubox-i Solo/DualLite devices.
Does revert of 5502b218e001 fixes your issue?
> This adds a phy node to the MicroSoM DTS and a 100Mb/s max-speed limit
> to the Cubox-i Solo/DualLite carrier DTS.
>
> Signed-off-by: tinywrkb <tinywrkb@gmail.com>
You must use your real name in sign-off.
> ---
> This patch fixes ethernet on my Cubox-i2-300-D which is limited to 100Mb/s,
> afaik due to the carrier board magnetics, and was since commit 5502b218e001
> ("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")
>
> The AR8035 PHY on the CPU module reports to the driver as 1GbE capable
> via MII_BSMR's BMSR_ESTATEN status bit, the auto-negotiation sets the
> speed at 1GbE while the carrier board can't support it.
> Same behavior with the generic phy_device and the at803x drivers.
>
> While the PHY is on the CPU module board I added the max-speed limit to
> the cubox-i carrier DTS as I suspect that if the Solo or DualLite v1.3
> MicroSoM will be connected to a 1GbE capable carrier board then it would
> work correctly with 1GbE.
>
> I can confirm that this commit doesn't break networking on the my
> Cubox-i4Pro Quad (i4P-300-D) with it's 1GbE capable carrier board, and
> was tested separately with the generic phy_device and at803x drivers.
>
> arch/arm/boot/dts/imx6dl-cubox-i.dts | 4 ++++
> arch/arm/boot/dts/imx6qdl-sr-som.dtsi | 9 +++++++++
> 2 files changed, 13 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6dl-cubox-i.dts b/arch/arm/boot/dts/imx6dl-cubox-i.dts
> index 2b1b3e193f53..cfc82513c78c 100644
> --- a/arch/arm/boot/dts/imx6dl-cubox-i.dts
> +++ b/arch/arm/boot/dts/imx6dl-cubox-i.dts
> @@ -49,3 +49,7 @@
> model = "SolidRun Cubox-i Solo/DualLite";
> compatible = "solidrun,cubox-i/dl", "fsl,imx6dl";
> };
> +
> +ðphy {
> + max-speed = <100>;
> +};
Where is the ethphy lable defined? Have you build tested this patch?
> diff --git a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
> index 6d7f6b9035bc..969bc96c3f99 100644
> --- a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
> @@ -57,6 +57,15 @@
> phy-reset-duration = <2>;
> phy-reset-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>;
> status = "okay";
> + phy-handle = <ðphy>;
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + ethphy: ethernet-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
> + };
> + };
> };
>
> &iomuxc {
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
_______________________________________________
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] ARM: dts: imx6dl: SolidRun: add phy node with 100Mb/s max-speed
From: Fabio Estevam @ 2019-09-10 16:10 UTC (permalink / raw)
To: tinywrkb, Jon Nettleton, Baruch Siach
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Sascha Hauer, Russell King, open list, Rob Herring,
NXP Linux Team, Pengutronix Kernel Team, Shawn Guo,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190910155507.491230-1-tinywrkb@gmail.com>
Adding Jon and Baruch
On Tue, Sep 10, 2019 at 12:55 PM tinywrkb <tinywrkb@gmail.com> wrote:
>
> Cubox-i Solo/DualLite carrier board has 100Mb/s magnetics while the
> Atheros AR8035 PHY on the MicroSoM v1.3 CPU module is a 1GbE PHY device.
>
> Since commit 5502b218e001 ("net: phy: use phy_resolve_aneg_linkmode in
> genphy_read_status") ethernet is broken on Cubox-i Solo/DualLite devices.
>
> This adds a phy node to the MicroSoM DTS and a 100Mb/s max-speed limit
> to the Cubox-i Solo/DualLite carrier DTS.
>
> Signed-off-by: tinywrkb <tinywrkb@gmail.com>
> ---
> This patch fixes ethernet on my Cubox-i2-300-D which is limited to 100Mb/s,
> afaik due to the carrier board magnetics, and was since commit 5502b218e001
> ("net: phy: use phy_resolve_aneg_linkmode in genphy_read_status")
>
> The AR8035 PHY on the CPU module reports to the driver as 1GbE capable
> via MII_BSMR's BMSR_ESTATEN status bit, the auto-negotiation sets the
> speed at 1GbE while the carrier board can't support it.
> Same behavior with the generic phy_device and the at803x drivers.
>
> While the PHY is on the CPU module board I added the max-speed limit to
> the cubox-i carrier DTS as I suspect that if the Solo or DualLite v1.3
> MicroSoM will be connected to a 1GbE capable carrier board then it would
> work correctly with 1GbE.
>
> I can confirm that this commit doesn't break networking on the my
> Cubox-i4Pro Quad (i4P-300-D) with it's 1GbE capable carrier board, and
> was tested separately with the generic phy_device and at803x drivers.
>
> arch/arm/boot/dts/imx6dl-cubox-i.dts | 4 ++++
> arch/arm/boot/dts/imx6qdl-sr-som.dtsi | 9 +++++++++
> 2 files changed, 13 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6dl-cubox-i.dts b/arch/arm/boot/dts/imx6dl-cubox-i.dts
> index 2b1b3e193f53..cfc82513c78c 100644
> --- a/arch/arm/boot/dts/imx6dl-cubox-i.dts
> +++ b/arch/arm/boot/dts/imx6dl-cubox-i.dts
> @@ -49,3 +49,7 @@
> model = "SolidRun Cubox-i Solo/DualLite";
> compatible = "solidrun,cubox-i/dl", "fsl,imx6dl";
> };
> +
> +ðphy {
> + max-speed = <100>;
> +};
> diff --git a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
> index 6d7f6b9035bc..969bc96c3f99 100644
> --- a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi
> @@ -57,6 +57,15 @@
> phy-reset-duration = <2>;
> phy-reset-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>;
> status = "okay";
> + phy-handle = <ðphy>;
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + ethphy: ethernet-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <0>;
> + };
> + };
> };
>
> &iomuxc {
> --
> 2.23.0
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 5/5] soc: qcom: cmd-db: Map with read-only mappings
From: Stephen Boyd @ 2019-09-10 16:09 UTC (permalink / raw)
To: Dan Williams
Cc: devicetree, linux-arm-msm, Will Deacon, linux-kernel, Evan Green,
Bjorn Andersson, Rob Herring, Andy Gross, Catalin Marinas,
linux-arm-kernel
In-Reply-To: <20190910160903.65694-1-swboyd@chromium.org>
The command DB is read-only already to the kernel because everything is
const marked once we map it. Let's go one step further and try to map
the memory as read-only in the page tables. This should make it harder
for random code to corrupt the database and change the contents.
Cc: Evan Green <evgreen@chromium.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Andy Gross <agross@kernel.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
drivers/soc/qcom/cmd-db.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/qcom/cmd-db.c b/drivers/soc/qcom/cmd-db.c
index 10a34d26b753..6365e8260282 100644
--- a/drivers/soc/qcom/cmd-db.c
+++ b/drivers/soc/qcom/cmd-db.c
@@ -240,7 +240,8 @@ static int cmd_db_dev_probe(struct platform_device *pdev)
{
int ret = 0;
- cmd_db_header = devm_memremap_reserved_mem(&pdev->dev, MEMREMAP_WB);
+ cmd_db_header = devm_memremap_reserved_mem(&pdev->dev,
+ MEMREMAP_RO | MEMREMAP_WB);
if (IS_ERR(cmd_db_header)) {
ret = PTR_ERR(cmd_db_header);
cmd_db_header = NULL;
--
Sent by a computer through tubes
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 4/5] arm64: Add support for arch_memremap_ro()
From: Stephen Boyd @ 2019-09-10 16:09 UTC (permalink / raw)
To: Dan Williams
Cc: devicetree, linux-arm-msm, Will Deacon, linux-kernel, Evan Green,
Bjorn Andersson, Rob Herring, Andy Gross, Catalin Marinas,
linux-arm-kernel
In-Reply-To: <20190910160903.65694-1-swboyd@chromium.org>
Pass in PAGE_KERNEL_RO to the underlying IO mapping mechanism to get a
read-only mapping for the MEMREMAP_RO type of memory mappings that
memremap() supports.
Cc: Evan Green <evgreen@chromium.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Andy Gross <agross@kernel.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
arch/arm64/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 7ed92626949d..c623e75d9152 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -172,6 +172,7 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
#define ioremap_nocache(addr, size) __ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRE))
#define ioremap_wc(addr, size) __ioremap((addr), (size), __pgprot(PROT_NORMAL_NC))
#define ioremap_wt(addr, size) __ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRE))
+#define arch_memremap_ro(addr, size) __ioremap((addr), (size), PAGE_KERNEL_RO)
#define iounmap __iounmap
/*
--
Sent by a computer through tubes
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 3/5] memremap: Add support for read-only memory mappings
From: Stephen Boyd @ 2019-09-10 16:09 UTC (permalink / raw)
To: Dan Williams
Cc: devicetree, linux-arm-msm, Will Deacon, linux-kernel, Evan Green,
Bjorn Andersson, Rob Herring, Andy Gross, Catalin Marinas,
linux-arm-kernel
In-Reply-To: <20190910160903.65694-1-swboyd@chromium.org>
Sometimes we have memories that are supposed to be read-only, but when
we map these regions the best we can do is map them as write-back with
MEMREMAP_WB. Introduce a read-only memory mapping (MEMREMAP_RO) that
allows us to map reserved memory regions as read-only. This way, we're
less likely to see these special memory regions become corrupted by
stray writes to them.
Cc: Evan Green <evgreen@chromium.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Andy Gross <agross@kernel.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
include/linux/io.h | 1 +
kernel/iomem.c | 20 +++++++++++++++++---
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/include/linux/io.h b/include/linux/io.h
index accac822336a..15a63efcd153 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -148,6 +148,7 @@ enum {
MEMREMAP_WC = 1 << 2,
MEMREMAP_ENC = 1 << 3,
MEMREMAP_DEC = 1 << 4,
+ MEMREMAP_RO = 1 << 5,
};
void *memremap(resource_size_t offset, size_t size, unsigned long flags);
diff --git a/kernel/iomem.c b/kernel/iomem.c
index 62c92e43aa0d..6d76b7398714 100644
--- a/kernel/iomem.c
+++ b/kernel/iomem.c
@@ -19,6 +19,13 @@ static void *arch_memremap_wb(resource_size_t offset, unsigned long size)
}
#endif
+#ifndef arch_memremap_ro
+static void *arch_memremap_ro(resource_size_t offset, unsigned long size)
+{
+ return NULL;
+}
+#endif
+
#ifndef arch_memremap_can_ram_remap
static bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
unsigned long flags)
@@ -45,7 +52,7 @@ static void *try_ram_remap(resource_size_t offset, size_t size,
* @offset: iomem resource start address
* @size: size of remap
* @flags: any of MEMREMAP_WB, MEMREMAP_WT, MEMREMAP_WC,
- * MEMREMAP_ENC, MEMREMAP_DEC
+ * MEMREMAP_ENC, MEMREMAP_DEC, MEMREMAP_RO
*
* memremap() is "ioremap" for cases where it is known that the resource
* being mapped does not have i/o side effects and the __iomem
@@ -53,6 +60,9 @@ static void *try_ram_remap(resource_size_t offset, size_t size,
* mapping types will be attempted in the order listed below until one of
* them succeeds.
*
+ * MEMREMAP_RO - establish a mapping whereby writes are ignored/rejected.
+ * Attempts to map System RAM with this mapping type will fail.
+ *
* MEMREMAP_WB - matches the default mapping for System RAM on
* the architecture. This is usually a read-allocate write-back cache.
* Moreover, if MEMREMAP_WB is specified and the requested remap region is RAM
@@ -84,7 +94,10 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
}
/* Try all mapping types requested until one returns non-NULL */
- if (flags & MEMREMAP_WB) {
+ if ((flags & MEMREMAP_RO) && is_ram != REGION_INTERSECTS)
+ addr = arch_memremap_ro(offset, size);
+
+ if (!addr && (flags & MEMREMAP_WB)) {
/*
* MEMREMAP_WB is special in that it can be satisfied
* from the direct map. Some archs depend on the
@@ -103,7 +116,8 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
* address mapping. Enforce that this mapping is not aliasing
* System RAM.
*/
- if (!addr && is_ram == REGION_INTERSECTS && flags != MEMREMAP_WB) {
+ if (!addr && is_ram == REGION_INTERSECTS &&
+ (flags != MEMREMAP_WB || flags != MEMREMAP_RO)) {
WARN_ONCE(1, "memremap attempted on ram %pa size: %#lx\n",
&offset, (unsigned long) size);
return NULL;
--
Sent by a computer through tubes
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 2/5] soc: qcom: cmd-db: Migrate to devm_memremap_reserved_mem()
From: Stephen Boyd @ 2019-09-10 16:09 UTC (permalink / raw)
To: Dan Williams
Cc: devicetree, linux-arm-msm, Will Deacon, linux-kernel, Evan Green,
Bjorn Andersson, Rob Herring, Andy Gross, Catalin Marinas,
linux-arm-kernel
In-Reply-To: <20190910160903.65694-1-swboyd@chromium.org>
This gets rid of some duplicate code, and also makes the reserved memory
region show up as 'cmd-db' memory in /proc/iomem.
Cc: Evan Green <evgreen@chromium.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Andy Gross <agross@kernel.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
drivers/soc/qcom/cmd-db.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/soc/qcom/cmd-db.c b/drivers/soc/qcom/cmd-db.c
index f6c3d17b05c7..10a34d26b753 100644
--- a/drivers/soc/qcom/cmd-db.c
+++ b/drivers/soc/qcom/cmd-db.c
@@ -238,18 +238,11 @@ EXPORT_SYMBOL(cmd_db_read_slave_id);
static int cmd_db_dev_probe(struct platform_device *pdev)
{
- struct reserved_mem *rmem;
int ret = 0;
- rmem = of_reserved_mem_lookup(pdev->dev.of_node);
- if (!rmem) {
- dev_err(&pdev->dev, "failed to acquire memory region\n");
- return -EINVAL;
- }
-
- cmd_db_header = memremap(rmem->base, rmem->size, MEMREMAP_WB);
- if (!cmd_db_header) {
- ret = -ENOMEM;
+ cmd_db_header = devm_memremap_reserved_mem(&pdev->dev, MEMREMAP_WB);
+ if (IS_ERR(cmd_db_header)) {
+ ret = PTR_ERR(cmd_db_header);
cmd_db_header = NULL;
return ret;
}
--
Sent by a computer through tubes
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 1/5] reserved_mem: Add a devm_memremap_reserved_mem() API
From: Stephen Boyd @ 2019-09-10 16:08 UTC (permalink / raw)
To: Dan Williams
Cc: devicetree, Rob Herring, linux-arm-msm, Will Deacon, linux-kernel,
Evan Green, Bjorn Andersson, Rob Herring, Andy Gross,
Catalin Marinas, linux-arm-kernel
In-Reply-To: <20190910160903.65694-1-swboyd@chromium.org>
We have a few drivers that need to get a reserved memory region, request
the region, and map the reserved memory with memremap(). Add an API to
do this all in one function call.
Cc: Evan Green <evgreen@chromium.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Andy Gross <agross@kernel.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
drivers/of/of_reserved_mem.c | 45 +++++++++++++++++++++++++++++++++
include/linux/of_reserved_mem.h | 6 +++++
2 files changed, 51 insertions(+)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 7989703b883c..b3899a2c74c4 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -12,6 +12,7 @@
#define pr_fmt(fmt) "OF: reserved mem: " fmt
#include <linux/err.h>
+#include <linux/io.h>
#include <linux/of.h>
#include <linux/of_fdt.h>
#include <linux/of_platform.h>
@@ -410,3 +411,47 @@ struct reserved_mem *of_reserved_mem_lookup(struct device_node *np)
return NULL;
}
EXPORT_SYMBOL_GPL(of_reserved_mem_lookup);
+
+/**
+ * devm_memremap_reserved_mem() - acquire reserved_mem from a device node,
+ * request and memremap it
+ * @dev: device with node pointer of the desired reserved-memory region
+ * @flags: flags to pass to memremap()
+ *
+ * This function allows drivers to acquire a reference to the reserved_mem
+ * struct based on the device's device_node handle, request it and then
+ * memremap() it.
+ *
+ * Returns: A remapped reserved memory region, or an error pointer on failure.
+ */
+void *devm_memremap_reserved_mem(struct device *dev, unsigned long flags)
+{
+ void *dest_ptr;
+ struct reserved_mem *rmem;
+ struct resource *res;
+ const char *name;
+
+ rmem = of_reserved_mem_lookup(dev->of_node);
+ if (!rmem) {
+ dev_err(dev, "failed to acquire memory region\n");
+ return ERR_PTR(-ENODEV);
+ }
+
+ name = rmem->name ? : dev_name(dev);
+
+ res = devm_request_mem_region(dev, rmem->base, rmem->size, name);
+ if (!res) {
+ dev_err(dev, "can't request region for reserved memory\n");
+ return ERR_PTR(-EBUSY);
+ }
+
+ dest_ptr = devm_memremap(dev, rmem->base, rmem->size, flags);
+ if (!dest_ptr) {
+ dev_err(dev, "memremap failed for reserved memory\n");
+ devm_release_mem_region(dev, rmem->base, rmem->size);
+ dest_ptr = ERR_PTR(-ENOMEM);
+ }
+
+ return dest_ptr;
+}
+EXPORT_SYMBOL_GPL(devm_memremap_reserved_mem);
diff --git a/include/linux/of_reserved_mem.h b/include/linux/of_reserved_mem.h
index 60f541912ccf..a36be60ef67c 100644
--- a/include/linux/of_reserved_mem.h
+++ b/include/linux/of_reserved_mem.h
@@ -39,6 +39,7 @@ void fdt_init_reserved_mem(void);
void fdt_reserved_mem_save_node(unsigned long node, const char *uname,
phys_addr_t base, phys_addr_t size);
struct reserved_mem *of_reserved_mem_lookup(struct device_node *np);
+void *devm_memremap_reserved_mem(struct device *dev, unsigned long flags);
#else
static inline int of_reserved_mem_device_init_by_idx(struct device *dev,
struct device_node *np, int idx)
@@ -54,6 +55,11 @@ static inline struct reserved_mem *of_reserved_mem_lookup(struct device_node *np
{
return NULL;
}
+static inline void *devm_memremap_reserved_mem(struct device *dev,
+ unsigned long flags)
+{
+ return NULL;
+}
#endif
/**
--
Sent by a computer through tubes
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 0/5] Read-only memremap()
From: Stephen Boyd @ 2019-09-10 16:08 UTC (permalink / raw)
To: Dan Williams
Cc: devicetree, linux-arm-msm, Will Deacon, linux-kernel, Evan Green,
Bjorn Andersson, Rob Herring, Andy Gross, Catalin Marinas,
linux-arm-kernel
This patch series implements a read-only version of memremap() via
a new MEMREMAP_RO flag. If this is passed in the mapping call, we'll
try to map the memory region as read-only if it doesn't intersect
with an existing mapping. Otherwise, we'll try to fallback to other
flags to try to map the memory that way.
The main use case I have is to map the command-db memory region on
Qualcomm devices with a read-only mapping. It's already a const marked
pointer and the API returns const pointers as well, so this series makes
sure that even stray writes can't modify the memory. To get there we
introduce a devm version of memremap() for a reserved memory region, add
a memremap() flag, and implement support for that flag on arm64.
Changes from v2 (https://lkml.kernel.org/r/20190614203717.75479-1-swboyd@chromium.org):
* Added a comment to kerneldoc for the new MEMREMAP_RO flag
* Rebased to v5.3-rc1
Changes from v1:
* Picked up tags and rebased to v5.2-rc3
Stephen Boyd (5):
reserved_mem: Add a devm_memremap_reserved_mem() API
soc: qcom: cmd-db: Migrate to devm_memremap_reserved_mem()
memremap: Add support for read-only memory mappings
arm64: Add support for arch_memremap_ro()
soc: qcom: cmd-db: Map with read-only mappings
Cc: Evan Green <evgreen@chromium.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Andy Gross <agross@kernel.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
arch/arm64/include/asm/io.h | 1 +
drivers/of/of_reserved_mem.c | 45 +++++++++++++++++++++++++++++++++
drivers/soc/qcom/cmd-db.c | 14 +++-------
include/linux/io.h | 1 +
include/linux/of_reserved_mem.h | 6 +++++
kernel/iomem.c | 20 ++++++++++++---
6 files changed, 74 insertions(+), 13 deletions(-)
base-commit: 5f9e832c137075045d15cd6899ab0505cfb2ca4b
--
Sent by a computer through tubes
_______________________________________________
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: Alexander Duyck @ 2019-09-10 16:05 UTC (permalink / raw)
To: Michal Hocko
Cc: Yang Zhang, Pankaj Gupta, kvm list, David Hildenbrand,
Catalin Marinas, lcapitulino, linux-mm, Alexander Duyck, will,
Andrea Arcangeli, virtio-dev, Michael S. Tsirkin, Matthew Wilcox,
Wang, Wei W, ying.huang, Rik van Riel, 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: <20190910144713.GF2063@dhcp22.suse.cz>
On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <mhocko@kernel.org> wrote:
>
> On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
> > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> wrote:
> > >
> > > I wanted to review "mm: Introduce Reported pages" just realize that I
> > > have no clue on what is going on so returned to the cover and it didn't
> > > really help much. I am completely unfamiliar with virtio so please bear
> > > with me.
> > >
> > > On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
> > > [...]
> > > > This series provides an asynchronous means of reporting to a hypervisor
> > > > that a guest page is no longer in use and can have the data associated
> > > > with it dropped. To do this I have implemented functionality that allows
> > > > for what I am referring to as unused page reporting
> > > >
> > > > The functionality for this is fairly simple. When enabled it will allocate
> > > > statistics to track the number of reported pages in a given free area.
> > > > When the number of free pages exceeds this value plus a high water value,
> > > > currently 32, it will begin performing page reporting which consists of
> > > > pulling pages off of free list and placing them into a scatter list. The
> > > > scatterlist is then given to the page reporting device and it will perform
> > > > the required action to make the pages "reported", in the case of
> > > > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > > > and as such they are forced out of the guest. After this they are placed
> > > > back on the free list,
> > >
> > > And here I am reallly lost because "forced out of the guest" makes me
> > > feel that those pages are no longer usable by the guest. So how come you
> > > can add them back to the free list. I suspect understanding this part
> > > will allow me to understand why we have to mark those pages and prevent
> > > merging.
> >
> > Basically as the paragraph above mentions "forced out of the guest"
> > really is just the hypervisor calling MADV_DONTNEED on the page in
> > question. So the behavior is the same as any userspace application
> > that calls MADV_DONTNEED where the contents are no longer accessible
> > from userspace and attempting to access them will result in a fault
> > and the page being populated with a zero fill on-demand page, or a
> > copy of the file contents if the memory is file backed.
>
> As I've said I have no idea about virt so this doesn't really tell me
> much. Does that mean that if somebody allocates such a page and tries to
> access it then virt will handle a fault and bring it back?
Actually I am probably describing too much as the MADV_DONTNEED is the
hypervisor behavior in response to the virtio-balloon notification. A
more thorough explanation of it can be found by just running "man
madvise", probably best just to leave it at that since I am probably
confusing things by describing hypervisor behavior in a kernel patch
set.
For the most part all the page reporting really does is provide a way
to incrementally identify unused regions of memory in the buddy
allocator. That in turn is used by virtio-balloon in a polling thread
to report to the hypervisor what pages are not in use so that it can
make a decision on what to do with the pages now that it knows they
are unused.
All this is providing is just a report and it is optional if the
hypervisor will act on it or not. If the hypervisor takes some sort of
action on the page, then the expectation is that the hypervisor will
use some sort of mechanism such as a page fault to discover when the
page is used again.
_______________________________________________
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