Re: [PATCH -next] ulp/ipoib/ipoib_multicast: convert comma to semicolon
On Mon, Dec 14, 2020 at 09:42:18PM +0800, Zheng Yongjun wrote: > Replace a comma between expression statements by a semicolon. > > Signed-off-by: Zheng Yongjun > --- > drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Can you please do it in one patch for whole subsystem? Thanks
Re: [PATCH] power: supply: PCHG: Peripheral device charger
On Mon, 14 Dec 2020, Daisuke Nojiri wrote:
> This patch adds a driver for PCHG (Peripheral CHarGer). PCHG is a
> framework managing power supplies for peripheral devices.
>
> This driver creates a sysfs node for each peripheral charge port:
>
> /sys/class/power_supply/PCHGn
>
> where is the index of a charge port.
>
> For example, when a stylus is connected to a NFC/WLC port, the node
> prints:
>
> /sys/class/power_supply/PCHG0/
> capacity=50
> status=Charging
> type=Wireless
>
> Signed-off-by: Daisuke Nojiri
> ---
>
> drivers/mfd/cros_ec_dev.c | 1 +
This should be a separate patch.
> drivers/power/supply/Kconfig | 10 +
> drivers/power/supply/Makefile | 1 +
> .../power/supply/cros_peripheral_charger.c| 346 ++
> .../linux/platform_data/cros_ec_commands.h| 48 +++
> 5 files changed, 406 insertions(+)
> create mode 100644 drivers/power/supply/cros_peripheral_charger.c
>
> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> index 6135321592b76c..945565fc46a319 100644
> --- a/drivers/mfd/cros_ec_dev.c
> +++ b/drivers/mfd/cros_ec_dev.c
> @@ -85,6 +85,7 @@ static const struct mfd_cell cros_ec_sensorhub_cells[] = {
> static const struct mfd_cell cros_usbpd_charger_cells[] = {
> { .name = "cros-usbpd-charger", },
> { .name = "cros-usbpd-logger", },
> + { .name = "cros-pchg", },
> };
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH -next] infiniband: core: Delete useless kfree code
On Mon, Dec 14, 2020 at 09:46:55PM +0800, Zheng Yongjun wrote: > The parameter of kfree function is NULL, so kfree code is useless, delete it. > > Signed-off-by: Zheng Yongjun > --- > drivers/infiniband/core/cma_configfs.c | 1 - > 1 file changed, 1 deletion(-) The best thing will be to delete whole "free:" section and return an error immediately. Thanks > > diff --git a/drivers/infiniband/core/cma_configfs.c > b/drivers/infiniband/core/cma_configfs.c > index 7ec4af2ed87a..c6e7cd9bc25a 100644 > --- a/drivers/infiniband/core/cma_configfs.c > +++ b/drivers/infiniband/core/cma_configfs.c > @@ -235,7 +235,6 @@ static int make_cma_ports(struct cma_dev_group > *cma_dev_group, > > return 0; > free: > - kfree(ports); > cma_dev_group->ports = NULL; > return err; > } > -- > 2.22.0 >
Re: [PATCH] drm/hisilicon: Fix rmmod hibmc_drm failed
Hi Tian
Am 15.12.20 um 04:01 schrieb Tian Tao:
drm_irq_uninstall should be called before pci_disable_msi, if use
devm_drm_irq_install to register the interrupt, the system will
call pci_disable_msi first and then call drm_irq_uninstall, which
will result in the following callstack.
kernel BUG at drivers/pci/msi.c:376!
Internal error: Oops - BUG: 0 [#1] SMP
CPU: 93 PID: 173814 Comm: rmmod Tainted:
pstate: a049 (NzCv daif +PAN -UAO -TCO BTYPE=--)
pc : free_msi_irqs+0x17c/0x1a0
lr : free_msi_irqs+0x16c/0x1a0
sp : 2028157f7bd0
x29: 2028157f7bd0 x28: 202849edab00
x27: x26:
x25: x24:
x23: 0020851da000 x22: 0020851da2d8
x21: 0020cc829000 x20:
x19: 0020d6714800 x18: 0010
x17: x16:
x15: x14: 2028957f77df
x13: 2028157f77ed x12:
x11: 0040 x10: 800011b2f8e0
x9 : 800011b2f8d8 x8 : 2020203fc458
x7 : x6 :
x5 : 2020203fc430 x4 : 2020203fc4a0
x3 : x2 :
x1 : 02c9 x0 : 0020d6719500
Call trace:
free_msi_irqs+0x17c/0x1a0
pci_disable_msi+0xe4/0x118
hibmc_unload+0x44/0x80 [hibmc_drm]
hibmc_pci_remove+0x2c/0x38 [hibmc_drm]
pci_device_remove+0x48/0x108
device_release_driver_internal+0x118/0x1f0
driver_detach+0x6c/0xe0
bus_remove_driver+0x74/0x100
driver_unregister+0x34/0x60
pci_unregister_driver+0x24/0xd8
hibmc_pci_driver_exit+0x14/0xe768 [hibmc_drm]
__arm64_sys_delete_module+0x1fc/0x2d0
el0_svc_common.constprop.3+0xa8/0x188
do_el0_svc+0x80/0xa0
el0_sync_handler+0x8c/0xb0
el0_sync+0x15c/0x180
Code: f940b400 b400 a903e7b8 f90013b5 (d421)
---[ end trace 310d94ee8abef44f ]---
Kernel panic - not syncing: Oops - BUG: Fatal exception
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index e3ab765b..02f3bd1 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -251,6 +251,10 @@ static int hibmc_hw_init(struct hibmc_drm_private *priv)
static int hibmc_unload(struct drm_device *dev)
{
drm_atomic_helper_shutdown(dev);
+
+ if (dev->irq_enabled)
+ drm_irq_uninstall(dev);
+
pci_disable_msi(dev->pdev);
We're trying to move towards managed driver releases; and this feels
like a step backwards.
I looked through the PCI-device release code in pcim_release() and it
already disables MSI automatically. [1] You can enable the PCI device
with pcim_enable_device() instead of pci_enable_device() to use the
automatic release. No more need to disable MSI manually.
If this does not work, could you provide a managed version of
pci_disable_msi() that solves the problem?
Best regards
Thomas
[1] https://elixir.bootlin.com/linux/latest/source/drivers/pci/pci.c#L1976
return 0;
@@ -286,7 +290,7 @@ static int hibmc_load(struct drm_device *dev)
if (ret) {
drm_warn(dev, "enabling MSI failed: %d\n", ret);
} else {
- ret = devm_drm_irq_install(dev, dev->pdev->irq);
+ ret = drm_irq_install(dev, dev->pdev->irq);
if (ret)
drm_warn(dev, "install irq failed: %d\n", ret);
}
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v4 2/3] backlight: rt4831: Adds DT binding document for Richtek RT4831 backlight
On Mon, 14 Dec 2020, Daniel Thompson wrote: > On Mon, Dec 14, 2020 at 10:40:55PM +0800, ChiYuan Huang wrote: > > Hi, > > > > Daniel Thompson 於 2020年12月14日 週一 下午5:59寫道： > > > > > > Hi CY > > > > > > On Sat, Dec 12, 2020 at 12:33:43AM +0800, cy_huang wrote: > > > > From: ChiYuan Huang > > > > > > > > Adds DT binding document for Richtek RT4831 backlight. > > > > > > > > Signed-off-by: ChiYuan Huang > > > > > > This patch got keyword filtered and brought to my attention > > > but the rest of the series did not. > > > > > > If it was a backlight patch series you need to send it To: the > > > all the backlight maintainers. > > > > > Yes, I'm waiting for mfd reviewing. > > Due to mfd patch, I need to add backlight dt-binding patch prior to > > backlight source code. > > Or autobuild robot will said mfd dt-binding build fail from Rob. > > That's why I send the backlight dt-binding prior to the source code. > > > > I still have backlight/regulator source code patch after mfd reviewing. > > Do you want me to send all the patches without waiting for mfd reviewing? > > To some extent it's up to you. > > I think I would have shared all the pieces at once (although not it Lee, > as mfd maintainer, had suggested otherwise). You should not need to concern yourself with patch ordering outside of the realms of the set i.e. [PATCH 1/x], [PATCH 2/x], etc. If you just send the whole patch set and you do not specify otherwise, it will be applied, in order, as a set. Sending subsystem patches without the correct maintainers as recipients is bad form. Many of us have filters on, so this tactic will seldom work in any case. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 00/10] workqueue: break affinity initiatively
On Tue, Dec 15, 2020 at 01:44:53PM +0800, Lai Jiangshan wrote: > I don't know how the scheduler distinguishes all these > different cases under the "new assumption". The special case is: (p->flags & PF_KTHREAD) && p->nr_cpus_allowed == 1
答复: [PATCH] irqchip/gic-v3: Check SRE bit for GICv2 legacy support
Sorry response late. Hi Shameer & Ard, Could you let me know which firmware you are using? If the difference is Madt table vGIC your pointed , they are the same. We changed the vGIC memory base address at very early design stage. Thanks！ -邮件原件- 发件人: Shameerali Kolothum Thodi 发送时间: 2020年12月2日 16:23 收件人: Ard Biesheuvel 抄送: Marc Zyngier ; eric.au...@redhat.com; linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Linuxarm ; wanghuiqiang ; xuwei (O) 主题: RE: [PATCH] irqchip/gic-v3: Check SRE bit for GICv2 legacy support [+] > -Original Message- > From: Ard Biesheuvel [mailto:a...@kernel.org] > Sent: 30 November 2020 18:32 > To: Shameerali Kolothum Thodi > Cc: Marc Zyngier ; eric.au...@redhat.com; > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > Linuxarm > Subject: Re: [PATCH] irqchip/gic-v3: Check SRE bit for GICv2 legacy > support > ... > > Any clue why production D06 firmware deviates from the D06 port that > exists in Tianocore's edk2-platforms repository? Because that version > does not have this bug, and I wonder why that code was upstreamed at > all if a substantially different version gets shipped with production > hardware. Ok. Thanks for pointing this out. I have informed our UEFI team about this. They will check Internally and clarify. Regards, Shameer
Re: linux-next: build warning after merge of the net-next tree
On Tue, Dec 15, 2020 at 07:01:25AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 26 Nov 2020 17:40:57 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the net-next tree, today's linux-next build (htmldocs)
> > produced this warning:
> >
> > include/linux/phy.h:869: warning: Function parameter or member
> > 'config_intr' not described in 'phy_driver'
> >
> > Introduced by commit
> >
> > 6527b938426f ("net: phy: remove the .did_interrupt() and .ack_interrupt()
> > callback")
>
> I am still getting this warning.
Hi,
Sorry for not responding in time, I know I verified this the first time
but somehow did not answer the email.
The .config_intr() is documented but it seems that it's not parsed
properly since the comment starts on the same line as the /**. A diff
like below seems to do the trick. I will send it out.
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -743,7 +743,8 @@ struct phy_driver {
/** @read_status: Determines the negotiated speed and duplex */
int (*read_status)(struct phy_device *phydev);
- /** @config_intr: Enables or disables interrupts.
+ /**
+* @config_intr: Enables or disables interrupts.
* It should also clear any pending interrupts prior to enabling the
* IRQs and after disabling them.
*/
Ioana
Re: [PATCH 0/3] block: blk_interposer - Block Layer Interposer
On 12/15/20 7:51 AM, Bob Liu wrote: Hi Folks, On 12/12/20 12:56 AM, Hannes Reinecke wrote: On 12/11/20 5:33 PM, Jens Axboe wrote: On 12/11/20 9:30 AM, Mike Snitzer wrote: While I still think there needs to be a proper _upstream_ consumer of blk_interposer as a condition of it going in.. I'll let others make the call. That's an unequivocal rule. As such, I'll defer to Jens, Christoph and others on whether your minimalist blk_interposer hook is acceptable in the near-term. I don't think so, we don't do short term bandaids just to plan on ripping that out when the real functionality is there. IMHO, the dm approach is the way to go - it provides exactly the functionality that is needed in an appropriate way, instead of hacking some "interposer" into the core block layer. Which is my plan, too. I'll be working with the Veeam folks to present a joint patchset (including the DM bits) for the next round. Besides the dm approach, do you think Veeam's original requirement is a good use case of "block/bpf: add eBPF based block layer IO filtering"? https://lwn.net/ml/bpf/20200812163305.545447-1-leah.ruman...@gmail.com/ That would actually a really cool use-case. You could also consider a XDP-like functionality for eBPF, to move individual requests from one queue to the other; DM on steroids :-) Should I try to include that patchset? Cheers, Hannes -- Dr. Hannes ReineckeKernel Storage Architect h...@suse.de +49 911 74053 688 SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
[PATCH v4 12/13] iommu/amd: Introduce iommu_v1_map_page and iommu_v1_unmap_page
These implement map and unmap for AMD IOMMU v1 pagetable, which
will be used by the IO pagetable framework.
Also clean up unused extern function declarations.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/amd_iommu.h | 13 -
drivers/iommu/amd/io_pgtable.c | 25 -
drivers/iommu/amd/iommu.c | 13 -
3 files changed, 20 insertions(+), 31 deletions(-)
diff --git a/drivers/iommu/amd/amd_iommu.h b/drivers/iommu/amd/amd_iommu.h
index 83ca822c5349..3770b1a4d51c 100644
--- a/drivers/iommu/amd/amd_iommu.h
+++ b/drivers/iommu/amd/amd_iommu.h
@@ -133,19 +133,6 @@ void amd_iommu_apply_ivrs_quirks(void);
static inline void amd_iommu_apply_ivrs_quirks(void) { }
#endif
-/* TODO: These are temporary and will be removed once fully transition */
-extern int iommu_map_page(struct protection_domain *dom,
- unsigned long bus_addr,
- unsigned long phys_addr,
- unsigned long page_size,
- int prot,
- gfp_t gfp);
-extern unsigned long iommu_unmap_page(struct protection_domain *dom,
- unsigned long bus_addr,
- unsigned long page_size);
-extern u64 *fetch_pte(struct amd_io_pgtable *pgtable,
- unsigned long address,
- unsigned long *page_size);
extern void amd_iommu_domain_set_pgtable(struct protection_domain *domain,
u64 *root, int mode);
#endif
diff --git a/drivers/iommu/amd/io_pgtable.c b/drivers/iommu/amd/io_pgtable.c
index a293b69b38b9..d91964e98d58 100644
--- a/drivers/iommu/amd/io_pgtable.c
+++ b/drivers/iommu/amd/io_pgtable.c
@@ -317,9 +317,9 @@ static u64 *alloc_pte(struct protection_domain *domain,
* This function checks if there is a PTE for a given dma address. If
* there is one, it returns the pointer to it.
*/
-u64 *fetch_pte(struct amd_io_pgtable *pgtable,
- unsigned long address,
- unsigned long *page_size)
+static u64 *fetch_pte(struct amd_io_pgtable *pgtable,
+ unsigned long address,
+ unsigned long *page_size)
{
int level;
u64 *pte;
@@ -392,13 +392,10 @@ static struct page *free_clear_pte(u64 *pte, u64 pteval,
struct page *freelist)
* supporting all features of AMD IOMMU page tables like level skipping
* and full 64 bit address spaces.
*/
-int iommu_map_page(struct protection_domain *dom,
- unsigned long iova,
- unsigned long paddr,
- unsigned long size,
- int prot,
- gfp_t gfp)
+static int iommu_v1_map_page(struct io_pgtable_ops *ops, unsigned long iova,
+ phys_addr_t paddr, size_t size, int prot, gfp_t gfp)
{
+ struct protection_domain *dom = io_pgtable_ops_to_domain(ops);
struct page *freelist = NULL;
bool updated = false;
u64 __pte, *pte;
@@ -461,11 +458,11 @@ int iommu_map_page(struct protection_domain *dom,
return ret;
}
-unsigned long iommu_unmap_page(struct protection_domain *dom,
- unsigned long iova,
- unsigned long size)
+static unsigned long iommu_v1_unmap_page(struct io_pgtable_ops *ops,
+ unsigned long iova,
+ size_t size,
+ struct iommu_iotlb_gather *gather)
{
- struct io_pgtable_ops *ops = >iop.iop.ops;
struct amd_io_pgtable *pgtable = io_pgtable_ops_to_data(ops);
unsigned long long unmapped;
unsigned long unmap_size;
@@ -554,6 +551,8 @@ static struct io_pgtable *v1_alloc_pgtable(struct
io_pgtable_cfg *cfg, void *coo
cfg->oas= IOMMU_OUT_ADDR_BIT_SIZE,
cfg->tlb= _flush_ops;
+ pgtable->iop.ops.map = iommu_v1_map_page;
+ pgtable->iop.ops.unmap= iommu_v1_unmap_page;
pgtable->iop.ops.iova_to_phys = iommu_v1_iova_to_phys;
return >iop;
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 29b7fefc8485..1f04b251f0c6 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -2066,8 +2066,9 @@ static int amd_iommu_map(struct iommu_domain *dom,
unsigned long iova,
gfp_t gfp)
{
struct protection_domain *domain = to_pdomain(dom);
+ struct io_pgtable_ops *ops = >iop.iop.ops;
int prot = 0;
- int ret;
+ int ret = -EINVAL;
if (domain->iop.mode == PAGE_MODE_NONE)
return -EINVAL;
@@ -2077,9 +2078,10 @@ static int amd_iommu_map(struct iommu_domain *dom,
unsigned long iova,
if (iommu_prot & IOMMU_WRITE)
prot |= IOMMU_PROT_IW;
- ret = iommu_map_page(domain, iova, paddr, page_size, prot, gfp);
-
-
Re: [PATCH] proc: Escape more characters in /proc/mounts output
On 12/15/20 11:40 AM, Al Viro wrote: On Tue, Dec 15, 2020 at 09:54:54AM +0530, Siddhesh Poyarekar wrote: + get_user(byte, (const char __user *)data); + + return byte ? strndup_user(data, PATH_MAX) : NULL; } No. Not to mention anything else, you * fetch the same data twice * fail to check the get_user() results Ahh sorry, I could inline the strndup_user call and put an additional check for length == 1 to return NULL. Would that be acceptable? The other alternative would be to not touch copy_mount_string and instead, check after fetching the string and if it is blank, free it and set to NULL. That seems more expensive though. Siddhesh
[PATCH v4 11/13] iommu/amd: Introduce iommu_v1_iova_to_phys
This implements iova_to_phys for AMD IOMMU v1 pagetable,
which will be used by the IO page table framework.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/io_pgtable.c | 22 ++
drivers/iommu/amd/iommu.c | 16 +---
2 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/drivers/iommu/amd/io_pgtable.c b/drivers/iommu/amd/io_pgtable.c
index 87184b6cee0f..a293b69b38b9 100644
--- a/drivers/iommu/amd/io_pgtable.c
+++ b/drivers/iommu/amd/io_pgtable.c
@@ -494,6 +494,26 @@ unsigned long iommu_unmap_page(struct protection_domain
*dom,
return unmapped;
}
+static phys_addr_t iommu_v1_iova_to_phys(struct io_pgtable_ops *ops, unsigned
long iova)
+{
+ struct amd_io_pgtable *pgtable = io_pgtable_ops_to_data(ops);
+ unsigned long offset_mask, pte_pgsize;
+ u64 *pte, __pte;
+
+ if (pgtable->mode == PAGE_MODE_NONE)
+ return iova;
+
+ pte = fetch_pte(pgtable, iova, _pgsize);
+
+ if (!pte || !IOMMU_PTE_PRESENT(*pte))
+ return 0;
+
+ offset_mask = pte_pgsize - 1;
+ __pte = __sme_clr(*pte & PM_ADDR_MASK);
+
+ return (__pte & ~offset_mask) | (iova & offset_mask);
+}
+
/*
*
*/
@@ -534,6 +554,8 @@ static struct io_pgtable *v1_alloc_pgtable(struct
io_pgtable_cfg *cfg, void *coo
cfg->oas= IOMMU_OUT_ADDR_BIT_SIZE,
cfg->tlb= _flush_ops;
+ pgtable->iop.ops.iova_to_phys = iommu_v1_iova_to_phys;
+
return >iop;
}
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 76f61dd6b89f..29b7fefc8485 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -2101,22 +2101,8 @@ static phys_addr_t amd_iommu_iova_to_phys(struct
iommu_domain *dom,
{
struct protection_domain *domain = to_pdomain(dom);
struct io_pgtable_ops *ops = >iop.iop.ops;
- struct amd_io_pgtable *pgtable = io_pgtable_ops_to_data(ops);
- unsigned long offset_mask, pte_pgsize;
- u64 *pte, __pte;
- if (domain->iop.mode == PAGE_MODE_NONE)
- return iova;
-
- pte = fetch_pte(pgtable, iova, _pgsize);
-
- if (!pte || !IOMMU_PTE_PRESENT(*pte))
- return 0;
-
- offset_mask = pte_pgsize - 1;
- __pte = __sme_clr(*pte & PM_ADDR_MASK);
-
- return (__pte & ~offset_mask) | (iova & offset_mask);
+ return ops->iova_to_phys(ops, iova);
}
static bool amd_iommu_capable(enum iommu_cap cap)
--
2.17.1
[PATCH v4 04/13] iommu/amd: Convert to using amd_io_pgtable
Make use of the new struct amd_io_pgtable in preparation to remove
the struct domain_pgtable.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/amd_iommu.h | 1 +
drivers/iommu/amd/iommu.c | 25 ++---
2 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/iommu/amd/amd_iommu.h b/drivers/iommu/amd/amd_iommu.h
index b8dae3941f0f..bf9723b35e77 100644
--- a/drivers/iommu/amd/amd_iommu.h
+++ b/drivers/iommu/amd/amd_iommu.h
@@ -56,6 +56,7 @@ extern void amd_iommu_domain_direct_map(struct iommu_domain
*dom);
extern int amd_iommu_domain_enable_v2(struct iommu_domain *dom, int pasids);
extern int amd_iommu_flush_page(struct iommu_domain *dom, u32 pasid,
u64 address);
+extern void amd_iommu_update_and_flush_device_table(struct protection_domain
*domain);
extern int amd_iommu_flush_tlb(struct iommu_domain *dom, u32 pasid);
extern int amd_iommu_domain_set_gcr3(struct iommu_domain *dom, u32 pasid,
unsigned long cr3);
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 5b93536d6877..fdb6030b505d 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -89,8 +89,6 @@ struct kmem_cache *amd_iommu_irq_cache;
static void update_domain(struct protection_domain *domain);
static void detach_device(struct device *dev);
-static void update_and_flush_device_table(struct protection_domain *domain,
- struct domain_pgtable *pgtable);
/
*
@@ -1502,7 +1500,7 @@ static bool increase_address_space(struct
protection_domain *domain,
pgtable.root = pte;
pgtable.mode += 1;
- update_and_flush_device_table(domain, );
+ amd_iommu_update_and_flush_device_table(domain);
domain_flush_complete(domain);
/*
@@ -1877,17 +1875,16 @@ static void free_gcr3_table(struct protection_domain
*domain)
}
static void set_dte_entry(u16 devid, struct protection_domain *domain,
- struct domain_pgtable *pgtable,
bool ats, bool ppr)
{
u64 pte_root = 0;
u64 flags = 0;
u32 old_domid;
- if (pgtable->mode != PAGE_MODE_NONE)
- pte_root = iommu_virt_to_phys(pgtable->root);
+ if (domain->iop.mode != PAGE_MODE_NONE)
+ pte_root = iommu_virt_to_phys(domain->iop.root);
- pte_root |= (pgtable->mode & DEV_ENTRY_MODE_MASK)
+ pte_root |= (domain->iop.mode & DEV_ENTRY_MODE_MASK)
<< DEV_ENTRY_MODE_SHIFT;
pte_root |= DTE_FLAG_IR | DTE_FLAG_IW | DTE_FLAG_V | DTE_FLAG_TV;
@@ -1977,7 +1974,7 @@ static void do_attach(struct iommu_dev_data *dev_data,
/* Update device table */
amd_iommu_domain_get_pgtable(domain, );
- set_dte_entry(dev_data->devid, domain, ,
+ set_dte_entry(dev_data->devid, domain,
ats, dev_data->iommu_v2);
clone_aliases(dev_data->pdev);
@@ -2284,22 +2281,20 @@ static int amd_iommu_domain_get_attr(struct
iommu_domain *domain,
*
*/
-static void update_device_table(struct protection_domain *domain,
- struct domain_pgtable *pgtable)
+static void update_device_table(struct protection_domain *domain)
{
struct iommu_dev_data *dev_data;
list_for_each_entry(dev_data, >dev_list, list) {
- set_dte_entry(dev_data->devid, domain, pgtable,
+ set_dte_entry(dev_data->devid, domain,
dev_data->ats.enabled, dev_data->iommu_v2);
clone_aliases(dev_data->pdev);
}
}
-static void update_and_flush_device_table(struct protection_domain *domain,
- struct domain_pgtable *pgtable)
+void amd_iommu_update_and_flush_device_table(struct protection_domain *domain)
{
- update_device_table(domain, pgtable);
+ update_device_table(domain);
domain_flush_devices(domain);
}
@@ -2309,7 +2304,7 @@ static void update_domain(struct protection_domain
*domain)
/* Update device table */
amd_iommu_domain_get_pgtable(domain, );
- update_and_flush_device_table(domain, );
+ amd_iommu_update_and_flush_device_table(domain);
/* Flush domain TLB(s) and wait for completion */
domain_flush_tlb_pde(domain);
--
2.17.1
[PATCH v4 02/13] iommu/amd: Prepare for generic IO page table framework
Add initial hook up code to implement generic IO page table framework.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/Kconfig | 1 +
drivers/iommu/amd/Makefile | 2 +-
drivers/iommu/amd/amd_iommu_types.h | 35 ++
drivers/iommu/amd/io_pgtable.c | 75 +
drivers/iommu/amd/iommu.c | 10
drivers/iommu/io-pgtable.c | 3 ++
include/linux/io-pgtable.h | 2 +
7 files changed, 117 insertions(+), 11 deletions(-)
create mode 100644 drivers/iommu/amd/io_pgtable.c
diff --git a/drivers/iommu/amd/Kconfig b/drivers/iommu/amd/Kconfig
index 626b97d0dd21..a3cbafb603f5 100644
--- a/drivers/iommu/amd/Kconfig
+++ b/drivers/iommu/amd/Kconfig
@@ -10,6 +10,7 @@ config AMD_IOMMU
select IOMMU_API
select IOMMU_IOVA
select IOMMU_DMA
+ select IOMMU_IO_PGTABLE
depends on X86_64 && PCI && ACPI && HAVE_CMPXCHG_DOUBLE
help
With this option you can enable support for AMD IOMMU hardware in
diff --git a/drivers/iommu/amd/Makefile b/drivers/iommu/amd/Makefile
index dc5a2fa4fd37..a935f8f4b974 100644
--- a/drivers/iommu/amd/Makefile
+++ b/drivers/iommu/amd/Makefile
@@ -1,4 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
-obj-$(CONFIG_AMD_IOMMU) += iommu.o init.o quirks.o
+obj-$(CONFIG_AMD_IOMMU) += iommu.o init.o quirks.o io_pgtable.o
obj-$(CONFIG_AMD_IOMMU_DEBUGFS) += debugfs.o
obj-$(CONFIG_AMD_IOMMU_V2) += iommu_v2.o
diff --git a/drivers/iommu/amd/amd_iommu_types.h
b/drivers/iommu/amd/amd_iommu_types.h
index 494b42a31b7a..5d77f34e0fda 100644
--- a/drivers/iommu/amd/amd_iommu_types.h
+++ b/drivers/iommu/amd/amd_iommu_types.h
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
/*
* Maximum number of IOMMUs supported
@@ -252,6 +253,19 @@
#define GA_GUEST_NR0x1
+#define IOMMU_IN_ADDR_BIT_SIZE 52
+#define IOMMU_OUT_ADDR_BIT_SIZE 52
+
+/*
+ * This bitmap is used to advertise the page sizes our hardware support
+ * to the IOMMU core, which will then use this information to split
+ * physically contiguous memory regions it is mapping into page sizes
+ * that we support.
+ *
+ * 512GB Pages are not supported due to a hardware bug
+ */
+#define AMD_IOMMU_PGSIZES ((~0xFFFUL) & ~(2ULL << 38))
+
/* Bit value definition for dte irq remapping fields*/
#define DTE_IRQ_PHYS_ADDR_MASK (((1ULL << 45)-1) << 6)
#define DTE_IRQ_REMAP_INTCTL_MASK (0x3ULL << 60)
@@ -465,6 +479,26 @@ struct amd_irte_ops;
#define AMD_IOMMU_FLAG_TRANS_PRE_ENABLED (1 << 0)
+#define io_pgtable_to_data(x) \
+ container_of((x), struct amd_io_pgtable, iop)
+
+#define io_pgtable_ops_to_data(x) \
+ io_pgtable_to_data(io_pgtable_ops_to_pgtable(x))
+
+#define io_pgtable_ops_to_domain(x) \
+ container_of(io_pgtable_ops_to_data(x), \
+struct protection_domain, iop)
+
+#define io_pgtable_cfg_to_data(x) \
+ container_of((x), struct amd_io_pgtable, pgtbl_cfg)
+
+struct amd_io_pgtable {
+ struct io_pgtable_cfg pgtbl_cfg;
+ struct io_pgtable iop;
+ int mode;
+ u64 *root;
+};
+
/*
* This structure contains generic data for IOMMU protection domains
* independent of their use.
@@ -473,6 +507,7 @@ struct protection_domain {
struct list_head dev_list; /* List of all devices in this domain */
struct iommu_domain domain; /* generic domain handle used by
iommu core code */
+ struct amd_io_pgtable iop;
spinlock_t lock;/* mostly used to lock the page table*/
u16 id; /* the domain id written to the device table */
atomic64_t pt_root; /* pgtable root and pgtable mode */
diff --git a/drivers/iommu/amd/io_pgtable.c b/drivers/iommu/amd/io_pgtable.c
new file mode 100644
index ..aedf2c932c40
--- /dev/null
+++ b/drivers/iommu/amd/io_pgtable.c
@@ -0,0 +1,75 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * CPU-agnostic AMD IO page table allocator.
+ *
+ * Copyright (C) 2020 Advanced Micro Devices, Inc.
+ * Author: Suravee Suthikulpanit
+ */
+
+#define pr_fmt(fmt) "AMD-Vi: " fmt
+#define dev_fmt(fmt)pr_fmt(fmt)
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "amd_iommu_types.h"
+#include "amd_iommu.h"
+
+static void v1_tlb_flush_all(void *cookie)
+{
+}
+
+static void v1_tlb_flush_walk(unsigned long iova, size_t size,
+ size_t granule, void *cookie)
+{
+}
+
+static void v1_tlb_flush_leaf(unsigned long iova, size_t size,
+ size_t granule, void *cookie)
+{
+}
+
+static void v1_tlb_add_page(struct iommu_iotlb_gather *gather,
+unsigned long iova, size_t granule,
+void *cookie)
+{
+}
+
+static const struct iommu_flush_ops v1_flush_ops =
[PATCH v4 10/13] iommu/amd: Refactor fetch_pte to use struct amd_io_pgtable
To simplify the fetch_pte function. There is no functional change.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/amd_iommu.h | 2 +-
drivers/iommu/amd/io_pgtable.c | 13 +++--
drivers/iommu/amd/iommu.c | 4 +++-
3 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/amd/amd_iommu.h b/drivers/iommu/amd/amd_iommu.h
index 76276d9e463c..83ca822c5349 100644
--- a/drivers/iommu/amd/amd_iommu.h
+++ b/drivers/iommu/amd/amd_iommu.h
@@ -143,7 +143,7 @@ extern int iommu_map_page(struct protection_domain *dom,
extern unsigned long iommu_unmap_page(struct protection_domain *dom,
unsigned long bus_addr,
unsigned long page_size);
-extern u64 *fetch_pte(struct protection_domain *domain,
+extern u64 *fetch_pte(struct amd_io_pgtable *pgtable,
unsigned long address,
unsigned long *page_size);
extern void amd_iommu_domain_set_pgtable(struct protection_domain *domain,
diff --git a/drivers/iommu/amd/io_pgtable.c b/drivers/iommu/amd/io_pgtable.c
index 35dd9153e6b7..87184b6cee0f 100644
--- a/drivers/iommu/amd/io_pgtable.c
+++ b/drivers/iommu/amd/io_pgtable.c
@@ -317,7 +317,7 @@ static u64 *alloc_pte(struct protection_domain *domain,
* This function checks if there is a PTE for a given dma address. If
* there is one, it returns the pointer to it.
*/
-u64 *fetch_pte(struct protection_domain *domain,
+u64 *fetch_pte(struct amd_io_pgtable *pgtable,
unsigned long address,
unsigned long *page_size)
{
@@ -326,11 +326,11 @@ u64 *fetch_pte(struct protection_domain *domain,
*page_size = 0;
- if (address > PM_LEVEL_SIZE(domain->iop.mode))
+ if (address > PM_LEVEL_SIZE(pgtable->mode))
return NULL;
- level = domain->iop.mode - 1;
- pte= >iop.root[PM_LEVEL_INDEX(level, address)];
+ level = pgtable->mode - 1;
+ pte= >root[PM_LEVEL_INDEX(level, address)];
*page_size = PTE_LEVEL_PAGE_SIZE(level);
while (level > 0) {
@@ -465,6 +465,8 @@ unsigned long iommu_unmap_page(struct protection_domain
*dom,
unsigned long iova,
unsigned long size)
{
+ struct io_pgtable_ops *ops = >iop.iop.ops;
+ struct amd_io_pgtable *pgtable = io_pgtable_ops_to_data(ops);
unsigned long long unmapped;
unsigned long unmap_size;
u64 *pte;
@@ -474,8 +476,7 @@ unsigned long iommu_unmap_page(struct protection_domain
*dom,
unmapped = 0;
while (unmapped < size) {
- pte = fetch_pte(dom, iova, _size);
-
+ pte = fetch_pte(pgtable, iova, _size);
if (pte) {
int i, count;
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 2963a37b7c16..76f61dd6b89f 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -2100,13 +2100,15 @@ static phys_addr_t amd_iommu_iova_to_phys(struct
iommu_domain *dom,
dma_addr_t iova)
{
struct protection_domain *domain = to_pdomain(dom);
+ struct io_pgtable_ops *ops = >iop.iop.ops;
+ struct amd_io_pgtable *pgtable = io_pgtable_ops_to_data(ops);
unsigned long offset_mask, pte_pgsize;
u64 *pte, __pte;
if (domain->iop.mode == PAGE_MODE_NONE)
return iova;
- pte = fetch_pte(domain, iova, _pgsize);
+ pte = fetch_pte(pgtable, iova, _pgsize);
if (!pte || !IOMMU_PTE_PRESENT(*pte))
return 0;
--
2.17.1
[PATCH v4 08/13] iommu/amd: Remove amd_iommu_domain_get_pgtable
Since the IO page table root and mode parameters have been moved into
the struct amd_io_pg, the function is no longer needed. Therefore,
remove it along with the struct domain_pgtable.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/amd_iommu.h | 4 ++--
drivers/iommu/amd/amd_iommu_types.h | 6 -
drivers/iommu/amd/io_pgtable.c | 36 ++---
drivers/iommu/amd/iommu.c | 34 ---
4 files changed, 19 insertions(+), 61 deletions(-)
diff --git a/drivers/iommu/amd/amd_iommu.h b/drivers/iommu/amd/amd_iommu.h
index 91d098003f12..76276d9e463c 100644
--- a/drivers/iommu/amd/amd_iommu.h
+++ b/drivers/iommu/amd/amd_iommu.h
@@ -110,6 +110,8 @@ static inline
void amd_iommu_domain_set_pt_root(struct protection_domain *domain, u64 root)
{
atomic64_set(>iop.pt_root, root);
+ domain->iop.root = (u64 *)(root & PAGE_MASK);
+ domain->iop.mode = root & 7; /* lowest 3 bits encode pgtable mode */
}
static inline
@@ -144,8 +146,6 @@ extern unsigned long iommu_unmap_page(struct
protection_domain *dom,
extern u64 *fetch_pte(struct protection_domain *domain,
unsigned long address,
unsigned long *page_size);
-extern void amd_iommu_domain_get_pgtable(struct protection_domain *domain,
-struct domain_pgtable *pgtable);
extern void amd_iommu_domain_set_pgtable(struct protection_domain *domain,
u64 *root, int mode);
#endif
diff --git a/drivers/iommu/amd/amd_iommu_types.h
b/drivers/iommu/amd/amd_iommu_types.h
index 7c971c76d685..6897567d307e 100644
--- a/drivers/iommu/amd/amd_iommu_types.h
+++ b/drivers/iommu/amd/amd_iommu_types.h
@@ -518,12 +518,6 @@ struct protection_domain {
unsigned dev_iommu[MAX_IOMMUS]; /* per-IOMMU reference count */
};
-/* For decocded pt_root */
-struct domain_pgtable {
- int mode;
- u64 *root;
-};
-
/*
* Structure where we save information about one hardware AMD IOMMU in the
* system.
diff --git a/drivers/iommu/amd/io_pgtable.c b/drivers/iommu/amd/io_pgtable.c
index dc674e79ddf0..d4d131e43dcd 100644
--- a/drivers/iommu/amd/io_pgtable.c
+++ b/drivers/iommu/amd/io_pgtable.c
@@ -184,30 +184,27 @@ static bool increase_address_space(struct
protection_domain *domain,
unsigned long address,
gfp_t gfp)
{
- struct domain_pgtable pgtable;
unsigned long flags;
bool ret = true;
u64 *pte;
spin_lock_irqsave(>lock, flags);
- amd_iommu_domain_get_pgtable(domain, );
-
- if (address <= PM_LEVEL_SIZE(pgtable.mode))
+ if (address <= PM_LEVEL_SIZE(domain->iop.mode))
goto out;
ret = false;
- if (WARN_ON_ONCE(pgtable.mode == PAGE_MODE_6_LEVEL))
+ if (WARN_ON_ONCE(domain->iop.mode == PAGE_MODE_6_LEVEL))
goto out;
pte = (void *)get_zeroed_page(gfp);
if (!pte)
goto out;
- *pte = PM_LEVEL_PDE(pgtable.mode, iommu_virt_to_phys(pgtable.root));
+ *pte = PM_LEVEL_PDE(domain->iop.mode,
iommu_virt_to_phys(domain->iop.root));
- pgtable.root = pte;
- pgtable.mode += 1;
+ domain->iop.root = pte;
+ domain->iop.mode += 1;
amd_iommu_update_and_flush_device_table(domain);
amd_iommu_domain_flush_complete(domain);
@@ -215,7 +212,7 @@ static bool increase_address_space(struct protection_domain
*domain,
* Device Table needs to be updated and flushed before the new root can
* be published.
*/
- amd_iommu_domain_set_pgtable(domain, pte, pgtable.mode);
+ amd_iommu_domain_set_pgtable(domain, pte, domain->iop.mode);
ret = true;
@@ -232,29 +229,23 @@ static u64 *alloc_pte(struct protection_domain *domain,
gfp_t gfp,
bool *updated)
{
- struct domain_pgtable pgtable;
int level, end_lvl;
u64 *pte, *page;
BUG_ON(!is_power_of_2(page_size));
- amd_iommu_domain_get_pgtable(domain, );
-
- while (address > PM_LEVEL_SIZE(pgtable.mode)) {
+ while (address > PM_LEVEL_SIZE(domain->iop.mode)) {
/*
* Return an error if there is no memory to update the
* page-table.
*/
if (!increase_address_space(domain, address, gfp))
return NULL;
-
- /* Read new values to check if update was successful */
- amd_iommu_domain_get_pgtable(domain, );
}
- level = pgtable.mode - 1;
- pte = [PM_LEVEL_INDEX(level, address)];
+ level = domain->iop.mode - 1;
+ pte = >iop.root[PM_LEVEL_INDEX(level, address)];
address = PAGE_SIZE_ALIGN(address, page_size);
end_lvl = PAGE_SIZE_LEVEL(page_size);
@@ -330,19 +321,16 @@ u64
[PATCH v4 06/13] iommu/amd: Move IO page table related functions
Preparing to migrate to use IO page table framework.
There is no functional change.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/amd_iommu.h | 18 ++
drivers/iommu/amd/io_pgtable.c | 473
drivers/iommu/amd/iommu.c | 476 +
3 files changed, 493 insertions(+), 474 deletions(-)
diff --git a/drivers/iommu/amd/amd_iommu.h b/drivers/iommu/amd/amd_iommu.h
index bf29ab8c99f0..1bad42a3c73c 100644
--- a/drivers/iommu/amd/amd_iommu.h
+++ b/drivers/iommu/amd/amd_iommu.h
@@ -131,4 +131,22 @@ void amd_iommu_apply_ivrs_quirks(void);
static inline void amd_iommu_apply_ivrs_quirks(void) { }
#endif
+/* TODO: These are temporary and will be removed once fully transition */
+extern void free_pagetable(struct domain_pgtable *pgtable);
+extern int iommu_map_page(struct protection_domain *dom,
+ unsigned long bus_addr,
+ unsigned long phys_addr,
+ unsigned long page_size,
+ int prot,
+ gfp_t gfp);
+extern unsigned long iommu_unmap_page(struct protection_domain *dom,
+ unsigned long bus_addr,
+ unsigned long page_size);
+extern u64 *fetch_pte(struct protection_domain *domain,
+ unsigned long address,
+ unsigned long *page_size);
+extern void amd_iommu_domain_get_pgtable(struct protection_domain *domain,
+struct domain_pgtable *pgtable);
+extern void amd_iommu_domain_set_pgtable(struct protection_domain *domain,
+u64 *root, int mode);
#endif
diff --git a/drivers/iommu/amd/io_pgtable.c b/drivers/iommu/amd/io_pgtable.c
index aedf2c932c40..345e9bc81fde 100644
--- a/drivers/iommu/amd/io_pgtable.c
+++ b/drivers/iommu/amd/io_pgtable.c
@@ -50,6 +50,479 @@ static const struct iommu_flush_ops v1_flush_ops = {
.tlb_add_page = v1_tlb_add_page,
};
+/*
+ * Helper function to get the first pte of a large mapping
+ */
+static u64 *first_pte_l7(u64 *pte, unsigned long *page_size,
+unsigned long *count)
+{
+ unsigned long pte_mask, pg_size, cnt;
+ u64 *fpte;
+
+ pg_size = PTE_PAGE_SIZE(*pte);
+ cnt = PAGE_SIZE_PTE_COUNT(pg_size);
+ pte_mask = ~((cnt << 3) - 1);
+ fpte = (u64 *)(((unsigned long)pte) & pte_mask);
+
+ if (page_size)
+ *page_size = pg_size;
+
+ if (count)
+ *count = cnt;
+
+ return fpte;
+}
+
+/
+ *
+ * The functions below are used the create the page table mappings for
+ * unity mapped regions.
+ *
+ /
+
+static void free_page_list(struct page *freelist)
+{
+ while (freelist != NULL) {
+ unsigned long p = (unsigned long)page_address(freelist);
+
+ freelist = freelist->freelist;
+ free_page(p);
+ }
+}
+
+static struct page *free_pt_page(unsigned long pt, struct page *freelist)
+{
+ struct page *p = virt_to_page((void *)pt);
+
+ p->freelist = freelist;
+
+ return p;
+}
+
+#define DEFINE_FREE_PT_FN(LVL, FN)
\
+static struct page *free_pt_##LVL (unsigned long __pt, struct page *freelist)
\
+{
\
+ unsigned long p;
\
+ u64 *pt;
\
+ int i;
\
+
\
+ pt = (u64 *)__pt;
\
+
\
+ for (i = 0; i < 512; ++i) {
\
+ /* PTE present? */
\
+ if (!IOMMU_PTE_PRESENT(pt[i]))
\
+ continue;
\
+
\
+ /* Large PTE? */
\
+ if (PM_PTE_LEVEL(pt[i]) == 0 ||
\
+ PM_PTE_LEVEL(pt[i]) == 7)
\
+ continue;
\
+
\
+ p = (unsigned long)IOMMU_PTE_PAGE(pt[i]);
[PATCH v4 13/13] iommu/amd: Adopt IO page table framework for AMD IOMMU v1 page table
Switch to using IO page table framework for AMD IOMMU v1 page table.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/amd_iommu.h | 1 +
drivers/iommu/amd/init.c | 2 ++
drivers/iommu/amd/iommu.c | 48 ++-
3 files changed, 39 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/amd/amd_iommu.h b/drivers/iommu/amd/amd_iommu.h
index 3770b1a4d51c..91452e0ff072 100644
--- a/drivers/iommu/amd/amd_iommu.h
+++ b/drivers/iommu/amd/amd_iommu.h
@@ -36,6 +36,7 @@ extern void amd_iommu_disable(void);
extern int amd_iommu_reenable(int);
extern int amd_iommu_enable_faulting(void);
extern int amd_iommu_guest_ir;
+extern enum io_pgtable_fmt amd_iommu_pgtable;
/* IOMMUv2 specific functions */
struct iommu_domain;
diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c
index 23a790f8f550..5fb4bea14cc4 100644
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -147,6 +147,8 @@ struct ivmd_header {
bool amd_iommu_dump;
bool amd_iommu_irq_remap __read_mostly;
+enum io_pgtable_fmt amd_iommu_pgtable = AMD_IOMMU_V1;
+
int amd_iommu_guest_ir = AMD_IOMMU_GUEST_IR_VAPIC;
static int amd_iommu_xt_mode = IRQ_REMAP_XAPIC_MODE;
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 1f04b251f0c6..571e8806e4a1 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1901,7 +1902,7 @@ static void protection_domain_free(struct
protection_domain *domain)
kfree(domain);
}
-static int protection_domain_init(struct protection_domain *domain, int mode)
+static int protection_domain_init_v1(struct protection_domain *domain, int
mode)
{
u64 *pt_root = NULL;
@@ -1924,34 +1925,55 @@ static int protection_domain_init(struct
protection_domain *domain, int mode)
return 0;
}
-static struct protection_domain *protection_domain_alloc(int mode)
+static struct protection_domain *protection_domain_alloc(unsigned int type)
{
+ struct io_pgtable_ops *pgtbl_ops;
struct protection_domain *domain;
+ int pgtable = amd_iommu_pgtable;
+ int mode = DEFAULT_PGTABLE_LEVEL;
+ int ret;
domain = kzalloc(sizeof(*domain), GFP_KERNEL);
if (!domain)
return NULL;
- if (protection_domain_init(domain, mode))
+ /*
+* Force IOMMU v1 page table when iommu=pt and
+* when allocating domain for pass-through devices.
+*/
+ if (type == IOMMU_DOMAIN_IDENTITY) {
+ pgtable = AMD_IOMMU_V1;
+ mode = PAGE_MODE_NONE;
+ } else if (type == IOMMU_DOMAIN_UNMANAGED) {
+ pgtable = AMD_IOMMU_V1;
+ }
+
+ switch (pgtable) {
+ case AMD_IOMMU_V1:
+ ret = protection_domain_init_v1(domain, mode);
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ if (ret)
goto out_err;
- return domain;
+ pgtbl_ops = alloc_io_pgtable_ops(pgtable, >iop.pgtbl_cfg,
domain);
+ if (!pgtbl_ops)
+ goto out_err;
+ return domain;
out_err:
kfree(domain);
-
return NULL;
}
static struct iommu_domain *amd_iommu_domain_alloc(unsigned type)
{
struct protection_domain *domain;
- int mode = DEFAULT_PGTABLE_LEVEL;
-
- if (type == IOMMU_DOMAIN_IDENTITY)
- mode = PAGE_MODE_NONE;
- domain = protection_domain_alloc(mode);
+ domain = protection_domain_alloc(type);
if (!domain)
return NULL;
@@ -2070,7 +2092,8 @@ static int amd_iommu_map(struct iommu_domain *dom,
unsigned long iova,
int prot = 0;
int ret = -EINVAL;
- if (domain->iop.mode == PAGE_MODE_NONE)
+ if ((amd_iommu_pgtable == AMD_IOMMU_V1) &&
+ (domain->iop.mode == PAGE_MODE_NONE))
return -EINVAL;
if (iommu_prot & IOMMU_READ)
@@ -2093,7 +2116,8 @@ static size_t amd_iommu_unmap(struct iommu_domain *dom,
unsigned long iova,
struct protection_domain *domain = to_pdomain(dom);
struct io_pgtable_ops *ops = >iop.iop.ops;
- if (domain->iop.mode == PAGE_MODE_NONE)
+ if ((amd_iommu_pgtable == AMD_IOMMU_V1) &&
+ (domain->iop.mode == PAGE_MODE_NONE))
return 0;
return (ops->unmap) ? ops->unmap(ops, iova, page_size, gather) : 0;
--
2.17.1
[PATCH v4 07/13] iommu/amd: Restructure code for freeing page table
By consolidate logic into v1_free_pgtable helper function,
which is called from IO page table framework.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/amd_iommu.h | 1 -
drivers/iommu/amd/io_pgtable.c | 41 --
drivers/iommu/amd/iommu.c | 21 -
3 files changed, 28 insertions(+), 35 deletions(-)
diff --git a/drivers/iommu/amd/amd_iommu.h b/drivers/iommu/amd/amd_iommu.h
index 1bad42a3c73c..91d098003f12 100644
--- a/drivers/iommu/amd/amd_iommu.h
+++ b/drivers/iommu/amd/amd_iommu.h
@@ -132,7 +132,6 @@ static inline void amd_iommu_apply_ivrs_quirks(void) { }
#endif
/* TODO: These are temporary and will be removed once fully transition */
-extern void free_pagetable(struct domain_pgtable *pgtable);
extern int iommu_map_page(struct protection_domain *dom,
unsigned long bus_addr,
unsigned long phys_addr,
diff --git a/drivers/iommu/amd/io_pgtable.c b/drivers/iommu/amd/io_pgtable.c
index 345e9bc81fde..dc674e79ddf0 100644
--- a/drivers/iommu/amd/io_pgtable.c
+++ b/drivers/iommu/amd/io_pgtable.c
@@ -163,23 +163,6 @@ static struct page *free_sub_pt(unsigned long root, int
mode,
return freelist;
}
-void free_pagetable(struct domain_pgtable *pgtable)
-{
- struct page *freelist = NULL;
- unsigned long root;
-
- if (pgtable->mode == PAGE_MODE_NONE)
- return;
-
- BUG_ON(pgtable->mode < PAGE_MODE_NONE ||
- pgtable->mode > PAGE_MODE_6_LEVEL);
-
- root = (unsigned long)pgtable->root;
- freelist = free_sub_pt(root, pgtable->mode, freelist);
-
- free_page_list(freelist);
-}
-
void amd_iommu_domain_set_pgtable(struct protection_domain *domain,
u64 *root, int mode)
{
@@ -528,6 +511,30 @@ unsigned long iommu_unmap_page(struct protection_domain
*dom,
*/
static void v1_free_pgtable(struct io_pgtable *iop)
{
+ struct amd_io_pgtable *pgtable = container_of(iop, struct
amd_io_pgtable, iop);
+ struct protection_domain *dom;
+ struct page *freelist = NULL;
+ unsigned long root;
+
+ if (pgtable->mode == PAGE_MODE_NONE)
+ return;
+
+ dom = container_of(pgtable, struct protection_domain, iop);
+
+ /* Update data structure */
+ amd_iommu_domain_clr_pt_root(dom);
+
+ /* Make changes visible to IOMMUs */
+ amd_iommu_domain_update(dom);
+
+ /* Page-table is not visible to IOMMU anymore, so free it */
+ BUG_ON(pgtable->mode < PAGE_MODE_NONE ||
+ pgtable->mode > PAGE_MODE_6_LEVEL);
+
+ root = (unsigned long)pgtable->root;
+ freelist = free_sub_pt(root, pgtable->mode, freelist);
+
+ free_page_list(freelist);
}
static struct io_pgtable *v1_alloc_pgtable(struct io_pgtable_cfg *cfg, void
*cookie)
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index e823a457..37ecedce2c14 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -1903,17 +1903,14 @@ static void cleanup_domain(struct protection_domain
*domain)
static void protection_domain_free(struct protection_domain *domain)
{
- struct domain_pgtable pgtable;
-
if (!domain)
return;
if (domain->id)
domain_id_free(domain->id);
- amd_iommu_domain_get_pgtable(domain, );
- amd_iommu_domain_clr_pt_root(domain);
- free_pagetable();
+ if (domain->iop.pgtbl_cfg.tlb)
+ free_io_pgtable_ops(>iop.iop.ops);
kfree(domain);
}
@@ -2302,22 +2299,12 @@ EXPORT_SYMBOL(amd_iommu_unregister_ppr_notifier);
void amd_iommu_domain_direct_map(struct iommu_domain *dom)
{
struct protection_domain *domain = to_pdomain(dom);
- struct domain_pgtable pgtable;
unsigned long flags;
spin_lock_irqsave(>lock, flags);
- /* First save pgtable configuration*/
- amd_iommu_domain_get_pgtable(domain, );
-
- /* Remove page-table from domain */
- amd_iommu_domain_clr_pt_root(domain);
-
- /* Make changes visible to IOMMUs */
- amd_iommu_domain_update(domain);
-
- /* Page-table is not visible to IOMMU anymore, so free it */
- free_pagetable();
+ if (domain->iop.pgtbl_cfg.tlb)
+ free_io_pgtable_ops(>iop.iop.ops);
spin_unlock_irqrestore(>lock, flags);
}
--
2.17.1
[PATCH v4 03/13] iommu/amd: Move pt_root to struct amd_io_pgtable
To better organize the data structure since it contains IO page table
related information.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/amd_iommu.h | 2 +-
drivers/iommu/amd/amd_iommu_types.h | 2 +-
drivers/iommu/amd/iommu.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/amd/amd_iommu.h b/drivers/iommu/amd/amd_iommu.h
index 0817bc732d1a..b8dae3941f0f 100644
--- a/drivers/iommu/amd/amd_iommu.h
+++ b/drivers/iommu/amd/amd_iommu.h
@@ -105,7 +105,7 @@ static inline void *iommu_phys_to_virt(unsigned long paddr)
static inline
void amd_iommu_domain_set_pt_root(struct protection_domain *domain, u64 root)
{
- atomic64_set(>pt_root, root);
+ atomic64_set(>iop.pt_root, root);
}
static inline
diff --git a/drivers/iommu/amd/amd_iommu_types.h
b/drivers/iommu/amd/amd_iommu_types.h
index 5d77f34e0fda..7c971c76d685 100644
--- a/drivers/iommu/amd/amd_iommu_types.h
+++ b/drivers/iommu/amd/amd_iommu_types.h
@@ -497,6 +497,7 @@ struct amd_io_pgtable {
struct io_pgtable iop;
int mode;
u64 *root;
+ atomic64_t pt_root;/* pgtable root and pgtable mode */
};
/*
@@ -510,7 +511,6 @@ struct protection_domain {
struct amd_io_pgtable iop;
spinlock_t lock;/* mostly used to lock the page table*/
u16 id; /* the domain id written to the device table */
- atomic64_t pt_root; /* pgtable root and pgtable mode */
int glx;/* Number of levels for GCR3 table */
u64 *gcr3_tbl; /* Guest CR3 table */
unsigned long flags;/* flags to find out type of domain */
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index 45d3977d6c00..5b93536d6877 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -145,7 +145,7 @@ static struct protection_domain *to_pdomain(struct
iommu_domain *dom)
static void amd_iommu_domain_get_pgtable(struct protection_domain *domain,
struct domain_pgtable *pgtable)
{
- u64 pt_root = atomic64_read(>pt_root);
+ u64 pt_root = atomic64_read(>iop.pt_root);
pgtable->root = (u64 *)(pt_root & PAGE_MASK);
pgtable->mode = pt_root & 7; /* lowest 3 bits encode pgtable mode */
--
2.17.1
[PATCH v4 05/13] iommu/amd: Declare functions as extern
And move declaration to header file so that they can be included across
multiple files. There is no functional change.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/amd_iommu.h | 3 +++
drivers/iommu/amd/iommu.c | 39 +--
2 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/drivers/iommu/amd/amd_iommu.h b/drivers/iommu/amd/amd_iommu.h
index bf9723b35e77..bf29ab8c99f0 100644
--- a/drivers/iommu/amd/amd_iommu.h
+++ b/drivers/iommu/amd/amd_iommu.h
@@ -57,6 +57,9 @@ extern int amd_iommu_domain_enable_v2(struct iommu_domain
*dom, int pasids);
extern int amd_iommu_flush_page(struct iommu_domain *dom, u32 pasid,
u64 address);
extern void amd_iommu_update_and_flush_device_table(struct protection_domain
*domain);
+extern void amd_iommu_domain_update(struct protection_domain *domain);
+extern void amd_iommu_domain_flush_complete(struct protection_domain *domain);
+extern void amd_iommu_domain_flush_tlb_pde(struct protection_domain *domain);
extern int amd_iommu_flush_tlb(struct iommu_domain *dom, u32 pasid);
extern int amd_iommu_domain_set_gcr3(struct iommu_domain *dom, u32 pasid,
unsigned long cr3);
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index fdb6030b505d..1b10710c91cf 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -87,7 +87,6 @@ struct iommu_cmd {
struct kmem_cache *amd_iommu_irq_cache;
-static void update_domain(struct protection_domain *domain);
static void detach_device(struct device *dev);
/
@@ -1314,12 +1313,12 @@ static void domain_flush_pages(struct protection_domain
*domain,
}
/* Flush the whole IO/TLB for a given protection domain - including PDE */
-static void domain_flush_tlb_pde(struct protection_domain *domain)
+void amd_iommu_domain_flush_tlb_pde(struct protection_domain *domain)
{
__domain_flush_pages(domain, 0, CMD_INV_IOMMU_ALL_PAGES_ADDRESS, 1);
}
-static void domain_flush_complete(struct protection_domain *domain)
+void amd_iommu_domain_flush_complete(struct protection_domain *domain)
{
int i;
@@ -1344,7 +1343,7 @@ static void domain_flush_np_cache(struct
protection_domain *domain,
spin_lock_irqsave(>lock, flags);
domain_flush_pages(domain, iova, size);
- domain_flush_complete(domain);
+ amd_iommu_domain_flush_complete(domain);
spin_unlock_irqrestore(>lock, flags);
}
}
@@ -1501,7 +1500,7 @@ static bool increase_address_space(struct
protection_domain *domain,
pgtable.root = pte;
pgtable.mode += 1;
amd_iommu_update_and_flush_device_table(domain);
- domain_flush_complete(domain);
+ amd_iommu_domain_flush_complete(domain);
/*
* Device Table needs to be updated and flushed before the new root can
@@ -1754,8 +1753,8 @@ static int iommu_map_page(struct protection_domain *dom,
* Updates and flushing already happened in
* increase_address_space().
*/
- domain_flush_tlb_pde(dom);
- domain_flush_complete(dom);
+ amd_iommu_domain_flush_tlb_pde(dom);
+ amd_iommu_domain_flush_complete(dom);
spin_unlock_irqrestore(>lock, flags);
}
@@ -1998,10 +1997,10 @@ static void do_detach(struct iommu_dev_data *dev_data)
device_flush_dte(dev_data);
/* Flush IOTLB */
- domain_flush_tlb_pde(domain);
+ amd_iommu_domain_flush_tlb_pde(domain);
/* Wait for the flushes to finish */
- domain_flush_complete(domain);
+ amd_iommu_domain_flush_complete(domain);
/* decrease reference counters - needs to happen after the flushes */
domain->dev_iommu[iommu->index] -= 1;
@@ -2134,9 +2133,9 @@ static int attach_device(struct device *dev,
* left the caches in the IOMMU dirty. So we have to flush
* here to evict all dirty stuff.
*/
- domain_flush_tlb_pde(domain);
+ amd_iommu_domain_flush_tlb_pde(domain);
- domain_flush_complete(domain);
+ amd_iommu_domain_flush_complete(domain);
out:
spin_unlock(_data->lock);
@@ -2298,7 +2297,7 @@ void amd_iommu_update_and_flush_device_table(struct
protection_domain *domain)
domain_flush_devices(domain);
}
-static void update_domain(struct protection_domain *domain)
+void amd_iommu_domain_update(struct protection_domain *domain)
{
struct domain_pgtable pgtable;
@@ -2307,8 +2306,8 @@ static void update_domain(struct protection_domain
*domain)
amd_iommu_update_and_flush_device_table(domain);
/* Flush domain TLB(s) and wait for completion */
- domain_flush_tlb_pde(domain);
- domain_flush_complete(domain);
+
[PATCH v4 09/13] iommu/amd: Rename variables to be consistent with struct io_pgtable_ops
There is no functional change.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/io_pgtable.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/drivers/iommu/amd/io_pgtable.c b/drivers/iommu/amd/io_pgtable.c
index d4d131e43dcd..35dd9153e6b7 100644
--- a/drivers/iommu/amd/io_pgtable.c
+++ b/drivers/iommu/amd/io_pgtable.c
@@ -393,9 +393,9 @@ static struct page *free_clear_pte(u64 *pte, u64 pteval,
struct page *freelist)
* and full 64 bit address spaces.
*/
int iommu_map_page(struct protection_domain *dom,
- unsigned long bus_addr,
- unsigned long phys_addr,
- unsigned long page_size,
+ unsigned long iova,
+ unsigned long paddr,
+ unsigned long size,
int prot,
gfp_t gfp)
{
@@ -404,15 +404,15 @@ int iommu_map_page(struct protection_domain *dom,
u64 __pte, *pte;
int ret, i, count;
- BUG_ON(!IS_ALIGNED(bus_addr, page_size));
- BUG_ON(!IS_ALIGNED(phys_addr, page_size));
+ BUG_ON(!IS_ALIGNED(iova, size));
+ BUG_ON(!IS_ALIGNED(paddr, size));
ret = -EINVAL;
if (!(prot & IOMMU_PROT_MASK))
goto out;
- count = PAGE_SIZE_PTE_COUNT(page_size);
- pte = alloc_pte(dom, bus_addr, page_size, NULL, gfp, );
+ count = PAGE_SIZE_PTE_COUNT(size);
+ pte = alloc_pte(dom, iova, size, NULL, gfp, );
ret = -ENOMEM;
if (!pte)
@@ -425,10 +425,10 @@ int iommu_map_page(struct protection_domain *dom,
updated = true;
if (count > 1) {
- __pte = PAGE_SIZE_PTE(__sme_set(phys_addr), page_size);
+ __pte = PAGE_SIZE_PTE(__sme_set(paddr), size);
__pte |= PM_LEVEL_ENC(7) | IOMMU_PTE_PR | IOMMU_PTE_FC;
} else
- __pte = __sme_set(phys_addr) | IOMMU_PTE_PR | IOMMU_PTE_FC;
+ __pte = __sme_set(paddr) | IOMMU_PTE_PR | IOMMU_PTE_FC;
if (prot & IOMMU_PROT_IR)
__pte |= IOMMU_PTE_IR;
@@ -462,20 +462,19 @@ int iommu_map_page(struct protection_domain *dom,
}
unsigned long iommu_unmap_page(struct protection_domain *dom,
- unsigned long bus_addr,
- unsigned long page_size)
+ unsigned long iova,
+ unsigned long size)
{
unsigned long long unmapped;
unsigned long unmap_size;
u64 *pte;
- BUG_ON(!is_power_of_2(page_size));
+ BUG_ON(!is_power_of_2(size));
unmapped = 0;
- while (unmapped < page_size) {
-
- pte = fetch_pte(dom, bus_addr, _size);
+ while (unmapped < size) {
+ pte = fetch_pte(dom, iova, _size);
if (pte) {
int i, count;
@@ -485,7 +484,7 @@ unsigned long iommu_unmap_page(struct protection_domain
*dom,
pte[i] = 0ULL;
}
- bus_addr = (bus_addr & ~(unmap_size - 1)) + unmap_size;
+ iova = (iova & ~(unmap_size - 1)) + unmap_size;
unmapped += unmap_size;
}
--
2.17.1
[PATCH v4 01/13] iommu/amd: Re-define amd_iommu_domain_encode_pgtable as inline
Move the function to header file to allow inclusion in other files.
Signed-off-by: Suravee Suthikulpanit
---
drivers/iommu/amd/amd_iommu.h | 13 +
drivers/iommu/amd/iommu.c | 10 --
2 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/amd/amd_iommu.h b/drivers/iommu/amd/amd_iommu.h
index 6b8cbdf71714..0817bc732d1a 100644
--- a/drivers/iommu/amd/amd_iommu.h
+++ b/drivers/iommu/amd/amd_iommu.h
@@ -102,6 +102,19 @@ static inline void *iommu_phys_to_virt(unsigned long paddr)
return phys_to_virt(__sme_clr(paddr));
}
+static inline
+void amd_iommu_domain_set_pt_root(struct protection_domain *domain, u64 root)
+{
+ atomic64_set(>pt_root, root);
+}
+
+static inline
+void amd_iommu_domain_clr_pt_root(struct protection_domain *domain)
+{
+ amd_iommu_domain_set_pt_root(domain, 0);
+}
+
+
extern bool translation_pre_enabled(struct amd_iommu *iommu);
extern bool amd_iommu_is_attach_deferred(struct iommu_domain *domain,
struct device *dev);
diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index b9cf59443843..7f6b0f60b958 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -161,16 +161,6 @@ static void amd_iommu_domain_get_pgtable(struct
protection_domain *domain,
pgtable->mode = pt_root & 7; /* lowest 3 bits encode pgtable mode */
}
-static void amd_iommu_domain_set_pt_root(struct protection_domain *domain, u64
root)
-{
- atomic64_set(>pt_root, root);
-}
-
-static void amd_iommu_domain_clr_pt_root(struct protection_domain *domain)
-{
- amd_iommu_domain_set_pt_root(domain, 0);
-}
-
static void amd_iommu_domain_set_pgtable(struct protection_domain *domain,
u64 *root, int mode)
{
--
2.17.1
[PATCH v4 00/13] iommu/amd: Add Generic IO Page Table Framework Support
The framework allows callable implementation of IO page table. This allows AMD IOMMU driver to switch between different types of AMD IOMMU page tables (e.g. v1 vs. v2). This series refactors the current implementation of AMD IOMMU v1 page table to adopt the framework. There should be no functional change. Subsequent series will introduce support for the AMD IOMMU v2 page table. Thanks, Suravee Change from V3 (https://lore.kernel.org/linux-iommu/20201004014549.16065-1-suravee.suthikulpa...@amd.com/) - Rebase to v5.10 - Patch 2: Add struct iommu_flush_ops (previously in patch 13 of v3) - Patch 7: Consolidate logic into v1_free_pgtable() instead of amd_iommu_free_pgtable() - Patch 12: Check ops->[map|unmap] before calling. - Patch 13: Setup page table when allocating domain (instead of when attaching device). Change from V2 (https://lore.kernel.org/lkml/835c0d46-ed96-9fbe-856a-777dcffac...@amd.com/T/#t) - Patch 2: Introduce helper function io_pgtable_cfg_to_data. - Patch 13: Put back the struct iommu_flush_ops since patch v2 would run into NULL pointer bug when calling free_io_pgtable_ops if not defined. Change from V1 (https://lkml.org/lkml/2020/9/23/251) - Do not specify struct io_pgtable_cfg.coherent_walk, since it is not currently used. (per Robin) - Remove unused struct iommu_flush_ops. (patch 2/13) - Move amd_iommu_setup_io_pgtable_ops to iommu.c instead of io_pgtable.c patch 13/13) Suravee Suthikulpanit (13): iommu/amd: Re-define amd_iommu_domain_encode_pgtable as inline iommu/amd: Prepare for generic IO page table framework iommu/amd: Move pt_root to struct amd_io_pgtable iommu/amd: Convert to using amd_io_pgtable iommu/amd: Declare functions as extern iommu/amd: Move IO page table related functions iommu/amd: Restructure code for freeing page table iommu/amd: Remove amd_iommu_domain_get_pgtable iommu/amd: Rename variables to be consistent with struct io_pgtable_ops iommu/amd: Refactor fetch_pte to use struct amd_io_pgtable iommu/amd: Introduce iommu_v1_iova_to_phys iommu/amd: Introduce iommu_v1_map_page and iommu_v1_unmap_page iommu/amd: Adopt IO page table framework for AMD IOMMU v1 page table drivers/iommu/amd/Kconfig | 1 + drivers/iommu/amd/Makefile | 2 +- drivers/iommu/amd/amd_iommu.h | 22 + drivers/iommu/amd/amd_iommu_types.h | 43 +- drivers/iommu/amd/init.c| 2 + drivers/iommu/amd/io_pgtable.c | 564 +++ drivers/iommu/amd/iommu.c | 672 drivers/iommu/io-pgtable.c | 3 + include/linux/io-pgtable.h | 2 + 9 files changed, 707 insertions(+), 604 deletions(-) create mode 100644 drivers/iommu/amd/io_pgtable.c -- 2.17.1
Re: [PATCH -next v2] net/mlx5_core: remove unused including
On Wed, 2020-12-09 at 15:01 +0800, Zou Wei wrote:
> Remove including that don't need it.
>
> Fixes: 17a7612b99e6 ("net/mlx5_core: Clean driver version and name")
> Signed-off-by: Zou Wei
> ---
Applied to net-next-mlx5.
Thanks!
Re: xen/evtchn: Interrupt for port 34, but apparently not enabled; per-user 00000000a86a4c1b on 5.10
On 14.12.20 22:25, Julien Grall wrote: Hi Juergen, When testing Linux 5.10 dom0, I could reliably hit the following warning with using event 2L ABI: [ 589.591737] Interrupt for port 34, but apparently not enabled; per-user a86a4c1b [ 589.593259] WARNING: CPU: 0 PID: at /home/ANT.AMAZON.COM/jgrall/works/oss/linux/drivers/xen/evtchn.c:170 evtchn_interrupt+0xeb/0x100 [ 589.595514] Modules linked in: [ 589.596145] CPU: 0 PID: Comm: qemu-system-i38 Tainted: G W 5.10.0+ #180 [ 589.597708] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [ 589.599782] RIP: e030:evtchn_interrupt+0xeb/0x100 [ 589.600698] Code: 48 8d bb d8 01 00 00 ba 01 00 00 00 be 1d 00 00 00 e8 d9 10 ca ff eb b2 8b 75 20 48 89 da 48 c7 c7 a8 31 3d 82 e8 65 29 a0 ff <0f> 0b e9 42 ff ff ff 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f [ 589.604087] RSP: e02b:c90040003e70 EFLAGS: 00010086 [ 589.605102] RAX: RBX: 888102091800 RCX: 0027 [ 589.606445] RDX: RSI: 88817fe19150 RDI: 88817fe19158 [ 589.607790] RBP: 88810f5ab980 R08: 0001 R09: 00328980 [ 589.609134] R10: R11: c90040003c70 R12: 888107fd3c00 [ 589.610484] R13: c90040003ed4 R14: R15: 88810f5ffd80 [ 589.611828] FS: 7f960c4b8ac0() GS:88817fe0() knlGS: [ 589.613348] CS: 1e030 DS: ES: CR0: 80050033 [ 589.614525] CR2: 7f17ee72e000 CR3: 00010f5b6000 CR4: 00050660 [ 589.615874] Call Trace: [ 589.616402] [ 589.616855] __handle_irq_event_percpu+0x4e/0x2c0 [ 589.617784] handle_irq_event_percpu+0x30/0x80 [ 589.618660] handle_irq_event+0x3a/0x60 [ 589.619428] handle_edge_irq+0x9b/0x1f0 [ 589.620209] generic_handle_irq+0x4f/0x60 [ 589.621008] evtchn_2l_handle_events+0x160/0x280 [ 589.621913] __xen_evtchn_do_upcall+0x66/0xb0 [ 589.622767] __xen_pv_evtchn_do_upcall+0x11/0x20 [ 589.623665] asm_call_irq_on_stack+0x12/0x20 [ 589.624511] [ 589.624978] xen_pv_evtchn_do_upcall+0x77/0xf0 [ 589.625848] exc_xen_hypervisor_callback+0x8/0x10 This can be reproduced when creating/destroying guest in a loop. Although, I have struggled to reproduce it on a vanilla Xen. After several hours of debugging, I think I have found the root cause. While we only expect the unmask to happen when the event channel is EOIed, there is an unmask happening as part of handle_edge_irq() because the interrupt was seen as pending by another vCPU (IRQS_PENDING is set). It turns out that the event channel is set for multiple vCPU is in cpu_evtchn_mask. This is happening because the affinity is not cleared when freeing an event channel. The implementation of evtchn_2l_handle_events() will look for all the active interrupts for the current vCPU and later on clear the pending bit (via the ack() callback). IOW, I believe, this is not an atomic operation. Even if Xen will notify the event to a single vCPU, evtchn_pending_sel may still be set on the other vCPU (thanks to a different event channel). Therefore, there is a chance that two vCPUs will try to handle the same interrupt. The IRQ handler handle_edge_irq() is able to deal with that and will mask/unmask the interrupt. This will mess us with the lateeoi logic (although, I managed to reproduce it once without XSA-332). Thanks for the analysis! My initial idea to fix the problem was to switch the affinity from CPU X to CPU0 when the event channel is freed. However, I am not sure this is enough because I haven't found anything yet preventing a race between evtchn_2l_handle_events9) and evtchn_2l_bind_vcpu(). So maybe we want to introduce a refcounting (if there is nothing provided by the IRQ framework) and only unmask when the counter drop to 0. Any opinions? I think we don't need a refcount, but just the internal states "masked" and "eoi_pending" and unmask only if both are false. "masked" will be set when the event is being masked. When delivering a lateeoi irq "eoi_pending" will be set and "masked "reset. "masked" will be reset when a normal unmask is happening. And "eoi_pending" will be reset when a lateeoi is signaled. Any reset of "masked" and "eoi_pending" will check the other flag and do an unmask if both are false. I'll write a patch. Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH net-next] net/mlx5: simplify the return expression of mlx5_esw_offloads_pair()
On Tue, 2020-12-08 at 16:25 -0800, David Miller wrote: > From: Zheng Yongjun > Date: Tue, 8 Dec 2020 21:56:25 +0800 > > > Simplify the return expression. > > > > Signed-off-by: Zheng Yongjun > > Applied. > Hey Dave, it's great to have you back! I still don't see this patch in net-next, i will take it to my tree and submit it in my next pr. Thanks, Saeed.
[rcu:dev.2020.12.13a] BUILD SUCCESS 42cc5a26ab93636323fea8cfadb28dec6fcc38b8
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2020.12.13a branch HEAD: 42cc5a26ab93636323fea8cfadb28dec6fcc38b8 squash! torture: Compress KASAN vmlinux files elapsed time: 723m configs tested: 144 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig m68km5307c3_defconfig ia64 tiger_defconfig armu300_defconfig powerpc ppc44x_defconfig arc axs101_defconfig sh se7206_defconfig arm zx_defconfig powerpc arches_defconfig arc alldefconfig powerpc kmeter1_defconfig i386 alldefconfig arm cns3420vb_defconfig archsdk_defconfig m68k sun3x_defconfig powerpc acadia_defconfig arm pxa168_defconfig arm omap2plus_defconfig m68k alldefconfig arm socfpga_defconfig sparc64 defconfig arm footbridge_defconfig sh rsk7264_defconfig powerpc obs600_defconfig mips cu1000-neo_defconfig cskydefconfig sh rts7751r2dplus_defconfig powerpc ps3_defconfig shecovec24-romimage_defconfig sh sh7770_generic_defconfig mipsnlm_xlp_defconfig mips loongson1b_defconfig sh sh03_defconfig x86_64 alldefconfig arm pxa255-idp_defconfig xtensa virt_defconfig shedosk7760_defconfig mips capcella_defconfig sh lboxre2_defconfig sh se7722_defconfig armspear6xx_defconfig mipsnlm_xlr_defconfig mipsgpr_defconfig mips lemote2f_defconfig arcnsimosci_defconfig sh sdk7780_defconfig powerpc g5_defconfig powerpc currituck_defconfig arm sunxi_defconfig sh ap325rxa_defconfig sh microdev_defconfig powerpc64alldefconfig mips decstation_r4k_defconfig mips rt305x_defconfig mips cavium_octeon_defconfig sh sh7724_generic_defconfig sh apsh4a3a_defconfig h8300 defconfig sh se7619_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a001-20201214 i386 randconfig-a004-20201214 i386 randconfig-a003-20201214 i386 randconfig-a002-20201214 i386 randconfig-a006-20201214 i386
[PATCH v5] Serial: silabs si4455 serial driver
This is a serial port driver for
Silicon Labs Si4455 Sub-GHz transciver.
The goal of this driver is to removing wires
between central(linux) device and remote serial devices/sensors,
but keeping the original user software.
It represents regular serial interface for the user space.
Datasheet: https://www.silabs.com/documents/public/data-sheets/Si4455.pdf
changes v1:
- fixed: drivers: serial: si4455: coding style
- fixed: drivers: serial: si4455: error checking and order
- fixed: drivers: serial: si4455: remove unnecessary compatibility
strings from si4455_dt_ids
- fixed: dt-bindings: rename sdn-gpios to shutdown-gpios
changes v2:
- fixed: drivers: serial: si4455: coding style
changes v3:
- fixed: drivers: serial: si4455: coding style
- fixed: drivers: serial: si4455: replace device configuration procedure
(SI4455_IOC_SEZC ioctl call) with request_firmware(...).
The firmware name comes from dt (silabs,ez-config)
- fixed: drivers: serial: si4455: replace transmit/receive channel
select (SI4455_IOC_STXC/SI4455_IOC_SRXC ioctl calls)
with sysfs entries (tx_channel, rx_channel).
Initial values comes from dt (silabs,tx-channel and silabs,rx-channel)
- fixed: drivers: serial: si4455: replace package size setting
(SI4455_IOC_SSIZ ioctl call) with sysfs entry (package_size).
Initial value comes from dt (silabs,package-size)
- fixed: drivers: serial: si4455: replace getting last rssi
(SI4455_IOC_GRSSI ioctl call) with sysfs entry (current_rssi)
- fixed: drivers: serial: si4455: remove si4455_api.h
and custom ioctl definitions
- fixed: dt-bindings: silabs,si4455: more detailed description
- added: dt-bindings: silabs,si4455: properties silabs,package-size,
silabs,tx-channel, silabs,rx-channel, silabs,ez-config
changes v4:
- fixed: dt-bindings: silabs,si4455: $id
from http://devicetree.org/schemas/serial/silabs,si4455.yaml
to http://devicetree.org/schemas/staging/serial/silabs,si4455.yaml
changes v5:
- fixed: drivers: serial: si4455: coding style
- fixed: drivers: serial: si4455: remove struct si4455_one,
members moved to struct si4455_port
- fixed: drivers: serial: si4455: fix line endings in dev_err and
dev_dbg messages
- fixed: drivers: serial: si4455: remove unnecessary else { ... }
- fixed: drivers: serial: si4455: refactor si4455_do_work(...),
xmit circular buffer handling and start tx moved to
si4455_start_tx_xmit(...)
- fixed: drivers: serial: si4455: refactor si4455_configure
- fixed: drivers: serial: si4455: refactor interrupt handling,
remove unnecessary wrapper
- fixed: drivers: serial: si4455: modem line(si4455_get_mctrl)
and tx buffer status(si4455_tx_empty) conditions and signaling
- fixed: drivers: serial: si4455: remove unsafe int to pointer conversion
- fixed: dt-bindings: silabs,si4455: $id
from http://devicetree.org/schemas/staging/serial/silabs,si4455.yaml
to http://devicetree.org/schemas/serial/silabs,si4455.yaml
- fixed: dt-bindings: silabs,si4455: serial.yaml reference added
Signed-off-by: József Horváth
---
.../bindings/serial/silabs,si4455.yaml| 98 ++
MAINTAINERS |6 +
drivers/tty/serial/Kconfig|8 +
drivers/tty/serial/Makefile |1 +
drivers/tty/serial/si4455.c | 1372 +
5 files changed, 1485 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/silabs,si4455.yaml
create mode 100644 drivers/tty/serial/si4455.c
diff --git a/Documentation/devicetree/bindings/serial/silabs,si4455.yaml
b/Documentation/devicetree/bindings/serial/silabs,si4455.yaml
new file mode 100644
index ..ddff67e6a667
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/silabs,si4455.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/serial/silabs,si4455.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Silicon Labs Si4455 device tree bindings
+
+maintainers:
+ - József Horváth
+
+description:
+ This document is for describing the required device tree parameters for
si4455 serial driver.
+ The si4455 driver tries to represent the Silicon Labs Si4455 sub-GHz
transceiver device
+ like a serial port. The required parameters for proper operation are
described below.
+ https://www.silabs.com/documents/public/data-sheets/Si4455.pdf
+
+allOf:
+ - $ref: "serial.yaml#"
+
+properties:
+ compatible:
+const: silabs,si4455
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ spi-max-frequency:
+description: maximum clock frequency on SPI port
+maximum: 50
+
+ shutdown-gpios:
+description: gpio pin for SDN
+maxItems: 1
+
+ silabs,package-size:
+description:
+ Radio payload length, variable packet length is not supported by driver.
+ This value should equal with EZConfig payload length.
+$ref:
Re: [PATCH 2/2] mm: rename memmap_init() and memmap_init_zone()
On 12/14/20 at 11:00am, David Hildenbrand wrote:
> On 13.12.20 16:09, Baoquan He wrote:
> > The current memmap_init_zone() only handles memory region inside one zone.
> > Actually memmap_init() does the memmap init of one zone. So rename both of
> > them accordingly.
> >
> > And also rename the function parameter 'range_start_pfn' and local variable
> > 'range_end_pfn' to zone_start_pfn/zone_end_pfn.
> >
> > Signed-off-by: Baoquan He
> > ---
> > arch/ia64/mm/init.c | 6 +++---
> > include/linux/mm.h | 2 +-
> > mm/memory_hotplug.c | 2 +-
> > mm/page_alloc.c | 16
> > 4 files changed, 13 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
> > index 27ca549ff47e..af678197ac2d 100644
> > --- a/arch/ia64/mm/init.c
> > +++ b/arch/ia64/mm/init.c
> > @@ -535,18 +535,18 @@ virtual_memmap_init(u64 start, u64 end, void *arg)
> > / sizeof(struct page));
> >
> > if (map_start < map_end)
> > - memmap_init_zone((unsigned long)(map_end - map_start),
> > + memmap_init_range((unsigned long)(map_end - map_start),
> > args->nid, args->zone, page_to_pfn(map_start),
> > page_to_pfn(map_end),
> > MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
> > return 0;
> > }
> >
> > void __meminit
> > -memmap_init (unsigned long size, int nid, unsigned long zone,
> > +memmap_init_zone (unsigned long size, int nid, unsigned long zone,
> > unsigned long start_pfn)
>
> While at it s/zone /zone/ please. :)
Yeah, when I git grep 'memmap_init(', I didn't searched the one in ia64,
didn't adjust it since I saw so many functions got a space between
name and parenthesis in arch/ia64/mm/. I will clean up this one anyway.
>
> > {
> > if (!vmem_map) {
> > - memmap_init_zone(size, nid, zone, start_pfn, start_pfn + size,
> > + memmap_init_range(size, nid, zone, start_pfn, start_pfn + size,
> > MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
> > } else {
> > struct page *start;
...
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 315c22974f0d..fac599deba56 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -6050,7 +6050,7 @@ overlap_memmap_init(unsigned long zone, unsigned long
> > *pfn)
> > * (usually MIGRATE_MOVABLE). Besides setting the migratetype, no related
> > * zone stats (e.g., nr_isolate_pageblock) are touched.
> > */
> > -void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long
> > zone,
> > +void __meminit memmap_init_range(unsigned long size, int nid, unsigned
> > long zone,
> > unsigned long start_pfn, unsigned long zone_end_pfn,
> > enum meminit_context context,
> > struct vmem_altmap *altmap, int migratetype)
> > @@ -6187,21 +6187,21 @@ static void __meminit zone_init_free_lists(struct
> > zone *zone)
> > }
> > }
> >
> > -void __meminit __weak memmap_init(unsigned long size, int nid,
> > +void __meminit __weak memmap_init_zone(unsigned long size, int nid,
> > unsigned long zone,
> > - unsigned long range_start_pfn)
> > + unsigned long zone_start_pfn)
>
> Why are we not simply passing "struct zone" like
>
> void __meminit __weak memmap_init_zone(struct zone *zone)
>
> from which we can derive
> - nid
> - zone idx
> - zone_start_pfn
> - spanned_pages / zone_end_pfn
>
> At least when called from free_area_init_core() this should work just
> fine I think.
Yes, passing 'struct zone *zone' looks much better, I will append a patch to
do this. Thanks.
>
>
>
> > {
> > unsigned long start_pfn, end_pfn;
> > - unsigned long range_end_pfn = range_start_pfn + size;
> > + unsigned long zone_end_pfn = zone_start_pfn + size;
> > int i;
> >
> > for_each_mem_pfn_range(i, nid, _pfn, _pfn, NULL) {
> > - start_pfn = clamp(start_pfn, range_start_pfn, range_end_pfn);
> > - end_pfn = clamp(end_pfn, range_start_pfn, range_end_pfn);
> > + start_pfn = clamp(start_pfn, zone_start_pfn, zone_end_pfn);
> > + end_pfn = clamp(end_pfn, zone_start_pfn, zone_end_pfn);
> >
> > if (end_pfn > start_pfn) {
> > size = end_pfn - start_pfn;
> > - memmap_init_zone(size, nid, zone, start_pfn,
> > range_end_pfn,
> > + memmap_init_range(size, nid, zone, start_pfn,
> > zone_end_pfn,
> > MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
> > }
> > }
> > @@ -6903,7 +6903,7 @@ static void __init free_area_init_core(struct
> > pglist_data *pgdat)
> > set_pageblock_order();
> > setup_usemap(pgdat, zone, zone_start_pfn, size);
> > init_currently_empty_zone(zone, zone_start_pfn, size);
> > - memmap_init(size, nid, j, zone_start_pfn);
> > +
Re: [PATCH v4 1/2] dt-bindings: pci: Retrain Link to work around Gen2 training defect.
Hi, On 14/12/20 8:35 pm, Rob Herring wrote: > On Sun, Dec 13, 2020 at 10:21 PM Kishon Vijay Abraham I wrote: >> >> Hi Nadeem, >> >> On 12/12/20 12:37 pm, Athani Nadeem Ladkhan wrote: >>> Hi Rob / Kishon, >>> -Original Message- From: Rob Herring Sent: Friday, December 11, 2020 10:32 PM To: Athani Nadeem Ladkhan Cc: Tom Joseph ; Lorenzo Pieralisi ; Bjorn Helgaas ; PCI ; linux-kernel@vger.kernel.org; Kishon Vijay Abraham I ; devicet...@vger.kernel.org; Milind Parab ; Swapnil Kashinath Jakhade ; Parshuram Raju Thombare Subject: Re: [PATCH v4 1/2] dt-bindings: pci: Retrain Link to work around Gen2 training defect. EXTERNAL MAIL On Fri, Dec 11, 2020 at 9:03 AM Nadeem Athani wrote: > > Cadence controller will not initiate autonomous speed change if > strapped as Gen2. The Retrain Link bit is set as quirk to enable this > speed change. > Adding a quirk flag based on a new compatible string. > > Signed-off-by: Nadeem Athani > --- > Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml | 4 > +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml > b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml > index 293b8ec318bc..204d78f9efe3 100644 > --- a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml > +++ b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.yaml > @@ -15,7 +15,9 @@ allOf: > > properties: >compatible: > -const: cdns,cdns-pcie-host > +enum: > +- cdns,cdns-pcie-host > +- cdns,cdns-pcie-host-quirk-retrain So, we'll just keep adding quirk strings on to the compatible? I don't think so. Compatible strings should map to a specific implementation/platform and quirks can then be implied from them. This is the only way we can implement quirks in the OS without firmware (DT) changes. >>> Ok, I will change the compatible string to " ti,j721e-pcie-host" in place >>> of " cdns,cdns-pcie-host-quirk-retrain" . >>> @Kishon Vijay Abraham I: Is this fine? Or will you suggest an appropriate >>> name? >> >> IMHO it should be something like "cdns,cdns-pcie-host-vX", since the >> quirk itself is not specific to TI platform rather Cadence IP version. > > That's fine if Cadence has a need for it, but for TI platforms use the > TI compatible string. ECOs on version X IP without changing X is not > uncommon. Okay. I re-worked the patch to be applicable only to TI's J721E SoC http://lore.kernel.org/r/20201215070009.27937-1-kis...@ti.com Thank You, Kishon
[PATCH v2] x86/mtrr: Correct the returned MTRR type of mtrr_type_lookup.
In mtrr_type_lookup, if the input memory address region is not in the
MTRR, over 4GB, and not over the top of memory, write-back attribute
is returned. These condition checks are for ensuring the input memory
address region is mapped to the physical memory actually.
However, if the end address is just aligned with the top of memory,
the condition check treats the address is over the top of memory, and
write-back attribute is not returned.
There is a real case of NVDIMM. The nd_pmem module tries to map
NVDIMMs as cacheable memories when NVDIMMs are connected. If a NVDIMM
is the last of the DIMMs, the performance of this NVDIMM becomes very
low since it aligned with the top of memory and its memory type is
uncached-minus.
The input end address should be changed to inclusive to be checked
for the top of memory.
Fixes: 0cc705f56e40 ("x86/mm/mtrr: Clean up mtrr_type_lookup()")
Signed-off-by: Ying-Tsun Huang
---
arch/x86/kernel/cpu/mtrr/generic.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/generic.c
b/arch/x86/kernel/cpu/mtrr/generic.c
index 23ad8e953dfb..a29997e6cf9e 100644
--- a/arch/x86/kernel/cpu/mtrr/generic.c
+++ b/arch/x86/kernel/cpu/mtrr/generic.c
@@ -167,9 +167,6 @@ static u8 mtrr_type_lookup_variable(u64 start, u64 end, u64
*partial_end,
*repeat = 0;
*uniform = 1;
- /* Make end inclusive instead of exclusive */
- end--;
-
prev_match = MTRR_TYPE_INVALID;
for (i = 0; i < num_var_ranges; ++i) {
unsigned short start_state, end_state, inclusive;
@@ -261,6 +258,9 @@ u8 mtrr_type_lookup(u64 start, u64 end, u8 *uniform)
int repeat;
u64 partial_end;
+ /* Make end inclusive instead of exclusive */
+ end--;
+
if (!mtrr_state_set)
return MTRR_TYPE_INVALID;
--
2.25.1
Re: [PATCH] [v2] tty: Protect disc_data in n_tty_close and n_tty_flush_buffer
A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Tue, Dec 15, 2020 at 02:45:01AM +, Tianxianting wrote: > Hi Greg KH > Could we get your comments for the updates? Thanks Sorry, it is the middle of the merge window, I'll get to this after 5.11-rc1 is released. thanks, greg k-h
[PATCH v5] PCI: cadence: Retrain Link to work around Gen2 training defect.
From: Nadeem Athani
Cadence controller will not initiate autonomous speed change if strapped as
Gen2. The Retrain Link bit is set as quirk to enable this speed change.
Signed-off-by: Nadeem Athani
[kis...@ti.com: Enable the workaround for TI's J721E SoC]
Signed-off-by: Kishon Vijay Abraham I
---
Hi Lorenzo,
The previous version of the patch can be found at [1].
I slightly re-worked the patch from Nadeem
*) Removed additional Link Up Check
*) Removed quirk from pcie-cadence-plat.c
*) Also removed additional compatible
"cdns,cdns-pcie-host-quirk-retrain" added in that series
*) Enabled the quirk for J721E
[1] -> http://lore.kernel.org/r/20201211144236.3825-1-nad...@cadence.com
drivers/pci/controller/cadence/pci-j721e.c| 3 +
.../controller/cadence/pcie-cadence-host.c| 67 ++-
drivers/pci/controller/cadence/pcie-cadence.h | 11 ++-
3 files changed, 62 insertions(+), 19 deletions(-)
diff --git a/drivers/pci/controller/cadence/pci-j721e.c
b/drivers/pci/controller/cadence/pci-j721e.c
index dac1ac8a7615..baf729850cb1 100644
--- a/drivers/pci/controller/cadence/pci-j721e.c
+++ b/drivers/pci/controller/cadence/pci-j721e.c
@@ -64,6 +64,7 @@ enum j721e_pcie_mode {
struct j721e_pcie_data {
enum j721e_pcie_modemode;
+ boolquirk_retrain_flag;
};
static inline u32 j721e_pcie_user_readl(struct j721e_pcie *pcie, u32 offset)
@@ -280,6 +281,7 @@ static struct pci_ops cdns_ti_pcie_host_ops = {
static const struct j721e_pcie_data j721e_pcie_rc_data = {
.mode = PCI_MODE_RC,
+ .quirk_retrain_flag = true,
};
static const struct j721e_pcie_data j721e_pcie_ep_data = {
@@ -388,6 +390,7 @@ static int j721e_pcie_probe(struct platform_device *pdev)
bridge->ops = _ti_pcie_host_ops;
rc = pci_host_bridge_priv(bridge);
+ rc->quirk_retrain_flag = data->quirk_retrain_flag;
cdns_pcie = >pcie;
cdns_pcie->dev = dev;
diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c
b/drivers/pci/controller/cadence/pcie-cadence-host.c
index 811c1cb2e8de..773c0d1137ed 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-host.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
@@ -77,6 +77,50 @@ static struct pci_ops cdns_pcie_host_ops = {
.write = pci_generic_config_write,
};
+static int cdns_pcie_host_wait_for_link(struct cdns_pcie *pcie)
+{
+ struct device *dev = pcie->dev;
+ int retries;
+
+ /* Check if the link is up or not */
+ for (retries = 0; retries < LINK_WAIT_MAX_RETRIES; retries++) {
+ if (cdns_pcie_link_up(pcie)) {
+ dev_info(dev, "Link up\n");
+ return 0;
+ }
+ usleep_range(LINK_WAIT_USLEEP_MIN, LINK_WAIT_USLEEP_MAX);
+ }
+
+ return -ETIMEDOUT;
+}
+
+static void cdns_pcie_retrain(struct cdns_pcie *pcie)
+{
+ u32 lnk_cap_sls, pcie_cap_off = CDNS_PCIE_RP_CAP_OFFSET;
+ u16 lnk_stat, lnk_ctl;
+
+ /*
+* Set retrain bit if current speed is 2.5 GB/s,
+* but the PCIe root port support is > 2.5 GB/s.
+*/
+
+ lnk_cap_sls = cdns_pcie_readl(pcie, (CDNS_PCIE_RP_BASE + pcie_cap_off +
+PCI_EXP_LNKCAP));
+ if ((lnk_cap_sls & PCI_EXP_LNKCAP_SLS) <= PCI_EXP_LNKCAP_SLS_2_5GB)
+ return;
+
+ lnk_stat = cdns_pcie_rp_readw(pcie, pcie_cap_off + PCI_EXP_LNKSTA);
+ if ((lnk_stat & PCI_EXP_LNKSTA_CLS) == PCI_EXP_LNKSTA_CLS_2_5GB) {
+ lnk_ctl = cdns_pcie_rp_readw(pcie,
+pcie_cap_off + PCI_EXP_LNKCTL);
+ lnk_ctl |= PCI_EXP_LNKCTL_RL;
+ cdns_pcie_rp_writew(pcie, pcie_cap_off + PCI_EXP_LNKCTL,
+ lnk_ctl);
+
+ if (cdns_pcie_host_wait_for_link(pcie))
+ return;
+ }
+}
static int cdns_pcie_host_init_root_port(struct cdns_pcie_rc *rc)
{
@@ -398,23 +442,6 @@ static int cdns_pcie_host_init(struct device *dev,
return cdns_pcie_host_init_address_translation(rc);
}
-static int cdns_pcie_host_wait_for_link(struct cdns_pcie *pcie)
-{
- struct device *dev = pcie->dev;
- int retries;
-
- /* Check if the link is up or not */
- for (retries = 0; retries < LINK_WAIT_MAX_RETRIES; retries++) {
- if (cdns_pcie_link_up(pcie)) {
- dev_info(dev, "Link up\n");
- return 0;
- }
- usleep_range(LINK_WAIT_USLEEP_MIN, LINK_WAIT_USLEEP_MAX);
- }
-
- return -ETIMEDOUT;
-}
-
int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
{
struct device *dev = rc->pcie.dev;
@@ -458,8 +485,12 @@ int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
}
ret = cdns_pcie_host_wait_for_link(pcie);
- if (ret)
+ if (ret) {
Re: Lockdep warning on io_file_data_ref_zero() with 5.10-rc5
hi,
On 11/28/20 5:13 PM, Pavel Begunkov wrote:
On 28/11/2020 23:59, Nadav Amit wrote:
Hello Pavel,
I got the following lockdep splat while rebasing my work on 5.10-rc5 on the
kernel (based on 5.10-rc5+).
I did not actually confirm that the problem is triggered without my changes,
as my iouring workload requires some kernel changes (not iouring changes),
yet IMHO it seems pretty clear that this is a result of your commit
e297822b20e7f ("io_uring: order refnode recycling”), that acquires a lock in
io_file_data_ref_zero() inside a softirq context.
Yeah, that's true. It was already reported by syzkaller and fixed by Jens, but
queued for 5.11. Thanks for letting know anyway!
https://lore.kernel.org/io-uring/948d2d3b-5f36-034d-28e6-7490343a5...@kernel.dk/T/#t
Jens, I think it's for the best to add it for 5.10, at least so that lockdep
doesn't complain.
Yeah maybe, though it's "just" a lockdep issue, it can't trigger any
deadlocks. I'd rather just keep it in 5.11 and ensure it goes to stable.
This isn't new in this series.
Sorry, I'm not familiar with lockdep implementation, here I wonder why you say
it can't trigger any deadlocks, looking at that the syzbot report, seems that
the deadlock may happen.
And I also wonder whether spin lock bh variants are enough, normal ios are
completed in interrupt context,
==> io_complete_rw
> __io_complete_rw
==> io_complete_rw_common
> __io_req_complete
==> io_put_req
> io_free_req
==> __io_free_req
> io_dismantle_req
==> io_put_file
> percpu_ref_put(req->fixed_file_refs);
if we drop the last reference here,
io_file_data_ref_zero() will be called,
then we'll call spin_lock(>lock);
in interrupt context.
Should we use spin lock irq variants?
Regards,
Xiaoguang Wang
[RESEND PATCH v3 2/2] usb: dwc3: Add driver for Xilinx platforms
Add a new driver for supporting Xilinx platforms. This driver is used
for some sequence of operations required for Xilinx USB controllers.
This driver is also used to choose between PIPE clock coming from SerDes
and the Suspend Clock. Before the controller is out of reset, the clock
selection should be changed to PIPE clock in order to make the USB
controller work. There is a register added in Xilinx USB controller
register space for the same.
Signed-off-by: Manish Narani
---
drivers/usb/dwc3/Kconfig | 9 +
drivers/usb/dwc3/Makefile | 1 +
drivers/usb/dwc3/dwc3-of-simple.c | 1 -
drivers/usb/dwc3/dwc3-xilinx.c| 334 ++
4 files changed, 344 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/dwc3/dwc3-xilinx.c
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 7a2304565a73..0e00e6dfccd8 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -139,4 +139,13 @@ config USB_DWC3_QCOM
for peripheral mode support.
Say 'Y' or 'M' if you have one such device.
+config USB_DWC3_XILINX
+ tristate "Xilinx Platforms"
+ depends on (ARCH_ZYNQMP || ARCH_VERSAL) && OF
+ default USB_DWC3
+ help
+ Support Xilinx SoCs with DesignWare Core USB3 IP.
+ This driver handles both ZynqMP and Versal SoC operations.
+ Say 'Y' or 'M' if you have one such device.
+
endif
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index ae86da0dc5bd..add567578b1f 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -51,3 +51,4 @@ obj-$(CONFIG_USB_DWC3_MESON_G12A) += dwc3-meson-g12a.o
obj-$(CONFIG_USB_DWC3_OF_SIMPLE) += dwc3-of-simple.o
obj-$(CONFIG_USB_DWC3_ST) += dwc3-st.o
obj-$(CONFIG_USB_DWC3_QCOM)+= dwc3-qcom.o
+obj-$(CONFIG_USB_DWC3_XILINX) += dwc3-xilinx.o
diff --git a/drivers/usb/dwc3/dwc3-of-simple.c
b/drivers/usb/dwc3/dwc3-of-simple.c
index e62ecd22b3ed..71fd620c5161 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -172,7 +172,6 @@ static const struct dev_pm_ops dwc3_of_simple_dev_pm_ops = {
static const struct of_device_id of_dwc3_simple_match[] = {
{ .compatible = "rockchip,rk3399-dwc3" },
- { .compatible = "xlnx,zynqmp-dwc3" },
{ .compatible = "cavium,octeon-7130-usb-uctl" },
{ .compatible = "sprd,sc9860-dwc3" },
{ .compatible = "allwinner,sun50i-h6-dwc3" },
diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
new file mode 100644
index ..7e485951d2f7
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -0,0 +1,334 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * dwc3-xilinx.c - Xilinx DWC3 controller specific glue driver
+ *
+ * Authors: Manish Narani
+ * Anurag Kumar Vulisha
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/* USB phy reset mask register */
+#define XLNX_USB_PHY_RST_EN0x001C
+#define XLNX_PHY_RST_MASK 0x1
+
+/* Xilinx USB 3.0 IP Register */
+#define XLNX_USB_TRAFFIC_ROUTE_CONFIG 0x005C
+#define XLNX_USB_TRAFFIC_ROUTE_FPD 0x1
+
+/* Versal USB Reset ID */
+#define VERSAL_USB_RESET_ID0xC104036
+
+#define XLNX_USB_FPD_PIPE_CLK 0x7c
+#define PIPE_CLK_DESELECT 1
+#define PIPE_CLK_SELECT0
+#define XLNX_USB_FPD_POWER_PRSNT 0x80
+#define PIPE_POWER_ON 1
+#define PIPE_POWER_OFF 0
+
+struct dwc3_xlnx {
+ int num_clocks;
+ struct clk_bulk_data*clks;
+ struct device *dev;
+ void __iomem*regs;
+ int (*pltfm_init)(struct dwc3_xlnx *data);
+};
+
+static void dwc3_xlnx_mask_phy_rst(struct dwc3_xlnx *priv_data, bool mask)
+{
+ u32 reg;
+
+ /*
+* Enable or disable ULPI PHY reset from USB Controller.
+* This does not actually reset the phy, but just controls
+* whether USB controller can or cannot reset ULPI PHY.
+*/
+ reg = readl(priv_data->regs + XLNX_USB_PHY_RST_EN);
+
+ if (mask)
+ reg &= ~XLNX_PHY_RST_MASK;
+ else
+ reg |= XLNX_PHY_RST_MASK;
+
+ writel(reg, priv_data->regs + XLNX_USB_PHY_RST_EN);
+}
+
+static int dwc3_xlnx_init_versal(struct dwc3_xlnx *priv_data)
+{
+ struct device *dev = priv_data->dev;
+ int ret;
+
+ dwc3_xlnx_mask_phy_rst(priv_data, false);
+
+ /* Assert and De-assert reset */
+ ret = zynqmp_pm_reset_assert(VERSAL_USB_RESET_ID,
+PM_RESET_ACTION_ASSERT);
+ if (ret <
Re: [PATCH 1/2] usb: cdnsp: Fixes for sparse warnings
On 20-12-15 06:14:07, Pawel Laszczak wrote: > >On 20-12-15 05:27:38, Pawel Laszczak wrote: > >> > > >> > > >> >On 20-12-14 13:03:44, Pawel Laszczak wrote: > >> >> Patch fixes all sparse warnings in cdsnp driver. > >> >> > >> >> It fixes the following warnings: > >> >> cdnsp-ring.c:1441: warning: incorrect type in assignment > >> >> cdnsp-ring.c:1444: warning: restricted __le32 degrades to integer > >> >> cdnsp-ring.c:2200: warning: dubious: x | !y > >> >> cdnsp-gadget.c:501: warning: incorrect type in assignment > >> >> cdnsp-gadget.c:504: warning: restricted __le32 degrades to integer > >> >> cdnsp-gadget.c:507: warning: restricted __le32 degrades to integer > >> >> cdnsp-gadget.c:508: warning: restricted __le32 degrades to integer > >> >> cdnsp-gadget.c:509: warning: invalid assignment: |= > >> >> cdnsp-gadget.c:510: warning: cast from restricted __le32 > >> >> cdnsp-gadget.c:558: warning: incorrect type in assignment > >> >> cdnsp-gadget.c:561: warning: restricted __le32 degrades to integer > >> >> cdnsp-gadget.c:570: warning: restricted __le32 degrades to integer > >> >> cdnsp-gadget.c:1571: warning: incorrect type in argument 1 > >> >> cdnsp-gadget.c:1602: warning: restricted __le32 degrades to integer > >> >> cdnsp-gadget.c:1760: warning: incorrect type in assignment > >> >> cdnsp-gadget.c:1762: warning: incorrect type in assignment > >> >> cdnsp-gadget.c:1763: warning: incorrect type in assignment > >> >> cdnsp-gadget.c:1764: warning: incorrect type in assignment > >> >> cdnsp-gadget.c:1765: warning: incorrect type in assignment > >> >> cdnsp-gadget.c:1766: warning: incorrect type in assignment > >> >> cdnsp-gadget.c:1767: warning: incorrect type in assignment > >> >> cdnsp-gadget.c:458: warning: cast truncates bits from constant value > >> >> (07ff becomes 7ff) > >> >> cdnsp-gadget.c:666: warning: cast truncates bits from constant value > >> >> (07ff becomes 7ff) > >> >> cdnsp-mem.c:762: warning: incorrect type in assignment > >> >> cdnsp-mem.c:763: warning: incorrect type in assignment > >> >> cdnsp-mem.c:928: warning: cast from restricted __le16 > >> >> cdnsp-mem.c:1187: warning: incorrect type in assignment > >> >> cdnsp-mem.c:1191: warning: incorrect type in assignment > >> >> cdnsp-ep0.c:142: warning: incorrect type in assignment > >> >> cdnsp-ep0.c:144: warning: restricted __le32 degrades to integer > >> >> cdnsp-ep0.c:147: warning: restricted __le32 degrades to integer > >> >> cdnsp-ep0.c:148: warning: restricted __le32 degrades to integer > >> >> cdnsp-ep0.c:179: warning: incorrect type in argument 1 > >> >> cdnsp-ep0.c:311: warning: incorrect type in argument 1 > >> >> cdnsp-ep0.c:469: warning: incorrect type in assignment > >> >> cdnsp-trace.h:611:1: warning: cast from restricted __le32 > >> >> > >> >> Signed-off-by: Pawel Laszczak > >> >> Reported-by: kernel test robot > >> > > >> >Hi Pawel, > >> > > >> >The Reported-by tag should be above your Sob tag, I will change it. > >> >Except the patch reported build error by kernel test robot, I will apply > >> >your other four patches after finishing the compile test. > >> > > >> >Peter > >> > >> Hi Peter, > >> > >> I'm going to fix the "usb: cdns3: Adds missing __iomem markers" today. > >> I haven't seen any issue on ARCH=parisc. Maybe it's some specific riscv > >> arch issue. > >> > >> I believe that: > >> [auto build test WARNING on next-20201211] > >> [cannot apply to peter.chen-usb/ci-for-usb-next v5.10 v5.10-rc7 v5.10-rc6 > >> v5.10] > >> > >> is not the problem. I based on peter.chen-usb/for-usb-next. > >> > >> Also I can't open the url from kernel test robot report. > >> Maybe there is some temporary issue with server. > >> > > > >Thanks for checking it, I have already pushed your other four patches. > >Besides, there is still a build error issue for new cdns3 driver. > > > >https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.spinics.net%2Flists%2Flinux-data=04%7C01%7Cpeter.chen%40nxp.com%7Cf036cd7630664c9e0c5c08d8a0c0a637%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637436096594708469%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=DLBFVB2px5GgA6Y%2FTU4DrfVru6z3P4RXz2x7BSpdE4o%3Dreserved=0 > >usb/msg206073.html__;!!EHscmS1ygiU1lA!X6rYk64ILtzjyHW903LAhBRjMKi9C2eyJWEXVlEZm0ly2BiNzY2wK46Ulq7q5w$ > > > > Did you applied: [PATCH] usb: cdnsp: Fix for undefined reference to > `usb_hcd_is_primary_hcd' ? > Applied now. -- Thanks, Peter Chen
[RESEND PATCH v3 1/2] dt-bindings: usb: dwc3-xilinx: Add documentation for Versal DWC3 Controller
Add documentation for Versal DWC3 controller. Add required property
'reg' for the same. Also add optional properties for snps,dwc3.
Signed-off-by: Manish Narani
Reviewed-by: Rob Herring
---
.../devicetree/bindings/usb/dwc3-xilinx.txt | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3-xilinx.txt
b/Documentation/devicetree/bindings/usb/dwc3-xilinx.txt
index 4aae5b2cef56..0629f48cc807 100644
--- a/Documentation/devicetree/bindings/usb/dwc3-xilinx.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3-xilinx.txt
@@ -1,7 +1,8 @@
Xilinx SuperSpeed DWC3 USB SoC controller
Required properties:
-- compatible: Should contain "xlnx,zynqmp-dwc3"
+- compatible: May contain "xlnx,zynqmp-dwc3" or "xlnx,versal-dwc3"
+- reg: Base address and length of the register control block
- clocks: A list of phandles for the clocks listed in clock-names
- clock-names: Should contain the following:
"bus_clk" Master/Core clock, have to be >= 125 MHz for SS
@@ -13,12 +14,22 @@ Required child node:
A child node must exist to represent the core DWC3 IP block. The name of
the node is not important. The content of the node is defined in dwc3.txt.
+Optional properties for snps,dwc3:
+- dma-coherent:Enable this flag if CCI is enabled in design. Adding
this
+ flag configures Global SoC bus Configuration Register and
+ Xilinx USB 3.0 IP - USB coherency register to enable CCI.
+- interrupt-names: Should contain the following:
+ "dwc_usb3" USB gadget mode interrupts
+ "otg"USB OTG mode interrupts
+ "hiber" USB hibernation interrupts
+
Example device node:
usb@0 {
#address-cells = <0x2>;
#size-cells = <0x1>;
compatible = "xlnx,zynqmp-dwc3";
+ reg = <0x0 0xff9d 0x0 0x100>;
clock-names = "bus_clk" "ref_clk";
clocks = <>, <>;
ranges;
@@ -26,7 +37,9 @@ Example device node:
dwc3@fe20 {
compatible = "snps,dwc3";
reg = <0x0 0xfe20 0x4>;
- interrupts = <0x0 0x41 0x4>;
+ interrupt-names = "dwc_usb3", "otg", "hiber";
+ interrupts = <0 65 4>, <0 69 4>, <0 75 4>;
dr_mode = "host";
+ dma-coherent;
};
};
--
2.17.1
[RESEND PATCH v3 0/2] Add a separate DWC3 OF driver for Xilinx platforms
This patch series documents the Xilinx Versal DWC3 controller. This also adds a new Xilinx specific driver for adding new features in the future. Changes in v2: - Addressed review comments from v1 - merged normal and runtime suspend resume functions as they are same - Improved description of some register operations to avoid confusion - Updated commit log for patch 2/2 for better clarity. Changes in v3: - Removed snps,enable-hibernation property from the devicetree binding. Manish Narani (2): dt-bindings: usb: dwc3-xilinx: Add documentation for Versal DWC3 Controller usb: dwc3: Add driver for Xilinx platforms .../devicetree/bindings/usb/dwc3-xilinx.txt | 17 +- drivers/usb/dwc3/Kconfig | 9 + drivers/usb/dwc3/Makefile | 1 + drivers/usb/dwc3/dwc3-of-simple.c | 1 - drivers/usb/dwc3/dwc3-xilinx.c| 334 ++ 5 files changed, 359 insertions(+), 3 deletions(-) create mode 100644 drivers/usb/dwc3/dwc3-xilinx.c -- 2.17.1
[PATCH v2 net-next 2/2] nfc: s3fwrn5: Remove unused NCI prop commands
From: Bongsu Jeon
Remove the unused NCI prop commands that s3fwrn5 driver doesn't use.
Signed-off-by: Bongsu Jeon
---
drivers/nfc/s3fwrn5/nci.c | 25 -
drivers/nfc/s3fwrn5/nci.h | 22 --
2 files changed, 47 deletions(-)
diff --git a/drivers/nfc/s3fwrn5/nci.c b/drivers/nfc/s3fwrn5/nci.c
index 103bf5c92bdc..f042d3eaf8f6 100644
--- a/drivers/nfc/s3fwrn5/nci.c
+++ b/drivers/nfc/s3fwrn5/nci.c
@@ -21,31 +21,11 @@ static int s3fwrn5_nci_prop_rsp(struct nci_dev *ndev,
struct sk_buff *skb)
}
static struct nci_driver_ops s3fwrn5_nci_prop_ops[] = {
- {
- .opcode = nci_opcode_pack(NCI_GID_PROPRIETARY,
- NCI_PROP_AGAIN),
- .rsp = s3fwrn5_nci_prop_rsp,
- },
- {
- .opcode = nci_opcode_pack(NCI_GID_PROPRIETARY,
- NCI_PROP_GET_RFREG),
- .rsp = s3fwrn5_nci_prop_rsp,
- },
{
.opcode = nci_opcode_pack(NCI_GID_PROPRIETARY,
NCI_PROP_SET_RFREG),
.rsp = s3fwrn5_nci_prop_rsp,
},
- {
- .opcode = nci_opcode_pack(NCI_GID_PROPRIETARY,
- NCI_PROP_GET_RFREG_VER),
- .rsp = s3fwrn5_nci_prop_rsp,
- },
- {
- .opcode = nci_opcode_pack(NCI_GID_PROPRIETARY,
- NCI_PROP_SET_RFREG_VER),
- .rsp = s3fwrn5_nci_prop_rsp,
- },
{
.opcode = nci_opcode_pack(NCI_GID_PROPRIETARY,
NCI_PROP_START_RFREG),
@@ -61,11 +41,6 @@ static struct nci_driver_ops s3fwrn5_nci_prop_ops[] = {
NCI_PROP_FW_CFG),
.rsp = s3fwrn5_nci_prop_rsp,
},
- {
- .opcode = nci_opcode_pack(NCI_GID_PROPRIETARY,
- NCI_PROP_WR_RESET),
- .rsp = s3fwrn5_nci_prop_rsp,
- },
};
void s3fwrn5_nci_get_prop_ops(struct nci_driver_ops **ops, size_t *n)
diff --git a/drivers/nfc/s3fwrn5/nci.h b/drivers/nfc/s3fwrn5/nci.h
index 23c0b28f247a..a80f0fb082a8 100644
--- a/drivers/nfc/s3fwrn5/nci.h
+++ b/drivers/nfc/s3fwrn5/nci.h
@@ -11,9 +11,6 @@
#include "s3fwrn5.h"
-#define NCI_PROP_AGAIN 0x01
-
-#define NCI_PROP_GET_RFREG 0x21
#define NCI_PROP_SET_RFREG 0x22
struct nci_prop_set_rfreg_cmd {
@@ -25,23 +22,6 @@ struct nci_prop_set_rfreg_rsp {
__u8 status;
};
-#define NCI_PROP_GET_RFREG_VER 0x24
-
-struct nci_prop_get_rfreg_ver_rsp {
- __u8 status;
- __u8 data[8];
-};
-
-#define NCI_PROP_SET_RFREG_VER 0x25
-
-struct nci_prop_set_rfreg_ver_cmd {
- __u8 data[8];
-};
-
-struct nci_prop_set_rfreg_ver_rsp {
- __u8 status;
-};
-
#define NCI_PROP_START_RFREG 0x26
struct nci_prop_start_rfreg_rsp {
@@ -70,8 +50,6 @@ struct nci_prop_fw_cfg_rsp {
__u8 status;
};
-#define NCI_PROP_WR_RESET 0x2f
-
void s3fwrn5_nci_get_prop_ops(struct nci_driver_ops **ops, size_t *n);
int s3fwrn5_nci_rf_configure(struct s3fwrn5_info *info, const char *fw_name);
--
2.17.1
[PATCH v2 net-next 1/2] nfc: s3fwrn5: Remove the delay for NFC sleep
From: Bongsu Jeon Remove the delay for NFC sleep because the delay is only needed to guarantee that the NFC is awake. Signed-off-by: Bongsu Jeon --- drivers/nfc/s3fwrn5/phy_common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/nfc/s3fwrn5/phy_common.c b/drivers/nfc/s3fwrn5/phy_common.c index 497b02b30ae7..81318478d5fd 100644 --- a/drivers/nfc/s3fwrn5/phy_common.c +++ b/drivers/nfc/s3fwrn5/phy_common.c @@ -20,7 +20,8 @@ void s3fwrn5_phy_set_wake(void *phy_id, bool wake) mutex_lock(>mutex); gpio_set_value(phy->gpio_fw_wake, wake); - msleep(S3FWRN5_EN_WAIT_TIME); + if (wake) + msleep(S3FWRN5_EN_WAIT_TIME); mutex_unlock(>mutex); } EXPORT_SYMBOL(s3fwrn5_phy_set_wake); -- 2.17.1
[PATCH v2 net-next 0/2] nfc: s3fwrn5: Refactor the s3fwrn5 module
From: Bongsu Jeon Refactor the s3fwrn5 module. 1/2 is to remove the unneeded delay for NFC sleep. 2/2 is to remove the unused NCI prop commands. ChangeLog: v2: - Update the commit messages. Bongsu Jeon (2): nfc: s3fwrn5: Remove the delay for NFC sleep nfc: s3fwrn5: Remove unused NCI prop commands drivers/nfc/s3fwrn5/nci.c| 25 - drivers/nfc/s3fwrn5/nci.h| 22 -- drivers/nfc/s3fwrn5/phy_common.c | 3 ++- 3 files changed, 2 insertions(+), 48 deletions(-) -- 2.17.1
Re: linux-next: manual merge of the amdgpu tree with the pci tree
On 12/14/20 3:37 PM, Bjorn Helgaas wrote: On Mon, Dec 14, 2020 at 06:18:54PM -0500, Alex Deucher wrote: On Mon, Dec 14, 2020 at 6:16 PM Bjorn Helgaas wrote: On Tue, Dec 15, 2020 at 07:34:31AM +1100, Stephen Rothwell wrote: Hi all, On Tue, 8 Dec 2020 13:56:20 +1100 Stephen Rothwell wrote: I don't plan to merge this upstream via my tree. I was just carrying it in my drm-next branch because we have a number of users that depend on it for working DPC and a number of people use this branch for testing. OK, thanks. FWIW, it's currently marked "Changes Requested" in patchwork, so it isn't really going anywhere right now: https://patchwork.kernel.org/project/linux-pci/patch/cbba08a5e9ca62778c8937f44eda2192a2045da7.1595617529.git.sathyanarayanan.kuppusw...@linux.intel.com/ There is a newer version of this patch set. Please use it when merging this patch. https://patchwork.kernel.org/project/linux-pci/list/?series=370855 I have merged Sean's series, so this would be a good time to try to move this one forward. -- Sathyanarayanan Kuppuswamy Linux Kernel Developer
RE: [EXT] Re: [PATCH 1/2] mmc: Support kmsg dumper based on pstore/blk
>-Original Message-
>From: Ulf Hansson
>Sent: Friday, December 11, 2020 5:02 PM
>To: Bhaskara Budiredla
>Cc: Kees Cook ; Colin Cross
>; Tony Luck ; Sunil Kovvuri
>Goutham ; linux-...@vger.kernel.org; Linux
>Kernel Mailing List ; Christoph Hellwig
>
>Subject: [EXT] Re: [PATCH 1/2] mmc: Support kmsg dumper based on
>pstore/blk
>
>External Email
>
>--
>+ Christoph
>
>On Mon, 7 Dec 2020 at 12:58, Bhaskara Budiredla
>wrote:
>>
>> This patch introduces to mmcpstore. The functioning of mmcpstore is
>> similar to mtdpstore. mmcpstore works on FTL based flash devices
>> whereas mtdpstore works on raw flash devices. When the system crashes,
>> mmcpstore stores the kmsg panic and oops logs to a user specified MMC
>> device.
>>
>> It collects the details about the host MMC device through pstore/blk
>> "blkdev" parameter. The user can specify the MMC device in many ways
>> by checking in Documentation/admin-guide/pstore-blk.rst.
>>
>> The individual mmc host drivers have to define suitable polling and
>> cleanup subroutines to write kmsg panic/oops logs through mmcpstore.
>> These new host operations are needed as pstore panic write runs with
>> interrupts disabled.
>
>Apologies for the delay. I have tried to give this some more thinking, more
>comments below.
>
>[...]
>
>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index
>> d42037f0f10d..7682b267f1d5 100644
>> --- a/drivers/mmc/core/core.c
>> +++ b/drivers/mmc/core/core.c
>> @@ -569,6 +569,30 @@ int mmc_cqe_recovery(struct mmc_host *host) }
>> EXPORT_SYMBOL(mmc_cqe_recovery);
>>
>> +#if IS_ENABLED(CONFIG_MMC_PSTORE)
>> +/**
>> + * mmc_wait_for_pstore_req - initiate a blocking mmc request
>> + * @host: MMC host to start command
>> + * @mrq: MMC request to start
>> + *
>> + * Start a blocking MMC request for a host and wait for the request
>> + * to complete that is based on polling and timeout.
>> + */
>> +void mmc_wait_for_pstore_req(struct mmc_host *host, struct
>> +mmc_request *mrq) {
>> + unsigned int timeout;
>> +
>> + host->ops->req_cleanup_pending(host);
>
>So, the host driver should through this callback, be able to terminate any
>ongoing requests/commands - and also try to make sure that the (e)MMC/SD
>card remains in the data transfer state. Moreover, no locks and no IRQs must
>be used to manage this, right?
>
Yes, that's correct.
>Have you really tried if this works for real?
>
Yes, it's a working solution. Patch were submitted after testing.
>> + mmc_start_request(host, mrq);
>
>This looks like the wrong approach to me, as it will try to re-use the regular
>request based path, where the host driver is allowed to use locks, IRQs,
>DMAs, etc, etc.
>
No. The locks on host driver will be dropped in CONFIG_MMC_PSTORE path.
Similarly, the IRQs will be replaced with polling subroutines during panic
write. Please take a look at patch 2/2 which does this for cavium host driver.
>I would suggest inventing a new separate request path and a new host ops, to
>deal with these kinds of requests.
>
The polling and cleanup host operations are the ones invented for this purpose.
Polling to replace IRQs and cleanup to terminate ongoing requests/commands.
>In this way, the below part with host->ops->req_completion_poll, can
>probably be removed. Instead we may just wait for the request to return
>from the new request path.
>
This is not possible unless CPU itself does the mmc write (through some block
interface?).
If the answer is block interface, sleeping cannot be avoided as part of it.
Do you really think DMA can be avoided for MMC panic writes?
>> +
>> + if (mrq->data) {
>> + timeout = mrq->data->timeout_ns / NSEC_PER_MSEC;
>> + host->ops->req_completion_poll(host, timeout);
>> + }
>> +}
>> +EXPORT_SYMBOL(mmc_wait_for_pstore_req);
>> +#endif
>> +
>> /**
>> * mmc_is_req_done - Determine if a 'cap_cmd_during_tfr' request is
>done
>> * @host: MMC host
>> diff --git a/drivers/mmc/core/mmcpstore.c
>> b/drivers/mmc/core/mmcpstore.c new file mode 100644 index
>> ..1113eae0756c
>> --- /dev/null
>> +++ b/drivers/mmc/core/mmcpstore.c
>> @@ -0,0 +1,302 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * MMC pstore support based on pstore/blk
>> + *
>> + * Copyright (c) 2020 Marvell.
>> + * Author: Bhaskara Budiredla */
>> +
>> +#define pr_fmt(fmt) "mmcpstore: " fmt
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include "block.h"
>> +#include "card.h"
>> +#include "core.h"
>> +
>> +static struct mmcpstore_context {
>> + char dev_name[BDEVNAME_SIZE];
>> + int partno;
>> + sector_t start_sect;
>> + sector_t size;
>> + struct pstore_device_info dev;
>> + struct pstore_blk_config conf;
>> + struct pstore_blk_info info;
>>
Re: [PATCH 0/3] block: blk_interposer - Block Layer Interposer
Hi Folks, On 12/12/20 12:56 AM, Hannes Reinecke wrote: > On 12/11/20 5:33 PM, Jens Axboe wrote: >> On 12/11/20 9:30 AM, Mike Snitzer wrote: >>> While I still think there needs to be a proper _upstream_ consumer of >>> blk_interposer as a condition of it going in.. I'll let others make the >>> call. >> >> That's an unequivocal rule. >> >>> As such, I'll defer to Jens, Christoph and others on whether your >>> minimalist blk_interposer hook is acceptable in the near-term. >> >> I don't think so, we don't do short term bandaids just to plan on >> ripping that out when the real functionality is there. IMHO, the dm >> approach is the way to go - it provides exactly the functionality that >> is needed in an appropriate way, instead of hacking some "interposer" >> into the core block layer. >> > Which is my plan, too. > > I'll be working with the Veeam folks to present a joint patchset (including > the DM bits) for the next round. > Besides the dm approach, do you think Veeam's original requirement is a good use case of "block/bpf: add eBPF based block layer IO filtering"? https://lwn.net/ml/bpf/20200812163305.545447-1-leah.ruman...@gmail.com/ Thanks, Bob
Re: [PATCH 5.4 00/36] 5.4.84-rc1 review
On Mon, 14 Dec 2020 at 22:57, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.4.84 release. > There are 36 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 16 Dec 2020 17:25:32 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.84-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.4.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 5.4.84-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.4.y git commit: fbaf54ae613a47a62193642683ab9f23997aaa50 git describe: v5.4.83-37-gfbaf54ae613a Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.83-37-gfbaf54ae613a No regressions (compared to build v5.4.83) No fixes (compared to build v5.4.83) Ran 53822 total tests in the following environments and test suites. Environments -- - arc - arm - arm64 - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - mips - nxp-ls2088 - parisc - powerpc - qemu-arm-clang - qemu-arm64-clang - qemu-arm64-kasan - qemu-x86_64-clang - qemu-x86_64-kasan - qemu-x86_64-kcsan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - riscv - s390 - sh - sparc - x15 - x86 - x86-kasan Test Suites --- * build * linux-log-parser * install-android-platform-tools-r2600 * kselftest * ltp-cap_bounds-tests * ltp-commands-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-tracing-tests * perf * v4l2-compliance * libhugetlbfs * ltp-controllers-tests * ltp-cve-tests * ltp-dio-tests * ltp-io-tests * network-basic-tests * ltp-containers-tests * ltp-fs-tests * ltp-open-posix-tests * kvm-unit-tests * rcutorture * fwts * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
[PATCH] sched: don't check rq after newidle_balance return positive
From: Chen Xiaoguang In pick_next_task_fair, if CPU is going to idle newidle_balance is called first trying to pull some tasks. When newidle_balance returns positive which means it does pulls tasks or some tasks enqueued then there is no need to check sched_fair_runnable again. Signed-off-by: He Chen Signed-off-by: Xiaoguang Chen --- kernel/sched/fair.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index ae7ceba..c2f7eac 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7004,10 +7004,9 @@ struct task_struct * struct task_struct *p; int new_tasks; -again: if (!sched_fair_runnable(rq)) goto idle; - +again: #ifdef CONFIG_FAIR_GROUP_SCHED if (!prev || prev->sched_class != _sched_class) goto simple; -- 1.8.3.1
[QUESTION] Dying cgroups in subsystem cpu, pids and named hierarchy systemd
Hi all,
When i do some tests with kernel-4.19.x，i found some dying cgroups.
There are dying cgroup in subsystem cpu/cpuacct, memory, pids and named
hierarchy systemd.
The root cause of dying cgroups in memory subsystem is that some charged pages
aren't gone.
I don't figure out why there are dying cgroup in cpu, pids and named hierarchy
systemd.
I used to turn on/off Delegate and do operation "systemctl daemon-reload" in
the machine,
but now can't reproduce it.
Is this normal and what may cause this or any suggestions about this?
The details about the machine with problem is as below:
# mount -t cgroup
cgroup on /sys/fs/cgroup/systemd type cgroup
(rw,nosuid,nodev,noexec,relatime,seclabel,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/pids type cgroup
(rw,nosuid,nodev,noexec,relatime,seclabel,pids)
cgroup on /sys/fs/cgroup/memory type cgroup
(rw,nosuid,nodev,noexec,relatime,seclabel,memory)
cgroup on /sys/fs/cgroup/blkio type cgroup
(rw,nosuid,nodev,noexec,relatime,seclabel,blkio)
cgroup on /sys/fs/cgroup/devices type cgroup
(rw,nosuid,nodev,noexec,relatime,seclabel,devices)
cgroup on /sys/fs/cgroup/perf_event type cgroup
(rw,nosuid,nodev,noexec,relatime,seclabel,perf_event)
cgroup on /sys/fs/cgroup/rdma type cgroup
(rw,nosuid,nodev,noexec,relatime,seclabel,rdma)
cgroup on /sys/fs/cgroup/freezer type cgroup
(rw,nosuid,nodev,noexec,relatime,seclabel,freezer)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup
(rw,nosuid,nodev,noexec,relatime,seclabel,net_cls,net_prio)
cgroup on /sys/fs/cgroup/cpuset type cgroup
(rw,nosuid,nodev,noexec,relatime,seclabel,cpuset)
cgroup on /sys/fs/cgroup/hugetlb type cgroup
(rw,nosuid,nodev,noexec,relatime,seclabel,hugetlb)
memory on /cgroup/memory type cgroup (rw,relatime,seclabel,memory)
cpu,cpuacct on /sys/fs/cgroup/cpu,cpuacct type cgroup
(rw,relatime,seclabel,cpu,cpuacct)
# cat /proc/cgroups
#subsys_namehierarchynum_cgroupsenabled
cpuset121091
cpu101101
cpuacct101101
blkio41091
memory325711
devices51091
freezer91091
net_cls1111
perf_event611
net_prio1111
hugetlb1311
pids24801
...
# crash vmlinux /proc/kcore
crash> list cgroup_roots
81272558
...
list -H 81272558 -s
cgroup_root.subsys_mask,hierarchy_id,cgrp.nr_dying_descendants -l
cgroup_root.root_list
8007ff67c6f8// cpu,cpuacct
subsys_mask = 6
hierarchy_id = 10
cgrp.nr_dying_descendants = 1,
...
8007ff6726f8// memory
subsys_mask = 16
hierarchy_id = 3
cgrp.nr_dying_descendants = 2036,
800fb579c6f8// pids
subsys_mask = 2048
hierarchy_id = 2
cgrp.nr_dying_descendants = 1,
800fb57986f8// named systemd
subsys_mask = 0
hierarchy_id = 1
cgrp.nr_dying_descendants = 1,
...
For the cpu subsystem, the dying cgroup is /sys/fs/cgroup/cpu/user.slice:
crash> p root_task_group.css.cgroup
$4 = (struct cgroup *) 0x8007ff67c010
crash> cgroup_subsys_state 8007ff67c010 -ox
struct cgroup_subsys_state {
[8007ff67c010] struct cgroup *cgroup;
[8007ff67c018] struct cgroup_subsys *ss;
[8007ff67c020] struct percpu_ref refcnt;
[8007ff67c058] struct list_head sibling;
[8007ff67c068] struct list_head children;
[8007ff67c078] struct list_head rstat_css_node;
[8007ff67c088] int id;
[8007ff67c08c] unsigned int flags;
[8007ff67c090] u64 serial_nr;
[8007ff67c098] atomic_t online_cnt;
[8007ff67c0a0] struct work_struct destroy_work;
[8007ff67c0e0] struct rcu_work destroy_rwork;
[8007ff67c138] struct cgroup_subsys_state *parent;
}
SIZE: 0x130
crash> list -H 8007ff67c068 -s cgroup_subsys_state.cgroup -l
cgroup_subsys_state.sibling
800faff65848
cgroup = 0x800faff65800
800fa18b1048
cgroup = 0x800fa18b1000
800fa22c0848
cgroup = 0x800fa22c0800
800fa940e048
cgroup = 0x800fa940e000
crash>
crash> cgroup.self.refcnt,flags,kn 0x800fa18b1000 -x
self.refcnt = {
count = {
counter = 0x3
},
percpu_count_ptr = 0xfffefdf041334c83,
release = 0x801c1ea0 ,
confirm_switch = 0x0,
force_atomic = 0x0,
rcu = {
next = 0x80083365da30,
func = 0x804fb748
}
},
flags = 0x0
kn = 0x800bbdb1b110
crash>
crash> kernfs_node.name 0x800bbdb1b110
name = 0x800fa54d9c00 "user.slice"
Thanks,
Chen Zhou
[PATCH] udlfb: Fix memory leak in dlfb_usb_probe
From: Zqiang The dlfb_alloc_urb_list function is called in dlfb_usb_probe function, after that if an error occurs, the dlfb_free_urb_list function need to be called. BUG: memory leak unreferenced object 0x88810adde100 (size 32): comm "kworker/1:0", pid 17, jiffies 4294947788 (age 19.520s) hex dump (first 32 bytes): 10 30 c3 0d 81 88 ff ff c0 fa 63 12 81 88 ff ff .0c. 00 30 c3 0d 81 88 ff ff 80 d1 3a 08 81 88 ff ff .0:. backtrace: [<19512953>] kmalloc include/linux/slab.h:552 [inline] [<19512953>] kzalloc include/linux/slab.h:664 [inline] [<19512953>] dlfb_alloc_urb_list drivers/video/fbdev/udlfb.c:1892 [inline] [<19512953>] dlfb_usb_probe.cold+0x289/0x988 drivers/video/fbdev/udlfb.c:1704 [<72160152>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [] really_probe+0x159/0x480 drivers/base/dd.c:554 [ ] driver_probe_device+0x84/0x100 drivers/base/dd.c:738 [ ] __device_attach_driver+0xee/0x110 drivers/base/dd.c:844 [ ] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431 [<463fbcb4>] __device_attach+0x122/0x250 drivers/base/dd.c:912 [ ] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:491 [<364bbda5>] device_add+0x5ac/0xc30 drivers/base/core.c:2936 [ ] usb_set_configuration+0x9de/0xb90 drivers/usb/core/message.c:2159 [ ] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238 [<1830872b>] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293 [ ] really_probe+0x159/0x480 drivers/base/dd.c:554 [ ] driver_probe_device+0x84/0x100 drivers/base/dd.c:738 [ ] __device_attach_driver+0xee/0x110 drivers/base/dd.c:844 [ ] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:431 Reported-by: syzbot+c9e365d7f450e8aa6...@syzkaller.appspotmail.com Signed-off-by: Zqiang --- drivers/video/fbdev/udlfb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c index f9b3c1cb9530..b9cdd02c1000 100644 --- a/drivers/video/fbdev/udlfb.c +++ b/drivers/video/fbdev/udlfb.c @@ -1017,6 +1017,7 @@ static void dlfb_ops_destroy(struct fb_info *info) } vfree(dlfb->backing_buffer); kfree(dlfb->edid); + dlfb_free_urb_list(dlfb); usb_put_dev(dlfb->udev); kfree(dlfb); -- 2.17.1
Re: [PATCH v1] serial: 8250_fintek: Print Fintek chip name
On 15. 12. 20, 1:29, Ji-Ze Hong (Peter Hong) wrote:
Hi,
Greg Kroah-Hartman 於 2020/12/14 下午 09:42 寫道:
pdata->pid = chip;
+
+ pr_info("%s%s%s Fintek %s\n",
+ uart->port.dev ? dev_name(uart->port.dev) : "",
+ uart->port.dev ? ": " : "",
+ uart->port.name,
+ chip_name);
Drivers, if all goes well, should not print anything to the kernel log.
This isn't ok.
And even if it was, dev_info() would be the correct thing to do...
Maybe can transform pr_info() to dev_dbg() for debug usage ?
And even then, the newly introduced fintek_8250.chip_name is unused.
thanks,
--
js
Re: [PATCH] Input: raydium_ts_i2c: Do not send zero length
On Tue, Dec 15, 2020 at 02:07:00PM +0800, Jeffrey Lin wrote:
> Yes, it is.
Great!
>
> Dmitry Torokhov 於 2020年12月15日 週二 下午1:48寫道：
>
> > Hi Jeffrey,
> >
> > On Tue, Dec 15, 2020 at 11:21:06AM +0800, jeffrey.lin wrote:
> > > Add default write command package to prevent i2c quirk error of zero
> > > data length as Raydium touch firmware update is executed.
> > >
> > > Signed-off-by: jeffrey.lin
> > > BUG=b:174207906
> > > TEST=Successfully tested update Raydium touch firmware over 100 times
> > > Change-Id: I311b0d26d7642bb800547cd0e87013be17cb7e1b
Could you please drop these BUG/TEST/Change-Id and re-send from your
main account (jeffrey@rad-ic.com)? Or simply add "From:" tag:
From: Jeffrey Lin
> > > ---
> > > drivers/input/touchscreen/raydium_i2c_ts.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/input/touchscreen/raydium_i2c_ts.c
> > b/drivers/input/touchscreen/raydium_i2c_ts.c
> > > index 603a948460d64..4d2d22a869773 100644
> > > --- a/drivers/input/touchscreen/raydium_i2c_ts.c
> > > +++ b/drivers/input/touchscreen/raydium_i2c_ts.c
> > > @@ -445,6 +445,7 @@ static int raydium_i2c_write_object(struct
> > i2c_client *client,
> > > enum raydium_bl_ack state)
> > > {
> > > int error;
> > > + static const u8 cmd[] = { 0xFF, 0x39 };
> > >
> > > error = raydium_i2c_send(client, RM_CMD_BOOT_WRT, data, len);
> > > if (error) {
> > > @@ -453,7 +454,7 @@ static int raydium_i2c_write_object(struct
> > i2c_client *client,
> > > return error;
> > > }
> > >
> > > - error = raydium_i2c_send(client, RM_CMD_BOOT_ACK, NULL, 0);
> > > + error = raydium_i2c_send(client, RM_CMD_BOOT_ACK, cmd,
> > sizeof(cmd));
> >
> > Is this supported by all firmwares?
> >
> > > if (error) {
> > > dev_err(>dev, "Ack obj command failed: %d\n",
> > error);
> > > return error;
> > > --
> > > 2.26.2
> > >
> >
> > Thanks.
> >
> > --
> > Dmitry
> >
Thanks!
--
Dmitry
Re: [PATCH v2] net/mlx4: Use true,false for bool variable
On Mon, Dec 14, 2020 at 09:37:34PM -0800, Joe Perches wrote: > On Tue, 2020-12-15 at 07:18 +0200, Leon Romanovsky wrote: > > On Mon, Dec 14, 2020 at 11:15:01AM -0800, Joe Perches wrote: > > > I prefer revisions to single patches (as opposed to large patch series) > > > in the same thread. > > > > It depends which side you are in that game. From the reviewer point of > > view, such submission breaks flow very badly. It unfolds the already > > reviewed thread, messes with the order and many more little annoying > > things. > > This is where I disagree with you. I am a reviewer here. It is ok, different people have different views. > > Not having context to be able to inspect vN -> vN+1 is made > more difficult not having the original patch available and > having to search history for it. I'm following after specific subsystems and see all patches there, so for me and Jakub context already exists. Bottom line, it depends on the workflow. > > Almost no one adds URL links to older submissions below the ---. Too bad, maybe it is time to enforce it. > > Were that a standard mechanism below the --- line, then it would > be OK. So let's me summarize, we (RDMA and netdev subsystems) would like to ask do not submit new patch revisions as reply-to. Thanks
RE: [PATCH 1/2] usb: cdnsp: Fixes for sparse warnings
>>On 20-12-15 05:27:38, Pawel Laszczak wrote: >>> > >>> > >>> >On 20-12-14 13:03:44, Pawel Laszczak wrote: >>> >> Patch fixes all sparse warnings in cdsnp driver. >>> >> >>> >> It fixes the following warnings: >>> >> cdnsp-ring.c:1441: warning: incorrect type in assignment >>> >> cdnsp-ring.c:1444: warning: restricted __le32 degrades to integer >>> >> cdnsp-ring.c:2200: warning: dubious: x | !y >>> >> cdnsp-gadget.c:501: warning: incorrect type in assignment >>> >> cdnsp-gadget.c:504: warning: restricted __le32 degrades to integer >>> >> cdnsp-gadget.c:507: warning: restricted __le32 degrades to integer >>> >> cdnsp-gadget.c:508: warning: restricted __le32 degrades to integer >>> >> cdnsp-gadget.c:509: warning: invalid assignment: |= >>> >> cdnsp-gadget.c:510: warning: cast from restricted __le32 >>> >> cdnsp-gadget.c:558: warning: incorrect type in assignment >>> >> cdnsp-gadget.c:561: warning: restricted __le32 degrades to integer >>> >> cdnsp-gadget.c:570: warning: restricted __le32 degrades to integer >>> >> cdnsp-gadget.c:1571: warning: incorrect type in argument 1 >>> >> cdnsp-gadget.c:1602: warning: restricted __le32 degrades to integer >>> >> cdnsp-gadget.c:1760: warning: incorrect type in assignment >>> >> cdnsp-gadget.c:1762: warning: incorrect type in assignment >>> >> cdnsp-gadget.c:1763: warning: incorrect type in assignment >>> >> cdnsp-gadget.c:1764: warning: incorrect type in assignment >>> >> cdnsp-gadget.c:1765: warning: incorrect type in assignment >>> >> cdnsp-gadget.c:1766: warning: incorrect type in assignment >>> >> cdnsp-gadget.c:1767: warning: incorrect type in assignment >>> >> cdnsp-gadget.c:458: warning: cast truncates bits from constant value >>> >> (07ff becomes 7ff) >>> >> cdnsp-gadget.c:666: warning: cast truncates bits from constant value >>> >> (07ff becomes 7ff) >>> >> cdnsp-mem.c:762: warning: incorrect type in assignment >>> >> cdnsp-mem.c:763: warning: incorrect type in assignment >>> >> cdnsp-mem.c:928: warning: cast from restricted __le16 >>> >> cdnsp-mem.c:1187: warning: incorrect type in assignment >>> >> cdnsp-mem.c:1191: warning: incorrect type in assignment >>> >> cdnsp-ep0.c:142: warning: incorrect type in assignment >>> >> cdnsp-ep0.c:144: warning: restricted __le32 degrades to integer >>> >> cdnsp-ep0.c:147: warning: restricted __le32 degrades to integer >>> >> cdnsp-ep0.c:148: warning: restricted __le32 degrades to integer >>> >> cdnsp-ep0.c:179: warning: incorrect type in argument 1 >>> >> cdnsp-ep0.c:311: warning: incorrect type in argument 1 >>> >> cdnsp-ep0.c:469: warning: incorrect type in assignment >>> >> cdnsp-trace.h:611:1: warning: cast from restricted __le32 >>> >> >>> >> Signed-off-by: Pawel Laszczak >>> >> Reported-by: kernel test robot >>> > >>> >Hi Pawel, >>> > >>> >The Reported-by tag should be above your Sob tag, I will change it. >>> >Except the patch reported build error by kernel test robot, I will apply >>> >your other four patches after finishing the compile test. >>> > >>> >Peter >>> >>> Hi Peter, >>> >>> I'm going to fix the "usb: cdns3: Adds missing __iomem markers" today. >>> I haven't seen any issue on ARCH=parisc. Maybe it's some specific riscv >>> arch issue. >>> >>> I believe that: >>> [auto build test WARNING on next-20201211] >>> [cannot apply to peter.chen-usb/ci-for-usb-next v5.10 v5.10-rc7 v5.10-rc6 >>> v5.10] >>> >>> is not the problem. I based on peter.chen-usb/for-usb-next. >>> >>> Also I can't open the url from kernel test robot report. >>> Maybe there is some temporary issue with server. >>> >> >>Thanks for checking it, I have already pushed your other four patches. >>Besides, there is still a build error issue for new cdns3 driver. >> >>https://urldefense.com/v3/__https://www.spinics.net/lists/linux- >>usb/msg206073.html__;!!EHscmS1ygiU1lA!X6rYk64ILtzjyHW903LAhBRjMKi9C2eyJWEXVlEZm0ly2BiNzY2wK46Ulq7q5w$ >> > >Did you applied: [PATCH] usb: cdnsp: Fix for undefined reference to >`usb_hcd_is_primary_hcd' ? It's my local log: ab474baa0302 (HEAD -> for-usb-next) usb: cdns3: Adds missing __iomem markers 4af8270829f2 usb: cdnsp: Fixes for sparse warnings 4f5f85f26e77 usb: cdns3: Fixes for sparse warnings cd41bb30fc26 dan.carpenter@oracle.comusb: cdnsp: fix error handling in cdnsp_mem_init() 1918b1486f94 usb: cdns3: Removes xhci_cdns3_suspend_quirk from host-export.h d47d84a1cd8a usb: cdnsp: Fix for undefined reference to `usb_hcd_is_primary_hcd' df1b6960d363 (peter.chen-usb/for-usb-next) usb: cdnsp: Removes some not useful function arguments 94e0623337a6 usb: cdns3: fix warning when USB_CDNS_HOST is not set >Pawel > >>Peter >>> Thanks, >>> Pawel >>> >>> >> --- >>> >> drivers/usb/cdns3/cdnsp-debug.h | 2 +- >>> >> drivers/usb/cdns3/cdnsp-ep0.c| 13 ++--- >>> >> drivers/usb/cdns3/cdnsp-gadget.c | 24 +--- >>> >> drivers/usb/cdns3/cdnsp-gadget.h | 13 +++-- >>> >> drivers/usb/cdns3/cdnsp-mem.c| 11
Re: [PATCH] x86/mtrr: Correct the returned MTRR type of mtrr_type_lookup.
On Fri, 11 Dec 2020, Borislav Petkov wrote:
> [CAUTION: External Email]
>
> On Mon, Dec 07, 2020 at 02:12:26PM +0800, Ying-Tsun Huang wrote:
> > In mtrr_type_lookup, if the input memory address region is not in the
> > MTRR, over 4GB, and not over the top of memory, write-back attribute
> > is returned. These condition checks are for ensuring the input memory
> > address region is mapped to the physical memory actually.
> >
> > However, if the end address is just aligned with the top of memory,
> > the condition check treats the address is over the top of memory, and
> > write-back attribute is not returned.
>
> Oh fun. So to make sure I understand this correctly end ends up equal to
> TOM2?
>
Yes, it's equal to TOM2.
> > There is a real case of NVDIMM. The nd_pmem module tries to map
> > NVDIMMs as cacheable memories when NVDIMMs are connected. If a NVDIMM
> > is the last of the DIMMs, the performance of this NVDIMM becomes very
> > low since it aligned with the top of memory and its memory type is
> > uncached-minus.
> >
> > To check the top of memory should use "<=" instead of "<" since both the
> > input end address and the value of top of memory are actually the start
> > of next region.
>
> Right, so looking at that function, it calls
> mtrr_type_lookup_variable(), among others, and that does:
>
> /* Make end inclusive instead of exclusive */
> end--;
>
> which sounds to me like it expects ranges with exclusive end.
>
> So maybe it would be better to do something like:
>
> /*
> * Blurb about end address being == tom2, perhaps give your example
> */
> end--;
>
> above the check so that it is absolutely obvious why this is done.
>
> But but, looking at this more, the PPR says about TOM2:
>
> "This value is normally placed above 4G. From 4G to TOM2 - 1 is DRAM;
> TOM2 and above is MMIO."
>
> So the check is *actually* correct - TOM2 - 1 is DRAM so you need '<'.
>
> Unless you do end-- before, which would make sense and suggest the end
> decrement to be the proper fix.
>
> Hmm?
>
I think your comment makes sense, "TOM2 - 1" is the last DRAM address, we
should make the end be included in the DRAM range, and the condition check
becomes more precise to use "<", even the both codes are with the same
result.
> > Fixes: b73522e0c1be ("x86/mm/mtrr: Enhance MTRR checks in kernel mapping
> > helpers")
>
> I think you mean:
>
> 35605a1027ac ("x86: enable PAT for amd k8 and fam10h")
>
> which first added that check.
>
> Btw, while doing git archeology, I saw that mtrr_type_lookup() used to do
> end--
> on function entry, see
>
> 2e5d9c857d4e ("x86: PAT infrastructure patch")
>
With your above comments, the bug should come from
0cc705f56e40 ("x86/mm/mtrr: Clean up mtrr_type_lookup()"
Before this commit, the "end--" is in __mtrr_type_lookup(), and the end
address is not used in mtrr_type_lookup, so the condition check is
correct.
After the commit, the end address is started to be used in
mtrr_type_lookup(), but the "end--" is in the mtrr_type_lookup_variable(),
it makes the check mtrr_type_lookup() become incorrect.
> Thx.
>
> --
> Regards/Gruss,
> Boris.
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpeople.kernel.org%2Ftglx%2Fnotes-about-netiquettedata=04%7C01%7Cying-tsun.huang%40amd.com%7C2e57de535baf40ff480f08d89dc2e51d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637432807709717408%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=tM5ww%2F96JirsAsDZyImHHtsR3L8TQyr%2B5xWeaGbdwH4%3Dreserved=0
>
Re: [PATCH v4 3/3] scsi: ufs: Revert "Make sure clk scaling happens only when HBA is runtime ACTIVE"
On Sun, 2020-12-13 at 08:31 -0800, Can Guo wrote:
> Commit 73cc291c27024 ("Make sure clk scaling happens only when HBA is
> runtime ACTIVE") is no longer needed since commit f7a42540928a8 ("scsi:
> ufs: Protect some contexts from unexpected clock scaling") is a more
> mature fix to protect UFS LLD stability from clock scaling invoked through
> sysfs nodes by users.
>
> Signed-off-by: Can Guo
Reviewed-by: Stanley Chu
RE: [PATCH 1/2] usb: cdnsp: Fixes for sparse warnings
>On 20-12-15 05:27:38, Pawel Laszczak wrote: >> > >> > >> >On 20-12-14 13:03:44, Pawel Laszczak wrote: >> >> Patch fixes all sparse warnings in cdsnp driver. >> >> >> >> It fixes the following warnings: >> >> cdnsp-ring.c:1441: warning: incorrect type in assignment >> >> cdnsp-ring.c:1444: warning: restricted __le32 degrades to integer >> >> cdnsp-ring.c:2200: warning: dubious: x | !y >> >> cdnsp-gadget.c:501: warning: incorrect type in assignment >> >> cdnsp-gadget.c:504: warning: restricted __le32 degrades to integer >> >> cdnsp-gadget.c:507: warning: restricted __le32 degrades to integer >> >> cdnsp-gadget.c:508: warning: restricted __le32 degrades to integer >> >> cdnsp-gadget.c:509: warning: invalid assignment: |= >> >> cdnsp-gadget.c:510: warning: cast from restricted __le32 >> >> cdnsp-gadget.c:558: warning: incorrect type in assignment >> >> cdnsp-gadget.c:561: warning: restricted __le32 degrades to integer >> >> cdnsp-gadget.c:570: warning: restricted __le32 degrades to integer >> >> cdnsp-gadget.c:1571: warning: incorrect type in argument 1 >> >> cdnsp-gadget.c:1602: warning: restricted __le32 degrades to integer >> >> cdnsp-gadget.c:1760: warning: incorrect type in assignment >> >> cdnsp-gadget.c:1762: warning: incorrect type in assignment >> >> cdnsp-gadget.c:1763: warning: incorrect type in assignment >> >> cdnsp-gadget.c:1764: warning: incorrect type in assignment >> >> cdnsp-gadget.c:1765: warning: incorrect type in assignment >> >> cdnsp-gadget.c:1766: warning: incorrect type in assignment >> >> cdnsp-gadget.c:1767: warning: incorrect type in assignment >> >> cdnsp-gadget.c:458: warning: cast truncates bits from constant value >> >> (07ff becomes 7ff) >> >> cdnsp-gadget.c:666: warning: cast truncates bits from constant value >> >> (07ff becomes 7ff) >> >> cdnsp-mem.c:762: warning: incorrect type in assignment >> >> cdnsp-mem.c:763: warning: incorrect type in assignment >> >> cdnsp-mem.c:928: warning: cast from restricted __le16 >> >> cdnsp-mem.c:1187: warning: incorrect type in assignment >> >> cdnsp-mem.c:1191: warning: incorrect type in assignment >> >> cdnsp-ep0.c:142: warning: incorrect type in assignment >> >> cdnsp-ep0.c:144: warning: restricted __le32 degrades to integer >> >> cdnsp-ep0.c:147: warning: restricted __le32 degrades to integer >> >> cdnsp-ep0.c:148: warning: restricted __le32 degrades to integer >> >> cdnsp-ep0.c:179: warning: incorrect type in argument 1 >> >> cdnsp-ep0.c:311: warning: incorrect type in argument 1 >> >> cdnsp-ep0.c:469: warning: incorrect type in assignment >> >> cdnsp-trace.h:611:1: warning: cast from restricted __le32 >> >> >> >> Signed-off-by: Pawel Laszczak >> >> Reported-by: kernel test robot >> > >> >Hi Pawel, >> > >> >The Reported-by tag should be above your Sob tag, I will change it. >> >Except the patch reported build error by kernel test robot, I will apply >> >your other four patches after finishing the compile test. >> > >> >Peter >> >> Hi Peter, >> >> I'm going to fix the "usb: cdns3: Adds missing __iomem markers" today. >> I haven't seen any issue on ARCH=parisc. Maybe it's some specific riscv >> arch issue. >> >> I believe that: >> [auto build test WARNING on next-20201211] >> [cannot apply to peter.chen-usb/ci-for-usb-next v5.10 v5.10-rc7 v5.10-rc6 >> v5.10] >> >> is not the problem. I based on peter.chen-usb/for-usb-next. >> >> Also I can't open the url from kernel test robot report. >> Maybe there is some temporary issue with server. >> > >Thanks for checking it, I have already pushed your other four patches. >Besides, there is still a build error issue for new cdns3 driver. > >https://urldefense.com/v3/__https://www.spinics.net/lists/linux- >usb/msg206073.html__;!!EHscmS1ygiU1lA!X6rYk64ILtzjyHW903LAhBRjMKi9C2eyJWEXVlEZm0ly2BiNzY2wK46Ulq7q5w$ > Did you applied: [PATCH] usb: cdnsp: Fix for undefined reference to `usb_hcd_is_primary_hcd' ? Pawel >Peter >> Thanks, >> Pawel >> >> >> --- >> >> drivers/usb/cdns3/cdnsp-debug.h | 2 +- >> >> drivers/usb/cdns3/cdnsp-ep0.c| 13 ++--- >> >> drivers/usb/cdns3/cdnsp-gadget.c | 24 +--- >> >> drivers/usb/cdns3/cdnsp-gadget.h | 13 +++-- >> >> drivers/usb/cdns3/cdnsp-mem.c| 11 ++- >> >> drivers/usb/cdns3/cdnsp-ring.c | 4 ++-- >> >> drivers/usb/cdns3/cdnsp-trace.h | 2 +- >> >> 7 files changed, 32 insertions(+), 37 deletions(-) >> >> >> >> diff --git a/drivers/usb/cdns3/cdnsp-debug.h >> >> b/drivers/usb/cdns3/cdnsp-debug.h >> >> index d6345d4d2911..a8776df2d4e0 100644 >> >> --- a/drivers/usb/cdns3/cdnsp-debug.h >> >> +++ b/drivers/usb/cdns3/cdnsp-debug.h >> >> @@ -414,7 +414,7 @@ static inline const char >> >> *cdnsp_decode_slot_context(u32 info, u32 info2, >> >> s = "UNKNOWN speed"; >> >> } >> >> >> >> - ret = sprintf(str, "%s Ctx Entries %ld", >> >> + ret = sprintf(str, "%s Ctx Entries %d", >> >> s, (info & LAST_CTX_MASK) >>
Re: [PATCH] proc: Escape more characters in /proc/mounts output
On Tue, Dec 15, 2020 at 09:54:54AM +0530, Siddhesh Poyarekar wrote: > + get_user(byte, (const char __user *)data); > + > + return byte ? strndup_user(data, PATH_MAX) : NULL; > } No. Not to mention anything else, you * fetch the same data twice * fail to check the get_user() results
Re: [PATCH 1/2] futex: mark futex_detect_cmpxchg() as 'noinline'
Hi Arnd,
On Mon, Dec 14, 2020 at 9:15 PM Arnd Bergmann wrote:
>
> On Sat, Dec 12, 2020 at 9:01 PM Thomas Gleixner wrote:
> >
> > On Sat, Dec 12 2020 at 13:26, Marco Elver wrote:
> > > On Thu, Mar 07, 2019 at 10:14AM +0100, Arnd Bergmann wrote:
> > >> -static void __init futex_detect_cmpxchg(void)
> > >> +static noinline void futex_detect_cmpxchg(void)
> > >> {
> > >> #ifndef CONFIG_HAVE_FUTEX_CMPXCHG
> > >> u32 curval;
> > >
> > > What ever happened to this patch?
> >
> > It obviously fell through the cracks.
> >
> > > I'm seeing this again with the attached config + next-20201211 (for
> > > testing https://bugs.llvm.org/show_bug.cgi?id=48492). Had to apply this
> > > patch to build the kernel.
> >
> > What really bothers me is to remove the __init from a function which is
> > clearly only used during init. And looking deeper it's simply a hack.
> >
> > This function is only needed when an architecture has to runtime
> > discover whether the CPU supports it or not. ARM has unconditional
> > support for this, so the obvious thing to do is the below.
> >
>
> Ah perfect, that is clearly the right solution here.
>
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -86,6 +86,7 @@ config ARM
> > select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL
> > select HAVE_FUNCTION_GRAPH_TRACER if !THUMB2_KERNEL && !CC_IS_CLANG
> > select HAVE_FUNCTION_TRACER if !XIP_KERNEL
> > + select HAVE_FUTEX_CMPXCHG if FUTEX
> > select HAVE_GCC_PLUGINS
> > select HAVE_HW_BREAKPOINT if PERF_EVENTS && (CPU_V6 || CPU_V6K ||
> > CPU_V7)
> > select HAVE_IDE if PCI || ISA || PCMCIA
>
> I had a look at what other architectures always implement
> futex_atomic_cmpxchg_inatomic() or can use the asm-generic non-SMP version,
> and I found that it's pretty much all of them, the odd ones being just sparc32
> and csky, which use asm-generic/futex.h but do have an SMP option,
> as well as xtensa
>
> I would guess that for csky, this is a mistake, as the architecture is fairly
> new and should be able to implement it. Not sure about sparc32.
The c610, c807, c810 don't support SMP, so futex_cmpxchg_enabled = 1
with asm-generic's implementation.
For c860, there is no HAVE_FUTEX_CMPXCHG and cmpxchg_inatomic/inuser
implementation, so futex_cmpxchg_enabled = 0.
Thx for point it out, we'll implement cmpxchg_inatomic/inuser for C860
and still use asm-generic for non-smp CPUs:
diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig
index a2189c0..e968c58 100644
--- a/arch/csky/Kconfig
+++ b/arch/csky/Kconfig
@@ -49,6 +49,7 @@ config CSKY
select HAVE_FUNCTION_TRACER
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_FUNCTION_ERROR_INJECTION
+ select HAVE_FUTEX_CMPXCHG if FUTEX && SMP
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_LZO
diff --git a/arch/csky/include/asm/futex.h b/arch/csky/include/asm/futex.h
new file mode 100644
index ..29275e8
--- /dev/null
+++ b/arch/csky/include/asm/futex.h
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __ASM_CSKY_FUTEX_H
+#define __ASM_CSKY_FUTEX_H
+
+#ifndef CONFIG_SMP
+#include
+#else
+#include
+#include
+#include
+
+static inline int
+arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
+{
+ int oldval = 0, ret = 0;
+
+ if (!access_ok(uaddr, sizeof(u32)))
+ return -EFAULT;
+
+ <...>
+
+ return ret;
+}
+
+static inline int
+futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
+ u32 oldval, u32 newval)
+{
+ int ret = 0;
+ u32 val;
+ uintptr_t tmp;
+
+ if (!access_ok(uaddr, sizeof(u32)))
+ return -EFAULT;
+
+ <...>
+
+ return ret;
+}
+#endif
+#endif /* __ASM_CSKY_FUTEX_H */
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
Re: [PATCH 1/2] usb: cdnsp: Fixes for sparse warnings
On 20-12-15 05:27:38, Pawel Laszczak wrote: > > > > > >On 20-12-14 13:03:44, Pawel Laszczak wrote: > >> Patch fixes all sparse warnings in cdsnp driver. > >> > >> It fixes the following warnings: > >> cdnsp-ring.c:1441: warning: incorrect type in assignment > >> cdnsp-ring.c:1444: warning: restricted __le32 degrades to integer > >> cdnsp-ring.c:2200: warning: dubious: x | !y > >> cdnsp-gadget.c:501: warning: incorrect type in assignment > >> cdnsp-gadget.c:504: warning: restricted __le32 degrades to integer > >> cdnsp-gadget.c:507: warning: restricted __le32 degrades to integer > >> cdnsp-gadget.c:508: warning: restricted __le32 degrades to integer > >> cdnsp-gadget.c:509: warning: invalid assignment: |= > >> cdnsp-gadget.c:510: warning: cast from restricted __le32 > >> cdnsp-gadget.c:558: warning: incorrect type in assignment > >> cdnsp-gadget.c:561: warning: restricted __le32 degrades to integer > >> cdnsp-gadget.c:570: warning: restricted __le32 degrades to integer > >> cdnsp-gadget.c:1571: warning: incorrect type in argument 1 > >> cdnsp-gadget.c:1602: warning: restricted __le32 degrades to integer > >> cdnsp-gadget.c:1760: warning: incorrect type in assignment > >> cdnsp-gadget.c:1762: warning: incorrect type in assignment > >> cdnsp-gadget.c:1763: warning: incorrect type in assignment > >> cdnsp-gadget.c:1764: warning: incorrect type in assignment > >> cdnsp-gadget.c:1765: warning: incorrect type in assignment > >> cdnsp-gadget.c:1766: warning: incorrect type in assignment > >> cdnsp-gadget.c:1767: warning: incorrect type in assignment > >> cdnsp-gadget.c:458: warning: cast truncates bits from constant value > >> (07ff becomes 7ff) > >> cdnsp-gadget.c:666: warning: cast truncates bits from constant value > >> (07ff becomes 7ff) > >> cdnsp-mem.c:762: warning: incorrect type in assignment > >> cdnsp-mem.c:763: warning: incorrect type in assignment > >> cdnsp-mem.c:928: warning: cast from restricted __le16 > >> cdnsp-mem.c:1187: warning: incorrect type in assignment > >> cdnsp-mem.c:1191: warning: incorrect type in assignment > >> cdnsp-ep0.c:142: warning: incorrect type in assignment > >> cdnsp-ep0.c:144: warning: restricted __le32 degrades to integer > >> cdnsp-ep0.c:147: warning: restricted __le32 degrades to integer > >> cdnsp-ep0.c:148: warning: restricted __le32 degrades to integer > >> cdnsp-ep0.c:179: warning: incorrect type in argument 1 > >> cdnsp-ep0.c:311: warning: incorrect type in argument 1 > >> cdnsp-ep0.c:469: warning: incorrect type in assignment > >> cdnsp-trace.h:611:1: warning: cast from restricted __le32 > >> > >> Signed-off-by: Pawel Laszczak > >> Reported-by: kernel test robot > > > >Hi Pawel, > > > >The Reported-by tag should be above your Sob tag, I will change it. > >Except the patch reported build error by kernel test robot, I will apply > >your other four patches after finishing the compile test. > > > >Peter > > Hi Peter, > > I'm going to fix the "usb: cdns3: Adds missing __iomem markers" today. > I haven't seen any issue on ARCH=parisc. Maybe it's some specific riscv arch > issue. > > I believe that: > [auto build test WARNING on next-20201211] > [cannot apply to peter.chen-usb/ci-for-usb-next v5.10 v5.10-rc7 v5.10-rc6 > v5.10] > > is not the problem. I based on peter.chen-usb/for-usb-next. > > Also I can't open the url from kernel test robot report. > Maybe there is some temporary issue with server. > Thanks for checking it, I have already pushed your other four patches. Besides, there is still a build error issue for new cdns3 driver. https://www.spinics.net/lists/linux-usb/msg206073.html Peter > Thanks, > Pawel > > >> --- > >> drivers/usb/cdns3/cdnsp-debug.h | 2 +- > >> drivers/usb/cdns3/cdnsp-ep0.c| 13 ++--- > >> drivers/usb/cdns3/cdnsp-gadget.c | 24 +--- > >> drivers/usb/cdns3/cdnsp-gadget.h | 13 +++-- > >> drivers/usb/cdns3/cdnsp-mem.c| 11 ++- > >> drivers/usb/cdns3/cdnsp-ring.c | 4 ++-- > >> drivers/usb/cdns3/cdnsp-trace.h | 2 +- > >> 7 files changed, 32 insertions(+), 37 deletions(-) > >> > >> diff --git a/drivers/usb/cdns3/cdnsp-debug.h > >> b/drivers/usb/cdns3/cdnsp-debug.h > >> index d6345d4d2911..a8776df2d4e0 100644 > >> --- a/drivers/usb/cdns3/cdnsp-debug.h > >> +++ b/drivers/usb/cdns3/cdnsp-debug.h > >> @@ -414,7 +414,7 @@ static inline const char > >> *cdnsp_decode_slot_context(u32 info, u32 info2, > >>s = "UNKNOWN speed"; > >>} > >> > >> - ret = sprintf(str, "%s Ctx Entries %ld", > >> + ret = sprintf(str, "%s Ctx Entries %d", > >> s, (info & LAST_CTX_MASK) >> 27); > >> > >>ret += sprintf(str + ret, " [Intr %ld] Addr %ld State %s", > >> diff --git a/drivers/usb/cdns3/cdnsp-ep0.c b/drivers/usb/cdns3/cdnsp-ep0.c > >> index d55b59ed7381..e2b1bcb3f80e 100644 > >> --- a/drivers/usb/cdns3/cdnsp-ep0.c > >> +++ b/drivers/usb/cdns3/cdnsp-ep0.c > >> @@ -137,10 +137,8 @@
Re: [PATCH] x86/sgx: Synchronize encl->srcu in sgx_encl_release().
On Tue, Dec 15, 2020 at 07:56:01AM +0200, Jarkko Sakkinen wrote:
> On Mon, Dec 14, 2020 at 11:01:32AM -0800, Sean Christopherson wrote:
> > On Fri, Dec 11, 2020, Jarkko Sakkinen wrote:
> > > Each sgx_mmun_notifier_release() starts a grace period, which means that
> >
> > Should be sgx_mmu_notifier_release(), here and in the comment.
>
> Thanks.
>
> > > one extra synchronize_rcu() in sgx_encl_release(). Add it there.
> > >
> > > sgx_release() has the loop that drains the list but with bad luck the
> > > entry is already gone from the list before that loop processes it.
> >
> > Why not include the actual analysis that "proves" the bug? The splat that
> > Haitao reported would also be useful info.
>
> True. I can include a snippet of dmesg to the commit message.
>
> > > Fixes: 1728ab54b4be ("x86/sgx: Add a page reclaimer")
> > > Cc: Borislav Petkov
> > > Cc: Dave Hansen
> > > Reported-by: Sean Christopherson
> >
> > Haitao reported the bug, and for all intents and purposes provided the fix.
> > I
> > just did the analysis to verify that there was a legitimate bug and that the
> > synchronization in sgx_encl_release() was indeed necessary.
>
> Good and valid point. The way I see it, the tags should be:
>
> Reported-by: Haitao Huang
> Suggested-by: Sean Christopherson
>
> Haitao pointed out the bug but from your analysis I could resolve that
> this is the fix to implement, and was able to write the long
> description for the commit.
>
> Does this make sense to you?
I'm sending v2 next week (this week on vacation).
/Jarkko
Re: [PATCH] usb: cdns3: Adds missing __iomem markers
On 20-12-14 23:35:56, kernel test robot wrote: > Hi Pawel, > > I love your patch! Perhaps something to improve: > > [auto build test WARNING on next-20201211] > [cannot apply to peter.chen-usb/ci-for-usb-next v5.10 v5.10-rc7 v5.10-rc6 > v5.10] Sorry, I changed the branch name to reflect the branch does not only queue chipidea USB patches. next branch: for-usb-next fixes branch: for-usb-fixes Peter > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit-scm.com%2Fdocs%2Fgit-format-patchdata=04%7C01%7Cpeter.chen%40nxp.com%7C6ce79474794448ae12b008d8a045f9ce%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637435572341553421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Cy3huYNzWiJ57OKmzmaleCT14gcFr8RyYDnqTfZWNG4%3Dreserved=0] > > url: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2F0day-ci%2Flinux%2Fcommits%2FPawel-Laszczak%2Fusb-cdns3-Adds-missing-__iomem-markers%2F20201214-205353data=04%7C01%7Cpeter.chen%40nxp.com%7C6ce79474794448ae12b008d8a045f9ce%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637435572341553421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=x5XoDUUskeGteTFaPjgS24Hrbb712XqMqaIkqwXWu14%3Dreserved=0 > base:3cc2bd440f2171f093b3a8480a4b54d8c270ed38 > config: riscv-allmodconfig (attached as .config) > compiler: riscv64-linux-gcc (GCC) 9.3.0 > reproduce (this is a W=1 build): > wget > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintel%2Flkp-tests%2Fmaster%2Fsbin%2Fmake.crossdata=04%7C01%7Cpeter.chen%40nxp.com%7C6ce79474794448ae12b008d8a045f9ce%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637435572341553421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=jAavg0T3itnjkbHXADvePHHgtYeqiVTBt%2BoatHT0VHU%3Dreserved=0 > -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2F0day-ci%2Flinux%2Fcommit%2F315bfcf1e0604de6ecfc1856cf5820876390f16cdata=04%7C01%7Cpeter.chen%40nxp.com%7C6ce79474794448ae12b008d8a045f9ce%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637435572341553421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=SQ75IXxfld6HMRIFkZ%2F8Z4YqxnFP%2F%2BZ%2BsYZIycNeO%2FA%3Dreserved=0 > git remote add linux-review > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2F0day-ci%2Flinuxdata=04%7C01%7Cpeter.chen%40nxp.com%7C6ce79474794448ae12b008d8a045f9ce%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637435572341553421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ZVS4723WbEO03hbsLXJ%2B%2FmB5EZElulY7lAsMEMatiko%3Dreserved=0 > git fetch --no-tags linux-review > Pawel-Laszczak/usb-cdns3-Adds-missing-__iomem-markers/20201214-205353 > git checkout 315bfcf1e0604de6ecfc1856cf5820876390f16c > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross > ARCH=riscv > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All warnings (new ones prefixed by >>): > >In file included from arch/riscv/include/asm/io.h:23, > from include/linux/io.h:13, > from include/linux/irq.h:20, > from include/asm-generic/hardirq.h:17, > from ./arch/riscv/include/generated/asm/hardirq.h:1, > from include/linux/hardirq.h:10, > from include/linux/interrupt.h:11, > from drivers/usb/cdns3/drd.c:13: >drivers/usb/cdns3/drd.c: In function 'cdns_otg_disable_irq': >drivers/usb/cdns3/drd.c:159:31: error: dereferencing pointer to incomplete > type 'struct cdns_otg_irq_reg' > 159 | writel(0, >otg_irq_regs->ien); > | ^~ >arch/riscv/include/asm/mmio.h:93:76: note: in definition of macro > 'writel_cpu' > 93 | #define writel_cpu(v, c) ((void)__raw_writel((__force > u32)cpu_to_le32(v), (c))) > | > ^ >drivers/usb/cdns3/drd.c:159:2: note: in expansion of macro 'writel' > 159 | writel(0, >otg_irq_regs->ien); > | ^~ >drivers/usb/cdns3/drd.c: In function 'cdns_drd_init': >drivers/usb/cdns3/drd.c:409:22: error: assignment to
Re: [PATCH v4 2/3] scsi: ufs: Clean up ufshcd_exit_clk_scaling/gating()
On Sun, 2020-12-13 at 08:31 -0800, Can Guo wrote: > ufshcd_hba_exit() is always called after ufshcd_exit_clk_scaling() and > ufshcd_exit_clk_gating(), so move ufshcd_exit_clk_scaling/gating() to > ufshcd_hba_exit(). > > Signed-off-by: Can Guo Reviewed-by: Stanley Chu
Re: [PATCH] x86/sgx: Synchronize encl->srcu in sgx_encl_release().
On Mon, Dec 14, 2020 at 11:01:32AM -0800, Sean Christopherson wrote:
> On Fri, Dec 11, 2020, Jarkko Sakkinen wrote:
> > Each sgx_mmun_notifier_release() starts a grace period, which means that
>
> Should be sgx_mmu_notifier_release(), here and in the comment.
Thanks.
> > one extra synchronize_rcu() in sgx_encl_release(). Add it there.
> >
> > sgx_release() has the loop that drains the list but with bad luck the
> > entry is already gone from the list before that loop processes it.
>
> Why not include the actual analysis that "proves" the bug? The splat that
> Haitao reported would also be useful info.
True. I can include a snippet of dmesg to the commit message.
> > Fixes: 1728ab54b4be ("x86/sgx: Add a page reclaimer")
> > Cc: Borislav Petkov
> > Cc: Dave Hansen
> > Reported-by: Sean Christopherson
>
> Haitao reported the bug, and for all intents and purposes provided the fix. I
> just did the analysis to verify that there was a legitimate bug and that the
> synchronization in sgx_encl_release() was indeed necessary.
Good and valid point. The way I see it, the tags should be:
Reported-by: Haitao Huang
Suggested-by: Sean Christopherson
Haitao pointed out the bug but from your analysis I could resolve that
this is the fix to implement, and was able to write the long
description for the commit.
Does this make sense to you?
/Jarkko
Re: [PATCH] Input: raydium_ts_i2c: Do not send zero length
Hi Jeffrey,
On Tue, Dec 15, 2020 at 11:21:06AM +0800, jeffrey.lin wrote:
> Add default write command package to prevent i2c quirk error of zero
> data length as Raydium touch firmware update is executed.
>
> Signed-off-by: jeffrey.lin
> BUG=b:174207906
> TEST=Successfully tested update Raydium touch firmware over 100 times
> Change-Id: I311b0d26d7642bb800547cd0e87013be17cb7e1b
> ---
> drivers/input/touchscreen/raydium_i2c_ts.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/raydium_i2c_ts.c
> b/drivers/input/touchscreen/raydium_i2c_ts.c
> index 603a948460d64..4d2d22a869773 100644
> --- a/drivers/input/touchscreen/raydium_i2c_ts.c
> +++ b/drivers/input/touchscreen/raydium_i2c_ts.c
> @@ -445,6 +445,7 @@ static int raydium_i2c_write_object(struct i2c_client
> *client,
> enum raydium_bl_ack state)
> {
> int error;
> + static const u8 cmd[] = { 0xFF, 0x39 };
>
> error = raydium_i2c_send(client, RM_CMD_BOOT_WRT, data, len);
> if (error) {
> @@ -453,7 +454,7 @@ static int raydium_i2c_write_object(struct i2c_client
> *client,
> return error;
> }
>
> - error = raydium_i2c_send(client, RM_CMD_BOOT_ACK, NULL, 0);
> + error = raydium_i2c_send(client, RM_CMD_BOOT_ACK, cmd, sizeof(cmd));
Is this supported by all firmwares?
> if (error) {
> dev_err(>dev, "Ack obj command failed: %d\n", error);
> return error;
> --
> 2.26.2
>
Thanks.
--
Dmitry
[PATCH v4 0/3] add custom hinge sensor support
Here we register one iio device with three channels which present angle for hinge, keyboard and screen. This driver works on devices with Intel integrated sensor hub, where hinge sensor is presented using a custom sensor usage id. Here the angle is presented in degrees, which is converted to radians. Changes since v3: - hid-sensor-custom: remove sensor_inst::custom_pdev_exposed. - hid-sensor-custom: use static buf, w_buf to avoid using goto in get_known_custom_sensor_index. - hid-sensor-custom-intel-hinge: use devm_ prefix function instead. - sysfs-bus-iio: put in_anglY_raw together with in_angl_raw. Changes since v2: - use 1 iio device instead of 3 for hinge sensor. - use indexed channel instead of modified channel and added channel labels. - remove 2,3 patch in last version, add a document patch to describe the hinge channels. - hid-sensor-custom: use meaningful return value in get_known_custom_sensor_index and checked in call side. - hid-sensor-ids.h: use HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE(x) to define custom sensor value. Changes since v1: - fixed errors reported by lkp Ye Xiang (3): HID: hid-sensor-custom: Add custom sensor iio support iio: hid-sensors: Add hinge sensor driver iio:Documentation: Add documentation for hinge sensor channels Documentation/ABI/testing/sysfs-bus-iio | 11 + drivers/hid/hid-sensor-custom.c | 143 +++ .../hid-sensors/hid-sensor-attributes.c | 2 + drivers/iio/position/Kconfig | 16 + drivers/iio/position/Makefile | 1 + .../position/hid-sensor-custom-intel-hinge.c | 391 ++ include/linux/hid-sensor-ids.h| 14 + 7 files changed, 578 insertions(+) create mode 100644 drivers/iio/position/hid-sensor-custom-intel-hinge.c -- 2.17.1
Re: [PATCH 00/10] workqueue: break affinity initiatively
On Tue, Dec 15, 2020 at 1:36 AM Peter Zijlstra wrote:
>
> On Mon, Dec 14, 2020 at 11:54:47PM +0800, Lai Jiangshan wrote:
> > From: Lai Jiangshan
> >
> > 06249738a41a ("workqueue: Manually break affinity on hotplug")
> > said that scheduler will not force break affinity for us.
> >
> > But workqueue highly depends on the old behavior. Many parts of the codes
> > relies on it, 06249738a41a ("workqueue: Manually break affinity on hotplug")
> > is not enough to change it, and the commit has flaws in itself too.
> >
> > We need to thoroughly update the way workqueue handles affinity
> > in cpu hot[un]plug, what is this patchset intends to do and
> > replace the Valentin Schneider's patch [1].
>
> So the actual problem is with per-cpu kthreads, the new assumption is
> that hot-un-plug will make all per-cpu kthreads for the dying CPU go
> away.
Hello, Peter
"new assumption" is all needed to be aligned. I haven't read the code.
I thought I understood to some extent which is enough for me to know
that workqueue does violate that.
Workqueue does not break affinity for all per-cpu kthreads in several
cases such as hot-un-plug and workers detaching from pool (those workers
will not be searchable from pools and should be handled alike to hot-un-plug).
But workqueue has not only per-cpu kthreads but also per-node threads.
And per-node threads may be bound to multiple CPUs or may be bound to
a single CPU. I don't know how the scheduler distinguishes all these
different cases under the "new assumption". But at least workqueue
handle these different cases at the same few places. Since workqueue
have to "break affinity" for per-cpu kthreads, it can also "break affinity"
for other cases. Making workqueue totally do not rely on scheduler's
work to "break affinity" is worth doing since we have to do it for the
most parts.
I haven't read the code about "new assumption", if possible, I'll first
try to find out how will scheduler handle these cases:
If a per-node thread has only cpu 4, and when it goes down, does
workqueue need to "break affinity" for it?
If a per-node thread has only cpu 41,42, and when both go down, does
workqueue need to "break affinity" for it?
Thanks
Lai
>
> Workqueues violated that. I fixed the obvious site, and Valentin's patch
> avoids workqueues from quickly creating new ones while we're not
> looking.
>
> What other problems did you find?
[PATCH v4 3/3] iio:Documentation: Add documentation for hinge sensor channels
Add channel description for hinge sensor, including channel label attribute and raw data description. Signed-off-by: Ye Xiang --- Documentation/ABI/testing/sysfs-bus-iio | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index df42bed09f25..5c0a84c50d43 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -198,6 +198,7 @@ Description: Units after application of scale and offset are m/s^2. What: /sys/bus/iio/devices/iio:deviceX/in_angl_raw +What: /sys/bus/iio/devices/iio:deviceX/in_anglY_raw KernelVersion: 4.17 Contact: linux-...@vger.kernel.org Description: @@ -1802,3 +1803,13 @@ Contact: linux-...@vger.kernel.org Description: Unscaled light intensity according to CIE 1931/DIN 5033 color space. Units after application of scale are nano nanowatts per square meter. + +What: /sys/bus/iio/devices/iio:deviceX/in_anglY_label +KernelVersion: 5.12 +Contact: linux-...@vger.kernel.org +Description: + Optional symbolic label for channel Y. + For Intel hid hinge sensor, the label values are: + hinge, keyboard, screen. It means the three channels + each correspond respectively to hinge angle, keyboard angle, + and screen angle. -- 2.17.1
[PATCH v4 2/3] iio: hid-sensors: Add hinge sensor driver
The Hinge sensor is a common custom sensor on laptops. It calculates
the angle between the lid (screen) and the base (keyboard). In addition,
it also exposes screen and the keyboard angles with respect to the
ground. Applications can easily get laptop's status in space through
this sensor, in order to display appropriate user interface.
Signed-off-by: Ye Xiang
---
.../hid-sensors/hid-sensor-attributes.c | 2 +
drivers/iio/position/Kconfig | 16 +
drivers/iio/position/Makefile | 1 +
.../position/hid-sensor-custom-intel-hinge.c | 391 ++
4 files changed, 410 insertions(+)
create mode 100644 drivers/iio/position/hid-sensor-custom-intel-hinge.c
diff --git a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
index 442ff787f7af..5b822a4298a0 100644
--- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
+++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
@@ -71,6 +71,8 @@ static struct {
{HID_USAGE_SENSOR_TEMPERATURE, HID_USAGE_SENSOR_UNITS_DEGREES, 1000, 0},
{HID_USAGE_SENSOR_HUMIDITY, 0, 1000, 0},
+ {HID_USAGE_SENSOR_HINGE, 0, 0, 17453293},
+ {HID_USAGE_SENSOR_HINGE, HID_USAGE_SENSOR_UNITS_DEGREES, 0, 17453293},
};
static void simple_div(int dividend, int divisor, int *whole,
diff --git a/drivers/iio/position/Kconfig b/drivers/iio/position/Kconfig
index eda67f008c5b..1576a6380b53 100644
--- a/drivers/iio/position/Kconfig
+++ b/drivers/iio/position/Kconfig
@@ -16,4 +16,20 @@ config IQS624_POS
To compile this driver as a module, choose M here: the module
will be called iqs624-pos.
+config HID_SENSOR_CUSTOM_INTEL_HINGE
+ depends on HID_SENSOR_HUB
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ select HID_SENSOR_IIO_COMMON
+ select HID_SENSOR_IIO_TRIGGER
+ tristate "HID Hinge"
+ help
+ This sensor present three angles, hinge angel, screen angles
+ and keyboard angle respect to horizon (ground).
+ Say yes here to build support for the HID custom
+ intel hinge sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called hid-sensor-custom-hinge.
+
endmenu
diff --git a/drivers/iio/position/Makefile b/drivers/iio/position/Makefile
index 3cbe7a734352..d70902f2979d 100644
--- a/drivers/iio/position/Makefile
+++ b/drivers/iio/position/Makefile
@@ -4,4 +4,5 @@
# When adding new entries keep the list in alphabetical order
+obj-$(CONFIG_HID_SENSOR_CUSTOM_INTEL_HINGE) += hid-sensor-custom-intel-hinge.o
obj-$(CONFIG_IQS624_POS) += iqs624-pos.o
diff --git a/drivers/iio/position/hid-sensor-custom-intel-hinge.c
b/drivers/iio/position/hid-sensor-custom-intel-hinge.c
new file mode 100644
index ..24cf31c039a3
--- /dev/null
+++ b/drivers/iio/position/hid-sensor-custom-intel-hinge.c
@@ -0,0 +1,391 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * HID Sensors Driver
+ * Copyright (c) 2020, Intel Corporation.
+ */
+#include
+#include
+#include
+#include
+
+#include "../common/hid-sensors/hid-sensor-trigger.h"
+
+enum hinge_channel {
+ CHANNEL_SCAN_INDEX_HINGE_ANGLE,
+ CHANNEL_SCAN_INDEX_SCREEN_ANGLE,
+ CHANNEL_SCAN_INDEX_KEYBOARD_ANGLE,
+ CHANNEL_SCAN_INDEX_MAX,
+};
+
+#define CHANNEL_SCAN_INDEX_TIMESTAMP CHANNEL_SCAN_INDEX_MAX
+
+static const u32 hinge_addresses[CHANNEL_SCAN_INDEX_MAX] = {
+ HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE(1),
+ HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE(2),
+ HID_USAGE_SENSOR_DATA_FIELD_CUSTOM_VALUE(3)
+};
+
+static const char *const hinge_labels[CHANNEL_SCAN_INDEX_MAX] = { "hinge",
+ "screen",
+ "keyboard" };
+
+struct hinge_state {
+ struct iio_dev *indio_dev;
+ struct hid_sensor_hub_attribute_info hinge[CHANNEL_SCAN_INDEX_MAX];
+ struct hid_sensor_hub_callbacks callbacks;
+ struct hid_sensor_common common_attributes;
+ const char *labels[CHANNEL_SCAN_INDEX_MAX];
+ struct {
+ u32 hinge_val[3];
+ u64 timestamp __aligned(8);
+ } scan;
+
+ int scale_pre_decml;
+ int scale_post_decml;
+ int scale_precision;
+ int value_offset;
+ u64 timestamp;
+};
+
+/* Channel definitions */
+static const struct iio_chan_spec hinge_channels[] = {
+ {
+ .type = IIO_ANGL,
+ .indexed = 1,
+ .channel = 0,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+ .info_mask_shared_by_type =
+ BIT(IIO_CHAN_INFO_OFFSET) | BIT(IIO_CHAN_INFO_SCALE) |
+ BIT(IIO_CHAN_INFO_SAMP_FREQ) |
BIT(IIO_CHAN_INFO_HYSTERESIS),
+ .scan_index = CHANNEL_SCAN_INDEX_HINGE_ANGLE,
+ .scan_type = {
+
[PATCH v4 1/3] HID: hid-sensor-custom: Add custom sensor iio support
Currently custom sensors properties are not decoded and it is up to
user space to interpret.
Some manufacturers already standardized the meaning of some custom sensors.
They can be presented as a proper IIO sensor. We can identify these sensors
based on manufacturer and serial number property in the report.
This change is identifying hinge sensor when the manufacturer is "INTEL".
This creates a platform device so that a sensor driver can be loaded to
process these sensors.
Signed-off-by: Ye Xiang
---
drivers/hid/hid-sensor-custom.c | 143
include/linux/hid-sensor-ids.h | 14
2 files changed, 157 insertions(+)
diff --git a/drivers/hid/hid-sensor-custom.c b/drivers/hid/hid-sensor-custom.c
index 4d25577a8573..2628bc53ed80 100644
--- a/drivers/hid/hid-sensor-custom.c
+++ b/drivers/hid/hid-sensor-custom.c
@@ -4,6 +4,7 @@
* Copyright (c) 2015, Intel Corporation.
*/
+#include
#include
#include
#include
@@ -21,6 +22,7 @@
#define HID_CUSTOM_TOTAL_ATTRS (HID_CUSTOM_MAX_CORE_ATTRS + 1)
#define HID_CUSTOM_FIFO_SIZE 4096
#define HID_CUSTOM_MAX_FEATURE_BYTES 64
+#define HID_SENSOR_USAGE_LENGTH (4 + 1)
struct hid_sensor_custom_field {
int report_id;
@@ -50,6 +52,7 @@ struct hid_sensor_custom {
struct kfifo data_fifo;
unsigned long misc_opened;
wait_queue_head_t wait;
+ struct platform_device *custom_pdev;
};
/* Header for each sample to user space via dev interface */
@@ -746,11 +749,130 @@ static void hid_sensor_custom_dev_if_remove(struct
hid_sensor_custom
}
+/* luid defined in FW (e.g. ISH). Maybe used to identify sensor. */
+static const char *const known_sensor_luid[] = { "020B" };
+
+static int get_luid_table_index(unsigned char *usage_str)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(known_sensor_luid); i++) {
+ if (!strncmp(usage_str, known_sensor_luid[i],
+strlen(known_sensor_luid[i])))
+ return i;
+ }
+
+ return -ENODEV;
+}
+
+static int get_known_custom_sensor_index(struct hid_sensor_hub_device *hsdev)
+{
+ struct hid_sensor_hub_attribute_info sensor_manufacturer = { 0 };
+ struct hid_sensor_hub_attribute_info sensor_luid_info = { 0 };
+ int report_size;
+ int ret;
+ static u16 w_buf[HID_CUSTOM_MAX_FEATURE_BYTES];
+ static char buf[HID_CUSTOM_MAX_FEATURE_BYTES];
+ int i;
+
+ memset(w_buf, 0, sizeof(w_buf));
+ memset(buf, 0, sizeof(buf));
+
+ /* get manufacturer info */
+ ret = sensor_hub_input_get_attribute_info(hsdev,
+ HID_FEATURE_REPORT, hsdev->usage,
+ HID_USAGE_SENSOR_PROP_MANUFACTURER,
_manufacturer);
+ if (ret < 0)
+ return ret;
+
+ report_size =
+ sensor_hub_get_feature(hsdev, sensor_manufacturer.report_id,
+ sensor_manufacturer.index, sizeof(w_buf),
+ w_buf);
+ if (report_size <= 0) {
+ hid_err(hsdev->hdev,
+ "Failed to get sensor manufacturer info %d\n",
+ report_size);
+ return -ENODEV;
+ }
+
+ /* convert from wide char to char */
+ for (i = 0; i < ARRAY_SIZE(buf) - 1 && w_buf[i]; i++)
+ buf[i] = (char)w_buf[i];
+
+ /* ensure it's ISH sensor */
+ if (strncmp(buf, "INTEL", strlen("INTEL")))
+ return -ENODEV;
+
+ memset(w_buf, 0, sizeof(w_buf));
+ memset(buf, 0, sizeof(buf));
+
+ /* get real usage id */
+ ret = sensor_hub_input_get_attribute_info(hsdev,
+ HID_FEATURE_REPORT, hsdev->usage,
+ HID_USAGE_SENSOR_PROP_SERIAL_NUM, _luid_info);
+ if (ret < 0)
+ return ret;
+
+ report_size = sensor_hub_get_feature(hsdev, sensor_luid_info.report_id,
+sensor_luid_info.index,
sizeof(w_buf),
+w_buf);
+ if (report_size <= 0) {
+ hid_err(hsdev->hdev, "Failed to get real usage info %d\n",
+ report_size);
+ return -ENODEV;
+ }
+
+ /* convert from wide char to char */
+ for (i = 0; i < ARRAY_SIZE(buf) - 1 && w_buf[i]; i++)
+ buf[i] = (char)w_buf[i];
+
+ if (strlen(buf) != strlen(known_sensor_luid[0]) + 5) {
+ hid_err(hsdev->hdev,
+ "%s luid length not match %zu != (%zu + 5)\n", __func__,
+ strlen(buf), strlen(known_sensor_luid[0]));
+ return -ENODEV;
+ }
+
+ /* get table index with luid (not matching 'LUID: ' in luid) */
+ return get_luid_table_index([5]);
+}
+
+static struct platform_device *
+hid_sensor_register_platform_device(struct platform_device *pdev,
+
Re: [PATCH v4 1/3] scsi: ufs: Protect some contexts from unexpected clock scaling
Hi Can,
On Sun, 2020-12-13 at 08:31 -0800, Can Guo wrote:
> In contexts like suspend, shutdown and error handling, we need to suspend
> devfreq to make sure these contexts won't be disturbed by clock scaling.
> However, suspending devfreq is not enough since users can still trigger a
> clock scaling by manipulating the sysfs node clkscale_enable and devfreq
> sysfs nodes like min/max_freq and governor. Add one more flag in struct
> clk_scaling such that these contexts can prevent clock scaling from being
> invoked through above sysfs nodes.
>
> Signed-off-by: Can Guo
> ---
> drivers/scsi/ufs/ufshcd.c | 83
> +++
> drivers/scsi/ufs/ufshcd.h | 2 ++
> 2 files changed, 57 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 0c148fc..4ccdd2b 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -1147,12 +1147,22 @@ static int ufshcd_clock_scaling_prepare(struct
> ufs_hba *hba)
>*/
> ufshcd_scsi_block_requests(hba);
> down_write(>clk_scaling_lock);
> - if (ufshcd_wait_for_doorbell_clr(hba, DOORBELL_CLR_TOUT_US)) {
> +
> + if (!hba->clk_scaling.is_allowed)
> + ret = -EAGAIN;
> + else if (ufshcd_wait_for_doorbell_clr(hba, DOORBELL_CLR_TOUT_US))
> ret = -EBUSY;
> +
> + if (ret) {
> up_write(>clk_scaling_lock);
> ufshcd_scsi_unblock_requests(hba);
> + goto out;
> }
>
> + /* let's not get into low power until clock scaling is completed */
> + ufshcd_hold(hba, false);
> +
> +out:
> return ret;
> }
>
> @@ -1160,6 +1170,7 @@ static void ufshcd_clock_scaling_unprepare(struct
> ufs_hba *hba)
> {
> up_write(>clk_scaling_lock);
> ufshcd_scsi_unblock_requests(hba);
> + ufshcd_release(hba);
> }
>
> /**
> @@ -1175,12 +1186,9 @@ static int ufshcd_devfreq_scale(struct ufs_hba *hba,
> bool scale_up)
> {
> int ret = 0;
>
> - /* let's not get into low power until clock scaling is completed */
> - ufshcd_hold(hba, false);
> -
> ret = ufshcd_clock_scaling_prepare(hba);
> if (ret)
> - goto out;
> + return ret;
>
> /* scale down the gear before scaling down clocks */
> if (!scale_up) {
> @@ -1212,8 +1220,6 @@ static int ufshcd_devfreq_scale(struct ufs_hba *hba,
> bool scale_up)
>
> out_unprepare:
> ufshcd_clock_scaling_unprepare(hba);
> -out:
> - ufshcd_release(hba);
> return ret;
> }
>
> @@ -1487,7 +1493,7 @@ static ssize_t ufshcd_clkscale_enable_show(struct
> device *dev,
> {
> struct ufs_hba *hba = dev_get_drvdata(dev);
>
> - return snprintf(buf, PAGE_SIZE, "%d\n", hba->clk_scaling.is_allowed);
> + return snprintf(buf, PAGE_SIZE, "%d\n", hba->clk_scaling.is_enabled);
> }
>
> static ssize_t ufshcd_clkscale_enable_store(struct device *dev,
> @@ -1496,12 +1502,20 @@ static ssize_t ufshcd_clkscale_enable_store(struct
> device *dev,
> struct ufs_hba *hba = dev_get_drvdata(dev);
> u32 value;
> int err;
> + unsigned long flags;
> + bool update = true;
>
> if (kstrtou32(buf, 0, ))
> return -EINVAL;
>
> value = !!value;
> - if (value == hba->clk_scaling.is_allowed)
> + spin_lock_irqsave(hba->host->host_lock, flags);
> + if (value == hba->clk_scaling.is_enabled)
> + update = false;
> + else
> + hba->clk_scaling.is_enabled = value;
> + spin_unlock_irqrestore(hba->host->host_lock, flags);
> + if (!update)
> goto out;
>
> pm_runtime_get_sync(hba->dev);
> @@ -1510,8 +1524,6 @@ static ssize_t ufshcd_clkscale_enable_store(struct
> device *dev,
> cancel_work_sync(>clk_scaling.suspend_work);
> cancel_work_sync(>clk_scaling.resume_work);
>
> - hba->clk_scaling.is_allowed = value;
> -
> if (value) {
> ufshcd_resume_clkscaling(hba);
> } else {
> @@ -1845,8 +1857,6 @@ static void ufshcd_init_clk_scaling(struct ufs_hba *hba)
> snprintf(wq_name, sizeof(wq_name), "ufs_clkscaling_%d",
>hba->host->host_no);
> hba->clk_scaling.workq = create_singlethread_workqueue(wq_name);
> -
> - ufshcd_clkscaling_init_sysfs(hba);
> }
>
> static void ufshcd_exit_clk_scaling(struct ufs_hba *hba)
> @@ -1854,6 +1864,8 @@ static void ufshcd_exit_clk_scaling(struct ufs_hba *hba)
> if (!ufshcd_is_clkscaling_supported(hba))
> return;
>
> + if (hba->devfreq)
> + device_remove_file(hba->dev, >clk_scaling.enable_attr);
> destroy_workqueue(hba->clk_scaling.workq);
> ufshcd_devfreq_remove(hba);
> }
> @@ -1918,7 +1930,7 @@ static void ufshcd_clk_scaling_start_busy(struct
> ufs_hba *hba)
> if (!hba->clk_scaling.active_reqs++)
> queue_resume_work = true;
>
> - if (!hba->clk_scaling.is_allowed ||
Re: [PATCH v2] net/mlx4: Use true,false for bool variable
On Tue, 2020-12-15 at 07:18 +0200, Leon Romanovsky wrote: > On Mon, Dec 14, 2020 at 11:15:01AM -0800, Joe Perches wrote: > > I prefer revisions to single patches (as opposed to large patch series) > > in the same thread. > > It depends which side you are in that game. From the reviewer point of > view, such submission breaks flow very badly. It unfolds the already > reviewed thread, messes with the order and many more little annoying > things. This is where I disagree with you. I am a reviewer here. Not having context to be able to inspect vN -> vN+1 is made more difficult not having the original patch available and having to search history for it. Almost no one adds URL links to older submissions below the ---. Were that a standard mechanism below the --- line, then it would be OK.
Re: [LKP] Re: [sched/hotplug] 2558aacff8: will-it-scale.per_thread_ops -1.6% regression
On 12/11/2020 12:14 AM, Peter Zijlstra wrote:
On Thu, Dec 10, 2020 at 04:18:59PM +0800, kernel test robot wrote:
FYI, we noticed a -1.6% regression of will-it-scale.per_thread_ops due to
commit:
commit: 2558aacff8586699bcd248b406febb28b0a25de2 ("sched/hotplug: Ensure only
per-cpu kthreads run during hotplug")
Mooo, weird but whatever. Does the below help at all?
I test the patch, the regression reduced to -0.6%.
=
tbox_group/testcase/rootfs/kconfig/compiler/nr_task/mode/test/cpufreq_governor/ucode:
lkp-cpl-4sp1/will-it-scale/debian-10.4-x86_64-20200603.cgz/x86_64-rhel-8.3/gcc-9/100%/thread/sched_yield/performance/0x71e
commit:
565790d28b1e33ee2f77bad5348b99f6dfc366fd
2558aacff8586699bcd248b406febb28b0a25de2
4b26139b8db627a55043183614a32b0aba799d27 (this test patch)
565790d28b1e33ee 2558aacff8586699bcd248b406f 4b26139b8db627a55043183614a
--- ---
%stddev %change %stddev %change %stddev
\ |\ |\
4.011e+08-1.6% 3.945e+08-0.6% 3.989e+08
will-it-scale.144.threads
2785455-1.6%2739520-0.6%2769967
will-it-scale.per_thread_ops
4.011e+08-1.6% 3.945e+08-0.6% 3.989e+08
will-it-scale.workload
---
kernel/sched/core.c | 40 +++-
kernel/sched/sched.h | 13 +
2 files changed, 20 insertions(+), 33 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 7af80c3fce12..f80245c7f903 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3985,15 +3985,20 @@ static void do_balance_callbacks(struct rq *rq, struct
callback_head *head)
}
}
+static void balance_push(struct rq *rq);
+
+struct callback_head balance_push_callback = {
+ .next = NULL,
+ .func = (void (*)(struct callback_head *))balance_push,
+};
+
static inline struct callback_head *splice_balance_callbacks(struct rq *rq)
{
struct callback_head *head = rq->balance_callback;
lockdep_assert_held(>lock);
- if (head) {
+ if (head)
rq->balance_callback = NULL;
- rq->balance_flags &= ~BALANCE_WORK;
- }
return head;
}
@@ -4014,21 +4019,6 @@ static inline void balance_callbacks(struct rq *rq,
struct callback_head *head)
}
}
-static void balance_push(struct rq *rq);
-
-static inline void balance_switch(struct rq *rq)
-{
- if (likely(!rq->balance_flags))
- return;
-
- if (rq->balance_flags & BALANCE_PUSH) {
- balance_push(rq);
- return;
- }
-
- __balance_callbacks(rq);
-}
-
#else
static inline void __balance_callbacks(struct rq *rq)
@@ -4044,10 +4034,6 @@ static inline void balance_callbacks(struct rq *rq,
struct callback_head *head)
{
}
-static inline void balance_switch(struct rq *rq)
-{
-}
-
#endif
static inline void
@@ -4075,7 +4061,7 @@ static inline void finish_lock_switch(struct rq *rq)
* prev into current:
*/
spin_acquire(>lock.dep_map, 0, 0, _THIS_IP_);
- balance_switch(rq);
+ __balance_callbacks(rq);
raw_spin_unlock_irq(>lock);
}
@@ -7256,6 +7242,10 @@ static void balance_push(struct rq *rq)
lockdep_assert_held(>lock);
SCHED_WARN_ON(rq->cpu != smp_processor_id());
+ /*
+* Ensure the thing is persistent until balance_push_set(, on = false);
+*/
+ rq->balance_callback = _push_callback;
/*
* Both the cpu-hotplug and stop task are in this case and are
@@ -7305,9 +7295,9 @@ static void balance_push_set(int cpu, bool on)
rq_lock_irqsave(rq, );
if (on)
- rq->balance_flags |= BALANCE_PUSH;
+ rq->balance_callback = _push_callback;
else
- rq->balance_flags &= ~BALANCE_PUSH;
+ rq->balance_callback = NULL;
rq_unlock_irqrestore(rq, );
}
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index f5acb6c5ce49..12ada79d40f3 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -975,7 +975,6 @@ struct rq {
unsigned long cpu_capacity_orig;
struct callback_head *balance_callback;
- unsigned char balance_flags;
unsigned char nohz_idle_balance;
unsigned char idle_balance;
@@ -1226,6 +1225,8 @@ struct rq_flags {
#endif
};
+extern struct callback_head balance_push_callback;
+
/*
* Lockdep annotation that avoids accidental unlocks; it's like a
* sticky/continuous lockdep_assert_held().
@@ -1243,9 +1244,9 @@ static inline void rq_pin_lock(struct rq *rq, struct
rq_flags *rf)
#ifdef CONFIG_SCHED_DEBUG
rq->clock_update_flags &=
[PATCH V3 3/3] arm64: topology: Make AMUs work with modular cpufreq drivers
The AMU counters won't get used today if the cpufreq driver is built as
a module as the amu core requires everything to be ready by late init.
Fix that properly by registering for cpufreq policy notifier. Note that
the amu core don't have any cpufreq dependency after the first time
CPUFREQ_CREATE_POLICY notifier is called for all the CPUs. And so we
don't need to do anything on the CPUFREQ_REMOVE_POLICY notifier. And for
the same reason we check if the CPUs are already parsed in the beginning
of amu_fie_setup() and skip if that is true. Alternatively we can shoot
a work from there to unregister the notifier instead, but that seemed
too much instead of this simple check.
Signed-off-by: Viresh Kumar
---
V3:
- This is a new patch.
Ionela,
I don't have a way to test the AMU stuff, will it be possible for you to
give it a try ?
arch/arm64/kernel/topology.c | 88 +++-
1 file changed, 46 insertions(+), 42 deletions(-)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 57267d694495..0fc2b32ddb45 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -199,64 +199,33 @@ static int freq_inv_set_max_ratio(int cpu, u64 max_rate,
u64 ref_rate)
return 0;
}
-static inline void
-enable_policy_freq_counters(int cpu, cpumask_var_t valid_cpus)
-{
- struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
-
- if (!policy) {
- pr_debug("CPU%d: No cpufreq policy found.\n", cpu);
- return;
- }
-
- if (cpumask_subset(policy->related_cpus, valid_cpus))
- cpumask_or(amu_fie_cpus, policy->related_cpus,
- amu_fie_cpus);
-
- cpufreq_cpu_put(policy);
-}
-
static DEFINE_STATIC_KEY_FALSE(amu_fie_key);
#define amu_freq_invariant() static_branch_unlikely(_fie_key)
-static int __init init_amu_fie(void)
+static void amu_fie_setup(const struct cpumask *cpus)
{
- cpumask_var_t valid_cpus;
bool invariant;
- int ret = 0;
int cpu;
- if (!zalloc_cpumask_var(_cpus, GFP_KERNEL))
- return -ENOMEM;
-
- if (!zalloc_cpumask_var(_fie_cpus, GFP_KERNEL)) {
- ret = -ENOMEM;
- goto free_valid_mask;
- }
+ /* We are already set since the last insmod of cpufreq driver */
+ if (unlikely(cpumask_subset(cpus, amu_fie_cpus)))
+ return;
- for_each_present_cpu(cpu) {
+ for_each_cpu(cpu, cpus) {
if (!freq_counters_valid(cpu) ||
freq_inv_set_max_ratio(cpu,
cpufreq_get_hw_max_freq(cpu) * 1000,
arch_timer_get_rate()))
- continue;
-
- cpumask_set_cpu(cpu, valid_cpus);
- enable_policy_freq_counters(cpu, valid_cpus);
+ return;
}
- /* Overwrite amu_fie_cpus if all CPUs support AMU */
- if (cpumask_equal(valid_cpus, cpu_present_mask))
- cpumask_copy(amu_fie_cpus, cpu_present_mask);
-
- if (cpumask_empty(amu_fie_cpus))
- goto free_valid_mask;
+ cpumask_or(amu_fie_cpus, amu_fie_cpus, cpus);
invariant = topology_scale_freq_invariant();
/* We aren't fully invariant yet */
if (!invariant && !cpumask_equal(amu_fie_cpus, cpu_present_mask))
- goto free_valid_mask;
+ return;
static_branch_enable(_fie_key);
@@ -271,13 +240,48 @@ static int __init init_amu_fie(void)
*/
if (!invariant)
rebuild_sched_domains_energy();
+}
+
+static int init_amu_fie_callback(struct notifier_block *nb, unsigned long val,
+void *data)
+{
+ struct cpufreq_policy *policy = data;
+
+ if (val == CPUFREQ_CREATE_POLICY)
+ amu_fie_setup(policy->related_cpus);
+
+ /*
+* We don't need to handle CPUFREQ_REMOVE_POLICY event as the AMU
+* counters don't have any dependency on cpufreq driver once we have
+* initialized AMU support and enabled invariance. The AMU counters will
+* keep on working just fine in the absence of the cpufreq driver, and
+* for the CPUs for which there are no counters availalbe, the last set
+* value of freq_scale will remain valid as that is the frequency those
+* CPUs are running at.
+*/
+
+ return 0;
+}
+
+static struct notifier_block init_amu_fie_notifier = {
+ .notifier_call = init_amu_fie_callback,
+};
+
+static int __init init_amu_fie(void)
+{
+ int ret;
+
+ if (!zalloc_cpumask_var(_fie_cpus, GFP_KERNEL))
+ return -ENOMEM;
-free_valid_mask:
- free_cpumask_var(valid_cpus);
+ ret = cpufreq_register_notifier(_amu_fie_notifier,
+ CPUFREQ_POLICY_NOTIFIER);
+ if (ret)
+
[PATCH V3 2/3] arm64: topology: Reorder init_amu_fie() a bit
This patch does a couple of optimizations in init_amu_fie(), like early
exits from paths where we don't need to continue any further, avoid the
enable/disable dance, moving the calls to
topology_scale_freq_invariant() just when we need them, instead of at
the top of the routine, and avoiding calling it for the third time.
Signed-off-by: Viresh Kumar
---
V3:
- Skipped the enable/disable dance.
- No need to call topology_scale_freq_invariant() multiple times.
arch/arm64/kernel/topology.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index ebadc73449f9..57267d694495 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -221,8 +221,8 @@ static DEFINE_STATIC_KEY_FALSE(amu_fie_key);
static int __init init_amu_fie(void)
{
- bool invariance_status = topology_scale_freq_invariant();
cpumask_var_t valid_cpus;
+ bool invariant;
int ret = 0;
int cpu;
@@ -249,18 +249,19 @@ static int __init init_amu_fie(void)
if (cpumask_equal(valid_cpus, cpu_present_mask))
cpumask_copy(amu_fie_cpus, cpu_present_mask);
- if (!cpumask_empty(amu_fie_cpus)) {
- pr_info("CPUs[%*pbl]: counters will be used for FIE.",
- cpumask_pr_args(amu_fie_cpus));
- static_branch_enable(_fie_key);
- }
+ if (cpumask_empty(amu_fie_cpus))
+ goto free_valid_mask;
- /*
-* If the system is not fully invariant after AMU init, disable
-* partial use of counters for frequency invariance.
-*/
- if (!topology_scale_freq_invariant())
- static_branch_disable(_fie_key);
+ invariant = topology_scale_freq_invariant();
+
+ /* We aren't fully invariant yet */
+ if (!invariant && !cpumask_equal(amu_fie_cpus, cpu_present_mask))
+ goto free_valid_mask;
+
+ static_branch_enable(_fie_key);
+
+ pr_info("CPUs[%*pbl]: counters will be used for FIE.",
+ cpumask_pr_args(amu_fie_cpus));
/*
* Task scheduler behavior depends on frequency invariance support,
@@ -268,7 +269,7 @@ static int __init init_amu_fie(void)
* a result of counter initialisation and use, retrigger the build of
* scheduling domains to ensure the information is propagated properly.
*/
- if (invariance_status != topology_scale_freq_invariant())
+ if (!invariant)
rebuild_sched_domains_energy();
free_valid_mask:
--
2.25.0.rc1.19.g042ed3e048af
Re: [PATCH v41 00/24] Intel SGX foundations
On Fri, Nov 13, 2020 at 12:01:11AM +0200, Jarkko Sakkinen wrote:
> Overview
>
>
> Intel(R) SGX is new hardware functionality that can be used by
> applications to populate protected regions of user code and data called
> enclaves. Once activated, the new hardware protects enclave code and
> data from outside access and modification.
>
> SGX implementations have existed on desktop processors for several
> years. The upcoming 3rd Generation Intel Xeon Scalable Platform,
> code-named ???Ice Lake??? will also support SGX[1].
>
> Use Cases
> =
>
> Enclaves provide a place to store secrets and process data with those
> secrets. SGX has been used, for example, to decrypt video without
> exposing the decryption keys to nosy debuggers that might be used to
> subvert DRM. Software has generally been rewritten specifically to run
> in enclaves, but there are also projects that try to run limited
> unmodified software in enclaves[2].
>
> SGX hardware is available in public clouds today. But, anyone wishing
> to use it must use a modified distribution or side-load SGX support[3].
>
> Hardware Implementation
> ===
>
> New memory controller hardware encrypts data transparently before
> leaving the processor package. The randomly-generated encryption key
> has a lifetime of exactly one power cycle. This mitigates attacks
> originating outside the processor, like snooping DIMM traffic.
>
> Important Kernel Touch Points
> =
>
> Although statically carved out of normal DRAM, enclave memory can not be
> accessed or managed directly by the kernel and is marked by the firmware
> as ???Reserved???. As a result, SGX support contains simple but analogous
> functionality to the core mm such as a page allocator and reclaim.
>
> Entering and exiting enclaves is tricky business. Enclaves are
> restricted from making system calls or taking interrupts directly. The
> enclave will exit out to userspace before things like this can happen.
> A new vDSO exception mechanism is introduced to help smooth over some of
> the architectural rough edges and make the job of userspace easier.
>
> This implementation is picky and will decline to work on hardware which
> is locked to Intel???s root of trust.
>
> 1.
> https://newsroom.intel.com/news-releases/intel-xeon-scalable-platform-built-most-sensitive-workloads/
> 2. https://grapheneproject.io/
> 3.
> https://docs.microsoft.com/en-us/azure/confidential-computing/quick-create-portal
>
> Other
> =
>
> Sean Christopherson is a major contributor to this series. However, he
> has left Intel and his @intel.com address will soon be bouncing. He
> does not have a email he wants us to substitute or put in .mailmap for
> now. To avoid subjecting everyone to bounces, we have commented out his
> tag lines in the commit messages.
>
> Originally the code was based on early prototyping work of Suresh S.
>
> This patch set has been rebased on top of tip tree commit
> c3c30db1b191bb1640a08bbcc593c212affcab75.
Tested-by: Chunyang Hui
The Occlum project (https://occlum.io/) is a libOS built on top of Intel
SGX feature. We ran Occlum tests using v5.10 kernel with SGX patch v41 on
SGX hardware with the Flexible Launch Control (FLC) feature and didn't
find any problems. As Occlum core developers, we would like these patches
to be merged.
> v40 (2020-10-20):
> * Change copyright years to 2016-2020 in the all files added.
> https://lore.kernel.org/linux-sgx/20201003143925.gb800...@kroah.com/
> * Remove dual licensing and use GPL 2.0 unconditionally.
> https://lore.kernel.org/linux-sgx/20201003143925.gb800...@kroah.com/
> * Remove platform capabilities checks from sgx_validate_secs(), as they are
> validated together with the SIGSTRUCT capabilities in
> sgx_ioc_enclave_init().
>
> https://lore.kernel.org/linux-sgx/20201005020819.124724-1-jarkko.sakki...@linux.intel.com/
> * During the migration from radix_tree to xarray, the locks went missing
> from sgx_encl_may_map(). Fix this by iterating with the enclave lock and
> xarray lock held.
>
> https://lore.kernel.org/linux-sgx/20201003195440.gd20...@casper.infradead.org/
> * Verify in the #PF handler that the faulted page has equal or higher build
> time permissions than the VMA permissions (i.e. the subset of {VM_READ,
> VM_WRITE, VM_EXECUTE} in vma->vm_flags). Trigger a bus error, if this not
> the case. By doing this, mmap() and mprotect() can be allowed to map an
> address range, which has unpopulated pages, because the required
> invariant will be checked before new pages are inserted to the process
> address space.
> * In the vDSO, do not save RBX before validating the reserved area of the
> struct sgx_enclave_run.
> https://lore.kernel.org/linux-sgx/20201006025703.gg15...@linux.intel.com/
> * Increase the reserved area to 256 bytes in struct sgx_enclave_run as
> there needs to be some space for expansion given the evolution of
>
[PATCH V3 1/3] arm64: topology: Avoid the have_policy check
Every time I have stumbled upon this routine, I get confused with the
way 'have_policy' is used and I have to dig in to understand why is it
so. Here is an attempt to make it easier to understand, and hopefully it
is an improvement.
The 'have_policy' check was just an optimization to avoid writing
to amu_fie_cpus in case we don't have to, but that optimization itself
is creating more confusion than the real work. Lets just do that if all
the CPUs support AMUs. It is much cleaner that way.
Reviewed-by: Ionela Voinescu
Signed-off-by: Viresh Kumar
---
V3:
- Added Reviewed by tag.
arch/arm64/kernel/topology.c | 20 ++--
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index f6faa697e83e..ebadc73449f9 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -199,14 +199,14 @@ static int freq_inv_set_max_ratio(int cpu, u64 max_rate,
u64 ref_rate)
return 0;
}
-static inline bool
+static inline void
enable_policy_freq_counters(int cpu, cpumask_var_t valid_cpus)
{
struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
if (!policy) {
pr_debug("CPU%d: No cpufreq policy found.\n", cpu);
- return false;
+ return;
}
if (cpumask_subset(policy->related_cpus, valid_cpus))
@@ -214,8 +214,6 @@ enable_policy_freq_counters(int cpu, cpumask_var_t
valid_cpus)
amu_fie_cpus);
cpufreq_cpu_put(policy);
-
- return true;
}
static DEFINE_STATIC_KEY_FALSE(amu_fie_key);
@@ -225,7 +223,6 @@ static int __init init_amu_fie(void)
{
bool invariance_status = topology_scale_freq_invariant();
cpumask_var_t valid_cpus;
- bool have_policy = false;
int ret = 0;
int cpu;
@@ -245,17 +242,12 @@ static int __init init_amu_fie(void)
continue;
cpumask_set_cpu(cpu, valid_cpus);
- have_policy |= enable_policy_freq_counters(cpu, valid_cpus);
+ enable_policy_freq_counters(cpu, valid_cpus);
}
- /*
-* If we are not restricted by cpufreq policies, we only enable
-* the use of the AMU feature for FIE if all CPUs support AMU.
-* Otherwise, enable_policy_freq_counters has already enabled
-* policy cpus.
-*/
- if (!have_policy && cpumask_equal(valid_cpus, cpu_present_mask))
- cpumask_or(amu_fie_cpus, amu_fie_cpus, valid_cpus);
+ /* Overwrite amu_fie_cpus if all CPUs support AMU */
+ if (cpumask_equal(valid_cpus, cpu_present_mask))
+ cpumask_copy(amu_fie_cpus, cpu_present_mask);
if (!cpumask_empty(amu_fie_cpus)) {
pr_info("CPUs[%*pbl]: counters will be used for FIE.",
--
2.25.0.rc1.19.g042ed3e048af
Re: [PATCH v41 00/24] Intel SGX foundations
On Fri, Nov 13, 2020 at 12:01:11AM +0200, Jarkko Sakkinen wrote:
> Overview
>
>
> Intel(R) SGX is new hardware functionality that can be used by
> applications to populate protected regions of user code and data called
> enclaves. Once activated, the new hardware protects enclave code and
> data from outside access and modification.
>
> SGX implementations have existed on desktop processors for several
> years. The upcoming 3rd Generation Intel Xeon Scalable Platform,
> code-named ???Ice Lake??? will also support SGX[1].
>
> Use Cases
> =
>
> Enclaves provide a place to store secrets and process data with those
> secrets. SGX has been used, for example, to decrypt video without
> exposing the decryption keys to nosy debuggers that might be used to
> subvert DRM. Software has generally been rewritten specifically to run
> in enclaves, but there are also projects that try to run limited
> unmodified software in enclaves[2].
>
> SGX hardware is available in public clouds today. But, anyone wishing
> to use it must use a modified distribution or side-load SGX support[3].
>
> Hardware Implementation
> ===
>
> New memory controller hardware encrypts data transparently before
> leaving the processor package. The randomly-generated encryption key
> has a lifetime of exactly one power cycle. This mitigates attacks
> originating outside the processor, like snooping DIMM traffic.
>
> Important Kernel Touch Points
> =
>
> Although statically carved out of normal DRAM, enclave memory can not be
> accessed or managed directly by the kernel and is marked by the firmware
> as ???Reserved???. As a result, SGX support contains simple but analogous
> functionality to the core mm such as a page allocator and reclaim.
>
> Entering and exiting enclaves is tricky business. Enclaves are
> restricted from making system calls or taking interrupts directly. The
> enclave will exit out to userspace before things like this can happen.
> A new vDSO exception mechanism is introduced to help smooth over some of
> the architectural rough edges and make the job of userspace easier.
>
> This implementation is picky and will decline to work on hardware which
> is locked to Intel???s root of trust.
>
> 1.
> https://newsroom.intel.com/news-releases/intel-xeon-scalable-platform-built-most-sensitive-workloads/
> 2. https://grapheneproject.io/
> 3.
> https://docs.microsoft.com/en-us/azure/confidential-computing/quick-create-portal
>
> Other
> =
>
> Sean Christopherson is a major contributor to this series. However, he
> has left Intel and his @intel.com address will soon be bouncing. He
> does not have a email he wants us to substitute or put in .mailmap for
> now. To avoid subjecting everyone to bounces, we have commented out his
> tag lines in the commit messages.
>
> Originally the code was based on early prototyping work of Suresh S.
>
> This patch set has been rebased on top of tip tree commit
> c3c30db1b191bb1640a08bbcc593c212affcab75.
Tested-by: Chunyang Hui
Occlum project (https://occlum.io/) is a libOS built on top of Intel SGX
feature. We ran Occlum tests using v5.10 kernel with SGX patch v41 on
SGX hardware with the Flexible Launch Control (FLC) feature and didn't
find any problems. As Occlum core developers, we would like these patches
to be merged.
> v40 (2020-10-20):
> * Change copyright years to 2016-2020 in the all files added.
> https://lore.kernel.org/linux-sgx/20201003143925.gb800...@kroah.com/
> * Remove dual licensing and use GPL 2.0 unconditionally.
> https://lore.kernel.org/linux-sgx/20201003143925.gb800...@kroah.com/
> * Remove platform capabilities checks from sgx_validate_secs(), as they are
> validated together with the SIGSTRUCT capabilities in
> sgx_ioc_enclave_init().
>
> https://lore.kernel.org/linux-sgx/20201005020819.124724-1-jarkko.sakki...@linux.intel.com/
> * During the migration from radix_tree to xarray, the locks went missing
> from sgx_encl_may_map(). Fix this by iterating with the enclave lock and
> xarray lock held.
>
> https://lore.kernel.org/linux-sgx/20201003195440.gd20...@casper.infradead.org/
> * Verify in the #PF handler that the faulted page has equal or higher build
> time permissions than the VMA permissions (i.e. the subset of {VM_READ,
> VM_WRITE, VM_EXECUTE} in vma->vm_flags). Trigger a bus error, if this not
> the case. By doing this, mmap() and mprotect() can be allowed to map an
> address range, which has unpopulated pages, because the required
> invariant will be checked before new pages are inserted to the process
> address space.
> * In the vDSO, do not save RBX before validating the reserved area of the
> struct sgx_enclave_run.
> https://lore.kernel.org/linux-sgx/20201006025703.gg15...@linux.intel.com/
> * Increase the reserved area to 256 bytes in struct sgx_enclave_run as
> there needs to be some space for expansion given the evolution of
>
!!! Ask Details For Relief
You has been chosen via E-mail for the United Nations Covid-19 Relief F und, for more details reply to sangior...@aclipisa.it Best regards, Dr. Susan Marshal
RE: [PATCH 1/2] usb: cdnsp: Fixes for sparse warnings
>
>
>On 20-12-14 13:03:44, Pawel Laszczak wrote:
>> Patch fixes all sparse warnings in cdsnp driver.
>>
>> It fixes the following warnings:
>> cdnsp-ring.c:1441: warning: incorrect type in assignment
>> cdnsp-ring.c:1444: warning: restricted __le32 degrades to integer
>> cdnsp-ring.c:2200: warning: dubious: x | !y
>> cdnsp-gadget.c:501: warning: incorrect type in assignment
>> cdnsp-gadget.c:504: warning: restricted __le32 degrades to integer
>> cdnsp-gadget.c:507: warning: restricted __le32 degrades to integer
>> cdnsp-gadget.c:508: warning: restricted __le32 degrades to integer
>> cdnsp-gadget.c:509: warning: invalid assignment: |=
>> cdnsp-gadget.c:510: warning: cast from restricted __le32
>> cdnsp-gadget.c:558: warning: incorrect type in assignment
>> cdnsp-gadget.c:561: warning: restricted __le32 degrades to integer
>> cdnsp-gadget.c:570: warning: restricted __le32 degrades to integer
>> cdnsp-gadget.c:1571: warning: incorrect type in argument 1
>> cdnsp-gadget.c:1602: warning: restricted __le32 degrades to integer
>> cdnsp-gadget.c:1760: warning: incorrect type in assignment
>> cdnsp-gadget.c:1762: warning: incorrect type in assignment
>> cdnsp-gadget.c:1763: warning: incorrect type in assignment
>> cdnsp-gadget.c:1764: warning: incorrect type in assignment
>> cdnsp-gadget.c:1765: warning: incorrect type in assignment
>> cdnsp-gadget.c:1766: warning: incorrect type in assignment
>> cdnsp-gadget.c:1767: warning: incorrect type in assignment
>> cdnsp-gadget.c:458: warning: cast truncates bits from constant value
>> (07ff becomes 7ff)
>> cdnsp-gadget.c:666: warning: cast truncates bits from constant value
>> (07ff becomes 7ff)
>> cdnsp-mem.c:762: warning: incorrect type in assignment
>> cdnsp-mem.c:763: warning: incorrect type in assignment
>> cdnsp-mem.c:928: warning: cast from restricted __le16
>> cdnsp-mem.c:1187: warning: incorrect type in assignment
>> cdnsp-mem.c:1191: warning: incorrect type in assignment
>> cdnsp-ep0.c:142: warning: incorrect type in assignment
>> cdnsp-ep0.c:144: warning: restricted __le32 degrades to integer
>> cdnsp-ep0.c:147: warning: restricted __le32 degrades to integer
>> cdnsp-ep0.c:148: warning: restricted __le32 degrades to integer
>> cdnsp-ep0.c:179: warning: incorrect type in argument 1
>> cdnsp-ep0.c:311: warning: incorrect type in argument 1
>> cdnsp-ep0.c:469: warning: incorrect type in assignment
>> cdnsp-trace.h:611:1: warning: cast from restricted __le32
>>
>> Signed-off-by: Pawel Laszczak
>> Reported-by: kernel test robot
>
>Hi Pawel,
>
>The Reported-by tag should be above your Sob tag, I will change it.
>Except the patch reported build error by kernel test robot, I will apply
>your other four patches after finishing the compile test.
>
>Peter
Hi Peter,
I'm going to fix the "usb: cdns3: Adds missing __iomem markers" today.
I haven't seen any issue on ARCH=parisc. Maybe it's some specific riscv arch
issue.
I believe that:
[auto build test WARNING on next-20201211]
[cannot apply to peter.chen-usb/ci-for-usb-next v5.10 v5.10-rc7 v5.10-rc6 v5.10]
is not the problem. I based on peter.chen-usb/for-usb-next.
Also I can't open the url from kernel test robot report.
Maybe there is some temporary issue with server.
Thanks,
Pawel
>> ---
>> drivers/usb/cdns3/cdnsp-debug.h | 2 +-
>> drivers/usb/cdns3/cdnsp-ep0.c| 13 ++---
>> drivers/usb/cdns3/cdnsp-gadget.c | 24 +---
>> drivers/usb/cdns3/cdnsp-gadget.h | 13 +++--
>> drivers/usb/cdns3/cdnsp-mem.c| 11 ++-
>> drivers/usb/cdns3/cdnsp-ring.c | 4 ++--
>> drivers/usb/cdns3/cdnsp-trace.h | 2 +-
>> 7 files changed, 32 insertions(+), 37 deletions(-)
>>
>> diff --git a/drivers/usb/cdns3/cdnsp-debug.h
>> b/drivers/usb/cdns3/cdnsp-debug.h
>> index d6345d4d2911..a8776df2d4e0 100644
>> --- a/drivers/usb/cdns3/cdnsp-debug.h
>> +++ b/drivers/usb/cdns3/cdnsp-debug.h
>> @@ -414,7 +414,7 @@ static inline const char *cdnsp_decode_slot_context(u32
>> info, u32 info2,
>> s = "UNKNOWN speed";
>> }
>>
>> -ret = sprintf(str, "%s Ctx Entries %ld",
>> +ret = sprintf(str, "%s Ctx Entries %d",
>>s, (info & LAST_CTX_MASK) >> 27);
>>
>> ret += sprintf(str + ret, " [Intr %ld] Addr %ld State %s",
>> diff --git a/drivers/usb/cdns3/cdnsp-ep0.c b/drivers/usb/cdns3/cdnsp-ep0.c
>> index d55b59ed7381..e2b1bcb3f80e 100644
>> --- a/drivers/usb/cdns3/cdnsp-ep0.c
>> +++ b/drivers/usb/cdns3/cdnsp-ep0.c
>> @@ -137,10 +137,8 @@ int cdnsp_status_stage(struct cdnsp_device *pdev)
>> return cdnsp_ep_enqueue(pdev->ep0_preq.pep, >ep0_preq);
>> }
>>
>> -static int cdnsp_w_index_to_ep_index(__le32 wIndex)
>> +static int cdnsp_w_index_to_ep_index(u16 wIndex)
>> {
>> -wIndex = le32_to_cpu(wIndex);
>> -
>> if (!(wIndex & USB_ENDPOINT_NUMBER_MASK))
>> return 0;
>>
>> @@ -176,7 +174,8 @@ static int cdnsp_ep0_handle_status(struct cdnsp_device
>>
Re: [PATCH -next] usb: phy: convert comma to semicolon
On 20-12-11 16:54:28, Zheng Yongjun wrote: > Replace a comma between expression statements by a semicolon. > > Signed-off-by: Zheng Yongjun Reviewed-by: Peter Chen Peter > --- > drivers/usb/phy/phy-isp1301-omap.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/usb/phy/phy-isp1301-omap.c > b/drivers/usb/phy/phy-isp1301-omap.c > index 4a6462c92ef2..6f4f74e6ba51 100644 > --- a/drivers/usb/phy/phy-isp1301-omap.c > +++ b/drivers/usb/phy/phy-isp1301-omap.c > @@ -1566,13 +1566,13 @@ isp1301_probe(struct i2c_client *i2c, const struct > i2c_device_id *id) > > isp->phy.dev = >dev; > isp->phy.label = DRIVER_NAME; > - isp->phy.set_power = isp1301_set_power, > + isp->phy.set_power = isp1301_set_power; > > isp->phy.otg->usb_phy = >phy; > - isp->phy.otg->set_host = isp1301_set_host, > - isp->phy.otg->set_peripheral = isp1301_set_peripheral, > - isp->phy.otg->start_srp = isp1301_start_srp, > - isp->phy.otg->start_hnp = isp1301_start_hnp, > + isp->phy.otg->set_host = isp1301_set_host; > + isp->phy.otg->set_peripheral = isp1301_set_peripheral; > + isp->phy.otg->start_srp = isp1301_start_srp; > + isp->phy.otg->start_hnp = isp1301_start_hnp; > > enable_vbus_draw(isp, 0); > power_down(isp); > -- > 2.22.0 > -- Thanks, Peter Chen
Re: [PATCH rdma-rc 0/5] Fixes to v5.10
On Mon, Dec 14, 2020 at 03:27:22PM -0400, Jason Gunthorpe wrote: > On Sun, Dec 13, 2020 at 03:29:35PM +0200, Leon Romanovsky wrote: > > From: Leon Romanovsky > > > > Hi, > > > > This is another series with various fixes that can easily go to -next too. > > > > Thanks > > > > Leon Romanovsky (1): > > RDMA/cma: Don't overwrite sgid_attr after device is released > > > > Maor Gottlieb (2): > > RDMA/mlx5: Fix MR cache memory leak > > Applied these two to for-next, thanks > > > RDMA/ucma: Fix memory leak of connection request > > IB/umad: Return EIO in case of when device disassociated > > IB/umad: Return EPOLLERR in case of when device disassociated > > These ones can wait till next cycle Thanks > > Jason
Re: [PATCH v3 4/6] mm: honor PF_MEMALLOC_PIN for all movable pages
On Mon, Dec 14, 2020 at 9:17 AM Michal Hocko wrote: > > On Fri 11-12-20 15:21:38, Pavel Tatashin wrote: > [...] > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > index c2dea9ad0e98..4d8e7f801c66 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -3802,16 +3802,12 @@ alloc_flags_nofragment(struct zone *zone, gfp_t > > gfp_mask) > > return alloc_flags; > > } > > > > -static inline unsigned int current_alloc_flags(gfp_t gfp_mask, > > - unsigned int alloc_flags) > > +static inline unsigned int cma_alloc_flags(gfp_t gfp_mask, > > +unsigned int alloc_flags) > > Do you have any strong reason to rename? Even though the current Yes :) > implementation only does something for cma I do not think this is all > that important. The naming nicely fits with current_gfp_context so I > would stick with it. I am renaming because current->flags is removed from this function, therefore keeping the name becomes misleading. This function only addresses cma flag check without looking at the thread local state now. > > Other than that the patch looks reasonable. I would just add a comment > explaining that current_alloc_flags should be called _after_ > current_gfp_context because that one might change the gfp_mask. Thanks, I will add it. > > With that addressed, feel free to add > Acked-by: Michal Hocko Thank you, Pasha
Re: [PATCH] kvm: don't lose the higher 32 bits of tlbs_dirty
On Tue, Dec 15, 2020 at 1:20 AM Sean Christopherson wrote:
>
> On Sun, Dec 13, 2020, Lai Jiangshan wrote:
> > From: Lai Jiangshan
> >
> > In kvm_mmu_notifier_invalidate_range_start(), tlbs_dirty is used as:
> > need_tlb_flush |= kvm->tlbs_dirty;
> > with need_tlb_flush's type being int and tlbs_dirty's type being long.
> >
> > It means that tlbs_dirty is always used as int and the higher 32 bits
> > is useless.
>
> It's probably worth noting in the changelog that it's _extremely_ unlikely
> this
> bug can cause problems in practice. It would require encountering tlbs_dirty
> on a 4 billion count boundary, and KVM would need to be using shadow paging or
> be running a nested guest.
You are right, I don't consider it would cause problems in practice, and I
also tried to make tlbs_dirty as "int" and found that I have to change too
many places.
And you are right it is worth noting about it, I'm sorry for neglecting.
>
> > We can just change need_tlb_flush's type to long to
> > make full use of tlbs_dirty.
>
> Hrm, this does solve the problem, but I'm not a fan of continuing to use an
> integer variable as a boolean. Rather than propagate tlbs_dirty to
> need_tlb_flush, what if this bug fix patch checks tlbs_dirty directly, and
> then
> a follow up patch converts need_tlb_flush to a bool and removes the
> unnecessary
> initialization (see below).
>
> E.g. the net result of both patches would be:
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 3abcb2ce5b7d..93b6986d3dfc 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -473,7 +473,8 @@ static int kvm_mmu_notifier_invalidate_range_start(struct
> mmu_notifier *mn,
> const struct mmu_notifier_range
> *range)
> {
> struct kvm *kvm = mmu_notifier_to_kvm(mn);
> - int need_tlb_flush = 0, idx;
> + bool need_tlb_flush;
> + int idx;
>
> idx = srcu_read_lock(>srcu);
> spin_lock(>mmu_lock);
> @@ -483,11 +484,10 @@ static int
> kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
> * count is also read inside the mmu_lock critical section.
> */
> kvm->mmu_notifier_count++;
> - need_tlb_flush = kvm_unmap_hva_range(kvm, range->start, range->end,
> -range->flags);
> - need_tlb_flush |= kvm->tlbs_dirty;
> + need_tlb_flush = !!kvm_unmap_hva_range(kvm, range->start, range->end,
> + range->flags);
> /* we've to flush the tlb before the pages can be freed */
> - if (need_tlb_flush)
> + if (need_tlb_flush || kvm->tlbs_dirty)
> kvm_flush_remote_tlbs(kvm);
>
> spin_unlock(>mmu_lock);
>
> Cc: sta...@vger.kernel.org
> Fixes: a4ee1ca4a36e ("KVM: MMU: delay flush all tlbs on sync_page path")
I searched back, found it and considered adding this fixes tag, but I was
afraid that this cleanup would be backported. Is it worth backporting such
patch which is extremely hardly a problem in practice?
>
> > Signed-off-by: Lai Jiangshan
> > ---
> > virt/kvm/kvm_main.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > index 2541a17ff1c4..4e519a517e9f 100644
> > --- a/virt/kvm/kvm_main.c
> > +++ b/virt/kvm/kvm_main.c
> > @@ -470,7 +470,8 @@ static int
> > kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn,
> > const struct mmu_notifier_range
> > *range)
> > {
> > struct kvm *kvm = mmu_notifier_to_kvm(mn);
> > - int need_tlb_flush = 0, idx;
> > + long need_tlb_flush = 0;
>
> need_tlb_flush doesn't need to be initialized here, it's explicitly set via
> the
> call to kvm_unmap_hva_range().
>
> > + int idx;
> >
> > idx = srcu_read_lock(>srcu);
> > spin_lock(>mmu_lock);
> > --
> > 2.19.1.6.gb485710b
> >
Re: [PATCH v4 2/3] backlight: rt4831: Adds DT binding document for Richtek RT4831 backlight
> On Sat, Dec 12, 2020 at 12:33:43AM +0800, cy_huang wrote:
> >
> > From: ChiYuan Huang
> >
> > Adds DT binding document for Richtek RT4831 backlight.
> >
> > Signed-off-by: ChiYuan Huang
> > ---
> > since v3
> > - Move inlcude/dt-bindings/leds/rt4831-backlight.h from v3 mfd
> > binding patch to here.
> > - Add dual license tag in header and backlight binding document.
> > - Left backlight dt-binding example only.
> > ---
> > .../leds/backlight/richtek,rt4831-backlight.yaml | 76
> > ++
> > include/dt-bindings/leds/rt4831-backlight.h| 23 +++
> > 2 files changed, 99 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-
> > backlight.yaml
> > create mode 100644 include/dt-bindings/leds/rt4831-backlight.h
> >
> > diff --git
> > a/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-
> > backlight.yaml
> > b/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-
> > backlight.yaml
> > new file mode 100644
> > index ..f24c8d1
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-
> > backlight.yaml
> > @@ -0,0 +1,76 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/leds/backlight/richtek,rt4831-b
> > acklight.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Richtek RT4831 Backlight
> > +
> > +maintainers:
> > + - ChiYuan Huang
> > +
> > +description: |
> > + RT4831 is a mutifunctional device that can provide power to the
> > LCD display
> > + and LCD backlight.
> > +
> > + For the LCD backlight, it can provide four channel WLED driving
> > capability.
> > + Each channel driving current is up to 30mA
> > +
> > + Datasheet is available at
> > + https://www.richtek.com/assets/product_file/RT4831A/DS4831A-05.p
> > df
> > +
> > +properties:
> > + compatible:
> > +const: richtek,rt4831-backlight
> > +
> > + default-brightness:
> > +description: |
> > + The default brightness that applied to the system on start-
> > up.
> > +$ref: /schemas/types.yaml#/definitions/uint32
> > +minimum: 0
> > +maximum: 2048
> > +
> > + max-brightness:
> > +description: |
> > + The max brightness for the H/W limit
> > +$ref: /schemas/types.yaml#/definitions/uint32
> > +minimum: 0
> > +maximum: 2048
> > +
> > + richtek,pwm-enable:
> > +description: |
> > + Specify the backlight dimming following by PWM duty or by SW
> > control.
> > +type: boolean
> > +
> > + richtek,bled-ovp-sel:
> > +description: |
> > + Backlight OVP level selection, currently support
> > 17V/21V/25V/29V.
> > +$ref: /schemas/types.yaml#/definitions/uint8
> > +default: 1
> > +minimum: 0
> > +maximum: 3
> > +
> > + richtek,channel-use:
> > +description: |
> > + Backlight LED channel to be used.
> > + BIT 0/1/2/3 is used to indicate led channel 1/2/3/4 enable
> > or disable.
> > +$ref: /schemas/types.yaml#/definitions/uint8
> > +minimum: 1
> > +maximum: 15
> > +
> > +required:
> > + - compatible
> > + - richtek,channel-use
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +backlight {
> > + compatible = "richtek,rt4831-backlight";
> > + default-brightness = <1024>;
> > + max-brightness = <2048>;
> > + richtek,bled-ovp-sel = /bits/ 8 ;
> > + richtek,channel-use = /bits/ 8 ;
> This is in the MFD schema already, so drop the example.
>
Will ack in next series patch.
> >
> > +};
> > diff --git a/include/dt-bindings/leds/rt4831-backlight.h
> > b/include/dt-bindings/leds/rt4831-backlight.h
> > new file mode 100644
> > index ..125c635
> > --- /dev/null
> > +++ b/include/dt-bindings/leds/rt4831-backlight.h
> > @@ -0,0 +1,23 @@
> > +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> > +/*
> > + * This header provides constants for rt4831 backlight bindings.
> > + *
> > + * Copyright (C) 2020, Richtek Technology Corp.
> > + * Author: ChiYuan Huang
> > + */
> > +
> > +#ifndef _DT_BINDINGS_RT4831_BACKLIGHT_H
> > +#define _DT_BINDINGS_RT4831_BACKLIGHT_H
> > +
> > +#define RT4831_BLOVPLVL_17V0
> > +#define RT4831_BLOVPLVL_21V1
> > +#define RT4831_BLOVPLVL_25V2
> > +#define RT4831_BLOVPLVL_29V3
> > +
> > +#define RT4831_BLED_CH1EN(1 << 0)
> > +#define RT4831_BLED_CH2EN(1 << 1)
> > +#define RT4831_BLED_CH3EN(1 << 2)
> > +#define RT4831_BLED_CH4EN(1 << 3)
> > +#define RT4831_BLED_ALLCHEN((1 << 4) - 1)
> > +
> > +#endif /* _DT_BINDINGS_RT4831_BACKLIGHT_H */
* Email Confidentiality Notice
The information contained in this e-mail message (including any attachments)
may be confidential, proprietary, privileged, or otherwise exempt from
disclosure under applicable laws. It is intended to be conveyed only to the
designated recipient(s). Any use, dissemination,
Re: [PATCH v4 2/3] backlight: rt4831: Adds DT binding document for Richtek RT4831 backlight
On Mon, Dec 14, 2020 at 10:40:55PM +0800, ChiYuan Huang wrote: > > Hi, > > Daniel Thompson 於 2020年12月14日 週一 > 下午5:59寫道： > > > > > > Hi CY > > > > On Sat, Dec 12, 2020 at 12:33:43AM +0800, cy_huang wrote: > > > > > > From: ChiYuan Huang > > > > > > Adds DT binding document for Richtek RT4831 backlight. > > > > > > Signed-off-by: ChiYuan Huang > > This patch got keyword filtered and brought to my attention > > but the rest of the series did not. > > > > If it was a backlight patch series you need to send it To: the > > all the backlight maintainers. > > > Yes, I'm waiting for mfd reviewing. > Due to mfd patch, I need to add backlight dt-binding patch prior to > backlight source code. > Or autobuild robot will said mfd dt-binding build fail from Rob. > That's why I send the backlight dt-binding prior to the source code. > > I still have backlight/regulator source code patch after mfd > reviewing. > Do you want me to send all the patches without waiting for mfd > reviewing? What happened to the regulator part of the binding? I said you could merge it into the mfd schema, not drop it. Bindings should be complete so we get a full picture of a device. Yes, I remove the regulator dt-binding and directly merge into mfd schema. Could you check the v4 3/3 patch? Or you just want me to remove regulator dt-binding example in regulator dt-binding patch? Sorry, please also loop my gmail account. Due to my company mailbox, I'm not sure whether the reply format is correct or not. Rob * Email Confidentiality Notice The information contained in this e-mail message (including any attachments) may be confidential, proprietary, privileged, or otherwise exempt from disclosure under applicable laws. It is intended to be conveyed only to the designated recipient(s). Any use, dissemination, distribution, printing, retaining or copying of this e-mail (including its attachments) by unintended recipient(s) is strictly prohibited and may be unlawful. If you are not an intended recipient of this e-mail, or believe that you have received this e-mail in error, please notify the sender immediately (by replying to this e-mail), delete any and all copies of this e-mail (including any attachments) from your system, and do not disclose the content of this e-mail to any other person. Thank you!
Re: [PATCH v2] net/mlx4: Use true,false for bool variable
On Mon, Dec 14, 2020 at 11:15:01AM -0800, Joe Perches wrote: > On Mon, 2020-12-14 at 11:03 -0800, Jakub Kicinski wrote: > > On Mon, 14 Dec 2020 13:16:08 +0200 Leon Romanovsky wrote: > > > On Mon, Dec 14, 2020 at 11:30:08AM +0100, Vasyl Gomonovych wrote: > > > > It is fix for semantic patch warning available in > > > > scripts/coccinelle/misc/boolinit.cocci > > > > Fix en_rx.c:687:1-17: WARNING: Assignment of 0/1 to bool variable > > > > Fix main.c:4465:5-13: WARNING: Comparison of 0/1 to bool variable > > > > > > > > Signed-off-by: Vasyl Gomonovych > > > > --- > > > > - Add coccicheck script name > > > > - Simplify if condition > > > > --- > > > > drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +- > > > > drivers/net/ethernet/mellanox/mlx4/main.c | 2 +- > > > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > > > Please refrain from sending new version of patches as reply-to to > > > previous variants. It makes to appear previous patches out-of-order > > > while viewing in threaded mode. > > > > Yes, please! I'm glad I'm not the only one who feels this way! :) > > I'm the other way. > > I prefer revisions to single patches (as opposed to large patch series) > in the same thread. It depends which side you are in that game. From the reviewer point of view, such submission breaks flow very badly. It unfolds the already reviewed thread, messes with the order and many more little annoying things. > > There is no other easy way for changes to a patch to be tracked AFAIK. Not really, I'm using very simple convention to keep tracking of changes. The changelog together with lorifier does the trick. https://github.com/danrue/lorifier https://lore.kernel.org/linux-rdma/20201125064628.8431-1-l...@kernel.org/ So I'm simply adding link to the previous version when sending new one. > > Most email clients use both In-Reply-To: and References: headers as > the mechanism to thread replies. Right, and this is exactly what we don't want for vX patches. > > Keeping the latest messages at the bottom of a thread works well > to see revision sequences. I have a different workflow. Thanks
Re: [PATCH v3 3/6] mm: apply per-task gfp constraints in fast path
> Ack to this. Thank you. > > But I do not really understand this. All allocation contexts should have > a proper gfp mask so why do we have to call current_gfp_context here? > In fact moving the current_gfp_context in the allocator path should have > made all this games unnecessary. Memcg reclaim path might need some > careful check because gfp mask is used more creative there but the > general reclaim paths should be ok. > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > Again, why do we need this when the gfp_mask > > }; > > -- Hi Michal, Beside from __alloc_pages_nodemask(), the current_gfp_context() is called from the following six functions: try_to_free_pages() try_to_free_mem_cgroup_pages() __node_reclaim() __need_fs_reclaim() alloc_contig_range() pcpu_alloc() As I understand, the idea is that because the allocator now honors gfp_context values for all paths, the call can be removed from some of the above functions. I think you are correct. But, at least from a quick glance, this is not obvious, and is not the case for all of the above functions. For example: alloc_contig_range() __alloc_contig_migrate_range isolate_migratepages_range isolate_migratepages_block /* * Only allow to migrate anonymous pages in GFP_NOFS context * because those do not depend on fs locks. */ if (!(cc->gfp_mask & __GFP_FS) && page_mapping(page)) goto isolate_fail; If we remove current_gfp_context() from alloc_contig_range(), the cc->gfp_mask will not be updated with proper __GFP_FS flag. I have studied some other paths, and they are also convoluted. Therefore, I am worried about performing this optimization in this series.
Re: [PATCH v4 2/3] backlight: rt4831: Adds DT binding document for Richtek RT4831 backlight
cy_huang(黃啟原) 於 2020年12月15日 週二 下午1:08寫道： > > On Mon, Dec 14, 2020 at 10:40:55PM +0800, ChiYuan Huang wrote: > > > > Hi, > > > > Daniel Thompson 於 2020年12月14日 週一 > > 下午5:59寫道： > > > > > > > > > Hi CY > > > > > > On Sat, Dec 12, 2020 at 12:33:43AM +0800, cy_huang wrote: > > > > > > > > From: ChiYuan Huang > > > > > > > > Adds DT binding document for Richtek RT4831 backlight. > > > > > > > > Signed-off-by: ChiYuan Huang > > > This patch got keyword filtered and brought to my attention > > > but the rest of the series did not. > > > > > > If it was a backlight patch series you need to send it To: the > > > all the backlight maintainers. > > > > > Yes, I'm waiting for mfd reviewing. > > Due to mfd patch, I need to add backlight dt-binding patch prior to > > backlight source code. > > Or autobuild robot will said mfd dt-binding build fail from Rob. > > That's why I send the backlight dt-binding prior to the source code. > > > > I still have backlight/regulator source code patch after mfd > > reviewing. > > Do you want me to send all the patches without waiting for mfd > > reviewing? > What happened to the regulator part of the binding? I said you could > merge it into the mfd schema, not drop it. Bindings should be complete > so we get a full picture of a device. > Sorry I found the gmail account already loop in. Just my gmail problem. I cannot see the email in it. The reply is below. Yes, I remove the regulator dt-binding and directly merge into mfd schema. Could you check the v4 3/3 patch? Or you just want me to remove regulator dt-binding example, not whole dt-binding file? > > Rob > * Email Confidentiality Notice > > The information contained in this e-mail message (including any attachments) > may be confidential, proprietary, privileged, or otherwise exempt from > disclosure under applicable laws. It is intended to be conveyed only to the > designated recipient(s). Any use, dissemination, distribution, printing, > retaining or copying of this e-mail (including its attachments) by unintended > recipient(s) is strictly prohibited and may be unlawful. If you are not an > intended recipient of this e-mail, or believe that you have received this > e-mail in error, please notify the sender immediately (by replying to this > e-mail), delete any and all copies of this e-mail (including any attachments) > from your system, and do not disclose the content of this e-mail to any other > person. Thank you!
Re: [PATCH v2 2/2] Documentation: fpga: dfl: Add description for DFL UIO support
On Mon, Dec 14, 2020 at 08:43:31PM -0800, Tom Rix wrote: > > On 12/14/20 6:22 PM, Xu Yilun wrote: > > On Mon, Dec 14, 2020 at 02:14:56PM -0800, Tom Rix wrote: > >> On 12/13/20 7:36 PM, Xu Yilun wrote: > >>> This patch adds description for UIO support for dfl devices on DFL > >>> bus. > >>> > >>> Signed-off-by: Xu Yilun > >>> --- > >>> v2: no doc in v1, add it for v2. > >>> --- > >> > >>> +components. They could instantiate a new private feature in the DFL, and > >>> then > >>> +get a DFL device in their system. In some cases users may need a > >>> userspace > >>> +driver for the DFL device: > >>> + > >>> +* Users may need to run some diagnostic test for their hardwares. > >> * Users may prototype the kernel driver in user space. > > Could we just add the line rather than replacing the previous line? I think > > this > > comment is describing a different usecase. > > Yes, this is what i ment, please use your original. > > I am offering another usecase, one I will use. > > Add mine as well, if you want. I'll add your usecase. > > > > >>> +* Some hardware is designed for specific purposes and does not fit into > >>> one of > >>> + the standard kernel subsystems. > >>> + > >>> +This requires the direct access to the MMIO space and interrupt handling > >>> in > >>> +userspace. We implemented a dfl-uio-pdev module which exposes the UIO > >>> device > >> The dfl-uio-pdev module exposes > > Will change it. > > > >>> +interfaces. It adds the uio_pdrv_genirq platform device with the > >>> resources of > >>> +the DFL device, and let the generic UIO platform device driver provide > >>> UIO > >> the DLF device, and lets > > Will change it. > > > >>> +support to userspace. > >> Use FPGA_DFL_UIO_PDEV to enable this feature. > > I didn't get your idea for this. > > I wanted the user to know which kconfig controls this feature. Understood. I'll add it. Thanks, Yilun
[PATCH] MIPS: No need to check CPU 0 in cps_cpu_disable()
After commit 9cce844abf07 ("MIPS: CPU#0 is not hotpluggable"),
c->hotpluggable is 0 for CPU 0 and it will not generate a control
file in sysfs for this CPU:
[root@linux loongson]# cat /sys/devices/system/cpu/cpu0/online
cat: /sys/devices/system/cpu/cpu0/online: No such file or directory
[root@linux loongson]# echo 0 > /sys/devices/system/cpu/cpu0/online
bash: /sys/devices/system/cpu/cpu0/online: Permission denied
So no need to check CPU 0 in cps_cpu_disable(), just remove it.
Reported-by: liwei (GF)
Signed-off-by: Tiezhu Yang
---
cps_cpu_disable() is not done in the early similar patch,
sorry for that.
arch/mips/kernel/smp-cps.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/mips/kernel/smp-cps.c b/arch/mips/kernel/smp-cps.c
index 8b027c7..bcd6a94 100644
--- a/arch/mips/kernel/smp-cps.c
+++ b/arch/mips/kernel/smp-cps.c
@@ -451,9 +451,6 @@ static int cps_cpu_disable(void)
unsigned cpu = smp_processor_id();
struct core_boot_config *core_cfg;
- if (!cpu)
- return -EBUSY;
-
if (!cps_pm_support_state(CPS_PM_POWER_GATED))
return -EINVAL;
--
2.1.0
Re: [PATCH 1/2] usb: cdnsp: Fixes for sparse warnings
On 20-12-14 13:03:44, Pawel Laszczak wrote:
> Patch fixes all sparse warnings in cdsnp driver.
>
> It fixes the following warnings:
> cdnsp-ring.c:1441: warning: incorrect type in assignment
> cdnsp-ring.c:1444: warning: restricted __le32 degrades to integer
> cdnsp-ring.c:2200: warning: dubious: x | !y
> cdnsp-gadget.c:501: warning: incorrect type in assignment
> cdnsp-gadget.c:504: warning: restricted __le32 degrades to integer
> cdnsp-gadget.c:507: warning: restricted __le32 degrades to integer
> cdnsp-gadget.c:508: warning: restricted __le32 degrades to integer
> cdnsp-gadget.c:509: warning: invalid assignment: |=
> cdnsp-gadget.c:510: warning: cast from restricted __le32
> cdnsp-gadget.c:558: warning: incorrect type in assignment
> cdnsp-gadget.c:561: warning: restricted __le32 degrades to integer
> cdnsp-gadget.c:570: warning: restricted __le32 degrades to integer
> cdnsp-gadget.c:1571: warning: incorrect type in argument 1
> cdnsp-gadget.c:1602: warning: restricted __le32 degrades to integer
> cdnsp-gadget.c:1760: warning: incorrect type in assignment
> cdnsp-gadget.c:1762: warning: incorrect type in assignment
> cdnsp-gadget.c:1763: warning: incorrect type in assignment
> cdnsp-gadget.c:1764: warning: incorrect type in assignment
> cdnsp-gadget.c:1765: warning: incorrect type in assignment
> cdnsp-gadget.c:1766: warning: incorrect type in assignment
> cdnsp-gadget.c:1767: warning: incorrect type in assignment
> cdnsp-gadget.c:458: warning: cast truncates bits from constant value
> (07ff becomes 7ff)
> cdnsp-gadget.c:666: warning: cast truncates bits from constant value
> (07ff becomes 7ff)
> cdnsp-mem.c:762: warning: incorrect type in assignment
> cdnsp-mem.c:763: warning: incorrect type in assignment
> cdnsp-mem.c:928: warning: cast from restricted __le16
> cdnsp-mem.c:1187: warning: incorrect type in assignment
> cdnsp-mem.c:1191: warning: incorrect type in assignment
> cdnsp-ep0.c:142: warning: incorrect type in assignment
> cdnsp-ep0.c:144: warning: restricted __le32 degrades to integer
> cdnsp-ep0.c:147: warning: restricted __le32 degrades to integer
> cdnsp-ep0.c:148: warning: restricted __le32 degrades to integer
> cdnsp-ep0.c:179: warning: incorrect type in argument 1
> cdnsp-ep0.c:311: warning: incorrect type in argument 1
> cdnsp-ep0.c:469: warning: incorrect type in assignment
> cdnsp-trace.h:611:1: warning: cast from restricted __le32
>
> Signed-off-by: Pawel Laszczak
> Reported-by: kernel test robot
Hi Pawel,
The Reported-by tag should be above your Sob tag, I will change it.
Except the patch reported build error by kernel test robot, I will apply
your other four patches after finishing the compile test.
Peter
> ---
> drivers/usb/cdns3/cdnsp-debug.h | 2 +-
> drivers/usb/cdns3/cdnsp-ep0.c| 13 ++---
> drivers/usb/cdns3/cdnsp-gadget.c | 24 +---
> drivers/usb/cdns3/cdnsp-gadget.h | 13 +++--
> drivers/usb/cdns3/cdnsp-mem.c| 11 ++-
> drivers/usb/cdns3/cdnsp-ring.c | 4 ++--
> drivers/usb/cdns3/cdnsp-trace.h | 2 +-
> 7 files changed, 32 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/usb/cdns3/cdnsp-debug.h b/drivers/usb/cdns3/cdnsp-debug.h
> index d6345d4d2911..a8776df2d4e0 100644
> --- a/drivers/usb/cdns3/cdnsp-debug.h
> +++ b/drivers/usb/cdns3/cdnsp-debug.h
> @@ -414,7 +414,7 @@ static inline const char *cdnsp_decode_slot_context(u32
> info, u32 info2,
> s = "UNKNOWN speed";
> }
>
> - ret = sprintf(str, "%s Ctx Entries %ld",
> + ret = sprintf(str, "%s Ctx Entries %d",
> s, (info & LAST_CTX_MASK) >> 27);
>
> ret += sprintf(str + ret, " [Intr %ld] Addr %ld State %s",
> diff --git a/drivers/usb/cdns3/cdnsp-ep0.c b/drivers/usb/cdns3/cdnsp-ep0.c
> index d55b59ed7381..e2b1bcb3f80e 100644
> --- a/drivers/usb/cdns3/cdnsp-ep0.c
> +++ b/drivers/usb/cdns3/cdnsp-ep0.c
> @@ -137,10 +137,8 @@ int cdnsp_status_stage(struct cdnsp_device *pdev)
> return cdnsp_ep_enqueue(pdev->ep0_preq.pep, >ep0_preq);
> }
>
> -static int cdnsp_w_index_to_ep_index(__le32 wIndex)
> +static int cdnsp_w_index_to_ep_index(u16 wIndex)
> {
> - wIndex = le32_to_cpu(wIndex);
> -
> if (!(wIndex & USB_ENDPOINT_NUMBER_MASK))
> return 0;
>
> @@ -176,7 +174,8 @@ static int cdnsp_ep0_handle_status(struct cdnsp_device
> *pdev,
>*/
> return cdnsp_ep0_delegate_req(pdev, ctrl);
> case USB_RECIP_ENDPOINT:
> - pep = >eps[cdnsp_w_index_to_ep_index(ctrl->wIndex)];
> + ep_sts = cdnsp_w_index_to_ep_index(le16_to_cpu(ctrl->wIndex));
> + pep = >eps[ep_sts];
> ep_sts = GET_EP_CTX_STATE(pep->out_ctx);
>
> /* check if endpoint is stalled */
> @@ -305,10 +304,10 @@ static int cdnsp_ep0_handle_feature_endpoint(struct
> cdnsp_device *pdev,
>int set)
> {
>
Re: linux-next: manual merge of the parisc-hd tree with the asm-generic tree
Hi Helge, On Tue, 15 Dec 2020 05:45:49 +0100 Helge Deller wrote: > > I dropped the patch from the parisc-hd tree for now - > it needs more work and will not be part of the next merge window. Thanks for letting me know. -- Cheers, Stephen Rothwell pgpNgyoZ38GwF.pgp Description: OpenPGP digital signature
Re: [PATCH net-next] seg6: fix the max number of supported SRv6 behavior attributes
On Sat, 12 Dec 2020 02:00:05 +0100 Andrea Mayer wrote:
> The set of required attributes for a given SRv6 behavior is identified
> using a bitmap stored in an unsigned long, since the initial design of
> SRv6 networking in Linux. Recently the same approach has been used for
> identifying the optional attributes.
>
> We realized that choosing an unsigned long to store a bitmap is not a
> proper design choice considering that new attributes can be defined in the
> future. The problem is that the size of an unsigned long can be 32 or 64
> bits depending on the architecture. Therefore the maximum number of
> attributes that can be defined currently is 32 or 64 depending on the
> architecture. This issue has not caused any harm so far, because new
> attributes are defined statically in the kernel code, and currently only 10
> attributes have been defined.
>
> With this patch, we set the maximum number of attributes that can be
> supported by the SRv6 networking in Linux to be 64 regardless of the
> architecture.
>
> We changed the unsigned long type of the bitmaps to the u64 type and
> adapted the code accordingly. In particular:
>
> - We replaced all patterns (1 << i) with the macro SEG6_F_ATTR(i) in order
>to address overflow issues caused by 32-bit signed arithmetic.
>
>Many thanks to Colin Ian King for catching the overflow problem and
>inspiring this patch;
>
> - At compile time we verify that the total number of attributes does not
>exceed the fixed value of 64. Otherwise, kernel build fails forcing
>developers to reconsider adding a new attribute or extending the
>total number of supported attributes by the SRv6 networking.
Over all seems like a good thing too catch but the patch seems to go
further than necessary. And on 32bit systems using u64 is when we only
need 10 attrs is kinda wasteful.
> Fixes: d1df6fd8a1d2 ("ipv6: sr: define core operations for seg6local
> lightweight tunnel")
> Fixes: 140f04c33bbc ("ipv6: sr: implement several seg6local actions")
> Fixes: 891ef8dd2a8d ("ipv6: sr: implement additional seg6local actions")
> Fixes: 004d4b274e2a ("ipv6: sr: Add seg6local action End.BPF")
> Fixes: 964adce526a4 ("seg6: improve management of behavior attributes")
> Fixes: 0a3021f1d4e5 ("seg6: add support for optional attributes in SRv6
> behaviors")
> Fixes: 664d6f86868b ("seg6: add support for the SRv6 End.DT4 behavior")
> Fixes: 20a081b7984c ("seg6: add VRF support for SRv6 End.DT6 behavior")
We use fixes tags for bugs only, nothing seems broken here. It's more
of a fool-proofing for the future.
> Signed-off-by: Andrea Mayer
> ---
> include/uapi/linux/seg6_local.h | 10
> net/ipv6/seg6_local.c | 89 ++---
> 2 files changed, 60 insertions(+), 39 deletions(-)
>
> diff --git a/include/uapi/linux/seg6_local.h b/include/uapi/linux/seg6_local.h
> index 3b39ef1dbb46..81b3ac430670 100644
> --- a/include/uapi/linux/seg6_local.h
> +++ b/include/uapi/linux/seg6_local.h
> @@ -27,9 +27,19 @@ enum {
> SEG6_LOCAL_OIF,
> SEG6_LOCAL_BPF,
> SEG6_LOCAL_VRFTABLE,
> + /* new attributes go here */
> __SEG6_LOCAL_MAX,
> +
> + /* Support up to 64 different types of attributes.
> + *
> + * If you need to add a new attribute, please make sure that it DOES
> + * NOT violate the constraint of having a maximum of 64 possible
> + * attributes.
> + */
> + __SEG6_LOCAL_MAX_SUPP = 64,
Let's not define this, especially in a uAPI header. No need to make
promises on max attr id to user space.
> +#define SEG6_F_ATTR(i) (((u64)1) << (i))
This wrapper looks useful, worth keeping.
> @@ -1692,6 +1694,15 @@ static const struct lwtunnel_encap_ops seg6_local_ops
> = {
>
> int __init seg6_local_init(void)
> {
> + /* If the max total number of defined attributes is reached, then your
> + * kernel build stops here.
> + *
> + * This check is required to avoid arithmetic overflows when processing
> + * behavior attributes and the maximum number of defined attributes
> + * exceeds the allowed value.
> + */
> + BUILD_BUG_ON(SEG6_LOCAL_MAX + 1 > SEG6_LOCAL_MAX_SUPP);
BUILD_BUG_ON(SEG6_LOCAL_MAX > 31)
> return lwtunnel_encap_add_ops(_local_ops,
> LWTUNNEL_ENCAP_SEG6_LOCAL);
> }
Re: [PATCH] drivers: core: Detach device from power domain on shutdown
On Tue, Dec 1, 2020 at 1:30 PM Furquan Shaikh wrote: > > When the system is powered off or rebooted, devices are not detached > from their PM domain. This results in ACPI PM not being invoked and > hence PowerResouce _OFF method not being invoked for any of the > devices. Because the ACPI power resources are not turned off in case > of poweroff and reboot, it violates the power sequencing requirements > which impacts the reliability of the devices over the lifetime of the > platform. This is currently observed on all Chromebooks using ACPI. > > In order to solve the above problem, this change detaches a device > from its PM domain whenever it is shutdown. This action is basically > analogous to ->remove() from driver model perspective. Detaching the > device from its PM domain ensures that the ACPI PM gets a chance to > turn off the power resources for the device thus complying with its > power sequencing requirements. > > Signed-off-by: Furquan Shaikh > --- > drivers/base/core.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/base/core.c b/drivers/base/core.c > index d661ada1518f..5823f1d719e1 100644 > --- a/drivers/base/core.c > +++ b/drivers/base/core.c > @@ -23,6 +23,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -4057,6 +4058,8 @@ void device_shutdown(void) > dev->driver->shutdown(dev); > } > > + dev_pm_domain_detach(dev, true); > + > device_unlock(dev); > if (parent) > device_unlock(parent); > -- > 2.29.2.454.gaff20da3a2-goog > Hello, Gentle ping. Just checking if there are any comments. Thanks, Furquan
Re: [GIT PULL] keys: Collected minor fixes and cleanups
On Mon, Dec 14, 2020 at 12:49:27PM -0800, Linus Torvalds wrote: > The pain just isn't worth it, but more importantly, you simply need to > get your workflow in order, and not send me completely untested > garbage that hasn't even been compiled. I have now more bandwidth. It was mostly eaten by SGX, especially last few months. Starting from next week, I'll start proactively test keyring changes (I'm this week on vacation). I've been thinking that maybe a two-folded approach would make sense for keyring: 1. I would pick fixes to my linux-tpmdd where they would get quickly mirrored to linux-next. It's already taking changes for trusted keys, i.e. not solely for TPM changes. 2. Feature changes would go through David's tree. >Linus /Jarkko
Re: [PATCH V2 2/2] arm64: topology: Reorder init_amu_fie() a bit
On 14-12-20, 14:00, Ionela Voinescu wrote: > I think there could be a potential problem here (it would be unlikely > but why not fix it :) ). It was in the code before your changes. > > When we enable amu_fie_key here, topology_scale_freq_tick() could be > called for AMU CPUs, which will compute and set a scale factor. Later > on, if we happen to find the system not invariant, we disable counter > based invariance, but a scale factor might have been set already for a > CPU, which would and should have returned 1024 otherwise (the > initialisation value of freq_scale). > > > Therefore, while here, you could instead do the following: > > cpufreq_inv = cpufreq_supports_freq_invariance(); > > if (!cpufreq_inv && > !cpumask_subset(cpu_online_mask, amu_fie_cpus)) > goto free_valid_mask; > > static_branch_enable(_fie_key); > > pr_info(..); > > if (!cpufreq_inv) > rebuild_sched_domains_energy(); > > What do you think? I already had a patch for this, but for a different reason, i.e. to avoid the enable/disable dance. /* We aren't fully invariant yet */ if (!prev && !cpumask_equal(amu_fie_cpus, cpu_present_mask)) return; And this is quite similar to what you have here. -- viresh
Re: linux-next: manual merge of the parisc-hd tree with the asm-generic tree
On 12/14/20 8:48 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 2 Nov 2020 12:38:41 +1100 Stephen Rothwell
> wrote:
>>
>> Today's linux-next merge of the parisc-hd tree got a conflict in:
>>
>> arch/parisc/kernel/time.c
>>
>> between commit:
>>
>> 686092e7daaa ("parisc: use legacy_timer_tick")
>>
>> from the asm-generic tree and commit:
>>
>> 3b7ab4a74a2d ("parisc: Switch to clockevent based timers")
>>
>> from the parisc-hd tree.
>>
>> I fixed it up (I effectively reverted the former commit) and can carry the
>> fix as necessary. This is now fixed as far as linux-next is concerned,
>> but any non trivial conflicts should be mentioned to your upstream
>> maintainer when your tree is submitted for merging. You may also want
>> to consider cooperating with the maintainer of the conflicting tree to
>> minimise any particularly complex conflicts.
>
> This is just a reminder that this conflict still exists.
I dropped the patch from the parisc-hd tree for now -
it needs more work and will not be part of the next merge window.
Thanks,
Helge
signature.asc
Description: OpenPGP digital signature
RE: [PATCH v3 5/6] Drivers: hv: vmbus: Resolve race condition in vmbus_onoffer_rescind()
From: Andrea Parri (Microsoft) Sent: Tuesday, December
8, 2020 11:08 PM
>
> An erroneous or malicious host could send multiple rescind messages for
> a same channel. In vmbus_onoffer_rescind(), the guest maps the channel
> ID to obtain a pointer to the channel object and it eventually releases
> such object and associated data. The host could time rescind messages
> and lead to an use-after-free. Add a new flag to the channel structure
> to make sure that only one instance of vmbus_onoffer_rescind() can get
> the reference to the channel object.
>
> Reported-by: Juan Vazquez
> Signed-off-by: Andrea Parri (Microsoft)
> ---
> drivers/hv/channel_mgmt.c | 12
> include/linux/hyperv.h| 1 +
> 2 files changed, 13 insertions(+)
>
> diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
> index 4072fd1f22146..68950a1e4b638 100644
> --- a/drivers/hv/channel_mgmt.c
> +++ b/drivers/hv/channel_mgmt.c
> @@ -1063,6 +1063,18 @@ static void vmbus_onoffer_rescind(struct
> vmbus_channel_message_header *hdr)
>
> mutex_lock(_connection.channel_mutex);
> channel = relid2channel(rescind->child_relid);
> + if (channel != NULL) {
> + /*
> + * Guarantee that no other instance of vmbus_onoffer_rescind()
> + * has got a reference to the channel object. Synchronize on
> + * _connection.channel_mutex.
> + */
> + if (channel->rescind_ref) {
> + mutex_unlock(_connection.channel_mutex);
> + return;
> + }
> + channel->rescind_ref = true;
> + }
> mutex_unlock(_connection.channel_mutex);
>
> if (channel == NULL) {
> diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
> index 2ea967bc17adf..f0d48a368f131 100644
> --- a/include/linux/hyperv.h
> +++ b/include/linux/hyperv.h
> @@ -809,6 +809,7 @@ struct vmbus_channel {
> u8 monitor_bit;
>
> bool rescind; /* got rescind msg */
> + bool rescind_ref; /* got rescind msg, got channel reference */
> struct completion rescind_event;
>
> u32 ringbuffer_gpadlhandle;
> --
> 2.25.1
Reviewed-by: Michael Kelley
Re: [PATCH v2 2/2] Documentation: fpga: dfl: Add description for DFL UIO support
On 12/14/20 6:22 PM, Xu Yilun wrote: > On Mon, Dec 14, 2020 at 02:14:56PM -0800, Tom Rix wrote: >> On 12/13/20 7:36 PM, Xu Yilun wrote: >>> This patch adds description for UIO support for dfl devices on DFL >>> bus. >>> >>> Signed-off-by: Xu Yilun >>> --- >>> v2: no doc in v1, add it for v2. >>> --- >> >>> +components. They could instantiate a new private feature in the DFL, and >>> then >>> +get a DFL device in their system. In some cases users may need a userspace >>> +driver for the DFL device: >>> + >>> +* Users may need to run some diagnostic test for their hardwares. >> * Users may prototype the kernel driver in user space. > Could we just add the line rather than replacing the previous line? I think > this > comment is describing a different usecase. Yes, this is what i ment, please use your original. I am offering another usecase, one I will use. Add mine as well, if you want. > >>> +* Some hardware is designed for specific purposes and does not fit into >>> one of >>> + the standard kernel subsystems. >>> + >>> +This requires the direct access to the MMIO space and interrupt handling in >>> +userspace. We implemented a dfl-uio-pdev module which exposes the UIO >>> device >> The dfl-uio-pdev module exposes > Will change it. > >>> +interfaces. It adds the uio_pdrv_genirq platform device with the resources >>> of >>> +the DFL device, and let the generic UIO platform device driver provide UIO >> the DLF device, and lets > Will change it. > >>> +support to userspace. >> Use FPGA_DFL_UIO_PDEV to enable this feature. > I didn't get your idea for this. I wanted the user to know which kconfig controls this feature. Leave it out if you don't think it fits. > >>> + >>> +The DFL UIO driver has a special matching algorithem. It will match any DFL >>> +device which could not be handled by other DFL drivers. In this way, it >>> will >>> +not impact the functionality of the features which are already supported >>> by the >>> +system. >> (not sure if this section is needed) > I think we may keep it. Ok. Tom > > Thanks, > Yilun >
Re: BUG: soft lockup in mac80211_hwsim_beacon
syzbot has found a reproducer for the following issue on: HEAD commit:2c85ebc5 Linux 5.10 git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=148fcc1350 kernel config: https://syzkaller.appspot.com/x/.config?x=8aff533d6c635e6 dashboard link: https://syzkaller.appspot.com/bug?extid=d6219cf21f26bdfcc22e compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1102527b50 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+d6219cf21f26bdfcc...@syzkaller.appspotmail.com watchdog: BUG: soft lockup - CPU#1 stuck for 134s! [syz-executor.4:10844] Modules linked in: irq event stamp: 16682675 hardirqs last enabled at (16682674): [] asm_sysvec_irq_work+0x12/0x20 arch/x86/include/asm/idtentry.h:657 hardirqs last disabled at (16682675): [] sysvec_apic_timer_interrupt+0xc/0x100 arch/x86/kernel/apic/apic.c:1091 softirqs last enabled at (11305198): [] asm_call_irq_on_stack+0xf/0x20 softirqs last disabled at (11305201): [] asm_call_irq_on_stack+0xf/0x20 CPU: 1 PID: 10844 Comm: syz-executor.4 Not tainted 5.10.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__iterate_interfaces+0x14b/0x520 net/mac80211/util.c:786 Code: 31 ff 44 89 fe e8 05 a8 1d f9 45 85 ff 0f 84 9a 01 00 00 e8 a7 af 1d f9 48 8d bb 50 06 00 00 48 89 f8 48 c1 e8 03 0f b6 04 28 <84> c0 74 08 3c 03 0f 8e a8 03 00 00 8b 83 50 06 00 00 31 ff 83 e0 RSP: 0018:c9d90a68 EFLAGS: 0212 RAX: RBX: 8880276ccc00 RCX: 885254eb RDX: 8880213c3480 RSI: 885254f9 RDI: 8880276cd250 RBP: dc00 R08: R09: 8ebb0667 R10: R11: R12: 8880276cde18 R13: R14: 88803d37a5b8 R15: 0002 FS: () GS:8880b9f0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 016b9e60 CR3: 3ca03000 CR4: 00350ee0 Call Trace: ieee80211_iterate_active_interfaces_atomic+0x8d/0x170 net/mac80211/util.c:828 mac80211_hwsim_addr_match+0x128/0x180 drivers/net/wireless/mac80211_hwsim.c:1060 mac80211_hwsim_tx_frame_no_nl.isra.0+0xb3d/0x1330 drivers/net/wireless/mac80211_hwsim.c:1498 mac80211_hwsim_tx_frame+0x14f/0x1e0 drivers/net/wireless/mac80211_hwsim.c:1705 mac80211_hwsim_beacon_tx+0x4ba/0x910 drivers/net/wireless/mac80211_hwsim.c:1759 __iterate_interfaces+0x1e5/0x520 net/mac80211/util.c:792 ieee80211_iterate_active_interfaces_atomic+0x8d/0x170 net/mac80211/util.c:828 mac80211_hwsim_beacon+0xd5/0x1a0 drivers/net/wireless/mac80211_hwsim.c:1782 __run_hrtimer kernel/time/hrtimer.c:1519 [inline] __hrtimer_run_queues+0x693/0xea0 kernel/time/hrtimer.c:1583 hrtimer_run_softirq+0x17b/0x360 kernel/time/hrtimer.c:1600 __do_softirq+0x2a0/0x9f6 kernel/softirq.c:298 asm_call_irq_on_stack+0xf/0x20 __run_on_irqstack arch/x86/include/asm/irq_stack.h:26 [inline] run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:77 [inline] do_softirq_own_stack+0xaa/0xd0 arch/x86/kernel/irq_64.c:77 invoke_softirq kernel/softirq.c:393 [inline] __irq_exit_rcu kernel/softirq.c:423 [inline] irq_exit_rcu+0x132/0x200 kernel/softirq.c:435 sysvec_apic_timer_interrupt+0x4d/0x100 arch/x86/kernel/apic/apic.c:1091 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:631 RIP: 0010:mm_update_next_owner+0x432/0x7a0 kernel/exit.c:387 Code: 8d ad 00 fc ff ff 48 81 fd 80 b3 09 8b 0f 84 65 01 00 00 e8 00 01 2e 00 48 8d bd 24 fc ff ff 48 89 f8 48 c1 e8 03 0f b6 14 18 <48> 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 b5 02 00 00 44 RSP: 0018:c90001bafb28 EFLAGS: 0213 RAX: 1110035d4004 RBX: dc00 RCX: 814203df RDX: RSI: 814203a0 RDI: 88801aea0024 RBP: 88801aea0400 R08: 0001 R09: 8b00a083 R10: R11: R12: 88802f0c6c00 R13: 88801aea R14: 0020 R15: 888140758010 exit_mm kernel/exit.c:485 [inline] do_exit+0xa6a/0x29b0 kernel/exit.c:796 do_group_exit+0x125/0x310 kernel/exit.c:906 get_signal+0x42a/0x1f10 kernel/signal.c:2758 arch_do_signal+0x82/0x2390 arch/x86/kernel/signal.c:811 exit_to_user_mode_loop kernel/entry/common.c:161 [inline] exit_to_user_mode_prepare+0x100/0x1a0 kernel/entry/common.c:191 irqentry_exit_to_user_mode+0x5/0x30 kernel/entry/common.c:279 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:631 RIP: 0033:0x45e159 Code: Unable to access opcode bytes at RIP 0x45e12f. RSP: 002b:7fabdf0dac68 EFLAGS: 0246 RAX: 20ffc000 RBX: 0006 RCX: 0045e159 RDX: RSI: 3000 RDI: 20ffc000 RBP: 0119c080 R08: 0004 R09: R10: 0011 R11: 0246 R12: 0119c034 R13:
