Re: [PATCH v4] drm/virtio: Track total GPU memory for virtio driver
On Thu, Jan 21, 2021 at 9:40 PM Yiwei Zhang wrote:
>
> On the success of virtio_gpu_object_create, add size of newly allocated
> bo to the tracked total_mem. In drm_gem_object_funcs.free, after the gem
> bo loses its last refcount, subtract the bo size from the tracked
> total_mem if the original underlying memory allocation is successful.
>
> It's more accurate to do this in device driver layer to best match when
> the underlying resource gets allocated and destroyed during tracing.
>
> Signed-off-by: Yiwei Zhang
> ---
> drivers/gpu/drm/virtio/Kconfig | 1 +
> drivers/gpu/drm/virtio/virtgpu_drv.h| 2 ++
> drivers/gpu/drm/virtio/virtgpu_object.c | 11 +++
> 3 files changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
> index b925b8b1da16..e103b7e883b1 100644
> --- a/drivers/gpu/drm/virtio/Kconfig
> +++ b/drivers/gpu/drm/virtio/Kconfig
> @@ -5,6 +5,7 @@ config DRM_VIRTIO_GPU
> select DRM_KMS_HELPER
> select DRM_GEM_SHMEM_HELPER
> select VIRTIO_DMA_SHARED_BUFFER
> + select TRACE_GPU_MEM
> help
>This is the virtual GPU driver for virtio. It can be used with
>QEMU based VMMs (like KVM or Xen).
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
> b/drivers/gpu/drm/virtio/virtgpu_drv.h
> index 6a232553c99b..c5622f9b591f 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_drv.h
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
> @@ -249,6 +249,8 @@ struct virtio_gpu_device {
> spinlock_t resource_export_lock;
> /* protects map state and host_visible_mm */
> spinlock_t host_visible_lock;
> +
> + atomic64_t total_mem;
> };
>
> struct virtio_gpu_fpriv {
> diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
> b/drivers/gpu/drm/virtio/virtgpu_object.c
> index d69a5b6da553..e2251fc41509 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_object.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
> @@ -25,12 +25,21 @@
>
> #include
> #include
> +#include
>
> #include "virtgpu_drv.h"
>
> static int virtio_gpu_virglrenderer_workaround = 1;
> module_param_named(virglhack, virtio_gpu_virglrenderer_workaround, int,
> 0400);
>
> +static inline void virtio_gpu_trace_total_mem(struct virtio_gpu_device
> *vgdev,
> + s64 delta)
> +{
> + u64 total_mem = atomic64_add_return(delta, &vgdev->total_mem);
> +
> + trace_gpu_mem_total(vgdev->ddev->primary->index, 0, total_mem);
> +}
> +
> int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev, uint32_t
> *resid)
> {
> if (virtio_gpu_virglrenderer_workaround) {
> @@ -104,6 +113,7 @@ static void virtio_gpu_free_object(struct drm_gem_object
> *obj)
> struct virtio_gpu_device *vgdev = bo->base.base.dev->dev_private;
>
> if (bo->created) {
> + virtio_gpu_trace_total_mem(vgdev, -(obj->size));
> virtio_gpu_cmd_unref_resource(vgdev, bo);
> virtio_gpu_notify(vgdev);
> /* completion handler calls virtio_gpu_cleanup_object() */
> @@ -265,6 +275,7 @@ int virtio_gpu_object_create(struct virtio_gpu_device
> *vgdev,
> virtio_gpu_object_attach(vgdev, bo, ents, nents);
> }
>
> + virtio_gpu_trace_total_mem(vgdev, shmem_obj->base.size);
> *bo_ptr = bo;
> return 0;
>
> --
> 2.30.0.280.ga3ce27912f-goog
>
Re Gerd and Daniel:
I'm not sure why we want to couple this patch too much with the
dma-bufs tracking. The tracepoint added here itself is pretty useful
for tracking gem bo total usage in virtio gpu upon tracing. The
original purpose for integrating this tracepoint in all Android gpu
kernel drivers is to just track total gpu memory usage and serve the
accurate data to game developers in a much easier way. It's something
they can rely on for robust testing and regression monitoring.
The only overlap with the dma-buf side is when we export a bo via
prime to a dma-buf. But still, the total here is already useful for
this particular device. Using which approach to account for the
overlap wouldn't block this small integration from my understanding.
Besides, there's no plan for adding per-process gem total tracking in
virtio-gpu at this moment. This patch should be light enough to carry
without worrying about tech debt I believe.
Many thanks!
Yiwei
Re: [PATCH v1] can: mcp251xfd: use regmap_bulk_write for compatibility
在 2021/1/22 下午3:26, Marc Kleine-Budde 写道: On 1/22/21 4:02 AM, Su Yanjun wrote: Recently i use mcp2518fd on 4.x kernel which multiple write is not backported, regmap_raw_write will cause old kernel crash because the tx buffer in driver is smaller then 2K. Use regmap_bulk_write instead for compatibility. Hmmm, this patch will never be backported to any 4.x kernel, as the driver is not available on these kernels. You have to carry patches for these kernels anyway, so I think I'll not take that patch. Sorry. Drop me a note if you are interested in updating your kernel to a recent v5.11 kernel. I got it. I have already port it to 4.x kernel. I just want anyone working on old kernels to use the driver more easier. Thanks. regards, Marc
Re: [PATCH] xfs: set inode size after creating symlink
Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH v1] can: mcp251xfd: Add some sysfs debug interfaces for registers r/w
在 2021/1/22 下午3:22, Marc Kleine-Budde 写道: On 1/22/21 7:22 AM, Su Yanjun wrote: When i debug mcp2518fd, some method to track registers is needed. This easy debug interface will be ok. NACK As the driver uses regmap, everything should be there already. To read use: | cat /sys/kernel/debug/regmap/spi0.0-crc/registers Register write support for devices that are handles by proper kernel drivers is a pure debugging tool, thus not enabled by default, not even with a Kconfig switch. You have to enable it manually, have a look at commit: 09c6ecd39410 regmap: Add support for writing to regmap registers via debugfs You're right. Thank you regards, Marc
Re: [RFC PATCH v0] mm/slub: Let number of online CPUs determine the slub page order
On Thu, 21 Jan 2021 at 19:19, Vlastimil Babka wrote: > > On 1/21/21 11:01 AM, Christoph Lameter wrote: > > On Thu, 21 Jan 2021, Bharata B Rao wrote: > > > >> > The problem is that calculate_order() is called a number of times > >> > before secondaries CPUs are booted and it returns 1 instead of 224. > >> > This makes the use of num_online_cpus() irrelevant for those cases > >> > > >> > After adding in my command line "slub_min_objects=36" which equals to > >> > 4 * (fls(num_online_cpus()) + 1) with a correct num_online_cpus == 224 > >> > , the regression diseapears: > >> > > >> > 9 iterations of hackbench -l 16000 -g 16: 3.201sec (+/- 0.90%) > > I'm surprised that hackbench is that sensitive to slab performance, anyway. > It's > supposed to be a scheduler benchmark? What exactly is going on? > >From hackbench description: Hackbench is both a benchmark and a stress test for the Linux kernel scheduler. It's main job is to create a specified number of pairs of schedulable entities (either threads or traditional processes) which communicate via either sockets or pipes and time how long it takes for each pair to send data back and forth. > >> Should we have switched to num_present_cpus() rather than > >> num_online_cpus()? If so, the below patch should address the > >> above problem. > > > > There is certainly an initcall after secondaries are booted where we could > > redo the calculate_order? > > We could do it even in hotplug handler. But in practice that means making sure > it's safe, i.e. all users of oo_order/oo_objects must handle the value > changing. > > Consider e.g. init_cache_random_seq() which uses oo_objects(s->oo) to allocate > s->random_seq when cache s is created. Then shuffle_freelist() will use the > current value of oo_objects(s->oo) to index s->random_seq, for a newly > allocated > slab - what if the page order has increased meanwhile due to secondary booting > or hotplug? Array overflow. That's why I just made the former sysfs handler > for > changing order read-only. > > Things would be easier if we could trust *on all arches* either > > - num_present_cpus() to count what the hardware really physically has during > boot, even if not yet onlined, at the time we init slab. This would still not > handle later hotplug (probably mostly in a VM scenario, not that somebody > would > bring bunch of actual new cpu boards to a running bare metal system?). > > - num_possible_cpus()/nr_cpu_ids not to be excessive (broken BIOS?) on systems > where it's not really possible to plug more CPU's. In a VM scenario we could > still have an opposite problem, where theoretically "anything is possible" but > the virtual cpus are never added later. On all the system that I have tested num_possible_cpus()/nr_cpu_ids were correctly initialized large arm64 acpi system small arm64 DT based system VM on x86 system > > We could also start questioning the very assumption that number of cpus should > affect slab page size in the first place. Should it? After all, each CPU will > have one or more slab pages privately cached, as we discuss in the other > thread... So why make the slab pages also larger? > > > Or the num_online_cpus needs to be up to date earlier. Why does this issue > > not occur on x86? Does x86 have an up to date num_online_cpus earlier? > > > > >
Re: [PATCH v3 1/4] drm/qxl: use drmm_mode_config_init
Am 20.01.21 um 12:12 schrieb Gerd Hoffmann:
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/qxl/qxl_display.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 012bce0cdb65..38d6b596094d 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -1195,7 +1195,9 @@ int qxl_modeset_init(struct qxl_device *qdev)
int i;
int ret;
- drm_mode_config_init(&qdev->ddev);
+ ret = drmm_mode_config_init(&qdev->ddev);
+ if (ret)
+ return ret;
ret = qxl_create_monitors_object(qdev);
if (ret)
@@ -1228,5 +1230,4 @@ int qxl_modeset_init(struct qxl_device *qdev)
void qxl_modeset_fini(struct qxl_device *qdev)
{
qxl_destroy_monitors_object(qdev);
- drm_mode_config_cleanup(&qdev->ddev);
}
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
Re: [RESEND PATCH v3 2/2] usb: dwc3: Add driver for Xilinx platforms
Hello!
On Mon, Jan 18, 2021 at 02:42:24PM +0100, Michael Grzeschik wrote:
Hi!
On Tue, Dec 15, 2020 at 12:24:51PM +0530, Manish Narani wrote:
Add a new driver for supporting Xilinx platforms. This driver is used
for some sequence of operations required for Xilinx USB controllers.
This driver is also used to choose between PIPE clock coming from SerDes
and the Suspend Clock. Before the controller is out of reset, the clock
selection should be changed to PIPE clock in order to make the USB
controller work. There is a register added in Xilinx USB controller
register space for the same.
I tried out this driver with the vanilla kernel on an zynqmp. Without
this patch the USB-Gadget is already acting buggy. In the gadget mode,
some iterations of plug/unplug results to an stalled gadget which will
never come back without a reboot.
With the corresponding code of this driver (reset assert, clk modify,
reset deassert) in the downstream kernels phy driver we found out it is
totaly stable. But using this exact glue driver which should do the same
as the downstream code, the gadget still was buggy the way described
above.
I suspect the difference lays in the different order of operations.
While the downstream code is runing the resets inside the phy driver
which is powered and initialized in the dwc3-core itself. With this glue
layser approach of this patch the whole phy init is done before even
touching dwc3-core in any way. It seems not to have the same effect,
though.
If really the order of operations is limiting us, we probably need
another solution than this glue layer. Any Ideas?
I found out what the difference between the Downstream and this
Glue is. When using vanilla with this Glue code we may not set
the following bit:
https://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-ultrascale-registers.html#usb3_regs___fpd_power_prsnt.html
+ /* Set PIPE Power Present signal in FPD Power Present Register*/
+ writel(PIPE_POWER_ON, priv_data->regs + XLNX_USB_FPD_POWER_PRSNT);
When I comment this out, the link stays stable. This is different in
the Downstream Xilinx Kernel, where the bit is also set but has no
negativ effect.
Manish, can you give me a pointer what to look for?
So setting this will also work with mainline?
Regards,
Michael
Signed-off-by: Manish Narani
---
drivers/usb/dwc3/Kconfig | 9 +
drivers/usb/dwc3/Makefile | 1 +
drivers/usb/dwc3/dwc3-of-simple.c | 1 -
drivers/usb/dwc3/dwc3-xilinx.c| 334 ++
4 files changed, 344 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/dwc3/dwc3-xilinx.c
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 7a2304565a73..0e00e6dfccd8 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -139,4 +139,13 @@ config USB_DWC3_QCOM
for peripheral mode support.
Say 'Y' or 'M' if you have one such device.
+config USB_DWC3_XILINX
+ tristate "Xilinx Platforms"
+ depends on (ARCH_ZYNQMP || ARCH_VERSAL) && OF
+ default USB_DWC3
+ help
+ Support Xilinx SoCs with DesignWare Core USB3 IP.
+ This driver handles both ZynqMP and Versal SoC operations.
+ Say 'Y' or 'M' if you have one such device.
+
endif
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index ae86da0dc5bd..add567578b1f 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -51,3 +51,4 @@ obj-$(CONFIG_USB_DWC3_MESON_G12A) += dwc3-meson-g12a.o
obj-$(CONFIG_USB_DWC3_OF_SIMPLE)+= dwc3-of-simple.o
obj-$(CONFIG_USB_DWC3_ST) += dwc3-st.o
obj-$(CONFIG_USB_DWC3_QCOM) += dwc3-qcom.o
+obj-$(CONFIG_USB_DWC3_XILINX) += dwc3-xilinx.o
diff --git a/drivers/usb/dwc3/dwc3-of-simple.c
b/drivers/usb/dwc3/dwc3-of-simple.c
index e62ecd22b3ed..71fd620c5161 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -172,7 +172,6 @@ static const struct dev_pm_ops dwc3_of_simple_dev_pm_ops = {
static const struct of_device_id of_dwc3_simple_match[] = {
{ .compatible = "rockchip,rk3399-dwc3" },
- { .compatible = "xlnx,zynqmp-dwc3" },
{ .compatible = "cavium,octeon-7130-usb-uctl" },
{ .compatible = "sprd,sc9860-dwc3" },
{ .compatible = "allwinner,sun50i-h6-dwc3" },
diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
new file mode 100644
index ..7e485951d2f7
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -0,0 +1,334 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * dwc3-xilinx.c - Xilinx DWC3 controller specific glue driver
+ *
+ * Authors: Manish Narani
+ * Anurag Kumar Vulisha
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/* USB phy reset mask register */
+#define XLNX_USB_PHY_RST_EN0x001C
+#defin
bisected regression in v5.11-rc1 snd-usb-audio
I've bisected a failure in support for the M2Tech USB HiFace Two 192kHz Digital Audio Interface device (read as: a reclocked USB S/PDIF) to the following ... commit 93db51d06b32227319dae2ac289029ccf1b33181 Author: Takashi Iwai Date: Mon Nov 23 09:53:09 2020 +0100 ALSA: usb-audio: Check valid altsetting at parsing rates for UAC2/3 This has always been a somewhat finicky device, but my life is a silent void without it, as it is currently a vital part of getting audio to my mixer (now, if I could get USB Audio on my Rane MP2015 actually working right I'd very happily take that approach instead[1], but I digress). It has been known to require replugging to initialize properly at times, but until now, it's always worked fine eventually. I've attached the dmesg from a working 5.10.9 kernel, the alsa-info output, and the lsusb -vvv output for this device when it's functioning. (Note, that alsa-info claims jack isn't running... that's not actually true though, maybe because I'm using jack 2's jackdbus subsystem, but jack is infact running, though it's probably not relevant to the issue at hand[2].) When I boot 93db51d06b32 or later I get lot of errors in the dmesg like: usb 1-1.1.2: New USB device found, idVendor=249c, idProduct=930b, bcdDevice= 2.13 usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-1.1.2: Product: M2Tech USB Audio 2.0 usb 1-1.1.2: Manufacturer: M2Tech usb 1-1.1.2: SerialNumber: usb 1-1.1.2: cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0xa00, type = 4 usb 1-1.1.2: 10:0: cannot get min/max values for control 2 (id 10) usb 1-1.1.2: cannot get ctl value: req = 0x83, wValue = 0x200, wIndex = 0xa00, type = 4 usb 1-1.1.2: 10:0: cannot get min/max values for control 2 (id 10) usbcore: registered new interface driver snd-usb-audio usb 1-1.1-port2: disabled by hub (EMI?), re-enabling... usb 1-1.1.2: USB disconnect, device number 6 usb 1-1.1.2: new full-speed USB device number 7 using ehci-pci usb 1-1.1.2: device descriptor read/64, error -32 usb 1-1.1.2: device descriptor read/64, error -32 usb 1-1.1.2: new full-speed USB device number 8 using ehci-pci usb 1-1.1.2: device descriptor read/64, error -32 usb 1-1.1.2: device descriptor read/64, error -32 usb 1-1.1-port2: attempt power cycle usb 1-1.1.2: new full-speed USB device number 9 using ehci-pci usb 1-1.1.2: device not accepting address 9, error -32 usb 1-1.1.2: new full-speed USB device number 10 using ehci-pci usb 1-1.1.2: device not accepting address 10, error -32 usb 1-1.1-port2: unable to enumerate USB device and obviously the device doesn't work at all. Sometimes there's more "cannot get ctl value:" noise than other times, but the above is a clean boot after being in a working state (it tends to require replugging to get back to a being usable again after this, once I've booted a working kernel, possibly becuase its hanging off a hub in my monitor, not the most elegant of setups, I know---but none of this changes even if I plug it directly into my workstation's USB ports, I tried that). I'm happy to try any patches, or provide more details, just ask. -- Jamie Heilman http://audible.transient.net/~jamie/ [1] it's never been quite right, if you ever want to try to figure out why, I'd be happy to tackle that separately [2] just in case, jack_control dp output: --- get driver parameters (type:isset:default:value) device: ALSA device name (str:set:hw:0:hw:CARD=hiFace2,DEV=0) capture: Provide capture ports. Optionally set device (str:notset:none:none) playback: Provide playback ports. Optionally set device (str:set:none:hw:CARD=hiFace2,DEV=0) rate: Sample rate (uint:set:48000:96000) period: Frames per period (uint:notset:1024:1024) nperiods: Number of periods of playback latency (uint:set:2:3) hwmon: Hardware monitoring, if available (bool:notset:False:False) hwmeter: Hardware metering, if available (bool:notset:False:False) duplex: Provide both capture and playback ports (bool:notset:True:True) softmode: Soft-mode, no xrun handling (bool:notset:False:False) monitor: Provide monitor ports for the output (bool:notset:False:False) dither: Dithering mode (char:notset:n:n) inchannels: Number of capture channels (defaults to hardware max) (uint:notset:0:0) outchannels: Number of playback channels (defaults to hardware max) (uint:notset:0:0) shorts: Try 16-bit samples before 32-bit (bool:notset:False:False) input-latency: Extra input latency (frames) (uint:notset:0:0) output-latency: Extra output latency (frames) (uint:notset:0:0) midi-driver: ALSA MIDI driver (str:notset:none:none) [0.00] Linux version 5.10.9 (jamie@cucamonga) (gcc (Debian 10.2.1-3) 10.2.1 20201224, GNU ld (GNU Binutils for Debian) 2.35.1) #1
Re: [PATCH 3/6] sched/deadline: Allow DL tasks on empty (cgroup v2) cpusets
Hi, On 12/01/21 16:53, Daniel Bristot de Oliveira wrote: > cgroups v2 allows the cpuset controller to be enabled/disabled on > demand. On Fedora 32, cpuset is disabled by default. To enable it, > a user needs to: > > # cd /sys/fs/cgroup/ > # echo +cpuset > cgroup.subtree_control > > Existing cgroups will expose the cpuset interface (e.g., cpuset.cpus > file). By default, cpuset.cpus has no CPU assigned, which means that > existing tasks will move to a cpuset without cpus. This is kind of confusing, though. Isn't it? > Initially, I thought about returning an error and blocking the > operation. However, that is indeed not needed. The cpuset without > CPUs assigned will be a non-root cpuset, hence its cpu mask will > be the same as the root one. So, the bandwidth was already accounted, > and the task can proceed. > > Signed-off-by: Daniel Bristot de Oliveira > Cc: Ingo Molnar > Cc: Peter Zijlstra > Cc: Juri Lelli > Cc: Vincent Guittot > Cc: Dietmar Eggemann > Cc: Steven Rostedt > Cc: Ben Segall > Cc: Mel Gorman > Cc: Daniel Bristot de Oliveira > Cc: Li Zefan > Cc: Tejun Heo > Cc: Johannes Weiner > Cc: Valentin Schneider > Cc: linux-kernel@vger.kernel.org > Cc: cgro...@vger.kernel.org > --- > kernel/sched/deadline.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c > index 943aa32cc1bc..788a391657a5 100644 > --- a/kernel/sched/deadline.c > +++ b/kernel/sched/deadline.c > @@ -2871,6 +2871,13 @@ int dl_task_can_attach(struct task_struct *p, > bool overflow; > int ret; > > + /* > + * The cpuset has no cpus assigned, so the thread will not > + * change its affinity. Is this always the case also in the presence of deeper hierarchies? Thanks, Juri
Re: [v7,1/2] dt-binding: reset-controller: mediatek: add YAML schemas
On Fri, Jan 15, 2021 at 7:23 PM Crystal Guo wrote:
>
> Add a YAML documentation for Mediatek, which uses ti reset-controller
> driver directly. The TI reset controller provides a common reset
> management, and is suitable for Mediatek SoCs.
>
> Signed-off-by: Crystal Guo
> ---
> .../bindings/reset/mediatek-syscon-reset.yaml | 51 +++
> 1 file changed, 51 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/reset/mediatek-syscon-reset.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/reset/mediatek-syscon-reset.yaml
> b/Documentation/devicetree/bindings/reset/mediatek-syscon-reset.yaml
> new file mode 100644
> index ..85d241cdb0ea
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/mediatek-syscon-reset.yaml
> @@ -0,0 +1,51 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/reset/mediatek-syscon-reset.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mediatek Reset Controller
> +
> +maintainers:
> + - Crystal Guo
> +
> +description:
> + The bindings describe the reset-controller for Mediatek SoCs,
> + which is based on TI reset controller. For more detail, please
> + visit Documentation/devicetree/bindings/reset/ti-syscon-reset.txt.
> +
> +properties:
> + compatible:
> +const: mediatek,syscon-reset
> +
> + '#reset-cells':
> +const: 1
> +
> + ti,reset-bits:
> +description: >
> + Contains the reset control register information, please refer to
> + Documentation/devicetree/bindings/reset/ti-syscon-reset.txt.
> +
I remember that Rob didn't like adding new users of this property,
How about removing this from here and using a hardcoded version of
register layouts into driver code (and match it with compatible) ?
e.g.
struct ti_syscon_reset_data mt8192_reset_data { ... }
> +required:
> + - compatible
> + - '#reset-cells'
> + - ti,reset-bits
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +infracfg: infracfg@10001000 {
> +compatible = "mediatek,mt8192-infracfg", "syscon", "simple-mfd";
> +reg = <0 0x10001000>;
> +#clock-cells = <1>;
> +
> +infracfg_rst: reset-controller {
> +compatible = "mediatek,syscon-reset";
> +#reset-cells = <1>;
> +ti,reset-bits = <
> + 0x140 15 0x144 15 0 0 (ASSERT_SET | DEASSERT_SET |
> STATUS_NONE)
> +>;
> +};
> +};
> --
> 2.18.0
>
Re: [PATCH v3 2/4] drm/qxl: unpin release objects
Hi Am 20.01.21 um 12:12 schrieb Gerd Hoffmann: Balances the qxl_create_bo(..., pinned=true, ...); call in qxl_release_bo_alloc(). Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/qxl/qxl_release.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/qxl/qxl_release.c b/drivers/gpu/drm/qxl/qxl_release.c index 0fcfc952d5e9..add979cba11b 100644 --- a/drivers/gpu/drm/qxl/qxl_release.c +++ b/drivers/gpu/drm/qxl/qxl_release.c @@ -166,6 +166,7 @@ qxl_release_free_list(struct qxl_release *release) entry = container_of(release->bos.next, struct qxl_bo_list, tv.head); bo = to_qxl_bo(entry->tv.bo); + bo->tbo.pin_count = 0; /* ttm_bo_unpin(&bo->tbo); */ This code looks like a workaround or a bug. AFAICT the only place with pre-pinned BO is qdev->dumb_shadow_bo. Can you remove the pinned flag entirely and handle pinning as part of dumb_shadow_bo's code. Otherwise maybe use if (pin_count) ttm_bo_unpin(); WARN_ON(pin_count); /* should always be 0 now */ with a comment similar to the commit's description. Best regards Thomas qxl_bo_unref(&bo); list_del(&entry->tv.head); kfree(entry); -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature
[PATCH v4] can: mcp251xfd: replace sizeof(u32) with val_bytes in regmap
The sizeof(u32) is hardcoded. It's better to use the config value in
regmap.
It increases the size of target object, but it's flexible when new mcp chip
need other val_bytes.
Signed-off-by: Su Yanjun
---
drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
index f07e8b737d31..3dde52669343 100644
--- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
+++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
@@ -1308,6 +1308,7 @@ mcp251xfd_tef_obj_read(const struct mcp251xfd_priv *priv,
const u8 offset, const u8 len)
{
const struct mcp251xfd_tx_ring *tx_ring = priv->tx;
+ int val_bytes = regmap_get_val_bytes(priv->map_rx);
if (IS_ENABLED(CONFIG_CAN_MCP251XFD_SANITY) &&
(offset > tx_ring->obj_num ||
@@ -1322,7 +1323,7 @@ mcp251xfd_tef_obj_read(const struct mcp251xfd_priv *priv,
return regmap_bulk_read(priv->map_rx,
mcp251xfd_get_tef_obj_addr(offset),
hw_tef_obj,
- sizeof(*hw_tef_obj) / sizeof(u32) * len);
+ sizeof(*hw_tef_obj) / val_bytes * len);
}
static int mcp251xfd_handle_tefif(struct mcp251xfd_priv *priv)
@@ -1511,11 +1512,12 @@ mcp251xfd_rx_obj_read(const struct mcp251xfd_priv *priv,
const u8 offset, const u8 len)
{
int err;
+ int val_bytes = regmap_get_val_bytes(priv->map_rx);
err = regmap_bulk_read(priv->map_rx,
mcp251xfd_get_rx_obj_addr(ring, offset),
hw_rx_obj,
- len * ring->obj_size / sizeof(u32));
+ len * ring->obj_size / val_bytes);
return err;
}
@@ -2139,6 +2141,7 @@ static irqreturn_t mcp251xfd_irq(int irq, void *dev_id)
struct mcp251xfd_priv *priv = dev_id;
irqreturn_t handled = IRQ_NONE;
int err;
+ int val_bytes = regmap_get_val_bytes(priv->map_reg);
if (priv->rx_int)
do {
@@ -2162,7 +2165,7 @@ static irqreturn_t mcp251xfd_irq(int irq, void *dev_id)
err = regmap_bulk_read(priv->map_reg, MCP251XFD_REG_INT,
&priv->regs_status,
sizeof(priv->regs_status) /
- sizeof(u32));
+ val_bytes);
if (err)
goto out_fail;
--
2.25.1
Re: [PATCH v1] can: mcp251xfd: use regmap_bulk_write for compatibility
On 1/22/21 8:59 AM, Su wrote: > > 在 2021/1/22 下午3:26, Marc Kleine-Budde 写道: >> On 1/22/21 4:02 AM, Su Yanjun wrote: >>> Recently i use mcp2518fd on 4.x kernel which multiple write is not >>> backported, regmap_raw_write will cause old kernel crash because the >>> tx buffer in driver is smaller then 2K. Use regmap_bulk_write instead >>> for compatibility. >> Hmmm, this patch will never be backported to any 4.x kernel, as the driver is >> not available on these kernels. You have to carry patches for these kernels >> anyway, so I think I'll not take that patch. Sorry. Drop me a note if you are >> interested in updating your kernel to a recent v5.11 kernel. > > I got it. I have already port it to 4.x kernel. I just want anyone > working on old kernels to use the driver more easier. Ok, you can post a link yo your repo with the patches for the interested reader. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 3/4] drm/qxl: release shadow on shutdown
Hi
Am 20.01.21 um 12:12 schrieb Gerd Hoffmann:
In case we have a shadow surface on shutdown release
it so it doesn't leak.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_display.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index 38d6b596094d..60331e31861a 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -1229,5 +1229,9 @@ int qxl_modeset_init(struct qxl_device *qdev)
void qxl_modeset_fini(struct qxl_device *qdev)
{
+ if (qdev->dumb_shadow_bo) {
Wrt to my comment on patch 2, this might be the place to unpin the BO.
+ drm_gem_object_put(&qdev->dumb_shadow_bo->tbo.base);
+ qdev->dumb_shadow_bo = NULL;
+ }
qxl_destroy_monitors_object(qdev);
}
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
RE: Re: [PATCH 1/1] clk: aspeed: modify some default clks are critical
Hello, How about this patch progress? It does impact a lot of machine that when BMC boot at u-boot. SUART is work for Host. But after boot into kernel, due to the clk disabled. The SUART is not work for Host anymore. Regards, Ryan > -Original Message- > From: Samuel Holland > Sent: Thursday, October 29, 2020 10:25 AM > To: Stephen Boyd ; Joel Stanley > Cc: Andrew Jeffery ; Michael Turquette > ; Ryan Chen ; > BMC-SW ; Linux ARM > ; linux-aspeed > ; linux-...@vger.kernel.org; Linux Kernel > Mailing List > Subject: Re: Re: [PATCH 1/1] clk: aspeed: modify some default clks are > critical > > Stephen, > > On 10/14/20 12:16 PM, Stephen Boyd wrote: > > Quoting Joel Stanley (2020-10-13 22:28:00) > >> On Wed, 14 Oct 2020 at 02:50, Stephen Boyd wrote: > >>> > >>> Quoting Ryan Chen (2020-09-28 00:01:08) > In ASPEED SoC LCLK is LPC clock for all SuperIO device, UART1/UART2 > are default for Host SuperIO UART device, eSPI clk for Host eSPI > bus access eSPI slave channel, those clks can't be disable should > keep default, otherwise will affect Host side access SuperIO and SPI > slave > device. > > Signed-off-by: Ryan Chen > --- > >>> > >>> Is there resolution on this thread? > >> > >> Not yet. > >> > >> We have a system where the BMC (management controller) controls some > >> clocks, but the peripherals that it's clocking are outside the BMC's > >> control. In this case, the host processor us using some UARTs and > >> what not independent of any code running on the BMC. > >> > >> Ryan wants to have them marked as critical so the BMC never powers them > down. > >> > >> However, there are systems that don't use this part of the soc, so > >> for those implementations they are not critical and Linux on the BMC > >> can turn them off. > >> > >> Do you have any thoughts? Has anyone solved a similar problem already? > >> > > > > Is this critical clocks in DT? Where we want to have different DT for > > different device configurations to indicate that some clks should be > > marked critical so they're never turned off and other times they > > aren't so they're turned off? > > > > It also sounds sort of like the protected-clocks binding. Where you > > don't want to touch certain clks depending on the usage configuration > > of the SoC. There is a patch to make that generic that I haven't > > applied because it looks wrong at first glance[1]. Maybe not > > registering those clks to the framework on the configuration that Ryan has > > is > good enough? > > Could you please be more specific than the patch "looks wrong"? I'm more > than happy to update the patch to address your concerns, but I cannot do that > unless I know what your concerns are. > > Regards, > Samuel > > > [1] > > https://lore.kernel.org/r/20200903040015.5627-2-sam...@sholland.org
[PATCH v4] Fixes: misc: rtsx: init value of aspm_enabled
From: Ricky Wu make sure ASPM state sync with pcr->aspm_enabled init value pcr->aspm_enabled Cc: sta...@vger.kernel.org Signed-off-by: Ricky Wu --- v2: fixed conditions in v1 if-statement v3: give description for v1 and v2 v4: move version change below --- --- drivers/misc/cardreader/rtsx_pcr.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/misc/cardreader/rtsx_pcr.c b/drivers/misc/cardreader/rtsx_pcr.c index 2aa6648fa41f..5a491d2cd1ae 100644 --- a/drivers/misc/cardreader/rtsx_pcr.c +++ b/drivers/misc/cardreader/rtsx_pcr.c @@ -1512,6 +1512,7 @@ static int rtsx_pci_probe(struct pci_dev *pcidev, struct pcr_handle *handle; u32 base, len; int ret, i, bar = 0; + u8 val; dev_dbg(&(pcidev->dev), ": Realtek PCI-E Card Reader found at %s [%04x:%04x] (rev %x)\n", @@ -1577,7 +1578,11 @@ static int rtsx_pci_probe(struct pci_dev *pcidev, pcr->host_cmds_addr = pcr->rtsx_resv_buf_addr; pcr->host_sg_tbl_ptr = pcr->rtsx_resv_buf + HOST_CMDS_BUF_LEN; pcr->host_sg_tbl_addr = pcr->rtsx_resv_buf_addr + HOST_CMDS_BUF_LEN; - + rtsx_pci_read_register(pcr, ASPM_FORCE_CTL, &val); + if (val & FORCE_ASPM_CTL0 && val & FORCE_ASPM_CTL1) + pcr->aspm_enabled = false; + else + pcr->aspm_enabled = true; pcr->card_inserted = 0; pcr->card_removed = 0; INIT_DELAYED_WORK(&pcr->carddet_work, rtsx_pci_card_detect); -- 2.17.1
[PATCH] drivers: spi: spi-au1550: Fix various whitespace warnings
From: corentin
Signed-off-by: corentin
---
drivers/spi/spi-au1550.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/spi/spi-au1550.c b/drivers/spi/spi-au1550.c
index dfb7196f4caf..ca9121ce668d 100644
--- a/drivers/spi/spi-au1550.c
+++ b/drivers/spi/spi-au1550.c
@@ -74,8 +74,7 @@ struct au1550_spi {
/* we use an 8-bit memory device for dma transfers to/from spi fifo */
-static dbdev_tab_t au1550_spi_mem_dbdev =
-{
+static dbdev_tab_t au1550_spi_mem_dbdev = {
.dev_id = DBDMA_MEM_CHAN,
.dev_flags = DEV_FLAGS_ANYUSE|DEV_FLAGS_SYNC,
.dev_tsize = 0,
@@ -399,10 +398,10 @@ static int au1550_spi_dma_txrxb(struct spi_device *spi,
struct spi_transfer *t)
DMA_FROM_DEVICE);
}
/* unmap buffers if mapped above */
- if (t->rx_buf && t->rx_dma == 0 )
+ if (t->rx_buf && t->rx_dma == 0)
dma_unmap_single(hw->dev, dma_rx_addr, t->len,
DMA_FROM_DEVICE);
- if (t->tx_buf && t->tx_dma == 0 )
+ if (t->tx_buf && t->tx_dma == 0)
dma_unmap_single(hw->dev, dma_tx_addr, t->len,
DMA_TO_DEVICE);
@@ -493,12 +492,12 @@ static void au1550_spi_tx_word_##size(struct au1550_spi
*hw) \
wmb(); /* drain writebuffer */ \
}
-AU1550_SPI_RX_WORD(8,0xff)
-AU1550_SPI_RX_WORD(16,0x)
-AU1550_SPI_RX_WORD(32,0xff)
-AU1550_SPI_TX_WORD(8,0xff)
-AU1550_SPI_TX_WORD(16,0x)
-AU1550_SPI_TX_WORD(32,0xff)
+AU1550_SPI_RX_WORD(8, 0xff)
+AU1550_SPI_RX_WORD(16, 0x)
+AU1550_SPI_RX_WORD(32, 0xff)
+AU1550_SPI_TX_WORD(8, 0xff)
+AU1550_SPI_TX_WORD(16, 0x)
+AU1550_SPI_TX_WORD(32, 0xff)
static int au1550_spi_pio_txrxb(struct spi_device *spi, struct spi_transfer *t)
{
@@ -636,12 +635,14 @@ static irqreturn_t au1550_spi_pio_irq_callback(struct
au1550_spi *hw)
static int au1550_spi_txrx_bufs(struct spi_device *spi, struct spi_transfer *t)
{
struct au1550_spi *hw = spi_master_get_devdata(spi->master);
+
return hw->txrx_bufs(spi, t);
}
static irqreturn_t au1550_spi_irq(int irq, void *dev)
{
struct au1550_spi *hw = dev;
+
return hw->irq_callback(hw);
}
@@ -872,6 +873,7 @@ static int au1550_spi_probe(struct platform_device *pdev)
{
int min_div = (2 << 0) * (2 * (4 + 1));
int max_div = (2 << 3) * (2 * (63 + 1));
+
master->max_speed_hz = hw->pdata->mainclk_hz / min_div;
master->min_speed_hz =
hw->pdata->mainclk_hz / (max_div + 1) + 1;
--
2.25.1
Small student project idea on appropriate integration trees in MAINTAINERS
Dear all, here is a small student project idea: In previous work on MAINTAINERS and process conformance, Pia Eichinger [1] has investigated: are patches integrated by the maintainers defined by the responsibilities in MAINTAINERS? In this project, we are interested in a related (possibly simpler) question: Are the commits integrated into the appropriate integration trees referenced in MAINTAINERS? As I believe, a main difference between considering maintainers and integration trees is that the information in MAINTAINERS about integration trees is more erroneous, as it is not used as prominently as the personal maintainer information, name and email, with the wide-spread use of ./scripts/get_maintainer.pl. So, correcting those errors on integration trees in MAINTAINERS is more dominant (but also simpler) compared to correcting errors on personal maintainer information in MAINTAINERS. The answer on the question above can then ultimately be used to identify which integration tree entries should be added to specific sections in MAINTAINERS to match best against the actual integration observed in git. The factors and metric to determine what is best is of course the challenging task of identifying a suitable heuristics that is: 1. good enough to be used to create a change to MAINTAINERS that is accepted by the community, and 2. simple enough to be implemented with reasonable effort. Background: The MAINTAINERS section includes references, through the T: entries, to the location of a source configuration management (SCM) tree with its type, e.g., git, quilt, hg, For each commit, the kernel git history carries the commit's integration tree path, i.e., the information through with source configuration management (SCM) trees a commit was integrated until it was finally integrated into Linus Torvalds' tree. Ideally the references in the MAINTAINERS sections are: - complete, i.e, all integration trees used for recent kernel releases are mentioned in MAINTAINERS. - sound, i.e., the majority of the commits are integrated through the trees referenced in the MAINTAINERS sections a patch belongs to. - precise, i.e., for each MAINTAINERS section, the majority of the commits that belong to a section are integrated through the tree referenced in that section. Goal: We identify and measure to these properties above, completeness, soundness and precision. Then, we use that information to determine which integration tree entries should be added to which specific sections to maximally increase the three properties. To evaluate the adequacy of this method, we can obtain feedback from the responsible kernel maintainers through proposing patches modifying the MAINTAINERS file, for the additions that we identified as most relevant (maximally increasing the properties, to a reasonable threshold of number of patch proposals [to not swamp maintainers initially] and a threshold on relevance [to not send out minor changes that are largely irrelevant to the community]). In this project, we can make use of: - gitdm [git://git.lwn.net/gitdm.git]: gitdm includes some scripts to parse MAINTAINERS and obtain the integration tree patch of a commit. and/or - pasta [https://github.com/lfd/PaStA]: Similarly to gitdm, pasta provides functionality to parse MAINTAINERS and some functionalities on extracting information on commits. Potential project phases: - In the first phase (PoC phase), we could probably just create a setup that combines or extends the functionality in gitdm and/or in pasta. - In the second phase (MAINTAINERS patch creation phase), we send out some patches and collect feedback from maintainers. - In a third phase, with a better understanding of the individual pieces in gitdm and/or in pasta, we could then create a cleaner design that also refactors gitdm and pasta to share the same implementation when essentially the same basic functionality is used within the various analyses. References: [1] https://lists.elisa.tech/g/devel/message/1269 --- Any thoughts on this small student project? If it is not too crazy, I will mentor a student on this project through one of the next mentoring programs (Google Summer of Code, LF mentorship, etc.). Lukas
Re: [PATCH] drm/panfrost: Add governor data with pre-defined thresholds
On 21/01/2021 17:04, Lukasz Luba wrote:
The simple_ondemand devfreq governor uses two thresholds to decide about
the frequency change: upthreshold, downdifferential. These two tunable
change the behavior of the governor decision, e.g. how fast to increase
the frequency or how rapidly limit the frequency. This patch adds needed
governor data with thresholds values gathered experimentally in different
workloads.
Signed-off-by: Lukasz Luba
---
Hi all,
This patch aims to improve the panfrost performance in various workloads,
(benchmarks, games). The simple_ondemand devfreq governor supports
tunables to tweak the behaviour of the internal algorithm. The default
values for these two thresholds (90 and 5) do not work well with panfrost.
These new settings should provide good performance, short latency for
rising the frequency due to rapid workload change and decent freq slow
down when the load is decaying. Based on frequency change statistics,
gathered during experiments, all frequencies are used, depending on
the load. This provides some power savings (statistically). The highest
frequency is also used when needed.
Example glmark2 results:
1. freq fixed to max: 153
2. these new thresholds values (w/ patch): 151
3. default governor values (w/o patch): 114
It would be good to state which platform this is on as this obviously
can vary depending on the OPPs available.
Of course the real fix here would be to improve the utilisation of the
GPU[1] so we actually hit the 90% threshold more easily (AFAICT kbase
uses the default 90/5 thresholds), but this seems like a reasonable
change for now.
Reviewed-by: Steven Price
Thanks,
Steve
[1] When I get some time I need to rework the "queue jobs on the
hardware"[2] patch I posted ages ago. Last time it actually caused a
performance regression though...
[2] https://lore.kernel.org/r/20190816093107.30518-2-steven.price%40arm.com
In future the devfreq framework would expose via sysfs these two
tunables, so they can be adjusted by the middleware based on currently
running workload (game, desktop, web browser, etc). These new values
should be good enough, though.
Regards,
Lukasz Luba
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 10 +-
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 2 ++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 56b3f5935703..7c5ffc81dce1 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -130,8 +130,16 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
panfrost_devfreq_profile.initial_freq = cur_freq;
dev_pm_opp_put(opp);
+ /*
+* Setup default thresholds for the simple_ondemand governor.
+* The values are chosen based on experiments.
+*/
+ pfdevfreq->gov_data.upthreshold = 45;
+ pfdevfreq->gov_data.downdifferential = 5;
+
devfreq = devm_devfreq_add_device(dev, &panfrost_devfreq_profile,
- DEVFREQ_GOV_SIMPLE_ONDEMAND, NULL);
+ DEVFREQ_GOV_SIMPLE_ONDEMAND,
+ &pfdevfreq->gov_data);
if (IS_ERR(devfreq)) {
DRM_DEV_ERROR(dev, "Couldn't initialize GPU devfreq\n");
ret = PTR_ERR(devfreq);
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
index db6ea48e21f9..1e2a4de941aa 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
@@ -4,6 +4,7 @@
#ifndef __PANFROST_DEVFREQ_H__
#define __PANFROST_DEVFREQ_H__
+#include
#include
#include
@@ -17,6 +18,7 @@ struct panfrost_devfreq {
struct devfreq *devfreq;
struct opp_table *regulators_opp_table;
struct thermal_cooling_device *cooling;
+ struct devfreq_simple_ondemand_data gov_data;
bool opp_of_table_added;
ktime_t busy_time;
Re: [PATCH 1/1] s390/vfio-ap: No need to disable IRQ after queue reset
On 21.01.21 08:20, Halil Pasic wrote:
> From: Tony Krowiak
>
> The queues assigned to a matrix mediated device are currently reset when:
>
> * The VFIO_DEVICE_RESET ioctl is invoked
> * The mdev fd is closed by userspace (QEMU)
> * The mdev is removed from sysfs.
>
> Immediately after the reset of a queue, a call is made to disable
> interrupts for the queue. This is entirely unnecessary because the reset of
> a queue disables interrupts, so this will be removed.
>
> Furthermore, vfio_ap_irq_disable() does an unconditional PQAP/AQIC which
> can result in a specification exception (when the corresponding facility
> is not available), so this is actually a bugfix.
>
> Signed-off-by: Tony Krowiak
> [pa...@linux.ibm.com: minor rework before merging]
> Reviewed-by: Halil Pasic
> Signed-off-by: Halil Pasic
> Fixes: ec89b55e3bce ("s390: ap: implement PAPQ AQIC interception in kernel")
> Cc:
Acked-by: Christian Borntraeger
Heiko, Vasily, lets carry this via the s390 tree.
>
> ---
>
> Since it turned out disabling the interrupts via PQAP/AQIC is not only
> unnecesary but also buggy, we decided to put this patch, which
> used to be apart of the series https://lkml.org/lkml/2020/12/22/757 on the
> fast
> lane.
>
> If the backports turn out to be a bother, which I hope won't be the case
> not, I am happy to help with those.
>
> ---
> drivers/s390/crypto/vfio_ap_drv.c | 6 +-
> drivers/s390/crypto/vfio_ap_ops.c | 100 --
> drivers/s390/crypto/vfio_ap_private.h | 12 ++--
> 3 files changed, 69 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/s390/crypto/vfio_ap_drv.c
> b/drivers/s390/crypto/vfio_ap_drv.c
> index be2520cc010b..7dc72cb718b0 100644
> --- a/drivers/s390/crypto/vfio_ap_drv.c
> +++ b/drivers/s390/crypto/vfio_ap_drv.c
> @@ -71,15 +71,11 @@ static int vfio_ap_queue_dev_probe(struct ap_device
> *apdev)
> static void vfio_ap_queue_dev_remove(struct ap_device *apdev)
> {
> struct vfio_ap_queue *q;
> - int apid, apqi;
>
> mutex_lock(&matrix_dev->lock);
> q = dev_get_drvdata(&apdev->device);
> + vfio_ap_mdev_reset_queue(q, 1);
> dev_set_drvdata(&apdev->device, NULL);
> - apid = AP_QID_CARD(q->apqn);
> - apqi = AP_QID_QUEUE(q->apqn);
> - vfio_ap_mdev_reset_queue(apid, apqi, 1);
> - vfio_ap_irq_disable(q);
> kfree(q);
> mutex_unlock(&matrix_dev->lock);
> }
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c
> b/drivers/s390/crypto/vfio_ap_ops.c
> index e0bde8518745..7ceb6c433b3b 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -25,6 +25,7 @@
> #define VFIO_AP_MDEV_NAME_HWVIRT "VFIO AP Passthrough Device"
>
> static int vfio_ap_mdev_reset_queues(struct mdev_device *mdev);
> +static struct vfio_ap_queue *vfio_ap_find_queue(int apqn);
>
> static int match_apqn(struct device *dev, const void *data)
> {
> @@ -49,20 +50,15 @@ static struct vfio_ap_queue *vfio_ap_get_queue(
> int apqn)
> {
> struct vfio_ap_queue *q;
> - struct device *dev;
>
> if (!test_bit_inv(AP_QID_CARD(apqn), matrix_mdev->matrix.apm))
> return NULL;
> if (!test_bit_inv(AP_QID_QUEUE(apqn), matrix_mdev->matrix.aqm))
> return NULL;
>
> - dev = driver_find_device(&matrix_dev->vfio_ap_drv->driver, NULL,
> - &apqn, match_apqn);
> - if (!dev)
> - return NULL;
> - q = dev_get_drvdata(dev);
> - q->matrix_mdev = matrix_mdev;
> - put_device(dev);
> + q = vfio_ap_find_queue(apqn);
> + if (q)
> + q->matrix_mdev = matrix_mdev;
>
> return q;
> }
> @@ -119,13 +115,18 @@ static void vfio_ap_wait_for_irqclear(int apqn)
> */
> static void vfio_ap_free_aqic_resources(struct vfio_ap_queue *q)
> {
> - if (q->saved_isc != VFIO_AP_ISC_INVALID && q->matrix_mdev)
> + if (!q)
> + return;
> + if (q->saved_isc != VFIO_AP_ISC_INVALID &&
> + !WARN_ON(!(q->matrix_mdev && q->matrix_mdev->kvm))) {
> kvm_s390_gisc_unregister(q->matrix_mdev->kvm, q->saved_isc);
> - if (q->saved_pfn && q->matrix_mdev)
> + q->saved_isc = VFIO_AP_ISC_INVALID;
> + }
> + if (q->saved_pfn && !WARN_ON(!q->matrix_mdev)) {
> vfio_unpin_pages(mdev_dev(q->matrix_mdev->mdev),
>&q->saved_pfn, 1);
> - q->saved_pfn = 0;
> - q->saved_isc = VFIO_AP_ISC_INVALID;
> + q->saved_pfn = 0;
> + }
> }
>
> /**
> @@ -144,7 +145,7 @@ static void vfio_ap_free_aqic_resources(struct
> vfio_ap_queue *q)
> * Returns if ap_aqic function failed with invalid, deconfigured or
> * checkstopped AP.
> */
> -struct ap_queue_status vfio_ap_irq_disable(struct vfio_ap_queue *q)
> +static struct ap_queue_status vfio_ap_irq_disable(struct vfio_ap_queue *q)
> {
> struct ap_qirq_ctrl aqic_gisa = {};
> struct ap_queue_status st
Re: [RFC][PATCH 00/25] Network fs helper library & fscache kiocb API
On Thu, Jan 21, 2021 at 06:55:13PM +, David Howells wrote: > > Is it that those "bridging" blocks only show up in certain corner cases > > that users can arrange to avoid? Or that it's OK as long as you use > > certain specific file systems whose behavior goes beyond what's > > technically required by the bamp or seek interfaces? > > That's a question for the xfs, ext4 and btrfs maintainers, and may vary > between kernel versions and fsck or filesystem packing utility versions. For XFS if you do not use reflinks, extent size hints or the RT subvolume there are no new allocations before i_size that will magically show up. But relying on such undocumented assumptions is very dangerous.
Re: [PATCH net-next] vmxnet3: Remove buf_info from device accessible structures
On 1/21/21, 5:07 PM, "Jakub Kicinski" wrote:
> On Tue, 19 Jan 2021 18:19:40 -0800 Ronak Doshi wrote:
> > From: Petr Vandrovec
> >
> > vmxnet3: Remove buf_info from device accessible structures
>
>Something happened to the posting, looks like the subject is listed
> twice?
It got sent twice. Please ignore.
> > - if (!tq->buf_info)
> > + tq->buf_info = kmalloc_array_node(tq->tx_ring.size,
> sizeof(tq->buf_info[0]),
> > +GFP_KERNEL | __GFP_ZERO,
> > +dev_to_node(&adapter->pdev->dev));
>
> kcalloc_node()
Sure, will use this callback.
> > + if (!tq->buf_info) {
> > + netdev_err(adapter->netdev, "failed to allocate tx buffer
> info\n")
>
> Please drop the message, OOM splat will be visible enough. checkpatch
> usually points this out
Okay, will drop it. Checkpatch did not complain about the error message though.
Thanks,
Ronak
Re: [PATCH v5] s390/vfio-ap: clean up vfio_ap resources when KVM pointer invalidated
On 23.12.20 02:20, Tony Krowiak wrote:
> The vfio_ap device driver registers a group notifier with VFIO when the
> file descriptor for a VFIO mediated device for a KVM guest is opened to
> receive notification that the KVM pointer is set (VFIO_GROUP_NOTIFY_SET_KVM
> event). When the KVM pointer is set, the vfio_ap driver takes the
> following actions:
> 1. Stashes the KVM pointer in the vfio_ap_mdev struct that holds the state
>of the mediated device.
> 2. Calls the kvm_get_kvm() function to increment its reference counter.
> 3. Sets the function pointer to the function that handles interception of
>the instruction that enables/disables interrupt processing.
> 4. Sets the masks in the KVM guest's CRYCB to pass AP resources through to
>the guest.
>
> In order to avoid memory leaks, when the notifier is called to receive
> notification that the KVM pointer has been set to NULL, the vfio_ap device
> driver should reverse the actions taken when the KVM pointer was set.
>
> Fixes: 258287c994de ("s390: vfio-ap: implement mediated device open callback")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Tony Krowiak
> Reviewed-by: Halil Pasic
> Reviewed-by: Cornelia Huck
Just to keep you up2date why this patch is still waiting in our queue. This
triggered
a lockdep splat in the CI which we want to fix first.
Re: [PATCH] mm: Fix potential pte_unmap_unlock pte error
Hi Andrew:
On 2021/1/14 10:51, Miaohe Lin wrote:
> Hi:
> On 2021/1/11 1:14, Andi Kleen wrote:
>> On Sat, Jan 09, 2021 at 03:01:18AM -0500, Miaohe Lin wrote:
>>> Since commit 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged
>>> high MMIO PROT_NONE mappings"), when the first pfn modify is not allowed,
>>> we would break the loop with pte unchanged. Then the wrong pte - 1 would
>>> be passed to pte_unmap_unlock.
>>
>> Thanks.
>>
>> While the fix is correct, I'm not sure if it actually is a real bug. Is there
>> any architecture that would do something else than unlocking the underlying
>> page? If it's just the underlying page then it should be always the same
>> page, so no bug.
>>
>
> It's just a theoretical issue via code inspection.
Should I send a new one without Cc statle or just drop this patch? Thanks.
>
>> That said of course the change is the right thing for main line, but
>> probably doesn't
>> need to be backported.
>>
>
> So it should not be backported. Should I resend a patch or Andrew would
> kindly do this?
>
>> -Andi
>> .
>>
>
> Many thanks for review and reply.
>
Re: [PATCH v4] Fixes: misc: rtsx: init value of aspm_enabled
On Fri, Jan 22, 2021 at 04:19:06PM +0800, ricky...@realtek.com wrote: > From: Ricky Wu > > make sure ASPM state sync with pcr->aspm_enabled > init value pcr->aspm_enabled > > Cc: sta...@vger.kernel.org > Signed-off-by: Ricky Wu > --- > > v2: fixed conditions in v1 if-statement > v3: give description for v1 and v2 > v4: move version change below --- What commit id does this fix? How far back should the stable backporting go? That's what we use the Fixes: line for. thanks, greg k-h
Re: [PATCH net-next] net: core: devlink: add new trap action HARD_DROP
From: Ido Schimmel
Sent: Thursday, January 21, 2021 2:21 PM
To: Oleksandr Mazur
Cc: net...@vger.kernel.org ; j...@nvidia.com
; da...@davemloft.net ;
linux-kernel@vger.kernel.org ; k...@kernel.org
Subject: Re: [PATCH net-next] net: core: devlink: add new trap action HARD_DROP
On Thu, Jan 21, 2021 at 01:29:37PM +0200, Oleksandr Mazur wrote:
>> Add new trap action HARD_DROP, which can be used by the
>> drivers to register traps, where it's impossible to get
>> packet reported to the devlink subsystem by the device
>> driver, because it's impossible to retrieve dropped packet
>> from the device itself.
>> In order to use this action, driver must also register
>> additional devlink operation - callback that is used
>> to retrieve number of packets that have been dropped by
>> the device.
>Are these global statistics about number of packets the hardware dropped
> for a specific reason or are these per-port statistics?
Global statistics. Basically, it’s the DROP action, with the only difference
that device might be unable to post the packet to the devlink subsystem.
Also, as this is an action, it could also be altered: e.g. changed to ‘mirror’
or else.
> Anyway, this patch really needs to be marked as "RFC" since we cannot
> add infrastructure without anyone using it.
Will do.
Also, should I make a V2 patch, that will already hold the RFC tag and the
changes (which include the commentaries fixes)?
> Additionally, the documentation
> (Documentation/networking/devlink/devlink-trap.rst) needs to be updated,
> netdevsim needs to be patched and the test over netdevsim
> (tools/testing/selftests/drivers/net/netdevsim/devlink_trap.sh) needs to
> be extended to cover the new functionality.
Okay. Will do.
>> @@ -9876,6 +9915,9 @@ void devlink_trap_report(struct devlink *devlink,
>> struct sk_buff *skb,
>> {
>>struct devlink_trap_item *trap_item = trap_ctx;
>>
>> + if (trap_item->action == DEVLINK_TRAP_ACTION_HARD_DROP)
>> + return;
>How can this happen?
My bad. Will get removed in V2.
[PATCH] scsi: sd: print write through due to no caching mode page as warning
For SD cardreaders it's extremely common not to find cache on disk.
The following error messages are thus very common and don't point
to a real error one could try to fix but rather describe how the disk
works:
sd 0:0:0:0: [sda] No Caching mode page found
sd 0:0:0:0: [sda] Assuming drive cache: write through
Print these messages as warnings instead of errors.
Signed-off-by: Martin Kepplinger
---
drivers/scsi/sd.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index e7c52d6df4dc..db0171c81c5b 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -2808,7 +2808,8 @@ sd_read_cache_type(struct scsi_disk *sdkp, unsigned char
*buffer)
}
}
- sd_first_printk(KERN_ERR, sdkp, "No Caching mode page found\n");
+ sd_first_printk(KERN_WARNING, sdkp,
+ "No Caching mode page found\n");
goto defaults;
Page_found:
@@ -2863,7 +2864,7 @@ sd_read_cache_type(struct scsi_disk *sdkp, unsigned char
*buffer)
"Assuming drive cache: write back\n");
sdkp->WCE = 1;
} else {
- sd_first_printk(KERN_ERR, sdkp,
+ sd_first_printk(KERN_WARNING, sdkp,
"Assuming drive cache: write through\n");
sdkp->WCE = 0;
}
--
2.20.1
[PATCH v2 net-next] vmxnet3: Remove buf_info from device
vmxnet3: Remove buf_info from device accessible structures
buf_info structures in RX & TX queues are private driver data that
do not need to be visible to the device. Although there is physical
address and length in the queue descriptor that points to these
structures, their layout is not standardized, and device never looks
at them.
So lets allocate these structures in non-DMA-able memory, and fill
physical address as all-ones and length as zero in the queue
descriptor.
That should alleviate worries brought by Martin Radev in
https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20210104/022829.html
that malicious vmxnet3 device could subvert SVM/TDX guarantees.
Signed-off-by: Petr Vandrovec
Signed-off-by: Ronak Doshi
---
Changes in v2:
- Use kcalloc_node()
- Remove log for memory allocation failure
---
drivers/net/vmxnet3/vmxnet3_drv.c | 37 -
drivers/net/vmxnet3/vmxnet3_int.h | 2 --
2 files changed, 12 insertions(+), 27 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c
b/drivers/net/vmxnet3/vmxnet3_drv.c
index 336504b7531d..c263b4767b28 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -452,9 +452,7 @@ vmxnet3_tq_destroy(struct vmxnet3_tx_queue *tq,
tq->comp_ring.base = NULL;
}
if (tq->buf_info) {
- dma_free_coherent(&adapter->pdev->dev,
- tq->tx_ring.size * sizeof(tq->buf_info[0]),
- tq->buf_info, tq->buf_info_pa);
+ kfree(tq->buf_info);
tq->buf_info = NULL;
}
}
@@ -505,8 +503,6 @@ static int
vmxnet3_tq_create(struct vmxnet3_tx_queue *tq,
struct vmxnet3_adapter *adapter)
{
- size_t sz;
-
BUG_ON(tq->tx_ring.base || tq->data_ring.base ||
tq->comp_ring.base || tq->buf_info);
@@ -534,9 +530,9 @@ vmxnet3_tq_create(struct vmxnet3_tx_queue *tq,
goto err;
}
- sz = tq->tx_ring.size * sizeof(tq->buf_info[0]);
- tq->buf_info = dma_alloc_coherent(&adapter->pdev->dev, sz,
- &tq->buf_info_pa, GFP_KERNEL);
+ tq->buf_info = kcalloc_node(tq->tx_ring.size, sizeof(tq->buf_info[0]),
+ GFP_KERNEL | __GFP_ZERO,
+ dev_to_node(&adapter->pdev->dev));
if (!tq->buf_info)
goto err;
@@ -1738,10 +1734,7 @@ static void vmxnet3_rq_destroy(struct vmxnet3_rx_queue
*rq,
}
if (rq->buf_info[0]) {
- size_t sz = sizeof(struct vmxnet3_rx_buf_info) *
- (rq->rx_ring[0].size + rq->rx_ring[1].size);
- dma_free_coherent(&adapter->pdev->dev, sz, rq->buf_info[0],
- rq->buf_info_pa);
+ kfree(rq->buf_info[0]);
rq->buf_info[0] = rq->buf_info[1] = NULL;
}
}
@@ -1883,10 +1876,9 @@ vmxnet3_rq_create(struct vmxnet3_rx_queue *rq, struct
vmxnet3_adapter *adapter)
goto err;
}
- sz = sizeof(struct vmxnet3_rx_buf_info) * (rq->rx_ring[0].size +
- rq->rx_ring[1].size);
- bi = dma_alloc_coherent(&adapter->pdev->dev, sz, &rq->buf_info_pa,
- GFP_KERNEL);
+ bi = kcalloc_node(rq->rx_ring[0].size + rq->rx_ring[1].size,
+ sizeof(rq->buf_info[0][0]), GFP_KERNEL | __GFP_ZERO,
+ dev_to_node(&adapter->pdev->dev));
if (!bi)
goto err;
@@ -2522,14 +2514,12 @@ vmxnet3_setup_driver_shared(struct vmxnet3_adapter
*adapter)
tqc->txRingBasePA = cpu_to_le64(tq->tx_ring.basePA);
tqc->dataRingBasePA = cpu_to_le64(tq->data_ring.basePA);
tqc->compRingBasePA = cpu_to_le64(tq->comp_ring.basePA);
- tqc->ddPA = cpu_to_le64(tq->buf_info_pa);
+ tqc->ddPA = cpu_to_le64(~0ULL);
tqc->txRingSize = cpu_to_le32(tq->tx_ring.size);
tqc->dataRingSize = cpu_to_le32(tq->data_ring.size);
tqc->txDataRingDescSize = cpu_to_le32(tq->txdata_desc_size);
tqc->compRingSize = cpu_to_le32(tq->comp_ring.size);
- tqc->ddLen = cpu_to_le32(
- sizeof(struct vmxnet3_tx_buf_info) *
- tqc->txRingSize);
+ tqc->ddLen = cpu_to_le32(0);
tqc->intrIdx= tq->comp_ring.intr_idx;
}
@@ -2541,14 +2531,11 @@ vmxnet3_setup_driver_shared(struct vmxnet3_adapter
*adapter)
rqc->rxRingBasePA[0] = cpu_to_le64(rq->rx_ring[0].basePA);
rqc->rxRingBasePA[1] = cpu_to_le64(rq->rx_ring[1].basePA);
rqc->compRingBasePA = cpu_to_le64(rq->comp_ring.basePA);
-
[PATCH v2] hugetlbfs: make hugepage size conversion more readable
The calculation 1U << (h->order + PAGE_SHIFT - 10) is actually equal to
(PAGE_SHIFT << (h->order)) >> 10. So we can make it more readable by
replace it with huge_page_size(h) >> 10.
Signed-off-by: Miaohe Lin
---
fs/hugetlbfs/inode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 25c1857ff45d..c87894b221da 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -1519,8 +1519,8 @@ static struct vfsmount *__init mount_one_hugetlbfs(struct
hstate *h)
put_fs_context(fc);
}
if (IS_ERR(mnt))
- pr_err("Cannot mount internal hugetlbfs for page size %uK",
- 1U << (h->order + PAGE_SHIFT - 10));
+ pr_err("Cannot mount internal hugetlbfs for page size %luK",
+ huge_page_size(h) >> 10);
return mnt;
}
--
2.19.1
Re: [PATCH v27 12/12] landlock: Add user and kernel documentation
Hello Mickaël, It would be great to have some manual pages for these system calls before release... Can you prepare something? Thanks, Michael On Thu, 21 Jan 2021 at 21:51, Mickaël Salaün wrote: > > From: Mickaël Salaün > > This documentation can be built with the Sphinx framework. > > Cc: James Morris > Cc: Jann Horn > Cc: Kees Cook > Cc: Serge E. Hallyn > Signed-off-by: Mickaël Salaün > Reviewed-by: Vincent Dagonneau > --- > > Changes since v25: > * Explain the behavior of layered access rights. > * Explain how bind mounts and overayfs mounts are handled by Landlock: > merged overlayfs mount points have their own inodes, which makes these > hierarchies independent from its upper and lower layers, unlike bind > mounts which share the same inodes between the source hierarchy and > the mount point hierarchy. > New overlayfs mount and bind mount tests check these behaviors. > * Synchronize with the new syscalls.c file and update syscall names. > * Fix spelling. > * Remove Reviewed-by Jann Horn because of the above changes. > > Changes since v24: > * Add Reviewed-by Jann Horn. > * Add a paragraph to explain how the ruleset layers work. > * Bump date. > > Changes since v23: > * Explain limitations for the maximum number of stacked ruleset, and the > memory usage restrictions. > > Changes since v22: > * Fix spelling and remove obsolete sentence (spotted by Jann Horn). > * Bump date. > > Changes since v21: > * Move the user space documentation to userspace-api/landlock.rst and > the kernel documentation to security/landlock.rst . > * Add license headers. > * Add last update dates. > * Update MAINTAINERS file. > * Add (back) links to git.kernel.org . > * Fix spelling. > > Changes since v20: > * Update examples and documentation with the new syscalls. > > Changes since v19: > * Update examples and documentation with the new syscalls. > > Changes since v15: > * Add current limitations. > > Changes since v14: > * Fix spelling (contributed by Randy Dunlap). > * Extend documentation about inheritance and explain layer levels. > * Remove the use of now-removed access rights. > * Use GitHub links. > * Improve kernel documentation. > * Add section for tests. > * Update example. > > Changes since v13: > * Rewrote the documentation according to the major revamp. > > Previous changes: > https://lore.kernel.org/lkml/20191104172146.30797-8-...@digikod.net/ > --- > Documentation/security/index.rst | 1 + > Documentation/security/landlock.rst | 79 ++ > Documentation/userspace-api/index.rst| 1 + > Documentation/userspace-api/landlock.rst | 306 +++ > MAINTAINERS | 2 + > 5 files changed, 389 insertions(+) > create mode 100644 Documentation/security/landlock.rst > create mode 100644 Documentation/userspace-api/landlock.rst > > diff --git a/Documentation/security/index.rst > b/Documentation/security/index.rst > index 8129405eb2cc..16335de04e8c 100644 > --- a/Documentation/security/index.rst > +++ b/Documentation/security/index.rst > @@ -16,3 +16,4 @@ Security Documentation > siphash > tpm/index > digsig > + landlock > diff --git a/Documentation/security/landlock.rst > b/Documentation/security/landlock.rst > new file mode 100644 > index ..244e616d3d7a > --- /dev/null > +++ b/Documentation/security/landlock.rst > @@ -0,0 +1,79 @@ > +.. SPDX-License-Identifier: GPL-2.0 > +.. Copyright © 2017-2020 Mickaël Salaün > +.. Copyright © 2019-2020 ANSSI > + > +== > +Landlock LSM: kernel documentation > +== > + > +:Author: Mickaël Salaün > +:Date: January 2021 > + > +Landlock's goal is to create scoped access-control (i.e. sandboxing). To > +harden a whole system, this feature should be available to any process, > +including unprivileged ones. Because such process may be compromised or > +backdoored (i.e. untrusted), Landlock's features must be safe to use from the > +kernel and other processes point of view. Landlock's interface must > therefore > +expose a minimal attack surface. > + > +Landlock is designed to be usable by unprivileged processes while following > the > +system security policy enforced by other access control mechanisms (e.g. DAC, > +LSM). Indeed, a Landlock rule shall not interfere with other access-controls > +enforced on the system, only add more restrictions. > + > +Any user can enforce Landlock rulesets on their processes. They are merged > and > +evaluated according to the inherited ones in a way that ensures that only > more > +constraints can be added. > + > +User space documentation can be found here: :doc:`/userspace-api/landlock`. > + > +Guiding principles for safe access controls > +=== > + > +* A Landlock rule shall be focused on access control on kernel objects > instead > + of syscall filtering (i.e. syscall arguments), which is the purpose of > + seccomp-bpf. >
Re: [RFC][PATCH 4/7] smp: Optimize send_call_function_single_ipi()
On Thu, Jan 21, 2021 at 04:20:12PM -0800, Paul E. McKenney wrote: > > --- > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > > index 368749008ae8..2c8d4c3e341e 100644 > > --- a/kernel/rcu/tree.c > > +++ b/kernel/rcu/tree.c > > @@ -445,7 +445,7 @@ static int rcu_is_cpu_rrupt_from_idle(void) > > /* > > * Usually called from the tick; but also used from smp_function_call() > > * for expedited grace periods. This latter can result in running from > > -* the idle task, instead of an actual IPI. > > +* a (usually the idle) task, instead of an actual IPI. > > The story is growing enough hair that we should tell it only once. > So here just where it is called from: > > /* >* Usually called from the tick; but also used from smp_function_call() >* for expedited grace periods. >*/ > > > lockdep_assert_irqs_disabled(); > > > > @@ -461,9 +461,14 @@ static int rcu_is_cpu_rrupt_from_idle(void) > > return false; > > > > /* > > -* If we're not in an interrupt, we must be in the idle task! > > +* If we're not in an interrupt, we must be in task context. > > +* > > +* This will typically be the idle task through: > > +* flush_smp_call_function_from_idle(), > > +* > > +* but can also be in CPU HotPlug through smpcfd_dying(). > > */ > > Good, but how about like this? > > /* >* If we are not in an interrupt handler, we must be in >* smp_call_function() handler. >* >* Normally, smp_call_function() handlers are invoked from >* the idle task via flush_smp_call_function_from_idle(). >* However, they can also be invoked from CPU hotplug >* operations via smpcfd_dying(). >*/ > > > - WARN_ON_ONCE(!nesting && !is_idle_task(current)); > > + WARN_ON_ONCE(!nesting && !in_task(current)); > > This is used in time-critical contexts, so why not RCU_LOCKDEP_WARN()? > That should also allow checking more closely. Would something like the > following work? > > RCU_LOCKDEP_WARN(!nesting && !is_idle_task(current) && > (!in_task(current) || !lockdep_cpus_write_held())); > > Where lockdep_cpus_write_held is defined in kernel/cpu.c: Works for me, except s/in_task(current)/in_task()/ compiles a lot better.
Re: [PATCH V3 0/3] mm/memory_hotplug: Pre-validate the address range with platform
On 22.01.21 07:04, Anshuman Khandual wrote: > > On 1/20/21 2:07 PM, Anshuman Khandual wrote: >> >> >> On 1/19/21 7:10 PM, Oscar Salvador wrote: >>> On Tue, Jan 19, 2021 at 02:33:03PM +0100, David Hildenbrand wrote: Minor thing, we should make up our mind if we want to call stuff internally "memhp_" or "mhp". I prefer the latter, because it is shorter. >>> >>> I would rather use the latter as well. I used that in [1]. >> >> Okay, will change all that is 'memhp' as 'mhp' instead. >> >>> MEMHP_MERGE_RESOURCE should be renamed if we agree on that. >>> >>> [1] >>> https://patchwork.kernel.org/project/linux-mm/cover/20201217130758.11565-1-osalva...@suse.de/ >>> > > While replacing 'memhp' as 'mhp' in this series, noticed there are > some more 'memhp' scattered around the code from earlier. A mix of > both 'memhp' and 'mhp' might not be a good idea. Hence should we > just change these remaining 'memhp' as 'mhp' as well and possibly > also MEMHP_MERGE_RESOURCE as suggested earlier, in a subsequent As mentioned in another thread to Oscar, I already have a cleanup patch for that one lying around, part of a bigger series. Might just send that one out separately earlier. > clean up patch ? Would there be a problem with memhp_default_state > being a command line parameter ? Yes, that one we should not change, to not break existing cmdlines without good reason. We could change the memhp_default_online_type/memhp_online_type_from_str/... thingies, though. Feel free to send a patch, thanks! -- Thanks, David / dhildenb
Re: [PATCH v4] can: mcp251xfd: replace sizeof(u32) with val_bytes in regmap
On Fri, Jan 22, 2021 at 04:13:34PM +0800, Su Yanjun wrote: > The sizeof(u32) is hardcoded. It's better to use the config value in > regmap. > > It increases the size of target object, but it's flexible when new mcp chip > need other val_bytes. > > Signed-off-by: Su Yanjun Applied to linux-can-next/testing. Thanks, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: PGP signature
Re: [PATCH net-next] net: core: devlink: add new trap action HARD_DROP
On Thu, 21 Jan 2021 14:21:52 +0200 Ido Schimmel wrote: > On Thu, Jan 21, 2021 at 01:29:37PM +0200, Oleksandr Mazur wrote: > > Add new trap action HARD_DROP, which can be used by the > > drivers to register traps, where it's impossible to get > > packet reported to the devlink subsystem by the device > > driver, because it's impossible to retrieve dropped packet > > from the device itself. > > In order to use this action, driver must also register > > additional devlink operation - callback that is used > > to retrieve number of packets that have been dropped by > > the device. > > Are these global statistics about number of packets the hardware dropped > for a specific reason or are these per-port statistics? > > It's a creative use of devlink-trap interface, but I think it makes > sense. Better to re-use an existing interface than creating yet another > one. > Not sure if I agree, if we can't trap why is it a trap? > It's just a counter. It's just another ACTION for trap item. Action however can be switched, e.g. from HARD_DROP to MIRROR. The thing is to be able to configure specific trap to be dropped, and provide a way for the device to report back how many packets have been dropped. If device is able to report the packet itself, then devlink would be in charge of counting. If not, there should be a way to retrieve these statistics from the devlink.
[RFC PATCH] kvm: arm64: Try stage2 block mapping for host device MMIO
The MMIO region of a device maybe huge (GB level), try to use block
mapping in stage2 to speedup both map and unmap.
Especially for unmap, it performs TLBI right after each invalidation
of PTE. If all mapping is of PAGE_SIZE, it takes much time to handle
GB level range.
Signed-off-by: Keqian Zhu
---
arch/arm64/include/asm/kvm_pgtable.h | 11 +++
arch/arm64/kvm/hyp/pgtable.c | 15 +++
arch/arm64/kvm/mmu.c | 12
3 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_pgtable.h
b/arch/arm64/include/asm/kvm_pgtable.h
index 52ab38db04c7..2266ac45f10c 100644
--- a/arch/arm64/include/asm/kvm_pgtable.h
+++ b/arch/arm64/include/asm/kvm_pgtable.h
@@ -82,6 +82,17 @@ struct kvm_pgtable_walker {
const enum kvm_pgtable_walk_flags flags;
};
+/**
+ * kvm_supported_pgsize() - Get the max supported page size of a mapping.
+ * @pgt: Initialised page-table structure.
+ * @addr: Virtual address at which to place the mapping.
+ * @end: End virtual address of the mapping.
+ * @phys: Physical address of the memory to map.
+ *
+ * The smallest return value is PAGE_SIZE.
+ */
+u64 kvm_supported_pgsize(struct kvm_pgtable *pgt, u64 addr, u64 end, u64 phys);
+
/**
* kvm_pgtable_hyp_init() - Initialise a hypervisor stage-1 page-table.
* @pgt: Uninitialised page-table structure to initialise.
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index bdf8e55ed308..ab11609b9b13 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -81,6 +81,21 @@ static bool kvm_block_mapping_supported(u64 addr, u64 end,
u64 phys, u32 level)
return IS_ALIGNED(addr, granule) && IS_ALIGNED(phys, granule);
}
+u64 kvm_supported_pgsize(struct kvm_pgtable *pgt, u64 addr, u64 end, u64 phys)
+{
+ u32 lvl;
+ u64 pgsize = PAGE_SIZE;
+
+ for (lvl = pgt->start_level; lvl < KVM_PGTABLE_MAX_LEVELS; lvl++) {
+ if (kvm_block_mapping_supported(addr, end, phys, lvl)) {
+ pgsize = kvm_granule_size(lvl);
+ break;
+ }
+ }
+
+ return pgsize;
+}
+
static u32 kvm_pgtable_idx(struct kvm_pgtable_walk_data *data, u32 level)
{
u64 shift = kvm_granule_shift(level);
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 7d2257cc5438..80b403fc8e64 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -499,7 +499,8 @@ void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)
int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
phys_addr_t pa, unsigned long size, bool writable)
{
- phys_addr_t addr;
+ phys_addr_t addr, end;
+ unsigned long pgsize;
int ret = 0;
struct kvm_mmu_memory_cache cache = { 0, __GFP_ZERO, NULL, };
struct kvm_pgtable *pgt = kvm->arch.mmu.pgt;
@@ -509,21 +510,24 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t
guest_ipa,
size += offset_in_page(guest_ipa);
guest_ipa &= PAGE_MASK;
+ end = guest_ipa + size;
- for (addr = guest_ipa; addr < guest_ipa + size; addr += PAGE_SIZE) {
+ for (addr = guest_ipa; addr < end; addr += pgsize) {
ret = kvm_mmu_topup_memory_cache(&cache,
kvm_mmu_cache_min_pages(kvm));
if (ret)
break;
+ pgsize = kvm_supported_pgsize(pgt, addr, end, pa);
+
spin_lock(&kvm->mmu_lock);
- ret = kvm_pgtable_stage2_map(pgt, addr, PAGE_SIZE, pa, prot,
+ ret = kvm_pgtable_stage2_map(pgt, addr, pgsize, pa, prot,
&cache);
spin_unlock(&kvm->mmu_lock);
if (ret)
break;
- pa += PAGE_SIZE;
+ pa += pgsize;
}
kvm_mmu_free_memory_cache(&cache);
--
2.19.1
[PATCH v6 4/7] Bluetooth: advmon offload MSFT handle controller reset
From: Archie Pusaka
When the controller is powered off, the registered advertising monitor
is removed from the controller. This patch handles the re-registration
of those monitors when the power is on.
Signed-off-by: Archie Pusaka
Reviewed-by: Miao-chen Chou
Reviewed-by: Yun-Hao Chung
---
(no changes since v5)
Changes in v5:
* Discard struct flags on msft_data and use it's members directly
net/bluetooth/msft.c | 76 +---
1 file changed, 71 insertions(+), 5 deletions(-)
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index f5aa0e3b1b9b..d25c6936daa4 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -82,8 +82,12 @@ struct msft_data {
struct list_head handle_map;
__u16 pending_add_handle;
__u16 pending_remove_handle;
+ __u8 reregistering;
};
+static int __msft_add_monitor_pattern(struct hci_dev *hdev,
+ struct adv_monitor *monitor);
+
bool msft_monitor_supported(struct hci_dev *hdev)
{
return !!(msft_get_features(hdev) & MSFT_FEATURE_MASK_LE_ADV_MONITOR);
@@ -134,6 +138,35 @@ static bool read_supported_features(struct hci_dev *hdev,
return false;
}
+/* This function requires the caller holds hdev->lock */
+static void reregister_monitor_on_restart(struct hci_dev *hdev, int handle)
+{
+ struct adv_monitor *monitor;
+ struct msft_data *msft = hdev->msft_data;
+ int err;
+
+ while (1) {
+ monitor = idr_get_next(&hdev->adv_monitors_idr, &handle);
+ if (!monitor) {
+ /* All monitors have been reregistered */
+ msft->reregistering = false;
+ hci_update_background_scan(hdev);
+ return;
+ }
+
+ msft->pending_add_handle = (u16)handle;
+ err = __msft_add_monitor_pattern(hdev, monitor);
+
+ /* If success, we return and wait for monitor added callback */
+ if (!err)
+ return;
+
+ /* Otherwise remove the monitor and keep registering */
+ hci_free_adv_monitor(hdev, monitor);
+ handle++;
+ }
+}
+
void msft_do_open(struct hci_dev *hdev)
{
struct msft_data *msft;
@@ -154,12 +187,18 @@ void msft_do_open(struct hci_dev *hdev)
INIT_LIST_HEAD(&msft->handle_map);
hdev->msft_data = msft;
+
+ if (msft_monitor_supported(hdev)) {
+ msft->reregistering = true;
+ reregister_monitor_on_restart(hdev, 0);
+ }
}
void msft_do_close(struct hci_dev *hdev)
{
struct msft_data *msft = hdev->msft_data;
struct msft_monitor_advertisement_handle_data *handle_data, *tmp;
+ struct adv_monitor *monitor;
if (!msft)
return;
@@ -169,6 +208,12 @@ void msft_do_close(struct hci_dev *hdev)
hdev->msft_data = NULL;
list_for_each_entry_safe(handle_data, tmp, &msft->handle_map, list) {
+ monitor = idr_find(&hdev->adv_monitors_idr,
+ handle_data->mgmt_handle);
+
+ if (monitor && monitor->state == ADV_MONITOR_STATE_OFFLOADED)
+ monitor->state = ADV_MONITOR_STATE_REGISTERED;
+
list_del(&handle_data->list);
kfree(handle_data);
}
@@ -282,9 +327,15 @@ static void msft_le_monitor_advertisement_cb(struct
hci_dev *hdev,
if (status && monitor)
hci_free_adv_monitor(hdev, monitor);
+ /* If in restart/reregister sequence, keep registering. */
+ if (msft->reregistering)
+ reregister_monitor_on_restart(hdev,
+ msft->pending_add_handle + 1);
+
hci_dev_unlock(hdev);
- hci_add_adv_patterns_monitor_complete(hdev, status);
+ if (!msft->reregistering)
+ hci_add_adv_patterns_monitor_complete(hdev, status);
}
static void msft_le_cancel_monitor_advertisement_cb(struct hci_dev *hdev,
@@ -374,7 +425,8 @@ static bool msft_monitor_pattern_valid(struct adv_monitor
*monitor)
}
/* This function requires the caller holds hdev->lock */
-int msft_add_monitor_pattern(struct hci_dev *hdev, struct adv_monitor *monitor)
+static int __msft_add_monitor_pattern(struct hci_dev *hdev,
+ struct adv_monitor *monitor)
{
struct msft_cp_le_monitor_advertisement *cp;
struct msft_le_monitor_advertisement_pattern_data *pattern_data;
@@ -387,9 +439,6 @@ int msft_add_monitor_pattern(struct hci_dev *hdev, struct
adv_monitor *monitor)
u8 pattern_count = 0;
int err = 0;
- if (!msft)
- return -EOPNOTSUPP;
-
if (!msft_monitor_pattern_valid(monitor))
return -EINVAL;
@@ -434,6 +483,20 @@ int msft_add_monitor_pattern(struct hci_dev *hdev, struct
adv_monitor *monitor)
Re: [PATCH 3/3] arm64: dts: zynqmp: Wire up the DisplayPort subsystem
Hi Laurent,
On 1/22/21 8:46 AM, Laurent Pinchart wrote:
> Hi Michal,
>
> On Fri, Jan 22, 2021 at 08:19:15AM +0100, Michal Simek wrote:
>> On 1/21/21 11:37 PM, Laurent Pinchart wrote:
>>> On Thu, Jan 21, 2021 at 01:36:07PM +0100, Michal Simek wrote:
From: Laurent Pinchart
Enable the dpsub device and wire it up to the PS-GTR PHY lanes routed to
the DisplayPort connector.
Signed-off-by: Laurent Pinchart
Signed-off-by: Michal Simek
---
Wire all the boards
---
.../boot/dts/xilinx/zynqmp-zcu100-revC.dts| 31 +++
.../boot/dts/xilinx/zynqmp-zcu102-revA.dts| 10 ++
.../boot/dts/xilinx/zynqmp-zcu104-revA.dts| 11 +++
.../boot/dts/xilinx/zynqmp-zcu104-revC.dts| 11 +++
.../boot/dts/xilinx/zynqmp-zcu106-revA.dts| 11 +++
.../boot/dts/xilinx/zynqmp-zcu111-revA.dts| 11 +++
6 files changed, 85 insertions(+)
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
index 71ebcaadb7c8..a53598c3624b 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
/ {
model = "ZynqMP ZCU100 RevC";
@@ -108,6 +109,18 @@ ina226 {
compatible = "iio-hwmon";
io-channels = <&u35 0>, <&u35 1>, <&u35 2>, <&u35 3>;
};
+
+ si5335a_0: clk26 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2600>;
+ };
+
+ si5335a_1: clk27 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2700>;
+ };
>>>
>>> This is fine as a workaround for now, but I'm still wondering how we'll
>>> solve this properly. We can declare the SI5335A in DT without wiring the
>>> output that provides the clock to the PS, otherwise it will be disabled
>>> as part of the boot process.
>>
>> All these clock chips are preprogrammed to certain rate and enabled by
>> default. It means there doesn't need to be any SW handling to enable it.
>> When driver for these clock chips comes we can change this that's why I
>> used labels which are saying which output it is.
>
> Unless I'm mistaken, on the ZCU106 board, the chip is an SI5341B, which
> has a driver already. I tried to declare it in DT, but the PS_REF_CLK
> then got disabled at the end of boot, and the system wasn't happy about
> it :-)
In series before si5341 chips are enabled as the part of sata
enablement. Maybe you missed always-on parameter.
si5341_9: out@9 {
/* refclk9 used for PS_REF_CLK 33.3 MHz */
reg = <9>;
always-on;
};
I just retest it and I can't see any issue. Sata
I see DP driver probed but I can't see anything on 4k monitor but maybe
there should be something to setup (I use fs from 2015).
thanks,
Michal
[PATCH v6 5/7] Bluetooth: advmon offload MSFT handle filter enablement
From: Archie Pusaka
Implements the feature to disable/enable the filter used for
advertising monitor on MSFT controller, effectively have the same
effect as "remove all monitors" and "add all previously removed
monitors".
This feature would be needed when suspending, where we would not want
to get packets from anything outside the allowlist. Note that the
integration with the suspending part is not included in this patch.
Signed-off-by: Archie Pusaka
Reviewed-by: Miao-chen Chou
Reviewed-by: Yun-Hao Chung
---
(no changes since v1)
net/bluetooth/msft.c | 67
net/bluetooth/msft.h | 6
2 files changed, 73 insertions(+)
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index d25c6936daa4..b2ef654b1d3d 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -69,6 +69,17 @@ struct msft_rp_le_cancel_monitor_advertisement {
__u8 sub_opcode;
} __packed;
+#define MSFT_OP_LE_SET_ADVERTISEMENT_FILTER_ENABLE 0x05
+struct msft_cp_le_set_advertisement_filter_enable {
+ __u8 sub_opcode;
+ __u8 enable;
+} __packed;
+
+struct msft_rp_le_set_advertisement_filter_enable {
+ __u8 status;
+ __u8 sub_opcode;
+} __packed;
+
struct msft_monitor_advertisement_handle_data {
__u8 msft_handle;
__u16 mgmt_handle;
@@ -83,6 +94,7 @@ struct msft_data {
__u16 pending_add_handle;
__u16 pending_remove_handle;
__u8 reregistering;
+ __u8 filter_enabled;
};
static int __msft_add_monitor_pattern(struct hci_dev *hdev,
@@ -190,6 +202,7 @@ void msft_do_open(struct hci_dev *hdev)
if (msft_monitor_supported(hdev)) {
msft->reregistering = true;
+ msft_set_filter_enable(hdev, true);
reregister_monitor_on_restart(hdev, 0);
}
}
@@ -395,6 +408,40 @@ static void msft_le_cancel_monitor_advertisement_cb(struct
hci_dev *hdev,
hci_remove_adv_monitor_complete(hdev, status);
}
+static void msft_le_set_advertisement_filter_enable_cb(struct hci_dev *hdev,
+ u8 status, u16 opcode,
+ struct sk_buff *skb)
+{
+ struct msft_cp_le_set_advertisement_filter_enable *cp;
+ struct msft_rp_le_set_advertisement_filter_enable *rp;
+ struct msft_data *msft = hdev->msft_data;
+
+ rp = (struct msft_rp_le_set_advertisement_filter_enable *)skb->data;
+ if (skb->len < sizeof(*rp))
+ return;
+
+ /* Error 0x0C would be returned if the filter enabled status is
+* already set to whatever we were trying to set.
+* Although the default state should be disabled, some controller set
+* the initial value to enabled. Because there is no way to know the
+* actual initial value before sending this command, here we also treat
+* error 0x0C as success.
+*/
+ if (status != 0x00 && status != 0x0C)
+ return;
+
+ hci_dev_lock(hdev);
+
+ cp = hci_sent_cmd_data(hdev, hdev->msft_opcode);
+ msft->filter_enabled = cp->enable;
+
+ if (status == 0x0C)
+ bt_dev_warn(hdev, "MSFT filter_enable is already %s",
+ cp->enable ? "on" : "off");
+
+ hci_dev_unlock(hdev);
+}
+
static bool msft_monitor_rssi_valid(struct adv_monitor *monitor)
{
struct adv_rssi_thresholds *r = &monitor->rssi;
@@ -531,3 +578,23 @@ int msft_remove_monitor(struct hci_dev *hdev, struct
adv_monitor *monitor,
return err;
}
+
+int msft_set_filter_enable(struct hci_dev *hdev, bool enable)
+{
+ struct msft_cp_le_set_advertisement_filter_enable cp;
+ struct hci_request req;
+ struct msft_data *msft = hdev->msft_data;
+ int err;
+
+ if (!msft)
+ return -EOPNOTSUPP;
+
+ cp.sub_opcode = MSFT_OP_LE_SET_ADVERTISEMENT_FILTER_ENABLE;
+ cp.enable = enable;
+
+ hci_req_init(&req, hdev);
+ hci_req_add(&req, hdev->msft_opcode, sizeof(cp), &cp);
+ err = hci_req_run_skb(&req, msft_le_set_advertisement_filter_enable_cb);
+
+ return err;
+}
diff --git a/net/bluetooth/msft.h b/net/bluetooth/msft.h
index 6f126a1f1688..f8e4d3a6d641 100644
--- a/net/bluetooth/msft.h
+++ b/net/bluetooth/msft.h
@@ -20,6 +20,7 @@ __u64 msft_get_features(struct hci_dev *hdev);
int msft_add_monitor_pattern(struct hci_dev *hdev, struct adv_monitor
*monitor);
int msft_remove_monitor(struct hci_dev *hdev, struct adv_monitor *monitor,
u16 handle);
+int msft_set_filter_enable(struct hci_dev *hdev, bool enable);
#else
@@ -45,4 +46,9 @@ static inline int msft_remove_monitor(struct hci_dev *hdev,
return -EOPNOTSUPP;
}
+static inline int msft_set_filter_enable(struct hci_dev *hdev, bool enable)
+{
+ return -EOPNOTSUPP;
+}
+
#endif
--
2.30.0.280.ga3ce27912f-goog
[PATCH v6 6/7] Bluetooth: advmon offload MSFT interleave scanning integration
From: Archie Pusaka
When MSFT extension is supported, we don't have to interleave the scan
as we could just do allowlist scan.
Signed-off-by: Archie Pusaka
Reviewed-by: Miao-chen Chou
---
Changes in v6:
* New patch "advmon offload MSFT interleave scanning integration"
net/bluetooth/hci_request.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index 5aa7bd5030a2..d29a44d77b4e 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -404,13 +404,18 @@ static void cancel_interleave_scan(struct hci_dev *hdev)
*/
static bool __hci_update_interleaved_scan(struct hci_dev *hdev)
{
- /* If there is at least one ADV monitors and one pending LE connection
-* or one device to be scanned for, we should alternate between
-* allowlist scan and one without any filters to save power.
+ /* Do interleaved scan only if all of the following are true:
+* - There is at least one ADV monitor
+* - At least one pending LE connection or one device to be scanned for
+* - Monitor offloading is not supported
+* If so, we should alternate between allowlist scan and one without
+* any filters to save power.
*/
bool use_interleaving = hci_is_adv_monitoring(hdev) &&
!(list_empty(&hdev->pend_le_conns) &&
- list_empty(&hdev->pend_le_reports));
+ list_empty(&hdev->pend_le_reports)) &&
+ hci_get_adv_monitor_offload_ext(hdev) ==
+ HCI_ADV_MONITOR_EXT_NONE;
bool is_interleaving = is_interleave_scanning(hdev);
if (use_interleaving && !is_interleaving) {
@@ -899,14 +904,11 @@ static u8 update_white_list(struct hci_request *req)
/* Use the allowlist unless the following conditions are all true:
* - We are not currently suspending
-* - There are 1 or more ADV monitors registered
+* - There are 1 or more ADV monitors registered and it's not offloaded
* - Interleaved scanning is not currently using the allowlist
-*
-* Once the controller offloading of advertisement monitor is in place,
-* the above condition should include the support of MSFT extension
-* support.
*/
if (!idr_is_empty(&hdev->adv_monitors_idr) && !hdev->suspended &&
+ hci_get_adv_monitor_offload_ext(hdev) == HCI_ADV_MONITOR_EXT_NONE &&
hdev->interleave_scan_state != INTERLEAVE_SCAN_ALLOWLIST)
return 0x00;
--
2.30.0.280.ga3ce27912f-goog
[PATCH v6 7/7] Bluetooth: disable advertisement filters during suspend
From: Howard Chung
This adds logic to disable and reenable advertisement filters during
suspend and resume. After this patch, we would only receive packets from
devices in allow list during suspend.
Signed-off-by: Howard Chung
Reviewed-by: Abhishek Pandit-Subedi
---
Changes in v6:
* New patch "disable advertisement filters during suspend"
include/net/bluetooth/hci_core.h | 2 ++
net/bluetooth/hci_request.c | 29 +
net/bluetooth/msft.c | 17 -
net/bluetooth/msft.h | 3 +++
4 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 29cfc6a2d689..fd1d10fe2f11 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -105,6 +105,8 @@ enum suspend_tasks {
SUSPEND_POWERING_DOWN,
SUSPEND_PREPARE_NOTIFIER,
+
+ SUSPEND_SET_ADV_FILTER,
__SUSPEND_NUM_TASKS
};
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index d29a44d77b4e..e55976db4403 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -29,6 +29,7 @@
#include "smp.h"
#include "hci_request.h"
+#include "msft.h"
#define HCI_REQ_DONE 0
#define HCI_REQ_PEND 1
@@ -1242,6 +1243,29 @@ static void suspend_req_complete(struct hci_dev *hdev,
u8 status, u16 opcode)
clear_bit(SUSPEND_SCAN_DISABLE, hdev->suspend_tasks);
wake_up(&hdev->suspend_wait_q);
}
+
+ if (test_bit(SUSPEND_SET_ADV_FILTER, hdev->suspend_tasks)) {
+ clear_bit(SUSPEND_SET_ADV_FILTER, hdev->suspend_tasks);
+ wake_up(&hdev->suspend_wait_q);
+ }
+}
+
+static void hci_req_add_set_adv_filter_enable(struct hci_request *req,
+ bool enable)
+{
+ struct hci_dev *hdev = req->hdev;
+
+ switch (hci_get_adv_monitor_offload_ext(hdev)) {
+ case HCI_ADV_MONITOR_EXT_MSFT:
+ msft_req_add_set_filter_enable(req, enable);
+ break;
+ default:
+ return;
+ }
+
+ /* No need to block when enabling since it's on resume path */
+ if (hdev->suspended && !enable)
+ set_bit(SUSPEND_SET_ADV_FILTER, hdev->suspend_tasks);
}
/* Call with hci_dev_lock */
@@ -1301,6 +1325,9 @@ void hci_req_prepare_suspend(struct hci_dev *hdev, enum
suspended_state next)
hci_req_add_le_scan_disable(&req, false);
}
+ /* Disable advertisement filters */
+ hci_req_add_set_adv_filter_enable(&req, false);
+
/* Mark task needing completion */
set_bit(SUSPEND_SCAN_DISABLE, hdev->suspend_tasks);
@@ -1340,6 +1367,8 @@ void hci_req_prepare_suspend(struct hci_dev *hdev, enum
suspended_state next)
hci_req_clear_event_filter(&req);
/* Reset passive/background scanning to normal */
__hci_update_background_scan(&req);
+ /* Enable all of the advertisement filters */
+ hci_req_add_set_adv_filter_enable(&req, true);
/* Unpause directed advertising */
hdev->advertising_paused = false;
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index b2ef654b1d3d..47b104f318e9 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -579,9 +579,19 @@ int msft_remove_monitor(struct hci_dev *hdev, struct
adv_monitor *monitor,
return err;
}
-int msft_set_filter_enable(struct hci_dev *hdev, bool enable)
+void msft_req_add_set_filter_enable(struct hci_request *req, bool enable)
{
+ struct hci_dev *hdev = req->hdev;
struct msft_cp_le_set_advertisement_filter_enable cp;
+
+ cp.sub_opcode = MSFT_OP_LE_SET_ADVERTISEMENT_FILTER_ENABLE;
+ cp.enable = enable;
+
+ hci_req_add(req, hdev->msft_opcode, sizeof(cp), &cp);
+}
+
+int msft_set_filter_enable(struct hci_dev *hdev, bool enable)
+{
struct hci_request req;
struct msft_data *msft = hdev->msft_data;
int err;
@@ -589,11 +599,8 @@ int msft_set_filter_enable(struct hci_dev *hdev, bool
enable)
if (!msft)
return -EOPNOTSUPP;
- cp.sub_opcode = MSFT_OP_LE_SET_ADVERTISEMENT_FILTER_ENABLE;
- cp.enable = enable;
-
hci_req_init(&req, hdev);
- hci_req_add(&req, hdev->msft_opcode, sizeof(cp), &cp);
+ msft_req_add_set_filter_enable(&req, enable);
err = hci_req_run_skb(&req, msft_le_set_advertisement_filter_enable_cb);
return err;
diff --git a/net/bluetooth/msft.h b/net/bluetooth/msft.h
index f8e4d3a6d641..88ed613dfa08 100644
--- a/net/bluetooth/msft.h
+++ b/net/bluetooth/msft.h
@@ -20,6 +20,7 @@ __u64 msft_get_features(struct hci_dev *hdev);
int msft_add_monitor_pattern(struct hci_dev *hdev, struct adv_monitor
*monitor);
int msft_remove_monitor(struct hci_dev *hdev, struct adv_monitor
Re: [PATCH 1/5] Add manpage for open_tree(2)
Hello David,
Ping!
Thanks,
Michael
On Thu, 27 Aug 2020 at 13:01, Michael Kerrisk (man-pages)
wrote:
>
> Hello David,
>
> Can I ask that you please reply to each of my mails, rather than
> just sending out a new patch series (which of course I would also
> like you to do). Some things that I mentioned in the last mails
> got lost, and I end up having to repeat them.
>
> So, even where I say "please change this", could you please reply with
> "done", or a reason why you declined the suggested change, is useful.
> But in any case, a few words in reply to explain the other changes
> that you make would be helpful.
>
> Also, some of my questions now will get a little more complex, and as
> well as you updating the pages, I think a little discussion may be
> required in some cases.
>
> On 8/24/20 2:24 PM, David Howells wrote:
> > Add a manual page to document the open_tree() system call.
> >
> > Signed-off-by: David Howells
> > ---
> >
> > man2/open_tree.2 | 249
> > ++
> > 1 file changed, 249 insertions(+)
> > create mode 100644 man2/open_tree.2
> >
> > diff --git a/man2/open_tree.2 b/man2/open_tree.2
> > new file mode 100644
> > index 0..d480bd82f
> > --- /dev/null
> > +++ b/man2/open_tree.2
> > @@ -0,0 +1,249 @@
> > +'\" t
> > +.\" Copyright (c) 2020 David Howells
> > +.\"
> > +.\" %%%LICENSE_START(VERBATIM)
> > +.\" Permission is granted to make and distribute verbatim copies of this
> > +.\" manual provided the copyright notice and this permission notice are
> > +.\" preserved on all copies.
> > +.\"
> > +.\" Permission is granted to copy and distribute modified versions of this
> > +.\" manual under the conditions for verbatim copying, provided that the
> > +.\" entire resulting derived work is distributed under the terms of a
> > +.\" permission notice identical to this one.
> > +.\"
> > +.\" Since the Linux kernel and libraries are constantly changing, this
> > +.\" manual page may be incorrect or out-of-date. The author(s) assume no
> > +.\" responsibility for errors or omissions, or for damages resulting from
> > +.\" the use of the information contained herein. The author(s) may not
> > +.\" have taken the same level of care in the production of this manual,
> > +.\" which is licensed free of charge, as they might when working
> > +.\" professionally.
> > +.\"
> > +.\" Formatted or processed versions of this manual, if unaccompanied by
> > +.\" the source, must acknowledge the copyright and authors of this work.
> > +.\" %%%LICENSE_END
> > +.\"
> > +.TH OPEN_TREE 2 2020-08-24 "Linux" "Linux Programmer's Manual"
> > +.SH NAME
> > +open_tree \- Pick or clone mount object and attach to fd
> > +.SH SYNOPSIS
> > +.nf
> > +.B #include
> > +.B #include
> > +.B #include
> > +.BR "#include" "/* Definition of AT_* constants */"
> > +.PP
> > +.BI "int open_tree(int " dirfd ", const char *" pathname ", unsigned int "
> > flags );
> > +.fi
> > +.PP
> > +.IR Note :
> > +There are no glibc wrappers for these system calls.
> > +.SH DESCRIPTION
> > +.BR open_tree ()
> > +picks the mount object specified by the pathname and attaches it to a new
> > file
>
> The terminology "pick" is unusual, and you never really explain what
> it means. Is there better terminology? In any case, can you add a few
> words to explain what the term (('pick" or whatever alternative you
> come up with) means.
>
> > +descriptor or clones it and attaches the clone to the file descriptor. The
>
> Please replace "it" by a noun (phrase) -- maybe: "the mount object"?
>
> > +resultant file descriptor is indistinguishable from one produced by
> > +.BR open "(2) with " O_PATH .
>
> What is the significance of that last piece? Can you add some words
> about why the fact that the resulting FD is indistinguishable from one
> produced by open() O_PATH matters or is useful?
>
> > +.PP
> > +In the case that the mount object is cloned, the clone will be "unmounted"
> > and
>
> You place "unmounted" in quotes. Why? Is this to signify that the the
> unmount is somehow different from other unmounts? If so, please
> explain how it is different. If not, then I think we can lose the double
> quotes.
>
> > +destroyed when the file descriptor is closed if it is not otherwise mounted
> > +somewhere by calling
> > +.BR move_mount (2).
> > +.PP
> > +To select a mount object, no permissions are required on the object
> > referred
>
> Here you use the word "select". Is this the same as "pick"? If yes, please
> use the same term.
>
> > +to by the path, but execute (search) permission is required on all of the
>
> s/the path/.I pathname/ ?
>
> (Where pathname == "the pathname argument)
>
> > +directories in
> > +.I pathname
> > +that lead to the object.
> > +.PP
> > +Appropriate privilege (Linux: the
>
> s/Linux: //
> (This is a Linux specific system call...)
>
> > +.B CAP_SYS_ADMIN
> > +capability) is required to clone mount objects.
> > +.PP
> > +.BR open_tree ()
> > +uses
>
Re: [PATCH 2/5] Add manpages for move_mount(2)
Hello David,
Ping!
Thanks,
Michael
On Mon, 24 Aug 2020 at 14:24, David Howells wrote:
>
> Add manual pages to document the move_mount() system call.
>
> Signed-off-by: David Howells
> ---
>
> man2/move_mount.2 | 267
> +
> 1 file changed, 267 insertions(+)
> create mode 100644 man2/move_mount.2
>
> diff --git a/man2/move_mount.2 b/man2/move_mount.2
> new file mode 100644
> index 0..2ceb775d9
> --- /dev/null
> +++ b/man2/move_mount.2
> @@ -0,0 +1,267 @@
> +'\" t
> +.\" Copyright (c) 2020 David Howells
> +.\"
> +.\" %%%LICENSE_START(VERBATIM)
> +.\" Permission is granted to make and distribute verbatim copies of this
> +.\" manual provided the copyright notice and this permission notice are
> +.\" preserved on all copies.
> +.\"
> +.\" Permission is granted to copy and distribute modified versions of this
> +.\" manual under the conditions for verbatim copying, provided that the
> +.\" entire resulting derived work is distributed under the terms of a
> +.\" permission notice identical to this one.
> +.\"
> +.\" Since the Linux kernel and libraries are constantly changing, this
> +.\" manual page may be incorrect or out-of-date. The author(s) assume no
> +.\" responsibility for errors or omissions, or for damages resulting from
> +.\" the use of the information contained herein. The author(s) may not
> +.\" have taken the same level of care in the production of this manual,
> +.\" which is licensed free of charge, as they might when working
> +.\" professionally.
> +.\"
> +.\" Formatted or processed versions of this manual, if unaccompanied by
> +.\" the source, must acknowledge the copyright and authors of this work.
> +.\" %%%LICENSE_END
> +.\"
> +.TH MOVE_MOUNT 2 2020-08-24 "Linux" "Linux Programmer's Manual"
> +.SH NAME
> +move_mount \- Move mount objects around the filesystem topology
> +.SH SYNOPSIS
> +.nf
> +.B #include
> +.B #include
> +.B #include
> +.BR "#include" "/* Definition of AT_* constants */"
> +.PP
> +.BI "int move_mount(int " from_dirfd ", const char *" from_pathname ","
> +.BI " int " to_dirfd ", const char *" to_pathname ","
> +.BI " unsigned int " flags );
> +.fi
> +.PP
> +.IR Note :
> +There is no glibc wrapper for this system call.
> +.SH DESCRIPTION
> +The
> +.BR move_mount ()
> +call moves a mount from one place to another; it can also be used to attach
> an
> +unattached mount that was created by
> +.BR fsmount "() or " open_tree "() with " OPEN_TREE_CLONE .
> +.PP
> +If
> +.BR move_mount ()
> +is called repeatedly with a file descriptor that refers to a mount object,
> +then the object will be attached/moved the first time and then moved
> +repeatedly, detaching it from the previous mountpoint each time.
> +.PP
> +To access the source mount object or the destination mountpoint, no
> +permissions are required on the object itself, but if either pathname is
> +supplied, execute (search) permission is required on all of the directories
> +specified in
> +.IR from_pathname " or " to_pathname .
> +.PP
> +The caller does, however, require the appropriate privilege (Linux: the
> +.B CAP_SYS_ADMIN
> +capability) to move or attach mounts.
> +.PP
> +.BR move_mount ()
> +uses
> +.IR from_pathname ", " from_dirfd " and part of " flags
> +to locate the mount object to be moved and
> +.IR to_pathname ", " to_dirfd " and another part of " flags
> +to locate the destination mountpoint. Each lookup can be done in one of a
> +variety of ways:
> +.TP
> +[*] By absolute path.
> +The pathname points to an absolute path and the dirfd is ignored. The file
> is
> +looked up by name, starting from the root of the filesystem as seen by the
> +calling process.
> +.TP
> +[*] By cwd-relative path.
> +The pathname points to a relative path and the dirfd is
> +.IR AT_FDCWD .
> +The file is looked up by name, starting from the current working directory.
> +.TP
> +[*] By dir-relative path.
> +The pathname points to relative path and the dirfd indicates a file
> descriptor
> +pointing to a directory. The file is looked up by name, starting from the
> +directory specified by
> +.IR dirfd .
> +.TP
> +[*] By file descriptor. The pathname is an empty string (""), the dirfd
> +points directly to the mount object to move or the destination mount point
> and
> +the appropriate
> +.B *_EMPTY_PATH
> +flag is set.
> +.PP
> +.I flags
> +can be used to influence a path-based lookup. The value for
> +.I flags
> +is constructed by OR'ing together zero or more of the following constants:
> +.TP
> +.BR MOVE_MOUNT_F_EMPTY_PATH
> +.\" commit 65cfc6722361570bfe255698d9cd4dccaf47570d
> +If
> +.I from_pathname
> +is an empty string, operate on the file referred to by
> +.IR from_dirfd
> +(which may have been obtained using the
> +.BR open (2)
> +.B O_PATH
> +flag or
> +.BR open_tree ())
> +If
> +.I from_dirfd
> +is
> +.BR AT_FDCWD ,
> +the call operates on the current working directory.
> +In this case,
> +.I f
Re: linux-next: build warning after merge of the drm tree
On Fri, Jan 22, 2021 at 8:29 AM Stephen Rothwell wrote: > > Hi Daniel, > > On Fri, 22 Jan 2021 08:17:58 +0100 Daniel Vetter wrote: > > > > Hm that has been in drm-intel-gt-next for a few days, is that tree not > > in linux-next? > > It is not. Adding -intel maintainers to get that sorted. -Daniel > These are the drm branches currently in linux-next: Oh for ordering maybe put drm-misc ahead of the other subtrees, -misc is where nowadays a lot of refactorings and core changes land. Probably doesn't matter in practice. -Daniel > drm-fixes git://git.freedesktop.org/git/drm/drm.git drm-fixes > amdgpu-fixesgit://people.freedesktop.org/~agd5f/linux drm-fixes > drm-intel-fixes git://anongit.freedesktop.org/drm-intel > for-linux-next-fixes > drm-misc-fixes git://anongit.freedesktop.org/drm/drm-misc > for-linux-next-fixes > drm git://git.freedesktop.org/git/drm/drm.git drm-next > amdgpu https://gitlab.freedesktop.org/agd5f/linux drm-next > drm-intel git://anongit.freedesktop.org/drm-intel for-linux-next > drm-tegra git://anongit.freedesktop.org/tegra/linux.git > drm/tegra/for-next > drm-miscgit://anongit.freedesktop.org/drm/drm-misc for-linux-next > drm-msm https://gitlab.freedesktop.org/drm/msm.git msm-next > imx-drm https://git.pengutronix.de/git/pza/linuximx-drm/next > etnaviv https://git.pengutronix.de/git/lst/linuxetnaviv/next > > -- > Cheers, > Stephen Rothwell -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH] scsi_logging: print cdb into new line after opcode
The current log message results in a line like the following where
the first byte is duplicated, giving a wrong impression:
sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 60 40 00 00 01 00
Print the cdb into a new line in any case, not only when cmd_len is
greater than 16. The above example error will then read:
sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28
28 00 01 c0 09 00 00 00 08 00
Signed-off-by: Martin Kepplinger
---
drivers/scsi/scsi_logging.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/scsi_logging.c b/drivers/scsi/scsi_logging.c
index 8ea44c6595ef..0081d3936f83 100644
--- a/drivers/scsi/scsi_logging.c
+++ b/drivers/scsi/scsi_logging.c
@@ -200,10 +200,11 @@ void scsi_print_command(struct scsi_cmnd *cmd)
if (off >= logbuf_len)
goto out_printk;
+ /* Print opcode in one line and use separate lines for CDB */
+ off += scnprintf(logbuf + off, logbuf_len - off, "\n");
+
/* print out all bytes in cdb */
if (cmd->cmd_len > 16) {
- /* Print opcode in one line and use separate lines for CDB */
- off += scnprintf(logbuf + off, logbuf_len - off, "\n");
dev_printk(KERN_INFO, &cmd->device->sdev_gendev, "%s", logbuf);
for (k = 0; k < cmd->cmd_len; k += 16) {
size_t linelen = min(cmd->cmd_len - k, 16);
@@ -224,7 +225,6 @@ void scsi_print_command(struct scsi_cmnd *cmd)
goto out;
}
if (!WARN_ON(off > logbuf_len - 49)) {
- off += scnprintf(logbuf + off, logbuf_len - off, " ");
hex_dump_to_buffer(cmd->cmnd, cmd->cmd_len, 16, 1,
logbuf + off, logbuf_len - off,
false);
--
2.20.1
Re: [PATCH 4/5] Add manpage for fsopen(2) and fsmount(2)
Hello David, Ping! Thanks, Michael On Fri, 16 Oct 2020 at 08:50, Michael Kerrisk (man-pages) wrote: > > Hi David, > > Another ping for these five patches please! > > Cheers, > > Michael > > On Fri, 11 Sep 2020 at 14:44, Michael Kerrisk (man-pages) > wrote: > > > > Hi David, > > > > A ping for these five patches please! > > > > Cheers, > > > > Michael > > > > On Wed, 2 Sep 2020 at 22:14, Michael Kerrisk (man-pages) > > wrote: > > > > > > On Wed, 2 Sep 2020 at 18:14, David Howells wrote: > > > > > > > > Michael Kerrisk (man-pages) wrote: > > > > > > > > > The term "filesystem configuration context" is introduced, but never > > > > > really explained. I think it would be very helpful to have a sentence > > > > > or three that explains this concept at the start of the page. > > > > > > > > Does that need a .7 manpage? > > > > > > I was hoping a sentence or a paragraph in this page might suffice. Do > > > you think more is required? > > > > > > Cheers, > > > > > > Michael > > > > > > -- > > > Michael Kerrisk > > > Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ > > > Linux/UNIX System Programming Training: http://man7.org/training/ > > > > > > > > -- > > Michael Kerrisk > > Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ > > Linux/UNIX System Programming Training: http://man7.org/training/ > > > > -- > Michael Kerrisk > Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ > Linux/UNIX System Programming Training: http://man7.org/training/ -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
Re: [PATCH v4 2/4] mm: simplify parater of function memmap_init_zone()
On 20.01.21 05:52, Baoquan He wrote:
> As David suggested, simply passing 'struct zone *zone' is enough. We can
> get all needed information from 'struct zone*' easily.
>
> Suggested-by: David Hildenbrand
> Signed-off-by: Baoquan He
> ---
> arch/ia64/include/asm/pgtable.h | 3 +--
> arch/ia64/mm/init.c | 12 +++-
> mm/page_alloc.c | 24 +++-
> 3 files changed, 19 insertions(+), 20 deletions(-)
>
> diff --git a/arch/ia64/include/asm/pgtable.h b/arch/ia64/include/asm/pgtable.h
> index dce2ff37df65..2c81394a2430 100644
> --- a/arch/ia64/include/asm/pgtable.h
> +++ b/arch/ia64/include/asm/pgtable.h
> @@ -520,8 +520,7 @@ extern struct page *zero_page_memmap_ptr;
>
> # ifdef CONFIG_VIRTUAL_MEM_MAP
>/* arch mem_map init routine is needed due to holes in a virtual mem_map */
> -extern void memmap_init_zone(unsigned long size, int nid, unsigned long
> zone,
> - unsigned long start_pfn);
> +extern void memmap_init_zone(struct zone *zone);
> # endif /* CONFIG_VIRTUAL_MEM_MAP */
> # endif /* !__ASSEMBLY__ */
>
> diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
> index c8e68e92beb3..88fb44895408 100644
> --- a/arch/ia64/mm/init.c
> +++ b/arch/ia64/mm/init.c
> @@ -541,12 +541,14 @@ virtual_memmap_init(u64 start, u64 end, void *arg)
> return 0;
> }
>
> -void __meminit
> -memmap_init_zone(unsigned long size, int nid, unsigned long zone,
> - unsigned long start_pfn)
> +void __meminit memmap_init_zone(struct zone *zone)
> {
> + int nid = zone_to_nid(zone), zone_id = zone_idx(zone);
> + unsigned long start_pfn = zone->zone_start_pfn;
> + unsigned long size = zone->spanned_pages;
> +
> if (!vmem_map) {
> - memmap_init_range(size, nid, zone, start_pfn, start_pfn + size,
> + memmap_init_range(size, nid, zone_id, start_pfn, start_pfn +
> size,
>MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
> } else {
> struct page *start;
> @@ -556,7 +558,7 @@ memmap_init_zone(unsigned long size, int nid, unsigned
> long zone,
> args.start = start;
> args.end = start + size;
> args.nid = nid;
> - args.zone = zone;
> + args.zone = zone_id;
>
> efi_memmap_walk(virtual_memmap_init, &args);
> }
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 42a1d2d2a87d..cbb67d9c1b2a 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6254,23 +6254,21 @@ static void __meminit zone_init_free_lists(struct
> zone *zone)
> }
> }
>
> -void __meminit __weak memmap_init_zone(unsigned long size, int nid,
> - unsigned long zone,
> - unsigned long range_start_pfn)
> +void __meminit __weak memmap_init_zone(struct zone *zone)
> {
> + unsigned long zone_start_pfn = zone->zone_start_pfn;
> + unsigned long zone_end_pfn = zone_start_pfn + zone->spanned_pages;
> + int i, nid = zone_to_nid(zone), zone_id = zone_idx(zone);
> unsigned long start_pfn, end_pfn;
> - unsigned long range_end_pfn = range_start_pfn + size;
> - int i;
>
> for_each_mem_pfn_range(i, nid, &start_pfn, &end_pfn, NULL) {
> - start_pfn = clamp(start_pfn, range_start_pfn, range_end_pfn);
> - end_pfn = clamp(end_pfn, range_start_pfn, range_end_pfn);
> + start_pfn = clamp(start_pfn, zone_start_pfn, zone_end_pfn);
> + end_pfn = clamp(end_pfn, zone_start_pfn, zone_end_pfn);
>
> - if (end_pfn > start_pfn) {
> - size = end_pfn - start_pfn;
> - memmap_init_range(size, nid, zone, start_pfn,
> range_end_pfn,
> - MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
> - }
> + if (end_pfn > start_pfn)
> + memmap_init_range(end_pfn - start_pfn, nid,
> + zone_id, start_pfn, zone_end_pfn,
> + MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
> }
> }
>
> @@ -6978,7 +6976,7 @@ static void __init free_area_init_core(struct
> pglist_data *pgdat)
> set_pageblock_order();
> setup_usemap(pgdat, zone, zone_start_pfn, size);
> init_currently_empty_zone(zone, zone_start_pfn, size);
> - memmap_init_zone(size, nid, j, zone_start_pfn);
> + memmap_init_zone(zone);
> }
> }
>
>
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
RE: [PATCH v2 1/3] perf vendor events: Add cache refill and DCZVA events
Hi, John, Shaokun
> > 在 2021/1/21 18:54, Shunsuke Nakamura 写道:
> >> Adds L1 data cache refill prefetch, L2 data cache refill prefetch,
> >> and DCZVA instruction events.
> >
> > A silly question, Does Arm define these events? I checked Arm ARM
> > document(DDI0487Fc) that these event numbers are reserved. Or maybe I
> > miss something.
>
> For events which are reserved (see k3-1), like 0x9f, prob should not be
> putting in
> this file, but rather the CPU JSON.
I missed the reservation area for ARM recommended events.
I will fix the patch as you pointed out.
Best Regards
> -Original Message-
> From: John Garry
> Sent: Friday, January 22, 2021 2:44 AM
> To: Shaokun Zhang ; Nakamura, Shunsuke/中村
> 俊介
> Cc: mathieu.poir...@linaro.org; linux-kernel@vger.kernel.org;
> leo@linaro.org; w...@kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v2 1/3] perf vendor events: Add cache refill and DCZVA
> events
>
> On 21/01/2021 11:39, Shaokun Zhang wrote:
> > Hi,
> >
> > 在 2021/1/21 18:54, Shunsuke Nakamura 写道:
> >> Adds L1 data cache refill prefetch, L2 data cache refill prefetch,
> >> and DCZVA instruction events.
> >
> > A silly question, Does Arm define these events? I checked Arm ARM
> > document(DDI0487Fc) that these event numbers are reserved. Or maybe I
> > miss something.
>
> For events which are reserved (see k3-1), like 0x9f, prob should not be
> putting in
> this file, but rather the CPU JSON.
>
> Cheers,
> John
>
> >
> >>
> >> Signed-off-by: Shunsuke Nakamura
> >> ---
> >> .../perf/pmu-events/arch/arm64/armv8-recommended.json | 18
> ++
> >> 1 file changed, 18 insertions(+)
> >>
> >> diff --git a/tools/perf/pmu-events/arch/arm64/armv8-recommended.json
> >> b/tools/perf/pmu-events/arch/arm64/armv8-recommended.json
> >> index d0a1986..ee0e67d 100644
> >> --- a/tools/perf/pmu-events/arch/arm64/armv8-recommended.json
> >> +++ b/tools/perf/pmu-events/arch/arm64/armv8-recommended.json
> >> @@ -54,6 +54,12 @@
> >> "BriefDescription": "L1D cache invalidate"
> >> },
> >> {
> >> +"PublicDescription": "This event counts L1D_CACHE_REFILL
> caused by software or hardware prefetch.",
> >> +"EventCode": "0x49",
> >> +"EventName": "L1D_CACHE_REFILL_PRF",
> >> +"BriefDescription": "This event counts L1D_CACHE_REFILL caused
> by software or hardware prefetch."
> >> +},
> >> +{
> >> "PublicDescription": "Attributable Level 1 data TLB refill,
> >> read",
> >> "EventCode": "0x4C",
> >> "EventName": "L1D_TLB_REFILL_RD", @@ -120,6 +126,12 @@
> >> "BriefDescription": "L2D cache invalidate"
> >> },
> >> {
> >> +"PublicDescription": "This event counts L2D_CACHE_REFILL
> caused by software or hardware prefetch.",
> >> +"EventCode": "0x59",
> >> +"EventName": "L2D_CACHE_REFILL_PRF",
> >> +"BriefDescription": "This event counts L2D_CACHE_REFILL caused
> by software or hardware prefetch."
> >> +},
> >> +{
> >> "PublicDescription": "Attributable Level 2 data or unified TLB
> >> refill,
> read",
> >> "EventCode": "0x5c",
> >> "EventName": "L2D_TLB_REFILL_RD", @@ -408,6 +420,12 @@
> >> "BriefDescription": "Release consistency operation speculatively
> executed, Store-Release"
> >> },
> >> {
> >> + "PublicDescription": "This event counts architecturally executed
> zero blocking operations due to the 'DC ZVA' instruction.",
> >> + "EventCode": "0x9f",
> >> + "EventName": "DCZVA_SPEC",
> >> + "BriefDescription": "This event counts architecturally executed
> zero blocking operations due to the 'DC ZVA' instruction."
> >> + },
> >> + {
> >> "PublicDescription": "Attributable Level 3 data or unified cache
> access, read",
> >> "EventCode": "0xa0",
> >> "EventName": "L3D_CACHE_RD",
> >>
> > .
> >
Re: bisected regression in v5.11-rc1 snd-usb-audio
On Fri, 22 Jan 2021 09:09:08 +0100,
Jamie Heilman wrote:
>
> I've bisected a failure in support for the M2Tech USB HiFace Two
> 192kHz Digital Audio Interface device (read as: a reclocked USB
> S/PDIF) to the following ...
>
> commit 93db51d06b32227319dae2ac289029ccf1b33181
> Author: Takashi Iwai
> Date: Mon Nov 23 09:53:09 2020 +0100
>
> ALSA: usb-audio: Check valid altsetting at parsing rates for UAC2/3
>
> This has always been a somewhat finicky device, but my life is a
> silent void without it, as it is currently a vital part of getting
> audio to my mixer (now, if I could get USB Audio on my Rane MP2015
> actually working right I'd very happily take that approach instead[1],
> but I digress). It has been known to require replugging to initialize
> properly at times, but until now, it's always worked fine eventually.
>
> I've attached the dmesg from a working 5.10.9 kernel, the alsa-info
> output, and the lsusb -vvv output for this device when it's
> functioning. (Note, that alsa-info claims jack isn't running...
> that's not actually true though, maybe because I'm using jack 2's
> jackdbus subsystem, but jack is infact running, though it's probably
> not relevant to the issue at hand[2].)
>
> When I boot 93db51d06b32 or later I get lot of errors in the dmesg
> like:
>
> usb 1-1.1.2: New USB device found, idVendor=249c, idProduct=930b, bcdDevice=
> 2.13
> usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 1-1.1.2: Product: M2Tech USB Audio 2.0
> usb 1-1.1.2: Manufacturer: M2Tech
> usb 1-1.1.2: SerialNumber:
> usb 1-1.1.2: cannot get ctl value: req = 0x83, wValue = 0x201, wIndex =
> 0xa00, type = 4
> usb 1-1.1.2: 10:0: cannot get min/max values for control 2 (id 10)
> usb 1-1.1.2: cannot get ctl value: req = 0x83, wValue = 0x200, wIndex =
> 0xa00, type = 4
> usb 1-1.1.2: 10:0: cannot get min/max values for control 2 (id 10)
> usbcore: registered new interface driver snd-usb-audio
> usb 1-1.1-port2: disabled by hub (EMI?), re-enabling...
> usb 1-1.1.2: USB disconnect, device number 6
> usb 1-1.1.2: new full-speed USB device number 7 using ehci-pci
> usb 1-1.1.2: device descriptor read/64, error -32
> usb 1-1.1.2: device descriptor read/64, error -32
> usb 1-1.1.2: new full-speed USB device number 8 using ehci-pci
> usb 1-1.1.2: device descriptor read/64, error -32
> usb 1-1.1.2: device descriptor read/64, error -32
> usb 1-1.1-port2: attempt power cycle
> usb 1-1.1.2: new full-speed USB device number 9 using ehci-pci
> usb 1-1.1.2: device not accepting address 9, error -32
> usb 1-1.1.2: new full-speed USB device number 10 using ehci-pci
> usb 1-1.1.2: device not accepting address 10, error -32
> usb 1-1.1-port2: unable to enumerate USB device
>
> and obviously the device doesn't work at all. Sometimes there's more
> "cannot get ctl value:" noise than other times, but the above is a
> clean boot after being in a working state (it tends to require
> replugging to get back to a being usable again after this, once I've
> booted a working kernel, possibly becuase its hanging off a hub in my
> monitor, not the most elegant of setups, I know---but none of this
> changes even if I plug it directly into my workstation's USB ports, I
> tried that).
>
> I'm happy to try any patches, or provide more details, just ask.
You seem hitting a firmware bug, and it doesn't look like the only
case. Interestingly, the backport of 5.11 USB-audio stuff on 5.3
kernel on openSUSE Leap 15.2 caused a similar bug on Steinberg device,
while it worked with 5.11-rc. So I thought this specific with the
older kernel (in USB core changes or such), but my guess seems wrong,
and the bug looks remaining in 5.11 for some cases.
Below is the fix patch. Please give it a try.
thanks,
Takashi
-- 8< --
From: Takashi Iwai
Subject: [PATCH] ALSA: usb-audio: workaround for iface reset issue
The recently introduced sample rate validation code seems causing a
problem on some devices; namely, after performing this, the bus gets
screwed and it influences even on other USB devices.
As a quick workaround, perform it only for the necessary devices;
currently MOTU devices are known to need the valid altset checks, so
filter out other devices.
Fixes: 93db51d06b32 ("ALSA: usb-audio: Check valid altsetting at parsing rates
for UAC2/3")
Reported-by: Jamie Heilman
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1178203
Signed-off-by: Takashi Iwai
---
sound/usb/format.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/sound/usb/format.c b/sound/usb/format.c
index 9ebc5d202c87..e6ff317a6785 100644
--- a/sound/usb/format.c
+++ b/sound/usb/format.c
@@ -466,6 +466,17 @@ static int validate_sample_rate_table_v2v3(struct
snd_usb_audio *chip,
unsigned int nr_rates;
int i, err;
+ /* performing the rate verification may lead to unexpected USB bus
+* behavior afterwards by some unknown reason. Do this only for the
+* know
Re: [PATCH v4 1/4] mm: rename memmap_init() and memmap_init_zone()
On 20.01.21 05:52, Baoquan He wrote:
> The current memmap_init_zone() only handles memory region inside one zone,
> actually memmap_init() does the memmap init of one zone. So rename both of
> them accordingly.
>
> Signed-off-by: Baoquan He
> ---
> arch/ia64/include/asm/pgtable.h | 2 +-
> arch/ia64/mm/init.c | 6 +++---
> include/linux/mm.h | 2 +-
> mm/memory_hotplug.c | 2 +-
> mm/page_alloc.c | 8
> 5 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/ia64/include/asm/pgtable.h b/arch/ia64/include/asm/pgtable.h
> index 779b6972aa84..dce2ff37df65 100644
> --- a/arch/ia64/include/asm/pgtable.h
> +++ b/arch/ia64/include/asm/pgtable.h
> @@ -520,7 +520,7 @@ extern struct page *zero_page_memmap_ptr;
>
> # ifdef CONFIG_VIRTUAL_MEM_MAP
>/* arch mem_map init routine is needed due to holes in a virtual mem_map */
> -extern void memmap_init (unsigned long size, int nid, unsigned long zone,
> +extern void memmap_init_zone(unsigned long size, int nid, unsigned long
> zone,
>unsigned long start_pfn);
> # endif /* CONFIG_VIRTUAL_MEM_MAP */
> # endif /* !__ASSEMBLY__ */
> diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
> index e76386a3479e..c8e68e92beb3 100644
> --- a/arch/ia64/mm/init.c
> +++ b/arch/ia64/mm/init.c
> @@ -535,18 +535,18 @@ virtual_memmap_init(u64 start, u64 end, void *arg)
> / sizeof(struct page));
>
> if (map_start < map_end)
> - memmap_init_zone((unsigned long)(map_end - map_start),
> + memmap_init_range((unsigned long)(map_end - map_start),
>args->nid, args->zone, page_to_pfn(map_start),
> page_to_pfn(map_end),
>MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
> return 0;
> }
>
> void __meminit
> -memmap_init (unsigned long size, int nid, unsigned long zone,
> +memmap_init_zone(unsigned long size, int nid, unsigned long zone,
>unsigned long start_pfn)
> {
> if (!vmem_map) {
> - memmap_init_zone(size, nid, zone, start_pfn, start_pfn + size,
> + memmap_init_range(size, nid, zone, start_pfn, start_pfn + size,
>MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
> } else {
> struct page *start;
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 3dac7bc667ee..56bb239f9150 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2398,7 +2398,7 @@ extern int __meminit early_pfn_to_nid(unsigned long
> pfn);
> #endif
>
> extern void set_dma_reserve(unsigned long new_dma_reserve);
> -extern void memmap_init_zone(unsigned long, int, unsigned long,
> +extern void memmap_init_range(unsigned long, int, unsigned long,
> unsigned long, unsigned long, enum meminit_context,
> struct vmem_altmap *, int migratetype);
> extern void setup_per_zone_wmarks(void);
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index f9d57b9be8c7..ddcb1cd24c60 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -713,7 +713,7 @@ void __ref move_pfn_range_to_zone(struct zone *zone,
> unsigned long start_pfn,
>* expects the zone spans the pfn range. All the pages in the range
>* are reserved so nobody should be touching them so we should be safe
>*/
> - memmap_init_zone(nr_pages, nid, zone_idx(zone), start_pfn, 0,
> + memmap_init_range(nr_pages, nid, zone_idx(zone), start_pfn, 0,
>MEMINIT_HOTPLUG, altmap, migratetype);
>
> set_zone_contiguous(zone);
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 44ec5594798d..42a1d2d2a87d 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -6117,7 +6117,7 @@ overlap_memmap_init(unsigned long zone, unsigned long
> *pfn)
> * (usually MIGRATE_MOVABLE). Besides setting the migratetype, no related
> * zone stats (e.g., nr_isolate_pageblock) are touched.
> */
> -void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long
> zone,
> +void __meminit memmap_init_range(unsigned long size, int nid, unsigned long
> zone,
> unsigned long start_pfn, unsigned long zone_end_pfn,
> enum meminit_context context,
> struct vmem_altmap *altmap, int migratetype)
> @@ -6254,7 +6254,7 @@ static void __meminit zone_init_free_lists(struct zone
> *zone)
> }
> }
>
> -void __meminit __weak memmap_init(unsigned long size, int nid,
> +void __meminit __weak memmap_init_zone(unsigned long size, int nid,
> unsigned long zone,
> unsigned long range_start_pfn)
> {
> @@ -6268,7 +6268,7 @@ void __meminit __weak memmap_init(unsigned long size,
> int nid,
>
> if (end_pfn > start_pfn) {
> size = end_pfn - start_pfn;
> - memmap_init_zone(size, nid, zone, start_p
[PATCH 2/2] dm crypt: support using trusted keys
Commit 27f5411a718c ("dm crypt: support using encrypted keys") extended
dm-crypt to allow use of "encrypted" keys along with "user" and "logon".
Along the same lines, teach dm-crypt to support "trusted" keys as well.
Signed-off-by: Ahmad Fatoum
---
Unsure on whether target_type::version is something authors increment or
maintainers fix up. I can respin if needed.
Cc: Jan Lübbe
Cc: linux-integr...@vger.kernel.org
Cc: keyri...@vger.kernel.org
Cc: Dmitry Baryshkov
---
.../admin-guide/device-mapper/dm-crypt.rst| 2 +-
drivers/md/Kconfig| 1 +
drivers/md/dm-crypt.c | 23 ++-
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/device-mapper/dm-crypt.rst
b/Documentation/admin-guide/device-mapper/dm-crypt.rst
index 1a6753b76dbb..aa2d04d95df6 100644
--- a/Documentation/admin-guide/device-mapper/dm-crypt.rst
+++ b/Documentation/admin-guide/device-mapper/dm-crypt.rst
@@ -67,7 +67,7 @@ Parameters::
the value passed in .
-Either 'logon', 'user' or 'encrypted' kernel key type.
+Either 'logon', 'user', 'encrypted' or 'trusted' kernel key type.
The kernel keyring key description crypt target should look for
diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
index 9e44c09f6410..f2014385d48b 100644
--- a/drivers/md/Kconfig
+++ b/drivers/md/Kconfig
@@ -270,6 +270,7 @@ config DM_CRYPT
tristate "Crypt target support"
depends on BLK_DEV_DM
depends on (ENCRYPTED_KEYS || ENCRYPTED_KEYS=n)
+ depends on (TRUSTED_KEYS || TRUSTED_KEYS=n)
select CRYPTO
select CRYPTO_CBC
select CRYPTO_ESSIV
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 7eeb9248eda5..6c7c687e546c 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
@@ -2452,6 +2453,22 @@ static int set_key_encrypted(struct crypt_config *cc,
struct key *key)
return 0;
}
+static int set_key_trusted(struct crypt_config *cc, struct key *key)
+{
+ const struct trusted_key_payload *tkp;
+
+ tkp = key->payload.data[0];
+ if (!tkp)
+ return -EKEYREVOKED;
+
+ if (cc->key_size != tkp->key_len)
+ return -EINVAL;
+
+ memcpy(cc->key, tkp->key, cc->key_size);
+
+ return 0;
+}
+
static int crypt_set_keyring_key(struct crypt_config *cc, const char
*key_string)
{
char *new_key_string, *key_desc;
@@ -2484,6 +2501,10 @@ static int crypt_set_keyring_key(struct crypt_config
*cc, const char *key_string
!strncmp(key_string, "encrypted:", key_desc - key_string +
1)) {
type = &key_type_encrypted;
set_key = set_key_encrypted;
+ } else if (IS_ENABLED(CONFIG_TRUSTED_KEYS) &&
+ !strncmp(key_string, "trusted:", key_desc - key_string + 1))
{
+ type = &key_type_trusted;
+ set_key = set_key_trusted;
} else {
return -EINVAL;
}
@@ -3555,7 +3576,7 @@ static void crypt_io_hints(struct dm_target *ti, struct
queue_limits *limits)
static struct target_type crypt_target = {
.name = "crypt",
- .version = {1, 22, 0},
+ .version = {1, 23, 0},
.module = THIS_MODULE,
.ctr= crypt_ctr,
.dtr= crypt_dtr,
--
2.30.0
RE: [PATCH v2 3/3] perf vendor events: Add Fujitsu A64FX V1.2 pmu event
Hi John
> I think that we need to the same here as the IMPDEF recommended events - add a
> common JSON to reduce the duplication.
>
> I had done work on this for current CPUs, but never got it finished. Let me
> check
> the status.
If you let me know the result, I will resend the patch according to the policy.
Best Regards
> -Original Message-
> From: John Garry
> Sent: Friday, January 22, 2021 2:41 AM
> To: Nakamura, Shunsuke/中村 俊介
> Cc: w...@kernel.org; mathieu.poir...@linaro.org; leo@linaro.org;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 3/3] perf vendor events: Add Fujitsu A64FX V1.2 pmu
> event
>
> On 21/01/2021 10:54, Shunsuke Nakamura wrote:
> > + {
> > +"PublicDescription": "This event counts each correction to the
> > predicted
> program flow that occurs because of a misprediction from, or no prediction
> from,
> the branch prediction resources and that relates to instructions that the
> branch
> prediction resources are capable of predicting.",
> > +"EventCode": "0x10",
> > +"EventName": "BR_MIS_PRED",
>
> I think that we need to the same here as the IMPDEF recommended events - add a
> common JSON to reduce the duplication.
>
> I had done work on this for current CPUs, but never got it finished. Let me
> check
> the status.
>
> Cheers,
> John
>
> Ps, arm have put JSONs here for their cores:
>
> https://github.com/ARM-software/data/tree/master/pmu
>
> But unfortunately the schema does not suit perf.
>
> I raised an issue, but no response.
>
> I'm just wondering if you hand copied the JSON data.
>
>
> > +"BriefDescription": "This event counts each correction to the predicted
> program flow that occurs because of a misprediction from, or no prediction
> from,
> the branch prediction resources and that relates to instructions that the
> branch
> prediction resources are capable of predicting."
> > + },
[PATCH 1/2] dm crypt: replaced #if defined with IS_ENABLED
IS_ENABLED(CONFIG_ENCRYPTED_KEYS) is true whether the option is built-in
or a module, so use it instead of #if defined checking for each
separately.
The other #if was to avoid a static function defined, but unused
warning. As we now always build the callsite when the function
is defined, we can remove that first #if guard.
Suggested-by: Arnd Bergmann
Signed-off-by: Ahmad Fatoum
---
Cc: Dmitry Baryshkov
---
drivers/md/dm-crypt.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 8c874710f0bc..7eeb9248eda5 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -2436,7 +2436,6 @@ static int set_key_user(struct crypt_config *cc, struct
key *key)
return 0;
}
-#if defined(CONFIG_ENCRYPTED_KEYS) || defined(CONFIG_ENCRYPTED_KEYS_MODULE)
static int set_key_encrypted(struct crypt_config *cc, struct key *key)
{
const struct encrypted_key_payload *ekp;
@@ -2452,7 +2451,6 @@ static int set_key_encrypted(struct crypt_config *cc,
struct key *key)
return 0;
}
-#endif /* CONFIG_ENCRYPTED_KEYS */
static int crypt_set_keyring_key(struct crypt_config *cc, const char
*key_string)
{
@@ -2482,11 +2480,10 @@ static int crypt_set_keyring_key(struct crypt_config
*cc, const char *key_string
} else if (!strncmp(key_string, "user:", key_desc - key_string + 1)) {
type = &key_type_user;
set_key = set_key_user;
-#if defined(CONFIG_ENCRYPTED_KEYS) || defined(CONFIG_ENCRYPTED_KEYS_MODULE)
- } else if (!strncmp(key_string, "encrypted:", key_desc - key_string +
1)) {
+ } else if (IS_ENABLED(CONFIG_ENCRYPTED_KEYS) &&
+ !strncmp(key_string, "encrypted:", key_desc - key_string +
1)) {
type = &key_type_encrypted;
set_key = set_key_encrypted;
-#endif
} else {
return -EINVAL;
}
--
2.30.0
Re: [PATCH] mm: fix prototype warning from kernel test robot
On 01/22/21 at 09:40am, David Hildenbrand wrote: > On 22.01.21 08:03, Baoquan He wrote: > > Kernel test robot calling make with 'W=1' triggering warning like below > > below for memmap_init_zone() function. > > > > mm/page_alloc.c:6259:23: warning: no previous prototype for > > 'memmap_init_zone' [-Wmissing-prototypes] > > 6259 | void __meminit __weak memmap_init_zone(unsigned long size, int nid, > > | ^~~~ > > > > Fix it by adding the function declaration in include/linux/mm.h. > > Since memmap_init_zone() has a generic version with '__weak', > > the declaratoin in ia64 header file can be simply removed. > > > > Signed-off-by: Baoquan He > > Reported-by: kernel test robot > > --- > > arch/ia64/include/asm/pgtable.h | 5 - > > include/linux/mm.h | 1 + > > 2 files changed, 1 insertion(+), 5 deletions(-) > > > > diff --git a/arch/ia64/include/asm/pgtable.h > > b/arch/ia64/include/asm/pgtable.h > > index 2c81394a2430..9b4efe89e62d 100644 > > --- a/arch/ia64/include/asm/pgtable.h > > +++ b/arch/ia64/include/asm/pgtable.h > > @@ -517,11 +517,6 @@ extern struct page *zero_page_memmap_ptr; > > __changed; \ > > }) > > #endif > > - > > -# ifdef CONFIG_VIRTUAL_MEM_MAP > > - /* arch mem_map init routine is needed due to holes in a virtual mem_map > > */ > > -extern void memmap_init_zone(struct zone *zone); > > -# endif /* CONFIG_VIRTUAL_MEM_MAP */ > > # endif /* !__ASSEMBLY__ */ > > > > /* > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > index 56bb239f9150..073049bd0b29 100644 > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -2401,6 +2401,7 @@ extern void set_dma_reserve(unsigned long > > new_dma_reserve); > > extern void memmap_init_range(unsigned long, int, unsigned long, > > unsigned long, unsigned long, enum meminit_context, > > struct vmem_altmap *, int migratetype); > > +extern void memmap_init_zone(struct zone *zone); > > extern void setup_per_zone_wmarks(void); > > extern int __meminit init_per_zone_wmark_min(void); > > extern void mem_init(void); > > > > This patch is on top of your other series, no? > > In -next, we have > > extern void memmap_init_zone(unsigned long, int, unsigned long, ... > > In that file, so something is wrong. Right, this one is based on the memmap_init_xx clean up patchset. I mentioned this the the sub-thread of kernel test robot reporting issues.
[PATCH] genirq: Limit irq_calc_affinity_vectors to housekeeping CPUs
Replace the cpumask used in irq_calc_affinity_vectors from all possible
CPUs to only housekeeping CPUs.
When we have isolated CPUs used by real-time tasks, IRQs will be move to
housekeeping CPUs.
If there are too many IRQ vectors, moving the all to housekeeping CPUs may
exceed per-CPU vector limits. For example, when I only have two
housekeeping CPUs, there are dozens of IRQs on two CPUs, but actually one
IRQ per housekeeping CPU is enough.
Signed-off-by: Liu Chao
---
kernel/irq/affinity.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
index 4d89ad4fae3b..3f22e3314e1b 100644
--- a/kernel/irq/affinity.c
+++ b/kernel/irq/affinity.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
static void irq_spread_init_one(struct cpumask *irqmsk, struct cpumask *nmsk,
unsigned int cpus_per_vec)
@@ -506,7 +507,8 @@ unsigned int irq_calc_affinity_vectors(unsigned int minvec,
unsigned int maxvec,
set_vecs = maxvec - resv;
} else {
get_online_cpus();
- set_vecs = cpumask_weight(cpu_possible_mask);
+ set_vecs = cpumask_weight(
+ housekeeping_cpumask(HK_FLAG_MANAGED_IRQ));
put_online_cpus();
}
--
2.23.0
Re: [PATCH 1/2] arm64: boot: dts: add new dts for hellcat & petra
Hi Daniel,
On 1/22/21 12:12 AM, Daniel Walker wrote:
> Add Petra and Hellcat dts file. These platforms are based on
> the Xilinx Zynqmp platform.
>
> Signed-off-by: Daniel Walker
> Cc: xe-linux-exter...@cisco.com
> ---
> arch/arm64/boot/dts/xilinx/Makefile | 2 +
> .../boot/dts/xilinx/zynqmp-petra-hellcat.dts | 856 ++
> arch/arm64/boot/dts/xilinx/zynqmp-petra.dts | 847 +
> 3 files changed, 1705 insertions(+)
> create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-petra-hellcat.dts
> create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-petra.dts
First of all I can't see 2/2.
>
> diff --git a/arch/arm64/boot/dts/xilinx/Makefile
> b/arch/arm64/boot/dts/xilinx/Makefile
> index 60f5443f3ef4..d9eacb3c60e5 100644
> --- a/arch/arm64/boot/dts/xilinx/Makefile
> +++ b/arch/arm64/boot/dts/xilinx/Makefile
> @@ -15,3 +15,5 @@ dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu102-rev1.0.dtb
> dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu104-revA.dtb
> dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu106-revA.dtb
> dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-zcu111-revA.dtb
> +dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-petra.dts
> +dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-petra-hellcat.dts
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-petra-hellcat.dts
> b/arch/arm64/boot/dts/xilinx/zynqmp-petra-hellcat.dts
> new file mode 100644
> index ..87e23c1cac65
> --- /dev/null
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-petra-hellcat.dts
> @@ -0,0 +1,856 @@
> +/*
> + * dts file for Cisco Petra-Hellcat Switching IOT platform
> + *
> + * (C) Copyright 2016-2018, Cisco Systems, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
This should be SPDX header.
> + */
> +
> +/dts-v1/;
> +
> +#include "zynqmp.dtsi"
> +#include "zynqmp-clk-ccf.dtsi"
> +
> +/*
> + * PL *
> + */
useless
> +
> +/ {
> +reserved-memory {
> +#address-cells = <0x2>;
just 2
> +#size-cells = <0x2>;
just 2
> +ranges;
> +
> +rproc@3ed0 {
> +no-map;
> +reg = <0x0 0x3ed0 0x0 0x100>;
> +};
> +zynqmp_sha_reserved: buffer@0 {
> +compatible = "shared-dma-pool";
> +no-map;
> +reg = <0x0 0x7800 0x0 0x0002>;
> +};
> +};
> +
> +sha384 {
> +compatible = "xlnx,zynqmp-keccak-384";
> +memory-region = <&zynqmp_sha_reserved>;
> +};
> +
> + amba_pl: amba_pl@0 {
Long time ago we said that we are not going to push any PL related
configurations. It means all below can't be merged.
And there are also coding style issues.
> + #address-cells = <2>;
> + #size-cells = <2>;
> + compatible = "simple-bus";
> + ranges ;
> + design_1_i_axi_iic_BP: i2c@80104000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +clocks = <0x3 0x47>;
> + compatible = "xlnx,xps-iic-2.00.a";
> + interrupt-parent = <&gic>;
> + interrupts = <0 93 4>;
> + reg = <0x0 0x80104000 0x0 0x1000>;
> + };
> + design_1_i_axi_iic_KM_PLT: i2c@80106000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +clocks = <0x3 0x47>;
> + compatible = "xlnx,xps-iic-2.00.a";
> + interrupt-parent = <&gic>;
> + interrupts = <0 107 4>;
> + reg = <0x0 0x80106000 0x0 0x1000>;
> + };
> + design_1_i_axi_iic_LC1: i2c@8010 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +clocks = <0x3 0x47>;
> + compatible = "xlnx,xps-iic-2.00.a";
> + interrupt-parent = <&gic>;
> + interrupts = <0 89 4>;
> + reg = <0x0 0x8010 0x0 0x1000>;
> + };
> + design_1_i_axi_iic_LC2: i2c@80101000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +clocks = <0x3 0x47>;
> + compatible = "xlnx,xps-iic-2.00.a";
> + interrupt-parent = <&gic>;
> + interrupts = <0 90 4>;
> + reg = <0x0 0x80101000 0x0 0x1000>;
> + };
> + design_1_i_axi_iic_LC3: i2c@80102000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +clocks = <0x3 0x47>;
> + compatible = "xlnx,xps-iic-2.00.a";
> + interrupt-parent = <&gic>;
> + interrupts = <0 91 4>
Re: [PATCH v3] x86: Treat R_386_PLT32 as R_386_PC32
On Thu, Jan 14, 2021 at 2:48 PM Fangrui Song wrote:
>
> This is similar to commit b21ebf2fb4cd ("x86: Treat R_X86_64_PLT32 as
> R_X86_64_PC32"), but for i386. As far as Linux kernel is concerned,
> R_386_PLT32 can be treated the same as R_386_PC32.
>
> R_386_PC32/R_X86_64_PC32 are PC-relative relocation types with the
> requirement that the symbol address is significant.
> R_386_PLT32/R_X86_64_PLT32 are PC-relative relocation types without the
> address significance requirement.
>
> On x86-64, there is no PIC vs non-PIC PLT distinction and an
> R_X86_64_PLT32 relocation is produced for both `call/jmp foo` and
> `call/jmp foo@PLT` with newer (2018) GNU as/LLVM integrated assembler.
>
> On i386, there are 2 types of PLTs, PIC and non-PIC. Currently the
> convention is to use R_386_PC32 for non-PIC PLT and R_386_PLT32 for PIC
> PLT.
>
> clang-12 -fno-pic (since
> https://github.com/llvm/llvm-project/commit/a084c0388e2a59b9556f2de008232da3f1d6)
> can emit R_386_PLT32 for compiler generated function declarations as
> well to avoid a canonical PLT entry (st_shndx=0, st_value!=0) if the
> symbol turns out to be defined externally. GCC/GNU as will likely keep
> using R_386_PC32 because (1) the ABI is legacy (2) the change will drop
> a GNU ld non-default visibility ifunc for shared objects.
> https://sourceware.org/bugzilla/show_bug.cgi?id=27169
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/1210
> Reported-by: Arnd Bergmann
> Signed-off-by: Fangrui Song
> Reviewed-by: Nick Desaulniers
> Reviewed-by: Nathan Chancellor
> Tested-by: Nick Desaulniers
> Tested-by: Nathan Chancellor
>
> ---
> Change in v2:
> * Improve commit message
> ---
> Change in v3:
> * Change the GCC link to the more relevant GNU as link.
> * Fix the relevant llvm-project commit id.
> ---
> arch/x86/kernel/module.c | 1 +
> arch/x86/tools/relocs.c | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
> index 34b153cbd4ac..5e9a34b5bd74 100644
> --- a/arch/x86/kernel/module.c
> +++ b/arch/x86/kernel/module.c
> @@ -114,6 +114,7 @@ int apply_relocate(Elf32_Shdr *sechdrs,
> *location += sym->st_value;
> break;
> case R_386_PC32:
> + case R_386_PLT32:
> /* Add the value, subtract its position */
> *location += sym->st_value - (uint32_t)location;
> break;
> diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
> index ce7188cbdae5..717e48ca28b6 100644
> --- a/arch/x86/tools/relocs.c
> +++ b/arch/x86/tools/relocs.c
> @@ -867,6 +867,7 @@ static int do_reloc32(struct section *sec, Elf_Rel *rel,
> Elf_Sym *sym,
> case R_386_PC32:
> case R_386_PC16:
> case R_386_PC8:
> + case R_386_PLT32:
> /*
> * NONE can be ignored and PC relative relocations don't
> * need to be adjusted.
> @@ -910,6 +911,7 @@ static int do_reloc_real(struct section *sec, Elf_Rel
> *rel, Elf_Sym *sym,
> case R_386_PC32:
> case R_386_PC16:
> case R_386_PC8:
> + case R_386_PLT32:
> /*
> * NONE can be ignored and PC relative relocations don't
> * need to be adjusted.
> --
> 2.30.0.296.g2bfb1c46d8-goog
>
Ping:)
Re: [PATCH v1] can: mcp251xfd: Add some sysfs debug interfaces for registers r/w
Hi,
In addition to Marc’s comment, I also have security concerns.
On Fri. 22 Jan 2021 at 15:22, Su Yanjun wrote:
> When i debug mcp2518fd, some method to track registers is
> needed. This easy debug interface will be ok.
>
> For example,
> read a register at 0xe00:
> echo 0xe00 > can_get_reg
> cat can_get_reg
>
> write a register at 0xe00:
> echo 0xe00,0x60 > can_set_reg
What about:
printf "A%0.s" {1..1000} > can_set_reg
Doesn’t it crash the kernel?
I see no checks of the buf len in your code and I suspect it to be
vulnerable to stack buffer overflow exploits.
> Signed-off-by: Su Yanjun
> ---
> .../net/can/spi/mcp251xfd/mcp251xfd-core.c| 132 ++
> 1 file changed, 132 insertions(+)
>
> diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
> b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
> index ab8aad0a7594..d65abe5505d5 100644
> --- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
> +++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
> @@ -27,6 +27,131 @@
>
> #define DEVICE_NAME "mcp251xfd"
>
> +/* Add sysfs debug interface for easy to debug
> + *
> + * For example,
> + *
> + * - read a register
> + * echo 0xe00 > can_get_reg
> + * cat can_get_reg
> + *
> + * - write a register
> + * echo 0xe00,0x1 > can_set_reg
> + *
> + */
> +static int reg_offset;
> +
> +static int __get_param(const char *buf, char *off, char *val)
> +{
> + int len;
> +
> + if (!buf || !off || !val)
> + return -EINVAL;
> +
> + len = 0;
> + while (*buf != ',') {
> + *off++ = *buf++;
> + len++;
> +
> + if (len >= 16)
> + return -EINVAL;
> + }
> +
> + buf++;
> +
> + *off = '\0';
> +
> + len = 0;
> + while (*buf) {
> + *val++ = *buf++;
> + len++;
> +
> + if (len >= 16)
> + return -EINVAL;
> + }
> +
> + *val = '\0';
> +
> + return 0;
> +}
> +
> +static ssize_t can_get_reg_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + int err;
> + u32 val;
> + struct mcp251xfd_priv *priv;
> +
> + priv = dev_get_drvdata(dev);
> +
> + err = regmap_read(priv->map_reg, reg_offset, &val);
> + if (err)
> + return 0;
> +
> + return sprintf(buf, "reg = 0x%08x, val = 0x%08x\n", reg_offset, val);
> +}
> +
> +static ssize_t can_get_reg_store(struct device *dev,
> +struct device_attribute *attr, const char
> *buf, size_t len)
> +{
> + u32 off;
> +
> + reg_offset = 0;
> +
> + if (kstrtouint(buf, 0, &off) || (off % 4))
> + return -EINVAL;
> +
> + reg_offset = off;
> +
> + return len;
> +}
> +
> +static ssize_t can_set_reg_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return 0;
> +}
> +
> +static ssize_t can_set_reg_store(struct device *dev,
> +struct device_attribute *attr, const char
> *buf, size_t len)
> +{
> + struct mcp251xfd_priv *priv;
> + u32 off, val;
> + int err;
> +
> + char s1[16];
> + char s2[16];
> +
> + if (__get_param(buf, s1, s2))
> + return -EINVAL;
> +
> + if (kstrtouint(s1, 0, &off) || (off % 4))
> + return -EINVAL;
> +
> + if (kstrtouint(s2, 0, &val))
> + return -EINVAL;
> +
> + err = regmap_write(priv->map_reg, off, val);
> + if (err)
> + return -EINVAL;
> +
> + return len;
> +}
> +
> +static DEVICE_ATTR_RW(can_get_reg);
> +static DEVICE_ATTR_RW(can_set_reg);
> +
> +static struct attribute *can_attributes[] = {
> + &dev_attr_can_get_reg.attr,
> + &dev_attr_can_set_reg.attr,
> + NULL
> +};
> +
> +static const struct attribute_group can_group = {
> + .attrs = can_attributes,
> + NULL
> +};
> +
> static const struct mcp251xfd_devtype_data mcp251xfd_devtype_data_mcp2517fd
> = {
> .quirks = MCP251XFD_QUIRK_MAB_NO_WARN | MCP251XFD_QUIRK_CRC_REG |
> MCP251XFD_QUIRK_CRC_RX | MCP251XFD_QUIRK_CRC_TX |
> @@ -2944,6 +3069,12 @@ static int mcp251xfd_probe(struct spi_device *spi)
> if (err)
> goto out_free_candev;
>
> + err = sysfs_create_group(&spi->dev.kobj, &can_group);
> + if (err) {
> + netdev_err(priv->ndev, "Create can group fail.\n");
> + goto out_free_candev;
> + }
> +
> err = can_rx_offload_add_manual(ndev, &priv->offload,
> MCP251XFD_NAPI_WEIGHT);
> if (err)
> @@ -2972,6 +3103,7 @@ static int mcp251xfd_remove(struct spi_device *spi)
> mcp251xfd_unregister(priv);
> spi->max_speed_hz = priv->spi_max_speed_hz_orig;
> free_candev(ndev);
> + sysfs_remove_group(&spi->dev.kobj, &can_group);
Re: [PATCH v5 1/2] lib: stackdepot: Add support to configure STACK_HASH_SIZE
On Mon, Jan 18, 2021 at 10:57 AM wrote: > > From: Yogesh Lal > > Use CONFIG_STACK_HASH_ORDER to configure STACK_HASH_SIZE. > > Aim is to have configurable value for STACK_HASH_SIZE, > so depend on use case one can configure it. > > One example is of Page Owner, default value of > STACK_HASH_SIZE lead stack depot to consume 8MB of static memory. > Making it configurable and use lower value helps to enable features like > CONFIG_PAGE_OWNER without any significant overhead. > > Signed-off-by: Yogesh Lal > Signed-off-by: Vinayak Menon > Signed-off-by: Vijayanand Jitta Reviewed-by: Alexander Potapenko > --- > lib/Kconfig | 9 + > lib/stackdepot.c | 3 +-- > 2 files changed, 10 insertions(+), 2 deletions(-) > > diff --git a/lib/Kconfig b/lib/Kconfig > index b46a9fd..96ee125 100644 > --- a/lib/Kconfig > +++ b/lib/Kconfig > @@ -651,6 +651,15 @@ config STACKDEPOT > bool > select STACKTRACE > > +config STACK_HASH_ORDER > + int "stack depot hash size (12 => 4KB, 20 => 1024KB)" > + range 12 20 > + default 20 > + depends on STACKDEPOT > + help > +Select the hash size as a power of 2 for the stackdepot hash table. > +Choose a lower value to reduce the memory impact. > + > config SBITMAP > bool > > diff --git a/lib/stackdepot.c b/lib/stackdepot.c > index 2caffc6..dff8521 100644 > --- a/lib/stackdepot.c > +++ b/lib/stackdepot.c > @@ -142,8 +142,7 @@ static struct stack_record *depot_alloc_stack(unsigned > long *entries, int size, > return stack; > } > > -#define STACK_HASH_ORDER 20 > -#define STACK_HASH_SIZE (1L << STACK_HASH_ORDER) > +#define STACK_HASH_SIZE (1L << CONFIG_STACK_HASH_ORDER) > #define STACK_HASH_MASK (STACK_HASH_SIZE - 1) > #define STACK_HASH_SEED 0x9747b28c > > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of > Code Aurora Forum, hosted by The Linux Foundation > 2.7.4 > -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
Re: [PATCH] media: atomisp: remove redundant NULL check
Thanks for the patch. Feel free to add my r-b: Reviewed-by: Robert Foss On Thu, 21 Jan 2021 at 09:31, Yang Li wrote: > > Fix below warnings reported by coccicheck: > ./drivers/staging/media/atomisp/pci/sh_css_params.c:1575:2-8: WARNING: > NULL check before some freeing functions is not needed. > ./drivers/staging/media/atomisp/pci/sh_css_params.c:3006:2-8: WARNING: > NULL check before some freeing functions is not needed. > > Reported-by: Abaci Robot > Signed-off-by: Yang Li > --- > drivers/staging/media/atomisp/pci/sh_css_params.c | 6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/drivers/staging/media/atomisp/pci/sh_css_params.c > b/drivers/staging/media/atomisp/pci/sh_css_params.c > index 24fc497..569473b9 100644 > --- a/drivers/staging/media/atomisp/pci/sh_css_params.c > +++ b/drivers/staging/media/atomisp/pci/sh_css_params.c > @@ -1575,8 +1575,7 @@ struct ia_css_isp_3a_statistics_map * > return me; > > err: > - if (me) > - kvfree(me); > + kvfree(me); > return NULL; > } > > @@ -3006,8 +3005,7 @@ static void free_map(struct sh_css_ddr_address_map *map) > } > > kvfree(params); > - if (per_frame_params) > - kvfree(per_frame_params); > + kvfree(per_frame_params); > stream->isp_params_configs = NULL; > stream->per_frame_isp_params_configs = NULL; > > -- > 1.8.3.1 >
Re: [PATCH v1 2/2] isa: Make the remove callback for isa drivers return void
On Thu, Jan 21, 2021 at 09:48:12PM +0100, Uwe Kleine-König wrote: > The driver core ignores the return value of the remove callback, so > don't give isa drivers the chance to provide a value. > > Adapt all isa_drivers with a remove callbacks accordingly; they all > return 0 unconditionally anyhow. > > Signed-off-by: Uwe Kleine-König Acked-by: Wolfram Sang # for I2C signature.asc Description: PGP signature
Re: [PATCH] ALSA: hda/realtek: Enable headset of ASUS B1400CEPE with ALC256
On Fri, 22 Jan 2021 06:47:06 +0100, Jian-Hong Pan wrote: > > ASUS B1400CEPE laptop's headset audio is not enabled until > ALC256_FIXUP_ASUS_HPE quirk is applied. > > Here is the original pin node values: > > 0x12 0x4000 > 0x13 0x41f0 > 0x14 0x90170110 > 0x18 0x41f0 > 0x19 0x41f0 > 0x1a 0x41f0 > 0x1b 0x41f0 > 0x1d 0x40461b45 > 0x1e 0x41f0 > 0x21 0x04211020 > > Signed-off-by: Jian-Hong Pan Thanks, applied now. Takashi
Re: [PATCH -next] hid/hid-sensor-custom: convert comma to semicolon
On Wed, 20 Jan 2021 20:49:57 +
Jonathan Cameron wrote:
> On Tue, 29 Dec 2020 18:18:41 +
> Jonathan Cameron wrote:
>
> > On Mon, 14 Dec 2020 06:13:58 -0800
> > Srinivas Pandruvada wrote:
> >
> > > On Mon, 2020-12-14 at 21:32 +0800, Zheng Yongjun wrote:
> > > > Replace a comma between expression statements by a semicolon.
> > > >
> > > > Signed-off-by: Zheng Yongjun
> > > Acked-by: Srinivas Pandruvada
> > Applied to the togreg branch of iio.git and pushed out as testing for
> > the autobuilders to see if they can break it.
> Hi Jiri,
>
> Just realised this is in HID rather than IIO. I hope you don't mind as
> it's now deep in a tree I'd rather not rebase.
On basis it wasn't actually that bad, (only one merge after it) I did
the rebase and dropped this patch. Jiri, guess you probably
want to pick this up through HID.
Thanks,
Jonathan
>
> Sorry about that.
>
> Jonathan
>
> >
> > Thanks,
> >
> > Jonathan
> >
> > >
> > > > ---
> > > > drivers/hid/hid-sensor-custom.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/hid/hid-sensor-custom.c b/drivers/hid/hid-
> > > > sensor-custom.c
> > > > index 4d25577a8573..6c47a2e7623d 100644
> > > > --- a/drivers/hid/hid-sensor-custom.c
> > > > +++ b/drivers/hid/hid-sensor-custom.c
> > > > @@ -728,7 +728,7 @@ static int hid_sensor_custom_dev_if_add(struct
> > > > hid_sensor_custom *sensor_inst)
> > > >
> > > > sensor_inst->custom_dev.minor = MISC_DYNAMIC_MINOR;
> > > > sensor_inst->custom_dev.name = dev_name(&sensor_inst->pdev-
> > > >
> > > > >dev);
> > > > - sensor_inst->custom_dev.fops = &hid_sensor_custom_fops,
> > > > + sensor_inst->custom_dev.fops = &hid_sensor_custom_fops;
> > > > ret = misc_register(&sensor_inst->custom_dev);
> > > > if (ret) {
> > > > kfifo_free(&sensor_inst->data_fifo);
> > >
> > >
> >
>
Re: [PATCH v5 1/2] lib: stackdepot: Add support to configure STACK_HASH_SIZE
On Mon, Jan 18, 2021 at 11:54 PM Randy Dunlap wrote:
>
> On 1/18/21 1:56 AM, vji...@codeaurora.org wrote:
> > From: Yogesh Lal
> >
> > Use CONFIG_STACK_HASH_ORDER to configure STACK_HASH_SIZE.
> >
> > Aim is to have configurable value for STACK_HASH_SIZE,
> > so depend on use case one can configure it.
> >
> > One example is of Page Owner, default value of
> > STACK_HASH_SIZE lead stack depot to consume 8MB of static memory.
> > Making it configurable and use lower value helps to enable features like
> > CONFIG_PAGE_OWNER without any significant overhead.
> >
> > Signed-off-by: Yogesh Lal
> > Signed-off-by: Vinayak Menon
> > Signed-off-by: Vijayanand Jitta
>
> Hi,
>
> Did you see
> https://lore.kernel.org/lkml/202101050729.cwtd47yw-...@intel.com/
>
> It seems that arch/arc/ does not have:
>arc-elf-ld: lib/stackdepot.o: in function `filter_irq_stacks':
>(.text+0x6): undefined reference to `__irqentry_text_start'
> >> arc-elf-ld: (.text+0x6): undefined reference to `__irqentry_text_start'
> >> arc-elf-ld: (.text+0x26): undefined reference to `__irqentry_text_end'
> >> arc-elf-ld: (.text+0x26): undefined reference to `__irqentry_text_end'
> >> arc-elf-ld: (.text+0x34): undefined reference to
> >> `__softirqentry_text_start'
> >> arc-elf-ld: (.text+0x34): undefined reference to
> >> `__softirqentry_text_start'
> >> arc-elf-ld: (.text+0x3c): undefined reference to `__softirqentry_text_end'
> >> arc-elf-ld: (.text+0x3c): undefined reference to `__softirqentry_text_end'
>
Hi Randy,
Could you try out the following patch?
Thanks,
Alex
diff --git a/arch/arc/kernel/vmlinux.lds.S b/arch/arc/kernel/vmlinux.lds.S
index 33ce59d91461..94d3f9620d0b 100644
--- a/arch/arc/kernel/vmlinux.lds.S
+++ b/arch/arc/kernel/vmlinux.lds.S
@@ -83,6 +83,8 @@ SECTIONS
.text : {
_text = .;
+ IRQENTRY_TEXT
+ SOFTIRQENTRY_TEXT
TEXT_TEXT
SCHED_TEXT
CPUIDLE_TEXT
Re: [PATCH] mm: fix prototype warning from kernel test robot
On 22.01.21 09:46, Baoquan He wrote: > On 01/22/21 at 09:40am, David Hildenbrand wrote: >> On 22.01.21 08:03, Baoquan He wrote: >>> Kernel test robot calling make with 'W=1' triggering warning like below >>> below for memmap_init_zone() function. >>> >>> mm/page_alloc.c:6259:23: warning: no previous prototype for >>> 'memmap_init_zone' [-Wmissing-prototypes] >>> 6259 | void __meminit __weak memmap_init_zone(unsigned long size, int nid, >>> | ^~~~ >>> >>> Fix it by adding the function declaration in include/linux/mm.h. >>> Since memmap_init_zone() has a generic version with '__weak', >>> the declaratoin in ia64 header file can be simply removed. >>> >>> Signed-off-by: Baoquan He >>> Reported-by: kernel test robot >>> --- >>> arch/ia64/include/asm/pgtable.h | 5 - >>> include/linux/mm.h | 1 + >>> 2 files changed, 1 insertion(+), 5 deletions(-) >>> >>> diff --git a/arch/ia64/include/asm/pgtable.h >>> b/arch/ia64/include/asm/pgtable.h >>> index 2c81394a2430..9b4efe89e62d 100644 >>> --- a/arch/ia64/include/asm/pgtable.h >>> +++ b/arch/ia64/include/asm/pgtable.h >>> @@ -517,11 +517,6 @@ extern struct page *zero_page_memmap_ptr; >>> __changed; \ >>> }) >>> #endif >>> - >>> -# ifdef CONFIG_VIRTUAL_MEM_MAP >>> - /* arch mem_map init routine is needed due to holes in a virtual mem_map >>> */ >>> -extern void memmap_init_zone(struct zone *zone); >>> -# endif /* CONFIG_VIRTUAL_MEM_MAP */ >>> # endif /* !__ASSEMBLY__ */ >>> >>> /* >>> diff --git a/include/linux/mm.h b/include/linux/mm.h >>> index 56bb239f9150..073049bd0b29 100644 >>> --- a/include/linux/mm.h >>> +++ b/include/linux/mm.h >>> @@ -2401,6 +2401,7 @@ extern void set_dma_reserve(unsigned long >>> new_dma_reserve); >>> extern void memmap_init_range(unsigned long, int, unsigned long, >>> unsigned long, unsigned long, enum meminit_context, >>> struct vmem_altmap *, int migratetype); >>> +extern void memmap_init_zone(struct zone *zone); >>> extern void setup_per_zone_wmarks(void); >>> extern int __meminit init_per_zone_wmark_min(void); >>> extern void mem_init(void); >>> >> >> This patch is on top of your other series, no? >> >> In -next, we have >> >> extern void memmap_init_zone(unsigned long, int, unsigned long, ... >> >> In that file, so something is wrong. > > Right, this one is based on the memmap_init_xx clean up patchset. I > mentioned this the the sub-thread of kernel test robot reporting issues. > I think it would make things easier to move that fix to the front and resend the whole (5 patches) series. -- Thanks, David / dhildenb
Re: [PATCH 1/3] i2c: remove sirf bus driver
On Wed, Jan 20, 2021 at 02:28:32PM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > The CSR SiRF prima2/atlas platforms are getting removed, so this driver > is no longer needed. > > Cc: Barry Song > Signed-off-by: Arnd Bergmann Applied to for-next, thanks! signature.asc Description: PGP signature
Re: [PATCH] mm: fix prototype warning from kernel test robot
On 22.01.21 08:03, Baoquan He wrote: > Kernel test robot calling make with 'W=1' triggering warning like below > below for memmap_init_zone() function. > > mm/page_alloc.c:6259:23: warning: no previous prototype for > 'memmap_init_zone' [-Wmissing-prototypes] > 6259 | void __meminit __weak memmap_init_zone(unsigned long size, int nid, > | ^~~~ > > Fix it by adding the function declaration in include/linux/mm.h. > Since memmap_init_zone() has a generic version with '__weak', > the declaratoin in ia64 header file can be simply removed. > > Signed-off-by: Baoquan He > Reported-by: kernel test robot > --- > arch/ia64/include/asm/pgtable.h | 5 - > include/linux/mm.h | 1 + > 2 files changed, 1 insertion(+), 5 deletions(-) > > diff --git a/arch/ia64/include/asm/pgtable.h b/arch/ia64/include/asm/pgtable.h > index 2c81394a2430..9b4efe89e62d 100644 > --- a/arch/ia64/include/asm/pgtable.h > +++ b/arch/ia64/include/asm/pgtable.h > @@ -517,11 +517,6 @@ extern struct page *zero_page_memmap_ptr; > __changed; \ > }) > #endif > - > -# ifdef CONFIG_VIRTUAL_MEM_MAP > - /* arch mem_map init routine is needed due to holes in a virtual mem_map */ > -extern void memmap_init_zone(struct zone *zone); > -# endif /* CONFIG_VIRTUAL_MEM_MAP */ > # endif /* !__ASSEMBLY__ */ > > /* > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 56bb239f9150..073049bd0b29 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -2401,6 +2401,7 @@ extern void set_dma_reserve(unsigned long > new_dma_reserve); > extern void memmap_init_range(unsigned long, int, unsigned long, > unsigned long, unsigned long, enum meminit_context, > struct vmem_altmap *, int migratetype); > +extern void memmap_init_zone(struct zone *zone); > extern void setup_per_zone_wmarks(void); > extern int __meminit init_per_zone_wmark_min(void); > extern void mem_init(void); > This patch is on top of your other series, no? In -next, we have extern void memmap_init_zone(unsigned long, int, unsigned long, ... In that file, so something is wrong. -- Thanks, David / dhildenb
[PATCH] net: Simplify the calculation of variables
Fix the following coccicheck warnings:
./net/ipv4/esp4_offload.c:288:32-34: WARNING !A || A && B is
equivalent to !A || B.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Zhong
---
net/ipv4/esp4_offload.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/esp4_offload.c b/net/ipv4/esp4_offload.c
index 5bda5ae..9ba8cc5 100644
--- a/net/ipv4/esp4_offload.c
+++ b/net/ipv4/esp4_offload.c
@@ -285,7 +285,7 @@ static int esp_xmit(struct xfrm_state *x, struct sk_buff
*skb, netdev_features_
esp.esph = ip_esp_hdr(skb);
- if (!hw_offload || (hw_offload && !skb_is_gso(skb))) {
+ if (!hw_offload || (!skb_is_gso(skb))) {
esp.nfrags = esp_output_head(x, skb, &esp);
if (esp.nfrags < 0)
return esp.nfrags;
--
1.8.3.1
Re: [PATCH] media: pwc: Fix the URB buffer allocation
Thanks for the patch, it all looks good to me.
Feel free to add my r-b:
Reviewed-by: Robert Foss
On Thu, 21 Jan 2021 at 21:34, Takashi Iwai wrote:
>
> The URB buffer allocation of pwc driver involves with the
> dma_map_single(), and it needs to pass the right device. Currently it
> passes usb_device.dev, but it's no real device that manages the DMA.
> Since the passed device has no DMA mask set up, now the pwc driver
> hits the WARN_ON_ONCE() check in dma_map_page_attrs() (that was
> introduced in 5.10), resulting in an error at URB allocations.
> Eventually this ended up with the black output.
>
> This patch fixes the bug by passing the proper device, the bus
> controller, to make the URB allocation and map working again.
>
> BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1181133
> Cc:
> Signed-off-by: Takashi Iwai
> ---
> drivers/media/usb/pwc/pwc-if.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/usb/pwc/pwc-if.c b/drivers/media/usb/pwc/pwc-if.c
> index 61869636ec61..d771160bb168 100644
> --- a/drivers/media/usb/pwc/pwc-if.c
> +++ b/drivers/media/usb/pwc/pwc-if.c
> @@ -461,7 +461,7 @@ static int pwc_isoc_init(struct pwc_device *pdev)
> urb->pipe = usb_rcvisocpipe(udev, pdev->vendpoint);
> urb->transfer_flags = URB_ISO_ASAP | URB_NO_TRANSFER_DMA_MAP;
> urb->transfer_buffer_length = ISO_BUFFER_SIZE;
> - urb->transfer_buffer = pwc_alloc_urb_buffer(&udev->dev,
> + urb->transfer_buffer =
> pwc_alloc_urb_buffer(udev->bus->controller,
>
> urb->transfer_buffer_length,
>
> &urb->transfer_dma);
> if (urb->transfer_buffer == NULL) {
> @@ -524,7 +524,7 @@ static void pwc_iso_free(struct pwc_device *pdev)
> if (urb) {
> PWC_DEBUG_MEMORY("Freeing URB\n");
> if (urb->transfer_buffer)
> - pwc_free_urb_buffer(&urb->dev->dev,
> + pwc_free_urb_buffer(urb->dev->bus->controller,
>
> urb->transfer_buffer_length,
> urb->transfer_buffer,
> urb->transfer_dma);
> --
> 2.26.2
>
Re: [PATCH] mm: fix prototype warning from kernel test robot
On 01/22/21 at 09:55am, David Hildenbrand wrote: > On 22.01.21 09:46, Baoquan He wrote: > > On 01/22/21 at 09:40am, David Hildenbrand wrote: > >> On 22.01.21 08:03, Baoquan He wrote: > >>> Kernel test robot calling make with 'W=1' triggering warning like below > >>> below for memmap_init_zone() function. > >>> > >>> mm/page_alloc.c:6259:23: warning: no previous prototype for > >>> 'memmap_init_zone' [-Wmissing-prototypes] > >>> 6259 | void __meminit __weak memmap_init_zone(unsigned long size, int > >>> nid, > >>> | ^~~~ > >>> > >>> Fix it by adding the function declaration in include/linux/mm.h. > >>> Since memmap_init_zone() has a generic version with '__weak', > >>> the declaratoin in ia64 header file can be simply removed. > >>> > >>> Signed-off-by: Baoquan He > >>> Reported-by: kernel test robot > >>> --- > >>> arch/ia64/include/asm/pgtable.h | 5 - > >>> include/linux/mm.h | 1 + > >>> 2 files changed, 1 insertion(+), 5 deletions(-) > >>> > >>> diff --git a/arch/ia64/include/asm/pgtable.h > >>> b/arch/ia64/include/asm/pgtable.h > >>> index 2c81394a2430..9b4efe89e62d 100644 > >>> --- a/arch/ia64/include/asm/pgtable.h > >>> +++ b/arch/ia64/include/asm/pgtable.h > >>> @@ -517,11 +517,6 @@ extern struct page *zero_page_memmap_ptr; > >>> __changed; \ > >>> }) > >>> #endif > >>> - > >>> -# ifdef CONFIG_VIRTUAL_MEM_MAP > >>> - /* arch mem_map init routine is needed due to holes in a virtual > >>> mem_map */ > >>> -extern void memmap_init_zone(struct zone *zone); > >>> -# endif /* CONFIG_VIRTUAL_MEM_MAP */ > >>> # endif /* !__ASSEMBLY__ */ > >>> > >>> /* > >>> diff --git a/include/linux/mm.h b/include/linux/mm.h > >>> index 56bb239f9150..073049bd0b29 100644 > >>> --- a/include/linux/mm.h > >>> +++ b/include/linux/mm.h > >>> @@ -2401,6 +2401,7 @@ extern void set_dma_reserve(unsigned long > >>> new_dma_reserve); > >>> extern void memmap_init_range(unsigned long, int, unsigned long, > >>> unsigned long, unsigned long, enum meminit_context, > >>> struct vmem_altmap *, int migratetype); > >>> +extern void memmap_init_zone(struct zone *zone); > >>> extern void setup_per_zone_wmarks(void); > >>> extern int __meminit init_per_zone_wmark_min(void); > >>> extern void mem_init(void); > >>> > >> > >> This patch is on top of your other series, no? > >> > >> In -next, we have > >> > >> extern void memmap_init_zone(unsigned long, int, unsigned long, ... > >> > >> In that file, so something is wrong. > > > > Right, this one is based on the memmap_init_xx clean up patchset. I > > mentioned this the the sub-thread of kernel test robot reporting issues. > > > > I think it would make things easier to move that fix to the front and > resend the whole (5 patches) series. OK, it's fine to me, will resend a series adding this one in. I also need polish log of this patch. Thanks for looking into this.
Re: [PATCH 2/3] i2c: remove u300 bus driver
On Wed, Jan 20, 2021 at 02:28:33PM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > The ST-Ericsson U300 platform is getting removed, so this driver is no > longer needed. > > Cc: Linus Walleij > Signed-off-by: Arnd Bergmann Applied to for-next, thanks! signature.asc Description: PGP signature
[PATCH v6 1/7] Bluetooth: advmon offload MSFT add rssi support
From: Archie Pusaka
MSFT needs rssi parameter for monitoring advertisement packet,
therefore we should supply them from mgmt. This adds a new opcode
to add advertisement monitor with rssi parameters.
Signed-off-by: Archie Pusaka
Reviewed-by: Manish Mandlik
Reviewed-by: Miao-chen Chou
Reviewed-by: Yun-Hao Chung
---
(no changes since v4)
Changes in v4:
* Change the logic of merging add_adv_patterns_monitor with rssi
* Aligning variable declaration on mgmt.h
Changes in v3:
* Flips the order of rssi and pattern_count on mgmt struct
Changes in v2:
* Add a new opcode instead of modifying an existing one
include/net/bluetooth/hci_core.h | 9 ++
include/net/bluetooth/mgmt.h | 16 +++
net/bluetooth/mgmt.c | 225 +--
3 files changed, 178 insertions(+), 72 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 677a8c50b2ad..8b7cf3620938 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -250,8 +250,17 @@ struct adv_pattern {
__u8 value[HCI_MAX_AD_LENGTH];
};
+struct adv_rssi_thresholds {
+ __s8 low_threshold;
+ __s8 high_threshold;
+ __u16 low_threshold_timeout;
+ __u16 high_threshold_timeout;
+ __u8 sampling_period;
+};
+
struct adv_monitor {
struct list_head patterns;
+ struct adv_rssi_thresholds rssi;
boolactive;
__u16 handle;
};
diff --git a/include/net/bluetooth/mgmt.h b/include/net/bluetooth/mgmt.h
index f9a6638e20b3..839a2028009e 100644
--- a/include/net/bluetooth/mgmt.h
+++ b/include/net/bluetooth/mgmt.h
@@ -821,6 +821,22 @@ struct mgmt_rp_add_ext_adv_data {
__u8instance;
} __packed;
+struct mgmt_adv_rssi_thresholds {
+ __s8high_threshold;
+ __le16 high_threshold_timeout;
+ __s8low_threshold;
+ __le16 low_threshold_timeout;
+ __u8sampling_period;
+} __packed;
+
+#define MGMT_OP_ADD_ADV_PATTERNS_MONITOR_RSSI 0x0056
+struct mgmt_cp_add_adv_patterns_monitor_rssi {
+ struct mgmt_adv_rssi_thresholds rssi;
+ __u8pattern_count;
+ struct mgmt_adv_pattern patterns[];
+} __packed;
+#define MGMT_ADD_ADV_PATTERNS_MONITOR_RSSI_SIZE8
+
#define MGMT_EV_CMD_COMPLETE 0x0001
struct mgmt_ev_cmd_complete {
__le16 opcode;
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 608dda5403b7..72d37c80e071 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -124,6 +124,7 @@ static const u16 mgmt_commands[] = {
MGMT_OP_REMOVE_ADV_MONITOR,
MGMT_OP_ADD_EXT_ADV_PARAMS,
MGMT_OP_ADD_EXT_ADV_DATA,
+ MGMT_OP_ADD_ADV_PATTERNS_MONITOR_RSSI,
};
static const u16 mgmt_events[] = {
@@ -4225,75 +4226,15 @@ static int read_adv_mon_features(struct sock *sk,
struct hci_dev *hdev,
return err;
}
-static int add_adv_patterns_monitor(struct sock *sk, struct hci_dev *hdev,
- void *data, u16 len)
+static int __add_adv_patterns_monitor(struct sock *sk, struct hci_dev *hdev,
+ struct adv_monitor *m, u8 status, u16 op)
{
- struct mgmt_cp_add_adv_patterns_monitor *cp = data;
struct mgmt_rp_add_adv_patterns_monitor rp;
- struct adv_monitor *m = NULL;
- struct adv_pattern *p = NULL;
- unsigned int mp_cnt = 0, prev_adv_monitors_cnt;
- __u8 cp_ofst = 0, cp_len = 0;
- int err, i;
-
- BT_DBG("request for %s", hdev->name);
-
- if (len <= sizeof(*cp) || cp->pattern_count == 0) {
- err = mgmt_cmd_status(sk, hdev->id,
- MGMT_OP_ADD_ADV_PATTERNS_MONITOR,
- MGMT_STATUS_INVALID_PARAMS);
- goto failed;
- }
-
- m = kmalloc(sizeof(*m), GFP_KERNEL);
- if (!m) {
- err = -ENOMEM;
- goto failed;
- }
-
- INIT_LIST_HEAD(&m->patterns);
- m->active = false;
-
- for (i = 0; i < cp->pattern_count; i++) {
- if (++mp_cnt > HCI_MAX_ADV_MONITOR_NUM_PATTERNS) {
- err = mgmt_cmd_status(sk, hdev->id,
- MGMT_OP_ADD_ADV_PATTERNS_MONITOR,
- MGMT_STATUS_INVALID_PARAMS);
- goto failed;
- }
-
- cp_ofst = cp->patterns[i].offset;
- cp_len = cp->patterns[i].length;
- if (cp_ofst >= HCI_MAX_AD_LENGTH ||
- cp_len > HCI_MAX_AD_LENGTH ||
- (cp_ofst + cp_len) > HCI_MAX_AD_LENGTH) {
- err = mgmt_cmd_status(sk, hdev->id,
- MGMT_OP_ADD_ADV_PATTERNS_MONITOR,
- MGMT_STATUS_INVALID_PARAMS);
- goto failed;
- }
-
- p = kmallo
Re: [PATCH 3/5] Add manpage for fspick(2)
Hello David, Ping! Thanks, Michael On Mon, 24 Aug 2020 at 14:25, David Howells wrote: > > Add a manual page to document the fspick() system call. > > Signed-off-by: David Howells > --- > > man2/fspick.2 | 180 > + > 1 file changed, 180 insertions(+) > create mode 100644 man2/fspick.2 > > diff --git a/man2/fspick.2 b/man2/fspick.2 > new file mode 100644 > index 0..72bf645dd > --- /dev/null > +++ b/man2/fspick.2 > @@ -0,0 +1,180 @@ > +'\" t > +.\" Copyright (c) 2020 David Howells > +.\" > +.\" %%%LICENSE_START(VERBATIM) > +.\" Permission is granted to make and distribute verbatim copies of this > +.\" manual provided the copyright notice and this permission notice are > +.\" preserved on all copies. > +.\" > +.\" Permission is granted to copy and distribute modified versions of this > +.\" manual under the conditions for verbatim copying, provided that the > +.\" entire resulting derived work is distributed under the terms of a > +.\" permission notice identical to this one. > +.\" > +.\" Since the Linux kernel and libraries are constantly changing, this > +.\" manual page may be incorrect or out-of-date. The author(s) assume no > +.\" responsibility for errors or omissions, or for damages resulting from > +.\" the use of the information contained herein. The author(s) may not > +.\" have taken the same level of care in the production of this manual, > +.\" which is licensed free of charge, as they might when working > +.\" professionally. > +.\" > +.\" Formatted or processed versions of this manual, if unaccompanied by > +.\" the source, must acknowledge the copyright and authors of this work. > +.\" %%%LICENSE_END > +.\" > +.TH FSPICK 2 2020-08-24 "Linux" "Linux Programmer's Manual" > +.SH NAME > +fspick \- Select filesystem for reconfiguration > +.SH SYNOPSIS > +.nf > +.B #include > +.B #include > +.B #include > +.BR "#include" "/* Definition of AT_* constants */" > +.PP > +.BI "int fspick(int " dirfd ", const char *" pathname ", unsigned int " > flags ); > +.fi > +.PP > +.IR Note : > +There is no glibc wrapper for this system call. > +.SH DESCRIPTION > +.PP > +.BR fspick () > +creates a new filesystem configuration context within the kernel and > attaches a > +pre-existing superblock to it so that it can be reconfigured (similar to > +.BR mount (8) > +with the "-o remount" option). The configuration context is marked as being > in > +reconfiguration mode and attached to a file descriptor, which is returned to > +the caller. The file descriptor can be marked close-on-exec by setting > +.B FSPICK_CLOEXEC > +in > +.IR flags . > +.PP > +The target is whichever superblock backs the object determined by > +.IR dfd ", " pathname " and " flags . > +The following can be set in > +.I flags > +to control the pathwalk to that object: > +.TP > +.B FSPICK_SYMLINK_NOFOLLOW > +Don't follow symbolic links in the final component of the path. > +.TP > +.B FSPICK_NO_AUTOMOUNT > +Don't follow automounts in the final component of the path. > +.TP > +.B FSPICK_EMPTY_PATH > +Allow an empty string to be specified as the pathname. This allows > +.I dirfd > +to specify the target mount exactly. > +.PP > +After calling fspick(), the file descriptor should be passed to the > +.BR fsconfig (2) > +system call, using that to specify the desired changes to filesystem and > +security parameters. > +.PP > +When the parameters are all set, the > +.BR fsconfig () > +system call should then be called again with > +.B FSCONFIG_CMD_RECONFIGURE > +as the command argument to effect the reconfiguration. > +.PP > +After the reconfiguration has taken place, the context is wiped clean (apart > +from the superblock attachment, which remains) and can be reused to make > +another reconfiguration. > +.PP > +The file descriptor also serves as a channel by which more comprehensive > error, > +warning and information messages may be retrieved from the kernel using > +.BR read (2). > +.SS Message Retrieval Interface > +The context file descriptor may be queried for message strings at any time by > +calling > +.BR read (2) > +on the file descriptor. This will return formatted messages that are > prefixed > +to indicate their class: > +.TP > +\fB"e "\fP > +An error message string was logged. > +.TP > +\fB"i "\fP > +An informational message string was logged. > +.TP > +\fB"w "\fP > +An warning message string was logged. > +.PP > +Messages are removed from the queue as they're read and the queue has a > limited > +depth of 8 messages, so it's possible for some to get lost. > +.SH RETURN VALUE > +On success, the function returns a file descriptor. On error, \-1 is > returned, > +and > +.I errno > +is set appropriately. > +.SH ERRORS > +The error values given below result from filesystem type independent errors. > +Additionally, each filesystem type may have its own special errors and its > own > +special behavior. See the Linux kernel source code for details
Re: [PATCH v1 2/2] isa: Make the remove callback for isa drivers return void
On Thu, 21 Jan 2021 21:48:12 +0100, Uwe Kleine-König wrote: > > The driver core ignores the return value of the remove callback, so > don't give isa drivers the chance to provide a value. > > Adapt all isa_drivers with a remove callbacks accordingly; they all > return 0 unconditionally anyhow. > > Signed-off-by: Uwe Kleine-König For the sound/* changes: Reviewed-by: Takashi Iwai BTW, how will we take the patches? Judging from the LOCs, sound/* are mostly affected, so I may merge them via sound.git tree, if other people have no objection. thanks, Takashi
Re: [PATCH v3] i2c: ismt: Use dma_set_mask_and_coherent
On Thu, Dec 03, 2020 at 02:50:52PM +0800, Youling Tang wrote:
> 'pci_set_dma_mask()' + 'pci_set_consistent_dma_mask()' can be replaced by
> an equivalent 'dma_set_mask_and_coherent()' which is much less verbose.
>
> Reported-by: kernel test robot
> Signed-off-by: Youling Tang
Seth, Neil, are you OK with this patch?
> ---
>
> v3: Fix build errors of incompatible pointer types.
>
> drivers/i2c/busses/i2c-ismt.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-ismt.c b/drivers/i2c/busses/i2c-ismt.c
> index a35a27c..88f6039 100644
> --- a/drivers/i2c/busses/i2c-ismt.c
> +++ b/drivers/i2c/busses/i2c-ismt.c
> @@ -903,16 +903,12 @@ ismt_probe(struct pci_dev *pdev, const struct
> pci_device_id *id)
> return -ENODEV;
> }
>
> - if ((pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) != 0) ||
> - (pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64)) != 0)) {
> - if ((pci_set_dma_mask(pdev, DMA_BIT_MASK(32)) != 0) ||
> - (pci_set_consistent_dma_mask(pdev,
> - DMA_BIT_MASK(32)) != 0)) {
> - dev_err(&pdev->dev, "pci_set_dma_mask fail %p\n",
> + if (dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)) != 0)
> + if (dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32)) !=
> 0) {
> + dev_err(&pdev->dev, "dma_set_mask_and_coherent fail
> %p\n",
> pdev);
> return -ENODEV;
> }
> - }
>
> err = ismt_dev_init(priv);
> if (err)
> --
> 2.1.0
>
signature.asc
Description: PGP signature
Re: [PATCH] mm: fix prototype warning from kernel test robot
On 22.01.21 09:58, Baoquan He wrote: > On 01/22/21 at 09:55am, David Hildenbrand wrote: >> On 22.01.21 09:46, Baoquan He wrote: >>> On 01/22/21 at 09:40am, David Hildenbrand wrote: On 22.01.21 08:03, Baoquan He wrote: > Kernel test robot calling make with 'W=1' triggering warning like below > below for memmap_init_zone() function. > > mm/page_alloc.c:6259:23: warning: no previous prototype for > 'memmap_init_zone' [-Wmissing-prototypes] > 6259 | void __meminit __weak memmap_init_zone(unsigned long size, int > nid, > | ^~~~ > > Fix it by adding the function declaration in include/linux/mm.h. > Since memmap_init_zone() has a generic version with '__weak', > the declaratoin in ia64 header file can be simply removed. > > Signed-off-by: Baoquan He > Reported-by: kernel test robot > --- > arch/ia64/include/asm/pgtable.h | 5 - > include/linux/mm.h | 1 + > 2 files changed, 1 insertion(+), 5 deletions(-) > > diff --git a/arch/ia64/include/asm/pgtable.h > b/arch/ia64/include/asm/pgtable.h > index 2c81394a2430..9b4efe89e62d 100644 > --- a/arch/ia64/include/asm/pgtable.h > +++ b/arch/ia64/include/asm/pgtable.h > @@ -517,11 +517,6 @@ extern struct page *zero_page_memmap_ptr; > __changed; \ > }) > #endif > - > -# ifdef CONFIG_VIRTUAL_MEM_MAP > - /* arch mem_map init routine is needed due to holes in a virtual > mem_map */ > -extern void memmap_init_zone(struct zone *zone); > -# endif /* CONFIG_VIRTUAL_MEM_MAP */ > # endif /* !__ASSEMBLY__ */ > > /* > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 56bb239f9150..073049bd0b29 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -2401,6 +2401,7 @@ extern void set_dma_reserve(unsigned long > new_dma_reserve); > extern void memmap_init_range(unsigned long, int, unsigned long, > unsigned long, unsigned long, enum meminit_context, > struct vmem_altmap *, int migratetype); > +extern void memmap_init_zone(struct zone *zone); > extern void setup_per_zone_wmarks(void); > extern int __meminit init_per_zone_wmark_min(void); > extern void mem_init(void); > This patch is on top of your other series, no? In -next, we have extern void memmap_init_zone(unsigned long, int, unsigned long, ... In that file, so something is wrong. >>> >>> Right, this one is based on the memmap_init_xx clean up patchset. I >>> mentioned this the the sub-thread of kernel test robot reporting issues. >>> >> >> I think it would make things easier to move that fix to the front and >> resend the whole (5 patches) series. > > OK, it's fine to me, will resend a series adding this one in. I also > need polish log of this patch. Thanks for looking into this. > I'll review ASAP once you resend :) -- Thanks, David / dhildenb
[GIT PULL] platform-drivers-x86 for 5.11-2
Hi Linus, Here is a set of small, straight-forward fixes and some model specific quirks for platform-drivers-x86 for 5.11. Regards, Hans The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git tags/platform-drivers-x86-v5.11-2 for you to fetch changes up to 173aac2fef96972e42d33c0e1189e6f756a0d719: platform/x86: thinkpad_acpi: Add P53/73 firmware to fan_quirk_table for dual fan control (2021-01-18 21:42:01 +0100) platform-drivers-x86 for v5.11-2 A small collection of bug-fixes and model-specific quirks for 5.11. The following is an automated git shortlog grouped by driver: amd-pmc: - Fix CONFIG_DEBUG_FS check hp-wmi: - Don't log a warning on HPWMI_RET_UNKNOWN_COMMAND errors i2c-multi-instantiate: - Don't create platform device for INT3515 ACPI nodes ideapad-laptop: - Disable touchpad_switch for ELAN0634 intel-vbtn: - Drop HP Stream x360 Convertible PC 11 from allow-list - Support for tablet mode on Dell Inspiron 7352 platform/surface: - SURFACE_PLATFORMS should depend on ACPI - surface_gpe: Fix non-PM_SLEEP build warnings thinkpad_acpi: - Add P53/73 firmware to fan_quirk_table for dual fan control - correct palmsensor error checking tools/power/x86/intel-speed-select: - Set higher of cpuinfo_max_freq or base_frequency - Set scaling_max_freq to base_frequency touchscreen_dmi: - Add swap-x-y quirk for Goodix touchscreen on Estar Beauty HD tablet Arnold Gozum (1): platform/x86: intel-vbtn: Support for tablet mode on Dell Inspiron 7352 Geert Uytterhoeven (1): platform/surface: SURFACE_PLATFORMS should depend on ACPI Hans de Goede (3): platform/x86: touchscreen_dmi: Add swap-x-y quirk for Goodix touchscreen on Estar Beauty HD tablet platform/x86: intel-vbtn: Drop HP Stream x360 Convertible PC 11 from allow-list platform/x86: hp-wmi: Don't log a warning on HPWMI_RET_UNKNOWN_COMMAND errors Heikki Krogerus (1): platform/x86: i2c-multi-instantiate: Don't create platform device for INT3515 ACPI nodes Jeannie Stevenson (1): platform/x86: thinkpad_acpi: Add P53/73 firmware to fan_quirk_table for dual fan control Jiaxun Yang (1): platform/x86: ideapad-laptop: Disable touchpad_switch for ELAN0634 Mark Pearson (1): platform/x86: thinkpad_acpi: correct palmsensor error checking Randy Dunlap (1): platform/surface: surface_gpe: Fix non-PM_SLEEP build warnings Shyam Sundar S K (1): platform/x86: amd-pmc: Fix CONFIG_DEBUG_FS check Srinivas Pandruvada (2): tools/power/x86/intel-speed-select: Set scaling_max_freq to base_frequency tools/power/x86/intel-speed-select: Set higher of cpuinfo_max_freq or base_frequency drivers/platform/surface/Kconfig | 8 +++--- drivers/platform/surface/surface_gpe.c | 4 +-- drivers/platform/x86/amd-pmc.c | 2 +- drivers/platform/x86/hp-wmi.c| 3 ++- drivers/platform/x86/i2c-multi-instantiate.c | 31 +-- drivers/platform/x86/ideapad-laptop.c| 15 ++- drivers/platform/x86/intel-vbtn.c| 10 drivers/platform/x86/thinkpad_acpi.c | 5 ++-- drivers/platform/x86/touchscreen_dmi.c | 18 + tools/power/x86/intel-speed-select/isst-config.c | 32 10 files changed, 104 insertions(+), 24 deletions(-)
Re: [PATCH 0/8] i2c: improve RECV_LEN documentation & usage
On Sat, Jan 09, 2021 at 01:43:04PM +0100, Wolfram Sang wrote: > Because I want to clarify I2C_M_RECV len usage, this series updates the > documentation and some of its users. Patch 1 refactors the whole > documentation of 'i2c_msg', so all usage of I2C_M_* flags and their > conditions hopefully become clearer. Patch 2+3 remove some obvious > boilerplate in the UAPI headers while here. Patch 4 is a driver fix I > found while working on this series. Patch 5 introduces a new convenience > macro to enable SMBus transfers which need I2C_M_RECV_LEN. Then, some > drivers use the new macro, sometimes to remove boilerplate, sometimes > because these SMBus transfers have been forgotten before. > > This series is the first part of a larger work to extend I2C_M_RECV_LEN > to allow larger transfer sizes (as specified in the SMBus 3.0 standard) > and to enable this on Renesas R-Car hardware. > > Looking forward to comments and/or reviews; the driver patches are only > build-tested. > > Happy hacking, > >Wolfram > > > Wolfram Sang (8): > i2c: refactor documentation of struct i2c_msg > i2c: remove licence boilerplate from main UAPI header > i2c: remove licence boilerplate from i2c-dev UAPI header > i2c: octeon: check correct size of maximum RECV_LEN packet > i2c: uapi: add macro to describe support for all SMBus transfers > i2c: algo: bit: use new macro to specifiy capabilities > i2c: qup: advertise SMBus transfers using RECV_LEN > i2c: s3c2410: advertise SMBus transfers using RECV_LEN > > drivers/i2c/algos/i2c-algo-bit.c | 4 +- > drivers/i2c/busses/i2c-octeon-core.c | 2 +- > drivers/i2c/busses/i2c-qup.c | 2 +- > drivers/i2c/busses/i2c-s3c2410.c | 2 +- Applied to for-next, thanks! signature.asc Description: PGP signature
Re: [PATCH] net: macb: ignore tx_clk if MII is used
On 21.01.2021 11:41, Michael Walle wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > Hi Claudiu, > > Am 2021-01-21 10:19, schrieb claudiu.bez...@microchip.com: >> On 20.01.2021 21:43, Michael Walle wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know >>> the content is safe >>> >>> If the MII interface is used, the PHY is the clock master, thus don't >>> set the clock rate. On Zynq-7000, this will prevent the following >>> warning: >>> macb e000b000.ethernet eth0: unable to generate target frequency: >>> 2500 Hz >>> >> >> Since in this case the PHY provides the TX clock and it provides the >> proper >> rate based on link speed, the MACB driver should not handle the >> bp->tx_clk >> at all (MACB driver uses this clock only for setting the proper rate on >> it >> based on link speed). So, I believe the proper fix would be to not pass >> the >> tx_clk at all in device tree. This clock is optional for MACB driver. > > Thanks for looking into this. > > I had the same thought. But shouldn't the driver handle this case > gracefully? > I mean it does know that the clock isn't needed at all. Currently it may knows that by checking the bp->tx_clk. Moreover the clock could be provided by PHY not only for MII interface. Moreover the IP has the bit "refclk" of register at offset 0xc (userio) that tells it to use the clock provided by PHY or to use one internal to the SoC. If a SoC generated clock would be used the IP logic may have the option to do the proper division based on link speed (if IP has this option enabled then this should be selected in driver with capability MACB_CAPS_CLK_HW_CHG). If the clock provided by the PHY is the one to be used then this is selected with capability MACB_CAPS_USRIO_HAS_CLKEN. So, if the change you proposed in this patch is still imperative then checking for this capability would be the best as the clock could be provided by PHY not only for MII interface. > Ususually that > clock > is defined in a device tree include. So you'd have to redefine that node > in > an actual board file which means duplicating the other clocks. > > -michael
[PATCH] scsi: bfa: remove redundant NULL check
Fix below warnings reported by coccicheck:
./drivers/scsi/bfa/bfad_debugfs.c:375:2-7: WARNING: NULL check before
some freeing functions is not needed.
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/scsi/bfa/bfad_debugfs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/bfa/bfad_debugfs.c b/drivers/scsi/bfa/bfad_debugfs.c
index fd1b378..52db147 100644
--- a/drivers/scsi/bfa/bfad_debugfs.c
+++ b/drivers/scsi/bfa/bfad_debugfs.c
@@ -371,8 +371,7 @@ struct bfad_debug_info {
if (!fw_debug)
return 0;
- if (fw_debug->debug_buffer)
- vfree(fw_debug->debug_buffer);
+ vfree(fw_debug->debug_buffer);
file->private_data = NULL;
kfree(fw_debug);
--
1.8.3.1
[PATCH 2/2] scsi: qla4xxx: remove redundant NULL check
Fix below warnings reported by coccicheck: ./drivers/scsi/qla4xxx/ql4_os.c:4171:2-7: WARNING: NULL check before some freeing functions is not needed. ./drivers/scsi/qla4xxx/ql4_os.c:4192:2-7: WARNING: NULL check before some freeing functions is not needed. ./drivers/scsi/qla4xxx/ql4_os.c:4211:2-7: WARNING: NULL check before some freeing functions is not needed. ./drivers/scsi/qla4xxx/ql4_os.c:6396:2-7: WARNING: NULL check before some freeing functions is not needed. ./drivers/scsi/qla4xxx/ql4_os.c:6551:2-7: WARNING: NULL check before some freeing functions is not needed. ./drivers/scsi/qla4xxx/ql4_os.c:7840:2-7: WARNING: NULL check before some freeing functions is not needed. Reported-by: Abaci Robot Signed-off-by: Yang Li --- drivers/scsi/qla4xxx/ql4_os.c | 27 +-- 1 file changed, 9 insertions(+), 18 deletions(-) diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c index a4b014e..73b89fd 100644 --- a/drivers/scsi/qla4xxx/ql4_os.c +++ b/drivers/scsi/qla4xxx/ql4_os.c @@ -4171,8 +4171,7 @@ static void qla4xxx_mem_free(struct scsi_qla_host *ha) dma_free_coherent(&ha->pdev->dev, ha->queues_len, ha->queues, ha->queues_dma); - if (ha->fw_dump) - vfree(ha->fw_dump); + vfree(ha->fw_dump); ha->queues_len = 0; ha->queues = NULL; @@ -4192,8 +4191,7 @@ static void qla4xxx_mem_free(struct scsi_qla_host *ha) dma_pool_destroy(ha->chap_dma_pool); - if (ha->chap_list) - vfree(ha->chap_list); + vfree(ha->chap_list); ha->chap_list = NULL; dma_pool_destroy(ha->fw_ddb_dma_pool); @@ -4211,8 +4209,7 @@ static void qla4xxx_mem_free(struct scsi_qla_host *ha) iounmap(ha->reg); } - if (ha->reset_tmplt.buff) - vfree(ha->reset_tmplt.buff); + vfree(ha->reset_tmplt.buff); pci_release_regions(ha->pdev); } @@ -6396,10 +6393,8 @@ static int qla4xxx_is_session_exists(struct scsi_qla_host *ha, } exit_check: - if (fw_tddb) - vfree(fw_tddb); - if (tmp_tddb) - vfree(tmp_tddb); + vfree(fw_tddb); + vfree(tmp_tddb); return ret; } @@ -6551,10 +6546,8 @@ static int qla4xxx_is_flash_ddb_exists(struct scsi_qla_host *ha, } exit_check: - if (fw_tddb) - vfree(fw_tddb); - if (tmp_tddb) - vfree(tmp_tddb); + vfree(fw_tddb); + vfree(tmp_tddb); return ret; } @@ -7834,10 +7827,8 @@ static int qla4xxx_sysfs_ddb_logout(struct iscsi_bus_flash_session *fnode_sess, ret = -ESRCH; exit_ddb_logout: - if (flash_tddb) - vfree(flash_tddb); - if (tmp_tddb) - vfree(tmp_tddb); + vfree(flash_tddb); + vfree(tmp_tddb); if (fw_ddb_entry) dma_pool_free(ha->fw_ddb_dma_pool, fw_ddb_entry, fw_ddb_dma); -- 1.8.3.1
Re: [RFC V2 2/2] cpufreq: cppc: Add support for frequency invariance
On 19-01-21, 19:17, Ionela Voinescu wrote:
> Hi,
>
> Do you know of a current platform that would benefit from this, that we
> could run some tests on?
Thunderx2 is one.
> On Tuesday 15 Dec 2020 at 16:46:36 (+0530), Viresh Kumar wrote:
> > @@ -243,7 +256,7 @@ static int cppc_cpufreq_cpu_init(struct cpufreq_policy
> > *policy)
> > struct cppc_cpudata *cpu_data = all_cpu_data[policy->cpu];
> > struct cppc_perf_caps *caps = &cpu_data->perf_caps;
> > unsigned int cpu = policy->cpu;
> > - int ret = 0;
> > + int ret = 0, i;
> >
> > cpu_data->cpu = cpu;
> > ret = cppc_get_perf_caps(cpu, caps);
> > @@ -300,6 +313,9 @@ static int cppc_cpufreq_cpu_init(struct cpufreq_policy
> > *policy)
> >
> > cpu_data->cur_policy = policy;
> >
> > + for_each_cpu(i, policy->cpus)
> > + per_cpu(cppc_f_i, i).max_freq = policy->cpuinfo.max_freq;
> > +
>
> Is policy->cpuinfo populated at this point?
The base has changed since the time I posted the patch, but yes this
routine itself updates min/max freq in cpuinfo at an earlier point.
> > +static void cppc_scale_freq_tick_workfn(struct kthread_work *work)
> > +{
> > + struct cppc_freq_invariance *cppc_fi;
> > + struct cppc_perf_fb_ctrs fb_ctrs = {0};
> > + int cpu = raw_smp_processor_id();
> > + struct cppc_cpudata *cpudata = all_cpu_data[cpu];
> > + u64 rate;
> > +
> > + cppc_fi = container_of(work, struct cppc_freq_invariance, work);
> > +
> > + if (cppc_get_perf_ctrs(cpu, &fb_ctrs)) {
> > + pr_info("%s: cppc_get_perf_ctrs() failed\n", __func__);
> > + return;
> > + }
> > +
> > + rate = cppc_get_rate_from_fbctrs(cpudata, cppc_fi->prev_perf_fb_ctrs,
> > fb_ctrs);
> > + cppc_fi->prev_perf_fb_ctrs = fb_ctrs;
> > +
> > + rate <<= SCHED_CAPACITY_SHIFT;
> > + per_cpu(freq_scale, cpu) = div64_u64(rate, cppc_fi->max_freq);
>
> It will save you some computation by skipping the intermediary frequency
> scale transition. For this computation you're obtaining current
> performance from counters, on the CPPC abstract performance scale,
> then you're converting it to a current frequency, which then gets
> translated again to a scale factor on the [0,1024] scale.
>
> You probably want to keep the sanitation done in
> cppc_get_rate_from_fbctrs() on the counter values, but you could skip
> the call to cppc_cpufreq_perf_to_khz(), and use obtained performance
> together with caps->highest_perf, or caps->nominal_perf instead of
> cppc_fi->max_freq, in this function.
Something like this ?
diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
index 0d7a950f3c9f..d4d7fb0dc918 100644
--- a/drivers/cpufreq/cppc_cpufreq.c
+++ b/drivers/cpufreq/cppc_cpufreq.c
@@ -389,9 +389,9 @@ static inline u64 get_delta(u64 t1, u64 t0)
return (u32)t1 - (u32)t0;
}
-static int cppc_get_rate_from_fbctrs(struct cppc_cpudata *cpu_data,
-struct cppc_perf_fb_ctrs fb_ctrs_t0,
-struct cppc_perf_fb_ctrs fb_ctrs_t1)
+static int cppc_perf_from_fbctrs(struct cppc_cpudata *cpu_data,
+struct cppc_perf_fb_ctrs fb_ctrs_t0,
+struct cppc_perf_fb_ctrs fb_ctrs_t1)
{
u64 delta_reference, delta_delivered;
u64 reference_perf, delivered_perf;
@@ -404,11 +404,20 @@ static int cppc_get_rate_from_fbctrs(struct cppc_cpudata
*cpu_data,
fb_ctrs_t0.delivered);
/* Check to avoid divide-by zero */
- if (delta_reference || delta_delivered)
- delivered_perf = (reference_perf * delta_delivered) /
- delta_reference;
- else
- delivered_perf = cpu_data->perf_ctrls.desired_perf;
+ if (!delta_reference && !delta_delivered)
+ return cpu_data->perf_ctrls.desired_perf;
+
+ return (reference_perf * delta_delivered) / delta_reference;
+}
+
+static int cppc_get_rate_from_fbctrs(struct cppc_cpudata *cpu_data,
+struct cppc_perf_fb_ctrs fb_ctrs_t0,
+struct cppc_perf_fb_ctrs fb_ctrs_t1)
+{
+ u64 delivered_perf;
+
+ delivered_perf = cppc_perf_from_fbctrs(cpu_data, fb_ctrs_t0,
+ fb_ctrs_t1);
return cppc_cpufreq_perf_to_khz(cpu_data, delivered_perf);
}
@@ -539,21 +548,23 @@ static void cppc_scale_freq_workfn(struct kthread_work
*work)
struct cppc_freq_invariance *cppc_fi;
struct cppc_perf_fb_ctrs fb_ctrs = {0};
int cpu = raw_smp_processor_id();
- u64 rate;
+ struct cppc_cpudata *cpu_data;
+ u64 perf;
cppc_fi = container_of(work, struct cppc_freq_invariance, work);
+ cpu_data = cppc_fi->cpu_data;
if (cppc_get_perf_ctrs(cpu, &fb_ctrs)) {
pr_info("%s: cppc_get_perf_ctrs() failed\n", __func__);
return;
}
[PATCH 1/2] scsi: qla2xxx: remove redundant NULL check
Fix below warnings reported by coccicheck:
./drivers/scsi/qla2xxx/qla_init.c:3371:2-7: WARNING: NULL check before
some freeing functions is not needed.
./drivers/scsi/qla2xxx/qla_init.c:7855:5-10: WARNING: NULL check before
some freeing functions is not needed.
./drivers/scsi/qla2xxx/qla_init.c:7916:2-7: WARNING: NULL check before
some freeing functions is not needed.
./drivers/scsi/qla2xxx/qla_init.c:8113:4-18: WARNING: NULL check before
some freeing functions is not needed.
./drivers/scsi/qla2xxx/qla_init.c:8174:2-7: WARNING: NULL check before
some freeing functions is not needed.
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/scsi/qla2xxx/qla_init.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index dcc0f0d8..edd5dd1 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -3371,8 +3371,7 @@ static void qla2x00_tmf_sp_done(srb_t *sp, int res)
"Re-Allocated (%d KB) and save firmware
dump.\n",
dump_size / 1024);
} else {
- if (ha->fw_dump)
- vfree(ha->fw_dump);
+ vfree(ha->fw_dump);
ha->fw_dump = fw_dump;
ha->fw_dump_len = ha->fw_dump_alloc_len =
@@ -7855,8 +7854,7 @@ bool qla24xx_risc_firmware_invalid(uint32_t *dword)
templates = (risc_attr & BIT_9) ? 2 : 1;
ql_dbg(ql_dbg_init, vha, 0x0160, "-> templates = %u\n", templates);
for (j = 0; j < templates; j++, fwdt++) {
- if (fwdt->template)
- vfree(fwdt->template);
+ vfree(fwdt->template);
fwdt->template = NULL;
fwdt->length = 0;
@@ -7916,8 +7914,7 @@ bool qla24xx_risc_firmware_invalid(uint32_t *dword)
return QLA_SUCCESS;
failed:
- if (fwdt->template)
- vfree(fwdt->template);
+ vfree(fwdt->template);
fwdt->template = NULL;
fwdt->length = 0;
@@ -8113,8 +8110,7 @@ bool qla24xx_risc_firmware_invalid(uint32_t *dword)
templates = (risc_attr & BIT_9) ? 2 : 1;
ql_dbg(ql_dbg_init, vha, 0x0170, "-> templates = %u\n", templates);
for (j = 0; j < templates; j++, fwdt++) {
- if (fwdt->template)
- vfree(fwdt->template);
+ vfree(fwdt->template);
fwdt->template = NULL;
fwdt->length = 0;
@@ -8174,8 +8170,7 @@ bool qla24xx_risc_firmware_invalid(uint32_t *dword)
return QLA_SUCCESS;
failed:
- if (fwdt->template)
- vfree(fwdt->template);
+ vfree(fwdt->template);
fwdt->template = NULL;
fwdt->length = 0;
--
1.8.3.1
[PATCH 1/2] scsi: qla2xxx: remove redundant NULL check
Fix below warnings reported by coccicheck:
./drivers/scsi/qla2xxx/qla_init.c:3371:2-7: WARNING: NULL check before
some freeing functions is not needed.
./drivers/scsi/qla2xxx/qla_init.c:7855:5-10: WARNING: NULL check before
some freeing functions is not needed.
./drivers/scsi/qla2xxx/qla_init.c:7916:2-7: WARNING: NULL check before
some freeing functions is not needed.
./drivers/scsi/qla2xxx/qla_init.c:8113:4-18: WARNING: NULL check before
some freeing functions is not needed.
./drivers/scsi/qla2xxx/qla_init.c:8174:2-7: WARNING: NULL check before
some freeing functions is not needed.
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/scsi/qla2xxx/qla_init.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index dcc0f0d8..edd5dd1 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -3371,8 +3371,7 @@ static void qla2x00_tmf_sp_done(srb_t *sp, int res)
"Re-Allocated (%d KB) and save firmware
dump.\n",
dump_size / 1024);
} else {
- if (ha->fw_dump)
- vfree(ha->fw_dump);
+ vfree(ha->fw_dump);
ha->fw_dump = fw_dump;
ha->fw_dump_len = ha->fw_dump_alloc_len =
@@ -7855,8 +7854,7 @@ bool qla24xx_risc_firmware_invalid(uint32_t *dword)
templates = (risc_attr & BIT_9) ? 2 : 1;
ql_dbg(ql_dbg_init, vha, 0x0160, "-> templates = %u\n", templates);
for (j = 0; j < templates; j++, fwdt++) {
- if (fwdt->template)
- vfree(fwdt->template);
+ vfree(fwdt->template);
fwdt->template = NULL;
fwdt->length = 0;
@@ -7916,8 +7914,7 @@ bool qla24xx_risc_firmware_invalid(uint32_t *dword)
return QLA_SUCCESS;
failed:
- if (fwdt->template)
- vfree(fwdt->template);
+ vfree(fwdt->template);
fwdt->template = NULL;
fwdt->length = 0;
@@ -8113,8 +8110,7 @@ bool qla24xx_risc_firmware_invalid(uint32_t *dword)
templates = (risc_attr & BIT_9) ? 2 : 1;
ql_dbg(ql_dbg_init, vha, 0x0170, "-> templates = %u\n", templates);
for (j = 0; j < templates; j++, fwdt++) {
- if (fwdt->template)
- vfree(fwdt->template);
+ vfree(fwdt->template);
fwdt->template = NULL;
fwdt->length = 0;
@@ -8174,8 +8170,7 @@ bool qla24xx_risc_firmware_invalid(uint32_t *dword)
return QLA_SUCCESS;
failed:
- if (fwdt->template)
- vfree(fwdt->template);
+ vfree(fwdt->template);
fwdt->template = NULL;
fwdt->length = 0;
--
1.8.3.1
[PATCH 2/2] scsi: qla4xxx: remove redundant NULL check
Fix below warnings reported by coccicheck: ./drivers/scsi/qla4xxx/ql4_os.c:4171:2-7: WARNING: NULL check before some freeing functions is not needed. ./drivers/scsi/qla4xxx/ql4_os.c:4192:2-7: WARNING: NULL check before some freeing functions is not needed. ./drivers/scsi/qla4xxx/ql4_os.c:4211:2-7: WARNING: NULL check before some freeing functions is not needed. ./drivers/scsi/qla4xxx/ql4_os.c:6396:2-7: WARNING: NULL check before some freeing functions is not needed. ./drivers/scsi/qla4xxx/ql4_os.c:6551:2-7: WARNING: NULL check before some freeing functions is not needed. ./drivers/scsi/qla4xxx/ql4_os.c:7840:2-7: WARNING: NULL check before some freeing functions is not needed. Reported-by: Abaci Robot Signed-off-by: Yang Li --- drivers/scsi/qla4xxx/ql4_os.c | 27 +-- 1 file changed, 9 insertions(+), 18 deletions(-) diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c index a4b014e..73b89fd 100644 --- a/drivers/scsi/qla4xxx/ql4_os.c +++ b/drivers/scsi/qla4xxx/ql4_os.c @@ -4171,8 +4171,7 @@ static void qla4xxx_mem_free(struct scsi_qla_host *ha) dma_free_coherent(&ha->pdev->dev, ha->queues_len, ha->queues, ha->queues_dma); - if (ha->fw_dump) - vfree(ha->fw_dump); + vfree(ha->fw_dump); ha->queues_len = 0; ha->queues = NULL; @@ -4192,8 +4191,7 @@ static void qla4xxx_mem_free(struct scsi_qla_host *ha) dma_pool_destroy(ha->chap_dma_pool); - if (ha->chap_list) - vfree(ha->chap_list); + vfree(ha->chap_list); ha->chap_list = NULL; dma_pool_destroy(ha->fw_ddb_dma_pool); @@ -4211,8 +4209,7 @@ static void qla4xxx_mem_free(struct scsi_qla_host *ha) iounmap(ha->reg); } - if (ha->reset_tmplt.buff) - vfree(ha->reset_tmplt.buff); + vfree(ha->reset_tmplt.buff); pci_release_regions(ha->pdev); } @@ -6396,10 +6393,8 @@ static int qla4xxx_is_session_exists(struct scsi_qla_host *ha, } exit_check: - if (fw_tddb) - vfree(fw_tddb); - if (tmp_tddb) - vfree(tmp_tddb); + vfree(fw_tddb); + vfree(tmp_tddb); return ret; } @@ -6551,10 +6546,8 @@ static int qla4xxx_is_flash_ddb_exists(struct scsi_qla_host *ha, } exit_check: - if (fw_tddb) - vfree(fw_tddb); - if (tmp_tddb) - vfree(tmp_tddb); + vfree(fw_tddb); + vfree(tmp_tddb); return ret; } @@ -7834,10 +7827,8 @@ static int qla4xxx_sysfs_ddb_logout(struct iscsi_bus_flash_session *fnode_sess, ret = -ESRCH; exit_ddb_logout: - if (flash_tddb) - vfree(flash_tddb); - if (tmp_tddb) - vfree(tmp_tddb); + vfree(flash_tddb); + vfree(tmp_tddb); if (fw_ddb_entry) dma_pool_free(ha->fw_ddb_dma_pool, fw_ddb_entry, fw_ddb_dma); -- 1.8.3.1
Re: BUG: MAX_LOCKDEP_KEYS too low!
On Fri, Jan 22, 2021 at 4:43 AM Alexey Kardashevskiy wrote:
>
> Hi!
>
> Syzkaller found this bug and it has a repro (below). I googled a similar
> bug in 2019 which was fixed so this seems new.
>
> The repro takes about a half a minute to produce the message, "grep
> lock-classes /proc/lockdep_stats" reports 8177 of 8192, before running
> the repro it is 702. It is a POWER8 box.
>
> The offender is htab->lockdep_key. If I run repro at the slow rate, no
> problems appears, traces show lockdep_unregister_key() is called and the
> leak is quite slow.
>
> Is this something known? Any hints how to debug this further? I'd give
> it a try since I have an easy reproducer. Thanks,
+netdev as it discusses net namespaces as well
Hi Alexey,
The reproducer only does 2 bpf syscalls, so something is slowly leaking in bpf.
My first suspect would be one of these. Since workqueue is async, it
may cause such slow drain that happens only when tasks are spawned
fast. I don't know if there is a procfs/debugfs introspection file to
monitor workqueue lengths to verify this hypothesis.
$ grep INIT_WORK kernel/bpf/*.c
kernel/bpf/arraymap.c: INIT_WORK(&aux->work, prog_array_map_clear_deferred);
kernel/bpf/cgroup.c: INIT_WORK(&cgrp->bpf.release_work, cgroup_bpf_release);
kernel/bpf/core.c: INIT_WORK(&aux->work, bpf_prog_free_deferred);
kernel/bpf/cpumap.c: INIT_WORK(&old_rcpu->kthread_stop_wq,
cpu_map_kthread_stop);
kernel/bpf/syscall.c: INIT_WORK(&map->work, bpf_map_free_deferred);
kernel/bpf/syscall.c: INIT_WORK(&link->work, bpf_link_put_deferred);
However, if it's indeed one of the workqueues, I am not sure how it
should be fixed.
We are having a similar (even worser) problem with async destruction
of network namespaces. These are way slower and take lots of mutexes.
I suspect that lots of hangs on net mutexes on syzbot dashboard are
related to that.
Unbounded async queueing is never a good idea. The classical solution
to this is to make the queue bounded and put back pressure on
producers. In this case it would limit the speed at which new
processes are created and make resource consumption (including # of
lockdep entries) bounded.
The restriction probably needs to be per-callback type, at least for
global workqueues.
However, I suspect that lots of callers of schedule_work can't block
(the reason for moving the work to background in the first place?). So
potentially the back pressure may be need to be applied at a different
point, which makes things a bit more complicated.
> root@le-dbg:~# egrep "BD.*htab->lockdep_key" /proc/lockdep | wc -l
> 7449
> root@le-dbg:~# egrep "BD.*htab->lockdep_key" /proc/lockdep | tail -n 3
> (ptrval) FD:1 BD:1 : &htab->lockdep_key#9531
> (ptrval) FD:1 BD:1 : &htab->lockdep_key#9532
> (ptrval) FD:1 BD:1 : &htab->lockdep_key#9533
>
>
> // autogenerated by syzkaller (https://github.com/google/syzkaller)
>
> #define __unix__ 1
> #define __gnu_linux__ 1
> #define __linux__ 1
>
> #define _GNU_SOURCE
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> static unsigned long long procid;
>
> static void sleep_ms(uint64_t ms)
> {
> usleep(ms * 1000);
> }
>
> static uint64_t current_time_ms(void)
> {
> struct timespec ts;
> if (clock_gettime(CLOCK_MONOTONIC, &ts))
> exit(1);
> return (uint64_t)ts.tv_sec * 1000 + (uint64_t)ts.tv_nsec / 100;
> }
>
> static bool write_file(const char* file, const char* what, ...)
> {
> char buf[1024];
> va_list args;
> va_start(args, what);
> vsnprintf(buf, sizeof(buf), what, args);
> va_end(args);
> buf[sizeof(buf) - 1] = 0;
> int len = strlen(buf);
> int fd = open(file, O_WRONLY | O_CLOEXEC);
> if (fd == -1)
> return false;
> if (write(fd, buf, len) != len) {
> int err = errno;
> close(fd);
> errno = err;
> return false;
> }
> close(fd);
> return true;
> }
>
> static void kill_and_wait(int pid, int* status)
> {
> kill(-pid, SIGKILL);
> kill(pid, SIGKILL);
> for (int i = 0; i < 100; i++) {
> if (waitpid(-1, status, WNOHANG | __WALL) == pid)
> return;
> usleep(1000);
> }
> DIR* dir = opendir("/sys/fs/fuse/connections");
> if (dir) {
> for (;;) {
> struct dirent* ent = readdir(dir);
> if (!ent)
> break;
> if (strcmp(ent->d_name, ".") == 0 ||
> strcmp(ent->d_name, "..") == 0)
> continue;
> char abort[300];
> snprintf(abort,
Re: [PATCH] prctl: allow to setup brk for et_dyn executables
CC: Pavel and Alexander On 22.01.2021 01:12, Cyrill Gorcunov wrote: > Keno Fischer reported that when a binray loaded via > ld-linux-x the prctl(PR_SET_MM_MAP) doesn't allow to > setup brk value because it lays before mm:end_data. > > For example a test program shows > > | # ~/t > | > | start_code 401000 > | end_code401a15 > | start_stack 7ffce4577dd0 > | start_data403e10 > | end_data40408c > | start_brk b5b000 > | sbrk(0) b5b000 > > and when executed via ld-linux > > | # /lib64/ld-linux-x86-64.so.2 ~/t > | > | start_code 7fc25b0a4000 > | end_code7fc25b0c4524 > | start_stack 7fffcc6b2400 > | start_data7fc25b0ce4c0 > | end_data7fc25b0cff98 > | start_brk 5710c000 > | sbrk(0) 5710c000 > > This of course prevent criu from restoring such programs. > Looking into how kernel operates with brk/start_brk inside > brk() syscall I don't see any problem if we allow to setup > brk/start_brk without checking for end_data. Even if someone > pass some weird address here on a purpose then the worst > possible result will be an unexpected unmapping of existing > vma (own vma, since prctl works with the callers memory) but > test for RLIMIT_DATA is still valid and a user won't be able > to gain more memory in case of expanding VMAs via new values > shipped with prctl call. > > Reported-by: Keno Fischer > Signed-off-by: Cyrill Gorcunov > CC: Andrew Morton > CC: Dmitry Safonov <0x7f454...@gmail.com> > CC: Andrey Vagin > CC: Kirill Tkhai > CC: Eric W. Biederman > --- > Guys, take a look please once time permit. Hopefully I didn't > miss something 'cause made this patch via code reading only. > > Andrey, do we still have a criu container which tests new kernels, > right? Would be great to run criu tests with this patch applied > to make sure everything is intact. > > kernel/sys.c |7 --- > 1 file changed, 7 deletions(-) > > Index: linux-tip.git/kernel/sys.c > === > --- linux-tip.git.orig/kernel/sys.c > +++ linux-tip.git/kernel/sys.c > @@ -1943,13 +1943,6 @@ static int validate_prctl_map_addr(struc > error = -EINVAL; > > /* > - * @brk should be after @end_data in traditional maps. > - */ > - if (prctl_map->start_brk <= prctl_map->end_data || > - prctl_map->brk <= prctl_map->end_data) > - goto out; > - > - /* >* Neither we should allow to override limits if they set. >*/ > if (check_data_rlimit(rlimit(RLIMIT_DATA), prctl_map->brk, >
Re: [PATCH] i2c: sprd:: depend on COMMON_CLK to fix compile tests
On Sun, Jan 17, 2021 at 12:43:13PM +0100, Krzysztof Kozlowski wrote:
> The I2C_SPRD uses Common Clock Framework thus it cannot be built on
> platforms without it (e.g. compile test on MIPS with LANTIQ):
>
> /usr/bin/mips-linux-gnu-ld: drivers/i2c/busses/i2c-sprd.o: in function
> `sprd_i2c_probe':
> i2c-sprd.c:(.text.sprd_i2c_probe+0x254): undefined reference to
> `clk_set_parent'
>
> Fixes: 4a2d5f663dab ("i2c: Enable compile testing for more drivers")
> Reported-by: kernel test robot
> Signed-off-by: Krzysztof Kozlowski
Fixed the "::" in $subject ad applied to for-current, thanks!
signature.asc
Description: PGP signature
Re: [PATCH V3 1/3] mm/memory_hotplug: Prevalidate the address range being added with platform
> +/*
> + * Platforms should define arch_get_mappable_range() that provides
> + * maximum possible addressable physical memory range for which the
> + * linear mapping could be created. The platform returned address
> + * range must adhere to these following semantics.
> + *
> + * - range.start <= range.end
> + * - Range includes both end points [range.start..range.end]
> + *
> + * There is also a fallback definition provided here, allowing the
> + * entire possible physical address range in case any platform does
> + * not define arch_get_mappable_range().
> + */
> +struct range __weak arch_get_mappable_range(void)
> +{
> + struct range memhp_range = {
> + .start = 0UL,
> + .end = -1ULL,
> + };
> + return memhp_range;
> +}
> +
> +struct range memhp_get_pluggable_range(bool need_mapping)
> +{
> + const u64 max_phys = (1ULL << (MAX_PHYSMEM_BITS + 1)) - 1;
Sorry, thought about that line a bit more, and I think this is just
wrong (took me longer to realize as it should). The old code used this
calculation to print the limit only (in a wrong way), let's recap:
Assume MAX_PHYSMEM_BITS=32
max_phys = (1ULL << (32 + 1)) - 1 = 0x1ull;
Ehm, these are 33 bit.
OTOH, old code checked for
if (max_addr >> MAX_PHYSMEM_BITS) {
Which makes sense, because
0x1ull >> 32 = 1
results in "true", meaning it's to big, while
0xull >> 32 = 0
correctly results in "false", meaning the address is fine.
So, this should just be
const u64 max_phys = 1ULL << MAX_PHYSMEM_BITS;
(similarly as calculated in virito-mem code, or in kernel/resource.c)
> + struct range memhp_range;
> +
> + if (need_mapping) {
> + memhp_range = arch_get_mappable_range();
> + if (memhp_range.start > max_phys) {
> + memhp_range.start = 0;
> + memhp_range.end = 0;
> + }
> + memhp_range.end = min_t(u64, memhp_range.end, max_phys);
> + } else {
> + memhp_range.start = 0;
> + memhp_range.end = max_phys;
> + }
> + return memhp_range;
> +}
> +EXPORT_SYMBOL_GPL(memhp_get_pluggable_range);
--
Thanks,
David / dhildenb
Re: [PATCH net v5] net: lapb: Add locking to the lapb module
On 2021-01-21 01:21, Xie He wrote:
In the lapb module, the timers may run concurrently with other code in
this module, and there is currently no locking to prevent the code from
racing on "struct lapb_cb". This patch adds locking to prevent racing.
1. Add "spinlock_t lock" to "struct lapb_cb"; Add "spin_lock_bh" and
"spin_unlock_bh" to APIs, timer functions and notifier functions.
2. Add "bool t1timer_stop, t2timer_stop" to "struct lapb_cb" to make us
able to ask running timers to abort; Modify "lapb_stop_t1timer" and
"lapb_stop_t2timer" to make them able to abort running timers;
Modify "lapb_t2timer_expiry" and "lapb_t1timer_expiry" to make them
abort after they are stopped by "lapb_stop_t1timer",
"lapb_stop_t2timer",
and "lapb_start_t1timer", "lapb_start_t2timer".
3. Let lapb_unregister wait for other API functions and running timers
to stop.
4. The lapb_device_event function calls lapb_disconnect_request. In
order to avoid trying to hold the lock twice, add a new function named
"__lapb_disconnect_request" which assumes the lock is held, and make
it called by lapb_disconnect_request and lapb_device_event.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: Martin Schiller
Signed-off-by: Xie He
I don't have the opportunity to test this at the moment, but code looks
reasonable so far. Have you tested this at runtime?
---
Change from v4:
Make lapb_unregister wait for other refs to "lapb" to drop, to ensure
that other LAPB API calls have all finished.
Change from v3:
In lapb_unregister make sure the self-restarting t1timer has really
been
stopped.
Change from v2:
Create a new __lapb_disconnect_request function to reduce redundant
code.
Change from v1:
Broke long lines to keep the line lengths within 80 characters.
---
include/net/lapb.h| 2 ++
net/lapb/lapb_iface.c | 70 +--
net/lapb/lapb_timer.c | 30 ---
3 files changed, 82 insertions(+), 20 deletions(-)
diff --git a/include/net/lapb.h b/include/net/lapb.h
index ccc3d1f020b0..eee73442a1ba 100644
--- a/include/net/lapb.h
+++ b/include/net/lapb.h
@@ -92,6 +92,7 @@ struct lapb_cb {
unsigned short n2, n2count;
unsigned short t1, t2;
struct timer_list t1timer, t2timer;
+ boolt1timer_stop, t2timer_stop;
/* Internal control information */
struct sk_buff_head write_queue;
@@ -103,6 +104,7 @@ struct lapb_cb {
struct lapb_frame frmr_data;
unsigned char frmr_type;
+ spinlock_t lock;
refcount_t refcnt;
};
diff --git a/net/lapb/lapb_iface.c b/net/lapb/lapb_iface.c
index 40961889e9c0..b028dfc438ce 100644
--- a/net/lapb/lapb_iface.c
+++ b/net/lapb/lapb_iface.c
@@ -122,6 +122,8 @@ static struct lapb_cb *lapb_create_cb(void)
timer_setup(&lapb->t1timer, NULL, 0);
timer_setup(&lapb->t2timer, NULL, 0);
+ lapb->t1timer_stop = true;
+ lapb->t2timer_stop = true;
lapb->t1 = LAPB_DEFAULT_T1;
lapb->t2 = LAPB_DEFAULT_T2;
@@ -129,6 +131,8 @@ static struct lapb_cb *lapb_create_cb(void)
lapb->mode= LAPB_DEFAULT_MODE;
lapb->window = LAPB_DEFAULT_WINDOW;
lapb->state = LAPB_STATE_0;
+
+ spin_lock_init(&lapb->lock);
refcount_set(&lapb->refcnt, 1);
out:
return lapb;
@@ -178,11 +182,23 @@ int lapb_unregister(struct net_device *dev)
goto out;
lapb_put(lapb);
+ /* Wait for other refs to "lapb" to drop */
+ while (refcount_read(&lapb->refcnt) > 2)
+ ;
+
+ spin_lock_bh(&lapb->lock);
+
lapb_stop_t1timer(lapb);
lapb_stop_t2timer(lapb);
lapb_clear_queues(lapb);
+ spin_unlock_bh(&lapb->lock);
+
+ /* Wait for running timers to stop */
+ del_timer_sync(&lapb->t1timer);
+ del_timer_sync(&lapb->t2timer);
+
__lapb_remove_cb(lapb);
lapb_put(lapb);
@@ -201,6 +217,8 @@ int lapb_getparms(struct net_device *dev, struct
lapb_parms_struct *parms)
if (!lapb)
goto out;
+ spin_lock_bh(&lapb->lock);
+
parms->t1 = lapb->t1 / HZ;
parms->t2 = lapb->t2 / HZ;
parms->n2 = lapb->n2;
@@ -219,6 +237,7 @@ int lapb_getparms(struct net_device *dev, struct
lapb_parms_struct *parms)
else
parms->t2timer = (lapb->t2timer.expires - jiffies) / HZ;
+ spin_unlock_bh(&lapb->lock);
lapb_put(lapb);
rc = LAPB_OK;
out:
@@ -234,6 +253,8 @@ int lapb_setparms(struct net_device *dev, struct
lapb_parms_struct *parms)
if (!lapb)
goto out;
+ spin_lock_bh(&lapb->lock);
+
rc = LAPB_INVALUE;
if (parms->t1 < 1 || parms->t2 < 1 || parms->n2 < 1)
goto out_put;
@@ -256,6 +277,7 @@ int lapb_setparms(struct net_device *dev, struct
lapb_parms_struct *parms)
rc = LAPB_OK;
out_put:
+ spin_
RE: [PATCH] genirq/msi: Make sure early activation of all PCI MSIs
Hi Marc,
> -Original Message-
> From: Marc Zyngier [mailto:m...@kernel.org]
> Sent: 21 January 2021 21:25
> To: Shameerali Kolothum Thodi
> Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> eric.au...@redhat.com; t...@linutronix.de; linux...@openeuler.org;
> Zengtao (B) ; Wangzhou (B)
>
> Subject: Re: [PATCH] genirq/msi: Make sure early activation of all PCI MSIs
>
> Hi Shameer,
>
> On Thu, 21 Jan 2021 11:02:47 +,
> Shameer Kolothum wrote:
> >
> > We currently do early activation of MSI irqs for PCI/MSI based on the
> > MSI_FLAG_ACTIVATE_EARLY flag. Though this activates all the allocated
> > MSIs in the case of MSI-X, it only does so for the base irq in the
> > case of MSI. This is because, for MSI, there is only one msi_desc
> > entry for all the 32 irqs it can support and the current
> > implementation iterates over the msi entries and ends up activating
> > the base irq only.
> >
> > The above creates an issue on platforms where the msi controller
> > supports direct injection of vLPIs(eg: ARM GICv4 ITS). On these
> > platforms, upon irq activation, ITS driver maps the event to an ITT
> > entry. And for Guest pass-through to work, early mapping of all the
> > dev MSI vectors is required. Otherwise, the vfio irq bypass manager
> > registration will fail. eg, On a HiSilicon D06 platform with GICv4
> > enabled, Guest boot with zip dev pass-through reports,
> >
> > "vfio-pci :75:00.1: irq bypass producer (token 06e5176a)
> > registration fails: 66311"
> >
> > and Guest boot fails.
> >
> > This is traced to,
> > kvm_arch_irq_bypass_add_producer
> > kvm_vgic_v4_set_forwarding
> > vgic_its_resolve_lpi --> returns
> E_ITS_INT_UNMAPPED_INTERRUPT
> >
> > Hence make sure we activate all the irqs for both MSI and MSI-x cases.
> >
> > Signed-off-by: Shameer Kolothum
> > ---
> > It is unclear to me whether not performing the early activation of all
> > MSI irqs was deliberate and has consequences on any other platforms.
> > Please let me know.
>
> Probably just an oversight.
Ok. That’s a good news :)
> >
> > Thanks,
> > Shameer
> > ---
> > kernel/irq/msi.c | 114
> > +--
> > 1 file changed, 90 insertions(+), 24 deletions(-)
> >
> > diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c index
> > 2c0c4d6d0f83..eec187fc32a9 100644
> > --- a/kernel/irq/msi.c
> > +++ b/kernel/irq/msi.c
> > @@ -395,6 +395,78 @@ static bool msi_check_reservation_mode(struct
> irq_domain *domain,
> > return desc->msi_attrib.is_msix || desc->msi_attrib.maskbit; }
> >
> > +static void msi_domain_deactivate_irq(struct irq_domain *domain, int
> > +irq) {
> > + struct irq_data *irqd;
> > +
> > + irqd = irq_domain_get_irq_data(domain, irq);
> > + if (irqd_is_activated(irqd))
> > + irq_domain_deactivate_irq(irqd);
> > +}
> > +
> > +static int msi_domain_activate_irq(struct irq_domain *domain,
> > + int irq, bool can_reserve)
> > +{
> > + struct irq_data *irqd;
> > +
> > + irqd = irq_domain_get_irq_data(domain, irq);
> > + if (!can_reserve) {
> > + irqd_clr_can_reserve(irqd);
> > + if (domain->flags & IRQ_DOMAIN_MSI_NOMASK_QUIRK)
> > + irqd_set_msi_nomask_quirk(irqd);
> > + }
> > + return irq_domain_activate_irq(irqd, can_reserve); }
> > +
> > +static int msi_domain_activate_msix_irqs(struct irq_domain *domain,
> > +struct device *dev, bool can_reserve) {
> > + struct msi_desc *desc;
> > + int ret, irq;
> > +
> > + for_each_msi_entry(desc, dev) {
> > + irq = desc->irq;
> > + ret = msi_domain_activate_irq(domain, irq, can_reserve);
> > + if (ret)
> > + goto out;
> > + }
> > + return 0;
> > +
> > +out:
> > + for_each_msi_entry(desc, dev) {
> > + if (irq == desc->irq)
> > + break;
> > + msi_domain_deactivate_irq(domain, desc->irq);
> > + }
> > + return ret;
> > +}
> > +
> > +static int msi_domain_activate_msi_irqs(struct irq_domain *domain,
> > + struct device *dev, bool can_reserve) {
> > + struct msi_desc *desc;
> > + int i, ret, base, irq;
> > +
> > + desc = first_msi_entry(dev);
> > + base = desc->irq;
> > +
> > + for (i = 0; i < desc->nvec_used; i++) {
> > + irq = base + i;
> > + ret = msi_domain_activate_irq(domain, irq, can_reserve);
> > + if (ret)
> > + goto out;
> > + }
> > + return 0;
> > +
> > +out:
> > + for (i = 0; i < desc->nvec_used; i++) {
> > + if (irq == base + i)
> > + break;
> > + msi_domain_deactivate_irq(domain, base + i);
> > + }
> > + return ret;
> > +}
> > +
> > int __msi_domain_alloc_irqs(struct irq_domain *domain, struct device
> *dev,
> > int nvec)
> > {
> > @@ -443,21 +515,25 @@ int __msi_domain_alloc_irqs(struct irq_
[PATCH] scsi: megaraid_sas: remove redundant NULL check
Fix below warnings reported by coccicheck:
./drivers/scsi/megaraid/megaraid_sas_fusion.c:3924:3-8: WARNING: NULL
check before some freeing functions is not needed.
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/scsi/megaraid/megaraid_sas_fusion.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index fd60728..38fc946 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -3920,8 +3920,7 @@ static irqreturn_t megasas_isr_fusion(int irq, void *devp)
{
unsigned int i;
for (i = 0; i < instance->drv_buf_alloc; i++) {
- if (instance->crash_buf[i])
- vfree(instance->crash_buf[i]);
+ vfree(instance->crash_buf[i]);
}
instance->drv_buf_index = 0;
instance->drv_buf_alloc = 0;
--
1.8.3.1
[PATCH v2 1/3] watchdog: pcwd: drop always-false if from remove callback
If pcwd_isa_probe() succeeded pcwd_private.io_addr cannot be NULL. (And
if pcwd_isa_probe() failed, pcwd_isa_remove() isn't called.)
Acked-by: Guenter Roeck
Acked-by: William Breathitt Gray
Signed-off-by: Uwe Kleine-König
---
drivers/watchdog/pcwd.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/watchdog/pcwd.c b/drivers/watchdog/pcwd.c
index e86fa7f8351d..b95cd38f3ceb 100644
--- a/drivers/watchdog/pcwd.c
+++ b/drivers/watchdog/pcwd.c
@@ -956,9 +956,6 @@ static int pcwd_isa_remove(struct device *dev, unsigned int
id)
if (debug >= DEBUG)
pr_debug("pcwd_isa_remove id=%d\n", id);
- if (!pcwd_private.io_addr)
- return 1;
-
/* Disable the board */
if (!nowayout)
pcwd_stop();
--
2.29.2
Re: [PATCH v2 07/12] ASoC: arizona-jack: Use arizona->dev for runtime-pm
On Fri, Jan 22, 2021 at 2:03 AM Hans de Goede wrote: > On 1/18/21 1:02 PM, Andy Shevchenko wrote: > > On Sun, Jan 17, 2021 at 6:06 PM Hans de Goede wrote: ... > > Can you elaborate switchings from get() to get_sync() in few places > > Sorry, those 2 changes really should have been in a separate commit. > I've put the 2 get -> get_sync() changed in their own commit now > with the following commit-msg: > > """ > extcon: arizona: Always use pm_runtime_get_sync() when we need the device to > be awake > > Before this commit the extcon-arizona code was mixing pm_runtime_get() > and pm_runtime_get_sync() in different places. In all cases where > either function is called we make use of the device immediately called and we > afterwards. This means that we should always use pm_runtime_get_sync(). > """ > > > along with moving disable()? > The enable / disable calls are not moved, they are removed. > > Here is a new commit msg which hopefully explains this better > which I plan to use for v3: > > """ > Drivers for MFD child-devices such as the arizona codec drivers > and the arizona-extcon driver can choose to either make > runtime_pm_get/_put calls on their own child-device, which will > then be propagated to their parent; or they can make them directly > on their MFD parent-device. > > The arizona-extcon code was using runtime_pm_get/_put calls on > its own child-device where as the codec drivers are using > runtime_pm_get/_put calls on their parent. > > The arizona-extcon MFD cell/child-device has been removed and this > commit is part of refactoring the arizona-extcon code into a library > to be used directly from the codec drivers. > > Specifically this commit moves the code over to make > runtime_pm_get/_put calls on the parent device (on arizona->dev) > bringing the code inline with how the codec drivers do this. > > Note this also removes the pm_runtime_enable/_disable calls > as pm_runtime support has already been enabled on the parent-device > by the arizona MFD driver. > """ Makes sense to me, thanks! -- With Best Regards, Andy Shevchenko
[PATCH] kdb: Make memory allocations more robust
Currently kdb uses in_interrupt() to determine whether it's library code has been called from the kgdb trap handler or from a saner calling context such as driver init. This approach is broken because in_interrupt() alone isn't able to determine kgdb trap handler entry via normal task context such as [1]. We can improve this by adding check for in_dbg_master() which explicitly determines if we are running in debugger context. Also, use in_atomic() instead of in_interrupt() as the former is more appropriate to know atomic context and moreover the later one is deprecated. [1] $ echo g > /proc/sysrq-trigger Signed-off-by: Sumit Garg --- kernel/debug/kdb/kdb_private.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/debug/kdb/kdb_private.h b/kernel/debug/kdb/kdb_private.h index 7a4a181..7a9ebd9 100644 --- a/kernel/debug/kdb/kdb_private.h +++ b/kernel/debug/kdb/kdb_private.h @@ -231,7 +231,7 @@ extern struct task_struct *kdb_curr_task(int); #define kdb_task_has_cpu(p) (task_curr(p)) -#define GFP_KDB (in_interrupt() ? GFP_ATOMIC : GFP_KERNEL) +#define GFP_KDB (in_atomic() || in_dbg_master() ? GFP_ATOMIC : GFP_KERNEL) extern void *debug_kmalloc(size_t size, gfp_t flags); extern void debug_kfree(void *); -- 2.7.4
[PATCH] scsi: fnic: remove redundant NULL check
Fix below warnings reported by coccicheck: ./drivers/scsi/fnic/fnic_debugfs.c:91:2-7: WARNING: NULL check before some freeing functions is not needed. Reported-by: Abaci Robot Signed-off-by: Yang Li --- drivers/scsi/fnic/fnic_debugfs.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/scsi/fnic/fnic_debugfs.c b/drivers/scsi/fnic/fnic_debugfs.c index 6c04936..6dce1cd 100644 --- a/drivers/scsi/fnic/fnic_debugfs.c +++ b/drivers/scsi/fnic/fnic_debugfs.c @@ -87,8 +87,7 @@ void fnic_debugfs_terminate(void) debugfs_remove(fnic_trace_debugfs_root); fnic_trace_debugfs_root = NULL; - if (fc_trc_flag) - vfree(fc_trc_flag); + vfree(fc_trc_flag); } /* -- 1.8.3.1
[PATCH v3] f2fs: compress: deny setting unsupported compress algorithm
If kernel doesn't support certain kinds of compress algorithm, deny to set
them as compress algorithm of f2fs via 'compress_algorithm=%s' mount option.
Signed-off-by: Chao Yu
---
v3:
- rebase to commit 03a9a1a64a11 ("f2fs: relocate f2fs_precache_extents()")
in dev branch
fs/f2fs/super.c | 16
1 file changed, 16 insertions(+)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index b4a07fe62d1a..a275bd312ae5 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -882,17 +882,33 @@ static int parse_options(struct super_block *sb, char
*options, bool is_remount)
if (!name)
return -ENOMEM;
if (!strcmp(name, "lzo")) {
+#ifdef CONFIG_F2FS_FS_LZO
F2FS_OPTION(sbi).compress_algorithm =
COMPRESS_LZO;
+#else
+ f2fs_info(sbi, "kernel doesn't support lzo
compression");
+#endif
} else if (!strcmp(name, "lz4")) {
+#ifdef CONFIG_F2FS_FS_LZ4
F2FS_OPTION(sbi).compress_algorithm =
COMPRESS_LZ4;
+#else
+ f2fs_info(sbi, "kernel doesn't support lz4
compression");
+#endif
} else if (!strcmp(name, "zstd")) {
+#ifdef CONFIG_F2FS_FS_ZSTD
F2FS_OPTION(sbi).compress_algorithm =
COMPRESS_ZSTD;
+#else
+ f2fs_info(sbi, "kernel doesn't support zstd
compression");
+#endif
} else if (!strcmp(name, "lzo-rle")) {
+#ifdef CONFIG_F2FS_FS_LZORLE
F2FS_OPTION(sbi).compress_algorithm =
COMPRESS_LZORLE;
+#else
+ f2fs_info(sbi, "kernel doesn't support lzorle
compression");
+#endif
} else {
kfree(name);
return -EINVAL;
--
2.29.2
Re: [PATCH] scsi: megaraid_sas: remove redundant NULL check
On Fri, Jan 22, 2021 at 05:23:44PM +0800, Yang Li wrote: > Fix below warnings reported by coccicheck: > ./drivers/scsi/megaraid/megaraid_sas_fusion.c:3924:3-8: WARNING: NULL > check before some freeing functions is not needed. > > Reported-by: Abaci Robot > Signed-off-by: Yang Li > --- > drivers/scsi/megaraid/megaraid_sas_fusion.c | 3 +-- Please always use scripts/get_maintainer.pl to determine who to send patches to, and what mailing list, otherwise they will just be ignored, like this one :( thanks, greg k-h
Re: [PATCH v2 6/7] ARM: dts: imx6dl-prtvt7: fix PWM cell count for the backlight node.
On Thu, Jan 21, 2021 at 11:17:42AM -0300, Fabio Estevam wrote: > Hi Oleksij, > > On Thu, Jan 21, 2021 at 3:12 AM Oleksij Rempel > wrote: > > > > At some point PWM cell count was changed, but it didn't triggered any > > It changed in this commit: > > commit fa28d8212ede9c533ae87a737571a9d3b3eebb29 > Author: Uwe Kleine-König > Date: Fri Jul 10 07:19:37 2020 +0200 > > ARM: dts: imx: default to #pwm-cells = <3> in the SoC dtsi files > > The imx-pwm driver supports 3 cells and this is the more flexible setting. > So use it by default and overwrite it back to two for the files that > reference the PWMs with just 2 cells to minimize changes. > > This allows to drop explicit setting to 3 cells for the boards that > already > depend on this. The boards that are now using 2 cells explicitly can be > converted to 3 individually. > > Signed-off-by: Uwe Kleine-König > Signed-off-by: Shawn Guo OK, nice. Thx! Should I resend this series without this patch? Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH 0/2] mmc: remove obsolete drivers
On Wed, 20 Jan 2021 at 15:28, Arnd Bergmann wrote: > > From: Arnd Bergmann > > A few Arm platforms are getting removed in v5.12, this removes > the corresponding mmc drivers. > > Link: > https://lore.kernel.org/linux-arm-kernel/20210120124812.2800027-1-a...@kernel.org/T/ > > > Arnd Bergmann (2): > mmc: remove dw_mmc-zx driver > mmc: remove sirf prima/atlas driver > > .../devicetree/bindings/mmc/sdhci-sirf.txt| 18 -- > .../devicetree/bindings/mmc/zx-dw-mshc.txt| 31 --- > drivers/mmc/host/Kconfig | 21 -- > drivers/mmc/host/Makefile | 2 - > drivers/mmc/host/dw_mmc-zx.c | 234 - > drivers/mmc/host/dw_mmc-zx.h | 32 --- > drivers/mmc/host/sdhci-sirf.c | 235 -- > 7 files changed, 573 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/mmc/sdhci-sirf.txt > delete mode 100644 Documentation/devicetree/bindings/mmc/zx-dw-mshc.txt > delete mode 100644 drivers/mmc/host/dw_mmc-zx.c > delete mode 100644 drivers/mmc/host/dw_mmc-zx.h > delete mode 100644 drivers/mmc/host/sdhci-sirf.c Applied for next, thanks! Kind regards Uffe
Re: [PATCH] bfq: don't check active group if bfq.weight is not changed
> Il giorno 14 gen 2021, alle ore 13:24, Yu Kuai ha
> scritto:
>
> Now the group scheduling in BFQ depends on the check of active group,
> but in most cases group scheduling is not used and the checking
> of active group will cause bfq_asymmetric_scenario() and its caller
> bfq_better_to_idle() to always return true, so the throughput
> will be impacted if the workload doesn't need idle (e.g. random rw)
>
> To fix that, adding check in bfq_io_set_weight_legacy() and
> bfq_pd_init() to check whether or not group scheduling is used
> (a non-default weight is used). If not, there is no need
> to check active group.
>
Hi,
I do like the goal you want to attain. Still, I see a problem with
your proposal. Consider two groups, say A and B. Suppose that both
have the same, default weight. Yet, group A generates large I/O
requests, while group B generates small requests. With your change,
idling would not be performed. This would cause group A to steal
bandwidth to group B, in proportion to how large its requests are
compared with those of group B.
As a possible solution, maybe we would need also a varied_rq_size
flag, similar to the varied_weights flag?
Thoughts?
Thanks for your contribution,
Paolo
> Signed-off-by: Yu Kuai
> ---
> block/bfq-cgroup.c | 14 --
> block/bfq-iosched.c | 8 +++-
> block/bfq-iosched.h | 19 +++
> 3 files changed, 34 insertions(+), 7 deletions(-)
>
> diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c
> index b791e2041e49..b4ac42c4bd9f 100644
> --- a/block/bfq-cgroup.c
> +++ b/block/bfq-cgroup.c
> @@ -505,12 +505,18 @@ static struct blkcg_policy_data *bfq_cpd_alloc(gfp_t
> gfp)
> return &bgd->pd;
> }
>
> +static inline int bfq_dft_weight(void)
> +{
> + return cgroup_subsys_on_dfl(io_cgrp_subsys) ?
> +CGROUP_WEIGHT_DFL : BFQ_WEIGHT_LEGACY_DFL;
> +
> +}
> +
> static void bfq_cpd_init(struct blkcg_policy_data *cpd)
> {
> struct bfq_group_data *d = cpd_to_bfqgd(cpd);
>
> - d->weight = cgroup_subsys_on_dfl(io_cgrp_subsys) ?
> - CGROUP_WEIGHT_DFL : BFQ_WEIGHT_LEGACY_DFL;
> + d->weight = bfq_dft_weight();
> }
>
> static void bfq_cpd_free(struct blkcg_policy_data *cpd)
> @@ -554,6 +560,9 @@ static void bfq_pd_init(struct blkg_policy_data *pd)
> bfqg->bfqd = bfqd;
> bfqg->active_entities = 0;
> bfqg->rq_pos_tree = RB_ROOT;
> +
> + if (entity->new_weight != bfq_dft_weight())
> + bfqd_enable_active_group_check(bfqd);
> }
>
> static void bfq_pd_free(struct blkg_policy_data *pd)
> @@ -1013,6 +1022,7 @@ static void bfq_group_set_weight(struct bfq_group
> *bfqg, u64 weight, u64 dev_wei
>*/
> smp_wmb();
> bfqg->entity.prio_changed = 1;
> + bfqd_enable_active_group_check(bfqg->bfqd);
> }
> }
>
> diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
> index 9e4eb0fc1c16..1b695de1df95 100644
> --- a/block/bfq-iosched.c
> +++ b/block/bfq-iosched.c
> @@ -699,11 +699,8 @@ static bool bfq_asymmetric_scenario(struct bfq_data
> *bfqd,
> (bfqd->busy_queues[0] && bfqd->busy_queues[2]) ||
> (bfqd->busy_queues[1] && bfqd->busy_queues[2]);
>
> - return varied_queue_weights || multiple_classes_busy
> -#ifdef CONFIG_BFQ_GROUP_IOSCHED
> -|| bfqd->num_groups_with_pending_reqs > 0
> -#endif
> - ;
> + return varied_queue_weights || multiple_classes_busy ||
> +bfqd_has_active_group(bfqd);
> }
>
> /*
> @@ -6472,6 +6469,7 @@ static int bfq_init_queue(struct request_queue *q,
> struct elevator_type *e)
>
> bfqd->queue_weights_tree = RB_ROOT_CACHED;
> bfqd->num_groups_with_pending_reqs = 0;
> + bfqd->check_active_group = false;
>
> INIT_LIST_HEAD(&bfqd->active_list);
> INIT_LIST_HEAD(&bfqd->idle_list);
> diff --git a/block/bfq-iosched.h b/block/bfq-iosched.h
> index 703895224562..216509013012 100644
> --- a/block/bfq-iosched.h
> +++ b/block/bfq-iosched.h
> @@ -524,6 +524,8 @@ struct bfq_data {
>
> /* true if the device is non rotational and performs queueing */
> bool nonrot_with_queueing;
> + /* true if need to check num_groups_with_pending_reqs */
> + bool check_active_group;
>
> /*
>* Maximum number of requests in driver in the last
> @@ -1066,6 +1068,17 @@ static inline void bfq_pid_to_str(int pid, char *str,
> int len)
> }
>
> #ifdef CONFIG_BFQ_GROUP_IOSCHED
> +static inline void bfqd_enable_active_group_check(struct bfq_data *bfqd)
> +{
> + cmpxchg_relaxed(&bfqd->check_active_group, false, true);
> +}
> +
> +static inline bool bfqd_has_active_group(struct bfq_data *bfqd)
> +{
> + return bfqd->check_active_group &&
> +bfqd->num_groups_with_pending_reqs > 0;
> +}
> +
> struct bfq_group *bfqq_group(struct bfq_queue *bfqq);
>
> #define bfq_log_bfqq(bfqd, bfqq, fmt, args...)do {
> \
> @@ -1085,6 +1098,12 @@ struct bfq_group *bfqq_group(st
