Re: [PATCH v1 5/9] firmware: keembay: Add support for Trusted Firmware Service call
On Mon, Jan 18, 2021 at 10:28:33AM +, Zulkifli, Muhammad Husaini wrote:
> Hi Sudeep and Mark,
>
> Thanks for the review. I replied inline.
>
> >-Original Message-
> >From: Sudeep Holla
> >Sent: Saturday, January 16, 2021 2:58 AM
> >To: Mark Brown
> >Cc: Zulkifli, Muhammad Husaini ;
> >ulf.hans...@linaro.org; lgirdw...@gmail.com; robh...@kernel.org;
> >devicet...@vger.kernel.org; Hunter, Adrian ;
> >michal.si...@xilinx.com; linux-...@vger.kernel.org; linux-
> >ker...@vger.kernel.org; Shevchenko, Andriy
> >; A, Rashmi ; Vaidya,
> >Mahesh R ; Sudeep Holla
> >
> >Subject: Re: [PATCH v1 5/9] firmware: keembay: Add support for Trusted
> >Firmware Service call
> >
> >On Thu, Jan 14, 2021 at 04:48:11PM +, Mark Brown wrote:
> >> On Thu, Jan 14, 2021 at 11:26:56PM +0800, Muhammad Husaini Zulkifli
> >wrote:
> >> > Export inline function to encapsulate AON_CFG1 for controling the
> >> > I/O Rail supplied voltage levels which communicate with Trusted Firmware.
> >>
> >> Adding Sudeep for the SMCCC bits, not deleting any context for his
> >> benefit.
> >>
> >
> >Thanks Mark for cc-ing me and joining the dots. I completely forgot about
> >that
> >fact that this platform was using SCMI using SMC as transport. Sorry for
> >that and
> >it is my fault. I did review the SCMI/SMC support for this platform sometime
> >in
> >June/July last year and forgot the fact it is same platform when
> >voltage/regulator support patches for SD/MMC was posted sometime later last
> >year. I concentrated on SMCCC conventions and other details.
>
> Yes Sudeep. I redesigned the way I handle the smccc call. Previously it was
> handled directly in mmc driver.
> After few discussion, we conclude to create an abstraction using regulator
> framework to encapsulate this smccc call
> during set voltage operation. Using standard abstraction will make things
> easier for the maintainer.
>
> >
> >[...]
> >
> >> > +#define ARM_SMCCC_SIP_KEEMBAY_SET_SD_VOLTAGE\
> >> > +ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> >> > + ARM_SMCCC_SMC_32,\
> >> > + ARM_SMCCC_OWNER_SIP, \
> >> > + KEEMBAY_SET_SD_VOLTAGE_ID)
> >> > +
> >> > +#define ARM_SMCCC_SIP_KEEMBAY_GET_SD_VOLTAGE\
> >> > +ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> >> > + ARM_SMCCC_SMC_32,\
> >> > + ARM_SMCCC_OWNER_SIP, \
> >> > + KEEMBAY_GET_SD_VOLTAGE_ID)
> >> > +
> >> > +#define KEEMBAY_REG_NUM_CONSUMERS 2
> >> > +
> >> > +struct keembay_reg_supply {
> >> > +struct regulator *consumer;
> >> > +};
> >> > +
> >> > +#if IS_ENABLED(CONFIG_HAVE_ARM_SMCCC_DISCOVERY)
> >> > +/*
> >> > + * Voltage applied on the IO Rail is controlled from the Always On
> >> > +Register using specific
> >> > + * bits in AON_CGF1 register. This is a secure register. Keem Bay
> >> > +SOC cannot exposed this
> >> > + * register address to the outside world.
> >> > + */
> >> > +static inline int keembay_set_io_rail_supplied_voltage(int volt) {
> >> > +struct arm_smccc_res res;
> >> > +
> >> > +
> > arm_smccc_1_1_invoke(ARM_SMCCC_SIP_KEEMBAY_SET_SD_VOLTA
> >GE, volt,
> >> > +&res);
> >>
> >> There is a SCMI voltage domain protocol intended for just this use
> >> case of controlling regulators managed by the firmware, why are you
> >> not using that for these systems? See drivers/firmware/arm_scmi/voltage.c.
>
> From mmc maintainer's perspective, I should use the common modelling either
> using regulator framework or pinctrl to perform voltage operation. Not just
> directly invoke smccc call in the mmc driver. That is why I came up with
> this regulator driver to perform voltage operation.
>
That's correct. Since the platform uses SCMI and SCMI spec[1] supports Voltage
protocol and there is upstream driver[2] to support it, I see no point in
duplicating the support with another custom/non-standard solution.
> >>
> >
> >Indeed. Please switch to using the new voltage protocol added for this
> >without
> >any extra code. You just need to wire up DT for this.
>
> May I know even if I wire up the DT, how should I call this from the mmc
> driver
> For set/get voltage operation? Any example?
>
Mark has already pointed you to the binding document[3]
> >
> >Just for curiosity, where is SCMI platform firmware implemented ? On Cortex-
> >A, secure side or external processor. Does this platform run TF-A ?
>
> The KMB SCMI framework is implemented in secure runtime firmware (TF-A BL31).
> Hopefully I am answering your question.
>
Yes, it should be easy to extend the implementation and add support for
voltage protocol.
If you still face any issues, please ask any queries on the list cc-ing
me and Cristian Marussi(cc-ed)
--
Regards,
Sudeep
[1] https://developer.arm.com/documentation/den0056/latest
[2] drivers/firmware/arm_scmi/voltage.c +
Re: [PATCH] usb: bdc: Remove the BDC PCI driver
On Mon, Jan 18, 2021 at 01:30:36PM +0200, Felipe Balbi wrote: > > Hi, > > Al Cooper writes: > > The BDC PCI driver was only used for design verification with > > an PCI/FPGA board. The board no longer exists and is not in use > > anywhere. All instances of this core now exist as a memory mapped > > device on the platform bus. > > > > NOTE: This only removes the PCI driver and does not remove the > > platform driver. > > > > Signed-off-by: Al Cooper > > It sounds like it could be used for pre-silicon verification of newer > Core Releases, much like Synopsys still uses the HAPS (with mainline > linux, mind you) for silicon validation. > > Why would we delete this small shim if it *could* still be useful? It ends up conflicting with the PCI id of a device that is actually in the wild (a camera on Apple laptops). So it's good to drop this driver so the wrong driver doesn't get constantly bound to the wrong device. thnaks, greg k-h
Re: [PATCH v2 02/12] ASoC: arizona-jack: Add arizona-jack.c
On Sun, Jan 17, 2021 at 6:06 PM Hans de Goede wrote: > > Add an unmodified copy of drivers/extcon/extcon-arizona.c as > sound/soc/codecs/arizona-jack.c . Usually adding -M -C to `git format-patch` helps a lot of rename detections. I think in the next version we easily see the evidence of the above which makes review by snapping our fingers. > This is a preparation patch for converting the arizona extcon driver into > a helper library for letting the arizona codec-drivers directly report jack > state through the standard sound/soc/soc-jack.c functions. -- With Best Regards, Andy Shevchenko
re: GTP: add support for flow based tunneling API
Hi,
Static analysis of today's linux-next using Coverity has found a
potential memory leak issue in the following commit:
commit 9ab7e76aefc97a9aa664accb59d6e8dc5e52514a
Author: Pravin B Shelar
Date: Sat Jan 9 23:00:21 2021 -0800
GTP: add support for flow based tunneling API
The analysis is as follows:
186 static int gtp_set_tun_dst(struct gtp_dev *gtp, struct sk_buff *skb,
187 unsigned int hdrlen, u8 gtp_version,
188 __be64 tid, u8 flags)
189 {
190struct metadata_dst *tun_dst;
191int opts_len = 0;
192
1. Condition !!(flags & 7), taking true branch.
2. Condition !!(flags & 7), taking true branch.
193if (unlikely(flags & GTP1_F_MASK))
194opts_len = sizeof(struct gtpu_metadata);
195
3. alloc_fn: Storage is returned from allocation function udp_tun_rx_dst.
4. var_assign: Assigning: tun_dst = storage returned from
udp_tun_rx_dst(skb, gtp->sk1u->__sk_common.skc_family, 1024, tid, opts_len).
196tun_dst = udp_tun_rx_dst(skb, gtp->sk1u->sk_family,
TUNNEL_KEY, tid, opts_len);
5. Condition !tun_dst, taking false branch.
197if (!tun_dst) {
198netdev_dbg(gtp->dev, "Failed to allocate tun_dst");
199goto err;
200}
201
6. Condition 0 /* __builtin_types_compatible_p() */, taking false branch.
7. Condition 1 /* __builtin_types_compatible_p() */, taking true branch.
8. Falling through to end of if statement.
9. Condition !!branch, taking false branch.
10. Condition ({...; !!branch;}), taking false branch.
202netdev_dbg(gtp->dev, "attaching metadata_dst to skb, gtp ver
%d hdrlen %d\n",
203 gtp_version, hdrlen);
11. Condition !!opts_len, taking true branch.
12. Condition !!opts_len, taking true branch.
204if (unlikely(opts_len)) {
205struct gtpu_metadata *opts;
206struct gtp1_header *gtp1;
207
208opts = ip_tunnel_info_opts(&tun_dst->u.tun_info);
209gtp1 = (struct gtp1_header *)(skb->data +
sizeof(struct udphdr));
210opts->ver = GTP_METADATA_V1;
211opts->flags = gtp1->flags;
212opts->type = gtp1->type;
13. Condition 0 /* __builtin_types_compatible_p() */, taking false
branch.
14. Condition 1 /* __builtin_types_compatible_p() */, taking true branch.
15. Falling through to end of if statement.
16. Condition !!branch, taking false branch.
17. Condition ({...; !!branch;}), taking false branch.
213netdev_dbg(gtp->dev, "recved control pkt: flag %x
type: %d\n",
214 opts->flags, opts->type);
215tun_dst->u.tun_info.key.tun_flags |= TUNNEL_GTPU_OPT;
216tun_dst->u.tun_info.options_len = opts_len;
217skb->protocol = htons(0x); /* Unknown */
218}
219/* Get rid of the GTP + UDP headers. */
18. Condition !net_eq(sock_net(gtp->sk1u), dev_net(gtp->dev)), taking
false branch.
19. Condition !net_eq(sock_net(gtp->sk1u), dev_net(gtp->dev)), taking
false branch.
20. Condition iptunnel_pull_header(skb, hdrlen, skb->protocol,
!net_eq(sock_net(gtp->sk1u), dev_net(gtp->dev))), taking true branch.
220if (iptunnel_pull_header(skb, hdrlen, skb->protocol,
221 !net_eq(sock_net(gtp->sk1u),
dev_net(gtp->dev {
222gtp->dev->stats.rx_length_errors++;
21. Jumping to label err.
223goto err;
224}
225
226skb_dst_set(skb, &tun_dst->dst);
227return 0;
228 err:
Resource leak (RESOURCE_LEAK)
22. leaked_storage: Variable tun_dst going out of scope leaks the
storage it points to.
229return -1;
230 }
The goto on line 223 is leaking tun_dst. From what I can see, I believe
a call to kfree(tun_dst) before the goto on line 223 looks like a
pertinent fix, but I'm not 100% sure, so I'm flagging this up as an
issue that need further investigation by folk who are more familiar with
this code.
Colin
Re: [PATCH v1 5/9] firmware: keembay: Add support for Trusted Firmware Service call
Hi
sorry I'm a bit late on this.
On Mon, Jan 18, 2021 at 10:28:33AM +, Zulkifli, Muhammad Husaini wrote:
> Hi Sudeep and Mark,
>
> Thanks for the review. I replied inline.
>
> >-Original Message-
> >From: Sudeep Holla
> >Sent: Saturday, January 16, 2021 2:58 AM
> >To: Mark Brown
> >Cc: Zulkifli, Muhammad Husaini ;
> >ulf.hans...@linaro.org; lgirdw...@gmail.com; robh...@kernel.org;
> >devicet...@vger.kernel.org; Hunter, Adrian ;
> >michal.si...@xilinx.com; linux-...@vger.kernel.org; linux-
> >ker...@vger.kernel.org; Shevchenko, Andriy
> >; A, Rashmi ; Vaidya,
> >Mahesh R ; Sudeep Holla
> >
> >Subject: Re: [PATCH v1 5/9] firmware: keembay: Add support for Trusted
> >Firmware Service call
> >
> >On Thu, Jan 14, 2021 at 04:48:11PM +, Mark Brown wrote:
> >> On Thu, Jan 14, 2021 at 11:26:56PM +0800, Muhammad Husaini Zulkifli
> >wrote:
> >> > Export inline function to encapsulate AON_CFG1 for controling the
> >> > I/O Rail supplied voltage levels which communicate with Trusted Firmware.
> >>
> >> Adding Sudeep for the SMCCC bits, not deleting any context for his
> >> benefit.
> >>
> >
> >Thanks Mark for cc-ing me and joining the dots. I completely forgot about
> >that
> >fact that this platform was using SCMI using SMC as transport. Sorry for
> >that and
> >it is my fault. I did review the SCMI/SMC support for this platform sometime
> >in
> >June/July last year and forgot the fact it is same platform when
> >voltage/regulator support patches for SD/MMC was posted sometime later last
> >year. I concentrated on SMCCC conventions and other details.
>
> Yes Sudeep. I redesigned the way I handle the smccc call. Previously it was
> handled directly in mmc driver.
> After few discussion, we conclude to create an abstraction using regulator
> framework to encapsulate this smccc call
> during set voltage operation. Using standard abstraction will make things
> easier for the maintainer.
>
> >
> >[...]
> >
> >> > +#define ARM_SMCCC_SIP_KEEMBAY_SET_SD_VOLTAGE\
> >> > +ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> >> > + ARM_SMCCC_SMC_32,\
> >> > + ARM_SMCCC_OWNER_SIP, \
> >> > + KEEMBAY_SET_SD_VOLTAGE_ID)
> >> > +
> >> > +#define ARM_SMCCC_SIP_KEEMBAY_GET_SD_VOLTAGE\
> >> > +ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> >> > + ARM_SMCCC_SMC_32,\
> >> > + ARM_SMCCC_OWNER_SIP, \
> >> > + KEEMBAY_GET_SD_VOLTAGE_ID)
> >> > +
> >> > +#define KEEMBAY_REG_NUM_CONSUMERS 2
> >> > +
> >> > +struct keembay_reg_supply {
> >> > +struct regulator *consumer;
> >> > +};
> >> > +
> >> > +#if IS_ENABLED(CONFIG_HAVE_ARM_SMCCC_DISCOVERY)
> >> > +/*
> >> > + * Voltage applied on the IO Rail is controlled from the Always On
> >> > +Register using specific
> >> > + * bits in AON_CGF1 register. This is a secure register. Keem Bay
> >> > +SOC cannot exposed this
> >> > + * register address to the outside world.
> >> > + */
> >> > +static inline int keembay_set_io_rail_supplied_voltage(int volt) {
> >> > +struct arm_smccc_res res;
> >> > +
> >> > +
> > arm_smccc_1_1_invoke(ARM_SMCCC_SIP_KEEMBAY_SET_SD_VOLTA
> >GE, volt,
> >> > +&res);
> >>
> >> There is a SCMI voltage domain protocol intended for just this use
> >> case of controlling regulators managed by the firmware, why are you
> >> not using that for these systems? See drivers/firmware/arm_scmi/voltage.c.
>
> From mmc maintainer's perspective, I should use the common modelling either
> using
> regulator framework or pinctrl to perform voltage operation. Not just
> directly invoke
> smccc call in the mmc driver. That is why I came up with this regulator
> driver to perform
> voltage operation.
>
There is an SCMI regulator driver built on top of SCMIv3.0 Voltage Domain
Protocol, so as long as your SCMI platform firmware support the new VD
protocol you should be able to wire up a generic SCMI regulator in the DT
(as described in the arm,scmi.txt bindings) and then just use the usual
regulator framework ops with such SCMI regulator without the need to add
a custom regulator using custom SMCCC calls).
Thanks
Cristian
> >>
> >
> >Indeed. Please switch to using the new voltage protocol added for this
> >without
> >any extra code. You just need to wire up DT for this.
>
> May I know even if I wire up the DT, how should I call this from the mmc
> driver
> For set/get voltage operation? Any example?
>
> >
> >Just for curiosity, where is SCMI platform firmware implemented ? On Cortex-
> >A, secure side or external processor. Does this platform run TF-A ?
>
> The KMB SCMI framework is implemented in secure runtime firmware (TF-A BL31).
> Hopefully I am answering your question.
>
> >
> >--
> >Regards,
> >Sudeep
Re: [PATCH v3 3/3] ASoC: rt715:add micmute led state control supports
On Sat, Jan 16, 2021 at 11:50:31PM +0800, Perry Yuan wrote: > On 2021/1/13 1:54, Mark Brown wrote: > > > + bool micmute_led; > > What is this for, it never seems to be read except for in the function > > where it's set? > Do you mean i can use a local micmute_led var in the function? Yes. signature.asc Description: PGP signature
RE: [PATCH v17 05/10] fs/ntfs3: Add attrib operations
From: Kari Argillander
Sent: Monday, January 4, 2021 3:26 AM
> To: Konstantin Komarov
> Cc: linux-fsde...@vger.kernel.org; v...@zeniv.linux.org.uk;
> linux-kernel@vger.kernel.org; p...@kernel.org; dste...@suse.cz;
> aap...@suse.com; wi...@infradead.org; rdun...@infradead.org;
> j...@perches.com; m...@harmstone.com; nbori...@suse.com;
> linux-ntfs-...@lists.sourceforge.net; an...@tuxera.com;
> dan.carpen...@oracle.com; h...@lst.de; ebigg...@kernel.org;
> andy.l...@gmail.com
> Subject: Re: [PATCH v17 05/10] fs/ntfs3: Add attrib operations
>
> On Thu, Dec 31, 2020 at 06:23:56PM +0300, Konstantin Komarov wrote:
> > This adds attrib operations
> >
> > Signed-off-by: Konstantin Komarov
> > ---
> > fs/ntfs3/attrib.c | 2081 +++
> > fs/ntfs3/attrlist.c | 463 ++
> > fs/ntfs3/xattr.c| 1072 ++
> > 3 files changed, 3616 insertions(+)
> > create mode 100644 fs/ntfs3/attrib.c
> > create mode 100644 fs/ntfs3/attrlist.c
> > create mode 100644 fs/ntfs3/xattr.c
> >
> > diff --git a/fs/ntfs3/attrlist.c b/fs/ntfs3/attrlist.c
>
> > +/*
> > + * al_find_ex
> > + *
> > + * finds the first le in the list which matches type, name and vcn
> > + * Returns NULL if not found
> > + */
> > +struct ATTR_LIST_ENTRY *al_find_ex(struct ntfs_inode *ni,
> > + struct ATTR_LIST_ENTRY *le,
> > + enum ATTR_TYPE type, const __le16 *name,
> > + u8 name_len, const CLST *vcn)
> > +{
> > + struct ATTR_LIST_ENTRY *ret = NULL;
> > + u32 type_in = le32_to_cpu(type);
> > +
> > + while ((le = al_enumerate(ni, le))) {
> > + u64 le_vcn;
> > + int diff;
> > +
> > + /* List entries are sorted by type, name and vcn */
>
> Isn't name sorted with upcase sort.
>
Hi! You are correct. Will be fixed in v18.
> > + diff = le32_to_cpu(le->type) - type_in;
> > + if (diff < 0)
> > + continue;
> > +
> > + if (diff > 0)
> > + return ret;
> > +
> > + if (le->name_len != name_len)
> > + continue;
> > +
> > + if (name_len &&
> > + memcmp(le_name(le), name, name_len * sizeof(short)))
> > + continue;
>
> So does this compare name correctly? So it is caller responsible that
> name is up_cased? Or does it even mater.
>
> And this will check every name in right type. Why not use name_cmp and
> then we know if we over. It might be because performance. But maybe
> we can check that like every 10 iteration or something.
>
Now name check will be only for list_entry with vcn==0.
> > + if (!vcn)
> > + return le;
> > +
> > + le_vcn = le64_to_cpu(le->vcn);
> > + if (*vcn == le_vcn)
> > + return le;
> > +
> > + if (*vcn < le_vcn)
> > + return ret;
> > +
> > + ret = le;
>
> So we still have wrong vcn at this point. And we save that so we can
> return it. What happens if we will not found right one. Atlest function
> comment say that we should return NULL if we do not found matching entry.
>
Can't agree here.
E.g. given list_entry: 0, 67, 89, 110, 137.
The function will return 89 as the similar thread stores the info about
vcn==100.
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +/*
> > + * al_find_le_to_insert
> > + *
> > + * finds the first list entry which matches type, name and vcn
>
> This comment seems wrong? This seems to find insert point for new
> le.
>
Thanks for this. Fixed.
> > + * Returns NULL if not found
> > + */
> > +static struct ATTR_LIST_ENTRY *
> > +al_find_le_to_insert(struct ntfs_inode *ni, enum ATTR_TYPE type,
> > +const __le16 *name, u8 name_len, const CLST *vcn)
> > +{
> > + struct ATTR_LIST_ENTRY *le = NULL, *prev;
> > + u32 type_in = le32_to_cpu(type);
> > + int diff;
> > +
> > + /* List entries are sorted by type, name, vcn */
> > +next:
> > + le = al_enumerate(ni, prev = le);
> > + if (!le)
> > + goto out;
> > + diff = le32_to_cpu(le->type) - type_in;
> > + if (diff < 0)
> > + goto next;
> > + if (diff > 0)
> > + goto out;
> > +
> > + if (ntfs_cmp_names(name, name_len, le_name(le), le->name_len, NULL) > 0)
> > + goto next;
>
> Why not go out if compare is < 0. In my mind this will totally ignore
> name and next just find right vcn (or we come next ID) and call it a day.
>
Will be fixed in v18 as well.
> NAME VCN
> [AAB] [2] <- Looks insert point for this.
>
> [AAA] [1]
> [AAB] [1]
> <- This is right point.
> [AAC] [1]
> <- But we tell that insert point is here.
> [AAD] [2]
>
> I might be totally wrong but please tell me what I'm missing.
>
> > + if (!vcn || *vcn > le64_to_cpu(le->vcn))
> > + goto next;
> > +
> > +out:
> > + if (!le)
> > + le = prev ? Add2Ptr(prev, le16_to_
Re: [PATCH v3 1/7] regulator: qcom-labibb: Implement voltage selector ops
On Sun, Jan 17, 2021 at 11:08:24PM +0100, AngeloGioacchino Del Regno wrote:
> Implement {get,set}_voltage_sel, list_voltage, map_voltage with
> the useful regulator regmap helpers in order to be able to manage
> the voltage of LAB (positive) and IBB (negative) regulators.
Please do not submit new versions of already applied patches, please
submit incremental updates to the existing code. Modifying existing
commits creates problems for other users building on top of those
commits so it's best practice to only change pubished git commits if
absolutely essential.
signature.asc
Description: PGP signature
Re: [PATCH v3 18/21] dt-bindings: allwinner: Add H616 compatible strings
On Mon, Jan 18, 2021 at 02:08:45AM +, Andre Przywara wrote: > Add simple "allwinner,sun50i-h616-xxx" compatible names to existing > bindings, and pair them with an existing fallback compatible string, > as the devices are compatible. > This covers I2C, infrared, RTC and SPI. > > Use enums to group all compatible devices together. Please submit normal, per subsystem patches for things like this. signature.asc Description: PGP signature
Re: [PATCH v2 06/12] ASoC: arizona-jack: Move jack-detect variables to struct arizona_priv
On Sun, Jan 17, 2021 at 6:06 PM Hans de Goede wrote:
>
> Move all the jack-detect variables from struct arizona_extcon_info to
> struct arizona_priv.
>
> This is part of a patch series converting the arizona extcon driver into
> a helper library for letting the arizona codec-drivers directly report jack
> state through the standard sound/soc/soc-jack.c functions.
Seems straight forward.
Reviewed-by: Andy Shevchenko
> Signed-off-by: Hans de Goede
> ---
> sound/soc/codecs/arizona-jack.c | 97 ++---
> sound/soc/codecs/arizona.h | 36
> 2 files changed, 65 insertions(+), 68 deletions(-)
>
> diff --git a/sound/soc/codecs/arizona-jack.c b/sound/soc/codecs/arizona-jack.c
> index 72d23b15108c..c81c3b20f94e 100644
> --- a/sound/soc/codecs/arizona-jack.c
> +++ b/sound/soc/codecs/arizona-jack.c
> @@ -27,6 +27,8 @@
> #include
> #include
>
> +#include "arizona.h"
> +
> #define ARIZONA_MAX_MICD_RANGE 8
>
> #define ARIZONA_MICD_CLAMP_MODE_JDL 0x4
> @@ -61,47 +63,6 @@
>
> #define MICD_LVL_0_TO_8 (MICD_LVL_0_TO_7 | ARIZONA_MICD_LVL_8)
>
> -struct arizona_extcon_info {
> - struct device *dev;
> - struct arizona *arizona;
> - struct mutex lock;
> - struct regulator *micvdd;
> - struct input_dev *input;
> -
> - u16 last_jackdet;
> -
> - int micd_mode;
> - const struct arizona_micd_config *micd_modes;
> - int micd_num_modes;
> -
> - const struct arizona_micd_range *micd_ranges;
> - int num_micd_ranges;
> -
> - bool micd_reva;
> - bool micd_clamp;
> -
> - struct delayed_work hpdet_work;
> - struct delayed_work micd_detect_work;
> - struct delayed_work micd_timeout_work;
> -
> - bool hpdet_active;
> - bool hpdet_done;
> - bool hpdet_retried;
> -
> - int num_hpdet_res;
> - unsigned int hpdet_res[3];
> -
> - bool mic;
> - bool detecting;
> - int jack_flips;
> -
> - int hpdet_ip_version;
> -
> - struct extcon_dev *edev;
> -
> - struct gpio_desc *micd_pol_gpio;
> -};
> -
> static const struct arizona_micd_config micd_default_modes[] = {
> { ARIZONA_ACCDET_SRC, 1, 0 },
> { 0, 2, 1 },
> @@ -135,9 +96,9 @@ static const unsigned int arizona_cable[] = {
> EXTCON_NONE,
> };
>
> -static void arizona_start_hpdet_acc_id(struct arizona_extcon_info *info);
> +static void arizona_start_hpdet_acc_id(struct arizona_priv *info);
>
> -static void arizona_extcon_hp_clamp(struct arizona_extcon_info *info,
> +static void arizona_extcon_hp_clamp(struct arizona_priv *info,
> bool clamp)
> {
> struct arizona *arizona = info->arizona;
> @@ -222,7 +183,7 @@ static void arizona_extcon_hp_clamp(struct
> arizona_extcon_info *info,
> snd_soc_dapm_mutex_unlock(arizona->dapm);
> }
>
> -static void arizona_extcon_set_mode(struct arizona_extcon_info *info, int
> mode)
> +static void arizona_extcon_set_mode(struct arizona_priv *info, int mode)
> {
> struct arizona *arizona = info->arizona;
>
> @@ -243,7 +204,7 @@ static void arizona_extcon_set_mode(struct
> arizona_extcon_info *info, int mode)
> dev_dbg(arizona->dev, "Set jack polarity to %d\n", mode);
> }
>
> -static const char *arizona_extcon_get_micbias(struct arizona_extcon_info
> *info)
> +static const char *arizona_extcon_get_micbias(struct arizona_priv *info)
> {
> switch (info->micd_modes[0].bias) {
> case 1:
> @@ -257,7 +218,7 @@ static const char *arizona_extcon_get_micbias(struct
> arizona_extcon_info *info)
> }
> }
>
> -static void arizona_extcon_pulse_micbias(struct arizona_extcon_info *info)
> +static void arizona_extcon_pulse_micbias(struct arizona_priv *info)
> {
> struct arizona *arizona = info->arizona;
> const char *widget = arizona_extcon_get_micbias(info);
> @@ -282,7 +243,7 @@ static void arizona_extcon_pulse_micbias(struct
> arizona_extcon_info *info)
> }
> }
>
> -static void arizona_start_mic(struct arizona_extcon_info *info)
> +static void arizona_start_mic(struct arizona_priv *info)
> {
> struct arizona *arizona = info->arizona;
> bool change;
> @@ -339,7 +300,7 @@ static void arizona_start_mic(struct arizona_extcon_info
> *info)
> }
> }
>
> -static void arizona_stop_mic(struct arizona_extcon_info *info)
> +static void arizona_stop_mic(struct arizona_priv *info)
> {
> struct arizona *arizona = info->arizona;
> const char *widget = arizona_extcon_get_micbias(info);
> @@ -407,7 +368,7 @@ static struct {
> { 1000, 1 },
> };
>
> -static int arizona_hpdet_read(struct arizona_extcon_info *info)
> +static int arizona_hpdet_read(struct arizona_priv *info)
> {
> struct arizona *arizona = info->arizona;
> unsigned int val, range;
> @@ -527,7 +488,7 @@ static int arizona_hpdet_read(struct arizona_extcon_info
> *info)
> return v
Re: [PATCH] openrisc: add arch/openrisc/Kbuild
On Sun, Jan 17, 2021 at 05:03:32PM +0900, Masahiro Yamada wrote: > Describe the subdirectories under arch/openrisc/ in arch/openrisc/Kbuild > so you can use the standard obj-y syntax. > > I removed the CONFIG_OPENRISC_BUILTIN_DTB conditional because it is > already controlled by arch/openrisc/boot/dts/Makefile. > > Signed-off-by: Masahiro Yamada Thank you, This looks OK to me, I have queued this for next. There was a small conflict with the vmlinux.bin changes you reviewed earlier. I resolved them and did a test bild and it seems to all be fine. -Stafford
[PATCH 5.10 037/152] compiler.h: Raise minimum version of GCC to 5.1 for arm64
From: Will Deacon commit dca5244d2f5b94f1809f0c02a549edf41ccd5493 upstream. GCC versions >= 4.9 and < 5.1 have been shown to emit memory references beyond the stack pointer, resulting in memory corruption if an interrupt is taken after the stack pointer has been adjusted but before the reference has been executed. This leads to subtle, infrequent data corruption such as the EXT4 problems reported by Russell King at the link below. Life is too short for buggy compilers, so raise the minimum GCC version required by arm64 to 5.1. Reported-by: Russell King Suggested-by: Arnd Bergmann Signed-off-by: Will Deacon Tested-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Reviewed-by: Nathan Chancellor Acked-by: Linus Torvalds Cc: Cc: Theodore Ts'o Cc: Florian Weimer Cc: Peter Zijlstra Cc: Nick Desaulniers Link: https://lore.kernel.org/r/20210105154726.gd1...@shell.armlinux.org.uk Link: https://lore.kernel.org/r/20210112224832.10980-1-w...@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman --- include/linux/compiler-gcc.h |6 ++ 1 file changed, 6 insertions(+) --- a/include/linux/compiler-gcc.h +++ b/include/linux/compiler-gcc.h @@ -13,6 +13,12 @@ /* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 */ #if GCC_VERSION < 40900 # error Sorry, your version of GCC is too old - please use 4.9 or newer. +#elif defined(CONFIG_ARM64) && GCC_VERSION < 50100 +/* + * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63293 + * https://lore.kernel.org/r/20210107111841.gn1...@shell.armlinux.org.uk + */ +# error Sorry, your version of GCC is too old - please use 5.1 or newer. #endif /*
Re: [PATCH v2 07/12] ASoC: arizona-jack: Use arizona->dev for runtime-pm
On Sun, Jan 17, 2021 at 6:06 PM Hans de Goede wrote: > > Use arizona->dev for runtime-pm as the main shared/libray code from > sound/soc/codecs/arizona.c does. Can you elaborate switchings from get() to get_sync() in few places along with moving disable()? -- With Best Regards, Andy Shevchenko
Re: [PATCH v4 net-next] net: bridge: check vlan with eth_type_vlan() method
On 17/01/2021 10:09, menglong8.d...@gmail.com wrote: > From: Menglong Dong > > Replace some checks for ETH_P_8021Q and ETH_P_8021AD with > eth_type_vlan(). > > Signed-off-by: Menglong Dong > --- > v4: > - remove unnecessary brackets. > > v3: > - fix compile warning in br_vlan_set_proto() by casting 'val' to > be16. > > v2: > - use eth_type_vlan() in br_validate() and __br_vlan_set_proto() > too. > --- > net/bridge/br_forward.c | 3 +-- > net/bridge/br_netlink.c | 12 +++- > net/bridge/br_vlan.c| 2 +- > 3 files changed, 5 insertions(+), 12 deletions(-) > Acked-by: Nikolay Aleksandrov
[PATCH 5.10 043/152] dm integrity: fix flush with external metadata device
From: Mikulas Patocka
commit 9b5948267adc9e689da609eb61cf7ed49cae5fa8 upstream.
With external metadata device, flush requests are not passed down to the
data device.
Fix this by submitting the flush request in dm_integrity_flush_buffers. In
order to not degrade performance, we overlap the data device flush with
the metadata device flush.
Reported-by: Lukas Straub
Signed-off-by: Mikulas Patocka
Cc: sta...@vger.kernel.org
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman
---
drivers/md/dm-bufio.c |6
drivers/md/dm-integrity.c | 60 +-
include/linux/dm-bufio.h |1
3 files changed, 56 insertions(+), 11 deletions(-)
--- a/drivers/md/dm-bufio.c
+++ b/drivers/md/dm-bufio.c
@@ -1534,6 +1534,12 @@ sector_t dm_bufio_get_device_size(struct
}
EXPORT_SYMBOL_GPL(dm_bufio_get_device_size);
+struct dm_io_client *dm_bufio_get_dm_io_client(struct dm_bufio_client *c)
+{
+ return c->dm_io;
+}
+EXPORT_SYMBOL_GPL(dm_bufio_get_dm_io_client);
+
sector_t dm_bufio_get_block_number(struct dm_buffer *b)
{
return b->block;
--- a/drivers/md/dm-integrity.c
+++ b/drivers/md/dm-integrity.c
@@ -1379,12 +1379,52 @@ thorough_test:
#undef MAY_BE_HASH
}
-static void dm_integrity_flush_buffers(struct dm_integrity_c *ic)
+struct flush_request {
+ struct dm_io_request io_req;
+ struct dm_io_region io_reg;
+ struct dm_integrity_c *ic;
+ struct completion comp;
+};
+
+static void flush_notify(unsigned long error, void *fr_)
+{
+ struct flush_request *fr = fr_;
+ if (unlikely(error != 0))
+ dm_integrity_io_error(fr->ic, "flusing disk cache", -EIO);
+ complete(&fr->comp);
+}
+
+static void dm_integrity_flush_buffers(struct dm_integrity_c *ic, bool
flush_data)
{
int r;
+
+ struct flush_request fr;
+
+ if (!ic->meta_dev)
+ flush_data = false;
+ if (flush_data) {
+ fr.io_req.bi_op = REQ_OP_WRITE,
+ fr.io_req.bi_op_flags = REQ_PREFLUSH | REQ_SYNC,
+ fr.io_req.mem.type = DM_IO_KMEM,
+ fr.io_req.mem.ptr.addr = NULL,
+ fr.io_req.notify.fn = flush_notify,
+ fr.io_req.notify.context = &fr;
+ fr.io_req.client = dm_bufio_get_dm_io_client(ic->bufio),
+ fr.io_reg.bdev = ic->dev->bdev,
+ fr.io_reg.sector = 0,
+ fr.io_reg.count = 0,
+ fr.ic = ic;
+ init_completion(&fr.comp);
+ r = dm_io(&fr.io_req, 1, &fr.io_reg, NULL);
+ BUG_ON(r);
+ }
+
r = dm_bufio_write_dirty_buffers(ic->bufio);
if (unlikely(r))
dm_integrity_io_error(ic, "writing tags", r);
+
+ if (flush_data)
+ wait_for_completion(&fr.comp);
}
static void sleep_on_endio_wait(struct dm_integrity_c *ic)
@@ -2110,7 +2150,7 @@ offload_to_thread:
if (unlikely(dio->op == REQ_OP_DISCARD) && likely(ic->mode != 'D')) {
integrity_metadata(&dio->work);
- dm_integrity_flush_buffers(ic);
+ dm_integrity_flush_buffers(ic, false);
dio->in_flight = (atomic_t)ATOMIC_INIT(1);
dio->completion = NULL;
@@ -2195,7 +2235,7 @@ static void integrity_commit(struct work
flushes = bio_list_get(&ic->flush_bio_list);
if (unlikely(ic->mode != 'J')) {
spin_unlock_irq(&ic->endio_wait.lock);
- dm_integrity_flush_buffers(ic);
+ dm_integrity_flush_buffers(ic, true);
goto release_flush_bios;
}
@@ -2409,7 +2449,7 @@ skip_io:
complete_journal_op(&comp);
wait_for_completion_io(&comp.comp);
- dm_integrity_flush_buffers(ic);
+ dm_integrity_flush_buffers(ic, true);
}
static void integrity_writer(struct work_struct *w)
@@ -2451,7 +2491,7 @@ static void recalc_write_super(struct dm
{
int r;
- dm_integrity_flush_buffers(ic);
+ dm_integrity_flush_buffers(ic, false);
if (dm_integrity_failed(ic))
return;
@@ -2654,7 +2694,7 @@ static void bitmap_flush_work(struct wor
unsigned long limit;
struct bio *bio;
- dm_integrity_flush_buffers(ic);
+ dm_integrity_flush_buffers(ic, false);
range.logical_sector = 0;
range.n_sectors = ic->provided_data_sectors;
@@ -2663,9 +2703,7 @@ static void bitmap_flush_work(struct wor
add_new_range_and_wait(ic, &range);
spin_unlock_irq(&ic->endio_wait.lock);
- dm_integrity_flush_buffers(ic);
- if (ic->meta_dev)
- blkdev_issue_flush(ic->dev->bdev, GFP_NOIO);
+ dm_integrity_flush_buffers(ic, true);
limit = ic->provided_data_sectors;
if (ic->sb->flags & cpu_to_le32(SB_FLAG_RECALCULATING)) {
@@ -2934,11 +2972,11 @@ static void dm_integrity_postsuspend(str
if (ic->meta_dev)
q
[PATCH 5.10 009/152] drm/amdgpu: fix DRM_INFO flood if display core is not supported (bug 210921)
From: Alexandre Demers
commit ff9346dbabbb6595c5c20d90d88ae4a2247487a9 upstream.
This fix bug 210921 where DRM_INFO floods log when hitting an unsupported ASIC
in
amdgpu_device_asic_has_dc_support(). This info should be only called once.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=210921
Signed-off-by: Alexandre Demers
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3008,7 +3008,7 @@ bool amdgpu_device_asic_has_dc_support(e
#endif
default:
if (amdgpu_dc > 0)
- DRM_INFO("Display Core has been requested via kernel
parameter "
+ DRM_INFO_ONCE("Display Core has been requested via
kernel parameter "
"but isn't supported by ASIC,
ignoring\n");
return false;
}
Re: [PATCH v2 12/12] extcon: arizona: Drop the arizona extcon driver
On Sun, Jan 17, 2021 at 6:06 PM Hans de Goede wrote:
>
> The codec drivers for arizona codecs now take care of jack-detect
> handling themselves; and drivers/mfd/arizona-core.c no longer
> instantiates a "arizona-extcon" child-device for these.
>
> This means that the "arizona-extcon" driver is no longer needed
> (there are no longer any devices for it to bind to), so it can
> be dropped.
Reviewed-by: Andy Shevchenko
> Signed-off-by: Hans de Goede
> ---
> MAINTAINERS |1 -
> drivers/extcon/Kconfig |8 -
> drivers/extcon/Makefile |1 -
> drivers/extcon/extcon-arizona.c | 1816 ---
> 4 files changed, 1826 deletions(-)
> delete mode 100644 drivers/extcon/extcon-arizona.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 66b56928cc47..9ded82d53c18 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -19255,7 +19255,6 @@ F:
> Documentation/devicetree/bindings/sound/wlf,arizona.yaml
> F: Documentation/hwmon/wm83??.rst
> F: arch/arm/mach-s3c/mach-crag6410*
> F: drivers/clk/clk-wm83*.c
> -F: drivers/extcon/extcon-arizona.c
> F: drivers/gpio/gpio-*wm*.c
> F: drivers/gpio/gpio-arizona.c
> F: drivers/hwmon/wm83??-hwmon.c
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index af58ebca2bf6..e3db936becfd 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -21,14 +21,6 @@ config EXTCON_ADC_JACK
> help
> Say Y here to enable extcon device driver based on ADC values.
>
> -config EXTCON_ARIZONA
> - tristate "Wolfson Arizona EXTCON support"
> - depends on MFD_ARIZONA && INPUT && SND_SOC
> - help
> - Say Y here to enable support for external accessory detection
> - with Wolfson Arizona devices. These are audio CODECs with
> - advanced audio accessory detection support.
> -
> config EXTCON_AXP288
> tristate "X-Power AXP288 EXTCON support"
> depends on MFD_AXP20X && USB_SUPPORT && X86 && ACPI
> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> index fe10a1b7d18b..1b390d934ca9 100644
> --- a/drivers/extcon/Makefile
> +++ b/drivers/extcon/Makefile
> @@ -6,7 +6,6 @@
> obj-$(CONFIG_EXTCON) += extcon-core.o
> extcon-core-objs += extcon.o devres.o
> obj-$(CONFIG_EXTCON_ADC_JACK) += extcon-adc-jack.o
> -obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o
> obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o
> obj-$(CONFIG_EXTCON_FSA9480) += extcon-fsa9480.o
> obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> deleted file mode 100644
> index aae82db542a5..
> --- a/drivers/extcon/extcon-arizona.c
> +++ /dev/null
> @@ -1,1816 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0-or-later
> -/*
> - * extcon-arizona.c - Extcon driver Wolfson Arizona devices
> - *
> - * Copyright (C) 2012-2014 Wolfson Microelectronics plc
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#include
> -
> -#include
> -#include
> -#include
> -#include
> -
> -#define ARIZONA_MAX_MICD_RANGE 8
> -
> -#define ARIZONA_MICD_CLAMP_MODE_JDL 0x4
> -#define ARIZONA_MICD_CLAMP_MODE_JDH 0x5
> -#define ARIZONA_MICD_CLAMP_MODE_JDL_GP5H 0x9
> -#define ARIZONA_MICD_CLAMP_MODE_JDH_GP5H 0xb
> -
> -#define ARIZONA_TST_CAP_DEFAULT 0x3
> -#define ARIZONA_TST_CAP_CLAMP 0x1
> -
> -#define ARIZONA_HPDET_MAX 1
> -
> -#define HPDET_DEBOUNCE 500
> -#define DEFAULT_MICD_TIMEOUT 2000
> -
> -#define ARIZONA_HPDET_WAIT_COUNT 15
> -#define ARIZONA_HPDET_WAIT_DELAY_MS 20
> -
> -#define QUICK_HEADPHONE_MAX_OHM 3
> -#define MICROPHONE_MIN_OHM 1257
> -#define MICROPHONE_MAX_OHM 3
> -
> -#define MICD_DBTIME_TWO_READINGS 2
> -#define MICD_DBTIME_FOUR_READINGS 4
> -
> -#define MICD_LVL_1_TO_7 (ARIZONA_MICD_LVL_1 | ARIZONA_MICD_LVL_2 | \
> -ARIZONA_MICD_LVL_3 | ARIZONA_MICD_LVL_4 | \
> -ARIZONA_MICD_LVL_5 | ARIZONA_MICD_LVL_6 | \
> -ARIZONA_MICD_LVL_7)
> -
> -#define MICD_LVL_0_TO_7 (ARIZONA_MICD_LVL_0 | MICD_LVL_1_TO_7)
> -
> -#define MICD_LVL_0_TO_8 (MICD_LVL_0_TO_7 | ARIZONA_MICD_LVL_8)
> -
> -struct arizona_extcon_info {
> - struct device *dev;
> - struct arizona *arizona;
> - struct mutex lock;
> - struct regulator *micvdd;
> - struct input_dev *input;
> -
> - u16 last_jackdet;
> -
> - int micd_mode;
> - const struct arizona_micd_config *micd_modes;
> - int micd_num_modes;
> -
> - const struct arizona_micd_range *micd_ranges;
> - int num_micd_ranges;
> -
> - bool micd_reva;
> - bool micd_clamp;
> -
> - struct delayed_work hpdet_work;
> - struct delayed_work micd_detect_work;
> - struct
Re: [PATCH v3 2/5] mfd: arizona: Replace arizona_of_get_type() with device_get_match_data()
On Sun, Jan 17, 2021 at 11:23 PM Hans de Goede wrote:
>
> Replace the custom arizona_of_get_type() function with the generic
> device_get_match_data() helper. Besides being a nice cleanup this
> also makes it easier to add support for binding to ACPI enumerated
> devices.
>
> While at it also fix a possible NULL pointer deref of the id
> argument to the probe functions (this could happen on e.g. manual
> driver binding through sysfs).
Reviewed-by: Andy Shevchenko
> Suggested-by: Andy Shevchenko
> Signed-off-by: Hans de Goede
> ---
> Changes in v2:
> - New patch in v2 of this patchset
> ---
> drivers/mfd/arizona-core.c | 11 ---
> drivers/mfd/arizona-i2c.c | 10 ++
> drivers/mfd/arizona-spi.c | 10 ++
> drivers/mfd/arizona.h | 9 -
> 4 files changed, 12 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
> index 000cb82023e3..75f1bc671d59 100644
> --- a/drivers/mfd/arizona-core.c
> +++ b/drivers/mfd/arizona-core.c
> @@ -797,17 +797,6 @@ const struct dev_pm_ops arizona_pm_ops = {
> EXPORT_SYMBOL_GPL(arizona_pm_ops);
>
> #ifdef CONFIG_OF
> -unsigned long arizona_of_get_type(struct device *dev)
> -{
> - const struct of_device_id *id = of_match_device(arizona_of_match,
> dev);
> -
> - if (id)
> - return (unsigned long)id->data;
> - else
> - return 0;
> -}
> -EXPORT_SYMBOL_GPL(arizona_of_get_type);
> -
> static int arizona_of_get_core_pdata(struct arizona *arizona)
> {
> struct arizona_pdata *pdata = &arizona->pdata;
> diff --git a/drivers/mfd/arizona-i2c.c b/drivers/mfd/arizona-i2c.c
> index 2a4a3a164d0a..5e83b730c4ce 100644
> --- a/drivers/mfd/arizona-i2c.c
> +++ b/drivers/mfd/arizona-i2c.c
> @@ -23,14 +23,16 @@
> static int arizona_i2c_probe(struct i2c_client *i2c,
> const struct i2c_device_id *id)
> {
> + const void *match_data;
> struct arizona *arizona;
> const struct regmap_config *regmap_config = NULL;
> - unsigned long type;
> + unsigned long type = 0;
> int ret;
>
> - if (i2c->dev.of_node)
> - type = arizona_of_get_type(&i2c->dev);
> - else
> + match_data = device_get_match_data(&i2c->dev);
> + if (match_data)
> + type = (unsigned long)match_data;
> + else if (id)
> type = id->driver_data;
>
> switch (type) {
> diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c
> index 704f214d2614..798b88295c77 100644
> --- a/drivers/mfd/arizona-spi.c
> +++ b/drivers/mfd/arizona-spi.c
> @@ -23,14 +23,16 @@
> static int arizona_spi_probe(struct spi_device *spi)
> {
> const struct spi_device_id *id = spi_get_device_id(spi);
> + const void *match_data;
> struct arizona *arizona;
> const struct regmap_config *regmap_config = NULL;
> - unsigned long type;
> + unsigned long type = 0;
> int ret;
>
> - if (spi->dev.of_node)
> - type = arizona_of_get_type(&spi->dev);
> - else
> + match_data = device_get_match_data(&spi->dev);
> + if (match_data)
> + type = (unsigned long)match_data;
> + else if (id)
> type = id->driver_data;
>
> switch (type) {
> diff --git a/drivers/mfd/arizona.h b/drivers/mfd/arizona.h
> index 995efc6d7f32..801cbbcd71cb 100644
> --- a/drivers/mfd/arizona.h
> +++ b/drivers/mfd/arizona.h
> @@ -50,13 +50,4 @@ int arizona_dev_exit(struct arizona *arizona);
> int arizona_irq_init(struct arizona *arizona);
> int arizona_irq_exit(struct arizona *arizona);
>
> -#ifdef CONFIG_OF
> -unsigned long arizona_of_get_type(struct device *dev);
> -#else
> -static inline unsigned long arizona_of_get_type(struct device *dev)
> -{
> - return 0;
> -}
> -#endif
> -
> #endif
> --
> 2.28.0
>
--
With Best Regards,
Andy Shevchenko
[PATCH 5.4 68/76] mm, slub: consider rest of partial list if acquire_slab() fails
From: Jann Horn
commit 8ff60eb052eeba95cfb3efe16b08c9199f8121cf upstream.
acquire_slab() fails if there is contention on the freelist of the page
(probably because some other CPU is concurrently freeing an object from
the page). In that case, it might make sense to look for a different page
(since there might be more remote frees to the page from other CPUs, and
we don't want contention on struct page).
However, the current code accidentally stops looking at the partial list
completely in that case. Especially on kernels without CONFIG_NUMA set,
this means that get_partial() fails and new_slab_objects() falls back to
new_slab(), allocating new pages. This could lead to an unnecessary
increase in memory fragmentation.
Link: https://lkml.kernel.org/r/20201228130853.1871516-1-ja...@google.com
Fixes: 7ced37197196 ("slub: Acquire_slab() avoid loop")
Signed-off-by: Jann Horn
Acked-by: David Rientjes
Acked-by: Joonsoo Kim
Cc: Christoph Lameter
Cc: Pekka Enberg
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
mm/slub.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1887,7 +1887,7 @@ static void *get_partial_node(struct kme
t = acquire_slab(s, n, page, object == NULL, &objects);
if (!t)
- break;
+ continue; /* cmpxchg raced */
available += objects;
if (!object) {
Re: [PATCH] x86/perf: Use static_call for x86_pmu.guest_get_msrs
Hi Like,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tip/perf/core]
[also build test ERROR on v5.11-rc4 next-20210118]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Like-Xu/x86-perf-Use-static_call-for-x86_pmu-guest_get_msrs/20210118-153219
base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
9a7832ce3d920426a36cdd78eda4b3568d4d09e3
config: x86_64-randconfig-a002-20210118 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
95d146182fdf2315e74943b93fb3bb0cbafc5d89)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/0cd2262fad043a5edef91fca07d16759703658b8
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Like-Xu/x86-perf-Use-static_call-for-x86_pmu-guest_get_msrs/20210118-153219
git checkout 0cd2262fad043a5edef91fca07d16759703658b8
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> arch/x86/events/core.c:670:31: error: redefinition of 'perf_guest_get_msrs'
struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr)
^
arch/x86/include/asm/perf_event.h:486:45: note: previous definition is here
static inline struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr)
^
1 error generated.
vim +/perf_guest_get_msrs +670 arch/x86/events/core.c
669
> 670 struct perf_guest_switch_msr *perf_guest_get_msrs(int *nr)
671 {
672 struct perf_guest_switch_msr *ret = NULL;
673
674 ret = static_call(x86_pmu_guest_get_msrs)(nr);
675 if (!ret)
676 *nr = 0;
677
678 return ret;
679 }
680 EXPORT_SYMBOL_GPL(perf_guest_get_msrs);
681
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH 5.4 30/76] btrfs: fix transaction leak and crash after RO remount caused by qgroup rescan
From: Filipe Manana [ Upstream commit cb13eea3b49055bd78e6ddf39defd6340f7379fc ] If we remount a filesystem in RO mode while the qgroup rescan worker is running, we can end up having it still running after the remount is done, and at unmount time we may end up with an open transaction that ends up never getting committed. If that happens we end up with several memory leaks and can crash when hardware acceleration is unavailable for crc32c. Possibly it can lead to other nasty surprises too, due to use-after-free issues. The following steps explain how the problem happens. 1) We have a filesystem mounted in RW mode and the qgroup rescan worker is running; 2) We remount the filesystem in RO mode, and never stop/pause the rescan worker, so after the remount the rescan worker is still running. The important detail here is that the rescan task is still running after the remount operation committed any ongoing transaction through its call to btrfs_commit_super(); 3) The rescan is still running, and after the remount completed, the rescan worker started a transaction, after it finished iterating all leaves of the extent tree, to update the qgroup status item in the quotas tree. It does not commit the transaction, it only releases its handle on the transaction; 4) A filesystem unmount operation starts shortly after; 5) The unmount task, at close_ctree(), stops the transaction kthread, which had not had a chance to commit the open transaction since it was sleeping and the commit interval (default of 30 seconds) has not yet elapsed since the last time it committed a transaction; 6) So after stopping the transaction kthread we still have the transaction used to update the qgroup status item open. At close_ctree(), when the filesystem is in RO mode and no transaction abort happened (or the filesystem is in error mode), we do not expect to have any transaction open, so we do not call btrfs_commit_super(); 7) We then proceed to destroy the work queues, free the roots and block groups, etc. After that we drop the last reference on the btree inode by calling iput() on it. Since there are dirty pages for the btree inode, corresponding to the COWed extent buffer for the quotas btree, btree_write_cache_pages() is invoked to flush those dirty pages. This results in creating a bio and submitting it, which makes us end up at btrfs_submit_metadata_bio(); 8) At btrfs_submit_metadata_bio() we end up at the if-then-else branch that calls btrfs_wq_submit_bio(), because check_async_write() returned a value of 1. This value of 1 is because we did not have hardware acceleration available for crc32c, so BTRFS_FS_CSUM_IMPL_FAST was not set in fs_info->flags; 9) Then at btrfs_wq_submit_bio() we call btrfs_queue_work() against the workqueue at fs_info->workers, which was already freed before by the call to btrfs_stop_all_workers() at close_ctree(). This results in an invalid memory access due to a use-after-free, leading to a crash. When this happens, before the crash there are several warnings triggered, since we have reserved metadata space in a block group, the delayed refs reservation, etc: [ cut here ] WARNING: CPU: 4 PID: 1729896 at fs/btrfs/block-group.c:125 btrfs_put_block_group+0x63/0xa0 [btrfs] Modules linked in: btrfs dm_snapshot dm_thin_pool (...) CPU: 4 PID: 1729896 Comm: umount Tainted: GB W 5.10.0-rc4-btrfs-next-73 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:btrfs_put_block_group+0x63/0xa0 [btrfs] Code: f0 01 00 00 48 39 c2 75 (...) RSP: 0018:b270826bbdd8 EFLAGS: 00010206 RAX: 0001 RBX: 947ed73e4000 RCX: 947ebc8b29c8 RDX: 0001 RSI: c0b150a0 RDI: 947ebc8b2800 RBP: 947ebc8b2800 R08: R09: R10: R11: 0001 R12: 947ed73e4110 R13: 947ed73e4160 R14: 947ebc8b2988 R15: dead0100 FS: 7f15edfea840() GS:9481ad60() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f37e2893320 CR3: 000138f68001 CR4: 003706e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: btrfs_free_block_groups+0x17f/0x2f0 [btrfs] close_ctree+0x2ba/0x2fa [btrfs] generic_shutdown_super+0x6c/0x100 kill_anon_super+0x14/0x30 btrfs_kill_super+0x12/0x20 [btrfs] deactivate_locked_super+0x31/0x70 cleanup_mnt+0x100/0x160 task_work_run+0x68/0xb0 exit_to_user_mode_prepare+0x1bb/0x1c0 syscall_exit_to_user_mode+0x4b/0x260 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f15ee221ee7 Code: ff 0b 00 f7 d8 64 89 01 48 (...) RSP: 002b:7ffe9470f0f8 EFLAGS: 0246 ORIG_RAX: 00a6
[PATCH 5.4 55/76] NFS4: Fix use-after-free in trace_event_raw_event_nfs4_set_lock
From: Dave Wysochanski
commit 3d1a90ab0ed93362ec8ac85cf291243c87260c21 upstream.
It is only safe to call the tracepoint before rpc_put_task() because
'data' is freed inside nfs4_lock_release (rpc_release).
Fixes: 48c9579a1afe ("Adding stateid information to tracepoints")
Signed-off-by: Dave Wysochanski
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman
---
fs/nfs/nfs4proc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -6959,9 +6959,9 @@ static int _nfs4_do_setlk(struct nfs4_st
data->arg.new_lock_owner, ret);
} else
data->cancelled = true;
+ trace_nfs4_set_lock(fl, state, &data->res.stateid, cmd, ret);
rpc_put_task(task);
dprintk("%s: done, ret = %d!\n", __func__, ret);
- trace_nfs4_set_lock(fl, state, &data->res.stateid, cmd, ret);
return ret;
}
[tip: x86/misc] selftests/fpu: Fix debugfs_simple_attr.cocci warning
The following commit has been merged into the x86/misc branch of tip:
Commit-ID: 443121b3ebb9025fd99ff11851d3537cb756d456
Gitweb:
https://git.kernel.org/tip/443121b3ebb9025fd99ff11851d3537cb756d456
Author:kernel test robot
AuthorDate:Sun, 25 Oct 2020 11:20:04 +01:00
Committer: Borislav Petkov
CommitterDate: Mon, 18 Jan 2021 11:03:26 +01:00
selftests/fpu: Fix debugfs_simple_attr.cocci warning
lib/test_fpu.c:66:0-23: WARNING: test_fpu_fops should be defined with
DEFINE_DEBUGFS_ATTRIBUTE
Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE
for debugfs files.
Semantic patch information:
Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file()
imposes some significant overhead as compared to
DEFINE_DEBUGFS_ATTRIBUTE + debugfs_create_file_unsafe().
In order to protect against file removal races, debugfs files created
via debugfs_create_file() now get wrapped by a struct file_operations
at their opening.
If the original struct file_operations are known to be safe against
removal races by themselves already, the proxy creation may be bypassed
by creating the files through debugfs_create_file_unsafe().
In order to help debugfs users who use the common
DEFINE_SIMPLE_ATTRIBUTE() + debugfs_create_file() idiom to
transition to removal safe struct file_operations, the helper macro
DEFINE_DEBUGFS_ATTRIBUTE() has been introduced.
Thus, the preferred strategy is to use
DEFINE_DEBUGFS_ATTRIBUTE() + debugfs_create_file_unsafe()
now.
Generated by: scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
Fixes: 4185b3b92792 ("selftests/fpu: Add an FPU selftest")
Signed-off-by: kernel test robot
Signed-off-by: Julia Lawall
Signed-off-by: Borislav Petkov
Link: https://lkml.kernel.org/r/alpine.DEB.2.22.394.2010251117180.2714@hadrien
---
lib/test_fpu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/test_fpu.c b/lib/test_fpu.c
index c33764a..e82db19 100644
--- a/lib/test_fpu.c
+++ b/lib/test_fpu.c
@@ -63,7 +63,7 @@ static int test_fpu_get(void *data, u64 *val)
return status;
}
-DEFINE_SIMPLE_ATTRIBUTE(test_fpu_fops, test_fpu_get, NULL, "%lld\n");
+DEFINE_DEBUGFS_ATTRIBUTE(test_fpu_fops, test_fpu_get, NULL, "%lld\n");
static struct dentry *selftest_dir;
static int __init test_fpu_init(void)
@@ -72,8 +72,8 @@ static int __init test_fpu_init(void)
if (!selftest_dir)
return -ENOMEM;
- debugfs_create_file("test_fpu", 0444, selftest_dir, NULL,
- &test_fpu_fops);
+ debugfs_create_file_unsafe("test_fpu", 0444, selftest_dir, NULL,
+ &test_fpu_fops);
return 0;
}
Re: [PATCH 3/4] x86/fpu: Make the EFI FPU calling convention explicit
On Sun, Jan 17, 2021 at 10:20:40PM -0800, Andy Lutomirski wrote: > EFI uses kernel_fpu_begin() to conform to the UEFI calling convention. > This specifically requires initializing FCW, whereas no sane 64-bit kernel > code should use legacy 387 operations that reference FCW. > > Add KFPU_EFI to make this self-documenting, and use it in the EFI code. I'd prefer if you slap a comment over the kernel_fpu_begin() calls in efi instead of adding a separate define etc. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
[PATCH 5.4 32/76] ethernet: ucc_geth: fix definition and size of ucc_geth_tx_global_pram
From: Rasmus Villemoes
[ Upstream commit 887078de2a23689e29d6fa1b75d7cbc544c280be ]
Table 8-53 in the QUICC Engine Reference manual shows definitions of
fields up to a size of 192 bytes, not just 128. But in table 8-111,
one does find the text
Base Address of the Global Transmitter Parameter RAM Page. [...]
The user needs to allocate 128 bytes for this page. The address must
be aligned to the page size.
I've checked both rev. 7 (11/2015) and rev. 9 (05/2018) of the manual;
they both have this inconsistency (and the table numbers are the
same).
Adding a bit of debug printing, on my board the struct
ucc_geth_tx_global_pram is allocated at offset 0x880, while
the (opaque) ucc_geth_thread_data_tx gets allocated immediately
afterwards, at 0x900. So whatever the engine writes into the thread
data overlaps with the tail of the global tx pram (and devmem says
that something does get written during a simple ping).
I haven't observed any failure that could be attributed to this, but
it seems to be the kind of thing that would be extremely hard to
debug. So extend the struct definition so that we do allocate 192
bytes.
Signed-off-by: Rasmus Villemoes
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/freescale/ucc_geth.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.h
b/drivers/net/ethernet/freescale/ucc_geth.h
index a86a42131fc71..b00fbef612cfe 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.h
+++ b/drivers/net/ethernet/freescale/ucc_geth.h
@@ -576,7 +576,14 @@ struct ucc_geth_tx_global_pram {
u32 vtagtable[0x8]; /* 8 4-byte VLAN tags */
u32 tqptr; /* a base pointer to the Tx Queues Memory
Region */
- u8 res2[0x80 - 0x74];
+ u8 res2[0x78 - 0x74];
+ u64 snums_en;
+ u32 l2l3baseptr;/* top byte consists of a few other bit fields
*/
+
+ u16 mtu[8];
+ u8 res3[0xa8 - 0x94];
+ u32 wrrtablebase; /* top byte is reserved */
+ u8 res4[0xc0 - 0xac];
} __packed;
/* structure representing Extended Filtering Global Parameters in PRAM */
--
2.27.0
[PATCH 5.10 136/152] RDMA/mlx5: Fix wrong free of blue flame register on error
From: Mark Bloch
commit 1c3aa6bd0b823105c2030af85d92d158e815d669 upstream.
If the allocation of the fast path blue flame register fails, the driver
should free the regular blue flame register allocated a statement above,
not the one that it just failed to allocate.
Fixes: 16c1975f1032 ("IB/mlx5: Create profile infrastructure to add and remove
stages")
Link: https://lore.kernel.org/r/20210113121703.559778-6-l...@kernel.org
Reported-by: Hans Petter Selasky
Signed-off-by: Mark Bloch
Signed-off-by: Leon Romanovsky
Signed-off-by: Jason Gunthorpe
Signed-off-by: Greg Kroah-Hartman
---
drivers/infiniband/hw/mlx5/main.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -4362,7 +4362,7 @@ static int mlx5_ib_stage_bfrag_init(stru
err = mlx5_alloc_bfreg(dev->mdev, &dev->fp_bfreg, false, true);
if (err)
- mlx5_free_bfreg(dev->mdev, &dev->fp_bfreg);
+ mlx5_free_bfreg(dev->mdev, &dev->bfreg);
return err;
}
[PATCH 5.10 148/152] dm: eliminate potential source of excessive kernel log noise
From: Mike Snitzer
commit 0378c625afe80eb3f212adae42cc33c9f6f31abf upstream.
There wasn't ever a real need to log an error in the kernel log for
ioctls issued with insufficient permissions. Simply return an error
and if an admin/user is sufficiently motivated they can enable DM's
dynamic debugging to see an explanation for why the ioctls were
disallowed.
Reported-by: Nir Soffer
Fixes: e980f62353c6 ("dm: don't allow ioctls to targets that don't map to whole
devices")
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman
---
drivers/md/dm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -562,7 +562,7 @@ static int dm_blk_ioctl(struct block_dev
* subset of the parent bdev; require extra privileges.
*/
if (!capable(CAP_SYS_RAWIO)) {
- DMWARN_LIMIT(
+ DMDEBUG_LIMIT(
"%s: sending ioctl %x to DM device without required privilege.",
current->comm, cmd);
r = -ENOIOCTLCMD;
[PATCH 5.10 147/152] selftests: netfilter: Pass family parameter "-f" to conntrack tool
From: Chen Yi
commit fab336b42441e0b2eb1d81becedb45fbdf99606e upstream.
Fix nft_conntrack_helper.sh false fail report:
1) Conntrack tool need "-f ipv6" parameter to show out ipv6 traffic items.
2) Sleep 1 second after background nc send packet, to make sure check
is after this statement executed.
False report:
FAIL: ns1-lkjUemYw did not show attached helper ip set via ruleset
PASS: ns1-lkjUemYw connection on port 2121 has ftp helper attached
...
After fix:
PASS: ns1-2hUniwU2 connection on port 2121 has ftp helper attached
PASS: ns2-2hUniwU2 connection on port 2121 has ftp helper attached
...
Fixes: 619ae8e0697a6 ("selftests: netfilter: add test case for conntrack helper
assignment")
Signed-off-by: Chen Yi
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Greg Kroah-Hartman
---
tools/testing/selftests/netfilter/nft_conntrack_helper.sh | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
--- a/tools/testing/selftests/netfilter/nft_conntrack_helper.sh
+++ b/tools/testing/selftests/netfilter/nft_conntrack_helper.sh
@@ -94,7 +94,13 @@ check_for_helper()
local message=$2
local port=$3
- ip netns exec ${netns} conntrack -L -p tcp --dport $port 2> /dev/null
|grep -q 'helper=ftp'
+ if echo $message |grep -q 'ipv6';then
+ local family="ipv6"
+ else
+ local family="ipv4"
+ fi
+
+ ip netns exec ${netns} conntrack -L -f $family -p tcp --dport $port 2>
/dev/null |grep -q 'helper=ftp'
if [ $? -ne 0 ] ; then
echo "FAIL: ${netns} did not show attached helper $message" 1>&2
ret=1
@@ -111,8 +117,8 @@ test_helper()
sleep 3 | ip netns exec ${ns2} nc -w 2 -l -p $port > /dev/null &
- sleep 1
sleep 1 | ip netns exec ${ns1} nc -w 2 10.0.1.2 $port > /dev/null &
+ sleep 1
check_for_helper "$ns1" "ip $msg" $port
check_for_helper "$ns2" "ip $msg" $port
@@ -128,8 +134,8 @@ test_helper()
sleep 3 | ip netns exec ${ns2} nc -w 2 -6 -l -p $port > /dev/null &
- sleep 1
sleep 1 | ip netns exec ${ns1} nc -w 2 -6 dead:1::2 $port > /dev/null &
+ sleep 1
check_for_helper "$ns1" "ipv6 $msg" $port
check_for_helper "$ns2" "ipv6 $msg" $port
[PATCH 5.10 149/152] ALSA: fireface: Fix integer overflow in transmit_midi_msg()
From: Geert Uytterhoeven
commit e7c22eeaff8565d9a8374f320238c251ca31480b upstream.
As snd_ff.rx_bytes[] is unsigned int, and NSEC_PER_SEC is 10L,
the second multiplication in
ff->rx_bytes[port] * 8 * NSEC_PER_SEC / 31250
always overflows on 32-bit platforms, truncating the result. Fix this
by precalculating "NSEC_PER_SEC / 31250", which is an integer constant.
Note that this assumes ff->rx_bytes[port] <= 16777.
Fixes: 19174295788de77d ("ALSA: fireface: add transaction support")
Reviewed-by: Takashi Sakamoto
Signed-off-by: Geert Uytterhoeven
Link: https://lore.kernel.org/r/2021030251.361335-2-geert+rene...@glider.be
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
---
sound/firewire/fireface/ff-transaction.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/sound/firewire/fireface/ff-transaction.c
+++ b/sound/firewire/fireface/ff-transaction.c
@@ -88,7 +88,7 @@ static void transmit_midi_msg(struct snd
/* Set interval to next transaction. */
ff->next_ktime[port] = ktime_add_ns(ktime_get(),
- ff->rx_bytes[port] * 8 * NSEC_PER_SEC / 31250);
+ ff->rx_bytes[port] * 8 * (NSEC_PER_SEC / 31250));
if (quad_count == 1)
tcode = TCODE_WRITE_QUADLET_REQUEST;
[PATCH 5.10 146/152] net: sunrpc: interpret the return value of kstrtou32 correctly
From: j.nixd...@avm.de
commit 86b53fbf08f48d353a86a06aef537e78e82ba721 upstream.
A return value of 0 means success. This is documented in lib/kstrtox.c.
This was found by trying to mount an NFS share from a link-local IPv6
address with the interface specified by its index:
mount("[fe80::1%1]:/srv/nfs", "/mnt", "nfs", 0, "nolock,addr=fe80::1%1")
Before this commit this failed with EINVAL and also caused the following
message in dmesg:
[...] NFS: bad IP address specified: addr=fe80::1%1
The syscall using the same address based on the interface name instead
of its index succeeds.
Credits for this patch go to my colleague Christian Speich, who traced
the origin of this bug to this line of code.
Signed-off-by: Johannes Nixdorf
Fixes: 00cfaa943ec3 ("replace strict_strto calls")
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman
---
net/sunrpc/addr.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/sunrpc/addr.c
+++ b/net/sunrpc/addr.c
@@ -185,7 +185,7 @@ static int rpc_parse_scope_id(struct net
scope_id = dev->ifindex;
dev_put(dev);
} else {
- if (kstrtou32(p, 10, &scope_id) == 0) {
+ if (kstrtou32(p, 10, &scope_id) != 0) {
kfree(p);
return 0;
}
[PATCH 5.10 109/152] mm: fix clear_refs_write locking
From: Linus Torvalds
[ Upstream commit 29a951dfb3c3263c3a0f3bd9f7f2c2cfde4baedb ]
Turning page table entries read-only requires the mmap_sem held for
writing.
So stop doing the odd games with turning things from read locks to write
locks and back. Just get the write lock.
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
fs/proc/task_mmu.c | 32 +---
1 file changed, 9 insertions(+), 23 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index ee5a235b30562..ab7d700b2caa4 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1215,41 +1215,26 @@ static ssize_t clear_refs_write(struct file *file,
const char __user *buf,
.type = type,
};
+ if (mmap_write_lock_killable(mm)) {
+ count = -EINTR;
+ goto out_mm;
+ }
if (type == CLEAR_REFS_MM_HIWATER_RSS) {
- if (mmap_write_lock_killable(mm)) {
- count = -EINTR;
- goto out_mm;
- }
-
/*
* Writing 5 to /proc/pid/clear_refs resets the peak
* resident set size to this mm's current rss value.
*/
reset_mm_hiwater_rss(mm);
- mmap_write_unlock(mm);
- goto out_mm;
+ goto out_unlock;
}
- if (mmap_read_lock_killable(mm)) {
- count = -EINTR;
- goto out_mm;
- }
tlb_gather_mmu(&tlb, mm, 0, -1);
if (type == CLEAR_REFS_SOFT_DIRTY) {
for (vma = mm->mmap; vma; vma = vma->vm_next) {
if (!(vma->vm_flags & VM_SOFTDIRTY))
continue;
- mmap_read_unlock(mm);
- if (mmap_write_lock_killable(mm)) {
- count = -EINTR;
- goto out_mm;
- }
- for (vma = mm->mmap; vma; vma = vma->vm_next) {
- vma->vm_flags &= ~VM_SOFTDIRTY;
- vma_set_page_prot(vma);
- }
- mmap_write_downgrade(mm);
- break;
+ vma->vm_flags &= ~VM_SOFTDIRTY;
+ vma_set_page_prot(vma);
}
mmu_notifier_range_init(&range, MMU_NOTIFY_SOFT_DIRTY,
@@ -1261,7 +1246,8 @@ static ssize_t clear_refs_write(struct file *file, const
char __user *buf,
if (type == CLEAR_REFS_SOFT_DIRTY)
mmu_notifier_invalidate_range_end(&range);
tlb_finish_mmu(&tlb, 0, -1);
- mmap_read_unlock(mm);
+out_unlock:
+ mmap_write_unlock(mm);
out_mm:
mmput(mm);
}
--
2.27.0
[PATCH 5.10 145/152] iommu/vt-d: Fix unaligned addresses for intel_flush_svm_range_dev()
From: Lu Baolu
commit 2d6ffc63f12417b979955a5b22ad9a76d2af5de9 upstream.
The VT-d hardware will ignore those Addr bits which have been masked by
the AM field in the PASID-based-IOTLB invalidation descriptor. As the
result, if the starting address in the descriptor is not aligned with
the address mask, some IOTLB caches might not invalidate. Hence people
will see below errors.
[ 1093.704661] dmar_fault: 29 callbacks suppressed
[ 1093.704664] DMAR: DRHD: handling fault status reg 3
[ 1093.712738] DMAR: [DMA Read] Request device [7a:02.0] PASID 2
fault addr 7f81c968d000 [fault reason 113]
SM: Present bit in first-level paging entry is clear
Fix this by using aligned address for PASID-based-IOTLB invalidation.
Fixes: 1c4f88b7f1f9 ("iommu/vt-d: Shared virtual address in scalable mode")
Reported-and-tested-by: Guo Kaijie
Signed-off-by: Lu Baolu
Link:
https://lore.kernel.org/r/20201231005323.2178523-2-baolu...@linux.intel.com
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman
---
drivers/iommu/intel/svm.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -118,8 +118,10 @@ void intel_svm_check(struct intel_iommu
iommu->flags |= VTD_FLAG_SVM_CAPABLE;
}
-static void intel_flush_svm_range_dev (struct intel_svm *svm, struct
intel_svm_dev *sdev,
- unsigned long address, unsigned long pages, int
ih)
+static void __flush_svm_range_dev(struct intel_svm *svm,
+ struct intel_svm_dev *sdev,
+ unsigned long address,
+ unsigned long pages, int ih)
{
struct qi_desc desc;
@@ -170,6 +172,22 @@ static void intel_flush_svm_range_dev (s
}
}
+static void intel_flush_svm_range_dev(struct intel_svm *svm,
+ struct intel_svm_dev *sdev,
+ unsigned long address,
+ unsigned long pages, int ih)
+{
+ unsigned long shift = ilog2(__roundup_pow_of_two(pages));
+ unsigned long align = (1ULL << (VTD_PAGE_SHIFT + shift));
+ unsigned long start = ALIGN_DOWN(address, align);
+ unsigned long end = ALIGN(address + (pages << VTD_PAGE_SHIFT), align);
+
+ while (start < end) {
+ __flush_svm_range_dev(svm, sdev, start, align >>
VTD_PAGE_SHIFT, ih);
+ start += align;
+ }
+}
+
static void intel_flush_svm_range(struct intel_svm *svm, unsigned long address,
unsigned long pages, int ih)
{
[PATCH 5.10 100/152] bpf: Save correct stopping point in file seq iteration
From: Jonathan Lemon
[ Upstream commit 69ca310f34168eae0ada434796bfc22fb4a0fa26 ]
On some systems, some variant of the following splat is
repeatedly seen. The common factor in all traces seems
to be the entry point to task_file_seq_next(). With the
patch, all warnings go away.
rcu: INFO: rcu_sched self-detected stall on CPU
rcu: \x0926-: (20992 ticks this GP) idle=d7e/1/0x4002
softirq=81556231/81556231 fqs=4876
\x09(t=21033 jiffies g=159148529 q=223125)
NMI backtrace for cpu 26
CPU: 26 PID: 2015853 Comm: bpftool Kdump: loaded Not tainted
5.6.13-0_fbk4_3876_gd8d1f9bf80bb #1
Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A12
10/08/2018
Call Trace:
dump_stack+0x50/0x70
nmi_cpu_backtrace.cold.6+0x13/0x50
? lapic_can_unplug_cpu.cold.30+0x40/0x40
nmi_trigger_cpumask_backtrace+0xba/0xca
rcu_dump_cpu_stacks+0x99/0xc7
rcu_sched_clock_irq.cold.90+0x1b4/0x3aa
? tick_sched_do_timer+0x60/0x60
update_process_times+0x24/0x50
tick_sched_timer+0x37/0x70
__hrtimer_run_queues+0xfe/0x270
hrtimer_interrupt+0xf4/0x210
smp_apic_timer_interrupt+0x5e/0x120
apic_timer_interrupt+0xf/0x20
RIP: 0010:get_pid_task+0x38/0x80
Code: 89 f6 48 8d 44 f7 08 48 8b 00 48 85 c0 74 2b 48 83 c6 55 48 c1 e6 04
48 29 f0 74 19 48 8d 78 20 ba 01 00 00 00 f0 0f c1 50 20 <85> d2 74 27 78 11 83
c2 01 78 0c 48 83 c4 08 c3 31 c0 48 83 c4 08
RSP: 0018:c9000d293dc8 EFLAGS: 0202 ORIG_RAX: ff13
RAX: 888637c05600 RBX: c9000d293e0c RCX:
RDX: 0001 RSI: 0550 RDI: 888637c05620
RBP: 8284eb80 R08: 88831341d300 R09: 88822ffd8248
R10: 88822ffd82d0 R11: 003a93c0 R12: 0001
R13: R14: 88831341d300 R15:
? find_ge_pid+0x1b/0x20
task_seq_get_next+0x52/0xc0
task_file_seq_get_next+0x159/0x220
task_file_seq_next+0x4f/0xa0
bpf_seq_read+0x159/0x390
vfs_read+0x8a/0x140
ksys_read+0x59/0xd0
do_syscall_64+0x42/0x110
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f95ae73e76e
Code: Bad RIP value.
RSP: 002b:7ffc02c1dbf8 EFLAGS: 0246 ORIG_RAX:
RAX: ffda RBX: 0170faa0 RCX: 7f95ae73e76e
RDX: 1000 RSI: 7ffc02c1dc30 RDI: 0007
RBP: 7ffc02c1ec70 R08: 0005 R09: 0006
R10: f20b R11: 0246 R12: 019112a0
R13: R14: 0007 R15: 004283c0
If unable to obtain the file structure for the current task,
proceed to the next task number after the one returned from
task_seq_get_next(), instead of the next task number from the
original iterator.
Also, save the stopping task number from task_seq_get_next()
on failure in case of restarts.
Fixes: eaaacd23910f ("bpf: Add task and task/file iterator targets")
Signed-off-by: Jonathan Lemon
Signed-off-by: Daniel Borkmann
Acked-by: Andrii Nakryiko
Link:
https://lore.kernel.org/bpf/20201218185032.2464558-2-jonathan.le...@gmail.com
Signed-off-by: Sasha Levin
---
kernel/bpf/task_iter.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/bpf/task_iter.c b/kernel/bpf/task_iter.c
index 767c93d38bf55..f3d3a562a802a 100644
--- a/kernel/bpf/task_iter.c
+++ b/kernel/bpf/task_iter.c
@@ -158,13 +158,14 @@ task_file_seq_get_next(struct bpf_iter_seq_task_file_info
*info)
if (!curr_task) {
info->task = NULL;
info->files = NULL;
+ info->tid = curr_tid;
return NULL;
}
curr_files = get_files_struct(curr_task);
if (!curr_files) {
put_task_struct(curr_task);
- curr_tid = ++(info->tid);
+ curr_tid = curr_tid + 1;
info->fd = 0;
goto again;
}
--
2.27.0
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 16th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
[PATCH 5.10 144/152] riscv: Trace irq on only interrupt is enabled
From: Atish Patra
commit 7cd1af107a92eb63b93a96dc07406dcbc5269436 upstream.
We should call irq trace only if interrupt is going to be enabled during
excecption handling. Otherwise, it results in following warning during
boot with lock debugging enabled.
[0.00] [ cut here ]
[0.00] DEBUG_LOCKS_WARN_ON(early_boot_irqs_disabled)
[0.00] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:4085
lockdep_hardirqs_on_prepare+0x22a/0x22e
[0.00] Modules linked in:
[0.00] CPU: 0 PID: 0 Comm: swapper Not tainted
5.10.0-00022-ge20097fb37e2-dirty #548
[0.00] epc: c005d5d4 ra : c005d5d4 sp : c1c01e80
[0.00] gp : c1d456e0 tp : c1c0a980 t0 :
[0.00] t1 : t2 : s0 : c1c01ea0
[0.00] s1 : c100f360 a0 : 002d a1 : c00666ee
[0.00] a2 : a3 : a4 :
[0.00] a5 : a6 : c1c6b390 a7 : 300e
[0.00] s2 : c2384fe8 s3 : s4 : 0001
[0.00] s5 : c1c0a980 s6 : c1d48000 s7 : c1613b4c
[0.00] s8 : 0fff s9 : 8200 s10: c1613b40
[0.00] s11: t3 : t4 :
[0.00] t5 : 0001 t6 :
Fixes: 3c4697982982 ("riscv:Enable LOCKDEP_SUPPORT & fixup
TRACE_IRQFLAGS_SUPPORT")
Signed-off-by: Atish Patra
Signed-off-by: Palmer Dabbelt
Signed-off-by: Greg Kroah-Hartman
---
arch/riscv/kernel/entry.S |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/arch/riscv/kernel/entry.S
+++ b/arch/riscv/kernel/entry.S
@@ -124,15 +124,15 @@ skip_context_tracking:
REG_L a1, (a1)
jr a1
1:
-#ifdef CONFIG_TRACE_IRQFLAGS
- call trace_hardirqs_on
-#endif
/*
* Exceptions run with interrupts enabled or disabled depending on the
* state of SR_PIE in m/sstatus.
*/
andi t0, s1, SR_PIE
beqz t0, 1f
+#ifdef CONFIG_TRACE_IRQFLAGS
+ call trace_hardirqs_on
+#endif
csrs CSR_STATUS, SR_IE
1:
[PATCH 5.10 134/152] RDMA/usnic: Fix memleak in find_free_vf_and_create_qp_grp
From: Dinghao Liu
commit a306aba9c8d869b1fdfc8ad9237f1ed718ea55e6 upstream.
If usnic_ib_qp_grp_create() fails at the first call, dev_list
will not be freed on error, which leads to memleak.
Fixes: e3cf00d0a87f ("IB/usnic: Add Cisco VIC low-level hardware driver")
Link: https://lore.kernel.org/r/20201226074248.2893-1-dinghao@zju.edu.cn
Signed-off-by: Dinghao Liu
Reviewed-by: Leon Romanovsky
Signed-off-by: Jason Gunthorpe
Signed-off-by: Greg Kroah-Hartman
---
drivers/infiniband/hw/usnic/usnic_ib_verbs.c |3 +++
1 file changed, 3 insertions(+)
--- a/drivers/infiniband/hw/usnic/usnic_ib_verbs.c
+++ b/drivers/infiniband/hw/usnic/usnic_ib_verbs.c
@@ -214,6 +214,7 @@ find_free_vf_and_create_qp_grp(struct us
}
usnic_uiom_free_dev_list(dev_list);
+ dev_list = NULL;
}
/* Try to find resources on an unused vf */
@@ -239,6 +240,8 @@ find_free_vf_and_create_qp_grp(struct us
qp_grp_check:
if (IS_ERR_OR_NULL(qp_grp)) {
usnic_err("Failed to allocate qp_grp\n");
+ if (usnic_ib_share_vf)
+ usnic_uiom_free_dev_list(dev_list);
return ERR_PTR(qp_grp ? PTR_ERR(qp_grp) : -ENOMEM);
}
return qp_grp;
[PATCH 5.10 143/152] mm, slub: consider rest of partial list if acquire_slab() fails
From: Jann Horn
commit 8ff60eb052eeba95cfb3efe16b08c9199f8121cf upstream.
acquire_slab() fails if there is contention on the freelist of the page
(probably because some other CPU is concurrently freeing an object from
the page). In that case, it might make sense to look for a different page
(since there might be more remote frees to the page from other CPUs, and
we don't want contention on struct page).
However, the current code accidentally stops looking at the partial list
completely in that case. Especially on kernels without CONFIG_NUMA set,
this means that get_partial() fails and new_slab_objects() falls back to
new_slab(), allocating new pages. This could lead to an unnecessary
increase in memory fragmentation.
Link: https://lkml.kernel.org/r/20201228130853.1871516-1-ja...@google.com
Fixes: 7ced37197196 ("slub: Acquire_slab() avoid loop")
Signed-off-by: Jann Horn
Acked-by: David Rientjes
Acked-by: Joonsoo Kim
Cc: Christoph Lameter
Cc: Pekka Enberg
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
mm/slub.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1971,7 +1971,7 @@ static void *get_partial_node(struct kme
t = acquire_slab(s, n, page, object == NULL, &objects);
if (!t)
- break;
+ continue; /* cmpxchg raced */
available += objects;
if (!object) {
Re: [PATCH net v2] udp: ipv4: manipulate network header of NATed UDP GRO fraglist
> From: Steffen Klassert > Date: Mon, 18 Jan 2021 07:37:59 +0100 > > On Fri, Jan 15, 2021 at 05:12:33PM +, Alexander Lobakin wrote: >> From: Dongseok Yi >> Date: Fri, 15 Jan 2021 22:20:35 +0900 >> >>> UDP/IP header of UDP GROed frag_skbs are not updated even after NAT >>> forwarding. Only the header of head_skb from ip_finish_output_gso -> >>> skb_gso_segment is updated but following frag_skbs are not updated. >>> >>> A call path skb_mac_gso_segment -> inet_gso_segment -> >>> udp4_ufo_fragment -> __udp_gso_segment -> __udp_gso_segment_list >>> does not try to update UDP/IP header of the segment list but copy >>> only the MAC header. >>> >>> Update dport, daddr and checksums of each skb of the segment list >>> in __udp_gso_segment_list. It covers both SNAT and DNAT. >>> >>> Fixes: 9fd1ff5d2ac7 (udp: Support UDP fraglist GRO/GSO.) >>> Signed-off-by: Dongseok Yi >>> --- >>> v1: >>> Steffen Klassert said, there could be 2 options. >>> https://lore.kernel.org/patchwork/patch/1362257/ >>> I was trying to write a quick fix, but it was not easy to forward >>> segmented list. Currently, assuming DNAT only. >>> >>> v2: >>> Per Steffen Klassert request, move the procedure from >>> udp4_ufo_fragment to __udp_gso_segment_list and support SNAT. >>> >>> To Alexander Lobakin, I've checked your email late. Just use this >>> patch as a reference. It support SNAT too, but does not support IPv6 >>> yet. I cannot make IPv6 header changes in __udp_gso_segment_list due >>> to the file is in IPv4 directory. >> >> I used another approach, tried to make fraglist GRO closer to plain >> in terms of checksummming, as it is confusing to me why GSO packet >> should have CHECKSUM_UNNECESSARY. > > This is intentional. With fraglist GRO, we don't mangle packets > in the standard (non NAT) case. So the checksum is still correct > after segmentation. That is one reason why it has good forwarding > performance when software segmentation is needed. Checksuming > touches the whole packet and has a lot of overhead, so it is > heplfull to avoid it whenever possible. > > We should find a way to do the checksum only when we really > need it. I.e. only if the headers of the head skb changed. I suggest to do memcmp() between skb_network_header(skb) and skb_network_header(skb->frag_list) with the len of skb->data - skb_network_header(skb). This way we will detect changes in IPv4/IPv6 and UDP headers. If so, copy the full headers and fall back to the standard checksum, recalculation, else use the current path. Al
Re: [PATCH v2 bpf-next 2/2] selftests: bpf: Add a new test for bare tracepoints
On 01/16/21 18:11, Yonghong Song wrote:
>
>
> On 1/16/21 10:21 AM, Qais Yousef wrote:
> > Reuse module_attach infrastructure to add a new bare tracepoint to check
> > we can attach to it as a raw tracepoint.
> >
> > Signed-off-by: Qais Yousef
> > ---
> > .../bpf/bpf_testmod/bpf_testmod-events.h | 6 +
> > .../selftests/bpf/bpf_testmod/bpf_testmod.c | 21 ++-
> > .../selftests/bpf/bpf_testmod/bpf_testmod.h | 6 +
> > .../selftests/bpf/prog_tests/module_attach.c | 27 +++
> > .../selftests/bpf/progs/test_module_attach.c | 10 +++
> > 5 files changed, 69 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod-events.h
> > b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod-events.h
> > index b83ea448bc79..89c6d58e5dd6 100644
> > --- a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod-events.h
> > +++ b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod-events.h
> > @@ -28,6 +28,12 @@ TRACE_EVENT(bpf_testmod_test_read,
> > __entry->pid, __entry->comm, __entry->off, __entry->len)
> > );
> > +/* A bare tracepoint with no event associated with it */
> > +DECLARE_TRACE(bpf_testmod_test_write_bare,
> > + TP_PROTO(struct task_struct *task, struct bpf_testmod_test_write_ctx
> > *ctx),
> > + TP_ARGS(task, ctx)
> > +);
> > +
> > #endif /* _BPF_TESTMOD_EVENTS_H */
> > #undef TRACE_INCLUDE_PATH
> > diff --git a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c
> > b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c
> > index 2df19d73ca49..e900adad2276 100644
> > --- a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c
> > +++ b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c
> > @@ -28,9 +28,28 @@ bpf_testmod_test_read(struct file *file, struct kobject
> > *kobj,
> > EXPORT_SYMBOL(bpf_testmod_test_read);
> > ALLOW_ERROR_INJECTION(bpf_testmod_test_read, ERRNO);
> > +noinline ssize_t
> > +bpf_testmod_test_write(struct file *file, struct kobject *kobj,
> > + struct bin_attribute *bin_attr,
> > + char *buf, loff_t off, size_t len)
> > +{
> > + struct bpf_testmod_test_write_ctx ctx = {
> > + .buf = buf,
> > + .off = off,
> > + .len = len,
> > + };
> > +
> > + trace_bpf_testmod_test_write_bare(current, &ctx);
> > +
> > + return -EIO; /* always fail */
> > +}
> > +EXPORT_SYMBOL(bpf_testmod_test_write);
> > +ALLOW_ERROR_INJECTION(bpf_testmod_test_write, ERRNO);
> > +
> > static struct bin_attribute bin_attr_bpf_testmod_file __ro_after_init = {
>
> Do we need to remove __ro_after_init?
I don't think so. The structure should still remain RO AFAIU.
>
> > - .attr = { .name = "bpf_testmod", .mode = 0444, },
> > + .attr = { .name = "bpf_testmod", .mode = 0666, },
> > .read = bpf_testmod_test_read,
> > + .write = bpf_testmod_test_write,
> > };
> > static int bpf_testmod_init(void)
> > diff --git a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.h
> > b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.h
> > index b81adfedb4f6..b3892dc40111 100644
> > --- a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.h
> > +++ b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.h
> > @@ -11,4 +11,10 @@ struct bpf_testmod_test_read_ctx {
> > size_t len;
> > };
> > +struct bpf_testmod_test_write_ctx {
> > + char *buf;
> > + loff_t off;
> > + size_t len;
> > +};
> > +
> > #endif /* _BPF_TESTMOD_H */
> > diff --git a/tools/testing/selftests/bpf/prog_tests/module_attach.c
> > b/tools/testing/selftests/bpf/prog_tests/module_attach.c
> > index 50796b651f72..e4605c0b5af1 100644
> > --- a/tools/testing/selftests/bpf/prog_tests/module_attach.c
> > +++ b/tools/testing/selftests/bpf/prog_tests/module_attach.c
> > @@ -21,9 +21,34 @@ static int trigger_module_test_read(int read_sz)
> > return 0;
> > }
> > +static int trigger_module_test_write(int write_sz)
> > +{
> > + int fd, err;
>
> Init err = 0?
I don't see what difference this makes.
>
> > + char *buf = malloc(write_sz);
> > +
> > + if (!buf)
> > + return -ENOMEM;
>
> Looks like we already non-negative value, so return ENOMEM?
We already set err=-errno. So shouldn't we return negative too?
>
> > +
> > + memset(buf, 'a', write_sz);
> > + buf[write_sz-1] = '\0';
> > +
> > + fd = open("/sys/kernel/bpf_testmod", O_WRONLY);
> > + err = -errno;
> > + if (CHECK(fd < 0, "testmod_file_open", "failed: %d\n", err))
> > + goto out;
>
> Change the above to
> fd = open("/sys/kernel/bpf_testmod", O_WRONLY);
> if (CHECK(fd < 0, "testmod_file_open", "failed: %d\n", errno)) {
> err = -errno;
> goto out;
> }
I kept the code consistent with the definition of trigger_module_test_read().
I'll leave it up to the maintainer to pick up the style changes if they prefer
it this way.
Thanks for the ack and for the review.
Cheers
--
Qais Yousef
Re: [PATCH] drm/panel: panel-simple: add bus-format and connector-type to Innolux n116bge
On Sat, 9 Jan 2021 14:09:51 +0100, Heiko Stuebner wrote: > The Innolux n116bge panel has an eDP connector and 3*6 bits bus format. Applied, thanks! [1/1] drm/panel: panel-simple: add bus-format and connector-type to Innolux n116bge commit: 87969bcd49480508568070fd93d7367f03316aa9 Best regards, -- Heiko Stuebner
Re: [PATCH] media: zr364xx: fix memory leaks in probe()
On Wed, Jan 13, 2021 at 05:13:41PM +0100, Hans Verkuil wrote: > Hi Dan, > > On 06/01/2021 11:10, Dan Carpenter wrote: > > Syzbot discovered that the probe error handling doesn't clean up the > > resources allocated in zr364xx_board_init(). There are several > > related bugs in this code so I have re-written the error handling. > > > > 1) Introduce a new function zr364xx_board_uninit() which cleans up > > the resources in zr364xx_board_init(). > > 2) In zr364xx_board_init() if the call to zr364xx_start_readpipe() > > fails then release the "cam->buffer.frame[i].lpvbits" memory > > before returning. This way every function either allocates > > everything successfully or it cleans up after itself. > > 3) Re-write the probe function so that each failure path goto frees > > the most recent allocation. That way we don't free anything > > before it has been allocated and we can also verify that > > everything is freed. > > 4) Originally, in the probe function the "cam->v4l2_dev.release" > > pointer was set to "zr364xx_release" near the start but I moved > > that assignment to the end, after everything had succeeded. The > > release function was never actually called during the probe cleanup > > process, but with this change I wanted to make it clear that we > > don't want to call zr364xx_release() until everything is > > allocated successfully. > > > > Next I re-wrote the zr364xx_release() function. Ideally this would > > have been a simple matter of copy and pasting the cleanup code from > > probe and adding an additional call to video_unregister_device(). But > > there are several quirks to note. > > > > 1) The original code never called video_unregister_device(). In other > > words, this is an additional bugfix. > > Not a bug, see below. > Thanks for reviewing this. I will fix a send a v2. I should have seen that. The layering here is sort of confusing in a way... But not anything that needs to be dealt with immediately. regards, dan carpenter
[PATCH V2] mm/compaction: correct deferral logic for proactive compaction
should_proactive_compact_node() returns true when sum of the
weighted fragmentation score of all the zones in the node is greater
than the wmark_high of compaction, which then triggers the proactive
compaction that operates on the individual zones of the node. But
proactive compaction runs on the zone only when its weighted
fragmentation score is greater than wmark_low(=wmark_high - 10).
This means that the sum of the weighted fragmentation scores of all the
zones can exceed the wmark_high but individual weighted fragmentation
zone scores can still be less than wmark_low which makes the unnecessary
trigger of the proactive compaction only to return doing nothing.
Issue with the return of proactive compaction with out even trying is
its deferral. It is simply deferred for 1 << COMPACT_MAX_DEFER_SHIFT if
the scores across the proactive compaction is same, thinking that
compaction didn't make any progress but in reality it didn't even try.
With the delay between successive retries for proactive compaction is
500msec, it can result into the deferral for ~30sec with out even trying
the proactive compaction.
Test scenario is that: compaction_proactiveness=50 thus the wmark_low =
50 and wmark_high = 60. System have 2 zones(Normal and Movable) with
sizes 5GB and 6GB respectively. After opening some apps on the android,
the weighted fragmentation scores of these zones are 47 and 49
respectively. Since the sum of these fragmentation scores are above the
wmark_high which triggers the proactive compaction and there since the
individual zones weighted fragmentation scores are below wmark_low, it
returns without trying the proactive compaction. As a result the
weighted fragmentation scores of the zones are still 47 and 49 which
makes the existing logic to defer the compaction thinking that
noprogress is made across the compaction.
Fix this by checking just zone fragmentation score, not the weighted, in
__compact_finished() and use the zones weighted fragmentation score in
fragmentation_score_node(). In the test case above, If the weighted
average of is above wmark_high, then individual score (not adjusted) of
atleast one zone has to be above wmark_high. Thus it avoids the
unnecessary trigger and deferrals of the proactive compaction.
Fix-suggested-by: Vlastimil Babka
Signed-off-by: Charan Teja Reddy
---
Changes in V2: Addressed comments from vlastimil
Changes in V1: https://lore.kernel.org/patchwork/patch/1364646/
mm/compaction.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index e5acb97..1b98427 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1924,16 +1924,16 @@ static bool kswapd_is_running(pg_data_t *pgdat)
}
/*
- * A zone's fragmentation score is the external fragmentation wrt to the
- * COMPACTION_HPAGE_ORDER scaled by the zone's size. It returns a value
- * in the range [0, 100].
+ * A weighted zone's fragmentation score is the external fragmentation
+ * wrt to the COMPACTION_HPAGE_ORDER scaled by the zone's size. It
+ * returns a value in the range [0, 100].
*
* The scaling factor ensures that proactive compaction focuses on larger
* zones like ZONE_NORMAL, rather than smaller, specialized zones like
* ZONE_DMA32. For smaller zones, the score value remains close to zero,
* and thus never exceeds the high threshold for proactive compaction.
*/
-static unsigned int fragmentation_score_zone(struct zone *zone)
+static unsigned int fragmentation_score_zone_weighted(struct zone *zone)
{
unsigned long score;
@@ -1943,6 +1943,15 @@ static unsigned int fragmentation_score_zone(struct zone
*zone)
}
/*
+ * A zone's fragmentation score is the external fragmentation wrt to the
+ * COMPACTION_HPAGE_ORDER. It returns a value in the range [0, 100].
+ */
+static unsigned int fragmentation_score_zone(struct zone *zone)
+{
+ return extfrag_for_order(zone, COMPACTION_HPAGE_ORDER);
+}
+
+/*
* The per-node proactive (background) compaction process is started by its
* corresponding kcompactd thread when the node's fragmentation score
* exceeds the high threshold. The compaction process remains active till
@@ -1958,7 +1967,7 @@ static unsigned int fragmentation_score_node(pg_data_t
*pgdat)
struct zone *zone;
zone = &pgdat->node_zones[zoneid];
- score += fragmentation_score_zone(zone);
+ score += fragmentation_score_zone_weighted(zone);
}
return score;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 1/4] x86/fpu: Add kernel_fpu_begin_mask() to selectively initialize state
On Sun, Jan 17, 2021 at 10:20:38PM -0800, Andy Lutomirski wrote: > - Code that wants MMX doesn't want need MXCSR or FCW initialized. >_mmx_memcpy(), for example, can run before CR4.OSFXSR gets set, and >initializing MXCSR will fail. > +#define KFPU_MMX 0 /* nothing gets initialized */ This... why is that correct?
Re: [PATCH v3] Documentation: livepatch: document reliable stacktrace
On Fri, Jan 15, 2021 at 10:20:14AM -0700, Jonathan Corbet wrote: > On Fri, 15 Jan 2021 17:12:51 + > Mark Brown wrote: > > > On Fri, Jan 15, 2021 at 04:47:18PM +, Mark Rutland wrote: > > > On Fri, Jan 15, 2021 at 02:24:46PM +, Mark Brown wrote: > > > > > > +3. Considerations > > > > + 3.1 Identifying successful termination > > > > > It looks like we forgot to update this with the addition of the new > > > section 3, so this needs a trivial update to add that and fix the > > > numbering. > > > > Bah, I thought the point with structured documentation formats was that > > tooling would handle stuff like this :/ > > The tooling *will* handle it if you let it, it's a simple matter of > replacing the hand-generated table of contents with a Sphinx directive. I > think that's generally the right thing to do, but it does have the > downside of only putting the TOC in the generated docs. Ah, I was not aware of that, and I had copied the TOC style from Documentation/livepatch/livepatch.rst. That does sound like the right thing to do generally, and I have no problem doing that here, but I guess we be consistent and either do that for all or none of the Documentation/livepatch/*.rst documents. I guess we could do that as a followup? Thanks, Mark.
Re: [PATCH] usb: bdc: Remove the BDC PCI driver
Hi, Greg Kroah-Hartman writes: >> Al Cooper writes: >> > The BDC PCI driver was only used for design verification with >> > an PCI/FPGA board. The board no longer exists and is not in use >> > anywhere. All instances of this core now exist as a memory mapped >> > device on the platform bus. >> > >> > NOTE: This only removes the PCI driver and does not remove the >> > platform driver. >> > >> > Signed-off-by: Al Cooper >> >> It sounds like it could be used for pre-silicon verification of newer >> Core Releases, much like Synopsys still uses the HAPS (with mainline >> linux, mind you) for silicon validation. >> >> Why would we delete this small shim if it *could* still be useful? > > It ends up conflicting with the PCI id of a device that is actually in > the wild (a camera on Apple laptops). So it's good to drop this driver > so the wrong driver doesn't get constantly bound to the wrong device. I see. Oh well... -- balbi signature.asc Description: PGP signature
[PATCH 5.10 108/152] blk-mq-debugfs: Add decode for BLK_MQ_F_TAG_HCTX_SHARED
From: John Garry
[ Upstream commit 02f938e9fed1681791605ca8b96c2d9da9355f6a ]
Showing the hctx flags for when BLK_MQ_F_TAG_HCTX_SHARED is set gives
something like:
root@debian:/home/john# more /sys/kernel/debug/block/sda/hctx0/flags
alloc_policy=FIFO SHOULD_MERGE|TAG_QUEUE_SHARED|3
Add the decoding for that flag.
Fixes: 32bc15afed04b ("blk-mq: Facilitate a shared sbitmap per tagset")
Signed-off-by: John Garry
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
---
block/blk-mq-debugfs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/blk-mq-debugfs.c b/block/blk-mq-debugfs.c
index 4d6e83e5b4429..4de03da9a624b 100644
--- a/block/blk-mq-debugfs.c
+++ b/block/blk-mq-debugfs.c
@@ -246,6 +246,7 @@ static const char *const hctx_flag_name[] = {
HCTX_FLAG_NAME(BLOCKING),
HCTX_FLAG_NAME(NO_SCHED),
HCTX_FLAG_NAME(STACKING),
+ HCTX_FLAG_NAME(TAG_HCTX_SHARED),
};
#undef HCTX_FLAG_NAME
--
2.27.0
[PATCH 5.10 107/152] net/mlx5: E-Switch, fix changing vf VLANID
From: Alaa Hleihel
[ Upstream commit 25c904b59aaf4816337acd415514b0c47715f604 ]
Adding vf VLANID for the first time, or after having cleared previously
defined VLANID works fine, however, attempting to change an existing vf
VLANID clears the rules on the firmware, but does not add new rules for
the new vf VLANID.
Fix this by changing the logic in function esw_acl_egress_lgcy_setup()
so that it will always configure egress rules.
Fixes: ea651a86d468 ("net/mlx5: E-Switch, Refactor eswitch egress acl codes")
Signed-off-by: Alaa Hleihel
Signed-off-by: Saeed Mahameed
Signed-off-by: Sasha Levin
---
.../mellanox/mlx5/core/esw/acl/egress_lgcy.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/egress_lgcy.c
b/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/egress_lgcy.c
index 2b85d4777303a..3e19b1721303f 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/egress_lgcy.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/egress_lgcy.c
@@ -95,22 +95,21 @@ int esw_acl_egress_lgcy_setup(struct mlx5_eswitch *esw,
return 0;
}
- if (!IS_ERR_OR_NULL(vport->egress.acl))
- return 0;
-
- vport->egress.acl = esw_acl_table_create(esw, vport->vport,
-MLX5_FLOW_NAMESPACE_ESW_EGRESS,
-table_size);
- if (IS_ERR(vport->egress.acl)) {
- err = PTR_ERR(vport->egress.acl);
- vport->egress.acl = NULL;
- goto out;
+ if (!vport->egress.acl) {
+ vport->egress.acl = esw_acl_table_create(esw, vport->vport,
+
MLX5_FLOW_NAMESPACE_ESW_EGRESS,
+table_size);
+ if (IS_ERR(vport->egress.acl)) {
+ err = PTR_ERR(vport->egress.acl);
+ vport->egress.acl = NULL;
+ goto out;
+ }
+
+ err = esw_acl_egress_lgcy_groups_create(esw, vport);
+ if (err)
+ goto out;
}
- err = esw_acl_egress_lgcy_groups_create(esw, vport);
- if (err)
- goto out;
-
esw_debug(esw->dev,
"vport[%d] configure egress rules, vlan(%d) qos(%d)\n",
vport->vport, vport->info.vlan, vport->info.qos);
--
2.27.0
[PATCH 5.10 106/152] net/mlx5: Fix passing zero to PTR_ERR
From: YueHaibing
[ Upstream commit 0c4accc41cb56e527c8c049f5495af9f3d6bef7e ]
Fix smatch warnings:
drivers/net/ethernet/mellanox/mlx5/core/esw/acl/egress_lgcy.c:105
esw_acl_egress_lgcy_setup() warn: passing zero to 'PTR_ERR'
drivers/net/ethernet/mellanox/mlx5/core/esw/acl/egress_ofld.c:177
esw_acl_egress_ofld_setup() warn: passing zero to 'PTR_ERR'
drivers/net/ethernet/mellanox/mlx5/core/esw/acl/ingress_lgcy.c:184
esw_acl_ingress_lgcy_setup() warn: passing zero to 'PTR_ERR'
drivers/net/ethernet/mellanox/mlx5/core/esw/acl/ingress_ofld.c:262
esw_acl_ingress_ofld_setup() warn: passing zero to 'PTR_ERR'
esw_acl_table_create() never returns NULL, so
NULL test should be removed.
Signed-off-by: YueHaibing
Signed-off-by: Saeed Mahameed
Signed-off-by: Sasha Levin
---
drivers/net/ethernet/mellanox/mlx5/core/esw/acl/egress_lgcy.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/esw/acl/egress_ofld.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/esw/acl/ingress_lgcy.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/esw/acl/ingress_ofld.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/egress_lgcy.c
b/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/egress_lgcy.c
index d46f8b225ebe3..2b85d4777303a 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/egress_lgcy.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/egress_lgcy.c
@@ -101,7 +101,7 @@ int esw_acl_egress_lgcy_setup(struct mlx5_eswitch *esw,
vport->egress.acl = esw_acl_table_create(esw, vport->vport,
MLX5_FLOW_NAMESPACE_ESW_EGRESS,
table_size);
- if (IS_ERR_OR_NULL(vport->egress.acl)) {
+ if (IS_ERR(vport->egress.acl)) {
err = PTR_ERR(vport->egress.acl);
vport->egress.acl = NULL;
goto out;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/egress_ofld.c
b/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/egress_ofld.c
index c3faae67e4d6e..4c74e2690d57b 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/egress_ofld.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/egress_ofld.c
@@ -173,7 +173,7 @@ int esw_acl_egress_ofld_setup(struct mlx5_eswitch *esw,
struct mlx5_vport *vport
table_size++;
vport->egress.acl = esw_acl_table_create(esw, vport->vport,
MLX5_FLOW_NAMESPACE_ESW_EGRESS, table_size);
- if (IS_ERR_OR_NULL(vport->egress.acl)) {
+ if (IS_ERR(vport->egress.acl)) {
err = PTR_ERR(vport->egress.acl);
vport->egress.acl = NULL;
return err;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/ingress_lgcy.c
b/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/ingress_lgcy.c
index b68976b378b81..d64fad2823e73 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/ingress_lgcy.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/ingress_lgcy.c
@@ -180,7 +180,7 @@ int esw_acl_ingress_lgcy_setup(struct mlx5_eswitch *esw,
vport->ingress.acl = esw_acl_table_create(esw, vport->vport,
MLX5_FLOW_NAMESPACE_ESW_INGRESS,
table_size);
- if (IS_ERR_OR_NULL(vport->ingress.acl)) {
+ if (IS_ERR(vport->ingress.acl)) {
err = PTR_ERR(vport->ingress.acl);
vport->ingress.acl = NULL;
return err;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/ingress_ofld.c
b/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/ingress_ofld.c
index 4e55d7225a265..548c005ea6335 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/ingress_ofld.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/ingress_ofld.c
@@ -258,7 +258,7 @@ int esw_acl_ingress_ofld_setup(struct mlx5_eswitch *esw,
vport->ingress.acl = esw_acl_table_create(esw, vport->vport,
MLX5_FLOW_NAMESPACE_ESW_INGRESS,
num_ftes);
- if (IS_ERR_OR_NULL(vport->ingress.acl)) {
+ if (IS_ERR(vport->ingress.acl)) {
err = PTR_ERR(vport->ingress.acl);
vport->ingress.acl = NULL;
return err;
--
2.27.0
[PATCH 5.10 105/152] net/mlx5e: CT: Use per flow counter when CT flow accounting is enabled
From: Oz Shlomo
[ Upstream commit eed38734756596e2cc163bdc7dac3be501b1 ]
Connection counters may be shared for both directions when the counter
is used for connection aging purposes. However, if TC flow
accounting is enabled then a unique counter is required per direction.
Instantiate a unique counter per direction if the conntrack accounting
extension is enabled. Use a shared counter when the connection accounting
extension is disabled.
Fixes: 1edae2335adf ("net/mlx5e: CT: Use the same counter for both directions")
Signed-off-by: Oz Shlomo
Reported-by: Marcelo Ricardo Leitner
Reviewed-by: Roi Dayan
Reviewed-by: Paul Blakey
Signed-off-by: Saeed Mahameed
Signed-off-by: Sasha Levin
---
.../ethernet/mellanox/mlx5/core/en/tc_ct.c| 77 ---
1 file changed, 49 insertions(+), 28 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_ct.c
b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_ct.c
index e521254d886ef..072363e73f1ce 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_ct.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_ct.c
@@ -118,16 +118,17 @@ struct mlx5_ct_tuple {
u16 zone;
};
-struct mlx5_ct_shared_counter {
+struct mlx5_ct_counter {
struct mlx5_fc *counter;
refcount_t refcount;
+ bool is_shared;
};
struct mlx5_ct_entry {
struct rhash_head node;
struct rhash_head tuple_node;
struct rhash_head tuple_nat_node;
- struct mlx5_ct_shared_counter *shared_counter;
+ struct mlx5_ct_counter *counter;
unsigned long cookie;
unsigned long restore_cookie;
struct mlx5_ct_tuple tuple;
@@ -394,13 +395,14 @@ mlx5_tc_ct_set_tuple_match(struct mlx5e_priv *priv,
struct mlx5_flow_spec *spec,
}
static void
-mlx5_tc_ct_shared_counter_put(struct mlx5_tc_ct_priv *ct_priv, struct
mlx5_ct_entry *entry)
+mlx5_tc_ct_counter_put(struct mlx5_tc_ct_priv *ct_priv, struct mlx5_ct_entry
*entry)
{
- if (!refcount_dec_and_test(&entry->shared_counter->refcount))
+ if (entry->counter->is_shared &&
+ !refcount_dec_and_test(&entry->counter->refcount))
return;
- mlx5_fc_destroy(ct_priv->dev, entry->shared_counter->counter);
- kfree(entry->shared_counter);
+ mlx5_fc_destroy(ct_priv->dev, entry->counter->counter);
+ kfree(entry->counter);
}
static void
@@ -699,7 +701,7 @@ mlx5_tc_ct_entry_add_rule(struct mlx5_tc_ct_priv *ct_priv,
attr->dest_ft = ct_priv->post_ct;
attr->ft = nat ? ct_priv->ct_nat : ct_priv->ct;
attr->outer_match_level = MLX5_MATCH_L4;
- attr->counter = entry->shared_counter->counter;
+ attr->counter = entry->counter->counter;
attr->flags |= MLX5_ESW_ATTR_FLAG_NO_IN_PORT;
mlx5_tc_ct_set_tuple_match(netdev_priv(ct_priv->netdev), spec,
flow_rule);
@@ -732,13 +734,34 @@ mlx5_tc_ct_entry_add_rule(struct mlx5_tc_ct_priv *ct_priv,
return err;
}
-static struct mlx5_ct_shared_counter *
+static struct mlx5_ct_counter *
+mlx5_tc_ct_counter_create(struct mlx5_tc_ct_priv *ct_priv)
+{
+ struct mlx5_ct_counter *counter;
+ int ret;
+
+ counter = kzalloc(sizeof(*counter), GFP_KERNEL);
+ if (!counter)
+ return ERR_PTR(-ENOMEM);
+
+ counter->is_shared = false;
+ counter->counter = mlx5_fc_create(ct_priv->dev, true);
+ if (IS_ERR(counter->counter)) {
+ ct_dbg("Failed to create counter for ct entry");
+ ret = PTR_ERR(counter->counter);
+ kfree(counter);
+ return ERR_PTR(ret);
+ }
+
+ return counter;
+}
+
+static struct mlx5_ct_counter *
mlx5_tc_ct_shared_counter_get(struct mlx5_tc_ct_priv *ct_priv,
struct mlx5_ct_entry *entry)
{
struct mlx5_ct_tuple rev_tuple = entry->tuple;
- struct mlx5_ct_shared_counter *shared_counter;
- struct mlx5_core_dev *dev = ct_priv->dev;
+ struct mlx5_ct_counter *shared_counter;
struct mlx5_ct_entry *rev_entry;
__be16 tmp_port;
int ret;
@@ -767,25 +790,20 @@ mlx5_tc_ct_shared_counter_get(struct mlx5_tc_ct_priv
*ct_priv,
rev_entry = rhashtable_lookup_fast(&ct_priv->ct_tuples_ht, &rev_tuple,
tuples_ht_params);
if (rev_entry) {
- if
(refcount_inc_not_zero(&rev_entry->shared_counter->refcount)) {
+ if (refcount_inc_not_zero(&rev_entry->counter->refcount)) {
mutex_unlock(&ct_priv->shared_counter_lock);
- return rev_entry->shared_counter;
+ return rev_entry->counter;
}
}
mutex_unlock(&ct_priv->shared_counter_lock);
- shared_counter = kzalloc(sizeof(*shared_counter), GFP_KERNEL);
- if (!shared_counter)
- return ERR_PTR(-ENOMEM);
-
- shared_counter->counter = mlx5_fc_create(dev, true);
- if (IS_ERR(share
[PATCH 5.10 128/152] NFS/pNFS: Fix a leak of the layout plh_outstanding counter
From: Trond Myklebust
commit cb2856c5971723910a86b7d1d0cf623d6919cbc4 upstream.
If we exit _lgopen_prepare_attached() without setting a layout, we will
currently leak the plh_outstanding counter.
Fixes: 411ae722d10a ("pNFS: Wait for stale layoutget calls to complete in
pnfs_update_layout()")
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman
---
fs/nfs/pnfs.c |1 +
1 file changed, 1 insertion(+)
--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -2245,6 +2245,7 @@ static void _lgopen_prepare_attached(str
&rng, GFP_KERNEL);
if (!lgp) {
pnfs_clear_first_layoutget(lo);
+ nfs_layoutget_end(lo);
pnfs_put_layout_hdr(lo);
return;
}
[PATCH 5.10 127/152] NFS/pNFS: Dont leak DS commits in pnfs_generic_retry_commit()
From: Trond Myklebust
commit 46c9ea1d4fee4cf1f8cc6001b9c14aae61b3d502 upstream.
We must ensure that we pass a layout segment to nfs_retry_commit() when
we're cleaning up after pnfs_bucket_alloc_ds_commits(). Otherwise,
requests that should be committed to the DS will get committed to the
MDS.
Do so by ensuring that pnfs_bucket_get_committing() always tries to
return a layout segment when it returns a non-empty page list.
Fixes: c84bea59449a ("NFS/pNFS: Simplify bucket layout segment reference
counting")
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman
---
fs/nfs/pnfs_nfs.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/fs/nfs/pnfs_nfs.c
+++ b/fs/nfs/pnfs_nfs.c
@@ -403,12 +403,16 @@ pnfs_bucket_get_committing(struct list_h
struct pnfs_commit_bucket *bucket,
struct nfs_commit_info *cinfo)
{
+ struct pnfs_layout_segment *lseg;
struct list_head *pos;
list_for_each(pos, &bucket->committing)
cinfo->ds->ncommitting--;
list_splice_init(&bucket->committing, head);
- return pnfs_free_bucket_lseg(bucket);
+ lseg = pnfs_free_bucket_lseg(bucket);
+ if (!lseg)
+ lseg = pnfs_get_lseg(bucket->lseg);
+ return lseg;
}
static struct nfs_commit_data *
@@ -420,8 +424,6 @@ pnfs_bucket_fetch_commitdata(struct pnfs
if (!data)
return NULL;
data->lseg = pnfs_bucket_get_committing(&data->pages, bucket, cinfo);
- if (!data->lseg)
- data->lseg = pnfs_get_lseg(bucket->lseg);
return data;
}
[PATCH 5.10 104/152] iommu/vt-d: Update domain geometry in iommu_ops.at(de)tach_dev
From: Lu Baolu [ Upstream commit c062db039f40e868c371c36afe8d0fac64305b5d ] The iommu-dma constrains IOVA allocation based on the domain geometry that the driver reports. Update domain geometry everytime a domain is attached to or detached from a device. Signed-off-by: Lu Baolu Tested-by: Logan Gunthorpe Link: https://lore.kernel.org/r/20201124082057.2614359-6-baolu...@linux.intel.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin --- drivers/iommu/intel/iommu.c | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index c9da9e93f545c..151243fa01ba5 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -67,8 +67,8 @@ #define MAX_AGAW_WIDTH 64 #define MAX_AGAW_PFN_WIDTH (MAX_AGAW_WIDTH - VTD_PAGE_SHIFT) -#define __DOMAIN_MAX_PFN(gaw) uint64_t)1) << (gaw-VTD_PAGE_SHIFT)) - 1) -#define __DOMAIN_MAX_ADDR(gaw) uint64_t)1) << gaw) - 1) +#define __DOMAIN_MAX_PFN(gaw) uint64_t)1) << ((gaw) - VTD_PAGE_SHIFT)) - 1) +#define __DOMAIN_MAX_ADDR(gaw) uint64_t)1) << (gaw)) - 1) /* We limit DOMAIN_MAX_PFN to fit in an unsigned long, and DOMAIN_MAX_ADDR to match. That way, we can use 'unsigned long' for PFNs with impunity. */ @@ -739,6 +739,18 @@ static void domain_update_iommu_cap(struct dmar_domain *domain) */ if (domain->nid == NUMA_NO_NODE) domain->nid = domain_update_device_node(domain); + + /* +* First-level translation restricts the input-address to a +* canonical address (i.e., address bits 63:N have the same +* value as address bit [N-1], where N is 48-bits with 4-level +* paging and 57-bits with 5-level paging). Hence, skip bit +* [N-1]. +*/ + if (domain_use_first_level(domain)) + domain->domain.geometry.aperture_end = __DOMAIN_MAX_ADDR(domain->gaw - 1); + else + domain->domain.geometry.aperture_end = __DOMAIN_MAX_ADDR(domain->gaw); } struct context_entry *iommu_context_addr(struct intel_iommu *iommu, u8 bus, -- 2.27.0
[PATCH 5.10 129/152] NFS: nfs_delegation_find_inode_server must first reference the superblock
From: Trond Myklebust
commit 113aac6d567bda783af36d08f73bfda47d8e9a40 upstream.
Before referencing the inode, we must ensure that the superblock can be
referenced. Otherwise, we can end up with iput() calling superblock
operations that are no longer valid or accessible.
Fixes: e39d8a186ed0 ("NFSv4: Fix an Oops during delegation callbacks")
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman
---
fs/nfs/delegation.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
--- a/fs/nfs/delegation.c
+++ b/fs/nfs/delegation.c
@@ -1011,22 +1011,24 @@ nfs_delegation_find_inode_server(struct
const struct nfs_fh *fhandle)
{
struct nfs_delegation *delegation;
- struct inode *freeme, *res = NULL;
+ struct super_block *freeme = NULL;
+ struct inode *res = NULL;
list_for_each_entry_rcu(delegation, &server->delegations, super_list) {
spin_lock(&delegation->lock);
if (delegation->inode != NULL &&
!test_bit(NFS_DELEGATION_REVOKED, &delegation->flags) &&
nfs_compare_fh(fhandle, &NFS_I(delegation->inode)->fh) ==
0) {
- freeme = igrab(delegation->inode);
- if (freeme && nfs_sb_active(freeme->i_sb))
- res = freeme;
+ if (nfs_sb_active(server->super)) {
+ freeme = server->super;
+ res = igrab(delegation->inode);
+ }
spin_unlock(&delegation->lock);
if (res != NULL)
return res;
if (freeme) {
rcu_read_unlock();
- iput(freeme);
+ nfs_sb_deactive(freeme);
rcu_read_lock();
}
return ERR_PTR(-EAGAIN);
Re: [PATCH v2 1/2] vfio/iommu_type1: Populate full dirty when detach non-pinned group
On 2021/1/16 2:01, Alex Williamson wrote:
> On Fri, 15 Jan 2021 17:26:42 +0800
> Keqian Zhu wrote:
>
>> If a group with non-pinned-page dirty scope is detached with dirty
>> logging enabled, we should fully populate the dirty bitmaps at the
>> time it's removed since we don't know the extent of its previous DMA,
>> nor will the group be present to trigger the full bitmap when the user
>> retrieves the dirty bitmap.
>>
>> Fixes: d6a4c185660c ("vfio iommu: Implementation of ioctl for dirty pages
>> tracking")
>> Suggested-by: Alex Williamson
>> Signed-off-by: Keqian Zhu
>> ---
>> drivers/vfio/vfio_iommu_type1.c | 18 +-
>> 1 file changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/vfio/vfio_iommu_type1.c
>> b/drivers/vfio/vfio_iommu_type1.c
>> index 0b4dedaa9128..4e82b9a3440f 100644
>> --- a/drivers/vfio/vfio_iommu_type1.c
>> +++ b/drivers/vfio/vfio_iommu_type1.c
>> @@ -236,6 +236,19 @@ static void vfio_dma_populate_bitmap(struct vfio_dma
>> *dma, size_t pgsize)
>> }
>> }
>>
>> +static void vfio_iommu_populate_bitmap_full(struct vfio_iommu *iommu)
>> +{
>> +struct rb_node *n;
>> +unsigned long pgshift = __ffs(iommu->pgsize_bitmap);
>> +
>> +for (n = rb_first(&iommu->dma_list); n; n = rb_next(n)) {
>> +struct vfio_dma *dma = rb_entry(n, struct vfio_dma, node);
>> +
>> +if (dma->iommu_mapped)
>> +bitmap_set(dma->bitmap, 0, dma->size >> pgshift);
>> +}
>> +}
>> +
>> static int vfio_dma_bitmap_alloc_all(struct vfio_iommu *iommu, size_t
>> pgsize)
>> {
>> struct rb_node *n;
>> @@ -2415,8 +2428,11 @@ static void vfio_iommu_type1_detach_group(void
>> *iommu_data,
>> * Removal of a group without dirty tracking may allow the iommu scope
>> * to be promoted.
>> */
>> -if (update_dirty_scope)
>> +if (update_dirty_scope) {
>> update_pinned_page_dirty_scope(iommu);
>> +if (iommu->dirty_page_tracking)
>> +vfio_iommu_populate_bitmap_full(iommu);
>> +}
>> mutex_unlock(&iommu->lock);
>> }
>>
>
> This doesn't do the right thing. This marks the bitmap dirty if:
>
> * The detached group dirty scope was not limited to pinned pages
>
> AND
>
> * Dirty tracking is enabled
>
> AND
>
> * The vfio_dma is *currently* (ie. after the detach) iommu_mapped
>
> We need to mark the bitmap dirty based on whether the vfio_dma *was*
> iommu_mapped by the group that is now detached. Thanks,
>
> Alex
>
Hi Alex,
Yes, I missed this point again :-(. The update_dirty_scope means we detached
an iommu backed group, and that means the vfio_dma *was* iommu_mapped by this
group, so we can populate full bitmap unconditionally, right?
Thanks,
Keqian
> .
>
[PATCH 5.10 130/152] NFS: nfs_igrab_and_active must first reference the superblock
From: Trond Myklebust
commit 896567ee7f17a8a736cda8a28cc987228410a2ac upstream.
Before referencing the inode, we must ensure that the superblock can be
referenced. Otherwise, we can end up with iput() calling superblock
operations that are no longer valid or accessible.
Fixes: ea7c38fef0b7 ("NFSv4: Ensure we reference the inode for return-on-close
in delegreturn")
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman
---
fs/nfs/internal.h | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
--- a/fs/nfs/internal.h
+++ b/fs/nfs/internal.h
@@ -605,12 +605,14 @@ extern void nfs4_test_session_trunk(stru
static inline struct inode *nfs_igrab_and_active(struct inode *inode)
{
- inode = igrab(inode);
- if (inode != NULL && !nfs_sb_active(inode->i_sb)) {
- iput(inode);
- inode = NULL;
+ struct super_block *sb = inode->i_sb;
+
+ if (sb && nfs_sb_active(sb)) {
+ if (igrab(inode))
+ return inode;
+ nfs_sb_deactive(sb);
}
- return inode;
+ return NULL;
}
static inline void nfs_iput_and_deactive(struct inode *inode)
[PATCH 5.10 132/152] ext4: fix superblock checksum failure when setting password salt
From: Jan Kara
commit dfd56c2c0c0dbb11be939b804ddc8d5395ab3432 upstream.
When setting password salt in the superblock, we forget to recompute the
superblock checksum so it will not match until the next superblock
modification which recomputes the checksum. Fix it.
CC: Michael Halcrow
Reported-by: Andreas Dilger
Fixes: 9bd8212f981e ("ext4 crypto: add encryption policy and password salt
support")
Signed-off-by: Jan Kara
Link: https://lore.kernel.org/r/20201216101844.22917-8-j...@suse.cz
Signed-off-by: Theodore Ts'o
Signed-off-by: Greg Kroah-Hartman
---
fs/ext4/ioctl.c |3 +++
1 file changed, 3 insertions(+)
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -1157,7 +1157,10 @@ resizefs_out:
err = ext4_journal_get_write_access(handle, sbi->s_sbh);
if (err)
goto pwsalt_err_journal;
+ lock_buffer(sbi->s_sbh);
generate_random_uuid(sbi->s_es->s_encrypt_pw_salt);
+ ext4_superblock_csum_set(sb);
+ unlock_buffer(sbi->s_sbh);
err = ext4_handle_dirty_metadata(handle, NULL,
sbi->s_sbh);
pwsalt_err_journal:
[PATCH 5.10 131/152] scsi: ufs: Fix possible power drain during system suspend
From: Stanley Chu
commit 1d53864c3617f5235f891ca0fbe9347c4cd35d46 upstream.
Currently if device needs to do flush or BKOP operations, the device VCC
power is kept during runtime-suspend period.
However, if system suspend is happening while device is runtime-suspended,
such power may not be disabled successfully.
The reasons may be,
1. If current PM level is the same as SPM level, device will keep
runtime-suspended by ufshcd_system_suspend().
2. Flush recheck work may not be scheduled successfully during system
suspend period. If it can wake up the system, this is also not the
intention of the recheck work.
To fix this issue, simply runtime-resume the device if the flush is allowed
during runtime suspend period. Flush capability will be disabled while
leaving runtime suspend, and also not be allowed in system suspend period.
Link: https://lore.kernel.org/r/20201222072905.32221-2-stanley@mediatek.com
Fixes: 51dd905bd2f6 ("scsi: ufs: Fix WriteBooster flush during runtime suspend")
Reviewed-by: Chaotian Jing
Reviewed-by: Can Guo
Signed-off-by: Stanley Chu
Signed-off-by: Martin K. Petersen
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/ufs/ufshcd.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -8818,7 +8818,8 @@ int ufshcd_system_suspend(struct ufs_hba
if ((ufs_get_pm_lvl_to_dev_pwr_mode(hba->spm_lvl) ==
hba->curr_dev_pwr_mode) &&
(ufs_get_pm_lvl_to_link_pwr_state(hba->spm_lvl) ==
-hba->uic_link_state))
+hba->uic_link_state) &&
+!hba->dev_info.b_rpm_dev_flush_capable)
goto out;
if (pm_runtime_suspended(hba->dev)) {
[PATCH 5.10 103/152] nvme-fc: avoid calling _nvme_fc_abort_outstanding_ios from interrupt context
From: James Smart
[ Upstream commit 19fce0470f05031e6af36e49ce222d0f0050d432 ]
Recent patches changed calling sequences. nvme_fc_abort_outstanding_ios
used to be called from a timeout or work context. Now it is being called
in an io completion context, which can be an interrupt handler.
Unfortunately, the abort outstanding ios routine attempts to stop nvme
queues and nested routines that may try to sleep, which is in conflict
with the interrupt handler.
Correct replacing the direct call with a work element scheduling, and the
abort outstanding ios routine will be called in the work element.
Fixes: 95ced8a2c72d ("nvme-fc: eliminate terminate_io use by
nvme_fc_error_recovery")
Signed-off-by: James Smart
Reported-by: Daniel Wagner
Tested-by: Daniel Wagner
Signed-off-by: Christoph Hellwig
Signed-off-by: Sasha Levin
---
drivers/nvme/host/fc.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/nvme/host/fc.c b/drivers/nvme/host/fc.c
index f4c246462658f..5ead217ac2bc8 100644
--- a/drivers/nvme/host/fc.c
+++ b/drivers/nvme/host/fc.c
@@ -166,6 +166,7 @@ struct nvme_fc_ctrl {
struct blk_mq_tag_set admin_tag_set;
struct blk_mq_tag_set tag_set;
+ struct work_struct ioerr_work;
struct delayed_work connect_work;
struct kref ref;
@@ -1888,6 +1889,15 @@ __nvme_fc_fcpop_chk_teardowns(struct nvme_fc_ctrl *ctrl,
}
}
+static void
+nvme_fc_ctrl_ioerr_work(struct work_struct *work)
+{
+ struct nvme_fc_ctrl *ctrl =
+ container_of(work, struct nvme_fc_ctrl, ioerr_work);
+
+ nvme_fc_error_recovery(ctrl, "transport detected io error");
+}
+
static void
nvme_fc_fcpio_done(struct nvmefc_fcp_req *req)
{
@@ -2046,7 +2056,7 @@ nvme_fc_fcpio_done(struct nvmefc_fcp_req *req)
check_error:
if (terminate_assoc)
- nvme_fc_error_recovery(ctrl, "transport detected io error");
+ queue_work(nvme_reset_wq, &ctrl->ioerr_work);
}
static int
@@ -3233,6 +3243,7 @@ nvme_fc_delete_ctrl(struct nvme_ctrl *nctrl)
{
struct nvme_fc_ctrl *ctrl = to_fc_ctrl(nctrl);
+ cancel_work_sync(&ctrl->ioerr_work);
cancel_delayed_work_sync(&ctrl->connect_work);
/*
* kill the association on the link side. this will block
@@ -3449,6 +3460,7 @@ nvme_fc_init_ctrl(struct device *dev, struct
nvmf_ctrl_options *opts,
INIT_WORK(&ctrl->ctrl.reset_work, nvme_fc_reset_ctrl_work);
INIT_DELAYED_WORK(&ctrl->connect_work, nvme_fc_connect_ctrl_work);
+ INIT_WORK(&ctrl->ioerr_work, nvme_fc_ctrl_ioerr_work);
spin_lock_init(&ctrl->lock);
/* io queue count */
@@ -3540,6 +3552,7 @@ nvme_fc_init_ctrl(struct device *dev, struct
nvmf_ctrl_options *opts,
fail_ctrl:
nvme_change_ctrl_state(&ctrl->ctrl, NVME_CTRL_DELETING);
+ cancel_work_sync(&ctrl->ioerr_work);
cancel_work_sync(&ctrl->ctrl.reset_work);
cancel_delayed_work_sync(&ctrl->connect_work);
--
2.27.0
[PATCH 5.10 121/152] NFS4: Fix use-after-free in trace_event_raw_event_nfs4_set_lock
From: Dave Wysochanski
commit 3d1a90ab0ed93362ec8ac85cf291243c87260c21 upstream.
It is only safe to call the tracepoint before rpc_put_task() because
'data' is freed inside nfs4_lock_release (rpc_release).
Fixes: 48c9579a1afe ("Adding stateid information to tracepoints")
Signed-off-by: Dave Wysochanski
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman
---
fs/nfs/nfs4proc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -7106,9 +7106,9 @@ static int _nfs4_do_setlk(struct nfs4_st
data->arg.new_lock_owner, ret);
} else
data->cancelled = true;
+ trace_nfs4_set_lock(fl, state, &data->res.stateid, cmd, ret);
rpc_put_task(task);
dprintk("%s: done, ret = %d!\n", __func__, ret);
- trace_nfs4_set_lock(fl, state, &data->res.stateid, cmd, ret);
return ret;
}
[PATCH 5.10 126/152] NFS/pNFS: Dont call pnfs_free_bucket_lseg() before removing the request
From: Trond Myklebust
commit 1757655d780d9d29bc4b60e708342e94924f7ef3 upstream.
In pnfs_generic_clear_request_commit(), we try calling
pnfs_free_bucket_lseg() before we remove the request from the DS bucket.
That will always fail, since the point is to test for whether or not
that bucket is empty.
Fixes: c84bea59449a ("NFS/pNFS: Simplify bucket layout segment reference
counting")
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman
---
fs/nfs/pnfs_nfs.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
--- a/fs/nfs/pnfs_nfs.c
+++ b/fs/nfs/pnfs_nfs.c
@@ -78,22 +78,18 @@ void
pnfs_generic_clear_request_commit(struct nfs_page *req,
struct nfs_commit_info *cinfo)
{
- struct pnfs_layout_segment *freeme = NULL;
+ struct pnfs_commit_bucket *bucket = NULL;
if (!test_and_clear_bit(PG_COMMIT_TO_DS, &req->wb_flags))
goto out;
cinfo->ds->nwritten--;
- if (list_is_singular(&req->wb_list)) {
- struct pnfs_commit_bucket *bucket;
-
+ if (list_is_singular(&req->wb_list))
bucket = list_first_entry(&req->wb_list,
- struct pnfs_commit_bucket,
- written);
- freeme = pnfs_free_bucket_lseg(bucket);
- }
+ struct pnfs_commit_bucket, written);
out:
nfs_request_remove_commit_list(req, cinfo);
- pnfs_put_lseg(freeme);
+ if (bucket)
+ pnfs_put_lseg(pnfs_free_bucket_lseg(bucket));
}
EXPORT_SYMBOL_GPL(pnfs_generic_clear_request_commit);
[PATCH 5.10 123/152] pNFS: Mark layout for return if return-on-close was not sent
From: Trond Myklebust
commit 67bbceedc9bb8ad48993a8bd6486054756d711f4 upstream.
If the layout return-on-close failed because the layoutreturn was never
sent, then we should mark the layout for return again.
Fixes: 9c47b18cf722 ("pNFS: Ensure we do clear the return-on-close layout
stateid on fatal errors")
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman
---
fs/nfs/pnfs.c |6 ++
1 file changed, 6 insertions(+)
--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -1558,12 +1558,18 @@ void pnfs_roc_release(struct nfs4_layout
int ret)
{
struct pnfs_layout_hdr *lo = args->layout;
+ struct inode *inode = args->inode;
const nfs4_stateid *arg_stateid = NULL;
const nfs4_stateid *res_stateid = NULL;
struct nfs4_xdr_opaque_data *ld_private = args->ld_private;
switch (ret) {
case -NFS4ERR_NOMATCHING_LAYOUT:
+ spin_lock(&inode->i_lock);
+ if (pnfs_layout_is_valid(lo) &&
+ nfs4_stateid_match_other(&args->stateid, &lo->plh_stateid))
+ pnfs_set_plh_return_info(lo, args->range.iomode, 0);
+ spin_unlock(&inode->i_lock);
break;
case 0:
if (res->lrs_present)
[PATCH 5.10 124/152] pNFS: Stricter ordering of layoutget and layoutreturn
From: Trond Myklebust
commit 2c8d5fc37fe2384a9bdb6965443ab9224d46f704 upstream.
If a layout return is in progress, we should wait for it to complete,
in case the layout segment we are picking up gets returned too.
Fixes: 30cb3ee299cb ("pNFS: Handle NFS4ERR_OLD_STATEID on layoutreturn by
bumping the state seqid")
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman
---
fs/nfs/pnfs.c | 43 +--
1 file changed, 21 insertions(+), 22 deletions(-)
--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -2019,6 +2019,27 @@ lookup_again:
goto lookup_again;
}
+ /*
+* Because we free lsegs when sending LAYOUTRETURN, we need to wait
+* for LAYOUTRETURN.
+*/
+ if (test_bit(NFS_LAYOUT_RETURN, &lo->plh_flags)) {
+ spin_unlock(&ino->i_lock);
+ dprintk("%s wait for layoutreturn\n", __func__);
+ lseg = ERR_PTR(pnfs_prepare_to_retry_layoutget(lo));
+ if (!IS_ERR(lseg)) {
+ pnfs_put_layout_hdr(lo);
+ dprintk("%s retrying\n", __func__);
+ trace_pnfs_update_layout(ino, pos, count, iomode, lo,
+lseg,
+PNFS_UPDATE_LAYOUT_RETRY);
+ goto lookup_again;
+ }
+ trace_pnfs_update_layout(ino, pos, count, iomode, lo, lseg,
+PNFS_UPDATE_LAYOUT_RETURN);
+ goto out_put_layout_hdr;
+ }
+
lseg = pnfs_find_lseg(lo, &arg, strict_iomode);
if (lseg) {
trace_pnfs_update_layout(ino, pos, count, iomode, lo, lseg,
@@ -2071,28 +2092,6 @@ lookup_again:
nfs4_stateid_copy(&stateid, &lo->plh_stateid);
}
- /*
-* Because we free lsegs before sending LAYOUTRETURN, we need to wait
-* for LAYOUTRETURN even if first is true.
-*/
- if (test_bit(NFS_LAYOUT_RETURN, &lo->plh_flags)) {
- spin_unlock(&ino->i_lock);
- dprintk("%s wait for layoutreturn\n", __func__);
- lseg = ERR_PTR(pnfs_prepare_to_retry_layoutget(lo));
- if (!IS_ERR(lseg)) {
- if (first)
- pnfs_clear_first_layoutget(lo);
- pnfs_put_layout_hdr(lo);
- dprintk("%s retrying\n", __func__);
- trace_pnfs_update_layout(ino, pos, count, iomode, lo,
- lseg, PNFS_UPDATE_LAYOUT_RETRY);
- goto lookup_again;
- }
- trace_pnfs_update_layout(ino, pos, count, iomode, lo, lseg,
- PNFS_UPDATE_LAYOUT_RETURN);
- goto out_put_layout_hdr;
- }
-
if (pnfs_layoutgets_blocked(lo)) {
trace_pnfs_update_layout(ino, pos, count, iomode, lo, lseg,
PNFS_UPDATE_LAYOUT_BLOCKED);
Re: [PATCH] swiotlb: Validate bounce size in the sync/unmap path
On Wed, Jan 13, 2021 at 12:30:17PM +0100, Christoph Hellwig wrote: > On Tue, Jan 12, 2021 at 04:07:29PM +0100, Martin Radev wrote: > > The size of the buffer being bounced is not checked if it happens > > to be larger than the size of the mapped buffer. Because the size > > can be controlled by a device, as it's the case with virtio devices, > > this can lead to memory corruption. > > > > I'm really worried about all these hodge podge hacks for not trusted > hypervisors in the I/O stack. Instead of trying to harden protocols > that are fundamentally not designed for this, how about instead coming > up with a new paravirtualized I/O interface that is specifically > designed for use with an untrusted hypervisor from the start? Your comment makes sense but then that would require the cooperation of these vendors and the cloud providers to agree on something meaningful. I am also not sure whether the end result would be better than hardening this interface to catch corruption. There is already some validation in unmap path anyway. Another possibility is to move this hardening to the common virtio code, but I think the code may become more complicated there since it would require tracking both the dma_addr and length for each descriptor.
[PATCH 5.10 122/152] pNFS: We want return-on-close to complete when evicting the inode
From: Trond Myklebust
commit 078000d02d57f02dde61de4901f289672e98c8bc upstream.
If the inode is being evicted, it should be safe to run return-on-close,
so we should do it to ensure we don't inadvertently leak layout segments.
Fixes: 1c5bd76d17cc ("pNFS: Enable layoutreturn operation for return-on-close")
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman
---
fs/nfs/nfs4proc.c | 26 ++
fs/nfs/pnfs.c |8 +++-
fs/nfs/pnfs.h |8 +++-
3 files changed, 16 insertions(+), 26 deletions(-)
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -3534,10 +3534,8 @@ static void nfs4_close_done(struct rpc_t
trace_nfs4_close(state, &calldata->arg, &calldata->res,
task->tk_status);
/* Handle Layoutreturn errors */
- if (pnfs_roc_done(task, calldata->inode,
- &calldata->arg.lr_args,
- &calldata->res.lr_res,
- &calldata->res.lr_ret) == -EAGAIN)
+ if (pnfs_roc_done(task, &calldata->arg.lr_args, &calldata->res.lr_res,
+ &calldata->res.lr_ret) == -EAGAIN)
goto out_restart;
/* hmm. we are done with the inode, and in the process of freeing
@@ -6379,10 +6377,8 @@ static void nfs4_delegreturn_done(struct
trace_nfs4_delegreturn_exit(&data->args, &data->res, task->tk_status);
/* Handle Layoutreturn errors */
- if (pnfs_roc_done(task, data->inode,
- &data->args.lr_args,
- &data->res.lr_res,
- &data->res.lr_ret) == -EAGAIN)
+ if (pnfs_roc_done(task, &data->args.lr_args, &data->res.lr_res,
+ &data->res.lr_ret) == -EAGAIN)
goto out_restart;
switch (task->tk_status) {
@@ -6436,10 +6432,10 @@ static void nfs4_delegreturn_release(voi
struct nfs4_delegreturndata *data = calldata;
struct inode *inode = data->inode;
+ if (data->lr.roc)
+ pnfs_roc_release(&data->lr.arg, &data->lr.res,
+data->res.lr_ret);
if (inode) {
- if (data->lr.roc)
- pnfs_roc_release(&data->lr.arg, &data->lr.res,
- data->res.lr_ret);
nfs_post_op_update_inode_force_wcc(inode, &data->fattr);
nfs_iput_and_deactive(inode);
}
@@ -6515,16 +6511,14 @@ static int _nfs4_proc_delegreturn(struct
nfs_fattr_init(data->res.fattr);
data->timestamp = jiffies;
data->rpc_status = 0;
- data->lr.roc = pnfs_roc(inode, &data->lr.arg, &data->lr.res, cred);
data->inode = nfs_igrab_and_active(inode);
- if (data->inode) {
+ if (data->inode || issync) {
+ data->lr.roc = pnfs_roc(inode, &data->lr.arg, &data->lr.res,
+ cred);
if (data->lr.roc) {
data->args.lr_args = &data->lr.arg;
data->res.lr_res = &data->lr.res;
}
- } else if (data->lr.roc) {
- pnfs_roc_release(&data->lr.arg, &data->lr.res, 0);
- data->lr.roc = false;
}
task_setup_data.callback_data = data;
--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -1509,10 +1509,8 @@ out_noroc:
return false;
}
-int pnfs_roc_done(struct rpc_task *task, struct inode *inode,
- struct nfs4_layoutreturn_args **argpp,
- struct nfs4_layoutreturn_res **respp,
- int *ret)
+int pnfs_roc_done(struct rpc_task *task, struct nfs4_layoutreturn_args **argpp,
+ struct nfs4_layoutreturn_res **respp, int *ret)
{
struct nfs4_layoutreturn_args *arg = *argpp;
int retval = -EAGAIN;
@@ -1545,7 +1543,7 @@ int pnfs_roc_done(struct rpc_task *task,
return 0;
case -NFS4ERR_OLD_STATEID:
if (!nfs4_layout_refresh_old_stateid(&arg->stateid,
- &arg->range, inode))
+&arg->range, arg->inode))
break;
*ret = -NFS4ERR_NOMATCHING_LAYOUT;
return -EAGAIN;
--- a/fs/nfs/pnfs.h
+++ b/fs/nfs/pnfs.h
@@ -295,10 +295,8 @@ bool pnfs_roc(struct inode *ino,
struct nfs4_layoutreturn_args *args,
struct nfs4_layoutreturn_res *res,
const struct cred *cred);
-int pnfs_roc_done(struct rpc_task *task, struct inode *inode,
- struct nfs4_layoutreturn_args **argpp,
- struct nfs4_layoutreturn_res **respp,
- int *ret);
+int pnfs_roc_done(struct rpc_task *task, struct nfs4_layoutreturn_args **argpp,
+ struct nfs4_layoutreturn_res **respp, int *ret);
void pnfs_roc_release(struct nfs4_layoutreturn_args *args,
struct nfs4
[PATCH 5.10 125/152] NFS: Adjust fs_context error logging
From: Scott Mayhew
commit c98e9daa59a611ff4e163689815f40380c912415 upstream.
Several existing dprink()/dfprintk() calls were converted to use the new
mount API logging macros by commit ce8866f0913f ("NFS: Attach
supplementary error information to fs_context"). If the fs_context was
not created using fsopen() then it will not have had a log buffer
allocated for it, and the new mount API logging macros will wind up
calling printk().
This can result in syslog messages being logged where previously there
were none... most notably "NFS4: Couldn't follow remote path", which can
happen if the client is auto-negotiating a protocol version with an NFS
server that doesn't support the higher v4.x versions.
Convert the nfs_errorf(), nfs_invalf(), and nfs_warnf() macros to check
for the existence of the fs_context's log buffer and call dprintk() if
it doesn't exist. Add nfs_ferrorf(), nfs_finvalf(), and nfs_warnf(),
which do the same thing but take an NFS debug flag as an argument and
call dfprintk(). Finally, modify the "NFS4: Couldn't follow remote
path" message to use nfs_ferrorf().
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207385
Signed-off-by: Scott Mayhew
Reviewed-by: Benjamin Coddington
Fixes: ce8866f0913f ("NFS: Attach supplementary error information to
fs_context.")
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman
---
fs/nfs/internal.h | 26 +++---
fs/nfs/nfs4super.c |4 ++--
2 files changed, 25 insertions(+), 5 deletions(-)
--- a/fs/nfs/internal.h
+++ b/fs/nfs/internal.h
@@ -142,9 +142,29 @@ struct nfs_fs_context {
} clone_data;
};
-#define nfs_errorf(fc, fmt, ...) errorf(fc, fmt, ## __VA_ARGS__)
-#define nfs_invalf(fc, fmt, ...) invalf(fc, fmt, ## __VA_ARGS__)
-#define nfs_warnf(fc, fmt, ...) warnf(fc, fmt, ## __VA_ARGS__)
+#define nfs_errorf(fc, fmt, ...) ((fc)->log.log ? \
+ errorf(fc, fmt, ## __VA_ARGS__) : \
+ ({ dprintk(fmt "\n", ## __VA_ARGS__); }))
+
+#define nfs_ferrorf(fc, fac, fmt, ...) ((fc)->log.log ?\
+ errorf(fc, fmt, ## __VA_ARGS__) : \
+ ({ dfprintk(fac, fmt "\n", ## __VA_ARGS__); }))
+
+#define nfs_invalf(fc, fmt, ...) ((fc)->log.log ? \
+ invalf(fc, fmt, ## __VA_ARGS__) : \
+ ({ dprintk(fmt "\n", ## __VA_ARGS__); -EINVAL; }))
+
+#define nfs_finvalf(fc, fac, fmt, ...) ((fc)->log.log ?\
+ invalf(fc, fmt, ## __VA_ARGS__) : \
+ ({ dfprintk(fac, fmt "\n", ## __VA_ARGS__); -EINVAL; }))
+
+#define nfs_warnf(fc, fmt, ...) ((fc)->log.log ? \
+ warnf(fc, fmt, ## __VA_ARGS__) :\
+ ({ dprintk(fmt "\n", ## __VA_ARGS__); }))
+
+#define nfs_fwarnf(fc, fac, fmt, ...) ((fc)->log.log ? \
+ warnf(fc, fmt, ## __VA_ARGS__) :\
+ ({ dfprintk(fac, fmt "\n", ## __VA_ARGS__); }))
static inline struct nfs_fs_context *nfs_fc2context(const struct fs_context
*fc)
{
--- a/fs/nfs/nfs4super.c
+++ b/fs/nfs/nfs4super.c
@@ -227,7 +227,7 @@ int nfs4_try_get_tree(struct fs_context
fc, ctx->nfs_server.hostname,
ctx->nfs_server.export_path);
if (err) {
- nfs_errorf(fc, "NFS4: Couldn't follow remote path");
+ nfs_ferrorf(fc, MOUNT, "NFS4: Couldn't follow remote path");
dfprintk(MOUNT, "<-- nfs4_try_get_tree() = %d [error]\n", err);
} else {
dfprintk(MOUNT, "<-- nfs4_try_get_tree() = 0\n");
@@ -250,7 +250,7 @@ int nfs4_get_referral_tree(struct fs_con
fc, ctx->nfs_server.hostname,
ctx->nfs_server.export_path);
if (err) {
- nfs_errorf(fc, "NFS4: Couldn't follow remote path");
+ nfs_ferrorf(fc, MOUNT, "NFS4: Couldn't follow remote path");
dfprintk(MOUNT, "<-- nfs4_get_referral_tree() = %d [error]\n",
err);
} else {
dfprintk(MOUNT, "<-- nfs4_get_referral_tree() = 0\n");
[PATCH 5.10 120/152] nvme-tcp: Fix warning with CONFIG_DEBUG_PREEMPT
From: Sagi Grimberg
commit ada831772188192243f9ea437c46e37e97a5975d upstream.
We shouldn't call smp_processor_id() in a preemptible
context, but this is advisory at best, so instead
call __smp_processor_id().
Fixes: db5ad6b7f8cd ("nvme-tcp: try to send request in queue_rq context")
Reported-by: Or Gerlitz
Reported-by: Yi Zhang
Signed-off-by: Sagi Grimberg
Signed-off-by: Christoph Hellwig
Signed-off-by: Greg Kroah-Hartman
---
drivers/nvme/host/tcp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/nvme/host/tcp.c
+++ b/drivers/nvme/host/tcp.c
@@ -286,7 +286,7 @@ static inline void nvme_tcp_queue_reques
* directly, otherwise queue io_work. Also, only do that if we
* are on the same cpu, so we don't introduce contention.
*/
- if (queue->io_cpu == smp_processor_id() &&
+ if (queue->io_cpu == __smp_processor_id() &&
sync && empty && mutex_trylock(&queue->send_mutex)) {
queue->more_requests = !last;
nvme_tcp_send_all(queue);
[PATCH 5.10 102/152] cfg80211: select CONFIG_CRC32
From: Arnd Bergmann
[ Upstream commit 152a8a6c017bfdeda7f6d052fbc6e151891bd9b6 ]
Without crc32 support, this fails to link:
arm-linux-gnueabi-ld: net/wireless/scan.o: in function `cfg80211_scan_6ghz':
scan.c:(.text+0x928): undefined reference to `crc32_le'
Fixes: c8cb5b854b40 ("nl80211/cfg80211: support 6 GHz scanning")
Signed-off-by: Arnd Bergmann
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
---
net/wireless/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 27026f587fa61..f620acd2a0f5e 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -21,6 +21,7 @@ config CFG80211
tristate "cfg80211 - wireless configuration API"
depends on RFKILL || !RFKILL
select FW_LOADER
+ select CRC32
# may need to update this when certificates are changed and are
# using a different algorithm, though right now they shouldn't
# (this is here rather than below to allow it to be a module)
--
2.27.0
Re: [PATCH v2 1/7] acpi: utils: move acpi_lpss_dep() to utils
On Mon, Jan 18, 2021 at 09:24:10AM +0200, Laurent Pinchart wrote: > On Mon, Jan 18, 2021 at 12:34:22AM +, Daniel Scally wrote: ... > > +bool acpi_lpss_dep(struct acpi_device *adev, acpi_handle handle); > > "lpss" stands for low power subsystem, an Intel device within the PCH > that handles I2C, SPI, UART, ... I think the function should be renamed, > as it's now generic. acpi_dev_has_dep() is a potential candidate, I'm > sure better ones exist. A bit of kerneldoc would also not hurt. Actually a good suggestions. Please apply my tag after addressing above. -- With Best Regards, Andy Shevchenko
[PATCH V7 00/10] remoteproc: imx_rproc: support iMX8MQ/M
From: Peng Fan V7: Add R-b tag from Mathieu vdevbuffer->vdev0buffer in patch 1/10, 7/10 correct err msg and shutdown seq per Mathieu's comments in patch 10/10 Hope this version is ok to be merged. V6: Add R-b tag from Mathieu Convert imx-rproc.txt to yaml and add dt-bindings support for i.MX8MQ/M, patch 1/10 2/10 No other changes. V5: Apply on Linux next Add V5 subject prefix Add R-b tag from Bjorn for 1/8, 2/8, 3/8 https://patchwork.kernel.org/project/linux-remoteproc/cover/20201229033019.25899-1-peng@nxp.com/ V4: According to Bjorn's comments, add is_iomem for da to va usage 1/8, 2/8 is new patch 3/8, follow Bjorn's comments to correct/update the err msg. 6/8, new patch 8/8, use dev_err_probe to simplify code, use queue_work instead schedule_delayed_work V3: Since I was quite busy in the past days, V3 is late Rebased on Linux-next Add R-b tags 1/7: Add R-b tag of Mathieu, add comments 4/7: Typo fix 5/7: Add R-b tag of Mathieu, drop index Per Mathieu's comments 6/7: Add R-b tag of Mathieu 7/7: Add comment for vqid << 16, drop unneeded timeout settings of mailbox Use queue_work instead of schedule_delayed_work free mbox channels when remove https://lkml.org/lkml/2020/12/4/82 V2: Rebased on linux-next Dropped early boot feature to make patchset simple. Drop rsc-da https://patchwork.kernel.org/project/linux-remoteproc/cover/20200927064131.24101-1-peng@nxp.com/ V1: https://patchwork.kernel.org/cover/11682461/ This patchset is to support i.MX8MQ/M coproc. The early boot feature was dropped to make the patchset small in V2. Since i.MX specific TCM memory requirement, add elf platform hook. Several patches have got reviewed by Oleksij and Mathieu in v1. Peng Fan (10): dt-bindings: remoteproc: convert imx rproc bindings to json-schema dt-bindings: remoteproc: imx_rproc: add i.MX8MQ/M support remoteproc: introduce is_iomem to rproc_mem_entry remoteproc: add is_iomem to da_to_va remoteproc: imx_rproc: correct err message remoteproc: imx_rproc: use devm_ioremap remoteproc: imx_rproc: add i.MX specific parse fw hook remoteproc: imx_rproc: support i.MX8MQ/M remoteproc: imx_rproc: ignore mapping vdev regions remoteproc: imx_proc: enable virtio/mailbox .../bindings/remoteproc/fsl,imx-rproc.yaml| 108 .../bindings/remoteproc/imx-rproc.txt | 33 --- drivers/remoteproc/imx_rproc.c| 260 +- drivers/remoteproc/ingenic_rproc.c| 2 +- drivers/remoteproc/keystone_remoteproc.c | 2 +- drivers/remoteproc/mtk_scp.c | 6 +- drivers/remoteproc/omap_remoteproc.c | 2 +- drivers/remoteproc/pru_rproc.c| 2 +- drivers/remoteproc/qcom_q6v5_adsp.c | 2 +- drivers/remoteproc/qcom_q6v5_pas.c| 2 +- drivers/remoteproc/qcom_q6v5_wcss.c | 2 +- drivers/remoteproc/qcom_wcnss.c | 2 +- drivers/remoteproc/remoteproc_core.c | 7 +- drivers/remoteproc/remoteproc_coredump.c | 8 +- drivers/remoteproc/remoteproc_debugfs.c | 2 +- drivers/remoteproc/remoteproc_elf_loader.c| 21 +- drivers/remoteproc/remoteproc_internal.h | 2 +- drivers/remoteproc/st_slim_rproc.c| 2 +- drivers/remoteproc/ti_k3_dsp_remoteproc.c | 2 +- drivers/remoteproc/ti_k3_r5_remoteproc.c | 2 +- drivers/remoteproc/wkup_m3_rproc.c| 2 +- include/linux/remoteproc.h| 4 +- 22 files changed, 407 insertions(+), 68 deletions(-) create mode 100644 Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml delete mode 100644 Documentation/devicetree/bindings/remoteproc/imx-rproc.txt -- 2.28.0
[PATCH V7 01/10] dt-bindings: remoteproc: convert imx rproc bindings to json-schema
From: Peng Fan
Convert the imx rproc binding to DT schema format using json-schema.
Signed-off-by: Peng Fan
---
.../bindings/remoteproc/fsl,imx-rproc.yaml| 59 +++
.../bindings/remoteproc/imx-rproc.txt | 33 ---
2 files changed, 59 insertions(+), 33 deletions(-)
create mode 100644
Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
delete mode 100644 Documentation/devicetree/bindings/remoteproc/imx-rproc.txt
diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
new file mode 100644
index ..bce6ccfe1538
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/remoteproc/fsl,imx-rproc.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: NXP iMX6SX/iMX7D Co-Processor Bindings
+
+description:
+ This binding provides support for ARM Cortex M4 Co-processor found on some
NXP iMX SoCs.
+
+maintainers:
+ - Peng Fan
+
+properties:
+ compatible:
+enum:
+ - fsl,imx7d-cm4
+ - fsl,imx6sx-cm4
+
+ clocks:
+description:
+ Clock for co-processor (See ../clock/clock-bindings.txt)
+
+ syscon:
+description:
+ Phandle to syscon block which provide access to System Reset Controller
+
+ memory-region:
+description:
+ list of phandels to the reserved memory regions.
+ (see ../reserved-memory/reserved-memory.txt)
+
+required:
+ - compatible
+ - clocks
+ - syscon
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+m4_reserved_sysmem1: cm4@8000 {
+ reg = <0x8000 0x8>;
+};
+
+m4_reserved_sysmem2: cm4@8100 {
+ reg = <0x8100 0x8>;
+};
+
+imx7d-cm4 {
+ compatible = "fsl,imx7d-cm4";
+ memory-region= <&m4_reserved_sysmem1>, <&m4_reserved_sysmem2>;
+ syscon = <&src>;
+ clocks = <&clks IMX7D_ARM_M4_ROOT_CLK>;
+};
+
+...
diff --git a/Documentation/devicetree/bindings/remoteproc/imx-rproc.txt
b/Documentation/devicetree/bindings/remoteproc/imx-rproc.txt
deleted file mode 100644
index fbcefd965dc4..
--- a/Documentation/devicetree/bindings/remoteproc/imx-rproc.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-NXP iMX6SX/iMX7D Co-Processor Bindings
-
-
-This binding provides support for ARM Cortex M4 Co-processor found on some
-NXP iMX SoCs.
-
-Required properties:
-- compatible Should be one of:
- "fsl,imx7d-cm4"
- "fsl,imx6sx-cm4"
-- clocks Clock for co-processor (See:
../clock/clock-bindings.txt)
-- syscon Phandle to syscon block which provide access to
- System Reset Controller
-
-Optional properties:
-- memory-regionlist of phandels to the reserved memory regions.
- (See: ../reserved-memory/reserved-memory.txt)
-
-Example:
- m4_reserved_sysmem1: cm4@8000 {
- reg = <0x8000 0x8>;
- };
-
- m4_reserved_sysmem2: cm4@8100 {
- reg = <0x8100 0x8>;
- };
-
- imx7d-cm4 {
- compatible = "fsl,imx7d-cm4";
- memory-region = <&m4_reserved_sysmem1>,
<&m4_reserved_sysmem2>;
- syscon = <&src>;
- clocks = <&clks IMX7D_ARM_M4_ROOT_CLK>;
- };
--
2.28.0
[PATCH V7 03/10] remoteproc: introduce is_iomem to rproc_mem_entry
From: Peng Fan
Introduce is_iomem to indicate this piece memory is iomem or not.
Reviewed-by: Bjorn Andersson
Signed-off-by: Peng Fan
Reviewed-by: Mathieu Poirier
---
include/linux/remoteproc.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
index f28ee75d1005..a5f6d2d9cde2 100644
--- a/include/linux/remoteproc.h
+++ b/include/linux/remoteproc.h
@@ -315,6 +315,7 @@ struct rproc;
/**
* struct rproc_mem_entry - memory entry descriptor
* @va:virtual address
+ * @is_iomem: io memory
* @dma: dma address
* @len: length, in bytes
* @da: device address
@@ -329,6 +330,7 @@ struct rproc;
*/
struct rproc_mem_entry {
void *va;
+ bool is_iomem;
dma_addr_t dma;
size_t len;
u32 da;
--
2.28.0
Re: [PATCH 4/6] regulator: Initial commit of sy7636a
On Sat, Jan 16, 2021 at 08:25:37PM -0800, Alistair Francis wrote:
> --- /dev/null
> +++ b/drivers/regulator/sy7636a-regulator.c
> @@ -0,0 +1,233 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Functions to access SY3686A power management chip voltages
> + *
Please make the entire comment a C++ one so things look more
intentional.
> + * Copyright (C) 2019 reMarkable AS - http://www.remarkable.com/
> + *
> + * Author: Lars Ivar Miljeteig
This probably needs an update.
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
This boilerplate is redundant and should be removed.
> +static int get_vcom_voltage_op(struct regulator_dev *rdev)
> +{
> + int ret = get_vcom_voltage_mv(rdev->regmap);
> +
Why is this get_vcom_voltage_mv() function not in the regulator driver,
and why is it not just inline here? It also needs namespacing.
> +static int disable_regulator(struct regulator_dev *rdev)
> +{
> + struct sy7636a *sy7636a = dev_get_drvdata(rdev->dev.parent);
> + int ret = 0;
> +
> + mutex_lock(&sy7636a->reglock);
> + ret = regulator_disable_regmap(rdev);
> + usleep_range(3, 35000);
> + mutex_unlock(&sy7636a->reglock);
Why do you need this delay here, and what purpose is this lock intended
to serve? I can't understand what it's intended to protect.
> + mutex_lock(&sy7636a->reglock);
> + ret = regulator_is_enabled_regmap(rdev);
> + mutex_unlock(&sy7636a->reglock);
This lock usage in particular looks confused.
> + ret = regulator_enable_regmap(rdev);
> + if (ret)
> + goto finish;
> + if (!pwr_good) {
> + dev_err(&rdev->dev, "Power good signal timeout after %u ms\n",
> + jiffies_to_msecs(t1 - t0));
> + ret = -ETIME;
> + goto finish;
> + }
This doesn't undo the underlying enable, leaving the regulator in a
partially enabled state.
> +static const struct regulator_ops sy7636a_vcom_volt_ops = {
> + .get_voltage = get_vcom_voltage_op,
> + .enable = enable_regulator_pgood,
> + .disable = disable_regulator,
> + .is_enabled = sy7636a_regulator_is_enabled,
> +};
The namespacing for functions is very random and prone to clashes.
Given the power good signal I'd also expect a get_status() operation.
> +static int sy7636a_regulator_suspend(struct device *dev)
> +{
> + int ret;
> + struct sy7636a *sy7636a = dev_get_drvdata(dev->parent);
> +
> + ret = get_vcom_voltage_mv(sy7636a->regmap);
> +
> + if (ret > 0)
> + sy7636a->vcom = (unsigned int)ret;
> +
> + return 0;
> +}
What's going on here, and if you are going to store this value over
suspend why not store it in a variable of the correct type? In general
it's surprising to need a suspend operation for a regulator.
> + sy7636a->pgood_gpio = gdp;
> + dev_info(sy7636a->dev,
> + "Power good GPIO registered (gpio# %d)\n",
> + desc_to_gpio(sy7636a->pgood_gpio));
This print is just adding noise to the boot process.
signature.asc
Description: PGP signature
[PATCH v7 00/11] Raspberry Pi PoE HAT fan support
The aim of this series is to add support to the fan found on RPi's PoE HAT. Some commentary on the design can be found below. But the important part to the people CC'd here not involved with PWM is that, in order to achieve this properly, we also have to fix the firmware interface the driver uses to communicate with the PWM bus (and many other low level functions). Specifically, we have to make sure the firmware interface isn't unbound while consumers are still up. So, patch #1 & #2 introduce reference counting in the firmware interface driver and patches #3 to #8 update all firmware users. Patches #9 to #11 introduce the new PWM driver. I sent everything as a single series as the final version of the PWM drivers depends on the firmware fixes, but I'll be happy to split this into two separate series if you think it's better. --- Original cover letter below --- This series aims at adding support to RPi's official PoE HAT fan[1]. The HW setup is the following: | Raspberry Pi | PoE HAT| arm core -> Mailbox -> RPi co-processor -> I2C -> Atmel MCU -> PWM -> FAN The arm cores have only access to the mailbox interface, as i2c0, even if physically accessible, is to be used solely by the co-processor (VideoCore 4/6). This series implements a PWM bus, and has pwm-fan sitting on top of it as per this discussion: https://lkml.org/lkml/2018/9/2/486. Although this design has a series of shortcomings: - It depends on a DT binding: it's not flexible if a new hat shows up with new functionality, we're not 100% sure we'll be able to expand it without breaking backwards compatibility. But without it we can't make use of DT thermal-zones, which IMO is overkill. - We're using pwm-fan, writing a hwmon driver would, again, give us more flexibility, but it's not really needed at the moment. I personally think that it's not worth the effort, it's unlikely we'll get things right in advance. And ultimately, if the RPi people come up with something new, we can always write a new driver/bindings from scratch (as in not reusing previous code). That said, I'm more than happy to change things if there is a consensus that another design will do the trick. [1] https://www.raspberrypi.org/blog/introducing-power-over-ethernet-poe-hat/ --- Changes since v6: - Address PWM driver comments Changes since v5: - Small cleanups - Add extra code comments Changes since v4: - Cleanup devm calls - Rename compatible string so it's unique to the PoE HAT Changes since v3: - Split first patch, #1 introduces refcount, then #2 the devm function - Fix touchscreen function - Use kref Changes since v2: - Introduce devm_rpi_firmware_get() - Small cleanups in PWM driver Changes since v1: - Address PWM driver changes - Fix binding, now with 2 cells Nicolas Saenz Julienne (11): firmware: raspberrypi: Keep count of all consumers firmware: raspberrypi: Introduce devm_rpi_firmware_get() clk: bcm: rpi: Release firmware handle on unbind gpio: raspberrypi-exp: Release firmware handle on unbind reset: raspberrypi: Release firmware handle on unbind soc: bcm: raspberrypi-power: Release firmware handle on unbind staging: vchiq: Release firmware handle on unbind input: raspberrypi-ts: Release firmware handle when not needed dt-bindings: pwm: Add binding for RPi firmware PWM bus DO NOT MERGE: ARM: dts: Add RPi's official PoE hat support pwm: Add Raspberry Pi Firmware based PWM bus .../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 20 ++ arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 54 + drivers/clk/bcm/clk-raspberrypi.c | 2 +- drivers/firmware/raspberrypi.c| 69 +- drivers/gpio/gpio-raspberrypi-exp.c | 2 +- drivers/input/touchscreen/raspberrypi-ts.c| 2 +- drivers/pwm/Kconfig | 9 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm-raspberrypi-poe.c | 220 ++ drivers/reset/reset-raspberrypi.c | 2 +- drivers/soc/bcm/raspberrypi-power.c | 2 +- .../interface/vchiq_arm/vchiq_arm.c | 2 +- .../pwm/raspberrypi,firmware-poe-pwm.h| 13 ++ include/soc/bcm2835/raspberrypi-firmware.h| 10 + 14 files changed, 399 insertions(+), 9 deletions(-) create mode 100644 drivers/pwm/pwm-raspberrypi-poe.c create mode 100644 include/dt-bindings/pwm/raspberrypi,firmware-poe-pwm.h -- 2.29.2
[PATCH V7 06/10] remoteproc: imx_rproc: use devm_ioremap
From: Peng Fan
We might need to map an region multiple times, becaue the region might
be shared between remote processors, such i.MX8QM with dual M4 cores.
So use devm_ioremap, not devm_ioremap_resource.
Reviewed-by: Oleksij Rempel
Reviewed-by: Richard Zhu
Signed-off-by: Peng Fan
Reviewed-by: Mathieu Poirier
---
drivers/remoteproc/imx_rproc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 2a093cea4997..47fc1d06be6a 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -296,7 +296,8 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
if (b >= IMX7D_RPROC_MEM_MAX)
break;
- priv->mem[b].cpu_addr = devm_ioremap_resource(&pdev->dev, &res);
+ /* Not use resource version, because we might share region */
+ priv->mem[b].cpu_addr = devm_ioremap(&pdev->dev, res.start,
resource_size(&res));
if (IS_ERR(priv->mem[b].cpu_addr)) {
dev_err(dev, "failed to remap %pr\n", &res);
err = PTR_ERR(priv->mem[b].cpu_addr);
--
2.28.0
[PATCH v7 04/11] gpio: raspberrypi-exp: Release firmware handle on unbind
Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware interface when unbinding the device. Signed-off-by: Nicolas Saenz Julienne Reviewed-by: Florian Fainelli Acked-by: Bartosz Golaszewski --- drivers/gpio/gpio-raspberrypi-exp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-raspberrypi-exp.c b/drivers/gpio/gpio-raspberrypi-exp.c index bb100e0124e6..64a552ecc2ad 100644 --- a/drivers/gpio/gpio-raspberrypi-exp.c +++ b/drivers/gpio/gpio-raspberrypi-exp.c @@ -208,7 +208,7 @@ static int rpi_exp_gpio_probe(struct platform_device *pdev) return -ENOENT; } - fw = rpi_firmware_get(fw_node); + fw = devm_rpi_firmware_get(&pdev->dev, fw_node); of_node_put(fw_node); if (!fw) return -EPROBE_DEFER; -- 2.29.2
Re: [PATCH v2 2/7] acpi: utils: Add function to fetch dependent acpi_devices
On Mon, Jan 18, 2021 at 12:34:23AM +, Daniel Scally wrote: > In some ACPI tables we encounter, devices use the _DEP method to assert > a dependence on other ACPI devices as opposed to the OpRegions that the > specification intends. We need to be able to find those devices "from" > the dependee, so add a function to parse all ACPI Devices and check if > the include the handle of the dependee device in their _DEP buffer. Fix prefix to be "ACPI / utils: " and rebase on top of function name changes as suggested by Laurent. ... > +/** > + * acpi_dev_get_next_dep_dev - Return next ACPI device dependent on input dev Are you expecting some kind of for_each_*() macro to be added and used? Otherwise there is probably no need to have it "_next_" in the name as it will be a bit confusing. > + * @adev: Pointer to the dependee device > + * @prev: Pointer to the previous dependent device (or NULL for first match) > + * > + * Return the next ACPI device which declares itself dependent on @adev in > + * the _DEP buffer. > + * > + * The caller is responsible to call put_device() on the returned device. > + */ -- With Best Regards, Andy Shevchenko
[PATCH v7 11/11] pwm: Add Raspberry Pi Firmware based PWM bus
Adds support to control the PWM bus available in official Raspberry Pi
PoE HAT. Only RPi's co-processor has access to it, so commands have to
be sent through RPi's firmware mailbox interface.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since v6:
- Use %pe
- Round divisions properly
- Use dev_err_probe()
- Pass check_patch
Changes since v3:
- Rename compatible string to be more explicit WRT to bus's limitations
Changes since v2:
- Use devm_rpi_firmware_get()
- Rename driver
- Small cleanups
Changes since v1:
- Use default pwm bindings and get rid of xlate() function
- Correct spelling errors
- Correct apply() function
- Round values
- Fix divisions in arm32 mode
- Small cleanups
drivers/pwm/Kconfig | 9 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-raspberrypi-poe.c | 220 ++
3 files changed, 230 insertions(+)
create mode 100644 drivers/pwm/pwm-raspberrypi-poe.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 0937e1c047ac..75e2344703b3 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -423,6 +423,15 @@ config PWM_PXA
To compile this driver as a module, choose M here: the module
will be called pwm-pxa.
+config PWM_RASPBERRYPI_POE
+ tristate "Raspberry Pi Firwmware PoE Hat PWM support"
+ # Make sure not 'y' when RASPBERRYPI_FIRMWARE is 'm'. This can only
+ # happen when COMPILE_TEST=y, hence the added !RASPBERRYPI_FIRMWARE.
+ depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST &&
!RASPBERRYPI_FIRMWARE)
+ help
+ Enable Raspberry Pi firmware controller PWM bus used to control the
+ official RPI PoE hat
+
config PWM_RCAR
tristate "Renesas R-Car PWM support"
depends on ARCH_RENESAS || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 18b89d7fd092..ed28d7bd4c64 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
obj-$(CONFIG_PWM_OMAP_DMTIMER) += pwm-omap-dmtimer.o
obj-$(CONFIG_PWM_PCA9685) += pwm-pca9685.o
obj-$(CONFIG_PWM_PXA) += pwm-pxa.o
+obj-$(CONFIG_PWM_RASPBERRYPI_POE) += pwm-raspberrypi-poe.o
obj-$(CONFIG_PWM_RCAR) += pwm-rcar.o
obj-$(CONFIG_PWM_RENESAS_TPU) += pwm-renesas-tpu.o
obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
diff --git a/drivers/pwm/pwm-raspberrypi-poe.c
b/drivers/pwm/pwm-raspberrypi-poe.c
new file mode 100644
index ..ca845e8fabe6
--- /dev/null
+++ b/drivers/pwm/pwm-raspberrypi-poe.c
@@ -0,0 +1,220 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020 Nicolas Saenz Julienne
+ * For more information on Raspberry Pi's PoE hat see:
+ * https://www.raspberrypi.org/products/poe-hat/
+ *
+ * Limitations:
+ * - No disable bit, so a disabled PWM is simulated by duty_cycle 0
+ * - Only normal polarity
+ * - Fixed 12.5 kHz period
+ *
+ * The current period is completed when HW is reconfigured.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define RPI_PWM_MAX_DUTY 255
+#define RPI_PWM_PERIOD_NS 8 /* 12.5 kHz */
+
+#define RPI_PWM_CUR_DUTY_REG 0x0
+#define RPI_PWM_DEF_DUTY_REG 0x1
+
+struct raspberrypi_pwm {
+ struct rpi_firmware *firmware;
+ struct pwm_chip chip;
+ unsigned int duty_cycle;
+};
+
+struct raspberrypi_pwm_prop {
+ __le32 reg;
+ __le32 val;
+ __le32 ret;
+} __packed;
+
+static inline
+struct raspberrypi_pwm *raspberrypi_pwm_from_chip(struct pwm_chip *chip)
+{
+ return container_of(chip, struct raspberrypi_pwm, chip);
+}
+
+static int raspberrypi_pwm_set_property(struct rpi_firmware *firmware,
+ u32 reg, u32 val)
+{
+ struct raspberrypi_pwm_prop msg = {
+ .reg = cpu_to_le32(reg),
+ .val = cpu_to_le32(val),
+ };
+ int ret;
+
+ ret = rpi_firmware_property(firmware, RPI_FIRMWARE_SET_POE_HAT_VAL,
+ &msg, sizeof(msg));
+ if (ret)
+ return ret;
+ if (msg.ret)
+ return -EIO;
+
+ return 0;
+}
+
+static int raspberrypi_pwm_get_property(struct rpi_firmware *firmware,
+ u32 reg, u32 *val)
+{
+ struct raspberrypi_pwm_prop msg = {
+ .reg = reg
+ };
+ int ret;
+
+ ret = rpi_firmware_property(firmware, RPI_FIRMWARE_GET_POE_HAT_VAL,
+ &msg, sizeof(msg));
+ if (ret)
+ return ret;
+ if (msg.ret)
+ return -EIO;
+
+ *val = le32_to_cpu(msg.val);
+
+ return 0;
+}
+
+static void raspberrypi_pwm_get_state(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+ struct raspberrypi_pwm *rpipwm = raspberrypi_pwm_from_chip(
[PATCH V7 08/10] remoteproc: imx_rproc: support i.MX8MQ/M
From: Peng Fan
Add i.MX8MQ dev/sys addr map and configuration data structure
i.MX8MM share i.MX8MQ settings.
Reviewed-by: Richard Zhu
Signed-off-by: Peng Fan
Reviewed-by: Mathieu Poirier
---
drivers/remoteproc/imx_rproc.c | 39 ++
1 file changed, 39 insertions(+)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 5ae1f5209548..fa01e64cc791 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -88,6 +88,34 @@ struct imx_rproc {
struct clk *clk;
};
+static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
+ /* dev addr , sys addr , size , flags */
+ /* TCML - alias */
+ { 0x, 0x007e, 0x0002, 0 },
+ /* OCRAM_S */
+ { 0x0018, 0x0018, 0x8000, 0 },
+ /* OCRAM */
+ { 0x0090, 0x0090, 0x0002, 0 },
+ /* OCRAM */
+ { 0x0092, 0x0092, 0x0002, 0 },
+ /* QSPI Code - alias */
+ { 0x0800, 0x0800, 0x0800, 0 },
+ /* DDR (Code) - alias */
+ { 0x1000, 0x8000, 0x0FFE, 0 },
+ /* TCML */
+ { 0x1FFE, 0x007E, 0x0002, ATT_OWN },
+ /* TCMU */
+ { 0x2000, 0x0080, 0x0002, ATT_OWN },
+ /* OCRAM_S */
+ { 0x2018, 0x0018, 0x8000, ATT_OWN },
+ /* OCRAM */
+ { 0x2020, 0x0090, 0x0002, ATT_OWN },
+ /* OCRAM */
+ { 0x2022, 0x0092, 0x0002, ATT_OWN },
+ /* DDR (Data) */
+ { 0x4000, 0x4000, 0x8000, 0 },
+};
+
static const struct imx_rproc_att imx_rproc_att_imx7d[] = {
/* dev addr , sys addr , size , flags */
/* OCRAM_S (M4 Boot code) - alias */
@@ -138,6 +166,15 @@ static const struct imx_rproc_att imx_rproc_att_imx6sx[] =
{
{ 0x8000, 0x8000, 0x6000, 0 },
};
+static const struct imx_rproc_dcfg imx_rproc_cfg_imx8mq = {
+ .src_reg= IMX7D_SRC_SCR,
+ .src_mask = IMX7D_M4_RST_MASK,
+ .src_start = IMX7D_M4_START,
+ .src_stop = IMX7D_M4_STOP,
+ .att= imx_rproc_att_imx8mq,
+ .att_size = ARRAY_SIZE(imx_rproc_att_imx8mq),
+};
+
static const struct imx_rproc_dcfg imx_rproc_cfg_imx7d = {
.src_reg= IMX7D_SRC_SCR,
.src_mask = IMX7D_M4_RST_MASK,
@@ -496,6 +533,8 @@ static int imx_rproc_remove(struct platform_device *pdev)
static const struct of_device_id imx_rproc_of_match[] = {
{ .compatible = "fsl,imx7d-cm4", .data = &imx_rproc_cfg_imx7d },
{ .compatible = "fsl,imx6sx-cm4", .data = &imx_rproc_cfg_imx6sx },
+ { .compatible = "fsl,imx8mq-cm4", .data = &imx_rproc_cfg_imx8mq },
+ { .compatible = "fsl,imx8mm-cm4", .data = &imx_rproc_cfg_imx8mq },
{},
};
MODULE_DEVICE_TABLE(of, imx_rproc_of_match);
--
2.28.0
[PATCH V7 10/10] remoteproc: imx_proc: enable virtio/mailbox
From: Peng Fan
Use virtio/mailbox to build connection between Remote Proccessors
and Linux. Add work queue to handle incoming messages.
Reviewed-by: Richard Zhu
Signed-off-by: Peng Fan
---
drivers/remoteproc/imx_rproc.c | 116 -
1 file changed, 113 insertions(+), 3 deletions(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 54ac143ba033..c16a91f8e410 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -15,6 +16,9 @@
#include
#include
#include
+#include
+
+#include "remoteproc_internal.h"
#define IMX7D_SRC_SCR 0x0C
#define IMX7D_ENABLE_M4BIT(3)
@@ -86,6 +90,11 @@ struct imx_rproc {
const struct imx_rproc_dcfg *dcfg;
struct imx_rproc_memmem[IMX7D_RPROC_MEM_MAX];
struct clk *clk;
+ struct mbox_client cl;
+ struct mbox_chan*tx_ch;
+ struct mbox_chan*rx_ch;
+ struct work_struct rproc_work;
+ struct workqueue_struct *workqueue;
};
static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
@@ -366,9 +375,33 @@ static int imx_rproc_parse_fw(struct rproc *rproc, const
struct firmware *fw)
return 0;
}
+static void imx_rproc_kick(struct rproc *rproc, int vqid)
+{
+ struct imx_rproc *priv = rproc->priv;
+ int err;
+ __u32 mmsg;
+
+ if (!priv->tx_ch) {
+ dev_err(priv->dev, "No initialized mbox tx channel\n");
+ return;
+ }
+
+ /*
+* Send the index of the triggered virtqueue as the mu payload.
+* Let remote processor know which virtqueue is used.
+*/
+ mmsg = vqid << 16;
+
+ err = mbox_send_message(priv->tx_ch, (void *)&mmsg);
+ if (err < 0)
+ dev_err(priv->dev, "%s: failed (%d, err:%d)\n",
+ __func__, vqid, err);
+}
+
static const struct rproc_ops imx_rproc_ops = {
.start = imx_rproc_start,
.stop = imx_rproc_stop,
+ .kick = imx_rproc_kick,
.da_to_va = imx_rproc_da_to_va,
.load = rproc_elf_load_segments,
.parse_fw = imx_rproc_parse_fw,
@@ -444,6 +477,66 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
return 0;
}
+static void imx_rproc_vq_work(struct work_struct *work)
+{
+ struct imx_rproc *priv = container_of(work, struct imx_rproc,
+ rproc_work);
+
+ rproc_vq_interrupt(priv->rproc, 0);
+ rproc_vq_interrupt(priv->rproc, 1);
+}
+
+static void imx_rproc_rx_callback(struct mbox_client *cl, void *msg)
+{
+ struct rproc *rproc = dev_get_drvdata(cl->dev);
+ struct imx_rproc *priv = rproc->priv;
+
+ queue_work(priv->workqueue, &priv->rproc_work);
+}
+
+static int imx_rproc_xtr_mbox_init(struct rproc *rproc)
+{
+ struct imx_rproc *priv = rproc->priv;
+ struct device *dev = priv->dev;
+ struct mbox_client *cl;
+ int ret;
+
+ if (!of_get_property(dev->of_node, "mbox-names", NULL))
+ return 0;
+
+ cl = &priv->cl;
+ cl->dev = dev;
+ cl->tx_block = true;
+ cl->tx_tout = 100;
+ cl->knows_txdone = false;
+ cl->rx_callback = imx_rproc_rx_callback;
+
+ priv->tx_ch = mbox_request_channel_byname(cl, "tx");
+ if (IS_ERR(priv->tx_ch)) {
+ ret = PTR_ERR(priv->tx_ch);
+ return dev_err_probe(cl->dev, ret,
+"failed to request tx mailbox channel:
%d\n", ret);
+ }
+
+ priv->rx_ch = mbox_request_channel_byname(cl, "rx");
+ if (IS_ERR(priv->rx_ch)) {
+ mbox_free_channel(priv->tx_ch);
+ ret = PTR_ERR(priv->rx_ch);
+ return dev_err_probe(cl->dev, ret,
+"failed to request rx mailbox channel:
%d\n", ret);
+ }
+
+ return 0;
+}
+
+static void imx_rproc_free_mbox(struct rproc *rproc)
+{
+ struct imx_rproc *priv = rproc->priv;
+
+ mbox_free_channel(priv->tx_ch);
+ mbox_free_channel(priv->rx_ch);
+}
+
static int imx_rproc_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -481,18 +574,28 @@ static int imx_rproc_probe(struct platform_device *pdev)
priv->dev = dev;
dev_set_drvdata(dev, rproc);
+ priv->workqueue = create_workqueue(dev_name(dev));
+ if (!priv->workqueue) {
+ dev_err(dev, "cannot create workqueue\n");
+ ret = -ENOMEM;
+ goto err_put_rproc;
+ }
+
+ ret = imx_rproc_xtr_mbox_init(rproc);
+ if (ret)
+ goto err_put_wkq;
ret = imx_rproc_addr_init(priv, pdev);
if (ret
[PATCH 0/3] auxdisplay: ht16k33: Improvement, fix, and json-schema conversion
Hi Robin, Rob, Miguel,
This patch series contains various updates for the Holtek HT16K33 LED
controller with keyscan DT bindings and driver:
1. Make the keypad function optional, from an old patch by Robin that seem to
have fallen through the cracks,
2. Fix the default brightness range,
3. Convert DT bindings to json-schema.
Thanks!
Geert Uytterhoeven (2):
dt-bindings: auxdisplay: ht16k33: Fix default-brightness-level range
dt-bindings: auxdisplay: ht16k33: Convert to json-schema
Robin van der Gracht (1):
dt-bindings: auxdisplay: ht16k33: Keyscan function should be optional
.../bindings/auxdisplay/holtek,ht16k33.yaml | 77 +++
.../devicetree/bindings/display/ht16k33.txt | 40 --
MAINTAINERS | 2 +-
drivers/auxdisplay/ht16k33.c | 14 ++--
4 files changed, 84 insertions(+), 49 deletions(-)
create mode 100644
Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml
delete mode 100644 Documentation/devicetree/bindings/display/ht16k33.txt
--
2.25.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 3/6] devicetree/bindings: Initial commit of silergy,sy7636a-regulator.yaml
On Sat, Jan 16, 2021 at 08:25:36PM -0800, Alistair Francis wrote:
> Initial support for the Silergy SY7636A-regulator Power Management chip
> driver.
Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to identify relevant patches.
Look at what existing commits in the area you're changing are doing and
make sure your subject lines visually resemble what they're doing.
There's no need to resubmit to fix this alone.
> +properties:
> + compatible:
> +enum:
> + - sy7636a-regulator
Compatible strings should be in the form vendor,device.
> +i2c {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +regulator@60 {
> + compatible = "sy7636a-regulator";
> + reg_epdpmic: vcom {
> +regulator-name = "vcom";
> +regulator-boot-on;
> + };
> +};
> +};
There's no documentation of VCOM as a valid regulator in the binding.
signature.asc
Description: PGP signature
Re: linux-next: build warning after merge of the amdgpu tree
On Mon, Jan 18, 2021 at 02:52:18PM +0800, Stephen Rothwell wrote: > Hi Ray, > > On Mon, 18 Jan 2021 05:56:20 + "Huang, Ray" wrote: > > > > [AMD Public Use] > > > > Thanks Setphen. Please check attached V2 patch. > > (If you can share the config file to me, I can do the test in my side) > > It looks good, but I did not try to build it. I have attached the > config (it is just a powerpc allyesconfig). > -- > Cheers, > Stephen Rothwell Thanks Stephen. Ray
YOU HAVE WON
LOTTO.NL, 2391 Beds 152 Koningin Julianaplein 21, Den Haag-Netherlands. (Lotto affiliate with Subscriber Agents). From: Susan Console (Lottery Coordinator) Website: www.lotto.nl Sir/Madam, CONGRATULATIONS!!! We are pleased to inform you of the result of the Lotto NL Winners International programs held on the 16th of January 2021. Your e-mail address attached to ticket #: 00903228100 with prize # 778009/UK drew €1,000,000.00 which was first in the 2nd class of the draws. you are to receive €1,000,000.00 (One Million Euros). Because of mix up in cash pay-outs, we ask that you keep your winning information confidential until your money (€1,000,000.00) has been fully remitted to you by our accredited pay-point bank. This measure must be adhere to avoid loss of your cash prize-winners of our cash prizes are advised to adhere to these instructions to forestall the abuse of this program by other participants. It's important to note that this draws were conducted formally, and winners are selected through an internet ballot system from 60,000 individual and companies e-mail addresses - the draws are conducted around the world through our internet based ballot system. The promotion is sponsored and promoted Lotto NL. We congratulate you once again. We hope you will use part of it in our next draws; the jackpot winning is €85million. Remember, all winning must be claimed not later than 20 days. After this date all unclaimed cash prize will be forfeited and included in the next sweepstake. Please, in order to avoid unnecessary delays and complications remember to quote personal and winning numbers in all correspondence with us. Congratulations once again from all members of Lotto NL. Thank you for being part of our promotional program. To file for the release of your winnings you are advice to contact our Foreign Transfer Manager: MR. WILSON WARREN JOHNSON Tel: +31-620-561-787 Fax: +31-84-438-5342 Email: johnsonwilson...@gmail.com
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:6580 ixgbe_setup_rx_resources() error: we previously assumed 'rx_ring->q_vector' could be null (see line 6550)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: e609571b5ffa3528bf85292de1ceaddac342bc1c
commit: b02e5a0ebb172c8276cea3151942aac681f7a4a6 xsk: Propagate napi_id to XDP
socket Rx path
config: x86_64-randconfig-m001-20210113 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Reported-by: Dan Carpenter
New smatch warnings:
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:6580 ixgbe_setup_rx_resources()
error: we previously assumed 'rx_ring->q_vector' could be null (see line 6550)
vim +6580 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
9247080816297de4 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c John Fastabend
2017-04-24 6540 int ixgbe_setup_rx_resources(struct ixgbe_adapter
*adapter,
9247080816297de4 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c John Fastabend
2017-04-24 6541 struct ixgbe_ring *rx_ring)
9a799d71034c4e2b drivers/net/ixgbe/ixgbe_main.cAuke Kok
2007-09-15 6542 {
b6ec895ecd32c007 drivers/net/ixgbe/ixgbe_main.cAlexander Duyck
2010-11-16 6543struct device *dev = rx_ring->dev;
de88eeeb16b164b6 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Alexander Duyck
2012-02-08 6544int orig_node = dev_to_node(dev);
98fa15f34cb37986 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Anshuman
Khandual2019-03-05 6545int ring_node = NUMA_NO_NODE;
d0bcacd0a130974f drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Björn Töpel
2018-10-02 6546int size;
9a799d71034c4e2b drivers/net/ixgbe/ixgbe_main.cAuke Kok
2007-09-15 6547
3a581073e0f9f396 drivers/net/ixgbe/ixgbe_main.cJesse Brandeburg
2008-08-26 6548size = sizeof(struct ixgbe_rx_buffer) *
rx_ring->count;
de88eeeb16b164b6 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Alexander Duyck
2012-02-08 6549
de88eeeb16b164b6 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Alexander Duyck
2012-02-08 @6550if (rx_ring->q_vector)
^
This code assumes "rx_ring->q_vector" can be NULL
ca8dfe2550cb3682 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Mark Rustad
2014-07-24 6551ring_node =
rx_ring->q_vector->numa_node;
de88eeeb16b164b6 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Alexander Duyck
2012-02-08 6552
ffed21bcee7a544f drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Alexander Duyck
2017-01-17 6553rx_ring->rx_buffer_info = vmalloc_node(size,
ring_node);
1a6c14a2c7c313c5 drivers/net/ixgbe/ixgbe_main.cJesse Brandeburg
2010-02-03 6554if (!rx_ring->rx_buffer_info)
ffed21bcee7a544f drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Alexander Duyck
2017-01-17 6555rx_ring->rx_buffer_info = vmalloc(size);
b6ec895ecd32c007 drivers/net/ixgbe/ixgbe_main.cAlexander Duyck
2010-11-16 6556if (!rx_ring->rx_buffer_info)
b6ec895ecd32c007 drivers/net/ixgbe/ixgbe_main.cAlexander Duyck
2010-11-16 6557goto err;
9a799d71034c4e2b drivers/net/ixgbe/ixgbe_main.cAuke Kok
2007-09-15 6558
9a799d71034c4e2b drivers/net/ixgbe/ixgbe_main.cAuke Kok
2007-09-15 6559/* Round up to nearest 4K */
3a581073e0f9f396 drivers/net/ixgbe/ixgbe_main.cJesse Brandeburg
2008-08-26 6560rx_ring->size = rx_ring->count * sizeof(union
ixgbe_adv_rx_desc);
3a581073e0f9f396 drivers/net/ixgbe/ixgbe_main.cJesse Brandeburg
2008-08-26 6561rx_ring->size = ALIGN(rx_ring->size, 4096);
9a799d71034c4e2b drivers/net/ixgbe/ixgbe_main.cAuke Kok
2007-09-15 6562
ca8dfe2550cb3682 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Mark Rustad
2014-07-24 6563set_dev_node(dev, ring_node);
de88eeeb16b164b6 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Alexander Duyck
2012-02-08 6564rx_ring->desc = dma_alloc_coherent(dev,
de88eeeb16b164b6 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Alexander Duyck
2012-02-08 6565
rx_ring->size,
de88eeeb16b164b6 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Alexander Duyck
2012-02-08 6566
&rx_ring->dma,
de88eeeb16b164b6 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Alexander Duyck
2012-02-08 6567 GFP_KERNEL);
de88eeeb16b164b6 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c Alexander Duyck
2012-02-08
[PATCH 3/3] dt-bindings: auxdisplay: ht16k33: Convert to json-schema
Convert the Holtek HT16K33 LED controller with keyscan Device Tree
binding documentation to json-schema.
Move the file from display to auxdisplay.
Update the example:
- Sort properties in order of documentation,
- Group tuples using angle brackets to improve human readability and
enable automatic validation.
Signed-off-by: Geert Uytterhoeven
---
.../bindings/auxdisplay/holtek,ht16k33.yaml | 77 +++
.../devicetree/bindings/display/ht16k33.txt | 43 ---
MAINTAINERS | 2 +-
3 files changed, 78 insertions(+), 44 deletions(-)
create mode 100644
Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml
delete mode 100644 Documentation/devicetree/bindings/display/ht16k33.txt
diff --git a/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml
b/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml
new file mode 100644
index ..64460026040f
--- /dev/null
+++ b/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml
@@ -0,0 +1,77 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/auxdisplay/holtek,ht16k33.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Holtek HT16K33 RAM mapping 16*8 LED controller with keyscan
+
+maintainers:
+ - Robin van der Gracht
+
+allOf:
+ - $ref: "/schemas/input/matrix-keymap.yaml#"
+
+properties:
+ compatible:
+const: holtek,ht16k33
+
+ reg:
+maxItems: 1
+
+ refresh-rate-hz:
+maxItems: 1
+description: Display update interval in Hertz
+
+ interrupts:
+maxItems: 1
+
+ debounce-delay-ms:
+maxItems: 1
+description: Debouncing interval time in milliseconds
+
+ linux,keymap: true
+
+ linux,no-autorepeat:
+description: Disable keyrepeat
+
+ default-brightness-level:
+minimum: 1
+maximum: 16
+default: 16
+description: Initial brightness level
+
+required:
+ - compatible
+ - reg
+ - refresh-rate-hz
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+i2c1 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+ht16k33: ht16k33@70 {
+compatible = "holtek,ht16k33";
+reg = <0x70>;
+refresh-rate-hz = <20>;
+interrupt-parent = <&gpio4>;
+interrupts = <5 (IRQ_TYPE_LEVEL_HIGH |
IRQ_TYPE_EDGE_RISING)>;
+debounce-delay-ms = <50>;
+linux,keymap = ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ;
+};
+ };
diff --git a/Documentation/devicetree/bindings/display/ht16k33.txt
b/Documentation/devicetree/bindings/display/ht16k33.txt
deleted file mode 100644
index ec43776970164921..
--- a/Documentation/devicetree/bindings/display/ht16k33.txt
+++ /dev/null
@@ -1,43 +0,0 @@
-Holtek ht16k33 RAM mapping 16*8 LED controller driver with keyscan
-
-Required properties:
-- compatible: "holtek,ht16k33"
-- reg: I2C slave address of the chip.
-- refresh-rate-hz: Display update interval in HZ.
-
-Optional properties:
-- linux,no-autorepeat: Disable keyrepeat.
-- default-brightness-level: Initial brightness level [1-16] (default: 16).
-
-- Keypad
- Supply the 'interrupts' property to enable the keyscan feature.
- - interrupts: Interrupt specification for the key pressed interrupt.
- - debounce-delay-ms: Debouncing interval time in milliseconds.
- - linux,keymap: The keymap for keys as described in the binding
- document (devicetree/bindings/input/matrix-keymap.txt).
-
-Example:
-
-&i2c1 {
- ht16k33: ht16k33@70 {
- compatible = "holtek,ht16k33";
- reg = <0x70>;
- refresh-rate-hz = <20>;
- debounce-delay-ms = <50>;
- interrupt-parent = <&gpio4>;
- interrupts = <5 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>;
- linux,keymap = <
- MATRIX_KEY(2, 0, KEY_F6)
- MATRIX_KEY(3, 0, KEY_F8)
- MATRIX_KEY(4, 0, KEY_F10)
- MATRIX_KEY(5, 0, KEY_F4)
- MATRIX_KEY(6, 0, KEY_F2)
- MATRIX_KEY(2, 1, KEY_F5)
- MATRIX_KEY(3, 1, KEY_F7)
- MATRIX_KEY(4, 1, KEY_F9)
- MATRIX_KEY(5, 1, KEY_F3)
- MATRIX_KEY(6, 1, KEY_F1)
- >;
- };
-};
diff --git a/MAINTAINERS b/MAINTAINERS
index
[PATCH 1/3] dt-bindings: auxdisplay: ht16k33: Keyscan function should be optional
From: Robin van der Gracht
Keyscan should be optional to support simple LED matrix displays (output
only).
Reported-by: Michael Kaplan
Signed-off-by: Robin van der Gracht
[geert: Rebased]
Signed-off-by: Geert Uytterhoeven
---
.../devicetree/bindings/display/ht16k33.txt| 11 +++
drivers/auxdisplay/ht16k33.c | 14 ++
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/ht16k33.txt
b/Documentation/devicetree/bindings/display/ht16k33.txt
index d5a8b070b46779a4..3d602f5b9eb6bb74 100644
--- a/Documentation/devicetree/bindings/display/ht16k33.txt
+++ b/Documentation/devicetree/bindings/display/ht16k33.txt
@@ -4,16 +4,19 @@ Holtek ht16k33 RAM mapping 16*8 LED controller driver with
keyscan
Required properties:
- compatible: "holtek,ht16k33"
- reg: I2C slave address of the chip.
-- interrupts: Interrupt specification for the key pressed interrupt.
- refresh-rate-hz: Display update interval in HZ.
-- debounce-delay-ms: Debouncing interval time in milliseconds.
-- linux,keymap:The keymap for keys as described in the binding
- document (devicetree/bindings/input/matrix-keymap.txt).
Optional properties:
- linux,no-autorepeat: Disable keyrepeat.
- default-brightness-level: Initial brightness level [0-15] (default: 15).
+- Keypad
+ Supply the 'interrupts' property to enable the keyscan feature.
+ - interrupts: Interrupt specification for the key pressed interrupt.
+ - debounce-delay-ms: Debouncing interval time in milliseconds.
+ - linux,keymap: The keymap for keys as described in the binding
+ document (devicetree/bindings/input/matrix-keymap.txt).
+
Example:
&i2c1 {
diff --git a/drivers/auxdisplay/ht16k33.c b/drivers/auxdisplay/ht16k33.c
index d951d54b26f5239b..444f3b1019e3d425 100644
--- a/drivers/auxdisplay/ht16k33.c
+++ b/drivers/auxdisplay/ht16k33.c
@@ -402,11 +402,6 @@ static int ht16k33_probe(struct i2c_client *client,
return -EIO;
}
- if (client->irq <= 0) {
- dev_err(&client->dev, "No IRQ specified\n");
- return -EINVAL;
- }
-
priv = devm_kzalloc(&client->dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
@@ -459,9 +454,12 @@ static int ht16k33_probe(struct i2c_client *client,
if (err)
goto err_fbdev_info;
- err = ht16k33_keypad_probe(client, &priv->keypad);
- if (err)
- goto err_fbdev_unregister;
+ /* Keypad */
+ if (client->irq > 0) {
+ err = ht16k33_keypad_probe(client, &priv->keypad);
+ if (err)
+ goto err_fbdev_unregister;
+ }
/* Backlight */
memset(&bl_props, 0, sizeof(struct backlight_properties));
--
2.25.1
Re: [PATCH bpf-next] xsk: build skb by page
From: Xuan Zhuo
Date: Sat, 16 Jan 2021 10:44:53 +0800
> This patch is used to construct skb based on page to save memory copy
> overhead.
>
> This has one problem:
>
> We construct the skb by fill the data page as a frag into the skb. In
> this way, the linear space is empty, and the header information is also
> in the frag, not in the linear space, which is not allowed for some
> network cards. For example, Mellanox Technologies MT27710 Family
> [ConnectX-4 Lx] will get the following error message:
>
> mlx5_core :3b:00.1 eth1: Error cqe on cqn 0x817, ci 0x8, qn 0x1dbb,
> opcode 0xd, syndrome 0x1, vendor syndrome 0x68
> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0030: 00 00 00 00 60 10 68 01 0a 00 1d bb 00 0f 9f d2
> WQE DUMP: WQ size 1024 WQ cur size 0, WQE index 0xf, len: 64
> : 00 00 0f 0a 00 1d bb 03 00 00 00 08 00 00 00 00
> 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0020: 00 00 00 2b 00 08 00 00 00 00 00 05 9e e3 08 00
> 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> mlx5_core :3b:00.1 eth1: ERR CQE on SQ: 0x1dbb
>
> I also tried to use build_skb to construct skb, but because of the
> existence of skb_shinfo, it must be behind the linear space, so this
> method is not working. We can't put skb_shinfo on desc->addr, it will be
> exposed to users, this is not safe.
>
> Finally, I added a feature NETIF_F_SKB_NO_LINEAR to identify whether the
> network card supports the header information of the packet in the frag
> and not in the linear space.
>
> Performance Testing
>
> The test environment is Aliyun ECS server.
> Test cmd:
> ```
> xdpsock -i eth0 -t -S -s
> ```
>
> Test result data:
>
> size64 512 10241500
> copy1916747 1775988 1600203 1440054
> page1974058 1953655 1945463 1904478
> percent 3.0%10.0% 21.58% 32.3%
>
> Signed-off-by: Xuan Zhuo
> Reviewed-by: Dust Li
> ---
> drivers/net/virtio_net.c| 2 +-
> include/linux/netdev_features.h | 5 +-
> net/ethtool/common.c| 1 +
> net/xdp/xsk.c | 108
> +---
> 4 files changed, 97 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 4ecccb8..841a331 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -2985,7 +2985,7 @@ static int virtnet_probe(struct virtio_device *vdev)
> /* Set up network device as normal. */
> dev->priv_flags |= IFF_UNICAST_FLT | IFF_LIVE_ADDR_CHANGE;
> dev->netdev_ops = &virtnet_netdev;
> - dev->features = NETIF_F_HIGHDMA;
> + dev->features = NETIF_F_HIGHDMA | NETIF_F_SKB_NO_LINEAR;
>
> dev->ethtool_ops = &virtnet_ethtool_ops;
> SET_NETDEV_DEV(dev, &vdev->dev);
> diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
> index 934de56..8dd28e2 100644
> --- a/include/linux/netdev_features.h
> +++ b/include/linux/netdev_features.h
> @@ -85,9 +85,11 @@ enum {
>
> NETIF_F_HW_MACSEC_BIT, /* Offload MACsec operations */
>
> + NETIF_F_SKB_NO_LINEAR_BIT, /* Allow skb linear is empty */
> +
> /*
>* Add your fresh new feature above and remember to update
> - * netdev_features_strings[] in net/core/ethtool.c and maybe
> + * netdev_features_strings[] in net/ethtool/common.c and maybe
>* some feature mask #defines below. Please also describe it
>* in Documentation/networking/netdev-features.rst.
>*/
> @@ -157,6 +159,7 @@ enum {
> #define NETIF_F_GRO_FRAGLIST __NETIF_F(GRO_FRAGLIST)
> #define NETIF_F_GSO_FRAGLIST __NETIF_F(GSO_FRAGLIST)
> #define NETIF_F_HW_MACSEC__NETIF_F(HW_MACSEC)
> +#define NETIF_F_SKB_NO_LINEAR__NETIF_F(SKB_NO_LINEAR)
>
> /* Finds the next feature with the highest number of the range of start till
> 0.
> */
> diff --git a/net/ethtool/common.c b/net/ethtool/common.c
> index 24036e3..2f3d309 100644
> --- a/net/ethtool/common.c
> +++ b/net/ethtool/common.c
> @@ -68,6 +68,7 @@
> [NETIF_F_HW_TLS_RX_BIT] ="tls-hw-rx-offload",
> [NETIF_F_GRO_FRAGLIST_BIT] = "rx-gro-list",
> [NETIF_F_HW_MACSEC_BIT] ="macsec-hw-offload",
> + [NETIF_F_SKB_NO_LINEAR_BIT] ="skb-no-linear",
> };
>
> const char
I think the best would be if you will split this patch into three:
- the first one will introduce NETI_F_SKB_NO_LINEAR;
- the second will add this feature to virtio_net;
- the third will do the rest.
Also, it would be nice if you'll mention (in the cover letter or
in the third patch) that in order to get a nice boost on non-ZC
XSK xmit developers can add a support for completely non-linear
skbs and advertise this new feature in their drivers. I think
there'll
[PATCH v6 2/6] mfd: ahc1ec0: Add Advantech EC include file used by dt-bindings
This files defines the sud-device types and hwmon profiles support by Advantech embedded controller. Signed-off-by: Campion Kang --- include/dt-bindings/mfd/ahc1ec0-dt.h | 25 + 1 file changed, 25 insertions(+) create mode 100644 include/dt-bindings/mfd/ahc1ec0-dt.h diff --git a/include/dt-bindings/mfd/ahc1ec0-dt.h b/include/dt-bindings/mfd/ahc1ec0-dt.h new file mode 100644 index ..389a7a7f8f02 --- /dev/null +++ b/include/dt-bindings/mfd/ahc1ec0-dt.h @@ -0,0 +1,25 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Device Tree defines for Advantech Embedded Controller (AHC1EC0) + */ + +#ifndef _DT_BINDINGS_MFD_AHC1EC0_H +#define _DT_BINDINGS_MFD_AHC1EC0_H + +/* Sub-device Definitions */ +#define AHC1EC0_SUBDEV_BRIGHTNESS 0x0 +#define AHC1EC0_SUBDEV_EEPROM 0x1 +#define AHC1EC0_SUBDEV_GPIO 0x2 +#define AHC1EC0_SUBDEV_HWMON 0x3 +#define AHC1EC0_SUBDEV_LED0x4 +#define AHC1EC0_SUBDEV_WDT0x5 + +/* HWMON Profile Definitions */ +#define AHC1EC0_HWMON_PRO_TEMPLATE 0x0 +#define AHC1EC0_HWMON_PRO_TPC5XXX 0x1 +#define AHC1EC0_HWMON_PRO_PRVR40x2 +#define AHC1EC0_HWMON_PRO_UNO2271G 0x3 +#define AHC1EC0_HWMON_PRO_UNO1172A 0x4 +#define AHC1EC0_HWMON_PRO_UNO1372G 0x5 + +#endif /* _DT_BINDINGS_MFD_AHC1EC0_H */ -- 2.17.1
[PATCH v6 5/6] hwmon: ahc1ec0-hwmon: Add sub-device hwmon for Advantech embedded controller
This is one of sub-device driver for Advantech embedded controller
AHC1EC0. This driver provides sysfs ABI for Advantech related
applications to monitor the system status.
Changed since V5:
- remove unnecessary header files
- Using [devm_]hwmon_device_register_with_info() to register
hwmon driver based on reviewer's suggestion
Signed-off-by: Campion Kang
---
drivers/hwmon/Kconfig | 10 +
drivers/hwmon/Makefile| 1 +
drivers/hwmon/ahc1ec0-hwmon.c | 660 ++
3 files changed, 671 insertions(+)
create mode 100644 drivers/hwmon/ahc1ec0-hwmon.c
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 1ecf697d8d99..bfa007026679 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -2139,6 +2139,16 @@ config SENSORS_INTEL_M10_BMC_HWMON
sensors monitor various telemetry data of different components on the
card, e.g. board temperature, FPGA core temperature/voltage/current.
+config SENSORS_AHC1EC0_HWMON
+ tristate "Advantech AHC1EC0 Hardware Monitor Function"
+ depends on MFD_AHC1EC0
+ help
+ This driver provide support for the hardware monitoring functionality
+ for Advantech AHC1EC0 embedded controller on the board.
+
+ This driver provides the sysfs attributes for applications to monitor
+ the system status, including system temperatures, voltages, current.
+
if ACPI
comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 09a86c5e1d29..0c37747e8c4f 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_SENSORS_ADT7411) += adt7411.o
obj-$(CONFIG_SENSORS_ADT7462) += adt7462.o
obj-$(CONFIG_SENSORS_ADT7470) += adt7470.o
obj-$(CONFIG_SENSORS_ADT7475) += adt7475.o
+obj-$(CONFIG_SENSORS_AHC1EC0_HWMON)+= ahc1ec0-hwmon.o
obj-$(CONFIG_SENSORS_AMD_ENERGY) += amd_energy.o
obj-$(CONFIG_SENSORS_APPLESMC) += applesmc.o
obj-$(CONFIG_SENSORS_ARM_SCMI) += scmi-hwmon.o
diff --git a/drivers/hwmon/ahc1ec0-hwmon.c b/drivers/hwmon/ahc1ec0-hwmon.c
new file mode 100644
index ..688f07e6a6e0
--- /dev/null
+++ b/drivers/hwmon/ahc1ec0-hwmon.c
@@ -0,0 +1,660 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * HWMON Driver for Advantech Embedded Controller chip AHC1EC0
+ *
+ * Copyright 2020, Advantech IIoT Group
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct ec_hwmon_attrs {
+ const char *name;
+ umode_t mode;
+ int (*read)(struct device *dev, long *val);
+};
+
+struct adv_hwmon_profile {
+ int offset;
+ unsigned long resolution, resolution_vin, resolution_sys,
resolution_curr, resolution_power;
+ unsigned long r1, r1_vin, r1_sys, r1_curr, r1_power;
+ unsigned long r2, r2_vin, r2_sys, r2_curr, r2_power;
+ int hwmon_in_list_cnt;
+ int temp_list_cnt;
+ int *hwmon_in_list;
+ int *temp_list;
+};
+
+struct ec_hwmon_data {
+ struct device *dev;
+ struct device *hwmon_dev;
+ struct adv_ec_platform_data *adv_ec_data;
+ unsigned long temperature[3];
+ unsigned long ec_current[5];
+ unsigned long power[5];
+ unsigned long voltage[7];
+
+ struct ec_hw_pin_table pin_tbl;
+ struct ec_smbuso_em0 ec_smboem0;
+ struct adv_hwmon_profile *profile;
+};
+
+static int get_ec_in_vbat_input(struct device *dev, long *val);
+static int get_ec_in_v5_input(struct device *dev, long *val);
+static int get_ec_in_v12_input(struct device *dev, long *val);
+static int get_ec_in_vcore_input(struct device *dev, long *val);
+static int get_ec_current1_input(struct device *dev, long *val);
+static int get_ec_cpu_temp(struct device *dev, long *val);
+static int get_ec_sys_temp(struct device *dev, long *val);
+
+const struct ec_hwmon_attrs ec_hwmon_in_attr_template[] = {
+ {"VBAT",0444, get_ec_in_vbat_input},// in1
+ {"5VSB",0444, get_ec_in_v5_input}, // in2
+ {"Vin", 0444, get_ec_in_v12_input}, // in3 (== in8)
+ {"VCORE", 0444, get_ec_in_vcore_input}, // in4
+ {"Vin1",0444, NULL},// in5
+ {"Vin2",0444, NULL},// in6
+ {"System Voltage", 0444, NULL}, // in7
+ {"Current", 0444, get_ec_current1_input},
+};
+
+const struct ec_hwmon_attrs ec_temp_attrs_template[] = {
+ {"CPU Temp",0444, get_ec_cpu_temp},
+ {"System Temp", 0444, get_ec_sys_temp},
+};
+
+enum ec_hwmon_in_type {
+ EC_HWMON_IN_VBAT,
+ EC_HWMON_IN_5VSB,
+ EC_HWMON_IN_12V,
+ EC_HWMON_IN_VCORE,
+ EC_HWMON_IN_VIN1,
+ EC_HWMON_IN_VIN2,
+ EC_HWMON_IN_SYS_VOL,
+ EC_HWMON_IN_CURRENT,
+};
+
+enum ec_temp_type {
+ EC_TEMP_CPU,
+ EC_TEMP_SYS,
+};
+
+static int hwmon_in_list_0[] = {
+ EC_HWMON_IN_VBAT,
+ EC_HWMON_IN_5VSB,
+
[PATCH v6 1/6] MAINTAINERS: Add Advantech AHC1EC0 embedded controller entry
Add Advantech AHC1EC0 embedded controller entry Changed since V5: - add include/linux/mfd/ahc1ec0.h Signed-off-by: Campion Kang --- MAINTAINERS | 11 +++ 1 file changed, 11 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 00836f6452f0..e1ccdaadb5ee 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -562,6 +562,17 @@ S: Maintained F: Documentation/scsi/advansys.rst F: drivers/scsi/advansys.c +ADVANTECH AHC1EC0 EMBEDDED CONTROLLER DRIVER +M: Campion Kang +L: linux-kernel@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/mfd/ahc1ec0.yaml +F: drivers/hwmon/ahc1ec0-hwmon.c +F: drivers/mfd/ahc1ec0.c +F: drivers/watchdog/ahc1ec0-wdt.c +F: include/dt-bindings/mfd/ahc1ec0-dt.h +F: include/linux/mfd/ahc1ec0.h + ADXL34X THREE-AXIS DIGITAL ACCELEROMETER DRIVER (ADXL345/ADXL346) M: Michael Hennerich S: Supported -- 2.17.1
[PATCH v6 3/6] dt-bindings: mfd: ahc1ec0.yaml: Add Advantech embedded controller - AHC1EC0
Add DT binding schema for Advantech embedded controller AHC1EC0.
Changed since V5:
- rename dt-bindings/mfd/ahc1ec0.h to dt-bindings/mfd/ahc1ec0-dt.h
that found errors by bot 'make dt_binding_check'
Signed-off-by: Campion Kang
---
.../devicetree/bindings/mfd/ahc1ec0.yaml | 69 +++
1 file changed, 69 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/ahc1ec0.yaml
diff --git a/Documentation/devicetree/bindings/mfd/ahc1ec0.yaml
b/Documentation/devicetree/bindings/mfd/ahc1ec0.yaml
new file mode 100644
index ..40af14bb9c0a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ahc1ec0.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/ahc1ec0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Advantech Embedded Controller (AHC1EC0)
+
+maintainers:
+ - Campion Kang
+
+description: |
+ AHC1EC0 is one of the embedded controllers used by Advantech to provide
several
+ functions such as watchdog, hwmon, brightness, etc. Advantech related
applications
+ can control the whole system via these functions.
+
+properties:
+ compatible:
+const: advantech,ahc1ec0
+
+ advantech,sub-dev-nb:
+description:
+ The number of sub-devices specified in the platform.
+$ref: /schemas/types.yaml#/definitions/uint32
+maxItems: 1
+
+ advantech,sub-dev:
+description:
+ A list of the sub-devices supported in the platform. Defines for the
+ appropriate values can found in dt-bindings/mfd/ahc1ec0-dt.h.
+$ref: "/schemas/types.yaml#/definitions/uint32-array"
+minItems: 1
+maxItems: 6
+
+ advantech,hwmon-profile:
+description:
+ The number of sub-devices specified in the platform. Defines for the
+ hwmon profiles can found in dt-bindings/mfd/ahc1ec0-dt.
+$ref: /schemas/types.yaml#/definitions/uint32
+maxItems: 1
+
+required:
+ - compatible
+ - advantech,sub-dev-nb
+ - advantech,sub-dev
+
+if:
+ properties:
+advantech,sub-dev:
+ contains:
+const: 0x3
+then:
+ required:
+- advantech,hwmon-profile
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+ahc1ec0 {
+compatible = "advantech,ahc1ec0";
+
+advantech,sub-dev-nb = <2>;
+advantech,sub-dev = ;
+
+advantech,hwmon-profile = ;
+};
--
2.17.1
[PATCH v6 6/6] watchdog: ahc1ec0-wdt: Add sub-device watchdog for Advantech embedded controller
This is one of sub-device driver for Advantech embedded controller
AHC1EC0. This driver provide watchdog functionality for Advantech
related applications to restart the system.
Changed since V5:
- remove unnecessary header files
- bug fixed: reboot halt if watchdog enabled
- Kconfig: add "AHC1EC0" string to clearly define the EC name
Signed-off-by: Campion Kang
---
drivers/watchdog/Kconfig | 11 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/ahc1ec0-wdt.c | 261 +
3 files changed, 273 insertions(+)
create mode 100644 drivers/watchdog/ahc1ec0-wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 7ff941e71b79..1a27836883ac 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1636,6 +1636,17 @@ config NIC7018_WDT
To compile this driver as a module, choose M here: the module will be
called nic7018_wdt.
+config AHC1EC0_WDT
+ tristate "Advantech AHC1EC0 Watchdog Function"
+ depends on MFD_AHC1EC0
+ help
+ This is sub-device for Advantech AHC1EC0 embedded controller.
+
+ This driver provide watchdog functionality for Advantech related
+ applications to restart the system.
+ To compile thie driver as a module, choose M here: the module will be
+ called ahc1ec0-wdt.
+
# M68K Architecture
config M54xx_WATCHDOG
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 5c74ee19d441..7190811b1e50 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -145,6 +145,7 @@ obj-$(CONFIG_INTEL_MID_WATCHDOG) += intel-mid_wdt.o
obj-$(CONFIG_INTEL_MEI_WDT) += mei_wdt.o
obj-$(CONFIG_NI903X_WDT) += ni903x_wdt.o
obj-$(CONFIG_NIC7018_WDT) += nic7018_wdt.o
+obj-$(CONFIG_AHC1EC0_WDT) += ahc1ec0-wdt.o
obj-$(CONFIG_MLX_WDT) += mlx_wdt.o
# M68K Architecture
diff --git a/drivers/watchdog/ahc1ec0-wdt.c b/drivers/watchdog/ahc1ec0-wdt.c
new file mode 100644
index ..4497b6106b24
--- /dev/null
+++ b/drivers/watchdog/ahc1ec0-wdt.c
@@ -0,0 +1,261 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Watchdog Driver for Advantech Embedded Controller chip AHC1EC0
+ *
+ * Copyright 2020, Advantech IIoT Group
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "ahc1ec0-wdt"
+
+struct ec_wdt_data {
+ struct watchdog_device wdtdev;
+ struct adv_ec_platform_data *adv_ec_data;
+ struct notifier_block reboot_nb;
+ struct mutex lock_ioctl;
+ int is_enable;
+ int current_timeout;
+};
+
+#define EC_WDT_MIN_TIMEOUT 1 /* The watchdog devices minimum timeout value
(in seconds). */
+#define EC_WDT_MAX_TIMEOUT 600 /* The watchdog devices maximum timeout value
(in seconds) */
+#define EC_WDT_DEFAULT_TIMEOUT 45
+
+static int set_delay(struct adv_ec_platform_data *adv_ec_data, unsigned short
delay_timeout_in_ms)
+{
+ if (write_hw_ram(adv_ec_data, EC_RESET_DELAY_TIME_L,
delay_timeout_in_ms & 0x00FF)) {
+ pr_err("Failed to set Watchdog Retset Time Low byte.");
+ return -EINVAL;
+ }
+
+ if (write_hw_ram(adv_ec_data, EC_RESET_DELAY_TIME_H,
(delay_timeout_in_ms & 0xFF00) >> 8)) {
+ pr_err("Failed to set Watchdog Retset Time Hight byte.");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int advwdt_set_heartbeat(unsigned long t)
+{
+ if (t < 1 || t > 6553) {
+ pr_err("%s: the input timeout is out of range.", __func__);
+ pr_err("Please choose valid data between 1 ~ 6553.");
+ return -EINVAL;
+ }
+
+ return (t * 10);
+}
+
+/* Notifier for system down */
+static int advwdt_notify_sys(struct notifier_block *nb, unsigned long code,
void *data)
+{
+ if (code == SYS_DOWN || code == SYS_HALT) {
+ struct ec_wdt_data *ec_wdt_data;
+
+ ec_wdt_data = container_of(nb, struct ec_wdt_data, reboot_nb);
+ if (!ec_wdt_data)
+ return NOTIFY_BAD;
+
+ /* Turn the WDT off */
+ if (write_hwram_command(ec_wdt_data->adv_ec_data, EC_WDT_STOP))
{
+ pr_err("Failed to set Watchdog stop.");
+ return -EINVAL;
+ }
+ ec_wdt_data->is_enable = 0;
+ pr_info("%s: notify sys shutdown", __func__);
+ }
+
+ return NOTIFY_DONE;
+}
+
+static int ec_wdt_start(struct watchdog_device *wdd)
+{
+ int ret;
+ int timeout, timeout_in_ms;
+ struct ec_wdt_data *ec_wdt_data = watchdog_get_drvdata(wdd);
+ struct adv_ec_platform_data *adv_ec_data;
+
+ dev_dbg(wdd->parent, "%s\n", __func__);
+
+ adv_ec_data = ec_wdt_data->adv_ec_data;
+ timeout = wdd->timeout; /* The watchdog devices timeout value (in
seconds). */
+
+ mutex_lock(&ec_wdt_data->lock_ioctl);
+
+
Re: [PATCH v2 3/7] i2c: i2c-core-base: Use format macro in i2c_dev_set_name()
On Mon, Jan 18, 2021 at 12:34:24AM +, Daniel Scally wrote:
> Some places in the kernel allow users to map resources to a device
> using device name (for example, gpiod_lookup_table). Currently
"...in the struct gpiod_lookup_table)." ?
> this involves waiting for the i2c_client to have been registered so we
I²C client ?
> can use dev_name(&client->dev). We want to add a function to allow users
> to refer to an i2c device by name before it has been instantiated, so
I²C device ?
> create a macro for the format that's accessible outside the i2c layer
I²C layer ?
> and use it in i2c_dev_set_name()
Period at the end.
For the record, I do not like wrapping below to 80 limit and agree with
Wolfram.
Reviewed-by: Andy Shevchenko
> Suggested-by: Andy Shevchenko
> Signed-off-by: Daniel Scally
> ---
> - Used format macro in i2c_dev_set_name() instead of sub func
>
> drivers/i2c/i2c-core-base.c | 4 ++--
> include/linux/i2c.h | 3 +++
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> index 63ebf722a424..547b8926cac8 100644
> --- a/drivers/i2c/i2c-core-base.c
> +++ b/drivers/i2c/i2c-core-base.c
> @@ -811,12 +811,12 @@ static void i2c_dev_set_name(struct i2c_adapter *adap,
> struct acpi_device *adev = ACPI_COMPANION(&client->dev);
>
> if (info && info->dev_name) {
> - dev_set_name(&client->dev, "i2c-%s", info->dev_name);
> + dev_set_name(&client->dev, I2C_DEV_NAME_FORMAT, info->dev_name);
> return;
> }
>
> if (adev) {
> - dev_set_name(&client->dev, "i2c-%s", acpi_dev_name(adev));
> + dev_set_name(&client->dev, I2C_DEV_NAME_FORMAT,
> acpi_dev_name(adev));
> return;
> }
>
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index 56622658b215..4d40a4b46810 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -39,6 +39,9 @@ enum i2c_slave_event;
> typedef int (*i2c_slave_cb_t)(struct i2c_client *client,
> enum i2c_slave_event event, u8 *val);
>
> +/* I2C Device Name Format - to maintain consistency outside the i2c layer */
> +#define I2C_DEV_NAME_FORMAT "i2c-%s"
> +
> /* I2C Frequency Modes */
> #define I2C_MAX_STANDARD_MODE_FREQ 10
> #define I2C_MAX_FAST_MODE_FREQ 40
> --
> 2.25.1
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v4 2/3] iommu/iova: Avoid double-negatives in magazine helpers
On Mon, Jan 18, 2021 at 10:55:52AM +, John Garry wrote: > On 18/01/2021 10:08, Jean-Philippe Brucker wrote: > > > > Any idea why that's happening? This fix seems ok but if we're expecting > > > > allocation failures for the loaded magazine then we could easily get it > > > > for cpu_rcaches too, and get a similar abort at runtime. > > > It's not specifically that we expect them (allocation failures for the > > > loaded magazine), rather we should make safe against it. > > > > > > So could you be more specific in your concern for the cpu_rcache failure? > > > cpu_rcache magazine assignment comes from this logic. > > If this fails: > > > > drivers/iommu/iova.c:847: rcache->cpu_rcaches = > > __alloc_percpu(sizeof(*cpu_rcache), cache_line_size()); > > > > then we'll get an Oops in __iova_rcache_get(). So if we're making the > > module safer against magazine allocation failure, shouldn't we also > > protect against cpu_rcaches allocation failure? > > Ah, gotcha. So we have the WARN there, but that's not much use as this would > still crash, as you say. > > So maybe we can embed the cpu rcaches in iova_domain struct, to avoid the > separate (failable) cpu rcache allocation. > > Alternatively, we could add NULL checks __iova_rcache_get() et al for this > allocation failure but that's not preferable as it's fastpath. > > Finally so we could pass back an error code from init_iova_rcache() to its > only caller, init_iova_domain(); but that has multiple callers and would > need to be fixed up. > > Not sure which is best or on other options. I would have initially gone with option 2 which seems the simplest, but I don't have a setup to measure that overhead Thanks, Jean
Re: [PATCH v5] pgo: add clang's Profile Guided Optimization infrastructure
On Mon, Jan 18, 2021 at 3:32 AM Bill Wendling wrote: > > On Sun, Jan 17, 2021 at 4:27 PM Sedat Dilek wrote: > > > > [ big snip ] > > [More snippage.] > > > [ CC Fangrui ] > > > > With the attached... > > > >[PATCH v3] module: Ignore _GLOBAL_OFFSET_TABLE_ when warning for > > undefined symbols > > > > ...I was finally able to boot into a rebuild PGO-optimized Linux-kernel. > > For details see ClangBuiltLinux issue #1250 "Unknown symbol > > _GLOBAL_OFFSET_TABLE_ loading kernel modules". > > > Thanks for confirming that this works with the above patch. > > > @ Bill Nick Sami Nathan > > > > 1, Can you say something of the impact passing "LLVM_IAS=1" to make? > > The integrated assembler and this option are more-or-less orthogonal > to each other. One can still use the GNU assembler with PGO. If you're > having an issue, it may be related to ClangBuiltLinux issue #1250. > > > 2. Can you please try Nick's DWARF v5 support patchset v5 and > > CONFIG_DEBUG_INFO_DWARF5=y (see attachments)? > > > I know Nick did several tests with PGO. He may have looked into it > already, but we can check. > Reproducible. LLVM_IAS=1 + DWARF5 = Not bootable I will try: LLVM_IAS=1 + DWARF4 - Sedat - > > I would like to know what the impact of the Clang's Integrated > > Assembler and DWARF v5 are. > > > > I dropped both means... > > > > 1. Do not pass "LLVM_IAS=1" to make. > > 2. Use default DWARF v2 (with Nick's patchset: CONFIG_DEBUG_INFO_DWARF2=y). > > > > ...for a successfull build and boot on bare metal. > > > > [Next message] > > > On each rebuild I need to pass to make ...? > > > > LLVM=1 -fprofile-use=vmlinux.profdata > > > Yes. > > > Did you try together with passing LLVM_IAS=1 to make? > > One of my tests was with the integrated assembler enabled. Are you > finding issues with it? > > The problem with using top-of-tree clang is that it's not necessarily > stable. You could try using the clang 11.x release (changing the > "CLANG_VERSION >= 12" in kernel/pgo/Kconfig/ to "CLANG_VERSION >= > 11"). > > -bw
Re: [PATCH V2] mm/compaction: correct deferral logic for proactive compaction
Thanks Vlasitmil!!
On 1/18/2021 6:07 PM, Vlastimil Babka wrote:
> On 1/18/21 1:20 PM, Charan Teja Reddy wrote:
>> should_proactive_compact_node() returns true when sum of the
>> weighted fragmentation score of all the zones in the node is greater
>> than the wmark_high of compaction, which then triggers the proactive
>> compaction that operates on the individual zones of the node. But
>> proactive compaction runs on the zone only when its weighted
>> fragmentation score is greater than wmark_low(=wmark_high - 10).
>>
>> This means that the sum of the weighted fragmentation scores of all the
>> zones can exceed the wmark_high but individual weighted fragmentation
>> zone scores can still be less than wmark_low which makes the unnecessary
>> trigger of the proactive compaction only to return doing nothing.
>>
>> Issue with the return of proactive compaction with out even trying is
>> its deferral. It is simply deferred for 1 << COMPACT_MAX_DEFER_SHIFT if
>> the scores across the proactive compaction is same, thinking that
>> compaction didn't make any progress but in reality it didn't even try.
>> With the delay between successive retries for proactive compaction is
>> 500msec, it can result into the deferral for ~30sec with out even trying
>> the proactive compaction.
>>
>> Test scenario is that: compaction_proactiveness=50 thus the wmark_low =
>> 50 and wmark_high = 60. System have 2 zones(Normal and Movable) with
>> sizes 5GB and 6GB respectively. After opening some apps on the android,
>> the weighted fragmentation scores of these zones are 47 and 49
>> respectively. Since the sum of these fragmentation scores are above the
>> wmark_high which triggers the proactive compaction and there since the
>> individual zones weighted fragmentation scores are below wmark_low, it
>> returns without trying the proactive compaction. As a result the
>> weighted fragmentation scores of the zones are still 47 and 49 which
>> makes the existing logic to defer the compaction thinking that
>> noprogress is made across the compaction.
>>
>> Fix this by checking just zone fragmentation score, not the weighted, in
>> __compact_finished() and use the zones weighted fragmentation score in
>> fragmentation_score_node(). In the test case above, If the weighted
>> average of is above wmark_high, then individual score (not adjusted) of
>> atleast one zone has to be above wmark_high. Thus it avoids the
>> unnecessary trigger and deferrals of the proactive compaction.
>>
>> Fix-suggested-by: Vlastimil Babka
>> Signed-off-by: Charan Teja Reddy
>
> Acked-by: Vlastimil Babka
>
> But I would move fragmentation_score_zone() above
> fragmentation_score_zone_weighted(), so fragmentation_score_zone_weighted()
> can
> call fragmentation_score_zone() instead of having two places with
> extfrag_for_order(...).
Yes, this suggestion makes the code cleaner. I will raise V3 for this.
Thanks.
>
> Thanks.
>
>> ---
>>
>> Changes in V2: Addressed comments from vlastimil
>>
>> Changes in V1: https://lore.kernel.org/patchwork/patch/1364646/
>>
>> mm/compaction.c | 19 ++-
>> 1 file changed, 14 insertions(+), 5 deletions(-)
>>
>> diff --git a/mm/compaction.c b/mm/compaction.c
>> index e5acb97..1b98427 100644
>> --- a/mm/compaction.c
>> +++ b/mm/compaction.c
>> @@ -1924,16 +1924,16 @@ static bool kswapd_is_running(pg_data_t *pgdat)
>> }
>>
>> /*
>> - * A zone's fragmentation score is the external fragmentation wrt to the
>> - * COMPACTION_HPAGE_ORDER scaled by the zone's size. It returns a value
>> - * in the range [0, 100].
>> + * A weighted zone's fragmentation score is the external fragmentation
>> + * wrt to the COMPACTION_HPAGE_ORDER scaled by the zone's size. It
>> + * returns a value in the range [0, 100].
>> *
>> * The scaling factor ensures that proactive compaction focuses on larger
>> * zones like ZONE_NORMAL, rather than smaller, specialized zones like
>> * ZONE_DMA32. For smaller zones, the score value remains close to zero,
>> * and thus never exceeds the high threshold for proactive compaction.
>> */
>> -static unsigned int fragmentation_score_zone(struct zone *zone)
>> +static unsigned int fragmentation_score_zone_weighted(struct zone *zone)
>> {
>> unsigned long score;
>>
>> @@ -1943,6 +1943,15 @@ static unsigned int fragmentation_score_zone(struct
>> zone *zone)
>> }
>>
>> /*
>> + * A zone's fragmentation score is the external fragmentation wrt to the
>> + * COMPACTION_HPAGE_ORDER. It returns a value in the range [0, 100].
>> + */
>> +static unsigned int fragmentation_score_zone(struct zone *zone)
>> +{
>> +return extfrag_for_order(zone, COMPACTION_HPAGE_ORDER);
>> +}
>> +
>> +/*
>> * The per-node proactive (background) compaction process is started by its
>> * corresponding kcompactd thread when the node's fragmentation score
>> * exceeds the high threshold. The compaction process remains active till
>> @@ -1958,7 +1967,7 @@ static unsigned int fragmentation_score_node(pg
[PATCH v4 1/2] dt-bindings: power: Add bindings document for Charger support on MT6360 PMIC
From: Gene Chen
Add bindings document for Charger support on MT6360 PMIC
Signed-off-by: Gene Chen
Reviewed-by: Rob Herring
---
.../bindings/power/supply/mt6360_charger.yaml | 48 ++
1 file changed, 48 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power/supply/mt6360_charger.yaml
diff --git a/Documentation/devicetree/bindings/power/supply/mt6360_charger.yaml
b/Documentation/devicetree/bindings/power/supply/mt6360_charger.yaml
new file mode 100644
index 000..b89b15a
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/mt6360_charger.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/mt6360_charger.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Battery charger driver for MT6360 PMIC from MediaTek Integrated.
+
+maintainers:
+ - Gene Chen
+
+description: |
+ This module is part of the MT6360 MFD device.
+ Provides Battery Charger, Boost for OTG devices and BC1.2 detection.
+
+properties:
+ compatible:
+const: mediatek,mt6360-chg
+
+ richtek,vinovp-microvolt:
+description: Maximum CHGIN regulation voltage in uV.
+enum: [ 550, 650, 1100, 1450 ]
+
+
+ usb-otg-vbus-regulator:
+type: object
+description: OTG boost regulator.
+$ref: /schemas/regulator/regulator.yaml#
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+mt6360_charger: charger {
+ compatible = "mediatek,mt6360-chg";
+ richtek,vinovp-microvolt = <1450>;
+
+ otg_vbus_regulator: usb-otg-vbus-regulator {
+regulator-compatible = "usb-otg-vbus";
+regulator-name = "usb-otg-vbus";
+regulator-min-microvolt = <4425000>;
+regulator-max-microvolt = <5825000>;
+ };
+};
+...
--
2.7.4
[PATCH v4 0/2] power: supply: mt6360_charger: add MT6360 charger support
This patch series add MT6360 Charger support contains driver and binding document Gene Chen (2) dt-bindings: power: Add bindings document for Charger support on MT6360 PMIC power: supply: mt6360_charger: add MT6360 charger support Documentation/devicetree/bindings/power/supply/mt6360_charger.yaml | 48 drivers/power/supply/Kconfig | 10 drivers/power/supply/Makefile |1 drivers/power/supply/mt6360_charger.c | 914 ++ 4 files changed, 973 insertions(+) changelogs between v1 & v2 - Add binding property with unit and custom name prefix - Remove extcon device, redundant brackets and interrupts - Fix power supply prop "charger type" changelogs between v2 & v3 - Add register selector to value mapping changelogs between v3 & v4 - move pdata vinovp to mt6360_chg_info - remove unuse sysfs attribute - refactor debug log and warning - add power supply prop input voltage limit
[PATCH v4 2/2] power: supply: mt6360_charger: add MT6360 charger support
From: Gene Chen Add basic support for the battery charger for MT6360 PMIC Signed-off-by: Gene Chen --- drivers/power/supply/Kconfig | 10 + drivers/power/supply/Makefile | 1 + drivers/power/supply/mt6360_charger.c | 914 ++ 3 files changed, 925 insertions(+) create mode 100644 drivers/power/supply/mt6360_charger.c diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig index eec646c..dd63bed 100644 --- a/drivers/power/supply/Kconfig +++ b/drivers/power/supply/Kconfig @@ -567,6 +567,16 @@ config CHARGER_MP2629 Battery charger. This driver provides Battery charger power management functions on the systems. +config CHARGER_MT6360 + tristate "Mediatek MT6360 Charger Driver" + depends on MFD_MT6360 + depends on REGULATOR + help + Say Y here to enable MT6360 Charger Part. + The device supports High-Accuracy Voltage/Current Regulation, + Average Input Current Regulation, Battery Tempature Sensing, + Over-Temperature Protection, DPDM Detection for BC1.2 + config CHARGER_QCOM_SMBB tristate "Qualcomm Switch-Mode Battery Charger and Boost" depends on MFD_SPMI_PMIC || COMPILE_TEST diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile index dd4b863..9bd0804 100644 --- a/drivers/power/supply/Makefile +++ b/drivers/power/supply/Makefile @@ -77,6 +77,7 @@ obj-$(CONFIG_CHARGER_MAX77693)+= max77693_charger.o obj-$(CONFIG_CHARGER_MAX8997) += max8997_charger.o obj-$(CONFIG_CHARGER_MAX8998) += max8998_charger.o obj-$(CONFIG_CHARGER_MP2629) += mp2629_charger.o +obj-$(CONFIG_CHARGER_MT6360) += mt6360_charger.o obj-$(CONFIG_CHARGER_QCOM_SMBB)+= qcom_smbb.o obj-$(CONFIG_CHARGER_BQ2415X) += bq2415x_charger.o obj-$(CONFIG_CHARGER_BQ24190) += bq24190_charger.o diff --git a/drivers/power/supply/mt6360_charger.c b/drivers/power/supply/mt6360_charger.c new file mode 100644 index 000..d80bdad --- /dev/null +++ b/drivers/power/supply/mt6360_charger.c @@ -0,0 +1,914 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2021 MediaTek Inc. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define MT6360_PMU_CHG_CTRL1 0x311 +#define MT6360_PMU_CHG_CTRL2 0x312 +#define MT6360_PMU_CHG_CTRL3 0x313 +#define MT6360_PMU_CHG_CTRL4 0x314 +#define MT6360_PMU_CHG_CTRL5 0x315 +#define MT6360_PMU_CHG_CTRL6 0x316 +#define MT6360_PMU_CHG_CTRL7 0x317 +#define MT6360_PMU_CHG_CTRL8 0x318 +#define MT6360_PMU_CHG_CTRL9 0x319 +#define MT6360_PMU_CHG_CTRL10 0x31A +#define MT6360_PMU_DEVICE_TYPE 0x322 +#define MT6360_PMU_USB_STATUS1 0x327 +#define MT6360_PMU_CHG_STAT0x34A +#define MT6360_PMU_CHG_CTRL19 0x361 +#define MT6360_PMU_FOD_STAT0x3E7 + +/* MT6360_PMU_CHG_CTRL1 */ +#define MT6360_FSLP_SHFT (3) +#define MT6360_FSLP_MASK BIT(MT6360_FSLP_SHFT) +#define MT6360_OPA_MODE_SHFT (0) +#define MT6360_OPA_MODE_MASK BIT(MT6360_OPA_MODE_SHFT) +/* MT6360_PMU_CHG_CTRL2 */ +#define MT6360_IINLMTSEL_SHFT (2) +#define MT6360_IINLMTSEL_MASK GENMASK(3, 2) +/* MT6360_PMU_CHG_CTRL3 */ +#define MT6360_IAICR_SHFT (2) +#define MT6360_IAICR_MASK GENMASK(7, 2) +#define MT6360_ILIM_EN_MASKBIT(0) +/* MT6360_PMU_CHG_CTRL4 */ +#define MT6360_VOREG_SHFT (1) +#define MT6360_VOREG_MASK GENMASK(7, 1) +/* MT6360_PMU_CHG_CTRL5 */ +#define MT6360_VOBST_MASK GENMASK(7, 2) +/* MT6360_PMU_CHG_CTRL6 */ +#define MT6360_VMIVR_SHFT (1) +#define MT6360_VMIVR_MASK GENMASK(7, 1) +/* MT6360_PMU_CHG_CTRL7 */ +#define MT6360_ICHG_SHFT (2) +#define MT6360_ICHG_MASK GENMASK(7, 2) +/* MT6360_PMU_CHG_CTRL8 */ +#define MT6360_IPREC_SHFT (0) +#define MT6360_IPREC_MASK GENMASK(3, 0) +/* MT6360_PMU_CHG_CTRL9 */ +#define MT6360_IEOC_SHFT (4) +#define MT6360_IEOC_MASK GENMASK(7, 4) +/* MT6360_PMU_CHG_CTRL10 */ +#define MT6360_OTG_OC_MASK GENMASK(3, 0) +/* MT6360_PMU_DEVICE_TYPE */ +#define MT6360_USBCHGEN_MASK BIT(7) +/* MT6360_PMU_USB_STATUS1 */ +#define MT6360_USB_STATUS_SHFT (4) +#define MT6360_USB_STATUS_MASK GENMASK(6, 4) +/* MT6360_PMU_CHG_STAT */ +#define MT6360_CHG_STAT_SHFT (6) +#define MT6360_CHG_STAT_MASK GENMASK(7, 6) +#define MT6360_VBAT_LVL_MASK BIT(5) +/* MT6360_PMU_CHG_CTRL19 */ +#define MT6360_VINOVP_SHFT (5) +#define MT6360_VINOVP_MASK GENMASK(6, 5) +/* MT6360_PMU_FOD_STAT */ +#define MT6360_CHRDET_EXT_MASK BIT(4) + +/* uV */ +#define MT6360_VMIVR_MIN 390 +#define MT6360_VMIVR_MAX 1340 +#define MT6360_VMIVR_STEP 10 +/* uA */ +#define MT6360_ICHG_MIN10 +#define MT6360_ICHG_MAX500 +#define MT6360_ICHG_STEP 10 +/* uV */ +#define MT6360_VOREG_MIN 390 +#define MT6360_VOREG_MAX 471 +#define MT6360_VOREG_STEP 1 +/* uA */ +#define MT6360_AICR_MIN1000
Re: WARNING in io_disable_sqo_submit
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an
issue:
INFO: task hung in io_sq_thread_stop
INFO: task kworker/u4:0:8 blocked for more than 143 seconds.
Not tainted 5.11.0-rc1-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:kworker/u4:0state:D stack:24056 pid:8 ppid: 2 flags:0x4000
Workqueue: events_unbound io_ring_exit_work
Call Trace:
context_switch kernel/sched/core.c:4313 [inline]
__schedule+0x90c/0x21a0 kernel/sched/core.c:5064
schedule+0xcf/0x270 kernel/sched/core.c:5143
schedule_timeout+0x1d8/0x250 kernel/time/timer.c:1854
do_wait_for_common kernel/sched/completion.c:85 [inline]
__wait_for_common kernel/sched/completion.c:106 [inline]
wait_for_common kernel/sched/completion.c:117 [inline]
wait_for_completion+0x163/0x260 kernel/sched/completion.c:138
kthread_park+0x122/0x1b0 kernel/kthread.c:557
io_sq_thread_park fs/io_uring.c:7445 [inline]
io_sq_thread_park fs/io_uring.c:7439 [inline]
io_sq_thread_stop+0xfe/0x570 fs/io_uring.c:7463
io_finish_async fs/io_uring.c:7481 [inline]
io_ring_ctx_free fs/io_uring.c:8646 [inline]
io_ring_exit_work+0x62/0x6d0 fs/io_uring.c:8739
process_one_work+0x98d/0x15f0 kernel/workqueue.c:2275
worker_thread+0x64c/0x1120 kernel/workqueue.c:2421
kthread+0x3b1/0x4a0 kernel/kthread.c:292
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
Showing all locks held in the system:
3 locks held by kworker/u4:0/8:
#0: 888010069138 ((wq_completion)events_unbound){+.+.}-{0:0}, at:
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
#0: 888010069138 ((wq_completion)events_unbound){+.+.}-{0:0}, at:
atomic64_set include/asm-generic/atomic-instrumented.h:856 [inline]
#0: 888010069138 ((wq_completion)events_unbound){+.+.}-{0:0}, at:
atomic_long_set include/asm-generic/atomic-long.h:41 [inline]
#0: 888010069138 ((wq_completion)events_unbound){+.+.}-{0:0}, at:
set_work_data kernel/workqueue.c:616 [inline]
#0: 888010069138 ((wq_completion)events_unbound){+.+.}-{0:0}, at:
set_work_pool_and_clear_pending kernel/workqueue.c:643 [inline]
#0: 888010069138 ((wq_completion)events_unbound){+.+.}-{0:0}, at:
process_one_work+0x871/0x15f0 kernel/workqueue.c:2246
#1: c9cd7da8 ((work_completion)(&ctx->exit_work)){+.+.}-{0:0}, at:
process_one_work+0x8a5/0x15f0 kernel/workqueue.c:2250
#2: 88801bfd4870 (&sqd->lock){+.+.}-{3:3}, at: io_sq_thread_park
fs/io_uring.c:7444 [inline]
#2: 88801bfd4870 (&sqd->lock){+.+.}-{3:3}, at: io_sq_thread_park
fs/io_uring.c:7439 [inline]
#2: 88801bfd4870 (&sqd->lock){+.+.}-{3:3}, at:
io_sq_thread_stop+0xd6/0x570 fs/io_uring.c:7463
1 lock held by khungtaskd/1647:
#0: 8b373aa0 (rcu_read_lock){}-{1:2}, at:
debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:6254
1 lock held by in:imklog/8164:
#0: 8880151b8870 (&f->f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100
fs/file.c:947
2 locks held by kworker/u4:6/8415:
2 locks held by kworker/0:4/8690:
#0: 88801007c538 ((wq_completion)rcu_gp){+.+.}-{0:0}, at:
arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
#0: 88801007c538 ((wq_completion)rcu_gp){+.+.}-{0:0}, at: atomic64_set
include/asm-generic/atomic-instrumented.h:856 [inline]
#0: 88801007c538 ((wq_completion)rcu_gp){+.+.}-{0:0}, at: atomic_long_set
include/asm-generic/atomic-long.h:41 [inline]
#0: 88801007c538 ((wq_completion)rcu_gp){+.+.}-{0:0}, at: set_work_data
kernel/workqueue.c:616 [inline]
#0: 88801007c538 ((wq_completion)rcu_gp){+.+.}-{0:0}, at:
set_work_pool_and_clear_pending kernel/workqueue.c:643 [inline]
#0: 88801007c538 ((wq_completion)rcu_gp){+.+.}-{0:0}, at:
process_one_work+0x871/0x15f0 kernel/workqueue.c:2246
#1: c9000288fda8 ((work_completion)(&rew.rew_work)){+.+.}-{0:0}, at:
process_one_work+0x8a5/0x15f0 kernel/workqueue.c:2250
1 lock held by syz-executor.3/8865:
#0: 888146ddcd88 (&xt[i].mutex){+.+.}-{3:3}, at:
xt_find_table_lock+0x41/0x540 net/netfilter/x_tables.c:1206
1 lock held by syz-executor.2/8867:
#0: 888146ddcd88 (&xt[i].mutex){+.+.}-{3:3}, at:
xt_find_table_lock+0x41/0x540 net/netfilter/x_tables.c:1206
2 locks held by syz-executor.5/8869:
#0: 888146ddcd88 (&xt[i].mutex){+.+.}-{3:3}, at:
xt_find_table_lock+0x41/0x540 net/netfilter/x_tables.c:1206
#1: 8b37c368 (rcu_state.exp_mutex){+.+.}-{3:3}, at: exp_funnel_lock
kernel/rcu/tree_exp.h:290 [inline]
#1: 8b37c368 (rcu_state.exp_mutex){+.+.}-{3:3}, at:
synchronize_rcu_expedited+0x4f2/0x610 kernel/rcu/tree_exp.h:836
1 lock held by syz-executor.4/8870:
#0: 888146ddcd88 (&xt[i].mutex){+.+.}-{3:3}, at:
xt_find_table_lock+0x41/0x540 net/netfilter/x_tables.c:1206
1 lock held by syz-executor.0/8872:
#0: 888146ddcd88 (&xt[i].mutex){+.+.}-{3:3}, at:
xt_find_table_lock+0x41/0x540 net/netfilter/x_tables.c:1206
1 lock held by syz-executor.1/8873:
#0: 888146ddcd88 (&xt[i].mutex){+.+.}-{
