Re: [PATCH] fnic: fixup patch to resolve stack frame issues
On Tue, Jan 26, 2021 at 05:21:24PM -0800, Lee Duncan wrote:
> From: Hannes Reinecke
>
> Commit 42ec15ceaea7 fixed a gcc issue with unused variables, but
> introduced errors since it allocated an array of two u64-s but
> then used more than that. Set the arrays to the proper size.
>
> Fixes: 42ec15ceaea74b5f7a621fc6686cbf69ca66c4cf
Please use the documented way to show sha1 commit ids to make it easier
to understand:
42ec15ceaea7 ("scsi: fnic: fix invalid stack access")
thanks,
greg k-h
[Patch v2 net-next 3/7] octeontx2-pf: ethtool fec mode support
From: Christina Jacob
Add ethtool support to configure fec modes baser/rs and
support to fecth FEC stats from CGX as well PHY.
Configure fec mode
- ethtool --set-fec eth0 encoding rs/baser/off/auto
Query fec mode
- ethtool --show-fec eth0
Signed-off-by: Christina Jacob
Signed-off-by: Sunil Goutham
Signed-off-by: Hariprasad Kelam
---
.../ethernet/marvell/octeontx2/nic/otx2_common.c | 23 +++
.../ethernet/marvell/octeontx2/nic/otx2_common.h | 6 +
.../ethernet/marvell/octeontx2/nic/otx2_ethtool.c | 181 -
.../net/ethernet/marvell/octeontx2/nic/otx2_pf.c | 3 +
4 files changed, 211 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
index bdfa2e2..f7e5450 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.c
@@ -60,6 +60,22 @@ void otx2_update_lmac_stats(struct otx2_nic *pfvf)
mutex_unlock(>mbox.lock);
}
+void otx2_update_lmac_fec_stats(struct otx2_nic *pfvf)
+{
+ struct msg_req *req;
+
+ if (!netif_running(pfvf->netdev))
+ return;
+ mutex_lock(>mbox.lock);
+ req = otx2_mbox_alloc_msg_cgx_fec_stats(>mbox);
+ if (!req) {
+ mutex_unlock(>mbox.lock);
+ return;
+ }
+ otx2_sync_mbox_msg(>mbox);
+ mutex_unlock(>mbox.lock);
+}
+
int otx2_update_rq_stats(struct otx2_nic *pfvf, int qidx)
{
struct otx2_rcv_queue *rq = >qset.rq[qidx];
@@ -1491,6 +1507,13 @@ void mbox_handler_cgx_stats(struct otx2_nic *pfvf,
pfvf->hw.cgx_tx_stats[id] = rsp->tx_stats[id];
}
+void mbox_handler_cgx_fec_stats(struct otx2_nic *pfvf,
+ struct cgx_fec_stats_rsp *rsp)
+{
+ pfvf->hw.cgx_fec_corr_blks += rsp->fec_corr_blks;
+ pfvf->hw.cgx_fec_uncorr_blks += rsp->fec_uncorr_blks;
+}
+
void mbox_handler_nix_txsch_alloc(struct otx2_nic *pf,
struct nix_txsch_alloc_rsp *rsp)
{
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
index 143ae04..b3f3de9 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_common.h
@@ -204,6 +204,8 @@ struct otx2_hw {
struct otx2_drv_stats drv_stats;
u64 cgx_rx_stats[CGX_RX_STATS_COUNT];
u64 cgx_tx_stats[CGX_TX_STATS_COUNT];
+ u64 cgx_fec_corr_blks;
+ u64 cgx_fec_uncorr_blks;
u8 cgx_links; /* No. of CGX links present in HW */
u8 lbk_links; /* No. of LBK links present in HW */
};
@@ -660,6 +662,9 @@ void mbox_handler_nix_txsch_alloc(struct otx2_nic *pf,
struct nix_txsch_alloc_rsp *rsp);
void mbox_handler_cgx_stats(struct otx2_nic *pfvf,
struct cgx_stats_rsp *rsp);
+void mbox_handler_cgx_fec_stats(struct otx2_nic *pfvf,
+ struct cgx_fec_stats_rsp *rsp);
+void otx2_set_fec_stats_count(struct otx2_nic *pfvf);
void mbox_handler_nix_bp_enable(struct otx2_nic *pfvf,
struct nix_bp_cfg_rsp *rsp);
@@ -668,6 +673,7 @@ void otx2_get_dev_stats(struct otx2_nic *pfvf);
void otx2_get_stats64(struct net_device *netdev,
struct rtnl_link_stats64 *stats);
void otx2_update_lmac_stats(struct otx2_nic *pfvf);
+void otx2_update_lmac_fec_stats(struct otx2_nic *pfvf);
int otx2_update_rq_stats(struct otx2_nic *pfvf, int qidx);
int otx2_update_sq_stats(struct otx2_nic *pfvf, int qidx);
void otx2_set_ethtool_ops(struct net_device *netdev);
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
index e0199f0..e5b1a57 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
@@ -66,6 +66,8 @@ static const unsigned int otx2_n_dev_stats =
ARRAY_SIZE(otx2_dev_stats);
static const unsigned int otx2_n_drv_stats = ARRAY_SIZE(otx2_drv_stats);
static const unsigned int otx2_n_queue_stats = ARRAY_SIZE(otx2_queue_stats);
+static struct cgx_fw_data *otx2_get_fwdata(struct otx2_nic *pfvf);
+
static void otx2_get_drvinfo(struct net_device *netdev,
struct ethtool_drvinfo *info)
{
@@ -128,6 +130,12 @@ static void otx2_get_strings(struct net_device *netdev,
u32 sset, u8 *data)
strcpy(data, "reset_count");
data += ETH_GSTRING_LEN;
+ if (pfvf->linfo.fec) {
+ sprintf(data, "Fec Corrected Errors: ");
+ data += ETH_GSTRING_LEN;
+ sprintf(data, "Fec Uncorrected Errors: ");
+ data +=
[Patch v2 net-next 2/7] octeontx2-af: Add new CGX_CMD to get PHY FEC statistics
From: Felix Manlunas
This patch adds support to fetch fec stats from PHY. The stats are
put in the shared data struct fwdata. A PHY driver indicates
that it has FEC stats by setting the flag fwdata.phy.misc.has_fec_stats
Besides CGX_CMD_GET_PHY_FEC_STATS, also add CGX_CMD_PRBS and
CGX_CMD_DISPLAY_EYE to enum cgx_cmd_id so that Linux's enum list is in sync
with firmware's enum list.
Signed-off-by: Felix Manlunas
Signed-off-by: Christina Jacob
Signed-off-by: Sunil Kovvuri Goutham
Signed-off-by: Hariprasad Kelam
---
drivers/net/ethernet/marvell/octeontx2/af/cgx.c| 12 ++
drivers/net/ethernet/marvell/octeontx2/af/cgx.h| 1 +
.../net/ethernet/marvell/octeontx2/af/cgx_fw_if.h | 5 +++
drivers/net/ethernet/marvell/octeontx2/af/mbox.h | 43 ++
drivers/net/ethernet/marvell/octeontx2/af/rvu.h| 4 ++
.../net/ethernet/marvell/octeontx2/af/rvu_cgx.c| 32
6 files changed, 97 insertions(+)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
index 5489dab..b3ae84c 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
@@ -859,6 +859,18 @@ int cgx_set_fec(u64 fec, int cgx_id, int lmac_id)
return err;
}
+int cgx_get_phy_fec_stats(void *cgxd, int lmac_id)
+{
+ struct cgx *cgx = cgxd;
+ u64 req = 0, resp;
+
+ if (!cgx)
+ return -ENODEV;
+
+ req = FIELD_SET(CMDREG_ID, CGX_CMD_GET_PHY_FEC_STATS, req);
+ return cgx_fwi_cmd_generic(req, , cgx, lmac_id);
+}
+
static int cgx_fwi_link_change(struct cgx *cgx, int lmac_id, bool enable)
{
u64 req = 0;
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
b/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
index 1824e95..c5294b7 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
+++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
@@ -154,5 +154,6 @@ void cgx_lmac_ptp_config(void *cgxd, int lmac_id, bool
enable);
u8 cgx_lmac_get_p2x(int cgx_id, int lmac_id);
int cgx_set_fec(u64 fec, int cgx_id, int lmac_id);
int cgx_get_fec_stats(void *cgxd, int lmac_id, struct cgx_fec_stats_rsp *rsp);
+int cgx_get_phy_fec_stats(void *cgxd, int lmac_id);
#endif /* CGX_H */
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx_fw_if.h
b/drivers/net/ethernet/marvell/octeontx2/af/cgx_fw_if.h
index 3485596..65f832a 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx_fw_if.h
+++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx_fw_if.h
@@ -89,6 +89,11 @@ enum cgx_cmd_id {
CGX_CMD_SET_AN,
CGX_CMD_GET_ADV_LINK_MODES,
CGX_CMD_GET_ADV_FEC,
+ CGX_CMD_GET_PHY_MOD_TYPE, /* line-side modulation type: NRZ or PAM4 */
+ CGX_CMD_SET_PHY_MOD_TYPE,
+ CGX_CMD_PRBS,
+ CGX_CMD_DISPLAY_EYE,
+ CGX_CMD_GET_PHY_FEC_STATS,
};
/* async event ids */
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
b/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
index a59a355..34e61a6 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
+++ b/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
@@ -151,6 +151,8 @@ M(CGX_CFG_PAUSE_FRM,0x20E, cgx_cfg_pause_frm,
cgx_pause_frm_cfg,\
cgx_pause_frm_cfg) \
M(CGX_FEC_SET, 0x210, cgx_set_fec_param, fec_mode, fec_mode) \
M(CGX_FEC_STATS, 0x211, cgx_fec_stats, msg_req, cgx_fec_stats_rsp) \
+M(CGX_GET_PHY_FEC_STATS, 0x212, cgx_get_phy_fec_stats, msg_req, msg_rsp) \
+M(CGX_FW_DATA_GET, 0x213, cgx_get_aux_link_info, msg_req, cgx_fw_data) \
/* NPA mbox IDs (range 0x400 - 0x5FF) */ \
/* NPA mbox IDs (range 0x400 - 0x5FF) */ \
M(NPA_LF_ALLOC,0x400, npa_lf_alloc,
\
@@ -411,6 +413,47 @@ struct fec_mode {
int fec;
};
+struct sfp_eeprom_s {
+#define SFP_EEPROM_SIZE 256
+ u16 sff_id;
+ u8 buf[SFP_EEPROM_SIZE];
+ u64 reserved;
+};
+
+struct phy_s {
+ struct {
+ u64 can_change_mod_type : 1;
+ u64 mod_type: 1;
+ u64 has_fec_stats : 1;
+ } misc;
+ struct fec_stats_s {
+ u32 rsfec_corr_cws;
+ u32 rsfec_uncorr_cws;
+ u32 brfec_corr_blks;
+ u32 brfec_uncorr_blks;
+ } fec_stats;
+};
+
+struct cgx_lmac_fwdata_s {
+ u16 rw_valid;
+ u64 supported_fec;
+ u64 supported_an;
+ u64 supported_link_modes;
+ /* only applicable if AN is supported */
+ u64 advertised_fec;
+ u64 advertised_link_modes;
+ /* Only applicable if SFP/QSFP slot is present */
+ struct sfp_eeprom_s sfp_eeprom;
+ struct phy_s phy;
+#define LMAC_FWDATA_RESERVED_MEM 1021
+ u64 reserved[LMAC_FWDATA_RESERVED_MEM];
+};
+
+struct cgx_fw_data {
+ struct mbox_msghdr hdr;
+
[Patch v2 net-next 7/7] octeontx2-pf: ethtool physical link configuration
From: Christina Jacob
Register set_link_ksetting callback with driver such that
link configurations parameters like advertised mode,speed, duplex
and autoneg can be configured.
below command
ethtool -s eth0 advertise 0x1 speed 10 duplex full autoneg on
Signed-off-by: Christina Jacob
Signed-off-by: Sunil Goutham
Signed-off-by: Hariprasad Kelam
---
.../ethernet/marvell/octeontx2/nic/otx2_ethtool.c | 53 ++
1 file changed, 53 insertions(+)
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
index b99f4bb..395a00d 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
@@ -1178,6 +1178,58 @@ static int otx2_get_link_ksettings(struct net_device
*netdev,
return 0;
}
+static int otx2_set_link_ksettings(struct net_device *netdev,
+ const struct ethtool_link_ksettings *cmd)
+{
+ struct otx2_nic *pf = netdev_priv(netdev);
+ struct ethtool_link_ksettings req_ks;
+ struct ethtool_link_ksettings cur_ks;
+ struct cgx_set_link_mode_req *req;
+ struct mbox *mbox = >mbox;
+ int err = 0;
+
+ /* save requested link settings */
+ memcpy(_ks, cmd, sizeof(struct ethtool_link_ksettings));
+
+ memset(_ks, 0, sizeof(struct ethtool_link_ksettings));
+
+ if (!ethtool_validate_speed(cmd->base.speed) ||
+ !ethtool_validate_duplex(cmd->base.duplex))
+ return -EINVAL;
+
+ if (cmd->base.autoneg != AUTONEG_ENABLE &&
+ cmd->base.autoneg != AUTONEG_DISABLE)
+ return -EINVAL;
+
+ otx2_get_link_ksettings(netdev, _ks);
+
+ /* Check requested modes against supported modes by hardware */
+ if (!bitmap_subset(req_ks.link_modes.advertising,
+ cur_ks.link_modes.supported,
+ __ETHTOOL_LINK_MODE_MASK_NBITS))
+ return -EINVAL;
+
+ mutex_lock(>lock);
+ req = otx2_mbox_alloc_msg_cgx_set_link_mode(>mbox);
+ if (!req) {
+ err = -ENOMEM;
+ goto end;
+ }
+
+ req->args.speed = req_ks.base.speed;
+ /* firmware expects 1 for half duplex and 0 for full duplex
+* hence inverting
+*/
+ req->args.duplex = req_ks.base.duplex ^ 0x1;
+ req->args.an = req_ks.base.autoneg;
+ req->args.mode = *req_ks.link_modes.advertising;
+
+ err = otx2_sync_mbox_msg(>mbox);
+end:
+ mutex_unlock(>lock);
+ return err;
+}
+
static const struct ethtool_ops otx2_ethtool_ops = {
.supported_coalesce_params = ETHTOOL_COALESCE_USECS |
ETHTOOL_COALESCE_MAX_FRAMES,
@@ -1208,6 +1260,7 @@ static const struct ethtool_ops otx2_ethtool_ops = {
.get_fecparam = otx2_get_fecparam,
.set_fecparam = otx2_set_fecparam,
.get_link_ksettings = otx2_get_link_ksettings,
+ .set_link_ksettings = otx2_set_link_ksettings,
};
void otx2_set_ethtool_ops(struct net_device *netdev)
--
2.7.4
arc-elf-ld: sil-sii8620.c:undefined reference to `extcon_unregister_notifier'
Hi Masahiro, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2ab38c17aac10bf55ab3efde4c4db3893d8691d2 commit: def2fbffe62c00c330c7f41584a356001179c59c kconfig: allow symbols implied by y to become m date: 11 months ago config: arc-randconfig-r016-20201229 (attached as .config) compiler: arc-elf-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=def2fbffe62c00c330c7f41584a356001179c59c git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout def2fbffe62c00c330c7f41584a356001179c59c # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): arc-elf-ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function `sii8620_remove': sil-sii8620.c:(.text+0x88): undefined reference to `extcon_unregister_notifier' >> arc-elf-ld: sil-sii8620.c:(.text+0x88): undefined reference to >> `extcon_unregister_notifier' arc-elf-ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function `sii8620_probe': >> sil-sii8620.c:(.text+0x1aac): undefined reference to >> `extcon_find_edev_by_node' >> arc-elf-ld: sil-sii8620.c:(.text+0x1aac): undefined reference to >> `extcon_find_edev_by_node' >> arc-elf-ld: sil-sii8620.c:(.text+0x1b10): undefined reference to >> `extcon_register_notifier' >> arc-elf-ld: sil-sii8620.c:(.text+0x1b10): undefined reference to >> `extcon_register_notifier' arc-elf-ld: drivers/gpu/drm/bridge/sil-sii8620.o: in function `sii8620_extcon_work': >> sil-sii8620.c:(.text+0x1b36): undefined reference to `extcon_get_state' >> arc-elf-ld: sil-sii8620.c:(.text+0x1b36): undefined reference to >> `extcon_get_state' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH] include: sysfs: Add macro to assign show for RO attributes
On Wed, Jan 27, 2021 at 12:19:22PM +0800, Orson Zhai wrote:
> In some circumstances, multiple __ATTR_RO attributes need to be assigned
> with a single show function.
>
> Add this macro to make life easier with simple code.
>
> Signed-off-by: Orson Zhai
> ---
> Documentation/filesystems/sysfs.rst | 2 ++
> include/linux/sysfs.h | 5 +
> 2 files changed, 7 insertions(+)
>
> diff --git a/Documentation/filesystems/sysfs.rst
> b/Documentation/filesystems/sysfs.rst
> index 004d490..0e2274a 100644
> --- a/Documentation/filesystems/sysfs.rst
> +++ b/Documentation/filesystems/sysfs.rst
> @@ -141,6 +141,8 @@ __ATTR_RO_MODE(name, mode):
>fore more restrictive RO access currently
> only use case is the EFI System Resource Table
> (see drivers/firmware/efi/esrt.c)
> +__ATTR_RO_SHOW(name, show):
> + assumes default mode 0444 with specified show.
> __ATTR_RW(name):
>assumes default name_show, name_store and setting
> mode to 0644.
> diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
> index 2caa34c..c851592 100644
> --- a/include/linux/sysfs.h
> +++ b/include/linux/sysfs.h
> @@ -117,6 +117,11 @@ struct attribute_group {
> .show = _name##_show, \
> }
>
> +#define __ATTR_RO_SHOW(_name, _show) {
> \
> + .attr = { .name = __stringify(_name), .mode = 0444 }, \
> + .show = _show,\
> +}
Do you have a real user for this? Using "raw" kobject attributes is
rare and should not be used often, so who needs this?
thanks,
greg k-h
Re: [PATCH RFC 1/2] dt: pci: designware-pcie.txt: convert it to yaml
Hi Marek, Em Tue, 26 Jan 2021 11:13:20 +0100 Marek Szyprowski escreveu: > Hi Mauro, > > On 26.01.2021 08:35, Mauro Carvalho Chehab wrote: > > Convert the file into a JSON description at the yaml format. > > > > Signed-off-by: Mauro Carvalho Chehab > > --- > > .../bindings/pci/amlogic,meson-pcie.txt | 4 +- > > .../bindings/pci/axis,artpec6-pcie.txt| 2 +- > > .../bindings/pci/designware,pcie.yaml | 194 ++ > > .../bindings/pci/designware-pcie.txt | 77 --- > > .../bindings/pci/fsl,imx6q-pcie.txt | 2 +- > > .../bindings/pci/hisilicon-histb-pcie.txt | 2 +- > > .../bindings/pci/hisilicon-pcie.txt | 2 +- > > .../devicetree/bindings/pci/kirin-pcie.txt| 2 +- > > .../bindings/pci/layerscape-pci.txt | 2 +- > > .../bindings/pci/nvidia,tegra194-pcie.txt | 4 +- > > .../devicetree/bindings/pci/pci-armada8k.txt | 2 +- > > .../devicetree/bindings/pci/pci-keystone.txt | 10 +- > > .../devicetree/bindings/pci/pcie-al.txt | 2 +- > > .../devicetree/bindings/pci/qcom,pcie.txt | 14 +- > > .../bindings/pci/samsung,exynos5440-pcie.txt | 4 +- > You must have used an old tree for preparing this patchset. The above > file is gone in v5.11-rc1 and there is > Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml instead. Yeah, this series was generated against v5.10, as part of my efforts to have Hikey 970 properly supported upstream: https://github.com/mchehab/linux/commits/devel/hikey970 For the next version, I'll rebase on the top of linux-next. Thanks, Mauro
Re: [PATCH] scripts/spelling.txt: increase error-prone spell checking
On Wed, 27 Jan 2021 11:01:05 +0800 dingsen...@163.com wrote: > From: dingsenjie > > Increase allocted spelling error check. I think you could improve the title and the commit message. You could refer to https://lore.kernel.org/lkml/7937a406-812e-0a41-12c5-41576737a...@lucaceresoli.net/ Thanks, SeongJae Park > > Signed-off-by: dingsenjie > --- > scripts/spelling.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/scripts/spelling.txt b/scripts/spelling.txt > index 953f4a2..5fa8ec2 100644 > --- a/scripts/spelling.txt > +++ b/scripts/spelling.txt > @@ -103,6 +103,7 @@ alloated||allocated > allocatote||allocate > allocatrd||allocated > allocte||allocate > +allocted||allocated > allpication||application > alocate||allocate > alogirhtms||algorithms > -- > 1.9.1 >
[Patch v2 net-next 5/7] octeontx2-af: advertised link modes support on cgx
From: Christina Jacob
CGX supports setting advertised link modes on physical link.
This patch adds support to derive cgx mode from ethtool
link mode and pass it to firmware to configure the same.
Signed-off-by: Christina Jacob
Signed-off-by: Sunil Goutham
Signed-off-by: Hariprasad Kelam
---
drivers/net/ethernet/marvell/octeontx2/af/cgx.c| 113 -
.../net/ethernet/marvell/octeontx2/af/cgx_fw_if.h | 32 +-
drivers/net/ethernet/marvell/octeontx2/af/mbox.h | 3 +-
3 files changed, 145 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
index 42ee67e..ff0e1db 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -644,6 +645,7 @@ static inline void cgx_link_usertable_init(void)
cgx_speed_mbps[CGX_LINK_25G] = 25000;
cgx_speed_mbps[CGX_LINK_40G] = 4;
cgx_speed_mbps[CGX_LINK_50G] = 5;
+ cgx_speed_mbps[CGX_LINK_80G] = 8;
cgx_speed_mbps[CGX_LINK_100G] = 10;
cgx_lmactype_string[LMAC_MODE_SGMII] = "SGMII";
@@ -691,6 +693,110 @@ static inline int cgx_link_usertable_index_map(int speed)
return CGX_LINK_NONE;
}
+static void set_mod_args(struct cgx_set_link_mode_args *args,
+u32 speed, u8 duplex, u8 autoneg, u64 mode)
+{
+ /* Fill default values incase of user did not pass
+* valid parameters
+*/
+ if (args->duplex == DUPLEX_UNKNOWN)
+ args->duplex = duplex;
+ if (args->speed == SPEED_UNKNOWN)
+ args->speed = speed;
+ if (args->an == AUTONEG_UNKNOWN)
+ args->an = autoneg;
+ args->mode = mode;
+ args->ports = 0;
+}
+
+static void otx2_map_ethtool_link_modes(u64 bitmask,
+ struct cgx_set_link_mode_args *args)
+{
+ switch (bitmask) {
+ case BIT_ULL(ETHTOOL_LINK_MODE_10baseT_Half_BIT):
+ set_mod_args(args, 10, 1, 1, BIT_ULL(CGX_MODE_SGMII));
+ break;
+ case BIT_ULL(ETHTOOL_LINK_MODE_10baseT_Full_BIT):
+ set_mod_args(args, 10, 0, 1, BIT_ULL(CGX_MODE_SGMII));
+ break;
+ case BIT_ULL(ETHTOOL_LINK_MODE_100baseT_Half_BIT):
+ set_mod_args(args, 100, 1, 1, BIT_ULL(CGX_MODE_SGMII));
+ break;
+ case BIT_ULL(ETHTOOL_LINK_MODE_100baseT_Full_BIT):
+ set_mod_args(args, 100, 0, 1, BIT_ULL(CGX_MODE_SGMII));
+ break;
+ case BIT_ULL(ETHTOOL_LINK_MODE_1000baseT_Half_BIT):
+ set_mod_args(args, 1000, 1, 1, BIT_ULL(CGX_MODE_SGMII));
+ break;
+ case BIT_ULL(ETHTOOL_LINK_MODE_1000baseT_Full_BIT):
+ set_mod_args(args, 1000, 0, 1, BIT_ULL(CGX_MODE_SGMII));
+ break;
+ case BIT_ULL(ETHTOOL_LINK_MODE_1000baseX_Full_BIT):
+ set_mod_args(args, 1000, 0, 0, BIT_ULL(CGX_MODE_1000_BASEX));
+ break;
+ case BIT_ULL(ETHTOOL_LINK_MODE_1baseT_Full_BIT):
+ set_mod_args(args, 1000, 0, 1, BIT_ULL(CGX_MODE_QSGMII));
+ break;
+ case BIT_ULL(ETHTOOL_LINK_MODE_1baseSR_Full_BIT):
+ set_mod_args(args, 1, 0, 0, BIT_ULL(CGX_MODE_10G_C2C));
+ break;
+ case BIT_ULL(ETHTOOL_LINK_MODE_1baseLR_Full_BIT):
+ set_mod_args(args, 1, 0, 0, BIT_ULL(CGX_MODE_10G_C2M));
+ break;
+ case BIT_ULL(ETHTOOL_LINK_MODE_1baseKR_Full_BIT):
+ set_mod_args(args, 1, 0, 1, BIT_ULL(CGX_MODE_10G_KR));
+ break;
+ case BIT_ULL(ETHTOOL_LINK_MODE_25000baseSR_Full_BIT):
+ set_mod_args(args, 25000, 0, 0, BIT_ULL(CGX_MODE_25G_C2C));
+ break;
+ case BIT_ULL(ETHTOOL_LINK_MODE_25000baseCR_Full_BIT):
+ set_mod_args(args, 25000, 0, 1, BIT_ULL(CGX_MODE_25G_CR));
+ break;
+ case BIT_ULL(ETHTOOL_LINK_MODE_25000baseKR_Full_BIT):
+ set_mod_args(args, 25000, 0, 1, BIT_ULL(CGX_MODE_25G_KR));
+ break;
+ case BIT_ULL(ETHTOOL_LINK_MODE_4baseSR4_Full_BIT):
+ set_mod_args(args, 4, 0, 0, BIT_ULL(CGX_MODE_40G_C2C));
+ break;
+ case BIT_ULL(ETHTOOL_LINK_MODE_4baseLR4_Full_BIT):
+ set_mod_args(args, 4, 0, 0, BIT_ULL(CGX_MODE_40G_C2M));
+ break;
+ case BIT_ULL(ETHTOOL_LINK_MODE_4baseCR4_Full_BIT):
+ set_mod_args(args, 4, 0, 1, BIT_ULL(CGX_MODE_40G_CR4));
+ break;
+ case BIT_ULL(ETHTOOL_LINK_MODE_4baseKR4_Full_BIT):
+ set_mod_args(args, 4, 0, 1, BIT_ULL(CGX_MODE_40G_KR4));
+ break;
+ case
[Patch v2 net-next 6/7] octeontx2-pf: ethtool physical link status
From: Christina Jacob
Register get_link_ksettings callback to get link status information
from the driver. As virtual function (vf) shares same physical link
same API is used for both the drivers and for loop back drivers
simply returns the fixed values as its does not have physical link.
ethtool eth3
Settings for eth3:
Supported ports: [ ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
1baseKR/Full
1000baseX/Full
Supports auto-negotiation: No
Supported FEC modes: BaseR RS
Advertised link modes: Not reported
Advertised pause frame use: No
Advertised auto-negotiation: No
Advertised FEC modes: None
ethtool lbk0
Settings for lbk0:
Speed: 10Mb/s
Duplex: Full
Signed-off-by: Christina Jacob
Signed-off-by: Sunil Goutham
Signed-off-by: Hariprasad Kelam
---
.../ethernet/marvell/octeontx2/nic/otx2_ethtool.c | 159 +
1 file changed, 159 insertions(+)
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
index e5b1a57..b99f4bb 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
@@ -32,6 +32,8 @@ struct otx2_stat {
.index = offsetof(struct otx2_dev_stats, stat) / sizeof(u64), \
}
+#define OTX2_ETHTOOL_SUPPORTED_MODES 0x638CCBF //11000111000110011001011
+#define OTX2_RESERVED_ETHTOOL_LINK_MODE0
static const struct otx2_stat otx2_dev_stats[] = {
OTX2_DEV_STAT(rx_ucast_frames),
OTX2_DEV_STAT(rx_bcast_frames),
@@ -1034,6 +1036,148 @@ static int otx2_set_fecparam(struct net_device *netdev,
return err;
}
+static void otx2_get_fec_info(u64 index, int mode, struct
ethtool_link_ksettings
+ *link_ksettings)
+{
+ switch (index) {
+ case OTX2_FEC_NONE:
+ if (mode)
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+advertising,
+FEC_NONE);
+ else
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+supported,
+FEC_NONE);
+ break;
+ case OTX2_FEC_BASER:
+ if (mode)
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+advertising,
+FEC_BASER);
+ else
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+supported,
+FEC_BASER);
+ break;
+ case OTX2_FEC_RS:
+ if (mode)
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+advertising,
+FEC_RS);
+ else
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+supported,
+FEC_RS);
+ break;
+ case OTX2_FEC_BASER | OTX2_FEC_RS:
+ if (mode) {
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+advertising,
+FEC_BASER);
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+advertising,
+FEC_RS);
+ } else {
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+supported,
+FEC_BASER);
+ ethtool_link_ksettings_add_link_mode(link_ksettings,
+supported,
+FEC_RS);
+ }
+
+ break;
+ }
+}
+
+static void otx2_get_link_mode_info(u64 index, int mode,
+ struct ethtool_link_ksettings
+ *link_ksettings)
+{
+ u64 ethtool_link_mode = 0;
+ int bit_position = 0;
+
[Patch v2 net-next 4/7] octeontx2-af: Physical link configuration support
From: Christina Jacob
CGX LMAC, the physical interface support link configuration parameters
like speed, auto negotiation, duplex etc. Firmware saves these into
memory region shared between firmware and this driver.
This patch adds mailbox handler set_link_mode, fw_data_get to
configure and read these parameters.
Signed-off-by: Christina Jacob
Signed-off-by: Sunil Goutham
Signed-off-by: Hariprasad Kelam
---
drivers/net/ethernet/marvell/octeontx2/af/cgx.c| 60 +-
drivers/net/ethernet/marvell/octeontx2/af/cgx.h| 2 +
.../net/ethernet/marvell/octeontx2/af/cgx_fw_if.h | 18 ++-
drivers/net/ethernet/marvell/octeontx2/af/mbox.h | 21
.../net/ethernet/marvell/octeontx2/af/rvu_cgx.c| 17 ++
5 files changed, 115 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
index b3ae84c..42ee67e 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.c
@@ -658,6 +658,39 @@ static inline void cgx_link_usertable_init(void)
cgx_lmactype_string[LMAC_MODE_USXGMII] = "USXGMII";
}
+static inline int cgx_link_usertable_index_map(int speed)
+{
+ switch (speed) {
+ case SPEED_10:
+ return CGX_LINK_10M;
+ case SPEED_100:
+ return CGX_LINK_100M;
+ case SPEED_1000:
+ return CGX_LINK_1G;
+ case SPEED_2500:
+ return CGX_LINK_2HG;
+ case SPEED_5000:
+ return CGX_LINK_5G;
+ case SPEED_1:
+ return CGX_LINK_10G;
+ case SPEED_2:
+ return CGX_LINK_20G;
+ case SPEED_25000:
+ return CGX_LINK_25G;
+ case SPEED_4:
+ return CGX_LINK_40G;
+ case SPEED_5:
+ return CGX_LINK_50G;
+ case 8:
+ return CGX_LINK_80G;
+ case SPEED_10:
+ return CGX_LINK_100G;
+ case SPEED_UNKNOWN:
+ return CGX_LINK_NONE;
+ }
+ return CGX_LINK_NONE;
+}
+
static inline void link_status_user_format(u64 lstat,
struct cgx_link_user_info *linfo,
struct cgx *cgx, u8 lmac_id)
@@ -667,6 +700,7 @@ static inline void link_status_user_format(u64 lstat,
linfo->link_up = FIELD_GET(RESP_LINKSTAT_UP, lstat);
linfo->full_duplex = FIELD_GET(RESP_LINKSTAT_FDUPLEX, lstat);
linfo->speed = cgx_speed_mbps[FIELD_GET(RESP_LINKSTAT_SPEED, lstat)];
+ linfo->an = FIELD_GET(RESP_LINKSTAT_AN, lstat);
linfo->fec = FIELD_GET(RESP_LINKSTAT_FEC, lstat);
linfo->lmac_type_id = cgx_get_lmac_type(cgx, lmac_id);
lmac_string = cgx_lmactype_string[linfo->lmac_type_id];
@@ -695,6 +729,9 @@ static inline void cgx_link_change_handler(u64 lstat,
lmac->link_info = event.link_uinfo;
linfo = >link_info;
+ if (err_type == CGX_ERR_SPEED_CHANGE_INVALID)
+ return;
+
/* Ensure callback doesn't get unregistered until we finish it */
spin_lock(>event_cb_lock);
@@ -723,7 +760,8 @@ static inline bool cgx_cmdresp_is_linkevent(u64 event)
id = FIELD_GET(EVTREG_ID, event);
if (id == CGX_CMD_LINK_BRING_UP ||
- id == CGX_CMD_LINK_BRING_DOWN)
+ id == CGX_CMD_LINK_BRING_DOWN ||
+ id == CGX_CMD_MODE_CHANGE)
return true;
else
return false;
@@ -838,6 +876,26 @@ int cgx_get_fwdata_base(u64 *base)
return err;
}
+int cgx_set_link_mode(void *cgxd, struct cgx_set_link_mode_args args,
+ int cgx_id, int lmac_id)
+{
+ struct cgx *cgx = cgxd;
+ u64 req = 0, resp;
+ int err = 0;
+
+ if (!cgx)
+ return -ENODEV;
+
+ req = FIELD_SET(CMDREG_ID, CGX_CMD_MODE_CHANGE, req);
+ req = FIELD_SET(CMDMODECHANGE_SPEED,
+ cgx_link_usertable_index_map(args.speed), req);
+ req = FIELD_SET(CMDMODECHANGE_DUPLEX, args.duplex, req);
+ req = FIELD_SET(CMDMODECHANGE_AN, args.an, req);
+ req = FIELD_SET(CMDMODECHANGE_PORT, args.ports, req);
+ req = FIELD_SET(CMDMODECHANGE_FLAGS, args.flags, req);
+ err = cgx_fwi_cmd_generic(req, , cgx, lmac_id);
+ return err;
+}
int cgx_set_fec(u64 fec, int cgx_id, int lmac_id)
{
u64 req = 0, resp;
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
b/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
index c5294b7..b458ad0 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
+++ b/drivers/net/ethernet/marvell/octeontx2/af/cgx.h
@@ -155,5 +155,7 @@ u8 cgx_lmac_get_p2x(int cgx_id, int lmac_id);
int cgx_set_fec(u64 fec, int cgx_id, int lmac_id);
int cgx_get_fec_stats(void *cgxd, int lmac_id, struct cgx_fec_stats_rsp *rsp);
int cgx_get_phy_fec_stats(void *cgxd, int lmac_id);
+int
[Patch v2 net-next 0/7] ethtool support for fec and link configuration
This series of patches add support for forward error correction(fec) and physical link configuration. Patches 1&2 adds necessary mbox handlers for fec mode configuration request and to fetch stats. Patch 3 registers driver callbacks for fec mode configuration and display. Patch 4&5 adds support of mbox handlers for configuring link parameters like speed/duplex and autoneg etc. Patche 6&7 registers driver callbacks for physical link configuration. Change-log: v2: -Fixed review comments - Corrected indentation issues - Return -ENOMEM incase of mbox allocation failure - added validation for input fecparams bitmask values - added more comments Christina Jacob (6): octeontx2-af: forward error correction configuration octeontx2-pf: ethtool fec mode support octeontx2-af: Physical link configuration support octeontx2-af: advertised link modes support on cgx octeontx2-pf: ethtool physical link status octeontx2-pf: ethtool physical link configuration Felix Manlunas (1): octeontx2-af: Add new CGX_CMD to get PHY FEC statistics drivers/net/ethernet/marvell/octeontx2/af/cgx.c| 257 +- drivers/net/ethernet/marvell/octeontx2/af/cgx.h| 10 + .../net/ethernet/marvell/octeontx2/af/cgx_fw_if.h | 70 +++- drivers/net/ethernet/marvell/octeontx2/af/mbox.h | 87 - drivers/net/ethernet/marvell/octeontx2/af/rvu.h| 4 + .../net/ethernet/marvell/octeontx2/af/rvu_cgx.c| 82 + .../ethernet/marvell/octeontx2/nic/otx2_common.c | 23 ++ .../ethernet/marvell/octeontx2/nic/otx2_common.h | 6 + .../ethernet/marvell/octeontx2/nic/otx2_ethtool.c | 393 - .../net/ethernet/marvell/octeontx2/nic/otx2_pf.c | 3 + 10 files changed, 928 insertions(+), 7 deletions(-) -- 2.7.4
Re: [PATCH] Revert "block: simplify set_init_blocksize" to regain lost performance
On Wed, Jan 27, 2021 at 6:23 AM Bart Van Assche wrote:
>
> On 1/26/21 11:59 AM, Maxim Mikityanskiy wrote:
> > The cited commit introduced a serious regression with SATA write speed,
> > as found by bisecting. This patch reverts this commit, which restores
> > write speed back to the values observed before this commit.
> >
> > The performance tests were done on a Helios4 NAS (2nd batch) with 4 HDDs
> > (WD8003FFBX) using dd (bs=1M count=2000). "Direct" is a test with a
> > single HDD, the rest are different RAID levels built over the first
> > partitions of 4 HDDs. Test results are in MB/s, R is read, W is write.
> >
> > | Direct | RAID0 | RAID10 f2 | RAID10 n2 | RAID6
> > ++---+---+---+
> > 9011495c9466| R:256 | R:313 | R:276 | R:313 | R:323
> > (before faulty) | W:254 | W:253 | W:195 | W:204 | W:117
> > ++---+---+---+
> > 5ff9f19231a0| R:257 | R:398 | R:312 | R:344 | R:391
> > (faulty commit) | W:154 | W:122 | W:67.7| W:66.6| W:67.2
> > ++---+---+---+
> > 5.10.10 | R:256 | R:401 | R:312 | R:356 | R:375
> > unpatched | W:149 | W:123 | W:64 | W:64.1| W:61.5
> > ++---+---+---+
> > 5.10.10 | R:255 | R:396 | R:312 | R:340 | R:393
> > patched | W:247 | W:274 | W:220 | W:225 | W:121
> >
> > Applying this patch doesn't hurt read performance, while improves the
> > write speed by 1.5x - 3.5x (more impact on RAID tests). The write speed
> > is restored back to the state before the faulty commit, and even a bit
> > higher in RAID tests (which aren't HDD-bound on this device) - that is
> > likely related to other optimizations done between the faulty commit and
> > 5.10.10 which also improved the read speed.
> >
> > Signed-off-by: Maxim Mikityanskiy
> > Fixes: 5ff9f19231a0 ("block: simplify set_init_blocksize")
> > Cc: Christoph Hellwig
> > Cc: Jens Axboe
> > ---
> > fs/block_dev.c | 10 +-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/block_dev.c b/fs/block_dev.c
> > index 3b8963e228a1..235b5042672e 100644
> > --- a/fs/block_dev.c
> > +++ b/fs/block_dev.c
> > @@ -130,7 +130,15 @@ EXPORT_SYMBOL(truncate_bdev_range);
> >
> > static void set_init_blocksize(struct block_device *bdev)
> > {
> > - bdev->bd_inode->i_blkbits =
> > blksize_bits(bdev_logical_block_size(bdev));
> > + unsigned int bsize = bdev_logical_block_size(bdev);
> > + loff_t size = i_size_read(bdev->bd_inode);
> > +
> > + while (bsize < PAGE_SIZE) {
> > + if (size & bsize)
> > + break;
> > + bsize <<= 1;
> > + }
> > + bdev->bd_inode->i_blkbits = blksize_bits(bsize);
> > }
> >
> > int set_blocksize(struct block_device *bdev, int size)
>
> How can this patch affect write speed? I haven't found any calls of
> set_init_blocksize() in the I/O path. Did I perhaps overlook something?
I don't know the exact mechanism how this change affects the speed,
I'm not an expert in the block device subsystem (I'm a networking
guy). This commit was found by git bisect, and my performance test
confirmed that reverting it fixes the bug.
It looks to me as this function sets the block size as part of control
flow, and this size is used later in the fast path, and the commit
that removed the loop decreased this block size.
> Bart.
>
>
Re: [PATCH] PCI: dwc: layerscape: convert to builtin_platform_driver()
Hi Saravana,
On Wed, Jan 27, 2021 at 1:44 AM Saravana Kannan wrote:
> On Tue, Jan 26, 2021 at 12:50 AM Geert Uytterhoeven
> wrote:
> > On Mon, Jan 25, 2021 at 11:42 PM Saravana Kannan
> > wrote:
> > > On Mon, Jan 25, 2021 at 11:49 AM Michael Walle wrote:
> > > > Am 2021-01-21 12:01, schrieb Geert Uytterhoeven:
> > > > > On Thu, Jan 21, 2021 at 1:05 AM Saravana Kannan
> > > > > wrote:
> > > > >> On Wed, Jan 20, 2021 at 3:53 PM Michael Walle
> > > > >> wrote:
> > > > >> > Am 2021-01-20 20:47, schrieb Saravana Kannan:
> > > > >> > > On Wed, Jan 20, 2021 at 11:28 AM Michael Walle
> > > > >> > > wrote:
> > > > >> > >>
> > > > >> > >> [RESEND, fat-fingered the buttons of my mail client and
> > > > >> > >> converted
> > > > >> > >> all CCs to BCCs :(]
> > > > >> > >>
> > > > >> > >> Am 2021-01-20 20:02, schrieb Saravana Kannan:
> > > > >> > >> > On Wed, Jan 20, 2021 at 6:24 AM Rob Herring
> > > > >> > >> > wrote:
> > > > >> > >> >>
> > > > >> > >> >> On Wed, Jan 20, 2021 at 4:53 AM Michael Walle
> > > > >> > >> >>
> > > > >> > >> >> wrote:
> > > > >> > >> >> >
> > > > >> > >> >> > fw_devlink will defer the probe until all suppliers are
> > > > >> > >> >> > ready. We can't
> > > > >> > >> >> > use builtin_platform_driver_probe() because it doesn't
> > > > >> > >> >> > retry after probe
> > > > >> > >> >> > deferral. Convert it to builtin_platform_driver().
> > > > >> > >> >>
> > > > >> > >> >> If builtin_platform_driver_probe() doesn't work with
> > > > >> > >> >> fw_devlink, then
> > > > >> > >> >> shouldn't it be fixed or removed?
> > > > >> > >> >
> > > > >> > >> > I was actually thinking about this too. The problem with
> > > > >> > >> > fixing
> > > > >> > >> > builtin_platform_driver_probe() to behave like
> > > > >> > >> > builtin_platform_driver() is that these probe functions could
> > > > >> > >> > be
> > > > >> > >> > marked with __init. But there are also only 20 instances of
> > > > >> > >> > builtin_platform_driver_probe() in the kernel:
> > > > >> > >> > $ git grep ^builtin_platform_driver_probe | wc -l
> > > > >> > >> > 20
> > > > >> > >> >
> > > > >> > >> > So it might be easier to just fix them to not use
> > > > >> > >> > builtin_platform_driver_probe().
> > > > >> > >> >
> > > > >> > >> > Michael,
> > > > >> > >> >
> > > > >> > >> > Any chance you'd be willing to help me by converting all
> > > > >> > >> > these to
> > > > >> > >> > builtin_platform_driver() and delete
> > > > >> > >> > builtin_platform_driver_probe()?
> > > > >> > >>
> > > > >> > >> If it just moving the probe function to the _driver struct and
> > > > >> > >> remove the __init annotations. I could look into that.
> > > > >> > >
> > > > >> > > Yup. That's pretty much it AFAICT.
> > > > >> > >
> > > > >> > > builtin_platform_driver_probe() also makes sure the driver
> > > > >> > > doesn't ask
> > > > >> > > for async probe, etc. But I doubt anyone is actually setting
> > > > >> > > async
> > > > >> > > flags and still using builtin_platform_driver_probe().
> > > > >> >
> > > > >> > Hasn't module_platform_driver_probe() the same problem? And there
> > > > >> > are ~80 drivers which uses that.
> > > > >>
> > > > >> Yeah. The biggest problem with all of these is the __init markers.
> > > > >> Maybe some familiar with coccinelle can help?
> > > > >
> > > > > And dropping them will increase memory usage.
> > > >
> > > > Although I do have the changes for the builtin_platform_driver_probe()
> > > > ready, I don't think it makes much sense to send these unless we agree
> > > > on the increased memory footprint. While there are just a few
> > > > builtin_platform_driver_probe() and memory increase _might_ be
> > > > negligible, there are many more module_platform_driver_probe().
> > >
> > > While it's good to drop code that'll not be used past kernel init, the
> > > module_platform_driver_probe() is going even more extreme. It doesn't
> > > even allow deferred probe (well before kernel init is done). I don't
> > > think that behavior is right and that's why we should delete it. Also,
> >
> > This construct is typically used for builtin hardware for which the
> > dependencies are registered very early, and thus known to probe at
> > first try (if present).
> >
> > > I doubt if any of these probe functions even take up 4KB of memory.
> >
> > How many 4 KiB pages do you have in a system with 10 MiB of SRAM?
> > How many can you afford to waste?
>
> There are only a few instances of this macro in the kernel. How many
$ git grep -lw builtin_platform_driver_probe | wc -l
21
$ git grep -lw module_platform_driver_probe | wc -l
86
+ the ones that haven't been converted to the above yet:
$ git grep -lw platform_driver_probe | wc -l
58
> of those actually fit the description above? We can probably just
> check the DT?
What do you mean by checking the DT?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations
[PATCH v4 3/5] drm/qxl: release shadow on shutdown
In case we have a shadow surface on shutdown release
it so it doesn't leak.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 38d6b596094d..60331e31861a 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -1229,5 +1229,9 @@ int qxl_modeset_init(struct qxl_device *qdev)
void qxl_modeset_fini(struct qxl_device *qdev)
{
+ if (qdev->dumb_shadow_bo) {
+ drm_gem_object_put(>dumb_shadow_bo->tbo.base);
+ qdev->dumb_shadow_bo = NULL;
+ }
qxl_destroy_monitors_object(qdev);
}
--
2.29.2
Re: [PATCH v3 1/2] perf tools: add 'perf irq' to measure the hardware interrupts
Hello,
On Sat, Jan 16, 2021 at 10:20 AM Bixuan Cui wrote:
>
> Add 'perf irq' to trace/measure the hardware interrupts.
>
> Now three functions are provided:
> 1. 'perf irq record ' to record the irq handler events.
> 2. 'perf irq script' to see a detailed trace of the workload that
>was recorded.
> 3. 'perf irq report' to calculate the time consumed by each
>hardware interrupt processing function.
>
> Signed-off-by: Bixuan Cui
> ---
> tools/perf/Build | 1 +
> tools/perf/builtin-irq.c | 283 +++
> tools/perf/builtin.h | 1 +
> tools/perf/perf.c| 1 +
> 4 files changed, 286 insertions(+)
> create mode 100644 tools/perf/builtin-irq.c
>
> diff --git a/tools/perf/Build b/tools/perf/Build
> index 5f392dbb88fc..d52a1e1d6d8a 100644
> --- a/tools/perf/Build
> +++ b/tools/perf/Build
> @@ -24,6 +24,7 @@ perf-y += builtin-mem.o
> perf-y += builtin-data.o
> perf-y += builtin-version.o
> perf-y += builtin-c2c.o
> +perf-y += builtin-irq.o
>
> perf-$(CONFIG_TRACE) += builtin-trace.o
> perf-$(CONFIG_LIBELF) += builtin-probe.o
> diff --git a/tools/perf/builtin-irq.c b/tools/perf/builtin-irq.c
> new file mode 100644
> index ..25ba0669a875
> --- /dev/null
> +++ b/tools/perf/builtin-irq.c
[SNIP]
> +
> +#define IRQ_NAME_LEN 20
> +#define MAX_CPUS 4096
> +
> +static const char *cpu_list;
> +static DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
> +
> +struct perf_irq;
Seems unnecessary.
> +
> +struct perf_irq {
> + struct perf_tool tool;
> + bool force;
> +
> + u32 irq_entry_irq;
> + char irq_name[IRQ_NAME_LEN];
> + u32 cpu;
> + u64 irq_entry_time;
> + u32 irq_entry_pid;
> + u32 irq_exit_irq;
> + u64 irq_exit_time;
> + u32 irq_exit_pid;
> +};
> +
> +typedef int (*irq_handler)(struct perf_tool *tool,
> + union perf_event *event,
> + struct evsel *evsel,
> + struct perf_sample *sample,
> + struct machine *machine);
You don't need to pass all the arguments if unused.
> +
> +static int perf_report_process_sample(struct perf_tool *tool,
> +union perf_event *event,
> +struct perf_sample *sample,
> +struct evsel *evsel,
> +struct machine *machine)
> +{
> + int err = 0;
> +
> + if (evsel->handler != NULL) {
> + irq_handler f = evsel->handler;
> + err = f(tool, event, evsel, sample, machine);
> + }
> +
> + return err;
> +}
> +
> +static void output_report(struct perf_irq *irq)
> +{
> + int ret, i;
> + char irq_entry_time[30], irq_exit_time[30], irq_diff[30];
> +
> + /* The entry and exit of the hardware irq function
> +* exist at the same time. Check it by irq and pid.
> +*/
> + if (irq->irq_entry_pid != irq->irq_exit_pid ||
> + irq->irq_entry_irq != irq->irq_exit_irq)
> + return;
Is there only a single instance of the perf_irq here?
Then I don't think this is correct and you should keep
pairs of irq entry/exit per cpu. Otherwise overlapped
irqs from different cpus will be discarded (wrongly).
> +
> + timestamp__scnprintf_usec(irq->irq_entry_time,
> + irq_entry_time, sizeof(irq_entry_time));
> + timestamp__scnprintf_usec(irq->irq_exit_time,
> + irq_exit_time, sizeof(irq_exit_time));
> + timestamp__scnprintf_usec(irq->irq_exit_time - irq->irq_entry_time,
> + irq_diff, sizeof(irq_diff));
> +
> + ret = printf(" %s ", irq->irq_name);
> + for (i = 0; i < IRQ_NAME_LEN - ret; i++)
> + printf(" ");
> +
> + printf("| [%04d] | %13s s | %16s s | %16s s\n",
> + irq->cpu, irq_diff, irq_entry_time, irq_exit_time);
> +}
> +
> +static int report_irq_handler_entry_event(struct perf_tool *tool,
> + union perf_event *event __maybe_unused,
> + struct evsel *evsel,
> + struct perf_sample *sample,
> + struct machine *machine __maybe_unused)
> +{
> + int err = 0;
> + struct perf_irq *irq = container_of(tool, struct perf_irq, tool);
> +
> + const char *name = evsel__strval(evsel, sample, "name");
> +
> + irq->irq_entry_pid = evsel__intval(evsel, sample, "pid");
> + irq->irq_entry_irq = evsel__intval(evsel, sample, "irq");
> + irq->irq_entry_time = sample->time;
> + strncpy(irq->irq_name, name, IRQ_NAME_LEN);
Note that strncpy doesn't guarantee the NUL-termination.
You'd better do it by yourself just in case.
Thanks,
Namhyung
> +
> + return err;
> +}
> +
> +static
Re: [PATCH 1/1] MAINTAINERS: remove myself from the list
Hi, On 1/27/21 3:18 AM, Hyun Kwon wrote: > Hi Laurent, > > On Tue, Jan 26, 2021 at 05:37:02PM -0800, Laurent Pinchart wrote: >> Hi Hyun, >> >> Thank you for the patch. >> >> On Tue, Jan 26, 2021 at 05:13:12PM -0800, Hyun Kwon wrote: >>> The email will become invalid soon. >> >> Is there, by any chance, anyone at Xilinx would could help maintaining >> these drivers ? >> > > Yes, there will be. I gave my recommendations, but it's still under > discussion. > I'll ensure it's decided sooner than later. I am still around and I will make sure that someone will take a look at it. Just let me know that you are expecting any input from Xilinx till we have someone. Thanks, Michal
RE: [PATCH] mmc: core: Apply trim broken quirk to R1J57L
> -Original Message-
> From: Ulf Hansson [mailto:ulf.hans...@linaro.org]
> Sent: 2021年1月21日 21:26
> To: Wang, Xiaolei ; Fabio Estevam
> ; Bough Chen
> Cc: Pali Rohár ; Lee Jones ;
> linux-...@vger.kernel.org; Linux Kernel Mailing List
>
> Subject: Re: [PATCH] mmc: core: Apply trim broken quirk to R1J57L
>
> + Fabio, Haibo
>
> On Thu, 21 Jan 2021 at 10:54, Wang, Xiaolei
> wrote:
> >
> > Hi
> >
> > >Are you sure this is an eMMC problem and not a mmc host driver issue?
> >
> > >Can you elaborate more what happens?
> >
> > When I use the mkfs.f2fs tool to format the eMMC file system on the
> > imx8qxp board, because mkfs.f2fs will use secdiscard first, when
> > entering mmc_blk_issue_secdiscard_rq erase, once the parameters are
> passed into MMC_SECURE_TRIM1_ARG, this function will take a long time to
> return .
> > The program has not ended, has been in TASK_UNINTERRUPTIBLE state.
> >
> > I compared the mkfs.ext4 tool to format the file system. Because it
> > directly uses mmc_blk_issue_discard_rq, this is a normal formatting
> phenomenon.
> >
> > mmc_blk_issue_secdiscard_rq and mmc_blk_issue_discard_rq are just
> different commands and parameters sent by the host as a bus.
> > I did not see the description of trim in the data sheet. Could the host
> > driver
> cause this problem?
>
> Yes, it can - and we have had issues like these before. So before adding a
> card
> quirk, I think we need to make sure this isn't the case.
>
> When using MMC_SECURE_TRIM1_ARG, it's very likely that the request takes
> longer to complete.
>
> The mmc host is responsible for either dealing with busy detection with the
> help of its HW/controller - or if that can't be supported, the mmc core falls
> back
> to polling the card for busy with a CMD13.
>
> See mmc_do_erase() in /drivers/mmc/core/core.c
>
> >
> > Note:
> > The host driver I use is sdhci-esdhc-imx.c
>
> Alright, I have looped in Fabio and Haibo that knows this driver, let's see
> if they
> can help.
>
Hi Ulf and Xiaolei,
I use the mkfs.f2fs tool format a partition on one Sandisk eMMC chip on imx8
platform, do not meet issue.
I add some log, confirm mkfs.f2fs call the mmc_blk_issue_secdiscard_rq(), and
the arg is MMC_SECURE_TRIM1_ARG.
For the busy detection, imx usdhc has one register bit represent the dat0
signal level. So for your mmc device, it should be the mmc device trim feature
problem.
Best Regards
Haibo
> >
> > Thanks
> > Xiaolei
>
> Kind regards
> Uffe
>
> >
> > -Original Message-
> > From: Ulf Hansson
> > Sent: Wednesday, January 20, 2021 9:41 PM
> > To: Wang, Xiaolei
> > Cc: Pali Rohár ; Lee Jones ;
> > linux-...@vger.kernel.org; Linux Kernel Mailing List
> >
> > Subject: Re: [PATCH] mmc: core: Apply trim broken quirk to R1J57L
> >
> > [Please note this e-mail is from an EXTERNAL e-mail address]
> >
> > On Mon, 18 Jan 2021 at 05:27, Xiaolei Wang
> wrote:
> > >
> > > R1J57L mmc chip hw capibility indicates that it supports trim
> > > function, but this function does not work properly, the SDIO bus
> > > does not respond, and the IO has been waiting so set quirks to skip
> > > trim
> >
> > Are you sure this is an eMMC problem and not a mmc host driver issue?
> >
> > Can you elaborate more what happens?
> >
> > Kind regards
> > Uffe
> >
> > >
> > > Signed-off-by: Xiaolei Wang
> > > ---
> > > drivers/mmc/core/quirks.h | 4
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/mmc/core/quirks.h b/drivers/mmc/core/quirks.h
> > > index d68e6e513a4f..63e02391c133 100644
> > > --- a/drivers/mmc/core/quirks.h
> > > +++ b/drivers/mmc/core/quirks.h
> > > @@ -89,6 +89,8 @@ static const struct mmc_fixup __maybe_unused
> mmc_blk_fixups[] = {
> > > MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> > > MMC_FIXUP("VZL00M", CID_MANFID_SAMSUNG,
> CID_OEMID_ANY, add_quirk_mmc,
> > > MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> > > + MMC_FIXUP("R1J57L", CID_MANFID_MICRON,
> CID_OEMID_ANY, add_quirk_mmc,
> > > + MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
> > >
> > > /*
> > > * On Some Kingston eMMCs, performing trim can result in
> @@
> > > -98,6 +100,8 @@ static const struct mmc_fixup __maybe_unused
> mmc_blk_fixups[] = {
> > > MMC_QUIRK_TRIM_BROKEN),
> > > MMC_FIXUP("V10016", CID_MANFID_KINGSTON,
> CID_OEMID_ANY, add_quirk_mmc,
> > > MMC_QUIRK_TRIM_BROKEN),
> > > + MMC_FIXUP("R1J57L", CID_MANFID_MICRON,
> CID_OEMID_ANY, add_quirk_mmc,
> > > + MMC_QUIRK_TRIM_BROKEN),
> > >
> > > END_FIXUP
> > > };
> > > --
> > > 2.25.1
> > >
Re: [PATCH 1/1] iommu/arm-smmu-v3: add support for BBML
On 2021/1/27 10:01, Leizhen (ThunderTown) wrote: > > > On 2021/1/26 18:12, Will Deacon wrote: >> On Mon, Jan 25, 2021 at 08:23:40PM +, Robin Murphy wrote: >>> Now we probably will need some degreee of BBML feature awareness for the >>> sake of SVA if and when we start using it for CPU pagetables, but I still >>> cannot see any need to consider it in io-pgtable. >> >> Agreed; I don't think this is something that io-pgtable should have to care >> about. Hi, I have a question here :-). If the old table is not live, then the break procedure seems unnecessary. Do I miss something? Thanks, Keqian > > Yes, the SVA works in stall mode, and the failed device access requests are > not > discarded. > > Let me look for examples. The BBML usage scenario was told by a former > colleague. > >> >> Will >> >> . >> > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > . >
Re: [PATCH BUGFIX/IMPROVEMENT 6/6] block, bfq: merge bursts of newly-created queues
Hi Paolo,
I love your patch! Perhaps something to improve:
[auto build test WARNING on block/for-next]
[cannot apply to v5.11-rc5 next-20210125]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Paolo-Valente/block-bfq-third-and-last-batch-of-fixes-and-improvements/20210127-090045
base: https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git
for-next
config: nds32-randconfig-r033-20210126 (attached as .config)
compiler: nds32le-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/2d32d2f7e624f94a180d6a6acfeea65c0c511fe1
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Paolo-Valente/block-bfq-third-and-last-batch-of-fixes-and-improvements/20210127-090045
git checkout 2d32d2f7e624f94a180d6a6acfeea65c0c511fe1
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=nds32
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> block/bfq-iosched.c:5340:1: warning: no previous prototype for
>> 'bfq_do_early_stable_merge' [-Wmissing-prototypes]
5340 | bfq_do_early_stable_merge(struct bfq_data *bfqd, struct bfq_queue
*bfqq,
| ^
vim +/bfq_do_early_stable_merge +5340 block/bfq-iosched.c
5338
5339 struct bfq_queue *
> 5340 bfq_do_early_stable_merge(struct bfq_data *bfqd, struct bfq_queue *bfqq,
5341struct bfq_io_cq *bic,
5342struct bfq_queue *last_bfqq_created)
5343 {
5344 struct bfq_queue *new_bfqq =
5345 bfq_setup_merge(bfqq, last_bfqq_created);
5346
5347 if (!new_bfqq)
5348 return bfqq;
5349
5350 if (new_bfqq->bic)
5351 new_bfqq->bic->stably_merged = true;
5352 bic->stably_merged = true;
5353
5354 /*
5355 * Reusing merge functions. This implies that
5356 * bfqq->bic must be set too, for
5357 * bfq_merge_bfqqs to correctly save bfqq's
5358 * state before killing it.
5359 */
5360 bfqq->bic = bic;
5361 bfq_merge_bfqqs(bfqd, bic, bfqq, new_bfqq);
5362
5363 return new_bfqq;
5364 }
5365
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [RFC PATCH 6/8] preempt/dynamic: Provide preempt_schedule[_notrace]() static calls
On Fri, Jan 22, 2021 at 05:52:26PM +0100, Peter Zijlstra wrote:
> static int static_call_add_module(struct module *mod)
> {
> - return __static_call_init(mod, mod->static_call_sites,
> - mod->static_call_sites +
> mod->num_static_call_sites);
> + struct static_call_site *start = mod->static_call_sites;
> + struct static_call_site *stop = start + mod->num_static_call_sites;
> + struct static_call_site *site;
> +
> + for (site = start; site != stop; site++) {
> + unsigned long addr = (unsigned long)static_call_key(site);
> + struct static_call_ass *ass;
> +
> + /*
> + * Gotta fix up the keys that point to the trampoline.
> + */
> + if (!kernel_text_address(addr))
> + continue;
> +
> + ass = static_call_find_ass(addr);
> + if (!ass) {
> + pr_warn("Failed to fixup __raw_static_call() usage at:
> %ps\n",
> + static_call_addr(site));
> + return -EINVAL;
> + }
> + site->key = ((unsigned long)ass->key - (unsigned
> long)>key) |
> + (site->key & STATIC_CALL_SITE_FLAGS);
Well, I hate it, but I'm not sure I have any better ideas. It should be
possible to use kallsyms, instead of the rb-tree/register nonsense. Not
sure about the performance impact though. Might be a good reason to
speed up kallsyms!
Also I do have some naming suggestions ;-)
--
Josh
Re: [PATCH 0/2] introduce DUMP_PREFIX_UNHASHED for hex dumps
On 1/26/21 10:47 AM, Vlastimil Babka wrote: Given Linus' current stance later in this thread, could we revive the idea of a boot time option, or at least a CONFIG (I assume a runtime toggle would be too much, even if limited to !kernel_lockdown:) , that would disable all hashing? It would be really useful for a development/active debugging, as evidenced below. Thanks. So you're saying: if CONFIG_PRINTK_NEVER_HASH is disabled, then %p prints hashed addresses and %px prints unhashed. If CONFIG_PRINTK_NEVER_HASH is enabled, then %p and %px both print unhashed addresses. I like this idea, and I would accept it as a solution if I had to, but I still would also like for an option for print_hex_dump() to print unhashed addresses even when CONFIG_PRINTK_NEVER_HASH is disabled. I can't always recompile the entire kernel for my testing purposes. The only drawback to this idea is: what happens if distros start enabling CONFIG_PRINTK_NEVER_HASH by default, just because it makes debugging easier?
[PATCH v2] mfd: max8997: Replace 8998 with 8997
The max8997 header is using "max8998" in some identifiers.
Fix it by replacing 8998 with 8997 in enum and macro.
Signed-off-by: Timon Baetz
---
v2: Fix commit message.
include/linux/mfd/max8997.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/mfd/max8997.h b/include/linux/mfd/max8997.h
index e955e2f0a2cc..6c98edcf4b0b 100644
--- a/include/linux/mfd/max8997.h
+++ b/include/linux/mfd/max8997.h
@@ -14,13 +14,13 @@
* others and b) it can be enabled simply by using MAX17042 driver.
*/
-#ifndef __LINUX_MFD_MAX8998_H
-#define __LINUX_MFD_MAX8998_H
+#ifndef __LINUX_MFD_MAX8997_H
+#define __LINUX_MFD_MAX8997_H
#include
/* MAX8997/8966 regulator IDs */
-enum max8998_regulators {
+enum max8997_regulators {
MAX8997_LDO1 = 0,
MAX8997_LDO2,
MAX8997_LDO3,
@@ -207,4 +207,4 @@ struct max8997_platform_data {
struct max8997_led_platform_data *led_pdata;
};
-#endif /* __LINUX_MFD_MAX8998_H */
+#endif /* __LINUX_MFD_MAX8997_H */
--
2.25.1
Re: [PATCH 5.10 000/199] 5.10.11-rc1 review
On 1/26/21 4:34 PM, Shuah Khan wrote: On 1/25/21 11:37 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 5.10.11 release. There are 199 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed, 27 Jan 2021 18:31:44 +. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.11-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. Tested-by: Shuah Khan Please ignore this. I tested rc2. thanks, -- Shuah
Re: [PATCH v4 0/8] Create 'old' ptes for faultaround mappings on arm64 with hardware access flag
On Tue, 26 Jan 2021, Will Deacon wrote: > On Wed, Jan 20, 2021 at 05:36:04PM +, Will Deacon wrote: > > Hi all, > > > > This is version four of the patches I previously posted here: > > > > v1: https://lore.kernel.org/r/20201209163950.8494-1-w...@kernel.org > > v2: https://lore.kernel.org/r/20210108171517.5290-1-w...@kernel.org > > v3: https://lore.kernel.org/r/20210114175934.13070-1-w...@kernel.org > > > > The patches allow architectures to opt-in at runtime for faultaround > > mappings to be created as 'old' instead of 'young'. Although there have > > been previous attempts at this, they failed either because the decision > > was deferred to userspace [1] or because it was done unconditionally and > > shown to regress benchmarks for particular architectures [2]. > > > > The big change since v3 is that the immutable fields of 'struct vm_fault' > > now live in a 'const' anonymous struct. Although Clang will silently > > accept modifications to these fields [3], GCC emits an error. The > > resulting diffstat is _considerably_ more manageable with this approach. > > The only changes I have pending against this series are cosmetic (commit > logs). Can I go ahead and queue this in the arm64 tree so that it can sit > in linux-next for a bit? (positive or negative feedback appreciated!). That would be fine by me: I ran v3 on rc3, then the nicer smaller v4 on rc4, and saw no problems when running either of them (x86_64 only). Hugh
Re: linux-next: manual merge of the pidfd tree with the xfs tree
Hi all,
On Mon, 25 Jan 2021 17:14:14 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the pidfd tree got a conflict in:
>
> fs/xfs/xfs_inode.c
>
> between commit:
>
> 01ea173e103e ("xfs: fix up non-directory creation in SGID directories")
>
> from the xfs tree and commit:
>
> f736d93d76d3 ("xfs: support idmapped mounts")
>
> from the pidfd tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc fs/xfs/xfs_inode.c
> index e2a1db4cee43,95b7f2ba4e06..
> --- a/fs/xfs/xfs_inode.c
> +++ b/fs/xfs/xfs_inode.c
> @@@ -809,13 -810,13 +810,13 @@@ xfs_init_new_inode
> inode->i_rdev = rdev;
> ip->i_d.di_projid = prid;
>
> -if (pip && XFS_INHERIT_GID(pip)) {
> -inode->i_gid = VFS_I(pip)->i_gid;
> -if ((VFS_I(pip)->i_mode & S_ISGID) && S_ISDIR(mode))
> -inode->i_mode |= S_ISGID;
> +if (dir && !(dir->i_mode & S_ISGID) &&
> +(mp->m_flags & XFS_MOUNT_GRPID)) {
> +inode->i_uid = current_fsuid();
Looking a bit harder, I replaced the above line with
inode->i_uid = fsuid_into_mnt(mnt_userns);
> +inode->i_gid = dir->i_gid;
> +inode->i_mode = mode;
> } else {
> - inode_init_owner(inode, dir, mode);
> -inode->i_gid = fsgid_into_mnt(mnt_userns);
> ++inode_init_owner(mnt_userns, inode, dir, mode);
> }
>
> /*
--
Cheers,
Stephen Rothwell
pgpJjzqcFID9U.pgp
Description: OpenPGP digital signature
Re: [PATCH v5 1/5] dt-bindings: aspeed-lpc: Remove LPC partitioning
On Thu, 14 Jan 2021, at 23:46, Chia-Wei, Wang wrote: > The LPC controller has no concept of the BMC and the Host partitions. > This patch fixes the documentation by removing the description on LPC > partitions. The register offsets illustrated in the DTS node examples > are also fixed to adapt to the LPC DTS change. > > Signed-off-by: Chia-Wei, Wang Any thoughts Lee? If you ack it would you be happy for the patch to go through the Aspeed tree? Andrew
Re: [PATCH v6 3/4] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements
On 1/26/2021 12:43 PM, Thinh Nguyen wrote:
> Wesley Cheng wrote:
>>
>> On 1/22/2021 4:15 PM, Thinh Nguyen wrote:
>>> Hi,
>>>
>>> Wesley Cheng wrote:
Some devices have USB compositions which may require multiple endpoints
that support EP bursting. HW defined TX FIFO sizes may not always be
sufficient for these compositions. By utilizing flexible TX FIFO
allocation, this allows for endpoints to request the required FIFO depth to
achieve higher bandwidth. With some higher bMaxBurst configurations, using
a larger TX FIFO size results in better TX throughput.
By introducing the check_config() callback, the resizing logic can fetch
the maximum number of endpoints used in the USB composition (can contain
multiple configurations), which helps ensure that the resizing logic can
fulfill the configuration(s), or return an error to the gadget layer
otherwise during bind time.
Signed-off-by: Wesley Cheng
---
drivers/usb/dwc3/core.c | 2 +
drivers/usb/dwc3/core.h | 8 ++
drivers/usb/dwc3/ep0.c| 2 +
drivers/usb/dwc3/gadget.c | 194
++
4 files changed, 206 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 6969196..e7fa6af 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1284,6 +1284,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
_thr_num_pkt_prd);
device_property_read_u8(dev, "snps,tx-max-burst-prd",
_max_burst_prd);
+ dwc->needs_fifo_resize = device_property_read_bool(dev,
+ "tx-fifo-resize");
dwc->disable_scramble_quirk = device_property_read_bool(dev,
"snps,disable_scramble_quirk");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index eec1cf4..983b2fd4 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -1223,6 +1223,7 @@ struct dwc3 {
unsignedis_utmi_l1_suspend:1;
unsignedis_fpga:1;
unsignedpending_events:1;
+ unsignedneeds_fifo_resize:1;
>>> The prefix "need" sounds like a requirement, but I don't think it is the
>>> case here. I think "do" would be a better prefix here.
>>>
>> Hi Thinh,
>>
>> Sure, that is true, since this may be an optional flag for certain
>> platforms.
>>
unsignedpullups_connected:1;
unsignedsetup_packet_pending:1;
unsignedthree_stage_setup:1;
@@ -1257,6 +1258,10 @@ struct dwc3 {
unsigneddis_split_quirk:1;
u16 imod_interval;
+
+ int max_cfg_eps;
+ int last_fifo_depth;
+ int num_ep_resized;
};
>>> Please document these new fields.
>>>
>> Will do.
>>
#define INCRX_BURST_MODE 0
@@ -1471,6 +1476,7 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep,
unsigned int cmd,
struct dwc3_gadget_ep_cmd_params *params);
int dwc3_send_gadget_generic_command(struct dwc3 *dwc, unsigned int cmd,
u32 param);
+void dwc3_gadget_clear_tx_fifos(struct dwc3 *dwc);
#else
static inline int dwc3_gadget_init(struct dwc3 *dwc)
{ return 0; }
@@ -1490,6 +1496,8 @@ static inline int dwc3_send_gadget_ep_cmd(struct
dwc3_ep *dep, unsigned int cmd,
static inline int dwc3_send_gadget_generic_command(struct dwc3 *dwc,
int cmd, u32 param)
{ return 0; }
+static inline void dwc3_gadget_clear_tx_fifos(struct dwc3 *dwc)
+{ }
#endif
#if IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 8b668ef..4f216bd 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -616,6 +616,8 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc,
struct usb_ctrlrequest *ctrl)
return -EINVAL;
case USB_STATE_ADDRESS:
+ dwc3_gadget_clear_tx_fifos(dwc);
+
ret = dwc3_ep0_delegate_req(dwc, ctrl);
/* if the cfg matches and the cfg is non zero */
if (cfg && (!ret || (ret == USB_GADGET_DELAYED_STATUS))) {
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 86f257f..26f9d64 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -615,6 +615,161 @@ static int dwc3_gadget_set_ep_config(struct dwc3_ep
*dep, unsigned int action)
static void dwc3_stop_active_transfer(struct dwc3_ep *dep, bool force,
bool interrupt);
+static
[PATCH v6] fbtft: add tearing signal detect
From: zhangxuezhi
For st7789v ic,add tearing signal detect to avoid screen tearing
Signed-off-by: zhangxuezhi
---
v6: add te gpio request fail deal logic
---
drivers/staging/fbtft/fb_st7789v.c | 133 -
drivers/staging/fbtft/fbtft.h | 1 +
2 files changed, 133 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/fbtft/fb_st7789v.c
b/drivers/staging/fbtft/fb_st7789v.c
index 3a280cc..777391e 100644
--- a/drivers/staging/fbtft/fb_st7789v.c
+++ b/drivers/staging/fbtft/fb_st7789v.c
@@ -9,9 +9,12 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
-
+#include
#include "fbtft.h"
#define DRVNAME "fb_st7789v"
@@ -66,6 +69,32 @@ enum st7789v_command {
#define MADCTL_MX BIT(6) /* bitmask for column address order */
#define MADCTL_MY BIT(7) /* bitmask for page address order */
+#define SPI_PANEL_TE_TIMEOUT 400
+static struct mutex te_mutex;/*mutex for tearing line*/
+static struct completion spi_panel_te;
+
+static irqreturn_t spi_panel_te_handler(int irq, void *data)
+{
+ complete(_panel_te);
+ return IRQ_HANDLED;
+}
+
+static void set_spi_panel_te_irq_status(struct fbtft_par *par, bool enable)
+{
+ static int te_irq_count;
+
+ mutex_lock(_mutex);
+
+ if (enable) {
+ if (++te_irq_count == 1)
+ enable_irq(gpiod_to_irq(par->gpio.te));
+ } else {
+ if (--te_irq_count == 0)
+ disable_irq(gpiod_to_irq(par->gpio.te));
+ }
+ mutex_unlock(_mutex);
+}
+
/**
* init_display() - initialize the display controller
*
@@ -82,6 +111,34 @@ enum st7789v_command {
*/
static int init_display(struct fbtft_par *par)
{
+ int rc;
+ struct device *dev = par->info->device;
+
+ par->gpio.te = devm_gpiod_get_index_optional(dev, "te", 0, GPIOD_IN);
+ if (IS_ERR(par->gpio.te)) {
+ rc = PTR_ERR(par->gpio.te);
+ pr_err("Failed to request te gpio: %d\n", rc);
+ par->gpio.te = NULL;
+ }
+ if (par->gpio.te) {
+ init_completion(_panel_te);
+ mutex_init(_mutex);
+ rc = devm_request_irq(dev,
+ gpiod_to_irq(par->gpio.te),
+spi_panel_te_handler, IRQF_TRIGGER_RISING,
+"TE_GPIO", par);
+ if (rc) {
+ pr_err("TE request_irq failed.\n");
+ devm_gpiod_put(dev, par->gpio.te);
+ par->gpio.te = NULL;
+ } else {
+ disable_irq_nosync(gpiod_to_irq(par->gpio.te));
+ pr_info("TE request_irq completion.\n");
+ }
+ } else {
+ pr_info("%s:%d, TE gpio not specified\n",
+ __func__, __LINE__);
+ }
/* turn off sleep mode */
write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
mdelay(120);
@@ -137,6 +194,9 @@ static int init_display(struct fbtft_par *par)
*/
write_reg(par, PWCTRL1, 0xA4, 0xA1);
+/*Tearing Effect Line On*/
+ if (par->gpio.te)
+ write_reg(par, 0x35, 0x00);
write_reg(par, MIPI_DCS_SET_DISPLAY_ON);
if (HSD20_IPS)
@@ -145,6 +205,76 @@ static int init_display(struct fbtft_par *par)
return 0;
}
+/*
+ *
+ * int (*write_vmem)(struct fbtft_par *par);
+ *
+ */
+
+/* 16 bit pixel over 8-bit databus */
+static int st7789v_write_vmem16_bus8(struct fbtft_par *par, size_t offset,
size_t len)
+{
+ u16 *vmem16;
+ __be16 *txbuf16 = par->txbuf.buf;
+ size_t remain;
+ size_t to_copy;
+ size_t tx_array_size;
+ int i;
+ int ret = 0;
+ size_t startbyte_size = 0;
+
+ fbtft_par_dbg(DEBUG_WRITE_VMEM, par, "st7789v ---%s(offset=%zu,
len=%zu)\n",
+ __func__, offset, len);
+
+ remain = len / 2;
+ vmem16 = (u16 *)(par->info->screen_buffer + offset);
+
+ if (par->gpio.dc)
+ gpiod_set_value(par->gpio.dc, 1);
+
+ /* non buffered write */
+ if (!par->txbuf.buf)
+ return par->fbtftops.write(par, vmem16, len);
+
+ /* buffered write */
+ tx_array_size = par->txbuf.len / 2;
+
+ if (par->startbyte) {
+ txbuf16 = par->txbuf.buf + 1;
+ tx_array_size -= 2;
+ *(u8 *)(par->txbuf.buf) = par->startbyte | 0x2;
+ startbyte_size = 1;
+ }
+
+ while (remain) {
+ to_copy = min(tx_array_size, remain);
+ dev_dbg(par->info->device, "to_copy=%zu, remain=%zu\n",
+ to_copy, remain - to_copy);
+
+ for (i = 0; i < to_copy; i++)
+
Re: [PATCH v2] KVM: kvmclock: Fix vCPUs > 64 can't be online/hotpluged
On Wed, 27 Jan 2021 at 01:26, Paolo Bonzini wrote: > > On 26/01/21 02:28, Wanpeng Li wrote: > > ping， > > On Mon, 18 Jan 2021 at 17:08, Wanpeng Li wrote: > >> > >> From: Wanpeng Li > >> > >> The per-cpu vsyscall pvclock data pointer assigns either an element of the > >> static array hv_clock_boot (#vCPU <= 64) or dynamically allocated memory > >> hvclock_mem (vCPU > 64), the dynamically memory will not be allocated if > >> kvmclock vsyscall is disabled, this can result in cpu hotpluged fails in > >> kvmclock_setup_percpu() which returns -ENOMEM. This patch fixes it by not > >> assigning vsyscall pvclock data pointer if kvmclock vdso_clock_mode is not > >> VDSO_CLOCKMODE_PVCLOCK. > > I am sorry, I still cannot figure out this patch. > > Is hotplug still broken if kvm vsyscall is enabled? Just when kvm vsyscall is disabled. :) # lscpu Architecture: x86_64 CPU op-mode(s):32-bit, 64-bit Byte Order: Little Endian CPU(s): 88 On-line CPU(s) list: 0-63 Off-line CPU(s) list: 64-87 # cat /proc/cmdline BOOT_IMAGE=/vmlinuz-5.10.0-rc3-tlinux2-0050+ root=/dev/mapper/cl-root ro rd.lvm.lv=cl/root rhgb quiet console=ttyS0 LANG=en_US .UTF-8 no-kvmclock-vsyscall # echo 1 > /sys/devices/system/cpu/cpu76/online -bash: echo: write error: Cannot allocate memory Wanpeng
Re: [PATCH v3 1/2] bio: limit bio max size
> On 2021/01/26 18:37, Changheun Lee wrote:
> > bio size can grow up to 4GB when muli-page bvec is enabled.
> > but sometimes it would lead to inefficient behaviors.
> > in case of large chunk direct I/O, - 32MB chunk read in user space -
> > all pages for 32MB would be merged to a bio structure if the pages
> > physical addresses are contiguous. it makes some delay to submit
> > until merge complete. bio max size should be limited to a proper size.
> >
> > When 32MB chunk read with direct I/O option is coming from userspace,
> > kernel behavior is below now. it's timeline.
> >
> > | bio merge for 32MB. total 8,192 pages are merged.
> > | total elapsed time is over 2ms.
> > |-- ... --->|
> > | 8,192 pages merged a bio.
> > | at this time, first bio
> > submit is done.
> > | 1 bio is split to 32
> > read request and issue.
> > |--->
> > |--->
> >|--->
> > ..
> >
> > |--->
> >
> > |--->|
> > total 19ms elapsed to complete 32MB read done
> > from device. |
> >
> > If bio max size is limited with 1MB, behavior is changed below.
> >
> > | bio merge for 1MB. 256 pages are merged for each bio.
> > | total 32 bio will be made.
> > | total elapsed time is over 2ms. it's same.
> > | but, first bio submit timing is fast. about 100us.
> > |--->|--->|--->|---> ... -->|--->|--->|--->|--->|
> > | 256 pages merged a bio.
> > | at this time, first bio submit is done.
> > | and 1 read request is issued for 1 bio.
> > |--->
> >|--->
> > |--->
> > ..
> > |--->
> > |--->|
> > total 17ms elapsed to complete 32MB read done from device. |
> >
> > As a result, read request issue timing is faster if bio max size is limited.
> > Current kernel behavior with multipage bvec, super large bio can be created.
> > And it lead to delay first I/O request issue.
> >
> > Signed-off-by: Changheun Lee
> > ---
> > block/bio.c| 17 -
> > include/linux/bio.h| 4 +++-
> > include/linux/blkdev.h | 3 +++
> > 3 files changed, 22 insertions(+), 2 deletions(-)
> >
> > diff --git a/block/bio.c b/block/bio.c
> > index 1f2cc1fbe283..ec0281889045 100644
> > --- a/block/bio.c
> > +++ b/block/bio.c
> > @@ -287,6 +287,21 @@ void bio_init(struct bio *bio, struct bio_vec *table,
> > }
> > EXPORT_SYMBOL(bio_init);
> >
> > +unsigned int bio_max_size(struct bio *bio)
> > +{
> > + struct request_queue *q;
> > +
> > + if (!bio->bi_disk)
> > + return UINT_MAX;
> > +
> > + q = bio->bi_disk->queue;
> > + if (!blk_queue_limit_bio_size(q))
> > + return UINT_MAX;
> > +
> > + return blk_queue_get_max_sectors(q, bio_op(bio)) << SECTOR_SHIFT;
> > +}
> > +EXPORT_SYMBOL(bio_max_size);
>
> Why export this ? This is only used in this file and in bio.h in bio_full().
OK. I'll remove it.
>
> > +
> > /**
> > * bio_reset - reinitialize a bio
> > * @bio: bio to reset
> > @@ -877,7 +892,7 @@ bool __bio_try_merge_page(struct bio *bio, struct page
> > *page,
> > struct bio_vec *bv = >bi_io_vec[bio->bi_vcnt - 1];
> >
> > if (page_is_mergeable(bv, page, len, off, same_page)) {
> > - if (bio->bi_iter.bi_size > UINT_MAX - len) {
> > + if (bio->bi_iter.bi_size > bio_max_size(bio) - len) {
> > *same_page = false;
> > return false;
> > }
> > diff --git a/include/linux/bio.h b/include/linux/bio.h
> > index 1edda614f7ce..cdb134ca7bf5 100644
> > --- a/include/linux/bio.h
> > +++ b/include/linux/bio.h
> > @@ -100,6 +100,8 @@ static inline void *bio_data(struct bio *bio)
> > return NULL;
> > }
> >
> > +extern unsigned int bio_max_size(struct bio *);
>
> No need for extern.
It's just for compile warning in my test environment.
I'll remove it too. But I think compile warning could be in the other
.c file which includes bio.h. Is it OK?
>
> > +
> > /**
> > * bio_full - check if the bio is full
> > * @bio: bio to check
> > @@ -113,7 +115,7 @@ static inline bool bio_full(struct bio *bio, unsigned
> > len)
> > if (bio->bi_vcnt >= bio->bi_max_vecs)
> > return true;
> >
[GIT PULL] KVM fixes for Linux 5.11-rc5
Linus,
The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837:
Linux 5.11-rc3 (2021-01-10 14:34:50 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
for you to fetch changes up to 9a78e15802a87de2b08dfd1bd88e855201d2c8fa:
KVM: x86: allow KVM_REQ_GET_NESTED_STATE_PAGES outside guest mode for VMX
(2021-01-25 18:54:09 -0500)
* x86 bugfixes
* Documentation fixes
* Avoid performance regression due to SEV-ES patches
ARM:
- Don't allow tagged pointers to point to memslots
- Filter out ARMv8.1+ PMU events on v8.0 hardware
- Hide PMU registers from userspace when no PMU is configured
- More PMU cleanups
- Don't try to handle broken PSCI firmware
- More sys_reg() to reg_to_encoding() conversions
Alexandru Elisei (1):
KVM: arm64: Use the reg_to_encoding() macro instead of sys_reg()
David Brazdil (1):
KVM: arm64: Allow PSCI SYSTEM_OFF/RESET to return
Jay Zhou (1):
KVM: x86: get smi pending status correctly
Like Xu (2):
KVM: x86/pmu: Fix UBSAN shift-out-of-bounds warning in intel_pmu_refresh()
KVM: x86/pmu: Fix HW_REF_CPU_CYCLES event pseudo-encoding in
intel_arch_events[]
Lorenzo Brescia (1):
kvm: tracing: Fix unmatched kvm_entry and kvm_exit events
Marc Zyngier (4):
KVM: arm64: Hide PMU registers from userspace when not available
KVM: arm64: Simplify handling of absent PMU system registers
KVM: arm64: Filter out v8.1+ events on v8.0 HW
KVM: Forbid the use of tagged userspace addresses for memslots
Maxim Levitsky (1):
KVM: nVMX: Sync unsync'd vmcs02 state to vmcs12 on migration
Paolo Bonzini (2):
Merge tag 'kvmarm-fixes-5.11-2' of git://git.kernel.org/.../kvmarm/kvmarm
into HEAD
KVM: x86: allow KVM_REQ_GET_NESTED_STATE_PAGES outside guest mode for VMX
Quentin Perret (1):
KVM: Documentation: Fix spec for KVM_CAP_ENABLE_CAP_VM
Sean Christopherson (3):
KVM: x86: Add more protection against undefined behavior in rsvd_bits()
KVM: SVM: Unconditionally sync GPRs to GHCB on VMRUN of SEV-ES guest
KVM: x86: Revert "KVM: x86: Mark GPRs dirty when written"
Steven Price (1):
KVM: arm64: Compute TPIDR_EL2 ignoring MTE tag
Zenghui Yu (1):
KVM: Documentation: Update description of KVM_{GET,CLEAR}_DIRTY_LOG
Documentation/virt/kvm/api.rst | 21
arch/arm64/kvm/arm.c | 3 +-
arch/arm64/kvm/hyp/nvhe/psci-relay.c | 13 ++---
arch/arm64/kvm/pmu-emul.c| 10 ++--
arch/arm64/kvm/sys_regs.c| 93 ++--
arch/x86/kvm/kvm_cache_regs.h| 51 ++--
arch/x86/kvm/mmu.h | 9 +++-
arch/x86/kvm/svm/nested.c| 3 ++
arch/x86/kvm/svm/sev.c | 15 +++---
arch/x86/kvm/svm/svm.c | 2 +
arch/x86/kvm/vmx/nested.c| 44 -
arch/x86/kvm/vmx/pmu_intel.c | 6 ++-
arch/x86/kvm/vmx/vmx.c | 2 +
arch/x86/kvm/x86.c | 11 +++--
virt/kvm/kvm_main.c | 1 +
15 files changed, 172 insertions(+), 112 deletions(-)
Re: [PATCH] venus: core: Parse firmware-name DT property
On Tue 26 Jan 02:42 CST 2021, Stanimir Varbanov wrote:
> On production devices the firmware could be located on different
> places, this path could be provided by special firmware-name DT
> property.
>
> Here we check for existence of such DT property and if it exist
> take the firmware path from there. Otherwise, if the property
> is missing we fallback to the predefined path from driver resource
> structure.
>
Reviewed-by: Bjorn Andersson
But firmware-name is not mentioned in the dt binding.
Regards,
Bjorn
> Signed-off-by: Stanimir Varbanov
> ---
> drivers/media/platform/qcom/venus/firmware.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/qcom/venus/firmware.c
> b/drivers/media/platform/qcom/venus/firmware.c
> index d03e2dd5808c..56c8fb5a019b 100644
> --- a/drivers/media/platform/qcom/venus/firmware.c
> +++ b/drivers/media/platform/qcom/venus/firmware.c
> @@ -187,6 +187,7 @@ int venus_boot(struct venus_core *core)
> {
> struct device *dev = core->dev;
> const struct venus_resources *res = core->res;
> + const char *fwpath = NULL;
> phys_addr_t mem_phys;
> size_t mem_size;
> int ret;
> @@ -195,7 +196,12 @@ int venus_boot(struct venus_core *core)
> (core->use_tz && !qcom_scm_is_available()))
> return -EPROBE_DEFER;
>
> - ret = venus_load_fw(core, core->res->fwname, _phys, _size);
> + ret = of_property_read_string_index(dev->of_node, "firmware-name", 0,
> + );
> + if (ret)
> + fwpath = core->res->fwname;
> +
> + ret = venus_load_fw(core, fwpath, _phys, _size);
> if (ret) {
> dev_err(dev, "fail to load video firmware\n");
> return -EINVAL;
> --
> 2.25.1
>
Re: [PATCH v7 07/11] staging: vchiq: Release firmware handle on unbind
On Mon, Jan 18, 2021 at 01:32:40PM +0100, Nicolas Saenz Julienne wrote: > Use devm_rpi_firmware_get() so as to make sure we release RPi's firmware > interface when unbinding the device. > > Signed-off-by: Nicolas Saenz Julienne > Reviewed-by: Florian Fainelli > --- > drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Greg Kroah-Hartman
Re: [PATCH] iommu/vt-d: do not use flush-queue when caching-mode is on
On 1/27/21 8:26 AM, Lu Baolu wrote:
+{
+ struct dmar_domain *dmar_domain = to_dmar_domain(domain);
+ struct intel_iommu *iommu = domain_get_iommu(dmar_domain);
+
+ if (intel_iommu_strict)
+ return 0;
+
+ /*
+ * The flush queue implementation does not perform page-selective
+ * invalidations that are required for efficient TLB flushes in
virtual
+ * environments. The benefit of batching is likely to be much
lower than
+ * the overhead of synchronizing the virtual and physical IOMMU
+ * page-tables.
+ */
+ if (iommu && cap_caching_mode(iommu->cap)) {
+ pr_warn_once("IOMMU batching is partially disabled due to
virtualization");
+ return 0;
+ }
domain_get_iommu() only returns the first iommu, and could return NULL
when this is called before domain attaching to any device. A better
choice could be check caching mode globally and return false if caching
mode is supported on any iommu.
struct dmar_drhd_unit *drhd;
struct intel_iommu *iommu;
rcu_read_lock();
for_each_active_iommu(iommu, drhd) {
if (cap_caching_mode(iommu->cap))
return false;
We should unlock rcu before return here. Sorry!
}
rcu_read_unlock();
Best regards,
baolu
Re: [PATCH 1/8] lib: test_bitmap: clearly separate ERANGE from EINVAL tests.
[Re: [PATCH 1/8] lib: test_bitmap: clearly separate ERANGE from EINVAL tests.]
On 26/01/2021 (Tue 23:04) Andy Shevchenko wrote:
> On Tue, Jan 26, 2021 at 12:11:34PM -0500, Paul Gortmaker wrote:
> > This block of tests was meant to find/flag incorrect use of the ":"
> > and "/" separators (syntax errors) and invalid (zero) group len.
> >
> > However they were specified with an 8 bit width and 32 bit operations,
> > so they really contained two errors (EINVAL and ERANGE).
> >
> > Promote them to 32 bit so it is clear what they are meant to target,
> > and then add tests specific for ERANGE (no syntax errors, just doing
> > 32bit op on 8 bit width, plus a typical 9-on-8 fencepost error).
> >
> > Note that the remaining "10-1" on 8 is left as-is, since that captures
> > the fact that we check for (r->start > r->end) ---> EINVAL before we
> > check for (r->end >= nbits) ---> ERANGE. If the code is ever re-ordered
> > then this test will pick up the mismatched errno value.
>
> I didn't get the last statement. You meant code in the bitmap library itself,
> and not in the test cases? Please, clarify this somehow.
It probably wasn't worth a mention at all, as that test in question was
left unchanged; but yes - it was a reference to the ordering of the
sanity checks in the bitmap code itself and not the test order. I'll
simply delete the confusing "10-1" paragraph/comment.
> I don't really much care, since it's not a tricky commit, but it might be
> split
> to two or three separated ones. Anyway, feel free to add
> Reviewed-by: Andy Shevchenko
Since you mentioned it, I assume you would prefer it. So I will make
the 8 --> 32 change in one commit, and add the two new ERANGE tests in
another subsequent commit.
Thanks,
Paul.
--
>
> > Cc: Yury Norov
> > Cc: Rasmus Villemoes
> > Cc: Andy Shevchenko
> > Signed-off-by: Paul Gortmaker
> > ---
> > lib/test_bitmap.c | 16 +---
> > 1 file changed, 9 insertions(+), 7 deletions(-)
> >
> > diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
> > index 4425a1dd4ef1..3d2cd3b1de84 100644
> > --- a/lib/test_bitmap.c
> > +++ b/lib/test_bitmap.c
> > @@ -337,13 +337,15 @@ static const struct test_bitmap_parselist
> > parselist_tests[] __initconst = {
> >
> > {-EINVAL, "-1", NULL, 8, 0},
> > {-EINVAL, "-0", NULL, 8, 0},
> > - {-EINVAL, "10-1", NULL, 8, 0},
> > - {-EINVAL, "0-31:", NULL, 8, 0},
> > - {-EINVAL, "0-31:0", NULL, 8, 0},
> > - {-EINVAL, "0-31:0/", NULL, 8, 0},
> > - {-EINVAL, "0-31:0/0", NULL, 8, 0},
> > - {-EINVAL, "0-31:1/0", NULL, 8, 0},
> > - {-EINVAL, "0-31:10/1", NULL, 8, 0},
> > + {-EINVAL, "10-1", NULL, 8, 0}, /* (start > end) ; also ERANGE */
> > + {-ERANGE, "8-8", NULL, 8, 0},
> > + {-ERANGE, "0-31", NULL, 8, 0},
> > + {-EINVAL, "0-31:", NULL, 32, 0},
> > + {-EINVAL, "0-31:0", NULL, 32, 0},
> > + {-EINVAL, "0-31:0/", NULL, 32, 0},
> > + {-EINVAL, "0-31:0/0", NULL, 32, 0},
> > + {-EINVAL, "0-31:1/0", NULL, 32, 0},
> > + {-EINVAL, "0-31:10/1", NULL, 32, 0},
> > {-EOVERFLOW, "0-98765432123456789:10/1", NULL, 8, 0},
> >
> > {-EINVAL, "a-31", NULL, 8, 0},
> > --
> > 2.17.1
> >
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
Re: [PATCH] iommu/vt-d: do not use flush-queue when caching-mode is on
Hi Nadav,
On 1/27/21 4:38 AM, Nadav Amit wrote:
From: Nadav Amit
When an Intel IOMMU is virtualized, and a physical device is
passed-through to the VM, changes of the virtual IOMMU need to be
propagated to the physical IOMMU. The hypervisor therefore needs to
monitor PTE mappings in the IOMMU page-tables. Intel specifications
provide "caching-mode" capability that a virtual IOMMU uses to report
that the IOMMU is virtualized and a TLB flush is needed after mapping to
allow the hypervisor to propagate virtual IOMMU mappings to the physical
IOMMU. To the best of my knowledge no real physical IOMMU reports
"caching-mode" as turned on.
Synchronizing the virtual and the physical TLBs is expensive if the
hypervisor is unaware which PTEs have changed, as the hypervisor is
required to walk all the virtualized tables and look for changes.
Consequently, domain flushes are much more expensive than page-specific
flushes on virtualized IOMMUs with passthrough devices. The kernel
therefore exploited the "caching-mode" indication to avoid domain
flushing and use page-specific flushing in virtualized environments. See
commit 78d5f0f500e6 ("intel-iommu: Avoid global flushes with caching
mode.")
This behavior changed after commit 13cf01744608 ("iommu/vt-d: Make use
of iova deferred flushing"). Now, when batched TLB flushing is used (the
default), full TLB domain flushes are performed frequently, requiring
the hypervisor to perform expensive synchronization between the virtual
TLB and the physical one.
Good catch. Thank you!
Getting batched TLB flushes to use in such circumstances page-specific
invalidations again is not easy, since the TLB invalidation scheme
assumes that "full" domain TLB flushes are performed for scalability.
Disable batched TLB flushes when caching-mode is on, as the performance
benefit from using batched TLB invalidations is likely to be much
smaller than the overhead of the virtual-to-physical IOMMU page-tables
synchronization.
Fixes: 78d5f0f500e6 ("intel-iommu: Avoid global flushes with caching mode.")
Signed-off-by: Nadav Amit
Cc: David Woodhouse
Cc: Lu Baolu
Cc: Joerg Roedel
Cc: Will Deacon
Cc: sta...@vger.kernel.org
---
drivers/iommu/intel/iommu.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 788119c5b021..4e08f5e17175 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -5373,6 +5373,30 @@ intel_iommu_domain_set_attr(struct iommu_domain *domain,
return ret;
}
+static int
+intel_iommu_domain_get_attr_use_flush_queue(struct iommu_domain *domain)
Just nit:
Can we just use this
static bool domain_use_flush_queue(struct iommu_domain *domain)
?
+{
+ struct dmar_domain *dmar_domain = to_dmar_domain(domain);
+ struct intel_iommu *iommu = domain_get_iommu(dmar_domain);
+
+ if (intel_iommu_strict)
+ return 0;
+
+ /*
+* The flush queue implementation does not perform page-selective
+* invalidations that are required for efficient TLB flushes in virtual
+* environments. The benefit of batching is likely to be much lower than
+* the overhead of synchronizing the virtual and physical IOMMU
+* page-tables.
+*/
+ if (iommu && cap_caching_mode(iommu->cap)) {
+ pr_warn_once("IOMMU batching is partially disabled due to
virtualization");
+ return 0;
+ }
domain_get_iommu() only returns the first iommu, and could return NULL
when this is called before domain attaching to any device. A better
choice could be check caching mode globally and return false if caching
mode is supported on any iommu.
struct dmar_drhd_unit *drhd;
struct intel_iommu *iommu;
rcu_read_lock();
for_each_active_iommu(iommu, drhd) {
if (cap_caching_mode(iommu->cap))
return false;
}
rcu_read_unlock();
+
+ return 1;
+}
+
static int
intel_iommu_domain_get_attr(struct iommu_domain *domain,
enum iommu_attr attr, void *data)
@@ -5383,7 +5407,7 @@ intel_iommu_domain_get_attr(struct iommu_domain *domain,
case IOMMU_DOMAIN_DMA:
switch (attr) {
case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
- *(int *)data = !intel_iommu_strict;
+ *(int *)data =
!intel_iommu_domain_get_attr_use_flush_queue(domain);
return 0;
default:
return -ENODEV;
Best regards,
baolu
Re: [PATCH v3 5/6] media: uvcvideo: Use dma_alloc_noncontiguos API
Hi Christoph Thanks for the series! I have a couple of questions: - Is there any platform where dma_alloc_noncontiguos can fail? This is, !ops->alloc_noncontiguous and !dev->coherent_dma_mask If yes then we need to add a function to let the driver know in advance that it has to use the coherent allocator (usb_alloc_coherent for uvc) - In dma_alloc_noncontiguos, on the dma_alloc_pages fallback. If we have a device where the dma happens in only one direction, could not get more performance with DMA_FROM/TO_DEVICE instead of DMA_BIDIRECTIONAL ? Then I have tried to use the API, and I have encountered a problem: on uvcvideo the device passed to the memory allocator is different for DMA_PAGES and NON_CONTIGUOUS: https://github.com/ribalda/linux/blob/042cd497739f71c8d4a83a67ee970369e2baca4a/drivers/media/usb/uvc/uvc_video.c#L1236 I need to dig a bit tomorrow to figure out why this is, I have hardware to test both paths, so it should not be too difficult. Thanks again On Tue, Jan 26, 2021 at 6:07 PM . Christoph Hellwig wrote: > > Please take a quick look at this branch: > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma_alloc_noncontiguous > > Warning: hot off the press, and only with the v4l conversion as that > seemed at little easier than uvcvideo. -- Ricardo Ribalda
Re: [PATCH] MAINTAINERS/.mailmap: Use my @kernel.org address
On Tue, Jan 26, 2021 at 10:27 PM Nathan Chancellor wrote: > > Use my @kernel.org for all points of contact so that I am always > accessible. > > Signed-off-by: Nathan Chancellor Acked-by: Miguel Ojeda Cheers, Miguel
Re: [PATCH v3 2/4] arm64: dts: correct vendor prefix hisi to hisilicon
Hi Arnd,
On 2021/1/27 6:23, Arnd Bergmann wrote:
> On Tue, Dec 8, 2020 at 1:46 PM Zhen Lei wrote:
>>
>> The vendor prefix of "Hisilicon Limited" is "hisilicon", it is clearly
>> stated in "vendor-prefixes.yaml".
>>
>> Fixes: 35ca8168133c ("arm64: dts: Add dts files for Hisilicon Hi3660 SoC")
>> Fixes: dd8c7b78c11b ("arm64: dts: Add devicetree for Hisilicon Hi3670 SoC")
>> Signed-off-by: Zhen Lei
>> Cc: Chen Feng
>> Cc: Manivannan Sadhasivam
>
> I see this change in the pull request I got, but I'm a bit worried about the
> incompatible binding change. Wouldn't the correct path forward be to
> list both the correct and the incorrect properties, both in the dts file
> and in the driver that interprets the properties?
Thanks for the comment!
The reset driver will look for "hisilicon" firstly and fall back to "hisi".
And the DTS is shipped with the driver together.
So I think there is no compatible issue here.
Please let me know if missed anything. Thanks!
Best Regards,
Wei
>
> The binding file in this case would need to list the old name as deprecated,
> though I'm not sure how that would work without causing a warning about
> the unknown vendor prefix.
>
> Arnd
> .
>
[PATCH v5 5/5] clk: qcom: gcc: Add clock driver for SM8350
From: Vivek Aknurwar
This adds Global Clock controller (GCC) driver for SM8350 SoC
Signed-off-by: Vivek Aknurwar
Signed-off-by: Jeevan Shriram
[vkoul: rebase and tidy up for upstream]
Signed-off-by: Vinod Koul
Reviewed-by: Bjorn Andersson
---
drivers/clk/qcom/Kconfig |8 +
drivers/clk/qcom/Makefile |1 +
drivers/clk/qcom/gcc-sm8350.c | 3790 +
3 files changed, 3799 insertions(+)
create mode 100644 drivers/clk/qcom/gcc-sm8350.c
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index d32bb12cd8d0..54b217956469 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -454,6 +454,14 @@ config SM_GCC_8250
Say Y if you want to use peripheral devices such as UART,
SPI, I2C, USB, SD/UFS, PCIe etc.
+config SM_GCC_8350
+ tristate "SM8350 Global Clock Controller"
+ select QCOM_GDSC
+ help
+ Support for the global clock controller on SM8350 devices.
+ Say Y if you want to use peripheral devices such as UART,
+ SPI, I2C, USB, SD/UFS, PCIe etc.
+
config SM_GPUCC_8150
tristate "SM8150 Graphics Clock Controller"
select SM_GCC_8150
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 9e5e0e3cb7b4..a89c7016 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_SDX_GCC_55) += gcc-sdx55.o
obj-$(CONFIG_SM_DISPCC_8250) += dispcc-sm8250.o
obj-$(CONFIG_SM_GCC_8150) += gcc-sm8150.o
obj-$(CONFIG_SM_GCC_8250) += gcc-sm8250.o
+obj-$(CONFIG_SM_GCC_8350) += gcc-sm8350.o
obj-$(CONFIG_SM_GPUCC_8150) += gpucc-sm8150.o
obj-$(CONFIG_SM_GPUCC_8250) += gpucc-sm8250.o
obj-$(CONFIG_SM_VIDEOCC_8150) += videocc-sm8150.o
diff --git a/drivers/clk/qcom/gcc-sm8350.c b/drivers/clk/qcom/gcc-sm8350.c
new file mode 100644
index ..a16c08651206
--- /dev/null
+++ b/drivers/clk/qcom/gcc-sm8350.c
@@ -0,0 +1,3790 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2019-2020, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2020-2021, Linaro Limited
+ */
+
+#include
+#include
+#include
+
+#include
+
+#include "clk-alpha-pll.h"
+#include "clk-branch.h"
+#include "clk-rcg.h"
+#include "clk-regmap.h"
+#include "clk-regmap-divider.h"
+#include "clk-regmap-mux.h"
+#include "reset.h"
+
+enum {
+ P_BI_TCXO,
+ P_CORE_BI_PLL_TEST_SE,
+ P_GCC_GPLL0_OUT_EVEN,
+ P_GCC_GPLL0_OUT_MAIN,
+ P_GCC_GPLL4_OUT_MAIN,
+ P_GCC_GPLL9_OUT_MAIN,
+ P_PCIE_0_PIPE_CLK,
+ P_PCIE_1_PIPE_CLK,
+ P_SLEEP_CLK,
+ P_UFS_CARD_RX_SYMBOL_0_CLK,
+ P_UFS_CARD_RX_SYMBOL_1_CLK,
+ P_UFS_CARD_TX_SYMBOL_0_CLK,
+ P_UFS_PHY_RX_SYMBOL_0_CLK,
+ P_UFS_PHY_RX_SYMBOL_1_CLK,
+ P_UFS_PHY_TX_SYMBOL_0_CLK,
+ P_USB3_PHY_WRAPPER_GCC_USB30_PIPE_CLK,
+ P_USB3_UNI_PHY_SEC_GCC_USB30_PIPE_CLK,
+};
+
+static struct clk_alpha_pll gcc_gpll0 = {
+ .offset = 0x0,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID],
+ .clkr = {
+ .enable_reg = 0x52018,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "gcc_gpll0",
+ .parent_data = &(const struct clk_parent_data){
+ .fw_name = "bi_tcxo",
+ },
+ .num_parents = 1,
+ .ops = _alpha_pll_fixed_lucid_5lpe_ops,
+ },
+ },
+};
+
+static const struct clk_div_table post_div_table_gcc_gpll0_out_even[] = {
+ { 0x1, 2 },
+ { }
+};
+
+static struct clk_alpha_pll_postdiv gcc_gpll0_out_even = {
+ .offset = 0x0,
+ .post_div_shift = 8,
+ .post_div_table = post_div_table_gcc_gpll0_out_even,
+ .num_post_div = ARRAY_SIZE(post_div_table_gcc_gpll0_out_even),
+ .width = 4,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID],
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "gcc_gpll0_out_even",
+ .parent_data = &(const struct clk_parent_data){
+ .hw = _gpll0.clkr.hw,
+ },
+ .num_parents = 1,
+ .ops = _alpha_pll_postdiv_lucid_5lpe_ops,
+ },
+};
+
+static struct clk_alpha_pll gcc_gpll4 = {
+ .offset = 0x76000,
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID],
+ .clkr = {
+ .enable_reg = 0x52018,
+ .enable_mask = BIT(4),
+ .hw.init = &(struct clk_init_data){
+ .name = "gcc_gpll4",
+ .parent_data = &(const struct clk_parent_data){
+ .fw_name = "bi_tcxo",
+ .name = "bi_tcxo",
+ },
+ .num_parents = 1,
+ .ops = _alpha_pll_fixed_lucid_5lpe_ops,
+ },
+ },
+};
+
+static struct
Re: [PATCH 2/5] kernel/dma: remove unnecessary unmap_kernel_range
On Tue, Jan 26, 2021 at 05:08:46PM -0500, Konrad Rzeszutek Wilk wrote: > On Tue, Jan 26, 2021 at 02:54:01PM +1000, Nicholas Piggin wrote: > > vunmap will remove ptes. > > Should there be some ASSERT after the vunmap to make sure that is the > case? Not really. removing the PTEs is the whole point of vunmap. Everything else is just house keeping.
RE: [RFC PATCH v1 1/2] block: bsg: resume scsi device before accessing
> > Resumes the scsi device before accessing it. > > Change-Id: I2929af60f2a92c89704a582fcdb285d35b429fde > Signed-off-by: Asutosh Das > Signed-off-by: Can Guo > Signed-off-by: Bao D. Nguyen Following this patch, is it possible to revert commit 74e5e468b664d? Thanks, Avri
Re: [PATCH RFC] gcc-plugins: Handle GCC version mismatch for OOT modules
On Mon, Jan 25, 2021 at 04:19:53PM -0600, Josh Poimboeuf wrote: > On Mon, Jan 25, 2021 at 02:03:07PM -0800, Kees Cook wrote: > > On Mon, Jan 25, 2021 at 02:42:10PM -0600, Josh Poimboeuf wrote: > > > When a GCC version mismatch is detected, print a warning and disable the > > > plugin. The only exception is the RANDSTRUCT plugin which needs all > > > code to see the same struct layouts. In that case print an error. > > > > I prefer this patch as-is: only randstruct needs a hard failure. The > > others likely work (in fact, randstruct likely works too). > > I'm curious about this last statement, why would randstruct likely work? > > Even struct module has '__randomize_layout', wouldn't basic module init > go splat? No; the seed is part of the generate includes -- you'll get the same layout with the same seed. -- Kees Cook
Re: linux-next: build warning after merge of the pidfd tree
On Wed, Jan 27, 2021 at 09:41:01AM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the pidfd tree, today's linux-next build (powerpc > ppc64_defconfig) produced this warning: > > fs/xfs/xfs_ioctl32.c: In function 'xfs_file_compat_ioctl': > fs/xfs/xfs_ioctl32.c:441:20: warning: unused variable 'mp' [-Wunused-variable] > 441 | struct xfs_mount *mp = ip->i_mount; > |^~ So this is only used in an x86-specific section of the function. Let me think what we can do about this.
Re: [PATCH v4 0/2] add support for GPIO based counter
On 1/27/21 7:44 AM, Oleksij Rempel wrote: >>> changes v3: >>> - convert counter to atomic_t >> >> What's the guaranteed width of atomic_t? IIRC a long time ago it was 24 bit >> only > > 32 bits. The counter is wrapped after 4294967295 Note: This is only true for >= v2.6.3 :D https://lwn.net/Articles/71732/ Feeling old, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: OpenPGP digital signature
Re: [PATCH 07/22] perf daemon: Add daemon command
Hi Jiri,
On Sun, Jan 3, 2021 at 7:05 AM Jiri Olsa wrote:
> +int cmd_daemon(int argc, const char **argv)
> +{
> + struct option daemon_options[] = {
> + OPT_INCR('v', "verbose", , "be more verbose"),
> + OPT_STRING(0, "config", &__daemon.config,
> + "config file", "config file path"),
> + OPT_STRING_OPTARG('x', "field-separator", &__daemon.csv_sep,
> + "field separator", "print counts with custom
> separator", ":"),
Oh, I didn't expect it's optional and default to ":" instead of ",".
Thanks,
Namhyung
> + OPT_END()
> + };
Re: [PATCH] net: mdiobus: Prevent spike on MDIO bus reset signal
See below. Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Products B.V. Materiaalweg 4, 5681 RJ Best The Netherlands T: +31 (0) 499 33 69 69 E: mike.looijm...@topicproducts.com W: www.topicproducts.com Please consider the environment before printing this e-mail On 26-01-2021 14:49, Russell King - ARM Linux admin wrote: On Tue, Jan 26, 2021 at 02:14:40PM +0100, Andrew Lunn wrote: On Tue, Jan 26, 2021 at 08:33:37AM +0100, Mike Looijmans wrote: The mdio_bus reset code first de-asserted the reset by allocating with GPIOD_OUT_LOW, then asserted and de-asserted again. In other words, if the reset signal defaulted to asserted, there'd be a short "spike" before the reset. Instead, directly assert the reset signal using GPIOD_OUT_HIGH, this removes the spike and also removes a line of code since the signal is already high. Hi Mike This however appears to remove the reset pulse, if the reset line was already low to start with. Notice you left fsleep(bus->reset_delay_us); without any action before it? What are we now waiting for? Most data sheets talk of a reset pulse. Take the reset line high, wait for some time, take the reset low, wait for some time, and then start talking to the PHY. I think with this patch, we have lost the guarantee of a low to high transition. Is this spike, followed by a pulse actually causing you problems? If so, i would actually suggest adding another delay, to stretch the spike. We have no control over the initial state of the reset line, it is how the bootloader left it, we have to handle both states. Andrew, I don't get what you're saying. Here is what happens depending on the pre-existing state of the reset signal: Reset (previously asserted): ~~~|_||___ Reset (previously deasserted): _||___ ^ ^^ A BC At point A, the low going transition is because the reset line is requested using GPIOD_OUT_LOW. If the line is successfully requested, the first thing we do is set it high _without_ any delay. This is point B. So, a glitch occurs between A and B. We then fsleep() and finally set the GPIO low at point C. Requesting the line using GPIOD_OUT_HIGH eliminates the A and B transitions. Instead we get: Reset (previously asserted) : ~~|__ Reset (previously deasserted): |~|__ ^ ^ A C Where A and C are the points described above in the code. Point B has been eliminated. Therefore, to me the patch looks entirely reasonable and correct. Thanks, excellent explanation. As a bit of background, we were using a Marvell PHY where the datasheet states that thou shallt not release the reset within 50 ms of power-up. A pull-down on the active-low reset was thus added. Looking at the reset signal with a scope revealed a short spike, visible only because it was being controlled by an I2C GPIO expander. So it's indeed point "B" that we wanted to eliminate. -- Mike Looijmans
Re: [PATCH v2] tracepoint: Do not fail unregistering a probe due to memory allocation
On 18/11/2020 23:46, Steven Rostedt wrote:
On Tue, 17 Nov 2020 20:54:24 -0800
Alexei Starovoitov wrote:
extern int
@@ -310,7 +312,12 @@ static inline struct tracepoint
*tracepoint_ptr_deref(tracepoint_ptr_t *p)
do {\
it_func = (it_func_ptr)->func; \
__data = (it_func_ptr)->data; \
- ((void(*)(void *, proto))(it_func))(__data, args); \
+ /* \
+* Removed functions that couldn't be allocated \
+* are replaced with TRACEPOINT_STUB. \
+*/ \
+ if (likely(it_func != TRACEPOINT_STUB)) \
+ ((void(*)(void *, proto))(it_func))(__data,
args); \
I think you're overreacting to the problem.
I will disagree with that.
Adding run-time check to extremely unlikely problem seems wasteful.
Show me a real benchmark that you can notice a problem here. I bet that
check is even within the noise of calling an indirect function. Especially
on a machine with retpolines.
99.9% of the time allocate_probes() will do kmalloc from slab of small
objects.
If that slab is out of memory it means it cannot allocate a single page.
In such case so many things will be failing to alloc that system
is unlikely operational. oom should have triggered long ago.
Imo Matt's approach to add __GFP_NOFAIL to allocate_probes()
Looking at the GFP_NOFAIL comment:
* %__GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller
* cannot handle allocation failures. The allocation could block
* indefinitely but will never return with failure. Testing for
* failure is pointless.
* New users should be evaluated carefully (and the flag should be
* used only when there is no reasonable failure policy) but it is
* definitely preferable to use the flag rather than opencode endless
* loop around allocator.
I realized I made a mistake in my patch for using it, as my patch is a
failure policy. It looks like something we want to avoid in general.
Thanks, I'll send a v3 that removes it.
when it's called from func_remove() is much better.
The error was reported by syzbot that was using
memory fault injections. ENOMEM in allocate_probes() was
never seen in real life and highly unlikely will ever be seen.
And the biggest thing you are missing here, is that if you are running on a
machine that has static calls, this code is never hit unless you have more
than one callback on a single tracepoint. That's because when there's only
one callback, it gets called directly, and this loop is not involved.
I am running syzkaller and the kernel keeps crashing in
__traceiter_##_name. This patch makes these crashes happen lot less
often (and so did the v1) but the kernel still crashes (examples below
but the common thing is that they crash in tracepoints). Disasm points
to __DO_TRACE_CALL(name) and this fixes it:
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -313,6 +313,7 @@ static inline struct tracepoint
*tracepoint_ptr_deref(tracepoint_ptr_t *p)
\
it_func_ptr = \
rcu_dereference_raw((&__tracepoint_##_name)->funcs); \
+ if (it_func_ptr)\
do {\
it_func = (it_func_ptr)->func; \
I am running on a powerpc box which does not have CONFIG_HAVE_STATIC_CALL.
I wonder if it is still the same problem which mentioned v3 might fix or
it is something different? Thanks,
[ 285.072538] Kernel attempted to read user page (0) - exploit attempt?
(uid: 0)
[ 285.073657] BUG: Kernel NULL pointer dereference on read at 0x
[ 285.075129] Faulting instruction address: 0xc02edf48
cpu 0xd: Vector: 300 (Data Access) at [c000115db530]
pc: c02edf48: lock_acquire+0x2e8/0x5d0
lr: c06ee450: step_into+0x940/0xc20
sp: c000115db7d0
msr: 80009033
dar: 0
dsisr: 4000
current = 0xc000115af280
paca= 0xc0005ff9fe00 irqmask: 0x03 irq_happened: 0x01
pid = 182, comm = systemd-journal
Linux version 5.11.0-rc5-le_syzkaller_a+fstn1 (aik@fstn1-p1) (gcc
(Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0, GNU ld (GNU Binutils for Ubuntu)
2.30) #65 SMP Wed Jan 27 16:46:46 AEDT 2021
enter ? for help
[c000115db8c0] c06ee450 step_into+0x940/0xc20
[c000115db950] c06efddc walk_component+0xbc/0x340
[c000115db9d0] c06f0418 link_path_walk.part.29+0x3b8/0x5b0
[PATCH v5 4/5] dt-bindings: clock: Add SM8350 GCC clock bindings
Add device tree bindings for global clock controller on SM8350 SoCs.
Reviewed-by: Rob Herring
Reviewed-by: Bjorn Andersson
Signed-off-by: Vinod Koul
---
.../bindings/clock/qcom,gcc-sm8350.yaml | 96 +++
include/dt-bindings/clock/qcom,gcc-sm8350.h | 254 ++
2 files changed, 350 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml
create mode 100644 include/dt-bindings/clock/qcom,gcc-sm8350.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml
b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml
new file mode 100644
index ..78f35832aa41
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/qcom,gcc-sm8350.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Global Clock & Reset Controller Binding for SM8350
+
+maintainers:
+ - Vinod Koul
+
+description: |
+ Qualcomm global clock control module which supports the clocks, resets and
+ power domains on SM8350.
+
+ See also:
+ - dt-bindings/clock/qcom,gcc-sm8350.h
+
+properties:
+ compatible:
+const: qcom,gcc-sm8350
+
+ clocks:
+items:
+ - description: Board XO source
+ - description: Sleep clock source
+ - description: PLL test clock source (Optional clock)
+ - description: PCIE 0 Pipe clock source (Optional clock)
+ - description: PCIE 1 Pipe clock source (Optional clock)
+ - description: UFS card Rx symbol 0 clock source (Optional clock)
+ - description: UFS card Rx symbol 1 clock source (Optional clock)
+ - description: UFS card Tx symbol 0 clock source (Optional clock)
+ - description: UFS phy Rx symbol 0 clock source (Optional clock)
+ - description: UFS phy Rx symbol 1 clock source (Optional clock)
+ - description: UFS phy Tx symbol 0 clock source (Optional clock)
+ - description: USB3 phy wrapper pipe clock source (Optional clock)
+ - description: USB3 phy sec pipe clock source (Optional clock)
+minItems: 2
+maxItems: 13
+
+ clock-names:
+items:
+ - const: bi_tcxo
+ - const: sleep_clk
+ - const: core_bi_pll_test_se # Optional clock
+ - const: pcie_0_pipe_clk # Optional clock
+ - const: pcie_1_pipe_clk # Optional clock
+ - const: ufs_card_rx_symbol_0_clk # Optional clock
+ - const: ufs_card_rx_symbol_1_clk # Optional clock
+ - const: ufs_card_tx_symbol_0_clk # Optional clock
+ - const: ufs_phy_rx_symbol_0_clk # Optional clock
+ - const: ufs_phy_rx_symbol_1_clk # Optional clock
+ - const: ufs_phy_tx_symbol_0_clk # Optional clock
+ - const: usb3_phy_wrapper_gcc_usb30_pipe_clk # Optional clock
+ - const: usb3_uni_phy_sec_gcc_usb30_pipe_clk # Optional clock
+minItems: 2
+maxItems: 13
+
+ '#clock-cells':
+const: 1
+
+ '#reset-cells':
+const: 1
+
+ '#power-domain-cells':
+const: 1
+
+ reg:
+maxItems: 1
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - reg
+ - '#clock-cells'
+ - '#reset-cells'
+ - '#power-domain-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+clock-controller@10 {
+ compatible = "qcom,gcc-sm8350";
+ reg = <0x0010 0x1f>;
+ clocks = < RPMH_CXO_CLK>,
+ <_clk>;
+ clock-names = "bi_tcxo", "sleep_clk";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+};
+
+...
diff --git a/include/dt-bindings/clock/qcom,gcc-sm8350.h
b/include/dt-bindings/clock/qcom,gcc-sm8350.h
new file mode 100644
index ..1331da65f669
--- /dev/null
+++ b/include/dt-bindings/clock/qcom,gcc-sm8350.h
@@ -0,0 +1,254 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (c) 2019-2020, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2020-2021, Linaro Limited
+ */
+
+#ifndef _DT_BINDINGS_CLK_QCOM_GCC_SM8350_H
+#define _DT_BINDINGS_CLK_QCOM_GCC_SM8350_H
+
+/* GCC HW clocks */
+#define CORE_BI_PLL_TEST_SE0
+#define PCIE_0_PIPE_CLK1
+#define PCIE_1_PIPE_CLK2
+#define UFS_CARD_RX_SYMBOL_0_CLK 3
+#define UFS_CARD_RX_SYMBOL_1_CLK 4
+#define UFS_CARD_TX_SYMBOL_0_CLK 5
+#define UFS_PHY_RX_SYMBOL_0_CLK6
+#define UFS_PHY_RX_SYMBOL_1_CLK7
+#define UFS_PHY_TX_SYMBOL_0_CLK8
+#define USB3_PHY_WRAPPER_GCC_USB30_PIPE_CLK9
+#define USB3_UNI_PHY_SEC_GCC_USB30_PIPE_CLK10
+
+/* GCC clocks */
+#define GCC_AGGRE_NOC_PCIE_0_AXI_CLK 11
[PATCH v5 3/5] clk: qcom: clk-alpha-pll: Add support for Lucid 5LPE PLL
From: Vivek Aknurwar
Lucid 5LPE is a slightly different Lucid PLL with different offsets and
porgramming sequence so add support for these
Signed-off-by: Vivek Aknurwar
Signed-off-by: Jeevan Shriram
[vkoul: rebase and tidy up for upstream]
Signed-off-by: Vinod Koul
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Bjorn Andersson
---
drivers/clk/qcom/clk-alpha-pll.c | 173 +++
drivers/clk/qcom/clk-alpha-pll.h | 4 +
2 files changed, 177 insertions(+)
diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
index a30ea7b09224..c6eb99169ddc 100644
--- a/drivers/clk/qcom/clk-alpha-pll.c
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -156,6 +156,12 @@ EXPORT_SYMBOL_GPL(clk_alpha_pll_regs);
/* LUCID PLL specific settings and offsets */
#define LUCID_PCAL_DONEBIT(27)
+/* LUCID 5LPE PLL specific settings and offsets */
+#define LUCID_5LPE_PCAL_DONE BIT(11)
+#define LUCID_5LPE_ALPHA_PLL_ACK_LATCH BIT(13)
+#define LUCID_5LPE_PLL_LATCH_INPUT BIT(14)
+#define LUCID_5LPE_ENABLE_VOTE_RUN BIT(21)
+
#define pll_alpha_width(p) \
((PLL_ALPHA_VAL_U(p) - PLL_ALPHA_VAL(p) == 4) ? \
ALPHA_REG_BITWIDTH : ALPHA_REG_16BIT_WIDTH)
@@ -1604,3 +1610,170 @@ const struct clk_ops clk_alpha_pll_agera_ops = {
.set_rate = clk_alpha_pll_agera_set_rate,
};
EXPORT_SYMBOL_GPL(clk_alpha_pll_agera_ops);
+
+static int alpha_pll_lucid_5lpe_enable(struct clk_hw *hw)
+{
+ struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
+ u32 val;
+ int ret;
+
+ ret = regmap_read(pll->clkr.regmap, PLL_USER_CTL(pll), );
+ if (ret)
+ return ret;
+
+ /* If in FSM mode, just vote for it */
+ if (val & LUCID_5LPE_ENABLE_VOTE_RUN) {
+ ret = clk_enable_regmap(hw);
+ if (ret)
+ return ret;
+ return wait_for_pll_enable_lock(pll);
+ }
+
+ /* Check if PLL is already enabled, return if enabled */
+ ret = trion_pll_is_enabled(pll, pll->clkr.regmap);
+ if (ret < 0)
+ return ret;
+
+ ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll), PLL_RESET_N,
PLL_RESET_N);
+ if (ret)
+ return ret;
+
+ regmap_write(pll->clkr.regmap, PLL_OPMODE(pll), PLL_RUN);
+
+ ret = wait_for_pll_enable_lock(pll);
+ if (ret)
+ return ret;
+
+ /* Enable the PLL outputs */
+ ret = regmap_update_bits(pll->clkr.regmap, PLL_USER_CTL(pll),
PLL_OUT_MASK, PLL_OUT_MASK);
+ if (ret)
+ return ret;
+
+ /* Enable the global PLL outputs */
+ return regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll), PLL_OUTCTRL,
PLL_OUTCTRL);
+}
+
+static void alpha_pll_lucid_5lpe_disable(struct clk_hw *hw)
+{
+ struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
+ u32 val;
+ int ret;
+
+ ret = regmap_read(pll->clkr.regmap, PLL_USER_CTL(pll), );
+ if (ret)
+ return;
+
+ /* If in FSM mode, just unvote it */
+ if (val & LUCID_5LPE_ENABLE_VOTE_RUN) {
+ clk_disable_regmap(hw);
+ return;
+ }
+
+ /* Disable the global PLL output */
+ ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll), PLL_OUTCTRL,
0);
+ if (ret)
+ return;
+
+ /* Disable the PLL outputs */
+ ret = regmap_update_bits(pll->clkr.regmap, PLL_USER_CTL(pll),
PLL_OUT_MASK, 0);
+ if (ret)
+ return;
+
+ /* Place the PLL mode in STANDBY */
+ regmap_write(pll->clkr.regmap, PLL_OPMODE(pll), PLL_STANDBY);
+}
+
+/*
+ * The Lucid 5LPE PLL requires a power-on self-calibration which happens
+ * when the PLL comes out of reset. Calibrate in case it is not completed.
+ */
+static int alpha_pll_lucid_5lpe_prepare(struct clk_hw *hw)
+{
+ struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
+ struct clk_hw *p;
+ u32 val = 0;
+ int ret;
+
+ /* Return early if calibration is not needed. */
+ regmap_read(pll->clkr.regmap, PLL_MODE(pll), );
+ if (val & LUCID_5LPE_PCAL_DONE)
+ return 0;
+
+ p = clk_hw_get_parent(hw);
+ if (!p)
+ return -EINVAL;
+
+ ret = alpha_pll_lucid_5lpe_enable(hw);
+ if (ret)
+ return ret;
+
+ alpha_pll_lucid_5lpe_disable(hw);
+
+ return 0;
+}
+
+static int alpha_pll_lucid_5lpe_set_rate(struct clk_hw *hw, unsigned long rate,
+unsigned long prate)
+{
+ return __alpha_pll_trion_set_rate(hw, rate, prate,
+ LUCID_5LPE_PLL_LATCH_INPUT,
+ LUCID_5LPE_ALPHA_PLL_ACK_LATCH);
+}
+
+static int clk_lucid_5lpe_pll_postdiv_set_rate(struct clk_hw *hw, unsigned
long rate,
+ unsigned long
[PATCH v5 1/5] clk: qcom: clk-alpha-pll: replace regval with val
Driver uses regval variable for holding register values, replace with a
shorter one val
Suggested-by: Stephen Boyd
Reviewed-by: Bjorn Andersson
Signed-off-by: Vinod Koul
---
drivers/clk/qcom/clk-alpha-pll.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
index 21c357c26ec4..f7721088494c 100644
--- a/drivers/clk/qcom/clk-alpha-pll.c
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -777,15 +777,15 @@ static long alpha_pll_huayra_round_rate(struct clk_hw
*hw, unsigned long rate,
static int trion_pll_is_enabled(struct clk_alpha_pll *pll,
struct regmap *regmap)
{
- u32 mode_regval, opmode_regval;
+ u32 mode_val, opmode_val;
int ret;
- ret = regmap_read(regmap, PLL_MODE(pll), _regval);
- ret |= regmap_read(regmap, PLL_OPMODE(pll), _regval);
+ ret = regmap_read(regmap, PLL_MODE(pll), _val);
+ ret |= regmap_read(regmap, PLL_OPMODE(pll), _val);
if (ret)
return 0;
- return ((opmode_regval & PLL_RUN) && (mode_regval & PLL_OUTCTRL));
+ return ((opmode_val & PLL_RUN) && (mode_val & PLL_OUTCTRL));
}
static int clk_trion_pll_is_enabled(struct clk_hw *hw)
@@ -1445,12 +1445,12 @@ EXPORT_SYMBOL_GPL(clk_trion_pll_configure);
static int __alpha_pll_trion_prepare(struct clk_hw *hw, u32 pcal_done)
{
struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
- u32 regval;
+ u32 val;
int ret;
/* Return early if calibration is not needed. */
- regmap_read(pll->clkr.regmap, PLL_STATUS(pll), );
- if (regval & pcal_done)
+ regmap_read(pll->clkr.regmap, PLL_STATUS(pll), );
+ if (val & pcal_done)
return 0;
/* On/off to calibrate */
@@ -1476,7 +1476,7 @@ static int alpha_pll_trion_set_rate(struct clk_hw *hw,
unsigned long rate,
{
struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
unsigned long rrate;
- u32 regval, l, alpha_width = pll_alpha_width(pll);
+ u32 val, l, alpha_width = pll_alpha_width(pll);
u64 a;
int ret;
@@ -1497,8 +1497,8 @@ static int alpha_pll_trion_set_rate(struct clk_hw *hw,
unsigned long rate,
/* Wait for 2 reference cycles before checking the ACK bit. */
udelay(1);
- regmap_read(pll->clkr.regmap, PLL_MODE(pll), );
- if (!(regval & ALPHA_PLL_ACK_LATCH)) {
+ regmap_read(pll->clkr.regmap, PLL_MODE(pll), );
+ if (!(val & ALPHA_PLL_ACK_LATCH)) {
pr_err("Lucid PLL latch failed. Output may be unstable!\n");
return -EINVAL;
}
--
2.26.2
[PATCH v5 0/5] Add clock drivers for SM8350
This adds gcc clock controller drivers for the controller found
in SM8350 SoC
Changes in v5:
- Add r-b from AngeloGioacchino and Bjorn
- Removed unused clock indices
- Initialize variable before use in regmap read
Changes in v4:
- Add Ack from Rob on binding
- modularize alpha_pll_trion_set_rate()
Changes in v3:
- Drop rpmh clk patches applied
- Add a new patch to replace regval with val as suggested by Stephen
- Fix comments for new Lucid 5LPE PLL: sort new defines by BIT numbers, fix
comments, use alpha_pll_check_rate_margin(), rework
clk_lucid_5lpe_pll_postdiv_set_rate() logic
- Add power domains and optional clocks in bindings
- Fix comments for gcc sm8350 driver: clean includes used, use only
.fw_name for clocks defined in DT, use floor ops for sdcc clocks, remove
critical clocks and enable them in probe, add comments for clks using
BRANCH_HALT_SKIP and BRANCH_HALT_DELAY
Changes in v2:
- Add r-b from Bjorn
- Add the gcc_qupv3_wrap_1_{m|s}_ahb_clk and gcc_qupv3_wrap1_s5_clk
Vinod Koul (3):
clk: qcom: clk-alpha-pll: replace regval with val
clk: qcom: clk-alpha-pll: modularize alpha_pll_trion_set_rate()
dt-bindings: clock: Add SM8350 GCC clock bindings
Vivek Aknurwar (2):
clk: qcom: clk-alpha-pll: Add support for Lucid 5LPE PLL
clk: qcom: gcc: Add clock driver for SM8350
.../bindings/clock/qcom,gcc-sm8350.yaml | 96 +
drivers/clk/qcom/Kconfig |8 +
drivers/clk/qcom/Makefile |1 +
drivers/clk/qcom/clk-alpha-pll.c | 209 +-
drivers/clk/qcom/clk-alpha-pll.h |4 +
drivers/clk/qcom/gcc-sm8350.c | 3790 +
include/dt-bindings/clock/qcom,gcc-sm8350.h | 254 ++
7 files changed, 4346 insertions(+), 16 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml
create mode 100644 drivers/clk/qcom/gcc-sm8350.c
create mode 100644 include/dt-bindings/clock/qcom,gcc-sm8350.h
--
2.26.2
[PATCH v5 2/5] clk: qcom: clk-alpha-pll: modularize alpha_pll_trion_set_rate()
Trion 5LPE set rate uses code similar to alpha_pll_trion_set_rate() but
with different registers. Modularize these by moving out latch and latch
ack bits so that we can reuse the function.
Suggested-by: AngeloGioacchino Del Regno
Reviewed-by: Bjorn Andersson
Signed-off-by: Vinod Koul
---
drivers/clk/qcom/clk-alpha-pll.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c
index f7721088494c..a30ea7b09224 100644
--- a/drivers/clk/qcom/clk-alpha-pll.c
+++ b/drivers/clk/qcom/clk-alpha-pll.c
@@ -1471,8 +1471,8 @@ static int alpha_pll_lucid_prepare(struct clk_hw *hw)
return __alpha_pll_trion_prepare(hw, LUCID_PCAL_DONE);
}
-static int alpha_pll_trion_set_rate(struct clk_hw *hw, unsigned long rate,
- unsigned long prate)
+static int __alpha_pll_trion_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long prate, u32 latch_bit, u32
latch_ack)
{
struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
unsigned long rrate;
@@ -1490,22 +1490,20 @@ static int alpha_pll_trion_set_rate(struct clk_hw *hw,
unsigned long rate,
regmap_write(pll->clkr.regmap, PLL_ALPHA_VAL(pll), a);
/* Latch the PLL input */
- ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll),
-PLL_UPDATE, PLL_UPDATE);
+ ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll), latch_bit,
latch_bit);
if (ret)
return ret;
/* Wait for 2 reference cycles before checking the ACK bit. */
udelay(1);
regmap_read(pll->clkr.regmap, PLL_MODE(pll), );
- if (!(val & ALPHA_PLL_ACK_LATCH)) {
+ if (!(val & latch_ack)) {
pr_err("Lucid PLL latch failed. Output may be unstable!\n");
return -EINVAL;
}
/* Return the latch input to 0 */
- ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll),
-PLL_UPDATE, 0);
+ ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll), latch_bit, 0);
if (ret)
return ret;
@@ -1520,6 +1518,12 @@ static int alpha_pll_trion_set_rate(struct clk_hw *hw,
unsigned long rate,
return 0;
}
+static int alpha_pll_trion_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long prate)
+{
+ return __alpha_pll_trion_set_rate(hw, rate, prate, PLL_UPDATE,
ALPHA_PLL_ACK_LATCH);
+}
+
const struct clk_ops clk_alpha_pll_trion_ops = {
.prepare = alpha_pll_trion_prepare,
.enable = clk_trion_pll_enable,
--
2.26.2
Re: [PATCH] PCI: dwc: layerscape: convert to builtin_platform_driver()
On Tue, Jan 26, 2021 at 12:50 AM Geert Uytterhoeven wrote: > > Hi Saravana, > > On Mon, Jan 25, 2021 at 11:42 PM Saravana Kannan wrote: > > On Mon, Jan 25, 2021 at 11:49 AM Michael Walle wrote: > > > Am 2021-01-21 12:01, schrieb Geert Uytterhoeven: > > > > On Thu, Jan 21, 2021 at 1:05 AM Saravana Kannan > > > > wrote: > > > >> On Wed, Jan 20, 2021 at 3:53 PM Michael Walle > > > >> wrote: > > > >> > Am 2021-01-20 20:47, schrieb Saravana Kannan: > > > >> > > On Wed, Jan 20, 2021 at 11:28 AM Michael Walle > > > >> > > wrote: > > > >> > >> > > > >> > >> [RESEND, fat-fingered the buttons of my mail client and converted > > > >> > >> all CCs to BCCs :(] > > > >> > >> > > > >> > >> Am 2021-01-20 20:02, schrieb Saravana Kannan: > > > >> > >> > On Wed, Jan 20, 2021 at 6:24 AM Rob Herring > > > >> > >> > wrote: > > > >> > >> >> > > > >> > >> >> On Wed, Jan 20, 2021 at 4:53 AM Michael Walle > > > >> > >> >> > > > >> > >> >> wrote: > > > >> > >> >> > > > > >> > >> >> > fw_devlink will defer the probe until all suppliers are > > > >> > >> >> > ready. We can't > > > >> > >> >> > use builtin_platform_driver_probe() because it doesn't retry > > > >> > >> >> > after probe > > > >> > >> >> > deferral. Convert it to builtin_platform_driver(). > > > >> > >> >> > > > >> > >> >> If builtin_platform_driver_probe() doesn't work with > > > >> > >> >> fw_devlink, then > > > >> > >> >> shouldn't it be fixed or removed? > > > >> > >> > > > > >> > >> > I was actually thinking about this too. The problem with fixing > > > >> > >> > builtin_platform_driver_probe() to behave like > > > >> > >> > builtin_platform_driver() is that these probe functions could be > > > >> > >> > marked with __init. But there are also only 20 instances of > > > >> > >> > builtin_platform_driver_probe() in the kernel: > > > >> > >> > $ git grep ^builtin_platform_driver_probe | wc -l > > > >> > >> > 20 > > > >> > >> > > > > >> > >> > So it might be easier to just fix them to not use > > > >> > >> > builtin_platform_driver_probe(). > > > >> > >> > > > > >> > >> > Michael, > > > >> > >> > > > > >> > >> > Any chance you'd be willing to help me by converting all these > > > >> > >> > to > > > >> > >> > builtin_platform_driver() and delete > > > >> > >> > builtin_platform_driver_probe()? > > > >> > >> > > > >> > >> If it just moving the probe function to the _driver struct and > > > >> > >> remove the __init annotations. I could look into that. > > > >> > > > > > >> > > Yup. That's pretty much it AFAICT. > > > >> > > > > > >> > > builtin_platform_driver_probe() also makes sure the driver doesn't > > > >> > > ask > > > >> > > for async probe, etc. But I doubt anyone is actually setting async > > > >> > > flags and still using builtin_platform_driver_probe(). > > > >> > > > > >> > Hasn't module_platform_driver_probe() the same problem? And there > > > >> > are ~80 drivers which uses that. > > > >> > > > >> Yeah. The biggest problem with all of these is the __init markers. > > > >> Maybe some familiar with coccinelle can help? > > > > > > > > And dropping them will increase memory usage. > > > > > > Although I do have the changes for the builtin_platform_driver_probe() > > > ready, I don't think it makes much sense to send these unless we agree > > > on the increased memory footprint. While there are just a few > > > builtin_platform_driver_probe() and memory increase _might_ be > > > negligible, there are many more module_platform_driver_probe(). > > > > While it's good to drop code that'll not be used past kernel init, the > > module_platform_driver_probe() is going even more extreme. It doesn't > > even allow deferred probe (well before kernel init is done). I don't > > think that behavior is right and that's why we should delete it. Also, > > This construct is typically used for builtin hardware for which the > dependencies are registered very early, and thus known to probe at > first try (if present). > > > I doubt if any of these probe functions even take up 4KB of memory. > > How many 4 KiB pages do you have in a system with 10 MiB of SRAM? > How many can you afford to waste? There are only a few instances of this macro in the kernel. How many of those actually fit the description above? We can probably just check the DT? -Saravana
Re: Preemptible idr_alloc() in QRTR code
On Tue, Jan 26, 2021 at 06:36:02PM +, Mark Rutland wrote: > On Tue, Jan 26, 2021 at 11:00:05AM -0600, Bjorn Andersson wrote: > > On Tue 26 Jan 10:21 CST 2021, Mark Rutland wrote: > > > > > On Tue, Jan 26, 2021 at 02:58:33PM +, Matthew Wilcox wrote: > > > > On Tue, Jan 26, 2021 at 10:47:34AM +, Mark Rutland wrote: > > > > > Hi, > > > > > > > > > > When fuzzing arm64 with Syzkaller, I'm seeing some splats where > > > > > this_cpu_ptr() is used in the bowels of idr_alloc(), by way of > > > > > radix_tree_node_alloc(), in a preemptible context: > > > > > > > > I sent a patch to fix this last June. The maintainer seems to be > > > > under the impression that I care an awful lot more about their > > > > code than I do. > > > > > > > > https://lore.kernel.org/netdev/20200605120037.17427-1-wi...@infradead.org/ > > > > > > Ah; I hadn't spotted the (glaringly obvious) GFP_ATOMIC abuse, thanks > > > for the pointer, and sorry for the noise. > > > > > > > I'm afraid this isn't as obvious to me as it is to you. Are you saying > > that one must not use GFP_ATOMIC in non-atomic contexts? > > > > That said, glancing at the code I'm puzzled to why it would use > > GFP_ATOMIC. > > I'm also not entirely sure about the legitimacy of GFP_ATOMIC outside of > atomic contexts -- I couldn't spot any documentation saying that wasn't > legitimate, but Matthew's commit message implies so, and it sticks out > as odd. It's actually an assumption in the radix tree code. If you say you can't be preempted by saying GFP_ATOMIC, it takes you at your word and does some things which cannot be done in preemptable context.
Re: [GIT PULL 3/4] bcm2835-defconfig-arm64-next-2021-01-25
On 1/25/2021 1:01 PM, Nicolas Saenz Julienne wrote: > Hi Florian, > > The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: > > Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/nsaenz/linux-rpi.git > tags/bcm2835-defconfig-arm64-next-2021-01-25 > > for you to fetch changes up to b4192249b0c66e0ad177cdab87ea863220a7e455: > > arm64: defconfig: Enable nvmem's rmem driver (2021-01-25 21:55:18 +0100) > > > Enable NVMEM_RMEM as module to expose RPi4's bootloader configuration to > userspace > > Merged into defconfig-arm64/next, thanks Nicolas! -- Florian
Re: [PATCH tip/core/rcu 1/4] rcu: Expedite deboost in case of deferred quiescent state
On Tue, Jan 26, 2021 at 08:40:24PM -0800, Paul E. McKenney wrote:
> On Wed, Jan 27, 2021 at 10:42:35AM +0800, Boqun Feng wrote:
> > Hi Paul,
> >
> > On Tue, Jan 19, 2021 at 08:32:33PM -0800, paul...@kernel.org wrote:
> > > From: "Paul E. McKenney"
> > >
> > > Historically, a task that has been subjected to RCU priority boosting is
> > > deboosted at rcu_read_unlock() time. However, with the advent of deferred
> > > quiescent states, if the outermost rcu_read_unlock() was invoked with
> > > either bottom halves, interrupts, or preemption disabled, the deboosting
> > > will be delayed for some time. During this time, a low-priority process
> > > might be incorrectly running at a high real-time priority level.
> > >
> > > Fortunately, rcu_read_unlock_special() already provides mechanisms for
> > > forcing a minimal deferral of quiescent states, at least for kernels
> > > built with CONFIG_IRQ_WORK=y. These mechanisms are currently used
> > > when expedited grace periods are pending that might be blocked by the
> > > current task. This commit therefore causes those mechanisms to also be
> > > used in cases where the current task has been or might soon be subjected
> > > to RCU priority boosting. Note that this applies to all kernels built
> > > with CONFIG_RCU_BOOST=y, regardless of whether or not they are also
> > > built with CONFIG_PREEMPT_RT=y.
> > >
> > > This approach assumes that kernels build for use with aggressive real-time
> > > applications are built with CONFIG_IRQ_WORK=y. It is likely to be far
> > > simpler to enable CONFIG_IRQ_WORK=y than to implement a fast-deboosting
> > > scheme that works correctly in its absence.
> > >
> > > While in the area, alphabetize the rcu_preempt_deferred_qs_handler()
> > > function's local variables.
> > >
> > > Cc: Sebastian Andrzej Siewior
> > > Cc: Scott Wood
> > > Cc: Lai Jiangshan
> > > Cc: Thomas Gleixner
> > > Signed-off-by: Paul E. McKenney
> > > ---
> > > kernel/rcu/tree_plugin.h | 26 ++
> > > 1 file changed, 14 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> > > index 8b0feb2..fca31c6 100644
> > > --- a/kernel/rcu/tree_plugin.h
> > > +++ b/kernel/rcu/tree_plugin.h
> > > @@ -660,9 +660,9 @@ static void rcu_preempt_deferred_qs_handler(struct
> > > irq_work *iwp)
> > > static void rcu_read_unlock_special(struct task_struct *t)
> > > {
> > > unsigned long flags;
> > > + bool irqs_were_disabled;
> > > bool preempt_bh_were_disabled =
> > > !!(preempt_count() & (PREEMPT_MASK | SOFTIRQ_MASK));
> > > - bool irqs_were_disabled;
> > >
> > > /* NMI handlers cannot block and cannot safely manipulate state. */
> > > if (in_nmi())
> > > @@ -671,30 +671,32 @@ static void rcu_read_unlock_special(struct
> > > task_struct *t)
> > > local_irq_save(flags);
> > > irqs_were_disabled = irqs_disabled_flags(flags);
> > > if (preempt_bh_were_disabled || irqs_were_disabled) {
> > > - bool exp;
> > > + bool expboost; // Expedited GP in flight or possible boosting.
> > > struct rcu_data *rdp = this_cpu_ptr(_data);
> > > struct rcu_node *rnp = rdp->mynode;
> > >
> > > - exp = (t->rcu_blocked_node &&
> > > -READ_ONCE(t->rcu_blocked_node->exp_tasks)) ||
> > > - (rdp->grpmask & READ_ONCE(rnp->expmask));
> > > + expboost = (t->rcu_blocked_node &&
> > > READ_ONCE(t->rcu_blocked_node->exp_tasks)) ||
> > > +(rdp->grpmask & READ_ONCE(rnp->expmask)) ||
> > > +(IS_ENABLED(CONFIG_RCU_BOOST) && irqs_were_disabled
> > > &&
> > > + t->rcu_blocked_node);
> >
> > I take it that you check whether possible boosting is in progress via
> > the last expression of "||", ie:
> >
> > (IS_ENABLED(CONFIG_RCU_BOOST) && irqs_were_disabled &&
> > t->rcu_blocked_node)
> >
> > if so, I don't see the point of using the new "expboost" in the
> > raise_softirq_irqoff() branch, because if in_irq() is false, we only
> > raise softirq if irqs_were_disabled is false (otherwise, we may take the
> > risk of doing a wakeup with a pi or rq lock held, IIRC), and the
> > boosting part of the "expboost" above is only true if irqs_were_disabled
> > is true, so using expboost makes no different here.
>
> I started out with two local variables, one for each side of the ||,
> but this looked nicer.
>
> > > // Need to defer quiescent state until everything is enabled.
> > > - if (use_softirq && (in_irq() || (exp && !irqs_were_disabled))) {
> > > + if (use_softirq && (in_irq() || (expboost &&
> > > !irqs_were_disabled))) {
> > > // Using softirq, safe to awaken, and either the
> > > - // wakeup is free or there is an expedited GP.
> > > + // wakeup is free or there is either an expedited
> > > + // GP in flight or a potential need to deboost.
>
Re: [PATCH 1/1] scsi: sd: use max_xfer_blocks for set rw_max if max_xfer_blocks is available
> Hello Changheun! > > > I want to discuss using max_xfer_blocks instead of opt_xfer_blocks as > > a optional. For example, device reports opt_xfer_blocks is 512KB and > > 1MB as a max_xfer_blocks too. Currently rw_max is set with 512KB only. > > Because that's what the device asks for. If a device explicitly requests > us to use 512 KB I/Os we should not be sending it 1 MB requests. > > The spec is very clear. It says that if you send a command *larger* than > opt_xfer_blocks, you should expect *slower* performance. That makes > max_xfer_blocks a particularly poor choice for setting the default I/O > size. > > In addition to being slower, max_xfer_blocks could potentially also be > much, much larger than opt_xfer_blocks. I understand your 512 KB vs. 1 > MB example. But if the max_xfer_blocks limit is reported as 1 GB, is > that then the right value to use instead of 512 KB? Probably not. > > If a device does not report an opt_xfer_blocks value that suits your > workload, just override the resulting max_sectors_kb in sysfs. This is > intentionally a soft limit so it can be adjusted by the user without > having to change the kernel. > > -- > Martin K. PetersenOracle Linux Engineering > I understood what you said. I reviewed meaning of opt_xfer_blocks from SCSI spec again. I think below is what you saw in spec. The OPTIMAL TRANSFER LENGTH field indicates the optimal transfer size in logical blocks for a single command shown in table 197. If a device server receives one of these commands with a transfer size greater than this value, then the device server may incur significant delays in processing the command. If the OPTIMAL TRANSFER LENGTH field is set to zero, then there is no reported optimal transfer size. Thank you for kindly feedback. :) --- Changheun Lee Samsung Electronics
Re: [PATCH] cmd_dtc: Enable generation of device tree symbols
+frank On 1/25/21 3:53 PM, Masahiro Yamada wrote: > On Mon, Jan 25, 2021 at 8:07 PM Uwe Kleine-König > wrote: >> >> Adding the -@ switch to dtc results in the binary devicetrees containing >> a list of symbolic references and their paths. This is necessary to >> apply device tree overlays e.g. on Raspberry Pi as described on >> https://www.raspberrypi.org/documentation/configuration/device-tree.md. >> >> Obviously the downside of this change is an increas of the size of the >> generated dtbs, for an arm out-of-tree build (multi_v7_defconfig): >> >> $ du -s arch/arm/boot/dts* >> 101380 arch/arm/boot/dts-pre >> 114308 arch/arm/boot/dts-post >> >> so this is in average an increase of 12.8% in size. >> >> Signed-off-by: Uwe Kleine-König > > > (CCing DT ML.) > > > https://www.spinics.net/lists/linux-kbuild/msg27904.html > > See Rob's comment: > > "We've already rejected doing that. Turning on '-@' can grow the dtb > size by a significant amount which could be problematic for some > boards." > > > > > > > > >> --- >> scripts/Makefile.lib | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib >> index 213677a5ed33..0683a5808f7f 100644 >> --- a/scripts/Makefile.lib >> +++ b/scripts/Makefile.lib >> @@ -319,7 +319,7 @@ $(obj)/%.dtb.S: $(obj)/%.dtb FORCE >> >> quiet_cmd_dtc = DTC $@ >> cmd_dtc = $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) >> $< ; \ >> - $(DTC) -O $(patsubst .%,%,$(suffix $@)) -o $@ -b 0 \ >> + $(DTC) -@ -O $(patsubst .%,%,$(suffix $@)) -o $@ -b 0 \ >> $(addprefix -i,$(dir $<) $(DTC_INCLUDE)) $(DTC_FLAGS) \ >> -d $(depfile).dtc.tmp $(dtc-tmp) ; \ >> cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile) >> -- >> 2.29.2 >> > > > -- > Best Regards > > Masahiro Yamada >
Re: [PATCH] cmd_dtc: Enable generation of device tree symbols
+frank On 1/25/21 4:57 AM, Uwe Kleine-König wrote: > Adding the -@ switch to dtc results in the binary devicetrees containing > a list of symbolic references and their paths. This is necessary to > apply device tree overlays e.g. on Raspberry Pi as described on > https://www.raspberrypi.org/documentation/configuration/device-tree.md. > > Obviously the downside of this change is an increas of the size of the > generated dtbs, for an arm out-of-tree build (multi_v7_defconfig): > > $ du -s arch/arm/boot/dts* > 101380 arch/arm/boot/dts-pre > 114308 arch/arm/boot/dts-post > > so this is in average an increase of 12.8% in size. > > Signed-off-by: Uwe Kleine-König > --- > scripts/Makefile.lib | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib > index 213677a5ed33..0683a5808f7f 100644 > --- a/scripts/Makefile.lib > +++ b/scripts/Makefile.lib > @@ -319,7 +319,7 @@ $(obj)/%.dtb.S: $(obj)/%.dtb FORCE > > quiet_cmd_dtc = DTC $@ > cmd_dtc = $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) > $< ; \ > - $(DTC) -O $(patsubst .%,%,$(suffix $@)) -o $@ -b 0 \ > + $(DTC) -@ -O $(patsubst .%,%,$(suffix $@)) -o $@ -b 0 \ > $(addprefix -i,$(dir $<) $(DTC_INCLUDE)) $(DTC_FLAGS) \ > -d $(depfile).dtc.tmp $(dtc-tmp) ; \ > cat $(depfile).pre.tmp $(depfile).dtc.tmp > $(depfile) >
Re: [RFC 2/7] KVM: VMX: Expose IA32_PKRS MSR
On 07/08/20 10:48, Chenyi Qiang wrote:
+{
+ struct vcpu_vmx *vmx = to_vmx(vcpu);
+ unsigned long *msr_bitmap = vmx->vmcs01.msr_bitmap;
+ bool pks_supported = guest_cpuid_has(vcpu, X86_FEATURE_PKS);
+
+ /*
+* set intercept for PKRS when the guest doesn't support pks
+*/
+ vmx_set_intercept_for_msr(msr_bitmap, MSR_IA32_PKRS, MSR_TYPE_RW,
!pks_supported);
+
+ if (pks_supported) {
+ vm_entry_controls_setbit(vmx, VM_ENTRY_LOAD_IA32_PKRS);
+ vm_exit_controls_setbit(vmx, VM_EXIT_LOAD_IA32_PKRS);
+ } else {
+ vm_entry_controls_clearbit(vmx, VM_ENTRY_LOAD_IA32_PKRS);
+ vm_exit_controls_clearbit(vmx, VM_EXIT_LOAD_IA32_PKRS);
+ }
Is the guest expected to do a lot of reads/writes to the MSR (e.g. at
every context switch)?
Even if this is the case, the MSR intercepts and the entry/exit controls
should only be done if CR4.PKS=1. If the guest does not use PKS, KVM
should behave as if these patches did not exist.
Paolo
Re: linux-next: build failure after merge of the scsi-mkp tree
Hi all,
On Mon, 25 Jan 2021 00:53:59 -0500 Douglas Gilbert
wrote:
>
> On 2021-01-24 11:13 p.m., Stephen Rothwell wrote:
> >
> > After merging the scsi-mkp tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > drivers/scsi/sg.c: In function 'sg_find_srp_by_id':
> > drivers/scsi/sg.c:2908:4: error: expected '}' before 'else'
> > 2908 |else
> >|^~~~
> > drivers/scsi/sg.c:2902:16: warning: unused variable 'cptp'
> > [-Wunused-variable]
> > 2902 |const char *cptp = "pack_id=";
> >|^~~~
> > drivers/scsi/sg.c:2896:5: error: label 'good' used but not defined
> > 2896 | goto good;
> >| ^~~~
> > drivers/scsi/sg.c: At top level:
> > drivers/scsi/sg.c:2913:2: error: expected identifier or '(' before 'return'
> > 2913 | return NULL;
> >| ^~
> > drivers/scsi/sg.c:2914:5: error: expected '=', ',', ';', 'asm' or
> > '__attribute__' before ':' token
> > 2914 | good:
> >| ^
> > drivers/scsi/sg.c:2917:2: error: expected identifier or '(' before 'return'
> > 2917 | return srp;
> >| ^~
> > drivers/scsi/sg.c:2918:1: error: expected identifier or '(' before '}' token
> > 2918 | }
> >| ^
> > drivers/scsi/sg.c: In function 'sg_find_srp_by_id':
> > drivers/scsi/sg.c:2912:2: error: control reaches end of non-void function
> > [-Werror=return-type]
> > 2912 | }
> >| ^
> >
> > Caused by commit
> >
> >7323ad3618b6 ("scsi: sg: Replace rq array with xarray")
> >
> > SG_LOG() degenerates to "{}" in some configs ...
> >
> > I have used the scsi-mkp tree from next-20210122 for today.
>
> I sent a new patchset to the linux-scsi list about 4 hours ago to
> fix that.
>
> Doug Gilbert
I am still getting this build failure.
--
Cheers,
Stephen Rothwell
pgpvMxxBAph6M.pgp
Description: OpenPGP digital signature
Re: [PATCH v3 1/2] bio: limit bio max size
> On Tue, Jan 26, 2021 at 06:26:02AM +, Damien Le Moal wrote:
> > On 2021/01/26 15:07, Ming Lei wrote:
> > > On Tue, Jan 26, 2021 at 04:06:06AM +, Damien Le Moal wrote:
> > >> On 2021/01/26 12:58, Ming Lei wrote:
> > >>> On Tue, Jan 26, 2021 at 10:32:34AM +0900, Changheun Lee wrote:
> > bio size can grow up to 4GB when muli-page bvec is enabled.
> > but sometimes it would lead to inefficient behaviors.
> > in case of large chunk direct I/O, - 32MB chunk read in user space -
> > all pages for 32MB would be merged to a bio structure if the pages
> > physical addresses are contiguous. it makes some delay to submit
> > until merge complete. bio max size should be limited to a proper size.
> >
> > When 32MB chunk read with direct I/O option is coming from userspace,
> > kernel behavior is below now. it's timeline.
> >
> > | bio merge for 32MB. total 8,192 pages are merged.
> > | total elapsed time is over 2ms.
> > |-- ... --->|
> > | 8,192 pages merged
> > a bio.
> > | at this time, first
> > bio submit is done.
> > | 1 bio is split to
> > 32 read request and issue.
> > |--->
> > |--->
> > |--->
> > ..
> >
> > |--->
> >
> > |--->|
> > total 19ms elapsed to complete 32MB read
> > done from device. |
> >
> > If bio max size is limited with 1MB, behavior is changed below.
> >
> > | bio merge for 1MB. 256 pages are merged for each bio.
> > | total 32 bio will be made.
> > | total elapsed time is over 2ms. it's same.
> > | but, first bio submit timing is fast. about 100us.
> > |--->|--->|--->|---> ... -->|--->|--->|--->|--->|
> > | 256 pages merged a bio.
> > | at this time, first bio submit is done.
> > | and 1 read request is issued for 1 bio.
> > |--->
> > |--->
> > |--->
> > ..
> > |--->
> > |--->|
> > total 17ms elapsed to complete 32MB read done from device. |
> >
> > As a result, read request issue timing is faster if bio max size is
> > limited.
> > Current kernel behavior with multipage bvec, super large bio can be
> > created.
> > And it lead to delay first I/O request issue.
> >
> > Signed-off-by: Changheun Lee
> > ---
> > block/bio.c| 17 -
> > include/linux/bio.h| 4 +++-
> > include/linux/blkdev.h | 3 +++
> > 3 files changed, 22 insertions(+), 2 deletions(-)
> >
> > diff --git a/block/bio.c b/block/bio.c
> > index 1f2cc1fbe283..ec0281889045 100644
> > --- a/block/bio.c
> > +++ b/block/bio.c
> > @@ -287,6 +287,21 @@ void bio_init(struct bio *bio, struct bio_vec
> > *table,
> > }
> > EXPORT_SYMBOL(bio_init);
> >
> > +unsigned int bio_max_size(struct bio *bio)
> > +{
> > + struct request_queue *q;
> > +
> > + if (!bio->bi_disk)
> > + return UINT_MAX;
> > +
> > + q = bio->bi_disk->queue;
> > + if (!blk_queue_limit_bio_size(q))
> > + return UINT_MAX;
> > +
> > + return blk_queue_get_max_sectors(q, bio_op(bio)) <<
> > SECTOR_SHIFT;
> > +}
> > +EXPORT_SYMBOL(bio_max_size);
> > +
> > /**
> > * bio_reset - reinitialize a bio
> > * @bio: bio to reset
> > @@ -877,7 +892,7 @@ bool __bio_try_merge_page(struct bio *bio, struct
> > page *page,
> > struct bio_vec *bv = >bi_io_vec[bio->bi_vcnt - 1];
> >
> > if (page_is_mergeable(bv, page, len, off, same_page)) {
> > - if (bio->bi_iter.bi_size > UINT_MAX - len) {
> > + if (bio->bi_iter.bi_size > bio_max_size(bio) -
> > len) {
> > *same_page = false;
> > return false;
> > }
> > >>>
> > >>> So far we don't need bio->bi_disk or
Re: [RFC PATCH v2] uacce: Add uacce_ctrl misc device
On Tue, Jan 26, 2021 at 01:26:45AM +, Song Bao Hua (Barry Song) wrote: > > On Mon, Jan 25, 2021 at 11:35:22PM +, Song Bao Hua (Barry Song) wrote: > > > > > > On Mon, Jan 25, 2021 at 10:21:14PM +, Song Bao Hua (Barry Song) > > > > wrote: > > > > > mlock, while certainly be able to prevent swapping out, it won't > > > > > be able to stop page moving due to: > > > > > * memory compaction in alloc_pages() > > > > > * making huge pages > > > > > * numa balance > > > > > * memory compaction in CMA > > > > > > > > Enabling those things is a major reason to have SVA device in the > > > > first place, providing a SW API to turn it all off seems like the > > > > wrong direction. > > > > > > I wouldn't say this is a major reason to have SVA. If we read the > > > history of SVA and papers, people would think easy programming due > > > to data struct sharing between cpu and device, and process space > > > isolation in device would be the major reasons for SVA. SVA also > > > declares it supports zero-copy while zero-copy doesn't necessarily > > > depend on SVA. > > > > Once you have to explicitly make system calls to declare memory under > > IO, you loose all of that. > > > > Since you've asked the app to be explicit about the DMAs it intends to > > do, there is not really much reason to use SVA for those DMAs anymore. > > Let's see a non-SVA case. We are not using SVA, we can have > a memory pool by hugetlb or pin, and app can allocate memory > from this pool, and get stable I/O performance on the memory > from the pool. But device has its separate page table which > is not bound with this process, thus lacking the protection > of process space isolation. Plus, CPU and device are using > different address. So you are relying on the platform to do the SVA for the device? This feels like it goes back to another topic where I felt the SVA setup uAPI should be shared and not buried into every driver's unique ioctls. Having something like this in a shared SVA system is somewhat less strange. Jason
IMPORTANT INVESTMENT INFORMATION..72
ATTENTION; IMPORTANT INVESTMENT INFORMATION We have a good investment program going on now. We have $95m USD for Investment in your Country. We use this opportunity to invest you to join the investment program and you will never regret it. Please kindly invest with us and you will be receiving monthly income/return/profit every month. Reply for more detail. Thank you Sir. Robert Nelson.
Re: [PATCH 07/13] opp: Allow _generic_set_opp_clk_only() to work for non-freq devices
On 26-01-21, 00:09, Dmitry Osipenko wrote: > Please remove unlikely() around IS_ERR(), it already has the unlikely(). Right. > https://elixir.bootlin.com/linux/v5.11-rc4/source/include/linux/err.h#L22 > > I'd also recommend to remove all the unlikely() from OPP code since it > doesn't bring any value if not used in a very performance-critical code > path. OPP core doesn't have such code paths. The [un]likely() only make > code less readable and may result in a worse assembly. The likely/unlikely() stuff is to optimize code, not necessarily the stuff in the hot path alone, therwise stuff like IS_ERR() would never have it. It surely does bring value by optimizing the code, surely the result isn't significant enough but that is fine, every effort counts. AFAIK, if we are sure of path the code will almost always take, then we should rather use these and so I am inclined towards keeping them. Though I understand that using them may result in bad behavior (performance) if they fail. -- viresh
Re: [PATCH v3 1/2] bio: limit bio max size
On 2021/01/27 9:36, Changheun Lee wrote:
>>> +
>>> /**
>>> * bio_reset - reinitialize a bio
>>> * @bio: bio to reset
>>> @@ -877,7 +892,7 @@ bool __bio_try_merge_page(struct bio *bio, struct page
>>> *page,
>>> struct bio_vec *bv = >bi_io_vec[bio->bi_vcnt - 1];
>>>
>>> if (page_is_mergeable(bv, page, len, off, same_page)) {
>>> - if (bio->bi_iter.bi_size > UINT_MAX - len) {
>>> + if (bio->bi_iter.bi_size > bio_max_size(bio) - len) {
>>> *same_page = false;
>>> return false;
>>> }
>>> diff --git a/include/linux/bio.h b/include/linux/bio.h
>>> index 1edda614f7ce..cdb134ca7bf5 100644
>>> --- a/include/linux/bio.h
>>> +++ b/include/linux/bio.h
>>> @@ -100,6 +100,8 @@ static inline void *bio_data(struct bio *bio)
>>> return NULL;
>>> }
>>>
>>> +extern unsigned int bio_max_size(struct bio *);
>>
>> No need for extern.
>
> It's just for compile warning in my test environment.
> I'll remove it too. But I think compile warning could be in the other
> .c file which includes bio.h. Is it OK?
Hmmm... not having extern should not generate a compilation warning. There are
tons of functions declared without extern in header files in the kernel. What
compiler are you using ?
--
Damien Le Moal
Western Digital Research
linux-next: manual merge of the scsi-mkp tree with the block tree
Hi all,
Today's linux-next merge of the scsi-mkp tree got a conflict in:
drivers/scsi/sg.c
between commit:
8eeed0b554b9 ("block: remove unnecessary argument from blk_execute_rq_nowait")
from the block tree and vaious commits from the scsi-mkp tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/scsi/sg.c
index 4383d93110f8,c5a34bb91335..
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@@ -437,73 -858,243 +858,242 @@@ sg_rq_state_chg(struct sg_request *srp
return 0;
}
- static ssize_t
- sg_read(struct file *filp, char __user *buf, size_t count, loff_t * ppos)
+ /*
+ * All writes and submits converge on this function to launch the SCSI
+ * command/request (via blk_execute_rq_nowait). Returns a pointer to a
+ * sg_request object holding the request just issued or a negated errno
+ * value twisted by ERR_PTR.
+ */
+ static struct sg_request *
+ sg_common_write(struct sg_fd *sfp, struct sg_comm_wr_t *cwrp)
{
- Sg_device *sdp;
- Sg_fd *sfp;
- Sg_request *srp;
- int req_pack_id = -1;
- sg_io_hdr_t *hp;
- struct sg_header *old_hdr;
- int retval;
+ bool at_head;
+ int res = 0;
+ int dxfr_len, dir, cmd_len;
+ int pack_id = SG_PACK_ID_WILDCARD;
+ u32 rq_flags;
+ struct sg_device *sdp = sfp->parentdp;
+ struct sg_request *srp;
+ struct sg_io_hdr *hi_p;
+
+ hi_p = cwrp->h3p;
+ dir = hi_p->dxfer_direction;
+ dxfr_len = hi_p->dxfer_len;
+ rq_flags = hi_p->flags;
+ pack_id = hi_p->pack_id;
+ if (dxfr_len >= SZ_256M)
+ return ERR_PTR(-EINVAL);
+
+ srp = sg_setup_req(sfp, dxfr_len, cwrp);
+ if (IS_ERR(srp))
+ return srp;
+ srp->rq_flags = rq_flags;
+ srp->pack_id = pack_id;
+
+ cmd_len = hi_p->cmd_len;
+ memcpy(>s_hdr3, hi_p, sizeof(srp->s_hdr3));
+ srp->cmd_opcode = cwrp->cmnd[0];/* hold opcode of command for debug */
+ SG_LOG(4, sfp, "%s: opcode=0x%02x, cdb_sz=%d, pack_id=%d\n", __func__,
+ (int)cwrp->cmnd[0], cmd_len, pack_id);
+
+ res = sg_start_req(srp, cwrp->cmnd, cmd_len, dir);
+ if (res < 0)/* probably out of space --> -ENOMEM */
+ goto err_out;
+ if (unlikely(SG_IS_DETACHING(sdp))) {
+ res = -ENODEV;
+ goto err_out;
+ }
+ if (unlikely(test_bit(SG_FRQ_BLK_PUT_REQ, srp->frq_bm) || !srp->rq)) {
+ res = -EIDRM; /* this failure unexpected but observed */
+ goto err_out;
+ }
+ if (xa_get_mark(>srp_arr, srp->rq_idx, SG_XA_RQ_FREE)) {
+ SG_LOG(1, sfp, "%s: ahhh, request erased!!!\n", __func__);
+ res = -ENODEV;
+ goto err_out;
+ }
+ srp->rq->timeout = cwrp->timeout;
+ kref_get(>f_ref); /* sg_rq_end_io() does kref_put(). */
+ res = sg_rq_state_chg(srp, SG_RS_BUSY, SG_RS_INFLIGHT, false,
+ __func__);
+ if (res)
+ goto err_out;
+ srp->start_ns = ktime_get_boottime_ns();
+ srp->duration = 0;
+
+ if (srp->s_hdr3.interface_id == '\0')
+ at_head = true; /* backward compatibility: v1+v2 interfaces */
+ else if (test_bit(SG_FFD_Q_AT_TAIL, sfp->ffd_bm))
+ /* cmd flags can override sfd setting */
+ at_head = !!(srp->rq_flags & SG_FLAG_Q_AT_HEAD);
+ else/* this sfd is defaulting to head */
+ at_head = !(srp->rq_flags & SG_FLAG_Q_AT_TAIL);
+ if (!test_bit(SG_FRQ_SYNC_INVOC, srp->frq_bm))
+ atomic_inc(>submitted);
- blk_execute_rq_nowait(sdp->device->request_queue, sdp->disk,
-srp->rq, at_head, sg_rq_end_io);
++ blk_execute_rq_nowait(sdp->disk, srp->rq, at_head, sg_rq_end_io);
+ return srp;
+ err_out:
+ sg_finish_scsi_blk_rq(srp);
+ sg_deact_request(sfp, srp);
+ return ERR_PTR(res);
+ }
- /*
-* This could cause a response to be stranded. Close the associated
-* file descriptor to free up any resources being held.
-*/
- retval = sg_check_file_access(filp, __func__);
- if (retval)
- return retval;
+ /*
+ * This function is called by wait_event_interruptible in sg_read() and
+ * sg_ctl_ioreceive(). wait_event_interruptible will return if this one
+ * returns true (or an event like a signal (e.g. control-C) occurs).
+ */
- if ((!(sfp = (Sg_fd *) filp->private_data)) || (!(sdp = sfp->parentdp)))
- return -ENXIO;
-
Re: [PATCH v2 0/6] Stop NULLifying match pointer in of_match_device()
On Fri, Jan 22, 2021 at 9:44 PM Stephen Boyd wrote: > > (This is a continuation of this series[1] per Rob's request. I've picked > up the acks, etc. with b4 and compile tested the patches along with an > arm64 allmodconfig build. Presumably Rob will pick these up directly.) > > of_match_device() uses of_match_ptr() to make the match table argument > NULL via the pre-processor when CONFIG_OF=n. This makes life harder for > compilers who think that match tables are never used and warn about > unused variables when CONFIG_OF=n. This series changes various callers > to use of_device_get_match_data() instead, which doesn't have this > problem, and removes the of_match_ptr() usage from of_match_device() so > that the compiler can stop complaining about unused variables. It will > do dead code elimination instead and remove the match table if it isn't > actually used. > > [1] https://lore.kernel.org/r/20191004214334.149976-1-swb...@chromium.org > > Cc: Alexandre Torgue > Cc: Arnd Bergmann > Cc: "David S. Miller" > Cc: Frank Rowand > Cc: Geert Uytterhoeven > Cc: Greg Kroah-Hartman > Cc: Grygorii Strashko > Cc: Guenter Roeck > Cc: Jacopo Mondi > Cc: Jean Delvare > Cc: Jiri Slaby > Cc: > Cc: , > Cc: > Cc: > Cc: > Cc: > Cc: > Cc: Mauro Carvalho Chehab > Cc: Maxime Coquelin > Cc: Richard Leitner > Cc: Rob Herring > > Stephen Boyd (6): > media: renesas-ceu: Use of_device_get_match_data() > drivers: net: davinci_mdio: Use of_device_get_match_data() > serial: stm32: Use of_device_get_match_data() > usb: usb251xb: Use of_device_get_match_data() > hwmon: (lm70) Avoid undefined reference to match table > of/device: Don't NULLify match table in of_match_device() with > CONFIG_OF=n > > drivers/hwmon/lm70.c | 2 +- > drivers/media/platform/renesas-ceu.c | 2 +- > drivers/net/ethernet/ti/davinci_mdio.c | 12 ++--- > drivers/tty/serial/stm32-usart.c | 71 -- > drivers/tty/serial/stm32-usart.h | 2 +- > drivers/usb/misc/usb251xb.c| 12 ++--- > include/linux/of_device.h | 4 +- > 7 files changed, 47 insertions(+), 58 deletions(-) Series applied. Rob
Re: [PATCH v3 4/5] amba: Make the remove callback return void
On Tue, 26 Jan 2021 17:58:34 +0100, Uwe Kleine-König wrote: > > All amba drivers return 0 in their remove callback. Together with the > driver core ignoring the return value anyhow, it doesn't make sense to > return a value here. > > Change the remove prototype to return void, which makes it explicit that > returning an error value doesn't work as expected. This simplifies changing > the core remove callback to return void, too. > > Reviewed-by: Ulf Hansson > Reviewed-by: Arnd Bergmann > Acked-by: Alexandre Belloni > Acked-by: Dmitry Torokhov > Acked-by: Krzysztof Kozlowski # for drivers/memory > Acked-by: Mark Brown > Acked-by: Dmitry Torokhov > Acked-by: Linus Walleij > Signed-off-by: Uwe Kleine-König > --- > drivers/amba/bus.c | 5 ++--- > drivers/char/hw_random/nomadik-rng.c | 3 +-- > drivers/dma/pl330.c| 3 +-- > drivers/gpu/drm/pl111/pl111_drv.c | 4 +--- > drivers/hwtracing/coresight/coresight-catu.c | 3 +-- > drivers/hwtracing/coresight/coresight-cpu-debug.c | 4 +--- > drivers/hwtracing/coresight/coresight-cti-core.c | 4 +--- > drivers/hwtracing/coresight/coresight-etb10.c | 4 +--- > drivers/hwtracing/coresight/coresight-etm3x-core.c | 4 +--- > drivers/hwtracing/coresight/coresight-etm4x-core.c | 4 +--- > drivers/hwtracing/coresight/coresight-funnel.c | 4 ++-- > drivers/hwtracing/coresight/coresight-replicator.c | 4 ++-- > drivers/hwtracing/coresight/coresight-stm.c| 4 +--- > drivers/hwtracing/coresight/coresight-tmc-core.c | 4 +--- > drivers/hwtracing/coresight/coresight-tpiu.c | 4 +--- > drivers/i2c/busses/i2c-nomadik.c | 4 +--- > drivers/input/serio/ambakmi.c | 3 +-- > drivers/memory/pl172.c | 4 +--- > drivers/memory/pl353-smc.c | 4 +--- > drivers/mmc/host/mmci.c| 4 +--- > drivers/rtc/rtc-pl030.c| 4 +--- > drivers/rtc/rtc-pl031.c| 4 +--- > drivers/spi/spi-pl022.c| 5 ++--- > drivers/tty/serial/amba-pl010.c| 4 +--- > drivers/tty/serial/amba-pl011.c| 3 +-- > drivers/vfio/platform/vfio_amba.c | 3 +-- > drivers/video/fbdev/amba-clcd.c| 4 +--- > drivers/watchdog/sp805_wdt.c | 4 +--- > include/linux/amba/bus.h | 2 +- > sound/arm/aaci.c | 4 +--- For the sound/*: Acked-by: Takashi Iwai thanks, Takashi
Re: [PATCH v4 0/4] OPP API fixes and improvements
On 22-01-21, 13:04, Viresh Kumar wrote: > Patch 2 can be applied only after the dependency patch for the stub > definition gets merge in Linus's tree. I see that Mark has already > queued that up in his for-5.11 branch, so it might be part of next > -rc. I will apply 2nd patch then. The consumer.h patch landed into Linus's tree this morning and hence I have applied the last patch 2/4 from this series as well. Thanks. -- viresh
Re: [PATCH v5] fbtft: add tearing signal detect
On Wed, Jan 27, 2021 at 02:19:27PM +0800, carlis wrote:
> hi,i will fix it like below:
> par->gpio.te = devm_gpiod_get_index_optional(dev, "te", 0,
> GPIOD_IN); if (IS_ERR(par->gpio.te)) {
> rc = PTR_ERR(par->gpio.te);
> pr_err("Failed to request te gpio: %d\n", rc);
> par->gpio.te = NULL;
> }
I wish you would just copy and paste the code that I sent you instead,
but this also fixes the crash...
regards,
dan carpenter
Re: [PATCH] MAINTAINERS/.mailmap: Use my @kernel.org address
On Wed, Jan 27, 2021 at 6:07 AM Lukas Bulwahn wrote: > > On Tue, Jan 26, 2021 at 10:27 PM Nathan Chancellor wrote: > > > > Use my @kernel.org for all points of contact so that I am always > > accessible. > > > > Signed-off-by: Nathan Chancellor > > Congrats, Nathan. You deserve it for all the warning fixes, reports, > maintenance, CI, reviews and much more stuff you are doing. > +1 Congrats Nathan. - Sedat -
Re: [PATCH 2/2] mm/hugetlb: refactor subpage recording
On 26 Jan 2021, at 21:24, Matthew Wilcox wrote:
> On Tue, Jan 26, 2021 at 08:07:30PM -0400, Jason Gunthorpe wrote:
>> I'm looking at Matt's folio patches and see:
>>
>> +static inline struct folio *next_folio(struct folio *folio)
>> +{
>> + return folio + folio_nr_pages(folio);
>> +}
>
> This is a replacement for places that would do 'page++'. eg it's
> used by the bio iterator where we already checked that the phys addr
> and the struct page are contiguous.
>
>> And checking page_trans_huge_mapcount():
>>
>> for (i = 0; i < thp_nr_pages(page); i++) {
>> mapcount = atomic_read([i]._mapcount) + 1;
>
> I think we are guaranteed this for transparent huge pages. At least
> for now. Zi Yan may have some thoughts for his work on 1GB transhuge
> pages ...
It should work for 1GB THP too. My implementation allocates 1GB pages
from cma_alloc(), which calls alloc_contig_range(). At least for now
subpages from a 1GB THP are physically contiguous.
It will be a concern if we use other ways (like migrating in-use pages)
of forming 1GB THPs. Thanks for pointing this out.
>
>> And we have the same logic in hmm_vma_walk_pud():
>>
>> if (pud_huge(pud) && pud_devmap(pud)) {
>> pfn = pud_pfn(pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
>> for (i = 0; i < npages; ++i, ++pfn)
>> hmm_pfns[i] = pfn | cpu_flags;
>>
>> So, if page[n] does not access the tail pages of a compound we have
>> many more people who are surprised by this than just GUP.
>>
>> Where are these special rules for hugetlb compound tails documented?
>> Why does it need to be like this?
>>
>> Isn't it saner to forbid a compound and its tails from being
>> non-linear in the page array? That limits when compounds can be
>> created, but seems more likely to happen than a full mm audit to find
>> all the places that assume linearity.
>>
>> Jason
—
Best Regards,
Yan Zi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v3 4/5] amba: Make the remove callback return void
On Tue, Jan 26, 2021 at 05:58:34PM +0100, Uwe Kleine-König wrote: > All amba drivers return 0 in their remove callback. Together with the > driver core ignoring the return value anyhow, it doesn't make sense to > return a value here. > > Change the remove prototype to return void, which makes it explicit that > returning an error value doesn't work as expected. This simplifies changing > the core remove callback to return void, too. > > Reviewed-by: Ulf Hansson > Reviewed-by: Arnd Bergmann > Acked-by: Alexandre Belloni > Acked-by: Dmitry Torokhov > Acked-by: Krzysztof Kozlowski # for drivers/memory > Acked-by: Mark Brown > Acked-by: Dmitry Torokhov > Acked-by: Linus Walleij > Signed-off-by: Uwe Kleine-König Acked-by: Wolfram Sang # for I2C signature.asc Description: PGP signature
Re: [PATCH v4 0/2] add support for GPIO based counter
On Tue, Jan 26, 2021 at 02:18:34PM +0100, Marc Kleine-Budde wrote: > On 1/26/21 2:12 PM, Oleksij Rempel wrote: > > changes v4: > > - use IRQ_NOAUTOEN to not enable IRQ by default > > - rename gpio_ from name pattern and make this driver work any IRQ > > source. > > > > changes v3: > > - convert counter to atomic_t > > What's the guaranteed width of atomic_t? IIRC a long time ago it was 24 bit > only 32 bits. The counter is wrapped after 4294967295 Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[rcu:dev.2021.01.22b] BUILD SUCCESS c6f6fddad7c84f0bd7fba3f1b076b71d6b902ab4
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev.2021.01.22b branch HEAD: c6f6fddad7c84f0bd7fba3f1b076b71d6b902ab4 rcu-tasks: Rectify kernel-doc for struct rcu_tasks elapsed time: 726m configs tested: 103 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig xtensageneric_kc705_defconfig x86_64 allyesconfig nios2 10m50_defconfig powerpc mpc8315_rdb_defconfig powerpc mpc85xx_cds_defconfig xtensa virt_defconfig arc haps_hs_defconfig arm prima2_defconfig mips rs90_defconfig armxcep_defconfig mips tb0287_defconfig sh polaris_defconfig xtensasmp_lx200_defconfig pariscgeneric-32bit_defconfig powerpc stx_gp3_defconfig powerpc kilauea_defconfig mips rt305x_defconfig mips cavium_octeon_defconfig arm netwinder_defconfig powerpc katmai_defconfig arm viper_defconfig armtrizeps4_defconfig arm aspeed_g4_defconfig powerpc pq2fads_defconfig powerpc powernv_defconfig arm pcm027_defconfig mips capcella_defconfig arm ep93xx_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a001-20210126 i386 randconfig-a002-20210126 i386 randconfig-a004-20210126 i386 randconfig-a006-20210126 i386 randconfig-a003-20210126 i386 randconfig-a005-20210126 x86_64 randconfig-a012-20210126 x86_64 randconfig-a016-20210126 x86_64 randconfig-a015-20210126 x86_64 randconfig-a011-20210126 x86_64 randconfig-a013-20210126 x86_64 randconfig-a014-20210126 i386 randconfig-a013-20210126 i386 randconfig-a011-20210126 i386 randconfig-a012-20210126 i386 randconfig-a015-20210126 i386 randconfig-a014-20210126 i386 randconfig-a016-20210126 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 rhel-8.3-kbuiltin x86_64 kexec clang tested configs: x86_64 randconfig-a003-20210126 x86_64 randconfig-a002-20210126 x86_64 randconfig
[PATCH] ASoC: qcom: lpass-cpu: Remove bit clock state check
No need of BCLK state maintenance from driver side as
clock_enable and clk_disable API's maintaing state counter.
One of the major issue was spotted when Headset jack inserted
while playback continues, due to same PCM device node opens twice
for playaback/capture and closes once for capture and playback continues.
It can resolve the errors in such scenarios.
Signed-off-by: Srinivasa Rao Mandadapu
---
sound/soc/qcom/lpass-cpu.c | 22 --
sound/soc/qcom/lpass-lpaif-reg.h | 3 ---
sound/soc/qcom/lpass.h | 1 -
3 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index ae8efbc89af2..a669202e0001 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -286,16 +286,12 @@ static int lpass_cpu_daiops_trigger(struct
snd_pcm_substream *substream,
dev_err(dai->dev, "error writing to i2sctl reg: %d\n",
ret);
- if (drvdata->bit_clk_state[id] == LPAIF_BIT_CLK_DISABLE) {
- ret = clk_enable(drvdata->mi2s_bit_clk[id]);
- if (ret) {
- dev_err(dai->dev, "error in enabling mi2s bit
clk: %d\n", ret);
- clk_disable(drvdata->mi2s_osr_clk[id]);
- return ret;
- }
- drvdata->bit_clk_state[id] = LPAIF_BIT_CLK_ENABLE;
+ ret = clk_enable(drvdata->mi2s_bit_clk[id]);
+ if (ret) {
+ dev_err(dai->dev, "error in enabling mi2s bit clk:
%d\n", ret);
+ clk_disable(drvdata->mi2s_osr_clk[id]);
+ return ret;
}
-
break;
case SNDRV_PCM_TRIGGER_STOP:
case SNDRV_PCM_TRIGGER_SUSPEND:
@@ -310,10 +306,9 @@ static int lpass_cpu_daiops_trigger(struct
snd_pcm_substream *substream,
if (ret)
dev_err(dai->dev, "error writing to i2sctl reg: %d\n",
ret);
- if (drvdata->bit_clk_state[id] == LPAIF_BIT_CLK_ENABLE) {
- clk_disable(drvdata->mi2s_bit_clk[dai->driver->id]);
- drvdata->bit_clk_state[id] = LPAIF_BIT_CLK_DISABLE;
- }
+
+ clk_disable(drvdata->mi2s_bit_clk[dai->driver->id]);
+
break;
}
@@ -861,7 +856,6 @@ int asoc_qcom_lpass_cpu_platform_probe(struct
platform_device *pdev)
PTR_ERR(drvdata->mi2s_bit_clk[dai_id]));
return PTR_ERR(drvdata->mi2s_bit_clk[dai_id]);
}
- drvdata->bit_clk_state[dai_id] = LPAIF_BIT_CLK_DISABLE;
}
/* Allocation for i2sctl regmap fields */
diff --git a/sound/soc/qcom/lpass-lpaif-reg.h b/sound/soc/qcom/lpass-lpaif-reg.h
index 405542832e99..c8e1d75340b2 100644
--- a/sound/soc/qcom/lpass-lpaif-reg.h
+++ b/sound/soc/qcom/lpass-lpaif-reg.h
@@ -60,9 +60,6 @@
#define LPAIF_I2SCTL_BITWIDTH_24 1
#define LPAIF_I2SCTL_BITWIDTH_32 2
-#define LPAIF_BIT_CLK_DISABLE 0
-#define LPAIF_BIT_CLK_ENABLE 1
-
#define LPAIF_I2SCTL_RESET_STATE 0x003C0004
#define LPAIF_DMACTL_RESET_STATE 0x0020
diff --git a/sound/soc/qcom/lpass.h b/sound/soc/qcom/lpass.h
index 2d68af0da34d..83b2e08ade06 100644
--- a/sound/soc/qcom/lpass.h
+++ b/sound/soc/qcom/lpass.h
@@ -68,7 +68,6 @@ struct lpass_data {
unsigned int mi2s_playback_sd_mode[LPASS_MAX_MI2S_PORTS];
unsigned int mi2s_capture_sd_mode[LPASS_MAX_MI2S_PORTS];
int hdmi_port_enable;
- int bit_clk_state[LPASS_MAX_MI2S_PORTS];
/* low-power audio interface (LPAIF) registers */
void __iomem *lpaif;
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH 3/8] lib: bitmap: fold nbits into region struct
On Tue, Jan 26, 2021 at 9:12 AM Paul Gortmaker
wrote:
>
> This will reduce parameter passing and enable using nbits as part
> of future dynamic region parameter parsing.
>
> Cc: Yury Norov
> Cc: Rasmus Villemoes
> Cc: Andy Shevchenko
> Suggested-by: Yury Norov
> Signed-off-by: Paul Gortmaker
> ---
> lib/bitmap.c | 19 ++-
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/lib/bitmap.c b/lib/bitmap.c
> index 75006c4036e9..162e2850c622 100644
> --- a/lib/bitmap.c
> +++ b/lib/bitmap.c
> @@ -487,24 +487,24 @@ EXPORT_SYMBOL(bitmap_print_to_pagebuf);
>
> /*
> * Region 9-38:4/10 describes the following bitmap structure:
> - * 0 9 1218 38
> - * .......
> - * ^ ^ ^ ^
> - * start off group_lenend
> + * 0 9 1218 38 N
> + * .......
> + * ^ ^ ^ ^ ^
> + * start off group_lenend nbits
> */
> struct region {
> unsigned int start;
> unsigned int off;
> unsigned int group_len;
> unsigned int end;
> + unsigned int nbits;
> };
>
> -static int bitmap_set_region(const struct region *r,
> - unsigned long *bitmap, int nbits)
> +static int bitmap_set_region(const struct region *r, unsigned long *bitmap)
> {
> unsigned int start;
>
> - if (r->end >= nbits)
> + if (r->end >= r->nbits)
> return -ERANGE;
>
> for (start = r->start; start <= r->end; start += r->group_len)
> @@ -640,7 +640,8 @@ int bitmap_parselist(const char *buf, unsigned long
> *maskp, int nmaskbits)
> struct region r;
> long ret;
>
> - bitmap_zero(maskp, nmaskbits);
> + r.nbits = nmaskbits;
> + bitmap_zero(maskp, r.nbits);
>
> while (buf) {
> buf = bitmap_find_region(buf);
> @@ -655,7 +656,7 @@ int bitmap_parselist(const char *buf, unsigned long
> *maskp, int nmaskbits)
> if (ret)
> return ret;
>
> - ret = bitmap_set_region(, maskp, nmaskbits);
> + ret = bitmap_set_region(, maskp);
> if (ret)
> return ret;
> }
> --
> 2.17.1
Acked-by: Yury Norov
Re: [PATCH 1/2] fs/efs/inode.c: follow style guide
On 1/26/21 9:13 PM, Amy Parker wrote: > On Tue, Jan 26, 2021 at 7:59 PM Randy Dunlap wrote: >> >> On 1/26/21 7:46 PM, Randy Dunlap wrote: >>> Hi Amy, >>> >>> What mail client did you use? >>> It is breaking (splitting) long lines into shorter lines and that >>> makes it not possible to apply the patch cleanly. > > Was worried about that, thought I had all my settings straightened out. > >>> >>> You can see this problem below or on the web in an email archive. >>> >>> Possibly Documentation/process/email-clients.rst can help you. > > Yeah, read that. Thought I had everything fixed up. > >> >> Also tabs in the source file have been converted to spaces. > > Was this inconsistent throughout the patch? I can't really seem to > tell. If it's consistent, bet it's probably my mail client - if it's > inconsistent it could be my editor, I had to switch out temporarily > for a different editor today. > There are no tabs in the patch. >> >> It would be good if you could email a patch to yourself and then >> see if you can apply cleanly it to your source tree (after removing >> any conflicting patches, of course -- or use a different source >> tree). > > Yeah, I'll make sure to double check with that in the future. > >> >> >> -- >> ~Randy >> Reported-by: Randy Dunlap >> netiquette: https://people.kernel.org/tglx/notes-about-netiquette > > Should I send in a v2 of this patchset, or just attach the patch here? > If I should just attach it here, then I'll do the same for patch 2/2. An attachment might be OK once but it would be better if you could get inline patches to work. You'll need to do that... -- ~Randy
Re: [PATCH net-next] cxgb4: remove redundant NULL check
On Tuesday, January 01/26/21, 2021 at 10:50:13 +0800, Yang Li wrote:
> Fix below warnings reported by coccicheck:
> ./drivers/net/ethernet/chelsio/cxgb4/clip_tbl.c:323:3-9: WARNING:
> NULL check before some freeing functions is not needed.
> ./drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c:3554:2-8: WARNING:
> NULL check before some freeing functions is not needed.
> ./drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c:157:2-7: WARNING:
> NULL check before some freeing functions is not needed.
> ./drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c:525:3-9: WARNING:
> NULL check before some freeing functions is not needed.
>
> Reported-by: Abaci Robot
> Signed-off-by: Yang Li
> ---
> drivers/net/ethernet/chelsio/cxgb4/clip_tbl.c | 3 +--
> drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c| 3 +--
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c | 3 +--
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c | 6 ++
> 4 files changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/clip_tbl.c
> b/drivers/net/ethernet/chelsio/cxgb4/clip_tbl.c
> index ce28820..12fcf84 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/clip_tbl.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/clip_tbl.c
> @@ -323,8 +323,7 @@ void t4_cleanup_clip_tbl(struct adapter *adap)
> struct clip_tbl *ctbl = adap->clipt;
>
> if (ctbl) {
> - if (ctbl->cl_list)
> - kvfree(ctbl->cl_list);
> + kvfree(ctbl->cl_list);
> kvfree(ctbl);
> }
> }
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c
> b/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c
> index 75474f8..94eb8a6 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c
> @@ -3554,8 +3554,7 @@ int cudbg_collect_qdesc(struct cudbg_init *pdbg_init,
> }
>
> out_free:
> - if (data)
> - kvfree(data);
> + kvfree(data);
>
> #undef QDESC_GET_FLQ
> #undef QDESC_GET_RXQ
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c
> b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c
> index 77648e4..dd66b24 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_cudbg.c
> @@ -157,8 +157,7 @@ static int cudbg_alloc_compress_buff(struct cudbg_init
> *pdbg_init)
>
> static void cudbg_free_compress_buff(struct cudbg_init *pdbg_init)
> {
> - if (pdbg_init->compress_buff)
NAK. The above check is necessary.
pdbg_init->compress_buff may be NULL when Zlib is unavailable or when
pdbg_init->compress_buff allocation fails, in which case we ignore error
and continue without compression. Check is necessary before calling
vfree().
> - vfree(pdbg_init->compress_buff);
> + vfree(pdbg_init->compress_buff);
> }
>
> int cxgb4_cudbg_collect(struct adapter *adap, void *buf, u32 *buf_size,
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c
> b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c
> index dede025..97a811f 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_u32.c
> @@ -525,12 +525,10 @@ struct cxgb4_tc_u32_table *cxgb4_init_tc_u32(struct
> adapter *adap)
> for (i = 0; i < t->size; i++) {
> struct cxgb4_link *link = >table[i];
>
> - if (link->tid_map)
> - kvfree(link->tid_map);
> + kvfree(link->tid_map);
The above change is wrong. NAK.
If the call to link->tid_map = kvcalloc() above fails, it still
goes ahead and calls kvfree(link->tid_map) even for failed cases, which is
wrong. Check is necessary before calling kvfree().
> }
>
> - if (t)
> - kvfree(t);
> + kvfree(t);
>
> return NULL;
> }
> --
> 1.8.3.1
>
[PATCH] bpf: Check for integer overflow when using roundup_pow_of_two()
On 32-bit architecture, roundup_pow_of_two() can return 0 when the argument
has upper most bit set due to resulting 1UL << 32. Add a check for this
case.
Fixes: d5a3b1f ("bpf: introduce BPF_MAP_TYPE_STACK_TRACE")
Signed-off-by: Bui Quang Minh
---
kernel/bpf/stackmap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
index aea96b638473..bfafbf115bf3 100644
--- a/kernel/bpf/stackmap.c
+++ b/kernel/bpf/stackmap.c
@@ -115,6 +115,8 @@ static struct bpf_map *stack_map_alloc(union bpf_attr *attr)
/* hash table size must be power of 2 */
n_buckets = roundup_pow_of_two(attr->max_entries);
+ if (!n_buckets)
+ return ERR_PTR(-E2BIG);
cost = n_buckets * sizeof(struct stack_map_bucket *) + sizeof(*smap);
cost += n_buckets * (value_size + sizeof(struct stack_map_bucket));
--
2.17.1
Re: [PATCH v5] fbtft: add tearing signal detect
On Wed, Jan 27, 2021 at 09:32:20AM +0800, Carlis wrote:
> @@ -82,6 +111,29 @@ enum st7789v_command {
> */
> static int init_display(struct fbtft_par *par)
> {
> + int rc;
> + struct device *dev = par->info->device;
> +
> + par->gpio.te = devm_gpiod_get_index_optional(dev, "te", 0, GPIOD_IN);
> + if (par->gpio.te) {
> + init_completion(_panel_te);
> + mutex_init(_mutex);
> + rc = devm_request_irq(dev,
> + gpiod_to_irq(par->gpio.te),
> + spi_panel_te_handler, IRQF_TRIGGER_RISING,
> + "TE_GPIO", par);
> + if (rc) {
> + pr_err("TE request_irq failed.\n");
> + devm_gpiod_put(dev, par->gpio.te);
> + par->gpio.te = NULL;
> + } else {
> + disable_irq_nosync(gpiod_to_irq(par->gpio.te));
> + pr_info("TE request_irq completion.\n");
This printk adds no value.
Don't print anything on the success path. You should add that to your
code while your debugging the feature, but don't push it to the upstream
kernel.
> + }
> + } else {
> + pr_info("%s:%d, TE gpio not specified\n",
> + __func__, __LINE__);
> + }
regards,
dan carpenter
[PATCH v2] iommu/vt-d: do not use flush-queue when caching-mode is on
From: Nadav Amit
When an Intel IOMMU is virtualized, and a physical device is
passed-through to the VM, changes of the virtual IOMMU need to be
propagated to the physical IOMMU. The hypervisor therefore needs to
monitor PTE mappings in the IOMMU page-tables. Intel specifications
provide "caching-mode" capability that a virtual IOMMU uses to report
that the IOMMU is virtualized and a TLB flush is needed after mapping to
allow the hypervisor to propagate virtual IOMMU mappings to the physical
IOMMU. To the best of my knowledge no real physical IOMMU reports
"caching-mode" as turned on.
Synchronizing the virtual and the physical IOMMU tables is expensive if
the hypervisor is unaware which PTEs have changed, as the hypervisor is
required to walk all the virtualized tables and look for changes.
Consequently, domain flushes are much more expensive than page-specific
flushes on virtualized IOMMUs with passthrough devices. The kernel
therefore exploited the "caching-mode" indication to avoid domain
flushing and use page-specific flushing in virtualized environments. See
commit 78d5f0f500e6 ("intel-iommu: Avoid global flushes with caching
mode.")
This behavior changed after commit 13cf01744608 ("iommu/vt-d: Make use
of iova deferred flushing"). Now, when batched TLB flushing is used (the
default), full TLB domain flushes are performed frequently, requiring
the hypervisor to perform expensive synchronization between the virtual
TLB and the physical one.
Getting batched TLB flushes to use in such circumstances page-specific
invalidations again is not easy, since the TLB invalidation scheme
assumes that "full" domain TLB flushes are performed for scalability.
Disable batched TLB flushes when caching-mode is on, as the performance
benefit from using batched TLB invalidations is likely to be much
smaller than the overhead of the virtual-to-physical IOMMU page-tables
synchronization.
Fixes: 78d5f0f500e6 ("intel-iommu: Avoid global flushes with caching mode.")
Signed-off-by: Nadav Amit
Cc: David Woodhouse
Cc: Lu Baolu
Cc: Joerg Roedel
Cc: Will Deacon
Cc: sta...@vger.kernel.org
---
v1->v2:
* disable flush queue for all domains if caching-mode is on for any
IOMMU (Lu).
---
drivers/iommu/intel/iommu.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 788119c5b021..de3dd617cf60 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -5373,6 +5373,36 @@ intel_iommu_domain_set_attr(struct iommu_domain *domain,
return ret;
}
+static bool domain_use_flush_queue(void)
+{
+ struct dmar_drhd_unit *drhd;
+ struct intel_iommu *iommu;
+ bool r = true;
+
+ if (intel_iommu_strict)
+ return false;
+
+ /*
+* The flush queue implementation does not perform page-selective
+* invalidations that are required for efficient TLB flushes in virtual
+* environments. The benefit of batching is likely to be much lower than
+* the overhead of synchronizing the virtual and physical IOMMU
+* page-tables.
+*/
+ rcu_read_lock();
+ for_each_active_iommu(iommu, drhd) {
+ if (!cap_caching_mode(iommu->cap))
+ continue;
+
+ pr_warn_once("IOMMU batching is disabled due to
virtualization");
+ r = false;
+ break;
+ }
+ rcu_read_unlock();
+
+ return r;
+}
+
static int
intel_iommu_domain_get_attr(struct iommu_domain *domain,
enum iommu_attr attr, void *data)
@@ -5383,7 +5413,7 @@ intel_iommu_domain_get_attr(struct iommu_domain *domain,
case IOMMU_DOMAIN_DMA:
switch (attr) {
case DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE:
- *(int *)data = !intel_iommu_strict;
+ *(int *)data = domain_use_flush_queue();
return 0;
default:
return -ENODEV;
--
2.25.1
RE: [PATCH] PCI: dwc: Move forward the iATU detection process
Hi,
Yes, they are fix the same issue.
Rob and other contributors sent so many patches to refine the drivers and make
the code brief and more readable, so I don't think we should just focus on the
fixes of this issue. I don't think it is a good choice that your patch move
some of the software perspective initializations into hardware ones.
Thanks
Zhiqiang
> -Original Message-
> From: Kunihiko Hayashi
> Sent: 2021年1月26日 13:26
> To: Z.q. Hou
> Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
> lorenzo.pieral...@arm.com; r...@kernel.org; bhelg...@google.com;
> gustavo.pimen...@synopsys.com; jingooh...@gmail.com;
> jaswinder.si...@linaro.org; masami.hirama...@linaro.org
> Subject: Re: [PATCH] PCI: dwc: Move forward the iATU detection process
>
> Hi,
>
> This looks to me the same fix as my posted patch[1].
> Is this more effective than mine?
>
> Thank you,
>
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .spinics.net%2Flists%2Flinux-pci%2Fmsg103889.htmldata=04%7C01%
> 7CZhiqiang.Hou%40nxp.com%7Cd9fa58aac4774c9dd61b08d8c1bad128%7C
> 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637472355412202563
> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Mt3B4jQ1Q1fu%2
> FAz9s4Y4eieHv7nYorvvT2pKlqFLE9k%3Dreserved=0
>
> On 2021/01/25 13:48, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang
> >
> > In the dw_pcie_ep_init(), it depends on the detected iATU region
> > numbers to allocate the in/outbound window management bit map.
> > It fails after the commit 281f1f99cf3a ("PCI: dwc: Detect number of
> > iATU windows").
> >
> > So this patch move the iATU region detection into a new function, move
> > forward the detection to the very beginning of functions
> > dw_pcie_host_init() and dw_pcie_ep_init(). And also remove it from the
> > dw_pcie_setup(), since it's more like a software perspective
> > initialization step than hardware setup.
> >
> > Fixes: 281f1f99cf3a ("PCI: dwc: Detect number of iATU windows")
> > Signed-off-by: Hou Zhiqiang
> > ---
> > drivers/pci/controller/dwc/pcie-designware-ep.c | 2 ++
> > drivers/pci/controller/dwc/pcie-designware-host.c | 2 ++
> > drivers/pci/controller/dwc/pcie-designware.c | 11 ---
> > drivers/pci/controller/dwc/pcie-designware.h | 1 +
> > 4 files changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > index bcd1cd9ba8c8..fcf935bf6f5e 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > @@ -707,6 +707,8 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> > }
> > }
> >
> > + dw_pcie_iatu_detect(pci);
> > +
> > res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> "addr_space");
> > if (!res)
> > return -EINVAL;
> > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
> > b/drivers/pci/controller/dwc/pcie-designware-host.c
> > index 8a84c005f32b..8eae817c138d 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> > @@ -316,6 +316,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
> > return PTR_ERR(pci->dbi_base);
> > }
> >
> > + dw_pcie_iatu_detect(pci);
> > +
> > bridge = devm_pci_alloc_host_bridge(dev, 0);
> > if (!bridge)
> > return -ENOMEM;
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > b/drivers/pci/controller/dwc/pcie-designware.c
> > index 5b72a5448d2e..5b9bf02d918b 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > @@ -654,11 +654,9 @@ static void dw_pcie_iatu_detect_regions(struct
> dw_pcie *pci)
> > pci->num_ob_windows = ob;
> > }
> >
> > -void dw_pcie_setup(struct dw_pcie *pci)
> > +void dw_pcie_iatu_detect(struct dw_pcie *pci)
> > {
> > - u32 val;
> > struct device *dev = pci->dev;
> > - struct device_node *np = dev->of_node;
> > struct platform_device *pdev = to_platform_device(dev);
> >
> > if (pci->version >= 0x480A || (!pci->version && @@ -687,6 +685,13
> > @@ void dw_pcie_setup(struct dw_pcie *pci)
> >
> > dev_info(pci->dev, "Detected iATU regions: %u outbound, %u
> inbound",
> > pci->num_ob_windows, pci->num_ib_windows);
> > +}
> > +
> > +void dw_pcie_setup(struct dw_pcie *pci) {
> > + u32 val;
> > + struct device *dev = pci->dev;
> > + struct device_node *np = dev->of_node;
> >
> > if (pci->link_gen > 0)
> > dw_pcie_link_set_max_speed(pci, pci->link_gen); diff --git
> > a/drivers/pci/controller/dwc/pcie-designware.h
> > b/drivers/pci/controller/dwc/pcie-designware.h
> > index 5d979953800d..867369d4c4f7 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> >
Re: [PATCH v5] fbtft: add tearing signal detect
On Wed, 27 Jan 2021 08:45:23 +0300
Dan Carpenter wrote:
> On Wed, Jan 27, 2021 at 09:32:20AM +0800, Carlis wrote:
> > @@ -82,6 +111,29 @@ enum st7789v_command {
> > */
> > static int init_display(struct fbtft_par *par)
> > {
> > + int rc;
> > + struct device *dev = par->info->device;
> > +
> > + par->gpio.te = devm_gpiod_get_index_optional(dev, "te", 0,
> > GPIOD_IN);
> > + if (par->gpio.te) {
> > + init_completion(_panel_te);
> > + mutex_init(_mutex);
> > + rc = devm_request_irq(dev,
> > + gpiod_to_irq(par->gpio.te),
> > +spi_panel_te_handler,
> > IRQF_TRIGGER_RISING,
> > +"TE_GPIO", par);
> > + if (rc) {
> > + pr_err("TE request_irq failed.\n");
> > + devm_gpiod_put(dev, par->gpio.te);
> > + par->gpio.te = NULL;
> > + } else {
> > +
> > disable_irq_nosync(gpiod_to_irq(par->gpio.te));
> > + pr_info("TE request_irq completion.\n");
> > + }
> > + } else {
> > + pr_info("%s:%d, TE gpio not specified\n",
> > + __func__, __LINE__);
> > + }
>
> I'm sorry that I was not clear before. This code will crash if
> devm_gpiod_get_index_optional() returns an error. You *NEED* to check
> for error pointers and return the error code. Write it exactly like
> this:
>
> par->gpio.te = devm_gpiod_get_index_optional(dev, "te", 0,
> GPIOD_IN); if (IS_ERR(par->gpio.te))
> return PTR_ERR(par->gpio.te);
>
> if (par->gpio.te) {
> init_completion(_panel_te);
>
>
> regards,
> dan carpenter
>
hi,i will fix it like below:
par->gpio.te = devm_gpiod_get_index_optional(dev, "te", 0,
GPIOD_IN); if (IS_ERR(par->gpio.te)) {
rc = PTR_ERR(par->gpio.te);
pr_err("Failed to request te gpio: %d\n", rc);
par->gpio.te = NULL;
}
if (par->gpio.te) {
init_completion(_panel_te);
mutex_init(_mutex);
rc = devm_request_irq(dev,
gpiod_to_irq(par->gpio.te),
spi_panel_te_handler,
IRQF_TRIGGER_RISING, "TE_GPIO", par);
if (rc) {
pr_err("TE request_irq failed.\n");
devm_gpiod_put(dev, par->gpio.te);
par->gpio.te = NULL;
} else {
disable_irq_nosync(gpiod_to_irq(par->gpio.te));
pr_info("TE request_irq completion.\n");
}
} else {
pr_info("%s:%d, TE gpio not specified\n",
__func__, __LINE__);
}
regards,
zhangxuezhi
[PATCH 19/20] dyndbg: try conditional linker expression in KEEP - RFC
This is the last patch in v3 of patchest Ive sent previously:
v2: https://lore.kernel.org/lkml/?q=Cromie+v2+00%2F19+2020-12-25+-Re
It isolates my only issue now, Id appreciate advice, and dont want to
distract you with the 18 previous commits.
Im trying to use ? : inside a KEEP(*(expression)) to only include
A_header when A has content.
IE:
KEEP(*( A ? A_header : ))
It fails with inscrutable linker error.
GEN modules.builtin
LD .tmp_vmlinux.kallsyms1
ld:./arch/x86/kernel/vmlinux.lds:46: syntax error
Is this possible by other modes of expression ?
I tried inserting {} 1st, that failed, appearing to foreclose any
foreach-like construct. I also tried () around each term, and a
preceding, embedded "_loc=.;" statement to test the parser.
I didnt try doing this with 2 separate KEEPs; while it would be
simple, it defeats the adjacency guaranteed by *(.text .rdata), which
is the point of this.
If this were to be possible, it opens up interesting options to
statically construct table headers, and possibly even tree structures
in the linker script. Id use it to add 1 header for each module, and
strip a column out of the table.
Ive pulled binutils to take a look at the source; having never done
anything bison-ish, I anticipate a long study without some focused
primer knowledge.
Signed-off-by: Jim Cromie
---
include/asm-generic/vmlinux.lds.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index 87868c5a980a..6198cc850f9b 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -329,10 +329,10 @@
#define DYNAMIC_DEBUG_DATA() \
. = ALIGN(8); \
__start___dyndbg_sites = .; \
- KEEP(*(__dyndbg_sites .gnu.linkonce.*.dyndbg_site))
\
+ KEEP(*(__dyndbg_sites ? .gnu.linkonce.*.dyndbg_site : ))\
__stop___dyndbg_sites = .; \
__start___dyndbg = .; \
- KEEP(*(__dyndbg .gnu.linkonce.*.dyndbg))
\
+ KEEP(*(__dyndbg ? .gnu.linkonce.*.dyndbg : )) \
__stop___dyndbg = .;
#else
#define DYNAMIC_DEBUG_DATA()
--
2.29.2
[PATCH v3] net/bluetooth/hci_debugfs.c: fix coccicheck warnings
Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE
for debugfs files.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Zhong
---
Changes in v2:
-Modifying row alignment.
net/bluetooth/hci_debugfs.c | 80 ++---
1 file changed, 40 insertions(+), 40 deletions(-)
diff --git a/net/bluetooth/hci_debugfs.c b/net/bluetooth/hci_debugfs.c
index 4626e02..1a0ab58 100644
--- a/net/bluetooth/hci_debugfs.c
+++ b/net/bluetooth/hci_debugfs.c
@@ -237,8 +237,8 @@ static int conn_info_min_age_get(void *data, u64 *val)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(conn_info_min_age_fops, conn_info_min_age_get,
- conn_info_min_age_set, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(conn_info_min_age_fops, conn_info_min_age_get,
+ conn_info_min_age_set, "%llu\n");
static int conn_info_max_age_set(void *data, u64 val)
{
@@ -265,8 +265,8 @@ static int conn_info_max_age_get(void *data, u64 *val)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(conn_info_max_age_fops, conn_info_max_age_get,
- conn_info_max_age_set, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(conn_info_max_age_fops, conn_info_max_age_get,
+ conn_info_max_age_set, "%llu\n");
static ssize_t use_debug_keys_read(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
@@ -419,8 +419,8 @@ static int voice_setting_get(void *data, u64 *val)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(voice_setting_fops, voice_setting_get,
- NULL, "0x%4.4llx\n");
+DEFINE_DEBUGFS_ATTRIBUTE(voice_setting_fops, voice_setting_get,
+ NULL, "0x%4.4llx\n");
static ssize_t ssp_debug_mode_read(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
@@ -476,9 +476,9 @@ static int min_encrypt_key_size_get(void *data, u64 *val)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(min_encrypt_key_size_fops,
- min_encrypt_key_size_get,
- min_encrypt_key_size_set, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(min_encrypt_key_size_fops,
+ min_encrypt_key_size_get,
+ min_encrypt_key_size_set, "%llu\n");
static int auto_accept_delay_get(void *data, u64 *val)
{
@@ -491,8 +491,8 @@ static int auto_accept_delay_get(void *data, u64 *val)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(auto_accept_delay_fops, auto_accept_delay_get,
- auto_accept_delay_set, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(auto_accept_delay_fops, auto_accept_delay_get,
+ auto_accept_delay_set, "%llu\n");
static ssize_t force_bredr_smp_read(struct file *file,
char __user *user_buf,
@@ -558,8 +558,8 @@ static int idle_timeout_get(void *data, u64 *val)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(idle_timeout_fops, idle_timeout_get,
- idle_timeout_set, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(idle_timeout_fops, idle_timeout_get,
+ idle_timeout_set, "%llu\n");
static int sniff_min_interval_set(void *data, u64 val)
{
@@ -586,8 +586,8 @@ static int sniff_min_interval_get(void *data, u64 *val)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(sniff_min_interval_fops, sniff_min_interval_get,
- sniff_min_interval_set, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(sniff_min_interval_fops, sniff_min_interval_get,
+ sniff_min_interval_set, "%llu\n");
static int sniff_max_interval_set(void *data, u64 val)
{
@@ -614,8 +614,8 @@ static int sniff_max_interval_get(void *data, u64 *val)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(sniff_max_interval_fops, sniff_max_interval_get,
- sniff_max_interval_set, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(sniff_max_interval_fops, sniff_max_interval_get,
+ sniff_max_interval_set, "%llu\n");
void hci_debugfs_create_bredr(struct hci_dev *hdev)
{
@@ -706,8 +706,8 @@ static int rpa_timeout_get(void *data, u64 *val)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(rpa_timeout_fops, rpa_timeout_get,
- rpa_timeout_set, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(rpa_timeout_fops, rpa_timeout_get,
+ rpa_timeout_set, "%llu\n");
static int random_address_show(struct seq_file *f, void *p)
{
@@ -869,8 +869,8 @@ static int conn_min_interval_get(void *data, u64 *val)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(conn_min_interval_fops, conn_min_interval_get,
- conn_min_interval_set, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(conn_min_interval_fops, conn_min_interval_get,
+ conn_min_interval_set, "%llu\n");
static int conn_max_interval_set(void *data, u64 val)
{
@@ -897,8 +897,8 @@ static int conn_max_interval_get(void *data, u64 *val)
return 0;
}
Re: [PATCH 4/8] lib: bitmap: move ERANGE check from set_region to check_region
On Tue, Jan 26, 2021 at 9:12 AM Paul Gortmaker
wrote:
>
> It makes sense to do all the checks in check_region() and not 1/2
> in check_region and 1/2 in set_region.
>
> Since set_region is called immediately after check_region, the net
> effect on runtime is zero, but it gets rid of an if (...) return...
>
> Cc: Yury Norov
> Cc: Rasmus Villemoes
> Cc: Andy Shevchenko
> Signed-off-by: Paul Gortmaker
> ---
> lib/bitmap.c | 14 +-
> 1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/lib/bitmap.c b/lib/bitmap.c
> index 162e2850c622..833f152a2c43 100644
> --- a/lib/bitmap.c
> +++ b/lib/bitmap.c
> @@ -500,17 +500,12 @@ struct region {
> unsigned int nbits;
> };
>
> -static int bitmap_set_region(const struct region *r, unsigned long *bitmap)
> +static void bitmap_set_region(const struct region *r, unsigned long *bitmap)
> {
> unsigned int start;
>
> - if (r->end >= r->nbits)
> - return -ERANGE;
> -
> for (start = r->start; start <= r->end; start += r->group_len)
> bitmap_set(bitmap, start, min(r->end - start + 1, r->off));
> -
> - return 0;
> }
>
> static int bitmap_check_region(const struct region *r)
> @@ -518,6 +513,9 @@ static int bitmap_check_region(const struct region *r)
> if (r->start > r->end || r->group_len == 0 || r->off > r->group_len)
> return -EINVAL;
>
> + if (r->end >= r->nbits)
> + return -ERANGE;
> +
> return 0;
> }
>
> @@ -656,9 +654,7 @@ int bitmap_parselist(const char *buf, unsigned long
> *maskp, int nmaskbits)
> if (ret)
> return ret;
>
> - ret = bitmap_set_region(, maskp);
> - if (ret)
> - return ret;
> + bitmap_set_region(, maskp);
> }
>
> return 0;
> --
> 2.17.1
Acked-by: Yury Norov
Re: [PATCH v1] scsi: lpfc: Add auto select on IRQ_POLL
Tong, > lpfc depends on irq_poll library, but it is not selected > automatically. When irq_poll is not selected, compiling it can run > into following error Applied to 5.12/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering
[PATCH V2] bcache: dont reset bio opf in bch_data_insert_start
commit ad0d9e76(bcache: use bio op accessors) makes the bi_opf
modified by bio_set_op_attrs(). But there is a logical
problem in this commit:
trace_bcache_cache_insert(k);
bch_keylist_push(>insert_keys);
- n->bi_rw |= REQ_WRITE;
+ bio_set_op_attrs(n, REQ_OP_WRITE, 0);
bch_submit_bbio(n, op->c, k, 0);
} while (n != bio);
The old code add REQ_WRITE into bio n and keep other flags; the
new code set REQ_OP_WRITE to bi_opf, but reset all other flags.
This problem is discoverd in our performance testing:
(1) start a fio with 1M x 128depth for read in /dev/nvme0n1p1
(2) start a fio with 1M x 128depth for write in /dev/escache0 (cache
device is /dev/nvme0n1p2)
We found the BW of reading is 2000+M/s, but the BW of writing is
0-100M/s. After some debugging, we found the problem is io submit in
writting is very slow.
bch_data_insert_start() insert a bio to /dev/nvme0n1p1, but as
cached_dev submit stack bio will be added into current->bio_list, and
return.Then __submit_bio_noacct() will submit the new bio in bio_list
into /dev/nvme0n1p1. This operation would be slow in
blk_mq_submit_bio() -> rq_qos_throttle(q, bio);
The rq_qos_throttle() will call wbt_should_throttle(),
static inline bool wbt_should_throttle(struct rq_wb *rwb, struct bio *bio)
{
switch (bio_op(bio)) {
case REQ_OP_WRITE:
/*
* Don't throttle WRITE_ODIRECT
*/
if ((bio->bi_opf & (REQ_SYNC | REQ_IDLE)) ==
(REQ_SYNC | REQ_IDLE))
return false;
... ...
}
As the bio_set_op_attrs() reset the (REQ_SYNC | REQ_IDLE), so this write
bio will be considered as non-direct write.
After this fix, bio to nvme will flaged as (REQ_SYNC | REQ_IDLE),
then fio for writing will get about 1000M/s bandwidth.
Fixes: ad0d9e76a412 ("bcache: use bio op accessors")
Close: EAS-60259
CC: Mike Christie
Signed-off-by: Dongsheng Yang
---
drivers/md/bcache/request.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c
index c7cadaafa947..eb734f7ddaac 100644
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@ -244,7 +244,7 @@ static void bch_data_insert_start(struct closure *cl)
trace_bcache_cache_insert(k);
bch_keylist_push(>insert_keys);
- bio_set_op_attrs(n, REQ_OP_WRITE, 0);
+ n->bi_opf |= REQ_OP_WRITE;
bch_submit_bbio(n, op->c, k, 0);
} while (n != bio);
--
2.25.1
Re: linux-next: manual merge of the pidfd tree with the xfs tree
On Wed, Jan 27, 2021 at 11:24:41AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 25 Jan 2021 17:14:14 +1100 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the pidfd tree got a conflict in:
> >
> > fs/xfs/xfs_inode.c
> >
> > between commit:
> >
> > 01ea173e103e ("xfs: fix up non-directory creation in SGID directories")
> >
> > from the xfs tree and commit:
> >
> > f736d93d76d3 ("xfs: support idmapped mounts")
> >
> > from the pidfd tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> >
> > diff --cc fs/xfs/xfs_inode.c
> > index e2a1db4cee43,95b7f2ba4e06..
> > --- a/fs/xfs/xfs_inode.c
> > +++ b/fs/xfs/xfs_inode.c
> > @@@ -809,13 -810,13 +810,13 @@@ xfs_init_new_inode
> > inode->i_rdev = rdev;
> > ip->i_d.di_projid = prid;
> >
> > - if (pip && XFS_INHERIT_GID(pip)) {
> > - inode->i_gid = VFS_I(pip)->i_gid;
> > - if ((VFS_I(pip)->i_mode & S_ISGID) && S_ISDIR(mode))
> > - inode->i_mode |= S_ISGID;
> > + if (dir && !(dir->i_mode & S_ISGID) &&
> > + (mp->m_flags & XFS_MOUNT_GRPID)) {
> > + inode->i_uid = current_fsuid();
>
> Looking a bit harder, I replaced the above line with
> inode->i_uid = fsuid_into_mnt(mnt_userns);
I think that looks good, though Mr. Brauner is probably better equipped
to tell if that change is correct.
(He says watching kernel.org mail take nearly a day to come through...)
--D
>
> > + inode->i_gid = dir->i_gid;
> > + inode->i_mode = mode;
> > } else {
> > - inode_init_owner(inode, dir, mode);
> > - inode->i_gid = fsgid_into_mnt(mnt_userns);
> > ++ inode_init_owner(mnt_userns, inode, dir, mode);
> > }
> >
> > /*
>
> --
> Cheers,
> Stephen Rothwell
Re: [PATCH] scsi: qla2xxx: fix some memory corruption
Dan, > This was supposed to be "data" instead of "". The current code > will corrupt the stack. Applied to 5.12/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v6] usb: xhci-mtk: fix unreleased bandwidth data
On Tue, 2021-01-26 at 16:27 +0200, Mathias Nyman wrote:
> On 26.1.2021 16.13, Greg Kroah-Hartman wrote:
> > On Wed, Jan 13, 2021 at 06:05:11PM +0800, Ikjoon Jang wrote:
> >> xhci-mtk needs XHCI_MTK_HOST quirk functions in add_endpoint() and
> >> drop_endpoint() to handle its own sw bandwidth management.
> >>
> >> It stores bandwidth data into an internal table every time
> >> add_endpoint() is called, and drops those in drop_endpoint().
> >> But when bandwidth allocation fails at one endpoint, all earlier
> >> allocation from the same interface could still remain at the table.
> >>
> >> This patch moves bandwidth management codes to check_bandwidth() and
> >> reset_bandwidth() path. To do so, this patch also adds those functions
> >> to xhci_driver_overrides and lets mtk-xhci to release all failed
> >> endpoints in reset_bandwidth() path.
> >>
> >> Fixes: 08e469de87a2 ("usb: xhci-mtk: supports bandwidth scheduling with
> >> multi-TT")
> >> Signed-off-by: Ikjoon Jang
> >
> > Mathias, any objection to me taking this patch, or do you have others
> > being queued up for 5.11-final?
> >
>
> No objections, haven't tried it out but it looks good to me.
>
> If I finish some additional small fix for 5.11-final I can make it on top of
> this
Please give me some time to test this patch, thank you
>
> -Mathias
[PATCH] scripts/spelling.txt: increase error-prone spell checking
From: zuoqilin Increase exeeds spelling error check. Signed-off-by: zuoqilin --- scripts/spelling.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/scripts/spelling.txt b/scripts/spelling.txt index 953f4a2..740aba3 100644 --- a/scripts/spelling.txt +++ b/scripts/spelling.txt @@ -566,6 +566,7 @@ estbalishment||establishment etsablishment||establishment etsbalishment||establishment evalution||evaluation +exeeds||exceeds excecutable||executable exceded||exceeded exceds||exceeds -- 1.9.1
[PATCH v2 1/3] x509: Detect sm2 keys by their parameters OID
From: Stefan Berger
Detect whether a key is an sm2 type of key by its OID in the parameters
array rather than assuming that everything under OID_id_ecPublicKey
is sm2, which is not the case.
Signed-off-by: Stefan Berger
---
crypto/asymmetric_keys/x509_cert_parser.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/crypto/asymmetric_keys/x509_cert_parser.c
b/crypto/asymmetric_keys/x509_cert_parser.c
index 52c9b455fc7d..4643fe5ed69a 100644
--- a/crypto/asymmetric_keys/x509_cert_parser.c
+++ b/crypto/asymmetric_keys/x509_cert_parser.c
@@ -459,6 +459,7 @@ int x509_extract_key_data(void *context, size_t hdrlen,
const void *value, size_t vlen)
{
struct x509_parse_context *ctx = context;
+ enum OID oid;
ctx->key_algo = ctx->last_oid;
switch (ctx->last_oid) {
@@ -470,7 +471,17 @@ int x509_extract_key_data(void *context, size_t hdrlen,
ctx->cert->pub->pkey_algo = "ecrdsa";
break;
case OID_id_ecPublicKey:
- ctx->cert->pub->pkey_algo = "sm2";
+ if (ctx->params_size < 2)
+ return -ENOPKG;
+
+ oid = look_up_OID(ctx->params + 2, ctx->params_size - 2);
+ switch (oid) {
+ case OID_sm2:
+ ctx->cert->pub->pkey_algo = "sm2";
+ break;
+ default:
+ return -ENOPKG;
+ }
break;
default:
return -ENOPKG;
--
2.25.4
Re: [RESEND v13 03/10] KVM: x86/pmu: Use IA32_PERF_CAPABILITIES to adjust features visibility
On 2021/1/26 17:42, Paolo Bonzini wrote:
On 08/01/21 02:36, Like Xu wrote:
@@ -401,6 +398,9 @@ static void intel_pmu_init(struct kvm_vcpu *vcpu)
pmu->fixed_counters[i].idx = i + INTEL_PMC_IDX_FIXED;
pmu->fixed_counters[i].current_config = 0;
}
+
+ vcpu->arch.perf_capabilities = guest_cpuid_has(vcpu,
X86_FEATURE_PDCM) ?
+ vmx_get_perf_capabilities() : 0;
There is one thing I don't understand with this patch: intel_pmu_init is
not called when CPUID is changed. So I would have thought that anything
that uses guest_cpuid_has must stay in intel_pmu_refresh. As I understand
it vcpu->arch.perf_capabilities is always set to 0
(vmx_get_perf_capabilities is never called), and kvm_set_msr_common would
fail to set any bit in the MSR. What am I missing?
In addition, the code of patch 4:
+ if (!intel_pmu_lbr_is_enabled(vcpu)) {
+ vcpu->arch.perf_capabilities &= ~PMU_CAP_LBR_FMT;
+ lbr_desc->records.nr = 0;
+ }
is not okay after MSR changes. The value written by the host must be
either rejected (with "return 1") or applied unchanged.
Fortunately I think this code is dead if you move the check in kvm_set_msr
from patch 9 to patch 4. However, in patch 9 vmx_get_perf_capabilities()
must only set the LBR format bits if intel_pmu_lbr_is_compatible(vcpu).
Thanks for the guidance. How about handling it in this way:
In the intel_pmu_init():
vcpu->arch.perf_capabilities = 0;
lbr_desc->records.nr = 0;
In the intel_pmu_refresh():
if (guest_cpuid_has(vcpu, X86_FEATURE_PDCM)) {
vcpu->arch.perf_capabilities = vmx_get_perf_capabilities();
if (!lbr_desc->records.nr)
vcpu->arch.perf_capabilities &= ~PMU_CAP_LBR_FMT;
}
In the vmx_set_msr():
case MSR_IA32_PERF_CAPABILITIES:
// set up lbr_desc->records.nr
if (!intel_pmu_lbr_is_compatible(vcpu))
return 1;
ret = kvm_set_msr_common(vcpu, msr_info);
In the kvm_set_msr_common():
case MSR_IA32_PERF_CAPABILITIES:
vcpu->arch.perf_capabilities = data;
kvm_pmu_refresh(vcpu);
The patches look good apart from these issues and the other nits I pointed
out. However, you need testcases here, for both kvm-unit-tests and
tools/testing/selftests/kvm.
For KVM, it would be at least a basic check that looks for the MSR LBR
(using the MSR indices for the various processors), does a branch, and
checks that the FROM_IP/TO_IP are good. You can write the kvm-unit-tests
using the QEMU option "-cpu host,migratable=no": if you do this, QEMU will
pick the KVM_GET_SUPPORTED_CPUID bits and move them more or less directly
into the guest CPUID.
For tools/testing/selftests/kvm, your test need to check the effect of
various CPUID settings on the PERF_CAPABILITIES MSR, check that whatever
you write with KVM_SET_MSR is _not_ modified and can be retrieved with
KVM_GET_MSR, and check that invalid LBR formats are rejected.
Thanks, I will add the above tests in the next version.
I'm really, really sorry for leaving these patches on my todo list for
months, but you guys need to understand the main reason for this: they come
with no testcases. A large patch series adding userspace APIs and
complicated CPUID/MSR processing *automatically* goes to the bottom of my
queue, because:
- I need to go with a fine comb over all the userspace API changes, I
cannot just look at test code and see if it works.
- I will have no way to test its correctness after it's committed.
For you, the work ends when your patch is accepted. For me, that's when
the work begins, and I need to make sure that the patch will be
maintainable in the future.
Thanks, and sorry again for the delay.
Paolo
[PATCH] Revert "checkpatch: add check for keyword 'boolean' in Kconfig definitions"
This reverts commit 327953e9af6c59ad111b28359e59e3ec0cbd71b6.
You cannot use 'boolean' since commit b92d804a5179 ("kconfig: drop
'boolean' keyword").
This check is no longer needed.
Signed-off-by: Masahiro Yamada
---
scripts/checkpatch.pl | 7 ---
1 file changed, 7 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 92e888ed939f..1afe3af1cc09 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3390,13 +3390,6 @@ sub process {
}
}
-# discourage the use of boolean for type definition attributes of Kconfig
options
- if ($realfile =~ /Kconfig/ &&
- $line =~ /^\+\s*\bboolean\b/) {
- WARN("CONFIG_TYPE_BOOLEAN",
-"Use of boolean is deprecated, please use bool
instead.\n" . $herecurr);
- }
-
if (($realfile =~ /Makefile.*/ || $realfile =~ /Kbuild.*/) &&
($line =~ /\+(EXTRA_[A-Z]+FLAGS).*/)) {
my $flag = $1;
--
2.27.0
Re: [PATCH V6 5/6] of: unittest: Create overlay_common.dtsi and testcases_common.dtsi
On 22-01-21, 16:20, Viresh Kumar wrote:
> In order to build-test the same unit-test files using fdtoverlay tool,
> move the device nodes from the existing overlay_base.dts and
> testcases_common.dts files to .dtsi files. The .dts files now include
> the new .dtsi files, resulting in exactly the same behavior as earlier.
>
> The .dtsi files can now be reused for compile time tests using
> fdtoverlay (will be done in a later patch).
>
> This is required because the base files passed to fdtoverlay tool
> shouldn't be overlays themselves (i.e. shouldn't have the /plugin/;
> tag).
>
> Signed-off-by: Viresh Kumar
> ---
> drivers/of/unittest-data/overlay_base.dts | 90 +-
> drivers/of/unittest-data/overlay_common.dtsi | 91 +++
> drivers/of/unittest-data/testcases.dts| 17 +---
> .../of/unittest-data/testcases_common.dtsi| 18
> 4 files changed, 111 insertions(+), 105 deletions(-)
> create mode 100644 drivers/of/unittest-data/overlay_common.dtsi
> create mode 100644 drivers/of/unittest-data/testcases_common.dtsi
Frank,
As I mentioned in the cover-letter, I get a build warning right now:
drivers/of/unittest-data/tests-interrupts.dtsi:20.5-28: Warning
(interrupts_property): /testcase-data/testcase-device2:#interrupt-cells: size
is (4), expected multiple of 8
I think I need to add below diff to this patch to fix this warning, will that
be okay ?
diff --git a/drivers/of/unittest-data/testcases.dts
b/drivers/of/unittest-data/testcases.dts
index 185125085784..04b9e7bb30d9 100644
--- a/drivers/of/unittest-data/testcases.dts
+++ b/drivers/of/unittest-data/testcases.dts
@@ -3,3 +3,14 @@
/plugin/;
#include "testcases_common.dtsi"
+
+/ {
+ testcase-data {
+ testcase-device2 {
+ compatible = "testcase-device";
+ interrupt-parent = <_intc2>;
+ interrupts = <1>; /* invalid specifier - too short */
+ };
+ };
+
+};
diff --git a/drivers/of/unittest-data/tests-interrupts.dtsi
b/drivers/of/unittest-data/tests-interrupts.dtsi
index ec175e800725..0e5914611107 100644
--- a/drivers/of/unittest-data/tests-interrupts.dtsi
+++ b/drivers/of/unittest-data/tests-interrupts.dtsi
@@ -61,12 +61,5 @@ testcase-device1 {
interrupt-parent = <_intc0>;
interrupts = <1>;
};
-
- testcase-device2 {
- compatible = "testcase-device";
- interrupt-parent = <_intc2>;
- interrupts = <1>; /* invalid specifier - too short */
- };
};
-
};
--
viresh
