Re: [PATCH] media: exynos4-is: Fix runtime PM imbalance in isp_video_open()
> pm_runtime_get_sync() increments the runtime PM usage counter even > when it returns an error code. Thus a pairing decrement is needed on > the error handling path to keep the counter balanced. How do you think about a wording variant like the following? Change description: The PM runtime usage counter is incremented even if a call of the function “pm_runtime_get_sync” failed. Thus decrement it also in an error case so that the reference counting is kept consistent. Would you like to add the tag “Fixes” to the commit message? Can it make sense to combine the software adjustment with the update step “media: exynos4-is: Fix runtime PM imbalance in fimc_is_probe”? https://lore.kernel.org/linux-arm-kernel/20200524025903.17219-1-dinghao@zju.edu.cn/ https://lore.kernel.org/patchwork/patch/1246424/ … +++ b/drivers/media/platform/exynos4-is/fimc-isp-video.c @@ -293,6 +293,7 @@ static int isp_video_open(struct file *file) if (!ret) goto unlock; rel_fh: + pm_runtime_put_noidle(>pdev->dev); v4l2_fh_release(file); unlock: … Is there a need to use a label like “put_pm”? Regards, Markus
[PATCH] staging:r8723bs: remove wrappers around skb_clone()
Wrappers around skb_clone() do not simplify the driver code.
Signed-off-by: Ivan Safonov
---
drivers/staging/rtl8723bs/include/osdep_service.h | 3 ---
drivers/staging/rtl8723bs/os_dep/osdep_service.c | 5 -
drivers/staging/rtl8723bs/os_dep/recv_linux.c | 2 +-
3 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/staging/rtl8723bs/include/osdep_service.h
b/drivers/staging/rtl8723bs/include/osdep_service.h
index 5f681899bbec..be34e279670b 100644
--- a/drivers/staging/rtl8723bs/include/osdep_service.h
+++ b/drivers/staging/rtl8723bs/include/osdep_service.h
@@ -94,7 +94,6 @@ void _kfree(u8 *pbuf, u32 sz);
struct sk_buff *_rtw_skb_alloc(u32 sz);
struct sk_buff *_rtw_skb_copy(const struct sk_buff *skb);
-struct sk_buff *_rtw_skb_clone(struct sk_buff *skb);
int _rtw_netif_rx(_nic_hdl ndev, struct sk_buff *skb);
#define rtw_malloc(sz) _rtw_malloc((sz))
@@ -103,9 +102,7 @@ int _rtw_netif_rx(_nic_hdl ndev, struct sk_buff *skb);
#define rtw_skb_alloc(size) _rtw_skb_alloc((size))
#define rtw_skb_alloc_f(size, mstat_f) _rtw_skb_alloc((size))
#define rtw_skb_copy(skb) _rtw_skb_copy((skb))
-#define rtw_skb_clone(skb) _rtw_skb_clone((skb))
#define rtw_skb_copy_f(skb, mstat_f) _rtw_skb_copy((skb))
-#define rtw_skb_clone_f(skb, mstat_f) _rtw_skb_clone((skb))
#define rtw_netif_rx(ndev, skb) _rtw_netif_rx(ndev, skb)
extern void _rtw_init_queue(struct __queue *pqueue);
diff --git a/drivers/staging/rtl8723bs/os_dep/osdep_service.c
b/drivers/staging/rtl8723bs/os_dep/osdep_service.c
index 4238209ec175..6d443197a0cf 100644
--- a/drivers/staging/rtl8723bs/os_dep/osdep_service.c
+++ b/drivers/staging/rtl8723bs/os_dep/osdep_service.c
@@ -47,11 +47,6 @@ inline struct sk_buff *_rtw_skb_copy(const struct sk_buff
*skb)
return skb_copy(skb, in_interrupt() ? GFP_ATOMIC : GFP_KERNEL);
}
-inline struct sk_buff *_rtw_skb_clone(struct sk_buff *skb)
-{
- return skb_clone(skb, in_interrupt() ? GFP_ATOMIC : GFP_KERNEL);
-}
-
inline int _rtw_netif_rx(_nic_hdl ndev, struct sk_buff *skb)
{
skb->dev = ndev;
diff --git a/drivers/staging/rtl8723bs/os_dep/recv_linux.c
b/drivers/staging/rtl8723bs/os_dep/recv_linux.c
index eb4d1c3008fe..b2a1bbb30df6 100644
--- a/drivers/staging/rtl8723bs/os_dep/recv_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/recv_linux.c
@@ -110,7 +110,7 @@ void rtw_os_recv_indicate_pkt(struct adapter *padapter,
_pkt *pkt, struct rx_pkt
if (memcmp(pattrib->dst, myid(>eeprompriv),
ETH_ALEN)) {
if (bmcast) {
psta = rtw_get_bcmc_stainfo(padapter);
- pskb2 = rtw_skb_clone(pkt);
+ pskb2 = skb_clone(pkt, GFP_ATOMIC);
} else {
psta = rtw_get_stainfo(pstapriv,
pattrib->dst);
}
--
2.26.2
Re: [PATCH v2 3/4] iio: chemical: scd30: add serial interface driver
On Sun, May 31, 2020 at 11:15:18AM +0100, Jonathan Cameron wrote:
> On Sat, 30 May 2020 23:36:29 +0200
> Tomasz Duszynski wrote:
>
> > Add serial interface driver for the SCD30 sensor.
> >
> > Signed-off-by: Tomasz Duszynski
>
> Ah Now I see why you had those extra elements in the iio_priv
> structure.
>
Indeed. That the whole point of having them. I'll add a short
explanation what those elements are for.
> Hmm. serdev_device callbacks using the top level device drvdata
> is a bit annoying. Really feels to me like they should have
> their own priv data for those callbacks given the device
> drvdata gets used for so many other things.
>
> Oh well. Guess this is the best we can do!
>
> Jonathan
>
> > ---
> > MAINTAINERS | 1 +
> > drivers/iio/chemical/Kconfig| 11 ++
> > drivers/iio/chemical/Makefile | 1 +
> > drivers/iio/chemical/scd30_serial.c | 266
> > 4 files changed, 279 insertions(+)
> > create mode 100644 drivers/iio/chemical/scd30_serial.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 13aed3473b7e..5db4b446c8ba 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -15143,6 +15143,7 @@ S: Maintained
> > F: drivers/iio/chemical/scd30.h
> > F: drivers/iio/chemical/scd30_core.c
> > F: drivers/iio/chemical/scd30_i2c.c
> > +F: drivers/iio/chemical/scd30_serial.c
> >
> > SENSIRION SPS30 AIR POLLUTION SENSOR DRIVER
> > M: Tomasz Duszynski
> > diff --git a/drivers/iio/chemical/Kconfig b/drivers/iio/chemical/Kconfig
> > index 970d34888c2e..10bb431bc3ce 100644
> > --- a/drivers/iio/chemical/Kconfig
> > +++ b/drivers/iio/chemical/Kconfig
> > @@ -107,6 +107,17 @@ config SCD30_I2C
> > To compile this driver as a module, choose M here: the module will
> > be called scd30_i2c.
> >
> > +config SCD30_SERIAL
> > + tristate "SCD30 carbon dioxide sensor serial driver"
> > + depends on SCD30_CORE && SERIAL_DEV_BUS
> > + select CRC16
> > + help
> > + Say Y here to build support for the Sensirion SCD30 serial interface
> > + driver.
> > +
> > + To compile this driver as a module, choose M here: the module will
> > + be called scd30_serial.
> > +
> > config SENSIRION_SGP30
> > tristate "Sensirion SGPxx gas sensors"
> > depends on I2C
> > diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile
> > index 0966ca34e34b..fef63dd5bf92 100644
> > --- a/drivers/iio/chemical/Makefile
> > +++ b/drivers/iio/chemical/Makefile
> > @@ -14,6 +14,7 @@ obj-$(CONFIG_IAQCORE) += ams-iaq-core.o
> > obj-$(CONFIG_PMS7003) += pms7003.o
> > obj-$(CONFIG_SCD30_CORE) += scd30_core.o
> > obj-$(CONFIG_SCD30_I2C) += scd30_i2c.o
> > +obj-$(CONFIG_SCD30_SERIAL) += scd30_serial.o
> > obj-$(CONFIG_SENSIRION_SGP30) += sgp30.o
> > obj-$(CONFIG_SPS30) += sps30.o
> > obj-$(CONFIG_VZ89X)+= vz89x.o
> > diff --git a/drivers/iio/chemical/scd30_serial.c
> > b/drivers/iio/chemical/scd30_serial.c
> > new file mode 100644
> > index ..07d7d3110fe0
> > --- /dev/null
> > +++ b/drivers/iio/chemical/scd30_serial.c
> > @@ -0,0 +1,266 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Sensirion SCD30 carbon dioxide sensor serial driver
> > + *
> > + * Copyright (c) 2020 Tomasz Duszynski
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "scd30.h"
> > +
> > +#define SCD30_SERDEV_ADDR 0x61
> > +#define SCD30_SERDEV_WRITE 0x06
> > +#define SCD30_SERDEV_READ 0x03
> > +#define SCD30_SERDEV_MAX_BUF_SIZE 17
> > +#define SCD30_SERDEV_RX_HEADER_SIZE 3
> > +#define SCD30_SERDEV_CRC_SIZE 2
> > +#define SCD30_SERDEV_TIMEOUT msecs_to_jiffies(200)
> > +
> > +struct scd30_serdev_priv {
> > + struct completion meas_ready;
> > + char *buf;
> > + int num_expected;
> > + int num;
> > +};
> > +
> > +static u16 scd30_serdev_cmd_lookup_tbl[] = {
> > + [CMD_START_MEAS] = 0x0036,
> > + [CMD_STOP_MEAS] = 0x0037,
> > + [CMD_MEAS_INTERVAL] = 0x0025,
> > + [CMD_MEAS_READY] = 0x0027,
> > + [CMD_READ_MEAS] = 0x0028,
> > + [CMD_ASC] = 0x003a,
> > + [CMD_FRC] = 0x0039,
> > + [CMD_TEMP_OFFSET] = 0x003b,
> > + [CMD_FW_VERSION] = 0x0020,
> > + [CMD_RESET] = 0x0034,
> > +};
> > +
> > +static u16 scd30_serdev_calc_crc(const char *buf, int size)
> > +{
> > + return crc16(0x, buf, size);
> > +}
> > +
> > +static int scd30_serdev_xfer(struct scd30_state *state, char *txbuf, int
> > txsize,
> > +char *rxbuf, int rxsize)
> > +{
> > + struct serdev_device *serdev = to_serdev_device(state->dev);
> > + struct scd30_serdev_priv *priv = state->priv;
> > + int ret;
> > +
> > + priv->buf = rxbuf;
> > + priv->num_expected = rxsize;
> > + priv->num = 0;
> > +
> > + ret = serdev_device_write(serdev, txbuf, txsize, SCD30_SERDEV_TIMEOUT);
> > + if (ret < txsize)
> > +
Re: [RFC PATCH v4 00/13] riscv: Add vector ISA support
Hi Greentime & Vincent, Thx for the dynamic vlen implementation. I've two suggestions: - Please give out glibc patches mail URL, we need to review them together. - We need to consider that not all processes need vectors. Most system processes do not have vector features, and we should not force save/restore vector for every process. On Tue, May 26, 2020 at 3:03 PM Greentime Hu wrote: > > This patchset is based on Guo Ren's v3 patchset to add dynamic vlen vector > support for all different kinds of vector length in riscv. To make this > happened we defined a new __riscv_v_state in sigcontext to save the vector > related registers. The datap pointer will be allocated dynamically in > kernel space and it will be put right after the __riscv_v_state data > structure to save all the vector registers in signal handler stack for user > space. So does the implementation in ptrace, they will be saved in ubuf > in which we put the __riscv_v_state data structure and datap pointer right > after it for vector registers. This patchset also fixes several bugs for > vector lazy save/restore and vtype not saving issue. It also adds new CSR > support for vector based on the 0.9 vector spec and clean up some unused > macros. > > This patchset is rebased to v5.7-rc4 and it is tested by running several > vector programs simultaneously. It also can get the correct ucontext_t in > signal handler and restore correct context after sigreturn. It is also > tested with ptrace() syscall to use PTRACE_GETREGSET/PTRACE_SETREGSET to > get/set the vector registers. I have tested vlen=128 and vlen=256 cases in > virt machine of qemu-system-riscv32 and qemu-system-riscv64 provided by > Zhiwei Lui. > > Since the vector spec is under developing, there might still need some > changes. For example the vle.v/vse.v instructions will be replaced with > proper instructions. The reason that I don't replace the instruction in > this patchset is because that the Qemu doesn't fully support 0.9 spec yet. > I have no simulator to test. We also like to discuss the default setting of > MINSIGSTKSZ and SIGSTKSZ. They might also need to set a proper number. They > are 2048 and 8096 now. Since the stack in signal will be reserved for > ucontext and the vector registers might be larger and larger someday, these > two macros will need to be defined as a proper value or maybe we should > provide a better mechanism to provide user to get a better default signal > stack size. > > > [1] https://github.com/romanheros/qemu/tree/linux-vector-dev > [2] https://blog.linuxplumbersconf.org/2017/ocw/sessions/4671.html > [3] https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc > > --- > Changelog V4 > - Support dynamic vlen > - Fix bugs: lazy save/resotre, not saving vtype > - Update VS bit offset based on latest vector spec > - Add new vector csr based on latest vector spec > - Code refine and removed unused macros > > Changelog V3 > - Rebase linux-5.6-rc3 and tested with qemu > - Seperate patches with Anup's advice > - Give out a ABI puzzle with unlimited vlen > > Changelog V2 > - Fixup typo "vecotr, fstate_save->vstate_save". > - Fixup wrong saved registers' length in vector.S. > - Seperate unrelated patches from this one. > > Greentime Hu (1): > ptrace: Use regset_size() for dynamic regset size. > > Guo Ren (11): > riscv: Separate patch for cflags and aflags > riscv: Rename __switch_to_aux -> fpu > riscv: Extending cpufeature.c to detect V-extension > riscv: Add new csr defines related to vector extension > riscv: Add vector feature to compile > riscv: Add has_vector/riscv_vsize to save vector features. > riscv: Reset vector register > riscv: Add vector struct and assembler definitions > riscv: Add task switch support for vector > riscv: Add ptrace vector support > riscv: Add sigcontext save/restore for vector > > Vincent Chen (1): > riscv: signal: Report signal frame size to userspace via auxv > > arch/riscv/Kconfig | 9 ++ > arch/riscv/Makefile | 19 ++-- > arch/riscv/include/asm/csr.h | 16 +++- > arch/riscv/include/asm/elf.h | 17 +++- > arch/riscv/include/asm/processor.h | 3 + > arch/riscv/include/asm/switch_to.h | 77 ++- > arch/riscv/include/uapi/asm/auxvec.h | 2 + > arch/riscv/include/uapi/asm/elf.h| 1 + > arch/riscv/include/uapi/asm/hwcap.h | 1 + > arch/riscv/include/uapi/asm/ptrace.h | 13 +++ > arch/riscv/include/uapi/asm/sigcontext.h | 2 + > arch/riscv/kernel/Makefile | 1 + > arch/riscv/kernel/asm-offsets.c | 8 ++ > arch/riscv/kernel/cpufeature.c | 15 ++- > arch/riscv/kernel/entry.S| 2 +- > arch/riscv/kernel/head.S | 49 +- > arch/riscv/kernel/process.c | 40 > arch/riscv/kernel/ptrace.c | 114 +++ > arch/riscv/kernel/setup.c
Re: [PATCH v2 4/4] dt-bindings: iio: scd30: add device binding file
On Sun, May 31, 2020 at 11:19:14AM +0100, Jonathan Cameron wrote:
> On Sat, 30 May 2020 23:36:30 +0200
> Tomasz Duszynski wrote:
>
> > Add SCD30 sensor binding file.
> >
> > Signed-off-by: Tomasz Duszynski
> > ---
> > .../iio/chemical/sensirion,scd30.yaml | 68 +++
> > MAINTAINERS | 1 +
> > 2 files changed, 69 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/iio/chemical/sensirion,scd30.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/iio/chemical/sensirion,scd30.yaml
> > b/Documentation/devicetree/bindings/iio/chemical/sensirion,scd30.yaml
> > new file mode 100644
> > index ..34cc3925d64d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/chemical/sensirion,scd30.yaml
> > @@ -0,0 +1,68 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iio/chemical/sensirion,scd30.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Sensirion SCD30 carbon dioxide sensor
> > +
> > +maintainers:
> > + - Tomasz Duszynski
> > +
> > +description: |
> > + Air quality sensor capable of measuring co2 concentration, temperature
> > + and relative humidity.
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - sensirion,scd30
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + interrupts:
> > +maxItems: 1
> > +
> > + vdd-supply: true
> > +
> > + sensirion,sel-gpios:
> > +description: GPIO connected to the SEL line
> > +maxItems: 1
> > +
> > + sensirion,pwm-gpios:
> > +description: GPIO connected to the PWM line
> > +maxItems: 1
> > +
> > +required:
> > + - compatible
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +# include
> > +i2c {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + scd30@61 {
>
> Nodes should have generic names. Not sure we have an appropriate
> one in the spec, but as main focus of people using this will be
> c02 herpas
>
> c02@61?
>
There are already a few recommended node names ending with '-sensor' on the list
like air-pollution-sensor or temperature-sensor. I'd say co2-sensor would work
here.
> Rob may well have a better suggestion!
>
> > +compatible = "sensirion,scd30";
> > +reg = <0x61>;
> > +vdd-supply = <>;
> > +interrupt-parent = <>;
> > +interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> > + };
> > +};
> > + - |
> > +# include
> > +serial {
> > + scd30 {
> > +compatible = "sensirion,scd30";
> > +vdd-supply = <>;
> > +interrupt-parent = <>;
> > +interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> > + };
> > +};
> > +
> > +...
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 5db4b446c8ba..0ab9cf39e051 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -15140,6 +15140,7 @@ F: include/uapi/linux/phantom.h
> > SENSIRION SCD30 CARBON DIOXIDE SENSOR DRIVER
> > M: Tomasz Duszynski
> > S: Maintained
> > +F: Documentation/devicetree/bindings/iio/chemical/sensirion,scd30.yaml
> > F: drivers/iio/chemical/scd30.h
> > F: drivers/iio/chemical/scd30_core.c
> > F: drivers/iio/chemical/scd30_i2c.c
>
Re: [PATCH v2 3/3] iio: remove iio_triggered_buffer_postenable()/iio_triggered_buffer_predisable()
On Mon, 25 May 2020 14:38:55 +0300
Alexandru Ardelean wrote:
> From: Lars-Peter Clausen
>
> This patch should be squashed into the first one, as the first one is
> breaking the build (intentionally) to make the IIO core files easier to
> review.
>
> Signed-off-by: Lars-Peter Clausen
> Signed-off-by: Alexandru Ardelean
> ---
Friend poke. Version log?
Other than the wistful comment below (which I'm not expecting you to
do anything about btw!) whole series looks good to me.
These are obviously no functional changes (I think) so it's only really patch 2
that
could do with more eyes and acks.
Far as I can tell that case is fine as well because of the protections
on being in the right mode, but more eyes on that would be great.
So assuming that's fine, what commit message do you want me to use for
the fused single patch?
Thanks,
Jonathan
> static const struct iio_trigger_ops atlas_interrupt_trigger_ops = {
> diff --git a/drivers/iio/dummy/iio_simple_dummy_buffer.c
> b/drivers/iio/dummy/iio_simple_dummy_buffer.c
> index 17606eca42b4..8e13c53d4360 100644
> --- a/drivers/iio/dummy/iio_simple_dummy_buffer.c
> +++ b/drivers/iio/dummy/iio_simple_dummy_buffer.c
> @@ -99,20 +99,6 @@ static irqreturn_t iio_simple_dummy_trigger_h(int irq,
> void *p)
> }
>
> static const struct iio_buffer_setup_ops iio_simple_dummy_buffer_setup_ops =
> {
> - /*
> - * iio_triggered_buffer_postenable:
> - * Generic function that simply attaches the pollfunc to the trigger.
> - * Replace this to mess with hardware state before we attach the
> - * trigger.
> - */
> - .postenable = _triggered_buffer_postenable,
> - /*
> - * iio_triggered_buffer_predisable:
> - * Generic function that simple detaches the pollfunc from the trigger.
> - * Replace this to put hardware state back again after the trigger is
> - * detached but before userspace knows we have disabled the ring.
> - */
> - .predisable = _triggered_buffer_predisable,
> };
>
Hmm. Guess we should probably 'invent' a reason to illustrate the bufer
ops in the dummy example. Anyone feeling creative?
[RFC PATCH -rcu lkmm] tools/memory-model/README: Expand dependency of klitmus7
>From 87048d7212f6cb16b0a2b85fa6d2f34c28b078c0 Mon Sep 17 00:00:00 2001
From: Akira Yokosawa
Date: Sun, 31 May 2020 20:04:32 +0900
Subject: [PATCH RFC] tools/memory-model/README: Expand dependency of klitmus7
klitmus7 is independent of the memory model but depends on the
build-target kernel release.
It occasionally lost compatibility due to kernel API changes [1, 2, 3].
It was remedied in a backwards-compatible manner respectively [4, 5, 6].
Reflect this fact in README.
[1]: b899a850431e ("compiler.h: Remove ACCESS_ONCE()")
[2]: 0bb95f80a38f ("Makefile: Globally enable VLA warning")
[3]: d56c0d45f0e2 ("proc: decouple proc from VFS with "struct proc_ops"")
[4]: https://github.com/herd/herdtools7/commit/e87d7f9287d1
("klitmus: Use WRITE_ONCE and READ_ONCE in place of deprecated
ACCESS_ONCE")
[5]: https://github.com/herd/herdtools7/commit/a0cbb10d02be
("klitmus: Avoid variable length array")
[6]: https://github.com/herd/herdtools7/commit/46b9412d3a58
("klitmus: Linux kernel v5.6.x compat")
NOTE: [5] was ahead of herdtools7 7.53, which did not make an
official release. Code generated by klitmus7 without [5] can still be
built targeting Linux 4.20--5.5 if you don't care VLA warnings.
Signed-off-by: Akira Yokosawa
---
Hi all,
Recent struggle of Andrii with the use of klitmus7 on an up-to-date
Linux system prompted me to add some explanation of klitmus7's dependency
in README.
As herdtools7 7.56 is still under development, I called out just HEAD
in the compatibility table. Once 7.56 is released, the table can be
updated.
I'm not sure if this is the right place to carry such info.
Anyway, I'd be glad if this patch can trigger a meaningful update of
README.
Thanks, Akira
--
tools/memory-model/README | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/tools/memory-model/README b/tools/memory-model/README
index b9c562e92981..90af203c3cf1 100644
--- a/tools/memory-model/README
+++ b/tools/memory-model/README
@@ -28,8 +28,34 @@ downloaded separately:
See "herdtools7/INSTALL.md" for installation instructions.
Note that although these tools usually provide backwards compatibility,
-this is not absolutely guaranteed. Therefore, if a later version does
-not work, please try using the exact version called out above.
+this is not absolutely guaranteed.
+
+For example, a future version of herd7 might not work with the model
+in this release. A compatible model will likely be made available in
+a later release of Linux kernel.
+
+If you absolutely need to run the model in this particular release,
+please try using the exact version called out above.
+
+klitmus7 is independent of the model provided here. It has its own
+dependency on a target kernel release where converted code is built
+and executed. Any change in kernel APIs essential to klitmus7 will
+necessitate an upgrade of klitmus7.
+
+If you find any compatibility issues in klitmus7, please inform the
+memory model maintainers.
+
+klitmus7 Compatibility Table
+
+
+ ==
+ target Linux herdtools7
+ --
+-- 4.18 7.48 --
+ 4.15 -- 4.19 7.49 --
+ 4.20 -- 5.5 7.54 --
+ 5.6 -- HEAD
+ ==
==
--
2.17.1
Re: [PATCH 1/2] arm64: dts: Add a device tree for the Librem5 phone
Hi,
On Fri, May 29, 2020 at 06:28:50PM +0200, Pavel Machek wrote:
> Hi!
>
> > From: "Angus Ainslie (Purism)"
> >
> > Add a devicetree description for the Librem 5 phone. The early batches
> > that have been sold are supported as well as the mass-produced device
> > available later this year, see https://puri.sm/products/librem-5/
> >
> > This boots to a working console with working WWAN modem, wifi usdhc,
> > IMU sensor device, proximity sensor, haptic motor, gpio keys, GNSS and LEDs.
> >
> > Signed-off-by: Martin Kepplinger
> > Signed-off-by: Angus Ainslie (Purism)
> > Signed-off-by: Guido Günther
>
>
> > + blue {
> > + label = "phone:blue:front";
> > + label = "phone:green:front";
> > + label = "phone:red:front";
>
> Droid 4 uses "status-led:{red,green,blue}". Could this use same
> naming?
Looking at leds-class.rst we don't have a useful devicename so
should that just be omitted and s.th. like
label = "blue:status";
label = "green:status";
label = "red:status";
be used instead. If we want to map to current usage
label = "blue:status";
label = "green:boot";
label = "red:charging";
would be even closer but since that is bound to change just going with
"status" would make sense.
Cheers,
-- Guido
>
> > + label = "lm3560:flash";
> > + label = "lm3560:torch";
>
> This is one LED, right? I'm pretty sure we don't want lm3560 in the
> name... "main-camera:flash" would be better. Even better would be
> something that's already in use.
>
> > + label = "white:backlight_cluster";
>
> Make this ":backlight", please. Again, we want something that's
> already used.
>
> Best regards,
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [RFC PATCH v4 10/13] riscv: Add task switch support for vector
Hi Greentime,
On Tue, May 26, 2020 at 3:03 PM Greentime Hu wrote:
>
> From: Guo Ren
>
> This patch adds task switch support for vector. It supports lazy
> save and restore mechanism. It also supports all lengths of vlen.
>
> [greentime...@sifive.com: add support for dynamic vlen, fix
> __vstate_clean() and lazy save/restore bug]
> [nick.kni...@sifive.com: Rewrite vector.S to support dynamic vlen, xlen and
> code refine]
> Signed-off-by: Nick Knight
> Signed-off-by: Greentime Hu
> Signed-off-by: Guo Ren
> ---
> arch/riscv/include/asm/switch_to.h | 71 +
> arch/riscv/kernel/Makefile | 1 +
> arch/riscv/kernel/process.c| 40 ++
> arch/riscv/kernel/vector.S | 84 ++
> 4 files changed, 196 insertions(+)
> create mode 100644 arch/riscv/kernel/vector.S
>
> diff --git a/arch/riscv/include/asm/switch_to.h
> b/arch/riscv/include/asm/switch_to.h
> index b9234e7178d0..a047dd75e09d 100644
> --- a/arch/riscv/include/asm/switch_to.h
> +++ b/arch/riscv/include/asm/switch_to.h
> @@ -6,10 +6,12 @@
> #ifndef _ASM_RISCV_SWITCH_TO_H
> #define _ASM_RISCV_SWITCH_TO_H
>
> +#include
> #include
> #include
> #include
> #include
> +#include
>
> #ifdef CONFIG_FPU
> extern void __fstate_save(struct task_struct *save_to);
> @@ -63,6 +65,73 @@ extern bool has_fpu;
> #define __switch_to_fpu(__prev, __next) do { } while (0)
> #endif
>
> +#ifdef CONFIG_VECTOR
> +extern bool has_vector;
> +extern unsigned long riscv_vsize;
> +extern void __vstate_save(struct __riscv_v_state *save_to, void *datap);
> +extern void __vstate_restore(struct __riscv_v_state *restore_from, void
> *datap);
> +
> +static inline void __vstate_clean(struct pt_regs *regs)
> +{
> + regs->status = (regs->status & ~(SR_VS)) | SR_VS_CLEAN;
> +}
> +
> +static inline void vstate_off(struct task_struct *task,
> + struct pt_regs *regs)
> +{
> + regs->status = (regs->status & ~SR_VS) | SR_VS_OFF;
> +}
> +
> +static inline void vstate_save(struct task_struct *task,
> + struct pt_regs *regs)
> +{
> + if ((regs->status & SR_VS) == SR_VS_DIRTY) {
> + struct __riscv_v_state *vstate = &(task->thread.vstate);
> +
> + /* Allocate space for vector registers. */
> + if (!vstate->datap) {
> + vstate->datap = kzalloc(riscv_vsize, GFP_KERNEL);
> + vstate->size = riscv_vsize;
> + }
> + __vstate_save(vstate, vstate->datap);
> + __vstate_clean(regs);
> + }
> +}
> +
> +static inline void vstate_restore(struct task_struct *task,
> + struct pt_regs *regs)
> +{
> + if ((regs->status & SR_VS) != SR_VS_OFF) {
> + struct __riscv_v_state *vstate = &(task->thread.vstate);
> +
> + /* Allocate space for vector registers. */
> + if (!vstate->datap) {
> + vstate->datap = kzalloc(riscv_vsize, GFP_KERNEL);
> + vstate->size = riscv_vsize;
> + }
> + __vstate_restore(vstate, vstate->datap);
> + __vstate_clean(regs);
> + }
> +}
> +
> +static inline void __switch_to_vector(struct task_struct *prev,
> + struct task_struct *next)
> +{
> + struct pt_regs *regs;
> +
> + regs = task_pt_regs(prev);
> + if (unlikely(regs->status & SR_SD))
> + vstate_save(prev, regs);
> + vstate_restore(next, task_pt_regs(next));
> +}
> +
> +#else
> +#define has_vector false
> +#define vstate_save(task, regs) do { } while (0)
> +#define vstate_restore(task, regs) do { } while (0)
> +#define __switch_to_vector(__prev, __next) do { } while (0)
> +#endif
> +
> extern struct task_struct *__switch_to(struct task_struct *,
>struct task_struct *);
>
> @@ -72,6 +141,8 @@ do { \
> struct task_struct *__next = (next);\
> if (has_fpu)\
> __switch_to_fpu(__prev, __next);\
> + if (has_vector) \
> + __switch_to_vector(__prev, __next); \
> ((last) = __switch_to(__prev, __next)); \
> } while (0)
>
> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> index 86c83081044f..dee489a1a526 100644
> --- a/arch/riscv/kernel/Makefile
> +++ b/arch/riscv/kernel/Makefile
> @@ -33,6 +33,7 @@ obj-$(CONFIG_MMU) += vdso.o vdso/
>
> obj-$(CONFIG_RISCV_M_MODE) += clint.o traps_misaligned.o
> obj-$(CONFIG_FPU) += fpu.o
> +obj-$(CONFIG_VECTOR) += vector.o
> obj-$(CONFIG_SMP) += smpboot.o
> obj-$(CONFIG_SMP) += smp.o
> obj-$(CONFIG_SMP) += cpu_ops.o
> diff --git
Re: [RFC PATCH v4 12/13] riscv: Add sigcontext save/restore for vector
Hi Greentime,
On Tue, May 26, 2020 at 3:03 PM Greentime Hu wrote:
>
> From: Guo Ren
>
> This patch adds sigcontext save/restore for vector. The vector registers
> will be saved in datap pointer. The datap pointer will be allocaed
> dynamically when the task needs in kernel space. The datap pointer will
> be set right after the __riscv_v_state data structure to save all the
> vector registers in the signal handler stack.
>
> [greentime...@sifive.com: add support for dynamic vlen]
> Signed-off-by: Greentime Hu
> Signed-off-by: Guo Ren
> ---
> arch/riscv/include/uapi/asm/sigcontext.h | 2 +
> arch/riscv/kernel/signal.c | 92 +++-
> 2 files changed, 91 insertions(+), 3 deletions(-)
>
> diff --git a/arch/riscv/include/uapi/asm/sigcontext.h
> b/arch/riscv/include/uapi/asm/sigcontext.h
> index 84f2dfcfdbce..4217f3f1c8ba 100644
> --- a/arch/riscv/include/uapi/asm/sigcontext.h
> +++ b/arch/riscv/include/uapi/asm/sigcontext.h
> @@ -8,6 +8,7 @@
>
> #include
>
> +#define RVV_MAGIC 0x53465457
> /*
> * Signal context structure
> *
> @@ -17,6 +18,7 @@
> struct sigcontext {
> struct user_regs_struct sc_regs;
> union __riscv_fp_state sc_fpregs;
> + struct __riscv_v_state sc_vregs;
> };
>
> #endif /* _UAPI_ASM_RISCV_SIGCONTEXT_H */
> diff --git a/arch/riscv/kernel/signal.c b/arch/riscv/kernel/signal.c
> index 17ba190e84a5..9ada6f74bb95 100644
> --- a/arch/riscv/kernel/signal.c
> +++ b/arch/riscv/kernel/signal.c
> @@ -83,6 +83,80 @@ static long save_fp_state(struct pt_regs *regs,
> #define restore_fp_state(task, regs) (0)
> #endif
>
> +#ifdef CONFIG_VECTOR
> +static long restore_v_state(struct pt_regs *regs, struct sigcontext *sc)
> +{
> + long err;
> + struct __riscv_v_state __user *state = >sc_vregs;
> + void *datap;
> + __u32 magic;
> +
> + /* Get magic number and check it. */
> + err = __get_user(magic, >magic);
> + if (unlikely(err))
> + return err;
> +
> + if (magic != RVV_MAGIC)
> + return -EINVAL;
> +
> + /* Copy everything of __riscv_v_state except datap. */
> + err = __copy_from_user(>thread.vstate, state,
> + RISCV_V_STATE_DATAP);
> + if (unlikely(err))
> + return err;
> +
> + /* Copy the pointer datap itself. */
> + err = __get_user(datap, >datap);
> + if (unlikely(err))
> + return err;
> +
> +
> + /* Copy the whole vector content from user space datap. */
> + err = __copy_from_user(current->thread.vstate.datap, datap,
> + current->thread.vstate.size);
> + if (unlikely(err))
> + return err;
> +
> + vstate_restore(current, regs);
> +
> + return err;
> +}
> +
> +static long save_v_state(struct pt_regs *regs, struct sigcontext *sc)
> +{
> + long err;
> + struct __riscv_v_state __user *state = >sc_vregs;
> + /* Set the datap right after the sigcntext structure. */
> + void *datap = sc + 1;
> +
> + vstate_save(current, regs);
> + /* Copy everything of vstate but datap. */
> + err = __copy_to_user(state, >thread.vstate,
> +RISCV_V_STATE_DATAP);
> + if (unlikely(err))
> + return err;
> +
> + /* Copy the magic number. */
> + err = __put_user(RVV_MAGIC, >magic);
> + if (unlikely(err))
> + return err;
> +
> + /* Copy the pointer datap itself. */
> + err = __put_user(datap, >datap);
> + if (unlikely(err))
> + return err;
> +
> + /* Copy the whole vector content to user space datap. */
> + err = __copy_to_user(datap, current->thread.vstate.datap,
> +current->thread.vstate.size);
> +
> + return err;
> +}
> +#else
> +#define save_v_state(task, regs) (0)
> +#define restore_v_state(task, regs) (0)
> +#endif
> +
> static long restore_sigcontext(struct pt_regs *regs,
> struct sigcontext __user *sc)
> {
> @@ -92,6 +166,9 @@ static long restore_sigcontext(struct pt_regs *regs,
> /* Restore the floating-point state. */
> if (has_fpu)
> err |= restore_fp_state(regs, >sc_fpregs);
> + /* Restore the vector state. */
> + if (has_vector)
> + err |= restore_v_state(regs, sc);
> return err;
> }
>
> @@ -101,13 +178,16 @@ SYSCALL_DEFINE0(rt_sigreturn)
> struct rt_sigframe __user *frame;
> struct task_struct *task;
> sigset_t set;
> + size_t frame_size = sizeof(*frame);
>
> /* Always make any pending restarted system calls return -EINTR */
> current->restart_block.fn = do_no_restart_syscall;
>
> frame = (struct rt_sigframe __user *)regs->sp;
>
> - if (!access_ok(frame, sizeof(*frame)))
> + if (has_vector)
> + frame_size += current->thread.vstate.size;
Shall we force all
Re: [RFC PATCH 08/14] iio: core: use new common ioctl() mechanism
On Mon, 25 May 2020 07:27:43 +
"Ardelean, Alexandru" wrote:
> On Sun, 2020-05-24 at 17:47 +0100, Jonathan Cameron wrote:
> > [External]
> >
> > On Fri, 8 May 2020 16:53:42 +0300
> > Alexandru Ardelean wrote:
> >
> > > This change makes use of the new centralized ioctl() mechanism. The event
> > > interface registers it's ioctl() handler to IIO device.
> > > Both the buffer & event interface call 'iio_device_ioctl()', which should
> > > take care of all of indio_dev's ioctl() calls.
> > >
> > > Later, we may add per-buffer ioctl() calls, and since each buffer will get
> > > it's own chardev, the buffer ioctl() handler will need a bit of tweaking
> > > for the first/legacy buffer (i.e. indio_dev->buffer).
> >
> > Do we have an ioctls that aren't safe if we just use them on 'any'
> > buffer? I don't think we do yet, though I guess we may have in the future.
> >
>
> This was done in the idea that we may want to keep the /dev/iio:deviceX for
> backwards compatibility.
> But, it's undetermined yet how this will look.
> I am currently working on more rework stuff [as you've seen].
> I'd try to do some of the rework now, before adding more stuff [like
> iio_dev_opaque].
> To avoid adding this work, then having to rework it.
Agreed. You are being so productive at the moment you may end up blocking
yourself. Best perhaps to slow down and clear some of the backlog.
Jonathan
>
> >
> > > Also, those per-buffer ioctl() calls will not be registered with this
> > > mechanism.
> > >
> > > Signed-off-by: Alexandru Ardelean
> > > ---
> > > drivers/iio/iio_core.h| 3 ---
> > > drivers/iio/industrialio-buffer.c | 2 +-
> > > drivers/iio/industrialio-event.c | 14 --
> > > 3 files changed, 9 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/iio/iio_core.h b/drivers/iio/iio_core.h
> > > index 34c3e19229d8..f68de4af2738 100644
> > > --- a/drivers/iio/iio_core.h
> > > +++ b/drivers/iio/iio_core.h
> > > @@ -54,9 +54,6 @@ ssize_t iio_format_value(char *buf, unsigned int type,
> > > int
> > > size, int *vals);
> > > #ifdef CONFIG_IIO_BUFFER
> > > struct poll_table_struct;
> > >
> > > -long iio_device_event_ioctl(struct iio_dev *indio_dev, struct file *filp,
> > > - unsigned int cmd, unsigned long arg);
> > > -
> > > void iio_device_buffer_attach_chrdev(struct iio_dev *indio_dev);
> > >
> > > int iio_buffer_alloc_sysfs_and_mask(struct iio_dev *indio_dev);
> > > diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-
> > > buffer.c
> > > index 1400688f5e42..e7a847e7b103 100644
> > > --- a/drivers/iio/industrialio-buffer.c
> > > +++ b/drivers/iio/industrialio-buffer.c
> > > @@ -1199,7 +1199,7 @@ static long iio_buffer_ioctl(struct file *filep,
> > > unsigned int cmd,
> > > if (!buffer || !buffer->access)
> > > return -ENODEV;
> > >
> > > - return iio_device_event_ioctl(buffer->indio_dev, filep, cmd, arg);
> > > + return iio_device_ioctl(buffer->indio_dev, filep, cmd, arg);
> > > }
> > >
> > > static ssize_t iio_buffer_store_enable(struct device *dev,
> > > diff --git a/drivers/iio/industrialio-event.c b/drivers/iio/industrialio-
> > > event.c
> > > index 0674b2117c98..1961c1d19370 100644
> > > --- a/drivers/iio/industrialio-event.c
> > > +++ b/drivers/iio/industrialio-event.c
> > > @@ -32,6 +32,7 @@
> > > * @read_lock: lock to protect kfifo read operations
> > > * @chrdev: associated chardev for this event
> > > * @indio_dev: IIO device to which this event interface belongs
> > > to
> > > + * @ioctl_handler: handler for event ioctl() calls
> > > */
> > > struct iio_event_interface {
> > > wait_queue_head_t wait;
> > > @@ -44,6 +45,7 @@ struct iio_event_interface {
> > >
> > > struct cdev chrdev;
> > > struct iio_dev *indio_dev;
> > > + struct iio_ioctl_handlerioctl_handler;
> > > };
> > >
> > > bool iio_event_enabled(const struct iio_event_interface *ev_int)
> > > @@ -261,15 +263,12 @@ static int iio_chrdev_release(struct inode *inode,
> > > struct file *filp)
> > > return 0;
> > > }
> > >
> > > -long iio_device_event_ioctl(struct iio_dev *indio_dev, struct file *filp,
> > > +static long iio_event_ioctl(struct iio_dev *indio_dev, struct file *filp,
> > > unsigned int cmd, unsigned long arg)
> > > {
> > > int __user *ip = (int __user *)arg;
> > > int fd;
> > >
> > > - if (!indio_dev->info)
> > > - return -ENODEV;
> > > -
> > > if (cmd == IIO_GET_EVENT_FD_IOCTL) {
> > > fd = iio_event_getfd(indio_dev);
> > > if (fd < 0)
> > > @@ -278,7 +277,7 @@ long iio_device_event_ioctl(struct iio_dev *indio_dev,
> > > struct file *filp,
> > > return -EFAULT;
> > > return 0;
> > > }
> > > - return -EINVAL;
> > > + return IIO_IOCTL_UNHANDLED;
> > > }
> > >
> > > static long iio_event_ioctl_wrapper(struct file *filp, unsigned
Re: [RFC PATCH 09/14] iio: buffer: split buffer sysfs creation to take buffer as primary arg
On Mon, 25 May 2020 07:28:18 +
"Ardelean, Alexandru" wrote:
> On Sun, 2020-05-24 at 17:49 +0100, Jonathan Cameron wrote:
> > [External]
> >
> > On Fri, 8 May 2020 16:53:43 +0300
> > Alexandru Ardelean wrote:
> >
> > > Currently the iio_buffer_{alloc,free}_sysfs_and_mask() take 'indio_dev' as
> > > primary argument. This change converts to take an IIO buffer as a primary
> > > argument.
> > >
> > > That will allow the functions to get called for multiple buffers.
> > >
> > > Signed-off-by: Alexandru Ardelean
> >
> > Looks good to me. We'll need this whatever the interface ends up being as
> > need the separate control infrastructure.
>
> I was wanting to split this into it's own patch at some point and send it now.
> I'll probably do it.
Great.
>
> >
> > Jonathan
> >
> > > ---
> > > drivers/iio/industrialio-buffer.c | 46 ---
> > > 1 file changed, 30 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-
> > > buffer.c
> > > index e7a847e7b103..6b1b5d5387bd 100644
> > > --- a/drivers/iio/industrialio-buffer.c
> > > +++ b/drivers/iio/industrialio-buffer.c
> > > @@ -1312,26 +1312,14 @@ static struct attribute *iio_buffer_attrs[] = {
> > > _attr_data_available.attr,
> > > };
> > >
> > > -int iio_buffer_alloc_sysfs_and_mask(struct iio_dev *indio_dev)
> > > +static int __iio_buffer_alloc_sysfs_and_mask(struct iio_buffer *buffer)
> > > {
> > > + struct iio_dev *indio_dev = buffer->indio_dev;
> > > struct iio_dev_attr *p;
> > > struct attribute **attr;
> > > - struct iio_buffer *buffer = indio_dev->buffer;
> > > int ret, i, attrn, attrcount, attrcount_orig = 0;
> > > const struct iio_chan_spec *channels;
> > >
> > > - channels = indio_dev->channels;
> > > - if (channels) {
> > > - int ml = indio_dev->masklength;
> > > -
> > > - for (i = 0; i < indio_dev->num_channels; i++)
> > > - ml = max(ml, channels[i].scan_index + 1);
> > > - indio_dev->masklength = ml;
> > > - }
> > > -
> > > - if (!buffer)
> > > - return 0;
> > > -
> > > attrcount = 0;
> > > if (buffer->attrs) {
> > > while (buffer->attrs[attrcount] != NULL)
> > > @@ -1411,19 +1399,45 @@ int iio_buffer_alloc_sysfs_and_mask(struct iio_dev
> > > *indio_dev)
> > > return ret;
> > > }
> > >
> > > -void iio_buffer_free_sysfs_and_mask(struct iio_dev *indio_dev)
> > > +int iio_buffer_alloc_sysfs_and_mask(struct iio_dev *indio_dev)
> > > {
> > > struct iio_buffer *buffer = indio_dev->buffer;
> > > + const struct iio_chan_spec *channels;
> > > + int i;
> > > +
> > > + channels = indio_dev->channels;
> > > + if (channels) {
> > > + int ml = indio_dev->masklength;
> > > +
> > > + for (i = 0; i < indio_dev->num_channels; i++)
> > > + ml = max(ml, channels[i].scan_index + 1);
> > > + indio_dev->masklength = ml;
> > > + }
> > >
> > > if (!buffer)
> > > - return;
> > > + return 0;
> > > +
> > > + return __iio_buffer_alloc_sysfs_and_mask(buffer);
> > > +}
> > >
> > > +static void __iio_buffer_free_sysfs_and_mask(struct iio_buffer *buffer)
> > > +{
> > > iio_buffer_free_scanmask(buffer);
> > > kfree(buffer->buffer_group.attrs);
> > > kfree(buffer->scan_el_group.attrs);
> > > iio_free_chan_devattr_list(>scan_el_dev_attr_list);
> > > }
> > >
> > > +void iio_buffer_free_sysfs_and_mask(struct iio_dev *indio_dev)
> > > +{
> > > + struct iio_buffer *buffer = indio_dev->buffer;
> > > +
> > > + if (!buffer)
> > > + return;
> > > +
> > > + __iio_buffer_free_sysfs_and_mask(buffer);
> > > +}
> > > +
> > > static const struct file_operations iio_buffer_fileops = {
> > > .read = iio_buffer_read_outer,
> > > .release = iio_buffer_chrdev_release,
Re: [PATCH v2 0/4] Introduce the Counter character device interface
On Sun, 24 May 2020 13:54:39 -0400 William Breathitt Gray wrote: > On Sun, May 24, 2020 at 05:25:42PM +0100, Jonathan Cameron wrote: > > > > ... > > > > > The following are some questions I have about this patchset: > > > > > > 1. Should the data format of the character device be configured via a > > >sysfs attribute? > > > > > >In this patchset, the first 196095 bytes of the character device are > > >dedicated as a selection area to choose which Counter components or > > >extensions should be exposed; the subsequent bytes are the actual > > >data for the Counter components and extensions that were selected. > > > > That sounds like the worst of all possible worlds. Reality is you need > > to do some magic library so at that point you might as well have ioctl > > options to configure it. I wonder if you can keep the data flow > > to be a simple 'read' from the chardev but move the control away from > > that. Either control via some chrdevs but keep them to the 'set / get' > > if this element is going to turn up in the read or not. You rapidly > > run into problems though, such as now to see how large a given element > > is going to be etc. Plus ioctls are rather messier to extend than > > simply adding a new sysfs file. Various subsystems do complex > > 'descriptor' type approaches to get around this, or you could do > > self describing records rather than raw data - like an input > > ev_dev event. > > Yes I agree, I don't think combining nondata with data is good design -- > it's better if users are able to simply perform read/write on the > character device without having to keep track of valid offsets and > controls. > > After giving this some more thought, I believe human-readable sysfs > attributes are the way to go to support configuration of the character > device. I am thinking of a system like this: > > * Users configure the counter character device via a sysfs attribute > such as /sys/bus/counter/devices/counterX/chrdev_format or similar. > > * Users may write to this sysfs attribute to select the components they > want to interface -- the layout can be determined as well from the > order. For example: > > # echo "C0 C3 C2" > /sys/bus/counter/devices/counter0/chrdev_format I guess that 'just' meets the sysfs requirement of one file => one thing. > > This would select Counts 0, 3, and 2 (in that order) to be available > in the /dev/counter0 node as a contiguous memory region. > > You can select extensions in a similar fashion: > > # echo "C4E2 S1E0" > /sys/bus/counter/devices/counter0/chrdev_format > > This would select extension 2 from Count 4, and extension 0 from > Signal 1. I'm not totally clear why we'd want to have a chrdev access to extensions. To be honest I'm not totally sure what an extension is today as it's been a week ;) Perhaps an example? I see timestamp below. What is that attached to? If we gave multiple counters, do they each have a timestamp? > > * Users may read from this chrdev_format sysfs attribute in order to see > the currently configured format of the character device. > > * Users may perform read/write operations on the /dev/counterX node > directly; the layout of the data is what they user has configured via > the chrdev_format sysfs attribute. For example: > > # echo "C0 C1 S0 S1" > /sys/bus/counter/devices/counter0/chrdev_format > > Yields the following /dev/counter0 memory layout: > > +-+--+--+--+ > | Byte 0 - Byte 7 | Byte 8 - Byte 15 | Byte 16 | Byte 17 | > +-+--+--+--+ > | Count 0 | Count 1 | Signal 0 | Signal 2 | > +-+--+--+--+ > > * Users may perform select/poll operations on the /dev/counterX node. > Users can be notified if data is available or events have occurred. One thing to think about early if watermarks. We bolted them on late in IIO and maybe we could have done it better from the start. I'd almost guarantee someone will want one fairly soon - particularly as it's more than possible you'll have a counter device with a hardware fifo. I have some vague recollection that ti-ecap stuff could be presented as a short fifo for starters. > > The benefit of this design is that the format is robust so users can > choose the components they want to interface and in the layout they > want. For example, if I am writing a userspace application to control a > dual-axis positioning table, I can select the two counts I care about > for the position axes. This allows me to read just those two values > directly from /dev/counterX with a simple read() call, without having to > fumble around seeking to an offset and parsing the layout. I wonder if I'm over thinking things for counters, but you may run into the complexity of different counters having different sampling frequencies. Here you are suggesting
Re: [PATCH] usb: common: usb-conn-gpio: Register optional charger
Hi,
Any feedback on this patch?
Cheers,
-Paul
Le lun. 13 avril 2020 à 14:25, Paul Cercueil a
écrit :
Register a power supply charger, if the Kconfig option
USB_CONN_GPIO_CHARGER is set, whose online state depends on whether
the USB role is set to device or not.
This is useful when the USB role is the only way to know if the device
is charging from USB. The API is the standard power supply charger
API,
you get a /sys/class/power_supply/xxx/online node which tells you the
state of the charger.
The sole purpose of this is to give userspace applications a way to
know whether or not the charger is plugged.
Signed-off-by: Paul Cercueil
---
Notes:
v2: - improve commit message... explain why we want a charger
- compile charger code only if CONFIG_USB_CONN_GPIO_CHARGER
is set
drivers/usb/common/Kconfig | 11 +++
drivers/usb/common/usb-conn-gpio.c | 47
++
2 files changed, 58 insertions(+)
diff --git a/drivers/usb/common/Kconfig b/drivers/usb/common/Kconfig
index d611477aae41..5405ae96c68f 100644
--- a/drivers/usb/common/Kconfig
+++ b/drivers/usb/common/Kconfig
@@ -49,3 +49,14 @@ config USB_CONN_GPIO
To compile the driver as a module, choose M here: the module will
be called usb-conn-gpio.ko
+
+if USB_CONN_GPIO
+
+config USB_CONN_GPIO_CHARGER
+ bool "USB charger support"
+ select POWER_SUPPLY
+ help
+ Register a charger with the power supply subsystem. This will
allow
+ userspace to know whether or not the device is charging from USB.
+
+endif
diff --git a/drivers/usb/common/usb-conn-gpio.c
b/drivers/usb/common/usb-conn-gpio.c
index ed204cbb63ea..129d48db280b 100644
--- a/drivers/usb/common/usb-conn-gpio.c
+++ b/drivers/usb/common/usb-conn-gpio.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -38,6 +39,9 @@ struct usb_conn_info {
struct gpio_desc *vbus_gpiod;
int id_irq;
int vbus_irq;
+
+ struct power_supply_desc desc;
+ struct power_supply *charger;
};
/**
@@ -98,6 +102,8 @@ static void usb_conn_detect_cable(struct
work_struct *work)
ret = regulator_enable(info->vbus);
if (ret)
dev_err(info->dev, "enable vbus regulator failed\n");
+ } else if (IS_ENABLED(CONFIG_USB_CONN_GPIO_CHARGER)) {
+ power_supply_changed(info->charger);
}
info->last_role = role;
@@ -121,10 +127,35 @@ static irqreturn_t usb_conn_isr(int irq, void
*dev_id)
return IRQ_HANDLED;
}
+static enum power_supply_property usb_charger_properties[] = {
+ POWER_SUPPLY_PROP_ONLINE,
+};
+
+static int usb_charger_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct usb_conn_info *info = power_supply_get_drvdata(psy);
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_ONLINE:
+ val->intval = info->last_role == USB_ROLE_DEVICE;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int usb_conn_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
+ struct power_supply_desc *desc;
struct usb_conn_info *info;
+ struct power_supply_config cfg = {
+ .of_node = dev->of_node,
+ };
int ret = 0;
info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL);
@@ -203,6 +234,22 @@ static int usb_conn_probe(struct platform_device
*pdev)
}
}
+ if (IS_ENABLED(CONFIG_USB_CONN_GPIO_CHARGER)) {
+ desc = >desc;
+ desc->name = "usb-charger";
+ desc->properties = usb_charger_properties;
+ desc->num_properties = ARRAY_SIZE(usb_charger_properties);
+ desc->get_property = usb_charger_get_property;
+ desc->type = POWER_SUPPLY_TYPE_USB;
+ cfg.drv_data = info;
+
+ info->charger = devm_power_supply_register(dev, desc, );
+ if (IS_ERR(info->charger)) {
+ dev_err(dev, "Unable to register charger\n");
+ return PTR_ERR(info->charger);
+ }
+ }
+
platform_set_drvdata(pdev, info);
/* Perform initial detection */
--
2.25.1
Re: [PATCH v4 3/4] scsi: ufs: cleanup ufs initialization path
On Sat, 2020-05-30 at 06:37 +, Avri Altman wrote:
> > + /* Get the length of descriptor */
> > + ufshcd_map_desc_id_to_length(hba, desc_id, _len);
> > + if (!buff_len) {
> > + dev_err(hba->dev, "%s: Failed to get desc length",
> > __func__);
> > + return -EINVAL;
> > }
> >
> > /* Check whether we need temp memory */
>
> The first time we are reading the descriptor, we no longer can rely
> on its true size.
> So for this check, buff_len is 256 and kmalloc will always happen.
> Do you think that this check is still relevant?
>
> /* Check whether we need temp memory */
> if (param_offset != 0 || param_size < buff_len) {
> desc_buf = kmalloc(buff_len, GFP_KERNEL);
> if (!desc_buf)
> return -ENOMEM;
> } else {
> desc_buf = param_read_buf;
> is_kmalloc = false;
> }
Avri
I found this checkup is still needed since LU descriptor read will
multiple enter this function. so I didn't delete it in the new version
patch.
thanks,
Bean
[PATCH v4 4/5] scsi: ufs: cleanup ufs initialization path
From: Bean Huo
At UFS initialization stage, to get the length of the descriptor,
ufshcd_read_desc_length() being called 6 times. Instead, we will
capture the descriptor size the first time we'll read it.
Delete unnecessary redundant code, remove ufshcd_read_desc_length(),
ufshcd_init_desc_sizes(), and boost UFS initialization.
Signed-off-by: Bean Huo
Reviewed-by: Bart van Assche
Reviewed-by: Stanley Chu
---
drivers/scsi/ufs/ufs.h | 10 ---
drivers/scsi/ufs/ufs_bsg.c | 5 +-
drivers/scsi/ufs/ufshcd.c | 168 -
drivers/scsi/ufs/ufshcd.h | 16 +---
4 files changed, 38 insertions(+), 161 deletions(-)
diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index fadba3a3bbcd..6548ef102eb9 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -200,16 +200,6 @@ enum desc_header_offset {
QUERY_DESC_DESC_TYPE_OFFSET = 0x01,
};
-enum ufs_desc_def_size {
- QUERY_DESC_DEVICE_DEF_SIZE = 0x59,
- QUERY_DESC_CONFIGURATION_DEF_SIZE = 0x90,
- QUERY_DESC_UNIT_DEF_SIZE= 0x2D,
- QUERY_DESC_INTERCONNECT_DEF_SIZE= 0x06,
- QUERY_DESC_GEOMETRY_DEF_SIZE= 0x48,
- QUERY_DESC_POWER_DEF_SIZE = 0x62,
- QUERY_DESC_HEALTH_DEF_SIZE = 0x25,
-};
-
/* Unit descriptor parameters offsets in bytes*/
enum unit_desc_param {
UNIT_DESC_PARAM_LEN = 0x0,
diff --git a/drivers/scsi/ufs/ufs_bsg.c b/drivers/scsi/ufs/ufs_bsg.c
index 53dd87628cbe..27f54615ee84 100644
--- a/drivers/scsi/ufs/ufs_bsg.c
+++ b/drivers/scsi/ufs/ufs_bsg.c
@@ -11,13 +11,12 @@ static int ufs_bsg_get_query_desc_size(struct ufs_hba *hba,
int *desc_len,
{
int desc_size = be16_to_cpu(qr->length);
int desc_id = qr->idn;
- int ret;
if (desc_size <= 0)
return -EINVAL;
- ret = ufshcd_map_desc_id_to_length(hba, desc_id, desc_len);
- if (ret || !*desc_len)
+ ufshcd_map_desc_id_to_length(hba, desc_id, desc_len);
+ if (!*desc_len)
return -EINVAL;
*desc_len = min_t(int, *desc_len, desc_size);
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index bc52a0e89cd3..45d1fef982a9 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -3052,95 +3052,32 @@ int ufshcd_query_descriptor_retry(struct ufs_hba *hba,
return err;
}
-/**
- * ufshcd_read_desc_length - read the specified descriptor length from header
- * @hba: Pointer to adapter instance
- * @desc_id: descriptor idn value
- * @desc_index: descriptor index
- * @desc_length: pointer to variable to read the length of descriptor
- *
- * Return 0 in case of success, non-zero otherwise
- */
-static int ufshcd_read_desc_length(struct ufs_hba *hba,
- enum desc_idn desc_id,
- int desc_index,
- int *desc_length)
-{
- int ret;
- u8 header[QUERY_DESC_HDR_SIZE];
- int header_len = QUERY_DESC_HDR_SIZE;
-
- if (desc_id >= QUERY_DESC_IDN_MAX)
- return -EINVAL;
-
- ret = ufshcd_query_descriptor_retry(hba, UPIU_QUERY_OPCODE_READ_DESC,
- desc_id, desc_index, 0, header,
- _len);
-
- if (ret) {
- dev_err(hba->dev, "%s: Failed to get descriptor header id %d",
- __func__, desc_id);
- return ret;
- } else if (desc_id != header[QUERY_DESC_DESC_TYPE_OFFSET]) {
- dev_warn(hba->dev, "%s: descriptor header id %d and desc_id %d
mismatch",
- __func__, header[QUERY_DESC_DESC_TYPE_OFFSET],
- desc_id);
- ret = -EINVAL;
- }
-
- *desc_length = header[QUERY_DESC_LENGTH_OFFSET];
- return ret;
-
-}
-
/**
* ufshcd_map_desc_id_to_length - map descriptor IDN to its length
* @hba: Pointer to adapter instance
* @desc_id: descriptor idn value
* @desc_len: mapped desc length (out)
- *
- * Return 0 in case of success, non-zero otherwise
*/
-int ufshcd_map_desc_id_to_length(struct ufs_hba *hba,
- enum desc_idn desc_id, int *desc_len)
+void ufshcd_map_desc_id_to_length(struct ufs_hba *hba, enum desc_idn desc_id,
+ int *desc_len)
{
- switch (desc_id) {
- case QUERY_DESC_IDN_DEVICE:
- *desc_len = hba->desc_size.dev_desc;
- break;
- case QUERY_DESC_IDN_POWER:
- *desc_len = hba->desc_size.pwr_desc;
- break;
- case QUERY_DESC_IDN_GEOMETRY:
- *desc_len = hba->desc_size.geom_desc;
- break;
- case QUERY_DESC_IDN_CONFIGURATION:
- *desc_len = hba->desc_size.conf_desc;
- break;
- case QUERY_DESC_IDN_UNIT:
- *desc_len = hba->desc_size.unit_desc;
- break;
- case QUERY_DESC_IDN_INTERCONNECT:
-
[PATCH v4 5/5] scsi: ufs: add compatibility with 3.1 UFS unit descriptor length
From: Bean Huo
For UFS 3.1, the normal unit descriptor is 10 bytes larger
than the RPMB unit, however, both descriptors share the same
desc_idn, to cover both unit descriptors with one length, we
choose the normal unit descriptor length by desc_index.
Signed-off-by: Bean Huo
Reviewed-by: Avri Altman
---
drivers/scsi/ufs/ufs.h| 1 +
drivers/scsi/ufs/ufshcd.c | 11 ---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index 6548ef102eb9..332ae09e6238 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -63,6 +63,7 @@
#define UFS_UPIU_MAX_UNIT_NUM_ID 0x7F
#define UFS_MAX_LUNS (SCSI_W_LUN_BASE + UFS_UPIU_MAX_UNIT_NUM_ID)
#define UFS_UPIU_WLUN_ID (1 << 7)
+#define UFS_RPMB_UNIT 0xC4
/* WriteBooster buffer is available only for the logical unit from 0 to 7 */
#define UFS_UPIU_MAX_WB_LUN_ID 8
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 45d1fef982a9..a64718bfe2bc 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -3070,11 +3070,16 @@ void ufshcd_map_desc_id_to_length(struct ufs_hba *hba,
enum desc_idn desc_id,
EXPORT_SYMBOL(ufshcd_map_desc_id_to_length);
static void ufshcd_update_desc_length(struct ufs_hba *hba,
- enum desc_idn desc_id,
+ enum desc_idn desc_id, int desc_index,
unsigned char desc_len)
{
if (hba->desc_size[desc_id] == QUERY_DESC_MAX_SIZE &&
- desc_id != QUERY_DESC_IDN_STRING)
+ desc_id != QUERY_DESC_IDN_STRING && desc_index != UFS_RPMB_UNIT)
+ /* For UFS 3.1, the normal unit descriptor is 10 bytes larger
+* than the RPMB unit, however, both descriptors share the same
+* desc_idn, to cover both unit descriptors with one length, we
+* choose the normal unit descriptor length by desc_index.
+*/
hba->desc_size[desc_id] = desc_len;
}
@@ -3143,7 +3148,7 @@ int ufshcd_read_desc_param(struct ufs_hba *hba,
/* Update descriptor length */
buff_len = desc_buf[QUERY_DESC_LENGTH_OFFSET];
- ufshcd_update_desc_length(hba, desc_id, buff_len);
+ ufshcd_update_desc_length(hba, desc_id, desc_index, buff_len);
/* Check wherher we will not copy more data, than available */
if (is_kmalloc && param_size > buff_len)
--
2.17.1
[PATCH v4 3/5] scsi: ufs: fix potential access NULL pointer while memcpy
From: Bean Huo
If param_offset is not 0, the memcpy length shouldn't be the
true descriptor length.
Fixes: a4b0e8a4e92b ("scsi: ufs: Factor out ufshcd_read_desc_param")
Signed-off-by: Bean Huo
---
drivers/scsi/ufs/ufshcd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index f7e8bfefe3d4..bc52a0e89cd3 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -3211,7 +3211,7 @@ int ufshcd_read_desc_param(struct ufs_hba *hba,
/* Check wherher we will not copy more data, than available */
if (is_kmalloc && param_size > buff_len)
- param_size = buff_len;
+ param_size = buff_len - param_offset;
if (is_kmalloc)
memcpy(param_read_buf, _buf[param_offset], param_size);
--
2.17.1
[PATCH v4 0/5] scsi: ufs: cleanup ufs initialization
From: Bean Huo Cleanup UFS descriptor length initialization, and delete some unnecessary code. Changelog: v3 - v4: 1. add desc_id >= QUERY_DESC_IDN_MAX check in patch 4/5 (Avri Altman) 2. update buff_len to hold the true descriptor size in 4/5 (Avri Altman) 3. add new patch 3/5 v2 - v3: 1. Fix typo in the commit message (Avri Altman & Bart van Assche) 2. Delete ufshcd_init_desc_sizes() in patch 3/4 (Stanley Chu) 3. Remove max_t() and buff_len in patch 1/4 (Bart van Assche) 4. Add patch 4/4 to compatable with 3.1 UFS unit descriptor length v1 - v2: 1. split patch 2. fix one compiling WARNING (Reported-by: kbuild test robot ) Bean Huo (5): scsi: ufs: remove max_t in ufs_get_device_desc scsi: ufs: delete ufshcd_read_desc() scsi: ufs: fix potential access NULL pointer while memcpy scsi: ufs: cleanup ufs initialization path scsi: ufs: add compatibility with 3.1 UFS unit descriptor length drivers/scsi/ufs/ufs.h | 11 +- drivers/scsi/ufs/ufs_bsg.c | 5 +- drivers/scsi/ufs/ufshcd.c | 205 + drivers/scsi/ufs/ufshcd.h | 16 +-- 4 files changed, 53 insertions(+), 184 deletions(-) -- 2.17.1
[PATCH v4 2/5] scsi: ufs: delete ufshcd_read_desc()
From: Bean Huo
Delete ufshcd_read_desc(). Instead, let caller directly call
ufshcd_read_desc_param().
Signed-off-by: Bean Huo
Reviewed-by: Avri Altman
Reviewed-by: Bart van Assche
Reviewed-by: Stanley Chu
---
drivers/scsi/ufs/ufshcd.c | 27 ---
1 file changed, 8 insertions(+), 19 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index f57acfbf9d60..f7e8bfefe3d4 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -3221,16 +3221,6 @@ int ufshcd_read_desc_param(struct ufs_hba *hba,
return ret;
}
-static inline int ufshcd_read_desc(struct ufs_hba *hba,
- enum desc_idn desc_id,
- int desc_index,
- void *buf,
- u32 size)
-{
- return ufshcd_read_desc_param(hba, desc_id, desc_index, 0, buf, size);
-}
-
-
/**
* struct uc_string_id - unicode string
*
@@ -3278,9 +3268,8 @@ int ufshcd_read_string_desc(struct ufs_hba *hba, u8
desc_index,
if (!uc_str)
return -ENOMEM;
- ret = ufshcd_read_desc(hba, QUERY_DESC_IDN_STRING,
- desc_index, uc_str,
- QUERY_DESC_MAX_SIZE);
+ ret = ufshcd_read_desc_param(hba, QUERY_DESC_IDN_STRING, desc_index, 0,
+(u8 *)uc_str, QUERY_DESC_MAX_SIZE);
if (ret < 0) {
dev_err(hba->dev, "Reading String Desc failed after %d retries.
err = %d\n",
QUERY_REQ_RETRIES, ret);
@@ -6684,8 +6673,8 @@ static void ufshcd_set_active_icc_lvl(struct ufs_hba *hba)
if (!desc_buf)
return;
- ret = ufshcd_read_desc(hba, QUERY_DESC_IDN_POWER, 0,
- desc_buf, buff_len);
+ ret = ufshcd_read_desc_param(hba, QUERY_DESC_IDN_POWER, 0, 0,
+desc_buf, buff_len);
if (ret) {
dev_err(hba->dev,
"%s: Failed reading power descriptor.len = %d ret = %d",
@@ -6886,8 +6875,8 @@ static int ufs_get_device_desc(struct ufs_hba *hba)
goto out;
}
- err = ufshcd_read_desc(hba, QUERY_DESC_IDN_DEVICE, 0, desc_buf,
- hba->desc_size.dev_desc);
+ err = ufshcd_read_desc_param(hba, QUERY_DESC_IDN_DEVICE, 0, 0, desc_buf,
+hba->desc_size.dev_desc);
if (err) {
dev_err(hba->dev, "%s: Failed reading Device Desc. err = %d\n",
__func__, err);
@@ -7168,8 +7157,8 @@ static int ufshcd_device_geo_params_init(struct ufs_hba
*hba)
goto out;
}
- err = ufshcd_read_desc(hba, QUERY_DESC_IDN_GEOMETRY, 0,
- desc_buf, buff_len);
+ err = ufshcd_read_desc_param(hba, QUERY_DESC_IDN_GEOMETRY, 0, 0,
+desc_buf, buff_len);
if (err) {
dev_err(hba->dev, "%s: Failed reading Geometry Desc. err =
%d\n",
__func__, err);
--
2.17.1
[PATCH v4 1/5] scsi: ufs: remove max_t in ufs_get_device_desc
From: Bean Huo
For the UFS device, the maximum descriptor size is 255, max_t called
in ufs_get_device_desc() is useless.
Signed-off-by: Bart van Assche
Signed-off-by: Bean Huo
Acked-by: Avri Altman
Reviewed-by: Stanley Chu
---
drivers/scsi/ufs/ufshcd.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index aca50ed39844..f57acfbf9d60 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -6876,14 +6876,11 @@ static void ufs_fixup_device_setup(struct ufs_hba *hba)
static int ufs_get_device_desc(struct ufs_hba *hba)
{
int err;
- size_t buff_len;
u8 model_index;
u8 *desc_buf;
struct ufs_dev_info *dev_info = >dev_info;
- buff_len = max_t(size_t, hba->desc_size.dev_desc,
-QUERY_DESC_MAX_SIZE + 1);
- desc_buf = kmalloc(buff_len, GFP_KERNEL);
+ desc_buf = kmalloc(QUERY_DESC_MAX_SIZE, GFP_KERNEL);
if (!desc_buf) {
err = -ENOMEM;
goto out;
--
2.17.1
[PATCH] platform/x86: touchscreen_dmi: Update Trekstor Twin 10.1 entry
Add minimum values for the x and y axis, correct the max value for the
x-axis and add support for the capacitive home-button these tablets have.
Signed-off-by: Hans de Goede
---
drivers/platform/x86/touchscreen_dmi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/touchscreen_dmi.c
b/drivers/platform/x86/touchscreen_dmi.c
index 931814e62454..48ffe90ec3ce 100644
--- a/drivers/platform/x86/touchscreen_dmi.c
+++ b/drivers/platform/x86/touchscreen_dmi.c
@@ -679,11 +679,14 @@ static const struct ts_dmi_data
trekstor_primetab_t13b_data = {
};
static const struct property_entry trekstor_surftab_twin_10_1_props[] = {
- PROPERTY_ENTRY_U32("touchscreen-size-x", 1900),
+ PROPERTY_ENTRY_U32("touchscreen-min-x", 20),
+ PROPERTY_ENTRY_U32("touchscreen-min-y", 0),
+ PROPERTY_ENTRY_U32("touchscreen-size-x", 1890),
PROPERTY_ENTRY_U32("touchscreen-size-y", 1280),
PROPERTY_ENTRY_U32("touchscreen-inverted-y", 1),
PROPERTY_ENTRY_STRING("firmware-name",
"gsl3670-surftab-twin-10-1-st10432-8.fw"),
PROPERTY_ENTRY_U32("silead,max-fingers", 10),
+ PROPERTY_ENTRY_BOOL("silead,home-button"),
{ }
};
--
2.26.2
Re: [PATCH v2] power: supply: bq24190_charger: Fix runtime PM imbalance in bq24190_sysfs_store()
> pm_runtime_get_sync() increments the runtime PM usage counter even > it returns an error code. Thus a pairing decrement is needed on > the error handling path to keep the counter balanced. How do you think about a wording variant like the following? Change description: The PM runtime usage counter is incremented even if a call of the function “pm_runtime_get_sync” failed. Thus decrement it also in an error case so that the reference counting is kept consistent. Would you like to add the tag “Fixes” to the commit message? Regards, Markus
Re: [PATCH 4/5] iio: light: lm3533-als: remove explicit parent assignment
On Fri, 29 May 2020 15:45:33 +0200 Johan Hovold wrote: > [ Trimming CC to something more reasonable... ] > > On Fri, May 29, 2020 at 11:08:38AM +, Ardelean, Alexandru wrote: > > On Fri, 2020-05-29 at 12:16 +0200, Johan Hovold wrote: > > > On Fri, May 22, 2020 at 11:22:07AM +0300, Alexandru Ardelean wrote: > > > > This assignment is the more peculiar of the bunch as it assigns the > > > > parent > > > > of the platform-device's device (i.e. pdev->dev.parent) as the IIO > > > > device's > > > > parent. > > > > > > > > It's unclear whether this is intentional or not. > > > > Hence it is in it's own patch. > > > > > > Yeah, we have a few mfd drivers whose child drivers registers their > > > class devices directly under the parent mfd device rather than the > > > corresponding child platform device. > > > > > > Since it's done consistently I think you need to update them all if you > > > really want to change this. > > > > > > And it may not be worth it since at least in theory someone could now be > > > relying on this topology. > > > > Thanks for the feedback. > > I guess, it could make sense to do here: > > devm_iio_device_alloc(pdev->dev.parent, ...) > > > > Currently it's: > > devm_iio_device_alloc(>dev, ...) > > > > That would make it slightly more consistent. i.e. the life-time of > > the object would be attached to the parent of the platform device, > > versus the platform-device. > > Not really. If you unbind the iio driver, the iio device gets > deregistered (as it should be) and there's no need to keep it around any > more. > > You'd essentially just leak resources every time you rebind the driver > (e.g. during development). > > And in fact, you could also introduce a use-after-free depending on if > the parent mfd driver use devres to deregister its children. > > > Currently, as it is, the allocation [of the IIO device] is tied the > > platform-device, and the IIO registration to the parent (of the > > platform-device). > > Not quite; the iio device still gets deregistered when the platform > device is unbound. > > > I'm not super-familiar with the internals here, but does this sound a > > bit wrong? > > It's not a common pattern but not necessarily wrong per se. > > > Is there a chance where the IIO device could be de-allocated, while > > registered? > > No, the device-managed iio device object is freed when the platform > device is unbound and specifically after the iio device has been > deregistered. I had a feeling we might have a few cases like this hiding in IIO. For these I'd just leave the parent being manually set. It doesn't do any harm and the facility existing is useful for messing around with topology. We may however want to wrap it up in a utility function on the basis that we may want to change the visibility and location of the IIO device down the line. iio_device_set_parent() perhaps with docs to specify that it must be called between allocation and registration + is meant to allow cases where we want a different parent than the device used for managed allocations etc. Jonathan > > > > > Signed-off-by: Alexandru Ardelean > > > > --- > > > > drivers/iio/light/lm3533-als.c | 1 - > > > > 1 file changed, 1 deletion(-) > > > > > > > > diff --git a/drivers/iio/light/lm3533-als.c > > > > b/drivers/iio/light/lm3533-als.c > > > > index bc196c212881..0f380ec8d30c 100644 > > > > --- a/drivers/iio/light/lm3533-als.c > > > > +++ b/drivers/iio/light/lm3533-als.c > > > > @@ -852,7 +852,6 @@ static int lm3533_als_probe(struct platform_device > > > > *pdev) > > > > indio_dev->channels = lm3533_als_channels; > > > > indio_dev->num_channels = ARRAY_SIZE(lm3533_als_channels); > > > > indio_dev->name = dev_name(>dev); > > > > - indio_dev->dev.parent = pdev->dev.parent; > > > > indio_dev->modes = INDIO_DIRECT_MODE; > > > > > > > > als = iio_priv(indio_dev); > > Johan
Re: [PATCH v3] iio: stm32-adc: remove usage of iio_priv_to_dev() helper
On Tue, 26 May 2020 17:46:41 +0200
Fabrice Gasnier wrote:
> On 5/26/20 3:44 PM, Alexandru Ardelean wrote:
> > We may want to get rid of the iio_priv_to_dev() helper. The reason is that
> > we will hide some of the members of the iio_dev structure (to prevent
> > drivers from accessing them directly), and that will also mean hiding the
> > implementation of the iio_priv_to_dev() helper inside the IIO core.
> >
> > Hiding the implementation of iio_priv_to_dev() implies that some fast-paths
> > may not be fast anymore, so a general idea is to try to get rid of the
> > iio_priv_to_dev() altogether.
> > The iio_priv() helper won't be affected by the rework, as the iio_dev
> > struct will keep a reference to the private information.
> >
> > For this driver, not using iio_priv_to_dev(), means reworking some paths to
> > pass the iio device and using iio_priv() to access the private information.
> >
> > Signed-off-by: Alexandru Ardelean
> > ---
> >
> > Changelog v2 -> v3:
> > - update doc-strings; warnings show-up during build with W=1 arg
> >
> > Changelog v1 -> v2:
> > - converted to pass reference to IIO device in function hooks (vs
> > reference
> > to adc private data)
> >
> > drivers/iio/adc/stm32-adc.c | 118 +++-
> > 1 file changed, 63 insertions(+), 55 deletions(-)
>
> Hi Alexandru,
>
> Acked-by: Fabrice Gasnier
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to poke at it.
Thanks,
Jonathan
>
> Thanks,
> Fabrice
>
> >
> > diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
> > index ae622ee6d08c..1dd97ec5571c 100644
> > --- a/drivers/iio/adc/stm32-adc.c
> > +++ b/drivers/iio/adc/stm32-adc.c
> > @@ -162,10 +162,10 @@ struct stm32_adc_cfg {
> > struct stm32_adc_trig_info *trigs;
> > bool clk_required;
> > bool has_vregready;
> > - int (*prepare)(struct stm32_adc *);
> > - void (*start_conv)(struct stm32_adc *, bool dma);
> > - void (*stop_conv)(struct stm32_adc *);
> > - void (*unprepare)(struct stm32_adc *);
> > + int (*prepare)(struct iio_dev *);
> > + void (*start_conv)(struct iio_dev *, bool dma);
> > + void (*stop_conv)(struct iio_dev *);
> > + void (*unprepare)(struct iio_dev *);
> > const unsigned int *smp_cycles;
> > };
> >
> > @@ -538,10 +538,11 @@ static void stm32_adc_set_res(struct stm32_adc *adc)
> >
> > static int stm32_adc_hw_stop(struct device *dev)
> > {
> > - struct stm32_adc *adc = dev_get_drvdata(dev);
> > + struct iio_dev *indio_dev = dev_get_drvdata(dev);
> > + struct stm32_adc *adc = iio_priv(indio_dev);
> >
> > if (adc->cfg->unprepare)
> > - adc->cfg->unprepare(adc);
> > + adc->cfg->unprepare(indio_dev);
> >
> > if (adc->clk)
> > clk_disable_unprepare(adc->clk);
> > @@ -551,7 +552,8 @@ static int stm32_adc_hw_stop(struct device *dev)
> >
> > static int stm32_adc_hw_start(struct device *dev)
> > {
> > - struct stm32_adc *adc = dev_get_drvdata(dev);
> > + struct iio_dev *indio_dev = dev_get_drvdata(dev);
> > + struct stm32_adc *adc = iio_priv(indio_dev);
> > int ret;
> >
> > if (adc->clk) {
> > @@ -563,7 +565,7 @@ static int stm32_adc_hw_start(struct device *dev)
> > stm32_adc_set_res(adc);
> >
> > if (adc->cfg->prepare) {
> > - ret = adc->cfg->prepare(adc);
> > + ret = adc->cfg->prepare(indio_dev);
> > if (ret)
> > goto err_clk_dis;
> > }
> > @@ -579,7 +581,7 @@ static int stm32_adc_hw_start(struct device *dev)
> >
> > /**
> > * stm32f4_adc_start_conv() - Start conversions for regular channels.
> > - * @adc: stm32 adc instance
> > + * @indio_dev: IIO device instance
> > * @dma: use dma to transfer conversion result
> > *
> > * Start conversions for regular channels.
> > @@ -587,8 +589,10 @@ static int stm32_adc_hw_start(struct device *dev)
> > * conversions, in IIO buffer modes. Otherwise, use ADC interrupt with
> > direct
> > * DR read instead (e.g. read_raw, or triggered buffer mode without DMA).
> > */
> > -static void stm32f4_adc_start_conv(struct stm32_adc *adc, bool dma)
> > +static void stm32f4_adc_start_conv(struct iio_dev *indio_dev, bool dma)
> > {
> > + struct stm32_adc *adc = iio_priv(indio_dev);
> > +
> > stm32_adc_set_bits(adc, STM32F4_ADC_CR1, STM32F4_SCAN);
> >
> > if (dma)
> > @@ -605,8 +609,10 @@ static void stm32f4_adc_start_conv(struct stm32_adc
> > *adc, bool dma)
> > stm32_adc_set_bits(adc, STM32F4_ADC_CR2, STM32F4_SWSTART);
> > }
> >
> > -static void stm32f4_adc_stop_conv(struct stm32_adc *adc)
> > +static void stm32f4_adc_stop_conv(struct iio_dev *indio_dev)
> > {
> > + struct stm32_adc *adc = iio_priv(indio_dev);
> > +
> > stm32_adc_clr_bits(adc, STM32F4_ADC_CR2, STM32F4_EXTEN_MASK);
> > stm32_adc_clr_bits(adc, STM32F4_ADC_SR, STM32F4_STRT);
> >
> > @@ -615,8 +621,9 @@ static void stm32f4_adc_stop_conv(struct
Re: [PATCH v2] iio: stm32-dfsdm-adc: remove usage of iio_priv_to_dev() helper
On Mon, 25 May 2020 11:26:48 +0300
Alexandru Ardelean wrote:
> We may want to get rid of the iio_priv_to_dev() helper. The reason is that
> we will hide some of the members of the iio_dev structure (to prevent
> drivers from accessing them directly), and that will also mean hiding the
> implementation of the iio_priv_to_dev() helper inside the IIO core.
>
> Hiding the implementation of iio_priv_to_dev() implies that some fast-paths
> may not be fast anymore, so a general idea is to try to get rid of the
> iio_priv_to_dev() altogether.
> The iio_priv() helper won't be affected by the rework, as the iio_dev
> struct will keep a reference to the private information.
>
> For this driver, not using iio_priv_to_dev(), means reworking some paths to
> pass the iio device and using iio_priv() to access the private information.
>
> Signed-off-by: Alexandru Ardelean
Looks great. Will let it sit a little longer on list for others to review
though.
Thanks,
Jonathan
> ---
>
> Changelog v1 -> v2:
> * changed some paths to pass a reference to ref to iio device and access
> private state-struct via iio_priv()
>
> drivers/iio/adc/stm32-dfsdm-adc.c | 65 ---
> 1 file changed, 33 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c
> b/drivers/iio/adc/stm32-dfsdm-adc.c
> index 76a60d93fe23..03dfc0b6ba98 100644
> --- a/drivers/iio/adc/stm32-dfsdm-adc.c
> +++ b/drivers/iio/adc/stm32-dfsdm-adc.c
> @@ -330,9 +330,9 @@ static int stm32_dfsdm_compute_all_osrs(struct iio_dev
> *indio_dev,
> return 0;
> }
>
> -static int stm32_dfsdm_start_channel(struct stm32_dfsdm_adc *adc)
> +static int stm32_dfsdm_start_channel(struct iio_dev *indio_dev)
> {
> - struct iio_dev *indio_dev = iio_priv_to_dev(adc);
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> struct regmap *regmap = adc->dfsdm->regmap;
> const struct iio_chan_spec *chan;
> unsigned int bit;
> @@ -350,9 +350,9 @@ static int stm32_dfsdm_start_channel(struct
> stm32_dfsdm_adc *adc)
> return 0;
> }
>
> -static void stm32_dfsdm_stop_channel(struct stm32_dfsdm_adc *adc)
> +static void stm32_dfsdm_stop_channel(struct iio_dev *indio_dev)
> {
> - struct iio_dev *indio_dev = iio_priv_to_dev(adc);
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> struct regmap *regmap = adc->dfsdm->regmap;
> const struct iio_chan_spec *chan;
> unsigned int bit;
> @@ -418,11 +418,11 @@ static void stm32_dfsdm_stop_filter(struct stm32_dfsdm
> *dfsdm,
> DFSDM_CR1_DFEN_MASK, DFSDM_CR1_DFEN(0));
> }
>
> -static int stm32_dfsdm_filter_set_trig(struct stm32_dfsdm_adc *adc,
> +static int stm32_dfsdm_filter_set_trig(struct iio_dev *indio_dev,
> unsigned int fl_id,
> struct iio_trigger *trig)
> {
> - struct iio_dev *indio_dev = iio_priv_to_dev(adc);
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> struct regmap *regmap = adc->dfsdm->regmap;
> u32 jextsel = 0, jexten = STM32_DFSDM_JEXTEN_DISABLED;
> int ret;
> @@ -447,11 +447,11 @@ static int stm32_dfsdm_filter_set_trig(struct
> stm32_dfsdm_adc *adc,
> return 0;
> }
>
> -static int stm32_dfsdm_channels_configure(struct stm32_dfsdm_adc *adc,
> +static int stm32_dfsdm_channels_configure(struct iio_dev *indio_dev,
> unsigned int fl_id,
> struct iio_trigger *trig)
> {
> - struct iio_dev *indio_dev = iio_priv_to_dev(adc);
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> struct regmap *regmap = adc->dfsdm->regmap;
> struct stm32_dfsdm_filter *fl = >dfsdm->fl_list[fl_id];
> struct stm32_dfsdm_filter_osr *flo = >flo[0];
> @@ -491,11 +491,11 @@ static int stm32_dfsdm_channels_configure(struct
> stm32_dfsdm_adc *adc,
> return 0;
> }
>
> -static int stm32_dfsdm_filter_configure(struct stm32_dfsdm_adc *adc,
> +static int stm32_dfsdm_filter_configure(struct iio_dev *indio_dev,
> unsigned int fl_id,
> struct iio_trigger *trig)
> {
> - struct iio_dev *indio_dev = iio_priv_to_dev(adc);
> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
> struct regmap *regmap = adc->dfsdm->regmap;
> struct stm32_dfsdm_filter *fl = >dfsdm->fl_list[fl_id];
> struct stm32_dfsdm_filter_osr *flo = >flo[fl->fast];
> @@ -521,7 +521,7 @@ static int stm32_dfsdm_filter_configure(struct
> stm32_dfsdm_adc *adc,
> if (ret)
> return ret;
>
> - ret = stm32_dfsdm_filter_set_trig(adc, fl_id, trig);
> + ret = stm32_dfsdm_filter_set_trig(indio_dev, fl_id, trig);
> if (ret)
> return ret;
>
> @@ -729,21 +729,22 @@ static ssize_t dfsdm_adc_audio_set_spiclk(struct
> iio_dev *indio_dev,
> return len;
> }
>
> -static int
Re: [PATCH] iio: at91_adc: remove usage of iio_priv_to_dev() helper
On Mon, 25 May 2020 13:25:13 +0300
Alexandru Ardelean wrote:
> We may want to get rid of the iio_priv_to_dev() helper. The reason is that
> we will hide some of the members of the iio_dev structure (to prevent
> drivers from accessing them directly), and that will also mean hiding the
> implementation of the iio_priv_to_dev() helper inside the IIO core.
>
> Hiding the implementation of iio_priv_to_dev() implies that some fast-paths
> may not be fast anymore, so a general idea is to try to get rid of the
> iio_priv_to_dev() altogether.
> The iio_priv() helper won't be affected by the rework, as the iio_dev
> struct will keep a reference to the private information.
>
> For this driver, not using iio_priv_to_dev(), means reworking some paths to
> pass the iio device and using iio_priv() to access the private information.
>
> Signed-off-by: Alexandru Ardelean
Looks good to me. Will leave it a bit longer though to potentially
get some people more familiar with the driver to sanity check it.
Poke me after the usual couple of weeks if I seem to have lost it
down the back of the sofa.
Thanks,
Jonathan
> ---
> drivers/iio/adc/at91_adc.c | 30 +++---
> 1 file changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> index 0368b6dc6d60..896af58e88bc 100644
> --- a/drivers/iio/adc/at91_adc.c
> +++ b/drivers/iio/adc/at91_adc.c
> @@ -287,13 +287,13 @@ static void handle_adc_eoc_trigger(int irq, struct
> iio_dev *idev)
> }
> }
>
> -static int at91_ts_sample(struct at91_adc_state *st)
> +static int at91_ts_sample(struct iio_dev *idev)
> {
> + struct at91_adc_state *st = iio_priv(idev);
> unsigned int xscale, yscale, reg, z1, z2;
> unsigned int x, y, pres, xpos, ypos;
> unsigned int rxp = 1;
> unsigned int factor = 1000;
> - struct iio_dev *idev = iio_priv_to_dev(st);
>
> unsigned int xyz_mask_bits = st->res;
> unsigned int xyz_mask = (1 << xyz_mask_bits) - 1;
> @@ -449,7 +449,7 @@ static irqreturn_t at91_adc_9x5_interrupt(int irq, void
> *private)
>
> if (status & AT91_ADC_ISR_PENS) {
> /* validate data by pen contact */
> - at91_ts_sample(st);
> + at91_ts_sample(idev);
> } else {
> /* triggered by event that is no pen contact, just read
>* them to clean the interrupt and discard all.
> @@ -737,10 +737,10 @@ static int at91_adc_read_raw(struct iio_dev *idev,
> return -EINVAL;
> }
>
> -static int at91_adc_of_get_resolution(struct at91_adc_state *st,
> +static int at91_adc_of_get_resolution(struct iio_dev *idev,
> struct platform_device *pdev)
> {
> - struct iio_dev *idev = iio_priv_to_dev(st);
> + struct at91_adc_state *st = iio_priv(idev);
> struct device_node *np = pdev->dev.of_node;
> int count, i, ret = 0;
> char *res_name, *s;
> @@ -866,10 +866,10 @@ static int at91_adc_probe_dt_ts(struct device_node
> *node,
> }
> }
>
> -static int at91_adc_probe_dt(struct at91_adc_state *st,
> +static int at91_adc_probe_dt(struct iio_dev *idev,
>struct platform_device *pdev)
> {
> - struct iio_dev *idev = iio_priv_to_dev(st);
> + struct at91_adc_state *st = iio_priv(idev);
> struct device_node *node = pdev->dev.of_node;
> struct device_node *trig_node;
> int i = 0, ret;
> @@ -910,7 +910,7 @@ static int at91_adc_probe_dt(struct at91_adc_state *st,
> }
> st->vref_mv = prop;
>
> - ret = at91_adc_of_get_resolution(st, pdev);
> + ret = at91_adc_of_get_resolution(idev, pdev);
> if (ret)
> goto error_ret;
>
> @@ -1010,9 +1010,9 @@ static void atmel_ts_close(struct input_dev *dev)
> at91_adc_writel(st, AT91_ADC_IDR, AT91RL_ADC_IER_PEN);
> }
>
> -static int at91_ts_hw_init(struct at91_adc_state *st, u32 adc_clk_khz)
> +static int at91_ts_hw_init(struct iio_dev *idev, u32 adc_clk_khz)
> {
> - struct iio_dev *idev = iio_priv_to_dev(st);
> + struct at91_adc_state *st = iio_priv(idev);
> u32 reg = 0;
> u32 tssctim = 0;
> int i = 0;
> @@ -1085,11 +1085,11 @@ static int at91_ts_hw_init(struct at91_adc_state *st,
> u32 adc_clk_khz)
> return 0;
> }
>
> -static int at91_ts_register(struct at91_adc_state *st,
> +static int at91_ts_register(struct iio_dev *idev,
> struct platform_device *pdev)
> {
> + struct at91_adc_state *st = iio_priv(idev);
> struct input_dev *input;
> - struct iio_dev *idev = iio_priv_to_dev(st);
> int ret;
>
> input = input_allocate_device();
> @@ -1161,7 +1161,7 @@ static int at91_adc_probe(struct platform_device *pdev)
> st = iio_priv(idev);
>
> if (pdev->dev.of_node)
> - ret = at91_adc_probe_dt(st, pdev);
> + ret =
Re: [PATCH] iio: Kconfig: at91_adc: add COMPILE_TEST dependency to driver
On Mon, 25 May 2020 13:27:44 +0300 Alexandru Ardelean wrote: > Since changes can come from all sort of places, it may make sense to have > this symbol as a dependency to make sure that the 'make allmodconfig' && > 'make allyesconfig' build rules cover this driver as well for a > compile-build/test. > > It seemed useful [recently] when trying to apply a change for this. > > Signed-off-by: Alexandru Ardelean Makes sense. Given this sort of change can expose weird an wonderful dependencies that were previously hidden, I'll be wanting an ack from at91 people. Jonathan > --- > drivers/iio/adc/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig > index c48c0005..c1f4c0aec265 100644 > --- a/drivers/iio/adc/Kconfig > +++ b/drivers/iio/adc/Kconfig > @@ -294,7 +294,7 @@ config ASPEED_ADC > > config AT91_ADC > tristate "Atmel AT91 ADC" > - depends on ARCH_AT91 > + depends on ARCH_AT91 || COMPILE_TEST > depends on INPUT && SYSFS > select IIO_BUFFER > select IIO_TRIGGERED_BUFFER
Re: [PATCH] iio: at91-sama5d2_adc: remove usage of iio_priv_to_dev() helper
On Mon, 25 May 2020 13:53:41 +0300
Alexandru Ardelean wrote:
> We may want to get rid of the iio_priv_to_dev() helper. The reason is that
> we will hide some of the members of the iio_dev structure (to prevent
> drivers from accessing them directly), and that will also mean hiding the
> implementation of the iio_priv_to_dev() helper inside the IIO core.
>
> Hiding the implementation of iio_priv_to_dev() implies that some fast-paths
> may not be fast anymore, so a general idea is to try to get rid of the
> iio_priv_to_dev() altogether.
> The iio_priv() helper won't be affected by the rework, as the iio_dev
> struct will keep a reference to the private information.
>
> For this driver, not using iio_priv_to_dev(), means reworking some paths to
> pass the iio device and using iio_priv() to access the private information,
> and also keeping a reference to the iio device for some quirky paths.
>
> One [quirky] path is the at91_adc_workq_handler() which requires the IIO
> device & the state struct to push to buffers.
> Since this requires the back-ref to the IIO device, the
> at91_adc_touch_pos() also uses it. This simplifies the patch a bit. The
> information required in this function is mostly for debugging purposes.
> Replacing it with a reference to the IIO device would have been a slightly
> bigger change, which may not be worth it (for just the debugging purpose
> and given that we need the back-ref to the IIO device anyway).
That workq is indeed quirky. This looks fine to me in general. I'll
want an appropriate ack from the at91 side of things if possible so
let's leave this on the list for a while longer.
Poke me if no action in a few weeks.
Thanks,
Jonathan
>
> Signed-off-by: Alexandru Ardelean
> ---
> drivers/iio/adc/at91-sama5d2_adc.c | 30 +-
> 1 file changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/iio/adc/at91-sama5d2_adc.c
> b/drivers/iio/adc/at91-sama5d2_adc.c
> index 9abbbdcc7420..7bce1830 100644
> --- a/drivers/iio/adc/at91-sama5d2_adc.c
> +++ b/drivers/iio/adc/at91-sama5d2_adc.c
> @@ -402,6 +402,7 @@ struct at91_adc_state {
> wait_queue_head_t wq_data_available;
> struct at91_adc_dma dma_st;
> struct at91_adc_touch touch_st;
> + struct iio_dev *indio_dev;
> u16 buffer[AT91_BUFFER_MAX_HWORDS];
> /*
>* lock to prevent concurrent 'single conversion' requests through
> @@ -642,13 +643,13 @@ static u16 at91_adc_touch_pos(struct at91_adc_state
> *st, int reg)
> /* first half of register is the x or y, second half is the scale */
> val = at91_adc_readl(st, reg);
> if (!val)
> - dev_dbg(_priv_to_dev(st)->dev, "pos is 0\n");
> + dev_dbg(>indio_dev->dev, "pos is 0\n");
>
> pos = val & AT91_SAMA5D2_XYZ_MASK;
> result = (pos << AT91_SAMA5D2_MAX_POS_BITS) - pos;
> scale = (val >> 16) & AT91_SAMA5D2_XYZ_MASK;
> if (scale == 0) {
> - dev_err(_priv_to_dev(st)->dev, "scale is 0\n");
> + dev_err(>indio_dev->dev, "scale is 0\n");
> return 0;
> }
> result /= scale;
> @@ -1204,9 +1205,9 @@ static unsigned at91_adc_startup_time(unsigned
> startup_time_min,
> return i;
> }
>
> -static void at91_adc_setup_samp_freq(struct at91_adc_state *st, unsigned
> freq)
> +static void at91_adc_setup_samp_freq(struct iio_dev *indio_dev, unsigned
> freq)
> {
> - struct iio_dev *indio_dev = iio_priv_to_dev(st);
> + struct at91_adc_state *st = iio_priv(indio_dev);
> unsigned f_per, prescal, startup, mr;
>
> f_per = clk_get_rate(st->per_clk);
> @@ -1275,9 +1276,9 @@ static void at91_adc_pen_detect_interrupt(struct
> at91_adc_state *st)
> st->touch_st.touching = true;
> }
>
> -static void at91_adc_no_pen_detect_interrupt(struct at91_adc_state *st)
> +static void at91_adc_no_pen_detect_interrupt(struct iio_dev *indio_dev)
> {
> - struct iio_dev *indio_dev = iio_priv_to_dev(st);
> + struct at91_adc_state *st = iio_priv(indio_dev);
>
> at91_adc_writel(st, AT91_SAMA5D2_TRGR,
> AT91_SAMA5D2_TRGR_TRGMOD_NO_TRIGGER);
> @@ -1297,7 +1298,7 @@ static void at91_adc_workq_handler(struct work_struct
> *workq)
> struct at91_adc_touch, workq);
> struct at91_adc_state *st = container_of(touch_st,
> struct at91_adc_state, touch_st);
> - struct iio_dev *indio_dev = iio_priv_to_dev(st);
> + struct iio_dev *indio_dev = st->indio_dev;
>
> iio_push_to_buffers(indio_dev, st->buffer);
> }
> @@ -1318,7 +1319,7 @@ static irqreturn_t at91_adc_interrupt(int irq, void
> *private)
> at91_adc_pen_detect_interrupt(st);
> } else if ((status & AT91_SAMA5D2_IER_NOPEN)) {
> /* nopen detected IRQ */
> - at91_adc_no_pen_detect_interrupt(st);
Re: [PATCH] iio: dac: ad5592r: remove usage of iio_priv_to_dev() helper
On Mon, 25 May 2020 16:10:34 +0300
Alexandru Ardelean wrote:
> This was partially removed when the mlock cleanup was done. Only one more
> call is left in the ad5592r_alloc_channels() function.
> This one is simple. We just need to pass the iio_dev object and get the
> state via iio_priv().
>
> Signed-off-by: Alexandru Ardelean
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to poke at.
Thanks,
Jonathan
> ---
> drivers/iio/dac/ad5592r-base.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/dac/ad5592r-base.c b/drivers/iio/dac/ad5592r-base.c
> index 410e90e5f75f..272c97bb841c 100644
> --- a/drivers/iio/dac/ad5592r-base.c
> +++ b/drivers/iio/dac/ad5592r-base.c
> @@ -508,11 +508,11 @@ static void ad5592r_setup_channel(struct iio_dev
> *iio_dev,
> chan->ext_info = ad5592r_ext_info;
> }
>
> -static int ad5592r_alloc_channels(struct ad5592r_state *st)
> +static int ad5592r_alloc_channels(struct iio_dev *iio_dev)
> {
> + struct ad5592r_state *st = iio_priv(iio_dev);
> unsigned i, curr_channel = 0,
>num_channels = st->num_channels;
> - struct iio_dev *iio_dev = iio_priv_to_dev(st);
> struct iio_chan_spec *channels;
> struct fwnode_handle *child;
> u32 reg, tmp;
> @@ -636,7 +636,7 @@ int ad5592r_probe(struct device *dev, const char *name,
> if (ret)
> goto error_disable_reg;
>
> - ret = ad5592r_alloc_channels(st);
> + ret = ad5592r_alloc_channels(iio_dev);
> if (ret)
> goto error_disable_reg;
>
Re: [PATCH] perf libdw: Fix off-by 1 relative directory includes
Hi Ian,
On Sat, May 30, 2020 at 7:53 AM Ian Rogers wrote:
>
> This is currently working due to extra include paths in the build.
>
> Before:
> $ cd tools/perf/arch/arm64/util
> $ ls -la ../../util/unwind-libdw.h
> ls: cannot access '../../util/unwind-libdw.h': No such file or directory
>
> After:
> $ ls -la ../../../util/unwind-libdw.h
> -rw-r- 1 irogers irogers 553 Apr 17 14:31 ../../../util/unwind-libdw.h
Missing sign-off, but otherwise looks good to me
Acked-by: Namhyung Kim
Thanks
Namhyung
> ---
> tools/perf/arch/arm64/util/unwind-libdw.c | 6 +++---
> tools/perf/arch/powerpc/util/unwind-libdw.c | 6 +++---
> tools/perf/arch/x86/util/unwind-libdw.c | 6 +++---
> 3 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/tools/perf/arch/arm64/util/unwind-libdw.c
> b/tools/perf/arch/arm64/util/unwind-libdw.c
> index 7623d85e77f3..a50941629649 100644
> --- a/tools/perf/arch/arm64/util/unwind-libdw.c
> +++ b/tools/perf/arch/arm64/util/unwind-libdw.c
> @@ -1,8 +1,8 @@
> // SPDX-License-Identifier: GPL-2.0
> #include
> -#include "../../util/unwind-libdw.h"
> -#include "../../util/perf_regs.h"
> -#include "../../util/event.h"
> +#include "../../../util/unwind-libdw.h"
> +#include "../../../util/perf_regs.h"
> +#include "../../../util/event.h"
>
> bool libdw__arch_set_initial_registers(Dwfl_Thread *thread, void *arg)
> {
> diff --git a/tools/perf/arch/powerpc/util/unwind-libdw.c
> b/tools/perf/arch/powerpc/util/unwind-libdw.c
> index abf2dbc7f829..7b2d96ec28e3 100644
> --- a/tools/perf/arch/powerpc/util/unwind-libdw.c
> +++ b/tools/perf/arch/powerpc/util/unwind-libdw.c
> @@ -1,9 +1,9 @@
> // SPDX-License-Identifier: GPL-2.0
> #include
> #include
> -#include "../../util/unwind-libdw.h"
> -#include "../../util/perf_regs.h"
> -#include "../../util/event.h"
> +#include "../../../util/unwind-libdw.h"
> +#include "../../../util/perf_regs.h"
> +#include "../../../util/event.h"
>
> /* See backends/ppc_initreg.c and backends/ppc_regs.c in elfutils. */
> static const int special_regs[3][2] = {
> diff --git a/tools/perf/arch/x86/util/unwind-libdw.c
> b/tools/perf/arch/x86/util/unwind-libdw.c
> index fda8f4206ee4..eea2bf87232b 100644
> --- a/tools/perf/arch/x86/util/unwind-libdw.c
> +++ b/tools/perf/arch/x86/util/unwind-libdw.c
> @@ -1,8 +1,8 @@
> // SPDX-License-Identifier: GPL-2.0
> #include
> -#include "../../util/unwind-libdw.h"
> -#include "../../util/perf_regs.h"
> -#include "../../util/event.h"
> +#include "../../../util/unwind-libdw.h"
> +#include "../../../util/perf_regs.h"
> +#include "../../../util/event.h"
>
> bool libdw__arch_set_initial_registers(Dwfl_Thread *thread, void *arg)
> {
> --
> 2.27.0.rc2.251.g90737beb825-goog
>
Re: [PATCH v4 4/5] iio: imu: bmi160: added regulator support
On Mon, 25 May 2020 18:46:03 +0200
Jonathan Albrieux wrote:
> Add vdd-supply and vddio-supply support.
>
> While working on an msm8916 device and having explicit declarations for
> regulators, without setting these regulators to regulators-always-on it
> happened those lines weren't ready because they could have been controlled
> by other components, causing failure in module's probe.
>
> This patch aim is to solve this situation by adding regulators control
> during bmi160_chip_init() and bmi160_chip_uninit(), assuring power to
> this component.
>
> Signed-off-by: Jonathan Albrieux
Applied,
Thanks,
Jonathan
> ---
> drivers/iio/imu/bmi160/bmi160.h | 2 ++
> drivers/iio/imu/bmi160/bmi160_core.c | 24
> 2 files changed, 26 insertions(+)
>
> diff --git a/drivers/iio/imu/bmi160/bmi160.h b/drivers/iio/imu/bmi160/bmi160.h
> index 621f5309d735..923c3b274fde 100644
> --- a/drivers/iio/imu/bmi160/bmi160.h
> +++ b/drivers/iio/imu/bmi160/bmi160.h
> @@ -3,10 +3,12 @@
> #define BMI160_H_
>
> #include
> +#include
>
> struct bmi160_data {
> struct regmap *regmap;
> struct iio_trigger *trig;
> + struct regulator_bulk_data supplies[2];
> };
>
> extern const struct regmap_config bmi160_regmap_config;
> diff --git a/drivers/iio/imu/bmi160/bmi160_core.c
> b/drivers/iio/imu/bmi160/bmi160_core.c
> index 77b05bd4a2b2..d3316ca02fbd 100644
> --- a/drivers/iio/imu/bmi160/bmi160_core.c
> +++ b/drivers/iio/imu/bmi160/bmi160_core.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -709,6 +710,12 @@ static int bmi160_chip_init(struct bmi160_data *data,
> bool use_spi)
> unsigned int val;
> struct device *dev = regmap_get_device(data->regmap);
>
> + ret = regulator_bulk_enable(ARRAY_SIZE(data->supplies), data->supplies);
> + if (ret) {
> + dev_err(dev, "Failed to enable regulators: %d\n", ret);
> + return ret;
> + }
> +
> ret = regmap_write(data->regmap, BMI160_REG_CMD, BMI160_CMD_SOFTRESET);
> if (ret)
> return ret;
> @@ -793,9 +800,16 @@ int bmi160_probe_trigger(struct iio_dev *indio_dev, int
> irq, u32 irq_type)
> static void bmi160_chip_uninit(void *data)
> {
> struct bmi160_data *bmi_data = data;
> + struct device *dev = regmap_get_device(bmi_data->regmap);
> + int ret;
>
> bmi160_set_mode(bmi_data, BMI160_GYRO, false);
> bmi160_set_mode(bmi_data, BMI160_ACCEL, false);
> +
> + ret = regulator_bulk_disable(ARRAY_SIZE(bmi_data->supplies),
> + bmi_data->supplies);
> + if (ret)
> + dev_err(dev, "Failed to disable regulators: %d\n", ret);
> }
>
> int bmi160_core_probe(struct device *dev, struct regmap *regmap,
> @@ -815,6 +829,16 @@ int bmi160_core_probe(struct device *dev, struct regmap
> *regmap,
> dev_set_drvdata(dev, indio_dev);
> data->regmap = regmap;
>
> + data->supplies[0].supply = "vdd";
> + data->supplies[1].supply = "vddio";
> + ret = devm_regulator_bulk_get(dev,
> + ARRAY_SIZE(data->supplies),
> + data->supplies);
> + if (ret) {
> + dev_err(dev, "Failed to get regulators: %d\n", ret);
> + return ret;
> + }
> +
> ret = bmi160_chip_init(data, use_spi);
> if (ret)
> return ret;
Re: [PATCH v4 3/5] iio: imu: bmi160: fix typo
On Mon, 25 May 2020 18:46:02 +0200
Jonathan Albrieux wrote:
> Fix a typo in MODULE_AUTHOR() argument.
>
> Signed-off-by: Jonathan Albrieux
applied
Thanks,
J
> ---
> drivers/iio/imu/bmi160/bmi160_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/imu/bmi160/bmi160_core.c
> b/drivers/iio/imu/bmi160/bmi160_core.c
> index 6af65d6f1d28..77b05bd4a2b2 100644
> --- a/drivers/iio/imu/bmi160/bmi160_core.c
> +++ b/drivers/iio/imu/bmi160/bmi160_core.c
> @@ -853,6 +853,6 @@ int bmi160_core_probe(struct device *dev, struct regmap
> *regmap,
> }
> EXPORT_SYMBOL_GPL(bmi160_core_probe);
>
> -MODULE_AUTHOR("Daniel Baluta +MODULE_AUTHOR("Daniel Baluta ");
> MODULE_DESCRIPTION("Bosch BMI160 driver");
> MODULE_LICENSE("GPL v2");
Re: [PATCH 01/27] vfs, afs, ext4: Make the inode hash table RCU searchable
Al Viro wrote:
> > + * The @test function is not permitted to take a ref on any inode presented
> > + * unless the caller is holding the inode hashtable lock. It is also not
> > + * permitted to sleep, since it may be called with the RCU read lock held.
> > + *
> > + * The caller must hold either the RCU read lock or the inode hashtable
> > lock.
>
> Just how could that caller be holding inode_hash_lock? It's static and IMO
> should remain such - it's too low-level detail of fs/inode.c for having the
> code outside play with it.
>
> Require the caller to hold rcu_read_lock() and make "not permitted to take
> a ref or sleep" unconditional.
My thinking was that it might be callable from within fs/inode.c, but I can
remove that idea for now since I didn't end up calling it from there.
> Umm.. I see the point of those WRITE_ONCE, but what's READ_ONCE for?
Fair point. It's under i_lock.
A revised version of the patch is attached.
I'm thinking I should probably undo the changes to find_inode(),
find_inode_fast() and test_inode_iunique(). They don't need to use
hlist_for_each_entry_rcu() as they use the hash table lock.
David
---
commit 3f19b2ab97a97b413c24b66c67ae16daa4f56c35
Author: David Howells
Date: Fri Dec 1 11:40:16 2017 +
vfs, afs, ext4: Make the inode hash table RCU searchable
Make the inode hash table RCU searchable so that searches that want to
access or modify an inode without taking a ref on that inode can do so
without taking the inode hash table lock.
The main thing this requires is some RCU annotation on the list
manipulation operations. Inodes are already freed by RCU in most cases.
Users of this interface must take care as the inode may be still under
construction or may be being torn down around them.
There are at least three instances where this can be of use:
(1) Testing whether the inode number iunique() is going to return is
currently unique (the iunique_lock is still held).
(2) Ext4 date stamp updating.
(3) AFS callback breaking.
Signed-off-by: David Howells
Acked-by: Konstantin Khlebnikov
cc: linux-e...@vger.kernel.org
cc: linux-...@lists.infradead.org
diff --git a/fs/afs/callback.c b/fs/afs/callback.c
index 2dca8df1a18d..0dcbd40732d1 100644
--- a/fs/afs/callback.c
+++ b/fs/afs/callback.c
@@ -252,6 +252,7 @@ static void afs_break_one_callback(struct afs_server
*server,
struct afs_vnode *vnode;
struct inode *inode;
+ rcu_read_lock();
read_lock(>cb_break_lock);
hlist_for_each_entry(vi, >cb_volumes, srv_link) {
if (vi->vid < fid->vid)
@@ -287,12 +288,16 @@ static void afs_break_one_callback(struct afs_server
*server,
} else {
data.volume = NULL;
data.fid = *fid;
- inode = ilookup5_nowait(cbi->sb, fid->vnode,
- afs_iget5_test, );
+
+ /* See if we can find a matching inode - even an I_NEW
+* inode needs to be marked as it can have its callback
+* broken before we finish setting up the local inode.
+*/
+ inode = find_inode_rcu(cbi->sb, fid->vnode,
+ afs_iget5_test, );
if (inode) {
vnode = AFS_FS_I(inode);
afs_break_callback(vnode,
afs_cb_break_for_callback);
- iput(inode);
} else {
trace_afs_cb_miss(fid,
afs_cb_break_for_callback);
}
@@ -301,6 +306,7 @@ static void afs_break_one_callback(struct afs_server
*server,
out:
read_unlock(>cb_break_lock);
+ rcu_read_unlock();
}
/*
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 2a4aae6acdcb..2bbb55d05bb7 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -4860,21 +4860,22 @@ static int ext4_inode_blocks_set(handle_t *handle,
return 0;
}
-struct other_inode {
- unsigned long orig_ino;
- struct ext4_inode *raw_inode;
-};
-
-static int other_inode_match(struct inode * inode, unsigned long ino,
-void *data)
+static void __ext4_update_other_inode_time(struct super_block *sb,
+ unsigned long orig_ino,
+ unsigned long ino,
+ struct ext4_inode *raw_inode)
{
- struct other_inode *oi = (struct other_inode *) data;
+ struct inode *inode;
+
+ inode = find_inode_by_ino_rcu(sb, ino);
+ if (!inode)
+ return;
- if ((inode->i_ino != ino) ||
- (inode->i_state & (I_FREEING | I_WILL_FREE | I_NEW |
+ if
Re: [PATCH v2] iio: magnetometer: ak8974: Fix runtime PM imbalance on error in ak8974_probe()
> When devm_regmap_init_i2c() returns an error code, a pairing > runtime PM usage counter decrement is needed to keep the > counter balanced. How do you think about to replace the word “pairing” by “corresponding”? > For error paths after ak8974_set_power(), > ak8974_detect() and ak8974_reset(), things are the same. Will an other wording become more helpful than this information? > However, When iio_triggered_buffer_setup() returns an error > code, there will be two PM usgae counter decrements. Please avoid two typos in this sentence. Would you like to add the tag “Fixes” to the commit message? … +++ b/drivers/iio/magnetometer/ak8974.c … @@ -854,7 +856,6 @@ static int ak8974_probe(struct i2c_client *i2c, … Can a source code variant like the following make sense for a more complete exception handling? power_off: ak8974_set_power(ak8974, AK8974_PWR_OFF); put_pm: pm_runtime_put_noidle(>dev); pm_runtime_disable(>dev); disable_regulator: regulator_bulk_disable(ARRAY_SIZE(ak8974->regs), ak8974->regs); return ret; Regards, Markus
Re: [PATCH v4 2/5] dt-bindings: iio: imu: bmi160: add regulators and mount-matrix
On Fri, 29 May 2020 11:09:43 -0600
Rob Herring wrote:
> On Mon, May 25, 2020 at 06:46:01PM +0200, Jonathan Albrieux wrote:
> > Add vdd-supply and vddio-supply support.
> > Add mount-matrix support.
> >
> > Signed-off-by: Jonathan Albrieux
> > ---
> > .../bindings/iio/imu/bosch,bmi160.yaml | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml
> > b/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml
> > index 0d0ef84e22b9..cfe40dbcd723 100644
> > --- a/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml
> > +++ b/Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml
> > @@ -37,6 +37,17 @@ properties:
> >set if the specified interrupt pin should be configured as
> >open drain. If not set, defaults to push-pull.
> >
> > + vdd-supply:
> > +maxItems: 1
>
> Supplies are always a single item, so don't need this.
Given this (and case below) were it outstanding for this patch I
fixed them up whilst applying rather than getting Jonathan to
go around again.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
>
> > +description: provide VDD power to the sensor.
> > +
> > + vddio-supply:
> > +maxItems: 1
> > +description: provide VDD IO power to the sensor.
> > +
> > + mount-matrix:
> > +description: an optional 3x3 mounting rotation matrix
> > +
> > required:
> >- compatible
> >- reg
> > @@ -52,9 +63,14 @@ examples:
> > bmi160@68 {
> > compatible = "bosch,bmi160";
> > reg = <0x68>;
> > +vdd-supply = <_l17>;
> > +vddio-supply = <_l6>;
> > interrupt-parent = <>;
> > interrupts = <12 IRQ_TYPE_EDGE_RISING>;
> > interrupt-names = "INT1";
> > +mount-matrix = "0", "1", "0",
> > + "-1", "0", "0",
> > + "0", "0", "1";
> > };
> > };
> >- |
> > --
> > 2.17.1
> >
Re: [PATCH v4 1/5] dt-bindings: iio: imu: bmi160: convert format to yaml, add maintainer
On Fri, 29 May 2020 11:08:34 -0600 Rob Herring wrote: > On Mon, 25 May 2020 18:46:00 +0200, Jonathan Albrieux wrote: > > Converts documentation from txt format to yaml. > > > > Signed-off-by: Jonathan Albrieux > > --- > > .../devicetree/bindings/iio/imu/bmi160.txt| 37 - > > .../bindings/iio/imu/bosch,bmi160.yaml| 75 +++ > > 2 files changed, 75 insertions(+), 37 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/iio/imu/bmi160.txt > > create mode 100644 > > Documentation/devicetree/bindings/iio/imu/bosch,bmi160.yaml > > > > Reviewed-by: Rob Herring Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to poke at. Thanks, Jonathan
Re: [PATCH] [v2] iio: magnetometer: ak8974: Fix runtime PM imbalance on error
On Tue, 26 May 2020 13:13:56 +0200 Linus Walleij wrote: > On Tue, May 26, 2020 at 12:47 PM Dinghao Liu wrote: > > > When devm_regmap_init_i2c() returns an error code, a pairing > > runtime PM usage counter decrement is needed to keep the > > counter balanced. For error paths after ak8974_set_power(), > > ak8974_detect() and ak8974_reset(), things are the same. > > > > However, When iio_triggered_buffer_setup() returns an error > > code, there will be two PM usgae counter decrements. > > > > Signed-off-by: Dinghao Liu > > --- > > > > Changelog: > > > > v2: - Change 3 goto targets from "power_off" to > > "disabel_pm". Remove unused lable "power_off". > > Move 3 PM runtime related calls to the end of > > the function. > > Thanks for fixing this Dinghao! > Reviewed-by: Linus Walleij Could I have a fixes tag for this one? Thanks, Jonathan > > Yours, > Linus Walleij
[GIT pull] x86/urgent for
Linus,
please pull the latest x86/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-urgent-2020-05-31
up to: aa61b7bb00f7: Merge branch 'fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs into x86/urgent
A pile of x86 fixes:
- Prevent a memory leak in ioperm which was caused by the stupid
assumption that the exit cleanup is always called for current, which is
not the case when fork fails after taking a reference on the ioperm
bitmap.
- Fix an arithmething overflow in the DMA code on 32bit systems
- Fill gaps in the xstate copy with defaults instead of leaving them
uninitialized
- Revert: "Make __X32_SYSCALL_BIT be unsigned long" as it turned out
that existing user space fails to build.
Thanks,
tglx
-->
Al Viro (1):
copy_xstate_to_kernel(): don't leave parts of destination uninitialized
Alexander Dahl (1):
x86/dma: Fix max PFN arithmetic overflow on 32 bit systems
Andy Lutomirski (1):
x86/syscalls: Revert "x86/syscalls: Make __X32_SYSCALL_BIT be unsigned
long"
Jay Lang (1):
x86/ioperm: Prevent a memory leak when fork fails
arch/x86/include/asm/dma.h | 2 +-
arch/x86/include/asm/io_bitmap.h | 4 +-
arch/x86/include/uapi/asm/unistd.h | 11 +++-
arch/x86/kernel/fpu/xstate.c | 86 ++--
arch/x86/kernel/ioport.c | 22
arch/x86/kernel/process.c| 4 +-
tools/arch/x86/include/uapi/asm/unistd.h | 2 +-
7 files changed, 74 insertions(+), 57 deletions(-)
diff --git a/arch/x86/include/asm/dma.h b/arch/x86/include/asm/dma.h
index 00f7cf45e699..8e95aa4b0d17 100644
--- a/arch/x86/include/asm/dma.h
+++ b/arch/x86/include/asm/dma.h
@@ -74,7 +74,7 @@
#define MAX_DMA_PFN ((16UL * 1024 * 1024) >> PAGE_SHIFT)
/* 4GB broken PCI/AGP hardware bus master zone */
-#define MAX_DMA32_PFN ((4UL * 1024 * 1024 * 1024) >> PAGE_SHIFT)
+#define MAX_DMA32_PFN (1UL << (32 - PAGE_SHIFT))
#ifdef CONFIG_X86_32
/* The maximum address that we can perform a DMA transfer to on this platform
*/
diff --git a/arch/x86/include/asm/io_bitmap.h b/arch/x86/include/asm/io_bitmap.h
index 07344d82e88e..ac1a99ffbd8d 100644
--- a/arch/x86/include/asm/io_bitmap.h
+++ b/arch/x86/include/asm/io_bitmap.h
@@ -17,7 +17,7 @@ struct task_struct;
#ifdef CONFIG_X86_IOPL_IOPERM
void io_bitmap_share(struct task_struct *tsk);
-void io_bitmap_exit(void);
+void io_bitmap_exit(struct task_struct *tsk);
void native_tss_update_io_bitmap(void);
@@ -29,7 +29,7 @@ void native_tss_update_io_bitmap(void);
#else
static inline void io_bitmap_share(struct task_struct *tsk) { }
-static inline void io_bitmap_exit(void) { }
+static inline void io_bitmap_exit(struct task_struct *tsk) { }
static inline void tss_update_io_bitmap(void) { }
#endif
diff --git a/arch/x86/include/uapi/asm/unistd.h
b/arch/x86/include/uapi/asm/unistd.h
index 196fdd02b8b1..be5e2e747f50 100644
--- a/arch/x86/include/uapi/asm/unistd.h
+++ b/arch/x86/include/uapi/asm/unistd.h
@@ -2,8 +2,15 @@
#ifndef _UAPI_ASM_X86_UNISTD_H
#define _UAPI_ASM_X86_UNISTD_H
-/* x32 syscall flag bit */
-#define __X32_SYSCALL_BIT 0x4000UL
+/*
+ * x32 syscall flag bit. Some user programs expect syscall NR macros
+ * and __X32_SYSCALL_BIT to have type int, even though syscall numbers
+ * are, for practical purposes, unsigned long.
+ *
+ * Fortunately, expressions like (nr & ~__X32_SYSCALL_BIT) do the right
+ * thing regardless.
+ */
+#define __X32_SYSCALL_BIT 0x4000
#ifndef __KERNEL__
# ifdef __i386__
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 32b153d38748..6a54e83d5589 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -957,18 +957,31 @@ static inline bool xfeatures_mxcsr_quirk(u64 xfeatures)
return true;
}
-/*
- * This is similar to user_regset_copyout(), but will not add offset to
- * the source data pointer or increment pos, count, kbuf, and ubuf.
- */
-static inline void
-__copy_xstate_to_kernel(void *kbuf, const void *data,
- unsigned int offset, unsigned int size, unsigned int
size_total)
+static void fill_gap(unsigned to, void **kbuf, unsigned *pos, unsigned *count)
{
- if (offset < size_total) {
- unsigned int copy = min(size, size_total - offset);
+ if (*pos < to) {
+ unsigned size = to - *pos;
+
+ if (size > *count)
+ size = *count;
+ memcpy(*kbuf, (void *)_fpstate.xsave + *pos, size);
+ *kbuf += size;
+ *pos += size;
+ *count -= size;
+ }
+}
- memcpy(kbuf + offset, data, copy);
+static void copy_part(unsigned offset, unsigned size, void *from,
+ void **kbuf, unsigned *pos, unsigned *count)
+{
+ fill_gap(offset, kbuf, pos, count);
+ if
[GIT pull] sched/urgent for v5.7
Linus, please pull the latest sched/urgent branch from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched-urgent-2020-05-31 up to: 18f855e574d9: sched/fair: Don't NUMA balance for kthreads A single scheduler fix preventing a crash in NUMA balancing. The current->mm check is not reliable as the mm might be temporary due to use_mm() in a kthread. Check for PF_KTHREAD explictely. Thanks, tglx --> Jens Axboe (1): sched/fair: Don't NUMA balance for kthreads kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 538ba5d94e99..da3e5b54715b 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -2908,7 +2908,7 @@ static void task_tick_numa(struct rq *rq, struct task_struct *curr) /* * We don't care about NUMA placement if we don't have memory. */ - if (!curr->mm || (curr->flags & PF_EXITING) || work->next != work) + if ((curr->flags & (PF_EXITING | PF_KTHREAD)) || work->next != work) return; /*
Re: [GIT PULL] Immutable branch between MFD, IIO and Power due for the v5.8 merge window
On Thu, 28 May 2020 09:09:39 +0200 Sebastian Reichel wrote: > Hi, > > Thanks for taking care of it Lee, merged! Thanks indeed. Given timing I'll probably only get this into IIO via a rebase after rc1. Thanks, Jonathan > > -- Sebastian > > On Tue, May 26, 2020 at 10:47:02AM +0100, Lee Jones wrote: > > Enjoy! > > > > The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136: > > > > Linux 5.7-rc1 (2020-04-12 12:35:55 -0700) > > > > are available in the Git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git > > tags/ib-mfd-iio-power-v5.8 > > > > for you to fetch changes up to 904ac71f4b0c1c26ec47ff597cb3d3c7d36e618d: > > > > MAINTAINERS: Add entry for mp2629 Battery Charger driver (2020-05-26 > > 10:42:02 +0100) > > > > > > Immutable branch between MFD, IIO and Power due for the v5.8 merge window > > > > > > Saravanan Sekar (6): > > dt-bindings: mfd: Add document bindings for mp2629 > > mfd: mp2629: Add support for mps battery charger > > iio: adc: mp2629: Add support for mp2629 ADC driver > > power: supply: Add support for mps mp2629 battery charger > > power: supply: mp2629: Add impedance compensation config > > MAINTAINERS: Add entry for mp2629 Battery Charger driver > > > > Documentation/ABI/testing/sysfs-class-power-mp2629 | 8 + > > .../devicetree/bindings/mfd/mps,mp2629.yaml| 62 ++ > > MAINTAINERS| 5 + > > drivers/iio/adc/Kconfig| 10 + > > drivers/iio/adc/Makefile | 1 + > > drivers/iio/adc/mp2629_adc.c | 208 +++ > > drivers/mfd/Kconfig| 9 + > > drivers/mfd/Makefile | 2 + > > drivers/mfd/mp2629.c | 79 +++ > > drivers/power/supply/Kconfig | 10 + > > drivers/power/supply/Makefile | 1 + > > drivers/power/supply/mp2629_charger.c | 669 > > + > > include/linux/mfd/mp2629.h | 26 + > > 13 files changed, 1090 insertions(+) > > create mode 100644 Documentation/ABI/testing/sysfs-class-power-mp2629 > > create mode 100644 Documentation/devicetree/bindings/mfd/mps,mp2629.yaml > > create mode 100644 drivers/iio/adc/mp2629_adc.c > > create mode 100644 drivers/mfd/mp2629.c > > create mode 100644 drivers/power/supply/mp2629_charger.c > > create mode 100644 include/linux/mfd/mp2629.h > > > > -- > > Lee Jones [李琼斯] > > Linaro Services Technical Lead > > Linaro.org │ Open source software for ARM SoCs > > Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] iio: cros_ec: Reapply range at resume
On Tue, 26 May 2020 21:35:17 -0700
Gwendal Grignou wrote:
> EC does not currently preserve range across sensor reinit.
> If sensor is powered down at suspend, it will default to the EC default
> range at resume, not the range set by the host.
>
> Save range if modified, and apply at resume.
>
> Signed-off-by: Gwendal Grignou
one minor moan inline, but not important.
Applied to the togreg branch of iio.git and pushed out as testing.
There would be some logic to applying this as a fix and to stable.
If you like me to do that, let me know.
Thanks,
Jonathan
> ---
> .../common/cros_ec_sensors/cros_ec_sensors.c | 5 +
> .../cros_ec_sensors/cros_ec_sensors_core.c| 21 +++
> drivers/iio/light/cros_ec_light_prox.c| 6 +-
> drivers/iio/pressure/cros_ec_baro.c | 8 +--
> .../linux/iio/common/cros_ec_sensors_core.h | 11 +-
> 5 files changed, 47 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> index a66941fdb3855..130ab8ce0269b 100644
> --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
> @@ -200,6 +200,10 @@ static int cros_ec_sensors_write(struct iio_dev
> *indio_dev,
> st->core.param.sensor_range.roundup = 1;
>
> ret = cros_ec_motion_send_host_cmd(>core, 0);
> + if (ret == 0) {
> + st->core.range_updated = true;
> + st->core.curr_range = val;
> + }
> break;
> default:
> ret = cros_ec_sensors_core_write(
> @@ -315,6 +319,7 @@ MODULE_DEVICE_TABLE(platform, cros_ec_sensors_ids);
> static struct platform_driver cros_ec_sensors_platform_driver = {
> .driver = {
> .name = "cros-ec-sensors",
> + .pm = _ec_sensors_pm_ops,
> },
> .probe = cros_ec_sensors_probe,
> .id_table = cros_ec_sensors_ids,
> diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> index c831915ca7e56..cda459b612067 100644
> --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
> @@ -824,5 +824,26 @@ int cros_ec_sensors_core_write(struct
> cros_ec_sensors_core_state *st,
> }
> EXPORT_SYMBOL_GPL(cros_ec_sensors_core_write);
>
> +static int __maybe_unused cros_ec_sensors_resume(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> + struct cros_ec_sensors_core_state *st = iio_priv(indio_dev);
> + int ret = 0;
> +
> + if (st->range_updated) {
> + mutex_lock(>cmd_lock);
> + st->param.cmd = MOTIONSENSE_CMD_SENSOR_RANGE;
> + st->param.sensor_range.data = st->curr_range;
> + st->param.sensor_range.roundup = 1;
> + ret = cros_ec_motion_send_host_cmd(st, 0);
> + mutex_unlock(>cmd_lock);
> + }
> + return ret;
> +}
> +
> +SIMPLE_DEV_PM_OPS(cros_ec_sensors_pm_ops, NULL, cros_ec_sensors_resume);
> +EXPORT_SYMBOL_GPL(cros_ec_sensors_pm_ops);
> +
> MODULE_DESCRIPTION("ChromeOS EC sensor hub core functions");
> MODULE_LICENSE("GPL v2");
> diff --git a/drivers/iio/light/cros_ec_light_prox.c
> b/drivers/iio/light/cros_ec_light_prox.c
> index 2198b50909ed0..fed79ba27fda5 100644
> --- a/drivers/iio/light/cros_ec_light_prox.c
> +++ b/drivers/iio/light/cros_ec_light_prox.c
> @@ -145,8 +145,11 @@ static int cros_ec_light_prox_write(struct iio_dev
> *indio_dev,
> break;
> case IIO_CHAN_INFO_CALIBSCALE:
> st->core.param.cmd = MOTIONSENSE_CMD_SENSOR_RANGE;
> - st->core.param.sensor_range.data = (val << 16) | (val2 / 100);
> + st->core.curr_range = (val << 16) | (val2 / 100);
> + st->core.param.sensor_range.data = st->core.curr_range;
> ret = cros_ec_motion_send_host_cmd(>core, 0);
> + if (ret == 0)
> + st->core.range_updated = true;
> break;
> default:
> ret = cros_ec_sensors_core_write(>core, chan, val, val2,
> @@ -256,6 +259,7 @@ MODULE_DEVICE_TABLE(platform, cros_ec_light_prox_ids);
> static struct platform_driver cros_ec_light_prox_platform_driver = {
> .driver = {
> .name = "cros-ec-light-prox",
> + .pm = _ec_sensors_pm_ops,
> },
> .probe = cros_ec_light_prox_probe,
> .id_table = cros_ec_light_prox_ids,
> diff --git a/drivers/iio/pressure/cros_ec_baro.c
> b/drivers/iio/pressure/cros_ec_baro.c
> index c079b89600824..f0938b6fbba07 100644
> --- a/drivers/iio/pressure/cros_ec_baro.c
> +++ b/drivers/iio/pressure/cros_ec_baro.c
> @@ -96,8 +96,11 @@ static int
Re: [PATCH] iio: accel: mxc4005: add support for mxc6655
On Sun, 31 May 2020 15:16:00 +0200
Christian Oder wrote:
> Hi Jonathan,
>
> I tested the sensor on a Chuwi Hi10 X and only went by what I've seen in other
> commits before[1].
>
> I just ran another test to see what entry is necessary and it appears the
> sensor
> still works when removing the i2c entry, but is not working anymore when
> removing the ACPI match. I got the ACPI IDs from udevadm info -e[2].
> Would that mean, that I should remove the i2c entry given it's working fine
> with ACPI on its own then, or am I missing something?
The i2c entry is fine.
>
> I'm also successfully using the ACPI ID for the touchscreen orientation quirk
> in systemd[3].
Great. That means it is out there so is a defacto binding even if
there isn't an official Doc. Sadly a lot of device manufacturers
don't do this stuff the way they are supposed to!
>
> > Adding an explicit DT binding table would also be
> > good if that is method you are using to probe this (or PRP0001
> > from acpi which uses the dt bindings table)
>
> Frankly, I have no idea how to do that or if that would still be required when
> using ACPI. Can you point me in a rough direction in case it's still needed?
It's all good given you've confirmed the ID is out there in the wild.
Applied to the togreg branch of iio.git and pushed out as testing for
autobuilders to poke at.
Note we've missed the merge window now so this will take a while to get
into the mainline kernel - should be in linux-next in a few weeks though.
Thanks,
Jonathan
>
> Regards,
> Christian
>
> ---
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/iio/accel/mxc6255.c?h=v5.6.15=06777c562a50a09c4a2becfb2bf63c762a45df17
>
> [2]
> P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:22/MXC6655:00
> L: 0
> E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:22/MXC6655:00
> E: SUBSYSTEM=acpi
> E: MODALIAS=acpi:MXC6655:MXC6655:
> E: USEC_INITIALIZED=5319671
> E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
>
> P: /devices/pci:00/:00:16.0/i2c_designware.0/i2c-0/i2c-MXC6655:00
> L: 0
> E:
> DEVPATH=/devices/pci:00/:00:16.0/i2c_designware.0/i2c-0/i2c-MXC6655:00
> E: SUBSYSTEM=i2c
> E: MODALIAS=acpi:MXC6655:MXC6655:
>
> [3]
> https://github.com/systemd/systemd/commit/5e0676c2cad60b1ea029b9bfb9737e1967abb93a
>
> On Sun, May 31, 2020 at 12:30 PM Jonathan Cameron wrote:
> >
> > On Fri, 29 May 2020 22:05:49 +0200
> > Christian Oder wrote:
> >
> > > The mxc6655 is fully working with the existing mxc4005 driver.
> > > Add support for it.
> > >
> > > Signed-off-by: Christian Oder
> >
> > One query on ACPI bindings. What is there already may
> > be missleading :(
> >
> >
> > > ---
> > > drivers/iio/accel/mxc4005.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/iio/accel/mxc4005.c b/drivers/iio/accel/mxc4005.c
> > > index 3d5bea651923..3b8614352cb4 100644
> > > --- a/drivers/iio/accel/mxc4005.c
> > > +++ b/drivers/iio/accel/mxc4005.c
> > > @@ -474,12 +474,14 @@ static int mxc4005_probe(struct i2c_client *client,
> > >
> > > static const struct acpi_device_id mxc4005_acpi_match[] = {
> > > {"MXC4005", 0},
> > > + {"MXC6655", 0},
> >
> > Do we have a reference for these ACPI bindings? While they may seem
> > obvious, memsic don't have a registered PNP or ACPI ID that I can
> > find. If these are in the wild (i.e. in shipping firmware) then we
> > can take them as defacto bindings, otherwise we should avoid making
> > them so by putting them in the driver.
> >
> > Quite a few similar bindings got in a while back that I should have
> > noticed, but I wasn't so familiar with ACPI back then. Some
> > scrubbing of these has gone on recently, but there are lots still
> > left in IIO.
> >
> > If we aren't sure, then drop the ACPI addition and just leave the
> > i2c one below. Adding an explicit DT binding table would also be
> > good if that is method you are using to probe this (or PRP0001
> > from acpi which uses the dt bindings table)
> >
> > Thanks,
> >
> > Jonathan
> >
> >
> > > { },
> > > };
> > > MODULE_DEVICE_TABLE(acpi, mxc4005_acpi_match);
> > >
> > > static const struct i2c_device_id mxc4005_id[] = {
> > > {"mxc4005", 0},
> > > + {"mxc6655", 0},
> > > { },
> > > };
> > > MODULE_DEVICE_TABLE(i2c, mxc4005_id);
> >
Re: [PATCH 5/6] iio: light: stk3310: Constify regmap_config
On Tue, 26 May 2020 23:02:22 +0200
Rikard Falkeborn wrote:
> stk3310_regmap_config is not modified and can be made const to allow the
> compiler to put it in read-only memory.
>
> Before:
>textdata bss dec hex filename
> 160275424 128 21579544b drivers/iio/light/stk3310.o
>
> After:
>textdata bss dec hex filename
> 163475104 128 21579544b drivers/iio/light/stk3310.o
>
> Signed-off-by: Rikard Falkeborn
Applied.
thanks,
Jonathan
> ---
> drivers/iio/light/stk3310.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/light/stk3310.c b/drivers/iio/light/stk3310.c
> index 185c24a75ae6..9d1e503bc958 100644
> --- a/drivers/iio/light/stk3310.c
> +++ b/drivers/iio/light/stk3310.c
> @@ -487,7 +487,7 @@ static bool stk3310_is_volatile_reg(struct device *dev,
> unsigned int reg)
> }
> }
>
> -static struct regmap_config stk3310_regmap_config = {
> +static const struct regmap_config stk3310_regmap_config = {
> .name = STK3310_REGMAP_NAME,
> .reg_bits = 8,
> .val_bits = 8,
Re: [PATCH 6/6] iio: magnetometer: mmc35240: Constify struct reg_default
On Tue, 26 May 2020 23:02:23 +0200
Rikard Falkeborn wrote:
> mmc35240_reg_defaults is not modified and can be made const to allow the
> compiler to put it in read-only memory.
>
> Before:
>textdata bss dec hex filename
>97593288 128 131753377 drivers/iio/magnetometer/mmc35240.o
>
> After:
>textdata bss dec hex filename
>98233224 128 131753377 drivers/iio/magnetometer/mmc35240.o
>
> Signed-off-by: Rikard Falkeborn
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/magnetometer/mmc35240.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/magnetometer/mmc35240.c
> b/drivers/iio/magnetometer/mmc35240.c
> index 1787d656d009..f27586716b5c 100644
> --- a/drivers/iio/magnetometer/mmc35240.c
> +++ b/drivers/iio/magnetometer/mmc35240.c
> @@ -459,7 +459,7 @@ static bool mmc35240_is_volatile_reg(struct device *dev,
> unsigned int reg)
> }
> }
>
> -static struct reg_default mmc35240_reg_defaults[] = {
> +static const struct reg_default mmc35240_reg_defaults[] = {
> { MMC35240_REG_CTRL0, 0x00 },
> { MMC35240_REG_CTRL1, 0x00 },
> };
Re: [PATCH 3/6] iio: dac: ad5592r-base: Constify struct iio_chan_spec_ext_info
On Wed, 27 May 2020 04:22:46 +
"Ardelean, Alexandru" wrote:
> On Tue, 2020-05-26 at 23:02 +0200, Rikard Falkeborn wrote:
> > [External]
> >
> > ad5592r_ext_info is not modified and can be made const to allow the
> > compiler to put it in read-only memory.
> >
> > Before:
> >textdata bss dec hex filename
> > 132932088 256 156373d15 drivers/iio/dac/ad5592r-base.o
> >
> > After:
> >textdata bss dec hex filename
> > 134211960 256 156373d15 drivers/iio/dac/ad5592r-base.o
> >
>
> Acked-by: Alexandru Ardelean
Applied.
Thanks
> > Signed-off-by: Rikard Falkeborn
> > ---
> > drivers/iio/dac/ad5592r-base.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/iio/dac/ad5592r-base.c b/drivers/iio/dac/ad5592r-
> > base.c
> > index 410e90e5f75f..7402f67a551d 100644
> > --- a/drivers/iio/dac/ad5592r-base.c
> > +++ b/drivers/iio/dac/ad5592r-base.c
> > @@ -484,7 +484,7 @@ static ssize_t ad5592r_show_scale_available(struct
> > iio_dev *iio_dev,
> > st->scale_avail[1][0], st->scale_avail[1][1]);
> > }
> >
> > -static struct iio_chan_spec_ext_info ad5592r_ext_info[] = {
> > +static const struct iio_chan_spec_ext_info ad5592r_ext_info[] = {
> > {
> > .name = "scale_available",
> > .read = ad5592r_show_scale_available,
Re: [PATCH 4/6] iio: dac: ad5686: Constify static struct iio_chan_spec
On Wed, 27 May 2020 04:50:46 +
"Ardelean, Alexandru" wrote:
> On Tue, 2020-05-26 at 23:02 +0200, Rikard Falkeborn wrote:
> > [External]
> >
> > These are never modified and can be made const to allow the compiler to
> > put it in read-only memory.
> >
> > Before:
> >textdata bss dec hex filename
> >6642 12608 64 193144b72 drivers/iio/dac/ad5686.o
> >
> > After:
> >textdata bss dec hex filename
> > 169462304 64 193144b72 drivers/iio/dac/ad5686.o
> >
>
> Acked-by: Alexandru Ardelean
>
Applied.
thanks,
> > Signed-off-by: Rikard Falkeborn
> > ---
> > drivers/iio/dac/ad5686.c | 8
> > drivers/iio/dac/ad5686.h | 2 +-
> > 2 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/iio/dac/ad5686.c b/drivers/iio/dac/ad5686.c
> > index 8dd67da0a7da..6de48f618c95 100644
> > --- a/drivers/iio/dac/ad5686.c
> > +++ b/drivers/iio/dac/ad5686.c
> > @@ -206,12 +206,12 @@ static const struct iio_chan_spec_ext_info
> > ad5686_ext_info[] = {
> > }
> >
> > #define DECLARE_AD5693_CHANNELS(name, bits, _shift)\
> > -static struct iio_chan_spec name[] = { \
> > +static const struct iio_chan_spec name[] = { \
> > AD5868_CHANNEL(0, 0, bits, _shift), \
> > }
> >
> > #define DECLARE_AD5686_CHANNELS(name, bits, _shift)\
> > -static struct iio_chan_spec name[] = { \
> > +static const struct iio_chan_spec name[] = { \
> > AD5868_CHANNEL(0, 1, bits, _shift), \
> > AD5868_CHANNEL(1, 2, bits, _shift), \
> > AD5868_CHANNEL(2, 4, bits, _shift), \
> > @@ -219,7 +219,7 @@ static struct iio_chan_spec name[] = {
> > \
> > }
> >
> > #define DECLARE_AD5676_CHANNELS(name, bits, _shift)\
> > -static struct iio_chan_spec name[] = { \
> > +static const struct iio_chan_spec name[] = { \
> > AD5868_CHANNEL(0, 0, bits, _shift), \
> > AD5868_CHANNEL(1, 1, bits, _shift), \
> > AD5868_CHANNEL(2, 2, bits, _shift), \
> > @@ -231,7 +231,7 @@ static struct iio_chan_spec name[] = {
> > \
> > }
> >
> > #define DECLARE_AD5679_CHANNELS(name, bits, _shift)\
> > -static struct iio_chan_spec name[] = { \
> > +static const struct iio_chan_spec name[] = { \
> > AD5868_CHANNEL(0, 0, bits, _shift), \
> > AD5868_CHANNEL(1, 1, bits, _shift), \
> > AD5868_CHANNEL(2, 2, bits, _shift), \
> > diff --git a/drivers/iio/dac/ad5686.h b/drivers/iio/dac/ad5686.h
> > index 52009b5eef88..a15f2970577e 100644
> > --- a/drivers/iio/dac/ad5686.h
> > +++ b/drivers/iio/dac/ad5686.h
> > @@ -104,7 +104,7 @@ typedef int (*ad5686_read_func)(struct ad5686_state
> > *st, u8 addr);
> > struct ad5686_chip_info {
> > u16 int_vref_mv;
> > unsigned intnum_channels;
> > - struct iio_chan_spec*channels;
> > + const struct iio_chan_spec *channels;
> > enum ad5686_regmap_type regmap_type;
> > };
> >
RE: [PATCH v2 1/5] scsi: ufs-mediatek: Fix imprecise waiting time for ref-clk control
Hi Avri,
On Sun, 2020-05-31 at 07:10 +, Avri Altman wrote:
> >
> > Currently ref-clk control timeout is implemented by Jiffies. However
> > jiffies is not accurate enough thus "false timeout" may happen.
> >
> > Use more accurate delay mechanism instead, for example, ktime.
> >
> > Signed-off-by: Stanley Chu
> > Reviewed-by: Andy Teng
> Reviewed-by: Avri Altman
>
Thanks for your review.
> >
> > /* Wait for ack */
> > - timeout = jiffies + msecs_to_jiffies(REFCLK_REQ_TIMEOUT_MS);
> > + timeout = ktime_add_us(ktime_get(), REFCLK_REQ_TIMEOUT_US);
> > do {
> > + time_checked = ktime_get();
> > value = ufshcd_readl(hba, REG_UFS_REFCLK_CTRL);
> >
> > /* Wait until ack bit equals to req bit */
> > @@ -144,7 +145,7 @@ static int ufs_mtk_setup_ref_clk(struct ufs_hba *hba,
> > bool on)
> > goto out;
> >
> > usleep_range(100, 200);
> > - } while (time_before(jiffies, timeout));
> > + } while (ktime_before(time_checked, timeout));
> Nit: you could get rid of time_checked if you would use
> ktime_compare(ktime_get(), timeout) > 0
>
> Thanks,
> Avri
If this context is preempted and scheduled out between ufshcd_readl()
and ktime_compare(ktime_get(), timeout), then the ktime_get() may get a
"timed-out" time even though the last ufshcd_readl() is actually
executed before the "timed-out" time. In this case, false alarm will
show up. Using "time_checked" here could solve above issue.
Thanks,
Stanley Chu
Re: [PATCH 2/6] iio: dac: ad5380: Constify struct iio_chan_spec_ext_info
On Wed, 27 May 2020 04:22:30 +
"Ardelean, Alexandru" wrote:
> On Tue, 2020-05-26 at 23:02 +0200, Rikard Falkeborn wrote:
> > [External]
> >
> > ad5380_ext_info is not modified and can be made const to allow the
> > compiler to put it in read-only memory.
> >
> > Before:
> >textdata bss dec hex filename
> > 120603280 192 155323cac drivers/iio/dac/ad5380.o
> >
> > After:
> >textdata bss dec hex filename
> > 122523088 192 155323cac drivers/iio/dac/ad5380.o
> >
>
> Acked-by: Alexandru Ardelean
>
Applied.
> > Signed-off-by: Rikard Falkeborn
> > ---
> > drivers/iio/dac/ad5380.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/iio/dac/ad5380.c b/drivers/iio/dac/ad5380.c
> > index b37e5675f716..04c74cc1a4ec 100644
> > --- a/drivers/iio/dac/ad5380.c
> > +++ b/drivers/iio/dac/ad5380.c
> > @@ -240,7 +240,7 @@ static const struct iio_info ad5380_info = {
> > .write_raw = ad5380_write_raw,
> > };
> >
> > -static struct iio_chan_spec_ext_info ad5380_ext_info[] = {
> > +static const struct iio_chan_spec_ext_info ad5380_ext_info[] = {
> > {
> > .name = "powerdown",
> > .read = ad5380_read_dac_powerdown,
Re: [PATCH v2 2/3] media: rockchip: Introduce driver for Rockhip's camera interface
Hi Maxime, Thanks for posting this patch. I think you can still improve it, but it's a neat first try! :-) On Fri, 29 May 2020 at 10:05, Maxime Chevallier wrote: > > Introduce a driver for the camera interface on some Rockchip platforms. > > This controller supports CSI2, Parallel and BT656 interfaces, but for > now only the parallel interface could be tested, hence it's the only one > that's supported in the first version of this driver. > I'm confused, you mention parallel as the only tested interface, but the cover letters mentions PAL. Doesn't PAL mean BT.656 or am I completely lost? (I am not super familiar with parallel sensors). > This controller can be fond on PX30, RK1808, RK3128, RK3288 and RK3288, > but for now it's only be tested on PX30. > My RK3288 and RK3326 (i.e. PX30) refer to this IP block as "Video Input interface". I am wondering if it won't be clearer for developers / users if we rename the driver to rockchip-vip (and of course s/cif/vip and s/CIF/VIP). > Most of this driver was written follwing the BSP driver from rockchip, > removing the parts that either didn't fit correctly the guidelines, or > that couldn't be tested. > > This basic version doesn't support cropping nor scaling, and is only > designed with one sensor being attached to it a any time. > > Signed-off-by: Maxime Chevallier > --- > > Changes since V1 : > > - Convert to the bulk APIs for clocks and resets Note that the bulk API clock conversion was not properly done. > - remove useless references to priv data > - Move around some init functions at probe time > - Upate some helpers to more suitable ones > > Here is the output from v4l2-compliance. There are no fails in the final > summary, but there is one in the output that I didn't catch previously. > > Still, here's the V2 in the meantime, if you have any further reviews > ompliance SHA: not available, 64 bits > > Compliance test for rkcif device /dev/video0: > > Driver Info: > Driver name : rkcif > Card type: rkcif > Bus info : platform:ff49.cif > Driver version : 5.7.0 > Capabilities : 0x84201000 > Video Capture Multiplanar > Streaming > Extended Pix Format > Device Capabilities > Device Caps : 0x04201000 > Video Capture Multiplanar > Streaming > Extended Pix Format > Media Driver Info: > Driver name : rkcif > Model: rkcif > Serial : > Bus info : > Media version: 5.7.0 > Hardware revision: 0x (0) > Driver version : 5.7.0 > Interface Info: > ID : 0x0302 > Type : V4L Video > Entity Info: > ID : 0x0001 (1) > Name : video_rkcif > Function : V4L2 I/O > Pad 0x0104 : 0: Sink > Link 0x0207: from remote pad 0x106 of entity 'tw9900 > 2-0044': Data, Enabled > > Required ioctls: > test MC information (see 'Media Driver Info' above): OK > test VIDIOC_QUERYCAP: OK > > Allow for multiple opens: > test second /dev/video0 open: OK > test VIDIOC_QUERYCAP: OK > test VIDIOC_G/S_PRIORITY: OK > test for unlimited opens: OK > > Debug ioctls: > test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) > test VIDIOC_LOG_STATUS: OK (Not Supported) > > Input ioctls: > test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) > test VIDIOC_ENUMAUDIO: OK (Not Supported) > test VIDIOC_G/S/ENUMINPUT: OK > test VIDIOC_G/S_AUDIO: OK (Not Supported) > Inputs: 1 Audio Inputs: 0 Tuners: 0 > > Output ioctls: > test VIDIOC_G/S_MODULATOR: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_ENUMAUDOUT: OK (Not Supported) > test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) > test VIDIOC_G/S_AUDOUT: OK (Not Supported) > Outputs: 0 Audio Outputs: 0 Modulators: 0 > > Input/Output configuration ioctls: > test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) > test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) > test VIDIOC_G/S_EDID: OK (Not Supported) > > Control ioctls (Input 0): > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK > test VIDIOC_QUERYCTRL: OK > test VIDIOC_G/S_CTRL: OK > test VIDIOC_G/S/TRY_EXT_CTRLS: OK > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) > Standard Controls: 0 Private Controls: 0 > > Format ioctls (Input 0): > test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS:
Re: [PATCH v2 4/4] docs: counter: Document character device interface
On Fri, May 29, 2020 at 03:26:04PM +0200, Pavel Machek wrote: > On Sat 2020-05-16 15:20:02, William Breathitt Gray wrote: > > This patch adds high-level documentation about the Counter subsystem > > character device interface. > > > > Signed-off-by: William Breathitt Gray > > --- > > Documentation/driver-api/generic-counter.rst | 112 +-- > > 1 file changed, 76 insertions(+), 36 deletions(-) > > > > diff --git a/Documentation/driver-api/generic-counter.rst > > b/Documentation/driver-api/generic-counter.rst > > index 8f85c30dea0b..58045b33b576 100644 > > --- a/Documentation/driver-api/generic-counter.rst > > +++ b/Documentation/driver-api/generic-counter.rst > > > + > > +Counter chrdev > > +-- > > +Translates counter data to the standard Counter character device; data > > +is transferred via standard character device read/write calls. > > + > > +Sysfs Interface > > +=== > > + > > +Several sysfs attributes are generated by the Generic Counter interface, > > +and reside under the `/sys/bus/counter/devices/counterX` directory, > > +where `X` is to the respective counter device id. Please see > > +Documentation/ABI/testing/sysfs-bus-counter for detailed information on > > +each Generic Counter interface sysfs attribute. > > + > > +Through these sysfs attributes, programs and scripts may interact with > > +the Generic Counter paradigm Counts, Signals, and Synapses of respective > > +counter devices. > > + > > +Counter Character Device > > + > > + > > +Counter character device nodes are created under the `/dev` directory as > > +`counterX`, where `X` is the respective counter device id. Defines for > > +the standard Counter data types are exposed via the userspace > > +`include/uapi/linux/counter-types.h` file. > > + > > +The first 196095 bytes of the character device serve as a control > > +selection area where control exposure of desired Counter components and > > +extensions may be selected. Each byte serves as a boolean selection > > +indicator for a respective Counter component or extension. The format of > > +this area is as follows: > > + > > +* For each device extension, a byte is required. > > +* For each Signal, a byte is reserved for the Signal component, and a > > + byte is reserved for each Signal extension. > > +* For each Count, a byte is reserved for the Count component, a byte is > > + reserved for the count function, a byte is reserved for each Synapse > > + action, and byte is reserved for each Count extension. > > + > > +The selected Counter components and extensions may then be interfaced > > +after the first 196095 bytes via standard character device read/write > > +operations. The number of bytes available for each component or > > +extension is dependent on their respective data type: u8 will have 1 > > +byte available, u64 will have 8 bytes available, strings will have 64 > > +bytes available, etc. > > This looks like very, very strange interface, and not described in detail > required to understand it. > > Could you take a look at input subsystem, /dev/input/event0? Perhaps it is > directly usable, and if not something similar should probably be acceptable. > > Best regards, > Pavel Yes, I don't think this is a good interface afterall. I'm implementing a different design for v3 that should be more intuitive. The input subsystem could be useful for streams of events such as timestamps, so I'll take a look at it as well in case something similar to it could be used. William Breathitt Gray signature.asc Description: PGP signature
Re: [PATCH] iio: accel: mxc4005: add support for mxc6655
Hi Jonathan,
I tested the sensor on a Chuwi Hi10 X and only went by what I've seen in other
commits before[1].
I just ran another test to see what entry is necessary and it appears the sensor
still works when removing the i2c entry, but is not working anymore when
removing the ACPI match. I got the ACPI IDs from udevadm info -e[2].
Would that mean, that I should remove the i2c entry given it's working fine
with ACPI on its own then, or am I missing something?
I'm also successfully using the ACPI ID for the touchscreen orientation quirk
in systemd[3].
> Adding an explicit DT binding table would also be
> good if that is method you are using to probe this (or PRP0001
> from acpi which uses the dt bindings table)
Frankly, I have no idea how to do that or if that would still be required when
using ACPI. Can you point me in a rough direction in case it's still needed?
Regards,
Christian
---
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/iio/accel/mxc6255.c?h=v5.6.15=06777c562a50a09c4a2becfb2bf63c762a45df17
[2]
P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:22/MXC6655:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:22/MXC6655:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:MXC6655:MXC6655:
E: USEC_INITIALIZED=5319671
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
P: /devices/pci:00/:00:16.0/i2c_designware.0/i2c-0/i2c-MXC6655:00
L: 0
E:
DEVPATH=/devices/pci:00/:00:16.0/i2c_designware.0/i2c-0/i2c-MXC6655:00
E: SUBSYSTEM=i2c
E: MODALIAS=acpi:MXC6655:MXC6655:
[3]
https://github.com/systemd/systemd/commit/5e0676c2cad60b1ea029b9bfb9737e1967abb93a
On Sun, May 31, 2020 at 12:30 PM Jonathan Cameron wrote:
>
> On Fri, 29 May 2020 22:05:49 +0200
> Christian Oder wrote:
>
> > The mxc6655 is fully working with the existing mxc4005 driver.
> > Add support for it.
> >
> > Signed-off-by: Christian Oder
>
> One query on ACPI bindings. What is there already may
> be missleading :(
>
>
> > ---
> > drivers/iio/accel/mxc4005.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/iio/accel/mxc4005.c b/drivers/iio/accel/mxc4005.c
> > index 3d5bea651923..3b8614352cb4 100644
> > --- a/drivers/iio/accel/mxc4005.c
> > +++ b/drivers/iio/accel/mxc4005.c
> > @@ -474,12 +474,14 @@ static int mxc4005_probe(struct i2c_client *client,
> >
> > static const struct acpi_device_id mxc4005_acpi_match[] = {
> > {"MXC4005", 0},
> > + {"MXC6655", 0},
>
> Do we have a reference for these ACPI bindings? While they may seem
> obvious, memsic don't have a registered PNP or ACPI ID that I can
> find. If these are in the wild (i.e. in shipping firmware) then we
> can take them as defacto bindings, otherwise we should avoid making
> them so by putting them in the driver.
>
> Quite a few similar bindings got in a while back that I should have
> noticed, but I wasn't so familiar with ACPI back then. Some
> scrubbing of these has gone on recently, but there are lots still
> left in IIO.
>
> If we aren't sure, then drop the ACPI addition and just leave the
> i2c one below. Adding an explicit DT binding table would also be
> good if that is method you are using to probe this (or PRP0001
> from acpi which uses the dt bindings table)
>
> Thanks,
>
> Jonathan
>
>
> > { },
> > };
> > MODULE_DEVICE_TABLE(acpi, mxc4005_acpi_match);
> >
> > static const struct i2c_device_id mxc4005_id[] = {
> > {"mxc4005", 0},
> > + {"mxc6655", 0},
> > { },
> > };
> > MODULE_DEVICE_TABLE(i2c, mxc4005_id);
>
[PATCH] drm/vkms: Optimize compute_crc(), blend()
Optimize looping pixels in compute_crc() and blend(). Calculate
src_offset in start of looping horizontally and increase it.
It's better than calculating in every pixels.
Cc: Rodrigo Siqueira
Cc: David Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Sidong Yang
---
drivers/gpu/drm/vkms/vkms_composer.c | 32 +++-
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 4af2f19480f4..9d2a765ca1fb 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -28,14 +28,14 @@ static uint32_t compute_crc(void *vaddr_out, struct
vkms_composer *composer)
u32 crc = 0;
for (i = y_src; i < y_src + h_src; ++i) {
- for (j = x_src; j < x_src + w_src; ++j) {
- src_offset = composer->offset
-+ (i * composer->pitch)
-+ (j * composer->cpp);
+ src_offset = composer->offset + (i * composer->pitch)
+ + (x_src * composer->cpp);
+ for (j = 0 ; j < w_src; ++j) {
/* XRGB format ignores Alpha channel */
memset(vaddr_out + src_offset + 24, 0, 8);
crc = crc32_le(crc, vaddr_out + src_offset,
sizeof(u32));
+ src_offset += composer->cpp;
}
}
@@ -61,7 +61,7 @@ static void blend(void *vaddr_dst, void *vaddr_src,
struct vkms_composer *dest_composer,
struct vkms_composer *src_composer)
{
- int i, j, j_dst, i_dst;
+ int i, j, i_dst;
int offset_src, offset_dst;
int x_src = src_composer->src.x1 >> 16;
@@ -73,21 +73,23 @@ static void blend(void *vaddr_dst, void *vaddr_src,
int w_dst = drm_rect_width(_composer->dst);
int y_limit = y_src + h_dst;
- int x_limit = x_src + w_dst;
- for (i = y_src, i_dst = y_dst; i < y_limit; ++i) {
- for (j = x_src, j_dst = x_dst; j < x_limit; ++j) {
- offset_dst = dest_composer->offset
-+ (i_dst * dest_composer->pitch)
-+ (j_dst++ * dest_composer->cpp);
- offset_src = src_composer->offset
-+ (i * src_composer->pitch)
-+ (j * src_composer->cpp);
+ for (i = y_src, i_dst = y_dst; i < y_limit; ++i, ++i_dst) {
+ offset_dst = dest_composer->offset
++ (i_dst * dest_composer->pitch)
++ (x_dst * dest_composer->cpp);
+ offset_src = src_composer->offset
++ (i * src_composer->pitch)
++ (x_src * src_composer->cpp);
+
+ for (j = 0; j < w_dst; ++j) {
memcpy(vaddr_dst + offset_dst,
vaddr_src + offset_src, sizeof(u32));
+
+ offset_dst += dest_composer->cpp;
+ offset_src += src_composer->cpp;
}
- i_dst++;
}
}
--
2.17.1
Re: [PATCH 01/27] vfs, afs, ext4: Make the inode hash table RCU searchable
On Fri, May 29, 2020 at 11:00:07PM +0100, David Howells wrote:
> @@ -1245,15 +1282,9 @@ static int test_inode_iunique(struct super_block *sb,
> unsigned long ino)
> struct inode *inode;
>
> spin_lock(_hash_lock);
> - hlist_for_each_entry(inode, b, i_hash) {
> - if (inode->i_ino == ino && inode->i_sb == sb) {
> - spin_unlock(_hash_lock);
> - return 0;
> - }
> - }
> + inode = __find_inode_by_ino_rcu(sb, b, ino);
> spin_unlock(_hash_lock);
> -
> - return 1;
> + return inode ? 0 : 1;
> }
Nit: that's really return !inode
> +/**
> + * find_inode_rcu - find an inode in the inode cache
> + * @sb: Super block of file system to search
> + * @hashval: Key to hash
> + * @test:Function to test match on an inode
> + * @data:Data for test function
> + *
> + * Search for the inode specified by @hashval and @data in the inode cache,
> + * where the helper function @test will return 0 if the inode does not match
> + * and 1 if it does. The @test function must be responsible for taking the
> + * i_lock spin_lock and checking i_state for an inode being freed or being
> + * initialized.
> + *
> + * If successful, this will return the inode for which the @test function
> + * returned 1 and NULL otherwise.
> + *
> + * The @test function is not permitted to take a ref on any inode presented
> + * unless the caller is holding the inode hashtable lock. It is also not
> + * permitted to sleep, since it may be called with the RCU read lock held.
> + *
> + * The caller must hold either the RCU read lock or the inode hashtable lock.
Just how could that caller be holding inode_hash_lock? It's static and IMO
should remain such - it's too low-level detail of fs/inode.c for having the
code outside play with it.
Require the caller to hold rcu_read_lock() and make "not permitted to take
a ref or sleep" unconditional.
> +struct inode *find_inode_rcu(struct super_block *sb, unsigned long hashval,
> + int (*test)(struct inode *, void *), void *data)
> +{
> + struct hlist_head *head = inode_hashtable + hash(sb, hashval);
> + struct inode *inode;
> +
> + RCU_LOCKDEP_WARN(!lockdep_is_held(_hash_lock) &&
> !rcu_read_lock_held(),
> + "suspicious find_inode_by_ino_rcu() usage");
... and modify that RCU_LOCKDEP_WARN (including the function name, preferably
;-)
> +
> + hlist_for_each_entry_rcu(inode, head, i_hash) {
> + if (inode->i_sb == sb &&
> + !(READ_ONCE(inode->i_state) & (I_FREEING | I_WILL_FREE)) &&
> + test(inode, data))
> + return inode;
> + }
> + return NULL;
> +}
> +EXPORT_SYMBOL(find_inode_rcu);
> +
> +/**
> + * find_inode_by_rcu - Find an inode in the inode cache
> + * @sb: Super block of file system to search
> + * @ino: The inode number to match
> + *
> + * Search for the inode specified by @hashval and @data in the inode cache,
> + * where the helper function @test will return 0 if the inode does not match
> + * and 1 if it does. The @test function must be responsible for taking the
> + * i_lock spin_lock and checking i_state for an inode being freed or being
> + * initialized.
> + *
> + * If successful, this will return the inode for which the @test function
> + * returned 1 and NULL otherwise.
> + *
> + * The @test function is not permitted to take a ref on any inode presented
> + * unless the caller is holding the inode hashtable lock. It is also not
> + * permitted to sleep, since it may be called with the RCU read lock held.
> + *
> + * The caller must hold either the RCU read lock or the inode hashtable lock.
> + */
Ditto.
> +struct inode *find_inode_by_ino_rcu(struct super_block *sb,
> + unsigned long ino)
> +{
> + struct hlist_head *head = inode_hashtable + hash(sb, ino);
> + struct inode *inode;
> +
> + RCU_LOCKDEP_WARN(!lockdep_is_held(_hash_lock) &&
> !rcu_read_lock_held(),
> + "suspicious find_inode_by_ino_rcu() usage");
> +
> + hlist_for_each_entry_rcu(inode, head, i_hash) {
> + if (inode->i_ino == ino &&
> + inode->i_sb == sb &&
> + !(READ_ONCE(inode->i_state) & (I_FREEING | I_WILL_FREE)))
> + return inode;
> + }
> + return NULL;
> +}
> +EXPORT_SYMBOL(find_inode_by_ino_rcu);
> @@ -1540,6 +1652,7 @@ static void iput_final(struct inode *inode)
> {
> struct super_block *sb = inode->i_sb;
> const struct super_operations *op = inode->i_sb->s_op;
> + unsigned long state;
> int drop;
>
> WARN_ON(inode->i_state & I_NEW);
> @@ -1555,16 +1668,20 @@ static void iput_final(struct inode *inode)
> return;
> }
>
> + state = READ_ONCE(inode->i_state);
> if (!drop) {
> - inode->i_state |= I_WILL_FREE;
> +
Re: [PATCH 1/6] iio: adc: max11100: Constify struct iio_chan_spec
On Tue, 26 May 2020 23:02:18 +0200
Rikard Falkeborn wrote:
> max11100_channels is not modified and can therefore be made const to
> allow the compiler to put it in read-only memory.
>
> Before:
>textdata bss dec hex filename
>37761168 049441350 drivers/iio/adc/max11100.o
>
> After:
>textdata bss dec hex filename
>3968 976 049441350 drivers/iio/adc/max11100.o
>
> Signed-off-by: Rikard Falkeborn
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/adc/max11100.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/adc/max11100.c b/drivers/iio/adc/max11100.c
> index 3440539cfdba..b121ca78f851 100644
> --- a/drivers/iio/adc/max11100.c
> +++ b/drivers/iio/adc/max11100.c
> @@ -37,7 +37,7 @@ struct max11100_state {
> u8 buffer[3] cacheline_aligned;
> };
>
> -static struct iio_chan_spec max11100_channels[] = {
> +static const struct iio_chan_spec max11100_channels[] = {
> { /* [0] */
> .type = IIO_VOLTAGE,
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
Re: [PATCH v2 10/12] iio: imu: inv_icm42600: add accurate timestamping
On Wed, 27 May 2020 20:57:09 +0200
Jean-Baptiste Maneyrol wrote:
> Add a timestamping mechanism for buffer that provides accurate
> event timestamps when using watermark. This mechanism estimates
> device internal clock by comparing FIFO interrupts delta time and
> device elapsed time computed by parsing FIFO data.
>
> Take interrupt timestamp in hard irq handler and add IIO device
> specific timestamp structures in device private allocation.
I haven't checked the maths or anything, but basic principle seems
sound. I'm wondering if we want to document somewhere what the
various ways we do this sort of timestamp generation are. They
give me a headache normally and it would be good to point people
to a reference. Still that's a job for another day.
I commented on the (lack) of need for force 8 byte alignment inline.
Jonathan
>
> Signed-off-by: Jean-Baptiste Maneyrol
> ---
> drivers/iio/imu/inv_icm42600/Makefile | 1 +
> drivers/iio/imu/inv_icm42600/inv_icm42600.h | 5 +
> .../iio/imu/inv_icm42600/inv_icm42600_accel.c | 40 +++-
> .../imu/inv_icm42600/inv_icm42600_buffer.c| 28 +++
> .../iio/imu/inv_icm42600/inv_icm42600_core.c | 17 +-
> .../iio/imu/inv_icm42600/inv_icm42600_gyro.c | 40 +++-
> .../imu/inv_icm42600/inv_icm42600_timestamp.c | 195 ++
> .../imu/inv_icm42600/inv_icm42600_timestamp.h | 85
> 8 files changed, 398 insertions(+), 13 deletions(-)
> create mode 100644 drivers/iio/imu/inv_icm42600/inv_icm42600_timestamp.c
> create mode 100644 drivers/iio/imu/inv_icm42600/inv_icm42600_timestamp.h
>
> diff --git a/drivers/iio/imu/inv_icm42600/Makefile
> b/drivers/iio/imu/inv_icm42600/Makefile
> index 0f49f6df3647..291714d9aa54 100644
> --- a/drivers/iio/imu/inv_icm42600/Makefile
> +++ b/drivers/iio/imu/inv_icm42600/Makefile
> @@ -6,6 +6,7 @@ inv-icm42600-y += inv_icm42600_gyro.o
> inv-icm42600-y += inv_icm42600_accel.o
> inv-icm42600-y += inv_icm42600_temp.o
> inv-icm42600-y += inv_icm42600_buffer.o
> +inv-icm42600-y += inv_icm42600_timestamp.o
>
> obj-$(CONFIG_INV_ICM42600_I2C) += inv-icm42600-i2c.o
> inv-icm42600-i2c-y += inv_icm42600_i2c.o
> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> b/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> index 4d5811562a61..2de0dd7675fb 100644
> --- a/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> @@ -126,6 +126,7 @@ struct inv_icm42600_suspended {
> * @indio_accel:accelerometer IIO device.
> * @buffer: data transfer buffer aligned for DMA.
> * @fifo: FIFO management structure.
> + * @timestamp: interrupt timestamps.
> */
> struct inv_icm42600_state {
> struct mutex lock;
> @@ -141,6 +142,10 @@ struct inv_icm42600_state {
> struct iio_dev *indio_accel;
> uint8_t buffer[2] cacheline_aligned;
> struct inv_icm42600_fifo fifo;
> + struct {
> + int64_t gyro;
> + int64_t accel;
> + } timestamp;
> };
>
> /* Virtual register addresses: @bank on MSB (4 upper bits), @address on LSB
> */
> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c
> b/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c
> index c73ce204efc6..ec1d124c1471 100644
> --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c
> +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c
> @@ -17,6 +17,7 @@
> #include "inv_icm42600.h"
> #include "inv_icm42600_temp.h"
> #include "inv_icm42600_buffer.h"
> +#include "inv_icm42600_timestamp.h"
>
> #define INV_ICM42600_ACCEL_CHAN(_modifier, _index, _ext_info)
> \
> { \
> @@ -50,6 +51,7 @@ enum inv_icm42600_accel_scan {
> INV_ICM42600_ACCEL_SCAN_Y,
> INV_ICM42600_ACCEL_SCAN_Z,
> INV_ICM42600_ACCEL_SCAN_TEMP,
> + INV_ICM42600_ACCEL_SCAN_TIMESTAMP,
> };
>
> static const struct iio_chan_spec_ext_info inv_icm42600_accel_ext_infos[] = {
> @@ -65,13 +67,15 @@ static const struct iio_chan_spec
> inv_icm42600_accel_channels[] = {
> INV_ICM42600_ACCEL_CHAN(IIO_MOD_Z, INV_ICM42600_ACCEL_SCAN_Z,
> inv_icm42600_accel_ext_infos),
> INV_ICM42600_TEMP_CHAN(INV_ICM42600_ACCEL_SCAN_TEMP),
> + IIO_CHAN_SOFT_TIMESTAMP(INV_ICM42600_ACCEL_SCAN_TIMESTAMP),
> };
>
> -/* IIO buffer data: 8 bytes */
> +/* IIO buffer data: 16 bytes */
> struct inv_icm42600_accel_buffer {
> struct inv_icm42600_fifo_sensor_data accel;
> int8_t temp;
> uint8_t padding;
> + int64_t timestamp;
So this falls into the open question I have in the cleanup set on timestamp
alignment. What you have here guarantees that we have the correct spacing, but
it allows the alignment of the whole structure to be 4 bytes on x86_32
I don't 'think' that's a problem because the relevant unaligned 8 bytes write
and read should be fine at 4 byte alignment. Most other archs will
do 8 byte
Re: [PATCH 1/2] mm/gup: introduce pin_user_pages_locked()
Acked-by: Pankaj Gupta
On Thu, 28 May 2020 at 00:32, John Hubbard wrote:
>
> Introduce pin_user_pages_locked(), which is nearly identical to
> get_user_pages_locked() except that it sets FOLL_PIN and rejects
> FOLL_GET.
>
> Signed-off-by: John Hubbard
> ---
> include/linux/mm.h | 2 ++
> mm/gup.c | 30 ++
> 2 files changed, 32 insertions(+)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 98be7289d7e9..d16951087c93 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1700,6 +1700,8 @@ long pin_user_pages(unsigned long start, unsigned long
> nr_pages,
> struct vm_area_struct **vmas);
> long get_user_pages_locked(unsigned long start, unsigned long nr_pages,
> unsigned int gup_flags, struct page **pages, int *locked);
> +long pin_user_pages_locked(unsigned long start, unsigned long nr_pages,
> + unsigned int gup_flags, struct page **pages, int *locked);
> long get_user_pages_unlocked(unsigned long start, unsigned long nr_pages,
> struct page **pages, unsigned int gup_flags);
> long pin_user_pages_unlocked(unsigned long start, unsigned long nr_pages,
> diff --git a/mm/gup.c b/mm/gup.c
> index 2f0a0b497c23..17418a949067 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -2992,3 +2992,33 @@ long pin_user_pages_unlocked(unsigned long start,
> unsigned long nr_pages,
> return get_user_pages_unlocked(start, nr_pages, pages, gup_flags);
> }
> EXPORT_SYMBOL(pin_user_pages_unlocked);
> +
> +/*
> + * pin_user_pages_locked() is the FOLL_PIN variant of
> get_user_pages_locked().
> + * Behavior is the same, except that this one sets FOLL_PIN and rejects
> + * FOLL_GET.
> + */
> +long pin_user_pages_locked(unsigned long start, unsigned long nr_pages,
> + unsigned int gup_flags, struct page **pages,
> + int *locked)
> +{
> + /*
> +* FIXME: Current FOLL_LONGTERM behavior is incompatible with
> +* FAULT_FLAG_ALLOW_RETRY because of the FS DAX check requirement on
> +* vmas. As there are no users of this flag in this call we simply
> +* disallow this option for now.
> +*/
> + if (WARN_ON_ONCE(gup_flags & FOLL_LONGTERM))
> + return -EINVAL;
> +
> + /* FOLL_GET and FOLL_PIN are mutually exclusive. */
> + if (WARN_ON_ONCE(gup_flags & FOLL_GET))
> + return -EINVAL;
> +
> + gup_flags |= FOLL_PIN;
> + return __get_user_pages_locked(current, current->mm, start, nr_pages,
> + pages, NULL, locked,
> + gup_flags | FOLL_TOUCH);
> +}
> +EXPORT_SYMBOL(pin_user_pages_locked);
> +
> --
> 2.26.2
>
>
Re: [PATCH] mm/gup: documentation fix for pin_user_pages*() APIs
Acked-by: Pankaj Gupta
Re: [PATCH RFC] seccomp: Implement syscall isolation based on memory areas
On 5/31/20 03:59, Andy Lutomirski wrote: > > I’m suggesting that the kernel learn how to help you, maybe like this: > > prctl(PR_SET_SYSCALL_THUNK, target, address_of_unredirected_syscall, 0, 0, 0, > 0); > > This would be inherited on clone/fork and cleared on execve. > If we are talking about explicit specification of syscall addresses to be trapped by Wine, the problem here is that we don't have any way of knowing the exact addresses of syscalls to be redirected. We would need some way to find those syscalls in the highly obfuscated dynamically generated code, the whole purpose of which is to prevent disassembling, debugging and finding things like that in it. What we do know is that if a syscall is executed from any memory which Wine allocates for Windows application then it should be treated as Windows syscall and routed to the Wine's dispatch function. Those code areas can be dynamically allocated and deallocated. If we are talking about explicit specification of syscall addresses not to be trapped, it might be technically possible but at the moment looks so messy so might be considered not feasible. Wine has a great number of external dependencies. Most of them depends on some other libraries in turn. Loading of those libraries goes out of Wine control. Linux libraries are allowed to issue direct syscalls from their code. I am not sure we can depend on them not doing it and always calling the same glibc wrapper.
Re: [PATCH v2 09/12] iio: imu: inv_icm42600: add buffer support in iio devices
On Wed, 27 May 2020 20:57:08 +0200
Jean-Baptiste Maneyrol wrote:
> Add all FIFO parsing and reading functions. Add accel and gyro
> kfifo buffer and FIFO data parsing. Use device interrupt for
> reading data FIFO and launching accel and gyro parsing.
>
> Support hwfifo watermark by multiplexing gyro and accel settings.
> Support hwfifo flush.
Both of these are complex given the interactions of the two sensors
types and to be honest I couldn't figure out exactly what the intent was.
Needs more docs!
Thanks,
Jonathan
>
> Signed-off-by: Jean-Baptiste Maneyrol
> ---
> drivers/iio/imu/inv_icm42600/Kconfig | 1 +
> drivers/iio/imu/inv_icm42600/Makefile | 1 +
> drivers/iio/imu/inv_icm42600/inv_icm42600.h | 8 +
> .../iio/imu/inv_icm42600/inv_icm42600_accel.c | 160 -
> .../imu/inv_icm42600/inv_icm42600_buffer.c| 555 ++
> .../imu/inv_icm42600/inv_icm42600_buffer.h| 98
> .../iio/imu/inv_icm42600/inv_icm42600_core.c | 30 +
> .../iio/imu/inv_icm42600/inv_icm42600_gyro.c | 160 -
> 8 files changed, 1011 insertions(+), 2 deletions(-)
> create mode 100644 drivers/iio/imu/inv_icm42600/inv_icm42600_buffer.c
> create mode 100644 drivers/iio/imu/inv_icm42600/inv_icm42600_buffer.h
>
> diff --git a/drivers/iio/imu/inv_icm42600/Kconfig
> b/drivers/iio/imu/inv_icm42600/Kconfig
> index 22390a72f0a3..50cbcfcb6cf1 100644
> --- a/drivers/iio/imu/inv_icm42600/Kconfig
> +++ b/drivers/iio/imu/inv_icm42600/Kconfig
> @@ -2,6 +2,7 @@
>
> config INV_ICM42600
> tristate
> + select IIO_BUFFER
>
> config INV_ICM42600_I2C
> tristate "InvenSense ICM-426xx I2C driver"
> diff --git a/drivers/iio/imu/inv_icm42600/Makefile
> b/drivers/iio/imu/inv_icm42600/Makefile
> index 48965824f00c..0f49f6df3647 100644
> --- a/drivers/iio/imu/inv_icm42600/Makefile
> +++ b/drivers/iio/imu/inv_icm42600/Makefile
> @@ -5,6 +5,7 @@ inv-icm42600-y += inv_icm42600_core.o
> inv-icm42600-y += inv_icm42600_gyro.o
> inv-icm42600-y += inv_icm42600_accel.o
> inv-icm42600-y += inv_icm42600_temp.o
> +inv-icm42600-y += inv_icm42600_buffer.o
>
> obj-$(CONFIG_INV_ICM42600_I2C) += inv-icm42600-i2c.o
> inv-icm42600-i2c-y += inv_icm42600_i2c.o
> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> b/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> index 43749f56426c..4d5811562a61 100644
> --- a/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> @@ -14,6 +14,8 @@
> #include
> #include
>
> +#include "inv_icm42600_buffer.h"
> +
> enum inv_icm42600_chip {
> INV_CHIP_ICM42600,
> INV_CHIP_ICM42602,
> @@ -123,6 +125,7 @@ struct inv_icm42600_suspended {
> * @indio_gyro: gyroscope IIO device.
> * @indio_accel:accelerometer IIO device.
> * @buffer: data transfer buffer aligned for DMA.
> + * @fifo: FIFO management structure.
> */
> struct inv_icm42600_state {
> struct mutex lock;
> @@ -137,6 +140,7 @@ struct inv_icm42600_state {
> struct iio_dev *indio_gyro;
> struct iio_dev *indio_accel;
> uint8_t buffer[2] cacheline_aligned;
> + struct inv_icm42600_fifo fifo;
> };
>
> /* Virtual register addresses: @bank on MSB (4 upper bits), @address on LSB
> */
> @@ -377,6 +381,10 @@ int inv_icm42600_core_probe(struct regmap *regmap, int
> chip, int irq,
>
> int inv_icm42600_gyro_init(struct inv_icm42600_state *st);
>
> +int inv_icm42600_gyro_parse_fifo(struct iio_dev *indio_dev);
> +
> int inv_icm42600_accel_init(struct inv_icm42600_state *st);
>
> +int inv_icm42600_accel_parse_fifo(struct iio_dev *indio_dev);
> +
> #endif
> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c
> b/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c
> index 6a615d7ffb24..c73ce204efc6 100644
> --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c
> +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_accel.c
> @@ -11,9 +11,12 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "inv_icm42600.h"
> #include "inv_icm42600_temp.h"
> +#include "inv_icm42600_buffer.h"
>
> #define INV_ICM42600_ACCEL_CHAN(_modifier, _index, _ext_info)
> \
> { \
> @@ -64,6 +67,76 @@ static const struct iio_chan_spec
> inv_icm42600_accel_channels[] = {
> INV_ICM42600_TEMP_CHAN(INV_ICM42600_ACCEL_SCAN_TEMP),
> };
>
> +/* IIO buffer data: 8 bytes */
> +struct inv_icm42600_accel_buffer {
> + struct inv_icm42600_fifo_sensor_data accel;
> + int8_t temp;
> + uint8_t padding;
> +};
> +
> +#define INV_ICM42600_SCAN_MASK_ACCEL_3AXIS \
> + (BIT(INV_ICM42600_ACCEL_SCAN_X) | \
> + BIT(INV_ICM42600_ACCEL_SCAN_Y) |\
> + BIT(INV_ICM42600_ACCEL_SCAN_Z))
> +
> +#define INV_ICM42600_SCAN_MASK_TEMP BIT(INV_ICM42600_ACCEL_SCAN_TEMP)
> +
> +static const
Re: [PATCH] lib: make a test module with get_count_order/long
On Sun, May 31, 2020 at 12:56:29AM +0300, Andy Shevchenko wrote: >On Sun, May 31, 2020 at 12:23 AM Wei Yang wrote: >> On Sat, May 30, 2020 at 01:25:31PM +0300, Andy Shevchenko wrote: >> >On Sat, May 30, 2020 at 12:43:28AM +, Wei Yang wrote: >> >> A test module to make sure get_count_order/long returns the correct >> >> result. >> > >> >> lib/Kconfig.debug | 13 ++ >> >> lib/Makefile | 2 + >> >> lib/test_getorder.c| 64 ++ >> > >> >I didn't get why it's not a part of test_bitops? >> > >> >> I see the document of test_bitops says it does exercise on clear_bit and >> set_bit. So not sure it is proper to put them together. > >It's not a problem to amend a documentation as well :-) > Sure. I am fine with this. Andrew, do you expect me to merge it into test_bitops.c? >-- >With Best Regards, >Andy Shevchenko -- Wei Yang Help you, Help me
Re: [PATCH RFCv2 9/9] arm64: Support async page fault
On 2020-05-29 12:11, Paolo Bonzini wrote: On 29/05/20 11:41, Marc Zyngier wrote: For x86 the advantage is that the processor can take care of raising the stage2 page fault in the guest, so it's faster. I think there might be too much overhead if the page can be populated quickly by host. For example, it's fast to populate the pages if swapin isn't involved. Those would still be handled by the host. Only those that are not present in the host (which you can see through the MMU notifier) would be routed to the guest. You can do things differently between "not present fault because the page table does not exist" and "not present fault because the page is missing in the host". If I'm correct enough, it seems arm64 doesn't have similar mechanism, routing stage2 page fault to guest. Indeed, this isn't a thing on arm64. Exception caused by a S2 fault are always routed to EL2. Is there an ARM-approved way to reuse the S2 fault syndromes to detect async page faults? It would mean being able to set an ESR_EL2 register value into ESR_EL1, and there is nothing in the architecture that would allow that, with the exception of nested virt: a VHE guest hypervisor running at EL1 must be able to observe S2 faults for its own S2, as synthesized by the host hypervisor. The trouble is that: - there is so far no commercially available CPU supporting NV - even if you could get hold of such a machine, there is no guarantee that such "EL2 syndrome at EL1" is valid outside of the nested context - this doesn't solve the issue for non-NV CPUs anyway (By the way, another "modern" use for async page faults is for postcopy live migration). Right. That's definitely a more interesting version of "swap-in". M. -- Jazz is not dead. It just smells funny...
Re: [PATCH RFC] seccomp: Implement syscall isolation based on memory areas
Hi! thanks for looking into this. On 5/31/20 08:56, Gabriel Krisman Bertazi wrote: > >> Is it possible to disassemble and instrument the Windows code to insert >> breakpoints (or emulation calls) at all the Windows syscall points? > Hi Kees, > > I considered instrumenting the syscall instructions with calls to some > wrapper, but I was told that modifying the game in memory or on disk > will trigger all sorts of anti-cheating mechanisms (my main use case are > windows games). Yes, this is the case. Besides, before instrumenting, we would need some way to find those syscalls in the highly obfuscated dynamically generated code, the whole purpose of which is to prevent disassembling, debugging and finding things like that in it. Ultimately, even for the cases when it would be technically feasible I don't think Wine could ever go for modifying the program's code (unless of course this is the part of what the program is doing itself using winapi calls). Wine is trying to implement the API as close to Windows as possible so the DRM can work with Wine, modifying the program's code is something different. > >>> [...] >>> * Why not SECCOMP_MODE_FILTER? >>> >>> We experimented with dynamically generating BPF filters for whitelisted >>> memory regions and using SECCOMP_MODE_FILTER, but there are a few >>> reasons why it isn't enough nor a good idea for our use case: >>> >>> 1. We cannot set the filters at program initialization time and forget >>> about it, since there is no way of knowing which modules will be loaded, >>> whether native and windows. Filter would need a way to be updated >>> frequently during game execution. >>> >>> 2. We cannot predict which Linux libraries will issue syscalls directly. >>> Most of the time, whitelisting libc and a few other libraries is enough, >>> but there are no guarantees other Linux libraries won't issue syscalls >>> directly and break the execution. Adding every linux library that is >>> loaded also has a large performance cost due to the large resulting >>> filter. >> Just so I can understand the expected use: given the dynamic nature of >> the library loading, how would Wine be marking the VMAs? > Paul (cc'ed) is the wine expert, but my understanding is that memory > allocation and initial program load of the emulated binary will go > through wine. It does the allocation and mark the vma accordingly > before returning the allocated range to the windows application. Yes, exactly. Pretty much any memory allocation which Wine does needs syscalls (if those are ever encountered later during executing code from those areas) to be trapped by Wine and passed to Wine's implementation of the corresponding Windows API function. Linux native libraries loading and memory allocations performed by them go outside of Wine control. > >>> Indeed, points 1 and 2 could be worked around with some userspace work >>> and improved SECCOMP_MODE_FILTER support, but at a high performance and >>> some stability cost, to obtain the semantics we want. Still, the >>> performance would suffer, and SECCOMP_MODE_MEMMAP is non intrusive >>> enough that I believe it should be considered as an upstream solution. >> It looks like you're using SECCOMP_RET_TRAP for this? Signal handling >> can be pretty slow. Did you try SECCOMP_RET_USER_NOTIF? We are not much concerned with the overhead of the trapped syscall in our use case, those are very rare. What we are concerned with is the performance impact on the normal Linux syscalls when the syscall trapping is enabled. When I was measuring that impact I've got the same 10% overhead for the untrapped syscalls (that is, always hitting SECCOMP_RET_ALLOW case) with the filters Gabriel mentioned. >> >>> + >>> + if (!(vma->vm_flags & VM_NOSYSCALL)) >>> + return 0; >>> + >>> + syscall_rollback(current, task_pt_regs(current)); >>> + seccomp_send_sigsys(this_syscall, 0); >>> + >>> + seccomp_log(this_syscall, SIGSYS, SECCOMP_RET_TRAP, true); >>> + >>> + return -1; >>> +} >> This really just looks like an ip_address filter, but I get what you >> mean about stacking filters, etc. This may finally be the day we turn to >> eBPF in seccomp, since that would give you access to using a map lookup >> on ip_address, and the map could be updated externally (removing the >> need for the madvise() changes). > And 64-bit comparisons :) > > that would be a good solution, we'd still need to look at some details, > like disabling/updating filters at runtime when some new library is > loaded, but since we can update externally, I think it covers it. I am afraid that for a general case the filter add / update / removal should be done not just when a new library is loaded or unloaded but pretty much any time new (executable) memory region is allocated or deallocated, or PROT_EXEC should be changed on allocated pages . But I am not sure I've got enough details yet on the suggested approach here and might be missing important details. I guess maybe we could discuss
Re: [PATCH] MIPS: ralink: bootrom: mark a function as __init to save some memory
On Sun, May 31, 2020 at 12:06:03PM +0200, Christophe JAILLET wrote: > 'bootrom_setup()' is only called via 'postcore_initcall'. > It can be marked as __init to save a few bytes of memory. > > Signed-off-by: Christophe JAILLET > --- > arch/mips/ralink/bootrom.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied to mips-next. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH] MIPS: ralink: drop ralink_clk_init for mt7621
On Sat, Mar 28, 2020 at 12:14:57PM +0800, Chuanhong Guo wrote: > ralink_clk_init is only called in arch/mips/ralink/clk.c which isn't > compiled for mt7621. And it doesn't export a proper cpu clock. > Drop this unused function. > > Signed-off-by: Chuanhong Guo > --- > arch/mips/ralink/mt7621.c | 43 --- > 1 file changed, 43 deletions(-) applied to mips-next. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Re: [PATCH v8 0/3] perf arm-spe: Add support for synthetic events
Em Sat, May 30, 2020 at 08:24:39PM +0800, Leo Yan escreveu:
> This patch set is to support synthetic events with enabling Arm SPE
> decoder. This patch set is based Xiaojun Tan (Hisilicon) and
> James Clark (Arm)'s previous patches who have contributed much for
> the related task.
Applied, will push to tmp.perf/core, and then perf/core if all tests are
successful, Adrian, if you could provide an Acked-by: for the auxtrace
case, that would be good,
- Arnaldo
> This patch set has been checked with checkpatch.pl, though it leaves
> several warnings, but these warnings are deliberately kept after
> reviewing. Some warnings ask to add maintainer (so far it's not
> necessary), and some warnings complaint for patch 02 "perf auxtrace:
> Add four itrace options" for the text format, since need to keep the
> consistency with the same code format in the source code, this is why
> this patch doesn't get rid of checkpatch warnings.
>
> This patch set has been rebased on Perf tmp.perf/core branch with
> latest commit 9300acc6fed8 ("perf build: Add a LIBPFM4=1 build test
> entry"). The patches has been tested on Arm N1 machine (by James)
> and on Hisilicon D06 platform (by Leo).
>
> Changes from v7:
> * Added James's tested-by tags;
> * Rebased on Perf tmp.perf/core branch.
>
>
> Tan Xiaojun (3):
> perf tools: Move arm-spe-pkt-decoder.h/c to the new dir
> perf auxtrace: Add four itrace options
> perf arm-spe: Support synthetic events
>
> tools/perf/Documentation/itrace.txt | 6 +-
> tools/perf/util/Build | 2 +-
> tools/perf/util/arm-spe-decoder/Build | 1 +
> .../util/arm-spe-decoder/arm-spe-decoder.c| 219 +
> .../util/arm-spe-decoder/arm-spe-decoder.h| 82 ++
> .../arm-spe-pkt-decoder.c | 0
> .../arm-spe-pkt-decoder.h | 16 +
> tools/perf/util/arm-spe.c | 823 +-
> tools/perf/util/auxtrace.c| 17 +
> tools/perf/util/auxtrace.h| 15 +-
> 10 files changed, 1135 insertions(+), 46 deletions(-)
> create mode 100644 tools/perf/util/arm-spe-decoder/Build
> create mode 100644 tools/perf/util/arm-spe-decoder/arm-spe-decoder.c
> create mode 100644 tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
> rename tools/perf/util/{ => arm-spe-decoder}/arm-spe-pkt-decoder.c (100%)
> rename tools/perf/util/{ => arm-spe-decoder}/arm-spe-pkt-decoder.h (64%)
>
> --
> 2.17.1
>
--
- Arnaldo
Re: [PATCH 0/3] perf test: Unwind fixes
Em Sat, May 30, 2020 at 01:20:12AM -0700, Ian Rogers escreveu: > Fix stack frame count and memory sanitizer issues when running the > dwarf unwinding test with the elfutils/libdw unwinder (libunwind > disabled). Thanks, applied. > Ian Rogers (3): > tools compiler.h: Add attribute to disable tail calls > perf tests: Don't tail call optimize in unwind test > perf test: Initialize memory in dwarf-unwind > > tools/include/linux/compiler-gcc.h | 8 > tools/include/linux/compiler.h | 3 +++ > tools/perf/arch/x86/tests/dwarf-unwind.c | 8 > tools/perf/tests/dwarf-unwind.c | 11 ++- > 4 files changed, 25 insertions(+), 5 deletions(-) > > -- > 2.27.0.rc2.251.g90737beb825-goog > -- - Arnaldo
Re: [PATCH v2 08/12] iio: imu: inv_icm42600: add device interrupt
On Wed, 27 May 2020 20:57:07 +0200
Jean-Baptiste Maneyrol wrote:
> Add INT1 interrupt support. Support interrupt edge and level,
> active high or low. Push-pull or open-drain configurations.
>
> Interrupt will be used to read data from the FIFO.
>
> Signed-off-by: Jean-Baptiste Maneyrol
Some nitpicks inline - all cases where a blank line would slightly
help readability.
J
> ---
> drivers/iio/imu/inv_icm42600/inv_icm42600.h | 2 +-
> .../iio/imu/inv_icm42600/inv_icm42600_core.c | 96 ++-
> .../iio/imu/inv_icm42600/inv_icm42600_i2c.c | 3 +-
> .../iio/imu/inv_icm42600/inv_icm42600_spi.c | 3 +-
> 4 files changed, 100 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> b/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> index c534acae0308..43749f56426c 100644
> --- a/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> @@ -372,7 +372,7 @@ int inv_icm42600_set_temp_conf(struct inv_icm42600_state
> *st, bool enable,
> int inv_icm42600_debugfs_reg(struct iio_dev *indio_dev, unsigned int reg,
>unsigned int writeval, unsigned int *readval);
>
> -int inv_icm42600_core_probe(struct regmap *regmap, int chip,
> +int inv_icm42600_core_probe(struct regmap *regmap, int chip, int irq,
> inv_icm42600_bus_setup bus_setup);
>
> int inv_icm42600_gyro_init(struct inv_icm42600_state *st);
> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
> b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
> index e7f7835aca9b..246c1eb52231 100644
> --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
> +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
> @@ -9,8 +9,11 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -409,6 +412,79 @@ static int inv_icm42600_setup(struct inv_icm42600_state
> *st,
> return inv_icm42600_set_conf(st, hw->conf);
> }
>
> +static irqreturn_t inv_icm42600_irq_handler(int irq, void *_data)
> +{
> + struct inv_icm42600_state *st = _data;
> + struct device *dev = regmap_get_device(st->map);
> + unsigned int status;
> + int ret;
> +
> + mutex_lock(>lock);
> +
> + ret = regmap_read(st->map, INV_ICM42600_REG_INT_STATUS, );
> + if (ret)
> + goto out_unlock;
> +
> + /* FIFO full */
> + if (status & INV_ICM42600_INT_STATUS_FIFO_FULL)
> + dev_warn(dev, "FIFO full data lost!\n");
> +
> +out_unlock:
> + mutex_unlock(>lock);
> + return IRQ_HANDLED;
> +}
> +
> +/**
> + * inv_icm42600_irq_init() - initialize int pin and interrupt handler
> + * @st: driver internal state
> + * @irq: irq number
> + * @irq_type:irq trigger type
> + * @open_drain: true if irq is open drain, false for push-pull
> + *
> + * Returns 0 on success, a negative error code otherwise.
> + */
> +static int inv_icm42600_irq_init(struct inv_icm42600_state *st, int irq,
> + int irq_type, bool open_drain)
> +{
> + struct device *dev = regmap_get_device(st->map);
> + unsigned int val;
> + int ret;
> +
> + /* configure INT1 interrupt: default is active low on edge */
> + switch (irq_type) {
> + case IRQF_TRIGGER_RISING:
> + case IRQF_TRIGGER_HIGH:
> + val = INV_ICM42600_INT_CONFIG_INT1_ACTIVE_HIGH;
> + break;
> + default:
> + val = INV_ICM42600_INT_CONFIG_INT1_ACTIVE_LOW;
> + break;
> + }
blank line here
> + switch (irq_type) {
> + case IRQF_TRIGGER_LOW:
> + case IRQF_TRIGGER_HIGH:
> + val |= INV_ICM42600_INT_CONFIG_INT1_LATCHED;
> + break;
> + default:
> + break;
> + }
blank line here.
> + if (!open_drain)
> + val |= INV_ICM42600_INT_CONFIG_INT1_PUSH_PULL;
blank line here
> + ret = regmap_write(st->map, INV_ICM42600_REG_INT_CONFIG, val);
> + if (ret)
> + return ret;
> +
> + /* Deassert async reset for proper INT pin operation (cf datasheet) */
> + ret = regmap_update_bits(st->map, INV_ICM42600_REG_INT_CONFIG1,
> + INV_ICM42600_INT_CONFIG1_ASYNC_RESET, 0);
> + if (ret)
> + return ret;
> +
> + return devm_request_threaded_irq(dev, irq, NULL,
> + inv_icm42600_irq_handler, irq_type,
> + "inv_icm42600", st);
> +}
> +
> static int inv_icm42600_enable_regulator_vddio(struct inv_icm42600_state *st)
> {
> int ret;
> @@ -453,11 +529,14 @@ static void inv_icm42600_disable_pm(void *_data)
> pm_runtime_disable(dev);
> }
>
> -int inv_icm42600_core_probe(struct regmap *regmap, int chip,
> +int inv_icm42600_core_probe(struct regmap *regmap, int chip, int irq,
> inv_icm42600_bus_setup bus_setup)
> {
>
Re: next-20200515: Xorg killed due to "OOM"
On Thu 2020-05-28 14:07:50, Michal Hocko wrote: > On Thu 28-05-20 14:03:54, Pavel Machek wrote: > > On Thu 2020-05-28 11:05:17, Michal Hocko wrote: > > > On Tue 26-05-20 11:10:54, Pavel Machek wrote: > > > [...] > > > > [38617.276517] oom_reaper: reaped process 31769 (chromium), now > > > > anon-rss:0kB, file-rss:0kB, shmem-rss:7968kB > > > > [38617.277232] Xorg invoked oom-killer: gfp_mask=0x0(), order=0, > > > > oom_score_adj=0 > > > > [38617.277247] CPU: 0 PID: 2978 Comm: Xorg Not tainted > > > > 5.7.0-rc5-next-20200515+ #117 > > > > [38617.277256] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW > > > > (2.19 ) 03/31/2011 > > > > [38617.277266] Call Trace: > > > > [38617.277286] dump_stack+0x54/0x6e > > > > [38617.277300] dump_header+0x45/0x321 > > > > [38617.277313] oom_kill_process.cold+0x9/0xe > > > > [38617.277324] ? out_of_memory+0x167/0x420 > > > > [38617.277336] out_of_memory+0x1f2/0x420 > > > > [38617.277348] pagefault_out_of_memory+0x34/0x56 > > > > [38617.277361] mm_fault_error+0x4a/0x130 > > > > [38617.277372] do_page_fault+0x3ce/0x416 > > > > > > The reason the OOM killer has been invoked is that the page fault > > > handler has returned VM_FAULT_OOM. So this is not a result of the page > > > allocator struggling to allocate a memory. It would be interesting to > > > check which code path has returned this. > > > > Should the core WARN_ON if that happens and there's enough memory, or > > something like that? > > I wish it would simply go away. There shouldn't be really any reason for > VM_FAULT_OOM to exist. The real low on memory situation is already > handled in the page allocator. Umm. Maybe the WARN_ON is first step in that direction? So we can see what driver actually did that, and complain to its authors? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: PGP signature
Re: drm/nouveau/clk/gm20b: Fix memory leaks after failed gk20a_clk_ctor() calls
> In this case, maybe we should check the return value of > gk20a_clk_ctor() and release clk if it returns -ENOMEM. All error situations (including failed memory allocations) can matter here. > And many other functions also have the same issue > (e.g. gm20b_clk_new_speedo0). I recommend to increase the error detection and improve the desired exception handling accordingly. Regards, Markus
Re: [PATCH v2 04/12] iio: imu: inv_icm42600: add gyroscope IIO device
On Wed, 27 May 2020 20:57:03 +0200
Jean-Baptiste Maneyrol wrote:
> Add IIO device for gyroscope sensor with data polling interface.
> Attributes: raw, scale, sampling_frequency, calibbias.
>
> Gyroscope in low noise mode.
>
> Signed-off-by: Jean-Baptiste Maneyrol
Unusual to have a calibration offset specified in output units,
which contributes a lot of the complexity in here.
Normally those are strictly front end (output of some calibration DAC).
So if they have units (and often they don't) I'd expect them to be
the same as _raw.
We need to tidy up the docs on this though as it doesn't express
any sort of preference. It's hard to be specific as often the calibration
scales are defined - they are just like tweaking a POT on an analog
sensor board.
A few trivial other things inline, including a suggestion to modify
the layering of the driver a tiny bit during probe.
Thanks,
Jonathan
> ---
> drivers/iio/imu/inv_icm42600/inv_icm42600.h | 6 +
> .../iio/imu/inv_icm42600/inv_icm42600_core.c | 4 +
> .../iio/imu/inv_icm42600/inv_icm42600_gyro.c | 600 ++
> 3 files changed, 610 insertions(+)
> create mode 100644 drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c
>
> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> b/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> index 14c8ef152418..c1023d59b37b 100644
> --- a/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600.h
> @@ -120,6 +120,8 @@ struct inv_icm42600_suspended {
> * @orientation:sensor chip orientation relative to main hardware.
> * @conf: chip sensors configurations.
> * @suspended: suspended sensors configuration.
> + * @indio_gyro: gyroscope IIO device.
> + * @buffer: data transfer buffer aligned for DMA.
> */
> struct inv_icm42600_state {
> struct mutex lock;
> @@ -131,6 +133,8 @@ struct inv_icm42600_state {
> struct iio_mount_matrix orientation;
> struct inv_icm42600_conf conf;
> struct inv_icm42600_suspended suspended;
> + struct iio_dev *indio_gyro;
> + uint8_t buffer[2] cacheline_aligned;
> };
>
> /* Virtual register addresses: @bank on MSB (4 upper bits), @address on LSB
> */
> @@ -369,4 +373,6 @@ int inv_icm42600_debugfs_reg(struct iio_dev *indio_dev,
> unsigned int reg,
> int inv_icm42600_core_probe(struct regmap *regmap, int chip,
> inv_icm42600_bus_setup bus_setup);
>
> +int inv_icm42600_gyro_init(struct inv_icm42600_state *st);
> +
> #endif
> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
> b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
> index 81b171d6782c..dccb7bcc782e 100644
> --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
> +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
> @@ -510,6 +510,10 @@ int inv_icm42600_core_probe(struct regmap *regmap, int
> chip,
> if (ret)
> return ret;
>
> + ret = inv_icm42600_gyro_init(st);
> + if (ret)
> + return ret;
> +
> /* setup runtime power management */
> ret = pm_runtime_set_active(dev);
> if (ret)
> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c
> b/drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c
> new file mode 100644
> index ..9d9672989b23
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_gyro.c
> @@ -0,0 +1,600 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2020 Invensense, Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "inv_icm42600.h"
> +
> +#define INV_ICM42600_GYRO_CHAN(_modifier, _index, _ext_info) \
> + { \
> + .type = IIO_ANGL_VEL, \
> + .modified = 1, \
> + .channel2 = _modifier, \
> + .info_mask_separate = \
> + BIT(IIO_CHAN_INFO_RAW) |\
> + BIT(IIO_CHAN_INFO_CALIBBIAS), \
> + .info_mask_shared_by_type = \
> + BIT(IIO_CHAN_INFO_SCALE), \
> + .info_mask_shared_by_type_available = \
> + BIT(IIO_CHAN_INFO_SCALE) | \
> + BIT(IIO_CHAN_INFO_CALIBBIAS), \
> + .info_mask_shared_by_all = \
> + BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> + .info_mask_shared_by_all_available =\
> + BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> + .scan_index = _index,
[PATCH v3 1/4] seccomp: rename "usage" to "refs" and document
Naming the lifetime counter of a seccomp filter "usage" suggests a
little too strongly that its about tasks that are using this filter
while it also tracks other references such as the user notifier or
ptrace. This also updates the documentation to note this fact.
We'll be introducing an actual usage counter in a follow-up patch.
Cc: Tycho Andersen
Cc: Kees Cook
Cc: Matt Denton
Cc: Sargun Dhillon
Cc: Jann Horn
Cc: Chris Palmer
Cc: Aleksa Sarai
Cc: Robert Sesek
Cc: Jeffrey Vander Stoep
Cc: Linux Containers
Signed-off-by: Christian Brauner
---
/* v2 */
patch not present
/* v3 */
patch introduced
---
kernel/seccomp.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 55a6184f5990..0ba2d6d0800f 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -106,10 +106,11 @@ struct notification {
/**
* struct seccomp_filter - container for seccomp BPF programs
*
- * @usage: reference count to manage the object lifetime.
- * get/put helpers should be used when accessing an instance
- * outside of a lifetime-guarded section. In general, this
- * is only needed for handling filters shared across tasks.
+ * @refs: Reference count to manage the object lifetime.
+ * A filter's reference count is incremented for each directly
+ * attached task, once for the dependent filter, and if
+ * requested for the user notifier. When @refs reaches zero,
+ * the filter can be freed.
* @log: true if all actions except for SECCOMP_RET_ALLOW should be logged
* @prev: points to a previously installed, or inherited, filter
* @prog: the BPF program to evaluate
@@ -124,10 +125,10 @@ struct notification {
* how namespaces work.
*
* seccomp_filter objects should never be modified after being attached
- * to a task_struct (other than @usage).
+ * to a task_struct (other than @refs).
*/
struct seccomp_filter {
- refcount_t usage;
+ refcount_t refs;
bool log;
struct seccomp_filter *prev;
struct bpf_prog *prog;
@@ -461,7 +462,7 @@ static struct seccomp_filter *seccomp_prepare_filter(struct
sock_fprog *fprog)
return ERR_PTR(ret);
}
- refcount_set(>usage, 1);
+ refcount_set(>refs, 1);
return sfilter;
}
@@ -554,7 +555,7 @@ static long seccomp_attach_filter(unsigned int flags,
static void __get_seccomp_filter(struct seccomp_filter *filter)
{
- refcount_inc(>usage);
+ refcount_inc(>refs);
}
/* get_seccomp_filter - increments the reference count of the filter on @tsk */
@@ -577,7 +578,7 @@ static inline void seccomp_filter_free(struct
seccomp_filter *filter)
static void __put_seccomp_filter(struct seccomp_filter *orig)
{
/* Clean up single-reference branches iteratively. */
- while (orig && refcount_dec_and_test(>usage)) {
+ while (orig && refcount_dec_and_test(>refs)) {
struct seccomp_filter *freeme = orig;
orig = orig->prev;
seccomp_filter_free(freeme);
base-commit: b9bbe6ed63b2b9f2c9ee5cbd0f2c946a2723f4ce
--
2.26.2
[PATCH v3 4/4] tests: test seccomp filter notifications
This verifies we're correctly notified when a seccomp filter becomes
unused when a notifier is in use.
Signed-off-by: Christian Brauner
---
/* v2 */
unchanged
/* v3 */
At first it seemed sensible to add POLLHUP to all poll invocations but
all checks test for revents to be equal to POLLIN. Hence, when POLLHUP
is reported we'd fail the test so we don't gain anyhing by testing for
POLLHUP additionally.
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 136 ++
1 file changed, 136 insertions(+)
diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
b/tools/testing/selftests/seccomp/seccomp_bpf.c
index c0aa46ce14f6..4dae278cf77e 100644
--- a/tools/testing/selftests/seccomp/seccomp_bpf.c
+++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
@@ -51,6 +51,7 @@
#include
#include "../kselftest_harness.h"
+#include "../clone3/clone3_selftests.h"
#ifndef PR_SET_PTRACER
# define PR_SET_PTRACER 0x59616d61
@@ -3686,6 +3687,141 @@ TEST(user_notification_continue)
}
}
+TEST(user_notification_filter_empty)
+{
+ pid_t pid;
+ long ret;
+ int status;
+ struct pollfd pollfd;
+ struct clone_args args = {
+ .flags = CLONE_FILES,
+ .exit_signal = SIGCHLD,
+ };
+
+ ret = prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
+ ASSERT_EQ(0, ret) {
+ TH_LOG("Kernel does not support PR_SET_NO_NEW_PRIVS!");
+ }
+
+ pid = sys_clone3(, sizeof(args));
+ ASSERT_GE(pid, 0);
+
+ if (pid == 0) {
+ int listener;
+
+ listener = user_trap_syscall(__NR_mknod,
SECCOMP_FILTER_FLAG_NEW_LISTENER);
+ if (listener < 0)
+ _exit(EXIT_FAILURE);
+
+ if (dup2(listener, 200) != 200)
+ _exit(EXIT_FAILURE);
+
+ close(listener);
+
+ _exit(EXIT_SUCCESS);
+ }
+
+ EXPECT_EQ(waitpid(pid, , 0), pid);
+ EXPECT_EQ(true, WIFEXITED(status));
+ EXPECT_EQ(0, WEXITSTATUS(status));
+
+ /*
+* The seccomp filter has become unused so we should be notified once
+* the kernel gets around to cleaning up task struct.
+*/
+ pollfd.fd = 200;
+ pollfd.events = POLLHUP;
+
+ EXPECT_GT(poll(, 1, -1), 0);
+ EXPECT_GT((pollfd.revents & POLLHUP) ?: 0, 0);
+}
+
+static void *do_thread(void *data)
+{
+ return NULL;
+}
+
+TEST(user_notification_filter_empty_threaded)
+{
+ pid_t pid;
+ long ret;
+ int status;
+ struct pollfd pollfd;
+ struct clone_args args = {
+ .flags = CLONE_FILES,
+ .exit_signal = SIGCHLD,
+ };
+
+ ret = prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
+ ASSERT_EQ(0, ret) {
+ TH_LOG("Kernel does not support PR_SET_NO_NEW_PRIVS!");
+ }
+
+ pid = sys_clone3(, sizeof(args));
+ ASSERT_GE(pid, 0);
+
+ if (pid == 0) {
+ pid_t pid1, pid2;
+ int listener, status;
+ pthread_t thread;
+
+ listener = user_trap_syscall(__NR_dup,
SECCOMP_FILTER_FLAG_NEW_LISTENER);
+ if (listener < 0)
+ _exit(EXIT_FAILURE);
+
+ if (dup2(listener, 200) != 200)
+ _exit(EXIT_FAILURE);
+
+ close(listener);
+
+ pid1 = fork();
+ if (pid1 < 0)
+ _exit(EXIT_FAILURE);
+
+ if (pid1 == 0)
+ _exit(EXIT_SUCCESS);
+
+ pid2 = fork();
+ if (pid2 < 0)
+ _exit(EXIT_FAILURE);
+
+ if (pid2 == 0)
+ _exit(EXIT_SUCCESS);
+
+ if (pthread_create(, NULL, do_thread, NULL) ||
+ pthread_join(thread, NULL))
+ _exit(EXIT_FAILURE);
+
+ if (pthread_create(, NULL, do_thread, NULL) ||
+ pthread_join(thread, NULL))
+ _exit(EXIT_FAILURE);
+
+ if (waitpid(pid1, , 0) != pid1 || !WIFEXITED(status) ||
+ WEXITSTATUS(status))
+ _exit(EXIT_FAILURE);
+
+ if (waitpid(pid2, , 0) != pid2 || !WIFEXITED(status) ||
+ WEXITSTATUS(status))
+ _exit(EXIT_FAILURE);
+
+ exit(EXIT_SUCCESS);
+ }
+
+ EXPECT_EQ(waitpid(pid, , 0), pid);
+ EXPECT_EQ(true, WIFEXITED(status));
+ EXPECT_EQ(0, WEXITSTATUS(status));
+
+ /*
+* The seccomp filter has become unused so we should be notified once
+* the kernel gets around to cleaning up task struct.
+*/
+ pollfd.fd = 200;
+ pollfd.events = POLLHUP;
+
+ EXPECT_GT(poll(, 1, -1), 0);
+ EXPECT_GT((pollfd.revents & POLLHUP) ?: 0, 0);
+}
+
/*
* TODO:
* - add microbenchmarks
--
2.26.2
[PATCH v3 2/4] seccomp: release filter after task is fully dead
The seccomp filter used to be released in free_task() which is called
asynchronously via call_rcu() and assorted mechanisms. Since we need
to inform tasks waiting on the seccomp notifier when a filter goes empty
we will notify them as soon as a task has been marked fully dead in
release_task(). To not split seccomp cleanup into two parts, move
filter release out of free_task() and into release_task() after we've
unhashed struct task from struct pid, exited signals, and unlinked it
from the threadgroups' thread list. We'll put the empty filter
notification infrastructure into it in a follow up patch.
This also renames put_seccomp_filter() to seccomp_filter_release() which
is a more descriptive name of what we're doing here especially once
we've added the empty filter notification mechanism in there.
We're also NULL-ing the task's filter tree entrypoint which seems
cleaner than leaving a dangling pointer in there. Note that this shouldn't
need any memory barriers since we're calling this when the task is in
release_task() which means it's EXIT_DEAD. So it can't modify it's seccomp
filters anymore. You can also see this from the point where we're calling
seccomp_filter_release(). It's after __exit_signal() and at this point,
tsk->sighand will already have been NULLed which is required for
thread-sync and filter installation alike.
Cc: Tycho Andersen
Cc: Kees Cook
Cc: Matt Denton
Cc: Sargun Dhillon
Cc: Jann Horn
Cc: Chris Palmer
Cc: Aleksa Sarai
Cc: Robert Sesek
Cc: Jeffrey Vander Stoep
Cc: Linux Containers
Signed-off-by: Christian Brauner
---
/* v2 */
patch not present
/* v3 */
patch introduced
---
include/linux/seccomp.h | 4 +--
kernel/exit.c | 1 +
kernel/fork.c | 1 -
kernel/seccomp.c| 60 -
4 files changed, 38 insertions(+), 28 deletions(-)
diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
index 4192369b8418..1644922af19a 100644
--- a/include/linux/seccomp.h
+++ b/include/linux/seccomp.h
@@ -82,10 +82,10 @@ static inline int seccomp_mode(struct seccomp *s)
#endif /* CONFIG_SECCOMP */
#ifdef CONFIG_SECCOMP_FILTER
-extern void put_seccomp_filter(struct task_struct *tsk);
+extern void seccomp_filter_release(struct task_struct *tsk);
extern void get_seccomp_filter(struct task_struct *tsk);
#else /* CONFIG_SECCOMP_FILTER */
-static inline void put_seccomp_filter(struct task_struct *tsk)
+static inline void seccomp_filter_release(struct task_struct *tsk)
{
return;
}
diff --git a/kernel/exit.c b/kernel/exit.c
index ce2a75bc0ade..5490cc04f436 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -218,6 +218,7 @@ void release_task(struct task_struct *p)
}
write_unlock_irq(_lock);
+ seccomp_filter_release(p);
proc_flush_pid(thread_pid);
put_pid(thread_pid);
release_thread(p);
diff --git a/kernel/fork.c b/kernel/fork.c
index 48ed22774efa..b948a14da94f 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -471,7 +471,6 @@ void free_task(struct task_struct *tsk)
#endif
rt_mutex_debug_task_free(tsk);
ftrace_graph_exit_task(tsk);
- put_seccomp_filter(tsk);
arch_release_task_struct(tsk);
if (tsk->flags & PF_KTHREAD)
free_kthread_struct(tsk);
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 0ba2d6d0800f..55251b1fe03f 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -367,6 +367,40 @@ static inline pid_t seccomp_can_sync_threads(void)
return 0;
}
+static inline void seccomp_filter_free(struct seccomp_filter *filter)
+{
+ if (filter) {
+ bpf_prog_destroy(filter->prog);
+ kfree(filter);
+ }
+}
+
+static void __put_seccomp_filter(struct seccomp_filter *orig)
+{
+ /* Clean up single-reference branches iteratively. */
+ while (orig && refcount_dec_and_test(>refs)) {
+ struct seccomp_filter *freeme = orig;
+ orig = orig->prev;
+ seccomp_filter_free(freeme);
+ }
+}
+
+/**
+ * seccomp_filter_release - Detach the task from its filter tree
+ * and drop its reference count during
+ * exit.
+ *
+ * This function should only be called when the task is exiting as
+ * it detaches it from its filter tree.
+ */
+void seccomp_filter_release(struct task_struct *tsk)
+{
+ struct seccomp_filter *cur = tsk->seccomp.filter;
+
+ tsk->seccomp.filter = NULL;
+ __put_seccomp_filter(cur);
+}
+
/**
* seccomp_sync_threads: sets all threads to use current's filter
*
@@ -396,7 +430,7 @@ static inline void seccomp_sync_threads(unsigned long flags)
* current's path will hold a reference. (This also
* allows a put before the assignment.)
*/
- put_seccomp_filter(thread);
+ __put_seccomp_filter(thread->seccomp.filter);
smp_store_release(>seccomp.filter,
[PATCH v3 3/4] seccomp: notify about unused filter
We've been making heavy use of the seccomp notifier to intercept and
handle certain syscalls for containers. This patch allows a syscall
supervisor listening on a given notifier to be notified when a seccomp
filter has become unused.
A container is often managed by a singleton supervisor process the
so-called "monitor". This monitor process has an event loop which has
various event handlers registered. If the user specified a seccomp
profile that included a notifier for various syscalls then we also
register a seccomp notify even handler. For any container using a
separate pid namespace the lifecycle of the seccomp notifier is bound to
the init process of the pid namespace, i.e. when the init process exits
the filter must be unused.
If a new process attaches to a container we force it to assume a seccomp
profile. This can either be the same seccomp profile as the container
was started with or a modified one. If the attaching process makes use
of the seccomp notifier we will register a new seccomp notifier handler
in the monitor's event loop. However, when the attaching process exits
we can't simply delete the handler since other child processes could've
been created (daemons spawned etc.) that have inherited the seccomp
filter and so we need to keep the seccomp notifier fd alive in the event
loop. But this is problematic since we don't get a notification when the
seccomp filter has become unused and so we currently never remove the
seccomp notifier fd from the event loop and just keep accumulating fds
in the event loop. We've had this issue for a while but it has recently
become more pressing as more and larger users make use of this.
To fix this, we introduce a new "users" reference counter that tracks
any tasks and dependent filters making use of a filter. When a notifier is
registered waiting tasks will be notified that the filter is now empty by
receiving a (E)POLLHUP event.
The concept in this patch introduces is the same as for signal_struct,
i.e. reference counting for life-cycle management is decoupled from
reference counting taks using the object.
There's probably some trickery possible but the second counter is just
the correct way of doing this imho and has precedence. The patch also
lifts the waitqeue from struct notification into sruct seccomp_filter.
This is cleaner overall and let's us avoid having to take the notifier
mutex since we neither need to read nor modify the notifier specific
aspects of the seccomp filter. In the exit path I'd very much like to
avoid having to take the notifier mutex for each filter in the task's
filter hierarchy.
Cc: Tycho Andersen
Cc: Kees Cook
Cc: Matt Denton
Cc: Sargun Dhillon
Cc: Jann Horn
Cc: Chris Palmer
Cc: Aleksa Sarai
Cc: Robert Sesek
Cc: Jeffrey Vander Stoep
Cc: Linux Containers
Signed-off-by: Christian Brauner
---
/* v2 */
- Jann Horn :
- Use more descriptive instead of seccomp_filter_notify().
(I went with seccomp_filter_release().)
/* v3 */
- Kees Cook :
- Rename counter from "live" to "users".
---
kernel/seccomp.c | 68 +---
1 file changed, 53 insertions(+), 15 deletions(-)
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 55251b1fe03f..45244f1ba148 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -94,13 +94,11 @@ struct seccomp_knotif {
* filter->notify_lock.
* @next_id: The id of the next request.
* @notifications: A list of struct seccomp_knotif elements.
- * @wqh: A wait queue for poll.
*/
struct notification {
struct semaphore request;
u64 next_id;
struct list_head notifications;
- wait_queue_head_t wqh;
};
/**
@@ -116,6 +114,15 @@ struct notification {
* @prog: the BPF program to evaluate
* @notif: the struct that holds all notification related information
* @notify_lock: A lock for all notification-related accesses.
+ * @wqh: A wait queue for poll if a notifier is in use.
+ * @users: A filter's @users count is incremented for each directly
+ * attached task (filter installation, fork(), thread_sync),
+ *and once for the dependent filter (tracked in filter->prev).
+ *When it reaches zero it indicates that no direct or indirect
+ *users of that filter exist. No new tasks can get associated with
+ *this filter after reaching 0. The @users count is always smaller
+ *or equal to @refs. Hence, reaching 0 for @users does not mean
+ *the filter can be freed.
*
* seccomp_filter objects are organized in a tree linked via the @prev
* pointer. For any task, it appears to be a singly-linked list starting
@@ -134,6 +141,8 @@ struct seccomp_filter {
struct bpf_prog *prog;
struct notification *notif;
struct mutex notify_lock;
+ refcount_t users;
+ wait_queue_head_t wqh;
};
/* Limit any path through the tree to 256KB worth of instructions. */
@@ -375,6 +384,15 @@ static inline void seccomp_filter_free(struct
Re: [PATCH v2 02/12] iio: imu: inv_icm42600: add I2C driver for inv_icm42600 driver
On Wed, 27 May 2020 20:57:01 +0200
Jean-Baptiste Maneyrol wrote:
> Add I2C driver for InvenSense ICM-426xxx devices.
>
> Configure bus signal slew rates as indicated in the datasheet.
>
> Signed-off-by: Jean-Baptiste Maneyrol
Looks fine to me.
J
> ---
> .../iio/imu/inv_icm42600/inv_icm42600_i2c.c | 100 ++
> 1 file changed, 100 insertions(+)
> create mode 100644 drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c
>
> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c
> b/drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c
> new file mode 100644
> index ..4789cead23b3
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c
> @@ -0,0 +1,100 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2020 InvenSense, Inc.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "inv_icm42600.h"
> +
> +static int inv_icm42600_i2c_bus_setup(struct inv_icm42600_state *st)
> +{
> + unsigned int mask, val;
> + int ret;
> +
> + /* setup interface registers */
> + ret = regmap_update_bits(st->map, INV_ICM42600_REG_INTF_CONFIG6,
> + INV_ICM42600_INTF_CONFIG6_MASK,
> + INV_ICM42600_INTF_CONFIG6_I3C_EN);
> + if (ret)
> + return ret;
> +
> + ret = regmap_update_bits(st->map, INV_ICM42600_REG_INTF_CONFIG4,
> + INV_ICM42600_INTF_CONFIG4_I3C_BUS_ONLY, 0);
> + if (ret)
> + return ret;
> +
> + /* set slew rates for I2C and SPI */
> + mask = INV_ICM42600_DRIVE_CONFIG_I2C_MASK |
> +INV_ICM42600_DRIVE_CONFIG_SPI_MASK;
> + val = INV_ICM42600_DRIVE_CONFIG_I2C(INV_ICM42600_SLEW_RATE_12_36NS) |
> + INV_ICM42600_DRIVE_CONFIG_SPI(INV_ICM42600_SLEW_RATE_12_36NS);
> + ret = regmap_update_bits(st->map, INV_ICM42600_REG_DRIVE_CONFIG,
> + mask, val);
> + if (ret)
> + return ret;
> +
> + /* disable SPI bus */
> + return regmap_update_bits(st->map, INV_ICM42600_REG_INTF_CONFIG0,
> + INV_ICM42600_INTF_CONFIG0_UI_SIFS_CFG_MASK,
> +
> INV_ICM42600_INTF_CONFIG0_UI_SIFS_CFG_SPI_DIS);
> +}
> +
> +static int inv_icm42600_probe(struct i2c_client *client)
> +{
> + const void *match;
> + enum inv_icm42600_chip chip;
> + struct regmap *regmap;
> +
> + if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_I2C_BLOCK))
> + return -ENOTSUPP;
> +
> + match = device_get_match_data(>dev);
> + if (!match)
> + return -EINVAL;
> + chip = (enum inv_icm42600_chip)match;
> +
> + regmap = devm_regmap_init_i2c(client, _icm42600_regmap_config);
> + if (IS_ERR(regmap))
> + return PTR_ERR(regmap);
> +
> + return inv_icm42600_core_probe(regmap, chip,
> inv_icm42600_i2c_bus_setup);
> +}
> +
> +static const struct of_device_id inv_icm42600_of_matches[] = {
> + {
> + .compatible = "invensense,icm42600",
> + .data = (void *)INV_CHIP_ICM42600,
> + }, {
> + .compatible = "invensense,icm42602",
> + .data = (void *)INV_CHIP_ICM42602,
> + }, {
> + .compatible = "invensense,icm42605",
> + .data = (void *)INV_CHIP_ICM42605,
> + }, {
> + .compatible = "invensense,icm42622",
> + .data = (void *)INV_CHIP_ICM42622,
> + },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, inv_icm42600_of_matches);
> +
> +static struct i2c_driver inv_icm42600_driver = {
> + .driver = {
> + .name = "inv-icm42600-i2c",
> + .of_match_table = inv_icm42600_of_matches,
> + .pm = _icm42600_pm_ops,
> + },
> + .probe_new = inv_icm42600_probe,
> +};
> +module_i2c_driver(inv_icm42600_driver);
> +
> +MODULE_AUTHOR("InvenSense, Inc.");
> +MODULE_DESCRIPTION("InvenSense ICM-426xx I2C driver");
> +MODULE_LICENSE("GPL");
Re: [PATCH 5.6 086/126] virtio-balloon: Revert "virtio-balloon: Switch back to OOM handler for VIRTIO_BALLOON_F_DEFLATE_ON_OOM"
On Sun, May 31, 2020 at 05:18:06AM -0400, Michael S. Tsirkin wrote: > On Tue, May 26, 2020 at 08:53:43PM +0200, Greg Kroah-Hartman wrote: > > From: Michael S. Tsirkin > > > > [ Upstream commit 835a6a649d0dd1b1f46759eb60fff2f63ed253a7 ] > > > > This reverts commit 5a6b4cc5b7a1892a8d7f63d6cbac6e0ae2a9d031. > > > > It has been queued properly in the akpm tree, this version is just > > creating conflicts. > > > > Signed-off-by: Michael S. Tsirkin > > Signed-off-by: Sasha Levin > > I don't understand. How does this make sense in stable? > stable does not merge akpm does it? It does not make sense, and is queued up to be reverted in the next release. thanks, greg k-h
Re: [PATCH v2 01/12] iio: imu: inv_icm42600: add core of new inv_icm42600 driver
On Wed, 27 May 2020 20:57:00 +0200
Jean-Baptiste Maneyrol wrote:
> Core component of a new driver for InvenSense ICM-426xx devices.
> It includes registers definition, main probe/setup, and device
> utility functions.
>
> ICM-426xx devices are latest generation of 6-axis IMU,
> gyroscope+accelerometer and temperature sensor. This device
> includes a 2K FIFO, supports I2C/I3C/SPI, and provides
> intelligent motion features like pedometer, tilt detection,
> and tap detection.
>
> Signed-off-by: Jean-Baptiste Maneyrol
A few things inline.
Either I'm missing something or I'm guessing vddio is not controllable
on your test board.
> ---
> drivers/iio/imu/inv_icm42600/inv_icm42600.h | 372 ++
> .../iio/imu/inv_icm42600/inv_icm42600_core.c | 635 ++
> 2 files changed, 1007 insertions(+)
> create mode 100644 drivers/iio/imu/inv_icm42600/inv_icm42600.h
> create mode 100644 drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
>
...
> diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
> b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
> new file mode 100644
> index ..81b171d6782c
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_core.c
> +const struct iio_mount_matrix *
> +inv_icm42600_get_mount_matrix(const struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan)
> +{
> + const struct inv_icm42600_state *st =
> + iio_device_get_drvdata((struct iio_dev *)indio_dev);
If you review my patch to the core, I can get that applied and we can drop
the ugly cast from here!
Just waiting for someone to sanity check it.
> +
> + return >orientation;
> +}
...
> +/* Runtime suspend will turn off sensors that are enabled by iio devices. */
> +static int __maybe_unused inv_icm42600_runtime_suspend(struct device *dev)
> +{
> + struct inv_icm42600_state *st = dev_get_drvdata(dev);
> + int ret;
> +
> + mutex_lock(>lock);
> +
> + /* disable all sensors */
> + ret = inv_icm42600_set_pwr_mgmt0(st, INV_ICM42600_SENSOR_MODE_OFF,
> + INV_ICM42600_SENSOR_MODE_OFF, false,
> + NULL);
> + if (ret)
> + goto error_unlock;
> +
> + regulator_disable(st->vddio_supply);
Don't seem to turn this on again in runtime_resume..
Why? Definitely needs at least a comment.
> +
> +error_unlock:
> + mutex_unlock(>lock);
> + return ret;
> +}
> +
> +/* Sensors are enabled by iio devices, no need to turn them back on here. */
> +static int __maybe_unused inv_icm42600_runtime_resume(struct device *dev)
> +{
> + struct inv_icm42600_state *st = dev_get_drvdata(dev);
> + int ret;
> +
> + mutex_lock(>lock);
> +
> + ret = inv_icm42600_enable_regulator_vddio(st);
> +
> + mutex_unlock(>lock);
> + return ret;
> +}
> +
> +const struct dev_pm_ops inv_icm42600_pm_ops = {
> + SET_SYSTEM_SLEEP_PM_OPS(inv_icm42600_suspend, inv_icm42600_resume)
> + SET_RUNTIME_PM_OPS(inv_icm42600_runtime_suspend,
> +inv_icm42600_runtime_resume, NULL)
> +};
> +EXPORT_SYMBOL_GPL(inv_icm42600_pm_ops);
> +
> +MODULE_AUTHOR("InvenSense, Inc.");
> +MODULE_DESCRIPTION("InvenSense ICM-426xx device driver");
> +MODULE_LICENSE("GPL");
Re: [PATCH v2] iio: mma8452: Add missed iio_device_unregister() call in mma8452_probe()
On Thu, 28 May 2020 14:41:21 +0800
Chuhong Yuan wrote:
> The function iio_device_register() was called in mma8452_probe().
> But the function iio_device_unregister() was not called after
> a call of the function mma8452_set_freefall_mode() failed.
> Thus add the missed function call for one error case.
>
> Fixes: 1a965d405fc6 ("drivers:iio:accel:mma8452: added cleanup provision in
> case of failure.")
> Signed-off-by: Chuhong Yuan
Applied to the fixes-togreg branch of iio.git
> ---
> Changes in v2:
> - Add fixes tag.
> - Modify description.
>
> drivers/iio/accel/mma8452.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 00e100fc845a..813bca7cfc3e 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -1685,10 +1685,13 @@ static int mma8452_probe(struct i2c_client *client,
>
> ret = mma8452_set_freefall_mode(data, false);
> if (ret < 0)
> - goto buffer_cleanup;
> + goto unregister_device;
>
> return 0;
>
> +unregister_device:
> + iio_device_unregister(indio_dev);
> +
> buffer_cleanup:
> iio_triggered_buffer_cleanup(indio_dev);
>
[tip:x86/entry 2/19] include/xen/interface/hvm/hvm_op.h:33:28: error: a parameter list without types is only allowed in a function definition
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/entry
head: 5980d208e5ef28455e9e8b08f6250b443a2f0893
commit: 28447ea4154239025044381144f849ff749ee9ef [2/19] xen: Move
xen_setup_callback_vector() definition to include/xen/hvm.h
config: x86_64-randconfig-r036-20200531 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
2388a096e7865c043e83ece4e26654bd3d1a20d5)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git checkout 28447ea4154239025044381144f849ff749ee9ef
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All error/warnings (new ones prefixed by >>, old ones prefixed by <<):
In file included from arch/x86/xen/suspend_hvm.c:5:
In file included from include/xen/hvm.h:6:
In file included from include/xen/interface/hvm/params.h:24:
include/xen/interface/hvm/hvm_op.h:29:5: error: unknown type name 'domid_t'
domid_t domid;/* IN */
^
>> include/xen/interface/hvm/hvm_op.h:33:1: warning: declaration specifier
>> missing, defaulting to 'int'
DEFINE_GUEST_HANDLE_STRUCT(xen_hvm_param);
^
int
>> include/xen/interface/hvm/hvm_op.h:33:28: error: a parameter list without
>> types is only allowed in a function definition
DEFINE_GUEST_HANDLE_STRUCT(xen_hvm_param);
^
include/xen/interface/hvm/hvm_op.h:39:5: error: unknown type name 'domid_t'
domid_t domid;
^
include/xen/interface/hvm/hvm_op.h:44:1: warning: declaration specifier
missing, defaulting to 'int'
DEFINE_GUEST_HANDLE_STRUCT(xen_hvm_pagetable_dying_t);
^
int
include/xen/interface/hvm/hvm_op.h:56:5: error: unknown type name 'domid_t'
domid_t domid;
^
include/xen/interface/hvm/hvm_op.h:63:1: warning: declaration specifier
missing, defaulting to 'int'
DEFINE_GUEST_HANDLE_STRUCT(xen_hvm_get_mem_type);
^
int
include/xen/interface/hvm/hvm_op.h:63:28: error: a parameter list without types
is only allowed in a function definition
DEFINE_GUEST_HANDLE_STRUCT(xen_hvm_get_mem_type);
^
3 warnings and 5 errors generated.
vim +33 include/xen/interface/hvm/hvm_op.h
18f19aa62a267f Jeremy Fitzhardinge 2010-05-14 23
18f19aa62a267f Jeremy Fitzhardinge 2010-05-14 24 /* Get/set subcommands: the
second argument of the hypercall is a
18f19aa62a267f Jeremy Fitzhardinge 2010-05-14 25 * pointer to a
xen_hvm_param struct. */
18f19aa62a267f Jeremy Fitzhardinge 2010-05-14 26 #define HVMOP_set_param
0
18f19aa62a267f Jeremy Fitzhardinge 2010-05-14 27 #define HVMOP_get_param
1
18f19aa62a267f Jeremy Fitzhardinge 2010-05-14 28 struct xen_hvm_param {
18f19aa62a267f Jeremy Fitzhardinge 2010-05-14 29 domid_t domid;/* IN
*/
18f19aa62a267f Jeremy Fitzhardinge 2010-05-14 30 uint32_t index;/* IN
*/
18f19aa62a267f Jeremy Fitzhardinge 2010-05-14 31 uint64_t value;/*
IN/OUT */
18f19aa62a267f Jeremy Fitzhardinge 2010-05-14 32 };
18f19aa62a267f Jeremy Fitzhardinge 2010-05-14 @33
DEFINE_GUEST_HANDLE_STRUCT(xen_hvm_param);
18f19aa62a267f Jeremy Fitzhardinge 2010-05-14 34
:: The code at line 33 was first introduced by commit
:: 18f19aa62a267f2f759e278018f1032adf4c3774 xen: Add support for HVM
hypercalls.
:: TO: Jeremy Fitzhardinge
:: CC: Jeremy Fitzhardinge
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] irqchip/gic-v3-its: Don't try to move a disabled irq
On 2020-05-30 17:49, Marc Zyngier wrote:
Hi Ali,
On Fri, 29 May 2020 12:36:42 +
"Saidi, Ali" wrote:
Hi Marc,
> On May 29, 2020, at 3:33 AM, Marc Zyngier wrote:
>
> Hi Ali,
>
>> On 2020-05-29 02:55, Ali Saidi wrote:
>> If an interrupt is disabled the ITS driver has sent a discard removing
>> the DeviceID and EventID from the ITT. After this occurs it can't be
>> moved to another collection with a MOVI and a command error occurs if
>> attempted. Before issuing the MOVI command make sure that the IRQ isn't
>> disabled and change the activate code to try and use the previous
>> affinity.
>>
>> Signed-off-by: Ali Saidi
>> ---
>> drivers/irqchip/irq-gic-v3-its.c | 18 +++---
>> 1 file changed, 15 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c
>> b/drivers/irqchip/irq-gic-v3-its.c
>> index 124251b0ccba..1235dd9a2fb2 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -1540,7 +1540,11 @@ static int its_set_affinity(struct irq_data *d,
>> const struct cpumask *mask_val,
>> /* don't set the affinity when the target cpu is same as current one
>> */
>> if (cpu != its_dev->event_map.col_map[id]) {
>> target_col = _dev->its->collections[cpu];
>> - its_send_movi(its_dev, target_col, id);
>> +
>> + /* If the IRQ is disabled a discard was sent so don't move */
>> + if (!irqd_irq_disabled(d))
>> + its_send_movi(its_dev, target_col, id);
>> +
>
> This looks wrong. What you are testing here is whether the interrupt
> is masked, not that there isn't a valid translation.
I’m not exactly sure the correct condition, but what I’m looking for
is interrupts which are deactivated and we have thus sent a discard.
That looks like IRQD_IRQ_STARTED not being set in this case.
>
> In the commit message, you're saying that we've issued a discard.
> This hints at doing a set_affinity on an interrupt that has been
> deactivated (mapping removed). Is that actually the case? If so,
> why was it deactivated
> the first place?
This is the case. If we down a NIC, that interface’s MSIs will be
deactivated but remain allocated until the device is unbound from the
driver or the NIC is brought up.
While stressing down/up a device I’ve found that irqbalance can move
interrupts and you end up with the situation described. The device is
downed, the interrupts are deactivated but still present and then
trying to move one results in sending a MOVI after the DISCARD which
is an error per the GIC spec.
Not great indeed. But this is not, as far as I can tell, a GIC
driver problem.
The semantic of activate/deactivate (which maps to started/shutdown
in the IRQ code) is that the HW resources for a given interrupt are
only committed when the interrupt is activated. Trying to perform
actions involving the HW on an interrupt that isn't active cannot be
guaranteed to take effect.
I'd rather address it in the core code, by preventing set_affinity (and
potentially others) to take place when the interrupt is not in the
STARTED state. Userspace would get an error, which is perfectly
legitimate, and which it already has to deal with it for plenty of
other
reasons.
How about this:
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 453a8a0f4804..1a2ac1392c0f 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -147,7 +147,8 @@ cpumask_var_t irq_default_affinity;
static bool __irq_can_set_affinity(struct irq_desc *desc)
{
if (!desc || !irqd_can_balance(>irq_data) ||
- !desc->irq_data.chip || !desc->irq_data.chip->irq_set_affinity)
+ !desc->irq_data.chip || !desc->irq_data.chip->irq_set_affinity ||
+ !irqd_is_started(>irq_data))
return false;
return true;
}
Thanks,
M.
--
Jazz is not dead. It just smells funny...
[PATCH] arm: allwinner: a20: Add Drejo DS167 initial support
From: Sertac TULLUK
Drejo DS167 is an Allwinner A20 based IoT device,
which support
- Allwinner A20 Cortex-A7
- Mali-400MP2 GPU
- AXP209 PMIC
- 1GB DDR3 RAM
- 8GB eMMC
- 10/100M Ethernet
- SATA
- HDMI
- 10.1inch and 7.0inch LVDS LCD and Touch screens
- CSI: OV5640 sensor
- USB OTG
- 2x USB2.0
- built-in KNX Transceiver
- 3x Dry Contact Input
- 3x Relay output
- IR RX/TX
- UART3
- SPI1
- RTC Battery
- 8x GPIO
- Analogue + Digital Microphone
- PAM8620 speaker Amplifier
- 12V DC power supply
- 3.7V Battery Operable
Signed-off-by: Sertac TULLUK
---
arch/arm/boot/dts/Makefile| 2 +
.../boot/dts/sun7i-a20-drejo-ds167-emmc.dts | 69 +
arch/arm/boot/dts/sun7i-a20-drejo-ds167.dts | 288 ++
3 files changed, 359 insertions(+)
create mode 100644 arch/arm/boot/dts/sun7i-a20-drejo-ds167-emmc.dts
create mode 100644 arch/arm/boot/dts/sun7i-a20-drejo-ds167.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 3823090d07e7..d81e685dee38 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1097,6 +1097,8 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-bananapro.dtb \
sun7i-a20-cubieboard2.dtb \
sun7i-a20-cubietruck.dtb \
+ sun7i-a20-drejo-ds167.dtb \
+sun7i-a20-drejo-ds167-emmc.dtb \
sun7i-a20-hummingbird.dtb \
sun7i-a20-itead-ibox.dtb \
sun7i-a20-i12-tvbox.dtb \
diff --git a/arch/arm/boot/dts/sun7i-a20-drejo-ds167-emmc.dts
b/arch/arm/boot/dts/sun7i-a20-drejo-ds167-emmc.dts
new file mode 100644
index ..b6147eb013b0
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-drejo-ds167-emmc.dts
@@ -0,0 +1,69 @@
+/*
+ * Copyright 2020 Sertac TULLUK
+ *
+ * Sertac TULLUK
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "sun7i-a20-drejo-ds167.dts"
+
+/ {
+ model = "drejo DS167-eMMC";
+ compatible = "drejo,sun7i-a20-drejo-ds167-emmc", "allwinner,sun7i-a20";
+
+ mmc2_pwrseq: pwrseq {
+ compatible = "mmc-pwrseq-emmc";
+ reset-gpios = < 2 24 GPIO_ACTIVE_LOW>;
+ };
+};
+
+ {
+ vmmc-supply = <_vcc3v3>;
+ bus-width = <4>;
+ non-removable;
+ mmc-pwrseq = <_pwrseq>;
+ status = "okay";
+
+ emmc: emmc@0 {
+ reg = <0>;
+ compatible = "mmc-card";
+ broken-hpi;
+ };
+};
diff --git a/arch/arm/boot/dts/sun7i-a20-drejo-ds167.dts
b/arch/arm/boot/dts/sun7i-a20-drejo-ds167.dts
new file mode 100644
index ..79db92f88251
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-drejo-ds167.dts
@@ -0,0 +1,288 @@
+/*
+ * Copyright 2020 Sertac TULLUK
+ *
+ * Sertac TULLUK
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the
Re: [PATCH v7 5/5] iio: magnetometer: ak8975: Add gpio reset support
On Thu, 28 May 2020 17:01:05 +0200
Jonathan Albrieux wrote:
> According to AK09911 datasheet, if reset gpio is provided then
> deassert reset on ak8975_power_on() and assert reset on ak8975_power_off().
>
> Without reset's deassertion during ak8975_power_on(), driver's probe fails
> on ak8975_who_i_am() while checking for device identity for AK09911 chip.
>
> AK09911 has an active low reset gpio to handle register's reset.
> AK09911 datasheet says that, if not used, reset pin should be connected
> to VID. This patch emulates this situation.
>
> Signed-off-by: Jonathan Albrieux
> Reviewed-by: Andy Shevchenko
> Reviewed-by: Stephan Gerhold
Applied. Thanks,
Jonathan
> ---
> drivers/iio/magnetometer/ak8975.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/iio/magnetometer/ak8975.c
> b/drivers/iio/magnetometer/ak8975.c
> index fd368455cd7b..a23422aad97d 100644
> --- a/drivers/iio/magnetometer/ak8975.c
> +++ b/drivers/iio/magnetometer/ak8975.c
> @@ -358,6 +358,7 @@ struct ak8975_data {
> u8 asa[3];
> longraw_to_gauss[3];
> struct gpio_desc*eoc_gpiod;
> + struct gpio_desc*reset_gpiod;
> int eoc_irq;
> wait_queue_head_t data_ready_queue;
> unsigned long flags;
> @@ -384,6 +385,9 @@ static int ak8975_power_on(const struct ak8975_data *data)
>"Failed to enable specified Vid supply\n");
> return ret;
> }
> +
> + gpiod_set_value_cansleep(data->reset_gpiod, 0);
> +
> /*
>* According to the datasheet the power supply rise time is 200us
>* and the minimum wait time before mode setting is 100us, in
> @@ -396,6 +400,8 @@ static int ak8975_power_on(const struct ak8975_data *data)
> /* Disable attached power regulator if any. */
> static void ak8975_power_off(const struct ak8975_data *data)
> {
> + gpiod_set_value_cansleep(data->reset_gpiod, 1);
> +
> regulator_disable(data->vid);
> regulator_disable(data->vdd);
> }
> @@ -839,6 +845,7 @@ static int ak8975_probe(struct i2c_client *client,
> struct ak8975_data *data;
> struct iio_dev *indio_dev;
> struct gpio_desc *eoc_gpiod;
> + struct gpio_desc *reset_gpiod;
> const void *match;
> unsigned int i;
> int err;
> @@ -856,6 +863,16 @@ static int ak8975_probe(struct i2c_client *client,
> if (eoc_gpiod)
> gpiod_set_consumer_name(eoc_gpiod, "ak_8975");
>
> + /*
> + * According to AK09911 datasheet, if reset GPIO is provided then
> + * deassert reset on ak8975_power_on() and assert reset on
> + * ak8975_power_off().
> + */
> + reset_gpiod = devm_gpiod_get_optional(>dev,
> + "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(reset_gpiod))
> + return PTR_ERR(reset_gpiod);
> +
> /* Register with IIO */
> indio_dev = devm_iio_device_alloc(>dev, sizeof(*data));
> if (indio_dev == NULL)
> @@ -866,6 +883,7 @@ static int ak8975_probe(struct i2c_client *client,
>
> data->client = client;
> data->eoc_gpiod = eoc_gpiod;
> + data->reset_gpiod = reset_gpiod;
> data->eoc_irq = 0;
>
> err = iio_read_mount_matrix(>dev, "mount-matrix",
> >orientation);
[PATCH] staging:rtl8712: avoid skb_clone after skb allocation fail
The skb allocated when out of memory is likely to be discarded
during subsequent processing.
Signed-off-by: Ivan Safonov
---
drivers/staging/rtl8712/rtl8712_recv.c | 29 ++
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl8712_recv.c
b/drivers/staging/rtl8712/rtl8712_recv.c
index 116773943a2e..570030be3077 100644
--- a/drivers/staging/rtl8712/rtl8712_recv.c
+++ b/drivers/staging/rtl8712/rtl8712_recv.c
@@ -1037,24 +1037,17 @@ static void recvbuf2recvframe(struct _adapter
*padapter, struct sk_buff *pskb)
*/
alloc_sz += 6;
pkt_copy = netdev_alloc_skb(padapter->pnetdev, alloc_sz);
- if (pkt_copy) {
- precvframe->u.hdr.pkt = pkt_copy;
- skb_reserve(pkt_copy, 4 - ((addr_t)(pkt_copy->data)
- % 4));
- skb_reserve(pkt_copy, shift_sz);
- memcpy(pkt_copy->data, pbuf, tmp_len);
- precvframe->u.hdr.rx_head = precvframe->u.hdr.rx_data =
-precvframe->u.hdr.rx_tail = pkt_copy->data;
- precvframe->u.hdr.rx_end = pkt_copy->data + alloc_sz;
- } else {
- precvframe->u.hdr.pkt = skb_clone(pskb, GFP_ATOMIC);
- if (!precvframe->u.hdr.pkt)
- return;
- precvframe->u.hdr.rx_head = pbuf;
- precvframe->u.hdr.rx_data = pbuf;
- precvframe->u.hdr.rx_tail = pbuf;
- precvframe->u.hdr.rx_end = pbuf + alloc_sz;
- }
+ if (!pkt_copy)
+ return;
+
+ precvframe->u.hdr.pkt = pkt_copy;
+ skb_reserve(pkt_copy, 4 - ((addr_t)(pkt_copy->data) % 4));
+ skb_reserve(pkt_copy, shift_sz);
+ memcpy(pkt_copy->data, pbuf, tmp_len);
+ precvframe->u.hdr.rx_head = precvframe->u.hdr.rx_data =
+ precvframe->u.hdr.rx_tail = pkt_copy->data;
+ precvframe->u.hdr.rx_end = pkt_copy->data + alloc_sz;
+
recvframe_put(precvframe, tmp_len);
recvframe_pull(precvframe, drvinfo_sz + RXDESC_SIZE);
/* because the endian issue, driver avoid reference to the
--
2.26.2
Re: [PATCH v7 4/5] iio: magnetometer: ak8975: Fix typo, uniform measurement unit style
On Thu, 28 May 2020 17:00:17 +0200 Jonathan Albrieux wrote: > Minor comment style edits. > > Signed-off-by: Jonathan Albrieux > Reviewed-by: Andy Shevchenko Applied > --- > drivers/iio/magnetometer/ak8975.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/iio/magnetometer/ak8975.c > b/drivers/iio/magnetometer/ak8975.c > index 3c881541ae72..fd368455cd7b 100644 > --- a/drivers/iio/magnetometer/ak8975.c > +++ b/drivers/iio/magnetometer/ak8975.c > @@ -385,9 +385,9 @@ static int ak8975_power_on(const struct ak8975_data *data) > return ret; > } > /* > - * According to the datasheet the power supply rise time i 200us > + * According to the datasheet the power supply rise time is 200us >* and the minimum wait time before mode setting is 100us, in > - * total 300 us. Add some margin and say minimum 500us here. > + * total 300us. Add some margin and say minimum 500us here. >*/ > usleep_range(500, 1000); > return 0;
Re: [PATCH v7 1/4] bitops: Introduce the the for_each_set_clump macro
On Sun, May 31, 2020 at 4:11 AM Syed Nayyar Waris wrote: > On Sat, May 30, 2020 at 2:50 PM Andy Shevchenko > wrote: > > On Sat, May 30, 2020 at 11:45 AM Syed Nayyar Waris > > wrote: > > > On Sat, May 30, 2020 at 3:49 AM Andy Shevchenko > > > wrote: ... > #if (l) == 0 > #define GENMASK_INPUT_CHECK(h, l) 0 > #elif > #define GENMASK_INPUT_CHECK(h, l) \ > (BUILD_BUG_ON_ZERO(__builtin_choose_expr( \ > __builtin_constant_p((l) > (h)), (l) > (h), 0))) > #endif > > I have verified that this works. Basically this just avoids the sanity > check when the 'lower' bound 'l' is zero. Let me know if it looks > fine. Unfortunately, it's not enough. We need to take care about the following cases 1) h or l negative; 2) h == 0, if l == 0, I dunno what is this. it's basically either 0 or warning; 3) l == 0; 4) h and l > 0. Now, on top of that (since it's a macro) we have to keep in mind that h and l can be signed and / or unsigned types. And macro shall work for all 4 cases (by type signedess). > Regarding min, max macro that you suggested I am also looking further into it. Since this has been introduced in v5.7 and not only your code is affected by this I think we need to ping original author either to fix or revert. So, I Cc'ed to the author and reviewers, because they probably know better why that had been done in the first place and breaking existing code. -- With Best Regards, Andy Shevchenko
Re: [PATCH v7 3/5] dt-bindings: iio: magnetometer: ak8975: add gpio reset support
On Thu, 28 May 2020 16:59:28 +0200
Jonathan Albrieux wrote:
> Add reset-gpio support.
>
> Without reset's deassertion during ak8975_power_on(), driver's probe fails
> on ak8975_who_i_am() while checking for device identity for AK09911 chip.
>
> AK09911 has an active low reset gpio to handle register's reset.
> AK09911 datasheet says that, if not used, reset pin should be connected
> to VID. This patch emulates this situation.
>
> Signed-off-by: Jonathan Albrieux
> Reviewed-by: Rob Herring
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
thanks,
Jonathan
> ---
> .../bindings/iio/magnetometer/asahi-kasei,ak8975.yaml | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git
> a/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
> b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
> index 55b18784e503..e8af53d60759 100644
> ---
> a/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
> +++
> b/Documentation/devicetree/bindings/iio/magnetometer/asahi-kasei,ak8975.yaml
> @@ -47,6 +47,11 @@ properties:
>mount-matrix:
> description: an optional 3x3 mounting rotation matrix.
>
> + reset-gpios:
> +description: |
> + an optional pin needed for AK09911 to set the reset state. This should
> + be usually active low
> +
> required:
>- compatible
>- reg
> @@ -54,6 +59,7 @@ required:
> examples:
>- |
> #include
> +#include
> i2c {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -64,6 +70,7 @@ examples:
> interrupt-parent = <>;
> interrupts = <15 IRQ_TYPE_EDGE_RISING>;
> vdd-supply = <_3v3_gnss>;
> +reset-gpios = < 111 GPIO_ACTIVE_LOW>;
> mount-matrix = "-0.984807753012208", /* x0 */
> "0", /* y0 */
> "-0.173648177666930", /* z0 */
[PATCH] arm64: debug: mark a function as __init to save some memory
'debug_monitors_init()' is only called via 'postcore_initcall'.
It can be marked as __init to save a few bytes of memory.
Signed-off-by: Christophe JAILLET
---
arch/arm64/kernel/debug-monitors.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/debug-monitors.c
b/arch/arm64/kernel/debug-monitors.c
index 15e80c876d46..5df49366e9ab 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -130,7 +130,7 @@ static int clear_os_lock(unsigned int cpu)
return 0;
}
-static int debug_monitors_init(void)
+static int __init debug_monitors_init(void)
{
return cpuhp_setup_state(CPUHP_AP_ARM64_DEBUG_MONITORS_STARTING,
"arm64/debug_monitors:starting",
--
2.25.1
Re: [PATCH V6 6/7] iio: adc: Update debug prints
On Thu, 28 May 2020 22:24:28 +0530
Jishnu Prakash wrote:
> Change pr_err/pr_debug statements to dev_err/dev_dbg for
> increased clarity.
>
> Signed-off-by: Jishnu Prakash
> Reviewed-by: Andy Shevchenko
Applied. Thanks, J
> ---
> drivers/iio/adc/qcom-spmi-adc5.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iio/adc/qcom-spmi-adc5.c
> b/drivers/iio/adc/qcom-spmi-adc5.c
> index 3022313..0f9af66 100644
> --- a/drivers/iio/adc/qcom-spmi-adc5.c
> +++ b/drivers/iio/adc/qcom-spmi-adc5.c
> @@ -246,11 +246,11 @@ static int adc5_read_voltage_data(struct adc5_chip
> *adc, u16 *data)
> *data = (rslt_msb << 8) | rslt_lsb;
>
> if (*data == ADC5_USR_DATA_CHECK) {
> - pr_err("Invalid data:0x%x\n", *data);
> + dev_err(adc->dev, "Invalid data:0x%x\n", *data);
> return -EINVAL;
> }
>
> - pr_debug("voltage raw code:0x%x\n", *data);
> + dev_dbg(adc->dev, "voltage raw code:0x%x\n", *data);
>
> return 0;
> }
> @@ -382,24 +382,24 @@ static int adc5_do_conversion(struct adc5_chip *adc,
>
> ret = adc5_configure(adc, prop);
> if (ret) {
> - pr_err("ADC configure failed with %d\n", ret);
> + dev_err(adc->dev, "ADC configure failed with %d\n", ret);
> goto unlock;
> }
>
> if (adc->poll_eoc) {
> ret = adc5_poll_wait_eoc(adc);
> if (ret) {
> - pr_err("EOC bit not set\n");
> + dev_err(adc->dev, "EOC bit not set\n");
> goto unlock;
> }
> } else {
> ret = wait_for_completion_timeout(>complete,
> ADC5_CONV_TIMEOUT);
> if (!ret) {
> - pr_debug("Did not get completion timeout.\n");
> + dev_dbg(adc->dev, "Did not get completion timeout.\n");
> ret = adc5_poll_wait_eoc(adc);
> if (ret) {
> - pr_err("EOC bit not set\n");
> + dev_err(adc->dev, "EOC bit not set\n");
> goto unlock;
> }
> }
> @@ -721,7 +721,7 @@ static int adc5_get_dt_channel_data(struct adc5_chip *adc,
> channel_name = of_get_property(node,
> "label", NULL) ? : node->name;
> if (!channel_name) {
> - pr_err("Invalid channel name\n");
> + dev_err(dev, "Invalid channel name\n");
> return -EINVAL;
> }
> prop->datasheet_name = channel_name;
> @@ -764,7 +764,7 @@ static int adc5_get_dt_channel_data(struct adc5_chip *adc,
> return ret;
> }
>
> - pr_debug("dig_ver:minor:%d, major:%d\n", dig_version[0],
> + dev_dbg(dev, "dig_ver:minor:%d, major:%d\n", dig_version[0],
> dig_version[1]);
> /* Digital controller >= 5.3 have hw_settle_2 option */
> if ((dig_version[0] >= ADC5_HW_SETTLE_DIFF_MINOR &&
> @@ -966,7 +966,7 @@ static int adc5_probe(struct platform_device *pdev)
>
> ret = adc5_get_dt_data(adc, node);
> if (ret) {
> - pr_err("adc get dt data failed\n");
> + dev_err(dev, "adc get dt data failed\n");
> return ret;
> }
>
Re: [PATCH v6 3/6] irqchip: RISC-V per-HART local interrupt controller driver
On 2020-05-31 11:06, Anup Patel wrote: On Sun, May 31, 2020 at 3:03 PM Marc Zyngier wrote: On 2020-05-31 06:36, Anup Patel wrote: > On Sat, May 30, 2020 at 5:31 PM Marc Zyngier wrote: [...] >> > plic_set_threshold(handler, PLIC_DISABLE_THRESHOLD); >> >> Why do you need to both disable the interrupt *and* change the >> priority >> threshold? It seems to be that one of them should be enough, but my >> kno9wledge of the PLIC is limited. In any case, this would deserve a >> comment. > > Okay, I will test and remove "disable the interrupt" part from > plic_dying_cpu(). Be careful, as interrupt enabling/disabling is refcounted in order to allow nesting. If you only enable on CPU_ON and not disable on CPU_OFF, you will end-up with a depth that only increases, up to the point where you hit the roof (it will take a while though). I would keep the enable/disable as is, and drop the priority setting from the CPU_OFF path. The PLIC threshold is like GICv2 CPU interface enable/disable. Looking at the documentation[1], that's not really a correct analogy: - The PLIC is far removed from the CPU, and is more akin a GICv3 distributor. The INTC itself is more like a GICv3 redistributor, as it deals with local interrupts only. I don't see anything in the RISC-V architecture that actually behaves like a GIC CPU interface (not necessarily a bad thing...). - The threshold register is not an ON/OFF, but a priority mask, similar to the GIC PMR (except that the PMR lives in the CPU interface and affects all interrupts targetting this CPU while this only seem to affect PLIC interrupts and not the INTC interrupts). You may be using it as an ON/OFF for now as you don't support multiple priorities yet, but that's just a SW thing. Based on your comment, we should only program the PLIC threshold in CPU_ON and don't touch the PLIC threshold in CPU_OFF. Right?? This seems like the correct thing to do. M. [1] https://sifive.cdn.prismic.io/sifive%2Fdc4980ff-17db-448b-b521-4c7ab26b7488_sifive+u54-mc+manual+v19.08.pdf -- Jazz is not dead. It just smells funny...
Re: [PATCH V6 7/7] iio: adc: Add a common read function for PMIC5 and PMIC7
On Thu, 28 May 2020 22:24:29 +0530
Jishnu Prakash wrote:
> Add a common function used for read_raw callback for both PMIC5
> and PMIC7 ADCs.
>
> Signed-off-by: Jishnu Prakash
Hmm. I'm not completely sold on this one. Suggestions below.
Jonathan
> ---
> drivers/iio/adc/qcom-spmi-adc5.c | 53
> +++-
> 1 file changed, 25 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/iio/adc/qcom-spmi-adc5.c
> b/drivers/iio/adc/qcom-spmi-adc5.c
> index 0f9af66..fe49741 100644
> --- a/drivers/iio/adc/qcom-spmi-adc5.c
> +++ b/drivers/iio/adc/qcom-spmi-adc5.c
> @@ -449,6 +449,13 @@ static int adc7_do_conversion(struct adc5_chip *adc,
> return ret;
> }
>
> +struct adc_do_conversion {
> + int (*adc_do_conversion)(struct adc5_chip *adc,
> + struct adc5_channel_prop *prop,
> + struct iio_chan_spec const *chan,
> + u16 *data_volt, u16 *data_cur);
Why use a structure for this? It's just a function pointer.
If they form is too long you can always use a typedef.
This is fine if you have other stuff coming shortly that will add
to this structure but for now it's just a bit confusing.
Directly passing the function pointer will reduce the amount
of coded added here and make the argument in favour of refactoring
rather stronger.
> +};
> +
> static irqreturn_t adc5_isr(int irq, void *dev_id)
> {
> struct adc5_chip *adc = dev_id;
> @@ -487,9 +494,9 @@ static int adc7_of_xlate(struct iio_dev *indio_dev,
> return -EINVAL;
> }
>
> -static int adc5_read_raw(struct iio_dev *indio_dev,
> +static int adc_read_raw_common(struct iio_dev *indio_dev,
>struct iio_chan_spec const *chan, int *val, int *val2,
> - long mask)
> + long mask, struct adc_do_conversion do_conv)
> {
> struct adc5_chip *adc = iio_priv(indio_dev);
> struct adc5_channel_prop *prop;
> @@ -500,8 +507,8 @@ static int adc5_read_raw(struct iio_dev *indio_dev,
>
> switch (mask) {
> case IIO_CHAN_INFO_PROCESSED:
> - ret = adc5_do_conversion(adc, prop, chan,
> - _code_volt, _code_cur);
> + ret = do_conv.adc_do_conversion(adc, prop, chan,
> + _code_volt, _code_cur);
> if (ret)
> return ret;
>
> @@ -518,36 +525,26 @@ static int adc5_read_raw(struct iio_dev *indio_dev,
> }
> }
>
> -static int adc7_read_raw(struct iio_dev *indio_dev,
> +static int adc5_read_raw(struct iio_dev *indio_dev,
>struct iio_chan_spec const *chan, int *val, int *val2,
>long mask)
> {
> - struct adc5_chip *adc = iio_priv(indio_dev);
> - struct adc5_channel_prop *prop;
> - u16 adc_code_volt, adc_code_cur;
> - int ret;
> -
> - prop = >chan_props[chan->address];
> -
> - switch (mask) {
> - case IIO_CHAN_INFO_PROCESSED:
> - ret = adc7_do_conversion(adc, prop, chan,
> - _code_volt, _code_cur);
> - if (ret)
> - return ret;
> + struct adc_do_conversion do_conv;
>
> - ret = qcom_adc5_hw_scale(prop->scale_fn_type,
> - _prescale_ratios[prop->prescale],
> - adc->data,
> - adc_code_volt, val);
> + do_conv.adc_do_conversion = adc5_do_conversion;
> + return adc_read_raw_common(indio_dev, chan, val, val2,
> + mask, do_conv);
> +}
>
> - if (ret)
> - return ret;
> +static int adc7_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int *val, int *val2,
> + long mask)
> +{
> + struct adc_do_conversion do_conv;
>
> - return IIO_VAL_INT;
> - default:
> - return -EINVAL;
> - }
> + do_conv.adc_do_conversion = adc7_do_conversion;
> + return adc_read_raw_common(indio_dev, chan, val, val2,
> + mask, do_conv);
> }
>
> static const struct iio_info adc5_info = {
Re: [PATCH] sh: Implement __get_user_u64() required for 64-bit get_user()
Hi Geert! Thanks a lot for the explanation! On 5/31/20 12:43 PM, Geert Uytterhoeven wrote: >> Hmm, this change is not the case for __put_user_asm() vs. __put_user_u64(). >> But I have to admit, I don't know what the part below "3:\n\t" is for. > > It's part of the exception handling, in case the passed (userspace) pointer > points to an inaccessible address, and triggers an exception. > > For an invalid store, nothing is done, besides returning -EFAULT. > Hence there's no "mov #0, %1\n\t" in the put_user case. I have replaced it with two individual mov's now as suggested since I now understand what's happening here. > For an invalid load, the data is replaced by zero, and -EFAULT is returned. > >> +__asm__ __volatile__( \ >> + "1:\n\t" \ >> + "mov.l %2,%R1\n\t" \ >> + "mov.l %T2,%S1\n\t" \ >> + "2:\n" \ > > (reordering the two sections for easier explanation) > >> + ".section __ex_table,\"a\"\n\t" \ >> + ".long 1b, 3b\n\t" \ > > In case an exception happens for the instruction at 1b, jump to 3b. > > Note that the m68k version has two entries here: one for each half of > the 64-bit access[*]. > I don't know if that is really needed (and thus SH needs it, too), or if > the exception code handles subsequent instructions automatically. Hmm. I assume this is something one of the SH maintainers or Yutaka Niibe can answer. >> + ".section .fixup,\"ax\"\n" \ >> + "3:\n\t" \ >> + "mov#0, %1\n\t" \ > > Return zero instead of the data at the (invalid) address. Makes sense. >> + "mov.l 4f, %0\n\t" \ >> + "jmp@%0\n\t" \ > > Resume at 2b. > Remember: branch delay slot, so the instruction below is executed first! I didn't even know that SH has delay slots. >> + " mov %3, %0\n\t" \ > > Set err to -EFAULT. Yes. >> + ".balign4\n" \ >> + "4: .long 2b\n\t" \ >> + ".previous\n" \ > >> + ".previous" \ >> + :"=" (err), "=" (x) \ >> + :"m" (__m(addr)), "i" (-EFAULT), "0" (err)); }) > > [*] arch/m68k/include/asm/uaccess_mm.h > > "1: "MOVES".l (%2)+,%1\n" \ > "2: "MOVES".l (%2),%R1\n" \ > > " .section __ex_table,\"a\"\n"\ > " .align 4\n"\ > " .long 1b,10b\n" \ > " .long 2b,10b\n" \ > Hmm. I'll wait for more feedback whether need to do the same as on m68k here. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[PATCH v2] sh: Implement __get_user_u64() required for 64-bit get_user()
Trying to build the kernel with CONFIG_INFINIBAND_USER_ACCESS enabled fails
ERROR: "__get_user_unknown" [drivers/infiniband/core/ib_uverbs.ko]
undefined!
with on SH since the kernel misses a 64-bit implementation of get_user().
Implement the missing 64-bit get_user() as __get_user_u64(), matching the
already existing __put_user_u64() which implements the 64-bit put_user().
Signed-off-by: John Paul Adrian Glaubitz
---
arch/sh/include/asm/uaccess_32.h | 51
1 file changed, 51 insertions(+)
Changes since v1:
- Replace single mov instruction for exception handling
in case of invalid load
diff --git a/arch/sh/include/asm/uaccess_32.h b/arch/sh/include/asm/uaccess_32.h
index 624cf55acc27..35f6c1e40ec3 100644
--- a/arch/sh/include/asm/uaccess_32.h
+++ b/arch/sh/include/asm/uaccess_32.h
@@ -26,6 +26,9 @@ do {
\
case 4: \
__get_user_asm(x, ptr, retval, "l");\
break; \
+ case 8: \
+ __get_user_u64(x, ptr, retval); \
+ break; \
default:\
__get_user_unknown(); \
break; \
@@ -66,6 +69,54 @@ do { \
extern void __get_user_unknown(void);
+#if defined(CONFIG_CPU_LITTLE_ENDIAN)
+#define __get_user_u64(x, addr, err) \
+({ \
+__asm__ __volatile__( \
+ "1:\n\t" \
+ "mov.l %2,%R1\n\t" \
+ "mov.l %T2,%S1\n\t" \
+ "2:\n" \
+ ".section .fixup,\"ax\"\n" \
+ "3:\n\t" \
+ "mov #0,%R1\n\t" \
+ "mov #0,%S1\n\t" \
+ "mov.l 4f, %0\n\t" \
+ "jmp@%0\n\t" \
+ " mov %3, %0\n\t" \
+ ".balign4\n" \
+ "4: .long 2b\n\t" \
+ ".previous\n" \
+ ".section __ex_table,\"a\"\n\t" \
+ ".long 1b, 3b\n\t" \
+ ".previous" \
+ :"=" (err), "=" (x) \
+ :"m" (__m(addr)), "i" (-EFAULT), "0" (err)); })
+#else
+#define __get_user_u64(x, addr, err) \
+({ \
+__asm__ __volatile__( \
+ "1:\n\t" \
+ "mov.l %2,%S1\n\t" \
+ "mov.l %T2,%R1\n\t" \
+ "2:\n" \
+ ".section .fixup,\"ax\"\n" \
+ "3:\n\t" \
+ "mov #0,%S1\n\t" \
+ "mov #0,%R1\n\t" \
+ "mov.l 4f, %0\n\t" \
+ "jmp@%0\n\t" \
+ " mov %3, %0\n\t" \
+ ".balign4\n" \
+ "4: .long 2b\n\t" \
+ ".previous\n" \
+ ".section __ex_table,\"a\"\n\t" \
+ ".long 1b, 3b\n\t" \
+ ".previous" \
+ :"=" (err), "=" (x) \
+ :"m" (__m(addr)), "i" (-EFAULT), "0" (err)); })
+#endif
+
#define __put_user_size(x,ptr,size,retval) \
do { \
retval = 0; \
--
2.27.0.rc2
Re: [PATCH V6 5/7] iio: adc: Update return value checks
On Thu, 28 May 2020 22:24:27 +0530
Jishnu Prakash wrote:
> Clean up some return value checks to make code more compact.
>
> Signed-off-by: Jishnu Prakash
Applied.
Thanks,
J
> ---
> drivers/iio/adc/qcom-spmi-adc5.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iio/adc/qcom-spmi-adc5.c
> b/drivers/iio/adc/qcom-spmi-adc5.c
> index dcc7599..3022313 100644
> --- a/drivers/iio/adc/qcom-spmi-adc5.c
> +++ b/drivers/iio/adc/qcom-spmi-adc5.c
> @@ -301,7 +301,7 @@ static int adc5_configure(struct adc5_chip *adc,
>
> /* Read registers 0x42 through 0x46 */
> ret = adc5_read(adc, ADC5_USR_DIG_PARAM, buf, sizeof(buf));
> - if (ret < 0)
> + if (ret)
> return ret;
>
> /* Digital param selection */
> @@ -388,7 +388,7 @@ static int adc5_do_conversion(struct adc5_chip *adc,
>
> if (adc->poll_eoc) {
> ret = adc5_poll_wait_eoc(adc);
> - if (ret < 0) {
> + if (ret) {
> pr_err("EOC bit not set\n");
> goto unlock;
> }
> @@ -398,7 +398,7 @@ static int adc5_do_conversion(struct adc5_chip *adc,
> if (!ret) {
> pr_debug("Did not get completion timeout.\n");
> ret = adc5_poll_wait_eoc(adc);
> - if (ret < 0) {
> + if (ret) {
> pr_err("EOC bit not set\n");
> goto unlock;
> }
> @@ -516,8 +516,6 @@ static int adc5_read_raw(struct iio_dev *indio_dev,
> default:
> return -EINVAL;
> }
> -
> - return 0;
> }
>
> static int adc7_read_raw(struct iio_dev *indio_dev,
> @@ -761,7 +759,7 @@ static int adc5_get_dt_channel_data(struct adc5_chip *adc,
>
> ret = adc5_read(adc, ADC5_USR_REVISION1, dig_version,
> sizeof(dig_version));
> - if (ret < 0) {
> + if (ret) {
> dev_err(dev, "Invalid dig version read %d\n", ret);
> return ret;
> }
Re: [PATCH V6 3/7] iio: adc: Add info property under adc_data
On Thu, 28 May 2020 22:24:25 +0530
Jishnu Prakash wrote:
> Add info property under adc_data to support adding ADC variants
> which may use different iio_info than the one defined for PMIC5.
>
> Signed-off-by: Jishnu Prakash
Applied.
Thanks,
Jonathan
> ---
> drivers/iio/adc/qcom-spmi-adc5.c | 4 +++-
> drivers/iio/adc/qcom-vadc-common.h | 1 +
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/adc/qcom-spmi-adc5.c
> b/drivers/iio/adc/qcom-spmi-adc5.c
> index 21fdcde..0fa1d37 100644
> --- a/drivers/iio/adc/qcom-spmi-adc5.c
> +++ b/drivers/iio/adc/qcom-spmi-adc5.c
> @@ -629,6 +629,7 @@ static const struct adc5_data adc5_data_pmic = {
> .full_scale_code_volt = 0x70e4,
> .full_scale_code_cur = 0x2710,
> .adc_chans = adc5_chans_pmic,
> + .info = _info,
> .decimation = (unsigned int [ADC5_DECIMATION_SAMPLES_MAX])
> {250, 420, 840},
> .hw_settle_1 = (unsigned int [VADC_HW_SETTLE_SAMPLES_MAX])
> @@ -643,6 +644,7 @@ static const struct adc5_data adc5_data_pmic_rev2 = {
> .full_scale_code_volt = 0x4000,
> .full_scale_code_cur = 0x1800,
> .adc_chans = adc5_chans_rev2,
> + .info = _info,
> .decimation = (unsigned int [ADC5_DECIMATION_SAMPLES_MAX])
> {256, 512, 1024},
> .hw_settle_1 = (unsigned int [VADC_HW_SETTLE_SAMPLES_MAX])
> @@ -777,7 +779,7 @@ static int adc5_probe(struct platform_device *pdev)
> indio_dev->dev.of_node = node;
> indio_dev->name = pdev->name;
> indio_dev->modes = INDIO_DIRECT_MODE;
> - indio_dev->info = _info;
> + indio_dev->info = adc->data->info;
> indio_dev->channels = adc->iio_chans;
> indio_dev->num_channels = adc->nchannels;
>
> diff --git a/drivers/iio/adc/qcom-vadc-common.h
> b/drivers/iio/adc/qcom-vadc-common.h
> index e074902a..6a7553f 100644
> --- a/drivers/iio/adc/qcom-vadc-common.h
> +++ b/drivers/iio/adc/qcom-vadc-common.h
> @@ -136,6 +136,7 @@ struct adc5_data {
> const u32 full_scale_code_volt;
> const u32 full_scale_code_cur;
> const struct adc5_channels *adc_chans;
> + const struct iio_info *info;
> unsigned int*decimation;
> unsigned int*hw_settle_1;
> unsigned int*hw_settle_2;
Re: [PATCH V6 4/7] iio: adc: Add support for PMIC7 ADC
On Thu, 28 May 2020 22:24:26 +0530
Jishnu Prakash wrote:
> The ADC architecture on PMIC7 is changed as compared to PMIC5. The
> major change from PMIC5 is that all SW communication to ADC goes through
> PMK8350, which communicates with other PMICs through PBS when the ADC
> on PMK8350 works in master mode. The SID register is used to identify the
> PMICs with which the PBS needs to communicate. Add support for the same.
>
> Signed-off-by: Jishnu Prakash
> Reviewed-by: Andy Shevchenko
one nitpick inline. But otherwise looks good to me.
Nitpick is trivial so I'll ignore it.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/adc/qcom-spmi-adc5.c | 215 +-
> drivers/iio/adc/qcom-vadc-common.c | 262
> +
> drivers/iio/adc/qcom-vadc-common.h | 14 ++
> 3 files changed, 488 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/adc/qcom-spmi-adc5.c
> b/drivers/iio/adc/qcom-spmi-adc5.c
> index 0fa1d37..dcc7599 100644
> --- a/drivers/iio/adc/qcom-spmi-adc5.c
> +++ b/drivers/iio/adc/qcom-spmi-adc5.c
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0
> /*
> - * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2018, 2020, The Linux Foundation. All rights reserved.
> */
>
> #include
> @@ -23,6 +23,7 @@
>
> #define ADC5_USR_REVISION1 0x0
> #define ADC5_USR_STATUS1 0x8
> +#define ADC5_USR_STATUS1_CONV_FAULT BIT(7)
> #define ADC5_USR_STATUS1_REQ_STS BIT(1)
> #define ADC5_USR_STATUS1_EOC BIT(0)
> #define ADC5_USR_STATUS1_REQ_STS_EOC_MASK0x3
> @@ -65,6 +66,9 @@
>
> #define ADC5_USR_IBAT_DATA1 0x53
>
> +#define ADC_CHANNEL_OFFSET 0x8
> +#define ADC_CHANNEL_MASK GENMASK(7, 0)
> +
> /*
> * Conversion time varies based on the decimation, clock rate, fast average
> * samples and measurements queued across different VADC peripherals.
> @@ -79,6 +83,11 @@
> #define ADC5_HW_SETTLE_DIFF_MINOR3
> #define ADC5_HW_SETTLE_DIFF_MAJOR5
>
> +/* For PMIC7 */
> +#define ADC_APP_SID 0x40
> +#define ADC_APP_SID_MASK GENMASK(3, 0)
> +#define ADC7_CONV_TIMEOUTmsecs_to_jiffies(10)
> +
> enum adc5_cal_method {
> ADC5_NO_CAL = 0,
> ADC5_RATIOMETRIC_CAL,
> @@ -96,6 +105,7 @@ enum adc5_cal_val {
> * @cal_method: calibration method.
> * @cal_val: calibration value
> * @decimation: sampling rate supported for the channel.
> + * @sid: slave id of PMIC owning the channel, for PMIC7.
> * @prescale: channel scaling performed on the input signal.
> * @hw_settle_time: the time between AMUX being configured and the
> * start of conversion.
> @@ -110,6 +120,7 @@ struct adc5_channel_prop {
> enum adc5_cal_methodcal_method;
> enum adc5_cal_val cal_val;
> unsigned intdecimation;
> + unsigned intsid;
> unsigned intprescale;
> unsigned inthw_settle_time;
> unsigned intavg_samples;
> @@ -165,6 +176,11 @@ static int adc5_write(struct adc5_chip *adc, u16 offset,
> u8 *data, int len)
> return regmap_bulk_write(adc->regmap, adc->base + offset, data, len);
> }
>
> +static int adc5_masked_write(struct adc5_chip *adc, u16 offset, u8 mask, u8
> val)
> +{
> + return regmap_update_bits(adc->regmap, adc->base + offset, mask, val);
> +}
> +
> static int adc5_prescaling_from_dt(u32 num, u32 den)
> {
> unsigned int pre;
> @@ -314,6 +330,47 @@ static int adc5_configure(struct adc5_chip *adc,
> return adc5_write(adc, ADC5_USR_DIG_PARAM, buf, sizeof(buf));
> }
>
> +static int adc7_configure(struct adc5_chip *adc,
> + struct adc5_channel_prop *prop)
> +{
> + int ret;
> + u8 conv_req = 0, buf[4];
> +
> + ret = adc5_masked_write(adc, ADC_APP_SID, ADC_APP_SID_MASK, prop->sid);
> + if (ret)
> + return ret;
> +
> + ret = adc5_read(adc, ADC5_USR_DIG_PARAM, buf, sizeof(buf));
> + if (ret)
> + return ret;
> +
> + /* Digital param selection */
> + adc5_update_dig_param(adc, prop, [0]);
> +
> + /* Update fast average sample value */
> + buf[1] &= ~ADC5_USR_FAST_AVG_CTL_SAMPLES_MASK;
> + buf[1] |= prop->avg_samples;
> +
> + /* Select ADC channel */
> + buf[2] = prop->channel;
> +
> + /* Select HW settle delay for channel */
> + buf[3] &= ~ADC5_USR_HW_SETTLE_DELAY_MASK;
> + buf[3] |= prop->hw_settle_time;
> +
> + /* Select CONV request */
> + conv_req = ADC5_USR_CONV_REQ_REQ;
> +
> + if (!adc->poll_eoc)
> + reinit_completion(>complete);
> +
> + ret = adc5_write(adc, ADC5_USR_DIG_PARAM, buf, sizeof(buf));
> + if (ret)
> +
Re: [PATCH V6 2/7] iio: adc: Add PMIC7 ADC bindings
On Thu, 28 May 2020 22:24:24 +0530 Jishnu Prakash wrote: > Add documentation for PMIC7 ADC peripheral. > For the PMIC7-type PMICs, ADC peripheral is present in HW for the > following PMICs: PMK8350, PM8350, PM8350b, PMR735a and PMR735b. > Of these, only the ADC peripheral on PMK8350 is exposed directly to SW. > If SW needs to communicate with ADCs on other PMICs, it specifies the > PMIC to PMK8350 through the newly added SID register and communication > between PMK8350 ADC and other PMIC ADCs is carried out through > PBS(Programmable Boot Sequence) at the firmware level. > > In addition, add definitions for ADC channels and virtual channel > definitions (combination of ADC channel number and PMIC SID number) > per PMIC, to be used by ADC clients for PMIC7. > > Signed-off-by: Jishnu Prakash > Reviewed-by: Amit Kucheria > Reviewed-by: Rob Herring Applied. Thanks, J > --- > .../bindings/iio/adc/qcom,spmi-vadc.yaml | 38 -- > include/dt-bindings/iio/qcom,spmi-adc7-pm8350.h| 67 > include/dt-bindings/iio/qcom,spmi-adc7-pm8350b.h | 88 > ++ > include/dt-bindings/iio/qcom,spmi-adc7-pmk8350.h | 46 +++ > include/dt-bindings/iio/qcom,spmi-adc7-pmr735a.h | 28 +++ > include/dt-bindings/iio/qcom,spmi-adc7-pmr735b.h | 28 +++ > include/dt-bindings/iio/qcom,spmi-vadc.h | 78 ++- > 7 files changed, 366 insertions(+), 7 deletions(-) > create mode 100644 include/dt-bindings/iio/qcom,spmi-adc7-pm8350.h > create mode 100644 include/dt-bindings/iio/qcom,spmi-adc7-pm8350b.h > create mode 100644 include/dt-bindings/iio/qcom,spmi-adc7-pmk8350.h > create mode 100644 include/dt-bindings/iio/qcom,spmi-adc7-pmr735a.h > create mode 100644 include/dt-bindings/iio/qcom,spmi-adc7-pmr735b.h > > diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml > b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml > index de8d243..e6263b6 100644 > --- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml > +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml > @@ -13,7 +13,7 @@ maintainers: > description: | >SPMI PMIC voltage ADC (VADC) provides interface to clients to read >voltage. The VADC is a 15-bit sigma-delta ADC. > - SPMI PMIC5 voltage ADC (ADC) provides interface to clients to read > + SPMI PMIC5/PMIC7 voltage ADC (ADC) provides interface to clients to read >voltage. The VADC is a 16-bit sigma-delta ADC. > > properties: > @@ -28,6 +28,7 @@ properties: >- qcom,spmi-vadc >- qcom,spmi-adc5 >- qcom,spmi-adc-rev2 > + - qcom,spmi-adc7 > >reg: > description: VADC base address in the SPMI PMIC register map > @@ -70,6 +71,8 @@ patternProperties: > description: | >ADC channel number. >See include/dt-bindings/iio/qcom,spmi-vadc.h > + For PMIC7 ADC, the channel numbers are specified separately per > PMIC > + in the PMIC-specific files in include/dt-bindings/iio/. > >label: > $ref: /schemas/types.yaml#/definitions/string > @@ -113,11 +116,11 @@ patternProperties: >channel calibration. If property is not found, channel will be >calibrated with 0.625V and 1.25V reference channels, also >known as absolute calibration. > -- For compatible property "qcom,spmi-adc5" and > "qcom,spmi-adc-rev2", > - if this property is specified VADC will use the VDD reference > (1.875V) > - and GND for channel calibration. If property is not found, > channel > - will be calibrated with 0V and 1.25V reference channels, also > known > - as absolute calibration. > +- For compatible property "qcom,spmi-adc5", "qcom,spmi-adc7" and > + "qcom,spmi-adc-rev2", if this property is specified VADC will > use > + the VDD reference (1.875V) and GND for channel calibration. If > + property is not found, channel will be calibrated with 0V and > 1.25V > + reference channels, also known as absolute calibration. > type: boolean > >qcom,hw-settle-time: > @@ -208,6 +211,29 @@ allOf: >enum: [ 1, 2, 4, 8, 16 ] >default: 1 > > + - if: > + properties: > +compatible: > + contains: > +const: qcom,spmi-adc7 > + > +then: > + patternProperties: > +"^.*@[0-9a-f]+$": > + properties: > +qcom,decimation: > + enum: [ 85, 340, 1360 ] > + default: 1360 > + > +qcom,hw-settle-time: > + enum: [ 15, 100, 200, 300, 400, 500, 600, 700, 1000, 2000, > 4000, > + 8000, 16000, 32000, 64000, 128000 ] > + default: 15 > + > +qcom,avg-samples: > + enum: [ 1, 2, 4, 8, 16 ] > +
Re: [PATCH V6 1/7] iio: adc: Convert the QCOM SPMI ADC bindings to .yaml format
On Sun, 31 May 2020 11:36:12 +0100 Jonathan Cameron wrote: > On Thu, 28 May 2020 22:24:23 +0530 > Jishnu Prakash wrote: > > > Convert the adc bindings from .txt to .yaml format. > > > > Signed-off-by: Jishnu Prakash > > Reviewed-by: Amit Kucheria > > Reviewed-by: Rob Herring > > Acked-by: Linus Walleij > > Jishnu, Patch is fine, but I'd like to have seen a cover > letter and clear statement of changes from v5. > Applied to the togreg branch of iio.git and pushed out as testing. Note we've missed the merge window now for IIO so this will be in the following cycle. Thanks, J > Thanks, > > Jonathan > > > --- > > .../devicetree/bindings/iio/adc/qcom,spmi-vadc.txt | 173 -- > > .../bindings/iio/adc/qcom,spmi-vadc.yaml | 252 > > + > > 2 files changed, 252 insertions(+), 173 deletions(-) > > delete mode 100644 > > Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt > > create mode 100644 > > Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.yaml > > > > diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt > > b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt > > deleted file mode 100644 > > index c878768..000 > > --- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt > > +++ /dev/null > > @@ -1,173 +0,0 @@ > > -Qualcomm's SPMI PMIC ADC > > - > > -- SPMI PMIC voltage ADC (VADC) provides interface to clients to read > > - voltage. The VADC is a 15-bit sigma-delta ADC. > > -- SPMI PMIC5 voltage ADC (ADC) provides interface to clients to read > > - voltage. The VADC is a 16-bit sigma-delta ADC. > > - > > -VADC node: > > - > > -- compatible: > > -Usage: required > > -Value type: > > -Definition: Should contain "qcom,spmi-vadc". > > -Should contain "qcom,spmi-adc5" for PMIC5 ADC driver. > > -Should contain "qcom,spmi-adc-rev2" for PMIC rev2 ADC > > driver. > > -Should contain "qcom,pms405-adc" for PMS405 PMIC > > - > > -- reg: > > -Usage: required > > -Value type: > > -Definition: VADC base address in the SPMI PMIC register map. > > - > > -- #address-cells: > > -Usage: required > > -Value type: > > -Definition: Must be one. Child node 'reg' property should define ADC > > -channel number. > > - > > -- #size-cells: > > -Usage: required > > -Value type: > > -Definition: Must be zero. > > - > > -- #io-channel-cells: > > -Usage: required > > -Value type: > > -Definition: Must be one. For details about IIO bindings see: > > -Documentation/devicetree/bindings/iio/iio-bindings.txt > > - > > -- interrupts: > > -Usage: optional > > -Value type: > > -Definition: End of conversion interrupt. > > - > > -Channel node properties: > > - > > -- reg: > > -Usage: required > > -Value type: > > -Definition: ADC channel number. > > -See include/dt-bindings/iio/qcom,spmi-vadc.h > > - > > -- label: > > -Usage: required for "qcom,spmi-adc5" and "qcom,spmi-adc-rev2" > > -Value type: > > -Definition: ADC input of the platform as seen in the schematics. > > -For thermistor inputs connected to generic AMUX or GPIO inputs > > -these can vary across platform for the same pins. Hence select > > -the platform schematics name for this channel. > > - > > -- qcom,decimation: > > -Usage: optional > > -Value type: > > -Definition: This parameter is used to decrease ADC sampling rate. > > -Quicker measurements can be made by reducing decimation ratio. > > -- For compatible property "qcom,spmi-vadc", valid values are > > - 512, 1024, 2048, 4096. If property is not found, default > > value > > - of 512 will be used. > > -- For compatible property "qcom,spmi-adc5", valid values are > > 250, 420 > > - and 840. If property is not found, default value of 840 is > > used. > > -- For compatible property "qcom,spmi-adc-rev2", valid values > > are 256, > > - 512 and 1024. If property is not present, default value is > > 1024. > > - > > -- qcom,pre-scaling: > > -Usage: optional > > -Value type: > > -Definition: Used for scaling the channel input signal before the > > signal is > > -fed to VADC. The configuration for this node is to know the > > -pre-determined ratio and use it for post scaling. Select one > > from > > -the following options. > > -<1 1>, <1 3>, <1 4>, <1 6>, <1 20>, <1 8>, <10 81>, <1 10> > > -If property is not found default value depending on chip will > > be used. > > - > > -- qcom,ratiometric: > > -Usage: optional > > -Value type: > > -Definition: Channel calibration type. > > -- For compatible property "qcom,spmi-vadc", if this property is > > - specified VADC
Re: Re: drm/nouveau/clk/gm20b: Fix memory leak in gm20b_clk_new()
> > If gk20a_clk_ctor() never returns such an error code, > > we may need not to release this clock object. > > Would you like to achieve complete exception handling > also for this function implementation? > It seems that it's possible to get -ENOMEM from gk20a_clk_ctor(). The call chain is as follows: gk20a_clk_ctor() <- nvkm_clk_ctor() <- nvkm_notify_init() When nvkm_notify_init() returns -ENOMEM, all of its callers (and callers of callers) will be influenced if there is a failed kzalloc inside which. In this case, maybe we should check the return value of gk20a_clk_ctor() and release clk if it returns -ENOMEM. And many other functions also have the same issue (e.g., gm20b_clk_new_speedo0). Do you have any idea about this problem? Regards, Dinghao
Re: [PATCH] sh: Implement __get_user_u64() required for 64-bit get_user()
Hi Adrian,
On Sun, May 31, 2020 at 11:59 AM John Paul Adrian Glaubitz
wrote:
> On 5/31/20 11:54 AM, John Paul Adrian Glaubitz wrote:
> > On 5/31/20 11:52 AM, Geert Uytterhoeven wrote:
> >> As this is the 64-bit variant, I think this single move should be
> >> replaced by a double move:
> >>
> >>"mov #0,%R1\n\t" \
> >>"mov #0,%S1\n\t" \
> >>
> >> Same for the big endian version below.
> >>
> >> Disclaimer: uncompiled, untested, no SH assembler expert.
> >
> > Right, this makes sense. I'll send a new patch shortly.
>
> Hmm, this change is not the case for __put_user_asm() vs. __put_user_u64().
> But I have to admit, I don't know what the part below "3:\n\t" is for.
It's part of the exception handling, in case the passed (userspace) pointer
points to an inaccessible address, and triggers an exception.
For an invalid store, nothing is done, besides returning -EFAULT.
Hence there's no "mov #0, %1\n\t" in the put_user case.
For an invalid load, the data is replaced by zero, and -EFAULT is returned.
> +__asm__ __volatile__( \
> + "1:\n\t" \
> + "mov.l %2,%R1\n\t" \
> + "mov.l %T2,%S1\n\t" \
> + "2:\n" \
(reordering the two sections for easier explanation)
> + ".section __ex_table,\"a\"\n\t" \
> + ".long 1b, 3b\n\t" \
In case an exception happens for the instruction at 1b, jump to 3b.
Note that the m68k version has two entries here: one for each half of
the 64-bit access[*].
I don't know if that is really needed (and thus SH needs it, too), or if
the exception code handles subsequent instructions automatically.
> + ".section .fixup,\"ax\"\n" \
> + "3:\n\t" \
> + "mov#0, %1\n\t" \
Return zero instead of the data at the (invalid) address.
> + "mov.l 4f, %0\n\t" \
> + "jmp@%0\n\t" \
Resume at 2b.
Remember: branch delay slot, so the instruction below is executed first!
> + " mov %3, %0\n\t" \
Set err to -EFAULT.
> + ".balign4\n" \
> + "4: .long 2b\n\t" \
> + ".previous\n" \
> + ".previous" \
> + :"=" (err), "=" (x) \
> + :"m" (__m(addr)), "i" (-EFAULT), "0" (err)); })
[*] arch/m68k/include/asm/uaccess_mm.h
"1: "MOVES".l (%2)+,%1\n" \
"2: "MOVES".l (%2),%R1\n" \
" .section __ex_table,\"a\"\n"\
" .align 4\n"\
" .long 1b,10b\n" \
" .long 2b,10b\n" \
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
