Re: [PATCH v33 12/12] LRNG - add power-on and runtime self-tests
Hi "Stephan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on char-misc/char-misc-testing]
[also build test ERROR on cryptodev/master crypto/master v5.9-rc1 next-20200821]
[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/Stephan-M-ller/dev-random-a-new-approach-with-full-SP800-90B-compliance/20200821-140523
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
d162219c655c8cf8003128a13840d6c1e183fb80
config: arm64-randconfig-s031-20200821 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-191-g10164920-dirty
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
aarch64-linux-ld: drivers/char/lrng/lrng_sw_noise.o: in function
`add_interrupt_randomness':
>> drivers/char/lrng/lrng_sw_noise.c:113: undefined reference to
>> `lrng_raw_irqflags_entropy_store'
drivers/char/lrng/lrng_sw_noise.c:113:(.text+0x280): relocation truncated to
fit: R_AARCH64_CALL26 against undefined symbol `lrng_raw_irqflags_entropy_store'
>> aarch64-linux-ld: drivers/char/lrng/lrng_sw_noise.c:115: undefined reference
>> to `lrng_raw_retip_entropy_store'
drivers/char/lrng/lrng_sw_noise.c:115:(.text+0x2b4): relocation truncated to
fit: R_AARCH64_CALL26 against undefined symbol `lrng_raw_retip_entropy_store'
aarch64-linux-ld: drivers/char/lrng/lrng_sw_noise.c:131: undefined reference
to `lrng_raw_retip_entropy_store'
drivers/char/lrng/lrng_sw_noise.c:131:(.text+0x368): relocation truncated to
fit: R_AARCH64_CALL26 against undefined symbol `lrng_raw_retip_entropy_store'
>> aarch64-linux-ld: drivers/char/lrng/lrng_sw_noise.c:146: undefined reference
>> to `lrng_raw_jiffies_entropy_store'
drivers/char/lrng/lrng_sw_noise.c:146:(.text+0x3d4): relocation truncated to
fit: R_AARCH64_CALL26 against undefined symbol `lrng_raw_jiffies_entropy_store'
>> aarch64-linux-ld: drivers/char/lrng/lrng_sw_noise.c:149: undefined reference
>> to `lrng_raw_irqflags_entropy_store'
drivers/char/lrng/lrng_sw_noise.c:149:(.text+0x3f0): relocation truncated to
fit: R_AARCH64_CALL26 against undefined symbol `lrng_raw_irqflags_entropy_store'
aarch64-linux-ld: drivers/char/lrng/lrng_sw_noise.c:152: undefined reference
to `lrng_raw_retip_entropy_store'
drivers/char/lrng/lrng_sw_noise.c:152:(.text+0x40c): relocation truncated to
fit: R_AARCH64_CALL26 against undefined symbol `lrng_raw_retip_entropy_store'
sparse warnings: (new ones prefixed by >>)
>> drivers/char/lrng/lrng_selftest.c:53:22: sparse: sparse: incorrect type in
>> assignment (different base types) @@ expected unsigned int [usertype] @@
>> got restricted __le32 [usertype] @@
>> drivers/char/lrng/lrng_selftest.c:53:22: sparse: expected unsigned int
>> [usertype]
>> drivers/char/lrng/lrng_selftest.c:53:22: sparse: got restricted __le32
>> [usertype]
>> drivers/char/lrng/lrng_selftest.c:53:22: sparse: sparse: incorrect type in
>> assignment (different base types) @@ expected unsigned int [usertype] @@
>> got restricted __le32 [usertype] @@
>> drivers/char/lrng/lrng_selftest.c:53:22: sparse: expected unsigned int
>> [usertype]
>> drivers/char/lrng/lrng_selftest.c:53:22: sparse: got restricted __le32
>> [usertype]
#
https://github.com/0day-ci/linux/commit/04c2864db01edca77a5a59da7b074dc191a30dd8
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Stephan-M-ller/dev-random-a-new-approach-with-full-SP800-90B-compliance/20200821-140523
git checkout 04c2864db01edca77a5a59da7b074dc191a30dd8
vim +53 drivers/char/lrng/lrng_selftest.c
46
47 static inline void lrng_selftest_bswap32(u32 *ptr, u32 words)
48 {
49 u32 i;
50
51 /* Byte-swap data which is an LE representation */
52 for (i = 0; i < words; i++) {
> 53 *ptr = cpu_to_le32(*ptr);
54 ptr++;
55 }
56 }
57
---
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 2/2] media: uvcvideo: Convey full ycbcr colorspace information to v4l2
Hi Adam,
(CC'ing Hans Verkuil)
On Sun, Aug 23, 2020 at 05:54:24PM +0300, Laurent Pinchart wrote:
> Hi Adam,
>
> Thank you for the patch.
>
> On Sat, Aug 22, 2020 at 09:21:34PM -0400, Adam Goode wrote:
> > The Color Matching Descriptor has been present in USB cameras since
> > the original version of UVC, but it has never been fully used
> > in Linux.
> >
> > This change informs V4L2 of all of the critical colorspace parameters:
> > colorspace (called "color primaries" in UVC), transfer function
> > (called "transfer characteristics" in UVC), ycbcr encoding (called
> > "matrix coefficients" in UVC), and quantization, which is always
> > LIMITED for UVC, see section 2.26 in USB_Video_FAQ_1.5.pdf.
>
> Isn't this valid for MJPEG only though ? There's not much else we can do
> though, as UVC cameras don't report quantization information. Shouldn't
> we however reflect this in the commit message, and in the comment below,
> to state that UVC requires limited quantization range for MJPEG, and
> while it doesn't explicitly specify the quantization range for other
> formats, we can only assume it should be limited as well ?
>
> The code otherwise looks good to me.
>
> Reviewed-by: Laurent Pinchart
>
> Please let me know if you'd like to address the above issue.
>
> > The quantization is the most important improvement for this patch,
> > because V4L2 will otherwise interpret MJPEG as FULL range. Web browsers
> > such as Chrome and Firefox already ignore V4L2's quantization for USB
> > devices and use the correct LIMITED value, but other programs such
> > as qv4l2 will incorrectly interpret the output of MJPEG from USB
> > cameras without this change.
> >
> > Signed-off-by: Adam Goode
> > ---
> > drivers/media/usb/uvc/uvc_driver.c | 52 +++---
> > drivers/media/usb/uvc/uvc_v4l2.c | 6
> > drivers/media/usb/uvc/uvcvideo.h | 5 ++-
> > 3 files changed, 58 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/media/usb/uvc/uvc_driver.c
> > b/drivers/media/usb/uvc/uvc_driver.c
> > index 431d86e1c94b..c0c81b089b7d 100644
> > --- a/drivers/media/usb/uvc/uvc_driver.c
> > +++ b/drivers/media/usb/uvc/uvc_driver.c
> > @@ -248,10 +248,10 @@ static struct uvc_format_desc
> > *uvc_format_by_guid(const u8 guid[16])
> > return NULL;
> > }
> >
> > -static u32 uvc_colorspace(const u8 primaries)
> > +static enum v4l2_colorspace uvc_colorspace(const u8 primaries)
> > {
> > - static const u8 colorprimaries[] = {
> > - 0,
> > + static const enum v4l2_colorspace colorprimaries[] = {
> > + V4L2_COLORSPACE_DEFAULT, /* Unspecified */
> > V4L2_COLORSPACE_SRGB,
> > V4L2_COLORSPACE_470_SYSTEM_M,
> > V4L2_COLORSPACE_470_SYSTEM_BG,
> > @@ -262,7 +262,43 @@ static u32 uvc_colorspace(const u8 primaries)
> > if (primaries < ARRAY_SIZE(colorprimaries))
> > return colorprimaries[primaries];
> >
> > - return 0;
> > + return V4L2_COLORSPACE_DEFAULT; /* Reserved */
> > +}
> > +
> > +static enum v4l2_xfer_func uvc_xfer_func(const u8 transfer_characteristics)
> > +{
> > + static const enum v4l2_xfer_func xfer_funcs[] = {
> > + V4L2_XFER_FUNC_DEFAULT, /* Unspecified */
> > + V4L2_XFER_FUNC_709,
> > + V4L2_XFER_FUNC_709, /* BT.470-2 M */
> > + V4L2_XFER_FUNC_709, /* BT.470-2 B, G */
> > + V4L2_XFER_FUNC_709, /* SMPTE 170M */
> > + V4L2_XFER_FUNC_SMPTE240M,
> > + V4L2_XFER_FUNC_NONE, /* Linear (V = Lc) */
> > + V4L2_XFER_FUNC_SRGB,
> > + };
> > +
> > + if (transfer_characteristics < ARRAY_SIZE(xfer_funcs))
> > + return xfer_funcs[transfer_characteristics];
> > +
> > + return V4L2_XFER_FUNC_DEFAULT; /* Reserved */
> > +}
> > +
> > +static enum v4l2_ycbcr_encoding uvc_ycbcr_enc(const u8 matrix_coefficients)
> > +{
> > + static const enum v4l2_ycbcr_encoding ycbcr_encs[] = {
> > + V4L2_YCBCR_ENC_DEFAULT, /* Unspecified */
> > + V4L2_YCBCR_ENC_709,
> > + V4L2_YCBCR_ENC_601, /* FCC */
I may have spoken a bit too fast. Doesn't FCC differ from BT.601 ?
According to https://en.wikipedia.org/wiki/Talk%3AYCbCr, the former uses
E'Y = 0.59 E'G + 0.11 E'B + 0.30 E'R
E'PB = – 0.331 E'G + 0.500 E'B – 0.169 E'R
E'PR = – 0.421 E'G – 0.079 E'B + 0.500 E'R
while the latter uses
E'Y = 0.587 E'G + 0.114 E'B + 0.299 E'R
E'PB = – 0.331 E'G + 0.500 E'B – 0.169 E'R
E'PR = – 0.419 E'G – 0.081 E'B + 0.500 E'R
We seems to be missing FCC in the V4L2 color space definitions.
> > + V4L2_YCBCR_ENC_601, /* BT.470-2 B, G */
> > + V4L2_YCBCR_ENC_601, /* SMPTE 170M */
> > + V4L2_YCBCR_ENC_SMPTE240M,
> > + };
> > +
> > + if (matrix_coefficients < ARRAY_SIZE(ycbcr_encs))
> > + return ycbcr_encs[matrix_coefficients];
> > +
> > + return V4L2_YCBCR_ENC_DEFAULT; /* Reserved */
> > }
> >
> > /* Simplify a fraction using a simple
Re: [PATCH] drm/brige/megachips: Add checking if ge_b850v3_lvds_init() is working correctly
Hi Nadezda
On Wed, Aug 19, 2020 at 05:37:56PM +0300, Nadezda Lutovinova wrote:
> If ge_b850v3_lvds_init() does not allocate memory for ge_b850v3_lvds_ptr,
> then a null pointer dereference is accessed.
>
> The patch adds checking of the return value of ge_b850v3_lvds_init().
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Nadezda Lutovinova
Thanks, applied to drm-misc-next, so it will hit upstream during the
next merge window.
Sam
> ---
> drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
> b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
> index 6200f12..ab81748 100644
> --- a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
> +++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
> @@ -302,8 +302,12 @@ static int stdp4028_ge_b850v3_fw_probe(struct i2c_client
> *stdp4028_i2c,
> const struct i2c_device_id *id)
> {
> struct device *dev = &stdp4028_i2c->dev;
> + int ret;
> +
> + ret = ge_b850v3_lvds_init(dev);
>
> - ge_b850v3_lvds_init(dev);
> + if (ret)
> + return ret;
>
> ge_b850v3_lvds_ptr->stdp4028_i2c = stdp4028_i2c;
> i2c_set_clientdata(stdp4028_i2c, ge_b850v3_lvds_ptr);
> @@ -361,8 +365,12 @@ static int stdp2690_ge_b850v3_fw_probe(struct i2c_client
> *stdp2690_i2c,
> const struct i2c_device_id *id)
> {
> struct device *dev = &stdp2690_i2c->dev;
> + int ret;
> +
> + ret = ge_b850v3_lvds_init(dev);
>
> - ge_b850v3_lvds_init(dev);
> + if (ret)
> + return ret;
>
> ge_b850v3_lvds_ptr->stdp2690_i2c = stdp2690_i2c;
> i2c_set_clientdata(stdp2690_i2c, ge_b850v3_lvds_ptr);
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] ntfs: add check for mft record size in superblock
number of bytes allocated for mft record should be equal to the mft
record size stored in ntfs superblock
as reported by syzbot, userspace might trigger out-of-bounds read by
dereferencing ctx->attr in ntfs_attr_find()
Reported-and-tested-by: syzbot+aed06913f36eff9b5...@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=aed06913f36eff9b544e
Signed-off-by: Rustam Kovhaev
---
fs/ntfs/inode.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/ntfs/inode.c b/fs/ntfs/inode.c
index 9bb9f0952b18..6407af7c2e4f 100644
--- a/fs/ntfs/inode.c
+++ b/fs/ntfs/inode.c
@@ -1810,6 +1810,12 @@ int ntfs_read_inode_mount(struct inode *vi)
brelse(bh);
}
+ if (m->bytes_allocated != vol->mft_record_size) {
+ ntfs_error(sb, "Incorrect mft record size [%u] in superblock,
should be [%u].",
+ m->bytes_allocated, vol->mft_record_size);
+ goto err_out;
+ }
+
/* Apply the mst fixups. */
if (post_read_mst_fixup((NTFS_RECORD*)m, vol->mft_record_size)) {
/* FIXME: Try to use the $MFTMirr now. */
--
2.28.0
Re: [PATCH] hugetlb_cgroup: convert comma to semicolon
On Wed, Aug 19, 2020 at 10:14:11AM +0200, Giuseppe Scrivano wrote: > >> - cft->file_offset = offsetof(struct hugetlb_cgroup, events_file[idx]), > >> + cft->file_offset = offsetof(struct hugetlb_cgroup, events_file[idx]); > >>cft->flags = CFTYPE_NOT_ON_ROOT; > > I think in this case having two expressions as part of the same > statement is equivalent to having two separate statements. Both > cft->file_offset and cft->flags get the expected value. That's not how the comma operator works. It will evaluate offsetof(struct hugetlb_cgroup, events_file[idx]) and then discard the result. Since it has no side-effects, this is effectively doing: cft->file_offset = cft->flags = CFTYPE_NOT_ON_ROOT;
Re: [PATCH V2 1/7] dt-bindings: PCI: qcom: Add ipq8074 Gen3 PCIe compatible
On 29-07-20, 21:00, Sivaprakash Murugesan wrote: > ipq8074 has two PCIe ports while the support for Gen2 PCIe port is > already available add the support for Gen3 binding. > > Co-developed-by: Selvam Sathappan Periakaruppan > Signed-off-by: Selvam Sathappan Periakaruppan > Reviewed-by: Rob Herring > Signed-off-by: Sivaprakash Murugesan > --- > .../devicetree/bindings/pci/qcom,pcie.yaml | 47 > ++ The issue is the yaml file is not in linux-phy next.. did we get the conversion done? > 1 file changed, 47 insertions(+) > > diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml > b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml > index 2eef6d5..e0559dd 100644 > --- a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml > +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml > @@ -23,6 +23,7 @@ properties: >- qcom,pcie-ipq8064 >- qcom,pcie-ipq8064-v2 >- qcom,pcie-ipq8074 > + - qcom,pcie-ipq8074-gen3 >- qcom,pcie-msm8996 >- qcom,pcie-qcs404 >- qcom,pcie-sdm845 > @@ -295,6 +296,52 @@ allOf: > compatible: > contains: > enum: > + - qcom,pcie-ipq8074-gen3 > + then: > + properties: > + clocks: > + items: > + - description: sys noc interface clock > + - description: AXI master clock > + - description: AXI secondary clock > + - description: AHB clock > + - description: Auxilary clock > + - description: AXI secondary bridge clock > + - description: PCIe rchng clock > + clock-names: > + items: > + - const: iface > + - const: axi_m > + - const: axi_s > + - const: ahb > + - const: aux > + - const: axi_bridge > + - const: rchng > + resets: > + items: > + - description: PIPE reset > + - description: PCIe sleep reset > + - description: PCIe sticky reset > + - description: AXI master reset > + - description: AXI secondary reset > + - description: AHB reset > + - description: AXI master sticky reset > + - description: AXI secondary sticky reset > + reset-names: > + items: > + - const: pipe > + - const: sleep > + - const: sticky > + - const: axi_m > + - const: axi_s > + - const: ahb > + - const: axi_m_sticky > + - const: axi_s_sticky > + - if: > + properties: > + compatible: > + contains: > + enum: > - qcom,pcie-msm8996 > then: > properties: > -- > 2.7.4 -- ~Vinod
Re: [PATCH V2 4/7] phy: qcom-qmp: Add compatible for ipq8074 PCIe Gen3 qmp phy
Hi Sivaprakash,
On 29-07-20, 21:00, Sivaprakash Murugesan wrote:
> ipq8074 has two PCIe ports, One Gen2 and one Gen3 ports.
> Since support for Gen2 phy is already available, add support for
> PCIe Gen3 phy.
>
> Co-developed-by: Selvam Sathappan Periakaruppan
> Signed-off-by: Selvam Sathappan Periakaruppan
> Signed-off-by: Sivaprakash Murugesan
> ---
> [V2]
> * Addressed review comments from Vinod
> drivers/phy/qualcomm/phy-qcom-pcie3-qmp.h | 139
> drivers/phy/qualcomm/phy-qcom-qmp.c | 171
> +-
> 2 files changed, 308 insertions(+), 2 deletions(-)
> create mode 100644 drivers/phy/qualcomm/phy-qcom-pcie3-qmp.h
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-pcie3-qmp.h
> b/drivers/phy/qualcomm/phy-qcom-pcie3-qmp.h
> new file mode 100644
> index 000..812ee75
> --- /dev/null
> +++ b/drivers/phy/qualcomm/phy-qcom-pcie3-qmp.h
> @@ -0,0 +1,139 @@
> +/* SPDX-License-Identifier: GPL-2.0
> + */
> +
> +/*
> + * Copyright (c) 2020, The Linux Foundation. All rights reserved.
> + */
> +
> +#ifndef PHY_QCOM_PCIE_H
Kernel uses this convention..
#ifndef PHY_QCOM_PCIE_H
#define PHY_QCOM_PCIE_H
header contents
#endif
Please update
> +
> +/* QMP V2 PCIE PHY - Found in IPQ8074 gen3 port - QSERDES PLL registers */
> +#define QSERDES_PLL_BG_TIMER 0x00c
> +#define QSERDES_PLL_SSC_PER1 0x01c
> +#define QSERDES_PLL_SSC_PER2 0x020
> +#define QSERDES_PLL_SSC_STEP_SIZE1_MODE0 0x024
> +#define QSERDES_PLL_SSC_STEP_SIZE2_MODE0 0x028
> +#define QSERDES_PLL_SSC_STEP_SIZE1_MODE1 0x02c
> +#define QSERDES_PLL_SSC_STEP_SIZE2_MODE1 0x030
> +#define QSERDES_PLL_BIAS_EN_CLKBUFLR_EN 0x03c
> +#define QSERDES_PLL_CLK_ENABLE1 0x040
> +#define QSERDES_PLL_SYS_CLK_CTRL 0x044
> +#define QSERDES_PLL_SYSCLK_BUF_ENABLE0x048
> +#define QSERDES_PLL_PLL_IVCO 0x050
> +#define QSERDES_PLL_LOCK_CMP1_MODE0 0x054
> +#define QSERDES_PLL_LOCK_CMP2_MODE0 0x058
> +#define QSERDES_PLL_LOCK_CMP1_MODE1 0x060
> +#define QSERDES_PLL_LOCK_CMP2_MODE1 0x064
> +#define QSERDES_PLL_BG_TRIM 0x074
> +#define QSERDES_PLL_CLK_EP_DIV_MODE0 0x078
> +#define QSERDES_PLL_CLK_EP_DIV_MODE1 0x07c
> +#define QSERDES_PLL_CP_CTRL_MODE00x080
> +#define QSERDES_PLL_CP_CTRL_MODE10x084
> +#define QSERDES_PLL_PLL_RCTRL_MODE0 0x088
> +#define QSERDES_PLL_PLL_RCTRL_MODE1 0x08C
why tab here instead of single space in others?
> static const struct qmp_phy_cfg sdm845_qmp_pciephy_cfg = {
> .type = PHY_TYPE_PCIE,
> .nlanes = 1,
> @@ -3024,8 +3181,15 @@ static int phy_pipe_clk_register(struct qcom_qmp *qmp,
> struct device_node *np)
>
> init.ops = &clk_fixed_rate_ops;
>
> - /* controllers using QMP phys use 125MHz pipe clock interface */
> - fixed->fixed_rate = 12500;
> + /*
> + * controllers using QMP phys use 125MHz pipe clock interface unless
> + * other frequency is specified in dts
> + */
> + ret = of_property_read_u32(np, "clock-output-rate",
> +(u32 *)&fixed->fixed_rate);
why this cast?
--
~Vinod
Re: [PATCH V2 5/7] PCI: qcom: Do PHY power on before PCIe init
On 29-07-20, 21:00, Sivaprakash Murugesan wrote:
> Commit cc1e06f033af ("phy: qcom: qmp: Use power_on/off ops for PCIe")
> changed phy ops from init/deinit to power on/off, due to this phy enable
> is getting called after PCIe init.
>
> On some platforms like ipq8074 phy should be inited before accessing the
> PCIe register space, otherwise the system would hang.
Have you verified that this causes no regression on sdm845 and other
platforms?
> So move phy_power_on API before PCIe init.
>
> Fixes: commit cc1e06f033af ("phy: qcom: qmp: Use power_on/off ops for PCIe")
Is this a fix..? You are updating sequencing for a new platform
> Co-developed-by: Selvam Sathappan Periakaruppan
> Signed-off-by: Selvam Sathappan Periakaruppan
> Signed-off-by: Sivaprakash Murugesan
> ---
> drivers/pci/controller/dwc/pcie-qcom.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c
> b/drivers/pci/controller/dwc/pcie-qcom.c
> index 3aac77a..e1b5651 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -1265,18 +1265,18 @@ static int qcom_pcie_host_init(struct pcie_port *pp)
>
> qcom_ep_reset_assert(pcie);
>
> - ret = pcie->ops->init(pcie);
> + ret = phy_power_on(pcie->phy);
> if (ret)
> return ret;
>
> - ret = phy_power_on(pcie->phy);
> + ret = pcie->ops->init(pcie);
> if (ret)
> - goto err_deinit;
> + goto err_disable_phy;
>
> if (pcie->ops->post_init) {
> ret = pcie->ops->post_init(pcie);
> if (ret)
> - goto err_disable_phy;
> + goto err_deinit;
> }
>
> dw_pcie_setup_rc(pp);
> @@ -1295,10 +1295,10 @@ static int qcom_pcie_host_init(struct pcie_port *pp)
> qcom_ep_reset_assert(pcie);
> if (pcie->ops->post_deinit)
> pcie->ops->post_deinit(pcie);
> -err_disable_phy:
> - phy_power_off(pcie->phy);
> err_deinit:
> pcie->ops->deinit(pcie);
> +err_disable_phy:
> + phy_power_off(pcie->phy);
>
> return ret;
> }
> --
> 2.7.4
--
~Vinod
Re: [PATCH V2 3/7] phy: qcom-qmp: Use correct values for ipq8074 PCIe Gen2 PHY init
On 29-07-20, 21:00, Sivaprakash Murugesan wrote:
> There were some problem in ipq8074 Gen2 PCIe phy init sequence.
>
> 1. Few register values were wrongly updated in the phy init sequence.
> 2. The register QSERDES_RX_SIGDET_CNTRL is a RX tuning parameter
>register which is added in serdes table causing the wrong register
>was getting updated.
> 3. Clocks and resets were not added in the phy init.
>
> Fix these to make Gen2 PCIe port on ipq8074 devices to work.
Applied to fixes, thanks
>
> Fixes: eef243d04b2b6 ("phy: qcom-qmp: Add support for IPQ8074")
>
no need of empty line here, have fixed it up while applying
--
~Vinod
Re: [PATCH] hugetlb_cgroup: convert comma to semicolon
On Sun, Aug 23, 2020 at 04:21:30PM +0100, Matthew Wilcox wrote:
> On Wed, Aug 19, 2020 at 10:14:11AM +0200, Giuseppe Scrivano wrote:
> > >> -cft->file_offset = offsetof(struct hugetlb_cgroup,
> > >> events_file[idx]),
> > >> +cft->file_offset = offsetof(struct hugetlb_cgroup,
> > >> events_file[idx]);
> > >> cft->flags = CFTYPE_NOT_ON_ROOT;
> >
> > I think in this case having two expressions as part of the same
> > statement is equivalent to having two separate statements. Both
> > cft->file_offset and cft->flags get the expected value.
>
> That's not how the comma operator works.
>
> It will evaluate offsetof(struct hugetlb_cgroup, events_file[idx]) and
> then discard the result. Since it has no side-effects, this is effectively
> doing:
>
> cft->file_offset = cft->flags = CFTYPE_NOT_ON_ROOT;
_oh_. I tested this. I'm wrong because the comma operator is at lower
precedence than assignment.
Testcase:
struct a {
int x;
int y;
};
void g(struct a *a) {
a->x = 1,
a->y = 0;
}
void h(struct a *a) {
a->x = (1,
a->y = 0);
}
test.c: In function ‘h’:
test.c:12:12: warning: left-hand operand of comma expression has no effect
[-Wunused-value]
12 | a->x = (1,
|^
:
0: 48 c7 07 01 00 00 00movq $0x1,(%rdi)
7: c3 retq
8: 0f 1f 84 00 00 00 00nopl 0x0(%rax,%rax,1)
f: 00
0010 :
10: 48 c7 07 00 00 00 00movq $0x0,(%rdi)
17: c3 retq
So there's no bug here! It's just confusing, so should be fixed.
(I think Andrew was confused too ;-)
Re: [PATCH] hugetlb_cgroup: convert comma to semicolon
On Sun, 2020-08-23 at 16:21 +0100, Matthew Wilcox wrote:
> On Wed, Aug 19, 2020 at 10:14:11AM +0200, Giuseppe Scrivano wrote:
> > > > - cft->file_offset = offsetof(struct hugetlb_cgroup,
> > > > events_file[idx]),
> > > > + cft->file_offset = offsetof(struct hugetlb_cgroup,
> > > > events_file[idx]);
> > > > cft->flags = CFTYPE_NOT_ON_ROOT;
> >
> > I think in this case having two expressions as part of the same
> > statement is equivalent to having two separate statements. Both
> > cft->file_offset and cft->flags get the expected value.
>
> That's not how the comma operator works.
>
> It will evaluate offsetof(struct hugetlb_cgroup, events_file[idx]) and
> then discard the result. Since it has no side-effects, this is effectively
> doing:
>
> cft->file_offset = cft->flags = CFTYPE_NOT_ON_ROOT;
$ gcc -x c -
#include
#include
struct foo {
int a;
char b[50];
};
int main(int argc, char **argv)
{
int a;
int b;
a = sizeof(struct foo), b = 1;
printf("a: %d, b: %d\n", a, b);
return 0;
}
$ ./a.out
a: 56, b: 1
Re: [RESEND PATCH v8 2/2] phy: Add USB3 PHY support for Intel LGM SoC
On 17-08-20, 15:05, Ramuthevar,Vadivel MuruganX wrote:
> From: Ramuthevar Vadivel Murugan
>
> Add support for USB PHY on Intel LGM SoC.
>
> Signed-off-by: Ramuthevar Vadivel Murugan
>
> Reviewed-by: Philipp Zabel
> ---
> drivers/phy/Kconfig | 11 ++
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-lgm-usb.c | 278
> ++
> 3 files changed, 290 insertions(+)
> create mode 100644 drivers/phy/phy-lgm-usb.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index de9362c25c07..01b53f86004c 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -49,6 +49,17 @@ config PHY_XGENE
> help
> This option enables support for APM X-Gene SoC multi-purpose PHY.
>
> +config USB_LGM_PHY
> + tristate "INTEL Lightning Mountain USB PHY Driver"
> + depends on USB_SUPPORT
Why is the dependent on USB..? Should that not be other way around?
> +static int get_flipped(struct tca_apb *ta, bool *flipped)
> +{
> + union extcon_property_value property;
> + int ret;
> +
> + ret = extcon_get_property(ta->phy.edev, EXTCON_USB_HOST,
> + EXTCON_PROP_USB_TYPEC_POLARITY, &property);
> + if (ret) {
> + dev_err(ta->phy.dev, "no polarity property from extcon\n");
> + return ret;
> + }
> +
> + *flipped = property.intval;
> +
> + return ret;
return 0 here?
> +static int phy_init(struct usb_phy *phy)
> +{
> + struct tca_apb *ta = container_of(phy, struct tca_apb, phy);
> + void __iomem *ctrl1 = phy->io_priv + CTRL1_OFFSET;
> + int val, ret, i;
> +
> + if (ta->phy_initialized)
> + return 0;
> +
> + for (i = 0; i < ARRAY_SIZE(PHY_RESETS); i++)
> + reset_control_deassert(ta->resets[i]);
> +
> + ret = readl_poll_timeout(ctrl1, val, val & SRAM_INIT_DONE, 10, 10 *
> 1000);
> + if (ret) {
> + dev_err(ta->phy.dev, "SRAM init failed, 0x%x\n", val);
> + return ret;
> + }
> +
> + writel(readl(ctrl1) | SRAM_EXT_LD_DONE, ctrl1);
> +
> + ta->phy_initialized = true;
> + if (!ta->phy.edev) {
> + writel(TCPC_CONN, ta->phy.io_priv + TCPC_OFFSET);
> + return phy->set_vbus(phy, true);
> + }
> +
> + schedule_work(&ta->wk);
why work for init?
> +static void tca_work(struct work_struct *work)
> +{
> + struct tca_apb *ta = container_of(work, struct tca_apb, wk);
> + bool connected;
> + bool flipped = false;
> + u32 val;
> + int ret;
> +
> + ret = get_flipped(ta, &flipped);
so every time this work is scheduled you are reading from firmware, why..
Typically we should read in probe and store it..
> + connected = extcon_get_state(ta->phy.edev, EXTCON_USB_HOST) && !ret;
lets handle ret and extcon_get_state separately please
> + if (connected == ta->connected)
> + return;
> +
> + ta->connected = connected;
> + if (connected) {
> + val = TCPC_CONN;
> + if (flipped)
> + val |= TCPC_FLIPPED;
> + dev_info(ta->phy.dev, "connected%s\n", flipped ? " flipped" :
> "");
debug perhaps
> + } else {
> + val = TCPC_DISCONN;
> + dev_info(ta->phy.dev, "disconnected\n");
here too
> +static int vbus_notifier(struct notifier_block *nb, unsigned long evnt, void
> *ptr)
> +{
> + return NOTIFY_DONE;
> +}
empty notifier, why bother?
> +static int phy_probe(struct platform_device *pdev)
> +{
> + struct reset_control *resets[ARRAY_SIZE(CTL_RESETS)];
> + struct device *dev = &pdev->dev;
> + struct usb_phy *phy;
> + struct tca_apb *ta;
> + int i;
> +
> + ta = devm_kzalloc(dev, sizeof(*ta), GFP_KERNEL);
> + if (!ta)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, ta);
> + INIT_WORK(&ta->wk, tca_work);
> +
> + phy = &ta->phy;
> + phy->dev = dev;
> + phy->label = dev_name(dev);
> + phy->type = USB_PHY_TYPE_USB3;
> + phy->init = phy_init;
> + phy->shutdown = phy_shutdown;
> + phy->set_vbus = phy_set_vbus;
> + phy->id_nb.notifier_call = id_notifier;
> + phy->vbus_nb.notifier_call = vbus_notifier;
> +
> + phy->io_priv = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(phy->io_priv))
> + return PTR_ERR(phy->io_priv);
> +
> + ta->vbus = devm_regulator_get(dev, "vbus");
> + if (IS_ERR(ta->vbus))
> + return PTR_ERR(ta->vbus);
> +
> + for (i = 0; i < ARRAY_SIZE(CTL_RESETS); i++) {
> + resets[i] = devm_reset_control_get_exclusive(dev,
> CTL_RESETS[i]);
> + if (IS_ERR(resets[i])) {
> + dev_err(dev, "%s reset not found\n", CTL_RESETS[i]);
> + return PTR_ERR(resets[i]);
> + }
> + }
> +
> + for (i = 0; i < ARRAY_SIZE(PHY_RESETS); i++) {
> + ta->resets[i] = devm_reset_control_get_exclusive(dev,
> PHY_RESETS[i]);
> +
Re: [PATCH -next] phy: ti: j721e-wiz: Remove duplicate include
On 18-08-20, 19:47, YueHaibing wrote: > Remove duplicate include file Applied, thanks > > Signed-off-by: YueHaibing > --- > drivers/phy/ti/phy-j721e-wiz.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c > index 33c4cf0105a4..c9cfafe89cbf 100644 > --- a/drivers/phy/ti/phy-j721e-wiz.c > +++ b/drivers/phy/ti/phy-j721e-wiz.c > @@ -20,7 +20,6 @@ > #include > #include > #include > -#include > > #define WIZ_SERDES_CTRL 0x404 > #define WIZ_SERDES_TOP_CTRL 0x408 > -- > 2.17.1 > -- ~Vinod
Re: [PATCH v5] phy: omap-usb2-phy: disable PHY charger detect
On 21-08-20, 11:03, Roger Quadros wrote:
> AM654x PG1.0 has a silicon bug that D+ is pulled high after POR, which
> could cause enumeration failure with some USB hubs. Disabling the
> USB2_PHY Charger Detect function will put D+ into the normal state.
>
> This addresses Silicon Errata:
> i2075 - "USB2PHY: USB2PHY Charger Detect is Enabled by Default Without VBUS
> Presence"
>
> Signed-off-by: Roger Quadros
> Tested-by: Jan Kiszka
> ---
> Vinod/Kishon,
>
> As this is an errata fix, it should be targetted for 5.9-rc cycle.
> Thanks.
>
> cheers,
> -roger
>
> Changelog:
> v5
> - don't use dt property to enable workaround. Use soc_device_match() instead.
>
> v4
> - fix example to fix dt_binding_check warnings
> - '#phy-cells' -> "#phy-cells"
> - Add 'oneOf' to compatible logic to allow just "ti,omap-usb2" as valid
>
> v3
> - Removed quotes from compatibles
> - changed property to "ti,disable-charger-det"
>
> v2
> - Address Rob's comments on YAML schema.
>
> drivers/phy/ti/phy-omap-usb2.c | 70 +-
> 1 file changed, 51 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/phy/ti/phy-omap-usb2.c b/drivers/phy/ti/phy-omap-usb2.c
> index cb2dd3230fa7..65d73142d4ec 100644
> --- a/drivers/phy/ti/phy-omap-usb2.c
> +++ b/drivers/phy/ti/phy-omap-usb2.c
> @@ -6,26 +6,31 @@
> * Author: Kishon Vijay Abraham I
> */
>
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> #include
> -#include
> -#include
> #include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> #include
> +#include
> #include
> -#include
> +#include
> +#include
> #include
> -#include
> +#include
> +#include
> +#include
Can we do reorder in a separate patch and not in a fixes patch
> static int omap_usb2_probe(struct platform_device *pdev)
> {
> struct omap_usb *phy;
> @@ -366,14 +399,14 @@ static int omap_usb2_probe(struct platform_device *pdev)
> phy->mask = phy_data->mask;
> phy->power_on = phy_data->power_on;
> phy->power_off = phy_data->power_off;
> + phy->flags = phy_data->flags;
>
> - if (phy_data->flags & OMAP_USB2_CALIBRATE_FALSE_DISCONNECT) {
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - phy->phy_base = devm_ioremap_resource(&pdev->dev, res);
> - if (IS_ERR(phy->phy_base))
> - return PTR_ERR(phy->phy_base);
> - phy->flags |= OMAP_USB2_CALIBRATE_FALSE_DISCONNECT;
> - }
> + omap_usb2_init_errata(phy);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + phy->phy_base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(phy->phy_base))
> + return PTR_ERR(phy->phy_base);
>
> phy->syscon_phy_power = syscon_regmap_lookup_by_phandle(node,
> "syscon-phy-power");
> @@ -405,7 +438,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
> }
> }
>
> -
this does not belong to this patch, pls feel free to send a separate one
for this
--
~Vinod
[PATCH 01/22] dt-bindings: gpio: fsl-imx-gpio: Add i.MX 8 compatibles
DTSes with new i.MX 8 SoCs introduce their own compatibles so add them
to fix dtbs_check warnings like:
arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: gpio@3020:
compatible:0: 'fsl,imx8mm-gpio' is not one of ['fsl,imx1-gpio',
'fsl,imx21-gpio', 'fsl,imx31-gpio', 'fsl,imx35-gpio', 'fsl,imx7d-gpio']
From schema: Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml
arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: gpio@3020:
compatible: ['fsl,imx8mm-gpio', 'fsl,imx35-gpio'] is too long
arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: gpio@3020:
compatible: Additional items are not allowed ('fsl,imx35-gpio' was
unexpected)
Signed-off-by: Krzysztof Kozlowski
---
.../bindings/gpio/fsl-imx-gpio.yaml | 21 +--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml
b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml
index 0b223abe8cfb..454db20c2d1a 100644
--- a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml
@@ -11,12 +11,21 @@ maintainers:
properties:
compatible:
-enum:
- - fsl,imx1-gpio
- - fsl,imx21-gpio
- - fsl,imx31-gpio
- - fsl,imx35-gpio
- - fsl,imx7d-gpio
+oneOf:
+ - enum:
+ - fsl,imx1-gpio
+ - fsl,imx21-gpio
+ - fsl,imx31-gpio
+ - fsl,imx35-gpio
+ - fsl,imx7d-gpio
+ - items:
+ - enum:
+ - fsl,imx8mm-gpio
+ - fsl,imx8mn-gpio
+ - fsl,imx8mp-gpio
+ - fsl,imx8mq-gpio
+ - fsl,imx8qxp-gpio
+ - const: fsl,imx35-gpio
reg:
maxItems: 1
--
2.17.1
[PATCH 03/22] dt-bindings: gpio: fsl-imx-gpio: Add parsing of hogs
Allow parsing GPIO controller children nodes with GPIO hogs to fix warning: arch/arm64/boot/dts/freescale/imx8mq-evk.dt.yaml: gpio@3024: 'wl-reg-on' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/gpio/fsl-imx-gpio.yaml | 17 + 1 file changed, 17 insertions(+) diff --git a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml index 1fac69573bb9..337b99343dce 100644 --- a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml @@ -54,6 +54,23 @@ properties: gpio-ranges: maxItems: 1 +patternProperties: + "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$": +type: object +properties: + gpio-hog: true + gpios: true + input: true + output-high: true + output-low: true + line-name: true + +required: + - gpio-hog + - gpios + +additionalProperties: false + required: - compatible - reg -- 2.17.1
[PATCH 02/22] dt-bindings: gpio: fsl-imx-gpio: Add gpio-ranges property
The GPIO controller node can have gpio-ranges property. This fixes
dtbs_check warnings like:
arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: gpio@3020:
'gpio-ranges' does not match any of the regexes: 'pinctrl-[0-9]+'
From schema: Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml
Signed-off-by: Krzysztof Kozlowski
---
.../devicetree/bindings/gpio/fsl-imx-gpio.yaml| 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml
b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml
index 454db20c2d1a..1fac69573bb9 100644
--- a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml
@@ -51,6 +51,9 @@ properties:
gpio-controller: true
+ gpio-ranges:
+maxItems: 1
+
required:
- compatible
- reg
@@ -62,6 +65,18 @@ required:
additionalProperties: false
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: fsl,imx8mp-gpio
+then:
+ properties:
+gpio-ranges:
+ minItems: 1
+ maxItems: 2
+
examples:
- |
gpio0: gpio@73f84000 {
--
2.17.1
[PATCH 06/22] dt-bindings: pwm: imx-pwm: Add i.MX 8M compatibles
DTSes with new i.MX 8M SoCs introduce their own compatibles so add them
to fix dtbs_check warnings like:
arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: pwm@3066:
compatible:0: 'fsl,imx8mm-pwm' is not one of ['fsl,imx1-pwm',
'fsl,imx27-pwm']
From schema: Documentation/devicetree/bindings/pwm/imx-pwm.yaml
arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: pwm@3066:
compatible: ['fsl,imx8mm-pwm', 'fsl,imx27-pwm'] is too long
arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: pwm@3066:
compatible: Additional items are not allowed ('fsl,imx27-pwm' was
unexpected)
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/pwm/imx-pwm.yaml | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.yaml
b/Documentation/devicetree/bindings/pwm/imx-pwm.yaml
index 01df06777cba..473863eb67e5 100644
--- a/Documentation/devicetree/bindings/pwm/imx-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/imx-pwm.yaml
@@ -19,9 +19,17 @@ properties:
- 3
compatible:
-enum:
- - fsl,imx1-pwm
- - fsl,imx27-pwm
+oneOf:
+ - enum:
+ - fsl,imx1-pwm
+ - fsl,imx27-pwm
+ - items:
+ - enum:
+ - fsl,imx8mm-pwm
+ - fsl,imx8mn-pwm
+ - fsl,imx8mp-pwm
+ - fsl,imx8mq-pwm
+ - const: fsl,imx27-pwm
reg:
maxItems: 1
--
2.17.1
[PATCH 04/22] dt-bindings: gpio: fsl-imx-gpio: Add power-domains
Parse also optional power-domains property to fix dtbs_check warnings like: arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dt.yaml: gpio@5d08: 'power-domains' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml index 337b99343dce..a7d17a98df6b 100644 --- a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml @@ -54,6 +54,9 @@ properties: gpio-ranges: maxItems: 1 + power-domains: +maxItems: 1 + patternProperties: "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$": type: object -- 2.17.1
[PATCH 07/22] dt-bindings: serial: fsl-imx-uart: imx-pwm: Add i.MX 8M compatibles
DTSes with new i.MX 8M SoCs introduce their own compatibles so add them
to fix dtbs_check warnings like:
arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: pwm@3066:
compatible:0: 'fsl,imx8mm-pwm' is not one of ['fsl,imx1-pwm',
'fsl,imx27-pwm']
From schema: Documentation/devicetree/bindings/pwm/imx-pwm.yaml
arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: pwm@3066:
compatible: ['fsl,imx8mm-pwm', 'fsl,imx27-pwm'] is too long
arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: pwm@3066:
compatible: Additional items are not allowed ('fsl,imx27-pwm' was
unexpected)
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml
b/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml
index cba3f83ccd5f..3d896173b3b0 100644
--- a/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml
@@ -36,6 +36,10 @@ properties:
- fsl,imx6sx-uart
- fsl,imx6ul-uart
- fsl,imx7d-uart
+- fsl,imx8mm-uart
+- fsl,imx8mn-uart
+- fsl,imx8mp-uart
+- fsl,imx8mq-uart
- const: fsl,imx6q-uart
reg:
--
2.17.1
[PATCH 10/22] dt-bindings: reset: fsl,imx7-src: Add i.MX 8M compatibles
DTSes with new i.MX 8M SoCs introduce their own compatibles so add them to fix dtbs_check warnings like: arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: reset-controller@3039: compatible:0: 'fsl,imx8mm-src' is not one of ['fsl,imx7d-src', 'fsl,imx8mq-src', 'fsl,imx8mp-src'] From schema: Documentation/devicetree/bindings/reset/fsl,imx7-src.yaml arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: reset-controller@3039: compatible:1: 'syscon' was expected arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: reset-controller@3039: compatible: ['fsl,imx8mm-src', 'fsl,imx8mq-src', 'syscon'] is too long Signed-off-by: Krzysztof Kozlowski --- .../bindings/reset/fsl,imx7-src.yaml | 19 +-- 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/reset/fsl,imx7-src.yaml b/Documentation/devicetree/bindings/reset/fsl,imx7-src.yaml index 569cd3bd3a70..00430e2eabc8 100644 --- a/Documentation/devicetree/bindings/reset/fsl,imx7-src.yaml +++ b/Documentation/devicetree/bindings/reset/fsl,imx7-src.yaml @@ -22,12 +22,19 @@ description: | properties: compatible: -items: - - enum: - - fsl,imx7d-src - - fsl,imx8mq-src - - fsl,imx8mp-src - - const: syscon +oneOf: + - items: + - enum: + - fsl,imx7d-src + - fsl,imx8mq-src + - fsl,imx8mp-src + - const: syscon + - items: + - enum: + - fsl,imx8mm-src + - fsl,imx8mn-src + - const: fsl,imx8mq-src + - const: syscon reg: maxItems: 1 -- 2.17.1
[PATCH 11/22] dt-bindings: thermal: imx8mm-thermal: Add i.MX 8M Nano compatible
DTSes with new i.MX 8M SoCs introduce their own compatibles so add them
to fix dtbs_check warnings like:
arch/arm64/boot/dts/freescale/imx8mn-evk.dt.yaml: tmu@3026:
compatible:0: 'fsl,imx8mn-tmu' is not one of ['fsl,imx8mm-tmu',
'fsl,imx8mp-tmu']
From schema: Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml
arch/arm64/boot/dts/freescale/imx8mn-evk.dt.yaml: tmu@3026:
compatible: ['fsl,imx8mn-tmu', 'fsl,imx8mm-tmu'] is too long
arch/arm64/boot/dts/freescale/imx8mn-evk.dt.yaml: tmu@3026:
compatible: Additional items are not allowed ('fsl,imx8mm-tmu' was
unexpected)
Signed-off-by: Krzysztof Kozlowski
---
.../devicetree/bindings/thermal/imx8mm-thermal.yaml| 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml
b/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml
index 38852877b8e3..89c54e08ee61 100644
--- a/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/imx8mm-thermal.yaml
@@ -18,9 +18,13 @@ description: |
properties:
compatible:
-enum:
- - fsl,imx8mm-tmu
- - fsl,imx8mp-tmu
+oneOf:
+ - enum:
+ - fsl,imx8mm-tmu
+ - fsl,imx8mp-tmu
+ - items:
+ - const: fsl,imx8mn-tmu
+ - const: fsl,imx8mm-tmu
reg:
maxItems: 1
--
2.17.1
[PATCH 05/22] dt-bindings: perf: fsl-imx-ddr: Add i.MX 8M compatibles
DTSes with new i.MX 8M SoCs introduce their own compatibles so add them
to fix dtbs_check warnings like:
arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: ddr-pmu@3d80:
compatible:0: 'fsl,imx8mm-ddr-pmu' is not one of ['fsl,imx8-ddr-pmu',
'fsl,imx8m-ddr-pmu', 'fsl,imx8mp-ddr-pmu']
From schema: Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: ddr-pmu@3d80:
compatible: ['fsl,imx8mm-ddr-pmu', 'fsl,imx8m-ddr-pmu'] is too long
arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: ddr-pmu@3d80:
compatible: Additional items are not allowed ('fsl,imx8m-ddr-pmu' was
unexpected)
Signed-off-by: Krzysztof Kozlowski
---
.../devicetree/bindings/perf/fsl-imx-ddr.yaml | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
b/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
index 9ed8f44adabe..3900b1093de0 100644
--- a/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
+++ b/Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
@@ -11,10 +11,17 @@ maintainers:
properties:
compatible:
-enum:
- - fsl,imx8-ddr-pmu
- - fsl,imx8m-ddr-pmu
- - fsl,imx8mp-ddr-pmu
+oneOf:
+ - enum:
+ - fsl,imx8-ddr-pmu
+ - fsl,imx8m-ddr-pmu
+ - fsl,imx8mp-ddr-pmu
+ - items:
+ - enum:
+ - fsl,imx8mm-ddr-pmu
+ - fsl,imx8mn-ddr-pmu
+ - fsl,imx8mq-ddr-pmu
+ - const: fsl,imx8m-ddr-pmu
reg:
maxItems: 1
--
2.17.1
[PATCH 22/22] arm64: dts: imx8mp: Remove i.MX7 compatible from DDR PMU
The DDR PMU on i.MX 8MP has its own compatible described in bindings and
used in the driver (with its own quirks). Remove additional
fsl,imx8m-ddr-pmu compatible to fix dtbs_check warnings like:
arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dt.yaml: ddr-pmu@3d80:
compatible: ['fsl,imx8mq-ddr-pmu', 'fsl,imx8m-ddr-pmu'] is not valid under
any of the given schemas (Possible causes of the failure):
arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dt.yaml: ddr-pmu@3d80:
compatible: ['fsl,imx8mq-ddr-pmu', 'fsl,imx8m-ddr-pmu'] is too long
From schema: Docmentation/devicetree/bindings/perf/fsl-imx-ddr.yaml
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index 9de2aa1c573c..e34eff19fcae 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -746,7 +746,7 @@
};
ddr-pmu@3d80 {
- compatible = "fsl,imx8mp-ddr-pmu", "fsl,imx8m-ddr-pmu";
+ compatible = "fsl,imx8mp-ddr-pmu";
reg = <0x3d80 0x40>;
interrupts = ;
};
--
2.17.1
[PATCH 18/22] arm64: dts: imx8mq-zii-ultra: Add hog suffixes to GPIO hogs
According to device tree specification, device node names should be
somewhat generic and reflecting the function of the device so add the
"hog" suffixes to all GPIO hog nodes.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
index 0d1088dcaa02..fa7a041ffcfd 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq-zii-ultra.dtsi
@@ -229,28 +229,28 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_gpio3_hog>;
- usb-emulation {
+ usb-emulation-hog {
gpio-hog;
gpios = <10 GPIO_ACTIVE_HIGH>;
output-low;
line-name = "usb-emulation";
};
- usb-mode1 {
+ usb-mode1-hog {
gpio-hog;
gpios = <11 GPIO_ACTIVE_HIGH>;
output-high;
line-name = "usb-mode1";
};
- usb-pwr {
+ usb-pwr-hog {
gpio-hog;
gpios = <12 GPIO_ACTIVE_LOW>;
output-high;
line-name = "usb-pwr-ctrl-en-n";
};
- usb-mode2 {
+ usb-mode2-hog {
gpio-hog;
gpios = <13 GPIO_ACTIVE_HIGH>;
output-high;
--
2.17.1
[PATCH 17/22] arm64: dts: imx8mq-evk: Add hog suffix to wl-reg-on
According to device tree specification, device node names should be
somewhat generic and reflecting the function of the device so add the
"hog" suffix to wl-reg-on GPIO hog.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
index 8aa9cd8e495a..a088831d2e24 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
@@ -157,7 +157,7 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_wifi_reset>;
- wl-reg-on {
+ wl-reg-on-hog {
gpio-hog;
gpios = <29 GPIO_ACTIVE_HIGH>;
output-high;
--
2.17.1
[PATCH 16/22] dt-bindings: interrupt-controller: fsl,irqsteer: Fix compatible matching
The i.MX 8M DTSes use two compatibles so update the binding to fix
dtbs_check warnings like:
arch/arm64/boot/dts/freescale/imx8mq-thor96.dt.yaml:
interrupt-controller@32e2d000:
compatible: ['fsl,imx8m-irqsteer', 'fsl,imx-irqsteer'] is too long
From schema:
Domentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml
arch/arm64/boot/dts/freescale/imx8mq-thor96.dt.yaml:
interrupt-controller@32e2d000:
compatible: Additional items are not allowed ('fsl,imx-irqsteer' was
unexpected)
Signed-off-by: Krzysztof Kozlowski
---
.../bindings/interrupt-controller/fsl,irqsteer.yaml | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml
b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml
index 360a575ef8b0..3b11a1a15398 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml
@@ -11,9 +11,11 @@ maintainers:
properties:
compatible:
-enum:
- - fsl,imx8m-irqsteer
- - fsl,imx-irqsteer
+oneOf:
+ - const: fsl,imx-irqsteer
+ - items:
+ - const: fsl,imx8m-irqsteer
+ - const: fsl,imx-irqsteer
reg:
maxItems: 1
--
2.17.1
[PATCH 15/22] dt-bindings: arm: fsl: Add ZII Ultra boards binding
Document the binding for Zodiac Inflight Innovations Ultra Boards. Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/arm/fsl.yaml | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 93a21b10d115..f2e670e9ae54 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -379,6 +379,14 @@ properties: - technexion,pico-pi-imx8m # TechNexion PICO-PI-8M evk - const: fsl,imx8mq + - description: Zodiac Inflight Innovations Ultra Boards +items: + - enum: + - zii,imx8mq-ultra-rmb3 + - zii,imx8mq-ultra-zest + - const: zii,imx8mq-ultra + - const: fsl,imx8mq + - description: i.MX8QXP based Boards items: - enum: -- 2.17.1
[PATCH 19/22] arm64: dts: imx8mm: Remove i.MX7 compatible from USDHC
The USDHC on i.MX 8M Mini has its own compatible described in bindings
and used in the driver (with its own quirks). Remove additional
fsl,imx7d-usdhc compatible to fix dtbs_check warnings like:
arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: mmc@30b4: compatible:
['fsl,imx8mm-usdhc', 'fsl,imx7d-usdhc'] is too long
From schema: Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: mmc@30b4: compatible:
Additional items are not allowed ('fsl,imx7d-usdhc' was unexpected)
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index 76f040e4be5e..38bf41184489 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -784,7 +784,7 @@
};
usdhc1: mmc@30b4 {
- compatible = "fsl,imx8mm-usdhc",
"fsl,imx7d-usdhc";
+ compatible = "fsl,imx8mm-usdhc";
reg = <0x30b4 0x1>;
interrupts = ;
clocks = <&clk IMX8MM_CLK_IPG_ROOT>,
@@ -798,7 +798,7 @@
};
usdhc2: mmc@30b5 {
- compatible = "fsl,imx8mm-usdhc",
"fsl,imx7d-usdhc";
+ compatible = "fsl,imx8mm-usdhc";
reg = <0x30b5 0x1>;
interrupts = ;
clocks = <&clk IMX8MM_CLK_IPG_ROOT>,
@@ -812,7 +812,7 @@
};
usdhc3: mmc@30b6 {
- compatible = "fsl,imx8mm-usdhc",
"fsl,imx7d-usdhc";
+ compatible = "fsl,imx8mm-usdhc";
reg = <0x30b6 0x1>;
interrupts = ;
clocks = <&clk IMX8MM_CLK_IPG_ROOT>,
--
2.17.1
[PATCH 21/22] arm64: dts: imx8qxp: Remove i.MX7 compatible from USDHC
The USDHC on i.MX 8QXP has its own compatible described in bindings
and used in the driver (with its own quirks). Remove additional
fsl,imx7d-usdhc compatible to fix dtbs_check warnings like:
arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dt.yaml: mmc@5b01:
compatible: ['fsl,imx8qxp-usdhc', 'fsl,imx7d-usdhc'] is too long
From schema: /ocumentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dt.yaml: mmc@5b01:
compatible: Additional items are not allowed ('fsl,imx7d-usdhc' was
unexpected)
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 61bccb69f09e..26c4fcdfe290 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -362,7 +362,7 @@
};
usdhc1: mmc@5b01 {
- compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc";
+ compatible = "fsl,imx8qxp-usdhc";
interrupts = ;
reg = <0x5b01 0x1>;
clocks = <&conn_lpcg IMX_CONN_LPCG_SDHC0_IPG_CLK>,
@@ -374,7 +374,7 @@
};
usdhc2: mmc@5b02 {
- compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc";
+ compatible = "fsl,imx8qxp-usdhc";
interrupts = ;
reg = <0x5b02 0x1>;
clocks = <&conn_lpcg IMX_CONN_LPCG_SDHC1_IPG_CLK>,
@@ -388,7 +388,7 @@
};
usdhc3: mmc@5b03 {
- compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc";
+ compatible = "fsl,imx8qxp-usdhc";
interrupts = ;
reg = <0x5b03 0x1>;
clocks = <&conn_lpcg IMX_CONN_LPCG_SDHC2_IPG_CLK>,
--
2.17.1
[PATCH 20/22] arm64: dts: imx8qxp: Remove i.MX7 compatible from UART
The UART on i.MX 8QXP has its own compatible described in bindings
and used in the driver (with its own quirks). Remove additional
fsl,imx7ulp-lpuart compatible to fix dtbs_check warnings like:
arch/arm64/boot/dts/freescale/imx8qxp-mek.dt.yaml: serial@5a06:
compatible: ['fsl,imx8qxp-lpuart', 'fsl,imx7ulp-lpuart'] is too long
From schema: Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
arch/arm64/boot/dts/freescale/imx8qxp-mek.dt.yaml: serial@5a06:
compatible: Additional items are not allowed ('fsl,imx7ulp-lpuart' was
unexpected)
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index e46faac1fe71..61bccb69f09e 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -257,7 +257,7 @@
};
adma_lpuart0: serial@5a06 {
- compatible = "fsl,imx8qxp-lpuart", "fsl,imx7ulp-lpuart";
+ compatible = "fsl,imx8qxp-lpuart";
reg = <0x5a06 0x1000>;
interrupts = ;
clocks = <&adma_lpcg IMX_ADMA_LPCG_UART0_IPG_CLK>,
@@ -268,7 +268,7 @@
};
adma_lpuart1: serial@5a07 {
- compatible = "fsl,imx8qxp-lpuart", "fsl,imx7ulp-lpuart";
+ compatible = "fsl,imx8qxp-lpuart";
reg = <0x5a07 0x1000>;
interrupts = ;
clocks = <&adma_lpcg IMX_ADMA_LPCG_UART1_IPG_CLK>,
@@ -279,7 +279,7 @@
};
adma_lpuart2: serial@5a08 {
- compatible = "fsl,imx8qxp-lpuart", "fsl,imx7ulp-lpuart";
+ compatible = "fsl,imx8qxp-lpuart";
reg = <0x5a08 0x1000>;
interrupts = ;
clocks = <&adma_lpcg IMX_ADMA_LPCG_UART2_IPG_CLK>,
@@ -290,7 +290,7 @@
};
adma_lpuart3: serial@5a09 {
- compatible = "fsl,imx8qxp-lpuart", "fsl,imx7ulp-lpuart";
+ compatible = "fsl,imx8qxp-lpuart";
reg = <0x5a09 0x1000>;
interrupts = ;
clocks = <&adma_lpcg IMX_ADMA_LPCG_UART3_IPG_CLK>,
--
2.17.1
[PATCH 12/22] dt-bindings: mmc: fsl-imx-esdhc: Fix i.MX 8M compatible matching
The i.MX 8M DTSes use two compatibles so update the binding to fix
dtbs_check warnings like:
arch/arm64/boot/dts/freescale/imx8mn-evk.dt.yaml: mmc@30b4:
compatible: ['fsl,imx8mn-usdhc', 'fsl,imx7d-usdhc'] is too long
From schema: Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
arch/arm64/boot/dts/freescale/imx8mn-evk.dt.yaml: mmc@30b4:
compatible: Additional items are not allowed ('fsl,imx7d-usdhc' was
unexpected)
arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dt.yaml: mmc@30b4:
compatible: ['fsl,imx8mn-usdhc', 'fsl,imx7d-usdhc'] is too long
Signed-off-by: Krzysztof Kozlowski
---
.../bindings/mmc/fsl-imx-esdhc.yaml | 38 ++-
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
index 10b45966f1b8..f26e0755b38d 100644
--- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
@@ -21,23 +21,27 @@ description: |
properties:
compatible:
-enum:
- - fsl,imx25-esdhc
- - fsl,imx35-esdhc
- - fsl,imx51-esdhc
- - fsl,imx53-esdhc
- - fsl,imx6q-usdhc
- - fsl,imx6sl-usdhc
- - fsl,imx6sx-usdhc
- - fsl,imx6ull-usdhc
- - fsl,imx7d-usdhc
- - fsl,imx7ulp-usdhc
- - fsl,imx8mq-usdhc
- - fsl,imx8mm-usdhc
- - fsl,imx8mn-usdhc
- - fsl,imx8mp-usdhc
- - fsl,imx8qm-usdhc
- - fsl,imx8qxp-usdhc
+oneOf:
+ - enum:
+ - fsl,imx25-esdhc
+ - fsl,imx35-esdhc
+ - fsl,imx51-esdhc
+ - fsl,imx53-esdhc
+ - fsl,imx6q-usdhc
+ - fsl,imx6sl-usdhc
+ - fsl,imx6sx-usdhc
+ - fsl,imx6ull-usdhc
+ - fsl,imx7d-usdhc
+ - fsl,imx7ulp-usdhc
+ - fsl,imx8mq-usdhc
+ - fsl,imx8mm-usdhc
+ - fsl,imx8qxp-usdhc
+ - items:
+ - enum:
+ - fsl,imx8mn-usdhc
+ - fsl,imx8mp-usdhc
+ - fsl,imx8mq-usdhc
+ - const: fsl,imx7d-usdhc
reg:
maxItems: 1
--
2.17.1
[PATCH 14/22] dt-bindings: arm: fsl: Fix Toradex Colibri i.MX 8 binding
The Toradex Colibri i.MX 8 Evaluation board has two Toradex compatibles so it needs separate entry. This fixes dtbs_check warning: arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dt.yaml: /: compatible: ['toradex,colibri-imx8x-eval-v3', 'toradex,colibri-imx8x', 'fsl,imx8qxp'] is not valid under any of the given schemas (Possible causes of the failure): arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dt.yaml: /: compatible: ['toradex,colibri-imx8x-eval-v3', 'toradex,colibri-imx8x', 'fsl,imx8qxp'] is too long Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 591fa336d6fa..93a21b10d115 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -385,7 +385,13 @@ properties: - einfochips,imx8qxp-ai_ml # i.MX8QXP AI_ML Board - fsl,imx8qxp-mek # i.MX8QXP MEK Board - toradex,colibri-imx8x # Colibri iMX8X Module + - const: fsl,imx8qxp + + - description: Toradex Colibri i.MX8 Evaluation Board +items: + - enum: - toradex,colibri-imx8x-eval-v3 # Colibri iMX8X Module on Colibri Evaluation Board V3 + - const: toradex,colibri-imx8x - const: fsl,imx8qxp - description: -- 2.17.1
[PATCH 13/22] dt-bindings: nvmem: imx-ocotp: Update i.MX 8M compatibles
DTSes with new i.MX 8M SoCs use two compatibles so update the binding to
fix dtbs_check warnings like:
arch/arm64/boot/dts/freescale/imx8mn-evk.dt.yaml: efuse@3035:
compatible:1: 'syscon' was expected
From schema: Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
arch/arm64/boot/dts/freescale/imx8mn-evk.dt.yaml: efuse@3035:
compatible: ['fsl,imx8mn-ocotp', 'fsl,imx8mm-ocotp', 'syscon'] is too long
arch/arm64/boot/dts/freescale/imx8mn-evk.dt.yaml: efuse@3035:
compatible: Additional items are not allowed ('syscon' was unexpected)
Signed-off-by: Krzysztof Kozlowski
---
.../devicetree/bindings/nvmem/imx-ocotp.yaml | 39 ---
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
index 1c9d7f05f173..b5b250185afd 100644
--- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
+++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
@@ -19,21 +19,30 @@ allOf:
properties:
compatible:
-items:
- - enum:
- - fsl,imx6q-ocotp
- - fsl,imx6sl-ocotp
- - fsl,imx6sx-ocotp
- - fsl,imx6ul-ocotp
- - fsl,imx6ull-ocotp
- - fsl,imx7d-ocotp
- - fsl,imx6sll-ocotp
- - fsl,imx7ulp-ocotp
- - fsl,imx8mq-ocotp
- - fsl,imx8mm-ocotp
- - fsl,imx8mn-ocotp
- - fsl,imx8mp-ocotp
- - const: syscon
+oneOf:
+ - items:
+ - enum:
+ - fsl,imx6q-ocotp
+ - fsl,imx6sl-ocotp
+ - fsl,imx6sx-ocotp
+ - fsl,imx6ul-ocotp
+ - fsl,imx6ull-ocotp
+ - fsl,imx7d-ocotp
+ - fsl,imx6sll-ocotp
+ - fsl,imx7ulp-ocotp
+ - fsl,imx8mq-ocotp
+ - fsl,imx8mm-ocotp
+ - fsl,imx8mn-ocotp
+ - fsl,imx8mp-ocotp
+ - const: syscon
+ - items:
+ # The devices are not really compatible with fsl,imx8mm-ocotp,
however
+ # the code for getting SoC revision depends on fsl,imx8mm-ocotp
compatible.
+ - enum:
+ - fsl,imx8mn-ocotp
+ - fsl,imx8mp-ocotp
+ - const: fsl,imx8mm-ocotp
+ - const: syscon
reg:
maxItems: 1
--
2.17.1
[PATCH 09/22] dt-bindings: mtd: gpmi-nand: Add i.MX 8M compatibles
DTSes with new i.MX 8M SoCs introduce their own compatibles so add them
to fix dtbs_check warnings like:
arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: nand-controller@33002000:
compatible:0: 'fsl,imx8mm-gpmi-nand' is not one of ['fsl,imx23-gpmi-nand',
'fsl,imx28-gpmi-nand', 'fsl,imx6q-gpmi-nand', 'fsl,imx6sx-gpmi-nand',
'fsl,imx7d-gpmi-nand']
From schema: Documentation/devicetree/bindings/mtd/gpmi-nand.yaml
arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: nand-controller@33002000:
compatible: ['fsl,imx8mm-gpmi-nand', 'fsl,imx7d-gpmi-nand'] is too long
arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: nand-controller@33002000:
compatible: Additional items are not allowed ('fsl,imx7d-gpmi-nand' was
unexpected)
Signed-off-by: Krzysztof Kozlowski
---
.../devicetree/bindings/mtd/gpmi-nand.yaml | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml
b/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml
index 3201372b7f85..28ff8c581837 100644
--- a/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml
+++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml
@@ -20,12 +20,18 @@ description: |
properties:
compatible:
-enum:
- - fsl,imx23-gpmi-nand
- - fsl,imx28-gpmi-nand
- - fsl,imx6q-gpmi-nand
- - fsl,imx6sx-gpmi-nand
- - fsl,imx7d-gpmi-nand
+oneOf:
+ - enum:
+ - fsl,imx23-gpmi-nand
+ - fsl,imx28-gpmi-nand
+ - fsl,imx6q-gpmi-nand
+ - fsl,imx6sx-gpmi-nand
+ - fsl,imx7d-gpmi-nand
+ - items:
+ - enum:
+ - fsl,imx8mm-gpmi-nand
+ - fsl,imx8mn-gpmi-nand
+ - const: fsl,imx7d-gpmi-nand
reg:
items:
--
2.17.1
[PATCH 08/22] dt-bindings: watchdog: fsl-imx-wdt: Add i.MX 8M compatibles
DTSes with new i.MX 8M SoCs introduce their own compatibles so add them
to fix dtbs_check warnings like:
arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dt.yaml:
watchdog@3028:
compatible:0: 'fsl,imx8mm-wdt' is not one of ['fsl,imx21-wdt']
From schema: Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml
arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dt.yaml:
watchdog@3028:
compatible: ['fsl,imx8mm-wdt', 'fsl,imx21-wdt'] is too long
arch/arm64/boot/dts/freescale/imx8mm-var-som-symphony.dt.yaml:
watchdog@3028:
compatible: Additional items are not allowed ('fsl,imx21-wdt' was
unexpected)
Signed-off-by: Krzysztof Kozlowski
---
.../devicetree/bindings/watchdog/fsl-imx-wdt.yaml | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml
b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml
index d96b93b11fad..991b4e33486e 100644
--- a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml
@@ -14,8 +14,15 @@ allOf:
properties:
compatible:
-enum:
- - fsl,imx21-wdt
+oneOf:
+ - const: fsl,imx21-wdt
+ - items:
+ - enum:
+ - fsl,imx8mm-wdt
+ - fsl,imx8mn-wdt
+ - fsl,imx8mp-wdt
+ - fsl,imx8mq-wdt
+ - const: fsl,imx21-wdt
reg:
maxItems: 1
--
2.17.1
Re: [REGRESSION] omapdrm/N900 display broken
Hi, On Tue, Aug 04, 2020 at 03:39:37PM +0300, Tomi Valkeinen wrote: > On 04/08/2020 15:13, Tomi Valkeinen wrote: > > Can you try to pinpoint a bit where the hang happens? Maybe add > > DRM/omapdrm debug prints, or perhaps sysrq works and it shows a lock > > that's in deadlock. > > Also, one data point would be to disable venc, e.g. set venc status to > "disabled" in dts. Disabling venc makes no difference. The hang happens in drm_fb_helper_initial_config(). I followed the "HANG DEBUGGING" tips in the function comment text and enabled fb.lockless_register_fb=1 to get more (serial) console output. Now I get this: [6.514739] omapdss_dss 4805.dss: supply vdda_video not found, using dummy regulator [6.566375] DSS: OMAP DSS rev 2.0 [6.571807] omapdss_dss 4805.dss: bound 48050400.dispc (ops dispc_component_ops) [6.580749] omapdrm omapdrm.0: DMM not available, disable DMM support [6.587982] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [6.626617] [ cut here ] [6.631774] WARNING: CPU: 0 PID: 18 at drivers/gpu/drm/drm_bridge.c:708 drm_atomic_helper_commit_modeset_enables+0x134/0x268 [6.643768] Modules linked in: [6.647033] CPU: 0 PID: 18 Comm: kworker/0:1 Tainted: G U 5.8.0-omap3-los_16068+-4-g2e7d4a7efefd-dirty #2 [6.658966] Hardware name: Nokia RX-51 board [6.663635] Workqueue: events deferred_probe_work_func [6.669097] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [6.677429] [] (show_stack) from [] (__warn+0xbc/0xd4) [6.684844] [] (__warn) from [] (warn_slowpath_fmt+0x60/0xb8) [6.692901] [] (warn_slowpath_fmt) from [] (drm_atomic_helper_commit_modeset_enables+0x134/0x268) [6.704254] [] (drm_atomic_helper_commit_modeset_enables) from [] (omap_atomic_commit_tail+0xb4/0xc0) [6.715972] [] (omap_atomic_commit_tail) from [] (commit_tail+0x9c/0x1a8) [6.725128] [] (commit_tail) from [] (drm_atomic_helper_commit+0x134/0x158) [6.734466] [] (drm_atomic_helper_commit) from [] (drm_client_modeset_commit_atomic+0x16c/0x208) [6.745727] [] (drm_client_modeset_commit_atomic) from [] (drm_client_modeset_commit_locked+0x58/0x184) [6.757629] [] (drm_client_modeset_commit_locked) from [] (drm_client_modeset_commit+0x24/0x40) [6.768798] [] (drm_client_modeset_commit) from [] (__drm_fb_helper_restore_fbdev_mode_unlocked+0xa0/0xc8) [6.780975] [] (__drm_fb_helper_restore_fbdev_mode_unlocked) from [] (drm_fb_helper_set_par+0x38/0x64) [6.792785] [] (drm_fb_helper_set_par) from [] (fbcon_init+0x3d4/0x568) [6.801757] [] (fbcon_init) from [] (visual_init+0xb8/0xfc) [6.809631] [] (visual_init) from [] (do_bind_con_driver+0x1e0/0x3bc) [6.818267] [] (do_bind_con_driver) from [] (do_take_over_console+0x138/0x1d8) [6.827880] [] (do_take_over_console) from [] (do_fbcon_takeover+0x74/0xd4) [6.837219] [] (do_fbcon_takeover) from [] (register_framebuffer+0x204/0x2d8) [6.846740] [] (register_framebuffer) from [] (__drm_fb_helper_initial_config_and_unlock+0x3a4/0x554) [6.858459] [] (__drm_fb_helper_initial_config_and_unlock) from [] (omap_fbdev_init+0x84/0xbc) [6.869537] [] (omap_fbdev_init) from [] (pdev_probe+0x580/0x7d8) [6.877807] [] (pdev_probe) from [] (platform_drv_probe+0x48/0x98) [6.886291] [] (platform_drv_probe) from [] (really_probe+0x1e0/0x344) [6.895172] [] (really_probe) from [] (driver_probe_device+0x5c/0xb4) [6.903961] [] (driver_probe_device) from [] (bus_for_each_drv+0x80/0xc4) [6.913085] [] (bus_for_each_drv) from [] (__device_attach+0xd0/0x13c) [6.921966] [] (__device_attach) from [] (bus_probe_device+0x84/0x8c) [6.930725] [] (bus_probe_device) from [] (device_add+0x3f0/0x740) [6.939086] [] (device_add) from [] (platform_device_add+0x110/0x204) [6.947845] [] (platform_device_add) from [] (platform_device_register_full+0xcc/0x110) [6.958282] [] (platform_device_register_full) from [] (dss_bind+0x80/0xa8) [6.967620] [] (dss_bind) from [] (try_to_bring_up_master+0x160/0x1a8) [6.976501] [] (try_to_bring_up_master) from [] (component_master_add_with_match+0xc4/0xf8) [6.987304] [] (component_master_add_with_match) from [] (dss_probe+0x494/0x55c) [6.997100] [] (dss_probe) from [] (platform_drv_probe+0x48/0x98) [7.005523] [] (platform_drv_probe) from [] (really_probe+0x1e0/0x344) [7.014404] [] (really_probe) from [] (driver_probe_device+0x5c/0xb4) [7.023193] [] (driver_probe_device) from [] (bus_for_each_drv+0x80/0xc4) [7.032348] [] (bus_for_each_drv) from [] (__device_attach+0xd0/0x13c) [7.041198] [] (__device_attach) from [] (bus_probe_device+0x84/0x8c) [7.049987] [] (bus_probe_device) from [] (deferred_probe_work_func+0x64/0x90) [7.059570] [] (deferred_probe_work_func) from [] (process_one_work+0x1d4/0x440) [7.069213] [] (process_one_work) from [] (worker_thread+0x260/0x590) [7.078002] [] (worker_th
Re: [PATCH RFC 2/2] ARM: dts: imx: add devicetree for Tolino Shine 2 HD
On Sun, 23 Aug 2020 09:42:31 +0800
Shawn Guo wrote:
> On Sat, Aug 15, 2020 at 09:33:36PM +0200, Andreas Kemnade wrote:
> > This adds a devicetree for the Tolino Shine 2 HD Ebook reader. It is based
> > on boards marked with "37NB-E60QF0+4A2". It is equipped with an i.MX6SL
> > SoC.
> >
> > Expected to work:
> > - Buttons
> > - Wifi
> > - Touchscreen
> > - LED
> > - uSD
> > - USB
> > - RTC
> >
> > Not working due to missing drivers:
> > - Backlight (requires NTXEC driver)
> > - EPD
> >
> > Not working due to unknown reasons:
> > - deep sleep (echo standby >/sys/power/state works),
> > wakeup fails when imx_gpc_pre_suspend(true) was called.
> >
> > Signed-off-by: Andreas Kemnade
> > ---
> > Reason for RFC: The suspend trouble might be caused by bad devicetree.
> > But as the devicetree is already useful I decided to submit it.
> >
> > arch/arm/boot/dts/Makefile | 1 +
> > arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts | 582 +++
> > 2 files changed, 583 insertions(+)
> > create mode 100644 arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index e6a1cac0bfc7..c65fa3852246 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -581,6 +581,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> > imx6qp-zii-rdu2.dtb
> > dtb-$(CONFIG_SOC_IMX6SL) += \
> > imx6sl-evk.dtb \
> > + imx6sl-tolino-shine2hd.dtb \
> > imx6sl-tolino-shine3.dtb \
> > imx6sl-warp.dtb
> > dtb-$(CONFIG_SOC_IMX6SLL) += \
> > diff --git a/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
> > b/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
> > new file mode 100644
> > index ..7b28e19a1d98
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/imx6sl-tolino-shine2hd.dts
> > @@ -0,0 +1,582 @@
> > +// SPDX-License-Identifier: (GPL-2.0)
> > +/*
> > + * Device tree for the Tolino Shine 2 HD ebook reader
> > + *
> > + * Name on mainboard is: 37NB-E60QF0+4A2
> > + * Serials start with: E60QF2
> > + *
> > + * Copyright 2020 Andreas Kemnade
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include
> > +#include
> > +#include "imx6sl.dtsi"
> > +
> > +/ {
> > + model = "Tolino Shine 2 HD";
> > + compatible = "kobo,tolino-shine2hd", "fsl,imx6sl";
> > +
> > + chosen {
> > + stdout-path = &uart1;
> > + };
> > +
> > + gpio_keys: gpio-keys {
> > + compatible = "gpio-keys";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_gpio_keys>;
> > +
> > + cover {
> > + label = "Cover";
> > + gpios = <&gpio5 12 GPIO_ACTIVE_LOW>;
> > + linux,code = ;
> > + linux,input-type = ;
> > + wakeup-source;
> > + };
> > +
> > + fl {
> > + label = "Frontlight";
> > + gpios = <&gpio3 26 GPIO_ACTIVE_LOW>;
> > + linux,code = ;
> > + };
> > +
> > + home {
> > + label = "Home";
> > + gpios = <&gpio3 25 GPIO_ACTIVE_LOW>;
> > + linux,code = ;
> > + };
> > +
> > + power {
> > + label = "Power";
> > + gpios = <&gpio5 8 GPIO_ACTIVE_LOW>;
> > + linux,code = ;
> > + wakeup-source;
> > + };
> > + };
> > +
> > + leds: leds {
> > + compatible = "gpio-leds";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_led>;
> > +
> > + on {
> > + label = "tolinoshine2hd:white:on";
> > + gpios = <&gpio5 13 GPIO_ACTIVE_LOW>;
> > + linux,default-trigger = "timer";
> > + };
> > + };
> > +
> > + memory@8000 {
> > + device_type = "memory";
> > + reg = <0x8000 0x2000>;
> > + };
> > +
> > + reg_wifi: regulator-wifi {
> > + compatible = "regulator-fixed";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_wifi_power>;
> > + regulator-name = "SD3_SPWR";
> > + regulator-min-microvolt = <300>;
> > + regulator-max-microvolt = <300>;
> > + gpio = <&gpio4 29 GPIO_ACTIVE_HIGH>;
>
> Missing enable-active-high?
>
no. I should rather use GPIO_ACTIVE_LOW to avoid that confusion.
corresponding code in vendor kernel is the function
_ntx_wifi_power_ctrl()
Regards,
Andreas
Re: [PATCH] drm/bridge/tc358775: Fix for PTR_ERR
Thanks Sam.
On Sun, Aug 23, 2020 at 8:35 PM Sam Ravnborg wrote:
>
> On Sun, Aug 16, 2020 at 11:20:41AM +0530, Vinay Simha BN wrote:
> > passing zero to 'PTR_ERR'
> >
> > Reported-by: kernel test robot
> > Signed-off-by: Vinay Simha BN
>
> Applied to drm-misc-next - thanks.
>
> Sam
>
> > ---
> > drivers/gpu/drm/bridge/tc358775.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/tc358775.c
> > b/drivers/gpu/drm/bridge/tc358775.c
> > index 7da15cd..d951cdc 100644
> > --- a/drivers/gpu/drm/bridge/tc358775.c
> > +++ b/drivers/gpu/drm/bridge/tc358775.c
> > @@ -684,7 +684,7 @@ static int tc_probe(struct i2c_client *client, const
> > struct i2c_device_id *id)
> >
> > tc->vdd = devm_regulator_get(dev, "vdd-supply");
> > if (IS_ERR(tc->vdd)) {
> > - ret = PTR_ERR(tc->vddio);
> > + ret = PTR_ERR(tc->vdd);
> > dev_err(dev, "vdd-supply not found\n");
> > return ret;
> > }
> > --
> > 2.7.4
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
regards,
vinaysimha
Re: [PATCH v2] x86/hotplug: Silence APIC only after all irq's are migrated
Hi Thomas,
I was wondering if you got a chance to take a look at this fix?
I had some mail issues recently and they showed up at lore after 2
days. I wasn't sure if you got the original mail, or maybe it didn't
make it.
If you had a different way to fix it, we can try those out.
On Thu, Aug 20, 2020 at 05:42:03PM -0700, Ashok Raj wrote:
> When offlining CPUs, fixup_irqs() migrates all interrupts away from the
> outgoing CPU to an online CPU. It's always possible the device sent an
> interrupt to the previous CPU destination. Pending interrupt bit in IRR in
> LAPIC identifies such interrupts. apic_soft_disable() will not capture any
> new interrupts in IRR. This causes interrupts from device to be lost during
> CPU offline. The issue was found when explicitly setting MSI affinity to a
> CPU and immediately offlining it. It was simple to recreate with a USB
> ethernet device and doing I/O to it while the CPU is offlined. Lost
> interrupts happen even when Interrupt Remapping is enabled.
>
> Current code does apic_soft_disable() before migrating interrupts.
>
> native_cpu_disable()
> {
> ...
> apic_soft_disable();
> cpu_disable_common();
> --> fixup_irqs(); // Too late to capture anything in IRR.
> }
>
> Just flipping the above call sequence seems to hit the IRR checks
> and the lost interrupt is fixed for both legacy MSI and when
> interrupt remapping is enabled.
On another note, we have tested both with and without the read
after write when programming MSI addr/data on the device. It didn't
seem to change the results. But I think its a useful one to add
for correctness.
https://lore.kernel.org/lkml/878si6rx7f@nanos.tec.linutronix.de/
This bug been eluding for a while. Looking for your feedback.
>
> Fixes: 60dcaad5736f ("x86/hotplug: Silence APIC and NMI when CPU is dead")
> Link: https://lore.kernel.org/lkml/875zdarr4h@nanos.tec.linutronix.de/
> Reported-by: Evan Green
> Tested-by: Mathias Nyman
> Tested-by: Evan Green
> Reviewed-by: Evan Green
> Signed-off-by: Ashok Raj
> ---
> v2:
> - Typos and fixes suggested by Randy Dunlap
>
> To: linux-kernel@vger.kernel.org
> To: Thomas Gleixner
> Cc: Sukumar Ghorai
> Cc: Srikanth Nandamuri
> Cc: Evan Green
> Cc: Mathias Nyman
> Cc: Bjorn Helgaas
> Cc: sta...@vger.kernel.org
> ---
> arch/x86/kernel/smpboot.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index 27aa04a95702..3016c3b627ce 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -1594,13 +1594,20 @@ int native_cpu_disable(void)
> if (ret)
> return ret;
>
> + cpu_disable_common();
> /*
>* Disable the local APIC. Otherwise IPI broadcasts will reach
>* it. It still responds normally to INIT, NMI, SMI, and SIPI
> - * messages.
> + * messages. It's important to do apic_soft_disable() after
> + * fixup_irqs(), because fixup_irqs() called from cpu_disable_common()
> + * depends on IRR being set. After apic_soft_disable() CPU preserves
> + * currently set IRR/ISR but new interrupts will not set IRR.
> + * This causes interrupts sent to outgoing CPU before completion
> + * of IRQ migration to be lost. Check SDM Vol 3 "10.4.7.2 Local
> + * APIC State after It Has been Software Disabled" section for more
> + * details.
>*/
> apic_soft_disable();
> - cpu_disable_common();
>
> return 0;
> }
> --
> 2.7.4
>
[PATCH bpf-next v9 4/7] bpf: Split bpf_local_storage to bpf_sk_storage
From: KP Singh
A purely mechanical change:
bpf_sk_storage.c = bpf_sk_storage.c + bpf_local_storage.c
bpf_sk_storage.h = bpf_sk_storage.h + bpf_local_storage.h
Signed-off-by: KP Singh
---
include/linux/bpf_local_storage.h | 163
include/net/bpf_sk_storage.h | 61 +--
kernel/bpf/Makefile | 1 +
kernel/bpf/bpf_local_storage.c| 600 ++
net/core/bpf_sk_storage.c | 672 +-
5 files changed, 766 insertions(+), 731 deletions(-)
create mode 100644 include/linux/bpf_local_storage.h
create mode 100644 kernel/bpf/bpf_local_storage.c
diff --git a/include/linux/bpf_local_storage.h
b/include/linux/bpf_local_storage.h
new file mode 100644
index ..b2c9463f36a1
--- /dev/null
+++ b/include/linux/bpf_local_storage.h
@@ -0,0 +1,163 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2019 Facebook
+ * Copyright 2020 Google LLC.
+ */
+
+#ifndef _BPF_LOCAL_STORAGE_H
+#define _BPF_LOCAL_STORAGE_H
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BPF_LOCAL_STORAGE_CACHE_SIZE 16
+
+struct bpf_local_storage_map_bucket {
+ struct hlist_head list;
+ raw_spinlock_t lock;
+};
+
+/* Thp map is not the primary owner of a bpf_local_storage_elem.
+ * Instead, the container object (eg. sk->sk_bpf_storage) is.
+ *
+ * The map (bpf_local_storage_map) is for two purposes
+ * 1. Define the size of the "local storage". It is
+ *the map's value_size.
+ *
+ * 2. Maintain a list to keep track of all elems such
+ *that they can be cleaned up during the map destruction.
+ *
+ * When a bpf local storage is being looked up for a
+ * particular object, the "bpf_map" pointer is actually used
+ * as the "key" to search in the list of elem in
+ * the respective bpf_local_storage owned by the object.
+ *
+ * e.g. sk->sk_bpf_storage is the mini-map with the "bpf_map" pointer
+ * as the searching key.
+ */
+struct bpf_local_storage_map {
+ struct bpf_map map;
+ /* Lookup elem does not require accessing the map.
+*
+* Updating/Deleting requires a bucket lock to
+* link/unlink the elem from the map. Having
+* multiple buckets to improve contention.
+*/
+ struct bpf_local_storage_map_bucket *buckets;
+ u32 bucket_log;
+ u16 elem_size;
+ u16 cache_idx;
+};
+
+struct bpf_local_storage_data {
+ /* smap is used as the searching key when looking up
+* from the object's bpf_local_storage.
+*
+* Put it in the same cacheline as the data to minimize
+* the number of cachelines access during the cache hit case.
+*/
+ struct bpf_local_storage_map __rcu *smap;
+ u8 data[] __aligned(8);
+};
+
+/* Linked to bpf_local_storage and bpf_local_storage_map */
+struct bpf_local_storage_elem {
+ struct hlist_node map_node; /* Linked to bpf_local_storage_map */
+ struct hlist_node snode;/* Linked to bpf_local_storage */
+ struct bpf_local_storage __rcu *local_storage;
+ struct rcu_head rcu;
+ /* 8 bytes hole */
+ /* The data is stored in aother cacheline to minimize
+* the number of cachelines access during a cache hit.
+*/
+ struct bpf_local_storage_data sdata cacheline_aligned;
+};
+
+struct bpf_local_storage {
+ struct bpf_local_storage_data __rcu
*cache[BPF_LOCAL_STORAGE_CACHE_SIZE];
+ struct hlist_head list; /* List of bpf_local_storage_elem */
+ void *owner;/* The object that owns the above "list" of
+* bpf_local_storage_elem.
+*/
+ struct rcu_head rcu;
+ raw_spinlock_t lock;/* Protect adding/removing from the "list" */
+};
+
+/* U16_MAX is much more than enough for sk local storage
+ * considering a tcp_sock is ~2k.
+ */
+#define BPF_LOCAL_STORAGE_MAX_VALUE_SIZE \
+ min_t(u32, \
+ (KMALLOC_MAX_SIZE - MAX_BPF_STACK - \
+ sizeof(struct bpf_local_storage_elem)), \
+ (U16_MAX - sizeof(struct bpf_local_storage_elem)))
+
+#define SELEM(_SDATA)
\
+ container_of((_SDATA), struct bpf_local_storage_elem, sdata)
+#define SDATA(_SELEM) (&(_SELEM)->sdata)
+
+#define BPF_LOCAL_STORAGE_CACHE_SIZE 16
+
+struct bpf_local_storage_cache {
+ spinlock_t idx_lock;
+ u64 idx_usage_counts[BPF_LOCAL_STORAGE_CACHE_SIZE];
+};
+
+#define DEFINE_BPF_STORAGE_CACHE(name) \
+static struct bpf_local_storage_cache name = { \
+ .idx_lock = __SPIN_LOCK_UNLOCKED(name.idx_lock),\
+}
+
+u16 bpf_local_storage_cache_idx_get(struct bpf_local_storage_cache *cache);
+void bpf_local_storage_cache_
[PATCH bpf-next v9 6/7] bpf: Allow local storage to be used from LSM programs
From: KP Singh
Adds support for both bpf_{sk, inode}_storage_{get, delete} to be used
in LSM programs. These helpers are not used for tracing programs
(currently) as their usage is tied to the life-cycle of the object and
should only be used where the owning object won't be freed (when the
owning object is passed as an argument to the LSM hook). Thus, they
are safer to use in LSM hooks than tracing. Usage of local storage in
tracing programs will probably follow a per function based whitelist
approach.
Since the UAPI helper signature for bpf_sk_storage expect a bpf_sock,
it, leads to a compilation warning for LSM programs, it's also updated
to accept a void * pointer instead.
Acked-by: Martin KaFai Lau
Signed-off-by: KP Singh
---
include/net/bpf_sk_storage.h | 2 ++
include/uapi/linux/bpf.h | 7 +--
kernel/bpf/bpf_lsm.c | 21 -
net/core/bpf_sk_storage.c | 25 +
tools/include/uapi/linux/bpf.h | 7 +--
5 files changed, 57 insertions(+), 5 deletions(-)
diff --git a/include/net/bpf_sk_storage.h b/include/net/bpf_sk_storage.h
index 3c516dd07caf..119f4c9c3a9c 100644
--- a/include/net/bpf_sk_storage.h
+++ b/include/net/bpf_sk_storage.h
@@ -20,6 +20,8 @@ void bpf_sk_storage_free(struct sock *sk);
extern const struct bpf_func_proto bpf_sk_storage_get_proto;
extern const struct bpf_func_proto bpf_sk_storage_delete_proto;
+extern const struct bpf_func_proto sk_storage_get_btf_proto;
+extern const struct bpf_func_proto sk_storage_delete_btf_proto;
struct bpf_local_storage_elem;
struct bpf_sk_storage_diag;
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index b0504ab59a2e..c7f0a806932d 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -2808,7 +2808,7 @@ union bpf_attr {
*
* **-ERANGE** if resulting value was out of range.
*
- * void *bpf_sk_storage_get(struct bpf_map *map, struct bpf_sock *sk, void
*value, u64 flags)
+ * void *bpf_sk_storage_get(struct bpf_map *map, void *sk, void *value, u64
flags)
* Description
* Get a bpf-local-storage from a *sk*.
*
@@ -2824,6 +2824,9 @@ union bpf_attr {
* "type". The bpf-local-storage "type" (i.e. the *map*) is
* searched against all bpf-local-storages residing at *sk*.
*
+ * *sk* is a kernel **struct sock** pointer for LSM program.
+ * *sk* is a **struct bpf_sock** pointer for other program types.
+ *
* An optional *flags* (**BPF_SK_STORAGE_GET_F_CREATE**) can be
* used such that a new bpf-local-storage will be
* created if one does not exist. *value* can be used
@@ -2836,7 +2839,7 @@ union bpf_attr {
* **NULL** if not found or there was an error in adding
* a new bpf-local-storage.
*
- * long bpf_sk_storage_delete(struct bpf_map *map, struct bpf_sock *sk)
+ * long bpf_sk_storage_delete(struct bpf_map *map, void *sk)
* Description
* Delete a bpf-local-storage from a *sk*.
* Return
diff --git a/kernel/bpf/bpf_lsm.c b/kernel/bpf/bpf_lsm.c
index fb278144e9fd..9cd1428c7199 100644
--- a/kernel/bpf/bpf_lsm.c
+++ b/kernel/bpf/bpf_lsm.c
@@ -11,6 +11,8 @@
#include
#include
#include
+#include
+#include
/* For every LSM hook that allows attachment of BPF programs, declare a nop
* function where a BPF program can be attached.
@@ -45,10 +47,27 @@ int bpf_lsm_verify_prog(struct bpf_verifier_log *vlog,
return 0;
}
+static const struct bpf_func_proto *
+bpf_lsm_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
+{
+ switch (func_id) {
+ case BPF_FUNC_inode_storage_get:
+ return &bpf_inode_storage_get_proto;
+ case BPF_FUNC_inode_storage_delete:
+ return &bpf_inode_storage_delete_proto;
+ case BPF_FUNC_sk_storage_get:
+ return &sk_storage_get_btf_proto;
+ case BPF_FUNC_sk_storage_delete:
+ return &sk_storage_delete_btf_proto;
+ default:
+ return tracing_prog_func_proto(func_id, prog);
+ }
+}
+
const struct bpf_prog_ops lsm_prog_ops = {
};
const struct bpf_verifier_ops lsm_verifier_ops = {
- .get_func_proto = tracing_prog_func_proto,
+ .get_func_proto = bpf_lsm_func_proto,
.is_valid_access = btf_ctx_access,
};
diff --git a/net/core/bpf_sk_storage.c b/net/core/bpf_sk_storage.c
index f29d9a9b4ea4..55fae03b4cc3 100644
--- a/net/core/bpf_sk_storage.c
+++ b/net/core/bpf_sk_storage.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
DEFINE_BPF_STORAGE_CACHE(sk_cache);
@@ -377,6 +378,30 @@ const struct bpf_func_proto bpf_sk_storage_delete_proto = {
.arg2_type = ARG_PTR_TO_SOCKET,
};
+BTF_ID_LIST(sk_storage_btf_ids)
+BTF_ID_UNUSED
+BTF_ID(struct, sock)
+
+const struct bpf_func_proto sk_storage_get_btf_proto = {
+ .func = bpf_sk_storage_get,
+ .gpl_only
[PATCH bpf-next v9 0/7] Generalizing bpf_local_storage
From: KP Singh
# v8 -> v9
- Fixed reference count logic for files for inode maps.
- Other fixes suggested by Martin
- Rebase
# v7 -> v8
- Fixed an issue with BTF IDs for helpers and added
bpf_<>_storage_delete to selftests to catch this issue.
- Update comments about refcounts and grabbed a refcount to the open
file for userspace inode helpers.
- Rebase.
# v6 -> v7
- Updated the series to use Martin's POC patch:
https://lore.kernel.org/bpf/20200725013047.4006241-1-ka...@fb.com/
I added a Co-developed-by: tag, but would need Martin's Signoff
(was not sure of the procedure here).
- Rebase.
# v5 -> v6
- Fixed a build warning.
- Rebase.
# v4 -> v5
- Split non-functional changes into separate commits.
- Updated the cache macros to be simpler.
- Fixed some bugs noticed by Martin.
- Updated the userspace map functions to use an fd for lookups, updates
and deletes.
- Rebase.
# v3 -> v4
- Fixed a missing include to bpf_sk_storage.h in bpf_sk_storage.c
- Fixed some functions that were not marked as static which led to
W=1 compilation warnings.
# v2 -> v3
* Restructured the code as per Martin's suggestions:
- Common functionality in bpf_local_storage.c
- bpf_sk_storage functionality remains in net/bpf_sk_storage.
- bpf_inode_storage is kept separate as it is enabled only with
CONFIG_BPF_LSM.
* A separate cache for inode and sk storage with macros to define it.
* Use the ops style approach as suggested by Martin instead of the
enum + switch style.
* Added the inode map to bpftool bash completion and docs.
* Rebase and indentation fixes.
# v1 -> v2
* Use the security blob pointer instead of dedicated member in
struct inode.
* Better code re-use as suggested by Alexei.
* Dropped the inode count arithmetic as pointed out by Alexei.
* Minor bug fixes and rebase.
bpf_sk_storage can already be used by some BPF program types to annotate
socket objects. These annotations are managed with the life-cycle of the
object (i.e. freed when the object is freed) which makes BPF programs
much simpler and less prone to errors and leaks.
This patch series:
* Generalizes the bpf_sk_storage infrastructure to allow easy
implementation of local storage for other objects
* Implements local storage for inodes
* Makes both bpf_{sk, inode}_storage available to LSM programs.
Local storage is safe to use in LSM programs as the attachment sites are
limited and the owning object won't be freed, however, this is not the
case for tracing. Usage in tracing is expected to follow a white-list
based approach similar to the d_path helper
(https://lore.kernel.org/bpf/20200506132946.2164578-1-jo...@kernel.org).
Access to local storage would allow LSM programs to implement stateful
detections like detecting the unlink of a running executable from the
examples shared as a part of the KRSI series
https://lore.kernel.org/bpf/20200329004356.27286-1-kpsi...@chromium.org/
and
https://github.com/sinkap/linux-krsi/blob/patch/v1/examples/samples/bpf/lsm_detect_exec_unlink.c
KP Singh (7):
bpf: Renames in preparation for bpf_local_storage
bpf: Generalize caching for sk_storage.
bpf: Generalize bpf_sk_storage
bpf: Split bpf_local_storage to bpf_sk_storage
bpf: Implement bpf_local_storage for inodes
bpf: Allow local storage to be used from LSM programs
bpf: Add selftests for local_storage
include/linux/bpf.h | 8 +
include/linux/bpf_local_storage.h | 163
include/linux/bpf_lsm.h | 29 +
include/linux/bpf_types.h | 3 +
include/net/bpf_sk_storage.h | 14 +
include/net/sock.h| 4 +-
include/uapi/linux/bpf.h | 53 +-
kernel/bpf/Makefile | 2 +
kernel/bpf/bpf_inode_storage.c| 265 ++
kernel/bpf/bpf_local_storage.c| 600 +
kernel/bpf/bpf_lsm.c | 21 +-
kernel/bpf/syscall.c | 3 +-
kernel/bpf/verifier.c | 10 +
net/core/bpf_sk_storage.c | 830 +++---
security/bpf/hooks.c | 7 +
.../bpf/bpftool/Documentation/bpftool-map.rst | 2 +-
tools/bpf/bpftool/bash-completion/bpftool | 3 +-
tools/bpf/bpftool/map.c | 3 +-
tools/include/uapi/linux/bpf.h| 53 +-
tools/lib/bpf/libbpf_probes.c | 5 +-
.../bpf/prog_tests/test_local_storage.c | 60 ++
.../selftests/bpf/progs/local_storage.c | 140 +++
22 files changed, 1566 insertions(+), 712 deletions(-)
create mode 100644 include/linux/bpf_local_storage.h
create mode 100644 kernel/bpf/bpf_inode_storage.c
create mode 100644 kernel/bpf/bpf_local_storage.c
create mode 100644 tools/testing/selftests/bpf/prog_tests/test_local_storage.c
create mode 100644 tools/testing/selftests/bpf/progs/local_storage.c
--
2.28.0.297.g1956fa8
[PATCH bpf-next v9 3/7] bpf: Generalize bpf_sk_storage
From: KP Singh
Refactor the functionality in bpf_sk_storage.c so that concept of
storage linked to kernel objects can be extended to other objects like
inode, task_struct etc.
Each new local storage will still be a separate map and provide its own
set of helpers. This allows for future object specific extensions and
still share a lot of the underlying implementation.
This includes the changes suggested by Martin in:
https://lore.kernel.org/bpf/20200725013047.4006241-1-ka...@fb.com/
adding new map operations to support bpf_local_storage maps:
* storages for different kernel objects to optionally have different
memory charging strategy (map_local_storage_charge,
map_local_storage_uncharge)
* Functionality to extract the storage pointer from a pointer to the
owning object (map_owner_storage_ptr)
Co-developed-by: Martin KaFai Lau
Signed-off-by: KP Singh
---
include/linux/bpf.h| 8 ++
include/net/bpf_sk_storage.h | 52 +++
include/uapi/linux/bpf.h | 8 +-
net/core/bpf_sk_storage.c | 238 +
tools/include/uapi/linux/bpf.h | 8 +-
5 files changed, 228 insertions(+), 86 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 81f38e2fda78..8c443b93ac11 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -34,6 +34,8 @@ struct btf_type;
struct exception_table_entry;
struct seq_operations;
struct bpf_iter_aux_info;
+struct bpf_local_storage;
+struct bpf_local_storage_map;
extern struct idr btf_idr;
extern spinlock_t btf_idr_lock;
@@ -104,6 +106,12 @@ struct bpf_map_ops {
__poll_t (*map_poll)(struct bpf_map *map, struct file *filp,
struct poll_table_struct *pts);
+ /* Functions called by bpf_local_storage maps */
+ int (*map_local_storage_charge)(struct bpf_local_storage_map *smap,
+ void *owner, u32 size);
+ void (*map_local_storage_uncharge)(struct bpf_local_storage_map *smap,
+ void *owner, u32 size);
+ struct bpf_local_storage __rcu ** (*map_owner_storage_ptr)(void *owner);
/* BTF name and id of struct allocated by map_alloc */
const char * const map_btf_name;
int *map_btf_id;
diff --git a/include/net/bpf_sk_storage.h b/include/net/bpf_sk_storage.h
index 950c5aaba15e..9e631b5466e3 100644
--- a/include/net/bpf_sk_storage.h
+++ b/include/net/bpf_sk_storage.h
@@ -3,8 +3,15 @@
#ifndef _BPF_SK_STORAGE_H
#define _BPF_SK_STORAGE_H
+#include
+#include
+#include
#include
#include
+#include
+#include
+#include
+#include
struct sock;
@@ -13,6 +20,7 @@ void bpf_sk_storage_free(struct sock *sk);
extern const struct bpf_func_proto bpf_sk_storage_get_proto;
extern const struct bpf_func_proto bpf_sk_storage_delete_proto;
+struct bpf_local_storage_elem;
struct bpf_sk_storage_diag;
struct sk_buff;
struct nlattr;
@@ -34,6 +42,50 @@ u16 bpf_local_storage_cache_idx_get(struct
bpf_local_storage_cache *cache);
void bpf_local_storage_cache_idx_free(struct bpf_local_storage_cache *cache,
u16 idx);
+/* Helper functions for bpf_local_storage */
+int bpf_local_storage_map_alloc_check(union bpf_attr *attr);
+
+struct bpf_local_storage_map *bpf_local_storage_map_alloc(union bpf_attr
*attr);
+
+struct bpf_local_storage_data *
+bpf_local_storage_lookup(struct bpf_local_storage *local_storage,
+struct bpf_local_storage_map *smap,
+bool cacheit_lockit);
+
+void bpf_local_storage_map_free(struct bpf_local_storage_map *smap);
+
+int bpf_local_storage_map_check_btf(const struct bpf_map *map,
+ const struct btf *btf,
+ const struct btf_type *key_type,
+ const struct btf_type *value_type);
+
+void bpf_selem_link_storage_nolock(struct bpf_local_storage *local_storage,
+ struct bpf_local_storage_elem *selem);
+
+bool bpf_selem_unlink_storage_nolock(struct bpf_local_storage *local_storage,
+struct bpf_local_storage_elem *selem,
+bool uncharge_omem);
+
+void bpf_selem_unlink(struct bpf_local_storage_elem *selem);
+
+void bpf_selem_link_map(struct bpf_local_storage_map *smap,
+ struct bpf_local_storage_elem *selem);
+
+void bpf_selem_unlink_map(struct bpf_local_storage_elem *selem);
+
+struct bpf_local_storage_elem *
+bpf_selem_alloc(struct bpf_local_storage_map *smap, void *owner, void *value,
+ bool charge_mem);
+
+int
+bpf_local_storage_alloc(void *owner,
+ struct bpf_local_storage_map *smap,
+ struct bpf_local_storage_elem *first_selem);
+
+struct bpf_local_storage_data *
+bpf_local_storage_update(void *owner, struct bpf_local_storage_map *smap,
+void
[PATCH bpf-next v9 5/7] bpf: Implement bpf_local_storage for inodes
From: KP Singh
Similar to bpf_local_storage for sockets, add local storage for inodes.
The life-cycle of storage is managed with the life-cycle of the inode.
i.e. the storage is destroyed along with the owning inode.
The BPF LSM allocates an __rcu pointer to the bpf_local_storage in the
security blob which are now stackable and can co-exist with other LSMs.
Signed-off-by: KP Singh
---
include/linux/bpf_lsm.h | 29 ++
include/linux/bpf_types.h | 3 +
include/uapi/linux/bpf.h | 38 +++
kernel/bpf/Makefile | 1 +
kernel/bpf/bpf_inode_storage.c| 265 ++
kernel/bpf/syscall.c | 3 +-
kernel/bpf/verifier.c | 10 +
security/bpf/hooks.c | 7 +
.../bpf/bpftool/Documentation/bpftool-map.rst | 2 +-
tools/bpf/bpftool/bash-completion/bpftool | 3 +-
tools/bpf/bpftool/map.c | 3 +-
tools/include/uapi/linux/bpf.h| 38 +++
tools/lib/bpf/libbpf_probes.c | 5 +-
13 files changed, 401 insertions(+), 6 deletions(-)
create mode 100644 kernel/bpf/bpf_inode_storage.c
diff --git a/include/linux/bpf_lsm.h b/include/linux/bpf_lsm.h
index af74712af585..aaacb6aafc87 100644
--- a/include/linux/bpf_lsm.h
+++ b/include/linux/bpf_lsm.h
@@ -17,9 +17,28 @@
#include
#undef LSM_HOOK
+struct bpf_storage_blob {
+ struct bpf_local_storage __rcu *storage;
+};
+
+extern struct lsm_blob_sizes bpf_lsm_blob_sizes;
+
int bpf_lsm_verify_prog(struct bpf_verifier_log *vlog,
const struct bpf_prog *prog);
+static inline struct bpf_storage_blob *bpf_inode(
+ const struct inode *inode)
+{
+ if (unlikely(!inode->i_security))
+ return NULL;
+
+ return inode->i_security + bpf_lsm_blob_sizes.lbs_inode;
+}
+
+extern const struct bpf_func_proto bpf_inode_storage_get_proto;
+extern const struct bpf_func_proto bpf_inode_storage_delete_proto;
+void bpf_inode_storage_free(struct inode *inode);
+
#else /* !CONFIG_BPF_LSM */
static inline int bpf_lsm_verify_prog(struct bpf_verifier_log *vlog,
@@ -28,6 +47,16 @@ static inline int bpf_lsm_verify_prog(struct
bpf_verifier_log *vlog,
return -EOPNOTSUPP;
}
+static inline struct bpf_storage_blob *bpf_inode(
+ const struct inode *inode)
+{
+ return NULL;
+}
+
+static inline void bpf_inode_storage_free(struct inode *inode)
+{
+}
+
#endif /* CONFIG_BPF_LSM */
#endif /* _LINUX_BPF_LSM_H */
diff --git a/include/linux/bpf_types.h b/include/linux/bpf_types.h
index a52a5688418e..2e6f568377f1 100644
--- a/include/linux/bpf_types.h
+++ b/include/linux/bpf_types.h
@@ -107,6 +107,9 @@ BPF_MAP_TYPE(BPF_MAP_TYPE_SK_STORAGE, sk_storage_map_ops)
BPF_MAP_TYPE(BPF_MAP_TYPE_SOCKMAP, sock_map_ops)
BPF_MAP_TYPE(BPF_MAP_TYPE_SOCKHASH, sock_hash_ops)
#endif
+#ifdef CONFIG_BPF_LSM
+BPF_MAP_TYPE(BPF_MAP_TYPE_INODE_STORAGE, inode_storage_map_ops)
+#endif
BPF_MAP_TYPE(BPF_MAP_TYPE_CPUMAP, cpu_map_ops)
#if defined(CONFIG_XDP_SOCKETS)
BPF_MAP_TYPE(BPF_MAP_TYPE_XSKMAP, xsk_map_ops)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index f1a4a476586b..b0504ab59a2e 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -155,6 +155,7 @@ enum bpf_map_type {
BPF_MAP_TYPE_DEVMAP_HASH,
BPF_MAP_TYPE_STRUCT_OPS,
BPF_MAP_TYPE_RINGBUF,
+ BPF_MAP_TYPE_INODE_STORAGE,
};
/* Note that tracing related programs such as
@@ -3395,6 +3396,41 @@ union bpf_attr {
* A non-negative value equal to or less than *size* on success,
* or a negative error in case of failure.
*
+ * void *bpf_inode_storage_get(struct bpf_map *map, void *inode, void *value,
u64 flags)
+ * Description
+ * Get a bpf_local_storage from an *inode*.
+ *
+ * Logically, it could be thought of as getting the value from
+ * a *map* with *inode* as the **key**. From this
+ * perspective, the usage is not much different from
+ * **bpf_map_lookup_elem**\ (*map*, **&**\ *inode*) except this
+ * helper enforces the key must be an inode and the map must also
+ * be a **BPF_MAP_TYPE_INODE_STORAGE**.
+ *
+ * Underneath, the value is stored locally at *inode* instead of
+ * the *map*. The *map* is used as the bpf-local-storage
+ * "type". The bpf-local-storage "type" (i.e. the *map*) is
+ * searched against all bpf_local_storage residing at *inode*.
+ *
+ * An optional *flags* (**BPF_LOCAL_STORAGE_GET_F_CREATE**) can be
+ * used such that a new bpf_local_storage will be
+ * created if one does not exist. *value* can be used
+ * together with **BPF_LOCAL_STORAGE_GET_F_CREATE** to specify
+ * the initial value of a bpf_local_storage. If *value* is
+
[PATCH bpf-next v9 1/7] bpf: Renames in preparation for bpf_local_storage
From: KP Singh
A purely mechanical change to split the renaming from the actual
generalization.
Flags/consts:
SK_STORAGE_CREATE_FLAG_MASK BPF_LOCAL_STORAGE_CREATE_FLAG_MASK
BPF_SK_STORAGE_CACHE_SIZE BPF_LOCAL_STORAGE_CACHE_SIZE
MAX_VALUE_SIZEBPF_LOCAL_STORAGE_MAX_VALUE_SIZE
Structs:
bucketbpf_local_storage_map_bucket
bpf_sk_storage_mapbpf_local_storage_map
bpf_sk_storage_data bpf_local_storage_data
bpf_sk_storage_elem bpf_local_storage_elem
bpf_sk_storagebpf_local_storage
The "sk" member in bpf_local_storage is also updated to "owner"
in preparation for changing the type to void * in a subsequent patch.
Functions:
selem_linked_to_skselem_linked_to_storage
selem_alloc bpf_selem_alloc
__selem_unlink_sk bpf_selem_unlink_storage_nolock
__selem_link_sk bpf_selem_link_storage_nolock
selem_unlink_sk __bpf_selem_unlink_storage
sk_storage_update bpf_local_storage_update
__sk_storage_lookup bpf_local_storage_lookup
bpf_sk_storage_map_free bpf_local_storage_map_free
bpf_sk_storage_map_alloc bpf_local_storage_map_alloc
bpf_sk_storage_map_alloc_checkbpf_local_storage_map_alloc_check
bpf_sk_storage_map_check_btf bpf_local_storage_map_check_btf
Acked-by: Martin KaFai Lau
Signed-off-by: KP Singh
---
include/net/sock.h| 4 +-
net/core/bpf_sk_storage.c | 488 +++---
2 files changed, 252 insertions(+), 240 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 064637d1ddf6..18423cc9cde8 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -246,7 +246,7 @@ struct sock_common {
/* public: */
};
-struct bpf_sk_storage;
+struct bpf_local_storage;
/**
*struct sock - network layer representation of sockets
@@ -517,7 +517,7 @@ struct sock {
void(*sk_destruct)(struct sock *sk);
struct sock_reuseport __rcu *sk_reuseport_cb;
#ifdef CONFIG_BPF_SYSCALL
- struct bpf_sk_storage __rcu *sk_bpf_storage;
+ struct bpf_local_storage __rcu *sk_bpf_storage;
#endif
struct rcu_head sk_rcu;
};
diff --git a/net/core/bpf_sk_storage.c b/net/core/bpf_sk_storage.c
index 281200dc0a01..f975e2d01207 100644
--- a/net/core/bpf_sk_storage.c
+++ b/net/core/bpf_sk_storage.c
@@ -12,33 +12,32 @@
#include
#include
-#define SK_STORAGE_CREATE_FLAG_MASK\
- (BPF_F_NO_PREALLOC | BPF_F_CLONE)
+#define BPF_LOCAL_STORAGE_CREATE_FLAG_MASK (BPF_F_NO_PREALLOC | BPF_F_CLONE)
-struct bucket {
+struct bpf_local_storage_map_bucket {
struct hlist_head list;
raw_spinlock_t lock;
};
-/* Thp map is not the primary owner of a bpf_sk_storage_elem.
- * Instead, the sk->sk_bpf_storage is.
+/* Thp map is not the primary owner of a bpf_local_storage_elem.
+ * Instead, the container object (eg. sk->sk_bpf_storage) is.
*
- * The map (bpf_sk_storage_map) is for two purposes
- * 1. Define the size of the "sk local storage". It is
+ * The map (bpf_local_storage_map) is for two purposes
+ * 1. Define the size of the "local storage". It is
*the map's value_size.
*
* 2. Maintain a list to keep track of all elems such
*that they can be cleaned up during the map destruction.
*
* When a bpf local storage is being looked up for a
- * particular sk, the "bpf_map" pointer is actually used
+ * particular object, the "bpf_map" pointer is actually used
* as the "key" to search in the list of elem in
- * sk->sk_bpf_storage.
+ * the respective bpf_local_storage owned by the object.
*
- * Hence, consider sk->sk_bpf_storage is the mini-map
- * with the "bpf_map" pointer as the searching key.
+ * e.g. sk->sk_bpf_storage is the mini-map with the "bpf_map" pointer
+ * as the searching key.
*/
-struct bpf_sk_storage_map {
+struct bpf_local_storage_map {
struct bpf_map map;
/* Lookup elem does not require accessing the map.
*
@@ -46,55 +45,57 @@ struct bpf_sk_storage_map {
* link/unlink the elem from the map. Having
* multiple buckets to improve contention.
*/
- struct bucket *buckets;
+ struct bpf_local_storage_map_bucket *buckets;
u32 bucket_log;
u16 elem_size;
u16 cache_idx;
};
-struct bpf_sk_storage_data {
+struct bpf_local_storage_data {
/* smap is used as the searching key when looking up
-* from sk->sk_bpf_storage.
+* from the object's bpf_local_storage.
*
* Put it in the same cacheline as the data to minimize
* the number of cachelines access during the cache hit case.
*/
- struct bpf_sk_storage_map __rcu *smap;
+ struct bpf_local_storage_map __rcu *smap;
[PATCH bpf-next v9 7/7] bpf: Add selftests for local_storage
From: KP Singh
inode_local_storage:
* Hook to the file_open and inode_unlink LSM hooks.
* Create and unlink a temporary file.
* Store some information in the inode's bpf_local_storage during
file_open.
* Verify that this information exists when the file is unlinked.
sk_local_storage:
* Hook to the socket_post_create and socket_bind LSM hooks.
* Open and bind a socket and set the sk_storage in the
socket_post_create hook using the start_server helper.
* Verify if the information is set in the socket_bind hook.
Acked-by: Andrii Nakryiko
Signed-off-by: KP Singh
---
.../bpf/prog_tests/test_local_storage.c | 60
.../selftests/bpf/progs/local_storage.c | 140 ++
2 files changed, 200 insertions(+)
create mode 100644 tools/testing/selftests/bpf/prog_tests/test_local_storage.c
create mode 100644 tools/testing/selftests/bpf/progs/local_storage.c
diff --git a/tools/testing/selftests/bpf/prog_tests/test_local_storage.c
b/tools/testing/selftests/bpf/prog_tests/test_local_storage.c
new file mode 100644
index ..91cd6f357246
--- /dev/null
+++ b/tools/testing/selftests/bpf/prog_tests/test_local_storage.c
@@ -0,0 +1,60 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Copyright (C) 2020 Google LLC.
+ */
+
+#include
+#include
+
+#include "local_storage.skel.h"
+#include "network_helpers.h"
+
+int create_and_unlink_file(void)
+{
+ char fname[PATH_MAX] = "/tmp/fileXX";
+ int fd;
+
+ fd = mkstemp(fname);
+ if (fd < 0)
+ return fd;
+
+ close(fd);
+ unlink(fname);
+ return 0;
+}
+
+void test_test_local_storage(void)
+{
+ struct local_storage *skel = NULL;
+ int err, duration = 0, serv_sk = -1;
+
+ skel = local_storage__open_and_load();
+ if (CHECK(!skel, "skel_load", "lsm skeleton failed\n"))
+ goto close_prog;
+
+ err = local_storage__attach(skel);
+ if (CHECK(err, "attach", "lsm attach failed: %d\n", err))
+ goto close_prog;
+
+ skel->bss->monitored_pid = getpid();
+
+ err = create_and_unlink_file();
+ if (CHECK(err < 0, "exec_cmd", "err %d errno %d\n", err, errno))
+ goto close_prog;
+
+ CHECK(skel->data->inode_storage_result != 0, "inode_storage_result",
+ "inode_local_storage not set\n");
+
+ serv_sk = start_server(AF_INET6, SOCK_STREAM, NULL, 0, 0);
+ if (CHECK(serv_sk < 0, "start_server", "failed to start server\n"))
+ goto close_prog;
+
+ CHECK(skel->data->sk_storage_result != 0, "sk_storage_result",
+ "sk_local_storage not set\n");
+
+ close(serv_sk);
+
+close_prog:
+ local_storage__destroy(skel);
+}
diff --git a/tools/testing/selftests/bpf/progs/local_storage.c
b/tools/testing/selftests/bpf/progs/local_storage.c
new file mode 100644
index ..0758ba229ae0
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/local_storage.c
@@ -0,0 +1,140 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Copyright 2020 Google LLC.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+char _license[] SEC("license") = "GPL";
+
+#define DUMMY_STORAGE_VALUE 0xdeadbeef
+
+int monitored_pid = 0;
+int inode_storage_result = -1;
+int sk_storage_result = -1;
+
+struct dummy_storage {
+ __u32 value;
+};
+
+struct {
+ __uint(type, BPF_MAP_TYPE_INODE_STORAGE);
+ __uint(map_flags, BPF_F_NO_PREALLOC);
+ __type(key, int);
+ __type(value, struct dummy_storage);
+} inode_storage_map SEC(".maps");
+
+struct {
+ __uint(type, BPF_MAP_TYPE_SK_STORAGE);
+ __uint(map_flags, BPF_F_NO_PREALLOC | BPF_F_CLONE);
+ __type(key, int);
+ __type(value, struct dummy_storage);
+} sk_storage_map SEC(".maps");
+
+/* TODO Use vmlinux.h once BTF pruning for embedded types is fixed.
+ */
+struct sock {} __attribute__((preserve_access_index));
+struct sockaddr {} __attribute__((preserve_access_index));
+struct socket {
+ struct sock *sk;
+} __attribute__((preserve_access_index));
+
+struct inode {} __attribute__((preserve_access_index));
+struct dentry {
+ struct inode *d_inode;
+} __attribute__((preserve_access_index));
+struct file {
+ struct inode *f_inode;
+} __attribute__((preserve_access_index));
+
+
+SEC("lsm/inode_unlink")
+int BPF_PROG(unlink_hook, struct inode *dir, struct dentry *victim)
+{
+ __u32 pid = bpf_get_current_pid_tgid() >> 32;
+ struct dummy_storage *storage;
+
+ if (pid != monitored_pid)
+ return 0;
+
+ storage = bpf_inode_storage_get(&inode_storage_map, victim->d_inode, 0,
+BPF_SK_STORAGE_GET_F_CREATE);
+ if (!storage)
+ return 0;
+
+ if (storage->value == DUMMY_STORAGE_VALUE)
+ inode_storage_result = -1;
+
+ inode_storage_result =
+ bpf_inode_storage_delete(&inode_storage_map, victim->d_inode);
+
+ return 0;
+}
+
+SEC("lsm/socket
[PATCH bpf-next v9 2/7] bpf: Generalize caching for sk_storage.
From: KP Singh
Provide the a ability to define local storage caches on a per-object
type basis. The caches and caching indices for different objects should
not be inter-mixed as suggested in:
https://lore.kernel.org/bpf/20200630193441.kdwnkestulg5e...@kafai-mbp.dhcp.thefacebook.com/
"Caching a sk-storage at idx=0 of a sk should not stop an
inode-storage to be cached at the same idx of a inode."
Acked-by: Martin KaFai Lau
Signed-off-by: KP Singh
---
include/net/bpf_sk_storage.h | 19 +++
net/core/bpf_sk_storage.c| 31 +++
2 files changed, 34 insertions(+), 16 deletions(-)
diff --git a/include/net/bpf_sk_storage.h b/include/net/bpf_sk_storage.h
index 5036c94c0503..950c5aaba15e 100644
--- a/include/net/bpf_sk_storage.h
+++ b/include/net/bpf_sk_storage.h
@@ -3,6 +3,9 @@
#ifndef _BPF_SK_STORAGE_H
#define _BPF_SK_STORAGE_H
+#include
+#include
+
struct sock;
void bpf_sk_storage_free(struct sock *sk);
@@ -15,6 +18,22 @@ struct sk_buff;
struct nlattr;
struct sock;
+#define BPF_LOCAL_STORAGE_CACHE_SIZE 16
+
+struct bpf_local_storage_cache {
+ spinlock_t idx_lock;
+ u64 idx_usage_counts[BPF_LOCAL_STORAGE_CACHE_SIZE];
+};
+
+#define DEFINE_BPF_STORAGE_CACHE(name) \
+static struct bpf_local_storage_cache name = { \
+ .idx_lock = __SPIN_LOCK_UNLOCKED(name.idx_lock),\
+}
+
+u16 bpf_local_storage_cache_idx_get(struct bpf_local_storage_cache *cache);
+void bpf_local_storage_cache_idx_free(struct bpf_local_storage_cache *cache,
+ u16 idx);
+
#ifdef CONFIG_BPF_SYSCALL
int bpf_sk_storage_clone(const struct sock *sk, struct sock *newsk);
struct bpf_sk_storage_diag *
diff --git a/net/core/bpf_sk_storage.c b/net/core/bpf_sk_storage.c
index f975e2d01207..ec61ee7c7ee4 100644
--- a/net/core/bpf_sk_storage.c
+++ b/net/core/bpf_sk_storage.c
@@ -14,6 +14,8 @@
#define BPF_LOCAL_STORAGE_CREATE_FLAG_MASK (BPF_F_NO_PREALLOC | BPF_F_CLONE)
+DEFINE_BPF_STORAGE_CACHE(sk_cache);
+
struct bpf_local_storage_map_bucket {
struct hlist_head list;
raw_spinlock_t lock;
@@ -78,10 +80,6 @@ struct bpf_local_storage_elem {
#define SELEM(_SDATA) \
container_of((_SDATA), struct bpf_local_storage_elem, sdata)
#define SDATA(_SELEM) (&(_SELEM)->sdata)
-#define BPF_LOCAL_STORAGE_CACHE_SIZE 16
-
-static DEFINE_SPINLOCK(cache_idx_lock);
-static u64 cache_idx_usage_counts[BPF_LOCAL_STORAGE_CACHE_SIZE];
struct bpf_local_storage {
struct bpf_local_storage_data __rcu
*cache[BPF_LOCAL_STORAGE_CACHE_SIZE];
@@ -521,16 +519,16 @@ static int sk_storage_delete(struct sock *sk, struct
bpf_map *map)
return 0;
}
-static u16 cache_idx_get(void)
+u16 bpf_local_storage_cache_idx_get(struct bpf_local_storage_cache *cache)
{
u64 min_usage = U64_MAX;
u16 i, res = 0;
- spin_lock(&cache_idx_lock);
+ spin_lock(&cache->idx_lock);
for (i = 0; i < BPF_LOCAL_STORAGE_CACHE_SIZE; i++) {
- if (cache_idx_usage_counts[i] < min_usage) {
- min_usage = cache_idx_usage_counts[i];
+ if (cache->idx_usage_counts[i] < min_usage) {
+ min_usage = cache->idx_usage_counts[i];
res = i;
/* Found a free cache_idx */
@@ -538,18 +536,19 @@ static u16 cache_idx_get(void)
break;
}
}
- cache_idx_usage_counts[res]++;
+ cache->idx_usage_counts[res]++;
- spin_unlock(&cache_idx_lock);
+ spin_unlock(&cache->idx_lock);
return res;
}
-static void cache_idx_free(u16 idx)
+void bpf_local_storage_cache_idx_free(struct bpf_local_storage_cache *cache,
+ u16 idx)
{
- spin_lock(&cache_idx_lock);
- cache_idx_usage_counts[idx]--;
- spin_unlock(&cache_idx_lock);
+ spin_lock(&cache->idx_lock);
+ cache->idx_usage_counts[idx]--;
+ spin_unlock(&cache->idx_lock);
}
/* Called by __sk_destruct() & bpf_sk_storage_clone() */
@@ -601,7 +600,7 @@ static void bpf_local_storage_map_free(struct bpf_map *map)
smap = (struct bpf_local_storage_map *)map;
- cache_idx_free(smap->cache_idx);
+ bpf_local_storage_cache_idx_free(&sk_cache, smap->cache_idx);
/* Note that this map might be concurrently cloned from
* bpf_sk_storage_clone. Wait for any existing bpf_sk_storage_clone
@@ -718,7 +717,7 @@ static struct bpf_map *bpf_local_storage_map_alloc(union
bpf_attr *attr)
smap->elem_size =
sizeof(struct bpf_local_storage_elem) + attr->value_size;
- smap->cache_idx = cache_idx_get();
+ smap->cache_idx = bpf_local_storage_cache_idx_get(&sk_cache);
return &smap->map;
}
--
2.28.0.297.g1956fa8f8d-goog
[PATCH 1/5] dt-bindings: arm: fsl: Add Beacon i.MX8M Mini Development Kit binding
Document the binding for Beacon EmbeddedWorks i.MX8M Mini Development Kit board. Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 6da9d734cdb7..37592e7bfee9 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -344,6 +344,7 @@ properties: - description: i.MX8MM based Boards items: - enum: + - beacon,imx8mm-beacon-kit # i.MX8MM Beacon Development Kit - fsl,imx8mm-evk# i.MX8MM EVK Board - const: fsl,imx8mm -- 2.17.1
[PATCH 2/5] arm64: dts: imx8mm-beacon-kit: Add missing build through Makefile
Add missing imx8mm-beacon-kit.dts object in Makefile so it will be build when building dtbs. Signed-off-by: Krzysztof Kozlowski --- arch/arm64/boot/dts/freescale/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile index a39f0a1723e0..903c0eb61290 100644 --- a/arch/arm64/boot/dts/freescale/Makefile +++ b/arch/arm64/boot/dts/freescale/Makefile @@ -28,6 +28,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-honeycomb.dtb dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-qds.dtb dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-rdb.dtb +dtb-$(CONFIG_ARCH_MXC) += imx8mm-beacon-kit.dtb dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb dtb-$(CONFIG_ARCH_MXC) += imx8mn-evk.dtb dtb-$(CONFIG_ARCH_MXC) += imx8mn-ddr4-evk.dtb -- 2.17.1
[PATCH 4/5] arm64: dts: imx8mm-beacon-som: Fix atmel,24c64 EEPROM compatible
Correct the EEPROM node compatible to match device tree schema (invalid
space, unknown ID) to fix dtbs_check warnings:
arch/arm64/boot/dts/freescale/imx8mm-beacon-kit.dt.yaml: eeprom@50:
compatible: ['microchip, at24c64d', 'atmel,24c64'] is not valid under any
of the given schemas
arch/arm64/boot/dts/freescale/imx8mm-beacon-kit.dt.yaml: eeprom@50:
compatible:0: 'microchip, at24c64d' does not match
'^[a-zA-Z][a-zA-Z0-9,+\\-._]+$'
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
index f627e82ad929..620a124dfb5f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
@@ -184,7 +184,7 @@
status = "okay";
eeprom@50 {
- compatible = "microchip, at24c64d", "atmel,24c64";
+ compatible = "microchip,24c64", "atmel,24c64";
pagesize = <32>;
read-only; /* Manufacturing EEPROM programmed at factory */
reg = <0x50>;
--
2.17.1
[PATCH 5/5] arm64: dts: imx8mm-evk: Align regulator names with schema
Device tree schema expects regulator names to be lowercase. This fixes
dtbs_check warnings like:
pmic@4b: regulators:LDO1:regulator-name:0: 'LDO1' does not match
'^ldo[1-6]$'
Signed-off-by: Krzysztof Kozlowski
---
arch/arm64/boot/dts/freescale/imx8mm-evk.dts | 22 ++--
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
index 0f1d7f8aeac4..b64b04f40b29 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dts
@@ -151,7 +151,7 @@
regulators {
buck1_reg: BUCK1 {
- regulator-name = "BUCK1";
+ regulator-name = "buck1";
regulator-min-microvolt = <70>;
regulator-max-microvolt = <130>;
regulator-boot-on;
@@ -160,7 +160,7 @@
};
buck2_reg: BUCK2 {
- regulator-name = "BUCK2";
+ regulator-name = "buck2";
regulator-min-microvolt = <70>;
regulator-max-microvolt = <130>;
regulator-boot-on;
@@ -172,7 +172,7 @@
buck3_reg: BUCK3 {
// BUCK5 in datasheet
- regulator-name = "BUCK3";
+ regulator-name = "buck3";
regulator-min-microvolt = <70>;
regulator-max-microvolt = <135>;
regulator-boot-on;
@@ -181,7 +181,7 @@
buck4_reg: BUCK4 {
// BUCK6 in datasheet
- regulator-name = "BUCK4";
+ regulator-name = "buck4";
regulator-min-microvolt = <300>;
regulator-max-microvolt = <330>;
regulator-boot-on;
@@ -190,7 +190,7 @@
buck5_reg: BUCK5 {
// BUCK7 in datasheet
- regulator-name = "BUCK5";
+ regulator-name = "buck5";
regulator-min-microvolt = <1605000>;
regulator-max-microvolt = <1995000>;
regulator-boot-on;
@@ -199,7 +199,7 @@
buck6_reg: BUCK6 {
// BUCK8 in datasheet
- regulator-name = "BUCK6";
+ regulator-name = "buck6";
regulator-min-microvolt = <80>;
regulator-max-microvolt = <140>;
regulator-boot-on;
@@ -207,7 +207,7 @@
};
ldo1_reg: LDO1 {
- regulator-name = "LDO1";
+ regulator-name = "ldo1";
regulator-min-microvolt = <160>;
regulator-max-microvolt = <330>;
regulator-boot-on;
@@ -215,7 +215,7 @@
};
ldo2_reg: LDO2 {
- regulator-name = "LDO2";
+ regulator-name = "ldo2";
regulator-min-microvolt = <80>;
regulator-max-microvolt = <90>;
regulator-boot-on;
@@ -223,7 +223,7 @@
};
ldo3_reg: LDO3 {
- regulator-name = "LDO3";
+ regulator-name = "ldo3";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <330>;
regulator-boot-on;
@@ -231,7 +231,7 @@
};
ldo4_reg: LDO4 {
- regulator-name = "LDO4";
+ regulator-name = "ldo4";
regulator-min-microvolt = <90>;
regulator-max-microvolt = <180>;
regulator-boot-on;
@@ -239,7 +239,7 @@
};
ldo6_reg: LDO6 {
- regulator-name = "LDO6";
+ regulator-name = "ldo6";
regulator-min-microvolt = <90>;
regulator-max-microvolt = <180>;
[PATCH 3/5] arm64: dts: imx8mm-beacon-som: Align regulator names with schema
Device tree schema expects regulator names to be lowercase. This fixes
dtbs_check warnings like:
pmic@4b: regulators:LDO1:regulator-name:0: 'LDO1' does not match
'^ldo[1-6]$'
Signed-off-by: Krzysztof Kozlowski
---
.../boot/dts/freescale/imx8mm-beacon-som.dtsi | 22 +--
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
b/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
index 94911b1707ef..f627e82ad929 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
@@ -79,7 +79,7 @@
regulators {
buck1_reg: BUCK1 {
- regulator-name = "BUCK1";
+ regulator-name = "buck1";
regulator-min-microvolt = <70>;
regulator-max-microvolt = <130>;
regulator-boot-on;
@@ -88,7 +88,7 @@
};
buck2_reg: BUCK2 {
- regulator-name = "BUCK2";
+ regulator-name = "buck2";
regulator-min-microvolt = <70>;
regulator-max-microvolt = <130>;
regulator-boot-on;
@@ -100,7 +100,7 @@
buck3_reg: BUCK3 {
// BUCK5 in datasheet
- regulator-name = "BUCK3";
+ regulator-name = "buck3";
regulator-min-microvolt = <70>;
regulator-max-microvolt = <135>;
regulator-boot-on;
@@ -109,7 +109,7 @@
buck4_reg: BUCK4 {
// BUCK6 in datasheet
- regulator-name = "BUCK4";
+ regulator-name = "buck4";
regulator-min-microvolt = <300>;
regulator-max-microvolt = <330>;
regulator-boot-on;
@@ -118,7 +118,7 @@
buck5_reg: BUCK5 {
// BUCK7 in datasheet
- regulator-name = "BUCK5";
+ regulator-name = "buck5";
regulator-min-microvolt = <1605000>;
regulator-max-microvolt = <1995000>;
regulator-boot-on;
@@ -127,7 +127,7 @@
buck6_reg: BUCK6 {
// BUCK8 in datasheet
- regulator-name = "BUCK6";
+ regulator-name = "buck6";
regulator-min-microvolt = <80>;
regulator-max-microvolt = <140>;
regulator-boot-on;
@@ -135,7 +135,7 @@
};
ldo1_reg: LDO1 {
- regulator-name = "LDO1";
+ regulator-name = "ldo1";
regulator-min-microvolt = <160>;
regulator-max-microvolt = <330>;
regulator-boot-on;
@@ -143,7 +143,7 @@
};
ldo2_reg: LDO2 {
- regulator-name = "LDO2";
+ regulator-name = "ldo2";
regulator-min-microvolt = <80>;
regulator-max-microvolt = <90>;
regulator-boot-on;
@@ -151,7 +151,7 @@
};
ldo3_reg: LDO3 {
- regulator-name = "LDO3";
+ regulator-name = "ldo3";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <330>;
regulator-boot-on;
@@ -159,7 +159,7 @@
};
ldo4_reg: LDO4 {
- regulator-name = "LDO4";
+ regulator-name = "ldo4";
regulator-min-microvolt = <90>;
regulator-max-microvolt = <180>;
regulator-boot-on;
@@ -167,7 +167,7 @@
};
ldo6_reg: LDO6 {
- regulator-name = "LDO6";
+ regulator-name = "ldo6";
regulator-min-microvolt = <90>;
regulator-max-m
[PATCH] blk-mq: use BLK_MQ_NO_TAG for no tag
Replace various magic -1 constants for tags with BLK_MQ_NO_TAG.
Signed-off-by: Xianting Tian
---
block/blk-core.c | 4 ++--
block/blk-mq-sched.c | 2 +-
include/linux/blk-mq.h | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index d9d632639..c7eaf7504 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -116,8 +116,8 @@ void blk_rq_init(struct request_queue *q, struct request
*rq)
rq->__sector = (sector_t) -1;
INIT_HLIST_NODE(&rq->hash);
RB_CLEAR_NODE(&rq->rb_node);
- rq->tag = -1;
- rq->internal_tag = -1;
+ rq->tag = BLK_MQ_NO_TAG;
+ rq->internal_tag = BLK_MQ_NO_TAG;
rq->start_time_ns = ktime_get_ns();
rq->part = NULL;
refcount_set(&rq->ref, 1);
diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
index a19cdf159..439481f59 100644
--- a/block/blk-mq-sched.c
+++ b/block/blk-mq-sched.c
@@ -522,7 +522,7 @@ void blk_mq_sched_insert_request(struct request *rq, bool
at_head,
goto run;
}
- WARN_ON(e && (rq->tag != -1));
+ WARN_ON(e && (rq->tag != BLK_MQ_NO_TAG));
if (blk_mq_sched_bypass_insert(hctx, !!e, rq)) {
/*
diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index 9d2d5ad36..161d8a0e6 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -569,7 +569,7 @@ static inline void *blk_mq_rq_to_pdu(struct request *rq)
static inline blk_qc_t request_to_qc_t(struct blk_mq_hw_ctx *hctx,
struct request *rq)
{
- if (rq->tag != -1)
+ if (rq->tag != BLK_MQ_NO_TAG)
return rq->tag | (hctx->queue_num << BLK_QC_T_SHIFT);
return rq->internal_tag | (hctx->queue_num << BLK_QC_T_SHIFT) |
--
2.17.1
Re: [PATCH v1] perf_event_open.2: update the man page with CAP_PERFMON related information
Hello Alexey, Could you look at the question below and update the patch. On 2/17/20 9:18 AM, Alexey Budankov wrote: Extend perf_event_open 2 man page with the information about CAP_PERFMON capability designed to secure performance monitoring and observability operation in a system according to the principle of least privilege [1] (POSIX IEEE 1003.1e, 2.2.2.39). [1] https://sites.google.com/site/fullycapable/, posix_1003.1e-990310.pdf Signed-off-by: Alexey Budankov --- man2/perf_event_open.2 | 27 +++ 1 file changed, 27 insertions(+) diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2 index 89d267c02..e9aab2ca1 100644 --- a/man2/perf_event_open.2 +++ b/man2/perf_event_open.2 @@ -98,6 +98,8 @@ when running on the specified CPU. .BR "pid == \-1" " and " "cpu >= 0" This measures all processes/threads on the specified CPU. This requires +.B CAP_PERFMON +or .B CAP_SYS_ADMIN capability or a .I /proc/sys/kernel/perf_event_paranoid @@ -2920,6 +2922,8 @@ to hold the result. This allows attaching a Berkeley Packet Filter (BPF) program to an existing kprobe tracepoint event. You need +.B CAP_PERFMON +or .B CAP_SYS_ADMIN privileges to use this ioctl. .IP @@ -2962,6 +2966,8 @@ have multiple events attached to a tracepoint. Querying this value on one tracepoint event returns the id of all BPF programs in all events attached to the tracepoint. You need +.B CAP_PERFMON +or .B CAP_SYS_ADMIN privileges to use this ioctl. .IP @@ -3170,6 +3176,8 @@ it was expecting. .TP .B EACCES Returned when the requested event requires +.B CAP_PERFMON +or .B CAP_SYS_ADMIN permissions (or a more permissive perf_event paranoid setting). Some common cases where an unprivileged process @@ -3291,6 +3299,8 @@ setting is specified. It can also happen, as with .BR EACCES , when the requested event requires +.B CAP_PERFMON +or .B CAP_SYS_ADMIN permissions (or a more permissive perf_event paranoid setting). This includes setting a breakpoint on a kernel address, @@ -3321,6 +3331,23 @@ The official way of knowing if support is enabled is checking for the existence of the file .IR /proc/sys/kernel/perf_event_paranoid . +.PP +.B CAP_PERFMON +capability (since Linux X.Y) provides secure approach to What's the version? +performance monitoring and observability operations in a system +according to the principal of least privilege (POSIX IEEE 1003.1e). +Accessing system performance monitoring and observability operations +using +.B CAP_PERFMON +capability singly, without the rest of +.B CAP_SYS_ADMIN +credentials, excludes chances to misuse the credentials and makes I think that wording like "using CAP_PERFMON rather than the much more powerful CAP_SYS_ADMIN..." +the operations more secure. +.B CAP_SYS_ADMIN +usage for secure system performance monitoring and observability +is discouraged with respect to +.B CAP_PERFMON +capability. .SH BUGS The .B F_SETOWN_EX Thanks, Michael
Re: kernel BUG at kernel/fork.c:LINE!
On 8/7/20 2:16 PM, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit:fffe3ae0 Merge tag 'for-linus-hmm' of git://git.kernel.org.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1194d90a90 > kernel config: https://syzkaller.appspot.com/x/.config?x=18bb86f2e4ebfda2 > dashboard link: https://syzkaller.appspot.com/bug?extid=3776ecd80aac504e6085 > compiler: gcc (GCC) 10.1.0-syz 20200507 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+3776ecd80aac504e6...@syzkaller.appspotmail.com Is this fixed by commit 991e7673859ed41e7ba83c8c4e57afe8cfebe314 Author: Shakeel Butt Date: Thu Aug 6 23:21:37 2020 -0700 mm: memcontrol: account kernel stack per node since the BUG_ON() at line 390 is removed by this patch. > [ cut here ] > kernel BUG at kernel/fork.c:390! > invalid opcode: [#1] PREEMPT SMP KASAN > CPU: 0 PID: 5239 Comm: syz-executor.1 Not tainted 5.8.0-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > RIP: 0010:account_kernel_stack+0x297/0x320 kernel/fork.c:390 > Code: 89 e2 be 23 00 00 00 48 89 ef c1 e2 05 e8 81 9e 75 00 48 83 c4 10 5b 5d > 41 5c 41 5d 41 5e 41 5f e9 ae c9 2f 00 e8 a9 c9 2f 00 <0f> 0b e8 f2 50 6f 00 > e9 d2 fd ff ff e8 98 c9 2f 00 48 c7 c6 20 24 > RSP: 0018:c90015e4f850 EFLAGS: 00010216 > RAX: 01f4 RBX: RCX: c90017983000 > RDX: 0004 RSI: 81445327 RDI: 0005 > RBP: R08: 0001 R09: 8880a2ef9663 > R10: 0008 R11: R12: > R13: 8880001b2280 R14: 88809e4fa840 R15: > FS: 7f7f035e5700() GS:8880ae60() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 001b2fd3 CR3: 9b747000 CR4: 001506f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Call Trace: > release_task_stack kernel/fork.c:447 [inline] > put_task_stack+0xc4/0x230 kernel/fork.c:459 > finish_task_switch+0x52a/0x750 kernel/sched/core.c:3649 > context_switch kernel/sched/core.c:3781 [inline] > __schedule+0x8ed/0x21e0 kernel/sched/core.c:4527 > schedule+0xd0/0x2a0 kernel/sched/core.c:4602 > freezable_schedule include/linux/freezer.h:172 [inline] > futex_wait_queue_me+0x2a7/0x570 kernel/futex.c:2588 > futex_wait+0x1df/0x560 kernel/futex.c:2690 > do_futex+0x15b/0x1a60 kernel/futex.c:3749 > __do_sys_futex kernel/futex.c:3810 [inline] > __se_sys_futex kernel/futex.c:3778 [inline] > __x64_sys_futex+0x378/0x4e0 kernel/futex.c:3778 > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > RIP: 0033:0x45ccd9 > Code: 2d b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 > 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f > 83 fb b5 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > RSP: 002b:7f7f035e4cf8 EFLAGS: 0246 ORIG_RAX: 00ca > RAX: ffda RBX: 0078bfa8 RCX: 0045ccd9 > RDX: RSI: 0080 RDI: 0078bfa8 > RBP: 0078bfa0 R08: R09: > R10: R11: 0246 R12: 0078bfac > R13: 7fff896cb67f R14: 7f7f035e59c0 R15: 0078bfac > Modules linked in: > ---[ end trace ff14b6c5822b8142 ]--- > RIP: 0010:account_kernel_stack+0x297/0x320 kernel/fork.c:390 > Code: 89 e2 be 23 00 00 00 48 89 ef c1 e2 05 e8 81 9e 75 00 48 83 c4 10 5b 5d > 41 5c 41 5d 41 5e 41 5f e9 ae c9 2f 00 e8 a9 c9 2f 00 <0f> 0b e8 f2 50 6f 00 > e9 d2 fd ff ff e8 98 c9 2f 00 48 c7 c6 20 24 > RSP: 0018:c90015e4f850 EFLAGS: 00010216 > RAX: 01f4 RBX: RCX: c90017983000 > RDX: 0004 RSI: 81445327 RDI: 0005 > RBP: R08: 0001 R09: 8880a2ef9663 > R10: 0008 R11: R12: > R13: 8880001b2280 R14: 88809e4fa840 R15: > FS: 7f7f035e5700() GS:8880ae60() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 001b2fd3 CR3: 9b747000 CR4: 001506f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > > > --- > This report is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this issue. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > -- ~Ran
Re: [PATCH v1 5/6] dt-bindings: mfd: ene-kb3930: Document power-supplies and monitored-battery properties
Hi,
On Sun, Aug 23, 2020 at 05:08:45PM +0300, Dmitry Osipenko wrote:
> Battery could be connected to the controller and in this case controller
> will provide a battery-monitor function.
>
> The power-supplies phandle property is needed in order to describe the
> power supply which is used for charging of the battery, this allows to
> determine whither battery is charging or discharging, depending on the
> supply state.
>
> The monitored-battery phandle provides information about the battery cell
> characteristics.
I believe it would be better if you created a new binding document
instead of reusing this one -- the hardware part iseems to be a
different one and the firmware it runs seems to be behaving totally
differently than the usual ENE firmware [1].
[1] This eneec.c seems to be coming from ENE, so I'm assuming it's a
good enough description of how their firmware behaves:
https://git.kernel.org/pub/scm/linux/kernel/git/lkundrak/linux-mmp3-dell-ariel.git/tree/drivers/input/serio/eneec.c
Cheers
Lubo
> Signed-off-by: Dmitry Osipenko
> ---
> .../devicetree/bindings/mfd/ene-kb3930.yaml| 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml
> b/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml
> index 5a1c4a959d9c..435728054f3a 100644
> --- a/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml
> +++ b/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml
> @@ -29,6 +29,8 @@ properties:
> description: GPIO used with the shutdown protocol on Ariel
> maxItems: 2
>
> + monitored-battery: true
> + power-supplies: true
>system-power-controller: true
>
> required:
> @@ -41,6 +43,19 @@ examples:
>- |
> #include
>
> +battery: battery-cell {
> +compatible = "simple-battery";
> +charge-full-design-microamp-hours = <326>;
> +energy-full-design-microwatt-hours = <2400>;
> +operating-range-celsius = <0 40>;
> +};
> +
> +mains: ac-adapter {
> + compatible = "gpio-charger";
> + charger-type = "mains";
> + gpios = <&gpio 125 GPIO_ACTIVE_LOW>;
> +};
> +
> i2c {
>#address-cells = <1>;
>#size-cells = <0>;
> @@ -52,6 +67,9 @@ examples:
>
> off-gpios = <&gpio 126 GPIO_ACTIVE_HIGH>,
> <&gpio 127 GPIO_ACTIVE_HIGH>;
> +
> +monitored-battery = <&battery>;
> +power-supplies = <&mains>;
>};
> };
>
> --
> 2.27.0
>
[likely PATCH] media: lmedm04: Fix misuse of comma
There's a comma used instead of a semicolon that causes multiple
statements to be executed after an if instead of just the intended
single statement.
Replace the comma with a semicolon.
Signed-off-by: Joe Perches
---
Untested, but really likely to be a defect given the indentation.
Found using Julia Lawall's (and my) coccinelle script.
https://lore.kernel.org/lkml/alpine.DEB.2.22.394.2008201856110.2524@hadrien/
drivers/media/usb/dvb-usb-v2/lmedm04.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb-v2/lmedm04.c
b/drivers/media/usb/dvb-usb-v2/lmedm04.c
index 8a3c0eeed959..cce431f34f61 100644
--- a/drivers/media/usb/dvb-usb-v2/lmedm04.c
+++ b/drivers/media/usb/dvb-usb-v2/lmedm04.c
@@ -391,7 +391,7 @@ static int lme2510_int_read(struct dvb_usb_adapter *adap)
ep = usb_pipe_endpoint(d->udev, lme_int->lme_urb->pipe);
if (usb_endpoint_type(&ep->desc) == USB_ENDPOINT_XFER_BULK)
- lme_int->lme_urb->pipe = usb_rcvbulkpipe(d->udev, 0xa),
+ lme_int->lme_urb->pipe = usb_rcvbulkpipe(d->udev, 0xa);
usb_submit_urb(lme_int->lme_urb, GFP_ATOMIC);
info("INT Interrupt Service Started");
Re: [PATCH v1 1/6] mfd: Add driver for Embedded Controller found on Acer Iconia Tab A500
Hello,
On Sun, Aug 23, 2020 at 05:08:41PM +0300, Dmitry Osipenko wrote:
> Acer Iconia Tab A500 is an Android tablet device, it has ENE KB930
> Embedded Controller which provides battery-gauge, LED, GPIO and some
> other functions. The EC uses firmware that is specifically customized
> for Acer A500. This patch adds MFD driver for the Embedded Controller
> which allows to power-off / reboot the A500 device, it also provides
> a common register read/write API that will be used by the sub-devices.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/mfd/Kconfig | 10 ++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/acer-ec-a500.c | 196 +++
> include/linux/mfd/acer-ec-a500.h | 80 +
> 4 files changed, 287 insertions(+)
> create mode 100644 drivers/mfd/acer-ec-a500.c
> create mode 100644 include/linux/mfd/acer-ec-a500.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 33df0837ab41..9e5cf88a52d8 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -2062,6 +2062,16 @@ config MFD_KHADAS_MCU
> additional drivers must be enabled in order to use the functionality
> of the device.
>
> +config MFD_ACER_A500_EC
> + tristate "Embedded Controller driver for Acer Iconia Tab A500"
> + depends on (I2C_TEGRA && ARCH_TEGRA_2x_SOC) || COMPILE_TEST
This seems to also depend on I2C and OF. Perhaps I2C_TEGRA and
ARCH_TEGRA_2x_SOC imply that, but it could lead to build failures with
COMPILE_TEST=y.
> + select MFD_CORE
> + help
> + Support for Acer Iconia Tab A500 Embedded Controller.
> +
> + The controller itself is ENE KB930, it is running firmware
> + customized for the specific needs of the Acer A500 hardware.
> +
> menu "Multimedia Capabilities Port drivers"
> depends on ARCH_SA1100
>
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index a60e5f835283..6e3a6162ad94 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -262,5 +262,6 @@ obj-$(CONFIG_MFD_ROHM_BD71828)+= rohm-bd71828.o
> obj-$(CONFIG_MFD_ROHM_BD718XX) += rohm-bd718x7.o
> obj-$(CONFIG_MFD_STMFX) += stmfx.o
> obj-$(CONFIG_MFD_KHADAS_MCU) += khadas-mcu.o
> +obj-$(CONFIG_MFD_ACER_A500_EC) += acer-ec-a500.o
>
> obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o
> diff --git a/drivers/mfd/acer-ec-a500.c b/drivers/mfd/acer-ec-a500.c
> new file mode 100644
> index ..f75bb60ab408
> --- /dev/null
> +++ b/drivers/mfd/acer-ec-a500.c
> @@ -0,0 +1,196 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * MFD driver for Acer Iconia Tab A500 Embedded Controller.
> + *
> + * Copyright 2020 GRATE-driver project.
> + *
> + * Based on downstream driver from Acer Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define A500_EC_I2C_ERR_TIMEOUT 500
> +
> +/* cmd delay ms */
> +A500_EC_COMMAND(SHUTDOWN,0x52, 1000);
> +A500_EC_COMMAND(WARM_REBOOT, 0x54, 1000);
> +A500_EC_COMMAND(COLD_REBOOT, 0x55, 1000);
> +
> +static struct a500_ec *a500_ec_scratch;
If this is only used for power_off, please rename it. I've been told to
do so in my driver: https://lore.kernel.org/lkml/20200519104933.GX271301@dell/
> +
> +static void a500_ec_delay(unsigned int delay_ms)
> +{
> + /* interrupts could be disabled on shutdown or reboot */
> + if (irqs_disabled())
> + mdelay(delay_ms);
> + else
> + msleep(delay_ms);
> +}
> +
> +int a500_ec_read_locked(struct a500_ec *ec_chip,
> + const struct a500_ec_cmd *cmd_desc)
Any reason you're exporting these to the cell drivers instead of using
regmap?
I think regmap would also help you with the locking if you set .lock() and
.unlock() callbacks in regmap_config.
> +{
> + struct i2c_client *client = ec_chip->client;
> + unsigned int retries = 5;
> + s32 ret = 0;
> +
> + while (retries-- > 0) {
> + ret = i2c_smbus_read_word_data(client, cmd_desc->cmd);
> + if (ret >= 0)
> + break;
> +
> + a500_ec_delay(A500_EC_I2C_ERR_TIMEOUT);
> + }
> +
> + if (ret < 0) {
> + dev_err(&client->dev, "i2c read command 0x%x failed: %d\n",
> + cmd_desc->cmd, ret);
> + return ret;
> + }
> +
> + a500_ec_delay(cmd_desc->post_delay);
> +
> + return le16_to_cpu(ret);
> +}
> +EXPORT_SYMBOL_GPL(a500_ec_read_locked);
> +
> +int a500_ec_write_locked(struct a500_ec *ec_chip,
> + const struct a500_ec_cmd *cmd_desc, u16 value)
> +{
> + struct i2c_client *client = ec_chip->client;
> + unsigned int retries = 5;
> + s32 ret = 0;
> +
> + while (retries-- > 0) {
> + ret = i2c_smbus_write_word_data(client, cmd_desc->cmd,
> + le16_to_cpu(value));
> +
Re: [GIT pull] perf/urgent for v5.9-rc2
On Sun, Aug 23, 2020 at 1:26 AM Thomas Gleixner wrote: > > A single update for perf on x86 which ass support for the > broken down bandwith counters. Spot the freudian slip.. Linus
Re: [PATCH v1 4/6] dt-bindings: mfd: ene-kb3930: Add compatibles for KB930 and Acer A500
On Sun, Aug 23, 2020 at 05:08:44PM +0300, Dmitry Osipenko wrote: > The ENE KB930 hardware is compatible with KB3930. > > Acer A500 Iconia Tab is Android tablet device, it has KB930 controller > that is running firmware specifically customized for the needs of the > Acer A500 hardware. This means that firmware interface isn't re-usable > by other non-Acer devices. Some akin models of Acer tablets should be > able to re-use the FW interface of A500 model, like A200 for example. > > This patch adds the new compatibles to the binding. I've responded to patch 5/6 with what should've been said here [1]. Sorry for the confusion. In any case please consider adding a new binding file instead of modifying the kb3930 binding doc. It would also remove a dependency on my patch set which should have slipped out of maintainers' radar. [1] https://lore.kernel.org/lkml/20200823180041.GB209852@demiurge.local/ Take care Lubo > > Signed-off-by: Dmitry Osipenko > --- > Documentation/devicetree/bindings/mfd/ene-kb3930.yaml | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml > b/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml > index 074243c40891..5a1c4a959d9c 100644 > --- a/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml > +++ b/Documentation/devicetree/bindings/mfd/ene-kb3930.yaml > @@ -17,8 +17,11 @@ properties: >compatible: > items: >- enum: > +- acer,a500-iconia-ec # Acer A500 Iconia tablet device > - dell,wyse-ariel-ec # Dell Wyse Ariel board (3020) > - - const: ene,kb3930 > + - enum: > +- ene,kb3930 > +- ene,kb930 >reg: > maxItems: 1 > > -- > 2.27.0 >
Re: [GIT pull] x86/urgent for v5.9-rc2
On Sun, Aug 23, 2020 at 1:26 AM Thomas Gleixner wrote: > > Remove the RDPID optimization, which is not even > backed by numbers from the paranoid entry path instead. Ugh, that's sad. I'd expect the LSL to be quite a bit slower than the RDPID on raw hardware, since LSL has to go out to the GDT. And I don't think we need the GDT for anything else normally, so it's not even going to be cached. Oh well. Linus
Re: [GIT] Networking
The pull request you sent on Sat, 22 Aug 2020 19:19:48 -0700 (PDT): > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git refs/heads/master has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/9d045ed1ebe1a6115d3fa9930c5371defb31d95a Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.9-3 tag
The pull request you sent on Sun, 23 Aug 2020 22:50:13 +1000: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-5.9-3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/cb95712138ec5e480db5160b41172bbc6f6494cc Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT pull] efi/urgent for v5.9-rc2
The pull request you sent on Sun, 23 Aug 2020 08:25:35 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > efi-urgent-2020-08-23 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/10c091b62e7fc3133d652b7212904348398b302e Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] EDAC urgent for v5.9-rc2
The pull request you sent on Sun, 23 Aug 2020 12:12:03 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git > tags/edac_urgent_for_v5.9_rc2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d9232cb79651c244f8679607b6e30c5230bcc967 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT pull] perf/urgent for v5.9-rc2
The pull request you sent on Sun, 23 Aug 2020 08:25:36 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > perf-urgent-2020-08-23 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/cea05c192b07b82a770816fc9d06031403cea164 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT pull] x86/urgent for v5.9-rc2
The pull request you sent on Sun, 23 Aug 2020 08:25:37 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > x86-urgent-2020-08-23 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/550c2129d93d5eb198835ac83c05ef672e8c491c Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT pull] core/urgent for v5.9-rc2
The pull request you sent on Sun, 23 Aug 2020 08:25:34 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > core-urgent-2020-08-23 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e99b2507baccca79394ec646e3d1a0884667ea98 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[PATCH V2] net: dsa: Add of_node_put() before break statement
Every iteration of for_each_child_of_node() decrements
the reference count of the previous node, however when control
is transferred from the middle of the loop, as in the case of
a return or break or goto, there is no decrement thus ultimately
resulting in a memory leak.
Fix a potential memory leak in mt7530.c by inserting of_node_put()
before the break statement.
Issue found with Coccinelle.
---
Changes in v2:
Add another of_node_put() in for_each_child_of_node() as pointed
out by Andrew.
---
Signed-off-by: Sumera Priyadarsini
---
drivers/net/dsa/mt7530.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 8dcb8a49ab67..e81198a65c26 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -1327,6 +1327,7 @@ mt7530_setup(struct dsa_switch *ds)
if (phy_node->parent == priv->dev->of_node->parent) {
ret = of_get_phy_mode(mac_np, &interface);
if (ret && ret != -ENODEV)
+ of_node_put(mac_np)
return ret;
id = of_mdio_parse_addr(ds->dev, phy_node);
if (id == 0)
@@ -1334,6 +1335,7 @@ mt7530_setup(struct dsa_switch *ds)
if (id == 4)
priv->p5_intf_sel = P5_INTF_SEL_PHY_P4;
}
+ of_node_put(mac_np);
of_node_put(phy_node);
break;
}
--
2.17.1
Re: [PATCH] watchdog: Fix double-free in watchdog_cdev_register
On 8/23/20 12:13 AM, Dinghao Liu wrote:
> When misc_register() fails, wd_data will be released by the
> release callback function watchdog_core_data_release(), so
> we don't need to free it again. But when watchdog_kworker is
> NULL, we should free wd_data to prevent memleak.
>
> Fixes: cb36e29bb0e4b ("watchdog: initialize device before misc_register")
> Signed-off-by: Dinghao Liu
> ---
> drivers/watchdog/watchdog_dev.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
> index 6798addabd5a..8ee78e26feb1 100644
> --- a/drivers/watchdog/watchdog_dev.c
> +++ b/drivers/watchdog/watchdog_dev.c
> @@ -994,8 +994,10 @@ static int watchdog_cdev_register(struct watchdog_device
> *wdd)
> wd_data->wdd = wdd;
> wdd->wd_data = wd_data;
>
> - if (IS_ERR_OR_NULL(watchdog_kworker))
> + if (IS_ERR_OR_NULL(watchdog_kworker)) {
> + kfree(wd_data);
This should be a separate patch, with
Fixes: 664a39236e718 ("watchdog: Introduce hardware maximum heartbeat in
watchdog core")
> return -ENODEV;
> + }
>
> device_initialize(&wd_data->dev);
> wd_data->dev.devt = MKDEV(MAJOR(watchdog_devt), wdd->id);
> @@ -1021,7 +1023,6 @@ static int watchdog_cdev_register(struct
> watchdog_device *wdd)
> pr_err("%s: a legacy watchdog module is
> probably present.\n",
> wdd->info->identity);
> old_wd_data = NULL;
> - kfree(wd_data);
Are you sure about this ? put_device() isn't called on &wd_data->dev
(unlike the code further below). How do you trigger the double free,
or, in other words, how is watchdog_core_data_release() ever called
in this code path ?
device_initialize() says:
NOTE: Use put_device() to give up your reference instead of freeing
@dev directly once you have called this function.
so it looks like put_device() should be called instead of kfree().
Thanks,
Guenter
> return err;
> }
> }
>
[PATCH v2] drm/etnaviv: fix external abort seen on GC600 rev 0x19
It looks like that this GPU core triggers an abort when
reading VIVS_HI_CHIP_PRODUCT_ID and/or VIVS_HI_CHIP_ECO_ID.
I looked at different versions of Vivante's kernel driver and did
not found anything about this issue or what feature flag can be
used. So go the simplest route and do not read these two registers
on the affected GPU core.
Signed-off-by: Christian Gmeiner
Reported-by: Josua Mayer
Fixes: 815e45bbd4d3 ("drm/etnaviv: determine product, customer and eco id")
Cc: sta...@vger.kernel.org
---
Changelog:
V2:
- use correct register for conditional reads.
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index d5a4cd85a0f6..c6404b8d067f 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -337,9 +337,16 @@ static void etnaviv_hw_identify(struct etnaviv_gpu *gpu)
gpu->identity.model = gpu_read(gpu, VIVS_HI_CHIP_MODEL);
gpu->identity.revision = gpu_read(gpu, VIVS_HI_CHIP_REV);
- gpu->identity.product_id = gpu_read(gpu,
VIVS_HI_CHIP_PRODUCT_ID);
gpu->identity.customer_id = gpu_read(gpu,
VIVS_HI_CHIP_CUSTOMER_ID);
- gpu->identity.eco_id = gpu_read(gpu, VIVS_HI_CHIP_ECO_ID);
+
+ /*
+* Reading these two registers on GC600 rev 0x19 result in a
+* unhandled fault: external abort on non-linefetch
+*/
+ if (!etnaviv_is_model_rev(gpu, GC600, 0x19)) {
+ gpu->identity.product_id = gpu_read(gpu,
VIVS_HI_CHIP_PRODUCT_ID);
+ gpu->identity.eco_id = gpu_read(gpu,
VIVS_HI_CHIP_ECO_ID);
+ }
/*
* HACK ALERT
--
2.26.2
Re: [PATCH] drm/etnaviv: fix external abort seen on GC600 rev 0x19
Hi > I have formally tested the patch with 5.7.10 - and it doesn't resolve > the issue - sadly :( > > From my testing, the reads on > VIVS_HI_CHIP_PRODUCT_ID > VIVS_HI_CHIP_ECO_ID > need to be conditional - while > VIVS_HI_CHIP_CUSTOMER_ID > seems to be okay. > Uhh.. okay.. just send a V2 - thanks for testing :) -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info/privacypolicy
Re: [PATCH V2] net: dsa: Add of_node_put() before break statement
> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> index 8dcb8a49ab67..e81198a65c26 100644
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
> @@ -1327,6 +1327,7 @@ mt7530_setup(struct dsa_switch *ds)
> if (phy_node->parent == priv->dev->of_node->parent) {
> ret = of_get_phy_mode(mac_np, &interface);
> if (ret && ret != -ENODEV)
> + of_node_put(mac_np)
> return ret;
> id = of_mdio_parse_addr(ds->dev, phy_node);
> if (id == 0)
You are missing some { }. And a ; . I'm surprised gcc did not warn
you!
Andrew
Re: [PATCH] drm/etnaviv: fix external abort seen on GC600 rev 0x19
On Sun, Aug 23, 2020 at 09:10:25PM +0200, Christian Gmeiner wrote: > Hi > > > I have formally tested the patch with 5.7.10 - and it doesn't resolve > > the issue - sadly :( > > > > From my testing, the reads on > > VIVS_HI_CHIP_PRODUCT_ID > > VIVS_HI_CHIP_ECO_ID > > need to be conditional - while > > VIVS_HI_CHIP_CUSTOMER_ID > > seems to be okay. > > > > Uhh.. okay.. just send a V2 - thanks for testing :) There is also something else going on with the GC600 - 5.4 worked fine, 5.8 doesn't - my 2D Xorg driver gets stuck waiting on a BO after just a couple of minutes. Looking in debugfs, there's a whole load of BOs that are listed as "active", yet the GPU is idle: 0002: A 0 ( 7) 8294400 0001: I 0 ( 1) 4096 0001: I 0 ( 1) 4096 0001: I 0 ( 1) 327680 0001: A 0 ( 7) 8388608 0001: I 0 ( 1) 8388608 0001: I 0 ( 1) 8388608 0001: A 0 ( 7) 8388608 0001: A 0 ( 3) 8388608 0001: A 0 ( 4) 8388608 0001: A 0 ( 3) 8388608 0001: A 0 ( 3) 8388608 0001: A 0 ( 3) 8388608 0001: A 0 ( 3) 8388608 Total 38 objects, 293842944 bytes My guess is there's something up with the way a job completes that's causing the BOs not to be marked inactive. I haven't yet been able to debug any further. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Re: [PATCH v1 1/6] mfd: Add driver for Embedded Controller found on Acer Iconia Tab A500
23.08.2020 21:16, Lubomir Rintel пишет:
> Hello,
...
>> +config MFD_ACER_A500_EC
>> +tristate "Embedded Controller driver for Acer Iconia Tab A500"
>> +depends on (I2C_TEGRA && ARCH_TEGRA_2x_SOC) || COMPILE_TEST
>
> This seems to also depend on I2C and OF. Perhaps I2C_TEGRA and
> ARCH_TEGRA_2x_SOC imply that, but it could lead to build failures with
> COMPILE_TEST=y.
Hello, Lubomir! You're right about the I2C because it could be compiled
as a loadable module, good catch! The OF seems should fine as-is.
...
>> +static struct a500_ec *a500_ec_scratch;
>
> If this is only used for power_off, please rename it. I've been told to
> do so in my driver: https://lore.kernel.org/lkml/20200519104933.GX271301@dell/
I don't mind to rename the variable, but not sure whether it will be a
worthwhile change since _scratch is also a common naming scheme among
MFD drivers. Please see max77620_scratch for example, which I added
about a year ago.
...
>> +int a500_ec_read_locked(struct a500_ec *ec_chip,
>> +const struct a500_ec_cmd *cmd_desc)
>
> Any reason you're exporting these to the cell drivers instead of using
> regmap?
>
> I think regmap would also help you with the locking if you set .lock() and
> .unlock() callbacks in regmap_config.
Yes, perhaps you're right. Right now I can't recall what stopped me from
using regmap. I'll give it a shot for v2, thank you for the suggestion!
...
>> +static struct notifier_block a500_ec_restart_handler = {
>> +.notifier_call = a500_ec_restart_notify,
>> +.priority = 200,
>
> What would happend if you didn't set priority explicitly?
Then the Tegra's default CPU soft-reset handler will be used for
rebooting [1].
[1]
https://elixir.bootlin.com/linux/v5.9-rc1/source/drivers/soc/tegra/pmc.c#L977
...
>> +MODULE_LICENSE("GPL v2");
>
> MODULE_LICENSE("GPL");
>
> Your SPDX tag suggests newer versions of GPL than v2 are okay.
Okay! I'll change this in v2, thanks.
...
>> +#define A500_EC_COMMAND(NAME, CMD, DELAY_MS)
>> \
>> +static const struct a500_ec_cmd A500_EC_##NAME = { \
>> +.cmd = CMD, \
>> +.post_delay = DELAY_MS, \
>> +}; \
>
> I think that the mfd driver should decide about the delay, not the cell
> drivers.
This should be a good idea, especially combined with the regmap, thanks!
[PATCH V3] net: dsa: Add of_node_put() before break and return statements
Every iteration of for_each_child_of_node() decrements
the reference count of the previous node, however when control
is transferred from the middle of the loop, as in the case of
a return or break or goto, there is no decrement thus ultimately
resulting in a memory leak.
Fix a potential memory leak in mt7530.c by inserting of_node_put()
before the break and return statements.
Issue found with Coccinelle.
---
Changes in v2:
Add another of_node_put() in for_each_child_of_node() as pointed
out by Andrew.
Changes in v3:
- Correct syntax errors
- Modify commit message
---
Signed-off-by: Sumera Priyadarsini
Signed-off-by: Sumera Priyadarsini
---
drivers/net/dsa/mt7530.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 8dcb8a49ab67..4b4701c69fe1 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -1326,14 +1326,17 @@ mt7530_setup(struct dsa_switch *ds)
if (phy_node->parent == priv->dev->of_node->parent) {
ret = of_get_phy_mode(mac_np, &interface);
- if (ret && ret != -ENODEV)
+ if (ret && ret != -ENODEV) {
+ of_node_put(mac_np);
return ret;
+ }
id = of_mdio_parse_addr(ds->dev, phy_node);
if (id == 0)
priv->p5_intf_sel = P5_INTF_SEL_PHY_P0;
if (id == 4)
priv->p5_intf_sel = P5_INTF_SEL_PHY_P4;
}
+ of_node_put(mac_np);
of_node_put(phy_node);
break;
}
--
2.17.1
Re: [PATCH v1 4/6] dt-bindings: mfd: ene-kb3930: Add compatibles for KB930 and Acer A500
23.08.2020 21:20, Lubomir Rintel пишет: > On Sun, Aug 23, 2020 at 05:08:44PM +0300, Dmitry Osipenko wrote: >> The ENE KB930 hardware is compatible with KB3930. >> >> Acer A500 Iconia Tab is Android tablet device, it has KB930 controller >> that is running firmware specifically customized for the needs of the >> Acer A500 hardware. This means that firmware interface isn't re-usable >> by other non-Acer devices. Some akin models of Acer tablets should be >> able to re-use the FW interface of A500 model, like A200 for example. >> >> This patch adds the new compatibles to the binding. > > I've responded to patch 5/6 with what should've been said here [1]. > Sorry for the confusion. > > In any case please consider adding a new binding file instead of > modifying the kb3930 binding doc. It would also remove a dependency on > my patch set which should have slipped out of maintainers' radar. > > [1] https://lore.kernel.org/lkml/20200823180041.GB209852@demiurge.local/ Hello, Lubomir! I was doing some research about the differences of KB3930 and KB930 before created this patch and my understanding is that the controllers are mostly identical. I've seen posts from people who replaced KB3930 with KB930 (and vice versa) on various notebooks and it worked, although not always. It's a very common practice to re-use binding in a case of a sibling hardware. Do you know what are the exact differences between KB3930 and KB930 which could justify having separate bindings? The firmware implementation varies a lot from device to device, and thus, each device needs to have its own driver in order to talk to the firmware, but hardware description (i.e. DT binding) should be common for all devices.
Re: [PATCH RESEND v1] ARM: dts: meson8: remove two invalid interrupt lines from the GPU node
On Sat, Aug 15, 2020 at 8:20 PM Martin Blumenstingl
wrote:
>
> The 3.10 vendor kernel defines the following GPU 20 interrupt lines:
> #define INT_MALI_GP AM_IRQ(160)
> #define INT_MALI_GP_MMU AM_IRQ(161)
> #define INT_MALI_PP AM_IRQ(162)
> #define INT_MALI_PMUAM_IRQ(163)
> #define INT_MALI_PP0AM_IRQ(164)
> #define INT_MALI_PP0_MMUAM_IRQ(165)
> #define INT_MALI_PP1AM_IRQ(166)
> #define INT_MALI_PP1_MMUAM_IRQ(167)
> #define INT_MALI_PP2AM_IRQ(168)
> #define INT_MALI_PP2_MMUAM_IRQ(169)
> #define INT_MALI_PP3AM_IRQ(170)
> #define INT_MALI_PP3_MMUAM_IRQ(171)
> #define INT_MALI_PP4AM_IRQ(172)
> #define INT_MALI_PP4_MMUAM_IRQ(173)
> #define INT_MALI_PP5AM_IRQ(174)
> #define INT_MALI_PP5_MMUAM_IRQ(175)
> #define INT_MALI_PP6AM_IRQ(176)
> #define INT_MALI_PP6_MMUAM_IRQ(177)
> #define INT_MALI_PP7AM_IRQ(178)
> #define INT_MALI_PP7_MMUAM_IRQ(179)
>
> However, the driver from the 3.10 vendor kernel does not use the
> following four interrupt lines:
> - INT_MALI_PP3
> - INT_MALI_PP3_MMU
> - INT_MALI_PP7
> - INT_MALI_PP7_MMU
>
> Drop the "pp3" and "ppmmu3" interrupt lines. This is also important
> because there is no matching entry in interrupt-names for it (meaning
> the "pp2" interrupt is actually assigned to the "pp3" interrupt line).
>
> Fixes: 7d3f6b536e72c9 ("ARM: dts: meson8: add the Mali-450 MP6 GPU")
> Reported-by: Thomas Graichen
> Signed-off-by: Martin Blumenstingl
Tested-by: thomas graichen
sorry - looks like i missed this one
> ---
> re-send of v1 from [0] because it was never picked up
>
>
> [0] https://patchwork.kernel.org/patch/11582619/
>
>
> arch/arm/boot/dts/meson8.dtsi | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
> index 277c0bb10453..04688e8abce2 100644
> --- a/arch/arm/boot/dts/meson8.dtsi
> +++ b/arch/arm/boot/dts/meson8.dtsi
> @@ -240,8 +240,6 @@ mali: gpu@c {
> ,
> ,
> ,
> -,
> -,
> ,
> ,
> ,
> --
> 2.28.0
>
Re: [PATCH] typhoon: switch from 'pci_' to 'dma_' API
On Sun, 2020-08-23 at 08:11 +0200, Christophe JAILLET wrote: > The wrappers in include/linux/pci-dma-compat.h should go away. > > The patch has been generated with the coccinelle script below and has > been > hand modified to replace GFP_ with a correct flag. > It has been compile tested. Looks good, thanks! Reviewed-by: David Dillow
Re: [PATCH] tools/power turbostat: call pread64 in kernel directly
Hi, I am not the original submitter, but I have answers and a proper patch :) On Fri, 21 Aug 2020, Len Brown wrote: > Re: offset size > > The offsets on this file are the MSR offsets. > What MSR are you trying to access at offset 0xc0010299? This MSR is particular is part of AMD RAPL (energy measurements) interface. > Re: pread vs pread64 > > If I take on faith that you have some kind of 32-bit execution > environment that makes pread into pread32 instead of pread64, and that > truncates an off_t to 32-bits from 64-bits, and it actually makes > sense to request a read at this large offset... The problem here stems from the backward compatibility in Glibc: off_t is 32-bit on 32-bit x86, unless compiled with -D_FILE_OFFSET_BITS=64. This macro should be used for all new code. Distros should enable it for all builds, but when one builds turbostat 'by hand', they hit the issue. > would we really have to invoke syscall() directly -- couldn't we > invoke pread64() directly? (eg. below) No, the proper fix is to pass -D_FILE_OFFSET_BITS=64 to the compiler. Here's the patch: ---8<--- From: Alexander Monakov Date: Sun, 23 Aug 2020 23:27:02 +0300 Subject: [PATCH] turbostat: build with _FILE_OFFSET_BITS=64 For compatibility reasons, Glibc off_t is a 32-bit type on 32-bit x86 unless _FILE_OFFSET_BITS=64 is defined. Add this define, as otherwise reading MSRs with index 0x8000 and above attempts a pread with a negative offset, which fails. Signed-off-by: Alexander Monakov --- tools/power/x86/turbostat/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/power/x86/turbostat/Makefile b/tools/power/x86/turbostat/Makefile index 2b6551269e43..40ae44402eec 100644 --- a/tools/power/x86/turbostat/Makefile +++ b/tools/power/x86/turbostat/Makefile @@ -12,6 +12,7 @@ turbostat : turbostat.c override CFLAGS += -O2 -Wall -I../../../include override CFLAGS += -DMSRHEADER='"../../../../arch/x86/include/asm/msr-index.h"' override CFLAGS += -DINTEL_FAMILY_HEADER='"../../../../arch/x86/include/asm/intel-family.h"' +override CFLAGS += -D_FILE_OFFSET_BITS=64 override CFLAGS += -D_FORTIFY_SOURCE=2 %: %.c -- 2.26.2
Re: [PATCH] blk-mq: use BLK_MQ_NO_TAG for no tag
On 8/23/20 9:44 AM, Xianting Tian wrote: > Replace various magic -1 constants for tags with BLK_MQ_NO_TAG. Doesn't look like this patch was even compiled... -- Jens Axboe
Re: [PATCH] thermal: ti-soc-thermal: Fix bogus thermal shutdowns for omap4430
Hi! > We can sometimes get bogus thermal shutdowns on omap4430 at least with > droid4 running idle with a battery charger connected: > > thermal thermal_zone0: critical temperature reached (143 C), shutting down > > Dumping out the register values shows we can occasionally get a 0x7f value > that is outside the TRM listed values in the ADC conversion table. And then > we get a normal value when reading again after that. Reading the register > multiple times does not seem help avoiding the bogus values as they stay > until the next sample is ready. > > Looking at the TRM chapter "18.4.10.2.3 ADC Codes Versus Temperature", we > should have values from 13 to 107 listed with a total of 95 values. But > looking at the omap4430_adc_to_temp array, the values are off, and the > end values are missing. And it seems that the 4430 ADC table is similar > to omap3630 rather than omap4460. > > Let's fix the issue by using values based on the omap3630 table and just > ignoring invalid values. Compared to the 4430 TRM, the omap3630 table has > the missing values added while the TRM table only shows every second > value. > > Note that sometimes the ADC register values within the valid table can > also be way off for about 1 out of 10 values. But it seems that those > just show about 25 C too low values rather than too high values. So those > do not cause a bogus thermal shutdown. This does not seem to be in recent -next. Ping? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: PGP signature
Re: Linux kernel in-tree Rust support
On Sun, Jul 12, 2020 at 12:39:44PM -0700, Josh Triplett wrote: >... > Rust has hard stability guarantees when upgrading from one stable > version to the next. If code compiles with a given stable version of > Rust, it'll compile with a newer stable version of Rust. >... In librsvg, breakages with more recent Rust versions in the past year required updates of two vendored crates: https://gitlab.gnome.org/GNOME/librsvg/-/commit/de26c4d8b192ed0224e6d38f54e429838608b902 https://gitlab.gnome.org/GNOME/librsvg/-/commit/696e4a6be2aeb00ea27945f94da066757431684d For updating Rust in Debian stable for the next Firefox ESR update it would actually be useful if these violations of the "hard stability guarantee" in Rust get fixed, so that the old librsvg 2.44.10 builds again with the latest Rust. It also makes me wonder how such regressions slip into Rust releases. cu Adrian
Re: [PATCH v1 4/6] dt-bindings: mfd: ene-kb3930: Add compatibles for KB930 and Acer A500
Hello, On Sun, Aug 23, 2020 at 10:31:36PM +0300, Dmitry Osipenko wrote: > 23.08.2020 21:20, Lubomir Rintel пишет: > > On Sun, Aug 23, 2020 at 05:08:44PM +0300, Dmitry Osipenko wrote: > >> The ENE KB930 hardware is compatible with KB3930. > >> > >> Acer A500 Iconia Tab is Android tablet device, it has KB930 controller > >> that is running firmware specifically customized for the needs of the > >> Acer A500 hardware. This means that firmware interface isn't re-usable > >> by other non-Acer devices. Some akin models of Acer tablets should be > >> able to re-use the FW interface of A500 model, like A200 for example. > >> > >> This patch adds the new compatibles to the binding. > > > > I've responded to patch 5/6 with what should've been said here [1]. > > Sorry for the confusion. > > > > In any case please consider adding a new binding file instead of > > modifying the kb3930 binding doc. It would also remove a dependency on > > my patch set which should have slipped out of maintainers' radar. > > > > [1] https://lore.kernel.org/lkml/20200823180041.GB209852@demiurge.local/ > > Hello, Lubomir! I was doing some research about the differences of > KB3930 and KB930 before created this patch and my understanding is that > the controllers are mostly identical. I've seen posts from people who > replaced KB3930 with KB930 (and vice versa) on various notebooks and it > worked, although not always. > > It's a very common practice to re-use binding in a case of a sibling > hardware. Do you know what are the exact differences between KB3930 and > KB930 which could justify having separate bindings? > > The firmware implementation varies a lot from device to device, It sometimes does. The ENE's downstream driver suggests there are parts that run more-or-less stock firmware that are comatible with each other. That is why I grabbed the generic kb3930 name. > and > thus, each device needs to have its own driver in order to talk to the > firmware, but hardware description (i.e. DT binding) should be common > for all devices. Note the DT is not the hardware description. It's the description of how the hardware presents itself, from the software's perspective. As far as that is concerned, the devices don't seem to have anything in common at all (other than the bus address). The fact that you need an entirely different driver implies this. This would be the case even if the A500 EC was based directly on a KB3930. A good reason to keep bindings for different yet somewhat similar devices in a single document is to avoid duplication. Yet here there's very little to share here. If you've done your bindings correctly, you'd need to conditionalize the monitored-battery and power-supplies properties for acer,a500-iconia-ec, complicating the binding too much. It makes more sense to just add a new document. Thanks, Lubo
Re: [IB/srpt] c804af2c1d: last_state.test.blktests.exit_code.143
On 2020-08-03 00:27, Sagi Grimberg wrote:
>
Greeting,
FYI, we noticed the following commit (built with gcc-9):
commit: c804af2c1d3152c0cf877eeb50d60c2d49ac0cf0 ("IB/srpt: use new shared
CQ mechanism")
https://git.kernel.org/cgit/linux/kernel/git/rdma/rdma.git for-next
in testcase: blktests
with following parameters:
test: srp-group1
ucode: 0x21
on test machine: 4 threads Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz with 4G
memory
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
If you fix the issue, kindly add following tag
Reported-by: kernel test robot
user :notice: [ 44.688140] 2020-08-01 16:10:22 ./check srp/001 srp/002
srp/003 srp/004 srp/005 srp/006 srp/007 srp/008 srp/009 srp/010 srp/011
srp/012 srp/013 srp/015
user :notice: [ 44.706657] srp/001 (Create and remove LUNs)
user :notice: [ 44.718405] srp/001 (Create and remove LUNs)
[passed]
user :notice: [ 44.729902] runtime ... 1.972s
user :notice: [ 99.038748] IPMI BMC is not supported on this machine,
skip bmc-watchdog setup!
user :notice: [ 3699.039790] Sat Aug 1 17:11:22 UTC 2020 detected
soft_timeout
user :notice: [ 3699.060341] kill 960 /usr/bin/time -v -o
/tmp/lkp/blktests.time /lkp/lkp/src/tests/blktests
>>> Yamin and Max, can you take a look at this? The SRP tests from the
>>> blktests repository pass reliably with kernel version v5.7 and before.
>>> With label next-20200731 from linux-next however that test triggers the
>>> following hang:
>>
>> I will look into it.
>
> FWIW, I ran into this as well with nvme-rdma, but it also reproduces
> when I revert the shared CQ patch from nvme-rdma. Another data point
> is that my tests passes with siw.
Hi Jason,
The patch below is sufficient to unbreak blktests. I think that the
deadlock while unloading rdma_rxe happens because the RDMA core waits for
all ib_dev references to be dropped before dealloc_driver is called.
The rdma_rxe dealloc_driver implementation drops an ib_dev reference. The
dealloc_driver callback was introduced by commit d0899892edd0
("RDMA/device: Provide APIs from the core code to help unregistration").
Do you agree that this regression has been introduced by commits
d0899892edd0 and c367074b6c37 ("RDMA/rxe: Use driver_unregister and new
unregistration API")?
Thanks,
Bart.
---
drivers/infiniband/core/device.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c
index dca2842a7872..5192f305b253 100644
--- a/drivers/infiniband/core/device.c
+++ b/drivers/infiniband/core/device.c
@@ -1287,13 +1287,8 @@ static void disable_device(struct ib_device *device)
/* Pairs with refcount_set in enable_device */
ib_device_put(device);
- wait_for_completion(&device->unreg_completion);
- /*
-* compat devices must be removed after device refcount drops to zero.
-* Otherwise init_net() may add more compatdevs after removing compat
-* devices and before device is disabled.
-*/
+ /* To do: prevent init_net() to add more compat_devs. */
remove_compat_devs(device);
}
Re: Camera LED on Librem 5 was Re: [PATCH] backlight: add led-backlight driver
Hi! > > > > This patch adds a led-backlight driver (led_bl), which is similar to > > > > pwm_bl except the driver uses a LED class driver to adjust the > > > > brightness in the HW. Multiple LEDs can be used for a single backlight. > > > > > > Tested-by: Guido Günther > > > > Thanks for testing! > > > > I noticed blog post about using Librem 5 torch. Unfortunately, it used > > very strange/non-standard interface, first using LED as a GPIO to > > enable LED controller, then direct i2c access. That is not acceptable > > interface for mainline, and it would be better not to advertise such > > code, as it will likely become broken in future. > > I agree, there's a driver for the lm3560 in media/ but how would one > expose the torch part as a LED? It seems you hit something similar in > > https://lkml.org/lkml/2018/5/6/30 (Actually, I might have been wrong in that comment). > I also couldn't find an in tree driver that registers a flashlight > as a v4l subdev. Did i miss that? You should get interface similar to this: https://wiki.postmarketos.org/wiki/PINE64_PinePhone_(pine64-pinephone) and the driver to enable that should already be in the mainline: drivers/leds/leds-sgm3140.c Best regards and good luck, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: PGP signature
Linux 5.9-rc2
It's Sunday afternoon, which means it's time for another release candidate. Nothing in particular stands out, there's a random collection of fixes and updates in here. It is perhaps a bit filesystem-heavy, because the ext4 updates came in late, so a bit unusually we have 20+% of the patch being under fs/, and that's the biggest chunk in here after the usual driver updates (sound, gpu, networking, scsi, vfio). Other than that, it's mostly arch fixes and some tooling fixes, with a smattering elsewhere. The appended shortlog gives an overview of the details, it's all pretty small stuff. The diffstat shows the ext4 changes and a RISC-V timer chip standing out, and even those aren't really particularly big. Please test, Linus --- Adrian Hunter (3): scsi: ufs-pci: Add quirk for broken auto-hibernate for Intel EHL scsi: ufs: Fix interrupt error message for shared interrupts scsi: ufs: Improve interrupt handling for shared interrupts Al Viro (1): do_epoll_ctl(): clean the failure exits up a bit Alaa Hleihel (1): net/sched: act_ct: Fix skb double-free in tcf_ct_handle_fragments() error flow Alain Volmat (1): spi: stm32: always perform registers configuration prior to transfer Alex Williamson (2): vfio-pci: Avoid recursive read-lock usage vfio/type1: Add proper error unwind for vfio_iommu_replay() Alex Zhuravlev (2): ext4: add prefetching for block allocation bitmaps ext4: skip non-loaded groups at cr=0/1 when scanning for good groups Alexander A. Klimov (1): ext4: replace HTTP links with HTTPS ones Alexander Tsoy (1): ALSA: usb-audio: Add capture support for Saffire 6 (USB 1.1) Alvin Šipraga (1): macvlan: validate setting of multiple remote source MAC addresses Amelie Delaunay (3): spi: stm32: fix fifo threshold level in case of short transfer spi: stm32: fix stm32_spi_prepare_mbr in case of odd clk_rate spi: stm32: fixes suspend/resume management Andrew Lunn (1): net: devlink: Remove overzealous WARN_ON with snapshots Andrii Nakryiko (13): bpf: Fix XDP FD-based attach/detach logic around XDP_FLAGS_UPDATE_IF_NOEXIST tools/bpftool: Make skeleton code C++17-friendly by dropping typeof() tools/bpftool: Fix compilation warnings in 32-bit mode selftest/bpf: Fix compilation warnings in 32-bit mode libbpf: Fix BTF-defined map-in-map initialization on 32-bit host arches libbpf: Handle BTF pointer sizes more carefully selftests/bpf: Fix btf_dump test cases on 32-bit arches libbpf: Enforce 64-bitness of BTF for BPF object files selftests/bpf: Correct various core_reloc 64-bit assumptions tools/bpftool: Generate data section struct with conservative alignment selftests/bpf: Make test_varlen work with 32-bit user-space arch libbpf: Fix build on ppc64le architecture bpf: xdp: Fix XDP mode when no mode flags specified Aneesh Kumar K.V (2): powerpc/pkeys: Fix build error with PPC_MEM_KEYS disabled mm/vunmap: add cond_resched() in vunmap_pmd_range Anju T Sudhakar (1): powerpc/perf: Add support for outputting extended regs in perf intr_regs Anthony Koo (2): drm/amd/display: Fix LFC multiplier changing erratically drm/amd/display: Switch to immediate mode for updating infopackets Antonio Borneo (1): spi: stm32h7: fix race condition at end of transfer Anup Patel (4): RISC-V: Add mechanism to provide custom IPI operations clocksource/drivers: Add CLINT timer driver RISC-V: Remove CLINT related code from timer and arch dt-bindings: timer: Add CLINT bindings Ard Biesheuvel (2): efi/x86: Move 32-bit code into efi_32.c Documentation: efi: remove description of efi=old_map Aric Cyr (1): drm/amd/display: Fix incorrect backlight register offset for DCN Arun Easi (2): scsi: qla2xxx: Allow ql2xextended_error_logging special value 1 to be set anytime scsi: qla2xxx: Fix WARN_ON in qla_nvme_register_hba Arvind Sankar (6): x86/boot/compressed: Use builtin mem functions for decompressor lib/string.c: Use freestanding environment efi/x86: Mark kernel rodata non-executable for mixed mode efi/libstub: Stop parsing arguments at "--" efi/libstub: Handle NULL cmdline efi/libstub: Handle unterminated cmdline Athira Rajeev (2): powerpc/perf: Add extended regs support for power10 platform powerpc/perf: Fix soft lockups due to missed interrupt accounting Bean Huo (1): scsi: ufs: No need to send Abort Task if the task in DB was cleared Bhawanpreet Lakha (1): drm/amdgpu: parse ta firmware for navy_flounder Bin Meng (1): riscv: Add SiFive drivers to rv32_defconfig Charan Teja Reddy (1): mm, page_alloc: fix core hung in free_pcppages_bulk() Chris Park (3): drm/amd/display: Call DMUB for eDP power control drm/amd/display: Assign correct left shift drm/amd/disp
Re: [GIT pull] perf/urgent for v5.9-rc2
On Sun, Aug 23 2020 at 11:16, Linus Torvalds wrote: > On Sun, Aug 23, 2020 at 1:26 AM Thomas Gleixner wrote: >> >> A single update for perf on x86 which ass support for the >> broken down bandwith counters. > > Spot the freudian slip.. At least it clearly reflects my true feelings vs. the well designed details of the X86 architecture. Thanks, tglx
[PATCH] x86/asm: Replace __force_order with memory clobber
The CRn accessor functions use __force_order as a dummy operand to
prevent the compiler from reordering the inline asm.
The fact that the asm is volatile should be enough to prevent this
already, however older versions of GCC had a bug that could sometimes
result in reordering. This was fixed in 8.1, 7.3 and 6.5.
There are some issues with __force_order as implemented:
- It is used only as an input operand for the write functions, and hence
doesn't do anything additional to prevent reordering writes.
- It allows memory accesses to be cached/reordered across write
functions, but CRn writes affect the semantics of memory accesses, so
this could be dangerous.
- __force_order is not actually defined in the kernel proper, but the
LLVM toolchain can in some cases require a definition: LLVM (as well
as GCC 4.9) requires it for PIE code, which is why the compressed
kernel has a definition, but also the clang integrated assembler may
consider the address of __force_order to be significant, resulting in
a reference that requires a definition.
Fix this by:
- Using a memory clobber for the write functions to additionally prevent
caching/reordering memory accesses across CRn writes.
- Using a dummy input operand with an arbitrary constant address for the
read functions, instead of a global variable. This will prevent reads
from being reordered across writes, while allowing memory loads to be
cached/reordered across CRn reads, which should be safe.
Signed-off-by: Arvind Sankar
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82602
---
arch/x86/boot/compressed/pgtable_64.c | 9 -
arch/x86/include/asm/special_insns.h | 27 ++-
arch/x86/kernel/cpu/common.c | 4 ++--
3 files changed, 16 insertions(+), 24 deletions(-)
diff --git a/arch/x86/boot/compressed/pgtable_64.c
b/arch/x86/boot/compressed/pgtable_64.c
index c8862696a47b..7d0394f4ebf9 100644
--- a/arch/x86/boot/compressed/pgtable_64.c
+++ b/arch/x86/boot/compressed/pgtable_64.c
@@ -5,15 +5,6 @@
#include "pgtable.h"
#include "../string.h"
-/*
- * __force_order is used by special_insns.h asm code to force instruction
- * serialization.
- *
- * It is not referenced from the code, but GCC < 5 with -fPIE would fail
- * due to an undefined symbol. Define it to make these ancient GCCs work.
- */
-unsigned long __force_order;
-
#define BIOS_START_MIN 0x2U/* 128K, less than this is
insane */
#define BIOS_START_MAX 0x9f000U/* 640K, absolute maximum */
diff --git a/arch/x86/include/asm/special_insns.h
b/arch/x86/include/asm/special_insns.h
index 59a3e13204c3..8f7791217ef4 100644
--- a/arch/x86/include/asm/special_insns.h
+++ b/arch/x86/include/asm/special_insns.h
@@ -11,45 +11,46 @@
#include
/*
- * Volatile isn't enough to prevent the compiler from reordering the
- * read/write functions for the control registers and messing everything up.
- * A memory clobber would solve the problem, but would prevent reordering of
- * all loads stores around it, which can hurt performance. Solution is to
- * use a variable and mimic reads and writes to it to enforce serialization
+ * The compiler should not reorder volatile asm, however older versions of GCC
+ * had a bug (which was fixed in 8.1, 7.3 and 6.5) where they could sometimes
+ * reorder volatile asm. The write functions are not a problem since they have
+ * memory clobbers preventing reordering. To prevent reads from being reordered
+ * with respect to writes, use a dummy memory operand.
*/
-extern unsigned long __force_order;
+
+#define __FORCE_ORDER "m"(*(unsigned int *)0x1000UL)
void native_write_cr0(unsigned long val);
static inline unsigned long native_read_cr0(void)
{
unsigned long val;
- asm volatile("mov %%cr0,%0\n\t" : "=r" (val), "=m" (__force_order));
+ asm volatile("mov %%cr0,%0\n\t" : "=r" (val) : __FORCE_ORDER);
return val;
}
static __always_inline unsigned long native_read_cr2(void)
{
unsigned long val;
- asm volatile("mov %%cr2,%0\n\t" : "=r" (val), "=m" (__force_order));
+ asm volatile("mov %%cr2,%0\n\t" : "=r" (val) : __FORCE_ORDER);
return val;
}
static __always_inline void native_write_cr2(unsigned long val)
{
- asm volatile("mov %0,%%cr2": : "r" (val), "m" (__force_order));
+ asm volatile("mov %0,%%cr2": : "r" (val) : "memory");
}
static inline unsigned long __native_read_cr3(void)
{
unsigned long val;
- asm volatile("mov %%cr3,%0\n\t" : "=r" (val), "=m" (__force_order));
+ asm volatile("mov %%cr3,%0\n\t" : "=r" (val) : __FORCE_ORDER);
return val;
}
static inline void native_write_cr3(unsigned long val)
{
- asm volatile("mov %0,%%cr3": : "r" (val), "m" (__force_order));
+ asm volatile("mov %0,%%cr3": : "r" (val) : "memory");
}
static inline unsigned long native_read_cr4(void)
@@ -64,10 +65,10 @@ static inline unsigned long native_read_cr4(void)
[PATCH] spi: spi-fsl-dspi: delete EOQ transfer mode
After the only user of the limited EOQ mode has now been converted to
DMA as of commit b09058bbf5f0 ("spi: spi-fsl-dspi: set ColdFire to DMA
mode"), we can finally delete this code.
Signed-off-by: Vladimir Oltean
---
drivers/spi/spi-fsl-dspi.c | 56 --
1 file changed, 5 insertions(+), 51 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 5b9a285d84a7..c739cc7e4561 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -53,7 +53,6 @@
#define SPI_SR 0x2c
#define SPI_SR_TCFQF BIT(31)
-#define SPI_SR_EOQFBIT(28)
#define SPI_SR_TFUFBIT(27)
#define SPI_SR_TFFFBIT(25)
#define SPI_SR_CMDTCF BIT(23)
@@ -62,7 +61,7 @@
#define SPI_SR_TFIWF BIT(18)
#define SPI_SR_RFDFBIT(17)
#define SPI_SR_CMDFFF BIT(16)
-#define SPI_SR_CLEAR (SPI_SR_TCFQF | SPI_SR_EOQF | \
+#define SPI_SR_CLEAR (SPI_SR_TCFQF | \
SPI_SR_TFUF | SPI_SR_TFFF | \
SPI_SR_CMDTCF | SPI_SR_SPEF | \
SPI_SR_RFOF | SPI_SR_TFIWF | \
@@ -75,7 +74,6 @@
#define SPI_RSER 0x30
#define SPI_RSER_TCFQE BIT(31)
-#define SPI_RSER_EOQFE BIT(28)
#define SPI_RSER_CMDTCFE BIT(23)
#define SPI_PUSHR 0x34
@@ -114,7 +112,6 @@ struct chip_data {
};
enum dspi_trans_mode {
- DSPI_EOQ_MODE = 0,
DSPI_XSPI_MODE,
DSPI_DMA_MODE,
};
@@ -671,11 +668,6 @@ static void ns_delay_scale(char *psc, char *sc, int
delay_ns,
}
}
-static void dspi_pushr_write(struct fsl_dspi *dspi)
-{
- regmap_write(dspi->regmap, SPI_PUSHR, dspi_pop_tx_pushr(dspi));
-}
-
static void dspi_pushr_cmd_write(struct fsl_dspi *dspi, u16 cmd)
{
/*
@@ -735,21 +727,6 @@ static void dspi_xspi_fifo_write(struct fsl_dspi *dspi,
int num_words)
}
}
-static void dspi_eoq_fifo_write(struct fsl_dspi *dspi, int num_words)
-{
- u16 xfer_cmd = dspi->tx_cmd;
-
- /* Fill TX FIFO with as many transfers as possible */
- while (num_words--) {
- dspi->tx_cmd = xfer_cmd;
- /* Request EOQF for last transfer in FIFO */
- if (num_words == 0)
- dspi->tx_cmd |= SPI_PUSHR_CMD_EOQ;
- /* Write combined TX FIFO and CMD FIFO entry */
- dspi_pushr_write(dspi);
- }
-}
-
static u32 dspi_popr_read(struct fsl_dspi *dspi)
{
u32 rxdata = 0;
@@ -818,7 +795,7 @@ static void dspi_setup_accel(struct fsl_dspi *dspi)
dspi->oper_word_size = DIV_ROUND_UP(dspi->oper_bits_per_word, 8);
/*
-* Update CTAR here (code is common for EOQ, XSPI and DMA modes).
+* Update CTAR here (code is common for XSPI and DMA modes).
* We will update CTARE in the portion specific to XSPI, when we
* also know the preload value (DTCP).
*/
@@ -862,10 +839,7 @@ static void dspi_fifo_write(struct fsl_dspi *dspi)
spi_take_timestamp_pre(dspi->ctlr, xfer, dspi->progress, !dspi->irq);
- if (dspi->devtype_data->trans_mode == DSPI_EOQ_MODE)
- dspi_eoq_fifo_write(dspi, num_words);
- else
- dspi_xspi_fifo_write(dspi, num_words);
+ dspi_xspi_fifo_write(dspi, num_words);
/*
* Everything after this point is in a potential race with the next
* interrupt, so we must never use dspi->words_in_flight again since it
@@ -898,7 +872,7 @@ static int dspi_poll(struct fsl_dspi *dspi)
regmap_read(dspi->regmap, SPI_SR, &spi_sr);
regmap_write(dspi->regmap, SPI_SR, spi_sr);
- if (spi_sr & (SPI_SR_EOQF | SPI_SR_CMDTCF))
+ if (spi_sr & SPI_SR_CMDTCF)
break;
} while (--tries);
@@ -916,7 +890,7 @@ static irqreturn_t dspi_interrupt(int irq, void *dev_id)
regmap_read(dspi->regmap, SPI_SR, &spi_sr);
regmap_write(dspi->regmap, SPI_SR, spi_sr);
- if (!(spi_sr & (SPI_SR_EOQF | SPI_SR_CMDTCF)))
+ if (!(spi_sr & SPI_SR_CMDTCF))
return IRQ_NONE;
if (dspi_rxtx(dspi) == 0)
@@ -1204,9 +1178,6 @@ static int dspi_init(struct fsl_dspi *dspi)
regmap_write(dspi->regmap, SPI_SR, SPI_SR_CLEAR);
switch (dspi->devtype_data->trans_mode) {
- case DSPI_EOQ_MODE:
- regmap_write(dspi->regmap, SPI_RSER, SPI_RSER_EOQFE);
- break;
case DSPI_XSPI_MODE:
regmap_write(dspi->regmap, SPI_RSER, SPI_RSER_CMDTCFE);
break;
@@ -1245,22 +1216,6 @@ static int dspi_slave_abort(struct spi_master *master)
return 0;
}
-/*
- * EOQ mode will inevitably deassert its PC
Re: [PATCH 16/18] staging/media/tegra-vde: Clean up IOMMU workaround
21.08.2020 03:11, Robin Murphy пишет: ... >> Hello, Robin! Thank you for yours work! >> >> Some drivers, like this Tegra VDE (Video Decoder Engine) driver for >> example, do not want to use implicit IOMMU domain. > > That isn't (intentionally) changing here - the only difference should be > that instead of having the ARM-special implicit domain, which you have > to kick out of the way with the ARM-specific API before you're able to > attach your own domain, the implicit domain is now a proper IOMMU API > default domain, which automatically gets bumped by your attach. The > default domains should still only be created in the same cases that the > ARM dma_iommu_mappings were. > >> Tegra VDE driver >> relies on explicit IOMMU domain in a case of Tegra SMMU because VDE >> hardware can't access last page of the AS and because driver wants to >> reserve some fixed addresses [1]. >> >> [1] >> https://elixir.bootlin.com/linux/v5.9-rc1/source/drivers/staging/media/tegra-vde/iommu.c#L100 >> >> >> Tegra30 SoC supports up to 4 domains, hence it's not possible to afford >> wasting unused implicit domains. I think this needs to be addressed >> before this patch could be applied. > > Yeah, there is one subtle change in behaviour from removing the ARM > layer on top of the core API, in that the IOMMU driver will no longer > see an explicit detach call. Thus it does stand to benefit from being a > bit cleverer about noticing devices being moved from one domain to > another by an attach call, either by releasing the hardware context for > the inactive domain once the device(s) are moved across to the new one, > or by simply reprogramming the hardware context in-place for the new > domain's address space without allocating a new one at all (most of the > drivers that don't have multiple contexts already handle the latter > approach quite well). > >> Would it be possible for IOMMU drivers to gain support for filtering out >> devices in iommu_domain_alloc(dev, type)? Then perhaps Tegra SMMU driver >> could simply return NULL in a case of type=IOMMU_DOMAIN_DMA and >> dev=tegra-vde. > > If you can implement IOMMU_DOMAIN_IDENTITY by allowing the relevant > devices to bypass translation entirely without needing a hardware > context (or at worst, can spare one context which all identity-mapped > logical domains can share), then you could certainly do that kind of > filtering with the .def_domain_type callback if you really wanted to. As > above, the intent is that that shouldn't be necessary for this > particular case, since only one of a group's default domain and > explicitly attached domain can be live at any given time, so the driver > should be able to take advantage of that. > > If you simply have more active devices (groups) than available contexts > then yes, you probably would want to do some filtering to decide who > deserves a translation domain and who doesn't, but in that case you > should already have had a long-standing problem with the ARM implicit > domains. > >> Alternatively, the Tegra SMMU could be changed such that the devices >> will be attached to a domain at the time of a first IOMMU mapping >> invocation instead of attaching at the time of attach_dev() callback >> invocation. >> >> Or maybe even IOMMU core could be changed to attach devices at the time >> of the first IOMMU mapping invocation? This could be a universal >> solution for all drivers. > > I suppose technically you could do that within an IOMMU driver already > (similar to how some defer most of setup that logically belongs to > ->domain_alloc until the first ->attach_dev). It's a bit grim from the > caller's PoV though, in terms of the failure mode being non-obvious and > having no real way to recover. Again, you'd be better off simply making > decisions up-front at domain_alloc or attach time based on the domain type. Robin, thank you very much for the clarifications! In accordance to yours comments, this patch can't be applied until Tegra SMMU will support IOMMU_DOMAIN_IDENTITY and implement def_domain_type() callback that returns IOMMU_DOMAIN_IDENTITY for the VDE device. Otherwise you're breaking the VDE driver because dma_buf_map_attachment() [1] returns the IOMMU SGT of the implicit domain which is then mapped into the VDE's explicit domain [2], and this is a nonsense. [1] https://elixir.bootlin.com/linux/v5.9-rc1/source/drivers/staging/media/tegra-vde/dmabuf-cache.c#L102 [2] https://elixir.bootlin.com/linux/v5.9-rc1/source/drivers/staging/media/tegra-vde/dmabuf-cache.c#L122 Hence, either VDE driver should bypass iommu_dma_ops from the start or it needs a way to kick out the ops, like it does this using ARM's arm_iommu_detach_device(). The same applies to the Tegra GPU devices, otherwise you're breaking them as well because Tegra DRM is sensible to implicit vs explicit domain. BTW, I tried to apply this series and T30 doesn't boot anymore. I don't have more info for now.
drivers/scsi/bfa/bfad_bsg.c:2748:1: warning: stack frame size of 2688 bytes in function 'bfad_iocmd_handler'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: cb95712138ec5e480db5160b41172bbc6f6494cc
commit: 3bbd8ef9f780749426d4e52be0dfa3f70656d92b scsi: bfa: Staticify all local
functions
date: 4 weeks ago
config: x86_64-randconfig-r003-20200824 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
b587ca93be114d07ec3bf654add97d7872325281)
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
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git checkout 3bbd8ef9f780749426d4e52be0dfa3f70656d92b
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/scsi/bfa/bfad_bsg.c:2748:1: warning: stack frame size of 2688 bytes
>> in function 'bfad_iocmd_handler' [-Wframe-larger-than=]
bfad_iocmd_handler(struct bfad_s *bfad, unsigned int cmd, void *iocmd,
^
1 warning generated.
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3bbd8ef9f780749426d4e52be0dfa3f70656d92b
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 3bbd8ef9f780749426d4e52be0dfa3f70656d92b
vim +/bfad_iocmd_handler +2748 drivers/scsi/bfa/bfad_bsg.c
e6826c96ced7ea Krishna Gudipati 2012-09-21 2746
b85daafe46eeb0 Krishna Gudipati 2011-06-13 2747 static int
b85daafe46eeb0 Krishna Gudipati 2011-06-13 @2748 bfad_iocmd_handler(struct
bfad_s *bfad, unsigned int cmd, void *iocmd,
b85daafe46eeb0 Krishna Gudipati 2011-06-13 2749 unsigned int
payload_len)
b85daafe46eeb0 Krishna Gudipati 2011-06-13 2750 {
9afbcfab74d260 Krishna Gudipati 2011-07-20 2751 int rc = -EINVAL;
b85daafe46eeb0 Krishna Gudipati 2011-06-13 2752
b85daafe46eeb0 Krishna Gudipati 2011-06-13 2753 switch (cmd) {
601380669baa2b Krishna Gudipati 2011-06-24 2754 case IOCMD_IOC_ENABLE:
601380669baa2b Krishna Gudipati 2011-06-24 2755 rc =
bfad_iocmd_ioc_enable(bfad, iocmd);
601380669baa2b Krishna Gudipati 2011-06-24 2756 break;
601380669baa2b Krishna Gudipati 2011-06-24 2757 case IOCMD_IOC_DISABLE:
601380669baa2b Krishna Gudipati 2011-06-24 2758 rc =
bfad_iocmd_ioc_disable(bfad, iocmd);
601380669baa2b Krishna Gudipati 2011-06-24 2759 break;
b85daafe46eeb0 Krishna Gudipati 2011-06-13 2760 case IOCMD_IOC_GET_INFO:
b85daafe46eeb0 Krishna Gudipati 2011-06-13 2761 rc =
bfad_iocmd_ioc_get_info(bfad, iocmd);
b85daafe46eeb0 Krishna Gudipati 2011-06-13 2762 break;
b85daafe46eeb0 Krishna Gudipati 2011-06-13 2763 case IOCMD_IOC_GET_ATTR:
b85daafe46eeb0 Krishna Gudipati 2011-06-13 2764 rc =
bfad_iocmd_ioc_get_attr(bfad, iocmd);
b85daafe46eeb0 Krishna Gudipati 2011-06-13 2765 break;
601380669baa2b Krishna Gudipati 2011-06-24 2766 case
IOCMD_IOC_GET_STATS:
601380669baa2b Krishna Gudipati 2011-06-24 2767 rc =
bfad_iocmd_ioc_get_stats(bfad, iocmd);
601380669baa2b Krishna Gudipati 2011-06-24 2768 break;
601380669baa2b Krishna Gudipati 2011-06-24 2769 case
IOCMD_IOC_GET_FWSTATS:
601380669baa2b Krishna Gudipati 2011-06-24 2770 rc =
bfad_iocmd_ioc_get_fwstats(bfad, iocmd, payload_len);
601380669baa2b Krishna Gudipati 2011-06-24 2771 break;
f2ee76017b30c8 Krishna Gudipati 2011-07-20 2772 case
IOCMD_IOC_RESET_STATS:
f2ee76017b30c8 Krishna Gudipati 2011-07-20 2773 case
IOCMD_IOC_RESET_FWSTATS:
f2ee76017b30c8 Krishna Gudipati 2011-07-20 2774 rc =
bfad_iocmd_ioc_reset_stats(bfad, iocmd, cmd);
f2ee76017b30c8 Krishna Gudipati 2011-07-20 2775 break;
f2ee76017b30c8 Krishna Gudipati 2011-07-20 2776 case
IOCMD_IOC_SET_ADAPTER_NAME:
f2ee76017b30c8 Krishna Gudipati 2011-07-20 2777 case
IOCMD_IOC_SET_PORT_NAME:
f2ee76017b30c8 Krishna Gudipati 2011-07-20 2778 rc =
bfad_iocmd_ioc_set_name(bfad, iocmd, cmd);
f2ee76017b30c8 Krishna Gudipati 2011-07-20 2779 break;
601380669baa2b Krishna Gudipati 2011-06-24 2780 case
IOCMD_IOCFC_GET_ATTR:
601380669baa2b Krishna Gudipati 2011-06-24 2781 rc =
bfad_iocmd_iocfc_get_attr(bfad, iocmd);
601380669baa2b Krishna Gudipati 2011-06-24 2782 break;
601380669baa2b Krishna Gudipati 2011-06-24 2783 case
IOCMD_IOCFC_SET_INTR:
601380669baa2b Krishna Gudipati 2011-06-24 2784 rc =
bfad_iocmd_iocfc_set_intr(bfad, iocmd);
601380669baa2b Kri
Re: [PATCH 12/18] iommu/tegra-gart: Add IOMMU_DOMAIN_DMA support
21.08.2020 03:28, Robin Murphy пишет: ... >> Will a returned NULL tell to IOMMU core that implicit domain shouldn't >> be used? Is it possible to leave this driver as-is? > > The aim of this patch was just to make the conversion without functional > changes wherever possible, i.e. maintain an equivalent to the existing > ARM behaviour of allocating its own implicit domains for everything. It > doesn't represent any judgement of whether that was ever appropriate for > this driver in the first place ;) > > Hopefully my other reply already covered the degree of control drivers > can have with proper default domains, but do shout if anything wasn't > clear. Thank you for the detailed comments! I wasn't watching closely all the recent iommu/ changes and yours clarification is very helpful! My current understanding is that the GART driver will need to support the IOMMU_DOMAIN_IDENTITY and set def_domain_type to IOMMU_DOMAIN_IDENTITY for all devices. Meanwhile, today's upstream drivers don't use GART, hence this patch should be okay. Although, it's a bit unlikely that the IOMMU_DOMAIN_DMA type will ever be useful for the GART, and thus, I'm still thinking that will be a bit nicer to keep GART driver as-is for now.
Re: Linux kernel in-tree Rust support
On Mon, 24 Aug 2020, Adrian Bunk wrote: In librsvg, breakages with more recent Rust versions in the past year required updates of two vendored crates: Interesting! https://gitlab.gnome.org/GNOME/librsvg/-/commit/de26c4d8b192ed0224e6d38f54e429838608b902 Looks like this was, for a while, a warning and not an error: https://github.com/servo/rust-cssparser/commit/3c98d22c5de3b696bf1fde2b6c90069812312aa6 = warning: this error has been downgraded to a warning for backwards compatibility with previous releases = warning: this represents potential undefined behavior in your code and this warning will become a hard error in the future https://gitlab.gnome.org/GNOME/librsvg/-/commit/696e4a6be2aeb00ea27945f94da066757431684d Same here, and it looks like the same warning/error, too: https://github.com/dimforge/nalgebra/issues/561 = warning: this error has been downgraded to a warning for backwards compatibility with previous releases = warning: this represents potential undefined behavior in your code and this warning will become a hard error in the future Following some links in that second issue, I see that this seems to be a summary of what's going on: https://github.com/rust-lang/rust/issues/59159 in particular this paragraph: "at the time that NLL [non-lexical lifetimes] was stabilized, the compiler's acceptance of this borrowing pattern was categorized by the NLL team as a 'known bug'. The NLL team assumed that, as a bug fix, the compiler would be allowed to start rejecting the pattern in the future." That is, both of these cases were code that should never have been accepted by the compiler because it is unsound, but the initial implementation of NLL was not clever enough to detect it. They later turned it into a warning, and later turned that into an error. There is a link to this policy document which explains their process for breaking existing code in the case where it's necessary to fix a compiler bug or similar: https://github.com/rust-lang/rfcs/blob/master/text/1589-rustc-bug-fix-procedure.md There is also a link to this comment about why they decided to take this approach: https://github.com/rust-lang/rust/pull/58739#issuecomment-476387184 which includes the followup task, "We do a retrospective and look to ways to alter our processes to better prevent this in the future." That is, it seems to me that the Rust team sees it as a mistake that they ended up in this situation. Josh, do you know if that retrospective has happened? (I see some mumbling about NLL -> Polonius, can we be confident something similar won't happen with that? :) ) For updating Rust in Debian stable for the next Firefox ESR update it would actually be useful if these violations of the "hard stability guarantee" in Rust get fixed, so that the old librsvg 2.44.10 builds again with the latest Rust. It also makes me wonder how such regressions slip into Rust releases. I do conceptually agree with this, even though it is not technically a "regression" (because it was really the old compiler that was buggy, not the new one). If I understand it right, neither of these lines of code were valid with the pre-NLL implementation either. They were only accepted by the initial NLL implementation. While the purpose of NLL was to enable writing (valid/sound) code that wouldn't have been accepted by the previous, simpler implementation of lifetimes, it seems like it should have been possible to opt out of it while there were "known bugs" precisely to prevent these sort of effective-regressions. (And I suspect that it was in fact possible to do so, but perhaps not documented clearly / perhaps there wasn't an awareness that this was a thing that users who deeply value stability would want to do.) And yeah, I can see the value of a --accept-previously-accepted-buggy-code flag from the distros' point of view (even if I can also see why Rust upstream would not be super excited about it :) ). After all, if the choice is between the distro not taking _any_ bug fixes in rustc and the distro taking all but one, the latter seems like a better option. The other takeaway, I think, is that you should regularly compile with warnings turned into hard errors. The policy document above (Rust RFC 1589) says that all such changes need to be a warning and not a hard error for at least one compiler reversion. That happened in this case, and both fixes were applied in the vendored crates while they were still warnings. For any kernel Rust use, I'd strongly advocate for running CI on every stable branch after each compiler release, preferably after each compiler beta release, and shaking out any warnings - even if they are not warnings the compiler will turn into errors on its own, they may still point to logic bugs in the code. (The Rust folks have some automation named "crater" for running these sorts of tests across the Rust ecosystem, which the document mentions. I'
[PATCH 5/8] phy: lantiq: vrx200-pcie: Constify ltq_vrx200_pcie_phy_ops
The only usage is to pass its address to devm_phy_create() which takes a
const pointer. Make it const to allow the compiler to put it in
read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/phy/lantiq/phy-lantiq-vrx200-pcie.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/lantiq/phy-lantiq-vrx200-pcie.c
b/drivers/phy/lantiq/phy-lantiq-vrx200-pcie.c
index 2ff9a48d833e..22c5698123cf 100644
--- a/drivers/phy/lantiq/phy-lantiq-vrx200-pcie.c
+++ b/drivers/phy/lantiq/phy-lantiq-vrx200-pcie.c
@@ -349,7 +349,7 @@ static int ltq_vrx200_pcie_phy_power_off(struct phy *phy)
return 0;
}
-static struct phy_ops ltq_vrx200_pcie_phy_ops = {
+static const struct phy_ops ltq_vrx200_pcie_phy_ops = {
.init = ltq_vrx200_pcie_phy_init,
.exit = ltq_vrx200_pcie_phy_exit,
.power_on = ltq_vrx200_pcie_phy_power_on,
--
2.28.0
[PATCH 7/8] phy: samsung-ufs: Constify samsung_ufs_phy_ops
The only usage is to pass its address to devm_phy_create() which takes a
const pointer. Make it const to allow the compiler to put it in
read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/phy/samsung/phy-samsung-ufs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/samsung/phy-samsung-ufs.c
b/drivers/phy/samsung/phy-samsung-ufs.c
index 9832599a0283..dd9ab1519d83 100644
--- a/drivers/phy/samsung/phy-samsung-ufs.c
+++ b/drivers/phy/samsung/phy-samsung-ufs.c
@@ -268,7 +268,7 @@ static int samsung_ufs_phy_exit(struct phy *phy)
return 0;
}
-static struct phy_ops samsung_ufs_phy_ops = {
+static const struct phy_ops samsung_ufs_phy_ops = {
.init = samsung_ufs_phy_init,
.exit = samsung_ufs_phy_exit,
.power_on = samsung_ufs_phy_power_on,
--
2.28.0
[PATCH 1/8] phy: cadence: salvo: Constify cdns_salvo_phy_ops
The only usage is to pass its address to devm_phy_create() which takes a
const pointer. Make it const to allow the compiler to put it in
read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/phy/cadence/phy-cadence-salvo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/cadence/phy-cadence-salvo.c
b/drivers/phy/cadence/phy-cadence-salvo.c
index 016514e4aa54..8c33d3215f2d 100644
--- a/drivers/phy/cadence/phy-cadence-salvo.c
+++ b/drivers/phy/cadence/phy-cadence-salvo.c
@@ -251,7 +251,7 @@ static int cdns_salvo_phy_power_off(struct phy *phy)
return 0;
}
-static struct phy_ops cdns_salvo_phy_ops = {
+static const struct phy_ops cdns_salvo_phy_ops = {
.init = cdns_salvo_phy_init,
.power_on = cdns_salvo_phy_power_on,
.power_off = cdns_salvo_phy_power_off,
--
2.28.0
[PATCH 6/8] phy: ralink-usb: Constify ralink_usb_phy_ops
The only usage is to pass its address to devm_phy_create() which takes a
const pointer. Make it const to allow the compiler to put it in
read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/phy/ralink/phy-ralink-usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/ralink/phy-ralink-usb.c
b/drivers/phy/ralink/phy-ralink-usb.c
index ba3c197fc5b0..95dfa9fd284d 100644
--- a/drivers/phy/ralink/phy-ralink-usb.c
+++ b/drivers/phy/ralink/phy-ralink-usb.c
@@ -142,7 +142,7 @@ static int ralink_usb_phy_power_off(struct phy *_phy)
return 0;
}
-static struct phy_ops ralink_usb_phy_ops = {
+static const struct phy_ops ralink_usb_phy_ops = {
.power_on = ralink_usb_phy_power_on,
.power_off = ralink_usb_phy_power_off,
.owner = THIS_MODULE,
--
2.28.0
[PATCH 8/8] phy: qcom-ipq4019-usb: Constify static phy_ops structs
Their only usages is to assign the address to the data field in the
of_device_id struct, which is a const void pointer. Make them const to
allow the compiler to put them in read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/phy/qualcomm/phy-qcom-ipq4019-usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-ipq4019-usb.c
b/drivers/phy/qualcomm/phy-qcom-ipq4019-usb.c
index b8ef331e1545..fc7f9df80a7b 100644
--- a/drivers/phy/qualcomm/phy-qcom-ipq4019-usb.c
+++ b/drivers/phy/qualcomm/phy-qcom-ipq4019-usb.c
@@ -48,7 +48,7 @@ static int ipq4019_ss_phy_power_on(struct phy *_phy)
return 0;
}
-static struct phy_ops ipq4019_usb_ss_phy_ops = {
+static const struct phy_ops ipq4019_usb_ss_phy_ops = {
.power_on = ipq4019_ss_phy_power_on,
.power_off = ipq4019_ss_phy_power_off,
};
@@ -80,7 +80,7 @@ static int ipq4019_hs_phy_power_on(struct phy *_phy)
return 0;
}
-static struct phy_ops ipq4019_usb_hs_phy_ops = {
+static const struct phy_ops ipq4019_usb_hs_phy_ops = {
.power_on = ipq4019_hs_phy_power_on,
.power_off = ipq4019_hs_phy_power_off,
};
--
2.28.0
