Re: [PATCH] PCI: Add missing link delays required by the PCIe spec
Hi Bjorn, On Tue, Aug 27, 2019 at 12:25:47PM +0300, Mika Westerberg wrote: > Here are the relevant parts from ICL. I'll send you the full dmesg as > a separate email. The topology is such that I have 2 Titan Ridge devices > connected in chain (each include PCIe switch + xHCI). I wait for the > whole hierarchy to enter D3cold: Did you had time to check the log I sent you? Also how should we proceed with this patch? I can update it according to comments and send a new version after v5.4-rc1 is released. Of course unless you have better way we can fix this issue. Thanks!
Re: [PATCH v1 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding
Hi,
On 19/09/2019 08:55, Xin Ji wrote:
> The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> for portable device. It converts MIPI to DisplayPort 1.3 4K.
>
> You can add support to your board with binding.
>
> Example:
> anx_bridge: anx7625@58 {
> compatible = "analogix,anx7625";
> reg = <0x58>;
> anx,low_power_mode = <1>;
> anx,dsi_supported = <1>;
> anx,dsi_channel = <1>;
> anx,dsi_lanes = <4>;
> anx,internal_pannel = <1>;
> anx,p-on-gpio = <&gpio0 45 GPIO_ACTIVE_LOW>;
> anx,reset-gpio = <&gpio0 73 GPIO_ACTIVE_LOW>;
> status = "okay";
> port {
> anx7625_1_in: endpoint {
> remote-endpoint = <&mipi_dsi_bridge_1>;
> };
> };
> };
>
> Signed-off-by: Xin Ji
> ---
> .../devicetree/bindings/display/bridge/anx7625.txt | 42
> ++
> 1 file changed, 42 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/anx7625.txt
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/anx7625.txt
> b/Documentation/devicetree/bindings/display/bridge/anx7625.txt
> new file mode 100644
> index 000..f2a1c2a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/anx7625.txt
> @@ -0,0 +1,42 @@
> +Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
> +---
New bindings should use yaml format:
https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/example-schema.yaml
Neil
> +
> +The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
> +designed for portable devices.
> +
> +Required properties:
> +
> + - compatible: "analogix,anx7625"
> + - reg : I2C address of the device
> + - anx,low_power_mode: Low power mode support feature
> + - anx,dsi_supported : DSI or DPI
> + - anx,dsi_channel : DSI channel index
> + - anx,dsi_lanes : DSI lane count
> + - anx,intr-hpd-gpio : Which GPIO to use for interrupt
> +
> +Optional properties:
> +
> + - anx,extcon_supported
> + external connector interface support flag
> + - anx,internal_pannel
> + Which indicate internal pannel
> + - anx,p-on-gpio
> + Which GPIO to use for Power On chip
> + - anx,reset-gpio
> + Which GPIO to use for RESET
> + - port
> + SoC specific port nodes with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt,
> +
> +Example:
> +
> + anx_bridge: anx7625@58 {
> + compatible = "analogix,anx7625";
> + reg = <0x58>;
> + anx,low_power_mode = <0>;
> + anx,dsi_supported = <1>;
> + anx,dsi_channel = <1>;
> + anx,dsi_lanes = <4>;
> + anx,intr-hpd-gpio = <&gpio1 19 IRQ_TYPE_LEVEL_LOW>;
> + status = "okay";
> + };
>
Re: [PATCH v1 0/2] Add initial support for slimport anx7625
Hi, Please Cc dri-de...@lists.freedesktop.org Thanks, Neil On 19/09/2019 08:51, Xin Ji wrote: > Hi all, > > The following series add initial support for the Slimport ANX7625 > transmitter, a > ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable > device. > > This is the first version upload, any mistakes, please let me know, I will fix > it in the next series. > > Thanks, > Xin > > > Xin Ji (2): > dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding > drm/bridge: anx7625: Add anx7625 MIPI to DP bridge driver > > .../devicetree/bindings/display/bridge/anx7625.txt | 42 + > drivers/gpu/drm/bridge/Makefile|2 +- > drivers/gpu/drm/bridge/analogix/Kconfig|6 + > drivers/gpu/drm/bridge/analogix/Makefile |1 + > drivers/gpu/drm/bridge/analogix/anx7625.c | 2086 > > drivers/gpu/drm/bridge/analogix/anx7625.h | 397 > 6 files changed, 2533 insertions(+), 1 deletion(-) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/anx7625.txt > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h >
[PATCH v1 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding
The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
for portable device. It converts MIPI to DisplayPort 1.3 4K.
You can add support to your board with binding.
Example:
anx_bridge: anx7625@58 {
compatible = "analogix,anx7625";
reg = <0x58>;
anx,low_power_mode = <1>;
anx,dsi_supported = <1>;
anx,dsi_channel = <1>;
anx,dsi_lanes = <4>;
anx,internal_pannel = <1>;
anx,p-on-gpio = <&gpio0 45 GPIO_ACTIVE_LOW>;
anx,reset-gpio = <&gpio0 73 GPIO_ACTIVE_LOW>;
status = "okay";
port {
anx7625_1_in: endpoint {
remote-endpoint = <&mipi_dsi_bridge_1>;
};
};
};
Signed-off-by: Xin Ji
---
.../devicetree/bindings/display/bridge/anx7625.txt | 42 ++
1 file changed, 42 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/bridge/anx7625.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/anx7625.txt
b/Documentation/devicetree/bindings/display/bridge/anx7625.txt
new file mode 100644
index 000..f2a1c2a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/anx7625.txt
@@ -0,0 +1,42 @@
+Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
+---
+
+The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
+designed for portable devices.
+
+Required properties:
+
+ - compatible : "analogix,anx7625"
+ - reg : I2C address of the device
+ - anx,low_power_mode : Low power mode support feature
+ - anx,dsi_supported : DSI or DPI
+ - anx,dsi_channel : DSI channel index
+ - anx,dsi_lanes : DSI lane count
+ - anx,intr-hpd-gpio : Which GPIO to use for interrupt
+
+Optional properties:
+
+ - anx,extcon_supported
+ external connector interface support flag
+ - anx,internal_pannel
+ Which indicate internal pannel
+ - anx,p-on-gpio
+ Which GPIO to use for Power On chip
+ - anx,reset-gpio
+ Which GPIO to use for RESET
+ - port
+ SoC specific port nodes with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt,
+
+Example:
+
+ anx_bridge: anx7625@58 {
+ compatible = "analogix,anx7625";
+ reg = <0x58>;
+ anx,low_power_mode = <0>;
+ anx,dsi_supported = <1>;
+ anx,dsi_channel = <1>;
+ anx,dsi_lanes = <4>;
+ anx,intr-hpd-gpio = <&gpio1 19 IRQ_TYPE_LEVEL_LOW>;
+ status = "okay";
+ };
--
2.7.4
Re: [PATCH 1/4] seccomp: add SECCOMP_RET_USER_NOTIF_ALLOW
On Wed, Sep 18, 2019 at 12:07:12PM -0600, Tycho Andersen wrote:
> On Wed, Sep 18, 2019 at 10:30:00AM -0700, Kees Cook wrote:
> > On Wed, Sep 18, 2019 at 10:48:30AM +0200, Christian Brauner wrote:
> > > This allows the seccomp notifier to continue a syscall. A positive
> > > discussion about this feature was triggered by a post to the
> > > ksummit-discuss mailing list (cf. [3]) and took place during KSummit
> > > (cf. [1]) and again at the containers/checkpoint-restore
> > > micro-conference at Linux Plumbers.
> > >
> > > Recently we landed seccomp support for SECCOMP_RET_USER_NOTIF (cf. [4])
> > > which enables a process (watchee) to retrieve an fd for its seccomp
> > > filter. This fd can then be handed to another (usually more privileged)
> > > process (watcher). The watcher will then be able to receive seccomp
> > > messages about the syscalls having been performed by the watchee.
> > >
> > > This feature is heavily used in some userspace workloads. For example,
> > > it is currently used to intercept mknod() syscalls in user namespaces
> > > aka in containers.
> > > The mknod() syscall can be easily filtered based on dev_t. This allows
> > > us to only intercept a very specific subset of mknod() syscalls.
> > > Furthermore, mknod() is not possible in user namespaces toto coelo and
> > > so intercepting and denying syscalls that are not in the whitelist on
> > > accident is not a big deal. The watchee won't notice a difference.
> > >
> > > In contrast to mknod(), a lot of other syscall we intercept (e.g.
> > > setxattr()) cannot be easily filtered like mknod() because they have
> > > pointer arguments. Additionally, some of them might actually succeed in
> > > user namespaces (e.g. setxattr() for all "user.*" xattrs). Since we
> > > currently cannot tell seccomp to continue from a user notifier we are
> > > stuck with performing all of the syscalls in lieu of the container. This
> > > is a huge security liability since it is extremely difficult to
> > > correctly assume all of the necessary privileges of the calling task
> > > such that the syscall can be successfully emulated without escaping
> > > other additional security restrictions (think missing CAP_MKNOD for
> > > mknod(), or MS_NODEV on a filesystem etc.). This can be solved by
> > > telling seccomp to resume the syscall.
> > >
> > > One thing that came up in the discussion was the problem that another
> > > thread could change the memory after userspace has decided to let the
> > > syscall continue which is a well known TOCTOU with seccomp which is
> > > present in other ways already.
> > > The discussion showed that this feature is already very useful for any
> > > syscall without pointer arguments. For any accidentally intercepted
> > > non-pointer syscall it is safe to continue.
> > > For syscalls with pointer arguments there is a race but for any cautious
> > > userspace and the main usec cases the race doesn't matter. The notifier
> > > is intended to be used in a scenario where a more privileged watcher
> > > supervises the syscalls of lesser privileged watchee to allow it to get
> > > around kernel-enforced limitations by performing the syscall for it
> > > whenever deemed save by the watcher. Hence, if a user tricks the watcher
> > > into allowing a syscall they will either get a deny based on
> > > kernel-enforced restrictions later or they will have changed the
> > > arguments in such a way that they manage to perform a syscall with
> > > arguments that they would've been allowed to do anyway.
> > > In general, it is good to point out again, that the notifier fd was not
> > > intended to allow userspace to implement a security policy but rather to
> > > work around kernel security mechanisms in cases where the watcher knows
> > > that a given action is safe to perform.
> > >
> > > /* References */
> > > [1]: https://linuxplumbersconf.org/event/4/contributions/560
> > > [2]: https://linuxplumbersconf.org/event/4/contributions/477
> > > [3]: https://lore.kernel.org/r/20190719093538.dhyopljyr5ns3...@brauner.io
> > > [4]: commit 6a21cc50f0c7 ("seccomp: add a return code to trap to
> > > userspace")
> > >
> > > Signed-off-by: Christian Brauner
> > > Cc: Kees Cook
> > > Cc: Andy Lutomirski
> > > Cc: Will Drewry
> > > Cc: Tycho Andersen
> > > CC: Tyler Hicks
> > > Cc: Jann Horn
> > > ---
> > > include/uapi/linux/seccomp.h | 2 ++
> > > kernel/seccomp.c | 24
> > > 2 files changed, 22 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h
> > > index 90734aa5aa36..2c23b9aa6383 100644
> > > --- a/include/uapi/linux/seccomp.h
> > > +++ b/include/uapi/linux/seccomp.h
> > > @@ -76,6 +76,8 @@ struct seccomp_notif {
> > > struct seccomp_data data;
> > > };
> > >
> > > +#define SECCOMP_RET_USER_NOTIF_ALLOW 0x0001
> >
> > nit: I'd like to avoid confusion here about what "family" these flags
> > belong to. "SECCOMP_RET_..." is
Re: [PATCH 1/4] seccomp: add SECCOMP_RET_USER_NOTIF_ALLOW
On Wed, Sep 18, 2019 at 10:30:00AM -0700, Kees Cook wrote:
> On Wed, Sep 18, 2019 at 10:48:30AM +0200, Christian Brauner wrote:
> > This allows the seccomp notifier to continue a syscall. A positive
> > discussion about this feature was triggered by a post to the
> > ksummit-discuss mailing list (cf. [3]) and took place during KSummit
> > (cf. [1]) and again at the containers/checkpoint-restore
> > micro-conference at Linux Plumbers.
> >
> > Recently we landed seccomp support for SECCOMP_RET_USER_NOTIF (cf. [4])
> > which enables a process (watchee) to retrieve an fd for its seccomp
> > filter. This fd can then be handed to another (usually more privileged)
> > process (watcher). The watcher will then be able to receive seccomp
> > messages about the syscalls having been performed by the watchee.
> >
> > This feature is heavily used in some userspace workloads. For example,
> > it is currently used to intercept mknod() syscalls in user namespaces
> > aka in containers.
> > The mknod() syscall can be easily filtered based on dev_t. This allows
> > us to only intercept a very specific subset of mknod() syscalls.
> > Furthermore, mknod() is not possible in user namespaces toto coelo and
> > so intercepting and denying syscalls that are not in the whitelist on
> > accident is not a big deal. The watchee won't notice a difference.
> >
> > In contrast to mknod(), a lot of other syscall we intercept (e.g.
> > setxattr()) cannot be easily filtered like mknod() because they have
> > pointer arguments. Additionally, some of them might actually succeed in
> > user namespaces (e.g. setxattr() for all "user.*" xattrs). Since we
> > currently cannot tell seccomp to continue from a user notifier we are
> > stuck with performing all of the syscalls in lieu of the container. This
> > is a huge security liability since it is extremely difficult to
> > correctly assume all of the necessary privileges of the calling task
> > such that the syscall can be successfully emulated without escaping
> > other additional security restrictions (think missing CAP_MKNOD for
> > mknod(), or MS_NODEV on a filesystem etc.). This can be solved by
> > telling seccomp to resume the syscall.
> >
> > One thing that came up in the discussion was the problem that another
> > thread could change the memory after userspace has decided to let the
> > syscall continue which is a well known TOCTOU with seccomp which is
> > present in other ways already.
> > The discussion showed that this feature is already very useful for any
> > syscall without pointer arguments. For any accidentally intercepted
> > non-pointer syscall it is safe to continue.
> > For syscalls with pointer arguments there is a race but for any cautious
> > userspace and the main usec cases the race doesn't matter. The notifier
> > is intended to be used in a scenario where a more privileged watcher
> > supervises the syscalls of lesser privileged watchee to allow it to get
> > around kernel-enforced limitations by performing the syscall for it
> > whenever deemed save by the watcher. Hence, if a user tricks the watcher
> > into allowing a syscall they will either get a deny based on
> > kernel-enforced restrictions later or they will have changed the
> > arguments in such a way that they manage to perform a syscall with
> > arguments that they would've been allowed to do anyway.
> > In general, it is good to point out again, that the notifier fd was not
> > intended to allow userspace to implement a security policy but rather to
> > work around kernel security mechanisms in cases where the watcher knows
> > that a given action is safe to perform.
> >
> > /* References */
> > [1]: https://linuxplumbersconf.org/event/4/contributions/560
> > [2]: https://linuxplumbersconf.org/event/4/contributions/477
> > [3]: https://lore.kernel.org/r/20190719093538.dhyopljyr5ns3...@brauner.io
> > [4]: commit 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace")
> >
> > Signed-off-by: Christian Brauner
> > Cc: Kees Cook
> > Cc: Andy Lutomirski
> > Cc: Will Drewry
> > Cc: Tycho Andersen
> > CC: Tyler Hicks
> > Cc: Jann Horn
> > ---
> > include/uapi/linux/seccomp.h | 2 ++
> > kernel/seccomp.c | 24
> > 2 files changed, 22 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h
> > index 90734aa5aa36..2c23b9aa6383 100644
> > --- a/include/uapi/linux/seccomp.h
> > +++ b/include/uapi/linux/seccomp.h
> > @@ -76,6 +76,8 @@ struct seccomp_notif {
> > struct seccomp_data data;
> > };
> >
> > +#define SECCOMP_RET_USER_NOTIF_ALLOW 0x0001
>
> nit: I'd like to avoid confusion here about what "family" these flags
> belong to. "SECCOMP_RET_..." is used for the cBPF filter return action
> value, so let's instead call this:
>
> #define SECCOMP_USER_NOTIF_CONTINUE BIT(0)
Ack.
>
> I'm thinking of "continue" as slightly different from "allow", in the
> sense that I'd like to hint that th
Re: [PATCH] iio: imu: adis16400: fix memory leak
On Wed, 2019-09-18 at 12:03 -0500, Navid Emamdoost wrote:
> [External]
>
Hey,
Thanks for this patch as well.
Comments inline here as well.
> In adis_update_scan_mode_burst, if adis->buffer allocation fails release
> the adis->xfer.
>
> Signed-off-by: Navid Emamdoost
> ---
> drivers/iio/imu/adis_buffer.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/imu/adis_buffer.c
> b/drivers/iio/imu/adis_buffer.c
> index 9ac8356d9a95..1dbe25572a39 100644
> --- a/drivers/iio/imu/adis_buffer.c
> +++ b/drivers/iio/imu/adis_buffer.c
> @@ -35,8 +35,10 @@ static int adis_update_scan_mode_burst(struct iio_dev
> *indio_dev,
> return -ENOMEM;
>
> adis->buffer = kzalloc(burst_length + sizeof(u16), GFP_KERNEL);
> - if (!adis->buffer)
> + if (!adis->buffer) {
> + kfree(adis->xfer);
Same as the other patch: it would be a good idea to do "adis->xfer = NULL"
here.
> return -ENOMEM;
> + }
>
> tx = adis->buffer + burst_length;
> tx[0] = ADIS_READ_REG(adis->burst->reg_cmd);
Re: [PATCH] iio: imu: adis16400: release allocated memory on failure
On Wed, 2019-09-18 at 11:57 -0500, Navid Emamdoost wrote:
> [External]
>
Hey,
Good catch.
One comment inline.
> In adis_update_scan_mode, if allocation for adis->buffer fails,
> previously allocated adis->xfer needs to be released.
>
> Signed-off-by: Navid Emamdoost
> ---
> drivers/iio/imu/adis_buffer.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/imu/adis_buffer.c
> b/drivers/iio/imu/adis_buffer.c
> index 9ac8356d9a95..c5d7e368a636 100644
> --- a/drivers/iio/imu/adis_buffer.c
> +++ b/drivers/iio/imu/adis_buffer.c
> @@ -78,8 +78,10 @@ int adis_update_scan_mode(struct iio_dev *indio_dev,
> return -ENOMEM;
>
> adis->buffer = kcalloc(indio_dev->scan_bytes, 2, GFP_KERNEL);
> - if (!adis->buffer)
> + if (!adis->buffer) {
> + kfree(adis->xfer);
Maybe also do "adis->xfer = NULL" here.
The idea is to make sure that the pointer is not double-free'd by some
other function (i.e. adis_cleanup_buffer_and_trigger() or another
adis_update_scan_mode() call).
> return -ENOMEM;
> + }
>
> rx = adis->buffer;
> tx = rx + scan_count;
[PATCH v1 0/2] Add initial support for slimport anx7625
Hi all, The following series add initial support for the Slimport ANX7625 transmitter, a ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable device. This is the first version upload, any mistakes, please let me know, I will fix it in the next series. Thanks, Xin Xin Ji (2): dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding drm/bridge: anx7625: Add anx7625 MIPI to DP bridge driver .../devicetree/bindings/display/bridge/anx7625.txt | 42 + drivers/gpu/drm/bridge/Makefile|2 +- drivers/gpu/drm/bridge/analogix/Kconfig|6 + drivers/gpu/drm/bridge/analogix/Makefile |1 + drivers/gpu/drm/bridge/analogix/anx7625.c | 2086 drivers/gpu/drm/bridge/analogix/anx7625.h | 397 6 files changed, 2533 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/anx7625.txt create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h -- 2.7.4
Re: [PATCH v2 3/3] dt-bindings: ddr: Add bindings for Samsung LPDDR3 memories
Hi Krzysztof, On 9/18/19 8:51 PM, Krzysztof Kozlowski wrote: > On Mon, 16 Sep 2019 at 12:07, Lukasz Luba wrote: >> >> Add compatible for Samsung k3qf2f20db LPDDR3 memory bindings. >> Introduce minor fixes in the old documentation. >> >> Signed-off-by: Lukasz Luba >> --- >> Documentation/devicetree/bindings/ddr/lpddr3.txt | 9 ++--- >> 1 file changed, 6 insertions(+), 3 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/ddr/lpddr3.txt >> b/Documentation/devicetree/bindings/ddr/lpddr3.txt >> index 3b2485b84b3f..49afe794daaa 100644 >> --- a/Documentation/devicetree/bindings/ddr/lpddr3.txt >> +++ b/Documentation/devicetree/bindings/ddr/lpddr3.txt >> @@ -1,7 +1,9 @@ >> * LPDDR3 SDRAM memories compliant to JEDEC JESD209-3C >> >> Required properties: >> -- compatible : Should be - "jedec,lpddr3" >> +- compatible : should be one of the following: >> + Generic default - "jedec,lpddr3". > > The convention is first compatible, then description. I gave you the > example to base on - at25. Why making it different? I have checked at25 that you pointed me to and also checked at24, which has a bit longer "compatible" section. I found that there are many "jedec,spi-nor" compatible devices, which I thought would be a better example for my "jedec,lpddr3". For example, two configurations, where you have a single labels or dual (with specific device) arch/arm/boot/dts/imx6dl-rex-basic.dts: compatible = "sst,sst25vf016b", "jedec,spi-nor"; arch/arm/boot/dts/imx6q-ba16.dtsi: compatible = "jedec,spi-nor"; The 'compatible' in documentation for the "jedec,spi-nor" is slightly different (similar to at24). Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt It has a long explanation, which is also OK. So I thought that it is quite flexible what you put in there. I have also checked Cadance QSPI controller. Documentation/devicetree/bindings/mtd/cadence-quadspi.txt The controller might be built-in into different vendor SoC's and the "compatible" is ready to reflect it in similar fashion but with a short explanation in this section. Therefore, what you see in the patch draw heavily on Cadence's qspi, with a bit of inspiration from jedec,spi-nor usage. Should I change it to at25 "compatible" style and send next patch? PS. Thank you for taking the other two patches. I will not respond in their threads to keep the traffic low. Regards, Lukasz
Re: [PATCH] PCI: Use minimum window alignment when calculating memory window size
On Mon, Aug 12, 2019 at 05:41:44PM +0300, Mika Westerberg wrote: > There is an issue in Linux PCI resource allocation that if we remove an > existing device that was initially configured by the BIOS and then issue > rescan, it will not fit in to the memory space allocated by the BIOS > even if it originally it fit there just fine. Any comments on this?
Re: [PATCH 2/9] perf/core: Add PERF_SAMPLE_CGROUP feature
On Mon, Sep 16, 2019 at 4:23 PM Tejun Heo wrote: > > Hello, Song. > > On Sat, Sep 14, 2019 at 03:02:51PM +0100, Song Liu wrote: > > I think we don't need a perfect identifier in this case. IIUC, the goal of > > I really don't want different versions of imperfect identifiers > proliferating. > > > this patchset is to map each sample with a cgroup name (or full path). > > To achieve this, we need > > > > 1. PERF_RECORD_CGROUP, that maps > >"64-bit number" => cgroup name/path > > 2. PERF_SAMPLE_CGROUP, that adds "64-bit number" to each sample. > > > > I call the id a "64-bit number" because it is not required to be a globally > > unique id. As long as it is consistent within the same perf-record session, > > we won't get any confusion. Since we add PERF_RECORD_CGROUP > > for each cgroup creation, we will map most of samples correctly even > > when the "64-bit number" is recycled within the same perf-record session. > > > > At the moment, I think ino is good enough for the "64-bit number" even > > for 32-bit systems. If we don't call it "ino" (just call it "cgroup_tag" or > > "cgroup_id", we can change it when kernfs provides a better 64-bit id. > > So, a firm nack on this direction. > > > About full path name: The user names the full path here. If the user gives > > two different workloads the same name/path, we really cannot change that. > > Reasonable users would be able to make sense from the full path. > > I don't see why we wanna be causing this avoidable problem to users. Sharing some offline discussions with Tejun. ino in current kernfs is not a good unique ID for cgroup, because it doesn't increase monotonically. So we need to improve kernfs. For 64-bit, we can make the ino monotonic, and use it as the ID. For 32-bit, we need to make the ino monotonic. and use and as the 64-bit ID. Thanks, Song
Re: [PATCH v2 1/2] PCI: pciehp: Do not disable interrupt twice on suspend
On Mon, Aug 12, 2019 at 05:31:32PM +0300, Mika Westerberg wrote:
> We try to keep PCIe hotplug ports runtime suspended when entering system
> suspend. Due to the fact that the PCIe portdrv sets NEVER_SKIP driver PM
> flag the PM core always calls system suspend/resume hooks even if the
> device is left runtime suspended. Since PCIe hotplug driver re-uses the
> same function for both it ends up disabling hotplug interrupt twice and
> the second time following is printed:
>
> pciehp :03:01.0:pcie204: pcie_do_write_cmd: no response from device
>
> Prevent this from happening by checking whether the device is already
> runtime suspended when system suspend hook is called.
>
> Fixes: 9c62f0bfb832 ("PCI: pciehp: Implement runtime PM callbacks")
> Reported-by: Kai-Heng Feng
> Tested-by: Kai-Heng Feng
> Signed-off-by: Mika Westerberg
> Reviewed-by: Rafael J. Wysocki
Hi Bjorn,
Any comments on these two?
Re: [PATCH v2] clk: imx7ulp: remove IMX7ULP_CLK_MIPI_PLL clock
Hi Fancy, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.3 next-20190918] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Fancy-Fang/clk-imx7ulp-remove-IMX7ULP_CLK_MIPI_PLL-clock/20190919-111243 config: arm-allmodconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (GCC) 7.4.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.4.0 make.cross ARCH=arm If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): >> Error: arch/arm/boot/dts/imx7ulp.dtsi:279.13-14 syntax error FATAL ERROR: Unable to parse input tree --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [GIT PULL afs: Development for 5.4
Linus Torvalds wrote: > However, I was close to unpulling it again. It has a merge commit with > this merge message: > > Merge remote-tracking branch 'net/master' into afs-next > > and that simply is not acceptable. Apologies - I meant to rebase that away. There was a bug fix to rxrpc in net/master that didn't get pulled into your tree until Saturday. David
[PATCH] fixed-regulator: dt-bindings: Fixed building error for compatible property
Compatible property is not of type 'string', so remove const: from it. Signed-off-by: Pragnesh Patel --- Documentation/devicetree/bindings/regulator/fixed-regulator.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml index a78150c..f324169 100644 --- a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml @@ -30,8 +30,8 @@ if: properties: compatible: enum: - - const: regulator-fixed - - const: regulator-fixed-clock + - regulator-fixed + - regulator-fixed-clock regulator-name: true -- 2.7.4
Re: [PATCH 5.2 00/85] 5.2.16-stable review
On Wed, Sep 18, 2019 at 05:28:49PM +0100, Jon Hunter wrote: > > On 18/09/2019 07:18, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.2.16 release. > > There are 85 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Fri 20 Sep 2019 06:09:47 AM UTC. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.16-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.2.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > All tests are passing for Tegra ... > > Test results for stable-v5.2: > 12 builds:12 pass, 0 fail > 22 boots: 22 pass, 0 fail > 38 tests: 38 pass, 0 fail > > Linux version:5.2.16-rc1-g2f63f02ef506 > Boards tested:tegra124-jetson-tk1, tegra186-p2771-, > tegra194-p2972-, tegra20-ventana, > tegra210-p2371-2180, tegra30-cardhu-a04 Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH 4.19 00/50] 4.19.74-stable review
On Wed, Sep 18, 2019 at 12:37:49PM -0700, Guenter Roeck wrote: > On Wed, Sep 18, 2019 at 08:18:43AM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.19.74 release. > > There are 50 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Fri 20 Sep 2019 06:09:47 AM UTC. > > Anything received after that time might be too late. > > > > For v4.19.73-51-g7290521ed4bd: > > Build results: > total: 156 pass: 156 fail: 0 > Qemu test results: > total: 390 pass: 390 fail: 0 Great, glad that got fixed up. Thanks for testing all of these. greg k-h
Re: [PATCH 5.2 00/85] 5.2.16-stable review
On Wed, Sep 18, 2019 at 08:47:06PM +0530, Naresh Kamboju wrote: > On Wed, 18 Sep 2019 at 11:56, Greg Kroah-Hartman > wrote: > > > > This is the start of the stable review cycle for the 5.2.16 release. > > There are 85 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Fri 20 Sep 2019 06:09:47 AM UTC. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.16-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.2.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Results from Linaro’s test farm. > No regressions on arm64, arm, x86_64, and i386. Great, thanks for testing all of these and letting me know. greg k-h
Re: [PATCH v4 1/3] kernel/notifier.c: intercepting duplicate registrations to avoid infinite loops
On Thu, Sep 19, 2019 at 10:58:06AM +0800, Xiaoming Ni wrote: > Registering the same notifier to a hook repeatedly can cause the hook > list to form a ring or lose other members of the list. > > case1: An infinite loop in notifier_chain_register() can cause soft lockup > atomic_notifier_chain_register(&test_notifier_list, &test1); > atomic_notifier_chain_register(&test_notifier_list, &test1); > atomic_notifier_chain_register(&test_notifier_list, &test2); > > case2: An infinite loop in notifier_chain_register() can cause soft lockup > atomic_notifier_chain_register(&test_notifier_list, &test1); > atomic_notifier_chain_register(&test_notifier_list, &test1); > atomic_notifier_call_chain(&test_notifier_list, 0, NULL); > > case3: lose other hook test2 > atomic_notifier_chain_register(&test_notifier_list, &test1); > atomic_notifier_chain_register(&test_notifier_list, &test2); > atomic_notifier_chain_register(&test_notifier_list, &test1); > > case4: Unregister returns 0, but the hook is still in the linked list, > and it is not really registered. If you call notifier_call_chain > after ko is unloaded, it will trigger oops. > > If the system is configured with softlockup_panic and the same > hook is repeatedly registered on the panic_notifier_list, it > will cause a loop panic. > > Add a check in notifier_chain_register(), > Intercepting duplicate registrations to avoid infinite loops > > Signed-off-by: Xiaoming Ni > Reviewed-by: Vasily Averin > --- > kernel/notifier.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly. Same thing goes for all of the patches in this series. thanks, greg k-h
Re: [PATCH 5.2 00/85] 5.2.16-stable review
On Wed, Sep 18, 2019 at 07:22:50PM -0600, shuah wrote: > On 9/18/19 12:18 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.2.16 release. > > There are 85 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Fri 20 Sep 2019 06:09:47 AM UTC. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.16-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.2.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. Thanks for testing all of these and letting me know. greg k-h
RE: [PATCH 1/3] hv_utils: Add the support of hibernation
> From: Vitaly Kuznetsov
> Sent: Monday, September 16, 2019 1:46 AM
> Dexuan Cui writes:
>
> >> From: Vitaly Kuznetsov
> >> Sent: Thursday, September 12, 2019 9:37 AM
> >
> >> > +static int util_suspend(struct hv_device *dev)
> >> > +{
> >> > +struct hv_util_service *srv = hv_get_drvdata(dev);
> >> > +
> >> > +if (srv->util_cancel_work)
> >> > +srv->util_cancel_work();
> >> > +
> >> > +vmbus_close(dev->channel);
> >>
> >> And what happens if you receive a real reply from userspace after you
> >> close the channel? You've only cancelled timeout work so the driver
> >> will not try to reply by itself but this doesn't mean we won't try to
> >> write to the channel on legitimate replies from daemons.
> >>
> >> I think you need to block all userspace requests (hang in kernel until
> >> util_resume()).
> >>
> >> While I'm not sure we can't get away without it but I'd suggest we add a
> >> new HVUTIL_SUSPENDED state to the hvutil state machine.
> >> Vitaly
> >
> > When we reach util_suspend(), all the userspace processes have been
> > frozen: see kernel/power/hibernate.c: hibernate() -> freeze_processes(),
> > so here we can not receive a reply from the userspace daemon.
> >
>
> Let's add a WARN() or something then as if this ever happens this is
> going to be realy tricky to catch.
Looking at the path hibernate() -> freeze_processes() ->
try_to_freeze_tasks(true) -> freeze_task() -> fake_signal_wake_up(), I'm
sure when try_to_freeze_tasks(true) returns 0, all the user-space processes
must be frozen in do_signal() -> get_signal() -> try_to_freeze() -> ... ->
__refrigerator().
hibernate () -> hibernation_snapshot () -> dpm_suspend() -> ... ->
util_suspend() only runs after hibernate() -> freeze_processes(), so I'm
pretty sure we're safe here.
> > However, it looks there is indeed some tricky corner cases we need to deal
> > with: in util_resume(), before we call vmbus_open(), all the userspace
> > processes are still frozen, and the userspace daemon (e.g. hv_kvp_daemon)
> > can be in any of these states:
> >
> > 1. the driver has not buffered any message for the daemon. This is good.
> >
> > 2. the driver has buffered a message for the daemon, and
> > kvp_transaction.state is HVUTIL_USERSPACE_REQ. Later, the kvp daemon
> > writes the response to the driver, and in kvp_on_msg()
> > kvp_transaction.state is moved to HVUTIL_USERSPACE_RECV, but since
> > cancel_delayed_work_sync(&kvp_timeout_work) is false (the work has
> > been cancelled by util_suspend()), the driver reports nothing to the host,
> > which is good as the VM has undergone a hibernation event and IMO the
> > response may be stale and I believe the host is not expecting this
> > response from the VM at all (the host side application that requested the
> > KVP must have failed or timed out), but the bad thing is: the "state"
> > remains in HVUTIL_USERSPACE_RECV, preventing
> > hv_kvp_onchannelcallback() from reading from the channel ringbuffer.
> >
> > I suggest we work around this race condition by the below patch:
> >
> > --- a/drivers/hv/hv_kvp.c
> > +++ b/drivers/hv/hv_kvp.c
> > @@ -250,8 +250,8 @@ static int kvp_on_msg(void *msg, int len)
> > */
> > if (cancel_delayed_work_sync(&kvp_timeout_work)) {
> > kvp_respond_to_host(message, error);
> > - hv_poll_channel(kvp_transaction.recv_channel,
> kvp_poll_wrapper);
> > }
> > + hv_poll_channel(kvp_transaction.recv_channel, kvp_poll_wrapper);
> >
> > return 0;
> > }
> >
> > How do you like this?
> >
>
> Is it safe to call hv_poll_channel() simultaneously on several CPUs? It
> seems it is as we're doing
>
> smp_call_function_single(channel->target_cpu, cb, channel, true);
Looks safe to me. The code has been there for years. :-)
> (I'm asking because if it's not, than doing what you suggest will open
> the following window: timeout function kvp_timeout_func() is already
> running but the daemon is trying to reply at the same moment).
>
> > I can imagine there is still a small chance that the state machine can run
> > out of order, and the kvp daemon may exit due to the return values of
> > read()/write() being -EINVAL, but the chance should be small enough in
> > practice, and IMO the issue even exists in the current code when
> > hibernation is not involved, e.g. kvp_timeout_func() and kvp_on_msg()
> > can run concurrently; if kvp_on_msg() runs slowly due to some reason
> > (e.g. the kvp daemon is stopped as I'm gdb'ing it), kvp_timeout_func()
> > fires and moves the state to HVUTIL_READY; later kvp_on_msg() starts
> > to run and returns -EINVAL, and the kvp daemon will exit().
> >
> > IMHO here it looks extremely difficult to make things flawless (if that's
> > even possible), so it's necessary to ask the daemons to auto-restart once
> > they exit() unexpectedly. This can be achieved by configuring systemd
> > properly for the kvp/vss/fcopy services.
>
> I think we can also teach
Re: [PATCH v2 1/2] edac: Add an API for edac device to report for multiple errors
On 12.09.19 15:53:04, Hanna Hawa wrote:
> Add an API for EDAC device to report multiple errors with same type.
>
> Signed-off-by: Hanna Hawa
> ---
> drivers/edac/edac_device.c | 91 ++
> drivers/edac/edac_device.h | 40 +
> 2 files changed, 131 insertions(+)
>
> diff --git a/drivers/edac/edac_device.c b/drivers/edac/edac_device.c
> index 65cf2b9355c4..78ac44103acc 100644
> --- a/drivers/edac/edac_device.c
> +++ b/drivers/edac/edac_device.c
> @@ -643,3 +643,94 @@ void edac_device_handle_ue(struct edac_device_ctl_info
> *edac_dev,
> block ? block->name : "N/A", msg);
> }
> EXPORT_SYMBOL_GPL(edac_device_handle_ue);
> +
> +void __edac_device_handle_ce(struct edac_device_ctl_info *edac_dev,
> + unsigned int count, int inst_nr, int block_nr,
> + const char *msg)
> +{
Please do not add a copy here, instead modify the existing function
and share the code with both, old and new functions.
Thanks,
-Robert
Re: [PATCH v4 1/1] platform/x86/intel_cht_int33fe: Split code to USB Micro-B and Type-C variants
On Thu, Sep 19, 2019 at 1:53 AM Yauhen Kharuzhy wrote:
>
You so fast with new versions that I had no chance to comment on.
Finally here mine.
> Existing intel_cht_int33fe ACPI pseudo-device driver assumes that
> hardware has Type-C connector and register related devices described as
> I2C connections in the _CRS resource.
>
> There is at least one hardware (Lenovo Yoga Book YB1-91L/F) with Micro-B
> USB connector exists. It has INT33FE device in the DSDT table but
> there are only two I2C connection described: PMIC and BQ27452 battery
> fuel gauge.
>
> Splitting existing INT33FE driver allow to maintain code for USB Micro-B
> (AB) connector variant separately and make it simpler.
I didn't get what (AB) means in this context?
Did you mean "(or AB)"?
> Split driver to intel_cht_int33fe_common.c and
> intel_cht_int33fe_{typeb,typec}.c. Compile all this sources to one .ko
> module to make user experience easier.
You forgot to replace typeb here.
> - ---help---
> + help
This is unneeded churn
> + CONFIG_BATTERY_BQ27XXX=m and CONFIG_BATTERY_BQ27XXX_I2C=m for
> Micro-B
> + device and CONFIG_TYPEC_FUSB302=m and CONFIG_BATTERY_MAX17042=m
First s/and/or/.
> + for Type-C device.
> + * 1. The Whiskey Cove pmic, which is also described by the INT34D3 ACPI
> device
pmic -> PMIC
> + if (IS_ERR(data->battery_fg)) {
> + int err = PTR_ERR(data->battery_fg);
> +
> + if (err != -EPROBE_DEFER)
> + dev_err(dev,
> + "Failed to register battery fuel gauge: %d\n",
> + err);
> + return err;
> + }
> +
> + return 0;
I would rather replace this altogether by return PTR_ERR_OR_ZERO()
like it's done in the other function in the original driver.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH net] net: dsa: sja1105: Add dependency for NET_DSA_SJA1105_TAS
On Thu, 19 Sep 2019 at 09:22, Mao Wenan wrote:
>
> If CONFIG_NET_DSA_SJA1105_TAS=y and CONFIG_NET_SCH_TAPRIO=n,
> below error can be found:
> drivers/net/dsa/sja1105/sja1105_tas.o: In function `sja1105_setup_tc_taprio':
> sja1105_tas.c:(.text+0x318): undefined reference to `taprio_offload_free'
> sja1105_tas.c:(.text+0x590): undefined reference to `taprio_offload_get'
> drivers/net/dsa/sja1105/sja1105_tas.o: In function `sja1105_tas_teardown':
> sja1105_tas.c:(.text+0x610): undefined reference to `taprio_offload_free'
> make: *** [vmlinux] Error 1
>
> sja1105_tas needs tc-taprio, so this patch add the dependency for it.
>
> Fixes: 317ab5b86c8e ("net: dsa: sja1105: Configure the Time-Aware Scheduler
> via tc-taprio offload")
> Signed-off-by: Mao Wenan
> ---
Reviewed-by: Vladimir Oltean
> drivers/net/dsa/sja1105/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/dsa/sja1105/Kconfig b/drivers/net/dsa/sja1105/Kconfig
> index 55424f3..f40b248 100644
> --- a/drivers/net/dsa/sja1105/Kconfig
> +++ b/drivers/net/dsa/sja1105/Kconfig
> @@ -27,6 +27,7 @@ config NET_DSA_SJA1105_PTP
> config NET_DSA_SJA1105_TAS
> bool "Support for the Time-Aware Scheduler on NXP SJA1105"
> depends on NET_DSA_SJA1105
> + depends on NET_SCH_TAPRIO
> help
> This enables support for the TTEthernet-based egress scheduling
> engine in the SJA1105 DSA driver, which is controlled using a
> --
> 2.7.4
>
Thanks!
-Vladimir
[PATCH net] net: dsa: sja1105: Add dependency for NET_DSA_SJA1105_TAS
If CONFIG_NET_DSA_SJA1105_TAS=y and CONFIG_NET_SCH_TAPRIO=n,
below error can be found:
drivers/net/dsa/sja1105/sja1105_tas.o: In function `sja1105_setup_tc_taprio':
sja1105_tas.c:(.text+0x318): undefined reference to `taprio_offload_free'
sja1105_tas.c:(.text+0x590): undefined reference to `taprio_offload_get'
drivers/net/dsa/sja1105/sja1105_tas.o: In function `sja1105_tas_teardown':
sja1105_tas.c:(.text+0x610): undefined reference to `taprio_offload_free'
make: *** [vmlinux] Error 1
sja1105_tas needs tc-taprio, so this patch add the dependency for it.
Fixes: 317ab5b86c8e ("net: dsa: sja1105: Configure the Time-Aware Scheduler via
tc-taprio offload")
Signed-off-by: Mao Wenan
---
drivers/net/dsa/sja1105/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/dsa/sja1105/Kconfig b/drivers/net/dsa/sja1105/Kconfig
index 55424f3..f40b248 100644
--- a/drivers/net/dsa/sja1105/Kconfig
+++ b/drivers/net/dsa/sja1105/Kconfig
@@ -27,6 +27,7 @@ config NET_DSA_SJA1105_PTP
config NET_DSA_SJA1105_TAS
bool "Support for the Time-Aware Scheduler on NXP SJA1105"
depends on NET_DSA_SJA1105
+ depends on NET_SCH_TAPRIO
help
This enables support for the TTEthernet-based egress scheduling
engine in the SJA1105 DSA driver, which is controlled using a
--
2.7.4
Re: [PATCH v2] of: restore old handling of cells_name=NULL in of_*_phandle_with_args()
On Wed, Sep 18, 2019 at 10:19:54PM +0200, Uwe Kleine-König wrote:
> On Wed, Sep 18, 2019 at 03:09:06PM -0500, Rob Herring wrote:
> > Can I get a proper patch please.
>
> I don't understand what is wrong with my patch. Can you please expand
> what you are missing? I just tried to git-am it and the result looks
> fine.
I see that the commit this patch is fixing isn't in Linus' tree yet. Do
you want instead of this commit fixing the previous one a single good
patch that replaces e42ee61017f5 ("of: Let of_for_each_phandle fallback
to non-negative cell_count")?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Thank you for your cooperation
Dear friend, Sorry to invade your privacy through this media. I have bad health condition and I'm just looking for someone I can trust to lead a charity work for me. If you are interested, come back to me as as soon as possible for further explanation. Thanks for your collaboration Mrs. Virginie Charlotte
[PATCH] gpio: mxc: Only getting second IRQ when there is more than one IRQ
On some of i.MX SoCs like i.MX8QXP, there is ONLY one IRQ for each
GPIO bank, so it is better to check the IRQ count before getting
second IRQ to avoid below error message during probe:
[1.070908] gpio-mxc 5d08.gpio: IRQ index 1 not found
[1.077420] gpio-mxc 5d09.gpio: IRQ index 1 not found
[1.083766] gpio-mxc 5d0a.gpio: IRQ index 1 not found
[1.090122] gpio-mxc 5d0b.gpio: IRQ index 1 not found
[1.096470] gpio-mxc 5d0c.gpio: IRQ index 1 not found
[1.102804] gpio-mxc 5d0d.gpio: IRQ index 1 not found
[1.109144] gpio-mxc 5d0e.gpio: IRQ index 1 not found
[1.115475] gpio-mxc 5d0f.gpio: IRQ index 1 not found
Signed-off-by: Anson Huang
---
drivers/gpio/gpio-mxc.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
index 7907a87..39ba7dd 100644
--- a/drivers/gpio/gpio-mxc.c
+++ b/drivers/gpio/gpio-mxc.c
@@ -426,9 +426,15 @@ static int mxc_gpio_probe(struct platform_device *pdev)
if (IS_ERR(port->base))
return PTR_ERR(port->base);
- port->irq_high = platform_get_irq(pdev, 1);
- if (port->irq_high < 0)
- port->irq_high = 0;
+ err = platform_irq_count(pdev);
+ if (err < 0)
+ return err;
+
+ if (err > 1) {
+ port->irq_high = platform_get_irq(pdev, 1);
+ if (port->irq_high < 0)
+ port->irq_high = 0;
+ }
port->irq = platform_get_irq(pdev, 0);
if (port->irq < 0)
--
2.7.4
Re: [PATCH] devlink: add devlink notification for recovery
Wed, Sep 18, 2019 at 08:52:21PM CEST, sheetal.tigad...@broadcom.com wrote:
>From: Vikas Gupta
>
>Add a devlink notification for reporter recovery
>
>Signed-off-by: Vikas Gupta
>Signed-off-by: Sheetal Tigadoli
>---
> net/core/devlink.c | 25 +
> 1 file changed, 25 insertions(+)
>
>diff --git a/net/core/devlink.c b/net/core/devlink.c
>index e48680e..42909fb 100644
>--- a/net/core/devlink.c
>+++ b/net/core/devlink.c
>@@ -4730,6 +4730,28 @@ struct devlink_health_reporter *
> }
> EXPORT_SYMBOL_GPL(devlink_health_reporter_state_update);
>
>+static void __devlink_recover_notify(struct devlink *devlink,
>+ enum devlink_command cmd)
>+{
>+ struct sk_buff *msg;
>+ int err;
>+
>+ WARN_ON(cmd != DEVLINK_CMD_HEALTH_REPORTER_RECOVER);
>+
>+ msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
>+ if (!msg)
>+ return;
>+
>+ err = devlink_nl_fill(msg, devlink, cmd, 0, 0, 0);
>+ if (err) {
>+ nlmsg_free(msg);
>+ return;
>+ }
>+
>+ genlmsg_multicast_netns(&devlink_nl_family, devlink_net(devlink),
>+ msg, 0, DEVLINK_MCGRP_CONFIG, GFP_KERNEL);
>+}
>+
> static int
> devlink_health_reporter_recover(struct devlink_health_reporter *reporter,
> void *priv_ctx)
>@@ -4747,6 +4769,9 @@ struct devlink_health_reporter *
> reporter->health_state = DEVLINK_HEALTH_REPORTER_STATE_HEALTHY;
> reporter->last_recovery_ts = jiffies;
>
>+ __devlink_recover_notify(reporter->devlink,
>+ DEVLINK_CMD_HEALTH_REPORTER_RECOVER);
>+
> return 0;
> }
To follow the rest of the code The notification should be done upon
any reported change, using devlink_nl_health_reporter_fill() to prepare
the message.
Also, this is net-next patch net-next is closed now.
>
[PATCH v3 1/3] mmc: Add MMC software queue support
Now the MMC read/write stack will always wait for previous request is
completed by mmc_blk_rw_wait(), before sending a new request to hardware,
or queue a work to complete request, that will bring context switching
overhead, especially for high I/O per second rates, to affect the IO
performance.
Thus this patch introduces MMC software queue interface based on the
hardware command queue engine's interfaces, which is similar with the
hardware command queue engine's idea, that can remove the context
switching. Moreover we set the queue depth as 2 for software queue,
that is enough to let the irq handler always trigger the next request
without a context switch and then ask the blk_mq layer for the next one
to get queued, as well as avoiding a long latency.
>From the fio testing data in cover letter, we can see the software
queue can improve performance obviously with 4K block size, increasing
about 52% for sequential read, increasing about 114% for random read,
increasing about 81% for sequential write, and increasing about 127%
for random write.
Moreover we can expand the software queue interface to support MMC
packed request or packed command in future.
Signed-off-by: Baolin Wang
---
drivers/mmc/core/block.c | 61
drivers/mmc/core/mmc.c| 13 +-
drivers/mmc/core/queue.c | 25 +++-
drivers/mmc/host/Kconfig |8 ++
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/sqhci.c | 344 +
drivers/mmc/host/sqhci.h | 53 +++
include/linux/mmc/host.h |3 +
8 files changed, 498 insertions(+), 10 deletions(-)
create mode 100644 drivers/mmc/host/sqhci.c
create mode 100644 drivers/mmc/host/sqhci.h
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index 2c71a43..870462c 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -168,6 +168,11 @@ struct mmc_rpmb_data {
static inline int mmc_blk_part_switch(struct mmc_card *card,
unsigned int part_type);
+static void mmc_blk_rw_rq_prep(struct mmc_queue_req *mqrq,
+ struct mmc_card *card,
+ int disable_multi,
+ struct mmc_queue *mq);
+static void mmc_blk_swq_req_done(struct mmc_request *mrq);
static struct mmc_blk_data *mmc_blk_get(struct gendisk *disk)
{
@@ -1569,9 +1574,30 @@ static int mmc_blk_cqe_issue_flush(struct mmc_queue *mq,
struct request *req)
return mmc_blk_cqe_start_req(mq->card->host, mrq);
}
+static int mmc_blk_swq_issue_rw_rq(struct mmc_queue *mq, struct request *req)
+{
+ struct mmc_queue_req *mqrq = req_to_mmc_queue_req(req);
+ struct mmc_host *host = mq->card->host;
+ int err;
+
+ mmc_blk_rw_rq_prep(mqrq, mq->card, 0, mq);
+ mqrq->brq.mrq.done = mmc_blk_swq_req_done;
+ mmc_pre_req(host, &mqrq->brq.mrq);
+
+ err = mmc_cqe_start_req(host, &mqrq->brq.mrq);
+ if (err)
+ mmc_post_req(host, &mqrq->brq.mrq, err);
+
+ return err;
+}
+
static int mmc_blk_cqe_issue_rw_rq(struct mmc_queue *mq, struct request *req)
{
struct mmc_queue_req *mqrq = req_to_mmc_queue_req(req);
+ struct mmc_host *host = mq->card->host;
+
+ if (host->swq_enabled)
+ return mmc_blk_swq_issue_rw_rq(mq, req);
mmc_blk_data_prep(mq, mqrq, 0, NULL, NULL);
@@ -1957,6 +1983,41 @@ static void mmc_blk_urgent_bkops(struct mmc_queue *mq,
mmc_run_bkops(mq->card);
}
+static void mmc_blk_swq_req_done(struct mmc_request *mrq)
+{
+ struct mmc_queue_req *mqrq =
+ container_of(mrq, struct mmc_queue_req, brq.mrq);
+ struct request *req = mmc_queue_req_to_req(mqrq);
+ struct request_queue *q = req->q;
+ struct mmc_queue *mq = q->queuedata;
+ struct mmc_host *host = mq->card->host;
+ unsigned long flags;
+
+ if (mmc_blk_rq_error(&mqrq->brq) ||
+ mmc_blk_urgent_bkops_needed(mq, mqrq)) {
+ spin_lock_irqsave(&mq->lock, flags);
+ mq->recovery_needed = true;
+ mq->recovery_req = req;
+ spin_unlock_irqrestore(&mq->lock, flags);
+
+ host->cqe_ops->cqe_recovery_start(host);
+
+ schedule_work(&mq->recovery_work);
+ return;
+ }
+
+ mmc_blk_rw_reset_success(mq, req);
+
+ /*
+* Block layer timeouts race with completions which means the normal
+* completion path cannot be used during recovery.
+*/
+ if (mq->in_recovery)
+ mmc_blk_cqe_complete_rq(mq, req);
+ else
+ blk_mq_complete_request(req);
+}
+
void mmc_blk_mq_complete(struct request *req)
{
struct mmc_queue *mq = req->q->queuedata;
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index c880489..8eac1a2 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1852,15 +1852,22 @@ static int mmc_init_card(struc
[PATCH v3 3/3] mmc: host: sdhci-sprd: Add software queue support
Add software queue support to improve the performance.
Signed-off-by: Baolin Wang
---
drivers/mmc/host/Kconfig |1 +
drivers/mmc/host/sdhci-sprd.c | 26 ++
2 files changed, 27 insertions(+)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index d117f18..862e8e9 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -619,6 +619,7 @@ config MMC_SDHCI_SPRD
depends on ARCH_SPRD
depends on MMC_SDHCI_PLTFM
select MMC_SDHCI_IO_ACCESSORS
+ select MMC_SQHCI
help
This selects the SDIO Host Controller in Spreadtrum
SoCs, this driver supports R11(IP version: R11P0).
diff --git a/drivers/mmc/host/sdhci-sprd.c b/drivers/mmc/host/sdhci-sprd.c
index d07b979..4dec0b3 100644
--- a/drivers/mmc/host/sdhci-sprd.c
+++ b/drivers/mmc/host/sdhci-sprd.c
@@ -19,6 +19,7 @@
#include
#include "sdhci-pltfm.h"
+#include "sqhci.h"
/* SDHCI_ARGUMENT2 register high 16bit */
#define SDHCI_SPRD_ARG2_STUFF GENMASK(31, 16)
@@ -379,6 +380,16 @@ static unsigned int sdhci_sprd_get_ro(struct sdhci_host
*host)
return 0;
}
+static void sdhci_sprd_request_done(struct sdhci_host *host,
+ struct mmc_request *mrq)
+{
+ /* Validate if the request was from software queue firstly. */
+ if (sqhci_finalize_request(host->mmc, mrq))
+ return;
+
+mmc_request_done(host->mmc, mrq);
+}
+
static struct sdhci_ops sdhci_sprd_ops = {
.read_l = sdhci_sprd_readl,
.write_l = sdhci_sprd_writel,
@@ -392,6 +403,7 @@ static unsigned int sdhci_sprd_get_ro(struct sdhci_host
*host)
.hw_reset = sdhci_sprd_hw_reset,
.get_max_timeout_count = sdhci_sprd_get_max_timeout_count,
.get_ro = sdhci_sprd_get_ro,
+ .request_done = sdhci_sprd_request_done,
};
static void sdhci_sprd_request(struct mmc_host *mmc, struct mmc_request *mrq)
@@ -521,6 +533,7 @@ static int sdhci_sprd_probe(struct platform_device *pdev)
{
struct sdhci_host *host;
struct sdhci_sprd_host *sprd_host;
+ struct sqhci_host *sq_host;
struct clk *clk;
int ret = 0;
@@ -631,6 +644,16 @@ static int sdhci_sprd_probe(struct platform_device *pdev)
sprd_host->flags = host->flags;
+ sq_host = devm_kzalloc(&pdev->dev, sizeof(*sq_host), GFP_KERNEL);
+ if (!sq_host) {
+ ret = -ENOMEM;
+ goto err_cleanup_host;
+ }
+
+ ret = sqhci_init(sq_host, host->mmc);
+ if (ret)
+ goto err_cleanup_host;
+
ret = __sdhci_add_host(host);
if (ret)
goto err_cleanup_host;
@@ -689,6 +712,7 @@ static int sdhci_sprd_runtime_suspend(struct device *dev)
struct sdhci_host *host = dev_get_drvdata(dev);
struct sdhci_sprd_host *sprd_host = TO_SPRD_HOST(host);
+ sqhci_suspend(host->mmc);
sdhci_runtime_suspend_host(host);
clk_disable_unprepare(sprd_host->clk_sdio);
@@ -717,6 +741,8 @@ static int sdhci_sprd_runtime_resume(struct device *dev)
goto clk_disable;
sdhci_runtime_resume_host(host, 1);
+ sqhci_resume(host->mmc);
+
return 0;
clk_disable:
--
1.7.9.5
[PATCH v3 2/3] mmc: host: sdhci: Add request_done ops for struct sdhci_ops
Add request_done ops for struct sdhci_ops as a preparation in case some
host controllers have different method to complete one request, such as
supporting request completion of MMC software queue.
Signed-off-by: Baolin Wang
---
drivers/mmc/host/sdhci.c | 12 ++--
drivers/mmc/host/sdhci.h |2 ++
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index a5dc5aa..b2c8695 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2710,7 +2710,10 @@ static bool sdhci_request_done(struct sdhci_host *host)
spin_unlock_irqrestore(&host->lock, flags);
- mmc_request_done(host->mmc, mrq);
+ if (host->ops->request_done)
+ host->ops->request_done(host, mrq);
+ else
+ mmc_request_done(host->mmc, mrq);
return false;
}
@@ -3133,7 +3136,12 @@ static irqreturn_t sdhci_irq(int irq, void *dev_id)
/* Process mrqs ready for immediate completion */
for (i = 0; i < SDHCI_MAX_MRQS; i++) {
- if (mrqs_done[i])
+ if (!mrqs_done[i])
+ continue;
+
+ if (host->ops->request_done)
+ host->ops->request_done(host, mrqs_done[i]);
+ else
mmc_request_done(host->mmc, mrqs_done[i]);
}
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 902f855..e9a476f 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -643,6 +643,8 @@ struct sdhci_ops {
void(*voltage_switch)(struct sdhci_host *host);
void(*adma_write_desc)(struct sdhci_host *host, void **desc,
dma_addr_t addr, int len, unsigned int cmd);
+ void(*request_done)(struct sdhci_host *host,
+ struct mmc_request *mrq);
};
#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
--
1.7.9.5
[PATCH v3 0/3] Add MMC software queue support
Hi All, Now the MMC read/write stack will always wait for previous request is completed by mmc_blk_rw_wait(), before sending a new request to hardware, or queue a work to complete request, that will bring context switching overhead, especially for high I/O per second rates, to affect the IO performance. Thus this patch set will introduce the MMC software command queue support based on command queue engine's interfaces, and set the queue depth as 2, that means we do not need wait for previous request is completed and can queue 2 requests in flight. It is enough to let the irq handler always trigger the next request without a context switch and then ask the blk_mq layer for the next one to get queued, as well as avoiding a long latency. Moreover we can expand the MMC software queue interface to support MMC packed request or packed command instead of adding new interfaces, according to previosus discussion. Below are some comparison data with fio tool. The fio command I used is like below with changing the '--rw' parameter and enabling the direct IO flag to measure the actual hardware transfer speed in 4K block size. ./fio --filename=/dev/mmcblk0p30 --direct=1 --iodepth=20 --rw=read --bs=4K --size=512M --group_reporting --numjobs=20 --name=test_read My eMMC card working at HS400 Enhanced strobe mode: [2.229856] mmc0: new HS400 Enhanced strobe MMC card at address 0001 [2.237566] mmcblk0: mmc0:0001 HBG4a2 29.1 GiB [2.242621] mmcblk0boot0: mmc0:0001 HBG4a2 partition 1 4.00 MiB [2.249110] mmcblk0boot1: mmc0:0001 HBG4a2 partition 2 4.00 MiB [2.255307] mmcblk0rpmb: mmc0:0001 HBG4a2 partition 3 4.00 MiB, chardev (248:0) 1. Without MMC software queue I tested 3 times for each case and output a average speed. 1) Sequential read: Speed: 28.9MiB/s, 26.4MiB/s, 30.9MiB/s Average speed: 28.7MiB/s 2) Random read: Speed: 18.2MiB/s, 8.9MiB/s, 15.8MiB/s Average speed: 14.3MiB/s 3) Sequential write: Speed: 21.1MiB/s, 27.9MiB/s, 25MiB/s Average speed: 24.7MiB/s 4) Random write: Speed: 21.5MiB/s, 18.1MiB/s, 18.1MiB/s Average speed: 19.2MiB/s 2. With MMC software queue I tested 3 times for each case and output a average speed. 1) Sequential read: Speed: 44.1MiB/s, 42.3MiB/s, 44.4MiB/s Average speed: 43.6MiB/s 2) Random read: Speed: 30.6MiB/s, 30.9MiB/s, 30.5MiB/s Average speed: 30.6MiB/s 3) Sequential write: Speed: 44.1MiB/s, 45.9MiB/s, 44.2MiB/s Average speed: 44.7MiB/s 4) Random write: Speed: 45.1MiB/s, 43.3MiB/s, 42.4MiB/s Average speed: 43.6MiB/s Form above data, we can see the MMC software queue can help to improve the performance obviously. Any comments are welcome. Thanks a lot. Changes from v2: - Remove reference to 'struct cqhci_host' and 'struct cqhci_slot', instead adding 'struct sqhci_host', which is only used by software queue. Changes from v1: - Add request_done ops for sdhci_ops. - Replace virtual command queue with software queue for functions and variables. - Rename the software queue file and add sqhci.h header file. Baolin Wang (3): mmc: Add MMC software queue support mmc: host: sdhci: Add request_done ops for struct sdhci_ops mmc: host: sdhci-sprd: Add software queue support drivers/mmc/core/block.c | 61 drivers/mmc/core/mmc.c| 13 +- drivers/mmc/core/queue.c | 25 ++- drivers/mmc/host/Kconfig |9 ++ drivers/mmc/host/Makefile |1 + drivers/mmc/host/sdhci-sprd.c | 26 drivers/mmc/host/sdhci.c | 12 +- drivers/mmc/host/sdhci.h |2 + drivers/mmc/host/sqhci.c | 344 + drivers/mmc/host/sqhci.h | 53 +++ include/linux/mmc/host.h |3 + 11 files changed, 537 insertions(+), 12 deletions(-) create mode 100644 drivers/mmc/host/sqhci.c create mode 100644 drivers/mmc/host/sqhci.h -- 1.7.9.5
[PATCH] x86/mm/pti: Handle unaligned addr to PMD-mapped page in pti_clone_pgtable
To clone page table of PMD-mapped pages, pti_clone_pgtable() requires PMD
aligned start address. [1] adds warning for unaligned addresses. However,
there is still no warning for unaligned address to valid huge pmd [2].
Add alignment check in valid pmd_large() case. If the address is
unaligned, round it down to the nearest PMD aligned address and show
warning.
[1] commit 825d0b73cd75 ("x86/mm/pti: Handle unaligned address gracefully
in pti_clone_pagetable()")
[2]
https://lore.kernel.org/lkml/156864062019.3407.14798418565580024723.t...@nanos.tec.linutronix.de/
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Peter Zijlstra (Intel)
Cc: Linus Torvalds
Signed-off-by: Song Liu
---
arch/x86/mm/pti.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index 7f2140414440..d224115c350d 100644
--- a/arch/x86/mm/pti.c
+++ b/arch/x86/mm/pti.c
@@ -343,6 +343,10 @@ pti_clone_pgtable(unsigned long start, unsigned long end,
}
if (pmd_large(*pmd) || level == PTI_CLONE_PMD) {
+ /* warn and round_down() unaligned addr */
+ if (WARN_ON_ONCE(addr & ~PMD_MASK))
+ addr &= PMD_MASK;
+
target_pmd = pti_user_pagetable_walk_pmd(addr);
if (WARN_ON(!target_pmd))
return;
--
2.17.1
Re: [PATCH trivial] KVM: PPC: Remove superfluous check for non-zero return value
On 18/09/2019 22.54, Greg Kurz wrote:
> On Wed, 18 Sep 2019 18:44:36 +0200
> Greg Kurz wrote:
>
>> On Wed, 11 Sep 2019 21:52:35 +0200
>> Thomas Huth wrote:
>>
>>> After the kfree()s haven been removed in the previous
>>> commit 9798f4ea71ea ("fix rollback when kvmppc_xive_create fails"),
>>> the code can be simplified even more to simply always "return ret"
>>> now.
>>>
>>> Signed-off-by: Thomas Huth
>>> ---
>>
>> This looks like a good candidate for trivial, hence Cc'ing Jiri
>> and adding trivial keyword in subject.
>>
>> Reviewed-by: Greg Kurz
>>
>
> Oops, the patch is correct but there are some fixes that require
> the return 0 to stay around...
>
> https://patchwork.ozlabs.org/project/kvm-ppc/list/?series=129957
:-)
Ok, then please simply ignore my patch.
Thomas
Re: [PATCH v1 2/2] spi: cadence-qspi: Add QSPI support for Intel LGM SoC
Hi Mark, Thank you for the comments and queries. On 18/9/2019 8:08 PM, Mark Brown wrote: On Wed, Sep 18, 2019 at 01:59:06PM +0800, Ramuthevar, Vadivel MuruganX wrote: On 17/9/2019 11:36 PM, Mark Brown wrote: On Tue, Sep 17, 2019 at 10:11:28AM +0800, Ramuthevar, Vadivel MuruganX wrote: * spi-cadence.c* in *drivers/spi/*, which supports very old legacy cadence-spi based devices(normal) * cadence-quadspi.c(drivers/mtd/spi-nor/)* : specific support to SPI-NOR flash with new spi-nor layer. all the API's in this driver purely on spi-nor specific, so couldn't proceed to adapt. Are these completely separate IPs or are they just different versions of the same IP? These are same IPs , but different features Enabled/Disabled depends upon the SoC vendors. for e.g: Intel LGM SoC uses the same IP, but without DMA and Direct access controller. also dedicated support to flash devices. If it's different versions of the same IP then everything should be in one driver with the optional features enabled depending on what's in a given system. Agreed!, I am trying to adapt the driver/mtd/spi-nor/cadence-quadspi.c and newly sent patches in a single driver file, also trying to use spi_mem_ops framework. With Best Regards Vadivel
Re: [PATCH] mm/pgtable/debug: Fix test validating architecture page table helpers
Le 18/09/2019 à 09:32, Anshuman Khandual a écrit : On 09/13/2019 11:53 AM, Christophe Leroy wrote: Fix build failure on powerpc. Fix preemption imbalance. Signed-off-by: Christophe Leroy --- mm/arch_pgtable_test.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/arch_pgtable_test.c b/mm/arch_pgtable_test.c index 8b4a92756ad8..f2b3c9ec35fa 100644 --- a/mm/arch_pgtable_test.c +++ b/mm/arch_pgtable_test.c @@ -24,6 +24,7 @@ #include #include #include +#include #include #include @@ -400,6 +401,8 @@ static int __init arch_pgtable_tests_init(void) p4d_clear_tests(p4dp); pgd_clear_tests(mm, pgdp); + pte_unmap(ptep); + pmd_populate_tests(mm, pmdp, saved_ptep); pud_populate_tests(mm, pudp, saved_pmdp); p4d_populate_tests(mm, p4dp, saved_pudp); Hello Christophe, I am planning to fold this fix into the current patch and retain your Signed-off-by. Are you okay with it ? No problem, do whatever is convenient for you. You can keep the signed-off-by, or use tested-by: as I tested it on PPC32. Christophe
Re: [PATCH V2 2/2] mm/pgtable/debug: Add test validating architecture page table helpers
Le 19/09/2019 à 06:56, Anshuman Khandual a écrit :
On 09/18/2019 09:56 PM, Christophe Leroy wrote:
Le 18/09/2019 à 07:04, Anshuman Khandual a écrit :
On 09/13/2019 03:31 PM, Christophe Leroy wrote:
Le 13/09/2019 à 11:02, Anshuman Khandual a écrit :
+#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)
#ifdefs have to be avoided as much as possible, see below
Yeah but it has been bit difficult to avoid all these $ifdef because of the
availability (or lack of it) for all these pgtable helpers in various config
combinations on all platforms.
As far as I can see these pgtable helpers should exist everywhere at least via
asm-generic/ files.
But they might not actually do the right thing.
Can you spot a particular config which fails ?
Lets consider the following example (after removing the $ifdefs around it)
which though builds successfully but fails to pass the intended test. This
is with arm64 config 4K pages sizes with 39 bits VA space which ends up
with a 3 level page table arrangement.
static void __init p4d_clear_tests(p4d_t *p4dp)
{
p4d_t p4d = READ_ONCE(*p4dp);
My suggestion was not to completely drop the #ifdef but to do like you did in
pgd_clear_tests() for instance, ie to add the following test on top of the
function:
if (mm_pud_folded(mm) || is_defined(__ARCH_HAS_5LEVEL_HACK))
return;
Sometimes this does not really work. On some platforms, combination of
__PAGETABLE_PUD_FOLDED and __ARCH_HAS_5LEVEL_HACK decide whether the
helpers such as __pud() or __pgd() is even available for that platform.
Ideally it should have been through generic falls backs in include/*/
but I guess there might be bugs on the platform or it has not been
changed to adopt 5 level page table framework with required folding
macros etc.
Yes. As I suggested below, most likely that's better to retain the
#ifdef __ARCH_HAS_5LEVEL_HACK but change the #ifdef
__PAGETABLE_PUD_FOLDED by a runtime test of mm_pud_folded(mm)
As pointed by Gerald, some arches don't have __PAGETABLE_PUD_FOLDED
because they are deciding dynamically if they fold the level on not, but
have mm_pud_folded(mm)
p4d = __p4d(p4d_val(p4d) | RANDOM_ORVALUE);
WRITE_ONCE(*p4dp, p4d);
p4d_clear(p4dp);
p4d = READ_ONCE(*p4dp);
WARN_ON(!p4d_none(p4d));
}
The following test hits an error at WARN_ON(!p4d_none(p4d))
[ 16.757333] [ cut here ]
[ 16.758019] WARNING: CPU: 11 PID: 1 at mm/arch_pgtable_test.c:187
arch_pgtable_tests_init+0x24c/0x474
[...]
[ 16.781282] ---[ end trace 042e6c40c0a3b038 ]---
On arm64 (4K page size|39 bits VA|3 level page table)
#elif CONFIG_PGTABLE_LEVELS == 3 /* Applicable here */
#define __ARCH_USE_5LEVEL_HACK
#include
Which pulls in
#include
which pulls in
#include
which defines
static inline int p4d_none(p4d_t p4d)
{
return 0;
}
which will invariably trigger WARN_ON(!p4d_none(p4d)).
Similarly for next test p4d_populate_tests() which will always be
successful because p4d_bad() invariably returns negative.
static inline int p4d_bad(p4d_t p4d)
{
return 0;
}
static void __init p4d_populate_tests(struct mm_struct *mm, p4d_t *p4dp,
pud_t *pudp)
{
p4d_t p4d;
/*
* This entry points to next level page table page.
* Hence this must not qualify as p4d_bad().
*/
pud_clear(pudp);
p4d_clear(p4dp);
p4d_populate(mm, p4dp, pudp);
p4d = READ_ONCE(*p4dp);
WARN_ON(p4d_bad(p4d));
}
We should not run these tests for the above config because they are
not applicable and will invariably produce same result.
[...]
So it shouldn't be an issue. Maybe if a couple of arches miss them, the best
would be to fix the arches, since that's the purpose of your testsuite isn't it
?
The run time failures as explained previously is because of the folding which
needs to be protected as they are not even applicable. The compile time
failures are because pxx_populate() signatures are platform specific depending
on how many page table levels they really support.
So IIUC, the compiletime problem is around __ARCH_HAS_5LEVEL_HACK. For all #if
!defined(__PAGETABLE_PXX_FOLDED), something equivalent to the following should
make the trick.
if (mm_pxx_folded())
return;
For the __ARCH_HAS_5LEVEL_HACK stuff, I think we should be able to regroup all
impacted functions inside a single #ifdef __ARCH_HAS_5LEVEL_HACK
I was wondering if it will be better to
1) Minimize all #ifdefs in the code which might fail on some platforms
2) Restrict proposed test module to platforms where it builds and runs
3) Enable other platforms afterwards after fixing their build problems or other
requirements
I understand that __ARCH_HAS_5LEVEL_HACK is an HACK as its name
suggests, so you can't expect all platforms to go for an HACK
RE: [PATCH V6 2/2] mailbox: introduce ARM SMC based mailbox
Hi Jassi,
> Subject: Re: [PATCH V6 2/2] mailbox: introduce ARM SMC based mailbox
>
> On Wed, Sep 18, 2019 at 5:00 AM Andre Przywara
> wrote:
>
> > >
> > > >
> > > > > + };
> > > > > +};
> > > >
> > > > If this is the data structure that this mailbox controller uses, I
> > > > would expect this to be documented somewhere, or even exported.
> > >
> > > Export this structure in include/linux/mailbox/smc-mailbox.h?
> >
> > For instance, even though I am not sure this is really desired or helpful,
> > since
> we expect a generic mailbox client (the SCPI or SCMI driver) to deal with that
> mailbox.
> >
> > But at least the expected format should be documented, which could just be
> in writing, not necessarily in code.
> >
> Yes, the packet format is specified by the controller and defined in some
> header for clients to include. Other platforms do that already.
So you prefer add the structure in include/linux/mailbox/smc-mailbox.h?
Thanks,
Peng.
>
>
>
> > > > > +
> > > > > +typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long,
> > > > > + unsigned long, unsigned long,
> > > > > + unsigned long, unsigned long,
> > > > > + unsigned long); static
> smc_mbox_fn
> > > > > +*invoke_smc_mbox_fn;
> > > > > +
> > > > > +static int arm_smc_send_data(struct mbox_chan *link, void
> > > > > +*data) { struct arm_smc_chan_data *chan_data = link->con_priv;
> > > > > +struct arm_smccc_mbox_cmd *cmd = data; unsigned long ret;
> > > > > + u32 function_id;
> > > > > +
> > > > > + function_id = chan_data->function_id; if (!function_id)
> > > > > + function_id = cmd->function_id;
> > > > > +
> > > > > + if (function_id & BIT(30)) {
> > > >
> > > > if (ARM_SMCCC_IS_64(function_id)) {
> > >
> > > ok
> > >
> > > >
> > > > > + ret = invoke_smc_mbox_fn(function_id,
> cmd->args_smccc64[0],
> > > > > + cmd->args_smccc64[1],
> > > > > + cmd->args_smccc64[2],
> > > > > + cmd->args_smccc64[3],
> > > > > + cmd->args_smccc64[4],
> > > > > + cmd->args_smccc64[5]); }
> else
> > > > > + {
> > > > > + ret = invoke_smc_mbox_fn(function_id,
> cmd->args_smccc32[0],
> > > > > + cmd->args_smccc32[1],
> > > > > + cmd->args_smccc32[2],
> > > > > + cmd->args_smccc32[3],
> > > > > + cmd->args_smccc32[4],
> > > > > + cmd->args_smccc32[5]); }
> > > > > +
> > > > > + mbox_chan_received_data(link, (void *)ret);
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > +static unsigned long __invoke_fn_hvc(unsigned int function_id,
> > > > > + unsigned long arg0, unsigned
> long arg1,
> > > > > + unsigned long arg2, unsigned
> long arg3,
> > > > > + unsigned long arg4, unsigned
> long
> > > > > +arg5) { struct arm_smccc_res res;
> > > > > +
> > > > > + arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4,
> > > > > + arg5, 0, &res);
> > > > > + return res.a0;
> > > > > +}
> > > > > +
> > > > > +static unsigned long __invoke_fn_smc(unsigned int function_id,
> > > > > + unsigned long arg0, unsigned
> long arg1,
> > > > > + unsigned long arg2, unsigned
> long arg3,
> > > > > + unsigned long arg4, unsigned
> long
> > > > > +arg5) { struct arm_smccc_res res;
> > > > > +
> > > > > + arm_smccc_smc(function_id, arg0, arg1, arg2, arg3, arg4,
> > > > > + arg5, 0, &res);
> > > > > + return res.a0;
> > > > > +}
> > > > > +
> > > > > +static const struct mbox_chan_ops arm_smc_mbox_chan_ops = {
> > > > > + .send_data = arm_smc_send_data,
> > > > > +};
> > > > > +
> > > > > +static int arm_smc_mbox_probe(struct platform_device *pdev) {
> > > > > +struct device *dev = &pdev->dev; struct mbox_controller *mbox;
> > > > > +struct arm_smc_chan_data *chan_data; int ret;
> > > > > + u32 function_id = 0;
> > > > > +
> > > > > + if (of_device_is_compatible(dev->of_node, "arm,smc-mbox"))
> > > > > + invoke_smc_mbox_fn = __invoke_fn_smc; else
> > > > > + invoke_smc_mbox_fn = __invoke_fn_hvc;
> > > > > +
> > > > > + mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL); if
> > > > > + (!mbox)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + mbox->num_chans = 1;
> > > > > + mbox->chans = devm_kzalloc(dev, sizeof(*mbox->chans),
> > > > > + mbox->GFP_KERNEL);
> > > > > + if (!mbox->chans)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + chan_data = devm_kzalloc(dev, sizeof(*chan_data), GFP_KERNEL);
> > > > > + if (!chan_data)
> > > > > + return -ENOMEM;
> > > > > +
> > >
remoteproc: don't allow modular build
Hi Christoph/Bjorn, There are a bunch of defconfigs that rely on modular build of remoteproc. If i do a git grep CONFIG_REMOTEPROC on linux-next: arch/arm/configs/davinci_all_defconfig:CONFIG_REMOTEPROC=m arch/arm/configs/multi_v7_defconfig:CONFIG_REMOTEPROC=m arch/arm/configs/omap2plus_defconfig:CONFIG_REMOTEPROC=m arch/arm/configs/qcom_defconfig:CONFIG_REMOTEPROC=y arch/arm64/configs/defconfig:CONFIG_REMOTEPROC=m All of them now stop building the remoteproc as a module and all the dependent modules consequently do not get built. Do you recommend all of them to get converted to built in? That will be some magnitude of change. Best Regards, Keerthy
[PATCH 5/6] arm64: dts: rockchip: Rename vcc12v_sys into dc_12v for roc-rk3399-pc
It is always better practice to follow regulator naming conventions
as per the schematics for future references.
This would indeed helpful to review and check the naming convention
directly on schematics, both for the code reviewers and the developers.
So, rename vcc12v_sys into dc_12v as per rk3399 power tree as per
roc-rk3399-pc schematics.
Signed-off-by: Jagan Teki
---
.../boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts
b/arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts
index e09bcbdd92f5..51242ea5447d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts
@@ -57,9 +57,9 @@
* should be placed inside mp8859, but not until mp8859 has
* its own dt-binding.
*/
- vcc12v_sys: mp8859-dcdc1 {
+ dc_12v: mp8859-dcdc1 {
compatible = "regulator-fixed";
- regulator-name = "vcc12v_sys";
+ regulator-name = "dc_12v";
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <1200>;
@@ -85,7 +85,7 @@
regulator-boot-on;
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
- vin-supply = <&vcc12v_sys>;
+ vin-supply = <&dc_12v>;
};
/* Actually 3 regulators (host0, 1, 2) controlled by the same gpio */
@@ -118,7 +118,7 @@
regulator-boot-on;
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
- vin-supply = <&vcc12v_sys>;
+ vin-supply = <&dc_12v>;
};
vdd_log: vdd-log {
--
2.18.0.321.gffc6fa0e3
[PATCH 6/6] arm64: dts: rockchip: Fix roc-rk3399-pc regulator input rails
Few, know rk808 pmic regulators VCC[1-4], VCC[6-7], VCC[9-11],
VDD_LOG, VDD_GPU, VDD_CPU_B, VCC3V3_SYS are inputting with vcc_sys
which is 5V power rail from dc_12v.
So, replace the vin-supply of above mentioned regulators
with vcc_sys as per the PMIC-RK808-D page of roc-rk3399-pc
schematics.
Signed-off-by: Jagan Teki
---
.../rk3399-libretech-roc-rk3399-pc.dts| 26 +--
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts
b/arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts
index 51242ea5447d..1eddb2e00809 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts
@@ -85,7 +85,7 @@
regulator-boot-on;
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
- vin-supply = <&dc_12v>;
+ vin-supply = <&vcc_sys>;
};
/* Actually 3 regulators (host0, 1, 2) controlled by the same gpio */
@@ -129,7 +129,7 @@
regulator-boot-on;
regulator-min-microvolt = <80>;
regulator-max-microvolt = <140>;
- vin-supply = <&vcc3v3_sys>;
+ vin-supply = <&vcc_sys>;
};
};
@@ -202,16 +202,16 @@
rockchip,system-power-controller;
wakeup-source;
- vcc1-supply = <&vcc3v3_sys>;
- vcc2-supply = <&vcc3v3_sys>;
- vcc3-supply = <&vcc3v3_sys>;
- vcc4-supply = <&vcc3v3_sys>;
- vcc6-supply = <&vcc3v3_sys>;
- vcc7-supply = <&vcc3v3_sys>;
+ vcc1-supply = <&vcc_sys>;
+ vcc2-supply = <&vcc_sys>;
+ vcc3-supply = <&vcc_sys>;
+ vcc4-supply = <&vcc_sys>;
+ vcc6-supply = <&vcc_sys>;
+ vcc7-supply = <&vcc_sys>;
vcc8-supply = <&vcc3v3_sys>;
- vcc9-supply = <&vcc3v3_sys>;
- vcc10-supply = <&vcc3v3_sys>;
- vcc11-supply = <&vcc3v3_sys>;
+ vcc9-supply = <&vcc_sys>;
+ vcc10-supply = <&vcc_sys>;
+ vcc11-supply = <&vcc_sys>;
vcc12-supply = <&vcc3v3_sys>;
vddio-supply = <&vcc1v8_pmu>;
@@ -385,7 +385,7 @@
regulator-ramp-delay = <1000>;
regulator-always-on;
regulator-boot-on;
- vin-supply = <&vcc3v3_sys>;
+ vin-supply = <&vcc_sys>;
regulator-state-mem {
regulator-off-in-suspend;
@@ -404,7 +404,7 @@
regulator-ramp-delay = <1000>;
regulator-always-on;
regulator-boot-on;
- vin-supply = <&vcc3v3_sys>;
+ vin-supply = <&vcc_sys>;
regulator-state-mem {
regulator-off-in-suspend;
--
2.18.0.321.gffc6fa0e3
[PATCH 3/6] arm64: dts: rockchip: Use libretech model, compatible for ROC-PC
Though the ROC-PC is manufactured by firefly, it is co-designed
by libretch like other Libretech computer boards from allwinner,
amlogic does.
So, it is always meaningful to keep maintain those vendors who
are part of design participation so-that the linux mainline
code will expose outside world who are the makers of such
hardware prototypes.
So,
- append the compatible to "libretech,roc-rk3399-pc" and
- update the model to "Libre Computer Board ROC-RK3399-PC"
like other libretech computer boards does.
Signed-off-by: Jagan Teki
---
arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
index c53f3d571620..e09bcbdd92f5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
@@ -9,8 +9,8 @@
#include "rk3399-opp.dtsi"
/ {
- model = "Firefly ROC-RK3399-PC Board";
- compatible = "firefly,roc-rk3399-pc", "rockchip,rk3399";
+ model = "Libre Computer Board ROC-RK3399-PC";
+ compatible = "libretech,roc-rk3399-pc", "firefly,roc-rk3399-pc",
"rockchip,rk3399";
chosen {
stdout-path = "serial2:150n8";
--
2.18.0.321.gffc6fa0e3
[PATCH 4/6] arm64: dts: rockchip: Rename roc-pc with libretech notation
Though the ROC-PC is manufactured by firefly, it is co-designed
by libretch like other Libretech computer boards from allwinner,
amlogic does.
So, it is always meaningful to keep maintain those vendors who
are part of design participation so-that the linux mainline
code will expose outside world who are the makers of such
hardware prototypes.
So, rename the existing rk3399-roc-pc.dts with libretch notation,
rk3399-libretech-roc-rk3399-pc.dts
Signed-off-by: Jagan Teki
---
arch/arm64/boot/dts/rockchip/Makefile | 2 +-
.../{rk3399-roc-pc.dts => rk3399-libretech-roc-rk3399-pc.dts} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename arch/arm64/boot/dts/rockchip/{rk3399-roc-pc.dts =>
rk3399-libretech-roc-rk3399-pc.dts} (100%)
diff --git a/arch/arm64/boot/dts/rockchip/Makefile
b/arch/arm64/boot/dts/rockchip/Makefile
index 1f18a9392d15..73c10ddb4300 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -21,12 +21,12 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-captain.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-v.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-leez-p710.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-libretech-roc-rk3399-pc.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-orangepi.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-puma-haikou.dtb
-dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-roc-pc.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock-pi-4.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock960.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rockpro64.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
b/arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts
similarity index 100%
rename from arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
rename to arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts
--
2.18.0.321.gffc6fa0e3
[PATCH 1/6] arm64: dts: rockchip: Fix rk3399-roc-pc pwm2 pin
ROC-PC is not able to boot linux console if PWM2_d is
unattached to any pinctrl logic.
To be precise the linux boot hang with last logs as,
...
.
[0.003367] Console: colour dummy device 80x25
[0.003788] printk: console [tty0] enabled
[0.004178] printk: bootconsole [uart8250] disabled
In ROC-PC the PWM2_d pin is connected to LOG_DVS_PWM of
VDD_LOG. So, for normal working operations this needs to
active and pull-down.
This patch fix, by attaching pinctrl active and pull-down
the pwm2.
Signed-off-by: Jagan Teki
---
arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
index 19f7732d728c..c53f3d571620 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
@@ -548,6 +548,8 @@
};
&pwm2 {
+ pinctrl-names = "active";
+ pinctrl-0 = <&pwm2_pin_pull_down>;
status = "okay";
};
--
2.18.0.321.gffc6fa0e3
[PATCH 2/6] dt-bindings: arm: rockchip: Use libretech for roc-pc binding
Though the ROC-PC is manufactured by firefly, it is co-designed by libretch like other Libretech computer boards from allwinner, amlogic does. So, it is always meaningful to keep maintain those vendors who are part of design participation so-that the linux mainline code will expose outside world who are the makers of such hardware prototypes. So, update the dt-bindings of ROC-PC with libretch notation like other libretech computer boards does. Signed-off-by: Jagan Teki --- Documentation/devicetree/bindings/arm/rockchip.yaml | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 110fcca1a94e..bb65a10e85ce 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -87,11 +87,6 @@ properties: - const: firefly,roc-rk3328-cc - const: rockchip,rk3328 - - description: Firefly ROC-RK3399-PC -items: - - const: firefly,roc-rk3399-pc - - const: rockchip,rk3399 - - description: FriendlyElec NanoPi4 series boards items: - enum: @@ -364,6 +359,12 @@ properties: - const: leez,p710 - const: rockchip,rk3399 + - description: Libre Computer Board ROC-RK3399-PC +items: + - const: libretech,roc-rk3399-pc + - const: firefly,roc-rk3399-pc + - const: rockchip,rk3399 + - description: Mecer Xtreme Mini S6 items: - const: mecer,xms6 -- 2.18.0.321.gffc6fa0e3
[PATCH 0/6] arm64: dts: rockchip: ROC-PC fixes
This series is trying to fix the Linux boot and other
regulators stuff for ROC-RK3399-PC board.
patch 1: attach pinctrl to pwm2 pin
patch 2-4: libretech naming conventions
patch 5-6: regulator renaming, input rails fixes
Any inputs?
Jagan.
Jagan Teki (6):
arm64: dts: rockchip: Fix rk3399-roc-pc pwm2 pin
dt-bindings: arm: rockchip: Use libretech for roc-pc binding
arm64: dts: rockchip: Use libretech model, compatible for ROC-PC
arm64: dts: rockchip: Rename roc-pc with libretech notation
arm64: dts: rockchip: Rename vcc12v_sys into dc_12v for roc-rk3399-pc
arm64: dts: rockchip: Fix roc-rk3399-pc regulator input rails
.../devicetree/bindings/arm/rockchip.yaml | 11 +++---
arch/arm64/boot/dts/rockchip/Makefile | 2 +-
...dts => rk3399-libretech-roc-rk3399-pc.dts} | 38 ++-
3 files changed, 27 insertions(+), 24 deletions(-)
rename arch/arm64/boot/dts/rockchip/{rk3399-roc-pc.dts =>
rk3399-libretech-roc-rk3399-pc.dts} (95%)
--
2.18.0.321.gffc6fa0e3
Re: [PATCH v3 2/2] powerpc/irq: inline call_do_irq() and call_do_softirq()
Le 18/09/2019 à 18:39, Segher Boessenkool a écrit :
Hi Christophe,
On Wed, Sep 18, 2019 at 03:48:20PM +, Christophe Leroy wrote:
call_do_irq() and call_do_softirq() are quite similar on PPC32 and
PPC64 and are simple enough to be worth inlining.
Inlining them avoids an mflr/mtlr pair plus a save/reload on stack.
But you hardcode the calling sequence in inline asm, which for various
reasons is not a great idea.
+static inline void call_do_irq(struct pt_regs *regs, void *sp)
+{
+ register unsigned long r3 asm("r3") = (unsigned long)regs;
+
+ asm volatile(
+ " "PPC_STLU"1, %2(%1);\n"
+ " mr 1, %1;\n"
+ " bl %3;\n"
+ " "PPC_LL" 1, 0(1);\n" : "+r"(r3) :
+ "b"(sp), "i"(THREAD_SIZE - STACK_FRAME_OVERHEAD), "i"(__do_irq)
:
+ "lr", "xer", "ctr", "memory", "cr0", "cr1", "cr5", "cr6", "cr7",
+ "r0", "r4", "r5", "r6", "r7", "r8", "r9", "r10", "r11", "r12");
+}
I realise the original code had this... Loading the old stack pointer
value back from the stack creates a bottleneck (via the store->load
forwarding it requires). It could just use
addi 1,1,-(%2)
here, which can also be written as
addi 1,1,%n2
(that is portable to all architectures btw).
No, we switched stack before the bl call, we replaced r1 by r3 after
saving r1 into r3 stack. Now we have to restore the original r1.
Please write the "+r"(r3) on the next line? Not on the same line as
the multi-line template. This make things more readable.
I don't know if using functions as an "i" works properly... It probably
does, it's just not something that you see often :-)
What about r2? Various ABIs handle that differently. This might make
it impossible to share implementation between 32-bit and 64-bit for this.
But we could add it to the clobber list worst case, that will always work.
Isn't r2 non-volatile on all ABIs ?
So anyway, it looks to me like it will work. Nice cleanup. Would be
better if you could do the call to __do_irq from C code, but maybe we
cannot have everything ;-)
sparc do it the following way, is there no risk that GCC adds unwanted
code inbetween that is not aware there the stack pointer has changed ?
void do_softirq_own_stack(void)
{
void *orig_sp, *sp = softirq_stack[smp_processor_id()];
sp += THREAD_SIZE - 192 - STACK_BIAS;
__asm__ __volatile__("mov %%sp, %0\n\t"
"mov %1, %%sp"
: "=&r" (orig_sp)
: "r" (sp));
__do_softirq();
__asm__ __volatile__("mov %0, %%sp"
: : "r" (orig_sp));
}
If the above is no risk, then can we do the same on powerpc ?
Reviewed-by: Segher Boessenkool
Thanks for the review.
Christophe
[PATCH v6] perf: Sharing PMU counters across compatible events
This patch tries to enable PMU sharing. To make perf event scheduling
fast, we use special data structures.
An array of "struct perf_event_dup" is added to the perf_event_context,
to remember all the duplicated events under this ctx. All the events
under this ctx has a "dup_id" pointing to its perf_event_dup. Compatible
events under the same ctx share the same perf_event_dup. The following
figure shows a simplified version of the data structure.
ctx -> perf_event_dup -> master
^
|
perf_event /|
|
perf_event /
Connection among perf_event and perf_event_dup are built when events are
added or removed from the ctx. So these are not on the critical path of
schedule or perf_rotate_context().
On the critical paths (add, del read), sharing PMU counters doesn't
increase the complexity. Helper functions event_pmu_[add|del|read]() are
introduced to cover these cases. All these functions have O(1) time
complexity.
We allocate a separate perf_event for perf_event_dup->master. This needs
extra attention, because perf_event_alloc() may sleep. To allocate the
master event properly, a new pointer, tmp_master, is added to perf_event.
tmp_master carries a separate perf_event into list_[add|del]_event().
The master event has valid ->ctx and holds ctx->refcount.
Details about the handling of the master event is added to
include/linux/perf_event.h, before struct perf_event_dup.
Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Alexey Budankov
Cc: Namhyung Kim
Cc: Tejun Heo
Signed-off-by: Song Liu
---
include/linux/perf_event.h | 61
kernel/events/core.c | 294 ++---
2 files changed, 332 insertions(+), 23 deletions(-)
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 61448c19a132..a694e5eee80a 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -722,6 +722,12 @@ struct perf_event {
#endif
struct list_headsb_list;
+
+ /* for PMU sharing */
+ struct perf_event *tmp_master;
+ int dup_id;
+ u64 dup_base_count;
+ u64 dup_base_child_count;
#endif /* CONFIG_PERF_EVENTS */
};
@@ -731,6 +737,58 @@ struct perf_event_groups {
u64 index;
};
+/*
+ * Sharing PMU across compatible events
+ *
+ * If two perf_events in the same perf_event_context are counting same
+ * hardware events (instructions, cycles, etc.), they could share the
+ * hardware PMU counter.
+ *
+ * When a perf_event is added to the ctx (list_add_event), it is compared
+ * against other events in the ctx. If they can share the PMU counter,
+ * a perf_event_dup is allocated to represent the sharing.
+ *
+ * Each perf_event_dup has a virtual master event, which is called by
+ * pmu->add() and pmu->del(). We cannot call perf_event_alloc() in
+ * list_add_event(), so it is allocated and carried by event->tmp_master
+ * into list_add_event().
+ *
+ * Virtual master in different cases/paths:
+ *
+ * < I > perf_event_open() -> close() path:
+ *
+ * 1. Allocated by perf_event_alloc() in sys_perf_event_open();
+ * 2. event->tmp_master->ctx assigned in perf_install_in_context();
+ * 3.a. if used by ctx->dup_events, freed in perf_event_release_kernel();
+ * 3.b. if not used by ctx->dup_events, freed in perf_event_open().
+ *
+ * < II > inherit_event() path:
+ *
+ * 1. Allocated by perf_event_alloc() in inherit_event();
+ * 2. tmp_master->ctx assigned in inherit_event();
+ * 3.a. if used by ctx->dup_events, freed in perf_event_release_kernel();
+ * 3.b. if not used by ctx->dup_events, freed in inherit_event().
+ *
+ * < III > perf_pmu_migrate_context() path:
+ * all dup_events removed during migration (no sharing after the move).
+ *
+ * < IV > perf_event_create_kernel_counter() path:
+ * not supported yet.
+ */
+struct perf_event_dup {
+ /*
+* master event being called by pmu->add() and pmu->del().
+* This event is allocated with perf_event_alloc(). When
+* attached to a ctx, this event should hold ctx->refcount.
+*/
+ struct perf_event *master;
+ /* number of events in the ctx that shares the master */
+ int total_event_count;
+ /* number of active events of the master */
+ int active_event_count;
+};
+
+#define MAX_PERF_EVENT_DUP_PER_CTX 4
/**
* struct perf_event_context - event context structure
*
@@ -791,6 +849,9 @@ struct perf_event_context {
#endif
void*task_ctx_data; /* pmu specific data */
struct rcu_head rcu_head;
+
+ /* for PMU sharing. array is needed for O(1) access */
+ struct perf_event_dup dup_events[MAX_PERF_EVENT_DUP_PER_CTX];
};
/*
diff --git a/kernel/events/core.c b/kernel/eve
[PATCH] Drivers: hv: vmbus: Fix harmless building warnings without CONFIG_PM
If CONFIG_PM is not set, we can comment out these functions to avoid the
below warnings:
drivers/hv/vmbus_drv.c:2208:12: warning: ‘vmbus_bus_resume’ defined but not
used [-Wunused-function]
drivers/hv/vmbus_drv.c:2128:12: warning: ‘vmbus_bus_suspend’ defined but not
used [-Wunused-function]
drivers/hv/vmbus_drv.c:937:12: warning: ‘vmbus_resume’ defined but not used
[-Wunused-function]
drivers/hv/vmbus_drv.c:918:12: warning: ‘vmbus_suspend’ defined but not used
[-Wunused-function]
Fixes: 271b2224d42f ("Drivers: hv: vmbus: Implement suspend/resume for VSC
drivers for hibernation")
Fixes: f53335e3289f ("Drivers: hv: vmbus: Suspend/resume the vmbus itself for
hibernation")
Reported-by: Arnd Bergmann
Signed-off-by: Dexuan Cui
---
drivers/hv/vmbus_drv.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 391f0b225c9a..8bfb36695413 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -912,6 +912,7 @@ static void vmbus_shutdown(struct device *child_device)
drv->shutdown(dev);
}
+#ifdef CONFIG_PM
/*
* vmbus_suspend - Suspend a vmbus device
*/
@@ -949,6 +950,7 @@ static int vmbus_resume(struct device *child_device)
return drv->resume(dev);
}
+#endif /* CONFIG_PM */
/*
* vmbus_device_release - Final callback release of the vmbus child device
@@ -1070,6 +1072,7 @@ void vmbus_on_msg_dpc(unsigned long data)
vmbus_signal_eom(msg, message_type);
}
+#ifdef CONFIG_PM
/*
* Fake RESCIND_CHANNEL messages to clean up hv_sock channels by force for
* hibernation, because hv_sock connections can not persist across hibernation.
@@ -1105,6 +1108,7 @@ static void vmbus_force_channel_rescinded(struct
vmbus_channel *channel)
vmbus_connection.work_queue,
&ctx->work);
}
+#endif /* CONFIG_PM */
/*
* Direct callback for channels using other deferred processing
@@ -2125,6 +2129,7 @@ static int vmbus_acpi_add(struct acpi_device *device)
return ret_val;
}
+#ifdef CONFIG_PM
static int vmbus_bus_suspend(struct device *dev)
{
struct vmbus_channel *channel, *sc;
@@ -2247,6 +2252,7 @@ static int vmbus_bus_resume(struct device *dev)
return 0;
}
+#endif /* CONFIG_PM */
static const struct acpi_device_id vmbus_acpi_device_ids[] = {
{"VMBUS", 0},
--
2.19.1
RE: [PATCH] hv: vmbus: mark PM functions as __maybe_unused
> From: Arnd Bergmann > Sent: Wednesday, September 18, 2019 1:01 PM > > When CONFIG_PM is disabled, we get a couple of harmless warnings: > > drivers/hv/vmbus_drv.c:918:12: error: unused function 'vmbus_suspend' > [-Werror,-Wunused-function] > drivers/hv/vmbus_drv.c:937:12: error: unused function 'vmbus_resume' > [-Werror,-Wunused-function] > drivers/hv/vmbus_drv.c:2128:12: error: unused function 'vmbus_bus_suspend' > [-Werror,-Wunused-function] > drivers/hv/vmbus_drv.c:2208:12: error: unused function 'vmbus_bus_resume' > [-Werror,-Wunused-function] > > Mark these functions __maybe_unused to let gcc drop them silently. Hi Arnd, Thanks for reporting the issue! If CONFIG_PM is not set, IMO it's better to comment out these functions. :-) I'll post a patch for this with you Cc'd. Thanks, -- Dexuan
[PATCH 1/3] arm64: dts: imx8mq: Use correct clock for usdhc's ipg clk
On i.MX8MQ, usdhc's ipg clock is from IMX8MQ_CLK_IPG_ROOT, assign it explicitly instead of using IMX8MQ_CLK_DUMMY. Signed-off-by: Anson Huang --- arch/arm64/boot/dts/freescale/imx8mq.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi index fd42bee..e2c95ad 100644 --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi @@ -850,7 +850,7 @@ "fsl,imx7d-usdhc"; reg = <0x30b4 0x1>; interrupts = ; - clocks = <&clk IMX8MQ_CLK_DUMMY>, + clocks = <&clk IMX8MQ_CLK_IPG_ROOT>, <&clk IMX8MQ_CLK_NAND_USDHC_BUS>, <&clk IMX8MQ_CLK_USDHC1_ROOT>; clock-names = "ipg", "ahb", "per"; @@ -867,7 +867,7 @@ "fsl,imx7d-usdhc"; reg = <0x30b5 0x1>; interrupts = ; - clocks = <&clk IMX8MQ_CLK_DUMMY>, + clocks = <&clk IMX8MQ_CLK_IPG_ROOT>, <&clk IMX8MQ_CLK_NAND_USDHC_BUS>, <&clk IMX8MQ_CLK_USDHC2_ROOT>; clock-names = "ipg", "ahb", "per"; -- 2.7.4
[PATCH 3/3] arm64: dts: imx8mn: Use correct clock for usdhc's ipg clk
On i.MX8MN, usdhc's ipg clock is from IMX8MN_CLK_IPG_ROOT, assign it explicitly instead of using IMX8MN_CLK_DUMMY. Signed-off-by: Anson Huang --- arch/arm64/boot/dts/freescale/imx8mn.dtsi | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi index 6cb6c9c..725a3a3 100644 --- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi @@ -594,7 +594,7 @@ compatible = "fsl,imx8mn-usdhc", "fsl,imx7d-usdhc"; reg = <0x30b4 0x1>; interrupts = ; - clocks = <&clk IMX8MN_CLK_DUMMY>, + clocks = <&clk IMX8MN_CLK_IPG_ROOT>, <&clk IMX8MN_CLK_NAND_USDHC_BUS>, <&clk IMX8MN_CLK_USDHC1_ROOT>; clock-names = "ipg", "ahb", "per"; @@ -610,7 +610,7 @@ compatible = "fsl,imx8mn-usdhc", "fsl,imx7d-usdhc"; reg = <0x30b5 0x1>; interrupts = ; - clocks = <&clk IMX8MN_CLK_DUMMY>, + clocks = <&clk IMX8MN_CLK_IPG_ROOT>, <&clk IMX8MN_CLK_NAND_USDHC_BUS>, <&clk IMX8MN_CLK_USDHC2_ROOT>; clock-names = "ipg", "ahb", "per"; @@ -624,7 +624,7 @@ compatible = "fsl,imx8mn-usdhc", "fsl,imx7d-usdhc"; reg = <0x30b6 0x1>; interrupts = ; - clocks = <&clk IMX8MN_CLK_DUMMY>, + clocks = <&clk IMX8MN_CLK_IPG_ROOT>, <&clk IMX8MN_CLK_NAND_USDHC_BUS>, <&clk IMX8MN_CLK_USDHC3_ROOT>; clock-names = "ipg", "ahb", "per"; -- 2.7.4
[PATCH 2/3] arm64: dts: imx8mm: Use correct clock for usdhc's ipg clk
On i.MX8MM, usdhc's ipg clock is from IMX8MM_CLK_IPG_ROOT, assign it explicitly instead of using IMX8MM_CLK_DUMMY. Signed-off-by: Anson Huang --- arch/arm64/boot/dts/freescale/imx8mm.dtsi | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi index 7c4dcce..8aafad2 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi @@ -694,7 +694,7 @@ compatible = "fsl,imx8mm-usdhc", "fsl,imx7d-usdhc"; reg = <0x30b4 0x1>; interrupts = ; - clocks = <&clk IMX8MM_CLK_DUMMY>, + clocks = <&clk IMX8MM_CLK_IPG_ROOT>, <&clk IMX8MM_CLK_NAND_USDHC_BUS>, <&clk IMX8MM_CLK_USDHC1_ROOT>; clock-names = "ipg", "ahb", "per"; @@ -710,7 +710,7 @@ compatible = "fsl,imx8mm-usdhc", "fsl,imx7d-usdhc"; reg = <0x30b5 0x1>; interrupts = ; - clocks = <&clk IMX8MM_CLK_DUMMY>, + clocks = <&clk IMX8MM_CLK_IPG_ROOT>, <&clk IMX8MM_CLK_NAND_USDHC_BUS>, <&clk IMX8MM_CLK_USDHC2_ROOT>; clock-names = "ipg", "ahb", "per"; @@ -724,7 +724,7 @@ compatible = "fsl,imx8mm-usdhc", "fsl,imx7d-usdhc"; reg = <0x30b6 0x1>; interrupts = ; - clocks = <&clk IMX8MM_CLK_DUMMY>, + clocks = <&clk IMX8MM_CLK_IPG_ROOT>, <&clk IMX8MM_CLK_NAND_USDHC_BUS>, <&clk IMX8MM_CLK_USDHC3_ROOT>; clock-names = "ipg", "ahb", "per"; -- 2.7.4
Re: [PATCH 3/5] ocxl: Tally up the LPC memory on a link & allow it to be mapped
On Wed, 2019-09-18 at 16:02 +0200, Frederic Barrat wrote:
>
> Le 17/09/2019 à 03:42, Alastair D'Silva a écrit :
> > From: Alastair D'Silva
> >
> > Tally up the LPC memory on an OpenCAPI link & allow it to be mapped
> >
> > Signed-off-by: Alastair D'Silva
> > ---
> > drivers/misc/ocxl/core.c | 9 +
> > drivers/misc/ocxl/link.c | 61
> > +++
> > drivers/misc/ocxl/ocxl_internal.h | 42 +
> > 3 files changed, 112 insertions(+)
> >
> > diff --git a/drivers/misc/ocxl/core.c b/drivers/misc/ocxl/core.c
> > index b7a09b21ab36..fdfe4e0a34e1 100644
> > --- a/drivers/misc/ocxl/core.c
> > +++ b/drivers/misc/ocxl/core.c
> > @@ -230,8 +230,17 @@ static int configure_afu(struct ocxl_afu *afu,
> > u8 afu_idx, struct pci_dev *dev)
> > if (rc)
> > goto err_free_pasid;
> >
> > + if (afu->config.lpc_mem_size || afu-
> > >config.special_purpose_mem_size) {
> > + rc = ocxl_link_add_lpc_mem(afu->fn->link,
> > + afu->config.lpc_mem_size + afu-
> > >config.special_purpose_mem_size);
>
> I don't think we should count the special purpose memory, as it's
> not
> meant to be accessed through the GPU mem BAR, but I'll check.
At least for OpenCAPI 3.0, there is no other in-spec way to access the
memory if it is not mapped by the NPU.
>
> What happens when unconfiguring the AFU? We should reduce the range
> (see
> also below). Partial reconfig doesn't seem so far off, so we should
> take
> it into account.
>
The mapping is left until the last AFU on the link offlines it's
memory, at which point we clear the mapping from the NPU.
>
> > + if (rc)
> > + goto err_free_mmio;
> > + }
> > +
> > return 0;
> >
> > +err_free_mmio:
> > + unmap_mmio_areas(afu);
> > err_free_pasid:
> > reclaim_afu_pasid(afu);
> > err_free_actag:
> > diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c
> > index 58d111afd9f6..2874811a4398 100644
> > --- a/drivers/misc/ocxl/link.c
> > +++ b/drivers/misc/ocxl/link.c
> > @@ -84,6 +84,11 @@ struct ocxl_link {
> > int dev;
> > atomic_t irq_available;
> > struct spa *spa;
> > + struct mutex lpc_mem_lock;
> > + u64 lpc_mem_sz; /* Total amount of LPC memory presented on the
> > link */
> > + u64 lpc_mem;
> > + int lpc_consumers;
> > +
> > void *platform_data;
> > };
> > static struct list_head links_list = LIST_HEAD_INIT(links_list);
> > @@ -396,6 +401,8 @@ static int alloc_link(struct pci_dev *dev, int
> > PE_mask, struct ocxl_link **out_l
> > if (rc)
> > goto err_spa;
> >
> > + mutex_init(&link->lpc_mem_lock);
> > +
> > /* platform specific hook */
> > rc = pnv_ocxl_spa_setup(dev, link->spa->spa_mem, PE_mask,
> > &link->platform_data);
> > @@ -711,3 +718,57 @@ void ocxl_link_free_irq(void *link_handle, int
> > hw_irq)
> > atomic_inc(&link->irq_available);
> > }
> > EXPORT_SYMBOL_GPL(ocxl_link_free_irq);
> > +
> > +int ocxl_link_add_lpc_mem(void *link_handle, u64 size)
> > +{
> > + struct ocxl_link *link = (struct ocxl_link *) link_handle;
> > +
> > + u64 orig_size;
> > + bool good = false;
> > +
> > + mutex_lock(&link->lpc_mem_lock);
> > + orig_size = link->lpc_mem_sz;
> > + link->lpc_mem_sz += size;
>
>
> We have a choice to make here:
> 1. either we only support one LPC memory-carrying AFU (and the above
> is
> overkill)
> 2. or we support multiple AFUs with LPC memory (on the same
> function),
> but then I think the above is too simple.
>
> From the opencapi spec, each AFU can define a chunk of memory with
> a
> starting address and a size. There's no rule which says they have to
> be
> contiguous. There's no rule which says it must start at 0. So to
> support
> multiple AFUs with LPC memory, we should record the current maximum
> range instead of just the global size. Ultimately, we need to tell
> the
> NPU the range of permissible addresses. It starts at 0, so we need
> to
> take into account any intial offset and holes.
>
> I would go for option 2, to at least be consistent within ocxl and
> support multiple AFUs. Even though I don't think we'll see FPGA
> images
> with multiple AFUs with LPC memory any time soon.
>
Ill rework this to take an offset & size, the NPU will map from the
base address up to the largest offset + size provided across all AFUs
on the link.
>
> > + good = orig_size < link->lpc_mem_sz;
> > + mutex_unlock(&link->lpc_mem_lock);
> > +
> > + // Check for overflow
> > + return (good) ? 0 : -EINVAL;
> > +}
> > +EXPORT_SYMBOL_GPL(ocxl_link_add_lpc_mem);
>
> Do the symbol really need to be exported? IIUC, the next patch
> defines a
> higher level ocxl_afu_map_lpc_mem() which is meant to be called by a
> calling driver.
>
No, I'll remove it.
>
> > +
> > +u64 ocxl_link_lpc_map(void *link_handle, struct pci_dev *pdev)
> > +{
> > + struct ocxl_link *link = (struct ocxl_lin
Re: [PATCH V2 2/2] mm/pgtable/debug: Add test validating architecture page table helpers
On 09/18/2019 09:56 PM, Christophe Leroy wrote:
>
>
> Le 18/09/2019 à 07:04, Anshuman Khandual a écrit :
>>
>>
>> On 09/13/2019 03:31 PM, Christophe Leroy wrote:
>>>
>>>
>>> Le 13/09/2019 à 11:02, Anshuman Khandual a écrit :
>> +#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)
>
> #ifdefs have to be avoided as much as possible, see below
Yeah but it has been bit difficult to avoid all these $ifdef because of the
availability (or lack of it) for all these pgtable helpers in various
config
combinations on all platforms.
>>>
>>> As far as I can see these pgtable helpers should exist everywhere at least
>>> via asm-generic/ files.
>>
>> But they might not actually do the right thing.
>>
>>>
>>> Can you spot a particular config which fails ?
>>
>> Lets consider the following example (after removing the $ifdefs around it)
>> which though builds successfully but fails to pass the intended test. This
>> is with arm64 config 4K pages sizes with 39 bits VA space which ends up
>> with a 3 level page table arrangement.
>>
>> static void __init p4d_clear_tests(p4d_t *p4dp)
>> {
>> p4d_t p4d = READ_ONCE(*p4dp);
>
> My suggestion was not to completely drop the #ifdef but to do like you did in
> pgd_clear_tests() for instance, ie to add the following test on top of the
> function:
>
> if (mm_pud_folded(mm) || is_defined(__ARCH_HAS_5LEVEL_HACK))
> return;
>
Sometimes this does not really work. On some platforms, combination of
__PAGETABLE_PUD_FOLDED and __ARCH_HAS_5LEVEL_HACK decide whether the
helpers such as __pud() or __pgd() is even available for that platform.
Ideally it should have been through generic falls backs in include/*/
but I guess there might be bugs on the platform or it has not been
changed to adopt 5 level page table framework with required folding
macros etc.
>>
>> p4d = __p4d(p4d_val(p4d) | RANDOM_ORVALUE);
>> WRITE_ONCE(*p4dp, p4d);
>> p4d_clear(p4dp);
>> p4d = READ_ONCE(*p4dp);
>> WARN_ON(!p4d_none(p4d));
>> }
>>
>> The following test hits an error at WARN_ON(!p4d_none(p4d))
>>
>> [ 16.757333] [ cut here ]
>> [ 16.758019] WARNING: CPU: 11 PID: 1 at mm/arch_pgtable_test.c:187
>> arch_pgtable_tests_init+0x24c/0x474
>> [ 16.759455] Modules linked in:
>> [ 16.759952] CPU: 11 PID: 1 Comm: swapper/0 Not tainted
>> 5.3.0-next-20190916-5-g61c218153bb8-dirty #222
>> [ 16.761449] Hardware name: linux,dummy-virt (DT)
>> [ 16.762185] pstate: 0045 (nzcv daif +PAN -UAO)
>> [ 16.762964] pc : arch_pgtable_tests_init+0x24c/0x474
>> [ 16.763750] lr : arch_pgtable_tests_init+0x174/0x474
>> [ 16.764534] sp : ffc011d7bd50
>> [ 16.765065] x29: ffc011d7bd50 x28: 1756bac0
>> [ 16.765908] x27: ff85ddaf3000 x26: 02e8
>> [ 16.766767] x25: ffc0111ce000 x24: ff85ddaf32e8
>> [ 16.767606] x23: ff85ddaef278 x22: 0045cc844000
>> [ 16.768445] x21: 00065daef003 x20: 1754
>> [ 16.769283] x19: ff85ddb6 x18: 0014
>> [ 16.770122] x17: 980426bb x16: 698594c6
>> [ 16.770976] x15: 66e25a88 x14:
>> [ 16.771813] x13: 1754 x12: 000a
>> [ 16.772651] x11: ff85fcfd0a40 x10: 0001
>> [ 16.773488] x9 : 0008 x8 : ffc01143ab26
>> [ 16.774336] x7 : x6 :
>> [ 16.775180] x5 : x4 :
>> [ 16.776018] x3 : 1756bbe8 x2 : 00065daeb003
>> [ 16.776856] x1 : 0065daeb x0 : f000
>> [ 16.777693] Call trace:
>> [ 16.778092] arch_pgtable_tests_init+0x24c/0x474
>> [ 16.778843] do_one_initcall+0x74/0x1b0
>> [ 16.779458] kernel_init_freeable+0x1cc/0x290
>> [ 16.780151] kernel_init+0x10/0x100
>> [ 16.780710] ret_from_fork+0x10/0x18
>> [ 16.781282] ---[ end trace 042e6c40c0a3b038 ]---
>>
>> On arm64 (4K page size|39 bits VA|3 level page table)
>>
>> #elif CONFIG_PGTABLE_LEVELS == 3 /* Applicable here */
>> #define __ARCH_USE_5LEVEL_HACK
>> #include
>>
>> Which pulls in
>>
>> #include
>>
>> which pulls in
>>
>> #include
>>
>> which defines
>>
>> static inline int p4d_none(p4d_t p4d)
>> {
>> return 0;
>> }
>>
>> which will invariably trigger WARN_ON(!p4d_none(p4d)).
>>
>> Similarly for next test p4d_populate_tests() which will always be
>> successful because p4d_bad() invariably returns negative.
>>
>> static inline int p4d_bad(p4d_t p4d)
>> {
>> return 0;
>> }
>>
>> static void __init p4d_populate_tests(struct mm_struct *mm, p4d_t *p4dp,
>> pud_t *pudp)
>> {
>> p4d_t p4d;
>>
>> /*
>> * This entry points to next level page table page.
>> * Hence this must not qualify as p4d_bad().
>> */
>> pud_clear(pudp);
>> p4d_clear(p4dp);
>>
RE: [PATCH] devfreq: Make log message more explicit when devfreq device already exists
>Before creating a new devfreq device devfreq_add_device() checks
>if there is already a devfreq dev associated with the requesting
>device (parent). If that's the case the function rejects to create
>another devfreq dev for that parent and logs an error. The error
>message is very unspecific, make it a bit more explicit.
>
>Signed-off-by: Matthias Kaehlcke
>---
> drivers/devfreq/devfreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>index ab22bf8a12d6..0e2dd734ab58 100644
>--- a/drivers/devfreq/devfreq.c
>+++ b/drivers/devfreq/devfreq.c
>@@ -625,7 +625,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
> devfreq = find_device_devfreq(dev);
> mutex_unlock(&devfreq_list_lock);
> if (!IS_ERR(devfreq)) {
>- dev_err(dev, "%s: Unable to create devfreq for the device.\n",
>+ dev_err(dev, "%s: devfreq device already exists!\n",
Yes, this is more helpful! Thanks!
Acked-by: MyungJoo Ham
Re: [PATCH] mm: Support memblock alloc on the exact node for sparse_buffer_init()
Hi,
On Wed, Sep 18, 2019 at 12:22:29PM +0800, Yunfeng Ye wrote:
> Currently, when memblock_find_in_range_node() fail on the exact node, it
> will use %NUMA_NO_NODE to find memblock from other nodes. At present,
> the work is good, but when the large memory is insufficient and the
> small memory is enough, we want to allocate the small memory of this
> node first, and do not need to allocate large memory from other nodes.
>
> In sparse_buffer_init(), it will prepare large chunks of memory for page
> structure. The page management structure requires a lot of memory, but
> if the node does not have enough memory, it can be converted to a small
> memory allocation without having to allocate it from other nodes.
>
> Add %MEMBLOCK_ALLOC_EXACT_NODE flag for this situation. Normally, the
> behavior is the same with %MEMBLOCK_ALLOC_ACCESSIBLE, only that it will
> not allocate from other nodes when a single node fails to allocate.
>
> If large contiguous block memory allocated fail in sparse_buffer_init(),
> it will allocates small block memmory section by section later.
Did you see the sparse_buffer_init() actually falling back to allocate from a
different node? If a node does not have enough memory to hold it's own
memory map, filling only it with parts of the memory map will not make such
node usable.
> Signed-off-by: Yunfeng Ye
> ---
> include/linux/memblock.h | 1 +
> mm/memblock.c| 3 ++-
> mm/sparse.c | 2 +-
> 3 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index f491690..9a81d9c 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -339,6 +339,7 @@ static inline int memblock_get_region_node(const struct
> memblock_region *r)
> #define MEMBLOCK_ALLOC_ANYWHERE (~(phys_addr_t)0)
> #define MEMBLOCK_ALLOC_ACCESSIBLE0
> #define MEMBLOCK_ALLOC_KASAN 1
> +#define MEMBLOCK_ALLOC_EXACT_NODE2
>
> /* We are using top down, so it is safe to use 0 here */
> #define MEMBLOCK_LOW_LIMIT 0
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 7d4f61a..dbd52c3c 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -277,6 +277,7 @@ static phys_addr_t __init_memblock
> memblock_find_in_range_node(phys_addr_t size,
>
> /* pump up @end */
> if (end == MEMBLOCK_ALLOC_ACCESSIBLE ||
> + end == MEMBLOCK_ALLOC_EXACT_NODE ||
> end == MEMBLOCK_ALLOC_KASAN)
> end = memblock.current_limit;
>
> @@ -1365,7 +1366,7 @@ static phys_addr_t __init
> memblock_alloc_range_nid(phys_addr_t size,
> if (found && !memblock_reserve(found, size))
> goto done;
>
> - if (nid != NUMA_NO_NODE) {
> + if (end != MEMBLOCK_ALLOC_EXACT_NODE && nid != NUMA_NO_NODE) {
> found = memblock_find_in_range_node(size, align, start,
> end, NUMA_NO_NODE,
> flags);
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 72f010d..828db46 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -477,7 +477,7 @@ static void __init sparse_buffer_init(unsigned long size,
> int nid)
> sparsemap_buf =
> memblock_alloc_try_nid_raw(size, PAGE_SIZE,
> addr,
> - MEMBLOCK_ALLOC_ACCESSIBLE, nid);
> + MEMBLOCK_ALLOC_EXACT_NODE, nid);
> sparsemap_buf_end = sparsemap_buf + size;
> }
>
> --
> 2.7.4.huawei.3
>
>
--
Sincerely yours,
Mike.
Re: [PATCH] staging: mt7621-pci-phy: Use devm_platform_ioremap_resource() in mt7621_pci_phy_probe()
Hi Markus,
Thanks for the patch. It looks good to me.
On Wed, Sep 18, 2019 at 9:12 PM Markus Elfring wrote:
>
> From: Markus Elfring
> Date: Wed, 18 Sep 2019 21:01:32 +0200
>
> Simplify this function implementation by using a known wrapper function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
> ---
> drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c | 10 +-
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c
> b/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c
> index d2a07f145143..6ca4a33d13c3 100644
> --- a/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c
> +++ b/drivers/staging/mt7621-pci-phy/pci-mt7621-phy.c
> @@ -324,7 +324,6 @@ static int mt7621_pci_phy_probe(struct platform_device
> *pdev)
> const struct soc_device_attribute *attr;
> struct phy_provider *provider;
> struct mt7621_pci_phy *phy;
> - struct resource *res;
> int port;
> void __iomem *port_base;
>
> @@ -344,14 +343,7 @@ static int mt7621_pci_phy_probe(struct platform_device
> *pdev)
>
> phy->dev = dev;
> platform_set_drvdata(pdev, phy);
> -
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - dev_err(dev, "failed to get address resource\n");
> - return -ENXIO;
> - }
> -
> - port_base = devm_ioremap_resource(dev, res);
> + port_base = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(port_base)) {
> dev_err(dev, "failed to remap phy regs\n");
> return PTR_ERR(port_base);
> --
> 2.23.0
>
Reviewed-by: Sergio Paracuellos
RE: [EXT] Re: [v4 2/2] clk: ls1028a: Add clock driver for Display output interface
> -Original Message-
> From: Stephen Boyd
> Sent: 2019年9月19日 1:01
> To: devicet...@vger.kernel.org; linux-...@vger.kernel.org;
> linux-de...@linux.nxdi.nxp.com; linux-kernel@vger.kernel.org; Mark Rutland
> ; Michael Turquette ;
> Rob Herring ; Wen He
> Cc: Leo Li ; liviu.du...@arm.com
> Subject: RE: [EXT] Re: [v4 2/2] clk: ls1028a: Add clock driver for Display
> output
> interface
>
>
> Quoting Wen He (2019-09-18 02:20:26)
> > > -Original Message-
> > > From: Stephen Boyd Quoting Wen He (2019-08-29
> > > 03:59:19)
> > > > diff --git a/drivers/clk/clk-plldig.c b/drivers/clk/clk-plldig.c
> > > > new file mode 100644 index ..d3239bcf59de
> > > > --- /dev/null
> > > > +++ b/drivers/clk/clk-plldig.c
> > > > @@ -0,0 +1,298 @@
> [...]
> >
> > >
> > > > +
> > > > +/* Maximum of the divider */
> > > > +#define MAX_RFDPHI1 63
> > > > +
> > > > +/* Best value of multiplication factor divider */
> > > > +#define PLLDIG_DEFAULE_MULT 44
> > > > +
> > > > +/*
> > > > + * Clock configuration relationship between the PHI1
> > > > +frequency(fpll_phi) and
> > > > + * the output frequency of the PLL is determined by the PLLDV,
> > > > +according to
> > > > + * the following equation:
> > > > + * fpll_phi = (pll_ref * mfd) / div_rfdphi1 */ struct
> > > > +plldig_phi1_param {
> > > > + unsigned long rate;
> > > > + unsigned int rfdphi1;
> > > > + unsigned int mfd;
> > > > +};
> > > > +
> > > > +enum plldig_phi1_freq_range {
> > > > + PHI1_MIN= 2700U,
> > > > + PHI1_MAX= 6U
> > > > +};
> > >
> > > Please just inline these values in the one place they're used.
> > >
> > > > +
> > > > +struct clk_plldig {
> > > > + struct clk_hw hw;
> > > > + void __iomem *regs;
> > > > + struct device *dev;
> > >
> > > Please remove this, it is unused.
> >
> > It is used for probe.
>
> Use a local variable and don't store it away forever in the struct.
>
Understand, will remove it.
> > >
> > > > +
> > > > + val = readl(data->regs + PLLDIG_REG_PLLDV);
> > > > + val = phi1_param.mfd;
> > > > + rfdphi1 = phi1_param.rfdphi1;
> > > > + val |= rfdphi1;
> > > > +
> > > > + writel(val, data->regs + PLLDIG_REG_PLLDV);
> > > > +
> > > > + /* delay 200us make sure that old lock state is cleared */
> > > > + udelay(200);
> > > > +
> > > > + /* Wait until PLL is locked or timeout (maximum 1000 usecs) */
> > > > + ret = readl_poll_timeout_atomic(data->regs +
> > > > + PLLDIG_REG_PLLSR,
> > > cond,
> > > > + cond &
> PLLDIG_LOCK_MASK,
> > > 0,
> > > > + USEC_PER_MSEC);
> > > > +
> > > > + return ret;
> > >
> > > Just return readl_poll_timeout_atomic(...) here.
> >
> > Maybe use below code will to best describes.
> >
> > If (ret)
> > return -ETIMEOUT;
> >
> > return 0;
>
> No, just return readl_poll_timeout_atomic().
Understand, I will send next version patch for this.
Thanks && Best Regards,
Wen
Re: [PATCH] [RFC] vmscan.c: add a sysctl entry for controlling memory reclaim IO congestion_wait length
On Thu, Sep 19, 2019 at 10:33:10AM +0800, Lin Feng wrote: > On 9/18/19 20:33, Michal Hocko wrote: > > I absolutely agree here. From you changelog it is also not clear what is > > the underlying problem. Both congestion_wait and wait_iff_congested > > should wake up early if the congestion is handled. Is this not the case? > > For now I don't know why, codes seem should work as you said, maybe I need to > trace more of the internals. > But weird thing is that once I set the people-disliked-tunable iowait > drop down instantly, this is contradictory to the code design. Yes, this is quite strange. If setting a smaller timeout makes a difference, that indicates we're not waking up soon enough. I see two possibilities; one is that a wakeup is missing somewhere -- ie the conditions under which we call clear_wb_congested() are wrong. Or we need to wake up sooner. Umm. We have clear_wb_congested() called from exactly one spot -- clear_bdi_congested(). That is only called from: drivers/block/pktcdvd.c fs/ceph/addr.c fs/fuse/control.c fs/fuse/dev.c fs/nfs/write.c Jens, is something supposed to be calling clear_bdi_congested() in the block layer? blk_clear_congested() used to exist until October 29th last year. Or is something else supposed to be waking up tasks that are sleeping on congestion?
Re: [PATCH v3 1/5] powerpc: Allow flush_icache_range to work across ranges >4GB
On Thu, 2019-09-19 at 13:43 +1000, Michael Ellerman wrote: > "Alastair D'Silva" writes: > > From: Alastair D'Silva > > > > When calling flush_icache_range with a size >4GB, we were masking > > off the upper 32 bits, so we would incorrectly flush a range > > smaller > > than intended. > > > > __kernel_sync_dicache in the 64 bit VDSO has the same bug. > > Please fix that in a separate patch. > > Your subject doesn't mention __kernel_sync_dicache(), and also the > two > changes backport differently, so it's better if they're done as > separate > patches. > Ok. > cheers > > > This patch replaces the 32 bit shifts with 64 bit ones, so that > > the full size is accounted for. > > > > Signed-off-by: Alastair D'Silva > > Cc: sta...@vger.kernel.org > > --- > > arch/powerpc/kernel/misc_64.S | 4 ++-- > > arch/powerpc/kernel/vdso64/cacheflush.S | 4 ++-- > > 2 files changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/arch/powerpc/kernel/misc_64.S > > b/arch/powerpc/kernel/misc_64.S > > index b55a7b4cb543..9bc0aa9aeb65 100644 > > --- a/arch/powerpc/kernel/misc_64.S > > +++ b/arch/powerpc/kernel/misc_64.S > > @@ -82,7 +82,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) > > subfr8,r6,r4/* compute length */ > > add r8,r8,r5/* ensure we get enough */ > > lwz r9,DCACHEL1LOGBLOCKSIZE(r10)/* Get log-2 of cache block > > size */ > > - srw.r8,r8,r9/* compute line count */ > > + srd.r8,r8,r9/* compute line count */ > > beqlr /* nothing to do? */ > > mtctr r8 > > 1: dcbst 0,r6 > > @@ -98,7 +98,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) > > subfr8,r6,r4/* compute length */ > > add r8,r8,r5 > > lwz r9,ICACHEL1LOGBLOCKSIZE(r10)/* Get log-2 of Icache > > block size */ > > - srw.r8,r8,r9/* compute line count */ > > + srd.r8,r8,r9/* compute line count */ > > beqlr /* nothing to do? */ > > mtctr r8 > > 2: icbi0,r6 > > diff --git a/arch/powerpc/kernel/vdso64/cacheflush.S > > b/arch/powerpc/kernel/vdso64/cacheflush.S > > index 3f92561a64c4..526f5ba2593e 100644 > > --- a/arch/powerpc/kernel/vdso64/cacheflush.S > > +++ b/arch/powerpc/kernel/vdso64/cacheflush.S > > @@ -35,7 +35,7 @@ V_FUNCTION_BEGIN(__kernel_sync_dicache) > > subfr8,r6,r4/* compute length */ > > add r8,r8,r5/* ensure we get enough */ > > lwz r9,CFG_DCACHE_LOGBLOCKSZ(r10) > > - srw.r8,r8,r9/* compute line count */ > > + srd.r8,r8,r9/* compute line count */ > > crclr cr0*4+so > > beqlr /* nothing to do? */ > > mtctr r8 > > @@ -52,7 +52,7 @@ V_FUNCTION_BEGIN(__kernel_sync_dicache) > > subfr8,r6,r4/* compute length */ > > add r8,r8,r5 > > lwz r9,CFG_ICACHE_LOGBLOCKSZ(r10) > > - srw.r8,r8,r9/* compute line count */ > > + srd.r8,r8,r9/* compute line count */ > > crclr cr0*4+so > > beqlr /* nothing to do? */ > > mtctr r8 > > -- > > 2.21.0 -- Alastair D'Silva Open Source Developer Linux Technology Centre, IBM Australia mob: 0423 762 819
Re: [PATCH v3 1/5] powerpc: Allow flush_icache_range to work across ranges >4GB
"Alastair D'Silva" writes: > From: Alastair D'Silva > > When calling flush_icache_range with a size >4GB, we were masking > off the upper 32 bits, so we would incorrectly flush a range smaller > than intended. > > __kernel_sync_dicache in the 64 bit VDSO has the same bug. Please fix that in a separate patch. Your subject doesn't mention __kernel_sync_dicache(), and also the two changes backport differently, so it's better if they're done as separate patches. cheers > This patch replaces the 32 bit shifts with 64 bit ones, so that > the full size is accounted for. > > Signed-off-by: Alastair D'Silva > Cc: sta...@vger.kernel.org > --- > arch/powerpc/kernel/misc_64.S | 4 ++-- > arch/powerpc/kernel/vdso64/cacheflush.S | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S > index b55a7b4cb543..9bc0aa9aeb65 100644 > --- a/arch/powerpc/kernel/misc_64.S > +++ b/arch/powerpc/kernel/misc_64.S > @@ -82,7 +82,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) > subfr8,r6,r4/* compute length */ > add r8,r8,r5/* ensure we get enough */ > lwz r9,DCACHEL1LOGBLOCKSIZE(r10)/* Get log-2 of cache block > size */ > - srw.r8,r8,r9/* compute line count */ > + srd.r8,r8,r9/* compute line count */ > beqlr /* nothing to do? */ > mtctr r8 > 1: dcbst 0,r6 > @@ -98,7 +98,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) > subfr8,r6,r4/* compute length */ > add r8,r8,r5 > lwz r9,ICACHEL1LOGBLOCKSIZE(r10)/* Get log-2 of Icache block > size */ > - srw.r8,r8,r9/* compute line count */ > + srd.r8,r8,r9/* compute line count */ > beqlr /* nothing to do? */ > mtctr r8 > 2: icbi0,r6 > diff --git a/arch/powerpc/kernel/vdso64/cacheflush.S > b/arch/powerpc/kernel/vdso64/cacheflush.S > index 3f92561a64c4..526f5ba2593e 100644 > --- a/arch/powerpc/kernel/vdso64/cacheflush.S > +++ b/arch/powerpc/kernel/vdso64/cacheflush.S > @@ -35,7 +35,7 @@ V_FUNCTION_BEGIN(__kernel_sync_dicache) > subfr8,r6,r4/* compute length */ > add r8,r8,r5/* ensure we get enough */ > lwz r9,CFG_DCACHE_LOGBLOCKSZ(r10) > - srw.r8,r8,r9/* compute line count */ > + srd.r8,r8,r9/* compute line count */ > crclr cr0*4+so > beqlr /* nothing to do? */ > mtctr r8 > @@ -52,7 +52,7 @@ V_FUNCTION_BEGIN(__kernel_sync_dicache) > subfr8,r6,r4/* compute length */ > add r8,r8,r5 > lwz r9,CFG_ICACHE_LOGBLOCKSZ(r10) > - srw.r8,r8,r9/* compute line count */ > + srd.r8,r8,r9/* compute line count */ > crclr cr0*4+so > beqlr /* nothing to do? */ > mtctr r8 > -- > 2.21.0
[PATCH] perf/probe: Skip same probe address
Fix to skip making a same probe address on given line.
Since dwarf line info contains several entries for one line
with different column, perf probe will make a different
probe on same address if user specifies a probe point by
"function:line" or "file:line".
e.g.
$ perf probe -D kernel_read:8
p:probe/kernel_read_L8 kernel_read+39
p:probe/kernel_read_L8_1 kernel_read+39
This skips such duplicated probe address.
Signed-off-by: Masami Hiramatsu
---
tools/perf/util/probe-finder.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
index 025fc4491993..02ca95deaf2c 100644
--- a/tools/perf/util/probe-finder.c
+++ b/tools/perf/util/probe-finder.c
@@ -1244,6 +1244,17 @@ static int expand_probe_args(Dwarf_Die *sc_die, struct
probe_finder *pf,
return n;
}
+static bool trace_event_finder_overlap(struct trace_event_finder *tf)
+{
+ int i;
+
+ for (i = 0; i < tf->ntevs; i++) {
+ if (tf->pf.addr == tf->tevs[i].point.address)
+ return true;
+ }
+ return false;
+}
+
/* Add a found probe point into trace event list */
static int add_probe_trace_event(Dwarf_Die *sc_die, struct probe_finder *pf)
{
@@ -1254,6 +1265,14 @@ static int add_probe_trace_event(Dwarf_Die *sc_die,
struct probe_finder *pf)
struct perf_probe_arg *args = NULL;
int ret, i;
+ /*
+* For some reason (e.g. different column assigned to same address)
+* This callback can be called with the address which already passed.
+* Ignore it first.
+*/
+ if (trace_event_finder_overlap(tf))
+ return 0;
+
/* Check number of tevs */
if (tf->ntevs == tf->max_tevs) {
pr_warning("Too many( > %d) probe point found.\n",
Re: [PATCH v2] serial: sprd: Add polling IO support
Baolin Wang 于2019年9月19日周四 上午11:21写道：
>
> Hi,
>
> On Thu, 19 Sep 2019 at 11:10, Lanqing Liu wrote:
> >
> > In order to access the UART without the interrupts, the kernel uses
> > the basic polling methods for IO with the device. With these methods
> > implemented, it is now possible to enable kgdb during early boot over
> > serial.
> >
> > Signed-off-by: Lanqing Liu
> > ---
> > Change from v1:
> > - Add poll_init() support.
>
> Looks good to me and the KGDB can work well on my board, so feel free
> to add my tags:
> Reviewed-by: Baolin Wang
> Tested-by: Baolin Wang
>
ok, thanks
> > ---
> > drivers/tty/serial/sprd_serial.c | 33 +
> > 1 file changed, 33 insertions(+)
> >
> > diff --git a/drivers/tty/serial/sprd_serial.c
> > b/drivers/tty/serial/sprd_serial.c
> > index 73d71a4..d833160 100644
> > --- a/drivers/tty/serial/sprd_serial.c
> > +++ b/drivers/tty/serial/sprd_serial.c
> > @@ -911,6 +911,34 @@ static void sprd_pm(struct uart_port *port, unsigned
> > int state,
> > }
> > }
> >
> > +#ifdef CONFIG_CONSOLE_POLL
> > +static int sprd_poll_init(struct uart_port *port)
> > +{
> > + if (port->state->pm_state != UART_PM_STATE_ON) {
> > + sprd_pm(port, UART_PM_STATE_ON, 0);
> > + port->state->pm_state = UART_PM_STATE_ON;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int sprd_poll_get_char(struct uart_port *port)
> > +{
> > + while (!(serial_in(port, SPRD_STS1) & SPRD_RX_FIFO_CNT_MASK))
> > + cpu_relax();
> > +
> > + return serial_in(port, SPRD_RXD);
> > +}
> > +
> > +static void sprd_poll_put_char(struct uart_port *port, unsigned char ch)
> > +{
> > + while (serial_in(port, SPRD_STS1) & SPRD_TX_FIFO_CNT_MASK)
> > + cpu_relax();
> > +
> > + serial_out(port, SPRD_TXD, ch);
> > +}
> > +#endif
> > +
> > static const struct uart_ops serial_sprd_ops = {
> > .tx_empty = sprd_tx_empty,
> > .get_mctrl = sprd_get_mctrl,
> > @@ -928,6 +956,11 @@ static void sprd_pm(struct uart_port *port, unsigned
> > int state,
> > .config_port = sprd_config_port,
> > .verify_port = sprd_verify_port,
> > .pm = sprd_pm,
> > +#ifdef CONFIG_CONSOLE_POLL
> > + .poll_init = sprd_poll_init,
> > + .poll_get_char = sprd_poll_get_char,
> > + .poll_put_char = sprd_poll_put_char,
> > +#endif
> > };
> >
> > #ifdef CONFIG_SERIAL_SPRD_CONSOLE
> > --
> > 1.9.1
> >
>
>
> --
> Baolin Wang
> Best Regards
Re: [PATCH v3 3/3] HID: core: fix dmesg flooding if report field larger than 32bit
Thanks!
It means a lot to have this accepted.
I actually started working on it, thinking "how hard can it be to
increase the size of a data structure"? It only has to be forward
compatible anyway.
My gut feeling is the existing code is working way too hard to do what
should be a memcpy, and the impulse to "fix" it is strong, despite my
absolute lack of usb-hid experience.
But the history of this little bit of code is already fraught with
complaints about big endian breakage.
I'm tempted to make it much simpler for size>32 bits (fix it only for
future users), or just way simpler for little endian,
But what do I know about usb and big endian? I sure don't have the
equipment to test it. And I worry a little I might be forgetting some
oddball non-byte-aligned data structure, which the spec would
theoretically allow.
Perhaps I'll have to time and courage to take another stab.
~Joshua
On Wed, Sep 18, 2019 at 11:35 AM Benjamin Tissoires
wrote:
>
> On Thu, Aug 29, 2019 at 1:26 AM Joshua Clayton
> wrote:
> >
> > ping?
> > I'd love to see this get in.
> > with distro kernel I have effectively no dmesg due to this issue
>
> Apologies for the delay.
>
> I really thought we should find a better way of fixing this, until I
> got a laptop affected by it. This series is a must have.
>
> Applied to for-5.4/core
>
> Cheers,
> Benjamin
>
> >
> > On Mon, Aug 12, 2019 at 9:20 AM wrote:
> > >
> > > From: Joshua Clayton
> > >
> > > Only warn once of oversize hid report value field
> > >
> > > On HP spectre x360 convertible the message:
> > > hid-sensor-hub 001F:8087:0AC2.0002: hid_field_extract() called with n
> > > (192) > 32! (kworker/1:2)
> > > is continually printed many times per second, crowding out all else.
> > > Protect dmesg by printing the warning only one time.
> > >
> > > The size of the hid report field data structure should probably be
> > > increased.
> > > The data structure is treated as a u32 in Linux, but an unlimited number
> > > of bits in the USB hid spec, so there is some rearchitecture needed now
> > > that
> > > devices are sending more than 32 bits.
> > >
> > > Signed-off-by: Joshua Clayton
> > >
> > > diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> > > index 210b81a56e1a..3eaee2c37931 100644
> > > --- a/drivers/hid/hid-core.c
> > > +++ b/drivers/hid/hid-core.c
> > > @@ -1311,8 +1311,8 @@ u32 hid_field_extract(const struct hid_device *hid,
> > > u8 *report,
> > > unsigned offset, unsigned n)
> > > {
> > > if (n > 32) {
> > > - hid_warn(hid, "hid_field_extract() called with n (%d) >
> > > 32! (%s)\n",
> > > -n, current->comm);
> > > + hid_warn_once(hid, "%s() called with n (%d) > 32! (%s)\n",
> > > + __func__, n, current->comm);
> > > n = 32;
> > > }
> > >
> > > --
> > > 2.21.0
> > >
>
Re: [PATCH v2 3/6] platform/x86: huawei-wmi: Implement huawei wmi management
Hi Ayman,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[cannot apply to v5.3 next-20190918]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Ayman-Bagabas/platform-x86-Huawei-WMI-laptop-extras-driver/20190919-090022
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
In file included from include/uapi/linux/posix_types.h:5:0,
from include/uapi/linux/types.h:14,
from include/linux/compiler.h:180,
from include/linux/ioport.h:13,
from include/linux/acpi.h:12,
from drivers/platform/x86/huawei-wmi.c:8:
drivers/platform/x86/huawei-wmi.c: In function 'huawei_wmi_micmute_led_set':
>> include/linux/stddef.h:8:14: warning: passing argument 3 of 'huawei_wmi_cmd'
>> makes integer from pointer without a cast [-Wint-conversion]
#define NULL ((void *)0)
^
>> drivers/platform/x86/huawei-wmi.c:290:40: note: in expansion of macro 'NULL'
return huawei_wmi_cmd(arg.cmd, NULL, NULL);
^~~~
drivers/platform/x86/huawei-wmi.c:161:12: note: expected 'size_t {aka long
unsigned int}' but argument is of type 'void *'
static int huawei_wmi_cmd(u64 arg, u8 *buf, size_t buflen)
^~
vim +/huawei_wmi_cmd +8 include/linux/stddef.h
^1da177e4c3f41 Linus Torvalds 2005-04-16 6
^1da177e4c3f41 Linus Torvalds 2005-04-16 7 #undef NULL
^1da177e4c3f41 Linus Torvalds 2005-04-16 @8 #define NULL ((void *)0)
6e218287432472 Richard Knutsson 2006-09-30 9
:: The code at line 8 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2
:: TO: Linus Torvalds
:: CC: Linus Torvalds
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: arch/riscv: disable too many harts before pick main boot hart
‐‐‐ Original Message ‐‐‐ On 2019年9月14日SaturdayAM3点04分, Palmer Dabbelt wrote: > On Thu, 05 Sep 2019 23:51:15 PDT (-0700), me...@hardenedlinux.org wrote: > > > From 12300865d1103618c9d4c375f7d7fbe601b6618c Mon Sep 17 00:00:00 2001 > > From: Xiang Wang me...@hardenedlinux.org > > Date: Fri, 6 Sep 2019 11:56:09 +0800 > > Subject: [PATCH] arch/riscv: disable too many harts before pick main boot > > hart > > These harts with id greater than or equal to CONFIG_NR_CPUS need to be > > disabled. > > But pick the main Hart can choose any one. So, before pick the main hart, > > you > > need to disable the hart with id greater than or equal to CONFIG_NR_CPUS. > > > > Signed-off-by: Xiang Wang me...@hardenedlinux.org > > > > -- > > > > arch/riscv/kernel/head.S | 8 +--- > > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S > > index 0f1ba17e476f..cfffea38eb17 100644 > > --- a/arch/riscv/kernel/head.S > > +++ b/arch/riscv/kernel/head.S > > @@ -63,6 +63,11 @@ _start_kernel: > > li t0, SR_FS > > csrc sstatus, t0 > > +#ifdef CONFIG_SMP > > > > - li t0, CONFIG_NR_CPUS > > - bgeu a0, t0, .Lsecondary_park > > +#endif > > > > - > > > > /* Pick one hart to run the main boot sequence */ > > la a3, hart_lottery > > li a2, 1 > > @@ -154,9 +159,6 @@ relocate: > > .Lsecondary_start: > > #ifdef CONFIG_SMP > > > > - li a1, CONFIG_NR_CPUS > > - bgeu a0, a1, .Lsecondary_park > > - > > > > /* Set trap vector to spin forever to help debug */ > > la a3, .Lsecondary_park > > csrw CSR_STVEC, a3 > > It would be better to decouple the hart masks from NR_CPUS, as there's really > no reason for these to be the same. This may be new feature. Need to define new macros such as disabled_hart_mask, this patch is used to fix bug and not add new feature. > > Reviewed-by: Palmer Dabbelt pal...@sifive.com
Re: [PATCH v2] serial: sprd: Add polling IO support
Hi,
On Thu, 19 Sep 2019 at 11:10, Lanqing Liu wrote:
>
> In order to access the UART without the interrupts, the kernel uses
> the basic polling methods for IO with the device. With these methods
> implemented, it is now possible to enable kgdb during early boot over serial.
>
> Signed-off-by: Lanqing Liu
> ---
> Change from v1:
> - Add poll_init() support.
Looks good to me and the KGDB can work well on my board, so feel free
to add my tags:
Reviewed-by: Baolin Wang
Tested-by: Baolin Wang
> ---
> drivers/tty/serial/sprd_serial.c | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/drivers/tty/serial/sprd_serial.c
> b/drivers/tty/serial/sprd_serial.c
> index 73d71a4..d833160 100644
> --- a/drivers/tty/serial/sprd_serial.c
> +++ b/drivers/tty/serial/sprd_serial.c
> @@ -911,6 +911,34 @@ static void sprd_pm(struct uart_port *port, unsigned int
> state,
> }
> }
>
> +#ifdef CONFIG_CONSOLE_POLL
> +static int sprd_poll_init(struct uart_port *port)
> +{
> + if (port->state->pm_state != UART_PM_STATE_ON) {
> + sprd_pm(port, UART_PM_STATE_ON, 0);
> + port->state->pm_state = UART_PM_STATE_ON;
> + }
> +
> + return 0;
> +}
> +
> +static int sprd_poll_get_char(struct uart_port *port)
> +{
> + while (!(serial_in(port, SPRD_STS1) & SPRD_RX_FIFO_CNT_MASK))
> + cpu_relax();
> +
> + return serial_in(port, SPRD_RXD);
> +}
> +
> +static void sprd_poll_put_char(struct uart_port *port, unsigned char ch)
> +{
> + while (serial_in(port, SPRD_STS1) & SPRD_TX_FIFO_CNT_MASK)
> + cpu_relax();
> +
> + serial_out(port, SPRD_TXD, ch);
> +}
> +#endif
> +
> static const struct uart_ops serial_sprd_ops = {
> .tx_empty = sprd_tx_empty,
> .get_mctrl = sprd_get_mctrl,
> @@ -928,6 +956,11 @@ static void sprd_pm(struct uart_port *port, unsigned int
> state,
> .config_port = sprd_config_port,
> .verify_port = sprd_verify_port,
> .pm = sprd_pm,
> +#ifdef CONFIG_CONSOLE_POLL
> + .poll_init = sprd_poll_init,
> + .poll_get_char = sprd_poll_get_char,
> + .poll_put_char = sprd_poll_put_char,
> +#endif
> };
>
> #ifdef CONFIG_SERIAL_SPRD_CONSOLE
> --
> 1.9.1
>
--
Baolin Wang
Best Regards
[PATCH v2] serial: sprd: Add polling IO support
In order to access the UART without the interrupts, the kernel uses
the basic polling methods for IO with the device. With these methods
implemented, it is now possible to enable kgdb during early boot over serial.
Signed-off-by: Lanqing Liu
---
Change from v1:
- Add poll_init() support.
---
drivers/tty/serial/sprd_serial.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/tty/serial/sprd_serial.c b/drivers/tty/serial/sprd_serial.c
index 73d71a4..d833160 100644
--- a/drivers/tty/serial/sprd_serial.c
+++ b/drivers/tty/serial/sprd_serial.c
@@ -911,6 +911,34 @@ static void sprd_pm(struct uart_port *port, unsigned int
state,
}
}
+#ifdef CONFIG_CONSOLE_POLL
+static int sprd_poll_init(struct uart_port *port)
+{
+ if (port->state->pm_state != UART_PM_STATE_ON) {
+ sprd_pm(port, UART_PM_STATE_ON, 0);
+ port->state->pm_state = UART_PM_STATE_ON;
+ }
+
+ return 0;
+}
+
+static int sprd_poll_get_char(struct uart_port *port)
+{
+ while (!(serial_in(port, SPRD_STS1) & SPRD_RX_FIFO_CNT_MASK))
+ cpu_relax();
+
+ return serial_in(port, SPRD_RXD);
+}
+
+static void sprd_poll_put_char(struct uart_port *port, unsigned char ch)
+{
+ while (serial_in(port, SPRD_STS1) & SPRD_TX_FIFO_CNT_MASK)
+ cpu_relax();
+
+ serial_out(port, SPRD_TXD, ch);
+}
+#endif
+
static const struct uart_ops serial_sprd_ops = {
.tx_empty = sprd_tx_empty,
.get_mctrl = sprd_get_mctrl,
@@ -928,6 +956,11 @@ static void sprd_pm(struct uart_port *port, unsigned int
state,
.config_port = sprd_config_port,
.verify_port = sprd_verify_port,
.pm = sprd_pm,
+#ifdef CONFIG_CONSOLE_POLL
+ .poll_init = sprd_poll_init,
+ .poll_get_char = sprd_poll_get_char,
+ .poll_put_char = sprd_poll_put_char,
+#endif
};
#ifdef CONFIG_SERIAL_SPRD_CONSOLE
--
1.9.1
[PATCH v2] clk: imx7ulp: remove IMX7ULP_CLK_MIPI_PLL clock
The mipi pll clock comes from the MIPI PHY PLL output, so
it should not be a fixed clock.
MIPI PHY PLL is in the MIPI DSI space, and it is used as
the bit clock for transferring the pixel data out and its
output clock is configured according to the display mode.
So it should be used only for MIPI DSI and not be exported
out for other usages.
Signed-off-by: Fancy Fang
---
ChangeLog v1->v2:
* Keep other clock indexes unchanged as Shawn suggested.
Documentation/devicetree/bindings/clock/imx7ulp-clock.txt | 1 -
drivers/clk/imx/clk-imx7ulp.c | 3 +--
include/dt-bindings/clock/imx7ulp-clock.h | 1 -
3 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
b/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
index a4f8cd478f92..93d89adb7afe 100644
--- a/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
@@ -82,7 +82,6 @@ pcc2: pcc2@403f {
<&scg1 IMX7ULP_CLK_APLL_PFD0>,
<&scg1 IMX7ULP_CLK_UPLL>,
<&scg1 IMX7ULP_CLK_SOSC_BUS_CLK>,
-<&scg1 IMX7ULP_CLK_MIPI_PLL>,
<&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>,
<&scg1 IMX7ULP_CLK_ROSC>,
<&scg1 IMX7ULP_CLK_SPLL_BUS_CLK>;
diff --git a/drivers/clk/imx/clk-imx7ulp.c b/drivers/clk/imx/clk-imx7ulp.c
index 995a4ad10904..936c39f767df 100644
--- a/drivers/clk/imx/clk-imx7ulp.c
+++ b/drivers/clk/imx/clk-imx7ulp.c
@@ -28,7 +28,7 @@ static const char * const scs_sels[] = { "dummy",
"sosc", "sirc", "firc", "dumm
static const char * const ddr_sels[] = { "apll_pfd_sel", "upll", };
static const char * const nic_sels[] = { "firc", "ddr_clk", };
static const char * const periph_plat_sels[] = { "dummy", "nic1_bus_clk",
"nic1_clk", "ddr_clk", "apll_pfd2", "apll_pfd1", "apll_pfd0", "upll", };
-static const char * const periph_bus_sels[]= { "dummy", "sosc_bus_clk",
"mpll", "firc_bus_clk", "rosc", "nic1_bus_clk", "nic1_clk", "spll_bus_clk", };
+static const char * const periph_bus_sels[]= { "dummy", "sosc_bus_clk",
"dummy", "firc_bus_clk", "rosc", "nic1_bus_clk", "nic1_clk", "spll_bus_clk", };
static const char * const arm_sels[] = { "divcore", "dummy",
"dummy", "hsrun_divcore", };
/* used by sosc/sirc/firc/ddr/spll/apll dividers */
@@ -75,7 +75,6 @@ static void __init imx7ulp_clk_scg1_init(struct device_node
*np)
clks[IMX7ULP_CLK_SOSC] = imx_obtain_fixed_clk_hw(np, "sosc");
clks[IMX7ULP_CLK_SIRC] = imx_obtain_fixed_clk_hw(np, "sirc");
clks[IMX7ULP_CLK_FIRC] = imx_obtain_fixed_clk_hw(np, "firc");
- clks[IMX7ULP_CLK_MIPI_PLL] = imx_obtain_fixed_clk_hw(np, "mpll");
clks[IMX7ULP_CLK_UPLL] = imx_obtain_fixed_clk_hw(np, "upll");
/* SCG1 */
diff --git a/include/dt-bindings/clock/imx7ulp-clock.h
b/include/dt-bindings/clock/imx7ulp-clock.h
index 6f66f9005c81..a39b0c40cb41 100644
--- a/include/dt-bindings/clock/imx7ulp-clock.h
+++ b/include/dt-bindings/clock/imx7ulp-clock.h
@@ -49,7 +49,6 @@
#define IMX7ULP_CLK_NIC1_DIV 36
#define IMX7ULP_CLK_NIC1_BUS_DIV 37
#define IMX7ULP_CLK_NIC1_EXT_DIV 38
-#define IMX7ULP_CLK_MIPI_PLL 39
#define IMX7ULP_CLK_SIRC 40
#define IMX7ULP_CLK_SOSC_BUS_CLK 41
#define IMX7ULP_CLK_FIRC_BUS_CLK 42
--
2.17.1
[PATCH v2] clk: imx7ulp: remove IMX7ULP_CLK_MIPI_PLL clock
The mipi pll clock comes from the MIPI PHY PLL output, so
it should not be a fixed clock.
MIPI PHY PLL is in the MIPI DSI space, and it is used as
the bit clock for transferring the pixel data out and its
output clock is configured according to the display mode.
So it should be used only for MIPI DSI and not be exported
out for other usages.
Signed-off-by: Fancy Fang
---
ChangeLog v1->v2:
* Keep other clock indexes unchanged as Shawn suggested.
Documentation/devicetree/bindings/clock/imx7ulp-clock.txt | 1 -
drivers/clk/imx/clk-imx7ulp.c | 3 +--
include/dt-bindings/clock/imx7ulp-clock.h | 1 -
3 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
b/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
index a4f8cd478f92..93d89adb7afe 100644
--- a/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx7ulp-clock.txt
@@ -82,7 +82,6 @@ pcc2: pcc2@403f {
<&scg1 IMX7ULP_CLK_APLL_PFD0>,
<&scg1 IMX7ULP_CLK_UPLL>,
<&scg1 IMX7ULP_CLK_SOSC_BUS_CLK>,
-<&scg1 IMX7ULP_CLK_MIPI_PLL>,
<&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>,
<&scg1 IMX7ULP_CLK_ROSC>,
<&scg1 IMX7ULP_CLK_SPLL_BUS_CLK>;
diff --git a/drivers/clk/imx/clk-imx7ulp.c b/drivers/clk/imx/clk-imx7ulp.c
index 995a4ad10904..936c39f767df 100644
--- a/drivers/clk/imx/clk-imx7ulp.c
+++ b/drivers/clk/imx/clk-imx7ulp.c
@@ -28,7 +28,7 @@ static const char * const scs_sels[] = { "dummy",
"sosc", "sirc", "firc", "dumm
static const char * const ddr_sels[] = { "apll_pfd_sel", "upll", };
static const char * const nic_sels[] = { "firc", "ddr_clk", };
static const char * const periph_plat_sels[] = { "dummy", "nic1_bus_clk",
"nic1_clk", "ddr_clk", "apll_pfd2", "apll_pfd1", "apll_pfd0", "upll", };
-static const char * const periph_bus_sels[]= { "dummy", "sosc_bus_clk",
"mpll", "firc_bus_clk", "rosc", "nic1_bus_clk", "nic1_clk", "spll_bus_clk", };
+static const char * const periph_bus_sels[]= { "dummy", "sosc_bus_clk",
"dummy", "firc_bus_clk", "rosc", "nic1_bus_clk", "nic1_clk", "spll_bus_clk", };
static const char * const arm_sels[] = { "divcore", "dummy",
"dummy", "hsrun_divcore", };
/* used by sosc/sirc/firc/ddr/spll/apll dividers */
@@ -75,7 +75,6 @@ static void __init imx7ulp_clk_scg1_init(struct device_node
*np)
clks[IMX7ULP_CLK_SOSC] = imx_obtain_fixed_clk_hw(np, "sosc");
clks[IMX7ULP_CLK_SIRC] = imx_obtain_fixed_clk_hw(np, "sirc");
clks[IMX7ULP_CLK_FIRC] = imx_obtain_fixed_clk_hw(np, "firc");
- clks[IMX7ULP_CLK_MIPI_PLL] = imx_obtain_fixed_clk_hw(np, "mpll");
clks[IMX7ULP_CLK_UPLL] = imx_obtain_fixed_clk_hw(np, "upll");
/* SCG1 */
diff --git a/include/dt-bindings/clock/imx7ulp-clock.h
b/include/dt-bindings/clock/imx7ulp-clock.h
index 6f66f9005c81..a39b0c40cb41 100644
--- a/include/dt-bindings/clock/imx7ulp-clock.h
+++ b/include/dt-bindings/clock/imx7ulp-clock.h
@@ -49,7 +49,6 @@
#define IMX7ULP_CLK_NIC1_DIV 36
#define IMX7ULP_CLK_NIC1_BUS_DIV 37
#define IMX7ULP_CLK_NIC1_EXT_DIV 38
-#define IMX7ULP_CLK_MIPI_PLL 39
#define IMX7ULP_CLK_SIRC 40
#define IMX7ULP_CLK_SOSC_BUS_CLK 41
#define IMX7ULP_CLK_FIRC_BUS_CLK 42
--
2.17.1
Re: [PATCH v2 4/6] platform/x86: huawei-wmi: Add battery charging thresholds
Hi Ayman,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190918]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Ayman-Bagabas/platform-x86-Huawei-WMI-laptop-extras-driver/20190919-090022
config: x86_64-randconfig-s1-201937 (attached as .config)
compiler: gcc-5 (Ubuntu 5.5.0-12ubuntu1) 5.5.0 20171010
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
ld: drivers/platform/x86/asus-wmi.o: in function `asus_wmi_battery_init':
drivers/platform/x86/asus-wmi.c:457: undefined reference to
`battery_hook_register'
ld: drivers/platform/x86/asus-wmi.o: in function `asus_wmi_battery_exit':
drivers/platform/x86/asus-wmi.c:464: undefined reference to
`battery_hook_unregister'
ld: drivers/platform/x86/huawei-wmi.o: in function `huawei_wmi_battery_exit':
>> drivers/platform/x86/huawei-wmi.c:513: undefined reference to
>> `battery_hook_unregister'
ld: drivers/platform/x86/huawei-wmi.o: in function
`huawei_wmi_battery_setup':
>> drivers/platform/x86/huawei-wmi.c:504: undefined reference to
>> `battery_hook_register'
vim +513 drivers/platform/x86/huawei-wmi.c
493
494 static void huawei_wmi_battery_setup(struct device *dev)
495 {
496 struct huawei_wmi *huawei = dev_get_drvdata(dev);
497
498 huawei->battery_available = true;
499 if (huawei_wmi_battery_get(NULL, NULL)) {
500 huawei->battery_available = false;
501 return;
502 }
503
> 504 battery_hook_register(&huawei_wmi_battery_hook);
505 device_create_file(dev, &dev_attr_charge_control_thresholds);
506 }
507
508 static void huawei_wmi_battery_exit(struct device *dev)
509 {
510 struct huawei_wmi *huawei = dev_get_drvdata(dev);
511
512 if (huawei->battery_available) {
> 513 battery_hook_unregister(&huawei_wmi_battery_hook);
514 device_remove_file(dev,
&dev_attr_charge_control_thresholds);
515 }
516 }
517
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH v4 1/3] kernel/notifier.c: intercepting duplicate registrations to avoid infinite loops
Registering the same notifier to a hook repeatedly can cause the hook
list to form a ring or lose other members of the list.
case1: An infinite loop in notifier_chain_register() can cause soft lockup
atomic_notifier_chain_register(&test_notifier_list, &test1);
atomic_notifier_chain_register(&test_notifier_list, &test1);
atomic_notifier_chain_register(&test_notifier_list, &test2);
case2: An infinite loop in notifier_chain_register() can cause soft lockup
atomic_notifier_chain_register(&test_notifier_list, &test1);
atomic_notifier_chain_register(&test_notifier_list, &test1);
atomic_notifier_call_chain(&test_notifier_list, 0, NULL);
case3: lose other hook test2
atomic_notifier_chain_register(&test_notifier_list, &test1);
atomic_notifier_chain_register(&test_notifier_list, &test2);
atomic_notifier_chain_register(&test_notifier_list, &test1);
case4: Unregister returns 0, but the hook is still in the linked list,
and it is not really registered. If you call notifier_call_chain
after ko is unloaded, it will trigger oops.
If the system is configured with softlockup_panic and the same
hook is repeatedly registered on the panic_notifier_list, it
will cause a loop panic.
Add a check in notifier_chain_register(),
Intercepting duplicate registrations to avoid infinite loops
Signed-off-by: Xiaoming Ni
Reviewed-by: Vasily Averin
---
kernel/notifier.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/notifier.c b/kernel/notifier.c
index d9f5081..30bedb8 100644
--- a/kernel/notifier.c
+++ b/kernel/notifier.c
@@ -23,7 +23,10 @@ static int notifier_chain_register(struct notifier_block
**nl,
struct notifier_block *n)
{
while ((*nl) != NULL) {
- WARN_ONCE(((*nl) == n), "double register detected");
+ if (unlikely((*nl) == n)) {
+ WARN(1, "double register detected");
+ return 0;
+ }
if (n->priority > (*nl)->priority)
break;
nl = &((*nl)->next);
--
1.8.5.6
[PATCH v4 0/3] kernel/notifier.c: intercepting duplicate registrations to avoid infinite loops
Registering the same notifier to a hook repeatedly can cause the hook list to form a ring or lose other members of the list. so, need add a check in in notifier_chain_register(), intercepting duplicate registrations to avoid infinite loops v1: * use notifier_chain_cond_register replace notifier_chain_register v2: * Add a check in notifier_chain_register() to avoid duplicate registration * remove notifier_chain_cond_register() to avoid duplicate code * remove blocking_notifier_chain_cond_register() to avoid duplicate code v3: * Add a cover letter. v4: * Add Reviewed-by and adjust the title. Xiaoming Ni (3): kernel/notifier.c: intercepting duplicate registrations to avoid infinite loops kernel/notifier.c: remove notifier_chain_cond_register() kernel/notifier.c: remove blocking_notifier_chain_cond_register() include/linux/notifier.h | 4 kernel/notifier.c| 41 +++-- net/sunrpc/rpc_pipe.c| 2 +- 3 files changed, 4 insertions(+), 43 deletions(-) -- 1.8.5.6
[PATCH v4 3/3] kernel/notifier.c: remove blocking_notifier_chain_cond_register()
blocking_notifier_chain_cond_register() does not consider
system_booting state, which is the only difference between this
function and blocking_notifier_cain_register(). This can be a bug
and is a piece of duplicate code.
Delete blocking_notifier_chain_cond_register()
Signed-off-by: Xiaoming Ni
---
include/linux/notifier.h | 4
kernel/notifier.c| 23 ---
net/sunrpc/rpc_pipe.c| 2 +-
3 files changed, 1 insertion(+), 28 deletions(-)
diff --git a/include/linux/notifier.h b/include/linux/notifier.h
index 0096a05..0189476 100644
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -150,10 +150,6 @@ extern int raw_notifier_chain_register(struct
raw_notifier_head *nh,
extern int srcu_notifier_chain_register(struct srcu_notifier_head *nh,
struct notifier_block *nb);
-extern int blocking_notifier_chain_cond_register(
- struct blocking_notifier_head *nh,
- struct notifier_block *nb);
-
extern int atomic_notifier_chain_unregister(struct atomic_notifier_head *nh,
struct notifier_block *nb);
extern int blocking_notifier_chain_unregister(struct blocking_notifier_head
*nh,
diff --git a/kernel/notifier.c b/kernel/notifier.c
index e3d221f..63d7501 100644
--- a/kernel/notifier.c
+++ b/kernel/notifier.c
@@ -221,29 +221,6 @@ int blocking_notifier_chain_register(struct
blocking_notifier_head *nh,
EXPORT_SYMBOL_GPL(blocking_notifier_chain_register);
/**
- * blocking_notifier_chain_cond_register - Cond add notifier to a blocking
notifier chain
- * @nh: Pointer to head of the blocking notifier chain
- * @n: New entry in notifier chain
- *
- * Adds a notifier to a blocking notifier chain, only if not already
- * present in the chain.
- * Must be called in process context.
- *
- * Currently always returns zero.
- */
-int blocking_notifier_chain_cond_register(struct blocking_notifier_head *nh,
- struct notifier_block *n)
-{
- int ret;
-
- down_write(&nh->rwsem);
- ret = notifier_chain_register(&nh->head, n);
- up_write(&nh->rwsem);
- return ret;
-}
-EXPORT_SYMBOL_GPL(blocking_notifier_chain_cond_register);
-
-/**
* blocking_notifier_chain_unregister - Remove notifier from a blocking
notifier chain
* @nh: Pointer to head of the blocking notifier chain
* @n: Entry to remove from notifier chain
diff --git a/net/sunrpc/rpc_pipe.c b/net/sunrpc/rpc_pipe.c
index b71a39d..39e14d5 100644
--- a/net/sunrpc/rpc_pipe.c
+++ b/net/sunrpc/rpc_pipe.c
@@ -51,7 +51,7 @@
int rpc_pipefs_notifier_register(struct notifier_block *nb)
{
- return blocking_notifier_chain_cond_register(&rpc_pipefs_notifier_list,
nb);
+ return blocking_notifier_chain_register(&rpc_pipefs_notifier_list, nb);
}
EXPORT_SYMBOL_GPL(rpc_pipefs_notifier_register);
--
1.8.5.6
RE: [PATCH V2 3/4] ASoC: pcm_dmaengine: Extract snd_dmaengine_pcm_set_runtime_hwparams
Hi > > When set the runtime hardware parameters, we may need to query the > capability of DMA to complete the parameters. > > This patch is to Extract this operation from > dmaengine_pcm_set_runtime_hwparams function to a separate function > snd_dmaengine_pcm_set_runtime_hwparams, that other components > which need this feature can call this function. > > Signed-off-by: Shengjiu Wang > --- kbuild test robot report compile issue, will resend v3 after fixing. Best regards Wang shengjiu
[PATCH v4 2/3] kernel/notifier.c: remove notifier_chain_cond_register()
The only difference between notifier_chain_cond_register() and
notifier_chain_register() is the lack of warning hints for duplicate
registrations.
Consider using notifier_chain_register() instead of
notifier_chain_cond_register() to avoid duplicate code
Signed-off-by: Xiaoming Ni
---
kernel/notifier.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/kernel/notifier.c b/kernel/notifier.c
index 30bedb8..e3d221f 100644
--- a/kernel/notifier.c
+++ b/kernel/notifier.c
@@ -36,21 +36,6 @@ static int notifier_chain_register(struct notifier_block
**nl,
return 0;
}
-static int notifier_chain_cond_register(struct notifier_block **nl,
- struct notifier_block *n)
-{
- while ((*nl) != NULL) {
- if ((*nl) == n)
- return 0;
- if (n->priority > (*nl)->priority)
- break;
- nl = &((*nl)->next);
- }
- n->next = *nl;
- rcu_assign_pointer(*nl, n);
- return 0;
-}
-
static int notifier_chain_unregister(struct notifier_block **nl,
struct notifier_block *n)
{
@@ -252,7 +237,7 @@ int blocking_notifier_chain_cond_register(struct
blocking_notifier_head *nh,
int ret;
down_write(&nh->rwsem);
- ret = notifier_chain_cond_register(&nh->head, n);
+ ret = notifier_chain_register(&nh->head, n);
up_write(&nh->rwsem);
return ret;
}
--
1.8.5.6
Re: [PATCH] workqueue: Fix spurious sanity check failures in destroy_workqueue()
Looks good to me.
There is one test in show_pwq()
"""
worker == pwq->wq->rescuer ? "(RESCUER)" : "",
"""
I'm wondering if it needs to be updated to
"""
worker->rescue_wq ? "(RESCUER)" : "",
"""
And document "/* MD: rescue worker */" might be better
than current "/* I: rescue worker */", although ->rescuer can
be accessed without wq_mayday_lock lock in some code.
Reviewed-by: Lai Jiangshan
On Thu, Sep 19, 2019 at 9:43 AM Tejun Heo wrote:
>
> Before actually destrying a workqueue, destroy_workqueue() checks
> whether it's actually idle. If it isn't, it prints out a bunch of
> warning messages and leaves the workqueue dangling. It unfortunately
> has a couple issues.
>
> * Mayday list queueing increments pwq's refcnts which gets detected as
> busy and fails the sanity checks. However, because mayday list
> queueing is asynchronous, this condition can happen without any
> actual work items left in the workqueue.
>
> * Sanity check failure leaves the sysfs interface behind too which can
> lead to init failure of newer instances of the workqueue.
>
> This patch fixes the above two by
>
> * If a workqueue has a rescuer, disable and kill the rescuer before
> sanity checks. Disabling and killing is guaranteed to flush the
> existing mayday list.
>
> * Remove sysfs interface before sanity checks.
>
> Signed-off-by: Tejun Heo
> Reported-by: Marcin Pawlowski
> Reported-by: "Williams, Gerald S"
> Cc: sta...@vger.kernel.org
> ---
> Applying to wq/for-5.4.
>
> Thanks.
>
> kernel/workqueue.c | 24 +++-
> 1 file changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index 95aea04ff722..73e3ea9e31d3 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -4318,9 +4318,28 @@ void destroy_workqueue(struct workqueue_struct *wq)
> struct pool_workqueue *pwq;
> int node;
>
> + /*
> +* Remove it from sysfs first so that sanity check failure doesn't
> +* lead to sysfs name conflicts.
> +*/
> + workqueue_sysfs_unregister(wq);
> +
> /* drain it before proceeding with destruction */
> drain_workqueue(wq);
>
> + /* kill rescuer, if sanity checks fail, leave it w/o rescuer */
> + if (wq->rescuer) {
> + struct worker *rescuer = wq->rescuer;
> +
> + /* this prevents new queueing */
> + spin_lock_irq(&wq_mayday_lock);
> + wq->rescuer = NULL;
> + spin_unlock_irq(&wq_mayday_lock);
> +
> + /* rescuer will empty maydays list before exiting */
> + kthread_stop(rescuer->task);
> + }
> +
> /* sanity checks */
> mutex_lock(&wq->mutex);
> for_each_pwq(pwq, wq) {
> @@ -4352,11 +4371,6 @@ void destroy_workqueue(struct workqueue_struct *wq)
> list_del_rcu(&wq->list);
> mutex_unlock(&wq_pool_mutex);
>
> - workqueue_sysfs_unregister(wq);
> -
> - if (wq->rescuer)
> - kthread_stop(wq->rescuer->task);
> -
> if (!(wq->flags & WQ_UNBOUND)) {
> wq_unregister_lockdep(wq);
> /*
> --
> 2.17.1
>
Re: Re: Re: [PATCH] connector: report comm change event when modifying /proc/pid/task/tid/comm
On 2019/9/18 at 1:08, Will Deacon wrote:
>On Tue, Sep 17, 2019 at 09:56:28AM -0400, KeMeng Shi wrote:
>>on 2019/9/17 at 5:10, Will Deacon wrote:
>>>The rough idea looks ok to me but I have two concerns:
>>>
>>> (1) This looks like it will be visible to userspace, and this changes
>>> the behaviour after ~8 years of not reporting this event.
>>This do bother for users who only care the comm change via prctl, but
>>it also benefits users who want all comm changes. Maybe the best way
>>is add something like config or switch to meet the both conditions
>>above. In my opinion, users cares comm change event rather than how it
>>change.
>
>I was really just looking for some intuition as to how this event is currently
>used and why extending it like this is unlikely to break those existing users.
By listening these comm change events, user is able to monitor and control
specific threads that they are interested. For instance, a process control
daemon listening to proc connector and following comm value policies can
place specific threads to assigned cgroup partitions (quota from commit
f786ecba415888 ("connector: add comm change event report to proc
connector")). It's harmless as user ignore the threads with names that
they are not interested.
>>>(2) What prevents proc_comm_connector(p) running concurrently with
>>>itself via the prctl()? The locking seems to be confined to set_task_comm().
>>To be honest, I did not consider the concurrence problem at beginning.
>>And some comm change events may lost or are reported repeatly as follows:
>>set name via procfs set name via prctl
>>set_task_comm
>> set_task_comm
>>proc_comm_connector
>> proc_comm_connector
>>Comm change event belong to procfs losts and the fresh comm change
>>belong to prctl is reported twice. Actually, there is also concurrence
>>problem without this update as follows:
>>set name via procfs set name via prctl
>> set_task_comm
>>set_task_comm
>> proc_comm_connector
>>Comm change event from procfs is reported instead of prctl, this may
>>bothers user who only care the comm change via prctl.
>
>Perhaps, although given that proc_comm_connector() is currently only
>called on the prctl() path, then it does at least provide the comm
>from the most recent prctl() invocation. With your path, the calls
>can go out of order, so I think that probably needs fixing.
It's indeed necessary to fix the concurrence problem. I will submit
a v2 patch when I fix this.
Thanks for your review and advise.
KeMeng Shi
[PATCH] PCI: Enhance the ACS quirk for Cavium devices
Enhance the ACS quirk for Cavium Processors. Add the root port
vendor ID's in an array and use the same in match function.
For newer devices add the vendor ID's in the array so that the
match function is simpler.
Signed-off-by: George Cherian
---
drivers/pci/quirks.c | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 44c4ae1abd00..64deeaddd51c 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4241,17 +4241,27 @@ static int pci_quirk_amd_sb_acs(struct pci_dev *dev,
u16 acs_flags)
#endif
}
+static const u16 pci_quirk_cavium_acs_ids[] = {
+ /* CN88xx family of devices */
+ 0xa180, 0xa170,
+ /* CN99xx family of devices */
+ 0xaf84,
+ /* CN11xxx family of devices */
+ 0xb884,
+};
+
static bool pci_quirk_cavium_acs_match(struct pci_dev *dev)
{
- /*
-* Effectively selects all downstream ports for whole ThunderX 1
-* family by 0xf800 mask (which represents 8 SoCs), while the lower
-* bits of device ID are used to indicate which subdevice is used
-* within the SoC.
-*/
- return (pci_is_pcie(dev) &&
- (pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT) &&
- ((dev->device & 0xf800) == 0xa000));
+ int i;
+
+ if (!pci_is_pcie(dev) || pci_pcie_type(dev) != PCI_EXP_TYPE_ROOT_PORT)
+ return false;
+
+ for (i = 0; i < ARRAY_SIZE(pci_quirk_cavium_acs_ids); i++)
+ if (pci_quirk_cavium_acs_ids[i] == dev->device)
+ return true;
+
+ return false;
}
static int pci_quirk_cavium_acs(struct pci_dev *dev, u16 acs_flags)
--
2.17.1
Re: [PATCH] staging: tracing/kprobe: filter kprobe based perf event
That's bloody true. Thanks for your insights. I will make an example program and commit into bcc repository. Jinshan On Wed, Sep 18, 2019 at 1:22 PM Alexei Starovoitov wrote: > > On Wed, Sep 18, 2019 at 8:13 AM Jinshan Xiong wrote: > > > > The problem with the current approach is that it would be difficult to > > filter cgroup, especially the cgroup in question has descendents, and also > > it would spawn new descendents after BPF program is installed. it's hard to > > filter it inside a BPF program. > > Why is that? > bpf_current_task_under_cgroup() fits exactly that purpose.
Re: [PATCH] [RFC] vmscan.c: add a sysctl entry for controlling memory reclaim IO congestion_wait length
On 9/18/19 20:33, Michal Hocko wrote: +mm_reclaim_congestion_wait_jiffies +== + +This control is used to define how long kernel will wait/sleep while +system memory is under pressure and memroy reclaim is relatively active. +Lower values will decrease the kernel wait/sleep time. + +It's suggested to lower this value on high-end box that system is under memory +pressure but with low storage IO utils and high CPU iowait, which could also +potentially decrease user application response time in this case. + +Keep this control as it were if your box are not above case. + +The default value is HZ/10, which is of equal value to 100ms independ of how +many HZ is defined. Adding a new tunable is not the right solution. The right way is to make Linux auto-tune itself to avoid the problem. I absolutely agree here. From you changelog it is also not clear what is the underlying problem. Both congestion_wait and wait_iff_congested should wake up early if the congestion is handled. Is this not the case? For now I don't know why, codes seem should work as you said, maybe I need to trace more of the internals. But weird thing is that once I set the people-disliked-tunable iowait drop down instantly, this is contradictory to the code design. Why? Are you sure a shorter timeout is not just going to cause problems elsewhere. These sleeps are used to throttle the reclaim. I do agree there is no great deal of design behind them so they are more of "let's hope it works" kinda thing but making their timeout configurable just doesn't solve this at all. You are effectively exporting a very subtle implementation detail into the userspace. Kind of agree, but it does fix the issue at least mine and user response time also improve in the meantime. So, just make it as it were and exported to someone needs it..
Re: [PATCH 2/3] dt-bindings: reset: add bindings for the Meson-A1 SoC Reset Controller
Hi, Neil Thanks for your review On 2019/9/18 20:39, Neil Armstrong wrote: Hi, On 18/09/2019 14:12, Xingyu Chen wrote: Add DT bindings for the Meson-A1 SoC Reset Controller include file, and also slightly update documentation. Signed-off-by: Xingyu Chen Signed-off-by: Jianxin Pan --- .../bindings/reset/amlogic,meson-reset.txt | 4 +- The reset bindings has been moved to yaml, either rebase on linux-next or wait for v5.4-rc1 : https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next/+/refs/tags/next-20190917/Documentation/devicetree/bindings/reset/amlogic%2Cmeson-reset.yaml NeilI will fix it in next version. include/dt-bindings/reset/amlogic,meson-a1-reset.h | 59 ++ 2 files changed, 61 insertions(+), 2 deletions(-) create mode 100644 include/dt-bindings/reset/amlogic,meson-a1-reset.h diff --git a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt index 28ef6c2..011151a 100644 --- a/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt +++ b/Documentation/devicetree/bindings/reset/amlogic,meson-reset.txt @@ -5,8 +5,8 @@ Please also refer to reset.txt in this directory for common reset controller binding usage. Required properties: -- compatible: Should be "amlogic,meson8b-reset", "amlogic,meson-gxbb-reset" or - "amlogic,meson-axg-reset". +- compatible: Should be "amlogic,meson8b-reset", "amlogic,meson-gxbb-reset", + "amlogic,meson-axg-reset" or "amlogic,meson-a1-reset". - reg: should contain the register address base - #reset-cells: 1, see below diff --git a/include/dt-bindings/reset/amlogic,meson-a1-reset.h b/include/dt-bindings/reset/amlogic,meson-a1-reset.h new file mode 100644 index ..8d76a47 --- /dev/null +++ b/include/dt-bindings/reset/amlogic,meson-a1-reset.h @@ -0,0 +1,59 @@ +/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) + * + * Copyright (c) 2019 Amlogic, Inc. All rights reserved. + * Author: Xingyu Chen + * + */ + +#ifndef _DT_BINDINGS_AMLOGIC_MESON_A1_RESET_H +#define _DT_BINDINGS_AMLOGIC_MESON_A1_RESET_H + +/* RESET0 */ +#define RESET_AM2AXI_VAD 1 +#define RESET_PSRAM4 +#define RESET_PAD_CTRL 5 +#define RESET_TEMP_SENSOR 7 +#define RESET_AM2AXI_DEV 8 +#define RESET_SPICC_A 10 +#define RESET_MSR_CLK 11 +#define RESET_AUDIO12 +#define RESET_ANALOG_CTRL 13 +#define RESET_SAR_ADC 14 +#define RESET_AUDIO_VAD15 +#define RESET_CEC 16 +#define RESET_PWM_EF 17 +#define RESET_PWM_CD 18 +#define RESET_PWM_AB 19 +#define RESET_IR_CTRL 21 +#define RESET_I2C_S_A 22 +#define RESET_I2C_M_D 24 +#define RESET_I2C_M_C 25 +#define RESET_I2C_M_B 26 +#define RESET_I2C_M_A 27 +#define RESET_I2C_PROD_AHB 28 +#define RESET_I2C_PROD 29 + +/* RESET1 */ +#define RESET_ACODEC 32 +#define RESET_DMA 33 +#define RESET_SD_EMMC_A34 +#define RESET_USBCTRL 36 +#define RESET_USBPHY 38 +#define RESET_RSA 42 +#define RESET_DMC 43 +#define RESET_IRQ_CTRL 45 +#define RESET_NIC_VAD 47 +#define RESET_NIC_AXI 48 +#define RESET_RAMA 49 +#define RESET_RAMB 50 +#define RESET_ROM 53 +#define RESET_SPIFC54 +#define RESET_GIC 55 +#define RESET_UART_C 56 +#define RESET_UART_B 57 +#define RESET_UART_A 58 +#define RESET_OSC_RING 59 + +/* RESET2 Reserved */ + +#endif .
Re: [PATCH] [RFC] vmscan.c: add a sysctl entry for controlling memory reclaim IO congestion_wait length
Hi, On 9/18/19 19:38, Matthew Wilcox wrote: On Wed, Sep 18, 2019 at 11:21:04AM +0800, Lin Feng wrote: Adding a new tunable is not the right solution. The right way is to make Linux auto-tune itself to avoid the problem. For example, bdi_writeback contains an estimated write bandwidth (calculated by the memory management layer). Given that, we should be able to make an estimate for how long to wait for the queues to drain. Yes, I had ever considered that, auto-tuning is definitely the senior AI way. While considering all kinds of production environments hybird storage solution is also common today, servers' dirty pages' bdi drivers can span from high end ssds to low end sata disk, so we have to think of a *formula(AI core)* by using the factors of dirty pages' amount and bdis' write bandwidth, and this AI-core will depend on if the estimated write bandwidth is sane and moreover the to be written back dirty pages is sequential or random if the bdi is rotational disk, it's likey to give a not-sane number and hurt guys who dont't want that, while if only consider ssd is relatively simple. So IMHO it's not sane to brute force add a guessing logic into memory writeback codes and pray on inventing a formula that caters everyone's need. Add a sysctl entry may be a right choice that give people who need it and doesn't hurt people who don't want it. You're making this sound far harder than it is. All the writeback code needs to know is "How long should I sleep for in order for the queues to drain a substantial amount". Since you know the bandwidth and how many pages you've queued up, it's a simple calculation. Ah, I should have read more of the writeback codes ;-) Based on Michal's comments: > the underlying problem. Both congestion_wait and wait_iff_congested > should wake up early if the congestion is handled. Is this not the case? If process is waken up once bdi congested is clear, this timeout length's role seems not that important. I need to trace more if I can reproduce this issue without online network traffic. But still weird thing is that once I set the people-disliked-tunable iowait drop down instantly, they are contradictory. Anyway, thanks a lot for your suggestions! linfeng
Re: [PATCH] mfd: mt6360: add pmic mt6360 driver
Lee Jones 於 2019年9月18日 週三 下午6:51寫道： > > On Wed, 18 Sep 2019, Gene Chen wrote: > > > From: Gene Chen > > > > Add mfd driver for mt6360 pmic chip include > > Battery Charger/USB_PD/Flash LED/RGB LED/LDO/Buck > > > > Signed-off-by: Gene Chen > --- > > This looks different from the one you sent before, but I don't see a > version bump or any changelog in this space. Please re-submit with > the differences noted. > the change is 1. add missing include file 2. modify commit message this patch is regarded as version 1 > > drivers/mfd/Kconfig| 12 + > > drivers/mfd/Makefile | 1 + > > drivers/mfd/mt6360-core.c | 463 > > + > > include/linux/mfd/mt6360-private.h | 279 ++ > > include/linux/mfd/mt6360.h | 33 +++ > > 5 files changed, 788 insertions(+) > > create mode 100644 drivers/mfd/mt6360-core.c > > create mode 100644 include/linux/mfd/mt6360-private.h > > create mode 100644 include/linux/mfd/mt6360.h > > -- > Lee Jones [李琼斯] > Linaro Services Technical Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog
[PATCH 4/4] thermal: step_wise: Extend thermal step-wise governor to monitor falling temperature.
>From the step wise governor point of view, the policy decisions
that has to taken on a thermal trip point that is defined to be monitored
for falling temprature is the mirror opposite of the decisions it has
to take on a trip point that is monitored for rising temperature.
Signed-off-by: Thara Gopinath
---
drivers/thermal/step_wise.c | 59 +
1 file changed, 44 insertions(+), 15 deletions(-)
diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index 6e051cb..aa8e0a0 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -35,7 +35,8 @@
* deactivate the thermal instance
*/
static unsigned long get_target_state(struct thermal_instance *instance,
- enum thermal_trend trend, bool throttle)
+ enum thermal_trend trend, bool throttle,
+ enum thermal_trip_monitor_type type)
{
struct thermal_cooling_device *cdev = instance->cdev;
unsigned long cur_state;
@@ -65,11 +66,21 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
switch (trend) {
case THERMAL_TREND_RAISING:
- if (throttle) {
- next_target = cur_state < instance->upper ?
- (cur_state + 1) : instance->upper;
- if (next_target < instance->lower)
- next_target = instance->lower;
+ if (type == THERMAL_TRIP_MONITOR_FALLING) {
+ if (cur_state <= instance->lower) {
+ if (!throttle)
+ next_target = THERMAL_NO_TARGET;
+ } else {
+ if (!throttle)
+ next_target = cur_state - 1;
+ }
+ } else {
+ if (throttle) {
+ next_target = cur_state < instance->upper ?
+ (cur_state + 1) : instance->upper;
+ if (next_target < instance->lower)
+ next_target = instance->lower;
+ }
}
break;
case THERMAL_TREND_RAISE_FULL:
@@ -77,14 +88,23 @@ static unsigned long get_target_state(struct
thermal_instance *instance,
next_target = instance->upper;
break;
case THERMAL_TREND_DROPPING:
- if (cur_state <= instance->lower) {
- if (!throttle)
- next_target = THERMAL_NO_TARGET;
+ if (type == THERMAL_TRIP_MONITOR_FALLING) {
+ if (throttle) {
+ next_target = cur_state < instance->upper ?
+ (cur_state + 1) : instance->upper;
+ if (next_target < instance->lower)
+ next_target = instance->lower;
+ }
} else {
- if (!throttle) {
- next_target = cur_state - 1;
- if (next_target > instance->upper)
- next_target = instance->upper;
+ if (cur_state <= instance->lower) {
+ if (!throttle)
+ next_target = THERMAL_NO_TARGET;
+ } else {
+ if (!throttle) {
+ next_target = cur_state - 1;
+ if (next_target > instance->upper)
+ next_target = instance->upper;
+ }
}
}
break;
@@ -117,6 +137,8 @@ static void thermal_zone_trip_update(struct
thermal_zone_device *tz, int trip)
{
int trip_temp;
enum thermal_trip_type trip_type;
+ enum thermal_trip_monitor_type monitor_type =
+ THERMAL_TRIP_MONITOR_RISING;
enum thermal_trend trend;
struct thermal_instance *instance;
bool throttle = false;
@@ -130,9 +152,15 @@ static void thermal_zone_trip_update(struct
thermal_zone_device *tz, int trip)
tz->ops->get_trip_type(tz, trip, &trip_type);
}
+ if (tz->ops->get_trip_monitor_type)
+ tz->ops->get_trip_monitor_type(tz, trip, &monitor_type);
+
trend = get_tz_trend(tz, trip);
- if (tz->temperature >= trip_temp) {
+ if (((monitor_type == THERMAL_TRIP_MONITOR_RISING) &&
+ (tz->temperature >= trip_temp)) ||
+ ((monitor_type == THERMAL_TRIP_MONITOR_FALLING) &&
+ (tz->t
[PATCH 2/4] thermal: Thermal core and sysfs changes needed to support bi-directional monitoring of trip points.
Thermal trip points can be defined to indicate whether a
temperature rise or a temperature fall is to be monitored. This
property can now be defined in the DT bindings for a trip point.
To support this following three changes are introduced to thermal
core and sysfs code.
1. Define a new variable in thermal_trip to capture the monitor
rising/falling information from trip point DT bindings.
2. Define a new ops in thermal_zone_device_ops that can be populated
to indicate whether a trip is being monitored for rising or falling
temperature. If the ops is not populated or if the binding is missing
in the DT, it is assumed that the trip is being monitored for rising
temperature. (default behavior today)
3. Introduce sysfs entries for each trip point to read the direction of
monitoring.
Signed-off-by: Thara Gopinath
---
drivers/thermal/thermal_sysfs.c | 60 ++---
include/linux/thermal.h | 10 +++
include/uapi/linux/thermal.h| 2 +-
3 files changed, 67 insertions(+), 5 deletions(-)
diff --git a/drivers/thermal/thermal_sysfs.c b/drivers/thermal/thermal_sysfs.c
index aa99edb..b4ef6be 100644
--- a/drivers/thermal/thermal_sysfs.c
+++ b/drivers/thermal/thermal_sysfs.c
@@ -216,6 +216,31 @@ trip_point_hyst_show(struct device *dev, struct
device_attribute *attr,
}
static ssize_t
+trip_point_monitor_type_show(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+ struct thermal_zone_device *tz = to_thermal_zone(dev);
+ enum thermal_trip_monitor_type type;
+ int trip, result;
+
+ if (sscanf(attr->attr.name, "trip_point_%d_monitor_type", &trip) != 1)
+ return -EINVAL;
+
+ if (!tz->ops->get_trip_monitor_type)
+ goto exit;
+
+ result = tz->ops->get_trip_monitor_type(tz, trip, &type);
+ if (result)
+ return result;
+
+ if (type == THERMAL_TRIP_MONITOR_FALLING)
+ return sprintf(buf, "falling\n");
+
+exit:
+ return sprintf(buf, "rising\n");
+}
+
+static ssize_t
passive_store(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
@@ -520,10 +545,20 @@ static int create_trip_attrs(struct thermal_zone_device
*tz, int mask)
if (!tz->trip_type_attrs)
return -ENOMEM;
+ tz->trip_monitor_type_attrs = kcalloc
+ (tz->trips,
+ sizeof(*tz->trip_monitor_type_attrs),
+ GFP_KERNEL);
+ if (!tz->trip_monitor_type_attrs) {
+ kfree(tz->trip_type_attrs);
+ return -ENOMEM;
+ }
+
tz->trip_temp_attrs = kcalloc(tz->trips, sizeof(*tz->trip_temp_attrs),
GFP_KERNEL);
if (!tz->trip_temp_attrs) {
kfree(tz->trip_type_attrs);
+ kfree(tz->trip_monitor_type_attrs);
return -ENOMEM;
}
@@ -533,14 +568,16 @@ static int create_trip_attrs(struct thermal_zone_device
*tz, int mask)
GFP_KERNEL);
if (!tz->trip_hyst_attrs) {
kfree(tz->trip_type_attrs);
+ kfree(tz->trip_monitor_type_attrs);
kfree(tz->trip_temp_attrs);
return -ENOMEM;
}
}
- attrs = kcalloc(tz->trips * 3 + 1, sizeof(*attrs), GFP_KERNEL);
+ attrs = kcalloc(tz->trips * 4 + 1, sizeof(*attrs), GFP_KERNEL);
if (!attrs) {
kfree(tz->trip_type_attrs);
+ kfree(tz->trip_monitor_type_attrs);
kfree(tz->trip_temp_attrs);
if (tz->ops->get_trip_hyst)
kfree(tz->trip_hyst_attrs);
@@ -559,6 +596,20 @@ static int create_trip_attrs(struct thermal_zone_device
*tz, int mask)
tz->trip_type_attrs[indx].attr.show = trip_point_type_show;
attrs[indx] = &tz->trip_type_attrs[indx].attr.attr;
+ /* create trip monitor type attribute */
+ snprintf(tz->trip_monitor_type_attrs[indx].name,
+THERMAL_NAME_LENGTH, "trip_point_%d_monitor_type",
+indx);
+
+ sysfs_attr_init(&tz->trip_monitor_type_attrs[indx].attr.attr);
+ tz->trip_monitor_type_attrs[indx].attr.attr.name =
+ tz->trip_monitor_type_attrs[indx].name;
+ tz->trip_monitor_type_attrs[indx].attr.attr.mode = S_IRUGO;
+ tz->trip_monitor_type_attrs[indx].attr.show =
+ trip_point_monitor_type_show;
+ attrs[indx + tz->trips] =
+ &tz->trip_monitor_type_attrs[indx].attr.attr;
+
/* create trip temp attribute */
snprintf(tz->trip_temp_attrs[indx].nam
[PATCH 0/4] thermal: Introduce support for monitoring falling temperatures.
Thermal framework today supports monitoring for rising temperatures and subsequently initiating cooling action in case of a trip point being crossed. There are scenarios where a SoC needs some warming action to be activated if the temperature falls below a cetain allowable limit. Since warming action can be considered mirror opposite of cooling action, most of the thermal framework can be re-used to achieve this. To enable thermal framework to monitor falling temperature, a new parameter is added to the thermal trip point binding in the device tree to indicate the direction(rising/falling) of temperature monitoring. Thermal DT driver is extended to capture this information from the device tree entries and to reflect it in the thermal framework as a new enum variable in the thermal trip point structure. As an initial attempt, step-wise governor is extended to support bi-directional monitoring of temprature if a trip point is hit, depending on the newly introduced enum variable. Finally thermal sysfs entries are extended to indicate the trip point monitor direction. Patch series introducing various resources that are used as warming devices on Qualcomm sdm845: https://lkml.org/lkml/2019/7/29/749 (already merged) https://lkml.org/lkml/2019/9/10/727 (under review) Thara Gopinath (4): dt-bindings: thermal: Introduce monitor-falling binding to thermal trip point description thermal: Thermal core and sysfs changes needed to support bi-directional monitoring of trip points. thermal: of-thermal: Extend thermal dt driver to support bi-directional monitoring of a thermal trip point. thermal: step_wise: Extend thermal step-wise governor to monitor falling temperature. .../devicetree/bindings/thermal/thermal.txt| 8 +++ drivers/thermal/of-thermal.c | 22 drivers/thermal/step_wise.c| 59 +++-- drivers/thermal/thermal_sysfs.c| 60 -- include/linux/thermal.h| 10 include/uapi/linux/thermal.h | 2 +- 6 files changed, 141 insertions(+), 20 deletions(-) -- 2.1.4
[PATCH 3/4] thermal: of-thermal: Extend thermal dt driver to support bi-directional monitoring of a thermal trip point.
Introduce of_thermal_get_trip_monitor_type to return the direction
of monitoring of a thermal trip point. Also translate the DT information
regarding trip point monitor direction into the thermal framework.
Signed-off-by: Thara Gopinath
---
drivers/thermal/of-thermal.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index dc5093b..a5f6fdc 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -377,6 +377,20 @@ static int of_thermal_set_trip_hyst(struct
thermal_zone_device *tz, int trip,
return 0;
}
+static int of_thermal_get_trip_monitor_type
+ (struct thermal_zone_device *tz, int trip,
+enum thermal_trip_monitor_type *type)
+{
+ struct __thermal_zone *data = tz->devdata;
+
+ if (trip >= data->ntrips || trip < 0)
+ return -EDOM;
+
+ *type = data->trips[trip].monitor_type;
+
+ return 0;
+}
+
static int of_thermal_get_crit_temp(struct thermal_zone_device *tz,
int *temp)
{
@@ -401,6 +415,7 @@ static struct thermal_zone_device_ops of_thermal_ops = {
.set_trip_temp = of_thermal_set_trip_temp,
.get_trip_hyst = of_thermal_get_trip_hyst,
.set_trip_hyst = of_thermal_set_trip_hyst,
+ .get_trip_monitor_type = of_thermal_get_trip_monitor_type,
.get_crit_temp = of_thermal_get_crit_temp,
.bind = of_thermal_bind,
@@ -809,6 +824,7 @@ static int thermal_of_populate_trip(struct device_node *np,
{
int prop;
int ret;
+ bool is_monitor_falling;
ret = of_property_read_u32(np, "temperature", &prop);
if (ret < 0) {
@@ -830,6 +846,12 @@ static int thermal_of_populate_trip(struct device_node *np,
return ret;
}
+ is_monitor_falling = of_property_read_bool(np, "monitor-falling");
+ if (is_monitor_falling)
+ trip->monitor_type = THERMAL_TRIP_MONITOR_FALLING;
+ else
+ trip->monitor_type = THERMAL_TRIP_MONITOR_RISING;
+
/* Required for cooling map matching */
trip->np = np;
of_node_get(np);
--
2.1.4
[PATCH 1/4] dt-bindings: thermal: Introduce monitor-falling parameter to thermal trip point binding
Introduce a new binding parameter to thermal trip point description to indicate whether the temperature level specified by the trip point is monitored for a rise or fall in temperature. Signed-off-by: Thara Gopinath --- Documentation/devicetree/bindings/thermal/thermal.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt index ca14ba9..849a2a9 100644 --- a/Documentation/devicetree/bindings/thermal/thermal.txt +++ b/Documentation/devicetree/bindings/thermal/thermal.txt @@ -90,6 +90,14 @@ Required properties: "critical": Hardware not reliable. Type: string +Optional property: +- monitor-falling: Indicate whether the system action is kick + Type: booleanstarted when the temperature falls below or rises + above the trip temperature level indicated in + "temperature".If true, the trip point is monitored + for falling temperature else the trip point is + monitored for rising temperature. + * Cooling device maps The cooling device maps node is a node to describe how cooling devices -- 2.1.4
Re: [PATCH v4 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
Hi Kirill
[On behalf of justin...@arm.com because some mails are filted...]
On 2019/9/18 22:00, Kirill A. Shutemov wrote:
On Wed, Sep 18, 2019 at 09:19:14PM +0800, Jia He wrote:
When we tested pmdk unit test [1] vmmalloc_fork TEST1 in arm64 guest, there
will be a double page fault in __copy_from_user_inatomic of cow_user_page.
Below call trace is from arm64 do_page_fault for debugging purpose
[ 110.016195] Call trace:
[ 110.016826] do_page_fault+0x5a4/0x690
[ 110.017812] do_mem_abort+0x50/0xb0
[ 110.018726] el1_da+0x20/0xc4
[ 110.019492] __arch_copy_from_user+0x180/0x280
[ 110.020646] do_wp_page+0xb0/0x860
[ 110.021517] __handle_mm_fault+0x994/0x1338
[ 110.022606] handle_mm_fault+0xe8/0x180
[ 110.023584] do_page_fault+0x240/0x690
[ 110.024535] do_mem_abort+0x50/0xb0
[ 110.025423] el0_da+0x20/0x24
The pte info before __copy_from_user_inatomic is (PTE_AF is cleared):
[9b007000] pgd=00023d4f8003, pud=00023da9b003,
pmd=00023d4b3003, pte=36298607bd3
As told by Catalin: "On arm64 without hardware Access Flag, copying from
user will fail because the pte is old and cannot be marked young. So we
always end up with zeroed page after fork() + CoW for pfn mappings. we
don't always have a hardware-managed access flag on arm64."
This patch fix it by calling pte_mkyoung. Also, the parameter is
changed because vmf should be passed to cow_user_page()
[1] https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork
Reported-by: Yibo Cai
Signed-off-by: Jia He
---
mm/memory.c | 35 ++-
1 file changed, 30 insertions(+), 5 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index e2bb51b6242e..d2c130a5883b 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -118,6 +118,13 @@ int randomize_va_space __read_mostly =
2;
#endif
+#ifndef arch_faults_on_old_pte
+static inline bool arch_faults_on_old_pte(void)
+{
+ return false;
+}
+#endif
+
static int __init disable_randmaps(char *s)
{
randomize_va_space = 0;
@@ -2140,8 +2147,12 @@ static inline int pte_unmap_same(struct mm_struct *mm,
pmd_t *pmd,
return same;
}
-static inline void cow_user_page(struct page *dst, struct page *src, unsigned long va, struct vm_area_struct *vma)
+static inline void cow_user_page(struct page *dst, struct page *src,
+struct vm_fault *vmf)
{
+ struct vm_area_struct *vma = vmf->vma;
+ unsigned long addr = vmf->address;
+
debug_dma_assert_idle(src);
/*
@@ -2152,20 +2163,34 @@ static inline void cow_user_page(struct page *dst,
struct page *src, unsigned lo
*/
if (unlikely(!src)) {
void *kaddr = kmap_atomic(dst);
- void __user *uaddr = (void __user *)(va & PAGE_MASK);
+ void __user *uaddr = (void __user *)(addr & PAGE_MASK);
+ pte_t entry;
/*
* This really shouldn't fail, because the page is there
* in the page tables. But it might just be unreadable,
* in which case we just give up and fill the result with
-* zeroes.
+* zeroes. On architectures with software "accessed" bits,
+* we would take a double page fault here, so mark it
+* accessed here.
*/
+ if (arch_faults_on_old_pte() && !pte_young(vmf->orig_pte)) {
+ spin_lock(vmf->ptl);
+ if (likely(pte_same(*vmf->pte, vmf->orig_pte))) {
+ entry = pte_mkyoung(vmf->orig_pte);
+ if (ptep_set_access_flags(vma, addr,
+ vmf->pte, entry, 0))
+ update_mmu_cache(vma, addr, vmf->pte);
+ }
I don't follow.
So if pte has changed under you, you don't set the accessed bit, but never
the less copy from the user.
What makes you think it will not trigger the same problem?
I think we need to make cow_user_page() fail in this case and caller --
wp_page_copy() -- return zero. If the fault was solved by other thread, we
are fine. If not userspace would re-fault on the same address and we will
handle the fault from the second attempt.
Thanks for the pointing. How about make cow_user_page() be returned
VM_FAULT_RETRY? Then in do_page_fault(), it can retry the page fault?
---
Cheers,
Justin (Jia He)
+ spin_unlock(vmf->ptl);
+ }
+
if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE))
clear_page(kaddr);
kunmap_atomic(kaddr);
flush_dcache_page(dst);
} else
- copy_user_highpage(dst, src, va, vma);
+ copy_user_highpage(dst, src, addr, vma);
}
static gfp_t __get_fault_gfp_mask(struct vm_area_struct *vma)
@@ -2318,7
RE: [PATCH] staging: exfat: add exfat filesystem code to
[..] > Put it in drivers/staging/sdfat/. > > But really we want someone from Samsung to say that they will treat > the staging version as upstream. It doesn't work when people apply > fixes to their version and a year later back port the fixes into > staging. The staging tree is going to have tons and tons of white space > fixes so backports are a pain. All development needs to be upstream > first where the staging driver is upstream. Otherwise we should just > wait for Samsung to get it read to be merged in fs/ and not through the > staging tree. Quite frankly, This whole thing came as a huge-huge surprise to us, we did not initiate upstreaming of exfat/sdfat code and, as of this moment, I'm not exactly sure that we are prepared for any immediate radical changes to our internal development process which people all of a sudden want from us. I need to discuss with related people on internal thread. please wait a while:) Thanks! > > regards, > dan carpenter >
Re: [PATCH] serial: sprd: Add polling IO support
Baolin Wang 于2019年9月18日周三 下午8:10写道：
>
> Hi Lanqing,
>
> On Wed, 18 Sep 2019 at 16:16, Lanqing Liu wrote:
> >
> > In order to access the UART without the interrupts, the kernel uses
> > the basic polling methods for IO with the device. With these methods
> > implemented, it is now possible to enable kgdb during early boot over
> > serial.
> >
> > Signed-off-by: Lanqing Liu
> > ---
> > drivers/tty/serial/sprd_serial.c | 22 ++
> > 1 file changed, 22 insertions(+)
> >
> > diff --git a/drivers/tty/serial/sprd_serial.c
> > b/drivers/tty/serial/sprd_serial.c
> > index 73d71a4..579ab41 100644
> > --- a/drivers/tty/serial/sprd_serial.c
> > +++ b/drivers/tty/serial/sprd_serial.c
> > @@ -911,6 +911,24 @@ static void sprd_pm(struct uart_port *port, unsigned
> > int state,
> > }
> > }
> >
> > +#ifdef CONFIG_CONSOLE_POLL
> > +static int sprd_poll_get_char(struct uart_port *port)
> > +{
> > + while (!(serial_in(port, SPRD_STS1) & SPRD_RX_FIFO_CNT_MASK))
> > + cpu_relax();
> > +
> > + return serial_in(port, SPRD_RXD);
> > +}
> > +
> > +static void sprd_poll_put_char(struct uart_port *port, unsigned char ch)
> > +{
> > + while (serial_in(port, SPRD_STS1) & SPRD_TX_FIFO_CNT_MASK)
> > + cpu_relax();
> > +
> > + serial_out(port, SPRD_TXD, ch);
> > +}
> > +#endif
>
> When I tested your patch, I found only one case can work if the port
> used by KGDB is same with the port selected as console, which means
> this port will be powered on all the time. We had implemented the
> power management for the UART ports, so I think you should enable the
> clock for the port used by KGDB in poll_init(), then other ports can
> be used by KGDB.
>
Yes, agree with you. I will add poll_init() support. Thanks for your
comments.
> > +
> > static const struct uart_ops serial_sprd_ops = {
> > .tx_empty = sprd_tx_empty,
> > .get_mctrl = sprd_get_mctrl,
> > @@ -928,6 +946,10 @@ static void sprd_pm(struct uart_port *port, unsigned
> > int state,
> > .config_port = sprd_config_port,
> > .verify_port = sprd_verify_port,
> > .pm = sprd_pm,
> > +#ifdef CONFIG_CONSOLE_POLL
> > + .poll_get_char = sprd_poll_get_char,
> > + .poll_put_char = sprd_poll_put_char,
> > +#endif
> > };
> >
> > #ifdef CONFIG_SERIAL_SPRD_CONSOLE
> > --
> > 1.9.1
> >
>
>
> --
> Baolin Wang
> Best Regards
[git pull] autofs-related stuff
The most interesting part here is getting rid of the last trylock loop on dentry->d_lock - the ones in fs/dcache.c had been dealt with several years ago, but there'd been leftovers in fs/autofs/expire.c The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.autofs for you to fetch changes up to 5f68056ca50fdd3954a93ae66fea7452abddb66f: autofs_lookup(): hold ->d_lock over playing with ->d_flags (2019-07-27 10:03:14 -0400) Al Viro (3): autofs: simplify get_next_positive_...(), get rid of trylocks get rid of autofs_info->active_count autofs_lookup(): hold ->d_lock over playing with ->d_flags fs/autofs/autofs_i.h | 1 - fs/autofs/expire.c | 103 --- fs/autofs/root.c | 44 ++ 3 files changed, 44 insertions(+), 104 deletions(-)
[PATCH 2/2] x86/mm: replace a goto by merging two if clause
There is only one place to use good_area jump, which could be reduced by
merging the following two if clause.
Signed-off-by: Wei Yang
---
arch/x86/mm/fault.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 9d18b73b5f77..72ce6c69e195 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1390,18 +1390,17 @@ void do_user_addr_fault(struct pt_regs *regs,
vma = find_vma(mm, address);
if (unlikely(!vma))
goto bad_area;
- if (likely(vma->vm_start <= address))
- goto good_area;
- if (unlikely(!(vma->vm_flags & VM_GROWSDOWN)))
- goto bad_area;
- if (unlikely(expand_stack(vma, address)))
+ if (likely(vma->vm_start <= address)) {
+ /* good area, do nothing */
+ } else if (unlikely(!(vma->vm_flags & VM_GROWSDOWN)) ||
+ unlikely(expand_stack(vma, address))) {
goto bad_area;
+ }
/*
* Ok, we have a good vm_area for this memory access, so
* we can handle it..
*/
-good_area:
if (unlikely(access_error(hw_error_code, vma))) {
bad_area_access_error(regs, hw_error_code, address, vma);
return;
--
2.17.1
[PATCH 1/2] x86/mm: consolidate bad_area handling to the end
There are totally 7 bad_area[_nosemaphore] error branch in
do_user_addr_fault().
Consolidate all these handling to the end to make the code a little
neat.
BTW, after doing so, function bad_area is not used any more. Remove it.
Signed-off-by: Wei Yang
---
arch/x86/mm/fault.c | 44
1 file changed, 16 insertions(+), 28 deletions(-)
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 9ceacd1156db..9d18b73b5f77 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -933,12 +933,6 @@ __bad_area(struct pt_regs *regs, unsigned long error_code,
__bad_area_nosemaphore(regs, error_code, address, pkey, si_code);
}
-static noinline void
-bad_area(struct pt_regs *regs, unsigned long error_code, unsigned long address)
-{
- __bad_area(regs, error_code, address, 0, SEGV_MAPERR);
-}
-
static inline bool bad_area_access_from_pkeys(unsigned long error_code,
struct vm_area_struct *vma)
{
@@ -1313,19 +1307,14 @@ void do_user_addr_fault(struct pt_regs *regs,
if (unlikely(cpu_feature_enabled(X86_FEATURE_SMAP) &&
!(hw_error_code & X86_PF_USER) &&
!(regs->flags & X86_EFLAGS_AC)))
- {
- bad_area_nosemaphore(regs, hw_error_code, address);
- return;
- }
+ goto bad_area_nosem;
/*
* If we're in an interrupt, have no user context or are running
* in a region with pagefaults disabled then we must not take the fault
*/
- if (unlikely(faulthandler_disabled() || !mm)) {
- bad_area_nosemaphore(regs, hw_error_code, address);
- return;
- }
+ if (unlikely(faulthandler_disabled() || !mm))
+ goto bad_area_nosem;
/*
* It's safe to allow irq's after cr2 has been saved and the
@@ -1385,8 +1374,7 @@ void do_user_addr_fault(struct pt_regs *regs,
* Fault from code in kernel from
* which we do not expect faults.
*/
- bad_area_nosemaphore(regs, hw_error_code, address);
- return;
+ goto bad_area_nosem;
}
retry:
down_read(&mm->mmap_sem);
@@ -1400,20 +1388,14 @@ void do_user_addr_fault(struct pt_regs *regs,
}
vma = find_vma(mm, address);
- if (unlikely(!vma)) {
- bad_area(regs, hw_error_code, address);
- return;
- }
+ if (unlikely(!vma))
+ goto bad_area;
if (likely(vma->vm_start <= address))
goto good_area;
- if (unlikely(!(vma->vm_flags & VM_GROWSDOWN))) {
- bad_area(regs, hw_error_code, address);
- return;
- }
- if (unlikely(expand_stack(vma, address))) {
- bad_area(regs, hw_error_code, address);
- return;
- }
+ if (unlikely(!(vma->vm_flags & VM_GROWSDOWN)))
+ goto bad_area;
+ if (unlikely(expand_stack(vma, address)))
+ goto bad_area;
/*
* Ok, we have a good vm_area for this memory access, so
@@ -1483,6 +1465,12 @@ void do_user_addr_fault(struct pt_regs *regs,
}
check_v8086_mode(regs, address, tsk);
+ return;
+
+bad_area:
+ up_read(&mm->mmap_sem);
+bad_area_nosem:
+ bad_area_nosemaphore(regs, hw_error_code, address);
}
NOKPROBE_SYMBOL(do_user_addr_fault);
--
2.17.1
[git pull] more mount API conversions
Conversions to new API for shmem and friends and for mount_mtd()-using
filesystems.
As for the rest of the work.mount in -next, some of the conversions
belong in the individual trees (e.g. binderfs one should definitely go through
android folks, after getting redone on top of their changes). I'm going to
drop those and send the rest (trivial ones + stuff ACKed by maintainers) in
a separate series - by that point they are independent from each other.
Some stuff has already migrated into individual trees (NFS conversion,
for example, or FUSE stuff, etc.); those presumably will go through the
regular merges from corresponding trees.
The following changes since commit 0f071004109d9c8de7023b9a64fa2ba3fa87cbed:
mtd: Provide fs_context-aware mount_mtd() replacement (2019-09-05 14:34:23
-0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.mount2
for you to fetch changes up to 74983ac20aeafc88d9ceed64a8bf2a9024c488d5:
vfs: Make fs_parse() handle fs_param_is_fd-type params better (2019-09-12
21:06:14 -0400)
Al Viro (7):
devtmpfs: don't mix {ramfs,shmem}_fill_super() with mount_single()
make ramfs_fill_super() static
make shmem_fill_super() static
shmem_parse_options(): use a separate structure to keep the results
shmem_parse_options(): don't bother with mpol in separate variable
shmem_parse_options(): take handling a single option into a helper
shmem_parse_one(): switch to use of fs_parse()
David Howells (8):
vfs: Add a single-or-reconfig keying to vfs_get_super()
vfs: Convert romfs to use the new mount API
vfs: Convert cramfs to use the new mount API
vfs: Convert jffs2 to use the new mount API
mtd: Kill mount_mtd()
vfs: Convert squashfs to use the new mount API
vfs: Convert ramfs, shmem, tmpfs, devtmpfs, rootfs to use the new mount
API
vfs: Make fs_parse() handle fs_param_is_fd-type params better
drivers/base/devtmpfs.c| 38 +++--
drivers/mtd/mtdsuper.c | 189 --
fs/cramfs/inode.c | 69
fs/fs_parser.c | 18 ++-
fs/jffs2/fs.c | 21 +--
fs/jffs2/os-linux.h| 4 +-
fs/jffs2/super.c | 172 ++--
fs/ramfs/inode.c | 99 +++-
fs/romfs/super.c | 46 +++---
fs/squashfs/super.c| 100 ++--
fs/super.c | 35 -
include/linux/fs_context.h | 4 +
include/linux/mtd/super.h | 3 -
include/linux/ramfs.h | 6 +-
include/linux/shmem_fs.h | 3 +-
init/do_mounts.c | 11 +-
mm/shmem.c | 385 +
17 files changed, 609 insertions(+), 594 deletions(-)
[v5,2/2] rtc: pcf85263/pcf85363: support PM, wakeup device, improve performance
Add some features as follow:
- Set quartz oscillator load capacitance by DT
(generate more accuracy frequency)
- Set quartz oscillator drive control by DT
(reduce/increase the current consumption)
- Set low jitter mode by DT
(improve jitter performance)
- Set wakeup source by DT
(wakeup device from suspend
- Select interrupt output pin by DT
(INTA/TS(INTB))
- Select interrupt type by DT
- Add power management
- Add ioctl to check rtc status
(check whether oscillator of pcf85263/pcf85363 is stopped)
Datasheet url:
- https://www.nxp.com/docs/en/data-sheet/PCF85263A.pdf
- https://www.nxp.com/docs/en/data-sheet/PCF85363A.pdf
Signed-off-by: Martin Fuzzey
Signed-off-by: Biwen Li
---
Change in v5:
- Replace nxp,quartz-drive-strength
with quartz-drive-strength-ohms
- Select ohm unit for quartz drive strength
Change in v4:
- Add nxp,rtc-interrupt-type property
- Interrupt output pin Cooperate with interrupt type
Change in v3:
- Fix compilation error
Change in v2:
- Replace properties name
quartz-load-capacitance -> quartz-load-femtofarads
quartz-drive-strength -> nxp,quartz-drive-strength
quartz-low-jitter -> nxp,quartz-low-jitter
- Set default interrupt-output-pin as "INTA"
drivers/rtc/rtc-pcf85363.c | 372 ++---
1 file changed, 349 insertions(+), 23 deletions(-)
diff --git a/drivers/rtc/rtc-pcf85363.c b/drivers/rtc/rtc-pcf85363.c
index 3450d615974d..4240c6b57875 100644
--- a/drivers/rtc/rtc-pcf85363.c
+++ b/drivers/rtc/rtc-pcf85363.c
@@ -18,6 +18,16 @@
#include
#include
+/* Quartz capacitance */
+#define PCF85363_QUARTZCAP_7pF 0
+#define PCF85363_QUARTZCAP_6pF 1
+#define PCF85363_QUARTZCAP_12p5pF 2
+
+/* Quartz drive strength */
+#define PCF85363_QUARTZDRIVE_NORMAL0
+#define PCF85363_QUARTZDRIVE_LOW 1
+#define PCF85363_QUARTZDRIVE_HIGH 2
+
/*
* Date/Time registers
*/
@@ -96,10 +106,20 @@
#define FLAGS_PIF BIT(7)
#define PIN_IO_INTAPM GENMASK(1, 0)
-#define PIN_IO_INTA_CLK0
-#define PIN_IO_INTA_BAT1
-#define PIN_IO_INTA_OUT2
-#define PIN_IO_INTA_HIZ3
+#define PIN_IO_INTAPM_SHIFT0
+#define PIN_IO_INTA_CLK(0 << PIN_IO_INTAPM_SHIFT)
+#define PIN_IO_INTA_BAT(1 << PIN_IO_INTAPM_SHIFT)
+#define PIN_IO_INTA_OUT(2 << PIN_IO_INTAPM_SHIFT)
+#define PIN_IO_INTA_HIZ(3 << PIN_IO_INTAPM_SHIFT)
+
+#define PIN_IO_TSPM GENMASK(3, 2)
+#define PIN_IO_TSPM_SHIFT 2
+#define PIN_IO_TS_DISABLE (0x0 << PIN_IO_TSPM_SHIFT)
+#define PIN_IO_TS_INTB_OUT (0x1 << PIN_IO_TSPM_SHIFT)
+#define PIN_IO_TS_CLK_OUT (0x2 << PIN_IO_TSPM_SHIFT)
+#define PIN_IO_TS_IN (0x3 << PIN_IO_TSPM_SHIFT)
+
+#define PIN_IO_CLKPM BIT(7) /* 0 = enable CLK pin,1 = disable CLK pin */
#define STOP_EN_STOP BIT(0)
@@ -107,9 +127,35 @@
#define NVRAM_SIZE 0x40
+#define DT_SECS_OS BIT(7)
+
+#define CTRL_OSCILLATOR_CL_MASKGENMASK(1, 0)
+#define CTRL_OSCILLATOR_CL_SHIFT 0
+#define CTRL_OSCILLATOR_OSCD_MASK GENMASK(3, 2)
+#define CTRL_OSCILLATOR_OSCD_SHIFT 2
+#define CTRL_OSCILLATOR_LOWJ BIT(4)
+
+#define CTRL_FUNCTION_COF_OFF 0x7 /* No clock output */
+
+enum pcf85363_irqpin {
+ IRQPIN_INTA,
+ IRQPIN_INTB,
+ IRQPIN_MAX,
+};
+
+static const char *const pcf85363_irqpin_names[] = {
+ [IRQPIN_INTA] = "INTA",
+ [IRQPIN_INTB] = "INTB",
+ [IRQPIN_MAX] = "",
+};
+
+
struct pcf85363 {
+ struct device *dev;
struct rtc_device *rtc;
struct regmap *regmap;
+ int irq;
+ u8 irq_type[IRQPIN_MAX];
};
struct pcf85x63_config {
@@ -205,26 +251,60 @@ static int pcf85363_rtc_read_alarm(struct device *dev,
struct rtc_wkalrm *alrm)
return 0;
}
-static int _pcf85363_rtc_alarm_irq_enable(struct pcf85363 *pcf85363, unsigned
- int enabled)
+static int _pcf85363_rtc_alarm_irq_enable(struct pcf85363 *pcf85363,
+ unsigned int enabled,
+ int irq_pin)
{
- unsigned int alarm_flags = ALRM_SEC_A1E | ALRM_MIN_A1E | ALRM_HR_A1E |
+ unsigned int alarm1_flags = ALRM_SEC_A1E | ALRM_MIN_A1E | ALRM_HR_A1E |
ALRM_DAY_A1E | ALRM_MON_A1E;
- int ret;
+ unsigned int alarm2_flags = ALRM_MIN_A2E | ALRM_HR_A2E | ALRM_DAY_A2E;
+ unsigned int alarm_flags = 0;
+ int ret, reg;
+ u8 reg_val = 0, ctrl_flags = FLAGS_A1F;
+
+ if (pcf85363->irq_type[irq_pin] & INT_A1IE) {
+ alarm_flags = alarm1_flags;
+ ctrl_flags = FLAGS_A1F;
+ }
+ if (pcf85363->irq_type[irq_pin] & INT_A2IE) {
+ alarm_flags |= alarm2_flags;
+ ctrl_flags |= FLAGS_A2F;
+ }
ret = r
