Re: [PATCH 4.19 00/39] 4.19.163-rc1 review
On Thu, 10 Dec 2020 at 20:05, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.19.163 release. > There are 39 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat, 12 Dec 2020 14:25:47 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.163-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.19.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 4.19.163-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.19.y git commit: a1b1c60de6b977bc1a2fc8176b647879030ab862 git describe: v4.19.162-41-ga1b1c60de6b9 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.162-41-ga1b1c60de6b9 No regressions (compared to build v4.19.162) No fixes (compared to build v4.19.162) Ran 43756 total tests in the following environments and test suites. Environments -- - arm - arm64 - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - juno-r2-compat - juno-r2-kasan - mips - nxp-ls2088 - qemu-arm64-clang - qemu-arm64-kasan - qemu-x86_64-clang - qemu-x86_64-kasan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - s390 - sparc - x15 - arm - x86_64 - x86-kasan Test Suites --- * build * linux-log-parser * install-android-platform-tools-r2600 * libhugetlbfs * ltp-controllers-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-sched-tests * kselftest * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-ipc-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-tracing-tests * network-basic-tests * perf * v4l2-compliance * ltp-commands-tests * ltp-fs-tests * ltp-math-tests * ltp-open-posix-tests * kvm-unit-tests * rcutorture * fwts -- Linaro LKFT https://lkft.linaro.org
Re: [RFC 18/18] power: supply: max17040: Do not enforce (incorrect) interrupt trigger type
On Thu, Dec 10, 2020 at 11:16:00PM +0100, Sebastian Reichel wrote: > (I shortened the Cc) > > Hi, > > On Thu, Dec 10, 2020 at 10:25:34PM +0100, Krzysztof Kozlowski wrote: > > [...] > > index d956c67d5155..f737de0470de 100644 > > --- a/drivers/power/supply/max17040_battery.c > > +++ b/drivers/power/supply/max17040_battery.c > > @@ -367,7 +367,7 @@ static int max17040_enable_alert_irq(struct > > max17040_chip *chip) > > > > flags = IRQF_TRIGGER_FALLING | IRQF_ONESHOT; > > ret = devm_request_threaded_irq(>dev, client->irq, NULL, > > - max17040_thread_handler, flags, > > + max17040_thread_handler, IRQF_ONESHOT, > > chip->battery->desc->name, chip); > > > > return ret; > > 'flags' is unused after this change. Indeed, thanks. Kbuild also complained now on my github branch. I'll fix it in v2.
Re: [RFC 18/18] power: supply: max17040: Do not enforce (incorrect) interrupt trigger type
On Thu, Dec 10, 2020 at 10:25:34PM +0100, Krzysztof Kozlowski wrote: > Interrupt line can be configured on different hardware in different way, > even inverted. Therefore driver should not enforce specific trigger > type - edge falling - but instead rely on Devicetree to configure it. > > The Maxim 14577/77836 datasheets describe the interrupt line as active > low with a requirement of acknowledge from the CPU therefore the edge > falling is not correct. > > Signed-off-by: Krzysztof Kozlowski > > --- > > This patch should wait till DTS changes are merged, as it relies on > proper Devicetree. > --- > .../devicetree/bindings/power/supply/max17040_battery.txt | 2 +- > drivers/power/supply/max17040_battery.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/power/supply/max17040_battery.txt > b/Documentation/devicetree/bindings/power/supply/max17040_battery.txt > index c802f664b508..194eb9fe574d 100644 > --- a/Documentation/devicetree/bindings/power/supply/max17040_battery.txt > +++ b/Documentation/devicetree/bindings/power/supply/max17040_battery.txt > @@ -39,7 +39,7 @@ Example: > reg = <0x36>; > maxim,alert-low-soc-level = <10>; > interrupt-parent = <>; > - interrupts = <2 IRQ_TYPE_EDGE_FALLING>; > + interrupts = <2 IRQ_TYPE_LEVEL_LOW>; > wakeup-source; > }; > > diff --git a/drivers/power/supply/max17040_battery.c > b/drivers/power/supply/max17040_battery.c > index d956c67d5155..f737de0470de 100644 > --- a/drivers/power/supply/max17040_battery.c > +++ b/drivers/power/supply/max17040_battery.c > @@ -367,7 +367,7 @@ static int max17040_enable_alert_irq(struct max17040_chip > *chip) > > flags = IRQF_TRIGGER_FALLING | IRQF_ONESHOT; This has to be removed. I will fix it in v2. Best regards, Krzysztof > ret = devm_request_threaded_irq(>dev, client->irq, NULL, > - max17040_thread_handler, flags, > + max17040_thread_handler, IRQF_ONESHOT, > chip->battery->desc->name, chip); > > return ret; > -- > 2.25.1 >
Re: [PATCH] x86/apic/vector: Fix ordering in vector assignment
On Thu, Dec 10, 2020 at 09:18:22PM +0100, Thomas Gleixner wrote:
> Prarit reported that depending on the affinity setting the
>
> ' irq $N: Affinity broken due to vector space exhaustion.'
>
> message is showing up in dmesg, but the vector space on the CPUs in the
> affinity mask is definitely not exhausted.
>
> Shung-Hsi provided traces and analysis which pinpoints the problem:
>
> The ordering of trying to assign an interrupt vector in
> assign_irq_vector_any_locked() is simply wrong if the interrupt data has a
> valid node assigned. It does:
>
> 1) Try the intersection of affinity mask and node mask
> 2) Try the node mask
> 3) Try the full affinity mask
> 4) Try the full online mask
>
> Obviously #2 and #3 are in the wrong order as the requested affinity
> mask has to take precedence.
>
> In the observed cases #1 failed because the affinity mask did not contain
> CPUs from node 0. That made it allocate a vector from node 0, thereby
> breaking affinity and emitting the misleading message.
>
> Revert the order of #2 and #3 so the full affinity mask without the node
> intersection is tried before actually affinity is broken.
>
> If no node is assigned then only the full affinity mask and if that fails
> the full online mask is tried.
>
> Fixes: d6ffc6ac83b1 ("x86/vector: Respect affinity mask in irq descriptor")
> Reported-by: Shung-Hsi Yu
> Reported-by: Prarit Bhargava
> Signed-off-by: Thomas Gleixner
> Tested-by: Shung-Hsi Yu
> Cc: sta...@vger.kernel.org
> ---
> arch/x86/kernel/apic/vector.c | 24 ++--
> 1 file changed, 14 insertions(+), 10 deletions(-)
>
> --- a/arch/x86/kernel/apic/vector.c
> +++ b/arch/x86/kernel/apic/vector.c
> @@ -273,20 +273,24 @@ static int assign_irq_vector_any_locked(
> const struct cpumask *affmsk = irq_data_get_affinity_mask(irqd);
> int node = irq_data_get_node(irqd);
>
> - if (node == NUMA_NO_NODE)
> - goto all;
> - /* Try the intersection of @affmsk and node mask */
> - cpumask_and(vector_searchmask, cpumask_of_node(node), affmsk);
> - if (!assign_vector_locked(irqd, vector_searchmask))
> - return 0;
> - /* Try the node mask */
> - if (!assign_vector_locked(irqd, cpumask_of_node(node)))
> - return 0;
> -all:
> + if (node != NUMA_NO_NODE) {
> + /* Try the intersection of @affmsk and node mask */
> + cpumask_and(vector_searchmask, cpumask_of_node(node), affmsk);
> + if (!assign_vector_locked(irqd, vector_searchmask))
> + return 0;
> + }
> +
> /* Try the full affinity mask */
> cpumask_and(vector_searchmask, affmsk, cpu_online_mask);
> if (!assign_vector_locked(irqd, vector_searchmask))
> return 0;
> +
> + if (node != NUMA_NO_NODE) {
> + /* Try the node mask */
> + if (!assign_vector_locked(irqd, cpumask_of_node(node)))
> + return 0;
> + }
> +
> /* Try the full online mask */
> return assign_vector_locked(irqd, cpu_online_mask);
> }
>
Reviewed-by: Ming Lei
Thanks,
Ming
Re: [PATCH v17 3/3] bus: mhi: Add userspace client interface driver
On Thu, Dec 10, 2020 at 11:04:11PM -0800, Hemant Kumar wrote: > This MHI client driver allows userspace clients to transfer > raw data between MHI device and host using standard file operations. > Driver instantiates UCI device object which is associated to device > file node. UCI device object instantiates UCI channel object when device > file node is opened. UCI channel object is used to manage MHI channels > by calling MHI core APIs for read and write operations. MHI channels > are started as part of device open(). MHI channels remain in start > state until last release() is called on UCI device file node. Device > file node is created with format > > /dev/ > > Currently it supports QMI channel. libqmi is userspace MHI client which > communicates to a QMI service using QMI channel. libqmi is a glib-based > library for talking to WWAN modems and devices which speaks QMI protocol. > For more information about libqmi please refer > https://www.freedesktop.org/wiki/Software/libqmi/ This says _what_ this is doing, but not _why_. Why do you want to circumvent the normal user/kernel apis for this type of device and move the normal network handling logic out to userspace? What does that help with? What does the current in-kernel api lack that this userspace interface is going to solve, and why can't the in-kernel api solve it instead? You are pushing a common user/kernel api out of the kernel here, to become very device-specific, with no apparent justification as to why this is happening. Also, because you are going around the existing network api, I will need the networking maintainers to ack this type of patch. thanks, greg k-h
[GIT PULL] devfreq next for v5.11
Dear Rafael, This is devfreq-next pull request for v5.11-rc1. I add detailed description of this pull request on the following tag. Please pull devfreq with following updates. - tag name : devfreq-next-for-5.11 Best Regards, Chanwoo Choi The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec: Linux 5.10-rc1 (2020-10-25 15:14:11 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git tags/devfreq-next-for-5.11 for you to fetch changes up to 6a575e84f11e15078629f0d16bff2bc354a6bfc0: PM / devfreq: tegra30: Separate configurations per-SoC generation (2020-12-07 10:25:51 +0900) Update devfreq for 5.11 Detailed description for this pull request: 1. Update devfreq core - Add new devfreq_frequency tracepoint to show the frequency change information. - Add governor feature flag. The devfreq governor is able to have the specific flag in order to contain the non-common feature. For example, if governor contains the 'immutable' feature, don't allow user to change the governor via sysfs. - Add governor sysfs attribute flag for each sysfs file. Prior to that devfreq subsystem show the all sysfs files regardless of governor type. But, some sysfs fils are not supported on the specific devfreq governor. In order to show the only supported sysfs files according to the governor, clarify the access permission of sysfs attributes according to governor. When adding the devfreq governor, can specify the available attribute information by using DEVFREQ_GOV_ATTR_* constant variable. The user can read or write the sysfs attributes in accordance to the specified attributes. - Clean-up the code to remove the duplicate code for the devfreq tracepoint and to remove redundant governor_name field from struct devfreq 2. Update exynos-bus.c devfreq driver - Add interconnect API support for the Samsung Exynos Bus Frequency driver of exynos-bus.c. Complementing the devfreq driver with an interconnect functionality allows to ensure the QoS requirements of devices accessing the system memory (e.g. video processing devices) are fulfilled and allows to avoid issues like the DMA underrun. 3. Update tegra devfreq driver - Add interconnect support and OPP interface for tegra30-devfreq.c. Also, it is to guarantee the QoS requirement of some devices like display controller. - Move tegra20-devfreq.c from drivers/devfreq/ into driver/memory/tegra/ in order to use the more proper monitoring feature such as EMC_STAT which is based in driver/memory/tegra/. - Separate the configuration information for different SoC on tegra30-devfrqe.c. The tegra30-devfreq.c had been supported both tegra30-actmon and tegra124-actmon devices. In order to use the more correct configuration data, separate them. - Use dev_err_probe() to handle the deferred probe error on tegra30-devfreq.c. 4. Pull the request of 'Tegra SoC and clock controller changes for v5.11' sent by Krzysztof Kozlowski in order to prevent the build error. Chanwoo Choi (6): trace: events: devfreq: Use fixed indentation size to improve readability PM / devfreq: Unify frequency change to devfreq_update_target func PM / devfreq: Add governor feature flag PM / devfreq: Add governor attribute flag for specifc sysfs nodes PM / devfreq: Remove redundant governor_name from struct devfreq Merge tag 'tegra-soc-clk-drivers-5.11' of https://git.kernel.org/.../krzk/linux-mem-ctrl into devfreq-next Dmitry Osipenko (9): PM / devfreq: tegra20: Silence deferred probe error PM / devfreq: tegra20: Relax Kconfig dependency PM / devfreq: tegra30: Silence deferred probe error clk: tegra: Export Tegra20 EMC kernel symbols soc/tegra: fuse: Export tegra_read_ram_code() soc/tegra: fuse: Add stub for tegra_sku_info PM / devfreq: tegra20: Deprecate in a favor of emc-stat based driver PM / devfreq: tegra30: Support interconnect and OPPs from device-tree PM / devfreq: tegra30: Separate configurations per-SoC generation Matthias Kaehlcke (1): PM / devfreq: Add tracepoint for frequency changes Sylwester Nawrocki (2): dt-bindings: devfreq: Add documentation for the interconnect properties PM / devfreq: exynos-bus: Add registration of interconnect child device Documentation/ABI/testing/sysfs-class-devfreq | 54 +++-- .../devicetree/bindings/devfreq/exynos-bus.txt | 71 +- MAINTAINERS| 1 - drivers/clk/tegra/clk-tegra20-emc.c| 3 + drivers/devfreq/Kconfig| 10 - drivers/devfreq/Makefile | 1 - drivers/devfreq/devfreq.c | 242 ++--- drivers/devfreq/exynos-bus.c | 17 ++ drivers/devfreq/governor.h
Re: [PATCH RESEND v8 4/4] input: elants: support 0x66 reply opcode for reporting touches
On Fri, Dec 11, 2020 at 07:53:57AM +0100, Michał Mirosław wrote:
> From: Dmitry Osipenko
>
> eKTF3624 touchscreen firmware uses two variants of the reply opcodes for
> reporting touch events: one is 0x63 (used by older firmware) and other is
> 0x66 (used by newer firmware). The 0x66 variant is equal to 0x63 of
> eKTH3500, while 0x63 needs small adjustment of the touch pressure value.
>
> Nexus 7 tablet device has eKTF3624 touchscreen and it uses 0x66 opcode for
> reporting touch events, let's support it now. Other devices, eg. ASUS TF300T,
> use 0x63.
>
> Note: CMD_HEADER_REK is used for replying to calibration requests, it has
> the same 0x66 opcode number which eKTF3624 uses for reporting touches.
> The calibration replies are handled separately from the the rest of the
> commands in the driver by entering into ELAN_WAIT_RECALIBRATION state
> and thus this change shouldn't change the old behavior.
>
> Signed-off-by: Dmitry Osipenko
> Tested-by: Michał Mirosław
> Signed-off-by: Michał Mirosław
> ---
> drivers/input/touchscreen/elants_i2c.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/elants_i2c.c
> b/drivers/input/touchscreen/elants_i2c.c
> index c24d8cdc4251..1cbda6f20d07 100644
> --- a/drivers/input/touchscreen/elants_i2c.c
> +++ b/drivers/input/touchscreen/elants_i2c.c
> @@ -61,6 +61,15 @@
> #define QUEUE_HEADER_NORMAL 0X63
> #define QUEUE_HEADER_WAIT0x64
>
> +/*
> + * Depending on firmware version, eKTF3624 touchscreens may utilize one of
> + * these opcodes for the touch events: 0x63 and 0x66. The 0x63 is used by
> + * older firmware version and differs from 0x66 such that touch pressure
> + * value needs to be adjusted. The 0x66 opcode of newer firmware is equal
> + * to 0x63 of eKTH3500.
> + */
> +#define QUEUE_HEADER_NORMAL2 0x66
> +
> /* Command header definition */
> #define CMD_HEADER_WRITE 0x54
> #define CMD_HEADER_READ 0x53
> @@ -1052,7 +1061,6 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
> switch (ts->buf[FW_HDR_TYPE]) {
> case CMD_HEADER_HELLO:
> case CMD_HEADER_RESP:
> - case CMD_HEADER_REK:
> break;
>
> case QUEUE_HEADER_WAIT:
> @@ -1072,6 +1080,7 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
> break;
>
> case QUEUE_HEADER_NORMAL:
> + case QUEUE_HEADER_NORMAL2:
I think here I would also prefer that we only accepted this for the
devices where we expect to see such packets:
case CMD_HEADER_REK:
/* comment from above why this is done ... */
if (ts->chip_id != EKTF3624)
break;
fallthrough;
case QUEUE_HEADER_NORMAL2:
...
Given this comments I wonder if it would not make sense to combine the 3
patches into one adding support for EKTF3624...
> report_count = ts->buf[FW_HDR_COUNT];
> if (report_count == 0 || report_count > 3) {
> dev_err(>dev,
> --
> 2.20.1
>
Thanks.
--
Dmitry
Re: [PATCH] tty: serial: meson: enable console as module
On Thu, Dec 10, 2020 at 04:57:44PM -0800, Kevin Hilman wrote: > Enable serial driver to be built as a module. To do so, init the > console support on driver/module load instead of using > console_initcall(). > > Signed-off-by: Kevin Hilman > --- > Yes, I'm well aware that having the serial console as a module makes > devices hard to debug, so I'm not changing any default behavior. The > goal is just to enable building as a module for environments where > serial debug is not available or needed. It's a good goal, I'm all for it, thanks for the patch! greg k-h
Re: [PATCH v4 1/7] mm: memcontrol: fix NR_ANON_THPS accounting in charge moving
> The unit of NR_ANON_THPS is HPAGE_PMD_NR already. So it should inc/dec
> by one rather than nr_pages.
>
> Fixes: 468c398233da ("mm: memcontrol: switch to native NR_ANON_THPS counter")
> Signed-off-by: Muchun Song
> Acked-by: Michal Hocko
> Acked-by: Johannes Weiner
> Reviewed-by: Roman Gushchin
> ---
> mm/memcontrol.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index b80328f52fb4..8818bf64d6fe 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -5653,10 +5653,8 @@ static int mem_cgroup_move_account(struct page *page,
> __mod_lruvec_state(from_vec, NR_ANON_MAPPED,
> -nr_pages);
> __mod_lruvec_state(to_vec, NR_ANON_MAPPED, nr_pages);
> if (PageTransHuge(page)) {
> - __mod_lruvec_state(from_vec, NR_ANON_THPS,
> - -nr_pages);
> - __mod_lruvec_state(to_vec, NR_ANON_THPS,
> - nr_pages);
> + __dec_lruvec_state(from_vec, NR_ANON_THPS);
> + __inc_lruvec_state(to_vec, NR_ANON_THPS);
> }
>
> }
Acked-by: Pankaj Gupta
Re: [PATCH v2] Serial: silabs si4455 serial driver
On Fri, Dec 11, 2020 at 06:37:52AM +, József Horváth wrote:
> On Fri, Dec 11, 2020 at 07:20:41AM +0100, 'Greg Kroah-Hartman' wrote:
> > On Fri, Dec 11, 2020 at 06:09:43AM +, József Horváth wrote:
> > > On Fri, Dec 11, 2020 at 06:50:58AM +0100, 'Greg Kroah-Hartman' wrote:
> > > > On Thu, Dec 10, 2020 at 07:46:25PM +, József Horváth wrote:
> > > > > On Thu, Dec 10, 2020 at 08:03:22PM +0100, 'Greg Kroah-Hartman' wrote:
> > > > > > On Thu, Dec 10, 2020 at 05:04:46PM +, József Horváth wrote:
> > > > > > > This is a serial port driver for
> > > > > > > Silicon Labs Si4455 Sub-GHz transciver.
> > > > > > > +
> > > > > > > +#define BASE_TTYIOC_PRIVATE 0xA0
> > > > > > > +/* Set EZConfig.
> > > > > > > + * After this ioctl call, the driver restarts the si4455,
> > > > > > > + * then apply the new configuration and patch.
> > > > > > > + */
> > > > > > > +#define SI4455_IOC_SEZC _IOW('T', \
> > > > > > > + BASE_TTYIOC_PRIVATE + 0x01, \
> > > > > > > + struct si4455_iocbuff)
> > > > > >
> > > > > > Why does a serial driver have private ioctls? Please no, don't do
> > > > > > that.
> > > > >
> > > > > I checked the ioctl.h and serial_core.h, but I not found any similar
> > > > > definition, like BASE_VIDIOC_PRIVATE in videodev2.h.
> > > > > In this case the name of macro BASE_TTYIOC_PRIVATE means the base
> > > > > value of special ioctl commands owned by this driver.
> > > >
> > > > My point is, a serial driver should NOT have any custom ioctls.
> > > >
> > > > > I can change it to BASE_TTYIOC or SI4455_IOC_BASE
> > > > >
> > > > > > Implement the basic serial driver first, and then we can talk about
> > > > > > "custom" configurations and the like, using the correct apis.
> > > > >
> > > > > Without the SI4455_IOC_SEZC call, the driver can't configure the
> > > > > Si4455 and not working at all.
> > > > > The cofiguration for interface is provided by user for application.
> > > >
> > > > That is what a device tree is for, to configure the device to have the
> > > > correct system configuration, why can't that be the same here?
> > > >
> > > > > It contains the base frequency, channel spacing, modulation, and a lot
> > > > > of more stuff, and generated by Silicon Labs Wireless Development
> > > > > Suite.
> > > > > The generated configuration is in a non public(compressed,
> > > > > encrypted...who knows) format, so without this the driver can't
> > > > > provide configuration parameters to Si4455.
> > > >
> > > > So we have to take a "custom" userspace blob and send it to the device
> > > > to configure it properly? Like Jiri said, sounds like firmware, so just
> > > > use that interface instead.
> > >
> > > I checked Jiri's suggestion, and it is a good solution to replace
> > > SI4455_IOC_SEZC(configuration) and SI4455_IOC_SEZP(firmware patch).
> > > I can move SI4455_IOC_SSIZ(package size) to device tree property.
> > >
> > > Maybe you have good suggestion for the following:
> > > SI4455_IOC_STXC -> Radio transmit channel index. It is a real use case to
> > > control this parameter by user at runtime.
> > > SI4455_IOC_SRXC -> Radio receive channel index. It is a real use case to
> > > control this parameter by user at runtime.
> >
> > These are not serial port things, why would a serial port care about
> > these?
>
> You are right, these are not regular serial port things, but this device is
> not a regular uart, it is a sub-GHz transciever, digital radio.
> This driver tries to represent it as a serial port to user.
Is that the correct representation to be using here? Why not act like a
proper radio device instead? That way you get to use the normal kernel
apis for radio devices.
> > > SI4455_IOC_GRSSI -> Last measured RSSI, when packet received. This is a
> > > useful information.
> > > (Currently I'm the only one user, and I need this :) )
> >
> > What is "RSSI"?
> >
> > And why not debugfs if it's only debugging stuff?
>
> Received signal strength indication, and not only debugging. It is an
> information for the end user.
How do other radio devices (like wifi controllers) export this
information to userspace? Don't create custom apis for only a single
device when the goal of a kernel is to make hardware interfaces all work
the same as far as userspace is concerned.
thanks,
greg k-h
Re: [PATCH RESEND v8 2/4] input: elants: support old touch report format
Hi Michał,
On Fri, Dec 11, 2020 at 07:53:56AM +0100, Michał Mirosław wrote:
> @@ -998,17 +1011,18 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
> }
>
> report_len = ts->buf[FW_HDR_LENGTH] / report_count;
> - if (report_len != PACKET_SIZE) {
> + if (report_len != PACKET_SIZE &&
> + report_len != PACKET_SIZE_OLD) {
> dev_err(>dev,
> - "mismatching report length: %*ph\n",
> + "unsupported report length: %*ph\n",
> HEADER_SIZE, ts->buf);
Do I understand this correctly that the old packets are only observed on
EKTF3624? If so can we expand the check so that we only accept packets
with "old" size when we know we are dealing with this device?
Thanks.
--
Dmitry
Re: [PATCH] init: fix msleep() is not accurate
Am Fri, Dec 11, 2020 at 11:24:12AM +0800 schrieb Yejune Deng: > See Documentation/timers/timers-howto.rst, msleep() is not > for (1ms - 20ms),use usleep_range() instead. While technically correct, this branch is only taken if the "rootwait" kernel parameter is passed -- and as the kernel is looping here, it does not really hurt if the msleep(5) takes a bit longer than advertised. Thanks, Dominik
linux-next: manual merge of the userns tree with the tip tree
Hi all,
Today's linux-next merge of the userns tree got a conflict in:
kernel/events/core.c
between commit:
78af4dc949da ("perf: Break deadlock involving exec_update_mutex")
from the tip tree and commit:
f7cfd871ae0c ("exec: Transform exec_update_mutex into a rw_semaphore")
from the userns tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc kernel/events/core.c
index 19ae6c931c52,55b2330b556c..
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@@ -11958,24 -11864,6 +11958,24 @@@ SYSCALL_DEFINE5(perf_event_open
goto err_context;
}
+ if (task) {
- err =
mutex_lock_interruptible(>signal->exec_update_mutex);
++ err = down_read_interruptible(>signal->exec_update_lock);
+ if (err)
+ goto err_file;
+
+ /*
+ * Preserve ptrace permission check for backwards compatibility.
+ *
-* We must hold exec_update_mutex across this and any potential
++ * We must hold exec_update_lock across this and any potential
+ * perf_install_in_context() call for this new event to
+ * serialize against exec() altering our credentials (and the
+ * perf_event_exit_task() that could imply).
+ */
+ err = -EACCES;
+ if (!perfmon_capable() && !ptrace_may_access(task,
PTRACE_MODE_READ_REALCREDS))
+ goto err_cred;
+ }
+
if (move_group) {
gctx = __perf_event_ctx_lock_double(group_leader, ctx);
@@@ -12151,10 -12039,7 +12151,10 @@@ err_locked
if (move_group)
perf_event_ctx_unlock(group_leader, gctx);
mutex_unlock(>mutex);
-/* err_file: */
+err_cred:
+ if (task)
- mutex_unlock(>signal->exec_update_mutex);
++ up_read(>signal->exec_update_lock);
+err_file:
fput(event_file);
err_context:
perf_unpin_context(ctx);
pgpVlMu_YJpPS.pgp
Description: OpenPGP digital signature
[PATCH] kunit: Print test statistics on failure
When a number of tests fail, it can be useful to get higher-level
statistics of how many tests are failing (or how many parameters are
failing in parameterised tests), and in what cases or suites. This is
already done by some non-KUnit tests, so add support for automatically
generating these for KUnit tests.
This change adds a 'kunit_stats_enabled' switch which has three values:
- 0: No stats are printed (current behaviour)
- 1: Stats are printed only for tests/suites with more than one
subtests, and at least one failure (new default)
- 2: Always print test statistics
For parameterised tests, the summary line looks as follows:
"# inode_test_xtimestamp_decoding: 0 / 16 test parameters failed"
For test suites, it looks like this:
"# ext4_inode_test: (0 / 1) tests failed (0 / 16 test parameters)"
kunit_tool is also updated to correctly ignore diagnostic lines, so that
these statistics do not prevent the result from parsing.
Signed-off-by: David Gow
---
This is largely a follow-up to the discussion here:
https://lore.kernel.org/linux-kselftest/CABVgOSmy4n_LGwDS7yWfoLftcQzxv6S+iXx9Y=opcgg2gu0...@mail.gmail.com/T/#t
Does this seem like a sensible addition?
Cheers,
-- David
lib/kunit/test.c| 71 +
tools/testing/kunit/kunit_parser.py | 2 +-
2 files changed, 72 insertions(+), 1 deletion(-)
diff --git a/lib/kunit/test.c b/lib/kunit/test.c
index ec9494e914ef..711e269366a7 100644
--- a/lib/kunit/test.c
+++ b/lib/kunit/test.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
@@ -16,6 +17,40 @@
#include "string-stream.h"
#include "try-catch-impl.h"
+/*
+ * KUnit statistic mode:
+ * 0 - disabled
+ * 1 - only when there is at least one failure, and more than one subtest
+ * 2 - enabled
+ */
+static int kunit_stats_enabled = 1;
+core_param(kunit_stats_enabled, kunit_stats_enabled, int, 0644);
+
+static bool kunit_should_print_stats(int num_failures, int num_subtests)
+{
+ if (kunit_stats_enabled == 0)
+ return false;
+
+ if (kunit_stats_enabled == 2)
+ return true;
+
+ return (num_failures > 0 && num_subtests > 1);
+}
+
+static void kunit_print_test_stats(struct kunit *test,
+ size_t num_failures, size_t num_subtests)
+{
+ if (!kunit_should_print_stats(num_failures, num_subtests))
+ return;
+
+ kunit_log(KERN_INFO, test,
+ KUNIT_SUBTEST_INDENT
+ "# %s: %lu / %lu test parameters failed",
+ test->name,
+ num_failures,
+ num_subtests);
+}
+
/*
* Append formatted message to log, size of which is limited to
* KUNIT_LOG_SIZE bytes (including null terminating byte).
@@ -346,15 +381,37 @@ static void kunit_run_case_catch_errors(struct
kunit_suite *suite,
test_case->success = test->success;
}
+static void kunit_print_suite_stats(struct kunit_suite *suite,
+ size_t num_failures,
+ size_t total_param_failures,
+ size_t total_params)
+{
+ size_t num_cases = kunit_suite_num_test_cases(suite);
+
+ if (!kunit_should_print_stats(num_failures, num_cases))
+ return;
+
+ kunit_log(KERN_INFO, suite,
+ "# %s: (%lu / %lu) tests failed (%lu / %lu test parameters)",
+ suite->name,
+ num_failures,
+ num_cases,
+ total_param_failures,
+ total_params);
+}
+
int kunit_run_tests(struct kunit_suite *suite)
{
char param_desc[KUNIT_PARAM_DESC_SIZE];
struct kunit_case *test_case;
+ size_t num_suite_failures = 0;
+ size_t total_param_failures = 0, total_params = 0;
kunit_print_subtest_start(suite);
kunit_suite_for_each_test_case(suite, test_case) {
struct kunit test = { .param_value = NULL, .param_index = 0 };
+ size_t num_params = 0, num_failures = 0;
bool test_success = true;
if (test_case->generate_params) {
@@ -385,13 +442,27 @@ int kunit_run_tests(struct kunit_suite *suite)
test.param_value =
test_case->generate_params(test.param_value, param_desc);
test.param_index++;
}
+
+ if (!test.success)
+ num_failures++;
+ num_params++;
+
} while (test.param_value);
+ kunit_print_test_stats(, num_failures, num_params);
+
kunit_print_ok_not_ok(, true, test_success,
kunit_test_case_num(suite, test_case),
test_case->name);
+
+ if (!test_success)
+ num_suite_failures++;
+ total_params +=
Re: [PATCH RESEND v8 3/4] input: elants: read touchscreen size for EKTF3624
Hi Michał,
On Fri, Dec 11, 2020 at 07:53:56AM +0100, Michał Mirosław wrote:
> +
> + if (!phy_x || !phy_y) {
> + dev_warn(>dev,
> + "invalid size data: %d x %d mm\n",
> + phy_x, phy_y);
> + return 0;
Given we are not treating this as hard error mind dropping this "return"
and making the below an "else" branch?
> + }
> +
> + dev_dbg(>dev, "phy_x=%d, phy_y=%d\n", phy_x, phy_y);
> +
> + /* calculate resolution from size */
> + ts->x_max = 2240-1;
> + ts->x_res = DIV_ROUND_CLOSEST(ts->prop.max_x, phy_x);
> +
> + ts->y_max = 1408-1;
> + ts->y_res = DIV_ROUND_CLOSEST(ts->prop.max_y, phy_y);
> +
> + return 0;
> +}
> +
>
> + if (client->dev.of_node)
> + ts->chip_id = (uintptr_t)of_device_get_match_data(>dev);
Why don't we add EKTH3500 tag to the ACPI entry and make this
unconditional device_get_match_data()?
> +
> ts->vcc33 = devm_regulator_get(>dev, "vcc33");
> if (IS_ERR(ts->vcc33)) {
> error = PTR_ERR(ts->vcc33);
> @@ -1495,7 +1568,8 @@ MODULE_DEVICE_TABLE(acpi, elants_acpi_id);
>
> #ifdef CONFIG_OF
> static const struct of_device_id elants_of_match[] = {
> - { .compatible = "elan,ekth3500" },
> + { .compatible = "elan,ekth3500", .data = (void *)EKTH3500 },
> + { .compatible = "elan,ektf3624", .data = (void *)EKTF3624 },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, elants_of_match);
> --
> 2.20.1
>
Thanks.
--
Dmitry
Re: [PATCH RESEND net-next 1/2] dpaa2-eth: send a scatter-gather FD instead of realloc-ing
On Thu, Dec 10, 2020 at 7:08 PM Ioana Ciornei wrote: > > [Added also the netdev mailing list, I haven't heard of linux-netdev > before but kept it] > > On Thu, Dec 10, 2020 at 05:31:56PM +, Daniel Thompson wrote: > > Hi Ioana > > Hi Daniel, > > > > > On Mon, Jun 29, 2020 at 06:47:11PM +, Ioana Ciornei wrote: > > > Instead of realloc-ing the skb on the Tx path when the provided headroom > > > is smaller than the HW requirements, create a Scatter/Gather frame > > > descriptor with only one entry. > > > > > > Remove the '[drv] tx realloc frames' counter exposed previously through > > > ethtool since it is no longer used. > > > > > > Signed-off-by: Ioana Ciornei > > > --- > > > > I've been chasing down a networking regression on my LX2160A board > > (Honeycomb LX2K based on CEx7 LX2160A COM) that first appeared in v5.9. > > > > It makes the board unreliable opening outbound connections meaning > > things like `apt update` or `git fetch` often can't open the connection. > > It does not happen all the time but is sufficient to make the boards > > built-in networking useless for workstation use. > > > > The problem is strongly linked to warnings in the logs so I used the > > warnings to bisect down to locate the cause of the regression and it > > pinpointed this patch. I have confirmed that in both v5.9 and v5.10-rc7 > > that reverting this patch (and fixing up the merge issues) fixes the > > regression and the warnings stop appearing. > > > > A typical example of the warning is below (io-pgtable-arm.c:281 is an > > error path that I guess would cause dma_map_page_attrs() to return > > an error): > > > > [ 714.464927] WARNING: CPU: 13 PID: 0 at > > drivers/iommu/io-pgtable-arm.c:281 __arm_lpae_map+0x2d4/0x30c > > [ 714.464930] Modules linked in: snd_seq_dummy(E) snd_hrtimer(E) > > snd_seq(E) snd_seq_device(E) snd_timer(E) snd(E) soundcore(E) bridge(E) > > stp(E) llc(E) rfkill(E) caam_jr(E) crypto_engine(E) rng_core(E) > > joydev(E) evdev(E) dpaa2_caam(E) caamhash_desc(E) caamalg_desc(E) > > authenc(E) libdes(E) dpaa2_console(E) ofpart(E) caam(E) sg(E) error(E) > > lm90(E) at24(E) spi_nor(E) mtd(E) sbsa_gwdt(E) qoriq_thermal(E) > > layerscape_edac_mod(E) qoriq_cpufreq(E) drm(E) fuse(E) configfs(E) > > ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc32c_generic(E) crc16(E) > > mbcache(E) jbd2(E) hid_generic(E) usbhid(E) hid(E) dm_crypt(E) dm_mod(E) > > sd_mod(E) fsl_dpaa2_ptp(E) ptp_qoriq(E) fsl_dpaa2_eth(E) > > xhci_plat_hcd(E) xhci_hcd(E) usbcore(E) aes_ce_blk(E) crypto_simd(E) > > cryptd(E) aes_ce_cipher(E) ghash_ce(E) gf128mul(E) at803x(E) libaes(E) > > fsl_mc_dpio(E) pcs_lynx(E) rtc_pcf2127(E) sha2_ce(E) phylink(E) > > xgmac_mdio(E) regmap_spi(E) of_mdio(E) sha256_arm64(E) > > i2c_mux_pca954x(E) fixed_phy(E) i2c_mux(E) sha1_ce(E) ptp(E) libphy(E) > > [ 714.465131] pps_core(E) ahci_qoriq(E) libahci_platform(E) nvme(E) > > libahci(E) nvme_core(E) t10_pi(E) libata(E) crc_t10dif(E) > > crct10dif_generic(E) crct10dif_common(E) dwc3(E) scsi_mod(E) udc_core(E) > > roles(E) ulpi(E) sdhci_of_esdhc(E) sdhci_pltfm(E) sdhci(E) > > spi_nxp_fspi(E) i2c_imx(E) fixed(E) > > [ 714.465192] CPU: 13 PID: 0 Comm: swapper/13 Tainted: GW E > > 5.10.0-rc7-1-gba98d13279ca #52 > > [ 714.465196] Hardware name: SolidRun LX2160A Honeycomb (DT) > > [ 714.465202] pstate: 6005 (nZCv daif -PAN -UAO -TCO BTYPE=--) > > [ 714.465207] pc : __arm_lpae_map+0x2d4/0x30c > > [ 714.465211] lr : __arm_lpae_map+0x114/0x30c > > [ 714.465215] sp : 80001006b340 > > [ 714.465219] x29: 80001006b340 x28: 002086538003 > > [ 714.465227] x27: 0a20 x26: 1000 > > [ 714.465236] x25: 0f44 x24: 0020adf8d000 > > [ 714.465245] x23: 0001 x22: faeca000 > > [ 714.465253] x21: 0003 x20: 19b60d64d200 > > [ 714.465261] x19: 00ca x18: > > [ 714.465270] x17: x16: cccb7cf3ca20 > > [ 714.465278] x15: x14: > > [ 714.465286] x13: 0003 x12: 0010 > > [ 714.465294] x11: x10: 0002 > > [ 714.465302] x9 : cccb7d5b6e78 x8 : 01ff > > [ 714.465311] x7 : 19b606538650 x6 : 19b606538000 > > [ 714.465319] x5 : 0009 x4 : 0f44 > > [ 714.465327] x3 : 1000 x2 : 0020adf8d000 > > [ 714.465335] x1 : 0002 x0 : 0003 > > [ 714.465343] Call trace: > > [ 714.465348] __arm_lpae_map+0x2d4/0x30c > > [ 714.465353] __arm_lpae_map+0x114/0x30c > > [ 714.465357] __arm_lpae_map+0x114/0x30c > > [ 714.465362] __arm_lpae_map+0x114/0x30c > > [ 714.465366] arm_lpae_map+0xf4/0x180 > > [ 714.465373] arm_smmu_map+0x4c/0xc0 > > [ 714.465379] __iommu_map+0x100/0x2bc > > [ 714.465385] iommu_map_atomic+0x20/0x30 > > [ 714.465391] __iommu_dma_map+0xb0/0x110 > > [ 714.465397] iommu_dma_map_page+0xb8/0x120 > > [ 714.465404]
[PATCH v1] usb: typec: tcpm: Update vbus_vsafe0v on init
During init, vbus_vsafe0v does not get updated till the first connect as a sink. This causes TCPM to be stuck in SRC_ATTACH_WAIT state while booting with a sink (For instance: a headset) connected. [1.429168] Start toggling [1.439907] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected] [1.445242] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected] [ 53.358528] CC1: 0 -> 0, CC2: 0 -> 2 [state TOGGLING, polarity 0, connected] [ 53.358564] state change TOGGLING -> SRC_ATTACH_WAIT [rev1 NONE_AMS] Fix this by updating vbus_vsafe0v based on vbus_present status on boot. Signed-off-by: Badhri Jagan Sridharan --- drivers/usb/typec/tcpm/tcpm.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index cedc6cf82d61..58a6302c549f 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -4794,6 +4794,24 @@ static void tcpm_init(struct tcpm_port *port) if (port->vbus_present) port->vbus_never_low = true; + /* +* 1. When vbus_present is true, voltage on VBUS is already at VSAFE5V. +* So implicitly vbus_vsafe0v = false. +* +* 2. When vbus_present is false and TCPC does NOT support querying +* vsafe0v status, then, it's best to assume vbus is at VSAFE0V i.e. +* vbus_vsafe0v is true. +* +* 3. When vbus_present is false and TCPC does support querying vsafe0v, +* then, query tcpc for vsafe0v status. +*/ + if (port->vbus_present) + port->vbus_vsafe0v = false; + else if (!port->tcpc->is_vbus_vsafe0v) + port->vbus_vsafe0v = true; + else + port->vbus_vsafe0v = port->tcpc->is_vbus_vsafe0v(port->tcpc); + tcpm_set_state(port, tcpm_default_state(port), 0); if (port->tcpc->get_cc(port->tcpc, , ) == 0) -- 2.29.2.576.ga3fc446d84-goog
[PATCH 2/2] Input: elantech - Some module tp of tracpoint report has a smbus protocol error.
1. Add the conditional expression to distinguish different patterns regarding
0, 1, 2.
2. Add the function to get or set more bytes from register
3. Get and correct the device informations including ic_type, module id from
different pattern.
4. Add the function to change the report id 0x5F of trackpoint.
5. Some module has a bug which makes default SMBUS trackpoint report 0x5E has a
smbus protocol error.
Signed-off-by: Jingle Wu
---
drivers/input/mouse/elantech.c | 98 +-
drivers/input/mouse/elantech.h | 4 ++
2 files changed, 100 insertions(+), 2 deletions(-)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 90f8765f9efc..1f6552e25bec 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -89,6 +89,48 @@ static int elantech_ps2_command(struct psmouse *psmouse,
return rc;
}
+/*
+ * Send an Elantech style special command to read 3 bytes from a register
+ */
+static int elantech_read_reg_params(struct psmouse *psmouse, unsigned char reg,
+ unsigned char *param)
+{
+ if (elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND) ||
+ elantech_ps2_command(psmouse, NULL, ETP_REGISTER_READWRITE) ||
+ elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND) ||
+ elantech_ps2_command(psmouse, NULL, reg) ||
+ elantech_ps2_command(psmouse, param, PSMOUSE_CMD_GETINFO)) {
+ psmouse_err(psmouse,
+ "failed to read register 0x%02x.\n", reg);
+ return -1;
+ }
+ return 0;
+}
+
+/*
+ * Send an Elantech style special command to write a register with a parameter
+ */
+static int elantech_write_reg_params(struct psmouse *psmouse, unsigned char
reg,
+ unsigned char *param)
+{
+ if (elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND) ||
+ elantech_ps2_command(psmouse, NULL, ETP_REGISTER_READWRITE) ||
+ elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND) ||
+ elantech_ps2_command(psmouse, NULL, reg) ||
+ elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND) ||
+ elantech_ps2_command(psmouse, NULL, param[0]) ||
+ elantech_ps2_command(psmouse, NULL, ETP_PS2_CUSTOM_COMMAND) ||
+ elantech_ps2_command(psmouse, NULL, param[1]) ||
+ elantech_ps2_command(psmouse, NULL, PSMOUSE_CMD_SETSCALE11)) {
+ psmouse_err(psmouse,
+ "failed to write register 0x%02x with value
0x%02x0x%02x.\n",
+ reg, param[0], param[1]);
+ return -1;
+ }
+ return 0;
+
+}
+
/*
* Send an Elantech style special command to read a value from a register
*/
@@ -1529,19 +1571,33 @@ static const struct dmi_system_id no_hw_res_dmi_table[]
= {
{ }
};
+/*
+ * Change Report id 0x5E to 0x5F.
+ */
+static int elantech_change_report_id(struct psmouse *psmouse)
+{
+ unsigned char param[2] = { 0x10, 0x03 };
+
+ if (elantech_write_reg_params(psmouse, 0x7, param) == 0)
+ if (elantech_read_reg_params(psmouse, 0x7, param) == 0)
+ if ((param[0] == 0x10) && (param[1] == 0x03))
+ return 0;
+ psmouse_err(psmouse, "change report id Fail.\n");
+ return -1;
+}
/*
* determine hardware version and set some properties according to it.
*/
static int elantech_set_properties(struct elantech_device_info *info)
{
/* This represents the version of IC body. */
- int ver = (info->fw_version & 0x0f) >> 16;
+ info->ic_version = (info->fw_version & 0x0f) >> 16;
/* Early version of Elan touchpads doesn't obey the rule. */
if (info->fw_version < 0x020030 || info->fw_version == 0x020600)
info->hw_version = 1;
else {
- switch (ver) {
+ switch (info->ic_version) {
case 2:
case 4:
info->hw_version = 2;
@@ -1557,6 +1613,11 @@ static int elantech_set_properties(struct
elantech_device_info *info)
}
}
+ /* Get information pattern for hw_version 4 */
+ info->pattern = 0x00;
+ if (info->ic_version == 0x0f && (info->fw_version & 0xff) <= 0x02)
+ info->pattern = info->fw_version & 0xff;
+
/* decide which send_cmd we're gonna use early */
info->send_cmd = info->hw_version >= 3 ? elantech_send_cmd :
synaptics_send_cmd;
@@ -1598,6 +1659,7 @@ static int elantech_query_info(struct psmouse *psmouse,
{
unsigned char param[3];
unsigned char traces;
+ unsigned char ic_body[3];
memset(info, 0, sizeof(*info));
@@ -1640,6 +1702,22 @@ static int elantech_query_info(struct psmouse
[PATCH 1/2] Input: elan_i2c - Add new trackpoint report type 0x5F.
The 0x5F is new trackpoint report type of some module.
Signed-off-by: Jingle Wu
---
drivers/input/mouse/elan_i2c.h | 6 ++
drivers/input/mouse/elan_i2c_core.c | 5 +
drivers/input/mouse/elan_i2c_smbus.c | 8 ++--
3 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/input/mouse/elan_i2c.h b/drivers/input/mouse/elan_i2c.h
index 36e3cd908671..d5f9cd76eefb 100644
--- a/drivers/input/mouse/elan_i2c.h
+++ b/drivers/input/mouse/elan_i2c.h
@@ -28,6 +28,12 @@
#define ETP_FEATURE_REPORT_MK BIT(0)
+#define ETP_REPORT_ID 0x5D
+#define ETP_REPORT_ID2 0x60/* High precision report */
+#define ETP_TP_REPORT_ID 0x5E
+#define ETP_TP_REPORT_ID2 0x5F
+#define ETP_REPORT_ID_OFFSET 2
+
/* IAP Firmware handling */
#define ETP_PRODUCT_ID_FORMAT_STRING "%d.0"
#define ETP_FW_NAME"elan_i2c_" ETP_PRODUCT_ID_FORMAT_STRING ".bin"
diff --git a/drivers/input/mouse/elan_i2c_core.c
b/drivers/input/mouse/elan_i2c_core.c
index 61ed3f5ca219..0f46e2f6c9e8 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -49,10 +49,6 @@
#define ETP_MAX_FINGERS5
#define ETP_FINGER_DATA_LEN5
-#define ETP_REPORT_ID 0x5D
-#define ETP_REPORT_ID2 0x60/* High precision report */
-#define ETP_TP_REPORT_ID 0x5E
-#define ETP_REPORT_ID_OFFSET 2
#define ETP_TOUCH_INFO_OFFSET 3
#define ETP_FINGER_DATA_OFFSET 4
#define ETP_HOVER_INFO_OFFSET 30
@@ -1076,6 +1072,7 @@ static irqreturn_t elan_isr(int irq, void *dev_id)
elan_report_absolute(data, report, true);
break;
case ETP_TP_REPORT_ID:
+ case ETP_TP_REPORT_ID2:
elan_report_trackpoint(data, report);
break;
default:
diff --git a/drivers/input/mouse/elan_i2c_smbus.c
b/drivers/input/mouse/elan_i2c_smbus.c
index 1820f1cfc1dc..6dc148b9d959 100644
--- a/drivers/input/mouse/elan_i2c_smbus.c
+++ b/drivers/input/mouse/elan_i2c_smbus.c
@@ -45,6 +45,7 @@
#define ETP_SMBUS_CALIBRATE_QUERY 0xC5
#define ETP_SMBUS_REPORT_LEN 32
+#define ETP_SMBUS_REPORT_LEN2 7
#define ETP_SMBUS_REPORT_OFFSET2
#define ETP_SMBUS_HELLOPACKET_LEN 5
#define ETP_SMBUS_IAP_PASSWORD 0x1234
@@ -497,10 +498,13 @@ static int elan_smbus_get_report(struct i2c_client
*client,
return len;
}
- if (len != ETP_SMBUS_REPORT_LEN) {
+ if (report[ETP_REPORT_ID_OFFSET] == ETP_TP_REPORT_ID2)
+ report_len = ETP_SMBUS_REPORT_LEN2;
+
+ if (len != report_len) {
dev_err(>dev,
"wrong report length (%d vs %d expected)\n",
- len, ETP_SMBUS_REPORT_LEN);
+ len, report_len);
return -EIO;
}
--
2.17.1
Re: [PATCH 2/2] blk-iocost: Use alloc_percpu_gfp() to simplify the code
Hi Tejun, Hello, On Thu, Dec 10, 2020 at 06:56:45PM +0800, Baolin Wang wrote: Use alloc_percpu_gfp() with __GFP_ZERO flag, which can remove some explicit initialization code. __GFP_ZERO is implicit for percpu allocations and local[64]_t's initial states aren't guaranteed to be all zeros on different archs. Thanks for teaching me this, at least I did not get this from the local_ops Documentation before. Just out of curiosity, these local[64]_t variables are also allocated from budy allocator ultimately, why they can not be initialized to zeros on some ARCHs with __GFP_ZERO? Could you elaborate on about this restriction? Thanks. By the way, seems the kyber-iosched has the same issue, since the 'struct kyber_cpu_latency' also contains an atomic_t variable. kqd->cpu_latency = alloc_percpu_gfp(struct kyber_cpu_latency, GFP_KERNEL | __GFP_ZERO); if (!kqd->cpu_latency) goto err_kqd;
[GIT PULL] clk fixes for v5.10-rc7
The following changes since commit c277ca155d2f0028a5c79708426d3f79b54a5fc1: clk: imx8m: fix bus critical clk registration (2020-11-04 17:13:12 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git tags/clk-fixes-for-linus for you to fetch changes up to ceabbf94c317c6175dee6e91805fca4a6353745a: clk: renesas: r9a06g032: Drop __packed for portability (2020-12-07 13:58:49 -0800) Two small clk driver build fixes - Remove __packed from a Renesas struct to improve portability - Fix a linking problem with i.MX when config options don't agree Dong Aisheng (1): clk: imx: scu: fix MXC_CLK_SCU module build break Geert Uytterhoeven (1): clk: renesas: r9a06g032: Drop __packed for portability drivers/clk/imx/Kconfig| 4 ++-- drivers/clk/renesas/r9a06g032-clocks.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) -- https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/ https://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi.git
[PATCH] usb: typec: tcpci: Enable bleed discharge when auto discharge is enabled
Auto discharge circuits kick in only when vbus decays and reaches VBUS_SINK_DISCONNECT_THRESHOLD threshold. Enable bleed discharge to discharge vbus to VBUS_SINK_DISCONNECT_THRESHOLD upon disconnect. Signed-off-by: Badhri Jagan Sridharan --- drivers/usb/typec/tcpm/tcpci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c index af5524338a63..f676abab044b 100644 --- a/drivers/usb/typec/tcpm/tcpci.c +++ b/drivers/usb/typec/tcpm/tcpci.c @@ -725,6 +725,8 @@ struct tcpci *tcpci_register_port(struct device *dev, struct tcpci_data *data) tcpci->tcpc.enable_auto_vbus_discharge = tcpci_enable_auto_vbus_discharge; tcpci->tcpc.set_auto_vbus_discharge_threshold = tcpci_set_auto_vbus_discharge_threshold; + regmap_update_bits(tcpci->regmap, TCPC_POWER_CTRL, TCPC_POWER_CTRL_BLEED_DISCHARGE, + TCPC_POWER_CTRL_BLEED_DISCHARGE); } if (tcpci->data->vbus_vsafe0v) -- 2.29.2.576.ga3fc446d84-goog
Re: [PATCH RESEND v8 1/4] input: elants: document some registers and values
On Fri, Dec 11, 2020 at 07:53:56AM +0100, Michał Mirosław wrote: > Add information found in downstream kernels, to make the code less > magic. > > Signed-off-by: Michał Mirosław > Reviewed-by: Dmitry Osipenko > Tested-by: Dmitry Osipenko Applied, thank you. -- Dmitry
[PATCH] fs/proc: make pde_get() return nothing
we don't need pde_get()'s return value, so make
pde_get() return nothing
Signed-off-by: Hui Su
---
fs/proc/internal.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/proc/internal.h b/fs/proc/internal.h
index 917cc85e3466..0abbd93a4a08 100644
--- a/fs/proc/internal.h
+++ b/fs/proc/internal.h
@@ -190,10 +190,9 @@ struct dentry *proc_lookup_de(struct inode *, struct
dentry *, struct proc_dir_e
extern int proc_readdir(struct file *, struct dir_context *);
int proc_readdir_de(struct file *, struct dir_context *, struct proc_dir_entry
*);
-static inline struct proc_dir_entry *pde_get(struct proc_dir_entry *pde)
+static inline void pde_get(struct proc_dir_entry *pde)
{
refcount_inc(>refcnt);
- return pde;
}
extern void pde_put(struct proc_dir_entry *);
--
2.29.2
Re: [PATCH v2 5/5] clk: qcom: gcc: Add clock driver for SM8350
Quoting Vinod Koul (2020-12-10 21:43:49)
> On 10-12-20, 12:43, Stephen Boyd wrote:
> > > +static struct clk_branch gcc_camera_ahb_clk = {
> > > + .halt_reg = 0x26004,
> > > + .halt_check = BRANCH_HALT_DELAY,
> > > + .hwcg_reg = 0x26004,
> > > + .hwcg_bit = 1,
> > > + .clkr = {
> > > + .enable_reg = 0x26004,
> > > + .enable_mask = BIT(0),
> > > + .hw.init = &(struct clk_init_data){
> > > + .name = "gcc_camera_ahb_clk",
> > > + .flags = CLK_IS_CRITICAL,
> >
> > Why is it critical? Can we just enable it in driver probe and stop
> > modeling it as a clk?
>
> it does not have a parent we control, yeah it would make sense to do
> that. Tanya do you folks agree ..?
>
Maybe it is needed for camera clk controller? Have to check other SoCs
and see if they're using it.
[PATCH] Input: cyapa - do not call input_device_enabled from power mode handler
Input device's user counter is supposed to be accessed only while holding
input->mutex. Commit d69f0a43c677 ("Input: use input_device_enabled()")
recently switched cyapa to using the dedicated API and it uncovered the
fact that cyapa driver violated this constraint.
This patch removes checks whether the input device is open when clearing
device queues when changing device's power mode as there is no harm in
sending input events through closed input device - the events will simply
be dropped by the input core.
Note that there are more places in cyapa driver that call
input_device_enabled() without holding input->mutex, those are left
unfixed for now.
Reported-by: Marek Szyprowski
Signed-off-by: Dmitry Torokhov
---
Marek, could you please try this one?
drivers/input/mouse/cyapa_gen3.c |5 +
drivers/input/mouse/cyapa_gen5.c |3 +--
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/input/mouse/cyapa_gen3.c b/drivers/input/mouse/cyapa_gen3.c
index a97f4acb6452..4a9022faf945 100644
--- a/drivers/input/mouse/cyapa_gen3.c
+++ b/drivers/input/mouse/cyapa_gen3.c
@@ -907,7 +907,6 @@ static u16 cyapa_get_wait_time_for_pwr_cmd(u8 pwr_mode)
static int cyapa_gen3_set_power_mode(struct cyapa *cyapa, u8 power_mode,
u16 always_unused, enum cyapa_pm_stage pm_stage)
{
- struct input_dev *input = cyapa->input;
u8 power;
int tries;
int sleep_time;
@@ -953,7 +952,6 @@ static int cyapa_gen3_set_power_mode(struct cyapa *cyapa,
u8 power_mode,
* depending on the command's content.
*/
if (cyapa->operational &&
- input && input_device_enabled(input) &&
(pm_stage == CYAPA_PM_RUNTIME_SUSPEND ||
pm_stage == CYAPA_PM_RUNTIME_RESUME)) {
/* Try to polling in 120Hz, read may fail, just ignore it. */
@@ -1223,8 +1221,7 @@ static int cyapa_gen3_try_poll_handler(struct cyapa
*cyapa)
(data.finger_btn & OP_DATA_VALID) != OP_DATA_VALID)
return -EINVAL;
- return cyapa_gen3_event_process(cyapa, );
-
+ return cyapa->input ? cyapa_gen3_event_process(cyapa, ) : 0;
}
static int cyapa_gen3_initialize(struct cyapa *cyapa) { return 0; }
diff --git a/drivers/input/mouse/cyapa_gen5.c b/drivers/input/mouse/cyapa_gen5.c
index abf42f77b4c5..afc5aa4dcf47 100644
--- a/drivers/input/mouse/cyapa_gen5.c
+++ b/drivers/input/mouse/cyapa_gen5.c
@@ -518,8 +518,7 @@ int cyapa_empty_pip_output_data(struct cyapa *cyapa,
*len = length;
/* Response found, success. */
return 0;
- } else if (cyapa->operational &&
- input && input_device_enabled(input) &&
+ } else if (cyapa->operational && input &&
(pm_stage == CYAPA_PM_RUNTIME_RESUME ||
pm_stage == CYAPA_PM_RUNTIME_SUSPEND)) {
/* Parse the data and report it if it's valid. */
Re: [PATCH v2 4/5] clk: qcom: clk-alpha-pll: Add support for Lucid 5LPE PLL
Quoting Vinod Koul (2020-12-10 21:02:57) > On 10-12-20, 12:36, Stephen Boyd wrote: > > > + > > > + return regmap_update_bits(pll->clkr.regmap, PLL_USER_CTL(pll), > > > + (BIT(pll->width) - 1) << > > > pll->post_div_shift, > > > > Use GENMASK? > > Looks like this can be: > GENMASK(pll->width + pll->post_div_shift - 1, > pll->post_div_shift) > > Not sure which one you like :) Preferably a local u32 mask = GENMASK(...)
Re: [PATCH v2 3/3] pinctrl: qcom: Clear possible pending irq when remuxing GPIOs
Hi Doug,
On 12/10/2020 6:13 AM, Doug Anderson wrote:
Hi,
On Tue, Dec 8, 2020 at 9:54 PM Maulik Shah wrote:
but as long as its IRQ is in disabled/masked state it
doesn't matter.
...but there's no requirement that someone would need to disable/mask
an interrupt while switching the muxing, is there? So it does matter.
its only when the GPIO is again set to IRQ mode with set_mux callback,
the phantom IRQ needs clear to start as clean.
So we should check only for if (i == pctrl->soc->gpio_func) then clear
phantom IRQ.
The same is case with .direction_output callback, when GPIO is used as
output say as clock, need not clear any phantom IRQ,
The reason is with every pulse of clock it can latch as pending IRQ in
GIC_ISPEND as long as it stay as output mode/clock.
its only when switching back GPIO from output direction to input & IRQ
function, need to clear the phantom IRQ.
so we do not require clear phantom irq in .direction_output callback.
I think all the above explanation is with the model that the interrupt
detection logic is still happening even when muxed away. I don't
believe that's true.
Its not the interrupt detection logic that is still happening when muxed
away, but the GPIO line is routed to GIC from PDC.
The GPIO line get forwarded when the system is active/out of system
level low power mode to GIC irrespective of whether GPIO is used as
interrupt or not.
Due to this it can still latch the IRQ at GIC after switching to lets
say Rx mode, whenever the line has any data recive, the line state
toggles can be latched as error interrupt at GIC.
From my tests, though, I strongly believe that the pin is only visible
to the PDC if it's muxed as GPIO. Specifically, in my tests I did
this (with all my patches applied so there were no phantom interrupts
when remuxing):
a) Muxed the pin away from GPIO to special function, but _didn't_ mask
the interrupt.
b) Toggled the line a whole bunch. These caused no interrupts at all.
c) Muxed back to GPIO.
To me this is quite strong evidence that the muxing is "earlier" in
the path than the connection to the PDC. In other words, if you
change the mux away from GPIO then the PDC stops seeing it and thus
the GIC also stops seeing it. The GIC can't latch what it can't see.
This means while you're in "Rx mode" it can't be latched.
OK, so just in case this somehow only happens in S3, I also tried this
(with my patch from https://crrev.com/c/2556012):
a) Muxed away from GPIO ("bogus" pinmux)
b) Enter S3.
c) Toggle the GPIO a whole bunch ("wp enable / wp disable" on Cr50).
d) Wake from S3.
e) Check to see if the interrupt fired a bunch. It didn't fire at all
In my test code the interrupt is not masked, only muxed away. That
means that if, somehow, the PDC was still observing it then we'd see
the interrupt fire. We don't.
Unless I messed up in my tests (always possible, though by this point
I've run them a number of times) then it still feels like your mental
model is wrong, or it's always possible I'm still misunderstanding
your model. Regardless, rather than trying to re-explain your model
can you please confirm that you've written test code to confirm your
mental model? If so, can you please provide this test code? I've
provided several test patches proving out my mental model.
Its not a mental model, its how the line is connected to GIC.
GPIO follows the path, TLMM to PDC to GIC.
PDC donot know if the line is muxed away from GPIO to some other
function, so it can stop forwarding to GIC.
I have slightly modified your test case (see at
https://crrev.com/c/2584729) which is as per what i used in my testing.
Here is what i am doing, setting GPIO to a fixed function (function 2 here)
Note that function 0 is the GPIO (interrupt mode).
1) Pull up the GPIO in function 2
2) Pull down the GPIO in function 2
Repeat above steps, and you will see fake interrupt every time pull down/up.
This proves that if you mux away from GPIO then still PDC sees the line
and can latch the interrupt at GIC.
Thanks,
Maulik
As the interrupt is in disabled state it won't be sent to CPU.
Its only when the driver chooses to switch back to interrupt mode we
want to clear the error interrupt latched to start as clean. same is the
case when used as output direction.
Hope above is clear.
Unfortunately, it's still not. :( Can I convince you to provide a
test patch and a set of steps that will demonstrate the problem you're
worried about? Specifically:
a) Maybe you're talking about the initial switch from a plain GPIO
input to making it an interrupt for the first time? Are you worried
about a phantom interrupt in this case? After patch #1 I think we're
safe because pdc_gic_set_type() will always clear the interrupt,
right?
b) You say "switch back to interrupt mode". Are you imagining that a
driver does something like this:
request_irq();
...
free_irq();
...
request_irq();
If you're worried about that then we can implement irq_shutdown() for
PDC
Re: [PATCH net-next 3/7] net: hns3: add support for forwarding packet to queues of specified TC when flow director rule hit
On 2020/12/11 4:46, Saeed Mahameed wrote:
On Thu, 2020-12-10 at 20:24 +0800, tanhuazhong wrote:
On 2020/12/10 13:40, Saeed Mahameed wrote:
On Thu, 2020-12-10 at 11:42 +0800, Huazhong Tan wrote:
From: Jian Shen
For some new device, it supports forwarding packet to queues
of specified TC when flow director rule hit. So extend the
command handle to support it.
...
static int hclge_config_action(struct hclge_dev *hdev, u8
stage,
struct hclge_fd_rule *rule)
{
+ struct hclge_vport *vport = hdev->vport;
+ struct hnae3_knic_private_info *kinfo = >nic.kinfo;
struct hclge_fd_ad_data ad_data;
+ memset(_data, 0, sizeof(struct hclge_fd_ad_data));
ad_data.ad_id = rule->location;
if (rule->action == HCLGE_FD_ACTION_DROP_PACKET) {
ad_data.drop_packet = true;
- ad_data.forward_to_direct_queue = false;
- ad_data.queue_id = 0;
+ } else if (rule->action == HCLGE_FD_ACTION_SELECT_TC) {
+ ad_data.override_tc = true;
+ ad_data.queue_id =
+ kinfo->tc_info.tqp_offset[rule->tc];
+ ad_data.tc_size =
+ ilog2(kinfo->tc_info.tqp_count[rule->tc]);
In the previous patch you copied this info from mqprio, which is an
egress qdisc feature, this patch is clearly about rx flow director,
I
think the patch is missing some context otherwise it doesn't make
any
sense.
Since tx and rx are in the same tqp, what we do here is to make tx
and
rx in the same tc when rule is hit.
this needs more clarification, even if tx and rx are the same hw
object, AFAIK there is not correlation between mqprio and tc rx
classifiers.
Could comment below make the code more readable?
"Since tx and rx are in the same tqp, if hit rule, forward the packet to
the rx queues pair with specified TC"
} else {
- ad_data.drop_packet = false;
ad_data.forward_to_direct_queue = true;
ad_data.queue_id = rule->queue_id;
}
@@ -5937,7 +5950,7 @@ static int hclge_add_fd_entry(struct
hnae3_handle *handle,
return -EINVAL;
}
- action = HCLGE_FD_ACTION_ACCEPT_PACKET;
+ action = HCLGE_FD_ACTION_SELECT_QUEUE;
q_index = ring;
}
diff --git
a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
index b3c1301..a481064 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
@@ -572,8 +572,9 @@ enum HCLGE_FD_PACKET_TYPE {
};
enum HCLGE_FD_ACTION {
- HCLGE_FD_ACTION_ACCEPT_PACKET,
+ HCLGE_FD_ACTION_SELECT_QUEUE,
HCLGE_FD_ACTION_DROP_PACKET,
+ HCLGE_FD_ACTION_SELECT_TC,
what is SELECT_TC ? you never actually write this value
anywhere in
this patch.
HCLGE_FD_ACTION_SELECT_TC means that the packet will be forwarded
into
the queue of specified TC when rule is hit.
what is "specified TC" in this context ?
TC specified by 'tc flower'
Are we talking about ethtool nfc steering here ? because clearly this
was the purpose of HCLGE_FD_ACTION_ACCEPT_PACKET before it got removed.
In fact, HCLGE_FD_ACTION_ACCEPT_PACKET is splitted in to
HCLGE_FD_ACTION_SELECT_QUEUE and HCLGE_FD_ACTION_SELECT_TC.
HCLGE_FD_ACTION_SELECT_QUEUE is configured by 'ethtool -U' (nfc
steering) or aRFS.
HCLGE_FD_ACTION_SELECT_TC is configured by 'tc flower' so far.
the assignment is in the next patch, maybe these two patch should be
merged for making it more readable.
Thanks.
Huazhong.
.
.
[PATCH v17 0/3] userspace MHI client interface driver
This patch series adds support for UCI driver. UCI driver enables userspace clients to communicate to external MHI devices like modem. UCI driver probe creates standard character device file nodes for userspace clients to perform open, read, write, poll and release file operations. These file operations call MHI core layer APIs to perform data transfer using MHI bus to communicate with MHI device. Currently driver supports QMI channel. libqmi is userspace MHI client which communicates to a QMI service using QMI channel. libqmi is a glib-based library for talking to WWAN modems and devices which speaks QMI protocol. For more information about libqmi please refer https://www.freedesktop.org/wiki/Software/libqmi/. Patch is tested using arm64 and x86 based platform. v17: - Updated commit text for UCI driver by mentioning about libqmi open-source userspace program that will be talking to this UCI kernel driver. - UCI driver depends upon patch "bus: mhi: core: Add helper API to return number of free TREs". v16: - Removed reference of WLAN as an external MHI device in documentation and cover letter. v15: - Updated documentation related to poll and release operations. V14: - Fixed device file node format to /dev/ instead of /dev/mhi_ because "mhi" is already part of mhi device name. For example old format: /dev/mhi_mhi0_QMI new format: /dev/mhi0_QMI. - Updated MHI documentation to reflect index mhi controller name in QMI usage example. V13: - Removed LOOPBACK channel from mhi_device_id table from this patch series. Pushing a new patch series to add support for LOOPBACK channel and the user space test application. Also removed the description from kernel documentation. - Added QMI channel to mhi_device_id table. QMI channel has existing libqmi support from user space. - Updated kernel Documentation for QMI channel and provided external reference for libqmi. - Updated device file node name by appending mhi device name only, which already includes mhi controller device name. V12: - Added loopback test driver under selftest/drivers/mhi. Updated kernel documentation for the usage of the loopback test application. - Addressed review comments for renaming variable names, updated inline comments and removed two redundant dev_dbg. V11: - Fixed review comments for UCI documentation by expanding TLAs and rewording some sentences. V10: - Replaced mutex_lock with mutex_lock_interruptible in read() and write() file ops call back. V9: - Renamed dl_lock to dl_pending _lock and pending list to dl_pending for clarity. - Used read lock to protect cur_buf. - Change transfer status check logic and only consider 0 and -EOVERFLOW as only success. - Added __int to module init function. - Print channel name instead of minor number upon successful probe. V8: - Fixed kernel test robot compilation error by changing %lu to %zu for size_t. - Replaced uci with UCI in Kconfig, commit text, and comments in driver code. - Fixed minor style related comments. V7: - Decoupled uci device and uci channel objects. uci device is associated with device file node. uci channel is associated with MHI channels. uci device refers to uci channel to perform MHI channel operations for device file operations like read() and write(). uci device increments its reference count for every open(). uci device calls mhi_uci_dev_start_chan() to start the MHI channel. uci channel object is tracking number of times MHI channel is referred. This allows to keep the MHI channel in start state until last release() is called. After that uci channel reference count goes to 0 and uci channel clean up is performed which stops the MHI channel. After the last call to release() if driver is removed uci reference count becomes 0 and uci object is cleaned up. - Use separate uci channel read and write lock to fine grain locking between reader and writer. - Use uci device lock to synchronize open, release and driver remove. - Optimize for downlink only or uplink only UCI device. V6: - Moved uci.c to mhi directory. - Updated Kconfig to add module information. - Updated Makefile to rename uci object file name as mhi_uci - Removed kref for open count V5: - Removed mhi_uci_drv structure. - Used idr instead of creating global list of uci devices. - Used kref instead of local ref counting for uci device and open count. - Removed unlikely macro. V4: - Fix locking to protect proper struct members. - Updated documentation describing uci client driver use cases. - Fixed uci ref counting in mhi_uci_open for error case. - Addressed style related review comments. V3: Added documentation for MHI UCI driver. V2: - Added mutex lock to prevent multiple readers to access same - mhi buffer which can result into use after free. Hemant Kumar (3): bus: mhi: core: Move MHI_MAX_MTU to external header file docs: Add documentation for userspace client interface bus: mhi: Add userspace client interface driver
[PATCH v17 1/3] bus: mhi: core: Move MHI_MAX_MTU to external header file
Currently this macro is defined in internal MHI header as
a TRE length mask. Moving it to external header allows MHI
client drivers to set this upper bound for the transmit
buffer size.
Signed-off-by: Hemant Kumar
Reviewed-by: Jeffrey Hugo
Reviewed-by: Manivannan Sadhasivam
---
drivers/bus/mhi/core/internal.h | 1 -
include/linux/mhi.h | 3 +++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
index 6f80ec3..2b9c063 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -453,7 +453,6 @@ enum mhi_pm_state {
#define CMD_EL_PER_RING128
#define PRIMARY_CMD_RING 0
#define MHI_DEV_WAKE_DB127
-#define MHI_MAX_MTU0x
#define MHI_RANDOM_U32_NONZERO(bmsk) (prandom_u32_max(bmsk) + 1)
enum mhi_er_type {
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index e36d575..f072605 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -15,6 +15,9 @@
#include
#include
+/* MHI client drivers to set this upper bound for tx buffer */
+#define MHI_MAX_MTU 0x
+
#define MHI_MAX_OEM_PK_HASH_SEGMENTS 16
struct mhi_chan;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v17 2/3] docs: Add documentation for userspace client interface
MHI userspace client driver is creating device file node for user application to perform file operations. File operations are handled by MHI core driver. Currently QMI MHI channel is supported by this driver. Signed-off-by: Hemant Kumar Reviewed-by: Jeffrey Hugo --- Documentation/mhi/index.rst | 1 + Documentation/mhi/uci.rst | 95 + 2 files changed, 96 insertions(+) create mode 100644 Documentation/mhi/uci.rst diff --git a/Documentation/mhi/index.rst b/Documentation/mhi/index.rst index 1d8dec3..c75a371 100644 --- a/Documentation/mhi/index.rst +++ b/Documentation/mhi/index.rst @@ -9,6 +9,7 @@ MHI mhi topology + uci .. only:: subproject and html diff --git a/Documentation/mhi/uci.rst b/Documentation/mhi/uci.rst new file mode 100644 index 000..1e0a015 --- /dev/null +++ b/Documentation/mhi/uci.rst @@ -0,0 +1,95 @@ +.. SPDX-License-Identifier: GPL-2.0 + += +Userspace Client Interface (UCI) += + +UCI driver enables userspace clients to communicate to external MHI devices +like modem. UCI driver probe creates standard character device file nodes for +userspace clients to perform open, read, write, poll and release file +operations. UCI device object represents UCI device file node which gets +instantiated as part of MHI UCI driver probe. UCI channel object represents +MHI uplink or downlink channel. + +Operations +== + +open + + +Instantiates UCI channel object and starts MHI channels to move it to running +state. Inbound buffers are queued to downlink channel transfer ring. Every +subsequent open() increments UCI device reference count as well as UCI channel +reference count. + +read + + +When data transfer is completed on downlink channel, transfer ring element +buffer is copied to pending list. Reader is unblocked and data is copied to +userspace buffer. Transfer ring element buffer is queued back to downlink +channel transfer ring. + +write +- + +Write buffer is queued to uplink channel transfer ring if ring is not full. Upon +uplink transfer completion buffer is freed. + +poll + + +Returns EPOLLIN | EPOLLRDNORM mask if pending list has buffers to be read by +userspace. Returns EPOLLOUT | EPOLLWRNORM mask if MHI uplink channel transfer +ring is not empty. When the uplink channel transfer ring is non-empty, more +data may be sent to the device. Returns EPOLLERR when UCI driver is removed. + +release +--- + +Decrements UCI device reference count and UCI channel reference count. Upon +last release() UCI channel clean up is performed. MHI channel moves to disable +state and inbound buffers are freed. + +Usage += + +Device file node is created with format:- + +/dev/ + +mhi_device_name includes mhi controller name and the name of the MHI channel +being used by MHI client in userspace to send or receive data using MHI +protocol. + +There is a separate character device file node created for each channel +specified in MHI device id table. MHI channels are statically defined by MHI +specification. The list of supported channels is in the channel list variable +of mhi_device_id table in UCI driver. + +Qualcomm MSM Interface(QMI) Channel +--- + +Qualcomm MSM Interface(QMI) is a modem control messaging protocol used to +communicate between software components in the modem and other peripheral +subsystems. QMI communication is of request/response type or an unsolicited +event type. libqmi is userspace MHI client which communicates to a QMI service +using UCI device. It sends a QMI request to a QMI service using MHI channel 14 +or 16. QMI response is received using MHI channel 15 or 17 respectively. libqmi +is a glib-based library for talking to WWAN modems and devices which speaks QMI +protocol. For more information about libqmi please refer +https://www.freedesktop.org/wiki/Software/libqmi/ + +Usage Example +~ + +QMI command to retrieve device mode +$ sudo qmicli -d /dev/mhi0_QMI --dms-get-model +[/dev/mhi0_QMI] Device model retrieved: +Model: 'FN980m' + +Other Use Cases +--- + +Getting MHI device specific diagnostics information to userspace MHI diagnostic +client using DIAG channel 4 (Host to device) and 5 (Device to Host). -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v17 3/3] bus: mhi: Add userspace client interface driver
This MHI client driver allows userspace clients to transfer
raw data between MHI device and host using standard file operations.
Driver instantiates UCI device object which is associated to device
file node. UCI device object instantiates UCI channel object when device
file node is opened. UCI channel object is used to manage MHI channels
by calling MHI core APIs for read and write operations. MHI channels
are started as part of device open(). MHI channels remain in start
state until last release() is called on UCI device file node. Device
file node is created with format
/dev/
Currently it supports QMI channel. libqmi is userspace MHI client which
communicates to a QMI service using QMI channel. libqmi is a glib-based
library for talking to WWAN modems and devices which speaks QMI protocol.
For more information about libqmi please refer
https://www.freedesktop.org/wiki/Software/libqmi/
Signed-off-by: Hemant Kumar
Reviewed-by: Manivannan Sadhasivam
Reviewed-by: Jeffrey Hugo
Tested-by: Loic Poulain
---
drivers/bus/mhi/Kconfig | 13 +
drivers/bus/mhi/Makefile | 3 +
drivers/bus/mhi/uci.c| 664 +++
3 files changed, 680 insertions(+)
create mode 100644 drivers/bus/mhi/uci.c
diff --git a/drivers/bus/mhi/Kconfig b/drivers/bus/mhi/Kconfig
index da5cd0c..5194e8e 100644
--- a/drivers/bus/mhi/Kconfig
+++ b/drivers/bus/mhi/Kconfig
@@ -29,3 +29,16 @@ config MHI_BUS_PCI_GENERIC
This driver provides MHI PCI controller driver for devices such as
Qualcomm SDX55 based PCIe modems.
+config MHI_UCI
+ tristate "MHI UCI"
+ depends on MHI_BUS
+ help
+ MHI based Userspace Client Interface (UCI) driver is used for
+ transferring raw data between host and device using standard file
+ operations from userspace. Open, read, write, poll and close
+ operations are supported by this driver. Please check
+ mhi_uci_match_table for all supported channels that are exposed to
+ userspace.
+
+ To compile this driver as a module, choose M here: the module will be
+ called mhi_uci.
diff --git a/drivers/bus/mhi/Makefile b/drivers/bus/mhi/Makefile
index 0a2d778..69f2111 100644
--- a/drivers/bus/mhi/Makefile
+++ b/drivers/bus/mhi/Makefile
@@ -4,3 +4,6 @@ obj-y += core/
obj-$(CONFIG_MHI_BUS_PCI_GENERIC) += mhi_pci_generic.o
mhi_pci_generic-y += pci_generic.o
+# MHI client
+mhi_uci-y := uci.o
+obj-$(CONFIG_MHI_UCI) += mhi_uci.o
diff --git a/drivers/bus/mhi/uci.c b/drivers/bus/mhi/uci.c
new file mode 100644
index 000..1df2377
--- /dev/null
+++ b/drivers/bus/mhi/uci.c
@@ -0,0 +1,664 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright (c) 2018-2020, The Linux Foundation. All rights reserved.*/
+
+#include
+#include
+#include
+#include
+#include
+
+#define MHI_UCI_DRIVER_NAME "mhi_uci"
+#define MHI_MAX_UCI_MINORS 128
+
+static DEFINE_IDR(uci_idr);
+static DEFINE_MUTEX(uci_drv_mutex);
+static struct class *uci_dev_class;
+static int uci_dev_major;
+
+/**
+ * struct uci_chan - MHI channel for a UCI device
+ * @udev: associated UCI device object
+ * @ul_wq: wait queue for writer
+ * @write_lock: mutex write lock for ul channel
+ * @dl_wq: wait queue for reader
+ * @read_lock: mutex read lock for dl channel
+ * @dl_pending_lock: spin lock for dl_pending list
+ * @dl_pending: list of dl buffers userspace is waiting to read
+ * @cur_buf: current buffer userspace is reading
+ * @dl_size: size of the current dl buffer userspace is reading
+ * @ref_count: uci_chan reference count
+ */
+struct uci_chan {
+ struct uci_dev *udev;
+ wait_queue_head_t ul_wq;
+
+ /* ul channel lock to synchronize multiple writes */
+ struct mutex write_lock;
+
+ wait_queue_head_t dl_wq;
+
+ /* dl channel lock to synchronize multiple reads */
+ struct mutex read_lock;
+
+ /*
+* protects pending list in bh context, channel release, read and
+* poll
+*/
+ spinlock_t dl_pending_lock;
+
+ struct list_head dl_pending;
+ struct uci_buf *cur_buf;
+ size_t dl_size;
+ struct kref ref_count;
+};
+
+/**
+ * struct uci_buf - UCI buffer
+ * @data: data buffer
+ * @len: length of data buffer
+ * @node: list node of the UCI buffer
+ */
+struct uci_buf {
+ void *data;
+ size_t len;
+ struct list_head node;
+};
+
+/**
+ * struct uci_dev - MHI UCI device
+ * @minor: UCI device node minor number
+ * @mhi_dev: associated mhi device object
+ * @uchan: UCI uplink and downlink channel object
+ * @mtu: max TRE buffer length
+ * @enabled: Flag to track the state of the UCI device
+ * @lock: mutex lock to manage uchan object
+ * @ref_count: uci_dev reference count
+ */
+struct uci_dev {
+ unsigned int minor;
+ struct mhi_device *mhi_dev;
+ struct uci_chan *uchan;
+ size_t mtu;
+ bool enabled;
+
+ /* synchronize open, release and driver remove */
+ struct mutex lock;
+
[PATCH] x86/kprobes: Fix optprobe to detect padding int3 correctly
Fix optprobe to detect padding int3 correctly.
Since commit 7705dc855797 ("x86/vmlinux: Use INT3 instead of NOP
for linker fill bytes") changed the padding bytes between functions
from nop to int3, when optprobe decodes a target function it finds
int3 and gives up the jump optimization.
Instead of giving up any int3 detection, this checks whether the
rest of bytes to the end of the function are int3 or not. If all
of those are int3, those come from the linker. In that case,
optprobe continues jump optimization.
Fixes: 7705dc855797 ("x86/vmlinux: Use INT3 instead of NOP for linker fill
bytes")
Cc: sta...@vger.kernel.org
Reported-by: Adam Zabrocki
Signed-off-by: Masami Hiramatsu
---
arch/x86/kernel/kprobes/opt.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
index 041f0b50bc27..b5cf39f1a855 100644
--- a/arch/x86/kernel/kprobes/opt.c
+++ b/arch/x86/kernel/kprobes/opt.c
@@ -272,6 +272,19 @@ static int insn_is_indirect_jump(struct insn *insn)
return ret;
}
+static bool is_padding_int3(unsigned long addr, unsigned long eaddr)
+{
+ unsigned char ops;
+
+ for (; addr < eaddr; addr++) {
+ if (get_kernel_nofault(ops, (void *)addr) < 0 ||
+ ops != INT3_INSN_OPCODE)
+ return false;
+ }
+
+ return true;
+}
+
/* Decode whole function to ensure any instructions don't jump into target */
static int can_optimize(unsigned long paddr)
{
@@ -310,9 +323,14 @@ static int can_optimize(unsigned long paddr)
return 0;
kernel_insn_init(, (void *)recovered_insn, MAX_INSN_SIZE);
insn_get_length();
- /* Another subsystem puts a breakpoint */
+ /*
+* In the case of detecting unknown breakpoint, this could be
+* a padding int3 between functions. Let's check that all the
+* rest of the bytes are also int3.
+*/
if (insn.opcode.bytes[0] == INT3_INSN_OPCODE)
- return 0;
+ return is_padding_int3(addr, paddr - offset + size) ? 1
: 0;
+
/* Recover address */
insn.kaddr = (void *)addr;
insn.next_byte = (void *)(addr + insn.length);
[PATCH] drm/hisilicon: Add the CONFIG_PM_SLEEP
add the CONFIG_PM_SLEEP to isolate the function of resume and suspend.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 7e91ef1..faa664d 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -65,6 +65,7 @@ static const struct drm_driver hibmc_driver = {
.irq_handler= hibmc_drm_interrupt,
};
+#ifdef CONFIG_PM_SLEEP
static int __maybe_unused hibmc_pm_suspend(struct device *dev)
{
struct drm_device *drm_dev = dev_get_drvdata(dev);
@@ -78,6 +79,7 @@ static int __maybe_unused hibmc_pm_resume(struct device *dev)
return drm_mode_config_helper_resume(drm_dev);
}
+#endif
static const struct dev_pm_ops hibmc_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(hibmc_pm_suspend,
--
2.7.4
Re: [PATCH v3 sl-b 1/6] mm: Add mem_dump_obj() to print source of memory block
On Thu, Dec 10, 2020 at 07:42:27PM -0800, Paul E. McKenney wrote: > On Thu, Dec 10, 2020 at 07:33:59PM -0800, Paul E. McKenney wrote: > > On Fri, Dec 11, 2020 at 11:22:10AM +0900, Joonsoo Kim wrote: > > > On Thu, Dec 10, 2020 at 05:19:58PM -0800, paul...@kernel.org wrote: > > > > From: "Paul E. McKenney" > > [ . . . ] > > > > We can get some infos even if CONFIG_SLUB_DEBUG isn't defined. > > > Please move them out. > > > > I guess since I worry about CONFIG_MMU=n it only makes sense to also > > worry about CONFIG_SLUB_DEBUG=n. Fix update. > > Like this? (Patch on top of the series, to be folded into the first one.) Yes! Acked-by: Joonsoo Kim Thanks.
Re: [PATCH net-next 2/7] net: hns3: add support for tc mqprio offload
On 2020/12/11 4:24, Saeed Mahameed wrote:
On Thu, 2020-12-10 at 20:27 +0800, tanhuazhong wrote:
On 2020/12/10 12:50, Saeed Mahameed wrote:
On Thu, 2020-12-10 at 11:42 +0800, Huazhong Tan wrote:
From: Jian Shen
Currently, the HNS3 driver only supports offload for tc number
and prio_tc. This patch adds support for other qopts, including
queues count and offset for each tc.
When enable tc mqprio offload, it's not allowed to change
queue numbers by ethtool. For hardware limitation, the queue
number of each tc should be power of 2.
For the queues is not assigned to each tc by average, so it's
should return vport->alloc_tqps for hclge_get_max_channels().
The commit message needs some improvements, it is not really clear
what
the last two sentences are about.
The hclge_get_max_channels() returns the max queue number of each TC
for
user can set by command ethool -L. In previous implement, the queues
are
assigned to each TC by average, so we return it by vport-:
alloc_tqps / num_tc. And now we can assign differrent queue number
for
each TC, so it shouldn't be divided by num_tc.
What do you mean by "queues assigned to each tc by average" ?
In previous implement the number of queue in each TC is same, now, we
allow that the number of queue in each TC is different.
[...]
+ }
+ if (hdev->vport[0].alloc_tqps < queue_sum) {
can't you just allocate new tqps according to the new mqprio input
like
other drivers do ? how the user allocates those tqps ?
maybe the name of 'alloc_tqps' is a little bit misleading, the
meaning
of this field is the total number of the available tqps in this
vport.
from your driver code it seems alloc_tqps is number of rings allocated
via ethool -L.
My point is, it seems like in this patch you demand for the queues to
be preallocated, but what other drivers do on setup tc, they just
duplicate what ever number of queues was configured prior to setup tc,
num_tc times.
The maximum number of queues is defined by 'alloc_tqps', not
preallocated queues. The behavior on setup tc of HNS3 is same as other
driver.
'alloc_tqps' in HNS3 has the same means as 'num_queue_pairs' in i40e below
if (vsi->num_queue_pairs <
(mqprio_qopt->qopt.offset[i] + mqprio_qopt->qopt.count[i])) {
return -EINVAL;
}
+ dev_err(>pdev->dev,
+ "qopt queue count sum should be less than
%u\n",
+ hdev->vport[0].alloc_tqps);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static void hclge_sync_mqprio_qopt(struct hnae3_tc_info
*tc_info,
+ struct tc_mqprio_qopt_offload
*mqprio_qopt)
+{
+ int i;
+
+ memset(tc_info, 0, sizeof(*tc_info));
+ tc_info->num_tc = mqprio_qopt->qopt.num_tc;
+ memcpy(tc_info->prio_tc, mqprio_qopt->qopt.prio_tc_map,
+ sizeof_field(struct hnae3_tc_info, prio_tc));
+ memcpy(tc_info->tqp_count, mqprio_qopt->qopt.count,
+ sizeof_field(struct hnae3_tc_info, tqp_count));
+ memcpy(tc_info->tqp_offset, mqprio_qopt->qopt.offset,
+ sizeof_field(struct hnae3_tc_info, tqp_offset));
+
isn't it much easier to just store a copy of tc_mqprio_qopt in you
tc_info and then just:
tc_info->qopt = mqprio->qopt;
[...]
The tc_mqprio_qopt_offload still contains a lot of opt hns3 driver
does
not use yet, even if the hns3 use all the opt, I still think it is
better to create our own struct, if struct tc_mqprio_qopt_offload
changes in the future, we can limit the change to the
tc_mqprio_qopt_offload convertion.
ok.
Thanks.
Huazhong.
.
[PATCH] nvmet: fix mismatched serial
Target side uses 'bin2hex' to convert u64 serial number to a hex
string, saving serial number as be64 to keep right byte order.
Test on x86 server, config '0123456789abcdef' to 'attr_serial' on
target side, and run 'nvme id-ctrl /dev/nvme0' on initiator side,
then we can get the same SN string.
Signed-off-by: zhenwei pi
---
drivers/nvme/target/configfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/nvme/target/configfs.c b/drivers/nvme/target/configfs.c
index 37e1d7784e17..e7808a86ccef 100644
--- a/drivers/nvme/target/configfs.c
+++ b/drivers/nvme/target/configfs.c
@@ -997,7 +997,7 @@ static ssize_t nvmet_subsys_attr_serial_show(struct
config_item *item,
{
struct nvmet_subsys *subsys = to_subsys(item);
- return snprintf(page, PAGE_SIZE, "%llx\n", subsys->serial);
+ return snprintf(page, PAGE_SIZE, "%llx\n", be64_to_cpu(subsys->serial));
}
static ssize_t nvmet_subsys_attr_serial_store(struct config_item *item,
@@ -1009,7 +1009,7 @@ static ssize_t nvmet_subsys_attr_serial_store(struct
config_item *item,
return -EINVAL;
down_write(_config_sem);
- to_subsys(item)->serial = serial;
+ to_subsys(item)->serial = cpu_to_be64(serial);
up_write(_config_sem);
return count;
--
2.25.1
Re: [PATCH v3 sl-b 1/6] mm: Add mem_dump_obj() to print source of memory block
On Thu, Dec 10, 2020 at 07:33:59PM -0800, Paul E. McKenney wrote:
> On Fri, Dec 11, 2020 at 11:22:10AM +0900, Joonsoo Kim wrote:
> > On Thu, Dec 10, 2020 at 05:19:58PM -0800, paul...@kernel.org wrote:
> > > From: "Paul E. McKenney"
> > >
> > > There are kernel facilities such as per-CPU reference counts that give
> > > error messages in generic handlers or callbacks, whose messages are
> > > unenlightening. In the case of per-CPU reference-count underflow, this
> > > is not a problem when creating a new use of this facility because in that
> > > case the bug is almost certainly in the code implementing that new use.
> > > However, trouble arises when deploying across many systems, which might
> > > exercise corner cases that were not seen during development and testing.
> > > Here, it would be really nice to get some kind of hint as to which of
> > > several uses the underflow was caused by.
> > >
> > > This commit therefore exposes a mem_dump_obj() function that takes
> > > a pointer to memory (which must still be allocated if it has been
> > > dynamically allocated) and prints available information on where that
> > > memory came from. This pointer can reference the middle of the block as
> > > well as the beginning of the block, as needed by things like RCU callback
> > > functions and timer handlers that might not know where the beginning of
> > > the memory block is. These functions and handlers can use mem_dump_obj()
> > > to print out better hints as to where the problem might lie.
> > >
> > > The information printed can depend on kernel configuration. For example,
> > > the allocation return address can be printed only for slab and slub,
> > > and even then only when the necessary debug has been enabled. For slab,
> > > build with CONFIG_DEBUG_SLAB=y, and either use sizes with ample space
> > > to the next power of two or use the SLAB_STORE_USER when creating the
> > > kmem_cache structure. For slub, build with CONFIG_SLUB_DEBUG=y and
> > > boot with slub_debug=U, or pass SLAB_STORE_USER to kmem_cache_create()
> > > if more focused use is desired. Also for slub, use CONFIG_STACKTRACE
> > > to enable printing of the allocation-time stack trace.
> > >
> > > Cc: Christoph Lameter
> > > Cc: Pekka Enberg
> > > Cc: David Rientjes
> > > Cc: Joonsoo Kim
> > > Cc: Andrew Morton
> > > Cc:
> > > Reported-by: Andrii Nakryiko
> > > [ paulmck: Convert to printing and change names per Joonsoo Kim. ]
> > > [ paulmck: Move slab definition per Stephen Rothwell and kbuild test
> > > robot. ]
> > > [ paulmck: Handle CONFIG_MMU=n case where vmalloc() is kmalloc(). ]
> > > [ paulmck: Apply Vlastimil Babka feedback on slab.c kmem_provenance(). ]
> > > Signed-off-by: Paul E. McKenney
> > > ---
> > > include/linux/mm.h | 2 ++
> > > include/linux/slab.h | 2 ++
> > > mm/slab.c| 20 ++
> > > mm/slab.h| 12 +
> > > mm/slab_common.c | 74
> > >
> > > mm/slob.c| 6 +
> > > mm/slub.c| 36 +
> > > mm/util.c| 24 +
> > > 8 files changed, 176 insertions(+)
> > >
> > > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > > index ef360fe..1eea266 100644
> > > --- a/include/linux/mm.h
> > > +++ b/include/linux/mm.h
> > > @@ -3153,5 +3153,7 @@ unsigned long wp_shared_mapping_range(struct
> > > address_space *mapping,
> > >
> > > extern int sysctl_nr_trim_pages;
> > >
> > > +void mem_dump_obj(void *object);
> > > +
> > > #endif /* __KERNEL__ */
> > > #endif /* _LINUX_MM_H */
> > > diff --git a/include/linux/slab.h b/include/linux/slab.h
> > > index dd6897f..169b511 100644
> > > --- a/include/linux/slab.h
> > > +++ b/include/linux/slab.h
> > > @@ -186,6 +186,8 @@ void kfree(const void *);
> > > void kfree_sensitive(const void *);
> > > size_t __ksize(const void *);
> > > size_t ksize(const void *);
> > > +bool kmem_valid_obj(void *object);
> > > +void kmem_dump_obj(void *object);
> > >
> > > #ifdef CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR
> > > void __check_heap_object(const void *ptr, unsigned long n, struct page
> > > *page,
> > > diff --git a/mm/slab.c b/mm/slab.c
> > > index b111356..66f00ad 100644
> > > --- a/mm/slab.c
> > > +++ b/mm/slab.c
> > > @@ -3633,6 +3633,26 @@ void *__kmalloc_node_track_caller(size_t size,
> > > gfp_t flags,
> > > EXPORT_SYMBOL(__kmalloc_node_track_caller);
> > > #endif /* CONFIG_NUMA */
> > >
> > > +void kmem_obj_info(struct kmem_obj_info *kpp, void *object, struct page
> > > *page)
> > > +{
> > > + struct kmem_cache *cachep;
> > > + unsigned int objnr;
> > > + void *objp;
> > > +
> > > + kpp->kp_ptr = object;
> > > + kpp->kp_page = page;
> > > + cachep = page->slab_cache;
> > > + kpp->kp_slab_cache = cachep;
> > > + objp = object - obj_offset(cachep);
> > > + kpp->kp_data_offset = obj_offset(cachep);
> > > + page = virt_to_head_page(objp);
> > > + objnr =
[PATCH] fs: ext4: remove unnecessary wbc parameter from ext4_bio_write_page
From: Lei Chen
ext4_bio_write_page does not need wbc parameter, since its parameter
io contains the io_wbc field. The io::io_wbc is initialized by
ext4_io_submit_init which is called in ext4_writepages and
ext4_writepage functions prior to ext4_bio_write_page.
Therefor, when ext4_bio_write_page is called, wbc info
has already been included in io parameter.
Signed-off-by: Lei Chen
---
fs/ext4/ext4.h| 1 -
fs/ext4/inode.c | 4 ++--
fs/ext4/page-io.c | 2 +-
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index cd95965..1385898 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -3638,7 +3638,6 @@ extern void ext4_io_submit_init(struct ext4_io_submit *io,
extern int ext4_bio_write_page(struct ext4_io_submit *io,
struct page *page,
int len,
- struct writeback_control *wbc,
bool keep_towrite);
extern struct ext4_io_end_vec *ext4_alloc_io_end_vec(ext4_io_end_t *io_end);
extern struct ext4_io_end_vec *ext4_last_io_end_vec(ext4_io_end_t *io_end);
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index b147c2e..7360e7a 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -2055,7 +2055,7 @@ static int ext4_writepage(struct page *page,
unlock_page(page);
return -ENOMEM;
}
- ret = ext4_bio_write_page(_submit, page, len, wbc, keep_towrite);
+ ret = ext4_bio_write_page(_submit, page, len, keep_towrite);
ext4_io_submit(_submit);
/* Drop io_end reference we got from init */
ext4_put_io_end_defer(io_submit.io_end);
@@ -2089,7 +2089,7 @@ static int mpage_submit_page(struct mpage_da_data *mpd,
struct page *page)
len = size & ~PAGE_MASK;
else
len = PAGE_SIZE;
- err = ext4_bio_write_page(>io_submit, page, len, mpd->wbc, false);
+ err = ext4_bio_write_page(>io_submit, page, len, false);
if (!err)
mpd->wbc->nr_to_write--;
mpd->first_page++;
diff --git a/fs/ext4/page-io.c b/fs/ext4/page-io.c
index cb135a9..03a44a0 100644
--- a/fs/ext4/page-io.c
+++ b/fs/ext4/page-io.c
@@ -435,7 +435,6 @@ static void io_submit_add_bh(struct ext4_io_submit *io,
int ext4_bio_write_page(struct ext4_io_submit *io,
struct page *page,
int len,
- struct writeback_control *wbc,
bool keep_towrite)
{
struct page *bounce_page = NULL;
@@ -445,6 +444,7 @@ int ext4_bio_write_page(struct ext4_io_submit *io,
int ret = 0;
int nr_submitted = 0;
int nr_to_submit = 0;
+ struct writeback_control *wbc = io->io_wbc;
BUG_ON(!PageLocked(page));
BUG_ON(PageWriteback(page));
--
1.8.3.1
[PATCH RESEND v8 1/4] input: elants: document some registers and values
Add information found in downstream kernels, to make the code less
magic.
Signed-off-by: Michał Mirosław
Reviewed-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
---
drivers/input/touchscreen/elants_i2c.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/input/touchscreen/elants_i2c.c
b/drivers/input/touchscreen/elants_i2c.c
index 50c348297e38..d51cb910fba1 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -82,7 +82,7 @@
#define HEADER_REPORT_10_FINGER0x62
-/* Header (4 bytes) plus 3 fill 10-finger packets */
+/* Header (4 bytes) plus 3 full 10-finger packets */
#define MAX_PACKET_SIZE169
#define BOOT_TIME_DELAY_MS 50
@@ -97,6 +97,10 @@
#define E_INFO_PHY_SCAN0xD7
#define E_INFO_PHY_DRIVER 0xD8
+/* FW write command, 0x54 0x?? 0x0, 0x01 */
+#define E_POWER_STATE_SLEEP0x50
+#define E_POWER_STATE_RESUME 0x58
+
#define MAX_RETRIES3
#define MAX_FW_UPDATE_RETRIES 30
@@ -269,8 +273,8 @@ static int elants_i2c_calibrate(struct elants_data *ts)
{
struct i2c_client *client = ts->client;
int ret, error;
- static const u8 w_flashkey[] = { 0x54, 0xC0, 0xE1, 0x5A };
- static const u8 rek[] = { 0x54, 0x29, 0x00, 0x01 };
+ static const u8 w_flashkey[] = { CMD_HEADER_WRITE, 0xC0, 0xE1, 0x5A };
+ static const u8 rek[] = { CMD_HEADER_WRITE, 0x29, 0x00, 0x01 };
static const u8 rek_resp[] = { CMD_HEADER_REK, 0x66, 0x66, 0x66 };
disable_irq(client->irq);
@@ -1388,7 +1392,9 @@ static int __maybe_unused elants_i2c_suspend(struct
device *dev)
{
struct i2c_client *client = to_i2c_client(dev);
struct elants_data *ts = i2c_get_clientdata(client);
- const u8 set_sleep_cmd[] = { 0x54, 0x50, 0x00, 0x01 };
+ const u8 set_sleep_cmd[] = {
+ CMD_HEADER_WRITE, E_POWER_STATE_SLEEP, 0x00, 0x01
+ };
int retry_cnt;
int error;
@@ -1425,7 +1431,9 @@ static int __maybe_unused elants_i2c_resume(struct device
*dev)
{
struct i2c_client *client = to_i2c_client(dev);
struct elants_data *ts = i2c_get_clientdata(client);
- const u8 set_active_cmd[] = { 0x54, 0x58, 0x00, 0x01 };
+ const u8 set_active_cmd[] = {
+ CMD_HEADER_WRITE, E_POWER_STATE_RESUME, 0x00, 0x01
+ };
int retry_cnt;
int error;
--
2.20.1
[PATCH RESEND v8 4/4] input: elants: support 0x66 reply opcode for reporting touches
From: Dmitry Osipenko
eKTF3624 touchscreen firmware uses two variants of the reply opcodes for
reporting touch events: one is 0x63 (used by older firmware) and other is
0x66 (used by newer firmware). The 0x66 variant is equal to 0x63 of
eKTH3500, while 0x63 needs small adjustment of the touch pressure value.
Nexus 7 tablet device has eKTF3624 touchscreen and it uses 0x66 opcode for
reporting touch events, let's support it now. Other devices, eg. ASUS TF300T,
use 0x63.
Note: CMD_HEADER_REK is used for replying to calibration requests, it has
the same 0x66 opcode number which eKTF3624 uses for reporting touches.
The calibration replies are handled separately from the the rest of the
commands in the driver by entering into ELAN_WAIT_RECALIBRATION state
and thus this change shouldn't change the old behavior.
Signed-off-by: Dmitry Osipenko
Tested-by: Michał Mirosław
Signed-off-by: Michał Mirosław
---
drivers/input/touchscreen/elants_i2c.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/elants_i2c.c
b/drivers/input/touchscreen/elants_i2c.c
index c24d8cdc4251..1cbda6f20d07 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -61,6 +61,15 @@
#define QUEUE_HEADER_NORMAL0X63
#define QUEUE_HEADER_WAIT 0x64
+/*
+ * Depending on firmware version, eKTF3624 touchscreens may utilize one of
+ * these opcodes for the touch events: 0x63 and 0x66. The 0x63 is used by
+ * older firmware version and differs from 0x66 such that touch pressure
+ * value needs to be adjusted. The 0x66 opcode of newer firmware is equal
+ * to 0x63 of eKTH3500.
+ */
+#define QUEUE_HEADER_NORMAL2 0x66
+
/* Command header definition */
#define CMD_HEADER_WRITE 0x54
#define CMD_HEADER_READ0x53
@@ -1052,7 +1061,6 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
switch (ts->buf[FW_HDR_TYPE]) {
case CMD_HEADER_HELLO:
case CMD_HEADER_RESP:
- case CMD_HEADER_REK:
break;
case QUEUE_HEADER_WAIT:
@@ -1072,6 +1080,7 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
break;
case QUEUE_HEADER_NORMAL:
+ case QUEUE_HEADER_NORMAL2:
report_count = ts->buf[FW_HDR_COUNT];
if (report_count == 0 || report_count > 3) {
dev_err(>dev,
--
2.20.1
[PATCH RESEND v8 3/4] input: elants: read touchscreen size for EKTF3624
EKTF3624 as present in Asus TF300T tablet has touchscreen size encoded
in different registers.
Signed-off-by: Michał Mirosław
Reviewed-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
---
drivers/input/touchscreen/elants_i2c.c | 84 --
1 file changed, 79 insertions(+), 5 deletions(-)
diff --git a/drivers/input/touchscreen/elants_i2c.c
b/drivers/input/touchscreen/elants_i2c.c
index f1bf3e000e96..c24d8cdc4251 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -35,7 +35,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -43,6 +43,10 @@
/* Device, Driver information */
#define DEVICE_NAME"elants_i2c"
+/* Device IDs */
+#define EKTH3500 0
+#define EKTF3624 1
+
/* Convert from rows or columns into resolution */
#define ELAN_TS_RESOLUTION(n, m) (((n) - 1) * (m))
@@ -94,6 +98,8 @@
#define E_ELAN_INFO_REK0xD0
#define E_ELAN_INFO_TEST_VER 0xE0
#define E_ELAN_INFO_FW_ID 0xF0
+#define E_INFO_X_RES 0x60
+#define E_INFO_Y_RES 0x63
#define E_INFO_OSR 0xD6
#define E_INFO_PHY_SCAN0xD7
#define E_INFO_PHY_DRIVER 0xD8
@@ -157,6 +163,7 @@ struct elants_data {
bool wake_irq_enabled;
bool keep_power_in_suspend;
+ u8 chip_id;
/* Must be last to be used for DMA operations */
u8 buf[MAX_PACKET_SIZE] cacheline_aligned;
@@ -434,7 +441,58 @@ static int elants_i2c_query_bc_version(struct elants_data
*ts)
return 0;
}
-static int elants_i2c_query_ts_info(struct elants_data *ts)
+static int elants_i2c_query_ts_info_ektf(struct elants_data *ts)
+{
+ struct i2c_client *client = ts->client;
+ int error;
+ u8 resp[4];
+ u16 phy_x, phy_y;
+ const u8 get_xres_cmd[] = {
+ CMD_HEADER_READ, E_INFO_X_RES, 0x00, 0x00
+ };
+ const u8 get_yres_cmd[] = {
+ CMD_HEADER_READ, E_INFO_Y_RES, 0x00, 0x00
+ };
+
+ /* Get X/Y size in mm */
+ error = elants_i2c_execute_command(client, get_xres_cmd,
+ sizeof(get_xres_cmd),
+ resp, sizeof(resp), 1,
+ "get X size");
+ if (error)
+ return error;
+
+ phy_x = resp[2] | ((resp[3] & 0xF0) << 4);
+
+ error = elants_i2c_execute_command(client, get_yres_cmd,
+ sizeof(get_yres_cmd),
+ resp, sizeof(resp), 1,
+ "get Y size");
+ if (error)
+ return error;
+
+ phy_y = resp[2] | ((resp[3] & 0xF0) << 4);
+
+ if (!phy_x || !phy_y) {
+ dev_warn(>dev,
+"invalid size data: %d x %d mm\n",
+phy_x, phy_y);
+ return 0;
+ }
+
+ dev_dbg(>dev, "phy_x=%d, phy_y=%d\n", phy_x, phy_y);
+
+ /* calculate resolution from size */
+ ts->x_max = 2240-1;
+ ts->x_res = DIV_ROUND_CLOSEST(ts->prop.max_x, phy_x);
+
+ ts->y_max = 1408-1;
+ ts->y_res = DIV_ROUND_CLOSEST(ts->prop.max_y, phy_y);
+
+ return 0;
+}
+
+static int elants_i2c_query_ts_info_ekth(struct elants_data *ts)
{
struct i2c_client *client = ts->client;
int error;
@@ -588,8 +646,20 @@ static int elants_i2c_initialize(struct elants_data *ts)
error = elants_i2c_query_fw_version(ts);
if (!error)
error = elants_i2c_query_test_version(ts);
- if (!error)
- error = elants_i2c_query_ts_info(ts);
+
+ switch (ts->chip_id) {
+ case EKTH3500:
+ if (!error)
+ error = elants_i2c_query_ts_info_ekth(ts);
+ break;
+ case EKTF3624:
+ if (!error)
+ error = elants_i2c_query_ts_info_ektf(ts);
+ break;
+ default:
+ unreachable();
+ break;
+ }
if (error)
ts->iap_mode = ELAN_IAP_RECOVERY;
@@ -1266,6 +1336,9 @@ static int elants_i2c_probe(struct i2c_client *client,
ts->client = client;
i2c_set_clientdata(client, ts);
+ if (client->dev.of_node)
+ ts->chip_id = (uintptr_t)of_device_get_match_data(>dev);
+
ts->vcc33 = devm_regulator_get(>dev, "vcc33");
if (IS_ERR(ts->vcc33)) {
error = PTR_ERR(ts->vcc33);
@@ -1495,7 +1568,8 @@ MODULE_DEVICE_TABLE(acpi, elants_acpi_id);
#ifdef CONFIG_OF
static const struct of_device_id elants_of_match[] = {
- { .compatible = "elan,ekth3500" },
+ { .compatible = "elan,ekth3500", .data = (void *)EKTH3500 },
+ { .compatible = "elan,ektf3624", .data = (void *)EKTF3624 },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, elants_of_match);
--
[PATCH RESEND v8 2/4] input: elants: support old touch report format
Support ELAN touchpad sensor with older firmware as found on eg. Asus
Transformer Pads.
Signed-off-by: Michał Mirosław
Reviewed-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
---
drivers/input/touchscreen/elants_i2c.c | 36 ++
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/drivers/input/touchscreen/elants_i2c.c
b/drivers/input/touchscreen/elants_i2c.c
index d51cb910fba1..f1bf3e000e96 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -69,6 +69,7 @@
#define CMD_HEADER_REK 0x66
/* FW position data */
+#define PACKET_SIZE_OLD40
#define PACKET_SIZE55
#define MAX_CONTACT_NUM10
#define FW_POS_HEADER 0
@@ -853,7 +854,8 @@ static int elants_i2c_fw_update(struct elants_data *ts)
* Event reporting.
*/
-static void elants_i2c_mt_event(struct elants_data *ts, u8 *buf)
+static void elants_i2c_mt_event(struct elants_data *ts, u8 *buf,
+ size_t report_len)
{
struct input_dev *input = ts->input;
unsigned int n_fingers;
@@ -866,7 +868,8 @@ static void elants_i2c_mt_event(struct elants_data *ts, u8
*buf)
buf[FW_POS_STATE];
dev_dbg(>client->dev,
- "n_fingers: %u, state: %04x\n", n_fingers, finger_state);
+ "n_fingers: %u, state: %04x, report_len: %zu\n",
+ n_fingers, finger_state, report_len);
/* Note: all fingers have the same tool type */
tool_type = buf[FW_POS_TOOL_TYPE] & BIT(0) ?
@@ -880,8 +883,16 @@ static void elants_i2c_mt_event(struct elants_data *ts, u8
*buf)
pos = [FW_POS_XY + i * 3];
x = (((u16)pos[0] & 0xf0) << 4) | pos[1];
y = (((u16)pos[0] & 0x0f) << 8) | pos[2];
- p = buf[FW_POS_PRESSURE + i];
- w = buf[FW_POS_WIDTH + i];
+ if (report_len == PACKET_SIZE_OLD) {
+ w = buf[FW_POS_WIDTH + i / 2];
+ w >>= 4 * (~i & 1); // little-endian-nibbles
+ w |= w << 4;
+ w |= !w;
+ p = w;
+ } else {
+ p = buf[FW_POS_PRESSURE + i];
+ w = buf[FW_POS_WIDTH + i];
+ }
dev_dbg(>client->dev, "i=%d x=%d y=%d p=%d w=%d\n",
i, x, y, p, w);
@@ -913,7 +924,8 @@ static u8 elants_i2c_calculate_checksum(u8 *buf)
return checksum;
}
-static void elants_i2c_event(struct elants_data *ts, u8 *buf)
+static void elants_i2c_event(struct elants_data *ts, u8 *buf,
+size_t report_len)
{
u8 checksum = elants_i2c_calculate_checksum(buf);
@@ -927,7 +939,7 @@ static void elants_i2c_event(struct elants_data *ts, u8
*buf)
"%s: unknown packet type: %02x\n",
__func__, buf[FW_POS_HEADER]);
else
- elants_i2c_mt_event(ts, buf);
+ elants_i2c_mt_event(ts, buf, report_len);
}
static irqreturn_t elants_i2c_irq(int irq, void *_dev)
@@ -985,7 +997,8 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
break;
case QUEUE_HEADER_SINGLE:
- elants_i2c_event(ts, >buf[HEADER_SIZE]);
+ elants_i2c_event(ts, >buf[HEADER_SIZE],
+ts->buf[FW_HDR_LENGTH]);
break;
case QUEUE_HEADER_NORMAL:
@@ -998,17 +1011,18 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
}
report_len = ts->buf[FW_HDR_LENGTH] / report_count;
- if (report_len != PACKET_SIZE) {
+ if (report_len != PACKET_SIZE &&
+ report_len != PACKET_SIZE_OLD) {
dev_err(>dev,
- "mismatching report length: %*ph\n",
+ "unsupported report length: %*ph\n",
HEADER_SIZE, ts->buf);
break;
}
for (i = 0; i < report_count; i++) {
u8 *buf = ts->buf + HEADER_SIZE +
- i * PACKET_SIZE;
- elants_i2c_event(ts, buf);
+ i * report_len;
+ elants_i2c_event(ts, buf, report_len);
}
break;
--
2.20.1
[PATCH RESEND v8 0/4] input: elants: Support Asus TF300T and Nexus 7 touchscreens
This series cleans up the driver a bit and implements changes needed to support EKTF3624-based touchscreen used in Asus TF300T, Google Nexus 7 and similar Tegra3-based tablets. --- v2: extended with Dmitry's patches (replaced v1 patches 3 and 4) v3: rebased for v5.7-rc1 v4: rebased onto v5.7-rc2+ (current Linus' master) update "remove unused axes" and "refactor elants_i2c_execute_command()" patches after review add David's patch converting DT binding to YAML v5: rebased onto dtor/input/for-linus v6: rebased onto newer dtor/input/for-linus remove yet unused constants from patch 1 added a new drive-by cleanup (last patch) v7: rebased onto current dtor/input/for-next v8: rebased onto current dtor/input/for-linus v8-resend: rebased again, no changes though --- Dmitry Osipenko (1): input: elants: support 0x66 reply opcode for reporting touches Michał Mirosław (3): input: elants: document some registers and values input: elants: support old touch report format input: elants: read touchscreen size for EKTF3624 drivers/input/touchscreen/elants_i2c.c | 149 + 1 file changed, 127 insertions(+), 22 deletions(-) -- 2.20.1
Re: [PATCH] mt76: Fixed kernel test robot warning
On Thu, Dec 10, 2020 at 12:46 PM Kalle Valo wrote: > > Souptick Joarder writes: > > > Kernel test robot throws below warning -> > > > >drivers/net/wireless/mediatek/mt76/tx.c: In function > > 'mt76_txq_schedule': > >>> drivers/net/wireless/mediatek/mt76/tx.c:499:21: warning: variable 'q' > >>> set but not used [-Wunused-but-set-variable] > > 499 | struct mt76_queue *q; > > | ^ > > > > This patch will silence this warning. > > > > Reported-by: kernel test robot > > Signed-off-by: Souptick Joarder > > I would like to take this directly to wireless-drivers-next, ok? Ok. > > I'll also change the title to: > > mt76: remove unused variable q > > -- > https://patchwork.kernel.org/project/linux-wireless/list/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 1/7] vfio: iommu_type1: Clear added dirty bit when unwind pin
On 2020/12/11 3:16, Alex Williamson wrote:
> On Thu, 10 Dec 2020 15:34:19 +0800
> Keqian Zhu wrote:
>
>> Currently we do not clear added dirty bit of bitmap when unwind
>> pin, so if pin failed at halfway, we set unnecessary dirty bit
>> in bitmap. Clearing added dirty bit when unwind pin, userspace
>> will see less dirty page, which can save much time to handle them.
>>
>> Note that we should distinguish the bits added by pin and the bits
>> already set before pin, so introduce bitmap_added to record this.
>>
>> Signed-off-by: Keqian Zhu
>> ---
>> drivers/vfio/vfio_iommu_type1.c | 33 ++---
>> 1 file changed, 22 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/vfio/vfio_iommu_type1.c
>> b/drivers/vfio/vfio_iommu_type1.c
>> index 67e827638995..f129d24a6ec3 100644
>> --- a/drivers/vfio/vfio_iommu_type1.c
>> +++ b/drivers/vfio/vfio_iommu_type1.c
>> @@ -637,7 +637,11 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
>> struct vfio_iommu *iommu = iommu_data;
>> struct vfio_group *group;
>> int i, j, ret;
>> +unsigned long pgshift = __ffs(iommu->pgsize_bitmap);
>> unsigned long remote_vaddr;
>> +unsigned long bitmap_offset;
>> +unsigned long *bitmap_added;
>> +dma_addr_t iova;
>> struct vfio_dma *dma;
>> bool do_accounting;
>>
>> @@ -650,6 +654,12 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
>>
>> mutex_lock(>lock);
>>
>> +bitmap_added = bitmap_zalloc(npage, GFP_KERNEL);
>> +if (!bitmap_added) {
>> +ret = -ENOMEM;
>> +goto pin_done;
>> +}
>
>
> This is allocated regardless of whether dirty tracking is enabled, so
> this adds overhead to the common case in order to reduce user overhead
> (not correctness) in the rare condition that dirty tracking is enabled,
> and the even rarer condition that there's a fault during that case.
> This is not a good trade-off. Thanks,
Hi Alex,
We can allocate the bitmap when dirty tracking is active, do you accept this?
Or we can set the dirty bitmap after all pins succeed, but this costs cpu time
to locate vfio_dma with iova.
Thanks,
Keqian
>
> Alex
>
>
>> +
>> /* Fail if notifier list is empty */
>> if (!iommu->notifier.head) {
>> ret = -EINVAL;
>> @@ -664,7 +674,6 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
>> do_accounting = !IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu);
>>
>> for (i = 0; i < npage; i++) {
>> -dma_addr_t iova;
>> struct vfio_pfn *vpfn;
>>
>> iova = user_pfn[i] << PAGE_SHIFT;
>> @@ -699,14 +708,10 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
>> }
>>
>> if (iommu->dirty_page_tracking) {
>> -unsigned long pgshift = __ffs(iommu->pgsize_bitmap);
>> -
>> -/*
>> - * Bitmap populated with the smallest supported page
>> - * size
>> - */
>> -bitmap_set(dma->bitmap,
>> - (iova - dma->iova) >> pgshift, 1);
>> +/* Populated with the smallest supported page size */
>> +bitmap_offset = (iova - dma->iova) >> pgshift;
>> +if (!test_and_set_bit(bitmap_offset, dma->bitmap))
>> +set_bit(i, bitmap_added);
>> }
>> }
>> ret = i;
>> @@ -722,14 +727,20 @@ static int vfio_iommu_type1_pin_pages(void *iommu_data,
>> pin_unwind:
>> phys_pfn[i] = 0;
>> for (j = 0; j < i; j++) {
>> -dma_addr_t iova;
>> -
>> iova = user_pfn[j] << PAGE_SHIFT;
>> dma = vfio_find_dma(iommu, iova, PAGE_SIZE);
>> vfio_unpin_page_external(dma, iova, do_accounting);
>> phys_pfn[j] = 0;
>> +
>> +if (test_bit(j, bitmap_added)) {
>> +bitmap_offset = (iova - dma->iova) >> pgshift;
>> +clear_bit(bitmap_offset, dma->bitmap);
>> +}
>> }
>> pin_done:
>> +if (bitmap_added)
>> +bitmap_free(bitmap_added);
>> +
>> mutex_unlock(>lock);
>> return ret;
>> }
>
> .
>
Re: [PATCH] arm64: topology: Drop the useless update to per-cpu cycles
On 10-12-20, 11:17, Viresh Kumar wrote:
> The previous call to update_freq_counters_refs() has already updated the
> per-cpu variables, don't overwrite them with the same value again.
>
> Fixes: 4b9cf23c179a ("arm64: wrap and generalise counter read functions")
> Signed-off-by: Viresh Kumar
> ---
> arch/arm64/kernel/topology.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> index c8308befdb1e..f6faa697e83e 100644
> --- a/arch/arm64/kernel/topology.c
> +++ b/arch/arm64/kernel/topology.c
> @@ -314,7 +314,7 @@ void topology_scale_freq_tick(void)
>
> if (unlikely(core_cnt <= prev_core_cnt ||
>const_cnt <= prev_const_cnt))
> - goto store_and_exit;
> + return;
>
> /*
>* /\corearch_max_freq_scale
> @@ -331,10 +331,6 @@ void topology_scale_freq_tick(void)
>
> scale = min_t(unsigned long, scale, SCHED_CAPACITY_SCALE);
> this_cpu_write(freq_scale, (unsigned long)scale);
> -
> -store_and_exit:
> - this_cpu_write(arch_core_cycles_prev, core_cnt);
> - this_cpu_write(arch_const_cycles_prev, const_cnt);
> }
>
> #ifdef CONFIG_ACPI_CPPC_LIB
Catalin: Can you please pick this up for 5.11-rc1, the earlier patch
(from fixes) is already in your tree. Thanks.
--
viresh
Re: [PATCH 5.4 00/54] 5.4.83-rc2 review
On Thu, 10 Dec 2020 at 22:17, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.4.83 release. > There are 54 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat, 12 Dec 2020 16:47:12 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.83-rc2.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.4.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 5.4.83-rc2 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.4.y git commit: fc1de0dc4276cf610646922e65df5ad81151ac1e git describe: v5.4.82-55-gfc1de0dc4276 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.82-55-gfc1de0dc4276 No regressions (compared to build v5.4.82) No fixes (compared to build v5.4.82) Ran 53098 total tests in the following environments and test suites. Environments -- - arc - arm - arm64 - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - mips - nxp-ls2088 - parisc - powerpc - qemu-arm-clang - qemu-arm64-clang - qemu-arm64-kasan - qemu-x86_64-clang - qemu-x86_64-kasan - qemu-x86_64-kcsan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - riscv - s390 - sh - sparc - x15 - x86 - x86-kasan Test Suites --- * build * linux-log-parser * igt-gpu-tools * install-android-platform-tools-r2600 * libhugetlbfs * ltp-commands-tests * ltp-controllers-tests * ltp-cve-tests * ltp-fs-tests * ltp-hugetlb-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * perf * kselftest * ltp-cap_bounds-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-dio-tests * ltp-io-tests * ltp-ipc-tests * ltp-tracing-tests * network-basic-tests * v4l2-compliance * ltp-containers-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-open-posix-tests * kvm-unit-tests * rcutorture * fwts * kselftest-vsyscall-mode-native * timesync-off -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH v2] Serial: silabs si4455 serial driver
On Fri, Dec 11, 2020 at 07:20:41AM +0100, 'Greg Kroah-Hartman' wrote:
> On Fri, Dec 11, 2020 at 06:09:43AM +, József Horváth wrote:
> > On Fri, Dec 11, 2020 at 06:50:58AM +0100, 'Greg Kroah-Hartman' wrote:
> > > On Thu, Dec 10, 2020 at 07:46:25PM +, József Horváth wrote:
> > > > On Thu, Dec 10, 2020 at 08:03:22PM +0100, 'Greg Kroah-Hartman' wrote:
> > > > > On Thu, Dec 10, 2020 at 05:04:46PM +, József Horváth wrote:
> > > > > > This is a serial port driver for
> > > > > > Silicon Labs Si4455 Sub-GHz transciver.
> > > > > > +
> > > > > > +#define BASE_TTYIOC_PRIVATE0xA0
> > > > > > +/* Set EZConfig.
> > > > > > + * After this ioctl call, the driver restarts the si4455,
> > > > > > + * then apply the new configuration and patch.
> > > > > > + */
> > > > > > +#define SI4455_IOC_SEZC_IOW('T', \
> > > > > > +BASE_TTYIOC_PRIVATE + 0x01, \
> > > > > > +struct si4455_iocbuff)
> > > > >
> > > > > Why does a serial driver have private ioctls? Please no, don't do
> > > > > that.
> > > >
> > > > I checked the ioctl.h and serial_core.h, but I not found any similar
> > > > definition, like BASE_VIDIOC_PRIVATE in videodev2.h.
> > > > In this case the name of macro BASE_TTYIOC_PRIVATE means the base value
> > > > of special ioctl commands owned by this driver.
> > >
> > > My point is, a serial driver should NOT have any custom ioctls.
> > >
> > > > I can change it to BASE_TTYIOC or SI4455_IOC_BASE
> > > >
> > > > > Implement the basic serial driver first, and then we can talk about
> > > > > "custom" configurations and the like, using the correct apis.
> > > >
> > > > Without the SI4455_IOC_SEZC call, the driver can't configure the Si4455
> > > > and not working at all.
> > > > The cofiguration for interface is provided by user for application.
> > >
> > > That is what a device tree is for, to configure the device to have the
> > > correct system configuration, why can't that be the same here?
> > >
> > > > It contains the base frequency, channel spacing, modulation, and a lot
> > > > of more stuff, and generated by Silicon Labs Wireless Development
> > > > Suite.
> > > > The generated configuration is in a non public(compressed,
> > > > encrypted...who knows) format, so without this the driver can't
> > > > provide configuration parameters to Si4455.
> > >
> > > So we have to take a "custom" userspace blob and send it to the device
> > > to configure it properly? Like Jiri said, sounds like firmware, so just
> > > use that interface instead.
> >
> > I checked Jiri's suggestion, and it is a good solution to replace
> > SI4455_IOC_SEZC(configuration) and SI4455_IOC_SEZP(firmware patch).
> > I can move SI4455_IOC_SSIZ(package size) to device tree property.
> >
> > Maybe you have good suggestion for the following:
> > SI4455_IOC_STXC -> Radio transmit channel index. It is a real use case to
> > control this parameter by user at runtime.
> > SI4455_IOC_SRXC -> Radio receive channel index. It is a real use case to
> > control this parameter by user at runtime.
>
> These are not serial port things, why would a serial port care about
> these?
You are right, these are not regular serial port things, but this device is not
a regular uart, it is a sub-GHz transciever, digital radio.
This driver tries to represent it as a serial port to user.
>
> > SI4455_IOC_GRSSI -> Last measured RSSI, when packet received. This is a
> > useful information.
> > (Currently I'm the only one user, and I need this :) )
>
> What is "RSSI"?
>
> And why not debugfs if it's only debugging stuff?
Received signal strength indication, and not only debugging. It is an
information for the end user.
>
> thanks,
>
> greg k-h
Üdvözlettel / Best regards:
József Horváth
Re: [PATCH 5/5] USB: typec: tcpci: Add Bleed discharge to POWER_CONTROL definition
On Thu, Dec 10, 2020 at 08:47:04PM -0800, Badhri Jagan Sridharan wrote: > Hi Greg, > > I have a patch ready to enable BLEED_DISCHARGE in tcpci code. > I will send that in once you merge this patch to usb-next. Feel free to send that now, no need to wait :) thanks, greg k-h
Re: [PATCH -next] input/rmi4: simplify the return expression of rmi_driver_of_probe()
On Thu, Dec 10, 2020 at 10:00:24PM +0800, Zheng Yongjun wrote:
> Simplify the return expression.
>
> Signed-off-by: Zheng Yongjun
> ---
> drivers/input/rmi4/rmi_driver.c | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
> index 258d5fe3d395..eec5d926da25 100644
> --- a/drivers/input/rmi4/rmi_driver.c
> +++ b/drivers/input/rmi4/rmi_driver.c
> @@ -991,14 +991,8 @@ static int rmi_driver_remove(struct device *dev)
> static int rmi_driver_of_probe(struct device *dev,
> struct rmi_device_platform_data *pdata)
> {
> - int retval;
> -
> - retval = rmi_of_property_read_u32(dev, >reset_delay_ms,
> + return rmi_of_property_read_u32(dev, >reset_delay_ms,
> "syna,reset-delay-ms", 1);
> - if (retval)
> - return retval;
> -
> - return 0;
The idea of this function is to potentially handle several device
properties, so I would prefer leaving it as is.
Thanks.
--
Dmitry
Re: [PATCH v2 0/3] Release allocated periodic bandwidth data from reset_bandwidth()
On Fri, Dec 11, 2020 at 9:53 AM Chunfeng Yun wrote:
>
> On Thu, 2020-12-10 at 18:47 +0800, Ikjoon Jang wrote:
> > xhci-mtk releases allocated TT bandwidth data only when whole
> > endpoints of a device are dropped as there're only {add|drop}_endpoint()
> > hooks are defined. This patchset adds more hooks and releases all
> > bandwidth data from reset_bandwidth() path, not drop_endpoint().
> >
> >
> > Changes in v2:
> > - fix a 0-day warning from unused variable
> > - split one big patch into three patches
> > - bugfix in hw flags
> >
> > Ikjoon Jang (3):
> > usb: xhci-mtk: code cleanups in getting bandwidth table
> > usb: xhci-mtk: delay association of tt and ep
> > usb: xhci-mtk: fix unreleased bandwidth data
> >
> > drivers/usb/host/xhci-mtk-sch.c | 180
> > drivers/usb/host/xhci-mtk.h | 13 +++
> > drivers/usb/host/xhci.c | 9 ++
> > 3 files changed, 133 insertions(+), 69 deletions(-)
> Thanks for your patch, I'll test it and check it with our DE
Thanks, I will upload v3.
But I don't expect any logic changes from v2.
Can you please give me feedback on v2 if you find anything?
>
> >
>
[PATCH v4 5/5] crypto: hisilicon/hpre - add 'CURVE25519' algorithm
1. Add 'CURVE25519' curve parameter definition to
'include/crypto/ecc_curve_defs.h';
2. Enable 'CURVE25519' algorithm in Kunpeng 930.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
Reported-by: kernel test robot
---
drivers/crypto/hisilicon/Kconfig| 1 +
drivers/crypto/hisilicon/hpre/hpre.h| 2 +
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 364 +++-
include/crypto/ecc_curve_defs.h | 17 ++
4 files changed, 375 insertions(+), 9 deletions(-)
diff --git a/drivers/crypto/hisilicon/Kconfig b/drivers/crypto/hisilicon/Kconfig
index 8431926..c45adb1 100644
--- a/drivers/crypto/hisilicon/Kconfig
+++ b/drivers/crypto/hisilicon/Kconfig
@@ -65,6 +65,7 @@ config CRYPTO_DEV_HISI_HPRE
depends on UACCE || UACCE=n
depends on ARM64 || (COMPILE_TEST && 64BIT)
depends on ACPI
+ select CRYPTO_LIB_CURVE25519_GENERIC
select CRYPTO_DEV_HISI_QM
select CRYPTO_DH
select CRYPTO_RSA
diff --git a/drivers/crypto/hisilicon/hpre/hpre.h
b/drivers/crypto/hisilicon/hpre/hpre.h
index 50e6b2e..92892e3 100644
--- a/drivers/crypto/hisilicon/hpre/hpre.h
+++ b/drivers/crypto/hisilicon/hpre/hpre.h
@@ -84,6 +84,8 @@ enum hpre_alg_type {
HPRE_ALG_DH_G2 = 0x4,
HPRE_ALG_DH = 0x5,
HPRE_ALG_ECC_MUL = 0xD,
+ /* shared by x25519 and x448, but x448 is not supported now */
+ HPRE_ALG_CURVE25519_MUL = 0x10,
};
struct hpre_sqe {
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index 58f847b..e135732 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/* Copyright (c) 2019 HiSilicon Limited. */
#include
+#include
#include
#include
#include
@@ -98,6 +99,16 @@ struct hpre_ecdh_ctx {
dma_addr_t dma_g;
};
+struct hpre_curve25519_ctx {
+ /* low address: p->a->k */
+ unsigned char *p;
+ dma_addr_t dma_p;
+
+ /* gx coordinate */
+ unsigned char *g;
+ dma_addr_t dma_g;
+};
+
struct hpre_ctx {
struct hisi_qp *qp;
struct hpre_asym_request **req_list;
@@ -110,6 +121,7 @@ struct hpre_ctx {
struct hpre_rsa_ctx rsa;
struct hpre_dh_ctx dh;
struct hpre_ecdh_ctx ecdh;
+ struct hpre_curve25519_ctx curve25519;
};
/* for ecc algorithms */
unsigned int curve_id;
@@ -124,6 +136,7 @@ struct hpre_asym_request {
struct akcipher_request *rsa;
struct kpp_request *dh;
struct kpp_request *ecdh;
+ struct kpp_request *curve25519;
} areq;
int err;
int req_id;
@@ -446,7 +459,6 @@ static void hpre_alg_cb(struct hisi_qp *qp, void *resp)
struct hpre_sqe *sqe = resp;
struct hpre_asym_request *req = ctx->req_list[le16_to_cpu(sqe->tag)];
-
if (unlikely(!req)) {
atomic64_inc([HPRE_INVALID_REQ_CNT].value);
return;
@@ -1176,6 +1188,12 @@ static void hpre_ecc_clear_ctx(struct hpre_ctx *ctx,
bool is_clear_all,
memzero_explicit(ctx->ecdh.p + shift, sz);
dma_free_coherent(dev, sz << 3, ctx->ecdh.p, ctx->ecdh.dma_p);
ctx->ecdh.p = NULL;
+ } else if (!is_ecdh && ctx->curve25519.p) {
+ /* curve25519: p->a->k */
+ memzero_explicit(ctx->curve25519.p + shift, sz);
+ dma_free_coherent(dev, sz << 2, ctx->curve25519.p,
+ ctx->curve25519.dma_p);
+ ctx->curve25519.p = NULL;
}
ctx->curve_id = 0;
@@ -1585,6 +1603,307 @@ static void hpre_ecdh_exit_tfm(struct crypto_kpp *tfm)
hpre_ecc_clear_ctx(ctx, true, true);
}
+static void hpre_curve25519_fill_curve(struct hpre_ctx *ctx, const void *buf,
+ unsigned int len)
+{
+ u8 secret[CURVE25519_KEY_SIZE] = { 0 };
+ unsigned int sz = ctx->key_sz;
+ unsigned int shift = sz << 1;
+ void *p;
+
+ /**
+* The key from 'buf' is in little-endian, we should preprocess it as
+* the description in rfc7748: "k[0] &= 248, k[31] &= 127, k[31] |= 64",
+* then convert it to big endian. Only in this way, the result can be
+* the same as the software curve-25519 that exists in crypto.
+*/
+ memcpy(secret, buf, len);
+ curve25519_clamp_secret(secret);
+ hpre_key_to_big_end(secret, CURVE25519_KEY_SIZE);
+
+ p = ctx->curve25519.p + sz - len;
+
+ /* fill curve parameters */
+ fill_curve_param(p, ecc_25519.p, len, ecc_25519.g.ndigits);
+ fill_curve_param(p + sz, ecc_25519.a, len, ecc_25519.g.ndigits);
+ memcpy(p + shift, secret, len);
+ fill_curve_param(p + shift + sz, ecc_25519.g.x, len,
ecc_25519.g.ndigits);
+ memzero_explicit(secret,
[PATCH v4 4/5] crypto: hisilicon/hpre - add 'ECDH' algorithm
1. Add some new 'ECDH' curve parameter definitions to
'include/crypto/ecc_curve_defs.h', and reorder ECC 'Curves IDs'
in 'include/crypto/ecdh.h';
2. Enable 'ECDH' algorithm in Kunpeng 930.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
crypto/ecc.c| 4 +-
crypto/testmgr.h| 12 +-
drivers/crypto/hisilicon/hpre/hpre.h| 2 +-
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 510 +++-
drivers/crypto/hisilicon/hpre/hpre_main.c | 1 +
include/crypto/ecc_curve_defs.h | 198 +--
include/crypto/ecdh.h | 9 +-
7 files changed, 698 insertions(+), 38 deletions(-)
diff --git a/crypto/ecc.c b/crypto/ecc.c
index f23efdd..6adcae2 100644
--- a/crypto/ecc.c
+++ b/crypto/ecc.c
@@ -46,9 +46,9 @@ static inline const struct ecc_curve *ecc_get_curve(unsigned
int curve_id)
switch (curve_id) {
/* In FIPS mode only allow P256 and higher */
case ECC_CURVE_NIST_P192:
- return fips_enabled ? NULL : _p192;
+ return fips_enabled ? NULL :
_curve_list[ECC_CURVE_NIST_P192 - 1];
case ECC_CURVE_NIST_P256:
- return _p256;
+ return _curve_list[ECC_CURVE_NIST_P256 - 1];
default:
return NULL;
}
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 8c83811..371692e 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -2268,12 +2268,12 @@ static const struct kpp_testvec ecdh_tv_template[] = {
#ifdef __LITTLE_ENDIAN
"\x02\x00" /* type */
"\x20\x00" /* len */
- "\x01\x00" /* curve_id */
+ "\x02\x00" /* curve_id */
"\x18\x00" /* key_size */
#else
"\x00\x02" /* type */
"\x00\x20" /* len */
- "\x00\x01" /* curve_id */
+ "\x00\x02" /* curve_id */
"\x00\x18" /* key_size */
#endif
"\xb5\x05\xb1\x71\x1e\xbf\x8c\xda"
@@ -2307,12 +2307,12 @@ static const struct kpp_testvec ecdh_tv_template[] = {
#ifdef __LITTLE_ENDIAN
"\x02\x00" /* type */
"\x28\x00" /* len */
- "\x02\x00" /* curve_id */
+ "\x04\x00" /* curve_id */
"\x20\x00" /* key_size */
#else
"\x00\x02" /* type */
"\x00\x28" /* len */
- "\x00\x02" /* curve_id */
+ "\x00\x04" /* curve_id */
"\x00\x20" /* key_size */
#endif
"\x24\xd1\x21\xeb\xe5\xcf\x2d\x83"
@@ -2351,12 +2351,12 @@ static const struct kpp_testvec ecdh_tv_template[] = {
#ifdef __LITTLE_ENDIAN
"\x02\x00" /* type */
"\x08\x00" /* len */
- "\x02\x00" /* curve_id */
+ "\x04\x00" /* curve_id */
"\x00\x00", /* key_size */
#else
"\x00\x02" /* type */
"\x00\x08" /* len */
- "\x00\x02" /* curve_id */
+ "\x00\x04" /* curve_id */
"\x00\x00", /* key_size */
#endif
.b_secret =
diff --git a/drivers/crypto/hisilicon/hpre/hpre.h
b/drivers/crypto/hisilicon/hpre/hpre.h
index 02193e1..50e6b2e 100644
--- a/drivers/crypto/hisilicon/hpre/hpre.h
+++ b/drivers/crypto/hisilicon/hpre/hpre.h
@@ -83,6 +83,7 @@ enum hpre_alg_type {
HPRE_ALG_KG_CRT = 0x3,
HPRE_ALG_DH_G2 = 0x4,
HPRE_ALG_DH = 0x5,
+ HPRE_ALG_ECC_MUL = 0xD,
};
struct hpre_sqe {
@@ -104,5 +105,4 @@ struct hisi_qp *hpre_create_qp(u8 type);
int hpre_algs_register(struct hisi_qm *qm);
void hpre_algs_unregister(struct hisi_qm *qm);
-
#endif
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index 712bea9..58f847b 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -2,6 +2,8 @@
/* Copyright (c) 2019 HiSilicon Limited. */
#include
#include
+#include
+#include
#include
#include
#include
@@ -36,6 +38,22 @@ struct hpre_ctx;
#define HPRE_DFX_SEC_TO_US 100
#define HPRE_DFX_US_TO_NS 1000
+/* size in bytes of the n prime */
+#define HPRE_ECC_NIST_P128_N_SIZE 16
+#define HPRE_ECC_NIST_P192_N_SIZE 24
+#define HPRE_ECC_NIST_P224_N_SIZE 28
+#define HPRE_ECC_NIST_P256_N_SIZE 32
+#define HPRE_ECC_NIST_P320_N_SIZE 40
+#define HPRE_ECC_NIST_P384_N_SIZE 48
+#define HPRE_ECC_NIST_P521_N_SIZE 66
+
+/* size in bytes */
+#define HPRE_ECC_HW256_KSZ_B 32
+#define HPRE_ECC_HW384_KSZ_B 48
+#define HPRE_ECC_HW576_KSZ_B 72
+
+#define HPRE_ECDH_MAX_SZ HPRE_ECC_HW576_KSZ_B
+
typedef void (*hpre_cb)(struct hpre_ctx *ctx, void *sqe);
struct hpre_rsa_ctx {
@@ -61,14 +79,25 @@ struct hpre_dh_ctx {
* else if base if the counterpart public key we
* compute the shared secret
* ZZ = yb^xa mod p; [RFC2631 sec 2.1.1]
+* low address: d--->n, please refer to Hisilicon HPRE UM
*/
- char *xa_p; /* low address: d--->n, please refer to Hisilicon HPRE UM */
+ char *xa_p;
dma_addr_t dma_xa_p;
char *g; /* m */
dma_addr_t
[PATCH v4 2/5] crypto: hisilicon/hpre - add algorithm type
Algorithm type is brought in to get hardware HPRE queue
to support different algorithms.
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/hpre/hpre.h| 10 +-
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 12 ++--
drivers/crypto/hisilicon/hpre/hpre_main.c | 11 +--
3 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/crypto/hisilicon/hpre/hpre.h
b/drivers/crypto/hisilicon/hpre/hpre.h
index cc50f23..02193e1 100644
--- a/drivers/crypto/hisilicon/hpre/hpre.h
+++ b/drivers/crypto/hisilicon/hpre/hpre.h
@@ -10,6 +10,14 @@
#define HPRE_PF_DEF_Q_NUM 64
#define HPRE_PF_DEF_Q_BASE 0
+/*
+ * type used in qm sqc DW6.
+ * 0 - Algorithm which has been supported in V2, like RSA, DH and so on;
+ * 1 - ECC algorithm in V3.
+ */
+#define HPRE_V2_ALG_TYPE 0
+#define HPRE_V3_ECC_ALG_TYPE 1
+
enum {
HPRE_CLUSTER0,
HPRE_CLUSTER1,
@@ -92,7 +100,7 @@ struct hpre_sqe {
__le32 rsvd1[_HPRE_SQE_ALIGN_EXT];
};
-struct hisi_qp *hpre_create_qp(void);
+struct hisi_qp *hpre_create_qp(u8 type);
int hpre_algs_register(struct hisi_qm *qm);
void hpre_algs_unregister(struct hisi_qm *qm);
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index d89b2f5..712bea9 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -152,12 +152,12 @@ static void hpre_rm_req_from_ctx(struct hpre_asym_request
*hpre_req)
}
}
-static struct hisi_qp *hpre_get_qp_and_start(void)
+static struct hisi_qp *hpre_get_qp_and_start(u8 type)
{
struct hisi_qp *qp;
int ret;
- qp = hpre_create_qp();
+ qp = hpre_create_qp(type);
if (!qp) {
pr_err("Can not create hpre qp!\n");
return ERR_PTR(-ENODEV);
@@ -422,11 +422,11 @@ static void hpre_alg_cb(struct hisi_qp *qp, void *resp)
req->cb(ctx, resp);
}
-static int hpre_ctx_init(struct hpre_ctx *ctx)
+static int hpre_ctx_init(struct hpre_ctx *ctx, u8 type)
{
struct hisi_qp *qp;
- qp = hpre_get_qp_and_start();
+ qp = hpre_get_qp_and_start(type);
if (IS_ERR(qp))
return PTR_ERR(qp);
@@ -674,7 +674,7 @@ static int hpre_dh_init_tfm(struct crypto_kpp *tfm)
{
struct hpre_ctx *ctx = kpp_tfm_ctx(tfm);
- return hpre_ctx_init(ctx);
+ return hpre_ctx_init(ctx, HPRE_V2_ALG_TYPE);
}
static void hpre_dh_exit_tfm(struct crypto_kpp *tfm)
@@ -1100,7 +1100,7 @@ static int hpre_rsa_init_tfm(struct crypto_akcipher *tfm)
return PTR_ERR(ctx->rsa.soft_tfm);
}
- ret = hpre_ctx_init(ctx);
+ ret = hpre_ctx_init(ctx, HPRE_V2_ALG_TYPE);
if (ret)
crypto_free_akcipher(ctx->rsa.soft_tfm);
diff --git a/drivers/crypto/hisilicon/hpre/hpre_main.c
b/drivers/crypto/hisilicon/hpre/hpre_main.c
index fc7173a..1ae8fa1 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_main.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_main.c
@@ -209,13 +209,20 @@ static u32 vfs_num;
module_param_cb(vfs_num, _num_ops, _num, 0444);
MODULE_PARM_DESC(vfs_num, "Number of VFs to enable(1-63), 0(default)");
-struct hisi_qp *hpre_create_qp(void)
+struct hisi_qp *hpre_create_qp(u8 type)
{
int node = cpu_to_node(smp_processor_id());
struct hisi_qp *qp = NULL;
int ret;
- ret = hisi_qm_alloc_qps_node(_devices, 1, 0, node, );
+ if (type != HPRE_V2_ALG_TYPE && type != HPRE_V3_ECC_ALG_TYPE)
+ return NULL;
+
+ /*
+* type: 0 - RSA/DH. algorithm supported in V2,
+* 1 - ECC algorithm in V3.
+*/
+ ret = hisi_qm_alloc_qps_node(_devices, 1, type, node, );
if (!ret)
return qp;
--
2.8.1
[PATCH v4 1/5] crypto: hisilicon/hpre - add some updates to adapt to Kunpeng 930
From: Hui Tang
HPRE of Kunpeng 930 is updated on cluster numbers and configurations
of Kunpeng 920 HPRE, so we try to update this driver to make it running
okay on both chips.
Signed-off-by: Hui Tang
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
drivers/crypto/hisilicon/hpre/hpre.h | 8 ++-
drivers/crypto/hisilicon/hpre/hpre_main.c | 93 +--
2 files changed, 68 insertions(+), 33 deletions(-)
diff --git a/drivers/crypto/hisilicon/hpre/hpre.h
b/drivers/crypto/hisilicon/hpre/hpre.h
index e784712..cc50f23 100644
--- a/drivers/crypto/hisilicon/hpre/hpre.h
+++ b/drivers/crypto/hisilicon/hpre/hpre.h
@@ -14,8 +14,7 @@ enum {
HPRE_CLUSTER0,
HPRE_CLUSTER1,
HPRE_CLUSTER2,
- HPRE_CLUSTER3,
- HPRE_CLUSTERS_NUM,
+ HPRE_CLUSTER3
};
enum hpre_ctrl_dbgfs_file {
@@ -36,7 +35,10 @@ enum hpre_dfx_dbgfs_file {
HPRE_DFX_FILE_NUM
};
-#define HPRE_DEBUGFS_FILE_NUM(HPRE_DEBUG_FILE_NUM + HPRE_CLUSTERS_NUM - 1)
+#define HPRE_CLUSTERS_NUM_V2 (HPRE_CLUSTER3 + 1)
+#define HPRE_CLUSTERS_NUM_V3 1
+#define HPRE_CLUSTERS_NUM_MAX HPRE_CLUSTERS_NUM_V2
+#define HPRE_DEBUGFS_FILE_NUM (HPRE_DEBUG_FILE_NUM + HPRE_CLUSTERS_NUM_MAX - 1)
struct hpre_debugfs_file {
int index;
diff --git a/drivers/crypto/hisilicon/hpre/hpre_main.c
b/drivers/crypto/hisilicon/hpre/hpre_main.c
index e5c9919..fc7173a 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_main.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_main.c
@@ -29,6 +29,8 @@
#define HPRE_BD_ARUSR_CFG 0x301030
#define HPRE_BD_AWUSR_CFG 0x301034
#define HPRE_TYPES_ENB 0x301038
+#define HPRE_RSA_ENB BIT(0)
+#define HPRE_ECC_ENB BIT(1)
#define HPRE_DATA_RUSER_CFG0x30103c
#define HPRE_DATA_WUSER_CFG0x301040
#define HPRE_INT_MASK 0x301400
@@ -73,7 +75,8 @@
#define HPRE_QM_AXI_CFG_MASK 0x
#define HPRE_QM_VFG_AX_MASK0xff
#define HPRE_BD_USR_MASK 0x3
-#define HPRE_CLUSTER_CORE_MASK 0xf
+#define HPRE_CLUSTER_CORE_MASK_V2 0xf
+#define HPRE_CLUSTER_CORE_MASK_V3 0xff
#define HPRE_AM_OOO_SHUTDOWN_ENB 0x301044
#define HPRE_AM_OOO_SHUTDOWN_ENABLEBIT(0)
@@ -86,6 +89,11 @@
#define HPRE_QM_PM_FLR BIT(11)
#define HPRE_QM_SRIOV_FLR BIT(12)
+#define HPRE_CLUSTERS_NUM(qm) \
+ (((qm)->ver >= QM_HW_V3) ? HPRE_CLUSTERS_NUM_V3 : HPRE_CLUSTERS_NUM_V2)
+#define HPRE_CLUSTER_CORE_MASK(qm) \
+ (((qm)->ver >= QM_HW_V3) ? HPRE_CLUSTER_CORE_MASK_V3 :\
+ HPRE_CLUSTER_CORE_MASK_V2)
#define HPRE_VIA_MSI_DSM 1
#define HPRE_SQE_MASK_OFFSET 8
#define HPRE_SQE_MASK_LEN 24
@@ -238,8 +246,40 @@ static int hpre_cfg_by_dsm(struct hisi_qm *qm)
return 0;
}
+static int hpre_set_cluster(struct hisi_qm *qm)
+{
+ u32 cluster_core_mask = HPRE_CLUSTER_CORE_MASK(qm);
+ u8 clusters_num = HPRE_CLUSTERS_NUM(qm);
+ struct device *dev = >pdev->dev;
+ unsigned long offset;
+ u32 val = 0;
+ int ret, i;
+
+ for (i = 0; i < clusters_num; i++) {
+ offset = i * HPRE_CLSTR_ADDR_INTRVL;
+
+ /* clusters initiating */
+ writel(cluster_core_mask,
+ HPRE_ADDR(qm, offset + HPRE_CORE_ENB));
+ writel(0x1, HPRE_ADDR(qm, offset + HPRE_CORE_INI_CFG));
+ ret = readl_relaxed_poll_timeout(HPRE_ADDR(qm, offset +
+ HPRE_CORE_INI_STATUS), val,
+ ((val & cluster_core_mask) ==
+ cluster_core_mask),
+ HPRE_REG_RD_INTVRL_US,
+ HPRE_REG_RD_TMOUT_US);
+ if (ret) {
+ dev_err(dev,
+ "cluster %d int st status timeout!\n", i);
+ return -ETIMEDOUT;
+ }
+ }
+
+ return 0;
+}
+
/*
- * For Hi1620, we shoul disable FLR triggered by hardware (BME/PM/SRIOV).
+ * For Kunpeng 920, we shoul disable FLR triggered by hardware (BME/PM/SRIOV).
* Or it may stay in D3 state when we bind and unbind hpre quickly,
* as it does FLR triggered by hardware.
*/
@@ -257,9 +297,8 @@ static void disable_flr_of_bme(struct hisi_qm *qm)
static int hpre_set_user_domain_and_cache(struct hisi_qm *qm)
{
struct device *dev = >pdev->dev;
- unsigned long offset;
- int ret, i;
u32 val;
+ int ret;
writel(HPRE_QM_USR_CFG_MASK, HPRE_ADDR(qm, QM_ARUSER_M_CFG_ENABLE));
writel(HPRE_QM_USR_CFG_MASK, HPRE_ADDR(qm, QM_AWUSER_M_CFG_ENABLE));
@@ -270,7 +309,12 @@ static int hpre_set_user_domain_and_cache(struct hisi_qm
*qm)
val |= BIT(HPRE_TIMEOUT_ABNML_BIT);
writel_relaxed(val,
[PATCH v4 3/5] crypto: expose elliptic curve parameters as Crypto APIs
Move elliptic curves definition to 'include/crypto/ecc_curve_defs.h',
so all can use it,
Signed-off-by: Meng Yu
Reviewed-by: Zaibo Xu
---
crypto/ecc.c| 1 -
crypto/ecc.h| 37 +
crypto/ecc_curve_defs.h | 57 -
crypto/ecrdsa_defs.h| 2 +-
include/crypto/ecc_curve_defs.h | 92 +
5 files changed, 95 insertions(+), 94 deletions(-)
delete mode 100644 crypto/ecc_curve_defs.h
create mode 100644 include/crypto/ecc_curve_defs.h
diff --git a/crypto/ecc.c b/crypto/ecc.c
index c80aa25..f23efdd 100644
--- a/crypto/ecc.c
+++ b/crypto/ecc.c
@@ -35,7 +35,6 @@
#include
#include "ecc.h"
-#include "ecc_curve_defs.h"
typedef struct {
u64 m_low;
diff --git a/crypto/ecc.h b/crypto/ecc.h
index d4e546b..e5afaf3 100644
--- a/crypto/ecc.h
+++ b/crypto/ecc.h
@@ -26,6 +26,8 @@
#ifndef _CRYPTO_ECC_H
#define _CRYPTO_ECC_H
+#include
+
/* One digit is u64 qword. */
#define ECC_CURVE_NIST_P192_DIGITS 3
#define ECC_CURVE_NIST_P256_DIGITS 4
@@ -33,44 +35,9 @@
#define ECC_DIGITS_TO_BYTES_SHIFT 3
-/**
- * struct ecc_point - elliptic curve point in affine coordinates
- *
- * @x: X coordinate in vli form.
- * @y: Y coordinate in vli form.
- * @ndigits: Length of vlis in u64 qwords.
- */
-struct ecc_point {
- u64 *x;
- u64 *y;
- u8 ndigits;
-};
-
#define ECC_POINT_INIT(x, y, ndigits) (struct ecc_point) { x, y, ndigits }
/**
- * struct ecc_curve - definition of elliptic curve
- *
- * @name: Short name of the curve.
- * @g: Generator point of the curve.
- * @p: Prime number, if Barrett's reduction is used for this curve
- * pre-calculated value 'mu' is appended to the @p after ndigits.
- * Use of Barrett's reduction is heuristically determined in
- * vli_mmod_fast().
- * @n: Order of the curve group.
- * @a: Curve parameter a.
- * @b: Curve parameter b.
- */
-struct ecc_curve {
- char *name;
- struct ecc_point g;
- u64 *p;
- u64 *n;
- u64 *a;
- u64 *b;
-};
-
-/**
* ecc_is_key_valid() - Validate a given ECDH private key
*
* @curve_id: id representing the curve to use
diff --git a/crypto/ecc_curve_defs.h b/crypto/ecc_curve_defs.h
deleted file mode 100644
index 69be6c7..000
--- a/crypto/ecc_curve_defs.h
+++ /dev/null
@@ -1,57 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _CRYTO_ECC_CURVE_DEFS_H
-#define _CRYTO_ECC_CURVE_DEFS_H
-
-/* NIST P-192: a = p - 3 */
-static u64 nist_p192_g_x[] = { 0xF4FF0AFD82FF1012ull, 0x7CBF20EB43A18800ull,
- 0x188DA80EB03090F6ull };
-static u64 nist_p192_g_y[] = { 0x73F977A11E794811ull, 0x631011ED6B24CDD5ull,
- 0x07192B95FFC8DA78ull };
-static u64 nist_p192_p[] = { 0xull, 0xFFFEull,
- 0xull };
-static u64 nist_p192_n[] = { 0x146BC9B1B4D22831ull, 0x99DEF836ull,
- 0xull };
-static u64 nist_p192_a[] = { 0xFFFCull, 0xFFFEull,
- 0xull };
-static u64 nist_p192_b[] = { 0xFEB8DEECC146B9B1ull, 0x0FA7E9AB72243049ull,
- 0x64210519E59C80E7ull };
-static struct ecc_curve nist_p192 = {
- .name = "nist_192",
- .g = {
- .x = nist_p192_g_x,
- .y = nist_p192_g_y,
- .ndigits = 3,
- },
- .p = nist_p192_p,
- .n = nist_p192_n,
- .a = nist_p192_a,
- .b = nist_p192_b
-};
-
-/* NIST P-256: a = p - 3 */
-static u64 nist_p256_g_x[] = { 0xF4A13945D898C296ull, 0x77037D812DEB33A0ull,
- 0xF8BCE6E563A440F2ull, 0x6B17D1F2E12C4247ull };
-static u64 nist_p256_g_y[] = { 0xCBB6406837BF51F5ull, 0x2BCE33576B315ECEull,
- 0x8EE7EB4A7C0F9E16ull, 0x4FE342E2FE1A7F9Bull };
-static u64 nist_p256_p[] = { 0xull, 0xull,
- 0xull, 0x0001ull };
-static u64 nist_p256_n[] = { 0xF3B9CAC2FC632551ull, 0xBCE6FAADA7179E84ull,
- 0xull, 0xull };
-static u64 nist_p256_a[] = { 0xFFFCull, 0xull,
- 0xull, 0x0001ull };
-static u64 nist_p256_b[] = { 0x3BCE3C3E27D2604Bull, 0x651D06B0CC53B0F6ull,
- 0xB3EBBD55769886BCull, 0x5AC635D8AA3A93E7ull };
-static struct ecc_curve nist_p256 = {
- .name = "nist_256",
- .g = {
- .x = nist_p256_g_x,
- .y = nist_p256_g_y,
- .ndigits = 4,
- },
- .p = nist_p256_p,
- .n = nist_p256_n,
- .a = nist_p256_a,
- .b = nist_p256_b
-};
-
[PATCH v4 0/5] add ECDH and CURVE25519 algorithms support for Kunpeng 930
1. Move elliptic curve parameter definitions out to "include/crypto"; 2. Add some new elliptic curve parameters definitions, and reorder ECC 'Curves IDs'; 3. Add ECDH and CURVE25519 algorithms support for Kunpeng 930. These patches depend on: [v2,1/6] crypto: hisilicon/hpre - add version adapt to new algorithms, https://patchwork.kernel.org/project/linux-crypto/patch/1607598607-8728- 2-git-send-email-liulongf...@huawei.com/ v3 -> v4: - patch #3: add new, move ecc_curve params to "include/crypto" v2 -> v3: - patch #5: fix sparse warnings - patch #5: add 'CRYPTO_LIB_CURVE25519_GENERIC' in 'Kconfig' v1 -> v2: - patch #5: delete `curve25519_null_point' Hui Tang (1): crypto: hisilicon/hpre - add some updates to adapt to Kunpeng 930 Meng Yu (4): crypto: hisilicon/hpre - add algorithm type crypto: expose elliptic curve parameters as Crypto APIs crypto: hisilicon/hpre - add 'ECDH' algorithm crypto: hisilicon/hpre - add 'CURVE25519' algorithm crypto/ecc.c| 5 +- crypto/ecc.h| 37 +- crypto/ecc_curve_defs.h | 57 -- crypto/ecrdsa_defs.h| 2 +- crypto/testmgr.h| 12 +- drivers/crypto/hisilicon/Kconfig| 1 + drivers/crypto/hisilicon/hpre/hpre.h| 22 +- drivers/crypto/hisilicon/hpre/hpre_crypto.c | 868 +++- drivers/crypto/hisilicon/hpre/hpre_main.c | 105 +++- include/crypto/ecc_curve_defs.h | 261 + include/crypto/ecdh.h | 9 +- 11 files changed, 1228 insertions(+), 151 deletions(-) delete mode 100644 crypto/ecc_curve_defs.h create mode 100644 include/crypto/ecc_curve_defs.h -- 2.8.1
Re: [PATCH -next] input/touchscreen: simplify the return expression of mxt_send_bootloader_cmd()
On Thu, Dec 10, 2020 at 09:59:43PM +0800, Zheng Yongjun wrote: > Simplify the return expression. > > Signed-off-by: Zheng Yongjun Applied, thank you. -- Dmitry
Re: [PATCH v2 3/3] usb: xhci-mtk: fix unreleased bandwidth data
On Thu, Dec 10, 2020 at 6:57 PM Greg Kroah-Hartman
wrote:
>
> On Thu, Dec 10, 2020 at 06:47:47PM +0800, Ikjoon Jang wrote:
> > xhci-mtk has hooks on add_endpoint() and drop_endpoint() from xhci
> > to handle its own sw bandwidth managements and stores bandwidth data
> > into internal table every time add_endpoint() is called,
> > so when bandwidth allocation fails at one endpoint, all earlier
> > allocation from the same interface could still remain at the table.
> >
> > This patch adds two more hooks from check_bandwidth() and
> > reset_bandwidth(), and make mtk-xhci to releases all failed endpoints
> > from reset_bandwidth().
> >
> > Fixes: 0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller")
> > Signed-off-by: Ikjoon Jang
>
> Shouldn't this be the first patch in the series? You don't want a fix
> to be dependent on code style changes, otherwise it is really really
> hard to backport it to older kernels that might need this fix, right?
yes, you're right.
This patchset also requires
"4b0f7a77fb3c usb: xhci-mtk: supports bandwidth scheduling with multi-TT",
which doesn't have a Fixes tag.
I think I can change Fixes to point to that commit (4b0f7a77fb3c),
as this unreleased bandwidth data is much more impactful to
TT bandwidth.
Thanks!
>
> Can you re-order these patches please?
>
> thanks,
>
> greg k-h
[PATCHv6 net-next 0/3] Add devlink and devlink health reporters to
Add basic devlink and devlink health reporters. Devlink health reporters are added for NPA block. Address Jakub's comment to add devlink support for error reporting. https://www.spinics.net/lists/netdev/msg670712.html For now, I have dropped the NIX block health reporters. This series attempts to add health reporters only for the NPA block. As per Jakub's suggestion separate reporters per event is used and also got rid of the counters. Change-log: v6 - Address Jakub comments - Add reporters per event for each block. - Remove the Sw counter. - Remove the mbox version from devlink info. v5 - Address Jiri's comment - use devlink_fmsg_arr_pair_nest_start() for NIX blocks v4 - Rebase to net-next (no logic changes). v3 - Address Saeed's comments on v2. - Renamed the reporter name as hw_*. - Call devlink_health_report() when an event is raised. - Added recover op too. v2 - Address Willem's comments on v1. - Fixed the sparse issues, reported by Jakub. George Cherian (3): octeontx2-af: Add devlink suppoort to af driver octeontx2-af: Add devlink health reporters for NPA docs: octeontx2: Add Documentation for NPA health reporters .../ethernet/marvell/octeontx2.rst| 50 ++ .../net/ethernet/marvell/octeontx2/Kconfig| 1 + .../ethernet/marvell/octeontx2/af/Makefile| 2 +- .../net/ethernet/marvell/octeontx2/af/rvu.c | 9 +- .../net/ethernet/marvell/octeontx2/af/rvu.h | 4 + .../marvell/octeontx2/af/rvu_devlink.c| 770 ++ .../marvell/octeontx2/af/rvu_devlink.h| 55 ++ .../marvell/octeontx2/af/rvu_struct.h | 23 + 8 files changed, 912 insertions(+), 2 deletions(-) create mode 100644 drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c create mode 100644 drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.h -- 2.25.1
[PATCHv6 net-next 1/3] octeontx2-af: Add devlink suppoort to af driver
Add devlink support to AF driver. Basic devlink support is added.
Currently info_get is the only supported devlink ops.
devlink ouptput looks like this
# devlink dev
pci/0002:01:00.0
# devlink dev info
pci/0002:01:00.0:
driver octeontx2-af
#
Signed-off-by: Sunil Kovvuri Goutham
Signed-off-by: Jerin Jacob
Signed-off-by: George Cherian
---
.../net/ethernet/marvell/octeontx2/Kconfig| 1 +
.../ethernet/marvell/octeontx2/af/Makefile| 2 +-
.../net/ethernet/marvell/octeontx2/af/rvu.c | 9 ++-
.../net/ethernet/marvell/octeontx2/af/rvu.h | 4 ++
.../marvell/octeontx2/af/rvu_devlink.c| 64 +++
.../marvell/octeontx2/af/rvu_devlink.h| 20 ++
6 files changed, 98 insertions(+), 2 deletions(-)
create mode 100644 drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c
create mode 100644 drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.h
diff --git a/drivers/net/ethernet/marvell/octeontx2/Kconfig
b/drivers/net/ethernet/marvell/octeontx2/Kconfig
index 543a1d047567..16caa02095fe 100644
--- a/drivers/net/ethernet/marvell/octeontx2/Kconfig
+++ b/drivers/net/ethernet/marvell/octeontx2/Kconfig
@@ -9,6 +9,7 @@ config OCTEONTX2_MBOX
config OCTEONTX2_AF
tristate "Marvell OcteonTX2 RVU Admin Function driver"
select OCTEONTX2_MBOX
+ select NET_DEVLINK
depends on (64BIT && COMPILE_TEST) || ARM64
depends on PCI
help
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/Makefile
b/drivers/net/ethernet/marvell/octeontx2/af/Makefile
index 7100d1dd856e..eb535c98ca38 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/Makefile
+++ b/drivers/net/ethernet/marvell/octeontx2/af/Makefile
@@ -10,4 +10,4 @@ obj-$(CONFIG_OCTEONTX2_AF) += octeontx2_af.o
octeontx2_mbox-y := mbox.o rvu_trace.o
octeontx2_af-y := cgx.o rvu.o rvu_cgx.o rvu_npa.o rvu_nix.o \
rvu_reg.o rvu_npc.o rvu_debugfs.o ptp.o rvu_npc_fs.o \
- rvu_cpt.o
+ rvu_cpt.o rvu_devlink.o
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c
b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c
index 9f901c0edcbb..e8fd712860a1 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c
@@ -2826,17 +2826,23 @@ static int rvu_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
if (err)
goto err_flr;
+ err = rvu_register_dl(rvu);
+ if (err)
+ goto err_irq;
+
rvu_setup_rvum_blk_revid(rvu);
/* Enable AF's VFs (if any) */
err = rvu_enable_sriov(rvu);
if (err)
- goto err_irq;
+ goto err_dl;
/* Initialize debugfs */
rvu_dbg_init(rvu);
return 0;
+err_dl:
+ rvu_unregister_dl(rvu);
err_irq:
rvu_unregister_interrupts(rvu);
err_flr:
@@ -2868,6 +2874,7 @@ static void rvu_remove(struct pci_dev *pdev)
rvu_dbg_exit(rvu);
rvu_unregister_interrupts(rvu);
+ rvu_unregister_dl(rvu);
rvu_flr_wq_destroy(rvu);
rvu_cgx_exit(rvu);
rvu_fwdata_exit(rvu);
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu.h
b/drivers/net/ethernet/marvell/octeontx2/af/rvu.h
index b6c0977499ab..b1a6ecfd563e 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu.h
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu.h
@@ -12,7 +12,10 @@
#define RVU_H
#include
+#include
+
#include "rvu_struct.h"
+#include "rvu_devlink.h"
#include "common.h"
#include "mbox.h"
#include "npc.h"
@@ -422,6 +425,7 @@ struct rvu {
#ifdef CONFIG_DEBUG_FS
struct rvu_debugfs rvu_dbg;
#endif
+ struct rvu_devlink *rvu_dl;
};
static inline void rvu_write64(struct rvu *rvu, u64 block, u64 offset, u64 val)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c
b/drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c
new file mode 100644
index ..5dabca04a34b
--- /dev/null
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Marvell OcteonTx2 RVU Devlink
+ *
+ * Copyright (C) 2020 Marvell.
+ *
+ */
+
+#include "rvu.h"
+
+#define DRV_NAME "octeontx2-af"
+
+static int rvu_devlink_info_get(struct devlink *devlink, struct
devlink_info_req *req,
+ struct netlink_ext_ack *extack)
+{
+ return devlink_info_driver_name_put(req, DRV_NAME);
+}
+
+static const struct devlink_ops rvu_devlink_ops = {
+ .info_get = rvu_devlink_info_get,
+};
+
+int rvu_register_dl(struct rvu *rvu)
+{
+ struct rvu_devlink *rvu_dl;
+ struct devlink *dl;
+ int err;
+
+ rvu_dl = kzalloc(sizeof(*rvu_dl), GFP_KERNEL);
+ if (!rvu_dl)
+ return -ENOMEM;
+
+ dl = devlink_alloc(_devlink_ops, sizeof(struct rvu_devlink));
+ if (!dl) {
+ dev_warn(rvu->dev, "devlink_alloc failed\n");
+ kfree(rvu_dl);
+
[PATCH 2/3] octeontx2-af: Add devlink health reporters for NPA
Add health reporters for RVU NPA block.
NPA Health reporters handle following HW event groups
- GENERAL events
- ERROR events
- RAS events
- RVU event
Output:
#devlink health
pci/0002:01:00.0:
reporter hw_npa_intr
state healthy error 0 recover 0 grace_period 0 auto_recover true
auto_dump true
reporter hw_npa_gen
state healthy error 0 recover 0 grace_period 0 auto_recover true
auto_dump true
reporter hw_npa_err
state healthy error 0 recover 0 grace_period 0 auto_recover true
auto_dump true
reporter hw_npa_ras
state healthy error 0 recover 0 grace_period 0 auto_recover true
auto_dump true
#devlink health dump show pci/0002:01:00.0 reporter hw_npa_err
NPA_AF_ERR:
NPA Error Interrupt Reg : 4096
AQ Doorbell Error
#devlink health dump show pci/0002:01:00.0 reporter hw_npa_ras
NPA_AF_RVU_RAS:
NPA RAS Interrupt Reg : 0
Each reporter dump shows the Register value and the description of the
cause.
Signed-off-by: Sunil Kovvuri Goutham
Signed-off-by: Jerin Jacob
Signed-off-by: George Cherian
---
.../marvell/octeontx2/af/rvu_devlink.c| 708 +-
.../marvell/octeontx2/af/rvu_devlink.h| 35 +
.../marvell/octeontx2/af/rvu_struct.h | 23 +
3 files changed, 765 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c
b/drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c
index 5dabca04a34b..3f9d0ab6d5ae 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c
@@ -5,10 +5,714 @@
*
*/
+#include
+
#include "rvu.h"
+#include "rvu_reg.h"
+#include "rvu_struct.h"
#define DRV_NAME "octeontx2-af"
+static int rvu_report_pair_start(struct devlink_fmsg *fmsg, const char *name)
+{
+ int err;
+
+ err = devlink_fmsg_pair_nest_start(fmsg, name);
+ if (err)
+ return err;
+
+ return devlink_fmsg_obj_nest_start(fmsg);
+}
+
+static int rvu_report_pair_end(struct devlink_fmsg *fmsg)
+{
+ int err;
+
+ err = devlink_fmsg_obj_nest_end(fmsg);
+ if (err)
+ return err;
+
+ return devlink_fmsg_pair_nest_end(fmsg);
+}
+
+static bool rvu_common_request_irq(struct rvu *rvu, int offset,
+ const char *name, irq_handler_t fn)
+{
+ struct rvu_devlink *rvu_dl = rvu->rvu_dl;
+ int rc;
+
+ sprintf(>irq_name[offset * NAME_SIZE], name);
+ rc = request_irq(pci_irq_vector(rvu->pdev, offset), fn, 0,
+>irq_name[offset * NAME_SIZE], rvu_dl);
+ if (rc)
+ dev_warn(rvu->dev, "Failed to register %s irq\n", name);
+ else
+ rvu->irq_allocated[offset] = true;
+
+ return rvu->irq_allocated[offset];
+}
+
+static void rvu_npa_intr_work(struct work_struct *work)
+{
+ struct rvu_npa_health_reporters *rvu_npa_health_reporter;
+
+ rvu_npa_health_reporter = container_of(work, struct
rvu_npa_health_reporters, intr_work);
+ devlink_health_report(rvu_npa_health_reporter->rvu_hw_npa_intr_reporter,
+ "NPA_AF_RVU Error",
+ rvu_npa_health_reporter->npa_event_ctx);
+}
+
+static irqreturn_t rvu_npa_af_rvu_intr_handler(int irq, void *rvu_irq)
+{
+ struct rvu_npa_event_ctx *npa_event_context;
+ struct rvu_devlink *rvu_dl = rvu_irq;
+ struct rvu *rvu;
+ int blkaddr;
+ u64 intr;
+
+ rvu = rvu_dl->rvu;
+ blkaddr = rvu_get_blkaddr(rvu, BLKTYPE_NPA, 0);
+ if (blkaddr < 0)
+ return IRQ_NONE;
+
+ npa_event_context = rvu_dl->rvu_npa_health_reporter->npa_event_ctx;
+ intr = rvu_read64(rvu, blkaddr, NPA_AF_RVU_INT);
+ npa_event_context->npa_af_rvu_int = intr;
+
+ /* Clear interrupts */
+ rvu_write64(rvu, blkaddr, NPA_AF_RVU_INT, intr);
+ rvu_write64(rvu, blkaddr, NPA_AF_RVU_INT_ENA_W1C, ~0ULL);
+ queue_work(rvu_dl->devlink_wq,
_dl->rvu_npa_health_reporter->intr_work);
+
+ return IRQ_HANDLED;
+}
+
+static void rvu_npa_gen_work(struct work_struct *work)
+{
+ struct rvu_npa_health_reporters *rvu_npa_health_reporter;
+
+ rvu_npa_health_reporter = container_of(work, struct
rvu_npa_health_reporters, gen_work);
+ devlink_health_report(rvu_npa_health_reporter->rvu_hw_npa_gen_reporter,
+ "NPA_AF_GEN Error",
+ rvu_npa_health_reporter->npa_event_ctx);
+}
+
+static irqreturn_t rvu_npa_af_gen_intr_handler(int irq, void *rvu_irq)
+{
+ struct rvu_npa_event_ctx *npa_event_context;
+ struct rvu_devlink *rvu_dl = rvu_irq;
+ struct rvu *rvu;
+ int blkaddr;
+ u64 intr;
+
+ rvu = rvu_dl->rvu;
+ blkaddr = rvu_get_blkaddr(rvu, BLKTYPE_NPA, 0);
+ if (blkaddr < 0)
+ return IRQ_NONE;
+
+ npa_event_context = rvu_dl->rvu_npa_health_reporter->npa_event_ctx;
+
[PATCH 3/3] docs: octeontx2: Add Documentation for NPA health reporters
Add Documentation for devlink health reporters for NPA block. Signed-off-by: George Cherian --- .../ethernet/marvell/octeontx2.rst| 50 +++ 1 file changed, 50 insertions(+) diff --git a/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst index 88f508338c5f..d3fcf536d14e 100644 --- a/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst +++ b/Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst @@ -12,6 +12,7 @@ Contents - `Overview`_ - `Drivers`_ - `Basic packet flow`_ +- `Devlink health reporters`_ Overview @@ -157,3 +158,52 @@ Egress 3. The SQ descriptor ring is maintained in buffers allocated from SQ mapped pool of NPA block LF. 4. NIX block transmits the pkt on the designated channel. 5. NPC MCAM entries can be installed to divert pkt onto a different channel. + +Devlink health reporters + + +NPA Reporters +- +The NPA reporters are responsible for reporting and recovering the following group of errors +1. GENERAL events + - Error due to operation of unmapped PF. + - Error due to disabled alloc/free for other HW blocks (NIX, SSO, TIM, DPI and AURA). +2. ERROR events + - Fault due to NPA_AQ_INST_S read or NPA_AQ_RES_S write. + - AQ Doorbell Error. +3. RAS events + - RAS Error Reporting for NPA_AQ_INST_S/NPA_AQ_RES_S. +4. RVU events + - Error due to unmapped slot. + +Sample Output +- +~# devlink health +pci/0002:01:00.0: + reporter hw_npa_intr + state healthy error 2872 recover 2872 last_dump_date 2020-12-10 last_dump_time 09:39:09 grace_period 0 auto_recover true auto_dump true + reporter hw_npa_gen + state healthy error 2872 recover 2872 last_dump_date 2020-12-11 last_dump_time 04:43:04 grace_period 0 auto_recover true auto_dump true + reporter hw_npa_err + state healthy error 2871 recover 2871 last_dump_date 2020-12-10 last_dump_time 09:39:17 grace_period 0 auto_recover true auto_dump true + reporter hw_npa_ras + state healthy error 0 recover 0 last_dump_date 2020-12-10 last_dump_time 09:32:40 grace_period 0 auto_recover true auto_dump true + +Each reporter dumps the + - Error Type + - Error Register value + - Reason in words + +For eg: +~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_gen + NPA_AF_GENERAL: + NPA General Interrupt Reg : 1 + NIX0: free disabled RX +~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_intr + NPA_AF_RVU: + NPA RVU Interrupt Reg : 1 + Unmap Slot Error +~# devlink health dump show pci/0002:01:00.0 reporter hw_npa_err + NPA_AF_ERR: +NPA Error Interrupt Reg : 4096 +AQ Doorbell Error -- 2.25.1
Re: [net PATCH] tcp: Mark fastopen SYN packet as lost when receiving ICMP_TOOBIG/ICMP_FRAG_NEEDED
On Fri, Dec 11, 2020 at 2:55 AM Alexander Duyck
wrote:
>
> From: Alexander Duyck
>
> In the case of a fastopen SYN there are cases where it may trigger either a
> ICMP_TOOBIG message in the case of IPv6 or a fragmentation request in the
> case of IPv4. This results in the socket stalling for a second or more as
> it does not respond to the message by retransmitting the SYN frame.
>
> Normally a SYN frame should not be able to trigger a ICMP_TOOBIG or
> ICMP_FRAG_NEEDED however in the case of fastopen we can have a frame that
> makes use of the entire MTU. In the case of fastopen it does, and an
> additional complication is that the retransmit queue doesn't contain the
> original frames. As a result when tcp_simple_retransmit is called and
> walks the list of frames in the queue it may not mark the frames as lost
> because both the SYN and the data packet each individually are smaller than
> the MSS size after the adjustment. This results in the socket being stalled
> until the retransmit timer kicks in and forces the SYN frame out again
> without the data attached.
>
> In order to resolve this we need to mark the SYN frame as lost if it is the
> first packet in the queue. Doing this allows the socket to recover much
> more quickly without the retransmit timeout stall.
>
> Signed-off-by: Alexander Duyck
I do not think it is net candidate, but net-next
Yuchung might correct me, but I think TCP Fastopen standard was very
conservative about payload len in the SYN packet
So receiving an ICMP was never considered.
> ---
> include/net/tcp.h|1 +
> net/ipv4/tcp_input.c |8
> net/ipv4/tcp_ipv4.c |6 ++
> net/ipv6/tcp_ipv6.c |4
> 4 files changed, 19 insertions(+)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index d4ef5bf94168..6181ad98727a 100644
> --- a/include/net/tcp.h
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -546,6 +546,12 @@ int tcp_v4_err(struct sk_buff *skb, u32 info)
> if (sk->sk_state == TCP_LISTEN)
> goto out;
>
> + /* fastopen SYN may have triggered the fragmentation
> +* request. Mark the SYN or SYN/ACK as lost.
> +*/
> + if (sk->sk_state == TCP_SYN_SENT)
> + tcp_mark_syn_lost(sk);
This is going to crash in some cases, you do not know if you own the socket.
(Look a few lines below)
> +
> tp->mtu_info = info;
> if (!sock_owned_by_user(sk)) {
> tcp_v4_mtu_reduced(sk);
> diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
> index 992cbf3eb9e3..d7b1346863e3 100644
> --- a/net/ipv6/tcp_ipv6.c
> +++ b/net/ipv6/tcp_ipv6.c
> @@ -443,6 +443,10 @@ static int tcp_v6_err(struct sk_buff *skb, struct
> inet6_skb_parm *opt,
> if (!ip6_sk_accept_pmtu(sk))
> goto out;
>
> + /* fastopen SYN may have triggered TOOBIG, mark it lost. */
> + if (sk->sk_state == TCP_SYN_SENT)
> + tcp_mark_syn_lost(sk);
Same issue here.
> +
> tp->mtu_info = ntohl(info);
> if (!sock_owned_by_user(sk))
> tcp_v6_mtu_reduced(sk);
>
>
Re: [PATCH v2] Serial: silabs si4455 serial driver
On Fri, Dec 11, 2020 at 06:09:43AM +, József Horváth wrote:
> On Fri, Dec 11, 2020 at 06:50:58AM +0100, 'Greg Kroah-Hartman' wrote:
> > On Thu, Dec 10, 2020 at 07:46:25PM +, József Horváth wrote:
> > > On Thu, Dec 10, 2020 at 08:03:22PM +0100, 'Greg Kroah-Hartman' wrote:
> > > > On Thu, Dec 10, 2020 at 05:04:46PM +, József Horváth wrote:
> > > > > This is a serial port driver for
> > > > > Silicon Labs Si4455 Sub-GHz transciver.
> > > > > +
> > > > > +#define BASE_TTYIOC_PRIVATE 0xA0
> > > > > +/* Set EZConfig.
> > > > > + * After this ioctl call, the driver restarts the si4455,
> > > > > + * then apply the new configuration and patch.
> > > > > + */
> > > > > +#define SI4455_IOC_SEZC _IOW('T', \
> > > > > + BASE_TTYIOC_PRIVATE + 0x01, \
> > > > > + struct si4455_iocbuff)
> > > >
> > > > Why does a serial driver have private ioctls? Please no, don't do that.
> > >
> > > I checked the ioctl.h and serial_core.h, but I not found any similar
> > > definition, like BASE_VIDIOC_PRIVATE in videodev2.h.
> > > In this case the name of macro BASE_TTYIOC_PRIVATE means the base value
> > > of special ioctl commands owned by this driver.
> >
> > My point is, a serial driver should NOT have any custom ioctls.
> >
> > > I can change it to BASE_TTYIOC or SI4455_IOC_BASE
> > >
> > > > Implement the basic serial driver first, and then we can talk about
> > > > "custom" configurations and the like, using the correct apis.
> > >
> > > Without the SI4455_IOC_SEZC call, the driver can't configure the Si4455
> > > and not working at all.
> > > The cofiguration for interface is provided by user for application.
> >
> > That is what a device tree is for, to configure the device to have the
> > correct system configuration, why can't that be the same here?
> >
> > > It contains the base frequency, channel spacing, modulation, and a lot
> > > of more stuff, and generated by Silicon Labs Wireless Development
> > > Suite.
> > > The generated configuration is in a non public(compressed,
> > > encrypted...who knows) format, so without this the driver can't
> > > provide configuration parameters to Si4455.
> >
> > So we have to take a "custom" userspace blob and send it to the device
> > to configure it properly? Like Jiri said, sounds like firmware, so just
> > use that interface instead.
>
> I checked Jiri's suggestion, and it is a good solution to replace
> SI4455_IOC_SEZC(configuration) and SI4455_IOC_SEZP(firmware patch).
> I can move SI4455_IOC_SSIZ(package size) to device tree property.
>
> Maybe you have good suggestion for the following:
> SI4455_IOC_STXC -> Radio transmit channel index. It is a real use case to
> control this parameter by user at runtime.
> SI4455_IOC_SRXC -> Radio receive channel index. It is a real use case to
> control this parameter by user at runtime.
These are not serial port things, why would a serial port care about
these?
> SI4455_IOC_GRSSI -> Last measured RSSI, when packet received. This is a
> useful information.
> (Currently I'm the only one user, and I need this :) )
What is "RSSI"?
And why not debugfs if it's only debugging stuff?
thanks,
greg k-h
Re: [patch 27/30] xen/events: Only force affinity mask for percpu interrupts
On 11.12.20 00:20, boris.ostrov...@oracle.com wrote: On 12/10/20 2:26 PM, Thomas Gleixner wrote: All event channel setups bind the interrupt on CPU0 or the target CPU for percpu interrupts and overwrite the affinity mask with the corresponding cpumask. That does not make sense. The XEN implementation of irqchip::irq_set_affinity() already picks a single target CPU out of the affinity mask and the actual target is stored in the effective CPU mask, so destroying the user chosen affinity mask which might contain more than one CPU is wrong. Change the implementation so that the channel is bound to CPU0 at the XEN level and leave the affinity mask alone. At startup of the interrupt affinity will be assigned out of the affinity mask and the XEN binding will be updated. If that's the case then I wonder whether we need this call at all and instead bind at startup time. This binding to cpu0 was introduced with commit 97253eeeb792d61ed2 and I have no reason to believe the underlying problem has been eliminated. Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v3] dt-bindings: usb: Add new compatible string for AM64 SoC
Hi Rob, On 11/12/20 9:07 am, Rob Herring wrote: > On Thu, Dec 10, 2020 at 12:24:50PM +0530, Aswath Govindraju wrote: >> Add compatible string in j721e-usb binding file as the same USB subsystem >> is present in AM64. >> >> Signed-off-by: Aswath Govindraju >> Acked-by: Roger Quadros >> --- >> >> Changes since v2: >> - added changes done over the versions >> >> Changes since v1: >> - replaced the '\t' at the beginning of the lines with spaces as it was >> causing the dt_binding_check to fail >> >> >> Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml | 7 +-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml >> b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml >> index 388245b91a55..453587f6d304 100644 >> --- a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml >> +++ b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml >> @@ -11,8 +11,11 @@ maintainers: >> >> properties: >>compatible: >> -items: >> - - const: ti,j721e-usb >> +anyOf: >> + - items: >> + - const: ti,j721e-usb >> + - items: >> + - const: ti,am64-usb > > compatible: > enum: > - ti,j721e-usb > - ti,am64-usb > Thank you for the comments. I have sent a respin for this patch making the above changes. May I please know a case where anyOf would be used rather than enum because after reading the documentation[1], I thought that using enum meant that only one of the listed strings in enum can be used as compatible strings in a given node. [1]https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/example-schema.yaml Thanks, Aswath >> >>reg: >> description: module registers >> -- >> 2.17.1 >>
Re: [PATCH v2] perf script: Fix overrun issue for dynamically-allocated pmu type number
On 9/12/20 2:58 am, Jin Yao wrote:
> When unpacking the event which is from dynamic pmu, the array
> output[OUTPUT_TYPE_MAX] may be overrun. For example, type number of
> SKL uncore_imc is 10, but OUTPUT_TYPE_MAX is 7 now (OUTPUT_TYPE_MAX =
> PERF_TYPE_MAX + 1).
>
> /* In builtin-script.c */
> process_event()
> {
> unsigned int type = output_type(attr->type);
>
> if (output[type].fields == 0)
> return;
> }
>
> output[10] is overrun.
>
> Create a type OUTPUT_TYPE_OTHER for dynamic pmu events, then
> output_type(attr->type) will return OUTPUT_TYPE_OTHER here.
>
> Note that if PERF_TYPE_MAX ever changed, then there would be a conflict
> between old perf.data files that had a dynamicaliy allocated PMU number
> that would then be the same as a fixed PERF_TYPE.
>
> Example:
>
> perf record --switch-events -C 0 -e
> "{cpu-clock,uncore_imc/data_reads/,uncore_imc/data_writes/}:SD" -a -- sleep 1
> perf script
>
> Before:
> swapper 0 [000] 1479253.987551: 277766
> cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
> swapper 0 [000] 1479253.987797: 246709
> cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
> swapper 0 [000] 1479253.988127: 329883
> cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
> swapper 0 [000] 1479253.988273: 146393
> cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
> swapper 0 [000] 1479253.988523: 249977
> cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
> swapper 0 [000] 1479253.988877: 354090
> cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
> swapper 0 [000] 1479253.989023: 145940
> cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
> swapper 0 [000] 1479253.989383: 359856
> cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
> swapper 0 [000] 1479253.989523: 140082
> cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
>
> After:
> swapper 0 [000] 1397040.402011: 272384
> cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
> swapper 0 [000] 1397040.402011: 5396
> uncore_imc/data_reads/:
> swapper 0 [000] 1397040.402011:967
> uncore_imc/data_writes/:
> swapper 0 [000] 1397040.402259: 249153
> cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
> swapper 0 [000] 1397040.402259: 7231
> uncore_imc/data_reads/:
> swapper 0 [000] 1397040.402259: 1297
> uncore_imc/data_writes/:
> swapper 0 [000] 1397040.402508: 249108
> cpu-clock: 9d4ddb6f cpuidle_enter_state+0xdf ([kernel.kallsyms])
> swapper 0 [000] 1397040.402508: 5333
> uncore_imc/data_reads/:
> swapper 0 [000] 1397040.402508: 1008
> uncore_imc/data_writes/:
>
> Signed-off-by: Jin Yao
Acked-by: Adrian Hunter
> ---
> v2:
> Remove Fixes tag because this issue has always been here, not caused by
> 1405720d4f26 ("perf script: Add 'synth' event type for synthesized events").
> No functional change in v2.
>
> tools/perf/builtin-script.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
> index 1c322c129185..5d8a64836228 100644
> --- a/tools/perf/builtin-script.c
> +++ b/tools/perf/builtin-script.c
> @@ -183,6 +183,7 @@ struct output_option {
>
> enum {
> OUTPUT_TYPE_SYNTH = PERF_TYPE_MAX,
> + OUTPUT_TYPE_OTHER,
> OUTPUT_TYPE_MAX
> };
>
> @@ -279,6 +280,18 @@ static struct {
>
> .invalid_fields = PERF_OUTPUT_TRACE | PERF_OUTPUT_BPF_OUTPUT,
> },
> +
> + [OUTPUT_TYPE_OTHER] = {
> + .user_set = false,
> +
> + .fields = PERF_OUTPUT_COMM | PERF_OUTPUT_TID |
> + PERF_OUTPUT_CPU | PERF_OUTPUT_TIME |
> + PERF_OUTPUT_EVNAME | PERF_OUTPUT_IP |
> + PERF_OUTPUT_SYM | PERF_OUTPUT_SYMOFFSET |
> + PERF_OUTPUT_DSO | PERF_OUTPUT_PERIOD,
> +
> + .invalid_fields = PERF_OUTPUT_TRACE | PERF_OUTPUT_BPF_OUTPUT,
> + },
> };
>
> struct evsel_script {
> @@ -339,8 +352,11 @@ static inline int output_type(unsigned int type)
> case PERF_TYPE_SYNTH:
> return OUTPUT_TYPE_SYNTH;
> default:
> - return type;
> + if (type < PERF_TYPE_MAX)
> + return type;
> }
> +
> + return OUTPUT_TYPE_OTHER;
> }
Re: [PATCH v2] Serial: silabs si4455 serial driver
On Fri, Dec 11, 2020 at 06:50:58AM +0100, 'Greg Kroah-Hartman' wrote:
> On Thu, Dec 10, 2020 at 07:46:25PM +, József Horváth wrote:
> > On Thu, Dec 10, 2020 at 08:03:22PM +0100, 'Greg Kroah-Hartman' wrote:
> > > On Thu, Dec 10, 2020 at 05:04:46PM +, József Horváth wrote:
> > > > This is a serial port driver for
> > > > Silicon Labs Si4455 Sub-GHz transciver.
> > > > +
> > > > +#define BASE_TTYIOC_PRIVATE0xA0
> > > > +/* Set EZConfig.
> > > > + * After this ioctl call, the driver restarts the si4455,
> > > > + * then apply the new configuration and patch.
> > > > + */
> > > > +#define SI4455_IOC_SEZC_IOW('T', \
> > > > +BASE_TTYIOC_PRIVATE + 0x01, \
> > > > +struct si4455_iocbuff)
> > >
> > > Why does a serial driver have private ioctls? Please no, don't do that.
> >
> > I checked the ioctl.h and serial_core.h, but I not found any similar
> > definition, like BASE_VIDIOC_PRIVATE in videodev2.h.
> > In this case the name of macro BASE_TTYIOC_PRIVATE means the base value of
> > special ioctl commands owned by this driver.
>
> My point is, a serial driver should NOT have any custom ioctls.
>
> > I can change it to BASE_TTYIOC or SI4455_IOC_BASE
> >
> > > Implement the basic serial driver first, and then we can talk about
> > > "custom" configurations and the like, using the correct apis.
> >
> > Without the SI4455_IOC_SEZC call, the driver can't configure the Si4455 and
> > not working at all.
> > The cofiguration for interface is provided by user for application.
>
> That is what a device tree is for, to configure the device to have the
> correct system configuration, why can't that be the same here?
>
> > It contains the base frequency, channel spacing, modulation, and a lot
> > of more stuff, and generated by Silicon Labs Wireless Development
> > Suite.
> > The generated configuration is in a non public(compressed,
> > encrypted...who knows) format, so without this the driver can't
> > provide configuration parameters to Si4455.
>
> So we have to take a "custom" userspace blob and send it to the device
> to configure it properly? Like Jiri said, sounds like firmware, so just
> use that interface instead.
I checked Jiri's suggestion, and it is a good solution to replace
SI4455_IOC_SEZC(configuration) and SI4455_IOC_SEZP(firmware patch).
I can move SI4455_IOC_SSIZ(package size) to device tree property.
Maybe you have good suggestion for the following:
SI4455_IOC_STXC -> Radio transmit channel index. It is a real use case to
control this parameter by user at runtime.
SI4455_IOC_SRXC -> Radio receive channel index. It is a real use case to
control this parameter by user at runtime.
SI4455_IOC_GRSSI -> Last measured RSSI, when packet received. This is a useful
information.
(Currently I'm the only one user, and I need this :) )
>
> thanks,
>
> greg k-h
Üdvözlettel / Best regards:
József Horváth
Re: [PATCH RFC] f2fs: compress: add compress_flag in struct f2fs_comp_option
On 2020/12/11 1:23, Jaegeuk Kim wrote:
On 12/10, Chao Yu wrote:
Add a extra field compress_flag to get/set more compress option from/to
compressed inode.
Signed-off-by: Chao Yu
---
Daeho, Jaegeuk,
Could you please check whether we could add this new field to struct
f2fs_comp_option? so we can expand to allow user to query/config more
options of compressed inode via new ioctl.
It needs to consider before original patches goes to merge window, let
me know you have other concerns.
Chao, I think it'd hard to add this at time point, unless there's critical
info that we need to set very urgently.
Oops, so it needs extra ioctl interface to get/set newly added chksum and
compress_level configs...
Thanks,
fs/f2fs/file.c| 1 +
include/uapi/linux/f2fs.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 16ea10f2bcf5..fbf06311c88d 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -3965,6 +3965,7 @@ static int f2fs_ioc_get_compress_option(struct file
*filp, unsigned long arg)
option.algorithm = F2FS_I(inode)->i_compress_algorithm;
option.log_cluster_size = F2FS_I(inode)->i_log_cluster_size;
+ option.compress_flag = F2FS_I(inode)->i_compress_flag;
inode_unlock_shared(inode);
diff --git a/include/uapi/linux/f2fs.h b/include/uapi/linux/f2fs.h
index 352a822d4370..2b9c4c99ceee 100644
--- a/include/uapi/linux/f2fs.h
+++ b/include/uapi/linux/f2fs.h
@@ -93,6 +93,7 @@ struct f2fs_sectrim_range {
struct f2fs_comp_option {
__u8 algorithm;
__u8 log_cluster_size;
+ __u16 compress_flag;
};
#endif /* _UAPI_LINUX_F2FS_H */
--
2.29.2
.
[PATCH v4] dt-bindings: usb: Add new compatible string for AM64 SoC
Add compatible string in j721e-usb binding file as the same USB subsystem is present in AM64. Signed-off-by: Aswath Govindraju --- Changes since v3: - used enum instead of anyOf. Changes since v2: - added changes done over the versions. Changes since v1: - replaced the '\t' at the beginning of the lines with spaces as it was causing the dt_binding_check to fail. Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml index 388245b91a55..1a5c7bbb40d1 100644 --- a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml +++ b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml @@ -11,8 +11,9 @@ maintainers: properties: compatible: -items: - - const: ti,j721e-usb +enum: + - ti,j721e-usb + - ti,am64-usb reg: description: module registers -- 2.17.1
Re: [PATCH] input: keyboard: imx_keypad: add COMPILE_TEST support
On Mon, Mar 02, 2020 at 04:26:13PM +0800, Anson Huang wrote: > Add COMPILE_TEST support to imx_keypad driver for better compile > testing coverage. > > Signed-off-by: Anson Huang Applied, thank you. -- Dmitry
Re: [PATCH] input: rmi4: rmi_spi: Use new structure for SPI transfer delays
On Thu, Feb 27, 2020 at 03:03:36PM +0200, Sergiu Cuciurean wrote:
> In a recent change to the SPI subsystem [1], a new `delay` struct was added
> to replace the `delay_usecs`. This change replaces the current
> `delay_usecs` with `delay` for this driver.
>
> The `spi_transfer_delay_exec()` function [in the SPI framework] makes sure
> that both `delay_usecs` & `delay` are used (in this order to preserve
> backwards compatibility).
>
> [1] commit bebcfd272df6 ("spi: introduce `delay` field for
> `spi_transfer` + spi_transfer_delay_exec()")
>
> Signed-off-by: Sergiu Cuciurean
Applied, thank you.
--
Dmitry
Re: [PATCH] input: keyboard: applespi: Use new structure for SPI transfer delays
On Thu, Feb 27, 2020 at 02:45:34PM +0200, Sergiu Cuciurean wrote:
> In a recent change to the SPI subsystem [1], a new `delay` struct was added
> to replace the `delay_usecs`. This change replaces the current
> `delay_usecs` with `delay` for this driver.
>
> The `spi_transfer_delay_exec()` function [in the SPI framework] makes sure
> that both `delay_usecs` & `delay` are used (in this order to preserve
> backwards compatibility).
>
> [1] commit bebcfd272df6 ("spi: introduce `delay` field for
> `spi_transfer` + spi_transfer_delay_exec()")
>
> Signed-off-by: Sergiu Cuciurean
Applied, thank you.
--
Dmitry
Re: [PATCH v3] mmc: sdhci-msm: Warn about overclocking SD/MMC
On 10/12/20 11:27 pm, Douglas Anderson wrote:
> As talked about in commit 5e4b7e82d497 ("clk: qcom: gcc-sdm845: Use
> floor ops for sdcc clks"), most clocks handled by the Qualcomm clock
> drivers are rounded _up_ by default instead of down. We should make
> sure SD/MMC clocks are always rounded down in the clock drivers.
> Let's add a warning in the Qualcomm SDHCI driver to help catch the
> problem.
>
> This would have saved a bunch of time [1].
>
> [1]
> http://lore.kernel.org/r/20201210102234.1.I096779f219625148900fc984dd0084ed1ba87c7f@changeid
>
> Suggested-by: Stephen Boyd
> Signed-off-by: Douglas Anderson
> ---
>
> Changes in v3:
> - Proper printf format code.
>
> Changes in v2:
> - Store rate in unsigned long, not unsigned int.
> - Reuse the clk_get_rate() in the later print.
>
> drivers/mmc/host/sdhci-msm.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index 3451eb325513..50beb407dbe9 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -353,6 +353,7 @@ static void msm_set_clock_rate_for_bus_mode(struct
> sdhci_host *host,
> struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
> struct mmc_ios curr_ios = host->mmc->ios;
> struct clk *core_clk = msm_host->bulk_clks[0].clk;
> + unsigned long achieved_rate;
> int rc;
>
> clock = msm_get_clock_rate_for_bus_mode(host, clock);
> @@ -363,10 +364,20 @@ static void msm_set_clock_rate_for_bus_mode(struct
> sdhci_host *host,
> curr_ios.timing);
> return;
> }
> +
> + /*
> + * Qualcomm clock drivers by default round clock _up_ if they can't
> + * make the requested rate. This is not good for SD. Yell if we
> + * encounter it.
> + */
> + achieved_rate = clk_get_rate(core_clk);
> + if (achieved_rate > clock)
> + pr_warn("%s: Card appears overclocked; req %u Hz, actual %lu
> Hz\n",
> + mmc_hostname(host->mmc), clock, achieved_rate);
How does a warning help?
Also, did you consider setting host->mmc->actual_clock
> +
> msm_host->clk_rate = clock;
> pr_debug("%s: Setting clock at rate %lu at timing %d\n",
> - mmc_hostname(host->mmc), clk_get_rate(core_clk),
> - curr_ios.timing);
> + mmc_hostname(host->mmc), achieved_rate, curr_ios.timing);
> }
>
> /* Platform specific tuning */
>
Re: [PATCH v2] input: touchscreen: ad7877: Use new structure for SPI transfer delays
On Fri, Feb 28, 2020 at 12:45:08PM +0200, Sergiu Cuciurean wrote:
> In a recent change to the SPI subsystem [1], a new `delay` struct was added
> to replace the `delay_usecs`. This change replaces the current
> `delay_usecs` with `delay` for this driver.
>
> The `spi_transfer_delay_exec()` function [in the SPI framework] makes sure
> that both `delay_usecs` & `delay` are used (in this order to preserve
> backwards compatibility).
>
> [1] commit bebcfd272df6 ("spi: introduce `delay` field for
> `spi_transfer` + spi_transfer_delay_exec()")
>
> Signed-off-by: Sergiu Cuciurean
Applied, thank you.
--
Dmitry
Re: [PATCH v2] Serial: silabs si4455 serial driver
On Thu, Dec 10, 2020 at 07:46:25PM +, József Horváth wrote:
> On Thu, Dec 10, 2020 at 08:03:22PM +0100, 'Greg Kroah-Hartman' wrote:
> > On Thu, Dec 10, 2020 at 05:04:46PM +, József Horváth wrote:
> > > This is a serial port driver for
> > > Silicon Labs Si4455 Sub-GHz transciver.
> > >
> > > Signed-off-by: József Horváth
> > > ---
> > > .../bindings/serial/silabs,si4455.yaml| 53 +
> > > MAINTAINERS |7 +
> > > drivers/tty/serial/Kconfig|8 +
> > > drivers/tty/serial/Makefile |1 +
> > > drivers/tty/serial/si4455.c | 1235 +
> > > drivers/tty/serial/si4455_api.h | 56 +
> >
> > First thing, a single .c file should not need a .h file.
> >
> > But then I looked at the .h file and see:
> >
> > > --- /dev/null
> > > +++ b/drivers/tty/serial/si4455_api.h
> > > @@ -0,0 +1,56 @@
> > > +/* SPDX-License-Identifier: GPL-2.0
> > > + *
> > > + * Copyright (C) 2020 József Horváth
> > > + *
> > > + */
> > > +#ifndef SI4455_API_H_
> > > +#define SI4455_API_H_
> > > +
> > > +struct si4455_iocbuff {
> > > + uint32_t length;
> > > + uint8_t data[4096];
> >
> > If you do have an ioctl, use proper data types. These are not the
> > correct ones (hint, __u32 and __u8).
> >
> > > +};
> > > +
> > > +#define BASE_TTYIOC_PRIVATE 0xA0
> > > +/* Set EZConfig.
> > > + * After this ioctl call, the driver restarts the si4455,
> > > + * then apply the new configuration and patch.
> > > + */
> > > +#define SI4455_IOC_SEZC _IOW('T', \
> > > + BASE_TTYIOC_PRIVATE + 0x01, \
> > > + struct si4455_iocbuff)
> >
> > Why does a serial driver have private ioctls? Please no, don't do that.
>
> I checked the ioctl.h and serial_core.h, but I not found any similar
> definition, like BASE_VIDIOC_PRIVATE in videodev2.h.
> In this case the name of macro BASE_TTYIOC_PRIVATE means the base value of
> special ioctl commands owned by this driver.
My point is, a serial driver should NOT have any custom ioctls.
> I can change it to BASE_TTYIOC or SI4455_IOC_BASE
>
> > Implement the basic serial driver first, and then we can talk about
> > "custom" configurations and the like, using the correct apis.
>
> Without the SI4455_IOC_SEZC call, the driver can't configure the Si4455 and
> not working at all.
> The cofiguration for interface is provided by user for application.
That is what a device tree is for, to configure the device to have the
correct system configuration, why can't that be the same here?
> It contains the base frequency, channel spacing, modulation, and a lot
> of more stuff, and generated by Silicon Labs Wireless Development
> Suite.
> The generated configuration is in a non public(compressed,
> encrypted...who knows) format, so without this the driver can't
> provide configuration parameters to Si4455.
So we have to take a "custom" userspace blob and send it to the device
to configure it properly? Like Jiri said, sounds like firmware, so just
use that interface instead.
thanks,
greg k-h
RE: [PATCH] ath10k: Remove voltage regulator votes during wifi disable
> -Original Message-
> From: Brian Norris
> Sent: Thursday, December 10, 2020 11:44 PM
> To: Rakesh Pillai
> Cc: ath10k ; linux-wireless wirel...@vger.kernel.org>; Linux Kernel ;
> Doug Anderson ; kua...@chromium.org;
> Youghandhar Chintala
> Subject: Re: [PATCH] ath10k: Remove voltage regulator votes during wifi
> disable
>
> On Thu, Dec 10, 2020 at 7:09 AM Rakesh Pillai
> wrote:
> > --- a/drivers/net/wireless/ath/ath10k/snoc.c
> > +++ b/drivers/net/wireless/ath/ath10k/snoc.c
> > @@ -1045,14 +1085,18 @@ static int ath10k_snoc_hif_power_up(struct
> ath10k *ar,
> > ret = ath10k_snoc_init_pipes(ar);
> > if (ret) {
> > ath10k_err(ar, "failed to initialize CE: %d\n", ret);
> > - goto err_wlan_enable;
> > + goto err_free_rri;
> > }
> >
> > return 0;
> >
> > -err_wlan_enable:
> > +err_free_rri:
> > + ath10k_ce_free_rri(ar);
>
> This change in the error path seems to be an unrelated (but correct)
> fix. It deserves its own patch, I think.
Sure Brian. I will post this error handling fix as a separate patch, and also
post a v2 for this patchset.
Re: [PATCH v2 5/5] clk: qcom: gcc: Add clock driver for SM8350
On 10-12-20, 12:43, Stephen Boyd wrote:
> Quoting Vinod Koul (2020-12-07 22:47:02)
> > +config SM_GCC_8350
> > + tristate "SM8350 Global Clock Controller"
> > + select QCOM_GDSC
> > + help
> > + Support for the global clock controller on SM8350 devices.
> > + Say Y if you want to use peripheral devices such as UART,
> > + SPI, I2C, USB, SD/UFS, PCIe etc.
> > +
> > +
>
> Why double newline?
Will drop
> > +#include
> > +#include
>
> Is this include used?
Will check this and others and drop unused ones
>
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> Please add newline here
>
> > +#include
>
> Please add newline here
Ok to both
> > +static const struct clk_parent_data gcc_parent_data_0[] = {
> > + { .fw_name = "bi_tcxo", .name = "bi_tcxo" },
> > + { .hw = _gpll0.clkr.hw },
> > + { .hw = _gpll0_out_even.clkr.hw },
> > + { .fw_name = "core_bi_pll_test_se", .name = "core_bi_pll_test_se" },
>
> Is this .fw_name in the binding? Please remove .name everywhere in this
> driver as it shouldn't be necessary.
Ack will drop
> > +static const struct clk_parent_data gcc_parent_data_13[] = {
> > + { .fw_name = "usb3_phy_wrapper_gcc_usb30_pipe_clk", .name =
>
> Is this documented in the binding?
Not yet, will update
> > +static struct clk_rcg2 gcc_sdcc2_apps_clk_src = {
> > + .cmd_rcgr = 0x1400c,
> > + .mnd_width = 8,
> > + .hid_width = 5,
> > + .parent_map = gcc_parent_map_6,
> > + .freq_tbl = ftbl_gcc_sdcc2_apps_clk_src,
> > + .clkr.hw.init = &(struct clk_init_data){
> > + .name = "gcc_sdcc2_apps_clk_src",
> > + .parent_data = gcc_parent_data_6,
> > + .num_parents = 6,
> > + .flags = CLK_SET_RATE_PARENT,
> > + .ops = _rcg2_ops,
>
> Please use floor ops per Doug's recent patch.
Yes
> > +static struct clk_branch gcc_camera_ahb_clk = {
> > + .halt_reg = 0x26004,
> > + .halt_check = BRANCH_HALT_DELAY,
> > + .hwcg_reg = 0x26004,
> > + .hwcg_bit = 1,
> > + .clkr = {
> > + .enable_reg = 0x26004,
> > + .enable_mask = BIT(0),
> > + .hw.init = &(struct clk_init_data){
> > + .name = "gcc_camera_ahb_clk",
> > + .flags = CLK_IS_CRITICAL,
>
> Why is it critical? Can we just enable it in driver probe and stop
> modeling it as a clk?
it does not have a parent we control, yeah it would make sense to do
that. Tanya do you folks agree ..?
> > +static struct clk_branch gcc_video_axi0_clk = {
> > + .halt_reg = 0x28010,
> > + .halt_check = BRANCH_HALT_SKIP,
>
> Do these need to be halt skip? Is the video axi clk stuff still broken?
I will check on this and update accordingly
> > +static int gcc_sm8350_probe(struct platform_device *pdev)
> > +{
> > + struct regmap *regmap;
> > + int ret;
> > +
> > + regmap = qcom_cc_map(pdev, _sm8350_desc);
> > + if (IS_ERR(regmap)) {
> > + dev_err(>dev, "Failed to map gcc registers\n");
> > + return PTR_ERR(regmap);
> > + }
> > +
> > + ret = qcom_cc_register_rcg_dfs(regmap, gcc_dfs_clocks,
> > ARRAY_SIZE(gcc_dfs_clocks));
> > + if (ret)
> > + return ret;
> > +
> > + /* FORCE_MEM_CORE_ON for ufs phy ice core clocks */
>
> Why?
So I understood that this needs to be set so that ufs clocks can
propagate to ufs mem stuff..
--
~Vinod
Re: [PATCH v2] Serial: silabs si4455 serial driver
On 10. 12. 20, 20:46, József Horváth wrote: Implement the basic serial driver first, and then we can talk about "custom" configurations and the like, using the correct apis. Without the SI4455_IOC_SEZC call, the driver can't configure the Si4455 and not working at all. The cofiguration for interface is provided by user for application. It contains the base frequency, channel spacing, modulation, and a lot of more stuff, and generated by Silicon Labs Wireless Development Suite. The generated configuration is in a non public(compressed, encrypted...who knows) format, so without this the driver can't provide configuration parameters to Si4455. request_firmware() comes to my mind then. thanks, -- js suse labs
Re: [PATCH 5.9 00/75] 5.9.14-rc1 review
On Thu, 10 Dec 2020 at 20:08, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.9.14 release. > There are 75 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat, 12 Dec 2020 14:25:47 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.9.14-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.9.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 5.9.14-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.9.y git commit: 81beabff31a7c60d2065f5711ffda6d97776a728 git describe: v5.9.13-77-g81beabff31a7 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.9.y/build/v5.9.13-77-g81beabff31a7 No regressions (compared to build v5.9.13) No fixes (compared to build v5.9.13) Ran 57691 total tests in the following environments and test suites. Environments -- - arc - arm - arm64 - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - mips - nxp-ls2088 - parisc - powerpc - qemu-arm-clang - qemu-arm64-clang - qemu-arm64-kasan - qemu-i386-clang - qemu-x86_64-clang - qemu-x86_64-kasan - qemu-x86_64-kcsan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - riscv - s390 - sh - sparc - x15 - x86 - x86-kasan Test Suites --- * build * linux-log-parser * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-fs-tests * ltp-hugetlb-tests * ltp-mm-tests * ltp-sched-tests * ltp-syscalls-tests * perf * v4l2-compliance * kvm-unit-tests * ltp-commands-tests * ltp-containers-tests * ltp-dio-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-tracing-tests * network-basic-tests * ltp-controllers-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-nptl-tests * ltp-open-posix-tests * ltp-pty-tests * ltp-securebits-tests * ltp-fcntl-locktests-tests * kunit * rcutorture * fwts * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH] genksyms: Ignore module scoped _Static_assert()
On Thu, 10 Dec 2020 17:25:30 +0100 Marco Elver wrote: > On Thu, 10 Dec 2020 at 14:29, Miguel Ojeda > wrote: > > On Thu, Dec 10, 2020 at 11:35 AM Marco Elver wrote: > > > > > > It looks like there's no clear MAINTAINER for this. :-/ > > > It'd still be good to fix this for 5.11. > > > > Richard seems to be the author, not sure if he picks patches (CC'd). > > > > I guess Masahiro or akpm (Cc'd) would be two options; otherwise, I > > could pick it up through compiler attributes (stretching the > > definition...). > > Thanks for the info. I did find that there's an alternative patch to > fix _Static_assert() with genksyms that was sent 3 days after mine > (it's simpler, but might miss cases). I've responded there ( > https://lkml.kernel.org/r/x9ji5kpwoo23w...@elver.google.com ). > > Now we have some choice. I'd argue for this patch, because it's not > doing preprocessor workarounds, but in the end I won't make that call. > :-) I have https://lkml.kernel.org/r/20201203230955.1482058-1-a...@kernel.org queued for later this week.
Re: x86/ioapic: Cleanup the timer_works() irqflags mess
On 10.12.20 21:15, Thomas Gleixner wrote: Mark tripped over the creative irqflags handling in the IO-APIC timer delivery check which ends up doing: local_irq_save(flags); local_irq_enable(); local_irq_restore(flags); which triggered a new consistency check he's working on required for replacing the POPF based restore with a conditional STI. That code is a historical mess and none of this is needed. Make it straightforward use local_irq_disable()/enable() as that's all what is required. It is invoked from interrupt enabled code nowadays. Reported-by: Mark Rutland Signed-off-by: Thomas Gleixner Tested-by: Mark Rutland Reviewed-by: Juergen Gross Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v2 4/5] clk: qcom: clk-alpha-pll: Add support for Lucid 5LPE PLL
On 10-12-20, 12:36, Stephen Boyd wrote:
> Quoting Vinod Koul (2020-12-07 22:47:01)
> > diff --git a/drivers/clk/qcom/clk-alpha-pll.c
> > b/drivers/clk/qcom/clk-alpha-pll.c
> > index 564431130a76..6a399663d564 100644
> > --- a/drivers/clk/qcom/clk-alpha-pll.c
> > +++ b/drivers/clk/qcom/clk-alpha-pll.c
> > @@ -146,6 +146,12 @@ EXPORT_SYMBOL_GPL(clk_alpha_pll_regs);
> > /* LUCID PLL specific settings and offsets */
> > #define LUCID_PCAL_DONEBIT(27)
> >
> > +/* LUCID 5LPE PLL specific settings and offsets */
> > +#define LUCID_5LPE_PCAL_DONE BIT(11)
> > +#define LUCID_5LPE_ENABLE_VOTE_RUN BIT(21)
> > +#define LUCID_5LPE_PLL_LATCH_INPUT BIT(14)
> > +#define LUCID_5LPE_ALPHA_PLL_ACK_LATCH BIT(13)
>
> Sort these by bit or define name?
Okay will sort by bit
>
> > +
> > #define pll_alpha_width(p) \
> > ((PLL_ALPHA_VAL_U(p) - PLL_ALPHA_VAL(p) == 4) ? \
> > ALPHA_REG_BITWIDTH : ALPHA_REG_16BIT_WIDTH)
> > @@ -1561,3 +1567,220 @@ const struct clk_ops
> > clk_alpha_pll_postdiv_lucid_ops = {
> > .set_rate = clk_alpha_pll_postdiv_fabia_set_rate,
> > };
> > EXPORT_SYMBOL_GPL(clk_alpha_pll_postdiv_lucid_ops);
> > +
> > +static int alpha_pll_lucid_5lpe_enable(struct clk_hw *hw)
> > +{
> > + struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
> > + u32 val;
> > + int ret;
> > +
> > + ret = regmap_read(pll->clkr.regmap, PLL_USER_CTL(pll), );
> > + if (ret)
> > + return ret;
> > +
> > + /* If in FSM mode, just vote for it */
> > + if (val & LUCID_5LPE_ENABLE_VOTE_RUN) {
> > + ret = clk_enable_regmap(hw);
> > + if (ret)
> > + return ret;
> > + return wait_for_pll_enable_lock(pll);
> > + }
> > +
> > + /* Check if PLL is already enabled */
>
> Yeah that's obvious, but then what?
then dont proceed :) will update
> > + ret = trion_pll_is_enabled(pll, pll->clkr.regmap);
> > + if (ret < 0)
> > + return ret;
> > +
> > + ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll),
> > PLL_RESET_N, PLL_RESET_N);
> > + if (ret)
> > + return ret;
> > +
> > + /* Set operation mode to RUN */
>
> This comment is worthless.
Will drop
>
> > + regmap_write(pll->clkr.regmap, PLL_OPMODE(pll), PLL_RUN);
> > +
> > + ret = wait_for_pll_enable_lock(pll);
> > + if (ret)
> > + return ret;
> > +
> > + /* Enable the PLL outputs */
> > + ret = regmap_update_bits(pll->clkr.regmap, PLL_USER_CTL(pll),
> > PLL_OUT_MASK, PLL_OUT_MASK);
> > + if (ret)
> > + return ret;
> > +
> > + /* Enable the global PLL outputs */
> > + ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll),
> > PLL_OUTCTRL, PLL_OUTCTRL);
> > + if (ret)
> > + return ret;
> > +
> > + /* Ensure that the write above goes through before returning. */
> > + mb();
>
> Regmap has a memory barrier in writel. Drop this.
yes
>
> > + return ret;
> > +}
> > +
> > +static void alpha_pll_lucid_5lpe_disable(struct clk_hw *hw)
> > +{
> > + struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
> > + u32 val;
> > + int ret;
> > +
> > + ret = regmap_read(pll->clkr.regmap, PLL_USER_CTL(pll), );
> > + if (ret)
> > + return;
> > +
> > + /* If in FSM mode, just unvote it */
> > + if (val & LUCID_5LPE_ENABLE_VOTE_RUN) {
> > + clk_disable_regmap(hw);
> > + return;
> > + }
> > +
> > + /* Disable the global PLL output */
> > + ret = regmap_update_bits(pll->clkr.regmap, PLL_MODE(pll),
> > PLL_OUTCTRL, 0);
> > + if (ret)
> > + return;
> > +
> > + /* Disable the PLL outputs */
> > + ret = regmap_update_bits(pll->clkr.regmap, PLL_USER_CTL(pll),
> > PLL_OUT_MASK, 0);
> > + if (ret)
> > + return;
> > +
> > + /* Place the PLL mode in STANDBY */
> > + regmap_write(pll->clkr.regmap, PLL_OPMODE(pll), PLL_STANDBY);
> > +}
> > +
> > +/*
> > + * The Lucid 5LPE PLL requires a power-on self-calibration which happens
> > + * when the PLL comes out of reset. Calibrate in case it is not completed.
> > + */
> > +static int alpha_pll_lucid_5lpe_prepare(struct clk_hw *hw)
> > +{
> > + struct clk_alpha_pll *pll = to_clk_alpha_pll(hw);
> > + struct clk_hw *p;
> > + u32 regval;
>
> Can you use u32 val? And also include a patch to replace the couple
> times where there is 'regval' in this file. The former is shorter and
> used far more in qcom clk code.
Will do
>
> > + int ret;
> > +
> > + /* Return early if calibration is not needed. */
> > + regmap_read(pll->clkr.regmap, PLL_MODE(pll), );
> > + if (regval & LUCID_5LPE_PCAL_DONE)
> > + return 0;
> > +
> > + p =
linux-next: build failure after merge of the keys tree
Hi all,
After merging the keys tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/linux/cred.h:13,
from security/integrity/ima/ima_mok.c:12:
security/integrity/ima/ima_mok.c: In function 'ima_mok_init':
include/linux/key.h:292:29: warning: passing argument 7 of 'keyring_alloc'
makes pointer from integer without a cast [-Wint-conversion]
292 | #define KEY_ALLOC_SET_KEEP 0x0020 /* Set the KEEP flag on the
key/keyring */
| ^~
| |
| int
security/integrity/ima/ima_mok.c:42:5: note: in expansion of macro
'KEY_ALLOC_SET_KEEP'
42 | KEY_ALLOC_SET_KEEP,
| ^~
include/linux/key.h:410:30: note: expected 'struct key_restriction *' but
argument is of type 'int'
410 | struct key_restriction *restrict_link,
| ^
security/integrity/ima/ima_mok.c:43:5: error: passing argument 8 of
'keyring_alloc' from incompatible pointer type
[-Werror=incompatible-pointer-types]
43 | restriction, NULL);
| ^~~
| |
| struct key_restriction *
In file included from include/linux/cred.h:13,
from security/integrity/ima/ima_mok.c:12:
include/linux/key.h:411:18: note: expected 'struct key *' but argument is of
type 'struct key_restriction *'
411 | struct key *dest);
| ^~~~
security/integrity/ima/ima_mok.c:36:26: error: too many arguments to function
'keyring_alloc'
36 | ima_blacklist_keyring = keyring_alloc(".ima_blacklist",
| ^
In file included from include/linux/cred.h:13,
from security/integrity/ima/ima_mok.c:12:
include/linux/key.h:406:20: note: declared here
406 | extern struct key *keyring_alloc(const char *description, kuid_t uid,
kgid_t gid,
|^
Caused by commit
33c36b2053de ("certs: Fix blacklist flag type confusion")
I have applied the following fix patch for today:
From: Stephen Rothwell
Date: Fri, 11 Dec 2020 15:46:09 +1100
Subject: [PATCH] fixup for "certs: Fix blacklist flag type confusion"
Signed-off-by: Stephen Rothwell
---
security/integrity/ima/ima_mok.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/security/integrity/ima/ima_mok.c b/security/integrity/ima/ima_mok.c
index ce8871d96f12..5594dd38ab04 100644
--- a/security/integrity/ima/ima_mok.c
+++ b/security/integrity/ima/ima_mok.c
@@ -38,8 +38,7 @@ __init int ima_mok_init(void)
(KEY_POS_ALL & ~KEY_POS_SETATTR) |
KEY_USR_VIEW | KEY_USR_READ |
KEY_USR_WRITE | KEY_USR_SEARCH,
- KEY_ALLOC_NOT_IN_QUOTA,
- KEY_ALLOC_SET_KEEP,
+ KEY_ALLOC_NOT_IN_QUOTA | KEY_ALLOC_SET_KEEP,
restriction, NULL);
if (IS_ERR(ima_blacklist_keyring))
--
2.29.2
--
Cheers,
Stephen Rothwell
pgpOFxzQdSKSq.pgp
Description: OpenPGP digital signature
Re: [PATCH 5/5] USB: typec: tcpci: Add Bleed discharge to POWER_CONTROL definition
Hi Greg, I have a patch ready to enable BLEED_DISCHARGE in tcpci code. I will send that in once you merge this patch to usb-next. Thanks, Badhri On Thu, Dec 10, 2020 at 10:56 AM Badhri Jagan Sridharan wrote: > > Hi Guenter, > > Yes I will send a follow up patch to update tcpci_maxim.c. > > Thanks, > Badhri > > > On Thu, Dec 10, 2020 at 9:45 AM Guenter Roeck wrote: > > > > On Thu, Dec 10, 2020 at 05:05:21PM +0100, Greg Kroah-Hartman wrote: > > > From: Badhri Jagan Sridharan > > > > > > "Table 4-19. POWER_CONTROL Register Definition" from tcpci spec > > > defines BIT(3) as the control bit for bleed discharge. > > > > > > Cc: Guenter Roeck > > > Cc: Heikki Krogerus > > > Cc: Kyle Tso > > > Signed-off-by: Badhri Jagan Sridharan > > > Signed-off-by: Will McVicker > > > Signed-off-by: Greg Kroah-Hartman > > > > Just wondering - is that going to be used in a follow-up commit ? > > > > Reviewed-by: Guenter Roeck > > > > Guenter > > > > > --- > > > drivers/usb/typec/tcpm/tcpci.h | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/drivers/usb/typec/tcpm/tcpci.h > > > b/drivers/usb/typec/tcpm/tcpci.h > > > index 116a69c85e38..c3c7d07d9b4e 100644 > > > --- a/drivers/usb/typec/tcpm/tcpci.h > > > +++ b/drivers/usb/typec/tcpm/tcpci.h > > > @@ -72,6 +72,7 @@ > > > > > > #define TCPC_POWER_CTRL 0x1c > > > #define TCPC_POWER_CTRL_VCONN_ENABLE BIT(0) > > > +#define TCPC_POWER_CTRL_BLEED_DISCHARGE BIT(3) > > > #define TCPC_POWER_CTRL_AUTO_DISCHARGE BIT(4) > > > #define TCPC_FAST_ROLE_SWAP_EN BIT(7) > > > > > > -- > > > 2.29.2 > > >
Re: [stable] ext4 fscrypt_get_encryption_info() circular locking dependency
On (20/12/11 13:08), Sergey Senozhatsky wrote:
> >
> > How interested are you in having this fixed? Did you encounter an actual
> > deadlock or just the lockdep report?
>
Got one more. fscrypt_get_encryption_info() again, but from ext4_lookup().
[ 162.840909] kswapd0/80 is trying to acquire lock:
[ 162.840912] 78ea628f (jbd2_handle){}, at:
start_this_handle+0x1f9/0x859
[ 162.840919]
but task is already holding lock:
[ 162.840922] 314ed5a0 (fs_reclaim){+.+.}, at:
__fs_reclaim_acquire+0x5/0x2f
[ 162.840929]
which lock already depends on the new lock.
[ 162.840932]
the existing dependency chain (in reverse order) is:
[ 162.840934]
-> #2 (fs_reclaim){+.+.}:
[ 162.840940]kmem_cache_alloc_trace+0x44/0x28b
[ 162.840944]mempool_create_node+0x46/0x92
[ 162.840947]fscrypt_initialize+0xa0/0xbf
[ 162.840950]fscrypt_get_encryption_info+0xa4/0x774
[ 162.840953]fscrypt_setup_filename+0x99/0x2d1
[ 162.840956]__fscrypt_prepare_lookup+0x25/0x6b
[ 162.840960]ext4_lookup+0x1b2/0x323
[ 162.840963]path_openat+0x9a5/0x156d
[ 162.840966]do_filp_open+0x97/0x13e
[ 162.840970]do_sys_open+0x128/0x3a3
[ 162.840973]do_syscall_64+0x6f/0x22a
[ 162.840977]entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 162.840979]
-> #1 (fscrypt_init_mutex){+.+.}:
[ 162.840983]mutex_lock_nested+0x20/0x26
[ 162.840986]fscrypt_initialize+0x20/0xbf
[ 162.840989]fscrypt_get_encryption_info+0xa4/0x774
[ 162.840992]fscrypt_inherit_context+0xbe/0xe6
[ 162.840995]__ext4_new_inode+0x11ee/0x1631
[ 162.840999]ext4_mkdir+0x112/0x416
[ 162.841002]vfs_mkdir2+0x135/0x1c6
[ 162.841004]do_mkdirat+0xc3/0x138
[ 162.841007]do_syscall_64+0x6f/0x22a
[ 162.841011]entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 162.841012]
-> #0 (jbd2_handle){}:
[ 162.841017]start_this_handle+0x21c/0x859
[ 162.841019]jbd2__journal_start+0xa2/0x282
[ 162.841022]ext4_release_dquot+0x58/0x93
[ 162.841025]dqput+0x196/0x1ec
[ 162.841028]__dquot_drop+0x8d/0xb2
[ 162.841032]ext4_clear_inode+0x22/0x8c
[ 162.841035]ext4_evict_inode+0x127/0x662
[ 162.841038]evict+0xc0/0x241
[ 162.841041]dispose_list+0x36/0x54
[RFC PATCH] pinctrl: add helper to expose pinctrl state in debugfs
BeagleBoard.org [0] currently uses an out-of-tree driver called
bone-pinmux-helper [1] developed by Pantelis Antoniou [2] back in 2013.
The driver assists users of our BeagleBone and PocketBeagle boards in
rapid prototyping by allowing them to change at run-time between defined
set of pinctrl states [3] for each pin on the expansion connectors [4].
This is achieved by exposing a 'state' file in sysfs for each pin which
is used by our 'config-pin' utility [5].
Our goal is to eliminate all out-of-tree drivers for BeagleBoard.org
boards and thus I have been working to replace bone-pinmux-helper with a
new driver that could be acceptable upstream. My understanding is that
debugfs, unlike sysfs, could be the appropriate mechanism to expose such
functionality.
Here is an example of how pin P9.14 on the BeagleBone Black expansion
connector [6] would be represented in device tree:
_pinmux {
/* P9_14 (ZCZ ball U14) gpio1_18 */
P9_14_default_pin: pinmux_P9_14_default_pin { pinctrl-single,pins = <
AM33XX_IOPAD(0x0848, PIN_OUTPUT_PULLDOWN | INPUT_EN |
MUX_MODE7) >; };
P9_14_gpio_pin: pinmux_P9_14_gpio_pin { pinctrl-single,pins = <
AM33XX_IOPAD(0x0848, PIN_OUTPUT | INPUT_EN | MUX_MODE7) >; };
P9_14_gpio_pu_pin: pinmux_P9_14_gpio_pu_pin { pinctrl-single,pins = <
AM33XX_IOPAD(0x0848, PIN_OUTPUT_PULLUP | INPUT_EN | MUX_MODE7)
>; };
P9_14_gpio_pd_pin: pinmux_P9_14_gpio_pd_pin { pinctrl-single,pins = <
AM33XX_IOPAD(0x0848, PIN_OUTPUT_PULLDOWN | INPUT_EN |
MUX_MODE7) >; };
P9_14_gpio_input_pin: pinmux_P9_14_gpio_input_pin { pinctrl-single,pins
= <
AM33XX_IOPAD(0x0848, PIN_INPUT | MUX_MODE7) >; };
P9_14_pwm_pin: pinmux_P9_14_pwm_pin { pinctrl-single,pins = <
AM33XX_IOPAD(0x0848, PIN_OUTPUT_PULLDOWN | INPUT_EN |
MUX_MODE6) >; };
};
{
/* P9_14 (ZCZ ball U14) */
P9_14_pinmux {
compatible = "pinctrl,state-helper";
status = "okay";
pinctrl-names = "default", "gpio", "gpio_pu", "gpio_pd",
"gpio_input", "pwm";
pinctrl-0 = <_14_default_pin>;
pinctrl-1 = <_14_gpio_pin>;
pinctrl-2 = <_14_gpio_pu_pin>;
pinctrl-3 = <_14_gpio_pd_pin>;
pinctrl-4 = <_14_gpio_input_pin>;
pinctrl-5 = <_14_pwm_pin>;
};
};
I used the compatible string "pinctrl,state-helper" but would appreciate
advice on how to best name this. Should I create a new vendor prefix?
The P9_14_pinmux entry would cause pinctrl-state-helper to be probed.
The driver would create the corresponding pinctrl state file in debugfs
for the pin. Here is an example of how the state can be read and
written from userspace:
root@beaglebone:~# cat /sys/kernel/debug/ocp\:P9_14_pinmux/state
default
root@beaglebone:~# echo pwm > /sys/kernel/debug/ocp\:P9_14_pinmux/state
root@beaglebone:~# cat /sys/kernel/debug/ocp\:P9_14_pinmux/state
pwm
I would very much appreciate feedback on both this general concept, and
also specific areas in which the code should be changed to be acceptable
upstream.
Thank you!
Drew
[0] http://beagleboard.org/latest-images
[1]
https://github.com/beagleboard/linux/blob/5.4/drivers/misc/cape/beaglebone/bone-pinmux-helper.c
[2]
https://github.com/RobertCNelson/linux-dev/blob/master/patches/drivers/ti/gpio/0001-BeagleBone-pinmux-helper.patch
[3]
https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v5.4.x-ti-overlays/src/arm/am335x-bone-common-univ.dtsi#L2084
[4]
https://github.com/beagleboard/beaglebone-black/wiki/System-Reference-Manual#section-7-1
[5]
https://github.com/beagleboard/bb.org-overlays/blob/master/tools/beaglebone-universal-io/config-pin
[6] https://beagleboard.org/Support/bone101/#headers
Cc: Pantelis Antoniou
Cc: Linus Walleij
Cc: Tony Lindgren
Signed-off-by: Drew Fustini
---
drivers/pinctrl/Kconfig| 10 ++
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/pinctrl-state-helper.c | 233 +
3 files changed, 244 insertions(+)
create mode 100644 drivers/pinctrl/pinctrl-state-helper.c
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 8828613c4e0e..4faed5c8c83b 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -255,6 +255,16 @@ config PINCTRL_SINGLE
help
This selects the device tree based generic pinctrl driver.
+config PINCTRL_STATE_HELPER
+ tristate "Helper to expose pinctrl state to debugfs"
+ depends on OF
+ depends on HAS_IOMEM
+ select GENERIC_PINCTRL_GROUPS
+ select GENERIC_PINMUX_FUNCTIONS
+ select GENERIC_PINCONF
+ help
+ This selects the device tree based generic pinctrl driver.
+
config PINCTRL_SIRF
bool "CSR SiRFprimaII pin controller driver"
depends on ARCH_SIRF
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
Re: [PATCH v2 3/5] dt-bindings: clock: Add SM8350 GCC clock bindings
On 10-12-20, 12:31, Stephen Boyd wrote: > Quoting Vinod Koul (2020-12-09 22:11:59) > > On 09-12-20, 22:01, Rob Herring wrote: > > > On Tue, Dec 08, 2020 at 12:17:00PM +0530, Vinod Koul wrote: > > > > > > +required: > > > > + - compatible > > > > + - clocks > > > > + - clock-names > > > > + - reg > > > > + - '#clock-cells' > > > > + - '#reset-cells' > > > > > > You may or may not have power domains? > > > > I have not added them in the driver yet, so I dont think it made sense > > to add them when they are not present. For basic stuff it is not > > required but eventually yes, so I plan to update binding and driver at > > that time > > > > They should still be required in the binding though if the hardware has > power domains. It's not like the hardware doesn't have power domains > already or can gain that ability after the fact. The driver should deal > with it when it is ready. Yeah that is a valid argument, I will add and send updated revision Thanks -- ~Vinod
[PATCH v4 6/7] mm: memcontrol: convert NR_FILE_PMDMAPPED account to pages
The unit of NR_FILE_PMDMAPPED is HPAGE_PMD_NR. Convert NR_FILE_PMDMAPPED
account to pages.
Signed-off-by: Muchun Song
---
drivers/base/node.c| 3 +--
fs/proc/meminfo.c | 2 +-
include/linux/mmzone.h | 3 ++-
mm/rmap.c | 6 --
4 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/base/node.c b/drivers/base/node.c
index 7a66aefe4e46..d02d86aec19f 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -465,8 +465,7 @@ static ssize_t node_read_meminfo(struct device *dev,
nid, K(node_page_state(pgdat, NR_SHMEM_THPS)),
nid, K(node_page_state(pgdat, NR_SHMEM_PMDMAPPED)),
nid, K(node_page_state(pgdat, NR_FILE_THPS)),
-nid, K(node_page_state(pgdat, NR_FILE_PMDMAPPED) *
- HPAGE_PMD_NR)
+nid, K(node_page_state(pgdat, NR_FILE_PMDMAPPED))
#endif
);
len += hugetlb_report_node_meminfo(buf, len, nid);
diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index c61f440570f9..6fa761c9cc78 100644
--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -137,7 +137,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
show_val_kb(m, "FileHugePages: ",
global_node_page_state(NR_FILE_THPS));
show_val_kb(m, "FilePmdMapped: ",
- global_node_page_state(NR_FILE_PMDMAPPED) * HPAGE_PMD_NR);
+ global_node_page_state(NR_FILE_PMDMAPPED));
#endif
#ifdef CONFIG_CMA
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index d6b13b9327be..c587343a3884 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -218,7 +218,8 @@ static __always_inline bool vmstat_item_print_in_thp(enum
node_stat_item item)
return item == NR_ANON_THPS ||
item == NR_FILE_THPS ||
item == NR_SHMEM_THPS ||
- item == NR_SHMEM_PMDMAPPED;
+ item == NR_SHMEM_PMDMAPPED ||
+ item == NR_FILE_PMDMAPPED;
}
/*
diff --git a/mm/rmap.c b/mm/rmap.c
index 3089ad6bf468..e383c5619501 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1222,7 +1222,8 @@ void page_add_file_rmap(struct page *page, bool compound)
__mod_lruvec_page_state(page, NR_SHMEM_PMDMAPPED,
HPAGE_PMD_NR);
else
- __inc_node_page_state(page, NR_FILE_PMDMAPPED);
+ __mod_lruvec_page_state(page, NR_FILE_PMDMAPPED,
+ HPAGE_PMD_NR);
} else {
if (PageTransCompound(page) && page_mapping(page)) {
VM_WARN_ON_ONCE(!PageLocked(page));
@@ -1264,7 +1265,8 @@ static void page_remove_file_rmap(struct page *page, bool
compound)
__mod_lruvec_page_state(page, NR_SHMEM_PMDMAPPED,
-HPAGE_PMD_NR);
else
- __dec_node_page_state(page, NR_FILE_PMDMAPPED);
+ __mod_lruvec_page_state(page, NR_FILE_PMDMAPPED,
+ -HPAGE_PMD_NR);
} else {
if (!atomic_add_negative(-1, >_mapcount))
return;
--
2.11.0
[PATCH v4 7/7] mm: memcontrol: make the slab calculation consistent
Although the ratio of the slab is one, we also should read the ratio
from the related memory_stats instead of hard-coding. And the local
variable of size is already the value of slab_unreclaimable. So we
do not need to read again.
We can drop the ratio in struct memory_stat. This can make the code
clean and simple. And get rid of the awkward mix of static and runtime
initialization of the memory_stats table.
Signed-off-by: Muchun Song
---
mm/memcontrol.c | 105 +++-
1 file changed, 66 insertions(+), 39 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index a40797a27f87..eec44918d373 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1511,49 +1511,71 @@ static bool mem_cgroup_wait_acct_move(struct mem_cgroup
*memcg)
struct memory_stat {
const char *name;
- unsigned int ratio;
unsigned int idx;
};
static const struct memory_stat memory_stats[] = {
- { "anon", PAGE_SIZE, NR_ANON_MAPPED },
- { "file", PAGE_SIZE, NR_FILE_PAGES },
- { "kernel_stack", 1024, NR_KERNEL_STACK_KB },
- { "pagetables", PAGE_SIZE, NR_PAGETABLE },
- { "percpu", 1, MEMCG_PERCPU_B },
- { "sock", PAGE_SIZE, MEMCG_SOCK },
- { "shmem", PAGE_SIZE, NR_SHMEM },
- { "file_mapped", PAGE_SIZE, NR_FILE_MAPPED },
- { "file_dirty", PAGE_SIZE, NR_FILE_DIRTY },
- { "file_writeback", PAGE_SIZE, NR_WRITEBACK },
+ { "anon", NR_ANON_MAPPED },
+ { "file", NR_FILE_PAGES },
+ { "kernel_stack", NR_KERNEL_STACK_KB },
+ { "pagetables", NR_PAGETABLE},
+ { "percpu", MEMCG_PERCPU_B },
+ { "sock", MEMCG_SOCK },
+ { "shmem", NR_SHMEM},
+ { "file_mapped",NR_FILE_MAPPED },
+ { "file_dirty", NR_FILE_DIRTY },
+ { "file_writeback", NR_WRITEBACK},
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
- { "anon_thp", PAGE_SIZE, NR_ANON_THPS },
- { "file_thp", PAGE_SIZE, NR_FILE_THPS },
- { "shmem_thp", PAGE_SIZE, NR_SHMEM_THPS },
+ { "anon_thp", NR_ANON_THPS},
+ { "file_thp", NR_FILE_THPS},
+ { "shmem_thp", NR_SHMEM_THPS },
#endif
- { "inactive_anon", PAGE_SIZE, NR_INACTIVE_ANON },
- { "active_anon", PAGE_SIZE, NR_ACTIVE_ANON },
- { "inactive_file", PAGE_SIZE, NR_INACTIVE_FILE },
- { "active_file", PAGE_SIZE, NR_ACTIVE_FILE },
- { "unevictable", PAGE_SIZE, NR_UNEVICTABLE },
-
- /*
-* Note: The slab_reclaimable and slab_unreclaimable must be
-* together and slab_reclaimable must be in front.
-*/
- { "slab_reclaimable", 1, NR_SLAB_RECLAIMABLE_B },
- { "slab_unreclaimable", 1, NR_SLAB_UNRECLAIMABLE_B },
+ { "inactive_anon", NR_INACTIVE_ANON},
+ { "active_anon",NR_ACTIVE_ANON },
+ { "inactive_file", NR_INACTIVE_FILE},
+ { "active_file",NR_ACTIVE_FILE },
+ { "unevictable",NR_UNEVICTABLE },
+ { "slab_reclaimable", NR_SLAB_RECLAIMABLE_B },
+ { "slab_unreclaimable", NR_SLAB_UNRECLAIMABLE_B },
/* The memory events */
- { "workingset_refault_anon", 1, WORKINGSET_REFAULT_ANON },
- { "workingset_refault_file", 1, WORKINGSET_REFAULT_FILE },
- { "workingset_activate_anon", 1, WORKINGSET_ACTIVATE_ANON },
- { "workingset_activate_file", 1, WORKINGSET_ACTIVATE_FILE },
- { "workingset_restore_anon", 1, WORKINGSET_RESTORE_ANON },
- { "workingset_restore_file", 1, WORKINGSET_RESTORE_FILE },
- { "workingset_nodereclaim", 1, WORKINGSET_NODERECLAIM },
+ { "workingset_refault_anon",WORKINGSET_REFAULT_ANON },
+ { "workingset_refault_file",WORKINGSET_REFAULT_FILE },
+ { "workingset_activate_anon", WORKINGSET_ACTIVATE_ANON},
+ { "workingset_activate_file", WORKINGSET_ACTIVATE_FILE},
+ { "workingset_restore_anon",WORKINGSET_RESTORE_ANON },
+ { "workingset_restore_file",WORKINGSET_RESTORE_FILE },
+ { "workingset_nodereclaim", WORKINGSET_NODERECLAIM },
};
+/* Translate stat items to the correct unit for memory.stat output */
+static int memcg_page_state_unit(int item)
+{
+ switch (item) {
+ case MEMCG_PERCPU_B:
+ case NR_SLAB_RECLAIMABLE_B:
+ case NR_SLAB_UNRECLAIMABLE_B:
+ case
[PATCHv2] selftests: test_vxlan_under_vrf: mute unnecessary error message
The cleanup function in this script that tries to delete hv-1 / hv-2
vm-1 / vm-2 netns will generate some uncessary error messages:
Cannot remove namespace file "/run/netns/hv-2": No such file or directory
Cannot remove namespace file "/run/netns/vm-1": No such file or directory
Cannot remove namespace file "/run/netns/vm-2": No such file or directory
Redirect it to /dev/null like other commands in the cleanup function
to reduce confusion.
Signed-off-by: Po-Hsu Lin
---
tools/testing/selftests/net/test_vxlan_under_vrf.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/test_vxlan_under_vrf.sh
b/tools/testing/selftests/net/test_vxlan_under_vrf.sh
index 09f9ed9..534c8b7 100755
--- a/tools/testing/selftests/net/test_vxlan_under_vrf.sh
+++ b/tools/testing/selftests/net/test_vxlan_under_vrf.sh
@@ -50,7 +50,7 @@ cleanup() {
ip link del veth-tap 2>/dev/null || true
for ns in hv-1 hv-2 vm-1 vm-2; do
-ip netns del $ns || true
+ip netns del $ns 2>/dev/null || true
done
}
--
2.7.4
[PATCH v4 4/7] mm: memcontrol: convert NR_SHMEM_THPS account to pages
The unit of NR_SHMEM_THPS is HPAGE_PMD_NR. Convert NR_SHMEM_THPS
account to pages
Signed-off-by: Muchun Song
---
drivers/base/node.c| 3 +--
fs/proc/meminfo.c | 2 +-
include/linux/mmzone.h | 3 ++-
mm/filemap.c | 2 +-
mm/huge_memory.c | 3 ++-
mm/khugepaged.c| 2 +-
mm/memcontrol.c| 26 ++
mm/page_alloc.c| 2 +-
mm/shmem.c | 3 ++-
9 files changed, 13 insertions(+), 33 deletions(-)
diff --git a/drivers/base/node.c b/drivers/base/node.c
index d5952f754911..6d5ac6ffb6e1 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -462,8 +462,7 @@ static ssize_t node_read_meminfo(struct device *dev,
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
,
nid, K(node_page_state(pgdat, NR_ANON_THPS)),
-nid, K(node_page_state(pgdat, NR_SHMEM_THPS) *
- HPAGE_PMD_NR),
+nid, K(node_page_state(pgdat, NR_SHMEM_THPS)),
nid, K(node_page_state(pgdat, NR_SHMEM_PMDMAPPED) *
HPAGE_PMD_NR),
nid, K(node_page_state(pgdat, NR_FILE_THPS)),
diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index 7ea4679880c8..cfb107eaa3e6 100644
--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -131,7 +131,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
show_val_kb(m, "AnonHugePages: ",
global_node_page_state(NR_ANON_THPS));
show_val_kb(m, "ShmemHugePages: ",
- global_node_page_state(NR_SHMEM_THPS) * HPAGE_PMD_NR);
+ global_node_page_state(NR_SHMEM_THPS));
show_val_kb(m, "ShmemPmdMapped: ",
global_node_page_state(NR_SHMEM_PMDMAPPED) * HPAGE_PMD_NR);
show_val_kb(m, "FileHugePages: ",
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 67b6598c9ea4..4f49af38dced 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -216,7 +216,8 @@ enum node_stat_item {
static __always_inline bool vmstat_item_print_in_thp(enum node_stat_item item)
{
return item == NR_ANON_THPS ||
- item == NR_FILE_THPS;
+ item == NR_FILE_THPS ||
+ item == NR_SHMEM_THPS;
}
/*
diff --git a/mm/filemap.c b/mm/filemap.c
index 9cc8b3ac9eac..c653717b92b6 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -205,7 +205,7 @@ static void unaccount_page_cache_page(struct address_space
*mapping,
if (PageSwapBacked(page)) {
__mod_lruvec_page_state(page, NR_SHMEM, -nr);
if (PageTransHuge(page))
- __dec_lruvec_page_state(page, NR_SHMEM_THPS);
+ __mod_lruvec_page_state(page, NR_SHMEM_THPS,
-HPAGE_PMD_NR);
} else if (PageTransHuge(page)) {
__mod_lruvec_page_state(page, NR_FILE_THPS, -HPAGE_PMD_NR);
filemap_nr_thps_dec(mapping);
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 1e24165fa53a..ac552807492e 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2746,7 +2746,8 @@ int split_huge_page_to_list(struct page *page, struct
list_head *list)
spin_unlock(_queue->split_queue_lock);
if (mapping) {
if (PageSwapBacked(head))
- __dec_lruvec_page_state(head, NR_SHMEM_THPS);
+ __mod_lruvec_page_state(head, NR_SHMEM_THPS,
+ -HPAGE_PMD_NR);
else
__mod_lruvec_page_state(head, NR_FILE_THPS,
-HPAGE_PMD_NR);
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 76b3e064a72a..2f1c22331188 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -1867,7 +1867,7 @@ static void collapse_file(struct mm_struct *mm,
}
if (is_shmem)
- __inc_lruvec_page_state(new_page, NR_SHMEM_THPS);
+ __mod_lruvec_page_state(new_page, NR_SHMEM_THPS, HPAGE_PMD_NR);
else {
__mod_lruvec_page_state(new_page, NR_FILE_THPS, HPAGE_PMD_NR);
filemap_nr_thps_inc(mapping);
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 04985c8c6a0a..a40797a27f87 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1515,7 +1515,7 @@ struct memory_stat {
unsigned int idx;
};
-static struct memory_stat memory_stats[] = {
+static const struct memory_stat memory_stats[] = {
{ "anon", PAGE_SIZE, NR_ANON_MAPPED },
{ "file", PAGE_SIZE, NR_FILE_PAGES },
{ "kernel_stack", 1024, NR_KERNEL_STACK_KB },
@@ -1527,14 +1527,9 @@ static struct memory_stat memory_stats[] = {
{ "file_dirty", PAGE_SIZE, NR_FILE_DIRTY },
{ "file_writeback", PAGE_SIZE, NR_WRITEBACK },
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
- /*
-
[PATCH v4 3/7] mm: memcontrol: convert NR_FILE_THPS account to pages
The unit of NR_FILE_THPS is HPAGE_PMD_NR. Converrt NR_FILE_THPS
account to pages.
Signed-off-by: Muchun Song
---
drivers/base/node.c| 3 +--
fs/proc/meminfo.c | 2 +-
include/linux/mmzone.h | 3 ++-
mm/filemap.c | 2 +-
mm/huge_memory.c | 3 ++-
mm/khugepaged.c| 2 +-
mm/memcontrol.c| 5 ++---
7 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/base/node.c b/drivers/base/node.c
index 6da0c3508bc9..d5952f754911 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -466,8 +466,7 @@ static ssize_t node_read_meminfo(struct device *dev,
HPAGE_PMD_NR),
nid, K(node_page_state(pgdat, NR_SHMEM_PMDMAPPED) *
HPAGE_PMD_NR),
-nid, K(node_page_state(pgdat, NR_FILE_THPS) *
- HPAGE_PMD_NR),
+nid, K(node_page_state(pgdat, NR_FILE_THPS)),
nid, K(node_page_state(pgdat, NR_FILE_PMDMAPPED) *
HPAGE_PMD_NR)
#endif
diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index a635c8a84ddf..7ea4679880c8 100644
--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -135,7 +135,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
show_val_kb(m, "ShmemPmdMapped: ",
global_node_page_state(NR_SHMEM_PMDMAPPED) * HPAGE_PMD_NR);
show_val_kb(m, "FileHugePages: ",
- global_node_page_state(NR_FILE_THPS) * HPAGE_PMD_NR);
+ global_node_page_state(NR_FILE_THPS));
show_val_kb(m, "FilePmdMapped: ",
global_node_page_state(NR_FILE_PMDMAPPED) * HPAGE_PMD_NR);
#endif
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 4ac95448421c..67b6598c9ea4 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -215,7 +215,8 @@ enum node_stat_item {
*/
static __always_inline bool vmstat_item_print_in_thp(enum node_stat_item item)
{
- return item == NR_ANON_THPS;
+ return item == NR_ANON_THPS ||
+ item == NR_FILE_THPS;
}
/*
diff --git a/mm/filemap.c b/mm/filemap.c
index 78090ee08ac2..9cc8b3ac9eac 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -207,7 +207,7 @@ static void unaccount_page_cache_page(struct address_space
*mapping,
if (PageTransHuge(page))
__dec_lruvec_page_state(page, NR_SHMEM_THPS);
} else if (PageTransHuge(page)) {
- __dec_lruvec_page_state(page, NR_FILE_THPS);
+ __mod_lruvec_page_state(page, NR_FILE_THPS, -HPAGE_PMD_NR);
filemap_nr_thps_dec(mapping);
}
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 66ec454120de..1e24165fa53a 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2748,7 +2748,8 @@ int split_huge_page_to_list(struct page *page, struct
list_head *list)
if (PageSwapBacked(head))
__dec_lruvec_page_state(head, NR_SHMEM_THPS);
else
- __dec_lruvec_page_state(head, NR_FILE_THPS);
+ __mod_lruvec_page_state(head, NR_FILE_THPS,
+ -HPAGE_PMD_NR);
}
__split_huge_page(page, list, end);
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 494d3cb0b58a..76b3e064a72a 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -1869,7 +1869,7 @@ static void collapse_file(struct mm_struct *mm,
if (is_shmem)
__inc_lruvec_page_state(new_page, NR_SHMEM_THPS);
else {
- __inc_lruvec_page_state(new_page, NR_FILE_THPS);
+ __mod_lruvec_page_state(new_page, NR_FILE_THPS, HPAGE_PMD_NR);
filemap_nr_thps_inc(mapping);
}
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index b18e25a5cdf3..04985c8c6a0a 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1533,7 +1533,7 @@ static struct memory_stat memory_stats[] = {
* constant(e.g. powerpc).
*/
{ "anon_thp", PAGE_SIZE, NR_ANON_THPS },
- { "file_thp", 0, NR_FILE_THPS },
+ { "file_thp", PAGE_SIZE, NR_FILE_THPS },
{ "shmem_thp", 0, NR_SHMEM_THPS },
#endif
{ "inactive_anon", PAGE_SIZE, NR_INACTIVE_ANON },
@@ -1565,8 +1565,7 @@ static int __init memory_stats_init(void)
for (i = 0; i < ARRAY_SIZE(memory_stats); i++) {
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
- if (memory_stats[i].idx == NR_FILE_THPS ||
- memory_stats[i].idx == NR_SHMEM_THPS)
+ if (memory_stats[i].idx == NR_SHMEM_THPS)
memory_stats[i].ratio = HPAGE_PMD_SIZE;
#endif
VM_BUG_ON(!memory_stats[i].ratio);
--
2.11.0
[PATCH v4 5/7] mm: memcontrol: convert NR_SHMEM_PMDMAPPED account to pages
The unit of NR_SHMEM_PMDMAPPED is HPAGE_PMD_NR. Convert NR_SHMEM_PMDMAPPED
account to pages.
Signed-off-by: Muchun Song
---
drivers/base/node.c| 3 +--
fs/proc/meminfo.c | 2 +-
include/linux/mmzone.h | 3 ++-
mm/page_alloc.c| 3 +--
mm/rmap.c | 6 --
5 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/base/node.c b/drivers/base/node.c
index 6d5ac6ffb6e1..7a66aefe4e46 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -463,8 +463,7 @@ static ssize_t node_read_meminfo(struct device *dev,
,
nid, K(node_page_state(pgdat, NR_ANON_THPS)),
nid, K(node_page_state(pgdat, NR_SHMEM_THPS)),
-nid, K(node_page_state(pgdat, NR_SHMEM_PMDMAPPED) *
- HPAGE_PMD_NR),
+nid, K(node_page_state(pgdat, NR_SHMEM_PMDMAPPED)),
nid, K(node_page_state(pgdat, NR_FILE_THPS)),
nid, K(node_page_state(pgdat, NR_FILE_PMDMAPPED) *
HPAGE_PMD_NR)
diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index cfb107eaa3e6..c61f440570f9 100644
--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -133,7 +133,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
show_val_kb(m, "ShmemHugePages: ",
global_node_page_state(NR_SHMEM_THPS));
show_val_kb(m, "ShmemPmdMapped: ",
- global_node_page_state(NR_SHMEM_PMDMAPPED) * HPAGE_PMD_NR);
+ global_node_page_state(NR_SHMEM_PMDMAPPED));
show_val_kb(m, "FileHugePages: ",
global_node_page_state(NR_FILE_THPS));
show_val_kb(m, "FilePmdMapped: ",
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 4f49af38dced..d6b13b9327be 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -217,7 +217,8 @@ static __always_inline bool vmstat_item_print_in_thp(enum
node_stat_item item)
{
return item == NR_ANON_THPS ||
item == NR_FILE_THPS ||
- item == NR_SHMEM_THPS;
+ item == NR_SHMEM_THPS ||
+ item == NR_SHMEM_PMDMAPPED;
}
/*
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 720fb5a220b6..575fbfeea4b5 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5578,8 +5578,7 @@ void show_free_areas(unsigned int filter, nodemask_t
*nodemask)
K(node_page_state(pgdat, NR_SHMEM)),
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
K(node_page_state(pgdat, NR_SHMEM_THPS)),
- K(node_page_state(pgdat, NR_SHMEM_PMDMAPPED)
- * HPAGE_PMD_NR),
+ K(node_page_state(pgdat, NR_SHMEM_PMDMAPPED)),
K(node_page_state(pgdat, NR_ANON_THPS)),
#endif
K(node_page_state(pgdat, NR_WRITEBACK_TEMP)),
diff --git a/mm/rmap.c b/mm/rmap.c
index f59e92e26b61..3089ad6bf468 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1219,7 +1219,8 @@ void page_add_file_rmap(struct page *page, bool compound)
if (!atomic_inc_and_test(compound_mapcount_ptr(page)))
goto out;
if (PageSwapBacked(page))
- __inc_node_page_state(page, NR_SHMEM_PMDMAPPED);
+ __mod_lruvec_page_state(page, NR_SHMEM_PMDMAPPED,
+ HPAGE_PMD_NR);
else
__inc_node_page_state(page, NR_FILE_PMDMAPPED);
} else {
@@ -1260,7 +1261,8 @@ static void page_remove_file_rmap(struct page *page, bool
compound)
if (!atomic_add_negative(-1, compound_mapcount_ptr(page)))
return;
if (PageSwapBacked(page))
- __dec_node_page_state(page, NR_SHMEM_PMDMAPPED);
+ __mod_lruvec_page_state(page, NR_SHMEM_PMDMAPPED,
+ -HPAGE_PMD_NR);
else
__dec_node_page_state(page, NR_FILE_PMDMAPPED);
} else {
--
2.11.0
[PATCH v4 2/7] mm: memcontrol: convert NR_ANON_THPS account to pages
The unit of NR_ANON_THPS is HPAGE_PMD_NR. Convert the NR_ANON_THPS
account to pages.
Signed-off-by: Muchun Song
---
drivers/base/node.c| 15 +--
fs/proc/meminfo.c | 2 +-
include/linux/mmzone.h | 9 +
mm/huge_memory.c | 3 ++-
mm/memcontrol.c| 20 ++--
mm/page_alloc.c| 2 +-
mm/rmap.c | 7 ---
mm/vmstat.c| 11 +--
8 files changed, 41 insertions(+), 28 deletions(-)
diff --git a/drivers/base/node.c b/drivers/base/node.c
index 04f71c7bc3f8..6da0c3508bc9 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -461,8 +461,7 @@ static ssize_t node_read_meminfo(struct device *dev,
nid, K(sunreclaimable)
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
,
-nid, K(node_page_state(pgdat, NR_ANON_THPS) *
- HPAGE_PMD_NR),
+nid, K(node_page_state(pgdat, NR_ANON_THPS)),
nid, K(node_page_state(pgdat, NR_SHMEM_THPS) *
HPAGE_PMD_NR),
nid, K(node_page_state(pgdat, NR_SHMEM_PMDMAPPED) *
@@ -519,10 +518,14 @@ static ssize_t node_read_vmstat(struct device *dev,
sum_zone_numa_state(nid, i));
#endif
- for (i = 0; i < NR_VM_NODE_STAT_ITEMS; i++)
- len += sysfs_emit_at(buf, len, "%s %lu\n",
-node_stat_name(i),
-node_page_state_pages(pgdat, i));
+ for (i = 0; i < NR_VM_NODE_STAT_ITEMS; i++) {
+ unsigned long pages = node_page_state_pages(pgdat, i);
+
+ if (vmstat_item_print_in_thp(i))
+ pages /= HPAGE_PMD_NR;
+ len += sysfs_emit_at(buf, len, "%s %lu\n", node_stat_name(i),
+pages);
+ }
return len;
}
diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index d6fc74619625..a635c8a84ddf 100644
--- a/fs/proc/meminfo.c
+++ b/fs/proc/meminfo.c
@@ -129,7 +129,7 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
show_val_kb(m, "AnonHugePages: ",
- global_node_page_state(NR_ANON_THPS) * HPAGE_PMD_NR);
+ global_node_page_state(NR_ANON_THPS));
show_val_kb(m, "ShmemHugePages: ",
global_node_page_state(NR_SHMEM_THPS) * HPAGE_PMD_NR);
show_val_kb(m, "ShmemPmdMapped: ",
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index b593316bff3d..4ac95448421c 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -210,6 +210,15 @@ enum node_stat_item {
};
/*
+ * Returns true if the item should prints in THPs. The /proc/vmstat currently
+ * prints number of anon, file and shmem THPs. But the item is charged in
pages.
+ */
+static __always_inline bool vmstat_item_print_in_thp(enum node_stat_item item)
+{
+ return item == NR_ANON_THPS;
+}
+
+/*
* Returns true if the value is measured in bytes (most vmstat values are
* measured in pages). This defines the API part, the internal representation
* might be different.
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 10dd3cae5f53..66ec454120de 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2178,7 +2178,8 @@ static void __split_huge_pmd_locked(struct vm_area_struct
*vma, pmd_t *pmd,
lock_page_memcg(page);
if (atomic_add_negative(-1, compound_mapcount_ptr(page))) {
/* Last compound_mapcount is gone. */
- __dec_lruvec_page_state(page, NR_ANON_THPS);
+ __mod_lruvec_page_state(page, NR_ANON_THPS,
+ -HPAGE_PMD_NR);
if (TestClearPageDoubleMap(page)) {
/* No need in mapcount reference anymore */
for (i = 0; i < HPAGE_PMD_NR; i++)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 8818bf64d6fe..b18e25a5cdf3 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1532,7 +1532,7 @@ static struct memory_stat memory_stats[] = {
* on some architectures, the macro of HPAGE_PMD_SIZE is not
* constant(e.g. powerpc).
*/
- { "anon_thp", 0, NR_ANON_THPS },
+ { "anon_thp", PAGE_SIZE, NR_ANON_THPS },
{ "file_thp", 0, NR_FILE_THPS },
{ "shmem_thp", 0, NR_SHMEM_THPS },
#endif
@@ -1565,8 +1565,7 @@ static int __init memory_stats_init(void)
for (i = 0; i < ARRAY_SIZE(memory_stats); i++) {
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
- if (memory_stats[i].idx == NR_ANON_THPS ||
- memory_stats[i].idx == NR_FILE_THPS ||
+ if (memory_stats[i].idx == NR_FILE_THPS ||
memory_stats[i].idx == NR_SHMEM_THPS)
[PATCH v4 0/7] Convert all THP vmstat counters to pages
Hi,
This patch series is aimed to convert all THP vmstat counters to pages.
The unit of some vmstat counters are pages, some are bytes, some are
HPAGE_PMD_NR, and some are KiB. When we want to expose these vmstat
counters to the userspace, we have to know the unit of the vmstat counters
is which one. When the unit is bytes or kB, both clearly distinguishable
by the B/KB suffix. But for the THP vmstat counters, we may make mistakes.
For example, the below is some bug fix for the THP vmstat counters:
- 7de2e9f195b9 ("mm: memcontrol: correct the NR_ANON_THPS counter of
hierarchical memcg")
- The first commit in this series ("fix NR_ANON_THPS accounting in charge
moving")
This patch series can make the code clear. And make all the unit of the THP
vmstat counters in pages. Finally, the unit of the vmstat counters are
pages, kB and bytes. The B/KB suffix can tell us that the unit is bytes
or kB. The rest which is without suffix are pages.
In this series, I changed the following vmstat counters unit from HPAGE_PMD_NR
to pages. However, there is no change to the print format of output to user
space.
- NR_ANON_THPS
- NR_FILE_THPS
- NR_SHMEM_THPS
- NR_SHMEM_PMDMAPPED
- NR_FILE_PMDMAPPED
Although every THP stats update overflows the per-cpu counter, resorting to
atomic global updates.
But this change is consistent with 4.7's 8f182270dfec ("mm/swap.c: flush
lru pvecs on compound page arrival"): we accepted greater overhead for
greater accuracy back then, so I think it's okay to do so for THP stats.
Thanks Hugh for mentioning this.
This was inspired by Johannes and Roman. Thanks to them.
Changes in v3 -> v4:
- Rename the first commit subject to "mm: memcontrol: fix NR_ANON_THPS
accounting in charge moving".
- Fix /proc/vmstat printing. Thanks to Johannes points out that.
Changes in v2 -> v3:
- Change the series subject from "Convert all vmstat counters to pages or
bytes"
to "Convert all THP vmstat counters to pages".
- Remove convert of KB to B.
Changes in v1 -> v2:
- Change the series subject from "Convert all THP vmstat counters to pages"
to "Convert all vmstat counters to pages or bytes".
- Convert NR_KERNEL_SCS_KB account to bytes.
- Convert vmstat slab counters to bytes.
- Remove {global_}node_page_state_pages.
Muchun Song (7):
mm: memcontrol: fix NR_ANON_THPS accounting in charge moving
mm: memcontrol: convert NR_ANON_THPS account to pages
mm: memcontrol: convert NR_FILE_THPS account to pages
mm: memcontrol: convert NR_SHMEM_THPS account to pages
mm: memcontrol: convert NR_SHMEM_PMDMAPPED account to pages
mm: memcontrol: convert NR_FILE_PMDMAPPED account to pages
mm: memcontrol: make the slab calculation consistent
drivers/base/node.c| 27 +-
fs/proc/meminfo.c | 10 ++--
include/linux/mmzone.h | 13 +
mm/filemap.c | 4 +-
mm/huge_memory.c | 9 ++--
mm/khugepaged.c| 4 +-
mm/memcontrol.c| 132 +++--
mm/page_alloc.c| 7 ++-
mm/rmap.c | 19 ---
mm/shmem.c | 3 +-
mm/vmstat.c| 11 -
11 files changed, 130 insertions(+), 109 deletions(-)
--
2.11.0
[PATCH v4 1/7] mm: memcontrol: fix NR_ANON_THPS accounting in charge moving
The unit of NR_ANON_THPS is HPAGE_PMD_NR already. So it should inc/dec
by one rather than nr_pages.
Fixes: 468c398233da ("mm: memcontrol: switch to native NR_ANON_THPS counter")
Signed-off-by: Muchun Song
Acked-by: Michal Hocko
Acked-by: Johannes Weiner
Reviewed-by: Roman Gushchin
---
mm/memcontrol.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index b80328f52fb4..8818bf64d6fe 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -5653,10 +5653,8 @@ static int mem_cgroup_move_account(struct page *page,
__mod_lruvec_state(from_vec, NR_ANON_MAPPED, -nr_pages);
__mod_lruvec_state(to_vec, NR_ANON_MAPPED, nr_pages);
if (PageTransHuge(page)) {
- __mod_lruvec_state(from_vec, NR_ANON_THPS,
- -nr_pages);
- __mod_lruvec_state(to_vec, NR_ANON_THPS,
- nr_pages);
+ __dec_lruvec_state(from_vec, NR_ANON_THPS);
+ __inc_lruvec_state(to_vec, NR_ANON_THPS);
}
}
--
2.11.0
