Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding
On 9/10/20 3:11 PM, Jason Gunthorpe wrote: On Thu, Sep 10, 2020 at 02:22:37PM -0700, John Hubbard wrote: Or am I way off here, and it really is possible (aside from the current s390 situation) to observe something that "is no longer a page table"? Yes, that is the issue. Remember there is no locking for GUP fast. While a page table cannot be freed there is nothing preventing the page table entry from being concurrently modified. OK, then we are saying the same thing after all, good. Without the stack variable it looks like this: pud_t pud = READ_ONCE(*pudp); if (!pud_present(pud)) return pmd_offset(pudp, address); And pmd_offset() expands to return (pmd_t *)pud_page_vaddr(*pud) + pmd_index(address); Between the READ_ONCE(*pudp) and (*pud) inside pmd_offset() the value of *pud can change, eg to !pud_present. Then pud_page_vaddr(*pud) will crash. It is not use after free, it is using data that has not been validated. Right, that matches what I had in mind, too: you can still have a problem even though you're in the same page table. I just wanted to confirm that there's not some odd way to launch out into completely non-page-table memory. thanks, -- John Hubbard NVIDIA
Re: [PATCH net-next 0/6] Fix some kernel-doc warnings for hns
From: Wang Hai Date: Thu, 10 Sep 2020 22:56:14 +0800 > Fix some kernel-doc warnings for hns. Series applied to net-next, thanks.
Re: [PATCH] net: mvpp2: ptp: Fix unused variables
From: Alex Dewar
Date: Thu, 10 Sep 2020 14:49:10 +0100
> In the functions mvpp2_isr_handle_xlg() and
> mvpp2_isr_handle_gmac_internal(), the bool variable link is assigned a
> true value in the case that a given bit of val is set. However, if the
> bit is unset, no value is assigned to link and it is then passed to
> mvpp2_isr_handle_link() without being initialised. Fix by assigning to
> link the value of the bit test.
>
> Build-tested on x86.
>
> Fixes: 36cfd3a6e52b ("net: mvpp2: restructure "link status" interrupt
> handling")
> Signed-off-by: Alex Dewar
Applied to net-next.
Re: [PATCH net-next] net: cxgb3: Fix some kernel-doc warnings
From: Wang Hai Date: Thu, 10 Sep 2020 21:36:16 +0800 > Fixes the following W=1 kernel build warning(s): > > drivers/net/ethernet/chelsio/cxgb3/t3_hw.c:2209: warning: Excess function > parameter 'adapter' description in 'clear_sge_ctxt' > drivers/net/ethernet/chelsio/cxgb3/t3_hw.c:2975: warning: Excess function > parameter 'adapter' description in 't3_set_proto_sram' > > Reported-by: Hulk Robot > Signed-off-by: Wang Hai Applied.
Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding
On Thu, Sep 10, 2020 at 02:22:37PM -0700, John Hubbard wrote: > Or am I way off here, and it really is possible (aside from the current > s390 situation) to observe something that "is no longer a page table"? Yes, that is the issue. Remember there is no locking for GUP fast. While a page table cannot be freed there is nothing preventing the page table entry from being concurrently modified. Without the stack variable it looks like this: pud_t pud = READ_ONCE(*pudp); if (!pud_present(pud)) return pmd_offset(pudp, address); And pmd_offset() expands to return (pmd_t *)pud_page_vaddr(*pud) + pmd_index(address); Between the READ_ONCE(*pudp) and (*pud) inside pmd_offset() the value of *pud can change, eg to !pud_present. Then pud_page_vaddr(*pud) will crash. It is not use after free, it is using data that has not been validated. Jason
Re: [PATCH v4 5/5] iommu/vt-d: Add is_aux_domain support
On Tue, 1 Sep 2020 11:34:22 +0800
Lu Baolu wrote:
> With subdevice information opt-in through iommu_ops.aux_at(de)tach_dev()
> interfaces, the vendor iommu driver is able to learn the knowledge about
> the relationships between the subdevices and the aux-domains. Implement
> is_aux_domain() support based on the relationship knowledges.
>
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel/iommu.c | 125 ++--
> include/linux/intel-iommu.h | 17 +++--
> 2 files changed, 103 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> index 3c12fd06856c..50431c7b2e71 100644
> --- a/drivers/iommu/intel/iommu.c
> +++ b/drivers/iommu/intel/iommu.c
> @@ -334,6 +334,8 @@ static int intel_iommu_attach_device(struct iommu_domain
> *domain,
>struct device *dev);
> static phys_addr_t intel_iommu_iova_to_phys(struct iommu_domain *domain,
> dma_addr_t iova);
> +static bool intel_iommu_dev_feat_enabled(struct device *dev,
> + enum iommu_dev_features feat);
>
> #ifdef CONFIG_INTEL_IOMMU_DEFAULT_ON
> int dmar_disabled = 0;
> @@ -1832,6 +1834,7 @@ static struct dmar_domain *alloc_domain(int flags)
> domain->flags |= DOMAIN_FLAG_USE_FIRST_LEVEL;
> domain->has_iotlb_device = false;
> INIT_LIST_HEAD(>devices);
> + INIT_LIST_HEAD(>subdevices);
>
> return domain;
> }
> @@ -2580,7 +2583,7 @@ static struct dmar_domain
> *dmar_insert_one_dev_info(struct intel_iommu *iommu,
> info->iommu = iommu;
> info->pasid_table = NULL;
> info->auxd_enabled = 0;
> - INIT_LIST_HEAD(>auxiliary_domains);
> + INIT_LIST_HEAD(>subdevices);
>
> if (dev && dev_is_pci(dev)) {
> struct pci_dev *pdev = to_pci_dev(info->dev);
> @@ -5137,21 +5140,28 @@ static void intel_iommu_domain_free(struct
> iommu_domain *domain)
> domain_exit(to_dmar_domain(domain));
> }
>
> -/*
> - * Check whether a @domain could be attached to the @dev through the
> - * aux-domain attach/detach APIs.
> - */
> -static inline bool
> -is_aux_domain(struct device *dev, struct iommu_domain *domain)
> +/* Lookup subdev_info in the domain's subdevice siblings. */
> +static struct subdev_info *
> +subdev_lookup_domain(struct dmar_domain *domain, struct device *dev,
> + struct device *subdev)
> {
> - struct device_domain_info *info = get_domain_info(dev);
> + struct subdev_info *sinfo = NULL, *tmp;
>
> - return info && info->auxd_enabled &&
> - domain->type == IOMMU_DOMAIN_UNMANAGED;
> + assert_spin_locked(_domain_lock);
> +
> + list_for_each_entry(tmp, >subdevices, link_domain) {
> + if ((!dev || tmp->pdev == dev) && tmp->dev == subdev) {
> + sinfo = tmp;
> + break;
> + }
> + }
> +
> + return sinfo;
> }
>
> -static void auxiliary_link_device(struct dmar_domain *domain,
> - struct device *dev)
> +static void
> +subdev_link_device(struct dmar_domain *domain, struct device *dev,
> +struct subdev_info *sinfo)
> {
> struct device_domain_info *info = get_domain_info(dev);
>
> @@ -5159,12 +5169,13 @@ static void auxiliary_link_device(struct dmar_domain
> *domain,
> if (WARN_ON(!info))
> return;
>
> - domain->auxd_refcnt++;
> - list_add(>auxd, >auxiliary_domains);
> + list_add(>subdevices, >link_phys);
> + list_add(>subdevices, >link_domain);
> }
>
> -static void auxiliary_unlink_device(struct dmar_domain *domain,
> - struct device *dev)
> +static void
> +subdev_unlink_device(struct dmar_domain *domain, struct device *dev,
> + struct subdev_info *sinfo)
> {
> struct device_domain_info *info = get_domain_info(dev);
>
> @@ -5172,24 +5183,30 @@ static void auxiliary_unlink_device(struct
> dmar_domain *domain,
> if (WARN_ON(!info))
> return;
>
> - list_del(>auxd);
> - domain->auxd_refcnt--;
> + list_del(>link_phys);
> + list_del(>link_domain);
> + kfree(sinfo);
>
> - if (!domain->auxd_refcnt && domain->default_pasid > 0)
> + if (list_empty(>subdevices) && domain->default_pasid > 0)
> ioasid_free(domain->default_pasid);
> }
>
> -static int aux_domain_add_dev(struct dmar_domain *domain,
> - struct device *dev)
> +static int aux_domain_add_dev(struct dmar_domain *domain, struct device *dev,
> + struct device *subdev)
> {
> int ret;
> unsigned long flags;
> struct intel_iommu *iommu;
> + struct subdev_info *sinfo;
>
> iommu = device_to_iommu(dev, NULL, NULL);
> if (!iommu)
> return -ENODEV;
>
> + sinfo = kzalloc(sizeof(*sinfo),
Re: [PATCH v4 1/5] iommu: Add optional subdev in aux_at(de)tach ops
On Tue, 1 Sep 2020 11:34:18 +0800
Lu Baolu wrote:
> In the vfio/mdev use case of aux-domain, the subdevices are created from
> the physical devices with IOMMU_DEV_FEAT_AUX enabled and the aux-domains
> are attached to the subdevices through the iommu_ops.aux_attach_dev()
> interface.
>
> Current iommu_ops.aux_at(de)tach_dev() design only takes the aux-domain
> and the physical device as the parameters, this is insufficient if we
> want the vendor iommu drivers to learn the knowledge about relationships
> between the aux-domains and the subdevices. Add a @subdev parameter to
> iommu_ops.aux_at(de)tach_dev() interfaces so that a subdevice could be
> opt-in.
>
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/intel/iommu.c | 10 ++
> drivers/iommu/iommu.c | 4 ++--
> include/linux/iommu.h | 6 --
> 3 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> index bce158468abf..3c12fd06856c 100644
> --- a/drivers/iommu/intel/iommu.c
> +++ b/drivers/iommu/intel/iommu.c
> @@ -5338,8 +5338,9 @@ static int intel_iommu_attach_device(struct
> iommu_domain *domain,
> return domain_add_dev_info(to_dmar_domain(domain), dev);
> }
>
> -static int intel_iommu_aux_attach_device(struct iommu_domain *domain,
> - struct device *dev)
> +static int
> +intel_iommu_aux_attach_device(struct iommu_domain *domain,
> + struct device *dev, struct device *subdev)
> {
> int ret;
>
> @@ -5359,8 +5360,9 @@ static void intel_iommu_detach_device(struct
> iommu_domain *domain,
> dmar_remove_one_dev_info(dev);
> }
>
> -static void intel_iommu_aux_detach_device(struct iommu_domain *domain,
> - struct device *dev)
> +static void
> +intel_iommu_aux_detach_device(struct iommu_domain *domain, struct device
> *dev,
> + struct device *subdev)
> {
> aux_domain_remove_dev(to_dmar_domain(domain), dev);
> }
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 609bd25bf154..38cdfeb887e1 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -2728,7 +2728,7 @@ int iommu_aux_attach_device(struct iommu_domain
> *domain, struct device *dev)
> int ret = -ENODEV;
>
> if (domain->ops->aux_attach_dev)
> - ret = domain->ops->aux_attach_dev(domain, dev);
> + ret = domain->ops->aux_attach_dev(domain, dev, NULL);
>
> if (!ret)
> trace_attach_device_to_domain(dev);
> @@ -2740,7 +2740,7 @@ EXPORT_SYMBOL_GPL(iommu_aux_attach_device);
> void iommu_aux_detach_device(struct iommu_domain *domain, struct device *dev)
> {
> if (domain->ops->aux_detach_dev) {
> - domain->ops->aux_detach_dev(domain, dev);
> + domain->ops->aux_detach_dev(domain, dev, NULL);
> trace_detach_device_from_domain(dev);
> }
> }
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index fee209efb756..871267104915 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -279,8 +279,10 @@ struct iommu_ops {
> int (*dev_disable_feat)(struct device *dev, enum iommu_dev_features f);
>
> /* Aux-domain specific attach/detach entries */
> - int (*aux_attach_dev)(struct iommu_domain *domain, struct device *dev);
> - void (*aux_detach_dev)(struct iommu_domain *domain, struct device *dev);
> + int (*aux_attach_dev)(struct iommu_domain *domain, struct device *dev,
> + struct device *subdev);
> + void (*aux_detach_dev)(struct iommu_domain *domain, struct device *dev,
> +struct device *subdev);
> int (*aux_get_pasid)(struct iommu_domain *domain, struct device *dev);
>
> struct iommu_sva *(*sva_bind)(struct device *dev, struct mm_struct *mm,
Would this be a good spot in the code to provide comments more formally
defining this subdevice concept? For example, what exactly is the
relationship between the device and the subdevice and which device do
we use for the remaining aux domain functions, ex. aux_get_pasid().
Thanks,
Alex
Re: [PATCH v4 2/5] iommu: Add iommu_at(de)tach_subdev_group()
On Tue, 1 Sep 2020 11:34:19 +0800
Lu Baolu wrote:
> This adds two new APIs for the use cases like vfio/mdev where subdevices
> derived from physical devices are created and put in an iommu_group. The
> new IOMMU API interfaces mimic the vfio_mdev_at(de)tach_domain() directly,
> testing whether the resulting device supports IOMMU_DEV_FEAT_AUX and using
> an aux vs non-aux at(de)tach.
>
> By doing this we could
>
> - Set the iommu_group.domain. The iommu_group.domain is private to iommu
> core (therefore vfio code cannot set it), but we need it set in order
> for iommu_get_domain_for_dev() to work with a group attached to an aux
> domain.
>
> - Prefer to use the _attach_group() interfaces while the _attach_device()
> interfaces are relegated to special cases.
>
> Link: https://lore.kernel.org/linux-iommu/20200730134658.44c57...@x1.home/
> Link: https://lore.kernel.org/linux-iommu/20200730151703.5daf8...@x1.home/
> Signed-off-by: Lu Baolu
> ---
> drivers/iommu/iommu.c | 136 ++
> include/linux/iommu.h | 20 +++
> 2 files changed, 156 insertions(+)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 38cdfeb887e1..fb21c2ff4861 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -2757,6 +2757,142 @@ int iommu_aux_get_pasid(struct iommu_domain *domain,
> struct device *dev)
> }
> EXPORT_SYMBOL_GPL(iommu_aux_get_pasid);
>
> +static int __iommu_aux_attach_device(struct iommu_domain *domain,
> + struct device *phys_dev,
> + struct device *sub_dev)
> +{
> + int ret;
> +
> + if (unlikely(!domain->ops->aux_attach_dev))
> + return -ENODEV;
> +
> + ret = domain->ops->aux_attach_dev(domain, phys_dev, sub_dev);
> + if (!ret)
> + trace_attach_device_to_domain(sub_dev);
> +
> + return ret;
> +}
> +
> +static void __iommu_aux_detach_device(struct iommu_domain *domain,
> + struct device *phys_dev,
> + struct device *sub_dev)
> +{
> + if (unlikely(!domain->ops->aux_detach_dev))
> + return;
> +
> + domain->ops->aux_detach_dev(domain, phys_dev, sub_dev);
> + trace_detach_device_from_domain(sub_dev);
> +}
> +
> +static int __iommu_attach_subdev_group(struct iommu_domain *domain,
> +struct iommu_group *group,
> +iommu_device_lookup_t fn)
> +{
> + struct group_device *device;
> + struct device *phys_dev;
> + int ret = -ENODEV;
> +
> + list_for_each_entry(device, >devices, list) {
> + phys_dev = fn(device->dev);
> + if (!phys_dev) {
> + ret = -ENODEV;
> + break;
> + }
> +
> + if (iommu_dev_feature_enabled(phys_dev, IOMMU_DEV_FEAT_AUX))
> + ret = __iommu_aux_attach_device(domain, phys_dev,
> + device->dev);
> + else
> + ret = __iommu_attach_device(domain, phys_dev);
> +
> + if (ret)
> + break;
> + }
> +
> + return ret;
> +}
> +
> +static void __iommu_detach_subdev_group(struct iommu_domain *domain,
> + struct iommu_group *group,
> + iommu_device_lookup_t fn)
> +{
> + struct group_device *device;
> + struct device *phys_dev;
> +
> + list_for_each_entry(device, >devices, list) {
> + phys_dev = fn(device->dev);
> + if (!phys_dev)
> + break;
Seems like this should be a continue rather than a break. On the
unwind path maybe we're relying on holding the group mutex and
deterministic behavior from the fn() callback to unwind to the same
point, but we still have an entirely separate detach interface and I'm
not sure we couldn't end up with an inconsistent state if we don't
iterate each group device here. Thanks,
Alex
> +
> + if (iommu_dev_feature_enabled(phys_dev, IOMMU_DEV_FEAT_AUX))
> + __iommu_aux_detach_device(domain, phys_dev,
> device->dev);
> + else
> + __iommu_detach_device(domain, phys_dev);
> + }
> +}
> +
> +/**
> + * iommu_attach_subdev_group - attach domain to an iommu_group which
> + * contains subdevices.
> + *
> + * @domain: domain
> + * @group: iommu_group which contains subdevices
> + * @fn: callback for each subdevice in the @iommu_group to retrieve the
> + * physical device where the subdevice was created from.
> + *
> + * Returns 0 on success, or an error value.
> + */
> +int iommu_attach_subdev_group(struct iommu_domain *domain,
> + struct iommu_group *group,
> + iommu_device_lookup_t fn)
> +{
> + int ret =
Re: [PATCH v2] macsec: Support 32bit PN netlink attribute for XPN links
From: Era Mayflower
Date: Thu, 10 Sep 2020 09:56:09 +
> - pn_len = secy->xpn ? MACSEC_XPN_PN_LEN : MACSEC_DEFAULT_PN_LEN;
> - if (nla_len(tb_sa[MACSEC_SA_ATTR_PN]) != pn_len) {
> - pr_notice("macsec: nl: upd_rxsa: bad pn length: %d !=
> %d\n",
> - nla_len(tb_sa[MACSEC_SA_ATTR_PN]), pn_len);
> + pr_notice("macsec: nl: upd_rxsa: pn length on non-xpn
> links must be %d\n",
> + MACSEC_DEFAULT_PN_LEN);
> + rtnl_unlock();
> + return -EINVAL;
> +
> + default:
> + pr_notice("macsec: nl: upd_rxsa: pn length must be %d
> or %d\n",
> + MACSEC_DEFAULT_PN_LEN, MACSEC_XPN_PN_LEN);
> rtnl_unlock();
Please do not spam the kernel log like this. Instead, report this
info via netlink extended ACKs.
Thank you.
Re: [PATCH 2/3] arm64: dts: sc7180: add bus clock to mdp node for sc7180 target
On Thu, Sep 10, 2020 at 3:00 PM Bjorn Andersson wrote: > > On Thu 16 Jul 11:35 UTC 2020, Kalyan Thota wrote: > > > From: Krishna Manikandan > > > > Move the bus clock to mdp device node,in order > > to facilitate bus band width scaling on sc7180 > > target. > > > > The parent device MDSS will not vote for bus bw, > > instead the vote will be triggered by mdp device > > node. Since a minimum vote is required to turn > > on bus clock, move the clock node to mdp device > > from where the votes are requested. > > > > This patch has dependency on the below series > > https://patchwork.kernel.org/patch/11468783/ > > > > Isn't this dependency on an old revision of patch 3/3 in this series? > > Regardless, I don't see either the linked patch or patch 3 merged in > linux-next, so I presume I should not merge this? I guess that would be "drm/msm/dpu: add support for clk and bw scaling for display" on msm-next-staging[1] (about to be msm-next) [1] https://gitlab.freedesktop.org/drm/msm/-/commits/msm-next-staging > Regards, > Bjorn > > > Signed-off-by: Krishna Manikandan > > --- > > arch/arm64/boot/dts/qcom/sc7180.dtsi | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi > > b/arch/arm64/boot/dts/qcom/sc7180.dtsi > > index 4f2c0d1..31fed6d 100644 > > --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi > > +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi > > @@ -1510,10 +1510,9 @@ > > power-domains = < MDSS_GDSC>; > > > > clocks = < GCC_DISP_AHB_CLK>, > > - < GCC_DISP_HF_AXI_CLK>, > >< DISP_CC_MDSS_AHB_CLK>, > >< DISP_CC_MDSS_MDP_CLK>; > > - clock-names = "iface", "bus", "ahb", "core"; > > + clock-names = "iface", "ahb", "core"; > > > > assigned-clocks = < DISP_CC_MDSS_MDP_CLK>; > > assigned-clock-rates = <3>; > > @@ -1539,12 +1538,13 @@ > > <0 0x0aeb 0 0x2008>; > > reg-names = "mdp", "vbif"; > > > > - clocks = < DISP_CC_MDSS_AHB_CLK>, > > + clocks = < GCC_DISP_HF_AXI_CLK>, > > + < DISP_CC_MDSS_AHB_CLK>, > >< DISP_CC_MDSS_ROT_CLK>, > >< DISP_CC_MDSS_MDP_LUT_CLK>, > >< DISP_CC_MDSS_MDP_CLK>, > >< DISP_CC_MDSS_VSYNC_CLK>; > > - clock-names = "iface", "rot", "lut", "core", > > + clock-names = "bus", "iface", "rot", "lut", > > "core", > > "vsync"; > > assigned-clocks = < > > DISP_CC_MDSS_MDP_CLK>, > > < > > DISP_CC_MDSS_VSYNC_CLK>; > > -- > > 1.9.1 > >
linux-next: Signed-off-by missing for commit in the iomap tree
Hi all,
Commit
3e88e7243277 ("xfs: don't crash with assfail")
is missing a Signed-off-by from its author and committer.
--
Cheers,
Stephen Rothwell
pgpLzfyEZHU_R.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/2] media: i2c: Add driver for the Analog Devices ADDI9036 ToF front-end
Hi Bogdan,
Thank you for the patch.
On Thu, Sep 10, 2020 at 07:24:06PM +0300, Bogdan Togorean wrote:
> The ADDI9036 is a complete, 45 MHz, front-end solution for charge
> coupled device (CCD) time of flight (TOF) imaging applications.
>
> It has 2-lane MIPI CSI-2 RAW12 data output and i2c control interface.
>
> The programming of calibration and firmware is performed by userspace
> SDK through CID_USER class IOCTLs.
I'm afraid that's not acceptable. The firmware should be loaded using
the Linux kernel firmware API. As for calibration, is it static data ?
How is it generated ?
> Signed-off-by: Bogdan Togorean
> ---
> MAINTAINERS| 10 +
> drivers/media/i2c/Kconfig | 14 +
> drivers/media/i2c/Makefile | 1 +
> drivers/media/i2c/addi9036.c | 673 +
> include/uapi/linux/v4l2-controls.h | 6 +
> 5 files changed, 704 insertions(+)
> create mode 100644 drivers/media/i2c/addi9036.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b5cfab015bd6..fb03ad9ca920 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -477,6 +477,16 @@ W: http://wiki.analog.com/AD7879
> W: http://ez.analog.com/community/linux-device-drivers
> F: drivers/input/touchscreen/ad7879.c
>
> +ADDI9036 TOF FRONTEND DRIVER
> +M: Bogdan Togorean
> +L: linux-me...@vger.kernel.org
> +S: Supported
> +W: https://www.analog.com/en/products/addi9036.html
> +W: http://ez.analog.com/community/linux-device-drivers
> +T: git git://linuxtv.org/media_tree.git
> +F: Documentation/devicetree/bindings/media/i2c/adi,addi9036.yaml
> +F: drivers/media/i2c/addi9036.c
> +
> ADDRESS SPACE LAYOUT RANDOMIZATION (ASLR)
> M: Jiri Kosina
> S: Maintained
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index c7ba76fee599..087dd307505d 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -725,6 +725,20 @@ config VIDEO_APTINA_PLL
> config VIDEO_SMIAPP_PLL
> tristate
>
> +config VIDEO_ADDI9036
> + tristate "Analog Devices ADDI9036 ToF front-end support"
> + depends on I2C && VIDEO_V4L2
> + select MEDIA_CONTROLLER
> + select VIDEO_V4L2_SUBDEV_API
> + select V4L2_FWNODE
> + select REGMAP_I2C
> + help
> + This is a Video4Linux2 driver for Analog Devices ADDI9036
> + Time of Flight front-end.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called addi9036.
> +
> config VIDEO_HI556
> tristate "Hynix Hi-556 sensor support"
> depends on I2C && VIDEO_V4L2
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index f0a77473979d..631a7c7612ca 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_VIDEO_AK7375) += ak7375.o
> obj-$(CONFIG_VIDEO_DW9714) += dw9714.o
> obj-$(CONFIG_VIDEO_DW9768) += dw9768.o
> obj-$(CONFIG_VIDEO_DW9807_VCM) += dw9807-vcm.o
> +obj-$(CONFIG_VIDEO_ADDI9036) += addi9036.o
> obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
> obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
> obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o
> diff --git a/drivers/media/i2c/addi9036.c b/drivers/media/i2c/addi9036.c
> new file mode 100644
> index ..76c3444058dc
> --- /dev/null
> +++ b/drivers/media/i2c/addi9036.c
> @@ -0,0 +1,673 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for the Analog Devices ADDI9036 ToF front-end.
> + *
> + * Copyright (C) 2019-2020 Analog Devices, All Rights Reserved.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct addi9036_mode_info {
> + u32 width;
> + u32 height;
> + u32 pixel_rate;
> + u32 link_freq_idx;
> +};
> +
> +struct addi9036 {
> + struct regmap *regmap;
> + struct device *dev;
> + struct v4l2_subdev sd;
> + struct media_pad pad;
> + struct v4l2_fwnode_endpoint ep;
> + struct v4l2_mbus_framefmt fmt;
> + struct v4l2_rect crop;
> +
> + const struct addi9036_mode_info *current_mode;
> +
> + struct v4l2_ctrl_handler ctrls;
> + struct v4l2_ctrl *pixel_rate;
> + struct v4l2_ctrl *link_freq;
> +
> + /* lock to protect power state */
> + struct mutex power_lock;
> + int power_count;
> +
> + struct gpio_desc *rst_gpio;
> +
> + /* controls */
> + struct v4l2_ctrl *set_chip_config;
> + struct v4l2_ctrl *reg_read;
> +};
> +
> +static inline struct addi9036 *to_addi9036(struct v4l2_subdev *sd)
> +{
> + return container_of(sd, struct addi9036, sd);
> +}
> +
> +#define V4L2_CID_AD_DEV_SET_CHIP_CONFIG_QUERY (V4L2_CID_USER_ADDI9036_BASE
> + 0)
> +#define V4L2_CID_AD_DEV_REG_READ_QUERY (V4L2_CID_USER_ADDI9036_BASE + 1)
> +
> +static const struct reg_sequence addi9036_powerup_setting[] = {
> + { 0xc4c0, 0x001c },
> + { 0xc4c3,
Re: [PATCH 04/10] clk: gpio: Simplify with dev_err_probe()
Quoting Krzysztof Kozlowski (2020-09-02 08:03:42)
> diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
> index 38755a241ab7..a3cc53edcb11 100644
> --- a/drivers/clk/clk-gpio.c
> +++ b/drivers/clk/clk-gpio.c
> @@ -211,17 +210,10 @@ static int gpio_clk_driver_probe(struct platform_device
> *pdev)
>
> gpio_name = is_mux ? "select" : "enable";
> gpiod = devm_gpiod_get(dev, gpio_name, GPIOD_OUT_LOW);
> - if (IS_ERR(gpiod)) {
> - ret = PTR_ERR(gpiod);
> - if (ret == -EPROBE_DEFER)
> - pr_debug("%pOFn: %s: GPIOs not yet available, retry
> later\n",
> - node, __func__);
> - else
> - pr_err("%pOFn: %s: Can't get '%s' named GPIO
> property\n",
> - node, __func__,
> - gpio_name);
> - return ret;
> - }
> + if (IS_ERR(gpiod))
> + return dev_err_probe(dev, PTR_ERR(gpiod),
This is cool! I wonder if we could make it even more simplified with
ret = dev_err_probe_ptr(dev, ptr, ...)
if (ret)
return ret;
then we don't have to do the PTR_ERR() or IS_ERR() dance in all the
drivers. It could already be changed here to look at the return value of
dev_err_probe() so please do that at the least.
It would also even be more super duper cool if we had a way to save some
sort of cookie when the provider can't find it and is returning the
-EPROBE_DEFER value. Maybe the provider could use
device_set_deferred_probe_reason() on error and then if dev_err_probe()
is called without any string it can print what is in the device's
deferred probe reason? Or append to it whatever string is passed from
the device driver? Sometimes the provider has more info like the DT
property is malformed or the provider isn't probed yet which would
probably help understand the deferred problem more.
Re: [[PATCH]] mm: khugepaged: recalculate min_free_kbytes after memory hotplug as expected by khugepaged
On Thu, Sep 10, 2020 at 01:47:39PM -0700, Vijay Balakrishna wrote:
> When memory is hotplug added or removed the min_free_kbytes must be
> recalculated based on what is expected by khugepaged. Currently
> after hotplug, min_free_kbytes will be set to a lower default and higher
> default set when THP enabled is lost. This leaves the system with small
> min_free_kbytes which isn't suitable for systems especially with network
> intensive loads. Typical failure symptoms include HW WATCHDOG reset,
> soft lockup hang notices, NETDEVICE WATCHDOG timeouts, and OOM process
> kills.
>
> Fixes: f000565adb77 ("thp: set recommended min free kbytes")
>
> Signed-off-by: Vijay Balakrishna
> Cc: sta...@vger.kernel.org
NAK. It would override min_free_kbytes set by user.
--
Kirill A. Shutemov
Re: WARNING in bpf_raw_tp_link_fill_link_info
On Thu, Sep 10, 2020 at 2:31 AM syzbot
wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:7fb5eefd selftests/bpf: Fix test_sysctl_loop{1, 2} failure..
> git tree: bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1424fdb390
> kernel config: https://syzkaller.appspot.com/x/.config?x=b6856d16f78d8fa9
> dashboard link: https://syzkaller.appspot.com/bug?extid=976d5ecfab0c7eb43ac3
> compiler: gcc (GCC) 10.1.0-syz 20200507
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14a1f41190
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10929c1190
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+976d5ecfab0c7eb43...@syzkaller.appspotmail.com
>
> [ cut here ]
> WARNING: CPU: 0 PID: 6854 at include/linux/thread_info.h:150 check_copy_size
> include/linux/thread_info.h:150 [inline]
> WARNING: CPU: 0 PID: 6854 at include/linux/thread_info.h:150 copy_to_user
> include/linux/uaccess.h:167 [inline]
> WARNING: CPU: 0 PID: 6854 at include/linux/thread_info.h:150
> bpf_raw_tp_link_fill_link_info+0x306/0x350 kernel/bpf/syscall.c:2661
> Kernel panic - not syncing: panic_on_warn set ...
> CPU: 0 PID: 6854 Comm: syz-executor574 Not tainted 5.9.0-rc1-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x18f/0x20d lib/dump_stack.c:118
> panic+0x2e3/0x75c kernel/panic.c:231
> __warn.cold+0x20/0x4a kernel/panic.c:600
> report_bug+0x1bd/0x210 lib/bug.c:198
> handle_bug+0x38/0x90 arch/x86/kernel/traps.c:234
> exc_invalid_op+0x14/0x40 arch/x86/kernel/traps.c:254
> asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:536
> RIP: 0010:check_copy_size include/linux/thread_info.h:150 [inline]
> RIP: 0010:copy_to_user include/linux/uaccess.h:167 [inline]
> RIP: 0010:bpf_raw_tp_link_fill_link_info+0x306/0x350 kernel/bpf/syscall.c:2661
> Code: 41 bc ea ff ff ff e9 35 ff ff ff 4c 89 ff e8 41 66 33 00 e9 d0 fd ff ff
> 4c 89 ff e8 a4 66 33 00 e9 06 ff ff ff e8 ca ed f2 ff <0f> 0b eb 94 48 89 ef
> e8 2e 66 33 00 e9 65 fd ff ff e8 24 66 33 00
> RSP: 0018:c900051c7bd0 EFLAGS: 00010293
> RAX: RBX: c900051c7c60 RCX: 818179d6
> RDX: 88808b49 RSI: 81817a96 RDI: 0006
> RBP: 0019 R08: R09: c900051c7c7f
> R10: R11: R12: 0019
> R13: 1265 R14: 8986ecc0 R15: c900051c7c78
> bpf_link_get_info_by_fd kernel/bpf/syscall.c:3626 [inline]
> bpf_obj_get_info_by_fd+0x43a/0xc40 kernel/bpf/syscall.c:3664
> __do_sys_bpf+0x1906/0x4b30 kernel/bpf/syscall.c:4237
> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x4405f9
> Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48
> 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f
> 83 7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:7fff47155808 EFLAGS: 0246 ORIG_RAX: 0141
> RAX: ffda RBX: 004002c8 RCX: 004405f9
> RDX: 0010 RSI: 20c0 RDI: 000f
> RBP: 006ca018 R08: 004002c8 R09: 004002c8
> R10: 004002c8 R11: 0246 R12: 00401e00
> R13: 00401e90 R14: R15:
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
#syz fix: b474959d5afd ("bpf: Fix a buffer out-of-bound access when
filling raw_tp link_info")
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test patches for this issue, for details see:
> https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH 2/3] arm64: dts: sc7180: add bus clock to mdp node for sc7180 target
On Thu 16 Jul 11:35 UTC 2020, Kalyan Thota wrote: > From: Krishna Manikandan > > Move the bus clock to mdp device node,in order > to facilitate bus band width scaling on sc7180 > target. > > The parent device MDSS will not vote for bus bw, > instead the vote will be triggered by mdp device > node. Since a minimum vote is required to turn > on bus clock, move the clock node to mdp device > from where the votes are requested. > > This patch has dependency on the below series > https://patchwork.kernel.org/patch/11468783/ > Isn't this dependency on an old revision of patch 3/3 in this series? Regardless, I don't see either the linked patch or patch 3 merged in linux-next, so I presume I should not merge this? Regards, Bjorn > Signed-off-by: Krishna Manikandan > --- > arch/arm64/boot/dts/qcom/sc7180.dtsi | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi > b/arch/arm64/boot/dts/qcom/sc7180.dtsi > index 4f2c0d1..31fed6d 100644 > --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi > +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi > @@ -1510,10 +1510,9 @@ > power-domains = < MDSS_GDSC>; > > clocks = < GCC_DISP_AHB_CLK>, > - < GCC_DISP_HF_AXI_CLK>, >< DISP_CC_MDSS_AHB_CLK>, >< DISP_CC_MDSS_MDP_CLK>; > - clock-names = "iface", "bus", "ahb", "core"; > + clock-names = "iface", "ahb", "core"; > > assigned-clocks = < DISP_CC_MDSS_MDP_CLK>; > assigned-clock-rates = <3>; > @@ -1539,12 +1538,13 @@ > <0 0x0aeb 0 0x2008>; > reg-names = "mdp", "vbif"; > > - clocks = < DISP_CC_MDSS_AHB_CLK>, > + clocks = < GCC_DISP_HF_AXI_CLK>, > + < DISP_CC_MDSS_AHB_CLK>, >< DISP_CC_MDSS_ROT_CLK>, >< DISP_CC_MDSS_MDP_LUT_CLK>, >< DISP_CC_MDSS_MDP_CLK>, >< DISP_CC_MDSS_VSYNC_CLK>; > - clock-names = "iface", "rot", "lut", "core", > + clock-names = "bus", "iface", "rot", "lut", > "core", > "vsync"; > assigned-clocks = < > DISP_CC_MDSS_MDP_CLK>, > < > DISP_CC_MDSS_VSYNC_CLK>; > -- > 1.9.1 >
[PATCH v1 0/3] convert sifive's prci, plic and pwm bindings to yaml
The PRCI and PLIC controller bindings are in txt format. Here, we convert
them to yaml format.
These patches are tested on commit f4d51dffc6c0 ("Linux 5.9-rc4"). I have
added the log of dt_binding_check for these IP block's on 5.9-rc4 kernel
here [1] in case someone want's to refer it.
[1] https://paste.ubuntu.com/p/VHqqnXdrkJ
Additionally the default log of dt_binding_check on linux-5.9-rc4 without
these patches can be found here [2].
[2] https://paste.ubuntu.com/p/KNGJrJvvdt
Patch History:
V1: Base version.
Sagar Kadam (3):
dt-bindings: fu540: prci: convert PRCI bindings to json-schema
dt-bindings: riscv: convert plic bindings to json-schema
dt-bindings: riscv: convert pwm bindings to json-schema
.../bindings/clock/sifive/fu540-prci.txt | 46 -
.../bindings/clock/sifive/fu540-prci.yaml | 75 +++
.../interrupt-controller/sifive,plic-1.0.0.txt | 58 ---
.../interrupt-controller/sifive,plic-1.0.0.yaml| 107 +
.../devicetree/bindings/pwm/pwm-sifive.txt | 33 ---
.../devicetree/bindings/pwm/pwm-sifive.yaml| 72 ++
6 files changed, 254 insertions(+), 137 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/clock/sifive/fu540-prci.txt
create mode 100644
Documentation/devicetree/bindings/clock/sifive/fu540-prci.yaml
delete mode 100644
Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.txt
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
delete mode 100644 Documentation/devicetree/bindings/pwm/pwm-sifive.txt
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-sifive.yaml
--
2.7.4
Re: [RFC 1/5] mm, page_alloc: clean up pageset high and batch update
On 10.09.20 10:31, Oscar Salvador wrote:
> On Mon, Sep 07, 2020 at 06:36:24PM +0200, Vlastimil Babka wrote:
>> Signed-off-by: Vlastimil Babka
>
>> for_each_possible_cpu(cpu)
>> -setup_pageset(_cpu(boot_pageset, cpu), 0);
>> +setup_pageset(_cpu(boot_pageset, cpu));
>
> This is not really anything important but I realized we have like 7 functions
> messing with pcp lists, and everytime I try to follow them my head spins.
>
> Since setup_pageset is only being called here, could we replace it by the
> pageset_init and pageset_update?
Had the same thought, so +1.
>> -/*
>> - * pageset_set_high() sets the high water mark for hot per_cpu_pagelist
>> - * to the value high for the pageset p.
>> - */
>> -static void pageset_set_high(struct per_cpu_pageset *p,
>> -unsigned long high)
>> -{
>> -unsigned long batch = max(1UL, high / 4);
>> -if ((high / 4) > (PAGE_SHIFT * 8))
>> -batch = PAGE_SHIFT * 8;
>> -
>> -pageset_update(>pcp, high, batch);
>> +pageset_update(>pcp, 0, 1);
>> }
>
> Could we restore the comment we had in pageset_set_high, and maybe
> update it to match this new function? I think it would be useful.
At least I didn't really understand what "pageset_set_high() sets the
high water mark for hot per_cpu_pagelist to the value high for the
pageset p." was trying to tell me.
I think the only valuable information is the "hot", meaning it is in use
and we have to be careful when updating, right?
>>
>> static void pageset_set_high_and_batch(struct zone *zone,
>> - struct per_cpu_pageset *pcp)
>> + struct per_cpu_pageset *p)
>> {
>> -if (percpu_pagelist_fraction)
>> -pageset_set_high(pcp,
>> -(zone_managed_pages(zone) /
>> -percpu_pagelist_fraction));
>> -else
>> -pageset_set_batch(pcp, zone_batchsize(zone));
>> +unsigned long new_high;
>> +unsigned long new_batch;
>> +int fraction = READ_ONCE(percpu_pagelist_fraction);
>
> Why the READ_ONCE? In case there is a parallel update so things to get
> messed up?
Agreed, this is an actual change in the code. If this is a fix, separate
patch?
Apart from that, looks much better to me!
--
Thanks,
David / dhildenb
Re: [PATCH 2/2] serial: core: fix console port-lock regression
On Thu, Sep 10, 2020 at 12:27:15PM +0300, Andy Shevchenko wrote:
> +Cc: Tony, let me add Tony to the discussion.
>
> On Thu, Sep 10, 2020 at 09:35:27AM +0200, Johan Hovold wrote:
> > On Wed, Sep 09, 2020 at 06:48:15PM +0300, Andy Shevchenko wrote:
> > > On Wed, Sep 09, 2020 at 04:31:01PM +0200, Johan Hovold wrote:
> > > > Fix the port-lock initialisation regression introduced by commit
> > > > a3cb39d258ef ("serial: core: Allow detach and attach serial device for
> > > > console") by making sure that the lock is again initialised during
> > > > console setup.
> > > >
> > > > The console may be registered before the serial controller has been
> > > > probed in which case the port lock needs to be initialised during
> > > > console setup by a call to uart_set_options(). The console-detach
> > > > changes introduced a regression in several drivers by effectively
> > > > removing that initialisation by not initialising the lock when the port
> > > > is used as a console (which is always the case during console setup).
> > > >
> > > > Add back the early lock initialisation and instead use a new
> > > > console-reinit flag to handle the case where a console is being
> > > > re-attached through sysfs.
> > > >
> > > > The question whether the console-detach interface should have been added
> > > > in the first place is left for another discussion.
> > >
> > > It was discussed in [1]. TL;DR: OMAP would like to keep runtime PM
> > > available
> > > for UART while at the same time we disable it for kernel consoles in
> > > bedb404e91bb.
> > >
> > > [1]: https://lists.openwall.net/linux-kernel/2018/09/29/65
> >
> > Yeah, I remember that. My fear is just that the new interface opens up a
> > can of worms as it removes the earlier assumption that the console would
> > essentially never be deregistered without really fixing all those
> > drivers, and core functions, written under that assumption. Just to
> > mention a few issues; we have drivers enabling clocks and other
> > resources during console setup which can now be done repeatedly,
>
> The series introduced the console ->exit() callback, so it should be
> easy to fix.
I'm not saying it's necessarily hard, I'm suggesting it should have been
considered before merging. But there could still be complications as the
console have always been considered a special case that's been hacked
around.
> > and
> > several drivers whose setup callbacks are marked __init and will oops
> > the minute you reattach the console.
>
> I believe this can be fixed relatively easy. As a last resort it can
> be a quirk that disables console detachment for problematic consoles.
Sure, but just removing the __init without vetting the drivers and
testing the new interface may not be much better than letting them oops.
> > And what about power management
> > which was the reason for wanting this on OMAP in the first place; tty
> > core never calls shutdown() for a console port, not even when it's been
> > detached using the new interface.
>
> That is interesting... Tony, do we have OMAP case working because of luck?
>
> > I know, the console setup is all a mess, but this still seems a little
> > rushed to me. I'm even inclined to suggest a revert until the above and
> > similar issues have been addressed properly rather keeping a known buggy
> > interface.
>
> You know that it will be a dead end. Any solution how to move forward?
I guess that depends on how broken this is. I only gave a few examples
of the top of my head of issues that needs to be considered.
But if this is to stay then making the feature opt-in by only exposing
the attribute for console drivers that implement the new exit() callback
or some other serial-driver flag might work.
Johan
Re: [PATCHSET 0/4] perf stat: Add --multiply-cgroup option
Em Thu, Sep 10, 2020 at 11:15:42AM +0200, Jiri Olsa escreveu:
> On Tue, Sep 08, 2020 at 01:42:24PM +0900, Namhyung Kim wrote:
> > When we profile cgroup events with perf stat, it's very annoying to
> > specify events and cgroups on the command line as it requires the
> > mapping between events and cgroups. (Note that perf record can use
> > cgroup sampling but it's not usable for perf stat).
> > I guess most cases we just want to use a same set of events (N) for
> > all cgroups (M), but we need to specify NxM events and NxM cgroups.
> > This is not good especially when profiling large number of cgroups:
> > say M=200.
> > So I added --multiply-cgroup option to make it easy for that case. It
> > will create NxM events from N events and M cgroups. One more upside
> > is that it can handle metrics too.
> agreed that it's PITA to use -G option ;-)
yeah, its great that someone is looking at cgroups improvements, thanks
Namyung, its great to have you working on this!
More below.
> > For example, the following example measures IPC metric for 3 cgroups
> > $ cat perf-multi-cgrp.sh
> > #!/bin/sh
> > METRIC=${1:-IPC}
> > CGROUP_DIR=/sys/fs/cgroup/perf_event
> > sudo mkdir $CGROUP_DIR/A $CGROUP_DIR/B $CGROUP_DIR/C
> > # add backgroupd workload for each cgroup
> > echo $$ | sudo tee $CGROUP_DIR/A/cgroup.procs > /dev/null
> > yes > /dev/null &
> > echo $$ | sudo tee $CGROUP_DIR/B/cgroup.procs > /dev/null
> > yes > /dev/null &
> > echo $$ | sudo tee $CGROUP_DIR/C/cgroup.procs > /dev/null
> > yes > /dev/null &
> > # run 'perf stat' in the root cgroup
> > echo $$ | sudo tee $CGROUP_DIR/cgroup.procs > /dev/null
> > perf stat -a -M $METRIC --multiply-cgroup -G A,B,C sleep 1
>
> would it be easier to have new option for this? like:
>
> perf stat -a -M $METRIC --for-cgroup A,B,C
> perf stat -a -M $METRIC --for-each-cgroup A,B,C
> perf stat -a -M $METRIC --attach-cgroup A,B,C
> perf stat -a -M $METRIC --attach-to-cgroup A,B,C
>
> I'm still not sure how the --multiply-cgroup deals with empty
> cgroup A,,C but looks like we don't need this behaviour now?
Yeah, I also didn't like the --multiply-cgroup thing, perhaps we can use
a per-event term? or per group, for example:
perf stat -a -M $METRIC/cgroups=A,B,C/
perf stat -a -e '{cycles,instructions,cache-misses}/cgroups=A,B,C/'
Allowing wildcards or regexps would help with some use cases.
We already have several terms that allows us to control per event knobs,
this would be one more.
- Arnaldo
Re: [PATCH v5 00/20] gpio: cdev: add uAPI v2
On Thu, Aug 27, 2020 at 06:02:03PM +0200, Bartosz Golaszewski wrote: > On Thu, Aug 27, 2020 at 5:53 PM Linus Walleij > wrote: > please hold it maybe for one more week - I'd love to have some more > people take a look at the user facing header at least. Andy is usually > very thorough in his reviews so I'm Ccing him here. > > I'll too skim through the series one more time. Thank you, Bart. I think you, guys know how to do that best. Unfortunately I was almost squeezed under pile of several tasks and didn't find time for this. Meanwhile I have sent an updated fix for v1 as suggested by Arnd. It works for me. -- With Best Regards, Andy Shevchenko
Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding
On Thu, Sep 10, 2020 at 12:32:05PM -0700, Linus Torvalds wrote:
> Yeah, I get hung up on naming sometimes. I don't tend to care much
> about private local variables ("i" is a perfectly fine variable name),
> but these kinds of somewhat subtle cross-architecture definitions I
> feel matter.
One of the first replys to this patch was to ask "when would I use
_orig vs normal", so you are not alone. The name should convey it..
So, I suggest pXX_offset_unlocked()
Since it is safe to call without the page table lock, while pXX_offset()
requires the page table lock to be held as the internal *pXX is a data
race otherwise.
Patch 1 might be OK for a stable backport, but to get to a clear
pXX_offset_unlocked() all the arches would want to be changed to
implement that API and the generic code would provide the wrapper:
#define pXX_offset(pXXp, address) pXX_offset_unlocked(pXXp, *(pXXp), address)
Arches would not have a *pXX inside their code.
Then we can talk about auditing call sites of pXX_offset and think
about using the _unlocked version in places where the page table lock
is not held.
For instance mm/pagewalk.c should be changed. So should
huge_pte_offset() and probably other places. These places might
already be exsting data-race bugs.
It is code-as-documentation indicating an unlocked page table walk.
Now it is not just a S390 story but a change that makes the data
concurrency much clearer, so I think I prefer this version to the
addr_end one too.
Regards,
Jason
[PATCH] scripts : config : Added example use when run without argument,extend help
This patch extends the help section by adding an explicit example of use. Signed-off-by: Bhaskar Chowdhury --- scripts/config | 19 +++ 1 file changed, 19 insertions(+) diff --git a/scripts/config b/scripts/config index eee5b7f3a092..b75a5aab2453 100755 --- a/scripts/config +++ b/scripts/config @@ -45,6 +45,25 @@ make time. By default, $myname will upper-case the given symbol. Use --keep-case to keep the case of all following symbols unchanged. +The concerete example, say, you want to change any particular config ,like +GKOV for profiling , you can simply use this command + +To enable : + +#scripts/config --enable GKOV_KERNEL && grep GKOV .config + + and the output will be like this : + + CONFIG_GKOV_KERNEL=y + +To disable : + +#scripts/config --disable GKOV_KERNEL && grep GKOV .config + + and the output will be like this : + +# CONFIG_GKOV_KERNEL is not set + $myname uses 'CONFIG_' as the default symbol prefix. Set the environment variable CONFIG_ to the prefix to use. Eg.: CONFIG_="FOO_" $myname ... EOL -- 2.26.2
[PATCH] drm: kernel-doc: add description for a new function parameter
As reported by "make htmldocs":
./drivers/gpu/drm/drm_prime.c:808: warning: Function parameter or
member 'dev' not described in 'drm_prime_pages_to_sg'
Add a description for the new parameter.
Fixes: 707d561f77b5 ("drm: allow limiting the scatter list size.")
Signed-off-by: Mauro Carvalho Chehab
---
drivers/gpu/drm/drm_prime.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 8a6a3c99b7d8..45e70ecdfa45 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -793,6 +793,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =
{
/**
* drm_prime_pages_to_sg - converts a page array into an sg list
+ * @dev: DRM device
* @pages: pointer to the array of page pointers to convert
* @nr_pages: length of the page vector
*
--
2.26.2
Re: [PATCH] mm: don't rely on system state to detect hot-plug operations
Le 10/09/2020 à 13:12, Michal Hocko a écrit : On Thu 10-09-20 09:51:39, Laurent Dufour wrote: Le 10/09/2020 à 09:23, Michal Hocko a écrit : On Wed 09-09-20 18:07:15, Laurent Dufour wrote: Le 09/09/2020 à 12:59, Michal Hocko a écrit : On Wed 09-09-20 11:21:58, Laurent Dufour wrote: [...] For the point a, using the enum allows to know in register_mem_sect_under_node() if the link operation is due to a hotplug operation or done at boot time. Yes, but let me repeat. We have a mess here and different paths check for the very same condition by different ways. We need to unify those. What are you suggesting to unify these checks (using a MP_* enum as suggested by David, something else)? We do have system_state check spread at different places. I would use this one and wrap it behind a helper. Or have I missed any reason why that wouldn't work for this case? That would not work in that case because memory can be hot-added at the SYSTEM_SCHEDULING system state and the regular memory is also registered at that system state too. So system state is not enough to discriminate between the both. If that is really the case all other places need a fix as well. Btw. could you be more specific about memory hotplug during early boot? How that happens? I am only aware of https://lkml.kernel.org/r/20200818110046.6664-1-osalva...@suse.de and that doesn't happen as early as SYSTEM_SCHEDULING. That points has been raised by David, quoting him here: IIRC, ACPI can hotadd memory while SCHEDULING, this patch would break that. Ccing Oscar, I think he mentioned recently that this is the case with ACPI. Oscar told that he need to investigate further on that. On my side I can't get these ACPI "early" hot-plug operations to happen so I can't check that. If this is clear that ACPI memory hotplug doesn't happen at SYSTEM_SCHEDULING, the patch I proposed at first is enough to fix the issue.
[sparc64] kernel OOPS bisected from "lockdep: improve current->(hard|soft)irqs_enabled synchronisation with actual irq state"
Hello! The following git patch 044d0d6de9f50192f9697583504a382347ee95ca (linux git master branch) introduced the following kernel OOPS upon kernel boot on my sparc64 T5-2 ldom (VM): $ uname -a Linux ttip 5.9.0-rc2-00011-g044d0d6de9f5 #59 SMP Thu Sep 10 13:07:45 MSK 2020 sparc64 GNU/Linux (OOPS is from the latest tag, but the same on commit above) ... rcu: Hierarchical SRCU implementation. smp: Bringing up secondary CPUs ... [ cut here ] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:4875 check_flags+0x9c/0x2c0 DEBUG_LOCKS_WARN_ON(lockdep_hardirqs_enabled()) Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc4 #36 Call Trace: [<004727a8>] __warn+0xa8/0x120 [<00472c10>] warn_slowpath_fmt+0x64/0x74 [<004e859c>] check_flags+0x9c/0x2c0 [<00c17ca0>] lock_is_held_type+0x20/0x140 [<005095f4>] rcu_read_lock_sched_held+0x54/0xa0 [<004ed4c0>] lock_acquire+0x120/0x480 [<00c21610>] _raw_spin_lock+0x30/0x60 [<009b9bdc>] p1275_cmd_direct+0x1c/0x60 [<009b9ab0>] prom_startcpu_cpuid+0x30/0x40 [<004427e4>] __cpu_up+0x184/0x3a0 [<00474600>] bringup_cpu+0x20/0x120 [<0047378c>] cpuhp_invoke_callback+0xec/0x340 [<004753d4>] cpu_up+0x154/0x220 [<00475c60>] bringup_nonboot_cpus+0x60/0xa0 [<00fbc338>] smp_init+0x28/0xa0 [<00fad3b4>] kernel_init_freeable+0x18c/0x300 irq event stamp: 5135 hardirqs last enabled at (5135): [<00c21a28>] _raw_spin_unlock_irqrestore+0x28/0x60 hardirqs last disabled at (5134): [<00c217e0>] _raw_spin_lock_irqsave+0x20/0x80 softirqs last enabled at (1474): [<00c245a0>] __do_softirq+0x4e0/0x560 softirqs last disabled at (1467): [<0042d394>] do_softirq_own_stack+0x34/0x60 random: get_random_bytes called from __warn+0xc8/0x120 with crng_init=0 ---[ end trace 4cf960ae85148e2e ]--- possible reason: unannotated irqs-off. irq event stamp: 5135 hardirqs last enabled at (5135): [<00c21a28>] _raw_spin_unlock_irqrestore+0x28/0x60 hardirqs last disabled at (5134): [<00c217e0>] _raw_spin_lock_irqsave+0x20/0x80 softirqs last enabled at (1474): [<00c245a0>] __do_softirq+0x4e0/0x560 softirqs last disabled at (1467): [<0042d394>] do_softirq_own_stack+0x34/0x60 smp: Brought up 1 node, 32 CPUs devtmpfs: initialized ... full boot log in [1], kernel config in [2] linux-2.6$ git bisect log git bisect start # good: [d012a7190fc1fd72ed48911e77ca97ba4521bccd] Linux 5.9-rc2 git bisect good d012a7190fc1fd72ed48911e77ca97ba4521bccd # bad: [34d4ddd359dbcdf6c5fb3f85a179243d7a1cb7f8] Merge tag 'linux-kselftest-5.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest git bisect bad 34d4ddd359dbcdf6c5fb3f85a179243d7a1cb7f8 # bad: [e1d0126ca3a66c284a02b083a42e2b39558002cd] Merge tag 'xfs-5.9-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux git bisect bad e1d0126ca3a66c284a02b083a42e2b39558002cd # good: [24148d8648e37f8c15bedddfa50d14a31a0582c5] Merge tag 'io_uring-5.9-2020-08-28' of git://git.kernel.dk/linux-block git bisect good 24148d8648e37f8c15bedddfa50d14a31a0582c5 # bad: [b69bea8a657b681442765b06be92a2607b1bd875] Merge tag 'locking-urgent-2020-08-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect bad b69bea8a657b681442765b06be92a2607b1bd875 # good: [20934c0de13b49a072fb1e0ca79fe0fe0e40eae5] usb: storage: Add unusual_uas entry for Sony PSZ drives git bisect good 20934c0de13b49a072fb1e0ca79fe0fe0e40eae5 # good: [c4011283a7d5d64a50991dd3baa9acdf3d49092c] Merge tag 'dma-mapping-5.9-2' of git://git.infradead.org/users/hch/dma-mapping git bisect good c4011283a7d5d64a50991dd3baa9acdf3d49092c # good: [8bb5021cc2ee5d5dd129a9f2f5ad2bb76eea297d] Merge tag 'powerpc-5.9-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux git bisect good 8bb5021cc2ee5d5dd129a9f2f5ad2bb76eea297d # good: [00b0ed2d4997af6d0a93edef820386951fd66d94] locking/lockdep: Cleanup git bisect good 00b0ed2d4997af6d0a93edef820386951fd66d94 # bad: [044d0d6de9f50192f9697583504a382347ee95ca] lockdep: Only trace IRQ edges git bisect bad 044d0d6de9f50192f9697583504a382347ee95ca # good: [021c109330ebc1f54b546c63a078ea3c31356ecb] arm64: Implement arch_irqs_disabled() git bisect good 021c109330ebc1f54b546c63a078ea3c31356ecb # good: [99dc56feb7932020502d40107a712fa302b32082] mips: Implement arch_irqs_disabled() git bisect good 99dc56feb7932020502d40107a712fa302b32082 # first bad commit: [044d0d6de9f50192f9697583504a382347ee95ca] lockdep: Only trace IRQ edges 1. https://github.com/mator/sparc64-dmesg/blob/master/dmesg-5.9.0-rc4 2. https://github.com/mator/sparc64-dmesg/blob/master/config-5.9.0-rc4.gz
Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding
On Thu, Sep 10, 2020 at 11:39:25AM +0200, Alexander Gordeev wrote:
> As Gerald mentioned, it is very difficult to explain in a clear way.
> Hopefully, one could make sense ot of it.
I would say the page table API requires this invariant:
pud = pud_offset(p4d, addr);
do {
WARN_ON(pud != pud_offset(p4d, addr);
next = pud_addr_end(addr, end);
} while (pud++, addr = next, addr != end);
ie pud++ is supposed to be a shortcut for
pud_offset(p4d, next)
While S390 does not follow this. Fixing addr_end brings it into
alignment by preventing pud++ from happening.
The only currently known side effect is that gup_fast crashes, but it
sure is an unexpected thing.
This suggests another fix, which is to say that pud++ is undefined and
pud_offset() must always be called, but I think that would cause worse
codegen on all other archs.
Jason
Re: [PATCH v3 1/2] leds: mt6360: Add LED driver for MT6360
Hi Gene,
Thanks for the update.
On 9/7/20 12:27 PM, Gene Chen wrote:
From: Gene Chen
Add MT6360 LED driver include 2-channel Flash LED with torch/strobe mode,
and 4-channel RGB LED support Register/Flash/Breath Mode
Signed-off-by: Gene Chen
---
drivers/leds/Kconfig | 11 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-mt6360.c | 681 +
3 files changed, 693 insertions(+)
create mode 100644 drivers/leds/leds-mt6360.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 1c181df..94a6d83 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -271,6 +271,17 @@ config LEDS_MT6323
This option enables support for on-chip LED drivers found on
Mediatek MT6323 PMIC.
+config LEDS_MT6360
+ tristate "LED Support for Mediatek MT6360 PMIC"
+ depends on LEDS_CLASS_FLASH && OF
+ depends on V4L2_FLASH_LED_CLASS || !V4L2_FLASH_LED_CLASS
+ depends on MFD_MT6360
+ help
+ This option enables support for dual Flash LED drivers found on
+ Mediatek MT6360 PMIC.
+ Independent current sources supply for each flash LED support torch
and strobe mode.
+ Includes Low-VF and short protection.
+
config LEDS_S3C24XX
tristate "LED Support for Samsung S3C24XX GPIO LEDs"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index c2c7d7a..5596427 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_LEDS_MIKROTIK_RB532) += leds-rb532.o
obj-$(CONFIG_LEDS_MLXCPLD)+= leds-mlxcpld.o
obj-$(CONFIG_LEDS_MLXREG) += leds-mlxreg.o
obj-$(CONFIG_LEDS_MT6323) += leds-mt6323.o
+obj-$(CONFIG_LEDS_MT6360) += leds-mt6360.o
obj-$(CONFIG_LEDS_NET48XX)+= leds-net48xx.o
obj-$(CONFIG_LEDS_NETXBIG)+= leds-netxbig.o
obj-$(CONFIG_LEDS_NIC78BX)+= leds-nic78bx.o
diff --git a/drivers/leds/leds-mt6360.c b/drivers/leds/leds-mt6360.c
new file mode 100644
index 000..bd6fa48
--- /dev/null
+++ b/drivers/leds/leds-mt6360.c
@@ -0,0 +1,681 @@
+// SPDX-License-Identifier: GPL-2.0-only
+//
+// Copyright (C) 2020 MediaTek Inc.
+//
+// Author: Gene Chen
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum {
+ MT6360_LED_ISNK1 = 0,
+ MT6360_LED_ISNK2,
+ MT6360_LED_ISNK3,
+ MT6360_LED_ISNK4,
+ MT6360_LED_FLASH1,
+ MT6360_LED_FLASH2,
+ MT6360_MAX_LEDS,
+};
+
+#define MT6360_REG_RGBEN 0x380
+#define MT6360_REG_ISNK(_led_no) (0x381 + (_led_no))
+#define MT6360_ISNK_ENMASK(_led_no)BIT(7 - (_led_no))
+#define MT6360_ISNK_MASK 0x1F
+#define MT6360_CHRINDSEL_MASK BIT(3)
+
+#define MT6360_REG_FLEDEN 0x37E
+#define MT6360_REG_STRBTO 0x373
+#define MT6360_REG_FLEDBASE(_id) (0x372 + 4 * (_id - MT6360_LED_FLASH1))
+#define MT6360_REG_FLEDISTRB(_id) (MT6360_REG_FLEDBASE(_id) + 2)
+#define MT6360_REG_FLEDITOR(_id) (MT6360_REG_FLEDBASE(_id) + 3)
+#define MT6360_REG_CHGSTAT20x3E1
+#define MT6360_REG_FLEDSTAT1 0x3E9
+#define MT6360_ITORCH_MASK GENMASK(4, 0)
+#define MT6360_ISTROBE_MASKGENMASK(6, 0)
+#define MT6360_STRBTO_MASK GENMASK(6, 0)
+#define MT6360_TORCHEN_MASKBIT(3)
+#define MT6360_STROBEN_MASKBIT(2)
+#define MT6360_FLCSEN_MASK(_id)BIT(MT6360_LED_FLASH2 - _id)
+#define MT6360_FLEDCHGVINOVP_MASK BIT(3)
+#define MT6360_FLED1STRBTO_MASKBIT(11)
+#define MT6360_FLED2STRBTO_MASKBIT(10)
+#define MT6360_FLED1STRB_MASK BIT(9)
+#define MT6360_FLED2STRB_MASK BIT(8)
+#define MT6360_FLED1SHORT_MASK BIT(7)
+#define MT6360_FLED2SHORT_MASK BIT(6)
+#define MT6360_FLEDLVF_MASKBIT(3)
+
+/* 0 means led_off, add one for dummy */
+#define MT6360_ISNK1_MAXLEVEL 13
+#define MT6360_ISNK4_MAXLEVEL 31
+
+#define MT6360_ITORCH_MIN 25000
+#define MT6360_ITORCH_STEP 12500
+#define MT6360_ITORCH_MAX 40
+#define MT6360_ISTRB_MIN 5
+#define MT6360_ISTRB_STEP 12500
+#define MT6360_ISTRB_MAX 150
+#define MT6360_STRBTO_MIN 64000
+#define MT6360_STRBTO_STEP 32000
+#define MT6360_STRBTO_MAX 2432000
+
+#define FLED_TORCH_FLAG_MASK 0x0c
+#define FLED_TORCH_FLAG_SHFT 2
+#define FLED_STROBE_FLAG_MASK 0x03
+
+#define STATE_OFF 0
+#define STATE_KEEP 1
+#define STATE_ON 2
+
+struct mt6360_led {
+ union {
+ struct led_classdev isnk;
+ struct led_classdev_flash flash;
+ };
+ struct v4l2_flash *v4l2_flash;
+ struct
[PATCH v2 3/4] remoteproc: mtk_vpu_rproc: Add support of JTAG
The DSP could be debugged using JTAG.
The support of JTAG could enabled at build time and it could be enabled
using debugfs.
Signed-off-by: Alexandre Bailon
---
drivers/remoteproc/Kconfig | 9 +++
drivers/remoteproc/mtk_apu.c | 151 ++-
2 files changed, 159 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 4ebea57bf4c8..310462346bd8 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -61,6 +61,15 @@ config MTK_APU
It's safe to say N here.
+config MTK_APU_JTAG
+ bool "Enable support of JTAG"
+ depends on MTK_APU
+ help
+ Say y to enable support of JTAG.
+ By default, JTAG will remain disabled until it is enabled using
+ debugfs: remoteproc/remoteproc0/jtag. Write 1 to enable it and
+ 0 to disable it.
+
config OMAP_REMOTEPROC
tristate "OMAP remoteproc support"
depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX
diff --git a/drivers/remoteproc/mtk_apu.c b/drivers/remoteproc/mtk_apu.c
index 6d2f577cfde5..07157fdc24ba 100644
--- a/drivers/remoteproc/mtk_apu.c
+++ b/drivers/remoteproc/mtk_apu.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include
#include
@@ -14,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -48,6 +50,11 @@
#define CORE_DEFAULT1 (0x0140)
#define CORE_DEFAULT0_ARUSER_IDMA_USE_IOMMU(0x10 << 0)
#define CORE_DEFAULT0_AWUSER_IDMA_USE_IOMMU(0x10 << 5)
+#define CORE_DEFAULT2 (0x0144)
+#define CORE_DEFAULT2_DBG_EN BIT(3)
+#define CORE_DEFAULT2_NIDENBIT(2)
+#define CORE_DEFAULT2_SPNIDEN BIT(1)
+#define CORE_DEFAULT2_SPIDEN BIT(0)
#define CORE_XTENSA_ALTRESETVEC(0x01F8)
struct mtk_apu_rproc {
@@ -57,6 +64,13 @@ struct mtk_apu_rproc {
void __iomem *base;
int irq;
struct clk_bulk_data clks[3];
+
+#ifdef CONFIG_MTK_APU_JTAG
+ struct pinctrl *pinctrl;
+ struct pinctrl_state *pinctrl_jtag;
+ bool jtag_enabled;
+ struct mutex jtag_mutex;
+#endif
};
static int mtk_apu_rproc_prepare(struct rproc *rproc)
@@ -166,6 +180,137 @@ static irqreturn_t handle_event(int irq, void *data)
return IRQ_HANDLED;
}
+#ifdef CONFIG_MTK_APU_JTAG
+
+static int apu_enable_jtag(struct mtk_apu_rproc *apu_rproc)
+{
+ int ret = 0;
+
+ mutex_lock(_rproc->jtag_mutex);
+ if (apu_rproc->jtag_enabled) {
+ ret = -EINVAL;
+ goto err_mutex_unlock;
+ }
+
+ writel(CORE_DEFAULT2_SPNIDEN | CORE_DEFAULT2_SPIDEN |
+ CORE_DEFAULT2_NIDEN | CORE_DEFAULT2_DBG_EN,
+ apu_rproc->base + CORE_DEFAULT2);
+
+ apu_rproc->jtag_enabled = 1;
+
+err_mutex_unlock:
+ mutex_unlock(_rproc->jtag_mutex);
+
+ return ret;
+}
+
+static int apu_disable_jtag(struct mtk_apu_rproc *apu_rproc)
+{
+ int ret = 0;
+
+ mutex_lock(_rproc->jtag_mutex);
+ if (!apu_rproc->jtag_enabled) {
+ ret = -EINVAL;
+ goto err_mutex_unlock;
+ }
+
+ writel(0, apu_rproc->base + CORE_DEFAULT2);
+
+ apu_rproc->jtag_enabled = 0;
+
+err_mutex_unlock:
+ mutex_unlock(_rproc->jtag_mutex);
+
+ return ret;
+}
+
+static ssize_t rproc_jtag_read(struct file *filp, char __user *userbuf,
+ size_t count, loff_t *ppos)
+{
+ struct rproc *rproc = filp->private_data;
+ struct mtk_apu_rproc *apu_rproc = (struct mtk_apu_rproc *)rproc->priv;
+ char *buf = apu_rproc->jtag_enabled ? "enabled\n" : "disabled\n";
+
+ return simple_read_from_buffer(userbuf, count, ppos, buf, strlen(buf));
+}
+
+static ssize_t rproc_jtag_write(struct file *filp, const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct rproc *rproc = filp->private_data;
+ struct mtk_apu_rproc *apu_rproc = (struct mtk_apu_rproc *)rproc->priv;
+ char buf[10];
+ int ret;
+
+ if (count < 1 || count > sizeof(buf))
+ return -EINVAL;
+
+ ret = copy_from_user(buf, user_buf, count);
+ if (ret)
+ return -EFAULT;
+
+ /* remove end of line */
+ if (buf[count - 1] == '\n')
+ buf[count - 1] = '\0';
+
+ if (!strncmp(buf, "enabled", count))
+ ret = apu_enable_jtag(apu_rproc);
+ else if (!strncmp(buf, "disabled", count))
+ ret = apu_disable_jtag(apu_rproc);
+ else
+ return -EINVAL;
+
+ return ret ? ret : count;
+}
+
+static const struct file_operations rproc_jtag_ops = {
+ .read = rproc_jtag_read,
+ .write = rproc_jtag_write,
+ .open = simple_open,
+};
+
+static int apu_jtag_probe(struct mtk_apu_rproc *apu_rproc)
+{
+ int ret;
+
+ if
[PATCH net-next 2/3] net: stmmac: Fix incorrect location to set real_num_rx|tx_queues
From: Aashish Verma
netif_set_real_num_tx_queues() & netif_set_real_num_rx_queues() should be
used to inform network stack about the real Tx & Rx queue (active) number
in both stmmac_open() and stmmac_resume(), therefore, we move the code
from stmmac_dvr_probe() to stmmac_hw_setup().
Fixes: c02b7a914551 net: stmmac: use netif_set_real_num_{rx,tx}_queues
Signed-off-by: Aashish Verma
Signed-off-by: Ong Boon Leong
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 9302d8012a10..fea3b77892ab 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2733,6 +2733,10 @@ static int stmmac_hw_setup(struct net_device *dev, bool
init_ptp)
stmmac_enable_tbs(priv, priv->ioaddr, enable, chan);
}
+ /* Configure real RX and TX queues */
+ netif_set_real_num_rx_queues(dev, priv->plat->rx_queues_to_use);
+ netif_set_real_num_tx_queues(dev, priv->plat->tx_queues_to_use);
+
/* Start the ball rolling... */
stmmac_start_all_dma(priv);
@@ -4883,10 +4887,6 @@ int stmmac_dvr_probe(struct device *device,
stmmac_check_ether_addr(priv);
- /* Configure real RX and TX queues */
- netif_set_real_num_rx_queues(ndev, priv->plat->rx_queues_to_use);
- netif_set_real_num_tx_queues(ndev, priv->plat->tx_queues_to_use);
-
ndev->netdev_ops = _netdev_ops;
ndev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
--
2.17.0
Re: [PATCH 07/12] dma-direct: lift gfp_t manipulation out of__dma_direct_alloc_pages
On 2020-09-08 17:47, Christoph Hellwig wrote:
Move the detailed gfp_t setup from __dma_direct_alloc_pages into the
caller to clean things up a little.
Other than a mild nitpick that it might be nicer to spend one extra line
to keep both gfp adjustments next to each other,
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 1d564bea58571b..12e9f5f75dfe4b 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -108,7 +108,7 @@ static inline bool dma_should_free_from_pool(struct device
*dev,
}
static struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
- gfp_t gfp, unsigned long attrs)
+ gfp_t gfp)
{
int node = dev_to_node(dev);
struct page *page = NULL;
@@ -116,11 +116,6 @@ static struct page *__dma_direct_alloc_pages(struct device
*dev, size_t size,
WARN_ON_ONCE(!PAGE_ALIGNED(size));
- if (attrs & DMA_ATTR_NO_WARN)
- gfp |= __GFP_NOWARN;
-
- /* we always manually zero the memory once we are done: */
- gfp &= ~__GFP_ZERO;
gfp |= dma_direct_optimal_gfp_mask(dev, dev->coherent_dma_mask,
_limit);
page = dma_alloc_contiguous(dev, size, gfp);
@@ -164,6 +159,8 @@ void *dma_direct_alloc(struct device *dev, size_t size,
return arch_dma_alloc(dev, size, dma_handle, gfp, attrs);
size = PAGE_ALIGN(size);
+ if (attrs & DMA_ATTR_NO_WARN)
+ gfp |= __GFP_NOWARN;
if (dma_should_alloc_from_pool(dev, gfp, attrs)) {
u64 phys_mask;
@@ -177,7 +174,8 @@ void *dma_direct_alloc(struct device *dev, size_t size,
goto done;
}
- page = __dma_direct_alloc_pages(dev, size, gfp, attrs);
+ /* we always manually zero the memory once we are done */
+ page = __dma_direct_alloc_pages(dev, size, gfp & ~__GFP_ZERO);
if (!page)
return NULL;
[PATCH v2 2/4] remoteproc: Add a remoteproc driver for the MT8183's APU
This adds a driver to control the APU present in the MT8183.
This loads the firmware and start the DSP.
Signed-off-by: Alexandre Bailon
---
drivers/remoteproc/Kconfig | 10 ++
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/mtk_apu.c | 288 +++
3 files changed, 299 insertions(+)
create mode 100644 drivers/remoteproc/mtk_apu.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index c6659dfea7c7..4ebea57bf4c8 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -51,6 +51,16 @@ config MTK_SCP
It's safe to say N here.
+config MTK_APU
+ tristate "Mediatek APU remoteproc support"
+ depends on ARCH_MEDIATEK
+ depends on MTK_IOMMU
+ help
+ Say y to support the Mediatek's Accelerated Processing Unit (APU) via
+ the remote processor framework.
+
+ It's safe to say N here.
+
config OMAP_REMOTEPROC
tristate "OMAP remoteproc support"
depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 3dfa28e6c701..174644f38fda 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_REMOTEPROC_CDEV) += remoteproc_cdev.o
obj-$(CONFIG_IMX_REMOTEPROC) += imx_rproc.o
obj-$(CONFIG_INGENIC_VPU_RPROC)+= ingenic_rproc.o
obj-$(CONFIG_MTK_SCP) += mtk_scp.o mtk_scp_ipi.o
+obj-$(CONFIG_MTK_APU) += mtk_apu.o
obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
diff --git a/drivers/remoteproc/mtk_apu.c b/drivers/remoteproc/mtk_apu.c
new file mode 100644
index ..6d2f577cfde5
--- /dev/null
+++ b/drivers/remoteproc/mtk_apu.c
@@ -0,0 +1,288 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 BayLibre SAS
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "remoteproc_internal.h"
+
+/* From MT8183 4.5 Vision Processor Unit (VPU).pdf datasheet */
+#define SW_RST (0x000C)
+#define SW_RST_OCD_HALT_ON_RST BIT(12)
+#define SW_RST_IPU_D_RST BIT(8)
+#define SW_RST_IPU_B_RST BIT(4)
+#define CORE_CTRL (0x0110)
+#define CORE_CTRL_PDEBUG_ENABLEBIT(31)
+#define CORE_CTRL_SRAM_64K_iMEM(0x00 << 27)
+#define CORE_CTRL_SRAM_96K_iMEM(0x01 << 27)
+#define CORE_CTRL_SRAM_128K_iMEM (0x02 << 27)
+#define CORE_CTRL_SRAM_192K_iMEM (0x03 << 27)
+#define CORE_CTRL_SRAM_256K_iMEM (0x04 << 27)
+#define CORE_CTRL_PBCLK_ENABLE BIT(26)
+#define CORE_CTRL_RUN_STALLBIT(23)
+#define CORE_CTRL_STATE_VECTOR_SELECT BIT(19)
+#define CORE_CTRL_PIF_GATEDBIT(17)
+#define CORE_CTRL_NMI BIT(0)
+#define CORE_XTENSA_INT(0x0114)
+#define CORE_CTL_XTENSA_INT(0x0118)
+#define CORE_DEFAULT0 (0x013C)
+#define CORE_DEFAULT0_QOS_SWAP_0 (0x00 << 28)
+#define CORE_DEFAULT0_QOS_SWAP_1 (0x01 << 28)
+#define CORE_DEFAULT0_QOS_SWAP_2 (0x02 << 28)
+#define CORE_DEFAULT0_QOS_SWAP_3 (0x03 << 28)
+#define CORE_DEFAULT0_ARUSER_USE_IOMMU (0x10 << 23)
+#define CORE_DEFAULT0_AWUSER_USE_IOMMU (0x10 << 18)
+#define CORE_DEFAULT1 (0x0140)
+#define CORE_DEFAULT0_ARUSER_IDMA_USE_IOMMU(0x10 << 0)
+#define CORE_DEFAULT0_AWUSER_IDMA_USE_IOMMU(0x10 << 5)
+#define CORE_XTENSA_ALTRESETVEC(0x01F8)
+
+struct mtk_apu_rproc {
+ struct device *dev;
+ struct rproc *rproc;
+
+ void __iomem *base;
+ int irq;
+ struct clk_bulk_data clks[3];
+};
+
+static int mtk_apu_rproc_prepare(struct rproc *rproc)
+{
+ struct mtk_apu_rproc *apu_rproc = rproc->priv;
+ int ret;
+
+ ret = clk_bulk_prepare_enable(ARRAY_SIZE(apu_rproc->clks),
+ apu_rproc->clks);
+ if (ret)
+ dev_err(apu_rproc->dev, "Failed to enable clocks\n");
+
+ return ret;
+}
+
+static int mtk_apu_rproc_unprepare(struct rproc *rproc)
+{
+ struct mtk_apu_rproc *apu_rproc = rproc->priv;
+
+ clk_bulk_disable_unprepare(ARRAY_SIZE(apu_rproc->clks),
+ apu_rproc->clks);
+
+ return 0;
+}
+
+static int mtk_apu_rproc_start(struct rproc *rproc)
+{
+ struct mtk_apu_rproc *apu_rproc = rproc->priv;
+ u32 core_ctrl;
+
+ /* Set reset vector of APU firmware
[PATCH v2 4/4] ARM64: mt8183: Add support of APU to mt8183
This adds the support of APU to mt8183.
Signed-off-by: Alexandre Bailon
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 39
1 file changed, 39 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index e215f1eb3eb2..28f75452961c 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -967,12 +967,51 @@ ipu_adl: syscon@1901 {
#clock-cells = <1>;
};
+ apu0: apu@0x1910 {
+ compatible = "mediatek,mt8183-apu";
+ reg = <0 0x1918 0 0x14000>;
+ interrupts = ;
+
+ iommus = < M4U_PORT_IMG_IPUO>,
+< M4U_PORT_IMG_IPU3O>,
+< M4U_PORT_IMG_IPUI>;
+
+ clocks = <_core0 CLK_IPU_CORE0_AXI>,
+<_core0 CLK_IPU_CORE0_IPU>,
+<_core0 CLK_IPU_CORE0_JTAG>;
+
+ clock-names = "axi", "ipu", "jtag";
+
+ power-domains = < MT8183_POWER_DOMAIN_VPU_CORE0>;
+ status = "disabled";
+ };
+
ipu_core0: syscon@1918 {
compatible = "mediatek,mt8183-ipu_core0", "syscon";
reg = <0 0x1918 0 0x1000>;
#clock-cells = <1>;
};
+ apu1: apu@1920 {
+ compatible = "mediatek,mt8183-apu";
+ reg = <0 0x1928 0 0x14000>;
+ interrupts = ;
+
+ iommus = < M4U_PORT_CAM_IPUO>,
+< M4U_PORT_CAM_IPU2O>,
+< M4U_PORT_CAM_IPU3O>,
+< M4U_PORT_CAM_IPUI>,
+< M4U_PORT_CAM_IPU2I>;
+
+ clocks = <_core0 CLK_IPU_CORE1_AXI>,
+<_core0 CLK_IPU_CORE1_IPU>,
+<_core0 CLK_IPU_CORE1_JTAG>;
+
+ clock-names = "axi", "ipu", "jtag";
+
+ power-domains = < MT8183_POWER_DOMAIN_VPU_CORE1>;
+ };
+
ipu_core1: syscon@1928 {
compatible = "mediatek,mt8183-ipu_core1", "syscon";
reg = <0 0x1928 0 0x1000>;
--
2.26.2
Re: [PATCH v1 01/12] fpga: fpga security manager class driver
On 9/10/20 1:22 PM, Russ Weight wrote: > > > On 9/5/20 12:09 PM, Tom Rix wrote: > > > >> >> On 9/4/20 4:52 PM, Russ Weight wrote: >> >>> >>> Create the Intel Security Manager class driver. The security >>> manager provides interfaces to manage secure updates for the >>> FPGA and BMC images that are stored in FLASH. The driver can >>> also be used to update root entry hashes and to cancel code >>> signing keys. >>> >>> This patch creates the class driver and provides sysfs >>> interfaces for displaying root entry hashes, canceled code >>> signing keys and flash counts. >>> >>> Signed-off-by: Russ Weight >>> Signed-off-by: Xu Yilun >>> --- >>> .../ABI/testing/sysfs-class-ifpga-sec-mgr | 75 >>> MAINTAINERS | 8 + >>> drivers/fpga/Kconfig | 9 + >>> drivers/fpga/Makefile | 3 + >>> drivers/fpga/ifpga-sec-mgr.c | 339 ++ >>> include/linux/fpga/ifpga-sec-mgr.h| 145 >>> 6 files changed, 579 insertions(+) >>> create mode 100644 Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr >>> create mode 100644 drivers/fpga/ifpga-sec-mgr.c >>> create mode 100644 include/linux/fpga/ifpga-sec-mgr.h >>> >>> diff --git a/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr >>> b/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr >>> new file mode 100644 >>> index ..86f8992559bf >>> --- /dev/null >>> +++ b/Documentation/ABI/testing/sysfs-class-ifpga-sec-mgr >>> @@ -0,0 +1,75 @@ >>> +What: /sys/class/ifpga_sec_mgr/ifpga_secX/name >>> +Date: Sep 2020 >>> +KernelVersion: 5.10 >>> +Contact: Russ Weight >>> +Description: Name of low level fpga security manager driver. >>> + >>> +What: >>> /sys/class/ifpga_sec_mgr/ifpga_secX/security/sr_root_entry_hash >>> +Date: Sep 2020 >>> +KernelVersion: 5.10 >>> +Contact: Russ Weight >>> +Description: Read only. Returns the root entry hash for the static >>> + region if one is programmed, else it returns the >>> + string: "hash not programmed". This file is only >>> + visible if the underlying device supports it. >>> + Format: "0x%x". >>> + >>> +What: >>> /sys/class/ifpga_sec_mgr/ifpga_secX/security/pr_root_entry_hash >>> +Date: Sep 2020 >>> +KernelVersion: 5.10 >>> +Contact: Russ Weight >>> +Description: Read only. Returns the root entry hash for the partial >>> + reconfiguration region if one is programmed, else it >>> + returns the string: "hash not programmed". This file >>> + is only visible if the underlying device supports it. >>> + Format: "0x%x". >>> + >>> +What: >>> /sys/class/ifpga_sec_mgr/ifpga_secX/security/bmc_root_entry_hash >>> +Date: Sep 2020 >>> +KernelVersion: 5.10 >>> +Contact: Russ Weight >>> +Description: Read only. Returns the root entry hash for the BMC image >>> + if one is programmed, else it returns the string: >>> + "hash not programmed". This file is only visible if the >>> + underlying device supports it. >>> + Format: "0x%x". >>> + >>> +What: >>> /sys/class/ifpga_sec_mgr/ifpga_secX/security/sr_canceled_csks >>> +Date: Sep 2020 >>> +KernelVersion: 5.10 >>> +Contact: Russ Weight >>> +Description: Read only. Returns a list of indices for canceled code >>> + signing keys for the static region. The standard bitmap >>> + list format is used (e.g. "1,2-6,9"). >>> + >>> +What: >>> /sys/class/ifpga_sec_mgr/ifpga_secX/security/pr_canceled_csks >>> +Date: Sep 2020 >>> +KernelVersion: 5.10 >>> +Contact: Russ Weight >>> +Description: Read only. Returns a list of indices for canceled code >>> + signing keys for the partial reconfiguration region. The >>> + standard bitmap list format is used (e.g. "1,2-6,9"). >>> + >>> +What: >>> /sys/class/ifpga_sec_mgr/ifpga_secX/security/bmc_canceled_csks >>> +Date: Sep 2020 >>> +KernelVersion: 5.10 >>> +Contact: Russ Weight >>> +Description: Read only. Returns a list of indices for canceled code >>> + signing keys for the BMC. The standard bitmap list format >>> + is used (e.g. "1,2-6,9"). >>> + >>> +What: >>> /sys/class/ifpga_sec_mgr/ifpga_secX/security/user_flash_count >>> +Date: Sep 2020 >>> +KernelVersion: 5.10 >>> +Contact: Russ Weight >>> +Description: Read only. Returns number of times the user image for >>> the >>> + static region has been flashed. >>> + Format: "%d". >>> >> >> could this be %u ? >> > Yes - I'll make the change for both of the flash update counts. > >> >>> >>> + >>> +What:
Re: [PATCH 06/12] dma-direct: remove dma_direct_{alloc,free}_pages
On 2020-09-08 17:47, Christoph Hellwig wrote:
Just merge these helpers into the main dma_direct_{alloc,free} routines,
as the additional checks are always false for the two callers.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
arch/x86/kernel/amd_gart_64.c | 6 +++---
include/linux/dma-direct.h| 4
kernel/dma/direct.c | 39 ++-
kernel/dma/pool.c | 2 +-
4 files changed, 19 insertions(+), 32 deletions(-)
diff --git a/arch/x86/kernel/amd_gart_64.c b/arch/x86/kernel/amd_gart_64.c
index bccc5357bffd6c..153374b996a279 100644
--- a/arch/x86/kernel/amd_gart_64.c
+++ b/arch/x86/kernel/amd_gart_64.c
@@ -467,7 +467,7 @@ gart_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_addr,
{
void *vaddr;
- vaddr = dma_direct_alloc_pages(dev, size, dma_addr, flag, attrs);
+ vaddr = dma_direct_alloc(dev, size, dma_addr, flag, attrs);
if (!vaddr ||
!force_iommu || dev->coherent_dma_mask <= DMA_BIT_MASK(24))
return vaddr;
@@ -479,7 +479,7 @@ gart_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_addr,
goto out_free;
return vaddr;
out_free:
- dma_direct_free_pages(dev, size, vaddr, *dma_addr, attrs);
+ dma_direct_free(dev, size, vaddr, *dma_addr, attrs);
return NULL;
}
@@ -489,7 +489,7 @@ gart_free_coherent(struct device *dev, size_t size, void *vaddr,
dma_addr_t dma_addr, unsigned long attrs)
{
gart_unmap_page(dev, dma_addr, size, DMA_BIDIRECTIONAL, 0);
- dma_direct_free_pages(dev, size, vaddr, dma_addr, attrs);
+ dma_direct_free(dev, size, vaddr, dma_addr, attrs);
}
static int no_agp;
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index 95e3e28bd93f47..20eceb2e4f91f8 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -77,10 +77,6 @@ void *dma_direct_alloc(struct device *dev, size_t size,
dma_addr_t *dma_handle,
gfp_t gfp, unsigned long attrs);
void dma_direct_free(struct device *dev, size_t size, void *cpu_addr,
dma_addr_t dma_addr, unsigned long attrs);
-void *dma_direct_alloc_pages(struct device *dev, size_t size,
- dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs);
-void dma_direct_free_pages(struct device *dev, size_t size, void *cpu_addr,
- dma_addr_t dma_addr, unsigned long attrs);
int dma_direct_get_sgtable(struct device *dev, struct sg_table *sgt,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs);
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 949c1cbf08b2d5..1d564bea58571b 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -151,13 +151,18 @@ static struct page *__dma_direct_alloc_pages(struct
device *dev, size_t size,
return page;
}
-void *dma_direct_alloc_pages(struct device *dev, size_t size,
+void *dma_direct_alloc(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
{
struct page *page;
void *ret;
int err;
+ if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
+ !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
+ dma_alloc_need_uncached(dev, attrs))
+ return arch_dma_alloc(dev, size, dma_handle, gfp, attrs);
+
size = PAGE_ALIGN(size);
if (dma_should_alloc_from_pool(dev, gfp, attrs)) {
@@ -256,11 +261,18 @@ void *dma_direct_alloc_pages(struct device *dev, size_t
size,
return NULL;
}
-void dma_direct_free_pages(struct device *dev, size_t size, void *cpu_addr,
- dma_addr_t dma_addr, unsigned long attrs)
+void dma_direct_free(struct device *dev, size_t size,
+ void *cpu_addr, dma_addr_t dma_addr, unsigned long attrs)
{
unsigned int page_order = get_order(size);
+ if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
+ !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
+ dma_alloc_need_uncached(dev, attrs)) {
+ arch_dma_free(dev, size, cpu_addr, dma_addr, attrs);
+ return;
+ }
+
/* If cpu_addr is not from an atomic pool, dma_free_from_pool() fails */
if (dma_should_free_from_pool(dev, attrs) &&
dma_free_from_pool(dev, cpu_addr, PAGE_ALIGN(size)))
@@ -284,27 +296,6 @@ void dma_direct_free_pages(struct device *dev, size_t
size, void *cpu_addr,
dma_free_contiguous(dev, dma_direct_to_page(dev, dma_addr), size);
}
-void *dma_direct_alloc(struct device *dev, size_t size,
- dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
-{
- if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
- !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
- dma_alloc_need_uncached(dev, attrs))
- return arch_dma_alloc(dev, size, dma_handle, gfp, attrs);
-
Re: [PATCH net-next + leds v2 6/7] net: phy: marvell: add support for LEDs controlled by Marvell PHYs
On Thu, Sep 10, 2020 at 10:31:12PM +0200, Marek Behun wrote: > On Thu, 10 Sep 2020 19:34:35 +0100 > Russell King - ARM Linux admin wrote: > > > On Thu, Sep 10, 2020 at 08:31:54PM +0200, Andrew Lunn wrote: > > > Generally the driver will default to the hardware reset blink > > > pattern. There are a few PHY drivers which change this at probe, but > > > not many. The silicon defaults are pretty good. > > > > The "right" blink pattern can be a matter of how the hardware is > > wired. For example, if you have bi-colour LEDs and the PHY supports > > special bi-colour mixing modes. > > > > Have you seen such, Russell? This could be achieved via the multicolor > LED framework, but I don't have a device which uses such LEDs, so I > did not write support for this in the Marvell PHY driver. > > (I guess I could test it though, since on my device LED0 and LED1 > are used, and this to can be put into bi-colour LED mode.) I haven't, much to my dismay. The Macchiatobin would have been ideal - the 10G RJ45s have bi-colour on one side and green on the other. It would have been useful if they were wired to support the PHYs bi- colour mode. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
[PATCH v2 1/4] dt bindings: remoteproc: Add bindings for MT8183 APU
This adds dt bindings for the APU present in the MT8183.
Signed-off-by: Alexandre Bailon
---
.../bindings/remoteproc/mtk,apu.yaml | 107 ++
1 file changed, 107 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/mtk,apu.yaml
diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,apu.yaml
b/Documentation/devicetree/bindings/remoteproc/mtk,apu.yaml
new file mode 100644
index ..7a71d2f5c4e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/mtk,apu.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+
+---
+$id: "http://devicetree.org/schemas/remoteproc/mtk,apu.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: MT8183 AI Processor Unit (APU) a.k.a. Vision Processor Unit (VPU)
+
+description:
+ This document defines the binding for the APU, a co-processor that could
+ offload the CPU for machine learning and neural network.
+
+maintainers:
+ - Alexandre Bailon
+
+properties:
+ compatible:
+const: mediatek,mt8183-apu
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+description:
+ Three clocks are expected for AXI, IPU and JTAG.
+ The JTAG clock seems to be required to run the DSP,
+ even when JTAG is not in use."
+maxItems: 3
+
+ clock-names:
+items:
+ - const: axi
+ - const: ipu
+ - const: jtag
+
+ iommus:
+maxItems: 3
+
+ memory-region:
+maxItems: 1
+
+ power-domains:
+maxItems: 1
+
+ pinctrl:
+description: pinctrl handles, required to configure pins for JTAG.
+
+ pinctrl-names:
+items:
+ - const: jtag
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - iommus
+ - memory-region
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+#include
+
+reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ apu_ram: apu_ram@0x6000 {
+compatible = "shared-dma-pool";
+reg = <0x6000 0x04000>;
+no-map;
+linux,cma-default;
+ };
+};
+
+apu0: apu@1910 {
+ compatible = "mediatek,mt8183-apu";
+ reg = <0x1918 0x14000>;
+ interrupts = ;
+
+ iommus = < M4U_PORT_IMG_IPUO>,
+ < M4U_PORT_IMG_IPU3O>,
+ < M4U_PORT_IMG_IPUI>;
+
+ clocks = <_core0 CLK_IPU_CORE0_AXI>,
+ <_core0 CLK_IPU_CORE0_IPU>,
+ <_core0 CLK_IPU_CORE0_JTAG>;
+
+ clock-names = "axi", "ipu", "jtag";
+
+ power-domains = < MT8183_POWER_DOMAIN_VPU_CORE0>;
+ memory-region = <_ram>;
+};
+...
--
2.26.2
Re: [PATCH] documentation: arm: sunxi: Allwinner H2+/H3 update
Hi, On Tue, Sep 08, 2020 at 03:18:08PM +0200, Wilken Gottwalt wrote: > Updated information about H2+ and H3 difference and added a link to a > slightly newer datasheet. > > Signed-off-by: Wilken Gottwalt > --- > Documentation/arm/sunxi.rst | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/arm/sunxi.rst b/Documentation/arm/sunxi.rst > index b037428aee98..50b9199d929d 100644 > --- a/Documentation/arm/sunxi.rst > +++ b/Documentation/arm/sunxi.rst > @@ -103,12 +103,15 @@ SunXi family > > * No document available now, but is known to be working properly with >H3 drivers and memory map. > +* It is basically a H3 where the GMAC block was replaced by a 100 > MBit only MAC block. There's more to it (like 4k output in the display engine iirc), but I'm not really sure that it's this file purpose to document each variation between SoCs. >- Allwinner H3 (sun8i) > > * Datasheet > >http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf > + or a slightly more up to date version > + https://linux-sunxi.org/images/4/4b/Allwinner_H3_Datasheet_V1.2.pdf Why not just update the link? Maxime signature.asc Description: PGP signature
[PATCH v2 0/4] Add support of mt8183 APU
Some Mediatek's SoC have an Accelerated Processing Unit. This adds support of the one available in the mt8183 (aswell some derivative SoC). This series depends on two other series: - Mediatek MT8183 scpsys support - arm64: dts: Add m4u and smi-larbs nodes for mt8183 Changes in v2: - Drop the workarounds needed to load bad firmwares - There are many name for the APU (most common one is VPU). Rename many functions and dts nodes to be more consistent. - Use the bulk clock API, and enable / disable clock at a better place - add few comments explaining how to start the APU - update the way to use pinctl for JTAG - fix some minors issues - fix device tree bindings Alexandre Bailon (4): dt bindings: remoteproc: Add bindings for MT8183 APU remoteproc: Add a remoteproc driver for the MT8183's APU remoteproc: mtk_vpu_rproc: Add support of JTAG ARM64: mt8183: Add support of APU to mt8183 .../bindings/remoteproc/mtk,apu.yaml | 107 + arch/arm64/boot/dts/mediatek/mt8183.dtsi | 39 ++ drivers/remoteproc/Kconfig| 19 + drivers/remoteproc/Makefile | 1 + drivers/remoteproc/mtk_apu.c | 437 ++ 5 files changed, 603 insertions(+) create mode 100644 Documentation/devicetree/bindings/remoteproc/mtk,apu.yaml create mode 100644 drivers/remoteproc/mtk_apu.c -- 2.26.2
Re: WARNING in tracepoint_probe_register_prio (4)
syzbot has found a reproducer for the following issue on: HEAD commit:34d4ddd3 Merge tag 'linux-kselftest-5.9-rc5' of git://git... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=13ab2b7d90 kernel config: https://syzkaller.appspot.com/x/.config?x=8f5c353182ed6199 dashboard link: https://syzkaller.appspot.com/bug?extid=1b2f76c6fb6f549f728b compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=145c473590 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12d3162190 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+1b2f76c6fb6f549f7...@syzkaller.appspotmail.com [ cut here ] WARNING: CPU: 1 PID: 6978 at kernel/tracepoint.c:243 func_add kernel/tracepoint.c:147 [inline] WARNING: CPU: 1 PID: 6978 at kernel/tracepoint.c:243 tracepoint_add_func kernel/tracepoint.c:241 [inline] WARNING: CPU: 1 PID: 6978 at kernel/tracepoint.c:243 tracepoint_probe_register_prio+0x4ac/0x590 kernel/tracepoint.c:315 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 6978 Comm: syz-executor432 Not tainted 5.9.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1d6/0x29e lib/dump_stack.c:118 panic+0x2c0/0x800 kernel/panic.c:231 __warn+0x227/0x250 kernel/panic.c:600 report_bug+0x1b1/0x2e0 lib/bug.c:198 handle_bug+0x42/0x80 arch/x86/kernel/traps.c:234 exc_invalid_op+0x16/0x40 arch/x86/kernel/traps.c:254 asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:536 RIP: 0010:tracepoint_add_func kernel/tracepoint.c:147 [inline] RIP: 0010:tracepoint_probe_register_prio+0x4ac/0x590 kernel/tracepoint.c:315 Code: 48 89 df e8 16 b2 1f 00 89 c5 31 ff 89 c6 e8 1b 7c fe ff 85 ed 7e 1a e8 02 78 fe ff eb 20 e8 fb 77 fe ff 49 c7 c7 ef ff ff ff <0f> 0b 44 89 fd eb 4f e8 e8 77 fe ff 48 89 df e8 30 b8 1f 00 31 ed RSP: 0018:c900055a7c38 EFLAGS: 00010293 RAX: 81768595 RBX: dc00 RCX: 88808d43e1c0 RDX: RSI: 000a RDI: 000a RBP: 88809d603660 R08: 8176831e R09: fbfff13164de R10: fbfff13164de R11: R12: 000a R13: 0003 R14: R15: ffef bpf_raw_tracepoint_open kernel/bpf/syscall.c:2741 [inline] __do_sys_bpf+0x63ae/0x11060 kernel/bpf/syscall.c:4220 do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x446bd9 Code: e8 8c e7 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b 07 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f6d31c3eda8 EFLAGS: 0246 ORIG_RAX: 0141 RAX: ffda RBX: 006dbc38 RCX: 00446bd9 RDX: 0010 RSI: 21c0 RDI: 0011 RBP: 006dbc30 R08: R09: R10: R11: 0246 R12: 006dbc3c R13: 2100 R14: 004aebc0 R15: 0064 Kernel Offset: disabled Rebooting in 86400 seconds..
Re: [PATCH] mm: don't rely on system state to detect hot-plug operations
On 10.09.20 14:47, Michal Hocko wrote: > On Thu 10-09-20 14:03:48, Oscar Salvador wrote: >> On Thu, Sep 10, 2020 at 01:35:32PM +0200, Laurent Dufour wrote: >> >>> That points has been raised by David, quoting him here: >>> IIRC, ACPI can hotadd memory while SCHEDULING, this patch would break that. Ccing Oscar, I think he mentioned recently that this is the case with ACPI. >>> >>> Oscar told that he need to investigate further on that. >> >> I think my reply got lost. >> >> We can see acpi hotplugs during SYSTEM_SCHEDULING: >> >> $QEMU -enable-kvm -machine pc -smp 4,sockets=4,cores=1,threads=1 -cpu host >> -monitor pty \ >> -m size=$MEM,slots=255,maxmem=4294967296k \ >> -numa node,nodeid=0,cpus=0-3,mem=512 -numa node,nodeid=1,mem=512 \ >> -object memory-backend-ram,id=memdimm0,size=134217728 -device >> pc-dimm,node=0,memdev=memdimm0,id=dimm0,slot=0 \ >> -object memory-backend-ram,id=memdimm1,size=134217728 -device >> pc-dimm,node=0,memdev=memdimm1,id=dimm1,slot=1 \ >> -object memory-backend-ram,id=memdimm2,size=134217728 -device >> pc-dimm,node=0,memdev=memdimm2,id=dimm2,slot=2 \ >> -object memory-backend-ram,id=memdimm3,size=134217728 -device >> pc-dimm,node=0,memdev=memdimm3,id=dimm3,slot=3 \ >> -object memory-backend-ram,id=memdimm4,size=134217728 -device >> pc-dimm,node=1,memdev=memdimm4,id=dimm4,slot=4 \ >> -object memory-backend-ram,id=memdimm5,size=134217728 -device >> pc-dimm,node=1,memdev=memdimm5,id=dimm5,slot=5 \ >> -object memory-backend-ram,id=memdimm6,size=134217728 -device >> pc-dimm,node=1,memdev=memdimm6,id=dimm6,slot=6 \ >> >> kernel: [0.753643] __add_memory: nid: 0 start: 01 - 010800 >> (size: 134217728) >> kernel: [0.756950] register_mem_sect_under_node: system_state= 1 >> >> kernel: [0.760811] register_mem_sect_under_node+0x4f/0x230 >> kernel: [0.760811] walk_memory_blocks+0x80/0xc0 >> kernel: [0.760811] link_mem_sections+0x32/0x40 >> kernel: [0.760811] add_memory_resource+0x148/0x250 >> kernel: [0.760811] __add_memory+0x5b/0x90 >> kernel: [0.760811] acpi_memory_device_add+0x130/0x300 >> kernel: [0.760811] acpi_bus_attach+0x13c/0x1c0 >> kernel: [0.760811] acpi_bus_attach+0x60/0x1c0 >> kernel: [0.760811] acpi_bus_scan+0x33/0x70 >> kernel: [0.760811] acpi_scan_init+0xea/0x21b >> kernel: [0.760811] acpi_init+0x2f1/0x33c >> kernel: [0.760811] do_one_initcall+0x46/0x1f4 > > Is there any actual usecase for a configuration like this? What is the > point to statically define additional memory like this when the same can > be achieved on the same command line? You can online it movable right away to unplug later. Also, under QEMU, just do a reboot with hotplugged memory and you're in the very same situation. -- Thanks, David / dhildenb
RE: [PATCH -rc v1] gcov: Disable gcov build with GCC 10
From: Linus Torvalds > Sent: 10 September 2020 20:19 > > On Thu, Sep 10, 2020 at 5:52 AM Peter Oberparleiter > wrote: > > > > Fix this by updating the in-kernel GCOV_COUNTERS value. Also re-enable > > config GCOV_KERNEL for use with GCC 10. > > Lovely. > > Is there some way we could see this value automatically, or at least > have a check for it? Right now it's that _very_ magical number that > depends on a gcc version in odd and undocumented ways.. > > IOW - I'm assuming user space gcov infrastructure finds this number > some way, and wondering if we couldn't do the same? > > Or is the gcov tool itself just doing the same kind of thing, and > having magic numbers? > > I get the feeling that somebody who knows gcov would go "You are just > doing this all completely incorrectly, you should do XYZ" when they > see that GCOV_COUNTERS thing. > > Maybe just a script that finds the right header file in the gcc > installation and extracts it from there, if only to verify the magic > number that we have? I was wondering what happens if files compiled with different versions of gcc get linked together? Not too far-fetched for someone to release a .a file containing 'gconv' objects. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH] sched/fair: use dst group while checking imbalance for NUMA balancer
Hi Hilf and Mel, thanks a lot for bringing this to my attention. We have tested the proposed patch and we are getting excellent results so far! 1) Threads stability has improved a lot. We see much fewer threads migrations. Check for example this heatmap based on the mpstat results collected while running sp.C test from the NAS benchmark. sp.C was run with 16 threads on a dual-socket AMD 7351 server with 8 NUMA nodes: 5.9 vanilla https://drive.google.com/file/d/10rojhTSQUSu-1aGQi-srr99SmVQ3Llgo/view?usp=sharing 5.9 with the patch https://drive.google.com/file/d/1eZdTBWvWMNvdvXqitwAlcKZ7gb-ySQUl/view?usp=sharing The heatmaps are generated from the mpstat output (there are 5 different runs at one picture). We collect CPU utilization every 5 seconds. Lighter color corresponds to lower CPU utilization. Light color means that the thread may have run on different CPUs during that 5 seconds. Solid straight lines, on the other hand, mean that thread was running on the same CPU all the time. The difference is striking. We see significantly fewer threads migrations across many different tests - NAS, SPECjbb2005, SPECjvm2008 2) We see also performance improvement in terms of runtime, especially at low load scenarios (number of threads being roughly equal to the 2* number of NUMA nodes). It fixes the performance drop which we see since 5.7 kernel, discussed for example here: https://lore.kernel.org/lkml/CAE4VaGB7+sR1nf3Ux8W=hgn46gnxryr0ubwju0oynk7h00y...@mail.gmail.com/ The biggest improvements are for the NAS and the SPECjvm2008 benchmarks (typically between 20-50%). SPECjbb2005 shows also improvements, around 10%. This is again on NUMA servers at the low utilization. You can find snapshots of some results here: https://drive.google.com/drive/folders/1k3Gb-vlI7UjPZZcLkoL2W2VB_zqxIJ3_?usp=sharing @Mel - could you please test the proposed patch? I know you have good coverage for the inter-process communication benchmarks which may show different behavior than benchmarks which we use. I hope that fewer threads migrations might show positive effects also for these tests. Please give it a try. Thanks a lot! Jirka On Tue, Sep 8, 2020 at 3:07 AM Hillf Danton wrote: > > > On Mon, 7 Sep 2020 18:01:06 +0530 Srikar Dronamraju wrote: > > > > On Mon, Sep 07, 2020 at 07:27:08PM +1200, Barry Song wrote: > > > > > Something is wrong. In find_busiest_group(), we are checking if src > > > > > has > > > > > higher load, however, in task_numa_find_cpu(), we are checking if dst > > > > > will have higher load after balancing. It seems it is not sensible to > > > > > check src. > > > > > It maybe cause wrong imbalance value, for example, if > > > > > dst_running = env->dst_stats.nr_running + 1 results in 3 or above, and > > > > > src_running = env->src_stats.nr_running - 1 results in 1; > > > > > The current code is thinking imbalance as 0 since src_running is > > > > > smaller > > > > > than 2. > > > > > This is inconsistent with load balancer. > > > > > > > Hi Srikar and Barry > > > > I have observed the similar behaviour what Barry Song has documented with a > > simple ebizzy with less threads on a 2 node system > > Thanks for your testing. > > > > ebizzy -t 6 -S 100 > > > > We see couple of ebizzy threads moving back and forth between the 2 nodes > > because of numa balancer and load balancer trying to do the exact opposite. > > > > However with Barry's patch, couple of tests regress heavily. (Any numa > > workload that has shared numa faults). > > For example: > > perf bench numa mem --no-data_rand_walk -p 1 -t 6 -G 0 -P 3072 -T 0 -l 50 -c > > > > I also don't understand the rational behind checking for dst_running in numa > > balancer path. This almost means no numa balancing in lightly loaded > > scenario. > > > > So agree with Mel that we should probably test more scenarios before > > we accept this patch. > > Take a look at Jirka's work [1] please if you have any plan to do some > more tests. > > [1] > https://lore.kernel.org/lkml/CAE4VaGB7+sR1nf3Ux8W=hgn46gnxryr0ubwju0oynk7h00y...@mail.gmail.com/ > > > > > > > > > > It checks the conditions if the move was to happen. Have you evaluated > > > > this for a NUMA balancing load and confirmed it a) balances properly and > > > > b) does not increase the scan rate trying to "fix" the problem? > > > > > > I think the original code was trying to check if the numa migration > > > would lead to new imbalance in load balancer. In case src is A, dst is B, > > > and > > > both of them have nr_running as 2. A moves one task to B, then A > > > will have 1, B will have 3. In load balancer, A will try to pull task > > > from B since B's nr_running is larger than min_imbalance. But the code > > > is saying imbalance=0 by finding A's nr_running is smaller than > > > min_imbalance. > > > > > > Will share more test data if you need. > > > > > > > > > > > -- > > > > Mel Gorman > > > > SUSE Labs > > > > > > Thanks > > > Barry > > > > -- > > Thanks and Regards > > Srikar Dronamraju > >
[PATCH v2 2/2] ASoC: ti: j721e-evm: Add support for j7200-cpb audio
When j7200 SOM is attached to the CPB we only have parent clock for 48KHz
family and the rate of the parent clock is 2359296000Hz.
Signed-off-by: Peter Ujfalusi
---
sound/soc/ti/j721e-evm.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/sound/soc/ti/j721e-evm.c b/sound/soc/ti/j721e-evm.c
index cb074af47a7d..29b73303f3fc 100644
--- a/sound/soc/ti/j721e-evm.c
+++ b/sound/soc/ti/j721e-evm.c
@@ -525,6 +525,14 @@ static const struct j721e_audio_match_data
j721e_cpb_ivi_data = {
},
};
+static const struct j721e_audio_match_data j7200_cpb_data = {
+ .board_type = J721E_BOARD_CPB,
+ .num_links = 2, /* CPB pcm3168a */
+ .pll_rates = {
+ [J721E_CLK_PARENT_48000] = 2359296000u, /* PLL4 */
+ },
+};
+
static const struct of_device_id j721e_audio_of_match[] = {
{
.compatible = "ti,j721e-cpb-audio",
@@ -532,6 +540,9 @@ static const struct of_device_id j721e_audio_of_match[] = {
}, {
.compatible = "ti,j721e-cpb-ivi-audio",
.data = _cpb_ivi_data,
+ }, {
+ .compatible = "ti,j7200-cpb-audio",
+ .data = _cpb_data,
},
{ },
};
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH] i2c: stm32: do not display error when DMA is not requested
> Indeed, that's a good point. I'll rework it then, to avoid the dependency > on dev_err_probe change. If that is ok, I propose to push a two patches serie > with both this fix (updated) followed by a rebased version of the > dev_err_probe patch from Krzysztof for dev_err_probe change. Perfect! signature.asc Description: PGP signature
Re: [PATCH] mm: don't rely on system state to detect hot-plug operations
Le 10/09/2020 à 14:00, David Hildenbrand a écrit : On 10.09.20 13:35, Laurent Dufour wrote: Le 10/09/2020 à 13:12, Michal Hocko a écrit : On Thu 10-09-20 09:51:39, Laurent Dufour wrote: Le 10/09/2020 à 09:23, Michal Hocko a écrit : On Wed 09-09-20 18:07:15, Laurent Dufour wrote: Le 09/09/2020 à 12:59, Michal Hocko a écrit : On Wed 09-09-20 11:21:58, Laurent Dufour wrote: [...] For the point a, using the enum allows to know in register_mem_sect_under_node() if the link operation is due to a hotplug operation or done at boot time. Yes, but let me repeat. We have a mess here and different paths check for the very same condition by different ways. We need to unify those. What are you suggesting to unify these checks (using a MP_* enum as suggested by David, something else)? We do have system_state check spread at different places. I would use this one and wrap it behind a helper. Or have I missed any reason why that wouldn't work for this case? That would not work in that case because memory can be hot-added at the SYSTEM_SCHEDULING system state and the regular memory is also registered at that system state too. So system state is not enough to discriminate between the both. If that is really the case all other places need a fix as well. Btw. could you be more specific about memory hotplug during early boot? How that happens? I am only aware of https://lkml.kernel.org/r/20200818110046.6664-1-osalva...@suse.de and that doesn't happen as early as SYSTEM_SCHEDULING. That points has been raised by David, quoting him here: IIRC, ACPI can hotadd memory while SCHEDULING, this patch would break that. Ccing Oscar, I think he mentioned recently that this is the case with ACPI. Oscar told that he need to investigate further on that. On my side I can't get these ACPI "early" hot-plug operations to happen so I can't check that. If this is clear that ACPI memory hotplug doesn't happen at SYSTEM_SCHEDULING, the patch I proposed at first is enough to fix the issue. Booting a qemu guest with 4 coldplugged DIMMs gives me: :/root# dmesg | grep link_mem [0.302247] link_mem_sections() during 1 [0.445086] link_mem_sections() during 1 [0.445766] link_mem_sections() during 1 [0.446749] link_mem_sections() during 1 [0.447746] link_mem_sections() during 1 So AFAICs everything happens during SYSTEM_SCHEDULING - boot memory and ACPI (cold)plug. To make forward progress with this, relying on the system_state is obviously not sufficient. 1. We have to fix this instance and the instance directly in get_nid_for_pfn() by passing in the context (I once had a patch to clean that up, to not have two state checks, but it got lost somewhere). 2. The "system_state < SYSTEM_RUNNING" check in register_memory_resource() is correct. Actual memory hotplug after boot is not impacted. (I remember we discussed this exact behavior back then) 3. build_all_zonelists() should work as expected, called from start_kernel() before sched_init(). I'm bit confused now. Since hotplug operation is happening at SYSTEM_SCHEDULING like the regular memory registration, would it be enough to add a parameter to register_mem_sect_under_node() (reworking the memmap_context enum)? That way the check is not based on the system state but on the calling path.
[PATCH v2 0/2] ASoC: ti: j721e-evm: Support for j7200 variant
Hi, Changes since v1: - Suffix the 2359296000 constant with 'u' to silence C90 warning When j7200 SOM is connected to the CPB, the audio setup is a bit different: Only 48KHz family have clock path, 44.1KHz is not supported. Update the binding documentation and add support for the j7200 version of CPB to the driver. Regards, Peter --- Peter Ujfalusi (2): ASoC: dt-bindings: ti,j721e-cpb-audio: Document support for j7200-cpb ASoC: ti: j721e-evm: Add support for j7200-cpb audio .../bindings/sound/ti,j721e-cpb-audio.yaml| 92 ++- sound/soc/ti/j721e-evm.c | 11 +++ 2 files changed, 81 insertions(+), 22 deletions(-) -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 1/6] kprobes: Init kprobes in early_initcall
Init kprobes feature in early_initcall as same as jump_label and dynamic_debug does, so that we can use kprobes events in earlier boot stage. Signed-off-by: Masami Hiramatsu --- kernel/kprobes.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 2880cdf37c47..7d1fbdaa7a08 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -2528,7 +2528,7 @@ static int __init init_kprobes(void) init_test_probes(); return err; } -subsys_initcall(init_kprobes); +early_initcall(init_kprobes); #ifdef CONFIG_DEBUG_FS static void report_probe(struct seq_file *pi, struct kprobe *p,
[PATCH 2/6] tracing: Define event fields early stage
Define event fields at early stage so that boot-time tracing can
access the event fields (like per-event filter setting).
Signed-off-by: Masami Hiramatsu
---
kernel/trace/trace_events.c | 92 ++-
1 file changed, 55 insertions(+), 37 deletions(-)
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index a85effb2373b..a2531301b44f 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -2123,12 +2123,48 @@ event_subsystem_dir(struct trace_array *tr, const char
*name,
return NULL;
}
+static int
+event_define_fields(struct trace_event_call *call)
+{
+ struct list_head *head;
+ int ret = 0;
+
+ /*
+* Other events may have the same class. Only update
+* the fields if they are not already defined.
+*/
+ head = trace_get_fields(call);
+ if (list_empty(head)) {
+ struct trace_event_fields *field = call->class->fields_array;
+ unsigned int offset = sizeof(struct trace_entry);
+
+ for (; field->type; field++) {
+ if (field->type == TRACE_FUNCTION_TYPE) {
+ field->define_fields(call);
+ break;
+ }
+
+ offset = ALIGN(offset, field->align);
+ ret = trace_define_field(call, field->type, field->name,
+offset, field->size,
+field->is_signed,
field->filter_type);
+ if (WARN_ON_ONCE(ret)) {
+ pr_err("error code is %d\n", ret);
+ break;
+ }
+
+ offset += field->size;
+ }
+ }
+
+ return ret;
+}
+
static int
event_create_dir(struct dentry *parent, struct trace_event_file *file)
{
struct trace_event_call *call = file->event_call;
struct trace_array *tr = file->tr;
- struct list_head *head;
struct dentry *d_events;
const char *name;
int ret;
@@ -2162,35 +2198,10 @@ event_create_dir(struct dentry *parent, struct
trace_event_file *file)
_event_id_fops);
#endif
- /*
-* Other events may have the same class. Only update
-* the fields if they are not already defined.
-*/
- head = trace_get_fields(call);
- if (list_empty(head)) {
- struct trace_event_fields *field = call->class->fields_array;
- unsigned int offset = sizeof(struct trace_entry);
-
- for (; field->type; field++) {
- if (field->type == TRACE_FUNCTION_TYPE) {
- ret = field->define_fields(call);
- break;
- }
-
- offset = ALIGN(offset, field->align);
- ret = trace_define_field(call, field->type, field->name,
-offset, field->size,
-field->is_signed,
field->filter_type);
- if (ret)
- break;
-
- offset += field->size;
- }
- if (ret < 0) {
- pr_warn("Could not initialize trace point events/%s\n",
- name);
- return -1;
- }
+ ret = event_define_fields(call);
+ if (ret < 0) {
+ pr_warn("Could not initialize trace point events/%s\n", name);
+ return ret;
}
/*
@@ -2493,7 +2504,7 @@ __trace_early_add_new_event(struct trace_event_call *call,
if (!file)
return -ENOMEM;
- return 0;
+ return event_define_fields(call);
}
struct ftrace_module_file_ops;
@@ -3431,6 +3442,18 @@ static __init int event_trace_enable_again(void)
early_initcall(event_trace_enable_again);
+/* Init fields which doesn't related to the tracefs */
+static __init int event_trace_init_fields(void)
+{
+ if (trace_define_generic_fields())
+ pr_warn("tracing: Failed to allocated generic fields");
+
+ if (trace_define_common_fields())
+ pr_warn("tracing: Failed to allocate common fields");
+
+ return 0;
+}
+
__init int event_trace_init(void)
{
struct trace_array *tr;
@@ -3451,12 +3474,6 @@ __init int event_trace_init(void)
if (!entry)
pr_warn("Could not create tracefs 'available_events' entry\n");
- if (trace_define_generic_fields())
- pr_warn("tracing: Failed to allocated generic fields");
-
- if (trace_define_common_fields())
- pr_warn("tracing: Failed to allocate common fields");
-
ret =
Re: [PATCH v7 71/72] x86/efi: Add GHCB mappings when SEV-ES is active
On Wed, 9 Sep 2020 at 16:49, Tom Lendacky wrote:
>
> On 9/9/20 7:44 AM, Laszlo Ersek wrote:
> > On 09/09/20 10:27, Ard Biesheuvel wrote:
> >> (adding Laszlo and Brijesh)
> >>
> >> On Tue, 8 Sep 2020 at 20:46, Borislav Petkov wrote:
> >>>
> >>> + Ard so that he can ack the efi bits.
> >>>
> >>> On Mon, Sep 07, 2020 at 03:16:12PM +0200, Joerg Roedel wrote:
> From: Tom Lendacky
>
> Calling down to EFI runtime services can result in the firmware
> performing VMGEXIT calls. The firmware is likely to use the GHCB of
> the OS (e.g., for setting EFI variables),
> >
> > I've had to stare at this for a while.
> >
> > Because, normally a VMGEXIT is supposed to occur like this:
> >
> > - guest does something privileged
> > - resultant non-automatic exit (NAE) injects a #VC exception
> > - exception handler figures out what that privileged thing was
> > - exception handler submits request to hypervisor via GHCB contents plus
> >VMGEXIT instruction
> >
> > Point being, the agent that "owns" the exception handler is supposed to
> > pre-allocate or otherwise provide the GHCB too, for information passing.
> >
> > So... what is the particular NAE that occurs during the execution of
> > UEFI runtime services (at OS runtime)?
> >
> > And assuming it occurs, I'm unsure if the exception handler (IDT) at
> > that point is owned (temporarily?) by the firmware.
> >
> > - If the #VC handler comes from the firmware, then I don't know why it
> > would use the OS's GHCB.
> >
> > - If the #VC handler comes from the OS, then I don't understand why the
> > commit message says "firmware performing VMGEXIT", given that in this
> > case it would be the OS's #VC handler executing VMGEXIT.
> >
> > So, I think the above commit message implies a VMGEXIT *without* a NAE /
> > #VC context. (Because, I fail to interpret the commit message in a NAE /
> > #VC context in any way; see above.)
>
> Correct.
>
> >
> > OK, so let's see where the firmware performs a VMGEXIT *outside* of an
> > exception handler, *while* at OS runtime. There seems to be one, in file
> > "OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlashDxe.c":
>
> Again, correct. Basically this is what is invoked when setting UEFI variables.
>
> >
> >> VOID
> >> QemuFlashPtrWrite (
> >>INvolatile UINT8*Ptr,
> >>INUINT8 Value
> >>)
> >> {
> >>if (MemEncryptSevEsIsEnabled ()) {
> >> MSR_SEV_ES_GHCB_REGISTER Msr;
> >> GHCB *Ghcb;
> >>
> >> Msr.GhcbPhysicalAddress = AsmReadMsr64 (MSR_SEV_ES_GHCB);
> >> Ghcb = Msr.Ghcb;
> >>
> >> //
> >> // Writing to flash is emulated by the hypervisor through the use of
> >> write
> >> // protection. This won't work for an SEV-ES guest because the write
> >> won't
> >> // be recognized as a true MMIO write, which would result in the
> >> required
> >> // #VC exception. Instead, use the the VMGEXIT MMIO write support
> >> directly
> >> // to perform the update.
> >> //
> >> VmgInit (Ghcb);
> >> Ghcb->SharedBuffer[0] = Value;
> >> Ghcb->SaveArea.SwScratch = (UINT64) (UINTN) Ghcb->SharedBuffer;
> >> VmgExit (Ghcb, SVM_EXIT_MMIO_WRITE, (UINT64) (UINTN) Ptr, 1);
> >> VmgDone (Ghcb);
> >>} else {
> >> *Ptr = Value;
> >>}
> >> }
> >
> > This function *does* run at OS runtime (as a part of non-volatile UEFI
> > variable writes).
> >
> > And note that, wherever MSR_SEV_ES_GHCB points to at the moment, is used
> > as GHCB.
> >
> > If the guest kernel allocates its own GHCB and writes the allocation
> > address to MSR_SEV_ES_GHCB, then indeed the firmware will use the GHCB
> > of the OS.
> >
> > I reviewed edk2 commit 437eb3f7a8db
> > ("OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Bypass flash detection with
> > SEV-ES", 2020-08-17), but I admit I never thought of the guest OS
> > changing MSR_SEV_ES_GHCB. I'm sorry about that.
> >
> > As long as this driver is running before OS runtime (i.e., during the
> > DXE and BDS phases), MSR_SEV_ES_GHCB is supposed to carry the value we
> > set in "OvmfPkg/PlatformPei/AmdSev.c":
> >
> >> STATIC
> >> VOID
> >> AmdSevEsInitialize (
> >>VOID
> >>)
> >> {
> >>VOID *GhcbBase;
> >>PHYSICAL_ADDRESS GhcbBasePa;
> >>UINTN GhcbPageCount, PageCount;
> >>RETURN_STATUS PcdStatus, DecryptStatus;
> >>IA32_DESCRIPTOR Gdtr;
> >>VOID *Gdt;
> >>
> >>if (!MemEncryptSevEsIsEnabled ()) {
> >> return;
> >>}
> >>
> >>PcdStatus = PcdSetBoolS (PcdSevEsIsEnabled, TRUE);
> >>ASSERT_RETURN_ERROR (PcdStatus);
> >>
> >>//
> >>// Allocate GHCB and per-CPU variable pages.
> >>// Since the pages must survive across the UEFI to OS transition
> >>// make them reserved.
> >>//
> >>GhcbPageCount = mMaxCpuCount * 2;
> >>GhcbBase = AllocateReservedPages (GhcbPageCount);
> >>ASSERT (GhcbBase != NULL);
> >>
> >>GhcbBasePa =
[PATCH 0/6] tracing/boot: Start boot-time tracing in earlier stage
Hi,
Here is a series of patches which starts the boot-time tracing earlier,
core_initcall_sync, so that we can start tracing from postcore_initcall
instead of device_initcall.
The boot-time tracing is useful for debugging kernel drivers which are
embedded in the kernel. Since most of the drivers are initialized in the
device_initcall, the boot-time tracing which starts in fs_initcall, can
trace them. However, many frameworks and platform drivers are initialized
in subsys_initcall or arch_initcall and the boot-time tracing still
misses it.
This series will improve the boot-time tracing to trace those events.
- Move kprobes initialization into early_initcall from subsys_initcall
as same as jump_label and dynamic_debug.
Previously arm64 didn't allow it, but commit b322c65f8ca3 ("arm64:
Call debug_traps_init() from trap_init() to help early kgdb") fixed it.
- Fixes tracing init routines to decouple the tracefs entry creation
and the data-structure allocation/initialization.
- Move dynamic-events initialization to core_initcall and call boot-time
tracing in core_initcall_sync (the core_initcall_sync is called after
all core_initcall functions are done).
Thank you,
---
Masami Hiramatsu (6):
kprobes: Init kprobes in early_initcall
tracing: Define event fields early stage
tracing: Enable adding dynamic events early stage
tracing: Enable creating new instance early boot
tracing/boot,kprobe,synth: Initialize boot-time tracing earlier
Documentation: tracing: Add the startup timing of boot-time tracing
Documentation/trace/boottime-trace.rst | 14
kernel/kprobes.c |2 -
kernel/trace/trace.c | 53 +
kernel/trace/trace.h |7 ++
kernel/trace/trace_boot.c |7 ++
kernel/trace/trace_events.c| 101
kernel/trace/trace_events_synth.c | 22 +--
kernel/trace/trace_functions.c | 22 ---
kernel/trace/trace_kprobe.c|6 +-
9 files changed, 165 insertions(+), 69 deletions(-)
--
Masami Hiramatsu (Linaro)
[PATCH] scsi: mvumi: Fix error return in mvumi_io_attach()
Fix to return error code PTR_ERR() from the error handling case instead
of 0.
Signed-off-by: Jing Xiangfeng
---
drivers/scsi/mvumi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/mvumi.c b/drivers/scsi/mvumi.c
index 8906aceda4c4..0354898d7cac 100644
--- a/drivers/scsi/mvumi.c
+++ b/drivers/scsi/mvumi.c
@@ -2425,6 +2425,7 @@ static int mvumi_io_attach(struct mvumi_hba *mhba)
if (IS_ERR(mhba->dm_thread)) {
dev_err(>pdev->dev,
"failed to create device scan thread\n");
+ ret = PTR_ERR(mhba->dm_thread);
mutex_unlock(>sas_discovery_mutex);
goto fail_create_thread;
}
--
2.17.1
Re: [PATCH 03/14] XArray: docs: add missing kernel-doc parameters for xas_split_alloc()
Em Thu, 10 Sep 2020 12:13:22 +0100 Matthew Wilcox escreveu: > On Thu, Sep 10, 2020 at 12:23:56PM +0200, Mauro Carvalho Chehab wrote: > > /** > > - * Allocate memory for splitting an entry of @order size into the order > > - * stored in the @xas. > > + * xas_split_alloc() - Allocate memory for splitting an entry of > > + *@order size into the order stored in the @xas. > > + * > > + * @xas: is the 'xarray operation state'. It may be either a pointer to > > + * an xa_state, or an xa_state stored on the stack. This is an unfortunate > > + * ambiguity. > > + * @entry: refers to something stored in a slot in the xarray > > + * @order: size of each entry > > + * @gfp: GFP allocation flags > > */ > > No. I'll do this properly. Thanks! Yeah, you should be able to document it better than me, as I'm not familiar with XArray subsystem ;-) > Sorry for forgetting to document the arguments. No problem. I know it was hard to identify such warnings in the past, as we used to have hundreds of warnings. Btw, while writing this series that finally gets rid of them, I even identified one such warning on media that slept though my review ;-) Thanks, Mauro
Re: [PATCH] mm: don't rely on system state to detect hot-plug operations
On 10.09.20 14:36, Laurent Dufour wrote: > Le 10/09/2020 à 14:00, David Hildenbrand a écrit : >> On 10.09.20 13:35, Laurent Dufour wrote: >>> Le 10/09/2020 à 13:12, Michal Hocko a écrit : On Thu 10-09-20 09:51:39, Laurent Dufour wrote: > Le 10/09/2020 à 09:23, Michal Hocko a écrit : >> On Wed 09-09-20 18:07:15, Laurent Dufour wrote: >>> Le 09/09/2020 à 12:59, Michal Hocko a écrit : On Wed 09-09-20 11:21:58, Laurent Dufour wrote: >> [...] > For the point a, using the enum allows to know in > register_mem_sect_under_node() if the link operation is due to a > hotplug > operation or done at boot time. Yes, but let me repeat. We have a mess here and different paths check for the very same condition by different ways. We need to unify those. >>> >>> What are you suggesting to unify these checks (using a MP_* enum as >>> suggested by David, something else)? >> >> We do have system_state check spread at different places. I would use >> this one and wrap it behind a helper. Or have I missed any reason why >> that wouldn't work for this case? > > That would not work in that case because memory can be hot-added at the > SYSTEM_SCHEDULING system state and the regular memory is also registered > at > that system state too. So system state is not enough to discriminate > between > the both. If that is really the case all other places need a fix as well. Btw. could you be more specific about memory hotplug during early boot? How that happens? I am only aware of https://lkml.kernel.org/r/20200818110046.6664-1-osalva...@suse.de and that doesn't happen as early as SYSTEM_SCHEDULING. >>> >>> That points has been raised by David, quoting him here: >>> IIRC, ACPI can hotadd memory while SCHEDULING, this patch would break that. Ccing Oscar, I think he mentioned recently that this is the case with ACPI. >>> >>> Oscar told that he need to investigate further on that. >>> >>> On my side I can't get these ACPI "early" hot-plug operations to happen so I >>> can't check that. >>> >>> If this is clear that ACPI memory hotplug doesn't happen at >>> SYSTEM_SCHEDULING, >>> the patch I proposed at first is enough to fix the issue. >>> >> >> Booting a qemu guest with 4 coldplugged DIMMs gives me: >> >> :/root# dmesg | grep link_mem >> [0.302247] link_mem_sections() during 1 >> [0.445086] link_mem_sections() during 1 >> [0.445766] link_mem_sections() during 1 >> [0.446749] link_mem_sections() during 1 >> [0.447746] link_mem_sections() during 1 >> >> So AFAICs everything happens during SYSTEM_SCHEDULING - boot memory and >> ACPI (cold)plug. >> >> To make forward progress with this, relying on the system_state is >> obviously not sufficient. >> >> 1. We have to fix this instance and the instance directly in >> get_nid_for_pfn() by passing in the context (I once had a patch to clean >> that up, to not have two state checks, but it got lost somewhere). >> >> 2. The "system_state < SYSTEM_RUNNING" check in >> register_memory_resource() is correct. Actual memory hotplug after boot >> is not impacted. (I remember we discussed this exact behavior back then) >> >> 3. build_all_zonelists() should work as expected, called from >> start_kernel() before sched_init(). > > I'm bit confused now. > Since hotplug operation is happening at SYSTEM_SCHEDULING like the regular > memory registration, would it be enough to add a parameter to > register_mem_sect_under_node() (reworking the memmap_context enum)? > That way the check is not based on the system state but on the calling path. > That would have been my suggestion to definitely fix it - maybe Michal/Oscar have a better suggestion know that we know what's going on. -- Thanks, David / dhildenb
[PATCH] Handle init_iova_flush_queue failure in dma-iommu path
init_iova_flush_queue can fail if we run out of memory. Fall back to noflush
queue if it fails.
Signed-off-by: Tom Murphy
---
drivers/iommu/dma-iommu.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 4959f5df21bd..5f69126f3e91 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -343,8 +343,11 @@ static int iommu_dma_init_domain(struct iommu_domain
*domain, dma_addr_t base,
if (!cookie->fq_domain && !iommu_domain_get_attr(domain,
DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE, ) && attr) {
- cookie->fq_domain = domain;
- init_iova_flush_queue(iovad, iommu_dma_flush_iotlb_all, NULL);
+ if (init_iova_flush_queue(iovad, iommu_dma_flush_iotlb_all,
+ NULL))
+ pr_warn("iova flush queue initialization failed\n");
+ else
+ cookie->fq_domain = domain;
}
if (!dev)
--
2.20.1
Re: [PATCH] mm: don't rely on system state to detect hot-plug operations
On Thu 10-09-20 14:03:48, Oscar Salvador wrote: > On Thu, Sep 10, 2020 at 01:35:32PM +0200, Laurent Dufour wrote: > > > That points has been raised by David, quoting him here: > > > > > IIRC, ACPI can hotadd memory while SCHEDULING, this patch would break > > > that. > > > > > > Ccing Oscar, I think he mentioned recently that this is the case with > > > ACPI. > > > > Oscar told that he need to investigate further on that. > > I think my reply got lost. > > We can see acpi hotplugs during SYSTEM_SCHEDULING: > > $QEMU -enable-kvm -machine pc -smp 4,sockets=4,cores=1,threads=1 -cpu host > -monitor pty \ > -m size=$MEM,slots=255,maxmem=4294967296k \ > -numa node,nodeid=0,cpus=0-3,mem=512 -numa node,nodeid=1,mem=512 \ > -object memory-backend-ram,id=memdimm0,size=134217728 -device > pc-dimm,node=0,memdev=memdimm0,id=dimm0,slot=0 \ > -object memory-backend-ram,id=memdimm1,size=134217728 -device > pc-dimm,node=0,memdev=memdimm1,id=dimm1,slot=1 \ > -object memory-backend-ram,id=memdimm2,size=134217728 -device > pc-dimm,node=0,memdev=memdimm2,id=dimm2,slot=2 \ > -object memory-backend-ram,id=memdimm3,size=134217728 -device > pc-dimm,node=0,memdev=memdimm3,id=dimm3,slot=3 \ > -object memory-backend-ram,id=memdimm4,size=134217728 -device > pc-dimm,node=1,memdev=memdimm4,id=dimm4,slot=4 \ > -object memory-backend-ram,id=memdimm5,size=134217728 -device > pc-dimm,node=1,memdev=memdimm5,id=dimm5,slot=5 \ > -object memory-backend-ram,id=memdimm6,size=134217728 -device > pc-dimm,node=1,memdev=memdimm6,id=dimm6,slot=6 \ > > kernel: [0.753643] __add_memory: nid: 0 start: 01 - 010800 > (size: 134217728) > kernel: [0.756950] register_mem_sect_under_node: system_state= 1 > > kernel: [0.760811] register_mem_sect_under_node+0x4f/0x230 > kernel: [0.760811] walk_memory_blocks+0x80/0xc0 > kernel: [0.760811] link_mem_sections+0x32/0x40 > kernel: [0.760811] add_memory_resource+0x148/0x250 > kernel: [0.760811] __add_memory+0x5b/0x90 > kernel: [0.760811] acpi_memory_device_add+0x130/0x300 > kernel: [0.760811] acpi_bus_attach+0x13c/0x1c0 > kernel: [0.760811] acpi_bus_attach+0x60/0x1c0 > kernel: [0.760811] acpi_bus_scan+0x33/0x70 > kernel: [0.760811] acpi_scan_init+0xea/0x21b > kernel: [0.760811] acpi_init+0x2f1/0x33c > kernel: [0.760811] do_one_initcall+0x46/0x1f4 Is there any actual usecase for a configuration like this? What is the point to statically define additional memory like this when the same can be achieved on the same command line? -- Michal Hocko SUSE Labs
Re: [PATCH 3/4] clk: meson: axg: add Video Clocks
Hi,
On 10/09/2020 12:13, Jerome Brunet wrote:
>
> On Mon 07 Sep 2020 at 11:38, Neil Armstrong wrote:
>
>> Add the Video Clocks present on the Amlogic AXg SoCs.
>>
>> The AXG only has a single ENCL CTS clock and even if VCLK exist along VCLK2,
>> only VCLK2 is used since it clocks the MIPI DSI IP directly.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/clk/meson/axg.c | 774
>> drivers/clk/meson/axg.h | 21 +-
>> 2 files changed, 794 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c
>> index 13fc0006f63d..2550616c14b0 100644
>> --- a/drivers/clk/meson/axg.c
>> +++ b/drivers/clk/meson/axg.c
>> @@ -1026,6 +1026,704 @@ static struct clk_regmap axg_sd_emmc_c_clk0 = {
>> },
>> };
>>
>> +/* VPU Clock */
>> +
>> +static const struct clk_hw *axg_vpu_parent_hws[] = {
>> +_fclk_div4.hw,
>> +_fclk_div3.hw,
>> +_fclk_div5.hw,
>> +_fclk_div7.hw,
>> +};
>> +
>> +static struct clk_regmap axg_vpu_0_sel = {
>> +.data = &(struct clk_regmap_mux_data){
>> +.offset = HHI_VPU_CLK_CNTL,
>> +.mask = 0x3,
>> +.shift = 9,
>> +},
>> +.hw.init = &(struct clk_init_data){
>> +.name = "vpu_0_sel",
>> +.ops = _regmap_mux_ops,
>> +/*
>> + * bits 9:10 selects from 4 possible parents:
>> + * fclk_div4, fclk_div3, fclk_div5, fclk_div7,
>> + */
>
> These comments (and the same bellow) are not very useful
Ok, these are copy/paste from gxbb.c and g12a.c, I wonder why these are now
useless.
>
>> +.parent_hws = axg_vpu_parent_hws,
>> +.num_parents = ARRAY_SIZE(axg_vpu_parent_hws),
>
> Could you add a comment here explaining why parenting needs to be
> manually controlled ?
Ditto, this was already explained for GXBB & G12A.
The VPU clock needs a specific clock parenting defined in DT to
achieve the frequency used by the vendor.
>
>> +.flags = CLK_SET_RATE_NO_REPARENT,
>> +},
>> +};
>> +
>> +static struct clk_regmap axg_vpu_0_div = {
>> +.data = &(struct clk_regmap_div_data){
>> +.offset = HHI_VPU_CLK_CNTL,
>> +.shift = 0,
>> +.width = 7,
>> +},
>> +.hw.init = &(struct clk_init_data){
>> +.name = "vpu_0_div",
>> +.ops = _regmap_divider_ops,
>> +.parent_hws = (const struct clk_hw *[]) { _vpu_0_sel.hw },
>> +.num_parents = 1,
>> +.flags = CLK_SET_RATE_PARENT,
>> +},
>> +};
>> +
>> +static struct clk_regmap axg_vpu_0 = {
>> +.data = &(struct clk_regmap_gate_data){
>> +.offset = HHI_VPU_CLK_CNTL,
>> +.bit_idx = 8,
>> +},
>> +.hw.init = &(struct clk_init_data) {
>> +.name = "vpu_0",
>> +.ops = _regmap_gate_ops,
>> +.parent_hws = (const struct clk_hw *[]) { _vpu_0_div.hw },
>> +.num_parents = 1,
>> +.flags = CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
>
> Why is UNUSED required ?
It's UNUSED until we have a mechanism to keep a clock enabled until the proper
module is loaded, and it was already discussed for GXBB & G12A.
>
>> +},
>> +};
>> +
>> +static struct clk_regmap axg_vpu_1_sel = {
>> +.data = &(struct clk_regmap_mux_data){
>> +.offset = HHI_VPU_CLK_CNTL,
>> +.mask = 0x3,
>> +.shift = 25,
>> +},
>> +.hw.init = &(struct clk_init_data){
>> +.name = "vpu_1_sel",
>> +.ops = _regmap_mux_ops,
>> +/*
>> + * bits 25:26 selects from 4 possible parents:
>> + * fclk_div4, fclk_div3, fclk_div5, fclk_div7,
>> + */
>> +.parent_hws = axg_vpu_parent_hws,
>> +.num_parents = ARRAY_SIZE(axg_vpu_parent_hws),
>> +.flags = CLK_SET_RATE_NO_REPARENT,
>> +},
>> +};
>> +
>> +static struct clk_regmap axg_vpu_1_div = {
>> +.data = &(struct clk_regmap_div_data){
>> +.offset = HHI_VPU_CLK_CNTL,
>> +.shift = 16,
>> +.width = 7,
>> +},
>> +.hw.init = &(struct clk_init_data){
>> +.name = "vpu_1_div",
>> +.ops = _regmap_divider_ops,
>> +.parent_hws = (const struct clk_hw *[]) { _vpu_1_sel.hw },
>> +.num_parents = 1,
>> +.flags = CLK_SET_RATE_PARENT,
>> +},
>> +};
>> +
>> +static struct clk_regmap axg_vpu_1 = {
>> +.data = &(struct clk_regmap_gate_data){
>> +.offset = HHI_VPU_CLK_CNTL,
>> +.bit_idx = 24,
>> +},
>> +.hw.init = &(struct clk_init_data) {
>> +.name = "vpu_1",
>> +.ops = _regmap_gate_ops,
>> +.parent_hws = (const struct clk_hw *[]) { _vpu_1_div.hw },
>> +.num_parents = 1,
>> +.flags = CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
>> +},
>> +};
>> +
>> +static struct clk_regmap axg_vpu = {
>> +.data = &(struct
[PATCH] vfio: Fix typo of the device_state
A typo fix ("_RUNNNG" => "_RUNNING") in comment block of the uapi header.
Signed-off-by: Zenghui Yu
---
include/uapi/linux/vfio.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 920470502329..d4bd39e124bf 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -462,7 +462,7 @@ struct vfio_region_gfx_edid {
* 5. Resumed
* |->|
*
- * 0. Default state of VFIO device is _RUNNNG when the user application starts.
+ * 0. Default state of VFIO device is _RUNNING when the user application
starts.
* 1. During normal shutdown of the user application, the user application may
*optionally change the VFIO device state from _RUNNING to _STOP. This
*transition is optional. The vendor driver must support this transition
but
--
2.19.1
[PATCH] usb: phy: tegra: Use IS_ERR() to check and simplify code
Use IS_ERR() and PTR_ERR() instead of PTR_ERR_OR_ZERO() to
simplify code, avoid redundant judgements.
Signed-off-by: Zhang Shengju
Signed-off-by: Tang Bin
---
drivers/usb/phy/phy-tegra-usb.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index 6153cc35a..3b901429d 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -1121,10 +1121,9 @@ static int tegra_usb_phy_probe(struct platform_device
*pdev)
return PTR_ERR(tegra_phy->vbus);
tegra_phy->pll_u = devm_clk_get(>dev, "pll_u");
- err = PTR_ERR_OR_ZERO(tegra_phy->pll_u);
- if (err) {
+ if (IS_ERR(tegra_phy->pll_u)) {
dev_err(>dev, "Failed to get pll_u clock: %d\n", err);
- return err;
+ return PTR_ERR(tegra_phy->pll_u);
}
phy_type = of_usb_get_phy_mode(np);
@@ -1135,20 +1134,18 @@ static int tegra_usb_phy_probe(struct platform_device
*pdev)
return err;
tegra_phy->pad_clk = devm_clk_get(>dev, "utmi-pads");
- err = PTR_ERR_OR_ZERO(tegra_phy->pad_clk);
- if (err) {
+ if (IS_ERR(tegra_phy->pad_clk)) {
dev_err(>dev,
"Failed to get UTMIP pad clock: %d\n", err);
- return err;
+ return PTR_ERR(tegra_phy->pad_clk);
}
reset = devm_reset_control_get_optional_shared(>dev,
"utmi-pads");
- err = PTR_ERR_OR_ZERO(reset);
- if (err) {
+ if (IS_ERR(reset)) {
dev_err(>dev,
"Failed to get UTMI-pads reset: %d\n", err);
- return err;
+ return PTR_ERR(reset);
}
tegra_phy->pad_rst = reset;
break;
@@ -1157,22 +1154,20 @@ static int tegra_usb_phy_probe(struct platform_device
*pdev)
tegra_phy->is_ulpi_phy = true;
tegra_phy->clk = devm_clk_get(>dev, "ulpi-link");
- err = PTR_ERR_OR_ZERO(tegra_phy->clk);
- if (err) {
+ if (IS_ERR(tegra_phy->clk)) {
dev_err(>dev,
"Failed to get ULPI clock: %d\n", err);
- return err;
+ return PTR_ERR(tegra_phy->clk);
}
gpiod = devm_gpiod_get_from_of_node(>dev, np,
"nvidia,phy-reset-gpio",
0, GPIOD_OUT_HIGH,
"ulpi_phy_reset_b");
- err = PTR_ERR_OR_ZERO(gpiod);
- if (err) {
+ if (IS_ERR(gpiod)) {
dev_err(>dev,
"Request failed for reset GPIO: %d\n", err);
- return err;
+ return PTR_ERR(gpiod);
}
tegra_phy->reset_gpio = gpiod;
--
2.20.1.windows.1
Re: [PATCH net-next + leds v2 6/7] net: phy: marvell: add support for LEDs controlled by Marvell PHYs
On Wed 2020-09-09 18:25:51, Marek Behún wrote: > This patch adds support for controlling the LEDs connected to several > families of Marvell PHYs via the PHY HW LED trigger API. These families > are: 88E1112, 88E1121R, 88E1240, 88E1340S, 88E1510 and 88E1545. More can > be added. > > This patch does not yet add support for compound LED modes. This could > be achieved via the LED multicolor framework. > > Settings such as HW blink rate or pulse stretch duration are not yet > supported. > > Signed-off-by: Marek Behún I suggest limiting to "useful" hardware modes, and documenting what those modes do somewhere. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: PGP signature
[PATCH v2] hv_netvsc: Add validation for untrusted Hyper-V values
From: Andres Beltran
For additional robustness in the face of Hyper-V errors or malicious
behavior, validate all values that originate from packets that Hyper-V
has sent to the guest in the host-to-guest ring buffer. Ensure that
invalid values cannot cause indexing off the end of an array, or
subvert an existing validation via integer overflow. Ensure that
outgoing packets do not have any leftover guest memory that has not
been zeroed out.
Signed-off-by: Andres Beltran
Co-developed-by: Andrea Parri (Microsoft)
Signed-off-by: Andrea Parri (Microsoft)
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: net...@vger.kernel.org
---
Changes in v2:
- Replace size check on struct nvsp_message with sub-checks (Haiyang)
drivers/net/hyperv/hyperv_net.h | 4 +
drivers/net/hyperv/netvsc.c | 120 ++
drivers/net/hyperv/netvsc_drv.c | 7 ++
drivers/net/hyperv/rndis_filter.c | 73 --
4 files changed, 184 insertions(+), 20 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 4d2b2d48ff2a1..da78bd0fb2aa2 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -860,6 +860,10 @@ static inline u32 netvsc_rqstor_size(unsigned long
ringbytes)
ringbytes / NETVSC_MIN_IN_MSG_SIZE;
}
+#define NETVSC_XFER_HEADER_SIZE(rng_cnt) \
+ (offsetof(struct vmtransfer_page_packet_header, ranges) + \
+ (rng_cnt) * sizeof(struct vmtransfer_page_range))
+
struct multi_send_data {
struct sk_buff *skb; /* skb containing the pkt */
struct hv_netvsc_packet *pkt; /* netvsc pkt pending */
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 03e93e3ddbad8..90b7a39c2dc78 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -388,6 +388,15 @@ static int netvsc_init_buf(struct hv_device *device,
net_device->recv_section_size = resp->sections[0].sub_alloc_size;
net_device->recv_section_cnt = resp->sections[0].num_sub_allocs;
+ /* Ensure buffer will not overflow */
+ if (net_device->recv_section_size < NETVSC_MTU_MIN ||
(u64)net_device->recv_section_size *
+ (u64)net_device->recv_section_cnt > (u64)buf_size) {
+ netdev_err(ndev, "invalid recv_section_size %u\n",
+ net_device->recv_section_size);
+ ret = -EINVAL;
+ goto cleanup;
+ }
+
/* Setup receive completion ring.
* Add 1 to the recv_section_cnt because at least one entry in a
* ring buffer has to be empty.
@@ -460,6 +469,12 @@ static int netvsc_init_buf(struct hv_device *device,
/* Parse the response */
net_device->send_section_size = init_packet->msg.
v1_msg.send_send_buf_complete.section_size;
+ if (net_device->send_section_size < NETVSC_MTU_MIN) {
+ netdev_err(ndev, "invalid send_section_size %u\n",
+ net_device->send_section_size);
+ ret = -EINVAL;
+ goto cleanup;
+ }
/* Section count is simply the size divided by the section size. */
net_device->send_section_cnt = buf_size / net_device->send_section_size;
@@ -740,12 +755,45 @@ static void netvsc_send_completion(struct net_device
*ndev,
int budget)
{
const struct nvsp_message *nvsp_packet = hv_pkt_data(desc);
+ u32 msglen = hv_pkt_datalen(desc);
+
+ /* Ensure packet is big enough to read header fields */
+ if (msglen < sizeof(struct nvsp_message_header)) {
+ netdev_err(ndev, "nvsp_message length too small: %u\n", msglen);
+ return;
+ }
switch (nvsp_packet->hdr.msg_type) {
case NVSP_MSG_TYPE_INIT_COMPLETE:
+ if (msglen < sizeof(struct nvsp_message_init_complete)) {
+ netdev_err(ndev, "nvsp_msg length too small: %u\n",
+ msglen);
+ return;
+ }
+ fallthrough;
+
case NVSP_MSG1_TYPE_SEND_RECV_BUF_COMPLETE:
+ if (msglen < sizeof(struct
nvsp_1_message_send_receive_buffer_complete)) {
+ netdev_err(ndev, "nvsp_msg1 length too small: %u\n",
+ msglen);
+ return;
+ }
+ fallthrough;
+
case NVSP_MSG1_TYPE_SEND_SEND_BUF_COMPLETE:
+ if (msglen < sizeof(struct
nvsp_1_message_send_send_buffer_complete)) {
+ netdev_err(ndev, "nvsp_msg1 length too small: %u\n",
+ msglen);
+ return;
+ }
+ fallthrough;
+
case NVSP_MSG5_TYPE_SUBCHANNEL:
+ if (msglen < sizeof(struct nvsp_5_subchannel_complete)) {
+ netdev_err(ndev,
Re: [PATCH 04/12] dma-mapping: fix DMA_OPS dependencies
On 2020-09-08 17:47, Christoph Hellwig wrote: Driver that select DMA_OPS need to depend on HAS_DMA support to work. The vop driver was missing that dependency, so add it, and also add a nother depends in DMA_OPS itself. That won't fix the issue due to how the Kconfig dependencies work, but at least produce a warning about unmet dependencies. Signed-off-by: Christoph Hellwig --- drivers/misc/mic/Kconfig | 1 + kernel/dma/Kconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/misc/mic/Kconfig b/drivers/misc/mic/Kconfig index b9bb086785db48..8a7c2c5711d5f4 100644 --- a/drivers/misc/mic/Kconfig +++ b/drivers/misc/mic/Kconfig @@ -35,6 +35,7 @@ config SCIF_BUS config VOP_BUS tristate "VOP Bus Driver" + depends on HAS_DMA select DMA_OPS AFAICS all three of these bus drivers are only proxying a struct dma_map_ops * pointer around, so if they used the set_dma_ops() helper they shouldn't even need these selects at all. Only INTEL_MIC_HOST appears to have a logical dependency on DMA_OPS for actual functionality. However, I have a vague feeling you might not be fond of those dma_ops helpers, and I have no great objection to this one-liner as-is, so (modulo the couple of commit message typos), Reviewed-by: Robin Murphy (of course the hunk below is unquestionably OK) Robin. help This option is selected by any driver which registers a diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig index 0ddfb5510fe45f..e7b801649f6574 100644 --- a/kernel/dma/Kconfig +++ b/kernel/dma/Kconfig @@ -9,6 +9,7 @@ config HAS_DMA default y config DMA_OPS + depends on HAS_DMA bool #
Re: [RESEND PATCH v1] PCI: pcie_bus_config can be set at build time
Hi Bjorn, On Wed, Sep 9, 2020 at 10:25 PM Bjorn Helgaas wrote: > > On Tue, Sep 08, 2020 at 12:32:48PM -0400, Jim Quinlan wrote: > > The Kconfig is modified so that the pcie_bus_config setting can be done at > > build time in the same manner as the CONFIG_PCIEASPM_ choice. The > > pci_bus_config setting may still be overridden by the bootline param. > > I guess... I really hate these build-time config settings for both > ASPM and MPS/MRRS. But Linux just isn't smart or flexible enough to > do the right thing at run-time, so I guess we're kind of stuck. > > I guess you have systems where you need a different default? Yes, we've been shipping our kernel with the DEFAULT and since we do not have FW it is not configured optimally. Some customers have noticed and I tell them to put 'pci=pcie_bus_safe' on their bootline but I'd rather have this setting work for all customers as it yields the option we want. > > It'd be nice if we could put a little more detail in the Kconfig to > help users choose the correct one. "Ensure MPS matches upstream > bridge" is *accurate*, but it doesn't really tell me why I would > choose this rather than a different one. IIRC I just copied the comments that were in the bootline settings. I'm concerned about there being the same comment in two places; sooner or later someone will update one place and not the other. > > Maybe we could mention the corresponding command-line parameters, > e.g., "This is the same as booting with 'pci=pcie_bus_tune_off'"? Will do and resubmit. Thanks, Jim Quinlan Broadcom STB > > > Signed-off-by: Jim Quinlan > > --- > > drivers/pci/Kconfig | 40 > > drivers/pci/pci.c | 12 > > 2 files changed, 52 insertions(+) > > > > diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig > > index 4bef5c2bae9f..efe69b0d9f7f 100644 > > --- a/drivers/pci/Kconfig > > +++ b/drivers/pci/Kconfig > > @@ -187,6 +187,46 @@ config PCI_HYPERV > > The PCI device frontend driver allows the kernel to import arbitrary > > PCI devices from a PCI backend to support PCI driver domains. > > > > +choice > > + prompt "PCIE default bus config setting" > > + default PCIE_BUS_DEFAULT > > + depends on PCI > > + help > > + One of the following choices will set the pci_bus_config at > > + compile time. This will still be overridden by the appropriate > > + pci bootline parameter. > > + > > +config PCIE_BUS_TUNE_OFF > > + bool "Tune Off" > > + depends on PCI > > + help > > + Use the BIOS defaults; doesn't touch MPS at all. > > + > > +config PCIE_BUS_DEFAULT > > + bool "Default" > > + depends on PCI > > + help > > + Ensure MPS matches upstream bridge. > > + > > +config PCIE_BUS_SAFE > > + bool "Safe" > > + depends on PCI > > + help > > + Use largest MPS boot-time devices support. > > + > > +config PCIE_BUS_PERFORMANCE > > + bool "Performance" > > + depends on PCI > > + help > > + Use MPS and MRRS for best performance. > > + > > +config PCIE_BUS_PEER2PEER > > + bool "Peer2peer" > > + depends on PCI > > + help > > + Set MPS = 128 for all devices. > > +endchoice > > + > > source "drivers/pci/hotplug/Kconfig" > > source "drivers/pci/controller/Kconfig" > > source "drivers/pci/endpoint/Kconfig" > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > > index e39c5499770f..dfb52ed4a931 100644 > > --- a/drivers/pci/pci.c > > +++ b/drivers/pci/pci.c > > @@ -101,7 +101,19 @@ unsigned long pci_hotplug_mmio_pref_size = > > DEFAULT_HOTPLUG_MMIO_PREF_SIZE; > > #define DEFAULT_HOTPLUG_BUS_SIZE 1 > > unsigned long pci_hotplug_bus_size = DEFAULT_HOTPLUG_BUS_SIZE; > > > > + > > +/* PCIE bus config, can be overridden by bootline param */ > > +#ifdef CONFIG_PCIE_BUS_TUNE_OFF > > +enum pcie_bus_config_types pcie_bus_config = PCIE_BUS_TUNE_OFF; > > +#elif defined CONFIG_PCIE_BUS_SAFE > > +enum pcie_bus_config_types pcie_bus_config = PCIE_BUS_SAFE; > > +#elif defined CONFIG_PCIE_BUS_PERFORMANCE > > +enum pcie_bus_config_types pcie_bus_config = PCIE_BUS_PERFORMANCE; > > +#elif defined CONFIG_PCIE_BUS_PEER2PEER > > +enum pcie_bus_config_types pcie_bus_config = PCIE_BUS_PEER2PEER; > > +#else > > enum pcie_bus_config_types pcie_bus_config = PCIE_BUS_DEFAULT; > > +#endif > > > > /* > > * The default CLS is used if arch didn't set CLS explicitly and not > > -- > > 2.17.1 > > smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH v2] cpuidle-pseries: Fix CEDE latency conversion from tb to us
On Thu, 3 Sep 2020 14:57:27 +0530, Gautham R. Shenoy wrote:
> commit d947fb4c965c ("cpuidle: pseries: Fixup exit latency for
> CEDE(0)") sets the exit latency of CEDE(0) based on the latency values
> of the Extended CEDE states advertised by the platform. The values
> advertised by the platform are in timebase ticks. However the cpuidle
> framework requires the latency values in microseconds.
>
> If the tb-ticks value advertised by the platform correspond to a value
> smaller than 1us, during the conversion from tb-ticks to microseconds,
> in the current code, the result becomes zero. This is incorrect as it
> puts a CEDE state on par with the snooze state.
>
> [...]
Applied to powerpc/fixes.
[1/1] cpuidle: pseries: Fix CEDE latency conversion from tb to us
https://git.kernel.org/powerpc/c/1d3ee7df009a46440c58508b8819213c09503acd
cheers
[PATCH V5 3/4] arm64: dts: qcom: sc7180-trogdor: Add pinctrl and interrupt config for BT UART
Add a suitable sleep configuration for uart3 to support Bluetooth wakeup.
If QUP function is selected in sleep state, UART RTS/RFR is pulled high
during suspend and BT SoC not able to send wakeup bytes. So, configure
GPIO mode in sleep state to keep it low during suspend.
Signed-off-by: satya priya
---
Changes in V5:
- Newly added in V5. This patch adds wakeup support for trogdor board files.
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 48
1 file changed, 48 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index a6b9beb..96b5331 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -792,6 +792,11 @@ ap_spi_fp: {
#include
{
+ pinctrl-names = "default", "sleep";
+ pinctrl-1 = <_uart3_sleep>;
+ interrupts-extended = < GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>,
+ < 41 IRQ_TYPE_EDGE_FALLING>;
+
status = "okay";
bluetooth: bluetooth {
@@ -1345,4 +1350,47 @@ ap_spi_fp: {
drive-strength = <2>;
};
};
+
+ qup_uart3_sleep: qup-uart3-sleep {
+ pinmux {
+ pins = "gpio38", "gpio39",
+ "gpio40", "gpio41";
+ function = "gpio";
+ };
+
+ pinconf-cts {
+ /*
+* Configure a pull-down on CTS to match the pull of
+* the Bluetooth module.
+*/
+ pins = "gpio38";
+ bias-pull-down;
+ };
+
+ pinconf-rts {
+ /*
+* Configure pull-down on RTS to make sure that the BT
SoC can
+* wake up the system by sending wakeup bytes during
suspend.
+*/
+pins = "gpio39";
+bias-pull-down;
+ };
+
+ pinconf-tx {
+ /* Configure pull-up on TX when it isn't actively
driven */
+ pins = "gpio40";
+ bias-pull-up;
+ };
+
+ pinconf-rx {
+ /*
+* Configure a pull-up on RX. This is needed to avoid
+* garbage data when the TX pin of the Bluetooth module
is
+* in tri-state (module powered off or not driving the
+* signal yet).
+*/
+ pins = "gpio41";
+ bias-pull-up;
+ };
+ };
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v2 1/2] ASoC: dt-bindings: ti,j721e-cpb-audio: Document support for j7200-cpb
j721e or j7200 SOM can be attached to the same Common Processor Board (CPB)
With the j7200 SOM only the 48KHz family parent clock is available and
McASP0 is used for the audio.
Signed-off-by: Peter Ujfalusi
---
.../bindings/sound/ti,j721e-cpb-audio.yaml| 92 ++-
1 file changed, 70 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml
b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml
index d52cfbeb2d07..805da4d6a88e 100644
--- a/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml
+++ b/Documentation/devicetree/bindings/sound/ti,j721e-cpb-audio.yaml
@@ -18,18 +18,25 @@ description: |
PLL15 (for 44.1KHz). The same PLLs are used for McASP10's AUXCLK clock via
different HSDIVIDER.
- Clocking setup for 48KHz family:
- PLL4 ---> PLL4_HSDIV0 ---> MCASP10_AUXCLK ---> McASP10.auxclk
-|-> PLL4_HSDIV2 ---> AUDIO_REFCLK2 ---> pcm3168a.SCKI
+ Clocking setup for j721e:
+48KHz family:
+PLL4 ---> PLL4_HSDIV0 ---> MCASP10_AUXCLK ---> McASP10.auxclk
+ |-> PLL4_HSDIV2 ---> AUDIO_REFCLK2 ---> pcm3168a.SCKI
- Clocking setup for 44.1KHz family:
- PLL15 ---> PLL15_HSDIV0 ---> MCASP10_AUXCLK ---> McASP10.auxclk
- |-> PLL15_HSDIV2 ---> AUDIO_REFCLK2 ---> pcm3168a.SCKI
+44.1KHz family:
+PLL15 ---> PLL15_HSDIV0 ---> MCASP10_AUXCLK ---> McASP10.auxclk
+ |-> PLL15_HSDIV2 ---> AUDIO_REFCLK2 ---> pcm3168a.SCKI
+
+ Clocking setup for j7200:
+48KHz family:
+PLL4 ---> PLL4_HSDIV0 ---> MCASP0_AUXCLK ---> McASP0.auxclk
+ |-> PLL4_HSDIV2 ---> AUDIO_REFCLK2 ---> pcm3168a.SCKI
properties:
compatible:
-items:
- - const: ti,j721e-cpb-audio
+enum:
+ - ti,j721e-cpb-audio
+ - ti,j7200-cpb-audio
model:
$ref: /schemas/types.yaml#/definitions/string
@@ -44,22 +51,12 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle
clocks:
-items:
- - description: AUXCLK clock for McASP used by CPB audio
- - description: Parent for CPB_McASP auxclk (for 48KHz)
- - description: Parent for CPB_McASP auxclk (for 44.1KHz)
- - description: SCKI clock for the pcm3168a codec on CPB
- - description: Parent for CPB_SCKI clock (for 48KHz)
- - description: Parent for CPB_SCKI clock (for 44.1KHz)
+minItems: 4
+maxItems: 6
clock-names:
-items:
- - const: cpb-mcasp-auxclk
- - const: cpb-mcasp-auxclk-48000
- - const: cpb-mcasp-auxclk-44100
- - const: cpb-codec-scki
- - const: cpb-codec-scki-48000
- - const: cpb-codec-scki-44100
+minItems: 4
+maxItems: 6
required:
- compatible
@@ -71,6 +68,57 @@ required:
additionalProperties: false
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: ti,j721e-cpb-audio
+
+then:
+ properties:
+clocks:
+ minItems: 6
+ items:
+- description: AUXCLK clock for McASP used by CPB audio
+- description: Parent for CPB_McASP auxclk (for 48KHz)
+- description: Parent for CPB_McASP auxclk (for 44.1KHz)
+- description: SCKI clock for the pcm3168a codec on CPB
+- description: Parent for CPB_SCKI clock (for 48KHz)
+- description: Parent for CPB_SCKI clock (for 44.1KHz)
+
+clock-names:
+ items:
+- const: cpb-mcasp-auxclk
+- const: cpb-mcasp-auxclk-48000
+- const: cpb-mcasp-auxclk-44100
+- const: cpb-codec-scki
+- const: cpb-codec-scki-48000
+- const: cpb-codec-scki-44100
+
+ - if:
+ properties:
+compatible:
+ contains:
+const: ti,j7200-cpb-audio
+
+then:
+ properties:
+clocks:
+ maxItems: 4
+ items:
+- description: AUXCLK clock for McASP used by CPB audio
+- description: Parent for CPB_McASP auxclk (for 48KHz)
+- description: SCKI clock for the pcm3168a codec on CPB
+- description: Parent for CPB_SCKI clock (for 48KHz)
+
+clock-names:
+ items:
+- const: cpb-mcasp-auxclk
+- const: cpb-mcasp-auxclk-48000
+- const: cpb-codec-scki
+- const: cpb-codec-scki-48000
+
examples:
- |+
sound {
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
BUG: unable to handle kernel paging request in free_swap_cache
Hello, syzbot found the following issue on: HEAD commit:dd9fb9bb Merge tags 'auxdisplay-for-linus-v5.9-rc4', 'clan.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=164e35cd90 kernel config: https://syzkaller.appspot.com/x/.config?x=bd46548257448703 dashboard link: https://syzkaller.appspot.com/bug?extid=b41193cb6e40673119c1 compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+b41193cb6e4067311...@syzkaller.appspotmail.com BUG: unable to handle page fault for address: ea00777f #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD 12fff8067 P4D 12fff8067 PUD 0 Oops: [#1] PREEMPT SMP KASAN CPU: 1 PID: 10690 Comm: syz-executor.2 Not tainted 5.9.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:compound_head include/linux/page-flags.h:182 [inline] RIP: 0010:PageSwapCache include/linux/page-flags.h:391 [inline] RIP: 0010:free_swap_cache+0x32/0x300 mm/swap_state.c:325 Code: 49 89 fc 55 4d 8d 6c 24 08 53 e8 49 10 c7 ff 4c 89 ea 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 85 02 00 00 <4d> 8b 74 24 08 31 ff 4c 89 e5 4c 89 f3 83 e3 01 48 89 de e8 b6 0c RSP: 0018:c900088a76d0 EFLAGS: 00010246 RAX: dc00 RBX: 888000143848 RCX: 81ad73c2 RDX: 1d400eef RSI: 81ad3ab7 RDI: ea00 RBP: 0107 R08: R09: ea00018ec9c7 R10: 01fe R11: R12: ea00 R13: ea00777f R14: dc00 R15: c900088a7a80 FS: () GS:8880ae70() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ea00777f CR3: 000214b08000 CR4: 001526e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: free_pages_and_swap_cache+0x58/0x90 mm/swap_state.c:353 tlb_batch_pages_flush mm/mmu_gather.c:49 [inline] tlb_flush_mmu_free mm/mmu_gather.c:242 [inline] tlb_flush_mmu+0xe9/0x6b0 mm/mmu_gather.c:249 zap_pte_range mm/memory.c:1159 [inline] zap_pmd_range mm/memory.c:1197 [inline] zap_pud_range mm/memory.c:1226 [inline] zap_p4d_range mm/memory.c:1247 [inline] unmap_page_range+0x1e22/0x2b20 mm/memory.c:1268 unmap_single_vma+0x198/0x300 mm/memory.c:1313 unmap_vmas+0x168/0x2e0 mm/memory.c:1345 exit_mmap+0x2b1/0x530 mm/mmap.c:3183 __mmput+0x122/0x470 kernel/fork.c:1076 mmput+0x53/0x60 kernel/fork.c:1097 exit_mm kernel/exit.c:483 [inline] do_exit+0xa8b/0x29f0 kernel/exit.c:793 do_group_exit+0x125/0x310 kernel/exit.c:903 get_signal+0x428/0x1f00 kernel/signal.c:2757 arch_do_signal+0x82/0x2520 arch/x86/kernel/signal.c:811 exit_to_user_mode_loop kernel/entry/common.c:136 [inline] exit_to_user_mode_prepare+0x1ae/0x200 kernel/entry/common.c:167 syscall_exit_to_user_mode+0x7e/0x2e0 kernel/entry/common.c:242 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45d5b9 Code: Bad RIP value. RSP: 002b:7f77c0d90cf8 EFLAGS: 0246 ORIG_RAX: 00ca RAX: 0001 RBX: 0118cf48 RCX: 0045d5b9 RDX: 000f4240 RSI: 0081 RDI: 0118cf4c RBP: 0118cf40 R08: 000e R09: R10: 0003 R11: 0246 R12: 0118cf4c R13: 0169fb6f R14: 7f77c0d919c0 R15: 0118cf4c Modules linked in: CR2: ea00777f ---[ end trace 07566fd2f7a76eaf ]--- RIP: 0010:compound_head include/linux/page-flags.h:182 [inline] RIP: 0010:PageSwapCache include/linux/page-flags.h:391 [inline] RIP: 0010:free_swap_cache+0x32/0x300 mm/swap_state.c:325 Code: 49 89 fc 55 4d 8d 6c 24 08 53 e8 49 10 c7 ff 4c 89 ea 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 85 02 00 00 <4d> 8b 74 24 08 31 ff 4c 89 e5 4c 89 f3 83 e3 01 48 89 de e8 b6 0c RSP: 0018:c900088a76d0 EFLAGS: 00010246 RAX: dc00 RBX: 888000143848 RCX: 81ad73c2 RDX: 1d400eef RSI: 81ad3ab7 RDI: ea00 RBP: 0107 R08: R09: ea00018ec9c7 R10: 01fe R11: R12: ea00 R13: ea00777f R14: dc00 R15: c900088a7a80 FS: () GS:8880ae70() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: ea00777f CR3: 000214b08000 CR4: 001526e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track
RE: [PATCH RESEND v3 04/11] usb: xhci-rcar: convert to readl_poll_timeout_atomic()
Hi Chunfeng,
Thank you for the patch!
> From: Chunfeng Yun, Sent: Thursday, September 10, 2020 5:22 PM
>
> Use readl_poll_timeout_atomic() to simplify code
>
> Cc: Mathias Nyman
> Cc: Yoshihiro Shimoda
> Signed-off-by: Chunfeng Yun
> ---
> v2~v3: no changes
> ---
> drivers/usb/host/xhci-rcar.c | 43 ---
> 1 file changed, 12 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-rcar.c b/drivers/usb/host/xhci-rcar.c
> index c1025d3..74f836f 100644
> --- a/drivers/usb/host/xhci-rcar.c
> +++ b/drivers/usb/host/xhci-rcar.c
> @@ -6,6 +6,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -127,8 +128,7 @@ static int xhci_rcar_download_firmware(struct usb_hcd
> *hcd)
> void __iomem *regs = hcd->regs;
> struct xhci_plat_priv *priv = hcd_to_xhci_priv(hcd);
> const struct firmware *fw;
> - int retval, index, j, time;
> - int timeout = 1;
> + int retval, index, j;
> u32 data, val, temp;
> u32 quirks = 0;
> const struct soc_device_attribute *attr;
> @@ -166,32 +166,19 @@ static int xhci_rcar_download_firmware(struct usb_hcd
> *hcd)
> temp |= RCAR_USB3_DL_CTRL_FW_SET_DATA0;
> writel(temp, regs + RCAR_USB3_DL_CTRL);
>
> - for (time = 0; time < timeout; time++) {
> - val = readl(regs + RCAR_USB3_DL_CTRL);
> - if ((val & RCAR_USB3_DL_CTRL_FW_SET_DATA0) == 0)
> - break;
> - udelay(1);
> - }
> - if (time == timeout) {
> - retval = -ETIMEDOUT;
> + retval = readl_poll_timeout_atomic(regs + RCAR_USB3_DL_CTRL,
> + val, !(val & RCAR_USB3_DL_CTRL_FW_SET_DATA0),
> + 1, 1);
> + if (retval < 0)
> break;
> - }
> }
>
> temp = readl(regs + RCAR_USB3_DL_CTRL);
> temp &= ~RCAR_USB3_DL_CTRL_ENABLE;
> writel(temp, regs + RCAR_USB3_DL_CTRL);
>
> - for (time = 0; time < timeout; time++) {
> - val = readl(regs + RCAR_USB3_DL_CTRL);
> - if (val & RCAR_USB3_DL_CTRL_FW_SUCCESS) {
> - retval = 0;
> - break;
> - }
> - udelay(1);
> - }
> - if (time == timeout)
> - retval = -ETIMEDOUT;
> + retval = readl_poll_timeout_atomic((regs + RCAR_USB3_DL_CTRL),
> + val, (val & RCAR_USB3_DL_CTRL_FW_SUCCESS), 1, 1);
Some parentheses are not needed like below:
retval = readl_poll_timeout_atomic(regs + RCAR_USB3_DL_CTRL,
val, val & RCAR_USB3_DL_CTRL_FW_SUCCESS, 1, 1);
> release_firmware(fw);
>
> @@ -200,18 +187,12 @@ static int xhci_rcar_download_firmware(struct usb_hcd
> *hcd)
>
> static bool xhci_rcar_wait_for_pll_active(struct usb_hcd *hcd)
> {
> - int timeout = 1000;
> + int retval;
> u32 val, mask = RCAR_USB3_AXH_STA_PLL_ACTIVE_MASK;
>
> - while (timeout > 0) {
> - val = readl(hcd->regs + RCAR_USB3_AXH_STA);
> - if ((val & mask) == mask)
> - return true;
> - udelay(1);
> - timeout--;
> - }
> -
> - return false;
> + retval = readl_poll_timeout_atomic(hcd->regs + RCAR_USB3_AXH_STA,
> + val, ((val & mask) == mask), 1, 1000);
Likewise above:
retval = readl_poll_timeout_atomic(hcd->regs + RCAR_USB3_AXH_STA,
val, (val & mask) == mask, 1, 1000);
> + return !!retval;
This breaks the code. If I changed this to "return retval < 0 ? false : true;",
it works again.
Best regards,
Yoshihiro Shimoda
[PATCH V5 4/4] tty: serial: qcom_geni_serial: Fix the UART wakeup issue
As a part of system suspend uart_port_suspend is called from the Serial driver, which calls set_mctrl passing mctrl as 0. This makes RFR high(NOT_READY) during suspend. Due to this BT SoC is not able to send wakeup bytes to UART during suspend. Include if check for non-suspend case to keep RFR low during suspend. Signed-off-by: satya priya Acked-by: Greg Kroah-Hartman Reviewed-by: Akash Asthana --- Changes in V2: - This patch fixes the UART flow control issue during suspend. Newly added in V2. Changes in V3: - As per Matthias's comment removed the extra parentheses. Changes in V4: - No change. Changes in V5: - As per Matthias comment, fixed nit-pick in commit text. drivers/tty/serial/qcom_geni_serial.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c index 3aa29d2..bc63c54 100644 --- a/drivers/tty/serial/qcom_geni_serial.c +++ b/drivers/tty/serial/qcom_geni_serial.c @@ -242,7 +242,7 @@ static void qcom_geni_serial_set_mctrl(struct uart_port *uport, if (mctrl & TIOCM_LOOP) port->loopback = RX_TX_CTS_RTS_SORTED; - if (!(mctrl & TIOCM_RTS)) + if (!(mctrl & TIOCM_RTS) && !uport->suspended) uart_manual_rfr = UART_MANUAL_RFR_EN | UART_RFR_NOT_READY; writel(uart_manual_rfr, uport->membase + SE_UART_MANUAL_RFR); } -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH] PM: s2idle: Introduce syscore callbacks in s2idle flow
On Thursday, September 3, 2020 4:14:07 AM CEST Claude. Yen wrote:
> On Tue, 2020-09-01 at 13:57 +0200, Rafael J. Wysocki wrote:
> > On Tue, Sep 1, 2020 at 9:05 AM Claude Yen wrote:
> > >
> > > This series based on 5.9-rc1
> > > This patch makes s2idle call existing syscore callbacks. Currently,
> > > when s2idle is selected as system suspend method, callbacks hooked
> > > by register_syscore_ops() will not be triggered. This may induce
> > > unexpected results.
> >
> > They are not executed by design.
> >
> > > For example, sched_clock_suspend() was added to s2idle flow in
> > > commit 3f2552f7e9c5 ("timers/sched_clock: Prevent generic sched_clock
> > > wrap caused by tick_freeze()") to fix clock wrap problem. However,
> > > sched_clock_suspend() is originally registered in syscore callback.
> >
> > I'm not sure why this matters here.
>
> If functions in syscore callbacks are needed in s2idle, explicit
> migration is needed like commit 3f2552f7e9c5 ("timers/sched_clock:
> Prevent generic sched_clock wrap caused by tick_freeze()").
> Thus, I am wondering if such effort could be saved.
Yes, it could.
You can define platform ops for s2idle and invoke what's needed from there.
> > > With this patch, if another syscore callback is needed in s2idle,
> > > additional migration effort could be saved.
> >
> > s2idle cannot execute syscore callbacks, because it doesn' take
> > non-boot CPUs offline and it won't do that.
> >
> > Thanks!
>
> Yes, the current design of syscore callback needs non-boot CPUs offline.
> Considering the following case: in s2idle flow, there is a status that
> only one CPU is alive and other CPUs have enter deepest idle state.
> This situation is similar to getting non-boot CPUs offline, though all
> CPUs are online from kernel's perspective.
It is only similar AFAICS.
You don't migrate interrupts during s2idle, for example.
> Reply from Stephen mentioned that if an operation is needed in both
> S2R and s2idle, CPU_PM notifier can be utilized.
> In my opinion, CPU_PM notifier is particularly for CPU entering idle
> state. In contrast, syscore callback is for system going low power
> state. There exists semantic difference between these two callbacks.
Fair enough.
> Could the current design of syscore callback be re-designed as
> system-wide suspend callback?
No, it couldn't.
> Proposed suspend flow in this patch:
>
> Freeze tasks
> |
> V
> Device suspend callbacks
> |
> |-s2idle--
> ||
> V|
> Disable nonboot CPUsIs this CPU last core to enter idle?
> ||
> V|-
> syscore callbacks||
> | No Yes
> V||
> platform suspend VV
> enter idle syscore callback
> |
> V
> enter idle
>
The primary problem with this is that on some architectures (x86 at least)
the syscore things cannot be run during the s2idle flow.
Also there is a way to invoke them through the platform ops as I said.
Thanks!
[PATCH] scripts/setlocalversion: make git describe output more reliable
When building for an embedded target using Yocto, we're sometimes
observing that the version string that gets built into vmlinux (and
thus what uname -a reports) differs from the path under /lib/modules/
where modules get installed in the rootfs, but only in the length of
the -gabc123def suffix. Hence modprobe always fails.
The problem is that Yocto has the concept of "sstate" (shared state),
which allows different developers/buildbots/etc. to share build
artifacts, based on a hash of all the metadata that went into building
that artifact - and that metadata includes all dependencies (e.g. the
compiler used etc.). That normally works quite well; usually a clean
build (without using any sstate cache) done by one developer ends up
being binary identical to a build done on another host. However, one
thing that can cause two developers to end up with different builds
[and thus make one's vmlinux package incompatible with the other's
kernel-dev package], which is not captured by the metadata hashing, is
this `git describe`: The output of that can be affected by
(1) git version: before 2.11 git defaulted to a minimum of 7, since
2.11 (git.git commit e6c587) the default is dynamic based on the
number of objects in the repo
(2) hence even if both run the same git version, the output can differ
based on how many remotes are being tracked (or just lots of local
development branches or plain old garbage)
(3) and of course somebody could have a core.abbrev config setting in
~/.gitconfig
So in order to avoid `uname -a` output relying on such random details
of the build environment which are rather hard to ensure are
consistent between developers and buildbots, use an explicit
--abbrev=15 option (and for consistency, also use rev-parse --short=15
for the unlikely case of no signed tags being usable).
Now, why is 60 bits enough for everyone? It's not mathematically
guaranteed that git won't have to use 16 in some git repo, but it is
beyond unlikely: Even in a repo with 100M objects, the probability
that any given commit (i.e. the one being described) clashes with some
other object in the first 15 hex chars is less than 1e-10, and
currently a git repo tracking Linus', -stable and -rt only has around
10M objects.
Signed-off-by: Rasmus Villemoes
---
I could probably fix things by adding a 'git config --local
core.abbrev 15' step to the Yocto build process after the repo to
build from has been cloned but before building has started. But in the
interest of binary reproducibility outside of just Yocto builds, I
think it's better if this lives in the kernel.
scripts/setlocalversion | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/setlocalversion b/scripts/setlocalversion
index 20f2efd57b11..c5262f0d953d 100755
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -45,7 +45,7 @@ scm_version()
# Check for git and a git repo.
if test -z "$(git rev-parse --show-cdup 2>/dev/null)" &&
- head=$(git rev-parse --verify --short HEAD 2>/dev/null); then
+ head=$(git rev-parse --verify --short=15 HEAD 2>/dev/null); then
# If we are at a tagged commit (like "v2.6.30-rc6"), we ignore
# it, because this version is defined in the top level Makefile.
@@ -59,7 +59,7 @@ scm_version()
fi
# If we are past a tagged commit (like
# "v2.6.30-rc5-302-g72357d5"), we pretty print it.
- if atag="$(git describe 2>/dev/null)"; then
+ if atag="$(git describe --abbrev=15 2>/dev/null)"; then
echo "$atag" | awk -F- '{printf("-%05d-%s",
$(NF-1),$(NF))}'
# If we don't have a tag at all we print -g{commitish}.
--
2.23.0
[PATCH net-next 3/3] net: stmmac: use netif_tx_start|stop_all_queues() function
From: Ong Boon Leong
The current implementation of stmmac_stop_all_queues() and
stmmac_start_all_queues() will not work correctly when the value of
tx_queues_to_use is changed through ethtool -L DEVNAME rx N tx M command.
Also, netif_tx_start|stop_all_queues() are only needed in driver open()
and close() only.
Fixes: c22a3f48 net: stmmac: adding multiple napi mechanism
Signed-off-by: Ong Boon Leong
Signed-off-by: Voon Weifeng
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 33 +--
1 file changed, 1 insertion(+), 32 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index fea3b77892ab..90c1c37b64e0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -176,32 +176,6 @@ static void stmmac_enable_all_queues(struct stmmac_priv
*priv)
}
}
-/**
- * stmmac_stop_all_queues - Stop all queues
- * @priv: driver private structure
- */
-static void stmmac_stop_all_queues(struct stmmac_priv *priv)
-{
- u32 tx_queues_cnt = priv->plat->tx_queues_to_use;
- u32 queue;
-
- for (queue = 0; queue < tx_queues_cnt; queue++)
- netif_tx_stop_queue(netdev_get_tx_queue(priv->dev, queue));
-}
-
-/**
- * stmmac_start_all_queues - Start all queues
- * @priv: driver private structure
- */
-static void stmmac_start_all_queues(struct stmmac_priv *priv)
-{
- u32 tx_queues_cnt = priv->plat->tx_queues_to_use;
- u32 queue;
-
- for (queue = 0; queue < tx_queues_cnt; queue++)
- netif_tx_start_queue(netdev_get_tx_queue(priv->dev, queue));
-}
-
static void stmmac_service_event_schedule(struct stmmac_priv *priv)
{
if (!test_bit(STMMAC_DOWN, >state) &&
@@ -2865,7 +2839,7 @@ static int stmmac_open(struct net_device *dev)
}
stmmac_enable_all_queues(priv);
- stmmac_start_all_queues(priv);
+ netif_tx_start_all_queues(priv->dev);
return 0;
@@ -2908,8 +2882,6 @@ static int stmmac_release(struct net_device *dev)
phylink_stop(priv->phylink);
phylink_disconnect_phy(priv->phylink);
- stmmac_stop_all_queues(priv);
-
stmmac_disable_all_queues(priv);
for (chan = 0; chan < priv->plat->tx_queues_to_use; chan++)
@@ -5117,7 +5089,6 @@ int stmmac_suspend(struct device *dev)
mutex_lock(>lock);
netif_device_detach(ndev);
- stmmac_stop_all_queues(priv);
stmmac_disable_all_queues(priv);
@@ -5244,8 +5215,6 @@ int stmmac_resume(struct device *dev)
stmmac_enable_all_queues(priv);
- stmmac_start_all_queues(priv);
-
mutex_unlock(>lock);
if (!device_may_wakeup(priv->device) || !priv->plat->pmt) {
--
2.17.0
[PATCH v2 02/11] rtc: rx8010: consolidate local variables of the same type
From: Bartosz Golaszewski
Move local variables of the same type into a single line for better
readability.
Signed-off-by: Bartosz Golaszewski
---
drivers/rtc/rtc-rx8010.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/rtc/rtc-rx8010.c b/drivers/rtc/rtc-rx8010.c
index 2faf5357a3a5..4c790d33f589 100644
--- a/drivers/rtc/rtc-rx8010.c
+++ b/drivers/rtc/rtc-rx8010.c
@@ -109,8 +109,7 @@ static int rx8010_get_time(struct device *dev, struct
rtc_time *dt)
{
struct rx8010_data *rx8010 = dev_get_drvdata(dev);
u8 date[7];
- int flagreg;
- int err;
+ int flagreg, err;
flagreg = i2c_smbus_read_byte_data(rx8010->client, RX8010_FLAG);
if (flagreg < 0)
@@ -141,8 +140,7 @@ static int rx8010_set_time(struct device *dev, struct
rtc_time *dt)
{
struct rx8010_data *rx8010 = dev_get_drvdata(dev);
u8 date[7];
- int ctrl, flagreg;
- int ret;
+ int ctrl, flagreg, ret;
if ((dt->tm_year < 100) || (dt->tm_year > 199))
return -EINVAL;
@@ -250,8 +248,7 @@ static int rx8010_read_alarm(struct device *dev, struct
rtc_wkalrm *t)
struct rx8010_data *rx8010 = dev_get_drvdata(dev);
struct i2c_client *client = rx8010->client;
u8 alarmvals[3];
- int flagreg;
- int err;
+ int flagreg, err;
err = i2c_smbus_read_i2c_block_data(client, RX8010_ALMIN, 3, alarmvals);
if (err != 3)
@@ -279,8 +276,7 @@ static int rx8010_set_alarm(struct device *dev, struct
rtc_wkalrm *t)
struct i2c_client *client = to_i2c_client(dev);
struct rx8010_data *rx8010 = dev_get_drvdata(dev);
u8 alarmvals[3];
- int extreg, flagreg;
- int err;
+ int extreg, flagreg, err;
flagreg = i2c_smbus_read_byte_data(client, RX8010_FLAG);
if (flagreg < 0)
@@ -346,9 +342,8 @@ static int rx8010_alarm_irq_enable(struct device *dev,
{
struct i2c_client *client = to_i2c_client(dev);
struct rx8010_data *rx8010 = dev_get_drvdata(dev);
- int flagreg;
+ int flagreg, err;
u8 ctrl;
- int err;
ctrl = rx8010->ctrlreg;
@@ -387,8 +382,7 @@ static int rx8010_alarm_irq_enable(struct device *dev,
static int rx8010_ioctl(struct device *dev, unsigned int cmd, unsigned long
arg)
{
struct rx8010_data *rx8010 = dev_get_drvdata(dev);
- int tmp;
- int flagreg;
+ int tmp, flagreg;
switch (cmd) {
case RTC_VL_READ:
--
2.26.1
[PATCH v2 05/11] rtc: rx8010: don't use magic values for time buffer length
From: Bartosz Golaszewski
The time buffer len is used directly in this driver. For readability
it's better to define it as the difference between the date register
offsets and use sizeof() whenever referencing it.
Signed-off-by: Bartosz Golaszewski
---
drivers/rtc/rtc-rx8010.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc-rx8010.c b/drivers/rtc/rtc-rx8010.c
index 67ff06a76629..b065973b8a14 100644
--- a/drivers/rtc/rtc-rx8010.c
+++ b/drivers/rtc/rtc-rx8010.c
@@ -108,7 +108,7 @@ static irqreturn_t rx8010_irq_1_handler(int irq, void
*dev_id)
static int rx8010_get_time(struct device *dev, struct rtc_time *dt)
{
struct rx8010_data *rx8010 = dev_get_drvdata(dev);
- u8 date[7];
+ u8 date[RX8010_YEAR - RX8010_SEC + 1];
int flagreg, err;
flagreg = i2c_smbus_read_byte_data(rx8010->client, RX8010_FLAG);
@@ -121,8 +121,8 @@ static int rx8010_get_time(struct device *dev, struct
rtc_time *dt)
}
err = i2c_smbus_read_i2c_block_data(rx8010->client, RX8010_SEC,
- 7, date);
- if (err != 7)
+ sizeof(date), date);
+ if (err != sizeof(date))
return err < 0 ? err : -EIO;
dt->tm_sec = bcd2bin(date[RX8010_SEC - RX8010_SEC] & 0x7f);
@@ -139,7 +139,7 @@ static int rx8010_get_time(struct device *dev, struct
rtc_time *dt)
static int rx8010_set_time(struct device *dev, struct rtc_time *dt)
{
struct rx8010_data *rx8010 = dev_get_drvdata(dev);
- u8 date[7];
+ u8 date[RX8010_YEAR - RX8010_SEC + 1];
int ctrl, flagreg, err;
if ((dt->tm_year < 100) || (dt->tm_year > 199))
@@ -164,7 +164,8 @@ static int rx8010_set_time(struct device *dev, struct
rtc_time *dt)
date[RX8010_WDAY - RX8010_SEC] = bin2bcd(1 << dt->tm_wday);
err = i2c_smbus_write_i2c_block_data(rx8010->client,
-RX8010_SEC, 7, date);
+RX8010_SEC, sizeof(date),
+date);
if (err < 0)
return err;
--
2.26.1
[PATCH v2 07/11] rtc: rx8010: use a helper variable for client->dev in probe()
From: Bartosz Golaszewski
Simple 'dev' looks better then repeated >dev and has the added
benefit of avoiding unnecessary line breaks.
Signed-off-by: Bartosz Golaszewski
---
drivers/rtc/rtc-rx8010.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/rtc/rtc-rx8010.c b/drivers/rtc/rtc-rx8010.c
index 3b8a95330a0a..e401d8ed0e19 100644
--- a/drivers/rtc/rtc-rx8010.c
+++ b/drivers/rtc/rtc-rx8010.c
@@ -409,6 +409,7 @@ static int rx8010_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct i2c_adapter *adapter = client->adapter;
+ struct device *dev = >dev;
struct rx8010_data *rx8010;
int err = 0;
@@ -418,8 +419,7 @@ static int rx8010_probe(struct i2c_client *client,
return -EIO;
}
- rx8010 = devm_kzalloc(>dev, sizeof(struct rx8010_data),
- GFP_KERNEL);
+ rx8010 = devm_kzalloc(dev, sizeof(struct rx8010_data), GFP_KERNEL);
if (!rx8010)
return -ENOMEM;
@@ -431,14 +431,14 @@ static int rx8010_probe(struct i2c_client *client,
return err;
if (client->irq > 0) {
- dev_info(>dev, "IRQ %d supplied\n", client->irq);
- err = devm_request_threaded_irq(>dev, client->irq, NULL,
+ dev_info(dev, "IRQ %d supplied\n", client->irq);
+ err = devm_request_threaded_irq(dev, client->irq, NULL,
rx8010_irq_1_handler,
IRQF_TRIGGER_LOW | IRQF_ONESHOT,
"rx8010", client);
if (err) {
- dev_err(>dev, "unable to request IRQ\n");
+ dev_err(dev, "unable to request IRQ\n");
client->irq = 0;
} else {
rx8010_rtc_ops.read_alarm = rx8010_read_alarm;
@@ -447,11 +447,11 @@ static int rx8010_probe(struct i2c_client *client,
}
}
- rx8010->rtc = devm_rtc_device_register(>dev, client->name,
+ rx8010->rtc = devm_rtc_device_register(dev, client->name,
_rtc_ops, THIS_MODULE);
if (IS_ERR(rx8010->rtc)) {
- dev_err(>dev, "unable to register the class device\n");
+ dev_err(dev, "unable to register the class device\n");
return PTR_ERR(rx8010->rtc);
}
--
2.26.1
[PATCH v2 04/11] rtc: rx8010: rename ret to err in rx8010_set_time()
From: Bartosz Golaszewski
All other functions in this driver use 'err' for integer return values.
Do the same in rx8010_set_time() for consistency.
Signed-off-by: Bartosz Golaszewski
---
drivers/rtc/rtc-rx8010.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/rtc/rtc-rx8010.c b/drivers/rtc/rtc-rx8010.c
index 2038700a3e8e..67ff06a76629 100644
--- a/drivers/rtc/rtc-rx8010.c
+++ b/drivers/rtc/rtc-rx8010.c
@@ -140,7 +140,7 @@ static int rx8010_set_time(struct device *dev, struct
rtc_time *dt)
{
struct rx8010_data *rx8010 = dev_get_drvdata(dev);
u8 date[7];
- int ctrl, flagreg, ret;
+ int ctrl, flagreg, err;
if ((dt->tm_year < 100) || (dt->tm_year > 199))
return -EINVAL;
@@ -150,10 +150,10 @@ static int rx8010_set_time(struct device *dev, struct
rtc_time *dt)
if (ctrl < 0)
return ctrl;
rx8010->ctrlreg = ctrl | RX8010_CTRL_STOP;
- ret = i2c_smbus_write_byte_data(rx8010->client, RX8010_CTRL,
+ err = i2c_smbus_write_byte_data(rx8010->client, RX8010_CTRL,
rx8010->ctrlreg);
- if (ret < 0)
- return ret;
+ if (err < 0)
+ return err;
date[RX8010_SEC - RX8010_SEC] = bin2bcd(dt->tm_sec);
date[RX8010_MIN - RX8010_SEC] = bin2bcd(dt->tm_min);
@@ -163,27 +163,27 @@ static int rx8010_set_time(struct device *dev, struct
rtc_time *dt)
date[RX8010_YEAR - RX8010_SEC] = bin2bcd(dt->tm_year - 100);
date[RX8010_WDAY - RX8010_SEC] = bin2bcd(1 << dt->tm_wday);
- ret = i2c_smbus_write_i2c_block_data(rx8010->client,
+ err = i2c_smbus_write_i2c_block_data(rx8010->client,
RX8010_SEC, 7, date);
- if (ret < 0)
- return ret;
+ if (err < 0)
+ return err;
/* clear STOP bit after changing clock/calendar */
ctrl = i2c_smbus_read_byte_data(rx8010->client, RX8010_CTRL);
if (ctrl < 0)
return ctrl;
rx8010->ctrlreg = ctrl & ~RX8010_CTRL_STOP;
- ret = i2c_smbus_write_byte_data(rx8010->client, RX8010_CTRL,
+ err = i2c_smbus_write_byte_data(rx8010->client, RX8010_CTRL,
rx8010->ctrlreg);
- if (ret < 0)
- return ret;
+ if (err < 0)
+ return err;
flagreg = i2c_smbus_read_byte_data(rx8010->client, RX8010_FLAG);
if (flagreg < 0)
return flagreg;
if (flagreg & RX8010_FLAG_VLF)
- ret = i2c_smbus_write_byte_data(rx8010->client, RX8010_FLAG,
+ err = i2c_smbus_write_byte_data(rx8010->client, RX8010_FLAG,
flagreg & ~RX8010_FLAG_VLF);
return 0;
--
2.26.1
[PATCH v2 03/11] rtc: rx8010: use tabs instead of spaces for code formatting
From: Bartosz Golaszewski
The define values in this driver are close to their names and they are
separated by spaces. Use tabs instead and align all defines.
Signed-off-by: Bartosz Golaszewski
---
drivers/rtc/rtc-rx8010.c | 58
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/rtc/rtc-rx8010.c b/drivers/rtc/rtc-rx8010.c
index 4c790d33f589..2038700a3e8e 100644
--- a/drivers/rtc/rtc-rx8010.c
+++ b/drivers/rtc/rtc-rx8010.c
@@ -13,40 +13,40 @@
#include
#include
-#define RX8010_SEC 0x10
-#define RX8010_MIN 0x11
-#define RX8010_HOUR0x12
-#define RX8010_WDAY0x13
-#define RX8010_MDAY0x14
-#define RX8010_MONTH 0x15
-#define RX8010_YEAR0x16
-#define RX8010_RESV17 0x17
-#define RX8010_ALMIN 0x18
-#define RX8010_ALHOUR 0x19
-#define RX8010_ALWDAY 0x1A
-#define RX8010_TCOUNT0 0x1B
-#define RX8010_TCOUNT1 0x1C
-#define RX8010_EXT 0x1D
-#define RX8010_FLAG0x1E
-#define RX8010_CTRL0x1F
+#define RX8010_SEC 0x10
+#define RX8010_MIN 0x11
+#define RX8010_HOUR0x12
+#define RX8010_WDAY0x13
+#define RX8010_MDAY0x14
+#define RX8010_MONTH 0x15
+#define RX8010_YEAR0x16
+#define RX8010_RESV17 0x17
+#define RX8010_ALMIN 0x18
+#define RX8010_ALHOUR 0x19
+#define RX8010_ALWDAY 0x1A
+#define RX8010_TCOUNT0 0x1B
+#define RX8010_TCOUNT1 0x1C
+#define RX8010_EXT 0x1D
+#define RX8010_FLAG0x1E
+#define RX8010_CTRL0x1F
/* 0x20 to 0x2F are user registers */
-#define RX8010_RESV30 0x30
-#define RX8010_RESV31 0x31
-#define RX8010_IRQ 0x32
+#define RX8010_RESV30 0x30
+#define RX8010_RESV31 0x31
+#define RX8010_IRQ 0x32
-#define RX8010_EXT_WADA BIT(3)
+#define RX8010_EXT_WADABIT(3)
-#define RX8010_FLAG_VLF BIT(1)
-#define RX8010_FLAG_AF BIT(3)
-#define RX8010_FLAG_TF BIT(4)
-#define RX8010_FLAG_UF BIT(5)
+#define RX8010_FLAG_VLFBIT(1)
+#define RX8010_FLAG_AF BIT(3)
+#define RX8010_FLAG_TF BIT(4)
+#define RX8010_FLAG_UF BIT(5)
-#define RX8010_CTRL_AIE BIT(3)
-#define RX8010_CTRL_UIE BIT(5)
-#define RX8010_CTRL_STOP BIT(6)
-#define RX8010_CTRL_TEST BIT(7)
+#define RX8010_CTRL_AIEBIT(3)
+#define RX8010_CTRL_UIEBIT(5)
+#define RX8010_CTRL_STOP BIT(6)
+#define RX8010_CTRL_TEST BIT(7)
-#define RX8010_ALARM_AE BIT(7)
+#define RX8010_ALARM_AEBIT(7)
static const struct i2c_device_id rx8010_id[] = {
{ "rx8010", 0 },
--
2.26.1
[PATCH v2 01/11] rtc: rx8010: remove unnecessary brackets
From: Bartosz Golaszewski
Remove brackets wherever they guard a single line.
Signed-off-by: Bartosz Golaszewski
---
drivers/rtc/rtc-rx8010.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/rtc/rtc-rx8010.c b/drivers/rtc/rtc-rx8010.c
index fe010151ec8f..2faf5357a3a5 100644
--- a/drivers/rtc/rtc-rx8010.c
+++ b/drivers/rtc/rtc-rx8010.c
@@ -181,9 +181,8 @@ static int rx8010_set_time(struct device *dev, struct
rtc_time *dt)
return ret;
flagreg = i2c_smbus_read_byte_data(rx8010->client, RX8010_FLAG);
- if (flagreg < 0) {
+ if (flagreg < 0)
return flagreg;
- }
if (flagreg & RX8010_FLAG_VLF)
ret = i2c_smbus_write_byte_data(rx8010->client, RX8010_FLAG,
@@ -284,17 +283,15 @@ static int rx8010_set_alarm(struct device *dev, struct
rtc_wkalrm *t)
int err;
flagreg = i2c_smbus_read_byte_data(client, RX8010_FLAG);
- if (flagreg < 0) {
+ if (flagreg < 0)
return flagreg;
- }
if (rx8010->ctrlreg & (RX8010_CTRL_AIE | RX8010_CTRL_UIE)) {
rx8010->ctrlreg &= ~(RX8010_CTRL_AIE | RX8010_CTRL_UIE);
err = i2c_smbus_write_byte_data(rx8010->client, RX8010_CTRL,
rx8010->ctrlreg);
- if (err < 0) {
+ if (err < 0)
return err;
- }
}
flagreg &= ~RX8010_FLAG_AF;
--
2.26.1
[PATCH v2 09/11] rtc: rx8010: switch to using the preferred RTC API
From: Bartosz Golaszewski
Use devm_rtc_allocate_device() + rtc_register_device() instead of the
deprecated devm_rtc_device_register().
Signed-off-by: Bartosz Golaszewski
---
drivers/rtc/rtc-rx8010.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/rtc/rtc-rx8010.c b/drivers/rtc/rtc-rx8010.c
index 0665878e8843..bb6578aad972 100644
--- a/drivers/rtc/rtc-rx8010.c
+++ b/drivers/rtc/rtc-rx8010.c
@@ -447,16 +447,21 @@ static int rx8010_probe(struct i2c_client *client,
}
}
- rx8010->rtc = devm_rtc_device_register(dev, client->name,
- _rtc_ops, THIS_MODULE);
-
+ rx8010->rtc = devm_rtc_allocate_device(dev);
if (IS_ERR(rx8010->rtc)) {
- dev_err(dev, "unable to register the class device\n");
+ dev_err(dev, "unable to allocate rtc device\n");
return PTR_ERR(rx8010->rtc);
}
+ rx8010->rtc->ops = _rtc_ops;
rx8010->rtc->max_user_freq = 1;
+ err = rtc_register_device(rx8010->rtc);
+ if (err) {
+ dev_err(dev, "unable to register the class device\n");
+ return err;
+ }
+
return 0;
}
--
2.26.1
Re: Packet gets stuck in NOLOCK pfifo_fast qdisc
On Thu, 2020-09-10 at 14:07 -0700, John Fastabend wrote:
> Cong Wang wrote:
> > On Thu, Sep 3, 2020 at 10:08 PM John Fastabend
> > wrote:
> > > Maybe this would unlock us,
> > >
> > > diff --git a/net/core/dev.c b/net/core/dev.c
> > > index 7df6c9617321..9b09429103f1 100644
> > > --- a/net/core/dev.c
> > > +++ b/net/core/dev.c
> > > @@ -3749,7 +3749,7 @@ static inline int __dev_xmit_skb(struct sk_buff
> > > *skb, struct Qdisc *q,
> > >
> > > if (q->flags & TCQ_F_NOLOCK) {
> > > rc = q->enqueue(skb, q, _free) & NET_XMIT_MASK;
> > > - qdisc_run(q);
> > > + __qdisc_run(q);
> > >
> > > if (unlikely(to_free))
> > > kfree_skb_list(to_free);
> > >
> > >
> > > Per other thread we also need the state deactivated check added
> > > back.
> >
> > I guess no, because pfifo_dequeue() seems to require q->seqlock,
> > according to comments in qdisc_run(), so we can not just get rid of
> > qdisc_run_begin()/qdisc_run_end() here.
> >
> > Thanks.
>
> Seems we would have to revert this as well then,
>
> commit 021a17ed796b62383f7623f4fea73787abddad77
> Author: Paolo Abeni
> Date: Tue May 15 16:24:37 2018 +0200
>
> pfifo_fast: drop unneeded additional lock on dequeue
>
> After the previous patch, for NOLOCK qdiscs, q->seqlock is
> always held when the dequeue() is invoked, we can drop
> any additional locking to protect such operation.
>
> Then I think it should be safe. Back when I was working on the ptr
> ring implementation I opted not to do a case without the spinlock
> because the performance benefit was minimal in the benchmarks I
> was looking at.
The main point behind all that changes was try to close the gap vs the
locked implementation in the uncontended scenario. In our benchmark,
after commit eb82a994479245a79647d302f9b4eb8e7c9d7ca6, was more near to
10%.
Anyway I agree reverting back to the bitlock should be safe.
Cheers,
Paolo
[PATCH v2 08/11] rtc: rx8010: prefer sizeof(*val) over sizeof(struct type_of_val)
From: Bartosz Golaszewski Using the size of the variable is preferred over using the size of its type when allocating memory. Convert the call to devm_kzalloc() in probe(). Signed-off-by: Bartosz Golaszewski --- drivers/rtc/rtc-rx8010.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/rtc-rx8010.c b/drivers/rtc/rtc-rx8010.c index e401d8ed0e19..0665878e8843 100644 --- a/drivers/rtc/rtc-rx8010.c +++ b/drivers/rtc/rtc-rx8010.c @@ -419,7 +419,7 @@ static int rx8010_probe(struct i2c_client *client, return -EIO; } - rx8010 = devm_kzalloc(dev, sizeof(struct rx8010_data), GFP_KERNEL); + rx8010 = devm_kzalloc(dev, sizeof(*rx8010), GFP_KERNEL); if (!rx8010) return -ENOMEM; -- 2.26.1
[PATCH v2 06/11] rtc: rx8010: drop unnecessary initialization
From: Bartosz Golaszewski
The 'err' local variable in rx8010_init_client() doesn't need to be
initialized.
Signed-off-by: Bartosz Golaszewski
---
drivers/rtc/rtc-rx8010.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-rx8010.c b/drivers/rtc/rtc-rx8010.c
index b065973b8a14..3b8a95330a0a 100644
--- a/drivers/rtc/rtc-rx8010.c
+++ b/drivers/rtc/rtc-rx8010.c
@@ -194,7 +194,7 @@ static int rx8010_init_client(struct i2c_client *client)
{
struct rx8010_data *rx8010 = i2c_get_clientdata(client);
u8 ctrl[2];
- int need_clear = 0, err = 0;
+ int need_clear = 0, err;
/* Initialize reserved registers as specified in datasheet */
err = i2c_smbus_write_byte_data(client, RX8010_RESV17, 0xD8);
--
2.26.1
[PATCH v2 10/11] rtc: rx8010: convert to using regmap
From: Bartosz Golaszewski
This driver requires SMBUS to work. We can relax this requirement if we
switch to using i2c regmap and let the regmap sub-system figure out how
to talk to the bus.
This also has the advantage of shrinking the code for register updates.
Signed-off-by: Bartosz Golaszewski
---
drivers/rtc/rtc-rx8010.c | 198 ---
1 file changed, 79 insertions(+), 119 deletions(-)
diff --git a/drivers/rtc/rtc-rx8010.c b/drivers/rtc/rtc-rx8010.c
index bb6578aad972..636e0de02d9b 100644
--- a/drivers/rtc/rtc-rx8010.c
+++ b/drivers/rtc/rtc-rx8010.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#define RX8010_SEC 0x10
@@ -61,7 +62,7 @@ static const struct of_device_id rx8010_of_match[] = {
MODULE_DEVICE_TABLE(of, rx8010_of_match);
struct rx8010_data {
- struct i2c_client *client;
+ struct regmap *regs;
struct rtc_device *rtc;
u8 ctrlreg;
};
@@ -70,13 +71,12 @@ static irqreturn_t rx8010_irq_1_handler(int irq, void
*dev_id)
{
struct i2c_client *client = dev_id;
struct rx8010_data *rx8010 = i2c_get_clientdata(client);
- int flagreg;
+ int flagreg, err;
mutex_lock(>rtc->ops_lock);
- flagreg = i2c_smbus_read_byte_data(client, RX8010_FLAG);
-
- if (flagreg <= 0) {
+ err = regmap_read(rx8010->regs, RX8010_FLAG, );
+ if (err) {
mutex_unlock(>rtc->ops_lock);
return IRQ_NONE;
}
@@ -99,10 +99,9 @@ static irqreturn_t rx8010_irq_1_handler(int irq, void
*dev_id)
rtc_update_irq(rx8010->rtc, 1, RTC_UF | RTC_IRQF);
}
- i2c_smbus_write_byte_data(client, RX8010_FLAG, flagreg);
-
+ err = regmap_write(rx8010->regs, RX8010_FLAG, flagreg);
mutex_unlock(>rtc->ops_lock);
- return IRQ_HANDLED;
+ return err ? IRQ_NONE : IRQ_HANDLED;
}
static int rx8010_get_time(struct device *dev, struct rtc_time *dt)
@@ -111,19 +110,18 @@ static int rx8010_get_time(struct device *dev, struct
rtc_time *dt)
u8 date[RX8010_YEAR - RX8010_SEC + 1];
int flagreg, err;
- flagreg = i2c_smbus_read_byte_data(rx8010->client, RX8010_FLAG);
- if (flagreg < 0)
- return flagreg;
+ err = regmap_read(rx8010->regs, RX8010_FLAG, );
+ if (err)
+ return err;
if (flagreg & RX8010_FLAG_VLF) {
dev_warn(dev, "Frequency stop detected\n");
return -EINVAL;
}
- err = i2c_smbus_read_i2c_block_data(rx8010->client, RX8010_SEC,
- sizeof(date), date);
- if (err != sizeof(date))
- return err < 0 ? err : -EIO;
+ err = regmap_bulk_read(rx8010->regs, RX8010_SEC, date, sizeof(date));
+ if (err)
+ return err;
dt->tm_sec = bcd2bin(date[RX8010_SEC - RX8010_SEC] & 0x7f);
dt->tm_min = bcd2bin(date[RX8010_MIN - RX8010_SEC] & 0x7f);
@@ -140,19 +138,14 @@ static int rx8010_set_time(struct device *dev, struct
rtc_time *dt)
{
struct rx8010_data *rx8010 = dev_get_drvdata(dev);
u8 date[RX8010_YEAR - RX8010_SEC + 1];
- int ctrl, flagreg, err;
+ int err;
if ((dt->tm_year < 100) || (dt->tm_year > 199))
return -EINVAL;
/* set STOP bit before changing clock/calendar */
- ctrl = i2c_smbus_read_byte_data(rx8010->client, RX8010_CTRL);
- if (ctrl < 0)
- return ctrl;
- rx8010->ctrlreg = ctrl | RX8010_CTRL_STOP;
- err = i2c_smbus_write_byte_data(rx8010->client, RX8010_CTRL,
- rx8010->ctrlreg);
- if (err < 0)
+ err = regmap_set_bits(rx8010->regs, RX8010_CTRL, RX8010_CTRL_STOP);
+ if (err)
return err;
date[RX8010_SEC - RX8010_SEC] = bin2bcd(dt->tm_sec);
@@ -163,66 +156,54 @@ static int rx8010_set_time(struct device *dev, struct
rtc_time *dt)
date[RX8010_YEAR - RX8010_SEC] = bin2bcd(dt->tm_year - 100);
date[RX8010_WDAY - RX8010_SEC] = bin2bcd(1 << dt->tm_wday);
- err = i2c_smbus_write_i2c_block_data(rx8010->client,
-RX8010_SEC, sizeof(date),
-date);
- if (err < 0)
+ err = regmap_bulk_write(rx8010->regs, RX8010_SEC, date, sizeof(date));
+ if (err)
return err;
/* clear STOP bit after changing clock/calendar */
- ctrl = i2c_smbus_read_byte_data(rx8010->client, RX8010_CTRL);
- if (ctrl < 0)
- return ctrl;
- rx8010->ctrlreg = ctrl & ~RX8010_CTRL_STOP;
- err = i2c_smbus_write_byte_data(rx8010->client, RX8010_CTRL,
- rx8010->ctrlreg);
- if (err < 0)
+ err = regmap_clear_bits(rx8010->regs, RX8010_CTRL, RX8010_CTRL_STOP);
+ if (err)
return err;
- flagreg =
[PATCH v2 11/11] rtc: rx8010: use range checking provided by core RTC code
From: Bartosz Golaszewski
We don't need to check the time range manually in set_time(), we can
use range_min and range_max exposed by struct rtc_device.
Signed-off-by: Bartosz Golaszewski
---
drivers/rtc/rtc-rx8010.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-rx8010.c b/drivers/rtc/rtc-rx8010.c
index 636e0de02d9b..e78f0808bdff 100644
--- a/drivers/rtc/rtc-rx8010.c
+++ b/drivers/rtc/rtc-rx8010.c
@@ -140,9 +140,6 @@ static int rx8010_set_time(struct device *dev, struct
rtc_time *dt)
u8 date[RX8010_YEAR - RX8010_SEC + 1];
int err;
- if ((dt->tm_year < 100) || (dt->tm_year > 199))
- return -EINVAL;
-
/* set STOP bit before changing clock/calendar */
err = regmap_set_bits(rx8010->regs, RX8010_CTRL, RX8010_CTRL_STOP);
if (err)
@@ -415,6 +412,8 @@ static int rx8010_probe(struct i2c_client *client,
rx8010->rtc->ops = _rtc_ops;
rx8010->rtc->max_user_freq = 1;
+ rx8010->rtc->range_min = RTC_TIMESTAMP_BEGIN_2000;
+ rx8010->rtc->range_max = RTC_TIMESTAMP_END_2099;
err = rtc_register_device(rx8010->rtc);
if (err) {
--
2.26.1
Re: [PATCH 10/12] dma-direct: rename and cleanup __phys_to_dma
On 2020-09-08 17:47, Christoph Hellwig wrote:
The __phys_to_dma vs phys_to_dma distinction isn't exactly obvious. Try
to improve the situation by renaming __phys_to_dma to
phys_to_dma_unencryped, and not forcing architectures that want to
override phys_to_dma to actually provide __phys_to_dma.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/dma-direct.h | 2 +-
arch/mips/bmips/dma.c | 2 +-
arch/mips/cavium-octeon/dma-octeon.c | 2 +-
arch/mips/include/asm/dma-direct.h | 2 +-
arch/mips/loongson2ef/fuloong-2e/dma.c | 2 +-
arch/mips/loongson2ef/lemote-2f/dma.c | 2 +-
arch/mips/loongson64/dma.c | 2 +-
arch/mips/pci/pci-ar2315.c | 2 +-
arch/mips/pci/pci-xtalk-bridge.c | 2 +-
arch/mips/sgi-ip32/ip32-dma.c | 2 +-
arch/powerpc/include/asm/dma-direct.h | 2 +-
drivers/iommu/intel/iommu.c| 2 +-
include/linux/dma-direct.h | 28 +++---
kernel/dma/direct.c| 8
kernel/dma/swiotlb.c | 4 ++--
15 files changed, 34 insertions(+), 30 deletions(-)
diff --git a/arch/arm/include/asm/dma-direct.h
b/arch/arm/include/asm/dma-direct.h
index a8cee87a93e8ab..bca0de56753439 100644
--- a/arch/arm/include/asm/dma-direct.h
+++ b/arch/arm/include/asm/dma-direct.h
@@ -2,7 +2,7 @@
#ifndef ASM_ARM_DMA_DIRECT_H
#define ASM_ARM_DMA_DIRECT_H 1
-static inline dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
+static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
{
unsigned int offset = paddr & ~PAGE_MASK;
return pfn_to_dma(dev, __phys_to_pfn(paddr)) + offset;
diff --git a/arch/mips/bmips/dma.c b/arch/mips/bmips/dma.c
index ba2a5d33dfd3fa..49061b870680b9 100644
--- a/arch/mips/bmips/dma.c
+++ b/arch/mips/bmips/dma.c
@@ -40,7 +40,7 @@ static struct bmips_dma_range *bmips_dma_ranges;
#define FLUSH_RAC 0x100
-dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t pa)
+dma_addr_t phys_to_dma(struct device *dev, phys_addr_t pa)
{
struct bmips_dma_range *r;
diff --git a/arch/mips/cavium-octeon/dma-octeon.c b/arch/mips/cavium-octeon/dma-octeon.c
index 388b13ba2558c2..232fa1017b1ec9 100644
--- a/arch/mips/cavium-octeon/dma-octeon.c
+++ b/arch/mips/cavium-octeon/dma-octeon.c
@@ -168,7 +168,7 @@ void __init octeon_pci_dma_init(void)
}
#endif /* CONFIG_PCI */
-dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
+dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
{
#ifdef CONFIG_PCI
if (dev && dev_is_pci(dev))
diff --git a/arch/mips/include/asm/dma-direct.h
b/arch/mips/include/asm/dma-direct.h
index 8e178651c638c2..9a640118316c9d 100644
--- a/arch/mips/include/asm/dma-direct.h
+++ b/arch/mips/include/asm/dma-direct.h
@@ -2,7 +2,7 @@
#ifndef _MIPS_DMA_DIRECT_H
#define _MIPS_DMA_DIRECT_H 1
-dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr);
+dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr);
phys_addr_t dma_to_phys(struct device *dev, dma_addr_t daddr);
#endif /* _MIPS_DMA_DIRECT_H */
diff --git a/arch/mips/loongson2ef/fuloong-2e/dma.c
b/arch/mips/loongson2ef/fuloong-2e/dma.c
index 83fadeb3fd7d56..cea167d8aba8db 100644
--- a/arch/mips/loongson2ef/fuloong-2e/dma.c
+++ b/arch/mips/loongson2ef/fuloong-2e/dma.c
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
#include
-dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
+dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
{
return paddr | 0x8000;
}
diff --git a/arch/mips/loongson2ef/lemote-2f/dma.c
b/arch/mips/loongson2ef/lemote-2f/dma.c
index 302b43a14eee74..3c9e994563578c 100644
--- a/arch/mips/loongson2ef/lemote-2f/dma.c
+++ b/arch/mips/loongson2ef/lemote-2f/dma.c
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
#include
-dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
+dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
{
return paddr | 0x8000;
}
diff --git a/arch/mips/loongson64/dma.c b/arch/mips/loongson64/dma.c
index b3dc5d0bd2b113..364f2f27c8723f 100644
--- a/arch/mips/loongson64/dma.c
+++ b/arch/mips/loongson64/dma.c
@@ -4,7 +4,7 @@
#include
#include
-dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
+dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
{
/* We extract 2bit node id (bit 44~47, only bit 44~45 used now) from
* Loongson-3's 48bit address space and embed it into 40bit */
diff --git a/arch/mips/pci/pci-ar2315.c b/arch/mips/pci/pci-ar2315.c
index d88395684f487d..cef4a47ab06311 100644
--- a/arch/mips/pci/pci-ar2315.c
+++ b/arch/mips/pci/pci-ar2315.c
@@ -170,7 +170,7 @@ static inline dma_addr_t ar2315_dev_offset(struct device
*dev)
return 0;
}
-dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
Re: [PATCHSET 0/4] perf stat: Add --multiply-cgroup option
Hi Arnaldo,
On Thu, Sep 10, 2020 at 8:10 PM Arnaldo Carvalho de Melo
wrote:
>
> Em Thu, Sep 10, 2020 at 11:15:42AM +0200, Jiri Olsa escreveu:
> > On Tue, Sep 08, 2020 at 01:42:24PM +0900, Namhyung Kim wrote:
> > > When we profile cgroup events with perf stat, it's very annoying to
> > > specify events and cgroups on the command line as it requires the
> > > mapping between events and cgroups. (Note that perf record can use
> > > cgroup sampling but it's not usable for perf stat).
>
> > > I guess most cases we just want to use a same set of events (N) for
> > > all cgroups (M), but we need to specify NxM events and NxM cgroups.
> > > This is not good especially when profiling large number of cgroups:
> > > say M=200.
>
> > > So I added --multiply-cgroup option to make it easy for that case. It
> > > will create NxM events from N events and M cgroups. One more upside
> > > is that it can handle metrics too.
>
> > agreed that it's PITA to use -G option ;-)
>
> yeah, its great that someone is looking at cgroups improvements, thanks
> Namyung, its great to have you working on this!
Thanks! :)
>
> More below.
>
> > > For example, the following example measures IPC metric for 3 cgroups
>
> > > $ cat perf-multi-cgrp.sh
> > > #!/bin/sh
>
> > > METRIC=${1:-IPC}
> > > CGROUP_DIR=/sys/fs/cgroup/perf_event
>
> > > sudo mkdir $CGROUP_DIR/A $CGROUP_DIR/B $CGROUP_DIR/C
>
> > > # add backgroupd workload for each cgroup
> > > echo $$ | sudo tee $CGROUP_DIR/A/cgroup.procs > /dev/null
> > > yes > /dev/null &
> > > echo $$ | sudo tee $CGROUP_DIR/B/cgroup.procs > /dev/null
> > > yes > /dev/null &
> > > echo $$ | sudo tee $CGROUP_DIR/C/cgroup.procs > /dev/null
> > > yes > /dev/null &
>
> > > # run 'perf stat' in the root cgroup
> > > echo $$ | sudo tee $CGROUP_DIR/cgroup.procs > /dev/null
> > > perf stat -a -M $METRIC --multiply-cgroup -G A,B,C sleep 1
> >
> > would it be easier to have new option for this? like:
> >
> > perf stat -a -M $METRIC --for-cgroup A,B,C
> > perf stat -a -M $METRIC --for-each-cgroup A,B,C
> > perf stat -a -M $METRIC --attach-cgroup A,B,C
> > perf stat -a -M $METRIC --attach-to-cgroup A,B,C
Looks good. I like the --for-each-cgroup.
Then we should make it and -G mutually exclusive IMHO.
> >
> > I'm still not sure how the --multiply-cgroup deals with empty
> > cgroup A,,C but looks like we don't need this behaviour now?
Yep, it can handle such case and bind the events to the root cgroup.
>
> Yeah, I also didn't like the --multiply-cgroup thing, perhaps we can use
> a per-event term? or per group, for example:
>
> perf stat -a -M $METRIC/cgroups=A,B,C/
> perf stat -a -e '{cycles,instructions,cache-misses}/cgroups=A,B,C/'
>
> Allowing wildcards or regexps would help with some use cases.
>
> We already have several terms that allows us to control per event knobs,
> this would be one more.
At some point, we can support this kind of flexibility, but it'd make the code
complex when multiple events or metrics have different cgroup membership.
So I'd like to do the simple case (all events are expanded to same cgroups)
first..
Thanks
Namhyung
Re: [RESEND PATCH v1] PCI: pcie_bus_config can be set at build time
On Thu, Sep 10, 2020 at 08:57:10AM -0400, Jim Quinlan wrote: > Hi Bjorn, > > On Wed, Sep 9, 2020 at 10:25 PM Bjorn Helgaas wrote: > > > > On Tue, Sep 08, 2020 at 12:32:48PM -0400, Jim Quinlan wrote: > > > The Kconfig is modified so that the pcie_bus_config setting can be done at > > > build time in the same manner as the CONFIG_PCIEASPM_ choice. The > > > pci_bus_config setting may still be overridden by the bootline param. > > > > I guess... I really hate these build-time config settings for both > > ASPM and MPS/MRRS. But Linux just isn't smart or flexible enough to > > do the right thing at run-time, so I guess we're kind of stuck. > > > > I guess you have systems where you need a different default? > > Yes, we've been shipping our kernel with the DEFAULT and since we do > not have FW it is not configured optimally. Some customers have > noticed and I tell them to put 'pci=pcie_bus_safe' on their bootline > but I'd rather have this setting work for all customers as it yields > the option we want. I'm guessing you probably don't have any hotplug slots. Seems like we ought to be able to recognize that and pick pcie_bus_safe automatically. Someday. Maybe that's part of the description: if you have a closed system with no possibility of adding new devices, we can use the largest MPS that's supported by all devices, i.e., pcie_bus_safe. > > It'd be nice if we could put a little more detail in the Kconfig to > > help users choose the correct one. "Ensure MPS matches upstream > > bridge" is *accurate*, but it doesn't really tell me why I would > > choose this rather than a different one. > > IIRC I just copied the comments that were in the bootline settings. > I'm concerned about there being the same comment in two places; sooner > or later someone will update one place and not the other. True. It'd be nice if we at least had *one* place with a useful description. I don't think we have any today. Bjorn
Re: [PATCH] hwmon: (pmbus) Expose PEC debugfs attribute
On 9/10/20 3:51 AM, Andrew Jeffery wrote:
>
>
> On Thu, 10 Sep 2020, at 20:04, Guenter Roeck wrote:
>> On 9/10/20 3:05 AM, Dan Carpenter wrote:
>>> Hi Andrew,
>>>
>>> url:
>>> https://github.com/0day-ci/linux/commits/Andrew-Jeffery/hwmon-pmbus-Expose-PEC-debugfs-attribute/20200910-010642
>>> base:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git
>>> hwmon-next
>>> config: x86_64-randconfig-m001-20200909 (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
>>>
>>> smatch warnings:
>>> drivers/hwmon/pmbus/pmbus_core.c:2415 pmbus_debugfs_ops_pec_open() warn:
>>> '0x' prefix is confusing together with '%1llu' specifier
>>>
>>> #
>>> https://github.com/0day-ci/linux/commit/705b8b5588d4102256d0954086ed16c9bdf9804f
>>> git remote add linux-review https://github.com/0day-ci/linux
>>> git fetch --no-tags linux-review
>>> Andrew-Jeffery/hwmon-pmbus-Expose-PEC-debugfs-attribute/20200910-010642
>>> git checkout 705b8b5588d4102256d0954086ed16c9bdf9804f
>>> vim +2415 drivers/hwmon/pmbus/pmbus_core.c
>>>
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2391 static int
>>> pmbus_debugfs_set_pec(void *data, u64 val)
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2392 {
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2393 int rc;
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2394 struct i2c_client
>>> *client = data;
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2395
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2396 if (!val) {
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2397 client->flags
>>> &= ~I2C_CLIENT_PEC;
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2398 return 0;
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2399 }
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2400
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2401 if (val != 1)
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2402 return -EINVAL;
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2403
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2404 rc =
>>> i2c_smbus_read_byte_data(client, PMBUS_CAPABILITY);
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2405 if (rc < 0)
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2406 return rc;
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2407
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2408 if (!(rc &
>>> PB_CAPABILITY_ERROR_CHECK))
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2409 return
>>> -ENOTSUPP;
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2410
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2411 client->flags |=
>>> I2C_CLIENT_PEC;
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2412
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2413 return 0;
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2414 }
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 @2415
>>> DEFINE_DEBUGFS_ATTRIBUTE(pmbus_debugfs_ops_pec, pmbus_debugfs_get_pec,
>>> 705b8b5588d410 Andrew Jeffery 2020-09-09 2416
>>> pmbus_debugfs_set_pec, "0x%1llu\n");
>>>
>>> ^^^
>>> Was the 1 intentional? Anyway, you probably want to remove the 0x so
>>> it doesn't look like hex.
>>>
>>
>> Nice catch; I didn't notice the 1. It is still there in v2, but it does
>> seem quite useless.
>
> Do you want to just rebase it out, or would you like me to send
> a patch removing the stray 1 from v2?
>
I'll rebase it.
Thanks,
Guenter
Re: [PATCH 1/3] fpga: dfl: move dfl_device_id to mod_devicetable.h
On 9/10/20 1:41 AM, Xu Yilun wrote:
> On Wed, Sep 09, 2020 at 05:55:33AM -0700, Tom Rix wrote:
>> On 9/7/20 10:48 PM, Xu Yilun wrote:
>>> In order to support MODULE_DEVICE_TABLE() for dfl device driver, this
>>> patch moves struct dfl_device_id to mod_devicetable.h
>>>
>>> Signed-off-by: Xu Yilun
>>> Signed-off-by: Wu Hao
>>> Signed-off-by: Matthew Gerlach
>>> Signed-off-by: Russ Weight
>>> ---
>>> drivers/fpga/dfl.h | 13 +
>>> include/linux/mod_devicetable.h | 12
>>> 2 files changed, 13 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/fpga/dfl.h b/drivers/fpga/dfl.h
>>> index 5dc758f..d5b0760 100644
>>> --- a/drivers/fpga/dfl.h
>>> +++ b/drivers/fpga/dfl.h
>>> @@ -26,6 +26,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> /* maximum supported number of ports */
>>> #define MAX_DFL_FPGA_PORT_NUM 4
>>> @@ -526,18 +527,6 @@ enum dfl_id_type {
>>> };
>>>
>>> /**
>>> - * struct dfl_device_id - dfl device identifier
>>> - * @type: contains 4 bits DFL FIU type of the device. See enum dfl_id_type.
>>> - * @feature_id: contains 12 bits feature identifier local to its DFL FIU
>>> type.
>>> - * @driver_data: driver specific data.
>>> - */
>>> -struct dfl_device_id {
>>> - u8 type;
>>> - u16 feature_id;
>>> - unsigned long driver_data;
>>> -};
>>> -
>>> -/**
>>> * struct dfl_device - represent an dfl device on dfl bus
>>> *
>>> * @dev: generic device interface.
>>> diff --git a/include/linux/mod_devicetable.h
>>> b/include/linux/mod_devicetable.h
>>> index 5b08a47..407d8dc 100644
>>> --- a/include/linux/mod_devicetable.h
>>> +++ b/include/linux/mod_devicetable.h
>>> @@ -838,4 +838,16 @@ struct mhi_device_id {
>>> kernel_ulong_t driver_data;
>>> };
>>>
>>> +/**
>>> + * struct dfl_device_id - dfl device identifier
>>> + * @type: contains 4 bits DFL FIU type of the device. See enum dfl_id_type.
>>> + * @feature_id: contains 12 bits feature identifier local to its DFL FIU
>>> type.
>>> + * @driver_data: driver specific data.
>>> + */
>>> +struct dfl_device_id {
>>> + __u8 type;
>>> + __u16 feature_id;
>> I thought i saw feature id's going to 64 bit, does this type need to expand ?
> Feature id is a 12bit field in DFL spec. Previously we define it u64
> cause we are considering it may expand sometime. But now seems GUID will
> be used in future design.
>
> And the header file will be used by modpost, which is not supporting u64
> now. So it is not necessary we use u64 for extra work. A patch is
> already applied for this change - "change data type of feature id to u16"
>
> Thanks,
> Yilun
Thanks for the explanation.
Reviewed-by: Tom Rix
>
>> TomÂÂ
>>
>>> + kernel_ulong_t driver_data;
>>> +};
>>> +
>>> #endif /* LINUX_MOD_DEVICETABLE_H */
Re: [PATCH] i2c: stm32: do not display error when DMA is not requested
On Thu, 10 Sep 2020 at 14:27, Alain Volmat wrote: > > On Thu, Sep 10, 2020 at 12:06:07PM +0200, Wolfram Sang wrote: > > On Thu, Sep 10, 2020 at 11:32:29AM +0200, Alain Volmat wrote: > > > DMA usage is optional for the I2C driver. check for the -ENODEV > > > error in order to avoid displaying an error when no DMA > > > has been requested. > > > > > > Signed-off-by: Alain Volmat > > > --- > > > This patch should be applied on top of the patch [i2c: stm32: Simplify > > > with dev_err_probe()] > > > > We can do it in this order, it just makes backporting to stable kernels > > (if that is desired) a bit harder than a self-contained patch. I am fine > > with both approaches, but just wanted to point it out. > > Indeed, that's a good point. I'll rework it then, to avoid the dependency > on dev_err_probe change. If that is ok, I propose to push a two patches serie > with both this fix (updated) followed by a rebased version of the > dev_err_probe patch from Krzysztof for dev_err_probe change. I can rebase mine on top of yours. Indeed such cleanups as mine should be rather later in the queue. Best regards, Krzysztof
Re: [PATCH 11/12] dma-mapping: move dma_common_{mmap,get_sgtable} out of mapping.c
On 2020-09-08 17:47, Christoph Hellwig wrote:
Add a new file that contains helpera for misc DMA ops, which is only
The Latin plural of the singular "helperum", I guess? :P
built when CONFIG_DMA_OPS is set.
Reviewed-by: Robin Murphy
Signed-off-by: Christoph Hellwig
---
kernel/dma/Makefile | 1 +
kernel/dma/mapping.c | 47 +---
kernel/dma/ops_helpers.c | 51
3 files changed, 53 insertions(+), 46 deletions(-)
create mode 100644 kernel/dma/ops_helpers.c
diff --git a/kernel/dma/Makefile b/kernel/dma/Makefile
index 32c7c1942bbd6c..dc755ab68aabf9 100644
--- a/kernel/dma/Makefile
+++ b/kernel/dma/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_HAS_DMA) += mapping.o direct.o
+obj-$(CONFIG_DMA_OPS) += ops_helpers.o
obj-$(CONFIG_DMA_OPS) += dummy.o
obj-$(CONFIG_DMA_CMA) += contiguous.o
obj-$(CONFIG_DMA_DECLARE_COHERENT)+= coherent.o
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 0d129421e75fc8..848c95c27d79ff 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -8,7 +8,7 @@
#include /* for max_pfn */
#include
#include
-#include
+#include
#include
#include
#include
@@ -295,22 +295,6 @@ void dma_sync_sg_for_device(struct device *dev, struct
scatterlist *sg,
}
EXPORT_SYMBOL(dma_sync_sg_for_device);
-/*
- * Create scatter-list for the already allocated DMA buffer.
- */
-int dma_common_get_sgtable(struct device *dev, struct sg_table *sgt,
-void *cpu_addr, dma_addr_t dma_addr, size_t size,
-unsigned long attrs)
-{
- struct page *page = virt_to_page(cpu_addr);
- int ret;
-
- ret = sg_alloc_table(sgt, 1, GFP_KERNEL);
- if (!ret)
- sg_set_page(sgt->sgl, page, PAGE_ALIGN(size), 0);
- return ret;
-}
-
/*
* The whole dma_get_sgtable() idea is fundamentally unsafe - it seems
* that the intention is to allow exporting memory allocated via the
@@ -358,35 +342,6 @@ pgprot_t dma_pgprot(struct device *dev, pgprot_t prot,
unsigned long attrs)
}
#endif /* CONFIG_MMU */
-/*
- * Create userspace mapping for the DMA-coherent memory.
- */
-int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
- void *cpu_addr, dma_addr_t dma_addr, size_t size,
- unsigned long attrs)
-{
-#ifdef CONFIG_MMU
- unsigned long user_count = vma_pages(vma);
- unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
- unsigned long off = vma->vm_pgoff;
- int ret = -ENXIO;
-
- vma->vm_page_prot = dma_pgprot(dev, vma->vm_page_prot, attrs);
-
- if (dma_mmap_from_dev_coherent(dev, vma, cpu_addr, size, ))
- return ret;
-
- if (off >= count || user_count > count - off)
- return -ENXIO;
-
- return remap_pfn_range(vma, vma->vm_start,
- page_to_pfn(virt_to_page(cpu_addr)) + vma->vm_pgoff,
- user_count << PAGE_SHIFT, vma->vm_page_prot);
-#else
- return -ENXIO;
-#endif /* CONFIG_MMU */
-}
-
/**
* dma_can_mmap - check if a given device supports dma_mmap_*
* @dev: device to check
diff --git a/kernel/dma/ops_helpers.c b/kernel/dma/ops_helpers.c
new file mode 100644
index 00..e443c69be4299f
--- /dev/null
+++ b/kernel/dma/ops_helpers.c
@@ -0,0 +1,51 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Helpers for DMA ops implementations. These generally rely on the fact that
+ * the allocated memory contains normal pages in the direct kernel mapping.
+ */
+#include
+
+/*
+ * Create scatter-list for the already allocated DMA buffer.
+ */
+int dma_common_get_sgtable(struct device *dev, struct sg_table *sgt,
+void *cpu_addr, dma_addr_t dma_addr, size_t size,
+unsigned long attrs)
+{
+ struct page *page = virt_to_page(cpu_addr);
+ int ret;
+
+ ret = sg_alloc_table(sgt, 1, GFP_KERNEL);
+ if (!ret)
+ sg_set_page(sgt->sgl, page, PAGE_ALIGN(size), 0);
+ return ret;
+}
+
+/*
+ * Create userspace mapping for the DMA-coherent memory.
+ */
+int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size,
+ unsigned long attrs)
+{
+#ifdef CONFIG_MMU
+ unsigned long user_count = vma_pages(vma);
+ unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
+ unsigned long off = vma->vm_pgoff;
+ int ret = -ENXIO;
+
+ vma->vm_page_prot = dma_pgprot(dev, vma->vm_page_prot, attrs);
+
+ if (dma_mmap_from_dev_coherent(dev, vma, cpu_addr, size, ))
+ return ret;
+
+ if (off >= count || user_count > count - off)
+ return -ENXIO;
+
+ return remap_pfn_range(vma, vma->vm_start,
+ page_to_pfn(virt_to_page(cpu_addr)) + vma->vm_pgoff,
+
Re: [PATCH v2 0/2] MTE support for KVM guest
On Thu, Sep 10, 2020 at 02:27:48PM +0100, Dr. David Alan Gilbert wrote: > * Andrew Jones (drjo...@redhat.com) wrote: > > On Wed, Sep 09, 2020 at 06:45:33PM -0700, Richard Henderson wrote: > > > On 9/9/20 8:25 AM, Andrew Jones wrote: > > > >> * Provide a KVM-specific method to extract the tags from guest memory. > > > >>This might also have benefits in terms of providing an easy way to > > > >>read bulk tag data from guest memory (since the LDGM instruction > > > >>isn't available at EL0). > > > > > > > > Maybe we need a new version of KVM_GET_DIRTY_LOG that also provides > > > > the tags for all addresses of each dirty page. > > > > > > KVM_GET_DIRTY_LOG just provides one bit per dirty page, no? Then VMM > > > copies > > > the data out from its local address to guest memory. > > > > > > There'd be no difference with or without tags, afaik. It's just about > > > how VMM > > > copies the data, with or without tags. > > > > Right, as long as it's fast enough to do > > > > for_each_dirty_page(page, dirty_log) > > for (i = 0; i < host-page-size/16; i += 16) > > append_tag(LDG(page + i)) > > > > to get all the tags for each dirty page. I understood it would be faster > > to use LDGM, but we'd need a new ioctl for that. So I was proposing we > > just piggyback on a new dirty-log ioctl instead. > > That feels a bad idea to me; there's a couple of different ways dirty > page checking work; lets keep extracting the tags separate. > It's sounding like it was a premature optimization anyway. We don't yet know if an ioctl for LDGM is worth it. Looping over LDG may work fine. Thanks, drew
Re: [PATCH][next] binder: remove redundant assignment to pointer n
On Thu, Sep 10, 2020 at 8:12 AM Colin King wrote:
>
> From: Colin Ian King
>
> The pointer n is being initialized with a value that is
> never read and it is being updated later with a new value. The
> initialization is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
Acked-by: Todd Kjos
> ---
> drivers/android/binder_alloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c
> index 910c53ba2c91..2f846b7ae8b8 100644
> --- a/drivers/android/binder_alloc.c
> +++ b/drivers/android/binder_alloc.c
> @@ -347,7 +347,7 @@ static void debug_low_async_space_locked(struct
> binder_alloc *alloc, int pid)
> * and at some point we'll catch them in the act. This is more
> efficient
> * than keeping a map per pid.
> */
> - struct rb_node *n = alloc->free_buffers.rb_node;
> + struct rb_node *n;
> struct binder_buffer *buffer;
> size_t total_alloc_size = 0;
> size_t num_buffers = 0;
> --
> 2.27.0
>
[PATCH net-next] net: cxgb3: Fix some kernel-doc warnings
Fixes the following W=1 kernel build warning(s): drivers/net/ethernet/chelsio/cxgb3/t3_hw.c:2209: warning: Excess function parameter 'adapter' description in 'clear_sge_ctxt' drivers/net/ethernet/chelsio/cxgb3/t3_hw.c:2975: warning: Excess function parameter 'adapter' description in 't3_set_proto_sram' Reported-by: Hulk Robot Signed-off-by: Wang Hai --- drivers/net/ethernet/chelsio/cxgb3/t3_hw.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/chelsio/cxgb3/t3_hw.c b/drivers/net/ethernet/chelsio/cxgb3/t3_hw.c index 0a9f2c596624..311fed38c101 100644 --- a/drivers/net/ethernet/chelsio/cxgb3/t3_hw.c +++ b/drivers/net/ethernet/chelsio/cxgb3/t3_hw.c @@ -2195,7 +2195,7 @@ static int t3_sge_write_context(struct adapter *adapter, unsigned int id, /** * clear_sge_ctxt - completely clear an SGE context - * @adapter: the adapter + * @adap: the adapter * @id: the context id * @type: the context type * @@ -2966,7 +2966,7 @@ static void ulp_config(struct adapter *adap, const struct tp_params *p) /** * t3_set_proto_sram - set the contents of the protocol sram - * @adapter: the adapter + * @adap: the adapter * @data: the protocol image * * Write the contents of the protocol SRAM. -- 2.17.1
Re: [Intel-gfx] [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
On Thu, 10 Sep 2020 at 14:33, Tom Murphy wrote:
>
> On Wed, 9 Sep 2020 at 13:56, Tvrtko Ursulin
> wrote:
> >
> >
> > On 09/09/2020 10:16, Tvrtko Ursulin wrote:
> > > On 08/09/2020 23:43, Tom Murphy wrote:
> > >> On Tue, 8 Sep 2020 at 16:56, Tvrtko Ursulin
> > >> wrote:
> > >>> On 08/09/2020 16:44, Logan Gunthorpe wrote:
> > On 2020-09-08 9:28 a.m., Tvrtko Ursulin wrote:
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h
> > >> b/drivers/gpu/drm/i915/i915
> > >> index b7b59328cb76..9367ac801f0c 100644
> > >> --- a/drivers/gpu/drm/i915/i915_scatterlist.h
> > >> +++ b/drivers/gpu/drm/i915/i915_scatterlist.h
> > >> @@ -27,13 +27,19 @@ static __always_inline struct sgt_iter {
> > >> } __sgt_iter(struct scatterlist *sgl, bool dma) {
> > >>struct sgt_iter s = { .sgp = sgl };
> > >>
> > >> + if (sgl && !sg_dma_len(s.sgp))
> > >
> > > I'd extend the condition to be, just to be safe:
> > > if (dma && sgl && !sg_dma_len(s.sgp))
> > >
> >
> > Right, good catch, that's definitely necessary.
> >
> > >> + s.sgp = NULL;
> > >> +
> > >>if (s.sgp) {
> > >>s.max = s.curr = s.sgp->offset;
> > >> - s.max += s.sgp->length;
> > >> - if (dma)
> > >> +
> > >> + if (dma) {
> > >> + s.max += sg_dma_len(s.sgp);
> > >>s.dma = sg_dma_address(s.sgp);
> > >> - else
> > >> + } else {
> > >> + s.max += s.sgp->length;
> > >>s.pfn = page_to_pfn(sg_page(s.sgp));
> > >> + }
> > >
> > > Otherwise has this been tested or alternatively how to test it?
> > > (How to
> > > repro the issue.)
> >
> > It has not been tested. To test it, you need Tom's patch set without
> > the
> > last "DO NOT MERGE" patch:
> >
> > https://lkml.kernel.org/lkml/20200907070035.ga25...@infradead.org/T/
> > >>>
> > >>> Tom, do you have a branch somewhere I could pull from? (Just being lazy
> > >>> about downloading a bunch of messages from the archives.)
> > >>
> > >> I don't unfortunately. I'm working locally with poor internet.
> > >>
> > >>>
> > >>> What GPU is in your Lenovo x1 carbon 5th generation and what
> > >>> graphical/desktop setup I need to repro?
> > >>
> > >>
> > >> Is this enough info?:
> > >>
> > >> $ lspci -vnn | grep VGA -A 12
> > >> 00:02.0 VGA compatible controller [0300]: Intel Corporation HD
> > >> Graphics 620 [8086:5916] (rev 02) (prog-if 00 [VGA controller])
> > >> Subsystem: Lenovo ThinkPad X1 Carbon 5th Gen [17aa:224f]
> > >> Flags: bus master, fast devsel, latency 0, IRQ 148
> > >> Memory at eb00 (64-bit, non-prefetchable) [size=16M]
> > >> Memory at 6000 (64-bit, prefetchable) [size=256M]
> > >> I/O ports at e000 [size=64]
> > >> [virtual] Expansion ROM at 000c [disabled] [size=128K]
> > >> Capabilities: [40] Vendor Specific Information: Len=0c
> > >> Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
> > >> Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-
> > >> Capabilities: [d0] Power Management version 2
> > >> Capabilities: [100] Process Address Space ID (PASID)
> > >> Capabilities: [200] Address Translation Service (ATS)
> > >
> > > Works for a start. What about the steps to repro? Any desktop
> > > environment and it is just visual corruption, no hangs/stalls or such?
> > >
> > > I've submitted a series consisting of what I understood are the patches
> > > needed to repro the issue to our automated CI here:
> > >
> > > https://patchwork.freedesktop.org/series/81489/
> > >
> > > So will see if it will catch something, or more targeted testing will be
> > > required. Hopefully it does trip over in which case I can add the patch
> > > suggested by Logan on top and see if that fixes it. Or I'll need to
> > > write a new test case.
> > >
> > > If you could glance over my series to check I identified the patches
> > > correctly it would be appreciated.
> >
> > Our CI was more than capable at catching the breakage so I've copied you
> > on a patch (https://patchwork.freedesktop.org/series/81497/) which has a
> > good potential to fix this. (Or improve the robustness of our sg walks,
> > depends how you look at it.)
> >
> > Would you be able to test it in your environment by any chance? If it
> > works I understand it unblocks your IOMMU work, right?
And yes this does unblock the iommu work
>
> I tested your latest patch set ([PATCH 1/2] drm/i915: Fix DMA mapped
> scatterlist walks) and it fixes the issue. great work!
>
> >
> > Regards,
> >
> > Tvrtko
[PATCH 3/6] can: mcp25xxfd: add regmap infrastructure
From: Marc Kleine-Budde
This patch adds the regmap infrastructure for the Microchip MCP25xxFD SPI CAN
controller family. The actual driver is added in the next commit.
Tested-by: Kurt Van Dijck
Tested-by: Manivannan Sadhasivam
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Manivannan Sadhasivam
---
drivers/net/can/spi/Kconfig | 2 +
drivers/net/can/spi/Makefile | 1 +
drivers/net/can/spi/mcp25xxfd/Kconfig | 17 +
drivers/net/can/spi/mcp25xxfd/Makefile| 7 +
.../net/can/spi/mcp25xxfd/mcp25xxfd-crc16.c | 89 ++
.../net/can/spi/mcp25xxfd/mcp25xxfd-regmap.c | 556
drivers/net/can/spi/mcp25xxfd/mcp25xxfd.h | 828 ++
7 files changed, 1500 insertions(+)
create mode 100644 drivers/net/can/spi/mcp25xxfd/Kconfig
create mode 100644 drivers/net/can/spi/mcp25xxfd/Makefile
create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd-crc16.c
create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd-regmap.c
create mode 100644 drivers/net/can/spi/mcp25xxfd/mcp25xxfd.h
diff --git a/drivers/net/can/spi/Kconfig b/drivers/net/can/spi/Kconfig
index f780c79aac6f..00b0a2e305b0 100644
--- a/drivers/net/can/spi/Kconfig
+++ b/drivers/net/can/spi/Kconfig
@@ -15,4 +15,6 @@ config CAN_MCP251X
Driver for the Microchip MCP251x and MCP25625 SPI CAN
controllers.
+source "drivers/net/can/spi/mcp25xxfd/Kconfig"
+
endmenu
diff --git a/drivers/net/can/spi/Makefile b/drivers/net/can/spi/Makefile
index f115b2c46623..20c18ac96b1c 100644
--- a/drivers/net/can/spi/Makefile
+++ b/drivers/net/can/spi/Makefile
@@ -6,3 +6,4 @@
obj-$(CONFIG_CAN_HI311X) += hi311x.o
obj-$(CONFIG_CAN_MCP251X) += mcp251x.o
+obj-y += mcp25xxfd/
diff --git a/drivers/net/can/spi/mcp25xxfd/Kconfig
b/drivers/net/can/spi/mcp25xxfd/Kconfig
new file mode 100644
index ..9eb596019a58
--- /dev/null
+++ b/drivers/net/can/spi/mcp25xxfd/Kconfig
@@ -0,0 +1,17 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+config CAN_MCP25XXFD
+ tristate "Microchip MCP25xxFD SPI CAN controllers"
+ select REGMAP
+ help
+ Driver for the Microchip MCP25XXFD SPI FD-CAN controller
+ family.
+
+config CAN_MCP25XXFD_SANITY
+ depends on CAN_MCP25XXFD
+ bool "Additional Sanity Checks"
+ help
+ This option enables additional sanity checks in the driver,
+ that compares various internal counters with the in chip
+ variants. This comes with a runtime overhead.
+ Disable if unsure.
diff --git a/drivers/net/can/spi/mcp25xxfd/Makefile
b/drivers/net/can/spi/mcp25xxfd/Makefile
new file mode 100644
index ..9dadf0070b42
--- /dev/null
+++ b/drivers/net/can/spi/mcp25xxfd/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-$(CONFIG_CAN_MCP25XXFD) += mcp25xxfd.o
+
+mcp25xxfd-objs :=
+mcp25xxfd-objs += mcp25xxfd-crc16.o
+mcp25xxfd-objs += mcp25xxfd-regmap.o
diff --git a/drivers/net/can/spi/mcp25xxfd/mcp25xxfd-crc16.c
b/drivers/net/can/spi/mcp25xxfd/mcp25xxfd-crc16.c
new file mode 100644
index ..79d09aaebf33
--- /dev/null
+++ b/drivers/net/can/spi/mcp25xxfd/mcp25xxfd-crc16.c
@@ -0,0 +1,89 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// mcp25xxfd - Microchip MCP25xxFD Family CAN controller driver
+//
+// Copyright (c) 2020 Pengutronix,
+//Marc Kleine-Budde
+//
+// Based on:
+//
+// CAN bus driver for Microchip 25XXFD CAN Controller with SPI Interface
+//
+// Copyright (c) 2019 Martin Sperl
+//
+
+#include "mcp25xxfd.h"
+
+/* The standard crc16 in linux/crc16.h is unfortunately not computing
+ * the correct results (left shift vs. right shift). So here an
+ * implementation with a table generated with the help of:
+ *
+ * http://lkml.iu.edu/hypermail/linux/kernel/0508.1/1085.html
+ */
+static const u16 mcp25xxfd_crc16_table[] = {
+ 0x, 0x8005, 0x800f, 0x000a, 0x801b, 0x001e, 0x0014, 0x8011,
+ 0x8033, 0x0036, 0x003c, 0x8039, 0x0028, 0x802d, 0x8027, 0x0022,
+ 0x8063, 0x0066, 0x006c, 0x8069, 0x0078, 0x807d, 0x8077, 0x0072,
+ 0x0050, 0x8055, 0x805f, 0x005a, 0x804b, 0x004e, 0x0044, 0x8041,
+ 0x80c3, 0x00c6, 0x00cc, 0x80c9, 0x00d8, 0x80dd, 0x80d7, 0x00d2,
+ 0x00f0, 0x80f5, 0x80ff, 0x00fa, 0x80eb, 0x00ee, 0x00e4, 0x80e1,
+ 0x00a0, 0x80a5, 0x80af, 0x00aa, 0x80bb, 0x00be, 0x00b4, 0x80b1,
+ 0x8093, 0x0096, 0x009c, 0x8099, 0x0088, 0x808d, 0x8087, 0x0082,
+ 0x8183, 0x0186, 0x018c, 0x8189, 0x0198, 0x819d, 0x8197, 0x0192,
+ 0x01b0, 0x81b5, 0x81bf, 0x01ba, 0x81ab, 0x01ae, 0x01a4, 0x81a1,
+ 0x01e0, 0x81e5, 0x81ef, 0x01ea, 0x81fb, 0x01fe, 0x01f4, 0x81f1,
+ 0x81d3, 0x01d6, 0x01dc, 0x81d9, 0x01c8, 0x81cd, 0x81c7, 0x01c2,
+ 0x0140, 0x8145, 0x814f, 0x014a, 0x815b, 0x015e, 0x0154, 0x8151,
+ 0x8173, 0x0176, 0x017c, 0x8179, 0x0168, 0x816d, 0x8167, 0x0162,
+ 0x8123, 0x0126, 0x012c, 0x8129, 0x0138, 0x813d, 0x8137, 0x0132,
+
Re: [PATCH] checkpatch: Warn on self-assignments
On Thu, 2020-09-10 at 12:51 -0700, Kees Cook wrote:
> On Sat, Sep 05, 2020 at 10:58:29AM -0700, Joe Perches wrote:
> > The uninitialized_var() macro was removed recently via
> > commit 63a0895d960a ("compiler: Remove uninitialized_var() macro")
> > as it's not a particularly useful warning and its use can
> > "paper over real bugs".
> >
> > Add a checkpatch test to warn on self-assignments as a means
> > to avoid compiler warnings and as a back-door mechanism to
> > reproduce the old uninitialized_var macro behavior.
> >
> > Signed-off-by: Joe Perches
>
> I like it! :)
>
> Can you add a section to code style and include a link in the checkpatch
> warning to it? (Feel free to just reuse the text removed from
> deprecated.rst)
Hi Kees.
I believe coding style is already a bit bloated
and more rules and content really won't add much
for new developers.
You're welcome to try to add whatever you want
to it though.
cheers, Joe
[PATCH] net: mvpp2: ptp: Fix unused variables
In the functions mvpp2_isr_handle_xlg() and
mvpp2_isr_handle_gmac_internal(), the bool variable link is assigned a
true value in the case that a given bit of val is set. However, if the
bit is unset, no value is assigned to link and it is then passed to
mvpp2_isr_handle_link() without being initialised. Fix by assigning to
link the value of the bit test.
Build-tested on x86.
Fixes: 36cfd3a6e52b ("net: mvpp2: restructure "link status" interrupt handling")
Signed-off-by: Alex Dewar
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 7d86940747d1..87b1c9cfdc77 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -3070,8 +3070,7 @@ static void mvpp2_isr_handle_xlg(struct mvpp2_port *port)
val = readl(port->base + MVPP22_XLG_INT_STAT);
if (val & MVPP22_XLG_INT_STAT_LINK) {
val = readl(port->base + MVPP22_XLG_STATUS);
- if (val & MVPP22_XLG_STATUS_LINK_UP)
- link = true;
+ link = (val & MVPP22_XLG_STATUS_LINK_UP);
mvpp2_isr_handle_link(port, link);
}
}
@@ -3087,8 +3086,7 @@ static void mvpp2_isr_handle_gmac_internal(struct
mvpp2_port *port)
val = readl(port->base + MVPP22_GMAC_INT_STAT);
if (val & MVPP22_GMAC_INT_STAT_LINK) {
val = readl(port->base + MVPP2_GMAC_STATUS0);
- if (val & MVPP2_GMAC_STATUS0_LINK_UP)
- link = true;
+ link = (val & MVPP2_GMAC_STATUS0_LINK_UP);
mvpp2_isr_handle_link(port, link);
}
}
--
2.28.0
[PATCH 2/6] dt-bindings: can: mcp25xxfd: document device tree bindings
From: Oleksij Rempel
This patch adds the device-tree binding documentation for the Microchip
MCP25xxFD SPI CAN controller family.
Signed-off-by: Oleksij Rempel
Signed-off-by: Marc Kleine-Budde
Signed-off-by: Manivannan Sadhasivam
---
.../bindings/net/can/microchip,mcp25xxfd.yaml | 79 +++
1 file changed, 79 insertions(+)
create mode 100644
Documentation/devicetree/bindings/net/can/microchip,mcp25xxfd.yaml
diff --git a/Documentation/devicetree/bindings/net/can/microchip,mcp25xxfd.yaml
b/Documentation/devicetree/bindings/net/can/microchip,mcp25xxfd.yaml
new file mode 100644
index ..aa2cad14d6d7
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/microchip,mcp25xxfd.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/can/microchip,mcp25xxfd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title:
+ Microchip MCP2517FD and MCP2518FD stand-alone CAN controller device tree
+ bindings
+
+maintainers:
+ - Marc Kleine-Budde
+
+properties:
+ compatible:
+oneOf:
+ - const: microchip,mcp2517fd
+description: for MCP2517FD
+ - const: microchip,mcp2518fd
+description: for MCP2518FD
+ - const: microchip,mcp25xxfd
+description: to autodetect chip variant
+
+ reg:
+maxItems: 1
+
+ interrupts-extended:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ vdd-supply:
+description: Regulator that powers the CAN controller.
+maxItems: 1
+
+ xceiver-supply:
+description: Regulator that powers the CAN transceiver.
+maxItems: 1
+
+ microchip,rx-int-gpios:
+description:
+ GPIO phandle of GPIO connected to to INT1 pin of the MCP25XXFD, which
+ signals a pending RX interrupt.
+maxItems: 1
+
+ spi-max-frequency:
+description:
+ Must be half or less of "clocks" frequency.
+maximum: 2000
+
+required:
+ - compatible
+ - reg
+ - interrupts-extended
+ - clocks
+
+examples:
+ - |
+#include
+#include
+
+spi0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+can@0 {
+compatible = "microchip,mcp25xxfd";
+reg = <0>;
+clocks = <_osc>;
+pinctrl-names = "default";
+pinctrl-0 = <_pins>;
+spi-max-frequency = <2000>;
+interrupts-extended = < 13 IRQ_TYPE_LEVEL_LOW>;
+microchip,rx-int-gpios = < 27 GPIO_ACTIVE_LOW>;
+vdd-supply = <>;
+xceiver-supply = <>;
+};
+};
--
2.17.1
[PATCH V2 1/4] perf tools: Rename group to topdown
From: Kan Liang
The group.h/c only include TopDown group related functions. The name
"group" is too generic and inaccurate. Use the name "topdown" to
replace it.
Move topdown related functions to a dedicated file, topdown.c.
Acked-by: Jiri Olsa
Signed-off-by: Kan Liang
---
tools/perf/arch/x86/util/Build| 2 +-
.../perf/arch/x86/util/{group.c => topdown.c} | 2 +-
tools/perf/builtin-stat.c | 51 +-
tools/perf/util/Build | 1 +
tools/perf/util/topdown.c | 53 +++
tools/perf/util/{group.h => topdown.h}| 6 ++-
6 files changed, 61 insertions(+), 54 deletions(-)
rename tools/perf/arch/x86/util/{group.c => topdown.c} (95%)
create mode 100644 tools/perf/util/topdown.c
rename tools/perf/util/{group.h => topdown.h} (52%)
diff --git a/tools/perf/arch/x86/util/Build b/tools/perf/arch/x86/util/Build
index 47f9c56e744f..347c39b960eb 100644
--- a/tools/perf/arch/x86/util/Build
+++ b/tools/perf/arch/x86/util/Build
@@ -3,7 +3,7 @@ perf-y += tsc.o
perf-y += pmu.o
perf-y += kvm-stat.o
perf-y += perf_regs.o
-perf-y += group.o
+perf-y += topdown.o
perf-y += machine.o
perf-y += event.o
diff --git a/tools/perf/arch/x86/util/group.c
b/tools/perf/arch/x86/util/topdown.c
similarity index 95%
rename from tools/perf/arch/x86/util/group.c
rename to tools/perf/arch/x86/util/topdown.c
index e2f8034b8973..597e963fb3e7 100644
--- a/tools/perf/arch/x86/util/group.c
+++ b/tools/perf/arch/x86/util/topdown.c
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
#include
#include "api/fs/fs.h"
-#include "util/group.h"
+#include "util/topdown.h"
/*
* Check whether we can use a group for top down.
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 483a28ef4ec4..5583e22ca808 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -56,7 +56,7 @@
#include "util/cpumap.h"
#include "util/thread_map.h"
#include "util/counts.h"
-#include "util/group.h"
+#include "util/topdown.h"
#include "util/session.h"
#include "util/tool.h"
#include "util/string2.h"
@@ -1495,55 +1495,6 @@ static int perf_stat_init_aggr_mode_file(struct
perf_stat *st)
return 0;
}
-static int topdown_filter_events(const char **attr, char **str, bool use_group)
-{
- int off = 0;
- int i;
- int len = 0;
- char *s;
-
- for (i = 0; attr[i]; i++) {
- if (pmu_have_event("cpu", attr[i])) {
- len += strlen(attr[i]) + 1;
- attr[i - off] = attr[i];
- } else
- off++;
- }
- attr[i - off] = NULL;
-
- *str = malloc(len + 1 + 2);
- if (!*str)
- return -1;
- s = *str;
- if (i - off == 0) {
- *s = 0;
- return 0;
- }
- if (use_group)
- *s++ = '{';
- for (i = 0; attr[i]; i++) {
- strcpy(s, attr[i]);
- s += strlen(s);
- *s++ = ',';
- }
- if (use_group) {
- s[-1] = '}';
- *s = 0;
- } else
- s[-1] = 0;
- return 0;
-}
-
-__weak bool arch_topdown_check_group(bool *warn)
-{
- *warn = false;
- return false;
-}
-
-__weak void arch_topdown_group_warn(void)
-{
-}
-
/*
* Add default attributes, if there were no attributes specified or
* if -d/--detailed, -d -d or -d -d -d is used:
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index cd5e41960e64..eebbd5223cae 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -101,6 +101,7 @@ perf-y += call-path.o
perf-y += rwsem.o
perf-y += thread-stack.o
perf-y += spark.o
+perf-y += topdown.o
perf-$(CONFIG_AUXTRACE) += auxtrace.o
perf-$(CONFIG_AUXTRACE) += intel-pt-decoder/
perf-$(CONFIG_AUXTRACE) += intel-pt.o
diff --git a/tools/perf/util/topdown.c b/tools/perf/util/topdown.c
new file mode 100644
index ..a085b3c77c27
--- /dev/null
+++ b/tools/perf/util/topdown.c
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+#include "pmu.h"
+#include "topdown.h"
+
+int topdown_filter_events(const char **attr, char **str, bool use_group)
+{
+ int off = 0;
+ int i;
+ int len = 0;
+ char *s;
+
+ for (i = 0; attr[i]; i++) {
+ if (pmu_have_event("cpu", attr[i])) {
+ len += strlen(attr[i]) + 1;
+ attr[i - off] = attr[i];
+ } else
+ off++;
+ }
+ attr[i - off] = NULL;
+
+ *str = malloc(len + 1 + 2);
+ if (!*str)
+ return -1;
+ s = *str;
+ if (i - off == 0) {
+ *s = 0;
+ return 0;
+ }
+ if (use_group)
+ *s++ = '{';
+ for (i = 0; attr[i]; i++) {
+ strcpy(s, attr[i]);
+ s += strlen(s);
+ *s++ = ',';
+ }
+
