Re: [PATCH] i2c: iproc: Change driver to use 'BIT' macro
On 2019-04-13 00:59, Peter Rosin wrote: > On 2019-04-03 23:05, Ray Jui wrote: >> Change the iProc I2C driver to use the 'BIT' macro from all '1 << XXX' >> bit operations to get rid of compiler warning and improve readability of >> the code > > All? I see lots more '1 << XXX_SHIFT' matches. I might be behind though? I verified that, and yes indeed, I was behind. That said, see below... > Anyway, if you are cleaning up, I'm just flagging that BIT(XXX_SHIFT) looks > a bit clunky to me. You might consider renaming all those single-bit > XXX_SHIFT macros to simple be > > #define XXX BIT() > > instead of > > #define XXX_SHIFT > > but that triggers more churn, so is obviously more error prone. You might > not dare it? > > Cheers, > Peter > >> Signed-off-by: Ray Jui >> --- >> drivers/i2c/busses/i2c-bcm-iproc.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c >> b/drivers/i2c/busses/i2c-bcm-iproc.c >> index 562942d0c05c..a845b8decac8 100644 >> --- a/drivers/i2c/busses/i2c-bcm-iproc.c >> +++ b/drivers/i2c/busses/i2c-bcm-iproc.c >> @@ -717,7 +717,7 @@ static int bcm_iproc_i2c_xfer_single_msg(struct >> bcm_iproc_i2c_dev *iproc_i2c, >> >> /* mark the last byte */ >> if (i == msg->len - 1) >> -val |= 1 << M_TX_WR_STATUS_SHIFT; >> +val |= BIT(M_TX_WR_STATUS_SHIFT); >> >> iproc_i2c_wr_reg(iproc_i2c, M_TX_OFFSET, val); >> } >> @@ -844,7 +844,7 @@ static int bcm_iproc_i2c_cfg_speed(struct >> bcm_iproc_i2c_dev *iproc_i2c) >> >> iproc_i2c->bus_speed = bus_speed; >> val = iproc_i2c_rd_reg(iproc_i2c, TIM_CFG_OFFSET); >> -val &= ~(1 << TIM_CFG_MODE_400_SHIFT); >> +val &= ~BIT(TIM_CFG_MODE_400_SHIFT); >> val |= (bus_speed == 40) << TIM_CFG_MODE_400_SHIFT; These two statements now no longer "match". One uses BIT and the other open codes the shift. I think that's bad. Losing the _SHIFT suffix and including BIT in the macro expansion, as suggested above, yields: val &= ~TIM_CFG_MODE_400; if (bus_speed == 40) val |= TIM_CFG_MODE_400; which is perhaps one more line, but also more readable IMO. But all this is of course in deep nit-pick-territory... Cheers, Peter >> iproc_i2c_wr_reg(iproc_i2c, TIM_CFG_OFFSET, val); >> >> @@ -995,7 +995,7 @@ static int bcm_iproc_i2c_resume(struct device *dev) >> >> /* configure to the desired bus speed */ >> val = iproc_i2c_rd_reg(iproc_i2c, TIM_CFG_OFFSET); >> -val &= ~(1 << TIM_CFG_MODE_400_SHIFT); >> +val &= ~BIT(TIM_CFG_MODE_400_SHIFT); >> val |= (iproc_i2c->bus_speed == 40) << TIM_CFG_MODE_400_SHIFT; >> iproc_i2c_wr_reg(iproc_i2c, TIM_CFG_OFFSET, val); >> >> >
Re: [PATCH v4 1/2] drm/bridge: sil_sii8620: make remote control optional.
Hi Andrzej,
On Wed, Apr 10, 2019 at 11:42:50AM +0200, Andrzej Hajda wrote:
> On 07.04.2019 07:03, Ronald Tschalär wrote:
> > commit d6abe6df706c (drm/bridge: sil_sii8620: do not have a dependency
> > of RC_CORE) changed the driver to select both RC_CORE and INPUT.
> > However, this causes problems with other drivers, in particular an input
> > driver that depends on MFD_INTEL_LPSS_PCI (to be added in a separate
> > commit):
> >
> > drivers/clk/Kconfig:9:error: recursive dependency detected!
> > drivers/clk/Kconfig:9:symbol COMMON_CLK is selected by
> > MFD_INTEL_LPSS
> > drivers/mfd/Kconfig:566: symbol MFD_INTEL_LPSS is selected by
> > MFD_INTEL_LPSS_PCI
> > drivers/mfd/Kconfig:580: symbol MFD_INTEL_LPSS_PCI is implied by
> > KEYBOARD_APPLESPI
> > drivers/input/keyboard/Kconfig:73:symbol KEYBOARD_APPLESPI depends on
> > INPUT
> > drivers/input/Kconfig:8: symbol INPUT is selected by DRM_SIL_SII8620
> > drivers/gpu/drm/bridge/Kconfig:83:symbol DRM_SIL_SII8620 depends on
> > DRM_BRIDGE
> > drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by
> > DRM_PL111
> > drivers/gpu/drm/pl111/Kconfig:1: symbol DRM_PL111 depends on
> > COMMON_CLK
> >
> > According to the docs and general consensus, select should only be used
> > for non user-visible symbols, but both RC_CORE and INPUT are
> > user-visible. Furthermore almost all other references to INPUT
> > throughout the kernel config are depends, not selects. For this reason
> > the first part of this change reverts commit d6abe6df706c.
> >
> > In order to address the original reason for commit d6abe6df706c, namely
> > that not all boards use the remote controller functionality and hence
> > should not need have to deal with RC_CORE, the second part of this
> > change now makes the remote control support in the driver optional and
> > contingent on RC_CORE being defined. And with this the hard dependency
> > on INPUT also goes away as that is only needed if RC_CORE is defined
> > (which in turn already depends on INPUT).
[snip]
> What about:
>
> -
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 8840f396a7b6..298189067929 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -86,8 +86,7 @@ config DRM_SIL_SII8620
> depends on OF
> select DRM_KMS_HELPER
> imply EXTCON
> - select INPUT
> - select RC_CORE
> + imply RC_CORE
> help
> Silicon Image SII8620 HDMI/MHL bridge chip driver.
>
> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
> b/drivers/gpu/drm/bridge/sil-sii8620.c
> index 0cc293a6ac24..df0f9dbbe839 100644
> --- a/drivers/gpu/drm/bridge/sil-sii8620.c
> +++ b/drivers/gpu/drm/bridge/sil-sii8620.c
> @@ -1762,10 +1762,8 @@ static bool sii8620_rcp_consume(struct sii8620
> *ctx, u8 scancode)
>
> scancode &= MHL_RCP_KEY_ID_MASK;
>
> - if (!ctx->rc_dev) {
> - dev_dbg(ctx->dev, "RCP input device not initialized\n");
> + if (!IS_ENABLED(RC_CORE) || !ctx->rc_dev)
> return false;
> - }
>
> if (pressed)
> rc_keydown(ctx->rc_dev, RC_PROTO_CEC, scancode, 0);
> @@ -2102,6 +2100,9 @@ static void sii8620_init_rcp_input_dev(struct
> sii8620 *ctx)
> struct rc_dev *rc_dev;
> int ret;
>
> + if (!IS_ENABLED(RC_CORE))
> + return;
> +
> rc_dev = rc_allocate_device(RC_DRIVER_SCANCODE);
> if (!rc_dev) {
> dev_err(ctx->dev, "Failed to allocate RC device\n");
> @@ -2216,6 +2217,9 @@ static void sii8620_detach(struct drm_bridge *bridge)
> {
> struct sii8620 *ctx = bridge_to_sii8620(bridge);
>
> + if (!IS_ENABLED(RC_CORE))
> + return;
> +
> rc_unregister_device(ctx->rc_dev);
> }
> ---
>
> Less changes, no conditional compilation - better compiler coverage,
> more readable.
This works for me (with RC_CORE replaced with CONFIG_RC_CORE). Sending
a new patch that includes this shortly.
Cheers,
Ronald
[PATCH v2 1/2] switchtec: Fix false maximum supported PCIe function number issue
The hardware supports up to 255 PFFs and the driver only supports 48, so
this patch updates the driver to support them all. To be backward
compatible, a new ioctl and corresponding data structure are created,
while keep the deprecated one.
Signed-off-by: Wesley Sheng
---
drivers/pci/switch/switchtec.c | 39 +---
include/linux/switchtec.h| 2 +-
include/uapi/linux/switchtec_ioctl.h | 13 +++-
3 files changed, 40 insertions(+), 14 deletions(-)
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index e22766c..7df9a69 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -658,19 +658,25 @@ static int ioctl_flash_part_info(struct switchtec_dev
*stdev,
static int ioctl_event_summary(struct switchtec_dev *stdev,
struct switchtec_user *stuser,
- struct switchtec_ioctl_event_summary __user *usum)
+ struct switchtec_ioctl_event_summary __user *usum,
+ size_t size)
{
- struct switchtec_ioctl_event_summary s = {0};
+ struct switchtec_ioctl_event_summary *s;
int i;
u32 reg;
+ int ret = 0;
- s.global = ioread32(&stdev->mmio_sw_event->global_summary);
- s.part_bitmap = ioread32(&stdev->mmio_sw_event->part_event_bitmap);
- s.local_part = ioread32(&stdev->mmio_part_cfg->part_event_summary);
+ s = kzalloc(sizeof(*s), GFP_KERNEL);
+ if (!s)
+ return -ENOMEM;
+
+ s->global = ioread32(&stdev->mmio_sw_event->global_summary);
+ s->part_bitmap = ioread32(&stdev->mmio_sw_event->part_event_bitmap);
+ s->local_part = ioread32(&stdev->mmio_part_cfg->part_event_summary);
for (i = 0; i < stdev->partition_count; i++) {
reg = ioread32(&stdev->mmio_part_cfg_all[i].part_event_summary);
- s.part[i] = reg;
+ s->part[i] = reg;
}
for (i = 0; i < SWITCHTEC_MAX_PFF_CSR; i++) {
@@ -679,15 +685,19 @@ static int ioctl_event_summary(struct switchtec_dev
*stdev,
break;
reg = ioread32(&stdev->mmio_pff_csr[i].pff_event_summary);
- s.pff[i] = reg;
+ s->pff[i] = reg;
}
- if (copy_to_user(usum, &s, sizeof(s)))
- return -EFAULT;
+ if (copy_to_user(usum, s, size)) {
+ ret = -EFAULT;
+ goto error_case;
+ }
stuser->event_cnt = atomic_read(&stdev->event_cnt);
- return 0;
+error_case:
+ kfree(s);
+ return ret;
}
static u32 __iomem *global_ev_reg(struct switchtec_dev *stdev,
@@ -977,8 +987,9 @@ static long switchtec_dev_ioctl(struct file *filp, unsigned
int cmd,
case SWITCHTEC_IOCTL_FLASH_PART_INFO:
rc = ioctl_flash_part_info(stdev, argp);
break;
- case SWITCHTEC_IOCTL_EVENT_SUMMARY:
- rc = ioctl_event_summary(stdev, stuser, argp);
+ case SWITCHTEC_IOCTL_EVENT_SUMMARY_LEGACY:
+ rc = ioctl_event_summary(stdev, stuser, argp,
+sizeof(struct
switchtec_ioctl_event_summary_legacy));
break;
case SWITCHTEC_IOCTL_EVENT_CTL:
rc = ioctl_event_ctl(stdev, argp);
@@ -989,6 +1000,10 @@ static long switchtec_dev_ioctl(struct file *filp,
unsigned int cmd,
case SWITCHTEC_IOCTL_PORT_TO_PFF:
rc = ioctl_port_to_pff(stdev, argp);
break;
+ case SWITCHTEC_IOCTL_EVENT_SUMMARY:
+ rc = ioctl_event_summary(stdev, stuser, argp,
+sizeof(struct
switchtec_ioctl_event_summary));
+ break;
default:
rc = -ENOTTY;
break;
diff --git a/include/linux/switchtec.h b/include/linux/switchtec.h
index 52a079b..0cfc34a 100644
--- a/include/linux/switchtec.h
+++ b/include/linux/switchtec.h
@@ -20,7 +20,7 @@
#include
#define SWITCHTEC_MRPC_PAYLOAD_SIZE 1024
-#define SWITCHTEC_MAX_PFF_CSR 48
+#define SWITCHTEC_MAX_PFF_CSR 255
#define SWITCHTEC_EVENT_OCCURRED BIT(0)
#define SWITCHTEC_EVENT_CLEARBIT(0)
diff --git a/include/uapi/linux/switchtec_ioctl.h
b/include/uapi/linux/switchtec_ioctl.h
index 4f4daf8..c912b5a 100644
--- a/include/uapi/linux/switchtec_ioctl.h
+++ b/include/uapi/linux/switchtec_ioctl.h
@@ -50,7 +50,7 @@ struct switchtec_ioctl_flash_part_info {
__u32 active;
};
-struct switchtec_ioctl_event_summary {
+struct switchtec_ioctl_event_summary_legacy {
__u64 global;
__u64 part_bitmap;
__u32 local_part;
@@ -59,6 +59,15 @@ struct switchtec_ioctl_event_summary {
__u32 pff[48];
};
+struct switchtec_ioctl_event_summary {
+ __u64 global;
+ __u64 part_bitmap;
+ __u32 local_part;
+ __u32 padding;
+ __u32 part[48];
+ __u32 pff[255];
+};
+
#define SWITCHTEC_IOCTL_EVENT_STACK_ERROR 0
#define SWITCHTEC_IOCTL
[PATCH v2 0/2] Fix two bugs of switchtec module
Hi, Everyone, This patch series fix two bugs of switchtec module. The first is introduced by device spec definition issue: the maximum supported PCIe function number by hardware should be 255 instead of the false number of 48. Rectify it in driver and for backward compatible, a new ioctl and corresponding data structure are created, while keep the deprecated one. The second is MRPC event unintentionally masked at corner case. Fix this bug by skipping the mask operation for MRPC event in event ISR like what we already do for LINK event. Regard, Wesley -- Changed since v1: - rewrapped the commit message of [PATCH 1/2] into one paragraph -- Wesley Sheng (2): switchtec: Fix false maximum supported PCIe function number issue switchtec: Fix unintended mask of MRPC event drivers/pci/switch/switchtec.c | 42 +--- include/linux/switchtec.h| 2 +- include/uapi/linux/switchtec_ioctl.h | 13 ++- 3 files changed, 42 insertions(+), 15 deletions(-) -- 2.7.4
[PATCH v2 2/2] switchtec: Fix unintended mask of MRPC event
When running application tool switchtec-user's `firmware update` and
`event wait` commands concurrently, sometimes the firmware update
speed reduced evidently.
It is because when the MRPC event happened right after MRPC event
occurrence check but before event mask loop reach to its header
register in event ISR, the MRPC event would be masked unintentionally.
Since there's no chance to enable it again except for a module reload,
all the following MRPC execution completion check will be deferred to
timeout.
Fix this bug by skipping the mask operation for MRPC event in event
ISR, same as what we already do for LINK event.
Fixes: 52eabba5bcdb ("switchtec: Add IOCTLs to the Switchtec driver")
Signed-off-by: Wesley Sheng
---
drivers/pci/switch/switchtec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
index 7df9a69..30f6e08 100644
--- a/drivers/pci/switch/switchtec.c
+++ b/drivers/pci/switch/switchtec.c
@@ -1177,7 +1177,8 @@ static int mask_event(struct switchtec_dev *stdev, int
eid, int idx)
if (!(hdr & SWITCHTEC_EVENT_OCCURRED && hdr & SWITCHTEC_EVENT_EN_IRQ))
return 0;
- if (eid == SWITCHTEC_IOCTL_EVENT_LINK_STATE)
+ if (eid == SWITCHTEC_IOCTL_EVENT_LINK_STATE ||
+ eid == SWITCHTEC_IOCTL_EVENT_MRPC_COMP)
return 0;
dev_dbg(&stdev->dev, "%s: %d %d %x\n", __func__, eid, idx, hdr);
--
2.7.4
Re: [PATCH] staging: android: vsoc: fix copy_from_user overrun
On Mon, Apr 15, 2019 at 09:32:44AM +0300, Dan Carpenter wrote:
> On Sun, Apr 14, 2019 at 05:37:26PM +0200, Vincent Stehlé wrote:
> > The `np->permission' structure is smaller than the `np' structure but
> > sizeof(*np) worth of data is copied in there. Fix the size passed to
> > copy_from_user() to avoid overrun.
> >
> > Fixes: 3d2ec9dcd5539d42 ("staging: Android: Add 'vsoc' driver for
> > cuttlefish.")
> > Signed-off-by: Vincent Stehlé
> > Cc: Greg Kroah-Hartman
> > ---
> > drivers/staging/android/vsoc.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/android/vsoc.c b/drivers/staging/android/vsoc.c
> > index 8a75bd27c4133..00a1ec7b91549 100644
> > --- a/drivers/staging/android/vsoc.c
> > +++ b/drivers/staging/android/vsoc.c
> > @@ -259,7 +259,8 @@ do_create_fd_scoped_permission(struct
> > vsoc_device_region *region_p,
> > atomic_t *owner_ptr = NULL;
> > struct vsoc_device_region *managed_region_p;
> >
> > - if (copy_from_user(&np->permission, &arg->perm, sizeof(*np)) ||
> > + if (copy_from_user(&np->permission,
> > + &arg->perm, sizeof(np->permission)) ||
>
> The original code was probably correct... This is a common thing where
> people use "&p->first_struct_member" to represent the whole struct.
> It seems like kind of a horrible thing to do and I can't explain why
> people do it, but they do...
I have reviewed the code in a less totally lazy way and your patch is
correct.
Reviewed-by: Dan Carpenter
The bug is harmless, though. We copy over the list pointers with user
data and then immediately write the correct data to it.
It should probably be a static checker warning when we copy to non
__user tagged pointers. I think someone was adding this to Sparse but I
should probably add it to Smatch as well.
regards,
dan carpenter
Re: [PATCH] staging: android: vsoc: fix copy_from_user overrun
On Sun, Apr 14, 2019 at 05:37:26PM +0200, Vincent Stehlé wrote:
> The `np->permission' structure is smaller than the `np' structure but
> sizeof(*np) worth of data is copied in there. Fix the size passed to
> copy_from_user() to avoid overrun.
>
> Fixes: 3d2ec9dcd5539d42 ("staging: Android: Add 'vsoc' driver for
> cuttlefish.")
> Signed-off-by: Vincent Stehlé
> Cc: Greg Kroah-Hartman
> ---
> drivers/staging/android/vsoc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/android/vsoc.c b/drivers/staging/android/vsoc.c
> index 8a75bd27c4133..00a1ec7b91549 100644
> --- a/drivers/staging/android/vsoc.c
> +++ b/drivers/staging/android/vsoc.c
> @@ -259,7 +259,8 @@ do_create_fd_scoped_permission(struct vsoc_device_region
> *region_p,
> atomic_t *owner_ptr = NULL;
> struct vsoc_device_region *managed_region_p;
>
> - if (copy_from_user(&np->permission, &arg->perm, sizeof(*np)) ||
> + if (copy_from_user(&np->permission,
> +&arg->perm, sizeof(np->permission)) ||
The original code was probably correct... This is a common thing where
people use "&p->first_struct_member" to represent the whole struct.
It seems like kind of a horrible thing to do and I can't explain why
people do it, but they do...
regards,
dan carpenter
Re: [PATCH 2/2] s390: boot, purgatory: pass $(CLANG_FLAGS) where needed
On Thu, 11 Apr 2019 11:08:31 -0700 Nick Desaulniers wrote: > On Thu, Apr 11, 2019 at 1:52 AM Arnd Bergmann wrote: > > > > On Thu, Apr 11, 2019 at 12:14 AM 'Nick Desaulniers' via Clang Built > > Linux wrote: > > > On Wed, Apr 10, 2019 at 1:13 PM Arnd Bergmann wrote: > > > > > > > > The purgatory and boot Makefiles do not inherit the original cflags, > > > > so clang falls back to the default target architecture when building it, > > > > typically this would be x86 when cross-compiling. > > > > > > > > Add $(CLANG_FLAGS) everywhere so we pass the correct > > > > --target=s390x-linux > > > > option when cross-compiling. > > > > > > > > Signed-off-by: Arnd Bergmann > > > > --- > > > > arch/s390/Makefile | 5 +++-- > > > > arch/s390/purgatory/Makefile | 1 + > > > > 2 files changed, 4 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/arch/s390/Makefile b/arch/s390/Makefile > > > > index 9c079a506325..443990791099 100644 > > > > --- a/arch/s390/Makefile > > > > +++ b/arch/s390/Makefile > > > > @@ -17,12 +17,13 @@ KBUILD_CFLAGS_MODULE += -fPIC > > > > KBUILD_AFLAGS += -m64 > > > > KBUILD_CFLAGS += -m64 > > > > aflags_dwarf := -Wa,-gdwarf-2 > > > > -KBUILD_AFLAGS_DECOMPRESSOR := -m64 -D__ASSEMBLY__ > > > > +KBUILD_AFLAGS_DECOMPRESSOR := $(CLANG_FLAGS) -m64 -D__ASSEMBLY__ > > > > KBUILD_AFLAGS_DECOMPRESSOR += $(if > > > > $(CONFIG_DEBUG_INFO),$(aflags_dwarf)) > > > > -KBUILD_CFLAGS_DECOMPRESSOR := -m64 -O2 > > > > +KBUILD_CFLAGS_DECOMPRESSOR := $(CLANG_FLAGS) -m64 -O2 > > > > KBUILD_CFLAGS_DECOMPRESSOR += -DDISABLE_BRANCH_PROFILING -D__NO_FORTIFY > > > > KBUILD_CFLAGS_DECOMPRESSOR += -fno-delete-null-pointer-checks > > > > -msoft-float > > > > KBUILD_CFLAGS_DECOMPRESSOR += -fno-asynchronous-unwind-tables > > > > > > Thanks for the respin with Nathan's suggestion. > > > > > > > +KBUILD_CFLAGS_DECOMPRESSOR += $(call cc-disable-warning,pointer-sign) > > > > > > What's up with this ^ ? Seems like the top level sets it (without > > > cc-disable-warning :( ), but then KBUILD_CFLAGS_DECOMPRESSOR discards > > > it. Does Clang actually flag code in this arch (that GCC doesn't)? > > > > Oops, that should have been a separate patch. > > > > I think what happens is that clang warns more aggressively about pointer > > sign > > bugs than gcc in some cases, and some of those cases happen in s390 > > header files that are included by both the kernel and the decompressor. > > > > The full warning log without this change is rather long, see > > https://pastebin.com/KG9xaTNB > > From this link, it looks like the definitions of: > __atomic64_or > __atomic64_and > __atomic64_xor > and their *_barrier variants are problematic. I think converting > those to use unsigned long is the way to go. Shouldn't you be doing > bitwise ops on unsigned types anyways? These functions follow the type of atomic64_t which is a "long" wrapped in a structure. We do not want to change that to unsigned long, are we? Then having some of the functions operate on "long" and others on "unsigned long" seem odd. > The warnings with __atomic64_add are tougher to read/understand since > at that point the log lines look like they start to mix together. > > > > > I also tried patching the code to avoid the warnings, but I'm not entirely > > happy with that result either, see > > https://pastebin.com/pSMz5eZA > > That's no terrible, IMO, particularly with the change I suggest above. That is not too bad, the only change I do not like is the s/u8/char/ in struct ipl_block_fcp. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin.
Re: [PATCH v4 3/3] csky: Add support for libdw
On Thu, Apr 11, 2019 at 03:45:01PM +0800, Mao Han wrote:
> This patch add support for DWARF register mappings and libdw registers
> initialization, which is used by perf callchain analyzing when
> --call-graph=dwarf is given.
>
> CC: Peter Zijlstra
> CC: Ingo Molnar
> CC: Arnaldo Carvalho de Melo
> CC: Alexander Shishkin
> CC: Jiri Olsa
> CC: Namhyung Kim
>
> Signed-off-by: Mao Han
> ---
> tools/arch/csky/include/uapi/asm/perf_regs.h | 51 ++
> tools/perf/Makefile.config | 6 +-
> tools/perf/arch/csky/Build | 1 +
> tools/perf/arch/csky/Makefile| 3 +
> tools/perf/arch/csky/include/perf_regs.h | 100
> +++
> tools/perf/arch/csky/util/Build | 2 +
> tools/perf/arch/csky/util/dwarf-regs.c | 49 +
> tools/perf/arch/csky/util/unwind-libdw.c | 78 +
> 8 files changed, 289 insertions(+), 1 deletion(-)
> create mode 100644 tools/arch/csky/include/uapi/asm/perf_regs.h
> create mode 100644 tools/perf/arch/csky/Build
> create mode 100644 tools/perf/arch/csky/Makefile
> create mode 100644 tools/perf/arch/csky/include/perf_regs.h
> create mode 100644 tools/perf/arch/csky/util/Build
> create mode 100644 tools/perf/arch/csky/util/dwarf-regs.c
> create mode 100644 tools/perf/arch/csky/util/unwind-libdw.c
>
> diff --git a/tools/arch/csky/include/uapi/asm/perf_regs.h
> b/tools/arch/csky/include/uapi/asm/perf_regs.h
> new file mode 100644
> index 000..ee323d8
> --- /dev/null
> +++ b/tools/arch/csky/include/uapi/asm/perf_regs.h
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +// Copyright (C) 2019 Hangzhou C-SKY Microsystems co.,ltd.
> +
> +#ifndef _ASM_CSKY_PERF_REGS_H
> +#define _ASM_CSKY_PERF_REGS_H
> +
> +/* Index of struct pt_regs */
> +enum perf_event_csky_regs {
> + PERF_REG_CSKY_TLS,
> + PERF_REG_CSKY_LR,
> + PERF_REG_CSKY_PC,
> + PERF_REG_CSKY_SR,
> + PERF_REG_CSKY_SP,
> + PERF_REG_CSKY_ORIG_A0,
> + PERF_REG_CSKY_A0,
> + PERF_REG_CSKY_A1,
> + PERF_REG_CSKY_A2,
> + PERF_REG_CSKY_A3,
> + PERF_REG_CSKY_REGS0,
> + PERF_REG_CSKY_REGS1,
> + PERF_REG_CSKY_REGS2,
> + PERF_REG_CSKY_REGS3,
> + PERF_REG_CSKY_REGS4,
> + PERF_REG_CSKY_REGS5,
> + PERF_REG_CSKY_REGS6,
> + PERF_REG_CSKY_REGS7,
> + PERF_REG_CSKY_REGS8,
> + PERF_REG_CSKY_REGS9,
> +#if defined(__CSKYABIV2__)
> + PERF_REG_CSKY_EXREGS0,
> + PERF_REG_CSKY_EXREGS1,
> + PERF_REG_CSKY_EXREGS2,
> + PERF_REG_CSKY_EXREGS3,
> + PERF_REG_CSKY_EXREGS4,
> + PERF_REG_CSKY_EXREGS5,
> + PERF_REG_CSKY_EXREGS6,
> + PERF_REG_CSKY_EXREGS7,
> + PERF_REG_CSKY_EXREGS8,
> + PERF_REG_CSKY_EXREGS9,
> + PERF_REG_CSKY_EXREGS10,
> + PERF_REG_CSKY_EXREGS11,
> + PERF_REG_CSKY_EXREGS12,
> + PERF_REG_CSKY_EXREGS13,
> + PERF_REG_CSKY_EXREGS14,
> + PERF_REG_CSKY_HI,
> + PERF_REG_CSKY_LO,
> + PERF_REG_CSKY_DCSR,
> +#endif
> + PERF_REG_CSKY_MAX,
> +};
> +#endif /* _ASM_CSKY_PERF_REGS_H */
> diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
> index fe3f97e..42985ae 100644
> --- a/tools/perf/Makefile.config
> +++ b/tools/perf/Makefile.config
> @@ -59,6 +59,10 @@ ifeq ($(SRCARCH),arm64)
>LIBUNWIND_LIBS = -lunwind -lunwind-aarch64
> endif
>
> +ifeq ($(SRCARCH),csky)
> + NO_PERF_REGS := 0
> +endif
> +
> ifeq ($(ARCH),s390)
>NO_PERF_REGS := 0
>NO_SYSCALL_TABLE := 0
> @@ -77,7 +81,7 @@ endif
> # Disable it on all other architectures in case libdw unwind
> # support is detected in system. Add supported architectures
> # to the check.
> -ifneq ($(SRCARCH),$(filter $(SRCARCH),x86 arm arm64 powerpc s390))
> +ifneq ($(SRCARCH),$(filter $(SRCARCH),x86 arm arm64 powerpc s390 csky))
>NO_LIBDW_DWARF_UNWIND := 1
> endif
>
> diff --git a/tools/perf/arch/csky/Build b/tools/perf/arch/csky/Build
> new file mode 100644
> index 000..e4e5f33
> --- /dev/null
> +++ b/tools/perf/arch/csky/Build
> @@ -0,0 +1 @@
> +perf-y += util/
> diff --git a/tools/perf/arch/csky/Makefile b/tools/perf/arch/csky/Makefile
> new file mode 100644
> index 000..7fbca17
> --- /dev/null
> +++ b/tools/perf/arch/csky/Makefile
> @@ -0,0 +1,3 @@
> +ifndef NO_DWARF
> +PERF_HAVE_DWARF_REGS := 1
> +endif
> diff --git a/tools/perf/arch/csky/include/perf_regs.h
> b/tools/perf/arch/csky/include/perf_regs.h
> new file mode 100644
> index 000..8f336ea
> --- /dev/null
> +++ b/tools/perf/arch/csky/include/perf_regs.h
> @@ -0,0 +1,100 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +// Copyright (C) 2019 Hangzhou C-SKY Microsystems co.,ltd.
> +
> +#ifndef ARCH_PERF_REGS_H
> +#define ARCH_PERF_REGS_H
> +
> +#include
> +#include
> +#include
> +
> +#define PERF_REGS_MASK ((1ULL << PERF_REG_CSKY_MAX) - 1)
> +#define PERF_REGS_MAXPERF_REG_CSKY_MAX
> +#define PERF_SAMPLE_REGS_ABI PERF_SAMPLE_REGS_ABI_32
> +
> +#define PERF_REG_IP PERF_REG_CSKY_PC
> +#def
[PATCH v2] pinctrl: rockchip: fix leaked of_node references
The call to of_parse_phandle returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: ./drivers/pinctrl/pinctrl-rockchip.c:3221:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 3196, but without a corresponding object release within this function. ./drivers/pinctrl/pinctrl-rockchip.c:3223:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 3196, but without a corresponding object release within this function. Signed-off-by: Wen Yang Cc: Linus Walleij Cc: Heiko Stuebner Cc: linux-g...@vger.kernel.org Cc: linux-rockc...@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- v2: - put of_node_put below the whole if clause. - In the if clause, since node is NULL, there is no need to call of_node_put before return. drivers/pinctrl/pinctrl-rockchip.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pinctrl/pinctrl-rockchip.c b/drivers/pinctrl/pinctrl-rockchip.c index 16bf21b..6436336 100644 --- a/drivers/pinctrl/pinctrl-rockchip.c +++ b/drivers/pinctrl/pinctrl-rockchip.c @@ -3212,6 +3212,7 @@ static int rockchip_get_bank_data(struct rockchip_pin_bank *bank, base, &rockchip_regmap_config); } + of_node_put(node); } bank->irq = irq_of_parse_and_map(bank->of_node, 0); -- 2.9.5
[PATCH] x86/entry/64: randomize kernel stack offset upon syscall
If CONFIG_RANDOMIZE_KSTACK_OFFSET is selected, the kernel stack offset is randomized upon each entry to a system call after fixed location of pt_regs struct. This feature is based on the original idea from the PaX's RANDKSTACK feature: https://pax.grsecurity.net/docs/randkstack.txt All the credits for the original idea goes to the PaX team. However, the design and implementation of RANDOMIZE_KSTACK_OFFSET differs greatly from the RANDKSTACK feature (see below). Reasoning for the feature: This feature aims to make considerably harder various stack-based attacks that rely on deterministic stack structure. We have had many of such attacks in past [1],[2],[3] (just to name few), and as Linux kernel stack protections have been constantly improving (vmap-based stack allocation with guard pages, removal of thread_info, STACKLEAK), attackers have to find new ways for their exploits to work. It is important to note that we currently cannot show a concrete attack that would be stopped by this new feature (given that other existing stack protections are enabled), so this is an attempt to be on a proactive side vs. catching up with existing successful exploits. The main idea is that since the stack offset is randomized upon each system call, it is very hard for attacker to reliably land in any particular place on the thread stack when attack is performed. Also, since randomization is performed *after* pt_regs, the ptrace-based approach to discover randomization offset during a long-running syscall should not be possible. [1] jon.oberheide.org/files/infiltrate12-thestackisback.pdf [2] jon.oberheide.org/files/stackjacking-infiltrate11.pdf [3] googleprojectzero.blogspot.com/2016/06/exploiting- recursion-in-linux-kernel_20.html Design description: During most of the kernel's execution, it runs on the "thread stack", which is allocated at fork.c/dup_task_struct() and stored in a per-task variable (tsk->stack). Since stack is growing downward, the stack top can be always calculated using task_top_of_stack(tsk) function, which essentially returns an address of tsk->stack + stack size. When VMAP_STACK is enabled, the thread stack is allocated from vmalloc space. Thread stack is pretty deterministic on its structure - fixed in size, and upon every entry from a userspace to kernel on a syscall the thread stack is started to be constructed from an address fetched from a per-cpu cpu_current_top_of_stack variable. The first element to be pushed to the thread stack is the pt_regs struct that stores all required CPU registers and sys call parameters. The goal of RANDOMIZE_KSTACK_OFFSET feature is to add a random offset after the pt_regs has been pushed to the stack and the rest of thread stack (used during the syscall processing) every time a process issues a syscall. The source of randomness can be taken either from prandom_u32() pseudo random generator (not cryptographically secure). The offset is added using alloca() call since it helps avoiding changes in assembly syscall entry code and unwinder. This is an example of produced assembly code for gcc x86_64: ... add_random_stack_offset(); 0x810022e9 callq 0x81459570 0x810022ee movzbl %al,%eax 0x810022f1 add$0x16,%rax 0x810022f5 and$0x1f8,%eax 0x810022fa sub%rax,%rsp 0x810022fd lea0xf(%rsp),%rax 0x81002302 and$0xfff0,%rax ... As a result of the above gcc-produce code this patch introduces a bit more than 5 bits of randomness after pt_regs location on the thread stack (33 different offsets are generated randomly for x86_64 and 47 for i386). The amount of randomness can be adjusted based on how much of the stack space we wish/can trade for security. Performance (x86_64 measuments only): 1) lmbench: ./lat_syscall -N 100 null base:Simple syscall: 0.1774 microseconds random_offset (prandom_u32() every syscall): Simple syscall: 0.1822 microseconds 2) Andy's tests, misc-tests: ./timing_test_64 10M sys_enosys base:1000 loops in 1.62224s = 162.22 nsec / loop random_offset (prandom_u32() every syscall): 1000 loops in 1.64660s = 166.26 nsec / loop Comparison to grsecurity RANDKSTACK feature: RANDKSTACK feature randomizes the location of the stack start (cpu_current_top_of_stack), i.e. location of pt_regs structure itself on the stack. Initially this patch followed the same approach, but during the recent discussions [4], it has been determined to be of a little value since, if ptrace functionality is available for an attacker, he can use PTRACE_PEEKUSR/PTRACE_POKEUSR api to read/write different offsets in the pt_regs struct, observe the cache behavior of the pt_regs accesses, and figure out the random stack offset. Another big difference is that randomization is done upon syscall entry and not the exit, as with RANDKSTACK. Also, as a result of the above two differ
linux-next: manual merge of the vhost tree with the pci tree
Hi all,
Today's linux-next merge of the vhost tree got a conflict in:
drivers/pci/of.c
between commit:
9cb30a71acd4 ("PCI: OF: Support "external-facing" property")
from the pci tree and commit:
e1c326663501 ("PCI: OF: Initialize dev->fwnode appropriately")
from the vhost tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/pci/of.c
index 73d5adec0a28,9454c90980c9..
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@@ -32,16 -34,13 +35,18 @@@ void pci_release_of_node(struct pci_de
void pci_set_bus_of_node(struct pci_bus *bus)
{
- if (bus->self == NULL)
- bus->dev.of_node = pcibios_get_phb_of_node(bus);
- else
- bus->dev.of_node = of_node_get(bus->self->dev.of_node);
+ struct device_node *node;
- if (bus->dev.of_node)
- bus->dev.fwnode = &bus->dev.of_node->fwnode;
+ if (bus->self == NULL) {
+ node = pcibios_get_phb_of_node(bus);
+ } else {
+ node = of_node_get(bus->self->dev.of_node);
+ if (node && of_property_read_bool(node, "external-facing"))
+ bus->self->untrusted = true;
+ }
+ bus->dev.of_node = node;
++ if (node)
++ bus->dev.fwnode = &node->fwnode;
}
void pci_release_bus_of_node(struct pci_bus *bus)
pgp6uFBgx5aR3.pgp
Description: OpenPGP digital signature
Re: [PATCH v11 0/2] PWM support for HiFive Unleashed
Hi, Any comments on this patch series? Any more changes are needed or it looks good to be merged upstream? - Yash
Re: [PATCH 4/4] mtd: rawnand: meson: only initialize the RB completion once
On 2019/4/12 6:00, Martin Blumenstingl wrote: Documentation/scheduler/completion.txt states: Calling init_completion() on the same completion object twice is most likely a bug as it re-initializes the queue to an empty queue and enqueued tasks could get "lost" - use reinit_completion() in that case, but be aware of other races. Initialize nfc->completion in meson_nfc_probe using init_completion and change the call in meson_nfc_queue_rb to reinit_completion so the logic matches what the documentation suggests. Signed-off-by: Martin Blumenstingl --- drivers/mtd/nand/raw/meson_nand.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c index 57cc4bd3f665..ea57ddcec41e 100644 --- a/drivers/mtd/nand/raw/meson_nand.c +++ b/drivers/mtd/nand/raw/meson_nand.c @@ -400,7 +400,7 @@ static int meson_nfc_queue_rb(struct meson_nfc *nfc, int timeout_ms) cfg |= NFC_RB_IRQ_EN; writel(cfg, nfc->reg_base + NFC_REG_CFG); - init_completion(&nfc->completion); + reinit_completion(&nfc->completion); Tested-by:Liang Yang Acked-by: Liang Yang /* use the max erase time as the maximum clock for waiting R/B */ cmd = NFC_CMD_RB | NFC_CMD_RB_INT @@ -1380,6 +1380,7 @@ static int meson_nfc_probe(struct platform_device *pdev) nand_controller_init(&nfc->controller); INIT_LIST_HEAD(&nfc->chips); + init_completion(&nfc->completion); Tested-by:Liang Yang Acked-by: Liang Yang nfc->dev = dev;
Re: [PATCH 3/4] mtd: rawnand: meson: use a void pointer for meson_nfc_dma_buffer_setup
On 2019/4/12 6:00, Martin Blumenstingl wrote:
This simplifies the code because it gets rid of the casts to an
u8-pointer when passing "info_buf" from struct meson_nfc_nand_chip.
Also it gets rid of the cast of the u8 databuf pointer to a void
pointer.
The logic inside meson_nfc_dma_buffer_setup() doesn't care about the
pointer types themselves because it only passes them to dma_map_single
which accepts a void pointer.
No functional changes.
Signed-off-by: Martin Blumenstingl
---
drivers/mtd/nand/raw/meson_nand.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/raw/meson_nand.c
b/drivers/mtd/nand/raw/meson_nand.c
index 9a6023638101..57cc4bd3f665 100644
--- a/drivers/mtd/nand/raw/meson_nand.c
+++ b/drivers/mtd/nand/raw/meson_nand.c
@@ -470,15 +470,15 @@ static int meson_nfc_ecc_correct(struct nand_chip *nand,
u32 *bitflips,
return ret;
}
-static int meson_nfc_dma_buffer_setup(struct nand_chip *nand, u8 *databuf,
- int datalen, u8 *infobuf, int infolen,
+static int meson_nfc_dma_buffer_setup(struct nand_chip *nand, void *databuf,
+ int datalen, void *infobuf, int infolen,
enum dma_data_direction dir)
Tested-by:Liang Yang
Acked-by: Liang Yang
{
struct meson_nfc *nfc = nand_get_controller_data(nand);
u32 cmd;
int ret = 0;
- nfc->daddr = dma_map_single(nfc->dev, (void *)databuf, datalen, dir);
+ nfc->daddr = dma_map_single(nfc->dev, databuf, datalen, dir);
ret = dma_mapping_error(nfc->dev, nfc->daddr);
if (ret) {
dev_err(nfc->dev, "DMA mapping error\n");
@@ -645,7 +645,7 @@ static int meson_nfc_write_page_sub(struct nand_chip *nand,
return ret;
ret = meson_nfc_dma_buffer_setup(nand, meson_chip->data_buf,
-data_len, (u8 *)meson_chip->info_buf,
+data_len, meson_chip->info_buf,
info_len, DMA_TO_DEVICE);
Tested-by:Liang Yang
Acked-by: Liang Yang
if (ret)
return ret;
@@ -729,7 +729,7 @@ static int meson_nfc_read_page_sub(struct nand_chip *nand,
return ret;
ret = meson_nfc_dma_buffer_setup(nand, meson_chip->data_buf,
-data_len, (u8 *)meson_chip->info_buf,
+data_len, meson_chip->info_buf,
Tested-by:Liang Yang
Acked-by: Liang Yang
info_len, DMA_FROM_DEVICE);
if (ret)
return ret;
Re: [PATCH 2/4] mtd: rawnand: meson: use of_property_count_elems_of_size helper
On 2019/4/12 6:00, Martin Blumenstingl wrote:
Use the of_property_count_elems_of_size() helper instead of open-coding
it's logic. As a bonus this will now error out if the "reg" property
values use an incorrect size (anything other than sizeof(u32)).
Signed-off-by: Martin Blumenstingl
---
drivers/mtd/nand/raw/meson_nand.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/raw/meson_nand.c
b/drivers/mtd/nand/raw/meson_nand.c
index c1a6af57dab5..9a6023638101 100644
--- a/drivers/mtd/nand/raw/meson_nand.c
+++ b/drivers/mtd/nand/raw/meson_nand.c
@@ -1233,10 +1233,7 @@ meson_nfc_nand_chip_init(struct device *dev,
int ret, i;
u32 tmp, nsels;
- if (!of_get_property(np, "reg", &nsels))
- return -EINVAL;
-
- nsels /= sizeof(u32);
+ nsels = of_property_count_elems_of_size(np, "reg", sizeof(u32));
Tested-by:Liang Yang
Acked-by: Liang Yang
if (!nsels || nsels > MAX_CE_NUM) {
dev_err(dev, "invalid register property size\n");
return -EINVAL;
[PATCH -tip] kprobes: Fix an inverted result check for reusing optimized probe
Fix an inverted result check for reusing unused kprobe correctly.
This has been introduced by commit 819319fc9346 ("kprobes: Return
error if we fail to reuse kprobe instead of BUG_ON()"), which
missed to handle the return value of kprobe_optready() as
error-value. In reality, the kprobe_optready() returns a bool
result, so "true" case must be passed instead of 0.
This causes some errors on kprobe boot-time selftests on arm.
[4.563544] Beginning kprobe tests...
[4.563648] Probe ARM code
[4.563733] kprobe
[4.564700] kretprobe
[4.565538] ARM instruction simulation
[4.565671] Check decoding tables
[4.565883] Run test cases
[5.070700] FAIL: test_case_handler not run
[5.070938] FAIL: Test andge r10, r11, r14, asr r7
[5.071118] FAIL: Scenario 11
...
[ 74.174729] FAIL: Scenario 7
[ 74.211776] Total instruction simulation tests=1631, pass=1433 fail=198
[ 74.212168] kprobe tests failed
This can happen if an optimized probe is unregistered and next
kprobe is registered on same address until the previous probe
is not reclaimed.
If this happens, a hidden aggregated probe may be kept in memory,
and no new kprobe can probe same address. Also, in that case
register_kprobe() will return "1" instead of minus error value,
which can mislead caller logic.
Signed-off-by: Masami Hiramatsu
Fixes: 819319fc9346 ("kprobes: Return error if we fail to reuse kprobe instead
of BUG_ON()")
Cc: sta...@vger.kernel.org # v5.0+
---
kernel/kprobes.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index c83e54727131..b1ea30a5540e 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -709,7 +709,6 @@ static void unoptimize_kprobe(struct kprobe *p, bool force)
static int reuse_unused_kprobe(struct kprobe *ap)
{
struct optimized_kprobe *op;
- int ret;
/*
* Unused kprobe MUST be on the way of delayed unoptimizing (means
@@ -720,9 +719,8 @@ static int reuse_unused_kprobe(struct kprobe *ap)
/* Enable the probe again */
ap->flags &= ~KPROBE_FLAG_DISABLED;
/* Optimize it again (remove from op->list) */
- ret = kprobe_optready(ap);
- if (ret)
- return ret;
+ if (!kprobe_optready(ap))
+ return -EINVAL;
optimize_kprobe(ap);
return 0;
Re: [PATCH 1/4] mtd: rawnand: meson: use struct_size macro
Hello Martin and Miquel, On 2019/4/12 6:00, Martin Blumenstingl wrote: Use the recently introduced struct_size macro instead of open-coding it's logic. No functional changes. Signed-off-by: Martin Blumenstingl --- drivers/mtd/nand/raw/meson_nand.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c index cb0b03e36a35..c1a6af57dab5 100644 --- a/drivers/mtd/nand/raw/meson_nand.c +++ b/drivers/mtd/nand/raw/meson_nand.c @@ -1242,8 +1242,7 @@ meson_nfc_nand_chip_init(struct device *dev, return -EINVAL; } - meson_chip = devm_kzalloc(dev, - sizeof(*meson_chip) + (nsels * sizeof(u8)), + meson_chip = devm_kzalloc(dev, struct_size(meson_chip, sels, nsels), GFP_KERNEL); Tested-by:Liang Yang Acked-by: Liang Yang if (!meson_chip) return -ENOMEM;
linux-next: manual merge of the scsi tree with the block tree
Hi all,
Today's linux-next merge of the scsi tree got a conflict in:
drivers/scsi/sd.c
between commit:
c92e2f04b359 ("block: disk_events: introduce event flags")
from the block tree and commit:
21e6ba3f0e02 ("scsi: sd: Rely on the driver core for asynchronous probing")
d16ece577bf2 ("scsi: sd: Inline sd_probe_part2()")
from the scsi tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/scsi/sd.c
index ebc80354714c,e610b393809b..
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@@ -3404,8 -3374,49 +3342,50 @@@ static int sd_probe(struct device *dev
get_device(dev);
dev_set_drvdata(dev, sdkp);
- get_device(&sdkp->dev); /* prevent release before async_schedule */
- async_schedule_domain(sd_probe_async, sdkp, &scsi_sd_probe_domain);
+ gd->major = sd_major((index & 0xf0) >> 4);
+ gd->first_minor = ((index & 0xf) << 4) | (index & 0xfff00);
+
+ gd->fops = &sd_fops;
+ gd->private_data = &sdkp->driver;
+ gd->queue = sdkp->device->request_queue;
+
+ /* defaults, until the device tells us otherwise */
+ sdp->sector_size = 512;
+ sdkp->capacity = 0;
+ sdkp->media_present = 1;
+ sdkp->write_prot = 0;
+ sdkp->cache_override = 0;
+ sdkp->WCE = 0;
+ sdkp->RCD = 0;
+ sdkp->ATO = 0;
+ sdkp->first_scan = 1;
+ sdkp->max_medium_access_timeouts = SD_MAX_MEDIUM_TIMEOUTS;
+
+ sd_revalidate_disk(gd);
+
+ gd->flags = GENHD_FL_EXT_DEVT;
+ if (sdp->removable) {
+ gd->flags |= GENHD_FL_REMOVABLE;
+ gd->events |= DISK_EVENT_MEDIA_CHANGE;
++ gd->event_flags = DISK_EVENT_FLAG_POLL | DISK_EVENT_FLAG_UEVENT;
+ }
+
+ blk_pm_runtime_init(sdp->request_queue, dev);
+ device_add_disk(dev, gd, NULL);
+ if (sdkp->capacity)
+ sd_dif_config_host(sdkp);
+
+ sd_revalidate_disk(gd);
+
+ if (sdkp->security) {
+ sdkp->opal_dev = init_opal_dev(sdp, &sd_sec_submit);
+ if (sdkp->opal_dev)
+ sd_printk(KERN_NOTICE, sdkp, "supports TCG Opal\n");
+ }
+
+ sd_printk(KERN_NOTICE, sdkp, "Attached SCSI %sdisk\n",
+ sdp->removable ? "removable " : "");
+ scsi_autopm_put_device(sdp);
return 0;
pgpGS5iuNnrxm.pgp
Description: OpenPGP digital signature
[PATCH v3] pinctrl:intel: Retain HOSTSW_OWN for requested gpio pin
The touchpad of the ASUS laptops E403NA, X540NA, X541NA are not
responsive after suspend/resume. The following error message
shows after resume.
i2c_hid i2c-ELAN1200:00: failed to reset device.
On these laptops, the touchpad interrupt is connected via a GPIO
pin which is controlled by Intel pinctrl. After system resumes,
the GPIO is in ACPI mode and no longer works as an IRQ.
This commit saves the HOSTSW_OWN value during suspend, make sure
the HOSTSW_OWN mode remains the same after resume.
Signed-off-by: Chris Chiu
---
Note:
v2: update hostown and show pr_info only when the host mode
change on requsted GPIO is not expected.
v3: change return type of intel_gpio_update_pad_mode() from
void to u32 and use dev_warn instead of pr_info.
drivers/pinctrl/intel/pinctrl-intel.c | 56 ++-
1 file changed, 55 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/intel/pinctrl-intel.c
b/drivers/pinctrl/intel/pinctrl-intel.c
index 8cda7b535b02..5337289c550b 100644
--- a/drivers/pinctrl/intel/pinctrl-intel.c
+++ b/drivers/pinctrl/intel/pinctrl-intel.c
@@ -81,6 +81,7 @@ struct intel_pad_context {
struct intel_community_context {
u32 *intmask;
+ u32 *hostown;
};
struct intel_pinctrl_context {
@@ -1284,7 +1285,7 @@ static int intel_pinctrl_pm_init(struct intel_pinctrl
*pctrl)
for (i = 0; i < pctrl->ncommunities; i++) {
struct intel_community *community = &pctrl->communities[i];
- u32 *intmask;
+ u32 *intmask, *hostown;
intmask = devm_kcalloc(pctrl->dev, community->ngpps,
sizeof(*intmask), GFP_KERNEL);
@@ -1292,6 +1293,13 @@ static int intel_pinctrl_pm_init(struct intel_pinctrl
*pctrl)
return -ENOMEM;
communities[i].intmask = intmask;
+
+ hostown = devm_kcalloc(pctrl->dev, community->ngpps,
+ sizeof(*hostown), GFP_KERNEL);
+ if (!hostown)
+ return -ENOMEM;
+
+ communities[i].hostown = hostown;
}
pctrl->context.pads = pads;
@@ -1503,6 +1511,10 @@ int intel_pinctrl_suspend(struct device *dev)
base = community->regs + community->ie_offset;
for (gpp = 0; gpp < community->ngpps; gpp++)
communities[i].intmask[gpp] = readl(base + gpp * 4);
+
+ base = community->regs + community->hostown_offset;
+ for (gpp = 0; gpp < community->ngpps; gpp++)
+ communities[i].hostown[gpp] = readl(base + gpp * 4);
}
return 0;
@@ -1529,6 +1541,29 @@ static void intel_gpio_irq_init(struct intel_pinctrl
*pctrl)
}
}
+static u32
+intel_gpio_is_requested(struct gpio_chip *chip, int base, unsigned int size)
+{
+ u32 requested = 0;
+ unsigned int i;
+
+ for (i = 0; i < size; i++)
+ if (gpiochip_is_requested(chip, base + i))
+ requested |= BIT(i);
+
+ return requested;
+}
+
+static u32
+intel_gpio_update_pad_mode(void __iomem *hostown, u32 mask, u32 value)
+{
+ u32 curr = readl(hostown);
+ u32 updated = (curr & ~mask) | (value & mask);
+
+ writel(updated, hostown);
+ return curr;
+}
+
int intel_pinctrl_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
@@ -1588,6 +1623,25 @@ int intel_pinctrl_resume(struct device *dev)
dev_dbg(dev, "restored mask %d/%u %#08x\n", i, gpp,
readl(base + gpp * 4));
}
+
+ base = community->regs + community->hostown_offset;
+ for (gpp = 0; gpp < community->ngpps; gpp++) {
+ const struct intel_padgroup *padgrp =
&community->gpps[gpp];
+ u32 requested = 0, value = 0;
+ u32 saved = communities[i].hostown[gpp];
+
+ if (padgrp->gpio_base < 0)
+ continue;
+
+ requested = intel_gpio_is_requested(&pctrl->chip,
+ padgrp->gpio_base, padgrp->size);
+ value = intel_gpio_update_pad_mode(base + gpp * 4,
+ requested, saved);
+ if ((value ^ saved) & requested) {
+ dev_warn(dev, "restore hostown %d/%u
%#8x->%#8x\n",
+ i, gpp, value, saved);
+ }
+ }
}
return 0;
--
2.21.0
Re: [PATCH 1/1] arm: mm: Export __sync_icache_dcache() for xen-privcmd
On Sat, Apr 13, 2019 at 06:30:52PM +0200, Heinrich Schuchardt wrote: > This patch avoids > ERROR: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko] undefined! > observed when compiling v4.19.34. > > The xen-privcmd driver, which can be modular, calls set_pte_at() > which in turn may call __sync_icache_dcache(). Maybe that really is a sign that it should not be modular..
Re: [PATCH v2 1/3] RISC-V: Add separate asm/encoding.h for spec related defines
On Sat, Apr 13, 2019 at 03:38:35PM +, Anup Patel wrote: > It's better to have all RISC-V spec related defines in one place > so this patch adds separate asm/encoding.h for such defines which > can be included in assembly as well as C code. As per the discussion of version 1 on Saturday I disagree with this move. There is both a philosophical and a practical reason for that: a) in RISC-V CSR access is really nicely split out into a separate number space, just accessed through a few special instructions. It has no overlap with the rest of instruction encoding b) is pulled into just about every file build in the kernel though , and So even if you want to later add a new for instruction encoding details later, I'd rather prefer to keep CSR access separate from it.
Re: [PATCH v2] sched/clock: Prevent generic sched_clock wrap caused by tick_freeze()
Hi,
This is just a gentle ping for this patch.
On Fri, 2019-03-29 at 10:59 +0800, Chang-An Chen wrote:
> tick_freeze() introduced by suspend-to-idle in commit 124cf9117c5f
> ("PM / sleep: Make it possible to quiesce timers during suspend-to-idle")
> will use timekeeping_suspend() instead of syscore_suspend() during
> suspend-to-idle. It means that generic sched_clock will keep going because
> sched_clock_suspend() and sched_clock_resume() are not taken during
> suspend-to-idle. This will lead to generic sched_clock wrap.
>
> For example:
> In my arm system with suspend-to-idle enabled, sched_clock is registered
> as "56 bits at 13MHz, resolution 76ns, wraps every 4398046511101ns", which
> means the real wrapping duration is 8796093022202ns.
>
> [ 134.551779] suspend-to-idle suspend (timekeeping_suspend())
> [ 1204.912239] suspend-to-idle resume (timekeeping_resume())
> ..
> [ 1206.912239] suspend-to-idle suspend (timekeeping_suspend())
> [ 5880.502807] suspend-to-idle resume (timekeeping_resume())
> ..
> [ 6000.403724] suspend-to-idle suspend (timekeeping_suspend())
> [ 8035.753167] suspend-to-idle resume (timekeeping_resume())
> ..
> [ 8795.786684] (2)[321:charger_thread]..
> [ 8795.788387] (2)[321:charger_thread]..
> [0.057226] (0)[0:swapper/0]..
> [0.061447] (2)[0:swapper/2]..
>
> Sched_clock was not stopped during suspend-to-idle, and sched_clock_poll
> hrtimer was not expired because timekeeping_suspend() is taken during
> suspend-to-idle. It makes sched_clock wrap at kernel time 8796s.
>
> To fix this issue, we add sched_clock_suspend() and sched_clock_resume() in
> tick_freeze() together with timekeeping_suspend() and timekeeping_resume()
> to make sure generic sched_clock wrapping will not happen.
>
> Signed-off-by: Chang-An Chen
> Fixes: 124cf9117c5f (PM / sleep: Make it possible to quiesce timers during
> suspend-to-idle)
> ---
> kernel/time/sched_clock.c |4 ++--
> kernel/time/tick-common.c |2 ++
> kernel/time/timekeeping.h |7 +++
> 3 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
> index 094b82c..930113b 100644
> --- a/kernel/time/sched_clock.c
> +++ b/kernel/time/sched_clock.c
> @@ -272,7 +272,7 @@ static u64 notrace suspended_sched_clock_read(void)
> return cd.read_data[seq & 1].epoch_cyc;
> }
>
> -static int sched_clock_suspend(void)
> +int sched_clock_suspend(void)
> {
> struct clock_read_data *rd = &cd.read_data[0];
>
> @@ -283,7 +283,7 @@ static int sched_clock_suspend(void)
> return 0;
> }
>
> -static void sched_clock_resume(void)
> +void sched_clock_resume(void)
> {
> struct clock_read_data *rd = &cd.read_data[0];
>
> diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
> index 529143b..df40146 100644
> --- a/kernel/time/tick-common.c
> +++ b/kernel/time/tick-common.c
> @@ -487,6 +487,7 @@ void tick_freeze(void)
> trace_suspend_resume(TPS("timekeeping_freeze"),
>smp_processor_id(), true);
> system_state = SYSTEM_SUSPEND;
> + sched_clock_suspend();
> timekeeping_suspend();
> } else {
> tick_suspend_local();
> @@ -510,6 +511,7 @@ void tick_unfreeze(void)
>
> if (tick_freeze_depth == num_online_cpus()) {
> timekeeping_resume();
> + sched_clock_resume();
> system_state = SYSTEM_RUNNING;
> trace_suspend_resume(TPS("timekeeping_freeze"),
>smp_processor_id(), false);
> diff --git a/kernel/time/timekeeping.h b/kernel/time/timekeeping.h
> index 7a9b4eb..141ab3a 100644
> --- a/kernel/time/timekeeping.h
> +++ b/kernel/time/timekeeping.h
> @@ -14,6 +14,13 @@ extern ktime_t ktime_get_update_offsets_now(unsigned int
> *cwsseq,
> extern void timekeeping_warp_clock(void);
> extern int timekeeping_suspend(void);
> extern void timekeeping_resume(void);
> +#ifdef CONFIG_GENERIC_SCHED_CLOCK
> +extern int sched_clock_suspend(void);
> +extern void sched_clock_resume(void);
> +#else
> +static inline int sched_clock_suspend(void) { return 0; }
> +static inline void sched_clock_resume(void) { }
> +#endif
>
> extern void do_timer(unsigned long ticks);
> extern void update_wall_time(void);
Re: [PATCH v2 06/26] PCI: keystone: Move initializations to appropriate places
Hi Bjorn,
On 13/04/19 8:00 PM, Bjorn Helgaas wrote:
> On Mon, Mar 25, 2019 at 02:04:41PM +0530, Kishon Vijay Abraham I wrote:
>> No functional change. Move host specific platform_get_resource to
>> ks_add_pcie_port and the common platform_get_resource (applicable
>> to both host and endpoint) to probe. This is in preparation for
>> adding endpoint support to pci-keystone driver.
>
> This seems to move platform_get_resource() *from* (not *to*)
> ks_add_pcie_port().
Maybe I should have mentioned "Keep host specific platform_get_resource() in
ks_add_pcie_port() and move the common platform_get_resource() (applicable
to both host and endpoint) to probe()"
>
> You seem to be making a distinction in the commit log between (1) a
> resource that's only used for host mode, and (2) a common resource
> that's used for both host and endpoint mode. But I don't see that
> distinction in the patch, so it's a little confusing to mention it in
> the commit log.
>
> It must make endpoint support easier, but I can't quite connect the
> dots yet. Maybe endpoint will also use ks_pcie_add_pcie_port(), but
> will have a separate .probe() function that doesn't look up the
> resource that's specific to host mode?
No ks_pcie_add_pcie_port() is specific to host mode, so "config" resource is
kept there whereas "dbics" and "app" resources are common to both host mode and
device mode, so they are moved to probe().
Thanks
Kishon
>
>> Signed-off-by: Kishon Vijay Abraham I
>> ---
>> drivers/pci/controller/dwc/pci-keystone.c | 27 +--
>> 1 file changed, 15 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/pci/controller/dwc/pci-keystone.c
>> b/drivers/pci/controller/dwc/pci-keystone.c
>> index 5eebef9b9ada..95997885a05c 100644
>> --- a/drivers/pci/controller/dwc/pci-keystone.c
>> +++ b/drivers/pci/controller/dwc/pci-keystone.c
>> @@ -806,11 +806,6 @@ static int __init ks_pcie_add_pcie_port(struct
>> keystone_pcie *ks_pcie,
>> struct resource *res;
>> int ret;
>>
>> -res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbics");
>> -pci->dbi_base = devm_pci_remap_cfg_resource(dev, res);
>> -if (IS_ERR(pci->dbi_base))
>> -return PTR_ERR(pci->dbi_base);
>> -
>> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "config");
>> pp->va_cfg0_base = devm_pci_remap_cfg_resource(dev, res);
>> if (IS_ERR(pp->va_cfg0_base))
>> @@ -818,13 +813,6 @@ static int __init ks_pcie_add_pcie_port(struct
>> keystone_pcie *ks_pcie,
>>
>> pp->va_cfg1_base = pp->va_cfg0_base;
>>
>> -res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "app");
>> -ks_pcie->va_app_base = devm_ioremap_resource(dev, res);
>> -if (IS_ERR(ks_pcie->va_app_base))
>> -return PTR_ERR(ks_pcie->va_app_base);
>> -
>> -ks_pcie->app = *res;
>> -
>> pp->ops = &ks_pcie_host_ops;
>> ret = dw_pcie_host_init(pp);
>> if (ret) {
>> @@ -895,6 +883,8 @@ static int __init ks_pcie_probe(struct platform_device
>> *pdev)
>> struct dw_pcie *pci;
>> struct keystone_pcie *ks_pcie;
>> struct device_link **link;
>> +struct resource *res;
>> +void __iomem *base;
>> u32 num_viewport;
>> struct phy **phy;
>> u32 num_lanes;
>> @@ -911,6 +901,19 @@ static int __init ks_pcie_probe(struct platform_device
>> *pdev)
>> if (!pci)
>> return -ENOMEM;
>>
>> +res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "app");
>> +ks_pcie->va_app_base = devm_ioremap_resource(dev, res);
>> +if (IS_ERR(ks_pcie->va_app_base))
>> +return PTR_ERR(ks_pcie->va_app_base);
>> +
>> +ks_pcie->app = *res;
>> +
>> +res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbics");
>> +base = devm_pci_remap_cfg_resource(dev, res);
>> +if (IS_ERR(base))
>> +return PTR_ERR(base);
>> +
>> +pci->dbi_base = base;
>> pci->dev = dev;
>> pci->ops = &ks_pcie_dw_pcie_ops;
>>
>> --
>> 2.17.1
>>
Re: [PATCH v3 02/26] PCI: keystone: Cleanup error_irq configuration
Hi Bjorn,
On 13/04/19 7:33 PM, Bjorn Helgaas wrote:
> Hi Kishon,
>
> On Mon, Mar 25, 2019 at 03:09:23PM +0530, Kishon Vijay Abraham I wrote:
>> pci-keystone driver uses irq_of_parse_and_map to get irq number of
>> error_irq. Use platform_get_irq instead and move platform_get_irq()
>> and request_irq() of error_irq from ks_pcie_add_pcie_port to ks_pcie_probe
>> since error_irq is common to both RC mode and EP mode.
>
> Does this have any DT implications?
No. platform_get_irq() uses of_irq_get(), which in-turn uses of_irq_parse_one()
and irq_create_of_mapping() while irq_of_parse_and_map() directly uses
of_irq_parse_one() and irq_create_of_mapping().
The only difference is platform_get_irq() falls back to using
platform_get_resource() if of_irq_get fails.
I thought it's better to use platform_get_irq() for platform devices.
Thanks
Kishon
>
> It's not obvious that platform_get_irq() and irq_of_parse_and_map() work
> similarly or that they get the same result from DT.
>
> I'm sure they *do*, but it would be nice to have some hints in the commit
> log about why that's the case.
>
>> Signed-off-by: Kishon Vijay Abraham I
>> ---
>> drivers/pci/controller/dwc/pci-keystone.c | 43 +--
>> 1 file changed, 17 insertions(+), 26 deletions(-)
>>
>> diff --git a/drivers/pci/controller/dwc/pci-keystone.c
>> b/drivers/pci/controller/dwc/pci-keystone.c
>> index 07f55b355d75..e50f8773e768 100644
>> --- a/drivers/pci/controller/dwc/pci-keystone.c
>> +++ b/drivers/pci/controller/dwc/pci-keystone.c
>> @@ -98,8 +98,6 @@ struct keystone_pcie {
>> struct irq_domain *legacy_irq_domain;
>> struct device_node *np;
>>
>> -int error_irq;
>> -
>> /* Application register space */
>> void __iomem*va_app_base; /* DT 1st resource */
>> struct resource app;
>> @@ -743,12 +741,6 @@ static int ks_pcie_config_legacy_irq(struct
>> keystone_pcie *ks_pcie)
>> return ret;
>> }
>>
>> -static void ks_pcie_setup_interrupts(struct keystone_pcie *ks_pcie)
>> -{
>> -if (ks_pcie->error_irq > 0)
>> -ks_pcie_enable_error_irq(ks_pcie);
>> -}
>> -
>> /*
>> * When a PCI device does not exist during config cycles, keystone host
>> gets a
>> * bus error instead of returning 0x. This handler always returns 0
>> @@ -810,7 +802,6 @@ static int __init ks_pcie_host_init(struct pcie_port *pp)
>>
>> ks_pcie_stop_link(pci);
>> ks_pcie_setup_rc_app_regs(ks_pcie);
>> -ks_pcie_setup_interrupts(ks_pcie);
>> writew(PCI_IO_RANGE_TYPE_32 | (PCI_IO_RANGE_TYPE_32 << 8),
>> pci->dbi_base + PCI_IO_BASE);
>>
>> @@ -854,23 +845,6 @@ static int __init ks_pcie_add_pcie_port(struct
>> keystone_pcie *ks_pcie,
>> struct device *dev = &pdev->dev;
>> int ret;
>>
>> -/*
>> - * Index 0 is the platform interrupt for error interrupt
>> - * from RC. This is optional.
>> - */
>> -ks_pcie->error_irq = irq_of_parse_and_map(ks_pcie->np, 0);
>> -if (ks_pcie->error_irq <= 0)
>> -dev_info(dev, "no error IRQ defined\n");
>> -else {
>> -ret = request_irq(ks_pcie->error_irq, ks_pcie_err_irq_handler,
>> - IRQF_SHARED, "pcie-error-irq", ks_pcie);
>> -if (ret < 0) {
>> -dev_err(dev, "failed to request error IRQ %d\n",
>> -ks_pcie->error_irq);
>> -return ret;
>> -}
>> -}
>> -
>> pp->ops = &ks_pcie_host_ops;
>> ret = ks_pcie_dw_host_init(ks_pcie);
>> if (ret) {
>> @@ -946,6 +920,7 @@ static int __init ks_pcie_probe(struct platform_device
>> *pdev)
>> u32 num_lanes;
>> char name[10];
>> int ret;
>> +int irq;
>> int i;
>>
>> ks_pcie = devm_kzalloc(dev, sizeof(*ks_pcie), GFP_KERNEL);
>> @@ -965,6 +940,20 @@ static int __init ks_pcie_probe(struct platform_device
>> *pdev)
>> return ret;
>> }
>>
>> +irq = platform_get_irq(pdev, 0);
>> +if (irq < 0) {
>> +dev_err(dev, "missing IRQ resource: %d\n", irq);
>> +return irq;
>> +}
>> +
>> +ret = request_irq(irq, ks_pcie_err_irq_handler, IRQF_SHARED,
>> + "ks-pcie-error-irq", ks_pcie);
>> +if (ret < 0) {
>> +dev_err(dev, "failed to request error IRQ %d\n",
>> +irq);
>> +return ret;
>> +}
>> +
>> ret = of_property_read_u32(np, "num-lanes", &num_lanes);
>> if (ret)
>> num_lanes = 1;
>> @@ -1020,6 +1009,8 @@ static int __init ks_pcie_probe(struct platform_device
>> *pdev)
>> if (ret < 0)
>> goto err_get_sync;
>>
>> +ks_pcie_enable_error_irq(ks_pcie);
>> +
>> return 0;
>>
>> err_get_sync:
>> --
>> 2.17.1
>>
RE: [PATCH] MAINTAINERS: normalize Michael Hennerich's email address
> -Original Message- > From: Lukas Bulwahn [mailto:lukas.bulw...@gmail.com] > Sent: Samstag, 13. April 2019 11:26 > To: Hennerich, Michael > Cc: linux-kernel@vger.kernel.org; Lukas Bulwahn > Subject: [PATCH] MAINTAINERS: normalize Michael Hennerich's email address > > MAINTAINERS contains a lower-case and upper-case variant of > Michael Hennerich' s email address. > > Only keep the lower-case variant in MAINTAINERS. > > Signed-off-by: Lukas Bulwahn Acked-by: Michael Hennerich > --- > MAINTAINERS | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index afa019b5c461..b486b9e5d73c 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -949,7 +949,7 @@ F: drivers/dma/dma-axi-dmac.c > > ANALOG DEVICES INC IIO DRIVERS > M: Lars-Peter Clausen > -M: Michael Hennerich > +M: Michael Hennerich > W: http://wiki.analog.com/ > W: http://ez.analog.com/community/linux-device-drivers > S: Supported > -- > 2.17.1
Re: [PATCH v4 1/9] clkdev: Hold clocks_mutex while iterating clocks list
On Fri, Apr 12, 2019 at 11:31:42AM -0700, Stephen Boyd wrote:
> We recently introduced a change to support devm clk lookups. That change
> introduced a code-path that used clk_find() without holding the
> 'clocks_mutex'. Unfortunately, clk_find() iterates over the 'clocks'
> list and so we need to prevent the list from being modified at the same
> time. Do this by holding the mutex and checking to make sure it's held
> while iterating the list.
>
> Note, we don't really care if the lookup is freed after we find it with
> clk_find() because we're just doing a pointer comparison, but if we did
> care we would need to keep holding the mutex while we dereference the
> clk_lookup pointer.
>
> Fixes: 3eee6c7d119c ("clkdev: add managed clkdev lookup registration")
> Cc: Miquel Raynal
> Cc: Jerome Brunet
> Cc: Russell King
> Cc: Michael Turquette
> Cc: Jeffrey Hugo
> Cc: Chen-Yu Tsai
> Cc: Matti Vaittinen
> Signed-off-by: Stephen Boyd
Acked-By: Matti Vaittinen
Re: Linux 5.1-rc5
Can we please have the page refcount overflow fixes out on the list for review, even if it is after the fact? On Sun, Apr 14, 2019 at 03:40:47PM -0700, Linus Torvalds wrote: > Nothing in here makes me feel uncomfortable about this release cycle > so far. Knock wood. > > Shortlog appended with an overview of the details, as usual. > > Linus > > --- > > Alex Deucher (1): > drm/amdkfd: Add picasso pci id > > Alexander Potapenko (1): > x86/asm: Use stricter assembly constraints in bitops > > Anand Jain (2): > btrfs: prop: fix zstd compression parameter validation > btrfs: prop: fix vanished compression property after failed set > > Andre Przywara (1): > PCI: Add function 1 DMA alias quirk for Marvell 9170 SATA controller > > Andrei Vagin (1): > alarmtimer: Return correct remaining time > > Annaliese McDermond (2): > ASoC: tlv320aic32x4: Fix Common Pins > ASoC: tlv320aic32x4: Change author's name > > Ard Biesheuvel (1): > arm64/ftrace: fix inadvertent BUG() in trampoline check > > Arnaud Pouliquen (1): > ASoC: stm32: fix sai driver name initialisation > > Bart Van Assche (1): > locking/lockdep: Zap lock classes even with lock debugging disabled > > Brian Norris (1): > Bluetooth: btusb: request wake pin with NOAUTOEN > > CK Hu (2): > drm/mediatek: Implement gem prime vmap/vunmap function > drm/mediatek: Add Mediatek framebuffer device > > Charles Keepax (6): > ASoC: wm_adsp: Correct handling of compressed streams that restart > ASoC: wm_adsp: Correct error messages in wm_adsp_buffer_get_error > ASoC: wm_adsp: Add locking to wm_adsp2_bus_error > ASoC: wm_adsp: Shutdown any compressed streams on DSP watchdog timeout > ASoC: wm_adsp: Check for buffer in trigger stop > ASoC: cs35l35: Disable regulators on driver removal > > Chong Qiao (1): > MIPS: KGDB: fix kgdb support for SMP platforms. > > Chris Wilson (2): > drm/i915/gvt: Annotate iomem usage > drm/i915/gvt: Prevent use-after-free in ppgtt_free_all_spt() > > Christoph Hellwig (1): > sparc64/pci_sun4v: fix ATU checks for large DMA masks > > Christophe Leroy (2): > powerpc/32: Fix early boot failure with RTAS built-in > powerpc/vdso32: fix CLOCK_MONOTONIC on PPC64 > > Chuck Lever (2): > NFS: Fix handling of reply page vector > xprtrdma: Fix helper that drains the transport > > Cornelia Huck (1): > virtio: Honour 'may_reduce_num' in vring_create_virtqueue > > Dan Carpenter (5): > drm/mediatek: Fix an error code in mtk_hdmi_dt_parse_pdata() > aio: Fix an error code in __io_submit_one() > irqchip/irq-ls1x: Missing error code in ls1x_intc_of_init() > NFC: nci: Add some bounds checking in nci_hci_cmd_received() > nfc: nci: Potential off by one in ->pipes[] array > > Daniel Drake (1): > mmc: alcor: don't write data before command has completed > > Daniel Mack (1): > ASoC: cs4270: Set auto-increment bit for register writes > > Daniel Mentz (1): > ALSA: uapi: #include in asound.h > > Dave Airlie (1): > drm/udl: add a release method and delay modeset teardown > > David Müller (1): > clk: x86: Add system specific quirk to mark clocks as critical > > Dongli Zhang (2): > virtio-blk: limit number of hw queues by nr_cpu_ids > scsi: virtio_scsi: limit number of hw queues by nr_cpu_ids > > Erik Schmauss (1): > ACPICA: Namespace: remove address node from global list after > method termination > > Faiz Abbas (1): > mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning > > Filipe Manana (1): > Btrfs: do not allow trimming when a fs is mounted with the > nologreplay option > > Guenter Roeck (1): > ASoC: intel: Fix crash at suspend/resume after failed codec registration > > Gustavo A. R. Silva (1): > ASoC: ab8500: Mark expected switch fall-through > > Hans Holmberg (1): > lightnvm: pblk: fix crash in pblk_end_partial_read due to multipage > bvecs > > Hans de Goede (1): > ASoC: Intel: cht_bsw_max98090_ti: Enable codec clock once and > keep it enabled > > Heiner Kallweit (1): > r8169: disable ASPM again > > Horatiu Vultur (1): > MIPS: generic: Add switchdev, pinctrl and fit to ocelot_defconfig > > Hui Wang (1): > ALSA: hda - Add two more machines to the power_save_blacklist > > Imre Deak (1): > drm/i915: Get power refs in encoder->get_power_domains() > > Iuliana Prodan (1): > crypto: caam - fix copy of next buffer for xcbc and cmac > > James Smart (1): > nvme-fc: correct csn initialization and increments on error > > Jani Nikula (1): > drm/i915/dp: revert back to max link rate and lane count on eDP > > Jann Horn (1): > linux/kernel.h: Use parentheses around argument in u64_to_user_ptr() > > Jarkko Sakkinen (2): > tpm: turn on TPM on suspend for TPM 1.x > KEYS: trusted: all
Re: [PATCH v3 3/4] arm64: kdump: support more than one crash kernel regions
Hi, On Mon, Apr 15, 2019 at 10:05:18AM +0800, Chen Zhou wrote: > Hi Mike, > > On 2019/4/14 20:10, Mike Rapoport wrote: > >> > >> solution A:phys_addr_t start[INIT_MEMBLOCK_RESERVED_REGIONS * 2]; > >>phys_addr_t end[INIT_MEMBLOCK_RESERVED_REGIONS * 2]; > >> start, end is physical addr > >> > >> solution B:int start_rgn[INIT_MEMBLOCK_REGIONS], > >> end_rgn[INIT_MEMBLOCK_REGIONS]; > >> start_rgn, end_rgn is rgn index > >> > >> Solution B do less remove operations and with no warning comparing to > >> solution A. > >> I think solution B is better, could you give some suggestions? > > > > Solution B is indeed better that solution A, but I'm still worried by > > relatively large arrays on stack and the amount of loops :( > > > > The very least we could do is to call memblock_cap_memory_range() to drop > > the memory before and after the ranges we'd like to keep. > > 1. relatively large arrays > As my said above, the start_rgn, end_rgn is rgn index, we could use unsigned > char type. Let's stick to int for now > 2. loops > Loops always exist, and the solution with fewer loops may be just > encapsulated well. Of course the loops are there, I just hoped we could get rid of the nested loop and get away with single passes in all the cases. Apparently it's not the case :( > Thanks, > Chen Zhou > -- Sincerely yours, Mike.
Re: [PATCH v3 3/4] arm64: kdump: support more than one crash kernel regions
On Mon, Apr 15, 2019 at 10:27:30AM +0800, Chen Zhou wrote:
> Hi Mike,
>
> On 2019/4/14 20:13, Mike Rapoport wrote:
> > Hi,
> >
> > On Tue, Apr 09, 2019 at 06:28:18PM +0800, Chen Zhou wrote:
> >> After commit (arm64: kdump: support reserving crashkernel above 4G),
> >> there may be two crash kernel regions, one is below 4G, the other is
> >> above 4G.
> >>
> >> Crash dump kernel reads more than one crash kernel regions via a dtb
> >> property under node /chosen,
> >> linux,usable-memory-range =
> >
> > Somehow I've missed that previously, but how is this supposed to work on
> > EFI systems?
>
> Whatever the way in which the systems work, there is FDT
> pointer(__fdt_pointer)
> in arm64 kernel and file /sys/firmware/fdt will be created in late_initcall.
>
> Kexec-tools read and update file /sys/firmware/fdt in EFI systems to support
> kdump to
> boot capture kernel.
>
> For supporting more than one crash kernel regions, kexec-tools make changes
> accordingly.
> Details are in below:
> http://lists.infradead.org/pipermail/kexec/2019-April/022792.html
Thanks for the clarification!
> Thanks,
> Chen Zhou
>
> >
> >> Signed-off-by: Chen Zhou
> >> ---
> >> arch/arm64/mm/init.c | 66
> >>
> >> include/linux/memblock.h | 6 +
> >> mm/memblock.c| 7 ++---
> >> 3 files changed, 66 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> >> index 3bebddf..0f18665 100644
> >> --- a/arch/arm64/mm/init.c
> >> +++ b/arch/arm64/mm/init.c
> >> @@ -65,6 +65,11 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
> >>
> >> #ifdef CONFIG_KEXEC_CORE
> >>
> >> +/* at most two crash kernel regions, low_region and high_region */
> >> +#define CRASH_MAX_USABLE_RANGES 2
> >> +#define LOW_REGION_IDX0
> >> +#define HIGH_REGION_IDX 1
> >> +
> >> /*
> >> * reserve_crashkernel() - reserves memory for crash kernel
> >> *
> >> @@ -297,8 +302,8 @@ static int __init
> >> early_init_dt_scan_usablemem(unsigned long node,
> >>const char *uname, int depth, void *data)
> >> {
> >>struct memblock_region *usablemem = data;
> >> - const __be32 *reg;
> >> - int len;
> >> + const __be32 *reg, *endp;
> >> + int len, nr = 0;
> >>
> >>if (depth != 1 || strcmp(uname, "chosen") != 0)
> >>return 0;
> >> @@ -307,22 +312,63 @@ static int __init
> >> early_init_dt_scan_usablemem(unsigned long node,
> >>if (!reg || (len < (dt_root_addr_cells + dt_root_size_cells)))
> >>return 1;
> >>
> >> - usablemem->base = dt_mem_next_cell(dt_root_addr_cells, ®);
> >> - usablemem->size = dt_mem_next_cell(dt_root_size_cells, ®);
> >> + endp = reg + (len / sizeof(__be32));
> >> + while ((endp - reg) >= (dt_root_addr_cells + dt_root_size_cells)) {
> >> + usablemem[nr].base = dt_mem_next_cell(dt_root_addr_cells, ®);
> >> + usablemem[nr].size = dt_mem_next_cell(dt_root_size_cells, ®);
> >> +
> >> + if (++nr >= CRASH_MAX_USABLE_RANGES)
> >> + break;
> >> + }
> >>
> >>return 1;
> >> }
> >>
> >> static void __init fdt_enforce_memory_region(void)
> >> {
> >> - struct memblock_region reg = {
> >> - .size = 0,
> >> - };
> >> + int i, cnt = 0;
> >> + struct memblock_region regs[CRASH_MAX_USABLE_RANGES];
> >> +
> >> + memset(regs, 0, sizeof(regs));
> >> + of_scan_flat_dt(early_init_dt_scan_usablemem, regs);
> >> +
> >> + for (i = 0; i < CRASH_MAX_USABLE_RANGES; i++)
> >> + if (regs[i].size)
> >> + cnt++;
> >> + else
> >> + break;
> >> +
> >> + if (cnt - 1 == LOW_REGION_IDX)
> >> + memblock_cap_memory_range(regs[LOW_REGION_IDX].base,
> >> + regs[LOW_REGION_IDX].size);
> >> + else if (cnt - 1 == HIGH_REGION_IDX) {
> >> + /*
> >> + * Two crash kernel regions, cap the memory range
> >> + * [regs[LOW_REGION_IDX].base, regs[HIGH_REGION_IDX].end]
> >> + * and then remove the memory range in the middle.
> >> + */
> >> + int start_rgn, end_rgn, i, ret;
> >> + phys_addr_t mid_base, mid_size;
> >> +
> >> + mid_base = regs[LOW_REGION_IDX].base +
> >> regs[LOW_REGION_IDX].size;
> >> + mid_size = regs[HIGH_REGION_IDX].base - mid_base;
> >> + ret = memblock_isolate_range(&memblock.memory, mid_base,
> >> + mid_size, &start_rgn, &end_rgn);
> >>
> >> - of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
> >> + if (ret)
> >> + return;
> >>
> >> - if (reg.size)
> >> - memblock_cap_memory_range(reg.base, reg.size);
> >> + memblock_cap_memory_range(regs[LOW_REGION_IDX].base,
> >> + regs[HIGH_REGION_IDX].base -
> >> + regs[LOW_REGION_IDX].base +
> >> + regs[HIGH_REGION_IDX].si
Re: misuse of fget_raw() in perf_event_get()
On Sat, Apr 13, 2019 at 10:02:42PM +0100, Al Viro wrote:
> What's the point of using fget_raw(), if you do
> _not_ accept O_PATH descriptors? That should be fget()...
I think you're talking about commit e03e7ee34fdd ("perf/bpf: Convert
perf_event_array to use struct file")
I don't really remember why we went with this instead of fget().
There was a bunch of back and forth back then with Peter.
Now it looks like that it can be fget just fine.
I think cgroup_get_from_fd() should do the same too?
linux-next: manual merge of the tip tree with the arm64 tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
mm/kasan/Makefile
between commit:
e2092740b723 ("kasan: Makefile: Replace -pg with CC_FLAGS_FTRACE")
from the arm64 tree and commit:
57b78a62e7f2 ("x86/uaccess, kasan: Fix KASAN vs SMAP")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc mm/kasan/Makefile
index f06ee820d356,613dfe681e9f..
--- a/mm/kasan/Makefile
+++ b/mm/kasan/Makefile
@@@ -5,9 -6,10 +6,10 @@@ UBSAN_SANITIZE_generic_report.o :=
UBSAN_SANITIZE_tags.o := n
KCOV_INSTRUMENT := n
-CFLAGS_REMOVE_common.o = -pg
-CFLAGS_REMOVE_generic.o = -pg
-CFLAGS_REMOVE_generic_report.o = -pg
-CFLAGS_REMOVE_tags.o = -pg
+CFLAGS_REMOVE_common.o = $(CC_FLAGS_FTRACE)
+CFLAGS_REMOVE_generic.o = $(CC_FLAGS_FTRACE)
++CFLAGS_REMOVE_generic_report.o = $(CC_FLAGS_FTRACE)
+CFLAGS_REMOVE_tags.o = $(CC_FLAGS_FTRACE)
# Function splitter causes unnecessary splits in __asan_load1/__asan_store1
# see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63533
pgpAbjFkbU_bG.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the tip tree with the arm64 tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/s390/include/asm/Kbuild
between commit:
fdcd06a8ab77 ("arch: Use asm-generic header for asm/mmiowb.h")
from the arm64 tree and commit:
46ad0840b158 ("locking/rwsem: Remove arch specific rwsem files")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/s390/include/asm/Kbuild
index bdc4f06a04c5,d5fadefea33c..
--- a/arch/s390/include/asm/Kbuild
+++ b/arch/s390/include/asm/Kbuild
@@@ -20,8 -20,6 +20,7 @@@ generic-y += local.
generic-y += local64.h
generic-y += mcs_spinlock.h
generic-y += mm-arch-hooks.h
+generic-y += mmiowb.h
- generic-y += rwsem.h
generic-y += trace_clock.h
generic-y += unaligned.h
generic-y += word-at-a-time.h
pgpSgACLcj9JN.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 01/21] docs/memory-barriers.txt: Rewrite "KERNEL I/O BARRIER EFFECTS" section
On Fri, 2019-04-12 at 14:17 +0100, Will Deacon wrote: > > +the same CPU thread to a particular device will arrive in program > +order. > + > + 2. A writeX() by a CPU thread to the peripheral will first wait for the > +completion of all prior writes to memory either issued by the thread > +or issued while holding a spinlock that was subsequently taken by the > +thread. This ensures that writes by the CPU to an outbound DMA > +buffer allocated by dma_alloc_coherent() will be visible to a DMA > +engine when the CPU writes to its MMIO control register to trigger > +the transfer. Not particularily trying to be annoying here but I find the above rather hard to parse :) I know what you're getting at but I'm not sure somebody who doesn't will understand. One way would be to instead prefix the whole thing with a blurb along the lines of: readX() and writeX() provide some ordering guarantees versus each other and other memory accesses that are described below. Those guarantees apply to accesses performed either by the same logical thread of execution, or by different threads but while holding the same lock (spinlock or mutex). Then have as simpler description of each case. No ? > + 3. A readX() by a CPU thread from the peripheral will complete before > +any subsequent reads from memory by the same thread can begin. This > +ensures that reads by the CPU from an incoming DMA buffer allocated > +by dma_alloc_coherent() will not see stale data after reading from > +the DMA engine's MMIO status register to establish that the DMA > +transfer has completed. > + > + 4. A readX() by a CPU thread from the peripheral will complete before > +any subsequent delay() loop can begin execution on the same thread. > +This ensures that two MMIO register writes by the CPU to a peripheral > +will arrive at least 1us apart if the first write is immediately read > +back with readX() and udelay(1) is called prior to the second > +writeX(): > > writel(42, DEVICE_REGISTER_0); // Arrives at the device... > readl(DEVICE_REGISTER_0); > @@ -2600,8 +2604,10 @@ guarantees: > These will perform appropriately for the type of access they're actually > doing, be it inX()/outX() or readX()/writeX(). > > -All of these accessors assume that the underlying peripheral is > little-endian, > -and will therefore perform byte-swapping operations on big-endian > architectures. > +With the exception of the string accessors (insX(), outsX(), readsX() and > +writesX()), all of the above assume that the underlying peripheral is > +little-endian and will therefore perform byte-swapping operations on > big-endian > +architectures. > > >
Re: [PATCH v5 0/5] init: Do not select DEBUG_KERNEL by default
On Sat, Apr 13, 2019 at 3:44 PM Sinan Kaya wrote:
>
> CONFIG_DEBUG_KERNEL has been designed to just enable Kconfig options.
> Kernel code generatoin should not depend on CONFIG_DEBUG_KERNEL.
>
> Proposed alternative plan: let's add a new symbol, something like
> DEBUG_MISC ("Miscellaneous debug code that should be under a more
> specific debug option but isn't"), make it depend on DEBUG_KERNEL and be
> "default DEBUG_KERNEL" but allow itself to be turned off, and then
> mechanically change the small handful of "#ifdef CONFIG_DEBUG_KERNEL" to
> "#ifdef CONFIG_DEBUG_MISC".
Thanks! This looks good to me. For the series:
Reviewed-by: Kees Cook
Andrew, can you take these from lkml, or should the series get resent
directly to you? I think you might be the best to carry this?
Thanks!
-Kees
>
> Diff from v4:
> - collect reviewed-by
> - collect acked-by
> - fix nit on 1/5
>
> Sinan Kaya (5):
> init: Introduce DEBUG_MISC option
> powerpc: Replace CONFIG_DEBUG_KERNEL with CONFIG_DEBUG_MISC
> mips: Replace CONFIG_DEBUG_KERNEL with CONFIG_DEBUG_MISC
> xtensa: Replace CONFIG_DEBUG_KERNEL with CONFIG_DEBUG_MISC
> net: Replace CONFIG_DEBUG_KERNEL with CONFIG_DEBUG_MISC
>
> arch/mips/kernel/setup.c | 2 +-
> arch/powerpc/kernel/sysfs.c| 8
> arch/xtensa/include/asm/irqflags.h | 2 +-
> arch/xtensa/kernel/smp.c | 2 +-
> lib/Kconfig.debug | 9 +
> net/netfilter/core.c | 2 +-
> 6 files changed, 17 insertions(+), 8 deletions(-)
>
> --
> 2.21.0
>
--
Kees Cook
Re: [PATCH v4 2/3] csky: Add support for perf registers sampling
Hi Mao,
On Thu, Apr 11, 2019 at 03:45:00PM +0800, Mao Han wrote:
> This patch implements the perf registers sampling and validation API
> for csky arch. The valid registers and their register ID are defined in
> perf_regs.h. Perf tool can backtrace in userspace with unwind library
> and the registers/user stack dump support.
>
> CC: Guo Ren
>
> Signed-off-by: Mao Han
> ---
> arch/csky/Kconfig | 2 ++
> arch/csky/include/uapi/asm/perf_regs.h | 51
> ++
> arch/csky/kernel/Makefile | 1 +
> arch/csky/kernel/perf_regs.c | 40 ++
> 4 files changed, 94 insertions(+)
> create mode 100644 arch/csky/include/uapi/asm/perf_regs.h
> create mode 100644 arch/csky/kernel/perf_regs.c
>
> diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig
> index c4974cf..8e45c7a 100644
> --- a/arch/csky/Kconfig
> +++ b/arch/csky/Kconfig
> @@ -38,6 +38,8 @@ config CSKY
> select HAVE_KERNEL_LZO
> select HAVE_KERNEL_LZMA
> select HAVE_PERF_EVENTS
> + select HAVE_PERF_REGS
> + select HAVE_PERF_USER_STACK_DUMP
> select HAVE_DMA_API_DEBUG
> select HAVE_DMA_CONTIGUOUS
> select HAVE_SYSCALL_TRACEPOINTS
> diff --git a/arch/csky/include/uapi/asm/perf_regs.h
> b/arch/csky/include/uapi/asm/perf_regs.h
> new file mode 100644
> index 000..ee323d8
> --- /dev/null
> +++ b/arch/csky/include/uapi/asm/perf_regs.h
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +// Copyright (C) 2019 Hangzhou C-SKY Microsystems co.,ltd.
> +
> +#ifndef _ASM_CSKY_PERF_REGS_H
> +#define _ASM_CSKY_PERF_REGS_H
> +
> +/* Index of struct pt_regs */
> +enum perf_event_csky_regs {
> + PERF_REG_CSKY_TLS,
> + PERF_REG_CSKY_LR,
> + PERF_REG_CSKY_PC,
> + PERF_REG_CSKY_SR,
> + PERF_REG_CSKY_SP,
> + PERF_REG_CSKY_ORIG_A0,
> + PERF_REG_CSKY_A0,
> + PERF_REG_CSKY_A1,
> + PERF_REG_CSKY_A2,
> + PERF_REG_CSKY_A3,
> + PERF_REG_CSKY_REGS0,
> + PERF_REG_CSKY_REGS1,
> + PERF_REG_CSKY_REGS2,
> + PERF_REG_CSKY_REGS3,
> + PERF_REG_CSKY_REGS4,
> + PERF_REG_CSKY_REGS5,
> + PERF_REG_CSKY_REGS6,
> + PERF_REG_CSKY_REGS7,
> + PERF_REG_CSKY_REGS8,
> + PERF_REG_CSKY_REGS9,
> +#if defined(__CSKYABIV2__)
> + PERF_REG_CSKY_EXREGS0,
> + PERF_REG_CSKY_EXREGS1,
> + PERF_REG_CSKY_EXREGS2,
> + PERF_REG_CSKY_EXREGS3,
> + PERF_REG_CSKY_EXREGS4,
> + PERF_REG_CSKY_EXREGS5,
> + PERF_REG_CSKY_EXREGS6,
> + PERF_REG_CSKY_EXREGS7,
> + PERF_REG_CSKY_EXREGS8,
> + PERF_REG_CSKY_EXREGS9,
> + PERF_REG_CSKY_EXREGS10,
> + PERF_REG_CSKY_EXREGS11,
> + PERF_REG_CSKY_EXREGS12,
> + PERF_REG_CSKY_EXREGS13,
> + PERF_REG_CSKY_EXREGS14,
> + PERF_REG_CSKY_HI,
> + PERF_REG_CSKY_LO,
> + PERF_REG_CSKY_DCSR,
> +#endif
> + PERF_REG_CSKY_MAX,
> +};
> +#endif /* _ASM_CSKY_PERF_REGS_H */
> diff --git a/arch/csky/kernel/Makefile b/arch/csky/kernel/Makefile
> index 4c462f5..1624b04 100644
> --- a/arch/csky/kernel/Makefile
> +++ b/arch/csky/kernel/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_FUNCTION_TRACER) += ftrace.o
> obj-$(CONFIG_STACKTRACE) += stacktrace.o
> obj-$(CONFIG_CSKY_PMU_V1)+= perf_event.o
> obj-$(CONFIG_PERF_EVENTS)+= perf_callchain.o
> +obj-$(CONFIG_HAVE_PERF_REGS)+= perf_regs.o
>
> ifdef CONFIG_FUNCTION_TRACER
> CFLAGS_REMOVE_ftrace.o = $(CC_FLAGS_FTRACE)
> diff --git a/arch/csky/kernel/perf_regs.c b/arch/csky/kernel/perf_regs.c
> new file mode 100644
> index 000..88f1875
> --- /dev/null
> +++ b/arch/csky/kernel/perf_regs.c
> @@ -0,0 +1,40 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2019 Hangzhou C-SKY Microsystems co.,ltd.
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +u64 perf_reg_value(struct pt_regs *regs, int idx)
> +{
> + if (WARN_ON_ONCE((u32)idx >= PERF_REG_CSKY_MAX))
> + return 0;
> +
> + return ((long *)regs)[idx];
Please use:
return (u64)((u32 *)regs + idx);
> +}
> +
> +#define REG_RESERVED (~((1ULL << PERF_REG_CSKY_MAX) - 1))
> +
> +int perf_reg_validate(u64 mask)
> +{
> + if (!mask || mask & REG_RESERVED)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +u64 perf_reg_abi(struct task_struct *task)
> +{
> + return PERF_SAMPLE_REGS_ABI_32;
> +}
> +
> +void perf_get_regs_user(struct perf_regs *regs_user,
> + struct pt_regs *regs,
> + struct pt_regs *regs_user_copy)
> +{
> + regs_user->regs = task_pt_regs(current);
> + regs_user->abi = perf_reg_abi(current);
> +}
Best Regards
Guo Ren
[PATCH 1/2] doc: Fixup definition of rcupdate.rcu_task_stall_timeout
A positive value of rcupdate.rcu_task_stall_timeout is an interval in seconds rather than jiffies. Signed-off-by: Zhenzhong Duan --- Documentation/RCU/stallwarn.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt index 1ab70c3..13e88fc 100644 --- a/Documentation/RCU/stallwarn.txt +++ b/Documentation/RCU/stallwarn.txt @@ -153,7 +153,7 @@ rcupdate.rcu_task_stall_timeout This boot/sysfs parameter controls the RCU-tasks stall warning interval. A value of zero or less suppresses RCU-tasks stall warnings. A positive value sets the stall-warning interval - in jiffies. An RCU-tasks stall warning starts with the line: + in seconds. An RCU-tasks stall warning starts with the line: INFO: rcu_tasks detected stalls on tasks: -- 1.8.3.1
[PATCH 2/2] doc: kernel-parameters.txt: fix documentation of nmi_watchdog parameter
As stated in "Documentation/lockup-watchdogs.txt:line 22", the default behaivor after 'hardlockup' is to stay locked up rather than panic. Signed-off-by: Zhenzhong Duan --- Documentation/admin-guide/kernel-parameters.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 2b8ee90..fcc9579 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2769,7 +2769,7 @@ 0 - turn hardlockup detector in nmi_watchdog off 1 - turn hardlockup detector in nmi_watchdog on When panic is specified, panic when an NMI watchdog - timeout occurs (or 'nopanic' to override the opposite + timeout occurs (or 'nopanic' which is the opposite default). To disable both hard and soft lockup detectors, please see 'nowatchdog'. This is useful when you use a panic=... timeout and -- 1.8.3.1
Re: [PATCH v3 net-next 18/24] net: dsa: sja1105: Add support for traffic through standalone ports
> It fails to decode the frames, obviously. But so does any other EtherType.
> Florian was hinting
> (https://lwn.net/ml/netdev/b52f4cdf-edcf-0757-1d6e-d4a831ec7...@gmail.com/)
> at the recent pull requests submitted to tcpdump and libpcap that make
> it possible to decode based on the string in
> /sys/class/net/${master}/dsa/tagging. I admit I haven't actually
> tested or studied those closely yet (there are more important things
> to focus on ATM), but since my driver returns "8021q" in sysfs and
> yours returns "edsa", I would presume tcpdump could use that
> information.
No it does not. It is a valid EtherType, that is what is used to
trigger the decoding, it takes no notice of what is in
/sys/class/net/${master}/dsa/tagging, nor the extra meta-data added to
the pcap file. There is no need. you can identify it is a Marvell EDSA
header from the EtherType.
In fact, this tcpdump code for decoding EDSA pre-dated Florians
patches by a few years.
You only need the code which Florian added when you cannot identify
the header directly from the packet. And that is true for most of the
tagging protocols. But EDSA you can.
> Anyway, since you obviously know more on this topic than I do,
> please make me understand what are the real problems in spoofing the
> Ethertype as a Marvell one.
Despite there being an EDSA EtherType in the frame, what follows is
not an ESDA header. It is like having the IPv4 EtherType but what
following is not an IP header. Broken.
Andrew
linux-next: manual merge of the block tree with Linus' tree
Hi all,
Today's linux-next merge of the block tree got a conflict in:
include/linux/bvec.h
between commit:
1200e07f3ad4 ("block: don't use for-inside-for in bio_for_each_segment_all")
from Linus' tree and commit:
52d52d1c98a9 ("block: only allow contiguous page structs in a bio_vec")
from the block tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/linux/bvec.h
index 3bc91879e1e2,44b0f4684190..
--- a/include/linux/bvec.h
+++ b/include/linux/bvec.h
@@@ -156,8 -151,8 +151,8 @@@ static inline void bvec_advance(const s
{
struct bio_vec *bv = &iter_all->bv;
- if (bv->bv_page) {
+ if (iter_all->done) {
- bv->bv_page = nth_page(bv->bv_page, 1);
+ bv->bv_page++;
bv->bv_offset = 0;
} else {
bv->bv_page = bvec->bv_page;
pgppe2Il3Bc9I.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the block tree with Linus' tree
Hi all,
Today's linux-next merge of the block tree got a conflict in:
block/bfq-iosched.c
between commit:
eed47d19d936 ("block, bfq: fix use after free in bfq_bfqq_expire")
from Linus' tree and commit:
636b8fe86bed ("block, bfq: fix some typos in comments")
from the block tree.
I fixed it up (the former included the fix from the latter, so I just
used that) and can carry the fix as necessary. This is now fixed as far as
linux-next is concerned, but any non trivial conflicts should be mentioned
to your upstream maintainer when your tree is submitted for merging.
You may also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpiKr3dDC2JG.pgp
Description: OpenPGP digital signature
Re: [PATCH] crypto: testmgr - allocate buffers with __GFP_COMP
On Sun, Apr 14, 2019 at 07:24:12PM -0700, Matthew Wilcox wrote:
> On Thu, Apr 11, 2019 at 01:32:32PM -0700, Kees Cook wrote:
> > > @@ -156,7 +156,8 @@ static int __testmgr_alloc_buf(char *buf[XBUFSIZE],
> > > int order)
> > > int i;
> > >
> > > for (i = 0; i < XBUFSIZE; i++) {
> > > - buf[i] = (char *)__get_free_pages(GFP_KERNEL, order);
> > > + buf[i] = (char *)__get_free_pages(GFP_KERNEL | __GFP_COMP,
> > > + order);
> >
> > Is there a reason __GFP_COMP isn't automatically included in all page
> > allocations? (Or rather, it seems like the exception is when things
> > should NOT be considered part of the same allocation, so something
> > like __GFP_SINGLE should exist?.)
>
> The question is not whether or not things should be considered part of the
> same allocation. The question is whether the allocation is of a compound
> page or of N consecutive pages. Now you're asking what the difference is,
> and it's whether you need to be able to be able to call compound_head(),
> compound_order(), PageTail() or use a compound_dtor. If you don't, then
> you can save some time at allocation & free by not specifying __GFP_COMP.
Thanks for clarifying Matthew.
Eric, this means that we should not use __GFP_COMP here just to
silent what is clearly a broken warning.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] printk: tie printk_once / printk_deferred_once into .data.once for reset
On (04/12/19 22:11), Paul Gortmaker wrote:
> In commit b1fca27d384e ("kernel debug: support resetting WARN*_ONCE")
> we got the opportunity to reset state on the one shot messages,
> without having to reboot.
Didn't know that.
> However printk_once (printk_deferred_once) live in a different file
> and didn't get the same kind of update/conversion, so they remain
> unconditionally one shot, until the system is rebooted.
>
> For example, we currently have:
>
> sched/rt.c: printk_deferred_once("sched: RT throttling activated\n");
>
> ..which could reasonably be tripped as someone is testing and tuning
> a new system/workload and their task placements. For consistency, and
> to avoid reboots in the same vein as the original commit, we make these
> two instances of _once the same as the WARN*_ONCE instances are.
Looks OK to me.
Reviewed-by: Sergey Senozhatsky
-ss
Re: [PATCH v3 3/4] arm64: kdump: support more than one crash kernel regions
Hi Mike,
On 2019/4/14 20:13, Mike Rapoport wrote:
> Hi,
>
> On Tue, Apr 09, 2019 at 06:28:18PM +0800, Chen Zhou wrote:
>> After commit (arm64: kdump: support reserving crashkernel above 4G),
>> there may be two crash kernel regions, one is below 4G, the other is
>> above 4G.
>>
>> Crash dump kernel reads more than one crash kernel regions via a dtb
>> property under node /chosen,
>> linux,usable-memory-range =
>
> Somehow I've missed that previously, but how is this supposed to work on
> EFI systems?
Whatever the way in which the systems work, there is FDT pointer(__fdt_pointer)
in arm64 kernel and file /sys/firmware/fdt will be created in late_initcall.
Kexec-tools read and update file /sys/firmware/fdt in EFI systems to support
kdump to
boot capture kernel.
For supporting more than one crash kernel regions, kexec-tools make changes
accordingly.
Details are in below:
http://lists.infradead.org/pipermail/kexec/2019-April/022792.html
Thanks,
Chen Zhou
>
>> Signed-off-by: Chen Zhou
>> ---
>> arch/arm64/mm/init.c | 66
>>
>> include/linux/memblock.h | 6 +
>> mm/memblock.c| 7 ++---
>> 3 files changed, 66 insertions(+), 13 deletions(-)
>>
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 3bebddf..0f18665 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -65,6 +65,11 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
>>
>> #ifdef CONFIG_KEXEC_CORE
>>
>> +/* at most two crash kernel regions, low_region and high_region */
>> +#define CRASH_MAX_USABLE_RANGES 2
>> +#define LOW_REGION_IDX 0
>> +#define HIGH_REGION_IDX 1
>> +
>> /*
>> * reserve_crashkernel() - reserves memory for crash kernel
>> *
>> @@ -297,8 +302,8 @@ static int __init early_init_dt_scan_usablemem(unsigned
>> long node,
>> const char *uname, int depth, void *data)
>> {
>> struct memblock_region *usablemem = data;
>> -const __be32 *reg;
>> -int len;
>> +const __be32 *reg, *endp;
>> +int len, nr = 0;
>>
>> if (depth != 1 || strcmp(uname, "chosen") != 0)
>> return 0;
>> @@ -307,22 +312,63 @@ static int __init
>> early_init_dt_scan_usablemem(unsigned long node,
>> if (!reg || (len < (dt_root_addr_cells + dt_root_size_cells)))
>> return 1;
>>
>> -usablemem->base = dt_mem_next_cell(dt_root_addr_cells, ®);
>> -usablemem->size = dt_mem_next_cell(dt_root_size_cells, ®);
>> +endp = reg + (len / sizeof(__be32));
>> +while ((endp - reg) >= (dt_root_addr_cells + dt_root_size_cells)) {
>> +usablemem[nr].base = dt_mem_next_cell(dt_root_addr_cells, ®);
>> +usablemem[nr].size = dt_mem_next_cell(dt_root_size_cells, ®);
>> +
>> +if (++nr >= CRASH_MAX_USABLE_RANGES)
>> +break;
>> +}
>>
>> return 1;
>> }
>>
>> static void __init fdt_enforce_memory_region(void)
>> {
>> -struct memblock_region reg = {
>> -.size = 0,
>> -};
>> +int i, cnt = 0;
>> +struct memblock_region regs[CRASH_MAX_USABLE_RANGES];
>> +
>> +memset(regs, 0, sizeof(regs));
>> +of_scan_flat_dt(early_init_dt_scan_usablemem, regs);
>> +
>> +for (i = 0; i < CRASH_MAX_USABLE_RANGES; i++)
>> +if (regs[i].size)
>> +cnt++;
>> +else
>> +break;
>> +
>> +if (cnt - 1 == LOW_REGION_IDX)
>> +memblock_cap_memory_range(regs[LOW_REGION_IDX].base,
>> +regs[LOW_REGION_IDX].size);
>> +else if (cnt - 1 == HIGH_REGION_IDX) {
>> +/*
>> + * Two crash kernel regions, cap the memory range
>> + * [regs[LOW_REGION_IDX].base, regs[HIGH_REGION_IDX].end]
>> + * and then remove the memory range in the middle.
>> + */
>> +int start_rgn, end_rgn, i, ret;
>> +phys_addr_t mid_base, mid_size;
>> +
>> +mid_base = regs[LOW_REGION_IDX].base +
>> regs[LOW_REGION_IDX].size;
>> +mid_size = regs[HIGH_REGION_IDX].base - mid_base;
>> +ret = memblock_isolate_range(&memblock.memory, mid_base,
>> +mid_size, &start_rgn, &end_rgn);
>>
>> -of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
>> +if (ret)
>> +return;
>>
>> -if (reg.size)
>> -memblock_cap_memory_range(reg.base, reg.size);
>> +memblock_cap_memory_range(regs[LOW_REGION_IDX].base,
>> +regs[HIGH_REGION_IDX].base -
>> +regs[LOW_REGION_IDX].base +
>> +regs[HIGH_REGION_IDX].size);
>> +for (i = end_rgn - 1; i >= start_rgn; i--) {
>> +if (!memblock_is_nomap(&memblock.memory.regions[i]))
>> +memblock_remove_region(&memblock.memory, i);
>> +}
>>
Re: [PATCH] crypto: testmgr - allocate buffers with __GFP_COMP
On Thu, Apr 11, 2019 at 01:32:32PM -0700, Kees Cook wrote:
> > @@ -156,7 +156,8 @@ static int __testmgr_alloc_buf(char *buf[XBUFSIZE], int
> > order)
> > int i;
> >
> > for (i = 0; i < XBUFSIZE; i++) {
> > - buf[i] = (char *)__get_free_pages(GFP_KERNEL, order);
> > + buf[i] = (char *)__get_free_pages(GFP_KERNEL | __GFP_COMP,
> > + order);
>
> Is there a reason __GFP_COMP isn't automatically included in all page
> allocations? (Or rather, it seems like the exception is when things
> should NOT be considered part of the same allocation, so something
> like __GFP_SINGLE should exist?.)
The question is not whether or not things should be considered part of the
same allocation. The question is whether the allocation is of a compound
page or of N consecutive pages. Now you're asking what the difference is,
and it's whether you need to be able to be able to call compound_head(),
compound_order(), PageTail() or use a compound_dtor. If you don't, then
you can save some time at allocation & free by not specifying __GFP_COMP.
I'll agree this is not documented well, and maybe most multi-page
allocations do want __GFP_COMP and we should invert that bit, but
__GFP_SINGLE doesn't seem like the right antonym to __GFP_COMP to me.
linux-next: manual merge of the wireless-drivers-next tree with the wireless-drivers tree
Hi all,
Today's linux-next merge of the wireless-drivers-next tree got a
conflict in:
drivers/net/wireless/intel/iwlwifi/pcie/drv.c
between commits:
0d5bad14226a ("iwlwifi: rename structs to fit the new names")
972d8e137779 ("iwlwifi: add new 0x2723/0x2080 card for 22000")
from the wireless-drivers tree and commit:
ef8a913766cd ("iwlwifi: remove misconfigured pci ids from 22260 series")
from the wireless-drivers-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/wireless/intel/iwlwifi/pcie/drv.c
index 9f1af8da9dc1,0329b626ada6..
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@@ -953,19 -953,15 +953,15 @@@ static const struct pci_device_id iwl_h
{IWL_PCI_DEVICE(0xA0F0, 0x1652, killer1650i_2ax_cfg_qu_b0_hr_b0)},
{IWL_PCI_DEVICE(0xA0F0, 0x4070, iwl_ax101_cfg_qu_hr)},
- {IWL_PCI_DEVICE(0x2723, 0x0080, iwl22260_2ax_cfg)},
- {IWL_PCI_DEVICE(0x2723, 0x0084, iwl22260_2ax_cfg)},
- {IWL_PCI_DEVICE(0x2723, 0x0088, iwl22260_2ax_cfg)},
- {IWL_PCI_DEVICE(0x2723, 0x008C, iwl22260_2ax_cfg)},
+ {IWL_PCI_DEVICE(0x2723, 0x0080, iwl_ax200_cfg_cc)},
+ {IWL_PCI_DEVICE(0x2723, 0x0084, iwl_ax200_cfg_cc)},
+ {IWL_PCI_DEVICE(0x2723, 0x0088, iwl_ax200_cfg_cc)},
+ {IWL_PCI_DEVICE(0x2723, 0x008C, iwl_ax200_cfg_cc)},
{IWL_PCI_DEVICE(0x2723, 0x1653, killer1650w_2ax_cfg)},
{IWL_PCI_DEVICE(0x2723, 0x1654, killer1650x_2ax_cfg)},
- {IWL_PCI_DEVICE(0x2723, 0x2080, iwl22260_2ax_cfg)},
- {IWL_PCI_DEVICE(0x2723, 0x4080, iwl22260_2ax_cfg)},
- {IWL_PCI_DEVICE(0x2723, 0x4088, iwl22260_2ax_cfg)},
+ {IWL_PCI_DEVICE(0x2723, 0x2080, iwl_ax200_cfg_cc)},
+ {IWL_PCI_DEVICE(0x2723, 0x4080, iwl_ax200_cfg_cc)},
+ {IWL_PCI_DEVICE(0x2723, 0x4088, iwl_ax200_cfg_cc)},
-
- {IWL_PCI_DEVICE(0x1a56, 0x1653, killer1650w_2ax_cfg)},
- {IWL_PCI_DEVICE(0x1a56, 0x1654, killer1650x_2ax_cfg)},
-
{IWL_PCI_DEVICE(0x2725, 0x0090, iwlax210_2ax_cfg_so_hr_a0)},
{IWL_PCI_DEVICE(0x7A70, 0x0090, iwlax210_2ax_cfg_so_hr_a0)},
{IWL_PCI_DEVICE(0x7A70, 0x0310, iwlax210_2ax_cfg_so_hr_a0)},
pgpxsMIYwSS6A.pgp
Description: OpenPGP digital signature
Re: [PATCH v3 3/4] arm64: kdump: support more than one crash kernel regions
Hi Mike,
On 2019/4/14 20:10, Mike Rapoport wrote:
> Hi,
>
> On Thu, Apr 11, 2019 at 08:17:43PM +0800, Chen Zhou wrote:
>> Hi Mike,
>>
>> This overall looks well.
>> Replacing memblock_cap_memory_range() with memblock_cap_memory_ranges() was
>> what i wanted
>> to do in v1, sorry for don't express that clearly.
>
> I didn't object to memblock_cap_memory_ranges() in general, I was worried
> about it's complexity and I hoped that we could find a simpler solution.
>
>> But there are some issues as below. After fixing this, it can work correctly.
>>
>> On 2019/4/10 21:09, Mike Rapoport wrote:
>>> Hi,
>>>
>>> On Tue, Apr 09, 2019 at 06:28:18PM +0800, Chen Zhou wrote:
After commit (arm64: kdump: support reserving crashkernel above 4G),
there may be two crash kernel regions, one is below 4G, the other is
above 4G.
Crash dump kernel reads more than one crash kernel regions via a dtb
property under node /chosen,
linux,usable-memory-range =
Signed-off-by: Chen Zhou
---
arch/arm64/mm/init.c | 66
include/linux/memblock.h | 6 +
mm/memblock.c| 7 ++---
3 files changed, 66 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 3bebddf..0f18665 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -65,6 +65,11 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
#ifdef CONFIG_KEXEC_CORE
+/* at most two crash kernel regions, low_region and high_region */
+#define CRASH_MAX_USABLE_RANGES 2
+#define LOW_REGION_IDX0
+#define HIGH_REGION_IDX 1
+
/*
* reserve_crashkernel() - reserves memory for crash kernel
*
@@ -297,8 +302,8 @@ static int __init
early_init_dt_scan_usablemem(unsigned long node,
const char *uname, int depth, void *data)
{
struct memblock_region *usablemem = data;
- const __be32 *reg;
- int len;
+ const __be32 *reg, *endp;
+ int len, nr = 0;
if (depth != 1 || strcmp(uname, "chosen") != 0)
return 0;
@@ -307,22 +312,63 @@ static int __init
early_init_dt_scan_usablemem(unsigned long node,
if (!reg || (len < (dt_root_addr_cells + dt_root_size_cells)))
return 1;
- usablemem->base = dt_mem_next_cell(dt_root_addr_cells, ®);
- usablemem->size = dt_mem_next_cell(dt_root_size_cells, ®);
+ endp = reg + (len / sizeof(__be32));
+ while ((endp - reg) >= (dt_root_addr_cells + dt_root_size_cells)) {
+ usablemem[nr].base = dt_mem_next_cell(dt_root_addr_cells, ®);
+ usablemem[nr].size = dt_mem_next_cell(dt_root_size_cells, ®);
+
+ if (++nr >= CRASH_MAX_USABLE_RANGES)
+ break;
+ }
return 1;
}
static void __init fdt_enforce_memory_region(void)
{
- struct memblock_region reg = {
- .size = 0,
- };
+ int i, cnt = 0;
+ struct memblock_region regs[CRASH_MAX_USABLE_RANGES];
>>>
>>> I only now noticed that fdt_enforce_memory_region() uses memblock_region to
>>> pass the ranges around. If we'd switch to memblock_type instead, the
>>> implementation of memblock_cap_memory_ranges() would be really
>>> straightforward. Can you check if the below patch works for you?
>>>
>>> >From e476d584098e31273af573e1a78e308880c5cf28 Mon Sep 17 00:00:00 2001
>>> From: Mike Rapoport
>>> Date: Wed, 10 Apr 2019 16:02:32 +0300
>>> Subject: [PATCH] memblock: extend memblock_cap_memory_range to multiple
>>> ranges
>>>
>>> The memblock_cap_memory_range() removes all the memory except the range
>>> passed to it. Extend this function to recieve memblock_type with the
>>> regions that should be kept. This allows switching to simple iteration over
>>> memblock arrays with 'for_each_mem_range' to remove the unneeded memory.
>>>
>>> Enable use of this function in arm64 for reservation of multile regions for
>>> the crash kernel.
>>>
>>> Signed-off-by: Mike Rapoport
>>> ---
>>> arch/arm64/mm/init.c | 34 --
>>> include/linux/memblock.h | 2 +-
>>> mm/memblock.c| 45 ++---
>>> 3 files changed, 47 insertions(+), 34 deletions(-)
>>>
>>>
>>> -void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
>>> +void __init memblock_cap_memory_ranges(struct memblock_type
>>> *regions_to_keep)
>>> {
>>> - int start_rgn, end_rgn;
>>> - int i, ret;
>>> -
>>> - if (!size)
>>> - return;
>>> -
>>> - ret = memblock_isolate_range(&memblock.memory, base, size,
>>> - &start_rgn, &end_rgn);
>>> - if (ret)
>>> - return;
>>> -
>>> - /* remove all the MAP regions */
>>
[RFC PATCH v4 4/4] x86/acrn: Add hypercall for ACRN guest
When ACRN hypervisor is detected, the hypercall is needed so that the
ACRN guest can query/config some settings. For example: it can be used
to query the resources in hypervisor and manage the CPU/memory/device/
interrupt for guest operating system.
Add the hypercall so that the kernel can communicate with the low-level
ACRN hypervisor. It is implemented with vmacll instruction.
Co-developed-by: Jason Chen CJ
Signed-off-by: Jason Chen CJ
Signed-off-by: Zhao Yakui
---
V1->V2: Refine the comments for the function of acrn_hypercall0/1/2
v2->v3: Use the "vmcall" mnemonic to replace hard-code byte definition
v3->v4: refine the commit log(minor change)
---
arch/x86/include/asm/acrn_hypercall.h | 81 +++
1 file changed, 81 insertions(+)
create mode 100644 arch/x86/include/asm/acrn_hypercall.h
diff --git a/arch/x86/include/asm/acrn_hypercall.h
b/arch/x86/include/asm/acrn_hypercall.h
new file mode 100644
index 000..30e256e
--- /dev/null
+++ b/arch/x86/include/asm/acrn_hypercall.h
@@ -0,0 +1,81 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _ASM_X86_ACRNHYPERCALL_H
+#define _ASM_X86_ACRNHYPERCALL_H
+
+#include
+
+#ifdef CONFIG_ACRN_GUEST
+
+/*
+ * Hypercalls for ACRN Guest
+ *
+ * Hypercall number is passed in r8 register.
+ * Return value will be placed in rax.
+ * Up to 2 arguments are passed in rdi, rsi.
+ */
+
+static inline long acrn_hypercall0(unsigned long hcall_id)
+{
+ register unsigned long r8 asm("r8") = hcall_id;
+ register long result asm("rax");
+
+ /* the hypercall is implemented with vmcall instruction.
+* asm volatile is used to avoid that it is dropped because of
+* compiler optimization.
+*/
+ asm volatile("vmcall"
+ : "=r"(result)
+ : "r"(r8));
+
+ return result;
+}
+
+static inline long acrn_hypercall1(unsigned long hcall_id,
+ unsigned long param1)
+{
+ register unsigned long r8 asm("r8") = hcall_id;
+ register long result asm("rax");
+
+ asm volatile("vmcall"
+ : "=r"(result)
+ : "D"(param1), "r"(r8));
+
+ return result;
+}
+
+static inline long acrn_hypercall2(unsigned long hcall_id,
+ unsigned long param1,
+ unsigned long param2)
+{
+ register unsigned long r8 asm("r8") = hcall_id;
+ register long result asm("rax");
+
+ asm volatile("vmcall"
+ : "=r"(result)
+ : "D"(param1), "S"(param2), "r"(r8));
+
+ return result;
+}
+
+#else
+
+static inline long acrn_hypercall0(unsigned long hcall_id)
+{
+ return -ENOTSUPP;
+}
+
+static inline long acrn_hypercall1(unsigned long hcall_id,
+ unsigned long param1)
+{
+ return -ENOTSUPP;
+}
+
+static inline long acrn_hypercall2(unsigned long hcall_id,
+ unsigned long param1,
+ unsigned long param2)
+{
+ return -ENOTSUPP;
+}
+#endif /* CONFIG_ACRN_GUEST */
+#endif /* _ASM_X86_ACRNHYPERCALL_H */
--
2.7.4
[RFC PATCH v4 3/4] x86/acrn: Use HYPERVISOR_CALLBACK_VECTOR for ACRN guest upcall vector
Linux kernel uses the HYPERVISOR_CALLBACK_VECTOR for hypervisor upcall
vector. And it is already used for Xen and HyperV.
After ACRN hypervisor is detected, it will also use this defined vector
to notify kernel.
Co-developed-by: Jason Chen CJ
Signed-off-by: Jason Chen CJ
Signed-off-by: Zhao Yakui
---
V1->V2: Remove the unused API definition of acrn_setup_intr_handler and
acrn_remove_intr_handler.
Adjust the order of header file
Add the declaration of acrn_hv_vector_handler and tracing
definition of acrn_hv_callback_vector.
v2->v3: Select the X86_HV_CALLBACK_VECTOR for ACRN guest
v3->v4: Refine the file name of acrnhyper.h to acrn.h
---
arch/x86/Kconfig| 1 +
arch/x86/entry/entry_64.S | 5 +
arch/x86/include/asm/acrn.h | 11 +++
arch/x86/kernel/cpu/acrn.c | 22 ++
4 files changed, 39 insertions(+)
create mode 100644 arch/x86/include/asm/acrn.h
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b33bfe5..4bad72c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -848,6 +848,7 @@ config JAILHOUSE_GUEST
config ACRN_GUEST
bool "ACRN Guest support"
depends on X86_64
+ select X86_HV_CALLBACK_VECTOR
help
This option allows to run Linux as guest in ACRN hypervisor. Enabling
this will allow the kernel to boot in virtualized environment under
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 1f0efdb..d1b8ad3 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1129,6 +1129,11 @@ apicinterrupt3 HYPERV_STIMER0_VECTOR \
hv_stimer0_callback_vector hv_stimer0_vector_handler
#endif /* CONFIG_HYPERV */
+#if IS_ENABLED(CONFIG_ACRN_GUEST)
+apicinterrupt3 HYPERVISOR_CALLBACK_VECTOR \
+ acrn_hv_callback_vector acrn_hv_vector_handler
+#endif
+
idtentry debug do_debughas_error_code=0
paranoid=1 shift_ist=DEBUG_STACK
idtentry int3 do_int3 has_error_code=0
idtentry stack_segment do_stack_segmenthas_error_code=1
diff --git a/arch/x86/include/asm/acrn.h b/arch/x86/include/asm/acrn.h
new file mode 100644
index 000..43ab032
--- /dev/null
+++ b/arch/x86/include/asm/acrn.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_X86_ACRN_H
+#define _ASM_X86_ACRN_H
+
+void acrn_hv_callback_vector(void);
+#ifdef CONFIG_TRACING
+#define trace_acrn_hv_callback_vector acrn_hv_callback_vector
+#endif
+
+void acrn_hv_vector_handler(struct pt_regs *regs);
+#endif /* _ASM_X86_ACRN_H */
diff --git a/arch/x86/kernel/cpu/acrn.c b/arch/x86/kernel/cpu/acrn.c
index f556640..d8072bf 100644
--- a/arch/x86/kernel/cpu/acrn.c
+++ b/arch/x86/kernel/cpu/acrn.c
@@ -9,7 +9,11 @@
*
*/
+#include
+#include
+#include
#include
+#include
static uint32_t __init acrn_detect(void)
{
@@ -18,6 +22,8 @@ static uint32_t __init acrn_detect(void)
static void __init acrn_init_platform(void)
{
+ alloc_intr_gate(HYPERVISOR_CALLBACK_VECTOR,
+ acrn_hv_callback_vector);
}
static bool acrn_x2apic_available(void)
@@ -30,6 +36,22 @@ static bool acrn_x2apic_available(void)
return false;
}
+static void (*acrn_intr_handler)(void);
+
+__visible void __irq_entry acrn_hv_vector_handler(struct pt_regs *regs)
+{
+ struct pt_regs *old_regs = set_irq_regs(regs);
+
+ entering_ack_irq();
+ inc_irq_stat(irq_hv_callback_count);
+
+ if (acrn_intr_handler)
+ acrn_intr_handler();
+
+ exiting_irq();
+ set_irq_regs(old_regs);
+}
+
const __initconst struct hypervisor_x86 x86_hyper_acrn = {
.name = "ACRN",
.detect = acrn_detect,
--
2.7.4
[PATCH v4 2/4] x86: Add the support of Linux guest on ACRN hypervisor
ACRN is an open-source hypervisor maintained by Linux Foundation.
It is built for embedded IOT with small footprint and real-time features.
Add the ACRN guest support so that it allows linux to be booted under
ACRN hypervisor. Following this patch it will setup the upcall
notification vector, enable hypercall and provide the interface that is
used to manage the virtualized CPU/memory/device/interrupt for other
guest OS.
Co-developed-by: Jason Chen CJ
Signed-off-by: Jason Chen CJ
Signed-off-by: Zhao Yakui
---
v1->v2: Change the CONFIG_ACRN to CONFIG_ACRN_GUEST, which makes it easy to
understand.
Remove the export of x86_hyper_acrn.
v2->v3: Remove the unnecessary dependency of PARAVIRT
v3->v4: Refine the commit log and add meaningful description
in Kconfig
---
arch/x86/Kconfig | 12
arch/x86/include/asm/hypervisor.h | 1 +
arch/x86/kernel/cpu/Makefile | 1 +
arch/x86/kernel/cpu/acrn.c| 39 +++
arch/x86/kernel/cpu/hypervisor.c | 4
5 files changed, 57 insertions(+)
create mode 100644 arch/x86/kernel/cpu/acrn.c
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 54d1fbc..b33bfe5 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -845,6 +845,18 @@ config JAILHOUSE_GUEST
cell. You can leave this option disabled if you only want to start
Jailhouse and run Linux afterwards in the root cell.
+config ACRN_GUEST
+ bool "ACRN Guest support"
+ depends on X86_64
+ help
+ This option allows to run Linux as guest in ACRN hypervisor. Enabling
+ this will allow the kernel to boot in virtualized environment under
+ the ACRN hypervisor.
+ ACRN is a flexible, lightweight reference open-source hypervisor,
built
+ with real-time and safety-criticality in mind. It is built for
embedded
+ IOT with small footprint and real-time features. More details can be
+ found in https://projectacrn.org/
+
endif #HYPERVISOR_GUEST
source "arch/x86/Kconfig.cpu"
diff --git a/arch/x86/include/asm/hypervisor.h
b/arch/x86/include/asm/hypervisor.h
index 8c5aaba..50a30f6 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -29,6 +29,7 @@ enum x86_hypervisor_type {
X86_HYPER_XEN_HVM,
X86_HYPER_KVM,
X86_HYPER_JAILHOUSE,
+ X86_HYPER_ACRN,
};
#ifdef CONFIG_HYPERVISOR_GUEST
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index cfd24f9..17a7cdf 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_X86_CPU_RESCTRL) += resctrl/
obj-$(CONFIG_X86_LOCAL_APIC) += perfctr-watchdog.o
obj-$(CONFIG_HYPERVISOR_GUEST) += vmware.o hypervisor.o mshyperv.o
+obj-$(CONFIG_ACRN_GUEST) += acrn.o
ifdef CONFIG_X86_FEATURE_NAMES
quiet_cmd_mkcapflags = MKCAP $@
diff --git a/arch/x86/kernel/cpu/acrn.c b/arch/x86/kernel/cpu/acrn.c
new file mode 100644
index 000..f556640
--- /dev/null
+++ b/arch/x86/kernel/cpu/acrn.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ACRN detection support
+ *
+ * Copyright (C) 2019 Intel Corporation. All rights reserved.
+ *
+ * Jason Chen CJ
+ * Zhao Yakui
+ *
+ */
+
+#include
+
+static uint32_t __init acrn_detect(void)
+{
+ return hypervisor_cpuid_base("ACRNACRNACRN\0\0", 0);
+}
+
+static void __init acrn_init_platform(void)
+{
+}
+
+static bool acrn_x2apic_available(void)
+{
+ /* x2apic is not supported now.
+* Later it needs to check the X86_FEATURE_X2APIC bit of cpu info
+* returned by CPUID to determine whether the x2apic is
+* supported in Linux guest.
+*/
+ return false;
+}
+
+const __initconst struct hypervisor_x86 x86_hyper_acrn = {
+ .name = "ACRN",
+ .detect = acrn_detect,
+ .type = X86_HYPER_ACRN,
+ .init.init_platform = acrn_init_platform,
+ .init.x2apic_available = acrn_x2apic_available,
+};
diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
index 479ca47..87e39ad 100644
--- a/arch/x86/kernel/cpu/hypervisor.c
+++ b/arch/x86/kernel/cpu/hypervisor.c
@@ -32,6 +32,7 @@ extern const struct hypervisor_x86 x86_hyper_xen_pv;
extern const struct hypervisor_x86 x86_hyper_xen_hvm;
extern const struct hypervisor_x86 x86_hyper_kvm;
extern const struct hypervisor_x86 x86_hyper_jailhouse;
+extern const struct hypervisor_x86 x86_hyper_acrn;
static const __initconst struct hypervisor_x86 * const hypervisors[] =
{
@@ -49,6 +50,9 @@ static const __initconst struct hypervisor_x86 * const
hypervisors[] =
#ifdef CONFIG_JAILHOUSE_GUEST
&x86_hyper_jailhouse,
#endif
+#ifdef CONFIG_ACRN_GUEST
+ &x86_hyper_acrn,
+#endif
};
enum x86_hypervisor_type x86_hyper_type;
--
2.7.4
[RFC PATCH v4 0/4] x86: Add the support of ACRN guest under arch/x86
ACRN is a flexible, lightweight reference hypervisor, built with real-time and safety-criticality in mind, optimized to streamline embedded development through an open source platform. It is built for embedded IOT with small footprint and real-time features. More details can be found in https://projectacrn.org/ This is the patch set that allows the Linux to work on ACRN hypervisor and it can work with the following patch set to manage the Linux guest on acrn-hypervisor. It includes the detection of acrn_hypervisor, upcall notification vector from hypervisor, hypercall. The hypervisor detection is similar to Xen/VMWARE/Hyperv. ACRN also uses the upcall notification mechanism similar to that in Xen/Microsoft HyperV when it needs to send the notification to Linux OS. The hypercall provides the mechanism that can be used to query/configure the acrn-hypervisor by Linux guest. Following this patch set, we will send acrn driver part, which provides the interface that can be used to manage the virtualized CPU/memory/device/interrupt for other guest OS after the acrn hypervisor is detected. v1->v2: Change the CONFIG_ACRN to CONFIG_ACRN_GUEST, which makes it easy to understand. Remove the export of x86_hyper_acrn. Remove the unused API definition of acrn_setup_intr_handler and acrn_remove_intr_handler. Adjust the order of header file Add the declaration of acrn_hv_vector_handler and tracing definition of acrn_hv_callback_vector. Refine the comments for the function of acrn_hypercall0/1/2 v2-v3: Add one new config symbol to unify the conditional definition of hv_irq_callback_count Use the "vmcall" mnemonic to replace the hard-code byte definition Remove the unnecessary dependency of CONFIG_PARAVIRT for ACRN_GUEST v3-v4: Rename the file name of acrnhyper.h to acrn.h Refine the commit log and some other minor changes(more comments and redundant ifdef in acrn.h, sorting the header file in acrn.c) Zhao Yakui (4): x86/Kconfig: Add new config symbol to unify conditional definition of hv_irq_callback_count x86: Add the support of Linux guest on ACRN hypervisor x86/acrn: Use HYPERVISOR_CALLBACK_VECTOR for ACRN guest upcall vector x86/acrn: Add hypercall for ACRN guest arch/x86/Kconfig | 16 +++ arch/x86/entry/entry_64.S | 5 +++ arch/x86/include/asm/acrn.h | 11 + arch/x86/include/asm/acrn_hypercall.h | 81 +++ arch/x86/include/asm/hardirq.h| 2 +- arch/x86/include/asm/hypervisor.h | 1 + arch/x86/kernel/cpu/Makefile | 1 + arch/x86/kernel/cpu/acrn.c| 61 ++ arch/x86/kernel/cpu/hypervisor.c | 4 ++ arch/x86/kernel/irq.c | 2 +- arch/x86/xen/Kconfig | 1 + drivers/hv/Kconfig| 1 + 12 files changed, 184 insertions(+), 2 deletions(-) create mode 100644 arch/x86/include/asm/acrn.h create mode 100644 arch/x86/include/asm/acrn_hypercall.h create mode 100644 arch/x86/kernel/cpu/acrn.c -- 2.7.4
[RFC PATCH v4 1/4] x86/Kconfig: Add new config symbol to unify conditional definition of hv_irq_callback_count
Add a special Kconfig symbol X86_HV_CALLBACK_VECTOR so that the guests
using the hypervisor interrupt callback counter can select and thus
enable that counter. Select it when xen or hyperv support is enabled.
No functional changes.
Signed-off-by: Zhao Yakui
Reviewed-by: Borislav Petkov
---
v3->v4: Follow the comments to refine the commit log.
---
arch/x86/Kconfig | 3 +++
arch/x86/include/asm/hardirq.h | 2 +-
arch/x86/kernel/irq.c | 2 +-
arch/x86/xen/Kconfig | 1 +
drivers/hv/Kconfig | 1 +
5 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 5ad9241..54d1fbc 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -791,6 +791,9 @@ config QUEUED_LOCK_STAT
behavior of paravirtualized queued spinlocks and report
them on debugfs.
+config X86_HV_CALLBACK_VECTOR
+ def_bool n
+
source "arch/x86/xen/Kconfig"
config KVM_GUEST
diff --git a/arch/x86/include/asm/hardirq.h b/arch/x86/include/asm/hardirq.h
index d9069bb..0753379 100644
--- a/arch/x86/include/asm/hardirq.h
+++ b/arch/x86/include/asm/hardirq.h
@@ -37,7 +37,7 @@ typedef struct {
#ifdef CONFIG_X86_MCE_AMD
unsigned int irq_deferred_error_count;
#endif
-#if IS_ENABLED(CONFIG_HYPERV) || defined(CONFIG_XEN)
+#ifdef CONFIG_X86_HV_CALLBACK_VECTOR
unsigned int irq_hv_callback_count;
#endif
#if IS_ENABLED(CONFIG_HYPERV)
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 59b5f2e..a147826 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -134,7 +134,7 @@ int arch_show_interrupts(struct seq_file *p, int prec)
seq_printf(p, "%10u ", per_cpu(mce_poll_count, j));
seq_puts(p, " Machine check polls\n");
#endif
-#if IS_ENABLED(CONFIG_HYPERV) || defined(CONFIG_XEN)
+#ifdef CONFIG_X86_HV_CALLBACK_VECTOR
if (test_bit(HYPERVISOR_CALLBACK_VECTOR, system_vectors)) {
seq_printf(p, "%*s: ", prec, "HYP");
for_each_online_cpu(j)
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index e07abef..ba5a418 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -7,6 +7,7 @@ config XEN
bool "Xen guest support"
depends on PARAVIRT
select PARAVIRT_CLOCK
+ select X86_HV_CALLBACK_VECTOR
depends on X86_64 || (X86_32 && X86_PAE)
depends on X86_LOCAL_APIC && X86_TSC
help
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 1c1a251..cafcb97 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -6,6 +6,7 @@ config HYPERV
tristate "Microsoft Hyper-V client drivers"
depends on X86 && ACPI && X86_LOCAL_APIC && HYPERVISOR_GUEST
select PARAVIRT
+ select X86_HV_CALLBACK_VECTOR
help
Select this option to run Linux as a Hyper-V client operating
system.
--
2.7.4
linux-next: manual merge of the wireless-drivers-next tree with the wireless-drivers tree
Hi all,
Today's linux-next merge of the wireless-drivers-next tree got a conflict
in:
drivers/net/wireless/intel/iwlwifi/iwl-trans.h
between commit:
07d35b4270ef ("iwlwifi: use sync nmi in case of init flow failure")
from the wireless-drivers tree and commit:
4b1831e48974 ("iwlwifi: dbg_ini: support HW error trigger")
from the wireless-drivers-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/wireless/intel/iwlwifi/iwl-trans.h
index d8690acee40c,2235978adf70..
--- a/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-trans.h
@@@ -830,6 -831,8 +830,7 @@@ struct iwl_trans
u32 lmac_error_event_table[2];
u32 umac_error_event_table;
unsigned int error_event_table_tlv_status;
- wait_queue_head_t fw_halt_waitq;
+ bool hw_error;
/* pointer to trans specific struct */
/*Ensure that this pointer will always be aligned to sizeof pointer */
pgpOqaMQ_PJcU.pgp
Description: OpenPGP digital signature
RE: [PATCH] MAINTAINERS: normalize Woojung Huh's email address
> MAINTAINERS contains a lower-case and upper-case variant of > Woojung Huh' s email address. > > Only keep the lower-case variant in MAINTAINERS. > > Signed-off-by: Lukas Bulwahn Acked-by: Woojung Huh
[PATCH v2 1/4] power: supply: max17040: Add IRQ handler for low SOC alert
According datasheet max17040 has a pin for alert host for low SOC.
This pin can be used as external interrupt, so we need to check for
interrupts assigned for device and handle it.
In hadler we are checking and storing fuel gauge registers values
and send an uevent to notificate user space, so user space can decide
save work or turn off since the alert demonstrate that the battery may
no have the power to keep the system turned on for much longer.
Signed-off-by: Matheus Castello
---
drivers/power/supply/max17040_battery.c | 69 +++--
1 file changed, 64 insertions(+), 5 deletions(-)
diff --git a/drivers/power/supply/max17040_battery.c
b/drivers/power/supply/max17040_battery.c
index 91cafc7bed30..8d2f8ed3f44c 100644
--- a/drivers/power/supply/max17040_battery.c
+++ b/drivers/power/supply/max17040_battery.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -160,21 +161,40 @@ static void max17040_get_status(struct i2c_client *client)
chip->status = POWER_SUPPLY_STATUS_FULL;
}
+static void max17040_check_changes(struct i2c_client *client)
+{
+ max17040_get_vcell(client);
+ max17040_get_soc(client);
+ max17040_get_online(client);
+ max17040_get_status(client);
+}
+
static void max17040_work(struct work_struct *work)
{
struct max17040_chip *chip;
chip = container_of(work, struct max17040_chip, work.work);
-
- max17040_get_vcell(chip->client);
- max17040_get_soc(chip->client);
- max17040_get_online(chip->client);
- max17040_get_status(chip->client);
+ max17040_check_changes(chip->client);
queue_delayed_work(system_power_efficient_wq, &chip->work,
MAX17040_DELAY);
}
+static irqreturn_t max17040_thread_handler(int id, void *dev)
+{
+ struct max17040_chip *chip = dev;
+ struct i2c_client *client = chip->client;
+
+ dev_warn(&client->dev, "IRQ: Alert battery low level");
+ /* read registers */
+ max17040_check_changes(chip->client);
+
+ /* send uevent */
+ power_supply_changed(chip->battery);
+
+ return IRQ_HANDLED;
+}
+
static enum power_supply_property max17040_battery_props[] = {
POWER_SUPPLY_PROP_STATUS,
POWER_SUPPLY_PROP_ONLINE,
@@ -217,6 +237,27 @@ static int max17040_probe(struct i2c_client *client,
return PTR_ERR(chip->battery);
}
+ /* check interrupt */
+ if (client->irq) {
+ int ret;
+ unsigned int flags;
+
+ dev_info(&client->dev, "IRQ: enabled\n");
+ flags = IRQF_TRIGGER_FALLING | IRQF_ONESHOT;
+
+ ret = devm_request_threaded_irq(&client->dev, client->irq, NULL,
+ max17040_thread_handler, flags,
+ chip->battery->desc->name,
+ chip);
+
+ if (ret) {
+ client->irq = 0;
+ if (ret != -EBUSY)
+ dev_warn(&client->dev,
+ "Failed to get IRQ err %d\n", ret);
+ }
+ }
+
max17040_reset(client);
max17040_get_version(client);
@@ -224,6 +265,8 @@ static int max17040_probe(struct i2c_client *client,
queue_delayed_work(system_power_efficient_wq, &chip->work,
MAX17040_DELAY);
+ device_init_wakeup(&client->dev, 1);
+
return 0;
}
@@ -244,6 +287,14 @@ static int max17040_suspend(struct device *dev)
struct max17040_chip *chip = i2c_get_clientdata(client);
cancel_delayed_work(&chip->work);
+
+ if (client->irq) {
+ if (device_may_wakeup(dev))
+ enable_irq_wake(client->irq);
+ else
+ disable_irq_wake(client->irq);
+ }
+
return 0;
}
@@ -254,6 +305,14 @@ static int max17040_resume(struct device *dev)
queue_delayed_work(system_power_efficient_wq, &chip->work,
MAX17040_DELAY);
+
+ if (client->irq) {
+ if (device_may_wakeup(dev))
+ disable_irq_wake(client->irq);
+ else
+ enable_irq_wake(client->irq);
+ }
+
return 0;
}
--
2.17.0
[PATCH v2 2/4] dt-bindings: power: supply: Max17040: Add low level SOC alert threshold
For configure low level state of charge threshold alert signaled from
max17040 we add "maxim,alert-soc-level" property.
Signed-off-by: Matheus Castello
---
.../power/supply/max17040_battery.txt | 24 +++
1 file changed, 24 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power/supply/max17040_battery.txt
diff --git
a/Documentation/devicetree/bindings/power/supply/max17040_battery.txt
b/Documentation/devicetree/bindings/power/supply/max17040_battery.txt
new file mode 100644
index ..9b2cc67d556f
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/max17040_battery.txt
@@ -0,0 +1,24 @@
+max17040_battery
+
+
+Required properties :
+ - compatible : "maxim,max17040" or "maxim,max77836-battery"
+
+Optional properties :
+- maxim,alert-soc-level : The alert threshold that sets the state of
+ charge level where an interrupt is generated.
+ Can be configured from 1 up to 32. If skipped
+ the power up default value of 4 will be used.
+- interrupt-parent : The GPIO bank from the interrupt line.
+- interrupts : Interrupt line see
Documentation/devicetree/
+ bindings/interrupt-controller/interrupts.txt
+
+Example:
+
+ battery-charger@36 {
+ compatible = "maxim,max17040";
+ reg = <0x36>;
+ maxim,alert-soc-level = <10>;
+ interrupt-parent = <&gpio7>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ };
--
2.17.0
[PATCH v2 3/4] power: supply: max17040: Config alert SOC low level threshold from FDT
For configuration of fuel gauge alert for a low level state of charge
interrupt we add a function to config level threshold and a device tree
binding property to set it in flatned device tree node.
Now we can use "maxim,alert-soc-level" property with the values from
1 up to 32 to configure alert interrupt threshold.
Signed-off-by: Matheus Castello
---
drivers/power/supply/max17040_battery.c | 56 ++---
1 file changed, 50 insertions(+), 6 deletions(-)
diff --git a/drivers/power/supply/max17040_battery.c
b/drivers/power/supply/max17040_battery.c
index 8d2f8ed3f44c..f036f272d52f 100644
--- a/drivers/power/supply/max17040_battery.c
+++ b/drivers/power/supply/max17040_battery.c
@@ -29,6 +29,9 @@
#define MAX17040_DELAY 1000
#define MAX17040_BATTERY_FULL 95
+#define MAX17040_ATHD_MASK 0xFFE0
+#define MAX17040_ATHD_DEFAULT_POWER_UP 4
+
struct max17040_chip {
struct i2c_client *client;
struct delayed_work work;
@@ -43,6 +46,8 @@ struct max17040_chip {
int soc;
/* State Of Charge */
int status;
+ /* Alert threshold from 32% to 1% of the State of Charge */
+ u32 alert_threshold;
};
static int max17040_get_property(struct power_supply *psy,
@@ -119,6 +124,27 @@ static void max17040_get_soc(struct i2c_client *client)
chip->soc = (soc >> 8);
}
+static int max17040_set_soc_threshold(struct i2c_client *client, u32 level)
+{
+ int ret;
+ u16 data;
+
+ /* check if level is between 1% and 32% */
+ if (level > 0 && level < 33) {
+ /* alert threshold use LSb 5 bits from RCOMP */
+ level = 32 - level;
+ data = max17040_read_reg(client, MAX17040_RCOMP);
+ data &= MAX17040_ATHD_MASK;
+ data |= level;
+ max17040_write_reg(client, MAX17040_RCOMP, data);
+ ret = 0;
+ } else {
+ ret = -EINVAL;
+ }
+
+ return ret;
+}
+
static void max17040_get_version(struct i2c_client *client)
{
u16 version;
@@ -161,6 +187,16 @@ static void max17040_get_status(struct i2c_client *client)
chip->status = POWER_SUPPLY_STATUS_FULL;
}
+static void max17040_get_of_data(struct max17040_chip *chip)
+{
+ struct device *dev = &chip->client->dev;
+ struct device_node *np = dev->of_node;
+
+ if (of_property_read_u32(np, "maxim,alert-soc-level",
+ &chip->alert_threshold))
+ chip->alert_threshold = MAX17040_ATHD_DEFAULT_POWER_UP;
+}
+
static void max17040_check_changes(struct i2c_client *client)
{
max17040_get_vcell(client);
@@ -226,6 +262,7 @@ static int max17040_probe(struct i2c_client *client,
chip->client = client;
chip->pdata = client->dev.platform_data;
+ max17040_get_of_data(chip);
i2c_set_clientdata(client, chip);
psy_cfg.drv_data = chip;
@@ -237,16 +274,26 @@ static int max17040_probe(struct i2c_client *client,
return PTR_ERR(chip->battery);
}
+ max17040_reset(client);
+ max17040_get_version(client);
+
/* check interrupt */
if (client->irq) {
int ret;
- unsigned int flags;
+
+ ret = max17040_set_soc_threshold(client, chip->alert_threshold);
+ if (ret) {
+ dev_err(&client->dev,
+ "Failed to set SOC alert threshold: err %d\n",
+ ret);
+ return ret;
+ }
dev_info(&client->dev, "IRQ: enabled\n");
- flags = IRQF_TRIGGER_FALLING | IRQF_ONESHOT;
ret = devm_request_threaded_irq(&client->dev, client->irq, NULL,
- max17040_thread_handler, flags,
+ max17040_thread_handler,
+ (client->flags | IRQF_ONESHOT),
chip->battery->desc->name,
chip);
@@ -258,9 +305,6 @@ static int max17040_probe(struct i2c_client *client,
}
}
- max17040_reset(client);
- max17040_get_version(client);
-
INIT_DEFERRABLE_WORK(&chip->work, max17040_work);
queue_delayed_work(system_power_efficient_wq, &chip->work,
MAX17040_DELAY);
--
2.17.0
[PATCH v2 4/4] power: supply: max17040: Send uevent in SOC changes
Notify core through power_supply_changed() in case of changes in state
of charge. This is useful for user-space to efficiently update current
battery level.
Signed-off-by: Matheus Castello
---
drivers/power/supply/max17040_battery.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/power/supply/max17040_battery.c
b/drivers/power/supply/max17040_battery.c
index f036f272d52f..db901ebf495d 100644
--- a/drivers/power/supply/max17040_battery.c
+++ b/drivers/power/supply/max17040_battery.c
@@ -208,10 +208,17 @@ static void max17040_check_changes(struct i2c_client
*client)
static void max17040_work(struct work_struct *work)
{
struct max17040_chip *chip;
+ int last_soc;
chip = container_of(work, struct max17040_chip, work.work);
+ /* store SOC for check change */
+ last_soc = chip->soc;
max17040_check_changes(chip->client);
+ /* check changes and send uevent */
+ if (last_soc != chip->soc)
+ power_supply_changed(chip->battery);
+
queue_delayed_work(system_power_efficient_wq, &chip->work,
MAX17040_DELAY);
}
--
2.17.0
Re: [PATCH] PCI: rockchip: fix bitwise operations on status and ROCKCHIP_PCIE_EP_CMD_STATUS_IS
On 2019/4/12 17:51, Lorenzo Pieralisi wrote:
On Sat, Mar 30, 2019 at 03:09:10PM +, Colin King wrote:
From: Colin Ian King
Currently the bitwise operations on the u16 variable 'status' with
the setting ROCKCHIP_PCIE_EP_CMD_STATUS_IS are incorrect because
ROCKCHIP_PCIE_EP_CMD_STATUS_IS is 1UL<<19 which is wider than the
u16 variable. Fix this by making status a u32. (Not tested).
Fixes: cf590b078391 ("PCI: rockchip: Add EP driver for Rockchip PCIe
controller")
Signed-off-by: Colin Ian King
---
drivers/pci/controller/pcie-rockchip-ep.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Shawn,
I need your ACK on this patch, thanks.
Acked-by: Shawn Lin
Lorenzo
diff --git a/drivers/pci/controller/pcie-rockchip-ep.c
b/drivers/pci/controller/pcie-rockchip-ep.c
index a5d799e2dff2..d743b0a48988 100644
--- a/drivers/pci/controller/pcie-rockchip-ep.c
+++ b/drivers/pci/controller/pcie-rockchip-ep.c
@@ -350,7 +350,7 @@ static void rockchip_pcie_ep_assert_intx(struct
rockchip_pcie_ep *ep, u8 fn,
struct rockchip_pcie *rockchip = &ep->rockchip;
u32 r = ep->max_regions - 1;
u32 offset;
- u16 status;
+ u32 status;
u8 msg_code;
if (unlikely(ep->irq_pci_addr != ROCKCHIP_PCIE_EP_PCI_LEGACY_IRQ_ADDR ||
--
2.20.1
[PATCH v2 0/4] power: supply: MAX17040: Add IRQ for low level and alert SOC changes
This series add IRQ handler for low level SOC alert, define a devicetree binding attribute to configure the alert level threshold and check for changes in SOC for send uevents. Max17040 have a pin for alert host about low level state of charge and this alert can be configured in a threshold from 1% up to 32% of SOC. Tested on Toradex Colibri iMX7D, with a SparkFun Lipo Fuel Gauge module based on MAXIM MAX17043. Thanks Krzysztof Kozlowski for your time reviewing it, and forgive me for the delay in working on it, now I'm back to the patchs. Let me know what you think about the fixes and I'm open to maintainers suggestions. Changes since v1: (Suggested by Krzysztof Kozlowski) - Put common code from max17040_work and max17040_thread_handler in a function - Code style fixes - Define mask and low level threshold alert default - Check return value from max17040_set_soc_threshold - Set low level state of charge threshold before IRQ - CC maintainers from drivers/mfd/max14577 - Use flags from FDT client->flags instead hard coded it - Mention interrupts on DT Documentation - Fix "maxim,max77836-battery" missed from DT Documentation - Fix commit description Matheus Castello (4): power: supply: max17040: Add IRQ handler for low SOC alert dt-bindings: power: supply: Max17040: Add low level SOC alert threshold power: supply: max17040: Config alert SOC low level threshold from FDT power: supply: max17040: Send uevent in SOC changes .../power/supply/max17040_battery.txt | 24 drivers/power/supply/max17040_battery.c | 118 +- 2 files changed, 138 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/power/supply/max17040_battery.txt -- 2.17.0
63c35ea6b8 ("x86/stacktrace: Use common infrastructure"): BUG: kernel hang in early-boot stage, last printk: early console in setup code
Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.core/stacktrace commit 63c35ea6b829a0f98d307a8dec038095681ecd13 Author: Thomas Gleixner AuthorDate: Thu Apr 11 12:52:04 2019 +0200 Commit: Thomas Gleixner CommitDate: Sun Apr 14 22:44:04 2019 +0200 x86/stacktrace: Use common infrastructure Replace the stack_trace_save*() functions with the new arch_stack_walk() interfaces. Signed-off-by: Thomas Gleixner 0245694164 stacktrace: Provide common infrastructure 63c35ea6b8 x86/stacktrace: Use common infrastructure 13adc4ee15 Merge branch 'WIP.locking/core' +-++++ | | 0245694164 | 63c35ea6b8 | 13adc4ee15 | +-++++ | boot_successes | 32 | 0 | 11 | | boot_failures | 1 | 13 || | BUG:kernel_reboot-without-warning_in_test_stage | 1 ||| | BUG:kernel_hang_in_early-boot_stage,last_printk:early_console_in_setup_code | 0 | 13 || +-++++ If you fix the issue, kindly add following tag Reported-by: kernel test robot early console in setup code BUG: kernel hang in early-boot stage, last printk: early console in setup code Linux version 5.1.0-rc4-00302-g63c35ea #39 Command line: root=/dev/ram0 hung_task_panic=1 debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0 drbd.minor_count=8 systemd.log_level=err ignore_loglevel console=tty0 earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw link=/cephfs/kbuild/run-queue/kvm/i386-randconfig-n3-201915/tip:WIP.core:stacktrace:63c35ea6b829a0f98d307a8dec038095681ecd13/.vmlinuz-63c35ea6b829a0f98d307a8dec038095681ecd13-20190415064514-2:yocto-vm-yocto-219 branch=tip/WIP.core/stacktrace BOOT_IMAGE=/pkg/linux/i386-randconfig-n3-201915/gcc-7/63c35ea6b829a0f98d307a8dec038095681ecd13/vmlinuz-5.1.0-rc4-00302-g63c35ea drbd.minor_count=8 rcuperf.shutdown=0 # HH:MM RESULT GOOD BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD git bisect start 63c35ea6b829a0f98d307a8dec038095681ecd13 4443f8e6ac7755cd775c70d08be8042dc2f936cb -- git bisect good 9da0899ac5cf06270762b0b530e7cd49e1a97759 # 08:27 G 10 00 0 latency_top: Simplify stack trace handling git bisect good 6f9fad69e30495d9b3c62cf696b7abf68192a400 # 08:33 G 10 00 0 lockdep: Remove unused trace argument from print_circular_bug() git bisect good c6b01c6ce59d329cd1f749faec3034809792d4c4 # 08:40 G 10 00 0 tracing: Simplify stack trace retrieval git bisect good 150bf3fe05c88b76bea37253b9993dd89e58dc2f # 08:47 G 11 00 0 stacktrace: Remove obsolete functions git bisect good 5468565682413ae5a788b1875bbd7e762c910cf9 # 08:53 G 10 01 1 lib/stackdepot: Remove obsolete functions git bisect good 0245694164748e86f0ca565c2d519db1c968dcb1 # 09:06 G 11 00 0 stacktrace: Provide common infrastructure # first bad commit: [63c35ea6b829a0f98d307a8dec038095681ecd13] x86/stacktrace: Use common infrastructure git bisect good 0245694164748e86f0ca565c2d519db1c968dcb1 # 09:12 G 31 00 1 stacktrace: Provide common infrastructure # extra tests with debug options # extra tests on HEAD of tip/WIP.core/stacktrace git bisect bad 63c35ea6b829a0f98d307a8dec038095681ecd13 # 09:15 B 0 13 30 0 x86/stacktrace: Use common infrastructure # extra tests on tree/branch tip/WIP.core/stacktrace git bisect bad 63c35ea6b829a0f98d307a8dec038095681ecd13 # 09:15 B 0 13 30 0 x86/stacktrace: Use common infrastructure # extra tests with first bad commit reverted git bisect good 0d34fc29df83b253f1289f69a8cea220358f651b # 09:23 G 11 00 0 Revert "x86/stacktrace: Use common infrastructure" # extra tests on tree/branch tip/master git bisect good 13adc4ee15853b456b55c061aa081df482a90fc1 # 09:27 G 10 00 0 Merge branch 'WIP.locking/core' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/lkp Intel Corporation dmesg-yocto-vm-yocto-219:20190415075307:i386-randconfig-n3-201915:5.1.0-rc4-00302-g63c35ea:39.gz Description: applic
[tip:WIP.core/stacktrace 34/47] drivers/gpu/drm/drm_mm.c:136:3: error: implicit declaration of function 'stack_trace_snprintf'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
WIP.core/stacktrace
head: 63c35ea6b829a0f98d307a8dec038095681ecd13
commit: 6476291d5b823a05b9c903a65a5f6e6026a02606 [34/47] drm: Simplify
stacktrace handling
config: i386-randconfig-a1-201915 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 6476291d5b823a05b9c903a65a5f6e6026a02606
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/gpu/drm/drm_mm.c: In function 'show_leaks':
>> drivers/gpu/drm/drm_mm.c:136:3: error: implicit declaration of function
>> 'stack_trace_snprintf' [-Werror=implicit-function-declaration]
stack_trace_snprintf(buf, BUFSZ, entries, nr_entries, 0);
^
cc1: some warnings being treated as errors
vim +/stack_trace_snprintf +136 drivers/gpu/drm/drm_mm.c
116
117 static void show_leaks(struct drm_mm *mm)
118 {
119 struct drm_mm_node *node;
120 unsigned long *entries;
121 unsigned int nr_entries;
122 char *buf;
123
124 buf = kmalloc(BUFSZ, GFP_KERNEL);
125 if (!buf)
126 return;
127
128 list_for_each_entry(node, drm_mm_nodes(mm), node_list) {
129 if (!node->stack) {
130 DRM_ERROR("node [%08llx + %08llx]: unknown
owner\n",
131node->start, node->size);
132 continue;
133 }
134
135 nr_entries = stack_depot_fetch(node->stack, &entries);
> 136 stack_trace_snprintf(buf, BUFSZ, entries, nr_entries,
> 0);
137 DRM_ERROR("node [%08llx + %08llx]: inserted at\n%s",
138node->start, node->size, buf);
139 }
140
141 kfree(buf);
142 }
143
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[tip:WIP.core/stacktrace 24/47] mm/slab.c:1490:11: error: 'trace' undeclared
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
WIP.core/stacktrace
head: 63c35ea6b829a0f98d307a8dec038095681ecd13
commit: c79cc35c00e9f15a9a32a08569036cb8365c8816 [24/47] mm/slab: Simplify
stack trace handling
config: i386-randconfig-a1-201915 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout c79cc35c00e9f15a9a32a08569036cb8365c8816
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
mm/slab.c: In function 'store_stackinfo':
>> mm/slab.c:1490:11: error: 'trace' undeclared (first use in this function)
addr += trace.nr_entries;
^
mm/slab.c:1490:11: note: each undeclared identifier is reported only once
for each function it appears in
vim +/trace +1490 mm/slab.c
^1da177e Linus Torvalds 2005-04-16 1468
^1da177e Linus Torvalds 2005-04-16 1469 #ifdef CONFIG_DEBUG_PAGEALLOC
343e0d7a Pekka Enberg2006-02-01 1470 static void store_stackinfo(struct
kmem_cache *cachep, unsigned long *addr,
^1da177e Linus Torvalds 2005-04-16 1471 unsigned
long caller)
^1da177e Linus Torvalds 2005-04-16 1472 {
b8623975 Thomas Gleixner 2019-04-08 1473 int size = cachep->object_size
/ sizeof(unsigned long);
^1da177e Linus Torvalds 2005-04-16 1474
3dafccf2 Manfred Spraul 2006-02-01 1475 addr = (unsigned long *)&((char
*)addr)[obj_offset(cachep)];
^1da177e Linus Torvalds 2005-04-16 1476
b8623975 Thomas Gleixner 2019-04-08 1477 if (size < 5)
^1da177e Linus Torvalds 2005-04-16 1478 return;
^1da177e Linus Torvalds 2005-04-16 1479
^1da177e Linus Torvalds 2005-04-16 1480 *addr++ = 0x12345678;
^1da177e Linus Torvalds 2005-04-16 1481 *addr++ = caller;
^1da177e Linus Torvalds 2005-04-16 1482 *addr++ = smp_processor_id();
b8623975 Thomas Gleixner 2019-04-08 1483 size -= 3;
b8623975 Thomas Gleixner 2019-04-08 1484 #ifdef CONFIG_STACKTRACE
^1da177e Linus Torvalds 2005-04-16 1485 {
c79cc35c Thomas Gleixner 2019-04-14 1486 unsigned int nr_entries;
^1da177e Linus Torvalds 2005-04-16 1487
c79cc35c Thomas Gleixner 2019-04-14 1488 /* Leave one for the
end marker below */
c79cc35c Thomas Gleixner 2019-04-14 1489 nr_entries =
stack_trace_save(addr, size - 1, 3);
b8623975 Thomas Gleixner 2019-04-08 @1490 addr +=
trace.nr_entries;
^1da177e Linus Torvalds 2005-04-16 1491 }
b8623975 Thomas Gleixner 2019-04-08 1492 #endif
b8623975 Thomas Gleixner 2019-04-08 1493 *addr = 0x87654321;
^1da177e Linus Torvalds 2005-04-16 1494 }
40b44137 Joonsoo Kim 2016-03-15 1495
:: The code at line 1490 was first introduced by commit
:: b86239751f8c4d6fc43f6a9eca29e77b0319f5d7 mm/slab: Fix broken stack trace
storage
:: TO: Thomas Gleixner
:: CC: Thomas Gleixner
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH v4 02/11] PCI: imx6: Drop imx6_pcie_wait_for_link()
All calls to imx6_pcie_wait_for_link() share the same error path and
the state of PHY debug registers will already be printed there, so
there's no real reason we can't just use dw_pcie_wait_for_link(). Drop
imx6_pcie_wait_for_link() and replace it with dw_pcie_wait_for_link().
Signed-off-by: Andrey Smirnov
Suggested-by: Lucas Stach
Cc: Lorenzo Pieralisi
Cc: Bjorn Helgaas
Cc: Chris Healy
Cc: Lucas Stach
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/pci/controller/dwc/pci-imx6.c | 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c
b/drivers/pci/controller/dwc/pci-imx6.c
index ea2617712a3b..bb3dcfdbf697 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -723,21 +723,6 @@ static int imx6_setup_phy_mpll(struct imx6_pcie *imx6_pcie)
return 0;
}
-static int imx6_pcie_wait_for_link(struct imx6_pcie *imx6_pcie)
-{
- struct dw_pcie *pci = imx6_pcie->pci;
- struct device *dev = pci->dev;
-
- /* check if the link is up or not */
- if (!dw_pcie_wait_for_link(pci))
- return 0;
-
- dev_dbg(dev, "DEBUG_R0: 0x%08x, DEBUG_R1: 0x%08x\n",
- dw_pcie_readl_dbi(pci, PCIE_PHY_DEBUG_R0),
- dw_pcie_readl_dbi(pci, PCIE_PHY_DEBUG_R1));
- return -ETIMEDOUT;
-}
-
static int imx6_pcie_wait_for_speed_change(struct imx6_pcie *imx6_pcie)
{
struct dw_pcie *pci = imx6_pcie->pci;
@@ -796,7 +781,7 @@ static int imx6_pcie_establish_link(struct imx6_pcie
*imx6_pcie)
/* Start LTSSM. */
imx6_pcie_ltssm_enable(dev);
- ret = imx6_pcie_wait_for_link(imx6_pcie);
+ ret = dw_pcie_wait_for_link(pci);
if (ret)
goto err_reset_phy;
@@ -834,7 +819,7 @@ static int imx6_pcie_establish_link(struct imx6_pcie
*imx6_pcie)
}
/* Make sure link training is finished as well! */
- ret = imx6_pcie_wait_for_link(imx6_pcie);
+ ret = dw_pcie_wait_for_link(pci);
if (ret) {
dev_err(dev, "Failed to bring link up!\n");
goto err_reset_phy;
--
2.20.1
[PATCH v4 05/11] PCI: dwc: imx6: Share PHY debug register definitions
Both pcie-designware.c and pci-imx6.c contain custom definitions for
PHY debug registers R0/R1 and on top of that there's already a
definition for R0 in pcie-designware.h. Move all of the definitions to
pcie-designware.h. No functional change intended.
Signed-off-by: Andrey Smirnov
Reviewed-by: Lucas Stach
Cc: Lorenzo Pieralisi
Cc: Bjorn Helgaas
Cc: Chris Healy
Cc: Lucas Stach
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/pci/controller/dwc/pci-imx6.c| 6 ++
drivers/pci/controller/dwc/pcie-designware.c | 12 +++-
drivers/pci/controller/dwc/pcie-designware.h | 3 +++
3 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c
b/drivers/pci/controller/dwc/pci-imx6.c
index c0867df090f5..eeacdebd9b50 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -103,8 +103,6 @@ struct imx6_pcie {
/* PCIe Port Logic registers (memory-mapped) */
#define PL_OFFSET 0x700
-#define PCIE_PHY_DEBUG_R0 (PL_OFFSET + 0x28)
-#define PCIE_PHY_DEBUG_R1 (PL_OFFSET + 0x2c)
#define PCIE_PHY_CTRL (PL_OFFSET + 0x114)
#define PCIE_PHY_CTRL_DATA_LOC 0
@@ -831,8 +829,8 @@ static int imx6_pcie_establish_link(struct imx6_pcie
*imx6_pcie)
err_reset_phy:
dev_dbg(dev, "PHY DEBUG_R0=0x%08x DEBUG_R1=0x%08x\n",
- dw_pcie_readl_dbi(pci, PCIE_PHY_DEBUG_R0),
- dw_pcie_readl_dbi(pci, PCIE_PHY_DEBUG_R1));
+ dw_pcie_readl_dbi(pci, PCIE_PORT_DEBUG0),
+ dw_pcie_readl_dbi(pci, PCIE_PORT_DEBUG1));
imx6_pcie_reset_phy(imx6_pcie);
return ret;
}
diff --git a/drivers/pci/controller/dwc/pcie-designware.c
b/drivers/pci/controller/dwc/pcie-designware.c
index 31f6331ca46f..086e87a40316 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -14,12 +14,6 @@
#include "pcie-designware.h"
-/* PCIe Port Logic registers */
-#define PLR_OFFSET 0x700
-#define PCIE_PHY_DEBUG_R1 (PLR_OFFSET + 0x2c)
-#define PCIE_PHY_DEBUG_R1_LINK_UP (0x1 << 4)
-#define PCIE_PHY_DEBUG_R1_LINK_IN_TRAINING (0x1 << 29)
-
int dw_pcie_read(void __iomem *addr, int size, u32 *val)
{
if (!IS_ALIGNED((uintptr_t)addr, size)) {
@@ -334,9 +328,9 @@ int dw_pcie_link_up(struct dw_pcie *pci)
if (pci->ops->link_up)
return pci->ops->link_up(pci);
- val = readl(pci->dbi_base + PCIE_PHY_DEBUG_R1);
- return ((val & PCIE_PHY_DEBUG_R1_LINK_UP) &&
- (!(val & PCIE_PHY_DEBUG_R1_LINK_IN_TRAINING)));
+ val = readl(pci->dbi_base + PCIE_PORT_DEBUG1);
+ return ((val & PCIE_PORT_DEBUG1_LINK_UP) &&
+ (!(val & PCIE_PORT_DEBUG1_LINK_IN_TRAINING)));
}
void dw_pcie_setup(struct dw_pcie *pci)
diff --git a/drivers/pci/controller/dwc/pcie-designware.h
b/drivers/pci/controller/dwc/pcie-designware.h
index 377f4c0b52da..b33ae13194be 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -41,6 +41,9 @@
#define PCIE_PORT_DEBUG0 0x728
#define PORT_LOGIC_LTSSM_STATE_MASK0x1f
#define PORT_LOGIC_LTSSM_STATE_L0 0x11
+#define PCIE_PORT_DEBUG1 0x72C
+#define PCIE_PORT_DEBUG1_LINK_UP BIT(4)
+#define PCIE_PORT_DEBUG1_LINK_IN_TRAINING BIT(29)
#define PCIE_LINK_WIDTH_SPEED_CONTROL 0x80C
#define PORT_LOGIC_SPEED_CHANGEBIT(17)
--
2.20.1
[PATCH v4 03/11] PCI: imx6: Return -ETIMEOUT from imx6_pcie_wait_for_speed_change()
Change error code from EINVAL to ETIMEDOUT in imx6_pcie_wait_for_speed_change() since that error code seems more appropriate. Signed-off-by: Andrey Smirnov Reviewed-by: Lucas Stach Cc: Lorenzo Pieralisi Cc: Bjorn Helgaas Cc: Chris Healy Cc: Lucas Stach Cc: linux-kernel@vger.kernel.org Cc: linux-...@vger.kernel.org --- drivers/pci/controller/dwc/pci-imx6.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c index bb3dcfdbf697..021ef121a058 100644 --- a/drivers/pci/controller/dwc/pci-imx6.c +++ b/drivers/pci/controller/dwc/pci-imx6.c @@ -739,7 +739,7 @@ static int imx6_pcie_wait_for_speed_change(struct imx6_pcie *imx6_pcie) } dev_err(dev, "Speed change timeout\n"); - return -EINVAL; + return -ETIMEDOUT; } static void imx6_pcie_ltssm_enable(struct device *dev) -- 2.20.1
[PATCH v4 08/11] PCI: imx6: Simplify pcie_phy_poll_ack()
Simplify pcie_phy_poll_ack() by incorporating shifting into constant
definition and convert the code to use 'bool'. No functional change
intended.
Signed-off-by: Andrey Smirnov
Cc: Lorenzo Pieralisi
Cc: Bjorn Helgaas
Cc: Chris Healy
Cc: Lucas Stach
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/pci/controller/dwc/pci-imx6.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c
b/drivers/pci/controller/dwc/pci-imx6.c
index 669e01353026..3fd084357488 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -112,7 +112,7 @@ struct imx6_pcie {
#define PCIE_PHY_CTRL_RD BIT(19)
#define PCIE_PHY_STAT (PL_OFFSET + 0x110)
-#define PCIE_PHY_STAT_ACK_LOC 16
+#define PCIE_PHY_STAT_ACK BIT(16)
#define PCIE_LINK_WIDTH_SPEED_CONTROL 0x80C
@@ -151,16 +151,16 @@ struct imx6_pcie {
#define PHY_RX_OVRD_IN_LO_RX_DATA_EN BIT(5)
#define PHY_RX_OVRD_IN_LO_RX_PLL_ENBIT(3)
-static int pcie_phy_poll_ack(struct imx6_pcie *imx6_pcie, int exp_val)
+static int pcie_phy_poll_ack(struct imx6_pcie *imx6_pcie, bool exp_val)
{
struct dw_pcie *pci = imx6_pcie->pci;
- u32 val;
+ bool val;
u32 max_iterations = 10;
u32 wait_counter = 0;
do {
- val = dw_pcie_readl_dbi(pci, PCIE_PHY_STAT);
- val = (val >> PCIE_PHY_STAT_ACK_LOC) & 0x1;
+ val = dw_pcie_readl_dbi(pci, PCIE_PHY_STAT) &
+ PCIE_PHY_STAT_ACK;
wait_counter++;
if (val == exp_val)
@@ -184,14 +184,14 @@ static int pcie_phy_wait_ack(struct imx6_pcie *imx6_pcie,
int addr)
val |= PCIE_PHY_CTRL_CAP_ADR;
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, val);
- ret = pcie_phy_poll_ack(imx6_pcie, 1);
+ ret = pcie_phy_poll_ack(imx6_pcie, true);
if (ret)
return ret;
val = PCIE_PHY_CTRL_DATA(addr);
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, val);
- return pcie_phy_poll_ack(imx6_pcie, 0);
+ return pcie_phy_poll_ack(imx6_pcie, false);
}
/* Read from the 16-bit PCIe PHY control registers (not memory-mapped) */
@@ -209,7 +209,7 @@ static int pcie_phy_read(struct imx6_pcie *imx6_pcie, int
addr, int *data)
phy_ctl = PCIE_PHY_CTRL_RD;
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, phy_ctl);
- ret = pcie_phy_poll_ack(imx6_pcie, 1);
+ ret = pcie_phy_poll_ack(imx6_pcie, true);
if (ret)
return ret;
@@ -219,7 +219,7 @@ static int pcie_phy_read(struct imx6_pcie *imx6_pcie, int
addr, int *data)
/* deassert Read signal */
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, 0x00);
- return pcie_phy_poll_ack(imx6_pcie, 0);
+ return pcie_phy_poll_ack(imx6_pcie, false);
}
static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int addr, int data)
@@ -241,7 +241,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int
addr, int data)
var |= PCIE_PHY_CTRL_CAP_DAT;
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
- ret = pcie_phy_poll_ack(imx6_pcie, 1);
+ ret = pcie_phy_poll_ack(imx6_pcie, true);
if (ret)
return ret;
@@ -250,7 +250,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int
addr, int data)
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
/* wait for ack de-assertion */
- ret = pcie_phy_poll_ack(imx6_pcie, 0);
+ ret = pcie_phy_poll_ack(imx6_pcie, false);
if (ret)
return ret;
@@ -259,7 +259,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int
addr, int data)
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
/* wait for ack */
- ret = pcie_phy_poll_ack(imx6_pcie, 1);
+ ret = pcie_phy_poll_ack(imx6_pcie, true);
if (ret)
return ret;
@@ -268,7 +268,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int
addr, int data)
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
/* wait for ack de-assertion */
- ret = pcie_phy_poll_ack(imx6_pcie, 0);
+ ret = pcie_phy_poll_ack(imx6_pcie, false);
if (ret)
return ret;
--
2.20.1
[PATCH v4 06/11] PCI: imx6: Make use of BIT() in constant definitions
Avoid using explicit left shifts and convert various definitions to
use BIT() instead. No functional change intended.
Signed-off-by: Andrey Smirnov
Reviewed-by: Lucas Stach
Cc: Lorenzo Pieralisi
Cc: Bjorn Helgaas
Cc: Chris Healy
Cc: Lucas Stach
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/pci/controller/dwc/pci-imx6.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c
b/drivers/pci/controller/dwc/pci-imx6.c
index eeacdebd9b50..5650642ab248 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -118,14 +118,14 @@ struct imx6_pcie {
/* PHY registers (not memory-mapped) */
#define PCIE_PHY_ATEOVRD 0x10
-#define PCIE_PHY_ATEOVRD_EN (0x1 << 2)
+#define PCIE_PHY_ATEOVRD_EN BIT(2)
#define PCIE_PHY_ATEOVRD_REF_CLKDIV_SHIFT 0
#define PCIE_PHY_ATEOVRD_REF_CLKDIV_MASK 0x1
#define PCIE_PHY_MPLL_OVRD_IN_LO 0x11
#define PCIE_PHY_MPLL_MULTIPLIER_SHIFT2
#define PCIE_PHY_MPLL_MULTIPLIER_MASK 0x7f
-#define PCIE_PHY_MPLL_MULTIPLIER_OVRD (0x1 << 9)
+#define PCIE_PHY_MPLL_MULTIPLIER_OVRD BIT(9)
#define PCIE_PHY_RX_ASIC_OUT 0x100D
#define PCIE_PHY_RX_ASIC_OUT_VALID (1 << 0)
@@ -148,8 +148,8 @@ struct imx6_pcie {
#define PCIE_PHY_CMN_REG26_ATT_MODE0xBC
#define PHY_RX_OVRD_IN_LO 0x1005
-#define PHY_RX_OVRD_IN_LO_RX_DATA_EN (1 << 5)
-#define PHY_RX_OVRD_IN_LO_RX_PLL_EN (1 << 3)
+#define PHY_RX_OVRD_IN_LO_RX_DATA_EN BIT(5)
+#define PHY_RX_OVRD_IN_LO_RX_PLL_ENBIT(3)
static int pcie_phy_poll_ack(struct imx6_pcie *imx6_pcie, int exp_val)
{
--
2.20.1
[PATCH v4 09/11] PCI: imx6: Restrict PHY register data to 16-bit
PHY registers on i.MX6 are 16-bit wide, so we can get rid of explicit
masking if we restrict pcie_phy_read/pcie_phy_write to use 'u16'
instead of 'int'. No functional change intended.
Signed-off-by: Andrey Smirnov
Reviewed-by: Lucas Stach
Cc: Lorenzo Pieralisi
Cc: Bjorn Helgaas
Cc: Chris Healy
Cc: Lucas Stach
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/pci/controller/dwc/pci-imx6.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c
b/drivers/pci/controller/dwc/pci-imx6.c
index 3fd084357488..30e764b6cbcc 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -195,10 +195,10 @@ static int pcie_phy_wait_ack(struct imx6_pcie *imx6_pcie,
int addr)
}
/* Read from the 16-bit PCIe PHY control registers (not memory-mapped) */
-static int pcie_phy_read(struct imx6_pcie *imx6_pcie, int addr, int *data)
+static int pcie_phy_read(struct imx6_pcie *imx6_pcie, int addr, u16 *data)
{
struct dw_pcie *pci = imx6_pcie->pci;
- u32 val, phy_ctl;
+ u32 phy_ctl;
int ret;
ret = pcie_phy_wait_ack(imx6_pcie, addr);
@@ -213,8 +213,7 @@ static int pcie_phy_read(struct imx6_pcie *imx6_pcie, int
addr, int *data)
if (ret)
return ret;
- val = dw_pcie_readl_dbi(pci, PCIE_PHY_STAT);
- *data = val & 0x;
+ *data = dw_pcie_readl_dbi(pci, PCIE_PHY_STAT);
/* deassert Read signal */
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, 0x00);
@@ -222,7 +221,7 @@ static int pcie_phy_read(struct imx6_pcie *imx6_pcie, int
addr, int *data)
return pcie_phy_poll_ack(imx6_pcie, false);
}
-static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int addr, int data)
+static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int addr, u16 data)
{
struct dw_pcie *pci = imx6_pcie->pci;
u32 var;
@@ -279,7 +278,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int
addr, int data)
static void imx6_pcie_reset_phy(struct imx6_pcie *imx6_pcie)
{
- u32 tmp;
+ u16 tmp;
if (!(imx6_pcie->drvdata->flags & IMX6_PCIE_FLAG_IMX6_PHY))
return;
@@ -675,7 +674,7 @@ static int imx6_setup_phy_mpll(struct imx6_pcie *imx6_pcie)
{
unsigned long phy_rate = clk_get_rate(imx6_pcie->pcie_phy);
int mult, div;
- u32 val;
+ u16 val;
if (!(imx6_pcie->drvdata->flags & IMX6_PCIE_FLAG_IMX6_PHY))
return 0;
--
2.20.1
[PATCH v4 04/11] PCI: imx6: Remove PCIE_PL_PFLR_* constants
Code using these constants was removed in commit a71280722eeb ("PCI:
imx6: Remove LTSSM disable workaround"). No functional change
intended.
Signed-off-by: Andrey Smirnov
Reviewed-by: Lucas Stach
Cc: Lorenzo Pieralisi
Cc: Bjorn Helgaas
Cc: Chris Healy
Cc: Lucas Stach
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/pci/controller/dwc/pci-imx6.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c
b/drivers/pci/controller/dwc/pci-imx6.c
index 021ef121a058..c0867df090f5 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -103,9 +103,6 @@ struct imx6_pcie {
/* PCIe Port Logic registers (memory-mapped) */
#define PL_OFFSET 0x700
-#define PCIE_PL_PFLR (PL_OFFSET + 0x08)
-#define PCIE_PL_PFLR_LINK_STATE_MASK (0x3f << 16)
-#define PCIE_PL_PFLR_FORCE_LINK(1 << 15)
#define PCIE_PHY_DEBUG_R0 (PL_OFFSET + 0x28)
#define PCIE_PHY_DEBUG_R1 (PL_OFFSET + 0x2c)
--
2.20.1
[PATCH v4 01/11] PCI: imx6: Simplify imx7d_pcie_wait_for_phy_pll_lock()
Make use of regmap_read_poll_timeout() to simplify
imx7d_pcie_wait_for_phy_pll_lock(). No functional change intended.
Signed-off-by: Andrey Smirnov
Reviewed-by: Lucas Stach
Cc: Lorenzo Pieralisi
Cc: Bjorn Helgaas
Cc: Chris Healy
Cc: Lucas Stach
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/pci/controller/dwc/pci-imx6.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c
b/drivers/pci/controller/dwc/pci-imx6.c
index 3d627f94a166..ea2617712a3b 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -89,9 +89,8 @@ struct imx6_pcie {
};
/* Parameters for the waiting for PCIe PHY PLL to lock on i.MX7 */
-#define PHY_PLL_LOCK_WAIT_MAX_RETRIES 2000
-#define PHY_PLL_LOCK_WAIT_USLEEP_MIN 50
#define PHY_PLL_LOCK_WAIT_USLEEP_MAX 200
+#define PHY_PLL_LOCK_WAIT_TIMEOUT (2000 * PHY_PLL_LOCK_WAIT_USLEEP_MAX)
/* PCIe Root Complex registers (memory-mapped) */
#define PCIE_RC_IMX6_MSI_CAP 0x50
@@ -488,20 +487,14 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie
*imx6_pcie)
static void imx7d_pcie_wait_for_phy_pll_lock(struct imx6_pcie *imx6_pcie)
{
u32 val;
- unsigned int retries;
struct device *dev = imx6_pcie->pci->dev;
- for (retries = 0; retries < PHY_PLL_LOCK_WAIT_MAX_RETRIES; retries++) {
- regmap_read(imx6_pcie->iomuxc_gpr, IOMUXC_GPR22, &val);
-
- if (val & IMX7D_GPR22_PCIE_PHY_PLL_LOCKED)
- return;
-
- usleep_range(PHY_PLL_LOCK_WAIT_USLEEP_MIN,
-PHY_PLL_LOCK_WAIT_USLEEP_MAX);
- }
-
- dev_err(dev, "PCIe PLL lock timeout\n");
+ if (regmap_read_poll_timeout(imx6_pcie->iomuxc_gpr,
+IOMUXC_GPR22, val,
+val & IMX7D_GPR22_PCIE_PHY_PLL_LOCKED,
+PHY_PLL_LOCK_WAIT_USLEEP_MAX,
+PHY_PLL_LOCK_WAIT_TIMEOUT))
+ dev_err(dev, "PCIe PLL lock timeout\n");
}
static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
--
2.20.1
[PATCH v4 07/11] PCI: imx6: Simplify bit operations in PHY functions
Simplify the code by incorporating left shifts into constant
defnitions as well as using FIELD_PREP/GENMASK. No functional change
intended.
Signed-off-by: Andrey Smirnov
Reviewed-by: Lucas Stach
Cc: Lorenzo Pieralisi
Cc: Bjorn Helgaas
Cc: Chris Healy
Cc: Lucas Stach
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/pci/controller/dwc/pci-imx6.c | 28 +--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c
b/drivers/pci/controller/dwc/pci-imx6.c
index 5650642ab248..669e01353026 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -105,11 +105,11 @@ struct imx6_pcie {
#define PL_OFFSET 0x700
#define PCIE_PHY_CTRL (PL_OFFSET + 0x114)
-#define PCIE_PHY_CTRL_DATA_LOC 0
-#define PCIE_PHY_CTRL_CAP_ADR_LOC 16
-#define PCIE_PHY_CTRL_CAP_DAT_LOC 17
-#define PCIE_PHY_CTRL_WR_LOC 18
-#define PCIE_PHY_CTRL_RD_LOC 19
+#define PCIE_PHY_CTRL_DATA(x) FIELD_PREP(GENMASK(15, 0), (x))
+#define PCIE_PHY_CTRL_CAP_ADR BIT(16)
+#define PCIE_PHY_CTRL_CAP_DAT BIT(17)
+#define PCIE_PHY_CTRL_WR BIT(18)
+#define PCIE_PHY_CTRL_RD BIT(19)
#define PCIE_PHY_STAT (PL_OFFSET + 0x110)
#define PCIE_PHY_STAT_ACK_LOC 16
@@ -178,17 +178,17 @@ static int pcie_phy_wait_ack(struct imx6_pcie *imx6_pcie,
int addr)
u32 val;
int ret;
- val = addr << PCIE_PHY_CTRL_DATA_LOC;
+ val = PCIE_PHY_CTRL_DATA(addr);
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, val);
- val |= (0x1 << PCIE_PHY_CTRL_CAP_ADR_LOC);
+ val |= PCIE_PHY_CTRL_CAP_ADR;
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, val);
ret = pcie_phy_poll_ack(imx6_pcie, 1);
if (ret)
return ret;
- val = addr << PCIE_PHY_CTRL_DATA_LOC;
+ val = PCIE_PHY_CTRL_DATA(addr);
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, val);
return pcie_phy_poll_ack(imx6_pcie, 0);
@@ -206,7 +206,7 @@ static int pcie_phy_read(struct imx6_pcie *imx6_pcie, int
addr, int *data)
return ret;
/* assert Read signal */
- phy_ctl = 0x1 << PCIE_PHY_CTRL_RD_LOC;
+ phy_ctl = PCIE_PHY_CTRL_RD;
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, phy_ctl);
ret = pcie_phy_poll_ack(imx6_pcie, 1);
@@ -234,11 +234,11 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie,
int addr, int data)
if (ret)
return ret;
- var = data << PCIE_PHY_CTRL_DATA_LOC;
+ var = PCIE_PHY_CTRL_DATA(data);
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
/* capture data */
- var |= (0x1 << PCIE_PHY_CTRL_CAP_DAT_LOC);
+ var |= PCIE_PHY_CTRL_CAP_DAT;
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
ret = pcie_phy_poll_ack(imx6_pcie, 1);
@@ -246,7 +246,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int
addr, int data)
return ret;
/* deassert cap data */
- var = data << PCIE_PHY_CTRL_DATA_LOC;
+ var = PCIE_PHY_CTRL_DATA(data);
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
/* wait for ack de-assertion */
@@ -255,7 +255,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int
addr, int data)
return ret;
/* assert wr signal */
- var = 0x1 << PCIE_PHY_CTRL_WR_LOC;
+ var = PCIE_PHY_CTRL_WR;
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
/* wait for ack */
@@ -264,7 +264,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int
addr, int data)
return ret;
/* deassert wr signal */
- var = data << PCIE_PHY_CTRL_DATA_LOC;
+ var = PCIE_PHY_CTRL_DATA(data);
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
/* wait for ack de-assertion */
--
2.20.1
[PATCH v4 11/11] PCI: imx6: Use usleep_range() in imx6_pcie_enable_ref_clk()
imx6_pcie_enable_ref_clk() is never called in atomic context, so there's no need to use udelay(). Replace it with usleep_range(). Signed-off-by: Andrey Smirnov Cc: Lorenzo Pieralisi Cc: Bjorn Helgaas Cc: Chris Healy Cc: Lucas Stach Cc: linux-kernel@vger.kernel.org Cc: linux-...@vger.kernel.org --- drivers/pci/controller/dwc/pci-imx6.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c index 3e45f49b8a4f..c6d6bde4d860 100644 --- a/drivers/pci/controller/dwc/pci-imx6.c +++ b/drivers/pci/controller/dwc/pci-imx6.c @@ -449,7 +449,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie) * reset time is too short, cannot meet the requirement. * add one ~10us delay here. */ - udelay(10); + usleep_range(10, 100); regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1, IMX6Q_GPR1_PCIE_REF_CLK_EN, 1 << 16); break; -- 2.20.1
[PATCH v4 10/11] PCI: imx6: Use flags to indicate support for suspend
Now that driver data has flags variable that can be used to indicate
quirks/features supported we can switch the code to use it instead of
having a special function that does so based on variant alone. No
functional change intended.
Signed-off-by: Andrey Smirnov
Reviewed-by: Lucas Stach
Cc: Lorenzo Pieralisi
Cc: Bjorn Helgaas
Cc: Chris Healy
Cc: Lucas Stach
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
drivers/pci/controller/dwc/pci-imx6.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c
b/drivers/pci/controller/dwc/pci-imx6.c
index 30e764b6cbcc..3e45f49b8a4f 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -52,6 +52,7 @@ enum imx6_pcie_variants {
#define IMX6_PCIE_FLAG_IMX6_PHYBIT(0)
#define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE BIT(1)
+#define IMX6_PCIE_FLAG_SUPPORTS_SUSPENDBIT(2)
struct imx6_pcie_drvdata {
enum imx6_pcie_variants variant;
@@ -965,17 +966,11 @@ static void imx6_pcie_clk_disable(struct imx6_pcie
*imx6_pcie)
}
}
-static inline bool imx6_pcie_supports_suspend(struct imx6_pcie *imx6_pcie)
-{
- return (imx6_pcie->drvdata->variant == IMX7D ||
- imx6_pcie->drvdata->variant == IMX6SX);
-}
-
static int imx6_pcie_suspend_noirq(struct device *dev)
{
struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
- if (!imx6_pcie_supports_suspend(imx6_pcie))
+ if (!(imx6_pcie->drvdata->flags & IMX6_PCIE_FLAG_SUPPORTS_SUSPEND))
return 0;
imx6_pcie_pm_turnoff(imx6_pcie);
@@ -991,7 +986,7 @@ static int imx6_pcie_resume_noirq(struct device *dev)
struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
struct pcie_port *pp = &imx6_pcie->pci->pp;
- if (!imx6_pcie_supports_suspend(imx6_pcie))
+ if (!(imx6_pcie->drvdata->flags & IMX6_PCIE_FLAG_SUPPORTS_SUSPEND))
return 0;
imx6_pcie_assert_core_reset(imx6_pcie);
@@ -1221,7 +1216,8 @@ static const struct imx6_pcie_drvdata drvdata[] = {
[IMX6SX] = {
.variant = IMX6SX,
.flags = IMX6_PCIE_FLAG_IMX6_PHY |
-IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE,
+IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE |
+IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
},
[IMX6QP] = {
.variant = IMX6QP,
@@ -1230,6 +1226,7 @@ static const struct imx6_pcie_drvdata drvdata[] = {
},
[IMX7D] = {
.variant = IMX7D,
+ .flags = IMX6_PCIE_FLAG_SUPPORTS_SUSPEND,
},
[IMX8MQ] = {
.variant = IMX8MQ,
--
2.20.1
[PATCH v4 00/11] i.MX6, DesignWare PCI improvements
Everyone: This is the series containing various small improvements that I made while reading the code and researching commit history of pci-imx6.c and pcie-designware*.c files. All changes are optional, so commits that don't seem like an improvement can be easily dropped. Hopefully each patch is self-explanatory. I tested this series on i.MX6Q, i.MX7D and i.MX8MQ. Feedback is welcome! Thanks, Andrey Smirnov Chagnes since [v3]: - Collected Reviewed-by from Lucas for most of the patches - Converted "PCI: imx6: Replace calls to udelay() with usleep_range()" to "PCI: imx6: Use usleep_range() in imx6_pcie_enable_ref_clk()" - Converted "PCI: imx6: Remove redundant debug tracing" to "PCI: imx6: Drop imx6_pcie_wait_for_link()" - Converted all of the callers of pcie_phy_poll_ack() to use true/false in "PCI: imx6: Simplify pcie_phy_poll_ack()" Changes since [v2]: - All non i.MX6 patches dropped, since they were accepted as a seprarte series - Series rebased on latest 'dwc-pci' branch of PCI tree - Patches "PCI: imx6: Use flags to indicate support for suspend" and "PCI: imx6: Replace calls to udelay() with usleep_range()" added to the series Changes since [v1]: - Dropped "PCI: imx6: Drop imx6_pcie_link_up()" due to the matter already having been addressed by "PCI: imx6: Fix link training status detection in link up check" from Trent Piepho - Changed "designware" -> "dwc" for all subject lines - Collected Acked-by's from Gustavo Pimentel [v3] lkml.kernel.org/r/20190401042547.14067-1-andrew.smir...@gmail.com [v2] lkml.kernel.org/r/20190104174925.17153-1-andrew.smir...@gmail.com [v1] lkml.kernel.org/r/20181221072716.29017-1-andrew.smir...@gmail.com Andrey Smirnov (11): PCI: imx6: Simplify imx7d_pcie_wait_for_phy_pll_lock() PCI: imx6: Drop imx6_pcie_wait_for_link() PCI: imx6: Return -ETIMEOUT from imx6_pcie_wait_for_speed_change() PCI: imx6: Remove PCIE_PL_PFLR_* constants PCI: dwc: imx6: Share PHY debug register definitions PCI: imx6: Make use of BIT() in constant definitions PCI: imx6: Simplify bit operations in PHY functions PCI: imx6: Simplify pcie_phy_poll_ack() PCI: imx6: Restrict PHY register data to 16-bit PCI: imx6: Use flags to indicate support for suspend PCI: imx6: Use usleep_range() in imx6_pcie_enable_ref_clk() drivers/pci/controller/dwc/pci-imx6.c| 143 --- drivers/pci/controller/dwc/pcie-designware.c | 12 +- drivers/pci/controller/dwc/pcie-designware.h | 3 + 3 files changed, 62 insertions(+), 96 deletions(-) -- 2.20.1
Re: Kconfig dependency issue on function-graph tracer and frame pointer on arm
On Sun, 14 Apr 2019 16:37:04 +0100
Russell King - ARM Linux admin wrote:
> On Sun, Apr 14, 2019 at 11:52:38PM +0900, Masami Hiramatsu wrote:
> > On Sun, 14 Apr 2019 14:34:58 +0100
> > Russell King - ARM Linux admin wrote:
> >
> > > On Sun, Apr 14, 2019 at 07:47:05PM +0900, Masami Hiramatsu wrote:
> > > > Hello,
> > > >
> > > > Recently, Naresh reported that the function-graph tracer on the latest
> > > > kernel crashes on arm. I could reproduce it and bisected. I finally
> > > > found
> > > > the commit f9b58e8c7d03 ("ARM: 8800/1: use choice for kernel unwinders")
> > > > was the first bad commit.
> > >
> > > I don't think that littering the rest of the kernel Kconfig with ARM
> > > specific stuff is really a viable solution to this.
> > >
> > > If we examine the current situation, we have:
> > >
> > > - THUMB2_KERNEL selecting ARM_UNWIND when enabled.
> > > - UNWINDER_FRAME_POINTER disabled if THUMB2_KERNEL is enabled, provided
> > > we're not using Clang. This leaves UNWINDER_ARM as the only choice,
> > > which also selects ARM_UNWIND.
> > > - The default choice is dependent on the settings of AEABI and
> > > FUNCTION_GRAPH_TRACER.
> > > - HAVE_FUNCTION_GRAPH_TRACER is disabled if THUMB2_KERNEL is enabled.
> > >
> > > which seems to be _way_ too messy.
> > >
> > > Looking back before this commit, the function graph tracer never had a
> > > strong dependence on frame pointers being enabled in the kernel, but it
> > > seems the code relies upon them (see ftrace_return_to_handler() in
> > > kernel/trace/ and return_to_handler in arch/arm/kernel/entry-frace.S).
> > > There is also the __ftrace_graph_caller macro which seems to rely on it.
> >
> > Yes, so I think similar bug is hiding in other LTS kernels. It should
> > have a dependency to FRAME_POINTER on arm.
> >
> > > Since Clang does not support frame pointers, we shouldn't even offer
> > > the function graph tracer for Clang compilers, so let's do that with
> > > the first hunk of the patch below.
> > >
> > > The subsequent hunks remove the defaulting of the choice according to
> > > the function graph tracer - this is not a "hint" where the user can
> > > still choose either option irrespective of the state of the function
> > > graph tracer. They should only be able to select the frame pointer
> > > option in that case.
> >
> > Agreed. Using default for making dependency is wrong.
> >
> > >
> > > Another way forward would be for someone to put the work in to making
> > > the function graph tracer work without frame pointers.
> >
> > Yes, we eventually need that. But for fixing current released kernel
> > (this bug is in v5.0 series), I think Kconfig fix is needed.
> >
> > >
> > > So, how about this:
> > >
> > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > > index 850b4805e2d1..9aed25a6019b 100644
> > > --- a/arch/arm/Kconfig
> > > +++ b/arch/arm/Kconfig
> > > @@ -73,7 +73,7 @@ config ARM
> > > select HAVE_EFFICIENT_UNALIGNED_ACCESS if (CPU_V6 || CPU_V6K || CPU_V7)
> > > && MMU
> > > select HAVE_EXIT_THREAD
> > > select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL
> > > - select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL
> > > + select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL && !CC_IS_CLANG
> > > select HAVE_FUNCTION_TRACER if !XIP_KERNEL
> > > select HAVE_GCC_PLUGINS
> > > select HAVE_HW_BREAKPOINT if PERF_EVENTS && (CPU_V6 || CPU_V6K ||
> > > CPU_V7)
> > > diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> > > index 6d6e0330930b..e388af4594a6 100644
> > > --- a/arch/arm/Kconfig.debug
> > > +++ b/arch/arm/Kconfig.debug
> > > @@ -47,8 +47,8 @@ config DEBUG_WX
> > >
> > > choice
> > > prompt "Choose kernel unwinder"
> > > - default UNWINDER_ARM if AEABI && !FUNCTION_GRAPH_TRACER
> > > - default UNWINDER_FRAME_POINTER if !AEABI || FUNCTION_GRAPH_TRACER
> > > + default UNWINDER_ARM if AEABI
> > > + default UNWINDER_FRAME_POINTER if !AEABI
> >
> > If UNWINDER_ARM depends on ARM EABI, would we really need this "if !AEABI"?
> > (I doubt we need these default...)
> >
> > > help
> > > This determines which method will be used for unwinding kernel stack
> > > traces for panics, oopses, bugs, warnings, perf, /proc//stack,
> > > @@ -65,7 +65,7 @@ config UNWINDER_FRAME_POINTER
> > >
> > > config UNWINDER_ARM
> > > bool "ARM EABI stack unwinder"
> > > - depends on AEABI
> > > + depends on AEABI && !FUNCTION_GRAPH_TRACER
> >
> > Hmm, AFAIK, FUNCTION_GRAPH_TRACER only depends on FRAME_POINTER, but not
> > UNWINDER_FRAME_POINTER. So can user still choose UNWINDER_ARM even if
> > FUNCTION_GRAPH_TRACER=y ? (Of course that may not be a meaningful option)
>
> The UNWINDER_* options do not control anything except whether
> FRAME_POINTER is enabled or not. FRAME_POINTER controls not only
> whether we build with frame pointers, but also how we unwind.
> If both ARM_UNWIND and FRAME_POINTER are set, the kernel will
> fail to link due to a multiple definition of unwind_frame().
Thank yo
Re: [PATCH 1/3 RFC] ARM: mvebu: at least warn on kzalloc failure
On Sun, Apr 14, 2019 at 06:26:02PM +0100, Russell King - ARM Linux admin wrote:
> On Sun, Apr 14, 2019 at 06:49:49AM +0200, Nicholas Mc Guire wrote:
> > Although it is very unlikely that the allocation during init would
> > fail any such failure should point to the original cause rather
> > than waiting for a null-pointer dereference to splat.
> >
> > Signed-off-by: Nicholas Mc Guire
> > ---
> >
> > Problem located with experimental coccinelle script
> >
> > While this will not really help much - but kzalloc failures should not
> > go unhandled.
>
> Sorry, no, not like this.
>
ok - well I wsa not sure about it either - it just seems wrong
to leave a possible allocation failure without any response.
The issue of generating excessive outout make sense - so will fix
it up to a pr_err() and resend.
thx!
hofrat
> With this patch, rather than getting an oops and a stacktrace which
> people can capture and email, we instead end up getting a warning
> line, a stack trace, followed by an oops containing another stack
> trace.
>
> We _already_ have problems getting people to send us kernel message
> debug information without editing out what they deem to be "unnecessary
> verbage", like all those numbers and function names that comprise a
> stack trace. We don't need yet more of that stuff, especially when it
> is redundant.
>
> So, I think throwing WARN_ON() at this case is way too excessive, and
> will only have a detrimental effect on the reports we receive - and
> that is extremely important.
>
> IMHO, A better solution would be to just print a warning, rather than
> causing the kernel to print several kB of needless messages.
>
> if (!new_compat)
> pr_err("new_compat allocation failure in %s()\n",
> __func__);
>
> >
> > Patch was compile-tested: mvebu_v7_defconfig (implies MACH_MVEBU_ANY=y)
> > (with some unrelated sparse warnings about missing syscalls)
> >
> > Patch is against 5.1-rc4 (localversion-next is 20190412)
> >
> > arch/arm/mach-mvebu/board-v7.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
> > index 0b10acd..37f8cb6 100644
> > --- a/arch/arm/mach-mvebu/board-v7.c
> > +++ b/arch/arm/mach-mvebu/board-v7.c
> > @@ -128,6 +128,7 @@ static void __init i2c_quirk(void)
> > struct property *new_compat;
> >
> > new_compat = kzalloc(sizeof(*new_compat), GFP_KERNEL);
> > + WARN_ON(!new_compat);
> >
> > new_compat->name = kstrdup("compatible", GFP_KERNEL);
> > new_compat->length = sizeof("marvell,mv78230-a0-i2c");
> > --
> > 2.1.4
> >
> >
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
Re: [PATCH 3/3] ARM: mvebu: add SPDX license identifier
On Sun, Apr 14, 2019 at 06:22:10PM +0200, Andrew Lunn wrote: > On Sun, Apr 14, 2019 at 06:49:51AM +0200, Nicholas Mc Guire wrote: > > The license is clearly identified as GPL V2 - so just add in the > > appropriate SPDX license identifier. > > > > Signed-off-by: Nicholas Mc Guire > > Hi Nicholas > > Adding a SPDX line makes the license text redundant, so you should > remove it in the same patch as adding the SPDX line. > So remove that first line from this paragraph * This file is licensed under the terms of the GNU General Public * License version 2. This program is licensed "as is" without any * warranty of any kind, whether express or implied. reducing it to: * This program is licensed "as is" without any warranty of any kind, * whether express or implied. Is that what you are proposing ? The GPL does state that there is no warranty but using a different wording that may not be legally equivalent. thx! hofrat
Re: [PATCH 1/1] pinctrl: Add alternative way for specifying register bases
Hi, Light
On Thu, Apr 11, 2019 at 8:15 PM Light Hsieh wrote:
>
> The orginal PINCTRL_MTK_PARIS/PINCTRL_MTK_MOORE need more effort for
> specifying register bases when porting platform driver:
> 1. Write mt_pinctrl_register_base_name[] array in pinctrl-mt.c
>to specify names of register bases, for exmaple:
>
> static const char * const mt6765_pinctrl_register_base_names[] = {
> "iocfg0", "iocfg1", "iocfg2", "iocfg3", "iocfg4", "iocfg5",
> "iocfg6", "iocfg7",
> };
> 2. Write reg = <...>, ..., <...>; in mt.dts to specify register
>bases. Each member of reg contain address range cloned from
>pre-generated devicetree node.
> 3. Write reg-names = "...", ..., "..."; in mt.dts to specify
>names of register bases. The sequence of names in reg-names shall match
>sequence of names that specified in pinctrl-mt.c.
>Besides, the seqeunce of names in reg-names shall also match sequence of
>address range in reg, for exmaple:
>
> pio: pinctrl {
> compatible = "mediatek,mt6765-pinctrl";
> reg = <0 0x10005000 0 0x1000>,
> <0 0x10002C00 0 0x200>,
> <0 0x10002800 0 0x200>,
> <0 0x10002A00 0 0x200>,
> <0 0x10002000 0 0x200>,
> <0 0x10002200 0 0x200>,
> <0 0x10002400 0 0x200>,
> <0 0x10002600 0 0x200>,
> <0 0x1000b000 0 0x1000>;
> reg-names = "iocfg0", "iocfg1", "iocfg2", "iocfg3",
> "iocfg4", "iocfg5", "iocfg6", "iocfg7",
> "eint";
>
> To reduce porting effort, this patch add an alternative way for specifying
> register bases:
> 1. Write reg_bases = <...>, ..., <...>; and reg_base_eint = <&eint>;
>in mt.dtsi where members in reg_bases and &eint are labels for
>pre-generated devicetree nodes, for example:
> pio: pinctrl {
> compatible = "mediatek,mt6765-pinctrl";
> reg_bases = <&gpio0>,
> <&iocfg0>,
> <&iocfg1>,
> <&iocfg2>,
> <&iocfg3>,
> <&iocfg4>,
> <&iocfg5>,
> <&iocfg6>,
> <&iocfg7>;
> reg_base_eint = <&eint>;
reg and reg-names both are generic properties used in all of DT-based
device and driver, described in
Documentation/devicetree/bindings/resource-names.txt, but reg_based
and reg_base_eint aren't.
If these properties are not hardware specific related, I personally
will encourage reusing those generic properties and relevant helpers
because those generic properties handling in the base driver are
almost bug-free, well maintained and even keep be extended in the
future. This way can help driver people put more concentration on
hardware specific stuff in the driver.
>
>Since this pre-generated nodes had already specify address range,
>it is not necessary to specify address range again in pinctrl node.
>
> Using this way, porting effort is reduced and therefore typo can occur with
> less chance.
>
> Change-Id: I55f5e328919f4f736ca4b9f8d1593e069f179637
> ---
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 19 +---
> drivers/pinctrl/mediatek/pinctrl-paris.c | 62
>
> 2 files changed, 54 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> index b1c3684..16b4863 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
>
> #include "mtk-eint.h"
> #include "pinctrl-mtk-common-v2.h"
> @@ -310,7 +311,7 @@ static int mtk_xt_set_gpio_as_eint(void *data, unsigned
> long eint_n)
>
> int mtk_build_eint(struct mtk_pinctrl *hw, struct platform_device *pdev)
> {
> - struct device_node *np = pdev->dev.of_node;
> + struct device_node *np = pdev->dev.of_node, *node;
> struct resource *res;
>
> if (!IS_ENABLED(CONFIG_EINT_MTK))
> @@ -323,13 +324,19 @@ int mtk_build_eint(struct mtk_pinctrl *hw, struct
> platform_device *pdev)
> if (!hw->eint)
> return -ENOMEM;
>
> - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "eint");
> - if (!res) {
> - dev_err(&pdev->dev, "Unable to get eint resource\n");
> - return -ENODEV;
> + node = of_parse_phandle(np, "reg_base_eint", 0);
> + if (node) {
> + hw->eint->base = of_iomap(node, 0);
> + } else {
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> + "eint");
> +
Linux 5.1-rc5
Here we go again.. It's Sunday afternoon, must mean another rc kernel. We have changes all over, but not unseasonably many of them, and most of the ones here are very small. Looking at the stats, the sound driver updates kind of stand out, being almost a third of the patch (and about a third of the commits too, so it's not because of some single big patch). But none of it looks all that scary. Outside of the sound fixes, another third is other drivers (gpu, rdma, nvme, mmc, block layer..) and the last third is "misc". That includes arch updates, tooling, and various core fixes (networking, filesystem, security modules, and core kernel/mm). Nothing in here makes me feel uncomfortable about this release cycle so far. Knock wood. Shortlog appended with an overview of the details, as usual. Linus --- Alex Deucher (1): drm/amdkfd: Add picasso pci id Alexander Potapenko (1): x86/asm: Use stricter assembly constraints in bitops Anand Jain (2): btrfs: prop: fix zstd compression parameter validation btrfs: prop: fix vanished compression property after failed set Andre Przywara (1): PCI: Add function 1 DMA alias quirk for Marvell 9170 SATA controller Andrei Vagin (1): alarmtimer: Return correct remaining time Annaliese McDermond (2): ASoC: tlv320aic32x4: Fix Common Pins ASoC: tlv320aic32x4: Change author's name Ard Biesheuvel (1): arm64/ftrace: fix inadvertent BUG() in trampoline check Arnaud Pouliquen (1): ASoC: stm32: fix sai driver name initialisation Bart Van Assche (1): locking/lockdep: Zap lock classes even with lock debugging disabled Brian Norris (1): Bluetooth: btusb: request wake pin with NOAUTOEN CK Hu (2): drm/mediatek: Implement gem prime vmap/vunmap function drm/mediatek: Add Mediatek framebuffer device Charles Keepax (6): ASoC: wm_adsp: Correct handling of compressed streams that restart ASoC: wm_adsp: Correct error messages in wm_adsp_buffer_get_error ASoC: wm_adsp: Add locking to wm_adsp2_bus_error ASoC: wm_adsp: Shutdown any compressed streams on DSP watchdog timeout ASoC: wm_adsp: Check for buffer in trigger stop ASoC: cs35l35: Disable regulators on driver removal Chong Qiao (1): MIPS: KGDB: fix kgdb support for SMP platforms. Chris Wilson (2): drm/i915/gvt: Annotate iomem usage drm/i915/gvt: Prevent use-after-free in ppgtt_free_all_spt() Christoph Hellwig (1): sparc64/pci_sun4v: fix ATU checks for large DMA masks Christophe Leroy (2): powerpc/32: Fix early boot failure with RTAS built-in powerpc/vdso32: fix CLOCK_MONOTONIC on PPC64 Chuck Lever (2): NFS: Fix handling of reply page vector xprtrdma: Fix helper that drains the transport Cornelia Huck (1): virtio: Honour 'may_reduce_num' in vring_create_virtqueue Dan Carpenter (5): drm/mediatek: Fix an error code in mtk_hdmi_dt_parse_pdata() aio: Fix an error code in __io_submit_one() irqchip/irq-ls1x: Missing error code in ls1x_intc_of_init() NFC: nci: Add some bounds checking in nci_hci_cmd_received() nfc: nci: Potential off by one in ->pipes[] array Daniel Drake (1): mmc: alcor: don't write data before command has completed Daniel Mack (1): ASoC: cs4270: Set auto-increment bit for register writes Daniel Mentz (1): ALSA: uapi: #include in asound.h Dave Airlie (1): drm/udl: add a release method and delay modeset teardown David Müller (1): clk: x86: Add system specific quirk to mark clocks as critical Dongli Zhang (2): virtio-blk: limit number of hw queues by nr_cpu_ids scsi: virtio_scsi: limit number of hw queues by nr_cpu_ids Erik Schmauss (1): ACPICA: Namespace: remove address node from global list after method termination Faiz Abbas (1): mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning Filipe Manana (1): Btrfs: do not allow trimming when a fs is mounted with the nologreplay option Guenter Roeck (1): ASoC: intel: Fix crash at suspend/resume after failed codec registration Gustavo A. R. Silva (1): ASoC: ab8500: Mark expected switch fall-through Hans Holmberg (1): lightnvm: pblk: fix crash in pblk_end_partial_read due to multipage bvecs Hans de Goede (1): ASoC: Intel: cht_bsw_max98090_ti: Enable codec clock once and keep it enabled Heiner Kallweit (1): r8169: disable ASPM again Horatiu Vultur (1): MIPS: generic: Add switchdev, pinctrl and fit to ocelot_defconfig Hui Wang (1): ALSA: hda - Add two more machines to the power_save_blacklist Imre Deak (1): drm/i915: Get power refs in encoder->get_power_domains() Iuliana Prodan (1): crypto: caam - fix copy of next buffer for xcbc and cmac James Smart (1): nvme-fc: correct csn initialization and increments on error Jani Nikula (1): drm/i915/dp: revert back to max link rate and lane count on eDP Jann Horn (
[tip:WIP.x86/stackguards 1/32] mm/slab.c:1486:27: error: expected '}' before ';' token
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
WIP.x86/stackguards
head: 310a7f5b0b42c6a8edeb74ae3289a98896e0e5c9
commit: 7552063baa017438f2bfd6060e0b949808acc812 [1/32] mm/slab: Fix broken
stack trace storage
config: x86_64-randconfig-x003-201915 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 7552063baa017438f2bfd6060e0b949808acc812
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
mm/slab.c: In function 'store_stackinfo':
>> mm/slab.c:1486:27: error: expected '}' before ';' token
.max_entries = size - 4;
^
vim +1486 mm/slab.c
1468
1469 #ifdef CONFIG_DEBUG_PAGEALLOC
1470 static void store_stackinfo(struct kmem_cache *cachep, unsigned long
*addr,
1471 unsigned long caller)
1472 {
1473 int size = cachep->object_size / sizeof(unsigned long);
1474
1475 addr = (unsigned long *)&((char *)addr)[obj_offset(cachep)];
1476
1477 if (size < 5)
1478 return;
1479
1480 *addr++ = 0x12345678;
1481 *addr++ = caller;
1482 *addr++ = smp_processor_id();
1483 #ifdef CONFIG_STACKTRACE
1484 {
1485 struct stack_trace trace = {
> 1486 .max_entries= size - 4;
1487 .entries= addr;
1488 .skip = 3;
1489 };
1490
1491 save_stack_trace(&trace);
1492 addr += trace.nr_entries;
1493 }
1494 #endif
1495 *addr = 0x87654321;
1496 }
1497
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[tip:WIP.core/stacktrace 37/47] kernel/locking/lockdep.c:2806:2: error: implicit declaration of function 'print_lock_trace'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
WIP.core/stacktrace
head: 63c35ea6b829a0f98d307a8dec038095681ecd13
commit: 88e5708cae1e9cb0cca97bb0af5866ac54532ceb [37/47] lockdep: Simplify
stack trace handling
config: x86_64-randconfig-l2-201915 (attached as .config)
compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
reproduce:
git checkout 88e5708cae1e9cb0cca97bb0af5866ac54532ceb
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
kernel/locking/lockdep.c: In function 'print_usage_bug':
>> kernel/locking/lockdep.c:2806:2: error: implicit declaration of function
>> 'print_lock_trace' [-Werror=implicit-function-declaration]
print_lock_trace(hlock_class(this)->usage_traces + prev_bit, 1);
^
cc1: some warnings being treated as errors
vim +/print_lock_trace +2806 kernel/locking/lockdep.c
2780
2781 static int
2782 print_usage_bug(struct task_struct *curr, struct held_lock *this,
2783 enum lock_usage_bit prev_bit, enum lock_usage_bit
new_bit)
2784 {
2785 if (!debug_locks_off_graph_unlock() || debug_locks_silent)
2786 return 0;
2787
2788 pr_warn("\n");
2789 pr_warn("\n");
2790 pr_warn("WARNING: inconsistent lock state\n");
2791 print_kernel_ident();
2792 pr_warn("\n");
2793
2794 pr_warn("inconsistent {%s} -> {%s} usage.\n",
2795 usage_str[prev_bit], usage_str[new_bit]);
2796
2797 pr_warn("%s/%d [HC%u[%lu]:SC%u[%lu]:HE%u:SE%u] takes:\n",
2798 curr->comm, task_pid_nr(curr),
2799 trace_hardirq_context(curr), hardirq_count() >>
HARDIRQ_SHIFT,
2800 trace_softirq_context(curr), softirq_count() >>
SOFTIRQ_SHIFT,
2801 trace_hardirqs_enabled(curr),
2802 trace_softirqs_enabled(curr));
2803 print_lock(this);
2804
2805 pr_warn("{%s} state was registered at:\n", usage_str[prev_bit]);
> 2806 print_lock_trace(hlock_class(this)->usage_traces + prev_bit, 1);
2807
2808 print_irqtrace_events(curr);
2809 pr_warn("\nother info that might help us debug this:\n");
2810 print_usage_bug_scenario(this);
2811
2812 lockdep_print_held_locks(curr);
2813
2814 pr_warn("\nstack backtrace:\n");
2815 dump_stack();
2816
2817 return 0;
2818 }
2819
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
BUG: Internal error: Oops: 17 [#1] SMP / _raw_spin_lock()
Hi, while issuing the command "dd if=/dev/zero of=test2 bs=8k count=64k conv=sync" in /tmp3 on the rootfs (/dev/sda1; a SSD drive), the system sometime crashes (maybe in 5% of the cases) The device is a Banana Pi using Allwinner A20 SoC (sunxi/sun7i/ARM), the kernel in use is the stock 5.0.5 kernel w/o any modifications, but compiled by myself. Could a kind kernel developer/tester please briefly check the following serial output whether the bug is in the SATA driver (ahci-sunxi[1c18000.sata]) or is it perhaps a kernel bug? That driver is linked into the kernel. A coredump was not generated. I'm new to kernel debugging. Is this a problem with _raw_spin_lock() (--> https://lwn.net/Articles/14473/ ), or a NULL pointer issue? Here's the serial debug output, interrupt list and iomem list: [ 262.990731] random: crng init done [ 262.994158] random: 7 urandom warning(s) missed due to ratelimiting [ 263.720319] Unable to handle kernel NULL pointer dereference at virtual address [ 263.728442] pgd = aaea8072 [ 263.731161] [] *pgd=7f213835 [ 263.734762] Internal error: Oops: 17 [#1] SMP THUMB2 [ 263.739730] Modules linked in: b53_mdio b53_common dsa_core phylink devlink bridge nvmem_sunxi_sid sun4i_ts input_leds sun4i_ss cpufreq_dt uio_pdrv_genirq uio evdev [ 263.754491] CPU: 1 PID: 568 Comm: dd Not tainted 5.0.5-my11 #1 [ 263.760327] Hardware name: Allwinner sun7i (A20) Family [ 263.765582] PC is at _raw_spin_lock+0x4/0x30 [ 263.769869] LR is at __queue_work+0x133/0x2c8 [ 263.774234] pc : []lr : []psr: 000701b3 [ 263.780506] sp : ee27fad0 ip : c0c10748 fp : ef10ab00 [ 263.785736] r10: c0b51324 r9 : ee27e000 r8 : c0c6fcf8 [ 263.790970] r7 : ef6b2f80 r6 : 0004 r5 : ee5ac840 r4 : ef6b7b00 [ 263.797503] r3 : 12c1 r2 : 12c0 r1 : r0 : [ 263.804039] Flags: nzcv IRQs off FIQs on Mode SVC_32 ISA Thumb Segment none [ 263.811442] Control: 50c5387d Table: 6e29c06a DAC: 0051 [ 263.817196] Process dd (pid: 568, stack limit = 0xe5362e05) [ 263.822776] Stack: (0xee27fad0 to 0xee28) [ 263.827150] fac0: 03024100 c056a955 0001 0014 [ 263.835345] fae0: ee27fad0 c0b51324 0001 ee5ac840 0004 ef10ab00 [ 263.843540] fb00: ee27fbe0 c0c03080 c0129e2d 20070113 c0c08d48 c0ca6cc8 ee5ac840 [ 263.851736] fb20: 0001 eeba0588 eeba09d4 c049c67f 3335 ee5ac800 0001 c04a33fb [ 263.859930] fb40: eeba0588 eeba0588 c04a3497 ee5ceb00 [ 263.868125] fb60: eead8800 c056b6bf ffe1 ee5cebb8 ee5ceb00 [ 263.876322] fb80: 0100 c056b7d5 ee5cebb8 0010 ee4ef418 ef05d800 ee27e000 c0c08d48 [ 263.884498] fba0: ee27fbe0 ee27fbc4 ee5ceb38 0004 c0c03090 ee27e000 0100 c04a1b2b [ 263.892666] fbc0: ee27fc00 ee27fbc4 ee27fbc4 c0c08d48 0025 4004 c0102263 [ 263.900835] fbe0: 0001 ef134a00 ef134a64 c0c03080 c0b51380 000a c0b58d40 c0b58d40 [ 263.909003] fc00: c0b51310 f1d4 c0c03d00 0044 c0c091f0 c0b58cfc [ 263.917171] fc20: 0001 ef00c000 f0803000 efb8fc74 c011c17b 008a c01506c7 [ 263.925340] fc40: 0048 c0c091f0 ee27fc78 f080200c f0802000 c04f7c15 ecac9a00 c01efaca [ 263.933509] fc60: 00070033 ee27fcac c39e ee27e000 c0101a65 c39f ee27fcc8 [ 263.941677] fc80: ef6b6b84 ef6b6b80 ef003a80 ecac99c0 00708840 2eb5a000 c39e [ 263.949846] fca0: efb8fc74 a0070013 ee27fcc8 ecac9a00 c01efaca 00070033 [ 263.958014] fcc0: 0051 bf00 1000 00700840 c0224429 [ 263.966182] fce0: c02244f3 ef058800 ef058800 efb8fc74 efb8fc74 [ 263.974350] fd00: ed482330 1000 ed48242c 1000 c02245c9 [ 263.982518] fd20: efb8fc74 c026f839 c0c08d48 eed430a0 ee5ba000 c0270899 [ 263.990686] fd40: ed482330 1000 c0ca02ac ed48242c 1000 c02981d3 00600040 ee5b9400 [ 263.998854] fd60: 0001 0c12 0002 c0c08d48 efb8fc74 eed430a0 [ 264.007022] fd80: ed482330 176ca000 ed48242c 1000 c0275787 1000 c0270899 [ 264.015190] fda0: efb8fc50 176cb000 ee27fe0c 000176ca c0c08d48 [ 264.023358] fdc0: 0656d5cd ee27fef8 ed48242c ee1fb480 c02756ad c081276c 1000 [ 264.031526] fde0: 1000 c01b8941 1000 ee27fe0c ee27fe10 176ca000 [ 264.039695] fe00: ee27e000 5cb39559 c0c08d48 ef39db80 [ 264.047863] fe20: ee27ff10 ed48242c ed482330 ee1fb480 ee27fef8 c01b9959 [ 264.056031] fe40: ed482330 0004 c01b65ff ee27fe58 c0b59180 2000 ee27ff10 [ 264.064200] fe60: ed482330 ee27fef8 ed4823b0 ed482330 2000 c0267475 [ 264.072368] fe80: c0760167 1000 c04bdc43 ee5cd380
[tip:WIP.core/stacktrace 24/47] mm/slab.c:1490:11: error: 'trace' undeclared; did you mean 'true'?
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
WIP.core/stacktrace
head: 63c35ea6b829a0f98d307a8dec038095681ecd13
commit: c79cc35c00e9f15a9a32a08569036cb8365c8816 [24/47] mm/slab: Simplify
stack trace handling
config: x86_64-randconfig-x003-201915 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout c79cc35c00e9f15a9a32a08569036cb8365c8816
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
mm/slab.c: In function 'store_stackinfo':
>> mm/slab.c:1490:11: error: 'trace' undeclared (first use in this function);
>> did you mean 'true'?
addr += trace.nr_entries;
^
true
mm/slab.c:1490:11: note: each undeclared identifier is reported only once
for each function it appears in
vim +1490 mm/slab.c
^1da177e Linus Torvalds 2005-04-16 1468
^1da177e Linus Torvalds 2005-04-16 1469 #ifdef CONFIG_DEBUG_PAGEALLOC
343e0d7a Pekka Enberg2006-02-01 1470 static void store_stackinfo(struct
kmem_cache *cachep, unsigned long *addr,
^1da177e Linus Torvalds 2005-04-16 1471 unsigned
long caller)
^1da177e Linus Torvalds 2005-04-16 1472 {
b8623975 Thomas Gleixner 2019-04-08 1473 int size = cachep->object_size
/ sizeof(unsigned long);
^1da177e Linus Torvalds 2005-04-16 1474
3dafccf2 Manfred Spraul 2006-02-01 1475 addr = (unsigned long *)&((char
*)addr)[obj_offset(cachep)];
^1da177e Linus Torvalds 2005-04-16 1476
b8623975 Thomas Gleixner 2019-04-08 1477 if (size < 5)
^1da177e Linus Torvalds 2005-04-16 1478 return;
^1da177e Linus Torvalds 2005-04-16 1479
^1da177e Linus Torvalds 2005-04-16 1480 *addr++ = 0x12345678;
^1da177e Linus Torvalds 2005-04-16 1481 *addr++ = caller;
^1da177e Linus Torvalds 2005-04-16 1482 *addr++ = smp_processor_id();
b8623975 Thomas Gleixner 2019-04-08 1483 size -= 3;
b8623975 Thomas Gleixner 2019-04-08 1484 #ifdef CONFIG_STACKTRACE
^1da177e Linus Torvalds 2005-04-16 1485 {
c79cc35c Thomas Gleixner 2019-04-14 1486 unsigned int nr_entries;
^1da177e Linus Torvalds 2005-04-16 1487
c79cc35c Thomas Gleixner 2019-04-14 1488 /* Leave one for the
end marker below */
c79cc35c Thomas Gleixner 2019-04-14 1489 nr_entries =
stack_trace_save(addr, size - 1, 3);
b8623975 Thomas Gleixner 2019-04-08 @1490 addr +=
trace.nr_entries;
^1da177e Linus Torvalds 2005-04-16 1491 }
b8623975 Thomas Gleixner 2019-04-08 1492 #endif
b8623975 Thomas Gleixner 2019-04-08 1493 *addr = 0x87654321;
^1da177e Linus Torvalds 2005-04-16 1494 }
40b44137 Joonsoo Kim 2016-03-15 1495
:: The code at line 1490 was first introduced by commit
:: b86239751f8c4d6fc43f6a9eca29e77b0319f5d7 mm/slab: Fix broken stack trace
storage
:: TO: Thomas Gleixner
:: CC: Thomas Gleixner
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[tip:WIP.core/stacktrace 37/47] kernel/locking/lockdep.c:2806:2: error: implicit declaration of function 'print_lock_trace'; did you mean 'print_lock_name'?
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
WIP.core/stacktrace
head: 63c35ea6b829a0f98d307a8dec038095681ecd13
commit: 88e5708cae1e9cb0cca97bb0af5866ac54532ceb [37/47] lockdep: Simplify
stack trace handling
config: i386-randconfig-x018-201915 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 88e5708cae1e9cb0cca97bb0af5866ac54532ceb
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
kernel/locking/lockdep.c: In function 'print_usage_bug':
>> kernel/locking/lockdep.c:2806:2: error: implicit declaration of function
>> 'print_lock_trace'; did you mean 'print_lock_name'?
>> [-Werror=implicit-function-declaration]
print_lock_trace(hlock_class(this)->usage_traces + prev_bit, 1);
^~~~
print_lock_name
cc1: some warnings being treated as errors
vim +2806 kernel/locking/lockdep.c
2780
2781 static int
2782 print_usage_bug(struct task_struct *curr, struct held_lock *this,
2783 enum lock_usage_bit prev_bit, enum lock_usage_bit
new_bit)
2784 {
2785 if (!debug_locks_off_graph_unlock() || debug_locks_silent)
2786 return 0;
2787
2788 pr_warn("\n");
2789 pr_warn("\n");
2790 pr_warn("WARNING: inconsistent lock state\n");
2791 print_kernel_ident();
2792 pr_warn("\n");
2793
2794 pr_warn("inconsistent {%s} -> {%s} usage.\n",
2795 usage_str[prev_bit], usage_str[new_bit]);
2796
2797 pr_warn("%s/%d [HC%u[%lu]:SC%u[%lu]:HE%u:SE%u] takes:\n",
2798 curr->comm, task_pid_nr(curr),
2799 trace_hardirq_context(curr), hardirq_count() >>
HARDIRQ_SHIFT,
2800 trace_softirq_context(curr), softirq_count() >>
SOFTIRQ_SHIFT,
2801 trace_hardirqs_enabled(curr),
2802 trace_softirqs_enabled(curr));
2803 print_lock(this);
2804
2805 pr_warn("{%s} state was registered at:\n", usage_str[prev_bit]);
> 2806 print_lock_trace(hlock_class(this)->usage_traces + prev_bit, 1);
2807
2808 print_irqtrace_events(curr);
2809 pr_warn("\nother info that might help us debug this:\n");
2810 print_usage_bug_scenario(this);
2811
2812 lockdep_print_held_locks(curr);
2813
2814 pr_warn("\nstack backtrace:\n");
2815 dump_stack();
2816
2817 return 0;
2818 }
2819
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[tip:WIP.core/stacktrace 47/47] kernel//trace/trace_stack.c:263:26: error: invalid use of undefined type 'struct stack_trace'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
WIP.core/stacktrace
head: 63c35ea6b829a0f98d307a8dec038095681ecd13
commit: 63c35ea6b829a0f98d307a8dec038095681ecd13 [47/47] x86/stacktrace: Use
common infrastructure
config: i386-randconfig-x010-201915 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 63c35ea6b829a0f98d307a8dec038095681ecd13
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
kernel//trace/trace_stack.c:24:17: error: static declaration of
'stack_trace_index' follows non-static declaration
static unsigned stack_trace_index[STACK_TRACE_ENTRIES];
^
In file included from kernel//trace/trace_stack.c:12:0:
include/linux/ftrace.h:248:17: note: previous declaration of
'stack_trace_index' was here
extern unsigned stack_trace_index[];
^
kernel//trace/trace_stack.c:27:22: error: static declaration of
'stack_trace_max_size' follows non-static declaration
static unsigned long stack_trace_max_size;
^~~~
In file included from kernel//trace/trace_stack.c:12:0:
include/linux/ftrace.h:250:22: note: previous declaration of
'stack_trace_max_size' was here
extern unsigned long stack_trace_max_size;
^~~~
kernel//trace/trace_stack.c:28:24: error: static declaration of
'stack_trace_max_lock' follows non-static declaration
static arch_spinlock_t stack_trace_max_lock =
^~~~
In file included from kernel//trace/trace_stack.c:12:0:
include/linux/ftrace.h:251:24: note: previous declaration of
'stack_trace_max_lock' was here
extern arch_spinlock_t stack_trace_max_lock;
^~~~
kernel//trace/trace_stack.c: In function '__next':
>> kernel//trace/trace_stack.c:263:26: error: invalid use of undefined type
>> 'struct stack_trace'
if (n >= stack_trace_max.nr_entries)
^
kernel//trace/trace_stack.c: In function 't_show':
kernel//trace/trace_stack.c:327:22: error: invalid use of undefined type
'struct stack_trace'
stack_trace_max.nr_entries);
^
kernel//trace/trace_stack.c:337:26: error: invalid use of undefined type
'struct stack_trace'
if (i >= stack_trace_max.nr_entries)
^
kernel//trace/trace_stack.c:340:30: error: invalid use of undefined type
'struct stack_trace'
if (i + 1 == stack_trace_max.nr_entries)
^
vim +263 kernel//trace/trace_stack.c
e5a81b62 Steven Rostedt 2008-08-27 257
e5a81b62 Steven Rostedt 2008-08-27 258 static void *
2fc5f0cf Li Zefan2009-08-17 259 __next(struct seq_file *m, loff_t
*pos)
e5a81b62 Steven Rostedt 2008-08-27 260 {
2fc5f0cf Li Zefan2009-08-17 261long n = *pos - 1;
e5a81b62 Steven Rostedt 2008-08-27 262
4285f2fc Thomas Gleixner 2019-04-10 @263if (n >=
stack_trace_max.nr_entries)
e5a81b62 Steven Rostedt 2008-08-27 264return NULL;
e5a81b62 Steven Rostedt 2008-08-27 265
2fc5f0cf Li Zefan2009-08-17 266m->private = (void *)n;
1b6cced6 Steven Rostedt 2008-08-29 267return &m->private;
e5a81b62 Steven Rostedt 2008-08-27 268 }
e5a81b62 Steven Rostedt 2008-08-27 269
:: The code at line 263 was first introduced by commit
:: 4285f2fcef8001ead0f1c9315ba50302cab68cda tracing: Remove the ULONG_MAX
stack trace hackery
:: TO: Thomas Gleixner
:: CC: Thomas Gleixner
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[tip:WIP.core/stacktrace 34/47] drivers/gpu/drm/drm_mm.c:136:3: error: implicit declaration of function 'stack_trace_snprintf'; did you mean 'stack_trace_snprint'?
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
WIP.core/stacktrace
head: 63c35ea6b829a0f98d307a8dec038095681ecd13
commit: 6476291d5b823a05b9c903a65a5f6e6026a02606 [34/47] drm: Simplify
stacktrace handling
config: i386-randconfig-x019-201915 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 6476291d5b823a05b9c903a65a5f6e6026a02606
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/gpu/drm/drm_mm.c: In function 'show_leaks':
>> drivers/gpu/drm/drm_mm.c:136:3: error: implicit declaration of function
>> 'stack_trace_snprintf'; did you mean 'stack_trace_snprint'?
>> [-Werror=implicit-function-declaration]
stack_trace_snprintf(buf, BUFSZ, entries, nr_entries, 0);
^~~~
stack_trace_snprint
cc1: some warnings being treated as errors
vim +136 drivers/gpu/drm/drm_mm.c
116
117 static void show_leaks(struct drm_mm *mm)
118 {
119 struct drm_mm_node *node;
120 unsigned long *entries;
121 unsigned int nr_entries;
122 char *buf;
123
124 buf = kmalloc(BUFSZ, GFP_KERNEL);
125 if (!buf)
126 return;
127
128 list_for_each_entry(node, drm_mm_nodes(mm), node_list) {
129 if (!node->stack) {
130 DRM_ERROR("node [%08llx + %08llx]: unknown
owner\n",
131node->start, node->size);
132 continue;
133 }
134
135 nr_entries = stack_depot_fetch(node->stack, &entries);
> 136 stack_trace_snprintf(buf, BUFSZ, entries, nr_entries,
> 0);
137 DRM_ERROR("node [%08llx + %08llx]: inserted at\n%s",
138node->start, node->size, buf);
139 }
140
141 kfree(buf);
142 }
143
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[tip:WIP.core/stacktrace 18/47] kernel//trace/trace_stack.c:24:17: error: static declaration of 'stack_trace_index' follows non-static declaration
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
WIP.core/stacktrace
head: 63c35ea6b829a0f98d307a8dec038095681ecd13
commit: 4a934c54305ab50cf2d4b0afb915feee0dbb487e [18/47] tracing: Cleanup stack
trace code
config: i386-randconfig-x010-201915 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout 4a934c54305ab50cf2d4b0afb915feee0dbb487e
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> kernel//trace/trace_stack.c:24:17: error: static declaration of
>> 'stack_trace_index' follows non-static declaration
static unsigned stack_trace_index[STACK_TRACE_ENTRIES];
^
In file included from kernel//trace/trace_stack.c:12:0:
include/linux/ftrace.h:248:17: note: previous declaration of
'stack_trace_index' was here
extern unsigned stack_trace_index[];
^
>> kernel//trace/trace_stack.c:36:22: error: static declaration of
>> 'stack_trace_max_size' follows non-static declaration
static unsigned long stack_trace_max_size;
^~~~
In file included from kernel//trace/trace_stack.c:12:0:
include/linux/ftrace.h:250:22: note: previous declaration of
'stack_trace_max_size' was here
extern unsigned long stack_trace_max_size;
^~~~
>> kernel//trace/trace_stack.c:37:24: error: static declaration of
>> 'stack_trace_max_lock' follows non-static declaration
static arch_spinlock_t stack_trace_max_lock =
^~~~
In file included from kernel//trace/trace_stack.c:12:0:
include/linux/ftrace.h:251:24: note: previous declaration of
'stack_trace_max_lock' was here
extern arch_spinlock_t stack_trace_max_lock;
^~~~
vim +/stack_trace_index +24 kernel//trace/trace_stack.c
22
23 static unsigned long stack_dump_trace[STACK_TRACE_ENTRIES];
> 24 static unsigned stack_trace_index[STACK_TRACE_ENTRIES];
25
26 /*
27 * Reserve one entry for the passed in ip. This will allow
28 * us to remove most or all of the stack size overhead
29 * added by the stack tracer itself.
30 */
31 struct stack_trace stack_trace_max = {
32 .max_entries= STACK_TRACE_ENTRIES - 1,
33 .entries= &stack_dump_trace[0],
34 };
35
> 36 static unsigned long stack_trace_max_size;
> 37 static arch_spinlock_t stack_trace_max_lock =
38 (arch_spinlock_t)__ARCH_SPIN_LOCK_UNLOCKED;
39
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: bug disabling NX (noexec=off)
On 4/14/19 11:59 AM, Thomas Gleixner wrote: > On Sat, 13 Apr 2019, Xose Vazquez Perez wrote: >> [0.00] NX (Execute Disable) protection: disabled by kernel command >> line option >> [0.00] [ cut here ] >> [0.00] attempted to set unsupported pgprot: 8163 bits: >> 8000 supported: 7fff > > Does the below patch fix it for you? > > Thanks, > > tglx > > 8< > diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c > index 0029604af8a4..dd73d5d74393 100644 > --- a/arch/x86/mm/ioremap.c > +++ b/arch/x86/mm/ioremap.c > @@ -825,7 +825,7 @@ void __init __early_set_fixmap(enum fixed_addresses idx, > pte = early_ioremap_pte(addr); > > /* Sanitize 'prot' against any unsupported bits: */ > - pgprot_val(flags) &= __default_kernel_pte_mask; > + pgprot_val(flags) &= __supported_pte_mask; > > if (pgprot_val(flags)) > set_pte(pte, pfn_pte(phys >> PAGE_SHIFT, flags)); > Yes, it fixed it. But there is another bug that I did not see before, but it was there: ---cut dmesg--- Freeing unused kernel image memory: 76K [ cut here ] x86/mm: Found insecure W+X mapping at address 0x9df5 WARNING: CPU: 1 PID: 1 at arch/x86/mm/dump_pagetables.c:262 note_page+0x2ae/0x650 Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.0.7-300.fc30.x86_64 #1 Hardware name: Hewlett-Packard p6-2004es/2ABF, BIOS 7.16 03/23/2012 RIP: 0010:note_page+0x2ae/0x650 Code: 29 f0 48 c1 e8 0c 48 01 43 40 80 3d 54 15 2c 01 00 0f 85 07 ff ff ff 48 c7 c7 a0 d9 0a b7 c6 05 40 15 2c 01 01 e8 41 2d 06 00 <0f> 0b 4c 8b 4b 20 e9 e9 fe ff ff 48 29 d6 84 c9 0f 85 71 09 00 00 RSP: 0018:b35940c63e18 EFLAGS: 00010286 RAX: RBX: b35940c63ec8 RCX: 0050 RDX: 0001 RSI: 0092 RDI: 0247 RBP: 0161 R08: 0001 R09: 02ca R10: e844 R11: 0003 R12: R13: 0005 R14: R15: FS: () GS:9df73728() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f2e235a8a88 CR3: 00012b20e002 CR4: 000606e0 Call Trace: ? vprintk_emit+0x1ec/0x250 ptdump_walk_pgd_level_core+0x46a/0x4c0 ? rest_init+0xaa/0xaa kernel_init+0x2c/0x106 ret_from_fork+0x1f/0x40 ---[ end trace 3288a26b9a3da7ee ]--- x86/mm: Checked W+X mappings: FAILED, 2175454 W+X pages found. rodata_test: all tests were successful Run /init as init process ---cut dmesg--- Thank you.
[tip:x86/urgent] x86/speculation: Prevent deadlock on ssb_state::lock
Commit-ID: 2f5fb19341883bb6e37da351bc3700489d8506a7
Gitweb: https://git.kernel.org/tip/2f5fb19341883bb6e37da351bc3700489d8506a7
Author: Thomas Gleixner
AuthorDate: Sun, 14 Apr 2019 19:51:06 +0200
Committer: Thomas Gleixner
CommitDate: Sun, 14 Apr 2019 23:05:52 +0200
x86/speculation: Prevent deadlock on ssb_state::lock
Mikhail reported a lockdep splat related to the AMD specific ssb_state
lock:
CPU0 CPU1
lock(&st->lock);
local_irq_disable();
lock(&(&sighand->siglock)->rlock);
lock(&st->lock);
lock(&(&sighand->siglock)->rlock);
*** DEADLOCK ***
The connection between sighand->siglock and st->lock comes through seccomp,
which takes st->lock while holding sighand->siglock.
Make sure interrupts are disabled when __speculation_ctrl_update() is
invoked via prctl() -> speculation_ctrl_update(). Add a lockdep assert to
catch future offenders.
Fixes: 1f50ddb4f418 ("x86/speculation: Handle HT correctly on AMD")
Reported-by: Mikhail Gavrilov
Signed-off-by: Thomas Gleixner
Tested-by: Mikhail Gavrilov
Cc: Thomas Lendacky
Cc: sta...@vger.kernel.org
Link:
https://lkml.kernel.org/r/alpine.deb.2.21.1904141948200.4...@nanos.tec.linutronix.de
---
arch/x86/kernel/process.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 58ac7be52c7a..957eae13b370 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -426,6 +426,8 @@ static __always_inline void
__speculation_ctrl_update(unsigned long tifp,
u64 msr = x86_spec_ctrl_base;
bool updmsr = false;
+ lockdep_assert_irqs_disabled();
+
/*
* If TIF_SSBD is different, select the proper mitigation
* method. Note that if SSBD mitigation is disabled or permanentely
@@ -477,10 +479,12 @@ static unsigned long speculation_ctrl_update_tif(struct
task_struct *tsk)
void speculation_ctrl_update(unsigned long tif)
{
+ unsigned long flags;
+
/* Forced update. Make sure all relevant TIF flags are different */
- preempt_disable();
+ local_irq_save(flags);
__speculation_ctrl_update(~tif, tif);
- preempt_enable();
+ local_irq_restore(flags);
}
/* Called from seccomp/prctl update */
[tip:core/stacktrace] tracing: Remove the ULONG_MAX stack trace hackery
Commit-ID: 4285f2fcef8001ead0f1c9315ba50302cab68cda
Gitweb: https://git.kernel.org/tip/4285f2fcef8001ead0f1c9315ba50302cab68cda
Author: Thomas Gleixner
AuthorDate: Wed, 10 Apr 2019 12:28:10 +0200
Committer: Thomas Gleixner
CommitDate: Sun, 14 Apr 2019 19:58:32 +0200
tracing: Remove the ULONG_MAX stack trace hackery
No architecture terminates the stack trace with ULONG_MAX anymore. As the
code checks the number of entries stored anyway there is no point in
keeping all that ULONG_MAX magic around.
The histogram code zeroes the storage before saving the stack, so if the
trace is shorter than the maximum number of entries it can terminate the
print loop if a zero entry is detected.
Signed-off-by: Thomas Gleixner
Acked-by: Peter Zijlstra (Intel)
Cc: Josh Poimboeuf
Cc: Andy Lutomirski
Cc: Steven Rostedt
Cc: Alexander Potapenko
Link: https://lkml.kernel.org/r/20190410103645.048761...@linutronix.de
---
kernel/trace/trace_events_hist.c | 2 +-
kernel/trace/trace_stack.c | 20 +---
2 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c
index 795aa2038377..21ceae299f7e 100644
--- a/kernel/trace/trace_events_hist.c
+++ b/kernel/trace/trace_events_hist.c
@@ -5246,7 +5246,7 @@ static void hist_trigger_stacktrace_print(struct seq_file
*m,
unsigned int i;
for (i = 0; i < max_entries; i++) {
- if (stacktrace_entries[i] == ULONG_MAX)
+ if (!stacktrace_entries[i])
return;
seq_printf(m, "%*c", 1 + spaces, ' ');
diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
index eec648a0d673..c6e54ff25cae 100644
--- a/kernel/trace/trace_stack.c
+++ b/kernel/trace/trace_stack.c
@@ -18,8 +18,7 @@
#include "trace.h"
-static unsigned long stack_dump_trace[STACK_TRACE_ENTRIES+1] =
-{ [0 ... (STACK_TRACE_ENTRIES)] = ULONG_MAX };
+static unsigned long stack_dump_trace[STACK_TRACE_ENTRIES + 1];
unsigned stack_trace_index[STACK_TRACE_ENTRIES];
/*
@@ -52,10 +51,7 @@ void stack_trace_print(void)
stack_trace_max.nr_entries);
for (i = 0; i < stack_trace_max.nr_entries; i++) {
- if (stack_dump_trace[i] == ULONG_MAX)
- break;
- if (i+1 == stack_trace_max.nr_entries ||
- stack_dump_trace[i+1] == ULONG_MAX)
+ if (i + 1 == stack_trace_max.nr_entries)
size = stack_trace_index[i];
else
size = stack_trace_index[i] - stack_trace_index[i+1];
@@ -150,8 +146,6 @@ check_stack(unsigned long ip, unsigned long *stack)
p = start;
for (; p < top && i < stack_trace_max.nr_entries; p++) {
- if (stack_dump_trace[i] == ULONG_MAX)
- break;
/*
* The READ_ONCE_NOCHECK is used to let KASAN know that
* this is not a stack-out-of-bounds error.
@@ -183,8 +177,6 @@ check_stack(unsigned long ip, unsigned long *stack)
}
stack_trace_max.nr_entries = x;
- for (; x < i; x++)
- stack_dump_trace[x] = ULONG_MAX;
if (task_stack_end_corrupted(current)) {
stack_trace_print();
@@ -286,7 +278,7 @@ __next(struct seq_file *m, loff_t *pos)
{
long n = *pos - 1;
- if (n >= stack_trace_max.nr_entries || stack_dump_trace[n] == ULONG_MAX)
+ if (n >= stack_trace_max.nr_entries)
return NULL;
m->private = (void *)n;
@@ -360,12 +352,10 @@ static int t_show(struct seq_file *m, void *v)
i = *(long *)v;
- if (i >= stack_trace_max.nr_entries ||
- stack_dump_trace[i] == ULONG_MAX)
+ if (i >= stack_trace_max.nr_entries)
return 0;
- if (i+1 == stack_trace_max.nr_entries ||
- stack_dump_trace[i+1] == ULONG_MAX)
+ if (i + 1 == stack_trace_max.nr_entries)
size = stack_trace_index[i];
else
size = stack_trace_index[i] - stack_trace_index[i+1];
[tip:core/stacktrace] drm: Remove the ULONG_MAX stack trace hackery
Commit-ID: fa49e2eac9aa8259e1ea540d1bd301448d5b735d Gitweb: https://git.kernel.org/tip/fa49e2eac9aa8259e1ea540d1bd301448d5b735d Author: Thomas Gleixner AuthorDate: Wed, 10 Apr 2019 12:28:09 +0200 Committer: Thomas Gleixner CommitDate: Sun, 14 Apr 2019 19:58:32 +0200 drm: Remove the ULONG_MAX stack trace hackery No architecture terminates the stack trace with ULONG_MAX anymore. Remove the cruft. Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Cc: Josh Poimboeuf Cc: Andy Lutomirski Cc: Steven Rostedt Cc: Alexander Potapenko Cc: intel-...@lists.freedesktop.org Cc: Joonas Lahtinen Cc: Maarten Lankhorst Cc: dri-de...@lists.freedesktop.org Cc: David Airlie Cc: Jani Nikula Cc: Daniel Vetter Cc: Rodrigo Vivi Link: https://lkml.kernel.org/r/20190410103644.945059...@linutronix.de --- drivers/gpu/drm/drm_mm.c| 3 --- drivers/gpu/drm/i915/intel_runtime_pm.c | 4 2 files changed, 7 deletions(-) diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c index 2b4f373736c7..69552777e13a 100644 --- a/drivers/gpu/drm/drm_mm.c +++ b/drivers/gpu/drm/drm_mm.c @@ -113,9 +113,6 @@ static noinline void save_stack(struct drm_mm_node *node) }; save_stack_trace(&trace); - if (trace.nr_entries != 0 && - trace.entries[trace.nr_entries-1] == ULONG_MAX) - trace.nr_entries--; /* May be called under spinlock, so avoid sleeping */ node->stack = depot_save_stack(&trace, GFP_NOWAIT); diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c index a017a4232c0f..1f8acbb332c9 100644 --- a/drivers/gpu/drm/i915/intel_runtime_pm.c +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c @@ -67,10 +67,6 @@ static noinline depot_stack_handle_t __save_depot_stack(void) }; save_stack_trace(&trace); - if (trace.nr_entries && - trace.entries[trace.nr_entries - 1] == ULONG_MAX) - trace.nr_entries--; - return depot_save_stack(&trace, GFP_NOWAIT | __GFP_NOWARN); }
[tip:core/stacktrace] latency_top: Remove the ULONG_MAX stack trace hackery
Commit-ID: accddc41b96915ab4e5d37796c6d17d70805999c
Gitweb: https://git.kernel.org/tip/accddc41b96915ab4e5d37796c6d17d70805999c
Author: Thomas Gleixner
AuthorDate: Wed, 10 Apr 2019 12:28:08 +0200
Committer: Thomas Gleixner
CommitDate: Sun, 14 Apr 2019 19:58:31 +0200
latency_top: Remove the ULONG_MAX stack trace hackery
No architecture terminates the stack trace with ULONG_MAX anymore. The
consumer terminates on the first zero entry or at the number of entries, so
no functional change.
Remove the cruft.
Signed-off-by: Thomas Gleixner
Acked-by: Peter Zijlstra (Intel)
Cc: Josh Poimboeuf
Cc: Andy Lutomirski
Cc: Steven Rostedt
Cc: Alexander Potapenko
Link: https://lkml.kernel.org/r/20190410103644.853527...@linutronix.de
---
fs/proc/base.c | 3 +--
kernel/latencytop.c | 12 ++--
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 6a803a0b75df..5569f215fc54 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -489,10 +489,9 @@ static int lstats_show_proc(struct seq_file *m, void *v)
lr->count, lr->time, lr->max);
for (q = 0; q < LT_BACKTRACEDEPTH; q++) {
unsigned long bt = lr->backtrace[q];
+
if (!bt)
break;
- if (bt == ULONG_MAX)
- break;
seq_printf(m, " %ps", (void *)bt);
}
seq_putc(m, '\n');
diff --git a/kernel/latencytop.c b/kernel/latencytop.c
index 96b4179cee6a..f5a90ab3c6b9 100644
--- a/kernel/latencytop.c
+++ b/kernel/latencytop.c
@@ -120,8 +120,8 @@ account_global_scheduler_latency(struct task_struct *tsk,
break;
}
- /* 0 and ULONG_MAX entries mean end of backtrace: */
- if (record == 0 || record == ULONG_MAX)
+ /* 0 entry marks end of backtrace: */
+ if (!record)
break;
}
if (same) {
@@ -210,8 +210,8 @@ __account_scheduler_latency(struct task_struct *tsk, int
usecs, int inter)
break;
}
- /* 0 and ULONG_MAX entries mean end of backtrace: */
- if (record == 0 || record == ULONG_MAX)
+ /* 0 entry is end of backtrace */
+ if (!record)
break;
}
if (same) {
@@ -252,10 +252,10 @@ static int lstats_show(struct seq_file *m, void *v)
lr->count, lr->time, lr->max);
for (q = 0; q < LT_BACKTRACEDEPTH; q++) {
unsigned long bt = lr->backtrace[q];
+
if (!bt)
break;
- if (bt == ULONG_MAX)
- break;
+
seq_printf(m, " %ps", (void *)bt);
}
seq_puts(m, "\n");
[tip:core/stacktrace] mm/kasan: Remove the ULONG_MAX stack trace hackery
Commit-ID: ead97a49ec3a3cb9b5133acbfed9a49b91ebf37c Gitweb: https://git.kernel.org/tip/ead97a49ec3a3cb9b5133acbfed9a49b91ebf37c Author: Thomas Gleixner AuthorDate: Wed, 10 Apr 2019 12:28:07 +0200 Committer: Thomas Gleixner CommitDate: Sun, 14 Apr 2019 19:58:31 +0200 mm/kasan: Remove the ULONG_MAX stack trace hackery No architecture terminates the stack trace with ULONG_MAX anymore. Remove the cruft. Signed-off-by: Thomas Gleixner Acked-by: Dmitry Vyukov Acked-by: Peter Zijlstra (Intel) Cc: Josh Poimboeuf Cc: Andy Lutomirski Cc: Steven Rostedt Cc: Alexander Potapenko Cc: Andrey Ryabinin Cc: kasan-...@googlegroups.com Cc: linux...@kvack.org Link: https://lkml.kernel.org/r/20190410103644.750219...@linutronix.de --- mm/kasan/common.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/mm/kasan/common.c b/mm/kasan/common.c index 80bbe62b16cd..38e5f20a775a 100644 --- a/mm/kasan/common.c +++ b/mm/kasan/common.c @@ -74,9 +74,6 @@ static inline depot_stack_handle_t save_stack(gfp_t flags) save_stack_trace(&trace); filter_irq_stacks(&trace); - if (trace.nr_entries != 0 && - trace.entries[trace.nr_entries-1] == ULONG_MAX) - trace.nr_entries--; return depot_save_stack(&trace, flags); }
[tip:core/stacktrace] mm/page_owner: Remove the ULONG_MAX stack trace hackery
Commit-ID: 4621c9858f05ab08434221e3a15cc8098645ef2a Gitweb: https://git.kernel.org/tip/4621c9858f05ab08434221e3a15cc8098645ef2a Author: Thomas Gleixner AuthorDate: Wed, 10 Apr 2019 12:28:06 +0200 Committer: Thomas Gleixner CommitDate: Sun, 14 Apr 2019 19:58:30 +0200 mm/page_owner: Remove the ULONG_MAX stack trace hackery No architecture terminates the stack trace with ULONG_MAX anymore. Remove the cruft. Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Cc: Josh Poimboeuf Cc: Andy Lutomirski Cc: Steven Rostedt Cc: Alexander Potapenko Cc: Michal Hocko Cc: linux...@kvack.org Cc: Mike Rapoport Cc: Andrew Morton Link: https://lkml.kernel.org/r/20190410103644.661974...@linutronix.de --- mm/page_owner.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/mm/page_owner.c b/mm/page_owner.c index 925b6f44a444..df277e6bc3c6 100644 --- a/mm/page_owner.c +++ b/mm/page_owner.c @@ -148,9 +148,6 @@ static noinline depot_stack_handle_t save_stack(gfp_t flags) depot_stack_handle_t handle; save_stack_trace(&trace); - if (trace.nr_entries != 0 && - trace.entries[trace.nr_entries-1] == ULONG_MAX) - trace.nr_entries--; /* * We need to check recursion here because our request to stackdepot
[tip:core/stacktrace] mm/slub: Remove the ULONG_MAX stack trace hackery
Commit-ID: b8ca7ff7731f57b256fcc13a9b7d4913f5282e5c
Gitweb: https://git.kernel.org/tip/b8ca7ff7731f57b256fcc13a9b7d4913f5282e5c
Author: Thomas Gleixner
AuthorDate: Wed, 10 Apr 2019 12:28:05 +0200
Committer: Thomas Gleixner
CommitDate: Sun, 14 Apr 2019 19:58:30 +0200
mm/slub: Remove the ULONG_MAX stack trace hackery
No architecture terminates the stack trace with ULONG_MAX anymore. Remove
the cruft.
While at it remove the pointless loop of clearing the stack array
completely. It's sufficient to clear the last entry as the consumers break
out on the first zeroed entry anyway.
Signed-off-by: Thomas Gleixner
Acked-by: Peter Zijlstra (Intel)
Cc: Josh Poimboeuf
Cc: Andy Lutomirski
Cc: Steven Rostedt
Cc: Alexander Potapenko
Cc: Andrew Morton
Cc: Pekka Enberg
Cc: linux...@kvack.org
Cc: David Rientjes
Cc: Christoph Lameter
Link: https://lkml.kernel.org/r/20190410103644.574058...@linutronix.de
---
mm/slub.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
index d30ede89f4a6..e2ccd12b6faa 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -553,7 +553,6 @@ static void set_track(struct kmem_cache *s, void *object,
if (addr) {
#ifdef CONFIG_STACKTRACE
struct stack_trace trace;
- int i;
trace.nr_entries = 0;
trace.max_entries = TRACK_ADDRS_COUNT;
@@ -563,20 +562,16 @@ static void set_track(struct kmem_cache *s, void *object,
save_stack_trace(&trace);
metadata_access_disable();
- /* See rant in lockdep.c */
- if (trace.nr_entries != 0 &&
- trace.entries[trace.nr_entries - 1] == ULONG_MAX)
- trace.nr_entries--;
-
- for (i = trace.nr_entries; i < TRACK_ADDRS_COUNT; i++)
- p->addrs[i] = 0;
+ if (trace.nr_entries < TRACK_ADDRS_COUNT)
+ p->addrs[trace.nr_entries] = 0;
#endif
p->addr = addr;
p->cpu = smp_processor_id();
p->pid = current->pid;
p->when = jiffies;
- } else
+ } else {
memset(p, 0, sizeof(struct track));
+ }
}
static void init_tracking(struct kmem_cache *s, void *object)
[tip:core/stacktrace] s390/stacktrace: Remove the pointless ULONG_MAX marker
Commit-ID: 6a28b4c2d93b812512d8d2e5179e61a14f578560 Gitweb: https://git.kernel.org/tip/6a28b4c2d93b812512d8d2e5179e61a14f578560 Author: Thomas Gleixner AuthorDate: Wed, 10 Apr 2019 12:28:03 +0200 Committer: Thomas Gleixner CommitDate: Sun, 14 Apr 2019 19:58:29 +0200 s390/stacktrace: Remove the pointless ULONG_MAX marker Terminating the last trace entry with ULONG_MAX is a completely pointless exercise and none of the consumers can rely on it because it's inconsistently implemented across architectures. In fact quite some of the callers remove the entry and adjust stack_trace.nr_entries afterwards. Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Cc: Josh Poimboeuf Cc: Andy Lutomirski Cc: Steven Rostedt Cc: Alexander Potapenko Cc: Martin Schwidefsky Cc: linux-s...@vger.kernel.org Cc: Heiko Carstens Link: https://lkml.kernel.org/r/20190410103644.396788...@linutronix.de --- arch/s390/kernel/stacktrace.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/arch/s390/kernel/stacktrace.c b/arch/s390/kernel/stacktrace.c index 460dcfba7d4e..cc9ed9787068 100644 --- a/arch/s390/kernel/stacktrace.c +++ b/arch/s390/kernel/stacktrace.c @@ -45,8 +45,6 @@ void save_stack_trace(struct stack_trace *trace) sp = current_stack_pointer(); dump_trace(save_address, trace, NULL, sp); - if (trace->nr_entries < trace->max_entries) - trace->entries[trace->nr_entries++] = ULONG_MAX; } EXPORT_SYMBOL_GPL(save_stack_trace); @@ -58,8 +56,6 @@ void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace) if (tsk == current) sp = current_stack_pointer(); dump_trace(save_address_nosched, trace, tsk, sp); - if (trace->nr_entries < trace->max_entries) - trace->entries[trace->nr_entries++] = ULONG_MAX; } EXPORT_SYMBOL_GPL(save_stack_trace_tsk); @@ -69,7 +65,5 @@ void save_stack_trace_regs(struct pt_regs *regs, struct stack_trace *trace) sp = kernel_stack_pointer(regs); dump_trace(save_address, trace, NULL, sp); - if (trace->nr_entries < trace->max_entries) - trace->entries[trace->nr_entries++] = ULONG_MAX; } EXPORT_SYMBOL_GPL(save_stack_trace_regs);
[tip:core/stacktrace] parisc/stacktrace: Remove the pointless ULONG_MAX marker
Commit-ID: 4f3bd6ca310b594df09c8f1e319cda9baf502ec8
Gitweb: https://git.kernel.org/tip/4f3bd6ca310b594df09c8f1e319cda9baf502ec8
Author: Thomas Gleixner
AuthorDate: Wed, 10 Apr 2019 12:28:02 +0200
Committer: Thomas Gleixner
CommitDate: Sun, 14 Apr 2019 19:58:29 +0200
parisc/stacktrace: Remove the pointless ULONG_MAX marker
Terminating the last trace entry with ULONG_MAX is a completely pointless
exercise and none of the consumers can rely on it because it's
inconsistently implemented across architectures. In fact quite some of the
callers remove the entry and adjust stack_trace.nr_entries afterwards.
Signed-off-by: Thomas Gleixner
Acked-by: Peter Zijlstra (Intel)
Cc: Josh Poimboeuf
Cc: Andy Lutomirski
Cc: Steven Rostedt
Cc: Alexander Potapenko
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: linux-par...@vger.kernel.org
Link: https://lkml.kernel.org/r/20190410103644.308534...@linutronix.de
---
arch/parisc/kernel/stacktrace.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/parisc/kernel/stacktrace.c b/arch/parisc/kernel/stacktrace.c
index ec5835e83a7a..6f0b9c8d8052 100644
--- a/arch/parisc/kernel/stacktrace.c
+++ b/arch/parisc/kernel/stacktrace.c
@@ -29,22 +29,17 @@ static void dump_trace(struct task_struct *task, struct
stack_trace *trace)
}
}
-
/*
* Save stack-backtrace addresses into a stack_trace buffer.
*/
void save_stack_trace(struct stack_trace *trace)
{
dump_trace(current, trace);
- if (trace->nr_entries < trace->max_entries)
- trace->entries[trace->nr_entries++] = ULONG_MAX;
}
EXPORT_SYMBOL_GPL(save_stack_trace);
void save_stack_trace_tsk(struct task_struct *tsk, struct stack_trace *trace)
{
dump_trace(tsk, trace);
- if (trace->nr_entries < trace->max_entries)
- trace->entries[trace->nr_entries++] = ULONG_MAX;
}
EXPORT_SYMBOL_GPL(save_stack_trace_tsk);
[tip:core/stacktrace] lockdep: Remove the ULONG_MAX stack trace hackery
Commit-ID: 2dfed4565afe263751d2451ad22336ad806c25a6 Gitweb: https://git.kernel.org/tip/2dfed4565afe263751d2451ad22336ad806c25a6 Author: Thomas Gleixner AuthorDate: Wed, 10 Apr 2019 12:28:04 +0200 Committer: Thomas Gleixner CommitDate: Sun, 14 Apr 2019 19:58:30 +0200 lockdep: Remove the ULONG_MAX stack trace hackery No architecture terminates the stack trace with ULONG_MAX anymore. Remove the cruft. Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Cc: Josh Poimboeuf Cc: Andy Lutomirski Cc: Steven Rostedt Cc: Alexander Potapenko Cc: Will Deacon Link: https://lkml.kernel.org/r/20190410103644.485737...@linutronix.de --- kernel/locking/lockdep.c | 11 --- 1 file changed, 11 deletions(-) diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index e16766ff184b..2edf9501d906 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -444,17 +444,6 @@ static int save_trace(struct stack_trace *trace) save_stack_trace(trace); - /* -* Some daft arches put -1 at the end to indicate its a full trace. -* -* this is buggy anyway, since it takes a whole extra entry so a -* complete trace that maxes out the entries provided will be reported -* as incomplete, friggin useless -*/ - if (trace->nr_entries != 0 && - trace->entries[trace->nr_entries-1] == ULONG_MAX) - trace->nr_entries--; - trace->max_entries = trace->nr_entries; nr_stack_trace_entries += trace->nr_entries;
[tip:core/stacktrace] arm64/stacktrace: Remove the pointless ULONG_MAX marker
Commit-ID: 7b2c7b6233497bfab8826ece574bc1c26e97478d Gitweb: https://git.kernel.org/tip/7b2c7b6233497bfab8826ece574bc1c26e97478d Author: Thomas Gleixner AuthorDate: Wed, 10 Apr 2019 12:28:01 +0200 Committer: Thomas Gleixner CommitDate: Sun, 14 Apr 2019 19:58:29 +0200 arm64/stacktrace: Remove the pointless ULONG_MAX marker Terminating the last trace entry with ULONG_MAX is a completely pointless exercise and none of the consumers can rely on it because it's inconsistently implemented across architectures. In fact quite some of the callers remove the entry and adjust stack_trace.nr_entries afterwards. Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Cc: Josh Poimboeuf Cc: Andy Lutomirski Cc: Steven Rostedt Cc: Alexander Potapenko Cc: Catalin Marinas Cc: Will Deacon Cc: linux-arm-ker...@lists.infradead.org Link: https://lkml.kernel.org/r/20190410103644.220247...@linutronix.de --- arch/arm64/kernel/stacktrace.c | 4 1 file changed, 4 deletions(-) diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c index d908b5e9e949..b00ec7d483d1 100644 --- a/arch/arm64/kernel/stacktrace.c +++ b/arch/arm64/kernel/stacktrace.c @@ -140,8 +140,6 @@ void save_stack_trace_regs(struct pt_regs *regs, struct stack_trace *trace) #endif walk_stackframe(current, &frame, save_trace, &data); - if (trace->nr_entries < trace->max_entries) - trace->entries[trace->nr_entries++] = ULONG_MAX; } EXPORT_SYMBOL_GPL(save_stack_trace_regs); @@ -172,8 +170,6 @@ static noinline void __save_stack_trace(struct task_struct *tsk, #endif walk_stackframe(tsk, &frame, save_trace, &data); - if (trace->nr_entries < trace->max_entries) - trace->entries[trace->nr_entries++] = ULONG_MAX; put_task_stack(tsk); }
