Re: [RFC PATCH 2/4] mdev: introduce helper to set per device dma ops
On 2019/9/18 上午3:00, Alex Williamson wrote:
On Tue, 10 Sep 2019 16:19:33 +0800
Jason Wang wrote:
This patch introduces mdev_set_dma_ops() which allows parent to set
per device DMA ops. This help for the kernel driver to setup a correct
DMA mappings.
Signed-off-by: Jason Wang
---
drivers/vfio/mdev/mdev_core.c | 7 +++
include/linux/mdev.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index b558d4cfd082..eb28552082d7 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include "mdev_private.h"
@@ -27,6 +28,12 @@ static struct class_compat *mdev_bus_compat_class;
static LIST_HEAD(mdev_list);
static DEFINE_MUTEX(mdev_list_lock);
+void mdev_set_dma_ops(struct mdev_device *mdev, struct dma_map_ops *ops)
+{
+ set_dma_ops(>dev, ops);
+}
+EXPORT_SYMBOL(mdev_set_dma_ops);
+
Why does mdev need to be involved here? Your sample driver in 4/4 calls
this from its create callback, where it could just as easily call:
set_dma_ops(mdev_dev(mdev), ops);
Thanks,
Alex
Yes, let me withdraw this patch.
Thanks
Re: [PATCH v1 2/2] spi: cadence-qspi: Add QSPI support for Intel LGM SoC
Hi Mark, Thank you for the review comments. On 17/9/2019 11:36 PM, Mark Brown wrote: On Tue, Sep 17, 2019 at 10:11:28AM +0800, Ramuthevar, Vadivel MuruganX wrote: * spi-cadence.c* in *drivers/spi/*, which supports very old legacy cadence-spi based devices(normal) * cadence-quadspi.c(drivers/mtd/spi-nor/)* : specific support to SPI-NOR flash with new spi-nor layer. all the API's in this driver purely on spi-nor specific, so couldn't proceed to adapt. Are these completely separate IPs or are they just different versions of the same IP? These are same IPs , but different features Enabled/Disabled depends upon the SoC vendors. for e.g: Intel LGM SoC uses the same IP, but without DMA and Direct access controller. also dedicated support to flash devices. Best regards Vadivel
Re: [PATCH] ionic: Remove unnecessary ternary operator in ionic_debugfs_add_ident
On Tue, Sep 17, 2019 at 04:26:16PM -0700, Nathan Chancellor wrote:
> clang warns:
>
> ../drivers/net/ethernet/pensando/ionic/ionic_debugfs.c:60:37: warning:
> expression result unused [-Wunused-value]
> ionic, _fops) ? 0 : -EOPNOTSUPP;
> ^~~
> 1 warning generated.
>
> The return value of debugfs_create_file does not need to be checked [1]
> and the function returns void so get rid of the ternary operator, it is
> unnecessary.
>
> [1]: https://lore.kernel.org/linux-mm/20150815160730.gb25...@kroah.com/
>
> Fixes: fbfb8031533c ("ionic: Add hardware init and device commands")
> Link: https://github.com/ClangBuiltLinux/linux/issues/658
> Signed-off-by: Nathan Chancellor
> ---
> drivers/net/ethernet/pensando/ionic/ionic_debugfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Greg Kroah-Hartman
[PATCH] ARM: zx: Use devm_platform_ioremap_resource() in zx296702_pd_probe()
From: Markus Elfring
Date: Wed, 18 Sep 2019 07:40:26 +0200
Simplify this function implementation by using a known wrapper function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
arch/arm/mach-zx/zx296702-pm-domain.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/arch/arm/mach-zx/zx296702-pm-domain.c
b/arch/arm/mach-zx/zx296702-pm-domain.c
index 7a08bf9dd792..ba4f556b7a13 100644
--- a/arch/arm/mach-zx/zx296702-pm-domain.c
+++ b/arch/arm/mach-zx/zx296702-pm-domain.c
@@ -152,7 +152,6 @@ static struct generic_pm_domain *zx296702_pm_domains[] = {
static int zx296702_pd_probe(struct platform_device *pdev)
{
struct genpd_onecell_data *genpd_data;
- struct resource *res;
int i;
genpd_data = devm_kzalloc(>dev, sizeof(*genpd_data), GFP_KERNEL);
@@ -161,14 +160,7 @@ static int zx296702_pd_probe(struct platform_device *pdev)
genpd_data->domains = zx296702_pm_domains;
genpd_data->num_domains = ARRAY_SIZE(zx296702_pm_domains);
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(>dev, "no memory resource defined\n");
- return -ENODEV;
- }
-
- pcubase = devm_ioremap_resource(>dev, res);
+ pcubase = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(pcubase)) {
dev_err(>dev, "ioremap fail.\n");
return -EIO;
--
2.23.0
RE: [PATCH V3 0/4] clk: imx8m: fix glitch/mux
Quoting Peng Fan (2019-09-17 22:45:20) > Hi Stephen, > > > Subject: RE: [PATCH V3 0/4] clk: imx8m: fix glitch/mux > > > > Quoting Peng Fan (2019-09-16 23:20:15) > > > Hi Stephen, Shawn, > > > > > > > Subject: [PATCH V3 0/4] clk: imx8m: fix glitch/mux > > > > > > Sorry to ping early. Is there a chance to land this patchset in 5.3 > > > release? > > > > > > > No, it won't be in 5.3 because that version is released. Shawn already sent > > the > > PR for 5.4 too so this will most likely be in v5.5 at the earliest. > > Thanks for the info. But this patchset is bugfix, so hope this could be > accepted in 5.4. > Ok. Then let's throw it into 5.4 PR and see what goes wrong.
[RESEND, PATCH v7 10/11] dt-bindings: pwm: update bindings for MT7629 SoC
From: Ryder Lee This updates bindings for MT7629 pwm controller. Signed-off-by: Ryder Lee Signed-off-by: Sam Shih Reviewed-by: Rob Herring Reviewed-by: Matthias Brugger --- Changes since v7: - add a missed Reviewed-by tag back from v1: https://patchwork.kernel.org/patch/10769381/ Changes since v1: - add a Reviewed-by tag --- Documentation/devicetree/bindings/pwm/pwm-mediatek.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt index ea95b490a913..c7bd5633d1eb 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt +++ b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt @@ -6,6 +6,7 @@ Required properties: - "mediatek,mt7622-pwm": found on mt7622 SoC. - "mediatek,mt7623-pwm": found on mt7623 SoC. - "mediatek,mt7628-pwm": found on mt7628 SoC. + - "mediatek,mt7629-pwm", "mediatek,mt7622-pwm": found on mt7629 SoC. - reg: physical base address and length of the controller's registers. - #pwm-cells: must be 2. See pwm.txt in this directory for a description of the cell format. -- 2.17.1
[RESEND, PATCH v7 11/11] arm: dts: mediatek: add mt7629 pwm support
This adds pwm support for MT7629.
Signed-off-by: Sam Shih
---
arch/arm/boot/dts/mt7629.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/mt7629.dtsi b/arch/arm/boot/dts/mt7629.dtsi
index 9608bc2ccb3f..493be9a9453b 100644
--- a/arch/arm/boot/dts/mt7629.dtsi
+++ b/arch/arm/boot/dts/mt7629.dtsi
@@ -241,6 +241,22 @@
status = "disabled";
};
+ pwm: pwm@11006000 {
+ compatible = "mediatek,mt7629-pwm",
+"mediatek,mt7622-pwm";
+ reg = <0 0x11006000 0 0x1000>;
+ interrupts = ;
+ clocks = < CLK_TOP_PWM_SEL>,
+< CLK_PERI_PWM_PD>,
+< CLK_PERI_PWM1_PD>;
+ clock-names = "top", "main", "pwm1";
+ assigned-clocks = < CLK_TOP_PWM_SEL>;
+ assigned-clock-parents =
+ < CLK_TOP_UNIVPLL2_D4>;
+ num-pwms = <1>;
+ status = "disabled";
+ };
+
i2c: i2c@11007000 {
compatible = "mediatek,mt7629-i2c",
"mediatek,mt2712-i2c";
--
2.17.1
[RESEND, PATCH v7 07/11] dt-bindings: pwm: pwm-mediatek: add a property "num-pwms"
From: Ryder Lee
This adds a property "num-pwms" in example so that we could
specify the number of PWM channels via device tree.
Signed-off-by: Ryder Lee
Signed-off-by: Sam Shih
Reviewed-by: Matthias Brugger
Acked-by: Uwe Kleine-König
---
Changes since v6:
Follow reviewers's comments:
- The subject should indicate this is for Mediatek
Changes since v5:
- Add an Acked-by tag
- This file is original v4 patch 5/10
(https://patchwork.kernel.org/patch/11102577/)
---
Documentation/devicetree/bindings/pwm/pwm-mediatek.txt | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
index 991728cb46cb..ea95b490a913 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
@@ -14,12 +14,12 @@ Required properties:
has no clocks
- "top": the top clock generator
- "main": clock used by the PWM core
- - "pwm1-8": the eight per PWM clocks for mt2712
- - "pwm1-6": the six per PWM clocks for mt7622
- - "pwm1-5": the five per PWM clocks for mt7623
+ - "pwm1-N": the PWM clocks for each channel
+ where N starting from 1 to the maximum number of PWM channels
- pinctrl-names: Must contain a "default" entry.
- pinctrl-0: One property must exist for each entry in pinctrl-names.
See pinctrl/pinctrl-bindings.txt for details of the property values.
+ - num-pwms: the number of PWM channels.
Example:
pwm0: pwm@11006000 {
@@ -37,4 +37,5 @@ Example:
"pwm3", "pwm4", "pwm5";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
+ num-pwms = <5>;
};
--
2.17.1
[RESEND, PATCH v7 08/11] arm64: dts: mt7622: add a property "num-pwms" for PWM
From: Ryder Lee This adds a property "num-pwms" for PWM controller. Signed-off-by: Ryder Lee Signed-off-by: Sam Shih --- arch/arm64/boot/dts/mediatek/mt7622.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi b/arch/arm64/boot/dts/mediatek/mt7622.dtsi index d1e13d340e26..9a043938881f 100644 --- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi @@ -439,6 +439,7 @@ < CLK_PERI_PWM6_PD>; clock-names = "top", "main", "pwm1", "pwm2", "pwm3", "pwm4", "pwm5", "pwm6"; + num-pwms = <6>; status = "disabled"; }; -- 2.17.1
Re: [PATCH v2 1/8] powerpc/32: Add VDSO version of getcpu
Hi Christophe,
Sorry I'm late replying to this.
Christophe Leroy writes:
> Commit 18ad51dd342a ("powerpc: Add VDSO version of getcpu") added
> getcpu() for PPC64 only, by making use of a user readable general
> purpose SPR.
>
> PPC32 doesn't have any such SPR, a full system call can still be
> avoided by implementing a fast system call which reads the CPU id
> in the task struct and returns immediately without going back in
> virtual mode.
>
> Before the patch, vdsotest reported:
> getcpu: syscall: 1572 nsec/call
> getcpu:libc: 1787 nsec/call
> getcpu:vdso: not tested
>
> Now, vdsotest reports:
> getcpu: syscall: 1582 nsec/call
> getcpu:libc: 667 nsec/call
> getcpu:vdso: 368 nsec/call
>
> For non SMP, just return CPU id 0 from the VDSO directly.
>
> PPC32 doesn't support CONFIG_NUMA so NUMA node is always 0.
>
> Signed-off-by: Christophe Leroy
>
> ---
> v2: fixed build error in getcpu.S
> ---
> arch/powerpc/include/asm/vdso.h | 2 ++
> arch/powerpc/kernel/head_32.h | 13 +
> arch/powerpc/kernel/head_booke.h| 11 +++
> arch/powerpc/kernel/vdso32/Makefile | 4 +---
> arch/powerpc/kernel/vdso32/getcpu.S | 7 +++
> arch/powerpc/kernel/vdso32/vdso32.lds.S | 2 --
> 6 files changed, 34 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/vdso.h b/arch/powerpc/include/asm/vdso.h
> index b5e1f8f8a05c..adb54782df5f 100644
> --- a/arch/powerpc/include/asm/vdso.h
> +++ b/arch/powerpc/include/asm/vdso.h
> @@ -16,6 +16,8 @@
> /* Define if 64 bits VDSO has procedure descriptors */
> #undef VDS64_HAS_DESCRIPTORS
>
> +#define NR_MAGIC_FAST_VDSO_SYSCALL 0x789a
We are still in the middle of the years long process of removing the
"magic" syscall on 64-bit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/exceptions-64s.S?commit=4d856f72c10ecb060868ed10ff1b1453943fc6c8#n1578
Can we not add another one on 32-bit?
Is it really such a fast path that it's worth putting a wart in the
syscall entry like that?
Is there some other method? On s390 they have a per-cpu VDSO page, that
would be a nice option. How we do that would be specific to a particular
MMU, and maybe not even possible with some MMUs. So maybe that's not
feasible.
If you do want to add a fastpath syscall then please just add it as a
regular syscall number, that way it's at least a bit less of a wart.
It's still not visible via tracing/ptrace etc. which is a pain but at
least the number is not "magical" too.
cheers
> /* Offsets relative to thread->vdso_base */
> diff --git a/arch/powerpc/kernel/head_32.h b/arch/powerpc/kernel/head_32.h
> index 4a692553651f..a2e38b59785a 100644
> --- a/arch/powerpc/kernel/head_32.h
> +++ b/arch/powerpc/kernel/head_32.h
> @@ -3,6 +3,8 @@
> #define __HEAD_32_H__
>
> #include /* for STACK_FRAME_REGS_MARKER */
> +#include
> +#include
>
> /*
> * MSR_KERNEL is > 0x8000 on 4xx/Book-E since it include MSR_CE.
> @@ -74,7 +76,13 @@
> .endm
>
> .macro SYSCALL_ENTRY trapno
> +#ifdef CONFIG_SMP
> + cmplwi cr0, r0, NR_MAGIC_FAST_VDSO_SYSCALL
> +#endif
> mfspr r12,SPRN_SPRG_THREAD
> +#ifdef CONFIG_SMP
> + beq-1f
> +#endif
> mfcrr10
> lwz r11,TASK_STACK-THREAD(r12)
> mflrr9
> @@ -152,6 +160,11 @@
> mtspr SPRN_SRR0,r11
> SYNC
> RFI /* jump to handler, enable MMU */
> +#ifdef CONFIG_SMP
> +1:
> + lwz r5, TASK_CPU - THREAD(r12)
> + RFI
> +#endif
> .endm
>
> /*
> diff --git a/arch/powerpc/kernel/head_booke.h
> b/arch/powerpc/kernel/head_booke.h
> index 2ae635df9026..c534e87cac84 100644
> --- a/arch/powerpc/kernel/head_booke.h
> +++ b/arch/powerpc/kernel/head_booke.h
> @@ -3,6 +3,8 @@
> #define __HEAD_BOOKE_H__
>
> #include /* for STACK_FRAME_REGS_MARKER */
> +#include
> +#include
> #include
> #include
>
> @@ -104,6 +106,10 @@ FTR_SECTION_ELSE
> #ifdef CONFIG_KVM_BOOKE_HV
> ALT_FTR_SECTION_END_IFSET(CPU_FTR_EMB_HV)
> #endif
> +#ifdef CONFIG_SMP
> + cmplwi cr0, r0, NR_MAGIC_FAST_VDSO_SYSCALL
> + beq-1f
> +#endif
> BOOKE_CLEAR_BTB(r11)
> lwz r11, TASK_STACK - THREAD(r10)
> rlwinm r12,r12,0,4,2 /* Clear SO bit in CR */
> @@ -176,6 +182,11 @@ ALT_FTR_SECTION_END_IFSET(CPU_FTR_EMB_HV)
> mtspr SPRN_SRR0,r11
> SYNC
> RFI /* jump to handler, enable MMU */
> +#ifdef CONFIG_SMP
> +1:
> + lwz r5, TASK_CPU - THREAD(r10)
> + RFI
> +#endif
> .endm
>
> /* To handle the additional exception priority levels on 40x and Book-E
> diff --git a/arch/powerpc/kernel/vdso32/Makefile
> b/arch/powerpc/kernel/vdso32/Makefile
> index 06f54d947057..e147bbdc12cd 100644
> --- a/arch/powerpc/kernel/vdso32/Makefile
> +++ b/arch/powerpc/kernel/vdso32/Makefile
> @@ -2,9 +2,7 @@
>
> # List of files in the vdso, has to be asm only for now
>
>
Re: [RFC v4 0/3] vhost: introduce mdev based hardware backend
On 2019/9/17 下午6:58, Tiwei Bie wrote:
On Tue, Sep 17, 2019 at 11:32:03AM +0800, Jason Wang wrote:
On 2019/9/17 上午9:02, Tiwei Bie wrote:
This RFC is to demonstrate below ideas,
a) Build vhost-mdev on top of the same abstraction defined in
the virtio-mdev series [1];
b) Introduce /dev/vhost-mdev to do vhost ioctls and support
setting mdev device as backend;
Now the userspace API looks like this:
- Userspace generates a compatible mdev device;
- Userspace opens this mdev device with VFIO API (including
doing IOMMU programming for this mdev device with VFIO's
container/group based interface);
- Userspace opens /dev/vhost-mdev and gets vhost fd;
- Userspace uses vhost ioctls to setup vhost (userspace should
do VHOST_MDEV_SET_BACKEND ioctl with VFIO group fd and device
fd first before doing other vhost ioctls);
Only compile test has been done for this series for now.
Have a hard thought on the architecture:
Thanks a lot! Do appreciate it!
1) Create a vhost char device and pass vfio mdev device fd to it as a
backend and translate vhost-mdev ioctl to virtio mdev transport (e.g
read/write). DMA was done through the VFIO DMA mapping on the container that
is attached.
Yeah, that's what we are doing in this series.
We have two more choices:
2) Use vfio-mdev but do not create vhost-mdev device, instead, just
implement vhost ioctl on vfio_device_ops, and translate them into
virtio-mdev transport or just pass ioctl to parent.
Yeah. Instead of introducing /dev/vhost-mdev char device, do
vhost ioctls on VFIO device fd directly. That's what we did
in RFC v3.
3) Don't use vfio-mdev, create a new vhost-mdev driver, during probe still
try to add dev to vfio group and talk to parent with device specific ops
If my understanding is correct, this means we need to introduce
a new VFIO device driver to replace the existing vfio-mdev driver
in our case. Below is a quick draft just to show my understanding:
#include
#include
#include
#include
#include
#include
#include
#include "mdev_private.h"
/* XXX: we need a proper way to include below vhost header. */
#include "../../vhost/vhost.h"
static int vfio_vhost_mdev_open(void *device_data)
{
if (!try_module_get(THIS_MODULE))
return -ENODEV;
/* ... */
vhost_dev_init(...);
return 0;
}
static void vfio_vhost_mdev_release(void *device_data)
{
/* ... */
module_put(THIS_MODULE);
}
static long vfio_vhost_mdev_unlocked_ioctl(void *device_data,
unsigned int cmd, unsigned long arg)
{
struct mdev_device *mdev = device_data;
struct mdev_parent *parent = mdev->parent;
/*
* Use vhost ioctls.
*
* We will have a different parent_ops design.
* And potentially, we can share the same parent_ops
* with virtio_mdev.
*/
switch (cmd) {
case VHOST_GET_FEATURES:
parent->ops->get_features(mdev, ...);
break;
/* ... */
}
return 0;
}
static ssize_t vfio_vhost_mdev_read(void *device_data, char __user *buf,
size_t count, loff_t *ppos)
{
/* ... */
return 0;
}
static ssize_t vfio_vhost_mdev_write(void *device_data, const char __user *buf,
size_t count, loff_t *ppos)
{
/* ... */
return 0;
}
static int vfio_vhost_mdev_mmap(void *device_data, struct vm_area_struct *vma)
{
/* ... */
return 0;
}
static const struct vfio_device_ops vfio_vhost_mdev_dev_ops = {
.name = "vfio-vhost-mdev",
.open = vfio_vhost_mdev_open,
.release= vfio_vhost_mdev_release,
.ioctl = vfio_vhost_mdev_unlocked_ioctl,
.read = vfio_vhost_mdev_read,
.write = vfio_vhost_mdev_write,
.mmap = vfio_vhost_mdev_mmap,
};
static int vfio_vhost_mdev_probe(struct device *dev)
{
struct mdev_device *mdev = to_mdev_device(dev);
/* ... */
return vfio_add_group_dev(dev, _vhost_mdev_dev_ops, mdev);
}
static void vfio_vhost_mdev_remove(struct device *dev)
{
/* ... */
vfio_del_group_dev(dev);
}
static struct mdev_driver vfio_vhost_mdev_driver = {
.name = "vfio_vhost_mdev",
.probe = vfio_vhost_mdev_probe,
.remove = vfio_vhost_mdev_remove,
};
static int __init vfio_vhost_mdev_init(void)
{
return mdev_register_driver(_vhost_mdev_driver, THIS_MODULE);
}
module_init(vfio_vhost_mdev_init)
static void __exit vfio_vhost_mdev_exit(void)
{
mdev_unregister_driver(_vhost_mdev_driver);
}
module_exit(vfio_vhost_mdev_exit)
Yes, something like this basically.
So I have some questions:
1) Compared to method 2, what's the advantage of creating a new vhost char
device? I guess it's for keep the API compatibility?
One benefit is that
[RESEND, PATCH v7 09/11] arm: dts: mt7623: add a property "num-pwms" for PWM
From: Ryder Lee This adds a property "num-pwms" for PWM controller. Signed-off-by: Ryder Lee Signed-off-by: Sam Shih --- arch/arm/boot/dts/mt7623.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi index a79f0b6c3429..208e0d19a575 100644 --- a/arch/arm/boot/dts/mt7623.dtsi +++ b/arch/arm/boot/dts/mt7623.dtsi @@ -452,6 +452,7 @@ < CLK_PERI_PWM5>; clock-names = "top", "main", "pwm1", "pwm2", "pwm3", "pwm4", "pwm5"; + num-pwms = <5>; status = "disabled"; }; -- 2.17.1
Re: [PATCH] staging: tracing/kprobe: filter kprobe based perf event
Adding cc to b...@vger.kernel.org mailing list since this is really
bpf related.
On 9/17/19 10:24 PM, jinshan.xi...@gmail.com wrote:
> From: Jinshan Xiong
>
> Invoking bpf program only if kprobe based perf_event has been added into
> the percpu list. This is essential to make event tracing for cgroup to work
> properly.
The issue actually exists for bpf programs with kprobe, uprobe,
tracepoint and trace_syscall_enter/exit.
In all these places, bpf program is called regardless of
whether there are perf events or not on this cpu.
This provides bpf programs more opportunities to see
the events. I guess this is by design.
Alexei/Daniel, could you clarify?
This, unfortunately, has a consequence on cgroup.
Currently, perf event cgroup based on filtering
(PERF_FLAG_PID_CGROUP) won't work for bpf programs
with kprobee/uprobe/tracepoint/trace_syscall.
The reason is the same, bpf programs see
more events than what perf has configured.
the overflow interrupt (nmi) based perf_event bpf programs
are not impacted.
Any suggestions on what is the proper way to move
forward?
One way to start to honor events only permitted by perf
like what this patch did. But I am not sure whether this
contradicts the original motivation for bpf programs
to see all events regardless.
Another way is to do filtering inside bpf program.
We already have bpf_get_cgroup_id() helper.
We may need another helper to check whether the current
is (a descendant of) another cgroup as it is often the cases
to trace all processes under one parent cgroup which may have many
child cgroups.
>
> Signed-off-by: Jinshan Xiong
> ---
> kernel/trace/trace_kprobe.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> index 9d483ad9bb6c..40ef0f1945f7 100644
> --- a/kernel/trace/trace_kprobe.c
> +++ b/kernel/trace/trace_kprobe.c
> @@ -1171,11 +1171,18 @@ static int
> kprobe_perf_func(struct trace_kprobe *tk, struct pt_regs *regs)
> {
> struct trace_event_call *call = trace_probe_event_call(>tp);
> + struct hlist_head *head = this_cpu_ptr(call->perf_events);
> struct kprobe_trace_entry_head *entry;
> - struct hlist_head *head;
> int size, __size, dsize;
> int rctx;
>
> + /*
> + * If head is empty, the process currently running on this cpu is not
> + * interested by kprobe perf PMU.
> + */
> + if (hlist_empty(head))
> + return 0;
> +
> if (bpf_prog_array_valid(call)) {
> unsigned long orig_ip = instruction_pointer(regs);
> int ret;
> @@ -1193,10 +1200,6 @@ kprobe_perf_func(struct trace_kprobe *tk, struct
> pt_regs *regs)
> return 0;
> }
>
> - head = this_cpu_ptr(call->perf_events);
> - if (hlist_empty(head))
> - return 0;
> -
> dsize = __get_data_size(>tp, regs);
> __size = sizeof(*entry) + tk->tp.size + dsize;
> size = ALIGN(__size + sizeof(u32), sizeof(u64));
>
[RESEND, PATCH v7 05/11] pwm: mediatek: use pwm_mediatek as common prefix
Use pwm_mediatek as common prefix to match the filename.
No functional change intended.
Signed-off-by: Ryder Lee
Signed-off-by: Sam Shih
Acked-by: Uwe Kleine-König
---
Changes since v6:
Add an Acked-by tag
Changes since v5:
- Follow reviewers's comments
The license stuff is a separate change
---
drivers/pwm/pwm-mediatek.c | 116 +++--
1 file changed, 59 insertions(+), 57 deletions(-)
diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index 71bfab7e2e19..11f9cc446f14 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -34,14 +34,13 @@
#define PWM45THRES_FIXUP 0x34
#define PWM_CLK_DIV_MAX7
-
-struct mtk_pwm_platform_data {
+struct pwm_mediatek_of_data {
unsigned int fallback_npwms;
bool pwm45_fixup;
};
/**
- * struct mtk_pwm_chip - struct representing PWM chip
+ * struct pwm_mediatek_chip - struct representing PWM chip
* @chip: linux PWM chip representation
* @regs: base address of PWM chip
* @clk_top: the top clock generator
@@ -49,27 +48,29 @@ struct mtk_pwm_platform_data {
* @clk_pwms: the clock used by each PWM channel
* @clk_freq: the fix clock frequency of legacy MIPS SoC
*/
-struct mtk_pwm_chip {
+struct pwm_mediatek_chip {
struct pwm_chip chip;
void __iomem *regs;
struct clk *clk_top;
struct clk *clk_main;
struct clk **clk_pwms;
- const struct mtk_pwm_platform_data *soc;
+ const struct pwm_mediatek_of_data *soc;
};
-static const unsigned int mtk_pwm_reg_offset[] = {
+static const unsigned int pwm_mediatek_reg_offset[] = {
0x0010, 0x0050, 0x0090, 0x00d0, 0x0110, 0x0150, 0x0190, 0x0220
};
-static inline struct mtk_pwm_chip *to_mtk_pwm_chip(struct pwm_chip *chip)
+static inline struct pwm_mediatek_chip *
+to_pwm_mediatek_chip(struct pwm_chip *chip)
{
- return container_of(chip, struct mtk_pwm_chip, chip);
+ return container_of(chip, struct pwm_mediatek_chip, chip);
}
-static int mtk_pwm_clk_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+static int pwm_mediatek_clk_enable(struct pwm_chip *chip,
+ struct pwm_device *pwm)
{
- struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
+ struct pwm_mediatek_chip *pc = to_pwm_mediatek_chip(chip);
int ret;
ret = clk_prepare_enable(pc->clk_top);
@@ -94,45 +95,46 @@ static int mtk_pwm_clk_enable(struct pwm_chip *chip, struct
pwm_device *pwm)
return ret;
}
-static void mtk_pwm_clk_disable(struct pwm_chip *chip, struct pwm_device *pwm)
+static void pwm_mediatek_clk_disable(struct pwm_chip *chip,
+struct pwm_device *pwm)
{
- struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
+ struct pwm_mediatek_chip *pc = to_pwm_mediatek_chip(chip);
clk_disable_unprepare(pc->clk_pwms[pwm->hwpwm]);
clk_disable_unprepare(pc->clk_main);
clk_disable_unprepare(pc->clk_top);
}
-static inline u32 mtk_pwm_readl(struct mtk_pwm_chip *chip, unsigned int num,
- unsigned int offset)
+static inline u32 pwm_mediatek_readl(struct pwm_mediatek_chip *chip,
+unsigned int num, unsigned int offset)
{
- return readl(chip->regs + mtk_pwm_reg_offset[num] + offset);
+ return readl(chip->regs + pwm_mediatek_reg_offset[num] + offset);
}
-static inline void mtk_pwm_writel(struct mtk_pwm_chip *chip,
- unsigned int num, unsigned int offset,
- u32 value)
+static inline void pwm_mediatek_writel(struct pwm_mediatek_chip *chip,
+ unsigned int num, unsigned int offset,
+ u32 value)
{
- writel(value, chip->regs + mtk_pwm_reg_offset[num] + offset);
+ writel(value, chip->regs + pwm_mediatek_reg_offset[num] + offset);
}
-static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
- int duty_ns, int period_ns)
+static int pwm_mediatek_config(struct pwm_chip *chip, struct pwm_device *pwm,
+ int duty_ns, int period_ns)
{
- struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
- struct clk *clk = pc->clks[MTK_CLK_PWM1 + pwm->hwpwm];
+ struct pwm_mediatek_chip *pc = to_pwm_mediatek_chip(chip);
u32 clkdiv = 0, cnt_period, cnt_duty, reg_width = PWMDWIDTH,
reg_thres = PWMTHRES;
u64 resolution;
int ret;
- ret = mtk_pwm_clk_enable(chip, pwm);
+ ret = pwm_mediatek_clk_enable(chip, pwm);
+
if (ret < 0)
return ret;
/* Using resolution in picosecond gets accuracy higher */
resolution = (u64)NSEC_PER_SEC * 1000;
- do_div(resolution, clk_get_rate(clk));
+ do_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm]));
cnt_period =
[RESEND, PATCH v7 0/11] Add mt7629 and fix mt7628 pwm
A gentle ping on this whole patch series Changes since v7: 1. PATCH v7 10/11: Add a missed Reviewed-by tag Changes since v6: 1. Due to we can use fixed-clock in DT We removed has_clks and fixed-clock properties Changes since v5: - Follow reviewer's comments: 1. the license stuff is a separate change 2. split fix mt7628 pwm into a single patch 3. to ensure to not use mtk_pwm_clk_name[10] (After dynamic allocate clock array patch, this is no need to check) 4. Use clock-frequency property to replace the use of has_clks Changes since v4: - Follow reviewer's comments (v3: pwm: mediatek: add a property "num-pwms") Move the changes of droping the check for of_device_get_match_data returning non-NULL to next patch - Follow reviewers's comments (v3: pwm: mediatek: allocate the clks array dynamically) 1. use pc->soc->has_clks to check clocks exist or not. 2. Add error message when probe() unable to get clks - Fixes bug when SoC is old mips which has no complex clock tree. if clocks not exist, use the new property from DT to apply period calculation; otherwise, use clk_get_rate to get clock frequency and apply period calculation. Changes since v3: - add a new property "clock-frequency" and fix mt7628 pwm - add mt7629 pwm support Changes since v2: - use num-pwms instead of mediatek,num-pwms. - rename the member from num_pwms to fallback_num_pwms to make it more obvious that it doesn't represent the actually used value. - add a dev_warn and a expressive comment to help other developers to not start adding num_pwms in the compatible_data. Changes since v1: - add some checks for backwards compatibility. Ryder Lee (5): pwm: mediatek: add a property "num-pwms" dt-bindings: pwm: add a property "num-pwms" arm64: dts: mt7622: add a property "num-pwms" for PWM arm: dts: mt7623: add a property "num-pwms" for PWM dt-bindings: pwm: update bindings for MT7629 SoC Sam Shih (6): pwm: mediatek: droping the check for of_device_get_match_data pwm: mediatek: remove a property "has-clks" pwm: mediatek: allocate the clks array dynamically pwm: mediatek: use pwm_mediatek as common prefix pwm: mediatek: update license and switch to SPDX tag arm: dts: mediatek: add mt7629 pwm support .../devicetree/bindings/pwm/pwm-mediatek.txt | 8 +- arch/arm/boot/dts/mt7623.dtsi | 1 + arch/arm64/boot/dts/mediatek/mt7622.dtsi | 1 + drivers/pwm/pwm-mediatek.c| 245 +- arch/arm/boot/dts/mt7629.dtsi | 16 5 files changed, 149 insertions(+), 122 deletions(-) -- 2.17.1
[RESEND, PATCH v7 06/11] pwm: mediatek: update license and switch to SPDX tag
Add SPDX identifiers to pwm-mediatek.c
Update license to GNU General Public License v2.0
Signed-off-by: Ryder Lee
Signed-off-by: Sam Shih
Reviewed-by: Uwe Kleine-König
---
Changes since v6:
Add a Reviewed-by tag
Changes since v5:
- Follow reviewers's comments
The license stuff is a separate change
---
drivers/pwm/pwm-mediatek.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index 11f9cc446f14..9a61829766fc 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -1,12 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
/*
- * Mediatek Pulse Width Modulator driver
+ * MediaTek Pulse Width Modulator driver
*
* Copyright (C) 2015 John Crispin
* Copyright (C) 2017 Zhi Mao
*
- * This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
*/
#include
@@ -331,4 +329,4 @@ static struct platform_driver pwm_mediatek_driver = {
module_platform_driver(pwm_mediatek_driver);
MODULE_AUTHOR("John Crispin ");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
--
2.17.1
[RESEND, PATCH v7 03/11] pwm: mediatek: remove a property "has-clks"
We can use fixed-clock to repair mt7628 pwm during configure from
userspace. The SoC is legacy MIPS and has no complex clock tree.
Due to we can get clock frequency for period calculation from DT
fixed-clock, so we can remove has-clock property, and directly
use devm_clk_get and clk_get_rate.
Signed-off-by: Ryder Lee
Signed-off-by: Sam Shih
---
Changes since v6:
Based on fixed-clock in DT, we can remove has-clks property
Changes since v5:
1. Follow reviewer's comments
Make the changes of fix mt7628 pwm as a single patch
Changes since v4:
- Follow reviewers's comments
1. use pc->soc->has_clks to check clocks exist or not.
2. Add error message when probe() unable to get clks
- Fixes bug when SoC is old mips which has no complex clock tree.
if clocks not exist, use the new property from DT to apply period caculation;
otherwise, use clk_get_rate to get clock frequency and apply period caculation.
---
drivers/pwm/pwm-mediatek.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index ebd62629e3fe..07e843aeddb1 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -57,7 +57,6 @@ static const char * const mtk_pwm_clk_name[MTK_CLK_MAX] = {
struct mtk_pwm_platform_data {
unsigned int fallback_npwms;
bool pwm45_fixup;
- bool has_clks;
};
/**
@@ -87,9 +86,6 @@ static int mtk_pwm_clk_enable(struct pwm_chip *chip, struct
pwm_device *pwm)
struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
int ret;
- if (!pc->soc->has_clks)
- return 0;
-
ret = clk_prepare_enable(pc->clks[MTK_CLK_TOP]);
if (ret < 0)
return ret;
@@ -116,9 +112,6 @@ static void mtk_pwm_clk_disable(struct pwm_chip *chip,
struct pwm_device *pwm)
{
struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
- if (!pc->soc->has_clks)
- return;
-
clk_disable_unprepare(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);
clk_disable_unprepare(pc->clks[MTK_CLK_MAIN]);
clk_disable_unprepare(pc->clks[MTK_CLK_TOP]);
@@ -262,11 +255,13 @@ static int mtk_pwm_probe(struct platform_device *pdev)
npwms = MTK_CLK_MAX - 2;
}
- for (i = 0; i < npwms + 2 && pc->soc->has_clks; i++) {
- pc->clks[i] = devm_clk_get(>dev, mtk_pwm_clk_name[i]);
+ for (i = 0; i < npwms + 2 ; i++) {
+ pc->clks[i] = devm_clk_get(>dev,
+ mtk_pwm_clk_name[i]);
if (IS_ERR(pc->clks[i])) {
dev_err(>dev, "clock: %s fail: %ld\n",
- mtk_pwm_clk_name[i], PTR_ERR(pc->clks[i]));
+ mtk_pwm_clk_name[i],
+ PTR_ERR(pc->clks[i]));
return PTR_ERR(pc->clks[i]);
}
}
@@ -297,25 +292,21 @@ static int mtk_pwm_remove(struct platform_device *pdev)
static const struct mtk_pwm_platform_data mt2712_pwm_data = {
.fallback_npwms = 8,
.pwm45_fixup = false,
- .has_clks = true,
};
static const struct mtk_pwm_platform_data mt7622_pwm_data = {
.fallback_npwms = 6,
.pwm45_fixup = false,
- .has_clks = true,
};
static const struct mtk_pwm_platform_data mt7623_pwm_data = {
.fallback_npwms = 5,
.pwm45_fixup = true,
- .has_clks = true,
};
static const struct mtk_pwm_platform_data mt7628_pwm_data = {
.fallback_npwms = 4,
.pwm45_fixup = true,
- .has_clks = false,
};
static const struct of_device_id mtk_pwm_of_match[] = {
--
2.17.1
[RESEND, PATCH v7 02/11] pwm: mediatek: droping the check for of_device_get_match_data
This patch drop the check for of_device_get_match_data.
Due to the only way call driver probe is compatible match.
The .data pointer which point to the SoC specify data is
directly set by driver, and it should not be NULL in our case.
We can safety remove the check for of_device_get_match_data.
Signed-off-by: Ryder Lee
Signed-off-by: Sam Shih
Acked-by: Uwe Kleine-König
---
Used:
https://patchwork.kernel.org/patch/11096905/
Changes since v6:
Add an Acked-by tag
Changes since v4:
Follow reviewer's comments:
Move the changes of droping the check for of_device_get_match_data
returning non-NULL to this patch
---
drivers/pwm/pwm-mediatek.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index e214f4f57107..ebd62629e3fe 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -226,7 +226,6 @@ static const struct pwm_ops mtk_pwm_ops = {
static int mtk_pwm_probe(struct platform_device *pdev)
{
- const struct mtk_pwm_platform_data *data;
struct device_node *np = pdev->dev.of_node;
struct mtk_pwm_chip *pc;
struct resource *res;
@@ -237,10 +236,7 @@ static int mtk_pwm_probe(struct platform_device *pdev)
if (!pc)
return -ENOMEM;
- data = of_device_get_match_data(>dev);
- if (data == NULL)
- return -EINVAL;
- pc->soc = data;
+ pc->soc = of_device_get_match_data(>dev);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
pc->regs = devm_ioremap_resource(>dev, res);
--
2.17.1
[RESEND, PATCH v7 01/11] pwm: mediatek: add a property "num-pwms"
From: Ryder Lee
This adds a property "num-pwms" to avoid having an endless
list of compatibles with no differences for the same driver.
Signed-off-by: Ryder Lee
Signed-off-by: Sam Shih
Reviewed-by: Uwe Kleine-König
---
Changes since v6:
Add a Reviewed-by tag
Changes since v5:
Check num-pwms value is no more than MTK_CLK_MAX - 2 (MAIN + TOP)
Changes since v4:
Follow reviewer's comments:
Move the changes of droping the check for of_device_get_match_data returning
non-NULL to next patch
---
drivers/pwm/pwm-mediatek.c | 36
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index eb6674ce995f..e214f4f57107 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -55,7 +55,7 @@ static const char * const mtk_pwm_clk_name[MTK_CLK_MAX] = {
};
struct mtk_pwm_platform_data {
- unsigned int num_pwms;
+ unsigned int fallback_npwms;
bool pwm45_fixup;
bool has_clks;
};
@@ -227,9 +227,10 @@ static const struct pwm_ops mtk_pwm_ops = {
static int mtk_pwm_probe(struct platform_device *pdev)
{
const struct mtk_pwm_platform_data *data;
+ struct device_node *np = pdev->dev.of_node;
struct mtk_pwm_chip *pc;
struct resource *res;
- unsigned int i;
+ unsigned int i, npwms;
int ret;
pc = devm_kzalloc(>dev, sizeof(*pc), GFP_KERNEL);
@@ -246,7 +247,26 @@ static int mtk_pwm_probe(struct platform_device *pdev)
if (IS_ERR(pc->regs))
return PTR_ERR(pc->regs);
- for (i = 0; i < data->num_pwms + 2 && pc->soc->has_clks; i++) {
+ ret = of_property_read_u32(np, "num-pwms", );
+ if (ret < 0) {
+ /* It's deprecated, we should specify num_pwms via DT now. */
+ if (pc->soc->fallback_npwms) {
+ npwms = pc->soc->fallback_npwms;
+ dev_warn(>dev, "DT is outdated, please update
it\n");
+ } else {
+ dev_err(>dev, "failed to get number of PWMs\n");
+ return ret;
+ }
+ }
+
+ /* MAIN + TOP + NPWM < MTK_CLK_MAX */
+ if ((npwms + 2) > MTK_CLK_MAX) {
+ dev_warn(>dev, "number of PWMs is larger than %d\n",
+MTK_CLK_MAX - 2);
+ npwms = MTK_CLK_MAX - 2;
+ }
+
+ for (i = 0; i < npwms + 2 && pc->soc->has_clks; i++) {
pc->clks[i] = devm_clk_get(>dev, mtk_pwm_clk_name[i]);
if (IS_ERR(pc->clks[i])) {
dev_err(>dev, "clock: %s fail: %ld\n",
@@ -260,7 +280,7 @@ static int mtk_pwm_probe(struct platform_device *pdev)
pc->chip.dev = >dev;
pc->chip.ops = _pwm_ops;
pc->chip.base = -1;
- pc->chip.npwm = data->num_pwms;
+ pc->chip.npwm = npwms;
ret = pwmchip_add(>chip);
if (ret < 0) {
@@ -279,25 +299,25 @@ static int mtk_pwm_remove(struct platform_device *pdev)
}
static const struct mtk_pwm_platform_data mt2712_pwm_data = {
- .num_pwms = 8,
+ .fallback_npwms = 8,
.pwm45_fixup = false,
.has_clks = true,
};
static const struct mtk_pwm_platform_data mt7622_pwm_data = {
- .num_pwms = 6,
+ .fallback_npwms = 6,
.pwm45_fixup = false,
.has_clks = true,
};
static const struct mtk_pwm_platform_data mt7623_pwm_data = {
- .num_pwms = 5,
+ .fallback_npwms = 5,
.pwm45_fixup = true,
.has_clks = true,
};
static const struct mtk_pwm_platform_data mt7628_pwm_data = {
- .num_pwms = 4,
+ .fallback_npwms = 4,
.pwm45_fixup = true,
.has_clks = false,
};
--
2.17.1
[RESEND, PATCH v7 04/11] pwm: mediatek: allocate the clks array dynamically
Instead of using fixed size of arrays, allocate the memory for them
based on the information we get from the DT.
Also remove the check for num_pwms, due to dynamically allocate pwm
should not cause array index out of bound.
Signed-off-by: Ryder Lee
Signed-off-by: Sam Shih
Reviewed-by: Uwe Kleine-König
---
Changes since v6:
- Add a Reviewed-by tag
Changes since v5:
- Follow reviewers's comments
Make the changes of allocate the clks array dynamically as a single patch
Changes since v4:
- Follow reviewers's comments
1. use pc->soc->has_clks to check clocks exist or not.
2. Add error message when probe() unable to get clks
- Fixes bug when SoC is old mips which has no complex clock tree.
if clocks not exist, use the new property from DT to apply period caculation;
otherwise, use clk_get_rate to get clock frequency and apply period caculation.
---
drivers/pwm/pwm-mediatek.c | 84 +++---
1 file changed, 42 insertions(+), 42 deletions(-)
diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index 07e843aeddb1..71bfab7e2e19 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -35,25 +35,6 @@
#define PWM_CLK_DIV_MAX7
-enum {
- MTK_CLK_MAIN = 0,
- MTK_CLK_TOP,
- MTK_CLK_PWM1,
- MTK_CLK_PWM2,
- MTK_CLK_PWM3,
- MTK_CLK_PWM4,
- MTK_CLK_PWM5,
- MTK_CLK_PWM6,
- MTK_CLK_PWM7,
- MTK_CLK_PWM8,
- MTK_CLK_MAX,
-};
-
-static const char * const mtk_pwm_clk_name[MTK_CLK_MAX] = {
- "main", "top", "pwm1", "pwm2", "pwm3", "pwm4", "pwm5", "pwm6", "pwm7",
- "pwm8"
-};
-
struct mtk_pwm_platform_data {
unsigned int fallback_npwms;
bool pwm45_fixup;
@@ -63,12 +44,17 @@ struct mtk_pwm_platform_data {
* struct mtk_pwm_chip - struct representing PWM chip
* @chip: linux PWM chip representation
* @regs: base address of PWM chip
- * @clks: list of clocks
+ * @clk_top: the top clock generator
+ * @clk_main: the clock used by PWM core
+ * @clk_pwms: the clock used by each PWM channel
+ * @clk_freq: the fix clock frequency of legacy MIPS SoC
*/
struct mtk_pwm_chip {
struct pwm_chip chip;
void __iomem *regs;
- struct clk *clks[MTK_CLK_MAX];
+ struct clk *clk_top;
+ struct clk *clk_main;
+ struct clk **clk_pwms;
const struct mtk_pwm_platform_data *soc;
};
@@ -86,24 +72,24 @@ static int mtk_pwm_clk_enable(struct pwm_chip *chip, struct
pwm_device *pwm)
struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
int ret;
- ret = clk_prepare_enable(pc->clks[MTK_CLK_TOP]);
+ ret = clk_prepare_enable(pc->clk_top);
if (ret < 0)
return ret;
- ret = clk_prepare_enable(pc->clks[MTK_CLK_MAIN]);
+ ret = clk_prepare_enable(pc->clk_main);
if (ret < 0)
goto disable_clk_top;
- ret = clk_prepare_enable(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);
+ ret = clk_prepare_enable(pc->clk_pwms[pwm->hwpwm]);
if (ret < 0)
goto disable_clk_main;
return 0;
disable_clk_main:
- clk_disable_unprepare(pc->clks[MTK_CLK_MAIN]);
+ clk_disable_unprepare(pc->clk_main);
disable_clk_top:
- clk_disable_unprepare(pc->clks[MTK_CLK_TOP]);
+ clk_disable_unprepare(pc->clk_top);
return ret;
}
@@ -112,9 +98,9 @@ static void mtk_pwm_clk_disable(struct pwm_chip *chip,
struct pwm_device *pwm)
{
struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
- clk_disable_unprepare(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);
- clk_disable_unprepare(pc->clks[MTK_CLK_MAIN]);
- clk_disable_unprepare(pc->clks[MTK_CLK_TOP]);
+ clk_disable_unprepare(pc->clk_pwms[pwm->hwpwm]);
+ clk_disable_unprepare(pc->clk_main);
+ clk_disable_unprepare(pc->clk_top);
}
static inline u32 mtk_pwm_readl(struct mtk_pwm_chip *chip, unsigned int num,
@@ -222,7 +208,7 @@ static int mtk_pwm_probe(struct platform_device *pdev)
struct device_node *np = pdev->dev.of_node;
struct mtk_pwm_chip *pc;
struct resource *res;
- unsigned int i, npwms;
+ unsigned int npwms;
int ret;
pc = devm_kzalloc(>dev, sizeof(*pc), GFP_KERNEL);
@@ -248,21 +234,35 @@ static int mtk_pwm_probe(struct platform_device *pdev)
}
}
- /* MAIN + TOP + NPWM < MTK_CLK_MAX */
- if ((npwms + 2) > MTK_CLK_MAX) {
- dev_warn(>dev, "number of PWMs is larger than %d\n",
-MTK_CLK_MAX - 2);
- npwms = MTK_CLK_MAX - 2;
+ int i;
+
+ pc->clk_pwms = devm_kcalloc(>dev, npwms,
+ sizeof(*pc->clk_pwms), GFP_KERNEL);
+ if (!pc->clk_pwms)
+ return -ENOMEM;
+
+ pc->clk_top = devm_clk_get(>dev, "top");
+ if (IS_ERR(pc->clk_top)) {
+ dev_err(>dev, "clock: top fail: %ld\n",
+
Re: [linux-sunxi] [PATCH] clk: sunxi-ng: h6: Use sigma-delta modulation for audio PLL
On Wed, Sep 18, 2019 at 1:21 PM Jernej Škrabec wrote:
>
> Dne torek, 17. september 2019 ob 08:54:08 CEST je Chen-Yu Tsai napisal(a):
> > On Sat, Sep 14, 2019 at 9:51 PM Jernej Skrabec
> wrote:
> > > Audio devices needs exact clock rates in order to correctly reproduce
> > > the sound. Until now, only integer factors were used to configure H6
> > > audio PLL which resulted in inexact rates. Fix that by adding support
> > > for fractional factors using sigma-delta modulation look-up table. It
> > > contains values for two most commonly used audio base frequencies.
> > >
> > > Signed-off-by: Jernej Skrabec
> > > ---
> > >
> > > drivers/clk/sunxi-ng/ccu-sun50i-h6.c | 21 +++--
> > > 1 file changed, 15 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6.c
> > > b/drivers/clk/sunxi-ng/ccu-sun50i-h6.c index d89353a3cdec..ed6338d74474
> > > 100644
> > > --- a/drivers/clk/sunxi-ng/ccu-sun50i-h6.c
> > > +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6.c
> > > @@ -203,12 +203,21 @@ static struct ccu_nkmp pll_hsic_clk = {
> > >
> > > * hardcode it to match with the clock names.
> > > */
> > >
> > > #define SUN50I_H6_PLL_AUDIO_REG0x078
> > >
> > > +
> > > +static struct ccu_sdm_setting pll_audio_sdm_table[] = {
> > > + { .rate = 541900800, .pattern = 0xc001288d, .m = 1, .n = 22 },
> > > + { .rate = 589824000, .pattern = 0xc00126e9, .m = 1, .n = 24 },
> > > +};
> > > +
> > >
> > > static struct ccu_nm pll_audio_base_clk = {
> > >
> > > .enable = BIT(31),
> > > .lock = BIT(28),
> > > .n = _SUNXI_CCU_MULT_MIN(8, 8, 12),
> > > .m = _SUNXI_CCU_DIV(1, 1), /* input divider */
> > >
> > > + .sdm= _SUNXI_CCU_SDM(pll_audio_sdm_table,
> > > +BIT(24), 0x178, BIT(31)),
> > >
> > > .common = {
> > >
> > > + .features = CCU_FEATURE_SIGMA_DELTA_MOD,
> > >
> > > .reg= 0x078,
> > > .hw.init= CLK_HW_INIT("pll-audio-base", "osc24M",
> > >
> > > _nm_ops,
> > >
> > > @@ -753,12 +762,12 @@ static const struct clk_hw *clk_parent_pll_audio[] =
> > > {>
> > > };
> > >
> > > /*
> > >
> > > - * The divider of pll-audio is fixed to 8 now, as pll-audio-4x has a
> > > - * fixed post-divider 2.
> > > + * The divider of pll-audio is fixed to 24 for now, so 24576000 and
> > > 22579200 + * rates can be set exactly in conjunction with sigma-delta
> > > modulation.>
> > > */
> > >
> > > static CLK_FIXED_FACTOR_HWS(pll_audio_clk, "pll-audio",
> > >
> > > clk_parent_pll_audio,
> > >
> > > - 8, 1, CLK_SET_RATE_PARENT);
> > > + 24, 1, CLK_SET_RATE_PARENT);
> > >
> > > static CLK_FIXED_FACTOR_HWS(pll_audio_2x_clk, "pll-audio-2x",
> > >
> > > clk_parent_pll_audio,
> > > 4, 1, CLK_SET_RATE_PARENT);
> >
> > You need to fix the factors for the other two outputs as well, since all
> > three are derived from pll-audio-base.
>
> Fix how? pll-audio-2x and pll-audio-4x clocks have fixed divider in regards to
> pll-audio-base, while pll-audio has not. Unless you mean changing their name?
Argh... I got it wrong. It looks good actually.
Acked-by: Chen-Yu Tsai
RE: [PATCH V3 0/4] clk: imx8m: fix glitch/mux
Hi Stephen, > Subject: RE: [PATCH V3 0/4] clk: imx8m: fix glitch/mux > > Quoting Peng Fan (2019-09-16 23:20:15) > > Hi Stephen, Shawn, > > > > > Subject: [PATCH V3 0/4] clk: imx8m: fix glitch/mux > > > > Sorry to ping early. Is there a chance to land this patchset in 5.3 release? > > > > No, it won't be in 5.3 because that version is released. Shawn already sent > the > PR for 5.4 too so this will most likely be in v5.5 at the earliest. Thanks for the info. But this patchset is bugfix, so hope this could be accepted in 5.4. Thanks, Peng.
Re: [PATCH v7 5/6] powerpc/64: Make COMPAT user-selectable disabled on littleendian by default.
Michal Suchánek writes: > On Tue, 03 Sep 2019 10:00:57 +1000 > Michael Ellerman wrote: >> Michal Suchánek writes: >> > On Mon, 02 Sep 2019 12:03:12 +1000 >> > Michael Ellerman wrote: >> > >> >> Michal Suchanek writes: >> >> > On bigendian ppc64 it is common to have 32bit legacy binaries but much >> >> > less so on littleendian. >> >> >> >> I think the toolchain people will tell you that there is no 32-bit >> >> little endian ABI defined at all, if anything works it's by accident. >> > >> > I have seen a piece of software that workarounds code issues on 64bit >> > by always compiling 32bit code. So it does work in some way. >> >> What software is that? > > The only one I have seen is stockfish (v9) OK, not sure how many people are testing that on powerpc :) >> > Also it has been pointed out that you can still switch to BE even with >> > the 'fast-switch' removed. >> >> Yes we have a proper syscall for endian switching, sys_switch_endian(), >> which is definitely supported. >> >> But that *only* switches the endian-ness of the process, it does nothing >> to the syscall layer. So any process that switches to the other endian >> must endian flip syscall arguments (that aren't in registers), or flip >> back to the native endian before calling syscalls. > > In other words just installing a chroot of binaries built for the other > endian won't work. You need something like qemu to do the syscall > translation or run full VM with a kernel that has the swapped endian > syscall ABI. Yes that's right. cheers
Re: [PATCH v3 bpf-next 00/14] samples: bpf: improve/fix cross-compilation
On Mon, Sep 16, 2019 at 4:02 AM Ivan Khoronzhuk wrote: > Thanks for these changes, they look good overall. It would be great if someone else could test and validate that cross-compilation works not just in your environment and generated binaries successfully run on target machines, though... [...] > > Ivan Khoronzhuk (14): > samples: bpf: makefile: fix HDR_PROBE "echo" > samples: bpf: makefile: fix cookie_uid_helper_example obj build > samples: bpf: makefile: use --target from cross-compile > samples: bpf: use own EXTRA_CFLAGS for clang commands > samples: bpf: makefile: use __LINUX_ARM_ARCH__ selector for arm > samples: bpf: makefile: drop unnecessarily inclusion for bpf_load > samples: bpf: add makefile.target for separate CC target build > samples: bpf: makefile: base target programs rules on Makefile.target > samples: bpf: makefile: use own flags but not host when cross compile > samples: bpf: makefile: use target CC environment for HDR_PROBE > libbpf: makefile: add C/CXX/LDFLAGS to libbpf.so and test_libpf > targets > samples: bpf: makefile: provide C/CXX/LD flags to libbpf > samples: bpf: makefile: add sysroot support > samples: bpf: README: add preparation steps and sysroot info > Prefixes like "samples: bpf: makefile: " are very verbose without adding much value. We've been converging to essentially this set of prefixes: - "libbpf:" for libbpf changes - "bpftool:" for bpftool changes - "selftests/bpf:" for bpf selftests - "samples/bpf:" for bpf samples There is no need to prefix with "makefile: " either. Please update your patch subjects in the next version. Thanks! > samples/bpf/Makefile| 179 +--- > samples/bpf/Makefile.target | 75 +++ > samples/bpf/README.rst | 41 - > tools/lib/bpf/Makefile | 11 ++- > 4 files changed, 225 insertions(+), 81 deletions(-) > create mode 100644 samples/bpf/Makefile.target > > -- > 2.17.1 >
Re: [PATCH V6 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
On Tue, Sep 17, 2019 at 12:31 PM Andre Przywara wrote: > > On Mon, 16 Sep 2019 09:44:37 + > Peng Fan wrote: > > Hi, > > > From: Peng Fan > > > > The ARM SMC/HVC mailbox binding describes a firmware interface to trigger > > actions in software layers running in the EL2 or EL3 exception levels. > > The term "ARM" here relates to the SMC instruction as part of the ARM > > instruction set, not as a standard endorsed by ARM Ltd. > > > > Signed-off-by: Peng Fan > > --- > > .../devicetree/bindings/mailbox/arm-smc.yaml | 96 > > ++ > > 1 file changed, 96 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > new file mode 100644 > > index ..bf01bec035fc > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > @@ -0,0 +1,96 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: ARM SMC Mailbox Interface > > + > > +maintainers: > > + - Peng Fan > > + > > +description: | > > + This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor > > I think "or" instead of "and" is less confusing. > > > + call) instruction to trigger a mailbox-connected activity in firmware, > > + executing on the very same core as the caller. The value of r0/w0/x0 > > + the firmware returns after the smc call is delivered as a received > > + message to the mailbox framework, so synchronous communication can be > > + established. The exact meaning of the action the mailbox triggers as > > + well as the return value is defined by their users and is not subject > > + to this binding. > > + > > + One use case of this mailbox is the SCMI interface, which uses shared > > One example use case of this mailbox ... > (to make it more obvious that it's not restricted to this) > > > + memory to transfer commands and parameters, and a mailbox to trigger a > > + function call. This allows SoCs without a separate management processor > > + (or when such a processor is not available or used) to use this > > + standardized interface anyway. > > + > > + This binding describes no hardware, but establishes a firmware interface. > > + Upon receiving an SMC using one of the described SMC function > > identifiers, > > ... the described SMC function identifier, > > > + the firmware is expected to trigger some mailbox connected functionality. > > + The communication follows the ARM SMC calling convention. > > + Firmware expects an SMC function identifier in r0 or w0. The supported > > + identifiers are passed from consumers, > > identifier > > "passed from consumers": How? Where? > But I want to repeat: We should not allow this. > This is a binding for a mailbox controller driver, not a generic firmware > backdoor. > Exactly. The mailbox controller here is the SMC/HVC instruction, 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? > 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. > > or listed in the the arm,func-ids > >arm,func-id > > > + properties as described below. The firmware can return one value in > > property > > > + the first SMC result register, it is expected to be an error value, > > + which shall be propagated to the mailbox client. > > + > > + Any core which supports the SMC or HVC instruction can be used, as long > > + as a firmware component running in EL3 or EL2 is handling these calls. > > + > > +properties: > > + compatible: > > +oneOf: > > + - description: > > + For implementations using ARM SMC instruction. > > +const: arm,smc-mbox > > + > > + - description: > > + For implementations using ARM HVC instruction. > > +const: arm,hvc-mbox > > I am not particularly happy with this, but well ... > > > + > > + "#mbox-cells": > > +const: 1 > > Why is this "1"? What is this number used for? It used to be the channel ID, > but since you are describing a single channel controller only, this should be > 0 now. > Yes. I overlooked it and actually queued the patch for pull request. But I think the bindings should not carry a 'fix' patch later.
[PATCH] staging: tracing/kprobe: filter kprobe based perf event
From: Jinshan Xiong
Invoking bpf program only if kprobe based perf_event has been added into
the percpu list. This is essential to make event tracing for cgroup to work
properly.
Signed-off-by: Jinshan Xiong
---
kernel/trace/trace_kprobe.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 9d483ad9bb6c..40ef0f1945f7 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -1171,11 +1171,18 @@ static int
kprobe_perf_func(struct trace_kprobe *tk, struct pt_regs *regs)
{
struct trace_event_call *call = trace_probe_event_call(>tp);
+ struct hlist_head *head = this_cpu_ptr(call->perf_events);
struct kprobe_trace_entry_head *entry;
- struct hlist_head *head;
int size, __size, dsize;
int rctx;
+ /*
+* If head is empty, the process currently running on this cpu is not
+* interested by kprobe perf PMU.
+*/
+ if (hlist_empty(head))
+ return 0;
+
if (bpf_prog_array_valid(call)) {
unsigned long orig_ip = instruction_pointer(regs);
int ret;
@@ -1193,10 +1200,6 @@ kprobe_perf_func(struct trace_kprobe *tk, struct pt_regs
*regs)
return 0;
}
- head = this_cpu_ptr(call->perf_events);
- if (hlist_empty(head))
- return 0;
-
dsize = __get_data_size(>tp, regs);
__size = sizeof(*entry) + tk->tp.size + dsize;
size = ALIGN(__size + sizeof(u32), sizeof(u64));
Re: [PATCH v3 bpf-next 13/14] samples: bpf: makefile: add sysroot support
On Mon, Sep 16, 2019 at 4:00 AM Ivan Khoronzhuk
wrote:
>
> Basically it only enables that was added by previous couple fixes.
> Sysroot contains correct libs installed and its headers ofc. Useful
Please, let's not use unnecessary abbreviations/slang. "Of course" is
not too long and is a proper English, let's stick to it.
> when working with NFC or virtual machine.
>
> Usage:
>
> clean (on demand)
> make ARCH=arm -C samples/bpf clean
> make ARCH=arm -C tools clean
> make ARCH=arm clean
>
> configure and install headers:
>
> make ARCH=arm defconfig
> make ARCH=arm headers_install
>
> build samples/bpf:
> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- samples/bpf/ \
> SYSROOT="path/to/sysroot"
>
> Signed-off-by: Ivan Khoronzhuk
> ---
> samples/bpf/Makefile | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> index 133123d4c7d7..57ddf055d6c3 100644
> --- a/samples/bpf/Makefile
> +++ b/samples/bpf/Makefile
> @@ -194,6 +194,11 @@ TPROGS_CFLAGS += -I$(srctree)/tools/lib/
> TPROGS_CFLAGS += -I$(srctree)/tools/include
> TPROGS_CFLAGS += -I$(srctree)/tools/perf
>
> +ifdef SYSROOT
> +TPROGS_CFLAGS += --sysroot=${SYSROOT}
> +TPROGS_LDFLAGS := -L${SYSROOT}/usr/lib
Please stay consistent: $() instead of ${}?
> +endif
> +
> EXTRA_CXXFLAGS := $(TPROGS_CFLAGS)
>
> # options not valid for C++
> --
> 2.17.1
>
[PATCH v3 5/5] powerpc: Don't flush caches when adding memory
From: Alastair D'Silva
This operation takes a significant amount of time when hotplugging
large amounts of memory (~50 seconds with 890GB of persistent memory).
This was orignally in commit fb5924fddf9e
("powerpc/mm: Flush cache on memory hot(un)plug") to support memtrace,
but the flush on add is not needed as it is flushed on remove.
Signed-off-by: Alastair D'Silva
---
arch/powerpc/mm/mem.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 4f892da59a6a..dd1aa80e854a 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -142,8 +142,6 @@ int __ref arch_add_memory(int nid, u64 start, u64 size,
return -EFAULT;
}
- flush_dcache_range_chunked(start, start + size, FLUSH_CHUNK_SIZE);
-
return __add_pages(nid, start_pfn, nr_pages, restrictions);
}
--
2.21.0
[PATCH v3 3/5] powerpc: Convert flush_icache_range & friends to C
From: Alastair D'Silva
Similar to commit 22e9c88d486a
("powerpc/64: reuse PPC32 static inline flush_dcache_range()")
this patch converts the following ASM symbols to C:
flush_icache_range()
__flush_dcache_icache()
__flush_dcache_icache_phys()
This was done as we discovered a long-standing bug where the length of the
range was truncated due to using a 32 bit shift instead of a 64 bit one.
By converting these functions to C, it becomes easier to maintain.
flush_dcache_icache_phys() retains a critical assembler section as we must
ensure there are no memory accesses while the data MMU is disabled
(authored by Christophe Leroy). Since this has no external callers, it has
also been made static, allowing the compiler to inline it within
flush_dcache_icache_page().
Signed-off-by: Alastair D'Silva
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/cache.h | 26 ++---
arch/powerpc/include/asm/cacheflush.h | 24 ++--
arch/powerpc/kernel/misc_32.S | 117
arch/powerpc/kernel/misc_64.S | 102 -
arch/powerpc/mm/mem.c | 151 +-
5 files changed, 172 insertions(+), 248 deletions(-)
diff --git a/arch/powerpc/include/asm/cache.h b/arch/powerpc/include/asm/cache.h
index f852d5cd746c..e33451a9c4e6 100644
--- a/arch/powerpc/include/asm/cache.h
+++ b/arch/powerpc/include/asm/cache.h
@@ -98,20 +98,7 @@ static inline u32 l1_icache_bytes(void)
#endif
#endif /* ! __ASSEMBLY__ */
-#if defined(__ASSEMBLY__)
-/*
- * For a snooping icache, we still need a dummy icbi to purge all the
- * prefetched instructions from the ifetch buffers. We also need a sync
- * before the icbi to order the the actual stores to memory that might
- * have modified instructions with the icbi.
- */
-#define PURGE_PREFETCHED_INS \
- sync; \
- icbi0,r3; \
- sync; \
- isync
-
-#else
+#if !defined(__ASSEMBLY__)
#define __read_mostly __attribute__((__section__(".data..read_mostly")))
#ifdef CONFIG_PPC_BOOK3S_32
@@ -145,6 +132,17 @@ static inline void dcbst(void *addr)
{
__asm__ __volatile__ ("dcbst %y0" : : "Z"(*(u8 *)addr) : "memory");
}
+
+static inline void icbi(void *addr)
+{
+ asm volatile ("icbi 0, %0" : : "r"(addr) : "memory");
+}
+
+static inline void iccci(void *addr)
+{
+ asm volatile ("iccci 0, %0" : : "r"(addr) : "memory");
+}
+
#endif /* !__ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_CACHE_H */
diff --git a/arch/powerpc/include/asm/cacheflush.h
b/arch/powerpc/include/asm/cacheflush.h
index ed57843ef452..4a1c9f0200e1 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -42,24 +42,20 @@ extern void flush_dcache_page(struct page *page);
#define flush_dcache_mmap_lock(mapping)do { } while (0)
#define flush_dcache_mmap_unlock(mapping) do { } while (0)
-extern void flush_icache_range(unsigned long, unsigned long);
+void flush_icache_range(unsigned long start, unsigned long stop);
extern void flush_icache_user_range(struct vm_area_struct *vma,
struct page *page, unsigned long addr,
int len);
-extern void __flush_dcache_icache(void *page_va);
extern void flush_dcache_icache_page(struct page *page);
-#if defined(CONFIG_PPC32) && !defined(CONFIG_BOOKE)
-extern void __flush_dcache_icache_phys(unsigned long physaddr);
-#else
-static inline void __flush_dcache_icache_phys(unsigned long physaddr)
-{
- BUG();
-}
-#endif
-
-/*
- * Write any modified data cache blocks out to memory and invalidate them.
- * Does not invalidate the corresponding instruction cache blocks.
+void __flush_dcache_icache(void *page);
+
+/**
+ * flush_dcache_range(): Write any modified data cache blocks out to memory and
+ * invalidate them. Does not invalidate the corresponding instruction cache
+ * blocks.
+ *
+ * @start: the start address
+ * @stop: the stop address (exclusive)
*/
static inline void flush_dcache_range(unsigned long start, unsigned long stop)
{
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index fe4bd321730e..12b95e6799d4 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -318,123 +318,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_UNIFIED_ID_CACHE)
EXPORT_SYMBOL(flush_instruction_cache)
#endif /* CONFIG_PPC_8xx */
-/*
- * Write any modified data cache blocks out to memory
- * and invalidate the corresponding instruction cache blocks.
- * This is a no-op on the 601.
- *
- * flush_icache_range(unsigned long start, unsigned long stop)
- */
-_GLOBAL(flush_icache_range)
-BEGIN_FTR_SECTION
- PURGE_PREFETCHED_INS
- blr /* for 601, do nothing */
-END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE)
- rlwinm r3,r3,0,0,31 - L1_CACHE_SHIFT
- subfr4,r3,r4
- addi
[PATCH v3 4/5] powerpc: Chunk calls to flush_dcache_range in arch_*_memory
From: Alastair D'Silva
When presented with large amounts of memory being hotplugged
(in my test case, ~890GB), the call to flush_dcache_range takes
a while (~50 seconds), triggering RCU stalls.
This patch breaks up the call into 1GB chunks, calling
cond_resched() inbetween to allow the scheduler to run.
Signed-off-by: Alastair D'Silva
---
arch/powerpc/mm/mem.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 85b40bad90c0..4f892da59a6a 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -104,6 +104,27 @@ int __weak remove_section_mapping(unsigned long start,
unsigned long end)
return -ENODEV;
}
+#define FLUSH_CHUNK_SIZE SZ_1G
+/**
+ * flush_dcache_range_chunked(): Write any modified data cache blocks out to
+ * memory and invalidate them, in chunks of up to FLUSH_CHUNK_SIZE
+ * Does not invalidate the corresponding instruction cache blocks.
+ *
+ * @start: the start address
+ * @stop: the stop address (exclusive)
+ * @chunk: the max size of the chunks
+ */
+static void flush_dcache_range_chunked(unsigned long start, unsigned long stop,
+ unsigned long chunk)
+{
+ unsigned long i;
+
+ for (i = start; i < stop; i += FLUSH_CHUNK_SIZE) {
+ flush_dcache_range(i, min(stop, start + FLUSH_CHUNK_SIZE));
+ cond_resched();
+ }
+}
+
int __ref arch_add_memory(int nid, u64 start, u64 size,
struct mhp_restrictions *restrictions)
{
@@ -120,7 +141,8 @@ int __ref arch_add_memory(int nid, u64 start, u64 size,
start, start + size, rc);
return -EFAULT;
}
- flush_dcache_range(start, start + size);
+
+ flush_dcache_range_chunked(start, start + size, FLUSH_CHUNK_SIZE);
return __add_pages(nid, start_pfn, nr_pages, restrictions);
}
@@ -137,7 +159,8 @@ void __ref arch_remove_memory(int nid, u64 start, u64 size,
/* Remove htab bolted mappings for this section of memory */
start = (unsigned long)__va(start);
- flush_dcache_range(start, start + size);
+ flush_dcache_range_chunked(start, start + size, FLUSH_CHUNK_SIZE);
+
ret = remove_section_mapping(start, start + size);
WARN_ON_ONCE(ret);
--
2.21.0
[PATCH v3 2/5] powerpc: define helpers to get L1 icache sizes
From: Alastair D'Silva
This patch adds helpers to retrieve icache sizes, and renames the existing
helpers to make it clear that they are for dcache.
Signed-off-by: Alastair D'Silva
---
arch/powerpc/include/asm/cache.h | 29 +++
arch/powerpc/include/asm/cacheflush.h | 12 +--
2 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/cache.h b/arch/powerpc/include/asm/cache.h
index b3388d95f451..f852d5cd746c 100644
--- a/arch/powerpc/include/asm/cache.h
+++ b/arch/powerpc/include/asm/cache.h
@@ -55,25 +55,46 @@ struct ppc64_caches {
extern struct ppc64_caches ppc64_caches;
-static inline u32 l1_cache_shift(void)
+static inline u32 l1_dcache_shift(void)
{
return ppc64_caches.l1d.log_block_size;
}
-static inline u32 l1_cache_bytes(void)
+static inline u32 l1_dcache_bytes(void)
{
return ppc64_caches.l1d.block_size;
}
+
+static inline u32 l1_icache_shift(void)
+{
+ return ppc64_caches.l1i.log_block_size;
+}
+
+static inline u32 l1_icache_bytes(void)
+{
+ return ppc64_caches.l1i.block_size;
+}
#else
-static inline u32 l1_cache_shift(void)
+static inline u32 l1_dcache_shift(void)
{
return L1_CACHE_SHIFT;
}
-static inline u32 l1_cache_bytes(void)
+static inline u32 l1_dcache_bytes(void)
{
return L1_CACHE_BYTES;
}
+
+static inline u32 l1_icache_shift(void)
+{
+ return L1_CACHE_SHIFT;
+}
+
+static inline u32 l1_icache_bytes(void)
+{
+ return L1_CACHE_BYTES;
+}
+
#endif
#endif /* ! __ASSEMBLY__ */
diff --git a/arch/powerpc/include/asm/cacheflush.h
b/arch/powerpc/include/asm/cacheflush.h
index eef388f2659f..ed57843ef452 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -63,8 +63,8 @@ static inline void __flush_dcache_icache_phys(unsigned long
physaddr)
*/
static inline void flush_dcache_range(unsigned long start, unsigned long stop)
{
- unsigned long shift = l1_cache_shift();
- unsigned long bytes = l1_cache_bytes();
+ unsigned long shift = l1_dcache_shift();
+ unsigned long bytes = l1_dcache_bytes();
void *addr = (void *)(start & ~(bytes - 1));
unsigned long size = stop - (unsigned long)addr + (bytes - 1);
unsigned long i;
@@ -89,8 +89,8 @@ static inline void flush_dcache_range(unsigned long start,
unsigned long stop)
*/
static inline void clean_dcache_range(unsigned long start, unsigned long stop)
{
- unsigned long shift = l1_cache_shift();
- unsigned long bytes = l1_cache_bytes();
+ unsigned long shift = l1_dcache_shift();
+ unsigned long bytes = l1_dcache_bytes();
void *addr = (void *)(start & ~(bytes - 1));
unsigned long size = stop - (unsigned long)addr + (bytes - 1);
unsigned long i;
@@ -108,8 +108,8 @@ static inline void clean_dcache_range(unsigned long start,
unsigned long stop)
static inline void invalidate_dcache_range(unsigned long start,
unsigned long stop)
{
- unsigned long shift = l1_cache_shift();
- unsigned long bytes = l1_cache_bytes();
+ unsigned long shift = l1_dcache_shift();
+ unsigned long bytes = l1_dcache_bytes();
void *addr = (void *)(start & ~(bytes - 1));
unsigned long size = stop - (unsigned long)addr + (bytes - 1);
unsigned long i;
--
2.21.0
[PATCH v3 0/5] powerpc: convert cache asm to C
From: Alastair D'Silva This series addresses a few issues discovered in how we flush caches: 1. Flushes were truncated at 4GB, so larger flushes were incorrect. 2. Flushing the dcache in arch_add_memory was unnecessary This series also converts much of the cache assembler to C, with the aim of making it easier to maintain. Alastair D'Silva (6): powerpc: Allow flush_icache_range to work across ranges >4GB powerpc: define helpers to get L1 icache sizes powerpc: Convert flush_icache_range & friends to C powerpc: Chunk calls to flush_dcache_range in arch_*_memory powerpc: Remove 'extern' from func prototypes in cache headers powerpc: Don't flush caches when adding memory Changelog: V3: - factor out chunking loop - Replace __asm__ __volatile__ with asm volatile - Replace flush_coherent_icache_or_return macro with flush_coherent_icache function - factor our invalidate_icache_range - Replace code duplicating clean_dcache_range() in __flush_dcache_icache() with a call to clean_dcache_range() - Remove redundant #ifdef CONFIG_44x - Fix preprocessor logic: #if !defined(CONFIG_PPC_8xx) & !defined(CONFIG_PPC64) - Added loop(1|2) to earlyclobbers in flush_dcache_icache_phys - Drop "Remove extern" patch - Replace 32 bit shifts in 64 bit VDSO with 64 bit ones V2: - Replace C implementation of flush_dcache_icache_phys() with inline assembler authored by Christophe Leroy - Add memory clobbers for iccci implementation - Give __flush_dcache_icache a real implementation, it can't just be a wrapper around flush_icache_range() - Remove PPC64_CACHES from misc_64.S - Replace code duplicating clean_dcache_range() in flush_icache_range() with a call to clean_dcache_range() - Replace #ifdef CONFIG_44x with IS_ENABLED(...) in flush_icache_cange() - Use 1GB chunks instead of 16GB in arch_*_memory Alastair D'Silva (5): powerpc: Allow flush_icache_range to work across ranges >4GB powerpc: define helpers to get L1 icache sizes powerpc: Convert flush_icache_range & friends to C powerpc: Chunk calls to flush_dcache_range in arch_*_memory powerpc: Don't flush caches when adding memory arch/powerpc/include/asm/cache.h| 55 +--- arch/powerpc/include/asm/cacheflush.h | 36 +++-- arch/powerpc/kernel/misc_32.S | 117 arch/powerpc/kernel/misc_64.S | 102 -- arch/powerpc/kernel/vdso64/cacheflush.S | 4 +- arch/powerpc/mm/mem.c | 176 +++- 6 files changed, 228 insertions(+), 262 deletions(-) -- 2.21.0
[PATCH v3 1/5] powerpc: Allow flush_icache_range to work across ranges >4GB
From: Alastair D'Silva When calling flush_icache_range with a size >4GB, we were masking off the upper 32 bits, so we would incorrectly flush a range smaller than intended. __kernel_sync_dicache in the 64 bit VDSO has the same bug. This patch replaces the 32 bit shifts with 64 bit ones, so that the full size is accounted for. Signed-off-by: Alastair D'Silva Cc: sta...@vger.kernel.org --- arch/powerpc/kernel/misc_64.S | 4 ++-- arch/powerpc/kernel/vdso64/cacheflush.S | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S index b55a7b4cb543..9bc0aa9aeb65 100644 --- a/arch/powerpc/kernel/misc_64.S +++ b/arch/powerpc/kernel/misc_64.S @@ -82,7 +82,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) subfr8,r6,r4/* compute length */ add r8,r8,r5/* ensure we get enough */ lwz r9,DCACHEL1LOGBLOCKSIZE(r10)/* Get log-2 of cache block size */ - srw.r8,r8,r9/* compute line count */ + srd.r8,r8,r9/* compute line count */ beqlr /* nothing to do? */ mtctr r8 1: dcbst 0,r6 @@ -98,7 +98,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE) subfr8,r6,r4/* compute length */ add r8,r8,r5 lwz r9,ICACHEL1LOGBLOCKSIZE(r10)/* Get log-2 of Icache block size */ - srw.r8,r8,r9/* compute line count */ + srd.r8,r8,r9/* compute line count */ beqlr /* nothing to do? */ mtctr r8 2: icbi0,r6 diff --git a/arch/powerpc/kernel/vdso64/cacheflush.S b/arch/powerpc/kernel/vdso64/cacheflush.S index 3f92561a64c4..526f5ba2593e 100644 --- a/arch/powerpc/kernel/vdso64/cacheflush.S +++ b/arch/powerpc/kernel/vdso64/cacheflush.S @@ -35,7 +35,7 @@ V_FUNCTION_BEGIN(__kernel_sync_dicache) subfr8,r6,r4/* compute length */ add r8,r8,r5/* ensure we get enough */ lwz r9,CFG_DCACHE_LOGBLOCKSZ(r10) - srw.r8,r8,r9/* compute line count */ + srd.r8,r8,r9/* compute line count */ crclr cr0*4+so beqlr /* nothing to do? */ mtctr r8 @@ -52,7 +52,7 @@ V_FUNCTION_BEGIN(__kernel_sync_dicache) subfr8,r6,r4/* compute length */ add r8,r8,r5 lwz r9,CFG_ICACHE_LOGBLOCKSZ(r10) - srw.r8,r8,r9/* compute line count */ + srd.r8,r8,r9/* compute line count */ crclr cr0*4+so beqlr /* nothing to do? */ mtctr r8 -- 2.21.0
Re: [PATCH v3 bpf-next 12/14] samples: bpf: makefile: provide C/CXX/LD flags to libbpf
On Mon, Sep 16, 2019 at 3:58 AM Ivan Khoronzhuk wrote: > > In order to build libs using C/CXX/LD flags of target arch, > provide them to libbpf make. > > Signed-off-by: Ivan Khoronzhuk > --- > samples/bpf/Makefile | 14 +++--- > 1 file changed, 11 insertions(+), 3 deletions(-) > > diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile > index 18ec22e7b444..133123d4c7d7 100644 > --- a/samples/bpf/Makefile > +++ b/samples/bpf/Makefile > @@ -182,8 +182,6 @@ ifdef CROSS_COMPILE > TPROGS_CFLAGS += -Wall > TPROGS_CFLAGS += -O2 > TPROGS_CFLAGS += -fomit-frame-pointer > -TPROGS_CFLAGS += -Wmissing-prototypes > -TPROGS_CFLAGS += -Wstrict-prototypes > else > TPROGS_LDLIBS := $(KBUILD_HOSTLDLIBS) > TPROGS_CFLAGS += $(KBUILD_HOSTCFLAGS) $(HOST_EXTRACFLAGS) > @@ -196,6 +194,14 @@ TPROGS_CFLAGS += -I$(srctree)/tools/lib/ > TPROGS_CFLAGS += -I$(srctree)/tools/include > TPROGS_CFLAGS += -I$(srctree)/tools/perf > > +EXTRA_CXXFLAGS := $(TPROGS_CFLAGS) > + > +# options not valid for C++ > +ifdef CROSS_COMPILE > +$(TPROGS_CFLAGS) += -Wmissing-prototypes > +$(TPROGS_CFLAGS) += -Wstrict-prototypes > +endif > + ugh, let's really get rid of dependency on C++ compiler, as suggested for previous patch. > TPROGCFLAGS_bpf_load.o += -Wno-unused-variable > > TPROGS_LDLIBS += $(LIBBPF) -lelf > @@ -257,7 +263,9 @@ clean: > > $(LIBBPF): FORCE > # Fix up variables inherited from Kbuild that tools/ build system won't like > - $(MAKE) -C $(dir $@) RM='rm -rf' LDFLAGS= > srctree=$(BPF_SAMPLES_PATH)/../../ O= > + $(MAKE) -C $(dir $@) RM='rm -rf' EXTRA_CFLAGS="$(TPROGS_CFLAGS)" \ > + EXTRA_CXXFLAGS="$(EXTRA_CXXFLAGS)" LDFLAGS=$(TPROGS_LDFLAGS) \ > + srctree=$(BPF_SAMPLES_PATH)/../../ O= > > $(obj)/syscall_nrs.h: $(obj)/syscall_nrs.s FORCE > $(call filechk,offsets,__SYSCALL_NRS_H__) > -- > 2.17.1 >
Re: [linux-sunxi] [PATCH] clk: sunxi-ng: h6: Use sigma-delta modulation for audio PLL
Dne torek, 17. september 2019 ob 08:54:08 CEST je Chen-Yu Tsai napisal(a):
> On Sat, Sep 14, 2019 at 9:51 PM Jernej Skrabec
wrote:
> > Audio devices needs exact clock rates in order to correctly reproduce
> > the sound. Until now, only integer factors were used to configure H6
> > audio PLL which resulted in inexact rates. Fix that by adding support
> > for fractional factors using sigma-delta modulation look-up table. It
> > contains values for two most commonly used audio base frequencies.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/clk/sunxi-ng/ccu-sun50i-h6.c | 21 +++--
> > 1 file changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6.c
> > b/drivers/clk/sunxi-ng/ccu-sun50i-h6.c index d89353a3cdec..ed6338d74474
> > 100644
> > --- a/drivers/clk/sunxi-ng/ccu-sun50i-h6.c
> > +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6.c
> > @@ -203,12 +203,21 @@ static struct ccu_nkmp pll_hsic_clk = {
> >
> > * hardcode it to match with the clock names.
> > */
> >
> > #define SUN50I_H6_PLL_AUDIO_REG0x078
> >
> > +
> > +static struct ccu_sdm_setting pll_audio_sdm_table[] = {
> > + { .rate = 541900800, .pattern = 0xc001288d, .m = 1, .n = 22 },
> > + { .rate = 589824000, .pattern = 0xc00126e9, .m = 1, .n = 24 },
> > +};
> > +
> >
> > static struct ccu_nm pll_audio_base_clk = {
> >
> > .enable = BIT(31),
> > .lock = BIT(28),
> > .n = _SUNXI_CCU_MULT_MIN(8, 8, 12),
> > .m = _SUNXI_CCU_DIV(1, 1), /* input divider */
> >
> > + .sdm= _SUNXI_CCU_SDM(pll_audio_sdm_table,
> > +BIT(24), 0x178, BIT(31)),
> >
> > .common = {
> >
> > + .features = CCU_FEATURE_SIGMA_DELTA_MOD,
> >
> > .reg= 0x078,
> > .hw.init= CLK_HW_INIT("pll-audio-base", "osc24M",
> >
> > _nm_ops,
> >
> > @@ -753,12 +762,12 @@ static const struct clk_hw *clk_parent_pll_audio[] =
> > {>
> > };
> >
> > /*
> >
> > - * The divider of pll-audio is fixed to 8 now, as pll-audio-4x has a
> > - * fixed post-divider 2.
> > + * The divider of pll-audio is fixed to 24 for now, so 24576000 and
> > 22579200 + * rates can be set exactly in conjunction with sigma-delta
> > modulation.>
> > */
> >
> > static CLK_FIXED_FACTOR_HWS(pll_audio_clk, "pll-audio",
> >
> > clk_parent_pll_audio,
> >
> > - 8, 1, CLK_SET_RATE_PARENT);
> > + 24, 1, CLK_SET_RATE_PARENT);
> >
> > static CLK_FIXED_FACTOR_HWS(pll_audio_2x_clk, "pll-audio-2x",
> >
> > clk_parent_pll_audio,
> > 4, 1, CLK_SET_RATE_PARENT);
>
> You need to fix the factors for the other two outputs as well, since all
> three are derived from pll-audio-base.
Fix how? pll-audio-2x and pll-audio-4x clocks have fixed divider in regards to
pll-audio-base, while pll-audio has not. Unless you mean changing their name?
Best regards,
Jernej
>
> ChenYu
>
> > @@ -1215,12 +1224,12 @@ static int sun50i_h6_ccu_probe(struct
> > platform_device *pdev)>
> > }
> >
> > /*
> >
> > -* Force the post-divider of pll-audio to 8 and the output divider
> > -* of it to 1, to make the clock name represents the real
> > frequency. +* Force the post-divider of pll-audio to 12 and the
> > output divider +* of it to 2, so 24576000 and 22579200 rates can
> > be set exactly.>
> > */
> >
> > val = readl(reg + SUN50I_H6_PLL_AUDIO_REG);
> > val &= ~(GENMASK(21, 16) | BIT(0));
> >
> > - writel(val | (7 << 16), reg + SUN50I_H6_PLL_AUDIO_REG);
> > + writel(val | (11 << 16) | BIT(0), reg + SUN50I_H6_PLL_AUDIO_REG);
> >
> > /*
> >
> > * First clock parent (osc32K) is unusable for CEC. But since
> > there
> >
> > --
> > 2.23.0
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "linux-sunxi" group. To unsubscribe from this group and stop receiving
> > emails from it, send an email to
> > linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the
> > web, visit
> > https://groups.google.com/d/msgid/linux-sunxi/20190914135100.327412-1-jer
> > nej.skrabec%40siol.net.
Re: [PATCH v3 bpf-next 11/14] libbpf: makefile: add C/CXX/LDFLAGS to libbpf.so and test_libpf targets
On Mon, Sep 16, 2019 at 4:00 AM Ivan Khoronzhuk wrote: > > In case of LDFLAGS and EXTRA_CC/CXX flags there is no way to pass them > correctly to build command, for instance when --sysroot is used or > external libraries are used, like -lelf, wich can be absent in > toolchain. This can be used for samples/bpf cross-compiling allowing > to get elf lib from sysroot. > > Signed-off-by: Ivan Khoronzhuk > --- > tools/lib/bpf/Makefile | 11 --- > 1 file changed, 8 insertions(+), 3 deletions(-) > > diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile > index c6f94cffe06e..bccfa556ef4e 100644 > --- a/tools/lib/bpf/Makefile > +++ b/tools/lib/bpf/Makefile > @@ -94,6 +94,10 @@ else >CFLAGS := -g -Wall > endif > > +ifdef EXTRA_CXXFLAGS > + CXXFLAGS := $(EXTRA_CXXFLAGS) > +endif > + > ifeq ($(feature-libelf-mmap), 1) >override CFLAGS += -DHAVE_LIBELF_MMAP_SUPPORT > endif > @@ -176,8 +180,9 @@ $(BPF_IN): force elfdep bpfdep > $(OUTPUT)libbpf.so: $(OUTPUT)libbpf.so.$(LIBBPF_VERSION) > > $(OUTPUT)libbpf.so.$(LIBBPF_VERSION): $(BPF_IN) > - $(QUIET_LINK)$(CC) --shared > -Wl,-soname,libbpf.so.$(LIBBPF_MAJOR_VERSION) \ > - -Wl,--version-script=$(VERSION_SCRIPT) $^ > -lelf -o $@ > + $(QUIET_LINK)$(CC) $(LDFLAGS) \ > + --shared -Wl,-soname,libbpf.so.$(LIBBPF_MAJOR_VERSION) \ > + -Wl,--version-script=$(VERSION_SCRIPT) $^ -lelf -o $@ > @ln -sf $(@F) $(OUTPUT)libbpf.so > @ln -sf $(@F) $(OUTPUT)libbpf.so.$(LIBBPF_MAJOR_VERSION) > > @@ -185,7 +190,7 @@ $(OUTPUT)libbpf.a: $(BPF_IN) > $(QUIET_LINK)$(RM) $@; $(AR) rcs $@ $^ > > $(OUTPUT)test_libbpf: test_libbpf.cpp $(OUTPUT)libbpf.a > - $(QUIET_LINK)$(CXX) $(INCLUDES) $^ -lelf -o $@ > + $(QUIET_LINK)$(CXX) $(CXXFLAGS) $(LDFLAGS) $(INCLUDES) $^ -lelf -o $@ Instead of doing ifdef EXTRA_CXXFLAGS bit above, you can just include both $(CXXFLAGS) and $(EXTRA_CXXFLAGS), which will do the right thing (and is actually recommended my make documentation way to do this). But actually, there is no need to use C++ compiler here, test_libbpf.cpp can just be plain C. Do you mind renaming it to .c and using C compiler instead? > > $(OUTPUT)libbpf.pc: > $(QUIET_GEN)sed -e "s|@PREFIX@|$(prefix)|" \ > -- > 2.17.1 >
Re: printk meeting at LPC
On (09/18/19 11:36), Sergey Senozhatsky wrote:
[..]
> For instance, tty/sysrq must be able to switch printk emergency on/off.
> That already means that printk emergency knob should be visible to the
> rest of the kernel. A long time ago, we had printk_emergency_begin_sync()
> and printk_emergency_end_sync(), which would define reentrable
> printk_emergency blocks [1]:
>
> printk_emergency_begin_sync();
> handle_sysrq();
> printk_emergency_end_sync();
Some explanations.
How did we come up to that _sync() printk() emergency mode (when we
make sure that there is no active printing kthread)? We had a number
of cases (complaints) of lost kernel messages. There are scenarios
in which we cannot offload to async preemptible printing kthread,
because current control path is, for instance, going to reboot the
kernel. In sync printk() mode we have some sort (!) of guarantees
that when we do
pr_emerg("Restarting system\n");
kmsg_dump(KMSG_DUMP_RESTART);
machine_restart(cmd);
pr_emerg("Restarting system\n") is going to flush logbuf before the
system will machine_restart().
I can also recall a regression report from 0day bot. 0day uses sysrq over
serial to reboot running qemu instances. The way things currently work
is that we have printk() in sysrq handler, which flushes logbuf before
it reboots the system. With printk_kthread offloading this "flush logbuf
before reboot()" was not there, because printing was offloaded to kthread,
so the system used to immediately reboot with pending (and thus lost)
logbuf messages.
I suspect that emergency flush from sysrq is easier to handle once we
have one global printing kthread.
Suppose:
logbuf
id 100
id 101
id 102
...
id 198 <- printing kthread
id 199
id 200
<+> sysrq, a bunch of printk()-s in emergency flush mode
id 201 -> atomic_write()
id 202 -> atomic_write()
...
id 300 -> atomic_write()
<-> sysrq iret
When we park printing kthread, we make sure that the first sysrq->printk()
will also print pending messages 198,199,200 before it prints message 201.
When we unpark printing kthread it knows that there are no pending messages
(last printed message id is in the logbuf head).
It's going to be a bit harder when we have per-console kthread. If
per-console kthread is simply gogin to continue from the last message id
it printed (e.g. 198) then it will re-print messages which we already
printed via ->atomic_write() path. If all per-console printing kthread
are going to jump to id 300, because this is the last printed id on
consoles, then we can lose some messages on consoles (possibly a different
number of messages on different consoles, depending on console's kthread
position).
Once again, I'm sorry I was not on LPC/KS and maybe you have already
discussed all of those cases and got everything covered.
-ss
[PATCH] RDMA: release allocated skb
In create_cq, the allocated skb buffer needs to be released on error
path.
Signed-off-by: Navid Emamdoost
---
drivers/infiniband/hw/cxgb4/cq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/infiniband/hw/cxgb4/cq.c b/drivers/infiniband/hw/cxgb4/cq.c
index b1bb61c65f4f..841a395d9896 100644
--- a/drivers/infiniband/hw/cxgb4/cq.c
+++ b/drivers/infiniband/hw/cxgb4/cq.c
@@ -166,6 +166,7 @@ static int create_cq(struct c4iw_rdev *rdev, struct t4_cq
*cq,
if (user && !cq->bar2_pa) {
pr_warn("%s: cqid %u not in BAR2 range\n",
pci_name(rdev->lldi.pdev), cq->cqid);
+ kfree_skb(skb);
ret = -EINVAL;
goto err4;
}
--
2.17.1
Re: [PATCH 0/2] pseries/hotplug: Change the default behaviour of cede_offline
Nathan Lynch writes: > Gautham R Shenoy writes: >> On Thu, Sep 12, 2019 at 10:39:45AM -0500, Nathan Lynch wrote: >>> "Gautham R. Shenoy" writes: >>> > The patchset also defines a new sysfs attribute >>> > "/sys/device/system/cpu/cede_offline_enabled" on PSeries Linux guests >>> > to allow userspace programs to change the state into which the >>> > offlined CPU need to be put to at runtime. >>> >>> A boolean sysfs interface will become awkward if we need to add another >>> mode in the future. >>> >>> What do you think about naming the attribute something like >>> 'offline_mode', with the possible values 'extended-cede' and >>> 'rtas-stopped'? >> >> We can do that. However, IMHO in the longer term, on PSeries guests, >> we should have only one offline state - rtas-stopped. The reason for >> this being, that on Linux, SMT switch is brought into effect through >> the CPU Hotplug interface. The only state in which the SMT switch will >> recognized by the hypervisors such as PHYP is rtas-stopped. > > OK. Why "longer term" though, instead of doing it now? > > >> All other states (such as extended-cede) should in the long-term be >> exposed via the cpuidle interface. >> >> With this in mind, I made the sysfs interface boolean to mirror the >> current "cede_offline" commandline parameter. Eventually when we have >> only one offline-state, we can deprecate the commandline parameter as >> well as the sysfs interface. > > I don't care for adding a sysfs interface that is intended from the > beginning to become vestigial... > > This strikes me as unnecessarily incremental if you're changing the > default offline state. Any user space programs depending on the current > behavior will have to change anyway (and why is it OK to break them?) > > Why isn't the plan: > > 1. Add extended cede support to the pseries cpuidle driver > 2. Make stop-self the only cpu offline state for pseries (no sysfs > interface necessary) I agree, that would be preferable. Adding more sysfs tunables sucks, especially if they're going to be deprecated in the not too distant future. Another option would be to add extended cede to the cpuidle driver, and retain the cede_offline boot parameter but make it false by default. cheers
Re: [PATCH 0/2] pseries/hotplug: Change the default behaviour of cede_offline
"Gautham R. Shenoy" writes:
> From: "Gautham R. Shenoy"
>
> Currently on Pseries Linux Guests, the offlined CPU can be put to one
> of the following two states:
>- Long term processor cede (also called extended cede)
>- Returned to the Hypervisor via RTAS "stop-self" call.
>
> This is controlled by the kernel boot parameter "cede_offline=on/off".
>
> By default the offlined CPUs enter extended cede.
Since commit 3aa565f53c39 ("powerpc/pseries: Add hooks to put the CPU into an
appropriate offline state") (Nov 2009)
Which you wrote :)
Why was that wrong?
> The PHYP hypervisor considers CPUs in extended cede to be "active"
> since the CPUs are still under the control fo the Linux Guests. Hence, when
> we change the
> SMT modes by offlining the secondary CPUs, the PURR and the RWMR SPRs
> will continue to count the values for offlined CPUs in extended cede
> as if they are online.
>
> One of the expectations with PURR is that the for an interval of time,
> the sum of the PURR increments across the online CPUs of a core should
> equal the number of timebase ticks for that interval.
>
> This is currently not the case.
But why does that matter? It's just some accounting stuff, does it
actually break something meaningful?
Also what does this do to the latency of CPU online/offline.
And what does this do on KVM?
> In the following data (Generated using
> https://github.com/gautshen/misc/blob/master/purr_tb.py):
>
>
> delta tb = tb ticks elapsed in 1 second.
> delta purr = sum of PURR increments on online CPUs of that core in 1
>second
>
> SMT=off
> ===
> Core delta tb(apprx) delta purr
> ===
> core00 [ 0] 51200 69883784
> core01 [ 8] 51200 88782536
> core02 [ 16] 51200 94296824
> core03 [ 24] 51200 80951968
Showing the expected value in another column would make this much
clearer.
cheers
> SMT=2
> ===
> Coredelta tb(apprx) delta purr
> ===
> core00 [ 0,1]51200 136147792
> core01 [ 8,9]51200 128636784
> core02 [ 16,17] 51200 135426488
> core03 [ 24,25] 51200 153027520
>
> SMT=4
> ===
> Core delta tb(apprx) delta purr
> ===
> core00 [ 0,1,2,3]51200 258331616
> core01 [ 8,9,10,11] 51200 274220072
> core02 [ 16,17,18,19] 51200 260013736
> core03 [ 24,25,26,27] 51200 260079672
>
> SMT=on
> ===
> Core delta tb(apprx) delta purr
> ===
> core00 [ 0,1,2,3,4,5,6,7]51200 512941248
> core01 [ 8,9,10,11,12,13,14,15] 51200 512936544
> core02 [ 16,17,18,19,20,21,22,23] 51200 512931544
> core03 [ 24,25,26,27,28,29,30,31] 51200 512923800
>
> This patchset addresses this issue by ensuring that by default, the
> offlined CPUs are returned to the Hypervisor via RTAS "stop-self" call
> by changing the default value of "cede_offline_enabled" to false.
>
> The patchset also defines a new sysfs attribute
> "/sys/device/system/cpu/cede_offline_enabled" on PSeries Linux guests
> to allow userspace programs to change the state into which the
> offlined CPU need to be put to at runtime. This is intended for
> userspace programs that fold CPUs for the purpose of saving energy
> when the utilization is low. Setting the value of this attribute
> ensures that subsequent CPU offline operations will put the offlined
> CPUs to extended cede. However, it will cause inconsistencies in the
> PURR accounting. Clearing the attribute will make the offlined CPUs
> call the RTAS "stop-self" call thereby returning the CPU to the
> hypervisor.
>
> With the patches,
>
> SMT=off
> ===
> Core delta tb(apprx) delta purr
> ===
> core00 [ 0] 51200512527568
> core01 [ 8] 51200512556128
> core02 [ 16] 51200512590016
> core03 [ 24] 51200512589440
>
> SMT=2
> ===
> Coredelta tb(apprx)delta purr
> ===
> core00 [ 0,1]51200 512635328
> core01 [ 8,9]51200 512610416
> core02 [ 16,17] 51200 512639360
> core03 [ 24,25] 51200 512638720
>
> SMT=4
>
Re: [PATCH V2 2/2] mm/pgtable/debug: Add test validating architecture page table helpers
On 09/13/2019 03:31 PM, Christophe Leroy wrote:
>
>
> Le 13/09/2019 à 11:02, Anshuman Khandual a écrit :
>>
+#if !defined(__PAGETABLE_PMD_FOLDED) && !defined(__ARCH_HAS_4LEVEL_HACK)
>>>
>>> #ifdefs have to be avoided as much as possible, see below
>>
>> Yeah but it has been bit difficult to avoid all these $ifdef because of the
>> availability (or lack of it) for all these pgtable helpers in various config
>> combinations on all platforms.
>
> As far as I can see these pgtable helpers should exist everywhere at least
> via asm-generic/ files.
But they might not actually do the right thing.
>
> Can you spot a particular config which fails ?
Lets consider the following example (after removing the $ifdefs around it)
which though builds successfully but fails to pass the intended test. This
is with arm64 config 4K pages sizes with 39 bits VA space which ends up
with a 3 level page table arrangement.
static void __init p4d_clear_tests(p4d_t *p4dp)
{
p4d_t p4d = READ_ONCE(*p4dp);
p4d = __p4d(p4d_val(p4d) | RANDOM_ORVALUE);
WRITE_ONCE(*p4dp, p4d);
p4d_clear(p4dp);
p4d = READ_ONCE(*p4dp);
WARN_ON(!p4d_none(p4d));
}
The following test hits an error at WARN_ON(!p4d_none(p4d))
[ 16.757333] [ cut here ]
[ 16.758019] WARNING: CPU: 11 PID: 1 at mm/arch_pgtable_test.c:187
arch_pgtable_tests_init+0x24c/0x474
[ 16.759455] Modules linked in:
[ 16.759952] CPU: 11 PID: 1 Comm: swapper/0 Not tainted
5.3.0-next-20190916-5-g61c218153bb8-dirty #222
[ 16.761449] Hardware name: linux,dummy-virt (DT)
[ 16.762185] pstate: 0045 (nzcv daif +PAN -UAO)
[ 16.762964] pc : arch_pgtable_tests_init+0x24c/0x474
[ 16.763750] lr : arch_pgtable_tests_init+0x174/0x474
[ 16.764534] sp : ffc011d7bd50
[ 16.765065] x29: ffc011d7bd50 x28: 1756bac0
[ 16.765908] x27: ff85ddaf3000 x26: 02e8
[ 16.766767] x25: ffc0111ce000 x24: ff85ddaf32e8
[ 16.767606] x23: ff85ddaef278 x22: 0045cc844000
[ 16.768445] x21: 00065daef003 x20: 1754
[ 16.769283] x19: ff85ddb6 x18: 0014
[ 16.770122] x17: 980426bb x16: 698594c6
[ 16.770976] x15: 66e25a88 x14:
[ 16.771813] x13: 1754 x12: 000a
[ 16.772651] x11: ff85fcfd0a40 x10: 0001
[ 16.773488] x9 : 0008 x8 : ffc01143ab26
[ 16.774336] x7 : x6 :
[ 16.775180] x5 : x4 :
[ 16.776018] x3 : 1756bbe8 x2 : 00065daeb003
[ 16.776856] x1 : 0065daeb x0 : f000
[ 16.777693] Call trace:
[ 16.778092] arch_pgtable_tests_init+0x24c/0x474
[ 16.778843] do_one_initcall+0x74/0x1b0
[ 16.779458] kernel_init_freeable+0x1cc/0x290
[ 16.780151] kernel_init+0x10/0x100
[ 16.780710] ret_from_fork+0x10/0x18
[ 16.781282] ---[ end trace 042e6c40c0a3b038 ]---
On arm64 (4K page size|39 bits VA|3 level page table)
#elif CONFIG_PGTABLE_LEVELS == 3/* Applicable here */
#define __ARCH_USE_5LEVEL_HACK
#include
Which pulls in
#include
which pulls in
#include
which defines
static inline int p4d_none(p4d_t p4d)
{
return 0;
}
which will invariably trigger WARN_ON(!p4d_none(p4d)).
Similarly for next test p4d_populate_tests() which will always be
successful because p4d_bad() invariably returns negative.
static inline int p4d_bad(p4d_t p4d)
{
return 0;
}
static void __init p4d_populate_tests(struct mm_struct *mm, p4d_t *p4dp,
pud_t *pudp)
{
p4d_t p4d;
/*
* This entry points to next level page table page.
* Hence this must not qualify as p4d_bad().
*/
pud_clear(pudp);
p4d_clear(p4dp);
p4d_populate(mm, p4dp, pudp);
p4d = READ_ONCE(*p4dp);
WARN_ON(p4d_bad(p4d));
}
We should not run these tests for the above config because they are
not applicable and will invariably produce same result.
>
>>
>>>
>
> [...]
>
+#if !defined(__PAGETABLE_PUD_FOLDED) && !defined(__ARCH_HAS_5LEVEL_HACK)
>>>
>>> The same can be done here.
>>
>> IIRC not only the page table helpers but there are data types (pxx_t) which
>> were not present on various configs and these wrappers help prevent build
>> failures. Any ways will try and see if this can be improved further. But
>> meanwhile if you have some suggestions, please do let me know.
>
> pgt_t and pmd_t are everywhere I guess.
> then pud_t and p4d_t have fallbacks in asm-generic files.
Lets take another example where it fails to compile. On arm64 with 16K
page size, 48 bits VA, 4 level page table arrangement in the following
test, pgd_populate() does not have the required signature.
static void pgd_populate_tests(struct mm_struct *mm, pgd_t *pgdp, p4d_t *p4dp)
{
pgd_t pgd;
if (mm_p4d_folded(mm))
Re: [PATCH] clk: sprd: add missing kfree
Quoting Chunyan Zhang (2019-09-05 03:30:09)
> From: Chunyan Zhang
>
> The number of config registers for different pll clocks probably are not
> same, so we have to use malloc, and should free the memory before return.
>
> Fixes: 3e37b005580b ("clk: sprd: add adjustable pll support")
> Signed-off-by: Chunyan Zhang
> Signed-off-by: Chunyan Zhang
> ---
Applied to clk-next
Re: [PATCH] clk: at91: allow 24 Mhz clock as input for PLL
Quoting eugen.hris...@microchip.com (2019-09-10 23:39:20) > From: Eugen Hristev > > The PLL input range needs to be able to allow 24 Mhz crystal as input > Update the range accordingly in plla characteristics struct > > Signed-off-by: Eugen Hristev > --- Applied to clk-next
Re: [PATCH 2/2] clk: socfpga: agilex: add clock driver for the Agilex platform
Quoting Dinh Nguyen (2019-09-17 18:34:59)
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 0cad76021297..ef2c96c0f1e0 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -18,6 +18,7 @@ endif
>
> # hardware specific clock types
> # please keep this section sorted lexicographically by file path name
> +obj-$(CONFIG_ARCH_AGILEX) += socfpga/
Sort by filepath, so all files come before all directories, and
directories have a different section in this file.
> obj-$(CONFIG_MACH_ASM9260) += clk-asm9260.o
> obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN)+= clk-axi-clkgen.o
> obj-$(CONFIG_ARCH_AXXIA) += clk-axm5516.o
> diff --git a/drivers/clk/socfpga/Makefile b/drivers/clk/socfpga/Makefile
> index ce5aa7802eb8..bf736f8d201a 100644
> --- a/drivers/clk/socfpga/Makefile
> +++ b/drivers/clk/socfpga/Makefile
> @@ -3,3 +3,5 @@ obj-$(CONFIG_ARCH_SOCFPGA) += clk.o clk-gate.o clk-pll.o
> clk-periph.o
> obj-$(CONFIG_ARCH_SOCFPGA) += clk-pll-a10.o clk-periph-a10.o clk-gate-a10.o
> obj-$(CONFIG_ARCH_STRATIX10) += clk-s10.o
> obj-$(CONFIG_ARCH_STRATIX10) += clk-pll-s10.o clk-periph-s10.o clk-gate-s10.o
> +obj-$(CONFIG_ARCH_AGILEX) += clk-agilex.o
> +obj-$(CONFIG_ARCH_AGILEX) += clk-pll-s10.o clk-periph-s10.o clk-gate-s10.o
Preferably keep this sorted on Kconfig name.
> diff --git a/drivers/clk/socfpga/clk-agilex.c
> b/drivers/clk/socfpga/clk-agilex.c
> new file mode 100644
> index ..7d5093f0b2c9
> --- /dev/null
> +++ b/drivers/clk/socfpga/clk-agilex.c
> @@ -0,0 +1,332 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019, Intel Corporation
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include "stratix10-clk.h"
> +
> +static const char * const pll_mux[] = { "osc1", "cb-intosc-hs-div2-clk",
> + "f2s-free-clk",};
> +static const char * const cntr_mux[] = { "main_pll", "periph_pll",
> +"osc1", "cb-intosc-hs-div2-clk",
> +"f2s-free-clk"};
> +static const char * const boot_mux[] = { "osc1", "cb-intosc-hs-div2-clk",};
> +
> +static const char * const mpu_free_mux[] = {"main_pll_c0", "peri_pll_c0",
> + "osc1", "cb-intosc-hs-div2-clk",
> + "f2s-free-clk"};
> +
> +static const char * const noc_free_mux[] = {"main_pll_c1", "peri_pll_c1",
> + "osc1", "cb-intosc-hs-div2-clk",
> + "f2s-free-clk"};
> +
> +static const char * const emaca_free_mux[] = {"main_pll_c2", "peri_pll_c2",
> + "osc1", "cb-intosc-hs-div2-clk",
> + "f2s-free-clk"};
> +static const char * const emacb_free_mux[] = {"main_pll_c3", "peri_pll_c3",
> + "osc1", "cb-intosc-hs-div2-clk",
> + "f2s-free-clk"};
> +static const char * const emac_ptp_free_mux[] = {"main_pll_c3",
> "peri_pll_c3",
> + "osc1", "cb-intosc-hs-div2-clk",
> + "f2s-free-clk"};
> +static const char * const gpio_db_free_mux[] = {"main_pll_c3", "peri_pll_c3",
> + "osc1", "cb-intosc-hs-div2-clk",
> + "f2s-free-clk"};
> +static const char * const psi_ref_free_mux[] = {"main_pll_c3", "peri_pll_c3",
> + "osc1", "cb-intosc-hs-div2-clk",
> + "f2s-free-clk"};
> +static const char * const sdmmc_free_mux[] = {"main_pll_c3", "peri_pll_c3",
> + "osc1", "cb-intosc-hs-div2-clk",
> + "f2s-free-clk"};
> +static const char * const s2f_usr0_free_mux[] = {"main_pll_c2",
> "peri_pll_c2",
> +"osc1",
> "cb-intosc-hs-div2-clk",
> +"f2s-free-clk"};
> +static const char * const s2f_usr1_free_mux[] = {"main_pll_c2",
> "peri_pll_c2",
> +"osc1",
> "cb-intosc-hs-div2-clk",
> +"f2s-free-clk"};
> +static const char * const mpu_mux[] = { "mpu_free_clk", "boot_clk",};
> +
> +static const char * const s2f_usr0_mux[] = {"f2s-free-clk", "boot_clk"};
> +static const char * const emac_mux[] = {"emaca_free_clk", "emacb_free_clk"};
> +static const char * const noc_mux[] = {"noc_free_clk", "boot_clk"};
> +
> +/* clocks in AO (always on) controller */
> +static const struct stratix10_pll_clock agilex_pll_clks[] = {
> + { AGILEX_BOOT_CLK, "boot_clk", boot_mux, ARRAY_SIZE(boot_mux), 0,
> +
Re: [PATCH 1/2] dt-bindings: documentation: add clock bindings information for Agilex
Quoting Dinh Nguyen (2019-09-17 18:34:58)
> From: Dinh Nguyen
>
> Document the Agilex clock bindings, and add the clock header file. The
> clock header is an enumeration of all the different clocks on the Agilex
> platform.
>
> Signed-off-by: Dinh Nguyen
This needs a signed-off-by from your intel address as that's the author.
> ---
> .../devicetree/bindings/clock/intc_agilex.txt | 20 ++
> include/dt-bindings/clock/agilex-clock.h | 70 +++
> 2 files changed, 90 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/intc_agilex.txt
> create mode 100644 include/dt-bindings/clock/agilex-clock.h
>
> diff --git a/Documentation/devicetree/bindings/clock/intc_agilex.txt
> b/Documentation/devicetree/bindings/clock/intc_agilex.txt
> new file mode 100644
> index ..bfec71420511
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/intc_agilex.txt
> @@ -0,0 +1,20 @@
> +Device Tree Clock bindings for Intel's SoCFPGA Agilex platform
> +
> +This binding uses the common clock binding[1].
Can you write this binding in YAML? That way we can verify the simple
usage of it easily.
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +Required properties:
> +- compatible : shall be
> + "intel,agilex-clkmgr"
> +
> +- reg : shall be the control register offset from CLOCK_MANAGER's base for
> the clock.
I don't quite understand what this means. What is the CLOCK_MANAGER
base for the clock? Doesn't this describe an offset to a clock
controller which provides more than one clk?
> +
> +- #clock-cells : from common clock binding, shall be set to 1.
> +
> +Example:
> + clkmgr: clock-controller@ffd1 {
> + compatible = "intel,agilex-clkmgr";
> + reg = <0xffd1 0x1000>;
> + #clock-cells = <1>;
> + };
Re: [PATCH v5 7/8] clk: Add common clock driver for BM1880 SoC
Quoting Manivannan Sadhasivam (2019-09-16 09:14:46)
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 801fa1cd0321..e70c64e43ff9 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -139,6 +139,13 @@ config COMMON_CLK_SI570
> This driver supports Silicon Labs 570/571/598/599 programmable
> clock generators.
>
> +config COMMON_CLK_BM1880
> + bool "Clock driver for Bitmain BM1880 SoC"
Can it be tristate?
> + depends on ARCH_BITMAIN || COMPILE_TEST
> + default ARCH_BITMAIN
> + help
> + This driver supports the clocks on Bitmain BM1880 SoC.
> +
> config COMMON_CLK_CDCE706
> tristate "Clock driver for TI CDCE706 clock synthesizer"
> depends on I2C
> diff --git a/drivers/clk/clk-bm1880.c b/drivers/clk/clk-bm1880.c
> new file mode 100644
> index ..3b10de929fd4
> --- /dev/null
> +++ b/drivers/clk/clk-bm1880.c
> @@ -0,0 +1,966 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Bitmain BM1880 SoC clock driver
> + *
> + * Copyright (c) 2019 Linaro Ltd.
> + * Author: Manivannan Sadhasivam
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#define BM1880_CLK_MPLL_CTL0x00
> +#define BM1880_CLK_SPLL_CTL0x04
> +#define BM1880_CLK_FPLL_CTL0x08
> +#define BM1880_CLK_DDRPLL_CTL 0x0c
> +
> +#define BM1880_CLK_ENABLE0 0x00
> +#define BM1880_CLK_ENABLE1 0x04
> +#define BM1880_CLK_SELECT 0x20
> +#define BM1880_CLK_DIV00x40
> +#define BM1880_CLK_DIV10x44
> +#define BM1880_CLK_DIV20x48
> +#define BM1880_CLK_DIV30x4c
> +#define BM1880_CLK_DIV40x50
> +#define BM1880_CLK_DIV50x54
> +#define BM1880_CLK_DIV60x58
> +#define BM1880_CLK_DIV70x5c
> +#define BM1880_CLK_DIV80x60
> +#define BM1880_CLK_DIV90x64
> +#define BM1880_CLK_DIV10 0x68
> +#define BM1880_CLK_DIV11 0x6c
> +#define BM1880_CLK_DIV12 0x70
> +#define BM1880_CLK_DIV13 0x74
> +#define BM1880_CLK_DIV14 0x78
> +#define BM1880_CLK_DIV15 0x7c
> +#define BM1880_CLK_DIV16 0x80
> +#define BM1880_CLK_DIV17 0x84
> +#define BM1880_CLK_DIV18 0x88
> +#define BM1880_CLK_DIV19 0x8c
> +#define BM1880_CLK_DIV20 0x90
> +#define BM1880_CLK_DIV21 0x94
> +#define BM1880_CLK_DIV22 0x98
> +#define BM1880_CLK_DIV23 0x9c
> +#define BM1880_CLK_DIV24 0xa0
> +#define BM1880_CLK_DIV25 0xa4
> +#define BM1880_CLK_DIV26 0xa8
> +#define BM1880_CLK_DIV27 0xac
> +#define BM1880_CLK_DIV28 0xb0
> +
> +#define to_bm1880_pll_clk(_hw) container_of(_hw, struct bm1880_pll_hw_clock,
> hw)
> +#define to_bm1880_div_clk(_hw) container_of(_hw, struct bm1880_div_hw_clock,
> hw)
> +
> +static DEFINE_SPINLOCK(bm1880_clk_lock);
> +
> +struct bm1880_clock_data {
> + void __iomem *pll_base;
> + void __iomem *sys_base;
> + struct clk_hw_onecell_data *clk_data;
Please call it hw_data or onecell_data instead so that the code doesn't
read as clk_data->clk_data. Also, probably can just make it part of the
same struct instead of a pointer inside so that it can all be allocated
in one big chunk instead of in two.
> +};
> +
> +struct bm1880_gate_clock {
> + unsigned intid;
> + const char *name;
> + const char *parent;
> + u32 gate_reg;
> + s8 gate_shift;
> + unsigned long flags;
> +};
> +
> +struct bm1880_mux_clock {
> + unsigned intid;
> + const char *name;
> + const char * const *parents;
> + s8 num_parents;
> + u32 reg;
> + s8 shift;
> + unsigned long flags;
> +};
> +
> +struct bm1880_div_clock {
> + unsigned intid;
> + const char *name;
> + u32 reg;
> + u8 shift;
> + u8 width;
> + u32 initval;
> + const struct clk_div_table *table;
> + unsigned long flags;
> +};
> +
> +struct bm1880_div_hw_clock {
> + struct bm1880_div_clock div;
> + void __iomem *base;
> + spinlock_t *lock;
> + struct clk_hw hw;
> + struct clk_init_data init;
> +};
> +
> +struct bm1880_composite_clock {
> + unsigned intid;
> + const char *name;
> + const char *parent;
> + const char * const *parents;
> + unsigned intnum_parents;
> + unsigned long flags;
> +
> + u32 gate_reg;
> + u32 mux_reg;
> + u32 div_reg;
> +
> + s8 gate_shift;
> + s8 mux_shift;
> + s8 div_shift;
> + s8 div_width;
> + s16 div_initval;
> + const struct clk_div_table
[PATCH] drivers/net: release skb on failure
In ql_run_loopback_test, ql_lb_send does not release skb when fails. So
it must be released before returning.
Signed-off-by: Navid Emamdoost
---
drivers/net/ethernet/qlogic/qlge/qlge_ethtool.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qlge/qlge_ethtool.c
b/drivers/net/ethernet/qlogic/qlge/qlge_ethtool.c
index a6886cc5654c..d539b71b2a5c 100644
--- a/drivers/net/ethernet/qlogic/qlge/qlge_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qlge/qlge_ethtool.c
@@ -544,8 +544,10 @@ static int ql_run_loopback_test(struct ql_adapter *qdev)
skb_put(skb, size);
ql_create_lb_frame(skb, size);
rc = ql_lb_send(skb, qdev->ndev);
- if (rc != NETDEV_TX_OK)
+ if (rc != NETDEV_TX_OK) {
+ dev_kfree_skb_any(skb);
return -EPIPE;
+ }
atomic_inc(>lb_count);
}
/* Give queue time to settle before testing results. */
--
2.17.1
[PATCH] libnvdimm/nfit_test: Fix acpi_handle redefinition
After commit 62974fc389b3 ("libnvdimm: Enable unit test infrastructure
compile checks"), clang warns:
In file included from
../drivers/nvdimm/../../tools/testing/nvdimm/test/iomap.c:15:
../drivers/nvdimm/../../tools/testing/nvdimm/test/nfit_test.h:206:15:
warning: redefinition of typedef 'acpi_handle' is a C11 feature
[-Wtypedef-redefinition]
typedef void *acpi_handle;
^
../include/acpi/actypes.h:424:15: note: previous definition is here
typedef void *acpi_handle; /* Actually a ptr to a NS Node */
^
1 warning generated.
The include chain:
iomap.c ->
linux/acpi.h ->
acpi/acpi.h ->
acpi/actypes.h
nfit_test.h
Avoid this by including linux/acpi.h in nfit_test.h, which allows us to
remove both the typedef and the forward declaration of acpi_object.
Link: https://github.com/ClangBuiltLinux/linux/issues/660
Signed-off-by: Nathan Chancellor
---
I know that every maintainer has their own thing with the number of
includes in each header file; this issue can be solved in a various
number of ways, I went with the smallest diff stat. Please solve it in a
different way if you see fit :)
tools/testing/nvdimm/test/nfit_test.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/tools/testing/nvdimm/test/nfit_test.h
b/tools/testing/nvdimm/test/nfit_test.h
index 448d686da8b1..0bf5640f1f07 100644
--- a/tools/testing/nvdimm/test/nfit_test.h
+++ b/tools/testing/nvdimm/test/nfit_test.h
@@ -4,6 +4,7 @@
*/
#ifndef __NFIT_TEST_H__
#define __NFIT_TEST_H__
+#include
#include
#include
#include
@@ -202,9 +203,6 @@ struct nd_intel_lss {
__u32 status;
} __packed;
-union acpi_object;
-typedef void *acpi_handle;
-
typedef struct nfit_test_resource *(*nfit_test_lookup_fn)(resource_size_t);
typedef union acpi_object *(*nfit_test_evaluate_dsm_fn)(acpi_handle handle,
const guid_t *guid, u64 rev, u64 func,
--
2.23.0
[PATCH] mm: Support memblock alloc on the exact node for sparse_buffer_init()
Currently, when memblock_find_in_range_node() fail on the exact node, it
will use %NUMA_NO_NODE to find memblock from other nodes. At present,
the work is good, but when the large memory is insufficient and the
small memory is enough, we want to allocate the small memory of this
node first, and do not need to allocate large memory from other nodes.
In sparse_buffer_init(), it will prepare large chunks of memory for page
structure. The page management structure requires a lot of memory, but
if the node does not have enough memory, it can be converted to a small
memory allocation without having to allocate it from other nodes.
Add %MEMBLOCK_ALLOC_EXACT_NODE flag for this situation. Normally, the
behavior is the same with %MEMBLOCK_ALLOC_ACCESSIBLE, only that it will
not allocate from other nodes when a single node fails to allocate.
If large contiguous block memory allocated fail in sparse_buffer_init(),
it will allocates small block memmory section by section later.
Signed-off-by: Yunfeng Ye
---
include/linux/memblock.h | 1 +
mm/memblock.c| 3 ++-
mm/sparse.c | 2 +-
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index f491690..9a81d9c 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -339,6 +339,7 @@ static inline int memblock_get_region_node(const struct
memblock_region *r)
#define MEMBLOCK_ALLOC_ANYWHERE(~(phys_addr_t)0)
#define MEMBLOCK_ALLOC_ACCESSIBLE 0
#define MEMBLOCK_ALLOC_KASAN 1
+#define MEMBLOCK_ALLOC_EXACT_NODE 2
/* We are using top down, so it is safe to use 0 here */
#define MEMBLOCK_LOW_LIMIT 0
diff --git a/mm/memblock.c b/mm/memblock.c
index 7d4f61a..dbd52c3c 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -277,6 +277,7 @@ static phys_addr_t __init_memblock
memblock_find_in_range_node(phys_addr_t size,
/* pump up @end */
if (end == MEMBLOCK_ALLOC_ACCESSIBLE ||
+ end == MEMBLOCK_ALLOC_EXACT_NODE ||
end == MEMBLOCK_ALLOC_KASAN)
end = memblock.current_limit;
@@ -1365,7 +1366,7 @@ static phys_addr_t __init
memblock_alloc_range_nid(phys_addr_t size,
if (found && !memblock_reserve(found, size))
goto done;
- if (nid != NUMA_NO_NODE) {
+ if (end != MEMBLOCK_ALLOC_EXACT_NODE && nid != NUMA_NO_NODE) {
found = memblock_find_in_range_node(size, align, start,
end, NUMA_NO_NODE,
flags);
diff --git a/mm/sparse.c b/mm/sparse.c
index 72f010d..828db46 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -477,7 +477,7 @@ static void __init sparse_buffer_init(unsigned long size,
int nid)
sparsemap_buf =
memblock_alloc_try_nid_raw(size, PAGE_SIZE,
addr,
- MEMBLOCK_ALLOC_ACCESSIBLE, nid);
+ MEMBLOCK_ALLOC_EXACT_NODE, nid);
sparsemap_buf_end = sparsemap_buf + size;
}
--
2.7.4.huawei.3
Re: [PATCH v3 bpf-next 10/14] samples: bpf: makefile: use target CC environment for HDR_PROBE
On Mon, Sep 16, 2019 at 3:59 AM Ivan Khoronzhuk wrote: > > No need in hacking HOSTCC to be cross-compiler any more, so drop > this trick and use target CC for HDR_PROBE. > > Signed-off-by: Ivan Khoronzhuk > --- Acked-by: Andrii Nakryiko [...]
[PATCH v2 1/2] powerpc/irq: bring back ksp_limit management in C functions.
Commit cbc9565ee826 ("powerpc: Remove ksp_limit on ppc64") moved
PPC32 ksp_limit handling in assembly functions call_do_softirq()
and call_do_irq() as they are different for PPC32 and PPC64.
In preparation of replacing these functions by inline assembly,
partialy revert that commit to bring back ksp_limit assignment
in the callers.
To get and set ksp_limit without a forest of #ifdefs CONFIG_PPC32,
use helpers that will void on PPC64.
Signed-off-by: Christophe Leroy
---
v2: added forward declaration of struct task_struct to avoid build failure.
---
arch/powerpc/include/asm/irq.h | 23 +++
arch/powerpc/kernel/irq.c | 14 +-
arch/powerpc/kernel/misc_32.S | 14 --
3 files changed, 36 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
index 814dfab7e392..70922661450e 100644
--- a/arch/powerpc/include/asm/irq.h
+++ b/arch/powerpc/include/asm/irq.h
@@ -64,5 +64,28 @@ extern void __do_irq(struct pt_regs *regs);
int irq_choose_cpu(const struct cpumask *mask);
+struct task_struct;
+
+#ifdef CONFIG_PPC32
+static inline unsigned long get_ksp_limit(struct task_struct *tsk)
+{
+ return tsk->thread.ksp_limit;
+}
+
+static inline void set_ksp_limit(struct task_struct *tsk, unsigned long limit)
+{
+ tsk->thread.ksp_limit = limit;
+}
+#else
+static inline unsigned long get_ksp_limit(struct task_struct *tsk)
+{
+ return 0;
+}
+
+static inline void set_ksp_limit(struct task_struct *tsk, unsigned long limit)
+{
+}
+#endif
+
#endif /* _ASM_IRQ_H */
#endif /* __KERNEL__ */
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 5645bc9cbc09..04204be49577 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -646,6 +646,7 @@ void do_IRQ(struct pt_regs *regs)
{
struct pt_regs *old_regs = set_irq_regs(regs);
void *cursp, *irqsp, *sirqsp;
+ unsigned long saved_ksp_limit = get_ksp_limit(current);
/* Switch to the irq stack to handle this */
cursp = (void *)(current_stack_pointer() & ~(THREAD_SIZE - 1));
@@ -658,9 +659,15 @@ void do_IRQ(struct pt_regs *regs)
set_irq_regs(old_regs);
return;
}
+ /* Adjust the stack limit */
+ set_ksp_limit(current, (unsigned long)irqsp);
+
/* Switch stack and call */
call_do_irq(regs, irqsp);
+ /* Restore stack limit */
+ set_ksp_limit(current, saved_ksp_limit);
+
set_irq_regs(old_regs);
}
@@ -681,7 +688,12 @@ void *hardirq_ctx[NR_CPUS] __read_mostly;
void do_softirq_own_stack(void)
{
- call_do_softirq(softirq_ctx[smp_processor_id()]);
+ void *irqsp = softirq_ctx[smp_processor_id()];
+ unsigned long saved_ksp_limit = get_ksp_limit(current);
+
+ set_ksp_limit(current, (unsigned long)irqsp);
+ call_do_softirq(irqsp);
+ set_ksp_limit(current, saved_ksp_limit);
}
irq_hw_number_t virq_to_hw(unsigned int virq)
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index 82df4b09e79f..a5422f7782b3 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -33,23 +33,14 @@
.text
-/*
- * We store the saved ksp_limit in the unused part
- * of the STACK_FRAME_OVERHEAD
- */
_GLOBAL(call_do_softirq)
mflrr0
stw r0,4(r1)
- lwz r10,THREAD+KSP_LIMIT(r2)
- stw r3, THREAD+KSP_LIMIT(r2)
stwur1,THREAD_SIZE-STACK_FRAME_OVERHEAD(r3)
mr r1,r3
- stw r10,8(r1)
bl __do_softirq
- lwz r10,8(r1)
lwz r1,0(r1)
lwz r0,4(r1)
- stw r10,THREAD+KSP_LIMIT(r2)
mtlrr0
blr
@@ -59,16 +50,11 @@ _GLOBAL(call_do_softirq)
_GLOBAL(call_do_irq)
mflrr0
stw r0,4(r1)
- lwz r10,THREAD+KSP_LIMIT(r2)
- stw r4, THREAD+KSP_LIMIT(r2)
stwur1,THREAD_SIZE-STACK_FRAME_OVERHEAD(r4)
mr r1,r4
- stw r10,8(r1)
bl __do_irq
- lwz r10,8(r1)
lwz r1,0(r1)
lwz r0,4(r1)
- stw r10,THREAD+KSP_LIMIT(r2)
mtlrr0
blr
--
2.13.3
[PATCH v2 2/2] powerpc/irq: inline call_do_irq() and call_do_softirq()
call_do_irq() and call_do_softirq() are quite similar on PPC32 and
PPC64 and are simple enough to be worth inlining.
Inlining them avoids an mflr/mtlr pair plus a save/reload on stack.
This is inspired from S390 arch. Several other arches do more or
less the same. The way sparc arch does seems odd thought.
Signed-off-by: Christophe Leroy
---
v2: no change.
---
arch/powerpc/include/asm/irq.h | 2 --
arch/powerpc/kernel/irq.c | 26 ++
arch/powerpc/kernel/misc_32.S | 25 -
arch/powerpc/kernel/misc_64.S | 22 --
4 files changed, 26 insertions(+), 49 deletions(-)
diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
index 70922661450e..86e8dbaecb7d 100644
--- a/arch/powerpc/include/asm/irq.h
+++ b/arch/powerpc/include/asm/irq.h
@@ -56,8 +56,6 @@ extern void *mcheckirq_ctx[NR_CPUS];
extern void *hardirq_ctx[NR_CPUS];
extern void *softirq_ctx[NR_CPUS];
-void call_do_softirq(void *sp);
-void call_do_irq(struct pt_regs *regs, void *sp);
extern void do_IRQ(struct pt_regs *regs);
extern void __init init_IRQ(void);
extern void __do_irq(struct pt_regs *regs);
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 04204be49577..b028c49f9635 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -642,6 +642,20 @@ void __do_irq(struct pt_regs *regs)
irq_exit();
}
+static inline void call_do_irq(struct pt_regs *regs, void *sp)
+{
+ register unsigned long r3 asm("r3") = (unsigned long)regs;
+
+ asm volatile(
+ " "PPC_STLU" 1, %2(%1);\n"
+ " mr 1, %1;\n"
+ " bl %3;\n"
+ " "PPC_LL"1, 0(1);\n" : "+r"(r3) :
+ "b"(sp), "i"(THREAD_SIZE - STACK_FRAME_OVERHEAD), "i"(__do_irq)
:
+ "lr", "xer", "ctr", "memory", "cr0", "cr1", "cr5", "cr6", "cr7",
+ "r0", "r4", "r5", "r6", "r7", "r8", "r9", "r10", "r11", "r12");
+}
+
void do_IRQ(struct pt_regs *regs)
{
struct pt_regs *old_regs = set_irq_regs(regs);
@@ -686,6 +700,18 @@ void *mcheckirq_ctx[NR_CPUS] __read_mostly;
void *softirq_ctx[NR_CPUS] __read_mostly;
void *hardirq_ctx[NR_CPUS] __read_mostly;
+static inline void call_do_softirq(const void *sp)
+{
+ asm volatile(
+ " "PPC_STLU" 1, %1(%0);\n"
+ " mr 1, %0;\n"
+ " bl %2;\n"
+ " "PPC_LL"1, 0(1);\n" : :
+ "b"(sp), "i"(THREAD_SIZE - STACK_FRAME_OVERHEAD),
"i"(__do_softirq) :
+ "lr", "xer", "ctr", "memory", "cr0", "cr1", "cr5", "cr6", "cr7",
+ "r0", "r4", "r5", "r6", "r7", "r8", "r9", "r10", "r11", "r12");
+}
+
void do_softirq_own_stack(void)
{
void *irqsp = softirq_ctx[smp_processor_id()];
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index a5422f7782b3..307307b57743 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -33,31 +33,6 @@
.text
-_GLOBAL(call_do_softirq)
- mflrr0
- stw r0,4(r1)
- stwur1,THREAD_SIZE-STACK_FRAME_OVERHEAD(r3)
- mr r1,r3
- bl __do_softirq
- lwz r1,0(r1)
- lwz r0,4(r1)
- mtlrr0
- blr
-
-/*
- * void call_do_irq(struct pt_regs *regs, void *sp);
- */
-_GLOBAL(call_do_irq)
- mflrr0
- stw r0,4(r1)
- stwur1,THREAD_SIZE-STACK_FRAME_OVERHEAD(r4)
- mr r1,r4
- bl __do_irq
- lwz r1,0(r1)
- lwz r0,4(r1)
- mtlrr0
- blr
-
/*
* This returns the high 64 bits of the product of two 64-bit numbers.
*/
diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
index b55a7b4cb543..69fd714a5236 100644
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -27,28 +27,6 @@
.text
-_GLOBAL(call_do_softirq)
- mflrr0
- std r0,16(r1)
- stdur1,THREAD_SIZE-STACK_FRAME_OVERHEAD(r3)
- mr r1,r3
- bl __do_softirq
- ld r1,0(r1)
- ld r0,16(r1)
- mtlrr0
- blr
-
-_GLOBAL(call_do_irq)
- mflrr0
- std r0,16(r1)
- stdur1,THREAD_SIZE-STACK_FRAME_OVERHEAD(r4)
- mr r1,r4
- bl __do_irq
- ld r1,0(r1)
- ld r0,16(r1)
- mtlrr0
- blr
-
.section".toc","aw"
PPC64_CACHES:
.tc ppc64_caches[TC],ppc64_caches
--
2.13.3
Re: [PATCH 3/6] Timer: expose monotonic clock and counter value
On Tue, Sep 17, 2019 at 07:24:27AM -0400, Jianyong Wu wrote: > A number of PTP drivers (such as ptp-kvm) are assuming what the > current clock source is, which could lead to interesting effects on > systems where the clocksource can change depending on external events. > > For this purpose, add a new API that retrives both the current > monotonic clock as well as its counter value. > > Signed-off-by: Marc Zyngier > Signed-off-by: Jianyong Wu > --- > include/linux/timekeeping.h | 3 +++ > kernel/time/timekeeping.c | 13 + > 2 files changed, 16 insertions(+) For core time keeping changes, you must CC lkml, tglx, and John Stultz. Thanks, Richard
Re: [PATCH] [RFC] vmscan.c: add a sysctl entry for controlling memory reclaim IO congestion_wait length
On 9/17/19 20:06, Matthew Wilcox wrote: On Tue, Sep 17, 2019 at 07:58:24PM +0800, Lin Feng wrote: In direct and background(kswapd) pages reclaim paths both may fall into calling msleep(100) or congestion_wait(HZ/10) or wait_iff_congested(HZ/10) while under IO pressure, and the sleep length is hard-coded and the later two will introduce 100ms iowait length per time. So if pages reclaim is relatively active in some circumstances such as high order pages reappings, it's possible to see a lot of iowait introduced by congestion_wait(HZ/10) and wait_iff_congested(HZ/10). The 100ms sleep length is proper if the backing drivers are slow like traditionnal rotation disks. While if the backing drivers are high-end storages such as high iops ssds or even faster drivers, the high iowait inroduced by pages reclaim is really misleading, because the storage IO utils seen by iostat is quite low, in this case the congestion_wait time modified to 1ms is likely enough for high-end ssds. Another benifit is that it's potentially shorter the direct reclaim blocked time when kernel falls into sync reclaim path, which may improve user applications response time. This is a great description of the problem. The always 100ms blocked time sometimes is not necessary :) +mm_reclaim_congestion_wait_jiffies +== + +This control is used to define how long kernel will wait/sleep while +system memory is under pressure and memroy reclaim is relatively active. +Lower values will decrease the kernel wait/sleep time. + +It's suggested to lower this value on high-end box that system is under memory +pressure but with low storage IO utils and high CPU iowait, which could also +potentially decrease user application response time in this case. + +Keep this control as it were if your box are not above case. + +The default value is HZ/10, which is of equal value to 100ms independ of how +many HZ is defined. Adding a new tunable is not the right solution. The right way is to make Linux auto-tune itself to avoid the problem. For example, bdi_writeback contains an estimated write bandwidth (calculated by the memory management layer). Given that, we should be able to make an estimate for how long to wait for the queues to drain. Yes, I had ever considered that, auto-tuning is definitely the senior AI way. While considering all kinds of production environments hybird storage solution is also common today, servers' dirty pages' bdi drivers can span from high end ssds to low end sata disk, so we have to think of a *formula(AI core)* by using the factors of dirty pages' amount and bdis' write bandwidth, and this AI-core will depend on if the estimated write bandwidth is sane and moreover the to be written back dirty pages is sequential or random if the bdi is rotational disk, it's likey to give a not-sane number and hurt guys who dont't want that, while if only consider ssd is relatively simple. So IMHO it's not sane to brute force add a guessing logic into memory writeback codes and pray on inventing a formula that caters everyone's need. Add a sysctl entry may be a right choice that give people who need it and doesn't hurt people who don't want it. thanks, linfeng
RE: [PATCH v3 09/11] PCI: layerscape: Add EP mode support for ls1088a and ls2088a
> -Original Message-
> From: Andrew Murray
> Sent: 2019年9月16日 22:38
> To: Xiaowei Bao ; robh...@kernel.org
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.com;
> gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org;
> a...@arndb.de; gre...@linuxfoundation.org; Z.q. Hou
>
> Subject: Re: [PATCH v3 09/11] PCI: layerscape: Add EP mode support for
> ls1088a and ls2088a
>
> On Sat, Sep 14, 2019 at 04:10:22AM +, Xiaowei Bao wrote:
> >
> >
> > > -Original Message-
> > > From: Andrew Murray
> > > Sent: 2019年9月12日 20:50
> > > To: Xiaowei Bao
> > > Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org;
> > > Leo Li ; kis...@ti.com; lorenzo.pieral...@arm.com;
> M.h.
> > > Lian ; Mingkai Hu ; Roy
> > > Zang ; jingooh...@gmail.com;
> > > gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org;
> > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org;
> > > a...@arndb.de; gre...@linuxfoundation.org; Z.q. Hou
> > >
> > > Subject: Re: [PATCH v3 09/11] PCI: layerscape: Add EP mode support
> > > for ls1088a and ls2088a
> > >
> > > On Tue, Sep 03, 2019 at 01:47:36AM +, Xiaowei Bao wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Andrew Murray
> > > > > Sent: 2019年9月2日 20:46
> > > > > To: Xiaowei Bao
> > > > > Cc: robh...@kernel.org; mark.rutl...@arm.com;
> > > > > shawn...@kernel.org; Leo Li ; kis...@ti.com;
> > > > > lorenzo.pieral...@arm.com;
> > > M.h.
> > > > > Lian ; Mingkai Hu ;
> > > > > Roy Zang ; jingooh...@gmail.com;
> > > > > gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org;
> > > > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > > > linux-arm-ker...@lists.infradead.org;
> > > > > linuxppc-...@lists.ozlabs.org; a...@arndb.de;
> > > > > gre...@linuxfoundation.org; Z.q. Hou
> > > > > Subject: Re: [PATCH v3 09/11] PCI: layerscape: Add EP mode
> > > > > support for ls1088a and ls2088a
> > > > >
> > > > > On Mon, Sep 02, 2019 at 11:17:14AM +0800, Xiaowei Bao wrote:
> > > > > > Add PCIe EP mode support for ls1088a and ls2088a, there are
> > > > > > some difference between LS1 and LS2 platform, so refactor the
> > > > > > code of the EP driver.
> > > > > >
> > > > > > Signed-off-by: Xiaowei Bao
> > > > > > ---
> > > > > > v2:
> > > > > > - This is a new patch for supporting the ls1088a and ls2088a
> platform.
> > > > > > v3:
> > > > > > - Adjust the some struct assignment order in probe function.
> > > > > >
> > > > > > drivers/pci/controller/dwc/pci-layerscape-ep.c | 72
> > > > > > +++---
> > > > > > 1 file changed, 53 insertions(+), 19 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > > > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > > > index 5f0cb99..723bbe5 100644
> > > > > > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > > > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > > > > @@ -20,27 +20,29 @@
> > > > > >
> > > > > > #define PCIE_DBI2_OFFSET 0x1000 /* DBI2 base address*/
> > > > > >
> > > > > > -struct ls_pcie_ep {
> > > > > > - struct dw_pcie *pci;
> > > > > > - struct pci_epc_features *ls_epc;
> > > > > > +#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > > > > > +
> > > > > > +struct ls_pcie_ep_drvdata {
> > > > > > + u32 func_offset;
> > > > > > + const struct dw_pcie_ep_ops *ops;
> > > > > > + const struct dw_pcie_ops*dw_pcie_ops;
> > > > > > };
> > > > > >
> > > > > > -#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > > > > > +struct ls_pcie_ep {
> > > > > > + struct dw_pcie *pci;
> > > > > > + struct pci_epc_features *ls_epc;
> > > > > > + const struct ls_pcie_ep_drvdata *drvdata; };
> > > > > >
> > > > > > static int ls_pcie_establish_link(struct dw_pcie *pci) {
> > > > > > return 0;
> > > > > > }
> > > > > >
> > > > > > -static const struct dw_pcie_ops ls_pcie_ep_ops = {
> > > > > > +static const struct dw_pcie_ops dw_ls_pcie_ep_ops = {
> > > > > > .start_link = ls_pcie_establish_link, };
> > > > > >
> > > > > > -static const struct of_device_id ls_pcie_ep_of_match[] = {
> > > > > > - { .compatible = "fsl,ls-pcie-ep",},
> > > > > > - { },
> > > > > > -};
> > > > > > -
> > > > > > static const struct pci_epc_features*
> > > > > > ls_pcie_ep_get_features(struct dw_pcie_ep *ep) { @@ -87,10
> > > > > > +89,39 @@ static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep,
> u8 func_no,
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > -static const struct dw_pcie_ep_ops pcie_ep_ops = {
> > > > > > +static unsigned int
[PATCH] arm:unwind: fix incorrect backtrace with unwind_table
For arm, if the CONFIG_ARM_UNWIND is open, when insmod a module,
the init section add to the unwind_table, the code path as follow:
load_module
--->post_relocation
--->module_finalize
--->maps[ARM_SEC_INIT].txt_sec = s
--->unwind_table_add
Later if load_module success, the init section's memory will be
vfree, the code path as follow:
load_module
--->do_init_module
--->freeinit->module_init = mod->init_layout.base
--->schedule_work(_free_wq)
--->do_free_init
--->vfree(freeinit->module_init)
But after the init section's had been vfree, but it's unwind_table
is not removed.
The issue as follow:
When insmod module A, the system alloc the "Addr1" for it's init
text section, and add it to the unwind_table list, after insmod
success, the "Addr1" would be vfreed.
Unfortunately, later insmod module B, the system alloc the "Addr1"
for it's text section, and add it to the unwind_table list, too.
And we dumpstack in module B, we may get a incorrect backtrace.
Signed-off-by: chenzefeng
---
arch/arm/kernel/module.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index deef17f..438ed67 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -410,7 +410,20 @@ int module_finalize(const Elf32_Ehdr *hdr, const Elf_Shdr
*sechdrs,
int i;
for (i = 0; i < ARM_SEC_MAX; i++)
- if (mod->arch.unwind[i])
+ if (mod->arch.unwind[i]) {
unwind_table_del(mod->arch.unwind[i]);
+ mod->arch.unwind[i] = NULL;
+ }
+#endif
+}
+
+void
+module_arch_freeing_init(struct module *mod)
+{
+#ifdef CONFIG_ARM_UNWIND
+ if (mod->arch.unwind[ARM_SEC_INIT]) {
+ unwind_table_del(mod->arch.unwind[ARM_SEC_INIT]);
+ mod->arch.unwind[ARM_SEC_INIT] = NULL;
+ }
#endif
}
--
1.8.5.6
[PATCH 2/2] dt-bindings: iio: light: add veml6030 ALS bindings
This commit adds device tree bindings for veml6030 ambient
light sensor.
Signed-off-by: Rishi Gupta
---
.../devicetree/bindings/iio/light/veml6030.yaml| 62 ++
1 file changed, 62 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/veml6030.yaml
diff --git a/Documentation/devicetree/bindings/iio/light/veml6030.yaml
b/Documentation/devicetree/bindings/iio/light/veml6030.yaml
new file mode 100644
index 000..d92684a
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/veml6030.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: GPL-2.0+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/light/veml6030.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: VEML6030 Ambient Light Sensor (ALS)
+
+maintainers:
+ - Rishi Gupta
+
+description: |
+ Bindings for the ambient light sensor veml6030 from Vishay
+ Semiconductors over an i2c interface.
+
+ Irrespective of whether interrupt is used or not, application
+ can get the ALS and White channel reading from IIO raw interface.
+
+ If the interrupts is used, application will receive an IIO event
+ whenever configured threshold is crossed.
+
+ Specifications about the sensor can be found at:
+https://www.vishay.com/docs/84366/veml6030.pdf
+
+properties:
+ compatible:
+enum:
+ - vishay,veml6030
+
+ reg:
+description:
+ I2C address of the device. If the ADDR pin on veml6030
+ is pulled up, this address is 0x48. If the ADDR pin is
+ pulled down, this address is 0x10.
+maxItems: 1
+
+ interrupts:
+description:
+ interrupt mapping for IRQ. Configure with IRQ_TYPE_LEVEL_LOW.
+ Refer to interrupt-controller/interrupts.txt for generic
+ interrupt client node bindings.
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+#include
+
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+light-sensor@10 {
+compatible = "vishay,veml6030";
+reg = <0x10>;
+interrupts = <12 IRQ_TYPE_LEVEL_LOW>;
+};
+};
+...
--
2.7.4
Add driver for veml6030 ambient light sensor
The veml6030 is an ambient light sensor from vishay and is a different hardware from an existing hardware for which driver currently exist, therefore this driver submission. * All features; ALS, white channel & power management is supported. * All configurable parameters are supported through standard iio sysfs entries. User space can get valid values of any parameter (xx_available) and then can write to appropriate sysfs entry. * User space can get ALS & White channel readings through RAW IIO interface. * IIO events are used to notify application whenever threshold is crossed. This uses IRQ pin of veml6030. * Some registers in veml6030 are read only. For these registers read callback returns error to user space. There are 2 patches for this submission: [PATCH 1/2] iio: light: add driver for veml6030 ambient light sensor [PATCH 2/2] dt-bindings: iio: light: add veml6030 ALS bindings Regards, Rishi
[PATCH 1/2] iio: light: add driver for veml6030 ambient light sensor
veml6030 is an ambient light sensor from Vishay semiconductors.
It has 16-bit resolution, supports both ambient light measurement
and white channel which is more responsive to wider wavelength
spectrum. It has flexible power saving, integration time and
gain options. Communication with host is over I2C.
Signed-off-by: Rishi Gupta
---
drivers/iio/light/Kconfig| 11 +
drivers/iio/light/Makefile | 1 +
drivers/iio/light/veml6030.c | 647 +++
3 files changed, 659 insertions(+)
create mode 100644 drivers/iio/light/veml6030.c
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index e3fd00b..9afe997 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -484,6 +484,17 @@ config VCNL4035
To compile this driver as a module, choose M here: the
module will be called vcnl4035.
+config VEML6030
+ tristate "VEML6030 ambient light sensor"
+ select REGMAP_I2C
+ depends on I2C
+ help
+ Say Y here if you want to build a driver for the Vishay VEML6030
+ ambient light sensor (ALS).
+
+ To compile this driver as a module, choose M here: the
+ module will be called veml6030.
+
config VEML6070
tristate "VEML6070 UV A light sensor"
depends on I2C
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index e40794f..011968b 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_TSL4531) += tsl4531.o
obj-$(CONFIG_US5182D) += us5182d.o
obj-$(CONFIG_VCNL4000) += vcnl4000.o
obj-$(CONFIG_VCNL4035) += vcnl4035.o
+obj-$(CONFIG_VEML6030) += veml6030.o
obj-$(CONFIG_VEML6070) += veml6070.o
obj-$(CONFIG_VL6180) += vl6180.o
obj-$(CONFIG_ZOPT2201) += zopt2201.o
diff --git a/drivers/iio/light/veml6030.c b/drivers/iio/light/veml6030.c
new file mode 100644
index 000..b12cdce
--- /dev/null
+++ b/drivers/iio/light/veml6030.c
@@ -0,0 +1,647 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * VEML6030 Ambient Light Sensor
+ *
+ * Copyright (c) 2019, Rishi Gupta
+ *
+ * Datasheet: https://www.vishay.com/docs/84366/veml6030.pdf
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Device registers */
+#define VEML6030_REG_ALS_CONF0x00
+#define VEML6030_REG_ALS_WH 0x01
+#define VEML6030_REG_ALS_WL 0x02
+#define VEML6030_REG_ALS_PSM 0x03
+#define VEML6030_REG_ALS_DATA0x04
+#define VEML6030_REG_WHITE_DATA 0x05
+#define VEML6030_REG_ALS_INT 0x06
+
+/* Bit masks for specific functionality */
+#define VEML6030_ALS_IT GENMASK(9, 6)
+#define VEML6030_PSM GENMASK(2, 1)
+#define VEML6030_ALS_PERS GENMASK(5, 4)
+#define VEML6030_ALS_GAIN GENMASK(12, 11)
+#define VEML6030_PSM_EN BIT(0)
+#define VEML6030_INT_TH_LOW BIT(15)
+#define VEML6030_INT_TH_HIGH BIT(14)
+#define VEML6030_ALS_INT_EN BIT(1)
+#define VEML6030_ALS_SD BIT(0)
+
+struct veml6030_data {
+ struct i2c_client *client;
+ struct regmap *regmap;
+};
+
+static IIO_CONST_ATTR_INT_TIME_AVAIL("0.025 0.05 0.1 0.2 0.4 0.8");
+
+static struct attribute *veml6030_attributes[] = {
+ _const_attr_integration_time_available.dev_attr.attr,
+ NULL
+};
+
+static const struct attribute_group veml6030_attr_group = {
+ .attrs = veml6030_attributes,
+};
+
+/*
+ * Scale is 1/gain. Value 0.125 is ALS gain x (1/8), 0.25 is
+ * ALS gain x (1/4), 1.0 = ALS gain x 1 and 2.0 is ALS gain x 2.
+ */
+static ssize_t veml6030_scale_available(struct iio_dev *indio_dev,
+ uintptr_t private, const struct iio_chan_spec *chan, char *buf)
+{
+ return sprintf(buf, "%s\n", "0.125 0.25 1.0 2.0");
+}
+
+/*
+ * Persistence = 1/2/4/8 x integration time
+ * Minimum time for which light readings must stay above configured
+ * threshold to assert interrupt.
+ */
+static ssize_t veml6030_persistence_available(struct iio_dev *indio_dev,
+ uintptr_t private, const struct iio_chan_spec *chan, char *buf)
+{
+ return sprintf(buf, "%s\n", "1 2 4 8");
+}
+
+/*
+ * Power saving modes supported.
+ * 1/2/3/4 corresponds to PSM modes 1/2/3/4 respectively.
+ */
+static ssize_t veml6030_psm_available(struct iio_dev *indio_dev,
+ uintptr_t private, const struct iio_chan_spec *chan, char *buf)
+{
+ return sprintf(buf, "%s\n", "1 2 3 4");
+}
+
+ssize_t veml6030_set_psm(struct iio_dev *indio_dev, uintptr_t priv,
+ const struct iio_chan_spec *chan, const char *buf,
+ size_t len)
+{
+ int ret;
+ unsigned int val;
+ struct veml6030_data *data = iio_priv(indio_dev);
+
+ ret = kstrtouint(buf, 0, );
+ if (ret < 0)
+ return ret;
+
+ if (val < 1 || val > 4)
+ return -EINVAL;
+
+ ret = regmap_update_bits(data->regmap, VEML6030_REG_ALS_PSM,
+
Add driver for veml6030 ambient light sensor
The veml6030 is an ambient light sensor from vishay and is a different hardware from an existing hardware for which driver currently exist, therefore this driver submission. * All features; ALS, white channel and power management is supported. * All configurable parameters are supported through standard iio sysfs entries. User space can get valid values of any parameter (xx_available) and then can write to appropriate sysfs entry. * User space can get ALS and White channel readings through RAW IIO interface. * IIO events are used to notify application whenever threshold is crossed. This uses IRQ pin of veml6030. * Some registers in veml6030 are read only. For these registers read callback returns error to user space. There are 2 patches for this submission: [PATCH 1/2] iio: light: add driver for veml6030 ambient light sensor [PATCH 2/2] dt-bindings: iio: light: add veml6030 ALS bindings Regards, Rishi
Re: [PATCH 2/3] ASoC: fsl_asrc: update supported sample format
Hi > > On Fri, Sep 13, 2019 at 05:48:40AM +, S.j. Wang wrote: > > Hi > > > > > > > > On Tue, Sep 10, 2019 at 02:07:25AM +, S.j. Wang wrote: > > > > > On Mon, Sep 09, 2019 at 06:33:20PM -0400, Shengjiu Wang wrote: > > > > > > The ASRC support 24bit/16bit/8bit input width, so S20_3LE > > > > > > format should not be supported, it is word width is 20bit. > > > > > > > > > > I thought 3LE used 24-bit physical width. And the driver assigns > > > > > ASRC_WIDTH_24_BIT to "width" for all non-16bit cases, so 20-bit > > > > > would go for that 24-bit slot also. I don't clearly recall if I > > > > > had explicitly tested S20_3LE, but I feel it should work since I put > there... > > > > > > > > For S20_3LE, the width is 20bit, but the ASRC only support 24bit, > > > > if set the ASRMCR1n.IWD= 24bit, because the actual width is 20 > > > > bit, the volume is Lower than expected, it likes 24bit data right > > > > shift 4 > bit. > > > > So it is not supported. > > > > > > Hmm..S20_3LE right-aligns 20 bits in a 24-bit slot? I thought > > > they're left aligned... > > > > > > If this is the case...shouldn't we have the same lower-volume > > > problem for all hardwares that support S20_3LE now? > > > > Actually some hardware/module when they do transmission from FIFO to > > shift register, they can select the start bit, for example from the > > 20th bit. but not all module have this capability. > > > > For ASRC, it haven't. IWD can only cover the data width, there is no > > Other bit for slot width. > > Okay..let's drop the S20_3LE then. But would it be possible for you to > elaborate the reasoning into the commit message also? Just for case when > people ask why we remove it simply. > > Thanks OK. Best regards Wang shengjiu
Re: [GIT PULL] Device properties framework updates for v5.4-rc1
The pull request you sent on Tue, 17 Sep 2019 12:27:16 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git > devprop-5.4-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/35f7a95266153b1cf0caca3aa9661cb721864527 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Power management updates for v5.4-rc1
The pull request you sent on Tue, 17 Sep 2019 12:23:15 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pm-5.4-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/77dcfe2b9edc98286cf18e03c243c9b999f955d9 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] ACPI updates for v5.4-rc1
The pull request you sent on Tue, 17 Sep 2019 12:25:05 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git acpi-5.4-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d2aaa49e281959828370667edbc1cdcc7fc4026a Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
RE: [PATCH 3/6] Timer: expose monotonic clock and counter value
Hi Marc,
> -Original Message-
> From: Marc Zyngier
> Sent: Wednesday, September 18, 2019 1:10 AM
> To: Jianyong Wu (Arm Technology China) ;
> net...@vger.kernel.org; pbonz...@redhat.com;
> sean.j.christopher...@intel.com; richardcoch...@gmail.com; Mark Rutland
> ; Will Deacon ; Suzuki
> Poulose
> Cc: linux-kernel@vger.kernel.org; Steve Capper ;
> Kaly Xin (Arm Technology China) ; Justin He (Arm
> Technology China) ; nd ; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH 3/6] Timer: expose monotonic clock and counter value
>
> On 17/09/2019 12:24, Jianyong Wu wrote:
> > A number of PTP drivers (such as ptp-kvm) are assuming what the
> > current clock source is, which could lead to interesting effects on
> > systems where the clocksource can change depending on external events.
> >
> > For this purpose, add a new API that retrives both the current
> > monotonic clock as well as its counter value.
> >
> > Signed-off-by: Marc Zyngier
> > Signed-off-by: Jianyong Wu
>
> There must be something wrong with the way you've taken this patch in your
> tree. My authorship is gone (not that I deeply care about it, but it is good
> practice to keep attributions), and the subject line has been rewritten.
>
> I'd appreciate it if you could fix this in a future revision of this series.
> For
> reference, the original patch is here[1].
>
Sorry for "steal" your patch, I'm not familiar with it and neglect this
important change.
I just copy this patch from your email and add the subject myself.
I will fix all of them later in v3.
> > ---
> > include/linux/timekeeping.h | 3 +++
> > kernel/time/timekeeping.c | 13 +
> > 2 files changed, 16 insertions(+)
> >
> > diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
> > index a8ab0f143ac4..a5389adaa8bc 100644
> > --- a/include/linux/timekeeping.h
> > +++ b/include/linux/timekeeping.h
> > @@ -247,6 +247,9 @@ extern int get_device_system_crosststamp(
> > struct system_time_snapshot *history,
> > struct system_device_crosststamp *xtstamp);
> >
> > +/* Obtain current monotonic clock and its counter value */ extern
> > +void get_current_counterval(struct system_counterval_t *sc);
> > +
> > /*
> > * Simultaneously snapshot realtime and monotonic raw clocks
> > */
> > diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> > index 44b726bab4bd..07a0969625b1 100644
> > --- a/kernel/time/timekeeping.c
> > +++ b/kernel/time/timekeeping.c
> > @@ -1098,6 +1098,19 @@ static bool cycle_between(u64 before, u64 test,
> u64 after)
> > return false;
> > }
> >
> > +/**
> > + * get_current_counterval - Snapshot the current clocksource and counter
> value
> > + * @sc:Pointer to a struct containing the current clocksource and its
> value
> > + */
> > +void get_current_counterval(struct system_counterval_t *sc) {
> > + struct timekeeper *tk = _core.timekeeper;
> > +
> > + sc->cs = READ_ONCE(tk->tkr_mono.clock);
> > + sc->cycles = sc->cs->read(sc->cs);
> > +}
> > +EXPORT_SYMBOL_GPL(get_current_counterval);
>
> This export wasn't in my original patch. I guess you need it because your ptp
> driver builds as a module? It'd be good to mention it in the commit log.
>
Yeah, ptp_kvm will be a module, so export is necessary. I will mention this
change
in commit log.
Thanks
Jianyong Wu
> > +
> > /**
> > * get_device_system_crosststamp - Synchronously capture
> system/device timestamp
> > * @get_time_fn: Callback to get simultaneous device time and
> >
>
> Thanks,
>
> M.
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-
> platforms.git/commit/?h=timer/counterval=a6e8abce025691b6a55e1c195
> 878d7f76bfeb9d1
> --
> Jazz is not dead, it just smells funny...
Re: [PATCH net-next] ixgbe: Use memzero_explicit directly in crypto cases
On 2019/9/18 10:36, zhong jiang wrote: > In general, Use kzfree() to replace memset() + kfree() is feasible and > resonable. But It's btter to use memzero_explicit() to replace memset() > in crypto cases. s/btter/better/, will repost. sorry for that. Thanks, zhong jiang > Signed-off-by: zhong jiang > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c > b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c > index 113f608..7e4f32f 100644 > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c > @@ -960,9 +960,11 @@ int ixgbe_ipsec_vf_add_sa(struct ixgbe_adapter *adapter, > u32 *msgbuf, u32 vf) > return 0; > > err_aead: > - kzfree(xs->aead); > + memzero_explicit(xs->aead, sizeof(*xs->aead)); > + kfree(xs->aead); > err_xs: > - kzfree(xs); > + memzero_explicit(xs, sizeof(*xs)); > + kfree(xs); > err_out: > msgbuf[1] = err; > return err; > @@ -1047,7 +1049,8 @@ int ixgbe_ipsec_vf_del_sa(struct ixgbe_adapter > *adapter, u32 *msgbuf, u32 vf) > ixgbe_ipsec_del_sa(xs); > > /* remove the xs that was made-up in the add request */ > - kzfree(xs); > + memzero_explicit(xs, sizeof(*xs)); > + kfree(xs); > > return 0; > }
Re: [RFC PATCH v2] mm: initialize struct pages reserved by ZONE_DEVICE driver.
On 2019/09/18 2:04, Waiman Long wrote: > On 9/17/19 12:21 PM, Qian Cai wrote: >> On Tue, 2019-09-17 at 11:49 -0400, Waiman Long wrote: >>> On 9/17/19 3:13 AM, David Hildenbrand wrote: On 17.09.19 04:34, Toshiki Fukasawa wrote: > On 2019/09/09 16:46, David Hildenbrand wrote: >> Let's take a step back here to understand the issues I am aware of. I >> think we should solve this for good now: >> >> A PFN walker takes a look at a random PFN at a random point in time. It >> finds a PFN with SECTION_MARKED_PRESENT && !SECTION_IS_ONLINE. The >> options are: >> >> 1. It is buddy memory (add_memory()) that has not been online yet. The >> memmap contains garbage. Don't access. >> >> 2. It is ZONE_DEVICE memory with a valid memmap. Access it. >> >> 3. It is ZONE_DEVICE memory with an invalid memmap, because the section >> is only partially present: E.g., device starts at offset 64MB within a >> section or the device ends at offset 64MB within a section. Don't access >> it. > I don't agree with case #3. In the case, struct page area is not > allocated on > ZONE_DEVICE, but is allocated on system memory. So I think we can access > the > struct pages. What do you mean "invalid memmap"? No, that's not the case. There is no memory, especially not system memory. We only allow partially present sections (sub-section memory hotplug) for ZONE_DEVICE. invalid memmap == memmap was not initialized == struct pages contains garbage. There is a memmap, but accessing it (e.g., pfn_to_nid()) will trigger a BUG. >>> As long as the page structures exist, they should be initialized to some >>> known state. We could set PagePoison for those invalid memmap. It is the >> Sounds like you want to run page_init_poison() by default. > > Yes for those pages that are not initialized otherwise. I don't want to > run page_init_poison() for the whole ZONE_DEVICE memory range as it can > take a while if we are talking about TBs of persistent memory. Also most > of the pages will be reinitialized anyway in the init process. So it is > mostly a wasted effort. However, for those reserved pages that are not > being exported to the memory management layer, having them initialized > to a known state will cause less problem down the road. > The same can be said about altmap->reserve. I think it should be initialized since the struct page exists. Thanks, Toshiki Fukasawa
Re: [RFC PATCH v2] mm: initialize struct pages reserved by ZONE_DEVICE driver.
On 2019/09/17 19:20, David Hildenbrand wrote: > On 17.09.19 11:32, Toshiki Fukasawa wrote: >> On 2019/09/17 16:13, David Hildenbrand wrote: >>> On 17.09.19 04:34, Toshiki Fukasawa wrote: On 2019/09/09 16:46, David Hildenbrand wrote: > Let's take a step back here to understand the issues I am aware of. I > think we should solve this for good now: > > A PFN walker takes a look at a random PFN at a random point in time. It > finds a PFN with SECTION_MARKED_PRESENT && !SECTION_IS_ONLINE. The > options are: > > 1. It is buddy memory (add_memory()) that has not been online yet. The > memmap contains garbage. Don't access. > > 2. It is ZONE_DEVICE memory with a valid memmap. Access it. > > 3. It is ZONE_DEVICE memory with an invalid memmap, because the section > is only partially present: E.g., device starts at offset 64MB within a > section or the device ends at offset 64MB within a section. Don't access > it. I don't agree with case #3. In the case, struct page area is not allocated on ZONE_DEVICE, but is allocated on system memory. So I think we can access the struct pages. What do you mean "invalid memmap"? >>> No, that's not the case. There is no memory, especially not system >>> memory. We only allow partially present sections (sub-section memory >>> hotplug) for ZONE_DEVICE. >> >> Let me clear my thoughts. If I read correctly, the struct pages for sections >> (including partially present sections) on ZONE_DEVICE are allocated by >> vmemmap_populate(). And all the struct pages except (altmap->base_pfn) to >> (altmap->base_pfn + altmap->reserve) are initialized by memmap_init_zone() >> and memmap_init_zone_device(). >> >> Do struct pages for partially present sections go through a different >> process? > > No. However, the memmap is initialized via move_pfn_range_to_zone(). So > partially present sections will have partially uninitialized memmaps. > Thank you for explanation. To my understanding, depending on architecture, the situation is possible that the struct pages for entire section is allocated, but only pages in the zone are initialized. Thanks, Toshiki Fukasawa
Re: [PATCH v5 1/5] pinctrl: mediatek: Check gpio pin number and use binary search in mtk_hw_pin_field_lookup()
Dear reviewer,
Due to my operation error, one file (pinctrl-paris.h) is missed in patch
seriers 5/5 of v4.
v5 is sent to correct this error.
On Wed, 2019-09-18 at 10:39 +0800, Light Hsieh wrote:
> 1. Check if gpio pin number is in valid range to prevent from get invalid
>pointer 'desc' in the following code:
> desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
>
> 2. Use binary search in mtk_hw_pin_field_lookup()
>Modify mtk_hw_pin_field_lookup() to use binary search for accelerating
>search.
>
> ---
> drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 24
> +++-
> drivers/pinctrl/mediatek/pinctrl-paris.c | 19 +++
> 2 files changed, 38 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> index 20e1c89..4687f63 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> @@ -68,7 +68,7 @@ static int mtk_hw_pin_field_lookup(struct mtk_pinctrl *hw,
> {
> const struct mtk_pin_field_calc *c, *e;
> const struct mtk_pin_reg_calc *rc;
> - u32 bits;
> + u32 bits, start = 0, end, found = 0, check;
>
> if (hw->soc->reg_cal && hw->soc->reg_cal[field].range) {
> rc = >soc->reg_cal[field];
> @@ -79,21 +79,32 @@ static int mtk_hw_pin_field_lookup(struct mtk_pinctrl *hw,
> return -ENOTSUPP;
> }
>
> + end = rc->nranges - 1;
> c = rc->range;
> e = c + rc->nranges;
>
> - while (c < e) {
> - if (desc->number >= c->s_pin && desc->number <= c->e_pin)
> + while (start <= end) {
> + check = (start + end) >> 1;
> + if (desc->number >= rc->range[check].s_pin
> + && desc->number <= rc->range[check].e_pin) {
> + found = 1;
> break;
> - c++;
> + } else if (start == end)
> + break;
> + else if (desc->number < rc->range[check].s_pin)
> + end = check - 1;
> + else
> + start = check + 1;
> }
>
> - if (c >= e) {
> + if (!found) {
> dev_dbg(hw->dev, "Not support field %d for pin = %d (%s)\n",
> field, desc->number, desc->name);
> return -ENOTSUPP;
> }
>
> + c = rc->range + check;
> +
> if (c->i_base > hw->nbase - 1) {
> dev_err(hw->dev,
> "Invalid base for field %d for pin = %d (%s)\n",
> @@ -182,6 +193,9 @@ int mtk_hw_set_value(struct mtk_pinctrl *hw, const struct
> mtk_pin_desc *desc,
> if (err)
> return err;
>
> + if (value < 0 || value > pf.mask)
> + return -EINVAL;
> +
> if (!pf.next)
> mtk_rmw(hw, pf.index, pf.offset, pf.mask << pf.bitpos,
> (value & pf.mask) << pf.bitpos);
> diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c
> b/drivers/pinctrl/mediatek/pinctrl-paris.c
> index 923264d..28b4951 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-paris.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
> @@ -693,6 +693,9 @@ static int mtk_gpio_get_direction(struct gpio_chip *chip,
> unsigned int gpio)
> const struct mtk_pin_desc *desc;
> int value, err;
>
> + if (gpio > hw->soc->npins)
> + return -EINVAL;
> +
> desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
>
> err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_DIR, );
> @@ -708,6 +711,9 @@ static int mtk_gpio_get(struct gpio_chip *chip, unsigned
> int gpio)
> const struct mtk_pin_desc *desc;
> int value, err;
>
> + if (gpio > hw->soc->npins)
> + return -EINVAL;
> +
> desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
>
> err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_DI, );
> @@ -722,6 +728,9 @@ static void mtk_gpio_set(struct gpio_chip *chip, unsigned
> int gpio, int value)
> struct mtk_pinctrl *hw = gpiochip_get_data(chip);
> const struct mtk_pin_desc *desc;
>
> + if (gpio > hw->soc->npins)
> + return;
> +
> desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
>
> mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_DO, !!value);
> @@ -729,12 +738,22 @@ static void mtk_gpio_set(struct gpio_chip *chip,
> unsigned int gpio, int value)
>
> static int mtk_gpio_direction_input(struct gpio_chip *chip, unsigned int
> gpio)
> {
> + struct mtk_pinctrl *hw = gpiochip_get_data(chip);
> +
> + if (gpio > hw->soc->npins)
> + return -EINVAL;
> +
> return pinctrl_gpio_direction_input(chip->base + gpio);
> }
>
> static int mtk_gpio_direction_output(struct gpio_chip *chip, unsigned int
> gpio,
>int value)
> {
> + struct mtk_pinctrl *hw = gpiochip_get_data(chip);
> +
> + if
[RESENT PATCH net-next] ixgbe: Use memzero_explicit directly in crypto cases
In general, Use kzfree() to replace memset() + kfree() is feasible and resonable. But It's better to use memzero_explicit() to replace memset() in crypto cases. Signed-off-by: zhong jiang --- drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c index 113f608..7e4f32f 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c @@ -960,9 +960,11 @@ int ixgbe_ipsec_vf_add_sa(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf) return 0; err_aead: - kzfree(xs->aead); + memzero_explicit(xs->aead, sizeof(*xs->aead)); + kfree(xs->aead); err_xs: - kzfree(xs); + memzero_explicit(xs, sizeof(*xs)); + kfree(xs); err_out: msgbuf[1] = err; return err; @@ -1047,7 +1049,8 @@ int ixgbe_ipsec_vf_del_sa(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf) ixgbe_ipsec_del_sa(xs); /* remove the xs that was made-up in the add request */ - kzfree(xs); + memzero_explicit(xs, sizeof(*xs)); + kfree(xs); return 0; } -- 1.7.12.4
[PATCH net-next] ixgbe: Use memzero_explicit directly in crypto cases
In general, Use kzfree() to replace memset() + kfree() is feasible and resonable. But It's btter to use memzero_explicit() to replace memset() in crypto cases. Signed-off-by: zhong jiang --- drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c index 113f608..7e4f32f 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c @@ -960,9 +960,11 @@ int ixgbe_ipsec_vf_add_sa(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf) return 0; err_aead: - kzfree(xs->aead); + memzero_explicit(xs->aead, sizeof(*xs->aead)); + kfree(xs->aead); err_xs: - kzfree(xs); + memzero_explicit(xs, sizeof(*xs)); + kfree(xs); err_out: msgbuf[1] = err; return err; @@ -1047,7 +1049,8 @@ int ixgbe_ipsec_vf_del_sa(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf) ixgbe_ipsec_del_sa(xs); /* remove the xs that was made-up in the add request */ - kzfree(xs); + memzero_explicit(xs, sizeof(*xs)); + kfree(xs); return 0; } -- 1.7.12.4
[PATCH v5 5/5] pinctrl: mediatek: Add support for pin configuration dump via debugfs.
Add support for pin configuration dump via catting
/sys/kernel/debug/pinctrl/$platform_dependent_path/pinconf-pins.
pinctrl framework had already support such dump. This patch implement the
operation function pointer to fullfill this dump.
---
drivers/pinctrl/mediatek/pinctrl-paris.c | 88
drivers/pinctrl/mediatek/pinctrl-paris.h | 30 +++
2 files changed, 118 insertions(+)
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c
b/drivers/pinctrl/mediatek/pinctrl-paris.c
index e847867..6acbdc3 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -530,12 +530,99 @@ static int mtk_pctrl_get_group_pins(struct pinctrl_dev
*pctldev,
return 0;
}
+int mtk_hw_get_value_wrap(struct mtk_pinctrl *hw, unsigned int gpio, int field)
+{
+ const struct mtk_pin_desc *desc;
+ int value, err;
+
+ if (gpio > hw->soc->npins)
+ return -EINVAL;
+
+ desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
+
+ err = mtk_hw_get_value(hw, desc, field, );
+ if (err)
+ return err;
+
+ return value;
+}
+
+ssize_t mtk_pctrl_show_one_pin(struct mtk_pinctrl *hw,
+ unsigned int gpio, char *buf, unsigned int bufLen)
+{
+ const struct mtk_pin_desc *desc;
+ int pinmux, pullup, pullen, r1 = -1, r0 = -1, len = 0;
+
+ if (gpio > hw->soc->npins)
+ return -EINVAL;
+
+ desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
+ pinmux = mtk_pctrl_get_pinmux(hw, gpio);
+ if (pinmux >= hw->soc->nfuncs)
+ pinmux -= hw->soc->nfuncs;
+
+ mtk_pinconf_bias_get_combo(hw, desc, , );
+ if (pullen == MTK_PUPD_SET_R1R0_00) {
+ pullen = 0;
+ r1 = 0;
+ r0 = 0;
+ } else if (pullen == MTK_PUPD_SET_R1R0_01) {
+ pullen = 1;
+ r1 = 0;
+ r0 = 1;
+ } else if (pullen == MTK_PUPD_SET_R1R0_10) {
+ pullen = 1;
+ r1 = 1;
+ r0 = 0;
+ } else if (pullen == MTK_PUPD_SET_R1R0_11) {
+ pullen = 1;
+ r1 = 1;
+ r0 = 1;
+ } else if (pullen != MTK_DISABLE && pullen != MTK_ENABLE) {
+ pullen = 0;
+ }
+ len += snprintf(buf + len, bufLen - len,
+ "%03d: %1d%1d%1d%1d%02d%1d%1d%1d%1d",
+ gpio,
+ pinmux,
+ mtk_pctrl_get_direction(hw, gpio),
+ mtk_pctrl_get_out(hw, gpio),
+ mtk_pctrl_get_in(hw, gpio),
+ mtk_pctrl_get_driving(hw, gpio),
+ mtk_pctrl_get_smt(hw, gpio),
+ mtk_pctrl_get_ies(hw, gpio),
+ pullen,
+ pullup);
+
+ if (r1 != -1) {
+ len += snprintf(buf + len, bufLen - len, " (%1d %1d)\n",
+ r1, r0);
+ } else {
+ len += snprintf(buf + len, bufLen - len, "\n");
+ }
+
+ return len;
+}
+
+#define PIN_DBG_BUF_SZ 96
+static void mtk_pctrl_dbg_show(struct pinctrl_dev *pctldev, struct seq_file *s,
+ unsigned int gpio)
+{
+ struct mtk_pinctrl *hw = pinctrl_dev_get_drvdata(pctldev);
+ char buf[PIN_DBG_BUF_SZ];
+
+ (void)mtk_pctrl_show_one_pin(hw, gpio, buf, PIN_DBG_BUF_SZ);
+
+ seq_printf(s, "%s", buf);
+}
+
static const struct pinctrl_ops mtk_pctlops = {
.dt_node_to_map = mtk_pctrl_dt_node_to_map,
.dt_free_map= pinctrl_utils_free_map,
.get_groups_count = mtk_pctrl_get_groups_count,
.get_group_name = mtk_pctrl_get_group_name,
.get_group_pins = mtk_pctrl_get_group_pins,
+ .pin_dbg_show = mtk_pctrl_dbg_show,
};
static int mtk_pmx_get_funcs_cnt(struct pinctrl_dev *pctldev)
@@ -632,6 +719,7 @@ static int mtk_pconf_group_set(struct pinctrl_dev *pctldev,
unsigned group,
.pin_config_get = mtk_pinconf_get,
.pin_config_group_get = mtk_pconf_group_get,
.pin_config_group_set = mtk_pconf_group_set,
+ .is_generic = true,
};
static struct pinctrl_desc mtk_desc = {
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.h
b/drivers/pinctrl/mediatek/pinctrl-paris.h
index 3d43771..d73f4b6 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.h
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.h
@@ -60,6 +60,36 @@
int mtk_paris_pinctrl_probe(struct platform_device *pdev,
const struct mtk_pin_soc *soc);
+int mtk_hw_get_value_wrap(struct mtk_pinctrl *hw, unsigned int gpio, int
field);
+
+#define mtk_pctrl_get_pinmux(hw, gpio) \
+ mtk_hw_get_value_wrap(hw, gpio, PINCTRL_PIN_REG_MODE)
+
+/* MTK HW use 0 as input, 1 for output
+ * This interface is for get direct register value,
+ * so don't reverse
+ */
+#define
[PATCH v5 1/5] pinctrl: mediatek: Check gpio pin number and use binary search in mtk_hw_pin_field_lookup()
1. Check if gpio pin number is in valid range to prevent from get invalid
pointer 'desc' in the following code:
desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
2. Use binary search in mtk_hw_pin_field_lookup()
Modify mtk_hw_pin_field_lookup() to use binary search for accelerating
search.
---
drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 24 +++-
drivers/pinctrl/mediatek/pinctrl-paris.c | 19 +++
2 files changed, 38 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
index 20e1c89..4687f63 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
@@ -68,7 +68,7 @@ static int mtk_hw_pin_field_lookup(struct mtk_pinctrl *hw,
{
const struct mtk_pin_field_calc *c, *e;
const struct mtk_pin_reg_calc *rc;
- u32 bits;
+ u32 bits, start = 0, end, found = 0, check;
if (hw->soc->reg_cal && hw->soc->reg_cal[field].range) {
rc = >soc->reg_cal[field];
@@ -79,21 +79,32 @@ static int mtk_hw_pin_field_lookup(struct mtk_pinctrl *hw,
return -ENOTSUPP;
}
+ end = rc->nranges - 1;
c = rc->range;
e = c + rc->nranges;
- while (c < e) {
- if (desc->number >= c->s_pin && desc->number <= c->e_pin)
+ while (start <= end) {
+ check = (start + end) >> 1;
+ if (desc->number >= rc->range[check].s_pin
+&& desc->number <= rc->range[check].e_pin) {
+ found = 1;
break;
- c++;
+ } else if (start == end)
+ break;
+ else if (desc->number < rc->range[check].s_pin)
+ end = check - 1;
+ else
+ start = check + 1;
}
- if (c >= e) {
+ if (!found) {
dev_dbg(hw->dev, "Not support field %d for pin = %d (%s)\n",
field, desc->number, desc->name);
return -ENOTSUPP;
}
+ c = rc->range + check;
+
if (c->i_base > hw->nbase - 1) {
dev_err(hw->dev,
"Invalid base for field %d for pin = %d (%s)\n",
@@ -182,6 +193,9 @@ int mtk_hw_set_value(struct mtk_pinctrl *hw, const struct
mtk_pin_desc *desc,
if (err)
return err;
+ if (value < 0 || value > pf.mask)
+ return -EINVAL;
+
if (!pf.next)
mtk_rmw(hw, pf.index, pf.offset, pf.mask << pf.bitpos,
(value & pf.mask) << pf.bitpos);
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c
b/drivers/pinctrl/mediatek/pinctrl-paris.c
index 923264d..28b4951 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -693,6 +693,9 @@ static int mtk_gpio_get_direction(struct gpio_chip *chip,
unsigned int gpio)
const struct mtk_pin_desc *desc;
int value, err;
+ if (gpio > hw->soc->npins)
+ return -EINVAL;
+
desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_DIR, );
@@ -708,6 +711,9 @@ static int mtk_gpio_get(struct gpio_chip *chip, unsigned
int gpio)
const struct mtk_pin_desc *desc;
int value, err;
+ if (gpio > hw->soc->npins)
+ return -EINVAL;
+
desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_DI, );
@@ -722,6 +728,9 @@ static void mtk_gpio_set(struct gpio_chip *chip, unsigned
int gpio, int value)
struct mtk_pinctrl *hw = gpiochip_get_data(chip);
const struct mtk_pin_desc *desc;
+ if (gpio > hw->soc->npins)
+ return;
+
desc = (const struct mtk_pin_desc *)>soc->pins[gpio];
mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_DO, !!value);
@@ -729,12 +738,22 @@ static void mtk_gpio_set(struct gpio_chip *chip, unsigned
int gpio, int value)
static int mtk_gpio_direction_input(struct gpio_chip *chip, unsigned int gpio)
{
+ struct mtk_pinctrl *hw = gpiochip_get_data(chip);
+
+ if (gpio > hw->soc->npins)
+ return -EINVAL;
+
return pinctrl_gpio_direction_input(chip->base + gpio);
}
static int mtk_gpio_direction_output(struct gpio_chip *chip, unsigned int gpio,
int value)
{
+ struct mtk_pinctrl *hw = gpiochip_get_data(chip);
+
+ if (gpio > hw->soc->npins)
+ return -EINVAL;
+
mtk_gpio_set(chip, gpio, value);
return pinctrl_gpio_direction_output(chip->base + gpio);
--
1.8.1.1.dirty
[PATCH v5 3/5] pinctrl: mediatek: Refine mtk_pinconf_get() and mtk_pinconf_set()
1.Refine mtk_pinconf_get():
1.1 Use only one occurrence of return at end of this function.
1.2 Correct cases for PIN_CONFIG_SLEW_RATE, PIN_CONFIG_INPUT_SCHMITT_ENABLE,
and PIN_CONFIG_OUTPUT_ENABLE -
Use variable ret to receive value in mtk_hw_get_value() (instead of
variable val) since pinconf_to_config_packed() at end of this function
use variable ret to pack config value.
2.Refine mtk_pinconf_set():
2.1 Use only one occurrence of return at end of this function.
2.2 Modify case of PIN_CONFIG_INPUT_ENABLE -
Remove check of ies_present flag and always invoke mtk_hw_set_value()
since mtk_hw_pin_field_lookup() invoked inside mtk_hw_set_value() has
the same effect of checking if ies control is supported.
[The rationale is that: available of a control is always checked
in mtk_hw_pin_field_lookup() and no need to add ies_present flag
specially for ies control.]
2.3 Simply code logic for case of PIN_CONFIG_INPUT_SCHMITT.
2.4 Add case for PIN_CONFIG_INPUT_SCHMITT_ENABLE and process it with the
same code for case of PIN_CONFIG_INPUT_SCHMITT.
---
drivers/pinctrl/mediatek/pinctrl-mt6765.c | 1 -
drivers/pinctrl/mediatek/pinctrl-paris.c | 205 +++---
2 files changed, 75 insertions(+), 131 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
index e024ebc..bada37f 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
@@ -1070,7 +1070,6 @@
.ngrps = ARRAY_SIZE(mtk_pins_mt6765),
.eint_hw = _eint_hw,
.gpio_m = 0,
- .ies_present = true,
.base_names = mt6765_pinctrl_register_base_names,
.nbase_names = ARRAY_SIZE(mt6765_pinctrl_register_base_names),
.bias_disable_set = mtk_pinconf_bias_disable_set,
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c
b/drivers/pinctrl/mediatek/pinctrl-paris.c
index 71c94b2..9433b72 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -78,93 +78,75 @@ static int mtk_pinconf_get(struct pinctrl_dev *pctldev,
{
struct mtk_pinctrl *hw = pinctrl_dev_get_drvdata(pctldev);
u32 param = pinconf_to_config_param(*config);
- int val, val2, err, reg, ret = 1;
+ int err, reg, ret = 1;
const struct mtk_pin_desc *desc;
desc = (const struct mtk_pin_desc *)>soc->pins[pin];
switch (param) {
case PIN_CONFIG_BIAS_DISABLE:
- if (hw->soc->bias_disable_get) {
+ if (hw->soc->bias_disable_get)
err = hw->soc->bias_disable_get(hw, desc, );
- if (err)
- return err;
- } else {
- return -ENOTSUPP;
- }
+ else
+ err = -ENOTSUPP;
break;
case PIN_CONFIG_BIAS_PULL_UP:
- if (hw->soc->bias_get) {
+ if (hw->soc->bias_get)
err = hw->soc->bias_get(hw, desc, 1, );
- if (err)
- return err;
- } else {
- return -ENOTSUPP;
- }
+ else
+ err = -ENOTSUPP;
break;
case PIN_CONFIG_BIAS_PULL_DOWN:
- if (hw->soc->bias_get) {
+ if (hw->soc->bias_get)
err = hw->soc->bias_get(hw, desc, 0, );
- if (err)
- return err;
- } else {
- return -ENOTSUPP;
- }
+ else
+ err = -ENOTSUPP;
break;
case PIN_CONFIG_SLEW_RATE:
- err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_SR, );
- if (err)
- return err;
-
- if (!val)
- return -EINVAL;
-
+ err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_SR, );
break;
case PIN_CONFIG_INPUT_ENABLE:
case PIN_CONFIG_OUTPUT_ENABLE:
- err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_DIR, );
+ err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_DIR, );
if (err)
- return err;
-
- /* HW takes input mode as zero; output mode as non-zero */
- if ((val && param == PIN_CONFIG_INPUT_ENABLE) ||
- (!val && param == PIN_CONFIG_OUTPUT_ENABLE))
- return -EINVAL;
+ goto out;
+ /* CONFIG Current direction return value
+* - - --
+* OUTPUT_ENABLE output 1 (= HW value)
+* input0 (= HW value)
+* INPUT_ENABLE
[PATCH v5 4/5] pinctrl: mediatek: Backward compatible to previous Mediatek's bias-pull usage
Refine mtk_pinconf_set()/mtk_pinconf_get() for backward compatibility to
previous Mediatek's bias-pull usage.
In PINCTRL_MTK that use pinctrl-mtk-common.c, bias-pull setting for pins
with 2 pull resistors can be specified as value for bias-pull-up and
bias-pull-down. For example:
bias-pull-up = ;
bias-pull-up = ;
bias-pull-up = ;
bias-pull-up = ;
bias-pull-down = ;
bias-pull-down = ;
bias-pull-down = ;
bias-pull-down = ;
On the other hand, PINCTRL_MTK_PARIS use customized properties
"mediatek,pull-up-adv" and "mediatek,pull-down-adv" to specify bias-pull
setting for pins with 2 pull resistors.
This introduce in-compatibility in device tree and increatse porting
effort to Mediatek's customer that had already used PINCTRL_MTK version.
Besides, if customers are not awared of this change and still write devicetree
for PINCTRL_MTK version, they may encounter runtime failure with pinctrl and
spent time to debug.
This patch add backward compatible to previous Mediatek's bias-pull usage
so that Mediatek's customer need not use a new devicetree property name.
The rationale is that: changing driver implemenation had better leave
interface unchanged.
---
drivers/pinctrl/mediatek/pinctrl-mt6765.c| 6 +-
drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 285 +++
drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 11 +
drivers/pinctrl/mediatek/pinctrl-paris.c | 49 ++--
4 files changed, 327 insertions(+), 24 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
index bada37f..ae85fdc 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
@@ -1072,10 +1072,8 @@
.gpio_m = 0,
.base_names = mt6765_pinctrl_register_base_names,
.nbase_names = ARRAY_SIZE(mt6765_pinctrl_register_base_names),
- .bias_disable_set = mtk_pinconf_bias_disable_set,
- .bias_disable_get = mtk_pinconf_bias_disable_get,
- .bias_set = mtk_pinconf_bias_set,
- .bias_get = mtk_pinconf_bias_get,
+ .bias_set_combo = mtk_pinconf_bias_set_combo,
+ .bias_get_combo = mtk_pinconf_bias_get_combo,
.drive_set = mtk_pinconf_drive_set_direct_val,
.drive_get = mtk_pinconf_drive_get_direct_val,
.adv_pull_get = mtk_pinconf_adv_pull_get,
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
index 23a9529..dab8418 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
@@ -13,6 +13,8 @@
#include
#include
+#include
+
#include "mtk-eint.h"
#include "pinctrl-mtk-common-v2.h"
@@ -205,6 +207,20 @@ int mtk_hw_set_value(struct mtk_pinctrl *hw, const struct
mtk_pin_desc *desc,
return 0;
}
+void mtk_hw_set_value_no_lookup(struct mtk_pinctrl *hw,
+ const struct mtk_pin_desc *desc,
+ int value, struct mtk_pin_field *pf)
+{
+ if (value < 0 || value > pf->mask)
+ return;
+
+ if (!pf->next)
+ mtk_rmw(hw, pf->index, pf->offset, pf->mask << pf->bitpos,
+ (value & pf->mask) << pf->bitpos);
+ else
+ mtk_hw_write_cross_field(hw, pf, value);
+}
+
int mtk_hw_get_value(struct mtk_pinctrl *hw, const struct mtk_pin_desc *desc,
int field, int *value)
{
@@ -224,6 +240,17 @@ int mtk_hw_get_value(struct mtk_pinctrl *hw, const struct
mtk_pin_desc *desc,
return 0;
}
+void mtk_hw_get_value_no_lookup(struct mtk_pinctrl *hw,
+ const struct mtk_pin_desc *desc,
+ int *value, struct mtk_pin_field *pf)
+{
+ if (!pf->next)
+ *value = (mtk_r32(hw, pf->index, pf->offset)
+ >> pf->bitpos) & pf->mask;
+ else
+ mtk_hw_read_cross_field(hw, pf, value);
+}
+
static int mtk_xt_find_eint_num(struct mtk_pinctrl *hw, unsigned long eint_n)
{
const struct mtk_pin_desc *desc;
@@ -516,6 +543,264 @@ int mtk_pinconf_bias_get_rev1(struct mtk_pinctrl *hw,
return 0;
}
+/* Combo for the following pull register type:
+ * 1. PU + PD
+ * 2. PULLSEL + PULLEN
+ * 3. PUPD + R0 + R1
+ */
+int mtk_pinconf_bias_set_pu_pd(struct mtk_pinctrl *hw,
+ const struct mtk_pin_desc *desc,
+ u32 pullup, u32 arg)
+{
+ struct mtk_pin_field pf;
+ int err = -EINVAL;
+ int pu, pd;
+
+ err = mtk_hw_pin_field_lookup(hw, desc, PINCTRL_PIN_REG_PU, );
+ if (err)
+ goto out;
+
+ if (arg == MTK_DISABLE) {
+ pu = 0;
+ pd = 0;
+ } else if ((arg == MTK_ENABLE) && pullup) {
+ pu = 1;
+ pd = 0;
+ } else if ((arg == MTK_ENABLE) && !pullup) {
+ pu = 0;
+
[PATCH v5 2/5] pinctrl: mediatek: Supporting driving setting without mapping current to register value
Mediatek's smarphone project actual usage does need to know current value
(in mA) in procedure of finding the best driving setting.
The steps in the procedure is like as follow:
1. set driving setting field in setting register as 0, measure waveform,
perform test, and etc.
2. set driving setting field in setting register as 1, measure waveform,
perform test, and etc.
...
n. set driving setting field in setting register as n-1, measure
waveform, perform test, and etc.
Check the results of steps 1~n and adopt the setting that get best result.
This procedure does need to know the mapping between current to register
value.
Therefore, setting driving without mapping current is more pratical for
Mediatek's smartphone usage.
---
drivers/pinctrl/mediatek/pinctrl-mt6765.c| 4 ++--
drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 21 +
drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h | 5 +
drivers/pinctrl/mediatek/pinctrl-paris.c | 1 +
4 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
index 32451e8..e024ebc 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt6765.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt6765.c
@@ -1077,8 +1077,8 @@
.bias_disable_get = mtk_pinconf_bias_disable_get,
.bias_set = mtk_pinconf_bias_set,
.bias_get = mtk_pinconf_bias_get,
- .drive_set = mtk_pinconf_drive_set_rev1,
- .drive_get = mtk_pinconf_drive_get_rev1,
+ .drive_set = mtk_pinconf_drive_set_direct_val,
+ .drive_get = mtk_pinconf_drive_get_direct_val,
.adv_pull_get = mtk_pinconf_adv_pull_get,
.adv_pull_set = mtk_pinconf_adv_pull_set,
};
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
index 4687f63..23a9529 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
@@ -607,6 +607,27 @@ int mtk_pinconf_drive_get_rev1(struct mtk_pinctrl *hw,
return 0;
}
+/* Revision direct value */
+int mtk_pinconf_drive_set_direct_val(struct mtk_pinctrl *hw,
+ const struct mtk_pin_desc *desc, u32 arg)
+{
+ int err;
+
+ err = mtk_hw_set_value(hw, desc, PINCTRL_PIN_REG_DRV, arg);
+
+ return err;
+}
+
+int mtk_pinconf_drive_get_direct_val(struct mtk_pinctrl *hw,
+ const struct mtk_pin_desc *desc, int *val)
+{
+ int err;
+
+ err = mtk_hw_get_value(hw, desc, PINCTRL_PIN_REG_DRV, val);
+
+ return err;
+}
+
int mtk_pinconf_adv_pull_set(struct mtk_pinctrl *hw,
const struct mtk_pin_desc *desc, bool pullup,
u32 arg)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
index 1b7da42..b3bada0 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.h
@@ -288,6 +288,11 @@ int mtk_pinconf_drive_set_rev1(struct mtk_pinctrl *hw,
int mtk_pinconf_drive_get_rev1(struct mtk_pinctrl *hw,
const struct mtk_pin_desc *desc, int *val);
+int mtk_pinconf_drive_set_direct_val(struct mtk_pinctrl *hw,
+ const struct mtk_pin_desc *desc, u32 arg);
+int mtk_pinconf_drive_get_direct_val(struct mtk_pinctrl *hw,
+ const struct mtk_pin_desc *desc, int *val);
+
int mtk_pinconf_adv_pull_set(struct mtk_pinctrl *hw,
const struct mtk_pin_desc *desc, bool pullup,
u32 arg);
diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c
b/drivers/pinctrl/mediatek/pinctrl-paris.c
index 28b4951..71c94b2 100644
--- a/drivers/pinctrl/mediatek/pinctrl-paris.c
+++ b/drivers/pinctrl/mediatek/pinctrl-paris.c
@@ -964,3 +964,4 @@ static int mtk_paris_pinctrl_resume(struct device *device)
.suspend_noirq = mtk_paris_pinctrl_suspend,
.resume_noirq = mtk_paris_pinctrl_resume,
};
+
--
1.8.1.1.dirty
Re: printk meeting at LPC
On (09/17/19 22:08), Steven Rostedt wrote: > > On (09/13/19 15:26), John Ogness wrote: > > > 2. A kernel thread will be created for each registered console, each > > > responsible for being the sole printers to their respective > > > consoles. With this, console printing is _fully_ decoupled from printk() > > > callers. > > > > sysrq over serial? > > > > What we currently have is hacky, but, as usual, is a "best effort": > > > > >> serial driver IRQ > > > > serial_handle_irq() [console driver] > > uart_handle_sysrq_char() > > handle_sysrq() > >printk() > > call_console_drivers() > > serial_write() [re-enter console driver] > > > > offloading this to kthread may be unreliable. > > But we also talked about an "emergency flush" which will not wait for > the kthreads to finish and just output everything it can find in the > printk buffers (expecting that the consoles have an "emergency" > handler. We can add a sysrq to do an emergency flush. I'm sorry, I wasn't there, so I'm surely is missing on some details. I agree that when consoles have ->atomic_write then it surely makes sense to switch to emergency mode. I like the emergency state approach, but I'm not sure how it can be completely invisible to the rest of the system. Quoting John: : Unlike oops_in_progress, this state will not be visible to : anything outside of the printk infrastructure. For instance, tty/sysrq must be able to switch printk emergency on/off. That already means that printk emergency knob should be visible to the rest of the kernel. A long time ago, we had printk_emergency_begin_sync() and printk_emergency_end_sync(), which would define reentrable printk_emergency blocks [1]: printk_emergency_begin_sync(); handle_sysrq(); printk_emergency_end_sync(); We also figured out that some PM (hibernation/suspend/etc.) stages (very early and/or very late ones) [2] also should have printk in emergency mode, plus some other parts of the kernel [3]. [1] https://lore.kernel.org/lkml/20170815025625.1977-4-sergey.senozhat...@gmail.com/ [2] https://lore.kernel.org/lkml/20170815025625.1977-7-sergey.senozhat...@gmail.com/ [3] https://lore.kernel.org/lkml/20170815025625.1977-8-sergey.senozhat...@gmail.com/ -ss
RE: [PATCH] staging: exfat: add exfat filesystem code to
I've summarized some of the big differences between sdfat and exfat in linux-next. 1. sdfat has been refactored to improve compatibility, readability and to be linux friendly.(included support mass storages larger than 2TB.) 2. sdfat has been optimized for the performance of SD-cards. - Support SD-card friendly block allocation and delayed allocation for vfat-fs only. - Support aligned_mpage_write for both vfat-fs and exfat-fs 3. sdfat has been optimized for the performance of general operations like create,lookup and readdir. 4. Fix many critical and minor bugs - Handle many kinds of error conditions gracefully to prevent panic. - Fix critical bugs related to rmdir, truncate behavior and so on... 5. Fix NLS functions Note, that Samsung is still improving sdfat driver. For instance, what will be realeased soon is sdfat v2.3.0, which will include support for "UtcOffset" of "File Directory Entry", in order to satisfy exFAT specification 7.4. Thanks! > -Original Message- > From: Ju Hyung Park [mailto:qkrwngud...@gmail.com] > Sent: Tuesday, September 17, 2019 3:04 PM > To: Greg KH; namjae.j...@samsung.com; Valdis Kletnieks > Cc: de...@driverdev.osuosl.org; linkinj...@gmail.com; linux- > ker...@vger.kernel.org; alexander.le...@microsoft.com; > sergey.senozhat...@gmail.com; linux-fsde...@vger.kernel.org > Subject: Re: [PATCH] staging: exfat: add exfat filesystem code to > > On Tue, Sep 17, 2019 at 2:47 PM Greg KH wrote: > > It's the fact that it actually was in a form that could be merged, no > > one has done that with the sdfat code :) > > Well, I'm more than happy to help if you guys are happy with merging > the new base. > > > What fixes? That's what I'm asking here. > > I gave this as an example in my previous email: > https://github.com/MotorolaMobilityLLC/kernel-msm/commit/7ab1657 > > > How do we "know" that this is better than what we currently have today? > > We don't, so it's a bit hard to tell someone, "delete the work you did > > and replace it with this other random chunk of code, causing you a bunch > > more work in the process for no specific reason other than it looks > > 'newer'." :( > > The new sdFAT base I'm suggesting, is just as "random" as the one > staging tree is based on. > > If exFAT gets merged to Torvald's tree, there will be a lot more eyes > interested in it. > If there's a better base, we better switch to it now and prevent > further headaches long-term. > > It's really hard to compare those 2 drivers base and extract > meaningful changelogs. > > But regardless, here are some diff stats: > > Kconfig | 79 +- > Makefile | 46 +- > api.c| 423 > api.h| 310 --- > blkdev.c | 409 +--- > cache.c | 1142 - > config.h | 49 - > core.c | 5583 > core.h | 196 -- > core_exfat.c | 1553 > exfat.h | 1309 +++ > exfat_fs.h | 417 > extent.c | 351 --- > fatent.c | 182 -- > misc.c | 401 > nls.c| 490 ++-- > super.c | 5103 +--- > upcase.c | 740 ++ > upcase.h | 407 > version.h| 29 - > xattr.c | 136 -- > 21 files changed, 8186 insertions(+), 11169 deletions(-) > > > Kconfig | 79 +- > Makefile | 46 +- > blkdev.c | 409 +--- > cache.c | 1142 +- > core.c | 5583 ++-- > exfat.h | 1309 > nls.c| 490 ++--- > super.c | 5103 ++- > 8 files changed, 7446 insertions(+), 6715 deletions(-) > > > I recommend looking at what we have in the tree now, and seeing what is > > missing compared to "sdfat". I know a lot of places in the exfat code > > that needs to be fixed up, odds are they are the same stuff that needs > > to be resolved in sdfat as well. > > Would there be any more data that I can provide? > It's really hard to go through the full diff :( > > Thanks.
Re: [PATCH v3 1/2] dt-bindings: phy: intel-sdxc-phy: Add YAML schema for LGM SDXC PHY
Hi Rob, Thank you for the review comments. On 18/9/2019 4:24 AM, Rob Herring wrote: On Wed, Sep 04, 2019 at 02:27:18PM +0800, Ramuthevar,Vadivel MuruganX wrote: From: Ramuthevar Vadivel Murugan Add a YAML schema to use the host controller driver with the SDXC PHY on Intel's Lightning Mountain SoC. Same issues on this one as emmc phy. Agreed!, once clarified the emmc phy comments, let me update further. Thanks! Best Regards Vadivel Signed-off-by: Ramuthevar Vadivel Murugan --- changes in v3: - Rob's review comments addressed and updated the patch - merged syscon and sdxc yaml file as single file after discussion changes in v2: - As per Rob's review comment syscon node entry added instead of reference - splitted two patches one for syscon and another for sdxc phy --- .../bindings/phy/intel,lgm-sdxc-phy.yaml | 69 ++ 1 file changed, 69 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/intel,lgm-sdxc-phy.yaml
Re: [PATCH v5 1/2] dt-bindings: phy: intel-emmc-phy: Add YAML schema for LGM eMMC PHY
Hi Rob,
Thank you for the review comments.
On 17/9/2019 10:23 PM, Rob Herring wrote:
On Wed, Sep 04, 2019 at 01:53:43PM +0800, Ramuthevar,Vadivel MuruganX wrote:
From: Ramuthevar Vadivel Murugan
Add a YAML schema to use the host controller driver with the
eMMC PHY on Intel's Lightning Mountain SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
changes in v5:
- earlier Review-by tag given by Rob
- rework done with syscon parent node.
changes in v4:
- As per Rob's review: validate 5.2 and 5.3
- drop unrelated items.
changes in v3:
- resolve 'make dt_binding_check' warnings
changes in v2:
As per Rob Herring review comments, the following updates
- change GPL-2.0 -> (GPL-2.0-only OR BSD-2-Clause)
- filename is the compatible string plus .yaml
- LGM: Lightning Mountain
- update maintainer
- add intel,syscon under property list
- keep one example instead of two
---
.../bindings/phy/intel,lgm-emmc-phy.yaml | 69 ++
1 file changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml
b/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml
new file mode 100644
index ..8f6ac8b3da42
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/intel,lgm-emmc-phy.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/intel,lgm-emmc-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel Lightning Mountain(LGM) eMMC PHY Device Tree Bindings
+
+maintainers:
+ - Ramuthevar Vadivel Murugan
+
+description: Bindings for eMMC PHY on Intel's Lightning Mountain SoC, syscon
+ node is used to reference the base address of eMMC phy registers.
+
+select:
+ properties:
+compatible:
+ contains:
+const: intel,lgm-syscon
This, plus...
you mean, need to add two compatible here-itself look like below
const: intel,lgm-syscon
const: intel,lgm-emmc-phy
Is it right?
+
+reg:
+ maxItems: 1
+
+ required:
+- compatible
+- reg
+
+properties:
+ "#phy-cells":
+const: 0
+
+ compatible:
+contains:
+ const: intel,lgm-emmc-phy
...this should not pass validation as they contradict each other.
when I do "make dt_binding_check" didn't throw an error, let me double
confirm once clarified first comment.
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+maxItems: 1
+
+required:
+ - "#phy-cells"
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+examples:
+ - |
+sysconf: chiptop@e020 {
+ compatible = "intel,lgm-syscon";
+ reg = <0xe020 0x100>;
I'm still waiting for a complete description of what all is in this
block.
Agree!, I will add it.
+
+ emmc-phy: emmc-phy {
+compatible = "intel,lgm-emmc-phy";
+reg = <0x00a8 0x4>,
+ <0x00ac 0x4>,
+ <0x00b0 0x4>,
+ <0x00b4 0x4>;
Looks contiguous and can be a single entry:
<0xa8 0x10>
Agreed, will fix it.
Best Regards
Vadivel
+clocks = <>;
+clock-names = "emmcclk";
+#phy-cells = <0>;
+ };
+};
+...
--
2.11.0
[PATCH 5/5] leds: lm3692x: Use flags from LM3692X_BRT_CTRL
Use LM3692X_RAMP_EN instead of LM3692X_PWM_HYSTER_4LSB since the later is a flag for the PWM register. The actual register value remains unchanged. Signed-off-by: Guido Günther --- drivers/leds/leds-lm3692x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/leds/leds-lm3692x.c b/drivers/leds/leds-lm3692x.c index d673f706385e..ecac586ca89c 100644 --- a/drivers/leds/leds-lm3692x.c +++ b/drivers/leds/leds-lm3692x.c @@ -269,7 +269,7 @@ static int lm3692x_init(struct lm3692x_led *led) goto out; ret = regmap_write(led->regmap, LM3692X_BRT_CTRL, - LM3692X_BL_ADJ_POL | LM3692X_PWM_HYSTER_4LSB); + LM3692X_BL_ADJ_POL | LM3692X_RAMP_EN); if (ret) goto out; -- 2.23.0.rc1
[PATCH 2/5] leds: lm3692x: Don't overwrite return value in error path
The driver currently reports successful initialization on every failure
as long as it's able to power off the regulator. Don't check the return
value of regulator_disable to avoid that.
Signed-off-by: Guido Günther
---
drivers/leds/leds-lm3692x.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/leds/leds-lm3692x.c b/drivers/leds/leds-lm3692x.c
index 487228c2bed2..f394669ad8f2 100644
--- a/drivers/leds/leds-lm3692x.c
+++ b/drivers/leds/leds-lm3692x.c
@@ -312,15 +312,12 @@ static int lm3692x_init(struct lm3692x_led *led)
if (led->enable_gpio)
gpiod_direction_output(led->enable_gpio, 0);
- if (led->regulator) {
- ret = regulator_disable(led->regulator);
- if (ret)
- dev_err(>client->dev,
- "Failed to disable regulator\n");
- }
+ if (led->regulator)
+ regulator_disable(led->regulator);
return ret;
}
+
static int lm3692x_probe_dt(struct lm3692x_led *led)
{
struct fwnode_handle *child = NULL;
--
2.23.0.rc1
[PATCH 4/5] leds: lm3692x: Use flags from LM3692X_BOOST_CTRL
The current setup of LM3692X_BOOST_CTRL uses flags from LM3692X_BRT_CTRL. Use flags from LM3692X_BOOST_CTRL but leave the resulting register value unchanged. Signed-off-by: Guido Günther --- drivers/leds/leds-lm3692x.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/leds/leds-lm3692x.c b/drivers/leds/leds-lm3692x.c index 9972c932d51e..d673f706385e 100644 --- a/drivers/leds/leds-lm3692x.c +++ b/drivers/leds/leds-lm3692x.c @@ -250,9 +250,9 @@ static int lm3692x_init(struct lm3692x_led *led) goto out; ret = regmap_write(led->regmap, LM3692X_BOOST_CTRL, - LM3692X_BRHT_MODE_RAMP_MULTI | - LM3692X_BL_ADJ_POL | - LM3692X_RAMP_RATE_250us); + LM3692X_BOOST_SW_1MHZ | + LM3692X_BOOST_SW_NO_SHIFT | + LM3692X_OCP_PROT_1_5A); if (ret) goto out; -- 2.23.0.rc1
[PATCH 0/5] leds: lm3692x: Probing and flag fixes
The driver currently returns success on init although probing fails and register setup uses flag values from other registers which is confusing when reading the driver. This series cleans this up. Guido Günther (5): leds: lm3692x: Print error value on dev_err leds: lm3692x: Don't overwrite return value in error path leds: lm3692x: Handle failure to probe the regulator leds: lm3692x: Use flags from LM3692X_BOOST_CTRL leds: lm3692x: Use flags from LM3692X_BRT_CTRL drivers/leds/leds-lm3692x.c | 45 - 1 file changed, 25 insertions(+), 20 deletions(-) -- 2.23.0.rc1
[PATCH 3/5] leds: lm3692x: Handle failure to probe the regulator
Instead use devm_regulator_get_optional since the regulator
is optional and check for errors.
Signed-off-by: Guido Günther
---
drivers/leds/leds-lm3692x.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/leds/leds-lm3692x.c b/drivers/leds/leds-lm3692x.c
index f394669ad8f2..9972c932d51e 100644
--- a/drivers/leds/leds-lm3692x.c
+++ b/drivers/leds/leds-lm3692x.c
@@ -333,9 +333,14 @@ static int lm3692x_probe_dt(struct lm3692x_led *led)
return ret;
}
- led->regulator = devm_regulator_get(>client->dev, "vled");
- if (IS_ERR(led->regulator))
- led->regulator = NULL;
+ led->regulator = devm_regulator_get_optional(>client->dev, "vled");
+ if (IS_ERR(led->regulator)) {
+ ret = PTR_ERR(led->regulator);
+ if (ret != -EPROBE_DEFER)
+ dev_err(>client->dev,
+ "Failed to get vled regulator: %d\n", ret);
+ return ret;
+ }
child = device_get_next_child_node(>client->dev, child);
if (!child) {
--
2.23.0.rc1
[PATCH 1/5] leds: lm3692x: Print error value on dev_err
This gives a way better idea what is going on.
Signed-off-by: Guido Günther
---
drivers/leds/leds-lm3692x.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/leds/leds-lm3692x.c b/drivers/leds/leds-lm3692x.c
index 3d381f2f73d0..487228c2bed2 100644
--- a/drivers/leds/leds-lm3692x.c
+++ b/drivers/leds/leds-lm3692x.c
@@ -174,19 +174,20 @@ static int lm3692x_brightness_set(struct led_classdev
*led_cdev,
ret = lm3692x_fault_check(led);
if (ret) {
- dev_err(>client->dev, "Cannot read/clear faults\n");
+ dev_err(>client->dev, "Cannot read/clear faults: %d\n",
+ ret);
goto out;
}
ret = regmap_write(led->regmap, LM3692X_BRT_MSB, brt_val);
if (ret) {
- dev_err(>client->dev, "Cannot write MSB\n");
+ dev_err(>client->dev, "Cannot write MSB: %d\n", ret);
goto out;
}
ret = regmap_write(led->regmap, LM3692X_BRT_LSB, led_brightness_lsb);
if (ret) {
- dev_err(>client->dev, "Cannot write LSB\n");
+ dev_err(>client->dev, "Cannot write LSB: %d\n", ret);
goto out;
}
out:
@@ -203,7 +204,7 @@ static int lm3692x_init(struct lm3692x_led *led)
ret = regulator_enable(led->regulator);
if (ret) {
dev_err(>client->dev,
- "Failed to enable regulator\n");
+ "Failed to enable regulator: %d\n", ret);
return ret;
}
}
@@ -213,7 +214,8 @@ static int lm3692x_init(struct lm3692x_led *led)
ret = lm3692x_fault_check(led);
if (ret) {
- dev_err(>client->dev, "Cannot read/clear faults\n");
+ dev_err(>client->dev, "Cannot read/clear faults: %d\n",
+ ret);
goto out;
}
@@ -409,7 +411,8 @@ static int lm3692x_remove(struct i2c_client *client)
ret = regmap_update_bits(led->regmap, LM3692X_EN, LM3692X_DEVICE_EN, 0);
if (ret) {
- dev_err(>client->dev, "Failed to disable regulator\n");
+ dev_err(>client->dev, "Failed to disable regulator: %d\n",
+ ret);
return ret;
}
@@ -420,7 +423,7 @@ static int lm3692x_remove(struct i2c_client *client)
ret = regulator_disable(led->regulator);
if (ret)
dev_err(>client->dev,
- "Failed to disable regulator\n");
+ "Failed to disable regulator: %d\n", ret);
}
mutex_destroy(>lock);
--
2.23.0.rc1
Re: [GIT PULL] dmaengine updates for v5.4-rc1
The pull request you sent on Tue, 17 Sep 2019 15:02:29 +0530: > git://git.infradead.org/users/vkoul/slave-dma.git tags/dmaengine-5.4-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/04cbfba6208592999d7bfe6609ec01dc3fde73f5 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] LED updates for 5.4-rc1
The pull request you sent on Tue, 17 Sep 2019 00:21:33 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git > tags/leds-for-5.4-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/4feaab05dc1eda3dbb57b097377766002e7a7cb9 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL for v5.4-rc1] media updates
The pull request you sent on Mon, 16 Sep 2019 09:25:15 -0300: > git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media media/v5.4-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e7345f92c27af003f219ad026d0e629a50b41e5c Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [Lkcamp] [PATCH v2] media: vimc: fla: Add virtual flash subdevice
Hi Lucas!
How are you?
I just have one comment about the strobe thread. Please check it below.
On Sun, Sep 15, 2019 at 3:44 PM Lucas A. M. Magalhães wrote:
>
> From: Lucas A. M. Magalhaes
>
> Add a virtual subdevice to simulate the flash control API.
> Those are the supported controls:
> v4l2-ctl -d /dev/v4l-subdev6 -L
> Flash Controls
>
>led_mode 0x009c0901 (menu) : min=0 max=2 default=0
> value=0
> 0: Off
> 1: Flash
> 2: Torch
> strobe_source 0x009c0902 (menu) : min=0 max=1 default=0
> value=0
> 0: Software
> 1: External
> strobe 0x009c0903 (button) : flags=write-only,
> execute-on-write
> stop_strobe 0x009c0904 (button) : flags=write-only,
> execute-on-write
> strobe_status 0x009c0905 (bool) : default=0 value=0
> flags=read-only
> strobe_timeout 0x009c0906 (int): min=1 max=10 step=1
> default=10 value=10
>intensity_flash_mode 0x009c0907 (int): min=0 max=255 step=1
> default=255 value=255
>intensity_torch_mode 0x009c0908 (int): min=0 max=255 step=1
> default=255 value=255
> intensity_indicator 0x009c0909 (int): min=0 max=255 step=1
> default=255 value=255
> faults 0x009c090a (bitmask): max=0x0002
> default=0x value=0x
>
> Co-authored-by: Eduardo Barretto
> Signed-off-by: Eduardo Barretto
> Signed-off-by: Lucas A. M. Magalhães
>
> ---
> Hi,
>
> This patch depends on the patch series
> "Collapse vimc into single monolithic driver" version 4.
>
> Changes in v2:
> - Fix v4l2-complience errors
> - Add V4L2_CID_FLASH_STROBE_STATUS behavior
> - Add V4L2_CID_FLASH_STROBE restrictions
> - Remove vimc_fla_g_volatile_ctrl
> - Remove unnecessarie V4L2_CID_FLASH_CLASS
> - Change varables names
> - Changes to apply over v4 of patch
> "Collapse vimc into single monolithic driver"
> ---
> drivers/media/platform/vimc/Makefile | 2 +-
> drivers/media/platform/vimc/vimc-common.c | 2 +
> drivers/media/platform/vimc/vimc-common.h | 4 +
> drivers/media/platform/vimc/vimc-core.c | 5 +
> drivers/media/platform/vimc/vimc-flash.c | 200 ++
> 5 files changed, 212 insertions(+), 1 deletion(-)
> create mode 100644 drivers/media/platform/vimc/vimc-flash.c
>
> diff --git a/drivers/media/platform/vimc/Makefile
> b/drivers/media/platform/vimc/Makefile
> index a53b2b532e9f..e759bbb04b14 100644
> --- a/drivers/media/platform/vimc/Makefile
> +++ b/drivers/media/platform/vimc/Makefile
> @@ -1,6 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
> vimc-y := vimc-core.o vimc-common.o vimc-streamer.o vimc-capture.o \
> - vimc-debayer.o vimc-scaler.o vimc-sensor.o
> + vimc-debayer.o vimc-scaler.o vimc-sensor.o vimc-flash.o
>
> obj-$(CONFIG_VIDEO_VIMC) += vimc.o
>
> diff --git a/drivers/media/platform/vimc/vimc-common.c
> b/drivers/media/platform/vimc/vimc-common.c
> index a3120f4f7a90..cb786de75573 100644
> --- a/drivers/media/platform/vimc/vimc-common.c
> +++ b/drivers/media/platform/vimc/vimc-common.c
> @@ -203,6 +203,8 @@ struct media_pad *vimc_pads_init(u16 num_pads, const
> unsigned long *pads_flag)
> struct media_pad *pads;
> unsigned int i;
>
> + if (!num_pads)
> + return NULL;
> /* Allocate memory for the pads */
> pads = kcalloc(num_pads, sizeof(*pads), GFP_KERNEL);
> if (!pads)
> diff --git a/drivers/media/platform/vimc/vimc-common.h
> b/drivers/media/platform/vimc/vimc-common.h
> index 236412ad7548..a1fbbc8066d3 100644
> --- a/drivers/media/platform/vimc/vimc-common.h
> +++ b/drivers/media/platform/vimc/vimc-common.h
> @@ -169,6 +169,10 @@ struct vimc_ent_device *vimc_sen_add(struct vimc_device
> *vimc,
> const char *vcfg_name);
> void vimc_sen_rm(struct vimc_device *vimc, struct vimc_ent_device *ved);
>
> +struct vimc_ent_device *vimc_fla_add(struct vimc_device *vimc,
> +const char *vcfg_name);
> +void vimc_fla_rm(struct vimc_device *vimc, struct vimc_ent_device *ved);
> +
> /**
> * vimc_pads_init - initialize pads
> *
> diff --git a/drivers/media/platform/vimc/vimc-core.c
> b/drivers/media/platform/vimc/vimc-core.c
> index a1218578cb9a..312723b4ed8a 100644
> --- a/drivers/media/platform/vimc/vimc-core.c
> +++ b/drivers/media/platform/vimc/vimc-core.c
> @@ -91,6 +91,11 @@ static struct vimc_ent_config ent_config[] = {
> .add = vimc_cap_add,
> .rm = vimc_cap_rm,
> },
> + {
> + .name = "Flash Controller",
> + .add = vimc_fla_add,
> + .rm = vimc_fla_rm,
> + }
>
Re: printk meeting at LPC
On Wed, 18 Sep 2019 10:25:46 +0900 Sergey Senozhatsky wrote: > On (09/13/19 15:26), John Ogness wrote: > > 2. A kernel thread will be created for each registered console, each > > responsible for being the sole printers to their respective > > consoles. With this, console printing is _fully_ decoupled from printk() > > callers. > > sysrq over serial? > > What we currently have is hacky, but, as usual, is a "best effort": > > >> serial driver IRQ > > serial_handle_irq() [console driver] >uart_handle_sysrq_char() > handle_sysrq() > printk() > call_console_drivers() >serial_write() [re-enter console driver] > > offloading this to kthread may be unreliable. But we also talked about an "emergency flush" which will not wait for the kthreads to finish and just output everything it can find in the printk buffers (expecting that the consoles have an "emergency" handler. We can add a sysrq to do an emergency flush. -- Steve
[PATCH] reset: build simple reset controller driver for Agilex
The Intel SoCFPGA Agilex platform shares the same reset controller that is on the Stratix10. Signed-off-by: Dinh Nguyen --- drivers/reset/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index 21efb7d39d62..280e69fbf86d 100644 --- a/drivers/reset/Kconfig +++ b/drivers/reset/Kconfig @@ -118,7 +118,7 @@ config RESET_QCOM_PDC config RESET_SIMPLE bool "Simple Reset Controller Driver" if COMPILE_TEST - default ARCH_STM32 || ARCH_STRATIX10 || ARCH_SUNXI || ARCH_ZX || ARCH_ASPEED || ARCH_BITMAIN + default ARCH_STM32 || ARCH_STRATIX10 || ARCH_SUNXI || ARCH_ZX || ARCH_ASPEED || ARCH_BITMAIN || ARCH_AGILEX help This enables a simple reset controller driver for reset lines that that can be asserted and deasserted by toggling bits in a contiguous, -- 2.20.0
Re: [GIT PULL] LED updates for 5.4-rc1
On Tue, Sep 17, 2019 at 6:14 PM Linus Torvalds
wrote:
>
> Famous last words. I now get a new warning:
>
> drivers/i2c/i2c-core-acpi.c:347:12: warning:
> ‘i2c_acpi_find_match_adapter’ defined but not used [-Wunused-function]
Commit 00500147cbd3 ("drivers: Introduce device lookup variants by
ACPI_COMPANION device") removed the use of that matching function, but
didn't remove the function.
It also removed the use of i2c_acpi_find_match_device(), but in that
case it _did_ remove the function.
And apparently nobody bothers checking warnings. Tssk tssk.
Linus
[PATCH 2/2] clk: socfpga: agilex: add clock driver for the Agilex platform
For the most part the Agilex clock structure is very similar to
Stratix10, so we re-use most of the Stratix10 clock driver.
Signed-off-by: Dinh Nguyen
---
drivers/clk/Makefile| 1 +
drivers/clk/socfpga/Makefile| 2 +
drivers/clk/socfpga/clk-agilex.c| 332
drivers/clk/socfpga/clk-pll-s10.c | 70 ++
drivers/clk/socfpga/stratix10-clk.h | 3 +
5 files changed, 408 insertions(+)
create mode 100644 drivers/clk/socfpga/clk-agilex.c
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 0cad76021297..ef2c96c0f1e0 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -18,6 +18,7 @@ endif
# hardware specific clock types
# please keep this section sorted lexicographically by file path name
+obj-$(CONFIG_ARCH_AGILEX) += socfpga/
obj-$(CONFIG_MACH_ASM9260) += clk-asm9260.o
obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN)+= clk-axi-clkgen.o
obj-$(CONFIG_ARCH_AXXIA) += clk-axm5516.o
diff --git a/drivers/clk/socfpga/Makefile b/drivers/clk/socfpga/Makefile
index ce5aa7802eb8..bf736f8d201a 100644
--- a/drivers/clk/socfpga/Makefile
+++ b/drivers/clk/socfpga/Makefile
@@ -3,3 +3,5 @@ obj-$(CONFIG_ARCH_SOCFPGA) += clk.o clk-gate.o clk-pll.o
clk-periph.o
obj-$(CONFIG_ARCH_SOCFPGA) += clk-pll-a10.o clk-periph-a10.o clk-gate-a10.o
obj-$(CONFIG_ARCH_STRATIX10) += clk-s10.o
obj-$(CONFIG_ARCH_STRATIX10) += clk-pll-s10.o clk-periph-s10.o clk-gate-s10.o
+obj-$(CONFIG_ARCH_AGILEX) += clk-agilex.o
+obj-$(CONFIG_ARCH_AGILEX) += clk-pll-s10.o clk-periph-s10.o clk-gate-s10.o
diff --git a/drivers/clk/socfpga/clk-agilex.c b/drivers/clk/socfpga/clk-agilex.c
new file mode 100644
index ..7d5093f0b2c9
--- /dev/null
+++ b/drivers/clk/socfpga/clk-agilex.c
@@ -0,0 +1,332 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019, Intel Corporation
+ */
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "stratix10-clk.h"
+
+static const char * const pll_mux[] = { "osc1", "cb-intosc-hs-div2-clk",
+ "f2s-free-clk",};
+static const char * const cntr_mux[] = { "main_pll", "periph_pll",
+"osc1", "cb-intosc-hs-div2-clk",
+"f2s-free-clk"};
+static const char * const boot_mux[] = { "osc1", "cb-intosc-hs-div2-clk",};
+
+static const char * const mpu_free_mux[] = {"main_pll_c0", "peri_pll_c0",
+ "osc1", "cb-intosc-hs-div2-clk",
+ "f2s-free-clk"};
+
+static const char * const noc_free_mux[] = {"main_pll_c1", "peri_pll_c1",
+ "osc1", "cb-intosc-hs-div2-clk",
+ "f2s-free-clk"};
+
+static const char * const emaca_free_mux[] = {"main_pll_c2", "peri_pll_c2",
+ "osc1", "cb-intosc-hs-div2-clk",
+ "f2s-free-clk"};
+static const char * const emacb_free_mux[] = {"main_pll_c3", "peri_pll_c3",
+ "osc1", "cb-intosc-hs-div2-clk",
+ "f2s-free-clk"};
+static const char * const emac_ptp_free_mux[] = {"main_pll_c3", "peri_pll_c3",
+ "osc1", "cb-intosc-hs-div2-clk",
+ "f2s-free-clk"};
+static const char * const gpio_db_free_mux[] = {"main_pll_c3", "peri_pll_c3",
+ "osc1", "cb-intosc-hs-div2-clk",
+ "f2s-free-clk"};
+static const char * const psi_ref_free_mux[] = {"main_pll_c3", "peri_pll_c3",
+ "osc1", "cb-intosc-hs-div2-clk",
+ "f2s-free-clk"};
+static const char * const sdmmc_free_mux[] = {"main_pll_c3", "peri_pll_c3",
+ "osc1", "cb-intosc-hs-div2-clk",
+ "f2s-free-clk"};
+static const char * const s2f_usr0_free_mux[] = {"main_pll_c2", "peri_pll_c2",
+"osc1",
"cb-intosc-hs-div2-clk",
+"f2s-free-clk"};
+static const char * const s2f_usr1_free_mux[] = {"main_pll_c2", "peri_pll_c2",
+"osc1",
"cb-intosc-hs-div2-clk",
+"f2s-free-clk"};
+static const char * const mpu_mux[] = { "mpu_free_clk", "boot_clk",};
+
+static const char * const s2f_usr0_mux[] = {"f2s-free-clk", "boot_clk"};
+static const char * const emac_mux[] = {"emaca_free_clk", "emacb_free_clk"};
+static const char * const noc_mux[] = {"noc_free_clk", "boot_clk"};
+
+/* clocks in AO (always on) controller */
+static const struct stratix10_pll_clock
[PATCH 1/2] dt-bindings: documentation: add clock bindings information for Agilex
From: Dinh Nguyen
Document the Agilex clock bindings, and add the clock header file. The
clock header is an enumeration of all the different clocks on the Agilex
platform.
Signed-off-by: Dinh Nguyen
---
.../devicetree/bindings/clock/intc_agilex.txt | 20 ++
include/dt-bindings/clock/agilex-clock.h | 70 +++
2 files changed, 90 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/intc_agilex.txt
create mode 100644 include/dt-bindings/clock/agilex-clock.h
diff --git a/Documentation/devicetree/bindings/clock/intc_agilex.txt
b/Documentation/devicetree/bindings/clock/intc_agilex.txt
new file mode 100644
index ..bfec71420511
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/intc_agilex.txt
@@ -0,0 +1,20 @@
+Device Tree Clock bindings for Intel's SoCFPGA Agilex platform
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be
+ "intel,agilex-clkmgr"
+
+- reg : shall be the control register offset from CLOCK_MANAGER's base for the
clock.
+
+- #clock-cells : from common clock binding, shall be set to 1.
+
+Example:
+ clkmgr: clock-controller@ffd1 {
+ compatible = "intel,agilex-clkmgr";
+ reg = <0xffd1 0x1000>;
+ #clock-cells = <1>;
+ };
diff --git a/include/dt-bindings/clock/agilex-clock.h
b/include/dt-bindings/clock/agilex-clock.h
new file mode 100644
index ..f19cf8ccbdd2
--- /dev/null
+++ b/include/dt-bindings/clock/agilex-clock.h
@@ -0,0 +1,70 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019, Intel Corporation
+ */
+
+#ifndef __AGILEX_CLOCK_H
+#define __AGILEX_CLOCK_H
+
+/* fixed rate clocks */
+#define AGILEX_OSC10
+#define AGILEX_CB_INTOSC_HS_DIV2_CLK 1
+#define AGILEX_CB_INTOSC_LS_CLK2
+#define AGILEX_L4_SYS_FREE_CLK 3
+#define AGILEX_F2S_FREE_CLK4
+
+/* PLL clocks */
+#define AGILEX_MAIN_PLL_CLK5
+#define AGILEX_MAIN_PLL_C0_CLK 6
+#define AGILEX_MAIN_PLL_C1_CLK 7
+#define AGILEX_MAIN_PLL_C2_CLK 8
+#define AGILEX_MAIN_PLL_C3_CLK 9
+#define AGILEX_PERIPH_PLL_CLK 10
+#define AGILEX_PERIPH_PLL_C0_CLK 11
+#define AGILEX_PERIPH_PLL_C1_CLK 12
+#define AGILEX_PERIPH_PLL_C2_CLK 13
+#define AGILEX_PERIPH_PLL_C3_CLK 14
+#define AGILEX_MPU_FREE_CLK15
+#define AGILEX_MPU_CCU_CLK 16
+#define AGILEX_BOOT_CLK17
+
+/* fixed factor clocks */
+#define AGILEX_L3_MAIN_FREE_CLK18
+#define AGILEX_NOC_FREE_CLK19
+#define AGILEX_S2F_USR0_CLK20
+#define AGILEX_NOC_CLK 21
+#define AGILEX_EMAC_A_FREE_CLK 22
+#define AGILEX_EMAC_B_FREE_CLK 23
+#define AGILEX_EMAC_PTP_FREE_CLK 24
+#define AGILEX_GPIO_DB_FREE_CLK25
+#define AGILEX_SDMMC_FREE_CLK 26
+#define AGILEX_S2F_USER0_FREE_CLK 27
+#define AGILEX_S2F_USER1_FREE_CLK 28
+#define AGILEX_PSI_REF_FREE_CLK29
+
+/* Gate clocks */
+#define AGILEX_MPU_CLK 30
+#define AGILEX_MPU_L2RAM_CLK 31
+#define AGILEX_MPU_PERIPH_CLK 32
+#define AGILEX_L4_MAIN_CLK 33
+#define AGILEX_L4_MP_CLK 34
+#define AGILEX_L4_SP_CLK 35
+#define AGILEX_CS_AT_CLK 36
+#define AGILEX_CS_TRACE_CLK37
+#define AGILEX_CS_PDBG_CLK 38
+#define AGILEX_CS_TIMER_CLK39
+#define AGILEX_S2F_USER0_CLK 40
+#define AGILEX_EMAC0_CLK 41
+#define AGILEX_EMAC1_CLK 43
+#define AGILEX_EMAC2_CLK 44
+#define AGILEX_EMAC_PTP_CLK45
+#define AGILEX_GPIO_DB_CLK 46
+#define AGILEX_NAND_CLK47
+#define AGILEX_PSI_REF_CLK 48
+#define AGILEX_S2F_USER1_CLK 49
+#define AGILEX_SDMMC_CLK 50
+#define AGILEX_SPI_M_CLK 51
+#define AGILEX_USB_CLK 52
+#define AGILEX_NUM_CLKS53
+
+#endif /* __AGILEX_CLOCK_H */
--
2.20.0
Re: [RESENT PATCH v2] ixgbe: Use memzero_explicit directly in crypto cases
On 2019/9/18 2:11, Jakub Kicinski wrote: > On Tue, 17 Sep 2019 22:44:22 +0800, zhong jiang wrote: >> It's better to use memzero_explicit() to replace memset() in crypto cases. >> >> Signed-off-by: zhong jiang > Thank you for the follow up! Your previous patch to use kzfree() > has been applied on its own merit, could you rebase this one on top > of current net-next/master? I will do that. Thanks, zhong jiang >> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c >> b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c >> index 31629fc..7e4f32f 100644 >> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c >> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c >> @@ -960,10 +960,10 @@ int ixgbe_ipsec_vf_add_sa(struct ixgbe_adapter >> *adapter, u32 *msgbuf, u32 vf) >> return 0; >> >> err_aead: >> -memset(xs->aead, 0, sizeof(*xs->aead)); >> +memzero_explicit(xs->aead, sizeof(*xs->aead)); >> kfree(xs->aead); >> err_xs: >> -memset(xs, 0, sizeof(*xs)); >> +memzero_explicit(xs, sizeof(*xs)); >> kfree(xs); >> err_out: >> msgbuf[1] = err; >> @@ -1049,7 +1049,7 @@ int ixgbe_ipsec_vf_del_sa(struct ixgbe_adapter >> *adapter, u32 *msgbuf, u32 vf) >> ixgbe_ipsec_del_sa(xs); >> >> /* remove the xs that was made-up in the add request */ >> -memset(xs, 0, sizeof(*xs)); >> +memzero_explicit(xs, sizeof(*xs)); >> kfree(xs); >> >> return 0; > > . >
Re: [RFC PATCH v3 00/16] Core scheduling v3
On Sun, Sep 15, 2019 at 10:14 PM Aaron Lu wrote: > > On Fri, Sep 13, 2019 at 07:12:52AM +0800, Aubrey Li wrote: > > On Thu, Sep 12, 2019 at 8:04 PM Aaron Lu wrote: > > > > > > On Wed, Sep 11, 2019 at 09:19:02AM -0700, Tim Chen wrote: > > > > On 9/11/19 7:02 AM, Aaron Lu wrote: > > > > I think Julien's result show that my patches did not do as well as > > > > your patches for fairness. Aubrey did some other testing with the same > > > > conclusion. So I think keeping the forced idle time balanced is not > > > > enough for maintaining fairness. > > > > > > Well, I have done following tests: > > > 1 Julien's test script: https://paste.debian.net/plainh/834cf45c > > > 2 start two tagged will-it-scale/page_fault1, see how each performs; > > > 3 Aubrey's mysql test: https://github.com/aubreyli/coresched_bench.git > > > > > > They all show your patchset performs equally well...And consider what > > > the patch does, I think they are really doing the same thing in > > > different ways. > > > > It looks like we are not on the same page, if you don't mind, can both of > > you rebase your patchset onto v5.3-rc8 and provide a public branch so I > > can fetch and test it at least by my benchmark? > > I'm using the following branch as base which is v5.1.5 based: > https://github.com/digitalocean/linux-coresched coresched-v3-v5.1.5-test > > And I have pushed Tim's branch to: > https://github.com/aaronlu/linux coresched-v3-v5.1.5-test-tim > > Mine: > https://github.com/aaronlu/linux coresched-v3-v5.1.5-test-core_vruntime > > The two branches both have two patches I have sent previouslly: > https://lore.kernel.org/lkml/20190810141556.GA73644@aaronlu/ > Although it has some potential performance loss as pointed out by > Vineeth, I haven't got time to rework it yet. In terms of these two branches, we tested two cases: 1) 32 AVX threads and 32 mysql threads on one core(2 HT) 2) 192 AVX threads and 192 mysql threads on 96 cores(192 HTs) For case 1), we saw two branches is on par Branch: coresched-v3-v5.1.5-test-core_vruntime -Avg throughput:: 1865.62 (std: 20.6%) -Avg latency: 26.43 (std: 8.3%) Branch: coresched-v3-v5.1.5-test-tim - Avg throughput: 1804.88 (std: 20.1%) - Avg latency: 29.78 (std: 11.8%) For case 2), we saw core vruntime performs better than counting forced idle time Branch: coresched-v3-v5.1.5-test-core_vruntime - Avg throughput: 5528.56 (std: 44.2%) - Avg latency: 165.99 (std: 45.2%) Branch: coresched-v3-v5.1.5-test-tim -Avg throughput:: 3842.33 (std: 35.1%) -Avg latency: 306.99 (std: 72.9%) As Aaron pointed out, vruntime is with se's weight, which could be a reason for the difference. So should we go with core vruntime approach? Or Tim - do you want to improve forced idle time approach? Thanks, -Aubrey
Re: Regression in fd5f7cde1b85 ("printk: Never set console_may_schedule in console_trylock()")
On (09/17/19 16:10), Uwe Kleine-König wrote:
> Hello,
>
> Today it saw sysrq on an UART driven by drivers/tty/serial/imx.c report
> a lockdep issue. Bisecting pointed to
>
> fd5f7cde1b85 ("printk: Never set console_may_schedule in
> console_trylock()")
Hmmm...
I don't see how this patch can affect anything. It simply
disables preemption in printk().
> When I type t I get:
>
> [ 87.940104] sysrq: SysRq : This sysrq operation is disabled.
> [ 87.948752]
> [ 87.948772] ==
> [ 87.948787] WARNING: possible circular locking dependency detected
> [ 87.948798] 4.14.0-12954-gfd5f7cde1b85 #26 Not tainted
> [ 87.948813] --
> [ 87.948822] swapper/0 is trying to acquire lock:
> [ 87.948829] (console_owner){-...}, at: []
> console_unlock+0x110/0x598
> [ 87.948861]
> [ 87.948869] but task is already holding lock:
> [ 87.948874] (_lock_key){-.-.}, at: [] imx_rxint+0x2c/0x290
> [ 87.948902]
> [ 87.948911] which lock already depends on the new lock.
> [ 87.948917]
> [ 87.948923]
> [ 87.948932] the existing dependency chain (in reverse order) is:
> [ 87.948938]
> [ 87.948943] -> #1 (_lock_key){-.-.}:
> [ 87.948975]_raw_spin_lock_irqsave+0x5c/0x70
> [ 87.948983]imx_console_write+0x138/0x15c
> [ 87.948991]console_unlock+0x204/0x598
> [ 87.949000]register_console+0x21c/0x3e8
> [ 87.949008]uart_add_one_port+0x3e4/0x4dc
> [ 87.949019]platform_drv_probe+0x3c/0x78
> [ 87.949027]driver_probe_device+0x25c/0x47c
> [ 87.949035]__driver_attach+0xec/0x114
> [ 87.949044]bus_for_each_dev+0x80/0xb0
> [ 87.949054]bus_add_driver+0x1d4/0x264
> [ 87.949062]driver_register+0x80/0xfc
> [ 87.949069]imx_serial_init+0x28/0x48
> [ 87.949078]do_one_initcall+0x44/0x18c
> [ 87.949087]kernel_init_freeable+0x11c/0x1cc
> [ 87.949095]kernel_init+0x10/0x114
> [ 87.949103]ret_from_fork+0x14/0x30
This is "normal" locking path
console_sem -> port->lock
printk()
lock console_sem
imx_console_write()
lock port->lock
> [ 87.949113] -> #0 (console_owner){-...}:
> [ 87.949145]lock_acquire+0x100/0x23c
> [ 87.949154]console_unlock+0x1a4/0x598
> [ 87.949162]vprintk_emit+0x1a4/0x45c
> [ 87.949171]vprintk_default+0x28/0x30
> [ 87.949180]printk+0x28/0x38
> [ 87.949189]__handle_sysrq+0x1c4/0x244
> [ 87.949196]imx_rxint+0x258/0x290
> [ 87.949206]imx_int+0x170/0x178
> [ 87.949216]__handle_irq_event_percpu+0x78/0x418
> [ 87.949225]handle_irq_event_percpu+0x24/0x6c
> [ 87.949233]handle_irq_event+0x40/0x64
> [ 87.949242]handle_level_irq+0xb4/0x138
> [ 87.949252]generic_handle_irq+0x28/0x3c
> [ 87.949261]__handle_domain_irq+0x50/0xb0
> [ 87.949269]avic_handle_irq+0x3c/0x5c
> [ 87.949277]__irq_svc+0x6c/0xa4
> [ 87.949287]arch_cpu_idle+0x30/0x40
> [ 87.949297]arch_cpu_idle+0x30/0x40
> [ 87.949305]do_idle+0xa0/0x104
> [ 87.949313]cpu_startup_entry+0x14/0x18
> [ 87.949323]start_kernel+0x30c/0x368
This one is a "reverse" locking path...
port->lock -> console_sem
There is more to it:
imxint()
lock port->lock
uart_handle_sysrq_char()
handle_sysrq()
printk()
lock conosole_sem
imx_console_write()
lock port->lock [boom]
This path re-enters serial driver. But it doesn't deadlock, because
uart_handle_sysrq_char() sets a special flag port->sysrq, and serial
consoles are expected to make sure that they don't lock port->lock
in this case. Otherwise we will kill the system:
void serial_console_write(...)
{
...
if (sport->port.sysrq)
locked = 0;
else if (oops_in_progress)
locked = spin_trylock_irqsave(>port.lock, flags);
else
spin_lock_irqsave(>port.lock, flags);
...
}
So I'd say that lockdep is correct, but there are several hacks which
prevent actual deadlock.
No idea why bisection has pointed at fd5f7cde1b85, it really doesn't
change the locking patterns.
-ss
Re: printk meeting at LPC
On (09/13/19 15:26), John Ogness wrote: > 2. A kernel thread will be created for each registered console, each > responsible for being the sole printers to their respective > consoles. With this, console printing is _fully_ decoupled from printk() > callers. sysrq over serial? What we currently have is hacky, but, as usual, is a "best effort": >> serial driver IRQ serial_handle_irq() [console driver] uart_handle_sysrq_char() handle_sysrq() printk() call_console_drivers() serial_write() [re-enter console driver] offloading this to kthread may be unreliable. -ss
Re: [PATCH] ethernet/intel: release the local packet buffer
Hi Navid,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING 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]
url:
https://github.com/0day-ci/linux/commits/Navid-Emamdoost/ethernet-intel-release-the-local-packet-buffer/20190918-080148
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-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=sparc64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
In file included from include/linux/if_ether.h:19:0,
from include/uapi/linux/ethtool.h:19,
from include/linux/ethtool.h:18,
from include/linux/netdevice.h:37,
from drivers/net/ethernet/intel/e100.c:140:
drivers/net/ethernet/intel/e100.c: In function 'e100_loopback_test':
>> include/linux/skbuff.h:1149:26: warning: 'skb' may be used uninitialized in
>> this function [-Wmaybe-uninitialized]
#define dev_kfree_skb(a) consume_skb(a)
^~~
drivers/net/ethernet/intel/e100.c:2347:18: note: 'skb' was declared here
struct sk_buff *skb;
^~~
--
In file included from include/linux/if_ether.h:19:0,
from include/uapi/linux/ethtool.h:19,
from include/linux/ethtool.h:18,
from include/linux/netdevice.h:37,
from drivers/net//ethernet/intel/e100.c:140:
drivers/net//ethernet/intel/e100.c: In function 'e100_loopback_test':
>> include/linux/skbuff.h:1149:26: warning: 'skb' may be used uninitialized in
>> this function [-Wmaybe-uninitialized]
#define dev_kfree_skb(a) consume_skb(a)
^~~
drivers/net//ethernet/intel/e100.c:2347:18: note: 'skb' was declared here
struct sk_buff *skb;
^~~
vim +/skb +1149 include/linux/skbuff.h
cd0a137acbb662 Florian Fainelli 2017-08-22 1133
cd0a137acbb662 Florian Fainelli 2017-08-22 1134 /**
cd0a137acbb662 Florian Fainelli 2017-08-22 1135 *skb_pad
- zero pad the tail of an skb
cd0a137acbb662 Florian Fainelli 2017-08-22 1136 *@skb: buffer to pad
cd0a137acbb662 Florian Fainelli 2017-08-22 1137 *@pad: space to pad
cd0a137acbb662 Florian Fainelli 2017-08-22 1138 *
cd0a137acbb662 Florian Fainelli 2017-08-22 1139 *Ensure that a buffer is
followed by a padding area that is zero
cd0a137acbb662 Florian Fainelli 2017-08-22 1140 *filled. Used by network
drivers which may DMA or transfer data
cd0a137acbb662 Florian Fainelli 2017-08-22 1141 *beyond the buffer end
onto the wire.
cd0a137acbb662 Florian Fainelli 2017-08-22 1142 *
cd0a137acbb662 Florian Fainelli 2017-08-22 1143 *May return error in out
of memory cases. The skb is freed on error.
cd0a137acbb662 Florian Fainelli 2017-08-22 1144 */
cd0a137acbb662 Florian Fainelli 2017-08-22 1145 static inline int
skb_pad(struct sk_buff *skb, int pad)
cd0a137acbb662 Florian Fainelli 2017-08-22 1146 {
cd0a137acbb662 Florian Fainelli 2017-08-22 1147return __skb_pad(skb,
pad, true);
cd0a137acbb662 Florian Fainelli 2017-08-22 1148 }
ead2ceb0ec9f85 Neil Horman 2009-03-11 @1149 #define dev_kfree_skb(a)
consume_skb(a)
^1da177e4c3f41 Linus Torvalds 2005-04-16 1150
:: The code at line 1149 was first introduced by commit
:: ead2ceb0ec9f85cff19c43b5cdb2f8a054484431 Network Drop Monitor: Adding
kfree_skb_clean for non-drops and modifying end-of-line points for skbs
:: TO: Neil Horman
:: CC: David S. Miller
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
