Re: [PATCH v10 4/4] arm64: boot: dts: qcom: pm8150b: Add DTS node for PMIC VBUS booster
On Thu, Oct 08, 2020 at 04:59:34PM -0700, Wesley Cheng wrote:
> Add the required DTS node for the USB VBUS output regulator, which is
> available on PM8150B. This will provide the VBUS source to connected
> peripherals.
>
> Signed-off-by: Wesley Cheng
> ---
> arch/arm64/boot/dts/qcom/pm8150b.dtsi | 6 ++
> arch/arm64/boot/dts/qcom/sm8150-mtp.dts | 4
> 2 files changed, 10 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
> b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
> index 2bf385f5a55a..49ea597cc0c5 100644
> --- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
> +++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
> @@ -53,6 +53,12 @@ power-on@800 {
> status = "disabled";
> };
>
> + pm8150b_vbus: regulator@1100 {
> + compatible = "qcom,pm8150b-vbus-reg";
> + status = "disabled";
> + reg = <0x1100>;
> + };
> +
> pm8150b_typec: usb-typec@1500 {
> compatible = "qcom,pm8150b-usb-typec";
> status = "disabled";
> diff --git a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
> b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
> index 6c6325c3af59..ba3b5b802954 100644
> --- a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
> +++ b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
> @@ -409,6 +409,10 @@ _mem_phy {
> vdda-pll-max-microamp = <19000>;
> };
>
> +_vbus {
> + status = "okay";
> +};
Why aren't you enabling the TypeC node and providing a complete example?
> +
> _1_hsphy {
> status = "okay";
> vdda-pll-supply = <_usb_hs_core>;
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
[PATCH v3 2/5] media: dt-bindings: media: renesas,drif: Convert to json-schema
Convert the Renesas DRIF bindings to DT schema and update MAINTAINERS accordingly. Signed-off-by: Fabrizio Castro Reviewed-by: Lad Prabhakar Reviewed-by: Laurent Pinchart --- v2->3: * Removed the definition of pinctrl-0 and pinctrl-names, as suggested by Geert * Added "power-domains" to the list of required properties, as suggested by Geert * Reworked the conditional requirements, Geert, what do you think? v1->v2: * s/controller/Controller/ in the title of renesas,drif.yaml as suggested by Laurent. .../bindings/media/renesas,drif.txt | 177 --- .../bindings/media/renesas,drif.yaml | 282 ++ MAINTAINERS | 2 +- 3 files changed, 283 insertions(+), 178 deletions(-) delete mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.yaml diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt b/Documentation/devicetree/bindings/media/renesas,drif.txt deleted file mode 100644 index 0d8974aa8b38.. --- a/Documentation/devicetree/bindings/media/renesas,drif.txt +++ /dev/null @@ -1,177 +0,0 @@ -Renesas R-Car Gen3 Digital Radio Interface controller (DRIF) - - -R-Car Gen3 DRIF is a SPI like receive only slave device. A general -representation of DRIF interfacing with a master device is shown below. - -+-++-+ -| |-SCK--->|CLK | -| Master|-SS>|SYNC DRIFn (slave) | -| |-SD0--->|D0 | -| |-SD1--->|D1 | -+-++-+ - -As per datasheet, each DRIF channel (drifn) is made up of two internal -channels (drifn0 & drifn1). These two internal channels share the common -CLK & SYNC. Each internal channel has its own dedicated resources like -irq, dma channels, address space & clock. This internal split is not -visible to the external master device. - -The device tree model represents each internal channel as a separate node. -The internal channels sharing the CLK & SYNC are tied together by their -phandles using a property called "renesas,bonding". For the rest of -the documentation, unless explicitly stated, the word channel implies an -internal channel. - -When both internal channels are enabled they need to be managed together -as one (i.e.) they cannot operate alone as independent devices. Out of the -two, one of them needs to act as a primary device that accepts common -properties of both the internal channels. This channel is identified by a -property called "renesas,primary-bond". - -To summarize, - - When both the internal channels that are bonded together are enabled, - the zeroth channel is selected as primary-bond. This channels accepts - properties common to all the members of the bond. - - When only one of the bonded channels need to be enabled, the property - "renesas,bonding" or "renesas,primary-bond" will have no effect. That - enabled channel can act alone as any other independent device. - -Required properties of an internal channel: -- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of R8A7795 SoC. - "renesas,r8a7796-drif" if DRIF controller is a part of R8A7796 SoC. - "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible device. - - When compatible with the generic version, nodes must list the - SoC-specific version corresponding to the platform first - followed by the generic version. - -- reg: offset and length of that channel. -- interrupts: associated with that channel. -- clocks: phandle and clock specifier of that channel. -- clock-names: clock input name string: "fck". -- dmas: phandles to the DMA channels. -- dma-names: names of the DMA channel: "rx". -- renesas,bonding: phandle to the other channel. - -Optional properties of an internal channel: -- power-domains: phandle to the respective power domain. - -Required properties of an internal channel when: - - It is the only enabled channel of the bond (or) - - If it acts as primary among enabled bonds - -- pinctrl-0: pin control group to be used for this channel. -- pinctrl-names: must be "default". -- renesas,primary-bond: empty property indicating the channel acts as primary - among the bonded channels. -- port: child port node corresponding to the data input, in accordance with - the video interface bindings defined in - Documentation/devicetree/bindings/media/video-interfaces.txt. The port - node must contain at
[PATCH v3 4/5] media: dt-bindings: media: renesas,drif: Add r8a77965 support
The r8a77965 (a.k.a. R-Car M3-N) device tree schema is compatible with the already documented R-Car Gen3 devices. Document r8a77965 support within renesas,drif.yaml. Signed-off-by: Fabrizio Castro --- v2->v3: * New patch Documentation/devicetree/bindings/media/renesas,drif.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/media/renesas,drif.yaml b/Documentation/devicetree/bindings/media/renesas,drif.yaml index ae50b1448320..89445ddd598e 100644 --- a/Documentation/devicetree/bindings/media/renesas,drif.yaml +++ b/Documentation/devicetree/bindings/media/renesas,drif.yaml @@ -53,6 +53,7 @@ properties: - enum: - renesas,r8a7795-drif# R-Car H3 - renesas,r8a7796-drif# R-Car M3-W +- renesas,r8a77965-drif # R-Car M3-N - renesas,r8a77990-drif # R-Car E3 - const: renesas,rcar-gen3-drif # Generic R-Car Gen3 compatible device -- 2.25.1
Re: [PATCH 1/5] clk: qcom: Add SDM660 Multimedia Clock Controller (MMCC) driver
Actually, correction. This parent is used by cpp_clk_src.
Re: i8042_init: PS/2 mouse not detected with ACPIPnP/PnPBIOS
Dear Rafael, dear Dmitry,
Am 12.10.20 um 13:00 schrieb Rafael J. Wysocki:
On Mon, Oct 12, 2020 at 12:50 PM Paul Menzel wrote:
Am 12.10.20 um 12:39 schrieb Rafael J. Wysocki:
On Sun, Oct 11, 2020 at 1:08 AM Paul Menzel wrote:
Am 08.10.20 um 00:16 schrieb Dmitry Torokhov:
On Wed, Oct 07, 2020 at 11:18:41PM +0200, Paul Menzel wrote:
On the Asus F2A85-M PRO Linux 5.9-rc8 (and previous versions) does not
recognize a plugged in PS/2 mouse using the Plug & Play method. The PS/2
keyboard is detected fine, and using `i8042.nopnp`, the PS/2 mouse also
works.
[1.035915] calling i8042_init+0x0/0x42d @ 1
[1.035947] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
[1.035948] i8042: PNP: PS/2 appears to have AUX port disabled, if this is
incorrect please boot with i8042.nopnp
[1.036589] serio: i8042 KBD port at 0x60,0x64 irq 1
[1.036621] initcall i8042_init+0x0/0x42d returned 0 after 687 usecs
But, the DSDT includes the “mouse device”. From
acpidump > dump.bin; acpixtract dump.bin; iasl -d *dat; more dsdt.dsl
we get
Device (PS2M)
{
Name (_HID, EisaId ("PNP0F03") /* Microsoft PS/2-style
Mouse */) // _HID: Hardware ID
Name (_CID, EisaId ("PNP0F13") /* PS/2 Mouse */) //
_CID: Compatible ID
Method (_STA, 0, NotSerialized) // _STA: Status
{
If ((IOST & 0x4000))
{
Return (0x0F)
}
Else
{
Return (Zero)
}
}
and the identifiers PNP0F03 and PNP0F13 are both listed in the array
`pnp_aux_devids[]`. But adding print statements to `i8042_pnp_aux_probe()`,
I do not see them, so the function does not seem to be called.
My guess is that _STA returns 0 indicating that the device is not
present. I would try tracking where IOST is being set and figuring out
why it does not have mouse bit enabled.
Does the ACPI subsystem allow to track, how ACPI variables(?) like IOST
are read and set?
My guess would be that IOST is a field in an operation region which
would indicate that it is initialized by the bootstrap part of the
BIOS.
Thank you for your answer. But how can I verify that?
Inspecting the ACPI tables from the system in question could help you
to find out whether or not IOST really is a field in an operation
region, but its initial value may not be possible to determine this
way.
Is there a Linux kernel parameter, that would print it?
Not that I know of.
I created an issue in the Linux kernel bugtracker [1] and attached the
output of `acpidump` there.
Could
If ((IOST & 0x4000))
versus
If ((IOST & 0x0400))
be a typo?
Kind regards,
Paul
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=209657
[PATCH v3 0/5] Add r8a77965 DRIF support
Dear All, this series is to add DRIF support for the r8a77965 (a.k.a. R-Car M3-N), but it also (re)includes the patches for the MAINTAINERS and documentation files, modified according to Ramesh's and Geert's comments. Thanks, Fab Fabrizio Castro (5): MAINTAINERS: Update MAINTAINERS for Renesas DRIF driver media: dt-bindings: media: renesas,drif: Convert to json-schema media: dt-bindings: media: renesas,drif: Add r8a77990 support media: dt-bindings: media: renesas,drif: Add r8a77965 support arm64: dts: r8a77965: Add DRIF support .../bindings/media/renesas,drif.txt | 177 --- .../bindings/media/renesas,drif.yaml | 284 ++ MAINTAINERS | 4 +- arch/arm64/boot/dts/renesas/r8a77965.dtsi | 120 4 files changed, 406 insertions(+), 179 deletions(-) delete mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.yaml -- 2.25.1
[PATCH v3 1/5] MAINTAINERS: Update MAINTAINERS for Renesas DRIF driver
Add Fabrizio castro and remove Ramesh Shanmugasundaram. Signed-off-by: Fabrizio Castro Reviewed-by: Laurent Pinchart --- v2->v3: * Removed Ramesh Shanmugasundaram as maintainer, as suggested by Ramesh * Reworked commit title and changelog v1->v2: * No change MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9a54806ebf02..4ff8e65df4e7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10835,7 +10835,7 @@ F: drivers/media/platform/renesas-ceu.c F: include/media/drv-intf/renesas-ceu.h MEDIA DRIVERS FOR RENESAS - DRIF -M: Ramesh Shanmugasundaram +M: Fabrizio Castro L: linux-me...@vger.kernel.org L: linux-renesas-...@vger.kernel.org S: Supported -- 2.25.1
[PATCH v5 2/2] ovl: introduce new "uuid=off" option for inodes index feature
This replaces uuid with null in overlayfs file handles and thus relaxes
uuid checks for overlay index feature. It is only possible in case there
is only one filesystem for all the work/upper/lower directories and bare
file handles from this backing filesystem are unique. In other case when
we have multiple filesystems lets just fallback to "uuid=on" which is
and equivalent of how it worked before with all uuid checks.
This is needed when overlayfs is/was mounted in a container with index
enabled (e.g.: to be able to resolve inotify watch file handles on it to
paths in CRIU), and this container is copied and started alongside with
the original one. This way the "copy" container can't have the same uuid
on the superblock and mounting the overlayfs from it later would fail.
That is an example of the problem on top of loop+ext4:
dd if=/dev/zero of=loopbackfile.img bs=100M count=10
losetup -fP loopbackfile.img
losetup -a
#/dev/loop0: [64768]:35 (/loop-test/loopbackfile.img)
mkfs.ext4 loopbackfile.img
mkdir loop-mp
mount -o loop /dev/loop0 loop-mp
mkdir loop-mp/{lower,upper,work,merged}
mount -t overlay overlay -oindex=on,lowerdir=loop-mp/lower,\
upperdir=loop-mp/upper,workdir=loop-mp/work loop-mp/merged
umount loop-mp/merged
umount loop-mp
e2fsck -f /dev/loop0
tune2fs -U random /dev/loop0
mount -o loop /dev/loop0 loop-mp
mount -t overlay overlay -oindex=on,lowerdir=loop-mp/lower,\
upperdir=loop-mp/upper,workdir=loop-mp/work loop-mp/merged
#mount: /loop-test/loop-mp/merged:
#mount(2) system call failed: Stale file handle.
If you just change the uuid of the backing filesystem, overlay is not
mounting any more. In Virtuozzo we copy container disks (ploops) when
create the copy of container and we require fs uuid to be unique for a new
container.
CC: Amir Goldstein
CC: Vivek Goyal
CC: Miklos Szeredi
CC: linux-unio...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Pavel Tikhomirov
---
v2: in v1 I missed actual uuid check skip
v3: rebase to overlayfs-next, replace uuid with null in file handles,
split ovl_fs propagation to function arguments to separate patch, add
separate bool "uuid=on/off" option, move numfs check up, add doc note.
v4: get rid of double negatives, remove nouuid leftower comment, fix
misprint in kernel config name
v5: fix typos; remove config option, module param, ovl_uuid_def and the
corresponding notes
Signed-off-by: Pavel Tikhomirov
---
Documentation/filesystems/overlayfs.rst | 5 +
fs/overlayfs/copy_up.c | 3 ++-
fs/overlayfs/namei.c| 4 +++-
fs/overlayfs/ovl_entry.h| 1 +
fs/overlayfs/super.c| 20
5 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/Documentation/filesystems/overlayfs.rst
b/Documentation/filesystems/overlayfs.rst
index 580ab9a0fe31..a3e588dc8437 100644
--- a/Documentation/filesystems/overlayfs.rst
+++ b/Documentation/filesystems/overlayfs.rst
@@ -563,6 +563,11 @@ This verification may cause significant overhead in some
cases.
Note: the mount options index=off,nfs_export=on are conflicting for a
read-write mount and will result in an error.
+Note: the mount option uuid=off can be used to replace UUID of the underlying
+filesystem in file handles with null, and effectively disable UUID checks. This
+can be useful in case the underlying disk is copied and the UUID of this copy
+is changed. This is only applicable if all lower/upper/work directories are on
+the same filesystem, otherwise it will fallback to normal behaviour.
Volatile mount
--
diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
index 3380039036d6..0b7e7a90a435 100644
--- a/fs/overlayfs/copy_up.c
+++ b/fs/overlayfs/copy_up.c
@@ -320,7 +320,8 @@ struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs,
struct dentry *real,
if (is_upper)
fh->fb.flags |= OVL_FH_FLAG_PATH_UPPER;
fh->fb.len = sizeof(fh->fb) + buflen;
- fh->fb.uuid = *uuid;
+ if (ofs->config.uuid)
+ fh->fb.uuid = *uuid;
return fh;
diff --git a/fs/overlayfs/namei.c b/fs/overlayfs/namei.c
index f058bf8e8b87..f731eb4d35f9 100644
--- a/fs/overlayfs/namei.c
+++ b/fs/overlayfs/namei.c
@@ -159,8 +159,10 @@ struct dentry *ovl_decode_real_fh(struct ovl_fs *ofs,
struct ovl_fh *fh,
/*
* Make sure that the stored uuid matches the uuid of the lower
* layer where file handle will be decoded.
+* In case of uuid=off option just make sure that stored uuid is null.
*/
- if (!uuid_equal(>fb.uuid, >mnt_sb->s_uuid))
+ if (ofs->config.uuid ? !uuid_equal(>fb.uuid, >mnt_sb->s_uuid) :
+ !uuid_is_null(>fb.uuid))
return NULL;
bytes = (fh->fb.len - offsetof(struct ovl_fb, fid));
diff --git a/fs/overlayfs/ovl_entry.h b/fs/overlayfs/ovl_entry.h
index 1b5a2094df8e..b7a73ea147b8 100644
--- a/fs/overlayfs/ovl_entry.h
+++
Re: [PATCH v10 2/4] dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding
On Thu, Oct 08, 2020 at 04:59:32PM -0700, Wesley Cheng wrote:
> Introduce the dt-binding for enabling USB type C orientation and role
> detection using the PM8150B. The driver will be responsible for receiving
> the interrupt at a state change on the CC lines, reading the
> orientation/role, and communicating this information to the remote
> clients, which can include a role switch node and a type C switch.
>
> Signed-off-by: Wesley Cheng
> ---
> .../bindings/usb/qcom,pmic-typec.yaml | 115 ++
> 1 file changed, 115 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
>
> diff --git a/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
> b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
> new file mode 100644
> index ..40e0a296f922
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
> @@ -0,0 +1,115 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/usb/qcom,pmic-typec.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: Qualcomm PMIC based USB type C Detection Driver
> +
> +maintainers:
> + - Wesley Cheng
> +
> +description: |
> + Qualcomm PMIC Type C Detect
> +
> +properties:
> + compatible:
> +enum:
> + - qcom,pm8150b-usb-typec
> +
> + reg:
> +maxItems: 1
> +description: Type C base address
> +
> + interrupts:
> +maxItems: 1
> +description: CC change interrupt from PMIC
> +
> + port:
> +description: Remote endpoint connection to the DRD switch
> +type: object
I don't understand what this is supposed to be. You'll have to expand
the example or provide a block diagram of what the connections/routing
looks like.
> +
> +properties:
> + endpoint:
> +description: Connection to the DRD switch being used
> +type: object
> +
> + connector:
> +$ref: /connector/usb-connector.yaml#
> +description: Connector type for remote endpoints
> +type: object
> +
> +properties:
> + compatible:
> +enum:
> + - usb-c-connector
> +
> + power-role: true
> + data-role: true
> +
> + ports:
> +description: Remote endpoint connections for type C paths
> +type: object
> +
> +properties:
> + port@1:
> +description: Remote endpoints for the Super Speed path
> +type: object
> +
> +properties:
> + endpoint:
> +description: Connection to USB type C mux node
> +type: object
> +
> +required:
> + - compatible
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - connector
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +pm8150b {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +pm8150b_typec: usb-typec@1500 {
> +compatible = "qcom,pm8150b-usb-typec";
> +reg = <0x1500>;
> +interrupts = <0x2 0x15 0x5 IRQ_TYPE_EDGE_RISING>;
> +
> +port {
> +usb3_role: endpoint {
> +remote-endpoint = <_drd_switch>;
> +};
> +};
> +
> +connector {
> +compatible = "usb-c-connector";
> +power-role = "dual";
> +data-role = "dual";
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +port@0 {
> +reg = <0>;
> +};
> +port@1 {
> +reg = <1>;
> +#address-cells = <1>;
> +#size-cells = <0>;
> +usb3_data_ss: endpoint {
> +remote-endpoint = <_ss_mux>;
> +};
> +};
> +};
> +};
> +};
> +};
> +...
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
[PATCH v5 1/2] ovl: propagate ovl_fs to ovl_decode_real_fh and ovl_encode_real_fh
This will be used in next patch to be able to change uuid checks and
add uuid nullification based on ofs->config.index for a new "uuid=off"
mode.
CC: Amir Goldstein
CC: Vivek Goyal
CC: Miklos Szeredi
CC: linux-unio...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Reviewed-by: Amir Goldstein
Signed-off-by: Pavel Tikhomirov
---
fs/overlayfs/copy_up.c | 22 --
fs/overlayfs/export.c| 10 ++
fs/overlayfs/namei.c | 19 ++-
fs/overlayfs/overlayfs.h | 14 --
fs/overlayfs/util.c | 3 ++-
5 files changed, 38 insertions(+), 30 deletions(-)
diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
index 955ecd4030f0..3380039036d6 100644
--- a/fs/overlayfs/copy_up.c
+++ b/fs/overlayfs/copy_up.c
@@ -275,7 +275,8 @@ int ovl_set_attr(struct dentry *upperdentry, struct kstat
*stat)
return err;
}
-struct ovl_fh *ovl_encode_real_fh(struct dentry *real, bool is_upper)
+struct ovl_fh *ovl_encode_real_fh(struct ovl_fs *ofs, struct dentry *real,
+ bool is_upper)
{
struct ovl_fh *fh;
int fh_type, dwords;
@@ -328,8 +329,8 @@ struct ovl_fh *ovl_encode_real_fh(struct dentry *real, bool
is_upper)
return ERR_PTR(err);
}
-int ovl_set_origin(struct dentry *dentry, struct dentry *lower,
- struct dentry *upper)
+int ovl_set_origin(struct ovl_fs *ofs, struct dentry *dentry,
+ struct dentry *lower, struct dentry *upper)
{
const struct ovl_fh *fh = NULL;
int err;
@@ -340,7 +341,7 @@ int ovl_set_origin(struct dentry *dentry, struct dentry
*lower,
* up and a pure upper inode.
*/
if (ovl_can_decode_fh(lower->d_sb)) {
- fh = ovl_encode_real_fh(lower, false);
+ fh = ovl_encode_real_fh(ofs, lower, false);
if (IS_ERR(fh))
return PTR_ERR(fh);
}
@@ -362,7 +363,7 @@ static int ovl_set_upper_fh(struct ovl_fs *ofs, struct
dentry *upper,
const struct ovl_fh *fh;
int err;
- fh = ovl_encode_real_fh(upper, true);
+ fh = ovl_encode_real_fh(ofs, upper, true);
if (IS_ERR(fh))
return PTR_ERR(fh);
@@ -380,6 +381,7 @@ static int ovl_set_upper_fh(struct ovl_fs *ofs, struct
dentry *upper,
static int ovl_create_index(struct dentry *dentry, struct dentry *origin,
struct dentry *upper)
{
+ struct ovl_fs *ofs = OVL_FS(dentry->d_sb);
struct dentry *indexdir = ovl_indexdir(dentry->d_sb);
struct inode *dir = d_inode(indexdir);
struct dentry *index = NULL;
@@ -402,7 +404,7 @@ static int ovl_create_index(struct dentry *dentry, struct
dentry *origin,
if (WARN_ON(ovl_test_flag(OVL_INDEX, d_inode(dentry
return -EIO;
- err = ovl_get_index_name(origin, );
+ err = ovl_get_index_name(ofs, origin, );
if (err)
return err;
@@ -411,7 +413,7 @@ static int ovl_create_index(struct dentry *dentry, struct
dentry *origin,
if (IS_ERR(temp))
goto free_name;
- err = ovl_set_upper_fh(OVL_FS(dentry->d_sb), upper, temp);
+ err = ovl_set_upper_fh(ofs, upper, temp);
if (err)
goto out;
@@ -521,7 +523,7 @@ static int ovl_copy_up_inode(struct ovl_copy_up_ctx *c,
struct dentry *temp)
* hard link.
*/
if (c->origin) {
- err = ovl_set_origin(c->dentry, c->lowerpath.dentry, temp);
+ err = ovl_set_origin(ofs, c->dentry, c->lowerpath.dentry, temp);
if (err)
return err;
}
@@ -700,7 +702,7 @@ static int ovl_copy_up_tmpfile(struct ovl_copy_up_ctx *c)
static int ovl_do_copy_up(struct ovl_copy_up_ctx *c)
{
int err;
- struct ovl_fs *ofs = c->dentry->d_sb->s_fs_info;
+ struct ovl_fs *ofs = OVL_FS(c->dentry->d_sb);
bool to_index = false;
/*
@@ -722,7 +724,7 @@ static int ovl_do_copy_up(struct ovl_copy_up_ctx *c)
if (to_index) {
c->destdir = ovl_indexdir(c->dentry->d_sb);
- err = ovl_get_index_name(c->lowerpath.dentry, >destname);
+ err = ovl_get_index_name(ofs, c->lowerpath.dentry,
>destname);
if (err)
return err;
} else if (WARN_ON(!c->parent)) {
diff --git a/fs/overlayfs/export.c b/fs/overlayfs/export.c
index ed35be3fafc6..41ebf52f1bbc 100644
--- a/fs/overlayfs/export.c
+++ b/fs/overlayfs/export.c
@@ -211,7 +211,8 @@ static int ovl_check_encode_origin(struct dentry *dentry)
return 1;
}
-static int ovl_dentry_to_fid(struct dentry *dentry, u32 *fid, int buflen)
+static int ovl_dentry_to_fid(struct ovl_fs *ofs, struct dentry *dentry,
+u32 *fid, int buflen)
{
struct ovl_fh *fh = NULL;
int err, enc_lower;
@@ -226,7 +227,7 @@ static int ovl_dentry_to_fid(struct dentry
[PATCH v5 0/2] ovl introduce "uuid=off"
This is a v5 of: ovl: introduce new "index=nouuid" option for inodes index feature Changes in v3: rebase to overlayfs-next, replace uuid with null in file handles, propagate ovl_fs to needed functions in a separate patch, add separate bool "uuid=on/off" option, fix numfs check fallback, add a note to docs. Changes in v4: get rid of double negatives, remove nouuid leftower comment, fix missprint in kernel config name. Changes in v5: fix typos; remove config option and module param. Amir, as second patch had changed quiet a bit, I don't add you reviewed-by to it. CC: Amir Goldstein CC: Vivek Goyal CC: Miklos Szeredi CC: linux-unio...@vger.kernel.org CC: linux-kernel@vger.kernel.org Signed-off-by: Pavel Tikhomirov Pavel Tikhomirov (2): ovl: propagate ovl_fs to ovl_decode_real_fh and ovl_encode_real_fh ovl: introduce new "uuid=off" option for inodes index feature Documentation/filesystems/overlayfs.rst | 5 + fs/overlayfs/copy_up.c | 25 ++--- fs/overlayfs/export.c | 10 ++ fs/overlayfs/namei.c| 23 +-- fs/overlayfs/overlayfs.h| 14 -- fs/overlayfs/ovl_entry.h| 1 + fs/overlayfs/super.c| 20 fs/overlayfs/util.c | 3 ++- 8 files changed, 69 insertions(+), 32 deletions(-) -- 2.26.2
Re: [PATCH V9 1/4] perf/core: Add PERF_SAMPLE_DATA_PAGE_SIZE
On 10/12/2020 4:48 AM, Will Deacon wrote: On Sat, Oct 10, 2020 at 12:28:39AM +1100, Michael Ellerman wrote: Peter Zijlstra writes: Patch 4 makes it all far worse by exposing it to pretty much everybody. Now, I think we can fix at least the user mappings with the below delta, but if archs are using non-page-table MMU sizes we'll need arch helpers. ARM64 is in that last boat. I think we probably need it to be weak so we can provide our own version. I guess the same thing applies to us, but I can't really tell how accurate this stuff needs to be for userspace. If it's trying to use the page-table configuration to infer properties of the TLB, that's never going to be reliable because the TLB can choose both to split and coalesce entries as long as software can't tell. Hi Peter, It looks like everybody wants a __weak function. If so, I guess we should drop the generic code in this patch. For X86, we have existing functions to retrieve the page level and the page size. I think we don't need the generic code either. https://lkml.kernel.org/r/1549648509-12704-2-git-send-email-kan.li...@linux.intel.com/ Should I send a V10 patch to drop the generic code and implement an X86 specific perf_get_page_size()? Will, Michael, and others can implement their version later separately. Thanks, Kan
Re: [PATCH] reset: meson: make it possible to build as a module
On 2020-10-13 14:39, Neil Armstrong wrote:
In order to reduce the kernel Image size on multi-platform distributions,
make it possible to build the reset controller driver as a module.
This partially reverts 8290924e ("reset: meson: make it explicitly non-modular")
Signed-off-by: Neil Armstrong
---
drivers/reset/Kconfig | 4 ++--
drivers/reset/reset-meson.c | 7 ++-
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index d9efbfd29646..ab315617565f 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -94,8 +94,8 @@ config RESET_LPC18XX
This enables the reset controller driver for NXP LPC18xx/43xx SoCs.
config RESET_MESON
- bool "Meson Reset Driver" if COMPILE_TEST
- default ARCH_MESON
+ tristate "Meson Reset Driver"
+ default ARCH_MESON || COMPILE_TEST
How about an actual dependency like:
depends on ARCH_MESON || COMPILE_TEST
default ARCH_MESON
?
That way the option won't be presented to users where it's completely
irrelevant, e.g. running "make oldconfig" with an x86 distro config. It
always bugs me when I rebase a branch and have to manually confirm that
indeed I don't want to build random drivers specific to x86/RISC-V/etc.
SoCs for my arm64 config... ;)
Robin.
help
This enables the reset driver for Amlogic Meson SoCs.
diff --git a/drivers/reset/reset-meson.c b/drivers/reset/reset-meson.c
index 94d7ba88d7d2..434d5c0f877e 100644
--- a/drivers/reset/reset-meson.c
+++ b/drivers/reset/reset-meson.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -142,4 +143,8 @@ static struct platform_driver meson_reset_driver = {
.of_match_table = meson_reset_dt_ids,
},
};
-builtin_platform_driver(meson_reset_driver);
+module_platform_driver(meson_reset_driver);
+
+MODULE_DESCRIPTION("Amlogic Meson Reset Controller driver");
+MODULE_AUTHOR("Neil Armstrong ");
+MODULE_LICENSE("Dual BSD/GPL");
Re: [PATCH] v4l: Add source change event for colorimetry
On Tue, Oct 13, 2020 at 4:53 PM Stanimir Varbanov wrote: > > > > On 10/13/20 5:07 PM, Tomasz Figa wrote: > > On Tue, Oct 13, 2020 at 3:53 PM Stanimir Varbanov > > wrote: > >> > >> > >> > >> On 10/13/20 4:40 PM, Tomasz Figa wrote: > >>> On Tue, Oct 13, 2020 at 11:03 AM Stanimir Varbanov > >>> wrote: > > Hi, > > On 7/2/20 2:52 PM, Stanimir Varbanov wrote: > > Hi, > > > > Once we have this event there is still open question how the client will > > know the data buffer on which the new colorspace is valid/applied. > > > > The options could be: > > * a new buffer flag and > > * some information in the v4l2_event structure. > > > > Thoughts? > > Kindly ping. > > >>> > >>> The event itself sounds good to me, but how do we know which buffer is > >>> the first to have the new colorimetry? > >> > >> I think Hans have a very good idea to have width/height and colorspace > >> specifiers in v4l2_ext_buffer [1]. > >> > >> [1] https://lkml.org/lkml/2020/9/9/531 > >> > > > > Hmm, I think that would basically make the event obsolete and without > > solving that problem I suspect the event is not very useful, because > > one could already receive and display (incorrectly) some buffers > > before realizing that they have different colorimetry > > Yes, I agree. I wasn't sure does Hans's idea will be well received, thus > I pinged. > > > > > I believe for now we would have to handle this like a resolution > > change - flush the CAPTURE queue and the next buffer after the flush > > would have the new colorimetry. With the new API we could optimize the > > I'm not sure what you mean by flush capture queue? Dequeue until LAST > flag (EPIPE) and stop streaming g_fmt(capture queue) and decide what is > changed and start streaming ? Yes, although no strict need to stop streaming, other ways are defined as well, e.g. DEC_CMD_START. Of course we would need to make appropriate changes to the spec and so I'd just unify it with the resolution change sequence. I think we could rename it to "Stream parameter change". > > > decoding by getting rid of the flushes and relying on the in-bound > > information. > > > > Best regards, > > Tomasz > > > >>> > >>> Best regards, > >>> Tomasz > >>> > > > > On 7/2/20 1:00 PM, Stanimir Varbanov wrote: > >> This event indicate that the source colorspace is changed > >> during run-time. The client has to retrieve the new colorspace > >> identifiers by getting the format (G_FMT). > >> > >> Signed-off-by: Stanimir Varbanov > >> --- > >> .../userspace-api/media/v4l/vidioc-dqevent.rst| 11 ++- > >> .../userspace-api/media/videodev2.h.rst.exceptions| 1 + > >> include/uapi/linux/videodev2.h| 1 + > >> 3 files changed, 12 insertions(+), 1 deletion(-) > >> > >> diff --git a/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst > >> b/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst > >> index a9a176d5256d..3f69c753db58 100644 > >> --- a/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst > >> +++ b/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst > >> @@ -381,7 +381,16 @@ call. > >> that many Video Capture devices are not able to recover from a > >> temporary > >> loss of signal and so restarting streaming I/O is required in > >> order for > >> the hardware to synchronize to the video signal. > >> - > >> +* - ``V4L2_EVENT_SRC_CH_COLORIMETRY`` > >> + - 0x0002 > >> + - This event gets triggered when a colorspace change is > >> detected at > >> +an input. By colorspace change here we include also changes in the > >> +colorspace specifiers (transfer function, Y'CbCr encoding and > >> +quantization). This event can come from an input or from video > >> decoder. > >> +Once the event has been send to the client the driver has to > >> update > >> +the colorspace specifiers internally so that they could be > >> retrieved by > >> +client. In that case queue re-negotiation is not needed as this > >> change > >> +only reflects on the interpretation of the data. > >> > >> Return Value > >> > >> diff --git > >> a/Documentation/userspace-api/media/videodev2.h.rst.exceptions > >> b/Documentation/userspace-api/media/videodev2.h.rst.exceptions > >> index ca05e4e126b2..54fc21af852d 100644 > >> --- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions > >> +++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions > >> @@ -492,6 +492,7 @@ replace define V4L2_EVENT_CTRL_CH_FLAGS > >> ctrl-changes-flags > >> replace define V4L2_EVENT_CTRL_CH_RANGE ctrl-changes-flags > >> > >> replace define V4L2_EVENT_SRC_CH_RESOLUTION src-changes-flags > >> +replace define
Re: [PATCH] arm64: KVM: marking pages as XN in Stage-2 does not care about CTR_EL0.DIC
On 2020-10-13 13:56, limingwang (A) wrote:
Hi Li,
On 2020-10-12 02:08, l00484210 wrote:
From: MingWang Li
When testing the ARMv8.2-TTS2UXN feature, setting bits of XN is
unavailable.
Because the control bit CTR_EL0.DIC is set by default on system.
But when CTR_EL0.DIC is set, software does not need to flush icache
actively, instead of clearing XN bits.The patch, the commit id of
which is 6ae4b6e0578886eb36cedbf99f04031d93f9e315, has implemented
the
function of CTR_EL0.DIC.
Signed-off-by: MingWang Li
Signed-off-by: Henglong Fan
---
arch/arm64/include/asm/pgtable-prot.h | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable-prot.h
b/arch/arm64/include/asm/pgtable-prot.h
index 4d867c6446c4..5feb94882bf7 100644
--- a/arch/arm64/include/asm/pgtable-prot.h
+++ b/arch/arm64/include/asm/pgtable-prot.h
@@ -79,17 +79,7 @@ extern bool arm64_use_ng_mappings;
__val; \
})
-#define PAGE_S2_XN \
- ({ \
- u64 __val; \
- if (cpus_have_const_cap(ARM64_HAS_CACHE_DIC)) \
- __val = 0; \
- else\
- __val = PTE_S2_XN; \
- __val; \
- })
-
-#define PAGE_S2__pgprot(_PROT_DEFAULT |
PAGE_S2_MEMATTR(NORMAL) |
PTE_S2_RDONLY | PAGE_S2_XN)
+#define PAGE_S2__pgprot(_PROT_DEFAULT |
PAGE_S2_MEMATTR(NORMAL) |
PTE_S2_RDONLY | PTE_S2_XN)
#define PAGE_S2_DEVICE __pgprot(_PROT_DEFAULT |
PAGE_S2_MEMATTR(DEVICE_nGnRE) | PTE_S2_RDONLY | PTE_S2_XN)
#define PAGE_NONE __pgprot(((_PAGE_DEFAULT) & ~PTE_VALID) |
PTE_PROT_NONE | PTE_RDONLY | PTE_NG | PTE_PXN | PTE_UXN)
I don't understand what you are trying to achieve here.
This whole point of not setting XN in the page tables when DIC is
present is to avoid a pointless permission fault at run time. At you
noticed above, no icache invalidation is necessary. So why would you
ever want to take a fault on exec the first place?
M.
--
Jazz is not dead. It just smells funny...
Hi Marc,
According to ARMv8.2-TTS2UXN feature, which extends the stage 2
translation table access
permissions to provide control of whether memory is executable at EL0
independent of whether
it is executable at EL1.
Testing this feature in some security scenario, for example, if I want
to grant execute permission
to some memory only for EL0, but it will failed. Because KVM clears XN
bits at first, this means that
the memory can be executable in both EL0 and El1.
KVM currently offers no support for this, and the only use we have for
XN so far is to to ensure Data/Instruction coherency when the CPU
doesn't offer it in HW.
So the execute permission is not granted when the page table is
created for the first time, then
grant the execute permission by setting xn, based on the actual
requirements.
And according to spec:
DIC, bit [29]
Instruction cache invalidation requirements for data to instruction
coherence.
0b0 Instruction cache invalidation to the Point of Unification is
required for data to instruction coherence.
0b1 Instruction cache invalidation to the Point of Unification is not
required for data to instruction coherence.
So when DIC is set, if the memory is changed to executable, the
hardware will flush icache.
No. The Icache *snoops* the Dcache at all times. Which is why we don't
need to trap on execution, and we can leave the guest run without
any intervention.
If as you said, I feel that DIC conflicts with ARMv8.2-TTS2UXN feature.
There is no conflict. KVM doesn't make use of all the bells and whistle
in the architecture, which is probably a good thing. If you feel that
there
is a need for S2UXN as a security feature, we can discuss how to expose
this
to the guest (because it definitely needs to know about that).
But setting XN when DIC is present for no other reason than "it may be
useful one day" doesn't make sense, and results in a massive performance
drop on the platforms that have DIC (and I really wish they all had it).
M.
--
Jazz is not dead. It just smells funny...
Re: [PATCH v2 00/14] perf arm-spe: Refactor decoding & dumping flow
Em Tue, Sep 29, 2020 at 02:39:03PM +0100, Leo Yan escreveu:
> The prominent issue for the SPE trace decoding and dumping is the packet
> header and payload values are hard coded with numbers and it's not
> readable and difficult to maintain; and has other minor issues, e.g. the
> packet length (header + payload) calculation is not correct for some
> packet types, and the dumping flow misses to support specific sub
> classes for operation packet, etc.
>
> So this patch set is to refactor the Arm SPE decoding SPE with:
> - Patches 01, 02 are minor cleans up;
> - Patches 03, 04 are used to fix and polish the packet and payload
> length calculation;
> - Patch 05 is to add a helper to wrap up printing strings, this can
> avoid bunch of duplicate code lines;
> - Patches 06 ~ 12 are used to refactor decoding for different types
> packet one by one (address packet, context packet, counter packet,
> event packet, operation packet);
> - Patch 13 is coming from Andre to dump memory tagging;
> - Patch 14 is coming from Wei Li to add decoding for ARMv8.3
> extension, in this version it has been improved to use defined
> macros, also is improved for failure handling and commit log.
>
> This patch set is cleanly applied on the top of perf/core branch
> with commit a55b7bb1c146 ("perf test: Fix msan uninitialized use."),
> and the patches have been verified on Hisilicon D06 platform and I
> manually inspected the dumping result.
>
> Changes from v1:
> - Heavily rewrote the patch 05 for refactoring printing strings; this
> is fundamental change, so adjusted the sequence for patches and moved
> the printing string patch ahead from patch 10 (v1) to patch 05;
> - Changed to use GENMASK_ULL() for bits mask;
> - Added Andre's patch 13 for dumping memory tagging;
> - Refined patch 12 for adding sub classes for Operation packet, merged
> some commit log from Andre's patch, which allows commit log and code
> to be more clear; Added "Co-developed-by: Andre Przywara" tag to
> reflect this.
Ok, so I'll wait for v3, as Leo indicated he'll respin.
Thanks,
- Arnaldo
>
> Andre Przywara (1):
> perf arm_spe: Decode memory tagging properties
>
> Leo Yan (12):
> perf arm-spe: Include bitops.h for BIT() macro
> perf arm-spe: Fix a typo in comment
> perf arm-spe: Refactor payload length calculation
> perf arm-spe: Fix packet length handling
> perf arm-spe: Refactor printing string to buffer
> perf arm-spe: Refactor packet header parsing
> perf arm-spe: Refactor address packet handling
> perf arm-spe: Refactor context packet handling
> perf arm-spe: Refactor counter packet handling
> perf arm-spe: Refactor event type handling
> perf arm-spe: Refactor operation packet handling
> perf arm-spe: Add more sub classes for operation packet
>
> Wei Li (1):
> perf arm-spe: Add support for ARMv8.3-SPE
>
> .../util/arm-spe-decoder/arm-spe-decoder.c| 54 +-
> .../util/arm-spe-decoder/arm-spe-decoder.h| 17 -
> .../arm-spe-decoder/arm-spe-pkt-decoder.c | 567 +++---
> .../arm-spe-decoder/arm-spe-pkt-decoder.h | 124 +++-
> 4 files changed, 478 insertions(+), 284 deletions(-)
>
> --
> 2.20.1
>
--
- Arnaldo
Re: [PATCH] v4l: Add source change event for colorimetry
On 10/13/20 5:07 PM, Tomasz Figa wrote:
> On Tue, Oct 13, 2020 at 3:53 PM Stanimir Varbanov
> wrote:
>>
>>
>>
>> On 10/13/20 4:40 PM, Tomasz Figa wrote:
>>> On Tue, Oct 13, 2020 at 11:03 AM Stanimir Varbanov
>>> wrote:
Hi,
On 7/2/20 2:52 PM, Stanimir Varbanov wrote:
> Hi,
>
> Once we have this event there is still open question how the client will
> know the data buffer on which the new colorspace is valid/applied.
>
> The options could be:
> * a new buffer flag and
> * some information in the v4l2_event structure.
>
> Thoughts?
Kindly ping.
>>>
>>> The event itself sounds good to me, but how do we know which buffer is
>>> the first to have the new colorimetry?
>>
>> I think Hans have a very good idea to have width/height and colorspace
>> specifiers in v4l2_ext_buffer [1].
>>
>> [1] https://lkml.org/lkml/2020/9/9/531
>>
>
> Hmm, I think that would basically make the event obsolete and without
> solving that problem I suspect the event is not very useful, because
> one could already receive and display (incorrectly) some buffers
> before realizing that they have different colorimetry
Yes, I agree. I wasn't sure does Hans's idea will be well received, thus
I pinged.
>
> I believe for now we would have to handle this like a resolution
> change - flush the CAPTURE queue and the next buffer after the flush
> would have the new colorimetry. With the new API we could optimize the
I'm not sure what you mean by flush capture queue? Dequeue until LAST
flag (EPIPE) and stop streaming g_fmt(capture queue) and decide what is
changed and start streaming ?
> decoding by getting rid of the flushes and relying on the in-bound
> information.
>
> Best regards,
> Tomasz
>
>>>
>>> Best regards,
>>> Tomasz
>>>
>
> On 7/2/20 1:00 PM, Stanimir Varbanov wrote:
>> This event indicate that the source colorspace is changed
>> during run-time. The client has to retrieve the new colorspace
>> identifiers by getting the format (G_FMT).
>>
>> Signed-off-by: Stanimir Varbanov
>> ---
>> .../userspace-api/media/v4l/vidioc-dqevent.rst| 11 ++-
>> .../userspace-api/media/videodev2.h.rst.exceptions| 1 +
>> include/uapi/linux/videodev2.h| 1 +
>> 3 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst
>> b/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst
>> index a9a176d5256d..3f69c753db58 100644
>> --- a/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst
>> +++ b/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst
>> @@ -381,7 +381,16 @@ call.
>> that many Video Capture devices are not able to recover from a
>> temporary
>> loss of signal and so restarting streaming I/O is required in order
>> for
>> the hardware to synchronize to the video signal.
>> -
>> +* - ``V4L2_EVENT_SRC_CH_COLORIMETRY``
>> + - 0x0002
>> + - This event gets triggered when a colorspace change is detected
>> at
>> +an input. By colorspace change here we include also changes in the
>> +colorspace specifiers (transfer function, Y'CbCr encoding and
>> +quantization). This event can come from an input or from video
>> decoder.
>> +Once the event has been send to the client the driver has to update
>> +the colorspace specifiers internally so that they could be
>> retrieved by
>> +client. In that case queue re-negotiation is not needed as this
>> change
>> +only reflects on the interpretation of the data.
>>
>> Return Value
>>
>> diff --git
>> a/Documentation/userspace-api/media/videodev2.h.rst.exceptions
>> b/Documentation/userspace-api/media/videodev2.h.rst.exceptions
>> index ca05e4e126b2..54fc21af852d 100644
>> --- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions
>> +++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions
>> @@ -492,6 +492,7 @@ replace define V4L2_EVENT_CTRL_CH_FLAGS
>> ctrl-changes-flags
>> replace define V4L2_EVENT_CTRL_CH_RANGE ctrl-changes-flags
>>
>> replace define V4L2_EVENT_SRC_CH_RESOLUTION src-changes-flags
>> +replace define V4L2_EVENT_SRC_CH_COLORIMETRY src-changes-flags
>>
>> replace define V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ
>> :c:type:`v4l2_event_motion_det`
>>
>> diff --git a/include/uapi/linux/videodev2.h
>> b/include/uapi/linux/videodev2.h
>> index 303805438814..b5838bc4e3a3 100644
>> --- a/include/uapi/linux/videodev2.h
>> +++ b/include/uapi/linux/videodev2.h
>> @@ -2351,6 +2351,7 @@ struct v4l2_event_frame_sync {
>> };
>>
>> #define V4L2_EVENT_SRC_CH_RESOLUTION(1 << 0)
>> +#define V4L2_EVENT_SRC_CH_COLORIMETRY
Re: [PATCH 4/5] perf: arm_spe: Decode memory tagging properties
Em Tue, Oct 13, 2020 at 11:51:03AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Sun, Sep 27, 2020 at 11:19:18AM +0800, Leo Yan escreveu:
> > On Tue, Sep 22, 2020 at 11:12:24AM +0100, Andre Przywara wrote:
> > > When SPE records a physical address, it can additionally tag the event
> > > with information from the Memory Tagging architecture extension.
> > >
> > > Decode the two additional fields in the SPE event payload.
> > >
> > > Signed-off-by: Andre Przywara
> > > ---
> > > .../util/arm-spe-decoder/arm-spe-pkt-decoder.c | 17 -
> > > 1 file changed, 12 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > > b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > > index 943e4155b246..a033f34846a6 100644
> > > --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > > @@ -8,13 +8,14 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #include "arm-spe-pkt-decoder.h"
> > >
> > > -#define BIT(n) (1ULL << (n))
> > > -
> > > #define NS_FLAG BIT(63)
> > > #define EL_FLAG (BIT(62) | BIT(61))
> > > +#define CH_FLAG BIT(62)
> > > +#define PAT_FLAG GENMASK_ULL(59, 56)
> > >
> > > #define SPE_HEADER0_PAD 0x0
> > > #define SPE_HEADER0_END 0x1
> > > @@ -447,10 +448,16 @@ int arm_spe_pkt_desc(const struct arm_spe_pkt
> > > *packet, char *buf,
> > > return snprintf(buf, buf_len, "%s 0x%llx el%d ns=%d",
> > > (idx == 1) ? "TGT" : "PC", payload, el,
> > > ns);
> > > case 2: return snprintf(buf, buf_len, "VA 0x%llx", payload);
> > > - case 3: ns = !!(packet->payload & NS_FLAG);
> > > + case 3: {
> > > + int ch = !!(packet->payload & CH_FLAG);
> > > + int pat = (packet->payload & PAT_FLAG) >> 56;
> > > +
> > > + ns = !!(packet->payload & NS_FLAG);
> > > payload &= ~(0xffULL << 56);
> > > - return snprintf(buf, buf_len, "PA 0x%llx ns=%d",
> > > - payload, ns);
> > > + return snprintf(buf, buf_len,
> > > + "PA 0x%llx ns=%d ch=%d, pat=%x",
> > > + payload, ns, ch, pat);
> > > + }
> >
> > Reviewed-by: Leo Yan
>
> Thanks, applied.
I take that back, I'm applying Leo's series that Andre reviewed instead.
- Arnaldo
Re: [PATCH 1/5] clk: qcom: Add SDM660 Multimedia Clock Controller (MMCC) driver
Yes, The unused parent map should be removed and resent.
Re: [PATCH] tracing: add tgid into common field
On Tue, Oct 13, 2020 at 9:05 PM Steven Rostedt wrote:
>
> On Tue, 13 Oct 2020 13:54:54 +0800
> Yafang Shao wrote:
>
> > --- a/include/linux/trace_events.h
> > +++ b/include/linux/trace_events.h
> > @@ -67,6 +67,7 @@ struct trace_entry {
> > unsigned char flags;
> > unsigned char preempt_count;
> > int pid;
> > + int tgid;
> > };
> >
>
> Sorry, this adds another 4 bytes to *every* event, if you want it to or
> not. I'd rather have some ways to remove fields from this header, and not
> add more to it.
>
> I can't take this patch.
>
Right, that is an overhead. I will think about some ways to avoid adding it.
--
Thanks
Yafang
[PATCH v12 5/5] drivers/tty/serial: add LiteUART driver
From: Filip Kokosinski This commit adds driver for the FPGA-based LiteUART serial controller from LiteX SoC builder. The current implementation supports LiteUART configured for 32 bit data width and 8 bit CSR bus width. It does not support IRQ. Signed-off-by: Filip Kokosinski Signed-off-by: Mateusz Holenko Reviewed-by: Greg Kroah-Hartman --- Notes: Changes in v12: - added xa_erase call in remove function - used devm_kzalloc instead of kzalloc - simplified probe implementation - switched to non-loop based LiteX CSR accessors - switched config dependency from LITEX_SOC_CONTROLLER to LITEX Changes in v11: - added Reviewed-by tag No changes in v10. No changes in v9. Changes in v8: - fixed help messages in LiteUART's KConfig - removed dependency between LiteUART and LiteX SoC drivers Changed in v7: - added missing include directive Changes in v6: - LiteUART ports now stored in xArray - removed PORT_LITEUART - fixed formatting - removed some unnecessary defines No changes in v5. Changes in v4: - fixed copyright header - removed a wrong dependency on UARTLITE from Kconfig - added a dependency on LITEX_SOC_CONTROLLER to LITEUART in Kconfig Changes in v3: - aliases made optional - used litex_get_reg/litex_set_reg functions instead of macros - SERIAL_LITEUART_NR_PORTS renamed to SERIAL_LITEUART_MAX_PORTS - PORT_LITEUART changed from 122 to 123 - added dependency on LITEX_SOC_CONTROLLER - patch number changed from 4 to 5 No changes in v2. MAINTAINERS | 1 + drivers/tty/serial/Kconfig| 32 +++ drivers/tty/serial/Makefile | 1 + drivers/tty/serial/liteuart.c | 404 ++ 4 files changed, 438 insertions(+) create mode 100644 drivers/tty/serial/liteuart.c diff --git a/MAINTAINERS b/MAINTAINERS index 8136620d4f35..c0a76996619b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10124,6 +10124,7 @@ M: Mateusz Holenko S: Maintained F: Documentation/devicetree/bindings/*/litex,*.yaml F: drivers/soc/litex/litex_soc_ctrl.c +F: drivers/tty/serial/liteuart.c F: include/linux/litex.h LIVE PATCHING diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index 9409be982aa6..8bf247e3214a 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -1580,6 +1580,38 @@ config SERIAL_MILBEAUT_USIO_CONSOLE receives all kernel messages and warnings and which allows logins in single user mode). +config SERIAL_LITEUART + tristate "LiteUART serial port support" + depends on HAS_IOMEM + depends on OF || COMPILE_TEST + depends on LITEX + select SERIAL_CORE + help + This driver is for the FPGA-based LiteUART serial controller from LiteX + SoC builder. + + Say 'Y' or 'M' here if you wish to use the LiteUART serial controller. + Otherwise, say 'N'. + +config SERIAL_LITEUART_MAX_PORTS + int "Maximum number of LiteUART ports" + depends on SERIAL_LITEUART + default "1" + help + Set this to the maximum number of serial ports you want the driver + to support. + +config SERIAL_LITEUART_CONSOLE + bool "LiteUART serial port console support" + depends on SERIAL_LITEUART=y + select SERIAL_CORE_CONSOLE + help + Say 'Y' or 'M' here if you wish to use the FPGA-based LiteUART serial + controller from LiteX SoC builder as the system console + (the system console is the device which receives all kernel messages + and warnings and which allows logins in single user mode). + Otherwise, say 'N'. + endmenu config SERIAL_MCTRL_GPIO diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile index caf167f0c10a..ed4be0ebab8d 100644 --- a/drivers/tty/serial/Makefile +++ b/drivers/tty/serial/Makefile @@ -90,6 +90,7 @@ obj-$(CONFIG_SERIAL_OWL) += owl-uart.o obj-$(CONFIG_SERIAL_RDA) += rda-uart.o obj-$(CONFIG_SERIAL_MILBEAUT_USIO) += milbeaut_usio.o obj-$(CONFIG_SERIAL_SIFIVE)+= sifive.o +obj-$(CONFIG_SERIAL_LITEUART) += liteuart.o # GPIOLIB helpers for modem control lines obj-$(CONFIG_SERIAL_MCTRL_GPIO)+= serial_mctrl_gpio.o diff --git a/drivers/tty/serial/liteuart.c b/drivers/tty/serial/liteuart.c new file mode 100644 index ..0bf6bff84fff --- /dev/null +++ b/drivers/tty/serial/liteuart.c @@ -0,0 +1,404 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * LiteUART serial controller (LiteX) Driver + * + * Copyright (C) 2019-2020 Antmicro + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* + * CSRs definitions (base address offsets + width) + * + * The definitions below are true for LiteX SoC configured for 8-bit CSR Bus, + * 32-bit aligned. + * + * Supporting other
[PATCH v12 4/5] dt-bindings: serial: document LiteUART bindings
From: Filip Kokosinski
Add documentation for LiteUART devicetree bindings.
Signed-off-by: Filip Kokosinski
Signed-off-by: Mateusz Holenko
Reviewed-by: Rob Herring
---
Notes:
Changes in v12:
- fixed the description in the yaml file
No changes in v11.
No changes in v10.
No changes in v9.
No changes in v8.
No changes in v7.
Changes in v6:
- fixed license header
No changes in v5.
No changes in v4.
Changes in v3:
- added Reviewed-by tag
- patch number changed from 3 to 4
- removed changes in MAINTAINERS file (moved to patch #2)
Changes in v2:
- binding description rewritten to a yaml schema file
- added interrupt line
- fixed unit address
- patch number changed from 2 to 3
.../bindings/serial/litex,liteuart.yaml | 38 +++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/litex,liteuart.yaml
diff --git a/Documentation/devicetree/bindings/serial/litex,liteuart.yaml
b/Documentation/devicetree/bindings/serial/litex,liteuart.yaml
new file mode 100644
index ..69acb222bb57
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/litex,liteuart.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/serial/litex,liteuart.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LiteUART serial controller
+
+maintainers:
+ - Karol Gugala
+ - Mateusz Holenko
+
+description: |
+ LiteUART serial controller is a part of the LiteX FPGA SoC builder. It
supports
+ multiple CPU architectures, currently including e.g. OpenRISC and RISC-V.
+
+properties:
+ compatible:
+const: litex,liteuart
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+uart0: serial@e0001800 {
+ compatible = "litex,liteuart";
+ reg = <0xe0001800 0x100>;
+ interrupts = <2>;
+};
--
2.25.1
[PATCH v12 3/5] drivers/soc/litex: add LiteX SoC Controller driver
From: Pawel Czarnecki
This commit adds driver for the FPGA-based LiteX SoC
Controller from LiteX SoC builder.
Co-developed-by: Mateusz Holenko
Signed-off-by: Mateusz Holenko
Signed-off-by: Pawel Czarnecki
---
Notes:
Changes in v12:
- removed unnecssary WARN on a failed validation (panic is enough)
- simplified probe implementation
- introduced litex_{read,write}{8,16,32,64}() fast accessors
- added formal documentation of litex_get_reg()/litex_set_reg()
- added LITEX config symbol
- removed unnecessary header include
- removed spin locks from CSR accessors
Changes in v11:
- removed an unnecessary comment left over from previous version
- changed a multi-line comment to comply with the formatting rules
- use WARN instad of BUG on a failed CSR validation
Changes in v10:
- added casting to avoid sparse warnings in the SoC Controller's driver
Changes in v9:
- added exporting of the `litex_set_reg`/`litex_get_reg` symbols
Changes in v8:
- removed `litex_check_accessors()` helper function
- added crashing (BUG) on the failed LiteX CSR access test
No changes in v7.
Changes in v6:
- added dependency on OF || COMPILE_TEST
- used le32_to_cpu(readl(addr)) instead of __raw_readl
and writel(cpu_to_le32(value), addr) instead of __raw_writel
to take advantage of memory barriers provided by readl/writel
Changes in v5:
- removed helper accessors and used __raw_readl/__raw_writel instead
- fixed checking for errors in litex_soc_ctrl_probe
Changes in v4:
- fixed indent in Kconfig's help section
- fixed copyright header
- changed compatible to "litex,soc-controller"
- simplified litex_soc_ctrl_probe
- removed unnecessary litex_soc_ctrl_remove
This commit has been introduced in v3 of the patchset.
It includes a simplified version of common 'litex.h'
header introduced in v2 of the patchset.
MAINTAINERS| 2 +
drivers/soc/Kconfig| 1 +
drivers/soc/Makefile | 1 +
drivers/soc/litex/Kconfig | 19
drivers/soc/litex/Makefile | 3 +
drivers/soc/litex/litex_soc_ctrl.c | 178 +
include/linux/litex.h | 103
7 files changed, 307 insertions(+)
create mode 100644 drivers/soc/litex/Kconfig
create mode 100644 drivers/soc/litex/Makefile
create mode 100644 drivers/soc/litex/litex_soc_ctrl.c
create mode 100644 include/linux/litex.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 39be98db7418..4d70a1b22a87 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9840,6 +9840,8 @@ M:Karol Gugala
M: Mateusz Holenko
S: Maintained
F: Documentation/devicetree/bindings/*/litex,*.yaml
+F: drivers/soc/litex/litex_soc_ctrl.c
+F: include/linux/litex.h
LIVE PATCHING
M: Josh Poimboeuf
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 425ab6f7e375..d097d070f579 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -9,6 +9,7 @@ source "drivers/soc/bcm/Kconfig"
source "drivers/soc/fsl/Kconfig"
source "drivers/soc/imx/Kconfig"
source "drivers/soc/ixp4xx/Kconfig"
+source "drivers/soc/litex/Kconfig"
source "drivers/soc/mediatek/Kconfig"
source "drivers/soc/qcom/Kconfig"
source "drivers/soc/renesas/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 36452bed86ef..0b16108823ef 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_ARCH_GEMINI) += gemini/
obj-y += imx/
obj-$(CONFIG_ARCH_IXP4XX) += ixp4xx/
obj-$(CONFIG_SOC_XWAY) += lantiq/
+obj-$(CONFIG_LITEX_SOC_CONTROLLER) += litex/
obj-y += mediatek/
obj-y += amlogic/
obj-y += qcom/
diff --git a/drivers/soc/litex/Kconfig b/drivers/soc/litex/Kconfig
new file mode 100644
index ..c974ec3846bc
--- /dev/null
+++ b/drivers/soc/litex/Kconfig
@@ -0,0 +1,19 @@
+# SPDX-License_Identifier: GPL-2.0
+
+menu "Enable LiteX SoC Builder specific drivers"
+
+config LITEX
+ bool
+
+config LITEX_SOC_CONTROLLER
+ tristate "Enable LiteX SoC Controller driver"
+ depends on OF || COMPILE_TEST
+ select LITEX
+ help
+ This option enables the SoC Controller Driver which verifies
+ LiteX CSR access and provides common litex_get_reg/litex_set_reg
+ accessors.
+ All drivers that use functions from litex.h must depend on
+ LITEX.
+
+endmenu
diff --git a/drivers/soc/litex/Makefile b/drivers/soc/litex/Makefile
new file mode 100644
index ..98ff7325b1c0
--- /dev/null
+++ b/drivers/soc/litex/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License_Identifier: GPL-2.0
+
+obj-$(CONFIG_LITEX_SOC_CONTROLLER) += litex_soc_ctrl.o
diff --git a/drivers/soc/litex/litex_soc_ctrl.c
b/drivers/soc/litex/litex_soc_ctrl.c
new
[PATCH v12 0/5] LiteX SoC controller and LiteUART serial driver
This patchset introduces support for LiteX SoC Controller
and LiteUART - serial device from LiteX SoC builder
(https://github.com/enjoy-digital/litex).
In the following patchset I will add
a new mor1kx-based (OpenRISC) platform that
uses this device.
Later I plan to extend this platform by
adding support for more devices from LiteX suite.
Changes in v12:
- fixed descriptions in yaml files
- simplified probe implementations
- introduced litex_{read,write}{8,16,32,64}() fast accessors
- added formal documentation of litex_get_reg()/litex_set_reg()
- fixed possible memory leaks
- removed spin locks from CSR accessors
Changes in v11:
- added Reviewed-by tag
- reformatted some comments
- switched to WARN instead of BUG on CSR validation fail
Changes in v10:
- added casting to avoid sparse warnings in the SoC Controller's driver
Changes in v9:
- fixed the `reg` node notation in the DT example
- added exporting of the `litex_set_reg`/`litex_get_reg` symbols
Changes in v8:
- fixed help messages in LiteUART's KConfig
- removed dependency between LiteUART and LiteX SoC drivers
- removed `litex_check_accessors()` helper function
- added crashing (BUG) on the failed LiteX CSR access test
Changes in v7:
- added missing include directive in UART's driver
Changes in v6:
- changed accessors in SoC Controller's driver
- reworked UART driver
Changes in v5:
- added Reviewed-by tag
- removed custom accessors from SoC Controller's driver
- fixed error checking in SoC Controller's driver
Changes in v4:
- fixed copyright headers
- fixed SoC Controller's yaml
- simplified SoC Controller's driver
Changes in v3:
- added Acked-by and Reviewed-by tags
- introduced LiteX SoC Controller driver
- removed endianness detection (handled now by LiteX SoC Controller driver)
- modified litex.h header
- DTS aliases for LiteUART made optional
- renamed SERIAL_LITEUART_NR_PORTS to SERIAL_LITEUART_MAX_PORTS
- changed PORT_LITEUART from 122 to 123
Changes in v2:
- binding description rewritten to a yaml schema file
- added litex.h header with common register access functions
Filip Kokosinski (3):
dt-bindings: vendor: add vendor prefix for LiteX
dt-bindings: serial: document LiteUART bindings
drivers/tty/serial: add LiteUART driver
Pawel Czarnecki (2):
dt-bindings: soc: document LiteX SoC Controller bindings
drivers/soc/litex: add LiteX SoC Controller driver
.../bindings/serial/litex,liteuart.yaml | 38 ++
.../soc/litex/litex,soc-controller.yaml | 39 ++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
MAINTAINERS | 9 +
drivers/soc/Kconfig | 1 +
drivers/soc/Makefile | 1 +
drivers/soc/litex/Kconfig | 19 +
drivers/soc/litex/Makefile| 3 +
drivers/soc/litex/litex_soc_ctrl.c| 176
drivers/tty/serial/Kconfig| 32 ++
drivers/tty/serial/Makefile | 1 +
drivers/tty/serial/liteuart.c | 404 ++
include/linux/litex.h | 103 +
13 files changed, 831 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/litex,liteuart.yaml
create mode 100644
Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml
create mode 100644 drivers/soc/litex/Kconfig
create mode 100644 drivers/soc/litex/Makefile
create mode 100644 drivers/soc/litex/litex_soc_ctrl.c
create mode 100644 drivers/tty/serial/liteuart.c
create mode 100644 include/linux/litex.h
--
2.25.1
[PATCH v12 2/5] dt-bindings: soc: document LiteX SoC Controller bindings
From: Pawel Czarnecki
Add documentation for LiteX SoC Controller bindings.
Signed-off-by: Pawel Czarnecki
Signed-off-by: Mateusz Holenko
Reviewed-by: Rob Herring
---
Notes:
Changes in v12:
- fixed the description and the example in the yaml file
No changes in v11.
No changes in v10.
Changes in v9:
- fixed the `reg` node notation in the DT example
No changes in v8.
No changes in v7.
Changes in v6:
- fixed license header
Changes in v5:
- added reviewed-by tag
Changes in v4:
- changes compatible to "litex,soc-controller"
- fixed yaml's header
- removed unnecessary sections from yaml
- fixed indentation in yaml
This commit has been introduced in v3 of the patchset.
.../soc/litex/litex,soc-controller.yaml | 39 +++
MAINTAINERS | 6 +++
2 files changed, 45 insertions(+)
create mode 100644
Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml
diff --git
a/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml
b/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml
new file mode 100644
index ..53121c1fbe4d
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+# Copyright 2020 Antmicro
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/soc/litex/litex,soc-controller.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: LiteX SoC Controller driver
+
+description: |
+ This is the SoC Controller driver for the LiteX SoC Builder.
+ Its purpose is to verify LiteX CSR (Control Register) access
+ operations and provide functions for other drivers to read/write CSRs
+ and to check if those accessors are ready to be used.
+
+maintainers:
+ - Karol Gugala
+ - Mateusz Holenko
+
+properties:
+ compatible:
+const: litex,soc-controller
+
+ reg:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+soc_ctrl0: soc-controller@f000 {
+compatible = "litex,soc-controller";
+reg = <0xf000 0xc>;
+status = "okay";
+};
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 7b58ca29cc80..39be98db7418 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9835,6 +9835,12 @@ L: kunit-...@googlegroups.com
S: Maintained
F: lib/list-test.c
+LITEX PLATFORM
+M: Karol Gugala
+M: Mateusz Holenko
+S: Maintained
+F: Documentation/devicetree/bindings/*/litex,*.yaml
+
LIVE PATCHING
M: Josh Poimboeuf
M: Jiri Kosina
--
2.25.1
Re: [PATCH v4 3/3] dt-bindings: touchscreen: Add binding for Novatek NT36xxx series driver
On Thu, Oct 08, 2020 at 08:15:14PM +0200, khol...@gmail.com wrote:
> From: AngeloGioacchino Del Regno
>
> Add binding for the Novatek NT36xxx series touchscreen driver.
>
> Signed-off-by: AngeloGioacchino Del Regno
> ---
> .../input/touchscreen/novatek,nt36xxx.yaml| 59 +++
> 1 file changed, 59 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/input/touchscreen/novatek,nt36xxx.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/input/touchscreen/novatek,nt36xxx.yaml
> b/Documentation/devicetree/bindings/input/touchscreen/novatek,nt36xxx.yaml
> new file mode 100644
> index ..e747cacae036
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/novatek,nt36xxx.yaml
> @@ -0,0 +1,59 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/touchscreen/novatek,nt36xxx.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Novatek NT36xxx series touchscreen controller Bindings
> +
> +maintainers:
> + - Dmitry Torokhov
This should be an owner for this device, not subsystem maintainers.
> +
> +allOf:
> + - $ref: touchscreen.yaml#
> +
> +properties:
> + compatible:
> +const: novatek,nt36xxx
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +maxItems: 1
> +
> + reset-gpio:
reset-gpios
> +maxItems: 1
> +
> + vdd-supply:
> +description: Power supply regulator for VDD pin
> +
> + vio-supply:
> +description: Power supply regulator on VDD-IO pin
> +
> +additionalProperties: false
This won't work with the ref to touchscreen.yaml. Use
'unevaluatedProperties: false' instead.
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> +
> +examples:
> + - |
> +#include
> +#include
> +
> +i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + touchscreen@62 {
> +compatible = "novatek,nt36xxx";
> +reg = <0x62>;
> +interrupt-parent = <>;
> +interrupts = <45 IRQ_TYPE_EDGE_RISING>;
> +reset-gpio = < 102 GPIO_ACTIVE_HIGH>;
> + };
> +};
> +
> +...
> --
> 2.28.0
>
[PATCH v12 1/5] dt-bindings: vendor: add vendor prefix for LiteX
From: Filip Kokosinski Add vendor prefix for LiteX SoC builder. Signed-off-by: Filip Kokosinski Signed-off-by: Mateusz Holenko Acked-by: Rob Herring --- Notes: No changes in v12. No changes in v11. No changes in v10. No changes in v9. No changes in v8. No changes in v7. No changes in v6. No changes in v5. No changes in v4. Changes in v3: - added Acked-by tag No changes in v2. Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index d3891386d671..9aae6c56d7a3 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -571,6 +571,8 @@ patternProperties: description: Linux-specific binding "^linx,.*": description: Linx Technologies + "^litex,.*": +description: LiteX SoC builder "^lltc,.*": description: Linear Technology Corporation "^logicpd,.*": -- 2.25.1
Re: [External] Re: [PATCH] mm: proc: add Sock to /proc/meminfo
On 10/13/20 1:09 AM, Mike Rapoport wrote:
> On Mon, Oct 12, 2020 at 05:53:01PM +0800, Muchun Song wrote:
>> On Mon, Oct 12, 2020 at 5:24 PM Eric Dumazet wrote:
>>>
>>> On 10/12/20 10:39 AM, Muchun Song wrote:
On Mon, Oct 12, 2020 at 3:42 PM Eric Dumazet wrote:
>
> On Mon, Oct 12, 2020 at 6:22 AM Muchun Song
> wrote:
>>
>> On Mon, Oct 12, 2020 at 2:39 AM Cong Wang
>> wrote:
>>>
>>> On Sat, Oct 10, 2020 at 3:39 AM Muchun Song
>>> wrote:
The amount of memory allocated to sockets buffer can become
significant.
However, we do not display the amount of memory consumed by sockets
buffer. In this case, knowing where the memory is consumed by the
kernel
>>>
>>> We do it via `ss -m`. Is it not sufficient? And if not, why not adding
>>> it there
>>> rather than /proc/meminfo?
>>
>> If the system has little free memory, we can know where the memory is via
>> /proc/meminfo. If a lot of memory is consumed by socket buffer, we cannot
>> know it when the Sock is not shown in the /proc/meminfo. If the unaware
>> user
>> can't think of the socket buffer, naturally they will not `ss -m`. The
>> end result
>> is that we still don’t know where the memory is consumed. And we add the
>> Sock to the /proc/meminfo just like the memcg does('sock' item in the
>> cgroup
>> v2 memory.stat). So I think that adding to /proc/meminfo is sufficient.
>>
>>>
static inline void __skb_frag_unref(skb_frag_t *frag)
{
- put_page(skb_frag_page(frag));
+ struct page *page = skb_frag_page(frag);
+
+ if (put_page_testzero(page)) {
+ dec_sock_node_page_state(page);
+ __put_page(page);
+ }
}
>>>
>>> You mix socket page frag with skb frag at least, not sure this is
>>> exactly
>>> what you want, because clearly skb page frags are frequently used
>>> by network drivers rather than sockets.
>>>
>>> Also, which one matches this dec_sock_node_page_state()? Clearly
>>> not skb_fill_page_desc() or __skb_frag_ref().
>>
>> Yeah, we call inc_sock_node_page_state() in the skb_page_frag_refill().
>> So if someone gets the page returned by skb_page_frag_refill(), it must
>> put the page via __skb_frag_unref()/skb_frag_unref(). We use PG_private
>> to indicate that we need to dec the node page state when the refcount of
>> page reaches zero.
>>
>
> Pages can be transferred from pipe to socket, socket to pipe (splice()
> and zerocopy friends...)
>
> If you want to track TCP memory allocations, you always can look at
> /proc/net/sockstat,
> without adding yet another expensive memory accounting.
The 'mem' item in the /proc/net/sockstat does not represent real
memory usage. This is just the total amount of charged memory.
For example, if a task sends a 10-byte message, it only charges one
page to memcg. But the system may allocate 8 pages. Therefore, it
does not truly reflect the memory allocated by the above memory
allocation path. We can see the difference via the following message.
cat /proc/net/sockstat
sockets: used 698
TCP: inuse 70 orphan 0 tw 617 alloc 134 mem 13
UDP: inuse 90 mem 4
UDPLITE: inuse 0
RAW: inuse 1
FRAG: inuse 0 memory 0
cat /proc/meminfo | grep Sock
Sock: 13664 kB
The /proc/net/sockstat only shows us that there are 17*4 kB TCP
memory allocations. But apply this patch, we can see that we truly
allocate 13664 kB(May be greater than this value because of per-cpu
stat cache). Of course the load of the example here is not high. In
some high load cases, I believe the difference here will be even
greater.
>>>
>>> This is great, but you have not addressed my feedback.
>>>
>>> TCP memory allocations are bounded by /proc/sys/net/ipv4/tcp_mem
>>>
>>> Fact that the memory is forward allocated or not is a detail.
>>>
>>> If you think we must pre-allocate memory, instead of forward allocations,
>>> your patch does not address this. Adding one line per consumer in
>>> /proc/meminfo looks
>>> wrong to me.
>>
>> I think that the consumer which consumes a lot of memory should be added
>> to the /proc/meminfo. This can help us know the user of large memory.
>>
>>>
>>> If you do not want 9.37 % of physical memory being possibly used by TCP,
>>> just change /proc/sys/net/ipv4/tcp_mem accordingly ?
>>
>> We are not complaining about TCP using too much memory, but how do
>> we know that TCP uses a lot of memory. When I firstly face this problem,
>> I do not know who uses the 25GB memory and it is not shown in the
>> /proc/meminfo.
>> If we can know the amount memory of the socket buffer via
[PATCH v5 4/4] mm,hwpoison: drop unneeded pcplist draining
memory_failure and soft_offline_path paths now drain pcplists by calling
get_hwpoison_page.
memory_failure flags the page as HWPoison before, so that page cannot
longer go into a pcplist, and soft_offline_page only flags a page as
HWPoison if 1) we took the page off a buddy freelist 2) the page was
in-use and we migrated it 3) was a clean pagecache.
Because of that, a page cannot longer be poisoned and be in a pcplist.
Signed-off-by: Oscar Salvador
---
mm/madvise.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/mm/madvise.c b/mm/madvise.c
index 416a56b8e757..c6b5524add58 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -877,7 +877,6 @@ static long madvise_remove(struct vm_area_struct *vma,
static int madvise_inject_error(int behavior,
unsigned long start, unsigned long end)
{
- struct zone *zone;
unsigned long size;
if (!capable(CAP_SYS_ADMIN))
@@ -922,10 +921,6 @@ static int madvise_inject_error(int behavior,
return ret;
}
- /* Ensure that all poisoned pages are removed from per-cpu lists */
- for_each_populated_zone(zone)
- drain_all_pages(zone);
-
return 0;
}
#endif
--
2.26.2
[PATCH v5 2/4] mm,hwpoison: take free pages off the buddy freelists
The crux of the matter is that historically we left poisoned pages in the
buddy system because we have some checks in place when allocating a page
that are gatekeeper for poisoned pages. Unfortunately, we do have other
users (e.g: compaction [1]) that scan buddy freelists and try to get a
page from there without checking whether the page is HWPoison.
As I stated already, I think it is fundamentally wrong to keep HWPoison
pages within the buddy systems, checks in place or not.
Let us fix this the same way we did for soft_offline [2], taking the page
off the buddy freelist so it is completely unreachable.
Note that this is fairly simple to trigger, as we only need to poison free
buddy pages (madvise MADV_HWPOISON) and then run some sort of memory stress
system.
Just for a matter of reference, I put a dump_page() in compaction_alloc()
to trigger for HWPoison patches:
kernel: page:12b2982b refcount:1 mapcount:0 mapping:
index:0x1 pfn:0x1d5db
kernel: flags: 0xfc080(hwpoison)
kernel: raw: 000fc080 ea7573c8 c9857de0
kernel: raw: 0001 0001
kernel: page dumped because: compaction_alloc
kernel: CPU: 4 PID: 123 Comm: kcompactd0 Tainted: GE
5.9.0-rc2-mm1-1-default+ #5
kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
kernel: Call Trace:
kernel: dump_stack+0x6d/0x8b
kernel: compaction_alloc+0xb2/0xc0
kernel: migrate_pages+0x2a6/0x12a0
kernel: ? isolate_freepages+0xc80/0xc80
kernel: ? __ClearPageMovable+0xb0/0xb0
kernel: compact_zone+0x5eb/0x11c0
kernel: ? finish_task_switch+0x74/0x300
kernel: ? lock_timer_base+0xa8/0x170
kernel: proactive_compact_node+0x89/0xf0
kernel: ? kcompactd+0x2d0/0x3a0
kernel: kcompactd+0x2d0/0x3a0
kernel: ? finish_wait+0x80/0x80
kernel: ? kcompactd_do_work+0x350/0x350
kernel: kthread+0x118/0x130
kernel: ? kthread_associate_blkcg+0xa0/0xa0
kernel: ret_from_fork+0x22/0x30
After that, if e.g: a process faults in the page, it will get killed
unexpectedly.
Fix it by containing the page immediatelly.
Besides that, two more changes can be noticed:
* MF_DELAYED no longer suits as we are fixing the issue by containing
the page immediately, so it does no longer rely on the allocation-time
checks to stop HWPoison to be handed over.
gain unless it is unpoisoned, so we fixed the situation.
Because of that, let us use MF_RECOVERED from now on.
* The second block that handles PageBuddy pages is no longer needed:
We call shake_page and then check whether the page is Buddy
because shake_page calls drain_all_pages, which sends pcp-pages back to
the buddy freelists, so we could have a chance to handle free pages.
Currently, get_hwpoison_page already calls drain_all_pages, and we call
get_hwpoison_page right before coming here, so we should be on the safe
side.
[1] https://lore.kernel.org/linux-mm/20190826104144.GA7849@linux/T/#u
[2] https://patchwork.kernel.org/cover/11792607/
Signed-off-by: Oscar Salvador
Acked-by: Naoya Horiguchi
---
mm/memory-failure.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index e2f12410c594..181bed890c16 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1341,6 +1341,7 @@ int memory_failure(unsigned long pfn, int flags)
struct dev_pagemap *pgmap;
int res;
unsigned long page_flags;
+ bool retry = true;
if (!sysctl_memory_failure_recovery)
panic("Memory failure on page %lx", pfn);
@@ -1358,6 +1359,7 @@ int memory_failure(unsigned long pfn, int flags)
return -ENXIO;
}
+try_again:
if (PageHuge(p))
return memory_failure_hugetlb(pfn, flags);
if (TestSetPageHWPoison(p)) {
@@ -1382,8 +1384,21 @@ int memory_failure(unsigned long pfn, int flags)
*/
if (!(flags & MF_COUNT_INCREASED) && !get_hwpoison_page(p)) {
if (is_free_buddy_page(p)) {
- action_result(pfn, MF_MSG_BUDDY, MF_DELAYED);
- return 0;
+ if (take_page_off_buddy(p)) {
+ page_ref_inc(p);
+ res = MF_RECOVERED;
+ } else {
+ /* We lost the race, try again */
+ if (retry) {
+ ClearPageHWPoison(p);
+ num_poisoned_pages_dec();
+ retry = false;
+ goto try_again;
+ }
+ res = MF_FAILED;
+ }
+ action_result(pfn, MF_MSG_BUDDY, res);
+ return res
[PATCH v5 3/4] mm,hwpoison: take free pages off the buddy freelists for hugetlb
Currently, free hugetlb get dissolved, but we also need to make sure
to take the poisoned subpage off the buddy frelists, so no one stumbles
upon it (see previous patch for more information).
Signed-off-by: Oscar Salvador
---
mm/memory-failure.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 181bed890c16..30aadeca97d2 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -809,7 +809,7 @@ static int me_swapcache_clean(struct page *p, unsigned long
pfn)
*/
static int me_huge_page(struct page *p, unsigned long pfn)
{
- int res = 0;
+ int res;
struct page *hpage = compound_head(p);
struct address_space *mapping;
@@ -820,6 +820,7 @@ static int me_huge_page(struct page *p, unsigned long pfn)
if (mapping) {
res = truncate_error_page(hpage, pfn, mapping);
} else {
+ res = MF_FAILED;
unlock_page(hpage);
/*
* migration entry prevents later access on error anonymous
@@ -828,8 +829,10 @@ static int me_huge_page(struct page *p, unsigned long pfn)
*/
if (PageAnon(hpage))
put_page(hpage);
- dissolve_free_huge_page(p);
- res = MF_RECOVERED;
+ if (!dissolve_free_huge_page(p) && take_page_off_buddy(p)) {
+ page_ref_inc(p);
+ res = MF_RECOVERED;
+ }
lock_page(hpage);
}
@@ -1198,9 +1201,13 @@ static int memory_failure_hugetlb(unsigned long pfn, int
flags)
}
}
unlock_page(head);
- dissolve_free_huge_page(p);
- action_result(pfn, MF_MSG_FREE_HUGE, MF_DELAYED);
- return 0;
+ res = MF_FAILED;
+ if (!dissolve_free_huge_page(p) && take_page_off_buddy(p)) {
+ page_ref_inc(p);
+ res = MF_RECOVERED;
+ }
+ action_result(pfn, MF_MSG_FREE_HUGE, res);
+ return res == MF_RECOVERED ? 0 : -EBUSY;
}
lock_page(head);
--
2.26.2
[PATCH v5 1/4] mm,hwpoison: drain pcplists before bailing out for non-buddy zero-refcount page
A page with 0-refcount and !PageBuddy could perfectly be a pcppage.
Currently, we bail out with an error if we encounter such a page, meaning
that we do not handle pcppages neither from hard-offline nor from
soft-offline path.
Fix this by draining pcplists whenever we find this kind of page and retry
the check again. It might be that pcplists have been spilled into the
buddy allocator and so we can handle it.
Signed-off-by: Oscar Salvador
Acked-by: Naoya Horiguchi
---
mm/memory-failure.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index c0bb186bba62..e2f12410c594 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -946,13 +946,13 @@ static int page_action(struct page_state *ps, struct page
*p,
}
/**
- * get_hwpoison_page() - Get refcount for memory error handling:
+ * __get_hwpoison_page() - Get refcount for memory error handling:
* @page: raw error page (hit by memory error)
*
* Return: return 0 if failed to grab the refcount, otherwise true (some
* non-zero value.)
*/
-static int get_hwpoison_page(struct page *page)
+static int __get_hwpoison_page(struct page *page)
{
struct page *head = compound_head(page);
@@ -982,6 +982,26 @@ static int get_hwpoison_page(struct page *page)
return 0;
}
+static int get_hwpoison_page(struct page *p)
+{
+ int ret;
+ bool drained = false;
+
+retry:
+ ret = __get_hwpoison_page(p);
+ if (!ret && !is_free_buddy_page(p) && !page_count(p) && !drained) {
+ /*
+* The page might be in a pcplist, so try to drain those
+* and see if we are lucky.
+*/
+ drain_all_pages(page_zone(p));
+ drained = true;
+ goto retry;
+ }
+
+ return ret;
+}
+
/*
* Do all that is necessary to remove user space mappings. Unmap
* the pages and send SIGBUS to the processes if the data was dirty.
--
2.26.2
[PATCH v5 0/4] HWpoison: further fixes and cleanups
This patchset includes some more fixes and a cleanup. Patch#2 and patch#3 are both fixes for taking a HWpoison page off a buddy freelist, since having them there has proved to be bad (see [1] and pathch#2's commit log). Patch#3 does the same for hugetlb pages. [1] https://lkml.org/lkml/2020/9/22/565 Thanks Oscar Salvador (4): mm,hwpoison: drain pcplists before bailing out for non-buddy zero-refcount page mm,hwpoison: take free pages off the buddy freelists mm,hwpoison: take free pages off the buddy freelists for hugetlb mm,hwpoison: drop unneeded pcplist draining mm/madvise.c| 5 mm/memory-failure.c | 70 + 2 files changed, 52 insertions(+), 23 deletions(-) -- 2.26.2
[PATCH] Fixed vfio-fsl-mc driver compilation on 32 bit
The FSL_MC_BUS on which the VFIO-FSL-MC driver is dependent on can be compiled on other architectures as well (not only ARM64) including 32 bit architectures. Include linux/io-64-nonatomic-hi-lo.h to make writeq/readq used in the driver available on 32bit platforms. Signed-off-by: Diana Craciun --- drivers/vfio/fsl-mc/vfio_fsl_mc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc.c b/drivers/vfio/fsl-mc/vfio_fsl_mc.c index d009f873578c..80fc7f4ed343 100644 --- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c +++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c @@ -13,6 +13,7 @@ #include #include #include +#include #include "vfio_fsl_mc_private.h" -- 2.17.1
Re: [PATCH v2 1/3] dt-bindings: rtc: add trickle-voltage-millivolt
On 13/10/2020 08:38:55-0500, Rob Herring wrote: > On Thu, Oct 08, 2020 at 12:05:04AM +0200, Alexandre Belloni wrote: > > Some RTCs have a trickle charge that is able to output different voltages > > depending on the type of the connected auxiliary power (battery, supercap, > > ...). Add a property allowing to specify the necessary voltage. > > > > Signed-off-by: Alexandre Belloni > > --- > > > > Changes in v2: > > - use millivolt suffix instead of mV > > Try again... Sorry, the change was wrongly squashed in patch 2/3, I've sent v3. > > > > > Documentation/devicetree/bindings/rtc/rtc.yaml | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/rtc/rtc.yaml > > b/Documentation/devicetree/bindings/rtc/rtc.yaml > > index ee237b2ed66a..93f04d5e5307 100644 > > --- a/Documentation/devicetree/bindings/rtc/rtc.yaml > > +++ b/Documentation/devicetree/bindings/rtc/rtc.yaml > > @@ -42,6 +42,13 @@ properties: > >Selected resistor for trickle charger. Should be given > >if trickle charger should be enabled. > > > > + trickle-voltage-mV: > > +$ref: /schemas/types.yaml#/definitions/uint32 > > +description: > > + Selected voltage for trickle charger. Should be given > > + if trickle charger should be enabled and the trickle voltage is > > different > > + from the RTC main power supply. > > + > >wakeup-source: > > $ref: /schemas/types.yaml#/definitions/flag > > description: > > -- > > 2.26.2 > > -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v4 3/3] dt-bindings: touchscreen: Add binding for Novatek NT36xxx series driver
On Thu, Oct 08, 2020 at 10:30:35PM +0200, AngeloGioacchino Del Regno wrote: > Il giorno gio 8 ott 2020 alle ore 20:21 Krzysztof Kozlowski > ha scritto: > > > > On Thu, 8 Oct 2020 at 20:15, wrote: > > > > > > From: AngeloGioacchino Del Regno > > > > > > Add binding for the Novatek NT36xxx series touchscreen driver. > > > > > > Signed-off-by: AngeloGioacchino Del Regno > > > --- > > > .../input/touchscreen/novatek,nt36xxx.yaml| 59 +++ > > > 1 file changed, 59 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/input/touchscreen/novatek,nt36xxx.yaml > > > > > > diff --git > > > a/Documentation/devicetree/bindings/input/touchscreen/novatek,nt36xxx.yaml > > > > > > b/Documentation/devicetree/bindings/input/touchscreen/novatek,nt36xxx.yaml > > > new file mode 100644 > > > index ..e747cacae036 > > > --- /dev/null > > > +++ > > > b/Documentation/devicetree/bindings/input/touchscreen/novatek,nt36xxx.yaml > > > @@ -0,0 +1,59 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: > > > http://devicetree.org/schemas/input/touchscreen/novatek,nt36xxx.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Novatek NT36xxx series touchscreen controller Bindings > > > + > > > +maintainers: > > > + - Dmitry Torokhov > > > + > > > +allOf: > > > + - $ref: touchscreen.yaml# > > > + > > > +properties: > > > + compatible: > > > +const: novatek,nt36xxx > > > > Thanks for the changes, they look good except this part here which I > > missed before. The compatible should not contain wildcards. If all > > devices are really compatible, just add here one const, e.g. "const: > > novatek,nt36525". If they are different, you could add multiple > > compatibles in enum. > > > > Best regards, > > Krzysztof > > They are all managed the same way, but the page addresses are > changing between all of them... the driver is reading the chip ID > while the TS MCU is in "boot mode", then checking in a ID table > if the chip is supported and finally assigning a page address table. > This is done for the entire NT36*** series. The important part is whether everything needed to read the chip ID is identical? Same power supplies and sequencing, clocks, resets, enables, etc.? If any of those vary then you'll need something more specific. You can always have a common fallback. Rob
[PATCH v3 1/3] dt-bindings: rtc: add trickle-voltage-millivolt
Some RTCs have a trickle charge that is able to output different voltages depending on the type of the connected auxiliary power (battery, supercap, ...). Add a property allowing to specify the necessary voltage. Signed-off-by: Alexandre Belloni --- changes in v3: - actually use -millivolt instead of -mV Documentation/devicetree/bindings/rtc/rtc.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/rtc/rtc.yaml b/Documentation/devicetree/bindings/rtc/rtc.yaml index ee237b2ed66a..538f3f9b29a2 100644 --- a/Documentation/devicetree/bindings/rtc/rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/rtc.yaml @@ -42,6 +42,12 @@ properties: Selected resistor for trickle charger. Should be given if trickle charger should be enabled. + trickle-voltage-millivolt: +description: + Selected voltage for trickle charger. Should be given + if trickle charger should be enabled and the trickle voltage is different + from the RTC main power supply. + wakeup-source: $ref: /schemas/types.yaml#/definitions/flag description: -- 2.26.2
[PATCH v3 3/3] rtc: rv3032: Add a driver for Microcrystal RV-3032
New driver for the Microcrystal RV-3032, including support for: - Date/time - Alarms - Low voltage detection - Trickle charge - Trimming - Clkout - RAM - EEPROM - Temperature sensor Signed-off-by: Alexandre Belloni --- changes in v3: - properly handle EEPROM configuration register update drivers/rtc/Kconfig | 10 + drivers/rtc/Makefile | 1 + drivers/rtc/rtc-rv3032.c | 925 +++ 3 files changed, 936 insertions(+) create mode 100644 drivers/rtc/rtc-rv3032.c diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig index b54d87d45c89..91faf74e188c 100644 --- a/drivers/rtc/Kconfig +++ b/drivers/rtc/Kconfig @@ -668,6 +668,16 @@ config RTC_DRV_RV3028 This driver can also be built as a module. If so, the module will be called rtc-rv3028. +config RTC_DRV_RV3032 + tristate "Micro Crystal RV3032" + select REGMAP_I2C + help + If you say yes here you get support for the Micro Crystal + RV3032. + + This driver can also be built as a module. If so, the module + will be called rtc-rv3032. + config RTC_DRV_RV8803 tristate "Micro Crystal RV8803, Epson RX8900" help diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile index 0721752c6ed4..7bb8367538db 100644 --- a/drivers/rtc/Makefile +++ b/drivers/rtc/Makefile @@ -142,6 +142,7 @@ obj-$(CONFIG_RTC_DRV_RS5C372) += rtc-rs5c372.o obj-$(CONFIG_RTC_DRV_RTD119X) += rtc-rtd119x.o obj-$(CONFIG_RTC_DRV_RV3028) += rtc-rv3028.o obj-$(CONFIG_RTC_DRV_RV3029C2) += rtc-rv3029c2.o +obj-$(CONFIG_RTC_DRV_RV3032) += rtc-rv3032.o obj-$(CONFIG_RTC_DRV_RV8803) += rtc-rv8803.o obj-$(CONFIG_RTC_DRV_RX4581) += rtc-rx4581.o obj-$(CONFIG_RTC_DRV_RX6110) += rtc-rx6110.o diff --git a/drivers/rtc/rtc-rv3032.c b/drivers/rtc/rtc-rv3032.c new file mode 100644 index ..3e67f71f4261 --- /dev/null +++ b/drivers/rtc/rtc-rv3032.c @@ -0,0 +1,925 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * RTC driver for the Micro Crystal RV3032 + * + * Copyright (C) 2020 Micro Crystal SA + * + * Alexandre Belloni + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define RV3032_SEC 0x01 +#define RV3032_MIN 0x02 +#define RV3032_HOUR0x03 +#define RV3032_WDAY0x04 +#define RV3032_DAY 0x05 +#define RV3032_MONTH 0x06 +#define RV3032_YEAR0x07 +#define RV3032_ALARM_MIN 0x08 +#define RV3032_ALARM_HOUR 0x09 +#define RV3032_ALARM_DAY 0x0A +#define RV3032_STATUS 0x0D +#define RV3032_TLSB0x0E +#define RV3032_TMSB0x0F +#define RV3032_CTRL1 0x10 +#define RV3032_CTRL2 0x11 +#define RV3032_CTRL3 0x12 +#define RV3032_TS_CTRL 0x13 +#define RV3032_CLK_IRQ 0x14 +#define RV3032_EEPROM_ADDR 0x3D +#define RV3032_EEPROM_DATA 0x3E +#define RV3032_EEPROM_CMD 0x3F +#define RV3032_RAM10x40 +#define RV3032_PMU 0xC0 +#define RV3032_OFFSET 0xC1 +#define RV3032_CLKOUT1 0xC2 +#define RV3032_CLKOUT2 0xC3 +#define RV3032_TREF0 0xC4 +#define RV3032_TREF1 0xC5 + +#define RV3032_STATUS_VLF BIT(0) +#define RV3032_STATUS_PORF BIT(1) +#define RV3032_STATUS_EVF BIT(2) +#define RV3032_STATUS_AF BIT(3) +#define RV3032_STATUS_TF BIT(4) +#define RV3032_STATUS_UF BIT(5) +#define RV3032_STATUS_TLF BIT(6) +#define RV3032_STATUS_THF BIT(7) + +#define RV3032_TLSB_CLKF BIT(1) +#define RV3032_TLSB_EEBUSY BIT(2) +#define RV3032_TLSB_TEMP GENMASK(7, 4) + +#define RV3032_CLKOUT2_HFD_MSK GENMASK(4, 0) +#define RV3032_CLKOUT2_FD_MSK GENMASK(6, 5) +#define RV3032_CLKOUT2_OS BIT(7) + +#define RV3032_CTRL1_EERD BIT(3) +#define RV3032_CTRL1_WADA BIT(5) + +#define RV3032_CTRL2_STOP BIT(0) +#define RV3032_CTRL2_EIE BIT(2) +#define RV3032_CTRL2_AIE BIT(3) +#define RV3032_CTRL2_TIE BIT(4) +#define RV3032_CTRL2_UIE BIT(5) +#define RV3032_CTRL2_CLKIE BIT(6) +#define RV3032_CTRL2_TSE BIT(7) + +#define RV3032_PMU_TCM GENMASK(1, 0) +#define RV3032_PMU_TCR GENMASK(3, 2) +#define RV3032_PMU_BSM GENMASK(5, 4) +#define RV3032_PMU_NCLKE BIT(6) + +#define RV3032_PMU_BSM_DSM 1 +#define RV3032_PMU_BSM_LSM 2 + +#define RV3032_OFFSET_MSK
[PATCH v3 2/3] dt-bindings: rtc: rv3032: add RV-3032 bindings
Document the Microcrystal RV-3032 device tree bindings
Signed-off-by: Alexandre Belloni
---
changes in v3:
- remove rtc.yaml change
.../bindings/rtc/microcrystal,rv3032.yaml | 64 +++
1 file changed, 64 insertions(+)
create mode 100644
Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml
diff --git a/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml
b/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml
new file mode 100644
index ..a2c55303810d
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/microcrystal,rv3032.yaml
@@ -0,0 +1,64 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/microcrystal,rv3032.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip RV-3032 RTC Device Tree Bindings
+
+allOf:
+ - $ref: "rtc.yaml#"
+
+maintainers:
+ - Alexandre Belloni
+
+properties:
+ compatible:
+const: microcrystal,rv3032
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ start-year: true
+
+ trickle-resistor-ohms:
+enum:
+ - 1000
+ - 2000
+ - 7000
+ - 11000
+
+ trickle-voltage-millivolt:
+enum:
+ - 1750
+ - 3000
+ - 4400
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+rtc@51 {
+compatible = "microcrystal,rv3032";
+reg = <0x51>;
+status = "okay";
+pinctrl-0 = <_nint_pins>;
+interrupts-extended = < 16 IRQ_TYPE_LEVEL_HIGH>;
+trickle-resistor-ohms = <7000>;
+trickle-voltage-millivolt = <1750>;
+};
+};
+
+...
--
2.26.2
[patch 0/4] media: Cleanup in_interrupt() usage
Folks, in the discussion about preempt count consistency accross kernel configurations: https://lore.kernel.org/r/20200914204209.256266...@linutronix.de/ it was concluded that the usage of in_interrupt() and related context checks should be removed from non-core code. The media subsystem has a few instances of in_interrupt() usage: 1) BUG_ON(in_interrupt() BUG_ON() is considered the last resort and the usage there is clearly not in that category. It could be replaced by a lockdep_assert_preemption_enabled(), but all these usage sites invoke core functionality which will catch incorrect context already. So adding more there is not really useful 2) Comments and printk()'s The comment is misleading and the checks in the printk()'s are pointless as the code can never be called from in_interrupt() as it contains GFP_KERNEL allocations. I'm collecting related cleanups all over the tree, but feel free to route them through the media tree as they have no dependencies. Let me know which route you prefer. Thanks, tglx --- common/saa7146/saa7146_fops.c |2 -- pci/bt8xx/bttv-risc.c |1 - pci/cx23885/cx23885-core.c|1 - pci/cx25821/cx25821-core.c|1 - platform/fsl-viu.c|2 -- platform/omap3isp/ispccdc.c |5 ++--- usb/au0828/au0828-video.c |5 ++--- usb/cx231xx/cx231xx-core.c| 10 -- usb/cx231xx/cx231xx-vbi.c |3 +-- usb/tm6000/tm6000-video.c |2 -- usb/zr364xx/zr364xx.c |2 -- 11 files changed, 9 insertions(+), 25 deletions(-)
Re: [PATCH v5 1/3] dt-bindings: pinctrl: Add bindings for pinctrl-microchip-sgpio driver
Linus Walleij writes:
> On Fri, Oct 9, 2020 at 12:00 PM Lars Povlsen
> wrote:
>
>> > So here reg = 0 and the out port has reg 1. Isn't that what you also put
>> > in the second cell of the GPIO phandle? Then why? The driver
>> > can very well just parse its own reg property and fill that in.
>>
>> NO! The second cell is the second dimension - NOT the direction. As I
>> wrote previously, the direction is now inherent from the handle, ie. the
>> "reg" value of the handle.
>
> OK I get it ... I think :)
Great!
>
>> The hardware describe a "port" and a "bit index" addressing, where the
>> second cell in
>>
>> gpios = <_in2 11 0 GPIO_OUT_LOW>;
>>
>> is the "bit index" - not the "reg" from the phandle.
>
> As long as the bindings specify exactly what is meant by bit index
> and the tupe (port, bit_index) is what uniquely addresses a certain
> GPIO line then it is fine I suppose.
>
Yes, that is confirmed.
>> In the example above, note
>>
>> ngpios = <96>;
>>
>> As the "port" is [0; 31], this defines "bit index" to be [0; 2], so the
>> (input) GPIO cells will be:
>>
>> p0b0, p0b1, p0b2
>> ...
>> p31b0, p31b1, p31b2
>>
>> being identical to
>>
>> <_inX 0 0 GPIO_OUT_LOW>
>> <_inX 0 1 GPIO_OUT_LOW>
>> <_inX 0 2 GPIO_OUT_LOW>
>> ...
>> <_inX 31 0 GPIO_OUT_LOW>
>> <_inX 31 1 GPIO_OUT_LOW>
>> <_inX 31 2 GPIO_OUT_LOW>
>>
>> ('X' being the SGPIO controller instance).
>
> So 32 possible ports with 3 possible bit indexes on each?
> This constraint should go into the bindings as well so it becomes
> impossible to put in illegal port numbers or bit indices.
>
> (Use the YAML min/max constraints, I suppose?)
>
Yes, I will to see if constraints in the GPIO args is possible.
>> So no, there *really* is a need for a 3-cell GPIO specifier (or whatever
>> its called).
>
> If that is the natural way to address the hardware lines
> and what is used in the documentation then it's fine, it's just so
> unorthodox that I have to push back on it a bit you know.
>
Yes, this piece of hw is certainly not a stock GPIO controller, so that
was kinda expected. But I think we ended up with an abstraction that
fits as good as possible.
I will send a new (last?) revision that includes the suggestions from
Rob tomorrow.
Thank you for your time and comments (also Rob!)
---Lars
--
Lars Povlsen,
Microchip
[patch 2/4] media: omap3isp: Remove misleading comment
in_interrupt() covers hard and soft interrupt servicing and bottom half disabled contexts, which is semantically ill defined. The comment for __ccdc_lsc_configure() "Context: in_interrupt()" is therefore as useful as "Context: unknown'. Remove it. Signed-off-by: Thomas Gleixner Cc: Mauro Carvalho Chehab Cc: Laurent Pinchart Cc: linux-me...@vger.kernel.org --- drivers/media/platform/omap3isp/ispccdc.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) --- a/drivers/media/platform/omap3isp/ispccdc.c +++ b/drivers/media/platform/omap3isp/ispccdc.c @@ -299,11 +299,10 @@ static int ccdc_lsc_busy(struct isp_ccdc ISPCCDC_LSC_BUSY; } -/* __ccdc_lsc_configure - Apply a new configuration to the LSC engine +/* + * __ccdc_lsc_configure - Apply a new configuration to the LSC engine * @ccdc: Pointer to ISP CCDC device * @req: New configuration request - * - * context: in_interrupt() */ static int __ccdc_lsc_configure(struct isp_ccdc_device *ccdc, struct ispccdc_lsc_config_req *req)
[patch 4/4] media: cx231xx: Consolidate dmesg output
The memory allocations in cx231xx_init_*() happen all in task context with
GFP_KERNEL. Therefore a dev_err() trying to deduce whether this is called
from task or interrupt context is pretty useless.
Remove these historical leftovers.
Signed-off-by: Thomas Gleixner
Cc: Mauro Carvalho Chehab
Cc: Hans Verkuil
Cc: linux-me...@vger.kernel.org
---
drivers/media/usb/cx231xx/cx231xx-core.c | 10 --
drivers/media/usb/cx231xx/cx231xx-vbi.c |3 +--
2 files changed, 5 insertions(+), 8 deletions(-)
--- a/drivers/media/usb/cx231xx/cx231xx-core.c
+++ b/drivers/media/usb/cx231xx/cx231xx-core.c
@@ -1061,9 +1061,8 @@ int cx231xx_init_isoc(struct cx231xx *de
>transfer_dma);
if (!dev->video_mode.isoc_ctl.transfer_buffer[i]) {
dev_err(dev->dev,
- "unable to allocate %i bytes for transfer
buffer %i%s\n",
- sb_size, i,
- in_interrupt() ? " while in int" : "");
+ "unable to allocate %i bytes for transfer
buffer %i\n",
+ sb_size, i);
cx231xx_uninit_isoc(dev);
return -ENOMEM;
}
@@ -1197,9 +1196,8 @@ int cx231xx_init_bulk(struct cx231xx *de
>transfer_dma);
if (!dev->video_mode.bulk_ctl.transfer_buffer[i]) {
dev_err(dev->dev,
- "unable to allocate %i bytes for transfer
buffer %i%s\n",
- sb_size, i,
- in_interrupt() ? " while in int" : "");
+ "unable to allocate %i bytes for transfer
buffer %i\n",
+ sb_size, i);
cx231xx_uninit_bulk(dev);
return -ENOMEM;
}
--- a/drivers/media/usb/cx231xx/cx231xx-vbi.c
+++ b/drivers/media/usb/cx231xx/cx231xx-vbi.c
@@ -409,8 +409,7 @@ int cx231xx_init_vbi_isoc(struct cx231xx
if (!dev->vbi_mode.bulk_ctl.transfer_buffer[i]) {
dev_err(dev->dev,
"unable to allocate %i bytes for transfer
buffer %i%s\n",
- sb_size, i,
- in_interrupt() ? " while in int" : "");
+ sb_size, i);
cx231xx_uninit_vbi_isoc(dev);
return -ENOMEM;
}
[patch 1/4] media: Bulk remove BUG_ON(in_interrupt())
None of these BUG_ON()'s is justified. BUG_ON() should only be used when
there is really no way to survive.
If at all these could be replaced by lockdep_assert_preemption_enabled() to
cover all invalid caller context and not just those covered by
in_interrupt().
But all functions which are invoked from those places contain already debug
mechanisms to catch wrong context, so having these extra checks is not
having any advantage.
Signed-off-by: Thomas Gleixner
Cc: Hans Verkuil
Cc: Laurent Pinchart
Cc: Mauro Carvalho Chehab
Cc: linux-me...@vger.kernel.org
Cc: linux-...@vger.kernel.org
diff --git a/drivers/media/common/saa7146/saa7146_fops.c
b/drivers/media/common/saa7146/saa7146_fops.c
index d6531874faa6..e936c56b0378 100644
--- a/drivers/media/common/saa7146/saa7146_fops.c
+++ b/drivers/media/common/saa7146/saa7146_fops.c
@@ -55,8 +55,6 @@ void saa7146_dma_free(struct saa7146_dev *dev,struct
videobuf_queue *q,
struct videobuf_dmabuf *dma=videobuf_to_dma(>vb);
DEB_EE("dev:%p, buf:%p\n", dev, buf);
- BUG_ON(in_interrupt());
-
videobuf_waiton(q, >vb, 0, 0);
videobuf_dma_unmap(q->dev, dma);
videobuf_dma_free(dma);
diff --git a/drivers/media/pci/bt8xx/bttv-risc.c
b/drivers/media/pci/bt8xx/bttv-risc.c
index 4af72826b006..32fa4a7fe76f 100644
--- a/drivers/media/pci/bt8xx/bttv-risc.c
+++ b/drivers/media/pci/bt8xx/bttv-risc.c
@@ -572,7 +572,6 @@ bttv_dma_free(struct videobuf_queue *q,struct bttv *btv,
struct bttv_buffer *buf
{
struct videobuf_dmabuf *dma=videobuf_to_dma(>vb);
- BUG_ON(in_interrupt());
videobuf_waiton(q, >vb, 0, 0);
videobuf_dma_unmap(q->dev, dma);
videobuf_dma_free(dma);
diff --git a/drivers/media/pci/cx23885/cx23885-core.c
b/drivers/media/pci/cx23885/cx23885-core.c
index 4b0c53f61fb7..16eb4ab0e73e 100644
--- a/drivers/media/pci/cx23885/cx23885-core.c
+++ b/drivers/media/pci/cx23885/cx23885-core.c
@@ -1322,7 +1322,6 @@ void cx23885_free_buffer(struct cx23885_dev *dev, struct
cx23885_buffer *buf)
{
struct cx23885_riscmem *risc = >risc;
- BUG_ON(in_interrupt());
pci_free_consistent(dev->pci, risc->size, risc->cpu, risc->dma);
}
diff --git a/drivers/media/pci/cx25821/cx25821-core.c
b/drivers/media/pci/cx25821/cx25821-core.c
index 55018d9e439f..6f8ffab8840f 100644
--- a/drivers/media/pci/cx25821/cx25821-core.c
+++ b/drivers/media/pci/cx25821/cx25821-core.c
@@ -1198,7 +1198,6 @@ EXPORT_SYMBOL(cx25821_risc_databuffer_audio);
void cx25821_free_buffer(struct cx25821_dev *dev, struct cx25821_buffer *buf)
{
- BUG_ON(in_interrupt());
if (WARN_ON(buf->risc.size == 0))
return;
pci_free_consistent(dev->pci,
diff --git a/drivers/media/platform/fsl-viu.c b/drivers/media/platform/fsl-viu.c
index 84633a3b8475..e0c51cd779b8 100644
--- a/drivers/media/platform/fsl-viu.c
+++ b/drivers/media/platform/fsl-viu.c
@@ -381,8 +381,6 @@ static void free_buffer(struct videobuf_queue *vq, struct
viu_buf *buf)
struct videobuf_buffer *vb = >vb;
void *vaddr = NULL;
- BUG_ON(in_interrupt());
-
videobuf_waiton(vq, >vb, 0, 0);
if (vq->int_ops && vq->int_ops->vaddr)
diff --git a/drivers/media/usb/tm6000/tm6000-video.c
b/drivers/media/usb/tm6000/tm6000-video.c
index bfba06ea60e9..9b44462c5332 100644
--- a/drivers/media/usb/tm6000/tm6000-video.c
+++ b/drivers/media/usb/tm6000/tm6000-video.c
@@ -692,8 +692,6 @@ static void free_buffer(struct videobuf_queue *vq, struct
tm6000_buffer *buf)
struct tm6000_core *dev = fh->dev;
unsigned long flags;
- BUG_ON(in_interrupt());
-
/* We used to wait for the buffer to finish here, but this didn't work
because, as we were keeping the state as VIDEOBUF_QUEUED,
videobuf_queue_cancel marked it as finished for us.
diff --git a/drivers/media/usb/zr364xx/zr364xx.c
b/drivers/media/usb/zr364xx/zr364xx.c
index 8c670934d920..83221c0b6e6d 100644
--- a/drivers/media/usb/zr364xx/zr364xx.c
+++ b/drivers/media/usb/zr364xx/zr364xx.c
@@ -357,8 +357,6 @@ static void free_buffer(struct videobuf_queue *vq, struct
zr364xx_buffer *buf)
{
_DBG("%s\n", __func__);
- BUG_ON(in_interrupt());
-
videobuf_vmalloc_free(>vb);
buf->vb.state = VIDEOBUF_NEEDS_INIT;
}
[patch 3/4] media: au0828: Consolidate dmesg output
The memory allocations in au0828_init_isoc() happen all in task context
with GFP_KERNEL. Therefore a printk() trying to deduce whether this is
called from task or interrupt context is pretty useless.
Convert it to au0828_isocdbg() as the other one in that function and for
completeness sake add one for the URB allocation as well.
Signed-off-by: Thomas Gleixner
Cc: Hans Verkuil
Cc: Mauro Carvalho Chehab
Cc: linux-me...@vger.kernel.org
---
drivers/media/usb/au0828/au0828-video.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -231,6 +231,7 @@ static int au0828_init_isoc(struct au082
for (i = 0; i < dev->isoc_ctl.num_bufs; i++) {
urb = usb_alloc_urb(max_packets, GFP_KERNEL);
if (!urb) {
+ au0828_isocdbg("cannot allocate URB\n");
au0828_uninit_isoc(dev);
return -ENOMEM;
}
@@ -239,9 +240,7 @@ static int au0828_init_isoc(struct au082
dev->isoc_ctl.transfer_buffer[i] =
usb_alloc_coherent(dev->usbdev,
sb_size, GFP_KERNEL, >transfer_dma);
if (!dev->isoc_ctl.transfer_buffer[i]) {
- printk("unable to allocate %i bytes for transfer buffer
%i%s\n",
- sb_size, i,
- in_interrupt() ? " while in int" : "");
+ au0828_isocdbg("cannot allocate transfer buffer\n");
au0828_uninit_isoc(dev);
return -ENOMEM;
}
Re: [PATCH] perf/x86/intel/uncore: Fix for iio mapping on Skylake Server
Hello Kyle,
Currently we do not have plans on supporting the Uncore units to IIO PMON
mapping on multiple segment platforms due to a variety of such platforms.
It would be great if you describe your case, I mean how you configure
segments
on your platform. It will help to cover your configuration and determine a
common approach for the mapping algorithm.
Thanks,
Alexander
On 10/09/2020 05:11 PM, Meyer, Kyle wrote:
Hello Alexander,
Do you plan on supporting multiple segment platforms?
Thanks,
Kyle Meyer
From: alexander.anto...@linux.intel.com
Sent: Monday, September 28, 2020 5:21 AM
To: pet...@infradead.org; linux-kernel@vger.kernel.org; x...@kernel.org
Cc: alexander.shish...@linux.intel.com; kan.li...@linux.intel.com;
alexey.budan...@linux.intel.com; a...@linux.intel.com; a...@kernel.org;
mi...@redhat.com; alexander.anto...@linux.intel.com; Meyer, Kyle; Anderson, Russ
Subject: [PATCH] perf/x86/intel/uncore: Fix for iio mapping on Skylake Server
From: Alexander Antonov
Introduced early attributes /sys/devices/uncore_iio_/die* are
initialized by skx_iio_set_mapping(), however, for example, for multiple
segment platforms skx_iio_get_topology() returns -EPERM before a list of
attributes in skx_iio_mapping_group will have been initialized.
As a result the list is being NULL. Thus the warning
"sysfs: (bin_)attrs not set by subsystem for group: uncore_iio_*/" appears
and uncore_iio pmus are not available in sysfs. Clear IIO attr_update
to properly handle the cases when topology information cannot be
retrieved.
Fixes: bb42b3d39781 ("perf/x86/intel/uncore: Expose an Uncore unit to IIO PMON
mapping")
Reported-by: Kyle Meyer
Suggested-by: Kan Liang
Reviewed-by: Alexei Budankov
Reviewed-by: Kan Liang
Signed-off-by: Alexander Antonov
---
arch/x86/events/intel/uncore_snbep.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/x86/events/intel/uncore_snbep.c
b/arch/x86/events/intel/uncore_snbep.c
index 62e88ad919ff..ccfa1d6b6aa0 100644
--- a/arch/x86/events/intel/uncore_snbep.c
+++ b/arch/x86/events/intel/uncore_snbep.c
@@ -3749,7 +3749,9 @@ static int skx_iio_set_mapping(struct intel_uncore_type
*type)
ret = skx_iio_get_topology(type);
if (ret)
- return ret;
+ goto clear_attr_update;
+
+ ret = -ENOMEM;
/* One more for NULL. */
attrs = kcalloc((uncore_max_dies() + 1), sizeof(*attrs), GFP_KERNEL);
@@ -3781,8 +3783,9 @@ static int skx_iio_set_mapping(struct intel_uncore_type
*type)
kfree(eas);
kfree(attrs);
kfree(type->topology);
+clear_attr_update:
type->attr_update = NULL;
- return -ENOMEM;
+ return ret;
}
static void skx_iio_cleanup_mapping(struct intel_uncore_type *type)
base-commit: a1b8638ba1320e6684aa98233c15255eb803fac7
--
2.19.1
Re: [PATCH v4] kcov, usb: specify contexts for remote coverage sections
On Tue, Oct 13, 2020 at 4:15 PM Dmitry Vyukov wrote: > > On Tue, Oct 13, 2020 at 3:58 PM Andrey Konovalov > wrote: > > > > Currently there's a KCOV remote coverage collection section in > > > > __usb_hcd_giveback_urb(). Initially that section was added based on the > > > > assumption that usb_hcd_giveback_urb() can only be called in interrupt > > > > context as indicated by a comment before it. This is what happens when > > > > syzkaller is fuzzing the USB stack via the dummy_hcd driver. > > > > > > > > As it turns out, it's actually valid to call usb_hcd_giveback_urb() in > > > > task > > > > context, provided that the caller turned off the interrupts; USB/IP does > > > > exactly that. This can lead to a nested KCOV remote coverage collection > > > > sections both trying to collect coverage in task context. This isn't > > > > supported by KCOV, and leads to a WARNING. > > > > > > How does this recursion happen? There is literal recursion in the task > > > context? A function starts a remote coverage section and calls another > > > function that also starts a remote coverage section? > > > > Yes, a literal recursion. Background thread for processing requests > > for USB/IP hub (which we collect coverage from) calls > > __usb_hcd_giveback_urb(). > > > > Here's the stack trace: > > > > kcov_remote_start_usb include/linux/kcov.h:52 [inline] > > __usb_hcd_giveback_urb+0x284/0x4b0 drivers/usb/core/hcd.c:1649 > > usb_hcd_giveback_urb+0x367/0x410 drivers/usb/core/hcd.c:1716 > > vhci_urb_enqueue.cold+0x37f/0x4c5 drivers/usb/usbip/vhci_hcd.c:801 > > usb_hcd_submit_urb+0x2b1/0x20d0 drivers/usb/core/hcd.c:1547 > > usb_submit_urb+0x6e5/0x13b0 drivers/usb/core/urb.c:570 > > usb_start_wait_urb+0x10f/0x2c0 drivers/usb/core/message.c:58 > > usb_internal_control_msg drivers/usb/core/message.c:102 [inline] > > usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153 > > hub_set_address drivers/usb/core/hub.c:4472 [inline] > > hub_port_init+0x23f6/0x2d20 drivers/usb/core/hub.c:4748 > > hub_port_connect drivers/usb/core/hub.c:5140 [inline] > > hub_port_connect_change drivers/usb/core/hub.c:5348 [inline] > > port_event drivers/usb/core/hub.c:5494 [inline] > > hub_event+0x1cc9/0x38d0 drivers/usb/core/hub.c:5576 > > process_one_work+0x7b6/0x1190 kernel/workqueue.c:2269 > > worker_thread+0x94/0xdc0 kernel/workqueue.c:2415 > > kthread+0x372/0x450 kernel/kthread.c:292 > > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 > > > > > Or is there recursion between task context and softirq context? > > > > No. This kind of recursion is actually supported by kcov right now. A > > softirq with a coverage collection section can come in the middle of a > > coverage collection section for a task. > > > > > But > > > this should not happen if softirq's disabled around > > > usb_hcd_giveback_urb call in task context... > > > > [...] > > > > > We do want to collect coverage from usb_hcd_giveback_urb in the task > > > context eventually, right? > > > > Ideally, eventually, yes. > > > > > Is this API supposed to be final? Or it only puts down fire re the > > > warning? > > > > Only puts down the fire. > > > > > I don't understand how this API can be used in other contexts. > > > Let's say there is recursion in task context and we want to collect > > > coverage in task context (the function is only called in task > > > context). This API won't help. > > > > No, it won't. Full recursion support is required for this. > > > > > Let's say a function is called from both task and softirq context and > > > these can recurse (softirq arrive while in remote task section). This > > > API won't help. It will force to choose either task or softirq, but > > > let's say you can't make that choice because they are equally > > > important. > > > > This currently works, everything that happens in a softirq gets > > associated with softirq, everything else - with the task. This seems > > to be the only logical approach here, it makes no sense to associate > > what happens in a softirq with the task where the softirq happened. > > > > > The API helps to work around the unimplemented recursion in KCOV, but > > > it's also specific to this particular case. It's not necessary that > > > recursion is specific to one context only and it's not necessary that > > > a user can choose to sacrifice one of the contexts. > > > Also, if we support recursion in one way or another, we will never > > > want to use this API, right? > > > > Correct. > > > I see. > The following is simpler option that does what this patch achieves but > in a more direct way: > > // Because ... > if (in_serving_softirq()) > kcov_remote_start_usb((u64)urb->dev->bus->busnum); Hmm, this actually makes a lot of sense. I wonder why I haven't thought of that :) Will do in v4.
Re: [PATCHv4] perf kvm: add kvm-stat for arm64
Em Tue, Sep 29, 2020 at 12:34:50PM +0900, Sergey Senozhatsky escreveu: > On (20/09/17 19:02), Sergey Senozhatsky wrote: > > Add support for perf kvm stat on arm64 platform. > > Example: > > # perf kvm stat report > > Analyze events for all VMs, all VCPUs: > > VM-EXITSamples Samples% Time%Min TimeMax Time > > Avg time > > > >DABT_LOW 66186798.91%40.45% 2.19us 3364.65us > > 6.24us ( +- 0.34% ) > > IRQ 4598 0.69%57.44% 2.89us 3397.59us > > 1276.27us ( +- 1.61% ) > > WFx 1475 0.22% 1.71% 2.22us 3388.63us > > 118.31us ( +- 8.69% ) > >IABT_LOW 1018 0.15% 0.38% 2.22us 2742.07us > > 38.29us ( +- 12.55% ) > > SYS64180 0.03% 0.01% 2.07us112.91us > > 6.57us ( +- 14.95% ) > > HVC64 17 0.00% 0.01% 2.19us322.35us > > 42.95us ( +- 58.98% ) > > Total Samples:669155, Total events handled time:10216387.86us. > > Signed-off-by: Sergey Senozhatsky > > Reviewed-by: Leo Yan > > Tested-by: Leo Yan > Arnaldo, any opinion on this? I'm not finding the actual patch, just this reply from you, lets try with b4 using this message Message-Id... Magic! But it isn't applying, can you please refresh the patch to what is in my perf/core branch? - Arnaldo [acme@five perf]$ b4 am -csl 20200929033450.GB529@jagdpanzerIV.localdomain Looking up https://lore.kernel.org/r/20200929033450.GB529%40jagdpanzerIV.localdomain Grabbing thread from lore.kernel.org/linux-arm-kernel Analyzing 2 messages in the thread --- Writing ./20200917_sergey_senozhatsky__1_2_3.mbx [PATCHv4] perf kvm: add kvm-stat for arm64 + Signed-off-by: Arnaldo Carvalho de Melo + Link: https://lore.kernel.org/r/20200917100225.208794-1-sergey.senozhat...@gmail.com --- Total patches: 1 --- Link: https://lore.kernel.org/r/20200917100225.208794-1-sergey.senozhat...@gmail.com Base: not found git am ./20200917_sergey_senozhatsky__1_2_3.mbx [acme@five perf]$ vim ./20200917_sergey_senozhatsky__1_2_3.mbx [acme@five perf]$ [acme@five perf]$git am ./20200917_sergey_senozhatsky__1_2_3.mbx Applying: perf kvm: add kvm-stat for arm64 error: patch failed: tools/perf/arch/arm64/util/Build:1 error: tools/perf/arch/arm64/util/Build: patch does not apply Patch failed at 0001 perf kvm: add kvm-stat for arm64 hint: Use 'git am --show-current-patch=diff' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". [acme@five perf]$
Re: [Regression] "tpm: Require that all digests are present in TCG_PCR_EVENT2 structures" causes null pointer dereference
On Tue, Oct 13, 2020 at 09:31:39AM -0500, Tyler Hicks wrote: > Sorry for coming in so late, I've been on an extended vacation with > little connectivity. > > On 2020-10-09 19:06:54, Jarkko Sakkinen wrote: > > On Thu, Oct 08, 2020 at 05:09:06PM +0800, Kai-Heng Feng wrote: > > > > I do not have yet any reasonable answer to this and my v5.10 PR is > > > > running late. Does everyone agree that I should revert the patch? > > > > > > Given that there are multiple users confirmed reverting the commit > > > helps, can you please revert it and Cc: linux-stable? > > > > I already sent the PR, but I schedule the revert to my rc2 PR. > > I'll try to better understand what's going on. I, too, am confused about > how the change would introduce the reported regression. I've only > skimmed the thread so far but it feels like there's possibly a latent > issue that the change may be uncovering on certain systems. > > FWIW, we've had this patch applied to our internal kernel for a month > and haven't seen any issues. > > Tyler Tyler, it will be a while before even rc1 is out, i.e. there's window for investigation. /Jarkko
Re: [PATCH] kbuild: doc: describe proper script invocation
On Thu, Oct 1, 2020 at 4:57 PM Lukas Bulwahn wrote: > > During an investigation to fix up the execute bits of scripts in the kernel > repository, Andrew Morton and Kees Cook pointed out that the execute bit > should not matter, and that build scripts cannot rely on that. Kees could > not point to any documentation, though. > > Masahiro Yamada explained the convention of setting execute bits to make it > easier for manual script invocation. > > Provide some basic documentation how the build shall invoke scripts, such > that the execute bits do not matter, and acknowledge that execute bits > are useful nonetheless. > > This serves as reference for further clean-up patches in the future. > > Link: > https://lore.kernel.org/lkml/20200830174409.c24c3f67addcce0cea9a9...@linux-foundation.org/ > Link: https://lore.kernel.org/lkml/202008271102.FEB906C88@keescook/ > Link: > https://lore.kernel.org/linux-kbuild/CAK7LNAQdrvMkDA6ApDJCGr+5db8SiPo=g+p8eiovnngven8...@mail.gmail.com/ > > Suggested-by: Andrew Morton > Suggested-by: Kees Cook > Signed-off-by: Lukas Bulwahn Applied to linux-kbuild. Thanks. > --- > RFC v1 -> RFC v2: > explain why execute bits are still convenient. > > Kees, Andrew, please ack. > > Masahiro-san, I have taken your feedback into account. Please pick this small > documentation update into your kbuild tree. > > Ujjwal Kumar, a potential future mentee, will follow up with further fixes to > the build scripts. > > Documentation/kbuild/makefiles.rst | 20 > 1 file changed, 20 insertions(+) > > diff --git a/Documentation/kbuild/makefiles.rst > b/Documentation/kbuild/makefiles.rst > index 58d513a0fa95..bd3e1baf58be 100644 > --- a/Documentation/kbuild/makefiles.rst > +++ b/Documentation/kbuild/makefiles.rst > @@ -21,6 +21,7 @@ This document describes the Linux kernel Makefiles. >--- 3.10 Special Rules >--- 3.11 $(CC) support functions >--- 3.12 $(LD) support functions > + --- 3.13 Script Invocation > > === 4 Host Program support >--- 4.1 Simple Host Program > @@ -605,6 +606,25 @@ more details, with real examples. > #Makefile > LDFLAGS_vmlinux += $(call ld-option, -X) > > +3.13 Script invocation > +-- > + > + Make rules may invoke scripts to build the kernel. The rules shall > + always provide the appropriate interpreter to execute the script. They > + shall not rely on the execute bits being set, and shall not invoke the > + script directly. For the convenience of manual script invocation, such > + as invoking ./scripts/checkpatch.pl, it is recommended to set execute > + bits on the scripts nonetheless. > + > + Kbuild provides variables $(CONFIG_SHELL), $(AWK), $(PERL), > + $(PYTHON) and $(PYTHON3) to refer to interpreters for the respective > + scripts. > + > + Example:: > + > + #Makefile > + cmd_depmod = $(CONFIG_SHELL) $(srctree)/scripts/depmod.sh > $(DEPMOD) \ > +$(KERNELRELEASE) > > 4 Host Program support > == > -- > 2.17.1 > -- Best Regards Masahiro Yamada
[PATCH] sched/deadline: Replace rq_of_dl_rq(dl_rq_of_se(dl_se)) with ... ...task_rq(dl_task_of(dl_se))
The rq is already obtained in the dl_rq_of_se() function:
struct task_struct *p = dl_task_of(dl_se);
struct rq *rq = task_rq(p);
So there is no need to do extra conversion.
Signed-off-by: Qi Zheng
---
kernel/sched/deadline.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 6d93f4518734..f64e577f6aba 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -1152,7 +1152,7 @@ void init_dl_task_timer(struct sched_dl_entity *dl_se)
static inline void dl_check_constrained_dl(struct sched_dl_entity *dl_se)
{
struct task_struct *p = dl_task_of(dl_se);
- struct rq *rq = rq_of_dl_rq(dl_rq_of_se(dl_se));
+ struct rq *rq = task_rq(p);
if (dl_time_before(dl_se->deadline, rq_clock(rq)) &&
dl_time_before(rq_clock(rq), dl_next_period(dl_se))) {
@@ -1498,7 +1498,7 @@ enqueue_dl_entity(struct sched_dl_entity *dl_se,
replenish_dl_entity(dl_se, pi_se);
} else if ((flags & ENQUEUE_RESTORE) &&
dl_time_before(dl_se->deadline,
-rq_clock(rq_of_dl_rq(dl_rq_of_se(dl_se) {
+rq_clock(task_rq(dl_task_of(dl_se) {
setup_new_dl_entity(dl_se);
}
--
2.25.1
Re: [Regression] "tpm: Require that all digests are present in TCG_PCR_EVENT2 structures" causes null pointer dereference
Sorry for coming in so late, I've been on an extended vacation with little connectivity. On 2020-10-09 19:06:54, Jarkko Sakkinen wrote: > On Thu, Oct 08, 2020 at 05:09:06PM +0800, Kai-Heng Feng wrote: > > > I do not have yet any reasonable answer to this and my v5.10 PR is > > > running late. Does everyone agree that I should revert the patch? > > > > Given that there are multiple users confirmed reverting the commit > > helps, can you please revert it and Cc: linux-stable? > > I already sent the PR, but I schedule the revert to my rc2 PR. I'll try to better understand what's going on. I, too, am confused about how the change would introduce the reported regression. I've only skimmed the thread so far but it feels like there's possibly a latent issue that the change may be uncovering on certain systems. FWIW, we've had this patch applied to our internal kernel for a month and haven't seen any issues. Tyler > > > Thanks! > > > > Kai-Heng > > /Jarkko >
[PATCH v2] dt-bindings: clock: adi,axi-clkgen: convert old binding to yaml format
This change converts the old binding for the AXI clkgen driver to a yaml
format.
As maintainers, added:
- Lars-Peter Clausen - as original author of driver &
binding
- Michael Hennerich - as supporter of
Analog Devices drivers
Acked-by: Michael Hennerich
Acked-by: Lars-Peter Clausen
Signed-off-by: Alexandru Ardelean
---
Changelog v1 -> v2:
* add 'additionalProperties: false'
* changed 'clock@...' -> 'clock-controller@...' in example
* added Acked-by for Michael & Lars on the re-licensing
* updated description for 'clocks' property
.../bindings/clock/adi,axi-clkgen.yaml| 53 +++
.../devicetree/bindings/clock/axi-clkgen.txt | 25 -
2 files changed, 53 insertions(+), 25 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/adi,axi-clkgen.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/axi-clkgen.txt
diff --git a/Documentation/devicetree/bindings/clock/adi,axi-clkgen.yaml
b/Documentation/devicetree/bindings/clock/adi,axi-clkgen.yaml
new file mode 100644
index ..0d06387184d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/adi,axi-clkgen.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/adi,axi-clkgen.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Binding for Analog Devices AXI clkgen pcore clock generator
+
+maintainers:
+ - Lars-Peter Clausen
+ - Michael Hennerich
+
+description: |
+ The axi_clkgen IP core is a software programmable clock generator,
+ that can be synthesized on various FPGA platforms.
+
+ Link: https://wiki.analog.com/resources/fpga/docs/axi_clkgen
+
+properties:
+ compatible:
+enum:
+ - adi,axi-clkgen-2.00.a
+
+ clocks:
+description:
+ Specifies the reference clock(s) from which the output frequency is
+ derived. This must either reference one clock if only the first clock
+ input is connected or two if both clock inputs are connected.
+minItems: 1
+maxItems: 2
+
+ '#clock-cells':
+const: 0
+
+ reg:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+clock-controller@ff00 {
+ compatible = "adi,axi-clkgen-2.00.a";
+ #clock-cells = <0>;
+ reg = <0xff00 0x1000>;
+ clocks = < 1>;
+};
diff --git a/Documentation/devicetree/bindings/clock/axi-clkgen.txt
b/Documentation/devicetree/bindings/clock/axi-clkgen.txt
deleted file mode 100644
index aca94fe9416f..
--- a/Documentation/devicetree/bindings/clock/axi-clkgen.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-Binding for the axi-clkgen clock generator
-
-This binding uses the common clock binding[1].
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Required properties:
-- compatible : shall be "adi,axi-clkgen-1.00.a" or "adi,axi-clkgen-2.00.a".
-- #clock-cells : from common clock binding; Should always be set to 0.
-- reg : Address and length of the axi-clkgen register set.
-- clocks : Phandle and clock specifier for the parent clock(s). This must
- either reference one clock if only the first clock input is connected
or two
- if both clock inputs are connected. For the later case the clock
connected
- to the first input must be specified first.
-
-Optional properties:
-- clock-output-names : From common clock binding.
-
-Example:
- clock@ff00 {
- compatible = "adi,axi-clkgen";
- #clock-cells = <0>;
- reg = <0xff00 0x1000>;
- clocks = < 1>;
- };
--
2.17.1
Re: [PATCH 07/18] dt-bindings: usb: Convert xHCI bindings to DT schema
On Tue, Oct 13, 2020 at 07:30:04AM -0500, Rob Herring wrote:
> On Sun, Oct 11, 2020 at 01:41:10AM +0300, Serge Semin wrote:
> > Currently the DT bindings of Generic xHCI Controllers are described by means
> > of the legacy text file. Since such format is deprecated in favor of the
> > DT schema, let's convert the Generic xHCI Controllers bindings file to the
> > corresponding yaml files. There will be two of them: a DT schema for the
> > xHCI controllers on a generic platform and a DT schema validating a generic
> > xHCI controllers properties. The later will be used to validate the xHCI
> > controllers, which aside from some vendor-specific features support the
> > basic xHCI functionality.
> >
> > An xHCI-compatible DT node shall support the standard USB HCD properties
> > and custom ones like: usb2-lpm-disable, usb3-lpm-capable,
> > quirk-broken-port-ped and imod-interval-ns. In addition if a generic xHCI
> > controller is being validated against the DT schema it is also supposed to
> > be equipped with mandatory compatible string, single registers range,
> > single interrupts source, and is supposed to optionally contain up to two
> > reference clocks for the controller core and CSRs.
> >
> > Signed-off-by: Serge Semin
> > ---
> > .../devicetree/bindings/usb/generic-xhci.yaml | 63 +++
> > .../devicetree/bindings/usb/usb-xhci.txt | 41
> > .../devicetree/bindings/usb/usb-xhci.yaml | 40
> > 3 files changed, 103 insertions(+), 41 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/usb/generic-xhci.yaml
> > delete mode 100644 Documentation/devicetree/bindings/usb/usb-xhci.txt
> > create mode 100644 Documentation/devicetree/bindings/usb/usb-xhci.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/usb/generic-xhci.yaml
> > b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
> > new file mode 100644
> > index ..1ea1d49a8175
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/generic-xhci.yaml
> > @@ -0,0 +1,63 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/usb/generic-xhci.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: USB xHCI Controller Device Tree Bindings
> > +
> > +maintainers:
> > + - Mathias Nyman
> > +
> > +allOf:
> > + - $ref: "usb-xhci.yaml#"
> > +
> > +properties:
> > + compatible:
> > +oneOf:
> > + - description: Generic xHCI device
> > +const: generic-xhci
> > + - description: Armada 37xx/375/38x/8k SoCs
> > +items:
> > + - enum:
> > + - marvell,armada3700-xhci
> > + - marvell,armada-375-xhci
> > + - marvell,armada-380-xhci
> > + - marvell,armada-8k-xhci
> > + - const: generic-xhci
> > + - description: Broadcom STB SoCs with xHCI
> > +const: brcm,bcm7445-xhci
> > + - description: Generic xHCI device
> > +const: xhci-platform
> > +deprecated: true
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + interrupts:
> > +maxItems: 1
> > +
> > + clocks:
> > +minItems: 1
> > +maxItems: 2
> > +
> > + clock-names:
> > +minItems: 1
> > +items:
> > + - const: core
> > + - const: reg
> > +
> > +unevaluatedProperties: false
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > +
> > +examples:
> > + - |
> > +usb@f0931000 {
> > + compatible = "generic-xhci";
> > + reg = <0xf0931000 0x8c8>;
> > + interrupts = <0x0 0x4e 0x0>;
> > +};
> > diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt
> > b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> > deleted file mode 100644
> > index 0c5cff84a969..
> > --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
> > +++ /dev/null
> > @@ -1,41 +0,0 @@
> > -USB xHCI controllers
> > -
> > -Required properties:
> > - - compatible: should be one or more of
> > -
> > -- "generic-xhci" for generic XHCI device
> > -- "marvell,armada3700-xhci" for Armada 37xx SoCs
> > -- "marvell,armada-375-xhci" for Armada 375 SoCs
> > -- "marvell,armada-380-xhci" for Armada 38x SoCs
> > -- "brcm,bcm7445-xhci" for Broadcom STB SoCs with XHCI
> > -- "xhci-platform" (deprecated)
> > -
> > -When compatible with the generic version, nodes must list the
> > -SoC-specific version corresponding to the platform first
> > -followed by the generic version.
> > -
> > - - reg: should contain address and length of the standard XHCI
> > -register set for the device.
> > - - interrupts: one XHCI interrupt should be described here.
> > -
> > -Optional properties:
> > - - clocks: reference to the clocks
> > - - clock-names: mandatory if there is a second clock, in this case
> > -the name must be "core" for the first clock and "reg" for the
> > -second one
> > - - usb2-lpm-disable: indicate if we don't
Re: [GIT PULL] x86/platform updates for v5.10
On 10/13/2020 6:37 AM, Mike Travis wrote: On 10/13/2020 6:29 AM, Borislav Petkov wrote: On Tue, Oct 13, 2020 at 05:33:37AM -0700, Mike Travis wrote: I'm working on the correct code now, and I have UV4 & UV4A machine time starting at 7am (PDT) to test it. The UV5 simulator does not yet emulate console initiated NMI from the BMC. Ok, let me put it another way: is this simple fix good enough for now so that it doesn't trigger the build error on Linus' tree or not? You can take your time and do all kinds of fixing later but we need a minimal fix *now*! Pretty please? Yes, it does fix the compile error. Turns out I was combining 3 different sources to determine if the NMI INT occurred and I used the 1ULL << SHIFT to check each one. So the MASK is indeed extraneous and can be removed. Tested and patch follows.
Re: [PATCH v3 1/2] dt-bindings: usb: dwc3-xilinx: Add documentation for Versal DWC3 Controller
On Thu, 08 Oct 2020 18:36:55 +0530, Manish Narani wrote: > Add documentation for Versal DWC3 controller. Add required property > 'reg' for the same. Also add optional properties for snps,dwc3. > > Signed-off-by: Manish Narani > --- > .../devicetree/bindings/usb/dwc3-xilinx.txt | 17 +++-- > 1 file changed, 15 insertions(+), 2 deletions(-) > Reviewed-by: Rob Herring
Re: [PATCH v4 1/3] dt-bindings: Add vendor prefix for Novatek Microelectronics Corp.
On Thu, 08 Oct 2020 20:15:12 +0200, khol...@gmail.com wrote: > From: AngeloGioacchino Del Regno > > Add prefix for Novatek Microelectronics Corp. > > Signed-off-by: AngeloGioacchino Del Regno > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring
Re: [PATCH 1/2] sched: Deny self-issued __set_cpus_allowed_ptr() when migrate_disable()
On 13/10/20 15:15, Sebastian Andrzej Siewior wrote:
> On 2020-10-13 15:01:15 [+0100], Valentin Schneider wrote:
>> migrate_disable();
>> set_cpus_allowed_ptr(current, {something excluding task_cpu(current)});
>> affine_move_task(); <-- never returns
>>
>> Signed-off-by: Valentin Schneider
>> ---
>> kernel/sched/core.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 4ccd1099adaa..7f4e38819de1 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -2189,6 +2189,11 @@ static int __set_cpus_allowed_ptr(struct task_struct
>> *p,
>> if (!(flags & SCA_MIGRATE_ENABLE) && cpumask_equal(>cpus_mask,
>> new_mask))
>> goto out;
>>
>> +if (p == current &&
>> +is_migration_disabled(p) &&
>> +!cpumask_test_cpu(task_cpu(p), new_mask))
>> +ret = -EBUSY;
>> +
>
> This shouldn't happen, right? The function may sleep so it shouldn't be
> entered with disabled migration. A WARN_ON might spot the bad caller.
>
Yeah, this is one of those paranoia-driven checks.
> Sebastian
Re: [PATCH 1/2] sched: Deny self-issued __set_cpus_allowed_ptr() when migrate_disable()
On Tue, Oct 13, 2020 at 04:15:08PM +0200, Sebastian Andrzej Siewior wrote:
> On 2020-10-13 15:01:15 [+0100], Valentin Schneider wrote:
> > migrate_disable();
> > set_cpus_allowed_ptr(current, {something excluding task_cpu(current)});
> > affine_move_task(); <-- never returns
> >
> > Signed-off-by: Valentin Schneider
> > ---
> > kernel/sched/core.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index 4ccd1099adaa..7f4e38819de1 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -2189,6 +2189,11 @@ static int __set_cpus_allowed_ptr(struct task_struct
> > *p,
> > if (!(flags & SCA_MIGRATE_ENABLE) && cpumask_equal(>cpus_mask,
> > new_mask))
> > goto out;
> >
> > + if (p == current &&
> > + is_migration_disabled(p) &&
> > + !cpumask_test_cpu(task_cpu(p), new_mask))
> > + ret = -EBUSY;
> > +
>
> This shouldn't happen, right? The function may sleep so it shouldn't be
> entered with disabled migration. A WARN_ON might spot the bad caller.
So yeah, I like detecting the case but agree with bigeasy that an
additional WARN would make sense, lemme go add that.
[PATCH v3 6/7] tracing: Handle synthetic event array field type checking correctly
Since synthetic event array types are derived from the field name,
there may be a semicolon at the end of the type which should be
stripped off.
If there are more characters following that, normal type string
checking will result in an invalid type.
Without this patch, you can end up with an invalid field type string
that gets displayed in both the synthetic event description and the
event format:
Before:
# echo 'myevent char str[16]; int v' >> synthetic_events
# cat synthetic_events
myevent char[16]; str; int v
name: myevent
ID: 1936
format:
field:unsigned short common_type; offset:0; size:2;
signed:0;
field:unsigned char common_flags; offset:2; size:1;
signed:0;
field:unsigned char common_preempt_count; offset:3; size:1;
signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:char str[16];;offset:8; size:16;signed:1;
field:int v;offset:40; size:4; signed:1;
print fmt: "str=%s, v=%d", REC->str, REC->v
After:
# echo 'myevent char str[16]; int v' >> synthetic_events
# cat synthetic_events
myevent char[16] str; int v
# cat events/synthetic/myevent/format
name: myevent
ID: 1936
format:
field:unsigned short common_type; offset:0; size:2;
signed:0;
field:unsigned char common_flags; offset:2; size:1;
signed:0;
field:unsigned char common_preempt_count; offset:3; size:1;
signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:char str[16]; offset:8; size:16;signed:1;
field:int v;offset:40; size:4; signed:1;
print fmt: "str=%s, v=%d", REC->str, REC->v
[ : wrote parse_synth_field() snippet. ]
Fixes: 4b147936fa50 (tracing: Add support for 'synthetic' events)
Reported-by: Masami Hiramatsu
Signed-off-by: Tom Zanussi
---
kernel/trace/trace_events_synth.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/kernel/trace/trace_events_synth.c
b/kernel/trace/trace_events_synth.c
index 7efe39be6576..ac3d112268ed 100644
--- a/kernel/trace/trace_events_synth.c
+++ b/kernel/trace/trace_events_synth.c
@@ -174,7 +174,7 @@ static int synth_field_string_size(char *type)
start += sizeof("char[") - 1;
end = strchr(type, ']');
- if (!end || end < start)
+ if (!end || end < start || type + strlen(type) > end + 1)
return -EINVAL;
len = end - start;
@@ -625,8 +625,14 @@ static struct synth_field *parse_synth_field(int argc,
const char **argv,
if (field_type[0] == ';')
field_type++;
len = strlen(field_type) + 1;
- if (array)
- len += strlen(array);
+
+if (array) {
+int l = strlen(array);
+
+if (l && array[l - 1] == ';')
+l--;
+len += l;
+}
if (prefix)
len += strlen(prefix);
--
2.17.1
Re: [PATCH 1/2] dt-bindings: dmaengine: Add JZ4775 bindings.
On Thu, 08 Oct 2020 17:30:59 +0800, 周琰杰 (Zhou Yanjie) wrote: > Add the dmaengine bindings for the JZ4775 SoC from Ingenic. > > Signed-off-by: 周琰杰 (Zhou Yanjie) > --- > include/dt-bindings/dma/jz4775-dma.h | 44 > > 1 file changed, 44 insertions(+) > create mode 100644 include/dt-bindings/dma/jz4775-dma.h > Acked-by: Rob Herring
Re: [PATCH 2/2] dt-bindings: dmaengine: Add X2000 bindings.
On Thu, 08 Oct 2020 17:31:00 +0800, 周琰杰 (Zhou Yanjie) wrote: > Add the dmaengine bindings for the X2000 SoC from Ingenic. > > Signed-off-by: 周琰杰 (Zhou Yanjie) > --- > include/dt-bindings/dma/x2000-dma.h | 54 > + > 1 file changed, 54 insertions(+) > create mode 100644 include/dt-bindings/dma/x2000-dma.h > Acked-by: Rob Herring
[PATCH v3 7/7] selftests/ftrace: Add test case for synthetic event syntax errors
Add a selftest that verifies that the syntax error messages and caret
positions are correct for most of the possible synthetic event syntax
error cases.
Signed-off-by: Tom Zanussi
---
.../trigger-synthetic_event_syntax_errors.tc | 19 +++
1 file changed, 19 insertions(+)
create mode 100644
tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-synthetic_event_syntax_errors.tc
diff --git
a/tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-synthetic_event_syntax_errors.tc
b/tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-synthetic_event_syntax_errors.tc
new file mode 100644
index ..ada594fe16cb
--- /dev/null
+++
b/tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-synthetic_event_syntax_errors.tc
@@ -0,0 +1,19 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+# description: event trigger - test synthetic_events syntax parser errors
+# requires: synthetic_events error_log
+
+check_error() { # command-with-error-pos-by-^
+ftrace_errlog_check 'synthetic_events' "$1" 'synthetic_events'
+}
+
+check_error 'myevent ^chr arg' # INVALID_TYPE
+check_error 'myevent ^char str[];; int v' # INVALID_TYPE
+check_error 'myevent char ^str]; int v'# INVALID_NAME
+check_error 'myevent char ^str;[]' # INVALID_NAME
+check_error 'myevent ^char str[; int v'# INVALID_TYPE
+check_error '^mye;vent char str[]' # BAD_NAME
+check_error 'myevent char str[]; ^int' # INVALID_FIELD
+check_error '^myevent' # INCOMPLETE_CMD
+
+exit 0
--
2.17.1
[PATCH v3 2/7] tracing: Move is_good_name() from trace_probe.h to trace.h
is_good_name() is useful for other trace infrastructure, such as
synthetic events, so make it available via trace.h.
Acked-by: Masami Hiramatsu
Signed-off-by: Tom Zanussi
---
kernel/trace/trace.h | 13 +
kernel/trace/trace_probe.h | 13 -
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 5b0e797cacdd..a94852838491 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_FTRACE_SYSCALLS
#include /* For NR_SYSCALLS */
@@ -2090,4 +2091,16 @@ static __always_inline void trace_iterator_reset(struct
trace_iterator *iter)
iter->pos = -1;
}
+/* Check the name is good for event/group/fields */
+static inline bool is_good_name(const char *name)
+{
+ if (!isalpha(*name) && *name != '_')
+ return false;
+ while (*++name != '\0') {
+ if (!isalpha(*name) && !isdigit(*name) && *name != '_')
+ return false;
+ }
+ return true;
+}
+
#endif /* _LINUX_KERNEL_TRACE_H */
diff --git a/kernel/trace/trace_probe.h b/kernel/trace/trace_probe.h
index 04d00987da69..2f703a20c724 100644
--- a/kernel/trace/trace_probe.h
+++ b/kernel/trace/trace_probe.h
@@ -16,7 +16,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -348,18 +347,6 @@ bool trace_probe_match_command_args(struct trace_probe *tp,
#define trace_probe_for_each_link_rcu(pos, tp) \
list_for_each_entry_rcu(pos, &(tp)->event->files, list)
-/* Check the name is good for event/group/fields */
-static inline bool is_good_name(const char *name)
-{
- if (!isalpha(*name) && *name != '_')
- return false;
- while (*++name != '\0') {
- if (!isalpha(*name) && !isdigit(*name) && *name != '_')
- return false;
- }
- return true;
-}
-
#define TPARG_FL_RETURN BIT(0)
#define TPARG_FL_KERNEL BIT(1)
#define TPARG_FL_FENTRY BIT(2)
--
2.17.1
[PATCH v3 4/7] tracing: Add synthetic event error logging
Add support for synthetic event error logging, which entails adding a
logging function for it, a way to save the synthetic event command,
and a set of specific synthetic event parse error strings and
handling.
[ : wrote save_cmdstr() seq_buf implementation. ]
Signed-off-by: Tom Zanussi
---
kernel/trace/trace_events_synth.c | 92 ++-
1 file changed, 90 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_events_synth.c
b/kernel/trace/trace_events_synth.c
index 8c9d6e464da0..7efe39be6576 100644
--- a/kernel/trace/trace_events_synth.c
+++ b/kernel/trace/trace_events_synth.c
@@ -20,6 +20,48 @@
#include "trace_synth.h"
+#undef ERRORS
+#define ERRORS \
+ C(BAD_NAME, "Illegal name"),\
+ C(CMD_INCOMPLETE, "Incomplete command"), \
+ C(EVENT_EXISTS, "Event already exists"),\
+ C(TOO_MANY_FIELDS, "Too many fields"), \
+ C(INCOMPLETE_TYPE, "Incomplete type"), \
+ C(INVALID_TYPE, "Invalid type"),\
+ C(INVALID_FIELD,"Invalid field"), \
+ C(CMD_TOO_LONG, "Command too long"),
+
+#undef C
+#define C(a, b)SYNTH_ERR_##a
+
+enum { ERRORS };
+
+#undef C
+#define C(a, b)b
+
+static const char *err_text[] = { ERRORS };
+
+static char last_cmd[MAX_FILTER_STR_VAL];
+
+static int errpos(const char *str)
+{
+ return err_pos(last_cmd, str);
+}
+
+static void last_cmd_set(char *str)
+{
+ if (!str)
+ return;
+
+ strncpy(last_cmd, str, MAX_FILTER_STR_VAL - 1);
+}
+
+static void synth_err(u8 err_type, u8 err_pos)
+{
+ tracing_log_err(NULL, "synthetic_events", last_cmd, err_text,
+ err_type, err_pos);
+}
+
static int create_synth_event(int argc, const char **argv);
static int synth_event_show(struct seq_file *m, struct dyn_event *ev);
static int synth_event_release(struct dyn_event *ev);
@@ -545,8 +587,10 @@ static struct synth_field *parse_synth_field(int argc,
const char **argv,
field_type++;
if (!strcmp(field_type, "unsigned")) {
- if (argc < 3)
+ if (argc < 3) {
+ synth_err(SYNTH_ERR_INCOMPLETE_TYPE,
errpos(field_type));
return ERR_PTR(-EINVAL);
+ }
prefix = "unsigned ";
field_type = argv[1];
field_name = argv[2];
@@ -573,6 +617,7 @@ static struct synth_field *parse_synth_field(int argc,
const char **argv,
goto free;
}
if (!is_good_name(field->name)) {
+ synth_err(SYNTH_ERR_BAD_NAME, errpos(field_name));
ret = -EINVAL;
goto free;
}
@@ -601,6 +646,7 @@ static struct synth_field *parse_synth_field(int argc,
const char **argv,
size = synth_field_size(field->type);
if (size < 0) {
+ synth_err(SYNTH_ERR_INVALID_TYPE, errpos(field_type));
ret = -EINVAL;
goto free;
} else if (size == 0) {
@@ -621,6 +667,7 @@ static struct synth_field *parse_synth_field(int argc,
const char **argv,
field->is_dynamic = true;
size = sizeof(u64);
} else {
+ synth_err(SYNTH_ERR_INVALID_TYPE, errpos(field_type));
ret = -EINVAL;
goto free;
}
@@ -1098,12 +1145,47 @@ int synth_event_gen_cmd_array_start(struct dynevent_cmd
*cmd, const char *name,
}
EXPORT_SYMBOL_GPL(synth_event_gen_cmd_array_start);
+static int save_cmdstr(int argc, const char *name, const char **argv)
+{
+struct seq_buf s;
+ char *buf;
+ int i;
+
+buf = kzalloc(MAX_DYNEVENT_CMD_LEN, GFP_KERNEL);
+if (!buf)
+return -ENOMEM;
+
+seq_buf_init(, buf, MAX_DYNEVENT_CMD_LEN);
+
+seq_buf_puts(, name);
+
+for (i = 0; i < argc; i++) {
+seq_buf_putc(, ' ');
+seq_buf_puts(, argv[i]);
+}
+
+if (!seq_buf_buffer_left()) {
+synth_err(SYNTH_ERR_CMD_TOO_LONG, 0);
+kfree(buf);
+return -EINVAL;
+}
+buf[s.len] = 0;
+last_cmd_set(buf);
+
+kfree(buf);
+return 0;
+}
+
static int __create_synth_event(int argc, const char *name, const char **argv)
{
struct synth_field *field, *fields[SYNTH_FIELDS_MAX];
struct synth_event *event = NULL;
int i, consumed = 0, n_fields = 0, ret = 0;
+ ret = save_cmdstr(argc, name, argv);
+ if (ret)
+ return ret;
+
/*
* Argument syntax:
* - Add synthetic event: field[;field] ...
@@ -,18 +1193,22 @@ static int __create_synth_event(int argc, const char
*name, const char **argv)
* where
[PATCH v3 0/7] tracing: Synthetic event dynamic string fixes
This updates v2 to replace some of the v2 code with improved code from Steve (tracing: Add synthetic event error logging) and (tracing: Handle synthetic event array field type checking correctly) and remove the synth_error_clear() function and change last_cmd_set() to use strncpy. Thanks, Tom v2 text: This updates v1 to fix a couple of additional things that Masami pointed out: - The error logging for the BAD_TYPE error was actually pointing to the name - it now points to the type as it should. - Added a new test case that verifies most of the synthetic event error messages and caret positions. - Added a new patch that correctly strips off trailing semicolons and everything else from array types, which wasn't happening before, even before the dynamic array patches. Original v1 text: These patches provide fixes for the problems observed by Masami in the new synthetic event dynamic string patchset. The first patch (tracing: Don't show dynamic string internals in synthetic event description) removes the __data_loc from the event description but leaves it in the format. The patch (tracing: Add synthetic event error logging) addresses the lack of error messages when parse errors occur. The remaining three patches address the other problems Masami noted which result from allowing illegal characters in synthetic event and field names when defining an event. The is_good_name() function is used to check that's not possible for the probe events, but should also be used for the synthetic events as well. (tracing: Move is_good_name() from trace_probe.h to trace.h) makes that function available to other trace subsystems by putting it in trace.h. (tracing: Check that the synthetic event and field names are legal) applies it to the synthetic events, and (selftests/ftrace: Change synthetic event name for inter-event-combined test) changes a testcase that now fails because it uses an illegal name. The following changes since commit 848183553e431e6e9c2ea2f72421a7a1bbc6532e: tracing: Fix synthetic print fmt check for use of __get_str() (2020-10-08 15:29:07 -0400) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/zanussi/linux-trace.git ftrace/dynstring-fixes-v3 Tom Zanussi (7): tracing: Don't show dynamic string internals in synthetic event description tracing: Move is_good_name() from trace_probe.h to trace.h tracing: Check that the synthetic event and field names are legal tracing: Add synthetic event error logging selftests/ftrace: Change synthetic event name for inter-event-combined test tracing: Handle synthetic event array field type checking correctly selftests/ftrace: Add test case for synthetic event syntax errors kernel/trace/trace.h | 13 ++ kernel/trace/trace_events_synth.c | 123 +- kernel/trace/trace_probe.h| 13 -- .../trigger-inter-event-combined-hist.tc | 8 +- .../trigger-synthetic_event_syntax_errors.tc | 19 +++ 5 files changed, 153 insertions(+), 23 deletions(-) create mode 100644 tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-synthetic_event_syntax_errors.tc -- 2.17.1
[PATCH v3 1/7] tracing: Don't show dynamic string internals in synthetic event description
For synthetic event dynamic fields, the type contains "__data_loc",
which is basically an internal part of the type which is only meant to
be displayed in the format, not in the event description itself, which
is confusing to users since they can't use __data_loc on the
command-line to define an event field, which printing it would lead
them to believe.
So filter it out from the description, while leaving it in the type.
Reported-by: Masami Hiramatsu
Signed-off-by: Tom Zanussi
---
kernel/trace/trace_events_synth.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace_events_synth.c
b/kernel/trace/trace_events_synth.c
index 3b2dcc42b8ee..b19e2f4159ab 100644
--- a/kernel/trace/trace_events_synth.c
+++ b/kernel/trace/trace_events_synth.c
@@ -1867,14 +1867,22 @@ static int __synth_event_show(struct seq_file *m,
struct synth_event *event)
{
struct synth_field *field;
unsigned int i;
+ char *type, *t;
seq_printf(m, "%s\t", event->name);
for (i = 0; i < event->n_fields; i++) {
field = event->fields[i];
+ type = field->type;
+ t = strstr(type, "__data_loc");
+ if (t) { /* __data_loc belongs in format but not event desc */
+ t += sizeof("__data_loc");
+ type = t;
+ }
+
/* parameter values */
- seq_printf(m, "%s %s%s", field->type, field->name,
+ seq_printf(m, "%s %s%s", type, field->name,
i == event->n_fields - 1 ? "" : "; ");
}
--
2.17.1
[PATCH v3 3/7] tracing: Check that the synthetic event and field names are legal
Call the is_good_name() function used by probe events to make sure
synthetic event and field names don't contain illegal characters and
cause unexpected parsing of synthetic event commands.
Fixes: 4b147936fa50 (tracing: Add support for 'synthetic' events)
Reported-by: Masami Hiramatsu
Reviewed-by: Masami Hiramatsu
Tested-by: Masami Hiramatsu
Signed-off-by: Tom Zanussi
---
kernel/trace/trace_events_synth.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/kernel/trace/trace_events_synth.c
b/kernel/trace/trace_events_synth.c
index b19e2f4159ab..8c9d6e464da0 100644
--- a/kernel/trace/trace_events_synth.c
+++ b/kernel/trace/trace_events_synth.c
@@ -572,6 +572,10 @@ static struct synth_field *parse_synth_field(int argc,
const char **argv,
ret = -ENOMEM;
goto free;
}
+ if (!is_good_name(field->name)) {
+ ret = -EINVAL;
+ goto free;
+ }
if (field_type[0] == ';')
field_type++;
@@ -1112,6 +1116,11 @@ static int __create_synth_event(int argc, const char
*name, const char **argv)
mutex_lock(_mutex);
+ if (!is_good_name(name)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
event = find_synth_event(name);
if (event) {
ret = -EEXIST;
--
2.17.1
[PATCH v3 5/7] selftests/ftrace: Change synthetic event name for inter-event-combined test
This test uses waking+wakeup_latency as an event name, which doesn't make sense since it includes an operator. Illegal names are now detected by the synthetic event command parsing, which causes this test to fail. Change the name to 'waking_plus_wakeup_latency' to prevent this. Fixes: f06eec4d0f2c (selftests: ftrace: Add inter-event hist triggers testcases) Acked-by: Masami Hiramatsu Signed-off-by: Tom Zanussi --- .../inter-event/trigger-inter-event-combined-hist.tc | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-inter-event-combined-hist.tc b/tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-inter-event-combined-hist.tc index 7449a4b8f1f9..9098f1e7433f 100644 --- a/tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-inter-event-combined-hist.tc +++ b/tools/testing/selftests/ftrace/test.d/trigger/inter-event/trigger-inter-event-combined-hist.tc @@ -25,12 +25,12 @@ echo 'wakeup_latency u64 lat pid_t pid' >> synthetic_events echo 'hist:keys=pid:ts1=common_timestamp.usecs if comm=="ping"' >> events/sched/sched_wakeup/trigger echo 'hist:keys=next_pid:wakeup_lat=common_timestamp.usecs-$ts1:onmatch(sched.sched_wakeup).wakeup_latency($wakeup_lat,next_pid) if next_comm=="ping"' > events/sched/sched_switch/trigger -echo 'waking+wakeup_latency u64 lat; pid_t pid' >> synthetic_events -echo 'hist:keys=pid,lat:sort=pid,lat:ww_lat=$waking_lat+$wakeup_lat:onmatch(synthetic.wakeup_latency).waking+wakeup_latency($ww_lat,pid)' >> events/synthetic/wakeup_latency/trigger -echo 'hist:keys=pid,lat:sort=pid,lat' >> events/synthetic/waking+wakeup_latency/trigger +echo 'waking_plus_wakeup_latency u64 lat; pid_t pid' >> synthetic_events +echo 'hist:keys=pid,lat:sort=pid,lat:ww_lat=$waking_lat+$wakeup_lat:onmatch(synthetic.wakeup_latency).waking_plus_wakeup_latency($ww_lat,pid)' >> events/synthetic/wakeup_latency/trigger +echo 'hist:keys=pid,lat:sort=pid,lat' >> events/synthetic/waking_plus_wakeup_latency/trigger ping $LOCALHOST -c 3 -if ! grep -q "pid:" events/synthetic/waking+wakeup_latency/hist; then +if ! grep -q "pid:" events/synthetic/waking_plus_wakeup_latency/hist; then fail "Failed to create combined histogram" fi -- 2.17.1
Re: [PATCH v9 05/15] dt-bindings: connector: Add property to set initial current cap for FRS
On Wed, Oct 7, 2020 at 8:07 PM Badhri Jagan Sridharan wrote: > > On Tue, Oct 6, 2020 at 11:29 AM Rob Herring wrote: > > > > On Mon, Sep 28, 2020 at 07:39:54PM -0700, Badhri Jagan Sridharan wrote: > > > This change adds frs-typec-current which allows setting the initial > > > current > > > capability of the new source when vSafe5V is applied during PD3.0 > > > sink Fast Role Swap. > > > > Shouldn't you Cc the person you copied this from? > Not sure whether I get this comment. The patch wasn't copied. Maybe you were > expecting me to CC amelie.delau...@st.com ? if so, just now CC'ed. > > > > > > > > Signed-off-by: Badhri Jagan Sridharan > > > --- > > > Changes since v1: > > > - Changing patch version to v6 to fix version number confusion. > > > > > > Changes since v6: > > > - Removed the redundant usb-connector.txt that I created by mistake. > > > - Moved to yaml. > > > > > > Changes since v7: > > > - Rebase > > > > > > Changes since v8: > > > - Redefine new-source-frs-typec-current as string enums to address > > > Rob Herring's comment. > > > --- > > > .../bindings/connector/usb-connector.yaml | 26 +++ > > > include/dt-bindings/usb/pd.h | 10 +++ > > > 2 files changed, 36 insertions(+) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/connector/usb-connector.yaml > > > b/Documentation/devicetree/bindings/connector/usb-connector.yaml > > > index 9bd52e63c935..0b8cd08a8678 100644 > > > --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml > > > +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml > > > @@ -142,6 +142,32 @@ properties: > > > required: > > >- port@0 > > > > > > + new-source-frs-typec-current: > > > +description: Initial current capability of the new source when > > > vSafe5V > > > + is applied during PD3.0 Fast Role Swap. "Table 6-14 Fixed Supply > > > PDO - Sink" > > > + of "USB Power Delivery Specification Revision 3.0, Version 1.2" > > > provides the > > > + different power levels and "6.4.1.3.1.6 Fast Role Swap USB Type-C > > > Current" > > > + provides a detailed description of the field. The sink PDO from > > > current source > > > + reflects the current source's(i.e. transmitter of the FRS signal) > > > power > > > + requirement during fr swap. The current sink (i.e. receiver of the > > > FRS signal), > > > + a.k.a new source, should check if it will be able to satisfy the > > > current source's, > > > + new sink's, requirement during frswap before enabling the frs > > > signal reception. > > > + This property refers to maximum current capability that the > > > current sink can > > > + satisfy. During FRS, VBUS voltage is at 5V, as the partners are in > > > implicit > > > + contract, hence, the power level is only a function of the current > > > capability. > > > + "not-supported" implies sink to source fast role swap not > > > supported. > > > + "default" refers to default USB power level as described by > > > + "Table 6-14 Fixed Supply PDO - Sink". > > > + "1.5A" refers to 1.5A@5V. > > > + "3.0A" refers to 3.0A@5V. > > > > > > > + > > > +$ref: /schemas/types.yaml#/definitions/string > > > +enum: > > > + - not-supported > > > + - default > > > + - 1.5A > > > + - 3.0A > > > > What happens if the property is not present? > > The behavior would be the same as "not-supported". Then you don't need 'not-supported'. > > > > > I'm not crazy about mixing strings and what could be a number. > > v8 version[1] of the patch was using uint32. I moved to using strings > as you were asking to unify with the approach in [2]. Since [3] was using > string enums, I moved to that. I don't have a strong preference here, so > I can move back to using u32 if you feel so. Since the u32 values are based on the USB spec, I think I prefer that. Should be easier to deal with in the driver than doing strcmp's. Rob
Re: [PATCH v4] kcov, usb: specify contexts for remote coverage sections
On Tue, Oct 13, 2020 at 3:58 PM Andrey Konovalov wrote: > > > Currently there's a KCOV remote coverage collection section in > > > __usb_hcd_giveback_urb(). Initially that section was added based on the > > > assumption that usb_hcd_giveback_urb() can only be called in interrupt > > > context as indicated by a comment before it. This is what happens when > > > syzkaller is fuzzing the USB stack via the dummy_hcd driver. > > > > > > As it turns out, it's actually valid to call usb_hcd_giveback_urb() in > > > task > > > context, provided that the caller turned off the interrupts; USB/IP does > > > exactly that. This can lead to a nested KCOV remote coverage collection > > > sections both trying to collect coverage in task context. This isn't > > > supported by KCOV, and leads to a WARNING. > > > > How does this recursion happen? There is literal recursion in the task > > context? A function starts a remote coverage section and calls another > > function that also starts a remote coverage section? > > Yes, a literal recursion. Background thread for processing requests > for USB/IP hub (which we collect coverage from) calls > __usb_hcd_giveback_urb(). > > Here's the stack trace: > > kcov_remote_start_usb include/linux/kcov.h:52 [inline] > __usb_hcd_giveback_urb+0x284/0x4b0 drivers/usb/core/hcd.c:1649 > usb_hcd_giveback_urb+0x367/0x410 drivers/usb/core/hcd.c:1716 > vhci_urb_enqueue.cold+0x37f/0x4c5 drivers/usb/usbip/vhci_hcd.c:801 > usb_hcd_submit_urb+0x2b1/0x20d0 drivers/usb/core/hcd.c:1547 > usb_submit_urb+0x6e5/0x13b0 drivers/usb/core/urb.c:570 > usb_start_wait_urb+0x10f/0x2c0 drivers/usb/core/message.c:58 > usb_internal_control_msg drivers/usb/core/message.c:102 [inline] > usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153 > hub_set_address drivers/usb/core/hub.c:4472 [inline] > hub_port_init+0x23f6/0x2d20 drivers/usb/core/hub.c:4748 > hub_port_connect drivers/usb/core/hub.c:5140 [inline] > hub_port_connect_change drivers/usb/core/hub.c:5348 [inline] > port_event drivers/usb/core/hub.c:5494 [inline] > hub_event+0x1cc9/0x38d0 drivers/usb/core/hub.c:5576 > process_one_work+0x7b6/0x1190 kernel/workqueue.c:2269 > worker_thread+0x94/0xdc0 kernel/workqueue.c:2415 > kthread+0x372/0x450 kernel/kthread.c:292 > ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 > > > Or is there recursion between task context and softirq context? > > No. This kind of recursion is actually supported by kcov right now. A > softirq with a coverage collection section can come in the middle of a > coverage collection section for a task. > > > But > > this should not happen if softirq's disabled around > > usb_hcd_giveback_urb call in task context... > > [...] > > > We do want to collect coverage from usb_hcd_giveback_urb in the task > > context eventually, right? > > Ideally, eventually, yes. > > > Is this API supposed to be final? Or it only puts down fire re the warning? > > Only puts down the fire. > > > I don't understand how this API can be used in other contexts. > > Let's say there is recursion in task context and we want to collect > > coverage in task context (the function is only called in task > > context). This API won't help. > > No, it won't. Full recursion support is required for this. > > > Let's say a function is called from both task and softirq context and > > these can recurse (softirq arrive while in remote task section). This > > API won't help. It will force to choose either task or softirq, but > > let's say you can't make that choice because they are equally > > important. > > This currently works, everything that happens in a softirq gets > associated with softirq, everything else - with the task. This seems > to be the only logical approach here, it makes no sense to associate > what happens in a softirq with the task where the softirq happened. > > > The API helps to work around the unimplemented recursion in KCOV, but > > it's also specific to this particular case. It's not necessary that > > recursion is specific to one context only and it's not necessary that > > a user can choose to sacrifice one of the contexts. > > Also, if we support recursion in one way or another, we will never > > want to use this API, right? > > Correct. I see. The following is simpler option that does what this patch achieves but in a more direct way: // Because ... if (in_serving_softirq()) kcov_remote_start_usb((u64)urb->dev->bus->busnum);
Re: [PATCH 1/2] sched: Deny self-issued __set_cpus_allowed_ptr() when migrate_disable()
On 2020-10-13 15:01:15 [+0100], Valentin Schneider wrote:
> migrate_disable();
> set_cpus_allowed_ptr(current, {something excluding task_cpu(current)});
> affine_move_task(); <-- never returns
>
> Signed-off-by: Valentin Schneider
> ---
> kernel/sched/core.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 4ccd1099adaa..7f4e38819de1 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2189,6 +2189,11 @@ static int __set_cpus_allowed_ptr(struct task_struct
> *p,
> if (!(flags & SCA_MIGRATE_ENABLE) && cpumask_equal(>cpus_mask,
> new_mask))
> goto out;
>
> + if (p == current &&
> + is_migration_disabled(p) &&
> + !cpumask_test_cpu(task_cpu(p), new_mask))
> + ret = -EBUSY;
> +
This shouldn't happen, right? The function may sleep so it shouldn't be
entered with disabled migration. A WARN_ON might spot the bad caller.
Sebastian
Re: [PATCH 4.19 27/38] iommu/exynos: add missing put_device() call in exynos_iommu_of_xlate()
Hi! > >> From: Yu Kuai > >> > >> [ Upstream commit 1a26044954a6d1f4d375d5e62392446af663be7a ] > >> > >> if of_find_device_by_node() succeed, exynos_iommu_of_xlate() doesn't have > >> a corresponding put_device(). Thus add put_device() to fix the exception > >> handling for this function implementation. > > Okay, this looks reasonable, but... > > > > Do we miss put_device() in normal path, too? I'd expect another > > put_device at end of exynos_iommu_of_xlate() or perhaps in release > > path somewhere... > > Frankly, there is no release path, so there is no need for put_device. > Once initialized, Exynos IOMMU stays in the system forever. There is no > point to remove IOMMU nor the API for that. Keeping increased refcount > for its device just matches this behavior. > > If the missing put_device() is really a problem, then we can move it > from the error path just after data = platform_get_drvdata(sysmmu) > assignment. Feel free to send a patch if you think this is a more > appropriate approach. exynos_iommu_detach_device() looks like a place where resources could be freed? But if there's no release path, we don't really need to do anything. Sorry about the noise. Best regards, Pavel -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany signature.asc Description: PGP signature
[PATCH] can: Explain PDU in CAN_ISOTP help text
The help text for the CAN_ISOTP config symbol uses the acronym "PDU". However, this acronym is not explained here, nor in Documentation/networking/can.rst. Expand the acronym to make it easier for users to decide if they need to enable the CAN_ISOTP option or not. Signed-off-by: Geert Uytterhoeven --- net/can/Kconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/net/can/Kconfig b/net/can/Kconfig index 224e5e0283a986d9..7c9958df91d353c8 100644 --- a/net/can/Kconfig +++ b/net/can/Kconfig @@ -62,8 +62,9 @@ config CAN_ISOTP communication between CAN nodes via two defined CAN Identifiers. As CAN frames can only transport a small amount of data bytes (max. 8 bytes for 'classic' CAN and max. 64 bytes for CAN FD) this - segmentation is needed to transport longer PDUs as needed e.g. for - vehicle diagnosis (UDS, ISO 14229) or IP-over-CAN traffic. + segmentation is needed to transport longer Protocol Data Units (PDU) + as needed e.g. for vehicle diagnosis (UDS, ISO 14229) or IP-over-CAN + traffic. This protocol driver implements data transfers according to ISO 15765-2:2016 for 'classic' CAN and CAN FD frame types. If you want to perform automotive vehicle diagnostic services (UDS), -- 2.17.1
Business Funding Proposal
Good Day, I am Dr.Per Lessen and I work as a financial consultant with Global Asset Management company LLC and some High Net worth individuals from the MENA region and European Union . Basically, my principals are interested in investing in projects that are viable and has capacity of generating a reasonable ROI for the investor. I MUST consider you a privileged entity who shall be privy to many sourcable CLEAN fund meant for foreign investment and you are able to access up to One Billion Euro or More. I will wish that you send a copy of your highlighted projects with a elucidated BUSINESS PLANS and EXECUTIVE SUMMARY which I shall propagate for its immediate approval for a minimal ROI return on investment which you shall have sole mandate. You should also bear in mind that funding of this nature is not completed on email communication alone, there will be the need for a face to face meeting with the investor or His representatives and have the paperwork perfected and signed. kindly reply as soon as possible if you have any viable project that you will want us to be involved as indicated above. Thanks Dr. Per Lessen -- Good Day, I am Dr.Per Lessen and I work as a financial consultant with Global Asset Management company LLC and some High Net worth individuals from the MENA region and European Union . Basically, my principals are interested in investing in projects that are viable and has capacity of generating a reasonable ROI for the investor. I MUST consider you a privileged entity who shall be privy to many sourcable CLEAN fund meant for foreign investment and you are able to access up to One Billion Euro or More. I will wish that you send a copy of your highlighted projects with a elucidated BUSINESS PLANS and EXECUTIVE SUMMARY which I shall propagate for its immediate approval for a minimal ROI return on investment which you shall have sole mandate. You should also bear in mind that funding of this nature is not completed on email communication alone, there will be the need for a face to face meeting with the investor or His representatives and have the paperwork perfected and signed. kindly reply as soon as possible if you have any viable project that you will want us to be involved as indicated above. Thanks Dr. Per Lessen
Re: [PATCH v10 00/15] TCPM support for FRS and AutoDischarge Disconnect
On Thu, Oct 8, 2020 at 2:45 AM Greg Kroah-Hartman wrote: > > On Wed, Oct 07, 2020 at 11:15:41PM -0700, Badhri Jagan Sridharan wrote: > > Hi, > > > > Made two changes: > > > > 1. Added "additionalProperties: false" as suggested by Rob Herring in > > https://lore.kernel.org/linux-usb/20201005144618.GA154206@bogus/ > > > > 2. Removed FRS dts binding constants to address Rob Herring's comment in > > https://lore.kernel.org/linux-usb/20201006182940.GA2574941@bogus/ And didn't address my other comments... > That worked better. I've applied the patches that Heikki had reviewed > to my usb-testing branch now. Why is the driver being applied without the binding? Bindings come first. The binding and driver don't even agree on the compatible string (maxim,tcpci vs. maxim,tcpc), neither of which are right. The FRS bindings need to be sorted out too as we have multiple folks proposing bindings for it. I wish someone would review all these TypeC related bindings because I'm getting a continual stream of piecemeal additions with no coordination and I don't have knowledge on TypeC nor bandwidth to review it all. Rob
[RFC/PATCH] MIPS: ralink: adds support for RT6855 SoC family
Add support code for rt6855 SOC.
The new irq-rt6855.c is based on irq.c
Signed-off-by: Rafaël Carré
---
Hello,
I decided I wanted to make OpenWRT run on this Linksys WAP300N router.
With the help of a serial console and the vendor GPL sources dump the
router can now boot 5.9 and give me a console prompt.
As a MIPS and kernel newbie I am pretty stoked ;)
It is still missing quite a few devices: net (ethernet/wlan), watchdog,
button, leds, maybe something else.
The timer (used to update jiffies I guess?) is most likely already
setup by U-Boot. IIUC there is room for a second timer although I am
not sure if it's required.
The simple IRQ controller is based on the existing Ralink 'intc' one.
I even re-used the name, I guess intc stands for "INTerrupt Controller"
Please give me your comments and insights on this simple patch, and
let me know if it's worth upstreaming this or if I should just leave
this patch and the next ones in the OpenWRT tree.
Thanks
Rafaël
arch/mips/boot/dts/ralink/Makefile| 1 +
arch/mips/boot/dts/ralink/rt6855.dtsi | 64 ++
arch/mips/boot/dts/ralink/wap300n.dts | 18 +++
arch/mips/ralink/Kconfig | 11 +-
arch/mips/ralink/Makefile | 6 +-
arch/mips/ralink/Platform | 5 +
arch/mips/ralink/early_printk.c | 5 +-
arch/mips/ralink/irq-rt6855.c | 168 ++
arch/mips/ralink/rt6855.c | 48
9 files changed, 323 insertions(+), 3 deletions(-)
create mode 100644 arch/mips/boot/dts/ralink/rt6855.dtsi
create mode 100644 arch/mips/boot/dts/ralink/wap300n.dts
create mode 100644 arch/mips/ralink/irq-rt6855.c
create mode 100644 arch/mips/ralink/rt6855.c
diff --git a/arch/mips/boot/dts/ralink/Makefile
b/arch/mips/boot/dts/ralink/Makefile
index 6c26dfa0a903..08c612190936 100644
--- a/arch/mips/boot/dts/ralink/Makefile
+++ b/arch/mips/boot/dts/ralink/Makefile
@@ -3,6 +3,7 @@ dtb-$(CONFIG_DTB_RT2880_EVAL) += rt2880_eval.dtb
dtb-$(CONFIG_DTB_RT305X_EVAL) += rt3052_eval.dtb
dtb-$(CONFIG_DTB_RT3883_EVAL) += rt3883_eval.dtb
dtb-$(CONFIG_DTB_MT7620A_EVAL) += mt7620a_eval.dtb
+dtb-$(CONFIG_DTB_WAP300N) += wap300n.dtb
dtb-$(CONFIG_DTB_OMEGA2P) += omega2p.dtb
dtb-$(CONFIG_DTB_VOCORE2) += vocore2.dtb
diff --git a/arch/mips/boot/dts/ralink/rt6855.dtsi
b/arch/mips/boot/dts/ralink/rt6855.dtsi
new file mode 100644
index ..745808ee1e37
--- /dev/null
+++ b/arch/mips/boot/dts/ralink/rt6855.dtsi
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "ralink,rt6855-soc";
+
+ cpus {
+ cpu@0 {
+ compatible = "mips,mips4KEc";
+ };
+ };
+
+ cpuintc: cpuintc {
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ compatible = "mti,cpu-interrupt-controller";
+ };
+
+ palmbus@1fb2 {
+ compatible = "palmbus";
+ reg = <0x1fb2 0xe>;
+ ranges = <0x0 0x1fb2 0xD>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ sysc@0 {
+ compatible = "ralink,rt6855-sysc", "ralink,rt3050-sysc";
+ reg = <0x0 0x100>;
+ };
+
+ intc: intc@2 {
+ compatible = "ralink,rt6855-intc", "ralink,rt2880-intc";
+ reg = <0x2 0x100>;
+
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interrupt-parent = <>;
+ };
+
+ memc@300 {
+ compatible = "ralink,rt6855-memc", "ralink,rt3050-memc";
+ reg = <0x300 0x100>;
+ };
+
+ uart: uart@d {
+ compatible = "ns8250";
+ reg = <0xd 0x30>;
+ interrupts = <0>;
+
+ clock-frequency = <921600>;
+
+ reg-io-width = <4>;
+ reg-shift = <2>;
+ no-loopback-test;
+
+ status = "okay";
+
+ interrupt-parent = <>;
+ };
+ };
+};
diff --git a/arch/mips/boot/dts/ralink/wap300n.dts
b/arch/mips/boot/dts/ralink/wap300n.dts
new file mode 100644
index ..d923946c4abe
--- /dev/null
+++ b/arch/mips/boot/dts/ralink/wap300n.dts
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+/include/ "rt6855.dtsi"
+
+/ {
+ compatible = "ralink,rt6855-soc";
+ model = "Linksys WAP300n";
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x2 0x3fe>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,57600";
+ };
+};
diff --git
Re: [PATCH v2 04/24] docs: lockdep-design: fix some warning issues
On Tue, Oct 13, 2020 at 02:11:16PM +0100, Matthew Wilcox wrote: > On Tue, Oct 13, 2020 at 02:52:06PM +0200, Peter Zijlstra wrote: > > On Tue, Oct 13, 2020 at 02:14:31PM +0200, Mauro Carvalho Chehab wrote: > > > + = === > > > + ``.`` acquired while irqs disabled and not in irq context > > > + ``-`` acquired in irq context > > > + ``+`` acquired with irqs enabled > > > + ``?`` acquired in irq context with irqs enabled. > > > + = === > > > > NAK! > > You're seriously suggesting that: > > - === === > - '.' acquired while irqs disabled and not in irq context > - '-' acquired in irq context > - '+' acquired with irqs enabled > - '?' acquired in irq context with irqs enabled. > - === === > + = === > + ``.`` acquired while irqs disabled and not in irq context > + ``-`` acquired in irq context > + ``+`` acquired with irqs enabled > + ``?`` acquired in irq context with irqs enabled. > + = === > > this change makes the lockdep docs less readable? Definitely makes it harder to read for me. My C trained eyes go WTF at seeing it, which breaks the flow. ',' is a regular single character constant, '','' a syntax error. > It's not the markup that makes the lockdep documentation hard to > understand. I'm not sure what you're alluding to, the subject just isn't easy to begin with. Over all I'm tempted to just convert the whole thing to .txt and avoid all the RST shit entirely.
[GIT PULL] cgroup changes for v5.10-rc1
Hello, Linus. Two minor changes. One makes cgroup interface files ignore 0 sized writes rather than triggering -EINVAL on them. The other change is a cleanup which doesn't cause any behavior changes. Thanks. The following changes since commit 02de58b24d2e1b2cf947d57205bd2221d897193c: Merge tag 'devicetree-fixes-for-5.9-3' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux (2020-09-29 17:56:30 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-5.10 for you to fetch changes up to 65026da59cda16baf6c3e98b74ec439f366e468f: cgroup: Zero sized write should be no-op (2020-09-30 13:52:06 -0400) Jouni Roivas (1): cgroup: Zero sized write should be no-op Wei Yang (1): cgroup: remove redundant kernfs_activate in cgroup_setup_root() kernel/cgroup/cgroup.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- tejun
Re: [PATCH] v4l: Add source change event for colorimetry
On Tue, Oct 13, 2020 at 3:53 PM Stanimir Varbanov
wrote:
>
>
>
> On 10/13/20 4:40 PM, Tomasz Figa wrote:
> > On Tue, Oct 13, 2020 at 11:03 AM Stanimir Varbanov
> > wrote:
> >>
> >> Hi,
> >>
> >> On 7/2/20 2:52 PM, Stanimir Varbanov wrote:
> >>> Hi,
> >>>
> >>> Once we have this event there is still open question how the client will
> >>> know the data buffer on which the new colorspace is valid/applied.
> >>>
> >>> The options could be:
> >>> * a new buffer flag and
> >>> * some information in the v4l2_event structure.
> >>>
> >>> Thoughts?
> >>
> >> Kindly ping.
> >>
> >
> > The event itself sounds good to me, but how do we know which buffer is
> > the first to have the new colorimetry?
>
> I think Hans have a very good idea to have width/height and colorspace
> specifiers in v4l2_ext_buffer [1].
>
> [1] https://lkml.org/lkml/2020/9/9/531
>
Hmm, I think that would basically make the event obsolete and without
solving that problem I suspect the event is not very useful, because
one could already receive and display (incorrectly) some buffers
before realizing that they have different colorimetry.
I believe for now we would have to handle this like a resolution
change - flush the CAPTURE queue and the next buffer after the flush
would have the new colorimetry. With the new API we could optimize the
decoding by getting rid of the flushes and relying on the in-bound
information.
Best regards,
Tomasz
> >
> > Best regards,
> > Tomasz
> >
> >>>
> >>> On 7/2/20 1:00 PM, Stanimir Varbanov wrote:
> This event indicate that the source colorspace is changed
> during run-time. The client has to retrieve the new colorspace
> identifiers by getting the format (G_FMT).
>
> Signed-off-by: Stanimir Varbanov
> ---
> .../userspace-api/media/v4l/vidioc-dqevent.rst| 11 ++-
> .../userspace-api/media/videodev2.h.rst.exceptions| 1 +
> include/uapi/linux/videodev2.h| 1 +
> 3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst
> b/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst
> index a9a176d5256d..3f69c753db58 100644
> --- a/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst
> +++ b/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst
> @@ -381,7 +381,16 @@ call.
> that many Video Capture devices are not able to recover from a
> temporary
> loss of signal and so restarting streaming I/O is required in order
> for
> the hardware to synchronize to the video signal.
> -
> +* - ``V4L2_EVENT_SRC_CH_COLORIMETRY``
> + - 0x0002
> + - This event gets triggered when a colorspace change is detected
> at
> +an input. By colorspace change here we include also changes in the
> +colorspace specifiers (transfer function, Y'CbCr encoding and
> +quantization). This event can come from an input or from video
> decoder.
> +Once the event has been send to the client the driver has to update
> +the colorspace specifiers internally so that they could be
> retrieved by
> +client. In that case queue re-negotiation is not needed as this
> change
> +only reflects on the interpretation of the data.
>
> Return Value
>
> diff --git
> a/Documentation/userspace-api/media/videodev2.h.rst.exceptions
> b/Documentation/userspace-api/media/videodev2.h.rst.exceptions
> index ca05e4e126b2..54fc21af852d 100644
> --- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions
> +++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions
> @@ -492,6 +492,7 @@ replace define V4L2_EVENT_CTRL_CH_FLAGS
> ctrl-changes-flags
> replace define V4L2_EVENT_CTRL_CH_RANGE ctrl-changes-flags
>
> replace define V4L2_EVENT_SRC_CH_RESOLUTION src-changes-flags
> +replace define V4L2_EVENT_SRC_CH_COLORIMETRY src-changes-flags
>
> replace define V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ
> :c:type:`v4l2_event_motion_det`
>
> diff --git a/include/uapi/linux/videodev2.h
> b/include/uapi/linux/videodev2.h
> index 303805438814..b5838bc4e3a3 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -2351,6 +2351,7 @@ struct v4l2_event_frame_sync {
> };
>
> #define V4L2_EVENT_SRC_CH_RESOLUTION(1 << 0)
> +#define V4L2_EVENT_SRC_CH_COLORIMETRY (1 << 1)
>
> struct v4l2_event_src_change {
> __u32 changes;
>
> >>>
> >>
> >> --
> >> regards,
> >> Stan
>
> --
> regards,
> Stan
[PATCH 2/2] selftests: add tests for CLOSE_RANGE_CLOEXEC
Signed-off-by: Giuseppe Scrivano
---
.../testing/selftests/core/close_range_test.c | 44 +++
1 file changed, 44 insertions(+)
diff --git a/tools/testing/selftests/core/close_range_test.c
b/tools/testing/selftests/core/close_range_test.c
index c99b98b0d461..b8789262cd7d 100644
--- a/tools/testing/selftests/core/close_range_test.c
+++ b/tools/testing/selftests/core/close_range_test.c
@@ -23,6 +23,10 @@
#define CLOSE_RANGE_UNSHARE(1U << 1)
#endif
+#ifndef CLOSE_RANGE_CLOEXEC
+#define CLOSE_RANGE_CLOEXEC(1U << 2)
+#endif
+
static inline int sys_close_range(unsigned int fd, unsigned int max_fd,
unsigned int flags)
{
@@ -224,4 +228,44 @@ TEST(close_range_unshare_capped)
EXPECT_EQ(0, WEXITSTATUS(status));
}
+TEST(close_range_cloexec)
+{
+ int i, ret;
+ int open_fds[101];
+
+ for (i = 0; i < ARRAY_SIZE(open_fds); i++) {
+ int fd;
+
+ fd = open("/dev/null", O_RDONLY);
+ ASSERT_GE(fd, 0) {
+ if (errno == ENOENT)
+ XFAIL(return, "Skipping test since /dev/null
does not exist");
+ }
+
+ open_fds[i] = fd;
+ }
+
+ EXPECT_EQ(-1, sys_close_range(open_fds[0], open_fds[100], -1)) {
+ if (errno == ENOSYS)
+ XFAIL(return, "close_range() syscall not supported");
+ }
+
+ EXPECT_EQ(0, sys_close_range(open_fds[0], open_fds[50],
CLOSE_RANGE_CLOEXEC));
+
+ for (i = 0; i <= 50; i++) {
+ int flags = fcntl(open_fds[i], F_GETFD);
+
+ EXPECT_GT(flags, -1);
+ EXPECT_EQ(flags & FD_CLOEXEC, FD_CLOEXEC);
+ }
+
+ for (i = 51; i <= 100; i++) {
+ int flags = fcntl(open_fds[i], F_GETFD);
+
+ EXPECT_GT(flags, -1);
+ EXPECT_EQ(flags & FD_CLOEXEC, 0);
+ }
+}
+
+
TEST_HARNESS_MAIN
--
2.26.2
[PATCH 1/2] fs, close_range: add flag CLOSE_RANGE_CLOEXEC
When the flag CLOSE_RANGE_CLOEXEC is set, close_range doesn't
immediately close the files but it sets the close-on-exec bit.
Signed-off-by: Giuseppe Scrivano
---
fs/file.c| 56 ++--
include/uapi/linux/close_range.h | 3 ++
2 files changed, 42 insertions(+), 17 deletions(-)
diff --git a/fs/file.c b/fs/file.c
index 21c0893f2f1d..ad4ebee41e09 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -672,6 +672,17 @@ int __close_fd(struct files_struct *files, unsigned fd)
}
EXPORT_SYMBOL(__close_fd); /* for ksys_close() */
+static unsigned int __get_max_fds(struct files_struct *cur_fds)
+{
+ unsigned int max_fds;
+
+ rcu_read_lock();
+ /* cap to last valid index into fdtable */
+ max_fds = files_fdtable(cur_fds)->max_fds;
+ rcu_read_unlock();
+ return max_fds;
+}
+
/**
* __close_range() - Close all file descriptors in a given range.
*
@@ -683,27 +694,23 @@ EXPORT_SYMBOL(__close_fd); /* for ksys_close() */
*/
int __close_range(unsigned fd, unsigned max_fd, unsigned int flags)
{
- unsigned int cur_max;
+ unsigned int cur_max = UINT_MAX;
struct task_struct *me = current;
struct files_struct *cur_fds = me->files, *fds = NULL;
- if (flags & ~CLOSE_RANGE_UNSHARE)
+ if (flags & ~(CLOSE_RANGE_UNSHARE | CLOSE_RANGE_CLOEXEC))
return -EINVAL;
if (fd > max_fd)
return -EINVAL;
- rcu_read_lock();
- cur_max = files_fdtable(cur_fds)->max_fds;
- rcu_read_unlock();
-
- /* cap to last valid index into fdtable */
- cur_max--;
-
if (flags & CLOSE_RANGE_UNSHARE) {
int ret;
unsigned int max_unshare_fds = NR_OPEN_MAX;
+ /* cap to last valid index into fdtable */
+ cur_max = __get_max_fds(cur_fds) - 1;
+
/*
* If the requested range is greater than the current maximum,
* we're closing everything so only copy all file descriptors
@@ -724,16 +731,31 @@ int __close_range(unsigned fd, unsigned max_fd, unsigned
int flags)
swap(cur_fds, fds);
}
- max_fd = min(max_fd, cur_max);
- while (fd <= max_fd) {
- struct file *file;
+ if (flags & CLOSE_RANGE_CLOEXEC) {
+ struct fdtable *fdt;
- file = pick_file(cur_fds, fd++);
- if (!file)
- continue;
+ spin_lock(_fds->file_lock);
+ fdt = files_fdtable(cur_fds);
+ cur_max = fdt->max_fds - 1;
+ max_fd = min(max_fd, cur_max);
+ while (fd <= max_fd)
+ __set_close_on_exec(fd++, fdt);
+ spin_unlock(_fds->file_lock);
+ } else {
+ /* Initialize cur_max if needed. */
+ if (cur_max == UINT_MAX)
+ cur_max = __get_max_fds(cur_fds) - 1;
+ max_fd = min(max_fd, cur_max);
+ while (fd <= max_fd) {
+ struct file *file;
- filp_close(file, cur_fds);
- cond_resched();
+ file = pick_file(cur_fds, fd++);
+ if (!file)
+ continue;
+
+ filp_close(file, cur_fds);
+ cond_resched();
+ }
}
if (fds) {
diff --git a/include/uapi/linux/close_range.h b/include/uapi/linux/close_range.h
index 6928a9fdee3c..2d804281554c 100644
--- a/include/uapi/linux/close_range.h
+++ b/include/uapi/linux/close_range.h
@@ -5,5 +5,8 @@
/* Unshare the file descriptor table before closing file descriptors. */
#define CLOSE_RANGE_UNSHARE(1U << 1)
+/* Set the FD_CLOEXEC bit instead of closing the file descriptor. */
+#define CLOSE_RANGE_CLOEXEC(1U << 2)
+
#endif /* _UAPI_LINUX_CLOSE_RANGE_H */
--
2.26.2
[PATCH 0/2] fs, close_range: add flag CLOSE_RANGE_CLOEXEC
When the new flag is used, close_range will set the close-on-exec bit for the file descriptors instead of close()-ing them. It is useful for e.g. container runtimes that want to minimize the number of syscalls used after a seccomp profile is installed but want to keep some fds open until the container process is executed. Giuseppe Scrivano (2): fs, close_range: add flag CLOSE_RANGE_CLOEXEC selftests: add tests for CLOSE_RANGE_CLOEXEC fs/file.c | 56 +-- include/uapi/linux/close_range.h | 3 + .../testing/selftests/core/close_range_test.c | 44 +++ 3 files changed, 86 insertions(+), 17 deletions(-) -- 2.26.2
Re: [PATCH] firmware: arm_scmi: fix notifications locking
On Tue, Oct 13, 2020 at 02:31:09PM +0100, Cristian Marussi wrote:
> When a protocol registers its events the notification core takes care to
> re-scan the hashtable of pending event handlers and activate all the
> possibly existent handlers that refer to any of the events just registered
> by the new protocol; when a pending handler becomes active the core takes
> also care to ask the SCMI platform to enable the corresponding events'
> notifications in the SCMI firmware.
>
> If, for whatever reason, the enable fails such invalid event handler must
> be finally removed and freed but it must be treated as an active handler
> like it has just become: ensure to use the scmi_put_active_handler() helper
> which handles properly the needed additional mutexing.
>
> Failing to properly acquire all the needed mutexes exposes a race that
> leads to the following splat being observed:
>
> [ 212.840876] [ cut here ]
Please drop the timestamp next time you have to copy backtrace, it is
useless in commit log.
> [ 212.845569] refcount_t: underflow; use-after-free.
> [ 212.850544] WARNING: CPU: 0 PID: 388 at lib/refcount.c:28
> refcount_warn_saturate+0xf8/0x148
> [ 212.858913] Modules linked in: dummy_scmi_consumer(-) scmi_perf [last
> unloaded: scmi_cpufreq]
> [ 212.867478] CPU: 0 PID: 388 Comm: rmmod Tainted: GW
> 5.9.0-rc1-00020-g9c4395e7867d-dirty #4
> [ 212.877153] Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno
> Development Platform, BIOS EDK II Jun 30 2020
> [ 212.887963] pstate: 4005 (nZcv daif -PAN -UAO BTYPE=--)
> [ 212.893554] pc : refcount_warn_saturate+0xf8/0x148
> [ 212.898361] lr : refcount_warn_saturate+0xf8/0x148
> [ 212.903160] sp : 80001298bc00
> [ 212.906480] x29: 80001298bc00 x28: 00097470aac0
> [ 212.911807] x27: x26:
> [ 212.917135] x25: 00097357fc80 x24: 0002
> [ 212.922462] x23: 00097357fca8 x22: 0003
> [ 212.927790] x21: 000974474688 x20: 000971e04f00
> [ 212.933117] x19: 0001 x18: 0010
> [ 212.938444] x17: x16:
> [ 212.943771] x15: x14: 800012269948
> [ 212.949098] x13: 80009298b947 x12: 80001298b94f
> [ 212.954426] x11: 0001 x10: 0a10
> [ 212.959753] x9 : 80001039fe88 x8 : 00097470b530
> [ 212.965080] x7 : x6 : 00097ef1b200
> [ 212.970407] x5 : 00097ef1b200 x4 :
> [ 212.975734] x3 : 00097ef2a398 x2 : 0001
> [ 212.981060] x1 : 4b16c3af5d721600 x0 :
Also trim and remove all the above hex values. I will modify this time,
again they are of not much use.
> [ 212.986388] Call trace:
> [ 212.988847] refcount_warn_saturate+0xf8/0x148
> [ 212.993308] scmi_put_handler_unlocked.isra.10+0x204/0x208
> [ 212.998811] scmi_put_handler+0x50/0xa0
> [ 213.002659] scmi_unregister_notifier+0x1bc/0x240
> [ 213.007385] scmi_notify_tester_remove+0x4c/0x68 [dummy_scmi_consumer]
> [ 213.013931] scmi_dev_remove+0x54/0x68
> [ 213.017695] device_release_driver_internal+0x114/0x1e8
> [ 213.022934] driver_detach+0x58/0xe8
> [ 213.026520] bus_remove_driver+0x88/0xe0
> [ 213.030454] driver_unregister+0x38/0x68
> [ 213.034389] scmi_driver_unregister+0x1c/0x28
> [ 213.038763] scmi_drv_exit+0x1c/0xae0 [dummy_scmi_consumer]
> [ 213.044354] __arm64_sys_delete_module+0x1a4/0x268
> [ 213.049160] el0_svc_common.constprop.3+0x94/0x178
> [ 213.053963] do_el0_svc+0x2c/0x98
> [ 213.057290] el0_sync_handler+0x148/0x1a8
> [ 213.061310] el0_sync+0x158/0x180
> [ 213.064632] ---[ end trace 5bff2d25d5820911 ]---
>
> Fixes: e7c215f358a35 ("firmware: arm_scmi: Add notification
> callbacks-registration")
> Signed-off-by: Cristian Marussi
> ---
>
> Applied and tested on [1] on top of :
>
> commit: 9724722fde8f ("firmware: arm_scmi: Add missing Rx size
> re-initialisation")
>
> [1]:https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git/log/?h=for-next/scmi
> ---
> ---
> drivers/firmware/arm_scmi/notify.c | 20 +---
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/firmware/arm_scmi/notify.c
> b/drivers/firmware/arm_scmi/notify.c
> index 2754f9d01636..c24e427dce0d 100644
> --- a/drivers/firmware/arm_scmi/notify.c
> +++ b/drivers/firmware/arm_scmi/notify.c
> @@ -1403,15 +1403,21 @@ static void scmi_protocols_late_init(struct
> work_struct *work)
> "finalized PENDING handler - key:%X\n",
> hndl->key);
> ret = scmi_event_handler_enable_events(hndl);
> + if (ret) {
> + dev_dbg(ni->handle->dev,
> + "purging INVALID handler - key:%X\n",
> + hndl->key);
[PATCH 1/2] sched: Deny self-issued __set_cpus_allowed_ptr() when migrate_disable()
migrate_disable();
set_cpus_allowed_ptr(current, {something excluding task_cpu(current)});
affine_move_task(); <-- never returns
Signed-off-by: Valentin Schneider
---
kernel/sched/core.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 4ccd1099adaa..7f4e38819de1 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2189,6 +2189,11 @@ static int __set_cpus_allowed_ptr(struct task_struct *p,
if (!(flags & SCA_MIGRATE_ENABLE) && cpumask_equal(>cpus_mask,
new_mask))
goto out;
+ if (p == current &&
+ is_migration_disabled(p) &&
+ !cpumask_test_cpu(task_cpu(p), new_mask))
+ ret = -EBUSY;
+
/*
* Picking a ~random cpu helps in cases where we are changing affinity
* for groups of tasks (ie. cpuset), so that load balancing is not
--
2.27.0
[PATCH 2/2] sched: Comment affine_move_task()
Signed-off-by: Valentin Schneider
---
kernel/sched/core.c | 81 +++--
1 file changed, 79 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 7f4e38819de1..8cf74ba49d61 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2032,7 +2032,75 @@ struct set_affinity_pending {
};
/*
- * This function is wildly self concurrent, consider at least 3 times.
+ * This function is wildly self concurrent; here be dragons.
+ *
+ *
+ * When given a valid mask, __set_cpus_allowed_ptr() must block until the
+ * designated task is enqueued on an allowed CPU. If that task is currently
+ * running, we have to kick it out using the CPU stopper.
+ *
+ * Migrate-Disable comes along and tramples all over our nice sandcastle.
+ * Consider:
+ *
+ * Initial conditions: P0->cpus_mask = [0, 1]
+ *
+ * P0@CPU0 P1
+ *
+ * migrate_disable();
+ *
+ * set_cpus_allowed_ptr(P0, [1]);
+ *
+ * P1 *cannot* return from this set_cpus_allowed_ptr() call until P0 executes
+ * its outermost migrate_enable() (i.e. it exits its Migrate-Disable region).
+ * This means we need the following scheme:
+ *
+ * P0@CPU0 P1
+ *
+ * migrate_disable();
+ *
+ * set_cpus_allowed_ptr(P0, [1]);
+ *
+ *
+ * migrate_enable();
+ * __set_cpus_allowed_ptr();
+ *
+ * `-->
+ *
+ * Now the fun stuff: there may be several P1-like tasks, i.e. multiple
+ * concurrent set_cpus_allowed_ptr(P0, [*]) calls. CPU affinity changes of any
+ * task p are serialized by p->pi_lock, which we can leverage: the one that
+ * should come into effect at the end of the Migrate-Disable region is the last
+ * one. This means we only need to track a single cpumask (i.e. p->cpus_mask),
+ * but we still need to properly signal those waiting tasks at the appropriate
+ * moment.
+ *
+ * This is implemented using struct set_affinity_pending. The first
+ * __set_cpus_allowed_ptr() caller within a given Migrate-Disable region will
+ * setup an instance of that struct and install it on the targeted task_struct.
+ * Any and all further callers will reuse that instance. Those then wait for
+ * a completion signaled at the tail of the CPU stopper callback (1), triggered
+ * on the end of the Migrate-Disable region (i.e. outermost migrate_enable()).
+ *
+ *
+ * (1) In the cases covered above. There is one more where the completion is
+ * signaled within affine_move_task() itself: when a subsequent affinity
request
+ * cancels the need for an active migration. Consider:
+ *
+ * Initial conditions: P0->cpus_mask = [0, 1]
+ *
+ * P0@CPU0P1 P2
+ *
+ * migrate_disable();
+ *
+ *set_cpus_allowed_ptr(P0, [1]);
+ *
+ *
set_cpus_allowed_ptr(P0, [0, 1]);
+ *
+ *
+ *
+ * Note that the above is safe vs a concurrent migrate_enable(), as any
+ * pending affinity completion is preceded an uninstallion of
+ * p->migration_pending done with p->pi_lock held.
*/
static int affine_move_task(struct rq *rq, struct rq_flags *rf,
struct task_struct *p, int dest_cpu, unsigned int
flags)
@@ -2075,6 +2143,7 @@ static int affine_move_task(struct rq *rq, struct
rq_flags *rf,
if (!(flags & SCA_MIGRATE_ENABLE)) {
/* serialized by p->pi_lock */
if (!p->migration_pending) {
+ /* Install the request */
refcount_set(_pending.refs, 1);
init_completion(_pending.done);
p->migration_pending = _pending;
@@ -2113,7 +2182,11 @@ static int affine_move_task(struct rq *rq, struct
rq_flags *rf,
}
if (task_running(rq, p) || p->state == TASK_WAKING) {
-
+ /*
+* Lessen races (and headaches) by delegating
+* is_migration_disabled(p) checks to the stopper, which will
+* run on the same CPU as said p.
+*/
task_rq_unlock(rq, p, rf);
stop_one_cpu(cpu_of(rq), migration_cpu_stop, );
@@ -2138,6 +2211,10 @@ static int affine_move_task(struct rq *rq, struct
rq_flags *rf,
if (refcount_dec_and_test(>refs))
wake_up_var(>refs);
+ /*
+* Block the original owner of until all subsequent callers
+* have seen the completion and decremented the refcount
+*/
wait_var_event(_pending.refs, !refcount_read(_pending.refs));
return 0;
--
2.27.0
Re: [PATCH 01/18] dt-bindings: usb: usb-hcd: Convert generic USB properties to DT schema
On Tue, Oct 13, 2020 at 07:14:41AM -0500, Rob Herring wrote:
> On Sun, Oct 11, 2020 at 01:41:04AM +0300, Serge Semin wrote:
> > The generic USB HCD properties have been described in the legacy bindings
> > text file: Documentation/devicetree/bindings/usb/generic.txt . Let's
> > convert it' content into the USB HCD DT schema properties so all USB DT
> > nodes would be validated to have them properly utilized.
> >
> > Signed-off-by: Serge Semin
> > ---
> > .../devicetree/bindings/usb/generic.txt | 57 -
> > .../devicetree/bindings/usb/usb-hcd.yaml | 84 +++
> > 2 files changed, 84 insertions(+), 57 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/usb/generic.txt
> >
> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt
> > b/Documentation/devicetree/bindings/usb/generic.txt
> > deleted file mode 100644
> > index ba472e7aefc9..
> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > +++ /dev/null
> > @@ -1,57 +0,0 @@
> > -Generic USB Properties
> > -
> > -Optional properties:
> > - - maximum-speed: tells USB controllers we want to work up to a certain
> > - speed. Valid arguments are "super-speed-plus",
> > - "super-speed", "high-speed", "full-speed" and
> > - "low-speed". In case this isn't passed via DT, USB
> > - controllers should default to their maximum HW
> > - capability.
> > - - dr_mode: tells Dual-Role USB controllers that we want to work on a
> > - particular mode. Valid arguments are "host",
> > - "peripheral" and "otg". In case this attribute isn't
> > - passed via DT, USB DRD controllers should default to
> > - OTG.
> > - - phy_type: tells USB controllers that we want to configure the core to
> > support
> > - a UTMI+ PHY with an 8- or 16-bit interface if UTMI+ is
> > - selected. Valid arguments are "utmi" and "utmi_wide".
> > - In case this isn't passed via DT, USB controllers should
> > - default to HW capability.
> > - - otg-rev: tells usb driver the release number of the OTG and EH
> > supplement
> > - with which the device and its descriptors are compliant,
> > - in binary-coded decimal (i.e. 2.0 is 0200H). This
> > - property is used if any real OTG features(HNP/SRP/ADP)
> > - is enabled, if ADP is required, otg-rev should be
> > - 0x0200 or above.
> > - - companion: phandle of a companion
> > - - hnp-disable: tells OTG controllers we want to disable OTG HNP, normally
> > HNP
> > - is the basic function of real OTG except you want it
> > - to be a srp-capable only B device.
> > - - srp-disable: tells OTG controllers we want to disable OTG SRP, SRP is
> > - optional for OTG device.
> > - - adp-disable: tells OTG controllers we want to disable OTG ADP, ADP is
> > - optional for OTG device.
> > - - usb-role-switch: boolean, indicates that the device is capable of
> > assigning
> > - the USB data role (USB host or USB device) for a given
> > - USB connector, such as Type-C, Type-B(micro).
> > - see connector/usb-connector.yaml.
> > - - role-switch-default-mode: indicating if usb-role-switch is enabled, the
> > - device default operation mode of controller while usb
> > - role is USB_ROLE_NONE. Valid arguments are "host" and
> > - "peripheral". Defaults to "peripheral" if not
> > - specified.
> > -
> > -
> > -This is an attribute to a USB controller such as:
> > -
> > -dwc3@4a03 {
> > - compatible = "synopsys,dwc3";
> > - reg = <0x4a03 0xcfff>;
> > - interrupts = <0 92 4>
> > - usb-phy = <_phy>, <,phy>;
> > - maximum-speed = "super-speed";
> > - dr_mode = "otg";
> > - phy_type = "utmi_wide";
> > - otg-rev = <0x0200>;
> > - adp-disable;
> > -};
> > diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> > b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> > index 7263b7f2b510..815de24127db 100644
> > --- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> > +++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> > @@ -22,9 +22,93 @@ properties:
> > description:
> >Name specifier for the USB PHY
> >
> > + maximum-speed:
> > + description: |
>
> Drop the '|' if there's no formatting to preserve.
Thanks for noticing this. I should have refreshed my YAML multi-line
knowledge https://yaml-multiline.info/ .) I'll fix it in all the patches of
the series.
>
> > + Tells USB controllers we want to work up to a certain speed. In case
> > this
> > + isn't passed via DT, USB controllers should default to their
[PATCH 3/3] interconnect: qcom: sc7180: Init BCMs before creating the nodes
Currently if we use sync_state, by default the bandwidth is maxed out,
but in order to set this in hardware, the BCMs (Bus Clock Managers) need
to be initialized first. Move the BCM initialization before creating the
nodes to fix this.
Fixes: 7d3b0b0d8184 ("interconnect: qcom: Use icc_sync_state")
Signed-off-by: Georgi Djakov
---
drivers/interconnect/qcom/sc7180.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/interconnect/qcom/sc7180.c
b/drivers/interconnect/qcom/sc7180.c
index bf11b82ed55c..8d9044ed18ab 100644
--- a/drivers/interconnect/qcom/sc7180.c
+++ b/drivers/interconnect/qcom/sc7180.c
@@ -553,6 +553,9 @@ static int qnoc_probe(struct platform_device *pdev)
return ret;
}
+ for (i = 0; i < qp->num_bcms; i++)
+ qcom_icc_bcm_init(qp->bcms[i], >dev);
+
for (i = 0; i < num_nodes; i++) {
size_t j;
@@ -576,9 +579,6 @@ static int qnoc_probe(struct platform_device *pdev)
}
data->num_nodes = num_nodes;
- for (i = 0; i < qp->num_bcms; i++)
- qcom_icc_bcm_init(qp->bcms[i], >dev);
-
platform_set_drvdata(pdev, qp);
return 0;
[PATCH 1/3] interconnect: Aggregate before setting initial bandwidth
When setting the initial bandwidth, make sure to call the aggregate()
function (if such is implemented for the current provider), to handle
cases when data needs to be aggregated first.
Fixes: b1d681d8d324 ("interconnect: Add sync state support")
Signed-off-by: Georgi Djakov
---
drivers/interconnect/core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
index eea47b4c84aa..974a66725d09 100644
--- a/drivers/interconnect/core.c
+++ b/drivers/interconnect/core.c
@@ -971,6 +971,9 @@ void icc_node_add(struct icc_node *node, struct
icc_provider *provider)
}
node->avg_bw = node->init_avg;
node->peak_bw = node->init_peak;
+ if (provider->aggregate)
+ provider->aggregate(node, 0, node->init_avg, node->init_peak,
+ >avg_bw, >peak_bw);
provider->set(node, node);
node->avg_bw = 0;
node->peak_bw = 0;
[PATCH 2/3] interconnect: qcom: sdm845: Init BCMs before creating the nodes
Currently if we use sync_state, by default the bandwidth is maxed out,
but in order to set this in hardware, the BCMs (Bus Clock Managers) need
to be initialized first. Move the BCM initialization before creating the
nodes to fix this.
Fixes: 7d3b0b0d8184 ("interconnect: qcom: Use icc_sync_state")
Signed-off-by: Georgi Djakov
---
drivers/interconnect/qcom/sdm845.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/interconnect/qcom/sdm845.c
b/drivers/interconnect/qcom/sdm845.c
index d79e3163e2c3..47556dc12ec0 100644
--- a/drivers/interconnect/qcom/sdm845.c
+++ b/drivers/interconnect/qcom/sdm845.c
@@ -489,6 +489,9 @@ static int qnoc_probe(struct platform_device *pdev)
return ret;
}
+ for (i = 0; i < qp->num_bcms; i++)
+ qcom_icc_bcm_init(qp->bcms[i], >dev);
+
for (i = 0; i < num_nodes; i++) {
size_t j;
@@ -512,9 +515,6 @@ static int qnoc_probe(struct platform_device *pdev)
}
data->num_nodes = num_nodes;
- for (i = 0; i < qp->num_bcms; i++)
- qcom_icc_bcm_init(qp->bcms[i], >dev);
-
platform_set_drvdata(pdev, qp);
return 0;
Re: [PATCH v4] kcov, usb: specify contexts for remote coverage sections
On Tue, Oct 13, 2020 at 8:46 AM Dmitry Vyukov wrote: > > On Mon, Oct 12, 2020 at 7:17 PM Andrey Konovalov > wrote: > > > > Currently there's a KCOV remote coverage collection section in > > __usb_hcd_giveback_urb(). Initially that section was added based on the > > assumption that usb_hcd_giveback_urb() can only be called in interrupt > > context as indicated by a comment before it. This is what happens when > > syzkaller is fuzzing the USB stack via the dummy_hcd driver. > > > > As it turns out, it's actually valid to call usb_hcd_giveback_urb() in task > > context, provided that the caller turned off the interrupts; USB/IP does > > exactly that. This can lead to a nested KCOV remote coverage collection > > sections both trying to collect coverage in task context. This isn't > > supported by KCOV, and leads to a WARNING. > > How does this recursion happen? There is literal recursion in the task > context? A function starts a remote coverage section and calls another > function that also starts a remote coverage section? Yes, a literal recursion. Background thread for processing requests for USB/IP hub (which we collect coverage from) calls __usb_hcd_giveback_urb(). Here's the stack trace: kcov_remote_start_usb include/linux/kcov.h:52 [inline] __usb_hcd_giveback_urb+0x284/0x4b0 drivers/usb/core/hcd.c:1649 usb_hcd_giveback_urb+0x367/0x410 drivers/usb/core/hcd.c:1716 vhci_urb_enqueue.cold+0x37f/0x4c5 drivers/usb/usbip/vhci_hcd.c:801 usb_hcd_submit_urb+0x2b1/0x20d0 drivers/usb/core/hcd.c:1547 usb_submit_urb+0x6e5/0x13b0 drivers/usb/core/urb.c:570 usb_start_wait_urb+0x10f/0x2c0 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x31c/0x4a0 drivers/usb/core/message.c:153 hub_set_address drivers/usb/core/hub.c:4472 [inline] hub_port_init+0x23f6/0x2d20 drivers/usb/core/hub.c:4748 hub_port_connect drivers/usb/core/hub.c:5140 [inline] hub_port_connect_change drivers/usb/core/hub.c:5348 [inline] port_event drivers/usb/core/hub.c:5494 [inline] hub_event+0x1cc9/0x38d0 drivers/usb/core/hub.c:5576 process_one_work+0x7b6/0x1190 kernel/workqueue.c:2269 worker_thread+0x94/0xdc0 kernel/workqueue.c:2415 kthread+0x372/0x450 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 > Or is there recursion between task context and softirq context? No. This kind of recursion is actually supported by kcov right now. A softirq with a coverage collection section can come in the middle of a coverage collection section for a task. > But > this should not happen if softirq's disabled around > usb_hcd_giveback_urb call in task context... [...] > We do want to collect coverage from usb_hcd_giveback_urb in the task > context eventually, right? Ideally, eventually, yes. > Is this API supposed to be final? Or it only puts down fire re the warning? Only puts down the fire. > I don't understand how this API can be used in other contexts. > Let's say there is recursion in task context and we want to collect > coverage in task context (the function is only called in task > context). This API won't help. No, it won't. Full recursion support is required for this. > Let's say a function is called from both task and softirq context and > these can recurse (softirq arrive while in remote task section). This > API won't help. It will force to choose either task or softirq, but > let's say you can't make that choice because they are equally > important. This currently works, everything that happens in a softirq gets associated with softirq, everything else - with the task. This seems to be the only logical approach here, it makes no sense to associate what happens in a softirq with the task where the softirq happened. > The API helps to work around the unimplemented recursion in KCOV, but > it's also specific to this particular case. It's not necessary that > recursion is specific to one context only and it's not necessary that > a user can choose to sacrifice one of the contexts. > Also, if we support recursion in one way or another, we will never > want to use this API, right? Correct.
Re: [PATCH v4 2/2] ovl: introduce new "uuid=off" option for inodes index feature
On 10/6/20 6:13 PM, Miklos Szeredi wrote: On Fri, Sep 25, 2020 at 10:35 AM Pavel Tikhomirov wrote: Note: In our (Virtuozzo) use case users inside a container can create "regular" overlayfs mounts without any "index=" option, but we still want to migrate this containers with CRIU so we set "index=on" as kernel default so that all the container overlayfs mounts get support of file handles automatically. With "uuid=off" we want the same thing (to be able to "copy" container with uuid change) - we would set kernel default so that all the container overlayfs mounts get "uuid=off" automatically. I'm not sure I buy that argument for a kernel option. It should rather be a "container" option in that case, but AFAIK the kernel doesn't have a concept of a container. I think this needs to be discussed on the relevant mailing lists. As of now mainline kernel doesn't support unprivileged overlay mounts, so I guess this is not an issue. Let's just merge this without the kernel and the module options. Virtuozzo kernel does have a "container" concept and we do have unprivileged overlay mounts to support docker inside Virtuozzo containers. We don't face any major issues with it. But you are right it's not mainstream. Probably a normal user of mainstream kernel also might want to set index=on+uuid=off by default, so that all their docker containters automatically support inotifies and survive backing disk uuid change automaticaly. I will prepare next patchset version without default. Thanks, Miklos -- Best regards, Tikhomirov Pavel Software Developer, Virtuozzo.
Re: [PATCH v2 2/2] [RFC] CPUFreq: Add support for cpu-perf-dependencies
Hi Viresh, On 10/9/20 6:39 AM, Viresh Kumar wrote: Oh yes, I get it now. Finally. Thanks for helping me out :) So if I can say all this stuff in simple terms, this is what it will be like: - We don't want software aggregation of frequencies and so we need to have per-cpu policies even when they share their clock lines. - But we still need a way for other frameworks to know which CPUs share the clock lines (that's what the perf-dependency is all about, right ?). - We can't get it from SCMI, but need a DT based solution. - Currently for the cpufreq-case we relied for this on the way OPP tables for the CPUs were described. i.e. the opp-table is marked as "shared" and multiple CPUs point to it. I've started wondering based on the OPP code if this is a good solution. We would end up with one (?) instance of opp_table and list of devices pinned to it, in: opp_table->dev_list It can be seen e.g. in function dev_pm_opp_get_sharing_cpus(), where we retrieve the cpumask simply looping through the devices: list_for_each_entry(opp_dev, _table->dev_list, node) cpumask_set_cpu(opp_dev->dev->id, cpumask); This means we have a single OPP table for all pinned CPUs. I wonder if this is not too strong assumption for still being compliant with SCMI spec, when in theory performance levels might differ... (please correct me here it that would never happen) There is also 2nd function dev_pm_opp_of_get_sharing_cpus() which looks more promising. But I still don't know if the framework will allow us to have private OPP tables when we use 'shared' in DT. Could you clarify if we would get 'private' opp table for each CPU, which could be then populated independently, but still 2nd function will work? Regards, Lukasz
Re: [2/2] drm/msm: Add support for GPU cooling
On 10/12/2020 11:10 PM, m...@chromium.org wrote:
On Mon, Oct 12, 2020 at 07:03:51PM +0530, Akhil P Oommen wrote:
On 10/10/2020 12:06 AM, m...@chromium.org wrote:
Hi Akhil,
On Thu, Oct 08, 2020 at 10:39:07PM +0530, Akhil P Oommen wrote:
Register GPU as a devfreq cooling device so that it can be passively
cooled by the thermal framework.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/msm_gpu.c | 13 -
drivers/gpu/drm/msm/msm_gpu.h | 2 ++
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 55d1648..93ffd66 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -107,9 +108,18 @@ static void msm_devfreq_init(struct msm_gpu *gpu)
if (IS_ERR(gpu->devfreq.devfreq)) {
DRM_DEV_ERROR(>pdev->dev, "Couldn't initialize GPU
devfreq\n");
gpu->devfreq.devfreq = NULL;
+ return;
}
devfreq_suspend_device(gpu->devfreq.devfreq);
+
+ gpu->cooling = of_devfreq_cooling_register(gpu->pdev->dev.of_node,
+ gpu->devfreq.devfreq);
+ if (IS_ERR(gpu->cooling)) {
+ DRM_DEV_ERROR(>pdev->dev,
+ "Couldn't register GPU cooling device\n");
+ gpu->cooling = NULL;
+ }
}
static int enable_pwrrail(struct msm_gpu *gpu)
@@ -926,7 +936,6 @@ int msm_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
msm_devfreq_init(gpu);
-
Will remove this unintended change.
gpu->aspace = gpu->funcs->create_address_space(gpu, pdev);
if (gpu->aspace == NULL)
@@ -1005,4 +1014,6 @@ void msm_gpu_cleanup(struct msm_gpu *gpu)
gpu->aspace->mmu->funcs->detach(gpu->aspace->mmu);
msm_gem_address_space_put(gpu->aspace);
}
+
+ devfreq_cooling_unregister(gpu->cooling);
Resources should be released in reverse order, otherwise the cooling device
could use resources that have already been freed.
Why do you think this is not the correct order? If you are thinking
about devfreq struct, it is managed device resource.
I did not check specifically if changing the frequency really uses any of the
resources that are released previously, In any case it's not a good idea to
allow other parts of the kernel to use a half initialized/torn down device.
Even if it isn't a problem today someone could change the driver to use any
of these resources (or add a new one) in a frequency change, without even
thinking about the cooling device, just (rightfully) asuming that things are
set up and torn down in a sane order.
'sane order' relative to what specifically here? Should we worry about
freq change at this point because we have already disabled gpu runtime
pm and devfreq?
-Akhil.
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
-Akhil.
Re: [PATCH] v4l: Add source change event for colorimetry
On 10/13/20 4:40 PM, Tomasz Figa wrote:
> On Tue, Oct 13, 2020 at 11:03 AM Stanimir Varbanov
> wrote:
>>
>> Hi,
>>
>> On 7/2/20 2:52 PM, Stanimir Varbanov wrote:
>>> Hi,
>>>
>>> Once we have this event there is still open question how the client will
>>> know the data buffer on which the new colorspace is valid/applied.
>>>
>>> The options could be:
>>> * a new buffer flag and
>>> * some information in the v4l2_event structure.
>>>
>>> Thoughts?
>>
>> Kindly ping.
>>
>
> The event itself sounds good to me, but how do we know which buffer is
> the first to have the new colorimetry?
I think Hans have a very good idea to have width/height and colorspace
specifiers in v4l2_ext_buffer [1].
[1] https://lkml.org/lkml/2020/9/9/531
>
> Best regards,
> Tomasz
>
>>>
>>> On 7/2/20 1:00 PM, Stanimir Varbanov wrote:
This event indicate that the source colorspace is changed
during run-time. The client has to retrieve the new colorspace
identifiers by getting the format (G_FMT).
Signed-off-by: Stanimir Varbanov
---
.../userspace-api/media/v4l/vidioc-dqevent.rst| 11 ++-
.../userspace-api/media/videodev2.h.rst.exceptions| 1 +
include/uapi/linux/videodev2.h| 1 +
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst
b/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst
index a9a176d5256d..3f69c753db58 100644
--- a/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst
+++ b/Documentation/userspace-api/media/v4l/vidioc-dqevent.rst
@@ -381,7 +381,16 @@ call.
that many Video Capture devices are not able to recover from a
temporary
loss of signal and so restarting streaming I/O is required in order
for
the hardware to synchronize to the video signal.
-
+* - ``V4L2_EVENT_SRC_CH_COLORIMETRY``
+ - 0x0002
+ - This event gets triggered when a colorspace change is detected at
+an input. By colorspace change here we include also changes in the
+colorspace specifiers (transfer function, Y'CbCr encoding and
+quantization). This event can come from an input or from video
decoder.
+Once the event has been send to the client the driver has to update
+the colorspace specifiers internally so that they could be retrieved
by
+client. In that case queue re-negotiation is not needed as this change
+only reflects on the interpretation of the data.
Return Value
diff --git a/Documentation/userspace-api/media/videodev2.h.rst.exceptions
b/Documentation/userspace-api/media/videodev2.h.rst.exceptions
index ca05e4e126b2..54fc21af852d 100644
--- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions
+++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions
@@ -492,6 +492,7 @@ replace define V4L2_EVENT_CTRL_CH_FLAGS
ctrl-changes-flags
replace define V4L2_EVENT_CTRL_CH_RANGE ctrl-changes-flags
replace define V4L2_EVENT_SRC_CH_RESOLUTION src-changes-flags
+replace define V4L2_EVENT_SRC_CH_COLORIMETRY src-changes-flags
replace define V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ
:c:type:`v4l2_event_motion_det`
diff --git a/include/uapi/linux/videodev2.h
b/include/uapi/linux/videodev2.h
index 303805438814..b5838bc4e3a3 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -2351,6 +2351,7 @@ struct v4l2_event_frame_sync {
};
#define V4L2_EVENT_SRC_CH_RESOLUTION(1 << 0)
+#define V4L2_EVENT_SRC_CH_COLORIMETRY (1 << 1)
struct v4l2_event_src_change {
__u32 changes;
>>>
>>
>> --
>> regards,
>> Stan
--
regards,
Stan
Re: [PATCH v9 03/15] dt-bindings: usb: Maxim type-c controller device tree binding document
On Tue, Oct 13, 2020 at 8:43 AM Rob Herring wrote: > > On Wed, Oct 7, 2020 at 7:43 PM Badhri Jagan Sridharan > wrote: > > > > Hi Robb, > > > > Thanks for the reviews ! Responses inline. > > > > Regards, > > Badhri > > > > On Mon, Oct 5, 2020 at 7:46 AM Rob Herring wrote: > > > > > > On Mon, Sep 28, 2020 at 07:39:52PM -0700, Badhri Jagan Sridharan wrote: > > > > Add device tree binding document for Maxim TCPCI based Type-C chip > > > > driver > > > > > > > > Signed-off-by: Badhri Jagan Sridharan > > > > --- > > > > Changes since v1: > > > > - Changing patch version to v6 to fix version number confusion. > > > > > > > > Changes since v6: > > > > - Migrated to yaml format. > > > > > > > > Changes since v7: > > > > - Rebase on usb-next > > > > > > > > Changes since v8: > > > > - Fix errors from make dt_binding_check as suggested by > > > > Rob Herring. > > > > --- > > > > .../devicetree/bindings/usb/maxim,tcpci.yaml | 68 +++ > > > > 1 file changed, 68 insertions(+) > > > > create mode 100644 > > > > Documentation/devicetree/bindings/usb/maxim,tcpci.yaml > > > > > > > > diff --git a/Documentation/devicetree/bindings/usb/maxim,tcpci.yaml > > > > b/Documentation/devicetree/bindings/usb/maxim,tcpci.yaml > > > > new file mode 100644 > > > > index ..f4b5f1a09b98 > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/usb/maxim,tcpci.yaml > > > > @@ -0,0 +1,68 @@ > > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > > +%YAML 1.2 > > > > +--- > > > > +$id: "http://devicetree.org/schemas/usb/maxim,tcpci.yaml#; > > > > +$schema: "http://devicetree.org/meta-schemas/core.yaml#; > > > > + > > > > +title: Maxim TCPCI Type-C PD controller DT bindings > > > > + > > > > +maintainers: > > > > + - Badhri Jagan Sridharan > > > > + > > > > +description: Maxim TCPCI Type-C PD controller > > > > + > > > > +properties: > > > > + compatible: > > > > +enum: > > > > + - maxim,tcpci > > > > > > Is there a datasheet for this? Searching for 'tcpci' doesn't really come > > > up with anything other than this patch. Only chip I found is MAX77958. > > > Bindings are for specific h/w devices. > > > > Unfortunately the datasheet cannot be made public yet. Has the datasheet > > have to be made public before sending the bindings ? > > No, but we need a part number or some assurance that 'tcpci' is a specific > part. I guess TCPCI is USB Type-C Port Controller Interface Specification. That's just a protocol definition, not a chip. DT describes h/w which is more than just the protocol. Rob
[PATCH] Asoc: qcom: lpass-cpu: Fix dp audio failure on monitors
From: V Sujith Kumar Reddy
Make LPASS_HDMI_TX_PARITY_ADDR reg as volatile to fix
dp audio failure with external monitors.
This patch is upgrade to below patch series.
https://lore.kernel.org/patchwork/project/lkml/list/?series=466460
Signed-off-by: V Sujith Kumar Reddy
Signed-off-by: Srinivasa Rao Mandadapu
---
sound/soc/qcom/lpass-cpu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index ba2aca3..78de888 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -660,6 +660,8 @@ static bool lpass_hdmi_regmap_volatile(struct device *dev,
unsigned int reg)
return true;
if (reg == LPASS_HDMI_TX_LEGACY_ADDR(v))
return true;
+ if (reg == LPASS_HDMI_TX_PARITY_ADDR(v))
+ return true;
for (i = 0; i < v->rdma_channels; ++i) {
if (reg == LPAIF_HDMI_RDMACURR_REG(v, i))
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH v9 03/15] dt-bindings: usb: Maxim type-c controller device tree binding document
On Wed, Oct 7, 2020 at 7:43 PM Badhri Jagan Sridharan wrote: > > Hi Robb, > > Thanks for the reviews ! Responses inline. > > Regards, > Badhri > > On Mon, Oct 5, 2020 at 7:46 AM Rob Herring wrote: > > > > On Mon, Sep 28, 2020 at 07:39:52PM -0700, Badhri Jagan Sridharan wrote: > > > Add device tree binding document for Maxim TCPCI based Type-C chip driver > > > > > > Signed-off-by: Badhri Jagan Sridharan > > > --- > > > Changes since v1: > > > - Changing patch version to v6 to fix version number confusion. > > > > > > Changes since v6: > > > - Migrated to yaml format. > > > > > > Changes since v7: > > > - Rebase on usb-next > > > > > > Changes since v8: > > > - Fix errors from make dt_binding_check as suggested by > > > Rob Herring. > > > --- > > > .../devicetree/bindings/usb/maxim,tcpci.yaml | 68 +++ > > > 1 file changed, 68 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/usb/maxim,tcpci.yaml > > > > > > diff --git a/Documentation/devicetree/bindings/usb/maxim,tcpci.yaml > > > b/Documentation/devicetree/bindings/usb/maxim,tcpci.yaml > > > new file mode 100644 > > > index ..f4b5f1a09b98 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/usb/maxim,tcpci.yaml > > > @@ -0,0 +1,68 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: "http://devicetree.org/schemas/usb/maxim,tcpci.yaml#; > > > +$schema: "http://devicetree.org/meta-schemas/core.yaml#; > > > + > > > +title: Maxim TCPCI Type-C PD controller DT bindings > > > + > > > +maintainers: > > > + - Badhri Jagan Sridharan > > > + > > > +description: Maxim TCPCI Type-C PD controller > > > + > > > +properties: > > > + compatible: > > > +enum: > > > + - maxim,tcpci > > > > Is there a datasheet for this? Searching for 'tcpci' doesn't really come > > up with anything other than this patch. Only chip I found is MAX77958. > > Bindings are for specific h/w devices. > > Unfortunately the datasheet cannot be made public yet. Has the datasheet > have to be made public before sending the bindings ? No, but we need a part number or some assurance that 'tcpci' is a specific part. Rob
Re: [PATCH 2/3] drm/msm: add DRM_MSM_GEM_SYNC_CACHE for non-coherent cache maintenance
On 2020-10-07 07:25, Christoph Hellwig wrote: On Tue, Oct 06, 2020 at 09:19:32AM -0400, Jonathan Marek wrote: One example why drm/msm can't use DMA API is multiple page table support (that is landing in 5.10), which is something that definitely couldn't work with DMA API. Another one is being able to choose the address for mappings, which AFAIK DMA API can't do (somewhat related to this: qcom hardware often has ranges of allowed addresses, which the dma_mask mechanism fails to represent, what I see is drivers using dma_mask as a "maximum address", and since addresses are allocated from the top it generally works) That sounds like a good enough rason to use the IOMMU API. I just wanted to make sure this really makes sense. I still think this situation would be best handled with a variant of dma_ops_bypass that also guarantees to bypass SWIOTLB, and can be set automatically when attaching to an unmanaged IOMMU domain. That way the device driver can make DMA API calls in the appropriate places that do the right thing either way, and only needs logic to decide whether to use the returned DMA addresses directly or ignore them if it knows they're overridden by its own IOMMU mapping. Robin.
Re: [PATCH v7 4/4] MAINTAINERS: Add entry for TEE based Trusted Keys
On Tue, Oct 13, 2020 at 04:58:47PM +0530, Sumit Garg wrote: > On Tue, 13 Oct 2020 at 07:52, Jarkko Sakkinen > wrote: > > > > On Wed, Oct 07, 2020 at 03:37:48PM +0530, Sumit Garg wrote: > > > Add MAINTAINERS entry for TEE based Trusted Keys framework. > > > > > > Signed-off-by: Sumit Garg > > > Acked-by: Jarkko Sakkinen > > > --- > > > MAINTAINERS | 8 > > > 1 file changed, 8 insertions(+) > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index 48aff80..eb3d889 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -9663,6 +9663,14 @@ F: include/keys/trusted-type.h > > > F: include/keys/trusted_tpm.h > > > F: security/keys/trusted-keys/ > > > > > > +KEYS-TRUSTED-TEE > > > +M: Sumit Garg > > > +L: linux-integr...@vger.kernel.org > > > +L: keyri...@vger.kernel.org > > > +S: Supported > > > +F: include/keys/trusted_tee.h > > > +F: security/keys/trusted-keys/trusted_tee.c > > > + > > > KEYS/KEYRINGS > > > M: David Howells > > > M: Jarkko Sakkinen > > > -- > > > 2.7.4 > > > > I'm sorry but I think I have changed my mind on this. This has been > > spinning for a while and sometimes conclusions change over the time. > > > > I don't think that we really need a separate subsystem tag. > > I don't see it as a separate subsystem but rather a kind of underlying > trust source (TEE) driver plugged into existing trusted keys > subsystem. We could relate it to the RNG subsystem as well where there > is a subsystem maintainer and specific driver maintainers. > > IMO, having a dedicated entry like this brings clarity in maintenance > and in future we may have more trust sources like this added where > everyone may not have access to all the trust sources to test. More entries pointing to the exact same stuff does not necessarily mean clarity in my books. > > I'd be for a > > new M-entry or R-entry to the existing subsystem tag. It's essential to > > have ack from someone with ARM and TEE knowledge but this way too heavy > > for the purpose. > > If you still think otherwise then I am fine with a new M-entry for > existing trusted keys subsystem as well. Adding a M-entry does makes sense because trusted keys backends can be based on various technologies and standard. It's a different in that sense than lets say a TPM hardware driver. > > I also see it the most manageable if the trusted keys PR's come from a > > single source. > > I echo here with you to have a single source for trusted keys PR's > irrespective of whether we go with a separate trust source entry or > update existing subsystem entry. > > -Sumit And I echo that oviously if there is someone to say the final ack about TEE, I will require that as the minimum to ever pick any of those changes :-) I would resolve this with just the M-entry, and we can *later on* restructure, if there is a need for that. These things are not sealed to stone. /Jarkko
