[PATCH -next] ext4: fix error return code in ext4_fc_perform_commit()
In case of if not ext4_fc_add_tlv branch, an error return code is missing.
Fixes: aa75f4d3daae ("ext4: main fast-commit commit path")
Reported-by: Hulk Robot
Signed-off-by: Xu Yihang
---
fs/ext4/fast_commit.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c
index 7541d0b5d706..312273ed8a9f 100644
--- a/fs/ext4/fast_commit.c
+++ b/fs/ext4/fast_commit.c
@@ -1088,8 +1088,10 @@ static int ext4_fc_perform_commit(journal_t *journal)
head.fc_tid = cpu_to_le32(
sbi->s_journal->j_running_transaction->t_tid);
if (!ext4_fc_add_tlv(sb, EXT4_FC_TAG_HEAD, sizeof(head),
- (u8 *)&head, &crc))
+ (u8 *)&head, &crc)) {
+ ret = -ENOSPC;
goto out;
+ }
}
spin_lock(&sbi->s_fc_lock);
--
2.17.1
Re: [RFC PATCH 24/37] mm: implement speculative handling in __do_fault()
On Wed, Apr 07, 2021 at 10:27:12PM +0100, Matthew Wilcox wrote: > Doing I/O without any lock held already works; it just uses the file > refcount. It would be better to use a vma refcount, as I already said. The original workload that I developed SPF for (wy back when) was prefaulting a single huge vma. Using a vma refcount was a total loss because it resulted in the same cacheline contention that down_read() was having. As such, I'm always incredibly sad to see mention of vma refcounts. They're fundamentally not solving the problem :/
Re: [PATCH] Revert "drm/syncobj: use dma_fence_get_stub"
Am 08.04.21 um 06:59 schrieb David Stevens:
From: David Stevens
This reverts commit 86bbd89d5da66fe760049ad3f04adc407ec0c4d6.
Using the singleton stub fence in drm_syncobj_assign_null_handle means
that all syncobjs created in an already signaled state or any syncobjs
signaled by userspace will reference the singleton fence when exported
to a sync_file. If those sync_files are queried with SYNC_IOC_FILE_INFO,
then the timestamp_ns value returned will correspond to whenever the
singleton stub fence was first initialized. This can break the ability
of userspace to use timestamps of these fences, as the singleton stub
fence's timestamp bears no relationship to any meaningful event.
And why exactly is having the timestamp of the call to
drm_syncobj_assign_null_handle() better?
Additional if you really need that please don't revert the patch.
Instead provide a function which returns a newly initialized stub fence
in the dma_fence.c code.
Regards,
Christian.
Signed-off-by: David Stevens
---
drivers/gpu/drm/drm_syncobj.c | 58 ++-
1 file changed, 44 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 349146049849..7cc11f1a83f4 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -211,6 +211,21 @@ struct syncobj_wait_entry {
static void syncobj_wait_syncobj_func(struct drm_syncobj *syncobj,
struct syncobj_wait_entry *wait);
+struct drm_syncobj_stub_fence {
+ struct dma_fence base;
+ spinlock_t lock;
+};
+
+static const char *drm_syncobj_stub_fence_get_name(struct dma_fence *fence)
+{
+ return "syncobjstub";
+}
+
+static const struct dma_fence_ops drm_syncobj_stub_fence_ops = {
+ .get_driver_name = drm_syncobj_stub_fence_get_name,
+ .get_timeline_name = drm_syncobj_stub_fence_get_name,
+};
+
/**
* drm_syncobj_find - lookup and reference a sync object.
* @file_private: drm file private pointer
@@ -344,18 +359,24 @@ void drm_syncobj_replace_fence(struct drm_syncobj
*syncobj,
}
EXPORT_SYMBOL(drm_syncobj_replace_fence);
-/**
- * drm_syncobj_assign_null_handle - assign a stub fence to the sync object
- * @syncobj: sync object to assign the fence on
- *
- * Assign a already signaled stub fence to the sync object.
- */
-static void drm_syncobj_assign_null_handle(struct drm_syncobj *syncobj)
+static int drm_syncobj_assign_null_handle(struct drm_syncobj *syncobj)
{
- struct dma_fence *fence = dma_fence_get_stub();
+ struct drm_syncobj_stub_fence *fence;
- drm_syncobj_replace_fence(syncobj, fence);
- dma_fence_put(fence);
+ fence = kzalloc(sizeof(*fence), GFP_KERNEL);
+ if (fence == NULL)
+ return -ENOMEM;
+
+ spin_lock_init(&fence->lock);
+ dma_fence_init(&fence->base, &drm_syncobj_stub_fence_ops,
+ &fence->lock, 0, 0);
+ dma_fence_signal(&fence->base);
+
+ drm_syncobj_replace_fence(syncobj, &fence->base);
+
+ dma_fence_put(&fence->base);
+
+ return 0;
}
/* 5s default for wait submission */
@@ -469,6 +490,7 @@ EXPORT_SYMBOL(drm_syncobj_free);
int drm_syncobj_create(struct drm_syncobj **out_syncobj, uint32_t flags,
struct dma_fence *fence)
{
+ int ret;
struct drm_syncobj *syncobj;
syncobj = kzalloc(sizeof(struct drm_syncobj), GFP_KERNEL);
@@ -479,8 +501,13 @@ int drm_syncobj_create(struct drm_syncobj **out_syncobj,
uint32_t flags,
INIT_LIST_HEAD(&syncobj->cb_list);
spin_lock_init(&syncobj->lock);
- if (flags & DRM_SYNCOBJ_CREATE_SIGNALED)
- drm_syncobj_assign_null_handle(syncobj);
+ if (flags & DRM_SYNCOBJ_CREATE_SIGNALED) {
+ ret = drm_syncobj_assign_null_handle(syncobj);
+ if (ret < 0) {
+ drm_syncobj_put(syncobj);
+ return ret;
+ }
+ }
if (fence)
drm_syncobj_replace_fence(syncobj, fence);
@@ -1322,8 +1349,11 @@ drm_syncobj_signal_ioctl(struct drm_device *dev, void
*data,
if (ret < 0)
return ret;
- for (i = 0; i < args->count_handles; i++)
- drm_syncobj_assign_null_handle(syncobjs[i]);
+ for (i = 0; i < args->count_handles; i++) {
+ ret = drm_syncobj_assign_null_handle(syncobjs[i]);
+ if (ret < 0)
+ break;
+ }
drm_syncobj_array_free(syncobjs, args->count_handles);
Re: [PATCH 06/25] HID: usbhid: Repair a formatting issue in a struct description
On Wed, 07 Apr 2021, Benjamin Tissoires wrote:
> On Fri, Mar 26, 2021 at 3:35 PM Lee Jones wrote:
> >
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/hid/usbhid/usbkbd.c:66: warning: bad line: should
> > be on
> >
> > Cc: Jiri Kosina
> > Cc: Benjamin Tissoires
> > Cc: message to
> > Cc: linux-...@vger.kernel.org
> > Cc: linux-in...@vger.kernel.org
> > Signed-off-by: Lee Jones
> > ---
> > drivers/hid/usbhid/usbkbd.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c
> > index d5b7a696a68c5..d0c640be8a885 100644
> > --- a/drivers/hid/usbhid/usbkbd.c
> > +++ b/drivers/hid/usbhid/usbkbd.c
> > @@ -63,7 +63,7 @@ static const unsigned char usb_kbd_keycode[256] = {
> > * new key is pressed or a key that was pressed is released.
> > * @led: URB for sending LEDs (e.g. numlock, ...)
> > * @newleds: data that will be sent with the @led URB representing which
> > LEDs
> > - should be on
> > + * should be on
>
> nitpick: checkpatch complains about spaces before tabs here.
>
> I amended locally and will push the fixed version.
Those are usually highlighted in my editor.
I wonder how I missed them.
Thanks for cleaning it up though.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
[Outreachy kernel] [PATCH v4] staging: rtl8723bs: hal: Remove camelcase in sdio_ops.c
Remove camelcase. Issue detected by checkpatch.pl. For now, change only
names of static functions in order to not break the driver's code.
Signed-off-by: Fabio M. De Francesco
---
Changes from v3: fix errors in the format of the patch.
Changes from v2: Remove unnecessary comment. Shortened a function name.
Changes from v1: No changes to the code but only to the subject for the
purpose to differentiate this patch because other removes of camelcase
have been made in other files of the same directory.
drivers/staging/rtl8723bs/hal/sdio_ops.c | 46 +++-
1 file changed, 21 insertions(+), 25 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/sdio_ops.c
b/drivers/staging/rtl8723bs/hal/sdio_ops.c
index 8df3350d53fb..af7f846f90fe 100644
--- a/drivers/staging/rtl8723bs/hal/sdio_ops.c
+++ b/drivers/staging/rtl8723bs/hal/sdio_ops.c
@@ -19,7 +19,7 @@
/* */
/* Creadted by Roger, 2011.01.31. */
/* */
-static void HalSdioGetCmdAddr8723BSdio(
+static void hal_sdio_get_cmd_addr_8723b(
struct adapter *adapter,
u8 device_id,
u32 addr,
@@ -95,10 +95,6 @@ static u8 get_deviceid(u32 addr)
return devide_id;
}
-/*
- * Ref:
- *HalSdioGetCmdAddr8723BSdio()
- */
static u32 _cvrt2ftaddr(const u32 addr, u8 *pdevice_id, u16 *poffset)
{
u8 device_id;
@@ -426,7 +422,7 @@ static u32 sdio_read_port(
psdio = &adapter_to_dvobj(adapter)->intf_data;
hal = GET_HAL_DATA(adapter);
- HalSdioGetCmdAddr8723BSdio(adapter, addr, hal->SdioRxFIFOCnt++, &addr);
+ hal_sdio_get_cmd_addr_8723b(adapter, addr, hal->SdioRxFIFOCnt++, &addr);
if (cnt > psdio->block_transfer_len)
cnt = _RND(cnt, psdio->block_transfer_len);
@@ -473,7 +469,7 @@ static u32 sdio_write_port(
return _FAIL;
cnt = round_up(cnt, 4);
- HalSdioGetCmdAddr8723BSdio(adapter, addr, cnt >> 2, &addr);
+ hal_sdio_get_cmd_addr_8723b(adapter, addr, cnt >> 2, &addr);
if (cnt > psdio->block_transfer_len)
cnt = _RND(cnt, psdio->block_transfer_len);
@@ -526,7 +522,7 @@ static s32 _sdio_local_read(
intfhdl = &adapter->iopriv.intf;
- HalSdioGetCmdAddr8723BSdio(adapter, SDIO_LOCAL_DEVICE_ID, addr, &addr);
+ hal_sdio_get_cmd_addr_8723b(adapter, SDIO_LOCAL_DEVICE_ID, addr, &addr);
rtw_hal_get_hwreg(adapter, HW_VAR_APFM_ON_MAC, &mac_pwr_ctrl_on);
if (!mac_pwr_ctrl_on)
@@ -564,7 +560,7 @@ s32 sdio_local_read(
intfhdl = &adapter->iopriv.intf;
- HalSdioGetCmdAddr8723BSdio(adapter, SDIO_LOCAL_DEVICE_ID, addr, &addr);
+ hal_sdio_get_cmd_addr_8723b(adapter, SDIO_LOCAL_DEVICE_ID, addr, &addr);
rtw_hal_get_hwreg(adapter, HW_VAR_APFM_ON_MAC, &mac_pwr_ctrl_on);
if (
@@ -610,7 +606,7 @@ s32 sdio_local_write(
intfhdl = &adapter->iopriv.intf;
- HalSdioGetCmdAddr8723BSdio(adapter, SDIO_LOCAL_DEVICE_ID, addr, &addr);
+ hal_sdio_get_cmd_addr_8723b(adapter, SDIO_LOCAL_DEVICE_ID, addr, &addr);
rtw_hal_get_hwreg(adapter, HW_VAR_APFM_ON_MAC, &mac_pwr_ctrl_on);
if (
@@ -637,24 +633,24 @@ u8 SdioLocalCmd52Read1Byte(struct adapter *adapter, u32
addr)
u8 val = 0;
struct intf_hdl *intfhdl = &adapter->iopriv.intf;
- HalSdioGetCmdAddr8723BSdio(adapter, SDIO_LOCAL_DEVICE_ID, addr, &addr);
+ hal_sdio_get_cmd_addr_8723b(adapter, SDIO_LOCAL_DEVICE_ID, addr, &addr);
sd_cmd52_read(intfhdl, addr, 1, &val);
return val;
}
-static u16 SdioLocalCmd52Read2Byte(struct adapter *adapter, u32 addr)
+static u16 sdio_local_cmd52_read2byte(struct adapter *adapter, u32 addr)
{
__le16 val = 0;
struct intf_hdl *intfhdl = &adapter->iopriv.intf;
- HalSdioGetCmdAddr8723BSdio(adapter, SDIO_LOCAL_DEVICE_ID, addr, &addr);
+ hal_sdio_get_cmd_addr_8723b(adapter, SDIO_LOCAL_DEVICE_ID, addr, &addr);
sd_cmd52_read(intfhdl, addr, 2, (u8 *)&val);
return le16_to_cpu(val);
}
-static u32 SdioLocalCmd53Read4Byte(struct adapter *adapter, u32 addr)
+static u32 sdio_local_cmd53_read4byte(struct adapter *adapter, u32 addr)
{
u8 mac_pwr_ctrl_on;
@@ -662,7 +658,7 @@ static u32 SdioLocalCmd53Read4Byte(struct adapter *adapter,
u32 addr)
struct intf_hdl *intfhdl = &adapter->iopriv.intf;
__le32 le_tmp;
- HalSdioGetCmdAddr8723BSdio(adapter, SDIO_LOCAL_DEVICE_ID, addr, &addr);
+ hal_sdio_get_cmd_addr_8723b(adapter, SDIO_LOCAL_DEVICE_ID, addr, &addr);
rtw_hal_get_hwreg(adapter, HW_VAR_APFM_ON_MAC, &mac_pwr_ctrl_on);
if (!mac_pwr_ctrl_on || adapter_to_pwrctl(adapter)->bFwCurrentInPSMode)
{
sd_cmd52_read(intfhdl, addr, 4, (u8 *)&le_tmp);
@@ -677,21 +673,21 @@ void SdioLocalCmd52Write1Byte(struct adapter *adapter,
u32 addr, u8 v)
{
struct intf_hdl *intfhdl = &adapter->iopriv.intf;
- HalSdioGetCmdAddr8723BSdio(adapter, SDIO_LOCAL_DEVICE_ID, addr, &addr);
+ hal_sdio_get_
Re: [RESEND 00/25] Rid W=1 warnings from HID
On Wed, 07 Apr 2021, Benjamin Tissoires wrote: > On Tue, Apr 6, 2021 at 10:56 AM Lee Jones wrote: > > > > On Fri, 26 Mar 2021, Lee Jones wrote: > > > > > This set is part of a larger effort attempting to clean-up W=1 > > > kernel builds, which are currently overwhelmingly riddled with > > > niggly little warnings. > > > > > > Lee Jones (25): > > > HID: intel-ish-hid: Remove unused variable 'err' > > > HID: ishtp-hid-client: Move variable to where it's actually used > > > HID: intel-ish-hid: pci-ish: Remove unused variable 'ret' > > > HID: intel-ish: Supply some missing param descriptions > > > HID: intel-ish: Fix a naming disparity and a formatting error > > > HID: usbhid: Repair a formatting issue in a struct description > > > HID: intel-ish-hid: Fix a little doc-rot > > > HID: usbhid: hid-pidff: Demote a couple kernel-doc abuses > > > HID: hid-alps: Correct struct misnaming > > > HID: intel-ish-hid: Fix potential copy/paste error > > > HID: hid-core: Fix incorrect function name in header > > > HID: intel-ish-hid: ipc: Correct fw_reset_work_fn() function name in > > > header > > > HID: ishtp-hid-client: Fix incorrect function name report_bad_packet() > > > HID: hid-kye: Fix incorrect function name for kye_tablet_enable() > > > HID: hid-picolcd_core: Remove unused variable 'ret' > > > HID: hid-logitech-hidpp: Fix conformant kernel-doc header and demote > > > abuses > > > HID: hid-uclogic-rdesc: Kernel-doc is for functions and structs > > > HID: hid-thrustmaster: Demote a bunch of kernel-doc abuses > > > HID: hid-uclogic-params: Ensure function names are present and correct > > > in kernel-doc headers > > > HID: hid-sensor-custom: Remove unused variable 'ret' > > > HID: wacom_sys: Demote kernel-doc abuse > > > HID: hid-sensor-hub: Remove unused struct member 'quirks' > > > HID: hid-sensor-hub: Move 'hsdev' description to correct struct > > > definition > > > HID: intel-ish-hid: ishtp-fw-loader: Fix a bunch of formatting issues > > > HID: ishtp-hid-client: Fix 'suggest-attribute=format' compiler warning > > > > These have been on the list for a couple of weeks now. > > > > Is there anything I can do to help expedite their merge? > > > > I'm concerned since -rc6 has just been released. > > Sorry for the delay. > > I am currently queuing them locally and running a few tests on them. I > don't expect anything to happen, but better be safe than anything. > > FWIW, I am splitting the series in 3: > - 11 patches for intel ish are going to be queued in for-5.13/intel-ish > - the thrustmaster one in for-5.13/thrustmaster > - the rest (13 patches) will be sent in for-5.13/warnings. Sounds good to me. Thanks Benjamin. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH] USB:ehci:fix ehci hardware problem
When rebooting the EHCI driver, ehci_shutdown() will be called. if the sbrn flag is 0, ehci_shutdown() will return directly. Our EHCI hardware does not define the SBRN register, which cause its value to default to 0. The sbrn flag being 0 will cause the EHCI interrupt signal to not be turned off after reboot. An interrupt that is not closed will cause an exception to the device sharing the interrupt. Currently, our hardware has this problem. We hope to solve this problem by skipping reading the sbrn register value. On the next generation of hardware, we will define this SBRN register in accordance with the controller standard. Signed-off-by: Longfang Liu --- drivers/usb/host/ehci-pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c index 3c3820a..5dc6821 100644 --- a/drivers/usb/host/ehci-pci.c +++ b/drivers/usb/host/ehci-pci.c @@ -291,6 +291,8 @@ static int ehci_pci_setup(struct usb_hcd *hcd) if (pdev->vendor == PCI_VENDOR_ID_STMICRO && pdev->device == PCI_DEVICE_ID_STMICRO_USB_HOST) ; /* ConneXT has no sbrn register */ + else if (pdev->vendor == PCI_VENDOR_ID_HUAWEI) + ; /* sbrn register is undefined */ else pci_read_config_byte(pdev, 0x60, &ehci->sbrn); -- 2.8.1
Re: [GIT PULL] clk: imx: Updates for v5.13
Quoting Abel Vesa (2021-04-04 13:40:24) > The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15: > > Linux 5.12-rc2 (2021-03-05 17:33:41 -0800) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/abelvesa/linux.git clk/imx > > for you to fetch changes up to 054ef44ea3ef2883e0f63c9a54c91c07f321a0b4: > > clk: imx: Reference preceded by free (2021-04-04 22:39:05 +0300) > > Thanks. Pulled into clk-next. Next time can you send a signed tag with a small blurb about what is included?
Re: [PATCH] mtd: add OTP (one-time-programmable) erase ioctl
Hello, Michael Walle wrote on Thu, 08 Apr 2021 08:55:42 +0200: > Hi Tudor, > > Am 2021-04-08 07:51, schrieb tudor.amba...@microchip.com: > > Would you please resend this patch, together with the mtd-utils > > and the SPI NOR patch in a single patch set? You'll help us all > > having all in a single place. > > This has already been picked-up: > https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git/commit/?h=mtd/next&id=e3c1f1c92d6ede3cfa09d6a103d3d1c1ef645e35 > > Although, I didn't receive an email notice. > > -michael Sometimes the notifications are not triggered when there is a conflict when applying the patch from patchwork directly. I usually answer manually in this case but I might have forgotten. About the patch, I felt it was good enough for merging, and I want to avoid applying such patches right before freezing our branches. Hence, I tend to be more aggressive earlier in the release cycles because I hate when my patches get delayed infinitely. The other side is a more careful approach when -rc6 gets tagged so that I can drop anything which would be crazily broken before our -next branches are stalled, leading for an useless public revert. Of course, I am fully open to removing this patch from -next if you ever feel it was too early and will happily get rid of it for this release: we can move the patch for the next release if you agree on this (especially since it touches the ABI). Cheers, Miquèl
Re: [PATCH net-next v3 1/2] mfd: Add Renesas Synchronization Management Unit (SMU) support
On Wed, 07 Apr 2021, min.li...@renesas.com wrote: > From: Min Li > > Add support for ClockMatrix(TM) and 82P33xxx families of timing > and synchronization devices. The access interface can be either > SPI or I2C. Currently, it will create 2 types of MFD devices, > which are to be used by the corresponding rsmu character device > driver and the PTP hardware clock driver, respectively. > > Signed-off-by: Min Li > --- If this is v3, there should be a changelog here. > drivers/mfd/Kconfig | 28 ++ > drivers/mfd/Makefile | 3 + > drivers/mfd/rsmu_i2c.c | 349 + > drivers/mfd/rsmu_private.h | 32 ++ > drivers/mfd/rsmu_spi.c | 376 ++ > include/linux/mfd/idt82p33_reg.h | 116 ++ > include/linux/mfd/idt8a340_reg.h | 817 > +++ > include/linux/mfd/rsmu.h | 54 +++ > 8 files changed, 1775 insertions(+) > create mode 100644 drivers/mfd/rsmu_i2c.c > create mode 100644 drivers/mfd/rsmu_private.h > create mode 100644 drivers/mfd/rsmu_spi.c > create mode 100644 include/linux/mfd/idt82p33_reg.h > create mode 100644 include/linux/mfd/idt8a340_reg.h > create mode 100644 include/linux/mfd/rsmu.h -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH] media: ti-vpe: cal: Fix runtime PM imbalance in cal_probe
pm_runtime_get_sync() will increase the rumtime PM counter even it returns an error. Thus a pairing decrement is needed to prevent refcount leak. Fix this by replacing this API with pm_runtime_resume_and_get(), which will not change the runtime PM counter on error. Signed-off-by: Dinghao Liu --- drivers/media/platform/ti-vpe/cal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/ti-vpe/cal.c b/drivers/media/platform/ti-vpe/cal.c index fa0931788040..ce4e53b9be10 100644 --- a/drivers/media/platform/ti-vpe/cal.c +++ b/drivers/media/platform/ti-vpe/cal.c @@ -1010,7 +1010,7 @@ static int cal_probe(struct platform_device *pdev) /* Read the revision and hardware info to verify hardware access. */ pm_runtime_enable(&pdev->dev); - ret = pm_runtime_get_sync(&pdev->dev); + ret = pm_runtime_resume_and_get(&pdev->dev); if (ret) goto error_pm_runtime; -- 2.17.1
Re: [PATCH v2 3/6] usb: typec: tcpm: update power supply once partner accepts
On Wed, Apr 07, 2021 at 01:07:20PM -0700, Badhri Jagan Sridharan wrote:
> power_supply_changed needs to be called to notify clients
> after the partner accepts the requested values for the pps
> case.
>
> Also, remove the redundant power_supply_changed at the end
> of the tcpm_reset_port as power_supply_changed is already
> called right after usb_type is changed.
>
> Fixes: f2a8aa053c176 ("typec: tcpm: Represent source supply through
> power_supply")
> Signed-off-by: Badhri Jagan Sridharan
> Reviewed-by: Adam Thomson
Reviewed-by: Heikki Krogerus
> ---
> Changes since V1:
> * Updated commit description to clarify Guenter Roeck's concern.
> * Added Reviewed-by tags
> ---
> drivers/usb/typec/tcpm/tcpm.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index b4a40099d7e9..d1d03ee90d8f 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -2568,6 +2568,7 @@ static void tcpm_pd_ctrl_request(struct tcpm_port *port,
> port->pps_data.max_curr = port->pps_data.req_max_curr;
> port->req_supply_voltage = port->pps_data.req_out_volt;
> port->req_current_limit = port->pps_data.req_op_curr;
> + power_supply_changed(port->psy);
> tcpm_set_state(port, SNK_TRANSITION_SINK, 0);
> break;
> case SOFT_RESET_SEND:
> @@ -3136,7 +3137,6 @@ static unsigned int tcpm_pd_select_pps_apdo(struct
> tcpm_port *port)
>
> port->pps_data.req_out_volt));
> port->pps_data.req_op_curr = min(port->pps_data.max_curr,
>port->pps_data.req_op_curr);
> - power_supply_changed(port->psy);
> }
>
> return src_pdo;
> @@ -3561,8 +3561,6 @@ static void tcpm_reset_port(struct tcpm_port *port)
> port->sink_cap_done = false;
> if (port->tcpc->enable_frs)
> port->tcpc->enable_frs(port->tcpc, false);
> -
> - power_supply_changed(port->psy);
> }
>
> static void tcpm_detach(struct tcpm_port *port)
> --
> 2.31.1.295.g9ea45b61b8-goog
--
heikki
Re: [PATCH -next] drm/bridge: lt8912b: DRM_LONTIUM_LT8912B select GPIOLIB
Hello Robert I am sorry that I make a mistake about the compiling error of lt8912b, the reason is that lt8912b miss the header file . Although there are many files reference gpiod_set_value_cansleep() and devm_gpiod_get_optional(), they all include and not occur the compiling error like lt8912b. I have send the second version patch, please read. Best regards, Zhang Jianhua 在 2021/4/7 17:50, zhangjianhua (E) 写道: Thanks, I will do that. 在 2021/4/7 16:03, Robert Foss 写道: Yes, you are right, there are many files reference gpiod_set_value_cansleep() and devm_gpiod_get_optional(). How about add config dependencies for all releated I think this is the way to go and roughly half of the drm bridge drivers seem to need this change. Do you mind submitting a series of patches adding this fix for all of the relevant bridge drivers? configs or only add config dependencies for the top level config? .
Re: [PATCH v4 0/8] make hugetlb put_page safe for all calling contexts
On Wed, Apr 07, 2021 at 05:56:55PM -0700, Mike Kravetz wrote:
> Hello Andrew,
>
> It has been suggested that this series be included before Oscar Salvador's
> series "Make alloc_contig_range handle Hugetlb pages". At a logical
> level, here is what I think needs to happen. However, I am not sure how
> you do tree management and I am open to anything you suggest. Please do
> not start until we get an Ack from Oscar as he will need to participate.
As I said, this is fine by me.
I think it is the most straightforward way to proceed with this series
as this is a problem that has been bugging us fore quite some time now.
See below:
> Remove patches for the series "Make alloc_contig_range handle Hugetlb pages"
> from Oscar Salvador.
> - mm,page_alloc: drop unnecessary checks from pfn_range_valid_contig
> - mm: make alloc_contig_range handle in-use hugetlb pages
> - mm: make alloc_contig_range handle free hugetlb pages
Yes, those need to be removed
> /*
>* Technically, the following patches do not need to be removed as
>* they do not interact with Mike's changes. Again, they do
>* contain 'cover letter comments' in the commit messages which may
>* not make sense out of context.
>*/
> - mmcompaction-let-isolate_migratepages_rangeblock-return-error-codes-fix
> - mm,compaction: let isolate_migratepages_{range,block} return error codes
Those could stay as well, but they mention a change in
alloc_contig_range() and without the context of the whole patchset might
be misleading, so I would pull those out as well.
> - mm,page_alloc: bail out earlier on -ENOMEM in alloc_contig_migrate_range
I think this one can stay.
But if It is going to be easier for Andrew, just pull them all out and I
will resend the whole series once this work goes in.
Thanks!
--
Oscar Salvador
SUSE L3
[PATCH] dmaengine: tegra20: Fix runtime PM imbalance in tegra_dma_issue_pending
pm_runtime_get_sync() will increase the rumtime PM counter
even it returns an error. Thus a pairing decrement is needed
to prevent refcount leak. Fix this by replacing this API with
pm_runtime_resume_and_get(), which will not change the runtime
PM counter on error.
Signed-off-by: Dinghao Liu
---
drivers/dma/tegra20-apb-dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
index 71827d9b0aa1..73178afaf4c2 100644
--- a/drivers/dma/tegra20-apb-dma.c
+++ b/drivers/dma/tegra20-apb-dma.c
@@ -723,7 +723,7 @@ static void tegra_dma_issue_pending(struct dma_chan *dc)
goto end;
}
if (!tdc->busy) {
- err = pm_runtime_get_sync(tdc->tdma->dev);
+ err = pm_runtime_resume_and_get(tdc->tdma->dev);
if (err < 0) {
dev_err(tdc2dev(tdc), "Failed to enable DMA\n");
goto end;
--
2.17.1
Re: [PATCH v2 1/1] powerpc/iommu: Enable remaining IOMMU Pagesizes present in LoPAR
On 08/04/2021 15:37, Michael Ellerman wrote:
Leonardo Bras writes:
According to LoPAR, ibm,query-pe-dma-window output named "IO Page Sizes"
will let the OS know all possible pagesizes that can be used for creating a
new DDW.
Currently Linux will only try using 3 of the 8 available options:
4K, 64K and 16M. According to LoPAR, Hypervisor may also offer 32M, 64M,
128M, 256M and 16G.
Do we know of any hardware & hypervisor combination that will actually
give us bigger pages?
On P8 16MB host pages and 16MB hardware iommu pages worked.
On P9, VM's 16MB IOMMU pages worked on top of 2MB host pages + 2MB
hardware IOMMU pages.
Enabling bigger pages would be interesting for direct mapping systems
with a lot of RAM, while using less TCE entries.
Signed-off-by: Leonardo Bras
---
arch/powerpc/platforms/pseries/iommu.c | 49 ++
1 file changed, 42 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index 9fc5217f0c8e..6cda1c92597d 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -53,6 +53,20 @@ enum {
DDW_EXT_QUERY_OUT_SIZE = 2
};
A comment saying where the values come from would be good.
+#define QUERY_DDW_PGSIZE_4K0x01
+#define QUERY_DDW_PGSIZE_64K 0x02
+#define QUERY_DDW_PGSIZE_16M 0x04
+#define QUERY_DDW_PGSIZE_32M 0x08
+#define QUERY_DDW_PGSIZE_64M 0x10
+#define QUERY_DDW_PGSIZE_128M 0x20
+#define QUERY_DDW_PGSIZE_256M 0x40
+#define QUERY_DDW_PGSIZE_16G 0x80
I'm not sure the #defines really gain us much vs just putting the
literal values in the array below?
Then someone says "u magic values" :) I do not mind either way. Thanks,
+struct iommu_ddw_pagesize {
+ u32 mask;
+ int shift;
+};
+
static struct iommu_table_group *iommu_pseries_alloc_group(int node)
{
struct iommu_table_group *table_group;
@@ -1099,6 +1113,31 @@ static void reset_dma_window(struct pci_dev *dev, struct
device_node *par_dn)
ret);
}
+/* Returns page shift based on "IO Page Sizes" output at ibm,query-pe-dma-window. See LoPAR */
+static int iommu_get_page_shift(u32 query_page_size)
+{
+ const struct iommu_ddw_pagesize ddw_pagesize[] = {
+ { QUERY_DDW_PGSIZE_16G, __builtin_ctz(SZ_16G) },
+ { QUERY_DDW_PGSIZE_256M, __builtin_ctz(SZ_256M) },
+ { QUERY_DDW_PGSIZE_128M, __builtin_ctz(SZ_128M) },
+ { QUERY_DDW_PGSIZE_64M, __builtin_ctz(SZ_64M) },
+ { QUERY_DDW_PGSIZE_32M, __builtin_ctz(SZ_32M) },
+ { QUERY_DDW_PGSIZE_16M, __builtin_ctz(SZ_16M) },
+ { QUERY_DDW_PGSIZE_64K, __builtin_ctz(SZ_64K) },
+ { QUERY_DDW_PGSIZE_4K, __builtin_ctz(SZ_4K) }
+ };
cheers
--
Alexey
Re: [RFC PATCH 24/37] mm: implement speculative handling in __do_fault()
On Thu, Apr 08, 2021 at 09:00:26AM +0200, Peter Zijlstra wrote: > On Wed, Apr 07, 2021 at 10:27:12PM +0100, Matthew Wilcox wrote: > > Doing I/O without any lock held already works; it just uses the file > > refcount. It would be better to use a vma refcount, as I already said. > > The original workload that I developed SPF for (wy back when) was > prefaulting a single huge vma. Using a vma refcount was a total loss > because it resulted in the same cacheline contention that down_read() > was having. > > As such, I'm always incredibly sad to see mention of vma refcounts. > They're fundamentally not solving the problem :/ OK, let me outline my locking scheme because I think it's rather better than Michel's. The vma refcount is the slow path. 1. take the RCU read lock 2. walk the pgd/p4d/pud/pmd 3. allocate page tables if necessary. *handwave GFP flags*. 4. walk the vma tree 5. call ->map_pages 6. take ptlock 7. insert page(s) 8. drop ptlock if this all worked out, we're done, drop the RCU read lock and return. 9. increment vma refcount 10. drop RCU read lock 11. call ->fault 12. decrement vma refcount Compared to today, where we bump the refcount on the file underlying the vma, this is _better_ scalability -- different mappings of the same file will not contend on the file's refcount. I suspect your huge VMA was anon, and that wouldn't need a vma refcount as faulting in new pages doesn't need to do I/O, just drop the RCU lock, allocate and retry.
Re: [PATCH v6 3/5] i2c: add support for HiSilicon I2C controller
On 2021/4/8 7:04, Wolfram Sang wrote: > >> Reason for temp variable is for me it's confusing to see statement like >> "rate_khz = rate_khz / 1000". > > Yes. And with this clearer calculation, we can maybe skip the HZ_PER_KHZ > define completely and just use plain '1000' as a factor/divider because > it then becomes obvious. I still find the define more confusing than > helpful TBH. But I'll leave the final decision to Yicong Yang. > HZ_PER_KHZ macro are defined separately in other places of the kernel. Andy suggested to have this defined and used so that one day we can factor this macro out to the public. :)
Re: [PATCH] iommu/amd: page-specific invalidations for more than one page
Hi Nadav, On Wed, Apr 07, 2021 at 05:57:31PM +, Nadav Amit wrote: > I tested it on real bare-metal hardware. I ran some basic I/O workloads > with the IOMMU enabled, checkers enabled/disabled, and so on. > > However, I only tested the IOMMU-flushes and I did not test that the > device-IOTLB flush work, since I did not have the hardware for that. > > If you can refer me to the old patches, I will have a look and see > whether I can see a difference in the logic or test them. If you want > me to run different tests - let me know. If you want me to remove > the device-IOTLB invalidations logic - that is also fine with me. Here is the patch-set, it is from 2010 and against a very old version of the AMD IOMMU driver: https://lore.kernel.org/lkml/1265898797-32183-1-git-send-email-joerg.roe...@amd.com/ Regards, Joerg
[PATCH -next 1/7] crypto: sun4i-ss - Fix PM reference leak when pm_runtime_get_sync() fails
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Signed-off-by: Shixin Liu --- drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c | 2 +- drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c | 2 +- drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c | 2 +- drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c index c2e6f5ed1d79..dec79fa3ebaf 100644 --- a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c +++ b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c @@ -561,7 +561,7 @@ int sun4i_ss_cipher_init(struct crypto_tfm *tfm) sizeof(struct sun4i_cipher_req_ctx) + crypto_skcipher_reqsize(op->fallback_tfm)); - err = pm_runtime_get_sync(op->ss->dev); + err = pm_runtime_resume_and_get(op->ss->dev); if (err < 0) goto error_pm; diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c index ef224d5e4903..44b8fc4b786d 100644 --- a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c +++ b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c @@ -454,7 +454,7 @@ static int sun4i_ss_probe(struct platform_device *pdev) * this info could be useful */ - err = pm_runtime_get_sync(ss->dev); + err = pm_runtime_resume_and_get(ss->dev); if (err < 0) goto error_pm; diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c index c1b4585e9bbc..d28292762b32 100644 --- a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c +++ b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c @@ -27,7 +27,7 @@ int sun4i_hash_crainit(struct crypto_tfm *tfm) algt = container_of(alg, struct sun4i_ss_alg_template, alg.hash); op->ss = algt->ss; - err = pm_runtime_get_sync(op->ss->dev); + err = pm_runtime_resume_and_get(op->ss->dev); if (err < 0) return err; diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c index 443160a114bb..491fcb7b81b4 100644 --- a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c +++ b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c @@ -29,7 +29,7 @@ int sun4i_ss_prng_generate(struct crypto_rng *tfm, const u8 *src, algt = container_of(alg, struct sun4i_ss_alg_template, alg.rng); ss = algt->ss; - err = pm_runtime_get_sync(ss->dev); + err = pm_runtime_resume_and_get(ss->dev); if (err < 0) return err; -- 2.25.1
[PATCH -next 3/7] crypto: sun8i-ce - Fix PM reference leak in sun8i_ce_probe()
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Signed-off-by: Shixin Liu --- drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c index 158422ff5695..00194d1d9ae6 100644 --- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c +++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c @@ -932,7 +932,7 @@ static int sun8i_ce_probe(struct platform_device *pdev) if (err) goto error_alg; - err = pm_runtime_get_sync(ce->dev); + err = pm_runtime_resume_and_get(ce->dev); if (err < 0) goto error_alg; -- 2.25.1
[PATCH -next 5/7] crypto: stm32/cryp - Fix PM reference leak on stm32-cryp.c
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Signed-off-by: Shixin Liu --- drivers/crypto/stm32/stm32-cryp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/crypto/stm32/stm32-cryp.c b/drivers/crypto/stm32/stm32-cryp.c index 2a4793176c71..7389a0536ff0 100644 --- a/drivers/crypto/stm32/stm32-cryp.c +++ b/drivers/crypto/stm32/stm32-cryp.c @@ -542,7 +542,7 @@ static int stm32_cryp_hw_init(struct stm32_cryp *cryp) int ret; u32 cfg, hw_mode; - pm_runtime_get_sync(cryp->dev); + pm_runtime_resume_and_get(cryp->dev); /* Disable interrupt */ stm32_cryp_write(cryp, CRYP_IMSCR, 0); @@ -2043,7 +2043,7 @@ static int stm32_cryp_remove(struct platform_device *pdev) if (!cryp) return -ENODEV; - ret = pm_runtime_get_sync(cryp->dev); + ret = pm_runtime_resume_and_get(cryp->dev); if (ret < 0) return ret; -- 2.25.1
[PATCH -next 2/7] crypto: sun8i-ss - Fix PM reference leak when pm_runtime_get_sync() fails
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.
Signed-off-by: Shixin Liu
---
drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c | 2 +-
drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
index f945750b65d9..9ef1c85c4aaa 100644
--- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
+++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c
@@ -354,7 +354,7 @@ int sun8i_ss_cipher_init(struct crypto_tfm *tfm)
op->enginectx.op.prepare_request = NULL;
op->enginectx.op.unprepare_request = NULL;
- err = pm_runtime_get_sync(op->ss->dev);
+ err = pm_runtime_resume_and_get(op->ss->dev);
if (err < 0) {
dev_err(op->ss->dev, "pm error %d\n", err);
goto error_pm;
diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
index e0ddc684798d..80e89066dbd1 100644
--- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
+++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
@@ -753,7 +753,7 @@ static int sun8i_ss_probe(struct platform_device *pdev)
if (err)
goto error_alg;
- err = pm_runtime_get_sync(ss->dev);
+ err = pm_runtime_resume_and_get(ss->dev);
if (err < 0)
goto error_alg;
--
2.25.1
[PATCH -next 4/7] crypto: stm32/hash - Fix PM reference leak on stm32-hash.c
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.
Signed-off-by: Shixin Liu
---
drivers/crypto/stm32/stm32-hash.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/stm32/stm32-hash.c
b/drivers/crypto/stm32/stm32-hash.c
index 7ac0573ef663..389de9e3302d 100644
--- a/drivers/crypto/stm32/stm32-hash.c
+++ b/drivers/crypto/stm32/stm32-hash.c
@@ -813,7 +813,7 @@ static void stm32_hash_finish_req(struct ahash_request
*req, int err)
static int stm32_hash_hw_init(struct stm32_hash_dev *hdev,
struct stm32_hash_request_ctx *rctx)
{
- pm_runtime_get_sync(hdev->dev);
+ pm_runtime_resume_and_get(hdev->dev);
if (!(HASH_FLAGS_INIT & hdev->flags)) {
stm32_hash_write(hdev, HASH_CR, HASH_CR_INIT);
@@ -962,7 +962,7 @@ static int stm32_hash_export(struct ahash_request *req,
void *out)
u32 *preg;
unsigned int i;
- pm_runtime_get_sync(hdev->dev);
+ pm_runtime_resume_and_get(hdev->dev);
while ((stm32_hash_read(hdev, HASH_SR) & HASH_SR_BUSY))
cpu_relax();
@@ -1000,7 +1000,7 @@ static int stm32_hash_import(struct ahash_request *req,
const void *in)
preg = rctx->hw_context;
- pm_runtime_get_sync(hdev->dev);
+ pm_runtime_resume_and_get(hdev->dev);
stm32_hash_write(hdev, HASH_IMR, *preg++);
stm32_hash_write(hdev, HASH_STR, *preg++);
@@ -1566,7 +1566,7 @@ static int stm32_hash_remove(struct platform_device *pdev)
if (!hdev)
return -ENODEV;
- ret = pm_runtime_get_sync(hdev->dev);
+ ret = pm_runtime_resume_and_get(hdev->dev);
if (ret < 0)
return ret;
--
2.25.1
[PATCH -next 7/7] crypto: omap-aes - Fix PM reference leak on omap-aes.c
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.
Signed-off-by: Shixin Liu
---
drivers/crypto/omap-aes.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index a45bdcf3026d..0dd4c6b157de 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -103,9 +103,8 @@ static int omap_aes_hw_init(struct omap_aes_dev *dd)
dd->err = 0;
}
- err = pm_runtime_get_sync(dd->dev);
+ err = pm_runtime_resume_and_get(dd->dev);
if (err < 0) {
- pm_runtime_put_noidle(dd->dev);
dev_err(dd->dev, "failed to get sync: %d\n", err);
return err;
}
@@ -1134,7 +1133,7 @@ static int omap_aes_probe(struct platform_device *pdev)
pm_runtime_set_autosuspend_delay(dev, DEFAULT_AUTOSUSPEND_DELAY);
pm_runtime_enable(dev);
- err = pm_runtime_get_sync(dev);
+ err = pm_runtime_resume_and_get(dev);
if (err < 0) {
dev_err(dev, "%s: failed to get_sync(%d)\n",
__func__, err);
@@ -1303,7 +1302,7 @@ static int omap_aes_suspend(struct device *dev)
static int omap_aes_resume(struct device *dev)
{
- pm_runtime_get_sync(dev);
+ pm_runtime_resume_and_get(dev);
return 0;
}
#endif
--
2.25.1
[PATCH -next 6/7] crypto: sa2ul - Fix PM reference leak in sa_ul_probe()
pm_runtime_get_sync will increment pm usage counter even it failed.
Forgetting to putting operation will result in reference leak here.
Fix it by replacing it with pm_runtime_resume_and_get to keep usage
counter balanced.
Signed-off-by: Shixin Liu
---
drivers/crypto/sa2ul.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/sa2ul.c b/drivers/crypto/sa2ul.c
index f300b0a5958a..d7b1628fb484 100644
--- a/drivers/crypto/sa2ul.c
+++ b/drivers/crypto/sa2ul.c
@@ -2350,7 +2350,7 @@ static int sa_ul_probe(struct platform_device *pdev)
dev_set_drvdata(sa_k3_dev, dev_data);
pm_runtime_enable(dev);
- ret = pm_runtime_get_sync(dev);
+ ret = pm_runtime_resume_and_get(dev);
if (ret < 0) {
dev_err(&pdev->dev, "%s: failed to get sync: %d\n", __func__,
ret);
--
2.25.1
Re: [PATCH v2] firmware: qcom_scm: Only compile legacy calls on ARM
On Wed, Apr 07, 2021 at 05:12:06PM -0700, Stephen Boyd wrote: > Quoting Stephan Gerhold (2021-04-05 05:50:26) > > On Fri, Apr 02, 2021 at 10:21:58AM -0700, Stephen Boyd wrote: > > > > > > Ah right, the whole secure world running in 32-bit mode thing. Is > > > msm8916 the only SoC that's using that? Or are there more? If only > > > msm8916 is affected then we could use a combination of CONFIG_ARM64 and > > > the compatible string to differentiate and then if more SoCs use 32-bit > > > secure world then we could have a new compatible string like qcom,scm-32 > > > that tells us this fact. Maybe this was all discussed before and I > > > missed it. Either way, I'm trying to get rid of this boot call so that > > > we don't have to bounce to the firmware an extra time to figure out > > > something we can figure out from the kernel arch and scm compatible > > > string. > > > > At least MSM8994 also uses SMC32 from what I heard. Overall it's > > probably quite hard to get that right now since all boards were tested > > with the dynamic detection so far. I suppose you could do the opposite, > > add an optional qcom,scm-64 to skip the detection step and force SMC64. > > Isn't SMC64 going to be the overall majority going forward? Legacy > convention is for sure limited to CONFIG_ARM so I'll send another > follow-up patch to add a warning if we find legacy on CONFIG_ARM64. > SMC32 is hopefully no longer being produced given that it was introduced > at the time that the bootloader team wasn't supporting PSCI and didn't > want to support it. So we're making all new boards/SoCs/firmwares do > this calling convention probing to figure out something they already > know? > > Maybe we should probe the calling convention on msm8994/msm8916 and > otherwise assume SMC64 on CONFIG_ARM64 kernels. I'd expect the exception > list to be smaller that way. > Personally, I think it would be best to introduce a new, SMC64 only compatible (e.g. "qcom,scm-64" like I mentioned). Then you can skip the detection check for the boards that opt-in by adding the compatible. You can then use it on all newer boards/SoCs/firmwares where you know exactly that there is SMC64. I would just like to avoid breaking any existing boards where we don't know exactly if they have SMC32 or SMC64. > > > > Also note that this could even be firmware-specific, not necessarily > > SoC-specific. There are some ancient MSM8916 firmwares that have legacy > > instead of SMC32. I could also imagine that there is also some SoC where > > there are different firmware versions with SMC32 or SMC64. > > Sure but in theory the firmware would update the DT to indicate what > sort of firmware is there. > In a perfect world the firmware would do that, but there is certainly no such mechanism on any of the old SoCs :/ > > > > Plus, IMO the overhead for this detection is negligible. At least it > > ensures that we always use the right calling convention. The PSCI code > > probably does much more firmware calls to figure out all supported > > features. > > > > Heh, it tried to ensure we use the right calling convention but broke > things in the process, because the way of detecting the convention isn't > always there. I wouldn't be surprised if this comes up again for other > boards that use TF-A. Ah okay, this sounds like a better reason than just trying to avoid the "overhead" of the detection step. :) I still think it should work if you just start marking all newer boards/SoCs/... as "qcom,scm-64" or something like that, right? Thanks, Stephan
Re: [PATCH v4] gpio: mpc8xxx: Add ACPI support
On Tue, Apr 6, 2021 at 3:49 AM Ran Wang wrote: > Could this version be accepted, or any comment/suggestion? Andy says yes, then it is a yes :) FWIW Acked-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH] USB:ehci:fix ehci hardware problem
On 2021/4/8 15:03, Longfang Liu wrote: > When rebooting the EHCI driver, ehci_shutdown() will be called. > if the sbrn flag is 0, ehci_shutdown() will return directly. > > Our EHCI hardware does not define the SBRN register, which cause > its value to default to 0. The sbrn flag being 0 will cause the > EHCI interrupt signal to not be turned off after reboot. An interrupt > that is not closed will cause an exception to the device sharing > the interrupt. > > Currently, our hardware has this problem. We hope to solve this > problem by skipping reading the sbrn register value. On the next > generation of hardware, we will define this SBRN register in accordance > with the controller standard. > > Signed-off-by: Longfang Liu > --- > drivers/usb/host/ehci-pci.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c > index 3c3820a..5dc6821 100644 > --- a/drivers/usb/host/ehci-pci.c > +++ b/drivers/usb/host/ehci-pci.c > @@ -291,6 +291,8 @@ static int ehci_pci_setup(struct usb_hcd *hcd) > if (pdev->vendor == PCI_VENDOR_ID_STMICRO > && pdev->device == PCI_DEVICE_ID_STMICRO_USB_HOST) > ; /* ConneXT has no sbrn register */ > + else if (pdev->vendor == PCI_VENDOR_ID_HUAWEI) > + ; /* sbrn register is undefined */ > else > pci_read_config_byte(pdev, 0x60, &ehci->sbrn); > > Sorry, please ignore this patch, I will resend it. Thanks. Longfang.
Re: [PATCH-next] powerpc/interrupt: Remove duplicate header file
在 2021/4/8 12:57, Christophe Leroy 写道: Le 08/04/2021 à 05:56, johnny.che...@huawei.com a écrit : From: Chen Yi Delete one of the header files that are included twice. Guys, we have been flooded with such tiny patches over the last weeks, some changes being sent several times by different people. That one is included in https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20210323062916.295346-1-wanjiab...@vivo.com/ And was already submitted a few hours earlier by someone else: https://patchwork.ozlabs.org/project/linuxppc-dev/patch/1616464656-59372-1-git-send-email-zhouchuan...@vivo.com/ Could you work all together and cook an overall patch including all duplicate removal from arch/powerpc/ files ? Best way would be I think to file an issue at https://github.com/linuxppc/issues/issues , then you do a complete analysis and list in the issue all places to be modified, then once the analysis is complete you send a full single patch. Thanks Christophe Dear Christophe, Thanks for your reply, I have checked that thers is no header files which has been included twice by mistake in arch/powerpc/.I would file an issue next time. Best regards, Chen Yi Signed-off-by: Chen Yi --- arch/powerpc/kernel/interrupt.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/powerpc/kernel/interrupt.c b/arch/powerpc/kernel/interrupt.c index c4dd4b8f9cfa..f64ace0208b7 100644 --- a/arch/powerpc/kernel/interrupt.c +++ b/arch/powerpc/kernel/interrupt.c @@ -7,7 +7,6 @@ #include #include #include -#include #include #include #include .
[PATCH] slimbus: qcom-ngd-ctrl: Fix runtime PM imbalance in qcom_slim_ngd_enable
When slim_register_controller() fails, a pairing PM usage counter
increment is needed to keep the counter balanced.
Signed-off-by: Dinghao Liu
---
drivers/slimbus/qcom-ngd-ctrl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/slimbus/qcom-ngd-ctrl.c b/drivers/slimbus/qcom-ngd-ctrl.c
index c054e83ab636..99cf2ab3d862 100644
--- a/drivers/slimbus/qcom-ngd-ctrl.c
+++ b/drivers/slimbus/qcom-ngd-ctrl.c
@@ -1268,6 +1268,7 @@ static int qcom_slim_ngd_enable(struct qcom_slim_ngd_ctrl
*ctrl, bool enable)
ret = slim_register_controller(&ctrl->ctrl);
if (ret) {
dev_err(ctrl->dev, "error adding slim controller\n");
+ pm_runtime_get_noresume(ctrl->dev);
return ret;
}
--
2.17.1
Re: [PATCH v1 4/6] clk: qcom: Add graphics clock controller driver for SC7280
Quoting Taniya Das (2021-03-16 18:22:20)
> +static struct clk_regmap_div gpu_cc_hub_ahb_div_clk_src = {
> + .reg = 0x11c0,
> + .shift = 0,
> + .width = 4,
> + .clkr.hw.init = &(struct clk_init_data) {
> + .name = "gpu_cc_hub_ahb_div_clk_src",
> + .parent_data = &(const struct clk_parent_data){
> + .hw = &gpu_cc_hub_clk_src.clkr.hw,
Can you follow what Dmitry has done and use .hws instead of
clk_parent_data when the whole array is clk_hw pointers?
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_regmap_div_ro_ops,
> + },
> +};
> +
[PATCH] PCI: rcar: Fix runtime PM imbalance in rcar_pcie_ep_probe
pm_runtime_get_sync() will increase the runtime PM counter
even it returns an error. Thus a pairing decrement is needed
to prevent refcount leak. Fix this by replacing this API with
pm_runtime_resume_and_get(), which will not change the runtime
PM counter on error.
Signed-off-by: Dinghao Liu
---
drivers/pci/controller/pcie-rcar-ep.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pcie-rcar-ep.c
b/drivers/pci/controller/pcie-rcar-ep.c
index b4a288e24aaf..c91d85b15129 100644
--- a/drivers/pci/controller/pcie-rcar-ep.c
+++ b/drivers/pci/controller/pcie-rcar-ep.c
@@ -492,9 +492,9 @@ static int rcar_pcie_ep_probe(struct platform_device *pdev)
pcie->dev = dev;
pm_runtime_enable(dev);
- err = pm_runtime_get_sync(dev);
+ err = pm_runtime_resume_and_get(dev);
if (err < 0) {
- dev_err(dev, "pm_runtime_get_sync failed\n");
+ dev_err(dev, "pm_runtime_resume_and_get failed\n");
goto err_pm_disable;
}
--
2.17.1
Re: [PATCH] lib/string: Introduce sysfs_streqcase
On Wed, Apr 7, 2021 at 10:07 PM Nick Desaulniers wrote: > > On Tue, Apr 6, 2021 at 11:15 PM Gioh Kim wrote: > > > > As the name shows, it checks if strings are equal in case insensitive > > manner. > > > > For example, drivers/infiniband/ulp/rtrs/rtrs-clt-sysfs.c uses > > strncasecmp to check that the input via sysfs is "mi". But it would > > work even-if the input is "min-wrongcommand". > > > > I found some more cases using strncasecmp to check the entire string > > such as rtrs-clt-sysfs.c does. drivers/pnp/interface.c checks > > "disable" command with strncasecmp but it would also work if the > > command is "disable-wrong". > > Reviewed-by: Nick Desaulniers > > I do wonder if these (sysfs_streqcase and sysfs_streq) could or should > be conditionally available on CONFIG_SYSFS=y; don't pay for what you > don't use (without needing CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y)? Good idea. Thank you. > > Also, it might be nice to share the second half of the function with > sysfs_streq via a new static function. Though it will just get > inlined in both for CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y, it might > help the compiler if CONFIG_CC_OPTIMIZE_FOR_SIZE=y was instead chosen > if the compiler cannot outline/deduplicate the shared code. At the > least, there's less duplication between two very similar functions; if > one changes then authors may need to be careful to update both. Yes, they are exactly the same. I will make an inline function for the common code. > > Are either of those concerns worth a v3? ¯\_(ツ)_/¯ Sure, I will not forget to add 'V2'. Thank you for kind review.
Re: [PATCH 01/10] staging: rtl8188eu: remove unused macros
On Wed, Apr 07, 2021 at 07:05:22PM +0200, Martin Kaiser wrote: > usb_ops_linux.h contains a couple of macros to make functions usable as > urb completion callbacks. Most of them are unused and can be removed. > > Signed-off-by: Martin Kaiser > --- > drivers/staging/rtl8188eu/include/usb_ops_linux.h | 8 > 1 file changed, 8 deletions(-) > > diff --git a/drivers/staging/rtl8188eu/include/usb_ops_linux.h > b/drivers/staging/rtl8188eu/include/usb_ops_linux.h > index 4e0e48cb5c8e..1a0b38de5027 100644 > --- a/drivers/staging/rtl8188eu/include/usb_ops_linux.h > +++ b/drivers/staging/rtl8188eu/include/usb_ops_linux.h > @@ -23,18 +23,10 @@ > #define USB_HIGH_SPEED_BULK_SIZE 512 > #define USB_FULL_SPEED_BULK_SIZE 64 > > -#define _usbctrl_vendorreq_async_callback(urb, regs) \ > - _usbctrl_vendorreq_async_callback(urb) > -#define usb_bulkout_zero_complete(purb, regs)\ > - usb_bulkout_zero_complete(purb) > -#define usb_write_mem_complete(purb, regs) \ > - usb_write_mem_complete(purb) > #define usb_write_port_complete(purb, regs) \ > usb_write_port_complete(purb) > #define usb_read_port_complete(purb, regs) \ > usb_read_port_complete(purb) > -#define usb_read_interrupt_complete(purb, regs) \ > - usb_read_interrupt_complete(purb) Wow, that's there for a really old kernel version and should not be needed anymore at all. I'll take this, but please remove the other ones here, they are not necessary. thanks, greg k-h
[PATCH] PCI: tegra: Fix runtime PM imbalance in pex_ep_event_pex_rst_deassert
pm_runtime_get_sync() will increase the runtime PM counter
even it returns an error. Thus a pairing decrement is needed
to prevent refcount leak. Fix this by replacing this API with
pm_runtime_resume_and_get(), which will not change the runtime
PM counter on error.
Signed-off-by: Dinghao Liu
---
drivers/pci/controller/dwc/pcie-tegra194.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c
b/drivers/pci/controller/dwc/pcie-tegra194.c
index 6fa216e52d14..0e94190ca4e8 100644
--- a/drivers/pci/controller/dwc/pcie-tegra194.c
+++ b/drivers/pci/controller/dwc/pcie-tegra194.c
@@ -1645,7 +1645,7 @@ static void pex_ep_event_pex_rst_deassert(struct
tegra_pcie_dw *pcie)
if (pcie->ep_state == EP_STATE_ENABLED)
return;
- ret = pm_runtime_get_sync(dev);
+ ret = pm_runtime_resume_and_get(dev);
if (ret < 0) {
dev_err(dev, "Failed to get runtime sync for PCIe dev: %d\n",
ret);
--
2.17.1
Re: [RFC PATCH v2 2/2] kvm/arm64: Try stage2 block mapping for host device MMIO
Hi Marc,
On 2021/4/7 21:18, Marc Zyngier wrote:
> On Tue, 16 Mar 2021 13:43:38 +,
> Keqian Zhu wrote:
>>
>> The MMIO region of a device maybe huge (GB level), try to use
>> block mapping in stage2 to speedup both map and unmap.
>>
>> Compared to normal memory mapping, we should consider two more
>> points when try block mapping for MMIO region:
>>
>> 1. For normal memory mapping, the PA(host physical address) and
>> HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
>> the HVA to request hugepage, so we don't need to consider PA
>> alignment when verifing block mapping. But for device memory
>> mapping, the PA and HVA may have different alignment.
>>
>> 2. For normal memory mapping, we are sure hugepage size properly
>> fit into vma, so we don't check whether the mapping size exceeds
>> the boundary of vma. But for device memory mapping, we should pay
>> attention to this.
>>
>> This adds device_rough_page_shift() to check these two points when
>> selecting block mapping size.
>>
>> Signed-off-by: Keqian Zhu
>> ---
>>
>> Mainly for RFC, not fully tested. I will fully test it when the
>> code logic is well accepted.
>>
>> ---
>> arch/arm64/kvm/mmu.c | 42 ++
>> 1 file changed, 38 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>> index c59af5ca01b0..224aa15eb4d9 100644
>> --- a/arch/arm64/kvm/mmu.c
>> +++ b/arch/arm64/kvm/mmu.c
>> @@ -624,6 +624,36 @@ static void kvm_send_hwpoison_signal(unsigned long
>> address, short lsb)
>> send_sig_mceerr(BUS_MCEERR_AR, (void __user *)address, lsb, current);
>> }
>>
>> +/*
>> + * Find a mapping size that properly insides the intersection of vma and
>> + * memslot. And hva and pa have the same alignment to this mapping size.
>> + * It's rough because there are still other restrictions, which will be
>> + * checked by the following fault_supports_stage2_huge_mapping().
>
> I don't think these restrictions make complete sense to me. If this is
> a PFNMAP VMA, we should use the biggest mapping size that covers the
> VMA, and not more than the VMA.
But as described by kvm_arch_prepare_memory_region(), the memslot may not fully
cover the VMA. If that's true and we just consider the boundary of the VMA, our
block mapping may beyond the boundary of memslot. Is this a problem?
>
>> + */
>> +static short device_rough_page_shift(struct kvm_memory_slot *memslot,
>> + struct vm_area_struct *vma,
>> + unsigned long hva)
>> +{
>> +size_t size = memslot->npages * PAGE_SIZE;
>> +hva_t sec_start = max(memslot->userspace_addr, vma->vm_start);
>> +hva_t sec_end = min(memslot->userspace_addr + size, vma->vm_end);
>> +phys_addr_t pa = (vma->vm_pgoff << PAGE_SHIFT) + (hva - vma->vm_start);
>> +
>> +#ifndef __PAGETABLE_PMD_FOLDED
>> +if ((hva & (PUD_SIZE - 1)) == (pa & (PUD_SIZE - 1)) &&
>> +ALIGN_DOWN(hva, PUD_SIZE) >= sec_start &&
>> +ALIGN(hva, PUD_SIZE) <= sec_end)
>> +return PUD_SHIFT;
>> +#endif
>> +
>> +if ((hva & (PMD_SIZE - 1)) == (pa & (PMD_SIZE - 1)) &&
>> +ALIGN_DOWN(hva, PMD_SIZE) >= sec_start &&
>> +ALIGN(hva, PMD_SIZE) <= sec_end)
>> +return PMD_SHIFT;
>> +
>> +return PAGE_SHIFT;
>> +}
>> +
>> static bool fault_supports_stage2_huge_mapping(struct kvm_memory_slot
>> *memslot,
>> unsigned long hva,
>> unsigned long map_size)
>> @@ -769,7 +799,10 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
>> phys_addr_t fault_ipa,
>> return -EFAULT;
>> }
>>
>> -/* Let's check if we will get back a huge page backed by hugetlbfs */
>> +/*
>> + * Let's check if we will get back a huge page backed by hugetlbfs, or
>> + * get block mapping for device MMIO region.
>> + */
>> mmap_read_lock(current->mm);
>> vma = find_vma_intersection(current->mm, hva, hva + 1);
>> if (unlikely(!vma)) {
>> @@ -780,11 +813,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu,
>> phys_addr_t fault_ipa,
>>
>> if (is_vm_hugetlb_page(vma))
>> vma_shift = huge_page_shift(hstate_vma(vma));
>> +else if (vma->vm_flags & VM_PFNMAP)
>> +vma_shift = device_rough_page_shift(memslot, vma, hva);
>> else
>> vma_shift = PAGE_SHIFT;
>>
>> -if (logging_active ||
>> -(vma->vm_flags & VM_PFNMAP)) {
>> +if (logging_active) {
>> force_pte = true;
>> vma_shift = PAGE_SHIFT;
>
> But why should we downgrade to page-size mappings if logging? This is
> a device, and you aren't moving the device around, are you? Or is your
> device actually memory with a device mapping that you are trying to
> migrate?
Thanks for the point. We should not move the device around, so we do not
need to consider logging when we build mapping for device.
I fou
[PATCH v2 00/14] usb: dwc2: Fix Partial Power down issues.
This patch set fixes and improves the Partial Power Down mode for dwc2 core. It adds support for the following cases 1. Entering and exiting partial power down when a port is suspended, resumed, port reset is asserted. 2. Exiting the partial power down mode before removing driver. 3. Exiting partial power down in wakeup detected interrupt handler. 4. Exiting from partial power down mode when connector ID. status changes to "connId B It updates and fixes the implementation of dwc2 entering and exiting partial power down mode when the system (PC) is suspended. The patch set also improves the implementation of function handlers for entering and exiting host or device partial power down. NOTE: This is the second patch set in the power saving mode fixes series. This patch set is part of multiple series and is continuation of the "usb: dwc2: Fix and improve power saving modes" patch set. (Patch set link: https://marc.info/?l=linux-usb&m=160379622403975&w=2). The patches that were included in the "usb: dwc2: Fix and improve power saving modes" which was submitted earlier was too large and needed to be split up into smaller patch sets. Changes since V1: No changes in the patches or the source code. Sending the second version of the patch set because the first version was not received by vger.kernel.org. Artur Petrosyan (14): usb: dwc2: Add device partial power down functions usb: dwc2: Add host partial power down functions usb: dwc2: Update enter and exit partial power down functions usb: dwc2: Add partial power down exit flow in wakeup intr. usb: dwc2: Update port suspend/resume function definitions. usb: dwc2: Add enter partial power down when port is suspended usb: dwc2: Add exit partial power down when port is resumed usb: dwc2: Add exit partial power down when port reset is asserted usb: dwc2: Add part. power down exit from dwc2_conn_id_status_change(). usb: dwc2: Allow exit partial power down in urb enqueue usb: dwc2: Fix session request interrupt handler usb: dwc2: Update partial power down entering by system suspend usb: dwc2: Fix partial power down exiting by system resume usb: dwc2: Add exit partial power down before removing driver drivers/usb/dwc2/core.c | 113 ++--- drivers/usb/dwc2/core.h | 27 ++- drivers/usb/dwc2/core_intr.c | 46 ++-- drivers/usb/dwc2/gadget.c| 148 ++- drivers/usb/dwc2/hcd.c | 458 +-- drivers/usb/dwc2/hw.h| 1 + drivers/usb/dwc2/platform.c | 11 +- 7 files changed, 558 insertions(+), 246 deletions(-) base-commit: e9fcb07704fcef6fa6d0333fd2b3a62442eaf45b -- 2.25.1
Re: [PATCH v1] usb: dwc3: core: Add shutdown callback for dwc3
On Thu, Apr 08, 2021 at 10:22:57AM +0530, Sandeep Maheswaram wrote: > > On 3/30/2021 7:02 PM, Greg Kroah-Hartman wrote: > > On Tue, Mar 30, 2021 at 06:18:43PM +0530, Sai Prakash Ranjan wrote: > > > On 2021-03-30 16:46, Greg Kroah-Hartman wrote: > > > > On Tue, Mar 30, 2021 at 03:25:58PM +0530, Sai Prakash Ranjan wrote: > > > > > On 2021-03-30 14:37, Greg Kroah-Hartman wrote: > > > > > > On Tue, Mar 30, 2021 at 02:12:04PM +0530, Sandeep Maheswaram wrote: > > > > > > > On 3/26/2021 7:07 PM, Greg Kroah-Hartman wrote: > > > > > > > > On Wed, Mar 24, 2021 at 12:57:32AM +0530, Sandeep Maheswaram > > > > > > > > wrote: > > > > > > > > > This patch adds a shutdown callback to USB DWC core driver to > > > > > > > > > ensure that > > > > > > > > > it is properly shutdown in reboot/shutdown path. This is > > > > > > > > > required > > > > > > > > > where SMMU address translation is enabled like on SC7180 > > > > > > > > > SoC and few others. If the hardware is still accessing memory > > > > > > > > > after > > > > > > > > > SMMU translation is disabled as part of SMMU shutdown > > > > > > > > > callback in > > > > > > > > > system reboot or shutdown path, then IOVAs(I/O virtual > > > > > > > > > address) > > > > > > > > > which it was using will go on the bus as the physical > > > > > > > > > addresses which > > > > > > > > > might result in unknown crashes (NoC/interconnect errors). > > > > > > > > > > > > > > > > > > Previously this was added in dwc3 qcom glue driver. > > > > > > > > > https://patchwork.kernel.org/project/linux-arm-msm/list/?series=382449 > > > > > > > > > But observed kernel panic as glue driver shutdown getting > > > > > > > > > called after > > > > > > > > > iommu shutdown. As we are adding iommu nodes in dwc core node > > > > > > > > > in device tree adding shutdown callback in core driver seems > > > > > > > > > correct. > > > > > > > > So shouldn't you also remove this from the qcom glue driver at > > > > > > > > the same > > > > > > > > time? Please submit both as a patch series. > > > > > > > > > > > > > > > > thanks, > > > > > > > > > > > > > > > > greg k-h > > > > > > > Hi Greg, > > > > > > > > > > > > > > The qcom glue driver patch is not merged yet. I have just > > > > > > > mentioned > > > > > > > for it for reference. > > > > > > You know that we can not add callbacks for no in-kernel user, so > > > > > > what > > > > > > good is this patch for now? > > > > > > > > > > > What in-kernel user? Since when does shutdown callback need an > > > > > in-kernel > > > > > user? When you reboot or shutdown a system, it gets called. The reason > > > > > why the shutdown callback is needed is provided in the commit text. > > > > As I can't see the patch here, I have no idea... > > > You are replying now to the same patch which adds this shutdown callback > > > :) > > > Anyways the qcom dwc3 driver patch which is abandoned which is also > > > mentioned > > > in the commit text is here [1] and the new shutdown callback patch which > > > we > > > are both replying to is in here [2] > > > > > > [1] > > > https://lore.kernel.org/lkml/1605162619-10064-1-git-send-email-s...@codeaurora.org/ > > > > > > [2] > > > https://lore.kernel.org/lkml/1616527652-7937-1-git-send-email-s...@codeaurora.org/ > > Thanks, so, what am I supposed to do here? The patch is long gone from > > my queue... > > > > greg k-h > > Hi Greg, > > Should I resend this patch ? If so let me know your about opinion about > Stephen's comment on just calling dwc3_remove in > > dwc3_shutdown and ignoring return value. > > https://lore.kernel.org/patchwork/patch/1401242/#1599316 Please resend as again, it's not in my queue of patches to review at all... And yes, Stephen's comment does make sense, why ignore that? thanks, greg k-h
Re: [PATCH net-next] net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)
On Wed, Apr 07, 2021 at 09:59:52PM +, Dexuan Cui wrote:
> > From: Leon Romanovsky
> > Sent: Wednesday, April 7, 2021 5:45 AM
> > > >
> > > > BTW, you don't need to write { 0 }, the {} is enough.
> > >
> > > Thanks for the suggestion! I'll use {0} in v2.
> >
> > You missed the point, "{ 0 }" change to be "{}" without 0.
>
> Got it. Will make the suggested change.
The numbers are not important, if you are curious, read this thread, it
talks about {}, {0}, memset(0,..) and padding :)
https://lore.kernel.org/linux-rdma/20200730192026.110246-1-yepeilin...@gmail.com/
>
> FWIW, {0} and { 0 } are still widely used, but it looks like
> {} is indeed more preferred:
>
> $ grep "= {};" drivers/net/ -nr | wc -l
> 829
>
> $ grep "= {0};" drivers/net/ -nr | wc -l
> 708
>
> $ grep "= {};" kernel/ -nr | wc -l
> 29
>
> $ grep "= {0};" kernel/ -nr | wc -l
> 4
[PATCH v2 13/14] usb: dwc2: Fix partial power down exiting by system resume
Fixes the implementation of exiting from partial power down
power saving mode when PC is resumed.
Added port connection status checking which prevents exiting from
Partial Power Down mode from _dwc2_hcd_resume() if not in Partial
Power Down mode.
Rearranged the implementation to get rid of many "if"
statements.
NOTE: Switch case statement is used for hibernation partial
power down and clock gating mode determination. In this patch
only Partial Power Down is implemented the Hibernation and
clock gating implementations are planned to be added.
Cc:
Fixes: 6f6d70597c15 ("usb: dwc2: bus suspend/resume for hosts with
DWC2_POWER_DOWN_PARAM_NONE")
Signed-off-by: Artur Petrosyan
---
Changes in v2:
- None
drivers/usb/dwc2/hcd.c | 90 +-
1 file changed, 46 insertions(+), 44 deletions(-)
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 34030bafdff4..f096006df96f 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -4427,7 +4427,7 @@ static int _dwc2_hcd_resume(struct usb_hcd *hcd)
{
struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
unsigned long flags;
- u32 pcgctl;
+ u32 hprt0;
int ret = 0;
spin_lock_irqsave(&hsotg->lock, flags);
@@ -4438,11 +4438,40 @@ static int _dwc2_hcd_resume(struct usb_hcd *hcd)
if (hsotg->lx_state != DWC2_L2)
goto unlock;
- if (hsotg->params.power_down > DWC2_POWER_DOWN_PARAM_PARTIAL) {
+ hprt0 = dwc2_read_hprt0(hsotg);
+
+ /*
+* Added port connection status checking which prevents exiting from
+* Partial Power Down mode from _dwc2_hcd_resume() if not in Partial
+* Power Down mode.
+*/
+ if (hprt0 & HPRT0_CONNSTS) {
+ hsotg->lx_state = DWC2_L0;
+ goto unlock;
+ }
+
+ switch (hsotg->params.power_down) {
+ case DWC2_POWER_DOWN_PARAM_PARTIAL:
+ ret = dwc2_exit_partial_power_down(hsotg, 0, true);
+ if (ret)
+ dev_err(hsotg->dev,
+ "exit partial_power_down failed\n");
+ /*
+* Set HW accessible bit before powering on the controller
+* since an interrupt may rise.
+*/
+ set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
+ break;
+ case DWC2_POWER_DOWN_PARAM_HIBERNATION:
+ case DWC2_POWER_DOWN_PARAM_NONE:
+ default:
hsotg->lx_state = DWC2_L0;
goto unlock;
}
+ /* Change Root port status, as port status change occurred after
resume.*/
+ hsotg->flags.b.port_suspend_change = 1;
+
/*
* Enable power if not already done.
* This must not be spinlocked since duration
@@ -4454,52 +4483,25 @@ static int _dwc2_hcd_resume(struct usb_hcd *hcd)
spin_lock_irqsave(&hsotg->lock, flags);
}
- if (hsotg->params.power_down == DWC2_POWER_DOWN_PARAM_PARTIAL) {
- /*
-* Set HW accessible bit before powering on the controller
-* since an interrupt may rise.
-*/
- set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
-
-
- /* Exit partial_power_down */
- ret = dwc2_exit_partial_power_down(hsotg, 0, true);
- if (ret && (ret != -ENOTSUPP))
- dev_err(hsotg->dev, "exit partial_power_down failed\n");
- } else {
- pcgctl = readl(hsotg->regs + PCGCTL);
- pcgctl &= ~PCGCTL_STOPPCLK;
- writel(pcgctl, hsotg->regs + PCGCTL);
- }
-
- hsotg->lx_state = DWC2_L0;
-
+ /* Enable external vbus supply after resuming the port. */
spin_unlock_irqrestore(&hsotg->lock, flags);
+ dwc2_vbus_supply_init(hsotg);
- if (hsotg->bus_suspended) {
- spin_lock_irqsave(&hsotg->lock, flags);
- hsotg->flags.b.port_suspend_change = 1;
- spin_unlock_irqrestore(&hsotg->lock, flags);
- dwc2_port_resume(hsotg);
- } else {
- if (hsotg->params.power_down == DWC2_POWER_DOWN_PARAM_PARTIAL) {
- dwc2_vbus_supply_init(hsotg);
-
- /* Wait for controller to correctly update D+/D- level
*/
- usleep_range(3000, 5000);
- }
+ /* Wait for controller to correctly update D+/D- level */
+ usleep_range(3000, 5000);
+ spin_lock_irqsave(&hsotg->lock, flags);
- /*
-* Clear Port Enable and Port Status changes.
-* Enable Port Power.
-*/
- dwc2_writel(hsotg, HPRT0_PWR | HPRT0_CONNDET |
- HPRT0_ENACHG, HPRT0);
- /* Wait for controller to detect Port Connect */
- usleep_range(5000, 7000);
- }
+ /*
+* Clear Po
RE: [PATCH 2/3] fpga: dfl: Add DFL bus driver for Altera SPI Master
> > On Mon, 5 Apr 2021, Moritz Fischer wrote:
> >
> > > Hi Matthew,
> > >
> > > On Mon, Apr 05, 2021 at 04:53:00PM -0700,
> matthew.gerl...@linux.intel.com wrote:
> > > > From: Matthew Gerlach
> > > >
> > > > This patch adds DFL bus driver for the Altera SPI Master
> > > > controller. The SPI master is connected to an Intel SPI Slave to
> > > > Avalon Master Bridge, inside an Intel MAX10 BMC Chip.
> > > >
> > > > Signed-off-by: Matthew Gerlach
> > > > ---
> > > > drivers/fpga/Kconfig | 9 ++
> > > > drivers/fpga/Makefile | 1 +
> > > > drivers/fpga/dfl-spi-altera.c | 221
> ++
> > > > 3 files changed, 231 insertions(+)
> > > > create mode 100644 drivers/fpga/dfl-spi-altera.c
> > > >
> > > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > > > index d591dd9..0a86994 100644
> > > > --- a/drivers/fpga/Kconfig
> > > > +++ b/drivers/fpga/Kconfig
> > > > @@ -210,6 +210,15 @@ config FPGA_DFL_NIOS_INTEL_PAC_N3000
> > > > the card. It also instantiates the SPI master (spi-altera) for
> > > > the card's BMC (Board Management Controller).
> > > >
> > > > +config FPGA_DFL_SPI_ALTERA
> > > > + tristate "FPGA DFL Altera SPI Master Driver"
> > > > + depends on FPGA_DFL
> > > > + select REGMAP
> > > > + help
> > > > + This is a DFL bus driver for the Altera SPI master controller.
> > > > + The SPI master is connected to a SPI slave to Avalon Master
> > > > + bridge in a Intel MAX BMC.
> > > > +
> > > > config FPGA_DFL_PCI
> > > > tristate "FPGA DFL PCIe Device Driver"
> > > > depends on PCI && FPGA_DFL
> > > > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> > > > index 18dc9885..58a42ad 100644
> > > > --- a/drivers/fpga/Makefile
> > > > +++ b/drivers/fpga/Makefile
> > > > @@ -45,6 +45,7 @@ dfl-afu-objs := dfl-afu-main.o dfl-afu-region.o dfl-
> afu-dma-region.o
> > > > dfl-afu-objs += dfl-afu-error.o
> > > >
> > > > obj-$(CONFIG_FPGA_DFL_NIOS_INTEL_PAC_N3000)+= dfl-n3000-
> nios.o
> > > > +obj-$(CONFIG_FPGA_DFL_SPI_ALTERA) += dfl-spi-altera.o
> > > >
> > > > # Drivers for FPGAs which implement DFL
> > > > obj-$(CONFIG_FPGA_DFL_PCI) += dfl-pci.o
> > > > diff --git a/drivers/fpga/dfl-spi-altera.c
> > > > b/drivers/fpga/dfl-spi-altera.c
> > > > new file mode 100644
> > > > index 000..9bec25fd
> > > > --- /dev/null
> > > > +++ b/drivers/fpga/dfl-spi-altera.c
> > > > @@ -0,0 +1,221 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * DFL bus driver for Altera SPI Master
> > > > + *
> > > > + * Copyright (C) 2020 Intel Corporation, Inc.
> > > > + *
> > > > + * Authors:
> > > > + * Matthew Gerlach
> > > > + */
> > > > +
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +
> > > > +struct dfl_altera_spi {
> > > > + void __iomem *base;
> > > > + struct regmap *regmap;
> > > > + struct device *dev;
> > > > + struct platform_device *altr_spi;
> > > > +};
> > > > +
> > > > +#define SPI_CORE_PARAMETER 0x8
> > > > +#define SHIFT_MODE BIT_ULL(1)
> > > > +#define SHIFT_MODE_MSB 0
> > > > +#define SHIFT_MODE_LSB 1
> > > > +#define DATA_WIDTH GENMASK_ULL(7, 2)
> > > > +#define NUM_CHIPSELECT GENMASK_ULL(13, 8)
> > > > +#define CLK_POLARITYBIT_ULL(14)
> > > > +#define CLK_PHASE BIT_ULL(15)
> > > > +#define PERIPHERAL_ID GENMASK_ULL(47, 32)
> > > > +#define SPI_CLK GENMASK_ULL(31, 22)
> > > > +#define SPI_INDIRECT_ACC_OFST 0x10
> > > > +
> > > > +#define INDIRECT_ADDR (SPI_INDIRECT_ACC_OFST+0x0)
> > > > +#define INDIRECT_WR BIT_ULL(8)
> > > > +#define INDIRECT_RD BIT_ULL(9)
> > > > +#define INDIRECT_RD_DATA(SPI_INDIRECT_ACC_OFST+0x8)
> > > > +#define INDIRECT_DATA_MASK GENMASK_ULL(31, 0)
> > > > +#define INDIRECT_DEBUG BIT_ULL(32)
> > > > +#define INDIRECT_WR_DATA(SPI_INDIRECT_ACC_OFST+0x10)
> > > > +#define INDIRECT_TIMEOUT1
> > > > +
> > > > +static int indirect_bus_reg_read(void *context, unsigned int reg,
> > > > +unsigned int *val)
> > > > +{
> > > > + struct dfl_altera_spi *aspi = context;
> > > > + void __iomem *base = aspi->base;
> > > > + int loops;
> > > > + u64 v;
> > > > +
> > > > + writeq((reg >> 2) | INDIRECT_RD, base + INDIRECT_ADDR);
> > > > +
> > > > + loops = 0;
> > > > + while ((readq(base + INDIRECT_ADDR) & INDIRECT_RD) &&
> > > > + (loops++ < INDIRECT_TIMEOUT))
> > > > + cpu_relax();
> > > > +
> > > > + if (loops >= INDIRECT_TIMEOUT) {
> > > > + pr_err("%s timed out %d\n"
[tip:x86/cleanups] BUILD SUCCESS dda451f391eee5d68db3ca87fd8b2a42c8c2b507
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/cleanups branch HEAD: dda451f391eee5d68db3ca87fd8b2a42c8c2b507 x86/cacheinfo: Remove unneeded dead-store initialization elapsed time: 723m configs tested: 151 configs skipped: 62 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 x86_64 allyesconfig riscvallmodconfig i386 allyesconfig riscvallyesconfig arm hackkit_defconfig arm u8500_defconfig mips bmips_be_defconfig arm h5000_defconfig mips loongson3_defconfig powerpcamigaone_defconfig arc axs103_smp_defconfig mipsbcm47xx_defconfig arc axs101_defconfig powerpc chrp32_defconfig armkeystone_defconfig alphaallyesconfig shshmin_defconfig mips ci20_defconfig armoxnas_v6_defconfig powerpc ppc44x_defconfig arm colibri_pxa300_defconfig powerpc mpc836x_rdk_defconfig arm socfpga_defconfig mips malta_kvm_defconfig i386defconfig mips allyesconfig s390 zfcpdump_defconfig nios2 3c120_defconfig m68km5407c3_defconfig powerpcklondike_defconfig arm eseries_pxa_defconfig arm sama5_defconfig xtensa alldefconfig m68kstmark2_defconfig armspear3xx_defconfig armzeus_defconfig openrisc or1klitex_defconfig arm at91_dt_defconfig sh rts7751r2dplus_defconfig sh kfr2r09_defconfig arm footbridge_defconfig arm iop32x_defconfig powerpc maple_defconfig arc defconfig armshmobile_defconfig mipsmaltaup_defconfig riscv nommu_k210_sdcard_defconfig m68kq40_defconfig sparc sparc32_defconfig mipsnlm_xlr_defconfig sh rsk7201_defconfig arm cm_x300_defconfig sh urquell_defconfig arm bcm2835_defconfig alphaalldefconfig m68km5307c3_defconfig arm tct_hammer_defconfig mips gcw0_defconfig sh alldefconfig m68k m5249evb_defconfig shsh7763rdp_defconfig h8300 defconfig powerpc ps3_defconfig x86_64 alldefconfig armxcep_defconfig arm davinci_all_defconfig sh rts7751r2d1_defconfig powerpc mgcoge_defconfig powerpc wii_defconfig powerpc stx_gp3_defconfig powerpc tqm8xx_defconfig powerpc tqm8541_defconfig mipsar7_defconfig powerpcfsp2_defconfig um allyesconfig arm omap2plus_defconfig powerpc ppc40x_defconfig sh ap325rxa_defconfig powerpc mpc832x_mds_defconfig powerpc bamboo_defconfig mips pistachio_defconfig armtrizeps4_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig xtensa
Re: [RFC PATCH] KVM: x86: Support write protect huge pages lazily
Hi Ben,
Do you have any similar idea that can share with us?
Thanks
Keqian
On 2021/4/7 7:42, Sean Christopherson wrote:
> +Ben
>
> On Tue, Apr 06, 2021, Keqian Zhu wrote:
>> Hi Paolo,
>>
>> I plan to rework this patch and do full test. What do you think about this
>> idea
>> (enable dirty logging for huge pages lazily)?
>
> Ben, don't you also have something similar (or maybe the exact opposite?) in
> the
> hopper? This sounds very familiar, but I can't quite connect the dots that
> are
> floating around my head...
>
>> PS: As dirty log of TDP MMU has been supported, I should add more code.
>>
>> On 2020/8/28 16:11, Keqian Zhu wrote:
>>> Currently during enable dirty logging, if we're with init-all-set,
>>> we just write protect huge pages and leave normal pages untouched,
>>> for that we can enable dirty logging for these pages lazily.
>>>
>>> It seems that enable dirty logging lazily for huge pages is feasible
>>> too, which not only reduces the time of start dirty logging, also
>>> greatly reduces side-effect on guest when there is high dirty rate.
>>>
>>> (These codes are not tested, for RFC purpose :-) ).
>>>
>>> Signed-off-by: Keqian Zhu
>>> ---
>>> arch/x86/include/asm/kvm_host.h | 3 +-
>>> arch/x86/kvm/mmu/mmu.c | 65 ++---
>>> arch/x86/kvm/vmx/vmx.c | 3 +-
>>> arch/x86/kvm/x86.c | 22 +--
>>> 4 files changed, 62 insertions(+), 31 deletions(-)
>>>
>>> diff --git a/arch/x86/include/asm/kvm_host.h
>>> b/arch/x86/include/asm/kvm_host.h
>>> index 5303dbc5c9bc..201a068cf43d 100644
>>> --- a/arch/x86/include/asm/kvm_host.h
>>> +++ b/arch/x86/include/asm/kvm_host.h
>>> @@ -1296,8 +1296,7 @@ void kvm_mmu_set_mask_ptes(u64 user_mask, u64
>>> accessed_mask,
>>>
>>> void kvm_mmu_reset_context(struct kvm_vcpu *vcpu);
>>> void kvm_mmu_slot_remove_write_access(struct kvm *kvm,
>>> - struct kvm_memory_slot *memslot,
>>> - int start_level);
>>> + struct kvm_memory_slot *memslot);
>>> void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm,
>>>const struct kvm_memory_slot *memslot);
>>> void kvm_mmu_slot_leaf_clear_dirty(struct kvm *kvm,
>>> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
>>> index 43fdb0c12a5d..4b7d577de6cd 100644
>>> --- a/arch/x86/kvm/mmu/mmu.c
>>> +++ b/arch/x86/kvm/mmu/mmu.c
>>> @@ -1625,14 +1625,45 @@ static bool __rmap_set_dirty(struct kvm *kvm,
>>> struct kvm_rmap_head *rmap_head)
>>> }
>>>
>>> /**
>>> - * kvm_mmu_write_protect_pt_masked - write protect selected PT level pages
>>> + * kvm_mmu_write_protect_largepage_masked - write protect selected
>>> largepages
>>> * @kvm: kvm instance
>>> * @slot: slot to protect
>>> * @gfn_offset: start of the BITS_PER_LONG pages we care about
>>> * @mask: indicates which pages we should protect
>>> *
>>> - * Used when we do not need to care about huge page mappings: e.g. during
>>> dirty
>>> - * logging we do not have any such mappings.
>>> + * @ret: true if all pages are write protected
>>> + */
>>> +static bool kvm_mmu_write_protect_largepage_masked(struct kvm *kvm,
>>> + struct kvm_memory_slot *slot,
>>> + gfn_t gfn_offset, unsigned long mask)
>>> +{
>>> + struct kvm_rmap_head *rmap_head;
>>> + bool protected, all_protected;
>>> + gfn_t start_gfn = slot->base_gfn + gfn_offset;
>>> + int i;
>>> +
>>> + all_protected = true;
>>> + while (mask) {
>>> + protected = false;
>>> + for (i = PG_LEVEL_2M; i <= KVM_MAX_HUGEPAGE_LEVEL; ++i) {
>>> + rmap_head = __gfn_to_rmap(start_gfn + __ffs(mask), i,
>>> slot);
>>> + protectd |= __rmap_write_protect(kvm, rmap_head, false);
>>> + }
>>> +
>>> + all_protected &= protectd;
>>> + /* clear the first set bit */
>>> + mask &= mask - 1;
>>> + }
>>> +
>>> + return all_protected;
>>> +}
>>> +
>>> +/**
>>> + * kvm_mmu_write_protect_pt_masked - write protect selected PT level pages
>>> + * @kvm: kvm instance
>>> + * @slot: slot to protect
>>> + * @gfn_offset: start of the BITS_PER_LONG pages we care about
>>> + * @mask: indicates which pages we should protect
>>> */
>>> static void kvm_mmu_write_protect_pt_masked(struct kvm *kvm,
>>> struct kvm_memory_slot *slot,
>>> @@ -1679,18 +1710,25 @@ EXPORT_SYMBOL_GPL(kvm_mmu_clear_dirty_pt_masked);
>>>
>>> /**
>>> * kvm_arch_mmu_enable_log_dirty_pt_masked - enable dirty logging for
>>> selected
>>> - * PT level pages.
>>> - *
>>> - * It calls kvm_mmu_write_protect_pt_masked to write protect selected
>>> pages to
>>> - * enable dirty logging for them.
>>> - *
>>> - * Used when we do not need to care about huge page mappings: e.g. during
>>> dirty
>>> - * logging we do not have any such mappings.
>>> + * dirty pages.
>>> */
>>>
RE: [PATCH] iommu/vt-d: Force to flush iotlb before creating superpage
Hi Baolu,
> -Original Message-
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Thursday, April 8, 2021 12:32 PM
> To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> ; io...@lists.linux-foundation.org;
> linux-kernel@vger.kernel.org
> Cc: baolu...@linux.intel.com; David Woodhouse ; Nadav
> Amit ; Alex Williamson ;
> Kevin Tian ; Gonglei (Arei) ;
> sta...@vger.kernel.org
> Subject: Re: [PATCH] iommu/vt-d: Force to flush iotlb before creating
> superpage
>
> Hi Longpeng,
>
> On 4/7/21 2:35 PM, Longpeng (Mike, Cloud Infrastructure Service Product
> Dept.) wrote:
> > Hi Baolu,
> >
> >> -Original Message-
> >> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> >> Sent: Friday, April 2, 2021 12:44 PM
> >> To: Longpeng (Mike, Cloud Infrastructure Service Product Dept.)
> >> ; io...@lists.linux-foundation.org;
> >> linux-kernel@vger.kernel.org
> >> Cc: baolu...@linux.intel.com; David Woodhouse ;
> >> Nadav Amit ; Alex Williamson
> >> ; Kevin Tian ;
> >> Gonglei (Arei) ; sta...@vger.kernel.org
> >> Subject: Re: [PATCH] iommu/vt-d: Force to flush iotlb before creating
> >> superpage
> >>
> >> Hi Longpeng,
> >>
> >> On 4/1/21 3:18 PM, Longpeng(Mike) wrote:
> >>> diff --git a/drivers/iommu/intel/iommu.c
> >>> b/drivers/iommu/intel/iommu.c index ee09323..cbcb434 100644
> >>> --- a/drivers/iommu/intel/iommu.c
> >>> +++ b/drivers/iommu/intel/iommu.c
> >>> @@ -2342,9 +2342,20 @@ static inline int
> >>> hardware_largepage_caps(struct
> >> dmar_domain *domain,
> >>>* removed to make room for
> >>> superpage(s).
> >>>* We're adding new large pages, so
> >>> make sure
> >>>* we don't remove their parent tables.
> >>> + *
> >>> + * We also need to flush the iotlb before
> >>> creating
> >>> + * superpage to ensure it does not perserves any
> >>> + * obsolete info.
> >>>*/
> >>> - dma_pte_free_pagetable(domain, iov_pfn, end_pfn,
> >>> -largepage_lvl + 1);
> >>> + if (dma_pte_present(pte)) {
> >>
> >> The dma_pte_free_pagetable() clears a batch of PTEs. So checking
> >> current PTE is insufficient. How about removing this check and always
> >> performing cache invalidation?
> >>
> >
> > Um...the PTE here may be present( e.g. 4K mapping --> superpage mapping )
> orNOT-present ( e.g. create a totally new superpage mapping ), but we only
> need to
> call free_pagetable and flush_iotlb in the former case, right ?
>
> But this code covers multiple PTEs and perhaps crosses the page boundary.
>
> How about moving this code into a separated function and check PTE presence
> there. A sample code could look like below: [compiled but not tested!]
>
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index
> d334f5b4e382..0e04d450c38a 100644
> --- a/drivers/iommu/intel/iommu.c
> +++ b/drivers/iommu/intel/iommu.c
> @@ -2300,6 +2300,41 @@ static inline int hardware_largepage_caps(struct
> dmar_domain *domain,
> return level;
> }
>
> +/*
> + * Ensure that old small page tables are removed to make room for
> superpage(s).
> + * We're going to add new large pages, so make sure we don't remove
> their parent
> + * tables. The IOTLB/devTLBs should be flushed if any PDE/PTEs are cleared.
> + */
> +static void switch_to_super_page(struct dmar_domain *domain,
> +unsigned long start_pfn,
> +unsigned long end_pfn, int level) {
Maybe "swith_to" will lead people to think "remove old and then setup new", so
how about something like "remove_room_for_super_page" or
"prepare_for_super_page" ?
> + unsigned long lvl_pages = lvl_to_nr_pages(level);
> + struct dma_pte *pte = NULL;
> + int i;
> +
> + while (start_pfn <= end_pfn) {
start_pfn < end_pfn ?
> + if (!pte)
> + pte = pfn_to_dma_pte(domain, start_pfn, &level);
> +
> + if (dma_pte_present(pte)) {
> + dma_pte_free_pagetable(domain, start_pfn,
> + start_pfn + lvl_pages - 1,
> + level + 1);
> +
> + for_each_domain_iommu(i, domain)
> + iommu_flush_iotlb_psi(g_iommus[i],
> domain,
> + start_pfn,
> lvl_pages,
> + 0, 0);
> + }
> +
> + pte++;
> + start_pfn += lvl_pages;
> + if (first_pte_in_page(pte))
> + pte = NULL;
> + }
> +}
> +
> static int
> __domain_mapping(struct dmar_domain *domain, unsigned long io
[PATCH 2/3] media: rdacm21: describe better a truncation
As warned by sparse: drivers/media/i2c/rdacm21.c:348:62: warning: cast truncates bits from constant value (300a becomes a) the intention of the code is to get just the lowest 8 bits. So, instead of using a typecast, use a bit and logic. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/i2c/rdacm21.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/rdacm21.c b/drivers/media/i2c/rdacm21.c index dcc21515e5a4..179d107f494c 100644 --- a/drivers/media/i2c/rdacm21.c +++ b/drivers/media/i2c/rdacm21.c @@ -345,7 +345,7 @@ static int ov10640_initialize(struct rdacm21_device *dev) /* Read OV10640 ID to test communications. */ ov490_write_reg(dev, OV490_SCCB_SLAVE0_DIR, OV490_SCCB_SLAVE_READ); ov490_write_reg(dev, OV490_SCCB_SLAVE0_ADDR_HIGH, OV10640_CHIP_ID >> 8); - ov490_write_reg(dev, OV490_SCCB_SLAVE0_ADDR_LOW, (u8)OV10640_CHIP_ID); + ov490_write_reg(dev, OV490_SCCB_SLAVE0_ADDR_LOW, OV10640_CHIP_ID & 0xff); /* Trigger SCCB slave transaction and give it some time to complete. */ ov490_write_reg(dev, OV490_HOST_CMD, OV490_HOST_CMD_TRIGGER); -- 2.30.2
[PATCH 1/3] media: venus: use NULL instead of zero for pointers
As reported by sparse: drivers/media/platform/qcom/venus/core.c:227:41: warning: Using plain integer as NULL pointer drivers/media/platform/qcom/venus/core.c:228:34: warning: Using plain integer as NULL pointer Two vars are using zero instead of NULL for pointers. Not really an issue, but using NULL makes it clearer that the init data is expecting a pointer. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/platform/qcom/venus/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c index f5b88b96f5f7..4451e3c11bc0 100644 --- a/drivers/media/platform/qcom/venus/core.c +++ b/drivers/media/platform/qcom/venus/core.c @@ -224,8 +224,8 @@ static void venus_assign_register_offsets(struct venus_core *core) core->cpu_cs_base = core->base + CPU_CS_BASE; core->cpu_ic_base = core->base + CPU_IC_BASE; core->wrapper_base = core->base + WRAPPER_BASE; - core->wrapper_tz_base = 0; - core->aon_base = 0; + core->wrapper_tz_base = NULL; + core->aon_base = NULL; } } -- 2.30.2
[PATCH 3/3] media: venus: don't de-reference NULL pointers at IRQ time
Smatch is warning that:
drivers/media/platform/qcom/venus/hfi_venus.c:1100 venus_isr() warn:
variable dereferenced before check 'hdev' (see line 1097)
The logic basically does:
hdev = to_hfi_priv(core);
with is translated to:
hdev = core->priv;
If the IRQ code can receive a NULL pointer for hdev, there's
a bug there, as it will first try to de-reference the pointer,
and then check if it is null.
After looking at the code, it seems that this indeed can happen:
Basically, the venus IRQ thread is started with:
devm_request_threaded_irq()
So, it will only be freed after the driver unbinds.
In order to prevent the IRQ code to work with freed data,
the logic at venus_hfi_destroy() sets core->priv to NULL,
which would make the IRQ code to ignore any pending IRQs.
There is, however a race condition, as core->priv is set
to NULL only after being freed. So, we need also to move the
core->priv = NULL to happen earlier.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/platform/qcom/venus/hfi_venus.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c
b/drivers/media/platform/qcom/venus/hfi_venus.c
index cebb20cf371f..ce98c523b3c6 100644
--- a/drivers/media/platform/qcom/venus/hfi_venus.c
+++ b/drivers/media/platform/qcom/venus/hfi_venus.c
@@ -1094,12 +1094,15 @@ static irqreturn_t venus_isr(struct venus_core *core)
{
struct venus_hfi_device *hdev = to_hfi_priv(core);
u32 status;
- void __iomem *cpu_cs_base = hdev->core->cpu_cs_base;
- void __iomem *wrapper_base = hdev->core->wrapper_base;
+ void __iomem *cpu_cs_base;
+ void __iomem *wrapper_base;
if (!hdev)
return IRQ_NONE;
+ cpu_cs_base = hdev->core->cpu_cs_base;
+ wrapper_base = hdev->core->wrapper_base;
+
status = readl(wrapper_base + WRAPPER_INTR_STATUS);
if (IS_V6(core)) {
if (status & WRAPPER_INTR_STATUS_A2H_MASK ||
@@ -1650,10 +1653,10 @@ void venus_hfi_destroy(struct venus_core *core)
{
struct venus_hfi_device *hdev = to_hfi_priv(core);
+ core->priv = NULL;
venus_interface_queues_release(hdev);
mutex_destroy(&hdev->lock);
kfree(hdev);
- core->priv = NULL;
core->ops = NULL;
}
--
2.30.2
Re: [PATCH] clk: imx: reference preceded by free
Quoting Jian Dong (2021-04-07 18:53:12) > On Tue, 30 Mar 2021 19:16:48 -0700 > Stephen Boyd wrote: > > > Quoting Jian Dong (2021-03-22 20:10:34) > > > From: Jian Dong > > > > > > when register failed, clk will be freed, it will generate dangling > > > pointer problem in later reference. it should return directly. > > > > > > Signed-off-by: Jian Dong > > > --- > > > > Any Fixes tag? > > Sorry for late, I'm unfamiliar with tag rule. > > For this patch include two files commit 2f77296d3 and fe37b482 > maybe likes: > > Fixes: 2f77296d3(clk: imx: add lpcg clock support) > Fixes: fe37b482 (clk: imx: add scu clock common part) > > and I noticed this patch has been merged, do I need RESEND again with > tags like above? > Looks like Abel already picked it up so no need to resend.
Re: [PATCH v2 2/4] crypto: support rsa-pss encoding
Hi Hongbo, Thank you for the patch! Yet something to improve: [auto build test ERROR on cryptodev/master] [also build test ERROR on crypto/master security/next-testing linus/master v5.12-rc6 next-20210407] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Hongbo-Li/x509-add-support-for-rsa-pss/20210407-115738 base: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master config: x86_64-rhel-8.3-kselftests (attached as .config) compiler: gcc-9 (Debian 9.3.0-22) 9.3.0 reproduce (this is a W=1 build): # https://github.com/0day-ci/linux/commit/7ae494f4046fa7980cf2ee1b40f175355609a9da git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Hongbo-Li/x509-add-support-for-rsa-pss/20210407-115738 git checkout 7ae494f4046fa7980cf2ee1b40f175355609a9da # save the attached .config to linux build tree make W=1 ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> make[2]: *** No rule to make target 'crypto/rsa-psspad.o', needed by >> 'crypto/built-in.a'. make[2]: Target '__build' not remade because of errors. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH] staging: rtl8712: removed unnecessary blank line
Cleanup patch for CHECK: blank lines aren't necessary after an open
brace '{'
Reported by checkpatch
Signed-off-by: Mitali Borkar
---
drivers/staging/rtl8712/usb_intf.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8712/usb_intf.c
b/drivers/staging/rtl8712/usb_intf.c
index dc21e7743349..9038570fb949 100644
--- a/drivers/staging/rtl8712/usb_intf.c
+++ b/drivers/staging/rtl8712/usb_intf.c
@@ -36,7 +36,6 @@ static int r871xu_drv_init(struct usb_interface *pusb_intf,
static void r871xu_dev_remove(struct usb_interface *pusb_intf);
static const struct usb_device_id rtl871x_usb_id_tbl[] = {
-
/* RTL8188SU */
/* Realtek */
{USB_DEVICE(0x0BDA, 0x8171)},
@@ -441,7 +440,7 @@ static int r871xu_drv_init(struct usb_interface *pusb_intf,
for (i = 0, offset = 0; i < 128; i += 8, offset++)
r8712_efuse_pg_packet_read(padapter, offset,
-&pdata[i]);
+ &pdata[i]);
if (!r8712_initmac || !mac_pton(r8712_initmac, mac)) {
/* Use the mac address stored in the Efuse
@@ -561,10 +560,10 @@ static int r871xu_drv_init(struct usb_interface
*pusb_intf,
*/
mac[0] &= 0xFE;
dev_info(&udev->dev,
- "r8712u: MAC Address from user = %pM\n", mac);
+"r8712u: MAC Address from user = %pM\n", mac);
} else {
dev_info(&udev->dev,
- "r8712u: MAC Address from efuse = %pM\n", mac);
+"r8712u: MAC Address from efuse = %pM\n", mac);
}
ether_addr_copy(pnetdev->dev_addr, mac);
}
--
2.30.2
Re: [PATCH v2 4/6] usb: typec: tcpm: Honour pSnkStdby requirement during negotiation
On Wed, Apr 07, 2021 at 01:07:21PM -0700, Badhri Jagan Sridharan wrote: > >From PD Spec: > The Sink Shall transition to Sink Standby before a positive or > negative voltage transition of VBUS. During Sink Standby > the Sink Shall reduce its power draw to pSnkStdby. This allows > the Source to manage the voltage transition as well as > supply sufficient operating current to the Sink to maintain PD > operation during the transition. The Sink Shall > complete this transition to Sink Standby within tSnkStdby > after evaluating the Accept Message from the Source. The > transition when returning to Sink operation from Sink Standby > Shall be completed within tSnkNewPower. The > pSnkStdby requirement Shall only apply if the Sink power draw > is higher than this level. > > The above requirement needs to be met to prevent hard resets > from port partner. > > Without the patch: (5V/3A during SNK_DISCOVERY all the way through > explicit contract) > [ 95.711984] CC1: 0 -> 0, CC2: 0 -> 5 [state TOGGLING, polarity 0, > connected] > [ 95.712007] state change TOGGLING -> SNK_ATTACH_WAIT [rev3 NONE_AMS] > [ 95.712017] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms > [rev3 NONE_AMS] > [ 95.837190] VBUS on > [ 95.882075] state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED [delayed 170 ms] > [ 95.882082] state change SNK_DEBOUNCED -> SNK_ATTACHED [rev3 NONE_AMS] > [ 95.882086] polarity 1 > [ 95.883151] set_auto_vbus_discharge_threshold mode:0 pps_active:n > vbus:5000 ret:0 > [ 95.883441] enable vbus discharge ret:0 > [ 95.883445] Requesting mux state 1, usb-role 2, orientation 2 > [ 95.883776] state change SNK_ATTACHED -> SNK_STARTUP [rev3 NONE_AMS] > [ 95.883879] pending state change SNK_STARTUP -> SNK_DISCOVERY @ 500 ms > [rev3 NONE_AMS] > [ 96.038960] VBUS on > [ 96.383939] state change SNK_STARTUP -> SNK_DISCOVERY [delayed 500 ms] > [ 96.383946] Setting voltage/current limit 5000 mV 3000 mA > [ 96.383961] vbus=0 charge:=1 > [ 96.386044] state change SNK_DISCOVERY -> SNK_WAIT_CAPABILITIES [rev3 > NONE_AMS] > [ 96.386309] pending state change SNK_WAIT_CAPABILITIES -> HARD_RESET_SEND > @ 450 ms [rev3 NONE_AMS] > [ 96.394404] PD RX, header: 0x2161 [1] > [ 96.394408] PDO 0: type 0, 5000 mV, 3000 mA [E] > [ 96.394410] PDO 1: type 0, 9000 mV, 2000 mA [] > [ 96.394412] state change SNK_WAIT_CAPABILITIES -> > SNK_NEGOTIATE_CAPABILITIES [rev2 POWER_NEGOTIATION] > [ 96.394416] Setting usb_comm capable false > [ 96.395083] cc=0 cc1=0 cc2=5 vbus=0 vconn=sink polarity=1 > [ 96.395089] Requesting PDO 1: 9000 mV, 2000 mA > [ 96.395093] PD TX, header: 0x1042 > [ 96.397404] PD TX complete, status: 0 > [ 96.397424] pending state change SNK_NEGOTIATE_CAPABILITIES -> > HARD_RESET_SEND @ 60 ms [rev2 POWER_NEGOTIATION] > [ 96.400826] PD RX, header: 0x363 [1] > [ 96.400829] state change SNK_NEGOTIATE_CAPABILITIES -> SNK_TRANSITION_SINK > [rev2 POWER_NEGOTIATION] > [ 96.400832] pending state change SNK_TRANSITION_SINK -> HARD_RESET_SEND @ > 500 ms [rev2 POWER_NEGOTIATION] > [ 96.577315] PD RX, header: 0x566 [1] > [ 96.577321] Setting voltage/current limit 9000 mV 2000 mA > [ 96.578363] set_auto_vbus_discharge_threshold mode:3 pps_active:n > vbus:9000 ret:0 > [ 96.578370] state change SNK_TRANSITION_SINK -> SNK_READY [rev2 > POWER_NEGOTIATION] > > With the patch: > [ 168.398573] CC1: 0 -> 0, CC2: 0 -> 5 [state TOGGLING, polarity 0, > connected] > [ 168.398605] state change TOGGLING -> SNK_ATTACH_WAIT [rev3 NONE_AMS] > [ 168.398619] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms > [rev3 NONE_AMS] > [ 168.522348] VBUS on > [ 168.568676] state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED [delayed 170 ms] > [ 168.568684] state change SNK_DEBOUNCED -> SNK_ATTACHED [rev3 NONE_AMS] > [ 168.568688] polarity 1 > [ 168.569867] set_auto_vbus_discharge_threshold mode:0 pps_active:n > vbus:5000 ret:0 > [ 168.570158] enable vbus discharge ret:0 > [ 168.570161] Requesting mux state 1, usb-role 2, orientation 2 > [ 168.570504] state change SNK_ATTACHED -> SNK_STARTUP [rev3 NONE_AMS] > [ 168.570634] pending state change SNK_STARTUP -> SNK_DISCOVERY @ 500 ms > [rev3 NONE_AMS] > [ 169.070689] state change SNK_STARTUP -> SNK_DISCOVERY [delayed 500 ms] > [ 169.070695] Setting voltage/current limit 5000 mV 3000 mA > [ 169.070702] vbus=0 charge:=1 > [ 169.072719] state change SNK_DISCOVERY -> SNK_WAIT_CAPABILITIES [rev3 > NONE_AMS] > [ 169.073145] pending state change SNK_WAIT_CAPABILITIES -> HARD_RESET_SEND > @ 450 ms [rev3 NONE_AMS] > [ 169.077162] PD RX, header: 0x2161 [1] > [ 169.077172] PDO 0: type 0, 5000 mV, 3000 mA [E] > [ 169.077178] PDO 1: type 0, 9000 mV, 2000 mA [] > [ 169.077183] state change SNK_WAIT_CAPABILITIES -> > SNK_NEGOTIATE_CAPABILITIES [rev2 POWER_NEGOTIATION] > [ 169.077191] Setting usb_comm capable false > [ 169.077753] cc=0 cc1=0 cc2=5 vbus=0 vconn=sink polarity=1 > [ 169.077759] Requesting PDO 1: 9000 mV,
Re: [PATCH] bus: mhi: core: Fix shadow declarations
Hi Manivannan,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.12-rc6 next-20210407]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Manivannan-Sadhasivam/bus-mhi-core-Fix-shadow-declarations/20210408-144747
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
454859c552da78b0f587205d308401922b56863e
config: i386-randconfig-s032-20210407 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.3-279-g6d5d9b42-dirty
#
https://github.com/0day-ci/linux/commit/cca6579a65f1295cba8d8e7f12162b6270f71449
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Manivannan-Sadhasivam/bus-mhi-core-Fix-shadow-declarations/20210408-144747
git checkout cca6579a65f1295cba8d8e7f12162b6270f71449
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/bus/mhi/core/main.c:774:64: sparse: sparse: mixing different enum
>> types:
>> drivers/bus/mhi/core/main.c:774:64: sparse:unsigned int enum mhi_pm_state
>> drivers/bus/mhi/core/main.c:774:64: sparse:unsigned int enum mhi_state
vim +774 drivers/bus/mhi/core/main.c
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 707
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 708 int
mhi_process_ctrl_ev_ring(struct mhi_controller *mhi_cntrl,
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 709
struct mhi_event *mhi_event,
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 710
u32 event_quota)
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 711 {
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 712struct mhi_tre *dev_rp,
*local_rp;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 713struct mhi_ring
*ev_ring = &mhi_event->ring;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 714struct mhi_event_ctxt
*er_ctxt =
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 715
&mhi_cntrl->mhi_ctxt->er_ctxt[mhi_event->er_index];
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 716struct mhi_chan
*mhi_chan;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 717struct device *dev =
&mhi_cntrl->mhi_dev->dev;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 718u32 chan;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 719int count = 0;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 720
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 721/*
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 722 * This is a quick
check to avoid unnecessary event processing
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 723 * in case MHI is
already in error state, but it's still possible
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 724 * to transition to
error state while processing events
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 725 */
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 726if
(unlikely(MHI_EVENT_ACCESS_INVALID(mhi_cntrl->pm_state)))
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 727return -EIO;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 728
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 729dev_rp =
mhi_to_virtual(ev_ring, er_ctxt->rp);
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 730local_rp = ev_ring->rp;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 731
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 732while (dev_rp !=
local_rp) {
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 733enum
mhi_pkt_type type = MHI_TRE_GET_EV_TYPE(local_rp);
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 734
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 735switch (type) {
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 736case
MHI_PKT_TYPE_BW_REQ_EVENT:
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 737{
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 738struct
mhi_link_info *link_info;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 739
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 740
link_info = &mhi_cntrl->mhi_link_info;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 741
write_lock_irq(&mhi_cntrl->pm_lock);
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 742
link_info->target_link_speed =
1d3173a3bae703 Manivannan Sadha
Re: [PATCH v2 1/1] powerpc/iommu: Enable remaining IOMMU Pagesizes present in LoPAR
Hi Leonardo,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v5.12-rc6 next-20210407]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Leonardo-Bras/powerpc-iommu-Enable-remaining-IOMMU-Pagesizes-present-in-LoPAR/20210408-035800
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-randconfig-r016-20210407 (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/faa8b10e5b9652dbd56ed8e759a1cc09b95805be
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Leonardo-Bras/powerpc-iommu-Enable-remaining-IOMMU-Pagesizes-present-in-LoPAR/20210408-035800
git checkout faa8b10e5b9652dbd56ed8e759a1cc09b95805be
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from include/vdso/const.h:5,
from include/linux/const.h:4,
from include/linux/bits.h:5,
from include/linux/bitops.h:6,
from include/linux/kernel.h:11,
from include/asm-generic/bug.h:20,
from arch/powerpc/include/asm/bug.h:109,
from include/linux/bug.h:5,
from include/linux/mmdebug.h:5,
from include/linux/gfp.h:5,
from include/linux/slab.h:15,
from arch/powerpc/platforms/pseries/iommu.c:15:
arch/powerpc/platforms/pseries/iommu.c: In function 'iommu_get_page_shift':
>> include/uapi/linux/const.h:20:19: error: conversion from 'long long unsigned
>> int' to 'unsigned int' changes value from '17179869184' to '0'
>> [-Werror=overflow]
20 | #define __AC(X,Y) (X##Y)
| ^~
include/uapi/linux/const.h:21:18: note: in expansion of macro '__AC'
21 | #define _AC(X,Y) __AC(X,Y)
| ^~~~
include/linux/sizes.h:48:19: note: in expansion of macro '_AC'
48 | #define SZ_16G_AC(0x4, ULL)
| ^~~
arch/powerpc/platforms/pseries/iommu.c:1120:42: note: in expansion of macro
'SZ_16G'
1120 | { QUERY_DDW_PGSIZE_16G, __builtin_ctz(SZ_16G) },
| ^~
cc1: all warnings being treated as errors
vim +20 include/uapi/linux/const.h
9d291e787b2b71 include/asm-x86_64/const.h Vivek Goyal 2007-05-02 6
9d291e787b2b71 include/asm-x86_64/const.h Vivek Goyal 2007-05-02 7
/* Some constant macros are used in both assembler and
9d291e787b2b71 include/asm-x86_64/const.h Vivek Goyal 2007-05-02 8
* C code. Therefore we cannot annotate them always with
6df95fd7ad9a84 include/linux/const.h Randy Dunlap2007-05-08 9
* 'UL' and other type specifiers unilaterally. We
9d291e787b2b71 include/asm-x86_64/const.h Vivek Goyal 2007-05-02 10
* use the following macros to deal with this.
74ef649fe847fd include/linux/const.h Jeremy Fitzhardinge 2008-01-30 11 *
74ef649fe847fd include/linux/const.h Jeremy Fitzhardinge 2008-01-30 12
* Similarly, _AT() will cast an expression with a type in C, but
74ef649fe847fd include/linux/const.h Jeremy Fitzhardinge 2008-01-30 13
* leave it unchanged in asm.
9d291e787b2b71 include/asm-x86_64/const.h Vivek Goyal 2007-05-02 14
*/
9d291e787b2b71 include/asm-x86_64/const.h Vivek Goyal 2007-05-02 15
9d291e787b2b71 include/asm-x86_64/const.h Vivek Goyal 2007-05-02 16
#ifdef __ASSEMBLY__
9d291e787b2b71 include/asm-x86_64/const.h Vivek Goyal 2007-05-02 17
#define _AC(X,Y) X
74ef649fe847fd include/linux/const.h Jeremy Fitzhardinge 2008-01-30 18
#define _AT(T,X) X
9d291e787b2b71 include/asm-x86_64/const.h Vivek Goyal 2007-05-02 19
#else
9d291e787b2b71 include/asm-x86_64/const.h Vivek Goyal 2007-05-02 @20
#define __AC(X,Y) (X##Y)
9d291e787b2b71 include/asm-x86_64/const.h Vivek Goyal 2007-05-02 21
#define _AC(X,Y) __AC(X,Y)
74ef649fe847fd include/linux/const.h Jeremy Fitzhardinge 2008-01-30 22
#define _AT(T,X) ((T)(X))
9d291e787b2b71 include/asm-x86_64/cons
Re: [Intel-gfx] [PATCH v2] drm/i915: Fix invalid access to ACPI _DSM objects
On Wed, 07 Apr 2021 23:28:48 +0200,
Ville Syrjälä wrote:
>
> On Wed, Apr 07, 2021 at 06:56:15PM +0200, Takashi Iwai wrote:
> > On Wed, 07 Apr 2021 18:34:46 +0200,
> > Ville Syrjälä wrote:
> > >
> > > On Fri, Apr 02, 2021 at 10:23:17AM +0200, Takashi Iwai wrote:
> > > > intel_dsm_platform_mux_info() tries to parse the ACPI package data
> > > > from _DSM for the debug information, but it assumes the fixed format
> > > > without checking what values are stored in the elements actually.
> > > > When an unexpected value is returned from BIOS, it may lead to GPF or
> > > > NULL dereference, as reported recently.
> > > >
> > > > Add the checks of the contents in the returned values and skip the
> > > > values for invalid cases.
> > > >
> > > > v1->v2: Check the info contents before dereferencing, too
> > > >
> > > > BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=1184074
> > > > Cc:
> > > > Signed-off-by: Takashi Iwai
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_acpi.c | 22 --
> > > > 1 file changed, 20 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> > > > b/drivers/gpu/drm/i915/display/intel_acpi.c
> > > > index e21fb14d5e07..833d0c1be4f1 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> > > > @@ -84,13 +84,31 @@ static void intel_dsm_platform_mux_info(acpi_handle
> > > > dhandle)
> > > > return;
> > > > }
> > > >
> > > > + if (!pkg->package.count) {
> > > > + DRM_DEBUG_DRIVER("no connection in _DSM\n");
> > > > + return;
> > > > + }
> > > > +
> > > > connector_count = &pkg->package.elements[0];
> > > > DRM_DEBUG_DRIVER("MUX info connectors: %lld\n",
> > > > (unsigned long long)connector_count->integer.value);
> > > > for (i = 1; i < pkg->package.count; i++) {
> > > > union acpi_object *obj = &pkg->package.elements[i];
> > > > - union acpi_object *connector_id =
> > > > &obj->package.elements[0];
> > > > - union acpi_object *info = &obj->package.elements[1];
> > > > + union acpi_object *connector_id;
> > > > + union acpi_object *info;
> > > > +
> > > > + if (obj->type != ACPI_TYPE_PACKAGE ||
> > > > obj->package.count < 2) {
> > > > + DRM_DEBUG_DRIVER("Invalid object for MUX
> > > > #%d\n", i);
> > > > + continue;
> > > > + }
> > > > +
> > > > + connector_id = &obj->package.elements[0];
> > >
> > > You don't want to check connector_id->type as well?
> >
> > I added only the minimal checks that may lead to Oops.
>
> OK. I guess misinterpreting something else as an integer isn't
> particular dangerous in this case.
>
> Pushed to drm-intel-next. Thanks.
Great, thanks!
> Oh, could you ask the bug reporter to attach an acpidump to the
> bug? Might be good to have that stuff on record somewhere if/when
> someone wants to actually figure out what's going on here.
OK, I'll ask.
> That said, maybe we should just nuke this whole thing instead?
> Unless I'm missing someting this code doesn't seem to actually
> do anything...
Yeah, that looks nothing but showing the debug information and that
can be checked via acpidump output, too...
Takashi
Re: [RFC bpf-next 0/1] bpf: Add page cache iterator
On Wed, Apr 07, 2021 at 02:46:10PM -0700, Daniel Xu wrote: > There currently does not exist a way to answer the question: "What is in > the page cache?". There are various heuristics and counters but nothing > that can tell you anything like: > > * 3M from /home/dxu/foo.txt > * 5K from ... > * etc. > > The answer to the question is particularly useful in the stacked > container world. Stacked containers implies multiple containers are run > on the same physical host. Memory is precious resource on some (if not Just to clarify: what are "stacked containers"? Do you mean nested containers, i.e. containers running within containers? Christian
Re: Linux 4.19.185
On 2021/4/7 19:16, Greg Kroah-Hartman wrote: I'm announcing the release of the 4.19.185 kernel. All users of the 4.19 kernel series must upgrade. The updated 4.19.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.19.y and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Tested on arm64 and x86 for 4.19.185, Kernel repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Branch: linux-4.19.y Version: 4.19.185 Commit: b4454811f122c6a0a330ced6b854e6ef32c37857 Compiler: gcc version 7.3.0 (GCC) arm64: Testcase Result Summary: total: 4679 passed: 4679 failed: 0 timeout: 0 x86: Testcase Result Summary: total: 4679 passed: 4679 failed: 0 timeout: 0 Tested-by: Hulk Robot
Re: linux-next: Fixes tag needs some work in the pm tree
Stephen Rothwell writes:
> Hi all,
>
> In commit
>
> fa26d0c778b4 ("ACPI: processor: Fix build when CONFIG_ACPI_PROCESSOR=m")
>
> Fixes tag
>
> Fixes: 8c182bd7 ("CPI: processor: Fix CPU0 wakeup in
> acpi_idle_play_dead()")
"A" in "ACPI" seems to be missing
>
> has these problem(s):
>
> - Subject does not match target commit subject
> Just use
> git log -1 --format='Fixes: %h ("%s")'
This is an extremely unlucky fix :-(
--
Vitaly
Re: [PATCH v4 08/16] KVM: x86/pmu: Add IA32_DS_AREA MSR emulation to manage guest DS buffer
On Thu, Apr 08, 2021 at 01:39:49PM +0800, Xu, Like wrote:
> Hi Peter,
>
> Thanks for your detailed comments.
>
> If you have more comments for other patches, please let me know.
>
> On 2021/4/7 23:39, Peter Zijlstra wrote:
> > On Mon, Mar 29, 2021 at 01:41:29PM +0800, Like Xu wrote:
> > > @@ -3869,10 +3876,12 @@ static struct perf_guest_switch_msr
> > > *intel_guest_get_msrs(int *nr, void *data)
> > > if (arr[1].guest)
> > > arr[0].guest |= arr[1].guest;
> > > - else
> > > + else {
> > > arr[1].guest = arr[1].host;
> > > + arr[2].guest = arr[2].host;
> > > + }
> > What's all this gibberish?
> >
> > The way I read that it says:
> >
> > if guest has PEBS_ENABLED
> > guest GLOBAL_CTRL |= PEBS_ENABLED
> > otherwise
> > guest PEBS_ENABLED = host PEBS_ENABLED
> > guest DS_AREA = host DS_AREA
> >
> > which is just completely random garbage afaict. Why would you leak host
> > msrs into the guest?
>
> In fact, this is not a leak at all.
>
> When we do "arr[i].guest = arr[i].host;" assignment in the
> intel_guest_get_msrs(), the KVM will check "if (msrs[i].host ==
> msrs[i].guest)" and if so, it disables the atomic switch for this msr
> during vmx transaction in the caller atomic_switch_perf_msrs().
Another marvel of bad coding style that function is :-( Lots of missing
{} and indentation fail.
This is terrible though, why would we clear the guest MSRs when it
changes PEBS_ENABLED. The guest had better clear them itself. Removing
guest DS_AREA just because we don't have any bits set in PEBS_ENABLED is
wrong and could very break all sorts of drivers.
> In that case, the msr value doesn't change and any guest write will be
> trapped. If the next check is "msrs[i].host != msrs[i].guest", the
> atomic switch will be triggered again.
>
> Compared to before, this part of the logic has not changed, which helps to
> reduce overhead.
It's unreadable garbage at best. If you don't want it changed, then
don't add it to the arr[] thing in the first place.
> > Why would you change guest GLOBAL_CTRL implicitly;
>
> This is because in the early part of this function, we have operations:
>
> if (x86_pmu.flags & PMU_FL_PEBS_ALL)
> arr[0].guest &= ~cpuc->pebs_enabled;
> else
> arr[0].guest &= ~(cpuc->pebs_enabled & PEBS_COUNTER_MASK);
>
> and if guest has PEBS_ENABLED, we need these bits back for PEBS counters:
>
> arr[0].guest |= arr[1].guest;
I don't think that's right, who's to say they were set in the first
place? The guest's GLOBAL_CTRL could have had the bits cleared at VMEXIT
time. You can't unconditionally add PEBS_ENABLED into GLOBAL_CTRL,
that's wrong.
> > guest had better wrmsr that himself to control when stuff is enabled.
>
> When vm_entry, the msr value of GLOBAL_CTRL on the hardware may be
> different from trapped value "pmu->global_ctrl" written by the guest.
>
> If the perf scheduler cross maps guest counter X to the host counter Y,
> we have to enable the bit Y in GLOBAL_CTRL before vm_entry rather than X.
Sure, but I don't see that happening here.
Re: [RFC PATCH 34/37] mm: rcu safe vma freeing only for multithreaded user space
On Wed, Apr 07, 2021 at 03:50:06AM +0100, Matthew Wilcox wrote: > On Tue, Apr 06, 2021 at 06:44:59PM -0700, Michel Lespinasse wrote: > > Performance tuning: as single threaded userspace does not use > > speculative page faults, it does not require rcu safe vma freeing. > > Turn this off to avoid the related (small) extra overheads. > > > > For multi threaded userspace, we often see a performance benefit from > > the rcu safe vma freeing - even in tests that do not have any frequent > > concurrent page faults ! This is because rcu safe vma freeing prevents > > recently released vmas from being immediately reused in a new thread. > > Why does that provide a performance benefit? Recently released > VMAs are cache-hot, and NUMA-local. I'd expect the RCU delay to be > performance-negative. I only have the observation and no full explanation for it. Just try it on wis-mmap and wis-malloc threaded cases. Of course this all washes away when dealing with more realistic macro benchmarks.
Re: [PATCH 2/3] media: rdacm21: describe better a truncation
Hi Mauro On Thu, Apr 08, 2021 at 09:40:03AM +0200, Mauro Carvalho Chehab wrote: > As warned by sparse: > > drivers/media/i2c/rdacm21.c:348:62: warning: cast truncates bits from > constant value (300a becomes a) > > the intention of the code is to get just the lowest 8 bits. > So, instead of using a typecast, use a bit and logic. > > Signed-off-by: Mauro Carvalho Chehab Please see https://patchwork.linuxtv.org/project/linux-media/patch/20210319164148.199192-11-jacopo+rene...@jmondi.org/ Whatever gets in first it's fine, so you can add my Acked-by: Jacopo Mondi to this one too Thanks j > --- > drivers/media/i2c/rdacm21.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/i2c/rdacm21.c b/drivers/media/i2c/rdacm21.c > index dcc21515e5a4..179d107f494c 100644 > --- a/drivers/media/i2c/rdacm21.c > +++ b/drivers/media/i2c/rdacm21.c > @@ -345,7 +345,7 @@ static int ov10640_initialize(struct rdacm21_device *dev) > /* Read OV10640 ID to test communications. */ > ov490_write_reg(dev, OV490_SCCB_SLAVE0_DIR, OV490_SCCB_SLAVE_READ); > ov490_write_reg(dev, OV490_SCCB_SLAVE0_ADDR_HIGH, OV10640_CHIP_ID >> 8); > - ov490_write_reg(dev, OV490_SCCB_SLAVE0_ADDR_LOW, (u8)OV10640_CHIP_ID); > + ov490_write_reg(dev, OV490_SCCB_SLAVE0_ADDR_LOW, OV10640_CHIP_ID & > 0xff); > > /* Trigger SCCB slave transaction and give it some time to complete. */ > ov490_write_reg(dev, OV490_HOST_CMD, OV490_HOST_CMD_TRIGGER); > -- > 2.30.2 >
[PATCH] KVM: vmx: add mismatched size in vmcs_check32
From: Haiwei Li
vmcs_check32 misses the check for 64-bit and 64-bit high.
Signed-off-by: Haiwei Li
---
arch/x86/kvm/vmx/vmx_ops.h | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/kvm/vmx/vmx_ops.h b/arch/x86/kvm/vmx/vmx_ops.h
index 692b0c3..164b64f 100644
--- a/arch/x86/kvm/vmx/vmx_ops.h
+++ b/arch/x86/kvm/vmx/vmx_ops.h
@@ -37,6 +37,10 @@ static __always_inline void vmcs_check32(unsigned long field)
{
BUILD_BUG_ON_MSG(__builtin_constant_p(field) && ((field) & 0x6000) == 0,
"32-bit accessor invalid for 16-bit field");
+ BUILD_BUG_ON_MSG(__builtin_constant_p(field) && ((field) & 0x6001) ==
0x2000,
+"32-bit accessor invalid for 64-bit field");
+ BUILD_BUG_ON_MSG(__builtin_constant_p(field) && ((field) & 0x6001) ==
0x2001,
+"32-bit accessor invalid for 64-bit high field");
BUILD_BUG_ON_MSG(__builtin_constant_p(field) && ((field) & 0x6000) ==
0x6000,
"32-bit accessor invalid for natural width field");
}
--
1.8.3.1
Re: linux-next: build failure after merge of the irqchip tree
Hi Stephen,
On 2021-04-08 07:35, Stephen Rothwell wrote:
Hi all,
After merging the irqchip tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/irqchip/irq-wpcm450-aic.c:9:10: fatal error: asm/exception.h:
No such file or directory
9 | #include
| ^
Caused by commit
fead4dd49663 ("irqchip: Add driver for WPCM450 interrupt controller")
I have used the irqchip tree from next-20210407 for today.
Thanks for the heads up. I guess that's the effect of COMPILE_TEST
which was apparently not very well tested... I'll drop it from Kconfig.
Jonathan, feel free to submit something re-enabling COMPILE_TEST once
you've worked out the missing dependencies.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Re: [PATCH v2 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
Hello Nobuhiro, On Thu, Apr 08, 2021 at 08:15:48AM +0900, Nobuhiro Iwamatsu wrote: > > > + /* > > > + * pwmc is a 2-bit divider for the input clock running at 1 MHz. > > > + * When the settings of the PWM are modified, the new values are > > > shadowed in hardware until > > > + * the period register (PCSR) is written and the currently running > > > period is completed. This > > > + * way the hardware switches atomically from the old setting to the new. > > > + * Also, disabling the hardware completes the currently running period > > > and keeps the output > > > + * at low level at all times. > > > > Did you just copy my optimal description or is your hardware really that > > nice? > > Yes, this hardware works as you wrote. > And I added about the state if the sinnal when this hardware disabled. > > > > > Do you know scripts/checkpatch.pl? I bet it will tell you to limit your > > lines to approx. 80 chars where sensible. > > Yes, I know. I ran scripts/checkpatch.pl before send patch. > I understand that the number of characters per line has been changed to > 100 characters. Does the pwm driver recommend 80 characters? For free-text comments I'd still recommend 80, yes. For code lines I'd be indeed more lax, as a line break in function calls reduces readability. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [PATCH 0/4] USB: serial: closing-wait cleanups
On Wed, Apr 07, 2021 at 05:24:52PM +0200, Greg Kroah-Hartman wrote: > On Wed, Apr 07, 2021 at 12:45:25PM +0200, Johan Hovold wrote: > > Now that all USB serial drivers supports changing the closing_wait > > parameter through TIOCSSERIAL (setserial), we can remove the related > > driver-specific module parameters and settings. > > > > These depend on the recently posted TIOCSSERIAL series. > > Yes! Getting rid of the module parameter is so good... > > Reviewed-by: Greg Kroah-Hartman Thanks for reviewing these. All three sets now applied. Johan
Re: [PATCH] staging: rtl8712: removed unnecessary blank line
On Thu, Apr 08, 2021 at 01:17:49PM +0530, Mitali Borkar wrote:
> Cleanup patch for CHECK: blank lines aren't necessary after an open
> brace '{'
> Reported by checkpatch
But you did more than just the above in this patch, which is not ok :(
Re: [PATCH 1/2] zram: fix crashes due to use of cpu hotplug multistate
On Thu, 8 Apr 2021, Greg KH wrote: > Removing a module from a system has always been "let's try it and see!" > type of operation for a very long time. Which part of it? If there is a driver/subsystem code that can't handle the reverse operation to modprobe, it clearly can't handle error handling during modprobe (which, one would hope, is supported), and should be fixed. If there is a particular issue in kernel dynamic linker that causes crash on module removal, we'd better off fixing it. Is there one such that makes you claim module removal unsupported? Thanks, -- Jiri Kosina SUSE Labs
[PATCH -next] cgroup/cpuset: fix typos in comments
Change hierachy to hierarchy and unrechable to unreachable, no functionality changed. Signed-off-by: Lu Jialin --- kernel/cgroup/cpuset.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index 5258b68153e0..a945504c0ae7 100644 --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -585,7 +585,7 @@ static int validate_change(struct cpuset *cur, struct cpuset *trial) par = parent_cs(cur); - /* On legacy hiearchy, we must be a subset of our parent cpuset. */ + /* On legacy hierarchy, we must be a subset of our parent cpuset. */ ret = -EACCES; if (!is_in_v2_mode() && !is_cpuset_subset(trial, par)) goto out; @@ -1726,7 +1726,7 @@ static void update_tasks_nodemask(struct cpuset *cs) * When configured nodemask is changed, the effective nodemasks of this cpuset * and all its descendants need to be updated. * - * On legacy hiearchy, effective_mems will be the same with mems_allowed. + * On legacy hierarchy, effective_mems will be the same with mems_allowed. * * Called with cpuset_mutex held */ @@ -2500,7 +2500,7 @@ static s64 cpuset_read_s64(struct cgroup_subsys_state *css, struct cftype *cft) BUG(); } - /* Unrechable but makes gcc happy */ + /* Unreachable but makes gcc happy */ return 0; } -- 2.17.1
Re: [PATCH v1] drivers: pinctrl: qcom: fix Kconfig dependency on GPIOLIB
On Mon, Mar 29, 2021 at 6:41 PM Julian Braha wrote: > > On Tuesday, March 2, 2021 9:46:04 AM EDT you wrote: > > On Thu, Feb 25, 2021 at 9:33 AM Julian Braha wrote: > > > > > When PINCTRL_MSM is enabled, and GPIOLIB is disabled, > > > Kbuild gives the following warning: > > > > > > WARNING: unmet direct dependencies detected for GPIOLIB_IRQCHIP > > > Depends on [n]: GPIOLIB [=n] > > > Selected by [y]: > > > - PINCTRL_MSM [=y] && PINCTRL [=y] && (ARCH_QCOM || COMPILE_TEST [=y]) > > > > > > This is because PINCTRL_MSM selects GPIOLIB_IRQCHIP, > > > without selecting or depending on GPIOLIB, despite > > > GPIOLIB_IRQCHIP depending on GPIOLIB. Having PINCTRL_MSM > > > select GPIOLIB will cause a recursive dependency error. > > > > > > Signed-off-by: Julian Braha > > > > Does it work to just: > > > > select GPIOLIB > > > > instead? > > > > The driver needs the library so... > > > > Yours, > > Linus Walleij > > > > Hi Linus, > > Looks like I confused this patch with another one when > I responded last time. This config option cannot select > GPIOLIB, because it will cause a recursive dependency > error. > > Any other ideas? No we can apply the patch as-is but let Bjorn have a look at it first, I noticed he is not on the To: line of the original patch. You may need to resend with Bjorn Andersson in the recipients. Yours, Linus Walleij
[Outreachy kernel] [PATCH] staging: rtl8723bs: Remove camelcase in several files
Remove camelcase in a symbol that is used by several files.
Signed-off-by: Fabio M. De Francesco
---
drivers/staging/rtl8723bs/core/rtw_cmd.c | 2 +-
drivers/staging/rtl8723bs/core/rtw_mlme.c | 2 +-
drivers/staging/rtl8723bs/core/rtw_pwrctrl.c | 18 +-
drivers/staging/rtl8723bs/hal/hal_intf.c | 2 +-
drivers/staging/rtl8723bs/hal/rtl8723b_dm.c| 6 +++---
.../staging/rtl8723bs/hal/rtl8723b_hal_init.c | 2 +-
drivers/staging/rtl8723bs/hal/sdio_ops.c | 14 +++---
.../staging/rtl8723bs/include/rtw_pwrctrl.h| 2 +-
8 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_cmd.c
b/drivers/staging/rtl8723bs/core/rtw_cmd.c
index baf8b1e0f43c..a08f22b53592 100644
--- a/drivers/staging/rtl8723bs/core/rtw_cmd.c
+++ b/drivers/staging/rtl8723bs/core/rtw_cmd.c
@@ -1510,7 +1510,7 @@ static void rtw_lps_change_dtim_hdl(struct adapter
*padapter, u8 dtim)
if (pwrpriv->dtim != dtim)
pwrpriv->dtim = dtim;
- if ((pwrpriv->bFwCurrentInPSMode == true) && (pwrpriv->pwr_mode >
PS_MODE_ACTIVE)) {
+ if ((pwrpriv->b_fw_current_in_ps_mode == true) && (pwrpriv->pwr_mode >
PS_MODE_ACTIVE)) {
u8 ps_mode = pwrpriv->pwr_mode;
rtw_hal_set_hwreg(padapter, HW_VAR_H2C_FW_PWRMODE, (u8
*)(&ps_mode));
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c
b/drivers/staging/rtl8723bs/core/rtw_mlme.c
index a7e40aaae2d9..51cea6cf46e7 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
@@ -1684,7 +1684,7 @@ void rtw_dynamic_check_timer_handler(struct adapter
*adapter)
if (adapter->net_closed)
return;
- if ((adapter_to_pwrctl(adapter)->bFwCurrentInPSMode)
+ if ((adapter_to_pwrctl(adapter)->b_fw_current_in_ps_mode)
&& !(hal_btcoex_IsBtControlLps(adapter))
) {
u8 bEnterPS;
diff --git a/drivers/staging/rtl8723bs/core/rtw_pwrctrl.c
b/drivers/staging/rtl8723bs/core/rtw_pwrctrl.c
index f7465cf90c46..21e7a847866f 100644
--- a/drivers/staging/rtl8723bs/core/rtw_pwrctrl.c
+++ b/drivers/staging/rtl8723bs/core/rtw_pwrctrl.c
@@ -365,7 +365,7 @@ void rtw_set_ps_mode(struct adapter *padapter, u8 ps_mode,
u8 smart_ps, u8 bcn_a
rtw_set_rpwm(padapter, PS_STATE_S4);
rtw_hal_set_hwreg(padapter, HW_VAR_H2C_FW_PWRMODE, (u8
*)(&ps_mode));
- pwrpriv->bFwCurrentInPSMode = false;
+ pwrpriv->b_fw_current_in_ps_mode = false;
hal_btcoex_LpsNotify(padapter, ps_mode);
}
@@ -377,7 +377,7 @@ void rtw_set_ps_mode(struct adapter *padapter, u8 ps_mode,
u8 smart_ps, u8 bcn_a
hal_btcoex_LpsNotify(padapter, ps_mode);
- pwrpriv->bFwCurrentInPSMode = true;
+ pwrpriv->b_fw_current_in_ps_mode = true;
pwrpriv->pwr_mode = ps_mode;
pwrpriv->smart_ps = smart_ps;
pwrpriv->bcn_ant_mode = bcn_ant_mode;
@@ -734,7 +734,7 @@ s32 rtw_register_task_alive(struct adapter *padapter, u32
task)
register_task_alive(pwrctrl, task);
- if (pwrctrl->bFwCurrentInPSMode) {
+ if (pwrctrl->b_fw_current_in_ps_mode) {
if (pwrctrl->cpwm < pslv) {
if (pwrctrl->cpwm < PS_STATE_S2)
res = _FAIL;
@@ -782,7 +782,7 @@ void rtw_unregister_task_alive(struct adapter *padapter,
u32 task)
unregister_task_alive(pwrctrl, task);
- if ((pwrctrl->pwr_mode != PS_MODE_ACTIVE) &&
pwrctrl->bFwCurrentInPSMode) {
+ if ((pwrctrl->pwr_mode != PS_MODE_ACTIVE) &&
pwrctrl->b_fw_current_in_ps_mode) {
if (pwrctrl->cpwm > pslv)
if ((pslv >= PS_STATE_S2) || (pwrctrl->alives == 0))
rtw_set_rpwm(padapter, pslv);
@@ -819,7 +819,7 @@ s32 rtw_register_tx_alive(struct adapter *padapter)
register_task_alive(pwrctrl, XMIT_ALIVE);
- if (pwrctrl->bFwCurrentInPSMode) {
+ if (pwrctrl->b_fw_current_in_ps_mode) {
if (pwrctrl->cpwm < pslv) {
if (pwrctrl->cpwm < PS_STATE_S2)
res = _FAIL;
@@ -864,7 +864,7 @@ s32 rtw_register_cmd_alive(struct adapter *padapter)
register_task_alive(pwrctrl, CMD_ALIVE);
- if (pwrctrl->bFwCurrentInPSMode) {
+ if (pwrctrl->b_fw_current_in_ps_mode) {
if (pwrctrl->cpwm < pslv) {
if (pwrctrl->cpwm < PS_STATE_S2)
res = _FAIL;
@@ -909,7 +909,7 @@ void rtw_unregister_tx_alive(struct adapter *padapter)
unregister_task_alive(pwrctrl, XMIT_ALIVE);
- if ((pwrctrl->pwr_mode != PS_MODE_ACTIVE) &&
pwrctrl->bFwCurrentInPSMode) {
+ if ((pwrctrl->pwr_mo
Re: [PATCH 1/2] zram: fix crashes due to use of cpu hotplug multistate
On Thu, Apr 08, 2021 at 10:01:23AM +0200, Jiri Kosina wrote: > On Thu, 8 Apr 2021, Greg KH wrote: > > > Removing a module from a system has always been "let's try it and see!" > > type of operation for a very long time. > > Which part of it? > > If there is a driver/subsystem code that can't handle the reverse > operation to modprobe, it clearly can't handle error handling during > modprobe (which, one would hope, is supported), and should be fixed. Huh? No, that's not the issue here, it's the issue of different userspace code paths into the module at the same time that it is trying to be unloaded. That has nothing to do with loading the module the first time as userspace is not touching those apis yet. > If there is a particular issue in kernel dynamic linker that causes crash > on module removal, we'd better off fixing it. Is there one such that makes > you claim module removal unsupported? The linker has nothing to do with this, it's userspace tasks touching code paths. thanks, greg k-h
Re: [PATCH v2] Bluetooth: Add ncmd=0 recovery handling
Hi Manish,
> During command status or command complete event, the controller may set
> ncmd=0 indicating that it is not accepting any more commands. In such a
> case, host holds off sending any more commands to the controller. If the
> controller doesn't recover from such condition, host will wait forever,
> until the user decides that the Bluetooth is broken and may power cycles
> the Bluetooth.
>
> This patch triggers the hardware error to reset the controller and
> driver when it gets into such state as there is no other wat out.
>
> Reviewed-by: Abhishek Pandit-Subedi
> Signed-off-by: Manish Mandlik
> ---
>
> Changes in v2:
> - Emit the hardware error when ncmd=0 occurs
>
> include/net/bluetooth/hci.h | 1 +
> include/net/bluetooth/hci_core.h | 1 +
> net/bluetooth/hci_core.c | 15 +++
> net/bluetooth/hci_event.c| 10 ++
> 4 files changed, 27 insertions(+)
>
> diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> index ea4ae551c426..c4b0650fb9ae 100644
> --- a/include/net/bluetooth/hci.h
> +++ b/include/net/bluetooth/hci.h
> @@ -339,6 +339,7 @@ enum {
> #define HCI_PAIRING_TIMEOUT msecs_to_jiffies(6) /* 60 seconds */
> #define HCI_INIT_TIMEOUT msecs_to_jiffies(1) /* 10 seconds */
> #define HCI_CMD_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */
> +#define HCI_NCMD_TIMEOUT msecs_to_jiffies(4000) /* 4 seconds */
> #define HCI_ACL_TX_TIMEOUTmsecs_to_jiffies(45000) /* 45 seconds */
> #define HCI_AUTO_OFF_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */
> #define HCI_POWER_OFF_TIMEOUT msecs_to_jiffies(5000) /* 5 seconds */
> diff --git a/include/net/bluetooth/hci_core.h
> b/include/net/bluetooth/hci_core.h
> index ebdd4afe30d2..f14692b39fd5 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -470,6 +470,7 @@ struct hci_dev {
> struct delayed_work service_cache;
>
> struct delayed_work cmd_timer;
> + struct delayed_work ncmd_timer;
>
> struct work_struct rx_work;
> struct work_struct cmd_work;
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index b0d9c36acc03..c102a8763cb5 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -2769,6 +2769,20 @@ static void hci_cmd_timeout(struct work_struct *work)
> queue_work(hdev->workqueue, &hdev->cmd_work);
> }
>
> +/* HCI ncmd timer function */
> +static void hci_ncmd_timeout(struct work_struct *work)
> +{
> + struct hci_dev *hdev = container_of(work, struct hci_dev,
> + ncmd_timer.work);
> +
> + bt_dev_err(hdev, "Controller not accepting commands anymore: ncmd = 0");
> +
> + /* This is an irrecoverable state. Inject hw error event to reset
> + * the device and driver.
> + */
> + hci_reset_dev(hdev);
/* This is an irrecoverable state, inject hardware error event */
hci_reset_dev(hdev);
Since you will not be resetting the driver here. You just tell the core stack
to reset itself and with HCI_Reset hopefully bring the hardware back to life.
Or if the ncmd=0 is a hardware bug, just start sending a new command.
> +}
> +
> struct oob_data *hci_find_remote_oob_data(struct hci_dev *hdev,
> bdaddr_t *bdaddr, u8 bdaddr_type)
> {
> @@ -3831,6 +3845,7 @@ struct hci_dev *hci_alloc_dev(void)
> init_waitqueue_head(&hdev->suspend_wait_q);
>
> INIT_DELAYED_WORK(&hdev->cmd_timer, hci_cmd_timeout);
> + INIT_DELAYED_WORK(&hdev->ncmd_timer, hci_ncmd_timeout);
>
> hci_request_setup(hdev);
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index cf2f4a0abdbd..114a9170d809 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -3635,6 +3635,11 @@ static void hci_cmd_complete_evt(struct hci_dev *hdev,
> struct sk_buff *skb,
> if (*opcode != HCI_OP_NOP)
> cancel_delayed_work(&hdev->cmd_timer);
>
> + if (!ev->ncmd &&!test_bit(HCI_RESET, &hdev->flags))
> + schedule_delayed_work(&hdev->ncmd_timer, HCI_NCMD_TIMEOUT);
> + else
> + cancel_delayed_work(&hdev->ncmd_timer);
> +
> if (ev->ncmd && !test_bit(HCI_RESET, &hdev->flags))
> atomic_set(&hdev->cmd_cnt, 1);
>
if (!test_bit(HCI_RESET, &hdev->flags)) {
if (ev->ncmd) {
cancel_delayed_work(&hdev->ncmd_timer);
atomic_set(&hdev->cmd_cnt, 1);
} else {
schedule_delayed_work(&hdev->ncmd_timer,
HCI_NCMD_TIMEOUT);
}
}
I think doing it this way is a bit cleaner and avoid the check of !ncmd and
!HCI_RESET twice.
And I wonder if there isn’t a cancel_delayed_work missing in hci_dev_do_close
or some related location when we are shutting down.
What do we do when
[PATCH] drm/vmwgfx: Remove useless variable
Fix the following gcc warning:
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c:163:6: warning: variable
‘ret’ set but not used [-Wunused-but-set-variable].
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
index 44d858c..0d210f8 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
@@ -160,7 +160,6 @@ void vmw_cmdbuf_res_commit(struct list_head *list)
void vmw_cmdbuf_res_revert(struct list_head *list)
{
struct vmw_cmdbuf_res *entry, *next;
- int ret;
list_for_each_entry_safe(entry, next, list, head) {
switch (entry->state) {
@@ -168,7 +167,7 @@ void vmw_cmdbuf_res_revert(struct list_head *list)
vmw_cmdbuf_res_free(entry->man, entry);
break;
case VMW_CMDBUF_RES_DEL:
- ret = drm_ht_insert_item(&entry->man->resources,
+ drm_ht_insert_item(&entry->man->resources,
&entry->hash);
list_del(&entry->head);
list_add_tail(&entry->head, &entry->man->list);
--
1.8.3.1
Re: [GIT PULL] clk: imx: Updates for v5.13
On 21-04-08 00:06:29, Stephen Boyd wrote: > Quoting Abel Vesa (2021-04-04 13:40:24) > > The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15: > > > > Linux 5.12-rc2 (2021-03-05 17:33:41 -0800) > > > > are available in the Git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/abelvesa/linux.git clk/imx > > > > for you to fetch changes up to 054ef44ea3ef2883e0f63c9a54c91c07f321a0b4: > > > > clk: imx: Reference preceded by free (2021-04-04 22:39:05 +0300) > > > > > > Thanks. Pulled into clk-next. Next time can you send a signed tag with a > small blurb about what is included? Oups, I mistakenly used the branch instead of using the tag. The tag is here: https://git.kernel.org/pub/scm/linux/kernel/git/abelvesa/linux.git/tag/?h=clk-imx-5.13
Re: [PATCH 05/16] media: cadence: csi2rx: Add external DPHY support
On Wed, 2021-04-07 at 00:24 +0530, Pratyush Yadav wrote:
> On 31/03/21 05:24PM, Chunfeng Yun wrote:
> > On Tue, 2021-03-30 at 23:03 +0530, Pratyush Yadav wrote:
> > > Some platforms like TI's J721E can have the CSI2RX paired with an
> > > external DPHY. Add support to enable and configure the DPHY using the
> > > generic PHY framework.
> > >
> > > Get the pixel rate and bpp from the subdev and pass them on to the DPHY
> > > along with the number of lanes. All other settings are left to their
> > > default values.
> > >
> > > Signed-off-by: Pratyush Yadav
> > > ---
> > > drivers/media/platform/cadence/cdns-csi2rx.c | 147 +--
> > > 1 file changed, 137 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c
> > > b/drivers/media/platform/cadence/cdns-csi2rx.c
> > > index c68a3eac62cd..31bd80e3f780 100644
> > > --- a/drivers/media/platform/cadence/cdns-csi2rx.c
> > > +++ b/drivers/media/platform/cadence/cdns-csi2rx.c
> > > @@ -30,6 +30,12 @@
> > > #define CSI2RX_STATIC_CFG_DLANE_MAP(llane, plane)((plane) << (16
> > > + (llane) * 4))
> > > #define CSI2RX_STATIC_CFG_LANES_MASK GENMASK(11, 8)
> > >
> > > +#define CSI2RX_DPHY_LANE_CTRL_REG0x40
> > > +#define CSI2RX_DPHY_CL_RST BIT(16)
> > > +#define CSI2RX_DPHY_DL_RST(i)BIT((i) + 12)
> > > +#define CSI2RX_DPHY_CL_ENBIT(4)
> > > +#define CSI2RX_DPHY_DL_EN(i) BIT(i)
> > > +
> > > #define CSI2RX_STREAM_BASE(n)(((n) + 1) * 0x100)
> > >
> > > #define CSI2RX_STREAM_CTRL_REG(n)(CSI2RX_STREAM_BASE(n)
> > > + 0x000)
> > > @@ -54,6 +60,11 @@ enum csi2rx_pads {
> > > CSI2RX_PAD_MAX,
> > > };
> > >
> > > +struct csi2rx_fmt {
> > > + u32 code;
> > > + u8 bpp;
> > > +};
> > > +
> > > struct csi2rx_priv {
> > > struct device *dev;
> > > unsigned intcount;
> > > @@ -85,6 +96,52 @@ struct csi2rx_priv {
> > > int source_pad;
> > > };
> > >
> > > +static const struct csi2rx_fmt formats[] = {
> > > + {
> > > + .code = MEDIA_BUS_FMT_YUYV8_2X8,
> > > + .bpp= 16,
> > > + },
> > > + {
> > > + .code = MEDIA_BUS_FMT_UYVY8_2X8,
> > > + .bpp= 16,
> > > + },
> > > + {
> > > + .code = MEDIA_BUS_FMT_YVYU8_2X8,
> > > + .bpp= 16,
> > > + },
> > > + {
> > > + .code = MEDIA_BUS_FMT_VYUY8_2X8,
> > > + .bpp= 16,
> > > + },
> > > +};
> > > +
> > > +static u8 csi2rx_get_bpp(u32 code)
> > > +{
> > > + int i;
> > > +
> > > + for (i = 0; i < ARRAY_SIZE(formats); i++) {
> > > + if (formats[i].code == code)
> > > + return formats[i].bpp;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static s64 csi2rx_get_pixel_rate(struct csi2rx_priv *csi2rx)
> > > +{
> > > + struct v4l2_ctrl *ctrl;
> > > +
> > > + ctrl = v4l2_ctrl_find(csi2rx->source_subdev->ctrl_handler,
> > > + V4L2_CID_PIXEL_RATE);
> > > + if (!ctrl) {
> > > + dev_err(csi2rx->dev, "no pixel rate control in subdev: %s\n",
> > > + csi2rx->source_subdev->name);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + return v4l2_ctrl_g_ctrl_int64(ctrl);
> > > +}
> > > +
> > > static inline
> > > struct csi2rx_priv *v4l2_subdev_to_csi2rx(struct v4l2_subdev *subdev)
> > > {
> > > @@ -101,6 +158,55 @@ static void csi2rx_reset(struct csi2rx_priv *csi2rx)
> > > writel(0, csi2rx->base + CSI2RX_SOFT_RESET_REG);
> > > }
> > >
> > > +static int csi2rx_configure_external_dphy(struct csi2rx_priv *csi2rx)
> > > +{
> > > + union phy_configure_opts opts = { };
> > > + struct phy_configure_opts_mipi_dphy *cfg = &opts.mipi_dphy;
> > > + struct v4l2_subdev_format sd_fmt;
> > > + s64 pixel_rate;
> > > + int ret;
> > > + u8 bpp;
> > > +
> > > + sd_fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
> > > + sd_fmt.pad = 0;
> > > +
> > > + ret = v4l2_subdev_call(csi2rx->source_subdev, pad, get_fmt, NULL,
> > > +&sd_fmt);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + bpp = csi2rx_get_bpp(sd_fmt.format.code);
> > > + if (!bpp)
> > > + return -EINVAL;
> > > +
> > > + pixel_rate = csi2rx_get_pixel_rate(csi2rx);
> > > + if (pixel_rate < 0)
> > > + return pixel_rate;
> > > +
> > > + ret = phy_mipi_dphy_get_default_config(pixel_rate, bpp,
> > > +csi2rx->num_lanes, cfg);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = phy_set_mode_ext(csi2rx->dphy, PHY_MODE_MIPI_DPHY,
> > > +PHY_MIPI_DPHY_SUBMODE_RX);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = phy_power_on(csi2rx->dphy);
> > > + if (ret)
> > > + return ret;
> > Seems phy_power_on, then phy_set_mode_ext?
>
> Shouldn't the mode be set be
[PATCH -next] PM: fix typos in comments
Change occured to occurred in kernel/power/autosleep.c. Change consiting to consisting in kernel/power/snapshot.c. Change avaiable to available in kernel/power/swap.c. No functionality changed. Signed-off-by: Lu Jialin --- kernel/power/autosleep.c | 2 +- kernel/power/snapshot.c | 2 +- kernel/power/swap.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/power/autosleep.c b/kernel/power/autosleep.c index 9af5a50d3489..b29c8aca7486 100644 --- a/kernel/power/autosleep.c +++ b/kernel/power/autosleep.c @@ -54,7 +54,7 @@ static void try_to_suspend(struct work_struct *work) goto out; /* -* If the wakeup occured for an unknown reason, wait to prevent the +* If the wakeup occurred for an unknown reason, wait to prevent the * system from trying to suspend and waking up in a tight loop. */ if (final_count == initial_count) diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c index 64b7aab9aee4..27cb4e7086b7 100644 --- a/kernel/power/snapshot.c +++ b/kernel/power/snapshot.c @@ -329,7 +329,7 @@ static void *chain_alloc(struct chain_allocator *ca, unsigned int size) /** * Data types related to memory bitmaps. * - * Memory bitmap is a structure consiting of many linked lists of + * Memory bitmap is a structure consisting of many linked lists of * objects. The main list's elements are of type struct zone_bitmap * and each of them corresonds to one zone. For each zone bitmap * object there is a list of objects of type struct bm_block that diff --git a/kernel/power/swap.c b/kernel/power/swap.c index 72e33054a2e1..bea3cb8afa11 100644 --- a/kernel/power/swap.c +++ b/kernel/power/swap.c @@ -884,7 +884,7 @@ static int save_image_lzo(struct swap_map_handle *handle, * enough_swap - Make sure we have enough swap to save the image. * * Returns TRUE or FALSE after checking the total amount of swap - * space avaiable from the resume partition. + * space available from the resume partition. */ static int enough_swap(unsigned int nr_pages) -- 2.17.1
Re: [PATCH v2 5/6] usb: typec: tcpm: Allow slow charging loops to comply to pSnkStby
On Wed, Apr 07, 2021 at 01:07:22PM -0700, Badhri Jagan Sridharan wrote:
> When a PD charger advertising Rp-3.0 is connected to a sink port, the
> sink port current limit would 3A, during SNK_DISCOVERY, till power
> negotiation starts. Once the negotiation starts the power limit needs
> to drop down to pSnkStby(500mA @ 5V) and to negotiated current limit
> once the explicit contract is in place. Not all charging loops can ramp
> up to 3A and drop down to 500mA within tSnkStdby which is 15ms. The port
> partner might hard reset if tSnkStdby is not met.
>
> To solve this problem, this patch introduces slow-charger-loop which
> when set makes the port request PD_P_SNK_STDBY_MW upon entering
> SNK_DISCOVERY(instead of 3A or the 1.5A during SNK_DISCOVERY) and the
> actual currrent limit after RX of PD_CTRL_PSRDY for PD link or during
> SNK_READY for non-pd link.
>
> Signed-off-by: Badhri Jagan Sridharan
> ---
> drivers/usb/typec/tcpm/tcpm.c | 18 +++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index 770b2edd9a04..b5bed6866a2b 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -459,6 +459,12 @@ struct tcpm_port {
> /* Auto vbus discharge status */
> bool auto_vbus_discharge_enabled;
>
> + /*
> + * When set, port requests PD_P_SNK_STDBY_MW upon entering
> SNK_DISCOVERY and
> + * the actual currrent limit after RX of PD_CTRL_PSRDY for PD link,
> + * SNK_READY for non-pd link.
> + */
> + bool slow_charger_loop;
> #ifdef CONFIG_DEBUG_FS
> struct dentry *dentry;
> struct mutex logbuffer_lock;/* log buffer access lock */
> @@ -4047,9 +4053,12 @@ static void run_state_machine(struct tcpm_port *port)
> break;
> case SNK_DISCOVERY:
> if (port->vbus_present) {
> - tcpm_set_current_limit(port,
> -tcpm_get_current_limit(port),
> -5000);
> + u32 current_lim = (!port->slow_charger_loop ||
> +(tcpm_get_current_limit(port) <=
> + PD_P_SNK_STDBY_MW / 5)) ?
> + tcpm_get_current_limit(port) :
> + PD_P_SNK_STDBY_MW / 5;
Here the use of the ternary operator is not appropriate. Please try to
clean that up somehow. Maybe something like this would be better?
u32 current_lim = tcpm_get_current_limit(port);
if (port->slow_charger_loop || (current_lim <
PD_P_SNK_STDBY_MW / 5))
current_lim = PD_P_SNK_STDBY_MW / 5;
> + tcpm_set_current_limit(port, current_lim, 5000);
> tcpm_set_charge(port, true);
> tcpm_set_state(port, SNK_WAIT_CAPABILITIES, 0);
> break;
> @@ -4161,6 +4170,8 @@ static void run_state_machine(struct tcpm_port *port)
> port->pwr_opmode = TYPEC_PWR_MODE_PD;
> }
>
> + if (!port->pd_capable && port->slow_charger_loop)
> + tcpm_set_current_limit(port,
> tcpm_get_current_limit(port), 5000);
> tcpm_swap_complete(port, 0);
> tcpm_typec_connect(port);
> mod_enable_frs_delayed_work(port, 0);
> @@ -5763,6 +5774,7 @@ static int tcpm_fw_get_caps(struct tcpm_port *port,
> port->typec_caps.type = ret;
> port->port_type = port->typec_caps.type;
>
> + port->slow_charger_loop = fwnode_property_read_bool(fwnode,
> "slow-charger-loop");
> if (port->port_type == TYPEC_PORT_SNK)
> goto sink;
>
> --
> 2.31.1.295.g9ea45b61b8-goog
thanks,
--
heikki
Re: [PATCH 1/2] KVM: x86: reduce pvclock_gtod_sync_lock critical sections
On 07/04/21 19:40, Marcelo Tosatti wrote: diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index fe806e894212..0a83eff40b43 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -2562,10 +2562,12 @@ static void kvm_gen_update_masterclock(struct kvm *kvm) kvm_hv_invalidate_tsc_page(kvm); - spin_lock(&ka->pvclock_gtod_sync_lock); kvm_make_mclock_inprogress_request(kvm); + Might be good to serialize against two kvm_gen_update_masterclock callers? Otherwise one caller could clear KVM_REQ_MCLOCK_INPROGRESS, while the other is still at pvclock_update_vm_gtod_copy(). Makes sense, but this stuff has always seemed unnecessarily complicated to me. KVM_REQ_MCLOCK_INPROGRESS is only needed to kick running vCPUs out of the execution loop; clearing it in kvm_gen_update_masterclock is unnecessary, because KVM_REQ_CLOCK_UPDATE takes pvclock_gtod_sync_lock too and thus will already wait for pvclock_update_vm_gtod_copy to end. I think it's possible to use a seqcount in KVM_REQ_CLOCK_UPDATE instead of KVM_REQ_MCLOCK_INPROGRESS. Both cause the vCPUs to spin. I'll take a look. Paolo
Re: [PATCH 2/3] fpga: dfl: Add DFL bus driver for Altera SPI Master
On Thu, Apr 08, 2021 at 03:30:15PM +0800, Wu, Hao wrote:
> > > On Mon, 5 Apr 2021, Moritz Fischer wrote:
> > >
> > > > Hi Matthew,
> > > >
> > > > On Mon, Apr 05, 2021 at 04:53:00PM -0700,
> > matthew.gerl...@linux.intel.com wrote:
> > > > > From: Matthew Gerlach
> > > > >
> > > > > This patch adds DFL bus driver for the Altera SPI Master
> > > > > controller. The SPI master is connected to an Intel SPI Slave to
> > > > > Avalon Master Bridge, inside an Intel MAX10 BMC Chip.
> > > > >
> > > > > Signed-off-by: Matthew Gerlach
> > > > > ---
> > > > > drivers/fpga/Kconfig | 9 ++
> > > > > drivers/fpga/Makefile | 1 +
> > > > > drivers/fpga/dfl-spi-altera.c | 221
> > ++
> > > > > 3 files changed, 231 insertions(+)
> > > > > create mode 100644 drivers/fpga/dfl-spi-altera.c
> > > > >
> > > > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > > > > index d591dd9..0a86994 100644
> > > > > --- a/drivers/fpga/Kconfig
> > > > > +++ b/drivers/fpga/Kconfig
> > > > > @@ -210,6 +210,15 @@ config FPGA_DFL_NIOS_INTEL_PAC_N3000
> > > > >the card. It also instantiates the SPI master (spi-altera) for
> > > > >the card's BMC (Board Management Controller).
> > > > >
> > > > > +config FPGA_DFL_SPI_ALTERA
> > > > > +tristate "FPGA DFL Altera SPI Master Driver"
> > > > > +depends on FPGA_DFL
> > > > > +select REGMAP
> > > > > +help
> > > > > + This is a DFL bus driver for the Altera SPI master controller.
> > > > > + The SPI master is connected to a SPI slave to Avalon Master
> > > > > + bridge in a Intel MAX BMC.
> > > > > +
> > > > > config FPGA_DFL_PCI
> > > > > tristate "FPGA DFL PCIe Device Driver"
> > > > > depends on PCI && FPGA_DFL
> > > > > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> > > > > index 18dc9885..58a42ad 100644
> > > > > --- a/drivers/fpga/Makefile
> > > > > +++ b/drivers/fpga/Makefile
> > > > > @@ -45,6 +45,7 @@ dfl-afu-objs := dfl-afu-main.o dfl-afu-region.o dfl-
> > afu-dma-region.o
> > > > > dfl-afu-objs += dfl-afu-error.o
> > > > >
> > > > > obj-$(CONFIG_FPGA_DFL_NIOS_INTEL_PAC_N3000)+= dfl-n3000-
> > nios.o
> > > > > +obj-$(CONFIG_FPGA_DFL_SPI_ALTERA)+= dfl-spi-altera.o
> > > > >
> > > > > # Drivers for FPGAs which implement DFL
> > > > > obj-$(CONFIG_FPGA_DFL_PCI)+= dfl-pci.o
> > > > > diff --git a/drivers/fpga/dfl-spi-altera.c
> > > > > b/drivers/fpga/dfl-spi-altera.c
> > > > > new file mode 100644
> > > > > index 000..9bec25fd
> > > > > --- /dev/null
> > > > > +++ b/drivers/fpga/dfl-spi-altera.c
> > > > > @@ -0,0 +1,221 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > +/*
> > > > > + * DFL bus driver for Altera SPI Master
> > > > > + *
> > > > > + * Copyright (C) 2020 Intel Corporation, Inc.
> > > > > + *
> > > > > + * Authors:
> > > > > + * Matthew Gerlach
> > > > > + */
> > > > > +
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +
> > > > > +struct dfl_altera_spi {
> > > > > +void __iomem *base;
> > > > > +struct regmap *regmap;
> > > > > +struct device *dev;
> > > > > +struct platform_device *altr_spi;
> > > > > +};
> > > > > +
> > > > > +#define SPI_CORE_PARAMETER 0x8
> > > > > +#define SHIFT_MODE BIT_ULL(1)
> > > > > +#define SHIFT_MODE_MSB 0
> > > > > +#define SHIFT_MODE_LSB 1
> > > > > +#define DATA_WIDTH GENMASK_ULL(7, 2)
> > > > > +#define NUM_CHIPSELECT GENMASK_ULL(13, 8)
> > > > > +#define CLK_POLARITYBIT_ULL(14)
> > > > > +#define CLK_PHASE BIT_ULL(15)
> > > > > +#define PERIPHERAL_ID GENMASK_ULL(47, 32)
> > > > > +#define SPI_CLK GENMASK_ULL(31, 22)
> > > > > +#define SPI_INDIRECT_ACC_OFST 0x10
> > > > > +
> > > > > +#define INDIRECT_ADDR (SPI_INDIRECT_ACC_OFST+0x0)
> > > > > +#define INDIRECT_WR BIT_ULL(8)
> > > > > +#define INDIRECT_RD BIT_ULL(9)
> > > > > +#define INDIRECT_RD_DATA(SPI_INDIRECT_ACC_OFST+0x8)
> > > > > +#define INDIRECT_DATA_MASK GENMASK_ULL(31, 0)
> > > > > +#define INDIRECT_DEBUG BIT_ULL(32)
> > > > > +#define INDIRECT_WR_DATA(SPI_INDIRECT_ACC_OFST+0x10)
> > > > > +#define INDIRECT_TIMEOUT1
> > > > > +
> > > > > +static int indirect_bus_reg_read(void *context, unsigned int reg,
> > > > > + unsigned int *val)
> > > > > +{
> > > > > +struct dfl_altera_spi *aspi = context;
> > > > > +void __iomem *base = aspi->base;
> > > > > +int loops;
> > > > > +u64 v;
> > > > > +
> > > > > +writeq((reg >> 2) | INDIRECT_RD, base + INDIRECT_ADDR);
> > > > > +
> > > > > +loops = 0;
> > > > > +while ((readq(base + INDIRECT_ADDR) & INDIRECT_RD) &&
> > > > > + (loops++ < INDIRECT_TIMEOUT))
> > > > > +cpu_relax();
> > > > > +
> > > > > +if
Re: [RFC Part1 PATCH 07/13] x86/compressed: register GHCB memory when SNP is active
On Wed, Apr 07, 2021 at 12:34:59PM -0500, Brijesh Singh wrote: > The feature is part of the GHCB version 2 and is enforced by the > hypervisor. I guess it can be extended for the ES. Since this feature > was not available in GHCB version 1 (base ES) so it should be presented > as an optional for the ES ? Yeah, it probably is not worth the effort. If an attacker controls the guest kernel, then it can re-register a new GHCB so it doesn't really matter. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
[PATCH] media: atomisp: Fix runtime PM imbalance in atomisp_pci_probe
When hmm_pool_register() fails, a pairing PM usage counter increment is needed to keep the counter balanced. It's the same for the following error paths. Signed-off-by: Dinghao Liu --- drivers/staging/media/atomisp/pci/atomisp_v4l2.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/media/atomisp/pci/atomisp_v4l2.c b/drivers/staging/media/atomisp/pci/atomisp_v4l2.c index 0295e2e32d79..02f774ed80c8 100644 --- a/drivers/staging/media/atomisp/pci/atomisp_v4l2.c +++ b/drivers/staging/media/atomisp/pci/atomisp_v4l2.c @@ -1815,6 +1815,7 @@ static int atomisp_pci_probe(struct pci_dev *pdev, const struct pci_device_id *i hmm_cleanup(); hmm_pool_unregister(HMM_POOL_TYPE_RESERVED); hmm_pool_fail: + pm_runtime_get_noresume(&pdev->dev); destroy_workqueue(isp->wdt_work_queue); wdt_work_queue_fail: atomisp_acc_cleanup(isp); -- 2.17.1
Re: [RFC PATCH 24/37] mm: implement speculative handling in __do_fault()
On Thu, Apr 08, 2021 at 08:13:43AM +0100, Matthew Wilcox wrote: > On Thu, Apr 08, 2021 at 09:00:26AM +0200, Peter Zijlstra wrote: > > On Wed, Apr 07, 2021 at 10:27:12PM +0100, Matthew Wilcox wrote: > > > Doing I/O without any lock held already works; it just uses the file > > > refcount. It would be better to use a vma refcount, as I already said. > > > > The original workload that I developed SPF for (wy back when) was > > prefaulting a single huge vma. Using a vma refcount was a total loss > > because it resulted in the same cacheline contention that down_read() > > was having. > > > > As such, I'm always incredibly sad to see mention of vma refcounts. > > They're fundamentally not solving the problem :/ > > OK, let me outline my locking scheme because I think it's rather better > than Michel's. The vma refcount is the slow path. > > 1. take the RCU read lock > 2. walk the pgd/p4d/pud/pmd > 3. allocate page tables if necessary. *handwave GFP flags*. The problem with allocating page-tables was that you can race with zap_page_range() if you're not holding mmap_sem, and as such can install a page-table after, in which case it leaks. IIRC that was solvable, but it did need a bit of care. > 4. walk the vma tree > 5. call ->map_pages I can't remember ->map_pages().. I think that's 'new'. git-blame tells me that's 2014, and I did the original SPF in 2010. Yes, that looks like a useful thing to have, it does the non-blocking part of ->fault(). I suppose the thing missing here is that if ->map_pages() does not return a page, we have: goto 9 > 6. take ptlock > 7. insert page(s) > 8. drop ptlock > if this all worked out, we're done, drop the RCU read lock and return. > 9. increment vma refcount > 10. drop RCU read lock > 11. call ->fault > 12. decrement vma refcount And here we do 6-8 again, right? > Compared to today, where we bump the refcount on the file underlying the > vma, this is _better_ scalability -- different mappings of the same file > will not contend on the file's refcount. > > I suspect your huge VMA was anon, and that wouldn't need a vma refcount > as faulting in new pages doesn't need to do I/O, just drop the RCU > lock, allocate and retry. IIRC yes, it was either a huge matrix setup or some database thing, I can't remember. But the thing was, we didn't have that ->map_pages(), so we had to call ->fault(), which can sleep, so I had to use SRCU across the whole thing (or rather, I hacked up preemptible-rcu, because SRCU was super primitive back then). It did kick start significant SRCU rework IIRC. Anyway, that's all ancient history.
Re: [RFC bpf-next 1/1] bpf: Introduce iter_pagecache
On Wed, Apr 07, 2021 at 02:46:11PM -0700, Daniel Xu wrote:
> This commit introduces the bpf page cache iterator. This iterator allows
> users to run a bpf prog against each page in the "page cache".
> Internally, the "page cache" is extremely tied to VFS superblock + inode
> combo. Because of this, iter_pagecache will only examine pages in the
> caller's mount namespace.
>
> Signed-off-by: Daniel Xu
> ---
> kernel/bpf/Makefile | 2 +-
> kernel/bpf/pagecache_iter.c | 293
> 2 files changed, 294 insertions(+), 1 deletion(-)
> create mode 100644 kernel/bpf/pagecache_iter.c
>
> diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile
> index 7f33098ca63f..3deb6a8d3f75 100644
> --- a/kernel/bpf/Makefile
> +++ b/kernel/bpf/Makefile
> @@ -6,7 +6,7 @@ cflags-nogcse-$(CONFIG_X86)$(CONFIG_CC_IS_GCC) := -fno-gcse
> endif
> CFLAGS_core.o += $(call cc-disable-warning, override-init)
> $(cflags-nogcse-yy)
>
> -obj-$(CONFIG_BPF_SYSCALL) += syscall.o verifier.o inode.o helpers.o tnum.o
> bpf_iter.o map_iter.o task_iter.o prog_iter.o
> +obj-$(CONFIG_BPF_SYSCALL) += syscall.o verifier.o inode.o helpers.o tnum.o
> bpf_iter.o pagecache_iter.o map_iter.o task_iter.o prog_iter.o
> obj-$(CONFIG_BPF_SYSCALL) += hashtab.o arraymap.o percpu_freelist.o
> bpf_lru_list.o lpm_trie.o map_in_map.o
> obj-$(CONFIG_BPF_SYSCALL) += local_storage.o queue_stack_maps.o ringbuf.o
> obj-$(CONFIG_BPF_SYSCALL) += bpf_local_storage.o bpf_task_storage.o
> diff --git a/kernel/bpf/pagecache_iter.c b/kernel/bpf/pagecache_iter.c
> new file mode 100644
> index ..8442ab0d4221
> --- /dev/null
> +++ b/kernel/bpf/pagecache_iter.c
> @@ -0,0 +1,293 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/* Copyright (c) 2021 Facebook */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "../../fs/mount.h"
This is a private header on purpose. Outside of fs/ poking around in
struct mount or struct mount_namespace should not be done.
> +
> +struct bpf_iter_seq_pagecache_info {
> + struct mnt_namespace *ns;
> + struct radix_tree_root superblocks;
> + struct super_block *cur_sb;
> + struct inode *cur_inode;
> + unsigned long cur_page_idx;
> +};
> +
> +static struct super_block *goto_next_sb(struct bpf_iter_seq_pagecache_info
> *info)
> +{
> + struct super_block *sb = NULL;
> + struct radix_tree_iter iter;
> + void **slot;
> +
> + radix_tree_for_each_slot(slot, &info->superblocks, &iter,
> + ((unsigned long)info->cur_sb + 1)) {
> + sb = (struct super_block *)iter.index;
> + break;
> + }
> +
> + info->cur_sb = sb;
> + info->cur_inode = NULL;
> + info->cur_page_idx = 0;
> + return sb;
> +}
> +
> +static bool inode_unusual(struct inode *inode) {
> + return ((inode->i_state & (I_FREEING|I_WILL_FREE|I_NEW)) ||
> + (inode->i_mapping->nrpages == 0));
> +}
> +
> +static struct inode *goto_next_inode(struct bpf_iter_seq_pagecache_info
> *info)
> +{
> + struct inode *prev_inode = info->cur_inode;
> + struct inode *inode;
> +
> +retry:
> + BUG_ON(!info->cur_sb);
> + spin_lock(&info->cur_sb->s_inode_list_lock);
> +
> + if (!info->cur_inode) {
> + list_for_each_entry(inode, &info->cur_sb->s_inodes, i_sb_list) {
> + spin_lock(&inode->i_lock);
> + if (inode_unusual(inode)) {
> + spin_unlock(&inode->i_lock);
> + continue;
> + }
> + __iget(inode);
> + spin_unlock(&inode->i_lock);
> + info->cur_inode = inode;
> + break;
> + }
> + } else {
> + inode = info->cur_inode;
> + info->cur_inode = NULL;
> + list_for_each_entry_continue(inode, &info->cur_sb->s_inodes,
> + i_sb_list) {
> + spin_lock(&inode->i_lock);
> + if (inode_unusual(inode)) {
> + spin_unlock(&inode->i_lock);
> + continue;
> + }
> + __iget(inode);
> + spin_unlock(&inode->i_lock);
> + info->cur_inode = inode;
> + break;
> + }
> + }
> +
> + /* Seen all inodes in this superblock */
> + if (!info->cur_inode) {
> + spin_unlock(&info->cur_sb->s_inode_list_lock);
> + if (!goto_next_sb(info)) {
> + inode = NULL;
> + goto out;
> + }
> +
> + goto retry;
> + }
> +
> + spin_unlock(&info->cur_sb->s_inode_list_lock);
> + info->cur_page_idx = 0;
> +out:
> + iput(prev_inode);
> + return info->cur_inode;
> +}
> +
> +static struct pa
[irqchip: irq/irqchip-next] irqchip/wpcm450: Drop COMPILE_TEST
The following commit has been merged into the irq/irqchip-next branch of irqchip: Commit-ID: 384cf046e474b40db4773e9358241a5de11ed8a7 Gitweb: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms/384cf046e474b40db4773e9358241a5de11ed8a7 Author:Marc Zyngier AuthorDate:Thu, 08 Apr 2021 08:56:27 +01:00 Committer: Marc Zyngier CommitterDate: Thu, 08 Apr 2021 08:56:27 +01:00 irqchip/wpcm450: Drop COMPILE_TEST This driver is (for now) ARM specific, and currently doesn't build with a variety of architectures (ia64, RISC-V, x86_64 at the very least). Drop COMPILE_TEST from Kconfig until it gets sorted out. Cc: Jonathan Neuschäfer Reported-by: Stephen Rothwell Signed-off-by: Marc Zyngier --- drivers/irqchip/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig index 38ad9dc..715eb43 100644 --- a/drivers/irqchip/Kconfig +++ b/drivers/irqchip/Kconfig @@ -579,7 +579,7 @@ config MST_IRQ config WPCM450_AIC bool "Nuvoton WPCM450 Advanced Interrupt Controller" - depends on ARCH_WPCM450 || COMPILE_TEST + depends on ARCH_WPCM450 help Support for the interrupt controller in the Nuvoton WPCM450 BMC SoC.
Re: [PATCH v6 3/8] regulator: IRQ based event/error notification helpers
Hello Andy, On Wed, 2021-04-07 at 16:21 +0300, Andy Shevchenko wrote: > On Wed, Apr 7, 2021 at 1:04 PM Matti Vaittinen > wrote: > > Provide helper function for IC's implementing regulator > > notifications > > when an IRQ fires. The helper also works for IRQs which can not be > > acked. > > Helper can be set to disable the IRQ at handler and then re- > > enabling it > > on delayed work later. The helper also adds > > regulator_get_error_flags() > > errors in cache for the duration of IRQ disabling. > > Thanks for an update, my comments below. After addressing them, feel > free to add > Reviewed-by: Andy Shevchenko I (eventually) disagreed with couple of points here and haven't changed those. Please see list below. I still do think you did a really good job reviewing this - and you should get the recognition from that work. Thus I'd nevertheless would like to add your Reviewed-by to the next version. Please let me know if you think it's ok. (I have the v7 ready but I'll wait until the next Monday before sending it to see if this brings more discussion). > > +/** > > + * devm_regulator_irq_helper - resource managed registration of > > IRQ based > > + * regulator event/error notifier > > + * > > + * @dev: device to which lifetime the helper's > > lifetime is > > + * bound. > > + * @d: IRQ helper descriptor. > > + * @irq: IRQ used to inform events/errors to be > > notified. > > + * @irq_flags: Extra IRQ flags to be OR's with the default > > IRQF_ONESHOT > > + * when requesting the (threaded) irq. > > + * @common_errs: Errors which can be flagged by this IRQ for > > all rdevs. > > + * When IRQ is re-enabled these errors will be > > cleared > > + * from all associated regulators > > + * @per_rdev_errs: Optional error flag array describing errors > > specific > > + * for only some of the regulators. These > > errors will be > > + * or'ed with common errors. If this is given > > the array > > + * should contain rdev_amount flags. Can be > > set to NULL > > + * if there is no regulator specific error > > flags for this > > + * IRQ. > > + * @rdev: Array of regulators associated with this > > IRQ. > > + * @rdev_amount: Amount of regulators associated wit this > > IRQ. > > Can you describe, please, the return value meaning. It will be good > also to move detailed descriptions (expectations?) of the fields to > the Description section, here. I added the return-value documentation as you suggested. For parameter descriptions I still think the best and clearest place is in parameter description. > > > + */ > > +void *devm_regulator_irq_helper(struct device *dev, > > + const struct regulator_irq_desc *d, > > int irq, > > + int irq_flags, int common_errs, > > + int *per_rdev_errs, > > + struct regulator_dev **rdev, int > > rdev_amount) > > I didn't get why you need the ** pointer instead of plain pointer. > This I replied to earlier - I did change the parameter documentation a bit to explain this: "@rdev: Array of pointers to regulators associated with this IRQ" > > +#include > > +#include > > +#include > > + Blank line? I would separate group of generic headers with > particular to the subsystem I haven't seen this practice in other parts of regulator subsystem (and I personally fail to see the value). > > +/** > > + * struct regulator_irq_data - regulator error/notification status > > date > > + * > > + * @states:Status structs for each of the associated > > regulators. > > + * @num_states:Amount of associated regulators. > > + * @data: Driver data pointer given at regulator_irq_desc. > > + * @opaque:Value storage for IC driver. Core does not update > > this. ICs > > + * may want to store status register value here at > > map_event and > > + * compare contents at renable to see if new problems > > have been > > re-enable / reenable > > > + * added to status. If that is the case it may be > > desirable to > > + * return REGULATOR_ERROR_CLEARED and not > > REGULATOR_ERROR_ON to > > + * allow IRQ fire again and to generate notifications > > also for > > + * the new issues. > > + * > > + * This structure is passed to map_event and renable for reporting > > regulator > > Ditto. 'renable' refers to the callback name. I tried to clarify that in comments though. "compare contents at 'renable' callback to see..." and "This structure is passed to 'map_event' and 'renable' callbacks for..." Best Regards Matti Vaittinen
Re: [PATCH v2 5/6] usb: typec: tcpm: Allow slow charging loops to comply to pSnkStby
> > @@ -4047,9 +4053,12 @@ static void run_state_machine(struct tcpm_port *port)
> > break;
> > case SNK_DISCOVERY:
> > if (port->vbus_present) {
> > - tcpm_set_current_limit(port,
> > - tcpm_get_current_limit(port),
> > - 5000);
> > + u32 current_lim = (!port->slow_charger_loop ||
> > + (tcpm_get_current_limit(port) <=
> > + PD_P_SNK_STDBY_MW / 5)) ?
> > + tcpm_get_current_limit(port) :
> > + PD_P_SNK_STDBY_MW / 5;
>
> Here the use of the ternary operator is not appropriate. Please try to
> clean that up somehow. Maybe something like this would be better?
>
> u32 current_lim = tcpm_get_current_limit(port);
>
> if (port->slow_charger_loop || (current_lim <
> PD_P_SNK_STDBY_MW / 5))
> current_lim = PD_P_SNK_STDBY_MW / 5;
Sorry, I mean:
if (port->slow_charger_loop || (current_lim >
PD_P_SNK_STDBY_MW / 5))
current_lim = PD_P_SNK_STDBY_MW / 5;
thanks,
--
heikki
Re: [PATCH -next] drm/bridge: lt8912b: DRM_LONTIUM_LT8912B select GPIOLIB
Hey Zhang, On Thu, 8 Apr 2021 at 09:10, zhangjianhua (E) wrote: > > Hello Robert > > I am sorry that I make a mistake about the compiling error of lt8912b, > > the reason is that lt8912b miss the header file . > > Although there are many files reference gpiod_set_value_cansleep() and > > devm_gpiod_get_optional(), they all include > > and not occur the compiling error like lt8912b. I have send the second > > version patch, please read. No worries at all, and good job finding the real issue. I'll have a look at the next version. Rob.
Re: [PATCH 05/16] media: cadence: csi2rx: Add external DPHY support
On 08/04/2021 11:13, Chunfeng Yun wrote:
On Wed, 2021-04-07 at 00:24 +0530, Pratyush Yadav wrote:
On 31/03/21 05:24PM, Chunfeng Yun wrote:
On Tue, 2021-03-30 at 23:03 +0530, Pratyush Yadav wrote:
Some platforms like TI's J721E can have the CSI2RX paired with an
external DPHY. Add support to enable and configure the DPHY using the
generic PHY framework.
Get the pixel rate and bpp from the subdev and pass them on to the DPHY
along with the number of lanes. All other settings are left to their
default values.
Signed-off-by: Pratyush Yadav
---
drivers/media/platform/cadence/cdns-csi2rx.c | 147 +--
1 file changed, 137 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c
b/drivers/media/platform/cadence/cdns-csi2rx.c
index c68a3eac62cd..31bd80e3f780 100644
--- a/drivers/media/platform/cadence/cdns-csi2rx.c
+++ b/drivers/media/platform/cadence/cdns-csi2rx.c
@@ -30,6 +30,12 @@
#define CSI2RX_STATIC_CFG_DLANE_MAP(llane, plane) ((plane) << (16 +
(llane) * 4))
#define CSI2RX_STATIC_CFG_LANES_MASK GENMASK(11, 8)
+#define CSI2RX_DPHY_LANE_CTRL_REG 0x40
+#define CSI2RX_DPHY_CL_RST BIT(16)
+#define CSI2RX_DPHY_DL_RST(i) BIT((i) + 12)
+#define CSI2RX_DPHY_CL_EN BIT(4)
+#define CSI2RX_DPHY_DL_EN(i) BIT(i)
+
#define CSI2RX_STREAM_BASE(n) (((n) + 1) * 0x100)
#define CSI2RX_STREAM_CTRL_REG(n) (CSI2RX_STREAM_BASE(n) + 0x000)
@@ -54,6 +60,11 @@ enum csi2rx_pads {
CSI2RX_PAD_MAX,
};
+struct csi2rx_fmt {
+ u32 code;
+ u8 bpp;
+};
+
struct csi2rx_priv {
struct device *dev;
unsigned intcount;
@@ -85,6 +96,52 @@ struct csi2rx_priv {
int source_pad;
};
+static const struct csi2rx_fmt formats[] = {
+ {
+ .code = MEDIA_BUS_FMT_YUYV8_2X8,
+ .bpp= 16,
+ },
+ {
+ .code = MEDIA_BUS_FMT_UYVY8_2X8,
+ .bpp= 16,
+ },
+ {
+ .code = MEDIA_BUS_FMT_YVYU8_2X8,
+ .bpp= 16,
+ },
+ {
+ .code = MEDIA_BUS_FMT_VYUY8_2X8,
+ .bpp= 16,
+ },
+};
+
+static u8 csi2rx_get_bpp(u32 code)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(formats); i++) {
+ if (formats[i].code == code)
+ return formats[i].bpp;
+ }
+
+ return 0;
+}
+
+static s64 csi2rx_get_pixel_rate(struct csi2rx_priv *csi2rx)
+{
+ struct v4l2_ctrl *ctrl;
+
+ ctrl = v4l2_ctrl_find(csi2rx->source_subdev->ctrl_handler,
+ V4L2_CID_PIXEL_RATE);
+ if (!ctrl) {
+ dev_err(csi2rx->dev, "no pixel rate control in subdev: %s\n",
+ csi2rx->source_subdev->name);
+ return -EINVAL;
+ }
+
+ return v4l2_ctrl_g_ctrl_int64(ctrl);
+}
+
static inline
struct csi2rx_priv *v4l2_subdev_to_csi2rx(struct v4l2_subdev *subdev)
{
@@ -101,6 +158,55 @@ static void csi2rx_reset(struct csi2rx_priv *csi2rx)
writel(0, csi2rx->base + CSI2RX_SOFT_RESET_REG);
}
+static int csi2rx_configure_external_dphy(struct csi2rx_priv *csi2rx)
+{
+ union phy_configure_opts opts = { };
+ struct phy_configure_opts_mipi_dphy *cfg = &opts.mipi_dphy;
+ struct v4l2_subdev_format sd_fmt;
+ s64 pixel_rate;
+ int ret;
+ u8 bpp;
+
+ sd_fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+ sd_fmt.pad = 0;
+
+ ret = v4l2_subdev_call(csi2rx->source_subdev, pad, get_fmt, NULL,
+ &sd_fmt);
+ if (ret)
+ return ret;
+
+ bpp = csi2rx_get_bpp(sd_fmt.format.code);
+ if (!bpp)
+ return -EINVAL;
+
+ pixel_rate = csi2rx_get_pixel_rate(csi2rx);
+ if (pixel_rate < 0)
+ return pixel_rate;
+
+ ret = phy_mipi_dphy_get_default_config(pixel_rate, bpp,
+ csi2rx->num_lanes, cfg);
+ if (ret)
+ return ret;
+
+ ret = phy_set_mode_ext(csi2rx->dphy, PHY_MODE_MIPI_DPHY,
+ PHY_MIPI_DPHY_SUBMODE_RX);
+ if (ret)
+ return ret;
+
+ ret = phy_power_on(csi2rx->dphy);
+ if (ret)
+ return ret;
Seems phy_power_on, then phy_set_mode_ext?
Shouldn't the mode be set before the PHY is powered on so the correct
power on procedure can be performed based on the mode of operation?
Of course, it is fine for cnds-dphy.
But it depends on HW design and also phy driver;
if the mode is controlled in PHY IP register, we can't access it before
phy_power_on if no phy_init called (e.g. clock/power is not enabled).
Just let you pay attention on the phy sequence.
I don't think the phy configuration s
[PATCH] staging: rtl8712: added spaces around '+'
Clean up Check:spaces preferred around that '+' (ctx:VxV)
Reported by checkpatch
Signed-off-by: Mitali Borkar
---
drivers/staging/rtl8712/wlan_bssdef.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8712/wlan_bssdef.h
b/drivers/staging/rtl8712/wlan_bssdef.h
index b54ccaacc527..ec3749813728 100644
--- a/drivers/staging/rtl8712/wlan_bssdef.h
+++ b/drivers/staging/rtl8712/wlan_bssdef.h
@@ -176,7 +176,7 @@ struct NDIS_802_11_WEP {
#define MIC_CHECK_TIME 6000
#ifndef Ndis802_11APMode
-#define Ndis802_11APMode (Ndis802_11InfrastructureMax+1)
+#define Ndis802_11APMode (Ndis802_11InfrastructureMax + 1)
#endif
struct wlan_network {
--
2.30.2
[RFC PATCH] vdpa: mandate 1.0 device
This patch mandates 1.0 for vDPA devices. The goal is to have the
semantic of normative statement in the virtio spec and eliminate the
burden of transitional device for both vDPA bus and vDPA parent.
uAPI seems fine since all the vDPA parent mandates
VIRTIO_F_ACCESS_PLATFORM which implies 1.0 devices.
For legacy guests, it can still work since Qemu will mediate when
necessary (e.g doing the endian conversion).
Signed-off-by: Jason Wang
---
include/linux/vdpa.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
index 0fefeb976877..cfde4ec999b4 100644
--- a/include/linux/vdpa.h
+++ b/include/linux/vdpa.h
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
/**
* vDPA callback definition.
@@ -317,6 +318,11 @@ static inline int vdpa_set_features(struct vdpa_device
*vdev, u64 features)
{
const struct vdpa_config_ops *ops = vdev->config;
+/* Mandating 1.0 to have semantics of normative statements in
+ * the spec. */
+if (!(features & BIT_ULL(VIRTIO_F_VERSION_1)))
+ return -EINVAL;
+
vdev->features_valid = true;
return ops->set_features(vdev, features);
}
--
2.25.1
Re: [PATCH 1/1] usb: typec: tcpm: remove unused static variable 'tcpm_altmode_ops'
On Wed, Apr 07, 2021 at 05:15:40PM +0800, Zhen Lei wrote:
> Fixes the following W=1 kernel build warning:
>
> drivers/usb/typec/tcpm/tcpm.c:2107:39: warning: ‘tcpm_altmode_ops’ defined
> but not used [-Wunused-const-variable=]
>
> The reference to the variable 'tcpm_altmode_ops' is deleted by the
> commit a079973f462a ("usb: typec: tcpm: Remove tcpc_config configuration
> mechanism").
>
> By the way, the static functions referenced only by the variable
> 'tcpm_altmode_ops' are deleted accordingly.
>
> Reported-by: Hulk Robot
> Signed-off-by: Zhen Lei
Oh, I thought this was already fixed. Should this go into the stable
trees as well?
Acked-by: Heikki Krogerus
> ---
> drivers/usb/typec/tcpm/tcpm.c | 60
> ---
> 1 file changed, 60 deletions(-)
>
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index ce7af398c7c1c1f..2f89bae29c0c297 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -1365,14 +1365,6 @@ static void tcpm_queue_vdm(struct tcpm_port *port,
> const u32 header,
> mod_vdm_delayed_work(port, 0);
> }
>
> -static void tcpm_queue_vdm_unlocked(struct tcpm_port *port, const u32 header,
> - const u32 *data, int cnt)
> -{
> - mutex_lock(&port->lock);
> - tcpm_queue_vdm(port, header, data, cnt);
> - mutex_unlock(&port->lock);
> -}
> -
> static void svdm_consume_identity(struct tcpm_port *port, const u32 *p, int
> cnt)
> {
> u32 vdo = p[VDO_INDEX_IDH];
> @@ -1705,8 +1697,6 @@ static void tcpm_handle_vdm_request(struct tcpm_port
> *port,
>*
>* And we also have this ordering:
>* 1. alt-mode driver takes the alt-mode's lock
> - * 2. alt-mode driver calls tcpm_altmode_enter which takes the
> - *tcpm port lock
>*
>* Dropping our lock here avoids this.
>*/
> @@ -2060,56 +2050,6 @@ static int tcpm_validate_caps(struct tcpm_port *port,
> const u32 *pdo,
> return 0;
> }
>
> -static int tcpm_altmode_enter(struct typec_altmode *altmode, u32 *vdo)
> -{
> - struct tcpm_port *port = typec_altmode_get_drvdata(altmode);
> - int svdm_version;
> - u32 header;
> -
> - svdm_version = typec_get_negotiated_svdm_version(port->typec_port);
> - if (svdm_version < 0)
> - return svdm_version;
> -
> - header = VDO(altmode->svid, vdo ? 2 : 1, svdm_version, CMD_ENTER_MODE);
> - header |= VDO_OPOS(altmode->mode);
> -
> - tcpm_queue_vdm_unlocked(port, header, vdo, vdo ? 1 : 0);
> - return 0;
> -}
> -
> -static int tcpm_altmode_exit(struct typec_altmode *altmode)
> -{
> - struct tcpm_port *port = typec_altmode_get_drvdata(altmode);
> - int svdm_version;
> - u32 header;
> -
> - svdm_version = typec_get_negotiated_svdm_version(port->typec_port);
> - if (svdm_version < 0)
> - return svdm_version;
> -
> - header = VDO(altmode->svid, 1, svdm_version, CMD_EXIT_MODE);
> - header |= VDO_OPOS(altmode->mode);
> -
> - tcpm_queue_vdm_unlocked(port, header, NULL, 0);
> - return 0;
> -}
> -
> -static int tcpm_altmode_vdm(struct typec_altmode *altmode,
> - u32 header, const u32 *data, int count)
> -{
> - struct tcpm_port *port = typec_altmode_get_drvdata(altmode);
> -
> - tcpm_queue_vdm_unlocked(port, header, data, count - 1);
> -
> - return 0;
> -}
> -
> -static const struct typec_altmode_ops tcpm_altmode_ops = {
> - .enter = tcpm_altmode_enter,
> - .exit = tcpm_altmode_exit,
> - .vdm = tcpm_altmode_vdm,
> -};
> -
> /*
> * PD (data, control) command handling functions
> */
> --
> 1.8.3
>
--
heikki
Re: [Outreachy kernel] [PATCH] staging: rtl8712: added spaces around '+'
The subject line should be in the imperative, so "add" instead of "added".
On Thu, 8 Apr 2021, Mitali Borkar wrote:
> Clean up Check:spaces preferred around that '+' (ctx:VxV)
> Reported by checkpatch
Please try to rephrase to explain what you did and why. "Clean up" kind
of states what the goal is, but your opinion about what is a clean up
might be different than someone else's. It's also not necessary to cite
the checkpatch warning exactly.
julia
>
> Signed-off-by: Mitali Borkar
> ---
> drivers/staging/rtl8712/wlan_bssdef.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/rtl8712/wlan_bssdef.h
> b/drivers/staging/rtl8712/wlan_bssdef.h
> index b54ccaacc527..ec3749813728 100644
> --- a/drivers/staging/rtl8712/wlan_bssdef.h
> +++ b/drivers/staging/rtl8712/wlan_bssdef.h
> @@ -176,7 +176,7 @@ struct NDIS_802_11_WEP {
> #define MIC_CHECK_TIME 6000
>
> #ifndef Ndis802_11APMode
> -#define Ndis802_11APMode (Ndis802_11InfrastructureMax+1)
> +#define Ndis802_11APMode (Ndis802_11InfrastructureMax + 1)
> #endif
>
> struct wlan_network {
> --
> 2.30.2
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/YG690ZIRdCEcjoM6%40kali.
>
Re: [PATCH -next v2] drm/bridge: lt8912b: Add header file
Hey Zhang, On Thu, 8 Apr 2021 at 05:54, Zhang Jianhua wrote: > > If CONFIG_DRM_LONTIUM_LT8912B=m, the following errors will be seen while > compiling lontium-lt8912b.c > > drivers/gpu/drm/bridge/lontium-lt8912b.c: In function > ‘lt8912_hard_power_on’: > drivers/gpu/drm/bridge/lontium-lt8912b.c:252:2: error: implicit > declaration of function ‘gpiod_set_value_cansleep’; did you mean > ‘gpio_set_value_cansleep’? [-Werror=implicit-function-declaration] > gpiod_set_value_cansleep(lt->gp_reset, 0); > ^~~~ > gpio_set_value_cansleep > drivers/gpu/drm/bridge/lontium-lt8912b.c: In function ‘lt8912_parse_dt’: > drivers/gpu/drm/bridge/lontium-lt8912b.c:628:13: error: implicit > declaration of function ‘devm_gpiod_get_optional’; did you mean > ‘devm_gpio_request_one’? [-Werror=implicit-function-declaration] > gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); > ^~~ > devm_gpio_request_one > drivers/gpu/drm/bridge/lontium-lt8912b.c:628:51: error: ‘GPIOD_OUT_HIGH’ > undeclared (first use in this function); did you mean ‘GPIOF_INIT_HIGH’? > gp_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); >^~ >GPIOF_INIT_HIGH > > Signed-off-by: Zhang Jianhua > --- > v2: > - add header file for lontium-lt8912b.c instead > of add config dependence for CONFIG_DRM_LONTIUM_LT8912B > --- > drivers/gpu/drm/bridge/lontium-lt8912b.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c > b/drivers/gpu/drm/bridge/lontium-lt8912b.c > index 61491615bad0..79845b3b19e1 100644 > --- a/drivers/gpu/drm/bridge/lontium-lt8912b.c > +++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c > @@ -3,6 +3,7 @@ > * Copyright (c) 2018, The Linux Foundation. All rights reserved. > */ > > +#include > #include > #include > #include Add this #include in alphabetical order. With this change, feel free to add my r-b. Reviewed-by: Robert Foss > -- > 2.17.1 >
[PATCH] cifs: Remove useless variable
Fix the following gcc warning: fs/cifs/cifsacl.c:1097:8: warning: variable ‘nmode’ set but not used [-Wunused-but-set-variable]. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- fs/cifs/cifsacl.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/cifs/cifsacl.c b/fs/cifs/cifsacl.c index d178cf8..fdb258a 100644 --- a/fs/cifs/cifsacl.c +++ b/fs/cifs/cifsacl.c @@ -1094,11 +1094,9 @@ static int set_chmod_dacl(struct cifs_acl *pdacl, struct cifs_acl *pndacl, struct cifs_ace *pnntace = NULL; char *nacl_base = NULL; u32 num_aces = 0; - __u64 nmode; bool new_aces_set = false; /* Assuming that pndacl and pnmode are never NULL */ - nmode = *pnmode; nacl_base = (char *)pndacl; nsize = sizeof(struct cifs_acl); -- 1.8.3.1
[PATCH] drm/panel: tpo-td043mtea1: convert sysfs snprintf to sysfs_emit
From: Xuezhi Zhang
Fix the following coccicheck warning:
drivers/gpu/drm//panel/panel-tpo-td043mtea1.c:217:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm//panel/panel-tpo-td043mtea1.c:189:8-16:
WARNING: use scnprintf or sprintf
Signed-off-by: Xuezhi Zhang
---
drivers/gpu/drm/panel/panel-tpo-td043mtea1.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-tpo-td043mtea1.c
b/drivers/gpu/drm/panel/panel-tpo-td043mtea1.c
index 49e6c9386258..bacaf1b7fb70 100644
--- a/drivers/gpu/drm/panel/panel-tpo-td043mtea1.c
+++ b/drivers/gpu/drm/panel/panel-tpo-td043mtea1.c
@@ -186,7 +186,7 @@ static ssize_t vmirror_show(struct device *dev, struct
device_attribute *attr,
{
struct td043mtea1_panel *lcd = dev_get_drvdata(dev);
- return snprintf(buf, PAGE_SIZE, "%d\n", lcd->vmirror);
+ return sysfs_emit(buf, "%d\n", lcd->vmirror);
}
static ssize_t vmirror_store(struct device *dev, struct device_attribute *attr,
@@ -214,7 +214,7 @@ static ssize_t mode_show(struct device *dev, struct
device_attribute *attr,
{
struct td043mtea1_panel *lcd = dev_get_drvdata(dev);
- return snprintf(buf, PAGE_SIZE, "%d\n", lcd->mode);
+ return sysfs_emit(buf, "%d\n", lcd->mode);
}
static ssize_t mode_store(struct device *dev, struct device_attribute *attr,
--
2.25.1
[PATCH] staging: rtl8712: remove unused variable from rtl871x_mlme.c
Remove unused variable from rtl871x_mlme.c.
No side effects can be seen locally or in r8712_find_network()
Signed-off-by: Sergei Krainov
---
drivers/staging/rtl8712/rtl871x_mlme.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_mlme.c
b/drivers/staging/rtl8712/rtl871x_mlme.c
index 8a97307fbbd6..4f41e321ea63 100644
--- a/drivers/staging/rtl8712/rtl871x_mlme.c
+++ b/drivers/staging/rtl8712/rtl871x_mlme.c
@@ -656,7 +656,7 @@ void r8712_joinbss_event_callback(struct _adapter *adapter,
u8 *pbuf)
struct sta_priv *pstapriv = &adapter->stapriv;
struct mlme_priv*pmlmepriv = &adapter->mlmepriv;
struct wlan_network *cur_network = &pmlmepriv->cur_network;
- struct wlan_network *pcur_wlan = NULL, *ptarget_wlan = NULL;
+ struct wlan_network *ptarget_wlan = NULL;
unsigned intthe_same_macaddr = false;
struct wlan_network *pnetwork;
@@ -721,13 +721,6 @@ void r8712_joinbss_event_callback(struct _adapter
*adapter, u8 *pbuf)
scanned_queue,
cur_network->network.MacAddress);
} else {
- pcur_wlan =
-r8712_find_network(&pmlmepriv->
-scanned_queue,
-cur_network->network.MacAddress);
- if (pcur_wlan)
- pcur_wlan->fixed = false;
-
pcur_sta = r8712_get_stainfo(pstapriv,
cur_network->network.MacAddress);
spin_lock_irqsave(&pstapriv->
--
2.25.1
Re: [next] [arm64] [gpio] BUG: key has not been registered! DEBUG_LOCKS_WARN_ON:
On Thu, 8 Apr 2021 at 04:21, Andy Shevchenko wrote: > > On Thu, Apr 8, 2021 at 12:38 AM Naresh Kamboju > wrote: > > > > While running kselftest recently added gpio gpio-sim.sh test case the > > following > > warning was triggered on Linux next tag 20210330 tag running on arm64 juno > > and hikey devices. > > > > GOOD: next-20210326 > > BAD: next-20210330 > > > > This is still happening today on Linux next tag 20210407. > > Can you add the following > > sysfs_attr_init(attrs[i]); > > to the end of the loop in gpio_sim_setup_sysfs()? Do you mean like this, diff --git a/drivers/gpio/gpio-sim.c b/drivers/gpio/gpio-sim.c index ea17289a869c..5fe67ccf45f7 100644 --- a/drivers/gpio/gpio-sim.c +++ b/drivers/gpio/gpio-sim.c @@ -296,6 +296,7 @@ static int gpio_sim_setup_sysfs(struct gpio_sim_chip *chip) dev_attr->store = gpio_sim_sysfs_line_store; attrs[i] = &dev_attr->attr; + sysfs_attr_init(attrs[i]); } chip->attr_group.name = "line-ctrl"; > > If it fixes an issue I'll send a formal patch. I will build and test this and report here. - Naresh
Re: [PATCH 02/10] mm/numa: automatically generate node migration order
On Thu, Apr 01, 2021 at 11:32:19AM -0700, Dave Hansen wrote:
>
> From: Dave Hansen
>
> When memory fills up on a node, memory contents can be
> automatically migrated to another node. The biggest problems are
> knowing when to migrate and to where the migration should be
> targeted.
>
> The most straightforward way to generate the "to where" list would
> be to follow the page allocator fallback lists. Those lists
> already tell us if memory is full where to look next. It would
> also be logical to move memory in that order.
>
> But, the allocator fallback lists have a fatal flaw: most nodes
> appear in all the lists. This would potentially lead to migration
> cycles (A->B, B->A, A->B, ...).
>
> Instead of using the allocator fallback lists directly, keep a
> separate node migration ordering. But, reuse the same data used
> to generate page allocator fallback in the first place:
> find_next_best_node().
>
> This means that the firmware data used to populate node distances
> essentially dictates the ordering for now. It should also be
> architecture-neutral since all NUMA architectures have a working
> find_next_best_node().
>
> The protocol for node_demotion[] access and writing is not
> standard. It has no specific locking and is intended to be read
> locklessly. Readers must take care to avoid observing changes
> that appear incoherent. This was done so that node_demotion[]
It might be just me being dense here, but that reads odd.
"Readers must take care to avoid observing changes that appear
incoherent" - I am not sure what is that supposed to mean.
I guess you mean readers of next_demotion_node()?
And if so, how do they have to take care? And what would apply for
"incoherent" terminology here?
> locking has no chance of becoming a bottleneck on large systems
> with lots of CPUs in direct reclaim.
>
> This code is unused for now. It will be called later in the
> series.
>
> Signed-off-by: Dave Hansen
> Reviewed-by: Yang Shi
> Cc: Wei Xu
> Cc: David Rientjes
> Cc: Huang Ying
> Cc: Dan Williams
> Cc: David Hildenbrand
> Cc: osalvador
...
> +static void __set_migration_target_nodes(void)
> +{
> + nodemask_t next_pass= NODE_MASK_NONE;
> + nodemask_t this_pass= NODE_MASK_NONE;
> + nodemask_t used_targets = NODE_MASK_NONE;
> + int node;
> +
> + /*
> + * Avoid any oddities like cycles that could occur
> + * from changes in the topology. This will leave
> + * a momentary gap when migration is disabled.
> + */
> + disable_all_migrate_targets();
> +
> + /*
> + * Ensure that the "disable" is visible across the system.
> + * Readers will see either a combination of before+disable
> + * state or disable+after. They will never see before and
> + * after state together.
> + *
> + * The before+after state together might have cycles and
> + * could cause readers to do things like loop until this
> + * function finishes. This ensures they can only see a
> + * single "bad" read and would, for instance, only loop
> + * once.
> + */
> + smp_wmb();
> +
> + /*
> + * Allocations go close to CPUs, first. Assume that
> + * the migration path starts at the nodes with CPUs.
> + */
> + next_pass = node_states[N_CPU];
> +again:
> + this_pass = next_pass;
> + next_pass = NODE_MASK_NONE;
> + /*
> + * To avoid cycles in the migration "graph", ensure
> + * that migration sources are not future targets by
> + * setting them in 'used_targets'. Do this only
> + * once per pass so that multiple source nodes can
> + * share a target node.
> + *
> + * 'used_targets' will become unavailable in future
> + * passes. This limits some opportunities for
> + * multiple source nodes to share a destination.
> + */
> + nodes_or(used_targets, used_targets, this_pass);
> + for_each_node_mask(node, this_pass) {
> + int target_node = establish_migrate_target(node, &used_targets);
> +
> + if (target_node == NUMA_NO_NODE)
> + continue;
> +
> + /* Visit targets from this pass in the next pass: */
> + node_set(target_node, next_pass);
> + }
> + /* Is another pass necessary? */
> + if (!nodes_empty(next_pass))
When I read this I was about puzzled and it took me a while to figure
out how the passes were made.
I think this could benefit from a better explanation on how the passes
are being performed e.g: why next_pass should be empty before leaving.
Other than that looks good to me.
--
Oscar Salvador
SUSE L3
Re: linux-next: build failure after merge of the irqchip tree
On Thu, Apr 08, 2021 at 08:56:18AM +0100, Marc Zyngier wrote:
> Hi Stephen,
>
> On 2021-04-08 07:35, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the irqchip tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/irqchip/irq-wpcm450-aic.c:9:10: fatal error: asm/exception.h:
> > No such file or directory
> > 9 | #include
> > | ^
> >
> > Caused by commit
> >
> > fead4dd49663 ("irqchip: Add driver for WPCM450 interrupt controller")
> >
> > I have used the irqchip tree from next-20210407 for today.
>
> Thanks for the heads up. I guess that's the effect of COMPILE_TEST
> which was apparently not very well tested... I'll drop it from Kconfig.
Right, sorry about that.
> Jonathan, feel free to submit something re-enabling COMPILE_TEST once
> you've worked out the missing dependencies.
I used __exception_irq_entry from asm/exception.h, like other irqchip
drivers for ARM. This macro is only defined in arch/arm and arch/arm64.
So, AFAICS, there is no right set of dependencies for COMPILE_TEST.
Jonathan
signature.asc
Description: PGP signature
Re: [PATCH 1/2] zram: fix crashes due to use of cpu hotplug multistate
On Thu, 8 Apr 2021, Greg KH wrote: > > If there is a driver/subsystem code that can't handle the reverse > > operation to modprobe, it clearly can't handle error handling during > > modprobe (which, one would hope, is supported), and should be fixed. > > Huh? No, that's not the issue here, it's the issue of different > userspace code paths into the module at the same time that it is trying > to be unloaded. That has nothing to do with loading the module the > first time as userspace is not touching those apis yet. So do you claim that once the first (out of possibly many) userspace-visible sysfs entry has been created during module insertion and made available to userspace, there is never going to be rollback happening that'd be removing that first sysfs entry again? Thanks, -- Jiri Kosina SUSE Labs
