Re: [PATCH v2] lib/string.c: implement stpcpy
On Sat, 2020-08-15 at 14:28 -0700, Nick Desaulniers wrote:
> On Sat, Aug 15, 2020 at 2:24 PM Joe Perches wrote:
> > On Sat, 2020-08-15 at 13:47 -0700, Nick Desaulniers wrote:
> > > On Sat, Aug 15, 2020 at 9:34 AM Kees Cook wrote:
> > > > On Fri, Aug 14, 2020 at 07:09:44PM -0700, Nick Desaulniers wrote:
> > > > > LLVM implemented a recent "libcall optimization" that lowers calls to
> > > > > `sprintf(dest, "%s", str)` where the return value is used to
> > > > > `stpcpy(dest, str) - dest`. This generally avoids the machinery
> > > > > involved
> > > > > in parsing format strings. Calling `sprintf` with overlapping
> > > > > arguments
> > > > > was clarified in ISO C99 and POSIX.1-2001 to be undefined behavior.
> > > > >
> > > > > `stpcpy` is just like `strcpy` except it returns the pointer to the
> > > > > new
> > > > > tail of `dest`. This allows you to chain multiple calls to `stpcpy` in
> > > > > one statement.
> > > >
> > > > O_O What?
> > > >
> > > > No; this is a _terrible_ API: there is no bounds checking, there are no
> > > > buffer sizes. Anything using the example sprintf() pattern is _already_
> > > > wrong and must be removed from the kernel. (Yes, I realize that the
> > > > kernel is *filled* with this bad assumption that "I'll never write more
> > > > than PAGE_SIZE bytes to this buffer", but that's both theoretically
> > > > wrong ("640k is enough for anybody") and has been known to be wrong in
> > > > practice too (e.g. when suddenly your writing routine is reachable by
> > > > splice(2) and you may not have a PAGE_SIZE buffer).
> > > >
> > > > But we cannot _add_ another dangerous string API. We're already in a
> > > > terrible mess trying to remove strcpy[1], strlcpy[2], and strncpy[3].
> > > > This
> > > > needs to be addressed up by removing the unbounded sprintf() uses. (And
> > > > to do so without introducing bugs related to using snprintf() when
> > > > scnprintf() is expected[4].)
> > >
> > > Well, everything (-next, mainline, stable) is broken right now (with
> > > ToT Clang) without providing this symbol. I'm not going to go clean
> > > the entire kernel's use of sprintf to get our CI back to being green.
> >
> > Maybe this should get place in compiler-clang.h so it isn't
> > generic and public.
>
> https://bugs.llvm.org/show_bug.cgi?id=47162#c7 and
> https://bugs.llvm.org/show_bug.cgi?id=47144
> Seem to imply that Clang is not the only compiler that can lower a
> sequence of libcalls to stpcpy. Do we want to wait until we have a
> fire drill w/ GCC to move such an implementation from
> include/linux/compiler-clang.h back in to lib/string.c?
My guess is yes, wait until gcc, if ever, needs it.
Re: [PATCH v6 09/15] iommu/vt-d: Check ownership for PASIDs from user-space
Hi Yi,
On 7/28/20 8:27 AM, Liu Yi L wrote:
> When an IOMMU domain with nesting attribute is used for guest SVA, a
> system-wide PASID is allocated for binding with the device and the domain.
> For security reason, we need to check the PASID passed from user-space.
> e.g. page table bind/unbind and PASID related cache invalidation.
>
> Cc: Kevin Tian
> CC: Jacob Pan
> Cc: Alex Williamson
> Cc: Eric Auger
> Cc: Jean-Philippe Brucker
> Cc: Joerg Roedel
> Cc: Lu Baolu
> Signed-off-by: Liu Yi L
> Signed-off-by: Jacob Pan
> ---
> drivers/iommu/intel/iommu.c | 10 ++
> drivers/iommu/intel/svm.c | 7 +--
> 2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> index b2fe54e..88f4647 100644
> --- a/drivers/iommu/intel/iommu.c
> +++ b/drivers/iommu/intel/iommu.c
> @@ -5436,6 +5436,7 @@ intel_iommu_sva_invalidate(struct iommu_domain *domain,
> struct device *dev,
> int granu = 0;
> u64 pasid = 0;
> u64 addr = 0;
> + void *pdata;
>
> granu = to_vtd_granularity(cache_type, inv_info->granularity);
> if (granu == -EINVAL) {
> @@ -5456,6 +5457,15 @@ intel_iommu_sva_invalidate(struct iommu_domain
> *domain, struct device *dev,
>(inv_info->granu.addr_info.flags &
> IOMMU_INV_ADDR_FLAGS_PASID))
> pasid = inv_info->granu.addr_info.pasid;
>
> + pdata = ioasid_find(dmar_domain->ioasid_sid, pasid, NULL);
> + if (!pdata) {
> + ret = -EINVAL;
> + goto out_unlock;
> + } else if (IS_ERR(pdata)) {
> + ret = PTR_ERR(pdata);
> + goto out_unlock;
> + }
> +
> switch (BIT(cache_type)) {
> case IOMMU_CACHE_INV_TYPE_IOTLB:
> /* HW will ignore LSB bits based on address mask */
> diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
> index c85b8d5..b9b29ad 100644
> --- a/drivers/iommu/intel/svm.c
> +++ b/drivers/iommu/intel/svm.c
> @@ -323,7 +323,7 @@ int intel_svm_bind_gpasid(struct iommu_domain *domain,
> struct device *dev,
> dmar_domain = to_dmar_domain(domain);
>
> mutex_lock(_mutex);
> - svm = ioasid_find(INVALID_IOASID_SET, data->hpasid, NULL);
> + svm = ioasid_find(dmar_domain->ioasid_sid, data->hpasid, NULL);
A question about the locking strategy. We don't take the
device_domain_lock here. Could you clarify whether it is safe?
> if (IS_ERR(svm)) {
> ret = PTR_ERR(svm);
> goto out;
> @@ -440,6 +440,7 @@ int intel_svm_unbind_gpasid(struct iommu_domain *domain,
> struct device *dev, u32 pasid)
> {
> struct intel_iommu *iommu = intel_svm_device_to_iommu(dev);
> + struct dmar_domain *dmar_domain;
> struct intel_svm_dev *sdev;
> struct intel_svm *svm;
> int ret = -EINVAL;
> @@ -447,8 +448,10 @@ int intel_svm_unbind_gpasid(struct iommu_domain *domain,
> if (WARN_ON(!iommu))
> return -EINVAL;
>
> + dmar_domain = to_dmar_domain(domain);
> +
> mutex_lock(_mutex);
> - svm = ioasid_find(INVALID_IOASID_SET, pasid, NULL);
> + svm = ioasid_find(dmar_domain->ioasid_sid, pasid, NULL);
same here.
> if (!svm) {
> ret = -EINVAL;
> goto out;
>
Thanks
Eric
[PATCH v2 3/3] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
The panel uses a Focaltech FT8006p, the touch part is handled by the
already existing edt-ft5x06.
Signed-off-by: Guido Günther
---
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-mantix-mlaf057we51.c | 328 ++
4 files changed, 347 insertions(+)
create mode 100644 drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 83ba7b62651f7..7dfe4cc3d4ec8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5474,6 +5474,13 @@ S: Maintained
F: drivers/gpu/drm/panel/panel-lvds.c
F: Documentation/devicetree/bindings/display/panel/lvds.yaml
+DRM DRIVER FOR MANTIX MLAF057WE51 PANELS
+M: Guido Günther
+R: Purism Kernel Team
+S: Maintained
+F:
Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
+F: drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+
DRM DRIVER FOR MATROX G200/G400 GRAPHICS CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/mga/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index de2f2a452be55..8d97d07c58713 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -217,6 +217,17 @@ config DRM_PANEL_NOVATEK_NT39016
Say Y here if you want to enable support for the panels built
around the Novatek NT39016 display controller.
+config DRM_PANEL_MANTIX_MLAF057WE51
+ tristate "Mantix MLAF057WE51-X MIPI-DSI LCD panel"
+ depends on OF
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for the Mantix
+ MLAF057WE51-X MIPI DSI panel as e.g. used in the Librem 5. It
+ has a resolution of 720x1440 pixels, a built in backlight and touch
+ controller.
+
config DRM_PANEL_OLIMEX_LCD_OLINUXINO
tristate "Olimex LCD-OLinuXino panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index e45ceac6286fd..15a4e77529514 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o
obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o
+obj-$(CONFIG_DRM_PANEL_MANTIX_MLAF057WE51) += panel-mantix-mlaf057we51.o
obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o
obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
obj-$(CONFIG_DRM_PANEL_OSD_OSD101T2587_53TS) += panel-osd-osd101t2587-53ts.o
diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
new file mode 100644
index 0..cd5424d5bdb63
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -0,0 +1,328 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Mantix MLAF057WE51 5.7" MIPI-DSI panel driver
+ *
+ * Copyright (C) Purism SPC 2020
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "panel-mantix-mlaf057we51"
+
+/* Manufacturer specific Commands send via DSI */
+#define MANTIX_CMD_OTP_STOP_RELOAD_MIPI 0x41
+#define MANTIX_CMD_INT_CANCEL 0x4C
+
+struct mantix {
+ struct device *dev;
+ struct drm_panel panel;
+ struct gpio_desc *reset_gpio;
+
+ struct regulator *avdd;
+ struct regulator *avee;
+ struct regulator *vddi;
+};
+
+static inline struct mantix *panel_to_mantix(struct drm_panel *panel)
+{
+ return container_of(panel, struct mantix, panel);
+}
+
+#define dsi_generic_write_seq(dsi, seq...) do {
\
+ static const u8 d[] = { seq }; \
+ int ret;\
+ ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));\
+ if (ret < 0)\
+ return ret; \
+ } while (0)
+
+static int mantix_init_sequence(struct mantix *ctx)
+{
+ struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
+ struct device *dev = ctx->dev;
+
+ /*
+* Init sequence was supplied by the panel vendor.
+*/
+ dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x5A);
+
+ dsi_generic_write_seq(dsi, MANTIX_CMD_INT_CANCEL, 0x03);
+ dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x5A, 0x03);
+ dsi_generic_write_seq(dsi, 0x80, 0xA9, 0x00);
+
+ dsi_generic_write_seq(dsi, MANTIX_CMD_OTP_STOP_RELOAD_MIPI, 0x5A, 0x09);
+ dsi_generic_write_seq(dsi, 0x80, 0x64, 0x00,
[PATCH v2 2/3] dt-bindings: Add Mantix MLAF057WE51-X panel bindings
The panel uses a Focaltech FT8006p, the touch part is handled by the
already existing edt-ft5x06.
Signed-off-by: Guido Günther
---
.../display/panel/mantix,mlaf057we51-x.yaml | 70 +++
1 file changed, 70 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
new file mode 100644
index 0..937323cc9aaac
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/mantix,mlaf057we51-x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mantix MLAF057WE51-X 5.7" 720x1440 TFT LCD panel
+
+maintainers:
+ - Guido Günther
+
+description:
+ Mantix MLAF057WE51 X is a 720x1440 TFT LCD panel connected using
+ a MIPI-DSI video interface.
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+enum:
+ - mantix,mlaf057we51-x
+
+ port: true
+ reg:
+maxItems: 1
+description: DSI virtual channel
+
+ avdd-supply:
+description: Positive analog power supply
+
+ avee-supply:
+description: Negative analog power supply
+
+ vddi-supply:
+description: 1.8V I/O voltage supply
+
+ reset-gpios: true
+
+ backlight: true
+
+required:
+ - compatible
+ - reg
+ - avdd-supply
+ - avee-supply
+ - vddi-supply
+ - reset-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "mantix,mlaf057we51-x";
+reg = <0>;
+avdd-supply = <_avdd>;
+avee-supply = <_avee>;
+vddi-supply = <_1v8_p>;
+reset-gpios = < 29 GPIO_ACTIVE_LOW>;
+backlight = <>;
+};
+};
+
+...
--
2.26.2
[PATCH v2 0/3] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
The panel uses a Focaltech FT8006p, the touch part is handled by the already
existing edt-ft5x06. It can be found in e.g. the Librem 5.
Changes from v1:
- Due to review comments by Sam Ravnborg, thanks!
https://lore.kernel.org/dri-devel/20200815083917.ga993...@ravnborg.org/
- Don't preserve newlines with '|' in description
- Use reset-gpios and backlight from panel-common.yaml
- Reindent example
https://lore.kernel.org/dri-devel/20200815093226.gb993...@ravnborg.org/
- Drop unused includes
- Use dev_* instead of DRM_* for printing
- Turn off regulators in reverse order from enable
- Silence errors in mantix_{shutdown,remove}
- Drop duplicate mipi_dsi_dcs_enter_sleep_mode()
https://lore.kernel.org/dri-devel/20200815100230.ga1002...@ravnborg.org/
- Use dev_err_probe()
- Add delays when turning off panel as suggested by the data sheet
This series is against next-20200814.
Guido Günther (3):
dt-bindings: vendor-prefixes: Add mantix vendor prefix
dt-bindings: Add Mantix MLAF057WE51-X panel bindings
drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
.../display/panel/mantix,mlaf057we51-x.yaml | 70
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
MAINTAINERS | 7 +
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile| 1 +
.../gpu/drm/panel/panel-mantix-mlaf057we51.c | 328 ++
6 files changed, 419 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
create mode 100644 drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
--
2.26.2
[PATCH v2 1/3] dt-bindings: vendor-prefixes: Add mantix vendor prefix
Add prefix for Mantix Display Technology Co.,Ltd. Signed-off-by: Guido Günther --- 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 2baee2c817c1a..59d4c8b068c4d 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -611,6 +611,8 @@ patternProperties: description: Linux Automation GmbH "^macnica,.*": description: Macnica Americas + "^mantix,.*": +description: Mantix Display Technology Co.,Ltd. "^mapleboard,.*": description: Mapleboard.org "^marvell,.*": -- 2.26.2
[PATCH] exfat: use i_blocksize() to get blocksize
We alreday has the interface i_blocksize() to get blocksize,
so use it.
Signed-off-by: Xianting Tian
---
fs/exfat/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/exfat/file.c b/fs/exfat/file.c
index a6a063830..163b599db 100644
--- a/fs/exfat/file.c
+++ b/fs/exfat/file.c
@@ -226,7 +226,7 @@ void exfat_truncate(struct inode *inode, loff_t size)
{
struct super_block *sb = inode->i_sb;
struct exfat_sb_info *sbi = EXFAT_SB(sb);
- unsigned int blocksize = 1 << inode->i_blkbits;
+ unsigned int blocksize = i_blocksize(inode);
loff_t aligned_size;
int err;
--
2.17.1
Re: [PATCH v6 07/15] vfio/type1: Add VFIO_IOMMU_PASID_REQUEST (alloc/free)
Yi,
On 7/28/20 8:27 AM, Liu Yi L wrote:
> This patch allows userspace to request PASID allocation/free, e.g. when
> serving the request from the guest.
>
> PASIDs that are not freed by userspace are automatically freed when the
> IOASID set is destroyed when process exits.
>
> Cc: Kevin Tian
> CC: Jacob Pan
> Cc: Alex Williamson
> Cc: Eric Auger
> Cc: Jean-Philippe Brucker
> Cc: Joerg Roedel
> Cc: Lu Baolu
> Signed-off-by: Liu Yi L
> Signed-off-by: Yi Sun
> Signed-off-by: Jacob Pan
> ---
> v5 -> v6:
> *) address comments from Eric against v5. remove the alloc/free helper.
>
> v4 -> v5:
> *) address comments from Eric Auger.
> *) the comments for the PASID_FREE request is addressed in patch 5/15 of
>this series.
>
> v3 -> v4:
> *) address comments from v3, except the below comment against the range
>of PASID_FREE request. needs more help on it.
> "> +if (req.range.min > req.range.max)
>
> Is it exploitable that a user can spin the kernel for a long time in
> the case of a free by calling this with [0, MAX_UINT] regardless of
> their actual allocations?"
> https://lore.kernel.org/linux-iommu/20200702151832.048b4...@x1.home/
>
> v1 -> v2:
> *) move the vfio_mm related code to be a seprate module
> *) use a single structure for alloc/free, could support a range of PASIDs
> *) fetch vfio_mm at group_attach time instead of at iommu driver open time
> ---
> drivers/vfio/Kconfig| 1 +
> drivers/vfio/vfio_iommu_type1.c | 69
> +
> drivers/vfio/vfio_pasid.c | 10 ++
> include/linux/vfio.h| 6
> include/uapi/linux/vfio.h | 37 ++
> 5 files changed, 123 insertions(+)
>
> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
> index 3d8a108..95d90c6 100644
> --- a/drivers/vfio/Kconfig
> +++ b/drivers/vfio/Kconfig
> @@ -2,6 +2,7 @@
> config VFIO_IOMMU_TYPE1
> tristate
> depends on VFIO
> + select VFIO_PASID if (X86)
> default n
>
> config VFIO_IOMMU_SPAPR_TCE
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 18ff0c3..ea89c7c 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -76,6 +76,7 @@ struct vfio_iommu {
> booldirty_page_tracking;
> boolpinned_page_dirty_scope;
> struct iommu_nesting_info *nesting_info;
> + struct vfio_mm *vmm;
> };
>
> struct vfio_domain {
> @@ -1937,6 +1938,11 @@ static void vfio_iommu_iova_insert_copy(struct
> vfio_iommu *iommu,
>
> static void vfio_iommu_release_nesting_info(struct vfio_iommu *iommu)
> {
> + if (iommu->vmm) {
> + vfio_mm_put(iommu->vmm);
> + iommu->vmm = NULL;
> + }
> +
> kfree(iommu->nesting_info);
> iommu->nesting_info = NULL;
> }
> @@ -2071,6 +2077,26 @@ static int vfio_iommu_type1_attach_group(void
> *iommu_data,
> iommu->nesting_info);
> if (ret)
> goto out_detach;
> +
> + if (iommu->nesting_info->features &
> + IOMMU_NESTING_FEAT_SYSWIDE_PASID) {
> + struct vfio_mm *vmm;
> + int sid;
> +
> + vmm = vfio_mm_get_from_task(current);
> + if (IS_ERR(vmm)) {
> + ret = PTR_ERR(vmm);
> + goto out_detach;
> + }
> + iommu->vmm = vmm;
> +
> + sid = vfio_mm_ioasid_sid(vmm);
> + ret = iommu_domain_set_attr(domain->domain,
> + DOMAIN_ATTR_IOASID_SID,
> + );
> + if (ret)
> + goto out_detach;
> + }
> }
>
> /* Get aperture info */
> @@ -2859,6 +2885,47 @@ static int vfio_iommu_type1_dirty_pages(struct
> vfio_iommu *iommu,
> return -EINVAL;
> }
>
> +static int vfio_iommu_type1_pasid_request(struct vfio_iommu *iommu,
> + unsigned long arg)
> +{
> + struct vfio_iommu_type1_pasid_request req;
> + unsigned long minsz;
> + int ret;
> +
> + minsz = offsetofend(struct vfio_iommu_type1_pasid_request, range);
> +
> + if (copy_from_user(, (void __user *)arg, minsz))
> + return -EFAULT;
> +
> + if (req.argsz < minsz || (req.flags & ~VFIO_PASID_REQUEST_MASK))
> + return -EINVAL;
> +
> + if (req.range.min > req.range.max)
> + return -EINVAL;
> +
> + mutex_lock(>lock);
> + if (!iommu->vmm) {
> + mutex_unlock(>lock);
> + return -EOPNOTSUPP;
> + }
> +
> + switch (req.flags & VFIO_PASID_REQUEST_MASK) {
> + case
Re: [PATCH v2] lib/string.c: implement stpcpy
On Sat, 2020-08-15 at 13:47 -0700, Nick Desaulniers wrote:
> On Sat, Aug 15, 2020 at 9:34 AM Kees Cook wrote:
> > On Fri, Aug 14, 2020 at 07:09:44PM -0700, Nick Desaulniers wrote:
> > > LLVM implemented a recent "libcall optimization" that lowers calls to
> > > `sprintf(dest, "%s", str)` where the return value is used to
> > > `stpcpy(dest, str) - dest`. This generally avoids the machinery involved
> > > in parsing format strings. Calling `sprintf` with overlapping arguments
> > > was clarified in ISO C99 and POSIX.1-2001 to be undefined behavior.
> > >
> > > `stpcpy` is just like `strcpy` except it returns the pointer to the new
> > > tail of `dest`. This allows you to chain multiple calls to `stpcpy` in
> > > one statement.
> >
> > O_O What?
> >
> > No; this is a _terrible_ API: there is no bounds checking, there are no
> > buffer sizes. Anything using the example sprintf() pattern is _already_
> > wrong and must be removed from the kernel. (Yes, I realize that the
> > kernel is *filled* with this bad assumption that "I'll never write more
> > than PAGE_SIZE bytes to this buffer", but that's both theoretically
> > wrong ("640k is enough for anybody") and has been known to be wrong in
> > practice too (e.g. when suddenly your writing routine is reachable by
> > splice(2) and you may not have a PAGE_SIZE buffer).
> >
> > But we cannot _add_ another dangerous string API. We're already in a
> > terrible mess trying to remove strcpy[1], strlcpy[2], and strncpy[3]. This
> > needs to be addressed up by removing the unbounded sprintf() uses. (And
> > to do so without introducing bugs related to using snprintf() when
> > scnprintf() is expected[4].)
>
> Well, everything (-next, mainline, stable) is broken right now (with
> ToT Clang) without providing this symbol. I'm not going to go clean
> the entire kernel's use of sprintf to get our CI back to being green.
Maybe this should get place in compiler-clang.h so it isn't
generic and public.
Something like:
---
include/linux/compiler-clang.h | 27 +++
1 file changed, 27 insertions(+)
diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index cee0c728d39a..6279f1904e39 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -61,3 +61,30 @@
#if __has_feature(shadow_call_stack)
# define __noscs __attribute__((__no_sanitize__("shadow-call-stack")))
#endif
+
+#ifndef __HAVE_ARCH_STPCPY
+/**
+ * stpcpy - copy a string from src to dest returning a pointer to the new end
+ * of dest, including src's NULL terminator. May overrun dest.
+ * @dest: pointer to buffer being copied into.
+ *Must be large enough to receive copy.
+ * @src: pointer to the beginning of string being copied from.
+ * Must not overlap dest.
+ *
+ * This function exists _only_ to support clang's possible conversion of
+ * sprintf calls to stpcpy.
+ *
+ * stpcpy differs from strcpy in two key ways:
+ * 1. inputs must not overlap.
+ * 2. return value is dest's NUL termination character after copy.
+ *(for strcpy, the return value is a pointer to src)
+ */
+
+static inline char *stpcpy(char __restrict *dest, const char __restrict *src)
+{
+ while ((*dest++ = *src++) != '\0') {
+ ; /* nothing */
+ }
+ return --dest;
+}
+#endif
[PATCH] genksyms: keywords: Use __restrict not _restrict
Use the proper form of the RESTRICT keyword.
Quote the comments properly too.
Signed-off-by: Joe Perches
---
scripts/genksyms/keywords.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/genksyms/keywords.c b/scripts/genksyms/keywords.c
index 7a85c4e21175..057c6cabad1d 100644
--- a/scripts/genksyms/keywords.c
+++ b/scripts/genksyms/keywords.c
@@ -25,9 +25,9 @@ static struct resword {
{ "__int128_t", BUILTIN_INT_KEYW },
{ "__uint128_t", BUILTIN_INT_KEYW },
- // According to rth, c99 defines "_Bool", __restrict", __restrict__",
"restrict". KAO
+ // According to rth, c99 defines "_Bool", "__restrict", "__restrict__",
"restrict". KAO
{ "_Bool", BOOL_KEYW },
- { "_restrict", RESTRICT_KEYW },
+ { "__restrict", RESTRICT_KEYW },
{ "__restrict__", RESTRICT_KEYW },
{ "restrict", RESTRICT_KEYW },
{ "asm", ASM_KEYW },
Re: [PATCH v2 2/3] dt-bindings: Add Mantix MLAF057WE51-X panel bindings
On Sat, Aug 15, 2020 at 11:16:21PM +0200, Guido Günther wrote:
> The panel uses a Focaltech FT8006p, the touch part is handled by the
> already existing edt-ft5x06.
>
> Signed-off-by: Guido Günther
Reviewed-by: Sam Ravnborg
I assume you will apply yourself, otherwise I will do so when we have
seen a backmerge.
Sam
> ---
> .../display/panel/mantix,mlaf057we51-x.yaml | 70 +++
> 1 file changed, 70 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> new file mode 100644
> index 0..937323cc9aaac
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> @@ -0,0 +1,70 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/mantix,mlaf057we51-x.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mantix MLAF057WE51-X 5.7" 720x1440 TFT LCD panel
> +
> +maintainers:
> + - Guido Günther
> +
> +description:
> + Mantix MLAF057WE51 X is a 720x1440 TFT LCD panel connected using
> + a MIPI-DSI video interface.
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +enum:
> + - mantix,mlaf057we51-x
> +
> + port: true
> + reg:
> +maxItems: 1
> +description: DSI virtual channel
> +
> + avdd-supply:
> +description: Positive analog power supply
> +
> + avee-supply:
> +description: Negative analog power supply
> +
> + vddi-supply:
> +description: 1.8V I/O voltage supply
> +
> + reset-gpios: true
> +
> + backlight: true
> +
> +required:
> + - compatible
> + - reg
> + - avdd-supply
> + - avee-supply
> + - vddi-supply
> + - reset-gpios
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +dsi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +panel@0 {
> +compatible = "mantix,mlaf057we51-x";
> +reg = <0>;
> +avdd-supply = <_avdd>;
> +avee-supply = <_avee>;
> +vddi-supply = <_1v8_p>;
> +reset-gpios = < 29 GPIO_ACTIVE_LOW>;
> +backlight = <>;
> +};
> +};
> +
> +...
> --
> 2.26.2
Re: [PATCH v2 1/3] dt-bindings: vendor-prefixes: Add mantix vendor prefix
On Sat, Aug 15, 2020 at 11:16:20PM +0200, Guido Günther wrote: > Add prefix for Mantix Display Technology Co.,Ltd. > > Signed-off-by: Guido Günther Acked-by: Sam Ravnborg > --- > 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 2baee2c817c1a..59d4c8b068c4d 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > @@ -611,6 +611,8 @@ patternProperties: > description: Linux Automation GmbH >"^macnica,.*": > description: Macnica Americas > + "^mantix,.*": > +description: Mantix Display Technology Co.,Ltd. >"^mapleboard,.*": > description: Mapleboard.org >"^marvell,.*": > -- > 2.26.2
Re: [PATCH v2 3/3] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
Hi Guido.
On Sat, Aug 15, 2020 at 11:16:22PM +0200, Guido Günther wrote:
> The panel uses a Focaltech FT8006p, the touch part is handled by the
> already existing edt-ft5x06.
>
> Signed-off-by: Guido Günther
Two small nits - otherwise looks good.
Reviewed-by: Sam Ravnborg
I can fix while applying or you can send a new revision,
but I cannot apply until drm-misc-next have seen a backmerge
due to dev_err_probe() usage.
Did you have commit rights yet?
If yes, then please apply yourself.
Sam
> ---
> MAINTAINERS | 7 +
> drivers/gpu/drm/panel/Kconfig | 11 +
> drivers/gpu/drm/panel/Makefile| 1 +
> .../gpu/drm/panel/panel-mantix-mlaf057we51.c | 328 ++
> 4 files changed, 347 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 83ba7b62651f7..7dfe4cc3d4ec8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5474,6 +5474,13 @@ S: Maintained
> F: drivers/gpu/drm/panel/panel-lvds.c
> F: Documentation/devicetree/bindings/display/panel/lvds.yaml
>
> +DRM DRIVER FOR MANTIX MLAF057WE51 PANELS
> +M: Guido Günther
> +R: Purism Kernel Team
> +S: Maintained
> +F:
> Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> +F: drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
> +
> DRM DRIVER FOR MATROX G200/G400 GRAPHICS CARDS
> S: Orphan / Obsolete
> F: drivers/gpu/drm/mga/
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index de2f2a452be55..8d97d07c58713 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -217,6 +217,17 @@ config DRM_PANEL_NOVATEK_NT39016
> Say Y here if you want to enable support for the panels built
> around the Novatek NT39016 display controller.
>
> +config DRM_PANEL_MANTIX_MLAF057WE51
> + tristate "Mantix MLAF057WE51-X MIPI-DSI LCD panel"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> + Say Y here if you want to enable support for the Mantix
> + MLAF057WE51-X MIPI DSI panel as e.g. used in the Librem 5. It
> + has a resolution of 720x1440 pixels, a built in backlight and touch
> + controller.
> +
> config DRM_PANEL_OLIMEX_LCD_OLINUXINO
> tristate "Olimex LCD-OLinuXino panel"
> depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index e45ceac6286fd..15a4e77529514 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
> obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
> obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o
> obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o
> +obj-$(CONFIG_DRM_PANEL_MANTIX_MLAF057WE51) += panel-mantix-mlaf057we51.o
> obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lcd-olinuxino.o
> obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
> obj-$(CONFIG_DRM_PANEL_OSD_OSD101T2587_53TS) += panel-osd-osd101t2587-53ts.o
> diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
> b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
> new file mode 100644
> index 0..cd5424d5bdb63
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
> @@ -0,0 +1,328 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Mantix MLAF057WE51 5.7" MIPI-DSI panel driver
> + *
> + * Copyright (C) Purism SPC 2020
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +#include
> +#include
drm_print.h is no longer used - drop.
> +
> +#define DRV_NAME "panel-mantix-mlaf057we51"
> +
> +/* Manufacturer specific Commands send via DSI */
> +#define MANTIX_CMD_OTP_STOP_RELOAD_MIPI 0x41
> +#define MANTIX_CMD_INT_CANCEL 0x4C
> +
> +struct mantix {
> + struct device *dev;
> + struct drm_panel panel;
> + struct gpio_desc *reset_gpio;
> +
> + struct regulator *avdd;
> + struct regulator *avee;
> + struct regulator *vddi;
> +};
> +
> +static inline struct mantix *panel_to_mantix(struct drm_panel *panel)
> +{
> + return container_of(panel, struct mantix, panel);
> +}
> +
> +#define dsi_generic_write_seq(dsi, seq...) do {
> \
> + static const u8 d[] = { seq }; \
> + int ret;\
> + ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));\
> + if (ret < 0)\
> + return ret; \
> + } while (0)
> +
> +static int mantix_init_sequence(struct mantix *ctx)
> +{
> + struct
Re: [PATCH 2/3] dt-bindings: Add Mantix MLAF057WE51-X panel bindings
Hi Guido.
On Fri, Aug 14, 2020 at 03:36:22PM +0200, Guido Günther wrote:
> The panel uses a Focaltech FT8006p, the touch part is handled by the
> already existing edt-ft5x06.
>
> Signed-off-by: Guido Günther
A few trivialities.
> ---
> .../display/panel/mantix,mlaf057we51-x.yaml | 73 +++
> 1 file changed, 73 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> new file mode 100644
> index 0..349f3380ac940
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> @@ -0,0 +1,73 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/mantix,mlaf057we51-x.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mantix MLAF057WE51-X 5.7" 720x1440 TFT LCD panel
> +
> +maintainers:
> + - Guido Günther
> +
> +description: |
> + Mantix MLAF057WE51 X is a 720x1440 TFT LCD panel
> + connected using a MIPI-DSI video interface.
Indent text with two spaces only.
And I have learned that '|' is only needed to preserve formatting - so
it can be dropped.
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> +enum:
> + - mantix,mlaf057we51-x
This is a list - so needs an extra 2 spaces indent.
See
https://lore.kernel.org/linux-devicetree/f1963eb9-283f-e903-2a3a-4f324d71d...@lucaceresoli.net/T/#m65900317fb948f6c40e8fb521f2201fba3c301a7
for examples where Rob fixes this.
> +
> + port: true
> + reg:
> +maxItems: 1
> +description: DSI virtual channel
> +
> + avdd-supply:
> +description: Positive analog power supply
> +
> + avee-supply:
> +description: Negative analog power supply
> +
> + vddi-supply:
> +description: 1.8V I/O voltage supply
> +
> + reset-gpios:
> +description: GPIO used for the reset pin
> +maxItems: 1
Use reset-gpios: true as we already have it in panel-common.yaml
> +
> + backlight:
> +description: Backlight used by the panel
> +$ref: "/schemas/types.yaml#/definitions/phandle"
Use backlight from panel-common.yaml.
> +
> +required:
> + - compatible
> + - reg
> + - avdd-supply
> + - avee-supply
> + - vddi-supply
> + - reset-gpios
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +dsi {
My personal preference is indent with 4 spaces in examples but there are
no rules so feel free to ignore.
> + #address-cells = <1>;
> + #size-cells = <0>;
> + panel@0 {
> +compatible = "mantix,mlaf057we51-x";
> +reg = <0>;
> +avdd-supply = <_avdd>;
> +avee-supply = <_avee>;
> +vddi-supply = <_1v8_p>;
> +reset-gpios = < 29 GPIO_ACTIVE_LOW>;
> +backlight = <>;
> + };
> +};
I think we need an ampty line here.
> +...
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] selinux: add tracepoint on denials
On 8/14/20 7:46 PM, Steven Rostedt wrote:
> On Fri, 14 Aug 2020 19:22:13 +0200
> peter enderborg wrote:
>
>> On 8/14/20 7:08 PM, Stephen Smalley wrote:
>>> On Fri, Aug 14, 2020 at 1:07 PM peter enderborg
>>> wrote:
On 8/14/20 6:51 PM, Stephen Smalley wrote:
> On Fri, Aug 14, 2020 at 9:05 AM Thiébaud Weksteen
> wrote:
>> On Thu, Aug 13, 2020 at 5:41 PM Stephen Smalley
>> wrote:
>>> An explanation here of how one might go about decoding audited and
>>> tclass would be helpful to users (even better would be a script to do it
>>> for them). Again, I know how to do that but not everyone using
>>> perf/ftrace will.
>> What about something along those lines:
>>
>> The tclass value can be mapped to a class by searching
>> security/selinux/flask.h. The audited value is a bit field of the
>> permissions described in security/selinux/av_permissions.h for the
>> corresponding class.
> Sure, I guess that works. Would be nice if we just included the class
> and permission name(s) in the event itself but I guess you viewed that
> as too heavyweight?
The class name is added in part 2. Im not sure how a proper format for
permission
would look like in trace terms. It is a list, right?
>>> Yes. See avc_audit_pre_callback() for example code to log the permission
>>> names.
>> I wrote about that on some of the previous sets. The problem is that trace
>> format is quite fixed. So it is lists are not
>> that easy to handle if you want to filter in them. You can have a trace
>> event for each of them. You can also add
>> additional trace event "selinux_audied_permission" for each permission. With
>> that you can filter out tclass or permissions.
>>
>> But the basic thing we would like at the moment is a event that we can debug
>> in user space.
> We have a trace_seq p helper, that lets you create strings in
> TP_printk(). I should document this more. Thus you can do:
>
> extern const char *audit_perm_to_name(struct trace_seq *p, u16 class, u32
> audited);
> #define __perm_to_name(p, class, audited) audit_perm_to_name(p, class,
> audited)
>
> TP_printk("tclass=%u audited=%x (%s)",
> __entry->tclass,
> __entry->audited,
> __perm_to_name(__entry->tclass, __entry->audited))
>
>
> const char *audit_perm_to_name(struct trace_seq *p, u16 tclass, u32 av)
> {
> const char *ret = trace_seq_buffer_ptr(p);
> int i, perm;
>
> ( some check for tclass integrity here)
>
> perms = secclass_map[tclass-1].perms;
>
> i = 0;
> perm = 1;
> while (i < (sizeof(av) * 8)) {
> if ((perm & av) && perms[i]) {
> trace_seq_printf(p, " %s", perms[i]);
> av &= ~perm;
> }
> i++;
> perm <<= 1;
> }
>
> return ret;
> }
>
> Note, this wont work for perf and trace-cmd as it wouldn't know how to
> parse it, but if the tclass perms are stable, you could create a plugin
> to libtraceevent that can do the above as well.
>
> -- Steve
That works fine. I will do this as third patch in our patch-set. But I think
we also should export the permission-map
somewhere. I don’t think there is any good place for it in tracefs. So
selinuxfs or debugfs might do? And I think it is
more useful to print what is denied than what is audited but that does not
match the trace event name.
Re: [PATCH v2 1/2] selinux: add tracepoint on denials
On 8/14/20 7:46 PM, Steven Rostedt wrote:
> On Fri, 14 Aug 2020 19:22:13 +0200
> peter enderborg wrote:
>
>> On 8/14/20 7:08 PM, Stephen Smalley wrote:
>>> On Fri, Aug 14, 2020 at 1:07 PM peter enderborg
>>> wrote:
On 8/14/20 6:51 PM, Stephen Smalley wrote:
> On Fri, Aug 14, 2020 at 9:05 AM Thiébaud Weksteen
> wrote:
>> On Thu, Aug 13, 2020 at 5:41 PM Stephen Smalley
>> wrote:
>>> An explanation here of how one might go about decoding audited and
>>> tclass would be helpful to users (even better would be a script to do it
>>> for them). Again, I know how to do that but not everyone using
>>> perf/ftrace will.
>> What about something along those lines:
>>
>> The tclass value can be mapped to a class by searching
>> security/selinux/flask.h. The audited value is a bit field of the
>> permissions described in security/selinux/av_permissions.h for the
>> corresponding class.
> Sure, I guess that works. Would be nice if we just included the class
> and permission name(s) in the event itself but I guess you viewed that
> as too heavyweight?
The class name is added in part 2. Im not sure how a proper format for
permission
would look like in trace terms. It is a list, right?
>>> Yes. See avc_audit_pre_callback() for example code to log the permission
>>> names.
>> I wrote about that on some of the previous sets. The problem is that trace
>> format is quite fixed. So it is lists are not
>> that easy to handle if you want to filter in them. You can have a trace
>> event for each of them. You can also add
>> additional trace event "selinux_audied_permission" for each permission. With
>> that you can filter out tclass or permissions.
>>
>> But the basic thing we would like at the moment is a event that we can debug
>> in user space.
> We have a trace_seq p helper, that lets you create strings in
> TP_printk(). I should document this more. Thus you can do:
>
> extern const char *audit_perm_to_name(struct trace_seq *p, u16 class, u32
> audited);
> #define __perm_to_name(p, class, audited) audit_perm_to_name(p, class,
> audited)
>
> TP_printk("tclass=%u audited=%x (%s)",
> __entry->tclass,
> __entry->audited,
> __perm_to_name(__entry->tclass, __entry->audited))
>
>
> const char *audit_perm_to_name(struct trace_seq *p, u16 tclass, u32 av)
> {
> const char *ret = trace_seq_buffer_ptr(p);
> int i, perm;
>
> ( some check for tclass integrity here)
>
> perms = secclass_map[tclass-1].perms;
>
> i = 0;
> perm = 1;
> while (i < (sizeof(av) * 8)) {
> if ((perm & av) && perms[i]) {
> trace_seq_printf(p, " %s", perms[i]);
> av &= ~perm;
> }
> i++;
> perm <<= 1;
> }
>
> return ret;
> }
>
> Note, this wont work for perf and trace-cmd as it wouldn't know how to
> parse it, but if the tclass perms are stable, you could create a plugin
> to libtraceevent that can do the above as well.
>
> -- Steve
Something like:
while (i < (sizeof(av) * 8)) {
if ((perm & av) && perms[i]) {
if (!(perm & avdenied))
trace_seq_printf(p, " %s", perms[i]);
else
trace_seq_printf(p, " !%s", perms[i]);
av &= ~perm;
And you get information about denied too.
Re: [PATCH 3/3] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
Hi Sam,
On Sat, Aug 15, 2020 at 11:32:26AM +0200, Sam Ravnborg wrote:
> Hi Guido.
>
> On Fri, Aug 14, 2020 at 03:36:23PM +0200, Guido Günther wrote:
> > The panel uses a Focaltech FT8006p, the touch part is handled by the
> > already existing edt-ft5x06.
> >
> > Signed-off-by: Guido Günther
>
> Looks good.
> A few notes in the following, nothing major.
Thanks. I've added your suggestions to v2.
-- Guido
>
> Sam
>
> > ---
> > MAINTAINERS | 7 +
> > drivers/gpu/drm/panel/Kconfig | 11 +
> > drivers/gpu/drm/panel/Makefile| 1 +
> > .../gpu/drm/panel/panel-mantix-mlaf057we51.c | 362 ++
> > 4 files changed, 381 insertions(+)
> > create mode 100644 drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 83ba7b62651f7..7dfe4cc3d4ec8 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -5474,6 +5474,13 @@ S: Maintained
> > F: drivers/gpu/drm/panel/panel-lvds.c
> > F: Documentation/devicetree/bindings/display/panel/lvds.yaml
> >
> > +DRM DRIVER FOR MANTIX MLAF057WE51 PANELS
> > +M: Guido Günther
> > +R: Purism Kernel Team
> > +S: Maintained
> > +F:
> > Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> > +F: drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
> > +
> > DRM DRIVER FOR MATROX G200/G400 GRAPHICS CARDS
> > S: Orphan / Obsolete
> > F: drivers/gpu/drm/mga/
> > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> > index de2f2a452be55..8d97d07c58713 100644
> > --- a/drivers/gpu/drm/panel/Kconfig
> > +++ b/drivers/gpu/drm/panel/Kconfig
> > @@ -217,6 +217,17 @@ config DRM_PANEL_NOVATEK_NT39016
> > Say Y here if you want to enable support for the panels built
> > around the Novatek NT39016 display controller.
> >
> > +config DRM_PANEL_MANTIX_MLAF057WE51
> > + tristate "Mantix MLAF057WE51-X MIPI-DSI LCD panel"
> > + depends on OF
> > + depends on DRM_MIPI_DSI
> > + depends on BACKLIGHT_CLASS_DEVICE
> > + help
> > + Say Y here if you want to enable support for the Mantix
> > + MLAF057WE51-X MIPI DSI panel as e.g. used in the Librem 5. It
> > + has a resolution of 720x1440 pixels, a built in backlight and touch
> > + controller.
> > +
> > config DRM_PANEL_OLIMEX_LCD_OLINUXINO
> > tristate "Olimex LCD-OLinuXino panel"
> > depends on OF
> > diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> > index e45ceac6286fd..15a4e77529514 100644
> > --- a/drivers/gpu/drm/panel/Makefile
> > +++ b/drivers/gpu/drm/panel/Makefile
> > @@ -20,6 +20,7 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
> > obj-$(CONFIG_DRM_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
> > obj-$(CONFIG_DRM_PANEL_NOVATEK_NT35510) += panel-novatek-nt35510.o
> > obj-$(CONFIG_DRM_PANEL_NOVATEK_NT39016) += panel-novatek-nt39016.o
> > +obj-$(CONFIG_DRM_PANEL_MANTIX_MLAF057WE51) += panel-mantix-mlaf057we51.o
> > obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) +=
> > panel-olimex-lcd-olinuxino.o
> > obj-$(CONFIG_DRM_PANEL_ORISETECH_OTM8009A) += panel-orisetech-otm8009a.o
> > obj-$(CONFIG_DRM_PANEL_OSD_OSD101T2587_53TS) +=
> > panel-osd-osd101t2587-53ts.o
> > diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
> > b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
> > new file mode 100644
> > index 0..6c07bcdb75937
> > --- /dev/null
> > +++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
> > @@ -0,0 +1,362 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Mantix MLAF057WE51 5.7" MIPI-DSI panel driver
> > + *
> > + * Copyright (C) Purism SPC 2020
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> Include not needed.
>
> > +#include
> > +#include
> > +
> > +#include
> I do not think this include is needed
>
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define DRV_NAME "panel-mantix-mlaf057we51"
> > +
> > +/* Manufacturer specific Commands send via DSI */
> > +#define MANTIX_CMD_OTP_STOP_RELOAD_MIPI 0x41
> > +#define MANTIX_CMD_INT_CANCEL 0x4C
> > +
> > +struct mantix {
> > + struct device *dev;
> > + struct drm_panel panel;
> > + struct gpio_desc *reset_gpio;
> > +
> > + struct regulator *avdd;
> > + struct regulator *avee;
> > + struct regulator *vddi;
> > +};
> > +
> > +static inline struct mantix *panel_to_mantix(struct drm_panel *panel)
> > +{
> > + return container_of(panel, struct mantix, panel);
> > +}
> > +
> > +#define dsi_generic_write_seq(dsi, seq...) do {
> > \
> > + static const u8 d[] = { seq }; \
> > + int ret;\
> > + ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));\
> > + if (ret < 0)\
> > + return
Re: [PATCH 2/3] dt-bindings: Add Mantix MLAF057WE51-X panel bindings
Hi Sam,
On Sat, Aug 15, 2020 at 10:39:17AM +0200, Sam Ravnborg wrote:
> Hi Guido.
>
> On Fri, Aug 14, 2020 at 03:36:22PM +0200, Guido Günther wrote:
> > The panel uses a Focaltech FT8006p, the touch part is handled by the
> > already existing edt-ft5x06.
> >
> > Signed-off-by: Guido Günther
>
> A few trivialities.
Thanks for having a look. One remark inline:
>
> > ---
> > .../display/panel/mantix,mlaf057we51-x.yaml | 73 +++
> > 1 file changed, 73 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> > b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> > new file mode 100644
> > index 0..349f3380ac940
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> > @@ -0,0 +1,73 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/panel/mantix,mlaf057we51-x.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Mantix MLAF057WE51-X 5.7" 720x1440 TFT LCD panel
> > +
> > +maintainers:
> > + - Guido Günther
> > +
> > +description: |
> > + Mantix MLAF057WE51 X is a 720x1440 TFT LCD panel
> > + connected using a MIPI-DSI video interface.
> Indent text with two spaces only.
> And I have learned that '|' is only needed to preserve formatting - so
> it can be dropped.
>
> > +
> > +allOf:
> > + - $ref: panel-common.yaml#
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - mantix,mlaf057we51-x
> This is a list - so needs an extra 2 spaces indent.
> See
> https://lore.kernel.org/linux-devicetree/f1963eb9-283f-e903-2a3a-4f324d71d...@lucaceresoli.net/T/#m65900317fb948f6c40e8fb521f2201fba3c301a7
> for examples where Rob fixes this.
Doesn't this only apply if the 'outer element' is a list too so e.g.:
- enum
- foo
trips up yamllint but
enum
- foo
doesn't. Since yamllint was happy i kept it as is (looking at your
reference suggests that too).
All the rest made sense and i fixed that for the upcoming v2.
Thanks for having a look!
-- Guido
>
> > +
> > + port: true
> > + reg:
> > +maxItems: 1
> > +description: DSI virtual channel
> > +
> > + avdd-supply:
> > +description: Positive analog power supply
> > +
> > + avee-supply:
> > +description: Negative analog power supply
> > +
> > + vddi-supply:
> > +description: 1.8V I/O voltage supply
> > +
> > + reset-gpios:
> > +description: GPIO used for the reset pin
> > +maxItems: 1
> Use reset-gpios: true as we already have it in panel-common.yaml
>
> > +
> > + backlight:
> > +description: Backlight used by the panel
> > +$ref: "/schemas/types.yaml#/definitions/phandle"
> Use backlight from panel-common.yaml.
>
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - avdd-supply
> > + - avee-supply
> > + - vddi-supply
> > + - reset-gpios
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +
> > +dsi {
> My personal preference is indent with 4 spaces in examples but there are
> no rules so feel free to ignore.
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + panel@0 {
> > +compatible = "mantix,mlaf057we51-x";
> > +reg = <0>;
> > +avdd-supply = <_avdd>;
> > +avee-supply = <_avee>;
> > +vddi-supply = <_1v8_p>;
> > +reset-gpios = < 29 GPIO_ACTIVE_LOW>;
> > +backlight = <>;
> > + };
> > +};
> I think we need an ampty line here.
> > +...
> > --
> > 2.26.2
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
Re: [PATCH] x86/hotplug: Silence APIC only after all irq's are migrated
Hi Randy
For some unknown reason my previous response said its taiting to be
delivered.
On Fri, Aug 14, 2020 at 04:25:32PM -0700, Randy Dunlap wrote:
> On 8/14/20 2:38 PM, Ashok Raj wrote:
> > When offlining CPU's, fixup_irqs() migrates all interrupts away from the
>
> CPUs,
I'll fix all these in the next rev.
Just waiting to hear back from Thomas if he has additional ones I can fix
and resend v2.
Cheers,
Ashok
>
> > outgoing CPU to an online CPU. Its always possible the device sent an
>
> It's
>
> > interrupt to the previous CPU destination. Pending interrupt bit in IRR in
> > lapic identifies such interrupts. apic_soft_disable() will not capture any
>
> LAPIC
>
> > new interrupts in IRR. This causes interrupts from device to be lost during
> > cpu offline. The issue was found when explicitly setting MSI affinity to a
>
> CPU
>
> > CPU and immediately offlining it. It was simple to recreate with a USB
> > ethernet device and doing I/O to it while the CPU is offlined. Lost
> > interrupts happen even when Interrupt Remapping is enabled.
> >
> > Current code does apic_soft_disable() before migrating interrupts.
> >
> > native_cpu_disable()
> > {
> > ...
> > apic_soft_disable();
> > cpu_disable_common();
> > --> fixup_irqs(); // Too late to capture anything in IRR.
> > }
> >
> > Just fliping the above call sequence seems to hit the IRR checks
>
>flipping
>
> > and the lost interrupt is fixed for both legacy MSI and when
> > interrupt remapping is enabled.
> >
> >
> > Fixes: 60dcaad5736f ("x86/hotplug: Silence APIC and NMI when CPU is dead")
> > Link: https://lore.kernel.org/lkml/875zdarr4h@nanos.tec.linutronix.de/
> > Signed-off-by: Ashok Raj
> >
> > To: linux-kernel@vger.kernel.org
> > To: Thomas Gleixner
> > Cc: Sukumar Ghorai
> > Cc: Srikanth Nandamuri
> > Cc: Evan Green
> > Cc: Mathias Nyman
> > Cc: Bjorn Helgaas
> > Cc: sta...@vger.kernel.org
> > ---
> > arch/x86/kernel/smpboot.c | 11 +--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> > index ffbd9a3d78d8..278cc9f92f2f 100644
> > --- a/arch/x86/kernel/smpboot.c
> > +++ b/arch/x86/kernel/smpboot.c
> > @@ -1603,13 +1603,20 @@ int native_cpu_disable(void)
> > if (ret)
> > return ret;
> >
> > + cpu_disable_common();
> > /*
> > * Disable the local APIC. Otherwise IPI broadcasts will reach
> > * it. It still responds normally to INIT, NMI, SMI, and SIPI
> > -* messages.
> > +* messages. Its important to do apic_soft_disable() after
>
>It's
>
> > +* fixup_irqs(), because fixup_irqs() called from cpu_disable_common()
> > +* depends on IRR being set. After apic_soft_disable() CPU preserves
> > +* currently set IRR/ISR but new interrupts will not set IRR.
> > +* This causes interrupts sent to outgoing cpu before completion
>
> CPU
>
> > +* of irq migration to be lost. Check SDM Vol 3 "10.4.7.2 Local
>
> IRQ
>
> > +* APIC State after It Has been Software Disabled" section for more
> > +* details.
> > */
> > apic_soft_disable();
> > - cpu_disable_common();
> >
> > return 0;
> > }
> >
>
> thanks.
> --
> ~Randy
>
Re: [kbuild-all] Re: fs/ocfs2/suballoc.c:2430:2-8: preceding lock on line 2413
On Fri, Aug 14, 2020 at 09:52:13PM +0200, Julia Lawall wrote: > > > On Fri, 14 Aug 2020, Thomas Gleixner wrote: > > > Julia, > > > > On Fri, Aug 14 2020 at 21:00, Julia Lawall wrote: > > > On Fri, 14 Aug 2020, Thomas Gleixner wrote: > > >> That's clearly a false positive. Is there anything what can be done to > > >> help that cocci script here? > > > > > > I have a better version that needs to get pushed. > > > > > > But normally these pass through me. Did you get it directly from kbuild? > > > > Yes, because I touched the affected lines last :) > > Actually, that's not the point. Normally, I get all the reports on this > case, and then I forward them if they look ok. If I forwarded something > incorrect, then sorry about that. If the policy has changed for this rule > to be sending the reports out directlty to the recipients, then I think it > should be changed back. There are a lot of real bugs with lock usage, but > there are alot of false positives too. Specifically, the rule looks for > the case with identical if tests, but only when the branches are identical > too. > > Kbuild people, can this be adjusted? Or have I misunderstood the > situation? Hi Julia and Thomas, pls allow us to check this further, usually all cocci reports will be sent to kbu...@01.org for Julia to check. But there maybe something wrong with this report. We will check the detail in next week as we have server maintainance during the weekend. > > thanks, > julia > ___ > kbuild-all mailing list -- kbuild-...@lists.01.org > To unsubscribe send an email to kbuild-all-le...@lists.01.org
Re: [Freedreno] [PATCH v10 3/5] drm/msm/dp: add support for DP PLL driver
On 8/15/20 4:20 PM, Rob Clark wrote:
On Fri, Aug 14, 2020 at 10:05 AM Dmitry Baryshkov
wrote:
On 12/08/2020 07:42, Tanmay Shah wrote:
> From: Chandan Uddaraju
>
> Add the needed DP PLL specific files to support
> display port interface on msm targets.
[skipped]
> diff --git a/drivers/gpu/drm/msm/dp/dp_pll_private.h
b/drivers/gpu/drm/msm/dp/dp_pll_private.h
> new file mode 100644
> index ..475ba6ed59ab
> --- /dev/null
> +++ b/drivers/gpu/drm/msm/dp/dp_pll_private.h
> @@ -0,0 +1,98 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) 2016-2020, The Linux Foundation. All rights reserved.
> + */
> +
> +#ifndef __DP_PLL_10NM_H
> +#define __DP_PLL_10NM_H
> +
> +#include "dp_pll.h"
> +#include "dp_reg.h"
> +
> +#define DP_VCO_HSCLK_RATE_1620MHZDIV1000162UL
> +#define DP_VCO_HSCLK_RATE_2700MHZDIV1000270UL
> +#define DP_VCO_HSCLK_RATE_5400MHZDIV1000540UL
> +#define DP_VCO_HSCLK_RATE_8100MHZDIV1000810UL
> +
> +#define NUM_DP_CLOCKS_MAX6
> +
> +#define DP_PHY_PLL_POLL_SLEEP_US500
> +#define DP_PHY_PLL_POLL_TIMEOUT_US1
> +
> +#define DP_VCO_RATE_8100MHZDIV1000810UL
> +#define DP_VCO_RATE_9720MHZDIV1000972UL
> +#define DP_VCO_RATE_10800MHZDIV10001080UL
> +
> +struct dp_pll_vco_clk {
> +struct clk_hw hw;
> +unsigned longrate;/* current vco rate */
> +u64min_rate;/* min vco rate */
> +u64max_rate;/* max vco rate */
> +void*priv;
> +};
> +
> +struct dp_pll_db {
This struct should probably go into dp_pll_10nm.c. dp_pll_7nm.c, for
example, will use slightly different structure.
Note that sboyd has a WIP series to move all of the pll code out to a
phy driver. If there is work already happening on 7nm support, it
might be better to go with the separate phy driver approach? I'm
still a bit undecided about whether to land the dp code initially with
the pll stuff in drm, and then continue refactoring to move to
separate phy driver upstream, or to strip out the pll code from the
beginning. If you/someone is working on 7nm support, then feedback
about which approach is easier is welcome.
https://lore.kernel.org/dri-devel/20200611091919.108018-1-swb...@chromium.org/
I have a sm8150/sm8250 (7nm) upstream kernel stack with DP enabled, and
I have done something similar, with the PLL driver in the QMP phy,
although not based on sboyd's series (along with some typec changes to
negotiate the DP alt mode and get HPD events, etc.). I don't think
having PLL in drm/msm makes sense, the drm/msm DP driver shouldn't need
to be aware of the DP PLL/PHY driver, it only needs to set the
link/pixel clock rates which are in dispcc (and those then have the PLL
clocks as a parent).
FYI, since it sounds you are considering landing this: it is completely
broken, for example:
- ioremap()'s to #define'd addresses in the PLL driver
- main DP driver reading/writing to registers in the PHY region, but
getting the base address from devicetree was removed since earlier
revisions, so it just fails completely. Look at usb3_dp_com (for
example), which in dp_catalog_ctrl_usb_reset() would be used to
overwrite registers already being driven by the qmp phy driver - but now
the usb3_dp_com.base is never initialized.
-Jonathan
BR,
-R
___
Freedreno mailing list
freedr...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [PATCH] genksyms: keywords: Use __restrict not _restrict
On Fri, Aug 14, 2020 at 8:06 PM Linus Torvalds wrote: > > It goes back to 2003 and the original keywords.gperf file, see > > > https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=46bd1da672d66ccd8a639d3c1f8a166048cca608 Interesting, I was wondering why upstream development on genksyms had stopped a long time ago. That commit provides more context. -- Thanks, ~Nick Desaulniers
Re: [GIT PULL] edac for v5.9 (part 2)
On Sat, Aug 15, 2020 at 08:21:13AM -0700, Linus Torvalds wrote: > On Fri, Aug 14, 2020 at 5:36 PM Luck, Tony wrote: > > > > Here's one more pull for EDAC with a driver that I let slip > > through the cracks. > > Shortlog? Diffstat? Just what am I getting? Ah. Looking at bash history I fumbled arguments to git pleasepull. Second try: The following changes since commit 0f959e19fadf00638b686fdeb70e24dfcc7bbcac: Merge branch 'edac-ghes' into edac-for-next (2020-06-22 15:28:01 +0200) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git tags/edac_updates_for_5.9_pt2 for you to fetch changes up to 709ed1bcef12398ac1a35c149f3e582db04456c2: EDAC/ie31200: Fallback if host bridge device is already initialized (2020-08-10 11:13:06 -0700) Fixes for ie31200 driver that missed the first pull Jason Baron (1): EDAC/ie31200: Fallback if host bridge device is already initialized drivers/edac/ie31200_edac.c | 50 ++--- 1 file changed, 47 insertions(+), 3 deletions(-) -Tony
[PATCH v4 3/6] x86/paravirt: use CONFIG_PARAVIRT_XXL instead of CONFIG_PARAVIRT
There are some code parts using CONFIG_PARAVIRT for Xen pvops related
issues instead of the more stringent CONFIG_PARAVIRT_XXL.
Signed-off-by: Juergen Gross
---
arch/x86/entry/entry_64.S| 4 ++--
arch/x86/include/asm/fixmap.h| 2 +-
arch/x86/include/asm/required-features.h | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 70dea9337816..26fc9b42fadc 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -46,13 +46,13 @@
.code64
.section .entry.text, "ax"
-#ifdef CONFIG_PARAVIRT
+#ifdef CONFIG_PARAVIRT_XXL
SYM_CODE_START(native_usergs_sysret64)
UNWIND_HINT_EMPTY
swapgs
sysretq
SYM_CODE_END(native_usergs_sysret64)
-#endif /* CONFIG_PARAVIRT */
+#endif /* CONFIG_PARAVIRT_XXL */
/*
* 64-bit SYSCALL instruction entry. Up to 6 arguments in registers.
diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index 0f0dd645b594..77217bd292bd 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -99,7 +99,7 @@ enum fixed_addresses {
FIX_PCIE_MCFG,
#endif
#endif
-#ifdef CONFIG_PARAVIRT
+#ifdef CONFIG_PARAVIRT_XXL
FIX_PARAVIRT_BOOTMAP,
#endif
#ifdef CONFIG_X86_INTEL_MID
diff --git a/arch/x86/include/asm/required-features.h
b/arch/x86/include/asm/required-features.h
index 6847d85400a8..3ff0d48469f2 100644
--- a/arch/x86/include/asm/required-features.h
+++ b/arch/x86/include/asm/required-features.h
@@ -54,7 +54,7 @@
#endif
#ifdef CONFIG_X86_64
-#ifdef CONFIG_PARAVIRT
+#ifdef CONFIG_PARAVIRT_XXL
/* Paravirtualized systems may not have PSE or PGE available */
#define NEED_PSE 0
#define NEED_PGE 0
--
2.26.2
[PATCH v4 5/6] x86/paravirt: remove set_pte_at pv-op
On x86 set_pte_at() is now always falling back to set_pte(). So instead
of having this fallback after the paravirt maze just drop the
set_pte_at paravirt operation and let set_pte_at() use the set_pte()
function directly.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt.h | 8 +---
arch/x86/include/asm/paravirt_types.h | 2 --
arch/x86/include/asm/pgtable.h| 7 +++
arch/x86/kernel/paravirt.c| 1 -
arch/x86/xen/mmu_pv.c | 8
include/trace/events/xen.h| 20
6 files changed, 4 insertions(+), 42 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index e02c409fa054..f0464b88ea1e 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -412,12 +412,6 @@ static inline void set_pte(pte_t *ptep, pte_t pte)
PVOP_VCALL2(mmu.set_pte, ptep, pte.pte);
}
-static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
- pte_t *ptep, pte_t pte)
-{
- PVOP_VCALL4(mmu.set_pte_at, mm, addr, ptep, pte.pte);
-}
-
static inline void set_pmd(pmd_t *pmdp, pmd_t pmd)
{
PVOP_VCALL2(mmu.set_pmd, pmdp, native_pmd_val(pmd));
@@ -510,7 +504,7 @@ static inline void set_pte_atomic(pte_t *ptep, pte_t pte)
static inline void pte_clear(struct mm_struct *mm, unsigned long addr,
pte_t *ptep)
{
- set_pte_at(mm, addr, ptep, __pte(0));
+ set_pte(ptep, __pte(0));
}
static inline void pmd_clear(pmd_t *pmdp)
diff --git a/arch/x86/include/asm/paravirt_types.h
b/arch/x86/include/asm/paravirt_types.h
index f27c3febaa6e..0fad9f61c76a 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -242,8 +242,6 @@ struct pv_mmu_ops {
/* Pagetable manipulation functions */
void (*set_pte)(pte_t *ptep, pte_t pteval);
- void (*set_pte_at)(struct mm_struct *mm, unsigned long addr,
- pte_t *ptep, pte_t pteval);
void (*set_pmd)(pmd_t *pmdp, pmd_t pmdval);
pte_t (*ptep_modify_prot_start)(struct vm_area_struct *vma, unsigned
long addr,
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index b836138ce852..7414b416779b 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -63,7 +63,6 @@ extern pmdval_t early_pmd_flags;
#include
#else /* !CONFIG_PARAVIRT_XXL */
#define set_pte(ptep, pte) native_set_pte(ptep, pte)
-#define set_pte_at(mm, addr, ptep, pte)native_set_pte_at(mm, addr,
ptep, pte)
#define set_pte_atomic(ptep, pte) \
native_set_pte_atomic(ptep, pte)
@@ -1033,10 +1032,10 @@ static inline pud_t
native_local_pudp_get_and_clear(pud_t *pudp)
return res;
}
-static inline void native_set_pte_at(struct mm_struct *mm, unsigned long addr,
-pte_t *ptep , pte_t pte)
+static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
+ pte_t *ptep, pte_t pte)
{
- native_set_pte(ptep, pte);
+ set_pte(ptep, pte);
}
static inline void set_pmd_at(struct mm_struct *mm, unsigned long addr,
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index e56a144c13b3..6c3407ba6ee9 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -360,7 +360,6 @@ struct paravirt_patch_template pv_ops = {
.mmu.release_p4d= paravirt_nop,
.mmu.set_pte= native_set_pte,
- .mmu.set_pte_at = native_set_pte_at,
.mmu.set_pmd= native_set_pmd,
.mmu.ptep_modify_prot_start = __ptep_modify_prot_start,
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 3273c985d3dd..eda78144c000 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -285,13 +285,6 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval)
__xen_set_pte(ptep, pteval);
}
-static void xen_set_pte_at(struct mm_struct *mm, unsigned long addr,
- pte_t *ptep, pte_t pteval)
-{
- trace_xen_mmu_set_pte_at(mm, addr, ptep, pteval);
- __xen_set_pte(ptep, pteval);
-}
-
pte_t xen_ptep_modify_prot_start(struct vm_area_struct *vma,
unsigned long addr, pte_t *ptep)
{
@@ -2105,7 +2098,6 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
.release_pmd = xen_release_pmd_init,
.set_pte = xen_set_pte_init,
- .set_pte_at = xen_set_pte_at,
.set_pmd = xen_set_pmd_hyper,
.ptep_modify_prot_start = __ptep_modify_prot_start,
diff --git a/include/trace/events/xen.h b/include/trace/events/xen.h
index a5ccfa67bc5c..3b61b587e137 100644
--- a/include/trace/events/xen.h
+++ b/include/trace/events/xen.h
@@ -153,26 +153,6 @@ DECLARE_EVENT_CLASS(xen_mmu__set_pte,
Re: [PATCH] fs: NTFS read-write driver GPL implementation by Paragon Software.
On Fri, Aug 14, 2020 at 12:29:01PM +, Konstantin Komarov wrote: > This patch adds NTFS Read-Write driver to fs/ntfs3. > > Having decades of expertise in commercial file systems development and huge > test coverage, we at Paragon Software GmbH want to make our contribution to > the Open Source Community by providing implementation of NTFS Read-Write > driver for the Linux Kernel. > > This is fully functional NTFS Read-Write driver. Current version works with > NTFS(including v3.1) normal/compressed/sparse files and supports journal > replaying. > > We plan to support this version after the codebase once merged, and add new > features and fix bugs. For example, full journaling support over JBD will be > added in later updates. > > The patch is too big to handle it within an e-mail body, so it is available > to download > on our server: https://dl.paragon-software.com/ntfs3/ntfs3.patch The way you submit the driver does not meet significant number of requirements documented in https://www.kernel.org/doc/html/latest/process/submitting-patches.html . so this may lead to ignoring the patch as this puts the burden on the kernel community to make the merge somehow happen. I don't see kernel involvement from Paragon, so let me build our half of the bridge. As I reckon, there is interest to have NTFS implementation that's better than the existing FUSE based support by NTFS-3G (namely performance), so let me propose something that might lead to merging the patch eventually. 1. check existing support in kernel There is fs/ntfs with read-only support from Tuxera, last change in the git tree is 3 years ago. The driver lacks read-write support so there's not 100% functionality duplication but there's still driver for the same filesystem. I don't know what's the feature parity, how much the in-kernel driver is used (or what are business relations of Tuxera and Paragon), compared to the FUSE-based driver, but ideally there's just one NTFS driver in linux kernel. The question I'd ask: - what are users of current fs/ntfs driver going to lose, if the driver is going to be completely replaced by your driver If the answer is 'nothing' then, the straightfowrad plan is to just replace it. Otherwise, we'll have to figure that out. 2. split the patch One patch of 27k lines of code is way too much to anybody to look at. As an example, what worked for the recent EXFAT support, send each new file as a patch. This will pass the mailinglist size filters and keep the patches logically separated, so eg. there are smaller patches implementing interaction with VFS (on the inode or directory level) and leaving out the other internal stuff of the filesystem. I'm counting about 20 files, that's acceptable. The last patch, or maybe a separate patch, adds the actual build and config-time support. The situation is a bit more complicated as there's an existing driver and I don't see a clear way how to do the transition from 2 implementations (one intermediate) to just one in the final state. We have that already with the old VFAT and new EXFAT drivers, and it's solved on the module level. Just one can be loaded (AFAIK). The same could be done here but it puts some burden on users to know what driver to load to get the expected set of features. 3. determine support status You state intentions to work on the driver and there's a new entry in MAINTAINERS file with 'Supported', so that's a good sign that it's not just one-time dump of code. Fixing bugs or adding functionality is expected. 4. development git tree Once the filesystem is merged, you'd be getting mails from people running eg. static checkers, build tests, sending cleanups or other tree-wide changes. The entry in MAINTAINER file does not point to any git tree, so that's not clear to me what's the expected way to get the fixes to Linus' tree or where are people supposed to look for 'is this fixed already'. There's maybe more I missed, but hopefully HTH. d.
[PATCH v4 4/6] x86/entry/32: revert "Fix XEN_PV build dependency"
With 32-bit Xen PV support gone commit a4c0e91d1d65bc58
("x86/entry/32: Fix XEN_PV build dependency") can be reverted again.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/idtentry.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/idtentry.h b/arch/x86/include/asm/idtentry.h
index a43366191212..337dcfd45472 100644
--- a/arch/x86/include/asm/idtentry.h
+++ b/arch/x86/include/asm/idtentry.h
@@ -547,7 +547,7 @@ DECLARE_IDTENTRY_RAW(X86_TRAP_MC, exc_machine_check);
/* NMI */
DECLARE_IDTENTRY_NMI(X86_TRAP_NMI, exc_nmi);
-#if defined(CONFIG_XEN_PV) && defined(CONFIG_X86_64)
+#ifdef CONFIG_XEN_PV
DECLARE_IDTENTRY_RAW(X86_TRAP_NMI, xenpv_exc_nmi);
#endif
@@ -557,7 +557,7 @@ DECLARE_IDTENTRY_DEBUG(X86_TRAP_DB, exc_debug);
#else
DECLARE_IDTENTRY_RAW(X86_TRAP_DB, exc_debug);
#endif
-#if defined(CONFIG_XEN_PV) && defined(CONFIG_X86_64)
+#ifdef CONFIG_XEN_PV
DECLARE_IDTENTRY_RAW(X86_TRAP_DB, xenpv_exc_debug);
#endif
--
2.26.2
[PATCH v4 2/6] x86/paravirt: cleanup paravirt macros
Some paravirt macros are no longer used, delete them. Signed-off-by: Juergen Gross --- arch/x86/include/asm/paravirt.h | 15 --- 1 file changed, 15 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index 25c7a73461f6..e02c409fa054 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -586,16 +586,9 @@ bool __raw_callee_save___native_vcpu_is_preempted(long cpu); #endif /* SMP && PARAVIRT_SPINLOCKS */ #ifdef CONFIG_X86_32 -#define PV_SAVE_REGS "pushl %ecx; pushl %edx;" -#define PV_RESTORE_REGS "popl %edx; popl %ecx;" - /* save and restore all caller-save registers, except return value */ #define PV_SAVE_ALL_CALLER_REGS"pushl %ecx;" #define PV_RESTORE_ALL_CALLER_REGS "popl %ecx;" - -#define PV_FLAGS_ARG "0" -#define PV_EXTRA_CLOBBERS -#define PV_VEXTRA_CLOBBERS #else /* save and restore all caller-save registers, except return value */ #define PV_SAVE_ALL_CALLER_REGS \ @@ -616,14 +609,6 @@ bool __raw_callee_save___native_vcpu_is_preempted(long cpu); "pop %rsi;" \ "pop %rdx;" \ "pop %rcx;" - -/* We save some registers, but all of them, that's too much. We clobber all - * caller saved registers but the argument parameter */ -#define PV_SAVE_REGS "pushq %%rdi;" -#define PV_RESTORE_REGS "popq %%rdi;" -#define PV_EXTRA_CLOBBERS EXTRA_CLOBBERS, "rcx" , "rdx", "rsi" -#define PV_VEXTRA_CLOBBERS EXTRA_CLOBBERS, "rdi", "rcx" , "rdx", "rsi" -#define PV_FLAGS_ARG "D" #endif /* -- 2.26.2
[PATCH v4 0/6] x86/paravirt: cleanup after 32-bit PV removal
A lot of cleanup after removal of 32-bit Xen PV guest support in paravirt code. Changes in V4: - dropped patches 1-3, as already committed - addressed comments to V3 - added new patches 5+6 Changes in V3: - addressed comments to V2 - split patch 1 into 2 patches - new patches 3 and 7 Changes in V2: - rebase to 5.8 kernel - addressed comments to V1 - new patches 3 and 4 Juergen Gross (6): x86/paravirt: remove 32-bit support from PARAVIRT_XXL x86/paravirt: cleanup paravirt macros x86/paravirt: use CONFIG_PARAVIRT_XXL instead of CONFIG_PARAVIRT x86/entry/32: revert "Fix XEN_PV build dependency" x86/paravirt: remove set_pte_at pv-op x86/paravirt: avoid needless paravirt step clearing page table entries arch/x86/entry/entry_64.S | 4 +- arch/x86/entry/vdso/vdso32/vclock_gettime.c | 1 + arch/x86/include/asm/fixmap.h | 2 +- arch/x86/include/asm/idtentry.h | 4 +- arch/x86/include/asm/paravirt.h | 151 +++- arch/x86/include/asm/paravirt_types.h | 23 --- arch/x86/include/asm/pgtable-3level_types.h | 5 - arch/x86/include/asm/pgtable.h | 7 +- arch/x86/include/asm/required-features.h| 2 +- arch/x86/include/asm/segment.h | 4 - arch/x86/kernel/cpu/common.c| 8 -- arch/x86/kernel/kprobes/core.c | 1 - arch/x86/kernel/kprobes/opt.c | 1 - arch/x86/kernel/paravirt.c | 19 --- arch/x86/kernel/paravirt_patch.c| 17 --- arch/x86/xen/enlighten_pv.c | 6 - arch/x86/xen/mmu_pv.c | 8 -- include/trace/events/xen.h | 20 --- 18 files changed, 27 insertions(+), 256 deletions(-) -- 2.26.2
[PATCH v4 6/6] x86/paravirt: avoid needless paravirt step clearing page table entries
pte_clear() et al are based on tw0 paravirt steps today: one step to
create a page table entry with all zeroes, and one step to write this
entry value.
Drop the first step as it is completely useless.
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/paravirt.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index f0464b88ea1e..d25cc6830e89 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -448,7 +448,7 @@ static inline pudval_t pud_val(pud_t pud)
static inline void pud_clear(pud_t *pudp)
{
- set_pud(pudp, __pud(0));
+ set_pud(pudp, native_make_pud(0));
}
static inline void set_p4d(p4d_t *p4dp, p4d_t p4d)
@@ -485,15 +485,15 @@ static inline void __set_pgd(pgd_t *pgdp, pgd_t pgd)
} while (0)
#define pgd_clear(pgdp) do { \
- if (pgtable_l5_enabled())
\
- set_pgd(pgdp, __pgd(0));\
+ if (pgtable_l5_enabled()) \
+ set_pgd(pgdp, native_make_pgd(0)); \
} while (0)
#endif /* CONFIG_PGTABLE_LEVELS == 5 */
static inline void p4d_clear(p4d_t *p4dp)
{
- set_p4d(p4dp, __p4d(0));
+ set_p4d(p4dp, native_make_p4d(0));
}
static inline void set_pte_atomic(pte_t *ptep, pte_t pte)
@@ -504,12 +504,12 @@ static inline void set_pte_atomic(pte_t *ptep, pte_t pte)
static inline void pte_clear(struct mm_struct *mm, unsigned long addr,
pte_t *ptep)
{
- set_pte(ptep, __pte(0));
+ set_pte(ptep, native_make_pte(0));
}
static inline void pmd_clear(pmd_t *pmdp)
{
- set_pmd(pmdp, __pmd(0));
+ set_pmd(pmdp, native_make_pmd(0));
}
#define __HAVE_ARCH_START_CONTEXT_SWITCH
--
2.26.2
[PATCH v4 1/6] x86/paravirt: remove 32-bit support from PARAVIRT_XXL
The last 32-bit user of stuff under CONFIG_PARAVIRT_XXL is gone.
Remove 32-bit specific parts.
Signed-off-by: Juergen Gross
---
arch/x86/entry/vdso/vdso32/vclock_gettime.c | 1 +
arch/x86/include/asm/paravirt.h | 120 ++--
arch/x86/include/asm/paravirt_types.h | 21
arch/x86/include/asm/pgtable-3level_types.h | 5 -
arch/x86/include/asm/segment.h | 4 -
arch/x86/kernel/cpu/common.c| 8 --
arch/x86/kernel/kprobes/core.c | 1 -
arch/x86/kernel/kprobes/opt.c | 1 -
arch/x86/kernel/paravirt.c | 18 ---
arch/x86/kernel/paravirt_patch.c| 17 ---
arch/x86/xen/enlighten_pv.c | 6 -
11 files changed, 13 insertions(+), 189 deletions(-)
diff --git a/arch/x86/entry/vdso/vdso32/vclock_gettime.c
b/arch/x86/entry/vdso/vdso32/vclock_gettime.c
index 84a4a73f77f7..283ed9d00426 100644
--- a/arch/x86/entry/vdso/vdso32/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vdso32/vclock_gettime.c
@@ -14,6 +14,7 @@
#undef CONFIG_ILLEGAL_POINTER_VALUE
#undef CONFIG_SPARSEMEM_VMEMMAP
#undef CONFIG_NR_CPUS
+#undef CONFIG_PARAVIRT_XXL
#define CONFIG_X86_32 1
#define CONFIG_PGTABLE_LEVELS 2
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 3d2afecde50c..25c7a73461f6 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -160,8 +160,6 @@ static inline void wbinvd(void)
PVOP_VCALL0(cpu.wbinvd);
}
-#define get_kernel_rpl() (pv_info.kernel_rpl)
-
static inline u64 paravirt_read_msr(unsigned msr)
{
return PVOP_CALL1(u64, cpu.read_msr, msr);
@@ -277,12 +275,10 @@ static inline void load_TLS(struct thread_struct *t,
unsigned cpu)
PVOP_VCALL2(cpu.load_tls, t, cpu);
}
-#ifdef CONFIG_X86_64
static inline void load_gs_index(unsigned int gs)
{
PVOP_VCALL1(cpu.load_gs_index, gs);
}
-#endif
static inline void write_ldt_entry(struct desc_struct *dt, int entry,
const void *desc)
@@ -375,52 +371,22 @@ static inline void paravirt_release_p4d(unsigned long pfn)
static inline pte_t __pte(pteval_t val)
{
- pteval_t ret;
-
- if (sizeof(pteval_t) > sizeof(long))
- ret = PVOP_CALLEE2(pteval_t, mmu.make_pte, val, (u64)val >> 32);
- else
- ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val);
-
- return (pte_t) { .pte = ret };
+ return (pte_t) { PVOP_CALLEE1(pteval_t, mmu.make_pte, val) };
}
static inline pteval_t pte_val(pte_t pte)
{
- pteval_t ret;
-
- if (sizeof(pteval_t) > sizeof(long))
- ret = PVOP_CALLEE2(pteval_t, mmu.pte_val,
- pte.pte, (u64)pte.pte >> 32);
- else
- ret = PVOP_CALLEE1(pteval_t, mmu.pte_val, pte.pte);
-
- return ret;
+ return PVOP_CALLEE1(pteval_t, mmu.pte_val, pte.pte);
}
static inline pgd_t __pgd(pgdval_t val)
{
- pgdval_t ret;
-
- if (sizeof(pgdval_t) > sizeof(long))
- ret = PVOP_CALLEE2(pgdval_t, mmu.make_pgd, val, (u64)val >> 32);
- else
- ret = PVOP_CALLEE1(pgdval_t, mmu.make_pgd, val);
-
- return (pgd_t) { ret };
+ return (pgd_t) { PVOP_CALLEE1(pgdval_t, mmu.make_pgd, val) };
}
static inline pgdval_t pgd_val(pgd_t pgd)
{
- pgdval_t ret;
-
- if (sizeof(pgdval_t) > sizeof(long))
- ret = PVOP_CALLEE2(pgdval_t, mmu.pgd_val,
- pgd.pgd, (u64)pgd.pgd >> 32);
- else
- ret = PVOP_CALLEE1(pgdval_t, mmu.pgd_val, pgd.pgd);
-
- return ret;
+ return PVOP_CALLEE1(pgdval_t, mmu.pgd_val, pgd.pgd);
}
#define __HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION
@@ -438,78 +404,40 @@ static inline void ptep_modify_prot_commit(struct
vm_area_struct *vma, unsigned
pte_t *ptep, pte_t old_pte, pte_t
pte)
{
- if (sizeof(pteval_t) > sizeof(long))
- /* 5 arg words */
- pv_ops.mmu.ptep_modify_prot_commit(vma, addr, ptep, pte);
- else
- PVOP_VCALL4(mmu.ptep_modify_prot_commit,
- vma, addr, ptep, pte.pte);
+ PVOP_VCALL4(mmu.ptep_modify_prot_commit, vma, addr, ptep, pte.pte);
}
static inline void set_pte(pte_t *ptep, pte_t pte)
{
- if (sizeof(pteval_t) > sizeof(long))
- PVOP_VCALL3(mmu.set_pte, ptep, pte.pte, (u64)pte.pte >> 32);
- else
- PVOP_VCALL2(mmu.set_pte, ptep, pte.pte);
+ PVOP_VCALL2(mmu.set_pte, ptep, pte.pte);
}
static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
pte_t *ptep, pte_t pte)
{
- if (sizeof(pteval_t) > sizeof(long))
- /* 5 arg words */
- pv_ops.mmu.set_pte_at(mm, addr, ptep, pte);
- else
- PVOP_VCALL4(mmu.set_pte_at, mm, addr, ptep, pte.pte);
+
Re: [PATCH 2/3] dt-bindings: Add Mantix MLAF057WE51-X panel bindings
Hi Guido.
On Sat, Aug 15, 2020 at 06:47:37PM +0200, Guido Günther wrote:
> Hi Sam,
> On Sat, Aug 15, 2020 at 10:39:17AM +0200, Sam Ravnborg wrote:
> > Hi Guido.
> >
> > On Fri, Aug 14, 2020 at 03:36:22PM +0200, Guido Günther wrote:
> > > The panel uses a Focaltech FT8006p, the touch part is handled by the
> > > already existing edt-ft5x06.
> > >
> > > Signed-off-by: Guido Günther
> >
> > A few trivialities.
>
> Thanks for having a look. One remark inline:
>
> >
> > > ---
> > > .../display/panel/mantix,mlaf057we51-x.yaml | 73 +++
> > > 1 file changed, 73 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> > >
> > > b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> > > new file mode 100644
> > > index 0..349f3380ac940
> > > --- /dev/null
> > > +++
> > > b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml
> > > @@ -0,0 +1,73 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id:
> > > http://devicetree.org/schemas/display/panel/mantix,mlaf057we51-x.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Mantix MLAF057WE51-X 5.7" 720x1440 TFT LCD panel
> > > +
> > > +maintainers:
> > > + - Guido Günther
> > > +
> > > +description: |
> > > + Mantix MLAF057WE51 X is a 720x1440 TFT LCD panel
> > > + connected using a MIPI-DSI video interface.
> > Indent text with two spaces only.
> > And I have learned that '|' is only needed to preserve formatting - so
> > it can be dropped.
> >
> > > +
> > > +allOf:
> > > + - $ref: panel-common.yaml#
> > > +
> > > +properties:
> > > + compatible:
> > > +enum:
> > > + - mantix,mlaf057we51-x
> > This is a list - so needs an extra 2 spaces indent.
> > See
> > https://lore.kernel.org/linux-devicetree/f1963eb9-283f-e903-2a3a-4f324d71d...@lucaceresoli.net/T/#m65900317fb948f6c40e8fb521f2201fba3c301a7
> > for examples where Rob fixes this.
>
> Doesn't this only apply if the 'outer element' is a list too so e.g.:
>
>- enum
> - foo
>
> trips up yamllint but
>
>enum
> - foo
>
> doesn't. Since yamllint was happy i kept it as is (looking at your
> reference suggests that too).
You are right, I missed that this was not a list (no '-' in front of
enum).
I would not be able to do this right without tool assistance.
Sam
>
> All the rest made sense and i fixed that for the upcoming v2.
> Thanks for having a look!
> -- Guido
>
> >
> > > +
> > > + port: true
> > > + reg:
> > > +maxItems: 1
> > > +description: DSI virtual channel
> > > +
> > > + avdd-supply:
> > > +description: Positive analog power supply
> > > +
> > > + avee-supply:
> > > +description: Negative analog power supply
> > > +
> > > + vddi-supply:
> > > +description: 1.8V I/O voltage supply
> > > +
> > > + reset-gpios:
> > > +description: GPIO used for the reset pin
> > > +maxItems: 1
> > Use reset-gpios: true as we already have it in panel-common.yaml
> >
> > > +
> > > + backlight:
> > > +description: Backlight used by the panel
> > > +$ref: "/schemas/types.yaml#/definitions/phandle"
> > Use backlight from panel-common.yaml.
> >
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - avdd-supply
> > > + - avee-supply
> > > + - vddi-supply
> > > + - reset-gpios
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > + - |
> > > +#include
> > > +
> > > +dsi {
> > My personal preference is indent with 4 spaces in examples but there are
> > no rules so feel free to ignore.
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + panel@0 {
> > > +compatible = "mantix,mlaf057we51-x";
> > > +reg = <0>;
> > > +avdd-supply = <_avdd>;
> > > +avee-supply = <_avee>;
> > > +vddi-supply = <_1v8_p>;
> > > +reset-gpios = < 29 GPIO_ACTIVE_LOW>;
> > > +backlight = <>;
> > > + };
> > > +};
> > I think we need an ampty line here.
> > > +...
> > > --
> > > 2.26.2
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-de...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
Re: [PATCH v2] x86/boot/compressed: Disable relocation relaxation
On Sat, Aug 15, 2020 at 10:57 PM Nick Desaulniers wrote: > > Hi Ingo, > I saw you picked up Arvind's other series into x86/boot. Would you > mind please including this, as well? Our CI is quite red for x86... > > EOM > +1 - Sedat - > On Sat, Aug 15, 2020 at 8:49 AM Sedat Dilek wrote: > > > > On Wed, Aug 12, 2020 at 2:43 AM Arvind Sankar wrote: > > > > > > The x86-64 psABI [0] specifies special relocation types > > > (R_X86_64_[REX_]GOTPCRELX) for indirection through the Global Offset > > > Table, semantically equivalent to R_X86_64_GOTPCREL, which the linker > > > can take advantage of for optimization (relaxation) at link time. This > > > is supported by LLD and binutils versions 2.26 onwards. > > > > > > The compressed kernel is position-independent code, however, when using > > > LLD or binutils versions before 2.27, it must be linked without the -pie > > > option. In this case, the linker may optimize certain instructions into > > > a non-position-independent form, by converting foo@GOTPCREL(%rip) to $foo. > > > > > > This potential issue has been present with LLD and binutils-2.26 for a > > > long time, but it has never manifested itself before now: > > > - LLD and binutils-2.26 only relax > > > movqfoo@GOTPCREL(%rip), %reg > > > to > > > leaqfoo(%rip), %reg > > > which is still position-independent, rather than > > > mov $foo, %reg > > > which is permitted by the psABI when -pie is not enabled. > > > - gcc happens to only generate GOTPCREL relocations on mov instructions. > > > - clang does generate GOTPCREL relocations on non-mov instructions, but > > > when building the compressed kernel, it uses its integrated assembler > > > (due to the redefinition of KBUILD_CFLAGS dropping -no-integrated-as), > > > which has so far defaulted to not generating the GOTPCRELX > > > relocations. > > > > > > Nick Desaulniers reports [1,2]: > > > A recent change [3] to a default value of configuration variable > > > (ENABLE_X86_RELAX_RELOCATIONS OFF -> ON) in LLVM now causes Clang's > > > integrated assembler to emit R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX > > > relocations. LLD will relax instructions with these relocations based > > > on whether the image is being linked as position independent or not. > > > When not, then LLD will relax these instructions to use absolute > > > addressing mode (R_RELAX_GOT_PC_NOPIC). This causes kernels built with > > > Clang and linked with LLD to fail to boot. > > > > > > Patch series [4] is a solution to allow the compressed kernel to be > > > linked with -pie unconditionally, but even if merged is unlikely to be > > > backported. As a simple solution that can be applied to stable as well, > > > prevent the assembler from generating the relaxed relocation types using > > > the -mrelax-relocations=no option. For ease of backporting, do this > > > unconditionally. > > > > > > [0] > > > https://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/master/x86-64-ABI/linker-optimization.tex#L65 > > > [1] > > > https://lore.kernel.org/lkml/20200807194100.3570838-1-ndesaulni...@google.com/ > > > [2] https://github.com/ClangBuiltLinux/linux/issues/1121 > > > [3] https://reviews.llvm.org/rGc41a18cf61790fc898dcda1055c3efbf442c14c0 > > > [4] > > > https://lore.kernel.org/lkml/20200731202738.2577854-1-nived...@alum.mit.edu/ > > > > > > Signed-off-by: Arvind Sankar > > > Reported-by: Nick Desaulniers > > > Reviewed-by: Nick Desaulniers > > > Tested-by: Nick Desaulniers > > > Cc: sta...@vger.kernel.org > > > Signed-off-by: Arvind Sankar > > > > Thanks for the patch. > > > > Tested-by: Sedat Dilek > > > > - Sedat - > > > > [1] > > https://github.com/ClangBuiltLinux/linux/issues/1120#issuecomment-674409705 > > > > > --- > > > arch/x86/boot/compressed/Makefile | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/arch/x86/boot/compressed/Makefile > > > b/arch/x86/boot/compressed/Makefile > > > index 3962f592633d..ff7894f39e0e 100644 > > > --- a/arch/x86/boot/compressed/Makefile > > > +++ b/arch/x86/boot/compressed/Makefile > > > @@ -43,6 +43,8 @@ KBUILD_CFLAGS += -Wno-pointer-sign > > > KBUILD_CFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=) > > > KBUILD_CFLAGS += -fno-asynchronous-unwind-tables > > > KBUILD_CFLAGS += -D__DISABLE_EXPORTS > > > +# Disable relocation relaxation in case the link is not PIE. > > > +KBUILD_CFLAGS += $(call as-option,-Wa$(comma)-mrelax-relocations=no) > > > > > > KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ > > > GCOV_PROFILE := n > > > -- > > > 2.26.2 > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Clang Built Linux" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to clang-built-linux+unsubscr...@googlegroups.com. > > > To view this discussion on the web visit > > >
Re: [PATCH v10 3/5] drm/msm/dp: add support for DP PLL driver
On Fri, Aug 14, 2020 at 10:05 AM Dmitry Baryshkov
wrote:
>
>
> On 12/08/2020 07:42, Tanmay Shah wrote:
> > From: Chandan Uddaraju
> >
> > Add the needed DP PLL specific files to support
> > display port interface on msm targets.
>
> [skipped]
>
> > diff --git a/drivers/gpu/drm/msm/dp/dp_pll_private.h
> b/drivers/gpu/drm/msm/dp/dp_pll_private.h
> > new file mode 100644
> > index ..475ba6ed59ab
> > --- /dev/null
> > +++ b/drivers/gpu/drm/msm/dp/dp_pll_private.h
> > @@ -0,0 +1,98 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * Copyright (c) 2016-2020, The Linux Foundation. All rights reserved.
> > + */
> > +
> > +#ifndef __DP_PLL_10NM_H
> > +#define __DP_PLL_10NM_H
> > +
> > +#include "dp_pll.h"
> > +#include "dp_reg.h"
> > +
> > +#define DP_VCO_HSCLK_RATE_1620MHZDIV1000162UL
> > +#define DP_VCO_HSCLK_RATE_2700MHZDIV1000270UL
> > +#define DP_VCO_HSCLK_RATE_5400MHZDIV1000540UL
> > +#define DP_VCO_HSCLK_RATE_8100MHZDIV1000810UL
> > +
> > +#define NUM_DP_CLOCKS_MAX6
> > +
> > +#define DP_PHY_PLL_POLL_SLEEP_US500
> > +#define DP_PHY_PLL_POLL_TIMEOUT_US1
> > +
> > +#define DP_VCO_RATE_8100MHZDIV1000810UL
> > +#define DP_VCO_RATE_9720MHZDIV1000972UL
> > +#define DP_VCO_RATE_10800MHZDIV10001080UL
> > +
> > +struct dp_pll_vco_clk {
> > +struct clk_hw hw;
> > +unsigned longrate;/* current vco rate */
> > +u64min_rate;/* min vco rate */
> > +u64max_rate;/* max vco rate */
> > +void*priv;
> > +};
> > +
> > +struct dp_pll_db {
>
> This struct should probably go into dp_pll_10nm.c. dp_pll_7nm.c, for
> example, will use slightly different structure.
Note that sboyd has a WIP series to move all of the pll code out to a
phy driver. If there is work already happening on 7nm support, it
might be better to go with the separate phy driver approach? I'm
still a bit undecided about whether to land the dp code initially with
the pll stuff in drm, and then continue refactoring to move to
separate phy driver upstream, or to strip out the pll code from the
beginning. If you/someone is working on 7nm support, then feedback
about which approach is easier is welcome.
https://lore.kernel.org/dri-devel/20200611091919.108018-1-swb...@chromium.org/
BR,
-R
[PATCH 1/2] dt-bindings: arm: fsl: add compatible string for Tolino Shine 2 HD
This adds a compatible string for the Tolino Shine 2 HD eBook reader. Signed-off-by: Andreas Kemnade --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 05906e291e38..a3fb61868a16 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -211,6 +211,7 @@ properties: items: - enum: - fsl,imx6sl-evk# i.MX6 SoloLite EVK Board + - kobo,tolino-shine2hd - kobo,tolino-shine3 - const: fsl,imx6sl -- 2.20.1
[PATCH v5 0/6] CTU CAN FD open-source IP core SocketCAN driver, PCI, platform integration and documentation
From: Pavel Pisa This driver adds support for the CTU CAN FD open-source IP core. More documentation and core sources at project page (https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core). The core integration to Xilinx Zynq system as platform driver is available (https://gitlab.fel.cvut.cz/canbus/zynq/zynq-can-sja1000-top). Implementation on Intel FPGA based PCI Express board is available from project (https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd). The CTU CAN FD core emulation send for review for QEMU mainline. Development repository for QEMU emulation - ctu-canfd branch of https://gitlab.fel.cvut.cz/canbus/qemu-canbus More about CAN bus related projects used and developed at CTU FEE on the guidepost page http://canbus.pages.fel.cvut.cz/ . Martin Jerabek (1): can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part. Pavel Pisa (5): dt-bindings: vendor-prefix: add prefix for the Czech Technical University in Prague. dt-bindings: net: can: binding for CTU CAN FD open-source IP core. can: ctucanfd: CTU CAN FD open-source IP core - PCI bus support. can: ctucanfd: CTU CAN FD open-source IP core - platform/SoC support. docs: ctucanfd: CTU CAN FD open-source IP core documentation. The version 5 changes: - sent at 2020-08-15 - correct Kconfig formatting according to Randy Dunlap - silence warnings reported by make W=1 C=1 flags. Changes suggested by Jakub Kicinski - big thanks for core patch review by Pavel Machek resulting in more readability and formating updates - fix power management errors found by Pavel Machek - removed comments from d-t bindings as suggested by Rob Herring - selected ctu,ctucanfd-2 as alternative name to ctu,ctucanfd which allows to bind to actual major HDL core sources version 2.x if for some reason driver adaptation would not work on version read from the core - line length limit relaxed to 100 characters on some cases where it helps to readability The version 4 changes: - sent at 2020-08-04 - changes summary, 169 non-merge commits, 6 driver, 32 IP core sources enhancements and fixes, 58 tests in master and about additional 30 iso-testbench preparation branch. - convert device-tree binding documentation to YAML - QEMU model of CTU CAN FD IP core and generic extension of QEMU CAN bus emulation developed by Jan Charvat. - driver tested on QEMU emulated Malta big-endian MIPS platform and big endian-support fixed. - checkpatch from 5.4 kernel used to cleanup driver formatting - header files generated from IP core IP-Xact description updated to include protocol exception (pex) field. Mechanism to set it from the driver is not provided yet. The version 3 changes: - sent at 2019-12-21 - adapts device tree bindings documentation according to Rob Herring suggestions. - the driver has been separated to individual modules for core support, PCI bus integration and platform, SoC integration. - the FPGA design has been cleaned up and CAN protocol FSM redesigned by Ondrej Ille (the core redesign has been reason to pause attempts to driver submission) - the work from February 2019 on core, test framework and driver 1601 commits in total, 436 commits in the core sources, 144 commits in the driver, 151 documentation, 502 in tests. - not all continuous integration tests updated for latest design version yet https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core/pipelines - Zynq hardware in the loop test show no issues for after driver PCI and platform separation and latest VHDL sources updates. - driver code has been periodically tested on 4.18.5-rt3 and 4.19 long term stable kernels. - test of the patches before submission is run on 5.4 kernel - the core has been integrated by Jaroslav Beran into Intel FPGA based SoC used in the tester developed for Skoda auto at Department of Measurement, Faculty of Electrical Engineering, Czech Technical University https://meas.fel.cvut.cz/ . He has contributed feedback and fixes to the project. The version 2 sent at 2019-02-27 The version 1 sent at 2019-02-22 Ondrej Ille has prepared the CTU CAN IP Core sources for new release. We are waiting with it for the driver review, our intention is to release IP when driver is reviewed and mainlined. DKMS CTU CAN FD driver build by OpenBuildService to ease integration into Debian systems when driver is not provided by the distribution https://build.opensuse.org/package/show/home:ppisa/ctu_can_fd Jan Charvat finished work to extend already mainlined QEMU SJA1000 and SocketCAN support to provide even CAN FD support and CTU CAN FD core support. https://gitlab.fel.cvut.cz/canbus/qemu-canbus/-/tree/ctu-canfd The patches has been sent for review to QEMU mainlining list. Thanks in advance to all who help us to deliver the project into public. Thanks to all colleagues, reviewers and other providing feedback,
[PATCH RFC 2/2] ARM: dts: imx: add devicetree for Tolino Shine 2 HD
This adds a devicetree for the Tolino Shine 2 HD Ebook reader. It is based
on boards marked with "37NB-E60QF0+4A2". It is equipped with an i.MX6SL
SoC.
Expected to work:
- Buttons
- Wifi
- Touchscreen
- LED
- uSD
- USB
- RTC
Not working due to missing drivers:
- Backlight (requires NTXEC driver)
- EPD
Not working due to unknown reasons:
- deep sleep (echo standby >/sys/power/state works),
wakeup fails when imx_gpc_pre_suspend(true) was called.
Signed-off-by: Andreas Kemnade
---
Reason for RFC: The suspend trouble might be caused by bad devicetree.
But as the devicetree is already useful I decided to submit it.
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts | 582 +++
2 files changed, 583 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e6a1cac0bfc7..c65fa3852246 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -581,6 +581,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6qp-zii-rdu2.dtb
dtb-$(CONFIG_SOC_IMX6SL) += \
imx6sl-evk.dtb \
+ imx6sl-tolino-shine2hd.dtb \
imx6sl-tolino-shine3.dtb \
imx6sl-warp.dtb
dtb-$(CONFIG_SOC_IMX6SLL) += \
diff --git a/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
b/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
new file mode 100644
index ..7b28e19a1d98
--- /dev/null
+++ b/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
@@ -0,0 +1,582 @@
+// SPDX-License-Identifier: (GPL-2.0)
+/*
+ * Device tree for the Tolino Shine 2 HD ebook reader
+ *
+ * Name on mainboard is: 37NB-E60QF0+4A2
+ * Serials start with: E60QF2
+ *
+ * Copyright 2020 Andreas Kemnade
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include "imx6sl.dtsi"
+
+/ {
+ model = "Tolino Shine 2 HD";
+ compatible = "kobo,tolino-shine2hd", "fsl,imx6sl";
+
+ chosen {
+ stdout-path =
+ };
+
+ gpio_keys: gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <_gpio_keys>;
+
+ cover {
+ label = "Cover";
+ gpios = < 12 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ linux,input-type = ;
+ wakeup-source;
+ };
+
+ fl {
+ label = "Frontlight";
+ gpios = < 26 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ home {
+ label = "Home";
+ gpios = < 25 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ power {
+ label = "Power";
+ gpios = < 8 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ wakeup-source;
+ };
+ };
+
+ leds: leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_led>;
+
+ on {
+ label = "tolinoshine2hd:white:on";
+ gpios = < 13 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "timer";
+ };
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ reg = <0x8000 0x2000>;
+ };
+
+ reg_wifi: regulator-wifi {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <_wifi_power>;
+ regulator-name = "SD3_SPWR";
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <300>;
+ gpio = < 29 GPIO_ACTIVE_HIGH>;
+ };
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <_wifi_reset>;
+ post-power-on-delay-ms = <20>;
+ reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+ };
+};
+
+ {
+ pinctrl-names = "default","sleep";
+ pinctrl-0 = <_i2c1>;
+ pinctrl-1 = <_i2c1_sleep>;
+ status = "okay";
+
+ /* TODO: embedded controller at 0x43 (driver missing) */
+
+};
+
+ {
+ pinctrl-names = "default","sleep";
+ pinctrl-0 = <_i2c2>;
+ pinctrl-1 = <_i2c2_sleep>;
+ clock-frequency = <10>;
+ status = "okay";
+
+ zforce: touchscreen@50 {
+ compatible = "neonode,zforce";
+ pinctrl-names = "default";
+ pinctrl-0 = <_zforce>;
+ reg = <0x50>;
+ interrupt-parent = <>;
+ interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
+ vdd-supply = <_reg>;
+
+ reset-gpios = < 9 GPIO_ACTIVE_LOW>;
+ x-size = <1072>;
+ y-size = <1448>;
+ };
+
+
[PATCH 0/2] ARM: dts: add Tolino Shine 2 HD
This adds a device tree for the Tolino Shine 2 HD Ebook reader. It is equipped with an i.MX6SL SoC. Except for backlight (via an EC) and the EPD, drivers are available and therefore things are defined in the dts. Andreas Kemnade (2): dt-bindings: arm: fsl: add compatible string for Tolino Shine 2 HD ARM: dts: imx: add devicetree for Tolino Shine 2 HD .../devicetree/bindings/arm/fsl.yaml | 1 + arch/arm/boot/dts/Makefile| 1 + arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts | 582 ++ 3 files changed, 584 insertions(+) create mode 100644 arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts -- 2.20.1
Re: [PATCH v2] lib/string.c: implement stpcpy
On Sat, Aug 15, 2020 at 2:24 PM Joe Perches wrote:
>
> On Sat, 2020-08-15 at 13:47 -0700, Nick Desaulniers wrote:
> > On Sat, Aug 15, 2020 at 9:34 AM Kees Cook wrote:
> > > On Fri, Aug 14, 2020 at 07:09:44PM -0700, Nick Desaulniers wrote:
> > > > LLVM implemented a recent "libcall optimization" that lowers calls to
> > > > `sprintf(dest, "%s", str)` where the return value is used to
> > > > `stpcpy(dest, str) - dest`. This generally avoids the machinery involved
> > > > in parsing format strings. Calling `sprintf` with overlapping arguments
> > > > was clarified in ISO C99 and POSIX.1-2001 to be undefined behavior.
> > > >
> > > > `stpcpy` is just like `strcpy` except it returns the pointer to the new
> > > > tail of `dest`. This allows you to chain multiple calls to `stpcpy` in
> > > > one statement.
> > >
> > > O_O What?
> > >
> > > No; this is a _terrible_ API: there is no bounds checking, there are no
> > > buffer sizes. Anything using the example sprintf() pattern is _already_
> > > wrong and must be removed from the kernel. (Yes, I realize that the
> > > kernel is *filled* with this bad assumption that "I'll never write more
> > > than PAGE_SIZE bytes to this buffer", but that's both theoretically
> > > wrong ("640k is enough for anybody") and has been known to be wrong in
> > > practice too (e.g. when suddenly your writing routine is reachable by
> > > splice(2) and you may not have a PAGE_SIZE buffer).
> > >
> > > But we cannot _add_ another dangerous string API. We're already in a
> > > terrible mess trying to remove strcpy[1], strlcpy[2], and strncpy[3]. This
> > > needs to be addressed up by removing the unbounded sprintf() uses. (And
> > > to do so without introducing bugs related to using snprintf() when
> > > scnprintf() is expected[4].)
> >
> > Well, everything (-next, mainline, stable) is broken right now (with
> > ToT Clang) without providing this symbol. I'm not going to go clean
> > the entire kernel's use of sprintf to get our CI back to being green.
>
> Maybe this should get place in compiler-clang.h so it isn't
> generic and public.
https://bugs.llvm.org/show_bug.cgi?id=47162#c7 and
https://bugs.llvm.org/show_bug.cgi?id=47144
Seem to imply that Clang is not the only compiler that can lower a
sequence of libcalls to stpcpy. Do we want to wait until we have a
fire drill w/ GCC to move such an implementation from
include/linux/compiler-clang.h back in to lib/string.c?
>
> Something like:
>
> ---
> include/linux/compiler-clang.h | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
> index cee0c728d39a..6279f1904e39 100644
> --- a/include/linux/compiler-clang.h
> +++ b/include/linux/compiler-clang.h
> @@ -61,3 +61,30 @@
> #if __has_feature(shadow_call_stack)
> # define __noscs __attribute__((__no_sanitize__("shadow-call-stack")))
> #endif
> +
> +#ifndef __HAVE_ARCH_STPCPY
> +/**
> + * stpcpy - copy a string from src to dest returning a pointer to the new end
> + * of dest, including src's NULL terminator. May overrun dest.
> + * @dest: pointer to buffer being copied into.
> + *Must be large enough to receive copy.
> + * @src: pointer to the beginning of string being copied from.
> + * Must not overlap dest.
> + *
> + * This function exists _only_ to support clang's possible conversion of
> + * sprintf calls to stpcpy.
> + *
> + * stpcpy differs from strcpy in two key ways:
> + * 1. inputs must not overlap.
> + * 2. return value is dest's NUL termination character after copy.
> + *(for strcpy, the return value is a pointer to src)
> + */
> +
> +static inline char *stpcpy(char __restrict *dest, const char __restrict *src)
> +{
> + while ((*dest++ = *src++) != '\0') {
> + ; /* nothing */
> + }
> + return --dest;
> +}
> +#endif
>
>
--
Thanks,
~Nick Desaulniers
Re: [PATCH v2] lib/string.c: implement stpcpy
-fno-builtin-stpcpy can be used to disable stpcpy but Nick at llvm bugzilla
wrote that these flags are broken with LTO.
> Dňa 15. 8. 2020 o 23:24 užívateľ Joe Perches napísal:
>
> On Sat, 2020-08-15 at 13:47 -0700, Nick Desaulniers wrote:
>>> On Sat, Aug 15, 2020 at 9:34 AM Kees Cook wrote:
>>> On Fri, Aug 14, 2020 at 07:09:44PM -0700, Nick Desaulniers wrote:
LLVM implemented a recent "libcall optimization" that lowers calls to
`sprintf(dest, "%s", str)` where the return value is used to
`stpcpy(dest, str) - dest`. This generally avoids the machinery involved
in parsing format strings. Calling `sprintf` with overlapping arguments
was clarified in ISO C99 and POSIX.1-2001 to be undefined behavior.
`stpcpy` is just like `strcpy` except it returns the pointer to the new
tail of `dest`. This allows you to chain multiple calls to `stpcpy` in
one statement.
>>>
>>> O_O What?
>>>
>>> No; this is a _terrible_ API: there is no bounds checking, there are no
>>> buffer sizes. Anything using the example sprintf() pattern is _already_
>>> wrong and must be removed from the kernel. (Yes, I realize that the
>>> kernel is *filled* with this bad assumption that "I'll never write more
>>> than PAGE_SIZE bytes to this buffer", but that's both theoretically
>>> wrong ("640k is enough for anybody") and has been known to be wrong in
>>> practice too (e.g. when suddenly your writing routine is reachable by
>>> splice(2) and you may not have a PAGE_SIZE buffer).
>>>
>>> But we cannot _add_ another dangerous string API. We're already in a
>>> terrible mess trying to remove strcpy[1], strlcpy[2], and strncpy[3]. This
>>> needs to be addressed up by removing the unbounded sprintf() uses. (And
>>> to do so without introducing bugs related to using snprintf() when
>>> scnprintf() is expected[4].)
>>
>> Well, everything (-next, mainline, stable) is broken right now (with
>> ToT Clang) without providing this symbol. I'm not going to go clean
>> the entire kernel's use of sprintf to get our CI back to being green.
>
> Maybe this should get place in compiler-clang.h so it isn't
> generic and public.
>
> Something like:
>
> ---
> include/linux/compiler-clang.h | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
> index cee0c728d39a..6279f1904e39 100644
> --- a/include/linux/compiler-clang.h
> +++ b/include/linux/compiler-clang.h
> @@ -61,3 +61,30 @@
> #if __has_feature(shadow_call_stack)
> # define __noscs__attribute__((__no_sanitize__("shadow-call-stack")))
> #endif
> +
> +#ifndef __HAVE_ARCH_STPCPY
> +/**
> + * stpcpy - copy a string from src to dest returning a pointer to the new end
> + * of dest, including src's NULL terminator. May overrun dest.
> + * @dest: pointer to buffer being copied into.
> + *Must be large enough to receive copy.
> + * @src: pointer to the beginning of string being copied from.
> + * Must not overlap dest.
> + *
> + * This function exists _only_ to support clang's possible conversion of
> + * sprintf calls to stpcpy.
> + *
> + * stpcpy differs from strcpy in two key ways:
> + * 1. inputs must not overlap.
> + * 2. return value is dest's NUL termination character after copy.
> + *(for strcpy, the return value is a pointer to src)
> + */
> +
> +static inline char *stpcpy(char __restrict *dest, const char __restrict *src)
> +{
> +while ((*dest++ = *src++) != '\0') {
> +;/* nothing */
> +}
> + return --dest;
> +}
> +#endif
>
>
[PATCH] swiotlb: Allow allocating buffer anywhere in memory
POWER secure guests (i.e., guests which use the Protection Execution
Facility) need to use SWIOTLB to be able to do I/O with the hypervisor, but
they don't need the SWIOTLB memory to be in low addresses since the
hypervisor doesn't have any addressing limitation.
This solves a SWIOTLB initialization problem we are seeing in secure guests
with 128 GB of RAM: they are configured with 4 GB of crashkernel reserved
memory, which leaves no space for SWIOTLB in low addresses.
Signed-off-by: Thiago Jung Bauermann
---
arch/powerpc/mm/mem.c | 7 ++-
include/linux/swiotlb.h | 8 +++-
kernel/dma/swiotlb.c| 10 +++---
3 files changed, 20 insertions(+), 5 deletions(-)
Normally I would split changes like this into one patch touching generic
code and another for the arch-specific part, but in this case I thought it
would be unneeded complexity. I can split though if people prefer it that
way.
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index c2c11eb8dcfc..13f2e3aff8b5 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
#include
@@ -290,7 +291,11 @@ void __init mem_init(void)
* back to to-down.
*/
memblock_set_bottom_up(true);
- swiotlb_init(0);
+ /*
+* SVM guests can use the SWIOTLB wherever it is in memory,
+* even if not DMA-able.
+*/
+ swiotlb_init_anywhere(0, is_secure_guest());
#endif
high_memory = (void *) __va(max_low_pfn * PAGE_SIZE);
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 046bb94bd4d6..433f3dbb35b5 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -29,7 +29,13 @@ enum swiotlb_force {
*/
#define IO_TLB_SHIFT 11
-extern void swiotlb_init(int verbose);
+void __init swiotlb_init_anywhere(int verbose, bool allocate_anywhere);
+
+static inline void swiotlb_init(int verbose)
+{
+ swiotlb_init_anywhere(verbose, false);
+}
+
int swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose);
extern unsigned long swiotlb_nr_tbl(void);
unsigned long swiotlb_size_or_default(void);
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index c19379fabd20..27070aa59e34 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -244,7 +244,7 @@ int __init swiotlb_init_with_tbl(char *tlb, unsigned long
nslabs, int verbose)
* structures for the software IO TLB used to implement the DMA API.
*/
void __init
-swiotlb_init(int verbose)
+swiotlb_init_anywhere(int verbose, bool allocate_anywhere)
{
size_t default_size = IO_TLB_DEFAULT_SIZE;
unsigned char *vstart;
@@ -257,8 +257,12 @@ swiotlb_init(int verbose)
bytes = io_tlb_nslabs << IO_TLB_SHIFT;
- /* Get IO TLB memory from the low pages */
- vstart = memblock_alloc_low(PAGE_ALIGN(bytes), PAGE_SIZE);
+ if (allocate_anywhere)
+ vstart = memblock_alloc(PAGE_ALIGN(bytes), PAGE_SIZE);
+ else
+ /* Get IO TLB memory from the low pages */
+ vstart = memblock_alloc_low(PAGE_ALIGN(bytes), PAGE_SIZE);
+
if (vstart && !swiotlb_init_with_tbl(vstart, io_tlb_nslabs, verbose))
return;
Re: [PATCH] nvme-pci: Use u32 for nvme_dev.q_depth and nvme_queue.q_depth
Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH 3/3] drm/panel: Add panel driver for the Mantix MLAF057WE51-X DSI panel
Hi Guido.
> +static int mantix_probe(struct mipi_dsi_device *dsi)
> +{
> + struct device *dev = >dev;
> + struct mantix *ctx;
> + int ret;
> +
> + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> + if (!ctx)
> + return -ENOMEM;
> +
> + ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> + if (IS_ERR(ctx->reset_gpio)) {
> + DRM_DEV_ERROR(dev, "cannot get reset gpio\n");
> + return PTR_ERR(ctx->reset_gpio);
> + }
> +
> + mipi_dsi_set_drvdata(dsi, ctx);
> + ctx->dev = dev;
> +
> + dsi->lanes = 4;
> + dsi->format = MIPI_DSI_FMT_RGB888;
> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
> + MIPI_DSI_MODE_VIDEO_BURST | MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
> +
> + ctx->avdd = devm_regulator_get(dev, "avdd");
> + if (IS_ERR(ctx->avdd)) {
> + ret = PTR_ERR(ctx->avdd);
> + if (ret != -EPROBE_DEFER)
> + DRM_DEV_ERROR(dev,
> + "Failed to request avdd regulator: %d\n",
> + ret);
> + return ret;
> + }
Consider to use the recently added dev_err_probe() here and below.
Note: Not part of drm-misc-next yet - but hopefully after -rc1
when a backmerge is done.
Sam
> + ctx->avee = devm_regulator_get(dev, "avee");
> + if (IS_ERR(ctx->avee)) {
> + ret = PTR_ERR(ctx->avee);
> + if (ret != -EPROBE_DEFER)
> + DRM_DEV_ERROR(dev,
> + "Failed to request avee regulator: %d\n",
> + ret);
> + return ret;
> + }
> + ctx->vddi = devm_regulator_get(dev, "vddi");
> + if (IS_ERR(ctx->vddi)) {
> + ret = PTR_ERR(ctx->vddi);
> + if (ret != -EPROBE_DEFER)
> + DRM_DEV_ERROR(dev,
> + "Failed to request vddi regulator: %d\n",
> + ret);
> + return ret;
> + }
> +
> + drm_panel_init(>panel, dev, _drm_funcs,
> +DRM_MODE_CONNECTOR_DSI);
> +
> + ret = drm_panel_of_backlight(>panel);
> + if (ret)
> + return ret;
> + drm_panel_add(>panel);
> +
> + ret = mipi_dsi_attach(dsi);
> + if (ret < 0) {
> + DRM_DEV_ERROR(dev,
> + "mipi_dsi_attach failed (%d). Is host ready?\n",
> + ret);
> + drm_panel_remove(>panel);
> + return ret;
> + }
> +
> + DRM_DEV_INFO(dev, "%ux%u@%u %ubpp dsi %udl - ready\n",
> + default_mode.hdisplay, default_mode.vdisplay,
> + drm_mode_vrefresh(_mode),
> + mipi_dsi_pixel_format_to_bpp(dsi->format), dsi->lanes);
> +
> + return 0;
> +}
> +
> +static void mantix_shutdown(struct mipi_dsi_device *dsi)
> +{
> + struct mantix *ctx = mipi_dsi_get_drvdata(dsi);
> + int ret;
> +
> + ret = drm_panel_unprepare(>panel);
> + if (ret < 0)
> + DRM_DEV_ERROR(>dev, "Failed to unprepare panel: %d\n",
> + ret);
> +
> + ret = drm_panel_disable(>panel);
> + if (ret < 0)
> + DRM_DEV_ERROR(>dev, "Failed to disable panel: %d\n",
> + ret);
> +}
> +
> +static int mantix_remove(struct mipi_dsi_device *dsi)
> +{
> + struct mantix *ctx = mipi_dsi_get_drvdata(dsi);
> + int ret;
> +
> + mantix_shutdown(dsi);
> +
> + ret = mipi_dsi_detach(dsi);
> + if (ret < 0)
> + DRM_DEV_ERROR(>dev, "Failed to detach from DSI host: %d\n",
> + ret);
> +
> + drm_panel_remove(>panel);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id mantix_of_match[] = {
> + { .compatible = "mantix,mlaf057we51-x" },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, mantix_of_match);
> +
> +static struct mipi_dsi_driver mantix_driver = {
> + .probe = mantix_probe,
> + .remove = mantix_remove,
> + .shutdown = mantix_shutdown,
> + .driver = {
> + .name = DRV_NAME,
> + .of_match_table = mantix_of_match,
> + },
> +};
> +module_mipi_dsi_driver(mantix_driver);
> +
> +MODULE_AUTHOR("Guido Günther ");
> +MODULE_DESCRIPTION("DRM driver for Mantix MLAF057WE51-X MIPI DSI panel");
> +MODULE_LICENSE("GPL v2");
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] Please pull NFS client updates for Linux 5.9
The pull request you sent on Fri, 14 Aug 2020 22:04:02 +: > git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-5.9-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/37711e5e2325535bf094bdc0a66790d659b52d5b Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: linux-next: new build warnings after binutils update
* Kees Cook wrote: > On Fri, Aug 14, 2020 at 12:22:06PM +0200, Ingo Molnar wrote: > > > [0] > > > https://lore.kernel.org/lkml/20200731202738.2577854-6-nived...@alum.mit.edu/ > > > > It all looked good to me but was a bit late for v5.9, will pick up > > after -rc1. > > Excellent! Thank you. I'll base the orphan series on x86/boot now. Once > I send a v6 (there are a few more things to tweak), can you carry that > in -tip as well (it includes arm and arm64 as well, all of which depend > on several asm-generic patches). Sure, that looks the most sensible, since there's so much x86 impact. Might migrate the commits over into a more generic topic branch - started out with x86/boot to get things going. Thanks, Ingo
Re: [PATCH v4 3/5] counter: Add character device interface
On Mon, Aug 10, 2020 at 06:02:16PM -0500, David Lechner wrote: > On 8/9/20 9:51 AM, William Breathitt Gray wrote: > > On Tue, Jul 28, 2020 at 07:20:03PM -0500, David Lechner wrote: > >> On 7/21/20 2:35 PM, William Breathitt Gray wrote: > >>> This patch introduces a character device interface for the Counter > >>> subsystem. Device data is exposed through standard character device read > >>> operations. Device data is gathered when a Counter event is pushed by > >>> the respective Counter device driver. Configuration is handled via ioctl > >>> operations on the respective Counter character device node. > >> > >> This sounds similar to triggers and buffers in the iio subsystem. And > >> I can see how it might be useful in some cases. But I think it would not > >> give the desired results when performance is important. > >> > >> Thinking through a few cases here... > >> > >> Suppose there was a new counter device that used the I2C bus. This would > >> either have to be periodically polled for events or it might have a > >> separate GPIO line to notify the MCU. In any case, with the proposed > >> implementation, there would be a separate I2C transaction for each data > >> point for that event. So none of the data for that event would actually > >> be from the same point in time. And with I2C, this time difference could > >> be significant. > >> > >> With the TI eQEP I have been working with, there are special latched > >> registers for some events. To make use of these with events, we would have > >> add extensions for each one we want to use (and expose it in sysfs). But > >> really, the fact that we are using a latched register should be an > >> implementation detail in the driver and not something userspace should have > >> to know about. > >> > >> So, I'm wondering if it would make sense to keep things simpler and have > >> events like the input subsystem where the event value is directly tied > >> to the event. It would probably be rare for an event to have more than > >> one or two values. And error events probably would not have a value at > >> all. > >> > >> For example, with the TI eQEP, there is a unit timer time out event. > >> This latches the position count, the timer count and the timer period. > >> To translate this to an event data structure, the latched time would > >> be the event timestamp and the position count would be the event value. > >> The timer period should already be known since we would have configured > >> the timer ourselves. There is also a count event that works similarly. > >> In this case, the latched time would be the event timestamp and the > >> latched timer period would be the event value. We would know the count > >> already since we get an event for each count (and a separate direction > >> change event if the direction changes). > > > > There are use-cases where it would be useful to have the extension reads > > occur as close to the event trigger as possible (e.g. multiple-axes > > positioning with boundary sensor flags) so I don't think this > > functionality should be completely abadoned, but I think your argument > > for standard event types makes sense. > > > > We could treat those extensions reads as an optional feature that can be > > enabled and configured by ioctls. However, the use-case you are > > concerned with, we can redesign Counter events to return specific data > > based on the specific event type. > > > > For example, we could have a COUNTER_EVENT_INDEX which occurs when an > > Index signal edge is detected, and the return data is the Count value > > for that channel; we can also have a COUNTER_EVENT_TIMEOUT which occurs > > when a unit timer times out, and returns the data you mentioned you are > > interested in seeing. > > > > These Counter event types would be standard, so user applications > > wouldn't need to know driver/device implementation details, but instead > > just follow the API to get the data they expect for that particular > > event type. Would this kind of design work for your needs? > > > Yes. After trying (and failing) to implement my suggestions here, I > came to the conclusion that it was not sufficient to only have one > value per event. And it doesn't seem as obvious as I initially thought > which should be the "standard" value for an event in some cases. I agree, after thinking this over a second I realized it's not as apparent as I had hoped to determine what value would be most useful in general. I think the uses of counter devices are too varied, so it's probably best to leave it to the user to choose what value they want to gather for the respective events. The good thing is that the interface is flexible enough for us to defined new COUNTER_COMPONENT_TYPE_XXX types to extend the kind of data that can be gathered on an event push. This provides us with a path we can go down to implement the kind of data read you need without the latency overhead of executing multiple Counter Extension read operations (allowing for
[PATCH v3] perf: arm_dsu: Support DSU ACPI devices
Add support for probing device from ACPI node.
Each DSU ACPI node and its associated cpus are inside a cluster node.
Signed-off-by: Tuan Phan
---
Changes in v3:
- Based on the latest ARM ACPI binding at:
https://developer.arm.com/documentation/den0093/c/
Changes in v2:
- Removed IRQF_SHARED.
- Fixed ACPI runtime detection.
drivers/perf/arm_dsu_pmu.c | 68 --
1 file changed, 60 insertions(+), 8 deletions(-)
diff --git a/drivers/perf/arm_dsu_pmu.c b/drivers/perf/arm_dsu_pmu.c
index 96ed93c..4be355d 100644
--- a/drivers/perf/arm_dsu_pmu.c
+++ b/drivers/perf/arm_dsu_pmu.c
@@ -11,6 +11,7 @@
#define DRVNAMEPMUNAME "_pmu"
#define pr_fmt(fmt)DRVNAME ": " fmt
+#include
#include
#include
#include
@@ -603,18 +604,21 @@ static struct dsu_pmu *dsu_pmu_alloc(struct
platform_device *pdev)
}
/**
- * dsu_pmu_dt_get_cpus: Get the list of CPUs in the cluster.
+ * dsu_pmu_dt_get_cpus: Get the list of CPUs in the cluster
+ * from device tree.
*/
-static int dsu_pmu_dt_get_cpus(struct device_node *dev, cpumask_t *mask)
+static int dsu_pmu_dt_get_cpus(struct platform_device *pdev)
{
int i = 0, n, cpu;
struct device_node *cpu_node;
+ struct dsu_pmu *dsu_pmu =
+ (struct dsu_pmu *) platform_get_drvdata(pdev);
- n = of_count_phandle_with_args(dev, "cpus", NULL);
+ n = of_count_phandle_with_args(pdev->dev.of_node, "cpus", NULL);
if (n <= 0)
return -ENODEV;
for (; i < n; i++) {
- cpu_node = of_parse_phandle(dev, "cpus", i);
+ cpu_node = of_parse_phandle(pdev->dev.of_node, "cpus", i);
if (!cpu_node)
break;
cpu = of_cpu_node_to_id(cpu_node);
@@ -626,11 +630,51 @@ static int dsu_pmu_dt_get_cpus(struct device_node *dev,
cpumask_t *mask)
*/
if (cpu < 0)
continue;
- cpumask_set_cpu(cpu, mask);
+ cpumask_set_cpu(cpu, _pmu->associated_cpus);
}
return 0;
}
+/**
+ * dsu_pmu_acpi_get_cpus: Get the list of CPUs in the cluster
+ * from ACPI.
+ */
+static int dsu_pmu_acpi_get_cpus(struct platform_device *pdev)
+{
+ int cpu;
+ struct dsu_pmu *dsu_pmu = (struct dsu_pmu *) platform_get_drvdata(pdev);
+
+ /*
+* A dsu pmu node is inside a cluster parent node along with cpu nodes.
+* We need to find out all cpus that have the same parent with this pmu.
+*/
+ for_each_possible_cpu(cpu) {
+ struct acpi_device *acpi_dev =
ACPI_COMPANION(get_cpu_device(cpu));
+
+ if (acpi_dev &&
+ acpi_dev->parent == ACPI_COMPANION(>dev)->parent)
+ cpumask_set_cpu(cpu, _pmu->associated_cpus);
+ }
+
+ return 0;
+}
+
+static int dsu_pmu_platform_get_cpus(struct platform_device *pdev)
+{
+ int ret = -ENOENT;
+ struct fwnode_handle *fwnode = dev_fwnode(>dev);
+
+ if (IS_ERR_OR_NULL(fwnode))
+ return ret;
+
+ if (is_of_node(fwnode))
+ ret = dsu_pmu_dt_get_cpus(pdev);
+ else if (is_acpi_device_node(fwnode))
+ ret = dsu_pmu_acpi_get_cpus(pdev);
+
+ return ret;
+}
+
/*
* dsu_pmu_probe_pmu: Probe the PMU details on a CPU in the cluster.
*/
@@ -683,7 +727,9 @@ static int dsu_pmu_device_probe(struct platform_device
*pdev)
if (IS_ERR(dsu_pmu))
return PTR_ERR(dsu_pmu);
- rc = dsu_pmu_dt_get_cpus(pdev->dev.of_node, _pmu->associated_cpus);
+ platform_set_drvdata(pdev, dsu_pmu);
+
+ rc = dsu_pmu_platform_get_cpus(pdev);
if (rc) {
dev_warn(>dev, "Failed to parse the CPUs\n");
return rc;
@@ -705,7 +751,6 @@ static int dsu_pmu_device_probe(struct platform_device
*pdev)
}
dsu_pmu->irq = irq;
- platform_set_drvdata(pdev, dsu_pmu);
rc = cpuhp_state_add_instance(dsu_pmu_cpuhp_state,
_pmu->cpuhp_node);
if (rc)
@@ -752,11 +797,19 @@ static const struct of_device_id dsu_pmu_of_match[] = {
{ .compatible = "arm,dsu-pmu", },
{},
};
+MODULE_DEVICE_TABLE(of, dsu_pmu_of_match);
+
+static const struct acpi_device_id dsu_pmu_acpi_match[] = {
+ { "ARMHD500", 0},
+ {},
+};
+MODULE_DEVICE_TABLE(acpi, dsu_pmu_acpi_match);
static struct platform_driver dsu_pmu_driver = {
.driver = {
.name = DRVNAME,
.of_match_table = of_match_ptr(dsu_pmu_of_match),
+ .acpi_match_table = ACPI_PTR(dsu_pmu_acpi_match),
.suppress_bind_attrs = true,
},
.probe = dsu_pmu_device_probe,
@@ -826,7 +879,6 @@ static void __exit dsu_pmu_exit(void)
module_init(dsu_pmu_init);
module_exit(dsu_pmu_exit);
-MODULE_DEVICE_TABLE(of, dsu_pmu_of_match);
MODULE_DESCRIPTION("Perf driver for ARM
[tip: x86/paravirt] x86/paravirt: Clean up paravirt macros
The following commit has been merged into the x86/paravirt branch of tip: Commit-ID: 94b827becc6a87c905ab30b398e12a266518acbb Gitweb: https://git.kernel.org/tip/94b827becc6a87c905ab30b398e12a266518acbb Author:Juergen Gross AuthorDate:Sat, 15 Aug 2020 12:06:37 +02:00 Committer: Ingo Molnar CommitterDate: Sat, 15 Aug 2020 13:52:11 +02:00 x86/paravirt: Clean up paravirt macros Some paravirt macros are no longer used, delete them. Signed-off-by: Juergen Gross Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20200815100641.26362-3-jgr...@suse.com --- arch/x86/include/asm/paravirt.h | 15 --- 1 file changed, 15 deletions(-) diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h index 25c7a73..e02c409 100644 --- a/arch/x86/include/asm/paravirt.h +++ b/arch/x86/include/asm/paravirt.h @@ -586,16 +586,9 @@ bool __raw_callee_save___native_vcpu_is_preempted(long cpu); #endif /* SMP && PARAVIRT_SPINLOCKS */ #ifdef CONFIG_X86_32 -#define PV_SAVE_REGS "pushl %ecx; pushl %edx;" -#define PV_RESTORE_REGS "popl %edx; popl %ecx;" - /* save and restore all caller-save registers, except return value */ #define PV_SAVE_ALL_CALLER_REGS"pushl %ecx;" #define PV_RESTORE_ALL_CALLER_REGS "popl %ecx;" - -#define PV_FLAGS_ARG "0" -#define PV_EXTRA_CLOBBERS -#define PV_VEXTRA_CLOBBERS #else /* save and restore all caller-save registers, except return value */ #define PV_SAVE_ALL_CALLER_REGS \ @@ -616,14 +609,6 @@ bool __raw_callee_save___native_vcpu_is_preempted(long cpu); "pop %rsi;" \ "pop %rdx;" \ "pop %rcx;" - -/* We save some registers, but all of them, that's too much. We clobber all - * caller saved registers but the argument parameter */ -#define PV_SAVE_REGS "pushq %%rdi;" -#define PV_RESTORE_REGS "popq %%rdi;" -#define PV_EXTRA_CLOBBERS EXTRA_CLOBBERS, "rcx" , "rdx", "rsi" -#define PV_VEXTRA_CLOBBERS EXTRA_CLOBBERS, "rdi", "rcx" , "rdx", "rsi" -#define PV_FLAGS_ARG "D" #endif /*
Re: [PATCH 1/2] x86/MCE/AMD, EDAC/mce_amd: Use AMD NodeId for Family17h+ DRAM Decode
* Yazen Ghannam wrote:
> From: Yazen Ghannam
>
> The edac_mce_amd module calls decode_dram_ecc() on AMD Family17h and
> later systems. This function is used in amd64_edac_mod to do
> system-specific decoding for DRAM ECC errors. The function takes a
> "NodeId" as a parameter.
>
> In AMD documentation, NodeId is used to identify a physical die in a
> system. This can be used to identify a node in the AMD_NB code and also
> it is used with umc_normaddr_to_sysaddr().
>
> However, the input used for decode_dram_ecc() is currently the NUMA node
> of a logical CPU. In the default configuration, the NUMA node and
> physical die will be equivalent, so this doesn't have an impact. But the
> NUMA node configuration can be adjusted with optional memory
> interleaving schemes. This will cause the NUMA node enumeration to not
> match the physical die enumeration. The mismatch will cause the address
> translation function to fail or report incorrect results.
>
> Save the "NodeId" as a percpu value during init in AMD MCE code. Export
> a function to return the value which can be used from modules like
> edac_mce_amd.
>
> Fixes: fbe63acf62f5 ("EDAC, mce_amd: Use cpu_to_node() to find the node ID")
> Signed-off-by: Yazen Ghannam
> ---
> arch/x86/include/asm/mce.h| 2 ++
> arch/x86/kernel/cpu/mce/amd.c | 11 +++
> drivers/edac/mce_amd.c| 2 +-
> 3 files changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
> index cf503824529c..92527cc9ed06 100644
> --- a/arch/x86/include/asm/mce.h
> +++ b/arch/x86/include/asm/mce.h
> @@ -343,6 +343,8 @@ extern struct smca_bank smca_banks[MAX_NR_BANKS];
> extern const char *smca_get_long_name(enum smca_bank_types t);
> extern bool amd_mce_is_memory_error(struct mce *m);
>
> +extern u8 amd_cpu_to_node(unsigned int cpu);
> +
> extern int mce_threshold_create_device(unsigned int cpu);
> extern int mce_threshold_remove_device(unsigned int cpu);
>
> diff --git a/arch/x86/kernel/cpu/mce/amd.c b/arch/x86/kernel/cpu/mce/amd.c
> index 99be063fcb1b..524edf81e287 100644
> --- a/arch/x86/kernel/cpu/mce/amd.c
> +++ b/arch/x86/kernel/cpu/mce/amd.c
> @@ -202,6 +202,9 @@ static DEFINE_PER_CPU(unsigned int, bank_map);
> /* Map of banks that have more than MCA_MISC0 available. */
> static DEFINE_PER_CPU(u32, smca_misc_banks_map);
>
> +/* CPUID_Fn801E_ECX[NodeId] used to identify a physical node/die. */
> +static DEFINE_PER_CPU(u8, node_id);
> +
> static void amd_threshold_interrupt(void);
> static void amd_deferred_error_interrupt(void);
>
> @@ -233,6 +236,12 @@ static void smca_set_misc_banks_map(unsigned int bank,
> unsigned int cpu)
>
> }
>
> +u8 amd_cpu_to_node(unsigned int cpu)
> +{
> + return per_cpu(node_id, cpu);
> +}
> +EXPORT_SYMBOL_GPL(amd_cpu_to_node);
> +
> static void smca_configure(unsigned int bank, unsigned int cpu)
> {
> unsigned int i, hwid_mcatype;
> @@ -240,6 +249,8 @@ static void smca_configure(unsigned int bank, unsigned
> int cpu)
> u32 high, low;
> u32 smca_config = MSR_AMD64_SMCA_MCx_CONFIG(bank);
>
> + this_cpu_write(node_id, cpuid_ecx(0x801e) & 0xFF);
So we already have this magic number used for a similar purpose, in
amd_get_topology():
cpuid(0x801e, , , , );
node_id = ecx & 0xff;
Firstly, could we please at least give 0x801e a proper symbolic
name, use it in hygon.c too (which AFAIK is derived from AMD anyway),
and then use it in these new patches?
Secondly, why not stick node_id into struct cpuinfo_x86, where the MCA
code can then use it without having to introduce a new percpu data
structure?
There's also the underlying assumption that there's only ever going to
be 256 nodes, which limitation I'm sure we'll hear about in a couple
of years as not being quite enough. ;-)
So less hardcoding and more generalizations please.
Thanks,
Ingo
Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag
On Sat, Aug 15, 2020 at 01:14:53AM +0200, Thomas Gleixner wrote: > #1 trivial fix is to force switching to an high prio thread or a soft >interrupt which does the allocation Yeah, push the alocation out to another context. I did consider it, but why bother? Also, raising a softirq can't be done from every context, that's a whole new problem. You can do irq_work I suppose, but not all architectures support the self-IPI yet. All in all, it's just more complexity than the fairly trivial __alloc_page_lockless(). Whichever way around, we can't rely on the allocation.
Re: POC: Alternative solution: Re: [PATCH 0/4] printk: reimplement LOG_CONT handling
On (20/08/14 15:46), Linus Torvalds wrote:
> On Thu, Aug 13, 2020 at 4:54 AM Sergey Senozhatsky
> wrote:
> >
> > I think what Linus said a long time ago was that the initial purpose of
> > pr_cont was
> >
> > pr_info("Initialize feature foo...");
> > if (init_feature_foo() == 0)
> > pr_cont("ok\n");
> > else
> > pr_cont("not ok\n");
> >
> > And if init_feature_foo() crashes the kernel then the first printk()
> > form panic() will flush the cont buffer.
>
> Right.
>
> This is why I think any discussion that says "people should buffer
> their lines themselves and we should get rid if pr_cont()" is
> fundamentally broken.
I think what we've been talking about so far was "how do we buffer
cont lines now", what are the problems of current buffering and what
can we do to make that buffering SMP safe (preserving the context of
broken cont buffer, etc. etc.). I don't think that anyone concluded
to just "s/pr_cont/printk/g", I don't see this.
-ss
Re: [PATCH v4 1/5] counter: Internalize sysfs interface code
On Mon, Aug 10, 2020 at 05:48:07PM -0500, David Lechner wrote:
>
> >
> > CPMAC ETHERNET DRIVER
> > M: Florian Fainelli
> > diff --git a/drivers/counter/104-quad-8.c b/drivers/counter/104-quad-8.c
> > index 78766b6ec271..0f20920073d6 100644
> > --- a/drivers/counter/104-quad-8.c
> > +++ b/drivers/counter/104-quad-8.c
> > @@ -621,7 +621,7 @@ static const struct iio_chan_spec quad8_channels[]
> > = {
> > };
> >
> > static int quad8_signal_read(struct counter_device *counter,
> > - struct counter_signal *signal, enum counter_signal_value *val)
> > +struct counter_signal *signal, u8 *val)
>
> I'm not a fan of replacing enum types with u8 everywhere in this patch.
> But if we have to for technical reasons (e.g. causes compiler error if
> we don't) then it would be helpful to add comments giving the enum type
> everywhere like this instance where u8 is actually an enum value.
>
> If we use u32 as the generic type for enums instead of u8, I think the
> compiler will happlily let us use enum type and u32 interchangeably and
> not complain.
> >>>
> >>> I switched to fixed-width types after the suggestion by David Laight:
> >>> https://lkml.org/lkml/2020/5/3/159. I'll CC David Laight just in case he
> >>> wants to chime in again.
> >>>
> >>> Enum types would be nice for making the valid values explicit, but there
> >>> is one benefit I have appreciated from the move to fixed-width types:
> >>> there has been a significant reduction of duplicate code; before, we had
> >>> a different read function for each different enum type, but now we use a
> >>> single function to handle them all.
> >>
> >> Yes, what I was trying to explain is that by using u32 instead of u8, I
> >> think we can actually do both.
> >>
> >> The function pointers in struct counter_device *counter would use u32 as a
> >> generic enum value in the declaration, but then the actual implementations
> >> could still use the proper enum type.
> >
> > Oh, I see what you mean now. So for example:
> >
> > int (*signal_read)(struct counter_device *counter,
> > struct counter_signal *signal, u8 *val)
> >
> > This will become instead:
> >
> > int (*signal_read)(struct counter_device *counter,
> > struct counter_signal *signal, u32 *val)
> >
> > Then in the driver callback implementation we use the enum type we need:
> >
> > enum counter_signal_level signal_level = COUNTER_SIGNAL_HIGH;
> > ...
> > *val = signal_level;
> >
> > Is that what you have in mind?
> >
>
> Yes.
>
> Additionally, if we have...
>
>
>int (*x_write)(struct counter_device *counter,
> ..., u32 val)
>
> We should be able to define the implementation as:
>
> static int my_driver_x_write(struct counter_device *counter,
> ..., enum some_type val)
> {
> ...
> }
>
> Not sure if it works if val is a pointer though. Little-
> endian systems would probably be fine, but maybe not big-
> endian combined with -fshort-enums compiler flag.
>
>
>int (*x_read)(struct counter_device *counter,
> ..., u32 *val)
>
>
> static int my_driver_x_read(struct counter_device *counter,
> ..., enum some_type *val)
> {
> ...
> }
Regardless of endianness for pointers, will targets that have
-fshort-enums enabled by default present a problem here? I imagine that
in these cases enum some_type will have a size of unsigned char because
that is the first type that can represent all the values:
https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html
What I'm worried about is whether we can gurantee u32 val can be swapped
out with enum some_type val -- or if this is not possible because some
architectures will be built with -fshort-enums enabled?
William Breathitt Gray
signature.asc
Description: PGP signature
Re: [PATCH] i2c: iproc: Fix checkpatch warnings by using 'BIT' macro
On 8/14/2020 3:40 PM, Ray Jui wrote: Fix additional checkpatch warnings in the iProc I2C driver by using 'BIT' marcro. Reported-by: Wolfram Sang Signed-off-by: Ray Jui Acked-by: Florian Fainelli -- Florian
Re: [PATCH] overflow: Add __must_check attribute to check_*() helpers
On Thu, Aug 13, 2020 at 08:39:44AM +0200, Rasmus Villemoes wrote: > On 12/08/2020 23.51, Kees Cook wrote: > > Since the destination variable of the check_*_overflow() helpers will > > contain a wrapped value on failure, it would be best to make sure callers > > really did check the return result of the helper. Adjust the macros to use > > a bool-wrapping static inline that is marked with __must_check. This means > > the macros can continue to have their type-agnostic behavior while gaining > > the function attribute (that cannot be applied directly to macros). > > > > Suggested-by: Rasmus Villemoes > > Signed-off-by: Kees Cook > > --- > > include/linux/overflow.h | 51 +++- > > 1 file changed, 30 insertions(+), 21 deletions(-) > > > > diff --git a/include/linux/overflow.h b/include/linux/overflow.h > > index 93fcef105061..ef7d538c2d08 100644 > > --- a/include/linux/overflow.h > > +++ b/include/linux/overflow.h > > @@ -43,6 +43,16 @@ > > #define is_non_negative(a) ((a) > 0 || (a) == 0) > > #define is_negative(a) (!(is_non_negative(a))) > > > > +/* > > + * Allows to effectively us apply __must_check to a macro so we can have > > word ordering? This and the __must_check-bool() renaming now done and sent in v2. Thanks! > Sorry, I meant to send this before your cooking was done but forgot > about it again. Not a big deal, but it occurred to me it might be better > to rename the existing check_*_overflow to __check_*_overflow (in both > branches of the COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW), and then > > #define check_*_overflow(a, b, d) > __must_check_bool(__check_*_overflow(a, b, d)) At the end of the day, I'd rather not have a way to ignore the overflow in this way -- I'd rather have a set of wrap_mul_overflow() helpers instead. Then we've got proper annotation of the expectation (and a place for function attributes to be added to tell sanitizers to ignore overflow). -- Kees Cook
[PATCH 6/9] habanalabs: remove redundant assignment to variable
new_dma_pkt->ctl is assigned a value and then is reassigned a new value without the first value ever being used. Reported-by: kernel test robot Signed-off-by: Oded Gabbay --- drivers/misc/habanalabs/gaudi/gaudi.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/misc/habanalabs/gaudi/gaudi.c b/drivers/misc/habanalabs/gaudi/gaudi.c index ed289a6ed622..ffd0849e8f2d 100644 --- a/drivers/misc/habanalabs/gaudi/gaudi.c +++ b/drivers/misc/habanalabs/gaudi/gaudi.c @@ -3944,8 +3944,6 @@ static int gaudi_patch_dma_packet(struct hl_device *hdev, } } - new_dma_pkt->ctl = user_dma_pkt->ctl; - ctl = le32_to_cpu(user_dma_pkt->ctl); if (likely(dma_desc_cnt)) ctl &= ~GAUDI_PKT_CTL_EB_MASK; -- 2.17.1
Re: [PATCH v10 3/5] drm/msm/dp: add support for DP PLL driver
On 15/08/2020 02:22, Tanmay Shah wrote:
On 2020-08-14 10:05, Dmitry Baryshkov wrote:
On 12/08/2020 07:42, Tanmay Shah wrote:
From: Chandan Uddaraju
Add the needed DP PLL specific files to support
display port interface on msm targets.
[skipped]
diff --git a/drivers/gpu/drm/msm/dp/dp_pll_private.h
b/drivers/gpu/drm/msm/dp/dp_pll_private.h
new file mode 100644
index ..475ba6ed59ab
--- /dev/null
+++ b/drivers/gpu/drm/msm/dp/dp_pll_private.h
@@ -0,0 +1,98 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2016-2020, The Linux Foundation. All rights reserved.
+ */
+
+#ifndef __DP_PLL_10NM_H
+#define __DP_PLL_10NM_H
+
+#include "dp_pll.h"
+#include "dp_reg.h"
+
+#define DP_VCO_HSCLK_RATE_1620MHZDIV1000 162UL
+#define DP_VCO_HSCLK_RATE_2700MHZDIV1000 270UL
+#define DP_VCO_HSCLK_RATE_5400MHZDIV1000 540UL
+#define DP_VCO_HSCLK_RATE_8100MHZDIV1000 810UL
+
+#define NUM_DP_CLOCKS_MAX 6
+
+#define DP_PHY_PLL_POLL_SLEEP_US 500
+#define DP_PHY_PLL_POLL_TIMEOUT_US 1
+
+#define DP_VCO_RATE_8100MHZDIV1000 810UL
+#define DP_VCO_RATE_9720MHZDIV1000 972UL
+#define DP_VCO_RATE_10800MHZDIV1000 1080UL
+
+struct dp_pll_vco_clk {
+ struct clk_hw hw;
+ unsigned long rate; /* current vco rate */
+ u64 min_rate; /* min vco rate */
+ u64 max_rate; /* max vco rate */
+ void *priv;
+};
+
+struct dp_pll_db {
This struct should probably go into dp_pll_10nm.c. dp_pll_7nm.c, for
example, will use slightly different structure.
Sure, it sounds good. I will give it try. Thanks!
+ struct msm_dp_pll *base;
+
+ int id;
+ struct platform_device *pdev;
+
+ /* private clocks: */
+ bool fixed_factor_clk[NUM_DP_CLOCKS_MAX];
+ struct clk_hw *hws[NUM_DP_CLOCKS_MAX];
Then these two fields can use exact number of clocks rather than
NUM_DP_CLOCKS_MAX.
I didn't get this. I think NUM_DP_CLOCKS_MAX is doing same?
Not exactly. We'd need fixed_factor_clk[4] for 10nm rather than 6. It's
not that important, just a small nitpick.
+ u32 num_hws;
+
+ /* lane and orientation settings */
+ u8 lane_cnt;
+ u8 orientation;
+
+ /* COM PHY settings */
+ u32 hsclk_sel;
+ u32 dec_start_mode0;
+ u32 div_frac_start1_mode0;
+ u32 div_frac_start2_mode0;
+ u32 div_frac_start3_mode0;
+ u32 integloop_gain0_mode0;
+ u32 integloop_gain1_mode0;
+ u32 vco_tune_map;
+ u32 lock_cmp1_mode0;
+ u32 lock_cmp2_mode0;
+ u32 lock_cmp3_mode0;
+ u32 lock_cmp_en;
+
+ /* PHY vco divider */
+ u32 phy_vco_div;
+ /*
+ * Certain pll's needs to update the same vco rate after resume in
+ * suspend/resume scenario. Cached the vco rate for such plls.
+ */
+ unsigned long vco_cached_rate;
+ u32 cached_cfg0;
+ u32 cached_cfg1;
+ u32 cached_outdiv;
+
+ uint32_t index;
+};
+
+static inline struct dp_pll_vco_clk *to_dp_vco_hw(struct clk_hw *hw)
+{
+ return container_of(hw, struct dp_pll_vco_clk, hw);
+}
+
+#define to_msm_dp_pll(vco) ((struct msm_dp_pll *)vco->priv)
+
+#define to_dp_pll_db(x) ((struct dp_pll_db *)x->priv)
+
+int dp_vco_set_rate_10nm(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate);
+unsigned long dp_vco_recalc_rate_10nm(struct clk_hw *hw,
+ unsigned long parent_rate);
+long dp_vco_round_rate_10nm(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate);
+int dp_vco_prepare_10nm(struct clk_hw *hw);
+void dp_vco_unprepare_10nm(struct clk_hw *hw);
+
+int msm_dp_pll_10nm_init(struct msm_dp_pll *dp_pll, int id);
+void msm_dp_pll_10nm_deinit(struct msm_dp_pll *dp_pll);
These functions don't seem to be used outside of dp_pll_10nm. What
about making them static?
I can't declare static to "init" and "deinit" as they are exported to
dp_pll.c.
Rest of them I can move to dp_pll_10nm and then define static.
Please exuse me for not being exact enough. Of course I meant
dp_vco_FOO_10nm() functions, not init/exit.
BTW: as I'm looking onto 7nm dp pll, which naming would you prefer?
We can have separate DP_PLL_10nm/DP_PLL_7nm namespaces (as DSI PLLs do)
or I can override only a set of constants (like downstream driver does).
--
With best wishes
Dmitry
[tip: x86/paravirt] x86/paravirt: Avoid needless paravirt step clearing page table entries
The following commit has been merged into the x86/paravirt branch of tip:
Commit-ID: 7c9f80cb76ec9f14c3b25509168b1a2f7942e418
Gitweb:
https://git.kernel.org/tip/7c9f80cb76ec9f14c3b25509168b1a2f7942e418
Author:Juergen Gross
AuthorDate:Sat, 15 Aug 2020 12:06:41 +02:00
Committer: Ingo Molnar
CommitterDate: Sat, 15 Aug 2020 13:52:12 +02:00
x86/paravirt: Avoid needless paravirt step clearing page table entries
pte_clear() et al are based on two paravirt steps today: one step to
create a page table entry with all zeroes, and one step to write this
entry value.
Drop the first step as it is completely useless.
Signed-off-by: Juergen Gross
Signed-off-by: Ingo Molnar
Link: https://lore.kernel.org/r/20200815100641.26362-7-jgr...@suse.com
---
arch/x86/include/asm/paravirt.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index f0464b8..d25cc68 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -448,7 +448,7 @@ static inline pudval_t pud_val(pud_t pud)
static inline void pud_clear(pud_t *pudp)
{
- set_pud(pudp, __pud(0));
+ set_pud(pudp, native_make_pud(0));
}
static inline void set_p4d(p4d_t *p4dp, p4d_t p4d)
@@ -485,15 +485,15 @@ static inline void __set_pgd(pgd_t *pgdp, pgd_t pgd)
} while (0)
#define pgd_clear(pgdp) do { \
- if (pgtable_l5_enabled())
\
- set_pgd(pgdp, __pgd(0));\
+ if (pgtable_l5_enabled()) \
+ set_pgd(pgdp, native_make_pgd(0)); \
} while (0)
#endif /* CONFIG_PGTABLE_LEVELS == 5 */
static inline void p4d_clear(p4d_t *p4dp)
{
- set_p4d(p4dp, __p4d(0));
+ set_p4d(p4dp, native_make_p4d(0));
}
static inline void set_pte_atomic(pte_t *ptep, pte_t pte)
@@ -504,12 +504,12 @@ static inline void set_pte_atomic(pte_t *ptep, pte_t pte)
static inline void pte_clear(struct mm_struct *mm, unsigned long addr,
pte_t *ptep)
{
- set_pte(ptep, __pte(0));
+ set_pte(ptep, native_make_pte(0));
}
static inline void pmd_clear(pmd_t *pmdp)
{
- set_pmd(pmdp, __pmd(0));
+ set_pmd(pmdp, native_make_pmd(0));
}
#define __HAVE_ARCH_START_CONTEXT_SWITCH
[PATCH 0/2] power: supply: RN5T618/RC5T619
This series adds support for the RN5T618/RC5T619 charger and fuel gauge. Battery and input power status can be read. Andreas Kemnade (2): power: supply: Add support for RN5T618/RC5T619 charger and fuel gauge mfd: rn5t618: Add a power supply subdevice drivers/mfd/rn5t618.c| 1 + drivers/power/supply/Kconfig | 8 + drivers/power/supply/Makefile| 1 + drivers/power/supply/rn5t618_power.c | 565 +++ 4 files changed, 575 insertions(+) create mode 100644 drivers/power/supply/rn5t618_power.c -- 2.20.1
possible deadlock in io_poll_double_wake
Hello,
syzbot found the following issue on:
HEAD commit:c9c9735c Merge tag 'scsi-misc' of git://git.kernel.org/pub..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=127399f690
kernel config: https://syzkaller.appspot.com/x/.config?x=adea84f38e7bc8d
dashboard link: https://syzkaller.appspot.com/bug?extid=0d56cfeec64f045baffc
compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/
c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+0d56cfeec64f045ba...@syzkaller.appspotmail.com
WARNING: possible recursive locking detected
5.8.0-syzkaller #0 Not tainted
syz-executor.1/9155 is trying to acquire lock:
8880a1fcc530 (>write_wait){-.-.}-{2:2}, at: spin_lock
include/linux/spinlock.h:354 [inline]
8880a1fcc530 (>write_wait){-.-.}-{2:2}, at:
io_poll_double_wake+0x108/0x360 fs/io_uring.c:4599
but task is already holding lock:
8880a1fcc530 (>write_wait){-.-.}-{2:2}, at: __wake_up_common_lock
kernel/sched/wait.c:122 [inline]
8880a1fcc530 (>write_wait){-.-.}-{2:2}, at: __wake_up+0xb8/0x150
kernel/sched/wait.c:142
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(>write_wait);
lock(>write_wait);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by syz-executor.1/9155:
#0: 8880a1fcc098 (>ldisc_sem){}-{0:0}, at:
tty_ldisc_ref_wait+0x21/0x70 drivers/tty/tty_ldisc.c:267
#1: 8880a1fcc2e8 (>termios_rwsem){}-{3:3}, at:
tty_set_termios+0xc5/0x1510 drivers/tty/tty_ioctl.c:328
#2: 8880a1fcc098 (>ldisc_sem){}-{0:0}, at:
tty_ldisc_ref+0x18/0x80 drivers/tty/tty_ldisc.c:288
#3: 8880a1fcc530 (>write_wait){-.-.}-{2:2}, at: __wake_up_common_lock
kernel/sched/wait.c:122 [inline]
#3: 8880a1fcc530 (>write_wait){-.-.}-{2:2}, at: __wake_up+0xb8/0x150
kernel/sched/wait.c:142
stack backtrace:
CPU: 0 PID: 9155 Comm: syz-executor.1 Not tainted 5.8.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1f0/0x31e lib/dump_stack.c:118
print_deadlock_bug kernel/locking/lockdep.c:2391 [inline]
check_deadlock kernel/locking/lockdep.c:2432 [inline]
validate_chain+0x69a4/0x88a0 kernel/locking/lockdep.c:3202
__lock_acquire+0x1161/0x2ab0 kernel/locking/lockdep.c:4426
lock_acquire+0x160/0x730 kernel/locking/lockdep.c:5005
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:151
spin_lock include/linux/spinlock.h:354 [inline]
io_poll_double_wake+0x108/0x360 fs/io_uring.c:4599
__wake_up_common+0x30a/0x4e0 kernel/sched/wait.c:93
__wake_up_common_lock kernel/sched/wait.c:123 [inline]
__wake_up+0xd4/0x150 kernel/sched/wait.c:142
n_tty_set_termios+0xa60/0x1080 drivers/tty/n_tty.c:1874
tty_set_termios+0xcac/0x1510 drivers/tty/tty_ioctl.c:341
set_termios+0x4a1/0x580 drivers/tty/tty_ioctl.c:414
tty_mode_ioctl+0x7b2/0xa80 drivers/tty/tty_ioctl.c:770
tty_ioctl+0xf81/0x15c0 drivers/tty/tty_io.c:2665
vfs_ioctl fs/ioctl.c:48 [inline]
__do_sys_ioctl fs/ioctl.c:753 [inline]
__se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739
do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45d239
Code: 5d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83
2b b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f063db5fc78 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 00017cc0 RCX: 0045d239
RDX: 2000 RSI: 5404 RDI: 0003
RBP: 0118cf80 R08: R09:
R10: R11: 0246 R12: 0118cf4c
R13: 7ffc7ff6341f R14: 7f063db609c0 R15: 0118cf4c
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
[GIT PULL] scheduler fixes
Linus,
Please pull the latest sched/urgent git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-2020-08-15
# HEAD: cc172ff301d8079e941a6eb31758951a6d764084 sched/debug: Fix the
alignment of the show-state debug output
Two fixes: fix a new tracepoint's output value, and fix the formatting
of show-state syslog printouts.
Thanks,
Ingo
-->
Libing Zhou (1):
sched/debug: Fix the alignment of the show-state debug output
Phil Auld (1):
sched: Fix use of count for nr_running tracepoint
kernel/sched/core.c | 15 ---
kernel/sched/sched.h | 2 +-
2 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 4a0e7b449b88..09fd62568ba9 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6387,10 +6387,10 @@ void sched_show_task(struct task_struct *p)
if (!try_get_task_stack(p))
return;
- printk(KERN_INFO "%-15.15s %c", p->comm, task_state_to_char(p));
+ pr_info("task:%-15.15s state:%c", p->comm, task_state_to_char(p));
if (p->state == TASK_RUNNING)
- printk(KERN_CONT " running task");
+ pr_cont(" running task");
#ifdef CONFIG_DEBUG_STACK_USAGE
free = stack_not_used(p);
#endif
@@ -6399,8 +6399,8 @@ void sched_show_task(struct task_struct *p)
if (pid_alive(p))
ppid = task_pid_nr(rcu_dereference(p->real_parent));
rcu_read_unlock();
- printk(KERN_CONT "%5lu %5d %6d 0x%08lx\n", free,
- task_pid_nr(p), ppid,
+ pr_cont(" stack:%5lu pid:%5d ppid:%6d flags:0x%08lx\n",
+ free, task_pid_nr(p), ppid,
(unsigned long)task_thread_info(p)->flags);
print_worker_info(KERN_INFO, p);
@@ -6435,13 +6435,6 @@ void show_state_filter(unsigned long state_filter)
{
struct task_struct *g, *p;
-#if BITS_PER_LONG == 32
- printk(KERN_INFO
- " taskPC stack pid father\n");
-#else
- printk(KERN_INFO
- " taskPC stack pid father\n");
-#endif
rcu_read_lock();
for_each_process_thread(g, p) {
/*
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 3fd283892761..28709f6b0975 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1999,7 +1999,7 @@ static inline void sub_nr_running(struct rq *rq, unsigned
count)
{
rq->nr_running -= count;
if (trace_sched_update_nr_running_tp_enabled()) {
- call_trace_sched_update_nr_running(rq, count);
+ call_trace_sched_update_nr_running(rq, -count);
}
/* Check if we still need preemption */
Re: [PATCH v2] lib/string.c: implement stpcpy
On Fri, Aug 14, 2020 at 07:09:44PM -0700, Nick Desaulniers wrote:
> LLVM implemented a recent "libcall optimization" that lowers calls to
> `sprintf(dest, "%s", str)` where the return value is used to
> `stpcpy(dest, str) - dest`. This generally avoids the machinery involved
> in parsing format strings. Calling `sprintf` with overlapping arguments
> was clarified in ISO C99 and POSIX.1-2001 to be undefined behavior.
>
> `stpcpy` is just like `strcpy` except it returns the pointer to the new
> tail of `dest`. This allows you to chain multiple calls to `stpcpy` in
> one statement.
O_O What?
No; this is a _terrible_ API: there is no bounds checking, there are no
buffer sizes. Anything using the example sprintf() pattern is _already_
wrong and must be removed from the kernel. (Yes, I realize that the
kernel is *filled* with this bad assumption that "I'll never write more
than PAGE_SIZE bytes to this buffer", but that's both theoretically
wrong ("640k is enough for anybody") and has been known to be wrong in
practice too (e.g. when suddenly your writing routine is reachable by
splice(2) and you may not have a PAGE_SIZE buffer).
But we cannot _add_ another dangerous string API. We're already in a
terrible mess trying to remove strcpy[1], strlcpy[2], and strncpy[3]. This
needs to be addressed up by removing the unbounded sprintf() uses. (And
to do so without introducing bugs related to using snprintf() when
scnprintf() is expected[4].)
-Kees
[1] https://github.com/KSPP/linux/issues/88
[2] https://github.com/KSPP/linux/issues/89
[3] https://github.com/KSPP/linux/issues/90
[4] https://lore.kernel.org/lkml/20200810092100.GA42813@2f5448a72a42/
--
Kees Cook
Re: [PATCH RFC 02/12] entry/idle: Add a common function for activites during idle entry/exit
On Fri, Aug 14, 2020 at 11:18:58PM -0400, Joel Fernandes (Google) wrote: > Currently only RCU hooks for idle entry/exit are called. In later > patches, kernel-entry protection functionality will be added. > > Signed-off-by: Joel Fernandes (Google) NAK, rcu_idle_enter() is broken where it is now, it needs to be pushed in deeper: http://lkml.kernel.org/r/20200807193017.962482...@infradead.org
Re: [PATCH] Replace HTTP links with HTTPS ones: EDAC-SBRIDGE
On Wed, Jul 08, 2020 at 01:35:46PM +0200, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
> Replace HTTP with HTTPS.
>
> Signed-off-by: Alexander A. Klimov
> ---
> Continuing my work started at 93431e0607e5.
> See also: git log --oneline '--author=Alexander A. Klimov
> ' v5.7..master
> (Actually letting a shell for loop submit all this stuff for me.)
>
> If there are any URLs to be removed completely or at least not HTTPSified:
> Just clearly say so and I'll *undo my change*.
> See also: https://lkml.org/lkml/2020/6/27/64
>
> If there are any valid, but yet not changed URLs:
> See: https://lkml.org/lkml/2020/6/26/837
>
> If you apply the patch, please let me know.
>
>
> drivers/edac/sb_edac.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/edac/sb_edac.c b/drivers/edac/sb_edac.c
> index d414698ca324..a6704e73fcce 100644
> --- a/drivers/edac/sb_edac.c
> +++ b/drivers/edac/sb_edac.c
> @@ -3552,6 +3552,6 @@ MODULE_PARM_DESC(edac_op_state, "EDAC Error Reporting
> state: 0=Poll,1=NMI");
>
> MODULE_LICENSE("GPL");
> MODULE_AUTHOR("Mauro Carvalho Chehab");
> -MODULE_AUTHOR("Red Hat Inc. (http://www.redhat.com)");
> +MODULE_AUTHOR("Red Hat Inc. (https://www.redhat.com)");
> MODULE_DESCRIPTION("MC Driver for Intel Sandy Bridge and Ivy Bridge memory
> controllers - "
> SBRIDGE_REVISION);
> --
Merged all your EDAC patches into one and applied. Will push out once
-rc1 releases.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
memory leak in read_adv_mon_features
Hello, syzbot found the following issue on: HEAD commit:7fca4dee Merge tag 'powerpc-5.9-2' of git://git.kernel.org.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=15ea92a190 kernel config: https://syzkaller.appspot.com/x/.config?x=e320bbff976a5cdc dashboard link: https://syzkaller.appspot.com/bug?extid=f7f6e564f4202d8601c6 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1286db9a90 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1143ddf690 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+f7f6e564f4202d860...@syzkaller.appspotmail.com BUG: memory leak unreferenced object 0x88812b18e6e0 (size 32): comm "syz-executor286", pid 6490, jiffies 4294993450 (age 13.120s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 20 00 10 00 00 00 00 00 ... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [] kmalloc include/linux/slab.h:559 [inline] [ ] read_adv_mon_features+0xa1/0x150 net/bluetooth/mgmt.c:4180 [ ] hci_mgmt_cmd net/bluetooth/hci_sock.c:1603 [inline] [ ] hci_sock_sendmsg+0xb01/0xc60 net/bluetooth/hci_sock.c:1738 [<1560da71>] sock_sendmsg_nosec net/socket.c:651 [inline] [<1560da71>] sock_sendmsg+0x4c/0x60 net/socket.c:671 [<7d7be9f6>] sock_write_iter+0xc5/0x140 net/socket.c:998 [ ] call_write_iter include/linux/fs.h:1882 [inline] [ ] new_sync_write+0x173/0x210 fs/read_write.c:503 [<21a87df2>] vfs_write+0x21d/0x280 fs/read_write.c:578 [<03f07ff6>] ksys_write+0xd8/0x120 fs/read_write.c:631 [<03a7df09>] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 [<5ecd28f6>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 BUG: memory leak unreferenced object 0x88812b18e660 (size 32): comm "syz-executor286", pid 6495, jiffies 4294993998 (age 7.640s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 20 00 10 00 00 00 00 00 ... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [ ] kmalloc include/linux/slab.h:559 [inline] [ ] read_adv_mon_features+0xa1/0x150 net/bluetooth/mgmt.c:4180 [ ] hci_mgmt_cmd net/bluetooth/hci_sock.c:1603 [inline] [ ] hci_sock_sendmsg+0xb01/0xc60 net/bluetooth/hci_sock.c:1738 [<1560da71>] sock_sendmsg_nosec net/socket.c:651 [inline] [<1560da71>] sock_sendmsg+0x4c/0x60 net/socket.c:671 [<7d7be9f6>] sock_write_iter+0xc5/0x140 net/socket.c:998 [ ] call_write_iter include/linux/fs.h:1882 [inline] [ ] new_sync_write+0x173/0x210 fs/read_write.c:503 [<21a87df2>] vfs_write+0x21d/0x280 fs/read_write.c:578 [<03f07ff6>] ksys_write+0xd8/0x120 fs/read_write.c:631 [<03a7df09>] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 [<5ecd28f6>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH v2 1/3] dt-bindings: media: ov772x: Document endpoint properties
Hi Jacopo,
On Mon, Aug 3, 2020 at 12:39 PM Lad Prabhakar
wrote:
>
> Document endpoint properties required for parallel interface
>
> Signed-off-by: Lad Prabhakar
> ---
> .../devicetree/bindings/media/i2c/ov772x.txt | 16
> 1 file changed, 16 insertions(+)
>
I see you already have a patch for YAML conversion for OV772x binding
[1], if you plan to post a v2 would you be OK to pick these changes as
part of your conversion changes ?
[1] https://www.spinics.net/lists/linux-media/msg173201.html
Cheers,
Prabhakar
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov772x.txt
> b/Documentation/devicetree/bindings/media/i2c/ov772x.txt
> index 0b3ede5b8e6a..1f4153484717 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ov772x.txt
> +++ b/Documentation/devicetree/bindings/media/i2c/ov772x.txt
> @@ -21,6 +21,22 @@ subnode for its digital output video port, in accordance
> with the video
> interface bindings defined in Documentation/devicetree/bindings/media/
> video-interfaces.txt.
>
> +Endpoint node required properties for parallel connection are:
> +- remote-endpoint: a phandle to the bus receiver's endpoint node.
> +- bus-width: shall be set to <8> for 8 bits parallel bus
> +or <10> for 10 bits parallel bus
> +- data-shift: shall be set to <2> for 8 bits parallel bus
> + (lines 9:2 are used) or <0> for 10 bits parallel bus
> +- hsync-active: active state of the HSYNC signal, 0/1 for LOW/HIGH
> respectively.
> + (Not required for bus-type equal 6)
> +- vsync-active: active state of the VSYNC signal, 0/1 for LOW/HIGH
> respectively.
> + (Not required for bus-type equal 6)
> +- pclk-sample: sample data on rising (1) or falling (0) edge of the pixel
> clock
> + signal. (Not required for bus-type equal 6)
> +- bus-type: data bus type. Possible values are:
> + 5 - Parallel
> + 6 - Bt.656
> +
> Example:
>
> {
> --
> 2.17.1
>
Re: [PATCH] lib/string.c: implement stpcpy
Hi Nick,
On Fri, Aug 14, 2020 at 5:24 PM Nick Desaulniers
wrote:
>
> LLVM implemented a recent "libcall optimization" that lowers calls to
> `sprintf(dest, "%s", str)` where the return value is used to
> `stpcpy(dest, str) - dest`. This generally avoids the machinery involved
> in parsing format strings.
>
> `stpcpy` is just like `strcpy` except:
> 1. it returns the pointer to the new tail of `dest`. This allows you to
>chain multiple calls to `stpcpy` in one statement.
> 2. it requires the parameters not to overlap. Calling `sprintf` with
>overlapping arguments was clarified in ISO C99 and POSIX.1-2001 to be
>undefined behavior.
>
> `stpcpy` was first standardized in POSIX.1-2008.
>
> Implement this so that we don't observe linkage failures due to missing
> symbol definitions for `stpcpy`.
>
> Similar to last year's fire drill with:
> commit 5f074f3e192f ("lib/string.c: implement a basic bcmp")
>
> This optimization was introduced into clang-12.
>
> Cc: sta...@vger.kernel.org
> Link: https://bugs.llvm.org/show_bug.cgi?id=47162
> Link: https://github.com/ClangBuiltLinux/linux/issues/1126
> Link: https://man7.org/linux/man-pages/man3/stpcpy.3.html
> Link: https://pubs.opengroup.org/onlinepubs/9699919799/functions/stpcpy.html
> Link: https://reviews.llvm.org/D85963
> Reported-by: Sami Tolvanen
> Signed-off-by: Nick Desaulniers
> ---
> include/linux/string.h | 3 +++
> lib/string.c | 23 +++
> 2 files changed, 26 insertions(+)
Thank you for the patch! I can confirm that this fixes the build for
me with ToT Clang.
Tested-by: Sami Tolvanen
Sami
[tip: x86/paravirt] x86/paravirt: Remove 32-bit support from CONFIG_PARAVIRT_XXL
The following commit has been merged into the x86/paravirt branch of tip:
Commit-ID: 0cabf9914990dc59a7e1793ef2fb294d578dc210
Gitweb:
https://git.kernel.org/tip/0cabf9914990dc59a7e1793ef2fb294d578dc210
Author:Juergen Gross
AuthorDate:Sat, 15 Aug 2020 12:06:36 +02:00
Committer: Ingo Molnar
CommitterDate: Sat, 15 Aug 2020 13:52:11 +02:00
x86/paravirt: Remove 32-bit support from CONFIG_PARAVIRT_XXL
The last 32-bit user of stuff under CONFIG_PARAVIRT_XXL is gone.
Remove 32-bit specific parts.
Signed-off-by: Juergen Gross
Signed-off-by: Ingo Molnar
Link: https://lore.kernel.org/r/20200815100641.26362-2-jgr...@suse.com
---
arch/x86/entry/vdso/vdso32/vclock_gettime.c | 1 +-
arch/x86/include/asm/paravirt.h | 120 +--
arch/x86/include/asm/paravirt_types.h | 21 +---
arch/x86/include/asm/pgtable-3level_types.h | 5 +-
arch/x86/include/asm/segment.h | 4 +-
arch/x86/kernel/cpu/common.c| 8 +-
arch/x86/kernel/kprobes/core.c | 1 +-
arch/x86/kernel/kprobes/opt.c | 1 +-
arch/x86/kernel/paravirt.c | 18 +---
arch/x86/kernel/paravirt_patch.c| 17 +---
arch/x86/xen/enlighten_pv.c | 6 +-
11 files changed, 13 insertions(+), 189 deletions(-)
diff --git a/arch/x86/entry/vdso/vdso32/vclock_gettime.c
b/arch/x86/entry/vdso/vdso32/vclock_gettime.c
index 84a4a73..283ed9d 100644
--- a/arch/x86/entry/vdso/vdso32/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vdso32/vclock_gettime.c
@@ -14,6 +14,7 @@
#undef CONFIG_ILLEGAL_POINTER_VALUE
#undef CONFIG_SPARSEMEM_VMEMMAP
#undef CONFIG_NR_CPUS
+#undef CONFIG_PARAVIRT_XXL
#define CONFIG_X86_32 1
#define CONFIG_PGTABLE_LEVELS 2
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 3d2afec..25c7a73 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -160,8 +160,6 @@ static inline void wbinvd(void)
PVOP_VCALL0(cpu.wbinvd);
}
-#define get_kernel_rpl() (pv_info.kernel_rpl)
-
static inline u64 paravirt_read_msr(unsigned msr)
{
return PVOP_CALL1(u64, cpu.read_msr, msr);
@@ -277,12 +275,10 @@ static inline void load_TLS(struct thread_struct *t,
unsigned cpu)
PVOP_VCALL2(cpu.load_tls, t, cpu);
}
-#ifdef CONFIG_X86_64
static inline void load_gs_index(unsigned int gs)
{
PVOP_VCALL1(cpu.load_gs_index, gs);
}
-#endif
static inline void write_ldt_entry(struct desc_struct *dt, int entry,
const void *desc)
@@ -375,52 +371,22 @@ static inline void paravirt_release_p4d(unsigned long pfn)
static inline pte_t __pte(pteval_t val)
{
- pteval_t ret;
-
- if (sizeof(pteval_t) > sizeof(long))
- ret = PVOP_CALLEE2(pteval_t, mmu.make_pte, val, (u64)val >> 32);
- else
- ret = PVOP_CALLEE1(pteval_t, mmu.make_pte, val);
-
- return (pte_t) { .pte = ret };
+ return (pte_t) { PVOP_CALLEE1(pteval_t, mmu.make_pte, val) };
}
static inline pteval_t pte_val(pte_t pte)
{
- pteval_t ret;
-
- if (sizeof(pteval_t) > sizeof(long))
- ret = PVOP_CALLEE2(pteval_t, mmu.pte_val,
- pte.pte, (u64)pte.pte >> 32);
- else
- ret = PVOP_CALLEE1(pteval_t, mmu.pte_val, pte.pte);
-
- return ret;
+ return PVOP_CALLEE1(pteval_t, mmu.pte_val, pte.pte);
}
static inline pgd_t __pgd(pgdval_t val)
{
- pgdval_t ret;
-
- if (sizeof(pgdval_t) > sizeof(long))
- ret = PVOP_CALLEE2(pgdval_t, mmu.make_pgd, val, (u64)val >> 32);
- else
- ret = PVOP_CALLEE1(pgdval_t, mmu.make_pgd, val);
-
- return (pgd_t) { ret };
+ return (pgd_t) { PVOP_CALLEE1(pgdval_t, mmu.make_pgd, val) };
}
static inline pgdval_t pgd_val(pgd_t pgd)
{
- pgdval_t ret;
-
- if (sizeof(pgdval_t) > sizeof(long))
- ret = PVOP_CALLEE2(pgdval_t, mmu.pgd_val,
- pgd.pgd, (u64)pgd.pgd >> 32);
- else
- ret = PVOP_CALLEE1(pgdval_t, mmu.pgd_val, pgd.pgd);
-
- return ret;
+ return PVOP_CALLEE1(pgdval_t, mmu.pgd_val, pgd.pgd);
}
#define __HAVE_ARCH_PTEP_MODIFY_PROT_TRANSACTION
@@ -438,78 +404,40 @@ static inline void ptep_modify_prot_commit(struct
vm_area_struct *vma, unsigned
pte_t *ptep, pte_t old_pte, pte_t
pte)
{
- if (sizeof(pteval_t) > sizeof(long))
- /* 5 arg words */
- pv_ops.mmu.ptep_modify_prot_commit(vma, addr, ptep, pte);
- else
- PVOP_VCALL4(mmu.ptep_modify_prot_commit,
- vma, addr, ptep, pte.pte);
+ PVOP_VCALL4(mmu.ptep_modify_prot_commit, vma, addr, ptep, pte.pte);
}
static inline void set_pte(pte_t *ptep, pte_t pte)
{
- if (sizeof(pteval_t) > sizeof(long))
-
[PATCH 0/2] Make debug_obj_descr const
These patches make debug_obj_descr into a const pointer. The second patch can be split up into many patches if desired and sent to respective susbsytem maintainers. Stephen Boyd (2): debugobjects: Allow debug_obj_descr to be const treewide: Make all debug_obj_descr's const drivers/gpu/drm/i915/i915_active.c | 2 +- drivers/gpu/drm/i915/i915_sw_fence.c | 2 +- include/linux/debugobjects.h | 32 ++-- kernel/rcu/rcu.h | 2 +- kernel/rcu/update.c | 2 +- kernel/time/hrtimer.c| 4 ++-- kernel/time/timer.c | 4 ++-- kernel/workqueue.c | 4 ++-- lib/debugobjects.c | 30 +- lib/percpu_counter.c | 4 ++-- 10 files changed, 43 insertions(+), 43 deletions(-) base-commit: c9c9735c46f589b9877b7fc00c89ef1b61a31e18 -- Sent by a computer, using git, on the internet
[PATCH 2/2] mfd: rn5t618: Add a power supply subdevice
The RN5T618 and RC5T619 both have a charger and a fuel gauge, so add
a subdevice for it. According to drivers in the wild, things
should be at least similar, but since it is not tested, add it
only to the RC5T619.
Signed-off-by: Andreas Kemnade
---
drivers/mfd/rn5t618.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/rn5t618.c b/drivers/mfd/rn5t618.c
index e25407ed3ad4..dc452df1f1bf 100644
--- a/drivers/mfd/rn5t618.c
+++ b/drivers/mfd/rn5t618.c
@@ -25,6 +25,7 @@ static const struct mfd_cell rn5t618_cells[] = {
static const struct mfd_cell rc5t619_cells[] = {
{ .name = "rn5t618-adc" },
+ { .name = "rn5t618-power" },
{ .name = "rn5t618-regulator" },
{ .name = "rc5t619-rtc" },
{ .name = "rn5t618-wdt" },
--
2.20.1
Re: [PATCH] x86: work around clang IAS bug referencing __force_order
On Sat, Aug 15, 2020 at 12:46 PM Sedat Dilek wrote: > > On Sat, Aug 15, 2020 at 10:23 AM Sedat Dilek wrote: > > > > On Sat, Aug 15, 2020 at 5:28 AM Sedat Dilek wrote: > > > > > > On Sat, Aug 15, 2020 at 2:27 AM Nick Desaulniers > > > wrote: > > > > > > > > On Fri, Aug 14, 2020 at 3:57 PM Nick Desaulniers > > > > wrote: > > > > > > > > > > On Fri, Aug 14, 2020 at 2:19 PM Sedat Dilek > > > > > wrote: > > > > > > > > > > > > On Fri, Aug 14, 2020 at 7:29 PM Sedat Dilek > > > > > > wrote: > > > > > > > > > > > > > > Thanks for the proposal. > > > > > > > > > > > > > > I have adapted it to fit my patchset against Linux v5.8. > > > > > > > > > > > > > > Both Debian's GCC-10 and a snapshot version of LLVM toolchain > > > > > > > v11.0.0-rc1+ seems to be OK. > > > > > > > > > > > > > > > > > > > Yupp, OK. > > > > > > > > > > > > I was able to boot FreeDOS 1.2 VM in VirtualBox GUI. > > > > > > > > > > Hi Sedat, > > > > > Apologies, but it's not clear to me precisely which patch you tested. > > > > > Can you please confirm whether you tested: > > > > > 1. Arnd's patch that started this thread. > > > > > 2. My proposed diff adding -fno-addrsig to CFLAGS_powernow-k6.o. > > > > > 3. My proposed diff removing __force_order from the kernel. > > > > > > > > > > I'm hoping you were referring to testing 3., but it's not clear to me. > > > > > > > > Ah, sorry, I missed your comment on github: > > > > https://github.com/ClangBuiltLinux/linux/issues/1120#issuecomment-674282107 > > > > > > > > Ok, I will look at more disassembly next week and hopefully have a > > > > patch ready, with your tested by tag. > > > > > > > > > > Sorry for not being precise - I tested with solution (3.). > > > Later I added the diff I used as mentioned in your above comment. > > > > > > See [1]: > > > > > > > In a 2nd run building with a selfmade clang-11 and LLVM "bin"utils is > > > > fine, too. > > > > > > I cannot say much to older versions of GCC and/or LLVM/Clang if > > > removing "__force_order" works fine. > > > > > > Another (4.) solution: > > > Sami tried successfully by adding "__weak" declaration with > > > CONFIG_LKDTM=m (see [2]). > > > I am OK if this works, too. > > > > > > Please, see my attachments. > > > > > > - Sedat - > > > > > > [1] > > > https://github.com/ClangBuiltLinux/linux/issues/1120#issuecomment-674340760 > > > [2] > > > https://github.com/ClangBuiltLinux/linux/issues/1120#issuecomment-674182703 > > > > Unfortunately, the diff from Sami does not work together with Arvind's > > patchset... > > > > x86/boot: Remove run-time relocations from compressed kernel > > > > ...which got included in recently. > > > > I see the following: > > > > ld.lld-11 -m elf_x86_64 -pie --no-dynamic-linker -T > > arch/x86/boot/compressed/vmlinux.lds > > arch/x86/boot/compressed/kernel_info.o > > arch/x86/boot/compressed/head_64.o arch/x86/boot/compressed/misc.o > > arch/x86/boot/compressed/string.o arch/x86/boot/compressed/cmdline.o > > arch/x86/boot/compressed/error.o arch/x86/boot/compressed/piggy.o > > arch/x86/boot/compressed/cpuflags.o > > arch/x86/boot/compressed/early_serial_console.o > > arch/x86/boot/compressed/kaslr.o arch/x86/boot/compressed/kaslr_64.o > > arch/x86/boot/compressed/mem_encrypt.o > > arch/x86/boot/compressed/pgtable_64.o arch/x86/boot/compressed/acpi.o > > arch/x86/boot/compressed/efi_thunk_64.o > > drivers/firmware/efi/libstub/lib.a -o arch/x86/boot/compressed/vmlinux > > ld.lld-11: error: Unexpected GOT entries detected! > > ld.lld-11: error: Unexpected run-time relocations detected! > > ld.lld-11: error: Unexpected GOT entries detected! > > ld.lld-11: error: Unexpected run-time relocations detected! > > make[5]: *** [arch/x86/boot/compressed/Makefile:91: > > arch/x86/boot/compressed/vmlinux] Error 1 > > > > When you need further informations, please let me know. > > > > - Sedat - > > > > [1] > > https://github.com/ClangBuiltLinux/linux/issues/1120#issuecomment-674182703 > > When I revert... > > commit df6d4f9db79c1a5d6f48b59db35ccd1e9ff9adfc > "x86/boot/compressed: Don't declare __force_order in kaslr_64.c" > > ...I can build, boot on bare metal and start FreeDOS VM in VirtualBox. > > For more details see [2]. > > - Sedat - > > [1] https://git.kernel.org/linus/df6d4f9db79c1a5d6f48b59db35ccd1e9ff9adfc > [2] > https://github.com/ClangBuiltLinux/linux/issues/1120#issuecomment-674378085 Fine with using Debian's GCC v10.2 and GNU/ld v2.35 (from binutils v2.35). All details in [1]. [1] https://github.com/ClangBuiltLinux/linux/issues/1120#issuecomment-674406068
[PATCH for-5.9] iio: adc: meson-saradc: Use the parent device to look up the calib data
On the older-gen 32-bit SoCs the meson-saradc driver is used to read the
SoC temperature. This requires reading calibration data from the eFuse.
Looking up the calibration data nvmem-cell requires the OF device_node
pointer to be available in the struct device which is passed to
devm_nvmem_cell_get(). This however got lost with commit 8cb631ccbb1952
("iio: Remove superfluous of_node assignments") from indio_dev->dev. As
devm_nvmem_cell_get() is called in the initialization phase the
device_node is not yet available because the NVMEM cell is looked up
before iio_device_register() is called (which would then set the
device_node automatically).
Use the parent device to look up the NVMEM cell instead to fix this
issue.
Fixes: 8cb631ccbb1952 ("iio: Remove superfluous of_node assignments")
Signed-off-by: Martin Blumenstingl
---
drivers/iio/adc/meson_saradc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index 93c2252c0b89..1a9189ba69ae 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -707,7 +707,7 @@ static int meson_sar_adc_temp_sensor_init(struct iio_dev
*indio_dev)
size_t read_len;
int ret;
- temperature_calib = devm_nvmem_cell_get(_dev->dev,
+ temperature_calib = devm_nvmem_cell_get(indio_dev->dev.parent,
"temperature_calib");
if (IS_ERR(temperature_calib)) {
ret = PTR_ERR(temperature_calib);
--
2.28.0
[RFC PATCH 0/2] proc,socket: attach description to sockets
Checking to see if this could fit in struct sock. This goes against v5.8 I tried to make it tl;dr in commit 2/2 but motivation is also described a bit in https://lore.kernel.org/linux-api/CAGbU3_nVvuzMn2wo4_ZKufWcGfmGsopVujzTWw-Bbeky=xs...@mail.gmail.com/
[PATCH 2/3] regulator: rt4801: Add DT binding documentation
From: ChiYuan Huang
Add a devicetree binding documentation for the rt4801 regulator driver.
Signed-off-by: ChiYuan Huang
---
.../regulator/richtek,rt4801-regulator.yaml| 80 ++
1 file changed, 80 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml
diff --git
a/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml
b/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml
new file mode 100644
index ..28d30e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/richtek,rt4801-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT4801 Display Bias regulators
+
+maintainers:
+ - ChiYuan Huang
+
+description: |
+ Regulator nodes should be named to DSVP and DSVN. The
+ definition for each of these nodes is defined using the standard
+ binding for regulators at
+ Documentation/devicetree/bindings/regulator/regulator.txt.
+ Datasheet is available at
+ https://www.richtek.com/assets/product_file/RT4801H/DS4801H-00.pdf
+
+#The valid names for RT4801 regulator nodes are:
+#DSVP, DSVN
+
+properties:
+ compatible:
+enum:
+ - richtek,rt4801
+
+ reg:
+maxItems: 1
+
+ enable-gpios:
+description: GPIOs to use to enable DSVP/DSVN regulator.
+ The first one is ENP to enable DSVP, and second one is ENM to enable
DSVN.
+ Number of GPIO in the array list could be 1 or 2.
+ If only one gpio is specified, only one gpio used to control ENP/ENM.
+ Else both are spefied, DSVP/DSVN could be controlled individually.
+ Othersie, this property not specified. treat both as always-on regulator.
+minItems: 1
+maxItems: 2
+
+patternProperties:
+ "^DSV(P|N)$":
+type: object
+$ref: regulator.yaml#
+description:
+ Properties for single display bias regulator.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties:
+ - enable-gpios
+
+examples:
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+rt4801@73 {
+compatible = "richtek,rt4801";
+reg = <0x73>;
+enable-gpios = < 2 0>, < 3 0>;
+
+dsvp: DSVP {
+regulator-name = "rt4801,dsvp";
+regulator-min-microvolt = <400>;
+regulator-max-microvolt = <600>;
+regulator-boot-on;
+};
+dsvn: DSVN {
+regulator-name = "rt4801,dsvn";
+regulator-min-microvolt = <400>;
+regulator-max-microvolt = <600>;
+regulator-boot-on;
+};
+
+};
+};
--
2.7.4
Re: [PATCH RFC 2/2] lkdtm: Add heap spraying test
On Thu, Aug 13, 2020 at 06:19:22PM +0300, Alexander Popov wrote:
> Add a simple test for CONFIG_SLAB_QUARANTINE.
>
> It performs heap spraying that aims to reallocate the recently freed heap
> object. This technique is used for exploiting use-after-free
> vulnerabilities in the kernel code.
>
> This test shows that CONFIG_SLAB_QUARANTINE breaks heap spraying
> exploitation technique.
Yay tests!
>
> Signed-off-by: Alexander Popov
> ---
> drivers/misc/lkdtm/core.c | 1 +
> drivers/misc/lkdtm/heap.c | 40 ++
> drivers/misc/lkdtm/lkdtm.h | 1 +
> 3 files changed, 42 insertions(+)
>
> diff --git a/drivers/misc/lkdtm/core.c b/drivers/misc/lkdtm/core.c
> index a5e344df9166..78b7669c35eb 100644
> --- a/drivers/misc/lkdtm/core.c
> +++ b/drivers/misc/lkdtm/core.c
> @@ -126,6 +126,7 @@ static const struct crashtype crashtypes[] = {
> CRASHTYPE(SLAB_FREE_DOUBLE),
> CRASHTYPE(SLAB_FREE_CROSS),
> CRASHTYPE(SLAB_FREE_PAGE),
> + CRASHTYPE(HEAP_SPRAY),
> CRASHTYPE(SOFTLOCKUP),
> CRASHTYPE(HARDLOCKUP),
> CRASHTYPE(SPINLOCKUP),
> diff --git a/drivers/misc/lkdtm/heap.c b/drivers/misc/lkdtm/heap.c
> index 1323bc16f113..a72a241e314a 100644
> --- a/drivers/misc/lkdtm/heap.c
> +++ b/drivers/misc/lkdtm/heap.c
> @@ -205,6 +205,46 @@ static void ctor_a(void *region)
> static void ctor_b(void *region)
> { }
>
> +#define HEAP_SPRAY_SIZE 128
> +
> +void lkdtm_HEAP_SPRAY(void)
> +{
> + int *addr;
> + int *spray_addrs[HEAP_SPRAY_SIZE] = { 0 };
(the 0 isn't needed -- and it was left there, it should be NULL)
> + unsigned long i = 0;
> +
> + addr = kmem_cache_alloc(a_cache, GFP_KERNEL);
I would prefer this test add its own cache (e.g. spray_cache), to avoid
misbehaviors between tests. (e.g. the a and b caches already run the
risk of getting corrupted weirdly.)
> + if (!addr) {
> + pr_info("Unable to allocate memory in lkdtm-heap-a cache\n");
> + return;
> + }
> +
> + *addr = 0x31337;
> + kmem_cache_free(a_cache, addr);
> +
> + pr_info("Performing heap spraying...\n");
> + for (i = 0; i < HEAP_SPRAY_SIZE; i++) {
> + spray_addrs[i] = kmem_cache_alloc(a_cache, GFP_KERNEL);
> + *spray_addrs[i] = 0x31337;
> + pr_info("attempt %lu: spray alloc addr %p vs freed addr %p\n",
> + i, spray_addrs[i], addr);
That's 128 lines spewed into dmesg... I would leave this out.
> + if (spray_addrs[i] == addr) {
> + pr_info("freed addr is reallocated!\n");
> + break;
> + }
> + }
> +
> + if (i < HEAP_SPRAY_SIZE)
> + pr_info("FAIL! Heap spraying succeed :(\n");
I'd move this into the "if (spray_addrs[i] == addr)" test instead of the
pr_info() that is there.
> + else
> + pr_info("OK! Heap spraying hasn't succeed :)\n");
And then make this an "if (i == HEAP_SPRAY_SIZE)" test
> +
> + for (i = 0; i < HEAP_SPRAY_SIZE; i++) {
> + if (spray_addrs[i])
> + kmem_cache_free(a_cache, spray_addrs[i]);
> + }
> +}
> +
> void __init lkdtm_heap_init(void)
> {
> double_free_cache = kmem_cache_create("lkdtm-heap-double_free",
> diff --git a/drivers/misc/lkdtm/lkdtm.h b/drivers/misc/lkdtm/lkdtm.h
> index 8878538b2c13..dfafb4ae6f3a 100644
> --- a/drivers/misc/lkdtm/lkdtm.h
> +++ b/drivers/misc/lkdtm/lkdtm.h
> @@ -45,6 +45,7 @@ void lkdtm_READ_BUDDY_AFTER_FREE(void);
> void lkdtm_SLAB_FREE_DOUBLE(void);
> void lkdtm_SLAB_FREE_CROSS(void);
> void lkdtm_SLAB_FREE_PAGE(void);
> +void lkdtm_HEAP_SPRAY(void);
>
> /* lkdtm_perms.c */
> void __init lkdtm_perms_init(void);
> --
> 2.26.2
>
I assume enabling the quarantine defense also ends up being seen in the
SLAB_FREE_DOUBLE LKDTM test too, yes?
--
Kees Cook
Re: [PATCH 3/5] arm64: dts: renesas: r8a774a1: Add PCIe EP nodes
Hello!
On 14.08.2020 20:30, Lad Prabhakar wrote:
Add PCIe EP nodes to R8A774A1 (RZ/G2M) SoC dtsi.
Signed-off-by: Lad Prabhakar
Reviewed-by: Biju Das
---
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 38 +++
1 file changed, 38 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index a603d947970e..50e9ed16a36d 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -2369,6 +2369,44 @@
status = "disabled";
};
+ pciec0_ep: pcie_ep@fe00 {
Hyphens are preferred over underscores in the node/prop names.
[...]> + pciec1_ep: pcie_ep@ee80 {
Ditto, should be "pci-ep@ee80".
[...]
MBR, Sergei
[PATCH v2] overflow: Add __must_check attribute to check_*() helpers
Since the destination variable of the check_*_overflow() helpers will
contain a wrapped value on failure, it would be best to make sure callers
really did check the return result of the helper. Adjust the macros to use
a bool-wrapping static inline that is marked with __must_check. This means
the macros can continue to have their type-agnostic behavior while gaining
the function attribute (that cannot be applied directly to macros).
Suggested-by: Rasmus Villemoes
Signed-off-by: Kees Cook
---
v2:
- de-generalized __must_check_overflow() from being named "bool" (willy)
- fix comment typos (rasmus)
v1: https://lore.kernel.org/lkml/202008121450.405E4A3@keescook
---
include/linux/overflow.h | 39 ---
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/include/linux/overflow.h b/include/linux/overflow.h
index 93fcef105061..f1c4e7b56bd9 100644
--- a/include/linux/overflow.h
+++ b/include/linux/overflow.h
@@ -43,6 +43,16 @@
#define is_non_negative(a) ((a) > 0 || (a) == 0)
#define is_negative(a) (!(is_non_negative(a)))
+/*
+ * Allows for effectively applying __must_check to a macro so we can have
+ * both the type-agnostic benefits of the macros while also being able to
+ * enforce that the return value is, in fact, checked.
+ */
+static inline bool __must_check __must_check_overflow(bool overflow)
+{
+ return unlikely(overflow);
+}
+
#ifdef COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW
/*
* For simplicity and code hygiene, the fallback code below insists on
@@ -52,32 +62,32 @@
* alias for __builtin_add_overflow, but add type checks similar to
* below.
*/
-#define check_add_overflow(a, b, d) ({ \
+#define check_add_overflow(a, b, d) __must_check_overflow(({ \
typeof(a) __a = (a);\
typeof(b) __b = (b);\
typeof(d) __d = (d);\
(void) (&__a == &__b); \
(void) (&__a == __d); \
__builtin_add_overflow(__a, __b, __d); \
-})
+}))
-#define check_sub_overflow(a, b, d) ({ \
+#define check_sub_overflow(a, b, d) __must_check_overflow(({ \
typeof(a) __a = (a);\
typeof(b) __b = (b);\
typeof(d) __d = (d);\
(void) (&__a == &__b); \
(void) (&__a == __d); \
__builtin_sub_overflow(__a, __b, __d); \
-})
+}))
-#define check_mul_overflow(a, b, d) ({ \
+#define check_mul_overflow(a, b, d) __must_check_overflow(({ \
typeof(a) __a = (a);\
typeof(b) __b = (b);\
typeof(d) __d = (d);\
(void) (&__a == &__b); \
(void) (&__a == __d); \
__builtin_mul_overflow(__a, __b, __d); \
-})
+}))
#else
@@ -190,21 +200,20 @@
})
-#define check_add_overflow(a, b, d)\
+#define check_add_overflow(a, b, d)__must_check_overflow( \
__builtin_choose_expr(is_signed_type(typeof(a)),\
__signed_add_overflow(a, b, d), \
- __unsigned_add_overflow(a, b, d))
+ __unsigned_add_overflow(a, b, d)))
-#define check_sub_overflow(a, b, d)\
+#define check_sub_overflow(a, b, d)__must_check_overflow( \
__builtin_choose_expr(is_signed_type(typeof(a)),\
__signed_sub_overflow(a, b, d), \
- __unsigned_sub_overflow(a, b, d))
+ __unsigned_sub_overflow(a, b, d)))
-#define check_mul_overflow(a, b, d)\
+#define check_mul_overflow(a, b, d)__must_check_overflow( \
__builtin_choose_expr(is_signed_type(typeof(a)),\
__signed_mul_overflow(a, b, d), \
- __unsigned_mul_overflow(a, b, d))
-
+ __unsigned_mul_overflow(a, b, d)))
#endif /* COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW */
@@ -227,7 +236,7 @@
* '*d' will hold the results of the attempted shift, but is not
* considered "safe for use" if false is returned.
*/
-#define check_shl_overflow(a, s, d) ({ \
+#define check_shl_overflow(a, s, d) __must_check_overflow(({ \
typeof(a) _a = a; \
typeof(s) _s = s; \
typeof(d) _d = d; \
@@ -237,7 +246,7 @@
*_d = (_a_full << _to_shift); \
(_to_shift != _s || is_negative(*_d) || is_negative(_a) || \
(*_d >> _to_shift) != _a);
Re: [PATCH] squashfs: avoid bio_alloc() failure with 1Mbyte blocks
On Fri, Aug 14, 2020 at 8:57 PM Phillip Lougher wrote:
>
> This is a regression introduced by the "migrate from ll_rw_block usage
> to BIO" patch.
>
> Bio_alloc() is limited to 256 pages (1 Mbyte). This can cause a
> failure when reading 1 Mbyte block filesystems. The problem is
> a datablock can be fully (or almost uncompressed), requiring 256
> pages, but, because blocks are not aligned to page boundaries, it
> may require 257 pages to read.
>
> Bio_kmalloc() can handle 1024 pages, and so use this for the
> edge condition.
>
> Reported-by: Nicolas Prochazka
> Reported-by: Tomoatsu Shimada
> Signed-off-by: Phillip Lougher
Fixes: 93e72b3c612a ("squashfs: migrate from ll_rw_block usage to BIO")
Reviewed-by: Guenter Roeck
> ---
> fs/squashfs/block.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/fs/squashfs/block.c b/fs/squashfs/block.c
> index 76bb1c846845..8a19773b5a0b 100644
> --- a/fs/squashfs/block.c
> +++ b/fs/squashfs/block.c
> @@ -87,7 +87,11 @@ static int squashfs_bio_read(struct super_block *sb, u64
> index, int length,
> int error, i;
> struct bio *bio;
>
> - bio = bio_alloc(GFP_NOIO, page_count);
> + if (page_count <= BIO_MAX_PAGES)
> + bio = bio_alloc(GFP_NOIO, page_count);
> + else
> + bio = bio_kmalloc(GFP_NOIO, page_count);
> +
> if (!bio)
> return -ENOMEM;
>
> --
> 2.20.1
>
[PATCH RFC 12/12] sched/coresched: rq->core should be set only if not previously set
From: Vineeth Pillai
During hotplug events, smt_mask would not contain all the CPUs in a core and
this can cause reassigning of rq->core, which breaks the core-wide counters
that are needed for tracking kernel-mode entry/exits.
This patch therefore makes sure that rq->core does not change once it is set.
Signed-off-by: Vineeth Pillai
Signed-off-by: Joel Fernandes (Google)
---
kernel/sched/core.c | 28
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 5da5b2317b21..464493f3a759 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7519,21 +7519,25 @@ int sched_cpu_starting(unsigned int cpu)
struct rq *rq, *core_rq = NULL;
int i;
- for_each_cpu(i, smt_mask) {
- rq = cpu_rq(i);
- if (rq->core && rq->core == rq)
- core_rq = rq;
- init_irq_work(>core_irq_work, sched_core_irq_work);
- }
+ core_rq = cpu_rq(cpu)->core;
+
+ if (!core_rq) {
+ for_each_cpu(i, smt_mask) {
+ rq = cpu_rq(i);
+ if (rq->core && rq->core == rq)
+ core_rq = rq;
+ init_irq_work(>core_irq_work, sched_core_irq_work);
+ }
- if (!core_rq)
- core_rq = cpu_rq(cpu);
+ if (!core_rq)
+ core_rq = cpu_rq(cpu);
- for_each_cpu(i, smt_mask) {
- rq = cpu_rq(i);
+ for_each_cpu(i, smt_mask) {
+ rq = cpu_rq(i);
- WARN_ON_ONCE(rq->core && rq->core != core_rq);
- rq->core = core_rq;
+ WARN_ON_ONCE(rq->core && rq->core != core_rq);
+ rq->core = core_rq;
+ }
}
printk("core: %d -> %d\n", cpu, cpu_of(core_rq));
--
2.28.0.220.ged08abb693-goog
Re: [RFC PATCH] vsprintf: Add %pv extension replacement for print_vma_addr
Cc-ing John
On (20/08/14 10:53), Joe Perches wrote:
[..]
In general, the idea looks nice.
> +static noinline_for_stack
> +char *vma_addr(char *buf, char *end, void *ip,
> +struct printf_spec spec, const char *fmt)
> +{
> +#ifdef CONFIG_MMU
> + struct mm_struct *mm = current->mm;
> + struct vm_area_struct *vma;
> +
> + /*
> + * we might be running from an atomic context so we cannot sleep
> + */
> + if (!mmap_read_trylock(mm))
> + return buf;
> +
> + vma = find_vma(mm, (unsigned long)ip);
> + if (vma && vma->vm_file) {
> + char *p;
> + struct file *f = vma->vm_file;
> + char *page = (char *)__get_free_page(GFP_NOWAIT);
Hmm, this is huge. For the time being this is going to introduce lock
inversion chains:
PRINTK -> printk_locks -> MM -> mm_locks
vs
MM -> mm_locks -> PRINTK -> printk_locks
Another thing to mention is
PRINTK -> printk_locks -> MM (WANR_ON/etc) -> PRINTK
we are in printk_safe, currently, but that's going to change.
We might not be ready to take this as of now, but things can change
once we drop printk_locks.
> + if (page) {
> + p = file_path(f, page, PAGE_SIZE);
> + if (IS_ERR(p))
> + p = "?";
> + buf = string(buf, end, kbasename(p), default_str_spec);
> + buf = string_nocheck(buf, end, "[", default_str_spec);
> + buf = pointer_string(buf, end,
> + (void *)vma->vm_start,
> + default_hex_spec);
> + buf = string_nocheck(buf, end, "+", default_str_spec);
> + buf = pointer_string(buf, end,
> + (void *)(vma->vm_end -
> vma->vm_start),
> + default_hex_spec);
> + buf = string_nocheck(buf, end, "]", default_str_spec);
> + free_page((unsigned long)page);
> + }
> + }
> + mmap_read_unlock(mm);
> +#else
> + buf = string_nocheck(buf, end, "CONFIG_MMU=n", default_str_spec);
Hmm, we don't usually do that CONFIG_FOO=n thing, I think we just need
to skip %pv and print nothing. Otherwise on !CONFIG_MMU systems the logbuf
may contain a number of CONFIG_MMU=n messages, which are hardly useful.
> +#endif
> + return buf;
> +}
> +
> /*
> * Show a '%p' thing. A kernel extension is that the '%p' is followed
> * by an extra set of alphanumeric characters that are extended format
> @@ -2254,6 +2304,8 @@ char *pointer(const char *fmt, char *buf, char *end,
> void *ptr,
> return uuid_string(buf, end, ptr, spec, fmt);
> case 'V':
> return va_format(buf, end, ptr, spec, fmt);
+ #ifdef CONFIG_MMU
> + case 'v':
> + return vma_addr(buf, end, ptr, spec, fmt);
+ #endif
> case 'K':
> return restricted_pointer(buf, end, ptr, spec);
> case 'N':
-ss
[PATCH] platform: cros_ec: Reduce ligthbar get version command
By default, the lightbar commands are set to the
biggest lightbar command and response. That length is greater than 128
bytes and may not work on all machines.
But all EC are probed for lightbar by sending a get version request.
Set that request size precisely.
BUG=chromium:160662061
TEST=Before the command would be:
cros_ec_cmd: version: 0, command: EC_CMD_LIGHTBAR_CMD, outsize: 194, insize:
128, result: 0
Afer:
cros_ec_cmd: version: 0, command: EC_CMD_LIGHTBAR_CMD, outsize: 1, insize: 8,
result: 0
Signed-off-by: Gwendal Grignou
---
drivers/platform/chrome/cros_ec_lightbar.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/platform/chrome/cros_ec_lightbar.c
b/drivers/platform/chrome/cros_ec_lightbar.c
index b59180bff5a3e..ef61298c30bdd 100644
--- a/drivers/platform/chrome/cros_ec_lightbar.c
+++ b/drivers/platform/chrome/cros_ec_lightbar.c
@@ -116,6 +116,8 @@ static int get_lightbar_version(struct cros_ec_dev *ec,
param = (struct ec_params_lightbar *)msg->data;
param->cmd = LIGHTBAR_CMD_VERSION;
+ msg->outsize = sizeof(param->cmd);
+ msg->result = sizeof(resp->version);
ret = cros_ec_cmd_xfer_status(ec->ec_dev, msg);
if (ret < 0) {
ret = 0;
--
2.28.0.220.ged08abb693-goog
Re: [PATCH v2] x86/boot/compressed: Disable relocation relaxation
On Wed, Aug 12, 2020 at 2:43 AM Arvind Sankar wrote: > > The x86-64 psABI [0] specifies special relocation types > (R_X86_64_[REX_]GOTPCRELX) for indirection through the Global Offset > Table, semantically equivalent to R_X86_64_GOTPCREL, which the linker > can take advantage of for optimization (relaxation) at link time. This > is supported by LLD and binutils versions 2.26 onwards. > > The compressed kernel is position-independent code, however, when using > LLD or binutils versions before 2.27, it must be linked without the -pie > option. In this case, the linker may optimize certain instructions into > a non-position-independent form, by converting foo@GOTPCREL(%rip) to $foo. > > This potential issue has been present with LLD and binutils-2.26 for a > long time, but it has never manifested itself before now: > - LLD and binutils-2.26 only relax > movqfoo@GOTPCREL(%rip), %reg > to > leaqfoo(%rip), %reg > which is still position-independent, rather than > mov $foo, %reg > which is permitted by the psABI when -pie is not enabled. > - gcc happens to only generate GOTPCREL relocations on mov instructions. > - clang does generate GOTPCREL relocations on non-mov instructions, but > when building the compressed kernel, it uses its integrated assembler > (due to the redefinition of KBUILD_CFLAGS dropping -no-integrated-as), > which has so far defaulted to not generating the GOTPCRELX > relocations. > > Nick Desaulniers reports [1,2]: > A recent change [3] to a default value of configuration variable > (ENABLE_X86_RELAX_RELOCATIONS OFF -> ON) in LLVM now causes Clang's > integrated assembler to emit R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX > relocations. LLD will relax instructions with these relocations based > on whether the image is being linked as position independent or not. > When not, then LLD will relax these instructions to use absolute > addressing mode (R_RELAX_GOT_PC_NOPIC). This causes kernels built with > Clang and linked with LLD to fail to boot. > > Patch series [4] is a solution to allow the compressed kernel to be > linked with -pie unconditionally, but even if merged is unlikely to be > backported. As a simple solution that can be applied to stable as well, > prevent the assembler from generating the relaxed relocation types using > the -mrelax-relocations=no option. For ease of backporting, do this > unconditionally. > > [0] > https://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/master/x86-64-ABI/linker-optimization.tex#L65 > [1] > https://lore.kernel.org/lkml/20200807194100.3570838-1-ndesaulni...@google.com/ > [2] https://github.com/ClangBuiltLinux/linux/issues/1121 > [3] https://reviews.llvm.org/rGc41a18cf61790fc898dcda1055c3efbf442c14c0 > [4] > https://lore.kernel.org/lkml/20200731202738.2577854-1-nived...@alum.mit.edu/ > > Signed-off-by: Arvind Sankar > Reported-by: Nick Desaulniers > Reviewed-by: Nick Desaulniers > Tested-by: Nick Desaulniers > Cc: sta...@vger.kernel.org > Signed-off-by: Arvind Sankar Thanks for the patch. Tested-by: Sedat Dilek - Sedat - [1] https://github.com/ClangBuiltLinux/linux/issues/1120#issuecomment-674409705 > --- > arch/x86/boot/compressed/Makefile | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/x86/boot/compressed/Makefile > b/arch/x86/boot/compressed/Makefile > index 3962f592633d..ff7894f39e0e 100644 > --- a/arch/x86/boot/compressed/Makefile > +++ b/arch/x86/boot/compressed/Makefile > @@ -43,6 +43,8 @@ KBUILD_CFLAGS += -Wno-pointer-sign > KBUILD_CFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=) > KBUILD_CFLAGS += -fno-asynchronous-unwind-tables > KBUILD_CFLAGS += -D__DISABLE_EXPORTS > +# Disable relocation relaxation in case the link is not PIE. > +KBUILD_CFLAGS += $(call as-option,-Wa$(comma)-mrelax-relocations=no) > > KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ > GCOV_PROFILE := n > -- > 2.26.2 > > -- > You received this message because you are subscribed to the Google Groups > "Clang Built Linux" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clang-built-linux+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/clang-built-linux/20200812004308.1448603-1-nivedita%40alum.mit.edu.
Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag
Paul, On Fri, Aug 14 2020 at 16:41, Paul E. McKenney wrote: > On Sat, Aug 15, 2020 at 01:14:53AM +0200, Thomas Gleixner wrote: >> As a matter of fact I assume^Wdeclare that removing struct rcu_head which >> provides a fallback is not an option at all. I know that you want to, >> but it wont work ever. Dream on, but as we agreed on recently there is >> this thing called reality which ruins everything. > > For call_rcu(), agreed. For kfree_rcu(), we know what the callback is > going to do, plus single-argument kfree_rcu() can only be invoked from > sleepable context. (If you want to kfree_rcu() from non-sleepable > context, that will cost you an rcu_head in the data structure being > freed.) kfree_rcu() as of today is just a conveniance wrapper around call_rcu(obj, rcu) which can be called from any context and it still takes TWO arguments. Icepack? So if you come up with a new kfree_rcu_magic(void *obj) single argument variant which can only be called from sleepable contexts then this does not require any of the raw lock vs. non raw hacks at all because you can simply allocate without holding the raw lock in the rare case that you run out of storage space. With four 4k pages preallocated per CPU that's every 2048 invocations per CPU on 64bit. So if you run into that situation then you drop the lock and then it's racy because you might be preempted or migrated after dropping the lock and you might have done a useless allocation, but that does not justify having a special allocator just for that? You have an extra page, so what? To prevent subsequent callers to add to the allocation race you simply can let them wait on the first allocating attempt to finish That avoids more pointless allocations and as a side effect prevents all of them to create more pressure by continuing their open/close loop naturally without extra work. > So if the single-argument kfree_rcu() case gets hit with a > memory-allocation failure, it can fall back to waiting for a grace > period and doing the free. Of course, grace-period waits have horrible > latency, but under OOM life is hard. If this becomes a problem in > non-OOM situations due to the lockless caches becoming empty, we will > have to allocate memory if needed before acquiring the lock with the > usual backout logic. Doing that means that we can let the allocator > acquire locks and maybe even do a little bit of blocking, so that the > inline grace-period-wait would only happen if the system was well and > truly OOMed. No. It dropped the rcu internal lock and does a regular GFP_KENRNEL allocation which waits for the page to become available. Which is a good thing in the open/close scenario because it throttles the offender. >> For normal operations a couple of pages which can be preallocated are >> enough. What you are concerned of is the case where you run out of >> pointer storage space. > > Agreed. > >> There are two reasons why that can happen: >> >> 1) RCU call flooding >> 2) RCU not being able to run and mop up the backlog >> >> #1 is observable by looking at the remaining storage space and the RCU >>call frequency >> >> #2 is uninteresting because it's caused by RCU being stalled / delayed >>e.g. by a runaway of some sorts or a plain RCU usage bug. >> >>Allocating more memory in that case does not solve or improve anything. > > Yes, #2 is instead RCU CPU stall warning territory. > > If this becomes a problem, one approach is to skip the page-of-pointers > allocation if the grace period is more than (say) one second old. If > the grace period never completes, OOM is unavoidable, but this is a way > of putting it off for a bit. Don't even think about optimizing your new thing for #2. It's a pointless exercise. If the task which runs into the 'can't allocate' case then is sleeps and waits. End of story. >> So the interesting case is #1. Which means we need to look at the >> potential sources of the flooding: >> >> 1) User space via syscalls, e.g. open/close >> 2) Kernel thread >> 3) Softirq >> 4) Device interrupt >> 5) System interrupts, deep atomic context, NMI ... >> >> #1 trivial fix is to force switching to an high prio thread or a soft >>interrupt which does the allocation >> >> #2 Similar to #1 unless that thread loops with interrupts, softirqs or >>preemption disabled. If that's the case then running out of RCU >>storage space is the least of your worries. >> >> #3 Similar to #2. The obvious candidates (e.g. NET) for monopolizing a >>CPU have loop limits in place already. If there is a bug which fails >>to care about the limit, why would RCU care and allocate more memory? >> >> #4 Similar to #3. If the interrupt handler loops forever or if the >>interrupt is a runaway which prevents task/softirq processing then >>RCU free performance is the least of your worries. >> >> #5 Clearly a bug and making RCU accomodate for that is beyond silly. >> >> So if call_rcu()
[RFC PATCH v1 1/2] ASoC: rockchip-spdif: add description for rk3308
A test with the command below shows that the compatible string
"rockchip,rk3308-spdif", "rockchip,rk3328-spdif"
is already in use, but is not added to a document.
The current fallback string "rockchip,rk3328-spdif" points to a data
set enum RK_SPDIF_RK3366 in rockchip_spdif.c that is not used both
in the mainline as in the manufacturer kernel.
(Of the enum only RK_SPDIF_RK3288 is used.)
So if the properties don't change we might as well use the first SoC
in line as fallback string and add the description for rk3308 as:
"rockchip,rk3308-spdif", "rockchip,rk3066-spdif"
make ARCH=arm64 dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/sound/rockchip-spdif.yaml
Signed-off-by: Johan Jonker
---
enum rk_spdif_type {
RK_SPDIF_RK3066,
RK_SPDIF_RK3188,
RK_SPDIF_RK3288,
RK_SPDIF_RK3366,
};
static const struct of_device_id rk_spdif_match[] = {
{ .compatible = "rockchip,rk3066-spdif",
.data = (void *)RK_SPDIF_RK3066 },
{ .compatible = "rockchip,rk3188-spdif",
.data = (void *)RK_SPDIF_RK3188 },
{ .compatible = "rockchip,rk3228-spdif",
.data = (void *)RK_SPDIF_RK3366 },
{ .compatible = "rockchip,rk3288-spdif",
.data = (void *)RK_SPDIF_RK3288 },
{ .compatible = "rockchip,rk3328-spdif",
.data = (void *)RK_SPDIF_RK3366 },
{ .compatible = "rockchip,rk3366-spdif",
.data = (void *)RK_SPDIF_RK3366 },
{ .compatible = "rockchip,rk3368-spdif",
.data = (void *)RK_SPDIF_RK3366 },
{ .compatible = "rockchip,rk3399-spdif",
.data = (void *)RK_SPDIF_RK3366 },
{},
};
---
Documentation/devicetree/bindings/sound/rockchip-spdif.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml
b/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml
index c46715265..26e986097 100644
--- a/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml
+++ b/Documentation/devicetree/bindings/sound/rockchip-spdif.yaml
@@ -27,6 +27,7 @@ properties:
- enum:
- rockchip,rk3188-spdif
- rockchip,rk3288-spdif
+- rockchip,rk3308-spdif
- const: rockchip,rk3066-spdif
reg:
--
2.11.0
Re: [PATCH] lib/string.c: implement stpcpy
On Fri, Aug 14, 2020 at 09:33:10PM -0400, Arvind Sankar wrote:
> On Fri, Aug 14, 2020 at 05:24:15PM -0700, Nick Desaulniers wrote:
> > +#ifndef __HAVE_ARCH_STPCPY
> > +/**
> > + * stpcpy - copy a string from src to dest returning a pointer to the new
> > end
> > + * of dest, including src's NULL terminator. May overrun dest.
> > + * @dest: pointer to end of string being copied into. Must be large enough
> > + *to receive copy.
> > + * @src: pointer to the beginning of string being copied from. Must not
> > overlap
> > + * dest.
> > + *
> > + * stpcpy differs from strcpy in two key ways:
> > + * 1. inputs must not overlap.
> > + * 2. return value is the new NULL terminated character. (for strcpy, the
> > + *return value is a pointer to src.
> > + */
> > +#undef stpcpy
> > +char *stpcpy(char *__restrict__ dest, const char *__restrict__ src)
> > +{
> > + while ((*dest++ = *src++) != '\0')
> > + /* nothing */;
> > + return dest;
> > +}
> > +#endif
> > +
>
> Won't this return a pointer that's one _past_ the terminating NUL? I
> think you need the increments to be inside the loop body, rather than as
> part of the condition.
>
> Nit: NUL is more correct than NULL to refer to the string terminator.
Also, strcpy (at least the one in the C standard) is undefined if the
strings overlap, so that's not really a difference.
Re: [PATCH RFC 0/2] Break heap spraying needed for exploiting use-after-free
On Thu, Aug 13, 2020 at 06:19:20PM +0300, Alexander Popov wrote: > I've found an easy way to break heap spraying for use-after-free > exploitation. I simply extracted slab freelist quarantine from KASAN > functionality and called it CONFIG_SLAB_QUARANTINE. Please see patch 1. Ah yeah, good idea. :) > [...] > I did a brief performance evaluation of this feature. > > 1. Memory consumption. KASAN quarantine uses 1/32 of the memory. > CONFIG_SLAB_QUARANTINE disabled: > # free -m > totalusedfree shared buff/cache > available > Mem: 1987 391862 10 86 > 1907 > Swap: 0 0 0 > CONFIG_SLAB_QUARANTINE enabled: > # free -m > totalusedfree shared buff/cache > available > Mem: 1987 1401760 10 87 > 1805 > Swap: 0 0 0 1/32 of memory doesn't seem too bad for someone interested in this defense. > 2. Performance penalty. I used `hackbench -s 256 -l 200 -g 15 -f 25 -P`. > CONFIG_SLAB_QUARANTINE disabled (x86_64, CONFIG_SLUB): > Times: 3.088, 3.103, 3.068, 3.103, 3.107 > Mean: 3.0938 > Standard deviation: 0.0144 > CONFIG_SLAB_QUARANTINE enabled (x86_64, CONFIG_SLUB): > Times: 3.303, 3.329, 3.356, 3.314, 3.292 > Mean: 3.3188 (+7.3%) > Standard deviation: 0.0223 That's rather painful, but hackbench can produce some big deltas given it can be an unrealistic workload for most systems. I'd be curious to see the "building a kernel" timings, which tends to be much more realistic for "busy system" without hammering one particular subsystem (though it's a bit VFS heavy, obviously). More notes in the patches... -- Kees Cook
[PATCH 5/9] habanalabs: use FIELD_PREP() instead of <
Use the standard FIELD_PREP() macro instead of << operator to perform bitmask operations. This ensures type check safety and eliminate compiler warnings. Reported-by: kernel test robot Signed-off-by: Oded Gabbay --- drivers/misc/habanalabs/common/hw_queue.c | 9 +- drivers/misc/habanalabs/gaudi/gaudi.c | 50 ++-- .../habanalabs/include/gaudi/gaudi_masks.h| 274 -- 3 files changed, 154 insertions(+), 179 deletions(-) diff --git a/drivers/misc/habanalabs/common/hw_queue.c b/drivers/misc/habanalabs/common/hw_queue.c index 65b9aa69a83e..e2f9ba04b32d 100644 --- a/drivers/misc/habanalabs/common/hw_queue.c +++ b/drivers/misc/habanalabs/common/hw_queue.c @@ -8,6 +8,7 @@ #include "habanalabs.h" #include +#include /* * hl_queue_add_ptr - add to pi or ci and checks if it wraps around @@ -288,10 +289,10 @@ static void ext_queue_schedule_job(struct hl_cs_job *job) ptr = cb->bus_address; cq_pkt.data = cpu_to_le32( - ((q->pi << CQ_ENTRY_SHADOW_INDEX_SHIFT) - & CQ_ENTRY_SHADOW_INDEX_MASK) | - (1 << CQ_ENTRY_SHADOW_INDEX_VALID_SHIFT) | - (1 << CQ_ENTRY_READY_SHIFT)); + ((q->pi << CQ_ENTRY_SHADOW_INDEX_SHIFT) + & CQ_ENTRY_SHADOW_INDEX_MASK) | + FIELD_PREP(CQ_ENTRY_SHADOW_INDEX_VALID_MASK, 1) | + FIELD_PREP(CQ_ENTRY_READY_MASK, 1)); /* * No need to protect pi_offset because scheduling to the diff --git a/drivers/misc/habanalabs/gaudi/gaudi.c b/drivers/misc/habanalabs/gaudi/gaudi.c index 6febfe4fdd81..ed289a6ed622 100644 --- a/drivers/misc/habanalabs/gaudi/gaudi.c +++ b/drivers/misc/habanalabs/gaudi/gaudi.c @@ -659,10 +659,10 @@ static int _gaudi_init_tpc_mem(struct hl_device *hdev, init_tpc_mem_pkt->tsize = cpu_to_le32(tpc_kernel_size); - ctl = ((PACKET_LIN_DMA << GAUDI_PKT_CTL_OPCODE_SHIFT) | - (1 << GAUDI_PKT_LIN_DMA_CTL_LIN_SHIFT) | - (1 << GAUDI_PKT_CTL_RB_SHIFT) | - (1 << GAUDI_PKT_CTL_MB_SHIFT)); + ctl = FIELD_PREP(GAUDI_PKT_CTL_OPCODE_MASK, PACKET_LIN_DMA); + ctl |= FIELD_PREP(GAUDI_PKT_LIN_DMA_CTL_LIN_MASK, 1); + ctl |= FIELD_PREP(GAUDI_PKT_CTL_RB_MASK, 1); + ctl |= FIELD_PREP(GAUDI_PKT_CTL_MB_MASK, 1); init_tpc_mem_pkt->ctl = cpu_to_le32(ctl); @@ -2305,7 +2305,8 @@ static void gaudi_init_tpc_qmans(struct hl_device *hdev) tpc_offset += mmTPC1_QM_GLBL_CFG0 - mmTPC0_QM_GLBL_CFG0; - gaudi->hw_cap_initialized |= 1 << (HW_CAP_TPC_SHIFT + tpc_id); + gaudi->hw_cap_initialized |= + FIELD_PREP(HW_CAP_TPC_MASK, 1 << tpc_id); } } @@ -2886,13 +2887,13 @@ static void gaudi_pre_hw_init(struct hl_device *hdev) (CFG_RST_H_DMA_MASK | CFG_RST_H_MME_MASK | CFG_RST_H_SM_MASK | - CFG_RST_H_TPC_MASK)); + CFG_RST_H_TPC_7_MASK)); WREG32(mmPSOC_GLOBAL_CONF_SOFT_RST_CFG_L, CFG_RST_L_TPC_MASK); WREG32(mmPSOC_GLOBAL_CONF_SW_ALL_RST_CFG_H, (CFG_RST_H_HBM_MASK | - CFG_RST_H_TPC_MASK | + CFG_RST_H_TPC_7_MASK | CFG_RST_H_NIC_MASK | CFG_RST_H_SM_MASK | CFG_RST_H_DMA_MASK | @@ -3445,9 +3446,10 @@ static int gaudi_test_queue(struct hl_device *hdev, u32 hw_queue_id) goto free_fence_ptr; } - tmp = (PACKET_MSG_PROT << GAUDI_PKT_CTL_OPCODE_SHIFT) | - (1 << GAUDI_PKT_CTL_EB_SHIFT) | - (1 << GAUDI_PKT_CTL_MB_SHIFT); + tmp = FIELD_PREP(GAUDI_PKT_CTL_OPCODE_MASK, PACKET_MSG_PROT); + tmp |= FIELD_PREP(GAUDI_PKT_CTL_EB_MASK, 1); + tmp |= FIELD_PREP(GAUDI_PKT_CTL_MB_MASK, 1); + fence_pkt->ctl = cpu_to_le32(tmp); fence_pkt->value = cpu_to_le32(fence_val); fence_pkt->addr = cpu_to_le64(fence_dma_addr); @@ -4252,11 +4254,11 @@ static void gaudi_add_end_of_cb_packets(struct hl_device *hdev, cq_pkt = (struct packet_msg_prot *) (uintptr_t) (kernel_address + len - (sizeof(struct packet_msg_prot) * 2)); - tmp = (PACKET_MSG_PROT << GAUDI_PKT_CTL_OPCODE_SHIFT) | - (1 << GAUDI_PKT_CTL_MB_SHIFT); + tmp = FIELD_PREP(GAUDI_PKT_CTL_OPCODE_MASK, PACKET_MSG_PROT); + tmp |= FIELD_PREP(GAUDI_PKT_CTL_MB_MASK, 1); if (eb) - tmp |= (1 << GAUDI_PKT_CTL_EB_SHIFT); + tmp |= FIELD_PREP(GAUDI_PKT_CTL_EB_MASK,
[PATCH v2] lib/string.c: implement stpcpy
LLVM implemented a recent "libcall optimization" that lowers calls to
`sprintf(dest, "%s", str)` where the return value is used to
`stpcpy(dest, str) - dest`. This generally avoids the machinery involved
in parsing format strings. Calling `sprintf` with overlapping arguments
was clarified in ISO C99 and POSIX.1-2001 to be undefined behavior.
`stpcpy` is just like `strcpy` except it returns the pointer to the new
tail of `dest`. This allows you to chain multiple calls to `stpcpy` in
one statement.
`stpcpy` was first standardized in POSIX.1-2008.
Implement this so that we don't observe linkage failures due to missing
symbol definitions for `stpcpy`.
Similar to last year's fire drill with:
commit 5f074f3e192f ("lib/string.c: implement a basic bcmp")
This optimization was introduced into clang-12.
Cc: sta...@vger.kernel.org
Link: https://bugs.llvm.org/show_bug.cgi?id=47162
Link: https://github.com/ClangBuiltLinux/linux/issues/1126
Link: https://man7.org/linux/man-pages/man3/stpcpy.3.html
Link: https://pubs.opengroup.org/onlinepubs/9699919799/functions/stpcpy.html
Link: https://reviews.llvm.org/D85963
Suggested-by: Arvind Sankar
Suggested-by: Joe Perches
Reported-by: Sami Tolvanen
Tested-by: Sami Tolvanen
Signed-off-by: Nick Desaulniers
---
Changes V2:
* Added Sami's Tested by; though the patch changed implementation, the
missing symbol at link time was the problem Sami was observing.
* Fix __restrict -> __restrict__ typo as per Joe.
* Drop note about restrict from commit message as per Arvind.
* Fix NULL -> NUL as per Arvind; NUL is ASCII '\0'. TIL
* Fix off by one error as per Arvind; I had another off by one error in
my test program that was masking this.
include/linux/string.h | 3 +++
lib/string.c | 23 +++
2 files changed, 26 insertions(+)
diff --git a/include/linux/string.h b/include/linux/string.h
index b1f3894a0a3e..7686dbca8582 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -31,6 +31,9 @@ size_t strlcpy(char *, const char *, size_t);
#ifndef __HAVE_ARCH_STRSCPY
ssize_t strscpy(char *, const char *, size_t);
#endif
+#ifndef __HAVE_ARCH_STPCPY
+extern char *stpcpy(char *__restrict__, const char *__restrict__);
+#endif
/* Wraps calls to strscpy()/memset(), no arch specific code required */
ssize_t strscpy_pad(char *dest, const char *src, size_t count);
diff --git a/lib/string.c b/lib/string.c
index 6012c385fb31..68ddbffbbd58 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -272,6 +272,29 @@ ssize_t strscpy_pad(char *dest, const char *src, size_t
count)
}
EXPORT_SYMBOL(strscpy_pad);
+#ifndef __HAVE_ARCH_STPCPY
+/**
+ * stpcpy - copy a string from src to dest returning a pointer to the new end
+ * of dest, including src's NUL terminator. May overrun dest.
+ * @dest: pointer to end of string being copied into. Must be large enough
+ *to receive copy.
+ * @src: pointer to the beginning of string being copied from. Must not overlap
+ * dest.
+ *
+ * stpcpy differs from strcpy in two key ways:
+ * 1. inputs must not overlap.
+ * 2. return value is the new NULL terminated character. (for strcpy, the
+ *return value is a pointer to src.
+ */
+#undef stpcpy
+char *stpcpy(char *__restrict__ dest, const char *__restrict__ src)
+{
+ while ((*dest++ = *src++) != '\0')
+ /* nothing */;
+ return --dest;
+}
+#endif
+
#ifndef __HAVE_ARCH_STRCAT
/**
* strcat - Append one %NUL-terminated string to another
--
2.28.0.220.ged08abb693-goog
Re: [PATCH 2/2] tree-wide: rename vmemdup_user to kvmemdup_user
On Sat, Aug 15, 2020 at 03:10:12PM +0200, Markus Elfring wrote: > > This helper uses kvmalloc, not vmalloc, so rename it to kvmemdup_user to > > make it clear we're using kvmalloc() and will need to use kvfree(). > > Can the renaming of this function name trigger software updates > for any more source files? Why don't you find out, and if there are, submit your own patch? > Example: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/coccinelle/api/memdup_user.cocci?id=c9c9735c46f589b9877b7fc00c89ef1b61a31e18#n18 > > Regards, > Markus
Hello
Hello My name is Jenifer Alex Please reply, so that we can know more better and share photos, Thank you.
[GIT PULL] SMB3 fixes
Please pull the following changes since commit 327a8d76b1ac2037f87bf041f3bc076407284ffc: Merge tag '5.9-rc-smb3-fixes-part1' of git://git.samba.org/sfrench/cifs-2.6 (2020-08-06 19:21:04 -0700) are available in the Git repository at: git://git.samba.org/sfrench/cifs-2.6.git tags/5.9-rc-smb3-fixes-part2 for you to fetch changes up to c8c412f976124d85b8ded85c6ac3f760c12b63a3: SMB3: Fix mkdir when idsfromsid configured on mount (2020-08-13 19:41:01 -0500) 3 small cifs/smb3 fixes, one for stable fixing a mkdir path when using idsfromsid mount option The update for cifs.ko to use the new mount API isn't complete so isn't included in this set. Build verification test results: http://smb3-test-rhel-75.southcentralus.cloudapp.azure.com/#/builders/2/builds/381 Dan Carpenter (1): cifs: Fix an error pointer dereference in cifs_mount() Miaohe Lin (1): cifs: Convert to use the fallthrough macro Steve French (1): SMB3: Fix mkdir when idsfromsid configured on mount fs/cifs/connect.c | 1 + fs/cifs/smb2inode.c | 1 + fs/cifs/smb2pdu.c | 4 ++-- 3 files changed, 4 insertions(+), 2 deletions(-) -- Thanks, Steve
KMSAN: uninit-value in hci_chan_lookup_handle
Hello, syzbot found the following issue on: HEAD commit:ce8056d1 wip: changed copy_from_user where instrumented git tree: https://github.com/google/kmsan.git master console output: https://syzkaller.appspot.com/x/log.txt?x=16c0e1e290 kernel config: https://syzkaller.appspot.com/x/.config?x=3afe005fb99591f dashboard link: https://syzkaller.appspot.com/bug?extid=4c14a8f574461e1c3659 compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16fd6aa690 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=105910ce90 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+4c14a8f574461e1c3...@syzkaller.appspotmail.com = BUG: KMSAN: uninit-value in __hci_chan_lookup_handle net/bluetooth/hci_conn.c:1741 [inline] BUG: KMSAN: uninit-value in hci_chan_lookup_handle+0x1e3/0x310 net/bluetooth/hci_conn.c:1757 CPU: 0 PID: 8496 Comm: kworker/u5:2 Not tainted 5.8.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: hci0 hci_rx_work Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 __hci_chan_lookup_handle net/bluetooth/hci_conn.c:1741 [inline] hci_chan_lookup_handle+0x1e3/0x310 net/bluetooth/hci_conn.c:1757 hci_disconn_loglink_complete_evt net/bluetooth/hci_event.c:4992 [inline] hci_event_packet+0x14e10/0x39d30 net/bluetooth/hci_event.c:6176 hci_rx_work+0x6df/0xd30 net/bluetooth/hci_core.c:4705 process_one_work+0x1688/0x2140 kernel/workqueue.c:2269 worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415 kthread+0x551/0x590 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:144 [inline] kmsan_internal_poison_shadow+0x66/0xd0 mm/kmsan/kmsan.c:127 kmsan_slab_alloc+0x8a/0xe0 mm/kmsan/kmsan_hooks.c:80 slab_alloc_node mm/slub.c:2839 [inline] __kmalloc_node_track_caller+0xeab/0x12e0 mm/slub.c:4478 __kmalloc_reserve net/core/skbuff.c:142 [inline] __alloc_skb+0x35f/0xb30 net/core/skbuff.c:210 alloc_skb include/linux/skbuff.h:1083 [inline] bt_skb_alloc include/net/bluetooth/bluetooth.h:377 [inline] vhci_get_user drivers/bluetooth/hci_vhci.c:165 [inline] vhci_write+0x18a/0x890 drivers/bluetooth/hci_vhci.c:285 call_write_iter include/linux/fs.h:1908 [inline] new_sync_write fs/read_write.c:503 [inline] vfs_write+0xf9a/0x17c0 fs/read_write.c:578 ksys_write+0x275/0x500 fs/read_write.c:631 __do_sys_write fs/read_write.c:643 [inline] __se_sys_write+0x92/0xb0 fs/read_write.c:640 __x64_sys_write+0x4a/0x70 fs/read_write.c:640 do_syscall_64+0xad/0x160 arch/x86/entry/common.c:386 entry_SYSCALL_64_after_hwframe+0x44/0xa9 = --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: POC: Alternative solution: Re: [PATCH 0/4] printk: reimplement LOG_CONT handling
On Fri, 2020-08-14 at 19:33 -0700, Linus Torvalds wrote: > On Fri, Aug 14, 2020 at 4:52 PM Joe Perches wrote: > > On Fri, 2020-08-14 at 15:46 -0700, Linus Torvalds wrote: > > > This is why I think any discussion that says "people should buffer > > > their lines themselves and we should get rid if pr_cont()" is > > > fundamentally broken. > > > > > > Don't go down that hole. I won't take it. It's wrong. > > > > I don't think it's wrong per se. > > It's *absolutely* and 100% wrong. > > Yes, any random *user* of pr_cont() can decide to buffer on it's own. Which I believe is the point of the discussion, not the complete removal of KERN_CONT. > But when the discussion is about printk() - the implementation, not > the users - then it's complete and utter BS to talk about trying to > get rid of pr_cont(). > > See the difference? Sure, but I fail to see where anyone said get rid of pr_cont in this thread. It seems all that was discussed was just various schemes to improve coalescing output.
[PATCH] MAINTAINERS: mention documentation maintainer entry profile
Since commit 53b7f3aa411b ("Add a maintainer entry profile for
documentation"), the documentation "subsystem" has a maintainer entry
profile, and it deserves to be mentioned in MAINTAINERS with a suitable
P: entry.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on docs-next, and was checkpatch-ed.
Jonathan, please pick this patch.
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f520202fa1ef..8aa1369d5926 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5178,6 +5178,7 @@ DOCUMENTATION
M: Jonathan Corbet
L: linux-...@vger.kernel.org
S: Maintained
+P: Documentation/doc-guide/maintainer-profile.rst
T: git git://git.lwn.net/linux.git docs-next
F: Documentation/
F: scripts/documentation-file-ref-check
--
2.17.1
Re: [GIT PULL v2] MFD for v5.9
On Fri, Aug 14, 2020 at 7:42 AM Lee Jones wrote: > > Here is the new pull request. It has been tested; locally, by > TuxBuild and the Intel 'kernel test robot' [0]. Please consider this for > addition into v5.9. All of these patches have also soak tested in > -next for a considerable amount of time. I'm extremely annoyed by this all, but I've pulled this. Please just *STOP* doing any W=1 fixes (and most definitely W=2 ones - many of those warnings are just plain garbage and indicate more about the compiler than they do about the code) if you can't then make damn sure that the warnings that actually matter are always *ALWAY* taken care of. I absolutely abhor warnings in the default build, just because they only result in people ignoring them. Which is exactly what happened bvecause you then tried to care about the more-or-less worthless W=1 ones. So a clean build is really important to me. And developers who don't check and follow up on warnings in the normal build are something that pisses me off no end. Now something like 25 commits are pointlessly rebased just because you didn't check warnings properly. Linus
[PATCH 2/2] net: socket: implement SO_DESCRIPTION
This command attaches the zero terminated string in optval to the
socket for troubleshooting purposes. The free string is displayed in the
process fdinfo file for that fd (/proc//fdinfo/).
One intended usage is to allow processes to self-document sockets
for netstat and friends to report
We ignore optlen and constrain the string to a static max size
Signed-off-by: Pascal Bouchareine
---
include/net/sock.h| 4
include/uapi/asm-generic/socket.h | 2 ++
net/core/sock.c | 23 +++
net/socket.c | 5 +
4 files changed, 34 insertions(+)
diff --git a/include/net/sock.h b/include/net/sock.h
index 1183507df95b..6b4fd1383282 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -342,6 +342,7 @@ struct bpf_sk_storage;
*@sk_txtime_deadline_mode: set deadline mode for SO_TXTIME
*@sk_txtime_report_errors: set report errors mode for SO_TXTIME
*@sk_txtime_unused: unused txtime flags
+ *@sk_description: user supplied with SO_DESCRIPTION
*/
struct sock {
/*
@@ -519,6 +520,9 @@ struct sock {
struct bpf_sk_storage __rcu *sk_bpf_storage;
#endif
struct rcu_head sk_rcu;
+
+#defineSK_MAX_DESC_SIZE256
+ char*sk_description;
};
enum sk_pacing {
diff --git a/include/uapi/asm-generic/socket.h
b/include/uapi/asm-generic/socket.h
index 77f7c1638eb1..fb51c4bb7a12 100644
--- a/include/uapi/asm-generic/socket.h
+++ b/include/uapi/asm-generic/socket.h
@@ -119,6 +119,8 @@
#define SO_DETACH_REUSEPORT_BPF 68
+#define SO_DESCRIPTION 69
+
#if !defined(__KERNEL__)
#if __BITS_PER_LONG == 64 || (defined(__x86_64__) && defined(__ILP32__))
diff --git a/net/core/sock.c b/net/core/sock.c
index 2e5b7870e5d3..2cb44a0e38b7 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -828,6 +828,24 @@ void sock_set_rcvbuf(struct sock *sk, int val)
}
EXPORT_SYMBOL(sock_set_rcvbuf);
+int sock_set_description(struct sock *sk, char __user *user_desc)
+{
+ char *old, *desc;
+
+ desc = strndup_user(user_desc, SK_MAX_DESC_SIZE, GFP_KERNEL_ACCOUNT);
+ if (IS_ERR(desc))
+ return PTR_ERR(desc);
+
+ lock_sock(sk);
+ old = sk->sk_description;
+ sk->sk_description = desc;
+ release_sock(sk);
+
+ kfree(old);
+
+ return 0;
+}
+
/*
* This is meant for all protocols to use and covers goings on
* at the socket level. Everything here is generic.
@@ -850,6 +868,9 @@ int sock_setsockopt(struct socket *sock, int level, int
optname,
if (optname == SO_BINDTODEVICE)
return sock_setbindtodevice(sk, optval, optlen);
+ if (optname == SO_DESCRIPTION)
+ return sock_set_description(sk, optval);
+
if (optlen < sizeof(int))
return -EINVAL;
@@ -1792,6 +1813,8 @@ static void __sk_destruct(struct rcu_head *head)
RCU_INIT_POINTER(sk->sk_filter, NULL);
}
+ kfree(sk->sk_description);
+
sock_disable_timestamp(sk, SK_FLAGS_TIMESTAMP);
#ifdef CONFIG_BPF_SYSCALL
diff --git a/net/socket.c b/net/socket.c
index 976426d03f09..4f2c1a7744b0 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -134,6 +134,11 @@ static void sock_show_fdinfo(struct seq_file *m, struct
file *f)
{
struct socket *sock = f->private_data;
+ lock_sock(sock->sk);
+ if (sock->sk->sk_description)
+ seq_printf(m, "desc:\t%s\n", sock->sk->sk_description);
+ release_sock(sock->sk);
+
if (sock->ops->show_fdinfo)
sock->ops->show_fdinfo(m, sock);
}
--
2.25.1
Re: [PATCH] genirq/affinity: show managed irq affinity correctly
On 2020-08-13 09:08, Thomas Gleixner wrote: Yunfeng Ye writes: [...] You are looking at the wrong file. /proc/irq/$IRQ/smp_affinity* is the possible mask. If you want to know to which CPU an interrupt is affine then look at /proc/irq/$IRQ/effective_affinity* If effective_affinity* is not showing the correct value, then the irq chip affinity setter is broken and needs to be fixed. In order to reassure myself that nothing was untoward in GIC-land, I went in and looked at an ITS-based VM running whatever is in Linus' tree today. I see the effective affinity being correctly setup, and being as expected a subset of the affinity. This is without isolcpu though. In any case, I'd be interested in understanding what this patch is trying to solve, really. M. -- Who you jivin' with that Cosmik Debris?
[PATCH v3] dma-mapping: set default segment_boundary_mask to ULONG_MAX
The default segment_boundary_mask was set to DMA_BIT_MAKS(32)
a decade ago by referencing SCSI/block subsystem, as a 32-bit
mask was good enough for most of the devices.
Now more and more drivers set dma_masks above DMA_BIT_MAKS(32)
while only a handful of them call dma_set_seg_boundary(). This
means that most drivers have a 4GB segmention boundary because
DMA API returns a 32-bit default value, though they might not
really have such a limit.
The default segment_boundary_mask should mean "no limit" since
the device doesn't explicitly set the mask. But a 32-bit mask
certainly limits those devices capable of 32+ bits addressing.
So this patch sets default segment_boundary_mask to ULONG_MAX.
Signed-off-by: Nicolin Chen
---
Changelog:
v2->v3
* Resent -- no change
v2 was sent 4 months ago https://lkml.org/lkml/2020/4/6/881
but it has not got replied yet
v1->v2
* Followed Robin's comments to revise the commit message by
dropping one paragraph of not-entirely-true justification
(no git-diff level change, so please ack if you tested v1)
include/linux/dma-mapping.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 016b96b384bd..27df499aa041 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -628,7 +628,7 @@ static inline unsigned long dma_get_seg_boundary(struct
device *dev)
{
if (dev->dma_parms && dev->dma_parms->segment_boundary_mask)
return dev->dma_parms->segment_boundary_mask;
- return DMA_BIT_MASK(32);
+ return ULONG_MAX;
}
static inline int dma_set_seg_boundary(struct device *dev, unsigned long mask)
--
2.17.1
[PATCH RFC 09/12] sched/coresched: Use for_each_cpu(_wrap)_or for pick_next_task
From: Vineeth Pillai
During a CPU hotplug event, schedule would be called with the hotplugged CPU
not in the cpumask. So use for_each_cpu(_wrap)_or to include the current cpu in
the task pick loop.
Signed-off-by: Vineeth Pillai
Co-developed-by: Joel Fernandes (Google)
Signed-off-by: Joel Fernandes (Google)
---
kernel/sched/core.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index ff13254ed317..3e9df8221c62 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4663,7 +4663,7 @@ pick_next_task(struct rq *rq, struct task_struct *prev,
struct rq_flags *rf)
/* reset state */
rq->core->core_cookie = 0UL;
- for_each_cpu(i, smt_mask) {
+ for_each_cpu_or(i, smt_mask, cpumask_of(cpu)) {
struct rq *rq_i = cpu_rq(i);
trace_printk("CPU %d is in smt_mask, resetting\n", i);
@@ -4685,7 +4685,7 @@ pick_next_task(struct rq *rq, struct task_struct *prev,
struct rq_flags *rf)
*/
for_each_class(class) {
again:
- for_each_cpu_wrap(i, smt_mask, cpu) {
+ for_each_cpu_wrap_or(i, smt_mask, cpumask_of(cpu), cpu) {
struct rq *rq_i = cpu_rq(i);
struct task_struct *p;
@@ -4774,6 +4774,9 @@ next_class:;
rq->core->core_pick_seq = rq->core->core_task_seq;
next = rq->core_pick;
rq->core_sched_seq = rq->core->core_pick_seq;
+
+ /* Something should have been selected for current CPU */
+ WARN_ON_ONCE(!next);
trace_printk("picked: %s/%d %lx\n", next->comm, next->pid,
next->core_cookie);
/*
@@ -4784,7 +4787,7 @@ next_class:;
* their task. This ensures there is no inter-sibling overlap between
* non-matching user state.
*/
- for_each_cpu(i, smt_mask) {
+ for_each_cpu_or(i, smt_mask, cpumask_of(cpu)) {
struct rq *rq_i = cpu_rq(i);
WARN_ON_ONCE(!rq_i->core_pick);
--
2.28.0.220.ged08abb693-goog
Re: POC: Alternative solution: Re: [PATCH 0/4] printk: reimplement LOG_CONT handling
On Fri, Aug 14, 2020 at 4:52 PM Joe Perches wrote: > > On Fri, 2020-08-14 at 15:46 -0700, Linus Torvalds wrote: > > > > This is why I think any discussion that says "people should buffer > > their lines themselves and we should get rid if pr_cont()" is > > fundamentally broken. > > > > Don't go down that hole. I won't take it. It's wrong. > > I don't think it's wrong per se. It's *absolutely* and 100% wrong. Yes, any random *user* of pr_cont() can decide to buffer on it's own. But when the discussion is about printk() - the implementation, not the users - then it's complete and utter BS to talk about trying to get rid of pr_cont(). See the difference? Linus
[PATCH 3/3] regulator: rt4801: Fix the dt-binding document for dtc check.
From: ChiYuan Huang
Fix the dt-binding document for dtc check.
Signed-off-by: ChiYuan Huang
---
.../devicetree/bindings/regulator/richtek,rt4801-regulator.yaml| 3 ---
1 file changed, 3 deletions(-)
diff --git
a/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml
b/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml
index 28d30e2..fa075c6 100644
--- a/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/richtek,rt4801-regulator.yaml
@@ -49,9 +49,6 @@ required:
- compatible
- reg
-additionalProperties:
- - enable-gpios
-
examples:
- |
i2c {
--
2.7.4
