* Re: [PATCH RESEND 00/14] Next round of associating ddc adapters with connectors
From: Andrzej Pietrasiewicz @ 2019-09-18 14:01 UTC (permalink / raw)
To: dri-devel
Cc: Neil Armstrong, David Airlie, Matthias Brugger, Thierry Reding,
Laurent Pinchart, kernel, Anthony Koo, Emil Velikov,
linux-samsung-soc, Tomi Valkeinen, David Francis,
Krzysztof Kozlowski, Jonathan Hunter, linux-rockchip, Kukjin Kim,
Jonas Karlman, Leo Li, linux-arm-msm, intel-gfx, Jyri Sarha,
Mamta Shukla, linux-mediatek, Rodrigo Vivi, linux-tegra,
Thomas Gleixner, Bhawanpreet Lakha, linux-arm-kernel, Sean Paul,
Jernej Skrabec, amd-gfx, Shawn Guo, Seung-Woo Kim, linux-kernel,
Christian König, Todor Tomov, Kyungmin Park, Alex Deucher,
freedreno, Nicholas Kazlauskas
In-Reply-To: <cover.1566845537.git.andrzej.p@collabora.com>
Hi All,
A gentle ping.
Andrzej
W dniu 26.08.2019 o 21:25, Andrzej Pietrasiewicz pisze:
> I'm resending the patches which have somehow got lost: one patch
> from Geert and 13 patches from me.
>
> Geert's patch updates the error message to reflect the actually
> called function's name.
>
> Most of patches from me have their Acked-by and Reviewed-by tags
> and deal with providing a ddc symlink in connector's sysfs directory.
>
> Rebased onto drm-misc-next as of 26th August.
>
> Andrzej Pietrasiewicz (13):
> drm/radeon: Provide ddc symlink in connector sysfs directory
> drm/amdgpu: Provide ddc symlink in dm connector's sysfs directory
> drm/exynos: Provide ddc symlink in connector's sysfs
> drm: rockchip: Provide ddc symlink in rk3066_hdmi sysfs directory
> drm: rockchip: Provide ddc symlink in inno_hdmi sysfs directory
> drm/msm/hdmi: Provide ddc symlink in hdmi connector sysfs directory
> drm/mediatek: Provide ddc symlink in hdmi connector sysfs directory
> drm/tegra: Provide ddc symlink in output connector sysfs directory
> drm/vc4: Provide ddc symlink in connector sysfs directory
> drm: zte: Provide ddc symlink in hdmi connector sysfs directory
> drm: zte: Provide ddc symlink in vga connector sysfs directory
> drm/tilcdc: Provide ddc symlink in connector sysfs directory
> drm/i915: Provide ddc symlink in hdmi connector sysfs directory
>
> Geert Uytterhoeven (1):
> drm/bridge: ti-tfp410: Update drm_connector_init_with_ddc() error
> message
>
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +-
> drivers/gpu/drm/bridge/ti-tfp410.c | 3 +-
> drivers/gpu/drm/exynos/exynos_hdmi.c | 6 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c | 12 +-
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 7 +-
> drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 6 +-
> drivers/gpu/drm/radeon/radeon_connectors.c | 143 +++++++++++++-----
> drivers/gpu/drm/rockchip/inno_hdmi.c | 6 +-
> drivers/gpu/drm/rockchip/rk3066_hdmi.c | 7 +-
> drivers/gpu/drm/tegra/hdmi.c | 7 +-
> drivers/gpu/drm/tegra/sor.c | 7 +-
> drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 6 +-
> drivers/gpu/drm/vc4/vc4_hdmi.c | 12 +-
> drivers/gpu/drm/zte/zx_hdmi.c | 6 +-
> drivers/gpu/drm/zte/zx_vga.c | 6 +-
> 15 files changed, 168 insertions(+), 71 deletions(-)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] pwm: atmel: Remove platform_device_id and use only dt bindings
From: Kamel Bouhara @ 2019-09-18 14:05 UTC (permalink / raw)
To: Claudiu Beznea, Thierry Reding, linux-pwm, linux-kernel
Cc: Kamel Bouhara, Alexandre Belloni, Gregory Clement,
Ludovic Desroches, linux-arm-kernel
Since commit 26202873bb51 ("avr32: remove support for AVR32
architecture") there is no more user of platform_device_id and we
should only use dt bindings
Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
---
drivers/pwm/Kconfig | 2 +-
drivers/pwm/pwm-atmel.c | 29 +++--------------------------
2 files changed, 4 insertions(+), 27 deletions(-)
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index a7e57516959e..b51fb1a33aa2 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -44,7 +44,7 @@ config PWM_AB8500
config PWM_ATMEL
tristate "Atmel PWM support"
- depends on ARCH_AT91
+ depends on ARCH_AT91 && OF
help
Generic PWM framework driver for Atmel SoC.
diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index e5e1eaf372fa..a3d93d634462 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -318,19 +318,6 @@ static const struct atmel_pwm_data mchp_sam9x60_pwm_data = {
},
};
-static const struct platform_device_id atmel_pwm_devtypes[] = {
- {
- .name = "at91sam9rl-pwm",
- .driver_data = (kernel_ulong_t)&atmel_sam9rl_pwm_data,
- }, {
- .name = "sama5d3-pwm",
- .driver_data = (kernel_ulong_t)&atmel_sama5_pwm_data,
- }, {
- /* sentinel */
- },
-};
-MODULE_DEVICE_TABLE(platform, atmel_pwm_devtypes);
-
static const struct of_device_id atmel_pwm_dt_ids[] = {
{
.compatible = "atmel,at91sam9rl-pwm",
@@ -353,14 +340,7 @@ MODULE_DEVICE_TABLE(of, atmel_pwm_dt_ids);
static inline const struct atmel_pwm_data *
atmel_pwm_get_driver_data(struct platform_device *pdev)
{
- const struct platform_device_id *id;
-
- if (pdev->dev.of_node)
- return of_device_get_match_data(&pdev->dev);
-
- id = platform_get_device_id(pdev);
-
- return (struct atmel_pwm_data *)id->driver_data;
+ return of_device_get_match_data(&pdev->dev);
}
static int atmel_pwm_probe(struct platform_device *pdev)
@@ -396,10 +376,8 @@ static int atmel_pwm_probe(struct platform_device *pdev)
atmel_pwm->chip.dev = &pdev->dev;
atmel_pwm->chip.ops = &atmel_pwm_ops;
- if (pdev->dev.of_node) {
- atmel_pwm->chip.of_xlate = of_pwm_xlate_with_flags;
- atmel_pwm->chip.of_pwm_n_cells = 3;
- }
+ atmel_pwm->chip.of_xlate = of_pwm_xlate_with_flags;
+ atmel_pwm->chip.of_pwm_n_cells = 3;
atmel_pwm->chip.base = -1;
atmel_pwm->chip.npwm = 4;
@@ -437,7 +415,6 @@ static struct platform_driver atmel_pwm_driver = {
.name = "atmel-pwm",
.of_match_table = of_match_ptr(atmel_pwm_dt_ids),
},
- .id_table = atmel_pwm_devtypes,
.probe = atmel_pwm_probe,
.remove = atmel_pwm_remove,
};
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] mfd: mt6360: add pmic mt6360 driver
From: kbuild test robot @ 2019-09-18 14:10 UTC (permalink / raw)
To: Gene Chen
Cc: gene_chen, Wilma.Wu, linux-kernel, linux-mediatek, kbuild-all,
matthias.bgg, Gene Chen, lee.jones, linux-arm-kernel
In-Reply-To: <1568800548-4035-1-git-send-email-gene.chen.richtek@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1447 bytes --]
Hi Gene,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190917]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Gene-Chen/mfd-mt6360-add-pmic-mt6360-driver/20190918-181041
config: s390-allmodconfig (attached as .config)
compiler: s390-linux-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=s390
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> drivers/mfd/mt6360-core.c:15:10: fatal error: linux/mfd/mt6360.h: No such file or directory
#include <linux/mfd/mt6360.h>
^~~~~~~~~~~~~~~~~~~~
compilation terminated.
vim +15 drivers/mfd/mt6360-core.c
14
> 15 #include <linux/mfd/mt6360.h>
16 #include <linux/mfd/mt6360-private.h>
17
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 56010 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v1 1/1] Add support for arm64 to carry ima measurement log in kexec_file_load
From: Mimi Zohar @ 2019-09-18 14:15 UTC (permalink / raw)
To: Prakhar Srivastava, linux-kernel, linux-arm-kernel,
linux-integrity, kexec
Cc: mark.rutland, jean-philippe, arnd, takahiro.akashi, sboyd,
catalin.marinas, yamada.masahiro, kristina.martsenko, duwe,
bauerman, james.morse, tglx, allison
In-Reply-To: <20190913225009.3406-2-prsriva@linux.microsoft.com>
Hi Prahkar,
On Fri, 2019-09-13 at 15:50 -0700, Prakhar Srivastava wrote:
> During kexec_file_load, carrying forward the ima measurement log allows
> a verifying party to get the entire runtime event log since the last
> full reboot since that is when PCRs were last reset.
>
> Signed-off-by: Prakhar Srivastava <prsriva@linux.microsoft.com>
Missing is the Changelog between versions. (v1 has now been posted 3
times.)
There's a number of trailing whitespaces, blanks before tabs, and
other warnings. Please use scripts/checkpatch.pl before posting
patches.
> ---
> arch/arm64/Kconfig | 7 +
> arch/arm64/include/asm/ima.h | 29 ++++
> arch/arm64/include/asm/kexec.h | 5 +
> arch/arm64/kernel/Makefile | 3 +-
> arch/arm64/kernel/ima_kexec.c | 213 +++++++++++++++++++++++++
> arch/arm64/kernel/machine_kexec_file.c | 6 +
> 6 files changed, 262 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm64/include/asm/ima.h
> create mode 100644 arch/arm64/kernel/ima_kexec.c
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 3adcec05b1f6..f39b12dbf9e8 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -976,6 +976,13 @@ config KEXEC_VERIFY_SIG
> verification for the corresponding kernel image type being
> loaded in order for this to work.
>
> +config HAVE_IMA_KEXEC
> + bool "Carry over IMA measurement log during kexec_file_load() syscall"
> + depends on KEXEC_FILE
> + help
> + Select this option to carry over IMA measurement log during
> + kexec_file_load.
> +
> config KEXEC_IMAGE_VERIFY_SIG
> bool "Enable Image signature verification support"
> default y
> diff --git a/arch/arm64/include/asm/ima.h b/arch/arm64/include/asm/ima.h
> new file mode 100644
> index 000000000000..e23cee84729f
> --- /dev/null
> +++ b/arch/arm64/include/asm/ima.h
> @@ -0,0 +1,29 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_ARM64_IMA_H
> +#define _ASM_ARM64_IMA_H
> +
> +struct kimage;
> +
> +int ima_get_kexec_buffer(void **addr, size_t *size);
> +int ima_free_kexec_buffer(void);
> +
> +#ifdef CONFIG_IMA
> +void remove_ima_buffer(void *fdt, int chosen_node);
> +#else
> +static inline void remove_ima_buffer(void *fdt, int chosen_node) {}
> +#endif
> +
> +#ifdef CONFIG_IMA_KEXEC
> +int arch_ima_add_kexec_buffer(struct kimage *image, unsigned long load_addr,
> + size_t size);
> +
> +int setup_ima_buffer(const struct kimage *image, void *fdt, int chosen_node);
> +#else
> +static inline int setup_ima_buffer(const struct kimage *image, void *fdt,
> + int chosen_node)
> +{
> + remove_ima_buffer(fdt, chosen_node);
> + return 0;
> +}
> +#endif /* CONFIG_IMA_KEXEC */
> +#endif /* _ASM_ARM64_IMA_H */
> diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
> index 12a561a54128..e8d2412066e7 100644
> --- a/arch/arm64/include/asm/kexec.h
> +++ b/arch/arm64/include/asm/kexec.h
> @@ -96,6 +96,11 @@ static inline void crash_post_resume(void) {}
> struct kimage_arch {
> void *dtb;
> unsigned long dtb_mem;
> +
> +#ifdef CONFIG_IMA_KEXEC
> + phys_addr_t ima_buffer_addr;
> + size_t ima_buffer_size;
> +#endif
> };
>
> extern const struct kexec_file_ops kexec_image_ops;
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index 478491f07b4f..580238f2e9a7 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -55,7 +55,8 @@ obj-$(CONFIG_RANDOMIZE_BASE) += kaslr.o
> obj-$(CONFIG_HIBERNATION) += hibernate.o hibernate-asm.o
> obj-$(CONFIG_KEXEC_CORE) += machine_kexec.o relocate_kernel.o \
> cpu-reset.o
> -obj-$(CONFIG_KEXEC_FILE) += machine_kexec_file.o kexec_image.o
> +obj-$(CONFIG_KEXEC_FILE) += machine_kexec_file.o kexec_image.o \
> + ima_kexec.o
The kernel may be built with/without IMA enabled or without IMA_KEXEC
support. Here you're requiring both IMA and IMA_KEXEC to be
configured. Please refer to the powerpc example.
> obj-$(CONFIG_ARM64_RELOC_TEST) += arm64-reloc-test.o
> arm64-reloc-test-y := reloc_test_core.o reloc_test_syms.o
> obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
> diff --git a/arch/arm64/kernel/ima_kexec.c b/arch/arm64/kernel/ima_kexec.c
> new file mode 100644
> index 000000000000..b14326d541f3
> --- /dev/null
> +++ b/arch/arm64/kernel/ima_kexec.c
> @@ -0,0 +1,213 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 Microsoft Corporation.
> + *
> + * Authors:
> + * Prakhar Srivastava <prsriva@linux.microsoft.com>
> + */
> +
> +#include <linux/slab.h>
> +#include <linux/kexec.h>
> +#include <linux/of.h>
> +#include <linux/memblock.h>
> +#include <linux/libfdt.h>
> +
> +
Extraneous blank line.
> +/**
> + * delete_fdt_mem_rsv - delete memory reservation with given address and size
> + * @fdt - pointer to the fdt.
> + * @start - start address of the memory.
> + * @size - number of cells to be deletd.
> + *
> + * Return: 0 on success, or negative errno on error.
> + */
> +int delete_fdt_mem_rsv(void *fdt, unsigned long start, unsigned long size)
> +{
> + int i, ret, num_rsvs = fdt_num_mem_rsv(fdt);
> +
> + for (i = 0; i < num_rsvs; i++) {
> + uint64_t rsv_start, rsv_size;
> +
> + ret = fdt_get_mem_rsv(fdt, i, &rsv_start, &rsv_size);
> + if (ret) {
> + pr_err("Malformed device tree\n");
> + return -EINVAL;
> + }
> +
> + if (rsv_start == start && rsv_size == size) {
> + ret = fdt_del_mem_rsv(fdt, i);
> + if (ret) {
> + pr_err("Error deleting device tree reservation\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> + }
> + }
> +
> + return -ENOENT;
> +}
> +
> +/**
> + * remove_ima_buffer - remove the IMA buffer property and reservation
> + * @fdt - pointer the fdt.
> + * @chosen_node - node under which property can be found.
> + *
> + * The IMA measurement buffer is either read by now and freeed or a kexec call
> + * needs to replace the ima measurement buffer, clear the property and memory
> + * reservation.
> + */
> +void remove_ima_buffer(void *fdt, int chosen_node)
> +{
> + int ret, len;
> + const void *prop;
> + uint64_t tmp_start, tmp_end;
> +
> + prop = fdt_getprop(fdt, chosen_node, "linux,ima-kexec-buffer", &len);
> + if (prop) {
> + tmp_start = fdt64_to_cpu(*((const fdt64_t *) prop));
> +
> + prop = fdt_getprop(fdt, chosen_node,
> + "linux,ima-kexec-buffer-end", &len);
> + if (!prop)
> + return;
> +
> + tmp_end = fdt64_to_cpu(*((const fdt64_t *) prop));
> +
> + ret = delete_fdt_mem_rsv(fdt, tmp_start, tmp_end - tmp_start);
> +
> + if (ret == 0)
> + pr_debug("Removed old IMA buffer reservation.\n");
> + else if (ret != -ENOENT)
> + return;
> +
> + fdt_delprop(fdt, chosen_node, "linux,ima-kexec-buffer");
> + fdt_delprop(fdt, chosen_node, "linux,ima-kexec-buffer-end");
> + }
> +}
> +
> +/**
> + * ima_get_kexec_buffer - get IMA buffer from the previous kernel
> + * @addr: On successful return, set to point to the buffer contents.
> + * @size: On successful return, set to the buffer size.
> + *
> + * Return: 0 on success, negative errno on error.
> + */
> +int ima_get_kexec_buffer(void **addr, size_t *size)
> +{
> + int len;
> + const void *prop;
> + uint64_t tmp_start, tmp_end;
> +
> + prop = of_get_property(of_chosen, "linux,ima-kexec-buffer", &len);
> + if (!prop)
> + return -ENOENT;
> +
> + tmp_start = fdt64_to_cpu(*((const fdt64_t *) prop));
> +
> + prop = of_get_property(of_chosen, "linux,ima-kexec-buffer-end", &len);
> + if (!prop)
> + return -ENOENT;
> +
> + tmp_end = fdt64_to_cpu(*((const fdt64_t *) prop));
> +
> + *addr = __va(tmp_start);
> + *size = tmp_end - tmp_start;
> +
> + return 0;
> +}
> +
> +/**
> + * ima_free_kexec_buffer - free memory used by the IMA buffer
> + *
> + * Return: 0 on success, negative errno on error.
> + */
> +int ima_free_kexec_buffer(void)
> +{
> + int ret;
> + void *propStart, *propEnd;
Is there a reason for using mixed case variables? Why does the
variable need to be prefixed with "prop"? Wouldn't ima_start/_stop,
buffer_start/_stop, or even buf_start/_stop be fine?
> + uint64_t tmp_start, tmp_end;
> +
> + propStart = of_find_property(of_chosen, "linux,ima-kexec-buffer",
> + NULL);
> + if (propStart) {
> + tmp_start = fdt64_to_cpu(*((const fdt64_t *) propStart));
> + ret = of_remove_property(of_chosen, propStart);
> + if (!ret) {
> + return ret;
> + }
> +
> + propEnd = of_find_property(of_chosen,
> + "linux,ima-kexec-buffer-end", NULL);
> + if (!propEnd) {
> + return -EINVAL;
> + }
> +
> + tmp_end = fdt64_to_cpu(*((const fdt64_t *) propEnd));
> +
> + ret = of_remove_property(of_chosen, propEnd);
> + if (!ret) {
> + return ret;
> + }
There seems to be quite a bit of code duplication in this function and
in ima_get_kexec_buffer(). It could probably be cleaned up with some
refactoring.
Mimi
> +
> + return memblock_free(tmp_start, tmp_end - tmp_start);
> + }
> + return 0;
> +}
> +
> +#ifdef CONFIG_IMA_KEXEC
> +/**
> + * arch_ima_add_kexec_buffer - do arch-specific steps to add the IMA
> + * measurement log.
> + * @image: - pointer to the kimage, to store the address and size of the
> + * IMA measurement log.
> + * @load_addr: - the address where the IMA measurement log is stored.
> + * @size - size of the IMA measurement log.
> + *
> + * Return: 0 on success, negative errno on error.
> + */
> +int arch_ima_add_kexec_buffer(struct kimage *image, unsigned long load_addr,
> + size_t size)
> +{
> + image->arch.ima_buffer_addr = load_addr;
> + image->arch.ima_buffer_size = size;
> + return 0;
> +}
> +
> +/**
> + * setup_ima_buffer - update the fdt to contain the ima mesasurement log
> + * @image: - pointer to the kimage, containing the address and size of
> + * the IMA measurement log.
> + * @fdt: - pointer to the fdt.
> + * @chosen_node: - node under which property is to be defined.
> + *
> + * Return: 0 on success, negative errno on error.
> + */
> +int setup_ima_buffer(const struct kimage *image, void *fdt, int chosen_node)
> +{
> + int ret;
> +
> + remove_ima_buffer(fdt, chosen_node);
> +
> + if (!image->arch.ima_buffer_size)
> + return 0;
> +
> + ret = fdt_setprop_u64(fdt, chosen_node, "linux,ima-kexec-buffer",
> + image->arch.ima_buffer_addr);
> + if (ret < 0)
> + return ret;
> +
> + ret = fdt_setprop_u64(fdt, chosen_node, "linux,ima-kexec-buffer-end",
> + image->arch.ima_buffer_addr +
> + image->arch.ima_buffer_size);
> + if (ret < 0)
> + return ret;
> +
> + ret = fdt_add_mem_rsv(fdt, image->arch.ima_buffer_addr,
> + image->arch.ima_buffer_size);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +#endif /* CONFIG_IMA_KEXEC */
> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> index 58871333737a..de5452539c67 100644
> --- a/arch/arm64/kernel/machine_kexec_file.c
> +++ b/arch/arm64/kernel/machine_kexec_file.c
> @@ -21,6 +21,7 @@
> #include <linux/types.h>
> #include <linux/vmalloc.h>
> #include <asm/byteorder.h>
> +#include <asm/ima.h>
>
> /* relevant device tree properties */
> #define FDT_PROP_INITRD_START "linux,initrd-start"
> @@ -85,6 +86,11 @@ static int setup_dtb(struct kimage *image,
> goto out;
> }
>
> + /* add ima measuremnet log buffer */
> + ret = setup_ima_buffer(image, dtb, off);
> + if (ret)
> + goto out;
> +
> /* add kaslr-seed */
> ret = fdt_delprop(dtb, off, FDT_PROP_KASLR_SEED);
> if (ret == -FDT_ERR_NOTFOUND)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH] ethernet: Use devm_platform_ioremap_resource() in three functions
From: Radhey Shyam Pandey @ 2019-09-18 14:16 UTC (permalink / raw)
To: Markus Elfring, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, David S. Miller,
Hans Ulli Kroll, Hauke Mehrtens, Linus Walleij, Michal Simek
Cc: Bartosz Golaszewski, kernel-janitors@vger.kernel.org, LKML,
Himanshu Jha
In-Reply-To: <af65355e-c2f8-9142-4d0b-6903f23a98b2@web.de>
> -----Original Message-----
> From: Markus Elfring <Markus.Elfring@web.de>
> Sent: Wednesday, September 18, 2019 7:01 PM
> To: netdev@vger.kernel.org; linux-arm-kernel@lists.infradead.org; David S.
> Miller <davem@davemloft.net>; Hans Ulli Kroll <ulli.kroll@googlemail.com>;
> Hauke Mehrtens <hauke@hauke-m.de>; Linus Walleij
> <linus.walleij@linaro.org>; Michal Simek <michals@xilinx.com>; Radhey
> Shyam Pandey <radheys@xilinx.com>
> Cc: LKML <linux-kernel@vger.kernel.org>; kernel-janitors@vger.kernel.org;
> Bartosz Golaszewski <bgolaszewski@baylibre.com>; Himanshu Jha
> <himanshujha199640@gmail.com>
> Subject: [PATCH] ethernet: Use devm_platform_ioremap_resource() in three
> functions
Prefer using a separate patch for each driver. Also skip mentioning
"three functions" in commit description.
>
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Wed, 18 Sep 2019 15:15:06 +0200
>
> Simplify these function implementations by using a known wrapper function.
Minor nit- Better to mention about these funcs in commit description.
Something like- uses devm_platform_ioremap_resource() instead of using
platform_get_resource() and devm_ioremap_resource() together to simplify.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
> ---
> drivers/net/ethernet/cortina/gemini.c | 6 +-----
> drivers/net/ethernet/lantiq_xrx200.c | 11 +----------
> drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 9 +--------
> 3 files changed, 3 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/net/ethernet/cortina/gemini.c
> b/drivers/net/ethernet/cortina/gemini.c
> index e736ce2c58ca..f009415ee4d8 100644
> --- a/drivers/net/ethernet/cortina/gemini.c
> +++ b/drivers/net/ethernet/cortina/gemini.c
> @@ -2549,17 +2549,13 @@ static int gemini_ethernet_probe(struct
> platform_device *pdev)
> struct device *dev = &pdev->dev;
> struct gemini_ethernet *geth;
> unsigned int retry = 5;
> - struct resource *res;
> u32 val;
>
> /* Global registers */
> geth = devm_kzalloc(dev, sizeof(*geth), GFP_KERNEL);
> if (!geth)
> return -ENOMEM;
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res)
> - return -ENODEV;
> - geth->base = devm_ioremap_resource(dev, res);
> + geth->base = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(geth->base))
> return PTR_ERR(geth->base);
> geth->dev = dev;
> diff --git a/drivers/net/ethernet/lantiq_xrx200.c
> b/drivers/net/ethernet/lantiq_xrx200.c
> index 900affbdcc0e..0a7ea45b9e59 100644
> --- a/drivers/net/ethernet/lantiq_xrx200.c
> +++ b/drivers/net/ethernet/lantiq_xrx200.c
> @@ -424,7 +424,6 @@ static int xrx200_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> struct device_node *np = dev->of_node;
> - struct resource *res;
> struct xrx200_priv *priv;
> struct net_device *net_dev;
> const u8 *mac;
> @@ -443,15 +442,7 @@ static int xrx200_probe(struct platform_device *pdev)
> SET_NETDEV_DEV(net_dev, dev);
> net_dev->min_mtu = ETH_ZLEN;
> net_dev->max_mtu = XRX200_DMA_DATA_LEN;
> -
> - /* load the memory ranges */
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (!res) {
> - dev_err(dev, "failed to get resources\n");
> - return -ENOENT;
> - }
> -
> - priv->pmac_reg = devm_ioremap_resource(dev, res);
> + priv->pmac_reg = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(priv->pmac_reg)) {
> dev_err(dev, "failed to request and remap io ranges\n");
> return PTR_ERR(priv->pmac_reg);
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> index 4fc627fb4d11..92783aaaa0a2 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> @@ -1787,14 +1787,7 @@ static int axienet_probe(struct platform_device
> *pdev)
> of_node_put(np);
> lp->eth_irq = platform_get_irq(pdev, 0);
> } else {
> - /* Check for these resources directly on the Ethernet node. */
> - struct resource *res = platform_get_resource(pdev,
> -
> IORESOURCE_MEM, 1);
> - if (!res) {
> - dev_err(&pdev->dev, "unable to get DMA memory
> resource\n");
> - goto free_netdev;
> - }
> - lp->dma_regs = devm_ioremap_resource(&pdev->dev, res);
> + lp->dma_regs = devm_platform_ioremap_resource(pdev, 1);
> lp->rx_irq = platform_get_irq(pdev, 1);
> lp->tx_irq = platform_get_irq(pdev, 0);
> lp->eth_irq = platform_get_irq(pdev, 2);
> --
> 2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] drm: sun8i-ui/vi: Fix layer zpos change/atomic modesetting
From: Maxime Ripard @ 2019-09-18 14:17 UTC (permalink / raw)
To: megous
Cc: David Airlie, linux-kernel, dri-devel, Chen-Yu Tsai,
Daniel Vetter, linux-arm-kernel
In-Reply-To: <20190914220337.646719-1-megous@megous.com>
[-- Attachment #1.1: Type: text/plain, Size: 753 bytes --]
Hi,
On Sun, Sep 15, 2019 at 12:03:37AM +0200, megous@megous.com wrote:
> From: Ondrej Jirman <megous@megous.com>
>
> There are various issues that this re-work of sun8i_[uv]i_layer_enable
> function fixes:
>
> - Make sure that we re-initialize zpos on reset
> - Minimize register updates by doing them only when state changes
> - Fix issue where DE pipe might get disabled even if it is no longer
> used by the layer that's currently calling sun8i_ui_layer_enable
> - .atomic_disable callback is not really needed because .atomic_update
> can do the disable too, so drop the duplicate code
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
It looks like these fixes should be in separate patches. Is there any
reason it's not the case?
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V6 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Jassi Brar @ 2019-09-18 14:19 UTC (permalink / raw)
To: Andre Przywara
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Peng Fan,
f.fainelli@gmail.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx, sudeep.holla@arm.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190918104347.285bd7ad@donnerap.cambridge.arm.com>
On Wed, Sep 18, 2019 at 4:44 AM Andre Przywara <andre.przywara@arm.com> wrote:
>
> > which needs 9 arguments to work. The fact that the fist argument is
> > always going to be same on a platform is just the way we use this
> > instruction.
> >
> > > We should be as strict as possible to avoid any security issues.
> > >
> > Any example of such a security issue?
>
> Someone finds a way to trick some mailbox client to send a crafted message to the mailbox.
>
What if someone finds a way to trick the block layer to erase 'sda' ?
That is called "bug in the code".
It does happen in every subsystem but we don't stop implementing new
features .... we write flexible code and then fix any bug.
> Do you have any example of a use case where the mailbox client needs to provide the function ID?
>
FSL_SIP_SCMI_1/2 ?
But that is not the main point, which is to be consistent (not
ignoring first argument because someone may find a bug to exploit) and
flexible.
> > > The firmware certainly knows the function ID it implements. The firmware controls the DT. So it is straight-forward to put the ID into the DT. The firmware could even do this at boot time, dynamically, before passing on the DT to the non-secure world (bootloader or kernel).
> > >
> > > What would be the use case of this functionality?
> > >
> > At least for flexibility and consistency.
>
> I appreciate the flexibility idea, but when creating an interface, especially a generic one to any kind of firmware, you should be as strict as possible, to avoid clashes in the future.
>
I really don't see how there can be clashes with more complete and
flexible implementation.
Thanks.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/3] arm64: cpufeature: introduce helper cpu_has_hw_af()
From: Matthew Wilcox @ 2019-09-18 14:20 UTC (permalink / raw)
To: Jia He
Cc: Mark Rutland, Kaly Xin, Ralph Campbell, Andrew Morton,
Suzuki Poulose, Catalin Marinas, Anshuman Khandual, linux-kernel,
Jun Yao, linux-mm, Jérôme Glisse, James Morse,
linux-arm-kernel, Punit Agrawal, Marc Zyngier, hejianet,
Thomas Gleixner, Will Deacon, Alex Van Brunt, Kirill A. Shutemov,
Robin Murphy
In-Reply-To: <20190918131914.38081-2-justin.he@arm.com>
On Wed, Sep 18, 2019 at 09:19:12PM +0800, Jia He wrote:
> +/* Decouple AF from AFDBM. */
> +bool cpu_has_hw_af(void)
> +{
> + return (read_cpuid(ID_AA64MMFR1_EL1) & 0xf);
> +}
> +
Do you really want to call read_cpuid() every time? I would have thought
you'd want to use the static branch mechanism to do the right thing at
boot time. See Documentation/static-keys.txt.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/3] arm64: cpufeature: introduce helper cpu_has_hw_af()
From: Suzuki K Poulose @ 2019-09-18 14:20 UTC (permalink / raw)
To: Jia He, Catalin Marinas, Will Deacon, Mark Rutland, James Morse,
Marc Zyngier, Matthew Wilcox, Kirill A. Shutemov,
linux-arm-kernel, linux-kernel, linux-mm
Cc: Ralph Campbell, Andrew Morton, Anshuman Khandual, Jun Yao,
Kaly Xin, Jérôme Glisse, Punit Agrawal, hejianet,
Thomas Gleixner, Robin Murphy, Alex Van Brunt
In-Reply-To: <20190918131914.38081-2-justin.he@arm.com>
Hi Jia,
On 18/09/2019 14:19, Jia He wrote:
> We unconditionally set the HW_AFDBM capability and only enable it on
> CPUs which really have the feature. But sometimes we need to know
> whether this cpu has the capability of HW AF. So decouple AF from
> DBM by new helper cpu_has_hw_af().
>
> Signed-off-by: Jia He <justin.he@arm.com>
> Suggested-by: Suzuki Poulose <Suzuki.Poulose@arm.com>
> ---
> arch/arm64/include/asm/cpufeature.h | 1 +
> arch/arm64/kernel/cpufeature.c | 6 ++++++
> 2 files changed, 7 insertions(+)
>
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index c96ffa4722d3..206b6e3954cf 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -390,6 +390,7 @@ extern DECLARE_BITMAP(boot_capabilities, ARM64_NPATCHABLE);
> for_each_set_bit(cap, cpu_hwcaps, ARM64_NCAPS)
>
> bool this_cpu_has_cap(unsigned int cap);
> +bool cpu_has_hw_af(void);
> void cpu_set_feature(unsigned int num);
> bool cpu_have_feature(unsigned int num);
> unsigned long cpu_get_elf_hwcap(void);
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index b1fdc486aed8..c5097f58649d 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1141,6 +1141,12 @@ static bool has_hw_dbm(const struct arm64_cpu_capabilities *cap,
> return true;
> }
>
> +/* Decouple AF from AFDBM. */
> +bool cpu_has_hw_af(void)
> +{
Sorry for not having asked this earlier. Are we interested in,
"whether *this* CPU has AF support ?" or "whether *at least one*
CPU has the AF support" ? The following code does the former.
> + return (read_cpuid(ID_AA64MMFR1_EL1) & 0xf);
Getting the latter is tricky, and I think it is what we are looking
for here. In which case we may need something more to report this.
Kind regards
Suzuki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] firmware: arm_scmi: fixes for scmi-updates-5.4
From: Sudeep Holla @ 2019-09-18 14:21 UTC (permalink / raw)
To: ARM SoC Team, SoC Team, ALKML
Cc: Olof Johansson, Sudeep Holla, Arnd Bergmann, Kevin Hilman
Hi ARM SoC Team,
Please pull ! The changes in reset driver has been acked by Philipp Zabel
and agreed to be merged via ARM SoC tree.
Regards,
Sudeep
-->8
The following changes since commit c8ae9c2da1cc5d18b6d51d10160508a3dc3436bf:
reset: Add support for resets provided by SCMI (2019-08-12 12:23:02 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/scmi-fixes-5.4
for you to fetch changes up to 61423712dbb86e02af4aa5de65b9041493c92cac:
reset: reset-scmi: add missing handle initialisation (2019-09-18 13:42:44 +0100)
----------------------------------------------------------------
ARM SCMI fixes for v5.4
Couple of fixes: one in scmi reset driver initialising missed scmi handle
and an other in scmi reset API implementation fixing the assignment of
reset state
----------------------------------------------------------------
Sudeep Holla (2):
firmware: arm_scmi: reset: fix reset_state assignment in scmi_domain_reset
reset: reset-scmi: add missing handle initialisation
drivers/firmware/arm_scmi/reset.c | 2 +-
drivers/reset/reset-scmi.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V6 2/2] mailbox: introduce ARM SMC based mailbox
From: Jassi Brar @ 2019-09-18 14:22 UTC (permalink / raw)
To: Andre Przywara
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Peng Fan,
f.fainelli@gmail.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx, sudeep.holla@arm.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190918145832.0bb72e16@donnerap.cambridge.arm.com>
On Wed, Sep 18, 2019 at 8:58 AM Andre Przywara <andre.przywara@arm.com> wrote:
>
> > > Also there is mbox_chan_txdone() with which a controller driver can signal TX completion explicitly.
> > >
> > No. Controller can use that only if it has specified txdone_irq, which
> > is not the case here.
>
> I see. So does the framework handle the case where both txdone_poll and txdone_irq are false?
>
Of course. If there is no IRQ or POLL mechanism for controller to
detect tx-done, the only way left is for client driver to know by some
'ack' response (if any). The client should call mbox_client_txdone()
Thanks
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 0/2] Simplify count_read/count_write/signal_read
From: William Breathitt Gray @ 2019-09-18 14:22 UTC (permalink / raw)
To: jic23
Cc: benjamin.gaignard, alexandre.torgue, linux-iio, patrick.havelange,
linux-kernel, William Breathitt Gray, mcoquelin.stm32,
fabrice.gasnier, linux-stm32, linux-arm-kernel
Changes in v3:
- Squash code changes to single patch to avoid compilation error
The changes in this patchset will not affect the userspace interface.
Rather, these changes are intended to simplify the kernelspace Counter
callbacks for counter device driver authors.
The following main changes are proposed:
* Retire the opaque counter_count_read_value/counter_count_write_value
structures and simply represent count data as an unsigned integer.
* Retire the opaque counter_signal_read_value structure and represent
Signal data as a counter_signal_value enum.
These changes should reduce some complexity and code in the use and
implementation of the count_read, count_write, and signal_read
callbacks.
The opaque structures for Count data and Signal data were introduced
originally in anticipation of supporting various representations of
counter data (e.g. arbitrary-precision tallies, floating-point spherical
coordinate positions, etc). However, with the counter device drivers
that have appeared, it's become apparent that utilizing opaque
structures in kernelspace is not the best approach to take.
I believe it is best to let userspace applications decide how to
interpret the count data they receive. There are a couple of reasons why
it would be good to do so:
* Users use their devices in unexpected ways.
For example, a quadrature encoder counter device is typically used to
keep track of the position of a motor, but a user could set the device
in a pulse-direction mode and instead use it to count sporadic rising
edges from an arbitrary signal line unrelated to positioning. Users
should have the freedom to decide what their data represents.
* Most counter devices represent data as unsigned integers anyway.
For example, whether the device is a tally counter or position
counter, the count data is represented to the user as an unsigned
integer value. So specifying that one device is representing tallies
while the other specifies positions does not provide much utility from
an interface perspective.
For these reasons, the count_read and count_write callbacks have been
redefined to pass count data directly as unsigned long instead of passed
via opaque structures:
count_read(struct counter_device *counter,
struct counter_count *count, unsigned long *val);
count_write(struct counter_device *counter,
struct counter_count *count, unsigned long val);
Similarly, the signal_read is redefined to pass Signal data directly as
a counter_signal_value enum instead of via an opaque structure:
signal_read(struct counter_device *counter,
struct counter_signal *signal,
enum counter_signal_value *val);
The counter_signal_value enum is simply the counter_signal_level enum
redefined to remove the references to the Signal data "level" data type.
William Breathitt Gray (2):
counter: Simplify the count_read and count_write callbacks
docs: driver-api: generic-counter: Update Count and Signal data types
Documentation/driver-api/generic-counter.rst | 22 ++--
drivers/counter/104-quad-8.c | 33 ++----
drivers/counter/counter.c | 101 +++----------------
drivers/counter/ftm-quaddec.c | 14 +--
drivers/counter/stm32-lptimer-cnt.c | 5 +-
drivers/counter/stm32-timer-cnt.c | 17 +---
include/linux/counter.h | 74 ++------------
7 files changed, 53 insertions(+), 213 deletions(-)
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 1/2] counter: Simplify the count_read and count_write callbacks
From: William Breathitt Gray @ 2019-09-18 14:22 UTC (permalink / raw)
To: jic23
Cc: benjamin.gaignard, alexandre.torgue, linux-iio, patrick.havelange,
linux-kernel, William Breathitt Gray, mcoquelin.stm32,
fabrice.gasnier, linux-stm32, linux-arm-kernel
In-Reply-To: <cover.1568816248.git.vilhelm.gray@gmail.com>
The count_read and count_write callbacks are simplified to pass val as
unsigned long rather than as an opaque data structure. The opaque
counter_count_read_value and counter_count_write_value structures,
counter_count_value_type enum, and relevant counter_count_read_value_set
and counter_count_write_value_get functions, are removed as they are no
longer used.
Cc: Patrick Havelange <patrick.havelange@essensium.com>
Acked-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
drivers/counter/104-quad-8.c | 33 +++------
drivers/counter/counter.c | 101 +++++-----------------------
drivers/counter/ftm-quaddec.c | 14 ++--
drivers/counter/stm32-lptimer-cnt.c | 5 +-
drivers/counter/stm32-timer-cnt.c | 17 ++---
include/linux/counter.h | 74 +++-----------------
6 files changed, 45 insertions(+), 199 deletions(-)
diff --git a/drivers/counter/104-quad-8.c b/drivers/counter/104-quad-8.c
index 00b113f4b958..17e67a84777d 100644
--- a/drivers/counter/104-quad-8.c
+++ b/drivers/counter/104-quad-8.c
@@ -562,11 +562,10 @@ static const struct iio_chan_spec quad8_channels[] = {
};
static int quad8_signal_read(struct counter_device *counter,
- struct counter_signal *signal, struct counter_signal_read_value *val)
+ struct counter_signal *signal, enum counter_signal_value *val)
{
const struct quad8_iio *const priv = counter->priv;
unsigned int state;
- enum counter_signal_level level;
/* Only Index signal levels can be read */
if (signal->id < 16)
@@ -575,22 +574,19 @@ static int quad8_signal_read(struct counter_device *counter,
state = inb(priv->base + QUAD8_REG_INDEX_INPUT_LEVELS)
& BIT(signal->id - 16);
- level = (state) ? COUNTER_SIGNAL_LEVEL_HIGH : COUNTER_SIGNAL_LEVEL_LOW;
-
- counter_signal_read_value_set(val, COUNTER_SIGNAL_LEVEL, &level);
+ *val = (state) ? COUNTER_SIGNAL_HIGH : COUNTER_SIGNAL_LOW;
return 0;
}
static int quad8_count_read(struct counter_device *counter,
- struct counter_count *count, struct counter_count_read_value *val)
+ struct counter_count *count, unsigned long *val)
{
const struct quad8_iio *const priv = counter->priv;
const int base_offset = priv->base + 2 * count->id;
unsigned int flags;
unsigned int borrow;
unsigned int carry;
- unsigned long position;
int i;
flags = inb(base_offset + 1);
@@ -598,36 +594,27 @@ static int quad8_count_read(struct counter_device *counter,
carry = !!(flags & QUAD8_FLAG_CT);
/* Borrow XOR Carry effectively doubles count range */
- position = (unsigned long)(borrow ^ carry) << 24;
+ *val = (unsigned long)(borrow ^ carry) << 24;
/* Reset Byte Pointer; transfer Counter to Output Latch */
outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_BP | QUAD8_RLD_CNTR_OUT,
base_offset + 1);
for (i = 0; i < 3; i++)
- position |= (unsigned long)inb(base_offset) << (8 * i);
-
- counter_count_read_value_set(val, COUNTER_COUNT_POSITION, &position);
+ *val |= (unsigned long)inb(base_offset) << (8 * i);
return 0;
}
static int quad8_count_write(struct counter_device *counter,
- struct counter_count *count, struct counter_count_write_value *val)
+ struct counter_count *count, unsigned long val)
{
const struct quad8_iio *const priv = counter->priv;
const int base_offset = priv->base + 2 * count->id;
- int err;
- unsigned long position;
int i;
- err = counter_count_write_value_get(&position, COUNTER_COUNT_POSITION,
- val);
- if (err)
- return err;
-
/* Only 24-bit values are supported */
- if (position > 0xFFFFFF)
+ if (val > 0xFFFFFF)
return -EINVAL;
/* Reset Byte Pointer */
@@ -635,7 +622,7 @@ static int quad8_count_write(struct counter_device *counter,
/* Counter can only be set via Preset Register */
for (i = 0; i < 3; i++)
- outb(position >> (8 * i), base_offset);
+ outb(val >> (8 * i), base_offset);
/* Transfer Preset Register to Counter */
outb(QUAD8_CTR_RLD | QUAD8_RLD_PRESET_CNTR, base_offset + 1);
@@ -644,9 +631,9 @@ static int quad8_count_write(struct counter_device *counter,
outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_BP, base_offset + 1);
/* Set Preset Register back to original value */
- position = priv->preset[count->id];
+ val = priv->preset[count->id];
for (i = 0; i < 3; i++)
- outb(position >> (8 * i), base_offset);
+ outb(val >> (8 * i), base_offset);
/* Reset Borrow, Carry, Compare, and Sign flags */
outb(QUAD8_CTR_RLD | QUAD8_RLD_RESET_FLAGS, base_offset + 1);
diff --git a/drivers/counter/counter.c b/drivers/counter/counter.c
index 106bc7180cd8..6a683d086008 100644
--- a/drivers/counter/counter.c
+++ b/drivers/counter/counter.c
@@ -220,86 +220,6 @@ ssize_t counter_device_enum_available_read(struct counter_device *counter,
}
EXPORT_SYMBOL_GPL(counter_device_enum_available_read);
-static const char *const counter_signal_level_str[] = {
- [COUNTER_SIGNAL_LEVEL_LOW] = "low",
- [COUNTER_SIGNAL_LEVEL_HIGH] = "high"
-};
-
-/**
- * counter_signal_read_value_set - set counter_signal_read_value data
- * @val: counter_signal_read_value structure to set
- * @type: property Signal data represents
- * @data: Signal data
- *
- * This function sets an opaque counter_signal_read_value structure with the
- * provided Signal data.
- */
-void counter_signal_read_value_set(struct counter_signal_read_value *const val,
- const enum counter_signal_value_type type,
- void *const data)
-{
- if (type == COUNTER_SIGNAL_LEVEL)
- val->len = sprintf(val->buf, "%s\n",
- counter_signal_level_str[*(enum counter_signal_level *)data]);
- else
- val->len = 0;
-}
-EXPORT_SYMBOL_GPL(counter_signal_read_value_set);
-
-/**
- * counter_count_read_value_set - set counter_count_read_value data
- * @val: counter_count_read_value structure to set
- * @type: property Count data represents
- * @data: Count data
- *
- * This function sets an opaque counter_count_read_value structure with the
- * provided Count data.
- */
-void counter_count_read_value_set(struct counter_count_read_value *const val,
- const enum counter_count_value_type type,
- void *const data)
-{
- switch (type) {
- case COUNTER_COUNT_POSITION:
- val->len = sprintf(val->buf, "%lu\n", *(unsigned long *)data);
- break;
- default:
- val->len = 0;
- }
-}
-EXPORT_SYMBOL_GPL(counter_count_read_value_set);
-
-/**
- * counter_count_write_value_get - get counter_count_write_value data
- * @data: Count data
- * @type: property Count data represents
- * @val: counter_count_write_value structure containing data
- *
- * This function extracts Count data from the provided opaque
- * counter_count_write_value structure and stores it at the address provided by
- * @data.
- *
- * RETURNS:
- * 0 on success, negative error number on failure.
- */
-int counter_count_write_value_get(void *const data,
- const enum counter_count_value_type type,
- const struct counter_count_write_value *const val)
-{
- int err;
-
- switch (type) {
- case COUNTER_COUNT_POSITION:
- err = kstrtoul(val->buf, 0, data);
- if (err)
- return err;
- break;
- }
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(counter_count_write_value_get);
-
struct counter_attr_parm {
struct counter_device_attr_group *group;
const char *prefix;
@@ -369,6 +289,11 @@ struct counter_signal_unit {
struct counter_signal *signal;
};
+static const char *const counter_signal_value_str[] = {
+ [COUNTER_SIGNAL_LOW] = "low",
+ [COUNTER_SIGNAL_HIGH] = "high"
+};
+
static ssize_t counter_signal_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -377,13 +302,13 @@ static ssize_t counter_signal_show(struct device *dev,
const struct counter_signal_unit *const component = devattr->component;
struct counter_signal *const signal = component->signal;
int err;
- struct counter_signal_read_value val = { .buf = buf };
+ enum counter_signal_value val;
err = counter->ops->signal_read(counter, signal, &val);
if (err)
return err;
- return val.len;
+ return sprintf(buf, "%s\n", counter_signal_value_str[val]);
}
struct counter_name_unit {
@@ -788,13 +713,13 @@ static ssize_t counter_count_show(struct device *dev,
const struct counter_count_unit *const component = devattr->component;
struct counter_count *const count = component->count;
int err;
- struct counter_count_read_value val = { .buf = buf };
+ unsigned long val;
err = counter->ops->count_read(counter, count, &val);
if (err)
return err;
- return val.len;
+ return sprintf(buf, "%lu\n", val);
}
static ssize_t counter_count_store(struct device *dev,
@@ -806,9 +731,13 @@ static ssize_t counter_count_store(struct device *dev,
const struct counter_count_unit *const component = devattr->component;
struct counter_count *const count = component->count;
int err;
- struct counter_count_write_value val = { .buf = buf };
+ unsigned long val;
+
+ err = kstrtoul(buf, 0, &val);
+ if (err)
+ return err;
- err = counter->ops->count_write(counter, count, &val);
+ err = counter->ops->count_write(counter, count, val);
if (err)
return err;
diff --git a/drivers/counter/ftm-quaddec.c b/drivers/counter/ftm-quaddec.c
index 4046aa9f9234..c2b3fdfd8b77 100644
--- a/drivers/counter/ftm-quaddec.c
+++ b/drivers/counter/ftm-quaddec.c
@@ -178,31 +178,25 @@ static const enum counter_count_function ftm_quaddec_count_functions[] = {
static int ftm_quaddec_count_read(struct counter_device *counter,
struct counter_count *count,
- struct counter_count_read_value *val)
+ unsigned long *val)
{
struct ftm_quaddec *const ftm = counter->priv;
uint32_t cntval;
ftm_read(ftm, FTM_CNT, &cntval);
- counter_count_read_value_set(val, COUNTER_COUNT_POSITION, &cntval);
+ *val = cntval;
return 0;
}
static int ftm_quaddec_count_write(struct counter_device *counter,
struct counter_count *count,
- struct counter_count_write_value *val)
+ const unsigned long val)
{
struct ftm_quaddec *const ftm = counter->priv;
- u32 cnt;
- int err;
- err = counter_count_write_value_get(&cnt, COUNTER_COUNT_POSITION, val);
- if (err)
- return err;
-
- if (cnt != 0) {
+ if (val != 0) {
dev_warn(&ftm->pdev->dev, "Can only accept '0' as new counter value\n");
return -EINVAL;
}
diff --git a/drivers/counter/stm32-lptimer-cnt.c b/drivers/counter/stm32-lptimer-cnt.c
index bbc930a5962c..73bb773f5e6d 100644
--- a/drivers/counter/stm32-lptimer-cnt.c
+++ b/drivers/counter/stm32-lptimer-cnt.c
@@ -377,8 +377,7 @@ static enum counter_synapse_action stm32_lptim_cnt_synapse_actions[] = {
};
static int stm32_lptim_cnt_read(struct counter_device *counter,
- struct counter_count *count,
- struct counter_count_read_value *val)
+ struct counter_count *count, unsigned long *val)
{
struct stm32_lptim_cnt *const priv = counter->priv;
u32 cnt;
@@ -388,7 +387,7 @@ static int stm32_lptim_cnt_read(struct counter_device *counter,
if (ret)
return ret;
- counter_count_read_value_set(val, COUNTER_COUNT_POSITION, &cnt);
+ *val = cnt;
return 0;
}
diff --git a/drivers/counter/stm32-timer-cnt.c b/drivers/counter/stm32-timer-cnt.c
index 644ba18a72ad..839083543323 100644
--- a/drivers/counter/stm32-timer-cnt.c
+++ b/drivers/counter/stm32-timer-cnt.c
@@ -48,34 +48,27 @@ static enum counter_count_function stm32_count_functions[] = {
};
static int stm32_count_read(struct counter_device *counter,
- struct counter_count *count,
- struct counter_count_read_value *val)
+ struct counter_count *count, unsigned long *val)
{
struct stm32_timer_cnt *const priv = counter->priv;
u32 cnt;
regmap_read(priv->regmap, TIM_CNT, &cnt);
- counter_count_read_value_set(val, COUNTER_COUNT_POSITION, &cnt);
+ *val = cnt;
return 0;
}
static int stm32_count_write(struct counter_device *counter,
struct counter_count *count,
- struct counter_count_write_value *val)
+ const unsigned long val)
{
struct stm32_timer_cnt *const priv = counter->priv;
- u32 cnt;
- int err;
-
- err = counter_count_write_value_get(&cnt, COUNTER_COUNT_POSITION, val);
- if (err)
- return err;
- if (cnt > priv->ceiling)
+ if (val > priv->ceiling)
return -EINVAL;
- return regmap_write(priv->regmap, TIM_CNT, cnt);
+ return regmap_write(priv->regmap, TIM_CNT, val);
}
static int stm32_count_function_get(struct counter_device *counter,
diff --git a/include/linux/counter.h b/include/linux/counter.h
index a061cdcdef7c..32fb4d8cc3fd 100644
--- a/include/linux/counter.h
+++ b/include/linux/counter.h
@@ -290,53 +290,22 @@ struct counter_device_state {
const struct attribute_group **groups;
};
-/**
- * struct counter_signal_read_value - Opaque Signal read value
- * @buf: string representation of Signal read value
- * @len: length of string in @buf
- */
-struct counter_signal_read_value {
- char *buf;
- size_t len;
-};
-
-/**
- * struct counter_count_read_value - Opaque Count read value
- * @buf: string representation of Count read value
- * @len: length of string in @buf
- */
-struct counter_count_read_value {
- char *buf;
- size_t len;
-};
-
-/**
- * struct counter_count_write_value - Opaque Count write value
- * @buf: string representation of Count write value
- */
-struct counter_count_write_value {
- const char *buf;
+enum counter_signal_value {
+ COUNTER_SIGNAL_LOW = 0,
+ COUNTER_SIGNAL_HIGH
};
/**
* struct counter_ops - Callbacks from driver
* @signal_read: optional read callback for Signal attribute. The read
* value of the respective Signal should be passed back via
- * the val parameter. val points to an opaque type which
- * should be set only by calling the
- * counter_signal_read_value_set function from within the
- * signal_read callback.
+ * the val parameter.
* @count_read: optional read callback for Count attribute. The read
* value of the respective Count should be passed back via
- * the val parameter. val points to an opaque type which
- * should be set only by calling the
- * counter_count_read_value_set function from within the
- * count_read callback.
+ * the val parameter.
* @count_write: optional write callback for Count attribute. The write
* value for the respective Count is passed in via the val
- * parameter. val points to an opaque type which should be
- * accessed only by calling the
- * counter_count_write_value_get function.
+ * parameter.
* @function_get: function to get the current count function mode. Returns
* 0 on success and negative error code on error. The index
* of the respective Count's returned function mode should
@@ -355,13 +324,11 @@ struct counter_count_write_value {
struct counter_ops {
int (*signal_read)(struct counter_device *counter,
struct counter_signal *signal,
- struct counter_signal_read_value *val);
+ enum counter_signal_value *val);
int (*count_read)(struct counter_device *counter,
- struct counter_count *count,
- struct counter_count_read_value *val);
+ struct counter_count *count, unsigned long *val);
int (*count_write)(struct counter_device *counter,
- struct counter_count *count,
- struct counter_count_write_value *val);
+ struct counter_count *count, unsigned long val);
int (*function_get)(struct counter_device *counter,
struct counter_count *count, size_t *function);
int (*function_set)(struct counter_device *counter,
@@ -477,29 +444,6 @@ struct counter_device {
void *priv;
};
-enum counter_signal_level {
- COUNTER_SIGNAL_LEVEL_LOW = 0,
- COUNTER_SIGNAL_LEVEL_HIGH
-};
-
-enum counter_signal_value_type {
- COUNTER_SIGNAL_LEVEL = 0
-};
-
-enum counter_count_value_type {
- COUNTER_COUNT_POSITION = 0,
-};
-
-void counter_signal_read_value_set(struct counter_signal_read_value *const val,
- const enum counter_signal_value_type type,
- void *const data);
-void counter_count_read_value_set(struct counter_count_read_value *const val,
- const enum counter_count_value_type type,
- void *const data);
-int counter_count_write_value_get(void *const data,
- const enum counter_count_value_type type,
- const struct counter_count_write_value *const val);
-
int counter_register(struct counter_device *const counter);
void counter_unregister(struct counter_device *const counter);
int devm_counter_register(struct device *dev,
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 2/2] docs: driver-api: generic-counter: Update Count and Signal data types
From: William Breathitt Gray @ 2019-09-18 14:22 UTC (permalink / raw)
To: jic23
Cc: benjamin.gaignard, alexandre.torgue, linux-iio, patrick.havelange,
linux-kernel, William Breathitt Gray, mcoquelin.stm32,
fabrice.gasnier, linux-stm32, linux-arm-kernel
In-Reply-To: <cover.1568816248.git.vilhelm.gray@gmail.com>
Count data is now always represented as an unsigned integer, while
Signal data is either SIGNAL_LOW or SIGNAL_HIGH.
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
---
Documentation/driver-api/generic-counter.rst | 22 +++++++-------------
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/Documentation/driver-api/generic-counter.rst b/Documentation/driver-api/generic-counter.rst
index 8382f01a53e3..161652fc1025 100644
--- a/Documentation/driver-api/generic-counter.rst
+++ b/Documentation/driver-api/generic-counter.rst
@@ -39,10 +39,7 @@ There are three core components to a counter:
COUNT
-----
A Count represents the count data for a set of Signals. The Generic
-Counter interface provides the following available count data types:
-
-* COUNT_POSITION:
- Unsigned integer value representing position.
+Counter interface represents the count data as an unsigned integer.
A Count has a count function mode which represents the update behavior
for the count data. The Generic Counter interface provides the following
@@ -93,19 +90,16 @@ SIGNAL
A Signal represents a counter input data; this is the input data that is
evaluated by the counter to determine the count data; e.g. a quadrature
signal output line of a rotary encoder. Not all counter devices provide
-user access to the Signal data.
-
-The Generic Counter interface provides the following available signal
-data types for when the Signal data is available for user access:
+user access to the Signal data, so exposure is optional for drivers.
-* SIGNAL_LEVEL:
- Signal line state level. The following states are possible:
+When the Signal data is available for user access, the Generic Counter
+interface provides the following available signal values:
- - SIGNAL_LEVEL_LOW:
- Signal line is in a low state.
+* SIGNAL_LOW:
+ Signal line is in a low state.
- - SIGNAL_LEVEL_HIGH:
- Signal line is in a high state.
+* SIGNAL_HIGH:
+ Signal line is in a high state.
A Signal may be associated with one or more Counts.
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 5/6] media: sun4i: Add H3 deinterlace driver
From: Maxime Ripard @ 2019-09-18 14:30 UTC (permalink / raw)
To: Jernej Škrabec
Cc: mark.rutland, devicetree, linux-sunxi, linux-kernel, hverkuil,
wens, robh+dt, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <3227980.eWD6USAIP4@jernej-laptop>
[-- Attachment #1.1: Type: text/plain, Size: 2967 bytes --]
Hi,
On Sat, Sep 14, 2019 at 08:42:22AM +0200, Jernej Škrabec wrote:
> Dne četrtek, 12. september 2019 ob 22:26:47 CEST je Maxime Ripard napisal(a):
> > Hi,
> >
> > On Thu, Sep 12, 2019 at 07:51:31PM +0200, Jernej Skrabec wrote:
> > > + dev->regmap = devm_regmap_init_mmio(dev->dev, dev->base,
> > > +
> &deinterlace_regmap_config);
> > > + if (IS_ERR(dev->regmap)) {
> > > + dev_err(dev->dev, "Couldn't create deinterlace
> regmap\n");
> > > +
> > > + return PTR_ERR(dev->regmap);
> > > + }
> > > +
> > > + ret = clk_prepare_enable(dev->bus_clk);
> > > + if (ret) {
> > > + dev_err(dev->dev, "Failed to enable bus clock\n");
> > > +
> > > + return ret;
> > > + }
> >
> > Do you need to keep the bus clock enabled all the time? Usually, for
> > the SoCs that have a reset line, you only need it to read / write to
> > the registers, not to have the controller actually running.
> >
> > If you don't, then regmap_init_mmio_clk will take care of that for
> > you.
> >
> > > + clk_set_rate(dev->mod_clk, 300000000);
> > > +
> > > + ret = clk_prepare_enable(dev->mod_clk);
> > > + if (ret) {
> > > + dev_err(dev->dev, "Failed to enable mod clock\n");
> > > +
> > > + goto err_bus_clk;
> > > + }
> > > +
> > > + ret = clk_prepare_enable(dev->ram_clk);
> > > + if (ret) {
> > > + dev_err(dev->dev, "Failed to enable ram clock\n");
> > > +
> > > + goto err_mod_clk;
> > > + }
> > > +
> > > + ret = reset_control_reset(dev->rstc);
> > > + if (ret) {
> > > + dev_err(dev->dev, "Failed to apply reset\n");
> > > +
> > > + goto err_ram_clk;
> > > + }
> >
> > This could be moved to a runtime_pm hook, with get_sync called in the
> > open. That way you won't leave the device powered on if it's unused.
>
> Currently I'm looking at sun4i_csi.c as an example of runtime ops, but it
> seems a bit wrong to have suspend and resume function marked with
> __maybe_unused because they are the only functions which enable needed clocks.
> If CONFIG_PM is not enabled, then this driver simply won't work, because
> clocks will never get enabled. I guess I can implement runtime pm ops in the
> same way and add additional handling when CONFIG_PM is not enabled, right?
Ah, right. I guess you can either add a depends on PM, or you can call
the function directly and use set_active like we're doing in the SPI
driver.
> BTW, which callback is get_sync? I don't see it in dev_pm_ops. I suppose I
> need only runtime_suspend and runtime_resume.
get_sync is the user facing API, ie what you call when you want the
device to be powered up. This will call runtime_resume if needed
(there were no users, and you become the first one), and on the parent
devices if needed too (even though it's not our case).
> Off topic: sun6i_csi.c includes linux/pm_runtime.h but it doesn't have any kind
> of power management as far as I can see.
That's probably something we can remove then
Thanks!
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 4/9] ASoC: wm8994: Add support for MCLKn clock gating
From: Charles Keepax @ 2019-09-18 14:31 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, alsa-devel, linux-samsung-soc, b.zolnierkie, sbkim73,
patches, broonie, lgirdwood, krzk, robh+dt, linux-arm-kernel,
m.szyprowski
In-Reply-To: <20190918104634.15216-5-s.nawrocki@samsung.com>
On Wed, Sep 18, 2019 at 12:46:29PM +0200, Sylwester Nawrocki wrote:
> As an intermediate step before covering the clocking subsystem
> of the CODEC entirely by the clk API add handling of external CODEC's
> master clocks in DAPM events when the AIFn clocks are sourced directly
> from MCLKn; when FLLn are used we enable/disable respective MCLKn
> before/after FLLn is enabled/disabled.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
> @@ -2260,8 +2321,28 @@ static int _wm8994_set_fll(struct snd_soc_component *component, int id, int src,
> /* Clear any pending completion from a previous failure */
> try_wait_for_completion(&wm8994->fll_locked[id]);
>
> + switch (src) {
> + case WM8994_FLL_SRC_MCLK1:
> + mclk = control->mclk[0].clk;
> + break;
> + case WM8994_FLL_SRC_MCLK2:
> + mclk = control->mclk[1].clk;
> + break;
> + default:
> + mclk = NULL;
> + }
> +
> /* Enable (with fractional mode if required) */
> if (freq_out) {
> + if (mclk) {
> + ret = clk_prepare_enable(mclk);
> + if (ret < 0) {
> + dev_err(component->dev,
> + "Failed to enable MCLK for FLL%d\n",
> + id + 1);
> + return ret;
> + }
> + }
> /* Enable VMID if we need it */
> if (!was_enabled) {
> active_reference(component);
> @@ -2315,6 +2396,8 @@ static int _wm8994_set_fll(struct snd_soc_component *component, int id, int src,
>
> active_dereference(component);
> }
> + if (mclk)
> + clk_disable_unprepare(mclk);
I don't think this works in the case of changing active FLLs.
The driver looks like it allows changing the FLL configuration
whilst the FLL is already active in which case it you would have
two wm8994_set_fll calls enabling the FLL but only a single one
disabling it. Resulting in the FLL being off but the MCLK being
left enabled.
Thanks,
Charles
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 5/9] ASoC: samsung: arndale: Simplify DAI link initialization
From: Charles Keepax @ 2019-09-18 14:33 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, alsa-devel, linux-samsung-soc, b.zolnierkie, sbkim73,
patches, broonie, lgirdwood, krzk, robh+dt, linux-arm-kernel,
m.szyprowski
In-Reply-To: <20190918104634.15216-6-s.nawrocki@samsung.com>
On Wed, Sep 18, 2019 at 12:46:30PM +0200, Sylwester Nawrocki wrote:
> There is only one DAI link so we can drop an unnecessary loop statement.
> Use card->dai_link in place of direct static arndale_rt5631_dai[] array
> dereference as a prerequisite for adding support for other CODECs.
> Unnecessary assignment of dai_link->codecs->name to NULL is removed.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Thanks,
Charles
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* printk() + memory offline deadlock (WAS Re: page_alloc.shuffle=1 + CONFIG_PROVE_LOCKING=y = arm64 hang)
From: Qian Cai @ 2019-09-18 14:39 UTC (permalink / raw)
To: Steven Rostedt
Cc: Petr Mladek, Theodore Ts'o, Sergey Senozhatsky, Arnd Bergmann,
Peter Zijlstra, Catalin Marinas, linux-kernel, linux-mm,
Greg Kroah-Hartman, Waiman Long, Dan Williams, Will Deacon,
Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20190916104239.124fc2e5@gandalf.local.home>
On Mon, 2019-09-16 at 10:42 -0400, Steven Rostedt wrote:
> On Thu, 12 Sep 2019 08:05:41 -0400
> Qian Cai <cai@lca.pw> wrote:
>
> > > drivers/char/random.c | 7 ++++---
> > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/char/random.c b/drivers/char/random.c
> > > index 9b54cdb301d3..975015857200 100644
> > > --- a/drivers/char/random.c
> > > +++ b/drivers/char/random.c
> > > @@ -1687,8 +1687,9 @@ static void _warn_unseeded_randomness(const char *func_name, void *caller,
> > > print_once = true;
> > > #endif
> > > if (__ratelimit(&unseeded_warning))
> > > - pr_notice("random: %s called from %pS with crng_init=%d\n",
> > > - func_name, caller, crng_init);
> > > + printk_deferred(KERN_NOTICE "random: %s called from %pS "
> > > + "with crng_init=%d\n", func_name, caller,
> > > + crng_init);
> > > }
> > >
> > > /*
> > > @@ -2462,4 +2463,4 @@ void add_bootloader_randomness(const void *buf, unsigned int size)
> > > else
> > > add_device_randomness(buf, size);
> > > }
> > > -EXPORT_SYMBOL_GPL(add_bootloader_randomness);
> > > \ No newline at end of file
> > > +EXPORT_SYMBOL_GPL(add_bootloader_randomness);
> >
> > This will also fix the hang.
> >
> > Sergey, do you plan to submit this Ted?
>
> Perhaps for a quick fix (and a comment that says this needs to be fixed
> properly). I think the changes to printk() that was discussed at
> Plumbers may also solve this properly.
I assume that the new printk() stuff will also fix this deadlock between
printk() and memory offline.
[ 317.337595] WARNING: possible circular locking dependency detected
[ 317.337596] 5.3.0-next-20190917+ #9 Not tainted
[ 317.337597] ------------------------------------------------------
[ 317.337597] test.sh/8738 is trying to acquire lock:
[ 317.337598] ffffffffb33a4978 ((console_sem).lock){-.-.}, at:
down_trylock+0x16/0x50
[ 317.337602] but task is already holding lock:
[ 317.337602] ffff88883fff4318 (&(&zone->lock)->rlock){-.-.}, at:
start_isolate_page_range+0x1f7/0x570
[ 317.337606] which lock already depends on the new lock.
[ 317.337608] the existing dependency chain (in reverse order) is:
[ 317.337609] -> #3 (&(&zone->lock)->rlock){-.-.}:
[ 317.337612] __lock_acquire+0x5b3/0xb40
[ 317.337613] lock_acquire+0x126/0x280
[ 317.337613] _raw_spin_lock+0x2f/0x40
[ 317.337614] rmqueue_bulk.constprop.21+0xb6/0x1160
[ 317.337615] get_page_from_freelist+0x898/0x22c0
[ 317.337616] __alloc_pages_nodemask+0x2f3/0x1cd0
[ 317.337617] alloc_page_interleave+0x18/0x130
[ 317.337618] alloc_pages_current+0xf6/0x110
[ 317.337619] allocate_slab+0x4c6/0x19c0
[ 317.337620] new_slab+0x46/0x70
[ 317.337621] ___slab_alloc+0x58b/0x960
[ 317.337621] __slab_alloc+0x43/0x70
[ 317.337622] kmem_cache_alloc+0x354/0x460
[ 317.337623] fill_pool+0x272/0x4b0
[ 317.337624] __debug_object_init+0x86/0x790
[ 317.337624] debug_object_init+0x16/0x20
[ 317.337625] hrtimer_init+0x27/0x1e0
[ 317.337626] init_dl_task_timer+0x20/0x40
[ 317.337627] __sched_fork+0x10b/0x1f0
[ 317.337627] init_idle+0xac/0x520
[ 317.337628] idle_thread_get+0x7c/0xc0
[ 317.337629] bringup_cpu+0x1a/0x1e0
[ 317.337630] cpuhp_invoke_callback+0x197/0x1120
[ 317.337630] _cpu_up+0x171/0x280
[ 317.337631] do_cpu_up+0xb1/0x120
[ 317.337632] cpu_up+0x13/0x20
[ 317.337632] smp_init+0xa4/0x12d
[ 317.337633] kernel_init_freeable+0x37e/0x76e
[ 317.337634] kernel_init+0x11/0x12f
[ 317.337635] ret_from_fork+0x3a/0x50
[ 317.337635] -> #2 (&rq->lock){-.-.}:
[ 317.337638] __lock_acquire+0x5b3/0xb40
[ 317.337639] lock_acquire+0x126/0x280
[ 317.337639] _raw_spin_lock+0x2f/0x40
[ 317.337640] task_fork_fair+0x43/0x200
[ 317.337641] sched_fork+0x29b/0x420
[ 317.337642] copy_process+0xf3c/0x2fd0
[ 317.337642] _do_fork+0xef/0x950
[ 317.337643] kernel_thread+0xa8/0xe0
[ 317.337644] rest_init+0x28/0x311
[ 317.337645] arch_call_rest_init+0xe/0x1b
[ 317.337645] start_kernel+0x6eb/0x724
[ 317.337646] x86_64_start_reservations+0x24/0x26
[ 317.337647] x86_64_start_kernel+0xf4/0xfb
[ 317.337648] secondary_startup_64+0xb6/0xc0
[ 317.337649] -> #1 (&p->pi_lock){-.-.}:
[ 317.337651] __lock_acquire+0x5b3/0xb40
[ 317.337652] lock_acquire+0x126/0x280
[ 317.337653] _raw_spin_lock_irqsave+0x3a/0x50
[ 317.337653] try_to_wake_up+0xb4/0x1030
[ 317.337654] wake_up_process+0x15/0x20
[ 317.337655] __up+0xaa/0xc0
[ 317.337655] up+0x55/0x60
[ 317.337656] __up_console_sem+0x37/0x60
[ 317.337657] console_unlock+0x3a0/0x750
[ 317.337658] vprintk_emit+0x10d/0x340
[ 317.337658] vprintk_default+0x1f/0x30
[ 317.337659] vprintk_func+0x44/0xd4
[ 317.337660] printk+0x9f/0xc5
[ 317.337660] crng_reseed+0x3cc/0x440
[ 317.337661] credit_entropy_bits+0x3e8/0x4f0
[ 317.337662] random_ioctl+0x1eb/0x250
[ 317.337663] do_vfs_ioctl+0x13e/0xa70
[ 317.337663] ksys_ioctl+0x41/0x80
[ 317.337664] __x64_sys_ioctl+0x43/0x4c
[ 317.337665] do_syscall_64+0xcc/0x76c
[ 317.337666] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 317.337667] -> #0 ((console_sem).lock){-.-.}:
[ 317.337669] check_prev_add+0x107/0xea0
[ 317.337670] validate_chain+0x8fc/0x1200
[ 317.337671] __lock_acquire+0x5b3/0xb40
[ 317.337671] lock_acquire+0x126/0x280
[ 317.337672] _raw_spin_lock_irqsave+0x3a/0x50
[ 317.337673] down_trylock+0x16/0x50
[ 317.337674] __down_trylock_console_sem+0x2b/0xa0
[ 317.337675] console_trylock+0x16/0x60
[ 317.337676] vprintk_emit+0x100/0x340
[ 317.337677] vprintk_default+0x1f/0x30
[ 317.337678] vprintk_func+0x44/0xd4
[ 317.337678] printk+0x9f/0xc5
[ 317.337679] __dump_page.cold.2+0x73/0x210
[ 317.337680] dump_page+0x12/0x50
[ 317.337680] has_unmovable_pages+0x3e9/0x4b0
[ 317.337681] start_isolate_page_range+0x3b4/0x570
[ 317.337682] __offline_pages+0x1ad/0xa10
[ 317.337683] offline_pages+0x11/0x20
[ 317.337683] memory_subsys_offline+0x7e/0xc0
[ 317.337684] device_offline+0xd5/0x110
[ 317.337685] state_store+0xc6/0xe0
[ 317.337686] dev_attr_store+0x3f/0x60
[ 317.337686] sysfs_kf_write+0x89/0xb0
[ 317.337687] kernfs_fop_write+0x188/0x240
[ 317.337688] __vfs_write+0x50/0xa0
[ 317.337688] vfs_write+0x105/0x290
[ 317.337689] ksys_write+0xc6/0x160
[ 317.337690] __x64_sys_write+0x43/0x50
[ 317.337691] do_syscall_64+0xcc/0x76c
[ 317.337691] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 317.337693] other info that might help us debug this:
[ 317.337694] Chain exists of:
[ 317.337694] (console_sem).lock --> &rq->lock --> &(&zone->lock)->rlock
[ 317.337699] Possible unsafe locking scenario:
[ 317.337700] CPU0 CPU1
[ 317.337701] ---- ----
[ 317.337701] lock(&(&zone->lock)->rlock);
[ 317.337703] lock(&rq->lock);
[ 317.337705] lock(&(&zone->lock)->rlock);
[ 317.337706] lock((console_sem).lock);
[ 317.337708] *** DEADLOCK ***
[ 317.337710] 8 locks held by test.sh/8738:
[ 317.337710] #0: ffff8883940b5408 (sb_writers#4){.+.+}, at:
vfs_write+0x25f/0x290
[ 317.337713] #1: ffff889fce310280 (&of->mutex){+.+.}, at:
kernfs_fop_write+0x128/0x240
[ 317.337716] #2: ffff889feb6d4830 (kn->count#115){.+.+}, at:
kernfs_fop_write+0x138/0x240
[ 317.337720] #3: ffffffffb3762d40 (device_hotplug_lock){+.+.}, at:
lock_device_hotplug_sysfs+0x16/0x50
[ 317.337723] #4: ffff88981f0dc990 (&dev->mutex){....}, at:
device_offline+0x70/0x110
[ 317.337726] #5: ffffffffb3315250 (cpu_hotplug_lock.rw_sem){++++}, at:
__offline_pages+0xbf/0xa10
[ 317.337729] #6: ffffffffb35408b0 (mem_hotplug_lock.rw_sem){++++}, at:
percpu_down_write+0x87/0x2f0
[ 317.337732] #7: ffff88883fff4318 (&(&zone->lock)->rlock){-.-.}, at:
start_isolate_page_range+0x1f7/0x570
[ 317.337736] stack backtrace:
[ 317.337737] CPU: 58 PID: 8738 Comm: test.sh Not tainted 5.3.0-next-20190917+
#9
[ 317.337738] Hardware name: HPE ProLiant DL560 Gen10/ProLiant DL560 Gen10,
BIOS U34 05/21/2019
[ 317.337739] Call Trace:
[ 317.337739] dump_stack+0x86/0xca
[ 317.337740] print_circular_bug.cold.31+0x243/0x26e
[ 317.337741] check_noncircular+0x29e/0x2e0
[ 317.337742] ? debug_lockdep_rcu_enabled+0x4b/0x60
[ 317.337742] ? print_circular_bug+0x120/0x120
[ 317.337743] ? is_ftrace_trampoline+0x9/0x20
[ 317.337744] ? kernel_text_address+0x59/0xc0
[ 317.337744] ? __kernel_text_address+0x12/0x40
[ 317.337745] check_prev_add+0x107/0xea0
[ 317.337746] validate_chain+0x8fc/0x1200
[ 317.337746] ? check_prev_add+0xea0/0xea0
[ 317.337747] ? format_decode+0xd6/0x600
[ 317.337748] ? file_dentry_name+0xe0/0xe0
[ 317.337749] __lock_acquire+0x5b3/0xb40
[ 317.337749] lock_acquire+0x126/0x280
[ 317.337750] ? down_trylock+0x16/0x50
[ 317.337751] ? vprintk_emit+0x100/0x340
[ 317.337752] _raw_spin_lock_irqsave+0x3a/0x50
[ 317.337753] ? down_trylock+0x16/0x50
[ 317.337753] down_trylock+0x16/0x50
[ 317.337754] ? vprintk_emit+0x100/0x340
[ 317.337755] __down_trylock_console_sem+0x2b/0xa0
[ 317.337756] console_trylock+0x16/0x60
[ 317.337756] vprintk_emit+0x100/0x340
[ 317.337757] vprintk_default+0x1f/0x30
[ 317.337758] vprintk_func+0x44/0xd4
[ 317.337758] printk+0x9f/0xc5
[ 317.337759] ? kmsg_dump_rewind_nolock+0x64/0x64
[ 317.337760] ? __dump_page+0x1d7/0x430
[ 317.337760] __dump_page.cold.2+0x73/0x210
[ 317.337761] dump_page+0x12/0x50
[ 317.337762] has_unmovable_pages+0x3e9/0x4b0
[ 317.337763] start_isolate_page_range+0x3b4/0x570
[ 317.337763] ? unset_migratetype_isolate+0x280/0x280
[ 317.337764] ? rcu_read_lock_bh_held+0xc0/0xc0
[ 317.337765] __offline_pages+0x1ad/0xa10
[ 317.337765] ? lock_acquire+0x126/0x280
[ 317.337766] ? __add_memory+0xc0/0xc0
[ 317.337767] ? __kasan_check_write+0x14/0x20
[ 317.337767] ? __mutex_lock+0x344/0xcd0
[ 317.337768] ? _raw_spin_unlock_irqrestore+0x49/0x50
[ 317.337769] ? device_offline+0x70/0x110
[ 317.337770] ? klist_next+0x1c1/0x1e0
[ 317.337770] ? __mutex_add_waiter+0xc0/0xc0
[ 317.337771] ? klist_next+0x10b/0x1e0
[ 317.337772] ? klist_iter_exit+0x16/0x40
[ 317.337772] ? device_for_each_child+0xd0/0x110
[ 317.337773] offline_pages+0x11/0x20
[ 317.337774] memory_subsys_offline+0x7e/0xc0
[ 317.337774] device_offline+0xd5/0x110
[ 317.337775] ? auto_online_blocks_show+0x70/0x70
[ 317.337776] state_store+0xc6/0xe0
[ 317.337776] dev_attr_store+0x3f/0x60
[ 317.337777] ? device_match_name+0x40/0x40
[ 317.337778] sysfs_kf_write+0x89/0xb0
[ 317.337778] ? sysfs_file_ops+0xa0/0xa0
[ 317.337779] kernfs_fop_write+0x188/0x240
[ 317.337780] __vfs_write+0x50/0xa0
[ 317.337780] vfs_write+0x105/0x290
[ 317.337781] ksys_write+0xc6/0x160
[ 317.337782] ? __x64_sys_read+0x50/0x50
[ 317.337782] ? do_syscall_64+0x79/0x76c
[ 317.337783] ? do_syscall_64+0x79/0x76c
[ 317.337784] __x64_sys_write+0x43/0x50
[ 317.337784] do_syscall_64+0xcc/0x76c
[ 317.337785] ? trace_hardirqs_on_thunk+0x1a/0x20
[ 317.337786] ? syscall_return_slowpath+0x210/0x210
[ 317.337787] ? entry_SYSCALL_64_after_hwframe+0x3e/0xbe
[ 317.337787] ? trace_hardirqs_off_caller+0x3a/0x150
[ 317.337788] ? trace_hardirqs_off_thunk+0x1a/0x20
[ 317.337789] entry_SYSCALL_64_after_hwframe+0x49/0xbe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] pwm: atmel: Remove platform_device_id and use only dt bindings
From: Alexandre Belloni @ 2019-09-18 14:40 UTC (permalink / raw)
To: Kamel Bouhara
Cc: linux-pwm, Gregory Clement, linux-kernel, Ludovic Desroches,
Thierry Reding, Claudiu Beznea, linux-arm-kernel
In-Reply-To: <20190918140534.23365-1-kamel.bouhara@bootlin.com>
Hi,
On 18/09/2019 16:05:34+0200, Kamel Bouhara wrote:
> Since commit 26202873bb51 ("avr32: remove support for AVR32
> architecture") there is no more user of platform_device_id and we
> should only use dt bindings
>
> Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
> ---
> drivers/pwm/Kconfig | 2 +-
> drivers/pwm/pwm-atmel.c | 29 +++--------------------------
> 2 files changed, 4 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index a7e57516959e..b51fb1a33aa2 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -44,7 +44,7 @@ config PWM_AB8500
>
> config PWM_ATMEL
> tristate "Atmel PWM support"
> - depends on ARCH_AT91
> + depends on ARCH_AT91 && OF
> help
> Generic PWM framework driver for Atmel SoC.
>
> diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> index e5e1eaf372fa..a3d93d634462 100644
> --- a/drivers/pwm/pwm-atmel.c
> +++ b/drivers/pwm/pwm-atmel.c
> @@ -318,19 +318,6 @@ static const struct atmel_pwm_data mchp_sam9x60_pwm_data = {
> },
> };
>
> -static const struct platform_device_id atmel_pwm_devtypes[] = {
> - {
> - .name = "at91sam9rl-pwm",
> - .driver_data = (kernel_ulong_t)&atmel_sam9rl_pwm_data,
> - }, {
> - .name = "sama5d3-pwm",
> - .driver_data = (kernel_ulong_t)&atmel_sama5_pwm_data,
> - }, {
> - /* sentinel */
> - },
> -};
> -MODULE_DEVICE_TABLE(platform, atmel_pwm_devtypes);
> -
> static const struct of_device_id atmel_pwm_dt_ids[] = {
> {
> .compatible = "atmel,at91sam9rl-pwm",
> @@ -353,14 +340,7 @@ MODULE_DEVICE_TABLE(of, atmel_pwm_dt_ids);
> static inline const struct atmel_pwm_data *
> atmel_pwm_get_driver_data(struct platform_device *pdev)
> {
> - const struct platform_device_id *id;
> -
> - if (pdev->dev.of_node)
> - return of_device_get_match_data(&pdev->dev);
> -
> - id = platform_get_device_id(pdev);
> -
> - return (struct atmel_pwm_data *)id->driver_data;
> + return of_device_get_match_data(&pdev->dev);
The whole function is gone so you could simply call
of_device_get_match_data from atmel_pwm_probe.
> }
>
> static int atmel_pwm_probe(struct platform_device *pdev)
> @@ -396,10 +376,8 @@ static int atmel_pwm_probe(struct platform_device *pdev)
> atmel_pwm->chip.dev = &pdev->dev;
> atmel_pwm->chip.ops = &atmel_pwm_ops;
>
> - if (pdev->dev.of_node) {
> - atmel_pwm->chip.of_xlate = of_pwm_xlate_with_flags;
> - atmel_pwm->chip.of_pwm_n_cells = 3;
> - }
> + atmel_pwm->chip.of_xlate = of_pwm_xlate_with_flags;
> + atmel_pwm->chip.of_pwm_n_cells = 3;
>
> atmel_pwm->chip.base = -1;
> atmel_pwm->chip.npwm = 4;
> @@ -437,7 +415,6 @@ static struct platform_driver atmel_pwm_driver = {
> .name = "atmel-pwm",
> .of_match_table = of_match_ptr(atmel_pwm_dt_ids),
> },
> - .id_table = atmel_pwm_devtypes,
> .probe = atmel_pwm_probe,
> .remove = atmel_pwm_remove,
> };
> --
> 2.23.0
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx6dl: SolidRun: add phy node with 100Mb/s max-speed
From: tinywrkb @ 2019-09-18 14:45 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Mark Rutland, Andrew Lunn, Baruch Siach,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Shawn Guo, Sascha Hauer, open list, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam, linux-arm-kernel
In-Reply-To: <20190917224347.GD25745@shell.armlinux.org.uk>
On Tue, Sep 17, 2019 at 11:43:47PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Sep 17, 2019 at 11:30:13PM +0100, Russell King - ARM Linux admin wrote:
> > On Tue, Sep 17, 2019 at 04:32:53PM +0300, tinywrkb wrote:
> > > Here's the output of # mii-tool -v -v eth0
> > >
> > > * linux-test-5.1rc1-a2703de70942-without_bad_commit
> > >
> > > Using SIOCGMIIPHY=0x8947
> > > eth0: negotiated 100baseTx-FD flow-control, link ok
> > > registers for MII PHY 0:
> > > 3100 796d 004d d072 15e1 c5e1 000f 0000
> > > 0000 0000 0800 0000 0000 0000 0000 a000
> > > 0000 0000 0000 f420 082c 0000 04e8 0000
> > > 3200 3000 0000 063d 0000 0000 0000 0000
> >
> > I'll also mention some other discrepencies that I've just spotted in
> > this register set.
> >
> > The BMSR is 0x796d. Bit 2 is the link status, which is indicating
> > that link is up. Bit 5 indicates negotiation complete, which it
> > claims it is.
> >
> > The PHY has a second status register at 0x11 which gives real time
> > information. That is 0x0000. Bit 10 indicates link up, and is
> > indicating that the link is down. Bit 11 is saying that the speed
> > and duplex is not resolved either.
> >
> > So, there's contradictory information being reported by this PHY.
> >
> > This brings up several questions:
> > 1. what is the _true_ state of the link? Is the link up or down?
> >
> > 2. what does the link partner think is the current link state and
> > results of negotiation?
> >
> > 3. should we be reading the register at 0x11 to determine the
> > negotiation results and link state (maybe logically anding the
> > present state with the BMSR link state)?
> >
> >
> > Compare that to a correctly functioning AR8035 such as I have in my
> > cubox-i4 connected to a Netgear GS116 switch:
> >
> > 3100 796d 004d d072 15e1 c5e1 000d 2001
> > 0000 0200 3c00 0000 0000 4007 b29a a000
> > 0862 bc1c 0000 0000 082c 0000 07e8 0000
> > 3200 3000 0000 063e 0000 0005 2d47 8100.
My Cubox-i4 (no issue getting an IP address and GbE) is connected to the
same switch as the Cubox-i2 (the one affected by this bug).
mii-tool output for my Cubox-i4:
Using SIOCGMIIPHY=0x8947
eth0: negotiated 1000baseT-FD flow-control, link ok
registers for MII PHY 4:
3100 796d 004d d072 15e1 c5e1 000d 0000
0000 0200 3800 0000 0000 0000 0000 a000
0000 0000 0000 0000 082c 0000 04e8 0000
3200 3000 0000 063e 0000 0000 0000 0000
product info: vendor 00:13:74, model 7 rev 2
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> >
> > BMSR is again 0x796d. The PHY specific status register this time
> > is 0xbc1c, which indicates 1G, full duplex, resolved, link up, no
> > smartspeed downgrade, tx/rx pause.
> >
> > The register at 0x10 is a control register, which is strangely also
> > different between our two. Apparently in your PHY configuration,
> > auto-MDI crossover mode is disabled, you are forced to MDI mode.
> > On hardware reset, this register contains 0x0862, as per my
> > example above, but yours is zero.
> >
> > I don't think the difference in register 0x10 can be explained away
> > by operation of the smartspeed feature - so maybe my theory about
> > the advertisement registers being cleared by the PHY is wrong. The
> > question is: how is 0x10 getting reset to zero in your setup? Maybe
> > something has corrupted the configuration of the PHY in ways that
> > Linux doesn't know how to reprogram?
> >
> > Have you tried power-cycling the cubox-i?
Yes, it doesn't help.
>
> Hopefully one last thing, which will explain why you may not be able
> to get an IP address even with some of these tweaks I've been getting
> you to try. Do you have either none or both of these commits in your
> kernel?
>
> 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode")
> 6d4cd041f0af ("net: phy: at803x: disable delay only for RGMII mode")
>
> I think you'll have the latter but not the former. You will need the
> former if you have the latter.
>
I was checked-out at 5502b218e001 ("net: phy: use
phy_resolve_aneg_linkmode in genphy_read_status") so I was missing both.
> Could you try this patch instead - it seems that the PHY needs to be
> soft-reset for the write to take effect, and _even_ for the clearance
> of the bit to become visible in the register.
>
> I'm not expecting this on its own to solve anything, but it should at
> least mean that the at803x doesn't modify the advertisement registers
> itself. It may mean that the link doesn't even come up without forcing
> the advertisement via the ethtool command I mentioned before.
>
> Thanks.
>
> drivers/net/phy/at803x.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
> index b3893347804d..69a58c0e6b42 100644
> --- a/drivers/net/phy/at803x.c
> +++ b/drivers/net/phy/at803x.c
> @@ -296,6 +296,16 @@ static int at803x_config_init(struct phy_device *phydev)
> if (ret < 0)
> return ret;
>
> + /* Disable smartspeed */
> + ret = phy_modify(phydev, 0x14, BIT(5), 0);
> + if (ret < 0)
> + return ret;
> +
> + /* Must soft-reset the PHY for smartspeed disable to take effect */
> + ret = genphy_soft_reset(phydev);
With the smartspeed disabled + soft reset patch against v5.1-rc1 +
cherry-pick the missing 0672d22a1924 ("ARM: dts: imx: Fix the AR803X
phy-mode") I'm finally getting an IP address.
Note that I do need the genphy soft reset without it I don't get an IP
address.
Also tested v5.3 with the patch and it does work.
I'm adding the output for v5.3 with this patch.
# mii-tool -v -v eth0
Using SIOCGMIIPHY=0x8947
eth0: negotiated 100baseTx-FD flow-control, link ok
registers for MII PHY 0:
3100 796d 004d d072 15e1 45e1 0007 0000
0000 0200 0000 0000 0000 0000 0000 a000
0000 0000 0000 f400 080c 0000 04e8 0000
3200 3000 0000 063d 0000 0000 0000 0000
product info: vendor 00:13:74, model 7 rev 2
basic mode: autonegotiation enabled
basic status: autonegotiation complete, link ok
capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
1000baseX/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
1000baseX/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Link detected: yes
# journalctl -b | egrep -i 'phy|eth|fec'|grep -v usb
kernel: Booting Linux on physical CPU 0x0
kernel: libphy: Fixed MDIO Bus: probed
kernel: libphy: fec_enet_mii_bus: probed
kernel: fec 2188000.ethernet eth0: registered PHC device 0
kernel: Atheros 8035 ethernet 2188000.ethernet-1:00: attached PHY driver [Atheros 8035 ethernet] (mii_bus:phy_addr=2188000.ethernet-1:00, irq=POLL)
kernel: Atheros 8035 ethernet 2188000.ethernet-1:00: PHY advertising (00,00000200,000022ef) more modes than genphy supports, some modes not advertised.
kernel: fec 2188000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
systemd-networkd[364]: eth0: Gained carrier
systemd-networkd[364]: eth0: DHCPv4 address 192.168.15.101/24 via 192.168.15.1
systemd-networkd[364]: eth0: Gained IPv6LL
systemd-networkd[364]: eth0: Configured
> I think this thread is a good illustration why breaking existing DT
> compatibility - even for the sake of fixing a bug - is just bad news.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 7/9] ASoC: samsung: arndale: Add support for WM1811 CODEC
From: Charles Keepax @ 2019-09-18 14:45 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, alsa-devel, linux-samsung-soc, b.zolnierkie, sbkim73,
patches, broonie, lgirdwood, krzk, robh+dt, linux-arm-kernel,
m.szyprowski
In-Reply-To: <20190918104634.15216-8-s.nawrocki@samsung.com>
On Wed, Sep 18, 2019 at 12:46:32PM +0200, Sylwester Nawrocki wrote:
> The Arndale boards come with different types of the audio daughter
> board. In order to support the WM1811 one we add new definition of
> an ASoC card which will be registered when the driver matches on
> "samsung,arndale-wm1811" compatible. There is no runtime detection of
> the audio daughter board type at the moment, compatible string of the
> audio card needs to be adjusted in DT, e.g. by the bootloader,
> depending on actual audio board (CODEC) used.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
> -static const struct of_device_id samsung_arndale_rt5631_of_match[] __maybe_unused = {
> - { .compatible = "samsung,arndale-rt5631", },
> - { .compatible = "samsung,arndale-alc5631", },
> +static const struct of_device_id arndale_audio_of_match[] __maybe_unused = {
If your removing the of_match_ptr below I think the
__maybe_unused should be removed as well.
Thanks,
Charles
> + { .compatible = "samsung,arndale-rt5631", .data = &arndale_rt5631 },
> + { .compatible = "samsung,arndale-alc5631", .data = &arndale_rt5631 },
> + { .compatible = "samsung,arndale-wm1811", .data = &arndale_wm1811 },
> {},
> };
> -MODULE_DEVICE_TABLE(of, samsung_arndale_rt5631_of_match);
> +MODULE_DEVICE_TABLE(of, arndale_of_match);
>
> static struct platform_driver arndale_audio_driver = {
> .driver = {
> - .name = "arndale-audio",
> + .name = "arndale-audio",
> .pm = &snd_soc_pm_ops,
> - .of_match_table = of_match_ptr(samsung_arndale_rt5631_of_match),
> + .of_match_table = arndale_audio_of_match,
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: allwinner: a64: pine64-plus: Add PHY regulator delay
From: Maxime Ripard @ 2019-09-18 14:46 UTC (permalink / raw)
To: Jernej Skrabec
Cc: mark.rutland, devicetree, Ondrej Jirman, linux-sunxi,
linux-kernel, wens, robh+dt, linux-arm-kernel
In-Reply-To: <20190909184235.13196-1-jernej.skrabec@siol.net>
[-- Attachment #1.1: Type: text/plain, Size: 602 bytes --]
On Mon, Sep 09, 2019 at 08:42:35PM +0200, Jernej Skrabec wrote:
> Depending on kernel and bootloader configuration, it's possible that
> Realtek ethernet PHY isn't powered on properly. According to the
> datasheet, it needs 30ms to power up and then some more time before it
> can be used.
>
> Fix that by adding 100ms ramp delay to regulator responsible for
> powering PHY.
>
> Fixes: 94dcfdc77fc5 ("arm64: allwinner: pine64-plus: Enable dwmac-sun8i")
> Suggested-by: Ondrej Jirman <megous@megous.com>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Queued as a fix for 5.4, thanks!
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V6 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Andre Przywara @ 2019-09-18 14:46 UTC (permalink / raw)
To: Jassi Brar
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Peng Fan,
f.fainelli@gmail.com, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx, sudeep.holla@arm.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CABb+yY3drgYHk2_SZMgGhgSisB7wMVKFSx8VVabCcXkGByvgwg@mail.gmail.com>
On Wed, 18 Sep 2019 09:19:46 -0500
Jassi Brar <jassisinghbrar@gmail.com> wrote:
Hi,
> On Wed, Sep 18, 2019 at 4:44 AM Andre Przywara <andre.przywara@arm.com> wrote:
>
> >
> > > which needs 9 arguments to work. The fact that the fist argument is
> > > always going to be same on a platform is just the way we use this
> > > instruction.
> > >
> > > > We should be as strict as possible to avoid any security issues.
> > > >
> > > Any example of such a security issue?
> >
> > Someone finds a way to trick some mailbox client to send a crafted message to the mailbox.
> >
> What if someone finds a way to trick the block layer to erase 'sda' ?
Yes, the Linux block driver control the whole block device, it can do whatever it wants.
The firmware provides an interface for multiple users, and the mailbox controller just uses *one part* of it. So we should make sure that it's the right part.
> That is called "bug in the code".
> It does happen in every subsystem but we don't stop implementing new
> features .... we write flexible code and then fix any bug.
>
>
> > Do you have any example of a use case where the mailbox client needs to provide the function ID?
> >
> FSL_SIP_SCMI_1/2 ?
Huh? Where does the SCPI or SCMI driver provide this? Those clients don't even provide any arguments. Adding some would defeat the whole point of having this mailbox in the first place, which was to provide a drop-in replacement for a hardware mailbox device used on other platforms.
> But that is not the main point, which is to be consistent (not
> ignoring first argument because someone may find a bug to exploit) and
> flexible.
Please read the SMCCC[1]: The first argument is in r1/w1/x1. r0/w0 is the function ID, and this is a specific value (fixed by the firmware implementation, see Peng's ATF patch) and not up to be guessed by a client.
Please keep in mind that we should *NOT* do smc calls without following the SMCCC spec.
> > > > The firmware certainly knows the function ID it implements. The firmware controls the DT. So it is straight-forward to put the ID into the DT. The firmware could even do this at boot time, dynamically, before passing on the DT to the non-secure world (bootloader or kernel).
> > > >
> > > > What would be the use case of this functionality?
> > > >
> > > At least for flexibility and consistency.
> >
> > I appreciate the flexibility idea, but when creating an interface, especially a generic one to any kind of firmware, you should be as strict as possible, to avoid clashes in the future.
> >
> I really don't see how there can be clashes with more complete and
> flexible implementation.
Platform A uses PSCI, but no other SMCCC services, so in your scenario you assign a valid function ID say from the SIP range and tell the mailbox *client* to use it. Now you want to run this client on platform B, which happens to have chosen this very function ID for the "set fire on the device" SMCCC service.
So now you would need to assign different IDs to the *client*, depending on the platform? That doesn't make sense. The solution is that you just assign the function ID to the controller, in the (platform specific) DT, so it naturally matches the platform requirements. You can even change it over time, as long as you change both the DT and firmware at the same time.
The client (SCPI, for instance) is totally ignorant about this communication detail, it just needs some mailbox to request services.
That's why I think the function ID (which is part of the SMCCC protocol, not of the mailbox service!) should just be set in the controller DT node and nowhere else.
Cheers,
Andre.
[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 8/9] ASoC: samsung: arndale: Add missing OF node dereferencing
From: Charles Keepax @ 2019-09-18 14:51 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, alsa-devel, linux-samsung-soc, b.zolnierkie, sbkim73,
patches, broonie, lgirdwood, krzk, robh+dt, linux-arm-kernel,
m.szyprowski
In-Reply-To: <20190918104634.15216-9-s.nawrocki@samsung.com>
On Wed, Sep 18, 2019 at 12:46:33PM +0200, Sylwester Nawrocki wrote:
> Ensure there is no OF node references kept when the driver is removed/unbound.
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Thanks,
Charles
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] pwm: stm32-lp: add check in case requested period cannot be achieved
From: Fabrice Gasnier @ 2019-09-18 14:54 UTC (permalink / raw)
To: thierry.reding
Cc: linux-pwm, alexandre.torgue, linux-kernel, u.kleine-koenig,
fabrice.gasnier, linux-stm32, linux-arm-kernel
LPTimer can use a 32KHz clock for counting. It depends on clock tree
configuration. In such a case, PWM output frequency range is limited.
Although unlikely, nothing prevents user from requesting a PWM frequency
above counting clock (32KHz for instance):
- This causes (prd - 1) = 0xffff to be written in ARR register later in
the apply() routine.
This results in badly configured PWM period (and also duty_cycle).
Add a check to report an error is such a case.
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
---
Changes in v2:
- remarks from Uwe: update the comment, use dev_dbg() and print period that
cannot be reached
---
drivers/pwm/pwm-stm32-lp.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/pwm/pwm-stm32-lp.c b/drivers/pwm/pwm-stm32-lp.c
index 2211a64..97a9afa 100644
--- a/drivers/pwm/pwm-stm32-lp.c
+++ b/drivers/pwm/pwm-stm32-lp.c
@@ -59,6 +59,12 @@ static int stm32_pwm_lp_apply(struct pwm_chip *chip, struct pwm_device *pwm,
/* Calculate the period and prescaler value */
div = (unsigned long long)clk_get_rate(priv->clk) * state->period;
do_div(div, NSEC_PER_SEC);
+ if (!div) {
+ /* Clock is too slow to achieve requested period. */
+ dev_dbg(priv->chip.dev, "Can't reach %u ns\n", state->period);
+ return -EINVAL;
+ }
+
prd = div;
while (div > STM32_LPTIM_MAX_ARR) {
presc++;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox