Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM
On Sat, Oct 03, 2020 at 11:40:22AM +0200, Daniel Vetter wrote: > > That leaves the only interesting places as vb2_dc_get_userptr() and > > vb2_vmalloc_get_userptr() which both completely fail to follow the > > REQUIRED behavior in the function's comment about checking PTEs. It > > just DMA maps them. Badly broken. > > > > Guessing this hackery is for some embedded P2P DMA transfer? > > Yeah, see also the follow_pfn trickery in > videobuf_dma_contig_user_get(), I think this is fully intentional and > userspace abi we can't break :-/ We don't need to break uABI, it just needs to work properly in the kernel: vma = find_vma_intersection() dma_buf = dma_buf_get_from_vma(vma) sg = dma_buf_p2p_dma_map(dma_buf) [.. do dma ..] dma_buf_unmap(sg) dma_buf_put(dma_buf) It is as we discussed before, dma buf needs to be discoverable from a VMA, at least for users doing this kind of stuff. > Yup this should be done with dma_buf instead, and v4l has that. But > old uapi and all that. This is why I said we might need a new > VM_DYNAMIC_PFNMAP or so, to make follow_pfn not resolve this in the > case where the driver manages the underlying iomem range (or whatever > it is) dynamically and moves buffer objects around, like drm drivers > do. But I looked, and we've run out of vma->vm_flags :-( A VM flag doesn't help - we need to introduce some kind of lifetime, and that has to be derived from the VMA. It needs data not just a flag > The other problem is that I also have no real working clue about all > the VM_* flags and what they all mean, and whether drm drivers set the > right ones in all cases (they probably don't, but oh well). > Documentation for this stuff in headers is a bit thin at times. Yah, I don't really know either :\ The comment above vm_normal_page() is a bit helpful. Don't know what VM_IO/VM_PFNMAP mean in their 3 combinations There are very few places that set VM_PFNMAP without VM_IO.. Jason
Re: [PATCH AUTOSEL 5.8 08/29] net: dsa: microchip: look for phy-mode in port nodes
On Tue, Sep 29, 2020 at 07:56:30AM +0200, Helmut Grohne wrote: Hi Sascha, On Tue, Sep 29, 2020 at 03:30:05AM +0200, Sasha Levin wrote: From: Helmut Grohne [ Upstream commit edecfa98f602a597666e3c5cab2677ada38d93c5 ] Documentation/devicetree/bindings/net/dsa/dsa.txt says that the phy-mode property should be specified on port nodes. However, the microchip drivers read it from the switch node. Let the driver use the per-port property and fall back to the old location with a warning. Fix in-tree users. I don't think this patch is useful for stable users. It corrects a device tree layout issue. Any existing users of the functionality will have an odd, but working device tree and that will continue working (with a warning) after applying this patch. It just has a property on the "wrong" node. I don't think I'd like to update my device tree in a stable update. I've dropped it, thanks! -- Thanks, Sasha
[PATCH v2] media: mtk-vcodec: fix builds when remoteproc is disabled
The addition of MT8183 support added a dependency on the SCP remoteproc
module. However the initial patch used the "select" Kconfig directive,
which may result in the SCP module to not be compiled if remoteproc was
disabled. In such a case, mtk-vcodec would try to link against
non-existent SCP symbols. "select" was clearly misused here as explained
in kconfig-language.txt.
Replace this by a "depends" directive on at least one of the VPU and
SCP modules, to allow the driver to be compiled as long as one of these
is enabled, and adapt the code to support this new scenario.
Also adapt the Kconfig text to explain the extra requirements for MT8173
and MT8183.
Reported-by: Sakari Ailus
Signed-off-by: Alexandre Courbot
Acked-by: Randy Dunlap # build-tested
---
drivers/media/platform/Kconfig| 10 +--
.../media/platform/mtk-vcodec/mtk_vcodec_fw.c | 72 ---
2 files changed, 54 insertions(+), 28 deletions(-)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index a3cb104956d5..98eb62e49ec2 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -253,14 +253,16 @@ config VIDEO_MEDIATEK_VCODEC
depends on MTK_IOMMU || COMPILE_TEST
depends on VIDEO_DEV && VIDEO_V4L2
depends on ARCH_MEDIATEK || COMPILE_TEST
+ depends on VIDEO_MEDIATEK_VPU || MTK_SCP
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
- select VIDEO_MEDIATEK_VPU
- select MTK_SCP
help
Mediatek video codec driver provides HW capability to
- encode and decode in a range of video formats
- This driver rely on VPU driver to communicate with VPU.
+ encode and decode in a range of video formats on MT8173
+ and MT8183.
+
+ Note that support for MT8173 requires VIDEO_MEDIATEK_VPU to
+ also be selected. Support for MT8183 depends on MTK_SCP.
To compile this driver as modules, choose M here: the
modules will be called mtk-vcodec-dec and mtk-vcodec-enc.
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c
index 6c2a2568d844..23a80027a8fb 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c
@@ -13,6 +13,7 @@ struct mtk_vcodec_fw_ops {
mtk_vcodec_ipi_handler handler, const char *name,
void *priv);
int (*ipi_send)(struct mtk_vcodec_fw *fw, int id, void *buf,
unsigned int len, unsigned int wait);
+ void (*release)(struct mtk_vcodec_fw *fw);
};
struct mtk_vcodec_fw {
@@ -22,6 +23,8 @@ struct mtk_vcodec_fw {
struct mtk_scp *scp;
};
+#if IS_ENABLED(CONFIG_VIDEO_MEDIATEK_VPU)
+
static int mtk_vcodec_vpu_load_firmware(struct mtk_vcodec_fw *fw)
{
return vpu_load_firmware(fw->pdev);
@@ -64,6 +67,27 @@ static int mtk_vcodec_vpu_ipi_send(struct mtk_vcodec_fw *fw,
int id, void *buf,
return vpu_ipi_send(fw->pdev, id, buf, len);
}
+static void mtk_vcodec_vpu_release(struct mtk_vcodec_fw *fw)
+{
+ put_device(&fw->pdev->dev);
+}
+
+static void mtk_vcodec_vpu_reset_handler(void *priv)
+{
+ struct mtk_vcodec_dev *dev = priv;
+ struct mtk_vcodec_ctx *ctx;
+
+ mtk_v4l2_err("Watchdog timeout!!");
+
+ mutex_lock(&dev->dev_mutex);
+ list_for_each_entry(ctx, &dev->ctx_list, list) {
+ ctx->state = MTK_STATE_ABORT;
+ mtk_v4l2_debug(0, "[%d] Change to state MTK_STATE_ABORT",
+ ctx->id);
+ }
+ mutex_unlock(&dev->dev_mutex);
+}
+
static const struct mtk_vcodec_fw_ops mtk_vcodec_vpu_msg = {
.load_firmware = mtk_vcodec_vpu_load_firmware,
.get_vdec_capa = mtk_vcodec_vpu_get_vdec_capa,
@@ -71,8 +95,13 @@ static const struct mtk_vcodec_fw_ops mtk_vcodec_vpu_msg = {
.map_dm_addr = mtk_vcodec_vpu_map_dm_addr,
.ipi_register = mtk_vcodec_vpu_set_ipi_register,
.ipi_send = mtk_vcodec_vpu_ipi_send,
+ .release = mtk_vcodec_vpu_release,
};
+#endif /* IS_ENABLED(CONFIG_VIDEO_MEDIATEK_VPU) */
+
+#if IS_ENABLED(CONFIG_MTK_SCP)
+
static int mtk_vcodec_scp_load_firmware(struct mtk_vcodec_fw *fw)
{
return rproc_boot(scp_get_rproc(fw->scp));
@@ -107,6 +136,11 @@ static int mtk_vcodec_scp_ipi_send(struct mtk_vcodec_fw
*fw, int id, void *buf,
return scp_ipi_send(fw->scp, id, buf, len, wait);
}
+static void mtk_vcodec_scp_release(struct mtk_vcodec_fw *fw)
+{
+ scp_put(fw->scp);
+}
+
static const struct mtk_vcodec_fw_ops mtk_vcodec_rproc_msg = {
.load_firmware = mtk_vcodec_scp_load_firmware,
.get_vdec_capa = mtk_vcodec_scp_get_vdec_capa,
@@ -114,23 +148,10 @@ static const struct mtk_vcodec_fw_ops
mtk_vcodec_rproc_msg = {
.map_dm_addr = mtk_vcodec_vpu_scp_dm_addr,
.ipi_register = mtk_vcodec_scp_set_ipi_register,
.ipi_se
Re: [PATCH] media: mtk-vcodec: fix builds when remoteproc is disabled
On Sun, Oct 4, 2020 at 1:50 AM Randy Dunlap wrote: > > On 10/3/20 6:09 AM, Alexandre Courbot wrote: > > The addition of MT8183 support added a dependency on the SCP remoteproc > > module. However the initial patch used the "select" Kconfig directive, > > which may result in the SCP module to not be compiled if remoteproc was > > disabled. In such a case, mtk-vcodec would try to link against > > non-existent SCP symbols. "select" was clearly misused here as explained > > in kconfig-language.txt. > > > > Replace this by a "depends" directive on at least one of the VPU and > > SCP modules, to allow the driver to be compiled as long as one of these > > is enabled, and adapt the code to support this new scenario. > > > > Also adapt the Kconfig text to explain the extra requirements for MT8173 > > and MT8183. > > > > Reported-by: Sakari Ailus > > Signed-off-by: Alexandre Courbot > > I was seeing this also, so I checked this patch. WFM. > > Acked-by: Randy Dunlap # build-tested Thanks for checking! I will send a v2 with your Acked-by and fix. > > See below. > > > --- > > drivers/media/platform/Kconfig| 11 +-- > > .../media/platform/mtk-vcodec/mtk_vcodec_fw.c | 72 --- > > 2 files changed, 55 insertions(+), 28 deletions(-) > > > > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > > index a3cb104956d5..e559d9c529b6 100644 > > --- a/drivers/media/platform/Kconfig > > +++ b/drivers/media/platform/Kconfig > > @@ -253,14 +253,17 @@ config VIDEO_MEDIATEK_VCODEC > > depends on MTK_IOMMU || COMPILE_TEST > > depends on VIDEO_DEV && VIDEO_V4L2 > > depends on ARCH_MEDIATEK || COMPILE_TEST > > + depends on VIDEO_MEDIATEK_VPU || MTK_SCP > > select VIDEOBUF2_DMA_CONTIG > > select V4L2_MEM2MEM_DEV > > - select VIDEO_MEDIATEK_VPU > > - select MTK_SCP > > help > > Mediatek video codec driver provides HW capability to > > - encode and decode in a range of video formats > > - This driver rely on VPU driver to communicate with VPU. > > + encode and decode in a range of video formats on MT8173 > > + and MT8183. > > + > > + Note that support for support for MT8173 requires > > Drop one of "support for" above. (or "for support" ;) > > > + VIDEO_MEDIATEK_VPU to also be selected. Support for > > + MT8183 depends on MTK_SCP. > > > > To compile this driver as modules, choose M here: the > > modules will be called mtk-vcodec-dec and mtk-vcodec-enc. > > > thanks. > -- > ~Randy
Re: [PATCH] Revert "Bluetooth: Update resolving list when updating whitelist"
On Sun, 2020-10-04 at 12:51 +0200, Greg Kroah-Hartman wrote:
> On Sat, Oct 03, 2020 at 08:33:18PM +0200, Marcel Holtmann wrote:
> > Hi Greg,
> >
> > > > > This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2
> > > > > as it
> > > > > breaks all bluetooth connections on my machine.
> > > > >
> > > > > Cc: Marcel Holtmann
> > > > > Cc: Sathish Narsimman
> > > > > Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when
> > > > > updating whitelist")
> > > > > Signed-off-by: Greg Kroah-Hartman
> > > > >
> > > > > ---
> > > > > net/bluetooth/hci_request.c | 41 ++--
> > > > > -
> > > > > 1 file changed, 2 insertions(+), 39 deletions(-)
> > > > >
> > > > > This has been bugging me for since 5.9-rc1, when all
> > > > > bluetooth devices
> > > > > stopped working on my desktop system. I finally got the time
> > > > > to do
> > > > > bisection today, and it came down to this patch. Reverting
> > > > > it on top of
> > > > > 5.9-rc7 restored bluetooth devices and now my input devices
> > > > > properly
> > > > > work.
> > > > >
> > > > > As it's almost 5.9-final, any chance this can be merged now
> > > > > to fix the
> > > > > issue?
> > > >
> > > > can you be specific what breaks since our guys and I also think
> > > > the
> > > > ChromeOS guys have been testing these series of patches
> > > > heavily.
> > >
> > > My bluetooth trackball does not connect at all. With this
> > > reverted, it
> > > all "just works".
> > >
> > > Same I think for a Bluetooth headset, can check that again if you
> > > really
> > > need me to, but the trackball is reliable here.
> > >
> > > > When you run btmon does it indicate any errors?
> > >
> > > How do I run it and where are the errors displayed?
> >
> > you can do btmon -w trace.log and just let it run like tcdpump.
>
> Ok, attached.
>
> The device is not connecting, and then I open the gnome bluetooth
> dialog
> and it scans for devices in the area, but does not connect to my
> existing devices at all.
>
> Any ideas?
Use bluetoothctl instead, the Bluetooth Settings from GNOME also run a
discovery the whole time the panel is opened, and this breaks a fair
number of poor quality adapters. This is worked-around in the most
recent version, but using bluetoothctl is a better debugging option in
all cases.
Cheers
Re: [RFC][PATCHSET] epoll cleanups
On Sun, Oct 04, 2020 at 03:36:08AM +0100, Al Viro wrote: > Finally, there's the mess with reverse path check. When we insert > a new file into a epoll, we need to check that there won't be excessively long > (or excessively many) wakeup chains. If the target is not an epoll, we need > to check that for the target alone, but if it's another epoll we need the same > check done to everything reachable from that epoll. The way it's currently > done is Not Nice(tm): we collect the set of files to check and, once we have > verified the absence of loops, created a new epitem and inserted it into > the epoll data structures, we run reverse_path_check_proc() for every file > in the set. The set is maintained as a (global) cyclic list threaded through > some struct file. Everything is serialized on epmutex, so the list can be > global. Unfortunately, each struct file ends up with list_head embedded into > it, all for the sake of operation that is rare *and* involves a small fraction > of all struct file instances on the system. > Worse, files can end up disappearing while we are collecting the set; > explicit EPOLL_CTL_DEL does not grab epmutex, and final fput() won't touch > epmutex if all epitem refering to that file have already been removed. This > had been worked around this cycle (by grabbing temporary references to struct > file added to the set), but that's not a good solution. > What we need is to separate the head of epitem list (->f_ep_links) > from struct file; all we need in struct file is a reference to that head. > We could thread the list representing the set of files through those objects > (getting rid of 3 pointers in each struct file) and have epitem removal > free those objects if there's no epitems left *and* they are not included > into the set. Reference from struct file would be cleared as soon as there's > no epitems left. Dissolving the set would free those that have no epitems > left and thus would've been freed by ep_remove() if they hadn't been in the > set. > With some massage it can be done; we end up with > * 3 pointers gone from each struct file > * one pointer added to struct eventpoll > * two-pointer object kept for each non-epoll file that is currently watched by > some epoll. Have you considered just storing a pointer to each struct file in an epoll set in an XArray? Linked lists suck for modern CPUs, and there'd be no need to store any additional data in each struct file. Using xa_alloc() to store the pointer and throw away the index the pointer got stored at would leave you with something approximating a singly linked list, except it's an array. Which does zero memory allocations for a single entry and will then allocate a single node for your first 64 entries.
[RFC v5 1/1] selftests/cpuidle: Add support for cpuidle latency measurement
Measure cpuidle latencies on wakeup to determine and compare with the
advertsied wakeup latencies for each idle state.
Cpuidle wakeup latencies are determined for IPIs and can help
determine any deviations from what is advertsied by the hardware.
A baseline measurement for each case of IPIs is taken at 100 percent
CPU usage to quantify for the kernel-userpsace overhead
during execution.
Signed-off-by: Pratik Rajesh Sampat
---
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/cpuidle/Makefile | 7 +
tools/testing/selftests/cpuidle/cpuidle.c | 479 ++
tools/testing/selftests/cpuidle/settings | 1 +
4 files changed, 488 insertions(+)
create mode 100644 tools/testing/selftests/cpuidle/Makefile
create mode 100644 tools/testing/selftests/cpuidle/cpuidle.c
create mode 100644 tools/testing/selftests/cpuidle/settings
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 9018f45d631d..2bb0e87f76fd 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -8,6 +8,7 @@ TARGETS += cgroup
TARGETS += clone3
TARGETS += core
TARGETS += cpufreq
+TARGETS += cpuidle
TARGETS += cpu-hotplug
TARGETS += drivers/dma-buf
TARGETS += efivarfs
diff --git a/tools/testing/selftests/cpuidle/Makefile
b/tools/testing/selftests/cpuidle/Makefile
new file mode 100644
index ..d332485e1bc5
--- /dev/null
+++ b/tools/testing/selftests/cpuidle/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+TEST_GEN_PROGS := cpuidle
+
+CFLAGS += -O2
+LDLIBS += -lpthread
+
+include ../lib.mk
diff --git a/tools/testing/selftests/cpuidle/cpuidle.c
b/tools/testing/selftests/cpuidle/cpuidle.c
new file mode 100644
index ..b2f6a0e655b8
--- /dev/null
+++ b/tools/testing/selftests/cpuidle/cpuidle.c
@@ -0,0 +1,479 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Cpuidle latency measurement microbenchmark
+ *
+ * A mechanism to measure wakeup latency for IPI based interrupts. Results of
+ * this microbenchmark can be used to check and validate against the
+ * advertised latencies for each cpuidle state
+ *
+ * IPIs (using pipes) are used to wake the CPU up and measure the
+ * time difference
+ *
+ * Baseline measurements on 100 busy load are used to account for the
+ * kernel-userspace overhead
+ *
+ * Usage:
+ * ./cpuidle --mode --output
+ *
+ * Copyright (C) 2020 Pratik Rajesh Sampat , IBM
+ */
+
+#define _GNU_SOURCE
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define READ 0
+#define WRITE 1
+
+static int pipe_fd[2];
+static int *cpu_list;
+static int cpus;
+static int idle_states;
+static uint64_t *latency_list;
+
+static char *log_file = "cpuidle.log";
+
+static int get_online_cpus(int *online_cpu_list, int total_cpus)
+{
+ char filename[80];
+ int i, index = 0;
+ FILE *fptr;
+
+ for (i = 0; i < total_cpus; i++) {
+ char status;
+
+ sprintf(filename, "/sys/devices/system/cpu/cpu");
+ sprintf(filename + strlen(filename), "%d%s", i, "/online");
+ fptr = fopen(filename, "r");
+ if (!fptr)
+ continue;
+ assert(fscanf(fptr, "%c", &status) != EOF);
+ if (status == '1')
+ online_cpu_list[index++] = i;
+ fclose(fptr);
+ }
+ return index;
+}
+
+static uint64_t us_to_ns(uint64_t val)
+{
+ return val * 1000;
+}
+
+static void get_latency(int cpu)
+{
+ char filename[80];
+ uint64_t latency;
+ FILE *fptr;
+ int state;
+
+ for (state = 0; state < idle_states; state++) {
+ sprintf(filename, "%s%d%s%d%s", "/sys/devices/system/cpu/cpu",
+ cpu, "/cpuidle/state",
+ state, "/latency");
+ fptr = fopen(filename, "r");
+ assert(fptr);
+
+ assert(fscanf(fptr, "%ld", &latency) != EOF);
+ latency_list[state] = latency;
+ fclose(fptr);
+ }
+}
+
+static int get_idle_state_count(int cpu)
+{
+ struct dirent *entry;
+ int dir_count = 0;
+ char filename[80];
+ DIR *dirp;
+
+ sprintf(filename, "%s%d%s", "/sys/devices/system/cpu/cpu",
+ cpu, "/cpuidle");
+
+ dirp = opendir(filename);
+ if (!dirp)
+ return -1;
+ while (entry = readdir(dirp)) {
+ if (entry->d_type == DT_DIR) {
+ if (strcmp(entry->d_name, ".") == 0 ||
+ strcmp(entry->d_name, "..") == 0)
+ continue;
+ dir_count++;
+ }
+ }
+ closedir(dirp);
+ return dir_count;
+}
+
+/* Enable or disable all idle states */
+static int state_all_idle(char *disable)
+{
+ cha
[RFC v5 0/1] Selftest for cpuidle latency measurement
v4: https://lkml.org/lkml/2020/9/2/356 v4-->v5 Based on comments from Artem Bityutskiy, evaluation of timer based wakeup latencies may not be a fruitful measurement especially on the x86 platform which has the capability to pre-arm a CPU when a timer is set. Hence, including only the IPI based tests for latency measurement to acheive expected behaviour across platforms. kernel module + bash selftest approach which presents lower deviations and higher accuracy: https://lkml.org/lkml/2020/7/21/567 --- The patch series introduces a mechanism to measure wakeup latency for IPI based interrupts. The motivation behind this series is to find significant deviations behind advertised latency values To achieve this in the userspace, IPI latencies are calculated by sending information through pipes and inducing a wakeup. To account for delays from kernel-userspace interactions baseline observations are taken on a 100% busy CPU and subsequent obervations must be considered relative to that. One downside of the userspace approach in contrast to the kernel implementation is that the run to run variance can turn out to be high in the order of ms; which is the scope of the experiments at times. Another downside of the userspace approach is that it takes much longer to run and hence a command-line option quick and full are added to make sure quick 1 CPU tests can be carried out when needed and otherwise it can carry out a full system comprehensive test. Usage --- ./cpuidle --mode --output full: runs on all CPUS quick: run on a random CPU num_cpus: Limit the number of CPUS to run on Sample output snippet - --IPI Latency Test--- SRC_CPU DEST_CPU IPI_Latency(ns) ... 0 5 256178 0 6 478161 0 7 285445 0 8 273553 Expected IPI latency(ns): 10 Observed Average IPI latency(ns): 248334 Pratik Rajesh Sampat (1): selftests/cpuidle: Add support for cpuidle latency measurement tools/testing/selftests/Makefile | 1 + tools/testing/selftests/cpuidle/Makefile | 7 + tools/testing/selftests/cpuidle/cpuidle.c | 479 ++ tools/testing/selftests/cpuidle/settings | 1 + 4 files changed, 488 insertions(+) create mode 100644 tools/testing/selftests/cpuidle/Makefile create mode 100644 tools/testing/selftests/cpuidle/cpuidle.c create mode 100644 tools/testing/selftests/cpuidle/settings -- 2.26.2
Re: [BUG] slab: double free detected in cache 'kmalloc-128', objp daff5780
On Tue, Sep 15, 2020 at 1:00 PM Randy Dunlap wrote: > > On 9/15/20 4:41 AM, Peter Geis wrote: > > [33633.566567] [] (unwind_backtrace) from [] > > (show_stack+0x10/0x14) > > Hi Peter, > > In the future, could you prevent long lines from being line-wrapped? > E.g., the 2 lines above should all be on one line. > It is much harder to read as it was posted. Apologies, I'll be sure to use an external client for bug reports from now on. > > thanks. > -- > ~Randy > This issue appears to have been resolved by: 678ff6a7afcc mm: slab: fix potential double free in ___cache_free Thank you.
Re: [PATCH v3 6/7] can: usb: etas_es58X: add support for ETAS ES58X CAN USB interfaces
On 10/2/20 5:41 PM, Vincent Mailhol wrote:
> This driver supports the ES581.4, ES582.1 and ES584.1 interfaces from
> ETAS GmbH (https://www.etas.com/en/products/es58x.php).
>
> Co-developed-by: Arunachalam Santhanam
> Signed-off-by: Arunachalam Santhanam
> Signed-off-by: Vincent Mailhol
> ---
>
> Changes in v3:
> - Remove all the calls to likely() and unlikely().
>
> Changes in v2:
> - Fixed -W1 warnings (v1 was tested with GCC -WExtra but not with -W1).
> ---
> drivers/net/can/usb/Kconfig |9 +
> drivers/net/can/usb/Makefile|1 +
> drivers/net/can/usb/etas_es58x/Makefile |3 +
> drivers/net/can/usb/etas_es58x/es581_4.c| 559
> drivers/net/can/usb/etas_es58x/es581_4.h| 237 ++
> drivers/net/can/usb/etas_es58x/es58x_core.c | 2725 +++
> drivers/net/can/usb/etas_es58x/es58x_core.h | 700 +
> drivers/net/can/usb/etas_es58x/es58x_fd.c | 648 +
> drivers/net/can/usb/etas_es58x/es58x_fd.h | 243 ++
> 9 files changed, 5125 insertions(+)
> create mode 100644 drivers/net/can/usb/etas_es58x/Makefile
> create mode 100644 drivers/net/can/usb/etas_es58x/es581_4.c
> create mode 100644 drivers/net/can/usb/etas_es58x/es581_4.h
> create mode 100644 drivers/net/can/usb/etas_es58x/es58x_core.c
> create mode 100644 drivers/net/can/usb/etas_es58x/es58x_core.h
> create mode 100644 drivers/net/can/usb/etas_es58x/es58x_fd.c
> create mode 100644 drivers/net/can/usb/etas_es58x/es58x_fd.h
[...]
Just one header file for now :)
> diff --git a/drivers/net/can/usb/etas_es58x/es58x_core.h
> b/drivers/net/can/usb/etas_es58x/es58x_core.h
> new file mode 100644
> index ..359ddc44a3ad
> --- /dev/null
> +++ b/drivers/net/can/usb/etas_es58x/es58x_core.h
> @@ -0,0 +1,700 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +/* Driver for ETAS GmbH ES58X USB CAN(-FD) Bus Interfaces.
> + *
> + * File es58x_core.h: All common definitions and declarations.
> + *
> + * Copyright (C) 2019 Robert Bosch Engineering and Business
> + * Solutions. All rights reserved.
> + * Copyright (C) 2020 ETAS K.K.. All rights reserved.
> + */
> +
> +#ifndef __ES58X_COMMON_H__
> +#define __ES58X_COMMON_H__
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "es581_4.h"
> +#include "es58x_fd.h"
> +
> +/* Size of a CAN Standard Frame (rounded up and ignoring bitsuffing). */
> +#define ES58X_SFF_BYTES(data_len) (round_up(47, 8) / 8 + (data_len))
DIV_ROUNDUP
> +/* Size of a CAN Extended Frame (rounded up and ignoring bitsuffing). */
> +#define ES58X_EFF_BYTES(data_len) (round_up(67, 8) / 8 + (data_len))
dame here
> +/* Maximum size of a CAN frame (rounded up and ignoring bitsuffing). */
> +#define ES58X_CAN_FRAME_BYTES_MAX ES58X_EFF_BYTES(CAN_MAX_DLEN)
please add a new file between the define and the doc of the next one
> +/* Maximum size of a CAN-FD frame (rough estimation because
> + * ES58X_SFF_BYTES() and ES58X_EFF_BYTES() macros are using the
> + * constant values for CAN not CAN-FD).
> + */
> +#define ES58X_CANFD_FRAME_BYTES_MAX ES58X_EFF_BYTES(CANFD_MAX_DLEN)
> +
> +/* Driver constants */
> +#define ES58X_RX_URBS_MAX 5 // Empirical value
> +#define ES58X_TX_URBS_MAX 8 // Empirical value
please use one space only
> +
> +#define ES58X_MAX(param) \
> + (ES581_4_##param > ES58X_FD_##param ? \
> + ES581_4_##param : ES58X_FD_##param)
> +#define ES58X_TX_BULK_MAX ES58X_MAX(TX_BULK_MAX)
> +#define ES58X_RX_BULK_MAX ES58X_MAX(RX_BULK_MAX)
> +#define ES58X_RX_LOOPBACK_BULK_MAX ES58X_MAX(RX_LOOPBACK_BULK_MAX)
> +#define ES58X_NUM_CAN_CH_MAX ES58X_MAX(NUM_CAN_CH)
> +
> +/* Use this when channel index is irrelevant (e.g. device
> + * timestamp).
> + */
> +#define ES58X_CHANNEL_IDX_NA 0xFF
> +#define ES58X_EMPTY_MSG NULL
> +
> +/* Threshold on consecutive CAN_STATE_ERROR_PASSIVE. If we receive
> + * ES58X_CONSECUTIVE_ERR_PASSIVE_MAX times the event
> + * ES58X_ERR_CRTL_PASSIVE in a row without any successful Rx or Tx,
> + * we force the device to switch to CAN_STATE_BUS_OFF state.
> + */
> +#define ES58X_CONSECUTIVE_ERR_PASSIVE_MAX 254
Does the device recover from bus off automatically or why is this needed?
> +
> +enum es58x_self_reception_mode {
> + ES58X_SELF_RECEPTION_OFF = 0,
> + ES58X_SELF_RECEPTION_ON = 1
> +};
nitpick: can you name all enums (here and below) according to the type?
e.g. ES58x_SELF_RECEPTION_MODE_OFF
> +
> +enum es58x_physical_media {
> + ES58X_MEDIA_HIGH_SPEED = 1,
> + ES58X_MEDIA_FAULT_TOLERANT = 2
You mean with FAULT_TOLERANT you mean ISO 11898-3? According to [1] they should
be named low speed.
[1]
https://can-cia.org/news/press-releases/view/harmonized-transceiver-naming/2020/7/16/
> +};
> +
> +enum es58x_samples_per_bit {
> + ES58X_ONE_SAMPLE_PER_BIT = 1,
> +
> + /* Some CAN controllers do not support three samples per
> + * bit. In this case the default value of one sample per bi
Re: [PATCH 2/2] mm/frame-vec: use FOLL_LONGTERM
On Sun, Oct 4, 2020 at 1:24 AM Jason Gunthorpe wrote:
> On Sat, Oct 03, 2020 at 03:52:32PM -0700, John Hubbard wrote:
> > On 10/3/20 2:45 AM, Daniel Vetter wrote:
> > > On Sat, Oct 3, 2020 at 12:39 AM John Hubbard wrote:
> > > >
> > > > On 10/2/20 10:53 AM, Daniel Vetter wrote:
> > > > > For $reasons I've stumbled over this code and I'm not sure the change
> > > > > to the new gup functions in 55a650c35fea ("mm/gup: frame_vector:
> > > > > convert get_user_pages() --> pin_user_pages()") was entirely correct.
> > > > >
> > > > > This here is used for long term buffers (not just quick I/O) like
> > > > > RDMA, and John notes this in his patch. But I thought the rule for
> > > > > these is that they need to add FOLL_LONGTERM, which John's patch
> > > > > didn't do.
> > > >
> > > > Yep. The earlier gup --> pup conversion patches were intended to not
> > > > have any noticeable behavior changes, and FOLL_LONGTERM, with it's
> > > > special cases and such, added some risk that I wasn't ready to take
> > > > on yet. Also, FOLL_LONGTERM rules are only *recently* getting firmed
> > > > up. So there was some doubt at least in my mind, about which sites
> > > > should have it.
> > > >
> > > > But now that we're here, I think it's really good that you've brought
> > > > this up. It's definitely time to add FOLL_LONGTERM wherever it's
> > > > missing.
> > >
> > > So should I keep this patch, or will it collide with a series you're
> > > working on?
> >
> > It doesn't collide with anything on my end yet, because I've been slow to
> > pick up on the need for changing callsites to add FOLL_LONGTERM. :)
> >
> > And it looks like that's actually a problem, because:
> >
> > >
> > > Also with the firmed up rules, correct that I can also drop the
> > > vma_is_fsdax check when the FOLL_LONGTERM flag is set?
> >
> > That's the right direction to go *in general*, but I see that the
> > pin_user_pages code is still a bit stuck in the past. And this patch
> > won't actually work, with or without that vma_is_fsdax() check.
> > Because:
> >
> > get_vaddr_frames(FOLL_LONGTERM)
> >pin_user_pages_locked()
> > if (WARN_ON_ONCE(gup_flags & FOLL_LONGTERM))
> > return -EINVAL;
>
> There is no particular reason this code needs to have the mm sem at
> that point.
>
> It should call pin_user_pages_fast() and only if that fails get the mmap
> lock and extract the VMA to do broken hackery.
Yeah I think that works. I tried understanding gup.c code a bit more,
and it looks like FOLL_LONGTERM only works for the pup_fast variant
right now? All others seem to have this comment that it's somehow
incompatible with FAULT_FLAG_ALLOW_RETRY and daxfs. But grepping
around for that didn't show up anything, at least not nearby dax code.
For my understanding of all this, what's the hiccup there?
For plans, I only started this for a bit of my own learning, but I
think I'll respin with the following changes:
- convert exynos and habanalabs to pin_user_pages_fast directly,
instead of going through this frame-vector detour
- move the locking and convert get_vaddr_frames to pup_fast as Jason suggested
- hack up some truly gross rfc to plug the follow_pfn hole
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v3 5/7] can: dev: add a helper function to calculate the duration of one bit
On 10/4/20 1:06 PM, Marc Kleine-Budde wrote:
> On 10/2/20 5:41 PM, Vincent Mailhol wrote:
>> Rename macro CAN_CALC_SYNC_SEG to CAN_SYNC_SEG and make it available
>> through include/linux/can/dev.h
>>
>> Add an helper function can_bit_time() which returns the duration (in
>> time quanta) of one CAN bit.
>>
>> Rationale for this patch: the sync segment and the bit time are two
>> concepts which are defined in the CAN ISO standard. Device drivers for
>> CAN might need those.
>>
>> Please refer to ISO 11898-1:2015, section 11.3.1.1 "Bit time" for
>> additional information.
>>
>> Signed-off-by: Vincent Mailhol
[...]
>> index 791c452d98e1..77c3ea49b8fb 100644
>> --- a/include/linux/can/dev.h
>> +++ b/include/linux/can/dev.h
>> @@ -82,6 +82,21 @@ struct can_priv {
>> #endif
>> };
>>
>> +#define CAN_SYNC_SEG 1
>> +
>> +/*
>> + * can_bit_time() - Duration of one bit
>> + *
>> + * Please refer to ISO 11898-1:2015, section 11.3.1.1 "Bit time" for
>> + * additional information.
>> + *
>> + * Return: the number of time quanta in one bit.
>> + */
>> +static inline int can_bit_time(struct can_bittiming *bt)
>
> make it return an unsigned int
> make the bt pointer const
I'll change this while applying the patch.
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 5/7] can: dev: add a helper function to calculate the duration of one bit
On 10/2/20 5:41 PM, Vincent Mailhol wrote:
> Rename macro CAN_CALC_SYNC_SEG to CAN_SYNC_SEG and make it available
> through include/linux/can/dev.h
>
> Add an helper function can_bit_time() which returns the duration (in
> time quanta) of one CAN bit.
>
> Rationale for this patch: the sync segment and the bit time are two
> concepts which are defined in the CAN ISO standard. Device drivers for
> CAN might need those.
>
> Please refer to ISO 11898-1:2015, section 11.3.1.1 "Bit time" for
> additional information.
>
> Signed-off-by: Vincent Mailhol
> ---
>
> Changes in v3: None
>
> Changes in v2: None
> ---
> drivers/net/can/dev.c | 13 ++---
> include/linux/can/dev.h | 15 +++
> 2 files changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
> index 8c3e11820e03..6070b4ab3bd8 100644
> --- a/drivers/net/can/dev.c
> +++ b/drivers/net/can/dev.c
> @@ -60,7 +60,6 @@ EXPORT_SYMBOL_GPL(can_len2dlc);
>
> #ifdef CONFIG_CAN_CALC_BITTIMING
> #define CAN_CALC_MAX_ERROR 50 /* in one-tenth of a percent */
> -#define CAN_CALC_SYNC_SEG 1
>
> /* Bit-timing calculation derived from:
> *
> @@ -86,8 +85,8 @@ can_update_sample_point(const struct can_bittiming_const
> *btc,
> int i;
>
> for (i = 0; i <= 1; i++) {
> - tseg2 = tseg + CAN_CALC_SYNC_SEG -
> - (sample_point_nominal * (tseg + CAN_CALC_SYNC_SEG)) /
> + tseg2 = tseg + CAN_SYNC_SEG -
> + (sample_point_nominal * (tseg + CAN_SYNC_SEG)) /
> 1000 - i;
> tseg2 = clamp(tseg2, btc->tseg2_min, btc->tseg2_max);
> tseg1 = tseg - tseg2;
> @@ -96,8 +95,8 @@ can_update_sample_point(const struct can_bittiming_const
> *btc,
> tseg2 = tseg - tseg1;
> }
>
> - sample_point = 1000 * (tseg + CAN_CALC_SYNC_SEG - tseg2) /
> - (tseg + CAN_CALC_SYNC_SEG);
> + sample_point = 1000 * (tseg + CAN_SYNC_SEG - tseg2) /
> + (tseg + CAN_SYNC_SEG);
> sample_point_error = abs(sample_point_nominal - sample_point);
>
> if (sample_point <= sample_point_nominal &&
> @@ -145,7 +144,7 @@ static int can_calc_bittiming(struct net_device *dev,
> struct can_bittiming *bt,
> /* tseg even = round down, odd = round up */
> for (tseg = (btc->tseg1_max + btc->tseg2_max) * 2 + 1;
>tseg >= (btc->tseg1_min + btc->tseg2_min) * 2; tseg--) {
> - tsegall = CAN_CALC_SYNC_SEG + tseg / 2;
> + tsegall = CAN_SYNC_SEG + tseg / 2;
>
> /* Compute all possible tseg choices (tseg=tseg1+tseg2) */
> brp = priv->clock.freq / (tsegall * bt->bitrate) + tseg % 2;
> @@ -223,7 +222,7 @@ static int can_calc_bittiming(struct net_device *dev,
> struct can_bittiming *bt,
>
> /* real bitrate */
> bt->bitrate = priv->clock.freq /
> - (bt->brp * (CAN_CALC_SYNC_SEG + tseg1 + tseg2));
> + (bt->brp * (CAN_SYNC_SEG + tseg1 + tseg2));
>
> return 0;
> }
> diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
> index 791c452d98e1..77c3ea49b8fb 100644
> --- a/include/linux/can/dev.h
> +++ b/include/linux/can/dev.h
> @@ -82,6 +82,21 @@ struct can_priv {
> #endif
> };
>
> +#define CAN_SYNC_SEG 1
> +
> +/*
> + * can_bit_time() - Duration of one bit
> + *
> + * Please refer to ISO 11898-1:2015, section 11.3.1.1 "Bit time" for
> + * additional information.
> + *
> + * Return: the number of time quanta in one bit.
> + */
> +static inline int can_bit_time(struct can_bittiming *bt)
make it return an unsigned int
make the bt pointer const
> +{
> + return CAN_SYNC_SEG + bt->prop_seg + bt->phase_seg1 + bt->phase_seg2;
> +}
> +
> /*
> * get_can_dlc(value) - helper macro to cast a given data length code (dlc)
> * to u8 and ensure the dlc value to be max. 8 bytes.
>
tnx,
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] USB: serial: option: Add Telit FT980-KS composition
On 10/4/2020 16:57, Leonid Bloch wrote: This commit adds the following Telit FT980-KS composition: 0x1054: rndis, diag, adb, nmea, modem, modem, aux AT commands can be sent to /dev/ttyUSB5. Please submit a verbose lsusb listing for the device, I can't imagine that the adb interface should be handled by the option serial driver so there will never be a ttyUSB5. thanks Lars
Re: [PATCH] Revert "Bluetooth: Update resolving list when updating whitelist"
On Sun, Oct 04, 2020 at 12:51:24PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Oct 03, 2020 at 08:33:18PM +0200, Marcel Holtmann wrote:
> > Hi Greg,
> >
> > >>> This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it
> > >>> breaks all bluetooth connections on my machine.
> > >>>
> > >>> Cc: Marcel Holtmann
> > >>> Cc: Sathish Narsimman
> > >>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating
> > >>> whitelist")
> > >>> Signed-off-by: Greg Kroah-Hartman
> > >>> ---
> > >>> net/bluetooth/hci_request.c | 41 ++---
> > >>> 1 file changed, 2 insertions(+), 39 deletions(-)
> > >>>
> > >>> This has been bugging me for since 5.9-rc1, when all bluetooth devices
> > >>> stopped working on my desktop system. I finally got the time to do
> > >>> bisection today, and it came down to this patch. Reverting it on top of
> > >>> 5.9-rc7 restored bluetooth devices and now my input devices properly
> > >>> work.
> > >>>
> > >>> As it's almost 5.9-final, any chance this can be merged now to fix the
> > >>> issue?
> > >>
> > >> can you be specific what breaks since our guys and I also think the
> > >> ChromeOS guys have been testing these series of patches heavily.
> > >
> > > My bluetooth trackball does not connect at all. With this reverted, it
> > > all "just works".
> > >
> > > Same I think for a Bluetooth headset, can check that again if you really
> > > need me to, but the trackball is reliable here.
> > >
> > >> When you run btmon does it indicate any errors?
> > >
> > > How do I run it and where are the errors displayed?
> >
> > you can do btmon -w trace.log and just let it run like tcdpump.
>
> Ok, attached.
>
> The device is not connecting, and then I open the gnome bluetooth dialog
> and it scans for devices in the area, but does not connect to my
> existing devices at all.
>
And any hints on how to read this file? 'btsnoop' has no man page, and
the --help options are pretty sparse :(
thanks,
greg k-h
Re: [PATCH] Revert "Bluetooth: Update resolving list when updating whitelist"
On Sat, Oct 03, 2020 at 08:33:18PM +0200, Marcel Holtmann wrote:
> Hi Greg,
>
> >>> This reverts commit 0eee35bdfa3b472cc986ecc6ad76293fdcda59e2 as it
> >>> breaks all bluetooth connections on my machine.
> >>>
> >>> Cc: Marcel Holtmann
> >>> Cc: Sathish Narsimman
> >>> Fixes: 0eee35bdfa3b ("Bluetooth: Update resolving list when updating
> >>> whitelist")
> >>> Signed-off-by: Greg Kroah-Hartman
> >>> ---
> >>> net/bluetooth/hci_request.c | 41 ++---
> >>> 1 file changed, 2 insertions(+), 39 deletions(-)
> >>>
> >>> This has been bugging me for since 5.9-rc1, when all bluetooth devices
> >>> stopped working on my desktop system. I finally got the time to do
> >>> bisection today, and it came down to this patch. Reverting it on top of
> >>> 5.9-rc7 restored bluetooth devices and now my input devices properly
> >>> work.
> >>>
> >>> As it's almost 5.9-final, any chance this can be merged now to fix the
> >>> issue?
> >>
> >> can you be specific what breaks since our guys and I also think the
> >> ChromeOS guys have been testing these series of patches heavily.
> >
> > My bluetooth trackball does not connect at all. With this reverted, it
> > all "just works".
> >
> > Same I think for a Bluetooth headset, can check that again if you really
> > need me to, but the trackball is reliable here.
> >
> >> When you run btmon does it indicate any errors?
> >
> > How do I run it and where are the errors displayed?
>
> you can do btmon -w trace.log and just let it run like tcdpump.
Ok, attached.
The device is not connecting, and then I open the gnome bluetooth dialog
and it scans for devices in the area, but does not connect to my
existing devices at all.
Any ideas?
thanks,
greg k-h
btsnoop � 5 5�� ⎉,~�Linux version
5.9.0-rc7-4-g0216685bdd99 (x86_64)! !�� ⎉,~�Bluetooth subsystem
version
2.22 ⎉,~� pe��Phci0 ⎉,~�
⎉,~�pe��P �� ⎉,~� bluetoothd ⎉-:�L
⎉-:�Y �
⎉-:�p ⎉-:�q
⎉-:�� : ⎉-:��B
⎉-<�_B ⎉-<�n
���.& ⎉-<� ⎉-<�$A
$ ⎉-<��A ⎉-<��B
⎉-<�lB
⎉-<�t3�� ⎉-<�'
⎉-<�T : ⎉-<�^ ⎉-<Ŗ �4�_� � 3 � � ⎉-<ŻR
� thread
k F7
3 ⎉-<��R
⎉-<�
⎉-<�0 �4�_� � 2 � � ⎉-<�9
��!5% �� o�o��wk�;QF*t����4� 3 3 ⎉-D�= ��!5%� o�o��wk�;QF*t����4�
⎉-E=pB ⎉-EH�B
⎉-EH�B ⎉-ET�B : : ⎉-H�Y>8
*�!�o� �� �L t'�ڶDE � r��5 IP� 4 4 ⎉-H�!>2
*�!�o� �� "
S19743271de39a3d6C J J ⎉-H�@ *�!�o��6 �L t'�ڶDE �
r��5 IP�" S19743271de39a3d6C 5 5 ⎉-I�>3
��!lT �� & MyRun 18004074 # # ⎉-I
�>!
��!lT �� &4 4 ⎉-I
� ��!lT� & MyRun 18004074&
⎉-L �B ⎉-L�B ⎉-L�B
⎉-L&�B ⎉-L�/�6 �ZV( <�[�
KD-43XD8305
=d� d
B B ⎉-L�' 6 �ZV( �.
KD-43XD8305
=d� d
< 5 5 ⎉-M8%>3
��!lT �� & MyRun 18004074 # # ⎉-M?�>!
��!lT �� &4 4 ⎉-M@ ��!lT�
&MyRun 18004074& ⎉-O�SB
⎉-O��B ⎉-O��B
⎉-O�VB 5 5 ⎉-P�>3
��!lT �� & MyRun 18004074 # # ⎉-P
�>!
��!lT �� &4 4 ⎉-P
� ��!lT� & MyRun 18004074&
⎉-S$]B ⎉-S38B ⎉-S3]B
⎉-S@�B : :
[PATCH] ASoC: omap-mcbsp: Fix use of uninitialised pointer
Commit 9c34d023dc35 ("ASoC: omap-mcbsp: Re-arrange files for core McBSP
and Sidetone function split"), in rearranging various files, also replaced
calls to platform_get_resource_by_name() + devm_ioremap_resource() with a
single call to devm_platform_ioremap_resource_byname(). However, the
struct resource is needed as we access its members so at present a null
pointer is dereferenced. Fix by doing things the old way.
Addresses-Coverity-ID: 1497530 ("Memory - illegal accesses")
Fixes: 9c34d023dc35 ("ASoC: omap-mcbsp: Re-arrange files for core McBSP and
Sidetone function split")
Signed-off-by: Alex Dewar
---
sound/soc/ti/omap-mcbsp.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/sound/soc/ti/omap-mcbsp.c b/sound/soc/ti/omap-mcbsp.c
index 186cea91076f..6025b30bbe77 100644
--- a/sound/soc/ti/omap-mcbsp.c
+++ b/sound/soc/ti/omap-mcbsp.c
@@ -620,7 +620,11 @@ static int omap_mcbsp_init(struct platform_device *pdev)
spin_lock_init(&mcbsp->lock);
mcbsp->free = true;
- mcbsp->io_base = devm_platform_ioremap_resource_byname(pdev, "mpu");
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mpu");
+ if (!res)
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+ mcbsp->io_base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(mcbsp->io_base))
return PTR_ERR(mcbsp->io_base);
--
2.28.0
[PATCH v3] i2c: pxa: move to generic GPIO recovery
Starting with
commit 75820314de26 ("i2c: core: add generic I2C GPIO recovery")
GPIO bus recovery is supported by the I2C core, so we can remove the
driver implementation and use that one instead.
Signed-off-by: Codrin Ciubotariu
---
patch not tested.
Changes in v3:
- fix compile errors from unprepare_recovery callback
Changes in v2:
- readded the pinctrl state change to default from the
unprepare_recovery callback;
drivers/i2c/busses/i2c-pxa.c | 76
1 file changed, 8 insertions(+), 68 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 35ca2c02c9b9..a636ea0eb50a 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -264,9 +264,6 @@ struct pxa_i2c {
u32 hs_mask;
struct i2c_bus_recovery_info recovery;
- struct pinctrl *pinctrl;
- struct pinctrl_state*pinctrl_default;
- struct pinctrl_state*pinctrl_recovery;
};
#define _IBMR(i2c) ((i2c)->reg_ibmr)
@@ -1305,13 +1302,12 @@ static void i2c_pxa_prepare_recovery(struct i2c_adapter
*adap)
*/
gpiod_set_value(i2c->recovery.scl_gpiod, ibmr & IBMR_SCLS);
gpiod_set_value(i2c->recovery.sda_gpiod, ibmr & IBMR_SDAS);
-
- WARN_ON(pinctrl_select_state(i2c->pinctrl, i2c->pinctrl_recovery));
}
static void i2c_pxa_unprepare_recovery(struct i2c_adapter *adap)
{
struct pxa_i2c *i2c = adap->algo_data;
+ struct i2c_bus_recovery_info *bri = adap->bus_recovery_info;
u32 isr;
/*
@@ -1325,7 +1321,7 @@ static void i2c_pxa_unprepare_recovery(struct i2c_adapter
*adap)
i2c_pxa_do_reset(i2c);
}
- WARN_ON(pinctrl_select_state(i2c->pinctrl, i2c->pinctrl_default));
+ WARN_ON(pinctrl_select_state(bri->pinctrl, bri->pins_default));
dev_dbg(&i2c->adap.dev, "recovery: IBMR 0x%08x ISR 0x%08x\n",
readl(_IBMR(i2c)), readl(_ISR(i2c)));
@@ -1347,76 +1343,20 @@ static int i2c_pxa_init_recovery(struct pxa_i2c *i2c)
if (IS_ENABLED(CONFIG_I2C_PXA_SLAVE))
return 0;
- i2c->pinctrl = devm_pinctrl_get(dev);
- if (PTR_ERR(i2c->pinctrl) == -ENODEV)
- i2c->pinctrl = NULL;
- if (IS_ERR(i2c->pinctrl))
- return PTR_ERR(i2c->pinctrl);
-
- if (!i2c->pinctrl)
- return 0;
-
- i2c->pinctrl_default = pinctrl_lookup_state(i2c->pinctrl,
- PINCTRL_STATE_DEFAULT);
- i2c->pinctrl_recovery = pinctrl_lookup_state(i2c->pinctrl, "recovery");
-
- if (IS_ERR(i2c->pinctrl_default) || IS_ERR(i2c->pinctrl_recovery)) {
- dev_info(dev, "missing pinmux recovery information: %ld %ld\n",
-PTR_ERR(i2c->pinctrl_default),
-PTR_ERR(i2c->pinctrl_recovery));
- return 0;
- }
-
- /*
-* Claiming GPIOs can influence the pinmux state, and may glitch the
-* I2C bus. Do this carefully.
-*/
- bri->scl_gpiod = devm_gpiod_get(dev, "scl", GPIOD_OUT_HIGH_OPEN_DRAIN);
- if (bri->scl_gpiod == ERR_PTR(-EPROBE_DEFER))
- return -EPROBE_DEFER;
- if (IS_ERR(bri->scl_gpiod)) {
- dev_info(dev, "missing scl gpio recovery information: %pe\n",
-bri->scl_gpiod);
- return 0;
- }
-
- /*
-* We have SCL. Pull SCL low and wait a bit so that SDA glitches
-* have no effect.
-*/
- gpiod_direction_output(bri->scl_gpiod, 0);
- udelay(10);
- bri->sda_gpiod = devm_gpiod_get(dev, "sda", GPIOD_OUT_HIGH_OPEN_DRAIN);
-
- /* Wait a bit in case of a SDA glitch, and then release SCL. */
- udelay(10);
- gpiod_direction_output(bri->scl_gpiod, 1);
-
- if (bri->sda_gpiod == ERR_PTR(-EPROBE_DEFER))
- return -EPROBE_DEFER;
-
- if (IS_ERR(bri->sda_gpiod)) {
- dev_info(dev, "missing sda gpio recovery information: %pe\n",
-bri->sda_gpiod);
+ bri->pinctrl = devm_pinctrl_get(dev);
+ if (PTR_ERR(bri->pinctrl) == -ENODEV) {
+ bri->pinctrl = NULL;
return 0;
}
+ if (IS_ERR(bri->pinctrl))
+ return PTR_ERR(bri->pinctrl);
bri->prepare_recovery = i2c_pxa_prepare_recovery;
bri->unprepare_recovery = i2c_pxa_unprepare_recovery;
- bri->recover_bus = i2c_generic_scl_recovery;
i2c->adap.bus_recovery_info = bri;
- /*
-* Claiming GPIOs can change the pinmux state, which confuses the
-* pinctrl since pinctrl's idea of the current setting is unaffected
-* by the pinmux change caused by claiming the GPIO. Work around that
-* by switching pinctrl to the GPIO state here. We do it this way to
-* avoid glitching the I2C bus.
-*/
- pinctrl_select_state(i
[PATCH 2/2] ath11k: Handle errors if peer creation fails
ath11k_peer_create() is called without its return value being checked,
meaning errors will be unhandled. Add missing check and, as the mutex is
unconditionally unlocked on leaving this function, simplify the exit
path.
Addresses-Coverity-ID: 1497531 ("Code maintainability issues")
Fixes: 701e48a43e15 ("ath11k: add packet log support for QCA6390")
Signed-off-by: Alex Dewar
---
drivers/net/wireless/ath/ath11k/mac.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ath/ath11k/mac.c
b/drivers/net/wireless/ath/ath11k/mac.c
index 7f8dd47d2333..58db1b57b941 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -5211,7 +5211,7 @@ ath11k_mac_op_assign_vif_chanctx(struct ieee80211_hw *hw,
struct ath11k *ar = hw->priv;
struct ath11k_base *ab = ar->ab;
struct ath11k_vif *arvif = (void *)vif->drv_priv;
- int ret;
+ int ret = 0;
struct peer_create_params param;
mutex_lock(&ar->conf_mutex);
@@ -5225,13 +5225,12 @@ ath11k_mac_op_assign_vif_chanctx(struct ieee80211_hw
*hw,
arvif->vdev_type != WMI_VDEV_TYPE_AP &&
arvif->vdev_type != WMI_VDEV_TYPE_MONITOR) {
memcpy(&arvif->chanctx, ctx, sizeof(*ctx));
- mutex_unlock(&ar->conf_mutex);
- return 0;
+ goto unlock;
}
if (WARN_ON(arvif->is_started)) {
- mutex_unlock(&ar->conf_mutex);
- return -EBUSY;
+ ret = -EBUSY;
+ goto unlock;
}
if (ab->hw_params.vdev_start_delay) {
@@ -5239,6 +5238,8 @@ ath11k_mac_op_assign_vif_chanctx(struct ieee80211_hw *hw,
param.peer_type = WMI_PEER_TYPE_DEFAULT;
param.peer_addr = ar->mac_addr;
ret = ath11k_peer_create(ar, arvif, NULL, ¶m);
+ if (ret)
+ goto unlock;
}
ret = ath11k_mac_vdev_start(arvif, &ctx->def);
@@ -5246,23 +5247,19 @@ ath11k_mac_op_assign_vif_chanctx(struct ieee80211_hw
*hw,
ath11k_warn(ab, "failed to start vdev %i addr %pM on freq %d:
%d\n",
arvif->vdev_id, vif->addr,
ctx->def.chan->center_freq, ret);
- goto err;
+ goto unlock;
}
if (arvif->vdev_type == WMI_VDEV_TYPE_MONITOR) {
ret = ath11k_monitor_vdev_up(ar, arvif->vdev_id);
if (ret)
- goto err;
+ goto unlock;
}
arvif->is_started = true;
/* TODO: Setup ps and cts/rts protection */
- mutex_unlock(&ar->conf_mutex);
-
- return 0;
-
-err:
+unlock:
mutex_unlock(&ar->conf_mutex);
return ret;
--
2.28.0
[PATCH 1/2] ath11k: Fix memory leak on error path
In ath11k_mac_setup_iface_combinations(), if memory cannot be assigned
for the variable limits, then the memory assigned to combinations will
be leaked. Fix this.
Addresses-Coverity-ID: 1497534 ("Resource leaks")
Fixes: 2626c269702e ("ath11k: add interface_modes to hw_params")
Signed-off-by: Alex Dewar
---
drivers/net/wireless/ath/ath11k/mac.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath11k/mac.c
b/drivers/net/wireless/ath/ath11k/mac.c
index 3f63a7bd6b59..7f8dd47d2333 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -6041,8 +6041,10 @@ static int ath11k_mac_setup_iface_combinations(struct
ath11k *ar)
n_limits = 2;
limits = kcalloc(n_limits, sizeof(*limits), GFP_KERNEL);
- if (!limits)
+ if (!limits) {
+ kfree(combinations);
return -ENOMEM;
+ }
limits[0].max = 1;
limits[0].types |= BIT(NL80211_IFTYPE_STATION);
--
2.28.0
RE: [PATCH 1/8] staging: rtl8723bs: replace RND4 with round_up()
From: Ross Schmidt > Sent: 04 October 2020 02:18 > > Use round_up instead of define RND4. RND4 was also particularly horrid! ... > diff --git a/drivers/staging/rtl8723bs/core/rtw_security.c > b/drivers/staging/rtl8723bs/core/rtw_security.c > index 7f74e1d05b3a..159d32ace2bc 100644 > --- a/drivers/staging/rtl8723bs/core/rtw_security.c > +++ b/drivers/staging/rtl8723bs/core/rtw_security.c > @@ -260,7 +260,7 @@ void rtw_wep_encrypt(struct adapter *padapter, u8 > *pxmitframe) > arcfour_encrypt(&mycontext, payload+length, > crc, 4); > > pframe += pxmitpriv->frag_len; > - pframe = (u8 *)RND4((SIZE_PTR)(pframe)); > + pframe = (u8 *)round_up((SIZE_PTR)(pframe), 4); I also suspect this is equivalent to: pframe == round_up(pxmitpriv->frag_len, 4); Does make one wonder whether the skipped bytes need to be zeroed though. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: linux-next: build warning after merge of the tip tree
Hi Kees, On Sun, 4 Oct 2020 01:27:01 -0700 Kees Cook wrote: > > I assume CONFIG_CONSTRUCTORS is enabled for your build (it should be for yes, indeed. > allmodconfig). Does this patch fix it? (I'm kind of blindly guessing > based on my understanding of where this could be coming from...) > > > diff --git a/include/asm-generic/vmlinux.lds.h > b/include/asm-generic/vmlinux.lds.h > index e1843976754a..22f14956214a 100644 > --- a/include/asm-generic/vmlinux.lds.h > +++ b/include/asm-generic/vmlinux.lds.h > @@ -701,6 +701,7 @@ > #ifdef CONFIG_CONSTRUCTORS > #define KERNEL_CTORS() . = ALIGN(8); \ > __ctors_start = .; \ > + KEEP(*(SORT(.ctors.*)))\ > KEEP(*(.ctors))\ > KEEP(*(SORT(.init_array.*))) \ > KEEP(*(.init_array)) \ And that makes the messages go away. -- Cheers, Stephen Rothwell pgp3nrbL3eZIJ.pgp Description: OpenPGP digital signature
Re: [PATCH] arch: x86: power: cpu: init %gs before __restore_processor_state (clang)
Hi! > > > > > I believe the kernel makes a questionable assumption on how clang > > > > > uses registers (gs will not be used if stack protection is disabled). > > > > > Both kernel and clang behaves unfortunate here. > > > > > > > > If the kernel is at fault here and this same thing happens with GCC, > > > > sure, but this is a clang-specific fix. > > > > > > This is fair. Unfortunately I am not an x86 asm expert. I expect the > > > proper > > > fix should land into arch/x86/kernel/acpi/wakeup_64.S to init %gs > > > (maybe some more registers) before "jmp restore_processor_state". > > > > That would certainly be nicer / more acceptable solution than patch > > being proposed here. > > > > Code was written with assumption compiler random C code would not use > > %gs. If that's no longer true, fixing it in wakeup_64.S _with comments > > explaining what goes on_ might be solution. > > I looked and restore_processor_state is referenced in several places, > so changing > wakeup_64.S is not enough. Is moving the beginning of restore_processor_state > to an .S file ok? I see restore_processor_state initializes CR registers > first, > do you know if there is a reason to do so (can I init segment > registers before CR ones)? Yes, moving to .S file should be okay. CR first... makes sense to me, they really select how segment registers will be interpretted, etc. If it will work the other way... not sure. I'd keep existing code if I were you. This is tricky to debug. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [ANNOUNCE] Reiser5: Selective File Migration - User Interface
Hi! > > In particular, using this functionality, user is able to push out > > "hot" files on any high-performance device (e.g. proxy device) and pin > > them there. What permissions are normally required for file migration? > > COMMENT. After ioctl successful completion the file is not necessarily > > written to the target device! To make sure of it, call fsync(2) after > > successful ioctl completion, or open the file with O_SYNC flag before > > migration. Ok. > > COMMENT. File migration is a volume operation (like adding, removing a > > device to/from > > a logical volumes), and all volume operations are serialized. So, any > > attempt to > > migrate a file, while performing other operation on that volume will fail. > > If some > > file migration procedure fails (with EBUSY, or other errors), or was > > interrupted by > > user, then it should be repeated in the current mount session. File > > migration > > procedures interrupted by system crash, hared reset, etc) should be > > repeated in the > > next mount sessions. Dunno. Returning -EBUSY is kind of "interesting" there. I'd expect kernel to queue the callers, because userland can't really do that easily. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH v2] i2c: pxa: move to generic GPIO recovery
On 04.10.2020 12:24, Russell King - ARM Linux admin wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Sun, Oct 04, 2020 at 12:16:56PM +0300, Codrin Ciubotariu wrote:
>> Starting with
>> commit 75820314de26 ("i2c: core: add generic I2C GPIO recovery")
>> GPIO bus recovery is supported by the I2C core, so we can remove the
>> driver implementation and use that one instead.
>>
>> Signed-off-by: Codrin Ciubotariu
>> ---
>>
>> This patch is not tested.
>>
>> Changes in v2:
>> - readded the pinctrl state change to default from the
>> unprepare_recovery callback;
>
> I don't think you've build tested this patch...
You're right, sorry about that. I used a wrong config... Will fix it
right away.
Best regards,
Codrin
>
>> diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
>> index 35ca2c02c9b9..006cc1d5931f 100644
>> --- a/drivers/i2c/busses/i2c-pxa.c
>> +++ b/drivers/i2c/busses/i2c-pxa.c
>> @@ -264,9 +264,6 @@ struct pxa_i2c {
>>u32 hs_mask;
>>
>>struct i2c_bus_recovery_info recovery;
>> - struct pinctrl *pinctrl;
>> - struct pinctrl_state*pinctrl_default;
>> - struct pinctrl_state*pinctrl_recovery;
>
> i2c_pxa_unprepare_recovery() refers to pinctrl and pinctrl_default which
> you've retained in this version of the patch, but you've deleted the
> members from this structure - which will lead to a build error.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
>
Re: [PATCH v9 11/13] arm64: dts: freescale: sl28: enable LED support
On Mon 2020-09-07 23:38:00, Michael Walle wrote: > Now that we have support for GPIO lines of the SMARC connector, enable > LED support on the KBox A-230-LS. There are two LEDs without fixed > functions, one is yellow and one is green. Unfortunately, it is just one > multi-color LED, thus while it is possible to enable both at the same > time it is hard to tell the difference between "yellow only" and "yellow > and green". > > Signed-off-by: Michael Walle Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH net-next v1 2/3] net: phy: add API for LEDs controlled by ethernet PHY chips
Hi! > Many an ethernet PHY supports various HW control modes for LEDs > connected directly to the PHY chip. > > This patch adds code for registering such LEDs when described in device > tree and also adds a new private LED trigger called phydev-hw-mode. > When this trigger is enabled for a LED, the various HW control modes > which are supported by the PHY for given LED cat be get/set via hw_mode > sysfs file. > > A PHY driver wishing to utilize this API needs to implement all the > methods in the phy_device_led_ops structure. > > Signed-off-by: Marek Beh??n > select MDIO_I2C > > +config PHY_LEDS > + bool > + default y if LEDS_TRIGGERS > + > comment "MII PHY device drivers" > > config AMD_PHY > +/* drivers/net/phy/phy_hw_led_mode.c > + * Stale comment. > + init_data.fwnode = &np->fwnode; > + init_data.devname_mandatory = true; > + snprintf(devicename, sizeof(devicename), "phy%d", phydev->phyindex); > + init_data.devicename = devicename; > + > + ret = phydev->led_ops->led_init(phydev, led, &pdata); > + if (ret < 0) > + goto err_free; > + > + ret = devm_led_classdev_register_ext(&phydev->mdio.dev, &led->cdev, > &init_data); > + if (ret < 0) > + goto err_free; > + > + led->flags |= PHY_DEVICE_LED_REGISTERED; > + > + return 0; > +err_free: > + devm_kfree(&phydev->mdio.dev, led); > + return ret; devm should take care of freeing, right? Plus, format comments to 80 colums. checkpatch no longer warns, but rule still exists. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[PATCH] USB: serial: option: Add Telit FT980-KS composition
This commit adds the following Telit FT980-KS composition:
0x1054: rndis, diag, adb, nmea, modem, modem, aux
AT commands can be sent to /dev/ttyUSB5.
Signed-off-by: Leonid Bloch
---
The full composition is not tested, and it is the default one according
to Telit support. What is tested, is that this commit makes
/dev/ttyUSB{1..7} appear upon connection of the FT980-KS, and allows
sending AT commands to /dev/ttyUSB5.
drivers/usb/serial/option.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 0c6f160a214a..e7a98435ac29 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -301,6 +301,7 @@ static void option_instat_callback(struct urb *urb);
#define TELIT_PRODUCT_LE920A4_1212 0x1212
#define TELIT_PRODUCT_LE920A4_1213 0x1213
#define TELIT_PRODUCT_LE920A4_1214 0x1214
+#define TELIT_PRODUCT_FT980_KS 0x1054
/* ZTE PRODUCTS */
#define ZTE_VENDOR_ID 0x19d2
@@ -1164,6 +1165,7 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_CC864_SINGLE) },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_DE910_DUAL) },
{ USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_UE910_V2) },
+ { USB_DEVICE(TELIT_VENDOR_ID, TELIT_PRODUCT_FT980_KS) },
{ USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1031, 0xff),/*
Telit LE910C1-EUX */
.driver_info = NCTRL(0) | RSVD(3) },
{ USB_DEVICE_INTERFACE_CLASS(TELIT_VENDOR_ID, 0x1033, 0xff),/*
Telit LE910C1-EUX (ECM) */
--
2.28.0
[PATCH] ASoC: mchp-spdifrx: convert to devm_platform_get_and_ioremap_resource
Use the helper function that wraps the calls to platform_get_resource() and devm_ioremap_resource() together. Signed-off-by: Codrin Ciubotariu --- sound/soc/atmel/mchp-spdifrx.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/atmel/mchp-spdifrx.c b/sound/soc/atmel/mchp-spdifrx.c index 6776d89d56df..726e4951d9a5 100644 --- a/sound/soc/atmel/mchp-spdifrx.c +++ b/sound/soc/atmel/mchp-spdifrx.c @@ -873,8 +873,7 @@ static int mchp_spdifrx_probe(struct platform_device *pdev) return -ENOMEM; /* Map I/O registers. */ - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); - base = devm_ioremap_resource(&pdev->dev, mem); + base = devm_platform_get_and_ioremap_resource(pdev, 0, &mem); if (IS_ERR(base)) return PTR_ERR(base); -- 2.25.1
Re: [PATCH] can: raw: add missing error queue support
On 9/26/20 6:24 PM, Vincent Mailhol wrote: > Error queue are not yet implemented in CAN-raw sockets. > > The problem: a userland call to recvmsg(soc, msg, MSG_ERRQUEUE) on a > CAN-raw socket would unqueue messages from the normal queue without > any kind of error or warning. As such, it prevented CAN drivers from > using the functionalities that relies on the error queue such as > skb_tx_timestamp(). > > SCM_CAN_RAW_ERRQUEUE is defined as the type for the CAN raw error > queue. SCM stands for "Socket control messages". The name is inspired > from SCM_J1939_ERRQUEUE of include/uapi/linux/can/j1939.h. > > Signed-off-by: Vincent Mailhol Applied to linux-can-next. Tnx, 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 v2] i2c: pxa: move to generic GPIO recovery
On Sun, Oct 04, 2020 at 12:16:56PM +0300, Codrin Ciubotariu wrote:
> Starting with
> commit 75820314de26 ("i2c: core: add generic I2C GPIO recovery")
> GPIO bus recovery is supported by the I2C core, so we can remove the
> driver implementation and use that one instead.
>
> Signed-off-by: Codrin Ciubotariu
> ---
>
> This patch is not tested.
>
> Changes in v2:
> - readded the pinctrl state change to default from the
>unprepare_recovery callback;
I don't think you've build tested this patch...
> diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
> index 35ca2c02c9b9..006cc1d5931f 100644
> --- a/drivers/i2c/busses/i2c-pxa.c
> +++ b/drivers/i2c/busses/i2c-pxa.c
> @@ -264,9 +264,6 @@ struct pxa_i2c {
> u32 hs_mask;
>
> struct i2c_bus_recovery_info recovery;
> - struct pinctrl *pinctrl;
> - struct pinctrl_state*pinctrl_default;
> - struct pinctrl_state*pinctrl_recovery;
i2c_pxa_unprepare_recovery() refers to pinctrl and pinctrl_default which
you've retained in this version of the patch, but you've deleted the
members from this structure - which will lead to a build error.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
[PATCH v2] i2c: pxa: move to generic GPIO recovery
Starting with
commit 75820314de26 ("i2c: core: add generic I2C GPIO recovery")
GPIO bus recovery is supported by the I2C core, so we can remove the
driver implementation and use that one instead.
Signed-off-by: Codrin Ciubotariu
---
This patch is not tested.
Changes in v2:
- readded the pinctrl state change to default from the
unprepare_recovery callback;
drivers/i2c/busses/i2c-pxa.c | 73 +++-
1 file changed, 6 insertions(+), 67 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 35ca2c02c9b9..006cc1d5931f 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -264,9 +264,6 @@ struct pxa_i2c {
u32 hs_mask;
struct i2c_bus_recovery_info recovery;
- struct pinctrl *pinctrl;
- struct pinctrl_state*pinctrl_default;
- struct pinctrl_state*pinctrl_recovery;
};
#define _IBMR(i2c) ((i2c)->reg_ibmr)
@@ -1305,8 +1302,6 @@ static void i2c_pxa_prepare_recovery(struct i2c_adapter
*adap)
*/
gpiod_set_value(i2c->recovery.scl_gpiod, ibmr & IBMR_SCLS);
gpiod_set_value(i2c->recovery.sda_gpiod, ibmr & IBMR_SDAS);
-
- WARN_ON(pinctrl_select_state(i2c->pinctrl, i2c->pinctrl_recovery));
}
static void i2c_pxa_unprepare_recovery(struct i2c_adapter *adap)
@@ -1347,76 +1342,20 @@ static int i2c_pxa_init_recovery(struct pxa_i2c *i2c)
if (IS_ENABLED(CONFIG_I2C_PXA_SLAVE))
return 0;
- i2c->pinctrl = devm_pinctrl_get(dev);
- if (PTR_ERR(i2c->pinctrl) == -ENODEV)
- i2c->pinctrl = NULL;
- if (IS_ERR(i2c->pinctrl))
- return PTR_ERR(i2c->pinctrl);
-
- if (!i2c->pinctrl)
- return 0;
-
- i2c->pinctrl_default = pinctrl_lookup_state(i2c->pinctrl,
- PINCTRL_STATE_DEFAULT);
- i2c->pinctrl_recovery = pinctrl_lookup_state(i2c->pinctrl, "recovery");
-
- if (IS_ERR(i2c->pinctrl_default) || IS_ERR(i2c->pinctrl_recovery)) {
- dev_info(dev, "missing pinmux recovery information: %ld %ld\n",
-PTR_ERR(i2c->pinctrl_default),
-PTR_ERR(i2c->pinctrl_recovery));
- return 0;
- }
-
- /*
-* Claiming GPIOs can influence the pinmux state, and may glitch the
-* I2C bus. Do this carefully.
-*/
- bri->scl_gpiod = devm_gpiod_get(dev, "scl", GPIOD_OUT_HIGH_OPEN_DRAIN);
- if (bri->scl_gpiod == ERR_PTR(-EPROBE_DEFER))
- return -EPROBE_DEFER;
- if (IS_ERR(bri->scl_gpiod)) {
- dev_info(dev, "missing scl gpio recovery information: %pe\n",
-bri->scl_gpiod);
- return 0;
- }
-
- /*
-* We have SCL. Pull SCL low and wait a bit so that SDA glitches
-* have no effect.
-*/
- gpiod_direction_output(bri->scl_gpiod, 0);
- udelay(10);
- bri->sda_gpiod = devm_gpiod_get(dev, "sda", GPIOD_OUT_HIGH_OPEN_DRAIN);
-
- /* Wait a bit in case of a SDA glitch, and then release SCL. */
- udelay(10);
- gpiod_direction_output(bri->scl_gpiod, 1);
-
- if (bri->sda_gpiod == ERR_PTR(-EPROBE_DEFER))
- return -EPROBE_DEFER;
-
- if (IS_ERR(bri->sda_gpiod)) {
- dev_info(dev, "missing sda gpio recovery information: %pe\n",
-bri->sda_gpiod);
+ bri->pinctrl = devm_pinctrl_get(dev);
+ if (PTR_ERR(bri->pinctrl) == -ENODEV) {
+ bri->pinctrl = NULL;
return 0;
}
+ if (IS_ERR(bri->pinctrl))
+ return PTR_ERR(bri->pinctrl);
bri->prepare_recovery = i2c_pxa_prepare_recovery;
bri->unprepare_recovery = i2c_pxa_unprepare_recovery;
- bri->recover_bus = i2c_generic_scl_recovery;
i2c->adap.bus_recovery_info = bri;
- /*
-* Claiming GPIOs can change the pinmux state, which confuses the
-* pinctrl since pinctrl's idea of the current setting is unaffected
-* by the pinmux change caused by claiming the GPIO. Work around that
-* by switching pinctrl to the GPIO state here. We do it this way to
-* avoid glitching the I2C bus.
-*/
- pinctrl_select_state(i2c->pinctrl, i2c->pinctrl_recovery);
-
- return pinctrl_select_state(i2c->pinctrl, i2c->pinctrl_default);
+ return 0;
}
static int i2c_pxa_probe(struct platform_device *dev)
--
2.25.1
[PATCH 1/2] regulator: qcom_smd: add pm8953 regulators
The PM8953 is commonly used on board with MSM8953 SoCs or its variants:
APQ8053, SDM(SDA)450 and SDM(SDA)632.
It provides 7 SMPS and 23 LDO regulators.
Signed-off-by: Vladimir Lypak
---
drivers/regulator/qcom_smd-regulator.c | 54 ++
1 file changed, 54 insertions(+)
diff --git a/drivers/regulator/qcom_smd-regulator.c
b/drivers/regulator/qcom_smd-regulator.c
index faa99690b7b3..bb944ee5fe3b 100644
--- a/drivers/regulator/qcom_smd-regulator.c
+++ b/drivers/regulator/qcom_smd-regulator.c
@@ -403,6 +403,24 @@ static const struct regulator_desc pm8950_pldo = {
.ops = &rpm_smps_ldo_ops,
};
+static const struct regulator_desc pm8953_lnldo = {
+ .linear_ranges = (struct linear_range[]) {
+ REGULATOR_LINEAR_RANGE(138, 8, 15, 12),
+ REGULATOR_LINEAR_RANGE(69, 0, 7, 6),
+ },
+ .n_linear_ranges = 2,
+ .n_voltages = 16,
+ .ops = &rpm_smps_ldo_ops,
+};
+
+static const struct regulator_desc pm8953_ult_nldo = {
+ .linear_ranges = (struct linear_range[]) {
+ REGULATOR_LINEAR_RANGE(375000, 0, 93, 12500),
+ },
+ .n_linear_ranges = 1,
+ .n_voltages = 94,
+ .ops = &rpm_smps_ldo_ops,
+};
static const struct regulator_desc pm8994_hfsmps = {
.linear_ranges = (struct linear_range[]) {
@@ -854,6 +872,41 @@ static const struct rpm_regulator_data
rpm_pm8950_regulators[] = {
{}
};
+static const struct rpm_regulator_data rpm_pm8953_regulators[] = {
+ { "s1", QCOM_SMD_RPM_SMPA, 1, &pm8998_hfsmps, "vdd_s1" },
+ { "s2", QCOM_SMD_RPM_SMPA, 2, &pm8998_hfsmps, "vdd_s2" },
+ { "s3", QCOM_SMD_RPM_SMPA, 3, &pm8998_hfsmps, "vdd_s3" },
+ { "s4", QCOM_SMD_RPM_SMPA, 4, &pm8998_hfsmps, "vdd_s4" },
+ { "s5", QCOM_SMD_RPM_SMPA, 5, &pm8950_ftsmps2p5, "vdd_s5" },
+ { "s6", QCOM_SMD_RPM_SMPA, 6, &pm8950_ftsmps2p5, "vdd_s6" },
+ { "s7", QCOM_SMD_RPM_SMPA, 7, &pm8998_hfsmps, "vdd_s7" },
+
+ { "l1", QCOM_SMD_RPM_LDOA, 1, &pm8953_ult_nldo, "vdd_l1" },
+ { "l2", QCOM_SMD_RPM_LDOA, 2, &pm8953_ult_nldo, "vdd_l2_l3" },
+ { "l3", QCOM_SMD_RPM_LDOA, 3, &pm8953_ult_nldo, "vdd_l2_l3" },
+ { "l4", QCOM_SMD_RPM_LDOA, 4, &pm8950_ult_pldo,
"vdd_l4_l5_l6_l7_l16_l19" },
+ { "l5", QCOM_SMD_RPM_LDOA, 5, &pm8950_ult_pldo,
"vdd_l4_l5_l6_l7_l16_l19" },
+ { "l6", QCOM_SMD_RPM_LDOA, 6, &pm8950_ult_pldo,
"vdd_l4_l5_l6_l7_l16_l19" },
+ { "l7", QCOM_SMD_RPM_LDOA, 7, &pm8950_ult_pldo,
"vdd_l4_l5_l6_l7_l16_l19" },
+ { "l8", QCOM_SMD_RPM_LDOA, 8, &pm8950_ult_pldo,
"vdd_l8_l11_l12_l13_l14_l15" },
+ { "l9", QCOM_SMD_RPM_LDOA, 9, &pm8950_ult_pldo,
"vdd_l9_l10_l17_l18_l22" },
+ { "l10", QCOM_SMD_RPM_LDOA, 10, &pm8950_ult_pldo,
"vdd_l9_l10_l17_l18_l22" },
+ { "l11", QCOM_SMD_RPM_LDOA, 11, &pm8950_ult_pldo,
"vdd_l8_l11_l12_l13_l14_l15" },
+ { "l12", QCOM_SMD_RPM_LDOA, 12, &pm8950_ult_pldo,
"vdd_l8_l11_l12_l13_l14_l15" },
+ { "l13", QCOM_SMD_RPM_LDOA, 13, &pm8950_ult_pldo,
"vdd_l8_l11_l12_l13_l14_l15" },
+ { "l14", QCOM_SMD_RPM_LDOA, 14, &pm8950_ult_pldo,
"vdd_l8_l11_l12_l13_l14_l15" },
+ { "l15", QCOM_SMD_RPM_LDOA, 15, &pm8950_ult_pldo,
"vdd_l8_l11_l12_l13_l14_l15" },
+ { "l16", QCOM_SMD_RPM_LDOA, 16, &pm8950_ult_pldo,
"vdd_l4_l5_l6_l7_l16_l19" },
+ { "l17", QCOM_SMD_RPM_LDOA, 17, &pm8950_ult_pldo,
"vdd_l9_l10_l17_l18_l22" },
+ { "l18", QCOM_SMD_RPM_LDOA, 18, &pm8950_ult_pldo,
"vdd_l9_l10_l17_l18_l22" },
+ { "l19", QCOM_SMD_RPM_LDOA, 19, &pm8953_ult_nldo,
"vdd_l4_l5_l6_l7_l16_l19" },
+ { "l20", QCOM_SMD_RPM_LDOA, 20, &pm8953_lnldo,"vdd_l20" },
+ { "l21", QCOM_SMD_RPM_LDOA, 21, &pm8953_lnldo,"vdd_l21" },
+ { "l22", QCOM_SMD_RPM_LDOA, 22, &pm8950_ult_pldo,
"vdd_l9_l10_l17_l18_l22" },
+ { "l23", QCOM_SMD_RPM_LDOA, 23, &pm8953_ult_nldo, "vdd_l23" },
+ {}
+};
+
static const struct rpm_regulator_data rpm_pm8994_regulators[] = {
{ "s1", QCOM_SMD_RPM_SMPA, 1, &pm8994_ftsmps, "vdd_s1" },
{ "s2", QCOM_SMD_RPM_SMPA, 2, &pm8994_ftsmps, "vdd_s2" },
@@ -1041,6 +1094,7 @@ static const struct of_device_id rpm_of_match[] = {
{ .compatible = "qcom,rpm-pm8916-regulators", .data =
&rpm_pm8916_regulators },
{ .compatible = "qcom,rpm-pm8941-regulators", .data =
&rpm_pm8941_regulators },
{ .compatible = "qcom,rpm-pm8950-regulators", .data =
&rpm_pm8950_regulators },
+ { .compatible = "qcom,rpm-pm8953-regulators", .data =
&rpm_pm8953_regulators },
{ .compatible = "qcom,rpm-pm8994-regulators", .data =
&rpm_pm8994_regulators },
{ .compatible = "qcom,rpm-pm8998-regulators", .data =
&rpm_pm8998_regulators },
{ .compatible = "qcom,rpm-pm660-regulators", .data =
&rpm_pm660_regulators },
--
2.24.1
[PATCH 2/2] dt-bindings: regulator: document pm8950 and pm8953 smd regulators
Add list of regulators available on PM8953 and PM8950 PMICs. Also document compatible for PM8953. Signed-off-by: Vladimir Lypak --- .../bindings/regulator/qcom,smd-rpm-regulator.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml index 8ef3033444b9..a35c6cb9bf97 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml @@ -33,6 +33,10 @@ description: l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, lvs1, lvs2, lvs3, 5vs1, 5vs2 + For pm8950 and pm8953, s1, s2, s3, s4, s5, s6, s7, l1, l2, l3, l4, l5, l6, + l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22, + l23 + For pm8994, s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, l25, l26, l27, l28, l29, l30, l31, l32, lvs1, lvs2 @@ -68,6 +72,7 @@ properties: - qcom,rpm-pm8916-regulators - qcom,rpm-pm8941-regulators - qcom,rpm-pm8950-regulators + - qcom,rpm-pm8953-regulators - qcom,rpm-pm8994-regulators - qcom,rpm-pm8998-regulators - qcom,rpm-pm660-regulators -- 2.24.1
Re: BUG: unable to handle kernel paging request in tcf_action_dump_terse
syzbot has found a reproducer for the following issue on: HEAD commit:2172e358 Add linux-next specific files for 20201002 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=12ba75ff90 kernel config: https://syzkaller.appspot.com/x/.config?x=70698f530a7e856f dashboard link: https://syzkaller.appspot.com/bug?extid=5f2adc70969940fd compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=142fd4af90 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16ffcdeb90 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+5f2adc7096994...@syzkaller.appspotmail.com BUG: unable to handle page fault for address: fff0 #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page PGD a291067 P4D a291067 PUD a293067 PMD 0 Oops: [#1] PREEMPT SMP KASAN CPU: 1 PID: 8162 Comm: syz-executor344 Not tainted 5.9.0-rc7-next-20201002-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:tcf_action_dump_terse+0x8c/0x4e0 net/sched/act_api.c:759 Code: 3c 03 0f 8e 0a 03 00 00 48 89 da 44 8b ad b8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 10 04 00 00 <48> 8b 03 4c 8d 60 10 4c 89 e7 e8 55 5b 58 fd 4c 89 e1 be 01 00 00 RSP: 0018:c90009bff178 EFLAGS: 00010246 RAX: dc00 RBX: fff0 RCX: RDX: 1ffe RSI: 867eb859 RDI: 888097102eb8 RBP: 888097102e00 R08: R09: 88809ea92024 R10: R11: R12: fff0 R13: 0024 R14: 88809ea92000 R15: 888097102ec0 FS: 7f6bfe65f700() GS:8880ae50() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: fff0 CR3: 96ec4000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: tcf_action_dump_1+0xd2/0x5a0 net/sched/act_api.c:788 tcf_dump_walker net/sched/act_api.c:249 [inline] tcf_generic_walker+0x207/0xba0 net/sched/act_api.c:343 tc_dump_action+0x6d5/0xe60 net/sched/act_api.c:1610 netlink_dump+0x4df/0xba0 net/netlink/af_netlink.c:2268 __netlink_dump_start+0x643/0x900 net/netlink/af_netlink.c:2373 netlink_dump_start include/linux/netlink.h:246 [inline] rtnetlink_rcv_msg+0x70f/0xad0 net/core/rtnetlink.c:5526 netlink_rcv_skb+0x15a/0x430 net/netlink/af_netlink.c:2489 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:671 sys_sendmsg+0x331/0x810 net/socket.c:2362 ___sys_sendmsg+0xf3/0x170 net/socket.c:2416 __sys_sendmmsg+0x196/0x4b0 net/socket.c:2506 __do_sys_sendmmsg net/socket.c:2535 [inline] __se_sys_sendmmsg net/socket.c:2532 [inline] __x64_sys_sendmmsg+0x99/0x100 net/socket.c:2532 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x44a569 Code: e8 8c e7 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b 05 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f6bfe65ed98 EFLAGS: 0246 ORIG_RAX: 0133 RAX: ffda RBX: 006dfc48 RCX: 0044a569 RDX: 010efe10675dec16 RSI: 2200 RDI: 0003 RBP: 006dfc40 R08: R09: R10: R11: 0246 R12: 006dfc4c R13: 0005 R14: 00a3a2074000 R15: 050700240038 Modules linked in: CR2: fff0 ---[ end trace c7fd3dfeaf54c122 ]--- RIP: 0010:tcf_action_dump_terse+0x8c/0x4e0 net/sched/act_api.c:759 Code: 3c 03 0f 8e 0a 03 00 00 48 89 da 44 8b ad b8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 10 04 00 00 <48> 8b 03 4c 8d 60 10 4c 89 e7 e8 55 5b 58 fd 4c 89 e1 be 01 00 00 RSP: 0018:c90009bff178 EFLAGS: 00010246 RAX: dc00 RBX: fff0 RCX: RDX: 1ffe RSI: 867eb859 RDI: 888097102eb8 RBP: 888097102e00 R08: R09: 88809ea92024 R10: R11: R12: fff0 R13: 0024 R14: 88809ea92000 R15: 888097102ec0 FS: 7f6bfe65f700() GS:8880ae50() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: fff0 CR3: 96ec4000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400
Re: [PATCH v3 5/7] rtc: New driver for RTC in Netronix embedded controller
On 04/10/2020 03:43:23+0200, Jonathan Neuschäfer wrote:
> > > +static int ntxec_set_time(struct device *dev, struct rtc_time *tm)
> > > +{
> > > + struct ntxec_rtc *rtc = dev_get_drvdata(dev);
> > > + int res = 0;
> > > +
> > > + res = regmap_write(rtc->ec->regmap, NTXEC_REG_WRITE_YEAR,
> > > ntxec_reg8(tm->tm_year - 100));
> > > + if (res)
> > > + return res;
> > > +
> > > + res = regmap_write(rtc->ec->regmap, NTXEC_REG_WRITE_MONTH,
> > > ntxec_reg8(tm->tm_mon + 1));
> > > + if (res)
> > > + return res;
> > > +
> > > + res = regmap_write(rtc->ec->regmap, NTXEC_REG_WRITE_DAY,
> > > ntxec_reg8(tm->tm_mday));
> > > + if (res)
> > > + return res;
> > > +
> > > + res = regmap_write(rtc->ec->regmap, NTXEC_REG_WRITE_HOUR,
> > > ntxec_reg8(tm->tm_hour));
> > > + if (res)
> > > + return res;
> > > +
> > > + res = regmap_write(rtc->ec->regmap, NTXEC_REG_WRITE_MINUTE,
> > > ntxec_reg8(tm->tm_min));
> > > + if (res)
> > > + return res;
> > > +
> > > + return regmap_write(rtc->ec->regmap, NTXEC_REG_WRITE_SECOND,
> > > ntxec_reg8(tm->tm_sec));
> >
> > I wonder: Is this racy? If you write minute, does the seconds reset to
> > zero or something like that? Or can it happen, that after writing the
> > minute register and before writing the second register the seconds
> > overflow and you end up with the time set to a minute later than
> > intended? If so it might be worth to set the seconds to 0 at the start
> > of the function (with an explaining comment).
>
> The setting the minutes does not reset the seconds, so I think this race
> condition is possible. I'll add the workaround.
>
Are you sure this happens? Usually, the seconds are not reset but the
internal 32768kHz counter is so you have a full second to write all the
registers.
> > .read_time has a similar race. What happens if minutes overflow between
> > reading NTXEC_REG_READ_DH and NTXEC_REG_READ_MS?
>
> Yes, we get read tearing in that case. It could even propagate all the
> way to the year/month field, for example when the following time rolls
> over:
> A | B | C
> 2020-10-31 23:59:59
> 2020-11-01 00:00:00
>
> - If the increment happens after reading C, we get 2020-10-31 23:59:59
> - If the increment happens between reading B and C, we get 2020-10-31 23:00:00
> - If the increment happens between reading A and B, we get 2020-10-01 00:00:00
> - If the increment happens before reading A, we get2020-11-01 00:00:00
>
> ... both of which are far from correct.
>
> To mitigate this issue, I think something like the following is needed:
>
> - Read year/month
> - Read day/hour
> - Read minute/second
> - Read day/hour, compare with previously read value, restart on mismatch
> - Read year/month, compare with previously read value, restart on mismatch
>
> The order of the last two steps doesn't matter, as far as I can see, but
> if I remove one of them, I can't catch all cases of read tearing.
>
Are you also sure this happens?
Only one comparison is necessary, the correct order would be:
- Read minute/second
- Read day/hour
- Read year/month
- Read minute/second, compare
If day/hour changes but not minute/second, it would mean that it took at
least an hour to read all the registers. At this point, I think you have
other problems and the exact time doesn't matter anymore.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[PATCH] soc: qcom: socinfo: add soc ids for msm8953 variants
Add SoC IDs for MSM8953, APQ8053, SDM(SDA)450, SDM(SDA)632.
Signed-off-by: Vladimir Lypak
---
drivers/soc/qcom/socinfo.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
index b44ede48decc..d21530d24253 100644
--- a/drivers/soc/qcom/socinfo.c
+++ b/drivers/soc/qcom/socinfo.c
@@ -218,13 +218,19 @@ static const struct soc_id soc_id[] = {
{ 251, "MSM8992" },
{ 253, "APQ8094" },
{ 291, "APQ8096" },
+ { 293, "MSM8953" },
+ { 304, "APQ8053" },
{ 305, "MSM8996SG" },
{ 310, "MSM8996AU" },
{ 311, "APQ8096AU" },
{ 312, "APQ8096SG" },
{ 318, "SDM630" },
{ 321, "SDM845" },
+ { 338, "SDM450" },
{ 341, "SDA845" },
+ { 349, "SDM632" },
+ { 350, "SDA632" },
+ { 351, "SDA450" },
{ 356, "SM8250" },
{ 402, "IPQ6018" },
{ 425, "SC7180" },
--
2.24.1
[PATCH 2/2] dt-bindings: pinctrl: qcom: add msm8953 pinctrl bindings
Add device tree bindings documentation for Qualcomm MSM8953 pinctrl driver. Signed-off-by: Vladimir Lypak --- .../pinctrl/qcom,msm8953-pinctrl.yaml | 160 ++ 1 file changed, 160 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml new file mode 100644 index ..e539149834b6 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml @@ -0,0 +1,160 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,msm8953-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. MSM8953 TLMM block + +maintainers: + - Bjorn Andersson + +description: | + This binding describes the Top Level Mode Multiplexer block found in the + MSM8953 platform. + +properties: + compatible: +const: qcom,msm8953-pinctrl + + reg: +maxItems: 1 + + interrupts: +description: Specifies the TLMM summary IRQ +maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': +description: + Specifies the PIN numbers and Flags, as defined in defined in + include/dt-bindings/interrupt-controller/irq.h +const: 2 + + gpio-controller: true + + '#gpio-cells': +description: Specifying the pin number and flags, as defined in + include/dt-bindings/gpio/gpio.h +const: 2 + + gpio-ranges: +maxItems: 1 + + wakeup-parent: +maxItems: 1 + +#PIN CONFIGURATION NODES +patternProperties: + '^.*$': +if: + type: object +then: + properties: +pins: + description: +List of gpio pins affected by the properties specified in this +subnode. + items: +oneOf: + - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-7][0-9])$" + - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc1_rclk, sdc2_clk, +sdc2_cmd, sdc2_data, qdsd_clk, qdsd_cmd, qdsd_data0, +qdsd_data1, qdsd_data2, qdsd_data3 ] + minItems: 1 + maxItems: 16 + +function: + description: +Specify the alternative function to be configured for the specified +pins. + + enum: [ accel_int, adsp_ext, alsp_int, atest_bbrx0, atest_bbrx1, + atest_char, atest_char0, atest_char1, atest_char2, atest_char3, + atest_gpsadc_dtest0_native, atest_gpsadc_dtest1_native, atest_tsens, + atest_wlan0, atest_wlan1, bimc_dte0, bimc_dte1, blsp1_spi, + blsp3_spi, blsp6_spi, blsp7_spi, blsp_i2c1, blsp_i2c2, blsp_i2c3, + blsp_i2c4, blsp_i2c5, blsp_i2c6, blsp_i2c7, blsp_i2c8, blsp_spi1, + blsp_spi2, blsp_spi3, blsp_spi4, blsp_spi5, blsp_spi6, blsp_spi7, + blsp_spi8, blsp_uart2, blsp_uart4, blsp_uart5, blsp_uart6, cam0_ldo, + cam1_ldo, cam1_rst, cam1_standby, cam2_rst, cam2_standby, cam3_rst, + cam3_standby, cam_irq, cam_mclk, cap_int, cci_async, cci_i2c, + cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4, + cdc_pdm0, codec_int1, codec_int2, codec_reset, cri_trng, cri_trng0, + cri_trng1, dac_calib0, dac_calib1, dac_calib10, dac_calib11, + dac_calib12, dac_calib13, dac_calib14, dac_calib15, dac_calib16, + dac_calib17, dac_calib18, dac_calib19, dac_calib2, dac_calib20, + dac_calib21, dac_calib22, dac_calib23, dac_calib24, dac_calib25, + dac_calib3, dac_calib4, dac_calib5, dac_calib6, dac_calib7, + dac_calib8, dac_calib9, dbg_out, ddr_bist, dmic0_clk, dmic0_data, + ebi_cdc, ebi_ch0, ext_lpass, flash_strobe, fp_int, gcc_gp1_clk_a, + gcc_gp1_clk_b, gcc_gp2_clk_a, gcc_gp2_clk_b, gcc_gp3_clk_a, + gcc_gp3_clk_b, gcc_plltest, gcc_tlmm, gpio, gsm0_tx, gsm1_tx, + gyro_int, hall_int, hdmi_int, key_focus, key_home, key_snapshot, + key_volp, ldo_en, ldo_update, lpass_slimbus, lpass_slimbus0, + lpass_slimbus1, m_voc, mag_int, mdp_vsync, mipi_dsi0, modem_tsync, + mss_lte, nav_pps, nav_pps_in_a, nav_pps_in_b, nav_tsync, + nfc_disable, nfc_dwl, nfc_irq, ois_sync, pa_indicator, pbs0, pbs1, + pbs2, pressure_int, pri_mi2s, pri_mi2s_mclk_a, pri_mi2s_mclk_b, + pri_mi2s_ws, prng_rosc, pwr_crypto_enabled_a, pwr_crypto_enabled_b, + pwr_down, pwr_modem_enabled_a, pwr_modem_enabled_b, + pwr_nav_enabled_a, pwr_nav_enabled_b, qdss_cti_trig_in_a0, + qdss_cti_trig_in_a1, qdss_cti_trig_in_b0, qdss_cti_trig_in_
[PATCH 1/2] pinctrl: qcom: add pinctrl driver for msm8953
Add inititial pinctrl driver for MSM8953 platform. Compatible SoCs are:
MSM8953, APQ8053, SDM(SDA)450, SDM(SDA)632.
Based off CAF implementation.
Signed-off-by: Prasad Sodagudi
Signed-off-by: Vladimir Lypak
---
drivers/pinctrl/qcom/Kconfig | 10 +
drivers/pinctrl/qcom/Makefile |1 +
drivers/pinctrl/qcom/pinctrl-msm8953.c | 1844
3 files changed, 1855 insertions(+)
create mode 100644 drivers/pinctrl/qcom/pinctrl-msm8953.c
diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index 5fe7b8aaf69d..98d075447a32 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -111,6 +111,16 @@ config PINCTRL_MSM8916
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found on the Qualcomm 8916 platform.
+config PINCTRL_MSM8953
+ tristate "Qualcomm 8953 pin controller driver"
+ depends on GPIOLIB && OF
+ select PINCTRL_MSM
+ help
+ This is the pinctrl, pinmux, pinconf and gpiolib driver for the
+ Qualcomm TLMM block found on the Qualcomm MSM8953 platform.
+ The Qualcomm APQ8053, SDM450, SDM632 platforms are also
+ supported by this driver.
+
config PINCTRL_MSM8976
tristate "Qualcomm 8976 pin controller driver"
depends on GPIOLIB && OF
diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
index 9e3d9c91a444..5072e66fd3ab 100644
--- a/drivers/pinctrl/qcom/Makefile
+++ b/drivers/pinctrl/qcom/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_PINCTRL_MSM8660) += pinctrl-msm8660.o
obj-$(CONFIG_PINCTRL_MSM8960) += pinctrl-msm8960.o
obj-$(CONFIG_PINCTRL_MSM8X74) += pinctrl-msm8x74.o
obj-$(CONFIG_PINCTRL_MSM8916) += pinctrl-msm8916.o
+obj-$(CONFIG_PINCTRL_MSM8953) += pinctrl-msm8953.o
obj-$(CONFIG_PINCTRL_MSM8976) += pinctrl-msm8976.o
obj-$(CONFIG_PINCTRL_MSM8994) += pinctrl-msm8994.o
obj-$(CONFIG_PINCTRL_MSM8996) += pinctrl-msm8996.o
diff --git a/drivers/pinctrl/qcom/pinctrl-msm8953.c
b/drivers/pinctrl/qcom/pinctrl-msm8953.c
new file mode 100644
index ..84678ae23802
--- /dev/null
+++ b/drivers/pinctrl/qcom/pinctrl-msm8953.c
@@ -0,0 +1,1844 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2020, The Linux Foundation. All rights reserved.
+
+#include
+#include
+#include
+#include
+
+#include "pinctrl-msm.h"
+
+#define FUNCTION(fname)\
+ [msm_mux_##fname] = { \
+ .name = #fname, \
+ .groups = fname##_groups, \
+ .ngroups = ARRAY_SIZE(fname##_groups), \
+ }
+
+#define PINGROUP(id, f1, f2, f3, f4, f5, f6, f7, f8, f9) \
+ { \
+ .name = "gpio" #id, \
+ .pins = gpio##id##_pins,\
+ .npins = ARRAY_SIZE(gpio##id##_pins), \
+ .funcs = (int[]){ \
+ msm_mux_gpio, /* gpio mode */ \
+ msm_mux_##f1, \
+ msm_mux_##f2, \
+ msm_mux_##f3, \
+ msm_mux_##f4, \
+ msm_mux_##f5, \
+ msm_mux_##f6, \
+ msm_mux_##f7, \
+ msm_mux_##f8, \
+ msm_mux_##f9\
+ }, \
+ .nfuncs = 10, \
+ .ctl_reg = 0x1000 * id, \
+ .io_reg = 0x4 + 0x1000 * id,\
+ .intr_cfg_reg = 0x8 + 0x1000 * id, \
+ .intr_status_reg = 0xc + 0x1000 * id, \
+ .intr_target_reg = 0x8 + 0x1000 * id, \
+ .mux_bit = 2, \
+ .pull_bit = 0, \
+ .drv_bit = 6, \
+ .oe_bit = 9,\
+ .in_bit = 0,\
+ .out_bit = 1, \
+ .intr_enable_bit = 0, \
+ .intr_status_bit = 0, \
+ .intr_target_bit = 5, \
+ .intr_target_kpss_val = 4, \
+ .intr_raw_status_bit = 4, \
+ .intr_polarity_bit = 1,
Re: linux-next: build warning after merge of the tip tree
On Sun, Oct 04, 2020 at 10:24:37AM +1100, Stephen Rothwell wrote: > Hi Kees, > > On Sat, 3 Oct 2020 14:54:46 -0700 Kees Cook wrote: > > > > On Mon, Sep 14, 2020 at 01:22:49PM +1000, Stephen Rothwell wrote: > > > Hi all, > > > > > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > > > produced this warning: > > > > > > x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from > > > `kernel/trace/trace_selftest_dynamic.o' being placed in section > > > `.ctors.65435' > > > [...] > > > > Is it only trace that is warning? > > Yes, it is only trace. it is always 65435 as well, in case that matters. > > > > gcc (Debian 10.2.0-5) 10.2.0 > > > GNU ld (GNU Binutils for Debian) 2.35 > > > > I can't reproduce this with: > > > > gcc (Ubuntu 10.2.0-11ubuntu1) 10.2.0 > > GNU ld (GNU Binutils for Ubuntu) 2.35.1 > > > > Are you running Debian testing or unstable? (I see binutils 2.35.1 is > > in both, so was this fixed in the .1?) > > > > I will go build a Debian testing container... > > I am running testing. Just upgraded to 2.35.1 and the messages are > still there. (I did a build of just tip/auto-latest - this is a cross > build powerpc le hosted) I assume CONFIG_CONSTRUCTORS is enabled for your build (it should be for allmodconfig). Does this patch fix it? (I'm kind of blindly guessing based on my understanding of where this could be coming from...) diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h index e1843976754a..22f14956214a 100644 --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -701,6 +701,7 @@ #ifdef CONFIG_CONSTRUCTORS #define KERNEL_CTORS() . = ALIGN(8); \ __ctors_start = .; \ + KEEP(*(SORT(.ctors.*)))\ KEEP(*(.ctors))\ KEEP(*(SORT(.init_array.*))) \ KEEP(*(.init_array)) \ -- Kees Cook
Re: [PATCH v2 8/8] selftests/vm: hmm-tests: remove the libhugetlbfs dependency
On 10/4/20 12:55 AM, Lukas Bulwahn wrote:
On Tue, 29 Sep 2020, John Hubbard wrote:
...
John, your change makes:
tools/testing/selftests$ make clean
fail with:
make[1]: Entering directory
'/home/lukas/repositories/kernel.org/pub/scm/linux/kernel/git/next/linux-next/tools/testing/selftests/vm'
Makefile:4: local_config.mk: No such file or directory
./check_config.sh gcc
make[1]: execvp: ./check_config.sh: Permission denied
Makefile:141: recipe for target 'local_config.mk' failed
make[1]: *** [local_config.mk] Error 127
Yes, there's a fix for that, here:
https://lore.kernel.org/r/20201003002142.32671-2-jhubb...@nvidia.com
...and Andrew Morton has merged it into his tree as of yesterday, too.
(As shown in the attached email, which has notes about how that flow
works.)
Sorry that you had to run into that, but this should fix you up.
thanks,
--
John Hubbard
NVIDIA
--- Begin Message ---
The patch titled
Subject: selftests/vm: fix an improper dependency upon executable script
permissions
has been added to the -mm tree. Its filename is
selftests-vm-hmm-tests-remove-the-libhugetlbfs-dependency-fix.patch
This patch should soon appear at
https://ozlabs.org/~akpm/mmots/broken-out/selftests-vm-hmm-tests-remove-the-libhugetlbfs-dependency-fix.patch
and later at
https://ozlabs.org/~akpm/mmotm/broken-out/selftests-vm-hmm-tests-remove-the-libhugetlbfs-dependency-fix.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing
your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
--
From: John Hubbard
Subject: selftests/vm: fix an improper dependency upon executable script
permissions
commit 30fb9454ab23 ("selftests/vm: hmm-tests: remove the libhugetlbfs
dependency") created the new check_config.sh file without the execute bit
set. This is a problem because that same commit caused the Makefile to
invoke it "./check_config.sh", so now "make" is failing in that directory.
Scripts are not supposed to depend on the executable bit being set,
because patch(1) doesn't set it, and using patch to install a kernel is
supported. Therefore, this fix involves two parts:
1) Invoke the new script via /bin/sh, to fix the problem, and
2) As an nice touch, make check_config.sh executable as well.
Link: https://lkml.kernel.org/r/20201003002142.32671-2-jhubb...@nvidia.com
Fixes: commit 30fb9454ab23 ("selftests/vm: hmm-tests: remove the libhugetlbfs
dependency")
Signed-off-by: John Hubbard
Signed-off-by: Andrew Morton
---
tools/testing/selftests/vm/Makefile |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
a/tools/testing/selftests/vm/Makefile~selftests-vm-hmm-tests-remove-the-libhugetlbfs-dependency-fix
+++ a/tools/testing/selftests/vm/Makefile
@@ -138,7 +138,7 @@ $(OUTPUT)/hmm-tests: local_config.h
$(OUTPUT)/hmm-tests: LDLIBS += $(HMM_EXTRA_LIBS)
local_config.mk local_config.h: check_config.sh
- ./check_config.sh $(CC)
+ /bin/sh ./check_config.sh $(CC)
EXTRA_CLEAN += local_config.mk local_config.h
_
Patches currently in -mm which might be from jhubb...@nvidia.com are
mm-dump_page-rename-head_mapcount-head_compound_mapcount.patch
mm-gup-protect-unpin_user_pages-against-npages==-errno.patch
selftests-vm-fix-false-build-success-on-the-second-and-later-attempts.patch
selftests-vm-fix-incorrect-gcc-invocation-in-some-cases.patch
selftests-vm-8x-compaction_test-speedup.patch
mm-gup_benchmark-rename-to-mm-gup_test.patch
selftests-vm-use-a-common-gup_testh.patch
selftests-vm-rename-run_vmtests-run_vmtestssh.patch
selftests-vm-minor-cleanup-makefile-and-gup_testc.patch
selftests-vm-only-some-gup_test-items-are-really-benchmarks.patch
selftests-vm-gup_test-introduce-the-dump_pages-sub-test.patch
selftests-vm-run_vmtestsh-update-and-clean-up-gup_test-invocation.patch
selftests-vm-hmm-tests-remove-the-libhugetlbfs-dependency.patch
selftests-vm-hmm-tests-remove-the-libhugetlbfs-dependency-fix.patch
--- End Message ---
[PATCH] scripts: kernel-doc: allow passing desired Sphinx C domain dialect
When kernel-doc is called via kerneldoc.py, there's no need to
auto-detect the Sphinx version, as the Sphinx module already
knows it. So, add an optional parameter to allow changing the
Sphinx dialect.
As kernel-doc can also be manually called, keep the auto-detection
logic if the parameter was not specified. On such case, emit
a warning if sphinx-build can't be found at PATH.
Suggested-by: Jonathan Corbet
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/sphinx/kerneldoc.py | 5
scripts/kernel-doc| 40 ---
2 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/Documentation/sphinx/kerneldoc.py
b/Documentation/sphinx/kerneldoc.py
index 233f610539f0..e9857ab904f1 100644
--- a/Documentation/sphinx/kerneldoc.py
+++ b/Documentation/sphinx/kerneldoc.py
@@ -71,6 +71,11 @@ class KernelDocDirective(Directive):
env = self.state.document.settings.env
cmd = [env.config.kerneldoc_bin, '-rst', '-enable-lineno']
+ # Pass the version string to kernel-doc, as it needs to use a different
+ # dialect, depending what the C domain supports for each specific
+ # Sphinx versions
+cmd += ['-sphinx-version', sphinx.__version__]
+
filename = env.config.kerneldoc_srctree + '/' + self.arguments[0]
export_file_patterns = []
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 5ac3749905e5..01efb0afb8c2 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -56,6 +56,13 @@ Output format selection (mutually exclusive):
-rst Output reStructuredText format.
-noneDo not output documentation, only warnings.
+Output format selection modifier (affects only ReST output):
+
+ -sphinx-version Use the ReST C domain dialect compatible with an
+ specific Sphinx Version.
+ If not specified, kernel-doc will auto-detect using
+ the sphinx-build version found on PATH.
+
Output selection (mutually exclusive):
-export Only output documentation for symbols that have been
exported using EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL()
@@ -270,7 +277,7 @@ if ($#ARGV == -1) {
}
my $kernelversion;
-my $sphinx_major;
+my ($sphinx_major, $sphinx_minor, $sphinx_patch);
my $dohighlight = "";
@@ -457,6 +464,15 @@ while ($ARGV[0] =~ m/^--?(.*)/) {
$enable_lineno = 1;
} elsif ($cmd eq 'show-not-found') {
$show_not_found = 1; # A no-op but don't fail
+} elsif ($cmd eq "sphinx-version") {
+ my $ver_string = shift @ARGV;
+ if ($ver_string =~ m/^(\d+)\.(\d+)\.(\d+)/) {
+ $sphinx_major = $1;
+ $sphinx_minor = $2;
+ $sphinx_patch = $3;
+ } else {
+ die "Sphinx version should be at major.minor.patch format\n";
+ }
} else {
# Unknown argument
usage();
@@ -477,29 +493,37 @@ sub findprog($)
sub get_sphinx_version()
{
my $ver;
- my $major = 1;
my $cmd = "sphinx-build";
if (!findprog($cmd)) {
my $cmd = "sphinx-build3";
- return $major if (!findprog($cmd));
+ if (!findprog($cmd)) {
+ $sphinx_major = 1;
+ $sphinx_minor = 2;
+ $sphinx_patch = 0;
+ printf STDERR "Warning: Sphinx version not found. Using
default (Sphinx version %d.%d.%d)\n",
+ $sphinx_major, $sphinx_minor, $sphinx_patch;
+ return;
+ }
}
open IN, "$cmd --version 2>&1 |";
while () {
if (m/^\s*sphinx-build\s+([\d]+)\.([\d\.]+)(\+\/[\da-f]+)?$/) {
- $major=$1;
+ $sphinx_major = $1;
+ $sphinx_minor = $2;
+ $sphinx_patch = $3;
last;
}
# Sphinx 1.2.x uses a different format
if (m/^\s*Sphinx.*\s+([\d]+)\.([\d\.]+)$/) {
- $major=$1;
+ $sphinx_major = $1;
+ $sphinx_minor = $2;
+ $sphinx_patch = $3;
last;
}
}
close IN;
-
- return $major;
}
# get kernel version from env
@@ -2338,7 +2362,7 @@ sub process_file($) {
}
-$sphinx_major = get_sphinx_version();
+get_sphinx_version() if (!$sphinx_major);
$kernelversion = get_kernel_version();
# generate a sequence of code that will splice in highlighting information
--
2.26.2
Re: [PATCH v2 8/8] selftests/vm: hmm-tests: remove the libhugetlbfs dependency
On Tue, 29 Sep 2020, John Hubbard wrote: > HMM selftests are incredibly useful, but they are only effective if > people actually build and run them. All the other tests in selftests/vm > can be built with very standard, always-available libraries: libpthread, > librt. The hmm-tests.c program, on the other hand, requires something > that is (much) less readily available: libhugetlbfs. And so the build > will typically fail for many developers. > > A simple attempt to install libhugetlbfs will also run into > complications on some common distros these days: Fedora and Arch Linux > (yes, Arch AUR has it, but that's fragile, as always with AUR). The > library is not maintained actively enough at the moment, for distros to > deal with it. I had to build it from source, for Fedora, and that didn't > go too smoothly either. > > It turns out that, out of 21 tests in hmm-tests.c, only 2 actually > require functionality from libhugetlbfs. Therefore, if libhugetlbfs is > missing, simply ifdef those two tests out and allow the developer to at > least have the other 19 tests, if they don't want to pause to work > through the above issues. Also issue a warning, so that it's clear that > there is an imperfection in the build. > > In order to do that, a tiny shell script (check_config.sh) runs a quick > compile (not link, that's too prone to false failures with library > paths), and basically, if the compiler doesn't find hugetlbfs.h in its > standard locations, then the script concludes that libhugetlbfs is not > available. The output is in two files, one for inclusion in hmm-test.c > (local_config.h), and one for inclusion in the Makefile > (local_config.mk). > > Cc: Ralph Campbell > Signed-off-by: John Hubbard > --- > tools/testing/selftests/vm/.gitignore | 1 + > tools/testing/selftests/vm/Makefile| 24 +++-- > tools/testing/selftests/vm/check_config.sh | 31 ++ > tools/testing/selftests/vm/hmm-tests.c | 10 ++- > 4 files changed, 63 insertions(+), 3 deletions(-) > create mode 100755 tools/testing/selftests/vm/check_config.sh > > diff --git a/tools/testing/selftests/vm/.gitignore > b/tools/testing/selftests/vm/.gitignore > index 2c8ddcf41c0e..e90d28bcd518 100644 > --- a/tools/testing/selftests/vm/.gitignore > +++ b/tools/testing/selftests/vm/.gitignore > @@ -20,3 +20,4 @@ va_128TBswitch > map_fixed_noreplace > write_to_hugetlbfs > hmm-tests > +local_config.* > diff --git a/tools/testing/selftests/vm/Makefile > b/tools/testing/selftests/vm/Makefile > index 2579242386ac..019cbb7f3cf8 100644 > --- a/tools/testing/selftests/vm/Makefile > +++ b/tools/testing/selftests/vm/Makefile > @@ -1,5 +1,8 @@ > # SPDX-License-Identifier: GPL-2.0 > # Makefile for vm selftests > + > +include local_config.mk > + John, your change makes: tools/testing/selftests$ make clean fail with: make[1]: Entering directory '/home/lukas/repositories/kernel.org/pub/scm/linux/kernel/git/next/linux-next/tools/testing/selftests/vm' Makefile:4: local_config.mk: No such file or directory ./check_config.sh gcc make[1]: execvp: ./check_config.sh: Permission denied Makefile:141: recipe for target 'local_config.mk' failed make[1]: *** [local_config.mk] Error 127 when make clean is called without building the vm selftests before, e.g., when someone just cleans everything in the repository to just be sure that everything is clean. Lukas > uname_M := $(shell uname -m 2>/dev/null || echo not) > MACHINE ?= $(shell echo $(uname_M) | sed -e 's/aarch64.*/arm64/') > > @@ -76,8 +79,6 @@ TEST_FILES := test_vmalloc.sh > KSFT_KHDR_INSTALL := 1 > include ../lib.mk > > -$(OUTPUT)/hmm-tests: LDLIBS += -lhugetlbfs > - > ifeq ($(ARCH),x86_64) > BINARIES_32 := $(patsubst %,$(OUTPUT)/%,$(BINARIES_32)) > BINARIES_64 := $(patsubst %,$(OUTPUT)/%,$(BINARIES_64)) > @@ -130,3 +131,22 @@ endif > $(OUTPUT)/mlock-random-test: LDLIBS += -lcap > > $(OUTPUT)/gup_test: ../../../../mm/gup_test.h > + > +$(OUTPUT)/hmm-tests: local_config.h > + > +# HMM_EXTRA_LIBS may get set in local_config.mk, or it may be left empty. > +$(OUTPUT)/hmm-tests: LDLIBS += $(HMM_EXTRA_LIBS) > + > +local_config.mk local_config.h: check_config.sh > + ./check_config.sh $(CC) > + > +EXTRA_CLEAN += local_config.mk local_config.h > + > +ifeq ($(HMM_EXTRA_LIBS),) > +all: warn_missing_hugelibs > + > +warn_missing_hugelibs: > + @echo ; \ > + echo "Warning: missing libhugetlbfs support. Some HMM tests will be > skipped." ; \ > + echo > +endif > diff --git a/tools/testing/selftests/vm/check_config.sh > b/tools/testing/selftests/vm/check_config.sh > new file mode 100755 > index ..079c8a40b85d > --- /dev/null > +++ b/tools/testing/selftests/vm/check_config.sh > @@ -0,0 +1,31 @@ > +#!/bin/sh > +# SPDX-License-Identifier: GPL-2.0 > +# > +# Probe for libraries and create header files to record the results. Both C > +# header files and Makefile include fragments are created. > + > +OUTPUT_H_FILE=local_confi
Re: linux-next: build warning after merge of the tip tree
On Sun, Oct 04, 2020 at 10:24:37AM +1100, Stephen Rothwell wrote: > On Sat, 3 Oct 2020 14:54:46 -0700 Kees Cook wrote: > > On Mon, Sep 14, 2020 at 01:22:49PM +1000, Stephen Rothwell wrote: > > > > > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig) > > > produced this warning: > > > > > > x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from > > > `kernel/trace/trace_selftest_dynamic.o' being placed in section > > > `.ctors.65435' > > > [...] > > > > Is it only trace that is warning? > > Yes, it is only trace. it is always 65435 as well, in case that matters. > > > > gcc (Debian 10.2.0-5) 10.2.0 > > > GNU ld (GNU Binutils for Debian) 2.35 > > > > I can't reproduce this with: > > > > gcc (Ubuntu 10.2.0-11ubuntu1) 10.2.0 > > GNU ld (GNU Binutils for Ubuntu) 2.35.1 > > > > Are you running Debian testing or unstable? (I see binutils 2.35.1 is > > in both, so was this fixed in the .1?) > > > > I will go build a Debian testing container... Still nothing for me on Debian testing, x86_64 host: gcc (Debian 10.2.0-9) 10.2.0 GNU ld (GNU Binutils for Debian) 2.35.1 $ lsb_release -r Release:testing $ uname -m x86_64 > I am running testing. Just upgraded to 2.35.1 and the messages are > still there. (I did a build of just tip/auto-latest - this is a cross > build powerpc le hosted) Interesting. I can't imagine this would be host-specific? -- Kees Cook
Re: [PATCH RFC 2/2] kbuild: use interpreters to invoke scripts
On Sat, Oct 03, 2020 at 08:51:23PM +0530, Ujjwal Kumar wrote: > We cannot rely on execute bits to be set on files in the repository. > The build script should use the explicit interpreter when invoking any > script from the repository. > > Link: > https://lore.kernel.org/lkml/20200830174409.c24c3f67addcce0cea9a9...@linux-foundation.org/ > Link: https://lore.kernel.org/lkml/202008271102.FEB906C88@keescook/ > > Suggested-by: Andrew Morton > Suggested-by: Kees Cook > Suggested-by: Lukas Bulwahn > Signed-off-by: Ujjwal Kumar Reviewed-by: Nathan Chancellor > --- > Makefile | 4 ++-- > arch/arm64/kernel/vdso/Makefile | 2 +- > arch/arm64/kernel/vdso32/Makefile | 2 +- > arch/ia64/Makefile| 4 ++-- > arch/nds32/kernel/vdso/Makefile | 2 +- > scripts/Makefile.build| 2 +- > scripts/Makefile.package | 4 ++-- > 7 files changed, 10 insertions(+), 10 deletions(-) > > diff --git a/Makefile b/Makefile > index f93dbae71248..5f1399a576d4 100644 > --- a/Makefile > +++ b/Makefile > @@ -1258,7 +1258,7 @@ include/generated/utsrelease.h: > include/config/kernel.release FORCE > PHONY += headerdep > headerdep: > $(Q)find $(srctree)/include/ -name '*.h' | xargs --max-args 1 \ > - $(srctree)/scripts/headerdep.pl -I$(srctree)/include > + $(PERL) $(srctree)/scripts/headerdep.pl -I$(srctree)/include > > # --- > # Kernel headers > @@ -1314,7 +1314,7 @@ PHONY += kselftest-merge > kselftest-merge: > $(if $(wildcard $(objtree)/.config),, $(error No .config exists, config > your kernel first!)) > $(Q)find $(srctree)/tools/testing/selftests -name config | \ > - xargs $(srctree)/scripts/kconfig/merge_config.sh -m > $(objtree)/.config > + xargs $(CONFIG_SHELL) > $(srctree)/scripts/kconfig/merge_config.sh -m $(objtree)/.config > $(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig > > # --- > diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile > index de981f7b4546..30fe93bb5488 100644 > --- a/arch/arm64/kernel/vdso/Makefile > +++ b/arch/arm64/kernel/vdso/Makefile > @@ -65,7 +65,7 @@ $(obj)/%.so: $(obj)/%.so.dbg FORCE > # Generate VDSO offsets using helper script > gen-vdsosym := $(srctree)/$(src)/gen_vdso_offsets.sh > quiet_cmd_vdsosym = VDSOSYM $@ > - cmd_vdsosym = $(NM) $< | $(gen-vdsosym) | LC_ALL=C sort > $@ > + cmd_vdsosym = $(NM) $< | $(CONFIG_SHELL) $(gen-vdsosym) | LC_ALL=C > sort > $@ > > include/generated/vdso-offsets.h: $(obj)/vdso.so.dbg FORCE > $(call if_changed,vdsosym) > diff --git a/arch/arm64/kernel/vdso32/Makefile > b/arch/arm64/kernel/vdso32/Makefile > index 572475b7b7ed..4f8fe34bc75a 100644 > --- a/arch/arm64/kernel/vdso32/Makefile > +++ b/arch/arm64/kernel/vdso32/Makefile > @@ -205,7 +205,7 @@ quiet_cmd_vdsomunge = MUNGE $@ > gen-vdsosym := $(srctree)/$(src)/../vdso/gen_vdso_offsets.sh > quiet_cmd_vdsosym = VDSOSYM $@ > # The AArch64 nm should be able to read an AArch32 binary > - cmd_vdsosym = $(NM) $< | $(gen-vdsosym) | LC_ALL=C sort > $@ > + cmd_vdsosym = $(NM) $< | $(CONFIG_SHELL) $(gen-vdsosym) | LC_ALL=C > sort > $@ > > # Install commands for the unstripped file > quiet_cmd_vdso_install = INSTALL32 $@ > diff --git a/arch/ia64/Makefile b/arch/ia64/Makefile > index 2876a7df1b0a..5f6cc3c3da50 100644 > --- a/arch/ia64/Makefile > +++ b/arch/ia64/Makefile > @@ -28,8 +28,8 @@ cflags-y:= -pipe $(EXTRA) -ffixed-r13 > -mfixed-range=f12-f15,f32-f127 \ > -falign-functions=32 -frename-registers > -fno-optimize-sibling-calls > KBUILD_CFLAGS_KERNEL := -mconstant-gp > > -GAS_STATUS = $(shell $(srctree)/arch/ia64/scripts/check-gas "$(CC)" > "$(OBJDUMP)") > -KBUILD_CPPFLAGS += $(shell $(srctree)/arch/ia64/scripts/toolchain-flags > "$(CC)" "$(OBJDUMP)" "$(READELF)") > +GAS_STATUS = $($(CONFIG_SHELL) $(srctree)/arch/ia64/scripts/check-gas > "$(CC)" "$(OBJDUMP)") > +KBUILD_CPPFLAGS += $($(CONFIG_SHELL) > $(srctree)/arch/ia64/scripts/toolchain-flags "$(CC)" "$(OBJDUMP)" > "$(READELF)") > > ifeq ($(GAS_STATUS),buggy) > $(error Sorry, you need a newer version of the assember, one that is built > from \ > diff --git a/arch/nds32/kernel/vdso/Makefile b/arch/nds32/kernel/vdso/Makefile > index 55df25ef0057..e77d4bcfa7c1 100644 > --- a/arch/nds32/kernel/vdso/Makefile > +++ b/arch/nds32/kernel/vdso/Makefile > @@ -39,7 +39,7 @@ $(obj)/%.so: $(obj)/%.so.dbg FORCE > # Generate VDSO offsets using helper script > gen-vdsosym := $(srctree)/$(src)/gen_vdso_offsets.sh > quiet_cmd_vdsosym = VDSOSYM $@ > - cmd_vdsosym = $(NM) $< | $(gen-vdsosym) | LC_ALL=C sort > $@ > + cmd_vdsosym = $(NM) $< | $(CONFIG_SHELL) $(gen-vdsosym) | LC_ALL=C > sort > $@ > > include/generated/vdso-offsets.h: $(obj)/vdso.so.dbg FORCE > $(call if_changed,vdsosym
Re: [PATCH RFC 1/2] kconfig: use interpreters to invoke scripts
On Sat, Oct 03, 2020 at 08:50:10PM +0530, Ujjwal Kumar wrote: > We cannot rely on execute bits to be set on files in the repository. > The build script should use the explicit interpreter when invoking any > script from the repository. > > Link: > https://lore.kernel.org/lkml/20200830174409.c24c3f67addcce0cea9a9...@linux-foundation.org/ > Link: https://lore.kernel.org/lkml/202008271102.FEB906C88@keescook/ > > Suggested-by: Andrew Morton > Suggested-by: Kees Cook > Suggested-by: Lukas Bulwahn > Signed-off-by: Ujjwal Kumar Reviewed-by: Nathan Chancellor > --- > init/Kconfig | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/init/Kconfig b/init/Kconfig > index 91456ac0ef20..524f6b555945 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -30,12 +30,12 @@ config CC_IS_GCC > > config GCC_VERSION > int > - default $(shell,$(srctree)/scripts/gcc-version.sh $(CC)) if CC_IS_GCC > + default $(shell,$(CONFIG_SHELL) $(srctree)/scripts/gcc-version.sh > $(CC)) if CC_IS_GCC > default 0 > > config LD_VERSION > int > - default $(shell,$(LD) --version | $(srctree)/scripts/ld-version.sh) > + default $(shell,$(LD) --version | $(AWK) -f > $(srctree)/scripts/ld-version.sh) > > config CC_IS_CLANG > def_bool $(success,echo "$(CC_VERSION_TEXT)" | grep -q clang) > @@ -45,20 +45,20 @@ config LD_IS_LLD > > config CLANG_VERSION > int > - default $(shell,$(srctree)/scripts/clang-version.sh $(CC)) > + default $(shell,$(CONFIG_SHELL) $(srctree)/scripts/clang-version.sh > $(CC)) > > config CC_CAN_LINK > bool > - default $(success,$(srctree)/scripts/cc-can-link.sh $(CC) > $(CLANG_FLAGS) $(m64-flag)) if 64BIT > - default $(success,$(srctree)/scripts/cc-can-link.sh $(CC) > $(CLANG_FLAGS) $(m32-flag)) > + default $(success,$(CONFIG_SHELL) $(srctree)/scripts/cc-can-link.sh > $(CC) $(CLANG_FLAGS) $(m64-flag)) if 64BIT > + default $(success,$(CONFIG_SHELL) $(srctree)/scripts/cc-can-link.sh > $(CC) $(CLANG_FLAGS) $(m32-flag)) > > config CC_CAN_LINK_STATIC > bool > - default $(success,$(srctree)/scripts/cc-can-link.sh $(CC) > $(CLANG_FLAGS) $(m64-flag) -static) if 64BIT > - default $(success,$(srctree)/scripts/cc-can-link.sh $(CC) > $(CLANG_FLAGS) $(m32-flag) -static) > + default $(success,$(CONFIG_SHELL) $(srctree)/scripts/cc-can-link.sh > $(CC) $(CLANG_FLAGS) $(m64-flag) -static) if 64BIT > + default $(success,$(CONFIG_SHELL) $(srctree)/scripts/cc-can-link.sh > $(CC) $(CLANG_FLAGS) $(m32-flag) -static) > > config CC_HAS_ASM_GOTO > - def_bool $(success,$(srctree)/scripts/gcc-goto.sh $(CC)) > + def_bool $(success,$(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC)) > > config CC_HAS_ASM_GOTO_OUTPUT > depends on CC_HAS_ASM_GOTO > -- > 2.26.2 >
RE: [PATCH 1/2] scsi: ufs: Add DeepSleep feature
> + /* > +* DeepSleep requires the Immediate flag. DeepSleep state is actually > +* entered when the link state goes to Hibern8. > +*/ > + if (pwr_mode == UFS_DEEPSLEEP_PWR_MODE) > + cmd[1] = 1; Shouldn't it be bit1, i.e. cmd[1] = 2 ? > cmd[4] = pwr_mode << 4; >
Re: [PATCH net-next 03/16] devlink: Add devlink reload limit option
On 10/3/2020 6:04 PM, Jakub Kicinski wrote:
External email: Use caution opening links or attachments
On Sat, 3 Oct 2020 09:51:00 +0200 Jiri Pirko wrote:
enum devlink_attr {
/* don't change the order or add anything between, this is ABI! */
DEVLINK_ATTR_UNSPEC,
@@ -507,6 +524,7 @@ enum devlink_attr {
DEVLINK_ATTR_RELOAD_ACTION, /* u8 */
DEVLINK_ATTR_RELOAD_ACTIONS_PERFORMED, /* u64 */
+DEVLINK_ATTR_RELOAD_LIMIT, /* u8 */
Hmm, why there could be specified only single "limit"? I believe this
should be a bitfield. Same for the internal api to the driver.
Hm I was expecting limits to be ordered (in maths sense) but you're
right perhaps that can't be always guaranteed.
Also - Moshe please double check that there will not be any kdoc
warnings here - I just learned that W=1 builds don't check headers
but I'll fix up my bot by the time you post v2.
Didn't know this tool, but I will. Thanks.
Re: [PATCH 4/4] ubsan: Disable UBSAN_TRAP for all*config
On Fri, Oct 02, 2020 at 03:15:27PM -0700, Kees Cook wrote: > Doing all*config builds attempts build as much as possible. UBSAN_TRAP > effectively short-circuits lib/usban.c, so it should be disabled for > COMPILE_TEST so that the lib/ubsan.c code gets built. > > Signed-off-by: Kees Cook Reviewed-by: Nathan Chancellor > --- > lib/Kconfig.ubsan | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan > index 1fc07f936e06..b5b9da0b635a 100644 > --- a/lib/Kconfig.ubsan > +++ b/lib/Kconfig.ubsan > @@ -14,6 +14,7 @@ if UBSAN > > config UBSAN_TRAP > bool "On Sanitizer warnings, abort the running kernel code" > + depends on !COMPILE_TEST > depends on $(cc-option, -fsanitize-undefined-trap-on-error) > help > Building kernels with Sanitizer features enabled tends to grow > -- > 2.25.1
Re: [PATCH 3/4] ubsan: Force -Wno-maybe-uninitialized only for GCC
On Fri, Oct 02, 2020 at 03:15:26PM -0700, Kees Cook wrote: > Clang handles 'maybe-uninitialized' better in the face of using UBSAN, > so do not make this universally disabled for UBSAN builds. > > Signed-off-by: Kees Cook Well this patch is not strictly necessary because Clang does not support -Wmaybe-uninitialized anyways :) its flags are -Wuninitialized and -Wsometimes-uninitialized so the warning stays enabled for UBSAN as it stands. However, something like this could still worthwhile because it would save us one call to cc-disable-warning (yay micro optimizations). Maybe it just does not need to have a whole new symbol, just make it ubsan-cflags-$(CONFIG_CC_IS_GCC) instead of ubsan-cflags-$(CONFIG_UBSAN) No strong opinions either way though. > --- > lib/Kconfig.ubsan | 6 ++ > scripts/Makefile.ubsan | 6 +++--- > 2 files changed, 9 insertions(+), 3 deletions(-) > > diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan > index aeb2cdea0b94..1fc07f936e06 100644 > --- a/lib/Kconfig.ubsan > +++ b/lib/Kconfig.ubsan > @@ -36,6 +36,12 @@ config UBSAN_KCOV_BROKEN > See https://bugs.llvm.org/show_bug.cgi?id=45831 for the status > in newer releases. > > +config UBSAN_DISABLE_MAYBE_UNINITIALIZED > + def_bool CC_IS_GCC > + help > + -fsanitize=* options makes GCC less smart than usual and > + increases the number of 'maybe-uninitialized' false-positives. > + > config CC_HAS_UBSAN_BOUNDS > def_bool $(cc-option,-fsanitize=bounds) > > diff --git a/scripts/Makefile.ubsan b/scripts/Makefile.ubsan > index 72862da47baf..c5ef6bac09d4 100644 > --- a/scripts/Makefile.ubsan > +++ b/scripts/Makefile.ubsan > @@ -1,8 +1,8 @@ > # SPDX-License-Identifier: GPL-2.0 > > -# -fsanitize=* options makes GCC less smart than usual and > -# increases the number of 'maybe-uninitialized' false-positives. > -ubsan-cflags-$(CONFIG_UBSAN) += $(call cc-disable-warning, > maybe-uninitialized) > +# The "maybe-uninitialized" warning can be very noisy. > +ubsan-cflags-$(CONFIG_UBSAN_DISABLE_MAYBE_UNINITIALIZED) += \ > + $(call cc-disable-warning, > maybe-uninitialized) > > # Enable available and selected UBSAN features. > ubsan-cflags-$(CONFIG_UBSAN_ALIGNMENT) += -fsanitize=alignment > -- > 2.25.1
Re: [PATCH net-next 16/16] devlink: Add Documentation/networking/devlink/devlink-reload.rst
On 10/3/2020 12:14 PM, Jiri Pirko wrote:
Thu, Oct 01, 2020 at 03:59:19PM CEST, mo...@mellanox.com wrote:
Add devlink reload rst documentation file.
Update index file to include it.
Signed-off-by: Moshe Shemesh
---
RFCv5 -> v1:
- Rename reload_action_limit_level to reload_limit
RFCv4 -> RFCv5:
- Rephrase namespace chnage section
- Rephrase note on actions performed
RFCv3 -> RFCv4:
- Remove reload action fw_activate_no_reset
- Add reload actions limit levels and document the no_reset limit level
constrains
RFCv2 -> RFCv3:
- Devlink reload returns the actions done
- Replace fw_live_patch action by fw_activate_no_reset
- Explain fw_activate meaning
RFCv1 -> RFCv2:
- Instead of reload levels driver,fw_reset,fw_live_patch have reload
actions driver_reinit,fw_activate,fw_live_patch
---
.../networking/devlink/devlink-reload.rst | 81 +++
Documentation/networking/devlink/index.rst| 1 +
2 files changed, 82 insertions(+)
create mode 100644 Documentation/networking/devlink/devlink-reload.rst
diff --git a/Documentation/networking/devlink/devlink-reload.rst
b/Documentation/networking/devlink/devlink-reload.rst
new file mode 100644
index ..5abc5c2c75fd
--- /dev/null
+++ b/Documentation/networking/devlink/devlink-reload.rst
@@ -0,0 +1,81 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
+Devlink Reload
No reason for capital "R".
It looks as the convention here for rst headers, as in
devlink-region.rst, devlink-trap.rst, devlink-resource.rst
+==
+
+``devlink-reload`` provides mechanism to either reinit driver entities,
+applying ``devlink-params`` and ``devlink-resources`` new values or firmware
+activation depends on reload action selected.
Could you perhaps split the sentense? It is hard to read.
Yes.
+
+Reload actions
+==
+
+User may select a reload action.
+By default ``driver_reinit`` action is selected.
+
+.. list-table:: Possible reload actions
+ :widths: 5 90
+
+ * - Name
+ - Description
+ * - ``driver-reinit``
+ - Devlink driver entities re-initialization, including applying
+ new values to devlink entities which are used during driver
+ load such as ``devlink-params`` in configuration mode
+ ``driverinit`` or ``devlink-resources``
+ * - ``fw_activate``
+ - Firmware activate. Activates new firmware if such image is stored and
+ pending activation. If no limitation specified this action may involve
+ firmware reset. If no new image pending this action will reload current
+ firmware image.
+
+Note that even though user asks for a specific action, the driver
+implementation might require to perform another action alongside with
+it. For example, some driver do not support driver reinitialization
+being performed without fw activation. Therefore, the devlink reload
+command returns the list of actions which were actrually performed.
+
+Reload limits
+=
+
+By default reload actions are not limited and driver implementation may
+include reset or downtime as needed to perform the actions.
+
+However, some drivers support action limits, which limit the action
+implementation to specific constrains.
+
+.. list-table:: Possible reload limits
+ :widths: 5 90
+
+ * - Name
+ - Description
+ * - ``no_reset``
+ - No reset allowed, no down time allowed, no link flap and no
+ configuration is lost.
+
+Change namespace
+
+
+The netns option allow user to be able to move devlink instances into
"allows"
Ack.
+namespaces during devlink reload operation.
+By default all devlink instances are created in init_net and stay there.
+
+example usage
+-
+
+.. code:: shell
+
+$ devlink dev reload help
+$ devlink dev reload DEV [ netns { PID | NAME | ID } ] [ action {
driver_reinit | fw_activate } ] [ limit no_reset ]
+
+# Run reload command for devlink driver entities re-initialization:
+$ devlink dev reload pci/:82:00.0 action driver_reinit
+reload_actions_performed:
+ driver_reinit
+
+# Run reload command to activate firmware:
+# Note that mlx5 driver reloads the driver while activating firmware
+$ devlink dev reload pci/:82:00.0 action fw_activate
+reload_actions_performed:
+ driver_reinit fw_activate
diff --git a/Documentation/networking/devlink/index.rst
b/Documentation/networking/devlink/index.rst
index 7684ae5c4a4a..d82874760ae2 100644
--- a/Documentation/networking/devlink/index.rst
+++ b/Documentation/networking/devlink/index.rst
@@ -20,6 +20,7 @@ general.
devlink-params
devlink-region
devlink-resource
+ devlink-reload
devlink-trap
Driver-specific documentation
--
2.18.2
Re: [PATCH v2] net: hso: do not call unregister if not registered
On Sat, Oct 03, 2020 at 05:00:42PM -0700, David Miller wrote: > From: Greg KH > Date: Fri, 2 Oct 2020 13:43:23 +0200 > > > @@ -2366,7 +2366,8 @@ static void hso_free_net_device(struct hso_device > > *hso_dev, bool bailout) > > > > remove_net_device(hso_net->parent); > > > > - if (hso_net->net) > > + if (hso_net->net && > > + hso_net->net->reg_state == NETREG_REGISTERED) > > unregister_netdev(hso_net->net); > > > > /* start freeing */ > > I really want to get out of the habit of drivers testing the internal > netdev registration state to make decisions. > > Instead, please track this internally. You know if you registered the > device or not, therefore use that to control whether you try to > unregister it or not. Fair enough. Tuba, do you want to fix this up in this way, or do you recommend that someone else do it? thanks, greg k-h
Re: [PATCH 2/4] ubsan: Disable object-size sanitizer under GCC
On Fri, Oct 02, 2020 at 03:15:25PM -0700, Kees Cook wrote: > GCC's -fsanitize=object-size (as part of CONFIG_UBSAN_MISC) greatly > increases stack utilization. Do not allow this under GCC. > > Suggested-by: Linus Torvalds > Signed-off-by: Kees Cook > Link: > https://lore.kernel.org/lkml/CAHk-=wjPasyJrDuwDnpHJS2TuQfExwe=px-szlen8gfmaqj...@mail.gmail.com/ Reviewed-by: Nathan Chancellor > --- > lib/Kconfig.ubsan | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan > index c0b801871e0b..aeb2cdea0b94 100644 > --- a/lib/Kconfig.ubsan > +++ b/lib/Kconfig.ubsan > @@ -104,6 +104,9 @@ config UBSAN_UNSIGNED_OVERFLOW > > config UBSAN_OBJECT_SIZE > def_bool UBSAN_MISC > + # gcc hugely expands stack usage with -fsanitize=object-size > + # > https://lore.kernel.org/lkml/CAHk-=wjPasyJrDuwDnpHJS2TuQfExwe=px-szlen8gfmaqj...@mail.gmail.com/ > + depends on !CC_IS_GCC > depends on $(cc-option,-fsanitize=object-size) > > config UBSAN_BOOL > -- > 2.25.1
Re: [PATCH net-next 05/16] devlink: Add remote reload stats
On 10/3/2020 12:05 PM, Jiri Pirko wrote:
Thu, Oct 01, 2020 at 03:59:08PM CEST, mo...@mellanox.com wrote:
Add remote reload stats to hold the history of actions performed due
devlink reload commands initiated by remote host. For example, in case
firmware activation with reset finished successfully but was initiated
by remote host.
The function devlink_remote_reload_actions_performed() is exported to
enable drivers update on remote reload actions performed as it was not
initiated by their own devlink instance.
Expose devlink remote reload stats to the user through devlink dev get
command.
Examples:
$ devlink dev show
pci/:82:00.0:
stats:
reload_stats:
driver_reinit 2
fw_activate 1
fw_activate_no_reset 0
remote_reload_stats:
driver_reinit 0
fw_activate 0
fw_activate_no_reset 0
pci/:82:00.1:
stats:
reload_stats:
driver_reinit 1
fw_activate 0
fw_activate_no_reset 0
remote_reload_stats:
driver_reinit 1
fw_activate 1
fw_activate_no_reset 0
$ devlink dev show -jp
{
"dev": {
"pci/:82:00.0": {
"stats": {
"reload_stats": [ {
"driver_reinit": 2
},{
"fw_activate": 1
},{
"fw_activate_no_reset": 0
} ],
"remote_reload_stats": [ {
"driver_reinit": 0
},{
"fw_activate": 0
},{
"fw_activate_no_reset": 0
} ]
}
},
"pci/:82:00.1": {
"stats": {
"reload_stats": [ {
"driver_reinit": 1
},{
"fw_activate": 0
},{
"fw_activate_no_reset": 0
} ],
"remote_reload_stats": [ {
"driver_reinit": 1
},{
"fw_activate": 1
},{
"fw_activate_no_reset": 0
} ]
}
}
}
}
Signed-off-by: Moshe Shemesh
---
RFCv5 -> v1:
- Resplit this patch and the previous one by remote/local reload stats
instead of set/get reload stats
- Rename reload_action_stats to reload_stats
RFCv4 -> RFCv5:
- Add remote actions stats
- If devlink reload is not supported, show only remote_stats
RFCv3 -> RFCv4:
- Renamed DEVLINK_ATTR_RELOAD_ACTION_CNT to
DEVLINK_ATTR_RELOAD_ACTION_STAT
- Add stats per action per limit level
RFCv2 -> RFCv3:
- Add reload actions counters instead of supported reload actions
(reload actions counters are only for supported action so no need for
both)
RFCv1 -> RFCv2:
- Removed DEVLINK_ATTR_RELOAD_DEFAULT_LEVEL
- Removed DEVLINK_ATTR_RELOAD_LEVELS_INFO
- Have actions instead of levels
---
include/net/devlink.h| 1 +
include/uapi/linux/devlink.h | 1 +
net/core/devlink.c | 49 +++-
3 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/include/net/devlink.h b/include/net/devlink.h
index 0f3bd23b6c04..a4ccb83bbd2c 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -42,6 +42,7 @@ struct devlink {
const struct devlink_ops *ops;
struct xarray snapshot_ids;
u32 reload_stats[DEVLINK_RELOAD_STATS_ARRAY_SIZE];
+ u32 remote_reload_stats[DEVLINK_RELOAD_STATS_ARRAY_SIZE];
Perhaps a nested struct {} stats?
I guess you mean struct that holds these two arrays.
struct device *dev;
possible_net_t _net;
struct mutex lock; /* Serializes access to devlink instance specific
objects such as
diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h
index 97e0137f6201..f9887d8afdc7 100644
--- a/include/uapi/linux/devlink.h
+++ b/include/uapi/linux/devlink.h
@@ -530,6 +530,7 @@ enum devlink_attr {
DEVLINK_ATTR_RELOAD_STATS, /* nested */
DEVLINK_ATTR_RELOAD_STATS_ENTRY,/* nested */
DEVLINK_ATTR_RELOAD_STATS_VALUE,/* u32 */
+ DEVLINK_ATTR_REMOTE_RELOAD_STATS, /* nested */
/* add new attributes above here, update the policy in devlink.c */
diff --git a/net/core/devlink.c b/net/core/devlink.c
index 05516f1e4c3e..3b6bd3b4d346 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -523,28 +523,35 @@ static int devlink_reload_stat_put(struct sk_buff *msg,
enum devlink_reload_acti
return -EMSGSIZE;
}
-static int devlink_reload_stats_put(struct sk_buff *msg, struct devlink
*devlink)
+static int devlink_reload_stats_put(struct sk_buff *msg, struct devlink
*devlink, bool is_remote)
{
struct nlattr *reload_stats_attr;
int i, j, stat_idx;
u32 value;
- reload_stats_attr = nla_nest_start(msg, DEVLINK_ATTR_RELOAD_S
Re: [PATCH 1/4] ubsan: Move cc-option tests into Kconfig
On Fri, Oct 02, 2020 at 03:15:24PM -0700, Kees Cook wrote:
> Instead of doing if/endif blocks with cc-option calls in the UBSAN
> Makefile, move all the tests into Kconfig and use the Makefile to
> collect the results.
>
> Suggested-by: Linus Torvalds
> Signed-off-by: Kees Cook
> Link:
> https://lore.kernel.org/lkml/CAHk-=wjPasyJrDuwDnpHJS2TuQfExwe=px-szlen8gfmaqj...@mail.gmail.com/
I tested menuconfig to make sure all the flags when CONFIG_UBSAN_MISC is
flipped.
Reviewed-by: Nathan Chancellor
Tested-by: Nathan Chancellor
One comment below.
> ---
> lib/Kconfig.ubsan | 48 +++-
> scripts/Makefile.ubsan | 50 ++
> 2 files changed, 64 insertions(+), 34 deletions(-)
>
> diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
> index 58f8d03d037b..c0b801871e0b 100644
> --- a/lib/Kconfig.ubsan
> +++ b/lib/Kconfig.ubsan
> @@ -36,10 +36,17 @@ config UBSAN_KCOV_BROKEN
> See https://bugs.llvm.org/show_bug.cgi?id=45831 for the status
> in newer releases.
>
> +config CC_HAS_UBSAN_BOUNDS
> + def_bool $(cc-option,-fsanitize=bounds)
> +
> +config CC_HAS_UBSAN_ARRAY_BOUNDS
> + def_bool $(cc-option,-fsanitize=array-bounds)
> +
> config UBSAN_BOUNDS
> bool "Perform array index bounds checking"
> default UBSAN
> depends on !UBSAN_KCOV_BROKEN
> + depends on CC_HAS_UBSAN_ARRAY_BOUNDS || CC_HAS_UBSAN_BOUNDS
> help
> This option enables detection of directly indexed out of bounds
> array accesses, where the array size is known at compile time.
> @@ -47,11 +54,17 @@ config UBSAN_BOUNDS
> to the {str,mem}*cpy() family of functions (that is addressed
> by CONFIG_FORTIFY_SOURCE).
>
> +config CC_ARG_UBSAN_BOUNDS
> + string
> + default "-fsanitize=array-bounds" if CC_HAS_UBSAN_ARRAY_BOUNDS
> + default "-fsanitize=bounds"
> + depends on UBSAN_BOUNDS
> +
> config UBSAN_LOCAL_BOUNDS
> bool "Perform array local bounds checking"
> depends on UBSAN_TRAP
> - depends on CC_IS_CLANG
> depends on !UBSAN_KCOV_BROKEN
> + depends on $(cc-option,-fsanitize=local-bounds)
> help
> This option enables -fsanitize=local-bounds which traps when an
> exception/error is detected. Therefore, it should be enabled only
> @@ -69,6 +82,38 @@ config UBSAN_MISC
> own Kconfig options. Disable this if you only want to have
> individually selected checks.
>
> +config UBSAN_SHIFT
> + def_bool UBSAN_MISC
> + depends on $(cc-option,-fsanitize=shift)
> +
> +config UBSAN_DIV_ZERO
> + def_bool UBSAN_MISC
> + depends on $(cc-option,-fsanitize=integer-divide-by-zero)
> +
> +config UBSAN_UNREACHABLE
> + def_bool UBSAN_MISC
> + depends on $(cc-option,-fsanitize=unreachable)
> +
> +config UBSAN_SIGNED_OVERFLOW
> + def_bool UBSAN_MISC
> + depends on $(cc-option,-fsanitize=signed-integer-overflow)
> +
> +config UBSAN_UNSIGNED_OVERFLOW
> + def_bool UBSAN_MISC
> + depends on $(cc-option,-fsanitize=unsigned-integer-overflow)
> +
> +config UBSAN_OBJECT_SIZE
> + def_bool UBSAN_MISC
> + depends on $(cc-option,-fsanitize=object-size)
> +
> +config UBSAN_BOOL
> + def_bool UBSAN_MISC
> + depends on $(cc-option,-fsanitize=bool)
> +
> +config UBSAN_ENUM
> + def_bool UBSAN_MISC
> + depends on $(cc-option,-fsanitize=enum)
> +
> config UBSAN_SANITIZE_ALL
> bool "Enable instrumentation for the entire kernel"
> depends on ARCH_HAS_UBSAN_SANITIZE_ALL
> @@ -89,6 +134,7 @@ config UBSAN_ALIGNMENT
> bool "Enable checks for pointers alignment"
> default !HAVE_EFFICIENT_UNALIGNED_ACCESS
> depends on !UBSAN_TRAP
> + depends on $(cc-option,-fsanitize=alignment)
> help
> This option enables the check of unaligned memory accesses.
> Enabling this option on architectures that support unaligned
> diff --git a/scripts/Makefile.ubsan b/scripts/Makefile.ubsan
> index 9716dab06bc7..72862da47baf 100644
> --- a/scripts/Makefile.ubsan
> +++ b/scripts/Makefile.ubsan
> @@ -1,37 +1,21 @@
> # SPDX-License-Identifier: GPL-2.0
>
> -export CFLAGS_UBSAN :=
> +# -fsanitize=* options makes GCC less smart than usual and
> +# increases the number of 'maybe-uninitialized' false-positives.
> +ubsan-cflags-$(CONFIG_UBSAN) += $(call cc-disable-warning,
> maybe-uninitialized)
Is this just to force -Wno-maybe-uninitialized even when W=2?
-Wmaybe-uninitialized is already disabled globally after
commit 78a5255ffb6a ("Stop the ad-hoc games with
-Wno-maybe-initialized"). I feel like it might be worth a comment in
case that changes in the future but maybe that is a bit much.
> -ifdef CONFIG_UBSAN_ALIGNMENT
> - CFLAGS_UBSAN += $(call cc-option, -fsanitize=alignment)
> -endif
> +# Enable available and selected UBSAN features.
> +ubsan-cflags-$(CONFIG_UBSAN_ALIGNMENT) += -fsanitize=alignment
> +ubsan-cflags-$(CONFIG_UBSAN_BOUNDS) +=
