Re: [PATCH v2 1/3] dt-bindings: pinctrl: qcom: Define common TLMM binding
On Tue, Jan 26, 2021 at 5:26 AM Bjorn Andersson wrote: > Several properties are shared between all TLMM bindings. By providing a > common binding to define these properties each platform's binding can be > reduced to just listing which of these properties should be checked for > - or further specified. > > Reviewed-by: Vinod Koul > Signed-off-by: Bjorn Andersson Patches applied! Good work with the YAML conversion here, much appreciated! Yours, Linus Walleij
[PATCH 4.19 00/27] 4.19.176-rc2 review
This is the start of the stable review cycle for the 4.19.176 release. There are 27 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun, 14 Feb 2021 07:42:29 +. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.176-rc2.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 4.19.176-rc2 Mark Brown regulator: Fix lockdep warning resolving supplies Douglas Anderson regulator: core: Clean enabling always-on regulators + their supplies Olliver Schinagl regulator: core: enable power when setting up constraints Phillip Lougher squashfs: add more sanity checks in xattr id lookup Phillip Lougher squashfs: add more sanity checks in inode lookup Phillip Lougher squashfs: add more sanity checks in id lookup Ming Lei blk-mq: don't hold q->sysfs_lock in blk_mq_map_swqueue Ming Lei block: don't hold q->sysfs_lock in elevator_init_mq Peter Gonda Fix unsynchronized access to sev members through svm_register_enc_region Theodore Ts'o memcg: fix a crash in wb_workfn when a device disappears Qian Cai include/trace/events/writeback.h: fix -Wstringop-truncation warnings Tobin C. Harding lib/string: Add strscpy_pad() function Dave Wysochanski SUNRPC: Handle 0 length opaque XDR object data properly Dave Wysochanski SUNRPC: Move simple_get_bytes and simple_get_netobj into private header Johannes Berg iwlwifi: mvm: guard against device removal in reprobe Johannes Berg iwlwifi: pcie: fix context info memory leak Emmanuel Grumbach iwlwifi: pcie: add a NULL check in iwl_pcie_txq_unmap Johannes Berg iwlwifi: mvm: take mutex for calling iwl_mvm_get_sync_time() Trond Myklebust pNFS/NFSv4: Try to return invalid layout in pnfs_layout_process() Pan Bian chtls: Fix potential resource leak David Collins regulator: core: avoid regulator_resolve_supply() race condition Cong Wang af_key: relax availability checks for skb size calculation Sibi Sankar remoteproc: qcom_q6v5_mss: Validate MBA firmware size before load Sibi Sankar remoteproc: qcom_q6v5_mss: Validate modem blob firmware size before load Steven Rostedt (VMware) fgraph: Initialize tracing_graph_pause at task creation zhengbin block: fix NULL pointer dereference in register_disk Masami Hiramatsu tracing/kprobe: Fix to support kretprobe events on unloaded modules - Diffstat: Makefile | 4 +- arch/x86/kvm/svm.c | 18 +++-- block/blk-mq.c | 7 -- block/elevator.c | 14 ++-- block/genhd.c | 10 +-- drivers/crypto/chelsio/chtls/chtls_cm.c| 7 +- .../net/wireless/intel/iwlwifi/mvm/debugfs-vif.c | 3 + drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 3 +- .../wireless/intel/iwlwifi/pcie/ctxt-info-gen3.c | 11 ++- drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 5 ++ drivers/regulator/core.c | 84 +++--- drivers/remoteproc/qcom_q6v5_pil.c | 11 ++- fs/fs-writeback.c | 2 +- fs/nfs/pnfs.c | 8 ++- fs/squashfs/export.c | 41 --- fs/squashfs/id.c | 40 --- fs/squashfs/squashfs_fs_sb.h | 1 + fs/squashfs/super.c| 6 +- fs/squashfs/xattr.h| 10 ++- fs/squashfs/xattr_id.c | 66 ++--- include/linux/backing-dev.h| 10 +++ include/linux/kprobes.h| 2 +- include/linux/string.h | 4 ++ include/linux/sunrpc/xdr.h | 3 +- include/trace/events/writeback.h | 35 + init/init_task.c | 3 +- kernel/kprobes.c | 34 ++--- kernel/trace/ftrace.c | 2 - kernel/trace/trace_kprobe.c| 4 +- lib/string.c | 47 ++-- mm/backing-dev.c | 1 + net/key/af_key.c | 6 +- net/sunrpc/auth_gss/auth_gss.c | 30 +--- net/sunrpc/auth_gss/auth_gss_internal.h
Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated
On Fri, Feb 12, 2021 at 6:47 AM Nicolas Boichat wrote:
>
> Filesystems such as procfs and sysfs generate their content at
> runtime. This implies the file sizes do not usually match the
> amount of data that can be read from the file, and that seeking
> may not work as intended.
>
> This will be useful to disallow copy_file_range with input files
> from such filesystems.
>
> Signed-off-by: Nicolas Boichat
> ---
> I first thought of adding a new field to struct file_operations,
> but that doesn't quite scale as every single file creation
> operation would need to be modified.
>
> include/linux/fs.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 3482146b11b0..5bd58b928e94 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -2335,6 +2335,7 @@ struct file_system_type {
> #define FS_ALLOW_IDMAP 32 /* FS has been updated to handle vfs
> idmappings. */
> #define FS_THP_SUPPORT 8192/* Remove once all fs converted */
> #define FS_RENAME_DOES_D_MOVE 32768 /* FS will handle d_move() during
> rename() internally. */
> +#define FS_GENERATED_CONTENT 65536 /* FS contains generated content */
Can you please make the flag name a little less arbitrary.
Either something that conveys the facts as they are (e.g. "zero size
but readable")
or anything that you think describes best the special behavior that follows from
observing this flag.
The alternative is for the flag name to express what you want
(e.g. "don't copy file range") like FS_DISALLOW_NOTIFY_PERM.
Also, I wonder. A great deal of the files you target are opened with seq_open()
(I didn't audit all of them). Maybe it's worth setting an FMODE flag
in seq_open()
and some of it's relatives to express the quality of the file instead
of flagging
the filesystem? Maybe we can do both to cover more cases.
Thanks,
Amir.
Re: [PATCH] virt: acrn: Fix vCPU removing code build error
On Fri, Feb 12, 2021 at 12:57:24PM +0800, shuo.a@intel.com wrote:
> From: Shuo Liu
>
> vCPU removing code depends on CONFIG_HOTPLUG_CPU as it uses remove_cpu()
> and add_cpu(). Make the vCPU removing interface building with
> CONFIG_HOTPLUG_CPU.
>
> ../drivers/virt/acrn/hsm.c: In function ‘remove_cpu_store’:
> ../drivers/virt/acrn/hsm.c:389:3: error: implicit declaration of function
> ‘remove_cpu’; [-Werror=implicit-function-declaration]
>remove_cpu(cpu);
>
> ../drivers/virt/acrn/hsm.c:402:2: error: implicit declaration of function
> ‘add_cpu’; [-Werror=implicit-function-declaration]
>add_cpu(cpu);
>
> Fixes: 279dcf693ac7 ("virt: acrn: Introduce an interface for Service VM to
> control vCPU")
> Reported-by: Randy Dunlap
> Acked-by: Randy Dunlap # build-tested
> Signed-off-by: Shuo Liu
> ---
> drivers/virt/acrn/hsm.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/virt/acrn/hsm.c b/drivers/virt/acrn/hsm.c
> index 1f6b7c54a1a4..e340788aacdf 100644
> --- a/drivers/virt/acrn/hsm.c
> +++ b/drivers/virt/acrn/hsm.c
> @@ -372,6 +372,7 @@ static int acrn_dev_release(struct inode *inode, struct
> file *filp)
> return 0;
> }
>
> +#ifdef CONFIG_HOTPLUG_CPU
> static ssize_t remove_cpu_store(struct device *dev,
> struct device_attribute *attr,
> const char *buf, size_t count)
> @@ -403,9 +404,12 @@ static ssize_t remove_cpu_store(struct device *dev,
> return ret;
> }
> static DEVICE_ATTR_WO(remove_cpu);
> +#endif
>
> static struct attribute *acrn_attrs[] = {
> +#ifdef CONFIG_HOTPLUG_CPU
> _attr_remove_cpu.attr,
> +#endif
> NULL
> };
>
>
Shouldn't the real solution for this be that remove_cpu() and add_cpu()
have function prototypes for when this is not enabled in the kernel
build?
Putting #ifdef in .c files like this is not a good idea at all.
Then, at runtime, you can determine if you need to create this sysfs
file or not, as you do not want to expose it to userspace if the kernel
can not handle it, right?
thanks,
greg k-h
Re: [GIT PULL v2] extcon next for v5.12
On Fri, Feb 12, 2021 at 02:19:37PM +0900, Chanwoo Choi wrote: > Dear Greg, > > This is extcon-next pull request for v5.12. I add detailed description of > this pull request on below. Please pull extcon with following updates. > > Changes from v1: > - Add missing committer information > > Best Regards, > Chanwoo Choi > > > The following changes since commit 6ee1d745b7c9fd573fba142a2efdad76a9f1cb04: > > Linux 5.11-rc5 (2021-01-24 16:47:14 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git > tags/extcon-next-for-5.12-v2 > > for you to fetch changes up to bd30a35764e136dc372e74c4856de633cb7ed8de: > > extcon: sm5502: Detect OTG when USB_ID is connected to ground > (2021-02-10 08:15:28 +0900) > > > Krzysztof Kozlowski (1): > extcon: Add stubs for extcon_register_notifier_all() functions > > Nikita Travkin (1): > extcon: sm5502: Detect OTG when USB_ID is connected to ground > > Timon Baetz (1): > extcon: max8997: Add CHGINS and CHGRM interrupt handling No diffstat??? How did you generate this pull request? thanks, greg k-h
Re: [PATCH v6 0/2] pinctrl: qcom: Add SM8350 pinctrl support
On Fri, Feb 5, 2021 at 3:01 PM Vinod Koul wrote: > This adds binding and driver for TLMM block found in SM8350 SoC > > The binding is dependent on TLMM common binding from Bjorn: > > https://lore.kernel.org/linux-arm-msm/20210126042650.1725176-1-bjorn.anders...@linaro.org > > Changes in v6: > - Add rob and bjorn r-b > - removed quotes around 'defs' and drop the phandle for binding Patches applied! Thanks! Linus Walleij
Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated
On Fri, Feb 12, 2021 at 12:44:00PM +0800, Nicolas Boichat wrote: > Filesystems such as procfs and sysfs generate their content at > runtime. This implies the file sizes do not usually match the > amount of data that can be read from the file, and that seeking > may not work as intended. > > This will be useful to disallow copy_file_range with input files > from such filesystems. > > Signed-off-by: Nicolas Boichat > --- > I first thought of adding a new field to struct file_operations, > but that doesn't quite scale as every single file creation > operation would need to be modified. Even so, you missed a load of filesystems in the kernel with this patch series, what makes the ones you did mark here different from the "internal" filesystems that you did not? This feels wrong, why is userspace suddenly breaking? What changed in the kernel that caused this? Procfs has been around for a _very_ long time :) thanks, greg k-h
Re: [PATCH] scripts: Fix linking extract-cert against libcrypto
Am Donnerstag, 11. Februar 2021, 11:29:33 CET schrieb Rolf Eike Beer:
> I'm just guessing, but your build error looks like you are also
> cross-building the tools, which is wrong. You want them to be host-tools.
> So don't export PKG_CONFIG_SYSROOT_DIR, it would then try to link target
> libraries into a host binary.
I have looked again how I do it:
# this is for additional _host_ .pc files
export PKG_CONFIG_PATH=${prefix}/lib/pkgconfig
Then have a target-pkg-config, so this code inside several kernel Makefiles
will work:
PKG_CONFIG ?= $(CROSS_COMPILE)pkg-config
And then export your PKG_CONFIG_SYSROOT_DIR and the like inside that. I bet
you have all of this already in place, so just remove the SYSROOT_DIR from
your kernel build script and things should work.
Eike
--
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055
emlix - smart embedded open source
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH v2] PCI: designware-ep: Fix the reference to pci->num_{ib,ob}_windows before setting
Cc: Hou Zhiqiang
I found that this patch would cause null pointer dereference exception
when removing the function link.
If once linking the test function to the controller,
# ln -s functions/pci_epf_test/test controllers/6600.pcie-ep/
and unlinking it immediately,
# rm controllers/6600.pcie-ep/test
then the driver will occur null pointer access in dw_pcie_ep_clear_bar()
because ep->ib_window_map doesn't have a pointer to allocated memory yet.
To fix the original issue, I strongly recommend to apply Hou's patch [1]
instead of this patch.
Thank you,
[1]
https://patchwork.kernel.org/project/linux-pci/patch/20210125044803.4310-1-zhiqiang@nxp.com/
On 2021/01/21 0:20, Rob Herring wrote:
On Mon, Jan 18, 2021 at 5:10 PM Kunihiko Hayashi
wrote:
The commit 281f1f99cf3a ("PCI: dwc: Detect number of iATU windows") gets
the values of pci->num_ib_windows and pci->num_ob_windows from iATU
registers instead of DT properties in dw_pcie_iatu_detect_regions*() or its
unroll version.
However, before the values are set, the allocations in dw_pcie_ep_init()
refer them to determine the sizes of window_map. As a result, null pointer
dereference exception will occur when linking the EP function and the
controller.
# ln -s functions/pci_epf_test/test controllers/6600.pcie-ep/
Unable to handle kernel NULL pointer dereference at virtual address
0010
The call trace is as follows:
Call trace:
_find_next_bit.constprop.1+0xc/0x88
dw_pcie_ep_set_bar+0x78/0x1f8
pci_epc_set_bar+0x9c/0xe8
pci_epf_test_core_init+0xe8/0x220
pci_epf_test_bind+0x1e0/0x378
pci_epf_bind+0x54/0xb0
pci_epc_epf_link+0x58/0x80
configfs_symlink+0x1c0/0x570
vfs_symlink+0xdc/0x198
do_symlinkat+0xa0/0x110
__arm64_sys_symlinkat+0x28/0x38
el0_svc_common+0x84/0x1a0
do_el0_svc+0x38/0x88
el0_svc+0x1c/0x28
el0_sync_handler+0x88/0xb0
el0_sync+0x140/0x180
The pci->num_{ib,ob}_windows should be referenced after they are set by
dw_pcie_iatu_detect_regions*() called from dw_pcie_setup().
Cc: Rob Herring
Fixes: 281f1f99cf3a ("PCI: dwc: Detect number of iATU windows")
Signed-off-by: Kunihiko Hayashi
---
drivers/pci/controller/dwc/pcie-designware-ep.c | 41 -
1 file changed, 20 insertions(+), 21 deletions(-)
Reviewed-by: Rob Herring
--
---
Best Regards
Kunihiko Hayashi
Re: [PATCH net-next v2] misc: Add Renesas Synchronization Management Unit (SMU) support
On Thu, Feb 11, 2021 at 08:16:15PM -0500, min.li...@renesas.com wrote: > From: Min Li > > This driver supports 1588 related functions of ClockMatrix(TM) > and 82P33xxx families of timing and synchronization devices. > > The driver is developed to be only used by Renesas PTP Clock > Manager for Linux (pcm4l) software. It supports 1588/PTP > releated functionalities that specific to Renesas devices > but are not supported by general PHC framework. So pcm4l > will use both the existing PHC driver and this module to > complete 1588/PTP support. The supported functons are: > > -set combomode > -get dpll's state > -get dpll's ffo > > This driver must work with Renesas MFD driver to access SMU > through I2C/SPI. > > Changes since v1: > -Provide more background for purpose of the change. > -Provide compat_ioctl support > -Fix ioctl cmd definition This "changes" list goes below the --- line. And you seem to have ignored my review, especially about documenting the sysfs files here, please do that as I can not accept this patch as-is. greg k-h
Re: kernel BUG at mm/zswap.c:1275! (rc6 - git 61556703b610)
Hello. On Thu, Feb 11, 2021 at 10:43:18AM +, Song Bao Hua (Barry Song) wrote: > Are you using zsmalloc? There is a known bug on the combination > of zsmalloc and zswap, fixed by patches of tiantao: > > mm: set the sleep_mapped to true for zbud and z3fold > mm/zswap: fix variable 'entry' is uninitialized when used > mm/zswap: fix potential memory leak > mm/zswap: add the flag can_sleep_mapped > > at Linux-next: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?qt=author=tiantao6%40hisilicon.com Is this a future stable-5.11 material (and/or, potentially, older stable branches as well)? -- Oleksandr Natalenko (post-factum)
Re: [PATCH 4.19 00/24] 4.19.176-rc1 review
On Fri, Feb 12, 2021 at 10:16:11AM +0530, Naresh Kamboju wrote: > On Thu, 11 Feb 2021 at 20:36, Greg Kroah-Hartman > wrote: > > > > This is the start of the stable review cycle for the 4.19.176 release. > > There are 24 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sat, 13 Feb 2021 15:01:39 +. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.176-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-4.19.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > The following lockdep noticed on the arm beaglebone x15 device. > I have not bisected this problem yet. > Suspecting this patch, > > > David Collins > > regulator: core: avoid regulator_resolve_supply() race condition Sasha queued up a fix for this, let me push out a -rc2 with that in there to see if this resolves the issue. thanks greg k-h
Re: [PATCH net-next v2] misc: Add Renesas Synchronization Management Unit (SMU) support
On Thu, Feb 11, 2021 at 08:16:15PM -0500, min.li...@renesas.com wrote:
> +static int
> +rsmu_open(struct inode *iptr, struct file *fptr)
> +{
> + struct rsmu_cdev *rsmu;
> +
> + rsmu = container_of(iptr->i_cdev, struct rsmu_cdev, rsmu_cdev);
> + if (!rsmu)
> + return -EAGAIN;
> +
> + /* Only one open per device at a time */
> + if (!atomic_dec_and_test(>open_count)) {
> + atomic_inc(>open_count);
> + return -EBUSY;
This does not do what you think it does, and does not prevent multiple
applications from talking to your device at the same time.
There is no need for this at all, as it does not work, sorry. If
multiple apps talk to your device, it's their fault, not the kernel's
fault, that things go wrong.
And I thought that Arnd already told you to fix this?
thanks,
greg k-h
Re: [PATCH v2] drm/msm: a6xx: Make sure the SQE microcode is safe
On 2/11/2021 9:32 PM, Jordan Crouse wrote:
On Thu, Feb 11, 2021 at 06:50:28PM +0530, Akhil P Oommen wrote:
On 2/10/2021 6:22 AM, Jordan Crouse wrote:
Most a6xx targets have security issues that were fixed with new versions
of the microcode(s). Make sure that we are booting with a safe version of
the microcode for the target and print a message and error if not.
v2: Add more informative error messages and fix typos
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 77 ++-
1 file changed, 64 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index ba8e9d3cf0fe..064b7face504 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -522,28 +522,73 @@ static int a6xx_cp_init(struct msm_gpu *gpu)
return a6xx_idle(gpu, ring) ? 0 : -EINVAL;
}
-static void a6xx_ucode_check_version(struct a6xx_gpu *a6xx_gpu,
+/*
+ * Check that the microcode version is new enough to include several key
+ * security fixes. Return true if the ucode is safe.
+ */
+static bool a6xx_ucode_check_version(struct a6xx_gpu *a6xx_gpu,
struct drm_gem_object *obj)
{
+ struct adreno_gpu *adreno_gpu = _gpu->base;
+ struct msm_gpu *gpu = _gpu->base;
u32 *buf = msm_gem_get_vaddr(obj);
+ bool ret = false;
if (IS_ERR(buf))
- return;
+ return false;
/*
-* If the lowest nibble is 0xa that is an indication that this microcode
-* has been patched. The actual version is in dword [3] but we only care
-* about the patchlevel which is the lowest nibble of dword [3]
-*
-* Otherwise check that the firmware is greater than or equal to 1.90
-* which was the first version that had this fix built in
+* Targets up to a640 (a618, a630 and a640) need to check for a
+* microcode version that is patched to support the whereami opcode or
+* one that is new enough to include it by default.
*/
- if (((buf[0] & 0xf) == 0xa) && (buf[2] & 0xf) >= 1)
- a6xx_gpu->has_whereami = true;
- else if ((buf[0] & 0xfff) > 0x190)
- a6xx_gpu->has_whereami = true;
+ if (adreno_is_a618(adreno_gpu) || adreno_is_a630(adreno_gpu) ||
+ adreno_is_a640(adreno_gpu)) {
nit: I feel a 'switch(revn)' would be more readable.
Reviewed-by: Akhil P Oommen
-Akhil
+ /*
+* If the lowest nibble is 0xa that is an indication that this
+* microcode has been patched. The actual version is in dword
+* [3] but we only care about the patchlevel which is the lowest
+* nibble of dword [3]
+*
+* Otherwise check that the firmware is greater than or equal
+* to 1.90 which was the first version that had this fix built
+* in
+*/
+ if buf[0] & 0xf) == 0xa) && (buf[2] & 0xf) >= 1) ||
+ (buf[0] & 0xfff) >= 0x190) {
+ a6xx_gpu->has_whereami = true;
+ ret = true;
+ goto out;
+ }
+ DRM_DEV_ERROR(>pdev->dev,
+ "a630 SQE ucode is too old. Have version %x need at least
%x\n",
+ buf[0] & 0xfff, 0x190);
+ } else {
+ /*
+* a650 tier targets don't need whereami but still need to be
+* equal to or newer than 1.95 for other security fixes
+*/
+ if (adreno_is_a650(adreno_gpu)) {
+ if ((buf[0] & 0xfff) >= 0x195) {
+ ret = true;
+ goto out;
+ }
+
+ DRM_DEV_ERROR(>pdev->dev,
+ "a650 SQE ucode is too old. Have version %x need at
least %x\n",
+ buf[0] & 0xfff, 0x195);
+ }
+
+ /*
+* When a660 is added those targets should return true here
+* since those have all the critical security fixes built in
+* from the start
+*/
Or we can just initialize 'ret' as true.
I thought about it and I think I want to force an accept list here instead of
letting new targets get by with an implicit pass.
Jordan
-Akhil
+ }
+out:
msm_gem_put_vaddr(obj);
+ return ret;
}
static int a6xx_ucode_init(struct msm_gpu *gpu)
@@ -566,7 +611,13 @@ static int a6xx_ucode_init(struct msm_gpu *gpu)
}
msm_gem_object_set_name(a6xx_gpu->sqe_bo, "sqefw");
- a6xx_ucode_check_version(a6xx_gpu, a6xx_gpu->sqe_bo);
+ if (!a6xx_ucode_check_version(a6xx_gpu, a6xx_gpu->sqe_bo)) {
+
[PATCH] Documentation: connector: Update the description of sink-vdos
Remove the acronym "VDM" and replace it with the full name "Vendor Defined Message". Signed-off-by: Kyle Tso --- .../devicetree/bindings/connector/usb-connector.yaml | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml index d385026944ec..ce11b2027199 100644 --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml @@ -138,9 +138,10 @@ properties: $ref: /schemas/types.yaml#/definitions/uint32-array sink-vdos: -description: An array of u32 with each entry (VDM Objects) providing additional information - corresponding to the product, the detailed bit definitions and the order of each VDO can be - found in "USB Power Delivery Specification Revision 3.0, Version 2.0 + ECNs 2020-12-10" +description: An array of u32 with each entry, a Vendor Defined Message Object (VDO), + providing additional information corresponding to the product, the detailed bit + definitions and the order of each VDO can be found in + "USB Power Delivery Specification Revision 3.0, Version 2.0 + ECNs 2020-12-10" chapter 6.4.4.3.1 Discover Identity. User can specify the VDO array via VDO_IDH/_CERT/_PRODUCT/_UFP/_DFP/_PCABLE/_ACABLE(1/2)/_VPD() defined in dt-bindings/usb/pd.h. -- 2.30.0.478.g8a0d178c01-goog
Re: [PATCH v2 0/2] of: of_device.h cleanups
On Thu, Feb 11, 2021 at 05:27:43PM -0600, Rob Herring wrote: > This is a couple of cleanups for of_device.h. They fell out from my > attempt at decoupling of_device.h and of_platform.h which is a mess > and I haven't finished, but there's no reason to wait on these. Reviewed-by: Greg Kroah-Hartman
[PATCH -next] staging: nvec: minor coding style fix
Fix for the below coding style warning.
Warning: Move const after static - use 'static const int'
Signed-off-by: Fatih Yildirim
---
drivers/staging/nvec/nvec_power.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/nvec/nvec_power.c
b/drivers/staging/nvec/nvec_power.c
index 0e861c4bfcbf..b1ef196e1cfe 100644
--- a/drivers/staging/nvec/nvec_power.c
+++ b/drivers/staging/nvec/nvec_power.c
@@ -338,7 +338,7 @@ static const struct power_supply_desc nvec_psy_desc = {
};
static int counter;
-static int const bat_iter[] = {
+static const int bat_iter[] = {
SLOT_STATUS, VOLTAGE, CURRENT, CAPACITY_REMAINING,
#ifdef EC_FULL_DIAG
AVERAGE_CURRENT, TEMPERATURE, TIME_REMAINING,
--
2.20.1
[PATCH 10/13] dt-bindings: watchdog: Add compatible for SC7280 SoC
From: Sai Prakash Ranjan Add compatible for watchdog timer on SC7280 SoC. Signed-off-by: Sai Prakash Ranjan Signed-off-by: Rajendra Nayak --- Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml index 8e3760a..b5b1268 100644 --- a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml @@ -17,6 +17,7 @@ properties: enum: - qcom,apss-wdt-qcs404 - qcom,apss-wdt-sc7180 + - qcom,apss-wdt-sc7280 - qcom,apss-wdt-sdm845 - qcom,apss-wdt-sm8150 - qcom,kpss-timer -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 11/13] arm64: dts: qcom: sc7280: Add APSS watchdog node
From: Sai Prakash Ranjan
Add APSS (Application Processor Subsystem) watchdog
DT node for SC7280 SoC.
Signed-off-by: Sai Prakash Ranjan
Signed-off-by: Rajendra Nayak
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index b5b9b6a..ef82d77 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -399,6 +399,13 @@
};
};
+ watchdog@17c1 {
+ compatible = "qcom,apss-wdt-sc7280", "qcom,kpss-wdt";
+ reg = <0 0x17c1 0 0x1000>;
+ clocks = <_clk>;
+ interrupts = ;
+ };
+
timer@17c2 {
#address-cells = <2>;
#size-cells = <2>;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 13/13] arm64: dts: qcom: sc7280: Add cpuidle states
From: Maulik Shah
Add cpuidle states for little and big cpus.
Signed-off-by: Maulik Shah
Signed-off-by: Rajendra Nayak
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 78
1 file changed, 78 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 8f2002b..3b86052 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -99,6 +99,9 @@
compatible = "arm,kryo";
reg = <0x0 0x0>;
enable-method = "psci";
+ cpu-idle-states = <_CPU_SLEEP_0
+ _CPU_SLEEP_1
+ _SLEEP_0>;
next-level-cache = <_0>;
L2_0: l2-cache {
compatible = "cache";
@@ -114,6 +117,9 @@
compatible = "arm,kryo";
reg = <0x0 0x100>;
enable-method = "psci";
+ cpu-idle-states = <_CPU_SLEEP_0
+ _CPU_SLEEP_1
+ _SLEEP_0>;
next-level-cache = <_100>;
L2_100: l2-cache {
compatible = "cache";
@@ -126,6 +132,9 @@
compatible = "arm,kryo";
reg = <0x0 0x200>;
enable-method = "psci";
+ cpu-idle-states = <_CPU_SLEEP_0
+ _CPU_SLEEP_1
+ _SLEEP_0>;
next-level-cache = <_200>;
L2_200: l2-cache {
compatible = "cache";
@@ -138,6 +147,9 @@
compatible = "arm,kryo";
reg = <0x0 0x300>;
enable-method = "psci";
+ cpu-idle-states = <_CPU_SLEEP_0
+ _CPU_SLEEP_1
+ _SLEEP_0>;
next-level-cache = <_300>;
L2_300: l2-cache {
compatible = "cache";
@@ -150,6 +162,9 @@
compatible = "arm,kryo";
reg = <0x0 0x400>;
enable-method = "psci";
+ cpu-idle-states = <_CPU_SLEEP_0
+ _CPU_SLEEP_1
+ _SLEEP_0>;
next-level-cache = <_400>;
L2_400: l2-cache {
compatible = "cache";
@@ -162,6 +177,9 @@
compatible = "arm,kryo";
reg = <0x0 0x500>;
enable-method = "psci";
+ cpu-idle-states = <_CPU_SLEEP_0
+ _CPU_SLEEP_1
+ _SLEEP_0>;
next-level-cache = <_500>;
L2_500: l2-cache {
compatible = "cache";
@@ -174,6 +192,9 @@
compatible = "arm,kryo";
reg = <0x0 0x600>;
enable-method = "psci";
+ cpu-idle-states = <_CPU_SLEEP_0
+ _CPU_SLEEP_1
+ _SLEEP_0>;
next-level-cache = <_600>;
L2_600: l2-cache {
compatible = "cache";
@@ -186,12 +207,69 @@
compatible = "arm,kryo";
reg = <0x0 0x700>;
enable-method = "psci";
+ cpu-idle-states = <_CPU_SLEEP_0
+ _CPU_SLEEP_1
+ _SLEEP_0>;
next-level-cache = <_700>;
L2_700: l2-cache {
compatible = "cache";
next-level-cache = <_0>;
};
};
+
+ idle-states {
+ entry-method = "psci";
+
+ LITTLE_CPU_SLEEP_0: cpu-sleep-0-0 {
+ compatible = "arm,idle-state";
+ idle-state-name = "little-power-down";
+ arm,psci-suspend-param = <0x4003>;
+ entry-latency-us = <549>;
+ exit-latency-us = <901>;
+ min-residency-us = <1774>;
+ local-timer-stop;
+ };
+
+ LITTLE_CPU_SLEEP_1: cpu-sleep-0-1 {
+
[PATCH 04/13] dt-bindings: qcom,pdc: Add compatible for sc7280
Add the compatible string for sc7180 SoC from Qualcomm Signed-off-by: Rajendra Nayak --- Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt index 1df2939..9345c2e 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt @@ -19,6 +19,7 @@ Properties: Value type: Definition: Should contain "qcom,-pdc" and "qcom,pdc" - "qcom,sc7180-pdc": For SC7180 + - "qcom,sc7280-pdc": For SC7280 - "qcom,sdm845-pdc": For SDM845 - reg: -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 08/13] arm64: dts: qcom: sc7280: Add device node for APPS SMMU
From: Sai Prakash Ranjan
Adding device node for APPS SMMU available on SC7280 chipset.
This is shared among the multiple client devices such as
display, video, usb, mmc and others.
Signed-off-by: Sai Prakash Ranjan
Signed-off-by: Rajendra Nayak
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 89
1 file changed, 89 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 10851e7..f71ba21 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -280,6 +280,95 @@
};
};
+ apps_smmu: iommu@1500 {
+ compatible = "qcom,sc7280-smmu-500", "arm,mmu-500";
+ reg = <0 0x1500 0 0x10>;
+ #iommu-cells = <2>;
+ #global-interrupts = <1>;
+ dma-coherent;
+ interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+ };
+
intc: interrupt-controller@17a0 {
compatible = "arm,gic-v3";
#address-cells = <2>;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 12/13] arm64: dts: qcom: sc7280: Add SPMI PMIC arbiter device for SC7280
From: satya priya
Add SPMI PMIC arbiter device to communicate with PMICs
attached to SPMI bus.
Signed-off-by: satya priya
Signed-off-by: Rajendra Nayak
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index ef82d77..8f2002b 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -273,6 +273,25 @@
interrupt-controller;
};
+ spmi_bus: qcom,spmi@c44 {
+ compatible = "qcom,spmi-pmic-arb";
+ reg = <0 0x0c44 0 0x1100>,
+ <0 0x0c60 0 0x200>,
+ <0 0x0e60 0 0x10>,
+ <0 0x0e70 0 0xa>,
+ <0 0x0c40a000 0 0x26000>;
+ reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
+ interrupt-names = "periph_irq";
+ interrupts-extended = < 1 IRQ_TYPE_LEVEL_HIGH>;
+ qcom,ee = <0>;
+ qcom,channel = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-controller;
+ #interrupt-cells = <4>;
+ cell-index = <0>;
+ };
+
tlmm: pinctrl@f10 {
compatible = "qcom,sc7280-pinctrl";
reg = <0 0xf10 0 0x100>;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 09/13] arm64: dts: qcom: Add reserved memory for fw
From: Maulik Shah
Add fw reserved memory area for CPUCP and AOP.
Signed-off-by: Maulik Shah
Signed-off-by: Rajendra Nayak
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index f71ba21..b5b9b6a 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -73,11 +73,21 @@
#size-cells = <2>;
ranges;
+ aop_mem: memory@8080 {
+ reg = <0x0 0x8080 0x0 0x6>;
+ no-map;
+ };
+
aop_cmd_db_mem: memory@8086 {
reg = <0x0 0x8086 0x0 0x2>;
compatible = "qcom,cmd-db";
no-map;
};
+
+ cpucp_mem: memory@80b0 {
+ no-map;
+ reg = <0x0 0x80b0 0x0 0x10>;
+ };
};
cpus {
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 07/13] dt-bindings: arm-smmu: Add compatible for SC7280 SoC
From: Sai Prakash Ranjan Add the SoC specific compatible for SC7280 implementing arm,mmu-500. Signed-off-by: Sai Prakash Ranjan Signed-off-by: Rajendra Nayak --- Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index 3b63f2a..c6e82ca 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -34,6 +34,7 @@ properties: items: - enum: - qcom,sc7180-smmu-500 + - qcom,sc7280-smmu-500 - qcom,sdm845-smmu-500 - qcom,sm8150-smmu-500 - qcom,sm8250-smmu-500 -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 06/13] arm64: dts: qcom: SC7280: Add rpmhcc clock controller node
Add rpmhcc clock controller node for SC7280. Also add the 'fixed
clock' nodes which can now be referenced in gcc.
Signed-off-by: Taniya Das
Signed-off-by: Rajendra Nayak
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 55
1 file changed, 55 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 7848e88..10851e7 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
@@ -29,6 +30,42 @@
clock-frequency = <32000>;
#clock-cells = <0>;
};
+
+ pcie_0_pipe_clk: pcie-0-pipe-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <1000>;
+ #clock-cells = <0>;
+ };
+
+ pcie_1_pipe_clk: pcie-1-pipe-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <1000>;
+ #clock-cells = <0>;
+ };
+
+ ufs_phy_rx_symbol_0_clk: ufs-phy-rx-symbol-0-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <1000>;
+ #clock-cells = <0>;
+ };
+
+ ufs_phy_rx_symbol_1_clk: ufs-phy-rx-symbol-1-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <1000>;
+ #clock-cells = <0>;
+ };
+
+ ufs_phy_tx_symbol_0_clk: ufs-phy-tx-symbol-0-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <1000>;
+ #clock-cells = <0>;
+ };
+
+ usb3_phy_wrapper_gcc_usb30_pipe_clk:
usb3-phy-wrapper-gcc-usb30-pipe-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <1000>;
+ #clock-cells = <0>;
+ };
};
reserved_memory: reserved-memory {
@@ -174,6 +211,17 @@
gcc: clock-controller@10 {
compatible = "qcom,gcc-sc7280";
reg = <0 0x0010 0 0x1f>;
+ clocks = < RPMH_CXO_CLK>,
+< RPMH_CXO_CLK_A>, <_clk>,
+<_0_pipe_clk>, <_1_pipe_clk>,
+<_phy_rx_symbol_0_clk>,
<_phy_rx_symbol_1_clk>,
+<_phy_tx_symbol_0_clk>,
+<_phy_wrapper_gcc_usb30_pipe_clk>;
+ clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk",
+ "pcie_0_pipe_clk", "pcie_1_pipe-clk",
+ "ufs_phy_rx_symbol_0_clk",
"ufs_phy_rx_symbol_1_clk",
+ "ufs_phy_tx_symbol_0_clk",
+ "usb3_phy_wrapper_gcc_usb30_pipe_clk";
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
@@ -325,6 +373,13 @@
,
,
;
+
+ rpmhcc: qcom,rpmhcc {
+ compatible = "qcom,sc7280-rpmh-clk";
+ clocks = <_board>;
+ clock-names = "xo";
+ #clock-cells = <1>;
+ };
};
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 00/13] Add binding updates and DT files for SC7280 SoC
This series includes a few minor binding updates and base device tree files (to boot to shell) for SC7280 SoC and the IDP board using this SoC. The series is dependent on a few driver patches to merge first, for gcc, rpmhcc and pinctrl https://lore.kernel.org/patchwork/project/lkml/list/?series=484517 https://lore.kernel.org/patchwork/project/lkml/list/?series=484489 https://lore.kernel.org/patchwork/patch/1379831/ Maulik Shah (3): arm64: dts: qcom: sc7280: Add RSC and PDC devices arm64: dts: qcom: Add reserved memory for fw arm64: dts: qcom: sc7280: Add cpuidle states Rajendra Nayak (5): dt-bindings: arm: qcom: Document SC7280 SoC and board dt-bindings: firmware: scm: Add SC7280 support arm64: dts: sc7280: Add basic dts/dtsi files for SC7280 soc dt-bindings: qcom,pdc: Add compatible for sc7280 arm64: dts: qcom: SC7280: Add rpmhcc clock controller node Sai Prakash Ranjan (4): dt-bindings: arm-smmu: Add compatible for SC7280 SoC arm64: dts: qcom: sc7280: Add device node for APPS SMMU dt-bindings: watchdog: Add compatible for SC7280 SoC arm64: dts: qcom: sc7280: Add APSS watchdog node satya priya (1): arm64: dts: qcom: sc7280: Add SPMI PMIC arbiter device for SC7280 Documentation/devicetree/bindings/arm/qcom.yaml| 6 + .../devicetree/bindings/firmware/qcom,scm.txt | 1 + .../bindings/interrupt-controller/qcom,pdc.txt | 1 + .../devicetree/bindings/iommu/arm,smmu.yaml| 1 + .../devicetree/bindings/watchdog/qcom-wdt.yaml | 1 + arch/arm64/boot/dts/qcom/Makefile | 1 + arch/arm64/boot/dts/qcom/sc7280-idp.dts| 47 ++ arch/arm64/boot/dts/qcom/sc7280.dtsi | 596 + 8 files changed, 654 insertions(+) create mode 100644 arch/arm64/boot/dts/qcom/sc7280-idp.dts create mode 100644 arch/arm64/boot/dts/qcom/sc7280.dtsi -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 03/13] arm64: dts: sc7280: Add basic dts/dtsi files for SC7280 soc
Add initial device tree support for the SC7280 SoC and the IDP
boards based on this SoC
Signed-off-by: Rajendra Nayak
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/sc7280-idp.dts | 47 +
arch/arm64/boot/dts/qcom/sc7280.dtsi| 294
3 files changed, 342 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sc7280-idp.dts
create mode 100644 arch/arm64/boot/dts/qcom/sc7280.dtsi
diff --git a/arch/arm64/boot/dts/qcom/Makefile
b/arch/arm64/boot/dts/qcom/Makefile
index 5113fac..6f16ff6 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -32,6 +32,7 @@ dtb-$(CONFIG_ARCH_QCOM) +=
sc7180-trogdor-lazor-r3-kb.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sc7180-trogdor-lazor-r3-lte.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sc7180-trogdor-r1.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sc7180-trogdor-r1-lte.dtb
+dtb-$(CONFIG_ARCH_QCOM)+= sc7280-idp.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm630-sony-xperia-ganges-kirin.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm630-sony-xperia-nile-discovery.dtb
dtb-$(CONFIG_ARCH_QCOM)+= sdm630-sony-xperia-nile-pioneer.dtb
diff --git a/arch/arm64/boot/dts/qcom/sc7280-idp.dts
b/arch/arm64/boot/dts/qcom/sc7280-idp.dts
new file mode 100644
index 000..428f863
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sc7280-idp.dts
@@ -0,0 +1,47 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * sc7280 IDP board device tree source
+ *
+ * Copyright (c) 2021, The Linux Foundation. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include "sc7280.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. SC7280 IDP platform";
+ compatible = "qcom,sc7280-idp";
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+_id_0 {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+/* PINCTRL - additions to nodes defined in sc7280.dtsi */
+
+_uart5_default {
+ tx {
+ pins = "gpio46";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ rx {
+ pins = "gpio47";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+};
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
new file mode 100644
index 000..1fe2eba
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -0,0 +1,294 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * sc7280 SoC device tree source
+ *
+ * Copyright (c) 2020-2021, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+
+/ {
+ interrupt-parent = <>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ chosen { };
+
+ clocks {
+ xo_board: xo-board {
+ compatible = "fixed-clock";
+ clock-frequency = <7680>;
+ #clock-cells = <0>;
+ };
+
+ sleep_clk: sleep-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <32000>;
+ #clock-cells = <0>;
+ };
+ };
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ CPU0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,kryo";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ next-level-cache = <_0>;
+ L2_0: l2-cache {
+ compatible = "cache";
+ next-level-cache = <_0>;
+ L3_0: l3-cache {
+ compatible = "cache";
+ };
+ };
+ };
+
+ CPU1: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,kryo";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ next-level-cache = <_100>;
+ L2_100: l2-cache {
+ compatible = "cache";
+ next-level-cache = <_0>;
+ };
+ };
+
+ CPU2: cpu@200 {
+ device_type = "cpu";
+ compatible = "arm,kryo";
+ reg = <0x0 0x200>;
+ enable-method = "psci";
+ next-level-cache = <_200>;
+ L2_200: l2-cache {
+ compatible = "cache";
+ next-level-cache = <_0>;
+ };
+ };
+
+ CPU3: cpu@300 {
+ device_type = "cpu";
+ compatible = "arm,kryo";
+
[PATCH 02/13] dt-bindings: firmware: scm: Add SC7280 support
Add compatible for SC7280 SoC Signed-off-by: Rajendra Nayak --- Documentation/devicetree/bindings/firmware/qcom,scm.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt index 7845643..4871fc5 100644 --- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt @@ -20,6 +20,7 @@ Required properties: * "qcom,scm-msm8996" * "qcom,scm-msm8998" * "qcom,scm-sc7180" + * "qcom,scm-sc7280" * "qcom,scm-sdm845" * "qcom,scm-sm8150" and: -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 05/13] arm64: dts: qcom: sc7280: Add RSC and PDC devices
From: Maulik Shah
Add PDC interrupt controller along with apps RSC device.
Also add reserved memory for command_db.
Signed-off-by: Maulik Shah
Signed-off-by: Rajendra Nayak
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 44
1 file changed, 44 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 1fe2eba..7848e88 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -7,6 +7,7 @@
#include
#include
+#include
/ {
interrupt-parent = <>;
@@ -30,6 +31,18 @@
};
};
+ reserved_memory: reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ aop_cmd_db_mem: memory@8086 {
+ reg = <0x0 0x8086 0x0 0x2>;
+ compatible = "qcom,cmd-db";
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <2>;
#size-cells = <0>;
@@ -189,6 +202,19 @@
};
};
+ pdc: interrupt-controller@b22 {
+ compatible = "qcom,sc7280-pdc", "qcom,pdc";
+ reg = <0 0xb22 0 0x3>;
+ qcom,pdc-ranges = <0 480 40>, <40 140 14>, <54 263 1>,
+ <55 306 4>, <59 312 3>, <62 374 2>,
+ <64 434 2>, <66 438 3>, <69 86 1>,
+ <70 520 54>, <124 609 31>, <155 63 1>,
+ <156 716 12>;
+ #interrupt-cells = <2>;
+ interrupt-parent = <>;
+ interrupt-controller;
+ };
+
tlmm: pinctrl@f10 {
compatible = "qcom,sc7280-pinctrl";
reg = <0 0xf10 0 0x100>;
@@ -198,6 +224,7 @@
interrupt-controller;
#interrupt-cells = <2>;
gpio-ranges = < 0 0 175>;
+ wakeup-parent = <>;
qup_uart5_default: qup-uart5-default {
pins = "gpio46", "gpio47";
@@ -282,6 +309,23 @@
status = "disabled";
};
};
+
+ apps_rsc: rsc@1820 {
+ compatible = "qcom,rpmh-rsc";
+ reg = <0 0x1820 0 0x1>,
+ <0 0x1821 0 0x1>,
+ <0 0x1822 0 0x1>;
+ reg-names = "drv-0", "drv-1", "drv-2";
+ interrupts = ,
+,
+;
+ qcom,tcs-offset = <0xd00>;
+ qcom,drv-id = <2>;
+ qcom,tcs-config = ,
+ ,
+ ,
+ ;
+ };
};
timer {
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 01/13] dt-bindings: arm: qcom: Document SC7280 SoC and board
Document the SC7280 SoC and the IDP board bindings Signed-off-by: Rajendra Nayak --- Documentation/devicetree/bindings/arm/qcom.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index c97d4a5..f730843 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -37,6 +37,7 @@ description: | msm8994 msm8996 sc7180 +sc7280 sdm630 sdm660 sdm845 @@ -164,6 +165,11 @@ properties: - items: - enum: + - qcom,sc7280-idp + - const: qcom,sc7280 + + - items: + - enum: - xiaomi,lavender - const: qcom,sdm660 -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: Memory keys and io_uring.
On 2/11/21 10:59 PM, Aneesh Kumar K.V wrote: > A read syscall do fail with EFAULT. But we allow read via io_uring > syscalls. Is that ok? In short, yes. As much as I'd like to apply pkey permissions to all accesses, when we don't have the CPU registers around, we don't have a choice: we have to let the access through. The same basic thing is done for accesses via the IOMMU and for things like ptrace() where the ptracer's registers don't have anything to do with the ptracee's address space. We could *probably* be a bit pickier at io_uring_submit() time. But, I'm not sure it's worth it.
Re: [RFC PATCH 4/7] regulator: add property parsing and callbacks to set protection limits
On Thu, 2021-02-11 at 14:35 +0200, Matti Vaittinen wrote: > Add DT property parsing code and setting callback for regulator > over/under > voltage, over-current and temperature error limits. > > Signed-off-by: Matti Vaittinen > --- > drivers/regulator/core.c | 122 > +- > drivers/regulator/of_regulator.c | 58 ++ > drivers/regulator/qcom-labibb-regulator.c | 10 +- > drivers/regulator/stpmic1_regulator.c | 17 ++- > include/linux/regulator/driver.h | 41 +++- > include/linux/regulator/machine.h | 26 + > 6 files changed, 267 insertions(+), 7 deletions(-) Just a note. I did somehow miss the qcom_spmi-regulator.c which also uses the .set_over_current_protection. I will include that file in next version if the idea is still seen worthy. Sorry for the incompleteness. Best Regards Matti Vaittinen
Re: [PATCH v6 6/7] dt-bindings: connector: Add SVDM VDO properties
On Fri, Feb 12, 2021 at 12:21 PM Guenter Roeck wrote: > > On Fri, Feb 05, 2021 at 11:34:14AM +0800, Kyle Tso wrote: > > Add bindings of VDO properties of USB PD SVDM so that they can be > > used in device tree. > > > > Signed-off-by: Kyle Tso > > Reviewed-by: Guenter Roeck > > Would it be possible to unify the dt definitions with the definitions > in include/linux/usb/pd_vdo.h ? I don't really like the duplication. > > Thanks, > Guenter > That's my question as well. But I don't know how to do that. Is it doable to include "include/linux/usb/pd_vdo.h" in the dt-bindings? thanks, Kyle > > --- > > Changes since v5: > > - no change > > > > .../bindings/connector/usb-connector.yaml | 11 + > > include/dt-bindings/usb/pd.h | 311 +- > > 2 files changed, 321 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml > > b/Documentation/devicetree/bindings/connector/usb-connector.yaml > > index 4286ed767a0a..d385026944ec 100644 > > --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml > > +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml > > @@ -137,6 +137,17 @@ properties: > > maxItems: 7 > > $ref: /schemas/types.yaml#/definitions/uint32-array > > > > + sink-vdos: > > +description: An array of u32 with each entry (VDM Objects) providing > > additional information > > + corresponding to the product, the detailed bit definitions and the > > order of each VDO can be > > + found in "USB Power Delivery Specification Revision 3.0, Version 2.0 > > + ECNs 2020-12-10" > > + chapter 6.4.4.3.1 Discover Identity. User can specify the VDO array > > via > > + VDO_IDH/_CERT/_PRODUCT/_UFP/_DFP/_PCABLE/_ACABLE(1/2)/_VPD() defined > > in > > + dt-bindings/usb/pd.h. > > +minItems: 3 > > +maxItems: 6 > > +$ref: /schemas/types.yaml#/definitions/uint32-array > > + > >op-sink-microwatt: > > description: Sink required operating power in microwatt, if source > > can't > >offer the power, Capability Mismatch is set. Required for power sink > > and > > diff --git a/include/dt-bindings/usb/pd.h b/include/dt-bindings/usb/pd.h > > index 0352893697f0..fef3ef65967f 100644 > > --- a/include/dt-bindings/usb/pd.h > > +++ b/include/dt-bindings/usb/pd.h > > @@ -93,4 +93,313 @@ > > #define FRS_DEFAULT_POWER 1 > > #define FRS_5V_1P5A2 > > #define FRS_5V_3A 3 > > - #endif /* __DT_POWER_DELIVERY_H */ > > + > > +/* > > + * SVDM Identity Header > > + * > > + * <31> :: data capable as a USB host > > + * <30> :: data capable as a USB device > > + * <29:27> :: product type (UFP / Cable / VPD) > > + * <26> :: modal operation supported (1b == yes) > > + * <25:23> :: product type (DFP) (SVDM version 2.0+ only; set to zero in > > version 1.0) > > + * <22:21> :: connector type (SVDM version 2.0+ only; set to zero in > > version 1.0) > > + * <20:16> :: Reserved, Shall be set to zero > > + * <15:0> :: USB-IF assigned VID for this cable vendor > > + */ > > +/* SOP Product Type (UFP) */ > > +#define IDH_PTYPE_NOT_UFP 0 > > +#define IDH_PTYPE_HUB 1 > > +#define IDH_PTYPE_PERIPH2 > > +#define IDH_PTYPE_PSD 3 > > +#define IDH_PTYPE_AMA 5 > > + > > +/* SOP' Product Type (Cable Plug / VPD) */ > > +#define IDH_PTYPE_NOT_CABLE 0 > > +#define IDH_PTYPE_PCABLE3 > > +#define IDH_PTYPE_ACABLE4 > > +#define IDH_PTYPE_VPD 6 > > + > > +/* SOP Product Type (DFP) */ > > +#define IDH_PTYPE_NOT_DFP 0 > > +#define IDH_PTYPE_DFP_HUB 1 > > +#define IDH_PTYPE_DFP_HOST 2 > > +#define IDH_PTYPE_DFP_PB3 > > + > > +#define VDO_IDH(usbh, usbd, ufp_cable, is_modal, dfp, conn, vid) > > \ > > + ((usbh) << 31 | (usbd) << 30 | ((ufp_cable) & 0x7) << 27 > > \ > > + | (is_modal) << 26 | ((dfp) & 0x7) << 23 | ((conn) & 0x3) << 21 > > \ > > + | ((vid) & 0x)) > > + > > +/* > > + * Cert Stat VDO > > + * - > > + * <31:0> : USB-IF assigned XID for this cable > > + */ > > +#define VDO_CERT(xid)((xid) & 0x) > > + > > +/* > > + * Product VDO > > + * --- > > + * <31:16> : USB Product ID > > + * <15:0> : USB bcdDevice > > + */ > > +#define VDO_PRODUCT(pid, bcd) (((pid) & 0x) << 16 | ((bcd) & 0x)) > > + > > +/* > > + * UFP VDO (PD Revision 3.0+ only) > > + * > > + * <31:29> :: UFP VDO version > > + * <28>:: Reserved > > + * <27:24> :: Device capability > > + * <23:22> :: Connector type (10b == receptacle, 11b == captive plug) > > + * <21:11> :: Reserved > > + * <10:8> :: Vconn power (AMA only) > > + * <7> :: Vconn required (AMA only, 0b == no, 1b == yes) > > + * <6> :: Vbus required (AMA only, 0b == yes, 1b == no) > > + * <5:3> :: Alternate modes > > + * <2:0> :: USB highest speed > > + */ > > +/*
Re: [PATCH v6 3/7] usb: typec: tcpm: Determine common SVDM Version
On Fri, Feb 12, 2021 at 3:10 PM Kyle Tso wrote:
>
> On Fri, Feb 12, 2021 at 12:17 PM Guenter Roeck wrote:
> >
> > On Fri, Feb 05, 2021 at 11:34:11AM +0800, Kyle Tso wrote:
> > > PD Spec Revision 3.0 Version 2.0 + ECNs 2020-12-10
> > > 6.4.4.2.3 Structured VDM Version
> > > "The Structured VDM Version field of the Discover Identity Command
> > > sent and received during VDM discovery Shall be used to determine the
> > > lowest common Structured VDM Version supported by the Port Partners or
> > > Cable Plug and Shall continue to operate using this Specification
> > > Revision until they are Detached."
> > >
> > > Also clear the fields newly defined in SVDM version 2.0 if the
> > > negotiated SVDM version is 1.0.
> > >
> > > Signed-off-by: Kyle Tso
> > > ---
> > > Changes since v5:
> > > - follow the changes of "usb: typec: Manage SVDM version"
> > > - remove the "reset to default". Now the default SVDM version will be
> > > set when calling to typec_register_partner
> > >
> > > drivers/usb/typec/tcpm/tcpm.c | 71 ++-
> > > 1 file changed, 61 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> > > index 9aadb1e1bec5..b45cd191a8a4 100644
> > > --- a/drivers/usb/typec/tcpm/tcpm.c
> > > +++ b/drivers/usb/typec/tcpm/tcpm.c
> > > @@ -1475,8 +1475,10 @@ static int tcpm_pd_svdm(struct tcpm_port *port,
> > > struct typec_altmode *adev,
> > > const u32 *p, int cnt, u32 *response,
> > > enum adev_actions *adev_action)
> > > {
> > > + struct typec_port *typec = port->typec_port;
> > > struct typec_altmode *pdev;
> > > struct pd_mode_data *modep;
> > > + int svdm_version;
> > > int rlen = 0;
> > > int cmd_type;
> > > int cmd;
> > > @@ -1493,6 +1495,10 @@ static int tcpm_pd_svdm(struct tcpm_port *port,
> > > struct typec_altmode *adev,
> > > pdev = typec_match_altmode(port->partner_altmode,
> > > ALTMODE_DISCOVERY_MAX,
> > > PD_VDO_VID(p[0]), PD_VDO_OPOS(p[0]));
> > >
> > > + svdm_version = typec_get_negotiated_svdm_version(typec);
> > > + if (svdm_version < 0)
> > > + return 0;
> > > +
> > > switch (cmd_type) {
> > > case CMDT_INIT:
> > > switch (cmd) {
> > > @@ -1500,10 +1506,22 @@ static int tcpm_pd_svdm(struct tcpm_port *port,
> > > struct typec_altmode *adev,
> > > if (PD_VDO_VID(p[0]) != USB_SID_PD)
> > > break;
> > >
> > > + if (PD_VDO_SVDM_VER(p[0]) < svdm_version)
> > > +
> > > typec_partner_set_svdm_version(port->partner,
> > > +
> > > PD_VDO_SVDM_VER(p[0]));
> > > /* 6.4.4.3.1: Only respond as UFP (device) */
> > > if (port->data_role == TYPEC_DEVICE &&
> > > port->nr_snk_vdo) {
> > > - for (i = 0; i < port->nr_snk_vdo; i++)
> > > + /*
> > > + * Product Type DFP and Connector Type are
> > > not defined in SVDM
> > > + * version 1.0 and shall be set to zero.
> > > + */
> > > + if
> > > (typec_get_negotiated_svdm_version(typec) < SVDM_VER_2_0)
> >
> > Why not
> > if (svdm_version)
> > ?
> >
>
> The "svdm_version" at this line is the cached value of
> "partner->svdm_version" at the time from below lines.
> In the case of the first calling to "tcpm_pd_svdm", this value is the
> default value set when "typec_register_partner" is called.
>
> >
>pdev = typec_match_altmode(port->partner_altmode,
> ALTMODE_DISCOVERY_MAX,
> PD_VDO_VID(p[0]), PD_VDO_OPOS(p[0]));
>
> + svdm_version = typec_get_negotiated_svdm_version(typec);
> + if (svdm_version < 0)
> + return 0;
> <
>
> "partner->svdm_version" is updated afterward If someone calls
> "typec_partner_set_svdm_version" like these lines:
> >
> + if (PD_VDO_SVDM_VER(p[0]) < svdm_version)
> + typec_partner_set_svdm_version(port->partner,
> +
> PD_VDO_SVDM_VER(p[0]));
> <
>
> However, this won't update the local variable "svdm_version". That's
> why we need to get the value of "partner->svdm_version" again.
> Unless every time the local variable "svdm_version" is updated when
> "typec_partner_set_svdm_version" is called.
>
I can do that if it is clearer to do so.
It just needs two additional lines.
>
> > > + response[1] = port->snk_vdo[0] &
> > > ~IDH_DFP_MASK
> > > + & ~IDH_CONN_MASK;
> > > +
Re: [PATCH 3/3] dma-contiguous: Type cast MAX_ORDER as unsigned int
On 2/11/21 1:34 PM, Christoph Hellwig wrote:
> On Thu, Feb 11, 2021 at 11:52:11AM +0530, Anshuman Khandual wrote:
>> Type cast MAX_ORDER as unsigned int to fix the following build warning.
>>
>> In file included from ./include/linux/kernel.h:14,
>> from ./include/asm-generic/bug.h:20,
>> from ./arch/arm64/include/asm/bug.h:26,
>> from ./include/linux/bug.h:5,
>> from ./include/linux/mmdebug.h:5,
>> from ./arch/arm64/include/asm/memory.h:166,
>> from ./arch/arm64/include/asm/page.h:42,
>> from kernel/dma/contiguous.c:46:
>> kernel/dma/contiguous.c: In function ‘rmem_cma_setup’:
>> ./include/linux/minmax.h:18:28: warning: comparison of distinct pointer
>> types lacks a cast
>> (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
>> ^~
>> ./include/linux/minmax.h:32:4: note: in expansion of macro ‘__typecheck’
>>(__typecheck(x, y) && __no_side_effects(x, y))
>> ^~~
>> ./include/linux/minmax.h:42:24: note: in expansion of macro ‘__safe_cmp’
>> __builtin_choose_expr(__safe_cmp(x, y), \
>> ^~
>> ./include/linux/minmax.h:58:19: note: in expansion of macro
>> ‘__careful_cmp’
>> #define max(x, y) __careful_cmp(x, y, >)
>>^
>> kernel/dma/contiguous.c:402:35: note: in expansion of macro ‘max’
>> phys_addr_t align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
>>
>> Cc: Christoph Hellwig
>> Cc: Marek Szyprowski
>> Cc: Robin Murphy
>> Cc: io...@lists.linux-foundation.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual
>> ---
>> kernel/dma/contiguous.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
>> index 3d63d91cba5c..1c2782349d71 100644
>> --- a/kernel/dma/contiguous.c
>> +++ b/kernel/dma/contiguous.c
>> @@ -399,7 +399,7 @@ static const struct reserved_mem_ops rmem_cma_ops = {
>>
>> static int __init rmem_cma_setup(struct reserved_mem *rmem)
>> {
>> -phys_addr_t align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
>> +phys_addr_t align = PAGE_SIZE << max((unsigned int)MAX_ORDER - 1,
>> pageblock_order);
>
> MAX_ORDER and pageblock_order should be the same type. So either fix
Right.
> MAX_ORDER to be an unsigned constant, which would be fundamentally
> the right thing to do but might cause some fallout, or turn
> pageblock_order into an int, which is probably much either as the stub
> define of it already has an integer type derived from MAX_ORDER as well.
Right, will change pageblock_order as 'int' which would be easier.
Re: [PATCH v10 2/7] i2c: Allow an ACPI driver to manage the device's power state during probe
> I'm actually renaming this as I2C_DRV_ACPI_WAIVE_D0_PROBE, with similar > changes to the function names. I opportunistically assume the ack holds > still. :-) Rightfully so :) signature.asc Description: PGP signature
Re: [PATCH 1/3] mm/page_alloc: Fix pageblock_order when HUGETLB_PAGE_ORDER >= MAX_ORDER
On 2/11/21 1:30 PM, Christoph Hellwig wrote: >> -if (HPAGE_SHIFT > PAGE_SHIFT) >> +if ((HPAGE_SHIFT > PAGE_SHIFT) && (HUGETLB_PAGE_ORDER < MAX_ORDER)) > > No need for the braces. Will drop them.
Re: [PATCH 2/3] arm64/hugetlb: Enable HUGETLB_PAGE_SIZE_VARIABLE
On 2/11/21 1:31 PM, Christoph Hellwig wrote: > On Thu, Feb 11, 2021 at 11:52:10AM +0530, Anshuman Khandual wrote: >> MAX_ORDER which invariably depends on FORCE_MAX_ZONEORDER can be a variable >> for a given page size, depending on whether TRANSPARENT_HUGEPAGE is enabled >> or not. In certain page size and THP combinations HUGETLB_PAGE_ORDER can be >> greater than MAX_ORDER, making it unusable as pageblock_order. >> >> This enables HUGETLB_PAGE_SIZE_VARIABLE making pageblock_order a variable >> rather than the compile time constant HUGETLB_PAGE_ORDER which could break >> MAX_ORDER rule for certain configurations. >> >> Cc: Catalin Marinas >> Cc: Will Deacon >> Cc: linux-arm-ker...@lists.infradead.org >> Cc: linux-kernel@vger.kernel.org >> Signed-off-by: Anshuman Khandual >> --- >> arch/arm64/Kconfig | 4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index f39568b28ec1..8e3a5578f663 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -1909,6 +1909,10 @@ config ARCH_ENABLE_THP_MIGRATION >> def_bool y >> depends on TRANSPARENT_HUGEPAGE >> >> +config HUGETLB_PAGE_SIZE_VARIABLE > > Please move the definition of HUGETLB_PAGE_SIZE_VARIABLE to > mm/Kconfig and select it from the arch Kconfigfs instead of duplicating > the definition. Sure, will do.
Re: [PATCH v6 3/7] usb: typec: tcpm: Determine common SVDM Version
On Fri, Feb 12, 2021 at 12:17 PM Guenter Roeck wrote:
>
> On Fri, Feb 05, 2021 at 11:34:11AM +0800, Kyle Tso wrote:
> > PD Spec Revision 3.0 Version 2.0 + ECNs 2020-12-10
> > 6.4.4.2.3 Structured VDM Version
> > "The Structured VDM Version field of the Discover Identity Command
> > sent and received during VDM discovery Shall be used to determine the
> > lowest common Structured VDM Version supported by the Port Partners or
> > Cable Plug and Shall continue to operate using this Specification
> > Revision until they are Detached."
> >
> > Also clear the fields newly defined in SVDM version 2.0 if the
> > negotiated SVDM version is 1.0.
> >
> > Signed-off-by: Kyle Tso
> > ---
> > Changes since v5:
> > - follow the changes of "usb: typec: Manage SVDM version"
> > - remove the "reset to default". Now the default SVDM version will be
> > set when calling to typec_register_partner
> >
> > drivers/usb/typec/tcpm/tcpm.c | 71 ++-
> > 1 file changed, 61 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> > index 9aadb1e1bec5..b45cd191a8a4 100644
> > --- a/drivers/usb/typec/tcpm/tcpm.c
> > +++ b/drivers/usb/typec/tcpm/tcpm.c
> > @@ -1475,8 +1475,10 @@ static int tcpm_pd_svdm(struct tcpm_port *port,
> > struct typec_altmode *adev,
> > const u32 *p, int cnt, u32 *response,
> > enum adev_actions *adev_action)
> > {
> > + struct typec_port *typec = port->typec_port;
> > struct typec_altmode *pdev;
> > struct pd_mode_data *modep;
> > + int svdm_version;
> > int rlen = 0;
> > int cmd_type;
> > int cmd;
> > @@ -1493,6 +1495,10 @@ static int tcpm_pd_svdm(struct tcpm_port *port,
> > struct typec_altmode *adev,
> > pdev = typec_match_altmode(port->partner_altmode,
> > ALTMODE_DISCOVERY_MAX,
> > PD_VDO_VID(p[0]), PD_VDO_OPOS(p[0]));
> >
> > + svdm_version = typec_get_negotiated_svdm_version(typec);
> > + if (svdm_version < 0)
> > + return 0;
> > +
> > switch (cmd_type) {
> > case CMDT_INIT:
> > switch (cmd) {
> > @@ -1500,10 +1506,22 @@ static int tcpm_pd_svdm(struct tcpm_port *port,
> > struct typec_altmode *adev,
> > if (PD_VDO_VID(p[0]) != USB_SID_PD)
> > break;
> >
> > + if (PD_VDO_SVDM_VER(p[0]) < svdm_version)
> > + typec_partner_set_svdm_version(port->partner,
> > +
> > PD_VDO_SVDM_VER(p[0]));
> > /* 6.4.4.3.1: Only respond as UFP (device) */
> > if (port->data_role == TYPEC_DEVICE &&
> > port->nr_snk_vdo) {
> > - for (i = 0; i < port->nr_snk_vdo; i++)
> > + /*
> > + * Product Type DFP and Connector Type are
> > not defined in SVDM
> > + * version 1.0 and shall be set to zero.
> > + */
> > + if (typec_get_negotiated_svdm_version(typec)
> > < SVDM_VER_2_0)
>
> Why not
> if (svdm_version)
> ?
>
The "svdm_version" at this line is the cached value of
"partner->svdm_version" at the time from below lines.
In the case of the first calling to "tcpm_pd_svdm", this value is the
default value set when "typec_register_partner" is called.
>
pdev = typec_match_altmode(port->partner_altmode, ALTMODE_DISCOVERY_MAX,
PD_VDO_VID(p[0]), PD_VDO_OPOS(p[0]));
+ svdm_version = typec_get_negotiated_svdm_version(typec);
+ if (svdm_version < 0)
+ return 0;
<
"partner->svdm_version" is updated afterward If someone calls
"typec_partner_set_svdm_version" like these lines:
>
+ if (PD_VDO_SVDM_VER(p[0]) < svdm_version)
+ typec_partner_set_svdm_version(port->partner,
+
PD_VDO_SVDM_VER(p[0]));
<
However, this won't update the local variable "svdm_version". That's
why we need to get the value of "partner->svdm_version" again.
Unless every time the local variable "svdm_version" is updated when
"typec_partner_set_svdm_version" is called.
> > + response[1] = port->snk_vdo[0] &
> > ~IDH_DFP_MASK
> > + & ~IDH_CONN_MASK;
> > + else
> > + response[1] = port->snk_vdo[0];
> > + for (i = 1; i < port->nr_snk_vdo; i++)
> > response[i + 1] = port->snk_vdo[i];
> > rlen = port->nr_snk_vdo + 1;
> > }
> > @@ -1532,6 +1550,8 @@ static
Re: [PATCH 0/3] mm/page_alloc: Fix pageblock_order with HUGETLB_PAGE_SIZE_VARIABLE
On 2/11/21 2:07 PM, David Hildenbrand wrote:
> On 11.02.21 07:22, Anshuman Khandual wrote:
>> The following warning gets triggered while trying to boot a 64K page size
>> without THP config kernel on arm64 platform.
>>
>> WARNING: CPU: 5 PID: 124 at mm/vmstat.c:1080 __fragmentation_index+0xa4/0xc0
>> Modules linked in:
>> CPU: 5 PID: 124 Comm: kswapd0 Not tainted 5.11.0-rc6-4-ga0ea7d62002 #159
>> Hardware name: linux,dummy-virt (DT)
>> [ 8.810673] pstate: 2045 (nzCv daif +PAN -UAO -TCO BTYPE=--)
>> [ 8.811732] pc : __fragmentation_index+0xa4/0xc0
>> [ 8.812555] lr : fragmentation_index+0xf8/0x138
>> [ 8.813360] sp : 864079b0
>> [ 8.813958] x29: 864079b0 x28: 0372
>> [ 8.814901] x27: 7682 x26: 8000135b3948
>> [ 8.815847] x25: 1fffe00010c80f48 x24:
>> [ 8.816805] x23: x22: 000d
>> [ 8.817764] x21: 0030 x20: 0005ffcb4d58
>> [ 8.818712] x19: 000b x18:
>> [ 8.819656] x17: x16:
>> [ 8.820613] x15: x14: 8000114c6258
>> [ 8.821560] x13: 6000bff969ba x12: 1fffe000bff969b9
>> [ 8.822514] x11: 1fffe000bff969b9 x10: 6000bff969b9
>> [ 8.823461] x9 : dfff8000 x8 : 0005ffcb4dcf
>> [ 8.824415] x7 : 0001 x6 : 41b58ab3
>> [ 8.825359] x5 : 600010c80f48 x4 : dfff8000
>> [ 8.826313] x3 : 8000102be670 x2 : 0007
>> [ 8.827259] x1 : 86407a60 x0 : 000d
>> [ 8.828218] Call trace:
>> [ 8.828667] __fragmentation_index+0xa4/0xc0
>> [ 8.829436] fragmentation_index+0xf8/0x138
>> [ 8.830194] compaction_suitable+0x98/0xb8
>> [ 8.830934] wakeup_kcompactd+0xdc/0x128
>> [ 8.831640] balance_pgdat+0x71c/0x7a0
>> [ 8.832327] kswapd+0x31c/0x520
>> [ 8.832902] kthread+0x224/0x230
>> [ 8.833491] ret_from_fork+0x10/0x30
>> [ 8.834150] ---[ end trace 472836f79c15516b ]---
>>
>> This warning comes from __fragmentation_index() when the requested order
>> is greater than MAX_ORDER.
>>
>> static int __fragmentation_index(unsigned int order,
>> struct contig_page_info *info)
>> {
>> unsigned long requested = 1UL << order;
>>
>> if (WARN_ON_ONCE(order >= MAX_ORDER)) <= Triggered here
>> return 0;
>>
>> Digging it further reveals that pageblock_order has been assigned a value
>> which is greater than MAX_ORDER failing the above check. But why this
>> happened ? Because HUGETLB_PAGE_ORDER for the given config on arm64 is
>> greater than MAX_ORDER.
>>
>> The solution involves enabling HUGETLB_PAGE_SIZE_VARIABLE which would make
>> pageblock_order a variable instead of constant HUGETLB_PAGE_ORDER. But that
>> change alone also did not really work as pageblock_order still got assigned
>> as HUGETLB_PAGE_ORDER in set_pageblock_order(). HUGETLB_PAGE_ORDER needs to
>> be less than MAX_ORDER for its appropriateness as pageblock_order otherwise
>> just fallback to MAX_ORDER - 1 as before. While here it also fixes a build
>> problem via type casting MAX_ORDER in rmem_cma_setup().
>
> I'm wondering, is there any real value in allowing FORCE_MAX_ZONEORDER to be
> "11" with ARM64_64K_PAGES/ARM64_16K_PAGES?
MAX_ORDER should be as high as would be required for the current config.
Unless THP is enabled, there is no need for it to be any higher than 11.
But I might be missing historical reasons around this as well. Probably
others from arm64 could help here.
>
> Meaning: are there any real use cases that actually build a kernel without
> TRANSPARENT_HUGEPAGE and with ARM64_64K_PAGES/ARM64_16K_PAGES?
THP is always optional. Besides kernel builds without THP should always
be supported. Assuming that all builds will have THP enabled, might not
be accurate.
>
> As builds are essentially broken, I assume this is not that relevant? Or how
> long has it been broken?
Git blame shows that it's been there for some time now. But how does
that make this irrelevant ? A problem should be fixed nonetheless.
>
> It might be easier to just drop the "TRANSPARENT_HUGEPAGE" part from the
> FORCE_MAX_ZONEORDER config.
>
Not sure if it would be a good idea to unnecessarily have larger MAX_ORDER
value for a given config. But I might be missing other contexts here.
Memory keys and io_uring.
Hi,
I am trying to estabilish the behaviour we should expect when passing a
buffer with memory keys attached to io_uring syscalls. As show in the
blow test
/*
* gcc -Wall -O2 -D_GNU_SOURCE -o pkey_uring pkey_uring.c -luring
*/
#include
#include
#include
#include
#include
#include
#include "liburing.h"
#define PAGE_SIZE (64 << 10)
int main(int argc, char *argv[])
{
int fd, ret, pkey;
struct io_uring ring;
struct io_uring_sqe *sqe;
struct io_uring_cqe *cqe;
struct iovec iovec;
void *buf;
if (argc < 2) {
printf("%s: file\n", argv[0]);
return 1;
}
ret = io_uring_queue_init(1, , IORING_SETUP_SQPOLL);
if (ret < 0) {
fprintf(stderr, "queue_init: %s\n", strerror(-ret));
return 1;
}
fd = open(argv[1], O_RDONLY | O_DIRECT);
if (fd < 0) {
perror("open");
return 1;
}
if (posix_memalign(, PAGE_SIZE, PAGE_SIZE))
return 1;
iovec.iov_base = buf;
iovec.iov_len = PAGE_SIZE;
//mprotect(buf, PAGE_SIZE, PROT_NONE);
pkey = pkey_alloc(0, PKEY_DISABLE_WRITE);
pkey_mprotect(buf, PAGE_SIZE, PROT_READ | PROT_WRITE, pkey);
sqe = io_uring_get_sqe();
if (!sqe) {
perror("io_uring_get_sqe");
return 1;
}
io_uring_prep_readv(sqe, fd, , 1, 0);
ret = io_uring_submit();
if (ret != 1) {
fprintf(stderr, "io_uring_submit: %s\n", strerror(-ret));
return 1;
}
ret = io_uring_wait_cqe(, );
if (cqe->res < 0)
fprintf(stderr, "iouring submit failed %s\n",
strerror(-cqe->res));
else
fprintf(stderr, "iouring submit success\n");
io_uring_cqe_seen(, cqe);
/*
* let's access this via a read syscall
*/
ret = read(fd, buf, PAGE_SIZE);
if (ret < 0)
fprintf(stderr, "read failed : %s\n", strerror(errno));
close(fd);
io_uring_queue_exit();
return 0;
}
A read syscall do fail with EFAULT. But we allow read via io_uring
syscalls. Is that ok? Considering memory keys are thread-specific we
could debate that kernel thread can be considered to be the one that got all
access
allowed via keys or we could update that access is denied via kernel
thread for any key value other than default key (key 0). Other option
is to inherit the memory key restrictions when doing
io_uring_submit() and use the same when accessing the userspace from
kernel thread.
Any thoughts here with respect to what should be behaviour?
-aneesh
Fair Pay O-S cont.. Internet Optimization.
Suggesting also a major optimization of the internet, with the Saturn Low-Latency Protocol, where we cut all that can be to binary (no HTML fully typed out words), No OS on servers, but Saturn X O-S on desktop. In line with Fair Pay thinking. Reducing ping time in games, as many also want! Serenity, Ywe, The Fair Pay Initiative, (Now becoming Saturn Medias). https://saturn-medias.com/
Re: [PATCH] rtw88: hold RCU lock when calling ieee80211_find_sta_by_ifaddr()
On 2021-02-12 03:13, Shuah Khan wrote: > ieee80211_find_sta_by_ifaddr() must be called under the RCU lock and > the resulting pointer is only valid under RCU lock as well. > > Fix rtw_rx_addr_match_iter() to hold RCU read lock before it calls > ieee80211_find_sta_by_ifaddr() and release it when the resulting > pointer is no longer needed. > > This problem was found while reviewing code to debug RCU warn from > ath10k_wmi_tlv_parse_peer_stats_info() and a subsequent manual audit > of other callers of ieee80211_find_sta_by_ifaddr() that don't hold > RCU read lock. > > Signed-off-by: Shuah Khan This one also seems unnecessary. rtw_rx_addr_match_iter is called by ieee80211_iterate_active_interfaces_atomic, which acquires the RCU read lock before calling it. - Felix
Re: [PATCH v7 3/5] counter: Add character device interface
On Wed, Dec 30, 2020 at 03:04:40PM +, Jonathan Cameron wrote:
> On Fri, 25 Dec 2020 19:15:36 -0500
> William Breathitt Gray wrote:
>
> > This patch introduces a character device interface for the Counter
> > subsystem. Device data is exposed through standard character device read
> > operations. Device data is gathered when a Counter event is pushed by
> > the respective Counter device driver. Configuration is handled via ioctl
> > operations on the respective Counter character device node.
> >
> > Cc: David Lechner
> > Cc: Gwendal Grignou
> > Cc: Dan Carpenter
> > Signed-off-by: William Breathitt Gray
>
> There are a few things in here that could profitably be pulled out as
> precursor
> patches. I don't really understand the connection of extension_name to the
> addition of a chardev for example. Might be needed to provide enough
> info to actually use the chardev, but does it have meaning without that?
> Either way, definitely feels like it can be done in a separate patch.
The extension_name attributes are needed so chrdev users have enough
info to identify which extension number corresponds to which extension.
I'll move this to change to a separate patch and provide an appropriate
explanation there to make things clearer.
> > +static long counter_chrdev_ioctl(struct file *filp, unsigned int cmd,
> > +unsigned long arg)
> > +{
> > + struct counter_device *const counter = filp->private_data;
> > + unsigned long flags;
> > + int err = 0;
> > +
> > + switch (cmd) {
> > + case COUNTER_CLEAR_WATCHES_IOCTL:
> > + return counter_clear_watches(counter);
> > + case COUNTER_ADD_WATCH_IOCTL:
> > + return counter_add_watch(counter, arg);
> > + case COUNTER_LOAD_WATCHES_IOCTL:
> > + raw_spin_lock_irqsave(>events_list_lock, flags);
> > +
> > + counter_events_list_free(>events_list);
> > + list_replace_init(>next_events_list,
> > + >events_list);
> > +
> > + if (counter->ops->events_configure)
> > + err = counter->ops->events_configure(counter);
> > +
> > + raw_spin_unlock_irqrestore(>events_list_lock, flags);
> > + break;
>
> return here.
Ack.
> > +static int counter_get_data(struct counter_device *const counter,
> > + const struct counter_comp_node *const comp_node,
> > + u64 *const value)
> > +{
> > + const struct counter_comp *const comp = _node->comp;
> > + void *const parent = comp_node->parent;
> > + int err = 0;
> > + u8 value_u8 = 0;
> > + u32 value_u32 = 0;
> > +
> > + if (comp_node->component.type == COUNTER_COMPONENT_NONE)
> > + return 0;
> > +
> > + switch (comp->type) {
> > + case COUNTER_COMP_U8:
> > + case COUNTER_COMP_BOOL:
> > + switch (comp_node->component.scope) {
> > + case COUNTER_SCOPE_DEVICE:
> > + err = comp->device_u8_read(counter, _u8);
> > + break;
> > + case COUNTER_SCOPE_SIGNAL:
> > + err = comp->signal_u8_read(counter, parent, _u8);
> > + break;
> > + case COUNTER_SCOPE_COUNT:
> > + err = comp->count_u8_read(counter, parent, _u8);
> > + break;
> > + }
> > + *value = value_u8;
> > + break;
> > + case COUNTER_COMP_SIGNAL_LEVEL:
> > + case COUNTER_COMP_FUNCTION:
> > + case COUNTER_COMP_ENUM:
> > + case COUNTER_COMP_COUNT_DIRECTION:
> > + case COUNTER_COMP_COUNT_MODE:
> > + switch (comp_node->component.scope) {
> > + case COUNTER_SCOPE_DEVICE:
> > + err = comp->device_u32_read(counter, _u32);
> > + break;
> > + case COUNTER_SCOPE_SIGNAL:
> > + err = comp->signal_u32_read(counter, parent,
> > + _u32);
> > + break;
> > + case COUNTER_SCOPE_COUNT:
> > + err = comp->count_u32_read(counter, parent, _u32);
> > + break;
> > + }
> > + *value = value_u32;
>
> Seems like a return here would make more sense as no shared stuff to do at
> end of the switch. Same in other similar cases.
Ack.
> > + break;
> > + case COUNTER_COMP_U64:
> > + switch (comp_node->component.scope) {
> > + case COUNTER_SCOPE_DEVICE:
> > + return comp->device_u64_read(counter, value);
> > + case COUNTER_SCOPE_SIGNAL:
> > + return comp->signal_u64_read(counter, parent, value);
> > + case COUNTER_SCOPE_COUNT:
> > + return comp->count_u64_read(counter, parent, value);
> > + }
> > + break;
> > + case COUNTER_COMP_SYNAPSE_ACTION:
> > + err = comp->action_read(counter, parent, comp->priv,
> > + _u32);
> > +
Re: [PATCH 1/2] ath9k: hold RCU lock when calling ieee80211_find_sta_by_ifaddr()
On 2021-02-12 03:13, Shuah Khan wrote: > ieee80211_find_sta_by_ifaddr() must be called under the RCU lock and > the resulting pointer is only valid under RCU lock as well. > > Fix ath_tx_process_buffer() to hold RCU read lock before it calls > ieee80211_find_sta_by_ifaddr() and release it when the resulting > pointer is no longer needed. > > This problem was found while reviewing code to debug RCU warn from > ath10k_wmi_tlv_parse_peer_stats_info() and a subsequent manual audit > of other callers of ieee80211_find_sta_by_ifaddr() that don't hold > RCU read lock. > > Signed-off-by: Shuah Khan This patch seems unnecessary as well. All callers of ath_tx_process_buffer seem to hold the RCU read lock already. - Felix
grcan.c:undefined reference to `devm_platform_ioremap_resource'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 291009f656e8eaebbdfd3a8d99f6b190a9ce9deb commit: 65725aa8829f0042db888c2b7e6cc8f1d79e7131 can: grcan: use devm_platform_ioremap_resource() to simplify code date: 1 year, 3 months ago config: s390-randconfig-r006-20210209 (attached as .config) compiler: s390-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=65725aa8829f0042db888c2b7e6cc8f1d79e7131 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 65725aa8829f0042db888c2b7e6cc8f1d79e7131 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=s390 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): s390-linux-ld: drivers/dma/fsl-edma.o: in function `fsl_edma_probe': fsl-edma.c:(.text+0x122a): undefined reference to `devm_ioremap_resource' s390-linux-ld: fsl-edma.c:(.text+0x135c): undefined reference to `devm_ioremap_resource' s390-linux-ld: drivers/dma/qcom/hidma.o: in function `hidma_probe': hidma.c:(.text+0xb22): undefined reference to `devm_ioremap_resource' s390-linux-ld: hidma.c:(.text+0xb82): undefined reference to `devm_ioremap_resource' s390-linux-ld: drivers/tty/ipwireless/main.o: in function `ipwireless_detach': main.c:(.text+0xda): undefined reference to `iounmap' s390-linux-ld: main.c:(.text+0x12a): undefined reference to `iounmap' s390-linux-ld: drivers/tty/ipwireless/main.o: in function `ipwireless_attach': main.c:(.text+0x35c): undefined reference to `iounmap' s390-linux-ld: main.c:(.text+0x3a6): undefined reference to `iounmap' s390-linux-ld: drivers/tty/ipwireless/main.o: in function `ipwireless_probe': main.c:(.text+0x6ba): undefined reference to `ioremap' s390-linux-ld: main.c:(.text+0x78a): undefined reference to `ioremap' s390-linux-ld: main.c:(.text+0x7ea): undefined reference to `iounmap' s390-linux-ld: main.c:(.text+0x82a): undefined reference to `iounmap' s390-linux-ld: drivers/net/can/grcan.o: in function `grcan_probe': >> grcan.c:(.text+0xb04): undefined reference to >> `devm_platform_ioremap_resource' s390-linux-ld: drivers/pcmcia/cistpl.o: in function `set_cis_map': cistpl.c:(.text+0xb0): undefined reference to `iounmap' s390-linux-ld: cistpl.c:(.text+0xc8): undefined reference to `ioremap' s390-linux-ld: cistpl.c:(.text+0x14e): undefined reference to `ioremap' s390-linux-ld: cistpl.c:(.text+0x16e): undefined reference to `iounmap' s390-linux-ld: drivers/pcmcia/cistpl.o: in function `release_cis_mem': cistpl.c:(.text+0x1476): undefined reference to `iounmap' --- 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 v2 2/3] dt-bindings: fpga: Add binding doc for versal fpga manager
Hi Rob, Please find my response inline. > -Original Message- > From: Rob Herring > Sent: Thursday, February 11, 2021 8:26 PM > To: Nava kishore Manne > Cc: linux-arm-ker...@lists.infradead.org; m...@kernel.org; linux- > f...@vger.kernel.org; git ; Appana Durga Kedareswara Rao > ; devicet...@vger.kernel.org; robh...@kernel.org; > chinnikishore...@gmail.com; linux-kernel@vger.kernel.org; > t...@redhat.com; Michal Simek > Subject: Re: [PATCH v2 2/3] dt-bindings: fpga: Add binding doc for versal fpga > manager > > On Thu, 11 Feb 2021 11:35:31 +0530, Nava kishore Manne wrote: > > From: Appana Durga Kedareswara rao > > > > This patch adds binding doc for versal fpga manager driver. > > > > Signed-off-by: Nava kishore Manne > > Signed-off-by: Appana Durga Kedareswara rao > > > > --- > > Changes for v2: > > -Fixed file format and syntax issues. > > > > .../bindings/fpga/xlnx,versal-fpga.yaml | 33 +++ > > 1 file changed, 33 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml > > > > My bot found errors running 'make dt_binding_check' on your patch: > > yamllint warnings/errors: > ./Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml:12:14: > [warning] too many spaces after colon (colons) > ./Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml:20:9: > [warning] wrong indentation: expected 10 but found 8 (indentation) > > dtschema/dtc warnings/errors: > > See https://patchwork.ozlabs.org/patch/1439305 > > This check can fail if there are any dependencies. The base for a patch series > is generally the most recent rc1. > > If you already ran 'make dt_binding_check' and didn't see the above error(s), > then make sure 'yamllint' is installed and dt-schema is up to > date: > > pip3 install dtschema --upgrade > > Please check and re-submit. Initially, I couldn't see any issue when I run. After installing yamllint and with upgraded dt-schema, I am able to reproduce the above pointed issues. Is there any prerequisite(Other than yamllint) I need to follow to run dt-schema? Regards, Navakishore.
Re: [RFC PATCH v4 00/17] virtio/vsock: introduce SOCK_SEQPACKET support
On 11.02.2021 17:57, Stefano Garzarella wrote:
> Hi Arseny,
>
> On Mon, Feb 08, 2021 at 09:32:59AM +0300, Arseny Krasnov wrote:
>> On 07.02.2021 19:20, Michael S. Tsirkin wrote:
>>> On Sun, Feb 07, 2021 at 06:12:56PM +0300, Arseny Krasnov wrote:
This patchset impelements support of SOCK_SEQPACKET for virtio
transport.
As SOCK_SEQPACKET guarantees to save record boundaries, so to
do it, two new packet operations were added: first for start of record
and second to mark end of record(SEQ_BEGIN and SEQ_END later). Also,
both operations carries metadata - to maintain boundaries and payload
integrity. Metadata is introduced by adding special header with two
fields - message count and message length:
struct virtio_vsock_seq_hdr {
__le32 msg_cnt;
__le32 msg_len;
} __attribute__((packed));
This header is transmitted as payload of SEQ_BEGIN and SEQ_END
packets(buffer of second virtio descriptor in chain) in the same way as
data transmitted in RW packets. Payload was chosen as buffer for this
header to avoid touching first virtio buffer which carries header of
packet, because someone could check that size of this buffer is equal
to size of packet header. To send record, packet with start marker is
sent first(it's header contains length of record and counter), then
counter is incremented and all data is sent as usual 'RW' packets and
finally SEQ_END is sent(it also carries counter of message, which is
counter of SEQ_BEGIN + 1), also after sedning SEQ_END counter is
incremented again. On receiver's side, length of record is known from
packet with start record marker. To check that no packets were dropped
by transport, counters of two sequential SEQ_BEGIN and SEQ_END are
checked(counter of SEQ_END must be bigger that counter of SEQ_BEGIN by
1) and length of data between two markers is compared to length in
SEQ_BEGIN header.
Now as packets of one socket are not reordered neither on
vsock nor on vhost transport layers, such markers allows to restore
original record on receiver's side. If user's buffer is smaller that
record length, when all out of size data is dropped.
Maximum length of datagram is not limited as in stream socket,
because same credit logic is used. Difference with stream socket is
that user is not woken up until whole record is received or error
occurred. Implementation also supports 'MSG_EOR' and 'MSG_TRUNC' flags.
Tests also implemented.
Arseny Krasnov (17):
af_vsock: update functions for connectible socket
af_vsock: separate wait data loop
af_vsock: separate receive data loop
af_vsock: implement SEQPACKET receive loop
af_vsock: separate wait space loop
af_vsock: implement send logic for SEQPACKET
af_vsock: rest of SEQPACKET support
af_vsock: update comments for stream sockets
virtio/vsock: dequeue callback for SOCK_SEQPACKET
virtio/vsock: fetch length for SEQPACKET record
virtio/vsock: add SEQPACKET receive logic
virtio/vsock: rest of SOCK_SEQPACKET support
virtio/vsock: setup SEQPACKET ops for transport
vhost/vsock: setup SEQPACKET ops for transport
vsock_test: add SOCK_SEQPACKET tests
loopback/vsock: setup SEQPACKET ops for transport
virtio/vsock: simplify credit update function API
drivers/vhost/vsock.c | 8 +-
include/linux/virtio_vsock.h| 15 +
include/net/af_vsock.h | 9 +
include/uapi/linux/virtio_vsock.h | 16 +
net/vmw_vsock/af_vsock.c| 588 +++---
net/vmw_vsock/virtio_transport.c| 5 +
net/vmw_vsock/virtio_transport_common.c | 316 ++--
net/vmw_vsock/vsock_loopback.c | 5 +
tools/testing/vsock/util.c | 32 +-
tools/testing/vsock/util.h | 3 +
tools/testing/vsock/vsock_test.c| 126 +
11 files changed, 895 insertions(+), 228 deletions(-)
TODO:
- What to do, when server doesn't support SOCK_SEQPACKET. In current
implementation RST is replied in the same way when listening port
is not found. I think that current RST is enough,because case when
server doesn't support SEQ_PACKET is same when listener missed(e.g.
no listener in both cases).
> I think is fine.
>
>>>- virtio spec patch
>> Ok
> Yes, please prepare a patch to discuss the VIRTIO spec changes.
>
> For example for 'virtio_vsock_seq_hdr', I left a comment about 'msg_cnt'
> naming that should be better to discuss with virtio guys.
Ok, i'll prepare it in v5. So I have to send it both LKML(as one of patches) and
virtio mailing lists? (e.g. virtio-comm...@lists.oasis-open.org)
>
> Anyway, I
mmotm 2021-02-11-22-05 uploaded
The mm-of-the-moment snapshot 2021-02-11-22-05 has been uploaded to https://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: https://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (5.x or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in https://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. https://github.com/hnaz/linux-mm The directory https://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is also available at https://github.com/hnaz/linux-mm This mmotm tree contains the following patches against 5.11-rc7: (patches marked "*" will be included in linux-next) origin.patch * m68k-make-__pfn_to_phys-and-__phys_to_pfn-available-for-mmu.patch * scripts-recordmcountpl-support-big-endian-for-arch-sh.patch * proc-kpageflags-prevent-an-integer-overflow-in-stable_page_flags.patch * proc-kpageflags-do-not-use-uninitialized-struct-pages.patch * hexagon-remove-config_experimental-from-defconfigs.patch * scripts-spellingtxt-increase-error-prone-spell-checking.patch * scripts-spellingtxt-increase-error-prone-spell-checking-2.patch * scripts-spellingtxt-add-allocted-and-exeeds-typo.patch * scripts-spellingtxt-add-more-spellings-to-spellingtxt.patch * ntfs-layouth-delete-duplicated-words.patch * ocfs2-remove-redundant-conditional-before-iput.patch * ocfs2-cleanup-some-definitions-which-is-not-used-anymore.patch * ocfs2-fix-a-use-after-free-on-error.patch * ocfs2-simplify-the-calculation-of-variables.patch * ocfs2-clear-links-count-in-ocfs2_mknod-if-an-error-occurs.patch * ocfs2-fix-ocfs2-corrupt-when-iputting-an-inode.patch * fs-delete-repeated-words-in-comments.patch * ramfs-support-o_tmpfile.patch * kernel-watchdog-flush-all-printk-nmi-buffers-when-hardlockup-detected.patch mm.patch * mm-tracing-record-slab-name-for-kmem_cache_free.patch * mm-remove-ctor-argument-from-kmem_cache_flags.patch * mm-slab-minor-coding-style-tweaks.patch * mm-slub-disable-user-tracing-for-kmemleak-caches-by-default.patch * mm-slub-stop-freeing-kmem_cache_node-structures-on-node-offline.patch * mm-slab-slub-stop-taking-memory-hotplug-lock.patch * mm-slab-slub-stop-taking-cpu-hotplug-lock.patch * mm-slub-splice-cpu-and-page-freelists-in-deactivate_slab.patch * mm-slub-remove-slub_memcg_sysfs-boot-param-and-config_slub_memcg_sysfs_on.patch * mm-slub-minor-coding-style-tweaks.patch * mm-debug-improve-memcg-debugging.patch * mm-debug_vm_pgtable-basic-add-validation-for-dirtiness-after-write-protect.patch * mm-debug_vm_pgtable-basic-iterate-over-entire-protection_map.patch * mm-page_owner-use-helper-function-zone_end_pfn-to-get-end_pfn.patch * mm-msync-exit-early-when-the-flags-is-an-ms_async-and-start-vm_start.patch * mm-filemap-remove-unused-parameter-and-change-to-void-type-for-replace_page_cache_page.patch * mm-filemap-dont-revert-iter-on-eiocbqueued.patch * mm-filemap-rename-generic_file_buffered_read-subfunctions.patch * mm-filemap-remove-dynamically-allocated-array-from-filemap_read.patch * mm-filemap-convert-filemap_get_pages-to-take-a-pagevec.patch * mm-filemap-use-head-pages-in-generic_file_buffered_read.patch * mm-filemap-pass-a-sleep-state-to-put_and_wait_on_page_locked.patch * mm-filemap-support-readpage-splitting-a-page.patch * mm-filemap-inline-__wait_on_page_locked_async-into-caller.patch * mm-filemap-dont-call-readpage-if-iocb_waitq-is-set.patch * mm-filemap-change-filemap_read_page-calling-conventions.patch * mm-filemap-change-filemap_create_page-calling-conventions.patch * mm-filemap-convert-filemap_update_page-to-return-an-errno.patch * mm-filemap-move-the-iocb-checks-into-filemap_update_page.patch * mm-filemap-add-filemap_range_uptodate.patch * mm-filemap-add-filemap_range_uptodate-fix.patch * mm-filemap-split-filemap_readahead-out-of-filemap_get_pages.patch * mm-filemap-restructure-filemap_get_pages.patch * mm-filemap-dont-relock-the-page-after-calling-readpage.patch * mm-filemap-rename-generic_file_buffered_read-to-filemap_read.patch *
Re: [PATCH v7 5/5] counter: 104-quad-8: Add IRQ support for the ACCES 104-QUAD-8
On Wed, Dec 30, 2020 at 03:31:15PM +, Jonathan Cameron wrote: > On Fri, 25 Dec 2020 19:15:38 -0500 > William Breathitt Gray wrote: > > > The LSI/CSI LS7266R1 chip provides programmable output via the FLG pins. > > When interrupts are enabled on the ACCES 104-QUAD-8, they occur whenever > > FLG1 is active. Four functions are available for the FLG1 signal: Carry, > > Compare, Carry-Borrow, and Index. > > > > Carry: > > Interrupt generated on active low Carry signal. Carry > > signal toggles every time the respective channel's > > counter overflows. > > > > Compare: > > Interrupt generated on active low Compare signal. > > Compare signal toggles every time respective channel's > > preset register is equal to the respective channel's > > counter. > > > > Carry-Borrow: > > Interrupt generated on active low Carry signal and > > active low Borrow signal. Carry signal toggles every > > time the respective channel's counter overflows. Borrow > > signal toggles every time the respective channel's > > counter underflows. > > > > Index: > > Interrupt generated on active high Index signal. > > > > The irq_trigger Count extension is introduced to allow the selection of > > the desired IRQ trigger function per channel. Interrupts push Counter > > events to event channel X, where 'X' is the respective channel whose > > FLG1 activated. > > > > This patch adds IRQ support for the ACCES 104-QUAD-8. The interrupt line > > numbers for the devices may be configured via the irq array module > > parameter. > > > > Reviewed-by: Syed Nayyar Waris > > Signed-off-by: William Breathitt Gray > > Immediate thought on this is that you should pull the lock type change > out as a precursor patch that simply says we need it to be a spin_lock > for the following patch. That should be an obvious change to review > and then leave a much shorter patch to focus on here. > > Jonathan Ack. > > --- > > .../ABI/testing/sysfs-bus-counter-104-quad-8 | 25 ++ > > drivers/counter/104-quad-8.c | 318 ++ > > drivers/counter/Kconfig | 6 +- > > 3 files changed, 276 insertions(+), 73 deletions(-) > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-counter-104-quad-8 > > b/Documentation/ABI/testing/sysfs-bus-counter-104-quad-8 > > index eac32180c40d..0ecba24d43aa 100644 > > --- a/Documentation/ABI/testing/sysfs-bus-counter-104-quad-8 > > +++ b/Documentation/ABI/testing/sysfs-bus-counter-104-quad-8 > > @@ -1,3 +1,28 @@ > > +What: /sys/bus/counter/devices/counterX/countY/irq_trigger > > A warning on this. The ABI docs are now built into the main kernel > html docs build. The snag is that it doesn't cope will with specialising > or different devices having the same named file with different allowed values. > You have to unify them all into one place. It may be worth just doing that > from the start. Ack. > > diff --git a/drivers/counter/104-quad-8.c b/drivers/counter/104-quad-8.c > > index f4fb36b751c4..7537575568d0 100644 > > --- a/drivers/counter/104-quad-8.c > > +++ b/drivers/counter/104-quad-8.c > > @@ -13,23 +13,30 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > #include > > #include > > +#include > > > > #define QUAD8_EXTENT 32 > > > > static unsigned int base[max_num_isa_dev(QUAD8_EXTENT)]; > > static unsigned int num_quad8; > > -module_param_array(base, uint, _quad8, 0); > > +module_param_hw_array(base, uint, ioport, _quad8, 0); > > Why this change? Perhaps a note in the patch description on why > this is needed? This change is unrelated to this patch so I'll move it to a precursor patch with an explanation of the reason for the change. > > MODULE_PARM_DESC(base, "ACCES 104-QUAD-8 base addresses"); > > > > +static unsigned int irq[max_num_isa_dev(QUAD8_EXTENT)]; > > +module_param_hw_array(irq, uint, irq, NULL, 0); > > +MODULE_PARM_DESC(irq, "ACCES 104-QUAD-8 interrupt line numbers"); > > + > > #define QUAD8_NUM_COUNTERS 8 > > > > /** > > * struct quad8_iio - IIO device private data structure > > + * @lock: synchronization lock to prevent I/O race conditions > > Probably want to be more specific. RMW, indexed writes or what sort of race? Ack. > > * @counter: instance of the counter_device > > * @fck_prescaler: array of filter clock prescaler configurations > > * @preset:array of preset values > > @@ -38,13 +45,14 @@ MODULE_PARM_DESC(base, "ACCES 104-QUAD-8 base > > addresses"); > > * @quadrature_scale: array of quadrature mode scale configurations > > * @ab_enable: array of A and B inputs enable configurations > > * @preset_enable: array of set_to_preset_on_index attribute configurations > > + * @irq_trigger: array of
[GIT PULL] xen: branch for v5.11-rc8
Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.11-rc8-tag xen: branch for v5.11-rc8 It contains a single fix for an issue introduced in 5.11: when running as a Xen guest on Arm systems the kernel will hang during boot. Thanks. Juergen arch/arm/xen/enlighten.c | 2 -- drivers/xen/xenbus/xenbus.h | 1 - drivers/xen/xenbus/xenbus_probe.c | 2 +- include/xen/xenbus.h | 2 -- 4 files changed, 1 insertion(+), 6 deletions(-) Julien Grall (1): arm/xen: Don't probe xenbus as part of an early initcall
Re: [PATCH] ARM: Implement Clang's SLS mitigation
Hi Jian,
On Thu, Feb 11, 2021 at 09:14:58PM -0800, Jian Cai wrote:
> This patch adds a config CONFIG_HARDEN_SLS_ALL that can be used to turn
Drop "a config".
> on -mharden-sls=all, which mitigates the straight-line speculation
> vulnerability, or more commonly known as Spectre, Meldown.
^ I would drop "or" here
^ drop comma,
use "and",
typo: "Meltdown"
Although, is that a fair statement? SLS is not called Spectre or
Meltdown by ARM, it is a speculative processor vulnerabilty. It
might just be better to drop eerything after the first comma (although
maybe that is just being pedantic).
>
> Notice -mharden-sls= has other options as below, and this config turns
> on the strongest option.
>
> all: enable all mitigations against Straight Line Speculation that are
> implemented.
> none: disable all mitigations against Straight Line Speculation.
> retbr: enable the mitigation against Straight Line Speculation for RET and BR
> instructions.
> blr: enable the mitigation against Straight Line Speculation for BLR
> instructions.
I cannot comment on whether or not this is worth doing, I will leave
that up to Will, Catalin, et al. The following comments are more from a
"regular kernel developer" perspective, rather than an "arm64 kernel
developer" :)
> Link: https://reviews.llvm.org/D93221
> Link: https://reviews.llvm.org/D81404
> Link:
> https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation
This is also a useful article it seems:
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/frequently-asked-questions#SLS2
> Link: https://crbug.com/1171521
This crbug is private. If it is going into a commit message, please
publicize it.
> Suggested-by: Manoj Gupta
> Signed-off-by: Jian Cai
> ---
> arch/arm/Makefile | 4
> arch/arm64/Makefile| 5 +
> security/Kconfig.hardening | 11 +++
> 3 files changed, 20 insertions(+)
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 4aaec9599e8a..11d89ef32da9 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -48,6 +48,10 @@ CHECKFLAGS += -D__ARMEL__
> KBUILD_LDFLAGS += -EL
> endif
>
> +ifeq ($(CONFIG_HARDEN_SLS_ALL), y)
> +KBUILD_CFLAGS += -mharden-sls=all
> +endif
> +
> #
> # The Scalar Replacement of Aggregates (SRA) optimization pass in GCC 4.9 and
> # later may result in code being generated that handles signed short and
> signed
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 90309208bb28..8fd0ccd87eca 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -34,6 +34,11 @@ $(warning LSE atomics not supported by binutils)
>endif
> endif
>
> +ifeq ($(CONFIG_HARDEN_SLS_ALL), y)
> +KBUILD_CFLAGS += -mharden-sls=all
> +endif
> +
> +
Extra space here
> cc_has_k_constraint := $(call try-run,echo \
> 'int main(void) { \
> asm volatile("and w0, w0, %w0" :: "K" (4294967295));\
> diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
> index 269967c4fc1b..d83c406c81a3 100644
> --- a/security/Kconfig.hardening
> +++ b/security/Kconfig.hardening
> @@ -121,6 +121,17 @@ choice
>
> endchoice
>
> +
> +config CC_HAS_HARDEN_SLS_ALL
> + def_bool $(cc-option,-mharden-sls=all)
I do not think that CONFIG_CC_HAS_HARDEN_SLS_ALL serves much purpose.
Moving the cc-option into CONFIG_HARDEN_SLS_ALL is just as clean.
config HARDEN_SLS_ALL
bool "enable SLS vulnerability hardening"
depends on $(cc-option,-mharden-sls=all)
help
Enables straight-line speculation vulnerability hardening
at highest level.
> +
> + config HARDEN_SLS_ALL
> + bool "enable SLS vulnerability hardening"
The spacing here seems messed up, I corrected it above.
> + depends on CC_HAS_HARDEN_SLS_ALL
> + help
> + Enables straight-line speculation vulnerability hardening
> + at highest level.
> +
> config GCC_PLUGIN_STRUCTLEAK_VERBOSE
> bool "Report forcefully initialized variables"
> depends on GCC_PLUGIN_STRUCTLEAK
> --
> 2.30.0.478.g8a0d178c01-goog
>
>
Cheers,
Nathan
arch/m68k/68000/dragen2.c:73:16: error: 'screen_bits' undeclared
Hi Arnd,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 291009f656e8eaebbdfd3a8d99f6b190a9ce9deb
commit: a734bbf694270dca8594a5c33375867dc31503f5 m68k: m68328: move platform
code to separate files
date: 10 weeks ago
config: m68k-randconfig-r001-20210211 (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a734bbf694270dca8594a5c33375867dc31503f5
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout a734bbf694270dca8594a5c33375867dc31503f5
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=m68k
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
arch/m68k/68000/dragen2.c:38:13: warning: no previous prototype for
'init_dragen2' [-Wmissing-prototypes]
38 | void __init init_dragen2(char *command, int size)
| ^~~~
arch/m68k/68000/dragen2.c: In function 'init_dragen2':
>> arch/m68k/68000/dragen2.c:73:16: error: 'screen_bits' undeclared (first use
>> in this function)
73 | LSSA = (long) screen_bits;
|^~~
arch/m68k/68000/dragen2.c:73:16: note: each undeclared identifier is
reported only once for each function it appears in
vim +/screen_bits +73 arch/m68k/68000/dragen2.c
37
> 38 void __init init_dragen2(char *command, int size)
39 {
40 mach_reset = dragen2_reset;
41
42 #ifdef CONFIG_DIRECT_IO_ACCESS
43 SCR = 0x10; /* allow user
access to internal registers */
44 #endif
45
46 /* CSGB Init */
47 CSGBB = 0x4000;
48 CSB = 0x1a1;
49
50 /* CS8900 init */
51 /* PK3: hardware sleep function pin, active low */
52 PKSEL |= PK(3); /* select pin as I/O */
53 PKDIR |= PK(3); /* select pin as output
*/
54 PKDATA |= PK(3);/* set pin high */
55
56 /* PF5: hardware reset function pin, active high */
57 PFSEL |= PF(5); /* select pin as I/O */
58 PFDIR |= PF(5); /* select pin as output
*/
59 PFDATA &= ~PF(5); /* set pin low */
60
61 /* cs8900 hardware reset */
62 PFDATA |= PF(5);
63 { int i; for (i = 0; i < 32000; ++i); }
64 PFDATA &= ~PF(5);
65
66 /* INT1 enable (cs8900 IRQ) */
67 PDPOL &= ~PD(1);/* active high signal */
68 PDIQEG &= ~PD(1);
69 PDIRQEN |= PD(1); /* IRQ enabled */
70
71 #ifdef CONFIG_INIT_LCD
72 /* initialize LCD controller */
> 73 LSSA = (long) screen_bits;
---
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 1/2] quota: Add mountpath based quota support
Hi Sascha,
I love your patch! Yet something to improve:
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on tip/x86/asm m68k/for-next hp-parisc/for-next
powerpc/next s390/features linus/master v5.11-rc7 next-20210211]
[cannot apply to sparc/master]
[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/Sascha-Hauer/quota-Add-mountpath-based-quota-support/20210211-233912
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
for-next/core
config: x86_64-randconfig-a012-20210209 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
c9439ca36342fb6013187d0a69aef92736951476)
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
#
https://github.com/0day-ci/linux/commit/4b7a3df11dd2ca215a6e9b24d81c98d6951476b6
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Sascha-Hauer/quota-Add-mountpath-based-quota-support/20210211-233912
git checkout 4b7a3df11dd2ca215a6e9b24d81c98d6951476b6
# 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 errors (new ones prefixed by >>):
>> fs/quota/quota.c:995:6: error: implicit declaration of function
>> 'quotactl_cmd_write' [-Werror,-Wimplicit-function-declaration]
if (quotactl_cmd_write(cmds)) {
^
fs/quota/quota.c:995:6: note: did you mean 'quotactl_cmd_onoff'?
fs/quota/quota.c:857:13: note: 'quotactl_cmd_onoff' declared here
static bool quotactl_cmd_onoff(int cmd)
^
1 error generated.
vim +/quotactl_cmd_write +995 fs/quota/quota.c
972
973 SYSCALL_DEFINE4(quotactl_path, unsigned int, cmd, const char __user *,
974 mountpoint, qid_t, id, void __user *, addr)
975 {
976 struct super_block *sb;
977 struct path mountpath;
978 unsigned int cmds = cmd >> SUBCMDSHIFT;
979 unsigned int type = cmd & SUBCMDMASK;
980 int ret;
981
982 if (type >= MAXQUOTAS)
983 return -EINVAL;
984
985 if (!mountpoint)
986 return -ENODEV;
987
988 ret = user_path_at(AT_FDCWD, mountpoint,
989 LOOKUP_FOLLOW | LOOKUP_AUTOMOUNT,
);
990 if (ret)
991 return ret;
992
993 sb = mountpath.dentry->d_inode->i_sb;
994
> 995 if (quotactl_cmd_write(cmds)) {
---
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 V3 11/14] coresight: sink: Add TRBE driver
On 2/11/21 12:30 AM, Mathieu Poirier wrote:
> On Wed, Jan 27, 2021 at 02:25:35PM +0530, Anshuman Khandual wrote:
>> Trace Buffer Extension (TRBE) implements a trace buffer per CPU which is
>> accessible via the system registers. The TRBE supports different addressing
>> modes including CPU virtual address and buffer modes including the circular
>> buffer mode. The TRBE buffer is addressed by a base pointer (TRBBASER_EL1),
>> an write pointer (TRBPTR_EL1) and a limit pointer (TRBLIMITR_EL1). But the
>> access to the trace buffer could be prohibited by a higher exception level
>> (EL3 or EL2), indicated by TRBIDR_EL1.P. The TRBE can also generate a CPU
>> private interrupt (PPI) on address translation errors and when the buffer
>> is full. Overall implementation here is inspired from the Arm SPE driver.
>>
>> Cc: Mathieu Poirier
>> Cc: Mike Leach
>> Cc: Suzuki K Poulose
>> Signed-off-by: Anshuman Khandual
>> ---
>> Changes in V3:
>>
>> - Added new DT bindings document TRBE.yaml
>> - Changed TRBLIMITR_TRIG_MODE_SHIFT from 2 to 3
>> - Dropped isb() from trbe_reset_local()
>> - Dropped gap between (void *) and buf->trbe_base
>> - Changed 'int' to 'unsigned int' in is_trbe_available()
>> - Dropped unused function set_trbe_running(), set_trbe_virtual_mode(),
>> set_trbe_enabled() and set_trbe_limit_pointer()
>> - Changed get_trbe_flag_update(), is_trbe_programmable() and
>> get_trbe_address_align() to accept TRBIDR value
>> - Changed is_trbe_running(), is_trbe_abort(), is_trbe_wrap(), is_trbe_trg(),
>> is_trbe_irq(), get_trbe_bsc() and get_trbe_ec() to accept TRBSR value
>> - Dropped snapshot mode condition in arm_trbe_alloc_buffer()
>> - Exit arm_trbe_init() when arm64_kernel_unmapped_at_el0() is enabled
>> - Compute trbe_limit before trbe_write to get the updated handle
>> - Added trbe_stop_and_truncate_event()
>> - Dropped trbe_handle_fatal()
>>
>> Documentation/trace/coresight/coresight-trbe.rst | 39 +
>> arch/arm64/include/asm/sysreg.h |1 +
>> drivers/hwtracing/coresight/Kconfig | 11 +
>> drivers/hwtracing/coresight/Makefile |1 +
>> drivers/hwtracing/coresight/coresight-trbe.c | 1023
>> ++
>> drivers/hwtracing/coresight/coresight-trbe.h | 160
>> 6 files changed, 1235 insertions(+)
>> create mode 100644 Documentation/trace/coresight/coresight-trbe.rst
>> create mode 100644 drivers/hwtracing/coresight/coresight-trbe.c
>> create mode 100644 drivers/hwtracing/coresight/coresight-trbe.h
>> +
>
> [...]
>
>> +static void arm_trbe_probe_coresight_cpu(void *info)
>> +{
>> +struct trbe_drvdata *drvdata = info;
>> +struct coresight_desc desc = { 0 };
>> +int cpu = smp_processor_id();
>> +struct trbe_cpudata *cpudata = per_cpu_ptr(drvdata->cpudata, cpu);
>> +struct coresight_device *trbe_csdev = per_cpu(csdev_sink, cpu);
>> +u64 trbidr = read_sysreg_s(SYS_TRBIDR_EL1);
>> +struct device *dev;
>> +
>> +if (WARN_ON(!cpudata))
>> +goto cpu_clear;
>
> There is already a check for this in arm_trbe_probe_coresight(), we couldn't
> be
> here if there was a problem with the allocation.
Right but just to be extra cautious. Do you really want this to be dropped ?
>
>> +
>> +if (trbe_csdev)
>> +return;
>
> Now that's a reason to have a WARN_ON(). If we are probing and a sink is
> already present in this cpu's slot, something went seriously wrong and we
> should
> be clear about it.
Right, will add an WARN_ON().
>
>> +
>> +cpudata->cpu = smp_processor_id();
>> +cpudata->drvdata = drvdata;
>> +dev = >drvdata->pdev->dev;
>> +
>> +if (!is_trbe_available()) {
>> +pr_err("TRBE is not implemented on cpu %d\n", cpudata->cpu);
>> +goto cpu_clear;
>> +}
>> +
>> +if (!is_trbe_programmable(trbidr)) {
>> +pr_err("TRBE is owned in higher exception level on cpu %d\n",
>> cpudata->cpu);
>> +goto cpu_clear;
>> +}
>> +desc.name = devm_kasprintf(dev, GFP_KERNEL, "%s%d", DRVNAME,
>> smp_processor_id());
>
> We will end up with "arm_trbe0", "arm_trbe1" and so on in sysfs... Is the
> "arm_" part absolutely needed? I think this should be like what we do for
> etmv3
> and etmv4 where only "etmX" shows up in sysfs.
Okay, will drop arm_ here. IIRC this was originally trbeX where X is the cpu
number
but then ended up using DRVNAME as prefix.
>
>> +if (IS_ERR(desc.name))
>> +goto cpu_clear;
>> +
>> +desc.type = CORESIGHT_DEV_TYPE_SINK;
>> +desc.subtype.sink_subtype = CORESIGHT_DEV_SUBTYPE_SINK_PERCPU_SYSMEM;
>> +desc.ops = _trbe_cs_ops;
>> +desc.pdata = dev_get_platdata(dev);
>> +desc.groups = arm_trbe_groups;
>> +desc.dev = dev;
>> +trbe_csdev = coresight_register();
>> +if (IS_ERR(trbe_csdev))
>> +goto cpu_clear;
>> +
>> +dev_set_drvdata(_csdev->dev, cpudata);
>> +cpudata->trbe_dbm = get_trbe_flag_update(trbidr);
>> +
Re: [PATCH v3] printk: Userspace format enumeration support
Hi Chris,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on jeyu/modules-next]
[also build test ERROR on linux/master soc/for-next openrisc/for-next
powerpc/next uml/linux-next asm-generic/master linus/master v5.11-rc7
next-20210211]
[cannot apply to tip/x86/core pmladek/for-next]
[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/Chris-Down/printk-Userspace-format-enumeration-support/20210209-223044
base: https://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux.git
modules-next
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/e90a39fb011f4c6124b244b00025332cd5d78bec
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Chris-Down/printk-Userspace-format-enumeration-support/20210209-223044
git checkout e90a39fb011f4c6124b244b00025332cd5d78bec
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=ia64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from include/linux/kernel.h:16,
from include/linux/list.h:9,
from include/linux/rculist.h:10,
from include/linux/sched/signal.h:5,
from arch/ia64/kernel/asm-offsets.c:10:
arch/ia64/include/asm/atomic.h: In function 'ia64_atomic_add':
>> include/linux/printk.h:311:3: error: expected identifier or '(' before '{'
>> token
311 | ({ \
| ^
include/linux/printk.h:331:26: note: in expansion of macro 'printk_store_fmt'
331 | #define printk(fmt, ...) printk_store_fmt(_printk, fmt,
##__VA_ARGS__)
| ^~~~
arch/ia64/include/uapi/asm/cmpxchg.h:142:14: note: in expansion of macro
'printk'
142 | extern int printk(const char *fmt, ...); \
| ^~
arch/ia64/include/asm/atomic.h:38:3: note: in expansion of macro
'CMPXCHG_BUGCHECK'
38 | CMPXCHG_BUGCHECK(v); \
| ^~~~
arch/ia64/include/asm/atomic.h:61:2: note: in expansion of macro 'ATOMIC_OP'
61 | ATOMIC_OP(op, c_op) \
| ^
arch/ia64/include/asm/atomic.h:64:1: note: in expansion of macro 'ATOMIC_OPS'
64 | ATOMIC_OPS(add, +)
| ^~
arch/ia64/include/asm/atomic.h: In function 'ia64_atomic_fetch_add':
>> include/linux/printk.h:311:3: error: expected identifier or '(' before '{'
>> token
311 | ({ \
| ^
include/linux/printk.h:331:26: note: in expansion of macro 'printk_store_fmt'
331 | #define printk(fmt, ...) printk_store_fmt(_printk, fmt,
##__VA_ARGS__)
| ^~~~
arch/ia64/include/uapi/asm/cmpxchg.h:142:14: note: in expansion of macro
'printk'
142 | extern int printk(const char *fmt, ...); \
| ^~
arch/ia64/include/asm/atomic.h:53:3: note: in expansion of macro
'CMPXCHG_BUGCHECK'
53 | CMPXCHG_BUGCHECK(v); \
| ^~~~
arch/ia64/include/asm/atomic.h:62:2: note: in expansion of macro
'ATOMIC_FETCH_OP'
62 | ATOMIC_FETCH_OP(op, c_op)
| ^~~
arch/ia64/include/asm/atomic.h:64:1: note: in expansion of macro 'ATOMIC_OPS'
64 | ATOMIC_OPS(add, +)
| ^~
arch/ia64/include/asm/atomic.h: In function 'ia64_atomic_sub':
>> include/linux/printk.h:311:3: error: expected identifier or '(' before '{'
>> token
311 | ({ \
| ^
include/linux/printk.h:331:26: note: in expansion of macro 'printk_store_fmt'
331 | #define printk(fmt, ...) printk_store_fmt(_printk, fmt,
##__VA_ARGS__)
| ^~~~
arch/ia64/include/uapi/asm/cmpxchg.h:142:14: note: in expansion of macro
'printk'
142 | extern int printk(const char *fmt, ...); \
| ^~
arch/ia64/include/asm/atomic.h:38:3: note: in expansion of macro
'CMPXCHG_BUGCHECK'
38 | CMPXCHG_BUGCHECK(v); \
| ^~~~
arch/ia64/include/asm/atomic.h:61:2: note: in expansion of macro 'ATOMIC_OP'
61 | ATOMIC_OP(op, c_op) \
| ^
arch/ia64/include/asm/atomic.h:65:1: note: in expansion of macro 'ATOMIC_OPS'
65 | ATOMIC_OPS(sub, -)
| ^~
a
Re: [PATCH] mt76: hold RCU lock when calling ieee80211_find_sta_by_ifaddr()
On 2021-02-12 03:13, Shuah Khan wrote: > ieee80211_find_sta_by_ifaddr() must be called under the RCU lock and > the resulting pointer is only valid under RCU lock as well. > > Fix mt76_check_sta() to hold RCU read lock before it calls > ieee80211_find_sta_by_ifaddr() and release it when the resulting > pointer is no longer needed. > > This problem was found while reviewing code to debug RCU warn from > ath10k_wmi_tlv_parse_peer_stats_info() and a subsequent manual audit > of other callers of ieee80211_find_sta_by_ifaddr() that don't hold > RCU read lock. > > Signed-off-by: Shuah Khan If I'm not mistaken, this patch is unnecessary. mt76_check_sta is only called from mt76_rx_poll_complete, which itself is only called under RCU lock. - Felix
drivers/mmc/host/sdhci-esdhc-imx.c:343:19: warning: unused function 'is_imx6q_usdhc'
Hi Krzysztof,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 291009f656e8eaebbdfd3a8d99f6b190a9ce9deb
commit: 54d8454436a205682bd89d66d8d9eedbc8452d15 mmc: host: Enable compile
testing of multiple drivers
date: 5 months ago
config: mips-randconfig-r036-20210212 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
c9439ca36342fb6013187d0a69aef92736951476)
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 mips cross compiling tool for clang build
# apt-get install binutils-mips-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=54d8454436a205682bd89d66d8d9eedbc8452d15
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 54d8454436a205682bd89d66d8d9eedbc8452d15
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/mmc/host/sdhci-esdhc-imx.c:343:19: warning: unused function
>> 'is_imx6q_usdhc'
static inline int is_imx6q_usdhc(struct pltfm_imx_data
^
fatal error: error in backend: Nested variants found in inline asm string:
'.if ( 0x00 ) != -1)) 0x00 ) != -1)) : ($( static struct ftrace_branch_data
__attribute__((__aligned__(4))) __attribute__((__section__("_ftrace_branch")))
__if_trace = $( .func = __func__, .file = "arch/mips/include/asm/barrier.h",
.line = 16, $); 0x00 ) != -1)) : $))) ) && ( (1 << 0) ); .set push; .set
mips64r2; .rept 1; sync 0x00; .endr; .set pop; .else; ; .endif'
clang-12: error: clang frontend command failed with exit code 70 (use -v to
see invocation)
clang version 12.0.0 (git://gitmirror/llvm_project
c9439ca36342fb6013187d0a69aef92736951476)
Target: mipsel-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/cross/clang-c9439ca363/bin
clang-12: note: diagnostic msg:
Makefile arch drivers fs include kernel mm scripts source usr
--
>> drivers/mmc/host/sdhci-sprd.c:134:20: warning: unused function
>> 'sdhci_sprd_writew'
static inline void sdhci_sprd_writew(struct sdhci_host u16 val, int reg)
^
fatal error: error in backend: Nested variants found in inline asm string:
'.if ( 0x00 ) != -1)) 0x00 ) != -1)) : ($( static struct ftrace_branch_data
__attribute__((__aligned__(4))) __attribute__((__section__("_ftrace_branch")))
__if_trace = $( .func = __func__, .file = "arch/mips/include/asm/barrier.h",
.line = 16, $); 0x00 ) != -1)) : $))) ) && ( (1 << 0) ); .set push; .set
mips64r2; .rept 1; sync 0x00; .endr; .set pop; .else; ; .endif'
clang-12: error: clang frontend command failed with exit code 70 (use -v to
see invocation)
clang version 12.0.0 (git://gitmirror/llvm_project
c9439ca36342fb6013187d0a69aef92736951476)
Target: mipsel-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/cross/clang-c9439ca363/bin
clang-12: note: diagnostic msg:
Makefile arch drivers fs include kernel mm scripts source usr
vim +/is_imx6q_usdhc +343 drivers/mmc/host/sdhci-esdhc-imx.c
57ed3314e0bfa9 Shawn Guo 2011-06-30 342
95a2482a9baaf5 Shawn Guo 2011-09-19 @343 static inline int
is_imx6q_usdhc(struct pltfm_imx_data *data)
95a2482a9baaf5 Shawn Guo 2011-09-19 344 {
f47c4bbfa283df Shawn Guo 2013-10-17 345return data->socdata ==
_imx6q_data;
95a2482a9baaf5 Shawn Guo 2011-09-19 346 }
95a2482a9baaf5 Shawn Guo 2011-09-19 347
:: The code at line 343 was first introduced by commit
:: 95a2482a9baaf55a3403d2e76f2abd7c0a32298c mmc: sdhci-esdhc-imx: add basic
imx6q usdhc support
:: TO: Shawn Guo
:: CC: Chris Ball
---
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 6/6] vfs: Disallow copy_file_range on generated file systems
On Fri, Feb 12, 2021 at 12:59 PM Darrick J. Wong wrote: > > On Thu, Feb 11, 2021 at 08:53:47PM -0800, Darrick J. Wong wrote: > > On Fri, Feb 12, 2021 at 12:44:05PM +0800, Nicolas Boichat wrote: > > > copy_file_range (which calls generic_copy_file_checks) uses the > > > inode file size to adjust the copy count parameter. This breaks > > > with special filesystems like procfs/sysfs/debugfs/tracefs, where > > > the file size appears to be zero, but content is actually returned > > > when a read operation is performed. Other issues would also > > > happen on partial writes, as the function would attempt to seek > > > in the input file. > > > > > > Use the newly introduced FS_GENERATED_CONTENT filesystem flag > > > to return -EOPNOTSUPP: applications can then retry with a more > > > usual read/write based file copy (the fallback code is usually > > > already present to handle older kernels). > > > > > > Signed-off-by: Nicolas Boichat > > > --- > > > > > > fs/read_write.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/fs/read_write.c b/fs/read_write.c > > > index 0029ff2b0ca8..80322e89fb0a 100644 > > > --- a/fs/read_write.c > > > +++ b/fs/read_write.c > > > @@ -1485,6 +1485,9 @@ ssize_t vfs_copy_file_range(struct file *file_in, > > > loff_t pos_in, > > > if (flags != 0) > > > return -EINVAL; > > > > > > + if (file_inode(file_in)->i_sb->s_type->fs_flags & > > > FS_GENERATED_CONTENT) > > > + return -EOPNOTSUPP; > > > > Why not declare a dummy copy_file_range_nop function that returns > > EOPNOTSUPP and point all of these filesystems at it? > > > > (Or, I guess in these days where function pointers are the enemy, > > create a #define that is a cast of 0x1, and fix do_copy_file_range to > > return EOPNOTSUPP if it sees that?) I was pondering abusing ERR_PTR(-EOPNOTSUPP) for this purpose ,-P > > Oh, I see, because that doesn't help if the source file is procfs and > the dest file is (say) xfs, because the generic version will try to do > splice magic and *poof*. Yep. I mean, we could still add a check if the file_in->f_op->copy_file_range == copy_file_range_nop in do_copy_file_range... But then we'd need to sprinkle .copy_file_range = copy_file_range_nop in many many places (~700 as a lower bound[1]), since the file operation structure is defined at the file level, not at the FS level, and people are likely to forget... [1] $ git grep "struct file_operations.*=" | grep debug | wc -l 631 $ git grep "struct file_operations.*=" | grep trace | wc -l 84 > > I guess the other nit thatI can think of at this late hour is ... what > about the other virtual filesystems like configfs and whatnot? Should > we have a way to flag them as "this can't be the source of a CFR > request" as well? > > Or is it just trace/debug/proc/sysfs that have these "zero size but > readable" speshul behaviors? I did try to audit the other filesystems. The ones I spotted: - devpts should be fine (only device nodes in there) - I think pstore doesn't need the flag as it's RAM-backed and persistent. But yes, I missed configfs, thanks for catching that. I think we need to add the flag for that one (looks like the sizes are all 4K). > > --D > > > > > --D > > > > > + > > > ret = generic_copy_file_checks(file_in, pos_in, file_out, pos_out, > > > , > > >flags); > > > if (unlikely(ret)) > > > -- > > > 2.30.0.478.g8a0d178c01-goog > > >
Re: [PATCH v2 2/6] platform/surface: aggregator_registry: Add base device hub
Hi Maximilian, I love your patch! Yet something to improve: [auto build test ERROR on next-20210211] [cannot apply to linus/master v5.11-rc7 v5.11-rc6 v5.11-rc5 v5.11-rc7] [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/Maximilian-Luz/platform-surface-Add-Surface-Aggregator-device-registry/20210212-035100 base:671176b0016c80b3943cb5387312c886aba3308d config: x86_64-allyesconfig (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce (this is a W=1 build): # https://github.com/0day-ci/linux/commit/32e4dc2a84e7cfca40f6efbf16ba50e294c70f1c git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Maximilian-Luz/platform-surface-Add-Surface-Aggregator-device-registry/20210212-035100 git checkout 32e4dc2a84e7cfca40f6efbf16ba50e294c70f1c # save the attached .config to linux build tree make W=1 ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): In file included from arch/x86/include/asm/bug.h:93, from include/linux/bug.h:5, from include/linux/cpumask.h:14, from include/linux/smp.h:13, from include/linux/lockdep.h:14, from include/linux/mutex.h:17, from include/linux/kernfs.h:12, from include/linux/sysfs.h:16, from include/linux/kobject.h:20, from include/linux/of.h:17, from include/linux/irqdomain.h:35, from include/linux/acpi.h:13, from drivers/platform/surface/surface_aggregator_registry.c:12: drivers/platform/surface/surface_aggregator_registry.c: In function '__ssam_base_hub_update': >> include/linux/lockdep.h:281:52: error: invalid type argument of '->' (have >> 'struct mutex') 281 | #define lockdep_is_held(lock) lock_is_held(&(lock)->dep_map) |^~ include/asm-generic/bug.h:119:25: note: in definition of macro 'WARN_ON' 119 | int __ret_warn_on = !!(condition);\ | ^ include/linux/lockdep.h:305:27: note: in expansion of macro 'lockdep_is_held' 305 | WARN_ON(debug_locks && !lockdep_is_held(l)); \ | ^~~ drivers/platform/surface/surface_aggregator_registry.c:266:2: note: in expansion of macro 'lockdep_assert_held' 266 | lockdep_assert_held(hub->lock); | ^~~ vim +281 include/linux/lockdep.h f607c668577481 Peter Zijlstra 2009-07-20 280 f8319483f57f1c Peter Zijlstra 2016-11-30 @281 #define lockdep_is_held(lock) lock_is_held(&(lock)->dep_map) f8319483f57f1c Peter Zijlstra 2016-11-30 282 #define lockdep_is_held_type(lock, r)lock_is_held_type(&(lock)->dep_map, (r)) f607c668577481 Peter Zijlstra 2009-07-20 283 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[git pull] drm fixes for 5.11 final
(resent with a subject this time) Hi Linus, Regular fixes for final, there is a ttm regression fix, dp-mst fix, one amdgpu revert, two i915 fixes, and some misc fixes for sun4i, xlnx, and vc4. All pretty quiet and don't think we have any known outstanding regressions. Dave. drm-fixes-2021-02-12: drm fixes for 5.11-rc8 ttm: - page pool regression fix. dp_mst: - Don't report un-attached ports as connected amdgpu: - Blank screen fix i915: - Ensure Type-C FIA is powered when initializing - Fix overlay frontbuffer tracking sun4i: - tcon1 sync polarity fix - Always set HDMI clock rate - Fix H6 HDMI PHY config - Fix H6 max frequency vc4: - Fix buffer overflow xlnx: - Fix memory leak The following changes since commit 92bf22614b21a2706f4993b278017e437f7785b3: Linux 5.11-rc7 (2021-02-07 13:57:38 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-02-12 for you to fetch changes up to 551c81853d6d3ff016269d62612e7cd0a53104ab: Merge branch 'drm-misc-fixes' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2021-02-12 13:38:51 +1000) drm fixes for 5.11-rc8 ttm: - page pool regression fix. dp_mst: - Don't report un-attached ports as connected amdgpu: - Blank screen fix i915: - Ensure Type-C FIA is powered when initializing - Fix overlay frontbuffer tracking sun4i: - tcon1 sync polarity fix - Always set HDMI clock rate - Fix H6 HDMI PHY config - Fix H6 max frequency vc4: - Fix buffer overflow xlnx: - Fix memory leak Alex Deucher (1): Revert "drm/amd/display: Update NV1x SR latency values" Christian König (1): drm/ttm: make sure pool pages are cleared Dave Airlie (3): Merge tag 'amd-drm-fixes-5.11-2021-02-10' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2021-02-11' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Merge branch 'drm-misc-fixes' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Imre Deak (2): drm/dp_mst: Don't report ports connected if nothing is attached to them drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it Jernej Skrabec (4): drm/sun4i: tcon: set sync polarity for tcon1 channel drm/sun4i: dw-hdmi: always set clock rate drm/sun4i: Fix H6 HDMI PHY configuration drm/sun4i: dw-hdmi: Fix max. frequency for H6 Maxime Ripard (1): drm/vc4: hvs: Fix buffer overflow with the dlist handling Quanyang Wang (1): drm/xlnx: fix kmemleak by sending vblank_event in atomic_disable Ville Syrjälä (1): drm/i915: Fix overlay frontbuffer tracking .../gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 4 +- drivers/gpu/drm/drm_dp_mst_topology.c | 1 + drivers/gpu/drm/i915/display/intel_overlay.c | 17 +++--- drivers/gpu/drm/i915/display/intel_tc.c| 67 -- drivers/gpu/drm/sun4i/sun4i_tcon.c | 25 drivers/gpu/drm/sun4i/sun4i_tcon.h | 6 ++ drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 10 +--- drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 - drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 26 +++-- drivers/gpu/drm/ttm/ttm_pool.c | 10 drivers/gpu/drm/vc4/vc4_plane.c| 18 -- drivers/gpu/drm/xlnx/zynqmp_disp.c | 15 +++-- 12 files changed, 122 insertions(+), 78 deletions(-)
[GIT PULL v2] extcon next for v5.12
Dear Greg, This is extcon-next pull request for v5.12. I add detailed description of this pull request on below. Please pull extcon with following updates. Changes from v1: - Add missing committer information Best Regards, Chanwoo Choi The following changes since commit 6ee1d745b7c9fd573fba142a2efdad76a9f1cb04: Linux 5.11-rc5 (2021-01-24 16:47:14 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git tags/extcon-next-for-5.12-v2 for you to fetch changes up to bd30a35764e136dc372e74c4856de633cb7ed8de: extcon: sm5502: Detect OTG when USB_ID is connected to ground (2021-02-10 08:15:28 +0900) Krzysztof Kozlowski (1): extcon: Add stubs for extcon_register_notifier_all() functions Nikita Travkin (1): extcon: sm5502: Detect OTG when USB_ID is connected to ground Timon Baetz (1): extcon: max8997: Add CHGINS and CHGRM interrupt handling
[PATCH] ARM: Implement Clang's SLS mitigation
This patch adds a config CONFIG_HARDEN_SLS_ALL that can be used to turn
on -mharden-sls=all, which mitigates the straight-line speculation
vulnerability, or more commonly known as Spectre, Meldown.
Notice -mharden-sls= has other options as below, and this config turns
on the strongest option.
all: enable all mitigations against Straight Line Speculation that are
implemented.
none: disable all mitigations against Straight Line Speculation.
retbr: enable the mitigation against Straight Line Speculation for RET and BR
instructions.
blr: enable the mitigation against Straight Line Speculation for BLR
instructions.
Link: https://reviews.llvm.org/D93221
Link: https://reviews.llvm.org/D81404
Link:
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation
Link: https://crbug.com/1171521
Suggested-by: Manoj Gupta
Signed-off-by: Jian Cai
---
arch/arm/Makefile | 4
arch/arm64/Makefile| 5 +
security/Kconfig.hardening | 11 +++
3 files changed, 20 insertions(+)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 4aaec9599e8a..11d89ef32da9 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -48,6 +48,10 @@ CHECKFLAGS += -D__ARMEL__
KBUILD_LDFLAGS += -EL
endif
+ifeq ($(CONFIG_HARDEN_SLS_ALL), y)
+KBUILD_CFLAGS += -mharden-sls=all
+endif
+
#
# The Scalar Replacement of Aggregates (SRA) optimization pass in GCC 4.9 and
# later may result in code being generated that handles signed short and signed
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 90309208bb28..8fd0ccd87eca 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -34,6 +34,11 @@ $(warning LSE atomics not supported by binutils)
endif
endif
+ifeq ($(CONFIG_HARDEN_SLS_ALL), y)
+KBUILD_CFLAGS += -mharden-sls=all
+endif
+
+
cc_has_k_constraint := $(call try-run,echo \
'int main(void) { \
asm volatile("and w0, w0, %w0" :: "K" (4294967295));\
diff --git a/security/Kconfig.hardening b/security/Kconfig.hardening
index 269967c4fc1b..d83c406c81a3 100644
--- a/security/Kconfig.hardening
+++ b/security/Kconfig.hardening
@@ -121,6 +121,17 @@ choice
endchoice
+
+config CC_HAS_HARDEN_SLS_ALL
+ def_bool $(cc-option,-mharden-sls=all)
+
+ config HARDEN_SLS_ALL
+ bool "enable SLS vulnerability hardening"
+ depends on CC_HAS_HARDEN_SLS_ALL
+ help
+ Enables straight-line speculation vulnerability hardening
+at highest level.
+
config GCC_PLUGIN_STRUCTLEAK_VERBOSE
bool "Report forcefully initialized variables"
depends on GCC_PLUGIN_STRUCTLEAK
--
2.30.0.478.g8a0d178c01-goog
[PATCH net-next 1/2] ptp: ptp_clockmatrix: Add wait_for_sys_apll_dpll_lock.
From: Vincent Cheng
Part of the device initialization aligns the rising edge of the output
clock to the internal 1 PPS clock. If the system APLL and DPLL is not
locked, then the alignment will fail and there will be a fixed offset
between the internal 1 PPS clock and the output clock.
After loading the device firmware, poll the system APLL and DPLL for
locked state prior to initialization, timing out after 2 seconds.
Signed-off-by: Vincent Cheng
---
drivers/ptp/idt8a340_reg.h| 10 ++
drivers/ptp/ptp_clockmatrix.c | 76 +--
drivers/ptp/ptp_clockmatrix.h | 17 --
3 files changed, 99 insertions(+), 4 deletions(-)
diff --git a/drivers/ptp/idt8a340_reg.h b/drivers/ptp/idt8a340_reg.h
index a664dfe..ac524cf 100644
--- a/drivers/ptp/idt8a340_reg.h
+++ b/drivers/ptp/idt8a340_reg.h
@@ -122,6 +122,8 @@
#define OTP_SCSR_CONFIG_SELECT0x0022
#define STATUS0xc03c
+#define DPLL_SYS_STATUS 0x0020
+#define DPLL_SYS_APLL_STATUS 0x0021
#define USER_GPIO0_TO_7_STATUS0x008a
#define USER_GPIO8_TO_15_STATUS 0x008b
@@ -707,4 +709,12 @@
/* Bit definitions for the DPLL_CTRL_COMBO_MASTER_CFG register */
#define COMBO_MASTER_HOLD BIT(0)
+/* Bit definitions for DPLL_SYS_STATUS register */
+#define DPLL_SYS_STATE_MASK (0xf)
+
+/* Bit definitions for SYS_APLL_STATUS register */
+#define SYS_APLL_LOSS_LOCK_LIVE_MASK BIT(0)
+#define SYS_APLL_LOSS_LOCK_LIVE_LOCKED 0
+#define SYS_APLL_LOSS_LOCK_LIVE_UNLOCKED 1
+
#endif
diff --git a/drivers/ptp/ptp_clockmatrix.c b/drivers/ptp/ptp_clockmatrix.c
index 051511f..1918de5 100644
--- a/drivers/ptp/ptp_clockmatrix.c
+++ b/drivers/ptp/ptp_clockmatrix.c
@@ -335,6 +335,79 @@ static int wait_for_boot_status_ready(struct idtcm *idtcm)
return -EBUSY;
}
+static int read_sys_apll_status(struct idtcm *idtcm, u8 *status)
+{
+ int err;
+
+ err = idtcm_read(idtcm, STATUS, DPLL_SYS_APLL_STATUS, status,
+sizeof(u8));
+
+ return err;
+}
+
+static int read_sys_dpll_status(struct idtcm *idtcm, u8 *status)
+{
+ int err;
+
+ err = idtcm_read(idtcm, STATUS, DPLL_SYS_STATUS, status, sizeof(u8));
+
+ return err;
+}
+
+static int wait_for_sys_apll_dpll_lock(struct idtcm *idtcm)
+{
+ char *fmt = "%d ms SYS lock timeout: APLL Loss Lock %d DPLL state %d";
+ u8 i = LOCK_TIMEOUT_MS / LOCK_POLL_INTERVAL_MS;
+ u8 apll = 0;
+ u8 dpll = 0;
+
+ int err;
+
+ do {
+ err = read_sys_apll_status(idtcm, );
+
+ if (err)
+ return err;
+
+ err = read_sys_dpll_status(idtcm, );
+
+ if (err)
+ return err;
+
+ apll &= SYS_APLL_LOSS_LOCK_LIVE_MASK;
+ dpll &= DPLL_SYS_STATE_MASK;
+
+ if ((apll == SYS_APLL_LOSS_LOCK_LIVE_LOCKED)
+ && (dpll == DPLL_STATE_LOCKED)) {
+ return 0;
+ } else if ((dpll == DPLL_STATE_FREERUN) ||
+ (dpll == DPLL_STATE_HOLDOVER) ||
+ (dpll == DPLL_STATE_OPEN_LOOP)) {
+ dev_warn(>client->dev,
+ "No wait state: DPLL_SYS_STATE %d", dpll);
+ return -EPERM;
+ }
+
+ msleep(LOCK_POLL_INTERVAL_MS);
+ i--;
+
+ } while (i);
+
+ dev_warn(>client->dev, fmt, LOCK_TIMEOUT_MS, apll, dpll);
+
+ return -ETIME;
+}
+
+static void wait_for_chip_ready(struct idtcm *idtcm)
+{
+ if (wait_for_boot_status_ready(idtcm))
+ dev_warn(>client->dev, "BOOT_STATUS != 0xA0");
+
+ if (wait_for_sys_apll_dpll_lock(idtcm))
+ dev_warn(>client->dev,
+"Continuing while SYS APLL/DPLL is not locked");
+}
+
static int _idtcm_gettime(struct idtcm_channel *channel,
struct timespec64 *ts)
{
@@ -2235,8 +2308,7 @@ static int idtcm_probe(struct i2c_client *client,
dev_warn(>client->dev,
"loading firmware failed with %d\n", err);
- if (wait_for_boot_status_ready(idtcm))
- dev_warn(>client->dev, "BOOT_STATUS != 0xA0\n");
+ wait_for_chip_ready(idtcm);
if (idtcm->tod_mask) {
for (i = 0; i < MAX_TOD; i++) {
diff --git a/drivers/ptp/ptp_clockmatrix.h b/drivers/ptp/ptp_clockmatrix.h
index 645de2c..fb32327 100644
--- a/drivers/ptp/ptp_clockmatrix.h
+++ b/drivers/ptp/ptp_clockmatrix.h
@@ -15,7 +15,6 @@
#define FW_FILENAME"idtcm.bin"
#define MAX_TOD(4)
#define MAX_PLL(8)
-#define MAX_OUTPUT (12)
#define MAX_ABS_WRITE_PHASE_PICOSECONDS (107374182350LL)
@@ -51,6 +50,9 @@
#define TOD_WRITE_OVERHEAD_COUNT_MAX (2)
#define TOD_BYTE_COUNT
[PATCH net-next 2/2] ptp: ptp_clockmatrix: Add alignment of 1 PPS to idtcm_perout_enable.
From: Vincent Cheng
When enabling output using PTP_CLK_REQ_PEROUT, need to align the output
clock to the internal 1 PPS clock.
Signed-off-by: Vincent Cheng
---
drivers/ptp/ptp_clockmatrix.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/ptp/ptp_clockmatrix.c b/drivers/ptp/ptp_clockmatrix.c
index 1918de5..ebe540e 100644
--- a/drivers/ptp/ptp_clockmatrix.c
+++ b/drivers/ptp/ptp_clockmatrix.c
@@ -1401,13 +1401,23 @@ static int idtcm_perout_enable(struct idtcm_channel
*channel,
bool enable,
struct ptp_perout_request *perout)
{
+ struct idtcm *idtcm = channel->idtcm;
unsigned int flags = perout->flags;
+ struct timespec64 ts = {0, 0};
+ int err;
if (flags == PEROUT_ENABLE_OUTPUT_MASK)
- return idtcm_output_mask_enable(channel, enable);
+ err = idtcm_output_mask_enable(channel, enable);
+ else
+ err = idtcm_output_enable(channel, enable, perout->index);
+
+ if (err) {
+ dev_err(>client->dev, "Unable to set output enable");
+ return err;
+ }
- /* Enable/disable individual output instead */
- return idtcm_output_enable(channel, enable, perout->index);
+ /* Align output to internal 1 PPS */
+ return _idtcm_settime(channel, , SCSR_TOD_WR_TYPE_SEL_DELTA_PLUS);
}
static int idtcm_get_pll_mode(struct idtcm_channel *channel,
--
2.7.4
[PATCH net-next 0/2] ptp: ptp_clockmatrix: Fix output 1 PPS alignment.
From: Vincent Cheng This series fixes a race condition that may result in the output clock not aligned to internal 1 PPS clock. Part of device initialization is to align the rising edge of output clocks to the internal rising edge of the 1 PPS clock. If the system APLL and DPLL are not locked when this alignment occurs, the alignment fails and a fixed offset between the internal 1 PPS clock and the output clock occurs. If a clock is dynamically enabled after power-up, the output clock also needs to be aligned to the internal 1 PPS clock. Vincent Cheng (2): ptp: ptp_clockmatrix: Add wait_for_sys_apll_dpll_lock. ptp: ptp_clockmatrix: Add alignment of 1 PPS to idtcm_perout_enable. drivers/ptp/idt8a340_reg.h| 10 + drivers/ptp/ptp_clockmatrix.c | 92 --- drivers/ptp/ptp_clockmatrix.h | 17 +++- 3 files changed, 112 insertions(+), 7 deletions(-) -- 2.7.4
RE: [Linuxarm] Re: [PATCH for next v1 1/2] gpio: omap: Replace raw_spin_lock_irqsave with raw_spin_lock in omap_gpio_irq_handler()
> -Original Message- > From: Grygorii Strashko [mailto:grygorii.stras...@ti.com] > Sent: Friday, February 12, 2021 9:17 AM > To: Arnd Bergmann > Cc: luojiaxing ; Linus Walleij > ; Andy Shevchenko ; Andy > Shevchenko ; Santosh Shilimkar > ; Kevin Hilman ; open list:GPIO > SUBSYSTEM , linux-kernel@vger.kernel.org > ; linux...@openeuler.org > Subject: [Linuxarm] Re: [PATCH for next v1 1/2] gpio: omap: Replace > raw_spin_lock_irqsave with raw_spin_lock in omap_gpio_irq_handler() > > > > On 11/02/2021 21:39, Arnd Bergmann wrote: > > On Thu, Feb 11, 2021 at 7:25 PM Grygorii Strashko > > wrote: > >> On 08/02/2021 10:56, Luo Jiaxing wrote: > >>> There is no need to use API with _irqsave in omap_gpio_irq_handler(), > >>> because it already be in a irq-disabled context. > >> > >> NACK. > >> Who said that this is always hard IRQ handler? > >> What about RT-kernel or boot with "threadirqs"? > > > > In those cases, the interrupt handler is just a normal thread, so the > > preempt_disable() that is implied by raw_spin_lock() is sufficient. > > > > Disabling interrupts inside of an interrupt handler is always incorrect, > > the patch looks like a useful cleanup to me, if only for readability. > > Note. there is also generic_handle_irq() call inside. So generic_handle_irq() is not safe to run in thread thus requires an interrupt-disabled environment to run? If so, I'd rather this irqsave moved into generic_handle_irq() rather than asking everyone calling it to do irqsave. On the other hand, the author changed a couple of spin_lock_irqsave to spin_lock, if only this one is incorrect, it seems it is worth a new version to fix this. > > -- > Best regards, > grygorii Thanks Barry
[PATCH] pinctrl: qcom: sc7280: Add GPIO wakeup interrupt map
From: Maulik Shah
GPIOs that can be configured as wakeup sources, have their
interrupt lines routed to PDC interrupt controller.
Provide the interrupt map of the GPIO to its wakeup capable
interrupt parent.
Signed-off-by: Maulik Shah
Signed-off-by: Rajendra Nayak
---
drivers/pinctrl/qcom/pinctrl-sc7280.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/pinctrl/qcom/pinctrl-sc7280.c
b/drivers/pinctrl/qcom/pinctrl-sc7280.c
index 8daccd5..99c416e 100644
--- a/drivers/pinctrl/qcom/pinctrl-sc7280.c
+++ b/drivers/pinctrl/qcom/pinctrl-sc7280.c
@@ -1449,6 +1449,28 @@ static const struct msm_pingroup sc7280_groups[] = {
[182] = SDC_QDSD_PINGROUP(sdc2_data, 0x1b4000, 9, 0),
};
+static const struct msm_gpio_wakeirq_map sc7280_pdc_map[] = {
+ { 0, 134 }, { 3, 131 }, { 4, 121 }, { 7, 103 }, { 8, 155 },
+ { 11, 93 }, { 12, 78 }, { 15, 79 }, { 16, 80 }, { 18, 81 },
+ { 19, 107 }, { 20, 82 }, { 21, 83 }, { 23, 99 }, { 24, 86 },
+ { 25, 95 }, { 27, 158 }, { 28, 159 }, { 31, 90 }, { 32, 144 },
+ { 34, 77 }, { 35, 92 }, { 36, 157 }, { 39, 73 }, { 40, 97 },
+ { 41, 98 }, { 43, 85 }, { 44, 100 }, { 45, 101 }, { 47, 102 },
+ { 48, 74 }, { 51, 112 }, { 52, 156 }, { 54, 117 }, { 55, 84 },
+ { 56, 108 }, { 59, 110 }, { 60, 111 }, { 61, 123 }, { 63, 104 },
+ { 68, 127 }, { 72, 150 }, { 75, 133 }, { 77, 125 }, { 78, 105 },
+ { 79, 106 }, { 80, 118 }, { 81, 119 }, { 82, 162 }, { 83, 122 },
+ { 86, 75 }, { 88, 154 }, { 89, 124 }, { 90, 149 }, { 91, 76 },
+ { 93, 128 }, { 95, 160 }, { 101, 126 }, { 102, 96 }, { 103, 116 },
+ { 104, 114 }, { 112, 72 }, { 116, 135 }, { 117, 163 }, { 119, 137 },
+ { 121, 138 }, { 123, 139 }, { 125, 140 }, { 127, 141 }, { 128, 165 },
+ { 129, 143 }, { 130, 94 }, { 131, 145 }, { 133, 146 }, { 136, 147 },
+ { 140, 148 }, { 141, 115 }, { 142, 113 }, { 145, 130 }, { 148, 132 },
+ { 150, 87 }, { 151, 88 }, { 153, 89 }, { 155, 164 }, { 156, 129 },
+ { 157, 161 }, { 158, 120 }, { 161, 136 }, { 163, 142 }, { 172, 166 },
+ { 174, 167 },
+};
+
static const struct msm_pinctrl_soc_data sc7280_pinctrl = {
.pins = sc7280_pins,
.npins = ARRAY_SIZE(sc7280_pins),
@@ -1457,6 +1479,8 @@ static const struct msm_pinctrl_soc_data sc7280_pinctrl =
{
.groups = sc7280_groups,
.ngroups = ARRAY_SIZE(sc7280_groups),
.ngpios = 176,
+ .wakeirq_map = sc7280_pdc_map,
+ .nwakeirq_map = ARRAY_SIZE(sc7280_pdc_map),
};
static int sc7280_pinctrl_probe(struct platform_device *pdev)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 6/6] vfs: Disallow copy_file_range on generated file systems
On Thu, Feb 11, 2021 at 08:53:47PM -0800, Darrick J. Wong wrote: > On Fri, Feb 12, 2021 at 12:44:05PM +0800, Nicolas Boichat wrote: > > copy_file_range (which calls generic_copy_file_checks) uses the > > inode file size to adjust the copy count parameter. This breaks > > with special filesystems like procfs/sysfs/debugfs/tracefs, where > > the file size appears to be zero, but content is actually returned > > when a read operation is performed. Other issues would also > > happen on partial writes, as the function would attempt to seek > > in the input file. > > > > Use the newly introduced FS_GENERATED_CONTENT filesystem flag > > to return -EOPNOTSUPP: applications can then retry with a more > > usual read/write based file copy (the fallback code is usually > > already present to handle older kernels). > > > > Signed-off-by: Nicolas Boichat > > --- > > > > fs/read_write.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/fs/read_write.c b/fs/read_write.c > > index 0029ff2b0ca8..80322e89fb0a 100644 > > --- a/fs/read_write.c > > +++ b/fs/read_write.c > > @@ -1485,6 +1485,9 @@ ssize_t vfs_copy_file_range(struct file *file_in, > > loff_t pos_in, > > if (flags != 0) > > return -EINVAL; > > > > + if (file_inode(file_in)->i_sb->s_type->fs_flags & FS_GENERATED_CONTENT) > > + return -EOPNOTSUPP; > > Why not declare a dummy copy_file_range_nop function that returns > EOPNOTSUPP and point all of these filesystems at it? > > (Or, I guess in these days where function pointers are the enemy, > create a #define that is a cast of 0x1, and fix do_copy_file_range to > return EOPNOTSUPP if it sees that?) Oh, I see, because that doesn't help if the source file is procfs and the dest file is (say) xfs, because the generic version will try to do splice magic and *poof*. I guess the other nit thatI can think of at this late hour is ... what about the other virtual filesystems like configfs and whatnot? Should we have a way to flag them as "this can't be the source of a CFR request" as well? Or is it just trace/debug/proc/sysfs that have these "zero size but readable" speshul behaviors? --D > > --D > > > + > > ret = generic_copy_file_checks(file_in, pos_in, file_out, pos_out, , > >flags); > > if (unlikely(ret)) > > -- > > 2.30.0.478.g8a0d178c01-goog > >
[PATCH] virt: acrn: Fix vCPU removing code build error
From: Shuo Liu
vCPU removing code depends on CONFIG_HOTPLUG_CPU as it uses remove_cpu()
and add_cpu(). Make the vCPU removing interface building with
CONFIG_HOTPLUG_CPU.
../drivers/virt/acrn/hsm.c: In function ‘remove_cpu_store’:
../drivers/virt/acrn/hsm.c:389:3: error: implicit declaration of function
‘remove_cpu’; [-Werror=implicit-function-declaration]
remove_cpu(cpu);
../drivers/virt/acrn/hsm.c:402:2: error: implicit declaration of function
‘add_cpu’; [-Werror=implicit-function-declaration]
add_cpu(cpu);
Fixes: 279dcf693ac7 ("virt: acrn: Introduce an interface for Service VM to
control vCPU")
Reported-by: Randy Dunlap
Acked-by: Randy Dunlap # build-tested
Signed-off-by: Shuo Liu
---
drivers/virt/acrn/hsm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/virt/acrn/hsm.c b/drivers/virt/acrn/hsm.c
index 1f6b7c54a1a4..e340788aacdf 100644
--- a/drivers/virt/acrn/hsm.c
+++ b/drivers/virt/acrn/hsm.c
@@ -372,6 +372,7 @@ static int acrn_dev_release(struct inode *inode, struct
file *filp)
return 0;
}
+#ifdef CONFIG_HOTPLUG_CPU
static ssize_t remove_cpu_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
@@ -403,9 +404,12 @@ static ssize_t remove_cpu_store(struct device *dev,
return ret;
}
static DEVICE_ATTR_WO(remove_cpu);
+#endif
static struct attribute *acrn_attrs[] = {
+#ifdef CONFIG_HOTPLUG_CPU
_attr_remove_cpu.attr,
+#endif
NULL
};
base-commit: 671176b0016c80b3943cb5387312c886aba3308d
--
2.28.0
Re: general protection fault in tomoyo_socket_sendmsg_permission
On 2021/02/12 11:22, Tetsuo Handa wrote:
> On 2021/02/12 10:34, Shuah Khan wrote:
>> On 2/10/21 6:14 PM, Tetsuo Handa wrote:
>>> (Dropping LSM ML because this is not a TOMOYO's bug.)
>>>
>>> On 2021/02/11 4:29, Shuah Khan wrote:
This is a good find. I already replied to the thread to send a complete
fix.
>>>
>>> As I said at
>>> https://lkml.kernel.org/r/f8cae6b1-8f84-0e6a-7d9c-fc4aec68f...@i-love.sakura.ne.jp
>>> ,
>>> the as-is patch is effectively a complete fix. And applying the as-is patch
>>> should help spending
>>> syzbot resources for reproducing "general protection fault in
>>> tomoyo_socket_sendmsg_permission"
>>> with debug printk() patch applied, which in turn will help you in
>>>
Right. I would like to get a clear understanding of how this condition
is triggered. I am not saying this isn't a problem. Understanding how
it is triggered helps find the best fix.
>>>
>>> part. Therefore, I strongly expect you to apply this version now.
>>>
>>
>> Is there a reproducer for this problem?
>
> There is no reproducer for "general protection fault in
> tomoyo_socket_sendmsg_permission" problem, but
> the race condition is explained at
> https://lkml.kernel.org/r/676d4518-0faa-9fab-15db-0db8d216d...@i-love.sakura.ne.jp
> .
>
Here is a race window widening patch, and I locally reproduced "general
protection fault in tomoyo_socket_sendmsg_permission".
diff --git a/drivers/usb/usbip/usbip_common.h b/drivers/usb/usbip/usbip_common.h
index 8be857a4fa13..a7c68097aa1d 100644
--- a/drivers/usb/usbip/usbip_common.h
+++ b/drivers/usb/usbip/usbip_common.h
@@ -286,6 +286,8 @@ struct usbip_device {
if (!IS_ERR(__k)) {\
get_task_struct(__k); \
wake_up_process(__k); \
+ } else { \
+ __k = NULL;\
} \
__k; \
})
diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c
index be37aec250c2..93e1271d0f5d 100644
--- a/drivers/usb/usbip/vhci_sysfs.c
+++ b/drivers/usb/usbip/vhci_sysfs.c
@@ -389,8 +389,12 @@ static ssize_t attach_store(struct device *dev, struct
device_attribute *attr,
/* end the lock */
vdev->ud.tcp_rx = kthread_get_run(vhci_rx_loop, >ud, "vhci_rx");
- vdev->ud.tcp_tx = kthread_get_run(vhci_tx_loop, >ud, "vhci_tx");
+ {
+ struct task_struct *tx = kthread_get_run(vhci_tx_loop,
>ud, "vhci_tx");
+ schedule_timeout_uninterruptible(HZ);
+ vdev->ud.tcp_tx = tx;
+ }
rh_port_connect(vdev, speed);
return count;
[ 134.880383][ T7879] vhci_hcd vhci_hcd.0: pdev(2) rhport(0) sockfd(6)
[ 134.883465][ T7879] vhci_hcd vhci_hcd.0: devid(0) speed(2)
speed_str(full-speed)
[ 134.904750][ T74] vhci_hcd: vhci_device speed not set
[ 134.933053][ T7873] vhci_hcd: connection closed
[ 134.933212][ T7870] vhci_hcd: connection closed
[ 134.933415][ T4488] vhci_hcd: stop threads
[ 134.942970][ T4488] vhci_hcd: release socket
[ 134.944949][ T14] vhci_hcd: vhci_device speed not set
[ 134.947063][ T4488] vhci_hcd: disconnect device
[ 134.951508][ T4488] vhci_hcd: stop threads
[ 134.953861][ T4488] vhci_hcd: release socket
[ 134.957113][ T4488] vhci_hcd: disconnect device
[ 135.014433][ T56] usb 15-1: enqueue for inactive port 0
[ 135.065119][ T7877] vhci_hcd: connection closed
[ 135.065205][ T7880] vhci_hcd: connection closed
[ 135.065370][ T4480] vhci_hcd: stop threads
[ 135.072854][ T4480] vhci_hcd: release socket
[ 135.076490][ T4480] vhci_hcd: disconnect device
[ 135.079535][ T4480] vhci_hcd: stop threads
[ 135.084024][ T4480] vhci_hcd: release socket
[ 135.087979][ T4480] vhci_hcd: disconnect device
[ 135.134526][ T6820] vhci_hcd: vhci_device speed not set
[ 135.314959][ T6821] vhci_hcd: vhci_device speed not set
[ 135.621271][ T7884] vhci_hcd vhci_hcd.0: pdev(4) rhport(0) sockfd(3)
[ 135.621290][ T7885] vhci_hcd vhci_hcd.0: pdev(0) rhport(0) sockfd(3)
[ 135.625072][ T7884] vhci_hcd vhci_hcd.0: devid(0) speed(5)
speed_str(super-speed)
[ 135.628665][ T7885] vhci_hcd vhci_hcd.0: devid(0) speed(5)
speed_str(super-speed)
[ 135.630109][ T7887] vhci_hcd vhci_hcd.0: pdev(1) rhport(0) sockfd(3)
[ 135.630116][ T7887] vhci_hcd vhci_hcd.0: devid(0) speed(5)
speed_str(super-speed)
[ 135.672834][ T7895] vhci_hcd vhci_hcd.0: pdev(0) rhport(0) sockfd(6)
[ 135.672863][ T7894] vhci_hcd vhci_hcd.0: pdev(4) rhport(0) sockfd(6)
[ 135.675986][ T7895] vhci_hcd vhci_hcd.0: devid(0) speed(2)
speed_str(full-speed)
[ 135.678963][ T7894] vhci_hcd vhci_hcd.0: devid(0) speed(2)
speed_str(full-speed)
[ 135.681093][ T7896] vhci_hcd vhci_hcd.0:
Re: sdhci.c:undefined reference to `mmc_can_gpio_cd'
On 2/11/21 1:44 AM, kernel test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 291009f656e8eaebbdfd3a8d99f6b190a9ce9deb > commit: e65bb38824711559844ba932132f417bc5a355e2 mmc: sdhci: do not enable > card detect interrupt for gpio cd type > date: 11 months ago > config: powerpc-randconfig-r032-20210210 (attached as .config) > compiler: powerpc-linux-gcc (GCC) 9.3.0 > reproduce (this is a W=1 build): > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e65bb38824711559844ba932132f417bc5a355e2 > git remote add linus > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > git fetch --no-tags linus master > git checkout e65bb38824711559844ba932132f417bc5a355e2 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross > ARCH=powerpc > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>): > >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/wimax/op-msg.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/wimax/op-reset.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/wimax/op-rfkill.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/wimax/op-state-get.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/wimax/stack.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/wimax/debugfs.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/batman-adv/bat_algo.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/batman-adv/bat_iv_ogm.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/batman-adv/bitarray.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/batman-adv/fragmentation.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/batman-adv/gateway_client.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/batman-adv/gateway_common.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/batman-adv/hard-interface.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/batman-adv/hash.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/batman-adv/log.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/batman-adv/main.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/batman-adv/netlink.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/batman-adv/originator.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/batman-adv/routing.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/batman-adv/send.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/batman-adv/soft-interface.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/batman-adv/tp_meter.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/batman-adv/translation-table.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/batman-adv/tvlv.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/nfc/core.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/nfc/netlink.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from > `net/nfc/af_nfc.o' being placed in section `.ctors.65435' >powerpc-linux-ld: warning: orphan section `.ctors.65435' from >
Re: [PATCH 2/3] net:ethernet:rmnet:Support for downlink MAPv5 csum offload
Hi Sharath,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on ipvs/master]
[also build test ERROR on linus/master sparc-next/master v5.11-rc7
next-20210211]
[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/Sharath-Chandra-Vurukala/docs-networking-Add-documentation-for-MAP-v5/20210212-063547
base: https://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs.git master
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/293142d706c02bf2e6ce7acb4e04ebb6cf4a2a63
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Sharath-Chandra-Vurukala/docs-networking-Add-documentation-for-MAP-v5/20210212-063547
git checkout 293142d706c02bf2e6ce7acb4e04ebb6cf4a2a63
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Note: the
linux-review/Sharath-Chandra-Vurukala/docs-networking-Add-documentation-for-MAP-v5/20210212-063547
HEAD 7f0a1e35c1d1c17de5873aded88d5dadfedce2fb builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c: In function
'rmnet_map_egress_handler':
>> drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:153:15: error: too few
>> arguments to function 'rmnet_map_add_map_header'
153 | map_header = rmnet_map_add_map_header(skb, additional_header_len,
0);
| ^~~~
In file included from
drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c:14:
drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h:66:26: note: declared here
66 | struct rmnet_map_header *rmnet_map_add_map_header(struct sk_buff
*skb,
| ^~~~
At top level:
drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h:76:11: warning:
'rmnet_map_get_next_hdr_type' defined but not used [-Wunused-function]
76 | static u8 rmnet_map_get_next_hdr_type(struct sk_buff *skb)
| ^~~
--
>> drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c:270:26: error:
>> conflicting types for 'rmnet_map_add_map_header'
270 | struct rmnet_map_header *rmnet_map_add_map_header(struct sk_buff
*skb,
| ^~~~
In file included from
drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c:12:
drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h:66:26: note: previous
declaration of 'rmnet_map_add_map_header' was here
66 | struct rmnet_map_header *rmnet_map_add_map_header(struct sk_buff
*skb,
| ^~~~
vim +/rmnet_map_add_map_header +153
drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c
ceed73a2cf4aff Subash Abhinov Kasiviswanathan 2017-08-29 129
ceed73a2cf4aff Subash Abhinov Kasiviswanathan 2017-08-29 130 static int
rmnet_map_egress_handler(struct sk_buff *skb,
56470c927f1ba1 Subash Abhinov Kasiviswanathan 2017-10-11 131
struct rmnet_port *port, u8 mux_id,
ceed73a2cf4aff Subash Abhinov Kasiviswanathan 2017-08-29 132
struct net_device *orig_dev)
ceed73a2cf4aff Subash Abhinov Kasiviswanathan 2017-08-29 133 {
ceed73a2cf4aff Subash Abhinov Kasiviswanathan 2017-08-29 134 int
required_headroom, additional_header_len;
ceed73a2cf4aff Subash Abhinov Kasiviswanathan 2017-08-29 135 struct
rmnet_map_header *map_header;
ceed73a2cf4aff Subash Abhinov Kasiviswanathan 2017-08-29 136
ceed73a2cf4aff Subash Abhinov Kasiviswanathan 2017-08-29 137
additional_header_len = 0;
ceed73a2cf4aff Subash Abhinov Kasiviswanathan 2017-08-29 138
required_headroom = sizeof(struct rmnet_map_header);
ceed73a2cf4aff Subash Abhinov Kasiviswanathan 2017-08-29 139
14452ca3b5ce30 Subash Abhinov Kasiviswanathan 2018-03-21 140 if
(port->data_format & RMNET_FLAGS_EGRESS_MAP_CKSUMV4) {
5eb5f8608ef118 Subash Abhinov Kasiviswanathan 2018-01-07 141
additional_header_len = sizeof(struct rmnet_map_ul_csum_header);
5eb5f8608ef118 Subash Abhinov Kasiviswanathan 2018-01-07 142
required_headroom += additional_header_len;
5eb5f8608ef118 Subash Abhinov Kasiviswanathan 2018-01-07 143 }
5eb5f8608ef118 Subash Abhinov Kasiviswanathan 2018-01-07 144
ceed73a2cf4aff Subash Abhinov Kasiviswanathan 20
Re: [PATCH 6/6] vfs: Disallow copy_file_range on generated file systems
On Fri, Feb 12, 2021 at 12:44:05PM +0800, Nicolas Boichat wrote: > copy_file_range (which calls generic_copy_file_checks) uses the > inode file size to adjust the copy count parameter. This breaks > with special filesystems like procfs/sysfs/debugfs/tracefs, where > the file size appears to be zero, but content is actually returned > when a read operation is performed. Other issues would also > happen on partial writes, as the function would attempt to seek > in the input file. > > Use the newly introduced FS_GENERATED_CONTENT filesystem flag > to return -EOPNOTSUPP: applications can then retry with a more > usual read/write based file copy (the fallback code is usually > already present to handle older kernels). > > Signed-off-by: Nicolas Boichat > --- > > fs/read_write.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/fs/read_write.c b/fs/read_write.c > index 0029ff2b0ca8..80322e89fb0a 100644 > --- a/fs/read_write.c > +++ b/fs/read_write.c > @@ -1485,6 +1485,9 @@ ssize_t vfs_copy_file_range(struct file *file_in, > loff_t pos_in, > if (flags != 0) > return -EINVAL; > > + if (file_inode(file_in)->i_sb->s_type->fs_flags & FS_GENERATED_CONTENT) > + return -EOPNOTSUPP; Why not declare a dummy copy_file_range_nop function that returns EOPNOTSUPP and point all of these filesystems at it? (Or, I guess in these days where function pointers are the enemy, create a #define that is a cast of 0x1, and fix do_copy_file_range to return EOPNOTSUPP if it sees that?) --D > + > ret = generic_copy_file_checks(file_in, pos_in, file_out, pos_out, , > flags); > if (unlikely(ret)) > -- > 2.30.0.478.g8a0d178c01-goog >
Re: [PATCH v2 0/2] hwmon: (pmbus) Add ST STPDDC60 pmbus driver
On 2/4/21 5:20 AM, Erik Rosen wrote: > This patch series adds hardware monitoring support for the ST STPDDC60 > chip. The driver has been tested with a Flex BMR481 converter. > > The checkpatch script complains about an unneeded paranthesis in an > if-statement but gcc gives a warning if it is removed. I side with > gcc in this case. > The if statement doesn't concern me, but I am a bit concerned that "u8 offset" may overflow. I understand that the return value won't overflow, but that doesn't necessarily apply to the calculation. In general, it is safer (and often generates less code) to declare such variables as int or u32. Anyway, I don't see a change log against v1 of the series, meaning I'll have to spend additional time to determine what changed and if the feedback has been addressed. I'll look at it after the v5.12 commit window closed. Thanks, Guenter > Erik Rosen (2): > Add pmbus_set_update() function to set update flag on selected sensors > Add ST STPDDC60 pmbus driver > > Documentation/hwmon/index.rst| 1 + > Documentation/hwmon/stpddc60.rst | 90 +++ > MAINTAINERS | 7 + > drivers/hwmon/pmbus/Kconfig | 10 ++ > drivers/hwmon/pmbus/Makefile | 2 + > drivers/hwmon/pmbus/pmbus.h | 1 + > drivers/hwmon/pmbus/pmbus_core.c | 11 ++ > drivers/hwmon/pmbus/stpddc60.c | 248 +++ > 8 files changed, 370 insertions(+) > create mode 100644 Documentation/hwmon/stpddc60.rst > create mode 100644 drivers/hwmon/pmbus/stpddc60.c > > > base-commit: 6ee1d745b7c9fd573fba142a2efdad76a9f1cb04 >
Re: [PATCH] fs: generic_copy_file_checks: Do not adjust count based on file size
On Thu, Jan 28, 2021 at 1:57 PM Darrick J. Wong wrote: > > On Thu, Jan 28, 2021 at 08:46:04AM +0800, Nicolas Boichat wrote: [snip] > > Okay, so, based on this and Al's reply, I see 2 things we can do: > > 1. Go should probably not use copy_file_range in a common library > > function, as I don't see any easy way to detect this scenario > > currently (detect 0 size? sure, but that won't work with the example > > you provide above). And the man page should document this behaviour > > more explicitly to prevent further incorrect usage. > > 2. Can procfs/sysfs/debugfs and friends explicitly prevent usage of > > copy_file_range? (based on Al's reply, there seems to be no way to > > implement it correctly as seeking in such files will not work in case > > of short writes) > > One /could/ make those three provide a phony CFR implementation that > would return -EOPNOTSUPP, though like others have said, it's weird to > have regular files that aren't quite regular. Not sure where that > leaves them, though... Not that simple, as the issue happens on cross-filesystem operations where file_operations->copy_file_range is not called (and also, that'd require modifying operations for every single generated file... Anyway, made an attempt here: https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drink...@chromium.org/T/#t > --D > > > > > Thanks, > > > > > > > > Cheers, > > > > > > Dave. > > > -- > > > Dave Chinner > > > da...@fromorbit.com
Re: [PATCH 4.19 00/24] 4.19.176-rc1 review
On Thu, 11 Feb 2021 at 20:36, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.19.176 release.
> There are 24 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 13 Feb 2021 15:01:39 +.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
>
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.176-rc1.gz
> or in the git tree and branch at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
The following lockdep noticed on the arm beaglebone x15 device.
I have not bisected this problem yet.
Suspecting this patch,
> David Collins
> regulator: core: avoid regulator_resolve_supply() race condition
[2.470568] WARNING: possible recursive locking detected
[2.470580] 4.19.176-rc1 #1 Not tainted
[2.470590]
[2.470600] swapper/0/1 is trying to acquire lock:
[2.470611] (ptrval) (>mutex){+.+.}, at: regulator_enable+0x44/0x20c
[2.470639]
[2.470639] but task is already holding lock:
[2.470650] (ptrval) (>mutex){+.+.}, at:
regulator_lock_nested+0x28/0x88
[2.470676]
[2.470676] other info that might help us debug this:
[2.470687] Possible unsafe locking scenario:
[2.470687]
[2.470698]CPU0
[2.470707]
[2.470716] lock(>mutex);
[2.470728] lock(>mutex);
[2.470740]
[2.470740] *** DEADLOCK ***
[2.470740]
[2.470752] May be due to missing lock nesting notation
[2.470752]
[2.470765] 2 locks held by swapper/0/1:
[2.470774] #0: (ptrval) (>mutex){}, at: __driver_attach+0x78/0x168
[2.470797] #1: (ptrval) (>mutex){+.+.}, at:
regulator_lock_nested+0x28/0x88
[2.470820]
[2.470820] stack backtrace:
[2.470836] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.19.176-rc1 #1
[2.470846] Hardware name: Generic DRA74X (Flattened Device Tree)
[2.470871] [] (unwind_backtrace) from []
(show_stack+0x20/0x24)
[2.470891] [] (show_stack) from []
(dump_stack+0xe8/0x114)
[2.470910] [] (dump_stack) from []
(__lock_acquire+0x7cc/0x1acc)
[2.470925] [] (__lock_acquire) from []
(lock_acquire+0xdc/0x238)
[2.470941] [] (lock_acquire) from []
(__mutex_lock+0xa0/0xaf4)
[2.470958] [] (__mutex_lock) from []
(mutex_lock_nested+0x2c/0x34)
[2.470974] [] (mutex_lock_nested) from []
(regulator_enable+0x44/0x20c)
[2.470990] [] (regulator_enable) from []
(regulator_resolve_supply+0x184/0x2c8)
[2.471006] [] (regulator_resolve_supply) from
[] (regulator_register_resolve_supply+0x24/0x8c)
[2.471022] [] (regulator_register_resolve_supply) from
[] (class_for_each_device+0x70/0xe8)
[2.471037] [] (class_for_each_device) from []
(regulator_register+0xa18/0xc58)
[2.471053] [] (regulator_register) from []
(devm_regulator_register+0x54/0x84)
[2.471069] [] (devm_regulator_register) from
[] (pbias_regulator_probe+0x1f4/0x2d0)
[2.471084] [] (pbias_regulator_probe) from []
(platform_drv_probe+0x58/0xa8)
[2.471101] [] (platform_drv_probe) from []
(really_probe+0x310/0x418)
[2.471119] [] (really_probe) from []
(driver_probe_device+0x88/0x1dc)
[2.471135] [] (driver_probe_device) from []
(__driver_attach+0x14c/0x168)
[2.471150] [] (__driver_attach) from []
(bus_for_each_dev+0x84/0xc4)
[2.471167] [] (bus_for_each_dev) from []
(driver_attach+0x2c/0x30)
[2.471184] [] (driver_attach) from []
(bus_add_driver+0x1d0/0x274)
[2.471199] [] (bus_add_driver) from []
(driver_register+0x84/0x118)
[2.471213] [] (driver_register) from []
(__platform_driver_register+0x50/0x58)
[2.471231] [] (__platform_driver_register) from
[] (pbias_regulator_driver_init+0x24/0x28)
[2.471249] [] (pbias_regulator_driver_init) from
[] (do_one_initcall+0xa0/0x394)
[2.471268] [] (do_one_initcall) from []
(kernel_init_freeable+0x3ec/0x484)
[2.471283] [] (kernel_init_freeable) from []
(kernel_init+0x18/0x128)
[2.471299] [] (kernel_init) from []
(ret_from_fork+0x14/0x28)
[2.471310] Exception stack(0xee19bfb0 to 0xee19bff8)
[2.471323] bfa0:
[2.471336] bfc0:
[2.471348] bfe0: 0013
[2.471385] vtt_fixed: supplied by smps3
test log link,
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.175-25-g30e16c3fd5ac/testrun/3938030/suite/linux-log-parser/test/check-kernel-warning-2263196/log
metadata:
git branch: linux-4.19.y
git repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git commit:
[PATCH 6/6] vfs: Disallow copy_file_range on generated file systems
copy_file_range (which calls generic_copy_file_checks) uses the inode file size to adjust the copy count parameter. This breaks with special filesystems like procfs/sysfs/debugfs/tracefs, where the file size appears to be zero, but content is actually returned when a read operation is performed. Other issues would also happen on partial writes, as the function would attempt to seek in the input file. Use the newly introduced FS_GENERATED_CONTENT filesystem flag to return -EOPNOTSUPP: applications can then retry with a more usual read/write based file copy (the fallback code is usually already present to handle older kernels). Signed-off-by: Nicolas Boichat --- fs/read_write.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/read_write.c b/fs/read_write.c index 0029ff2b0ca8..80322e89fb0a 100644 --- a/fs/read_write.c +++ b/fs/read_write.c @@ -1485,6 +1485,9 @@ ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in, if (flags != 0) return -EINVAL; + if (file_inode(file_in)->i_sb->s_type->fs_flags & FS_GENERATED_CONTENT) + return -EOPNOTSUPP; + ret = generic_copy_file_checks(file_in, pos_in, file_out, pos_out, , flags); if (unlikely(ret)) -- 2.30.0.478.g8a0d178c01-goog
[PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated
Filesystems such as procfs and sysfs generate their content at
runtime. This implies the file sizes do not usually match the
amount of data that can be read from the file, and that seeking
may not work as intended.
This will be useful to disallow copy_file_range with input files
from such filesystems.
Signed-off-by: Nicolas Boichat
---
I first thought of adding a new field to struct file_operations,
but that doesn't quite scale as every single file creation
operation would need to be modified.
include/linux/fs.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 3482146b11b0..5bd58b928e94 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2335,6 +2335,7 @@ struct file_system_type {
#define FS_ALLOW_IDMAP 32 /* FS has been updated to handle vfs
idmappings. */
#define FS_THP_SUPPORT 8192/* Remove once all fs converted */
#define FS_RENAME_DOES_D_MOVE 32768 /* FS will handle d_move() during
rename() internally. */
+#define FS_GENERATED_CONTENT 65536 /* FS contains generated content */
int (*init_fs_context)(struct fs_context *);
const struct fs_parameter_spec *parameters;
struct dentry *(*mount) (struct file_system_type *, int,
--
2.30.0.478.g8a0d178c01-goog
[PATCH 2/6] proc: Add FS_GENERATED_CONTENT to filesystem flags
procfs content is generated at runtime.
Signed-off-by: Nicolas Boichat
---
fs/proc/root.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/proc/root.c b/fs/proc/root.c
index c7e3b1350ef8..7ed715a0f807 100644
--- a/fs/proc/root.c
+++ b/fs/proc/root.c
@@ -282,7 +282,7 @@ static struct file_system_type proc_fs_type = {
.init_fs_context= proc_init_fs_context,
.parameters = proc_fs_parameters,
.kill_sb= proc_kill_sb,
- .fs_flags = FS_USERNS_MOUNT | FS_DISALLOW_NOTIFY_PERM,
+ .fs_flags = FS_USERNS_MOUNT | FS_DISALLOW_NOTIFY_PERM |
FS_GENERATED_CONTENT,
};
void __init proc_root_init(void)
--
2.30.0.478.g8a0d178c01-goog
[PATCH 5/6] tracefs: Add FS_GENERATED_CONTENT to filesystem flags
tracefs content is generated at runtime.
Signed-off-by: Nicolas Boichat
---
fs/tracefs/inode.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/tracefs/inode.c b/fs/tracefs/inode.c
index 4b83cbded559..89980312c7a3 100644
--- a/fs/tracefs/inode.c
+++ b/fs/tracefs/inode.c
@@ -308,6 +308,7 @@ static struct file_system_type trace_fs_type = {
.name = "tracefs",
.mount =trace_mount,
.kill_sb = kill_litter_super,
+ .fs_flags = FS_GENERATED_CONTENT,
};
MODULE_ALIAS_FS("tracefs");
--
2.30.0.478.g8a0d178c01-goog
[PATCH 4/6] debugfs: Add FS_GENERATED_CONTENT to filesystem flags
debugfs content is generated at runtime.
Signed-off-by: Nicolas Boichat
---
fs/debugfs/inode.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index c35249497b9b..2bbc5e6d3041 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -279,6 +279,7 @@ static struct file_system_type debug_fs_type = {
.name = "debugfs",
.mount =debug_mount,
.kill_sb = kill_litter_super,
+ .fs_flags = FS_GENERATED_CONTENT,
};
MODULE_ALIAS_FS("debugfs");
--
2.30.0.478.g8a0d178c01-goog
[PATCH 3/6] sysfs: Add FS_GENERATED_CONTENT to filesystem flags
sysfs content is generated at runtime.
Signed-off-by: Nicolas Boichat
---
fs/sysfs/mount.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/sysfs/mount.c b/fs/sysfs/mount.c
index e747c135c1d1..7e367ae5edc1 100644
--- a/fs/sysfs/mount.c
+++ b/fs/sysfs/mount.c
@@ -91,7 +91,7 @@ static struct file_system_type sysfs_fs_type = {
.name = "sysfs",
.init_fs_context= sysfs_init_fs_context,
.kill_sb= sysfs_kill_sb,
- .fs_flags = FS_USERNS_MOUNT,
+ .fs_flags = FS_USERNS_MOUNT | FS_GENERATED_CONTENT,
};
int __init sysfs_init(void)
--
2.30.0.478.g8a0d178c01-goog
[PATCH 0/6] Add generated flag to filesystem struct to block copy_file_range
We hit an issue when upgrading Go compiler from 1.13 to 1.15 [1], as we use Go's `io.Copy` to copy the content of `/sys/kernel/debug/tracing/trace` to a temporary file. Under the hood, Go 1.15 uses `copy_file_range` syscall to optimize the copy operation. However, that fails to copy any content when the input file is from tracefs, with an apparent size of 0 (but there is still content when you `cat` it, of course). >From discussions in [2][3], it is clear that copy_file_range cannot be properly implemented on filesystems where the content is generated at runtime: the file size is incorrect (because it is unknown before the content is generated), and seeking in such files (as required by partial writes) is unlikely to work correctly. With this patch, Go's `io.Copy` gracefully falls back to a normal read/write file copy. I'm not 100% sure which stable tree this should go in, I'd say at least >=5.3 since this is what introduced support for cross-filesystem copy_file_range (and where most users are somewhat likely to hit this issue). But let's discuss the patch series first. [1] http://issuetracker.google.com/issues/178332739 [2] https://lkml.org/lkml/2021/1/25/64 [3] https://lkml.org/lkml/2021/1/26/1736 Nicolas Boichat (6): fs: Add flag to file_system_type to indicate content is generated proc: Add FS_GENERATED_CONTENT to filesystem flags sysfs: Add FS_GENERATED_CONTENT to filesystem flags debugfs: Add FS_GENERATED_CONTENT to filesystem flags tracefs: Add FS_GENERATED_CONTENT to filesystem flags vfs: Disallow copy_file_range on generated file systems fs/debugfs/inode.c | 1 + fs/proc/root.c | 2 +- fs/read_write.c| 3 +++ fs/sysfs/mount.c | 2 +- fs/tracefs/inode.c | 1 + include/linux/fs.h | 1 + 6 files changed, 8 insertions(+), 2 deletions(-) -- 2.30.0.478.g8a0d178c01-goog
Re: [PATCH V7 1/3] kbuild: Add generic rule to apply fdtoverlay
On 12-02-21, 12:07, Masahiro Yamada wrote: > BTW, I do not know how to use overlay. > Do we apply overlay in the build time? Ideally it can be applied at both build time and runtime, but we haven't allowed the runtime way until now in kernel. This patchset is all about applying it at build time. > If so, I do not know what the benefit of overlay is. > Or is this just for build testing? For now the main benefit of using them is that we can keep stuff in separate files without including each other. For example a primary board may or may not have an extension board connected to it. Without overlays we will have this many dtbs for this simple case: 1. primary.dtb 2. extension.dtb 3. primary-includes-extension.dtb With overlays we will have the first two. Now the same extension can be applied to lots of boards and multiple extensions can be applied to the same primary board. This just complicates the process of managing dtbs. > I just thought this was done in the boot time, > for example, in U-Boot or something. Yes, bootloader can do it as well. -- viresh
Re: [PATCH 1/2] dt-bindings: remoteproc: qcom: pas: Add SM8350 remoteprocs
On 11-02-21, 12:52, Bjorn Andersson wrote: > On Wed 10 Feb 04:45 CST 2021, Vinod Koul wrote: > > > Add the SM8350 audio, compute, modem and sensor remoteprocs to the PAS > > DT binding. > > > > Signed-off-by: Vinod Koul > > --- > > .../devicetree/bindings/remoteproc/qcom,adsp.txt | 12 > > 1 file changed, 12 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt > > b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt > > index 54737024da20..41eaa2466aab 100644 > > --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt > > +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt > > @@ -25,6 +25,10 @@ on the Qualcomm ADSP Hexagon core. > > "qcom,sm8250-adsp-pas" > > "qcom,sm8250-cdsp-pas" > > "qcom,sm8250-slpi-pas" > > + "qcom,sm8350-adsp-pas" > > + "qcom,sm8350-cdsp-pas" > > + "qcom,sm8350-slpi-pas" > > + "qcom,sm8350-mpss-pas" > > > > - interrupts-extended: > > Usage: required > > @@ -51,10 +55,14 @@ on the Qualcomm ADSP Hexagon core. > > qcom,sm8250-adsp-pas: > > qcom,sm8250-cdsp-pas: > > qcom,sm8250-slpi-pas: > > + qcom,sm8350-adsp-pas: > > + qcom,sm8350-cdsp-pas: > > + qcom,sm8350-slpi-pas: > > must be "wdog", "fatal", "ready", "handover", "stop-ack" > > qcom,qcs404-wcss-pas: > > qcom,sc7180-mpss-pas: > > qcom,sm8150-mpss-pas: > > + qcom,sm8350-mpss-pas: > > must be "wdog", "fatal", "ready", "handover", "stop-ack", > > "shutdown-ack" > > > > @@ -113,14 +121,18 @@ on the Qualcomm ADSP Hexagon core. > > qcom,sdm845-cdsp-pas: > > qcom,sm8150-adsp-pas: > > qcom,sm8150-cdsp-pas: > > + qcom,sm8250-cdsp-pas: > > This should be sm8350, I fixed this up and applied the patch. Sorry for missing this and thanks for fixing it up -- ~Vinod
[PATCH] perf libperf: Remove unused xyarray.c
Migrated to libperf in:
commit 4b247fa7314c ("libperf: Adopt xyarray class from perf")
Signed-off-by: Ian Rogers
---
tools/perf/util/xyarray.c | 33 -
1 file changed, 33 deletions(-)
delete mode 100644 tools/perf/util/xyarray.c
diff --git a/tools/perf/util/xyarray.c b/tools/perf/util/xyarray.c
deleted file mode 100644
index 86889ebc3514..
--- a/tools/perf/util/xyarray.c
+++ /dev/null
@@ -1,33 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include "xyarray.h"
-#include
-#include
-#include
-
-struct xyarray *xyarray__new(int xlen, int ylen, size_t entry_size)
-{
- size_t row_size = ylen * entry_size;
- struct xyarray *xy = zalloc(sizeof(*xy) + xlen * row_size);
-
- if (xy != NULL) {
- xy->entry_size = entry_size;
- xy->row_size = row_size;
- xy->entries= xlen * ylen;
- xy->max_x = xlen;
- xy->max_y = ylen;
- }
-
- return xy;
-}
-
-void xyarray__reset(struct xyarray *xy)
-{
- size_t n = xy->entries * xy->entry_size;
-
- memset(xy->contents, 0, n);
-}
-
-void xyarray__delete(struct xyarray *xy)
-{
- free(xy);
-}
--
2.30.0.478.g8a0d178c01-goog
include/linux/unaligned/be_byteshift.h:46:19: error: redefinition of 'get_unaligned_be32'
Hi Gene, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 291009f656e8eaebbdfd3a8d99f6b190a9ce9deb commit: 1f4877218f7e2c2b914aeb69a8a0f47d59c74717 iio: adc: mt6360: Add ADC driver for MT6360 date: 3 months ago config: arc-allyesconfig (attached as .config) compiler: arceb-elf-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1f4877218f7e2c2b914aeb69a8a0f47d59c74717 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 1f4877218f7e2c2b914aeb69a8a0f47d59c74717 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): In file included from drivers/iio/adc/mt6360-adc.c:12: include/linux/unaligned/be_byteshift.h:41:19: error: redefinition of 'get_unaligned_be16' 41 | static inline u16 get_unaligned_be16(const void *p) | ^~ In file included from include/asm-generic/unaligned.h:13, from arch/arc/include/asm/unaligned.h:11, from arch/arc/include/asm/io.h:12, from include/linux/io.h:13, from include/linux/irq.h:20, from drivers/iio/adc/mt6360-adc.c:5: include/linux/unaligned/access_ok.h:23:28: note: previous definition of 'get_unaligned_be16' was here 23 | static __always_inline u16 get_unaligned_be16(const void *p) |^~ In file included from drivers/iio/adc/mt6360-adc.c:12: >> include/linux/unaligned/be_byteshift.h:46:19: error: redefinition of >> 'get_unaligned_be32' 46 | static inline u32 get_unaligned_be32(const void *p) | ^~ In file included from include/asm-generic/unaligned.h:13, from arch/arc/include/asm/unaligned.h:11, from arch/arc/include/asm/io.h:12, from include/linux/io.h:13, from include/linux/irq.h:20, from drivers/iio/adc/mt6360-adc.c:5: include/linux/unaligned/access_ok.h:28:28: note: previous definition of 'get_unaligned_be32' was here 28 | static __always_inline u32 get_unaligned_be32(const void *p) |^~ In file included from drivers/iio/adc/mt6360-adc.c:12: include/linux/unaligned/be_byteshift.h:51:19: error: redefinition of 'get_unaligned_be64' 51 | static inline u64 get_unaligned_be64(const void *p) | ^~ In file included from include/asm-generic/unaligned.h:13, from arch/arc/include/asm/unaligned.h:11, from arch/arc/include/asm/io.h:12, from include/linux/io.h:13, from include/linux/irq.h:20, from drivers/iio/adc/mt6360-adc.c:5: include/linux/unaligned/access_ok.h:33:28: note: previous definition of 'get_unaligned_be64' was here 33 | static __always_inline u64 get_unaligned_be64(const void *p) |^~ In file included from drivers/iio/adc/mt6360-adc.c:12: include/linux/unaligned/be_byteshift.h:56:20: error: redefinition of 'put_unaligned_be16' 56 | static inline void put_unaligned_be16(u16 val, void *p) |^~ In file included from include/asm-generic/unaligned.h:13, from arch/arc/include/asm/unaligned.h:11, from arch/arc/include/asm/io.h:12, from include/linux/io.h:13, from include/linux/irq.h:20, from drivers/iio/adc/mt6360-adc.c:5: include/linux/unaligned/access_ok.h:53:29: note: previous definition of 'put_unaligned_be16' was here 53 | static __always_inline void put_unaligned_be16(u16 val, void *p) | ^~ In file included from drivers/iio/adc/mt6360-adc.c:12: >> include/linux/unaligned/be_byteshift.h:61:20: error: redefinition of >> 'put_unaligned_be32' 61 | static inline void put_unaligned_be32(u32 val, void *p) |^~ In file included from include/asm-generic/unaligned.h:13, from arch/arc/include/asm/unaligned.h:11, from arch/arc/include/asm/io.h:12, from include/linux/io.h:13,
Re: [PATCH v5 3/3] MAINTAINERS: Add entry for Texas Instruments TPS23861 PoE PSE
On Thu, Jan 21, 2021 at 02:44:34PM +0100, Robert Marko wrote: > Add maintainers entry for the Texas Instruments TPS23861 PoE PSE driver. > > Signed-off-by: Robert Marko > Cc: Luka Perkov > Reviewed-by: Guenter Roeck Applied. Thanks, Guenter > --- > Changes in v4: > * Add documentation file > > MAINTAINERS | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index f95e887e5d76..2a7f22587774 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -17602,6 +17602,15 @@ F: include/dt-bindings/soc/ti,sci_pm_domain.h > F: include/linux/soc/ti/ti_sci_inta_msi.h > F: include/linux/soc/ti/ti_sci_protocol.h > > +TEXAS INSTRUMENTS TPS23861 PoE PSE DRIVER > +M: Robert Marko > +M: Luka Perkov > +L: linux-hw...@vger.kernel.org > +S: Maintained > +F: Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml > +F: Documentation/hwmon/tps23861.rst > +F: drivers/hwmon/tps23861.c > + > THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER > M: Hans Verkuil > L: linux-me...@vger.kernel.org
Re: [PATCH v5 2/3] hwmon: add Texas Instruments TPS23861 driver
On Thu, Jan 21, 2021 at 02:44:33PM +0100, Robert Marko wrote: > Add basic monitoring support as well as port on/off control for Texas > Instruments TPS23861 PoE PSE IC. > > Signed-off-by: Robert Marko > Cc: Luka Perkov > Reviewed-by: Guenter Roeck Applied. Thanks, Guenter > --- > Changes in v4: > * Add documentation > * Correct of_property_read_u32() return check > * Drop useless and incorrect debugfs return check > > Changes in v3: > * Leave only standard values in hwmon hwmon > * Drop custom sysfs entries > * Use debugfs to provide non standard debug information > * Add temperature label > * Use hwmon_in_enable to enable/disable ports > > Changes in v2: > * Convert to devm_hwmon_device_register_with_info() > * Change license > > Documentation/hwmon/index.rst| 1 + > Documentation/hwmon/tps23861.rst | 41 +++ > drivers/hwmon/Kconfig| 11 + > drivers/hwmon/Makefile | 1 + > drivers/hwmon/tps23861.c | 601 +++ > 5 files changed, 655 insertions(+) > create mode 100644 Documentation/hwmon/tps23861.rst > create mode 100644 drivers/hwmon/tps23861.c > > diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst > index fcb870ce6286..2c94f0b524dd 100644 > --- a/Documentation/hwmon/index.rst > +++ b/Documentation/hwmon/index.rst > @@ -178,6 +178,7 @@ Hardware Monitoring Kernel Drivers > tmp401 > tmp421 > tmp513 > + tps23861 > tps40422 > tps53679 > twl4030-madc-hwmon > diff --git a/Documentation/hwmon/tps23861.rst > b/Documentation/hwmon/tps23861.rst > new file mode 100644 > index ..46d121ff3f31 > --- /dev/null > +++ b/Documentation/hwmon/tps23861.rst > @@ -0,0 +1,41 @@ > +.. SPDX-License-Identifier: GPL-2.0-only > + > +Kernel driver tps23861 > +== > + > +Supported chips: > + * Texas Instruments TPS23861 > + > +Prefix: 'tps23861' > + > +Datasheet: https://www.ti.com/lit/gpn/tps23861 > + > +Author: Robert Marko > + > +Description > +--- > + > +This driver supports hardware monitoring for Texas Instruments TPS23861 PoE > PSE. > + > +TPS23861 is a quad port IEEE802.3at PSE controller with optional I2C control > +and monitoring capabilities. > + > +TPS23861 offers three modes of operation: Auto, Semi-Auto and Manual. > + > +This driver only supports the Auto mode of operation providing monitoring > +as well as enabling/disabling the four ports. > + > +Sysfs entries > +- > + > +=== > = > +in[0-3]_inputVoltage on ports [1-4] > +in[0-3]_label"Port[1-4]" > +in4_inputIC input voltage > +in4_label"Input" > +temp1_input IC die temperature > +temp1_label "Die" > +curr[1-4]_input Current on ports [1-4] > +in[1-4]_label"Port[1-4]" > +in[0-3]_enable Enable/disable ports [1-4] > +=== > = > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig > index 1ecf697d8d99..e2a3aeed0628 100644 > --- a/drivers/hwmon/Kconfig > +++ b/drivers/hwmon/Kconfig > @@ -1136,6 +1136,17 @@ config SENSORS_TC654 > This driver can also be built as a module. If so, the module > will be called tc654. > > +config SENSORS_TPS23861 > + tristate "Texas Instruments TPS23861 PoE PSE" > + depends on I2C > + select REGMAP_I2C > + help > + If you say yes here you get support for Texas Instruments > + TPS23861 802.3at PoE PSE chips. > + > + This driver can also be built as a module. If so, the module > + will be called tps23861. > + > config SENSORS_MENF21BMC_HWMON > tristate "MEN 14F021P00 BMC Hardware Monitoring" > depends on MFD_MENF21BMC > diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile > index 09a86c5e1d29..583ca5dbd838 100644 > --- a/drivers/hwmon/Makefile > +++ b/drivers/hwmon/Makefile > @@ -144,6 +144,7 @@ obj-$(CONFIG_SENSORS_MAX31790)+= max31790.o > obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o > obj-$(CONFIG_SENSORS_MCP3021)+= mcp3021.o > obj-$(CONFIG_SENSORS_TC654) += tc654.o > +obj-$(CONFIG_SENSORS_TPS23861) += tps23861.o > obj-$(CONFIG_SENSORS_MLXREG_FAN) += mlxreg-fan.o > obj-$(CONFIG_SENSORS_MENF21BMC_HWMON) += menf21bmc_hwmon.o > obj-$(CONFIG_SENSORS_MR75203)+= mr75203.o > diff --git a/drivers/hwmon/tps23861.c b/drivers/hwmon/tps23861.c > new file mode 100644 > index ..c2484f15298b > --- /dev/null > +++ b/drivers/hwmon/tps23861.c > @@ -0,0 +1,601 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Copyright (c) 2020 Sartura Ltd. > + * > + * Driver for the TI TPS23861 PoE PSE. > + * > + * Author: Robert Marko > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include
Re: [PATCH v5 1/3] dt-bindings: hwmon: Add TI TPS23861 bindings
On Thu, Jan 21, 2021 at 02:44:32PM +0100, Robert Marko wrote:
> Document bindings for the Texas Instruments TPS23861 driver.
>
> Signed-off-by: Robert Marko
> Cc: Luka Perkov
> Reviewed-by: Rob Herring
Applied.
Thanks,
Guenter
> ---
> Changes in v5:
> * Drop uint32 reference
>
> Changes in v4:
> * Correct shunt binding
>
> .../bindings/hwmon/ti,tps23861.yaml | 51 +++
> 1 file changed, 51 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml
>
> diff --git a/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml
> b/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml
> new file mode 100644
> index ..3bc8e73dfbf0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/ti,tps23861.yaml
> @@ -0,0 +1,51 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +
> +$id: http://devicetree.org/schemas/hwmon/ti,tps23861.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: TI TPS23861 PoE PSE
> +
> +maintainers:
> + - Robert Marko
> +
> +description: |
> + The TPS23861 is a IEEE 802.3at Quad Port Power-over-Ethernet PSE
> Controller.
> +
> + Datasheets:
> + https://www.ti.com/lit/gpn/tps23861
> +
> +
> +properties:
> + compatible:
> +enum:
> + - ti,tps23861
> +
> + reg:
> +maxItems: 1
> +
> + shunt-resistor-micro-ohms:
> +description: The value of curent sense resistor in microohms.
> +default: 255000
> +minimum: 25
> +maximum: 255000
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + tps23861@30 {
> + compatible = "ti,tps23861";
> + reg = <0x30>;
> + shunt-resistor-micro-ohms = <255000>;
> + };
> +};
linux-next: manual merge of the spi tree with the powerpc tree
Hi all,
Today's linux-next merge of the spi tree got a conflict in:
drivers/spi/spi-mpc52xx.c
between commit:
e10656114d32 ("spi: mpc52xx: Avoid using get_tbl()")
from the powerpc tree and commit:
258ea99fe25a ("spi: spi-mpc52xx: Use new structure for SPI transfer delays")
from the spi tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
BTW Mark: the author's address in 258ea99fe25a uses a non existent domain :-(
--
Cheers,
Stephen Rothwell
diff --cc drivers/spi/spi-mpc52xx.c
index e6a30f232370,36f941500676..
--- a/drivers/spi/spi-mpc52xx.c
+++ b/drivers/spi/spi-mpc52xx.c
@@@ -247,8 -247,10 +247,10 @@@ static int mpc52xx_spi_fsmstate_transfe
/* Is the transfer complete? */
ms->len--;
if (ms->len == 0) {
- ms->timestamp = get_tbl();
+ ms->timestamp = mftb();
- ms->timestamp += ms->transfer->delay_usecs * tb_ticks_per_usec;
+ if (ms->transfer->delay.unit == SPI_DELAY_UNIT_USECS)
+ ms->timestamp += ms->transfer->delay.value *
+tb_ticks_per_usec;
ms->state = mpc52xx_spi_fsmstate_wait;
return FSM_CONTINUE;
}
pgpdwZmbI6ghe.pgp
Description: OpenPGP digital signature
Re: [PATCH v1 2/9] cpufreq: sfi-cpufreq: Remove driver for deprecated firmware
On 11-02-21, 15:40, Andy Shevchenko wrote: > SFI-based platforms are gone. So does this driver. > > Signed-off-by: Andy Shevchenko > Acked-by: Linus Walleij > --- > drivers/cpufreq/Kconfig.x86 | 10 --- > drivers/cpufreq/Makefile | 1 - > drivers/cpufreq/sfi-cpufreq.c | 127 -- > 3 files changed, 138 deletions(-) > delete mode 100644 drivers/cpufreq/sfi-cpufreq.c Acked-by: Viresh Kumar -- viresh
Re: [PATCH 5.4 00/24] 5.4.98-rc1 review
On Thu, 11 Feb 2021 at 20:36, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 5.4.98 release.
> There are 24 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 13 Feb 2021 15:01:39 +.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
>
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.98-rc1.gz
> or in the git tree and branch at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
The following lockdep warning was found during the arm64 db410c boot.
And this is easily reproducible.
This was noticed on Linux next and reported on linux arm msm mailing list.
https://lore.kernel.org/linux-arm-msm/CA+G9fYunK_2h3-pHtZT_+56Xf8b=m-8q9gntscj3kxvajul...@mail.gmail.com/
> David Collins
> regulator: core: avoid regulator_resolve_supply() race condition
[3.982889] WARNING: possible recursive locking detected
[3.988186] 5.4.98-rc1 #1 Not tainted
[3.993477]
[3.997041] kworker/1:1/31 is trying to acquire lock:
[4.002421] 0eb36940 (regulator_ww_class_mutex){+.+.}, at:
create_regulator+0x23c/0x360
[4.007372]
[4.007372] but task is already holding lock:
[4.011044] mmc1: SDHCI controller on 7864900.sdhci [7864900.sdhci]
using ADMA 64-bit
[4.015874] 3a9d8940 (regulator_ww_class_mutex){+.+.}, at:
regulator_resolve_supply+0xbc/0x330
[4.015887]
[4.015887] other info that might help us debug this:
[4.015890] Possible unsafe locking scenario:
[4.015890]
[4.015893]CPU0
[4.015895]
[4.015897] lock(regulator_ww_class_mutex);
[4.015903] lock(regulator_ww_class_mutex);
[4.026541] ci_hdrc ci_hdrc.0: EHCI Host Controller
[4.029681]
[4.029681] *** DEADLOCK ***
[4.029681]
[4.029684] May be due to missing lock nesting notation
[4.029684]
[4.029688] 5 locks held by kworker/1:1/31:
[4.029691] #0: 0eb24928 ((wq_completion)events){+.+.},
at: process_one_work+0x1fc/0x758
[4.029709] #1: 800013203de8
((work_completion)(>state_work)){+.+.}, at:
process_one_work+0x1fc/0x758
[4.039092] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
[4.045388] #2: 3a91c160 (>mutex){}, at:
__device_attach+0x4c/0x178
[4.045402] #3: 3a91d170 (>mutex){}, at:
__device_attach+0x4c/0x178
[4.045416] #4: 3a9d8940 (regulator_ww_class_mutex){+.+.},
at: regulator_resolve_supply+0xbc/0x330
[4.066243] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
[4.069606]
[4.069606] stack backtrace:
[4.069614] CPU: 1 PID: 31 Comm: kworker/1:1 Not tainted 5.4.98-rc1 #1
[4.077634] hub 1-0:1.0: USB hub found
[4.082453] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
[4.082464] Workqueue: events qcom_channel_state_worker
[4.082469] Call trace:
[4.082476] dump_backtrace+0x0/0x188
[4.082481] show_stack+0x24/0x30
[4.082488] dump_stack+0xe8/0x168
[4.082494] __lock_acquire+0xd80/0x1458
[4.082501] lock_acquire+0xe8/0x270
[4.086663] hub 1-0:1.0: 1 port detected
[4.095487] __ww_mutex_lock.constprop.15+0xbc/0xf60
[4.095494] ww_mutex_lock+0x98/0x3a0
[4.095500] create_regulator+0x23c/0x360
[4.095505] regulator_resolve_supply+0x1ac/0x330
[4.095512] regulator_register_resolve_supply+0x24/0x80
[4.123419] mmc0: new HS200 MMC card at address 0001
[4.128297] class_for_each_device+0x78/0xf8
[4.128303] regulator_register+0x8c4/0xb40
[4.128310] devm_regulator_register+0x50/0xa8
[4.128317] rpm_reg_probe+0x108/0x1c0
[4.128325] platform_drv_probe+0x58/0xa8
[4.139377] mmcblk0: mmc0:0001 DS1008 7.28 GiB
[4.143393] really_probe+0x290/0x498
[4.143398] driver_probe_device+0x12c/0x148
[4.143404] __device_attach_driver+0xa4/0x120
[4.143411] bus_for_each_drv+0x78/0xd8
[4.143416] __device_attach+0xf0/0x178
[4.143421] device_initial_probe+0x24/0x30
[4.143429] bus_probe_device+0xa0/0xa8
[4.148410] mmcblk0boot0: mmc0:0001 DS1008 partition 1 4.00 MiB
[4.154157] device_add+0x3fc/0x660
[4.154163] of_device_add+0x50/0x68
[4.154170] of_platform_device_create_pdata+0xf0/0x170
[4.154175] of_platform_bus_create+0x174/0x550
[4.154181] of_platform_populate+0x8c/0x148
[4.154189] qcom_smd_rpm_probe+0x88/0xa0
[4.158693] mmcblk0boot1: mmc0:0001 DS1008 partition 2 4.00 MiB
[4.164749] rpmsg_dev_probe+0x124/0x1b0
[4.164755] really_probe+0x290/0x498
[4.164760] driver_probe_device+0x12c/0x148
[4.164766] __device_attach_driver+0xa4/0x120
[4.164772] bus_for_each_drv+0x78/0xd8
[
Re: [PATCH] ext4: add .kunitconfig fragment to enable ext4-specific tests
On Tue, Feb 09, 2021 at 05:32:06PM -0800, Daniel Latypov wrote: > As of [1], we no longer want EXT4_KUNIT_TESTS and others to `select` > their deps. This means it can get harder to get all the right things > selected as we gain more tests w/ more deps over time. > > This patch (and [2]) proposes we store kunitconfig fragments in-tree to > represent sets of tests. (N.B. right now we only have one ext4 test). > > There's still a discussion to be had about how to have a hierarchy of > these files (e.g. if one wanted to test all of fs/, not just fs/ext4). > > But this fragment would likely be a leaf node and isn't blocked on > deciding if we want `import` statements and the like. > > Usage > = > > Before [2] (on its way to being merged): > $ cp fs/ext4/.kunitconfig .kunit/ > $ ./tools/testing/kunit.py run > > After [2]: > $ ./tools/testing/kunit.py run --kunitconfig=fs/ext4/.kunitconfig Thanks, applied, with one minor fixup. The path to kunit.py is ./tools/testing/kunit/kunit.py - Ted
Re: [PATCH v6 6/7] dt-bindings: connector: Add SVDM VDO properties
On Fri, Feb 05, 2021 at 11:34:14AM +0800, Kyle Tso wrote: > Add bindings of VDO properties of USB PD SVDM so that they can be > used in device tree. > > Signed-off-by: Kyle Tso Reviewed-by: Guenter Roeck Would it be possible to unify the dt definitions with the definitions in include/linux/usb/pd_vdo.h ? I don't really like the duplication. Thanks, Guenter > --- > Changes since v5: > - no change > > .../bindings/connector/usb-connector.yaml | 11 + > include/dt-bindings/usb/pd.h | 311 +- > 2 files changed, 321 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml > b/Documentation/devicetree/bindings/connector/usb-connector.yaml > index 4286ed767a0a..d385026944ec 100644 > --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml > +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml > @@ -137,6 +137,17 @@ properties: > maxItems: 7 > $ref: /schemas/types.yaml#/definitions/uint32-array > > + sink-vdos: > +description: An array of u32 with each entry (VDM Objects) providing > additional information > + corresponding to the product, the detailed bit definitions and the > order of each VDO can be > + found in "USB Power Delivery Specification Revision 3.0, Version 2.0 + > ECNs 2020-12-10" > + chapter 6.4.4.3.1 Discover Identity. User can specify the VDO array via > + VDO_IDH/_CERT/_PRODUCT/_UFP/_DFP/_PCABLE/_ACABLE(1/2)/_VPD() defined in > + dt-bindings/usb/pd.h. > +minItems: 3 > +maxItems: 6 > +$ref: /schemas/types.yaml#/definitions/uint32-array > + >op-sink-microwatt: > description: Sink required operating power in microwatt, if source can't >offer the power, Capability Mismatch is set. Required for power sink > and > diff --git a/include/dt-bindings/usb/pd.h b/include/dt-bindings/usb/pd.h > index 0352893697f0..fef3ef65967f 100644 > --- a/include/dt-bindings/usb/pd.h > +++ b/include/dt-bindings/usb/pd.h > @@ -93,4 +93,313 @@ > #define FRS_DEFAULT_POWER 1 > #define FRS_5V_1P5A2 > #define FRS_5V_3A 3 > - #endif /* __DT_POWER_DELIVERY_H */ > + > +/* > + * SVDM Identity Header > + * > + * <31> :: data capable as a USB host > + * <30> :: data capable as a USB device > + * <29:27> :: product type (UFP / Cable / VPD) > + * <26> :: modal operation supported (1b == yes) > + * <25:23> :: product type (DFP) (SVDM version 2.0+ only; set to zero in > version 1.0) > + * <22:21> :: connector type (SVDM version 2.0+ only; set to zero in > version 1.0) > + * <20:16> :: Reserved, Shall be set to zero > + * <15:0> :: USB-IF assigned VID for this cable vendor > + */ > +/* SOP Product Type (UFP) */ > +#define IDH_PTYPE_NOT_UFP 0 > +#define IDH_PTYPE_HUB 1 > +#define IDH_PTYPE_PERIPH2 > +#define IDH_PTYPE_PSD 3 > +#define IDH_PTYPE_AMA 5 > + > +/* SOP' Product Type (Cable Plug / VPD) */ > +#define IDH_PTYPE_NOT_CABLE 0 > +#define IDH_PTYPE_PCABLE3 > +#define IDH_PTYPE_ACABLE4 > +#define IDH_PTYPE_VPD 6 > + > +/* SOP Product Type (DFP) */ > +#define IDH_PTYPE_NOT_DFP 0 > +#define IDH_PTYPE_DFP_HUB 1 > +#define IDH_PTYPE_DFP_HOST 2 > +#define IDH_PTYPE_DFP_PB3 > + > +#define VDO_IDH(usbh, usbd, ufp_cable, is_modal, dfp, conn, vid) >\ > + ((usbh) << 31 | (usbd) << 30 | ((ufp_cable) & 0x7) << 27 > \ > + | (is_modal) << 26 | ((dfp) & 0x7) << 23 | ((conn) & 0x3) << 21 > \ > + | ((vid) & 0x)) > + > +/* > + * Cert Stat VDO > + * - > + * <31:0> : USB-IF assigned XID for this cable > + */ > +#define VDO_CERT(xid)((xid) & 0x) > + > +/* > + * Product VDO > + * --- > + * <31:16> : USB Product ID > + * <15:0> : USB bcdDevice > + */ > +#define VDO_PRODUCT(pid, bcd) (((pid) & 0x) << 16 | ((bcd) & 0x)) > + > +/* > + * UFP VDO (PD Revision 3.0+ only) > + * > + * <31:29> :: UFP VDO version > + * <28>:: Reserved > + * <27:24> :: Device capability > + * <23:22> :: Connector type (10b == receptacle, 11b == captive plug) > + * <21:11> :: Reserved > + * <10:8> :: Vconn power (AMA only) > + * <7> :: Vconn required (AMA only, 0b == no, 1b == yes) > + * <6> :: Vbus required (AMA only, 0b == yes, 1b == no) > + * <5:3> :: Alternate modes > + * <2:0> :: USB highest speed > + */ > +/* UFP VDO Version */ > +#define UFP_VDO_VER1_2 2 > + > +/* Device Capability */ > +#define DEV_USB2_CAPABLE BIT(0) > +#define DEV_USB2_BILLBOARD BIT(1) > +#define DEV_USB3_CAPABLE BIT(2) > +#define DEV_USB4_CAPABLE BIT(3) > + > +/* Connector Type */ > +#define UFP_RECEPTACLE 2 > +#define UFP_CAPTIVE 3 > + > +/* Vconn Power (AMA only, set to AMA_VCONN_NOT_REQ if Vconn is not required) > */ > +#define AMA_VCONN_PWR_1W
Re: [PATCH v6 7/7] usb: typec: tcpm: Get Sink VDO from fwnode
On Fri, Feb 05, 2021 at 11:34:15AM +0800, Kyle Tso wrote:
> Commit a079973f462a ("usb: typec: tcpm: Remove tcpc_config
> configuration mechanism") removed the tcpc_config which includes the
> Sink VDO and it is not yet added back with fwnode. Add it now.
>
> Signed-off-by: Kyle Tso
Reviewed-by: Guenter Roeck
> ---
> Changes since v5:
> - no change
>
> drivers/usb/typec/tcpm/tcpm.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index b45cd191a8a4..be0b6469dd3d 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -5722,6 +5722,20 @@ static int tcpm_fw_get_caps(struct tcpm_port *port,
> port->new_source_frs_current = frs_current;
> }
>
> + /* sink-vdos is optional */
> + ret = fwnode_property_count_u32(fwnode, "sink-vdos");
> + if (ret < 0)
> + ret = 0;
> +
> + port->nr_snk_vdo = min(ret, VDO_MAX_OBJECTS);
> + if (port->nr_snk_vdo) {
> + ret = fwnode_property_read_u32_array(fwnode, "sink-vdos",
> + port->snk_vdo,
> + port->nr_snk_vdo);
> + if (ret < 0)
> + return ret;
> + }
> +
> return 0;
> }
>
> --
> 2.30.0.365.g02bc693789-goog
>
Re: [PATCH v6 5/7] usb: typec: displayport: Fill the negotiated SVDM Version in the header
On Fri, Feb 05, 2021 at 11:34:13AM +0800, Kyle Tso wrote:
> VDM header now requires SVDM Version. Get it from typec_partner.
>
> Signed-off-by: Kyle Tso
Reviewed-by: Guenter Roeck
> ---
> Changes since v5:
> - follow the changes of "usb: typec: Manage SVDM version"
>
> drivers/usb/typec/altmodes/displayport.c | 17 +
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/typec/altmodes/displayport.c
> b/drivers/usb/typec/altmodes/displayport.c
> index 0abc3121238f..b7f094435b00 100644
> --- a/drivers/usb/typec/altmodes/displayport.c
> +++ b/drivers/usb/typec/altmodes/displayport.c
> @@ -15,8 +15,8 @@
> #include
> #include "displayport.h"
>
> -#define DP_HEADER(_dp, cmd) (VDO((_dp)->alt->svid, 1, SVDM_VER_1_0,
> cmd) | \
> - VDO_OPOS(USB_TYPEC_DP_MODE))
> +#define DP_HEADER(_dp, ver, cmd) (VDO((_dp)->alt->svid, 1, ver, cmd)
> \
> + | VDO_OPOS(USB_TYPEC_DP_MODE))
>
> enum {
> DP_CONF_USB,
> @@ -156,9 +156,14 @@ static int dp_altmode_configured(struct dp_altmode *dp)
>
> static int dp_altmode_configure_vdm(struct dp_altmode *dp, u32 conf)
> {
> - u32 header = DP_HEADER(dp, DP_CMD_CONFIGURE);
> + int svdm_version = typec_altmode_get_svdm_version(dp->alt);
> + u32 header;
> int ret;
>
> + if (svdm_version < 0)
> + return svdm_version;
> +
> + header = DP_HEADER(dp, svdm_version, DP_CMD_CONFIGURE);
> ret = typec_altmode_notify(dp->alt, TYPEC_STATE_SAFE, >data);
> if (ret) {
> dev_err(>alt->dev,
> @@ -181,6 +186,7 @@ static int dp_altmode_configure_vdm(struct dp_altmode
> *dp, u32 conf)
> static void dp_altmode_work(struct work_struct *work)
> {
> struct dp_altmode *dp = container_of(work, struct dp_altmode, work);
> + int svdm_version;
> u32 header;
> u32 vdo;
> int ret;
> @@ -194,7 +200,10 @@ static void dp_altmode_work(struct work_struct *work)
> dev_err(>alt->dev, "failed to enter mode\n");
> break;
> case DP_STATE_UPDATE:
> - header = DP_HEADER(dp, DP_CMD_STATUS_UPDATE);
> + svdm_version = typec_altmode_get_svdm_version(dp->alt);
> + if (svdm_version < 0)
> + break;
> + header = DP_HEADER(dp, svdm_version, DP_CMD_STATUS_UPDATE);
> vdo = 1;
> ret = typec_altmode_vdm(dp->alt, header, , 2);
> if (ret)
> --
> 2.30.0.365.g02bc693789-goog
>
Re: [PATCH v6 4/7] usb: typec: ucsi: Determine common SVDM Version
On Fri, Feb 05, 2021 at 11:34:12AM +0800, Kyle Tso wrote:
> This patch implements the following requirement in the Spec.
>
> PD Spec Revision 3.0 Version 2.0 + ECNs 2020-12-10
> 6.4.4.2.3 Structured VDM Version
> "The Structured VDM Version field of the Discover Identity Command
> sent and received during VDM discovery Shall be used to determine the
> lowest common Structured VDM Version supported by the Port Partners or
> Cable Plug and Shall continue to operate using this Specification
> Revision until they are Detached."
>
> Signed-off-by: Kyle Tso
Reviewed-by: Guenter Roeck
> ---
> Changes since v5:
> - follow the changes of "usb: typec: Manage SVDM version"
> - remove the "reset to default". Now the default SVDM version will be
> set when calling to typec_register_partner
>
> drivers/usb/typec/ucsi/displayport.c | 32 +---
> drivers/usb/typec/ucsi/ucsi.c| 1 +
> 2 files changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/typec/ucsi/displayport.c
> b/drivers/usb/typec/ucsi/displayport.c
> index 1d387bddefb9..73cd5bf35047 100644
> --- a/drivers/usb/typec/ucsi/displayport.c
> +++ b/drivers/usb/typec/ucsi/displayport.c
> @@ -49,6 +49,7 @@ static int ucsi_displayport_enter(struct typec_altmode
> *alt, u32 *vdo)
> {
> struct ucsi_dp *dp = typec_altmode_get_drvdata(alt);
> struct ucsi *ucsi = dp->con->ucsi;
> + int svdm_version;
> u64 command;
> u8 cur = 0;
> int ret;
> @@ -83,7 +84,13 @@ static int ucsi_displayport_enter(struct typec_altmode
> *alt, u32 *vdo)
>* mode, and letting the alt mode driver continue.
>*/
>
> - dp->header = VDO(USB_TYPEC_DP_SID, 1, SVDM_VER_1_0, CMD_ENTER_MODE);
> + svdm_version = typec_altmode_get_svdm_version(alt);
> + if (svdm_version < 0) {
> + ret = svdm_version;
> + goto err_unlock;
> + }
> +
> + dp->header = VDO(USB_TYPEC_DP_SID, 1, svdm_version, CMD_ENTER_MODE);
> dp->header |= VDO_OPOS(USB_TYPEC_DP_MODE);
> dp->header |= VDO_CMDT(CMDT_RSP_ACK);
>
> @@ -101,6 +108,7 @@ static int ucsi_displayport_enter(struct typec_altmode
> *alt, u32 *vdo)
> static int ucsi_displayport_exit(struct typec_altmode *alt)
> {
> struct ucsi_dp *dp = typec_altmode_get_drvdata(alt);
> + int svdm_version;
> u64 command;
> int ret = 0;
>
> @@ -120,7 +128,13 @@ static int ucsi_displayport_exit(struct typec_altmode
> *alt)
> if (ret < 0)
> goto out_unlock;
>
> - dp->header = VDO(USB_TYPEC_DP_SID, 1, SVDM_VER_1_0, CMD_EXIT_MODE);
> + svdm_version = typec_altmode_get_svdm_version(alt);
> + if (svdm_version < 0) {
> + ret = svdm_version;
> + goto out_unlock;
> + }
> +
> + dp->header = VDO(USB_TYPEC_DP_SID, 1, svdm_version, CMD_EXIT_MODE);
> dp->header |= VDO_OPOS(USB_TYPEC_DP_MODE);
> dp->header |= VDO_CMDT(CMDT_RSP_ACK);
>
> @@ -186,6 +200,7 @@ static int ucsi_displayport_vdm(struct typec_altmode *alt,
> struct ucsi_dp *dp = typec_altmode_get_drvdata(alt);
> int cmd_type = PD_VDO_CMDT(header);
> int cmd = PD_VDO_CMD(header);
> + int svdm_version;
>
> mutex_lock(>con->lock);
>
> @@ -198,9 +213,20 @@ static int ucsi_displayport_vdm(struct typec_altmode
> *alt,
> return -EOPNOTSUPP;
> }
>
> + svdm_version = typec_altmode_get_svdm_version(alt);
> + if (svdm_version < 0) {
> + mutex_unlock(>con->lock);
> + return svdm_version;
> + }
> +
> switch (cmd_type) {
> case CMDT_INIT:
> - dp->header = VDO(USB_TYPEC_DP_SID, 1, SVDM_VER_1_0, cmd);
> + if (PD_VDO_SVDM_VER(header) < svdm_version) {
> + typec_partner_set_svdm_version(dp->con->partner,
> PD_VDO_SVDM_VER(header));
> + svdm_version = PD_VDO_SVDM_VER(header);
> + }
> +
> + dp->header = VDO(USB_TYPEC_DP_SID, 1, svdm_version, cmd);
> dp->header |= VDO_OPOS(USB_TYPEC_DP_MODE);
>
> switch (cmd) {
> diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
> index ca3f4194ad90..244270755ae6 100644
> --- a/drivers/usb/typec/ucsi/ucsi.c
> +++ b/drivers/usb/typec/ucsi/ucsi.c
> @@ -1052,6 +1052,7 @@ static int ucsi_register_port(struct ucsi *ucsi, int
> index)
>
> cap->revision = ucsi->cap.typec_version;
> cap->pd_revision = ucsi->cap.pd_version;
> + cap->svdm_version = SVDM_VER_2_0;
> cap->prefer_role = TYPEC_NO_PREFERRED_ROLE;
>
> if (con->cap.op_mode & UCSI_CONCAP_OPMODE_AUDIO_ACCESSORY)
> --
> 2.30.0.365.g02bc693789-goog
>
