[PATCH AUTOSEL 5.9 052/111] rtw88: increse the size of rx buffer size
From: Tzu-En Huang [ Upstream commit ee755732b7a16af018daa77d9562d2493fb7092f ] The vht capability of MAX_MPDU_LENGTH is 11454 in rtw88; however, the rx buffer size for each packet is 8192. When receiving packets that are larger than rx buffer size, it will leads to rx buffer ring overflow. Signed-off-by: Tzu-En Huang Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200925061219.23754-2-tehu...@realtek.com Signed-off-by: Sasha Levin --- drivers/net/wireless/realtek/rtw88/pci.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/realtek/rtw88/pci.h b/drivers/net/wireless/realtek/rtw88/pci.h index 024c2bc275cbe..ca17aa9cf7dc7 100644 --- a/drivers/net/wireless/realtek/rtw88/pci.h +++ b/drivers/net/wireless/realtek/rtw88/pci.h @@ -9,8 +9,8 @@ #define RTK_BEQ_TX_DESC_NUM256 #define RTK_MAX_RX_DESC_NUM512 -/* 8K + rx desc size */ -#define RTK_PCI_RX_BUF_SIZE(8192 + 24) +/* 11K + rx desc size */ +#define RTK_PCI_RX_BUF_SIZE(11454 + 24) #define RTK_PCI_CTRL 0x300 #define BIT_RST_TRXDMA_INTFBIT(20) -- 2.25.1
[PATCH AUTOSEL 5.9 070/111] usb: ohci: Default to per-port over-current protection
From: Hamish Martin
[ Upstream commit b77d2a0a223bc139ee8904991b2922d215d02636 ]
Some integrated OHCI controller hubs do not expose all ports of the hub
to pins on the SoC. In some cases the unconnected ports generate
spurious over-current events. For example the Broadcom 56060/Ranger 2 SoC
contains a nominally 3 port hub but only the first port is wired.
Default behaviour for ohci-platform driver is to use global over-current
protection mode (AKA "ganged"). This leads to the spurious over-current
events affecting all ports in the hub.
We now alter the default to use per-port over-current protection.
This patch results in the following configuration changes depending
on quirks:
- For quirk OHCI_QUIRK_SUPERIO no changes. These systems remain set up
for ganged power switching and no over-current protection.
- For quirk OHCI_QUIRK_AMD756 or OHCI_QUIRK_HUB_POWER power switching
remains at none, while over-current protection is now guaranteed to be
set to per-port rather than the previous behaviour where it was either
none or global over-current protection depending on the value at
function entry.
Suggested-by: Alan Stern
Acked-by: Alan Stern
Signed-off-by: Hamish Martin
Link:
https://lore.kernel.org/r/20200910212512.16670-1-hamish.mar...@alliedtelesis.co.nz
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/usb/host/ohci-hcd.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index dd37e77dae001..2845ea328a064 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -673,20 +673,24 @@ static int ohci_run (struct ohci_hcd *ohci)
/* handle root hub init quirks ... */
val = roothub_a (ohci);
- val &= ~(RH_A_PSM | RH_A_OCPM);
+ /* Configure for per-port over-current protection by default */
+ val &= ~RH_A_NOCP;
+ val |= RH_A_OCPM;
if (ohci->flags & OHCI_QUIRK_SUPERIO) {
- /* NSC 87560 and maybe others */
+ /* NSC 87560 and maybe others.
+* Ganged power switching, no over-current protection.
+*/
val |= RH_A_NOCP;
- val &= ~(RH_A_POTPGT | RH_A_NPS);
- ohci_writel (ohci, val, >regs->roothub.a);
+ val &= ~(RH_A_POTPGT | RH_A_NPS | RH_A_PSM | RH_A_OCPM);
} else if ((ohci->flags & OHCI_QUIRK_AMD756) ||
(ohci->flags & OHCI_QUIRK_HUB_POWER)) {
/* hub power always on; required for AMD-756 and some
-* Mac platforms. ganged overcurrent reporting, if any.
+* Mac platforms.
*/
val |= RH_A_NPS;
- ohci_writel (ohci, val, >regs->roothub.a);
}
+ ohci_writel(ohci, val, >regs->roothub.a);
+
ohci_writel (ohci, RH_HS_LPSC, >regs->roothub.status);
ohci_writel (ohci, (val & RH_A_NPS) ? 0 : RH_B_PPCM,
>regs->roothub.b);
--
2.25.1
[PATCH AUTOSEL 5.9 068/111] opp: Prevent memory leak in dev_pm_opp_attach_genpd()
From: Viresh Kumar
[ Upstream commit cb60e9602cce1593eb1e9cdc8ee562815078a354 ]
If dev_pm_opp_attach_genpd() is called multiple times (once for each CPU
sharing the table), then it would result in unwanted behavior like
memory leak, attaching the domain multiple times, etc.
Handle that by checking and returning earlier if the domains are already
attached. Now that dev_pm_opp_detach_genpd() can get called multiple
times as well, we need to protect that too.
Note that the virtual device pointers aren't returned in this case, as
they may become unavailable to some callers during the middle of the
operation.
Reported-by: Stephan Gerhold
Signed-off-by: Viresh Kumar
Signed-off-by: Sasha Levin
---
drivers/opp/core.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 3ca7543142bf3..1a95ad40795be 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1949,6 +1949,9 @@ static void _opp_detach_genpd(struct opp_table *opp_table)
{
int index;
+ if (!opp_table->genpd_virt_devs)
+ return;
+
for (index = 0; index < opp_table->required_opp_count; index++) {
if (!opp_table->genpd_virt_devs[index])
continue;
@@ -1995,6 +1998,9 @@ struct opp_table *dev_pm_opp_attach_genpd(struct device
*dev,
if (!opp_table)
return ERR_PTR(-ENOMEM);
+ if (opp_table->genpd_virt_devs)
+ return opp_table;
+
/*
* If the genpd's OPP table isn't already initialized, parsing of the
* required-opps fail for dev. We should retry this after genpd's OPP
--
2.25.1
[PATCH AUTOSEL 5.9 045/111] mic: vop: copy data to kernel space then write to io memory
From: Sherry Sun
[ Upstream commit 675f0ad4046946e80412896436164d172cd92238 ]
Read and write io memory should address align on ARCH ARM. Change to use
memcpy_toio to avoid kernel panic caused by the address un-align issue.
Signed-off-by: Sherry Sun
Signed-off-by: Joakim Zhang
Link: https://lore.kernel.org/r/20200929091106.24624-5-sherry@nxp.com
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/misc/mic/vop/vop_vringh.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/misc/mic/vop/vop_vringh.c
b/drivers/misc/mic/vop/vop_vringh.c
index 30eac172f0170..d069947b09345 100644
--- a/drivers/misc/mic/vop/vop_vringh.c
+++ b/drivers/misc/mic/vop/vop_vringh.c
@@ -602,6 +602,7 @@ static int vop_virtio_copy_from_user(struct vop_vdev *vdev,
void __user *ubuf,
size_t partlen;
bool dma = VOP_USE_DMA && vi->dma_ch;
int err = 0;
+ size_t offset = 0;
if (dma) {
dma_alignment = 1 << vi->dma_ch->device->copy_align;
@@ -655,13 +656,20 @@ static int vop_virtio_copy_from_user(struct vop_vdev
*vdev, void __user *ubuf,
* We are copying to IO below and should ideally use something
* like copy_from_user_toio(..) if it existed.
*/
- if (copy_from_user((void __force *)dbuf, ubuf, len)) {
- err = -EFAULT;
- dev_err(vop_dev(vdev), "%s %d err %d\n",
- __func__, __LINE__, err);
- goto err;
+ while (len) {
+ partlen = min_t(size_t, len, VOP_INT_DMA_BUF_SIZE);
+
+ if (copy_from_user(vvr->buf, ubuf + offset, partlen)) {
+ err = -EFAULT;
+ dev_err(vop_dev(vdev), "%s %d err %d\n",
+ __func__, __LINE__, err);
+ goto err;
+ }
+ memcpy_toio(dbuf + offset, vvr->buf, partlen);
+ offset += partlen;
+ vdev->out_bytes += partlen;
+ len -= partlen;
}
- vdev->out_bytes += len;
err = 0;
err:
vpdev->hw_ops->unmap(vpdev, dbuf);
--
2.25.1
[PATCH AUTOSEL 5.9 051/111] udf: Avoid accessing uninitialized data on failed inode read
From: Jan Kara
[ Upstream commit 044e2e26f214e5ab26af85faffd8d1e4ec066931 ]
When we fail to read inode, some data accessed in udf_evict_inode() may
be uninitialized. Move the accesses to !is_bad_inode() branch.
Reported-by: syzbot+91f02b28f9bb5f5f1...@syzkaller.appspotmail.com
Signed-off-by: Jan Kara
Signed-off-by: Sasha Levin
---
fs/udf/inode.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index adaba8e8b326e..566118417e562 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -139,21 +139,24 @@ void udf_evict_inode(struct inode *inode)
struct udf_inode_info *iinfo = UDF_I(inode);
int want_delete = 0;
- if (!inode->i_nlink && !is_bad_inode(inode)) {
- want_delete = 1;
- udf_setsize(inode, 0);
- udf_update_inode(inode, IS_SYNC(inode));
+ if (!is_bad_inode(inode)) {
+ if (!inode->i_nlink) {
+ want_delete = 1;
+ udf_setsize(inode, 0);
+ udf_update_inode(inode, IS_SYNC(inode));
+ }
+ if (iinfo->i_alloc_type != ICBTAG_FLAG_AD_IN_ICB &&
+ inode->i_size != iinfo->i_lenExtents) {
+ udf_warn(inode->i_sb,
+"Inode %lu (mode %o) has inode size %llu
different from extent length %llu. Filesystem need not be standards
compliant.\n",
+inode->i_ino, inode->i_mode,
+(unsigned long long)inode->i_size,
+(unsigned long long)iinfo->i_lenExtents);
+ }
}
truncate_inode_pages_final(>i_data);
invalidate_inode_buffers(inode);
clear_inode(inode);
- if (iinfo->i_alloc_type != ICBTAG_FLAG_AD_IN_ICB &&
- inode->i_size != iinfo->i_lenExtents) {
- udf_warn(inode->i_sb, "Inode %lu (mode %o) has inode size %llu
different from extent length %llu. Filesystem need not be standards
compliant.\n",
-inode->i_ino, inode->i_mode,
-(unsigned long long)inode->i_size,
-(unsigned long long)iinfo->i_lenExtents);
- }
kfree(iinfo->i_ext.i_data);
iinfo->i_ext.i_data = NULL;
udf_clear_extent_cache(inode);
--
2.25.1
[PATCH AUTOSEL 5.9 081/111] rtl8xxxu: prevent potential memory leak
From: Chris Chiu
[ Upstream commit 86279456a4d47782398d3cb8193f78f672e36cac ]
Free the skb if usb_submit_urb fails on rx_urb. And free the urb
no matter usb_submit_urb succeeds or not in rtl8xxxu_submit_int_urb.
Signed-off-by: Chris Chiu
Signed-off-by: Kalle Valo
Link: https://lore.kernel.org/r/20200906040424.22022-1-c...@endlessm.com
Signed-off-by: Sasha Levin
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 19efae462a242..5cd7ef3625c5e 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -5795,7 +5795,6 @@ static int rtl8xxxu_submit_int_urb(struct ieee80211_hw
*hw)
ret = usb_submit_urb(urb, GFP_KERNEL);
if (ret) {
usb_unanchor_urb(urb);
- usb_free_urb(urb);
goto error;
}
@@ -5804,6 +5803,7 @@ static int rtl8xxxu_submit_int_urb(struct ieee80211_hw
*hw)
rtl8xxxu_write32(priv, REG_USB_HIMR, val32);
error:
+ usb_free_urb(urb);
return ret;
}
@@ -6318,6 +6318,7 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
struct rtl8xxxu_priv *priv = hw->priv;
struct rtl8xxxu_rx_urb *rx_urb;
struct rtl8xxxu_tx_urb *tx_urb;
+ struct sk_buff *skb;
unsigned long flags;
int ret, i;
@@ -6368,6 +6369,13 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
rx_urb->hw = hw;
ret = rtl8xxxu_submit_rx_urb(priv, rx_urb);
+ if (ret) {
+ if (ret != -ENOMEM) {
+ skb = (struct sk_buff *)rx_urb->urb.context;
+ dev_kfree_skb(skb);
+ }
+ rtl8xxxu_queue_rx_urb(priv, rx_urb);
+ }
}
schedule_delayed_work(>ra_watchdog, 2 * HZ);
--
2.25.1
[PATCH AUTOSEL 5.9 080/111] brcmsmac: fix memory leak in wlc_phy_attach_lcnphy
From: Keita Suzuki
[ Upstream commit f4443293d741d1776b86ed1dd8c4e4285d0775fc ]
When wlc_phy_txpwr_srom_read_lcnphy fails in wlc_phy_attach_lcnphy,
the allocated pi->u.pi_lcnphy is leaked, since struct brcms_phy will be
freed in the caller function.
Fix this by calling wlc_phy_detach_lcnphy in the error handler of
wlc_phy_txpwr_srom_read_lcnphy before returning.
Signed-off-by: Keita Suzuki
Signed-off-by: Kalle Valo
Link:
https://lore.kernel.org/r/20200908121743.23108-1-keitasuzuki.p...@sslab.ics.keio.ac.jp
Signed-off-by: Sasha Levin
---
.../net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c| 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
index 7ef36234a25dc..66797dc5e90d5 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
@@ -5065,8 +5065,10 @@ bool wlc_phy_attach_lcnphy(struct brcms_phy *pi)
pi->pi_fptr.radioloftget = wlc_lcnphy_get_radio_loft;
pi->pi_fptr.detach = wlc_phy_detach_lcnphy;
- if (!wlc_phy_txpwr_srom_read_lcnphy(pi))
+ if (!wlc_phy_txpwr_srom_read_lcnphy(pi)) {
+ kfree(pi->u.pi_lcnphy);
return false;
+ }
if (LCNREV_IS(pi->pubpi.phy_rev, 1)) {
if (pi_lcn->lcnphy_tempsense_option == 3) {
--
2.25.1
[PATCH AUTOSEL 5.9 043/111] scsi: mvumi: Fix error return in mvumi_io_attach()
From: Jing Xiangfeng
[ Upstream commit 055f15ab2cb4a5cbc4c0a775ef3d0066e0fa9b34 ]
Return PTR_ERR() from the error handling case instead of 0.
Link: https://lore.kernel.org/r/20200910123848.93649-1-jingxiangf...@huawei.com
Signed-off-by: Jing Xiangfeng
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
---
drivers/scsi/mvumi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/mvumi.c b/drivers/scsi/mvumi.c
index 8906aceda4c43..0354898d7cac1 100644
--- a/drivers/scsi/mvumi.c
+++ b/drivers/scsi/mvumi.c
@@ -2425,6 +2425,7 @@ static int mvumi_io_attach(struct mvumi_hba *mhba)
if (IS_ERR(mhba->dm_thread)) {
dev_err(>pdev->dev,
"failed to create device scan thread\n");
+ ret = PTR_ERR(mhba->dm_thread);
mutex_unlock(>sas_discovery_mutex);
goto fail_create_thread;
}
--
2.25.1
[PATCH AUTOSEL 5.9 060/111] ath9k: hif_usb: fix race condition between usb_get_urb() and usb_kill_anchored_urbs()
From: Brooke Basile
[ Upstream commit 03fb92a432ea5abe5909bca1455b7e44a9380480 ]
Calls to usb_kill_anchored_urbs() after usb_kill_urb() on multiprocessor
systems create a race condition in which usb_kill_anchored_urbs() deallocates
the URB before the completer callback is called in usb_kill_urb(), resulting
in a use-after-free.
To fix this, add proper lock protection to usb_kill_urb() calls that can
possibly run concurrently with usb_kill_anchored_urbs().
Reported-by: syzbot+89bd486af9427a9fc...@syzkaller.appspotmail.com
Link:
https://syzkaller.appspot.com/bug?id=cabffad18eb74197f84871802fd2c5117b61febf
Signed-off-by: Brooke Basile
Signed-off-by: Kalle Valo
Link: https://lore.kernel.org/r/20200911071427.32354-1-brookebas...@gmail.com
Signed-off-by: Sasha Levin
---
drivers/net/wireless/ath/ath9k/hif_usb.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 3f563e02d17da..2ed98aaed6fb5 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -449,10 +449,19 @@ static void hif_usb_stop(void *hif_handle)
spin_unlock_irqrestore(_dev->tx.tx_lock, flags);
/* The pending URBs have to be canceled. */
+ spin_lock_irqsave(_dev->tx.tx_lock, flags);
list_for_each_entry_safe(tx_buf, tx_buf_tmp,
_dev->tx.tx_pending, list) {
+ usb_get_urb(tx_buf->urb);
+ spin_unlock_irqrestore(_dev->tx.tx_lock, flags);
usb_kill_urb(tx_buf->urb);
+ list_del(_buf->list);
+ usb_free_urb(tx_buf->urb);
+ kfree(tx_buf->buf);
+ kfree(tx_buf);
+ spin_lock_irqsave(_dev->tx.tx_lock, flags);
}
+ spin_unlock_irqrestore(_dev->tx.tx_lock, flags);
usb_kill_anchored_urbs(_dev->mgmt_submitted);
}
@@ -762,27 +771,37 @@ static void ath9k_hif_usb_dealloc_tx_urbs(struct
hif_device_usb *hif_dev)
struct tx_buf *tx_buf = NULL, *tx_buf_tmp = NULL;
unsigned long flags;
+ spin_lock_irqsave(_dev->tx.tx_lock, flags);
list_for_each_entry_safe(tx_buf, tx_buf_tmp,
_dev->tx.tx_buf, list) {
+ usb_get_urb(tx_buf->urb);
+ spin_unlock_irqrestore(_dev->tx.tx_lock, flags);
usb_kill_urb(tx_buf->urb);
list_del(_buf->list);
usb_free_urb(tx_buf->urb);
kfree(tx_buf->buf);
kfree(tx_buf);
+ spin_lock_irqsave(_dev->tx.tx_lock, flags);
}
+ spin_unlock_irqrestore(_dev->tx.tx_lock, flags);
spin_lock_irqsave(_dev->tx.tx_lock, flags);
hif_dev->tx.flags |= HIF_USB_TX_FLUSH;
spin_unlock_irqrestore(_dev->tx.tx_lock, flags);
+ spin_lock_irqsave(_dev->tx.tx_lock, flags);
list_for_each_entry_safe(tx_buf, tx_buf_tmp,
_dev->tx.tx_pending, list) {
+ usb_get_urb(tx_buf->urb);
+ spin_unlock_irqrestore(_dev->tx.tx_lock, flags);
usb_kill_urb(tx_buf->urb);
list_del(_buf->list);
usb_free_urb(tx_buf->urb);
kfree(tx_buf->buf);
kfree(tx_buf);
+ spin_lock_irqsave(_dev->tx.tx_lock, flags);
}
+ spin_unlock_irqrestore(_dev->tx.tx_lock, flags);
usb_kill_anchored_urbs(_dev->mgmt_submitted);
}
--
2.25.1
[PATCH AUTOSEL 5.9 027/111] mmc: sdio: Check for CISTPL_VERS_1 buffer size
From: Pali Rohár [ Upstream commit 8ebe2607965d3e2dc02029e8c7dd35fbe508ffd0 ] Before parsing CISTPL_VERS_1 structure check that its size is at least two bytes to prevent buffer overflow. Signed-off-by: Pali Rohár Link: https://lore.kernel.org/r/20200727133837.19086-2-p...@kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin --- drivers/mmc/core/sdio_cis.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mmc/core/sdio_cis.c b/drivers/mmc/core/sdio_cis.c index e0655278c5c32..3efaa9534a777 100644 --- a/drivers/mmc/core/sdio_cis.c +++ b/drivers/mmc/core/sdio_cis.c @@ -26,6 +26,9 @@ static int cistpl_vers_1(struct mmc_card *card, struct sdio_func *func, unsigned i, nr_strings; char **buffer, *string; + if (size < 2) + return 0; + /* Find all null-terminated (including zero length) strings in the TPLLV1_INFO field. Trailing garbage is ignored. */ buf += 2; -- 2.25.1
[PATCH AUTOSEL 5.9 073/111] drm/msm/a6xx: fix a potential overflow issue
From: Zhenzhong Duan [ Upstream commit 08d3ab4b46339bc6f97e83b54a3fb4f8bf8f4cd9 ] It's allocating an array of a6xx_gpu_state_obj structure rathor than its pointers. This patch fix it. Signed-off-by: Zhenzhong Duan Signed-off-by: Rob Clark Signed-off-by: Sasha Levin --- drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c index b12f5b4a1bea9..e9ede19193b0e 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c @@ -875,7 +875,7 @@ static void a6xx_get_indexed_registers(struct msm_gpu *gpu, int i; a6xx_state->indexed_regs = state_kcalloc(a6xx_state, count, - sizeof(a6xx_state->indexed_regs)); + sizeof(*a6xx_state->indexed_regs)); if (!a6xx_state->indexed_regs) return; -- 2.25.1
[PATCH AUTOSEL 5.9 056/111] usb: dwc3: simple: add support for Hikey 970
From: Mauro Carvalho Chehab
[ Upstream commit b68d9251561f33661e53dd618f1cafe7ec9ec3c2 ]
This binding driver is needed for Hikey 970 to work,
as otherwise a Serror is produced:
[1.837458] SError Interrupt on CPU0, code 0xbf02 -- SError
[1.837462] CPU: 0 PID: 74 Comm: kworker/0:1 Not tainted 5.8.0+ #205
[1.837463] Hardware name: HiKey970 (DT)
[1.837465] Workqueue: events deferred_probe_work_func
[1.837467] pstate: 2005 (nzCv daif -PAN -UAO BTYPE=--)
[1.837468] pc : _raw_spin_unlock_irqrestore+0x18/0x50
[1.837469] lr : regmap_unlock_spinlock+0x14/0x20
[1.837470] sp : 8000124dba60
[1.837471] x29: 8000124dba60 x28:
[1.837474] x27: 0001b7e854c8 x26: 80001204ea18
[1.837476] x25: 0005 x24: 800011f918f8
[1.837479] x23: 800011fbb588 x22: 0001b7e40e00
[1.837481] x21: 0100 x20:
[1.837483] x19: 0001b767ec00 x18: ff10c000
[1.837485] x17: 0002 x16: b0740fdb9950
[1.837488] x15: 8000116c1198 x14:
[1.837490] x13: 0030 x12: 0101010101010101
[1.837493] x11: 0020 x10: 0001bf17d130
[1.837495] x9 : x8 : 0001b6938080
[1.837497] x7 : x6 : 003f
[1.837500] x5 : x4 :
[1.837502] x3 : 80001096a880 x2 :
[1.837505] x1 : 0001b7e40e00 x0 : 00010001
[1.837507] Kernel panic - not syncing: Asynchronous SError Interrupt
[1.837509] CPU: 0 PID: 74 Comm: kworker/0:1 Not tainted 5.8.0+ #205
[1.837510] Hardware name: HiKey970 (DT)
[1.837511] Workqueue: events deferred_probe_work_func
[1.837513] Call trace:
[1.837514] dump_backtrace+0x0/0x1e0
[1.837515] show_stack+0x18/0x24
[1.837516] dump_stack+0xc0/0x11c
[1.837517] panic+0x15c/0x324
[1.837518] nmi_panic+0x8c/0x90
[1.837519] arm64_serror_panic+0x78/0x84
[1.837520] do_serror+0x158/0x15c
[1.837521] el1_error+0x84/0x100
[1.837522] _raw_spin_unlock_irqrestore+0x18/0x50
[1.837523] regmap_write+0x58/0x80
[1.837524] hi3660_reset_deassert+0x28/0x34
[1.837526] reset_control_deassert+0x50/0x260
[1.837527] reset_control_deassert+0xf4/0x260
[1.837528] dwc3_probe+0x5dc/0xe6c
[1.837529] platform_drv_probe+0x54/0xb0
[1.837530] really_probe+0xe0/0x490
[1.837531] driver_probe_device+0xf4/0x160
[1.837532] __device_attach_driver+0x8c/0x114
[1.837533] bus_for_each_drv+0x78/0xcc
[1.837534] __device_attach+0x108/0x1a0
[1.837535] device_initial_probe+0x14/0x20
[1.837537] bus_probe_device+0x98/0xa0
[1.837538] deferred_probe_work_func+0x88/0xe0
[1.837539] process_one_work+0x1cc/0x350
[1.837540] worker_thread+0x2c0/0x470
[1.837541] kthread+0x154/0x160
[1.837542] ret_from_fork+0x10/0x30
[1.837569] SMP: stopping secondary CPUs
[1.837570] Kernel Offset: 0x1d from 0x80001000
[1.837571] PHYS_OFFSET: 0x0
[1.837572] CPU features: 0x240002,20882004
[1.837573] Memory Limit: none
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Felipe Balbi
Signed-off-by: Sasha Levin
---
drivers/usb/dwc3/dwc3-of-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/dwc3/dwc3-of-simple.c
b/drivers/usb/dwc3/dwc3-of-simple.c
index 7df1150129354..2816e4a9813ad 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -176,6 +176,7 @@ static const struct of_device_id of_dwc3_simple_match[] = {
{ .compatible = "cavium,octeon-7130-usb-uctl" },
{ .compatible = "sprd,sc9860-dwc3" },
{ .compatible = "allwinner,sun50i-h6-dwc3" },
+ { .compatible = "hisilicon,hi3670-dwc3" },
{ /* Sentinel */ }
};
MODULE_DEVICE_TABLE(of, of_dwc3_simple_match);
--
2.25.1
[PATCH AUTOSEL 5.9 057/111] habanalabs: cast to u64 before shift > 31 bits
From: Oded Gabbay
[ Upstream commit f763946aefe67b3ea58696b75a930ba1ed886a83 ]
When shifting a boolean variable by more than 31 bits and putting the
result into a u64 variable, we need to cast the boolean into unsigned 64
bits to prevent possible overflow.
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Signed-off-by: Oded Gabbay
Signed-off-by: Sasha Levin
---
drivers/misc/habanalabs/gaudi/gaudi.c | 8 +---
drivers/misc/habanalabs/goya/goya.c | 8 +---
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/misc/habanalabs/gaudi/gaudi.c
b/drivers/misc/habanalabs/gaudi/gaudi.c
index 4009b7df4cafe..2e55890ad6a61 100644
--- a/drivers/misc/habanalabs/gaudi/gaudi.c
+++ b/drivers/misc/habanalabs/gaudi/gaudi.c
@@ -6099,7 +6099,7 @@ static bool gaudi_is_device_idle(struct hl_device *hdev,
u32 *mask,
is_idle &= is_eng_idle;
if (mask)
- *mask |= !is_eng_idle <<
+ *mask |= ((u64) !is_eng_idle) <<
(GAUDI_ENGINE_ID_DMA_0 + dma_id);
if (s)
seq_printf(s, fmt, dma_id,
@@ -6122,7 +6122,8 @@ static bool gaudi_is_device_idle(struct hl_device *hdev,
u32 *mask,
is_idle &= is_eng_idle;
if (mask)
- *mask |= !is_eng_idle << (GAUDI_ENGINE_ID_TPC_0 + i);
+ *mask |= ((u64) !is_eng_idle) <<
+ (GAUDI_ENGINE_ID_TPC_0 + i);
if (s)
seq_printf(s, fmt, i,
is_eng_idle ? "Y" : "N",
@@ -6150,7 +6151,8 @@ static bool gaudi_is_device_idle(struct hl_device *hdev,
u32 *mask,
is_idle &= is_eng_idle;
if (mask)
- *mask |= !is_eng_idle << (GAUDI_ENGINE_ID_MME_0 + i);
+ *mask |= ((u64) !is_eng_idle) <<
+ (GAUDI_ENGINE_ID_MME_0 + i);
if (s) {
if (!is_slave)
seq_printf(s, fmt, i,
diff --git a/drivers/misc/habanalabs/goya/goya.c
b/drivers/misc/habanalabs/goya/goya.c
index 33cd2ae653d23..c09742f440f96 100644
--- a/drivers/misc/habanalabs/goya/goya.c
+++ b/drivers/misc/habanalabs/goya/goya.c
@@ -5166,7 +5166,8 @@ static bool goya_is_device_idle(struct hl_device *hdev,
u32 *mask,
is_idle &= is_eng_idle;
if (mask)
- *mask |= !is_eng_idle << (GOYA_ENGINE_ID_DMA_0 + i);
+ *mask |= ((u64) !is_eng_idle) <<
+ (GOYA_ENGINE_ID_DMA_0 + i);
if (s)
seq_printf(s, dma_fmt, i, is_eng_idle ? "Y" : "N",
qm_glbl_sts0, dma_core_sts0);
@@ -5189,7 +5190,8 @@ static bool goya_is_device_idle(struct hl_device *hdev,
u32 *mask,
is_idle &= is_eng_idle;
if (mask)
- *mask |= !is_eng_idle << (GOYA_ENGINE_ID_TPC_0 + i);
+ *mask |= ((u64) !is_eng_idle) <<
+ (GOYA_ENGINE_ID_TPC_0 + i);
if (s)
seq_printf(s, fmt, i, is_eng_idle ? "Y" : "N",
qm_glbl_sts0, cmdq_glbl_sts0, tpc_cfg_sts);
@@ -5209,7 +5211,7 @@ static bool goya_is_device_idle(struct hl_device *hdev,
u32 *mask,
is_idle &= is_eng_idle;
if (mask)
- *mask |= !is_eng_idle << GOYA_ENGINE_ID_MME_0;
+ *mask |= ((u64) !is_eng_idle) << GOYA_ENGINE_ID_MME_0;
if (s) {
seq_printf(s, fmt, 0, is_eng_idle ? "Y" : "N", qm_glbl_sts0,
cmdq_glbl_sts0, mme_arch_sts);
--
2.25.1
[PATCH AUTOSEL 5.9 028/111] media: saa7134: avoid a shift overflow
From: Mauro Carvalho Chehab
[ Upstream commit 15a36aae1ec1c1f17149b6113b92631791830740 ]
As reported by smatch:
drivers/media/pci/saa7134//saa7134-tvaudio.c:686 saa_dsp_writel() warn:
should 'reg << 2' be a 64 bit type?
On a 64-bits Kernel, the shift might be bigger than 32 bits.
In real, this should never happen, but let's shut up the warning.
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/media/pci/saa7134/saa7134-tvaudio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/pci/saa7134/saa7134-tvaudio.c
b/drivers/media/pci/saa7134/saa7134-tvaudio.c
index 79e1afb710758..5cc4ef21f9d37 100644
--- a/drivers/media/pci/saa7134/saa7134-tvaudio.c
+++ b/drivers/media/pci/saa7134/saa7134-tvaudio.c
@@ -683,7 +683,8 @@ int saa_dsp_writel(struct saa7134_dev *dev, int reg, u32
value)
{
int err;
- audio_dbg(2, "dsp write reg 0x%x = 0x%06x\n", reg << 2, value);
+ audio_dbg(2, "dsp write reg 0x%x = 0x%06x\n",
+ (reg << 2) & 0x, value);
err = saa_dsp_wait_bit(dev,SAA7135_DSP_RWSTATE_WRR);
if (err < 0)
return err;
--
2.25.1
[PATCH AUTOSEL 5.9 037/111] ip_gre: set dev->hard_header_len and dev->needed_headroom properly
From: Cong Wang
[ Upstream commit fdafed459998e2be0e877e6189b24cb7a0183224 ]
GRE tunnel has its own header_ops, ipgre_header_ops, and sets it
conditionally. When it is set, it assumes the outer IP header is
already created before ipgre_xmit().
This is not true when we send packets through a raw packet socket,
where L2 headers are supposed to be constructed by user. Packet
socket calls dev_validate_header() to validate the header. But
GRE tunnel does not set dev->hard_header_len, so that check can
be simply bypassed, therefore uninit memory could be passed down
to ipgre_xmit(). Similar for dev->needed_headroom.
dev->hard_header_len is supposed to be the length of the header
created by dev->header_ops->create(), so it should be used whenever
header_ops is set, and dev->needed_headroom should be used when it
is not set.
Reported-and-tested-by: syzbot+4a2c52677a8a1aa28...@syzkaller.appspotmail.com
Cc: William Tu
Acked-by: Willem de Bruijn
Signed-off-by: Cong Wang
Acked-by: Xie He
Signed-off-by: Jakub Kicinski
Signed-off-by: Sasha Levin
---
net/ipv4/ip_gre.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 4e31f23e4117e..e70291748889b 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -625,9 +625,7 @@ static netdev_tx_t ipgre_xmit(struct sk_buff *skb,
}
if (dev->header_ops) {
- /* Need space for new headers */
- if (skb_cow_head(skb, dev->needed_headroom -
- (tunnel->hlen + sizeof(struct iphdr
+ if (skb_cow_head(skb, 0))
goto free_skb;
tnl_params = (const struct iphdr *)skb->data;
@@ -748,7 +746,11 @@ static void ipgre_link_update(struct net_device *dev, bool
set_mtu)
len = tunnel->tun_hlen - len;
tunnel->hlen = tunnel->hlen + len;
- dev->needed_headroom = dev->needed_headroom + len;
+ if (dev->header_ops)
+ dev->hard_header_len += len;
+ else
+ dev->needed_headroom += len;
+
if (set_mtu)
dev->mtu = max_t(int, dev->mtu - len, 68);
@@ -944,6 +946,7 @@ static void __gre_tunnel_init(struct net_device *dev)
tunnel->parms.iph.protocol = IPPROTO_GRE;
tunnel->hlen = tunnel->tun_hlen + tunnel->encap_hlen;
+ dev->needed_headroom = tunnel->hlen + sizeof(tunnel->parms.iph);
dev->features |= GRE_FEATURES;
dev->hw_features|= GRE_FEATURES;
@@ -987,10 +990,14 @@ static int ipgre_tunnel_init(struct net_device *dev)
return -EINVAL;
dev->flags = IFF_BROADCAST;
dev->header_ops = _header_ops;
+ dev->hard_header_len = tunnel->hlen + sizeof(*iph);
+ dev->needed_headroom = 0;
}
#endif
} else if (!tunnel->collect_md) {
dev->header_ops = _header_ops;
+ dev->hard_header_len = tunnel->hlen + sizeof(*iph);
+ dev->needed_headroom = 0;
}
return ip_tunnel_init(dev);
--
2.25.1
[PATCH AUTOSEL 5.9 036/111] ntfs: add check for mft record size in superblock
From: Rustam Kovhaev
[ Upstream commit 4f8c94022f0bc3babd0a124c0a7dcdd7547bd94e ]
Number of bytes allocated for mft record should be equal to the mft record
size stored in ntfs superblock as reported by syzbot, userspace might
trigger out-of-bounds read by dereferencing ctx->attr in ntfs_attr_find()
Reported-by: syzbot+aed06913f36eff9b5...@syzkaller.appspotmail.com
Signed-off-by: Rustam Kovhaev
Signed-off-by: Andrew Morton
Tested-by: syzbot+aed06913f36eff9b5...@syzkaller.appspotmail.com
Acked-by: Anton Altaparmakov
Link: https://syzkaller.appspot.com/bug?extid=aed06913f36eff9b544e
Link: https://lkml.kernel.org/r/20200824022804.226242-1-rkovh...@gmail.com
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
fs/ntfs/inode.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/ntfs/inode.c b/fs/ntfs/inode.c
index 9bb9f0952b186..caf563981532b 100644
--- a/fs/ntfs/inode.c
+++ b/fs/ntfs/inode.c
@@ -1810,6 +1810,12 @@ int ntfs_read_inode_mount(struct inode *vi)
brelse(bh);
}
+ if (le32_to_cpu(m->bytes_allocated) != vol->mft_record_size) {
+ ntfs_error(sb, "Incorrect mft record size %u in superblock,
should be %u.",
+ le32_to_cpu(m->bytes_allocated),
vol->mft_record_size);
+ goto err_out;
+ }
+
/* Apply the mst fixups. */
if (post_read_mst_fixup((NTFS_RECORD*)m, vol->mft_record_size)) {
/* FIXME: Try to use the $MFTMirr now. */
--
2.25.1
[PATCH AUTOSEL 5.9 003/111] x86/dumpstack: Fix misleading instruction pointer error message
From: Mark Mossberg
[ Upstream commit 238c91115cd05c71447ea071624a4c9fe661f970 ]
Printing "Bad RIP value" if copy_code() fails can be misleading for
userspace pointers, since copy_code() can fail if the instruction
pointer is valid but the code is paged out. This is because copy_code()
calls copy_from_user_nmi() for userspace pointers, which disables page
fault handling.
This is reproducible in OOM situations, where it's plausible that the
code may be reclaimed in the time between entry into the kernel and when
this message is printed. This leaves a misleading log in dmesg that
suggests instruction pointer corruption has occurred, which may alarm
users.
Change the message to state the error condition more precisely.
[ bp: Massage a bit. ]
Signed-off-by: Mark Mossberg
Signed-off-by: Borislav Petkov
Link: https://lkml.kernel.org/r/20201002042915.403558-1-mark.mossb...@gmail.com
Signed-off-by: Sasha Levin
---
arch/x86/kernel/dumpstack.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 48ce44576947c..ea8d51ec251bb 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -115,7 +115,8 @@ void show_opcodes(struct pt_regs *regs, const char *loglvl)
unsigned long prologue = regs->ip - PROLOGUE_SIZE;
if (copy_code(regs, opcodes, prologue, sizeof(opcodes))) {
- printk("%sCode: Bad RIP value.\n", loglvl);
+ printk("%sCode: Unable to access opcode bytes at RIP 0x%lx.\n",
+ loglvl, prologue);
} else {
printk("%sCode: %" __stringify(PROLOGUE_SIZE) "ph <%02x> %"
__stringify(EPILOGUE_SIZE) "ph\n", loglvl, opcodes,
--
2.25.1
Re: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks
On Sun, 2020-10-18 at 20:16 +0100, Matthew Wilcox wrote: > On Sun, Oct 18, 2020 at 12:13:35PM -0700, James Bottomley wrote: > > On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote: > > > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote: > > > > clang has a number of useful, new warnings see > > > > https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$ > > > > > > > > > > Please get your IT department to remove that stupidity. If you > > > can't, please send email from a non-Red Hat email address. > > > > Actually, the problem is at Oracle's end somewhere in the ocfs2 > > list ... if you could fix it, that would be great. The usual real > > mailing lists didn't get this transformation > > > > https://lore.kernel.org/bpf/20201017160928.12698-1-t...@redhat.com/ > > > > but the ocfs2 list archive did: > > > > https://oss.oracle.com/pipermail/ocfs2-devel/2020-October/015330.html > > > > I bet Oracle IT has put some spam filter on the list that mangles > > URLs this way. > > *sigh*. I'm sure there's a way. I've raised it with someone who > should be able to fix it. As someone who works for IBM I can only say I feel your pain ... James
[PATCH AUTOSEL 5.9 018/111] media: media/pci: prevent memory leak in bttv_probe
From: Xiaolong Huang
[ Upstream commit 7b817585b730665126b45df5508dd69526448bc8 ]
In bttv_probe if some functions such as pci_enable_device,
pci_set_dma_mask and request_mem_region fails the allocated
memory for btv should be released.
Signed-off-by: Xiaolong Huang
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/media/pci/bt8xx/bttv-driver.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/media/pci/bt8xx/bttv-driver.c
b/drivers/media/pci/bt8xx/bttv-driver.c
index 9144f795fb933..b721720f9845a 100644
--- a/drivers/media/pci/bt8xx/bttv-driver.c
+++ b/drivers/media/pci/bt8xx/bttv-driver.c
@@ -4013,11 +4013,13 @@ static int bttv_probe(struct pci_dev *dev, const struct
pci_device_id *pci_id)
btv->id = dev->device;
if (pci_enable_device(dev)) {
pr_warn("%d: Can't enable device\n", btv->c.nr);
- return -EIO;
+ result = -EIO;
+ goto free_mem;
}
if (pci_set_dma_mask(dev, DMA_BIT_MASK(32))) {
pr_warn("%d: No suitable DMA available\n", btv->c.nr);
- return -EIO;
+ result = -EIO;
+ goto free_mem;
}
if (!request_mem_region(pci_resource_start(dev,0),
pci_resource_len(dev,0),
@@ -4025,7 +4027,8 @@ static int bttv_probe(struct pci_dev *dev, const struct
pci_device_id *pci_id)
pr_warn("%d: can't request iomem (0x%llx)\n",
btv->c.nr,
(unsigned long long)pci_resource_start(dev, 0));
- return -EBUSY;
+ result = -EBUSY;
+ goto free_mem;
}
pci_set_master(dev);
pci_set_command(dev);
@@ -4211,6 +4214,10 @@ static int bttv_probe(struct pci_dev *dev, const struct
pci_device_id *pci_id)
release_mem_region(pci_resource_start(btv->c.pci,0),
pci_resource_len(btv->c.pci,0));
pci_disable_device(btv->c.pci);
+
+free_mem:
+ bttvs[btv->c.nr] = NULL;
+ kfree(btv);
return result;
}
--
2.25.1
[PATCH AUTOSEL 5.9 001/111] md/bitmap: fix memory leak of temporary bitmap
From: Zhao Heming
[ Upstream commit 1383b347a8ae4a69c04ae3746e6cb5c8d38e2585 ]
Callers of get_bitmap_from_slot() are responsible to free the bitmap.
Suggested-by: Guoqing Jiang
Signed-off-by: Zhao Heming
Signed-off-by: Song Liu
Signed-off-by: Sasha Levin
---
drivers/md/md-bitmap.c | 3 ++-
drivers/md/md-cluster.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/md/md-bitmap.c b/drivers/md/md-bitmap.c
index b10c51988c8ee..c61ab86a28b52 100644
--- a/drivers/md/md-bitmap.c
+++ b/drivers/md/md-bitmap.c
@@ -1949,6 +1949,7 @@ int md_bitmap_load(struct mddev *mddev)
}
EXPORT_SYMBOL_GPL(md_bitmap_load);
+/* caller need to free returned bitmap with md_bitmap_free() */
struct bitmap *get_bitmap_from_slot(struct mddev *mddev, int slot)
{
int rv = 0;
@@ -2012,6 +2013,7 @@ int md_bitmap_copy_from_slot(struct mddev *mddev, int
slot,
md_bitmap_unplug(mddev->bitmap);
*low = lo;
*high = hi;
+ md_bitmap_free(bitmap);
return rv;
}
@@ -2615,4 +2617,3 @@ struct attribute_group md_bitmap_group = {
.name = "bitmap",
.attrs = md_bitmap_attrs,
};
-
diff --git a/drivers/md/md-cluster.c b/drivers/md/md-cluster.c
index d50737ec40394..afbbc552c3275 100644
--- a/drivers/md/md-cluster.c
+++ b/drivers/md/md-cluster.c
@@ -1166,6 +1166,7 @@ static int resize_bitmaps(struct mddev *mddev, sector_t
newsize, sector_t oldsiz
* can't resize bitmap
*/
goto out;
+ md_bitmap_free(bitmap);
}
return 0;
--
2.25.1
[PATCH AUTOSEL 5.9 011/111] media: exynos4-is: Fix several reference count leaks due to pm_runtime_get_sync
From: Qiushi Wu
[ Upstream commit 7ef64ceea0008c17e94a8a2c60c5d6d46f481996 ]
On calling pm_runtime_get_sync() the reference count of the device
is incremented. In case of failure, decrement the
reference count before returning the error.
Signed-off-by: Qiushi Wu
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/media/platform/exynos4-is/fimc-isp.c | 4 +++-
drivers/media/platform/exynos4-is/fimc-lite.c | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-isp.c
b/drivers/media/platform/exynos4-is/fimc-isp.c
index cde0d254ec1c4..a77c49b185115 100644
--- a/drivers/media/platform/exynos4-is/fimc-isp.c
+++ b/drivers/media/platform/exynos4-is/fimc-isp.c
@@ -305,8 +305,10 @@ static int fimc_isp_subdev_s_power(struct v4l2_subdev *sd,
int on)
if (on) {
ret = pm_runtime_get_sync(>pdev->dev);
- if (ret < 0)
+ if (ret < 0) {
+ pm_runtime_put(>pdev->dev);
return ret;
+ }
set_bit(IS_ST_PWR_ON, >state);
ret = fimc_is_start_firmware(is);
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c
b/drivers/media/platform/exynos4-is/fimc-lite.c
index 9c666f663ab43..fdd0d369b1925 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -471,7 +471,7 @@ static int fimc_lite_open(struct file *file)
set_bit(ST_FLITE_IN_USE, >state);
ret = pm_runtime_get_sync(>pdev->dev);
if (ret < 0)
- goto unlock;
+ goto err_pm;
ret = v4l2_fh_open(file);
if (ret < 0)
--
2.25.1
[PATCH AUTOSEL 5.9 024/111] media: rcar_drif: Fix fwnode reference leak when parsing DT
From: Laurent Pinchart
[ Upstream commit cdd4f7824994c9254acc6e415750529ea2d2cfe0 ]
The fwnode reference corresponding to the endpoint is leaked in an error
path of the rcar_drif_parse_subdevs() function. Fix it, and reorganize
fwnode reference handling in the function to release references early,
simplifying error paths.
Signed-off-by: Laurent Pinchart
Signed-off-by: Sakari Ailus
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/media/platform/rcar_drif.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/rcar_drif.c
b/drivers/media/platform/rcar_drif.c
index 3d2451ac347d7..3f1e5cb8b1976 100644
--- a/drivers/media/platform/rcar_drif.c
+++ b/drivers/media/platform/rcar_drif.c
@@ -1227,28 +1227,22 @@ static int rcar_drif_parse_subdevs(struct rcar_drif_sdr
*sdr)
if (!ep)
return 0;
+ /* Get the endpoint properties */
+ rcar_drif_get_ep_properties(sdr, ep);
+
fwnode = fwnode_graph_get_remote_port_parent(ep);
+ fwnode_handle_put(ep);
if (!fwnode) {
dev_warn(sdr->dev, "bad remote port parent\n");
- fwnode_handle_put(ep);
return -EINVAL;
}
sdr->ep.asd.match.fwnode = fwnode;
sdr->ep.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
ret = v4l2_async_notifier_add_subdev(notifier, >ep.asd);
- if (ret) {
- fwnode_handle_put(fwnode);
- return ret;
- }
-
- /* Get the endpoint properties */
- rcar_drif_get_ep_properties(sdr, ep);
-
fwnode_handle_put(fwnode);
- fwnode_handle_put(ep);
- return 0;
+ return ret;
}
/* Check if the given device is the primary bond */
--
2.25.1
[PATCH AUTOSEL 5.9 014/111] media: vsp1: Fix runtime PM imbalance on error
From: Dinghao Liu
[ Upstream commit 98fae901c8883640202802174a4bd70a1b9118bd ]
pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu
Reviewed-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/media/platform/vsp1/vsp1_drv.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
b/drivers/media/platform/vsp1/vsp1_drv.c
index c650e45bb0ad1..dc62533cf32ce 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -562,7 +562,12 @@ int vsp1_device_get(struct vsp1_device *vsp1)
int ret;
ret = pm_runtime_get_sync(vsp1->dev);
- return ret < 0 ? ret : 0;
+ if (ret < 0) {
+ pm_runtime_put_noidle(vsp1->dev);
+ return ret;
+ }
+
+ return 0;
}
/*
@@ -845,12 +850,12 @@ static int vsp1_probe(struct platform_device *pdev)
/* Configure device parameters based on the version register. */
pm_runtime_enable(>dev);
- ret = pm_runtime_get_sync(>dev);
+ ret = vsp1_device_get(vsp1);
if (ret < 0)
goto done;
vsp1->version = vsp1_read(vsp1, VI6_IP_VERSION);
- pm_runtime_put_sync(>dev);
+ vsp1_device_put(vsp1);
for (i = 0; i < ARRAY_SIZE(vsp1_device_infos); ++i) {
if ((vsp1->version & VI6_IP_VERSION_MODEL_MASK) ==
--
2.25.1
[PATCH AUTOSEL 5.9 009/111] media: st-delta: Fix reference count leak in delta_run_work
From: Aditya Pakki
[ Upstream commit 57cc666d36adc7b45e37ba4cd7bc4e44ec4c43d7 ]
delta_run_work() calls delta_get_sync() that increments
the reference counter. In case of failure, decrement the reference
count by calling delta_put_autosuspend().
Signed-off-by: Aditya Pakki
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/media/platform/sti/delta/delta-v4l2.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/sti/delta/delta-v4l2.c
b/drivers/media/platform/sti/delta/delta-v4l2.c
index 250322451..c691b3d81549d 100644
--- a/drivers/media/platform/sti/delta/delta-v4l2.c
+++ b/drivers/media/platform/sti/delta/delta-v4l2.c
@@ -954,8 +954,10 @@ static void delta_run_work(struct work_struct *work)
/* enable the hardware */
if (!dec->pm) {
ret = delta_get_sync(ctx);
- if (ret)
+ if (ret) {
+ delta_put_autosuspend(ctx);
goto err;
+ }
}
/* decode this access unit */
--
2.25.1
[PATCH AUTOSEL 5.9 019/111] x86/mce: Annotate mce_rd/wrmsrl() with noinstr
From: Borislav Petkov
[ Upstream commit e100777016fdf6ec3a9d7c1773b15a2b5eca6c55 ]
They do get called from the #MC handler which is already marked
"noinstr".
Commit
e2def7d49d08 ("x86/mce: Make mce_rdmsrl() panic on an inaccessible MSR")
already got rid of the instrumentation in the MSR accessors, fix the
annotation now too, in order to get rid of:
vmlinux.o: warning: objtool: do_machine_check()+0x4a: call to mce_rdmsrl()
leaves .noinstr.text section
Signed-off-by: Borislav Petkov
Link: https://lkml.kernel.org/r/20200915194020.28807-1...@alien8.de
Signed-off-by: Sasha Levin
---
arch/x86/kernel/cpu/mce/core.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index fc4f8c04bdb56..4288645425f15 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -374,16 +374,25 @@ static int msr_to_offset(u32 msr)
}
/* MSR access wrappers used for error injection */
-static u64 mce_rdmsrl(u32 msr)
+static noinstr u64 mce_rdmsrl(u32 msr)
{
u64 v;
if (__this_cpu_read(injectm.finished)) {
- int offset = msr_to_offset(msr);
+ int offset;
+ u64 ret;
+ instrumentation_begin();
+
+ offset = msr_to_offset(msr);
if (offset < 0)
- return 0;
- return *(u64 *)((char *)this_cpu_ptr() + offset);
+ ret = 0;
+ else
+ ret = *(u64 *)((char *)this_cpu_ptr() + offset);
+
+ instrumentation_end();
+
+ return ret;
}
if (rdmsrl_safe(msr, )) {
@@ -399,13 +408,19 @@ static u64 mce_rdmsrl(u32 msr)
return v;
}
-static void mce_wrmsrl(u32 msr, u64 v)
+static noinstr void mce_wrmsrl(u32 msr, u64 v)
{
if (__this_cpu_read(injectm.finished)) {
- int offset = msr_to_offset(msr);
+ int offset;
+ instrumentation_begin();
+
+ offset = msr_to_offset(msr);
if (offset >= 0)
*(u64 *)((char *)this_cpu_ptr() + offset) = v;
+
+ instrumentation_end();
+
return;
}
wrmsrl(msr, v);
--
2.25.1
[PATCH AUTOSEL 5.9 013/111] media: exynos4-is: Fix a reference count leak
From: Qiushi Wu
[ Upstream commit 64157b2cb1940449e7df2670e85781c690266588 ]
pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code, causing incorrect ref count if
pm_runtime_put_noidle() is not called in error handling paths.
Thus call pm_runtime_put_noidle() if pm_runtime_get_sync() fails.
Signed-off-by: Qiushi Wu
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin
---
drivers/media/platform/exynos4-is/mipi-csis.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/exynos4-is/mipi-csis.c
b/drivers/media/platform/exynos4-is/mipi-csis.c
index 540151bbf58f2..1aac167abb175 100644
--- a/drivers/media/platform/exynos4-is/mipi-csis.c
+++ b/drivers/media/platform/exynos4-is/mipi-csis.c
@@ -510,8 +510,10 @@ static int s5pcsis_s_stream(struct v4l2_subdev *sd, int
enable)
if (enable) {
s5pcsis_clear_counters(state);
ret = pm_runtime_get_sync(>pdev->dev);
- if (ret && ret != 1)
+ if (ret && ret != 1) {
+ pm_runtime_put_noidle(>pdev->dev);
return ret;
+ }
}
mutex_lock(>lock);
--
2.25.1
[PATCH AUTOSEL 5.9 023/111] x86/mce: Make mce_rdmsrl() panic on an inaccessible MSR
From: Borislav Petkov
[ Upstream commit e2def7d49d0812ea40a224161b2001b2e815dce2 ]
If an exception needs to be handled while reading an MSR - which is in
most of the cases caused by a #GP on a non-existent MSR - then this
is most likely the incarnation of a BIOS or a hardware bug. Such bug
violates the architectural guarantee that MCA banks are present with all
MSRs belonging to them.
The proper fix belongs in the hardware/firmware - not in the kernel.
Handling an #MC exception which is raised while an NMI is being handled
would cause the nasty NMI nesting issue because of the shortcoming of
IRET of reenabling NMIs when executed. And the machine is in an #MC
context already so be at its side.
Tracing MSR accesses while in #MC is another no-no due to tracing being
inherently a bad idea in atomic context:
vmlinux.o: warning: objtool: do_machine_check()+0x4a: call to mce_rdmsrl()
leaves .noinstr.text section
so remove all that "additional" functionality from mce_rdmsrl() and
provide it with a special exception handler which panics the machine
when that MSR is not accessible.
The exception handler prints a human-readable message explaining what
the panic reason is but, what is more, it panics while in the #GP
handler and latter won't have executed an IRET, thus opening the NMI
nesting issue in the case when the #MC has happened while handling
an NMI. (#MC itself won't be reenabled until MCG_STATUS hasn't been
cleared).
Suggested-by: Andy Lutomirski
Suggested-by: Peter Zijlstra
[ Add missing prototypes for ex_handler_* ]
Reported-by: kernel test robot
Signed-off-by: Borislav Petkov
Reviewed-by: Tony Luck
Link: https://lkml.kernel.org/r/20200906212130.ga28...@zn.tnic
Signed-off-by: Sasha Levin
---
arch/x86/kernel/cpu/mce/core.c | 72 +-
arch/x86/kernel/cpu/mce/internal.h | 10 +
2 files changed, 70 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index 4288645425f15..84eef4fa95990 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -373,10 +373,28 @@ static int msr_to_offset(u32 msr)
return -1;
}
+__visible bool ex_handler_rdmsr_fault(const struct exception_table_entry
*fixup,
+ struct pt_regs *regs, int trapnr,
+ unsigned long error_code,
+ unsigned long fault_addr)
+{
+ pr_emerg("MSR access error: RDMSR from 0x%x at rIP: 0x%lx (%pS)\n",
+(unsigned int)regs->cx, regs->ip, (void *)regs->ip);
+
+ show_stack_regs(regs);
+
+ panic("MCA architectural violation!\n");
+
+ while (true)
+ cpu_relax();
+
+ return true;
+}
+
/* MSR access wrappers used for error injection */
static noinstr u64 mce_rdmsrl(u32 msr)
{
- u64 v;
+ DECLARE_ARGS(val, low, high);
if (__this_cpu_read(injectm.finished)) {
int offset;
@@ -395,21 +413,43 @@ static noinstr u64 mce_rdmsrl(u32 msr)
return ret;
}
- if (rdmsrl_safe(msr, )) {
- WARN_ONCE(1, "mce: Unable to read MSR 0x%x!\n", msr);
- /*
-* Return zero in case the access faulted. This should
-* not happen normally but can happen if the CPU does
-* something weird, or if the code is buggy.
-*/
- v = 0;
- }
+ /*
+* RDMSR on MCA MSRs should not fault. If they do, this is very much an
+* architectural violation and needs to be reported to hw vendor. Panic
+* the box to not allow any further progress.
+*/
+ asm volatile("1: rdmsr\n"
+"2:\n"
+_ASM_EXTABLE_HANDLE(1b, 2b, ex_handler_rdmsr_fault)
+: EAX_EDX_RET(val, low, high) : "c" (msr));
- return v;
+
+ return EAX_EDX_VAL(val, low, high);
+}
+
+__visible bool ex_handler_wrmsr_fault(const struct exception_table_entry
*fixup,
+ struct pt_regs *regs, int trapnr,
+ unsigned long error_code,
+ unsigned long fault_addr)
+{
+ pr_emerg("MSR access error: WRMSR to 0x%x (tried to write 0x%08x%08x)
at rIP: 0x%lx (%pS)\n",
+(unsigned int)regs->cx, (unsigned int)regs->dx, (unsigned
int)regs->ax,
+ regs->ip, (void *)regs->ip);
+
+ show_stack_regs(regs);
+
+ panic("MCA architectural violation!\n");
+
+ while (true)
+ cpu_relax();
+
+ return true;
}
static noinstr void mce_wrmsrl(u32 msr, u64 v)
{
+ u32 low, high;
+
if (__this_cpu_read(injectm.finished)) {
int offset;
@@ -423,7 +463,15 @@ static noinstr void mce_wrmsrl(u32 msr, u64 v)
return;
}
- wrmsrl(msr, v);
+
+ low = (u32)v;
+
Re: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks
On Sun, Oct 18, 2020 at 12:13:35PM -0700, James Bottomley wrote: > On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote: > > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote: > > > clang has a number of useful, new warnings see > > > https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$ > > > > > > > Please get your IT department to remove that stupidity. If you > > can't, please send email from a non-Red Hat email address. > > Actually, the problem is at Oracle's end somewhere in the ocfs2 list > ... if you could fix it, that would be great. The usual real mailing > lists didn't get this transformation > > https://lore.kernel.org/bpf/20201017160928.12698-1-t...@redhat.com/ > > but the ocfs2 list archive did: > > https://oss.oracle.com/pipermail/ocfs2-devel/2020-October/015330.html > > I bet Oracle IT has put some spam filter on the list that mangles URLs > this way. *sigh*. I'm sure there's a way. I've raised it with someone who should be able to fix it.
Re: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks
On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote: > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote: > > clang has a number of useful, new warnings see > > https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$ > > > > Please get your IT department to remove that stupidity. If you > can't, please send email from a non-Red Hat email address. Actually, the problem is at Oracle's end somewhere in the ocfs2 list ... if you could fix it, that would be great. The usual real mailing lists didn't get this transformation https://lore.kernel.org/bpf/20201017160928.12698-1-t...@redhat.com/ but the ocfs2 list archive did: https://oss.oracle.com/pipermail/ocfs2-devel/2020-October/015330.html I bet Oracle IT has put some spam filter on the list that mangles URLs this way. James
lib/crypto/chacha.c:65:1: warning: the frame size of 1604 bytes is larger than 1024 bytes
Hi Ard,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 9d9af1007bc08971953ae915d88dc9bb21344b53
commit: 5fb8ef25803ef33e2eb60b626435828b937bed75 crypto: chacha - move existing
library code into lib/crypto
date: 11 months ago
config: i386-randconfig-r023-20201019 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5fb8ef25803ef33e2eb60b626435828b937bed75
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 5fb8ef25803ef33e2eb60b626435828b937bed75
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
lib/crypto/chacha.c: In function 'chacha_permute':
>> lib/crypto/chacha.c:65:1: warning: the frame size of 1604 bytes is larger
>> than 1024 bytes [-Wframe-larger-than=]
65 | }
| ^
vim +65 lib/crypto/chacha.c
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12 16
1ca1b917940c24 lib/chacha.c Eric Biggers 2018-11-16 17 static void
chacha_permute(u32 *x, int nrounds)
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12 18 {
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12 19 int i;
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12 20
1ca1b917940c24 lib/chacha.c Eric Biggers 2018-11-16 21 /* whitelist
the allowed round counts */
aa7624093cb7fb lib/chacha.c Eric Biggers 2018-11-16 22
WARN_ON_ONCE(nrounds != 20 && nrounds != 12);
1ca1b917940c24 lib/chacha.c Eric Biggers 2018-11-16 23
1ca1b917940c24 lib/chacha.c Eric Biggers 2018-11-16 24 for (i = 0; i <
nrounds; i += 2) {
7660b1fb367eb3 lib/chacha20.c Eric Biggers 2017-12-31 25 x[0]
+= x[4];x[12] = rol32(x[12] ^ x[0], 16);
7660b1fb367eb3 lib/chacha20.c Eric Biggers 2017-12-31 26 x[1]
+= x[5];x[13] = rol32(x[13] ^ x[1], 16);
7660b1fb367eb3 lib/chacha20.c Eric Biggers 2017-12-31 27 x[2]
+= x[6];x[14] = rol32(x[14] ^ x[2], 16);
7660b1fb367eb3 lib/chacha20.c Eric Biggers 2017-12-31 28 x[3]
+= x[7];x[15] = rol32(x[15] ^ x[3], 16);
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12 29
7660b1fb367eb3 lib/chacha20.c Eric Biggers 2017-12-31 30 x[8]
+= x[12]; x[4] = rol32(x[4] ^ x[8], 12);
7660b1fb367eb3 lib/chacha20.c Eric Biggers 2017-12-31 31 x[9]
+= x[13]; x[5] = rol32(x[5] ^ x[9], 12);
7660b1fb367eb3 lib/chacha20.c Eric Biggers 2017-12-31 32 x[10]
+= x[14]; x[6] = rol32(x[6] ^ x[10], 12);
7660b1fb367eb3 lib/chacha20.c Eric Biggers 2017-12-31 33 x[11]
+= x[15]; x[7] = rol32(x[7] ^ x[11], 12);
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12 34
7660b1fb367eb3 lib/chacha20.c Eric Biggers 2017-12-31 35 x[0]
+= x[4];x[12] = rol32(x[12] ^ x[0], 8);
7660b1fb367eb3 lib/chacha20.c Eric Biggers 2017-12-31 36 x[1]
+= x[5];x[13] = rol32(x[13] ^ x[1], 8);
7660b1fb367eb3 lib/chacha20.c Eric Biggers 2017-12-31 37 x[2]
+= x[6];x[14] = rol32(x[14] ^ x[2], 8);
7660b1fb367eb3 lib/chacha20.c Eric Biggers 2017-12-31 38 x[3]
+= x[7];x[15] = rol32(x[15] ^ x[3], 8);
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12 39
7660b1fb367eb3 lib/chacha20.c Eric Biggers 2017-12-31 40 x[8]
+= x[12]; x[4] = rol32(x[4] ^ x[8], 7);
7660b1fb367eb3 lib/chacha20.c Eric Biggers 2017-12-31 41 x[9]
+= x[13]; x[5] = rol32(x[5] ^ x[9], 7);
7660b1fb367eb3 lib/chacha20.c Eric Biggers 2017-12-31 42 x[10]
+= x[14]; x[6] = rol32(x[6] ^ x[10], 7);
7660b1fb367eb3 lib/chacha20.c Eric Biggers 2017-12-31 43 x[11]
+= x[15]; x[7] = rol32(x[7] ^ x[11], 7);
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12 44
7660b1fb367eb3 lib/chacha20.c Eric Biggers 2017-12-31 45 x[0]
+= x[5];x[15] = rol32(x[15] ^ x[0], 16);
7660b1fb367eb3 lib/chacha20.c Eric Biggers 2017-12-31 46 x[1]
+= x[6];x[12] = rol32(x[12] ^ x[1], 16);
7660b1fb367eb3 lib/chacha20.c Eric Biggers 2017-12-31 47 x[2]
+= x[7];x[13] = rol32(x[13] ^ x[2], 16);
7660b1fb367eb3 lib/chacha20.c Eric Biggers 2017-12-31 48 x[3]
+= x[4];x[14] = rol32(x[14] ^ x[3], 16);
e192be9d9a3055 lib/chacha20.c Theodore Ts'o 2016-06-12 49
7660b1fb367eb3 lib/chacha20.c Eric Biggers 2017-12-31 50 x[10]
+= x[15]; x[5] = rol32(x[5] ^ x[10], 12);
7660b1fb367eb3 lib/chacha20.c Eric Biggers 2017-12-31 51 x[11]
+= x[12]; x[6] =
Donation for you
I am donating $3,700,000 USD to you. Reply back for more information. Email royah...@gmail.com
Re: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks
On Sun, 2020-10-18 at 19:59 +0100, Matthew Wilcox wrote: > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote: > > clang has a number of useful, new warnings see > > https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$ > > > > Please get your IT department to remove that stupidity. If you can't, > please send email from a non-Red Hat email address. I didn't get it this way, neither did lore. It's on your end. https://lore.kernel.org/lkml/20201017160928.12698-1-t...@redhat.com/ > I don't understand why this is a useful warning to fix. Precision in coding style intent and code minimization would be the biggest factors IMO. > What actual problem is caused by the code below? Obviously none.
iperf 2.0.14 in early field test (EFT) phase
Hi All, Sorry for the spam - trying to reach interested parties. Just a heads up that iperf 2.0.14 is in early field test phase. Lots of new features around write to read latencies and others. Also, full-duplex, same socket testing now supported too. Use -e to get the enhanced output. Man page should be in reasonable shape. Release notes as of today: https://sourceforge.net/projects/iperf2/ 2.0.14 change set (as of October 17th, 2020) o scaling improvements for -P, i.e. improved support for large numbers of traffic threads o major code refactoring (see doc/DESIGN_NOTES) for maintainability, extensibilty, performance, scaling, memory usage o support for full duplex traffic using --full-duplex o support for reverse traffic using --reverse o support for role-reversal character of asterisk in the transfer id o transfer id now an incrementing integer and no longer the socket id o support for TCP connect only tests with --connect-only o isochronous support compiled in by default, must use config to disable o support --isochronous for both UDP or TCP traffic to simulate video streams o use of clock_nanosleep when supported to schedule isochronous burst starts, otherwise use nanosleep delay o support for --trip-times indicating the client and server clocks are synchronized to an accuracy sufficient, note: consider the use of precision time protocol as well as ask your data center to provide access to a GPS disciplined reference time source o support for --trip-times with -d and -r bidirectional tests o output TCP connect times (3WHS) in connect reports o support for application level tcp connect retries via --connect-retries n o rate-limited options of -b and --fq-rate supported for unidirectional, full duplex and reverse traffic o reporter thread designed to automatically cause packet reports to aggregate - mitigating and hopefully removing thread thrashing o support for frame or burst based reporting or sampling vs time based via -i [f|F] (experimental) o support for UDP traffic only from client to server with --no-udp-fin o support for write to read latencies (UDP and TCP) with --trip-times o support for sum only outputs with --sum-only o support for little's law calculations in --trip-time outputs o support for --txstart-time to schedule client traffic start, timestamp support microseconds, e.g. unix $(expr $(date +%s) + 1).$(date +%N) o support for --txdelay-time to insert delay between TCP three way handshake (3WHS) and data transfer o support for --no-connect-sync which disables transmit traffic start synchronization when -P is used, defaults to synchronized o option of --full-duplex implementation uses a barrier on the client side to synchronize full duplex traffic o no limits to group sum reports, i.e. all clients will get its own sum report per a server o improved report timestamps, e.g. end to end or client and server based timestamps with --trip-times o improved settings messaging o improved messaging for --tcp-congestion or -Z o re-implemented -U for single UDP server with minimal threading interactions o re-implemented -1 or --singleclient where server will serialize traffic runs o warning message if the test were likely CPU bound instead of network i/o bound o fix the case when -P is set on the server such that summing output is displayed o multicast listener will autoset -U (single server), e.g -P > 1 not supported for multicast o multicast listener no longer busy drops multicast packets during traffic test, i.e. only server thread receives them o immediate bail out on mutually exclusive command line options o man page updates with examples o tested with 1000's of traffic streams, WiFi, 10G and 100G Thanks, Bob McMahon
Re: [Ocfs2-devel] [RFC] treewide: cleanup unreachable breaks
On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> clang has a number of useful, new warnings see
> https://urldefense.com/v3/__https://clang.llvm.org/docs/DiagnosticsReference.html__;!!GqivPVa7Brio!Krxz78O3RKcB9JBMVo_F98FupVhj_jxX60ddN6tKGEbv_cnooXc1nnBmchm-e_O9ieGnyQ$
>
Please get your IT department to remove that stupidity. If you can't,
please send email from a non-Red Hat email address.
I don't understand why this is a useful warning to fix. What actual
problem is caused by the code below?
> return and break
>
> switch (c->x86_vendor) {
> case X86_VENDOR_INTEL:
> intel_p5_mcheck_init(c);
> return 1;
> - break;
Sure, it's unnecessary, but it's not masking a bug. It's not unclear.
Why do we want to enable this warning?
Re: [PATCH v3 2/2] i2c: i2c-mux-gpio: Enable this driver in ACPI land
On Sat, Oct 17, 2020 at 8:30 AM Evan Green wrote: > > Enable i2c-mux-gpio devices to be defined via ACPI. The idle-state > property translates directly to a fwnode_property_*() call. The child > reg property translates naturally into _ADR in ACPI. > > The i2c-parent binding is a relic from the days when the bindings > dictated that all direct children of an I2C controller had to be I2C > devices. These days that's no longer required. The i2c-mux can sit as a > direct child of its parent controller, which is where it makes the most > sense from a hardware description perspective. For the ACPI > implementation we'll assume that's always how the i2c-mux-gpio is > instantiated. Can you tell me if the following is relevant to what you are looking for? https://elixir.bootlin.com/linux/latest/source/drivers/i2c/i2c-mux.c#L393 -- With Best Regards, Andy Shevchenko
Re: [PATCH v5 4/6] drivers: leds: Add the iEi WT61P803 PUZZLE LED driver
On Sun, Oct 18, 2020 at 12:18 AM Luka Kovacic wrote:
>
> Add support for the iEi WT61P803 PUZZLE LED driver.
> Currently only the front panel power LED is supported.
>
> This driver depends on the iEi WT61P803 PUZZLE MFD driver.
...
> +/**
> + * struct iei_wt61p803_puzzle_led - MCU LED Driver
> + *
> + * @mcu: MCU struct pointer
> + * @response_bufferGlobal MCU response buffer allocation
> + * @lock: General mutex lock to protect simultaneous R/W access
> to led_power_state
> + * @led_power_state: State of the front panel power LED
> + * @cdev: LED classdev
> + */
> +struct iei_wt61p803_puzzle_led {
> + struct iei_wt61p803_puzzle *mcu;
> + unsigned char *response_buffer;
> + struct mutex lock;
> + int led_power_state;
> + struct led_classdev cdev;
If you are using container_of() and move this member to be first, you
will effectively make the container_of() a no-op.
> +};
> +
> +static inline struct iei_wt61p803_puzzle_led *cdev_to_iei_wt61p803_puzzle_led
> + (struct led_classdev *led_cdev)
> +{
> + return dev_get_drvdata(led_cdev->dev->parent);
Why not simply call container_of()
> +}
...
> + ret = fwnode_property_read_u32(child, "reg", );
> + if (ret || reg > 1) {
> + dev_err(dev, "Could not register 'reg' (%lu)\n", (unsigned
> long)reg);
When you cast explicitly during printf() you are doing something wrong
in 99.9% cases.
What's wrong with %u in this case?
> + ret = -EINVAL;
> + goto err_child_node;
> + }
--
With Best Regards,
Andy Shevchenko
[PATCH V2] checkpatch: Enable GIT_DIR environment use to set git repository location
If set, use the environment variable GIT_DIR to change the
default .git location of the kernel git tree.
If GIT_DIR is unset, keep using the current ".git" default.
Signed-off-by: Joe Perches
---
V2: learn to type my own email address...
commit f5f613259f3f ("checkpatch: allow not using -f with files that are in
git")
breaks the use of checkpatch with:
Global symbol "$gitroot" requires explicit package name (did you forget to
declare "my $gitroot"?) at ./scripts/checkpatch.pl line 980.
Execution of ./scripts/checkpatch.pl aborted due to compilation errors.
An unsigned test patch exists in -next that is required for
that new commit.
So, provide a better commit description for that test patch
and sign it too...
scripts/checkpatch.pl | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index f40a81f24d43..a213cdb82ab0 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -43,6 +43,8 @@ my $list_types = 0;
my $fix = 0;
my $fix_inplace = 0;
my $root;
+my $gitroot = $ENV{'GIT_DIR'};
+$gitroot = ".git" if !defined($gitroot);
my %debug;
my %camelcase = ();
my %use_type = ();
@@ -908,7 +910,7 @@ sub is_maintained_obsolete {
sub is_SPDX_License_valid {
my ($license) = @_;
- return 1 if (!$tree || which("python") eq "" || !(-e
"$root/scripts/spdxcheck.py") || !(-e "$root/.git"));
+ return 1 if (!$tree || which("python") eq "" || !(-e
"$root/scripts/spdxcheck.py") || !(-e "$gitroot"));
my $root_path = abs_path($root);
my $status = `cd "$root_path"; echo "$license" | python
scripts/spdxcheck.py -`;
@@ -926,7 +928,7 @@ sub seed_camelcase_includes {
$camelcase_seeded = 1;
- if (-e ".git") {
+ if (-e "$gitroot") {
my $git_last_include_commit = `${git_command} log --no-merges
--pretty=format:"%h%n" -1 -- include`;
chomp $git_last_include_commit;
$camelcase_cache =
".checkpatch-camelcase.git.$git_last_include_commit";
@@ -954,7 +956,7 @@ sub seed_camelcase_includes {
return;
}
- if (-e ".git") {
+ if (-e "$gitroot") {
$files = `${git_command} ls-files "include/*.h"`;
@include_files = split('\n', $files);
}
@@ -987,7 +989,7 @@ sub git_is_single_file {
sub git_commit_info {
my ($commit, $id, $desc) = @_;
- return ($id, $desc) if ((which("git") eq "") || !(-e ".git"));
+ return ($id, $desc) if ((which("git") eq "") || !(-e "$gitroot"));
my $output = `${git_command} log --no-color --format='%H %s' -1 $commit
2>&1`;
$output =~ s/^\s*//gm;
@@ -1026,7 +1028,7 @@ my $fixlinenr = -1;
# If input is git commits, extract all commits from the commit expressions.
# For example, HEAD-3 means we need check 'HEAD, HEAD~1, HEAD~2'.
-die "$P: No git repository found\n" if ($git && !-e ".git");
+die "$P: No git repository found\n" if ($git && !-e "$gitroot");
if ($git) {
my @commits = ();
[PATCH] checkpatch: Enable GIT_DIR environment use to set git repository location
If set, use the environment variable GIT_DIR to change the
default .git location of the kernel git tree.
If GIT_DIR is unset, keep using the current ".git" default.
Signed-off-by: Joe Perches
---
commit f5f613259f3f ("checkpatch: allow not using -f with files that are in
git")
breaks the use of checkpatch with:
Global symbol "$gitroot" requires explicit package name (did you forget to
declare "my $gitroot"?) at ./scripts/checkpatch.pl line 980.
Execution of ./scripts/checkpatch.pl aborted due to compilation errors.
An unsigned test patch exists in -next that is required for
that new commit.
So, provide a better commit description for that test patch
and sign it too...
scripts/checkpatch.pl | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index f40a81f24d43..a213cdb82ab0 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -43,6 +43,8 @@ my $list_types = 0;
my $fix = 0;
my $fix_inplace = 0;
my $root;
+my $gitroot = $ENV{'GIT_DIR'};
+$gitroot = ".git" if !defined($gitroot);
my %debug;
my %camelcase = ();
my %use_type = ();
@@ -908,7 +910,7 @@ sub is_maintained_obsolete {
sub is_SPDX_License_valid {
my ($license) = @_;
- return 1 if (!$tree || which("python") eq "" || !(-e
"$root/scripts/spdxcheck.py") || !(-e "$root/.git"));
+ return 1 if (!$tree || which("python") eq "" || !(-e
"$root/scripts/spdxcheck.py") || !(-e "$gitroot"));
my $root_path = abs_path($root);
my $status = `cd "$root_path"; echo "$license" | python
scripts/spdxcheck.py -`;
@@ -926,7 +928,7 @@ sub seed_camelcase_includes {
$camelcase_seeded = 1;
- if (-e ".git") {
+ if (-e "$gitroot") {
my $git_last_include_commit = `${git_command} log --no-merges
--pretty=format:"%h%n" -1 -- include`;
chomp $git_last_include_commit;
$camelcase_cache =
".checkpatch-camelcase.git.$git_last_include_commit";
@@ -954,7 +956,7 @@ sub seed_camelcase_includes {
return;
}
- if (-e ".git") {
+ if (-e "$gitroot") {
$files = `${git_command} ls-files "include/*.h"`;
@include_files = split('\n', $files);
}
@@ -987,7 +989,7 @@ sub git_is_single_file {
sub git_commit_info {
my ($commit, $id, $desc) = @_;
- return ($id, $desc) if ((which("git") eq "") || !(-e ".git"));
+ return ($id, $desc) if ((which("git") eq "") || !(-e "$gitroot"));
my $output = `${git_command} log --no-color --format='%H %s' -1 $commit
2>&1`;
$output =~ s/^\s*//gm;
@@ -1026,7 +1028,7 @@ my $fixlinenr = -1;
# If input is git commits, extract all commits from the commit expressions.
# For example, HEAD-3 means we need check 'HEAD, HEAD~1, HEAD~2'.
-die "$P: No git repository found\n" if ($git && !-e ".git");
+die "$P: No git repository found\n" if ($git && !-e "$gitroot");
if ($git) {
my @commits = ();
[PATCH] net: korina: cast KSEG0 address to pointer in kfree
Fixes gcc warning:
passing argument 1 of 'kfree' makes pointer from integer without a cast
Fixes: 3af5f0f5c74e ("net: korina: fix kfree of rx/tx descriptor array")
Reported-by: kernel test robot
Signed-off-by: Valentin Vidic
---
drivers/net/ethernet/korina.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/korina.c b/drivers/net/ethernet/korina.c
index af441d699a57..bf48f0ded9c7 100644
--- a/drivers/net/ethernet/korina.c
+++ b/drivers/net/ethernet/korina.c
@@ -1113,7 +1113,7 @@ static int korina_probe(struct platform_device *pdev)
return rc;
probe_err_register:
- kfree(KSEG0ADDR(lp->td_ring));
+ kfree((struct dma_desc *)KSEG0ADDR(lp->td_ring));
probe_err_td_ring:
iounmap(lp->tx_dma_regs);
probe_err_dma_tx:
@@ -1133,7 +1133,7 @@ static int korina_remove(struct platform_device *pdev)
iounmap(lp->eth_regs);
iounmap(lp->rx_dma_regs);
iounmap(lp->tx_dma_regs);
- kfree(KSEG0ADDR(lp->td_ring));
+ kfree((struct dma_desc *)KSEG0ADDR(lp->td_ring));
unregister_netdev(bif->dev);
free_netdev(bif->dev);
--
2.20.1
Re: [PATCH v2] iio: adc: mediatek: fix unset field
On Sun, Oct 18, 2020 at 9:31 PM Andy Shevchenko
wrote:
>
> On Sun, Oct 18, 2020 at 8:16 PM Fabien Parent wrote:
> >
> > dev_comp field is used in a couple of places but it is never set. This
> > results in kernel oops when dereferencing a NULL pointer. Set the
> > `dev_comp` field correctly in the probe function.
> >
> > Fixes: 6d97024dce23 ("iio: adc: mediatek: mt6577-auxadc, add mt6765
> > support")
> >
> > Signed-off-by: Fabien Parent
>
> Shouldn't be a blank line in the tag block.
>
> I think Jonathan can fix it, but be more careful in the future.
One more serious issue, you forgot to add tags you have gotten in the
previous round.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v2] iio: adc: mediatek: fix unset field
On Sun, Oct 18, 2020 at 8:16 PM Fabien Parent wrote:
>
> dev_comp field is used in a couple of places but it is never set. This
> results in kernel oops when dereferencing a NULL pointer. Set the
> `dev_comp` field correctly in the probe function.
>
> Fixes: 6d97024dce23 ("iio: adc: mediatek: mt6577-auxadc, add mt6765 support")
>
> Signed-off-by: Fabien Parent
Shouldn't be a blank line in the tag block.
I think Jonathan can fix it, but be more careful in the future.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v3] iio: proximity: vl53l0x-i2c add i2c_device_id
On Sun, Oct 18, 2020 at 6:53 PM Vaishnav M A wrote: > > Add i2c_device_id table for the vl53l0x-i2c driver, > helps in device instantiation using i2c_new_client_device > or from userspace in cases where device-tree based description > is not possible now (Example: device on a gbphy i2c adapter > created by greybus) Same comments as per v1. -- With Best Regards, Andy Shevchenko
Re: [PATCH v3] iio: light: vcnl4035 add i2c_device_id
On Sun, Oct 18, 2020 at 6:47 PM Vaishnav M A wrote: > > Add i2c_device_id table for the vl53l0x-i2c driver, > helps in device instantiation using i2c_new_client_device In all your patches please refer to the functions like function(). For example, here is i2c_new_client_device(). > or from userspace in cases where device-tree based description > is not possible now (Example: device on a gbphy i2c adapter > created by greybus) Don't forget proper English punctuation, like periods at the end of sentences. -- With Best Regards, Andy Shevchenko
Re: [PATCH] checkpatch: Allow not using -f with files that are in git
On Sun, 2020-10-18 at 20:15 +0200, Geert Uytterhoeven wrote:
> Hi Joe,
rehi Geert
> On Sun, Oct 18, 2020 at 6:07 PM Joe Perches wrote:
> > On Sun, 2020-10-18 at 16:03 +0200, Geert Uytterhoeven wrote:
[]
> > > This is now commit f5f613259f3fea81 ("checkpatch: allow not using -f
> > > with files that are in git"), causing:
> > >
> > > Global symbol "$gitroot" requires explicit package name (did you
> > > forget to declare "my $gitroot"?) at scripts/checkpatch.pl line 980.
> > > Execution of scripts/checkpatch.pl aborted due to compilation errors.
[]
> > I believe there is a dependency on another patch
> > in -next that wasn't pushed to Linus' tree.
> >
> > commit 5ec1f7de97b26a3fa364bbb31fdd2e42c8e6fa22
> > Author: Joe Perches
> > Date: Thu Oct 8 11:53:44 2020 +1100
> >
> > checkpatch: test $GIT_DIR changes
> >
> > So it'd be better to revert right now until
> > this other patch is accepted or pushed.
>
> Thanks, after cherry-picking that one from next, checkpatch works again.
> However, there are some issues with that commit:
> 1. ERROR: Missing Signed-off-by: line by nominal patch author 'Joe
> Perches ',
> 2. The Link: is bogus, and gives 404.
I generally create patches against -next.
The above commit was a test patch for Andrew who
had some inconvenience because he doesn't generally
use git or has a git repo in some non-standard path.
I believe it works well enough to be OK, but I
didn't test it and don't have the same setup.
I'll post it again as a reply to this email with a
with a sign-off and a better commit description and
Linus/Andrew can decide if it's better to revert
f5f613259f3f or apply it separately.
Re: [PATCH 1/3] iio: adc: aspeed: Orgnaize and add the define of adc
On Sun, Oct 18, 2020 at 1:32 PM Jonathan Cameron wrote: > On Tue, 13 Oct 2020 18:32:43 +0800 > Billy Tsai wrote: ... > > +/* [31:16] */ Useless comment. > > +#define ASPEED_ADC_CTRL_CH_EN(n) (1 << (16 + n)) > > +#define ASPEED_ADC_CTRL_CH_EN_ALLGENMASK(31, 16) But the main point is here. First of all you may use BIT() in above. Second, it's a good practice to put variables in the additional parentheses in macros in case you are doing some operations with. So, something like BIT(16 + (n)) would be nice to have at the end. -- With Best Regards, Andy Shevchenko
[GIT PULL] Mailbox changes for v5.10
Hi Linus, The following changes since commit 549738f15da0e5a00275977623be199fbbf7df50: Linux 5.9-rc8 (2020-10-04 16:04:34 -0700) are available in the Git repository at: git://git.linaro.org/landing-teams/working/fujitsu/integration.git tags/mailbox-v5.10 for you to fetch changes up to c7dacf5b0f32957b24ef29df1207dc2cd8307743: mailbox: avoid timer start from callback (2020-10-16 19:09:17 -0500) - arm: implementation of mhu as a doorbell driver conversion of dt-bindings to json-schema - mediatek: fix platform_get_irq error handling - bcm: convert tasklets to use new tasklet_setup api - core: fix race cause by hrtimer starting inappropriately Allen Pais (1): mailbox: bcm: convert tasklets to use new tasklet_setup() API Jassi Brar (1): mailbox: avoid timer start from callback Krzysztof Kozlowski (1): maiblox: mediatek: Fix handling of platform_get_irq() error Sudeep Holla (3): dt-bindings: mailbox: add doorbell support to ARM MHU mailbox: arm_mhu: Match only if compatible is "arm,mhu" mailbox: arm_mhu: Add ARM MHU doorbell driver Viresh Kumar (1): dt-bindings: mailbox : arm,mhu: Convert to Json-schema .../devicetree/bindings/mailbox/arm,mhu.yaml | 135 .../devicetree/bindings/mailbox/arm-mhu.txt| 43 --- drivers/mailbox/Makefile | 2 +- drivers/mailbox/arm_mhu.c | 3 + drivers/mailbox/arm_mhu_db.c | 354 + drivers/mailbox/bcm-pdc-mailbox.c | 6 +- drivers/mailbox/mailbox.c | 12 +- drivers/mailbox/mtk-cmdq-mailbox.c | 8 +- 8 files changed, 506 insertions(+), 57 deletions(-) create mode 100644 Documentation/devicetree/bindings/mailbox/arm,mhu.yaml delete mode 100644 Documentation/devicetree/bindings/mailbox/arm-mhu.txt create mode 100644 drivers/mailbox/arm_mhu_db.c
Re: [PATCH 1/2] iio:core: Introduce unlocked version of iio_map_array_unregister()
On Sun, Oct 18, 2020 at 4:13 AM Lino Sanfilippo wrote:
>
> Introduce an unlocked version of iio_map_array_unregister(). This function
> can help to unwind in case of error while the iio_map_list_lock mutex is
> held.
Both looks good to me, FWIW,
Reviewed-by: Andy Shevchenko
if Jonathan is okay with them.
> Signed-off-by: Lino Sanfilippo
> ---
> drivers/iio/inkern.c | 27 ++-
> 1 file changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
> index ede99e0..39c1d63 100644
> --- a/drivers/iio/inkern.c
> +++ b/drivers/iio/inkern.c
> @@ -24,6 +24,21 @@ struct iio_map_internal {
> static LIST_HEAD(iio_map_list);
> static DEFINE_MUTEX(iio_map_list_lock);
>
> +static int iio_map_array_unregister_locked(struct iio_dev *indio_dev)
> +{
> + int ret = -ENODEV;
> + struct iio_map_internal *mapi, *next;
> +
> + list_for_each_entry_safe(mapi, next, _map_list, l) {
> + if (indio_dev == mapi->indio_dev) {
> + list_del(>l);
> + kfree(mapi);
> + ret = 0;
> + }
> + }
> + return ret;
> +}
> +
> int iio_map_array_register(struct iio_dev *indio_dev, struct iio_map *maps)
> {
> int i = 0, ret = 0;
> @@ -57,18 +72,12 @@ EXPORT_SYMBOL_GPL(iio_map_array_register);
> */
> int iio_map_array_unregister(struct iio_dev *indio_dev)
> {
> - int ret = -ENODEV;
> - struct iio_map_internal *mapi, *next;
> + int ret;
>
> mutex_lock(_map_list_lock);
> - list_for_each_entry_safe(mapi, next, _map_list, l) {
> - if (indio_dev == mapi->indio_dev) {
> - list_del(>l);
> - kfree(mapi);
> - ret = 0;
> - }
> - }
> + ret = iio_map_array_unregister_locked(indio_dev);
> mutex_unlock(_map_list_lock);
> +
> return ret;
> }
> EXPORT_SYMBOL_GPL(iio_map_array_unregister);
> --
> 2.7.4
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCH] checkpatch: Allow not using -f with files that are in git
Hi Joe,
On Sun, Oct 18, 2020 at 6:07 PM Joe Perches wrote:
> On Sun, 2020-10-18 at 16:03 +0200, Geert Uytterhoeven wrote:
> > On Tue, Aug 25, 2020 at 2:12 AM Joe Perches wrote:
> > > If a file exists in git and checkpatch is used without the -f
> > > flag for scanning a file, then checkpatch will scan the file
> > > assuming it's a patch and emit:
> > >
> > > ERROR: Does not appear to be a unified-diff format patch
> > >
> > > Change the behavior to assume the -f flag if the file exists
> > > in git.
> > >
> > > Signed-off-by: Joe Perches
> >
> > Thanks for your patch!
> >
> > > --- a/scripts/checkpatch.pl
> > > +++ b/scripts/checkpatch.pl
> > > @@ -976,6 +976,16 @@ sub seed_camelcase_includes {
> > > }
> > > }
> > >
> > > +sub git_is_single_file {
> > > + my ($filename) = @_;
> > > +
> > > + return 0 if ((which("git") eq "") || !(-e "$gitroot"));
> > > +
> > > + my $output = `${git_command} ls-files -- $filename`;
> > > + my $count = $output =~ tr/\n//;
> > > + return $count eq 1 && $output =~ m{^${filename}$};
> > > +}
> > > +
> > > sub git_commit_info {
> > > my ($commit, $id, $desc) = @_;
> > >
> >
> > This is now commit f5f613259f3fea81 ("checkpatch: allow not using -f
> > with files that are in git"), causing:
> >
> > Global symbol "$gitroot" requires explicit package name (did you
> > forget to declare "my $gitroot"?) at scripts/checkpatch.pl line 980.
> > Execution of scripts/checkpatch.pl aborted due to compilation errors.
> >
> > FWIW, host system is running Ubuntu 18.04.5 LTS (upgrade to 20.04 LTS
> > planned soon ;-).
>
> I believe there is a dependency on another patch
> in -next that wasn't pushed to Linus' tree.
>
> commit 5ec1f7de97b26a3fa364bbb31fdd2e42c8e6fa22
> Author: Joe Perches
> Date: Thu Oct 8 11:53:44 2020 +1100
>
> checkpatch: test $GIT_DIR changes
>
> So it'd be better to revert right now until
> this other patch is accepted or pushed.
Thanks, after cherry-picking that one from next, checkpatch works again.
However, there are some issues with that commit:
1. ERROR: Missing Signed-off-by: line by nominal patch author 'Joe
Perches ',
2. The Link: is bogus, and gives 404.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH 2/2] docs: fb: Add font_6x8 to available built-in fonts
Recently we added a new 6x8 font in commit e2028c8e6bf9 ("lib/fonts: add
font 6x8 for OLED display"). Add its name to the "compiled-in fonts"
list.
Signed-off-by: Peilin Ye
---
Documentation/fb/fbcon.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/fb/fbcon.rst b/Documentation/fb/fbcon.rst
index 9aad964b767c..57f66de2f7e1 100644
--- a/Documentation/fb/fbcon.rst
+++ b/Documentation/fb/fbcon.rst
@@ -81,7 +81,7 @@ C. Boot options
1. fbcon=font:
Select the initial font to use. The value 'name' can be any of the
- compiled-in fonts: 10x18, 6x10, 7x14, Acorn8x8, MINI4x6,
+ compiled-in fonts: 10x18, 6x10, 6x8, 7x14, Acorn8x8, MINI4x6,
PEARL8x8, ProFont6x11, SUN12x22, SUN8x16, TER16x32, VGA8x16, VGA8x8.
Note, not all drivers can handle font with widths not divisible by 8,
--
2.25.1
Re: [PATCH v4 4/4] PCI: Limit pci_alloc_irq_vectors() to housekeeping CPUs
On 10/16/20 8:20 AM, Peter Zijlstra wrote:
> On Mon, Sep 28, 2020 at 02:35:29PM -0400, Nitesh Narayan Lal wrote:
>> If we have isolated CPUs dedicated for use by real-time tasks, we try to
>> move IRQs to housekeeping CPUs from the userspace to reduce latency
>> overhead on the isolated CPUs.
>>
>> If we allocate too many IRQ vectors, moving them all to housekeeping CPUs
>> may exceed per-CPU vector limits.
>>
>> When we have isolated CPUs, limit the number of vectors allocated by
>> pci_alloc_irq_vectors() to the minimum number required by the driver, or
>> to one per housekeeping CPU if that is larger.
>>
>> Signed-off-by: Nitesh Narayan Lal
>> ---
>> drivers/pci/msi.c | 18 ++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
>> index 30ae4ffda5c1..8c156867803c 100644
>> --- a/drivers/pci/msi.c
>> +++ b/drivers/pci/msi.c
>> @@ -23,6 +23,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "pci.h"
>>
>> @@ -1191,8 +1192,25 @@ int pci_alloc_irq_vectors_affinity(struct pci_dev
>> *dev, unsigned int min_vecs,
>> struct irq_affinity *affd)
>> {
>> struct irq_affinity msi_default_affd = {0};
>> +unsigned int hk_cpus;
>> int nvecs = -ENOSPC;
>>
>> +hk_cpus = housekeeping_num_online_cpus(HK_FLAG_MANAGED_IRQ);
>> +
>> +/*
>> + * If we have isolated CPUs for use by real-time tasks, to keep the
>> + * latency overhead to a minimum, device-specific IRQ vectors are moved
>> + * to the housekeeping CPUs from the userspace by changing their
>> + * affinity mask. Limit the vector usage to keep housekeeping CPUs from
>> + * running out of IRQ vectors.
>> + */
>> +if (hk_cpus < num_online_cpus()) {
>> +if (hk_cpus < min_vecs)
>> +max_vecs = min_vecs;
>> +else if (hk_cpus < max_vecs)
>> +max_vecs = hk_cpus;
> is that:
>
> max_vecs = clamp(hk_cpus, min_vecs, max_vecs);
Yes, I think this will do.
>
> Also, do we really need to have that conditional on hk_cpus <
> num_online_cpus()? That is, why can't we do this unconditionally?
FWIU most of the drivers using this API already restricts the number of
vectors based on the num_online_cpus, if we do it unconditionally we can
unnecessary duplicate the restriction for cases where we don't have any
isolated CPUs.
Also, different driver seems to take different factors into consideration
along with num_online_cpus while finding the max_vecs to request, for
example in the case of mlx5:
MLX5_CAP_GEN(dev, num_ports) * num_online_cpus() +
MLX5_EQ_VEC_COMP_BASE
Having hk_cpus < num_online_cpus() helps us ensure that we are only
changing the behavior when we have isolated CPUs.
Does that make sense?
>
> And what are the (desired) semantics vs hotplug? Using a cpumask without
> excluding hotplug is racy.
The housekeeping_mask should still remain constant, isn't?
In any case, I can double check this.
>
>> +}
>> +
>> if (flags & PCI_IRQ_AFFINITY) {
>> if (!affd)
>> affd = _default_affd;
>> --
>> 2.18.2
>>
--
Thanks
Nitesh
signature.asc
Description: OpenPGP digital signature
[PATCH 1/2] Fonts: Support FONT_EXTRA_WORDS macros for font_6x8
Recently, in commit 6735b4632def ("Fonts: Support FONT_EXTRA_WORDS macros
for built-in fonts"), we wrapped each of our built-in data buffers in a
`font_data` structure, in order to use the following macros on them, see
include/linux/font.h:
#define REFCOUNT(fd)(((int *)(fd))[-1])
#define FNTSIZE(fd) (((int *)(fd))[-2])
#define FNTCHARCNT(fd) (((int *)(fd))[-3])
#define FNTSUM(fd) (((int *)(fd))[-4])
#define FONT_EXTRA_WORDS 4
Do the same thing to our new 6x8 font. For built-in fonts, currently we
only use FNTSIZE(). Since this is only a temporary solution for an
out-of-bounds issue in the framebuffer layer (see commit 5af08640795b
("fbcon: Fix global-out-of-bounds read in fbcon_get_font()")), all the
three other fields are intentionally set to zero in order to discourage
using these negative-indexing macros.
Signed-off-by: Peilin Ye
---
lib/fonts/font_6x8.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/fonts/font_6x8.c b/lib/fonts/font_6x8.c
index e06447788418..700039a9ceae 100644
--- a/lib/fonts/font_6x8.c
+++ b/lib/fonts/font_6x8.c
@@ -3,8 +3,8 @@
#define FONTDATAMAX 2048
-static const unsigned char fontdata_6x8[FONTDATAMAX] = {
-
+static struct font_data fontdata_6x8 = {
+ { 0, 0, FONTDATAMAX, 0 }, {
/* 0 0x00 '^@' */
0x00, /* 00 */
0x00, /* 00 */
@@ -2564,13 +2564,13 @@ static const unsigned char fontdata_6x8[FONTDATAMAX] = {
0x00, /* 00 */
0x00, /* 00 */
0x00, /* 00 */
-};
+} };
const struct font_desc font_6x8 = {
.idx= FONT6x8_IDX,
.name = "6x8",
.width = 6,
.height = 8,
- .data = fontdata_6x8,
+ .data = fontdata_6x8.data,
.pref = 0,
};
--
2.25.1
Re: [PATCH v5] checkpatch: add new exception to repeated word check
On Sat, 2020-10-17 at 21:57 +0530, Dwaipayan Ray wrote:
> Recently, commit 4f6ad8aa1eac ("checkpatch: move repeated word test")
> moved the repeated word test to check for more file types. But after
> this, if checkpatch.pl is run on MAINTAINERS, it generates several
> new warnings of the type:
Andrew, can you pick this up please?
Acked-by: Joe Perches
> WARNING: Possible repeated word: 'git'
>
> For example:
> WARNING: Possible repeated word: 'git'
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git
>
> So, the pattern "git git://..." is a false positive in this case.
>
> There are several other combinations which may produce a wrong
> warning message, such as "@size size", ":Begin begin", etc.
>
> Extend repeated word check to compare the characters before and
> after the word matches.
>
> If there is a non whitespace character before the first word or a
> non whitespace character excluding punctuation characters after
> the second word, then the check is skipped and the warning is avoided.
>
> Also add case insensitive word matching to the repeated word check.
>
> Link:
> https://lore.kernel.org/linux-kernel-mentees/81b6a0bb2c7b9256361573f7a13201ebcd4876f1.ca...@perches.com/
> Suggested-by: Joe Perches
> Suggested-by: Lukas Bulwahn
> Signed-off-by: Dwaipayan Ray
> ---
> scripts/checkpatch.pl | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index f1a4e61917eb..ec380626bebc 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3052,19 +3052,30 @@ sub process {
>
> # check for repeated words separated by a single space
> if ($rawline =~ /^\+/ || $in_commit_log) {
> + pos($rawline) = 1 if (!$in_commit_log);
> while ($rawline =~ /\b($word_pattern)
> (?=($word_pattern))/g) {
>
> my $first = $1;
> my $second = $2;
> -
> + my $start_pos = $-[1];
> + my $end_pos = $+[2];
> if ($first =~ /(?:struct|union|enum)/) {
> pos($rawline) += length($first) +
> length($second) + 1;
> next;
> }
>
> - next if ($first ne $second);
> + next if (lc($first) ne lc($second));
> next if ($first eq 'long');
>
> + # check for character before and after the word
> matches
> + my $start_char = '';
> + my $end_char = '';
> + $start_char = substr($rawline, $start_pos - 1,
> 1) if ($start_pos > ($in_commit_log ? 0 : 1));
> + $end_char = substr($rawline, $end_pos, 1) if
> ($end_pos < length($rawline));
> +
> + next if ($start_char =~ /^\S$/);
> + next if (index(" \t.,;?!", $end_char) == -1);
> +
> if (WARN("REPEATED_WORD",
>"Possible repeated word: '$first'\n" .
> $herecurr) &&
> $fix) {
Re: Remove __napi_schedule_irqoff?
On Sun, 18 Oct 2020 19:57:53 +0200 Heiner Kallweit wrote: > > Dunno how acceptable this is to run in an IRQ handler on RT.. > > If I understand this code right then it's not a loop that actually > waits for something. It just retries if the value of n->state has > changed in between. So I don't think we'll ever see the loop being > executed more than twice. Right, but WCET = inf. IDK if that's acceptable.
Re: Remove __napi_schedule_irqoff?
On 18.10.2020 19:19, Jakub Kicinski wrote:
> On Sun, 18 Oct 2020 10:20:41 +0200 Heiner Kallweit wrote:
Otherwise a non-solution could be to make IRQ_FORCED_THREADING
configurable.
>>>
>>> I have to say I do not understand why we want to defer to a thread the
>>> hard IRQ that we use in NAPI model.
>>>
>> Seems like the current forced threading comes with the big hammer and
>> thread-ifies all hard irq's. To avoid this all NAPI network drivers
>> would have to request the interrupt with IRQF_NO_THREAD.
>
> Right, it'd work for some drivers. Other drivers try to take spin locks
> in their IRQ handlers.
>
> What gave me a pause was that we have a busy loop in napi_schedule_prep:
>
> bool napi_schedule_prep(struct napi_struct *n)
> {
> unsigned long val, new;
>
> do {
> val = READ_ONCE(n->state);
> if (unlikely(val & NAPIF_STATE_DISABLE))
> return false;
> new = val | NAPIF_STATE_SCHED;
>
> /* Sets STATE_MISSED bit if STATE_SCHED was already set
>* This was suggested by Alexander Duyck, as compiler
>* emits better code than :
>* if (val & NAPIF_STATE_SCHED)
>* new |= NAPIF_STATE_MISSED;
>*/
> new |= (val & NAPIF_STATE_SCHED) / NAPIF_STATE_SCHED *
> NAPIF_STATE_MISSED;
> } while (cmpxchg(>state, val, new) != val);
>
> return !(val & NAPIF_STATE_SCHED);
> }
>
>
> Dunno how acceptable this is to run in an IRQ handler on RT..
>
If I understand this code right then it's not a loop that actually
waits for something. It just retries if the value of n->state has
changed in between. So I don't think we'll ever see the loop being
executed more than twice.
Re: [PATCH] arm64: dts: allwinner: beelink-gs1: Enable both RGMII RX/TX delay
Hi,
On Sun, 18 Oct 2020 at 19:24, Clément Péron wrote:
>
> Before the commit:
> net: phy: realtek: fix rtl8211e rx/tx delay config
bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config")
With the hash for reference it's better :)
Clement
>
> The software overwrite for RX/TX delays of the RTL8211e were not
> working properly and the Beelink GS1 had both RX/TX delay of RGMII
> interface set using pull-up on the TXDLY and RXDLY pins.
>
> Now that these delays are working properly they overwrite the HW
> config and set this to 'rgmii' meaning no delay on both RX/TX.
> This makes the ethernet of this board not working anymore.
>
> Set the phy-mode to 'rgmii-id' meaning RGMII with RX/TX delays
> in the device-tree to keep the correct configuration.
>
> Fixes: 089bee8dd119 ("arm64: dts: allwinner: h6: Introduce Beelink GS1 board")
> Signed-off-by: Clément Péron
> ---
> arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> index a364cb4e5b3f..6ab53860e447 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> @@ -99,7 +99,7 @@ {
> {
> pinctrl-names = "default";
> pinctrl-0 = <_rgmii_pins>;
> - phy-mode = "rgmii";
> + phy-mode = "rgmii-id";
> phy-handle = <_rgmii_phy>;
> phy-supply = <_aldo2>;
> status = "okay";
> --
> 2.25.1
>
Re: Fwd: [WARNING AND ERROR] may be system slow and audio and video breaking
On Sun, Oct 18, 2020 at 10:42:39PM +0530, Jeffrin Jose T wrote: > smpboot: Scheduler frequency invariance went wobbly, disabling! > [ 1112.592866] unchecked MSR access error: RDMSR from 0x123 at rIP: > 0xb5c9a184 (native_read_msr+0x4/0x30) > [ 1112.592869] Call Trace: > [ 1112.592876] update_srbds_msr+0x6f/0xb0 > [ 1112.592880] smp_store_cpu_info+0x8e/0xb0 > [ 1112.592883] start_secondary+0x93/0x200 > [ 1112.592887] ? set_cpu_sibling_map+0xcb0/0xcb0 > [ 1112.592891] secondary_startup_64+0xa4/0xb0 > [ 1112.592898] unchecked MSR access error: WRMSR to 0x123 (tried to > write 0x) at rIP: 0xb5c9a264 > (native_write_msr+0x4/0x20) > [ 1112.592899] Call Trace: > [ 1112.592902] update_srbds_msr+0x98/0xb0 > [ 1112.592904] smp_store_cpu_info+0x8e/0xb0 > [ 1112.592907] start_secondary+0x93/0x200 > [ 1112.592911] ? set_cpu_sibling_map+0xcb0/0xcb0 > [ 1112.592914] secondary_startup_64+0xa4/0xb0 > [ 2915.106879] show_signal: 6 callbacks suppressed > [ 6089.209343] WARNING: stack going in the wrong direction? at > i915_gem_close_object+0x2fb/0x560 [i915] This looks strange. Please send - full dmesg - output from the "grep -r . /sys/devices/system/cpu/vulnerabilities/" command - /proc/cpuinfo - .config Privately is fine too. > -x---xx > Linux debian 5.9.1-rc1+ #4 SMP Fri Oct 16 16:48:04 IST 2020 x86_64 What kernel is that exactly? Can you reproduce with plain v5.9 too? Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH v1] usb: dwc3: core: fix a issue about clear connect state
Hello!
On 10/18/20 4:47 PM, Dejin Zheng wrote:
> According to Synopsys Programming Guide chapter 2.2 Register Resets,
> it cannot reset the DCTL register by set DCTL.CSFTRST for Core Soft Reset,
s/set/setting/.
> if DWC3 controller as a slave device and stay connected with a usb host,
> then, reboot linux, it will fail to reinitialize dwc3 as a slave device
s/reboot/while rebooting/.
> when the DWC3 controller did not power off. because the connection status
> is incorrect, so we also need clear DCTL.RUN_STOP bit for disable connect
^ to ^ ing
> when do core soft reset.
^ ing
> Fixes: f59dcab176293b6 ("usb: dwc3: core: improve reset sequence")
> Signed-off-by: Dejin Zheng
[...]
MBR, Sergei
[PATCH v2 1/2] powerpc/44x: Don't support 440 when CONFIG_PPC_47x is set
As stated in platform/44x/Kconfig, CONFIG_PPC_47x is not
compatible with 440 and 460 variants.
This is confirmed in asm/cache.h as L1_CACHE_SHIFT is different
for 47x, meaning a kernel built for 47x will not run correctly
on a 440.
In cputable, opt out all 440 and 460 variants when CONFIG_PPC_47x
is set. Also add a default match dedicated to 470.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/cputable.h | 9 +
arch/powerpc/include/asm/mmu.h | 7 +++
arch/powerpc/kernel/cputable.c | 29 +
3 files changed, 29 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index d88bcb79f16d..4a0ddf66bd4a 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -523,11 +523,10 @@ enum {
#ifdef CONFIG_40x
CPU_FTRS_40X |
#endif
-#ifdef CONFIG_44x
- CPU_FTRS_44X | CPU_FTRS_440x6 |
-#endif
#ifdef CONFIG_PPC_47x
CPU_FTRS_47X | CPU_FTR_476_DD2 |
+#elif defined(CONFIG_44x)
+ CPU_FTRS_44X | CPU_FTRS_440x6 |
#endif
#ifdef CONFIG_E200
CPU_FTRS_E200 |
@@ -596,7 +595,9 @@ enum {
#ifdef CONFIG_40x
CPU_FTRS_40X &
#endif
-#ifdef CONFIG_44x
+#ifdef CONFIG_PPC_47x
+ CPU_FTRS_47X &
+#elif defined(CONFIG_44x)
CPU_FTRS_44X & CPU_FTRS_440x6 &
#endif
#ifdef CONFIG_E200
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index a1769c0426f2..bf5d3b5291f1 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -162,15 +162,14 @@ enum {
#ifdef CONFIG_40x
MMU_FTR_TYPE_40x |
#endif
-#ifdef CONFIG_44x
+#ifdef CONFIG_PPC_47x
+ MMU_FTR_TYPE_47x | MMU_FTR_USE_TLBIVAX_BCAST |
MMU_FTR_LOCK_BCAST_INVAL |
+#elif defined(CONFIG_44x)
MMU_FTR_TYPE_44x |
#endif
#if defined(CONFIG_E200) || defined(CONFIG_E500)
MMU_FTR_TYPE_FSL_E | MMU_FTR_BIG_PHYS | MMU_FTR_USE_TLBILX |
#endif
-#ifdef CONFIG_PPC_47x
- MMU_FTR_TYPE_47x | MMU_FTR_USE_TLBIVAX_BCAST |
MMU_FTR_LOCK_BCAST_INVAL |
-#endif
#ifdef CONFIG_PPC_BOOK3S_32
MMU_FTR_USE_HIGH_BATS |
#endif
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 492c0b36aff6..cf80e6c8ed5e 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1533,6 +1533,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
#endif /* CONFIG_40x */
#ifdef CONFIG_44x
+#ifndef CONFIG_PPC_47x
{
.pvr_mask = 0xffff,
.pvr_value = 0x4850,
@@ -1815,7 +1816,19 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_440A,
.platform = "ppc440",
},
-#ifdef CONFIG_PPC_47x
+ { /* default match */
+ .pvr_mask = 0x,
+ .pvr_value = 0x,
+ .cpu_name = "(generic 44x PPC)",
+ .cpu_features = CPU_FTRS_44X,
+ .cpu_user_features = COMMON_USER_BOOKE,
+ .mmu_features = MMU_FTR_TYPE_44x,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .machine_check = machine_check_4xx,
+ .platform = "ppc440",
+ }
+#else /* CONFIG_PPC_47x */
{ /* 476 DD2 core */
.pvr_mask = 0x,
.pvr_value = 0x11a52080,
@@ -1872,19 +1885,19 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_47x,
.platform = "ppc470",
},
-#endif /* CONFIG_PPC_47x */
{ /* default match */
.pvr_mask = 0x,
.pvr_value = 0x,
- .cpu_name = "(generic 44x PPC)",
- .cpu_features = CPU_FTRS_44X,
+ .cpu_name = "(generic 47x PPC)",
+ .cpu_features = CPU_FTRS_47X,
.cpu_user_features = COMMON_USER_BOOKE,
- .mmu_features = MMU_FTR_TYPE_44x,
+ .mmu_features = MMU_FTR_TYPE_47x,
.icache_bsize = 32,
- .dcache_bsize = 32,
- .machine_check = machine_check_4xx,
- .platform = "ppc440",
+ .dcache_bsize = 128,
+ .machine_check = machine_check_47x,
+ .platform = "ppc470",
}
+#endif /* CONFIG_PPC_47x */
#endif /* CONFIG_44x */
#ifdef CONFIG_E200
{ /* e200z5 */
--
2.25.0
Re: [PATCH v2] arm64: dts: allwinner: beelink-gs1: Update LED power node
HI Maxime,
On Mon, 12 Oct 2020 at 13:22, Maxime Ripard wrote:
>
> Hi!
>
> On Sun, Oct 11, 2020 at 11:22:37PM +0200, Clément Péron wrote:
> > Beelink GS1 LED trigger a warning when running dtbs_check.
> >
> > Update the node with a valid pattern property.
> >
> > Also add the function and the color of the LED and drop the
> > label which is deprecated.
> >
> > Signed-off-by: Clément Péron
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> > b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> > index 3f7ceeb1a767..a364cb4e5b3f 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> > @@ -7,6 +7,7 @@
> > #include "sun50i-h6-cpu-opp.dtsi"
> >
> > #include
> > +#include
> >
> > / {
> > model = "Beelink GS1";
> > @@ -43,8 +44,9 @@ ext_osc32k: ext_osc32k_clk {
> > leds {
> > compatible = "gpio-leds";
> >
> > - power {
> > - label = "beelink:white:power";
> > + led-0 {
> > + function = LED_FUNCTION_POWER;
> > + color = ;
> > gpios = <_pio 0 4 GPIO_ACTIVE_HIGH>; /* PL4 */
> > default-state = "on";
> > };
>
> Doesn't that also change the sysfs file that LED is exposed to the userspace
> with?
Indeed the previous led sysfs:
/sys/class/leds/beelink:white:power/
is now
/sys/class/leds/white:power/
Do you want me to keep the label property to avoid this sysfs change ?
Regards,
Clement
>
> Maxime
[PATCH v2 2/2] powerpc/44x: Don't support 47x code and non 47x code at the same time
440/460 variants and 470 variants are not compatible, no need to make code supporting both and using MMU features. Just use CONFIG_PPC_47x to decide what to build. Signed-off-by: Christophe Leroy --- v2: Move outside #ifdef CONFIG_PPC_47x a label "1:" used by 44x --- arch/powerpc/kernel/entry_32.S | 11 +++ arch/powerpc/mm/nohash/tlb_low.S | 29 +++-- 2 files changed, 10 insertions(+), 30 deletions(-) diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S index 8cdc8bcde703..a425360deabb 100644 --- a/arch/powerpc/kernel/entry_32.S +++ b/arch/powerpc/kernel/entry_32.S @@ -439,15 +439,13 @@ syscall_exit_cont: andis. r10,r0,DBCR0_IDM@h bnel- load_dbcr0 #endif -#ifdef CONFIG_44x -BEGIN_MMU_FTR_SECTION +#ifdef CONFIG_PPC_47x lis r4,icache_44x_need_flush@ha lwz r5,icache_44x_need_flush@l(r4) cmplwi cr0,r5,0 bne-2f +#endif /* CONFIG_PPC_47x */ 1: -END_MMU_FTR_SECTION_IFCLR(MMU_FTR_TYPE_47x) -#endif /* CONFIG_44x */ BEGIN_FTR_SECTION lwarx r7,0,r1 END_FTR_SECTION_IFSET(CPU_FTR_NEED_PAIRED_STWCX) @@ -948,10 +946,7 @@ restore_kuap: /* interrupts are hard-disabled at this point */ restore: -#ifdef CONFIG_44x -BEGIN_MMU_FTR_SECTION - b 1f -END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x) +#if defined(CONFIG_44x) && !defined(CONFIG_PPC_47x) lis r4,icache_44x_need_flush@ha lwz r5,icache_44x_need_flush@l(r4) cmplwi cr0,r5,0 diff --git a/arch/powerpc/mm/nohash/tlb_low.S b/arch/powerpc/mm/nohash/tlb_low.S index eaeee402f96e..68797e072f55 100644 --- a/arch/powerpc/mm/nohash/tlb_low.S +++ b/arch/powerpc/mm/nohash/tlb_low.S @@ -92,36 +92,25 @@ _GLOBAL(__tlbil_va) tlbsx. r6,0,r3 bne 10f sync -BEGIN_MMU_FTR_SECTION - b 2f -END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x) +#ifndef CONFIG_PPC_47x /* On 440 There are only 64 TLB entries, so r3 < 64, which means bit * 22, is clear. Since 22 is the V bit in the TLB_PAGEID, loading this * value will invalidate the TLB entry. */ tlbwe r6,r6,PPC44x_TLB_PAGEID - isync -10:wrtee r10 - blr -2: -#ifdef CONFIG_PPC_47x +#else orisr7,r6,0x8000/* specify way explicitly */ clrrwi r4,r3,12/* get an EPN for the hashing with V = 0 */ ori r4,r4,PPC47x_TLBE_SIZE tlbwe r4,r7,0 /* write it */ +#endif /* !CONFIG_PPC_47x */ isync - wrtee r10 +10:wrtee r10 blr -#else /* CONFIG_PPC_47x */ -1: trap - EMIT_BUG_ENTRY 1b,__FILE__,__LINE__,0; -#endif /* !CONFIG_PPC_47x */ _GLOBAL(_tlbil_all) _GLOBAL(_tlbil_pid) -BEGIN_MMU_FTR_SECTION - b 2f -END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x) +#ifndef CONFIG_PPC_47x li r3,0 sync @@ -136,8 +125,7 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x) isync blr -2: -#ifdef CONFIG_PPC_47x +#else /* 476 variant. There's not simple way to do this, hopefully we'll * try to limit the amount of such full invalidates */ @@ -179,11 +167,8 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x) b 1b /* Then loop */ 1: isync /* Sync shadows */ wrtee r11 -#else /* CONFIG_PPC_47x */ -1: trap - EMIT_BUG_ENTRY 1b,__FILE__,__LINE__,0; -#endif /* !CONFIG_PPC_47x */ blr +#endif /* !CONFIG_PPC_47x */ #ifdef CONFIG_PPC_47x -- 2.25.0
[PATCH] arm64: dts: allwinner: beelink-gs1: Enable both RGMII RX/TX delay
Before the commit:
net: phy: realtek: fix rtl8211e rx/tx delay config
The software overwrite for RX/TX delays of the RTL8211e were not
working properly and the Beelink GS1 had both RX/TX delay of RGMII
interface set using pull-up on the TXDLY and RXDLY pins.
Now that these delays are working properly they overwrite the HW
config and set this to 'rgmii' meaning no delay on both RX/TX.
This makes the ethernet of this board not working anymore.
Set the phy-mode to 'rgmii-id' meaning RGMII with RX/TX delays
in the device-tree to keep the correct configuration.
Fixes: 089bee8dd119 ("arm64: dts: allwinner: h6: Introduce Beelink GS1 board")
Signed-off-by: Clément Péron
---
arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
index a364cb4e5b3f..6ab53860e447 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
@@ -99,7 +99,7 @@ {
{
pinctrl-names = "default";
pinctrl-0 = <_rgmii_pins>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
phy-handle = <_rgmii_phy>;
phy-supply = <_aldo2>;
status = "okay";
--
2.25.1
Re: Remove __napi_schedule_irqoff?
On Sun, 18 Oct 2020 10:20:41 +0200 Heiner Kallweit wrote:
> >> Otherwise a non-solution could be to make IRQ_FORCED_THREADING
> >> configurable.
> >
> > I have to say I do not understand why we want to defer to a thread the
> > hard IRQ that we use in NAPI model.
> >
> Seems like the current forced threading comes with the big hammer and
> thread-ifies all hard irq's. To avoid this all NAPI network drivers
> would have to request the interrupt with IRQF_NO_THREAD.
Right, it'd work for some drivers. Other drivers try to take spin locks
in their IRQ handlers.
What gave me a pause was that we have a busy loop in napi_schedule_prep:
bool napi_schedule_prep(struct napi_struct *n)
{
unsigned long val, new;
do {
val = READ_ONCE(n->state);
if (unlikely(val & NAPIF_STATE_DISABLE))
return false;
new = val | NAPIF_STATE_SCHED;
/* Sets STATE_MISSED bit if STATE_SCHED was already set
* This was suggested by Alexander Duyck, as compiler
* emits better code than :
* if (val & NAPIF_STATE_SCHED)
* new |= NAPIF_STATE_MISSED;
*/
new |= (val & NAPIF_STATE_SCHED) / NAPIF_STATE_SCHED *
NAPIF_STATE_MISSED;
} while (cmpxchg(>state, val, new) != val);
return !(val & NAPIF_STATE_SCHED);
}
Dunno how acceptable this is to run in an IRQ handler on RT..
Re: [PATCH] iio: adc: mediatek: fix unset field
Hi Jonathan,
On Sun, Oct 18, 2020 at 12:07 PM Jonathan Cameron wrote:
>
> On Tue, 13 Oct 2020 17:37:12 +0200
> Matthias Brugger wrote:
>
> > On 12/10/2020 21:46, Fabien Parent wrote:
> > > dev_comp field is used in a couple of places but it is never set. This
> > > results in kernel oops when dereferencing a NULL pointer. Set the
> > > `dev_comp` field correctly in the probe function.
> > >
> > > Fixes: 6d97024dce23 ("iio: adc: mediatek: mt6577-auxadc, add mt6765
> > > support")
> > >
> > > Signed-off-by: Fabien Parent
> >
> > Ouch.
> >
> > Reviewed-by: Matthias Brugger
> >
> > > ---
> > > drivers/iio/adc/mt6577_auxadc.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/iio/adc/mt6577_auxadc.c
> > > b/drivers/iio/adc/mt6577_auxadc.c
> > > index ac415cb089cd..7bd48377cd79 100644
> > > --- a/drivers/iio/adc/mt6577_auxadc.c
> > > +++ b/drivers/iio/adc/mt6577_auxadc.c
> > > @@ -276,6 +276,8 @@ static int mt6577_auxadc_probe(struct platform_device
> > > *pdev)
> > > goto err_disable_clk;
> > > }
> > >
> > > + adc_dev->dev_comp = of_device_get_match_data(>dev);
> > > +
>
> Could we switch this to device_get_match_data(>dev)?
>
> Whilst is unlikely this driver will used in a platform using ACPI, there
> is nothing inside the driver itself preventing this (which is good as no
> reason to do so!) My main motivation for this is to reduce the chances
> of cut and paste of the of_* functions in future driver.
>
> Also switch the headers to linux/property.h and linux/mod_devicetable.h
> to more tightly reflect what we are using in the driver.
I applied these changes in v2.
>
> Thanks,
>
> Jonathan
>
> > > mutex_init(_dev->lock);
> > >
> > > mt6577_auxadc_mod_reg(adc_dev->reg_base + MT6577_AUXADC_MISC,
> > >
>
[PATCH v2] iio: adc: mediatek: fix unset field
dev_comp field is used in a couple of places but it is never set. This
results in kernel oops when dereferencing a NULL pointer. Set the
`dev_comp` field correctly in the probe function.
Fixes: 6d97024dce23 ("iio: adc: mediatek: mt6577-auxadc, add mt6765 support")
Signed-off-by: Fabien Parent
---
Changelog:
V2:
* s/of_device_get_match_data/device_get_match_data
* include mod_devicetable.h and property.h instead of of_*.h headers
drivers/iio/adc/mt6577_auxadc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/adc/mt6577_auxadc.c b/drivers/iio/adc/mt6577_auxadc.c
index ac415cb089cd..79c1dd68b909 100644
--- a/drivers/iio/adc/mt6577_auxadc.c
+++ b/drivers/iio/adc/mt6577_auxadc.c
@@ -9,9 +9,9 @@
#include
#include
#include
-#include
-#include
+#include
#include
+#include
#include
#include
#include
@@ -276,6 +276,8 @@ static int mt6577_auxadc_probe(struct platform_device *pdev)
goto err_disable_clk;
}
+ adc_dev->dev_comp = device_get_match_data(>dev);
+
mutex_init(_dev->lock);
mt6577_auxadc_mod_reg(adc_dev->reg_base + MT6577_AUXADC_MISC,
--
2.28.0
[PATCH v2 2/4] scatterlist: add sgl_copy_sgl() function
Both the SCSI and NVMe subsystems receive user data from the block
layer in scatterlist_s (aka scatter gather lists (sgl) which are
often arrays). If drivers in those subsystems represent storage
(e.g. a ramdisk) or cache "hot" user data then they may also
choose to use scatterlist_s. Currently there are no sgl to sgl
operations in the kernel. Start with a copy.
Signed-off-by: Douglas Gilbert
---
include/linux/scatterlist.h | 4 ++
lib/scatterlist.c | 74 +
2 files changed, 78 insertions(+)
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 80178afc2a4a..6649414c0749 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -321,6 +321,10 @@ size_t sg_pcopy_to_buffer(struct scatterlist *sgl,
unsigned int nents,
size_t sg_zero_buffer(struct scatterlist *sgl, unsigned int nents,
size_t buflen, off_t skip);
+size_t sgl_copy_sgl(struct scatterlist *d_sgl, unsigned int d_nents, off_t
d_skip,
+ struct scatterlist *s_sgl, unsigned int s_nents, off_t
s_skip,
+ size_t n_bytes);
+
/*
* Maximum number of entries that will be allocated in one piece, if
* a list larger than this is required then chaining will be utilized.
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index d5770e7f1030..a0a86059c10e 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -974,3 +974,77 @@ size_t sg_zero_buffer(struct scatterlist *sgl, unsigned
int nents,
return offset;
}
EXPORT_SYMBOL(sg_zero_buffer);
+
+/**
+ * sgl_copy_sgl - Copy over a destination sgl from a source sgl
+ * @d_sgl: Destination sgl
+ * @d_nents:Number of SG entries in destination sgl
+ * @d_skip: Number of bytes to skip in destination before starting
+ * @s_sgl: Source sgl
+ * @s_nents:Number of SG entries in source sgl
+ * @s_skip: Number of bytes to skip in source before starting
+ * @n_bytes:The (maximum) number of bytes to copy
+ *
+ * Returns the number of copied bytes.
+ *
+ * Notes:
+ * Destination arguments appear before the source arguments, as with
memcpy().
+ *
+ * Stops copying if either d_sgl, s_sgl or n_bytes is exhausted.
+ *
+ * Since memcpy() is used, overlapping copies (where d_sgl and s_sgl belong
+ * to the same sgl and the copy regions overlap) are not supported.
+ *
+ * Large copies are broken into copy segments whose sizes may vary. Those
+ * copy segment sizes are chosen by the min3() statement in the code below.
+ * Since SG_MITER_ATOMIC is used for both sides, each copy segment is started
+ * with kmap_atomic() [in sg_miter_next()] and completed with kunmap_atomic()
+ * [in sg_miter_stop()]. This means pre-emption is inhibited for relatively
+ * short periods even in very large copies.
+ *
+ * If d_skip is large, potentially spanning multiple d_nents then some
+ * integer arithmetic to adjust d_sgl may improve performance. For example
+ * if d_sgl is built using sgl_alloc_order(chainable=false) then the sgl
+ * will be an array with equally sized segments facilitating that
+ * arithmetic. The suggestion applies to s_skip, s_sgl and s_nents as well.
+ *
+ **/
+size_t sgl_copy_sgl(struct scatterlist *d_sgl, unsigned int d_nents, off_t
d_skip,
+ struct scatterlist *s_sgl, unsigned int s_nents, off_t
s_skip,
+ size_t n_bytes)
+{
+ size_t len;
+ size_t offset = 0;
+ struct sg_mapping_iter d_iter, s_iter;
+
+ if (n_bytes == 0)
+ return 0;
+ sg_miter_start(_iter, s_sgl, s_nents, SG_MITER_ATOMIC |
SG_MITER_FROM_SG);
+ sg_miter_start(_iter, d_sgl, d_nents, SG_MITER_ATOMIC |
SG_MITER_TO_SG);
+ if (!sg_miter_skip(_iter, s_skip))
+ goto fini;
+ if (!sg_miter_skip(_iter, d_skip))
+ goto fini;
+
+ while (offset < n_bytes) {
+ if (!sg_miter_next(_iter))
+ break;
+ if (!sg_miter_next(_iter))
+ break;
+ len = min3(d_iter.length, s_iter.length, n_bytes - offset);
+
+ memcpy(d_iter.addr, s_iter.addr, len);
+ offset += len;
+ /* LIFO order (stop d_iter before s_iter) needed with
SG_MITER_ATOMIC */
+ d_iter.consumed = len;
+ sg_miter_stop(_iter);
+ s_iter.consumed = len;
+ sg_miter_stop(_iter);
+ }
+fini:
+ sg_miter_stop(_iter);
+ sg_miter_stop(_iter);
+ return offset;
+}
+EXPORT_SYMBOL(sgl_copy_sgl);
+
--
2.25.1
[PATCH v2 0/4] scatterlist: add new capabilities
Scatter-gather lists (sgl_s) are frequently used as data carriers in the block layer. For example the SCSI and NVMe subsystems interchange data with the block layer using sgl_s. The sgl API is declared in The author has extended these transient sgl use cases to a store (i.e. a ramdisk) in the scsi_debug driver. Other new potential uses of sgl_s could be for caches. When this extra step is taken, the need to copy between sgl_s becomes apparent. The patchset adds sgl_copy_sgl() and two other sgl operations. The existing sgl_alloc_order() function can be seen as a replacement for vmalloc() for large, long-term allocations. For what seems like no good reason, sgl_alloc_order() currently restricts its total allocation to less than or equal to 4 GiB. vmalloc() has no such restriction. Changes since v1 [posted 20201016]: - Bodo Stroesser pointed out a problem with the nesting of kmap_atomic() [called via sg_miter_next()] and kunmap_atomic() calls [called via sg_miter_stop()] and proposed a solution that simplifies the previous code. - the new implementation of the three functions has shorter periods when pre-emption is disabled (but has more them). This should make operations on large sgl_s more pre-emption "friendly" with a relatively small performance hit. - sgl_memset return type changed from void to size_t and is the number of bytes actually (over)written. That number is needed anyway internally so may as well return it as it may be useful to the caller. This patchset is against lk 5.9.0 Douglas Gilbert (4): sgl_alloc_order: remove 4 GiB limit, sgl_free() warning scatterlist: add sgl_copy_sgl() function scatterlist: add sgl_compare_sgl() function scatterlist: add sgl_memset() include/linux/scatterlist.h | 12 +++ lib/scatterlist.c | 204 +++- 2 files changed, 213 insertions(+), 3 deletions(-) -- 2.25.1 *** BLURB HERE *** Douglas Gilbert (4): sgl_alloc_order: remove 4 GiB limit, sgl_free() warning scatterlist: add sgl_copy_sgl() function scatterlist: add sgl_compare_sgl() function scatterlist: add sgl_memset() include/linux/scatterlist.h | 12 +++ lib/scatterlist.c | 185 +++- 2 files changed, 194 insertions(+), 3 deletions(-) -- 2.25.1
[PATCH v2 4/4] scatterlist: add sgl_memset()
The existing sg_zero_buffer() function is a bit restrictive.
For example protection information (PI) blocks are usually
initialized to 0xff bytes. As its name suggests sgl_memset()
is modelled on memset(). One difference is the type of the
val argument which is u8 rather than int. Plus it returns
the number of bytes (over)written.
Signed-off-by: Douglas Gilbert
---
include/linux/scatterlist.h | 3 +++
lib/scatterlist.c | 54 ++---
2 files changed, 54 insertions(+), 3 deletions(-)
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index ae260dc5fedb..a40012c8a4e6 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -329,6 +329,9 @@ bool sgl_compare_sgl(struct scatterlist *x_sgl, unsigned
int x_nents, off_t x_sk
struct scatterlist *y_sgl, unsigned int y_nents, off_t
y_skip,
size_t n_bytes);
+size_t sgl_memset(struct scatterlist *sgl, unsigned int nents, off_t skip,
+ u8 val, size_t n_bytes);
+
/*
* Maximum number of entries that will be allocated in one piece, if
* a list larger than this is required then chaining will be utilized.
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index d910776a4c96..a704039ab54d 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -985,7 +985,8 @@ EXPORT_SYMBOL(sg_zero_buffer);
* @s_skip: Number of bytes to skip in source before starting
* @n_bytes:The (maximum) number of bytes to copy
*
- * Returns the number of copied bytes.
+ * Returns:
+ * The number of copied bytes.
*
* Notes:
* Destination arguments appear before the source arguments, as with
memcpy().
@@ -1058,8 +1059,9 @@ EXPORT_SYMBOL(sgl_copy_sgl);
* @y_skip: Number of bytes to skip in y (right) before starting
* @n_bytes:The (maximum) number of bytes to compare
*
- * Returns true if x and y compare equal before x, y or n_bytes is exhausted.
- * Otherwise on a miscompare, returns false (and stops comparing).
+ * Returns:
+ * true if x and y compare equal before x, y or n_bytes is exhausted.
+ * Otherwise on a miscompare, returns false (and stops comparing).
*
* Notes:
* x and y are symmetrical: they can be swapped and the result is the same.
@@ -1108,3 +1110,49 @@ bool sgl_compare_sgl(struct scatterlist *x_sgl, unsigned
int x_nents, off_t x_sk
return equ;
}
EXPORT_SYMBOL(sgl_compare_sgl);
+
+/**
+ * sgl_memset - set byte 'val' up to n_bytes times on SG list
+ * @sgl:The SG list
+ * @nents: Number of SG entries in sgl
+ * @skip: Number of bytes to skip before starting
+ * @val:byte value to write to sgl
+ * @n_bytes:The (maximum) number of bytes to modify
+ *
+ * Returns:
+ * The number of bytes written.
+ *
+ * Notes:
+ * Stops writing if either sgl or n_bytes is exhausted. If n_bytes is
+ * set SIZE_MAX then val will be written to each byte until the end
+ * of sgl.
+ *
+ * The notes in sgl_copy_sgl() about large sgl_s _applies here as well.
+ *
+ **/
+size_t sgl_memset(struct scatterlist *sgl, unsigned int nents, off_t skip,
+ u8 val, size_t n_bytes)
+{
+ size_t offset = 0;
+ size_t len;
+ struct sg_mapping_iter miter;
+
+ if (n_bytes == 0)
+ return 0;
+ sg_miter_start(, sgl, nents, SG_MITER_ATOMIC | SG_MITER_TO_SG);
+ if (!sg_miter_skip(, skip))
+ goto fini;
+
+ while ((offset < n_bytes) && sg_miter_next()) {
+ len = min(miter.length, n_bytes - offset);
+ memset(miter.addr, val, len);
+ offset += len;
+ miter.consumed = len;
+ sg_miter_stop();
+ }
+fini:
+ sg_miter_stop();
+ return offset;
+}
+EXPORT_SYMBOL(sgl_memset);
+
--
2.25.1
[PATCH v2 1/4] sgl_alloc_order: remove 4 GiB limit, sgl_free() warning
This patch removes a check done by sgl_alloc_order() before it starts
any allocations. The comment before the removed code says: "Check for
integer overflow" arguably gives a false sense of security. The right
hand side of the expression in the condition is resolved as u32 so
cannot exceed UINT32_MAX (4 GiB) which means 'length' cannot exceed
that amount. If that was the intention then the comment above it
could be dropped and the condition rewritten more clearly as:
if (length > UINT32_MAX) <>;
The author's intention is to use sgl_alloc_order() to replace
vmalloc(unsigned long) for a large allocation (debug ramdisk).
vmalloc has no limit at 4 GiB so its seems unreasonable that:
sgl_alloc_order(unsigned long long length, )
does. sgl_s made with sgl_alloc_order(chainable=false) have equally
sized segments placed in a scatter gather array. That allows O(1)
navigation around a big sgl using some simple integer maths.
Having previously sent a patch to fix a memory leak in
sg_alloc_order() take the opportunity to put a one line comment above
sgl_free()'s declaration that it is not suitable when order > 0 . The
mis-use of sgl_free() when order > 0 was the reason for the memory
leak. The other users of sgl_alloc_order() in the kernel where
checked and found to handle free-ing properly.
Signed-off-by: Douglas Gilbert
---
include/linux/scatterlist.h | 1 +
lib/scatterlist.c | 3 ---
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 45cf7b69d852..80178afc2a4a 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -302,6 +302,7 @@ struct scatterlist *sgl_alloc(unsigned long long length,
gfp_t gfp,
unsigned int *nent_p);
void sgl_free_n_order(struct scatterlist *sgl, int nents, int order);
void sgl_free_order(struct scatterlist *sgl, int order);
+/* Only use sgl_free() when order is 0 */
void sgl_free(struct scatterlist *sgl);
#endif /* CONFIG_SGL_ALLOC */
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index c448642e0f78..d5770e7f1030 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -493,9 +493,6 @@ struct scatterlist *sgl_alloc_order(unsigned long long
length,
u32 elem_len;
nent = round_up(length, PAGE_SIZE << order) >> (PAGE_SHIFT + order);
- /* Check for integer overflow */
- if (length > (nent << (PAGE_SHIFT + order)))
- return NULL;
nalloc = nent;
if (chainable) {
/* Check for integer overflow */
--
2.25.1
[PATCH v2 3/4] scatterlist: add sgl_compare_sgl() function
After enabling copies between scatter gather lists (sgl_s),
another storage related operation is to compare two sgl_s.
This new function is modelled on NVMe's Compare command and
the SCSI VERIFY(BYTCHK=1) command. Like memcmp() this function
returns false on the first miscompare and stop comparing.
Signed-off-by: Douglas Gilbert
---
include/linux/scatterlist.h | 4 +++
lib/scatterlist.c | 60 +
2 files changed, 64 insertions(+)
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 6649414c0749..ae260dc5fedb 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -325,6 +325,10 @@ size_t sgl_copy_sgl(struct scatterlist *d_sgl, unsigned
int d_nents, off_t d_ski
struct scatterlist *s_sgl, unsigned int s_nents, off_t
s_skip,
size_t n_bytes);
+bool sgl_compare_sgl(struct scatterlist *x_sgl, unsigned int x_nents, off_t
x_skip,
+struct scatterlist *y_sgl, unsigned int y_nents, off_t
y_skip,
+size_t n_bytes);
+
/*
* Maximum number of entries that will be allocated in one piece, if
* a list larger than this is required then chaining will be utilized.
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index a0a86059c10e..d910776a4c96 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -1048,3 +1048,63 @@ size_t sgl_copy_sgl(struct scatterlist *d_sgl, unsigned
int d_nents, off_t d_ski
}
EXPORT_SYMBOL(sgl_copy_sgl);
+/**
+ * sgl_compare_sgl - Compare x and y (both sgl_s)
+ * @x_sgl: x (left) sgl
+ * @x_nents:Number of SG entries in x (left) sgl
+ * @x_skip: Number of bytes to skip in x (left) before starting
+ * @y_sgl: y (right) sgl
+ * @y_nents:Number of SG entries in y (right) sgl
+ * @y_skip: Number of bytes to skip in y (right) before starting
+ * @n_bytes:The (maximum) number of bytes to compare
+ *
+ * Returns true if x and y compare equal before x, y or n_bytes is exhausted.
+ * Otherwise on a miscompare, returns false (and stops comparing).
+ *
+ * Notes:
+ * x and y are symmetrical: they can be swapped and the result is the same.
+ *
+ * Implementation is based on memcmp(). x and y segments may overlap.
+ *
+ * The notes in sgl_copy_sgl() about large sgl_s _applies here as well.
+ *
+ **/
+bool sgl_compare_sgl(struct scatterlist *x_sgl, unsigned int x_nents, off_t
x_skip,
+struct scatterlist *y_sgl, unsigned int y_nents, off_t
y_skip,
+size_t n_bytes)
+{
+ bool equ = true;
+ size_t len;
+ size_t offset = 0;
+ struct sg_mapping_iter x_iter, y_iter;
+
+ if (n_bytes == 0)
+ return true;
+ sg_miter_start(_iter, x_sgl, x_nents, SG_MITER_ATOMIC |
SG_MITER_FROM_SG);
+ sg_miter_start(_iter, y_sgl, y_nents, SG_MITER_ATOMIC |
SG_MITER_FROM_SG);
+ if (!sg_miter_skip(_iter, x_skip))
+ goto fini;
+ if (!sg_miter_skip(_iter, y_skip))
+ goto fini;
+
+ while (equ && offset < n_bytes) {
+ if (!sg_miter_next(_iter))
+ break;
+ if (!sg_miter_next(_iter))
+ break;
+ len = min3(x_iter.length, y_iter.length, n_bytes - offset);
+
+ equ = !memcmp(x_iter.addr, y_iter.addr, len);
+ offset += len;
+ /* LIFO order is important when SG_MITER_ATOMIC is used */
+ y_iter.consumed = len;
+ sg_miter_stop(_iter);
+ x_iter.consumed = len;
+ sg_miter_stop(_iter);
+ }
+fini:
+ sg_miter_stop(_iter);
+ sg_miter_stop(_iter);
+ return equ;
+}
+EXPORT_SYMBOL(sgl_compare_sgl);
--
2.25.1
Fwd: [WARNING AND ERROR] may be system slow and audio and video breaking
--- Begin Message --- hello, System was slow and audio and video was breaking. I was compiling a kernel and also played a youtube video in firefox and maybe evolution. meminfo.txt and lscpu.txt files are attached. The following is a part from "dmesg -l warn" ---x--x-x smpboot: Scheduler frequency invariance went wobbly, disabling! [ 1112.592866] unchecked MSR access error: RDMSR from 0x123 at rIP: 0xb5c9a184 (native_read_msr+0x4/0x30) [ 1112.592869] Call Trace: [ 1112.592876] update_srbds_msr+0x6f/0xb0 [ 1112.592880] smp_store_cpu_info+0x8e/0xb0 [ 1112.592883] start_secondary+0x93/0x200 [ 1112.592887] ? set_cpu_sibling_map+0xcb0/0xcb0 [ 1112.592891] secondary_startup_64+0xa4/0xb0 [ 1112.592898] unchecked MSR access error: WRMSR to 0x123 (tried to write 0x) at rIP: 0xb5c9a264 (native_write_msr+0x4/0x20) [ 1112.592899] Call Trace: [ 1112.592902] update_srbds_msr+0x98/0xb0 [ 1112.592904] smp_store_cpu_info+0x8e/0xb0 [ 1112.592907] start_secondary+0x93/0x200 [ 1112.592911] ? set_cpu_sibling_map+0xcb0/0xcb0 [ 1112.592914] secondary_startup_64+0xa4/0xb0 [ 2915.106879] show_signal: 6 callbacks suppressed [ 6089.209343] WARNING: stack going in the wrong direction? at i915_gem_close_object+0x2fb/0x560 [i915] $ -x---xx Linux debian 5.9.1-rc1+ #4 SMP Fri Oct 16 16:48:04 IST 2020 x86_64 GNU/Linux GNU Make4.3 Binutils2.35.1 Util-linux 2.36 Mount 2.36 Bison 3.7.2 Flex2.6.4 Dynamic linker (ldd)2.30 Procps 3.3.16 Kbd 2.3.0 Console-tools 2.3.0 Sh-utils8.32 Udev246 Reported-by: Jeffrin Jose T MemTotal:6952576 kB MemFree: 299000 kB MemAvailable:2964748 kB Buffers: 169024 kB Cached: 3447336 kB SwapCached: 108 kB Active: 1996356 kB Inactive:3315820 kB Active(anon): 643748 kB Inactive(anon): 1950892 kB Active(file):1352608 kB Inactive(file): 1364928 kB Unevictable: 57668 kB Mlocked: 160 kB SwapTotal: 8263676 kB SwapFree:8261092 kB Dirty: 16632 kB Writeback: 0 kB AnonPages: 1736772 kB Mapped: 520572 kB Shmem:898760 kB KReclaimable: 264048 kB Slab:1045968 kB SReclaimable: 264048 kB SUnreclaim: 781920 kB KernelStack: 28320 kB PageTables:27856 kB NFS_Unstable: 0 kB Bounce:0 kB WritebackTmp: 0 kB CommitLimit:11739964 kB Committed_AS:7741848 kB VmallocTotal: 34359738367 kB VmallocUsed: 60544 kB VmallocChunk: 0 kB Percpu: 2672 kB HardwareCorrupted: 0 kB AnonHugePages:763904 kB ShmemHugePages:0 kB ShmemPmdMapped:0 kB FileHugePages: 0 kB FilePmdMapped: 0 kB HugePages_Total: 0 HugePages_Free:0 HugePages_Rsvd:0 HugePages_Surp:0 Hugepagesize: 2048 kB Hugetlb: 0 kB DirectMap4k: 891756 kB DirectMap2M: 7372800 kB DirectMap1G: 1048576 kB Architecture:x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 39 bits physical, 48 bits virtual CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 2 Core(s) per socket: 2 Socket(s): 1 NUMA node(s):1 Vendor ID: GenuineIntel CPU family: 6 Model: 142 Model name: Intel(R) Core(TM) i3-7020U CPU @ 2.30GHz Stepping:9 CPU MHz: 2299.999 CPU max MHz: 2300. CPU min MHz: 400. BogoMIPS:4599.93 Virtualization: VT-x L1d cache: 64 KiB L1i cache: 64 KiB L2 cache:512 KiB L3 cache:3 MiB NUMA node0 CPU(s): 0-3 Vulnerability Itlb multihit: KVM: Mitigation: VMX disabled Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable Vulnerability Mds: Mitigation; Clear CPU buffers; SMT vulnerable Vulnerability Meltdown: Mitigation; PTI Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp Vulnerability Spectre v1:Mitigation; usercopy/swapgs barriers and __user pointer sanitization Vulnerability Spectre v2:Mitigation; Full generic retpoline, IBPB conditional, IBRS_FW, STIBP conditional, RSB filling Vulnerability Srbds: Mitigation; Microcode
Re: [PATCH] lib/test_free_pages: Add basic progress indicators
On Sun, Oct 18, 2020 at 04:01:46PM +0100, Matthew Wilcox wrote:
> On Sun, Oct 18, 2020 at 04:39:27PM +0200, Geert Uytterhoeven wrote:
> > Hi Matthew,
> >
> > On Sun, Oct 18, 2020 at 4:25 PM Matthew Wilcox wrote:
> > > On Sun, Oct 18, 2020 at 04:04:45PM +0200, Geert Uytterhoeven wrote:
> > > > The test module to check that free_pages() does not leak memory does not
> > > > provide any feedback whatsoever its state or progress, but may take some
> > > > time on slow machines. Add the printing of messages upon starting each
> > > > phase of the test, and upon completion.
> > >
> > > It's not supposed to take a long time. Can you crank down that 1000 *
> >
> > It took 1m11s on ARAnyM, running on an i7-8700K.
> > Real hardware may even take longer.
>
> 71 seconds is clearly too long. 0.7 seconds would be fine, so 10 * 1000
> would be appropriate, but then that's only 320MB which might not be
> enough to notice on a modern machine.
>
> > > 1000 to something more appropriate?
> >
> > What would be a suitable value? You do want to see it "leak gigabytes
> > of memory and probably OOM your system" if something's wrong,
> > so decreasing the value a lot may not be a good idea?
> >
> > Regardless, if it OOMs, I think you do want to see this happens
> > while running this test.
>
> How about scaling with the amount of memory on the machine?
>
> This might cause problems on machines with terabytes of memory.
> Maybe we should cap it at a terabyte?
On ARAnyM wih 782 MBytes of RAM running on i7-8650U it takes ~1.75
seconds.
Still, I think adding some verbosity to the test wouldn't hurt ;-)
> diff --git a/lib/test_free_pages.c b/lib/test_free_pages.c
> index 074e76bd76b2..aa18fa52290a 100644
> --- a/lib/test_free_pages.c
> +++ b/lib/test_free_pages.c
> @@ -9,11 +9,11 @@
> #include
> #include
>
> -static void test_free_pages(gfp_t gfp)
> +static void test_free_pages(gfp_t gfp, unsigned long totalram)
> {
> - unsigned int i;
> + unsigned long i, max = totalram / 8;
>
> - for (i = 0; i < 1000 * 1000; i++) {
> + for (i = 0; i < max; i++) {
> unsigned long addr = __get_free_pages(gfp, 3);
> struct page *page = virt_to_page(addr);
>
> @@ -26,8 +26,11 @@ static void test_free_pages(gfp_t gfp)
>
> static int m_in(void)
> {
> - test_free_pages(GFP_KERNEL);
> - test_free_pages(GFP_KERNEL | __GFP_COMP);
> + struct sysinfo si;
> +
> + si_meminfo();
> + test_free_pages(GFP_KERNEL, si.totalram);
> + test_free_pages(GFP_KERNEL | __GFP_COMP, si.totalram);
>
> return 0;
> }
--
Sincerely yours,
Mike.
Re: [GIT PULL] UBI and UBIFS fixes for 5.10
The pull request you sent on Sat, 17 Oct 2020 21:37:51 +0200 (CEST): > git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs.git > tags/for-linus-5.10-rc1-part2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/429731277dfd4b7940cff206dcde28b771b29210 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] uml updates for 5.10
The pull request you sent on Sat, 17 Oct 2020 22:59:47 +0200 (CEST): > git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git > tags/for-linus-5.10-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/9453b2d4694c2cb6c30d99e65d4a3deb09e94ac3 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] UBIFS updates for 5.10
The pull request you sent on Sat, 17 Oct 2020 21:37:40 +0200 (CEST): > git://git.kernel.org/pub/scm/linux/kernel/git/rw/ubifs.git > tags/for-linus-5.10-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a96fd1cc3ff3f9dd6f06140fc0b8c91342859450 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH 1/1] usb: serial: option: add Quectel EC200T module support
Add usb product id of the Quectel EC200T module.
Signed-off-by: septs
---
drivers/usb/serial/option.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 2a3bfd6f8..7e879233b 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -250,6 +250,7 @@ static void option_instat_callback(struct urb *urb);
#define QUECTEL_PRODUCT_EP06 0x0306
#define QUECTEL_PRODUCT_EM12 0x0512
#define QUECTEL_PRODUCT_RM500Q 0x0800
+#define QUECTEL_PRODUCT_EC200T 0x6026
#define CMOTECH_VENDOR_ID 0x16d8
#define CMOTECH_PRODUCT_6001 0x6001
@@ -1117,6 +1118,7 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID,
QUECTEL_PRODUCT_RM500Q, 0xff, 0, 0) },
{ USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID,
QUECTEL_PRODUCT_RM500Q, 0xff, 0xff, 0x10),
.driver_info = ZLP },
+ { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID,
QUECTEL_PRODUCT_EC200T, 0xff, 0, 0) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
--
2.25.1
On Sun, Oct 18, 2020, at 20:49, Greg Kroah-Hartman wrote:
> On Sun, Oct 18, 2020 at 06:51:11PM +0800, septs wrote:
> > Add usb product id of the Quectel EC200T module.
> > ---
> > drivers/usb/serial/option.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> > index 2a3bfd6f8..7e879233b 100644
> > --- a/drivers/usb/serial/option.c
> > +++ b/drivers/usb/serial/option.c
> > @@ -250,6 +250,7 @@ static void option_instat_callback(struct urb *urb);
> > #define QUECTEL_PRODUCT_EP06 0x0306
> > #define QUECTEL_PRODUCT_EM12 0x0512
> > #define QUECTEL_PRODUCT_RM500Q 0x0800
> > +#define QUECTEL_PRODUCT_EC200T 0x6026
> >
> > #define CMOTECH_VENDOR_ID 0x16d8
> > #define CMOTECH_PRODUCT_6001 0x6001
> > @@ -1117,6 +1118,7 @@ static const struct usb_device_id option_ids[] = {
> > { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID,
> > QUECTEL_PRODUCT_RM500Q, 0xff, 0, 0) },
> > { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID,
> > QUECTEL_PRODUCT_RM500Q, 0xff, 0xff, 0x10),
> > .driver_info = ZLP },
> > + { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID,
> > QUECTEL_PRODUCT_EC200T, 0xff, 0, 0) },
> >
> > { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
> > { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
> > --
> > 2.25.1
> >
>
> Hi,
>
> This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
> a patch that has triggered this response. He used to manually respond
> to these common problems, but in order to save his sanity (he kept
> writing the same thing over and over, yet to different people), I was
> created. Hopefully you will not take offence and will fix the problem
> in your patch and resubmit it so that it can be accepted into the Linux
> kernel tree.
>
> You are receiving this message because of the following common error(s)
> as indicated below:
>
> - Your patch does not have a Signed-off-by: line. Please read the
> kernel file, Documentation/SubmittingPatches and resend it after
> adding that line. Note, the line needs to be in the body of the
> email, before the patch, not at the bottom of the patch or in the
> email signature.
>
>
> - It looks like you did not use your "real" name for the patch on either
> the Signed-off-by: line, or the From: line (both of which have to
> match). Please read the kernel file, Documentation/SubmittingPatches
> for how to do this correctly.
>
> If you wish to discuss this problem further, or you have questions about
> how to resolve this issue, please feel free to respond to this email and
> Greg will reply once he has dug out from the pending patches received
> from other developers.
>
> thanks,
>
> greg k-h's patch email bot
>
[PATCH] docs/cpu-load: format the example code.
format the example code.
Signed-off-by: Hui Su
---
Documentation/admin-guide/cpu-load.rst | 63 ++
1 file changed, 33 insertions(+), 30 deletions(-)
diff --git a/Documentation/admin-guide/cpu-load.rst
b/Documentation/admin-guide/cpu-load.rst
index ebdecf864080..f3ada90e9ca8 100644
--- a/Documentation/admin-guide/cpu-load.rst
+++ b/Documentation/admin-guide/cpu-load.rst
@@ -61,43 +61,46 @@ will lead to quite erratic information inside
``/proc/stat``::
static volatile sig_atomic_t stop;
- static void sighandler (int signr)
+ static void sighandler(int signr)
{
- (void) signr;
- stop = 1;
+ (void) signr;
+ stop = 1;
}
+
static unsigned long hog (unsigned long niters)
{
- stop = 0;
- while (!stop && --niters);
- return niters;
+ stop = 0;
+ while (!stop && --niters);
+ return niters;
}
+
int main (void)
{
- int i;
- struct itimerval it = { .it_interval = { .tv_sec = 0, .tv_usec = 1 },
- .it_value = { .tv_sec = 0, .tv_usec = 1 } };
- sigset_t set;
- unsigned long v[HIST];
- double tmp = 0.0;
- unsigned long n;
- signal (SIGALRM, );
- setitimer (ITIMER_REAL, , NULL);
-
- hog (ULONG_MAX);
- for (i = 0; i < HIST; ++i) v[i] = ULONG_MAX - hog (ULONG_MAX);
- for (i = 0; i < HIST; ++i) tmp += v[i];
- tmp /= HIST;
- n = tmp - (tmp / 3.0);
-
- sigemptyset ();
- sigaddset (, SIGALRM);
-
- for (;;) {
- hog (n);
- sigwait (, );
- }
- return 0;
+ int i;
+ struct itimerval it = {
+ .it_interval = { .tv_sec = 0, .tv_usec = 1 },
+ .it_value= { .tv_sec = 0, .tv_usec = 1 } };
+ sigset_t set;
+ unsigned long v[HIST];
+ double tmp = 0.0;
+ unsigned long n;
+ signal(SIGALRM, );
+ setitimer(ITIMER_REAL, , NULL);
+
+ hog (ULONG_MAX);
+ for (i = 0; i < HIST; ++i) v[i] = ULONG_MAX - hog(ULONG_MAX);
+ for (i = 0; i < HIST; ++i) tmp += v[i];
+ tmp /= HIST;
+ n = tmp - (tmp / 3.0);
+
+ sigemptyset();
+ sigaddset(, SIGALRM);
+
+ for (;;) {
+ hog(n);
+ sigwait(, );
+ }
+ return 0;
}
--
2.25.1
Re: [PATCH v5 1/5] counter: Internalize sysfs interface code
On Wed, Oct 14, 2020 at 08:38:40PM -0500, David Lechner wrote:
> On 9/26/20 9:18 PM, William Breathitt Gray wrote:
> > +static ssize_t counter_comp_u8_store(struct device *dev,
> > +struct device_attribute *attr,
> > +const char *buf, size_t len)
> > +{
> > + const struct counter_attribute *const a = to_counter_attribute(attr);
> > + struct counter_device *const counter = dev_get_drvdata(dev);
> > + struct counter_count *const count = a->parent;
> > + struct counter_synapse *const synapse = a->comp.priv;
> > + const struct counter_available *const avail = a->comp.priv;
> > + int err;
> > + bool bool_data;
> > + u8 data;
> > +
> > + switch (a->comp.type) {
> > + case COUNTER_COMP_BOOL:
> > + err = kstrtobool(buf, _data);
> > + data = bool_data;
> > + break;
> > + case COUNTER_COMP_FUNCTION:
> > + err = find_in_string_array(, count->functions_list,
> > + count->num_functions, buf,
> > + counter_function_str);
> > + break;
> > + case COUNTER_COMP_SYNAPSE_ACTION:
> > + err = find_in_string_array(, synapse->actions_list,
> > + synapse->num_actions, buf,
> > + counter_synapse_action_str);
> > + break;
> > + case COUNTER_COMP_ENUM:
> > + err = __sysfs_match_string(avail->strs, avail->num_items, buf);
> > + data = err;
> > + break;
> > + case COUNTER_COMP_COUNT_MODE:
> > + err = find_in_string_array(, avail->enums,
> > + avail->num_items, buf,
> > + counter_count_mode_str);
> > + break;
> > + default:
> > + err = kstrtou8(buf, 0, );
> > + break;
> > + }
>
> In this function, return values are not always errors. So it would make
> sense to call the err variable ret instead and check for ret < 0 below.
>
> Setting enums to a value with index > 0 fails currently because of this.
Thank you for pointing this out, I'll fix this.
William Breathitt Gray
> > + if (err)
> > + return err;
> > +
> > + switch (a->scope) {
> > + case COUNTER_SCOPE_DEVICE:
> > + err = a->comp.device_u8_write(counter, data);
> > + break;
> > + case COUNTER_SCOPE_SIGNAL:
> > + err = a->comp.signal_u8_write(counter, a->parent, data);
> > + break;
> > + case COUNTER_SCOPE_COUNT:
> > + if (a->comp.type == COUNTER_COMP_SYNAPSE_ACTION)
> > + err = a->comp.action_write(counter, count, synapse,
> > + data);
> > + else
> > + err = a->comp.count_u8_write(counter, count, data);
> > + break;
> > + }
> > + if (err)
> > + return err;
> > +
> > + return len;
> > +}
>
signature.asc
Description: PGP signature
Re: [PATCH v5 3/5] counter: Add character device interface
On Wed, Oct 14, 2020 at 05:40:44PM -0500, David Lechner wrote:
> On 9/26/20 9:18 PM, William Breathitt Gray wrote:
> > +static ssize_t counter_chrdev_read(struct file *filp, char __user *buf,
> > + size_t len, loff_t *f_ps)
> > +{
> > + struct counter_device *const counter = filp->private_data;
> > + int err;
> > + unsigned long flags;
> > + unsigned int copied;
> > +
> > + if (len < sizeof(struct counter_event))
> > + return -EINVAL;
> > +
> > + do {
> > + if (kfifo_is_empty(>events)) {
> > + if (filp->f_flags & O_NONBLOCK)
> > + return -EAGAIN;
> > +
> > + err = wait_event_interruptible(counter->events_wait,
> > + !kfifo_is_empty(>events));
> > + if (err)
> > + return err;
> > + }
> > +
> > + raw_spin_lock_irqsave(>events_lock, flags);
> > + err = kfifo_to_user(>events, buf, len, );
> > + raw_spin_unlock_irqrestore(>events_lock, flags);
> > + if (err)
> > + return err;
> > + } while (!copied);
> > +
> > + return copied;
> > +}
>
> All other uses of kfifo_to_user() I saw use a mutex instead of spin
> lock. I don't see a reason for disabling interrupts here.
The Counter character device interface is special in this case because
counter->events could be accessed from an interrupt context. This is
possible if counter_push_event() is called for an interrupt (as is the
case for the 104_quad_8 driver). In this case, we can't use mutex
because we can't sleep in an interrupt context, so our only option is to
use spin lock.
William Breathitt Gray
signature.asc
Description: PGP signature
[Attenzione!] Con che velocità vola il tempo. Tutto bene?
https://bit.ly/33KlF6q Con i migliori auguri,Francesco Alfano
Re: [PATCH v5] checkpatch: add new exception to repeated word check
On Sun, Oct 18, 2020 at 12:41 PM Joe Perches wrote:
>
> On Sun, 2020-10-18 at 12:10 +0530, Dwaipayan Ray wrote:
> > print index(" \t.,;?!", '');
> >
> > It output 0 in my case. So last words on a line seems to work.
> > I don't know if this changes with the perl version though.
> >
> > So given this, will it be necessary to change end_char to ' ' ?
> > or perhaps change both start_char and end_char to a ' ' to maintain
> > uniformity?
>
> It seems it's fine even back to perl 5.6, so it's fine as is.
>
> cheers, Joe
>
Okay thanks!
Please let me know if any other change is needed
or if it's good to go.
Regards,
Dwaipayan.
Re: [PATCH v5 3/5] counter: Add character device interface
On Tue, Oct 13, 2020 at 08:40:18PM -0500, David Lechner wrote:
> On 9/26/20 9:18 PM, William Breathitt Gray wrote:
> > This patch introduces a character device interface for the Counter
> > subsystem. Device data is exposed through standard character device read
> > operations. Device data is gathered when a Counter event is pushed by
> > the respective Counter device driver. Configuration is handled via ioctl
> > operations on the respective Counter character device node.
> >
>
> Probably don't need to duplicate the full documentation in the commit
> message.
Ack.
> > diff --git a/drivers/counter/counter-chrdev.c
> > b/drivers/counter/counter-chrdev.c
> > new file mode 100644
> > index ..2be3846e4105
> > --- /dev/null
> > +++ b/drivers/counter/counter-chrdev.c
>
>
> > +
> > +static int counter_set_event_node(struct counter_device *const counter,
> > + struct counter_watch *const watch,
> > + const struct counter_comp_node *const cfg)
> > +{
> > + struct counter_event_node *event_node;
> > + int err;
> > + struct counter_comp_node *comp_node;
> > +
> > + /* Search for event in the list */
> > + list_for_each_entry(event_node, >next_events_list, l)
> > + if (event_node->event == watch->event &&
> > + event_node->channel == watch->channel)
> > + break;
> > +
> > + /* If event is not already in the list */
> > + if (_node->l == >next_events_list) {
> > + /* Allocate new event node */
> > + event_node = kmalloc(sizeof(*event_node), GFP_ATOMIC);
> > + if (!event_node)
> > + return -ENOMEM;
> > +
> > + /* Configure event node and add to the list */
> > + event_node->event = watch->event;
> > + event_node->channel = watch->channel;
> > + INIT_LIST_HEAD(_node->comp_list);
> > + list_add(_node->l, >next_events_list);
> > + }
> > +
> > + /* Check if component watch has already been set before */
> > + list_for_each_entry(comp_node, _node->comp_list, l)
> > + if (comp_node->parent == cfg->parent &&
> > + comp_node->comp.count_u8_read == cfg->comp.count_u8_read)
> > + return -EINVAL;
>
> There are already enough things that could cause EINVAL, we could
> probably skip this duplicate check to make troubleshooting easier.
I'm not sure it would be safe to remove this check. This prevents
duplicate watches from being allocated for the same component -- the
rationale is that there's no benefit in repeating a component value grab
for the same event. Although a typical user will not have the motivation
to do this, a bad actor could purposely keep allocating duplicate
watches in order to starve all the available memory.
> > +
> > + /* Allocate component node */
> > + comp_node = kmalloc(sizeof(*comp_node), GFP_ATOMIC);
> > + if (!comp_node) {
> > + err = -ENOMEM;
> > + goto err_comp_node;
>
> Since there is only one goto, we could just handle the error and
> return here instead.
Ack.
> > + }
> > + *comp_node = *cfg;
> > +
> > + /* Add component node to event node */
> > + list_add_tail(_node->l, _node->comp_list);
> > +
> > + return 0;
> > +
> > +err_comp_node:
>
> A comment explaining the list_empty() check would be nice.
> It makes sense if you think about it, but it is not super
> obvious.
Ack.
> > + if (list_empty(_node->comp_list)) {
> > + list_del(_node->l);
> > + kfree(event_node);
> > + }
> > + return err;
> > +}
> > +
> > +static int counter_set_watch(struct counter_device *const counter,
> > +const unsigned long arg)
> > +{
> > + void __user *const uwatch = (void __user *)arg;
> > + struct counter_watch watch;
> > + struct counter_comp_node comp_node;
> > + size_t parent, id;
> > + struct counter_comp *ext;
> > + size_t num_ext;
> > +
> > + if (copy_from_user(, uwatch, sizeof(watch)))
> > + return -EFAULT;
> > + parent = watch.component.parent;
> > + id = watch.component.id;
> > +
> > + /* Configure parent component info for comp node */
> > + switch (watch.component.scope) {
> > + case COUNTER_SCOPE_DEVICE:
> > + comp_node.parent = NULL;
> > +
> > + ext = counter->ext;
> > + num_ext = counter->num_ext;
> > + break;
> > + case COUNTER_SCOPE_SIGNAL:
> > + if (counter->num_signals < parent + 1)
>
> I think it would be more conventional this way:
>
> if (parent >= counter->num_signals)
Ack.
> > + return -EINVAL;
> > +
> > + comp_node.parent = counter->signals + parent;
> > +
> > + ext = counter->signals[parent].ext;
> > + num_ext = counter->signals[parent].num_ext;
> > + break;
> > + case COUNTER_SCOPE_COUNT:
> > + if (counter->num_counts < parent + 1)
>
> Same here.
Ack.
> > +
Re: [PATCH v1 00/29] virtio-mem: Big Block Mode (BBM)
> Am 18.10.2020 um 17:29 schrieb Michael S. Tsirkin : > > On Mon, Oct 12, 2020 at 02:52:54PM +0200, David Hildenbrand wrote: >> virtio-mem currently only supports device block sizes that span at most >> a single Linux memory block. For example, gigantic pages in the hypervisor >> result on x86-64 in a device block size of 1 GiB - when the Linux memory >> block size is 128 MiB, we cannot support such devices (we fail loading the >> driver). Of course, we want to support any device block size in any Linux >> VM. >> >> Bigger device block sizes will become especially important once supporting >> VFIO in QEMU - each device block has to be mapped separately, and the >> maximum number of mappings for VFIO is 64k. So we usually want blocks in >> the gigabyte range when wanting to grow the VM big. > > I guess it missed this Linux right? There's an mm change which did not > get an ack from mm mainatiners, so I can't merge it ... No issue, I was targeting 5.11 either way! I‘ll resend based on linus‘ tree now that all prereqs are upstream.
Re: [PATCH] Bluetooth: A2MP: Do not set rsp.id to zero
Am Sonntag, den 18.10.2020, 10:05 +0200 schrieb Stefan Gottwald:
> Due to security reasons the rsp struct is not zerod out in one case this will
> also zero out the former set rsp.id which seems to be wrong.
>
> Signed-off-by: Stefan Gottwald
> ---
> net/bluetooth/a2mp.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/a2mp.c b/net/bluetooth/a2mp.c
> index da7fd7c..7a1e0b7 100644
> --- a/net/bluetooth/a2mp.c
> +++ b/net/bluetooth/a2mp.c
> @@ -381,10 +381,11 @@ static int a2mp_getampassoc_req(struct amp_mgr *mgr,
> struct sk_buff *skb,
> hdev = hci_dev_get(req->id);
> if (!hdev || hdev->amp_type == AMP_TYPE_BREDR || tmp) {
> struct a2mp_amp_assoc_rsp rsp;
> - rsp.id = req->id;
>
> memset(, 0, sizeof(rsp));
>
> + rsp.id = req->id;
> +
> if (tmp) {
> rsp.status = A2MP_STATUS_COLLISION_OCCURED;
> amp_mgr_put(tmp);
As it seems I'm too slow there is already a fix from the author of the initial
patch.
https://lore.kernel.org/linux-bluetooth/20201016180956.707681-2-luiz.de...@gmail.com/
There is a additional patch in this series which might also be a important fix
https://lore.kernel.org/linux-bluetooth/20201016180956.707681-1-luiz.de...@gmail.com/
Thanks to a LWN member pointing this out to me.
Re: [Cocci] Determination of an usage statistic for memory allocation calls
On Sun, 18 Oct 2020, Markus Elfring wrote:
> > …
> > > +E = \(kmalloc\|kzalloc\|krealloc\|kcalloc\|
> > > + kmalloc_node\|kzalloc_node\|kmalloc_array\|
> > > + kmalloc_array_node\|kcalloc_node\)(...)@kok
> > …
> >
> > How do you think about the possibility for any adjustments according to the
> > order
> > of the mentioned function names in proposed disjunctions for the semantic
> > patch language?
>
>
> I would like to share another source code analysis approach.
> I hope that this contribution can trigger further helpful software
> development ideas.
>
>
> @initialize:python@
> @@
> import sys
>
> def write_identifier(source, call):
> names = []
> for x in source:
>names.append(call)
>
> sys.stdout.write("\n".join(names) + "\n")
>
> @find1@
> expression e;
> identifier call, x;
> position pos;
> type rt;
> @@
> rt x(...)
> {
> <+...
> e =@pos
> (kzalloc@call
> |kmalloc@call
> |kcalloc@call
> |kmalloc_array@call
> |kmemdup@call
> |kstrdup@call
> |vmalloc@call
> |vzalloc@call
> |kzalloc_node@call
> |kvmalloc@call
> |krealloc@call
> |kmalloc_node@call
> |kcalloc_node@call
> |__vmalloc@call
> |vmalloc_user@call
> |vzalloc_node@call
> |vmalloc_32@call
> |__vmalloc_node_range@call
> |vmalloc_node@call
> |kmalloc_array_node@call
> |__vmalloc_node@call
> |vmalloc_32_user@call
> |vmalloc_exec@call
> )(...)
> ...+>
> }
>
> @script:python collection1@
> call << find1.call;
> place << find1.pos;
> @@
> write_identifier(place, call)
>
> @find2@
> identifier call, var, x;
> position pos;
> type rt, vt;
> @@
> rt x(...)
> {
> <+...
> vt var =@pos
> (kzalloc@call
> |kmalloc@call
> |kcalloc@call
> |kmalloc_array@call
> |kmemdup@call
> |kstrdup@call
> |vmalloc@call
> |vzalloc@call
> |kzalloc_node@call
> |kvmalloc@call
> |krealloc@call
> |kmalloc_node@call
> |kcalloc_node@call
> |__vmalloc@call
> |vmalloc_user@call
> |vzalloc_node@call
> |vmalloc_32@call
> |__vmalloc_node_range@call
> |vmalloc_node@call
> |kmalloc_array_node@call
> |__vmalloc_node@call
> |vmalloc_32_user@call
> |vmalloc_exec@call
> )(...);
> ...+>
> }
>
> @script:python collection2@
> call << find2.call;
> place << find2.pos;
> @@
> write_identifier(place, call)
>
>
> Test result:
> elfring@Sonne:~/Projekte/Linux/next-patched> git checkout next-20201016 &&
> XX=$(date) && time spatch --timeout 23 --python python3 --jobs 4 --chunksize
> 1 --include-headers --no-includes --dir .
> ~/Projekte/Coccinelle/janitor/report_memory_allocation_calls4.cocci 2>
> ~/Projekte/Bau/Linux/scripts/Coccinelle/call_checks/20201016/report_memory_allocation_calls4-errors.txt
> | echo "$(echo 'call' && cat)" | csvsql --query 'select call, count(*) from
> stdin group by call order by count(*) desc'; YY=$(date) && echo "$XX | $YY"
> …
> call,count(*)
> kzalloc,12652
> kmalloc,4902
> kcalloc,2564
> kmalloc_array,859
> kmemdup,797
> kstrdup,469
> vmalloc,405
> vzalloc,359
> kzalloc_node,177
> kvmalloc,154
> krealloc,151
> kmalloc_node,49
> kcalloc_node,44
> __vmalloc,34
> vmalloc_user,28
> vzalloc_node,21
> vmalloc_32,9
> __vmalloc_node_range,8
> vmalloc_node,7
> kmalloc_array_node,5
> __vmalloc_node,4
> vmalloc_32_user,1
>
> real 22m25,049s
> user 84m11,257s
> sys 0m12,168s
> So 18. Okt 16:55:08 CEST 2020 | So 18. Okt 17:17:33 CEST 2020
>
>
> The log file contains the information “9211 files match”.
> Can such facts influence the specification of efficient SmPL disjunctions
> another bit?
On my machine, putting the three functions that you have foudn to be the
most frequent at the end of each disjunction has no impact on the
performance. So what do you suggest?
julia
Re: [PATCH 2/2] net: dsa: mv88e6xxx: Support serdes ports on MV88E6097
On Tue, Oct 13, 2020 at 03:18:58PM +1300, Chris Packham wrote:
> Implement serdes_power, serdes_get_lane and serdes_pcs_get_state ops for
> the MV88E6097 so that ports 8 & 9 can be supported as serdes ports and
> directly connected to other network interfaces or to SFPs without a PHY.
>
> Signed-off-by: Chris Packham
> ---
>
> This should be usable for all variants of the 88E6185 that have
> tri-speed capable ports (which is why I used the mv88e6185 prefix
> instead of mv88e6097). But my hardware only has a 88e6097 so I've only
> connected up the ops for that chip.
>
> drivers/net/dsa/mv88e6xxx/chip.c | 61
> 1 file changed, 61 insertions(+)
>
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c
> b/drivers/net/dsa/mv88e6xxx/chip.c
> index 1ef392ee52c5..1c6cd5c43eb1 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -3436,6 +3436,64 @@ static int mv88e6xxx_set_eeprom(struct dsa_switch *ds,
> return err;
> }
>
> +static int mv88e6185_serdes_power(struct mv88e6xxx_chip *chip, int port, u8
> lane,
> + bool up)
> +{
> + /* The serdes power can't be controlled on this switch chip but we need
> + * to supply this function to avoid returning -EOPNOTSUPP in
> + * mv88e6xxx_serdes_power_up/mv88e6xxx_serdes_power_down
> + */
Hi Chris
How about bit 11 of the control register 0? This looks a lot like a
BMCR, and BMCR_PDOWN.
This is what mv88e6352_serdes_power() does. You might be able to even
re-use it, if you can make the lane numbers work.
Andrew
Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver
On Sun, Oct 18, 2020 at 8:59 AM Michael S. Tsirkin wrote: > > On Sun, Oct 18, 2020 at 08:54:36AM -0700, Andy Lutomirski wrote: > > On Sun, Oct 18, 2020 at 8:52 AM Michael S. Tsirkin wrote: > > > > > > On Sat, Oct 17, 2020 at 03:24:08PM +0200, Jason A. Donenfeld wrote: > > > > 4c. The guest kernel maintains an array of physical addresses that are > > > > MADV_WIPEONFORK. The hypervisor knows about this array and its > > > > location through whatever protocol, and before resuming a > > > > moved/snapshotted/duplicated VM, it takes the responsibility for > > > > memzeroing this memory. The huge pro here would be that this > > > > eliminates all races, and reduces complexity quite a bit, because the > > > > hypervisor can perfectly synchronize its bringup (and SMP bringup) > > > > with this, and it can even optimize things like on-disk memory > > > > snapshots to simply not write out those pages to disk. > > > > > > > > A 4c-like approach seems like it'd be a lot of bang for the buck -- we > > > > reuse the existing mechanism (MADV_WIPEONFORK), so there's no new > > > > userspace API to deal with, and it'd be race free, and eliminate a lot > > > > of kernel complexity. > > > > > > Clearly this has a chance to break applications, right? > > > If there's an app that uses this as a non-system-calls way > > > to find out whether there was a fork, it will break > > > when wipe triggers without a fork ... > > > For example, imagine: > > > > > > MADV_WIPEONFORK > > > copy secret data to MADV_DONTFORK > > > fork > > > > > > > > > used to work, with this change it gets 0s instead of the secret data. > > > > > > > > > I am also not sure it's wise to expose each guest process > > > to the hypervisor like this. E.g. each process needs a > > > guest physical address of its own then. This is a finite resource. > > > > > > > > > The mmap interface proposed here is somewhat baroque, but it is > > > certainly simple to implement ... > > > > Wipe of fork/vmgenid/whatever could end up being much more problematic > > than it naively appears -- it could be wiped in the middle of a read. > > Either the API needs to handle this cleanly, or we need something more > > aggressive like signal-on-fork. > > > > --Andy > > > Right, it's not on fork, it's actually when process is snapshotted. > > If we assume it's CRIU we care about, then I > wonder what's wrong with something like > MADV_CHANGEONPTRACE_SEIZE > and basically say it's X bytes which change the value... I feel like we may be approaching this from the wrong end. Rather than saying "what data structure can the kernel expose that might plausibly be useful", how about we try identifying some specific userspace needs and see what a good solution could look like. I can identify two major cryptographic use cases: 1. A userspace RNG. The API exposed by the userspace end is a function that generates random numbers. The userspace code in turn wants to know some things from the kernel: it wants some best-quality-available random seed data from the kernel (and possibly an indication of how good it is) as well as an indication of whether the userspace memory may have been cloned or rolled back, or, failing that, an indication of whether a reseed is needed. Userspace could implement a wide variety of algorithms on top depending on its goals and compliance requirements, but the end goal is for the userspace part to be very, very fast. 2. A userspace crypto stack that wants to avoid shooting itself in the foot due to inadvertently doing the same thing twice. For example, an AES-GCM stack does not want to reuse an IV, *expecially* if there is even the slightest chance that it might reuse the IV for different data. This use case doesn't necessarily involve random numbers, but, if anything, it needs to be even faster than #1. The threats here are not really the same. For #1, a userspace RNG should be able to recover from a scenario in which an adversary clones the entire process *and gets to own the clone*. For example, in Android, an adversary can often gain complete control of a fork of the zygote -- this shouldn't adversely affect the security properties of other forks. Similarly, a server farm could operate by having one booted server that is cloned to create more workers. Those clones could be provisioned with secrets and permissions post-clone, and at attacker gaining control of a fresh clone could be considered acceptable. For #2, in contrast, if an adversary gains control of a clone of an AES-GCM session, they learn the key outright -- the relevant attack scenario is that the adversary gets to interact with two clones without compromising either clone per se. It's worth noting that, in both cases, there could possibly be more than one instance of an RNG or an AES-GCM session in the same process. This means that using signals is awkward but not necessarily impossibly. (This is an area in which Linux, and POSIX in general, is much weaker than Windows.)
Re: [PATCH] checkpatch: Allow not using -f with files that are in git
On Sun, 2020-10-18 at 16:03 +0200, Geert Uytterhoeven wrote:
> Hi Joe,
>
> On Tue, Aug 25, 2020 at 2:12 AM Joe Perches wrote:
> > If a file exists in git and checkpatch is used without the -f
> > flag for scanning a file, then checkpatch will scan the file
> > assuming it's a patch and emit:
> >
> > ERROR: Does not appear to be a unified-diff format patch
> >
> > Change the behavior to assume the -f flag if the file exists
> > in git.
> >
> > Signed-off-by: Joe Perches
>
> Thanks for your patch!
>
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -976,6 +976,16 @@ sub seed_camelcase_includes {
> > }
> > }
> >
> > +sub git_is_single_file {
> > + my ($filename) = @_;
> > +
> > + return 0 if ((which("git") eq "") || !(-e "$gitroot"));
> > +
> > + my $output = `${git_command} ls-files -- $filename`;
> > + my $count = $output =~ tr/\n//;
> > + return $count eq 1 && $output =~ m{^${filename}$};
> > +}
> > +
> > sub git_commit_info {
> > my ($commit, $id, $desc) = @_;
> >
>
> This is now commit f5f613259f3fea81 ("checkpatch: allow not using -f
> with files that are in git"), causing:
>
> Global symbol "$gitroot" requires explicit package name (did you
> forget to declare "my $gitroot"?) at scripts/checkpatch.pl line 980.
> Execution of scripts/checkpatch.pl aborted due to compilation errors.
>
> FWIW, host system is running Ubuntu 18.04.5 LTS (upgrade to 20.04 LTS
> planned soon ;-).
I believe there is a dependency on another patch
in -next that wasn't pushed to Linus' tree.
commit 5ec1f7de97b26a3fa364bbb31fdd2e42c8e6fa22
Author: Joe Perches
Date: Thu Oct 8 11:53:44 2020 +1100
checkpatch: test $GIT_DIR changes
So it'd be better to revert right now until
this other patch is accepted or pushed.
Re: [PATCH 1/2] net: dsa: mv88e6xxx: Don't force link when using in-band-status
On Tue, Oct 13, 2020 at 03:18:57PM +1300, Chris Packham wrote: > When a port is configured with 'managed = "in-band-status"' don't force > the link up, the switch MAC will detect the link status correctly. > > Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn Andrew
Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver
On Sun, Oct 18, 2020 at 08:54:36AM -0700, Andy Lutomirski wrote: > On Sun, Oct 18, 2020 at 8:52 AM Michael S. Tsirkin wrote: > > > > On Sat, Oct 17, 2020 at 03:24:08PM +0200, Jason A. Donenfeld wrote: > > > 4c. The guest kernel maintains an array of physical addresses that are > > > MADV_WIPEONFORK. The hypervisor knows about this array and its > > > location through whatever protocol, and before resuming a > > > moved/snapshotted/duplicated VM, it takes the responsibility for > > > memzeroing this memory. The huge pro here would be that this > > > eliminates all races, and reduces complexity quite a bit, because the > > > hypervisor can perfectly synchronize its bringup (and SMP bringup) > > > with this, and it can even optimize things like on-disk memory > > > snapshots to simply not write out those pages to disk. > > > > > > A 4c-like approach seems like it'd be a lot of bang for the buck -- we > > > reuse the existing mechanism (MADV_WIPEONFORK), so there's no new > > > userspace API to deal with, and it'd be race free, and eliminate a lot > > > of kernel complexity. > > > > Clearly this has a chance to break applications, right? > > If there's an app that uses this as a non-system-calls way > > to find out whether there was a fork, it will break > > when wipe triggers without a fork ... > > For example, imagine: > > > > MADV_WIPEONFORK > > copy secret data to MADV_DONTFORK > > fork > > > > > > used to work, with this change it gets 0s instead of the secret data. > > > > > > I am also not sure it's wise to expose each guest process > > to the hypervisor like this. E.g. each process needs a > > guest physical address of its own then. This is a finite resource. > > > > > > The mmap interface proposed here is somewhat baroque, but it is > > certainly simple to implement ... > > Wipe of fork/vmgenid/whatever could end up being much more problematic > than it naively appears -- it could be wiped in the middle of a read. > Either the API needs to handle this cleanly, or we need something more > aggressive like signal-on-fork. > > --Andy Right, it's not on fork, it's actually when process is snapshotted. If we assume it's CRIU we care about, then I wonder what's wrong with something like MADV_CHANGEONPTRACE_SEIZE and basically say it's X bytes which change the value... -- MST
Re: Dts for eth network based on marvell's mv88e6390x crashes Xilinx's linux-kernel v5.4
On Sun, Oct 18, 2020 at 10:18:53AM +0300, michael alayev wrote: > Hello andrew, > > This is pretty unreadable with all the white space removed. > > Please could you post again with the white space. > Its formatted better here: > https://stackoverflow.com/q/64301750/8926995?sem=2 Better, but the indentation is still wrong. Please fix your email client and post the DT file for review. I will then point out some of the errors. Andrew
Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver
On Sun, Oct 18, 2020 at 8:52 AM Michael S. Tsirkin wrote: > > On Sat, Oct 17, 2020 at 03:24:08PM +0200, Jason A. Donenfeld wrote: > > 4c. The guest kernel maintains an array of physical addresses that are > > MADV_WIPEONFORK. The hypervisor knows about this array and its > > location through whatever protocol, and before resuming a > > moved/snapshotted/duplicated VM, it takes the responsibility for > > memzeroing this memory. The huge pro here would be that this > > eliminates all races, and reduces complexity quite a bit, because the > > hypervisor can perfectly synchronize its bringup (and SMP bringup) > > with this, and it can even optimize things like on-disk memory > > snapshots to simply not write out those pages to disk. > > > > A 4c-like approach seems like it'd be a lot of bang for the buck -- we > > reuse the existing mechanism (MADV_WIPEONFORK), so there's no new > > userspace API to deal with, and it'd be race free, and eliminate a lot > > of kernel complexity. > > Clearly this has a chance to break applications, right? > If there's an app that uses this as a non-system-calls way > to find out whether there was a fork, it will break > when wipe triggers without a fork ... > For example, imagine: > > MADV_WIPEONFORK > copy secret data to MADV_DONTFORK > fork > > > used to work, with this change it gets 0s instead of the secret data. > > > I am also not sure it's wise to expose each guest process > to the hypervisor like this. E.g. each process needs a > guest physical address of its own then. This is a finite resource. > > > The mmap interface proposed here is somewhat baroque, but it is > certainly simple to implement ... Wipe of fork/vmgenid/whatever could end up being much more problematic than it naively appears -- it could be wiped in the middle of a read. Either the API needs to handle this cleanly, or we need something more aggressive like signal-on-fork. --Andy
Re: [PATCH] drivers/virt: vmgenid: add vm generation id driver
On Sat, Oct 17, 2020 at 03:24:08PM +0200, Jason A. Donenfeld wrote: > 4c. The guest kernel maintains an array of physical addresses that are > MADV_WIPEONFORK. The hypervisor knows about this array and its > location through whatever protocol, and before resuming a > moved/snapshotted/duplicated VM, it takes the responsibility for > memzeroing this memory. The huge pro here would be that this > eliminates all races, and reduces complexity quite a bit, because the > hypervisor can perfectly synchronize its bringup (and SMP bringup) > with this, and it can even optimize things like on-disk memory > snapshots to simply not write out those pages to disk. > > A 4c-like approach seems like it'd be a lot of bang for the buck -- we > reuse the existing mechanism (MADV_WIPEONFORK), so there's no new > userspace API to deal with, and it'd be race free, and eliminate a lot > of kernel complexity. Clearly this has a chance to break applications, right? If there's an app that uses this as a non-system-calls way to find out whether there was a fork, it will break when wipe triggers without a fork ... For example, imagine: MADV_WIPEONFORK copy secret data to MADV_DONTFORK fork used to work, with this change it gets 0s instead of the secret data. I am also not sure it's wise to expose each guest process to the hypervisor like this. E.g. each process needs a guest physical address of its own then. This is a finite resource. The mmap interface proposed here is somewhat baroque, but it is certainly simple to implement ... -- MST
Re: [PATCH v3 10/19] sched: Fix migrate_disable() vs set_cpus_allowed_ptr()
Hi,
On 18/10/20 10:46, ouwen wrote:
> On Fri, Oct 16, 2020 at 01:48:17PM +0100, Valentin Schneider wrote:
>> ---
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index a5b6eac07adb..1ebf653c2c2f 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -1859,6 +1859,13 @@ static struct rq *__migrate_task(struct rq *rq,
>> struct rq_flags *rf,
>> return rq;
>> }
>>
>> +struct set_affinity_pending {
>> +refcount_t refs;
>> +struct completion done;
>> +struct cpu_stop_workstop_work;
>> +struct migration_argarg;
>> +};
>> +
>> /*
>> * migration_cpu_stop - this will be executed by a highprio stopper thread
>> * and performs thread migration by bumping thread off CPU then
>> @@ -1866,6 +1873,7 @@ static struct rq *__migrate_task(struct rq *rq, struct
>> rq_flags *rf,
>> */
>> static int migration_cpu_stop(void *data)
>> {
>> +struct set_affinity_pending *pending;
>> struct migration_arg *arg = data;
>> struct task_struct *p = arg->task;
>> struct rq *rq = this_rq();
>> @@ -1886,13 +1894,22 @@ static int migration_cpu_stop(void *data)
>>
>> raw_spin_lock(>pi_lock);
>> rq_lock(rq, );
>> +
>> +if (arg->done)
>
> If I'm not wrong(always likely), arg->done is point to the installed
> pending's done of the first task that calling sca. It should not be
> NULL because it is a pointer to the stack address not related to the
> content in the stack.
>
Correct; here I'm using it as an indicator of whether migration_cpu_stop()
was invoked by SCA with a pending affinity request. I'll admit it's icky,
I'd prefer having an explicit flag to check against.
>> +pending = container_of(arg->done, struct set_affinity_pending,
>> done);
>> /*
>> * If task_rq(p) != rq, it cannot be migrated here, because we're
>> * holding rq->lock, if p->on_rq == 0 it cannot get enqueued because
>> * we're holding p->pi_lock.
>> */
>> if (task_rq(p) == rq) {
>> -if (is_migration_disabled(p))
>> +/*
>> + * An affinity update may have raced with us.
>> + * p->migration_pending could now be NULL, or could be pointing
>> + * elsewhere entirely.
>> + */
>> +if (is_migration_disabled(p) ||
>> +(arg->done && p->migration_pending != pending))
> ^^^
> p->migration_pending can be set on the random task's stack but the
> address is possible to be the same with the previous pending. It's
> very very unlikely. But I'm also totally failed.
>
Do you mean if we encounter the above race, but on top of that a new
pending gets installed that has the *same* address as the previous one?
That would mean that the task which installed that first pending got out of
affine_move_task() and *back into it*, with the same stack depth, before the
stopper got to run & grab the task_rq_lock. I also thought about this, but
am unsure how far to push the paranoia.
Side thought: don't we need to NULL p->migration_pending in __sched_fork()?
> I can't realize anything that time, but now I just give this noise.
> Use refcount_add/dec on MIGRATE_ENABLE path to prevent that not sure
> yet.
>
One annoying thing is that in that path we can't wait on the refcount
reaching 0, since migrate_{disable, enable}() disable preemption.
(the stopper is only schedule()'d upon reenabling preemption in
migrate_enable()).
Including the stopper callback in the refcount chain would probably reduce
future headaches, but it's not as straightforward.
>> goto out;
>>
>> if (task_on_rq_queued(p))
>> @@ -2024,13 +2041,6 @@ void do_set_cpus_allowed(struct task_struct *p, const
>> struct cpumask *new_mask)
>> __do_set_cpus_allowed(p, new_mask, 0);
>> }
>>
>> -struct set_affinity_pending {
>> -refcount_t refs;
>> -struct completion done;
>> -struct cpu_stop_workstop_work;
>> -struct migration_argarg;
>> -};
>> -
>> /*
>> * This function is wildly self concurrent; here be dragons.
>> *
QATAR PETROLEUM INVESTMENT....
Greetings. I am Mr. H.E. Ali Shareef Al-Emadi, Finance and Account, Qatar Petroleum. I have $30m for Investment. Contact me if you are interested; I have all it will take to move the fund to any of your account designate as a Contract Fund to avoid every query by the authority in your Country. I sent this message from my private Email; I will give you more details through my official Email upon the receipt of your response to prove myself and office to you. Email Address: alishareefalemadi...@gmail.com Regards. Mr. H.E. Ali Shareef Al-Emadi, Minister Of Finance. Qatar Petroleum
Re: [PATCH v2] iio: proximity: as3935 change of_property_read to device_property_read
On Sun, Oct 18, 2020 at 4:47 PM Jonathan Cameron wrote:
>
> On Sun, 18 Oct 2020 08:47:32 +0530
> Vaishnav M A wrote:
>
> A very similar change was made recently in
> 00fa493b9989 ("iio:proximity:as3935: Drop of_match_ptr and use generic fw
> accessors")
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=00fa493b99894b930e431c05a9dba294c5189120
>
Sorry for missing that, happy to see this change.
Thanks,
Vaishnav M A
> Review follows for reference as I wrote it before remembering the above!
>
> > replace the of_property_read_u32 for reading
> > the ams,tuning-capacitor-pf, ams,nflwdth properties with
> > device_property_read_u32, allows the driver to get the properties
> > information using the more generic device_property_* helpers and opens
> > the possibility of passing the properties during platform instantiation
> > of the device by a suitably populated struct property_entry
>
> Please format this to aid readability.
>
> Replace of_property_read_u32() with device_property_read_u32,
> when reading the ams,tuning-capacitor-pf and ams,nflwdth properties.
> This opens up the possibility of passing the properties during platform
> instantiation of the device by a suitable populated struct property_entry.
>
>
> As in your other patch, please add the header property.h.
>
> >
> > Signed-off-by: Vaishnav M A
> > ---
> > v2:
> > - fix commit message
> > drivers/iio/proximity/as3935.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/iio/proximity/as3935.c b/drivers/iio/proximity/as3935.c
> > index c339e7339ec8..7e47ddf89a56 100644
> > --- a/drivers/iio/proximity/as3935.c
> > +++ b/drivers/iio/proximity/as3935.c
> > @@ -355,7 +355,6 @@ static int as3935_probe(struct spi_device *spi)
> > struct iio_dev *indio_dev;
> > struct iio_trigger *trig;
> > struct as3935_state *st;
> > - struct device_node *np = spi->dev.of_node;
> > int ret;
> >
> > /* Be sure lightning event interrupt is specified */
> > @@ -374,7 +373,7 @@ static int as3935_probe(struct spi_device *spi)
> > spi_set_drvdata(spi, indio_dev);
> > mutex_init(>lock);
> >
> > - ret = of_property_read_u32(np,
> > + ret = device_property_read_u32(>dev,
> > "ams,tuning-capacitor-pf", >tune_cap);
> > if (ret) {
> > st->tune_cap = 0;
> > @@ -390,7 +389,7 @@ static int as3935_probe(struct spi_device *spi)
> > return -EINVAL;
> > }
> >
> > - ret = of_property_read_u32(np,
> > + ret = device_property_read_u32(>dev,
> > "ams,nflwdth", >nflwdth_reg);
> > if (!ret && st->nflwdth_reg > AS3935_NFLWDTH_MASK) {
> > dev_err(>dev,
>
Re: [PATCH v1 00/29] virtio-mem: Big Block Mode (BBM)
On Mon, Oct 12, 2020 at 02:52:54PM +0200, David Hildenbrand wrote: > virtio-mem currently only supports device block sizes that span at most > a single Linux memory block. For example, gigantic pages in the hypervisor > result on x86-64 in a device block size of 1 GiB - when the Linux memory > block size is 128 MiB, we cannot support such devices (we fail loading the > driver). Of course, we want to support any device block size in any Linux > VM. > > Bigger device block sizes will become especially important once supporting > VFIO in QEMU - each device block has to be mapped separately, and the > maximum number of mappings for VFIO is 64k. So we usually want blocks in > the gigabyte range when wanting to grow the VM big. I guess it missed this Linux right? There's an mm change which did not get an ack from mm mainatiners, so I can't merge it ... > This series: > - Performs some cleanups > - Factors out existing Sub Block Mode (SBM) > - Implements memory hot(un)plug in Big Block Mode (BBM) > > I need one core-mm change, to make offline_and_remove_memory() eat bigger > chunks. > > This series is based on "next-20201009" and can be found at: > g...@gitlab.com:virtio-mem/linux.git virtio-mem-dbm-v1 > > Once some virtio-mem patches that are pending in the -mm tree are upstream > (I guess they'll go in in 5.10), I'll resend based on Linus' tree. > I suggest to take this (including the MM patch, acks/review please) via the > vhost tree once time has come. In the meantime, I'll do more testing. > > David Hildenbrand (29): > virtio-mem: determine nid only once using memory_add_physaddr_to_nid() > virtio-mem: simplify calculation in > virtio_mem_mb_state_prepare_next_mb() > virtio-mem: simplify MAX_ORDER - 1 / pageblock_order handling > virtio-mem: drop rc2 in virtio_mem_mb_plug_and_add() > virtio-mem: generalize check for added memory > virtio-mem: generalize virtio_mem_owned_mb() > virtio-mem: generalize virtio_mem_overlaps_range() > virtio-mem: drop last_mb_id > virtio-mem: don't always trigger the workqueue when offlining memory > virtio-mem: generalize handling when memory is getting onlined > deferred > virtio-mem: use "unsigned long" for nr_pages when fake > onlining/offlining > virtio-mem: factor out fake-offlining into virtio_mem_fake_offline() > virtio-mem: factor out handling of fake-offline pages in memory > notifier > virtio-mem: retry fake-offlining via alloc_contig_range() on > ZONE_MOVABLE > virito-mem: document Sub Block Mode (SBM) > virtio-mem: memory block states are specific to Sub Block Mode (SBM) > virito-mem: subblock states are specific to Sub Block Mode (SBM) > virtio-mem: factor out calculation of the bit number within the > sb_states bitmap > virito-mem: existing (un)plug functions are specific to Sub Block Mode > (SBM) > virtio-mem: nb_sb_per_mb and subblock_size are specific to Sub Block > Mode (SBM) > virtio-mem: memory notifier callbacks are specific to Sub Block Mode > (SBM) > virtio-mem: memory block ids are specific to Sub Block Mode (SBM) > virtio-mem: factor out adding/removing memory from Linux > virtio-mem: print debug messages from virtio_mem_send_*_request() > virtio-mem: Big Block Mode (BBM) memory hotplug > virtio-mem: allow to force Big Block Mode (BBM) and set the big block > size > mm/memory_hotplug: extend offline_and_remove_memory() to handle more > than one memory block > virtio-mem: Big Block Mode (BBM) - basic memory hotunplug > virtio-mem: Big Block Mode (BBM) - safe memory hotunplug > > drivers/virtio/virtio_mem.c | 1783 +-- > mm/memory_hotplug.c | 105 ++- > 2 files changed, 1373 insertions(+), 515 deletions(-) > > -- > 2.26.2
Re: [PATCH v2] iio: proximity: vl53l0x-i2c add i2c_device_id
On Sun, Oct 18, 2020 at 5:03 PM Jonathan Cameron wrote:
>
> On Sun, 18 Oct 2020 09:01:42 +0530
> Vaishnav M A wrote:
>
> > add i2c_device_id for the vl53l0x-i2c driver so
> > that the device can be instantiated using i2c_new_client_device
> > or from userspace, useful in cases where device tree based description
> > is not possible now(Eg. a device on a gbphy i2c
> > adapter created by greybus).
> >
> > Signed-off-by: Vaishnav M A
>
> Please fix the description as mentioned in other patches.
>
Thank you Jonathan for your review, I have sent a v3 patch with fixed
description : https://lore.kernel.org/patchwork/patch/1322196/
understand your concern about the redundant device_id(s), it will be nice to see
of_match_table reused in such cases as you suggested.
> The code change is fine, but it does raise the question of whether we want to
> think
> about providing a means to register such devices using the of_match_table.
> It's somewhat irritating to need to provide both (I'd rather not
> just provide the non-dt version rely on the old hack that drops the
> vendor ID for matching).
>
> +CC Wolfram.
>
> > ---
> > v2:
> > - fix commit message
> > drivers/iio/proximity/vl53l0x-i2c.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/iio/proximity/vl53l0x-i2c.c
> > b/drivers/iio/proximity/vl53l0x-i2c.c
> > index 5fbda9475ba9..7c29d4cae24a 100644
> > --- a/drivers/iio/proximity/vl53l0x-i2c.c
> > +++ b/drivers/iio/proximity/vl53l0x-i2c.c
> > @@ -143,6 +143,12 @@ static int vl53l0x_probe(struct i2c_client *client)
> > return devm_iio_device_register(>dev, indio_dev);
> > }
> >
> > +static const struct i2c_device_id vl53l0x_id[] = {
> > + { "vl53l0x", 0},
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(i2c, vl53l0x_id);
> > +
> > static const struct of_device_id st_vl53l0x_dt_match[] = {
> > { .compatible = "st,vl53l0x", },
> > { }
> > @@ -155,6 +161,7 @@ static struct i2c_driver vl53l0x_driver = {
> > .of_match_table = st_vl53l0x_dt_match,
> > },
> > .probe_new = vl53l0x_probe,
> > + .id_table = vl53l0x_id,
> > };
> > module_i2c_driver(vl53l0x_driver);
> >
>
[PATCH] powercap: Fix typo in Kconfig "Plance" -> "Plane"
Signed-off-by: Hubert Jasudowicz --- drivers/powercap/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/powercap/Kconfig b/drivers/powercap/Kconfig index ebc4d4578339..bc228725346b 100644 --- a/drivers/powercap/Kconfig +++ b/drivers/powercap/Kconfig @@ -30,7 +30,7 @@ config INTEL_RAPL In RAPL, the platform level settings are divided into domains for fine grained control. These domains include processor package, DRAM - controller, CPU core (Power Plance 0), graphics uncore (Power Plane + controller, CPU core (Power Plane 0), graphics uncore (Power Plane 1), etc. config IDLE_INJECT base-commit: 9d9af1007bc08971953ae915d88dc9bb21344b53 -- 2.28.0
[PATCH v3] iio: proximity: vl53l0x-i2c add i2c_device_id
Add i2c_device_id table for the vl53l0x-i2c driver,
helps in device instantiation using i2c_new_client_device
or from userspace in cases where device-tree based description
is not possible now (Example: device on a gbphy i2c adapter
created by greybus)
Signed-off-by: Vaishnav M A
---
v3:
-modify commit message for readability
as suggested by Jonathan Cameron
v2:
-fix commit message
drivers/iio/proximity/vl53l0x-i2c.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/iio/proximity/vl53l0x-i2c.c
b/drivers/iio/proximity/vl53l0x-i2c.c
index 5fbda9475ba9..7c29d4cae24a 100644
--- a/drivers/iio/proximity/vl53l0x-i2c.c
+++ b/drivers/iio/proximity/vl53l0x-i2c.c
@@ -143,6 +143,12 @@ static int vl53l0x_probe(struct i2c_client *client)
return devm_iio_device_register(>dev, indio_dev);
}
+static const struct i2c_device_id vl53l0x_id[] = {
+ { "vl53l0x", 0},
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, vl53l0x_id);
+
static const struct of_device_id st_vl53l0x_dt_match[] = {
{ .compatible = "st,vl53l0x", },
{ }
@@ -155,6 +161,7 @@ static struct i2c_driver vl53l0x_driver = {
.of_match_table = st_vl53l0x_dt_match,
},
.probe_new = vl53l0x_probe,
+ .id_table = vl53l0x_id,
};
module_i2c_driver(vl53l0x_driver);
--
2.25.1
Re: [PATCH 1/4] tracing: Make trace_*_run_command() more flexible
Hi Tom,
On Sun, 18 Oct 2020 23:20:11 +0900
Masami Hiramatsu wrote:
> Hi Tom,
>
> On Fri, 16 Oct 2020 16:48:22 -0500
> Tom Zanussi wrote:
>
> > trace_run_command() and therefore functions that use it, such as
> > trace_parse_run_command(), uses argv_split() to split the command into
> > an array of args then passed to the callback to handle.
> >
> > This works fine for most commands but some commands would like to
> > allow the user to use and additional separator to visually group items
> > in the command. One example would be synthetic event commands, which
> > use semicolons to group fields:
> >
> > echo 'event_name int a; char b[]; u64 lat' >> synthetic_events
> >
> > What gets passed as an args array to the command for a command like
> > this include tokens that have semicolons included with the token,
> > which the callback then needs to strip out, since argv_split() only
> > looks at whitespace as a separator.
> >
> > It would be nicer to just have trace_run_command() strip out the
> > semicolons at its level rather than passing that task onto the
> > callback. To accomplish that, this change adds an 'additional_sep'
> > arg to a new __trace_run_command() function that allows a caller to
> > pass an additional separator char that if non-zero simply replaces
> > that character with whitespace before splitting the command into args.
> > The original trace_run_command() remains as-is in this regard, simply
> > calling __trace_run_command() with 0 for the separator, while making a
> > new trace_run_command_add_sep() version that can be used to pass in a
> > separator.
>
> No, I don't like to tweak trace_run_command() that way, I'm OK to
> delegate the argv_split() totally to the callback function (pass
> the raw command string to the callback), OR __create_synth_event()
> concatinate the fields argv and parse it by itself (I think the
> latter is better and simpler).
>
> The ";" separator is not an additinal separator but that is higher
> level separator for synthetic event. Suppose that you get the
> following input;
> "myevent int c ; char b"
> "myevent int;c;char;b;"
> These should not be same for the synthetic events. The fields must be
> splitted by ';' at first, and then each field should be parsed.
>
> So, I recommend you not to pass the additional separator to the
> generic function, but (since it is only for synthetic event) to
> reconstruct the raw command from argv, and parse it again with
> ";" inside synthetic event parser. Then each fields parser can
> check that is a wrong input or not.
>
> It will be something like
>
> __create_synth_event(argc, argv)
> {
>
> argc--; argv++;
>
> raw_fields = concat_argv(argc, argv);// you can assume argv is
> generated by argv_split().
> vfields = split_fields(raw_fields, );// similar to argv_split()
> for (i = 0; i < nfields; i++)
> parse_synth_field(vfields[i]);
> }
>
> Then, you don't need to change the generic functions, and also
> you will get the correct parser routines.
If you think the split->concat->split process is redundant, I think we
can remove trace_run_command() and just pass a raw command string to each
event command parser as I said above.
In this way, each event create function can parse the command by themselves.
So you can parse the command as you like.
Here is the patch which modifies trace-{k,u}probe and trace-dynevent
side, but not changing synthetic event side yet. Will this help you?
>From 5aed03a8df0926d92f6585b3932fdc96324cb82d Mon Sep 17 00:00:00 2001
From: Masami Hiramatsu
Date: Sat, 17 Oct 2020 23:11:29 +0900
Subject: [PATCH] tracing/dynevent: Delegate parsing to create function
Delegate command parsing to each create function so that the
command syntax can be customized.
Signed-off-by: Masami Hiramatsu
---
kernel/trace/trace.c | 23 ++-
kernel/trace/trace.h | 3 +--
kernel/trace/trace_dynevent.c | 35 ++-
kernel/trace/trace_dynevent.h | 4 ++--
kernel/trace/trace_kprobe.c | 33 ++---
kernel/trace/trace_probe.c| 17 +
kernel/trace/trace_probe.h| 1 +
kernel/trace/trace_uprobe.c | 17 +++--
8 files changed, 74 insertions(+), 59 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 63c97012ed39..277d97220971 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -9367,30 +9367,11 @@ void ftrace_dump(enum ftrace_dump_mode oops_dump_mode)
}
EXPORT_SYMBOL_GPL(ftrace_dump);
-int trace_run_command(const char *buf, int (*createfn)(int, char **))
-{
- char **argv;
- int argc, ret;
-
- argc = 0;
- ret = 0;
- argv = argv_split(GFP_KERNEL, buf, );
- if (!argv)
- return -ENOMEM;
-
- if (argc)
- ret = createfn(argc, argv);
-
- argv_free(argv);
-
- return ret;
-}
-
#define WRITE_BUFSIZE 4096
ssize_t
