Re: [PATCH 1/2] arm64: dts: imx8mq: Correct OPP table according to latest datasheet
On 28.06.2019 06:37, anson.hu...@nxp.com wrote: > From: Anson Huang > > According to latest datasheet (Rev.1, 10/2018) from below links, > in the consumer datasheet, 1.5GHz is mentioned as highest opp but > depends on speed grading fuse, and in the industrial datasheet, > 1.3GHz is mentioned as highest opp but depends on speed grading > fuse. 1.5GHz and 1.3GHz opp use same voltage, so no need for > consumer part to support 1.3GHz opp, with same voltage, CPU should > run at highest frequency in order to go into idle as quick as > possible, this can save power. I looked at the same datasheets and it's not clear to me that 1.3 Ghz should be disallowed for consumer parts. Power consumption increases with both voltage and frequency so having two OPPs with same voltage does make sense. > opp-hz = /bits/ 64 <13>; > opp-microvolt = <100>; > - opp-supported-hw = <0xc>, <0x7>; > + /* Industrial only but rely on speed grading */ > + opp-supported-hw = <0xc>, <0x4>; Comment is false, you're explicitly excluding consumer parts via the second element. > opp-hz = /bits/ 64 <15>; > opp-microvolt = <100>; > /* Consumer only but rely on speed grading */ > - opp-supported-hw = <0x8>, <0x7>; > + opp-supported-hw = <0x8>, <0x3>; If you don't want to rely on the fact that only consumer parts should be fused for 1.5 Ghz then please delete the comment.
Re: [PATCH 1/2] lib/genalloc.c: Add algorithm, align and zeroed family of DMA allocators
Thanks, I've added both patches to the dma-mapping for-next tree.
Re: [PATCH 07/13] xfs: allow merging ioends over append boundaries
On Thu, Jun 27, 2019 at 11:23:09AM -0700, Darrick J. Wong wrote: > On Thu, Jun 27, 2019 at 12:48:30PM +0200, Christoph Hellwig wrote: > > There is no real problem merging ioends that go beyond i_size into an > > ioend that doesn't. We just need to move the append transaction to the > > base ioend. Also use the opportunity to use a real error code instead > > of the magic 1 to cancel the transactions, and write a comment > > explaining the scheme. > > > > Signed-off-by: Christoph Hellwig > > Reading through this patch, I have a feeling it fixes the crash that > Zorro has been seeing occasionally with generic/475... So you think for some reason the disk i_size changes underneath and thus the xfs_ioend_is_append misfired vs the actual transaction allocations? I didn't even think of that, but using the different checks sure sounds dangerous. So yes, we'd either need to backport my patch, or at least replace the checks in xfs_ioend_can_merge with direct checks of io_append_trans.
Re: [PATCH v3 1/3] x86: Move DEBUG_TLBFLUSH option.
On Mon, 29 Apr 2019, Atish Patra wrote:
> CONFIG_DEBUG_TLBFLUSH was added in
>
> 'commit 3df3212f9722 ("x86/tlb: add tlb_flushall_shift knob into debugfs")'
> to support tlb_flushall_shift knob. The knob was removed in
>
> 'commit e9f4e0a9fe27 ("x86/mm: Rip out complicated, out-of-date, buggy
> TLB flushing")'.
> However, the debug option was never removed from Kconfig. It was reused
> in commit
>
> '9824cf9753ec ("mm: vmstats: tlb flush counters")'
> but the commit text was never updated accordingly.
>
> Update the Kconfig option description as per its current usage.
>
> Take this opportunity to make this kconfig option a common option as it
> touches the common vmstat code. Introduce another arch specific config
> HAVE_ARCH_DEBUG_TLBFLUSH that can be selected to enable this config.
Looks like this one still needs to be merged or acked by one of the x86
maintainers?
- Paul
Re: [PATCH v3 3/3] RISC-V: Update tlb flush counters
On Mon, 29 Apr 2019, Atish Patra wrote: > The TLB flush counters under vmstat seems to be very helpful while > debugging TLB flush performance in RISC-V. > > Update the counters in every TLB flush methods respectively. > > Signed-off-by: Atish Patra This one doesn't apply any longer. Care to update and repost? - Paul
Re: [RFC PATCH v3 0/4] Deliver vGPU display vblank event to userspace
On Fri, Jun 28, 2019 at 11:21:49AM +0800, Zhenyu Wang wrote: > On 2019.06.27 12:31:33 +0200, Gerd Hoffmann wrote: > > > > Hi, > > > > > > > > > Instead of delivering page flip events, we choose to post display > > > > > vblank event. Handling page flip events for both primary plane and > > > > > cursor plane may make user space quite busy, although we have the > > > > > mask/unmask mechansim for mitigation. Besides, there are some cases > > > > > that guest app only uses one framebuffer for both drawing and display. > > > > > In such case, guest OS won't do the plane page flip when the > > > > > framebuffer is updated, thus the user land won't be notified about the > > > > updated framebuffer. > > > > > > > > What happens when the guest is idle and doesn't draw anything to the > > > > framebuffer? > > > The vblank event will be delivered to userspace as well, unless guest OS > > > disable the pipe. > > > Does it make sense to vfio/display? > > > > Getting notified only in case there are actual display updates would be > > a nice optimization, assuming the hardware is able to do that. If the > > guest pageflips this is obviously trivial. Not sure this is possible in > > case the guest renders directly to the frontbuffer. > > > > What exactly happens when the guest OS disables the pipe? Is a vblank > > event delivered at least once? That would be very useful because it > > will be possible for userspace to stop polling altogether without > > missing the "guest disabled pipe" event. > > > > It looks like purpose to use vblank here is to replace user space > polling totally by kernel event? Which just act as display update > event to replace user space timer to make it query and update > planes? I think it makes sense to design it that way, so userspace will either use the events (when supported by the driver) or a timer (fallback if not) but not both. > Although in theory vblank is not appropriate for this which > doesn't align with plane update or possible front buffer rendering at > all, but looks it's just a compromise e.g not sending event for every > cursor position change, etc. > > I think we need to define semantics for this event properly, e.g user > space purely depends on this event for display update, the opportunity > for issuing this event is controlled by driver when it's necessary for > update, etc. Definitely not named as vblank event or only issue at vblank, > that need to happen for other plane change too. I think it should be "display update notification", i.e. userspace should check for plane changes and update the display. Most events will probably come from vblank (typically plane update are actually committed at vblank time to avoid tearing, right?). That is an implementation detail though. cheers, Gerd
Re: [PATCH V2] soc: imx-scu: Add SoC UID(unique identifier) support
On Fri, Jun 28, 2019 at 6:36 AM wrote: > > From: Anson Huang > > Add i.MX SCU SoC's UID(unique identifier) support, user > can read it from sysfs: > > root@imx8qxpmek:~# cat /sys/devices/soc0/soc_uid > 7B64280B57AC1898 > > Signed-off-by: Anson Huang Reviewed-by: Daniel Baluta
Re: lift the xfs writepage code into iomap v2
On Thu, Jun 27, 2019 at 06:32:56PM -0700, Darrick J. Wong wrote: > I think Dave has voiced some valid concerns about our ability to support > this code over the long term once we start sharing it with other fses. > XFS has a longish history of sailing away from generic code so that we > can remove awkward abstractions which aren't working well for us. If > we're going to continue to go our own way with things like file locking > and mapping I wonder how long we'd keep using the iomap ioends before > moving away again. How well will that iomap code avoid bitrot once XFS > does that? As outlied in my mail to Dave I agree with the high level issue. But I very much thing that the writeback code is and should be generic. For one it is much more tightly integrated with other iomap code than with XFS. And second the kernel doesn't have a sane generic writeback implementation. We have like three different crappy buffer head ones, and anyone wanting to sanely implement writeback currently has to write their own, which is a major PITA. > How does that sound? Who are the other potential users? The immediate current user is Damiens zonefs, which is just a thin abstraction on top of zones in zoned block devices. Then my plan has always been to convert gfs2 over to it, away from buffer heads. With btrfs now joining iomap land I'd be really excited to move it over, but we'll see how feasily that is. But with gfs2 done I think we also are ready to convert anything currently using plain old buffer heads over, so things like sysvfs, minix, jfs, etc. While that isn't a priority and will take a while it will help with my grand overall scheme of killing buffer_heads, at least for the data path.
Re: [PATCH v2 19/27] staging: rtl8*: use zeroing allocator rather than allocator followed with memset 0
On Fri, 28 Jun 2019, Fuqian Huang wrote:
> Use zeroing allocator rather than allocator followed with memset 0.
Maybe it would be better to just change these to the appropriate kmalloc
and kzalloc calls.
You will need to check on whether locks are held to know whether the secon
argument should be GFP_ATOMIC or GFP_KERNEL. The current code doesn't
address this issue in a correct manner.
You may also want to add some options to your get_maintainer call to not
send patches to everyone who has ever worked on the driver.
julia
>
> Signed-off-by: Fuqian Huang
> ---
> drivers/staging/rtl8188eu/os_dep/mlme_linux.c | 3 +--
> drivers/staging/rtl8712/rtl871x_io.c | 4 +---
> drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 8 ++--
> drivers/staging/rtl8723bs/os_dep/ioctl_linux.c| 12 +++-
> 4 files changed, 7 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/staging/rtl8188eu/os_dep/mlme_linux.c
> b/drivers/staging/rtl8188eu/os_dep/mlme_linux.c
> index 9db11b16cb93..250acb01d1a9 100644
> --- a/drivers/staging/rtl8188eu/os_dep/mlme_linux.c
> +++ b/drivers/staging/rtl8188eu/os_dep/mlme_linux.c
> @@ -98,10 +98,9 @@ void rtw_report_sec_ie(struct adapter *adapter, u8
> authmode, u8 *sec_ie)
> if (authmode == _WPA_IE_ID_) {
> RT_TRACE(_module_mlme_osdep_c_, _drv_info_,
>("rtw_report_sec_ie, authmode=%d\n", authmode));
> - buff = rtw_malloc(IW_CUSTOM_MAX);
> + buff = rtw_zmalloc(IW_CUSTOM_MAX);
> if (!buff)
> return;
> - memset(buff, 0, IW_CUSTOM_MAX);
> p = buff;
> p += sprintf(p, "ASSOCINFO(ReqIEs =");
> len = sec_ie[1] + 2;
> diff --git a/drivers/staging/rtl8712/rtl871x_io.c
> b/drivers/staging/rtl8712/rtl871x_io.c
> index 17dafeffd6f4..87024d6a465e 100644
> --- a/drivers/staging/rtl8712/rtl871x_io.c
> +++ b/drivers/staging/rtl8712/rtl871x_io.c
> @@ -107,13 +107,11 @@ uint r8712_alloc_io_queue(struct _adapter *adapter)
> INIT_LIST_HEAD(_queue->processing);
> INIT_LIST_HEAD(_queue->pending);
> spin_lock_init(_queue->lock);
> - pio_queue->pallocated_free_ioreqs_buf = kmalloc(NUM_IOREQ *
> + pio_queue->pallocated_free_ioreqs_buf = kzalloc(NUM_IOREQ *
> (sizeof(struct io_req)) + 4,
> GFP_ATOMIC);
> if ((pio_queue->pallocated_free_ioreqs_buf) == NULL)
> goto alloc_io_queue_fail;
> - memset(pio_queue->pallocated_free_ioreqs_buf, 0,
> - (NUM_IOREQ * (sizeof(struct io_req)) + 4));
> pio_queue->free_ioreqs_buf = pio_queue->pallocated_free_ioreqs_buf + 4
> - ((addr_t)(pio_queue->pallocated_free_ioreqs_buf)
> & 3);
> diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
> b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
> index db553f2e4c0b..f8e0723f5d1f 100644
> --- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
> +++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
> @@ -1078,12 +1078,10 @@ static int cfg80211_rtw_add_key(struct wiphy *wiphy,
> struct net_device *ndev,
> DBG_871X("pairwise =%d\n", pairwise);
>
> param_len = sizeof(struct ieee_param) + params->key_len;
> - param = rtw_malloc(param_len);
> + param = rtw_zmalloc(param_len);
> if (param == NULL)
> return -1;
>
> - memset(param, 0, param_len);
> -
> param->cmd = IEEE_CMD_SET_ENCRYPTION;
> memset(param->sta_addr, 0xff, ETH_ALEN);
>
> @@ -2167,15 +2165,13 @@ static int cfg80211_rtw_connect(struct wiphy *wiphy,
> struct net_device *ndev,
> {
> wep_key_len = wep_key_len <= 5 ? 5 : 13;
> wep_total_len = wep_key_len + FIELD_OFFSET(struct
> ndis_802_11_wep, KeyMaterial);
> - pwep = rtw_malloc(wep_total_len);
> + pwep = rtw_zmalloc(wep_total_len);
> if (pwep == NULL) {
> DBG_871X(" wpa_set_encryption: pwep allocate
> fail !!!\n");
> ret = -ENOMEM;
> goto exit;
> }
>
> - memset(pwep, 0, wep_total_len);
> -
> pwep->KeyLength = wep_key_len;
> pwep->Length = wep_total_len;
>
> diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
> b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
> index e3d356952875..1491d420929c 100644
> --- a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
> +++ b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
> @@ -478,14 +478,12 @@ static int wpa_set_encryption(struct net_device *dev,
> struct ieee_param *param,
> if (wep_key_len > 0) {
> wep_key_len = wep_key_len <= 5 ? 5 : 13;
> wep_total_len =
Re: [PATCH 1/4] tracing: Simplify assignment parsing for hist triggers
On Thu, 27 Jun 2019 10:35:16 -0500
Tom Zanussi wrote:
> In the process of adding better error messages for sorting, I realized
> that strsep was being used incorrectly and some of the error paths I
> was expecting to be hit weren't and just fell through to the common
> invalid key error case.
Would you mean this includes a bugfix too?
>
> It also became obvious that for keyword assignments, it wasn't
> necessary to save the full assignment and reparse it later, and having
> a common empty-assignment check would also make more sense in terms of
> error processing.
>
> Change the code to fix these problems and simplify it for new error
> message changes in a subsequent patch.
>
> Signed-off-by: Tom Zanussi
Anyway looks good to me.
Reviewed-by: Masami Hiramatsu
Thanks,
> ---
> kernel/trace/trace_events_hist.c | 70
>
> 1 file changed, 27 insertions(+), 43 deletions(-)
>
> diff --git a/kernel/trace/trace_events_hist.c
> b/kernel/trace/trace_events_hist.c
> index ca6b0dff60c5..964d032f51c6 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -1985,12 +1985,6 @@ static int parse_map_size(char *str)
> unsigned long size, map_bits;
> int ret;
>
> - strsep(, "=");
> - if (!str) {
> - ret = -EINVAL;
> - goto out;
> - }
> -
> ret = kstrtoul(str, 0, );
> if (ret)
> goto out;
> @@ -2050,25 +2044,25 @@ static int parse_action(char *str, struct
> hist_trigger_attrs *attrs)
> static int parse_assignment(struct trace_array *tr,
> char *str, struct hist_trigger_attrs *attrs)
> {
> - int ret = 0;
> + int len, ret = 0;
>
> - if ((str_has_prefix(str, "key=")) ||
> - (str_has_prefix(str, "keys="))) {
> - attrs->keys_str = kstrdup(str, GFP_KERNEL);
> + if ((len = str_has_prefix(str, "key=")) ||
> + (len = str_has_prefix(str, "keys="))) {
> + attrs->keys_str = kstrdup(str + len, GFP_KERNEL);
> if (!attrs->keys_str) {
> ret = -ENOMEM;
> goto out;
> }
> - } else if ((str_has_prefix(str, "val=")) ||
> -(str_has_prefix(str, "vals=")) ||
> -(str_has_prefix(str, "values="))) {
> - attrs->vals_str = kstrdup(str, GFP_KERNEL);
> + } else if ((len = str_has_prefix(str, "val=")) ||
> +(len = str_has_prefix(str, "vals=")) ||
> +(len = str_has_prefix(str, "values="))) {
> + attrs->vals_str = kstrdup(str + len, GFP_KERNEL);
> if (!attrs->vals_str) {
> ret = -ENOMEM;
> goto out;
> }
> - } else if (str_has_prefix(str, "sort=")) {
> - attrs->sort_key_str = kstrdup(str, GFP_KERNEL);
> + } else if ((len = str_has_prefix(str, "sort="))) {
> + attrs->sort_key_str = kstrdup(str + len, GFP_KERNEL);
> if (!attrs->sort_key_str) {
> ret = -ENOMEM;
> goto out;
> @@ -2079,12 +2073,8 @@ static int parse_assignment(struct trace_array *tr,
> ret = -ENOMEM;
> goto out;
> }
> - } else if (str_has_prefix(str, "clock=")) {
> - strsep(, "=");
> - if (!str) {
> - ret = -EINVAL;
> - goto out;
> - }
> + } else if ((len = str_has_prefix(str, "clock="))) {
> + str += len;
>
> str = strstrip(str);
> attrs->clock = kstrdup(str, GFP_KERNEL);
> @@ -2092,8 +2082,8 @@ static int parse_assignment(struct trace_array *tr,
> ret = -ENOMEM;
> goto out;
> }
> - } else if (str_has_prefix(str, "size=")) {
> - int map_bits = parse_map_size(str);
> + } else if ((len = str_has_prefix(str, "size="))) {
> + int map_bits = parse_map_size(str + len);
>
> if (map_bits < 0) {
> ret = map_bits;
> @@ -2133,8 +2123,14 @@ parse_hist_trigger_attrs(struct trace_array *tr, char
> *trigger_str)
>
> while (trigger_str) {
> char *str = strsep(_str, ":");
> + char *rhs;
>
> - if (strchr(str, '=')) {
> + rhs = strchr(str, '=');
> + if (rhs) {
> + if (!strlen(++rhs)) {
> + ret = -EINVAL;
> + goto free;
> + }
> ret = parse_assignment(tr, str, attrs);
> if (ret)
> goto free;
> @@ -4459,10 +4455,6 @@ static int create_val_fields(struct hist_trigger_data
> *hist_data,
> if (!fields_str)
> goto out;
>
> - strsep(_str, "=");
> - if (!fields_str)
> -
Re: [PATCH 2/2] drivers/perf: Add CCPI2 PMU support in ThunderX2 UNCORE driver.
Hi will,
On Thu, Jun 27, 2019 at 3:27 PM Will Deacon wrote:
>
> Hi Ganapat,
>
> On Fri, Jun 14, 2019 at 05:42:46PM +, Ganapatrao Kulkarni wrote:
> > CCPI2 is a low-latency high-bandwidth serial interface for connecting
> > ThunderX2 processors. This patch adds support to capture CCPI2 perf events.
> >
> > Signed-off-by: Ganapatrao Kulkarni
> > ---
> > drivers/perf/thunderx2_pmu.c | 179 ++-
> > 1 file changed, 157 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/perf/thunderx2_pmu.c b/drivers/perf/thunderx2_pmu.c
> > index 43d76c85da56..3791ac9b897d 100644
> > --- a/drivers/perf/thunderx2_pmu.c
> > +++ b/drivers/perf/thunderx2_pmu.c
> > @@ -16,7 +16,9 @@
> > * they need to be sampled before overflow(i.e, at every 2 seconds).
> > */
> >
> > -#define TX2_PMU_MAX_COUNTERS 4
> > +#define TX2_PMU_DMC_L3C_MAX_COUNTERS 4
>
> I find it odd that you rename this...
i am not sure, how to avoid this since dmc/l3c have 4 counters and ccpi2 has 8.
i will try to make this better in v2.
>
> > +#define TX2_PMU_CCPI2_MAX_COUNTERS 8
> > +
> > #define TX2_PMU_DMC_CHANNELS 8
> > #define TX2_PMU_L3_TILES 16
> >
> > @@ -28,11 +30,22 @@
> >*/
> > #define DMC_EVENT_CFG(idx, val) ((val) << (((idx) * 8) + 1))
> >
> > +#define GET_EVENTID_CCPI2(ev)((ev->hw.config) & 0x1ff)
> > +/* bits[3:0] to select counters, starts from 8, bit[3] set always. */
> > +#define GET_COUNTERID_CCPI2(ev) ((ev->hw.idx) & 0x7)
> > +#define CCPI2_COUNTER_OFFSET 8
>
>
> ... but leave GET_EVENTID alone, even though it only applies to DMC/L3C
> events. Saying that, if you have the event you can figure out its type,
> so could you avoid the need for additional macros entirely and just use
> the correct masks based on the corresponding PMU type? That might also
> avoid some of the conditional control flow you're introducing elsewhere.
sure, i will add mask as argument to macro.
>
> > #define L3C_COUNTER_CTL 0xA8
> > #define L3C_COUNTER_DATA 0xAC
> > #define DMC_COUNTER_CTL 0x234
> > #define DMC_COUNTER_DATA 0x240
> >
> > +#define CCPI2_PERF_CTL 0x108
> > +#define CCPI2_COUNTER_CTL0x10C
> > +#define CCPI2_COUNTER_SEL0x12c
> > +#define CCPI2_COUNTER_DATA_L 0x130
> > +#define CCPI2_COUNTER_DATA_H 0x134
> > +
> > /* L3C event IDs */
> > #define L3_EVENT_READ_REQ0xD
> > #define L3_EVENT_WRITEBACK_REQ 0xE
> > @@ -51,9 +64,16 @@
> > #define DMC_EVENT_READ_TXNS 0xF
> > #define DMC_EVENT_MAX0x10
> >
> > +#define CCPI2_EVENT_REQ_PKT_SENT 0x3D
> > +#define CCPI2_EVENT_SNOOP_PKT_SENT 0x65
> > +#define CCPI2_EVENT_DATA_PKT_SENT0x105
> > +#define CCPI2_EVENT_GIC_PKT_SENT 0x12D
> > +#define CCPI2_EVENT_MAX 0x200
> > +
> > enum tx2_uncore_type {
> > PMU_TYPE_L3C,
> > PMU_TYPE_DMC,
> > + PMU_TYPE_CCPI2,
> > PMU_TYPE_INVALID,
> > };
> >
> > @@ -73,8 +93,8 @@ struct tx2_uncore_pmu {
> > u32 max_events;
> > u64 hrtimer_interval;
> > void __iomem *base;
> > - DECLARE_BITMAP(active_counters, TX2_PMU_MAX_COUNTERS);
> > - struct perf_event *events[TX2_PMU_MAX_COUNTERS];
> > + DECLARE_BITMAP(active_counters, TX2_PMU_CCPI2_MAX_COUNTERS);
> > + struct perf_event *events[TX2_PMU_DMC_L3C_MAX_COUNTERS];
>
> Hmm, that looks very odd. Why are they now different sizes?
events[ ] is used to hold reference to active events to use in timer
callback, which is not applicable to ccpi2, hence 4.
active_counters is set to max of both. i.e, 8. i will try to make it
better readable in v2.
>
> > struct device *dev;
> > struct hrtimer hrtimer;
> > const struct attribute_group **attr_groups;
> > @@ -92,7 +112,21 @@ static inline struct tx2_uncore_pmu
> > *pmu_to_tx2_pmu(struct pmu *pmu)
> > return container_of(pmu, struct tx2_uncore_pmu, pmu);
> > }
> >
> > -PMU_FORMAT_ATTR(event, "config:0-4");
> > +#define TX2_PMU_FORMAT_ATTR(_var, _name, _format)\
> > +static ssize_t
> > \
> > +__tx2_pmu_##_var##_show(struct device *dev, \
> > +struct device_attribute *attr, \
> > +char *page) \
> > +{\
> > + BUILD_BUG_ON(sizeof(_format) >= PAGE_SIZE); \
> > + return sprintf(page, _format "\n"); \
> > +}\
> > + \
> > +static struct device_attribute format_attr_##_var = \
> > +
Re: [PATCH 06/13] xfs: remove XFS_TRANS_NOFS
On Thu, Jun 27, 2019 at 03:30:30PM -0700, Darrick J. Wong wrote:
> I think the wording of this is too indirect. The reason we need to set
> NOFS is because we could be doing writeback as part of reclaiming
> memory, which means that we cannot recurse back into filesystems to
> satisfy the memory allocation needed to create a transaction. The NOFS
> part applies to any memory allocation, of course.
>
> If you're fine with the wording below I'll just edit that into the
> patch:
>
> /*
>* We can allocate memory here while doing writeback on behalf of
>* memory reclaim. To avoid memory allocation deadlocks set the
>* task-wide nofs context for the following operations.
>*/
> nofs_flag = memalloc_nofs_save();
Fine with me.
> > trace_xfs_end_io_direct_write(ip, offset, size);
> > @@ -395,10 +396,11 @@ xfs_dio_write_end_io(
> > */
> > XFS_STATS_ADD(ip->i_mount, xs_write_bytes, size);
> >
> > + nofs_flag = memalloc_nofs_save();
>
> Hmm, do we need this here? I can't remember if there was a need for
> setting NOFS under xfs_reflink_end_cow from a dio completion or if that
> was purely the buffered writeback case...
We certainly had to add it for the unwritten extent conversion, maybe
the corner case just didn't manage to show up for COW yet:
commit 80641dc66a2d6dfb22af4413227a92b8ab84c7bb
Author: Christoph Hellwig
Date: Mon Oct 19 04:00:03 2009 +
xfs: I/O completion handlers must use NOFS allocations
When completing I/O requests we must not allow the memory allocator to
recurse into the filesystem, as we might deadlock on waiting for the
I/O completion otherwise. The only thing currently allocating normal
GFP_KERNEL memory is the allocation of the transaction structure for
the unwritten extent conversion. Add a memflags argument to
_xfs_trans_alloc to allow controlling the allocator behaviour.
Signed-off-by: Christoph Hellwig
Reported-by: Thomas Neumann
Tested-by: Thomas Neumann
Reviewed-by: Alex Elder
Signed-off-by: Alex Elder
diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c
index 2d0b3e1da9e6..6f83f58c099f 100644
--- a/fs/xfs/xfs_fsops.c
+++ b/fs/xfs/xfs_fsops.c
@@ -611,7 +611,7 @@ xfs_fs_log_dummy(
xfs_inode_t *ip;
int error;
- tp = _xfs_trans_alloc(mp, XFS_TRANS_DUMMY1);
+ tp = _xfs_trans_alloc(mp, XFS_TRANS_DUMMY1, KM_SLEEP);
error = xfs_trans_reserve(tp, 0, XFS_ICHANGE_LOG_RES(mp), 0, 0, 0);
if (error) {
xfs_trans_cancel(tp, 0);
diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index 67aea30a..7294abce6ef2 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -860,8 +860,15 @@ xfs_iomap_write_unwritten(
* set up a transaction to convert the range of extents
* from unwritten to real. Do allocations in a loop until
* we have covered the range passed in.
+*
+* Note that we open code the transaction allocation here
+* to pass KM_NOFS--we can't risk to recursing back into
+* the filesystem here as we might be asked to write out
+* the same inode that we complete here and might deadlock
+* on the iolock.
*/
- tp = xfs_trans_alloc(mp, XFS_TRANS_STRAT_WRITE);
+ xfs_wait_for_freeze(mp, SB_FREEZE_TRANS);
+ tp = _xfs_trans_alloc(mp, XFS_TRANS_STRAT_WRITE, KM_NOFS);
tp->t_flags |= XFS_TRANS_RESERVE;
error = xfs_trans_reserve(tp, resblks,
XFS_WRITE_LOG_RES(mp), 0,
diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
index 8b6c9e807efb..4d509f742bd2 100644
--- a/fs/xfs/xfs_mount.c
+++ b/fs/xfs/xfs_mount.c
@@ -1471,7 +1471,7 @@ xfs_log_sbcount(
if (!xfs_sb_version_haslazysbcount(>m_sb))
return 0;
- tp = _xfs_trans_alloc(mp, XFS_TRANS_SB_COUNT);
+ tp = _xfs_trans_alloc(mp, XFS_TRANS_SB_COUNT, KM_SLEEP);
error = xfs_trans_reserve(tp, 0, mp->m_sb.sb_sectsize + 128, 0, 0,
XFS_DEFAULT_LOG_COUNT);
if (error) {
diff --git a/fs/xfs/xfs_trans.c b/fs/xfs/xfs_trans.c
index 66b849358e62..237badcbac3b 100644
--- a/fs/xfs/xfs_trans.c
+++ b/fs/xfs/xfs_trans.c
@@ -236,19 +236,20 @@ xfs_trans_alloc(
uinttype)
{
xfs_wait_for_freeze(mp, SB_FREEZE_TRANS);
- return _xfs_trans_alloc(mp, type);
+ return _xfs_trans_alloc(mp, type, KM_SLEEP);
}
xfs_trans_t *
_xfs_trans_alloc(
xfs_mount_t *mp,
- uinttype)
+ uinttype,
+ uintmemflags)
{
xfs_trans_t *tp;
atomic_inc(>m_active_trans);
- tp = kmem_zone_zalloc(xfs_trans_zone, KM_SLEEP);
+ tp = kmem_zone_zalloc(xfs_trans_zone, memflags);
tp->t_magic =
Re: [PATCH 11/12] iomap: move the xfs writeback code to iomap.c
On Fri, Jun 28, 2019 at 10:45:42AM +1000, Dave Chinner wrote: > You've already mentioned two new users you want to add. I don't even > have zone capable hardware here to test one of the users you are > indicating will use this code, and I suspect that very few people > do. That's a non-trivial increase in testing requirements for > filesystem developers and distro QA departments who will want to > change and/or validate this code path. Why do you assume you have to test it? Back when we shared generic_file_read with everyone you also didn't test odd change to it with every possible fs. If you change iomap.c, you'll test it with XFS, and Cc other maintainers so that they get a chance to also test it and comment on it, just like we do with other shared code in the kernel. > Indeed, integrating gfs2 into the existing generic iomap code has > required quite a bit of munging and adding new code paths and so on. > That's mostly been straight forward because it's just been adding > flags and conditional code to the existing paths. The way we > regularly rewrite sections of the XFS writeback code is a very > different sort of modification, and one that will be much harder to > do if we have to make those changes to generic code. As the person who has done a lot of the recent rewriting of the writeback code I disagree. Most of it has been do divorce is from leftovers of the buffer_head based sinle page at a time design from stone age. Very little is about XFS itself, most of it has been about not being stupid in a fairly generic way. And every since I got rid of buffer heads xfs_aops.c has been intimately tied into the iomap infrastructure, and I'd rather keep those details in one place. I.e. with this series now XFS doesn't even need to know about the details of the iomap_page structure and the uptodate bits. If for example I'd want to add sub-page dirty bits (which I don't if I can avoid it) I can handle this entirely in iomap now instead of spreading around iomap, xfs and duplicating the thing in every copy of the XFS code that would otherwise show up. > i.e. shared code is good if it's simple and doesn't have a lot of > external dependencies that restrict the type and scope of > modifications that can be made easily. Shared code that is complex > and comes from code that was tightly integrated with a specific > subsystem architecture is going to carry all those architectural > foilbles into the new "generic" code. Once it gets sufficient > users it's going to end up with the same "we can't change this code" > problems that we had with the existing IO path, and we'll go back to > implementing our own writeback path >From the high level POV I agree with your stance. But the point is that the writeback code is not tightly integrated with xfs, and that is why I don't want it in XFS. It is on other other hand very tightly integrated with the iomap buffer read and write into pagecache code, which is why I want to keep it together with that. > I've been planning on taking it even closer to the extent tree to > give us lockless, modification range coherent extent map caching in > this path (e.g. write() can add new delalloc extents without > invalidating cached writeback maps). This patchset re-introduces > the iomap abstraction over the bmbt - an abstraction we removed some > time ago - and that makes these sorts of improvements much harder > and more complex to implement FYI, I had an earlier but not quite optimal implementation of lockless extent lookups using rcu updates in the btree. And at least for that scheme all the details stay 100% in XFS in the split code, as the abstraction between iomap and xfs is very clear and allows for that.
[tip:x86/cpu] x86/mtrr: Skip cache flushes on CPUs with cache self-snooping
Commit-ID: fd329f276ecaad7a371d6f91b9bbea031d0c3440
Gitweb: https://git.kernel.org/tip/fd329f276ecaad7a371d6f91b9bbea031d0c3440
Author: Ricardo Neri
AuthorDate: Thu, 27 Jun 2019 19:35:37 -0700
Committer: Thomas Gleixner
CommitDate: Fri, 28 Jun 2019 07:21:00 +0200
x86/mtrr: Skip cache flushes on CPUs with cache self-snooping
Programming MTRR registers in multi-processor systems is a rather lengthy
process. Furthermore, all processors must program these registers in lock
step and with interrupts disabled; the process also involves flushing
caches and TLBs twice. As a result, the process may take a considerable
amount of time.
On some platforms, this can lead to a large skew of the refined-jiffies
clock source. Early when booting, if no other clock is available (e.g.,
booting with hpet=disabled), the refined-jiffies clock source is used to
monitor the TSC clock source. If the skew of refined-jiffies is too large,
Linux wrongly assumes that the TSC is unstable:
clocksource: timekeeping watchdog on CPU1: Marking clocksource
'tsc-early' as unstable because the skew is too large:
clocksource: 'refined-jiffies' wd_now: fffedc10 wd_last:
fffedb90 mask:
clocksource: 'tsc-early' cs_now: 5eccfddebc cs_last: 5e7e3303d4
mask:
tsc: Marking TSC unstable due to clocksource watchdog
As per measurements, around 98% of the time needed by the procedure to
program MTRRs in multi-processor systems is spent flushing caches with
wbinvd(). As per the Section 11.11.8 of the Intel 64 and IA 32
Architectures Software Developer's Manual, it is not necessary to flush
caches if the CPU supports cache self-snooping. Thus, skipping the cache
flushes can reduce by several tens of milliseconds the time needed to
complete the programming of the MTRR registers:
PlatformBefore After
104-core (208 Threads) Skylake 1437ms 28ms
2-core ( 4 Threads) Haswell 114ms 2ms
Reported-by: Mohammad Etemadi
Signed-off-by: Ricardo Neri
Signed-off-by: Thomas Gleixner
Cc: Borislav Petkov
Cc: Alan Cox
Cc: Tony Luck
Cc: "H. Peter Anvin"
Cc: Andy Shevchenko
Cc: Andi Kleen
Cc: Hans de Goede
Cc: Greg Kroah-Hartman
Cc: Jordan Borgner
Cc: "Ravi V. Shankar"
Cc: Ricardo Neri
Cc: Andy Shevchenko
Cc: Andi Kleen
Cc: Peter Feiner
Cc: "Rafael J. Wysocki"
Link:
https://lkml.kernel.org/r/1561689337-19390-3-git-send-email-ricardo.neri-calde...@linux.intel.com
---
arch/x86/kernel/cpu/mtrr/generic.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/generic.c
b/arch/x86/kernel/cpu/mtrr/generic.c
index 9356c1c9024d..aa5c064a6a22 100644
--- a/arch/x86/kernel/cpu/mtrr/generic.c
+++ b/arch/x86/kernel/cpu/mtrr/generic.c
@@ -743,7 +743,15 @@ static void prepare_set(void)
__acquires(set_atomicity_lock)
/* Enter the no-fill (CD=1, NW=0) cache mode and flush caches. */
cr0 = read_cr0() | X86_CR0_CD;
write_cr0(cr0);
- wbinvd();
+
+ /*
+* Cache flushing is the most time-consuming step when programming
+* the MTRRs. Fortunately, as per the Intel Software Development
+* Manual, we can skip it if the processor supports cache self-
+* snooping.
+*/
+ if (!static_cpu_has(X86_FEATURE_SELFSNOOP))
+ wbinvd();
/* Save value of CR4 and clear Page Global Enable (bit 7) */
if (boot_cpu_has(X86_FEATURE_PGE)) {
@@ -760,7 +768,10 @@ static void prepare_set(void)
__acquires(set_atomicity_lock)
/* Disable MTRRs, and set the default type to uncached */
mtrr_wrmsr(MSR_MTRRdefType, deftype_lo & ~0xcff, deftype_hi);
- wbinvd();
+
+ /* Again, only flush caches if we have to. */
+ if (!static_cpu_has(X86_FEATURE_SELFSNOOP))
+ wbinvd();
}
static void post_set(void) __releases(set_atomicity_lock)
[tip:x86/cpu] x86/cpu/intel: Clear cache self-snoop capability in CPUs with known errata
Commit-ID: 1e03bff3600101bd9158d005e4313132e55bdec8
Gitweb: https://git.kernel.org/tip/1e03bff3600101bd9158d005e4313132e55bdec8
Author: Ricardo Neri
AuthorDate: Thu, 27 Jun 2019 19:35:36 -0700
Committer: Thomas Gleixner
CommitDate: Fri, 28 Jun 2019 07:20:48 +0200
x86/cpu/intel: Clear cache self-snoop capability in CPUs with known errata
Processors which have self-snooping capability can handle conflicting
memory type across CPUs by snooping its own cache. However, there exists
CPU models in which having conflicting memory types still leads to
unpredictable behavior, machine check errors, or hangs.
Clear this feature on affected CPUs to prevent its use.
Suggested-by: Alan Cox
Signed-off-by: Ricardo Neri
Signed-off-by: Thomas Gleixner
Cc: Borislav Petkov
Cc: Tony Luck
Cc: "H. Peter Anvin"
Cc: Andy Shevchenko
Cc: Andi Kleen
Cc: Hans de Goede
Cc: Greg Kroah-Hartman
Cc: Jordan Borgner
Cc: "Ravi V. Shankar"
Cc: Mohammad Etemadi
Cc: Ricardo Neri
Cc: Andy Shevchenko
Cc: Andi Kleen
Cc: Peter Feiner
Cc: "Rafael J. Wysocki"
Link:
https://lkml.kernel.org/r/1561689337-19390-2-git-send-email-ricardo.neri-calde...@linux.intel.com
---
arch/x86/kernel/cpu/intel.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index f17c1a714779..8d6d92ebeb54 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -66,6 +66,32 @@ void check_mpx_erratum(struct cpuinfo_x86 *c)
}
}
+/*
+ * Processors which have self-snooping capability can handle conflicting
+ * memory type across CPUs by snooping its own cache. However, there exists
+ * CPU models in which having conflicting memory types still leads to
+ * unpredictable behavior, machine check errors, or hangs. Clear this
+ * feature to prevent its use on machines with known erratas.
+ */
+static void check_memory_type_self_snoop_errata(struct cpuinfo_x86 *c)
+{
+ switch (c->x86_model) {
+ case INTEL_FAM6_CORE_YONAH:
+ case INTEL_FAM6_CORE2_MEROM:
+ case INTEL_FAM6_CORE2_MEROM_L:
+ case INTEL_FAM6_CORE2_PENRYN:
+ case INTEL_FAM6_CORE2_DUNNINGTON:
+ case INTEL_FAM6_NEHALEM:
+ case INTEL_FAM6_NEHALEM_G:
+ case INTEL_FAM6_NEHALEM_EP:
+ case INTEL_FAM6_NEHALEM_EX:
+ case INTEL_FAM6_WESTMERE:
+ case INTEL_FAM6_WESTMERE_EP:
+ case INTEL_FAM6_SANDYBRIDGE:
+ setup_clear_cpu_cap(X86_FEATURE_SELFSNOOP);
+ }
+}
+
static bool ring3mwait_disabled __read_mostly;
static int __init ring3mwait_disable(char *__unused)
@@ -304,6 +330,7 @@ static void early_init_intel(struct cpuinfo_x86 *c)
}
check_mpx_erratum(c);
+ check_memory_type_self_snoop_errata(c);
/*
* Get the number of SMT siblings early from the extended topology
[tip:x86/boot] x86/kdump/64: Restrict kdump kernel reservation to <64TB
Commit-ID: 8ff80fbe7e9870078b1cc3c2cdd8f3f223b333a9 Gitweb: https://git.kernel.org/tip/8ff80fbe7e9870078b1cc3c2cdd8f3f223b333a9 Author: Baoquan He AuthorDate: Fri, 24 May 2019 15:38:10 +0800 Committer: Thomas Gleixner CommitDate: Fri, 28 Jun 2019 07:14:59 +0200 x86/kdump/64: Restrict kdump kernel reservation to <64TB Restrict kdump to only reserve crashkernel below 64TB. The reaons is that the kdump may jump from a 5-level paging mode to a 4-level paging mode kernel. If a 4-level paging mode kdump kernel is put above 64TB, then the kdump kernel cannot start. The 1st kernel reserves the kdump kernel region during bootup. At that point it is not known whether the kdump kernel has 5-level or 4-level paging support. To support both restrict the kdump kernel reservation to the lower 64TB address space to ensure that a 4-level paging mode kdump kernel can be loaded and successfully started. [ tglx: Massaged changelog ] Signed-off-by: Baoquan He Signed-off-by: Thomas Gleixner Acked-by: Kirill A. Shutemov Acked-by: Dave Young Cc: b...@alien8.de Cc: h...@zytor.com Link: https://lkml.kernel.org/r/20190524073810.24298-4-...@redhat.com --- arch/x86/kernel/setup.c | 15 --- include/linux/sizes.h | 1 + 2 files changed, 13 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 08a5f4a131f5..dcbdf54fb5c1 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -453,15 +453,24 @@ static void __init memblock_x86_reserve_range_setup_data(void) #define CRASH_ALIGNSZ_16M /* - * Keep the crash kernel below this limit. On 32 bits earlier kernels - * would limit the kernel to the low 512 MiB due to mapping restrictions. + * Keep the crash kernel below this limit. + * + * On 32 bits earlier kernels would limit the kernel to the low 512 MiB + * due to mapping restrictions. + * + * On 64bit, kdump kernel need be restricted to be under 64TB, which is + * the upper limit of system RAM in 4-level paing mode. Since the kdump + * jumping could be from 5-level to 4-level, the jumping will fail if + * kernel is put above 64TB, and there's no way to detect the paging mode + * of the kernel which will be loaded for dumping during the 1st kernel + * bootup. */ #ifdef CONFIG_X86_32 # define CRASH_ADDR_LOW_MAXSZ_512M # define CRASH_ADDR_HIGH_MAX SZ_512M #else # define CRASH_ADDR_LOW_MAXSZ_4G -# define CRASH_ADDR_HIGH_MAX MAXMEM +# define CRASH_ADDR_HIGH_MAX SZ_64T #endif static int __init reserve_crashkernel_low(void) diff --git a/include/linux/sizes.h b/include/linux/sizes.h index fbde0bc7e882..8651269cb46c 100644 --- a/include/linux/sizes.h +++ b/include/linux/sizes.h @@ -47,5 +47,6 @@ #define SZ_2G 0x8000 #define SZ_4G _AC(0x1, ULL) +#define SZ_64T _AC(0x4000, ULL) #endif /* __LINUX_SIZES_H__ */
[tip:x86/boot] x86/kexec/64: Prevent kexec from 5-level paging to a 4-level only kernel
Commit-ID: ee338b9ee2822e65a85750da6129946c14962410
Gitweb: https://git.kernel.org/tip/ee338b9ee2822e65a85750da6129946c14962410
Author: Baoquan He
AuthorDate: Fri, 24 May 2019 15:38:09 +0800
Committer: Thomas Gleixner
CommitDate: Fri, 28 Jun 2019 07:14:59 +0200
x86/kexec/64: Prevent kexec from 5-level paging to a 4-level only kernel
If the running kernel has 5-level paging activated, the 5-level paging mode
is preserved across kexec. If the kexec'ed kernel does not contain support
for handling active 5-level paging mode in the decompressor, the
decompressor will crash with #GP.
Prevent this situation at load time. If 5-level paging is active, check the
xloadflags whether the kexec kernel can handle 5-level paging at least in
the decompressor. If not, reject the load attempt and print out an error
message.
Signed-off-by: Baoquan He
Signed-off-by: Thomas Gleixner
Acked-by: Kirill A. Shutemov
Cc: b...@alien8.de
Cc: h...@zytor.com
Cc: dyo...@redhat.com
Link: https://lkml.kernel.org/r/20190524073810.24298-3-...@redhat.com
---
arch/x86/kernel/kexec-bzimage64.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/kernel/kexec-bzimage64.c
b/arch/x86/kernel/kexec-bzimage64.c
index 22f60dd26460..7f439739ea3d 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -321,6 +321,11 @@ static int bzImage64_probe(const char *buf, unsigned long
len)
return ret;
}
+ if (!(header->xloadflags & XLF_5LEVEL) && pgtable_l5_enabled()) {
+ pr_err("bzImage cannot handle 5-level paging mode.\n");
+ return ret;
+ }
+
/* I've got a bzImage */
pr_debug("It's a relocatable bzImage64\n");
ret = 0;
[tip:x86/boot] x86/boot: Add xloadflags bits to check for 5-level paging support
Commit-ID: f2d08c5d3bcf3f7ef788af122b57a919efa1e9d0 Gitweb: https://git.kernel.org/tip/f2d08c5d3bcf3f7ef788af122b57a919efa1e9d0 Author: Baoquan He AuthorDate: Fri, 24 May 2019 15:38:08 +0800 Committer: Thomas Gleixner CommitDate: Fri, 28 Jun 2019 07:14:59 +0200 x86/boot: Add xloadflags bits to check for 5-level paging support The current kernel supports 5-level paging mode, and supports dynamically choosing the paging mode during bootup depending on the kernel image, hardware and kernel parameter settings. This flexibility brings several issues to kexec/kdump: 1) Dynamic switching between paging modes requires support in the target kernel. This means kexec from a 5-level paging kernel into a kernel which does not support mode switching is not possible. So the loader needs to be able to analyze the supported paging modes of the kexec target kernel. 2) If running on a 5-level paging kernel and the kexec target kernel is a 4-level paging kernel, the target immage cannot be loaded above the 64TB address space limit. But the kexec loader searches for a load area from top to bottom which would eventually put the target kernel above 64TB when the machine has large enough RAM size. So the loader needs to be able to analyze the paging mode of the target kernel to load it at a suitable spot in the address space. Solution: Add two bits XLF_5LEVEL and XLF_5LEVEL_ENABLED: - Bit XLF_5LEVEL indicates whether 5-level paging mode switching support is available. (Issue #1) - Bit XLF_5LEVEL_ENABLED indicates whether the kernel was compiled with full 5-level paging support (CONFIG_X86_5LEVEL=y). (Issue #2) The loader will use these bits to verify whether the target kernel is suitable to be kexec'ed to from a 5-level paging kernel and to determine the constraints of the target kernel load address. The flags will be used by the kernel kexec subsystem and the userspace kexec tools. [ tglx: Massaged changelog ] Signed-off-by: Baoquan He Signed-off-by: Thomas Gleixner Acked-by: Kirill A. Shutemov Cc: b...@alien8.de Cc: h...@zytor.com Cc: dyo...@redhat.com Link: https://lkml.kernel.org/r/20190524073810.24298-2-...@redhat.com --- arch/x86/boot/header.S| 12 +++- arch/x86/include/uapi/asm/bootparam.h | 2 ++ 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S index 850b8762e889..be19f4199727 100644 --- a/arch/x86/boot/header.S +++ b/arch/x86/boot/header.S @@ -419,7 +419,17 @@ xloadflags: # define XLF4 0 #endif - .word XLF0 | XLF1 | XLF23 | XLF4 +#ifdef CONFIG_X86_64 +#ifdef CONFIG_X86_5LEVEL +#define XLF56 (XLF_5LEVEL|XLF_5LEVEL_ENABLED) +#else +#define XLF56 XLF_5LEVEL +#endif +#else +#define XLF56 0 +#endif + + .word XLF0 | XLF1 | XLF23 | XLF4 | XLF56 cmdline_size: .long COMMAND_LINE_SIZE-1 #length of the command line, #added with boot protocol diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h index 60733f137e9a..c895df5482c5 100644 --- a/arch/x86/include/uapi/asm/bootparam.h +++ b/arch/x86/include/uapi/asm/bootparam.h @@ -29,6 +29,8 @@ #define XLF_EFI_HANDOVER_32(1<<2) #define XLF_EFI_HANDOVER_64(1<<3) #define XLF_EFI_KEXEC (1<<4) +#define XLF_5LEVEL (1<<5) +#define XLF_5LEVEL_ENABLED (1<<6) #ifndef __ASSEMBLY__
[PATCH V3 2/5] cpufreq: Don't skip frequency validation for has_target() drivers
CPUFREQ_CONST_LOOPS was introduced in a very old commit from pre-2.6
kernel release by commit 6a4a93f9c0d5 ("[CPUFREQ] Fix 'out of sync'
issue").
If we you look at that commit, it does two things:
- It adds the frequency verification code (which is quite similar to
what we have today as well).
- And it sets the CPUFREQ_CONST_LOOPS flag only for setpolicy drivers,
rightly so based on the code we had then. The idea was to avoid
frequency validation for setpolicy drivers as the cpufreq core doesn't
know what frequency the hardware is running at and so no point in
doing frequency verification.
The problem happened when we started to use the same CPUFREQ_CONST_LOOPS
flag for constant loops-per-jiffy thing as well and many has_target()
drivers started using the same flag and unknowingly skipped the
verification of frequency. There is no logical reason behind skipping
frequency validation because of the presence of CPUFREQ_CONST_LOOPS
flag otherwise.
This patch fixes this issue by skipping frequency validation only for
setpolicy drivers and always doing it for has_target() drivers
irrespective of the presence or absence of CPUFREQ_CONST_LOOPS flag.
cpufreq_notify_transition() is only called for has_target() type driver
and not for set_policy type, and the check is simply redundant. Remove
it as well.
Also remove () around freq comparison statement as they aren't required
and checkpatch also warns for them.
Signed-off-by: Viresh Kumar
---
V2->V3:
- Updated commit log and $subject.
drivers/cpufreq/cpufreq.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 54befd775bd6..41ac701e324f 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -359,12 +359,10 @@ static void cpufreq_notify_transition(struct
cpufreq_policy *policy,
* which is not equal to what the cpufreq core thinks is
* "old frequency".
*/
- if (!(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) {
- if (policy->cur && (policy->cur != freqs->old)) {
- pr_debug("Warning: CPU frequency is %u, cpufreq
assumed %u kHz\n",
-freqs->old, policy->cur);
- freqs->old = policy->cur;
- }
+ if (policy->cur && policy->cur != freqs->old) {
+ pr_debug("Warning: CPU frequency is %u, cpufreq assumed
%u kHz\n",
+freqs->old, policy->cur);
+ freqs->old = policy->cur;
}
srcu_notifier_call_chain(_transition_notifier_list,
@@ -1618,8 +1616,7 @@ static unsigned int __cpufreq_get(struct cpufreq_policy
*policy)
if (policy->fast_switch_enabled)
return ret_freq;
- if (ret_freq && policy->cur &&
- !(cpufreq_driver->flags & CPUFREQ_CONST_LOOPS)) {
+ if (has_target() && ret_freq && policy->cur) {
/* verify no discrepancy between actual and
saved value exists */
if (unlikely(ret_freq != policy->cur)) {
--
2.21.0.rc0.269.g1a574e7a288b
[PATCH] kbuild: use -E instead of -c for __cc-option
Use -E instead of -c like scripts/Kconfig.include This makes the compiler flag evaluation slightly faster. Signed-off-by: Masahiro Yamada --- scripts/Kbuild.include | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include index f641bb0aa63f..e4329b92d165 100644 --- a/scripts/Kbuild.include +++ b/scripts/Kbuild.include @@ -113,7 +113,7 @@ as-instr = $(call try-run,\ # __cc-option # Usage: MY_CFLAGS += $(call __cc-option,$(CC),$(MY_CFLAGS),-march=winchip-c6,-march=i586) __cc-option = $(call try-run,\ - $(1) -Werror $(2) $(3) -c -x c /dev/null -o "$$TMP",$(3),$(4)) + $(1) -Werror $(2) $(3) -E -x c /dev/null -o "$$TMP",$(3),$(4)) # Do not attempt to build with gcc plugins during cc-option tests. # (And this uses delayed resolution so the flags will be up to date.) -- 2.17.1
Re: No 8254 PIT & no HPET on new Intel N3350 platforms causes kernel panic during early boot
On Fri, 28 Jun 2019, Daniel Drake wrote: > On Thu, Jun 27, 2019 at 10:07 PM Thomas Gleixner wrote: > > Nah. That extra timer works thing is just another bandaid. > > > > What I had in mind is something like the below. That's on top of > > > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/apic > > > > Be warned. It's neither compiled nor tested, so keep a fire extinguisher > > handy. If it explodes you own the pieces. > > Thanks, it works, and makes sense! > > I'll add a commit message and send it as a patch, just one quick > function naming question... did you mean apic_and_tsc_needs_pit() or > apic_needs_pit()? That's the only compile fix needed. I'd say apic_needs_pit(). Less places to change :) Thanks, tglx
Re: [PATCH v4 0/2] Use NVMEM as reboot-mode write interface
Hi, Changes since v3: - documentation updated according to the comments Thanks, queued. Please fix your git/mail setup, I had to fix the line endings (\r\n -> \n) to apply this. -- Sebastian Ok. Thanks Sebastian. -- Nandor
[PATCH RFC] mtd: ubi: Add fastmap sysfs attribute
From: Zhihao Cheng
The UBI device can be attached to a MTD device via fastmap by set
CONFIG_MTD_UBI_FASTMAP to 'y' (If there already exists a fastmap on the
UBI device). To support some debugging scenarios, attaching process by
fastmap can be confirmed in dmesg. If the UBI device is attached by
fastmap, logs like following will appear in dmesg:
ubi0: attached by fastmap
If multiple UBI devices are attached to multiple MTD devices at the same
time, how to distinguish which UBI devices are successfully attached by
fastmap? Extracting attaching information for each UBI device one by one
from dmesg is a way. A better method is to record fastmap existence in
sysfs, so it can be obtained by userspace tools.
This patch exposes fastmap on sysfs. Suppose you attach an UBI device to a
MTD device by fastmap: if fastmap equals to '1', that is, the fastmap
generated before last detaching operation is confirmed valid. Else, there
may be some problems with old fastmap. Besides, userspace tool can also
check whether the fastmap updating triggered by other operations (such as
resize volume) is successful by reading this sysfs attribute.
Signed-off-by: Zhihao Cheng
---
Documentation/ABI/stable/sysfs-class-ubi | 15 +++
drivers/mtd/ubi/build.c | 5 +
2 files changed, 20 insertions(+)
diff --git a/Documentation/ABI/stable/sysfs-class-ubi
b/Documentation/ABI/stable/sysfs-class-ubi
index a6b3240..1d96cf0 100644
--- a/Documentation/ABI/stable/sysfs-class-ubi
+++ b/Documentation/ABI/stable/sysfs-class-ubi
@@ -116,6 +116,21 @@ Description:
device, and "0\n" if it is cleared. UBI devices mark themselves
as read-only when they detect an unrecoverable error.
+What: /sys/class/ubi/ubiX/fastmap
+Date: June 2019
+KernelVersion: 5.2
+Contact: linux-...@lists.infradead.org
+Description:
+ Contains ASCII "1\n" if there exists a fastmap on UBI device,
+ and "0\n" if there not exists a fastmap on UBI device. After
+ attaching the UBI device to a MTD device via fastmap, userspace
+ tool can sense that there is a fastmap on UBI device by
+ checking sysfs attribute 'fastmap', that is, the fastmap
+ generated before last detaching operation is valid. In addition,
+ userspace tool can also check whether the fastmap updating
+ triggered by volume operation is successful by reading this
+ sysfs attribute.
+
What: /sys/class/ubi/ubiX/total_eraseblocks
Date: July 2006
KernelVersion: 2.6.22
diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index d636bbe..7cce44f 100644
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -140,6 +140,8 @@ static struct device_attribute dev_mtd_num =
__ATTR(mtd_num, S_IRUGO, dev_attribute_show, NULL);
static struct device_attribute dev_ro_mode =
__ATTR(ro_mode, S_IRUGO, dev_attribute_show, NULL);
+static struct device_attribute dev_fastmap =
+ __ATTR(fastmap, S_IRUGO, dev_attribute_show, NULL);
/**
* ubi_volume_notify - send a volume change notification.
@@ -378,6 +380,8 @@ static ssize_t dev_attribute_show(struct device *dev,
ret = sprintf(buf, "%d\n", ubi->mtd->index);
else if (attr == _ro_mode)
ret = sprintf(buf, "%d\n", ubi->ro_mode);
+ else if (attr == _fastmap)
+ ret = sprintf(buf, "%d\n", ubi->fm ? 1 : 0);
else
ret = -EINVAL;
@@ -398,6 +402,7 @@ static struct attribute *ubi_dev_attrs[] = {
_bgt_enabled.attr,
_mtd_num.attr,
_ro_mode.attr,
+ _fastmap.attr,
NULL
};
ATTRIBUTE_GROUPS(ubi_dev);
--
2.7.4
Re: [PATCH] riscv: ccache: Remove unused variable
On Thu, Jun 27, 2019 at 9:43 PM Paul Walmsley wrote: > > On Thu, 27 Jun 2019, Yash Shah wrote: > > > Reading the count register clears the interrupt signal. Currently, the > > count registers are read into 'regval' variable but the variable is > > never used. Therefore remove it. > > > > Signed-off-by: Yash Shah > > This is a good start. Could you also add comments in the code that > describe what those reads are doing, as you did in the patch description? > Otherwise they look pretty mysterious. > Sure, will add comments and send v2 > > - Paul
Re: [RFC PATCH 00/28] Removing struct page from P2PDMA
On Thu, Jun 27, 2019 at 10:49:43AM -0600, Logan Gunthorpe wrote: > > I don't think a GPU/FPGA driver will be involved, this would enter the > > block layer through the O_DIRECT path or something generic.. This the > > general flow I was suggesting to Dan earlier > > I would say the O_DIRECT path has to somehow call into the driver > backing the VMA to get an address to appropriate memory (in some way > vaguely similar to how we were discussing at LSF/MM) Maybe, maybe no. For something like VFIO the PTE already has the correct phys_addr_t and we don't need to do anything.. For DEVICE_PRIVATE we need to get the phys_addr_t out - presumably through a new pagemap op? > If P2P can't be done at that point, then the provider driver would > do the copy to system memory, in the most appropriate way, and > return regular pages for O_DIRECT to submit to the block device. That only makes sense for the migratable DEVICE_PRIVATE case, it doesn't help the VFIO-like case, there you'd need to bounce buffer. > >> I think it would be a larger layering violation to have the NVMe driver > >> (for example) memcpy data off a GPU's bar during a dma_map step to > >> support this bouncing. And it's even crazier to expect a DMA transfer to > >> be setup in the map step. > > > > Why? Don't we already expect the DMA mapper to handle bouncing for > > lots of cases, how is this case different? This is the best place to > > place it to make it shared. > > This is different because it's special memory where the DMA mapper > can't possibly know the best way to transfer the data. Why not? If we have a 'bar info' structure that could have data transfer op callbacks, infact, I think we might already have similar callbacks for migrating to/from DEVICE_PRIVATE memory with DMA.. > One could argue that the hook to the GPU/FPGA driver could be in the > mapping step but then we'd have to do lookups based on an address -- > where as the VMA could more easily have a hook back to whatever driver > exported it. The trouble with a VMA hook is that it is only really avaiable when working with the VA, and it is not actually available during GUP, you have to have a GUP-like thing such as hmm_range_snapshot that is specifically VMA based. And it is certainly not available during dma_map. When working with VMA's/etc it seems there are some good reasons to drive things off of the PTE content (either via struct page & pgmap or via phys_addr_t & barmap) I think the best reason to prefer a uniform phys_addr_t is that it does give us the option to copy the data to/from CPU memory. That option goes away as soon as the bio sometimes provides a dma_addr_t. At least for RDMA, we do have some cases (like siw/rxe, hfi) where they sometimes need to do that copy. I suspect the block stack is similar, in the general case. Jason
linux-next: manual merge of the devicetree tree with the net-next tree
Hi all,
Today's linux-next merge of the devicetree tree got a conflict in:
Documentation/devicetree/bindings/net/ethernet.txt
between commit:
79b647a0c0d5 ("dt-bindings: net: document new usxgmii phy mode")
from the net-next tree and commit:
4e7a33bff7d7 ("dt-bindings: net: Add YAML schemas for the generic Ethernet
options")
from the devicetree tree.
I fixed it up (the latter seems to include the change made by the former,
so I just used the latter) 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
pgpACqEJoWJnX.pgp
Description: OpenPGP digital signature
[PATCH] rbtree: avoid generating code twice for the cached versions
As was already noted in rbtree.h, the logic to cache rb_first (or rb_last)
can easily be implemented externally to the core rbtree api.
Change the implementation to do just that. Previously the update of
rb_leftmost was wired deeper into the implemntation, but there were
some disadvantages to that - mostly, lib/rbtree.c had separate
instantiations for rb_insert_color() vs rb_insert_color_cached(), as well
as rb_erase() vs rb_erase_cached(), which were doing exactly the same
thing save for the rb_leftmost update at the start of either function.
Change-Id: I0cb62be774fc0138b81188e6ae81d5f1da64578d
Signed-off-by: Michel Lespinasse
---
include/linux/rbtree.h | 70 +---
include/linux/rbtree_augmented.h | 27 +---
lib/rbtree.c | 40 ++
3 files changed, 59 insertions(+), 78 deletions(-)
diff --git a/include/linux/rbtree.h b/include/linux/rbtree.h
index fcbeed4053ef..9e8d41a90072 100644
--- a/include/linux/rbtree.h
+++ b/include/linux/rbtree.h
@@ -44,25 +44,9 @@ struct rb_root {
struct rb_node *rb_node;
};
-/*
- * Leftmost-cached rbtrees.
- *
- * We do not cache the rightmost node based on footprint
- * size vs number of potential users that could benefit
- * from O(1) rb_last(). Just not worth it, users that want
- * this feature can always implement the logic explicitly.
- * Furthermore, users that want to cache both pointers may
- * find it a bit asymmetric, but that's ok.
- */
-struct rb_root_cached {
- struct rb_root rb_root;
- struct rb_node *rb_leftmost;
-};
-
#define rb_parent(r) ((struct rb_node *)((r)->__rb_parent_color & ~3))
#define RB_ROOT(struct rb_root) { NULL, }
-#define RB_ROOT_CACHED (struct rb_root_cached) { {NULL, }, NULL }
#definerb_entry(ptr, type, member) container_of(ptr, type, member)
#define RB_EMPTY_ROOT(root) (READ_ONCE((root)->rb_node) == NULL)
@@ -84,12 +68,6 @@ extern struct rb_node *rb_prev(const struct rb_node *);
extern struct rb_node *rb_first(const struct rb_root *);
extern struct rb_node *rb_last(const struct rb_root *);
-extern void rb_insert_color_cached(struct rb_node *,
- struct rb_root_cached *, bool);
-extern void rb_erase_cached(struct rb_node *node, struct rb_root_cached *);
-/* Same as rb_first(), but O(1) */
-#define rb_first_cached(root) (root)->rb_leftmost
-
/* Postorder iteration - always visit the parent after its children */
extern struct rb_node *rb_first_postorder(const struct rb_root *);
extern struct rb_node *rb_next_postorder(const struct rb_node *);
@@ -99,8 +77,6 @@ extern void rb_replace_node(struct rb_node *victim, struct
rb_node *new,
struct rb_root *root);
extern void rb_replace_node_rcu(struct rb_node *victim, struct rb_node *new,
struct rb_root *root);
-extern void rb_replace_node_cached(struct rb_node *victim, struct rb_node *new,
- struct rb_root_cached *root);
static inline void rb_link_node(struct rb_node *node, struct rb_node *parent,
struct rb_node **rb_link)
@@ -148,4 +124,50 @@ static inline void rb_link_node_rcu(struct rb_node *node,
struct rb_node *parent
typeof(*pos), field); 1; }); \
pos = n)
+/*
+ * Leftmost-cached rbtrees.
+ *
+ * We do not cache the rightmost node based on footprint
+ * size vs number of potential users that could benefit
+ * from O(1) rb_last(). Just not worth it, users that want
+ * this feature can always implement the logic explicitly.
+ * Furthermore, users that want to cache both pointers may
+ * find it a bit asymmetric, but that's ok.
+ */
+struct rb_root_cached {
+ struct rb_root rb_root;
+ struct rb_node *rb_leftmost;
+};
+
+#define RB_ROOT_CACHED (struct rb_root_cached) { {NULL, }, NULL }
+
+/* Same as rb_first(), but O(1) */
+#define rb_first_cached(root) (root)->rb_leftmost
+
+static inline void rb_insert_color_cached(struct rb_node *node,
+ struct rb_root_cached *root,
+ bool leftmost)
+{
+ if (leftmost)
+ root->rb_leftmost = node;
+ rb_insert_color(node, >rb_root);
+}
+
+static inline void rb_erase_cached(struct rb_node *node,
+ struct rb_root_cached *root)
+{
+if (root->rb_leftmost == node)
+root->rb_leftmost = rb_next(node);
+ rb_erase(node, >rb_root);
+}
+
+static inline void rb_replace_node_cached(struct rb_node *victim,
+ struct rb_node *new,
+ struct rb_root_cached *root)
+{
+ if (root->rb_leftmost == victim)
+ root->rb_leftmost = new;
+ rb_replace_node(victim, new, >rb_root);
+}
+
#endif /* _LINUX_RBTREE_H */
diff --git a/include/linux/rbtree_augmented.h
[RFC 2/2] arm64/mm: Enable device memory allocation and free for vmemmap mapping
This enables vmemmap_populate() and vmemmap_free() functions to incorporate
struct vmem_altmap based device memory allocation and free requests. With
this device memory with specific atlmap configuration can be hot plugged
and hot removed as ZONE_DEVICE memory on arm64 platforms.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
arch/arm64/mm/mmu.c | 57 ++---
1 file changed, 37 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 39e18d1..8867bbd 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -735,15 +735,26 @@ int kern_addr_valid(unsigned long addr)
}
#ifdef CONFIG_MEMORY_HOTPLUG
-static void free_hotplug_page_range(struct page *page, size_t size)
+static void free_hotplug_page_range(struct page *page, size_t size,
+ struct vmem_altmap *altmap)
{
- WARN_ON(!page || PageReserved(page));
- free_pages((unsigned long)page_address(page), get_order(size));
+ if (altmap) {
+ /*
+* vmemmap_populate() creates vmemmap mapping either at pte
+* or pmd level. Unmapping request at any other level would
+* be a problem.
+*/
+ WARN_ON((size != PAGE_SIZE) && (size != PMD_SIZE));
+ vmem_altmap_free(altmap, size >> PAGE_SHIFT);
+ } else {
+ WARN_ON(!page || PageReserved(page));
+ free_pages((unsigned long)page_address(page), get_order(size));
+ }
}
static void free_hotplug_pgtable_page(struct page *page)
{
- free_hotplug_page_range(page, PAGE_SIZE);
+ free_hotplug_page_range(page, PAGE_SIZE, NULL);
}
static void free_pte_table(pmd_t *pmdp, unsigned long addr)
@@ -807,7 +818,8 @@ static void free_pud_table(pgd_t *pgdp, unsigned long addr)
}
static void unmap_hotplug_pte_range(pmd_t *pmdp, unsigned long addr,
- unsigned long end, bool sparse_vmap)
+ unsigned long end, bool sparse_vmap,
+ struct vmem_altmap *altmap)
{
struct page *page;
pte_t *ptep, pte;
@@ -823,12 +835,13 @@ static void unmap_hotplug_pte_range(pmd_t *pmdp, unsigned
long addr,
pte_clear(_mm, addr, ptep);
flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
if (sparse_vmap)
- free_hotplug_page_range(page, PAGE_SIZE);
+ free_hotplug_page_range(page, PAGE_SIZE, altmap);
} while (addr += PAGE_SIZE, addr < end);
}
static void unmap_hotplug_pmd_range(pud_t *pudp, unsigned long addr,
- unsigned long end, bool sparse_vmap)
+ unsigned long end, bool sparse_vmap,
+ struct vmem_altmap *altmap)
{
unsigned long next;
struct page *page;
@@ -847,16 +860,17 @@ static void unmap_hotplug_pmd_range(pud_t *pudp, unsigned
long addr,
pmd_clear(pmdp);
flush_tlb_kernel_range(addr, next);
if (sparse_vmap)
- free_hotplug_page_range(page, PMD_SIZE);
+ free_hotplug_page_range(page, PMD_SIZE, altmap);
continue;
}
WARN_ON(!pmd_table(pmd));
- unmap_hotplug_pte_range(pmdp, addr, next, sparse_vmap);
+ unmap_hotplug_pte_range(pmdp, addr, next, sparse_vmap, altmap);
} while (addr = next, addr < end);
}
static void unmap_hotplug_pud_range(pgd_t *pgdp, unsigned long addr,
- unsigned long end, bool sparse_vmap)
+ unsigned long end, bool sparse_vmap,
+ struct vmem_altmap *altmap)
{
unsigned long next;
struct page *page;
@@ -875,16 +889,16 @@ static void unmap_hotplug_pud_range(pgd_t *pgdp, unsigned
long addr,
pud_clear(pudp);
flush_tlb_kernel_range(addr, next);
if (sparse_vmap)
- free_hotplug_page_range(page, PUD_SIZE);
+ free_hotplug_page_range(page, PUD_SIZE, altmap);
continue;
}
WARN_ON(!pud_table(pud));
- unmap_hotplug_pmd_range(pudp, addr, next, sparse_vmap);
+ unmap_hotplug_pmd_range(pudp, addr, next, sparse_vmap, altmap);
} while (addr = next, addr < end);
}
static void unmap_hotplug_range(unsigned long addr, unsigned long end,
- bool sparse_vmap)
+ bool sparse_vmap, struct vmem_altmap
[RFC 0/2] arm64: Enable vmemmap from device memory
This series enables vmemmap mapping allocation from device memory ranges on arm64. Before that it enables vmemmap_populate_basepages() to accommodate struct vmem_altmap based requests. This series is based on linux next (next-20190613) along with v6 arm64 hot-remove series [1]. [1] https://lkml.org/lkml/2019/6/19/3 Cc: Catalin Marinas Cc: Will Deacon Cc: Mark Rutland Cc: Tony Luck Cc: Fenghua Yu Cc: Dave Hansen Cc: Andy Lutomirski Cc: Andrew Morton Cc: linux-arm-ker...@lists.infradead.org Cc: linux-i...@vger.kernel.org Cc: x...@kernel.org Cc: linux-kernel@vger.kernel.org Anshuman Khandual (2): mm/sparsemem: Add vmem_altmap support in vmemmap_populate_basepages() arm64/mm: Enable device memory allocation and free for vmemmap mapping arch/arm64/mm/mmu.c | 57 +++- arch/ia64/mm/discontig.c | 2 +- arch/x86/mm/init_64.c| 4 ++-- include/linux/mm.h | 5 +++-- mm/sparse-vmemmap.c | 16 +- 5 files changed, 54 insertions(+), 30 deletions(-) -- 2.7.4
[RFC 1/2] mm/sparsemem: Add vmem_altmap support in vmemmap_populate_basepages()
Generic vmemmap_populate_basepages() is used across platforms for vmemmap
as standard or as fallback when huge pages mapping fails. On arm64 it is
used for configs with ARM64_SWAPPER_USES_SECTION_MAPS applicable both for
ARM64_16K_PAGES and ARM64_64K_PAGES which cannot use huge pages because of
alignment requirements.
This prevents those configs from allocating from device memory for vmemap
mapping as vmemmap_populate_basepages() does not support vmem_altmap. This
enables that required support. Each architecture should evaluate and decide
on enabling device based base page allocation when appropriate. Hence this
keeps it disabled for all architectures to preserve the existing semantics.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Andrew Morton
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-i...@vger.kernel.org
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
arch/arm64/mm/mmu.c | 2 +-
arch/ia64/mm/discontig.c | 2 +-
arch/x86/mm/init_64.c| 4 ++--
include/linux/mm.h | 5 +++--
mm/sparse-vmemmap.c | 16 +++-
5 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 194c84e..39e18d1 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -982,7 +982,7 @@ static void remove_pagetable(unsigned long start, unsigned
long end,
int __meminit vmemmap_populate(unsigned long start, unsigned long end, int
node,
struct vmem_altmap *altmap)
{
- return vmemmap_populate_basepages(start, end, node);
+ return vmemmap_populate_basepages(start, end, node, NULL);
}
#else /* !ARM64_SWAPPER_USES_SECTION_MAPS */
int __meminit vmemmap_populate(unsigned long start, unsigned long end, int
node,
diff --git a/arch/ia64/mm/discontig.c b/arch/ia64/mm/discontig.c
index 05490dd..faefd7e 100644
--- a/arch/ia64/mm/discontig.c
+++ b/arch/ia64/mm/discontig.c
@@ -660,7 +660,7 @@ void arch_refresh_nodedata(int update_node, pg_data_t
*update_pgdat)
int __meminit vmemmap_populate(unsigned long start, unsigned long end, int
node,
struct vmem_altmap *altmap)
{
- return vmemmap_populate_basepages(start, end, node);
+ return vmemmap_populate_basepages(start, end, node, NULL);
}
void vmemmap_free(unsigned long start, unsigned long end,
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 8335ac6..c67ad5d 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -1509,7 +1509,7 @@ static int __meminit vmemmap_populate_hugepages(unsigned
long start,
vmemmap_verify((pte_t *)pmd, node, addr, next);
continue;
}
- if (vmemmap_populate_basepages(addr, next, node))
+ if (vmemmap_populate_basepages(addr, next, node, NULL))
return -ENOMEM;
}
return 0;
@@ -1527,7 +1527,7 @@ int __meminit vmemmap_populate(unsigned long start,
unsigned long end, int node,
__func__);
err = -ENOMEM;
} else
- err = vmemmap_populate_basepages(start, end, node);
+ err = vmemmap_populate_basepages(start, end, node, NULL);
if (!err)
sync_global_pgds(start, end - 1);
return err;
diff --git a/include/linux/mm.h b/include/linux/mm.h
index c6ae9eb..dda9bd4 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2758,14 +2758,15 @@ pgd_t *vmemmap_pgd_populate(unsigned long addr, int
node);
p4d_t *vmemmap_p4d_populate(pgd_t *pgd, unsigned long addr, int node);
pud_t *vmemmap_pud_populate(p4d_t *p4d, unsigned long addr, int node);
pmd_t *vmemmap_pmd_populate(pud_t *pud, unsigned long addr, int node);
-pte_t *vmemmap_pte_populate(pmd_t *pmd, unsigned long addr, int node);
+pte_t *vmemmap_pte_populate(pmd_t *pmd, unsigned long addr, int node,
+ struct vmem_altmap *altmap);
void *vmemmap_alloc_block(unsigned long size, int node);
struct vmem_altmap;
void *vmemmap_alloc_block_buf(unsigned long size, int node);
void *altmap_alloc_block_buf(unsigned long size, struct vmem_altmap *altmap);
void vmemmap_verify(pte_t *, int, unsigned long, unsigned long);
int vmemmap_populate_basepages(unsigned long start, unsigned long end,
- int node);
+ int node, struct vmem_altmap *altmap);
int vmemmap_populate(unsigned long start, unsigned long end, int node,
struct vmem_altmap *altmap);
void vmemmap_populate_print_last(void);
diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
index 7fec057..d333b75 100644
--- a/mm/sparse-vmemmap.c
+++ b/mm/sparse-vmemmap.c
@@ -140,12 +140,18 @@ void __meminit vmemmap_verify(pte_t *pte, int node,
start, end - 1);
}
-pte_t * __meminit vmemmap_pte_populate(pmd_t *pmd, unsigned long addr,
RE: [LINUX PATCH v12 3/3] mtd: rawnand: arasan: Add support for Arasan NAND Flash Controller
Hi Miquel, > -Original Message- > From: Miquel Raynal > Sent: Thursday, June 27, 2019 9:58 PM > To: Naga Sureshkumar Relli > Cc: Naga Sureshkumar Relli ; r...@kernel.org; > martin.lund@keep-it- > simple.com; rich...@nod.at; linux-kernel@vger.kernel.org; Boris Brezillon > ; linux-...@lists.infradead.org; > nagasures...@gmail.com; > Michal Simek ; computersforpe...@gmail.com; > dw...@infradead.org; > marek.va...@gmail.com > Subject: Re: [LINUX PATCH v12 3/3] mtd: rawnand: arasan: Add support for > Arasan NAND > Flash Controller > > Hi Naga, > > Naga Sureshkumar Relli wrote on Tue, > 18 Jun 2019 22:44:24 -0600: > > > On Mon, Jan 28, 2019 at 10:27:39AM +0100, Miquel Raynal wrote: > > Hi Miquel, > > > > > Hi Naga, > > > > > > Naga Sureshkumar Relli wrote on Mon, 28 Jan > > > 2019 > > > 06:04:53 +: > > > > > > > Hi Boris & Miquel, > > > > > > > > Could you please provide your thoughts on this driver to support HW-ECC? > > > > As I said previously, there is no way to detect errors beyond N bit. > > > > I am ok to update the driver based on your inputs. > > > > > > We won't support the ECC engine. It simply cannot be used reliably. > > > > > > I am working on a generic ECC engine object. It's gonna take a few > > > months until it gets merged but after that you could update the > > > controller driver to drop any ECC-related function. Although the ECC > > > > Could you please let me know that, when can we expect generic ECC > > engine update in mtd NAND? > > Based on that, i will plan to update the ARASAN NAND driver along with > > your comments mentioned above under this update, as you know there is > > a limiation in ARASAN NAND controller to detect ECC errors. > > i am following this series > > https://patchwork.kernel.org/patch/10838705/ > > It is gonna take more time than expected. You can stick to the software > engines for now. Ok. I will update the driver accordingly. Thanks, Naga Sureshkumar Relli > > Thanks, > Miquèl
Re: [PATCH] crypto: asymmetric_keys - select CRYPTO_HASH where needed
On Tue, Jun 18, 2019 at 02:13:47PM +0200, Arnd Bergmann wrote: > Build testing with some core crypto options disabled revealed > a few modules that are missing CRYPTO_HASH: > > crypto/asymmetric_keys/x509_public_key.o: In function `x509_get_sig_params': > x509_public_key.c:(.text+0x4c7): undefined reference to `crypto_alloc_shash' > x509_public_key.c:(.text+0x5e5): undefined reference to `crypto_shash_digest' > crypto/asymmetric_keys/pkcs7_verify.o: In function `pkcs7_digest.isra.0': > pkcs7_verify.c:(.text+0xab): undefined reference to `crypto_alloc_shash' > pkcs7_verify.c:(.text+0x1b2): undefined reference to `crypto_shash_digest' > pkcs7_verify.c:(.text+0x3c1): undefined reference to `crypto_shash_update' > pkcs7_verify.c:(.text+0x411): undefined reference to `crypto_shash_finup' > > This normally doesn't show up in randconfig tests because there is > a large number of other options that select CRYPTO_HASH. > > Signed-off-by: Arnd Bergmann > --- > crypto/asymmetric_keys/Kconfig | 3 +++ > 1 file changed, 3 insertions(+) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 00/10] crypto: k3: Add sa2ul driver
On 28/06/19 9:49 AM, Herbert Xu wrote: On Tue, Jun 18, 2019 at 05:38:33PM +0530, Keerthy wrote: The series adds Crypto hardware accelerator support for SA2UL. SA2UL stands for security accelerator ultra lite. Please cc linux-cry...@vger.kernel.org. Okay. I will do that. Thanks,
Re: [PATCH 00/10] crypto: k3: Add sa2ul driver
On Tue, Jun 18, 2019 at 05:38:33PM +0530, Keerthy wrote: > The series adds Crypto hardware accelerator support for SA2UL. > SA2UL stands for security accelerator ultra lite. Please cc linux-cry...@vger.kernel.org. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH -next] bus: ti-sysc: remove set but not used variable 'quirks'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/bus/ti-sysc.c: In function sysc_reset:
drivers/bus/ti-sysc.c:1452:50: warning: variable quirks set but not used
[-Wunused-but-set-variable]
It is never used since commit e0db94fe87da ("bus: ti-sysc: Make
OCP reset work for sysstatus and sysconfig reset bits")
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/bus/ti-sysc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
index e6deabd..8cb5351 100644
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -1558,12 +1558,11 @@ static int sysc_rstctrl_reset_deassert(struct sysc
*ddata, bool reset)
*/
static int sysc_reset(struct sysc *ddata)
{
- int sysc_offset, syss_offset, sysc_val, rstval, quirks, error = 0;
+ int sysc_offset, syss_offset, sysc_val, rstval, error = 0;
u32 sysc_mask, syss_done;
sysc_offset = ddata->offsets[SYSC_SYSCONFIG];
syss_offset = ddata->offsets[SYSC_SYSSTATUS];
- quirks = ddata->cfg.quirks;
if (ddata->legacy_mode || sysc_offset < 0 ||
ddata->cap->regbits->srst_shift < 0 ||
--
2.7.4
[PATCH v3] mtd: spinand: read return badly if the last page has bitflips
In case of the last page containing bitflips (ret > 0),
spinand_mtd_read() will return that number of bitflips for the last
page. But to me it looks like it should instead return max_bitflips like
it does when the last page read returns with 0.
Signed-off-by: Weixiong Liao
Reviewed-by: Boris Brezillon
Reviewed-by: Frieder Schrempf
Cc: sta...@vger.kernel.org
Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs")
---
Changes since v2:
- Resend this patch with Cc and Fixes tags.
Changes since v1:
- More accurate description for this patch
---
drivers/mtd/nand/spi/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 556bfdb..6b9388d 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -511,12 +511,12 @@ static int spinand_mtd_read(struct mtd_info *mtd, loff_t
from,
if (ret == -EBADMSG) {
ecc_failed = true;
mtd->ecc_stats.failed++;
- ret = 0;
} else {
mtd->ecc_stats.corrected += ret;
max_bitflips = max_t(unsigned int, max_bitflips, ret);
}
+ ret = 0;
ops->retlen += iter.req.datalen;
ops->oobretlen += iter.req.ooblen;
}
--
1.9.1
Re: [PATCH] net: stmmac: add sanity check to device_property_read_u32_array call
On Tue, Jun 25, 2019 at 9:58 AM Colin Ian King wrote:
>
> On 25/06/2019 05:44, Martin Blumenstingl wrote:
> > Hi Colin,
> >
> > On Thu, Jun 20, 2019 at 3:34 AM Martin Blumenstingl
> > wrote:
> >>
> >> Hi Colin,
> >>
> >> On Wed, Jun 19, 2019 at 8:55 AM Colin Ian King
> >> wrote:
> >>>
> >>> On 19/06/2019 06:13, Martin Blumenstingl wrote:
> Hi Colin,
>
> > Currently the call to device_property_read_u32_array is not error
> > checked
> > leading to potential garbage values in the delays array that are then
> > used
> > in msleep delays. Add a sanity check to the property fetching.
> >
> > Addresses-Coverity: ("Uninitialized scalar variable")
> > Signed-off-by: Colin Ian King
> I have also sent a patch [0] to fix initialize the array.
> can you please look at my patch so we can work out which one to use?
>
> my concern is that the "snps,reset-delays-us" property is optional,
> the current dt-bindings documentation states that it's a required
> property. in reality it isn't, there are boards (two examples are
> mentioned in my patch: [0]) without it.
>
> so I believe that the resulting behavior has to be:
> 1. don't delay if this property is missing (instead of delaying for
> ms)
> 2. don't error out if this property is missing
>
> your patch covers #1, can you please check whether #2 is also covered?
> I tested case #2 when submitting my patch and it worked fine (even
> though I could not reproduce the garbage values which are being read
> on some boards)
> > in the meantime I have tested your patch.
> > when I don't set the "snps,reset-delays-us" property then I get the
> > following error:
> > invalid property snps,reset-delays-us
> >
> > my patch has landed in the meantime: [0]
> > how should we proceed with your patch?
>
> I'm out of the office today. I'll get back to you on this tomorrow.
gentle ping
(I will be away for the weekend but I can reply on Monday)
Re: [PATCH] powerpc/64s/radix: Define arch_ioremap_p4d_supported()
Hi Anshuman,
On Fri, 28 Jun 2019 09:14:46 +0530 Anshuman Khandual
wrote:
>
> On linux-next (next-20190627) this change has already been applied though a
> merge commit 153083a99fe431 ("Merge branch 'akpm-current/current'"). So we
> are good on this ? Or shall I send out a V2 for the original patch. Please
> suggest. Thank you.
Please send Andrew a v2.
--
Cheers,
Stephen Rothwell
pgpmAevjbiceQ.pgp
Description: OpenPGP digital signature
[PATCH -next] mmc: sdhci_am654: Make some symbols static
Fix sparse warnings:
drivers/mmc/host/sdhci_am654.c:192:6: warning: symbol
'sdhci_j721e_4bit_set_clock' was not declared. Should it be static?
drivers/mmc/host/sdhci_am654.c:261:18: warning: symbol 'sdhci_j721e_8bit_ops'
was not declared. Should it be static?
drivers/mmc/host/sdhci_am654.c:284:18: warning: symbol 'sdhci_j721e_4bit_ops'
was not declared. Should it be static?
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/mmc/host/sdhci_am654.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c
index 3b39481..bb90757 100644
--- a/drivers/mmc/host/sdhci_am654.c
+++ b/drivers/mmc/host/sdhci_am654.c
@@ -189,7 +189,8 @@ static void sdhci_am654_set_clock(struct sdhci_host *host,
unsigned int clock)
}
}
-void sdhci_j721e_4bit_set_clock(struct sdhci_host *host, unsigned int clock)
+static void sdhci_j721e_4bit_set_clock(struct sdhci_host *host,
+ unsigned int clock)
{
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_am654_data *sdhci_am654 = sdhci_pltfm_priv(pltfm_host);
@@ -258,7 +259,7 @@ static const struct sdhci_am654_driver_data
sdhci_am654_drvdata = {
.flags = IOMUX_PRESENT | FREQSEL_2_BIT | STRBSEL_4_BIT | DLL_PRESENT,
};
-struct sdhci_ops sdhci_j721e_8bit_ops = {
+static struct sdhci_ops sdhci_j721e_8bit_ops = {
.get_max_clock = sdhci_pltfm_clk_get_max_clock,
.get_timeout_clock = sdhci_pltfm_clk_get_max_clock,
.set_uhs_signaling = sdhci_set_uhs_signaling,
@@ -281,7 +282,7 @@ static const struct sdhci_am654_driver_data
sdhci_j721e_8bit_drvdata = {
.flags = DLL_PRESENT,
};
-struct sdhci_ops sdhci_j721e_4bit_ops = {
+static struct sdhci_ops sdhci_j721e_4bit_ops = {
.get_max_clock = sdhci_pltfm_clk_get_max_clock,
.get_timeout_clock = sdhci_pltfm_clk_get_max_clock,
.set_uhs_signaling = sdhci_set_uhs_signaling,
--
2.7.4
Re: [PATCH] selftests/powerpc: ppc_asm.h: typo in the header guard
Denis Efremov writes: > The guard macro __PPC_ASM_H in the header ppc_asm.h > doesn't match the #ifndef macro _PPC_ASM_H. The patch > makes them the same. > > Signed-off-by: Denis Efremov > --- > tools/testing/selftests/powerpc/stringloops/asm/ppc_asm.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) I'll merge this. Please include linuxppc-dev on powerpc selftest patches. cheers > diff --git a/tools/testing/selftests/powerpc/stringloops/asm/ppc_asm.h > b/tools/testing/selftests/powerpc/stringloops/asm/ppc_asm.h > index d2c0a911f55e..2b488b78c4f2 100644 > --- a/tools/testing/selftests/powerpc/stringloops/asm/ppc_asm.h > +++ b/tools/testing/selftests/powerpc/stringloops/asm/ppc_asm.h > @@ -1,6 +1,6 @@ > /* SPDX-License-Identifier: GPL-2.0 */ > #ifndef _PPC_ASM_H > -#define __PPC_ASM_H > +#define _PPC_ASM_H > #include > > #ifndef r1 > -- > 2.21.0
linux-next: build failure after merge of the battery tree
Hi all,
After merging the battery tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/power/supply/wilco-charger.c: In function 'wilco_charge_get_property':
drivers/power/supply/wilco-charger.c:104:8: error: implicit declaration of
function 'wilco_ec_get_byte_property'; did you mean
'wilco_charge_get_property'? [-Werror=implicit-function-declaration]
ret = wilco_ec_get_byte_property(ec, property_id, );
^~
wilco_charge_get_property
drivers/power/supply/wilco-charger.c: In function 'wilco_charge_set_property':
drivers/power/supply/wilco-charger.c:130:10: error: implicit declaration of
function 'wilco_ec_set_byte_property'; did you mean
'wilco_charge_set_property'? [-Werror=implicit-function-declaration]
return wilco_ec_set_byte_property(ec, PID_CHARGE_MODE, mode);
^~
wilco_charge_set_property
Caused by commit
0736343e4c56 ("power_supply: wilco_ec: Add charging config driver")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgp6wAJRU4s5I.pgp
Description: OpenPGP digital signature
Re: [PATCHv5] mm/gup: speed up check_and_migrate_cma_pages() on huge page
On Fri, Jun 28, 2019 at 7:25 AM Andrew Morton wrote:
>
> On Thu, 27 Jun 2019 13:15:45 +0800 Pingfan Liu wrote:
>
> > Both hugetlb and thp locate on the same migration type of pageblock, since
> > they are allocated from a free_list[]. Based on this fact, it is enough to
> > check on a single subpage to decide the migration type of the whole huge
> > page. By this way, it saves (2M/4K - 1) times loop for pmd_huge on x86,
> > similar on other archs.
> >
> > Furthermore, when executing isolate_huge_page(), it avoid taking global
> > hugetlb_lock many times, and meanless remove/add to the local link list
> > cma_page_list.
> >
>
> Thanks, looks good to me. Have any timing measurements been taken?
Not yet. It is a little hard to force huge page to be allocated CMA
area. Should I provide the measurements?
>
> > ...
> >
> > --- a/mm/gup.c
> > +++ b/mm/gup.c
> > @@ -1336,25 +1336,30 @@ static long check_and_migrate_cma_pages(struct
> > task_struct *tsk,
> > struct vm_area_struct **vmas,
> > unsigned int gup_flags)
> > {
> > - long i;
> > + long i, step;
>
> I'll make these variables unsigned long - to match nr_pages and because
> we have no need for them to be negative.
OK, will fix it.
Thanks,
Pingfan
>
> > ...
Re: [PATCH 08/16] nfsd: escape high characters in binary data
On Thu, Jun 27, 2019 at 04:21:24PM -0400, J. Bruce Fields wrote: > No, I was confused: "\n" is non-printable according to isprint(), so > ESCAPE_ANY_NP *will* escape it. So this isn't quite so bad. SSIDs are > usually printed as '%*pE', so arguably we should be escaping the single > quote character too, but at least we're not allowing line breaks > through. I don't know about non-ascii. Okay, cool. Given that most things are just trying to log, it seems like it should be safe to have %pE escape non-ascii, non-printable, \, ', and "? And if we changing that, we're likely changing string_escape_mem(). Looking at callers of string_escape_mem() makes my head spin... Anyway, I don't want to block you needlessly. What would like to have be next steps here? -- Kees Cook
linux-next: manual merge of the battery tree with the pci tree
Hi all,
Today's linux-next merge of the battery tree got a conflict in:
Documentation/power/power_supply_class.txt
between commit:
151f4e2bdc7a ("docs: power: convert docs to ReST and rename to *.rst")
from the pci tree and commit:
49c9cd95bb6d ("power: supply: add input power and voltage limit properties")
from the battery tree.
I fixed it up (I deleted the file and adde the following merge fix patch)
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.
From: Stephen Rothwell
Date: Fri, 28 Jun 2019 13:52:44 +1000
Subject: [PATCH] power: supply: update for conversion to .rst
Signed-off-by: Stephen Rothwell
---
Documentation/power/power_supply_class.rst | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/power/power_supply_class.rst
b/Documentation/power/power_supply_class.rst
index 3f2c3fe38a61..883b2ef63119 100644
--- a/Documentation/power/power_supply_class.rst
+++ b/Documentation/power/power_supply_class.rst
@@ -166,6 +166,14 @@ INPUT_CURRENT_LIMIT
input current limit programmed by charger. Indicates
the current drawn from a charging source.
+INPUT_VOLTAGE_LIMIT
+ input voltage limit programmed by charger. Indicates
+ the voltage limit from a charging source.
+
+INPUT_POWER_LIMIT
+ input power limit programmed by charger. Indicates
+ the power limit from a charging source.
+
CHARGE_CONTROL_LIMIT
current charge control limit setting
CHARGE_CONTROL_LIMIT_MAX
--
2.20.1
--
Cheers,
Stephen Rothwell
pgpedwVjRcm0Y.pgp
Description: OpenPGP digital signature
Re: [RESEND PATCH v2] mtd: spinand: read return badly if the last page has bitflips
Hi Miquel,
On 2019/6/28 AM2:17, Miquel Raynal wrote:
> Hi Miquel,
>
> Miquel Raynal wrote on Thu, 27 Jun 2019
> 19:06:44 +0200:
>
>> Hello,
>>
>> Schrempf Frieder wrote on Tue, 25 Jun
>> 2019 07:04:06 +:
>>
>>> Hi liaoweixiong,
>>>
>>> On 25.06.19 05:08, Greg KH wrote:
On Tue, Jun 25, 2019 at 09:02:29AM +0800, liaoweixiong wrote:
> In case of the last page containing bitflips (ret > 0),
> spinand_mtd_read() will return that number of bitflips for the last
> page. But to me it looks like it should instead return max_bitflips like
> it does when the last page read returns with 0.
>
> Signed-off-by: liaoweixiong
>>
>> Please write your entire official first/last name(s)
>>
OK.
> Reviewed-by: Boris Brezillon
> Reviewed-by: Frieder Schrempf
>>
>> I am waiting your next version with Acked-by instead of Rewieved-by
>> tags and Greg's comment addressed.
>
> Sorry for the mistake, R-b tags are fine here, don't touch that.
> The rest needs to be fixed though.
>
OK.
> Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI
> NANDs")
>>
>> Finally, when we ask you to resend a patch, it means sending a new
>> version of the patch. So in the subject, you should not use the
>> [RESEND] keyword (which means you are sending something again exactly
>> as it was before, you just got ignored, for example) but instead you
>> should increment the version number (v3) and also write a nice
>> changelog after the three dashes '---' (will be ignored by Git when
>> applying).
>>
>> I would like to queue this for the next release so if you can do it
>> ASAP, that would be great.
>>
I will do it right now.
>> Thank you,
>> Miquèl
>
>
>
>
> Thanks,
> Miquèl
>
--
liaoweixiong
Hello
Pozdrowienia i jak twoja rodzina? Przepraszam za sposób, w jaki do ciebie podchodzę, ale to dlatego, że nie mam innego wyboru. Natknąłem się na Twój e-mail podczas przeglądania izby handlowej DTC i postanowiłem się z tobą skontaktować. Nazywam się Miss Victoria AbdulMagid Breish, Libijczyk po narodowości i córka późnego pana AbdulMagida AbdulSalam Breish z LIBYA. Mój zmarły ojciec był byłym przewodniczącym i dyrektorem generalnym Libyan Investment Authority, zanim został zabity przez siły NATO podczas libijskiej wojny domowej. Kontaktuję się z tobą w celu uzyskania pomocy i asystenta przy projekcie inwestycyjnym wartym dwadzieścia siedem milionów pięćset tysięcy dolarów amerykańskich (27, 500, 000, 00) pod twoim kierownictwem w twoim kraju. Jestem gotów wynegocjować z Tobą stosunek zysków do inwestycji i zysków w oparciu o przyszłe zyski z inwestycji. Możesz dowiedzieć się więcej o kryzysie: https://www.ndtv.com/world-news/un-unveils-proplays-to-end-libya-crisis-749348 Mój zmarły ojciec złożył ten fundusz w jednym z banków w Burkina Faso, a ja miałem na imię najbliższy krewny. Udało mi się przedostać do Burkina Faso, gdzie teraz mieszkam jako uchodźca pod rządową opieką bez matki. Po przyjeździe skontaktowałem się z bankiem, aby wyczyścić zdeponowany fundusz, ale dyrektor banku powiedział mi, że mój nieżyjący ojciec składa instrukcję na temat wpłacony fundusz, który muszę przedstawić zagranicznemu powiernikowi, który pomoże mi w inwestowaniu funduszu w dobry interes. Dyrektor banku doradził mi, aby przekazać powiernikowi, który stanie w moim imieniu za przekazanie funduszu. i dlatego kontaktuję się z tobą w tej chwili. ZE WZGLĘDU NA KRYZYS WYJŚCIOWY W LIBII uważam, że konieczne jest zróżnicowanie mojego planu inwestycyjnego poza granice zamorskie, aby zabezpieczyć się przed moją przyszłością. MAM NASTĘPUJĄCY PLAN INWESTYCJI NA TWOJE ROZWAŻANIE: A) Zarządzanie nieruchomościami B) Restauracja i hotel C) Zarządzanie szpitalem D) Produkcja żywności Jeśli masz inny opłacalny biznesplan, który może być zainteresowany zainwestowaniem w twoim kraju, uprzejmie odpowiedz na pilne informacje o tym, w jaki sposób fundusz inwestycyjny zostanie przekazany pod Twoją opiekę w celu dalszego inwestowania. Jednakże, gdy wyrazisz zainteresowanie pomocą, przekażę ci z niezbędną informacją o depozycie potwierdzenie Twojej zgody, aby pomóc mi w przekazaniu i inwestycji funduszu w twoim kraju. Będę bardzo szczęśliwy, jeśli odpiszesz mi w celu łatwej komunikacji, abyśmy mogli się poznać. Kiedy odpiszesz, podam ci moje zdjęcia i mój osobisty numer telefonu oraz więcej szczegółów o sobie w mojej następnej wiadomości. Proszę o bezpieczeństwo i poufny powód, odpowiedz mi przez mój osobisty adres e-mail: vicktoria.abdulmagidbre...@yandex.com Twoja pilna odpowiedź zostanie doceniona. Z poważaniem,
linux-next: manual merge of the battery tree with the mfd tree
Hi all,
Today's linux-next merge of the battery tree got conflicts in:
drivers/power/supply/Kconfig
drivers/power/supply/Makefile
between commit:
f8c7f7ddd8ef ("power: supply: Initial support for ROHM BD70528 PMIC charger
block")
from the mfd tree and commit:
0736343e4c56 ("power_supply: wilco_ec: Add charging config driver")
from the battery 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/power/supply/Kconfig
index 4a3cd679295b,4c01598f5ccb..
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@@ -689,13 -702,13 +703,22 @@@ config CHARGER_UCS100
Say Y to enable support for Microchip UCS1002 Programmable
USB Port Power Controller with Charger Emulation.
+config CHARGER_BD70528
+ tristate "ROHM bd70528 charger driver"
+ depends on MFD_ROHM_BD70528
+ default n
+ help
+ Say Y here to enable support for getting battery status
+ information and altering charger configurations from charger
+ block of the ROHM BD70528 Power Management IC.
+
+ config CHARGER_WILCO
+ tristate "Wilco EC based charger for ChromeOS"
+ depends on WILCO_EC
+ help
+ Say Y here to enable control of the charging routines performed
+ by the Embedded Controller on the Chromebook named Wilco. Further
+ information can be found in
+ Documentation/ABI/testing/sysfs-class-power-wilco
+
endif # POWER_SUPPLY
diff --cc drivers/power/supply/Makefile
index 346a8ef5f348,d2263e1e2b6f..
--- a/drivers/power/supply/Makefile
+++ b/drivers/power/supply/Makefile
@@@ -90,4 -91,4 +91,5 @@@ obj-$(CONFIG_CHARGER_CROS_USBPD) += cro
obj-$(CONFIG_CHARGER_SC2731) += sc2731_charger.o
obj-$(CONFIG_FUEL_GAUGE_SC27XX) += sc27xx_fuel_gauge.o
obj-$(CONFIG_CHARGER_UCS1002) += ucs1002_power.o
+obj-$(CONFIG_CHARGER_BD70528) += bd70528-charger.o
+ obj-$(CONFIG_CHARGER_WILCO) += wilco-charger.o
pgpxNqZrWcDSf.pgp
Description: OpenPGP digital signature
Re: [RFC 1/2] arm64/mm: Change THP helpers to comply with generic MM semantics
On 06/27/2019 09:01 PM, Zi Yan wrote: > On 27 Jun 2019, at 8:48, Anshuman Khandual wrote: > >> pmd_present() and pmd_trans_huge() are expected to behave in the following >> manner during various phases of a given PMD. It is derived from a previous >> detailed discussion on this topic [1] and present THP documentation [2]. >> >> pmd_present(pmd): >> >> - Returns true if pmd refers to system RAM with a valid pmd_page(pmd) >> - Returns false if pmd does not refer to system RAM - Invalid pmd_page(pmd) >> >> pmd_trans_huge(pmd): >> >> - Returns true if pmd refers to system RAM and is a trans huge mapping >> >> - >> |PMD states | pmd_present | pmd_trans_huge | >> - >> |Mapped | Yes | Yes | >> - >> |Splitting | Yes | Yes | >> - >> |Migration/Swap | No | No | >> - >> >> The problem: >> >> PMD is first invalidated with pmdp_invalidate() before it's splitting. This >> invalidation clears PMD_SECT_VALID as below. >> >> PMD Split -> pmdp_invalidate() -> pmd_mknotpresent -> Clears PMD_SECT_VALID >> >> Once PMD_SECT_VALID gets cleared, it results in pmd_present() return false >> on the PMD entry. It will need another bit apart from PMD_SECT_VALID to re- >> affirm pmd_present() as true during the THP split process. To comply with >> above mentioned semantics, pmd_trans_huge() should also check pmd_present() >> first before testing presence of an actual transparent huge mapping. >> >> The solution: >> >> Ideally PMD_TYPE_SECT should have been used here instead. But it shares the >> bit position with PMD_SECT_VALID which is used for THP invalidation. Hence >> it will not be there for pmd_present() check after pmdp_invalidate(). >> >> PTE_SPECIAL never gets used for PMD mapping i.e there is no pmd_special(). >> Hence this bit can be set on the PMD entry during invalidation which can >> help in making pmd_present() return true and in recognizing the fact that >> it still points to memory. >> >> This bit is transient. During the split is process it will be overridden >> by a page table page representing the normal pages in place of erstwhile >> huge page. Other pmdp_invalidate() callers always write a fresh PMD value >> on the entry overriding this transient PTE_SPECIAL making it safe. In the >> past former pmd_[mk]splitting() functions used PTE_SPECIAL. >> >> [1]: https://lkml.org/lkml/2018/10/17/231 > > Just want to point out that lkml.org link might not be stable. > This one would be better: > https://lore.kernel.org/linux-mm/20181017020930.gn30...@redhat.com/ Sure will update the link in the commit. Thanks !
Re: [PATCH] powerpc/64s/radix: Define arch_ioremap_p4d_supported()
On 06/27/2019 10:18 AM, Michael Ellerman wrote:
> Anshuman Khandual writes:
>> Recent core ioremap changes require HAVE_ARCH_HUGE_VMAP subscribing archs
>> provide arch_ioremap_p4d_supported() failing which will result in a build
>> failure like the following.
>>
>> ld: lib/ioremap.o: in function `.ioremap_huge_init':
>> ioremap.c:(.init.text+0x3c): undefined reference to
>> `.arch_ioremap_p4d_supported'
>>
>> This defines a stub implementation for arch_ioremap_p4d_supported() keeping
>> it disabled for now to fix the build problem.
>
> The easiest option is for this to be folded into your patch that creates
> the requirement for arch_ioremap_p4d_supported().
>
> Andrew might do that for you, or you could send a v2.
>
> This looks fine from a powerpc POV:
>
> Acked-by: Michael Ellerman
>
> cheers
Hello Stephen/Michael/Andrew,
On linux-next (next-20190627) this change has already been applied though a
merge commit 153083a99fe431 ("Merge branch 'akpm-current/current'"). So we
are good on this ? Or shall I send out a V2 for the original patch. Please
suggest. Thank you.
- Anshuman
Re: [PATCH 32/87] usb: pvrusb2: replace kmalloc and memset with kzalloc in pvrusb2-eeprom.c
Acked-by: Mike Isely
-Mike
On Fri, 28 Jun 2019, Fuqian Huang wrote:
> kmalloc + memset(0) -> kzalloc
>
> Signed-off-by: Fuqian Huang
> ---
> drivers/media/usb/pvrusb2/pvrusb2-eeprom.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-eeprom.c
> b/drivers/media/usb/pvrusb2/pvrusb2-eeprom.c
> index 79f0e0c6df37..fac90af8b537 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-eeprom.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-eeprom.c
> @@ -39,7 +39,7 @@ static u8 *pvr2_eeprom_fetch(struct pvr2_hdw *hdw)
> int ret;
> int mode16 = 0;
> unsigned pcnt,tcnt;
> - eeprom = kmalloc(EEPROM_SIZE,GFP_KERNEL);
> + eeprom = kzalloc(EEPROM_SIZE,GFP_KERNEL);
> if (!eeprom) {
> pvr2_trace(PVR2_TRACE_ERROR_LEGS,
> "Failed to allocate memory required to read eeprom");
> @@ -74,7 +74,6 @@ static u8 *pvr2_eeprom_fetch(struct pvr2_hdw *hdw)
> (1) we're only fetching part of the eeprom, and (2) if we were
> getting the whole thing our I2C driver can't grab it in one
> pass - which is what tveeprom is otherwise going to attempt */
> - memset(eeprom,0,EEPROM_SIZE);
> for (tcnt = 0; tcnt < EEPROM_SIZE; tcnt += pcnt) {
> pcnt = 16;
> if (pcnt + tcnt > EEPROM_SIZE) pcnt = EEPROM_SIZE-tcnt;
>
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
Re: [PATCH] objtool: Be lenient about -Wundef
On Fri, Jun 28, 2019 at 8:00 AM Josh Poimboeuf wrote: > > On Wed, Jun 19, 2019 at 05:03:37AM -0700, Olof Johansson wrote: > > Some libelf versions use undefined macros, which combined with newer GCC > > makes for errors from system headers. This isn't overly useful to fail > > compiling objtool for. > > > > Error as seen: > > > > cc1: all warnings being treated as errors > > In file included from arch/x86/../../elf.h:10, > > from arch/x86/decode.c:14: > > /usr/include/libelf/gelf.h:25:5: error: "__LIBELF_INTERNAL__" is not > > defined, evaluates to 0 [-Werror=undef] > > #if __LIBELF_INTERNAL__ > > ^~~ > > > > For this reason, skip -Wundef on objtool. > > > > Signed-off-by: Olof Johansson > > Sorry for the delay, I was out last week and I'm still getting caught > up. > > Which libelf was this? I'm guessing it's the old non-elfutils version > which has been unmaintained for 10 years (and which doesn't work with > objtool anyway). > > It would be nice if we could figure out a way to detect that libelf and > report a more useful error for it. Yeah, looks like my docker image pulled in the very old libelf 0.8.13, but has elfutils available. I'll switch it over locally to resolve this. -Olof
[PATCH V3 4/5] arm64: dts: imx8mq: Add system counter node
From: Anson Huang
Add i.MX8MQ system counter node to enable timer-imx-sysctr
broadcast timer driver.
Signed-off-by: Anson Huang
---
No changes.
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index b1114a6..bea53bc 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -636,6 +636,14 @@
#pwm-cells = <2>;
status = "disabled";
};
+
+ system_counter: timer@306a {
+ compatible = "nxp,sysctr-timer";
+ reg = <0x306a 0x3>;
+ interrupts = ,
+;
+ clock-frequency = <833>;
+ };
};
bus@3080 { /* AIPS3 */
--
2.7.4
[PATCH V3 3/5] clocksource: imx-sysctr: Make timer work with clock driver using platform driver model
From: Anson Huang
On some i.MX8M platforms, clock driver uses platform driver
model and it is NOT ready during timer initialization phase,
the clock operations will fail and system counter driver will
fail too. As all the i.MX8M platforms' system counter clock
are from OSC which is always enabled, so it is no need to enable
clock for system counter driver, the ONLY thing is to pass
clock frequence to driver.
To make system counter driver work for upper scenario, if DT's
system counter node has property "clock-frequency" present,
setting TIMER_OF_CLOCK_FREQUENCY flag to indicate timer-of driver
to get clock frequency from DT directly instead of of_clk operation
via clk APIs.
Signed-off-by: Anson Huang
---
Changes since V2:
- do runtime check to decide whether using TIMER_OF_CLOCK_FREQUENCY or
TIMER_OF_CLOCK
according to DT node settings.
---
drivers/clocksource/timer-imx-sysctr.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/clocksource/timer-imx-sysctr.c
b/drivers/clocksource/timer-imx-sysctr.c
index fd7d680..73e3193 100644
--- a/drivers/clocksource/timer-imx-sysctr.c
+++ b/drivers/clocksource/timer-imx-sysctr.c
@@ -98,7 +98,7 @@ static irqreturn_t sysctr_timer_interrupt(int irq, void
*dev_id)
}
static struct timer_of to_sysctr = {
- .flags = TIMER_OF_IRQ | TIMER_OF_CLOCK | TIMER_OF_BASE,
+ .flags = TIMER_OF_IRQ | TIMER_OF_BASE,
.clkevt = {
.name = "i.MX system counter timer",
.features = CLOCK_EVT_FEAT_ONESHOT |
@@ -114,6 +114,7 @@ static struct timer_of to_sysctr = {
},
.of_clk = {
.name = "per",
+ .prop_name = "clock-frequency",
},
};
@@ -130,6 +131,9 @@ static int __init sysctr_timer_init(struct device_node *np)
{
int ret = 0;
+ to_sysctr.flags |= of_find_property(np, "clock-frequency", NULL) ?
+ TIMER_OF_CLOCK_FREQUENCY : TIMER_OF_CLOCK;
+
ret = timer_of_init(np, _sysctr);
if (ret)
return ret;
--
2.7.4
[PATCH V3 1/5] clocksource: timer-of: Support getting clock frequency from DT
From: Anson Huang
More and more platforms use platform driver model for clock driver,
so the clock driver is NOT ready during timer initialization phase,
it will cause timer initialization failed.
To support those platforms with upper scenario, introducing a new
flag TIMER_OF_CLOCK_FREQUENCY which is mutually exclusive with
TIMER_OF_CLOCK flag to support getting timer clock frequency from
DT, then of_clk operations can be skipped.
User needs to select either TIMER_OF_CLOCK_FREQUENCY or TIMER_OF_CLOCK
flag if want to use timer-of driver to initialize the clock rate,
and the corresponding clock name or property name needs to be specified.
Signed-off-by: Anson Huang
---
New patch:
- Add new flag of TIMER_OF_CLOCK_FREQUENCY, mutually exclusive with
TIMER_OF_CLOCK, to support
getting clock frequency from DT directly;
- Add prop_name to of_timer_clk structure, if using
TIMER_OF_CLOCK_FREQUENCY flag, user needs
to pass the property name for timer-of driver to get clock frequency
from DT, this is to avoid
the couple of timer-of driver and DT, so timer-of driver does NOT use
a fixed property name.
---
drivers/clocksource/timer-of.c | 23 +++
drivers/clocksource/timer-of.h | 8 +---
2 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/clocksource/timer-of.c b/drivers/clocksource/timer-of.c
index 8054228..c91a8b6 100644
--- a/drivers/clocksource/timer-of.c
+++ b/drivers/clocksource/timer-of.c
@@ -161,6 +161,21 @@ static __init int timer_of_base_init(struct device_node
*np,
return 0;
}
+static __init int timer_of_clk_frequency_init(struct device_node *np,
+ struct of_timer_clk *of_clk)
+{
+ int ret;
+ u32 rate;
+
+ ret = of_property_read_u32(np, of_clk->prop_name, );
+ if (!ret) {
+ of_clk->rate = rate;
+ of_clk->period = DIV_ROUND_UP(rate, HZ);
+ }
+
+ return ret;
+}
+
int __init timer_of_init(struct device_node *np, struct timer_of *to)
{
int ret = -EINVAL;
@@ -178,6 +193,11 @@ int __init timer_of_init(struct device_node *np, struct
timer_of *to)
if (ret)
goto out_fail;
flags |= TIMER_OF_CLOCK;
+ } else if (to->flags & TIMER_OF_CLOCK_FREQUENCY) {
+ ret = timer_of_clk_frequency_init(np, >of_clk);
+ if (ret)
+ goto out_fail;
+ flags |= TIMER_OF_CLOCK_FREQUENCY;
}
if (to->flags & TIMER_OF_IRQ) {
@@ -201,6 +221,9 @@ int __init timer_of_init(struct device_node *np, struct
timer_of *to)
if (flags & TIMER_OF_CLOCK)
timer_of_clk_exit(>of_clk);
+ if (flags & TIMER_OF_CLOCK_FREQUENCY)
+ to->of_clk.rate = 0;
+
if (flags & TIMER_OF_BASE)
timer_of_base_exit(>of_base);
return ret;
diff --git a/drivers/clocksource/timer-of.h b/drivers/clocksource/timer-of.h
index a5478f3..f1a083e 100644
--- a/drivers/clocksource/timer-of.h
+++ b/drivers/clocksource/timer-of.h
@@ -4,9 +4,10 @@
#include
-#define TIMER_OF_BASE 0x1
-#define TIMER_OF_CLOCK 0x2
-#define TIMER_OF_IRQ 0x4
+#define TIMER_OF_BASE 0x1
+#define TIMER_OF_CLOCK 0x2
+#define TIMER_OF_IRQ 0x4
+#define TIMER_OF_CLOCK_FREQUENCY 0x8
struct of_timer_irq {
int irq;
@@ -26,6 +27,7 @@ struct of_timer_base {
struct of_timer_clk {
struct clk *clk;
const char *name;
+ const char *prop_name;
int index;
unsigned long rate;
unsigned long period;
--
2.7.4
[PATCH V3 5/5] arm64: dts: imx8mm: Add system counter node
From: Anson Huang
Add i.MX8MM system counter node to enable timer-imx-sysctr
broadcast timer driver.
Signed-off-by: Anson Huang
---
New patch:
- As i.MX8MM clock driver will be soon moved to using platform driver
model, so the patch
series I sent out for i.MX8MM system counter driver support will need
rework accordingly,
so I add the i.MX8MM DT support in this patch series, it uses same
method as i.MX8MQ's
system counter driver.
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index 63f4731..aa985a0 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -528,6 +528,14 @@
#pwm-cells = <2>;
status = "disabled";
};
+
+ system_counter: timer@306a {
+ compatible = "nxp,sysctr-timer";
+ reg = <0x306a 0x3>;
+ interrupts = ,
+;
+ clock-frequency = <800>;
+ };
};
aips3: bus@3080 {
--
2.7.4
[PATCH V3 2/5] clocksource/drivers/sysctr: Add clock-frequency property
From: Anson Huang
Systems which use platform driver model for clock driver require the
clock frequency to be supplied via device tree when system counter
driver is enabled.
This is necessary as in the platform driver model the of_clk operations
do not work correctly because system counter driver is initialized in
early phase of system boot up, and clock driver using platform driver
model is NOT ready at that time, it will cause system counter driver
initialization failed.
Add clock-frequency property to the device tree bindings of the NXP
system counter, so the driver can tell timer-of driver to get clock
frequency from DT directly instead of doing of_clk operations via
clk APIs.
Signed-off-by: Anson Huang
---
Changes since V2:
- make clock-frequency property as required property, mutually
exclusive with clocks/clock-names.
- update the example using the DT node added in this patch series.
---
.../devicetree/bindings/timer/nxp,sysctr-timer.txt| 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt
b/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt
index d576599..7088a0e 100644
--- a/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt
+++ b/Documentation/devicetree/bindings/timer/nxp,sysctr-timer.txt
@@ -11,15 +11,18 @@ Required properties:
- reg : Specifies the base physical address and size of the comapre
frame and the counter control, read & compare.
- interrupts : should be the first compare frames' interrupt
-- clocks : Specifies the counter clock.
-- clock-names: Specifies the clock's name of this module
+- clocks : Specifies the counter clock, mutually exclusive with
clock-frequency.
+- clock-names : Specifies the clock's name of this module, mutually
exclusive with
+ clock-frequency.
+- clock-frequency : Specifies system counter clock frequency, mutually
exclusive with
+ clocks/clock-names.
Example:
system_counter: timer@306a {
compatible = "nxp,sysctr-timer";
- reg = <0x306a 0x2>;/* system-counter-rd & compare */
- clocks = <_8m>;
- clock-names = "per";
- interrupts = ;
+ reg = <0x306a 0x3>;
+ interrupts = ,
+;
+ clock-frequency = <833>;
};
--
2.7.4
Re: linux-next: Tree for May 8 (drivers/platform/x86/intel_pmc_core_plat_drv.c)
Hi Andy, On Tue, Jun 11, 2019 at 12:06 PM Andy Shevchenko wrote: > > On Thu, May 9, 2019 at 2:15 AM Rajat Jain wrote: > > > OK, NP. Just to be sure I understand, > > > > 1) Please let me know if I should send in a fix (it would be > > #include/linux/module.h and also add MODULE_LICENSE() I believe)? > > 2) Would this be lined up for next version though? > > Resend a complete series based on the latest stuff we have in our > for-next branch. My apologies for the delay in resending. I just sent a v7 of the patch that was dropped: https://lkml.org/lkml/2019/6/27/1264 Only 2 changes from the v6: #include and MODULE_LICENSE() Thanks & Best Regards, Rajat > > -- > With Best Regards, > Andy Shevchenko
Re: [PATCH v2] arm64: Kconfig.platforms: Enable GPIO_DAVINCI for ARCH_K3
On 27/06/19 8:02 PM, Nishanth Menon wrote: On 16:39-20190627, Keerthy wrote: Enable GPIO_DAVINCI and related configs for TI K3 AM6 platforms. Signed-off-by: Keerthy --- Changes in v2: * Enabling configs in Kconfig.platforms file instead of defconfig. * Removed GPIO_DEBUG config. arch/arm64/Kconfig.platforms | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 4778c775de1b..6e43a0995ed4 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -97,6 +97,8 @@ config ARCH_K3 select TI_SCI_PROTOCOL select TI_SCI_INTR_IRQCHIP select TI_SCI_INTA_IRQCHIP + select GPIO_SYSFS + select GPIO_DAVINCI Could you help explain the logic of doing this? commit message is basically the diff in English. To me, this does NOT make sense. I understand GPIO_DAVINCI is the driver compatible, but we cant do this for every single SoC driver that is NOT absolutely mandatory for basic functionality. In case of ARM64 could you help me find the right place to enable such SoC specific configs? Also keep in mind the impact to arm64/configs/defconfig -> every single SoC in the arm64 world will be now rebuild with GPIO_SYSFS.. why force that? This was the practice in arm32 soc specific configs like omap2plus_defconfig. GPIO_SYSFS was he only way to validate. Now i totally understand your concern about every single SoC rebuilding but now where do we need to enable the bare minimal GPIO_DAVINCI config? v1 i received feedback from Tero to enable in Kconfig.platforms. Hence i shifted to this approach.
[PATCH 1/2] arm64: dts: imx8mq: Correct OPP table according to latest datasheet
From: Anson Huang
According to latest datasheet (Rev.1, 10/2018) from below links,
in the consumer datasheet, 1.5GHz is mentioned as highest opp but
depends on speed grading fuse, and in the industrial datasheet,
1.3GHz is mentioned as highest opp but depends on speed grading
fuse. 1.5GHz and 1.3GHz opp use same voltage, so no need for
consumer part to support 1.3GHz opp, with same voltage, CPU should
run at highest frequency in order to go into idle as quick as
possible, this can save power.
That means for consumer part, 1GHz/1.5GHz are supported, for
industrial part, 800MHz/1.3GHz are supported, and then check the
speed grading fuse to limit the highest CPU frequency further.
Correct the market segment bits in opp table to make them work
according to datasheets.
https://www.nxp.com/docs/en/data-sheet/IMX8MDQLQIEC.pdf
https://www.nxp.com/docs/en/data-sheet/IMX8MDQLQCEC.pdf
Fixes: 12629c5c3749 ("arm64: dts: imx8mq: Add cpu speed grading and all OPPs")
Signed-off-by: Anson Huang
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 9d99191..bea53bc 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -169,7 +169,8 @@
opp-13 {
opp-hz = /bits/ 64 <13>;
opp-microvolt = <100>;
- opp-supported-hw = <0xc>, <0x7>;
+ /* Industrial only but rely on speed grading */
+ opp-supported-hw = <0xc>, <0x4>;
clock-latency-ns = <15>;
};
@@ -177,7 +178,7 @@
opp-hz = /bits/ 64 <15>;
opp-microvolt = <100>;
/* Consumer only but rely on speed grading */
- opp-supported-hw = <0x8>, <0x7>;
+ opp-supported-hw = <0x8>, <0x3>;
clock-latency-ns = <15>;
};
};
--
2.7.4
[PATCH 2/2] arm64: dts: imx8mm: Correct OPP table according to latest datasheet
From: Anson Huang According to latest datasheet (Rev.0.2, 04/2019) from below links, 1.8GHz is ONLY available for consumer part, so the market segment bits for 1.8GHz opp should ONLY available for consumer part accordingly. https://www.nxp.com/docs/en/data-sheet/IMX8MMIEC.pdf https://www.nxp.com/docs/en/data-sheet/IMX8MMCEC.pdf Fixes: f403a26c865b (arm64: dts: imx8mm: Add cpu speed grading and all OPPs) Signed-off-by: Anson Huang --- arch/arm64/boot/dts/freescale/imx8mm.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi index c38813d..ab0d135 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi @@ -135,7 +135,7 @@ opp-hz = /bits/ 64 <18>; opp-microvolt = <100>; /* Consumer only but rely on speed grading */ - opp-supported-hw = <0x8>, <0x7>; + opp-supported-hw = <0x8>, <0x3>; clock-latency-ns = <15>; }; }; -- 2.7.4
[PATCH V2] soc: imx-scu: Add SoC UID(unique identifier) support
From: Anson Huang
Add i.MX SCU SoC's UID(unique identifier) support, user
can read it from sysfs:
root@imx8qxpmek:~# cat /sys/devices/soc0/soc_uid
7B64280B57AC1898
Signed-off-by: Anson Huang
---
Changes since V1:
- Improve the comment of skipping SCFW API return value check for
getting UID.
---
drivers/soc/imx/soc-imx-scu.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/drivers/soc/imx/soc-imx-scu.c b/drivers/soc/imx/soc-imx-scu.c
index 676f612..3eacb54 100644
--- a/drivers/soc/imx/soc-imx-scu.c
+++ b/drivers/soc/imx/soc-imx-scu.c
@@ -27,6 +27,40 @@ struct imx_sc_msg_misc_get_soc_id {
} data;
} __packed;
+struct imx_sc_msg_misc_get_soc_uid {
+ struct imx_sc_rpc_msg hdr;
+ u32 uid_low;
+ u32 uid_high;
+} __packed;
+
+static ssize_t soc_uid_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct imx_sc_msg_misc_get_soc_uid msg;
+ struct imx_sc_rpc_msg *hdr =
+ u64 soc_uid;
+
+ hdr->ver = IMX_SC_RPC_VERSION;
+ hdr->svc = IMX_SC_RPC_SVC_MISC;
+ hdr->func = IMX_SC_MISC_FUNC_UNIQUE_ID;
+ hdr->size = 1;
+
+ /*
+* SCU FW API always returns an error even the
+* function is successfully executed, so skip
+* returned value check.
+*/
+ imx_scu_call_rpc(soc_ipc_handle, , true);
+
+ soc_uid = msg.uid_high;
+ soc_uid <<= 32;
+ soc_uid |= msg.uid_low;
+
+ return sprintf(buf, "%016llX\n", soc_uid);
+}
+
+static DEVICE_ATTR_RO(soc_uid);
+
static int imx_scu_soc_id(void)
{
struct imx_sc_msg_misc_get_soc_id msg;
@@ -102,6 +136,11 @@ static int imx_scu_soc_probe(struct platform_device *pdev)
goto free_revision;
}
+ ret = device_create_file(soc_device_to_device(soc_dev),
+_attr_soc_uid);
+ if (ret)
+ goto free_revision;
+
return 0;
free_revision:
--
2.7.4
Re: power9 NUMA crash while reading debugfs imc_cmd
> On Jun 27, 2019, at 11:12 PM, Michael Ellerman wrote: > > Qian Cai writes: >> Read of debugfs imc_cmd file for a memory-less node will trigger a crash >> below >> on this power9 machine which has the following NUMA layout. > > What type of machine is it? description: PowerNV product: 8335-GTH (ibm,witherspoon) vendor: IBM width: 64 bits capabilities: smp powernv opal > > cheers > >> I don't understand why I only saw it recently on linux-next where it >> was tested everyday. I can reproduce it back to 4.20 where 4.18 seems >> work fine. >> >> # cat /sys/kernel/debug/powerpc/imc/imc_cmd_252 (On a 4.18-based kernel) >> 0x >> >> # numactl -H >> available: 6 nodes (0,8,252-255) >> node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 >> 24 25 >> 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 >> 51 52 >> 53 54 55 56 57 58 59 60 61 62 63 >> node 0 size: 130210 MB >> node 0 free: 128406 MB >> node 8 cpus: 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 >> 85 >> 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 >> 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 >> node 8 size: 130784 MB >> node 8 free: 130051 MB >> node 252 cpus: >> node 252 size: 0 MB >> node 252 free: 0 MB >> node 253 cpus: >> node 253 size: 0 MB >> node 253 free: 0 MB >> node 254 cpus: >> node 254 size: 0 MB >> node 254 free: 0 MB >> node 255 cpus: >> node 255 size: 0 MB >> node 255 free: 0 MB >> node distances: >> node 0 8 252 253 254 255 >> 0: 10 40 80 80 80 80 >> 8: 40 10 80 80 80 80 >> 252: 80 80 10 80 80 80 >> 253: 80 80 80 10 80 80 >> 254: 80 80 80 80 10 80 >> 255: 80 80 80 80 80 10 >> >> # cat /sys/kernel/debug/powerpc/imc/imc_cmd_252 >> >> [ 1139.415461][ T5301] Faulting instruction address: 0xc00d0d58 >> [ 1139.415492][ T5301] Oops: Kernel access of bad area, sig: 11 [#1] >> [ 1139.415509][ T5301] LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=256 >> DEBUG_PAGEALLOC NUMA PowerNV >> [ 1139.415542][ T5301] Modules linked in: i2c_opal i2c_core ip_tables >> x_tables >> xfs sd_mod bnx2x mdio ahci libahci tg3 libphy libata firmware_class dm_mirror >> dm_region_hash dm_log dm_mod >> [ 1139.415595][ T5301] CPU: 67 PID: 5301 Comm: cat Not tainted >> 5.2.0-rc6-next- >> 20190627+ #19 >> [ 1139.415634][ T5301] NIP: c00d0d58 LR: c049aa18 CTR: >> c00d0d50 >> [ 1139.415675][ T5301] REGS: c00020194548f9e0 TRAP: 0300 Not tainted >> (5.2.0- >> rc6-next-20190627+) >> [ 1139.415705][ T5301] MSR: 90009033 CR: >> 28022822 XER: >> [ 1139.415777][ T5301] CFAR: c049aa14 DAR: 0003fc08 DSISR: >> 4000 IRQMASK: 0 >> [ 1139.415777][ T5301] GPR00: c049aa18 c00020194548fc70 >> c16f8b00 >> 0003fc08 >> [ 1139.415777][ T5301] GPR04: c00020194548fcd0 >> 14884e73 >> 00011eaa >> [ 1139.415777][ T5301] GPR08: 7eea5a52 c00d0d50 >> >> >> [ 1139.415777][ T5301] GPR12: c00d0d50 c000201fff7f8c00 >> >> >> [ 1139.415777][ T5301] GPR16: 000d 7fffeb0c3368 >> >> >> [ 1139.415777][ T5301] GPR20: >> >> 0002 >> [ 1139.415777][ T5301] GPR24: >> 0002 >> 00010ec9 >> [ 1139.415777][ T5301] GPR28: c00020194548fdf0 c00020049a584ef8 >> >> c00020049a584ea8 >> [ 1139.416116][ T5301] NIP [c00d0d58] imc_mem_get+0x8/0x20 >> [ 1139.416143][ T5301] LR [c049aa18] simple_attr_read+0x118/0x170 >> [ 1139.416158][ T5301] Call Trace: >> [ 1139.416182][ T5301] [c00020194548fc70] [c049a970] >> simple_attr_read+0x70/0x170 (unreliable) >> [ 1139.416255][ T5301] [c00020194548fd10] [c054385c] >> debugfs_attr_read+0x6c/0xb0 >> [ 1139.416305][ T5301] [c00020194548fd60] [c0454c1c] >> __vfs_read+0x3c/0x70 >> [ 1139.416363][ T5301] [c00020194548fd80] [c0454d0c] >> vfs_read+0xbc/0x1a0 >> [ 1139.416392][ T5301] [c00020194548fdd0] [c045519c] >> ksys_read+0x7c/0x140 >> [ 1139.416434][ T5301] [c00020194548fe20] [c000b108] >> system_call+0x5c/0x70 >> [ 1139.416473][ T5301] Instruction dump: >> [ 1139.416511][ T5301] 4e800020 6000 7c0802a6 6000 7c801d28 3860 >> 4e800020 6000 >> [ 1139.416572][ T5301] 6000 6000 7c0802a6 6000 <7d201c28> >> 3860 >> f924 4e800020 >> [ 1139.416636][ T5301] ---[ end trace c44d1fb4ace04784 ]--- >> [ 1139.520686][ T5301] >> [ 1140.520820][ T5301] Kernel panic - not syncing: Fatal exception
[PATCH v7] platform/x86: intel_pmc_core: Attach using APCI HID "INT33A1"
Most modern platforms already have the ACPI device "INT33A1" that could
be used to attach to the driver. Switch the driver to using that and
thus make the intel_pmc_core.c a pure platform_driver.
Some of the legacy platforms though, may still not have this ACPI device
in their ACPI tables. Thus for such platforms, move the code to manually
instantiate a platform_device into a new file of its own. This would
instantiate the intel_pmc_core platform device and thus attach to
the driver, if the ACPI device for the same ("INT33A1") is not present
in a system where it should be. This was discussed here:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1966991.html
Signed-off-by: Rajat Jain
---
v7: Include module.h and add MODULE_LICENSE()
v6: was here: https://patchwork.kernel.org/patch/10906387/
(The patchset was accepted, but this particular patch was later
dropped becasue it created some warnings in certain kernel
configurations: https://www.spinics.net/lists/linux-next/msg47611.html)
drivers/platform/x86/Makefile | 2 +-
drivers/platform/x86/intel_pmc_core.c | 40 +++-
.../platform/x86/intel_pmc_core_plat_drv.c| 62 +++
3 files changed, 71 insertions(+), 33 deletions(-)
create mode 100644 drivers/platform/x86/intel_pmc_core_plat_drv.c
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 87b0069bd781..4ba707111c27 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -89,7 +89,7 @@ obj-$(CONFIG_INTEL_BXTWC_PMIC_TMU)+= intel_bxtwc_tmu.o
obj-$(CONFIG_INTEL_TELEMETRY) += intel_telemetry_core.o \
intel_telemetry_pltdrv.o \
intel_telemetry_debugfs.o
-obj-$(CONFIG_INTEL_PMC_CORE)+= intel_pmc_core.o
+obj-$(CONFIG_INTEL_PMC_CORE)+= intel_pmc_core.o intel_pmc_core_plat_drv.o
obj-$(CONFIG_PMC_ATOM) += pmc_atom.o
obj-$(CONFIG_MLX_PLATFORM) += mlx-platform.o
obj-$(CONFIG_INTEL_TURBO_MAX_3) += intel_turbo_max_3.o
diff --git a/drivers/platform/x86/intel_pmc_core.c
b/drivers/platform/x86/intel_pmc_core.c
index 1d902230ba61..f20d08ad39ea 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -1023,47 +1023,23 @@ static const struct dev_pm_ops pmc_core_pm_ops = {
SET_LATE_SYSTEM_SLEEP_PM_OPS(pmc_core_suspend, pmc_core_resume)
};
+static const struct acpi_device_id pmc_core_acpi_ids[] = {
+ {"INT33A1", 0}, /* _HID for Intel Power Engine, _CID PNP0D80*/
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, pmc_core_acpi_ids);
+
static struct platform_driver pmc_core_driver = {
.driver = {
.name = "intel_pmc_core",
+ .acpi_match_table = ACPI_PTR(pmc_core_acpi_ids),
.pm = _core_pm_ops,
},
.probe = pmc_core_probe,
.remove = pmc_core_remove,
};
-static struct platform_device pmc_core_device = {
- .name = "intel_pmc_core",
-};
-
-static int __init pmc_core_init(void)
-{
- int ret;
-
- if (!x86_match_cpu(intel_pmc_core_ids))
- return -ENODEV;
-
- ret = platform_driver_register(_core_driver);
- if (ret)
- return ret;
-
- ret = platform_device_register(_core_device);
- if (ret) {
- platform_driver_unregister(_core_driver);
- return ret;
- }
-
- return 0;
-}
-
-static void __exit pmc_core_exit(void)
-{
- platform_device_unregister(_core_device);
- platform_driver_unregister(_core_driver);
-}
-
-module_init(pmc_core_init)
-module_exit(pmc_core_exit)
+module_platform_driver(pmc_core_driver);
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("Intel PMC Core Driver");
diff --git a/drivers/platform/x86/intel_pmc_core_plat_drv.c
b/drivers/platform/x86/intel_pmc_core_plat_drv.c
new file mode 100644
index ..a8754a6db1b8
--- /dev/null
+++ b/drivers/platform/x86/intel_pmc_core_plat_drv.c
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Intel PMC Core platform init
+ * Copyright (c) 2019, Google Inc.
+ * Author - Rajat Jain
+ *
+ * This code instantiates platform devices for intel_pmc_core driver, only
+ * on supported platforms that may not have the ACPI devices in the ACPI
tables.
+ * No new platforms should be added here, because we expect that new platforms
+ * should all have the ACPI device, which is the preferred way of enumeration.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+
+static struct platform_device pmc_core_device = {
+ .name = "intel_pmc_core",
+};
+
+/*
+ * intel_pmc_core_platform_ids is the list of platforms where we want to
+ * instantiate the platform_device if not already instantiated. This is
+ * different than intel_pmc_core_ids in intel_pmc_core.c which is the
+ * list of platforms that the driver supports for pmc_core device. The
+ * other list may grow, but this list should not.
+
Re: No 8254 PIT & no HPET on new Intel N3350 platforms causes kernel panic during early boot
On Thu, Jun 27, 2019 at 10:07 PM Thomas Gleixner wrote: > Nah. That extra timer works thing is just another bandaid. > > What I had in mind is something like the below. That's on top of > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/apic > > Be warned. It's neither compiled nor tested, so keep a fire extinguisher > handy. If it explodes you own the pieces. Thanks, it works, and makes sense! I'll add a commit message and send it as a patch, just one quick function naming question... did you mean apic_and_tsc_needs_pit() or apic_needs_pit()? That's the only compile fix needed. Daniel
Re: [PATCH 07/13] xfs: allow merging ioends over append boundaries
On Fri, Jun 28, 2019 at 10:52:04AM +0800, Zorro Lang wrote: > On Thu, Jun 27, 2019 at 09:43:04PM +, Luis Chamberlain wrote: > > On Thu, Jun 27, 2019 at 11:23:09AM -0700, Darrick J. Wong wrote: > > > On Thu, Jun 27, 2019 at 12:48:30PM +0200, Christoph Hellwig wrote: > > > > There is no real problem merging ioends that go beyond i_size into an > > > > ioend that doesn't. We just need to move the append transaction to the > > > > base ioend. Also use the opportunity to use a real error code instead > > > > of the magic 1 to cancel the transactions, and write a comment > > > > explaining the scheme. > > > > > > > > Signed-off-by: Christoph Hellwig > > > > > > Reading through this patch, I have a feeling it fixes the crash that > > > Zorro has been seeing occasionally with generic/475... > > > > > > Reviewed-by: Darrick J. Wong > > > > Zorro, can you confirm? If so it would be great to also refer to > > the respective bugzilla entry #203947 [0]. > > Sure, I'll give it a test. But it's so hard to reproduce, I need long enough > time to prove "the panic's gone". > > BTW, should I only merge this single patch to test, or merge your whole > patchset > with 13 patches? Just this one patch. --D > Thanks, > Zorro > > > > > [0] https://bugzilla.kernel.org/show_bug.cgi?id=203947 > > > > Luis
Re: [PATCH][next] regulator: lp87565: fix missing break in switch statement
On 27/06/19 6:46 PM, Colin King wrote:
From: Colin Ian King
Currently the LP87565_DEVICE_TYPE_LP87561_Q1 case does not have a
break statement, causing it to fall through to a dev_err message.
Fix this by adding in the missing break statement.
Addresses-Coverity: ("Missing break in switch")
Fixes: 7ee63bd74750 ("regulator: lp87565: Add 4-phase lp87561 regulator
support")
Signed-off-by: Colin Ian King
---
drivers/regulator/lp87565-regulator.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/regulator/lp87565-regulator.c
b/drivers/regulator/lp87565-regulator.c
index 993c11702083..5d067f7c2116 100644
--- a/drivers/regulator/lp87565-regulator.c
+++ b/drivers/regulator/lp87565-regulator.c
@@ -180,6 +180,7 @@ static int lp87565_regulator_probe(struct platform_device
*pdev)
case LP87565_DEVICE_TYPE_LP87561_Q1:
min_idx = LP87565_BUCK_3210;
max_idx = LP87565_BUCK_3210;
+ break;
Thanks Colin.
Reviewed-by: Keerthy
default:
dev_err(lp87565->dev, "Invalid lp config %d\n",
lp87565->dev_type);
Re: [RFC PATCH v3 0/4] Deliver vGPU display vblank event to userspace
On 2019.06.27 12:31:33 +0200, Gerd Hoffmann wrote: > > > Hi, > > > > > > > Instead of delivering page flip events, we choose to post display > > > > vblank event. Handling page flip events for both primary plane and > > > > cursor plane may make user space quite busy, although we have the > > > > mask/unmask mechansim for mitigation. Besides, there are some cases > > > > that guest app only uses one framebuffer for both drawing and display. > > > > In such case, guest OS won't do the plane page flip when the > > > > framebuffer is updated, thus the user land won't be notified about the > > > updated framebuffer. > > > > > > What happens when the guest is idle and doesn't draw anything to the > > > framebuffer? > > The vblank event will be delivered to userspace as well, unless guest OS > > disable the pipe. > > Does it make sense to vfio/display? > > Getting notified only in case there are actual display updates would be > a nice optimization, assuming the hardware is able to do that. If the > guest pageflips this is obviously trivial. Not sure this is possible in > case the guest renders directly to the frontbuffer. > > What exactly happens when the guest OS disables the pipe? Is a vblank > event delivered at least once? That would be very useful because it > will be possible for userspace to stop polling altogether without > missing the "guest disabled pipe" event. > It looks like purpose to use vblank here is to replace user space polling totally by kernel event? Which just act as display update event to replace user space timer to make it query and update planes? Although in theory vblank is not appropriate for this which doesn't align with plane update or possible front buffer rendering at all, but looks it's just a compromise e.g not sending event for every cursor position change, etc. I think we need to define semantics for this event properly, e.g user space purely depends on this event for display update, the opportunity for issuing this event is controlled by driver when it's necessary for update, etc. Definitely not named as vblank event or only issue at vblank, that need to happen for other plane change too. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: PGP signature
RE: [PATCH v3] e1000e: Make watchdog use delayed work
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] > On Behalf Of Detlev Casanova > Sent: Saturday, June 22, 2019 8:15 PM > To: Kirsher, Jeffrey T ; David S. Miller > ; intel-wired-...@lists.osuosl.org; > net...@vger.kernel.org; linux-kernel@vger.kernel.org > Cc: Detlev Casanova > Subject: [PATCH v3] e1000e: Make watchdog use delayed work > > Use delayed work instead of timers to run the watchdog of the e1000e > driver. > > Simplify the code with one less middle function. > > Signed-off-by: Detlev Casanova > --- > drivers/net/ethernet/intel/e1000e/e1000.h | 5 +- > drivers/net/ethernet/intel/e1000e/netdev.c | 54 -- > 2 files changed, 32 insertions(+), 27 deletions(-) Tested-by: Aaron Brown
[PATCH 1/3] media: xilinx: fix leaked of_node references
The call to of_get_child_by_name 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/media/platform/xilinx/xilinx-vipp.c:487:3-9: ERROR: missing
of_node_put; acquired a node pointer with refcount incremented on line 477, but
without a corresponding object release within this function.
drivers/media/platform/xilinx/xilinx-vipp.c:491:1-7: ERROR: missing
of_node_put; acquired a node pointer with refcount incremented on line 477, but
without a corresponding object release within this function.
drivers/media/platform/xilinx/xilinx-tpg.c:732:3-9: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 717, but without a
corresponding object release within this function.
drivers/media/platform/xilinx/xilinx-tpg.c:741:3-9: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 717, but without a
corresponding object release within this function.
drivers/media/platform/xilinx/xilinx-tpg.c:757:2-8: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 717, but without a
corresponding object release within this function.
drivers/media/platform/xilinx/xilinx-tpg.c:764:1-7: ERROR: missing of_node_put;
acquired a node pointer with refcount incremented on line 717, but without a
corresponding object release within this function.
Signed-off-by: Wen Yang
Cc: Patrice Chotard
Cc: Hyun Kwon
Cc: Laurent Pinchart
Cc: Mauro Carvalho Chehab
Cc: Michal Simek
Cc: linux-me...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/media/platform/xilinx/xilinx-tpg.c | 18 +-
drivers/media/platform/xilinx/xilinx-vipp.c | 8 +---
2 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/xilinx/xilinx-tpg.c
b/drivers/media/platform/xilinx/xilinx-tpg.c
index ed01bed..e71d022 100644
--- a/drivers/media/platform/xilinx/xilinx-tpg.c
+++ b/drivers/media/platform/xilinx/xilinx-tpg.c
@@ -713,10 +713,13 @@ static int xtpg_parse_of(struct xtpg_device *xtpg)
struct device_node *port;
unsigned int nports = 0;
bool has_endpoint = false;
+ int ret = 0;
ports = of_get_child_by_name(node, "ports");
- if (ports == NULL)
+ if (ports == NULL) {
ports = node;
+ of_node_get(ports);
+ }
for_each_child_of_node(ports, port) {
const struct xvip_video_format *format;
@@ -729,7 +732,8 @@ static int xtpg_parse_of(struct xtpg_device *xtpg)
if (IS_ERR(format)) {
dev_err(dev, "invalid format in DT");
of_node_put(port);
- return PTR_ERR(format);
+ ret = PTR_ERR(format);
+ goto out_put_node;
}
/* Get and check the format description */
@@ -738,7 +742,8 @@ static int xtpg_parse_of(struct xtpg_device *xtpg)
} else if (xtpg->vip_format != format) {
dev_err(dev, "in/out format mismatch in DT");
of_node_put(port);
- return -EINVAL;
+ ret = -EINVAL;
+ goto out_put_node;
}
if (nports == 0) {
@@ -754,14 +759,17 @@ static int xtpg_parse_of(struct xtpg_device *xtpg)
if (nports != 1 && nports != 2) {
dev_err(dev, "invalid number of ports %u\n", nports);
- return -EINVAL;
+ ret = -EINVAL;
+ goto out_put_node;
}
xtpg->npads = nports;
if (nports == 2 && has_endpoint)
xtpg->has_input = true;
- return 0;
+out_put_node:
+ of_node_put(ports);
+ return ret;
}
static int xtpg_probe(struct platform_device *pdev)
diff --git a/drivers/media/platform/xilinx/xilinx-vipp.c
b/drivers/media/platform/xilinx/xilinx-vipp.c
index edce040..307717c 100644
--- a/drivers/media/platform/xilinx/xilinx-vipp.c
+++ b/drivers/media/platform/xilinx/xilinx-vipp.c
@@ -472,7 +472,7 @@ static int xvip_graph_dma_init(struct xvip_composite_device
*xdev)
{
struct device_node *ports;
struct device_node *port;
- int ret;
+ int ret = 0;
ports = of_get_child_by_name(xdev->dev->of_node, "ports");
if (ports == NULL) {
@@ -484,11 +484,13 @@ static int xvip_graph_dma_init(struct
xvip_composite_device *xdev)
ret = xvip_graph_dma_init_one(xdev, port);
if (ret < 0) {
of_node_put(port);
- return ret;
+ goto out_put_node;
}
}
- return 0;
+out_put_node:
+ of_node_put(ports);
+ return ret;
}
static void xvip_graph_cleanup(struct
[PATCH 0/3] fix leaked of_node references in drivers/media
The call to of_get_cpu_node/of_find_compatible_node/of_parse_phandle... returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. We developed a coccinelle SmPL to detect drivers/media/ code and found some issues. This patch series fixes those issues. Wen Yang (3): media: xilinx: fix leaked of_node references media: exynos4-is: fix leaked of_node references media: ti-vpe: fix leaked of_node references drivers/media/platform/exynos4-is/fimc-is.c | 1 + drivers/media/platform/exynos4-is/media-dev.c | 2 ++ drivers/media/platform/ti-vpe/cal.c | 1 + drivers/media/platform/xilinx/xilinx-tpg.c| 18 +- drivers/media/platform/xilinx/xilinx-vipp.c | 8 +--- 5 files changed, 22 insertions(+), 8 deletions(-) Cc: Mauro Carvalho Chehab Cc: Hans Verkuil Cc: Laurent Pinchart Cc: Philipp Zabel Cc: Stanimir Varbanov Cc: linux-me...@vger.kernel.org -- 2.9.5
[PATCH 3/3] media: ti-vpe: fix leaked of_node references
The call to of_get_parent 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/media/platform/ti-vpe/cal.c:1621:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 1607, but without a corresponding object release within this function. Signed-off-by: Wen Yang Cc: Benoit Parrot Cc: Mauro Carvalho Chehab Cc: linux-me...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/media/platform/ti-vpe/cal.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/ti-vpe/cal.c b/drivers/media/platform/ti-vpe/cal.c index 9e86d761..8e19974 100644 --- a/drivers/media/platform/ti-vpe/cal.c +++ b/drivers/media/platform/ti-vpe/cal.c @@ -1613,6 +1613,7 @@ of_get_next_port(const struct device_node *parent, } prev = port; } while (!of_node_name_eq(port, "port")); + of_node_put(ports); } return port; -- 2.9.5
Re: power9 NUMA crash while reading debugfs imc_cmd
Qian Cai writes: > Read of debugfs imc_cmd file for a memory-less node will trigger a crash below > on this power9 machine which has the following NUMA layout. What type of machine is it? cheers > I don't understand why I only saw it recently on linux-next where it > was tested everyday. I can reproduce it back to 4.20 where 4.18 seems > work fine. > > # cat /sys/kernel/debug/powerpc/imc/imc_cmd_252 (On a 4.18-based kernel) > 0x > > # numactl -H > available: 6 nodes (0,8,252-255) > node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 > 25 > 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 > 52 > 53 54 55 56 57 58 59 60 61 62 63 > node 0 size: 130210 MB > node 0 free: 128406 MB > node 8 cpus: 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 > 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 > 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 > node 8 size: 130784 MB > node 8 free: 130051 MB > node 252 cpus: > node 252 size: 0 MB > node 252 free: 0 MB > node 253 cpus: > node 253 size: 0 MB > node 253 free: 0 MB > node 254 cpus: > node 254 size: 0 MB > node 254 free: 0 MB > node 255 cpus: > node 255 size: 0 MB > node 255 free: 0 MB > node distances: > node 0 8 252 253 254 255 > 0: 10 40 80 80 80 80 > 8: 40 10 80 80 80 80 > 252: 80 80 10 80 80 80 > 253: 80 80 80 10 80 80 > 254: 80 80 80 80 10 80 > 255: 80 80 80 80 80 10 > > # cat /sys/kernel/debug/powerpc/imc/imc_cmd_252 > > [ 1139.415461][ T5301] Faulting instruction address: 0xc00d0d58 > [ 1139.415492][ T5301] Oops: Kernel access of bad area, sig: 11 [#1] > [ 1139.415509][ T5301] LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=256 > DEBUG_PAGEALLOC NUMA PowerNV > [ 1139.415542][ T5301] Modules linked in: i2c_opal i2c_core ip_tables x_tables > xfs sd_mod bnx2x mdio ahci libahci tg3 libphy libata firmware_class dm_mirror > dm_region_hash dm_log dm_mod > [ 1139.415595][ T5301] CPU: 67 PID: 5301 Comm: cat Not tainted 5.2.0-rc6-next- > 20190627+ #19 > [ 1139.415634][ T5301] NIP: c00d0d58 LR: c049aa18 CTR: > c00d0d50 > [ 1139.415675][ T5301] REGS: c00020194548f9e0 TRAP: 0300 Not tainted > (5.2.0- > rc6-next-20190627+) > [ 1139.415705][ T5301] MSR: 90009033 CR: > 28022822 XER: > [ 1139.415777][ T5301] CFAR: c049aa14 DAR: 0003fc08 DSISR: > 4000 IRQMASK: 0 > [ 1139.415777][ T5301] GPR00: c049aa18 c00020194548fc70 > c16f8b00 > 0003fc08 > [ 1139.415777][ T5301] GPR04: c00020194548fcd0 > 14884e73 > 00011eaa > [ 1139.415777][ T5301] GPR08: 7eea5a52 c00d0d50 > > > [ 1139.415777][ T5301] GPR12: c00d0d50 c000201fff7f8c00 > > > [ 1139.415777][ T5301] GPR16: 000d 7fffeb0c3368 > > > [ 1139.415777][ T5301] GPR20: > > 0002 > [ 1139.415777][ T5301] GPR24: > 0002 > 00010ec9 > [ 1139.415777][ T5301] GPR28: c00020194548fdf0 c00020049a584ef8 > > c00020049a584ea8 > [ 1139.416116][ T5301] NIP [c00d0d58] imc_mem_get+0x8/0x20 > [ 1139.416143][ T5301] LR [c049aa18] simple_attr_read+0x118/0x170 > [ 1139.416158][ T5301] Call Trace: > [ 1139.416182][ T5301] [c00020194548fc70] [c049a970] > simple_attr_read+0x70/0x170 (unreliable) > [ 1139.416255][ T5301] [c00020194548fd10] [c054385c] > debugfs_attr_read+0x6c/0xb0 > [ 1139.416305][ T5301] [c00020194548fd60] [c0454c1c] > __vfs_read+0x3c/0x70 > [ 1139.416363][ T5301] [c00020194548fd80] [c0454d0c] > vfs_read+0xbc/0x1a0 > [ 1139.416392][ T5301] [c00020194548fdd0] [c045519c] > ksys_read+0x7c/0x140 > [ 1139.416434][ T5301] [c00020194548fe20] [c000b108] > system_call+0x5c/0x70 > [ 1139.416473][ T5301] Instruction dump: > [ 1139.416511][ T5301] 4e800020 6000 7c0802a6 6000 7c801d28 3860 > 4e800020 6000 > [ 1139.416572][ T5301] 6000 6000 7c0802a6 6000 <7d201c28> 3860 > f924 4e800020 > [ 1139.416636][ T5301] ---[ end trace c44d1fb4ace04784 ]--- > [ 1139.520686][ T5301] > [ 1140.520820][ T5301] Kernel panic - not syncing: Fatal exception
Re: [PATCH 0/3] riscv: add SOC_SIFIVE config for SiFive specific resource
Hi Loys, On Mon, 17 Jun 2019, Loys Ollivier wrote: > Following is a patch series that adds a SOC_SIFIVE config. > The purpose of this config is to group all the code specific to the SiFive > architecture such as device tree and platform drivers. > > The initial thought/discussion came from [0]. > > [0] > https://lore.kernel.org/linux-riscv/20190602080500.31700-1-paul.walms...@sifive.com/ Thanks for giving us a good start here. Queued for v5.3 with Palmer's Reviewed-by:s. - Paul
[PATCH 2/3] media: exynos4-is: fix leaked of_node references
The call to of_get_child_by_name 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/media/platform/exynos4-is/fimc-is.c:813:2-8: ERROR: missing
of_node_put; acquired a node pointer with refcount incremented on line 807, but
without a corresponding object release within this function.
drivers/media/platform/exynos4-is/fimc-is.c:870:1-7: ERROR: missing
of_node_put; acquired a node pointer with refcount incremented on line 807, but
without a corresponding object release within this function.
drivers/media/platform/exynos4-is/fimc-is.c:885:1-7: ERROR: missing
of_node_put; acquired a node pointer with refcount incremented on line 807, but
without a corresponding object release within this function.
drivers/media/platform/exynos4-is/media-dev.c:545:1-7: ERROR: missing
of_node_put; acquired a node pointer with refcount incremented on line 541, but
without a corresponding object release within this function.
drivers/media/platform/exynos4-is/media-dev.c:528:1-7: ERROR: missing
of_node_put; acquired a node pointer with refcount incremented on line 499, but
without a corresponding object release within this function.
drivers/media/platform/exynos4-is/media-dev.c:534:1-7: ERROR: missing
of_node_put; acquired a node pointer with refcount incremented on line 499, but
without a corresponding object release within this function.
Signed-off-by: Wen Yang
Cc: Kyungmin Park
Cc: Sylwester Nawrocki
Cc: Mauro Carvalho Chehab
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: linux-me...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/media/platform/exynos4-is/fimc-is.c | 1 +
drivers/media/platform/exynos4-is/media-dev.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/media/platform/exynos4-is/fimc-is.c
b/drivers/media/platform/exynos4-is/fimc-is.c
index e043d55..b7cc8e6 100644
--- a/drivers/media/platform/exynos4-is/fimc-is.c
+++ b/drivers/media/platform/exynos4-is/fimc-is.c
@@ -806,6 +806,7 @@ static int fimc_is_probe(struct platform_device *pdev)
return -ENODEV;
is->pmu_regs = of_iomap(node, 0);
+ of_node_put(node);
if (!is->pmu_regs)
return -ENOMEM;
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index d53427a..a838189 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -501,6 +501,7 @@ static int fimc_md_register_sensor_entities(struct fimc_md
*fmd)
continue;
ret = fimc_md_parse_port_node(fmd, port, index);
+ of_node_put(port);
if (ret < 0) {
of_node_put(node);
goto cleanup;
@@ -542,6 +543,7 @@ static int __of_get_csis_id(struct device_node *np)
if (!np)
return -EINVAL;
of_property_read_u32(np, "reg", );
+ of_node_put(np);
return reg - FIMC_INPUT_MIPI_CSI2_0;
}
--
2.9.5
Re: [PATCH] powerpc/eeh_cache: fix a W=1 kernel-doc warning
On Wed, 2019-06-05 at 16:46 -0400, Qian Cai wrote: > The opening comment mark "/**" is reserved for kernel-doc comments, > so > it will generate a warning with "make W=1". > > arch/powerpc/kernel/eeh_cache.c:37: warning: cannot understand > function > prototype: 'struct pci_io_addr_range > > Since this is not a kernel-doc for the struct below, but rather an > overview of this source eeh_cache.c, just use the free-form comments > kernel-doc syntax instead. > > Signed-off-by: Qian Cai Looks good to me. Acked-by: Russell Currey
Re: [PATCH v2] PCI: rpaphp: Avoid a sometimes-uninitialized warning
>On Mon, Jun 03, 2019 at 03:11:58PM -0700, Nathan Chancellor wrote:
>> When building with -Wsometimes-uninitialized, clang warns:
>>
>> drivers/pci/hotplug/rpaphp_core.c:243:14: warning: variable 'fndit' is
>> used uninitialized whenever 'for' loop exits because its condition is
>> false [-Wsometimes-uninitialized]
>> for (j = 0; j < entries; j++) {
>> ^~~
>> drivers/pci/hotplug/rpaphp_core.c:256:6: note: uninitialized use occurs
>> here
>> if (fndit)
>> ^
>> drivers/pci/hotplug/rpaphp_core.c:243:14: note: remove the condition if
>> it is always true
>> for (j = 0; j < entries; j++) {
>> ^~~
>> drivers/pci/hotplug/rpaphp_core.c:233:14: note: initialize the variable
>> 'fndit' to silence this warning
>> int j, fndit;
>> ^
>> = 0
>>
>> fndit is only used to gate a sprintf call, which can be moved into the
>> loop to simplify the code and eliminate the local variable, which will
>> fix this warning.
>>
>> Link: https://github.com/ClangBuiltLinux/linux/issues/504
>> Fixes: 2fcf3ae508c2 ("hotplug/drc-info: Add code to search ibm,drc-info
>> property")
>> Suggested-by: Nick Desaulniers
>> Signed-off-by: Nathan Chancellor
>> ---
>>
>> v1 -> v2:
>>
>> * Eliminate fndit altogether by shuffling the sprintf call into the for
>> loop and changing the if conditional, as suggested by Nick.
>
>> drivers/pci/hotplug/rpaphp_core.c | 18 +++---
>> 1 file changed, 7 insertions(+), 11 deletions(-)
>> Gentle ping, can someone pick this up?
Looks a good simplification of somewhat convoluted control flow.
Acked-by: Joel Savitz
[PATCH v2 26/27] sound: oss: use kzalloc rather than kmalloc with memset
Use zeroing allocator instead of using allocator followed
with memset with 0.
Signed-off-by: Fuqian Huang
---
sound/core/seq/oss/seq_oss_init.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/sound/core/seq/oss/seq_oss_init.c
b/sound/core/seq/oss/seq_oss_init.c
index 6dc94efc19c9..6e8020d4368a 100644
--- a/sound/core/seq/oss/seq_oss_init.c
+++ b/sound/core/seq/oss/seq_oss_init.c
@@ -66,7 +66,7 @@ snd_seq_oss_create_client(void)
struct snd_seq_port_info *port;
struct snd_seq_port_callback port_callback;
- port = kmalloc(sizeof(*port), GFP_KERNEL);
+ port = kzalloc(sizeof(*port), GFP_KERNEL);
if (!port) {
rc = -ENOMEM;
goto __error;
@@ -81,7 +81,6 @@ snd_seq_oss_create_client(void)
system_client = rc;
/* create annoucement receiver port */
- memset(port, 0, sizeof(*port));
strcpy(port->name, "Receiver");
port->addr.client = system_client;
port->capability = SNDRV_SEQ_PORT_CAP_WRITE; /* receive only */
--
2.11.0
[PATCH v2 27/27] sound: ppc: remove unneeded memset after dma_alloc_coherent
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of
git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang
---
sound/ppc/pmac.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sound/ppc/pmac.c b/sound/ppc/pmac.c
index 1b11e53f6a62..1ab12f4f8631 100644
--- a/sound/ppc/pmac.c
+++ b/sound/ppc/pmac.c
@@ -56,7 +56,6 @@ static int snd_pmac_dbdma_alloc(struct snd_pmac *chip, struct
pmac_dbdma *rec, i
if (rec->space == NULL)
return -ENOMEM;
rec->size = size;
- memset(rec->space, 0, rsize);
rec->cmds = (void __iomem *)DBDMA_ALIGN(rec->space);
rec->addr = rec->dma_base + (unsigned long)((char *)rec->cmds - (char
*)rec->space);
--
2.11.0
[PATCH v2 24/27] fs: jffs2: use kzalloc rather than kmalloc followed with memset
Use zero allocator rather than kmalloc followed with memset with 0.
Signed-off-by: Fuqian Huang
---
fs/jffs2/erase.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/fs/jffs2/erase.c b/fs/jffs2/erase.c
index 83b8f06b4a64..30c4385c6545 100644
--- a/fs/jffs2/erase.c
+++ b/fs/jffs2/erase.c
@@ -43,7 +43,7 @@ static void jffs2_erase_block(struct jffs2_sb_info *c,
jffs2_dbg(1, "%s(): erase block %#08x (range %#08x-%#08x)\n",
__func__,
jeb->offset, jeb->offset, jeb->offset + c->sector_size);
- instr = kmalloc(sizeof(struct erase_info), GFP_KERNEL);
+ instr = kzalloc(sizeof(struct erase_info), GFP_KERNEL);
if (!instr) {
pr_warn("kmalloc for struct erase_info in jffs2_erase_block
failed. Refiling block for later\n");
mutex_lock(>erase_free_sem);
@@ -57,8 +57,6 @@ static void jffs2_erase_block(struct jffs2_sb_info *c,
return;
}
- memset(instr, 0, sizeof(*instr));
-
instr->addr = jeb->offset;
instr->len = c->sector_size;
--
2.11.0
[PATCH v2 25/27] kernel: power: use kzalloc rather than kmalloc followed with memset
Use zeroing allocator instead of using allocator
followed with memset with 0
Signed-off-by: Fuqian Huang
---
kernel/power/swap.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/power/swap.c b/kernel/power/swap.c
index e1912ad13bdc..ca0fcb5ced71 100644
--- a/kernel/power/swap.c
+++ b/kernel/power/swap.c
@@ -974,12 +974,11 @@ static int get_swap_reader(struct swap_map_handle *handle,
last = handle->maps = NULL;
offset = swsusp_header->image;
while (offset) {
- tmp = kmalloc(sizeof(*handle->maps), GFP_KERNEL);
+ tmp = kzalloc(sizeof(*handle->maps), GFP_KERNEL);
if (!tmp) {
release_swap_reader(handle);
return -ENOMEM;
}
- memset(tmp, 0, sizeof(*tmp));
if (!handle->maps)
handle->maps = tmp;
if (last)
--
2.11.0
[PATCH v2 22/27] usb: remove unneeded memset after dma_alloc_coherent
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of
git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang
---
drivers/usb/host/xhci-dbgcap.c | 1 -
drivers/usb/host/xhci-mem.c| 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/usb/host/xhci-dbgcap.c b/drivers/usb/host/xhci-dbgcap.c
index 52e32644a4b2..93e2cca5262d 100644
--- a/drivers/usb/host/xhci-dbgcap.c
+++ b/drivers/usb/host/xhci-dbgcap.c
@@ -22,7 +22,6 @@ dbc_dma_alloc_coherent(struct xhci_hcd *xhci, size_t size,
vaddr = dma_alloc_coherent(xhci_to_hcd(xhci)->self.sysdev,
size, dma_handle, flags);
- memset(vaddr, 0, size);
return vaddr;
}
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index cf5e17962179..e16eda6e2b8b 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -2399,7 +2399,6 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
flags);
if (!xhci->dcbaa)
goto fail;
- memset(xhci->dcbaa, 0, sizeof *(xhci->dcbaa));
xhci->dcbaa->dma = dma;
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"// Device context base array address = 0x%llx (DMA),
%p (virt)",
--
2.11.0
[PATCH v2 20/27] staging: rtl8723bs: remove unneeded memset
rtw_zmalloc already zeroes the memory,
so memset is unneeded.
Signed-off-by: Fuqian Huang
---
drivers/staging/rtl8723bs/core/rtw_ap.c | 2 --
drivers/staging/rtl8723bs/core/rtw_mlme.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c
b/drivers/staging/rtl8723bs/core/rtw_ap.c
index bc0230672457..dc1da5626ce1 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ap.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ap.c
@@ -1504,8 +1504,6 @@ static int rtw_ap_set_key(
goto exit;
}
- memset(psetkeyparm, 0, sizeof(struct setkey_parm));
-
psetkeyparm->keyid = (u8)keyid;
if (is_wep_enc(alg))
padapter->securitypriv.key_mask |= BIT(psetkeyparm->keyid);
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c
b/drivers/staging/rtl8723bs/core/rtw_mlme.c
index 5f78f1eaa7aa..3586da79af5a 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
@@ -2229,7 +2229,6 @@ sint rtw_set_auth(struct adapter *adapter, struct
security_priv *psecuritypriv)
goto exit;
}
- memset(psetauthparm, 0, sizeof(struct setauth_parm));
psetauthparm->mode = (unsigned char)psecuritypriv->dot11AuthAlgrthm;
pcmd->cmdcode = _SetAuth_CMD_;
@@ -2262,7 +2261,6 @@ sint rtw_set_key(struct adapter *adapter, struct
security_priv *psecuritypriv, s
res = _FAIL;
goto exit;
}
- memset(psetkeyparm, 0, sizeof(struct setkey_parm));
if (psecuritypriv->dot11AuthAlgrthm == dot11AuthAlgrthm_8021X) {
psetkeyparm->algorithm = (unsigned
char)psecuritypriv->dot118021XGrpPrivacy;
--
2.11.0
[PATCH v2 21/27] tty: remove unneeded memset
pci_alloc_consistent calls dma_alloc_coherent directly.
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of
git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang
---
drivers/tty/serial/icom.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/tty/serial/icom.c b/drivers/tty/serial/icom.c
index ad374f7c476d..624f3d541c68 100644
--- a/drivers/tty/serial/icom.c
+++ b/drivers/tty/serial/icom.c
@@ -207,8 +207,6 @@ static int get_port_memory(struct icom_port *icom_port)
return -ENOMEM;
}
- memset(icom_port->statStg, 0, 4096);
-
/* FODs: Frame Out Descriptor Queue, this is a FIFO queue that
indicates that frames are to be transmitted
*/
--
2.11.0
[PATCH v2 17/27] scsi: remove unneeded memset
The memset with 0 after zeroing alloctors is unneeded.
pci_alloc_persistent calls dma_alloc_coherent directly.
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of
git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So the memset after these functions is not needed.
Signed-off-by: Fuqian Huang
---
drivers/scsi/3w-9xxx.c| 2 --
drivers/scsi/3w-.c| 2 --
drivers/scsi/aacraid/rx.c | 1 -
drivers/scsi/arcmsr/arcmsr_hba.c | 1 -
drivers/scsi/be2iscsi/be_iscsi.c | 1 -
drivers/scsi/bfa/bfad.c | 1 -
drivers/scsi/bnx2fc/bnx2fc_io.c | 2 --
drivers/scsi/dpt_i2o.c| 4
drivers/scsi/esas2r/esas2r_init.c | 1 -
drivers/scsi/ips.c| 2 --
drivers/scsi/lpfc/lpfc_init.c | 2 --
drivers/scsi/megaraid/megaraid_sas_base.c | 2 --
drivers/scsi/mpt3sas/mpt3sas_transport.c | 2 --
drivers/scsi/mvsas/mv_init.c | 4
drivers/scsi/myrs.c | 1 -
drivers/scsi/pmcraid.c| 1 -
drivers/scsi/qla4xxx/ql4_mbx.c| 1 -
drivers/scsi/qla4xxx/ql4_os.c | 2 --
drivers/scsi/qlogicpti.c | 2 --
19 files changed, 34 deletions(-)
diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
index 3337b1e80412..da17d9104e6b 100644
--- a/drivers/scsi/3w-9xxx.c
+++ b/drivers/scsi/3w-9xxx.c
@@ -534,8 +534,6 @@ static int twa_allocate_memory(TW_Device_Extension *tw_dev,
int size, int which)
goto out;
}
- memset(cpu_addr, 0, size*TW_Q_LENGTH);
-
for (i = 0; i < TW_Q_LENGTH; i++) {
switch(which) {
case 0:
diff --git a/drivers/scsi/3w-.c b/drivers/scsi/3w-.c
index 2b1e0d503020..26703ef52a2e 100644
--- a/drivers/scsi/3w-.c
+++ b/drivers/scsi/3w-.c
@@ -848,8 +848,6 @@ static int tw_allocate_memory(TW_Device_Extension *tw_dev,
int size, int which)
return 1;
}
- memset(cpu_addr, 0, size*TW_Q_LENGTH);
-
for (i=0;ipdev->dev, 512, buffer, baddr);
return ret;
}
- memset(buffer, 0, 512);
post->Post_Command = cpu_to_le32(COMMAND_POST_RESULTS);
post->Post_Address = cpu_to_le32(baddr);
rx_writel(dev, MUnit.IMRx[0], paddr);
diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
index 88053b15c363..a0d0dc83184f 100644
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@ -727,7 +727,6 @@ static int arcmsr_alloc_ccb_pool(struct AdapterControlBlock
*acb)
}
acb->dma_coherent = dma_coherent;
acb->dma_coherent_handle = dma_coherent_handle;
- memset(dma_coherent, 0, acb->uncache_size);
acb->ccbsize = roundup_ccbsize;
ccb_tmp = dma_coherent;
curr_phy_upper32 = upper_32_bits(dma_coherent_handle);
diff --git a/drivers/scsi/be2iscsi/be_iscsi.c b/drivers/scsi/be2iscsi/be_iscsi.c
index 2058d50d62e1..09d63bac6d80 100644
--- a/drivers/scsi/be2iscsi/be_iscsi.c
+++ b/drivers/scsi/be2iscsi/be_iscsi.c
@@ -1081,7 +1081,6 @@ static int beiscsi_open_conn(struct iscsi_endpoint *ep,
return -ENOMEM;
}
nonemb_cmd.size = req_memsize;
- memset(nonemb_cmd.va, 0, nonemb_cmd.size);
tag = mgmt_open_connection(phba, dst_addr, beiscsi_ep, _cmd);
if (!tag) {
beiscsi_log(phba, KERN_ERR, BEISCSI_LOG_CONFIG,
diff --git a/drivers/scsi/bfa/bfad.c b/drivers/scsi/bfa/bfad.c
index 2f9213b257a4..39ac58337290 100644
--- a/drivers/scsi/bfa/bfad.c
+++ b/drivers/scsi/bfa/bfad.c
@@ -622,7 +622,6 @@ bfad_hal_mem_alloc(struct bfad_s *bfad)
goto ext;
}
dma_elem->dma = phys_addr;
- memset(dma_elem->kva, 0, dma_elem->mem_len);
}
ext:
return rc;
diff --git a/drivers/scsi/bnx2fc/bnx2fc_io.c b/drivers/scsi/bnx2fc/bnx2fc_io.c
index 8def63c0755f..92b289466797 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_io.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_io.c
@@ -614,8 +614,6 @@ int bnx2fc_init_mp_req(struct bnx2fc_cmd *io_req)
bnx2fc_free_mp_resc(io_req);
return FAILED;
}
- memset(mp_req->req_buf, 0, CNIC_PAGE_SIZE);
- memset(mp_req->resp_buf, 0, CNIC_PAGE_SIZE);
/* Allocate and map mp_req_bd and mp_resp_bd */
sz = sizeof(struct fcoe_bd_ctx);
diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
index abc74fd474dc..b1b879beebfb 100644
--- a/drivers/scsi/dpt_i2o.c
+++ b/drivers/scsi/dpt_i2o.c
@@ -1331,7 +1331,6 @@ static s32 adpt_i2o_reset_hba(adpt_hba* pHba)
printk(KERN_ERR"IOP reset failed - no free memory.\n");
return -ENOMEM;
}
- memset(status,0,4);
msg[0]=EIGHT_WORD_MSG_SIZE|SGL_OFFSET_0;
[PATCH v2 18/27] scsi: use zeroing allocator rather than allocator followed by memset 0
Replace allocator followed by memset with 0 with zeroing allocator.
Signed-off-by: Fuqian Huang
---
drivers/scsi/lpfc/lpfc_debugfs.c | 5 +
drivers/scsi/qedf/qedf_dbg.c | 3 +--
drivers/scsi/qla2xxx/qla_attr.c | 7 ++-
3 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_debugfs.c b/drivers/scsi/lpfc/lpfc_debugfs.c
index 1ee857d9d165..0dfac41f2fa8 100644
--- a/drivers/scsi/lpfc/lpfc_debugfs.c
+++ b/drivers/scsi/lpfc/lpfc_debugfs.c
@@ -6017,7 +6017,7 @@ lpfc_debugfs_initialize(struct lpfc_vport *vport)
phba->hba_debugfs_root,
phba, _debugfs_op_slow_ring_trc);
if (!phba->slow_ring_trc) {
- phba->slow_ring_trc = kmalloc(
+ phba->slow_ring_trc = kzalloc(
(sizeof(struct lpfc_debugfs_trc) *
lpfc_debugfs_max_slow_ring_trc),
GFP_KERNEL);
@@ -6028,9 +6028,6 @@ lpfc_debugfs_initialize(struct lpfc_vport *vport)
goto debug_failed;
}
atomic_set(>slow_ring_trc_cnt, 0);
- memset(phba->slow_ring_trc, 0,
- (sizeof(struct lpfc_debugfs_trc) *
- lpfc_debugfs_max_slow_ring_trc));
}
snprintf(name, sizeof(name), "nvmeio_trc");
diff --git a/drivers/scsi/qedf/qedf_dbg.c b/drivers/scsi/qedf/qedf_dbg.c
index e0387e495261..0d2aed82882a 100644
--- a/drivers/scsi/qedf/qedf_dbg.c
+++ b/drivers/scsi/qedf/qedf_dbg.c
@@ -106,11 +106,10 @@ qedf_dbg_info(struct qedf_dbg_ctx *qedf, const char
*func, u32 line,
int
qedf_alloc_grc_dump_buf(u8 **buf, uint32_t len)
{
- *buf = vmalloc(len);
+ *buf = vzalloc(len);
if (!(*buf))
return -ENOMEM;
- memset(*buf, 0, len);
return 0;
}
diff --git a/drivers/scsi/qla2xxx/qla_attr.c b/drivers/scsi/qla2xxx/qla_attr.c
index 8d560c562e9c..dabd139fdaeb 100644
--- a/drivers/scsi/qla2xxx/qla_attr.c
+++ b/drivers/scsi/qla2xxx/qla_attr.c
@@ -382,7 +382,7 @@ qla2x00_sysfs_write_optrom_ctl(struct file *filp, struct
kobject *kobj,
ha->optrom_region_size = size;
ha->optrom_state = QLA_SREADING;
- ha->optrom_buffer = vmalloc(ha->optrom_region_size);
+ ha->optrom_buffer = vzalloc(ha->optrom_region_size);
if (ha->optrom_buffer == NULL) {
ql_log(ql_log_warn, vha, 0x7062,
"Unable to allocate memory for optrom retrieval "
@@ -404,7 +404,6 @@ qla2x00_sysfs_write_optrom_ctl(struct file *filp, struct
kobject *kobj,
"Reading flash region -- 0x%x/0x%x.\n",
ha->optrom_region_start, ha->optrom_region_size);
- memset(ha->optrom_buffer, 0, ha->optrom_region_size);
ha->isp_ops->read_optrom(vha, ha->optrom_buffer,
ha->optrom_region_start, ha->optrom_region_size);
break;
@@ -457,7 +456,7 @@ qla2x00_sysfs_write_optrom_ctl(struct file *filp, struct
kobject *kobj,
ha->optrom_region_size = size;
ha->optrom_state = QLA_SWRITING;
- ha->optrom_buffer = vmalloc(ha->optrom_region_size);
+ ha->optrom_buffer = vzalloc(ha->optrom_region_size);
if (ha->optrom_buffer == NULL) {
ql_log(ql_log_warn, vha, 0x7066,
"Unable to allocate memory for optrom update "
@@ -471,8 +470,6 @@ qla2x00_sysfs_write_optrom_ctl(struct file *filp, struct
kobject *kobj,
ql_dbg(ql_dbg_user, vha, 0x7067,
"Staging flash region write -- 0x%x/0x%x.\n",
ha->optrom_region_start, ha->optrom_region_size);
-
- memset(ha->optrom_buffer, 0, ha->optrom_region_size);
break;
case 3:
if (ha->optrom_state != QLA_SWRITING) {
--
2.11.0
[PATCH v2 19/27] staging: rtl8*: use zeroing allocator rather than allocator followed with memset 0
Use zeroing allocator rather than allocator followed with memset 0.
Signed-off-by: Fuqian Huang
---
drivers/staging/rtl8188eu/os_dep/mlme_linux.c | 3 +--
drivers/staging/rtl8712/rtl871x_io.c | 4 +---
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 8 ++--
drivers/staging/rtl8723bs/os_dep/ioctl_linux.c| 12 +++-
4 files changed, 7 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/rtl8188eu/os_dep/mlme_linux.c
b/drivers/staging/rtl8188eu/os_dep/mlme_linux.c
index 9db11b16cb93..250acb01d1a9 100644
--- a/drivers/staging/rtl8188eu/os_dep/mlme_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/mlme_linux.c
@@ -98,10 +98,9 @@ void rtw_report_sec_ie(struct adapter *adapter, u8 authmode,
u8 *sec_ie)
if (authmode == _WPA_IE_ID_) {
RT_TRACE(_module_mlme_osdep_c_, _drv_info_,
("rtw_report_sec_ie, authmode=%d\n", authmode));
- buff = rtw_malloc(IW_CUSTOM_MAX);
+ buff = rtw_zmalloc(IW_CUSTOM_MAX);
if (!buff)
return;
- memset(buff, 0, IW_CUSTOM_MAX);
p = buff;
p += sprintf(p, "ASSOCINFO(ReqIEs =");
len = sec_ie[1] + 2;
diff --git a/drivers/staging/rtl8712/rtl871x_io.c
b/drivers/staging/rtl8712/rtl871x_io.c
index 17dafeffd6f4..87024d6a465e 100644
--- a/drivers/staging/rtl8712/rtl871x_io.c
+++ b/drivers/staging/rtl8712/rtl871x_io.c
@@ -107,13 +107,11 @@ uint r8712_alloc_io_queue(struct _adapter *adapter)
INIT_LIST_HEAD(_queue->processing);
INIT_LIST_HEAD(_queue->pending);
spin_lock_init(_queue->lock);
- pio_queue->pallocated_free_ioreqs_buf = kmalloc(NUM_IOREQ *
+ pio_queue->pallocated_free_ioreqs_buf = kzalloc(NUM_IOREQ *
(sizeof(struct io_req)) + 4,
GFP_ATOMIC);
if ((pio_queue->pallocated_free_ioreqs_buf) == NULL)
goto alloc_io_queue_fail;
- memset(pio_queue->pallocated_free_ioreqs_buf, 0,
- (NUM_IOREQ * (sizeof(struct io_req)) + 4));
pio_queue->free_ioreqs_buf = pio_queue->pallocated_free_ioreqs_buf + 4
- ((addr_t)(pio_queue->pallocated_free_ioreqs_buf)
& 3);
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index db553f2e4c0b..f8e0723f5d1f 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -1078,12 +1078,10 @@ static int cfg80211_rtw_add_key(struct wiphy *wiphy,
struct net_device *ndev,
DBG_871X("pairwise =%d\n", pairwise);
param_len = sizeof(struct ieee_param) + params->key_len;
- param = rtw_malloc(param_len);
+ param = rtw_zmalloc(param_len);
if (param == NULL)
return -1;
- memset(param, 0, param_len);
-
param->cmd = IEEE_CMD_SET_ENCRYPTION;
memset(param->sta_addr, 0xff, ETH_ALEN);
@@ -2167,15 +2165,13 @@ static int cfg80211_rtw_connect(struct wiphy *wiphy,
struct net_device *ndev,
{
wep_key_len = wep_key_len <= 5 ? 5 : 13;
wep_total_len = wep_key_len + FIELD_OFFSET(struct
ndis_802_11_wep, KeyMaterial);
- pwep = rtw_malloc(wep_total_len);
+ pwep = rtw_zmalloc(wep_total_len);
if (pwep == NULL) {
DBG_871X(" wpa_set_encryption: pwep allocate
fail !!!\n");
ret = -ENOMEM;
goto exit;
}
- memset(pwep, 0, wep_total_len);
-
pwep->KeyLength = wep_key_len;
pwep->Length = wep_total_len;
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
index e3d356952875..1491d420929c 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
@@ -478,14 +478,12 @@ static int wpa_set_encryption(struct net_device *dev,
struct ieee_param *param,
if (wep_key_len > 0) {
wep_key_len = wep_key_len <= 5 ? 5 : 13;
wep_total_len = wep_key_len + FIELD_OFFSET(struct
ndis_802_11_wep, KeyMaterial);
- pwep = rtw_malloc(wep_total_len);
+ pwep = rtw_zmalloc(wep_total_len);
if (pwep == NULL) {
RT_TRACE(_module_rtl871x_ioctl_os_c, _drv_err_,
(" wpa_set_encryption: pwep allocate fail !!!\n"));
goto exit;
}
- memset(pwep, 0, wep_total_len);
-
pwep->KeyLength = wep_key_len;
[PATCH v2 15/27] net: use zeroing allocator rather than allocator followed by memset zero
Replace allocator followed by memset with 0 with zeroing allocator.
Signed-off-by: Fuqian Huang
---
drivers/net/eql.c | 3 +--
drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c | 4 +---
drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c | 4 +---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 3 +--
4 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/net/eql.c b/drivers/net/eql.c
index 74263f8efe1a..2f101a6036e6 100644
--- a/drivers/net/eql.c
+++ b/drivers/net/eql.c
@@ -419,14 +419,13 @@ static int eql_enslave(struct net_device *master_dev,
slaving_request_t __user *
if ((master_dev->flags & IFF_UP) == IFF_UP) {
/* slave is not a master & not already a slave: */
if (!eql_is_master(slave_dev) && !eql_is_slave(slave_dev)) {
- slave_t *s = kmalloc(sizeof(*s), GFP_KERNEL);
+ slave_t *s = kzalloc(sizeof(*s), GFP_KERNEL);
equalizer_t *eql = netdev_priv(master_dev);
int ret;
if (!s)
return -ENOMEM;
- memset(s, 0, sizeof(*s));
s->dev = slave_dev;
s->priority = srq.priority;
s->priority_bps = srq.priority;
diff --git a/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
b/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
index 43d11c38b38a..cf3835da32c8 100644
--- a/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
@@ -719,12 +719,10 @@ static int cn23xx_setup_pf_mbox(struct octeon_device *oct)
for (i = 0; i < oct->sriov_info.max_vfs; i++) {
q_no = i * oct->sriov_info.rings_per_vf;
- mbox = vmalloc(sizeof(*mbox));
+ mbox = vzalloc(sizeof(*mbox));
if (!mbox)
goto free_mbox;
- memset(mbox, 0, sizeof(struct octeon_mbox));
-
spin_lock_init(>lock);
mbox->oct_dev = oct;
diff --git a/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c
b/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c
index fda49404968c..b3bd2767d3dd 100644
--- a/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/cn23xx_vf_device.c
@@ -279,12 +279,10 @@ static int cn23xx_setup_vf_mbox(struct octeon_device *oct)
{
struct octeon_mbox *mbox = NULL;
- mbox = vmalloc(sizeof(*mbox));
+ mbox = vzalloc(sizeof(*mbox));
if (!mbox)
return 1;
- memset(mbox, 0, sizeof(struct octeon_mbox));
-
spin_lock_init(>lock);
mbox->oct_dev = oct;
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index 6c01314e87b0..f1dff5c47676 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -1062,7 +1062,7 @@ static int mlx4_en_config_rss_qp(struct mlx4_en_priv
*priv, int qpn,
struct mlx4_qp_context *context;
int err = 0;
- context = kmalloc(sizeof(*context), GFP_KERNEL);
+ context = kzalloc(sizeof(*context), GFP_KERNEL);
if (!context)
return -ENOMEM;
@@ -1073,7 +1073,6 @@ static int mlx4_en_config_rss_qp(struct mlx4_en_priv
*priv, int qpn,
}
qp->event = mlx4_en_sqp_event;
- memset(context, 0, sizeof(*context));
mlx4_en_fill_qp_context(priv, ring->actual_size, ring->stride, 0, 0,
qpn, ring->cqn, -1, context);
context->db_rec_addr = cpu_to_be64(ring->wqres.db.dma);
--
2.11.0
[PATCH v2 13/27] message: fusion: remove memset after pci_alloc_consistent
pci_alloc_consistent calls dma_alloc_coherent directly.
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of
git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang
---
drivers/message/fusion/mptbase.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
index d8882b0a1338..845d1ef8abdf 100644
--- a/drivers/message/fusion/mptbase.c
+++ b/drivers/message/fusion/mptbase.c
@@ -4507,7 +4507,6 @@ PrimeIocFifos(MPT_ADAPTER *ioc)
dinitprintk(ioc, printk(MYIOC_s_DEBUG_FMT "Total alloc @
%p[%p], sz=%d[%x] bytes\n",
ioc->name, mem, (void *)(ulong)alloc_dma,
total_size, total_size));
- memset(mem, 0, total_size);
ioc->alloc_total += total_size;
ioc->alloc = mem;
ioc->alloc_dma = alloc_dma;
--
2.11.0
[PATCH v2 14/27] mtd: nand: use kzalloc instead of kmalloc and memset
Replace kmalloc followed by a memset with kzalloc. There is a recommendation to use zeroing allocator rather than allocator followed by memset with 0 in ./scripts/coccinelle/api/alloc/zalloc-simple.cocci Signed-off-by: Fuqian Huang --- drivers/mtd/nand/raw/nand_bch.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/mtd/nand/raw/nand_bch.c b/drivers/mtd/nand/raw/nand_bch.c index 55aa4c1cd414..17527310c3a1 100644 --- a/drivers/mtd/nand/raw/nand_bch.c +++ b/drivers/mtd/nand/raw/nand_bch.c @@ -170,7 +170,7 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd) goto fail; } - nbc->eccmask = kmalloc(eccbytes, GFP_KERNEL); + nbc->eccmask = kzalloc(eccbytes, GFP_KERNEL); nbc->errloc = kmalloc_array(t, sizeof(*nbc->errloc), GFP_KERNEL); if (!nbc->eccmask || !nbc->errloc) goto fail; @@ -182,7 +182,6 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd) goto fail; memset(erased_page, 0xff, eccsize); - memset(nbc->eccmask, 0, eccbytes); encode_bch(nbc->bch, erased_page, eccsize, nbc->eccmask); kfree(erased_page); -- 2.11.0
[PATCH v2 12/27] media: use kzalloc instead of kmalloc and memset
Replace kmalloc followed by a memset with kzalloc.
Signed-off-by: Fuqian Huang
---
drivers/media/usb/pvrusb2/pvrusb2-eeprom.c | 3 +--
drivers/media/usb/pvrusb2/pvrusb2-hdw.c| 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-eeprom.c
b/drivers/media/usb/pvrusb2/pvrusb2-eeprom.c
index 79f0e0c6df37..fac90af8b537 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-eeprom.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-eeprom.c
@@ -39,7 +39,7 @@ static u8 *pvr2_eeprom_fetch(struct pvr2_hdw *hdw)
int ret;
int mode16 = 0;
unsigned pcnt,tcnt;
- eeprom = kmalloc(EEPROM_SIZE,GFP_KERNEL);
+ eeprom = kzalloc(EEPROM_SIZE,GFP_KERNEL);
if (!eeprom) {
pvr2_trace(PVR2_TRACE_ERROR_LEGS,
"Failed to allocate memory required to read eeprom");
@@ -74,7 +74,6 @@ static u8 *pvr2_eeprom_fetch(struct pvr2_hdw *hdw)
(1) we're only fetching part of the eeprom, and (2) if we were
getting the whole thing our I2C driver can't grab it in one
pass - which is what tveeprom is otherwise going to attempt */
- memset(eeprom,0,EEPROM_SIZE);
for (tcnt = 0; tcnt < EEPROM_SIZE; tcnt += pcnt) {
pcnt = 16;
if (pcnt + tcnt > EEPROM_SIZE) pcnt = EEPROM_SIZE-tcnt;
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
index 70b5cb08d65b..ff75b4a53dfa 100644
--- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
+++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
@@ -3309,7 +3309,7 @@ static u8 *pvr2_full_eeprom_fetch(struct pvr2_hdw *hdw)
int ret;
int mode16 = 0;
unsigned pcnt,tcnt;
- eeprom = kmalloc(EEPROM_SIZE,GFP_KERNEL);
+ eeprom = kzalloc(EEPROM_SIZE,GFP_KERNEL);
if (!eeprom) {
pvr2_trace(PVR2_TRACE_ERROR_LEGS,
"Failed to allocate memory required to read eeprom");
@@ -3344,7 +3344,6 @@ static u8 *pvr2_full_eeprom_fetch(struct pvr2_hdw *hdw)
(1) we're only fetching part of the eeprom, and (2) if we were
getting the whole thing our I2C driver can't grab it in one
pass - which is what tveeprom is otherwise going to attempt */
- memset(eeprom,0,EEPROM_SIZE);
for (tcnt = 0; tcnt < EEPROM_SIZE; tcnt += pcnt) {
pcnt = 16;
if (pcnt + tcnt > EEPROM_SIZE) pcnt = EEPROM_SIZE-tcnt;
--
2.11.0
[PATCH v2 11/27] media: remove memset after dma_alloc_coherent/pci_alloc_consistent
pci_alloc_consistent calls dma_alloc_coherent directly.
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of
git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset after these 2 functions is not needed.
Signed-off-by: Fuqian Huang
---
drivers/media/pci/ngene/ngene-core.c| 4
drivers/media/platform/exynos4-is/fimc-is.c | 1 -
2 files changed, 5 deletions(-)
diff --git a/drivers/media/pci/ngene/ngene-core.c
b/drivers/media/pci/ngene/ngene-core.c
index b75ab7d29226..af15ca1c501b 100644
--- a/drivers/media/pci/ngene/ngene-core.c
+++ b/drivers/media/pci/ngene/ngene-core.c
@@ -854,8 +854,6 @@ static int create_ring_buffer(struct pci_dev *pci_dev,
if (!Head)
return -ENOMEM;
- memset(Head, 0, MemSize);
-
PARingBufferCur = PARingBufferHead;
Cur = Head;
@@ -907,8 +905,6 @@ static int AllocateRingBuffers(struct pci_dev *pci_dev,
if (SCListMem == NULL)
return -ENOMEM;
- memset(SCListMem, 0, SCListMemSize);
-
pRingBuffer->SCListMem = SCListMem;
pRingBuffer->PASCListMem = PASCListMem;
pRingBuffer->SCListMemSize = SCListMemSize;
diff --git a/drivers/media/platform/exynos4-is/fimc-is.c
b/drivers/media/platform/exynos4-is/fimc-is.c
index e043d55133a3..77633e356305 100644
--- a/drivers/media/platform/exynos4-is/fimc-is.c
+++ b/drivers/media/platform/exynos4-is/fimc-is.c
@@ -341,7 +341,6 @@ static int fimc_is_alloc_cpu_memory(struct fimc_is *is)
return -ENOMEM;
is->memory.size = FIMC_IS_CPU_MEM_SIZE;
- memset(is->memory.vaddr, 0, is->memory.size);
dev_info(dev, "FIMC-IS CPU memory base: %#x\n", (u32)is->memory.paddr);
--
2.11.0
[PATCH v2 09/27] infiniband: remove unneeded memset
pci_alloc_consistent calls dma_alloc_coherent directly.
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of
git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent/dmam_alloc_coherent has already zeroed the memory.
So the memset after these 3 function calls is not needed.
Signed-off-by: Fuqian Huang
---
drivers/infiniband/hw/cxgb3/cxio_hal.c| 3 ---
drivers/infiniband/hw/cxgb4/cq.c | 1 -
drivers/infiniband/hw/cxgb4/qp.c | 1 -
drivers/infiniband/hw/hns/hns_roce_hw_v1.c| 1 -
drivers/infiniband/hw/hns/hns_roce_hw_v2.c| 3 ---
drivers/infiniband/hw/mthca/mthca_allocator.c | 2 --
drivers/infiniband/hw/nes/nes_verbs.c | 3 ---
drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 3 ---
drivers/infiniband/ulp/ipoib/ipoib_cm.c | 1 -
9 files changed, 18 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/cxio_hal.c
b/drivers/infiniband/hw/cxgb3/cxio_hal.c
index 8ac72ac7cbac..0e37f55678f8 100644
--- a/drivers/infiniband/hw/cxgb3/cxio_hal.c
+++ b/drivers/infiniband/hw/cxgb3/cxio_hal.c
@@ -174,7 +174,6 @@ int cxio_create_cq(struct cxio_rdev *rdev_p, struct t3_cq
*cq, int kernel)
return -ENOMEM;
}
dma_unmap_addr_set(cq, mapping, cq->dma_addr);
- memset(cq->queue, 0, size);
setup.id = cq->cqid;
setup.base_addr = (u64) (cq->dma_addr);
setup.size = 1UL << cq->size_log2;
@@ -538,8 +537,6 @@ static int cxio_hal_init_ctrl_qp(struct cxio_rdev *rdev_p)
dma_unmap_addr_set(_p->ctrl_qp, mapping,
rdev_p->ctrl_qp.dma_addr);
rdev_p->ctrl_qp.doorbell = (void __iomem *)rdev_p->rnic_info.kdb_addr;
- memset(rdev_p->ctrl_qp.workq, 0,
- (1 << T3_CTRL_QP_SIZE_LOG2) * sizeof(union t3_wr));
mutex_init(_p->ctrl_qp.lock);
init_waitqueue_head(_p->ctrl_qp.waitq);
diff --git a/drivers/infiniband/hw/cxgb4/cq.c b/drivers/infiniband/hw/cxgb4/cq.c
index 52ce586621c6..fcd161e3495b 100644
--- a/drivers/infiniband/hw/cxgb4/cq.c
+++ b/drivers/infiniband/hw/cxgb4/cq.c
@@ -104,7 +104,6 @@ static int create_cq(struct c4iw_rdev *rdev, struct t4_cq
*cq,
goto err3;
}
dma_unmap_addr_set(cq, mapping, cq->dma_addr);
- memset(cq->queue, 0, cq->memsize);
if (user && ucontext->is_32b_cqe) {
cq->qp_errp = &((struct t4_status_page *)
diff --git a/drivers/infiniband/hw/cxgb4/qp.c b/drivers/infiniband/hw/cxgb4/qp.c
index e92b9544357a..4882dcbb7d20 100644
--- a/drivers/infiniband/hw/cxgb4/qp.c
+++ b/drivers/infiniband/hw/cxgb4/qp.c
@@ -274,7 +274,6 @@ static int create_qp(struct c4iw_rdev *rdev, struct t4_wq
*wq,
(unsigned long long)virt_to_phys(wq->sq.queue),
wq->rq.queue,
(unsigned long long)virt_to_phys(wq->rq.queue));
- memset(wq->rq.queue, 0, wq->rq.memsize);
dma_unmap_addr_set(>rq, mapping, wq->rq.dma_addr);
}
diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
index e068a02122f5..36d9dcaaa8f9 100644
--- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
+++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
@@ -4265,7 +4265,6 @@ static int hns_roce_v1_create_eq(struct hns_roce_dev
*hr_dev,
}
eq->buf_list[i].map = tmp_dma_addr;
- memset(eq->buf_list[i].buf, 0, HNS_ROCE_BA_SIZE);
}
eq->cons_index = 0;
roce_set_field(tmp, ROCEE_CAEP_AEQC_AEQE_SHIFT_CAEP_AEQC_STATE_M,
diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
index b5392cb5b20f..a4a7c5962916 100644
--- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
+++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
@@ -1774,7 +1774,6 @@ static int hns_roce_init_link_table(struct hns_roce_dev
*hr_dev,
goto err_alloc_buf_failed;
link_tbl->pg_list[i].map = t;
- memset(link_tbl->pg_list[i].buf, 0, buf_chk_sz);
entry[i].blk_ba0 = (t >> 12) & 0x;
roce_set_field(entry[i].blk_ba1_nxt_ptr,
@@ -5387,8 +5386,6 @@ static int hns_roce_mhop_alloc_eq(struct hns_roce_dev
*hr_dev,
eq->cur_eqe_ba = eq->l0_dma;
eq->nxt_eqe_ba = 0;
- memset(eq->bt_l0, 0, eq->entries * eq->eqe_size);
-
return 0;
}
diff --git a/drivers/infiniband/hw/mthca/mthca_allocator.c
b/drivers/infiniband/hw/mthca/mthca_allocator.c
index aaf10dd5364d..aef1d274a14e 100644
--- a/drivers/infiniband/hw/mthca/mthca_allocator.c
+++ b/drivers/infiniband/hw/mthca/mthca_allocator.c
@@ -214,8 +214,6 @@ int mthca_buf_alloc(struct mthca_dev *dev, int size, int
max_direct,
dma_unmap_addr_set(>direct, mapping, t);
- memset(buf->direct.buf, 0, size);
-
while (t & ((1 << shift) - 1)) {
[PATCH v2 08/27] i2c: busses: remove memset after dmam_alloc_coherent
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of
git://git.infradead.org/users/hch/dma-mapping"),
dmam_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang
---
drivers/i2c/busses/i2c-ismt.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-ismt.c b/drivers/i2c/busses/i2c-ismt.c
index 02d23edb2fb1..2f95e25a10f7 100644
--- a/drivers/i2c/busses/i2c-ismt.c
+++ b/drivers/i2c/busses/i2c-ismt.c
@@ -781,8 +781,6 @@ static int ismt_dev_init(struct ismt_priv *priv)
if (!priv->hw)
return -ENOMEM;
- memset(priv->hw, 0, (ISMT_DESC_ENTRIES * sizeof(struct ismt_desc)));
-
priv->head = 0;
init_completion(>cmp);
--
2.11.0
kernel BUG at net/rxrpc/local_object.c:LINE!
Hello,
syzbot found the following crash on:
HEAD commit:249155c2 Merge branch 'parisc-5.2-4' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14fabe45a0
kernel config: https://syzkaller.appspot.com/x/.config?x=e7c31a94f66cc0aa
dashboard link: https://syzkaller.appspot.com/bug?extid=1e0edc4b8b7494c28450
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13e2738da0
The bug was bisected to:
commit 46894a13599a977ac35411b536fb3e0b2feefa95
Author: David Howells
Date: Thu Oct 4 08:32:28 2018 +
rxrpc: Use IPv4 addresses throught the IPv6
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=152fabe3a0
final crash:https://syzkaller.appspot.com/x/report.txt?x=172fabe3a0
console output: https://syzkaller.appspot.com/x/log.txt?x=132fabe3a0
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+1e0edc4b8b7494c28...@syzkaller.appspotmail.com
Fixes: 46894a13599a ("rxrpc: Use IPv4 addresses throught the IPv6")
rxrpc: Assertion failed
[ cut here ]
kernel BUG at net/rxrpc/local_object.c:468!
invalid opcode: [#1] PREEMPT SMP KASAN
CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 5.2.0-rc6+ #60
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:rxrpc_local_rcu net/rxrpc/local_object.c:468 [inline]
RIP: 0010:rxrpc_local_rcu.cold+0x11/0x13 net/rxrpc/local_object.c:462
Code: 83 eb 20 e9 74 ff ff ff e8 58 aa 2d fb eb cc 4c 89 ef e8 6e aa 2d fb
eb e2 e8 d7 fd f4 fa 48 c7 c7 20 8c 15 88 e8 6f 03 df fa <0f> 0b e8 c4 fd
f4 fa 48 c7 c7 20 8c 15 88 e8 5c 03 df fa 0f 0b e8
RSP: 0018:8880a9917c98 EFLAGS: 00010286
RAX: 0017 RBX: 0001 RCX:
RDX: RSI: 815ad926 RDI: ed1015322f85
RBP: 8880a9917ca8 R08: 0017 R09: ed1015d260a1
R10: ed1015d260a0 R11: 8880ae930507 R12: 888099033b40
R13: 888099033b40 R14: 867b8f10 R15: 8880a9917d28
FS: () GS:8880ae90() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7f380ebda000 CR3: 7ad5 CR4: 001406e0
Call Trace:
__rcu_reclaim kernel/rcu/rcu.h:222 [inline]
rcu_do_batch kernel/rcu/tree.c:2092 [inline]
invoke_rcu_callbacks kernel/rcu/tree.c:2310 [inline]
rcu_core+0xba5/0x1500 kernel/rcu/tree.c:2291
__do_softirq+0x25c/0x94c kernel/softirq.c:292
run_ksoftirqd kernel/softirq.c:603 [inline]
run_ksoftirqd+0x8e/0x110 kernel/softirq.c:595
smpboot_thread_fn+0x6a3/0xa30 kernel/smpboot.c:165
kthread+0x354/0x420 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Modules linked in:
---[ end trace 0e784d6285151217 ]---
RIP: 0010:rxrpc_local_rcu net/rxrpc/local_object.c:468 [inline]
RIP: 0010:rxrpc_local_rcu.cold+0x11/0x13 net/rxrpc/local_object.c:462
Code: 83 eb 20 e9 74 ff ff ff e8 58 aa 2d fb eb cc 4c 89 ef e8 6e aa 2d fb
eb e2 e8 d7 fd f4 fa 48 c7 c7 20 8c 15 88 e8 6f 03 df fa <0f> 0b e8 c4 fd
f4 fa 48 c7 c7 20 8c 15 88 e8 5c 03 df fa 0f 0b e8
RSP: 0018:8880a9917c98 EFLAGS: 00010286
RAX: 0017 RBX: 0001 RCX:
RDX: RSI: 815ad926 RDI: ed1015322f85
RBP: 8880a9917ca8 R08: 0017 R09: ed1015d260a1
R10: ed1015d260a0 R11: 8880ae930507 R12: 888099033b40
R13: 888099033b40 R14: 867b8f10 R15: 8880a9917d28
FS: () GS:8880ae90() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7f380ebda000 CR3: 7ad5 CR4: 001406e0
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
[PATCH v2 02/27] ata: Remove memset after dma_alloc_coherent/dmam_alloc_coherent
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of
git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent/dmam_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang
---
drivers/ata/acard-ahci.c | 1 -
drivers/ata/libahci.c| 1 -
drivers/ata/pdc_adma.c | 1 -
drivers/ata/sata_nv.c| 2 --
drivers/ata/sata_qstor.c | 1 -
drivers/ata/sata_sil24.c | 1 -
6 files changed, 7 deletions(-)
diff --git a/drivers/ata/acard-ahci.c b/drivers/ata/acard-ahci.c
index b1b49dbd0b14..85357f27a66b 100644
--- a/drivers/ata/acard-ahci.c
+++ b/drivers/ata/acard-ahci.c
@@ -344,7 +344,6 @@ static int acard_ahci_port_start(struct ata_port *ap)
mem = dmam_alloc_coherent(dev, dma_sz, _dma, GFP_KERNEL);
if (!mem)
return -ENOMEM;
- memset(mem, 0, dma_sz);
/*
* First item in chunk of DMA memory: 32-slot command table,
diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
index 0984c4b76d7e..e4c45d3cca79 100644
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -2365,7 +2365,6 @@ static int ahci_port_start(struct ata_port *ap)
mem = dmam_alloc_coherent(dev, dma_sz, _dma, GFP_KERNEL);
if (!mem)
return -ENOMEM;
- memset(mem, 0, dma_sz);
/*
* First item in chunk of DMA memory: 32-slot command table,
diff --git a/drivers/ata/pdc_adma.c b/drivers/ata/pdc_adma.c
index 52fa8606a25f..c5bbb07aa7d9 100644
--- a/drivers/ata/pdc_adma.c
+++ b/drivers/ata/pdc_adma.c
@@ -550,7 +550,6 @@ static int adma_port_start(struct ata_port *ap)
(u32)pp->pkt_dma);
return -ENOMEM;
}
- memset(pp->pkt, 0, ADMA_PKT_BYTES);
ap->private_data = pp;
adma_reinit_engine(ap);
return 0;
diff --git a/drivers/ata/sata_nv.c b/drivers/ata/sata_nv.c
index 54bfab15c74a..b44b4b64354c 100644
--- a/drivers/ata/sata_nv.c
+++ b/drivers/ata/sata_nv.c
@@ -1136,7 +1136,6 @@ static int nv_adma_port_start(struct ata_port *ap)
_dma, GFP_KERNEL);
if (!mem)
return -ENOMEM;
- memset(mem, 0, NV_ADMA_PORT_PRIV_DMA_SZ);
/*
* First item in chunk of DMA memory:
@@ -1946,7 +1945,6 @@ static int nv_swncq_port_start(struct ata_port *ap)
>prd_dma, GFP_KERNEL);
if (!pp->prd)
return -ENOMEM;
- memset(pp->prd, 0, ATA_PRD_TBL_SZ * ATA_MAX_QUEUE);
ap->private_data = pp;
pp->sactive_block = ap->ioaddr.scr_addr + 4 * SCR_ACTIVE;
diff --git a/drivers/ata/sata_qstor.c b/drivers/ata/sata_qstor.c
index 7ec0c216a6a6..865e5c58bd94 100644
--- a/drivers/ata/sata_qstor.c
+++ b/drivers/ata/sata_qstor.c
@@ -477,7 +477,6 @@ static int qs_port_start(struct ata_port *ap)
GFP_KERNEL);
if (!pp->pkt)
return -ENOMEM;
- memset(pp->pkt, 0, QS_PKT_BYTES);
ap->private_data = pp;
qs_enter_reg_mode(ap);
diff --git a/drivers/ata/sata_sil24.c b/drivers/ata/sata_sil24.c
index bfdf41912588..98aad8206921 100644
--- a/drivers/ata/sata_sil24.c
+++ b/drivers/ata/sata_sil24.c
@@ -1202,7 +1202,6 @@ static int sil24_port_start(struct ata_port *ap)
cb = dmam_alloc_coherent(dev, cb_size, _dma, GFP_KERNEL);
if (!cb)
return -ENOMEM;
- memset(cb, 0, cb_size);
pp->cmd_block = cb;
pp->cmd_block_dma = cb_dma;
--
2.11.0
Re: [PATCH 07/13] xfs: allow merging ioends over append boundaries
On Thu, Jun 27, 2019 at 09:43:04PM +, Luis Chamberlain wrote: > On Thu, Jun 27, 2019 at 11:23:09AM -0700, Darrick J. Wong wrote: > > On Thu, Jun 27, 2019 at 12:48:30PM +0200, Christoph Hellwig wrote: > > > There is no real problem merging ioends that go beyond i_size into an > > > ioend that doesn't. We just need to move the append transaction to the > > > base ioend. Also use the opportunity to use a real error code instead > > > of the magic 1 to cancel the transactions, and write a comment > > > explaining the scheme. > > > > > > Signed-off-by: Christoph Hellwig > > > > Reading through this patch, I have a feeling it fixes the crash that > > Zorro has been seeing occasionally with generic/475... > > > > Reviewed-by: Darrick J. Wong > > Zorro, can you confirm? If so it would be great to also refer to > the respective bugzilla entry #203947 [0]. Sure, I'll give it a test. But it's so hard to reproduce, I need long enough time to prove "the panic's gone". BTW, should I only merge this single patch to test, or merge your whole patchset with 13 patches? Thanks, Zorro > > [0] https://bugzilla.kernel.org/show_bug.cgi?id=203947 > > Luis
[PATCH v2 06/27] dma: remove memset after dma_alloc_coherent/dmam_alloc_coherent
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of
git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent/dmam_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang
---
drivers/dma/imx-sdma.c | 4
drivers/dma/qcom/hidma_ll.c | 2 --
2 files changed, 6 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 99d9f431ae2c..54d86359bdf8 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1886,10 +1886,6 @@ static int sdma_init(struct sdma_engine *sdma)
sdma->context_phys = ccb_phys +
MAX_DMA_CHANNELS * sizeof (struct sdma_channel_control);
- /* Zero-out the CCB structures array just allocated */
- memset(sdma->channel_control, 0,
- MAX_DMA_CHANNELS * sizeof (struct
sdma_channel_control));
-
/* disable all channels */
for (i = 0; i < sdma->drvdata->num_events; i++)
writel_relaxed(0, sdma->regs + chnenbl_ofs(sdma, i));
diff --git a/drivers/dma/qcom/hidma_ll.c b/drivers/dma/qcom/hidma_ll.c
index 5bf8b145c427..bb4471e84e48 100644
--- a/drivers/dma/qcom/hidma_ll.c
+++ b/drivers/dma/qcom/hidma_ll.c
@@ -749,7 +749,6 @@ struct hidma_lldev *hidma_ll_init(struct device *dev, u32
nr_tres,
if (!lldev->tre_ring)
return NULL;
- memset(lldev->tre_ring, 0, (HIDMA_TRE_SIZE + 1) * nr_tres);
lldev->tre_ring_size = HIDMA_TRE_SIZE * nr_tres;
lldev->nr_tres = nr_tres;
@@ -769,7 +768,6 @@ struct hidma_lldev *hidma_ll_init(struct device *dev, u32
nr_tres,
if (!lldev->evre_ring)
return NULL;
- memset(lldev->evre_ring, 0, (HIDMA_EVRE_SIZE + 1) * nr_tres);
lldev->evre_ring_size = HIDMA_EVRE_SIZE * nr_tres;
/* the EVRE ring has to be EVRE_SIZE aligned */
--
2.11.0
[PATCH v2 03/27] atm: idt77252: remove memset after dma_alloc_coherent
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of
git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang
---
drivers/atm/idt77252.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/atm/idt77252.c b/drivers/atm/idt77252.c
index 43a14579e80e..df51680e8931 100644
--- a/drivers/atm/idt77252.c
+++ b/drivers/atm/idt77252.c
@@ -1379,7 +1379,6 @@ init_tsq(struct idt77252_dev *card)
printk("%s: can't allocate TSQ.\n", card->name);
return -1;
}
- memset(card->tsq.base, 0, TSQSIZE);
card->tsq.last = card->tsq.base + TSQ_NUM_ENTRIES - 1;
card->tsq.next = card->tsq.last;
--
2.11.0
[PATCH v2 01/27] sh: mm: Remove call to memset after dma_alloc_coherent
In commit af7ddd8a627c
("Merge tag 'dma-mapping-4.21' of
git://git.infradead.org/users/hch/dma-mapping"),
dma_alloc_coherent has already zeroed the memory.
So memset is not needed.
Signed-off-by: Fuqian Huang
---
arch/sh/mm/consistent.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/sh/mm/consistent.c b/arch/sh/mm/consistent.c
index 792f36129062..b09510adfae9 100644
--- a/arch/sh/mm/consistent.c
+++ b/arch/sh/mm/consistent.c
@@ -58,8 +58,6 @@ int __init platform_resource_setup_memory(struct
platform_device *pdev,
return -ENOMEM;
}
- memset(buf, 0, memsize);
-
r->flags = IORESOURCE_MEM;
r->start = dma_handle;
r->end = r->start + memsize - 1;
--
2.11.0
Re: [PATCH v2] rcu: Change return type of rcu_spawn_one_boost_kthread()
On Thu, Jun 27, 2019 at 01:57:03PM -0700, Paul E. McKenney wrote:
> On Thu, Jun 27, 2019 at 09:42:40AM -0400, Joel Fernandes wrote:
> > On Thu, Jun 27, 2019 at 04:07:46PM +0900, Byungchul Park wrote:
> > > Hello,
> > >
> > > I tested if the WARN_ON_ONCE() is fired with my box and it was ok.
> >
> > Looks pretty safe to me and nice clean up!
> >
> > Acked-by: Joel Fernandes (Google)
>
> Agreed, but I still cannot find where this applies. I did try rcu/next,
> which is currently here:
>
> commit b989ff070574ad8b8621d866de0a8e9a65d42c80 (rcu/rcu/next, rcu/next)
> Merge: 4289ee7d5a83 11ca7a9d541d
> Author: Paul E. McKenney
> Date: Mon Jun 24 09:12:39 2019 -0700
>
> Merge LKMM and RCU commits
>
> Help?
commit 204d7a60670f3f6399a4d0826667ab7863b3e429
Merge LKMM and RCU commits
I made it on top of the above. And could you tell me which branch I'd
better use when developing. I think it's been changing sometimes.
Thank you for the answer in advance!
Thanks,
Byungchul
> Thanx, Paul
>
> > - Joel
> >
> > >
> > > Thanks,
> > > Byungchul
> > >
> > > Changes from v1
> > > -. WARN_ON_ONCE() on failing to create rcu_boost_kthread.
> > > -. Changed title and commit message a bit.
> > >
> > > ---8<---
> > > From 7100fcf82202f063f70f45def208ea5198412f5a Mon Sep 17 00:00:00 2001
> > > From: Byungchul Park
> > > Date: Thu, 27 Jun 2019 15:58:10 +0900
> > > Subject: [PATCH v2] rcu: Change return type of
> > > rcu_spawn_one_boost_kthread()
> > >
> > > The return value of rcu_spawn_one_boost_kthread() is not used any
> > > longer. Change return type of that function from int to void.
> > >
> > > Signed-off-by: Byungchul Park
> > > ---
> > > kernel/rcu/tree_plugin.h | 17 -
> > > 1 file changed, 8 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> > > index 1102765..3c8444e 100644
> > > --- a/kernel/rcu/tree_plugin.h
> > > +++ b/kernel/rcu/tree_plugin.h
> > > @@ -1131,7 +1131,7 @@ static void rcu_preempt_boost_start_gp(struct
> > > rcu_node *rnp)
> > > * already exist. We only create this kthread for preemptible RCU.
> > > * Returns zero if all is well, a negated errno otherwise.
> > > */
> > > -static int rcu_spawn_one_boost_kthread(struct rcu_node *rnp)
> > > +static void rcu_spawn_one_boost_kthread(struct rcu_node *rnp)
> > > {
> > > int rnp_index = rnp - rcu_get_root();
> > > unsigned long flags;
> > > @@ -1139,25 +1139,24 @@ static int rcu_spawn_one_boost_kthread(struct
> > > rcu_node *rnp)
> > > struct task_struct *t;
> > >
> > > if (!IS_ENABLED(CONFIG_PREEMPT_RCU))
> > > - return 0;
> > > + return;
> > >
> > > if (!rcu_scheduler_fully_active || rcu_rnp_online_cpus(rnp) == 0)
> > > - return 0;
> > > + return;
> > >
> > > rcu_state.boost = 1;
> > > if (rnp->boost_kthread_task != NULL)
> > > - return 0;
> > > + return;
> > > t = kthread_create(rcu_boost_kthread, (void *)rnp,
> > > "rcub/%d", rnp_index);
> > > - if (IS_ERR(t))
> > > - return PTR_ERR(t);
> > > + if (WARN_ON_ONCE(IS_ERR(t)))
> > > + return;
> > > raw_spin_lock_irqsave_rcu_node(rnp, flags);
> > > rnp->boost_kthread_task = t;
> > > raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
> > > sp.sched_priority = kthread_prio;
> > > sched_setscheduler_nocheck(t, SCHED_FIFO, );
> > > wake_up_process(t); /* get to TASK_INTERRUPTIBLE quickly. */
> > > - return 0;
> > > }
> > >
> > > static void rcu_cpu_kthread_setup(unsigned int cpu)
> > > @@ -1265,7 +1264,7 @@ static void __init rcu_spawn_boost_kthreads(void)
> > > if (WARN_ONCE(smpboot_register_percpu_thread(_cpu_thread_spec),
> > > "%s: Could not start rcub kthread, OOM is now expected behavior\n",
> > > __func__))
> > > return;
> > > rcu_for_each_leaf_node(rnp)
> > > - (void)rcu_spawn_one_boost_kthread(rnp);
> > > + rcu_spawn_one_boost_kthread(rnp);
> > > }
> > >
> > > static void rcu_prepare_kthreads(int cpu)
> > > @@ -1275,7 +1274,7 @@ static void rcu_prepare_kthreads(int cpu)
> > >
> > > /* Fire up the incoming CPU's kthread and leaf rcu_node kthread. */
> > > if (rcu_scheduler_fully_active)
> > > - (void)rcu_spawn_one_boost_kthread(rnp);
> > > + rcu_spawn_one_boost_kthread(rnp);
> > > }
> > >
> > > #else /* #ifdef CONFIG_RCU_BOOST */
> > > --
> > > 1.9.1
> > >
