[net-next 1/3] net: dsa: optimize tx timestamp request handling
Optimization could be done on dsa_skb_tx_timestamp(), and dsa device
drivers should adapt to it.
- Check SKBTX_HW_TSTAMP request flag at the very beginning, instead of in
port_txtstamp, so that most skbs not requiring tx timestamp just return.
- No longer to identify PTP packets, and limit tx timestamping only for PTP
packets. If device driver likes, let device driver do.
- It is a waste to clone skb directly in dsa_skb_tx_timestamp().
For one-step timestamping, a clone is not needed. For any failure of
port_txtstamp (this may usually happen), the skb clone has to be freed.
So put skb cloning into port_txtstamp where it really needs.
Signed-off-by: Yangbo Lu
---
Documentation/networking/timestamping.rst | 7 +--
.../net/dsa/hirschmann/hellcreek_hwtstamp.c | 20 --
.../net/dsa/hirschmann/hellcreek_hwtstamp.h | 2 +-
drivers/net/dsa/mv88e6xxx/hwtstamp.c | 21 +--
drivers/net/dsa/mv88e6xxx/hwtstamp.h | 6 +++---
drivers/net/dsa/ocelot/felix.c| 11 ++
drivers/net/dsa/sja1105/sja1105_ptp.c | 6 +-
drivers/net/dsa/sja1105/sja1105_ptp.h | 2 +-
include/net/dsa.h | 2 +-
net/dsa/slave.c | 20 +-
10 files changed, 57 insertions(+), 40 deletions(-)
diff --git a/Documentation/networking/timestamping.rst
b/Documentation/networking/timestamping.rst
index f682e88fa87e..7f04a699a5d1 100644
--- a/Documentation/networking/timestamping.rst
+++ b/Documentation/networking/timestamping.rst
@@ -635,8 +635,8 @@ in generic code: a BPF classifier (``ptp_classify_raw``) is
used to identify
PTP event messages (any other packets, including PTP general messages, are not
timestamped), and provides two hooks to drivers:
-- ``.port_txtstamp()``: The driver is passed a clone of the timestampable skb
- to be transmitted, before actually transmitting it. Typically, a switch will
+- ``.port_txtstamp()``: A clone of the timestampable skb to be transmitted
+ is needed, before actually transmitting it. Typically, a switch will
have a PTP TX timestamp register (or sometimes a FIFO) where the timestamp
becomes available. There may be an IRQ that is raised upon this timestamp's
availability, or the driver might have to poll after invoking
@@ -645,6 +645,9 @@ timestamped), and provides two hooks to drivers:
later use (when the timestamp becomes available). Each skb is annotated with
a pointer to its clone, in ``DSA_SKB_CB(skb)->clone``, to ease the driver's
job of keeping track of which clone belongs to which skb.
+ But one-step timestamping request is handled differently with above two-step
+ timestamping. The skb clone is no longer needed since hardware will insert
+ TX time information on packet during egress.
- ``.port_rxtstamp()``: The original (and only) timestampable skb is provided
to the driver, for it to annotate it with a timestamp, if that is immediately
diff --git a/drivers/net/dsa/hirschmann/hellcreek_hwtstamp.c
b/drivers/net/dsa/hirschmann/hellcreek_hwtstamp.c
index 69dd9a2e8bb6..2ff4b7c08b72 100644
--- a/drivers/net/dsa/hirschmann/hellcreek_hwtstamp.c
+++ b/drivers/net/dsa/hirschmann/hellcreek_hwtstamp.c
@@ -374,31 +374,39 @@ long hellcreek_hwtstamp_work(struct ptp_clock_info *ptp)
}
bool hellcreek_port_txtstamp(struct dsa_switch *ds, int port,
-struct sk_buff *clone, unsigned int type)
+struct sk_buff *skb, struct sk_buff **clone)
{
struct hellcreek *hellcreek = ds->priv;
struct hellcreek_port_hwtstamp *ps;
struct ptp_header *hdr;
+ unsigned int type;
ps = &hellcreek->ports[port].port_hwtstamp;
- /* Check if the driver is expected to do HW timestamping */
- if (!(skb_shinfo(clone)->tx_flags & SKBTX_HW_TSTAMP))
+ type = ptp_classify_raw(skb);
+ if (type == PTP_CLASS_NONE)
return false;
/* Make sure the message is a PTP message that needs to be timestamped
* and the interaction with the HW timestamping is enabled. If not, stop
* here
*/
- hdr = hellcreek_should_tstamp(hellcreek, port, clone, type);
+ hdr = hellcreek_should_tstamp(hellcreek, port, skb, type);
if (!hdr)
return false;
+ *clone = skb_clone_sk(skb);
+ if (!(*clone))
+ return false;
+
if (test_and_set_bit_lock(HELLCREEK_HWTSTAMP_TX_IN_PROGRESS,
- &ps->state))
+ &ps->state)) {
+ kfree_skb(*clone);
+ *clone = NULL;
return false;
+ }
- ps->tx_skb = clone;
+ ps->tx_skb = *clone;
/* store the number of ticks occurred since system start-up till this
* moment
diff --git a/drivers/net/dsa/hirschmann/hellcreek_hwtstamp.h
b/drivers/net/dsa/hirschmann/hellc
Re: [PATCH] floppy: remove redundant assignment to variable st
On 4/16/21 6:29 AM, Denis Efremov wrote: > Jens, could you please take this one? I thought to send it to you with other > cleanup patches in a merge request, but you already applied rest of the > patches. If you prefer to take it as merge request, it's ok I'll send it > based on your branch for-5.13/drivers. I have applied it, thanks. -- Jens Axboe
[net-next 0/3] Support ocelot PTP Sync one-step timestamping
This patch-set is to support ocelot PTP Sync one-step timestamping. Actually before that, this patch-set cleans up and optimizes the DSA slave tx timestamp request handling process. Yangbo Lu (3): net: dsa: optimize tx timestamp request handling net: mscc: ocelot: convert to ocelot_port_txtstamp_request() net: mscc: ocelot: support PTP Sync one-step timestamping Documentation/networking/timestamping.rst | 7 +- .../net/dsa/hirschmann/hellcreek_hwtstamp.c | 20 +++-- .../net/dsa/hirschmann/hellcreek_hwtstamp.h | 2 +- drivers/net/dsa/mv88e6xxx/hwtstamp.c | 21 +++-- drivers/net/dsa/mv88e6xxx/hwtstamp.h | 6 +- drivers/net/dsa/ocelot/felix.c| 15 ++-- drivers/net/dsa/sja1105/sja1105_ptp.c | 6 +- drivers/net/dsa/sja1105/sja1105_ptp.h | 2 +- drivers/net/ethernet/mscc/ocelot.c| 81 ++- drivers/net/ethernet/mscc/ocelot_net.c| 19 ++--- include/net/dsa.h | 2 +- include/soc/mscc/ocelot.h | 6 +- net/dsa/slave.c | 20 ++--- net/dsa/tag_ocelot.c | 25 +- net/dsa/tag_ocelot_8021q.c| 39 +++-- 15 files changed, 158 insertions(+), 113 deletions(-) base-commit: 392c36e5be1dee19ffce8c8ba8f07f90f5aa3f7c -- 2.25.1
Re: [PATCH] floppy: remove redundant assignment to variable st
Jens, could you please take this one? I thought to send it to you with other
cleanup patches in a merge request, but you already applied rest of the
patches. If you prefer to take it as merge request, it's ok I'll send it
based on your branch for-5.13/drivers.
On 4/15/21 4:00 PM, Colin King wrote:
> From: Colin Ian King
>
> The variable st is being assigned a value that is never read and
> it is being updated later with a new value. The initialization is
> redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
Reviewed-by: Denis Efremov
Thanks,
Denis
> ---
> arch/x86/include/asm/floppy.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/floppy.h b/arch/x86/include/asm/floppy.h
> index d43717b423cb..6ec3fc969ad5 100644
> --- a/arch/x86/include/asm/floppy.h
> +++ b/arch/x86/include/asm/floppy.h
> @@ -74,7 +74,6 @@ static irqreturn_t floppy_hardint(int irq, void *dev_id)
> int lcount;
> char *lptr;
>
> - st = 1;
> for (lcount = virtual_dma_count, lptr = virtual_dma_addr;
>lcount; lcount--, lptr++) {
> st = inb(virtual_dma_port + FD_STATUS);
>
linux-next: Fixes tag needs some work in the kvm tree
Hi all,
In commit
c3171e94cc1c ("KVM: s390: VSIE: fix MVPG handling for prefixing and MSO")
Fixes tag
Fixes: bdf7509bbefa ("s390/kvm: VSIE: correctly handle MVPG when in VSIE")
has these problem(s):
- Subject does not match target commit subject
Just use
git log -1 --format='Fixes: %h ("%s")'
--
Cheers,
Stephen Rothwell
pgp8D6dFguKch.pgp
Description: OpenPGP digital signature
Re: [PATCH 04/13] Kbuild: Rust support
On Thu, Apr 15, 2021 at 8:03 PM Nick Desaulniers wrote: > > Until then, I don't see why we need to permit developers to express > such flexibility for just the Rust code, or have it differ from the > intent of the C code. Does it make sense to set RUST_OPT_LEVEL_3 and > CC_OPTIMIZE_FOR_SIZE? I doubt it. That doesn't seem like a development > feature, but a mistake. YAGNI. Instead developers should clarify > what they care about in terms of high level intent; if someone wants > to micromanage optimization level flags in their forks they don't need > a Kconfig to do it (they're either going to hack KBUILD_CFLAGS, > CFLAGS_*.o, or KCFLAGS), and there's probably better mechanisms for > fine-tooth precision of optimizing actually hot code or not via PGO > and AutoFDO. I completely agree when we are talking about higher level optimization levels. From a user perspective, it does not make much sense to want slightly different optimizations levels or different size/performance trade-offs between C and Rust. However, I am thinking from the debugging side, i.e. mostly low or no optimization; rather than about micromanaging optimizations for performance. For instance, last year I used `RUST_OPT_LEVEL_0/1` to quickly rule out optimizer/codegen/etc. bugs on the Rust side when we had some memory corruption over Rust data (https://github.com/Rust-for-Linux/linux/pull/28), which is important when dealing with compiler nightly versions. It was also nice to be able to easily follow along when stepping, too. Having said that, I agree that in those cases one can simply tweak the flags manually -- so that's why I said it is fine dropping the the `Kconfig` options. There might be some advantages of having them, such as making developers aware that those builds should work, to keep them tested/working, etc.; but we can do that manually too in the CI/docs too. Cheers, Miguel
[PATCH 3/3] crypto: s5p-sss - consistently use local 'dev' variable in probe()
For code readability, the probe() function uses 'dev' variable instead
of '&pdev->dev', so update remaining places.
Signed-off-by: Krzysztof Kozlowski
---
drivers/crypto/s5p-sss.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 8c310816deab..55aa3a71169b 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -2186,14 +2186,14 @@ static int s5p_aes_probe(struct platform_device *pdev)
}
pdata->res = res;
- pdata->ioaddr = devm_ioremap_resource(&pdev->dev, res);
+ pdata->ioaddr = devm_ioremap_resource(dev, res);
if (IS_ERR(pdata->ioaddr)) {
if (!pdata->use_hash)
return PTR_ERR(pdata->ioaddr);
/* try AES without HASH */
res->end -= 0x300;
pdata->use_hash = false;
- pdata->ioaddr = devm_ioremap_resource(&pdev->dev, res);
+ pdata->ioaddr = devm_ioremap_resource(dev, res);
if (IS_ERR(pdata->ioaddr))
return PTR_ERR(pdata->ioaddr);
}
--
2.25.1
[PATCH 2/3] crypto: s5p-sss - remove unneeded local variable initialization
The initialization of 'err' local variable is not needed as it is
shortly after overwritten.
Addresses-Coverity: Unused value
Signed-off-by: Krzysztof Kozlowski
---
drivers/crypto/s5p-sss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index d613bd557016..8c310816deab 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -2156,7 +2156,7 @@ static struct skcipher_alg algs[] = {
static int s5p_aes_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
- int i, j, err = -ENODEV;
+ int i, j, err;
const struct samsung_aes_variant *variant;
struct s5p_aes_dev *pdata;
struct resource *res;
--
2.25.1
[PATCH 1/3] crypto: s5p-sss - simplify getting of_device_id match data
Use of_device_get_match_data() to make the code slightly smaller.
Signed-off-by: Krzysztof Kozlowski
---
drivers/crypto/s5p-sss.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 8ed08130196f..d613bd557016 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -424,13 +425,9 @@ MODULE_DEVICE_TABLE(of, s5p_sss_dt_match);
static inline const struct samsung_aes_variant *find_s5p_sss_version
(const struct platform_device *pdev)
{
- if (IS_ENABLED(CONFIG_OF) && (pdev->dev.of_node)) {
- const struct of_device_id *match;
+ if (IS_ENABLED(CONFIG_OF) && (pdev->dev.of_node))
+ return of_device_get_match_data(&pdev->dev);
- match = of_match_node(s5p_sss_dt_match,
- pdev->dev.of_node);
- return (const struct samsung_aes_variant *)match->data;
- }
return (const struct samsung_aes_variant *)
platform_get_device_id(pdev)->driver_data;
}
--
2.25.1
Re: [PATCH 2/2] iio: accel: Add driver for Murata SCA3300 accelerometer
Updated email-address for Alexandru. On 4/16/21 3:17 PM, Tomas Melin wrote: On 4/15/21 11:41 AM, Tomas Melin wrote: While working on updates I did notice something new which I cannot reproduce on older (5.10.17 kernel) version. If compiling this as a module, getting error while unloading module: [ 40.200084] Unable to handle kernel NULL pointer dereference at virtual address 0104 ... [ 40.510054] Backtrace: [ 40.512502] [] (iio_device_ioctl_handler_unregister) from [] (iio_buffers_free_sysfs_and_mask+0x2c/0x6c) [ 40.523735] [] (iio_buffers_free_sysfs_and_mask) from [] (iio_device_unregister+0xa8/0xac) [ 40.533746] r5:c1811228 r4:c1811000 [ 40.537318] [] (iio_device_unregister) from [] (devm_iio_device_unreg+0x1c/0x20) [ 40.546461] r5:c2415000 r4:c25bab80 [ 40.550025] [] (devm_iio_device_unreg) from [] (release_nodes+0x1c0/0x1f0) [ 40.558654] [] (release_nodes) from [] (devres_release_all+0x40/0x60) [ 40.566847] r10:0081 r9:c235 r8:c0100264 r7:0081 r6:bf00c010 r5:c19be000 [ 40.574669] r4:c1a91c00 [ 40.577194] [] (devres_release_all) from [] (device_release_driver_internal+0x120/0x1cc) [ 40.587031] r5:c19be000 r4:c1a91c00 [ 40.590596] [] (device_release_driver_internal) from [] (driver_detach+0x54/0x90) [ 40.599828] r7:0081 r6: r5:bf00c010 r4:c1a91c00 [ 40.605482] [] (driver_detach) from [] (bus_remove_driver+0x5c/0xb0) [ 40.613583] r5:0800 r4:bf00c010 [ 40.617148] [] (bus_remove_driver) from [] (driver_unregister+0x38/0x5c) [ 40.625596] r5:0800 r4:bf00c010 [ 40.629161] [] (driver_unregister) from [] (sca3300_driver_exit+0x14/0x8b4 [sca3300]) [ 40.638747] r5:0800 r4:bf00c080 [ 40.642311] [] (sca3300_driver_exit [sca3300]) from [] (sys_delete_module+0x16c/0x238) [ 40.651990] [] (sys_delete_module) from [] (__sys_trace_return+0x0/0x1c) [ 40.660435] Exception stack(0xc2351fa8 to 0xc2351ff0) [ 40.665484] 1fa0: 0050e5a8 0050e5e4 0800 081d4b00 bec18af4 [ 40.673661] 1fc0: 0050e5a8 bec18b50 0081 bec18e51 0050e190 0001 bec18d3c [ 40.681834] 1fe0: 0050cf70 bec18afc 004f1ec8 b6ecb27c [ 40.686887] r6:bec18b50 r5: r4:0050e5a8 [ 40.691507] Code: e8bd4000 e1c020d0 e3a0cc01 e3001122 (e5823004) [ 40.707675] ---[ end trace 189882b050077333 ]--- This happens when building against linux-next 5.12.0-rc6-next-20210409. I'm failing to see what is wrong. Any ideas? Thanks, Tomas Tested further that for this driver, loading and unloading as module works fine until commit: commit f73f7f4da581875f9b1f2fb8ebd1ab15ed634488 Author: Alexandru Ardelean Date: Mon Feb 15 12:40:39 2021 +0200 iio: buffer: add ioctl() to support opening extra buffers for IIO device Any thoughts what causes this issue? Thanks, Tomas --- drivers/iio/accel/Kconfig | 13 ++ drivers/iio/accel/Makefile | 1 + drivers/iio/accel/sca3300.c | 434 3 files changed, 448 insertions(+) create mode 100644 drivers/iio/accel/sca3300.c diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig index cceda3cecbcf..0dbf7b648e8a 100644 --- a/drivers/iio/accel/Kconfig +++ b/drivers/iio/accel/Kconfig @@ -450,6 +450,19 @@ config SCA3000 To compile this driver as a module, say M here: the module will be called sca3000. +config SCA3300 + tristate "Murata SCA3300 3-Axis Accelerometer Driver" + depends on SPI + select CRC8 + select IIO_BUFFER + select IIO_TRIGGERED_BUFFER + help + Say yes here to build support for Murata SCA3300 3-Axis + accelerometer. + + To compile this driver as a module, choose M here: the module will be + called sca3300. + config STK8312 tristate "Sensortek STK8312 3-Axis Accelerometer Driver" depends on I2C diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile index 32cd1342a31a..4b56527a2b97 100644 --- a/drivers/iio/accel/Makefile +++ b/drivers/iio/accel/Makefile @@ -50,6 +50,7 @@ obj-$(CONFIG_MXC4005) += mxc4005.o obj-$(CONFIG_MXC6255) += mxc6255.o obj-$(CONFIG_SCA3000) += sca3000.o +obj-$(CONFIG_SCA3300) += sca3300.o obj-$(CONFIG_STK8312) += stk8312.o obj-$(CONFIG_STK8BA50) += stk8ba50.o diff --git a/drivers/iio/accel/sca3300.c b/drivers/iio/accel/sca3300.c new file mode 100644 index ..112fb88ecd3a --- /dev/null +++ b/drivers/iio/accel/sca3300.c @@ -0,0 +1,434 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (c) Vaisala Oyj. All rights reserved. Give a year for the copyright notice if you can. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define SCA3300_ALIAS "sca3300" + +#define SCA3300_REG_STATUS 0x6 +#define SCA3300_REG_MODE 0xd +#define SCA3300_REG_WHOAMI 0x10 +#define SCA3300_VALUE_SW_RESET 0x20 +#define SCA3300_CRC8_POLYN
Re: [PATCH] dma-buf: Add DmaBufTotal counter in meminfo
Hi Peter, Thank you for the patch! Yet something to improve: [auto build test ERROR on linux/master] [also build test ERROR on linus/master v5.12-rc7 next-20210415] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Peter-Enderborg/dma-buf-Add-DmaBufTotal-counter-in-meminfo/20210416-174133 base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 5e46d1b78a03d52306f21f77a4e4a144b6d31486 config: nios2-defconfig (attached as .config) compiler: nios2-linux-gcc (GCC) 9.3.0 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 # https://github.com/0day-ci/linux/commit/0549b4e26c5fc079bdec725b55fc031a5db388c5 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Peter-Enderborg/dma-buf-Add-DmaBufTotal-counter-in-meminfo/20210416-174133 git checkout 0549b4e26c5fc079bdec725b55fc031a5db388c5 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=nios2 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): nios2-linux-ld: fs/proc/meminfo.o: in function `meminfo_proc_show': >> meminfo.c:(.text+0x3d0): undefined reference to `dma_buf_get_size' meminfo.c:(.text+0x3d0): relocation truncated to fit: R_NIOS2_CALL26 against `dma_buf_get_size' --- 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] dma-buf: Add DmaBufTotal counter in meminfo
Hi Peter, Thank you for the patch! Yet something to improve: [auto build test ERROR on linux/master] [also build test ERROR on linus/master v5.12-rc7 next-20210415] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Peter-Enderborg/dma-buf-Add-DmaBufTotal-counter-in-meminfo/20210416-174133 base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 5e46d1b78a03d52306f21f77a4e4a144b6d31486 config: arc-alldefconfig (attached as .config) compiler: arc-elf-gcc (GCC) 9.3.0 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 # https://github.com/0day-ci/linux/commit/0549b4e26c5fc079bdec725b55fc031a5db388c5 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Peter-Enderborg/dma-buf-Add-DmaBufTotal-counter-in-meminfo/20210416-174133 git checkout 0549b4e26c5fc079bdec725b55fc031a5db388c5 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross W=1 ARCH=arc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): arc-elf-ld: fs/proc/meminfo.o: in function `meminfo_proc_show': meminfo.c:(.text+0x2b2): undefined reference to `dma_buf_get_size' >> arc-elf-ld: meminfo.c:(.text+0x2b2): undefined reference to >> `dma_buf_get_size' --- 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 v3 1/2] perf/core: Share an event with multiple cgroups
On Fri, Apr 16, 2021 at 8:59 PM Peter Zijlstra wrote: > > On Fri, Apr 16, 2021 at 08:22:38PM +0900, Namhyung Kim wrote: > > On Fri, Apr 16, 2021 at 7:28 PM Peter Zijlstra wrote: > > > > > > On Fri, Apr 16, 2021 at 11:29:30AM +0200, Peter Zijlstra wrote: > > > > > > > > So I think we've had proposals for being able to close fds in the > > > > > past; > > > > > while preserving groups etc. We've always pushed back on that because > > > > > of > > > > > the resource limit issue. By having each counter be a filedesc we get > > > > > a > > > > > natural limit on the amount of resources you can consume. And in that > > > > > respect, having to use 400k fds is things working as designed. > > > > > > > > > > Anyway, there might be a way around this.. > > > > > > So how about we flip the whole thing sideways, instead of doing one > > > event for multiple cgroups, do an event for multiple-cpus. > > > > > > Basically, allow: > > > > > > perf_event_open(.pid=fd, cpu=-1, .flag=PID_CGROUP); > > > > > > Which would have the kernel create nr_cpus events [the corrolary is that > > > we'd probably also allow: (.pid=-1, cpu=-1) ]. > > > > Do you mean it'd have separate perf_events per cpu internally? > > From a cpu's perspective, there's nothing changed, right? > > Then it will have the same performance problem as of now. > > Yes, but we'll not end up in ioctl() hell. The interface is sooo much > better. The performance thing just means we need to think harder. > > I thought cgroup scheduling got a lot better with the work Ian did a > while back? What's the actual bottleneck now? Yep, that's true but it still comes with a high cost of multiplexing in context (cgroup) switch. It's inefficient that it programs the PMU with exactly the same config just for a different cgroup. You know accessing the MSRs is no cheap operation. > > > > Output could be done by adding FORMAT_PERCPU, which takes the current > > > read() format and writes a copy for each CPU event. (p)read(v)() could > > > be used to explode or partial read that. > > > > Yeah, I think it's good for read. But what about mmap? > > I don't think we can use file offset since it's taken for auxtrace. > > Maybe we can simply disallow that.. > > Are you actually using mmap() to read? I had a proposal for FORMAT_GROUP > like thing for mmap(), but I never implemented that (didn't get the > enthousiatic response I thought it would). But yeah, there's nowhere > near enough space in there for PERCPU. Recently there's a patch to do it with rdpmc which needs to mmap first. https://lore.kernel.org/lkml/20210414155412.3697605-1-r...@kernel.org/ > > Not sure how to do that, these counters must not be sampling counters > because we can't be sharing a buffer from multiple CPUs, so data/aux > just isn't a concern. But it's weird to have them magically behave > differently. Yeah it's weird, and we should limit the sampling use case. Thanks, Namhyung
Re: [PATCH 2/2] iio: accel: Add driver for Murata SCA3300 accelerometer
On 4/15/21 11:41 AM, Tomas Melin wrote: While working on updates I did notice something new which I cannot reproduce on older (5.10.17 kernel) version. If compiling this as a module, getting error while unloading module: [ 40.200084] Unable to handle kernel NULL pointer dereference at virtual address 0104 ... [ 40.510054] Backtrace: [ 40.512502] [] (iio_device_ioctl_handler_unregister) from [] (iio_buffers_free_sysfs_and_mask+0x2c/0x6c) [ 40.523735] [] (iio_buffers_free_sysfs_and_mask) from [] (iio_device_unregister+0xa8/0xac) [ 40.533746] r5:c1811228 r4:c1811000 [ 40.537318] [] (iio_device_unregister) from [] (devm_iio_device_unreg+0x1c/0x20) [ 40.546461] r5:c2415000 r4:c25bab80 [ 40.550025] [] (devm_iio_device_unreg) from [] (release_nodes+0x1c0/0x1f0) [ 40.558654] [] (release_nodes) from [] (devres_release_all+0x40/0x60) [ 40.566847] r10:0081 r9:c235 r8:c0100264 r7:0081 r6:bf00c010 r5:c19be000 [ 40.574669] r4:c1a91c00 [ 40.577194] [] (devres_release_all) from [] (device_release_driver_internal+0x120/0x1cc) [ 40.587031] r5:c19be000 r4:c1a91c00 [ 40.590596] [] (device_release_driver_internal) from [] (driver_detach+0x54/0x90) [ 40.599828] r7:0081 r6: r5:bf00c010 r4:c1a91c00 [ 40.605482] [] (driver_detach) from [] (bus_remove_driver+0x5c/0xb0) [ 40.613583] r5:0800 r4:bf00c010 [ 40.617148] [] (bus_remove_driver) from [] (driver_unregister+0x38/0x5c) [ 40.625596] r5:0800 r4:bf00c010 [ 40.629161] [] (driver_unregister) from [] (sca3300_driver_exit+0x14/0x8b4 [sca3300]) [ 40.638747] r5:0800 r4:bf00c080 [ 40.642311] [] (sca3300_driver_exit [sca3300]) from [] (sys_delete_module+0x16c/0x238) [ 40.651990] [] (sys_delete_module) from [] (__sys_trace_return+0x0/0x1c) [ 40.660435] Exception stack(0xc2351fa8 to 0xc2351ff0) [ 40.665484] 1fa0: 0050e5a8 0050e5e4 0800 081d4b00 bec18af4 [ 40.673661] 1fc0: 0050e5a8 bec18b50 0081 bec18e51 0050e190 0001 bec18d3c [ 40.681834] 1fe0: 0050cf70 bec18afc 004f1ec8 b6ecb27c [ 40.686887] r6:bec18b50 r5: r4:0050e5a8 [ 40.691507] Code: e8bd4000 e1c020d0 e3a0cc01 e3001122 (e5823004) [ 40.707675] ---[ end trace 189882b050077333 ]--- This happens when building against linux-next 5.12.0-rc6-next-20210409. I'm failing to see what is wrong. Any ideas? Thanks, Tomas Tested further that for this driver, loading and unloading as module works fine until commit: commit f73f7f4da581875f9b1f2fb8ebd1ab15ed634488 Author: Alexandru Ardelean Date: Mon Feb 15 12:40:39 2021 +0200 iio: buffer: add ioctl() to support opening extra buffers for IIO device Any thoughts what causes this issue? Thanks, Tomas --- drivers/iio/accel/Kconfig | 13 ++ drivers/iio/accel/Makefile | 1 + drivers/iio/accel/sca3300.c | 434 3 files changed, 448 insertions(+) create mode 100644 drivers/iio/accel/sca3300.c diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig index cceda3cecbcf..0dbf7b648e8a 100644 --- a/drivers/iio/accel/Kconfig +++ b/drivers/iio/accel/Kconfig @@ -450,6 +450,19 @@ config SCA3000 To compile this driver as a module, say M here: the module will be called sca3000. +config SCA3300 + tristate "Murata SCA3300 3-Axis Accelerometer Driver" + depends on SPI + select CRC8 + select IIO_BUFFER + select IIO_TRIGGERED_BUFFER + help + Say yes here to build support for Murata SCA3300 3-Axis + accelerometer. + + To compile this driver as a module, choose M here: the module will be + called sca3300. + config STK8312 tristate "Sensortek STK8312 3-Axis Accelerometer Driver" depends on I2C diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile index 32cd1342a31a..4b56527a2b97 100644 --- a/drivers/iio/accel/Makefile +++ b/drivers/iio/accel/Makefile @@ -50,6 +50,7 @@ obj-$(CONFIG_MXC4005) += mxc4005.o obj-$(CONFIG_MXC6255) += mxc6255.o obj-$(CONFIG_SCA3000) += sca3000.o +obj-$(CONFIG_SCA3300) += sca3300.o obj-$(CONFIG_STK8312) += stk8312.o obj-$(CONFIG_STK8BA50) += stk8ba50.o diff --git a/drivers/iio/accel/sca3300.c b/drivers/iio/accel/sca3300.c new file mode 100644 index ..112fb88ecd3a --- /dev/null +++ b/drivers/iio/accel/sca3300.c @@ -0,0 +1,434 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (c) Vaisala Oyj. All rights reserved. Give a year for the copyright notice if you can. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define SCA3300_ALIAS "sca3300" + +#define SCA3300_REG_STATUS 0x6 +#define SCA3300_REG_MODE 0xd +#define SCA3300_REG_WHOAMI 0x10 +#define SCA3300_VALUE_SW_RESET 0x20 +#define SCA3300_CRC8_POLYNOMIAL 0x1d +#define SCA3300_X_READ 0 I wouldn't bother defining this. +#defi
Re: [patch] x86/crash: fix crash_setup_memmap_entries() out-of-bounds access
On Fri, Apr 16, 2021 at 02:02:07PM +0200, Mike Galbraith wrote:
> [ 15.428011] BUG: KASAN: vmalloc-out-of-bounds in
> crash_setup_memmap_entries+0x17e/0x3a0
> [ 15.428018] Write of size 8 at addr c9426008 by task kexec/1187
>
> (gdb) list *crash_setup_memmap_entries+0x17e
> 0x8107cafe is in crash_setup_memmap_entries
> (arch/x86/kernel/crash.c:322).
> 317 unsigned long long mend)
> 318 {
> 319 unsigned long start, end;
> 320
> 321 cmem->ranges[0].start = mstart;
> 322 cmem->ranges[0].end = mend;
> 323 cmem->nr_ranges = 1;
> 324
> 325 /* Exclude elf header region */
> 326 start = image->arch.elf_load_addr;
> (gdb)
>
> Append missing struct crash_mem_range to cmem.
This is winning this year's contest for most laconic patch commit
message! :-)
Please be more verbose and structure your commit message like this:
Problem is A.
It happens because of B.
Fix it by doing C.
(Potentially do D).
For more detailed info, see
Documentation/process/submitting-patches.rst, Section "2) Describe your
changes".
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH v4 2/2] pwm: visconti: Add Toshiba Visconti SoC PWM support
Hi Uwe, Thanks for your comment. On Fri, Apr 16, 2021 at 11:44:26AM +0200, Uwe Kleine-König wrote: > Hello Nobuhiro, > > On Fri, Apr 16, 2021 at 05:07:21PM +0900, Nobuhiro Iwamatsu wrote: > > On Mon, Apr 12, 2021 at 09:02:32AM +0200, Uwe Kleine-König wrote: > > > On Mon, Apr 12, 2021 at 11:55:36AM +0900, Nobuhiro Iwamatsu wrote: > > > > On Sat, Apr 10, 2021 at 03:53:21PM +0200, Uwe Kleine-König wrote: > > > > > Can you please put a paragraph analogous to the one in pwm-sifive in > > > > > the > > > > > same format. This simplified keeping an overview about the oddities of > > > > > the various supported chips. > > > > > > > > OK, I will check pwm-sifive's, and add. > > > > I will add the following : > > > > * Limitations: > > * - PIPGM_PWMC is a 2-bit divider (00: 1, 01: 2, 10: 4, 11: 8) for the > > input > > * clock running at 1 MHz. > > I would strip that to: > > - Fixed input clock running at 1 MHz > OK, I will update. > > * - When the settings of the PWM are modified, the new values are shadowed > > * in hardware until the PIPGM_PCSR register is written and the currently > > * running period is completed. This way the hardware switches atomically > > * from the old setting to the new. > > * - Disabling the hardware completes the currently running period and keeps > > * the output at low level at all times. > > This looks fine. > > > > For me the critical (and only) difference between "off" and > > > "duty cycle = 0" is that when a new configuration is to be applied. In > > > the "off" state a new period can (and should) start immediately, while > > > with "duty_cycle = 0" the rising edge should be delayed until the > > > currently running period is over.[1] > > > > > > So the thing to do here (IMHO) is: > > > > > > Iff with PIPGM_PCSR = 0 configuring a new setting (that is finalized > > > with writing a non-zero value to PIPGM_PCSR) completes the currently > > > running period, then always assume the PWM as enabled. > > > > Yes, this device works that way. > > OK, then please use > > state->enabled = true > > unconditionally in visconti_pwm_get_state(). > Please let me check. If I unconditionally add 'state->enabled = true' to visconti_pwm_get_state(), state->enabled is set to true because visconti_pwm_get_state() is called when the device is created (this is when I write the device number to the export of /sys/class/pwm/pwmchip0 ). And since PIPGM_PCSR is 0 in this state, the pulse by PWM is not output. However, I think this means that the device is working as this driver. Is this correct? > Best regards > Uwe > Best regards, Nobuhiro
Re: [PATCH v1 1/2] coresight: Add support for device names
On 2021-04-16 19:19, Alexander Shishkin wrote:
Tao Zhang writes:
diff --git a/drivers/hwtracing/coresight/coresight-core.c
b/drivers/hwtracing/coresight/coresight-core.c
index 4ba801d..b79c726 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -1640,6 +1640,12 @@ char *coresight_alloc_device_name(struct
coresight_dev_list *dict,
int idx;
char *name = NULL;
struct fwnode_handle **list;
+ struct device_node *node = dev->of_node;
+
+ if (!node) {
+ if (!of_property_read_string(node, "coresight-name", &name))
Ok, I'm not a device tree expert, but I'm pretty sure the above is a
nop.
Regards,
--
Alex
You are right. The pointer check code here is wrong, I will correct it
on the V2 version.
Tao
Re: [PATCH v9 5/7] mm: Make alloc_contig_range handle free hugetlb pages
On Fri, Apr 16, 2021 at 05:49:20PM +0800, Baoquan He wrote:
> On 04/16/21 at 09:00am, Oscar Salvador wrote:
> ...
> > +/*
> > + * alloc_and_dissolve_huge_page - Allocate a new page and dissolve the old
> > one
> > + * @h: struct hstate old page belongs to
> > + * @old_page: Old page to dissolve
> > + * Returns 0 on success, otherwise negated error.
> > + */
> > +static int alloc_and_dissolve_huge_page(struct hstate *h, struct page
> > *old_page)
> > +{
> > + gfp_t gfp_mask = htlb_alloc_mask(h) | __GFP_THISNODE;
> > + int nid = page_to_nid(old_page);
> > + struct page *new_page;
> > + int ret = 0;
> > +
> > + /*
> > +* Before dissolving the page, we need to allocate a new one for the
> > +* pool to remain stable. Using alloc_buddy_huge_page() allows us to
> > +* not having to deal with prep_new_page() and avoids dealing of any
> ~ prep_new_huge_page() ?
Yep, clumsy.
@Andrew: could you please amend that or should I send a new version?
Thanks
--
Oscar Salvador
SUSE L3
Re: [PATCH] drivers: ipa: Fix missing IRQF_ONESHOT as only threaded handler
On 4/15/21 10:40 PM, zhuguangqin...@gmail.com wrote:
From: Guangqing Zhu
This is not required here. -Alex
https://lore.kernel.org/netdev/d57e0a43-4d87-93cf-471c-c8185ea85...@ieee.org/
Coccinelle noticed:
drivers/net/ipa/ipa_smp2p.c:186:7-27: ERROR: Threaded IRQ with no primary
handler requested without IRQF_ONESHOT
Signed-off-by: Guangqing Zhu
---
drivers/net/ipa/ipa_smp2p.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ipa/ipa_smp2p.c b/drivers/net/ipa/ipa_smp2p.c
index a5f7a79a1923..74e04427a711 100644
--- a/drivers/net/ipa/ipa_smp2p.c
+++ b/drivers/net/ipa/ipa_smp2p.c
@@ -183,7 +183,8 @@ static int ipa_smp2p_irq_init(struct ipa_smp2p *smp2p,
const char *name,
}
irq = ret;
- ret = request_threaded_irq(irq, NULL, handler, 0, name, smp2p);
+ ret = request_threaded_irq(irq, NULL, handler, IRQF_ONESHOT,
+ name, smp2p);
if (ret) {
dev_err(dev, "error %d requesting \"%s\" IRQ\n", ret, name);
return ret;
Re: [RFC PATCH 2/2] bfq/mq-deadline: remove redundant check for passthrough request
On 4/14/21 9:43 PM, Lin Feng wrote: > Since commit 01e99aeca39796003 'blk-mq: insert passthrough request into > hctx->dispatch directly', passthrough request should not appear in > IO-scheduler any more, so blk_rq_is_passthrough checking in addon IO > schedulers is redundant. > > (Notes: this patch passes generic IO load test with hdds under SAS > controller and hdds under AHCI controller but obviously not covers all. > Not sure if passthrough request can still escape into IO scheduler from > blk_mq_sched_insert_requests, which is used by blk_mq_flush_plug_list and > has lots of indirect callers.) Applied, with the bfq bits hand edited to apply for 5.13. -- Jens Axboe
Re: [PATCH 1/2] blk-mq: bypass IO scheduler's limit_depth for passthrough request
On 4/14/21 9:39 PM, Lin Feng wrote:
> Commit 01e99aeca39796003 ("blk-mq: insert passthrough request into
> hctx->dispatch directly") gives high priority to passthrough requests and
> bypass underlying IO scheduler. But as we allocate tag for such request it
> still runs io-scheduler's callback limit_depth, while we really want is to
> give full sbitmap-depth capabity to such request for acquiring available
> tag.
> blktrace shows PC requests(dmraid -s -c -i) hit bfq's limit_depth:
> 8,020 0.0 39952 1,0 m N bfq [bfq_limit_depth]
> wr_busy 0 sync 0 depth 8
> 8,021 0.08134 39952 D R 4 [dmraid]
> 8,022 0.2153824 C R [0]
> 8,020 0.35442 39952 1,0 m N bfq [bfq_limit_depth]
> wr_busy 0 sync 0 depth 8
> 8,023 0.38813 39952 D R 24 [dmraid]
> 8,024 0.4435624 C R [0]
>
> This patch introduce a new wrapper to make code not that ugly.
Applied, thanks.
--
Jens Axboe
Re: [PATCH v5 0/3] CAN TRANSCEIVER: Add support for CAN transceivers
On 4/16/21 1:30 PM, Aswath Govindraju wrote: > The following series of patches add support for CAN transceivers. > > TCAN1042 has a standby signal that needs to be pulled high for > sending/receiving messages[1]. TCAN1043 has a enable signal along with > standby signal that needs to be pulled up for sending/receiving > messages[2], and other combinations of the two lines can be used to put the > transceiver in different states to reduce power consumption. On boards > like the AM654-idk and J721e-evm these signals are controlled using gpios. > > Patch 1 rewords the comment that restricts max_link_rate attribute to have > units of Mbps. > > Patch 2 models the transceiver as a phy device tree node with properties > for max bit rate supported, gpio properties for indicating gpio pin numbers > to which standby and enable signals are connected. > > Patch 2 adds a generic driver to support CAN transceivers. > > changes since v4: > - In patch 3 made the correction from mcan to CAN, in Kconfig help > > changes since v3: > - dropped patch 2(in v3) > - changed the node name property in patch 3(in v3) > - picked up Rob Herring's reviewed-by for patch 3(in v3) > > changes since v2: > - dropped 5 and 6 patches and to be sent via linux-can-next > - added static keyword for can_transceiver_phy_probe() > - changed enable gpio example to active high in patch 3 > - Rearranged the file names in alphabetical order in Makefile > and MAINTAINERS file > > changes since v1: > - Added patch 1 (in v2) that rewords the comment that restrict > max_link_rate attribute to have units of Mbps. > - Added patch 2 (in v2) that adds an API for > devm_of_phy_optional_get_by_index > - Patch 1 (in v1) > - updated MAINTAINERS file > - Patch 2 (in v1) > - replaced m_can with CAN to make the driver independent of CAN driver > - Added prefix CAN_TRANSCEIVER for EN_PRESENT and STB_PRESENT > - Added new line before return statements in power_on() and power_off > - Added error handling patch for devm_kzalloc() > - used the max_link_rate attribute directly instead of dividing it by > 100 > - removed the spaces before GPIOD_OUT_LOW in devm_gpiod_get() > - Corrected requested value for standby-gpios to GPIOD_OUT_HIGH > - Updated MAINTAINERS file > - Patch 3 (in v1) > - replaced minItems with maxItems > - Removed phy-names property as there is only one phy > - Patch 4 (in v1) > - replaced dev_warn with dev_info when no transceiver is found > - Added struct phy * field in m_can_classdev struct > - moved phy_power_on and phy_power_off to m_can_open and m_can_close > respectively > - Moved the check for max_bit_rate to generice transceiver driver > > [1] - https://www.ti.com/lit/ds/symlink/tcan1042h.pdf > [2] - https://www.ti.com/lit/ds/symlink/tcan1043-q1.pdf > > Aswath Govindraju (3): > phy: core: Reword the comment specifying the units of max_link_rate to > be Mbps > dt-bindings: phy: Add binding for TI TCAN104x CAN transceivers > phy: phy-can-transceiver: Add support for generic CAN transceiver > driver > Acked-by: Marc Kleine-Budde Please upstream this via the phy-tree, I'll take the mcan changes via linux-can-next. regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/5] Another small set of cleanups for floppy driver
On 4/16/21 2:34 AM, Denis Efremov wrote: > Just a couple of patches to make checkpatch.pl a bit more happy. > All these patches preserve original semantics of the code and only > memset(), memcpy() patches change binary code. Applied, thanks. -- Jens Axboe
[PATCH 10/12] arm64: dts: qcom: sm8250: Use QMP binding to control load state
Use the Qualcomm Mailbox Protocol (QMP) binding to control the load
state resources on SM8250 SoCs and drop deprecated power-domains exposed
by AOSS QMP node.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 4c0de12aaba6..0a5b747f55b9 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -11,7 +11,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -1881,13 +1880,14 @@
clocks = <&rpmhcc RPMH_CXO_CLK>;
clock-names = "xo";
- power-domains = <&aoss_qmp AOSS_QMP_LS_SLPI>,
- <&rpmhpd SM8250_LCX>,
+ power-domains = <&rpmhpd SM8250_LCX>,
<&rpmhpd SM8250_LMX>;
- power-domain-names = "load_state", "lcx", "lmx";
+ power-domain-names = "lcx", "lmx";
memory-region = <&slpi_mem>;
+ qcom,qmp = <&aoss_qmp>;
+
qcom,smem-states = <&smp2p_slpi_out 0>;
qcom,smem-state-names = "stop";
@@ -1947,12 +1947,12 @@
clocks = <&rpmhcc RPMH_CXO_CLK>;
clock-names = "xo";
- power-domains = <&aoss_qmp AOSS_QMP_LS_CDSP>,
- <&rpmhpd SM8250_CX>;
- power-domain-names = "load_state", "cx";
+ power-domains = <&rpmhpd SM8250_CX>;
memory-region = <&cdsp_mem>;
+ qcom,qmp = <&aoss_qmp>;
+
qcom,smem-states = <&smp2p_cdsp_out 0>;
qcom,smem-state-names = "stop";
@@ -2689,7 +2689,6 @@
IPCC_MPROC_SIGNAL_GLINK_QMP>;
#clock-cells = <0>;
- #power-domain-cells = <1>;
};
spmi_bus: spmi@c44 {
@@ -3517,13 +3516,14 @@
clocks = <&rpmhcc RPMH_CXO_CLK>;
clock-names = "xo";
- power-domains = <&aoss_qmp AOSS_QMP_LS_LPASS>,
- <&rpmhpd SM8250_LCX>,
+ power-domains = <&rpmhpd SM8250_LCX>,
<&rpmhpd SM8250_LMX>;
- power-domain-names = "load_state", "lcx", "lmx";
+ power-domain-names = "lcx", "lmx";
memory-region = <&adsp_mem>;
+ qcom,qmp = <&aoss_qmp>;
+
qcom,smem-states = <&smp2p_adsp_out 0>;
qcom,smem-state-names = "stop";
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 11/12] arm64: dts: qcom: sm8350: Use QMP binding to control load state
Use the Qualcomm Mailbox Protocol (QMP) binding to control the load
state resources on SM8350 SoCs and drop deprecated power-domains exposed
by AOSS QMP node.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi
b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index ed0b51bc03ea..ddbe932e4066 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -7,7 +7,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -651,15 +650,16 @@
clocks = <&rpmhcc RPMH_CXO_CLK>;
clock-names = "xo";
- power-domains = <&aoss_qmp AOSS_QMP_LS_MODEM>,
- <&rpmhpd 0>,
+ power-domains = <&rpmhpd 0>,
<&rpmhpd 12>;
- power-domain-names = "load_state", "cx", "mss";
+ power-domain-names = "cx", "mss";
interconnects = <&mc_virt 0 &mc_virt 1>;
memory-region = <&pil_modem_mem>;
+ qcom,qmp = <&aoss_qmp>;
+
qcom,smem-states = <&smp2p_modem_out 0>;
qcom,smem-state-names = "stop";
@@ -719,7 +719,6 @@
mboxes = <&ipcc IPCC_CLIENT_AOP
IPCC_MPROC_SIGNAL_GLINK_QMP>;
#clock-cells = <0>;
- #power-domain-cells = <1>;
};
spmi_bus: spmi@c44 {
@@ -1018,13 +1017,14 @@
clocks = <&rpmhcc RPMH_CXO_CLK>;
clock-names = "xo";
- power-domains = <&aoss_qmp AOSS_QMP_LS_SLPI>,
- <&rpmhpd 4>,
+ power-domains = <&rpmhpd 4>,
<&rpmhpd 5>;
- power-domain-names = "load_state", "lcx", "lmx";
+ power-domain-names = "lcx", "lmx";
memory-region = <&pil_slpi_mem>;
+ qcom,qmp = <&aoss_qmp>;
+
qcom,smem-states = <&smp2p_slpi_out 0>;
qcom,smem-state-names = "stop";
@@ -1058,15 +1058,16 @@
clocks = <&rpmhcc RPMH_CXO_CLK>;
clock-names = "xo";
- power-domains = <&aoss_qmp AOSS_QMP_LS_CDSP>,
- <&rpmhpd 0>,
+ power-domains = <&rpmhpd 0>,
<&rpmhpd 10>;
- power-domain-names = "load_state", "cx", "mxc";
+ power-domain-names = "cx", "mxc";
interconnects = <&compute_noc 1 &mc_virt 1>;
memory-region = <&pil_cdsp_mem>;
+ qcom,qmp = <&aoss_qmp>;
+
qcom,smem-states = <&smp2p_cdsp_out 0>;
qcom,smem-state-names = "stop";
@@ -1292,13 +1293,14 @@
clocks = <&rpmhcc RPMH_CXO_CLK>;
clock-names = "xo";
- power-domains = <&aoss_qmp AOSS_QMP_LS_LPASS>,
- <&rpmhpd 4>,
+ power-domains = <&rpmhpd 4>,
<&rpmhpd 5>;
- power-domain-names = "load_state", "lcx", "lmx";
+ power-domain-names = "lcx", "lmx";
memory-region = <&pil_adsp_mem>;
+ qcom,qmp = <&aoss_qmp>;
+
qcom,smem-states = <&smp2p_adsp_out 0>;
qcom,smem-state-names = "stop";
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 08/12] arm64: dts: qcom: sdm845: Use QMP binding to control load state
Use the Qualcomm Mailbox Protocol (QMP) binding to control the load
state resources on SDM845 SoCs and drop deprecated power-domains exposed
by AOSS QMP node.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 0a86fe71a66d..22bc69240d2b 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -2984,6 +2984,8 @@
clock-names = "iface", "bus", "mem", "gpll0_mss",
"snoc_axi", "mnoc_axi", "prng", "xo";
+ qcom,qmp = <&aoss_qmp>;
+
qcom,smem-states = <&modem_smp2p_out 0>;
qcom,smem-state-names = "stop";
@@ -2993,11 +2995,10 @@
qcom,halt-regs = <&tcsr_mutex_regs 0x23000 0x25000
0x24000>;
- power-domains = <&aoss_qmp 2>,
- <&rpmhpd SDM845_CX>,
+ power-domains = <&rpmhpd SDM845_CX>,
<&rpmhpd SDM845_MX>,
<&rpmhpd SDM845_MSS>;
- power-domain-names = "load_state", "cx", "mx", "mss";
+ power-domain-names = "cx", "mx", "mss";
mba {
memory-region = <&mba_region>;
@@ -4582,7 +4583,6 @@
mboxes = <&apss_shared 0>;
#clock-cells = <0>;
- #power-domain-cells = <1>;
cx_cdev: cx {
#cooling-cells = <2>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 12/12] dt-bindings: soc: qcom: aoss: Delete unused power-domain definitions
Delete unused power-domain definitions exposed by AOSS QMP. Signed-off-by: Sibi Sankar --- include/dt-bindings/power/qcom-aoss-qmp.h | 14 -- 1 file changed, 14 deletions(-) delete mode 100644 include/dt-bindings/power/qcom-aoss-qmp.h diff --git a/include/dt-bindings/power/qcom-aoss-qmp.h b/include/dt-bindings/power/qcom-aoss-qmp.h deleted file mode 100644 index ec336d31dee4.. --- a/include/dt-bindings/power/qcom-aoss-qmp.h +++ /dev/null @@ -1,14 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -/* Copyright (c) 2018, Linaro Ltd. */ - -#ifndef __DT_BINDINGS_POWER_QCOM_AOSS_QMP_H -#define __DT_BINDINGS_POWER_QCOM_AOSS_QMP_H - -#define AOSS_QMP_LS_CDSP 0 -#define AOSS_QMP_LS_LPASS 1 -#define AOSS_QMP_LS_MODEM 2 -#define AOSS_QMP_LS_SLPI 3 -#define AOSS_QMP_LS_SPSS 4 -#define AOSS_QMP_LS_VENUS 5 - -#endif -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 09/12] arm64: dts: qcom: sm8150: Use QMP binding to control load state
Use the Qualcomm Mailbox Protocol (QMP) binding to control the load
state resources on SM8150 SoCs and drop deprecated power-domains exposed
by AOSS QMP node.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index 51235a9521c2..19f6bc268b9d 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -5,7 +5,6 @@
*/
#include
-#include
#include
#include
#include
@@ -1040,13 +1039,14 @@
clocks = <&rpmhcc RPMH_CXO_CLK>;
clock-names = "xo";
- power-domains = <&aoss_qmp AOSS_QMP_LS_SLPI>,
- <&rpmhpd 3>,
+ power-domains = <&rpmhpd 3>,
<&rpmhpd 2>;
- power-domain-names = "load_state", "lcx", "lmx";
+ power-domain-names = "lcx", "lmx";
memory-region = <&slpi_mem>;
+ qcom,qmp = <&aoss_qmp>;
+
qcom,smem-states = <&slpi_smp2p_out 0>;
qcom,smem-state-names = "stop";
@@ -1486,13 +1486,14 @@
clocks = <&rpmhcc RPMH_CXO_CLK>;
clock-names = "xo";
- power-domains = <&aoss_qmp AOSS_QMP_LS_MODEM>,
- <&rpmhpd 7>,
+ power-domains = <&rpmhpd 7>,
<&rpmhpd 0>;
- power-domain-names = "load_state", "cx", "mss";
+ power-domain-names = "cx", "mss";
memory-region = <&mpss_mem>;
+ qcom,qmp = <&aoss_qmp>;
+
qcom,smem-states = <&modem_smp2p_out 0>;
qcom,smem-state-names = "stop";
@@ -2110,12 +2111,12 @@
clocks = <&rpmhcc RPMH_CXO_CLK>;
clock-names = "xo";
- power-domains = <&aoss_qmp AOSS_QMP_LS_CDSP>,
- <&rpmhpd 7>;
- power-domain-names = "load_state", "cx";
+ power-domains = <&rpmhpd 7>;
memory-region = <&cdsp_mem>;
+ qcom,qmp = <&aoss_qmp>;
+
qcom,smem-states = <&cdsp_smp2p_out 0>;
qcom,smem-state-names = "stop";
@@ -2339,7 +2340,6 @@
mboxes = <&apss_shared 0>;
#clock-cells = <0>;
- #power-domain-cells = <1>;
};
tsens0: thermal-sensor@c263000 {
@@ -2486,12 +2486,12 @@
clocks = <&rpmhcc RPMH_CXO_CLK>;
clock-names = "xo";
- power-domains = <&aoss_qmp AOSS_QMP_LS_LPASS>,
- <&rpmhpd 7>;
- power-domain-names = "load_state", "cx";
+ power-domains = <&rpmhpd 7>;
memory-region = <&adsp_mem>;
+ qcom,qmp = <&aoss_qmp>;
+
qcom,smem-states = <&adsp_smp2p_out 0>;
qcom,smem-state-names = "stop";
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 07/12] arm64: dts: qcom: sc7280: Use QMP binding to control load state
Use the Qualcomm Mailbox Protocol (QMP) binding to control the load
state resources on SC7280 SoCs and drop deprecated power-domains exposed
by AOSS QMP node.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 2cc478553935..0ee0e492b183 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -9,7 +9,6 @@
#include
#include
#include
-#include
#include
#include
@@ -835,7 +834,6 @@
IPCC_MPROC_SIGNAL_GLINK_QMP>;
#clock-cells = <0>;
- #power-domain-cells = <1>;
};
spmi_bus: spmi@c44 {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 04/12] dt-bindings: remoteproc: qcom: Add QMP bindings
Add Qualcomm Mailbox Protocol (QMP) binding to replace the power domains exposed by the AOSS QMP node. Signed-off-by: Sibi Sankar --- Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt index 69c49c7b2cff..494257010629 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt @@ -174,7 +174,12 @@ For the compatible string below the following supplies are required: must be "cx", "mx" qcom,sc7180-mss-pil: qcom,sdm845-mss-pil: - must be "cx", "mx", "mss", "load_state" + must be "cx", "mx", "mss" + +- qcom,qmp: + Usage: optional + Value type: + Definition: reference to the AOSS side-channel message RAM. - qcom,smem-states: Usage: required -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 06/12] arm64: dts: qcom: sc7180: Use QMP binding to control load state
Use the Qualcomm Mailbox Protocol (QMP) binding to control the load
state resources on SC7180 SoCs and drop deprecated power-domains exposed
by AOSS QMP node.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index a6da78d31fdd..6b55d74e2534 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -15,7 +15,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -1998,14 +1997,15 @@
clock-names = "iface", "bus", "nav", "snoc_axi",
"mnoc_axi", "xo";
- power-domains = <&aoss_qmp AOSS_QMP_LS_MODEM>,
- <&rpmhpd SC7180_CX>,
+ power-domains = <&rpmhpd SC7180_CX>,
<&rpmhpd SC7180_MX>,
<&rpmhpd SC7180_MSS>;
- power-domain-names = "load_state", "cx", "mx", "mss";
+ power-domain-names = "cx", "mx", "mss";
memory-region = <&mpss_mem>;
+ qcom,qmp = <&aoss_qmp>;
+
qcom,smem-states = <&modem_smp2p_out 0>;
qcom,smem-state-names = "stop";
@@ -3220,7 +3220,6 @@
mboxes = <&apss_shared 0>;
#clock-cells = <0>;
- #power-domain-cells = <1>;
};
spmi_bus: spmi@c44 {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 05/12] remoteproc: qcom: q6v5: Use qmp_send to update co-processor load state
The power domains exposed by the AOSS QMP driver control the load state
resources linked to modem, adsp, cdsp remoteprocs. These are used to
notify the Always on Subsystem (AOSS) that a particular co-processor is
up/down. AOSS uses this information to wait for the co-processors to
suspend before starting its sleep sequence.
These co-processors enter low-power modes independent to that of the
application processor and the load state resources linked to them are
expected to remain unaltered across system suspend/resume cycles. To
achieve this behavior lets stop using the power-domains exposed by the
AOSS QMP node and replace them with generic qmp_send interface instead.
Signed-off-by: Sibi Sankar
---
drivers/remoteproc/qcom_q6v5.c | 57 +-
drivers/remoteproc/qcom_q6v5.h | 7 +++-
drivers/remoteproc/qcom_q6v5_adsp.c | 7 +++-
drivers/remoteproc/qcom_q6v5_mss.c | 44
drivers/remoteproc/qcom_q6v5_pas.c | 80 +
drivers/remoteproc/qcom_q6v5_wcss.c | 4 +-
6 files changed, 95 insertions(+), 104 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
index 9627a950928e..be78a286b3ec 100644
--- a/drivers/remoteproc/qcom_q6v5.c
+++ b/drivers/remoteproc/qcom_q6v5.c
@@ -16,8 +16,28 @@
#include "qcom_common.h"
#include "qcom_q6v5.h"
+#define Q6V5_LOAD_STATE_MSG_LEN64
#define Q6V5_PANIC_DELAY_MS200
+static int q6v5_load_state_toggle(struct qcom_q6v5 *q6v5, bool enable)
+{
+ char buf[Q6V5_LOAD_STATE_MSG_LEN] = {};
+ int ret;
+
+ if (IS_ERR(q6v5->qmp))
+ return 0;
+
+ snprintf(buf, sizeof(buf),
+"{class: image, res: load_state, name: %s, val: %s}",
+q6v5->load_state, enable ? "on" : "off");
+
+ ret = qmp_send(q6v5->qmp, buf, sizeof(buf));
+ if (ret)
+ dev_err(q6v5->dev, "failed to toggle load state\n");
+
+ return ret;
+}
+
/**
* qcom_q6v5_prepare() - reinitialize the qcom_q6v5 context before start
* @q6v5: reference to qcom_q6v5 context to be reinitialized
@@ -26,6 +46,12 @@
*/
int qcom_q6v5_prepare(struct qcom_q6v5 *q6v5)
{
+ int ret;
+
+ ret = q6v5_load_state_toggle(q6v5, true);
+ if (ret)
+ return ret;
+
reinit_completion(&q6v5->start_done);
reinit_completion(&q6v5->stop_done);
@@ -47,6 +73,7 @@ EXPORT_SYMBOL_GPL(qcom_q6v5_prepare);
int qcom_q6v5_unprepare(struct qcom_q6v5 *q6v5)
{
disable_irq(q6v5->handover_irq);
+ q6v5_load_state_toggle(q6v5, false);
return !q6v5->handover_issued;
}
@@ -196,12 +223,13 @@ EXPORT_SYMBOL_GPL(qcom_q6v5_panic);
* @pdev: platform_device reference for acquiring resources
* @rproc: associated remoteproc instance
* @crash_reason: SMEM id for crash reason string, or 0 if none
+ * @load_state: load state resource string
* @handover: function to be called when proxy resources should be released
*
* Return: 0 on success, negative errno on failure
*/
int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev,
- struct rproc *rproc, int crash_reason,
+ struct rproc *rproc, int crash_reason, const char
*load_state,
void (*handover)(struct qcom_q6v5 *q6v5))
{
int ret;
@@ -210,6 +238,7 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct
platform_device *pdev,
q6v5->dev = &pdev->dev;
q6v5->crash_reason = crash_reason;
q6v5->handover = handover;
+ q6v5->load_state = kstrdup_const(load_state, GFP_KERNEL);
init_completion(&q6v5->start_done);
init_completion(&q6v5->stop_done);
@@ -286,9 +315,35 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct
platform_device *pdev,
return PTR_ERR(q6v5->state);
}
+ q6v5->qmp = qmp_get(&pdev->dev);
+ if (IS_ERR(q6v5->qmp)) {
+ if (PTR_ERR(q6v5->qmp) != -ENODEV) {
+ if (PTR_ERR(q6v5->qmp) != -EPROBE_DEFER)
+ dev_err(&pdev->dev, "failed to acquire load
state\n");
+ return PTR_ERR(q6v5->qmp);
+ }
+ } else {
+ if (!q6v5->load_state) {
+ dev_err(&pdev->dev, "load state resource string
empty\n");
+ return -EINVAL;
+ }
+ }
+
return 0;
}
EXPORT_SYMBOL_GPL(qcom_q6v5_init);
+/**
+ * qcom_q6v5_deinit() - deinitialize the q6v5 common struct
+ * @q6v5: reference to qcom_q6v5 context to be deinitialized
+ * @pdev: platform_device reference for acquiring resources
+ */
+void qcom_q6v5_deinit(struct qcom_q6v5 *q6v5, struct platform_device *pdev)
+{
+ if (!IS_ERR(q6v5->qmp))
+ qmp_put(pdev);
+}
+EXPORT_SYMBOL_GPL(qcom_q6v5_deinit);
+
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("Qualcomm Peripheral Image Loader for Q6V5");
diff --git
[PATCH 02/12] soc: qcom: aoss: Drop power domain support
The load state resources are expected to follow the life cycle of the
remote processor it tracks. However, modeling load state resources as
power-domains result in them getting turned off during system suspend
and thereby falling out of sync with the remote processors that are still
on. Fix this by replacing load state resource control through the generic
qmp message send interface instead.
Signed-off-by: Sibi Sankar
---
drivers/soc/qcom/qcom_aoss.c | 109 ++-
1 file changed, 3 insertions(+), 106 deletions(-)
diff --git a/drivers/soc/qcom/qcom_aoss.c b/drivers/soc/qcom/qcom_aoss.c
index 51b32f6d9bdb..f084ea9f6b66 100644
--- a/drivers/soc/qcom/qcom_aoss.c
+++ b/drivers/soc/qcom/qcom_aoss.c
@@ -2,7 +2,6 @@
/*
* Copyright (c) 2019, Linaro Ltd
*/
-#include
#include
#include
#include
@@ -11,7 +10,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -68,7 +66,6 @@ struct qmp_cooling_device {
* @event: wait_queue for synchronization with the IRQ
* @tx_lock: provides synchronization between multiple callers of qmp_send()
* @qdss_clk: QDSS clock hw struct
- * @pd_data: genpd data
* @cooling_devs: thermal cooling devices
*/
struct qmp {
@@ -87,20 +84,12 @@ struct qmp {
struct mutex tx_lock;
struct clk_hw qdss_clk;
- struct genpd_onecell_data pd_data;
struct qmp_cooling_device *cooling_devs;
#if IS_ENABLED(CONFIG_DEBUG_FS)
struct dentry *debugfs_file;
#endif /* CONFIG_DEBUG_FS */
};
-struct qmp_pd {
- struct qmp *qmp;
- struct generic_pm_domain pd;
-};
-
-#define to_qmp_pd_resource(res) container_of(res, struct qmp_pd, pd)
-
static void qmp_kick(struct qmp *qmp)
{
mbox_send_message(qmp->mbox_chan, NULL);
@@ -329,95 +318,6 @@ static void qmp_qdss_clk_remove(struct qmp *qmp)
clk_hw_unregister(&qmp->qdss_clk);
}
-static int qmp_pd_power_toggle(struct qmp_pd *res, bool enable)
-{
- char buf[QMP_MSG_LEN] = {};
-
- snprintf(buf, sizeof(buf),
-"{class: image, res: load_state, name: %s, val: %s}",
-res->pd.name, enable ? "on" : "off");
- return qmp_send(res->qmp, buf, sizeof(buf));
-}
-
-static int qmp_pd_power_on(struct generic_pm_domain *domain)
-{
- return qmp_pd_power_toggle(to_qmp_pd_resource(domain), true);
-}
-
-static int qmp_pd_power_off(struct generic_pm_domain *domain)
-{
- return qmp_pd_power_toggle(to_qmp_pd_resource(domain), false);
-}
-
-static const char * const sdm845_resources[] = {
- [AOSS_QMP_LS_CDSP] = "cdsp",
- [AOSS_QMP_LS_LPASS] = "adsp",
- [AOSS_QMP_LS_MODEM] = "modem",
- [AOSS_QMP_LS_SLPI] = "slpi",
- [AOSS_QMP_LS_SPSS] = "spss",
- [AOSS_QMP_LS_VENUS] = "venus",
-};
-
-static int qmp_pd_add(struct qmp *qmp)
-{
- struct genpd_onecell_data *data = &qmp->pd_data;
- struct device *dev = qmp->dev;
- struct qmp_pd *res;
- size_t num = ARRAY_SIZE(sdm845_resources);
- int ret;
- int i;
-
- res = devm_kcalloc(dev, num, sizeof(*res), GFP_KERNEL);
- if (!res)
- return -ENOMEM;
-
- data->domains = devm_kcalloc(dev, num, sizeof(*data->domains),
-GFP_KERNEL);
- if (!data->domains)
- return -ENOMEM;
-
- for (i = 0; i < num; i++) {
- res[i].qmp = qmp;
- res[i].pd.name = sdm845_resources[i];
- res[i].pd.power_on = qmp_pd_power_on;
- res[i].pd.power_off = qmp_pd_power_off;
-
- ret = pm_genpd_init(&res[i].pd, NULL, true);
- if (ret < 0) {
- dev_err(dev, "failed to init genpd\n");
- goto unroll_genpds;
- }
-
- data->domains[i] = &res[i].pd;
- }
-
- data->num_domains = i;
-
- ret = of_genpd_add_provider_onecell(dev->of_node, data);
- if (ret < 0)
- goto unroll_genpds;
-
- return 0;
-
-unroll_genpds:
- for (i--; i >= 0; i--)
- pm_genpd_remove(data->domains[i]);
-
- return ret;
-}
-
-static void qmp_pd_remove(struct qmp *qmp)
-{
- struct genpd_onecell_data *data = &qmp->pd_data;
- struct device *dev = qmp->dev;
- int i;
-
- of_genpd_del_provider(dev->of_node);
-
- for (i = 0; i < data->num_domains; i++)
- pm_genpd_remove(data->domains[i]);
-}
-
static int qmp_cdev_get_max_state(struct thermal_cooling_device *cdev,
unsigned long *state)
{
@@ -636,13 +536,11 @@ static int qmp_probe(struct platform_device *pdev)
if (ret)
goto err_close_qmp;
- ret = qmp_pd_add(qmp);
- if (ret)
- goto err_remove_qdss_clk;
-
ret = qmp_cooling_devices_register(qmp);
- if (ret)
+ if (ret) {
dev_err(&pdev->dev, "failed to register aoss cooling
devices\n");
+
[PATCH 03/12] dt-bindings: remoteproc: qcom: pas: Add QMP bindings
Add Qualcomm Mailbox Protocol (QMP) binding to replace the power domains exposed by the AOSS QMP node. Signed-off-by: Sibi Sankar --- Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt index 1c330a8941f9..bc2a09c3c045 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt @@ -123,17 +123,22 @@ on the Qualcomm ADSP Hexagon core. qcom,sm8150-cdsp-pas: qcom,sm8250-cdsp-pas: qcom,sm8350-cdsp-pas: - must be "cx", "load_state" + must be "cx" qcom,sc7180-mpss-pas: qcom,sm8150-mpss-pas: qcom,sm8350-mpss-pas: - must be "cx", "load_state", "mss" + must be "cx", "mss" qcom,sm8250-adsp-pas: qcom,sm8350-adsp-pas: qcom,sm8150-slpi-pas: qcom,sm8250-slpi-pas: qcom,sm8350-slpi-pas: - must be "lcx", "lmx", "load_state" + must be "lcx", "lmx" + +- qcom,qmp: + Usage: optional + Value type: + Definition: reference to the AOSS side-channel message RAM. - memory-region: Usage: required -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 01/12] dt-bindings: soc: qcom: aoss: Drop power-domain bindings
Drop power-domain bindings exposed by AOSS QMP node.
Signed-off-by: Sibi Sankar
---
.../devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt
index 783dc81b0f26..c0ae051a5b76 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt
@@ -9,8 +9,7 @@ Messaging Protocol (QMP)
The AOSS side channel exposes control over a set of resources, used to control
a set of debug related clocks and to affect the low power state of resources
-related to the secondary subsystems. These resources are exposed as a set of
-power-domains.
+related to the secondary subsystems.
- compatible:
Usage: required
@@ -46,14 +45,6 @@ power-domains.
Definition: must be 0
The single clock represents the QDSS clock.
-- #power-domain-cells:
- Usage: optional
- Value type:
- Definition: must be 1
- The provided power-domains are:
- CDSP state (0), LPASS state (1), modem state (2), SLPI
- state (3), SPSS state (4) and Venus state (5).
-
= SUBNODES
The AOSS side channel also provides the controls for three cooling devices,
these are expressed as subnodes of the QMP node. The name of the node is used
@@ -66,8 +57,7 @@ to identify the resource and must therefor be "cx", "mx" or
"ebi".
= EXAMPLE
-The following example represents the AOSS side-channel message RAM and the
-mechanism exposing the power-domains, as found in SDM845.
+The following example represents the AOSS side-channel message RAM as found in
SDM845.
aoss_qmp: qmp@c30 {
compatible = "qcom,sdm845-aoss-qmp";
@@ -75,8 +65,6 @@ mechanism exposing the power-domains, as found in SDM845.
interrupts = ;
mboxes = <&apss_shared 0>;
- #power-domain-cells = <1>;
-
cx_cdev: cx {
#cooling-cells = <2>;
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 00/12] Use qmp_send to update co-processor load state
The power domains exposed by the AOSS QMP driver control the load state resources linked to modem, adsp, cdsp remoteprocs. These are used to notify the Always on Subsystem (AOSS) that a particular co-processor is up/down. AOSS uses this information to wait for the co-processors to suspend before starting its sleep sequence. These co-processors enter low-power modes independent to that of the application processor and the load state resources linked to them are expected to remain unaltered across system suspend/resume cycles. To achieve this behavior lets stop modeling them as power-domains and replace them with generic qmp_send interface instead. https://lore.kernel.org/lkml/20200913034603.GV3715@yoga/ Previous dicussion on dropping power-domain support from AOSS QMP driver https://lore.kernel.org/lkml/1617943188-23278-2-git-send-email-dee...@qti.qualcomm.com/ Depends on ^^ Sibi Sankar (12): dt-bindings: soc: qcom: aoss: Drop power-domain bindings soc: qcom: aoss: Drop power domain support dt-bindings: remoteproc: qcom: pas: Add QMP bindings dt-bindings: remoteproc: qcom: Add QMP bindings remoteproc: qcom: q6v5: Use qmp_send to update co-processor load state arm64: dts: qcom: sc7180: Use QMP binding to control load state arm64: dts: qcom: sc7280: Use QMP binding to control load state arm64: dts: qcom: sdm845: Use QMP binding to control load state arm64: dts: qcom: sm8150: Use QMP binding to control load state arm64: dts: qcom: sm8250: Use QMP binding to control load state arm64: dts: qcom: sm8350: Use QMP binding to control load state dt-bindings: soc: qcom: aoss: Delete unused power-domain definitions .../devicetree/bindings/remoteproc/qcom,adsp.txt | 11 ++- .../devicetree/bindings/remoteproc/qcom,q6v5.txt | 7 +- .../devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt | 16 +-- arch/arm64/boot/dts/qcom/sc7180.dtsi | 9 +- arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 - arch/arm64/boot/dts/qcom/sdm845.dtsi | 8 +- arch/arm64/boot/dts/qcom/sm8150.dtsi | 28 +++--- arch/arm64/boot/dts/qcom/sm8250.dtsi | 22 ++--- arch/arm64/boot/dts/qcom/sm8350.dtsi | 30 +++--- drivers/remoteproc/qcom_q6v5.c | 57 ++- drivers/remoteproc/qcom_q6v5.h | 7 +- drivers/remoteproc/qcom_q6v5_adsp.c| 7 +- drivers/remoteproc/qcom_q6v5_mss.c | 44 ++--- drivers/remoteproc/qcom_q6v5_pas.c | 80 --- drivers/remoteproc/qcom_q6v5_wcss.c| 4 +- drivers/soc/qcom/qcom_aoss.c | 109 + include/dt-bindings/power/qcom-aoss-qmp.h | 14 --- 17 files changed, 163 insertions(+), 292 deletions(-) delete mode 100644 include/dt-bindings/power/qcom-aoss-qmp.h -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[patch] x86/crash: fix crash_setup_memmap_entries() out-of-bounds access
[ 15.428011] BUG: KASAN: vmalloc-out-of-bounds in
crash_setup_memmap_entries+0x17e/0x3a0
[ 15.428018] Write of size 8 at addr c9426008 by task kexec/1187
(gdb) list *crash_setup_memmap_entries+0x17e
0x8107cafe is in crash_setup_memmap_entries
(arch/x86/kernel/crash.c:322).
317 unsigned long long mend)
318 {
319 unsigned long start, end;
320
321 cmem->ranges[0].start = mstart;
322 cmem->ranges[0].end = mend;
323 cmem->nr_ranges = 1;
324
325 /* Exclude elf header region */
326 start = image->arch.elf_load_addr;
(gdb)
Append missing struct crash_mem_range to cmem.
Signed-off-by: Mike Galbraith
---
arch/x86/kernel/crash.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -337,7 +337,7 @@ int crash_setup_memmap_entries(struct ki
struct crash_memmap_data cmd;
struct crash_mem *cmem;
- cmem = vzalloc(sizeof(struct crash_mem));
+ cmem = vzalloc(struct_size(cmem, ranges, 1));
if (!cmem)
return -ENOMEM;
[PATCH] ASoC: ak4458: check reset control status
From: Viorel Suman
check the return value of ak4458_rstn_control.
Signed-off-by: Viorel Suman
Signed-off-by: Shengjiu Wang
---
sound/soc/codecs/ak4458.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/sound/soc/codecs/ak4458.c b/sound/soc/codecs/ak4458.c
index 85a1d00894a9..0a94973889a1 100644
--- a/sound/soc/codecs/ak4458.c
+++ b/sound/soc/codecs/ak4458.c
@@ -419,8 +419,13 @@ static int ak4458_hw_params(struct snd_pcm_substream
*substream,
snd_soc_component_update_bits(component, AK4458_00_CONTROL1,
AK4458_DIF_MASK, format);
- ak4458_rstn_control(component, 0);
- ak4458_rstn_control(component, 1);
+ ret = ak4458_rstn_control(component, 0);
+ if (ret)
+ return ret;
+
+ ret = ak4458_rstn_control(component, 1);
+ if (ret)
+ return ret;
return 0;
}
@@ -429,6 +434,7 @@ static int ak4458_set_dai_fmt(struct snd_soc_dai *dai,
unsigned int fmt)
{
struct snd_soc_component *component = dai->component;
struct ak4458_priv *ak4458 = snd_soc_component_get_drvdata(component);
+ int ret;
switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
case SND_SOC_DAIFMT_CBS_CFS: /* Slave Mode */
@@ -461,8 +467,13 @@ static int ak4458_set_dai_fmt(struct snd_soc_dai *dai,
unsigned int fmt)
ak4458->fmt == SND_SOC_DAIFMT_PDM ?
AK4458_DP_MASK : 0);
- ak4458_rstn_control(component, 0);
- ak4458_rstn_control(component, 1);
+ ret = ak4458_rstn_control(component, 0);
+ if (ret)
+ return ret;
+
+ ret = ak4458_rstn_control(component, 1);
+ if (ret)
+ return ret;
return 0;
}
--
2.27.0
Re: [PATCH v3 1/2] perf/core: Share an event with multiple cgroups
On Fri, Apr 16, 2021 at 08:22:38PM +0900, Namhyung Kim wrote: > On Fri, Apr 16, 2021 at 7:28 PM Peter Zijlstra wrote: > > > > On Fri, Apr 16, 2021 at 11:29:30AM +0200, Peter Zijlstra wrote: > > > > > > So I think we've had proposals for being able to close fds in the past; > > > > while preserving groups etc. We've always pushed back on that because of > > > > the resource limit issue. By having each counter be a filedesc we get a > > > > natural limit on the amount of resources you can consume. And in that > > > > respect, having to use 400k fds is things working as designed. > > > > > > > > Anyway, there might be a way around this.. > > > > So how about we flip the whole thing sideways, instead of doing one > > event for multiple cgroups, do an event for multiple-cpus. > > > > Basically, allow: > > > > perf_event_open(.pid=fd, cpu=-1, .flag=PID_CGROUP); > > > > Which would have the kernel create nr_cpus events [the corrolary is that > > we'd probably also allow: (.pid=-1, cpu=-1) ]. > > Do you mean it'd have separate perf_events per cpu internally? > From a cpu's perspective, there's nothing changed, right? > Then it will have the same performance problem as of now. Yes, but we'll not end up in ioctl() hell. The interface is sooo much better. The performance thing just means we need to think harder. I thought cgroup scheduling got a lot better with the work Ian did a while back? What's the actual bottleneck now? > > Output could be done by adding FORMAT_PERCPU, which takes the current > > read() format and writes a copy for each CPU event. (p)read(v)() could > > be used to explode or partial read that. > > Yeah, I think it's good for read. But what about mmap? > I don't think we can use file offset since it's taken for auxtrace. > Maybe we can simply disallow that.. Are you actually using mmap() to read? I had a proposal for FORMAT_GROUP like thing for mmap(), but I never implemented that (didn't get the enthousiatic response I thought it would). But yeah, there's nowhere near enough space in there for PERCPU. Not sure how to do that, these counters must not be sampling counters because we can't be sharing a buffer from multiple CPUs, so data/aux just isn't a concern. But it's weird to have them magically behave differently.
Re: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved pages
On 16.04.21 13:44, Mike Rapoport wrote: On Thu, Apr 15, 2021 at 11:30:12AM +0200, David Hildenbrand wrote: Not sure we really need a new pagetype here, PG_Reserved seems to be quite enough to say "don't touch this". I generally agree that we could make PG_Reserved a PageType and then have several sub-types for reserved memory. This definitely will add clarity but I'm not sure that this justifies amount of churn and effort required to audit uses of PageResrved(). Then, we could mostly avoid having to query memblock at runtime to figure out that this is special memory. This would obviously be an extension to this series. Just a thought. Stop pushing memblock out of kernel! ;-) Can't stop. Won't stop. :D It's lovely for booting up a kernel until we have other data-structures in place ;) A bit more seriously, we don't have any data structure that reliably represents physical memory layout and arch-independent fashion. memblock is probably the best starting point for eventually having one. We have the (slowish) kernel resource tree after boot and the (faster) memmap. I really don't see why we really need another slowish variant. We might be better off to just extend and speed up the kernel resource tree. Memblock as is is not a reasonable datastructure to keep around after boot: for example, how we handle boottime allocations and reserve regions both as reserved. -- Thanks, David / dhildenb
Re: [PATCH] tcp: fix silent loss when syncookie is trigered
On Fri, Apr 16, 2021 at 12:52 PM zhaoya wrote: > > When syncookie is triggered, since $MSSID is spliced into cookie and > the legal index of msstab is 0,1,2,3, this gives client 3 bytes > of freedom, resulting in at most 3 bytes of silent loss. > > C seq=12345-> S > C <--seq=cookie/ack=12346 S S generated the cookie > [RFC4987 Appendix A] > C ---seq=123456/ack=cookie+1-->X S The first byte was loss. > C -seq=123457/ack=cookie+1--> S The second byte was received and > cookie-check was still okay and > handshake was finished. > C
Re: [PATCH 4.9 00/47] 4.9.267-rc1 review
On Thu, 15 Apr 2021 at 20:23, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.267 release. > There are 47 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat, 17 Apr 2021 14:44:01 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.267-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing ## Build * kernel: 4.9.267-rc1 * git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git * git branch: linux-4.9.y * git commit: 5183cf83a541a4684e52ca704658b93e63fdf243 * git describe: v4.9.266-48-g5183cf83a541 * test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.9.y/build/v4.9.266-48-g5183cf83a541 ## No regressions (compared to v4.9.266-43-ga0c17d36dea3) ## No fixes (compared to v4.9.266-43-ga0c17d36dea3) ## Test result summary total: 54076, pass: 44392, fail: 544, skip: 8849, xfail: 291, ## Build Summary * arm: 96 total, 96 passed, 0 failed * arm64: 23 total, 23 passed, 0 failed * dragonboard-410c: 1 total, 1 passed, 0 failed * hi6220-hikey: 1 total, 1 passed, 0 failed * i386: 13 total, 13 passed, 0 failed * juno-r2: 1 total, 1 passed, 0 failed * mips: 36 total, 36 passed, 0 failed * sparc: 9 total, 9 passed, 0 failed * x15: 1 total, 1 passed, 0 failed * x86: 1 total, 1 passed, 0 failed * x86_64: 13 total, 13 passed, 0 failed ## Test suites summary * fwts * igt-gpu-tools * install-android-platform-tools-r2600 * kselftest-android * kselftest-bpf * kselftest-capabilities * kselftest-cgroup * kselftest-clone3 * kselftest-core * kselftest-cpu-hotplug * kselftest-cpufreq * kselftest-efivarfs * kselftest-filesystems * kselftest-firmware * kselftest-fpu * kselftest-futex * kselftest-gpio * kselftest-intel_pstate * kselftest-ipc * kselftest-ir * kselftest-kcmp * kselftest-kexec * kselftest-kvm * kselftest-lib * kselftest-livepatch * kselftest-lkdtm * kselftest-membarrier * kselftest-ptrace * kselftest-rseq * kselftest-rtc * kselftest-seccomp * kselftest-sigaltstack * kselftest-size * kselftest-splice * kselftest-static_keys * kselftest-sync * kselftest-sysctl * kselftest-timens * kselftest-timers * kselftest-tmpfs * kselftest-tpm2 * kselftest-user * kselftest-vm * kselftest-x86 * kselftest-zram * kvm-unit-tests * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-open-posix-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-tracing-tests * network-basic-tests * perf * ssuite * v4l2-compliance -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH] coresight: add support to enable more coresight paths
On 2021-04-15 17:49, Suzuki K Poulose wrote:
Hi
On 15/04/2021 10:33, Tao Zhang wrote:
Current coresight implementation only supports enabling source
ETMs or STM. This patch adds support to enable more kinds of
coresight source to sink paths. We build a path from source to
sink when any source is enabled and store it in a list. When the
source is disabled, we fetch the corresponding path from the list
and decrement the refcount on each device in the path. The device
is disabled if the refcount reaches zero. Don't store path to
coresight data structure of source to avoid unnecessary change to
ABI.
Since some targets may have coresight sources other than STM and
ETMs, we need to add this change to support these coresight
devices.
While I am not against the patch, I would like to see why this change
is
needed. Which compnents are we talking about , other than STM / ETM ?
Where is the "device" support code ? Without a legitimate user, we
cannot add this change in.
Some other comments below.
We will upload coresight source device driver code in addition to
STM/ETM in the future. This patch is only our first step. e.g, this
patch can support to build a path from TPDM(a kind of coresight source
device on Qualcomm target) to sink. At the same time, this patch also
can support coresight source devices other than STM/ETM on the other
targets.
Signed-off-by: Satyajit Desai
Signed-off-by: Rama Aparna Mallavarapu
Signed-off-by: Mulu He
Signed-off-by: Tingwei Zhang
Signed-off-by: Tao Zhang
---
drivers/hwtracing/coresight/coresight-core.c | 101
+++
1 file changed, 56 insertions(+), 45 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-core.c
b/drivers/hwtracing/coresight/coresight-core.c
index 4ba801d..7dfadb6 100644
--- a/drivers/hwtracing/coresight/coresight-core.c
+++ b/drivers/hwtracing/coresight/coresight-core.c
@@ -35,18 +35,16 @@ struct coresight_node {
};
/*
- * When operating Coresight drivers from the sysFS interface, only a
single
- * path can exist from a tracer (associated to a CPU) to a sink.
+ * struct coresight_path - path from source to sink
+ * @path: Address of path list.
+ * @link: hook to the list.
*/
-static DEFINE_PER_CPU(struct list_head *, tracer_path);
+struct coresight_path {
+ struct list_head *path;
+ struct list_head link;
+};
-/*
- * As of this writing only a single STM can be found in CS
topologies. Since
- * there is no way to know if we'll ever see more and what kind of
- * configuration they will enact, for the time being only define a
single path
- * for STM.
- */
-static struct list_head *stm_path;
+static LIST_HEAD(cs_active_paths);
/*
* When losing synchronisation a new barrier packet needs to be
inserted at the
@@ -326,7 +324,7 @@ static void coresight_disable_sink(struct
coresight_device *csdev)
if (ret)
return;
coresight_control_assoc_ectdev(csdev, false);
- csdev->enable = false;
+ csdev->activated = false;
}
static int coresight_enable_link(struct coresight_device *csdev,
@@ -562,6 +560,20 @@ int coresight_enable_path(struct list_head *path,
u32 mode, void *sink_data)
goto out;
}
+static struct coresight_device *coresight_get_source(struct
list_head *path)
+{
+ struct coresight_device *csdev;
+
+ if (!path)
+ return NULL;
+
+ csdev = list_first_entry(path, struct coresight_node, link)->csdev;
+ if (csdev->type != CORESIGHT_DEV_TYPE_SOURCE)
+ return NULL;
+
+ return csdev;
+}
+
struct coresight_device *coresight_get_sink(struct list_head *path)
{
struct coresight_device *csdev;
@@ -1047,9 +1059,23 @@ static int coresight_validate_source(struct
coresight_device *csdev,
return 0;
}
+static int coresight_store_path(struct list_head *path)
+{
+ struct coresight_path *node;
+
+ node = kzalloc(sizeof(struct coresight_path), GFP_KERNEL);
Have you run this with all the "DEBUG" whistles turned on ? This could
be problematic when called from a context where you are not allowed to
sleep. e.g, perf enable call back.
Only coresight_enable function will call coresight_store_path, and seems
like coresight_enable function should be allowed to sleep since it is
protected by Mutex. And I find in function coresight_build_path also
will call kzalloc. Do you have any other concerns about calling kzalloc
here?
+ if (!node)
+ return -ENOMEM;
+
+ node->path = path;
+ list_add(&node->link, &cs_active_paths);
+
+ return 0;
+}
+
int coresight_enable(struct coresight_device *csdev)
{
- int cpu, ret = 0;
+ int ret = 0;
struct coresight_device *sink;
struct list_head *path;
enum coresight_dev_subtype_source subtype;
@@ -1094,25 +1120,9 @@ int coresight_enable(struct coresight_device
*csdev)
if (ret)
goto err_source;
-
[PATCH 5/5] mtd: core: add OTP nvmem provider support
Flash OTP regions can already be read via user space. Some boards have
their serial number or MAC addresses stored in the OTP regions. Add
support for them being a (read-only) nvmem provider.
The API to read the OTP data is already in place. It distinguishes
between factory and user OTP, thus there are up to two different
providers.
Signed-off-by: Michael Walle
---
Changes since RFC:
- none
drivers/mtd/mtdcore.c | 149
include/linux/mtd/mtd.h | 2 +
2 files changed, 151 insertions(+)
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 0bc6871c3863..92201e3d187a 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -777,6 +777,147 @@ static void mtd_set_dev_defaults(struct mtd_info *mtd)
mutex_init(&mtd->master.chrdev_lock);
}
+static ssize_t mtd_otp_size(struct mtd_info *mtd, bool is_user)
+{
+ struct otp_info *info = kmalloc(PAGE_SIZE, GFP_KERNEL);
+ ssize_t size = 0;
+ unsigned int i;
+ size_t retlen;
+ int ret;
+
+ if (is_user)
+ ret = mtd_get_user_prot_info(mtd, PAGE_SIZE, &retlen, info);
+ else
+ ret = mtd_get_fact_prot_info(mtd, PAGE_SIZE, &retlen, info);
+ if (ret)
+ goto err;
+
+ for (i = 0; i < retlen / sizeof(*info); i++) {
+ size += info->length;
+ info++;
+ }
+
+ kfree(info);
+ return size;
+
+err:
+ kfree(info);
+ return ret;
+}
+
+static struct nvmem_device *mtd_otp_nvmem_register(struct mtd_info *mtd,
+ const char *name, int size,
+ nvmem_reg_read_t reg_read,
+ const char *compatible)
+{
+ struct nvmem_device *nvmem = NULL;
+ struct nvmem_config config = {};
+ struct device_node *np;
+
+ /* DT binding is optional */
+ np = of_get_compatible_child(mtd->dev.of_node, compatible);
+
+ /* OTP nvmem will be registered on the physical device */
+ config.dev = mtd->dev.parent;
+ config.name = name;
+ config.id = NVMEM_DEVID_NONE;
+ config.owner = THIS_MODULE;
+ config.type = NVMEM_TYPE_OTP;
+ config.root_only = true;
+ config.reg_read = reg_read;
+ config.size = size;
+ config.of_node = np;
+ config.priv = mtd;
+
+ nvmem = nvmem_register(&config);
+ /* Just ignore if there is no NVMEM support in the kernel */
+ if (IS_ERR(nvmem) && PTR_ERR(nvmem) == -EOPNOTSUPP)
+ nvmem = NULL;
+
+ of_node_put(np);
+
+ return nvmem;
+}
+
+static int mtd_nvmem_user_otp_reg_read(void *priv, unsigned int offset,
+ void *val, size_t bytes)
+{
+ struct mtd_info *mtd = priv;
+ size_t retlen;
+ int ret;
+
+ ret = mtd_read_user_prot_reg(mtd, offset, bytes, &retlen, val);
+ if (ret)
+ return ret;
+
+ return retlen == bytes ? 0 : -EIO;
+}
+
+static int mtd_nvmem_fact_otp_reg_read(void *priv, unsigned int offset,
+ void *val, size_t bytes)
+{
+ struct mtd_info *mtd = priv;
+ size_t retlen;
+ int ret;
+
+ ret = mtd_read_fact_prot_reg(mtd, offset, bytes, &retlen, val);
+ if (ret)
+ return ret;
+
+ return retlen == bytes ? 0 : -EIO;
+}
+
+static int mtd_otp_nvmem_add(struct mtd_info *mtd)
+{
+ struct nvmem_device *nvmem;
+ ssize_t size;
+ int err;
+
+ if (mtd->_get_user_prot_info && mtd->_read_user_prot_reg) {
+ size = mtd_otp_size(mtd, true);
+ if (size < 0)
+ return size;
+
+ if (size > 0) {
+ nvmem = mtd_otp_nvmem_register(mtd, "user-otp", size,
+
mtd_nvmem_user_otp_reg_read,
+ "mtd-user-otp");
+ if (IS_ERR(nvmem)) {
+ dev_err(&mtd->dev, "Failed to register OTP
NVMEM device\n");
+ return PTR_ERR(nvmem);
+ }
+ mtd->otp_user_nvmem = nvmem;
+ }
+ }
+
+ if (mtd->_get_fact_prot_info && mtd->_read_fact_prot_reg) {
+ size = mtd_otp_size(mtd, false);
+ if (size < 0) {
+ err = size;
+ goto err;
+ }
+
+ if (size > 0) {
+ nvmem = mtd_otp_nvmem_register(mtd, "factory-otp", size,
+
mtd_nvmem_fact_otp_reg_read,
+ "mtd-factory-otp");
+ if (IS_ERR(nvmem)) {
+ dev_err(&mtd->dev, "Failed to register OTP
NVMEM device
[PATCH 2/5] dt-bindings: mtd: add YAML schema for the generic MTD bindings
Convert MTD's common.txt to mtd.yaml.
Signed-off-by: Michael Walle
Reviewed-by: Rob Herring
---
Changes since RFC:
- use real device compatibles
.../devicetree/bindings/mtd/common.txt| 16 +---
.../devicetree/bindings/mtd/mtd.yaml | 39 +++
2 files changed, 40 insertions(+), 15 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mtd/mtd.yaml
diff --git a/Documentation/devicetree/bindings/mtd/common.txt
b/Documentation/devicetree/bindings/mtd/common.txt
index fc068b923d7a..ae16f9ea8606 100644
--- a/Documentation/devicetree/bindings/mtd/common.txt
+++ b/Documentation/devicetree/bindings/mtd/common.txt
@@ -1,15 +1 @@
-* Common properties of all MTD devices
-
-Optional properties:
-- label: user-defined MTD device name. Can be used to assign user
- friendly names to MTD devices (instead of the flash model or flash
- controller based name) in order to ease flash device identification
- and/or describe what they are used for.
-
-Example:
-
- flash@0 {
- label = "System-firmware";
-
- /* flash type specific properties */
- };
+This file has been moved to mtd.yaml.
diff --git a/Documentation/devicetree/bindings/mtd/mtd.yaml
b/Documentation/devicetree/bindings/mtd/mtd.yaml
new file mode 100644
index ..086b0ecd1604
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/mtd.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/mtd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MTD (Memory Technology Device) Device Tree Bindings
+
+maintainers:
+ - Miquel Raynal
+ - Richard Weinberger
+
+properties:
+ $nodename:
+pattern: "^flash(@.*)?$"
+
+ label:
+description:
+ User-defined MTD device name. Can be used to assign user friendly
+ names to MTD devices (instead of the flash model or flash controller
+ based name) in order to ease flash device identification and/or
+ describe what they are used for.
+
+additionalProperties: true
+
+examples:
+ - |
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+flash@0 {
+reg = <0>;
+compatible = "jedec,spi-nor";
+label = "System-firmware";
+};
+};
+
+...
--
2.20.1
[PATCH 4/5] dt-bindings: mtd: spi-nor: add otp property
SPI-NOR flashes may have OTP regions and have a nvmem binding. This binding is described in mtd.yaml. Signed-off-by: Michael Walle --- Changes since RFC: - new patch Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml index 5e7e5349f9a1..ed590d7c6e37 100644 --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml @@ -9,6 +9,9 @@ title: SPI NOR flash ST M25Pxx (and similar) serial flash chips maintainers: - Rob Herring +allOf: + - $ref: "mtd.yaml#" + properties: compatible: oneOf: @@ -82,6 +85,9 @@ patternProperties: '^partition@': type: object + "^otp(-[0-9]+)?$": +type: object + additionalProperties: false examples: -- 2.20.1
[PATCH 3/5] dt-bindings: mtd: add OTP bindings
Flash devices can have one-time-programmable regions. Add a nvmem
binding so they can be used as a nvmem provider.
Signed-off-by: Michael Walle
---
Changes since RFC:
- added missing "$"
- dropped first example
- use real device compatibles
Please note, that this will lead to an error without patch 4/5, which
introduces that property for the jedec,spi-nor. Should I keep it
seperate or should I squash that patch into this one?
.../devicetree/bindings/mtd/mtd.yaml | 50 +++
1 file changed, 50 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/mtd.yaml
b/Documentation/devicetree/bindings/mtd/mtd.yaml
index 086b0ecd1604..dd43fb8b4fd1 100644
--- a/Documentation/devicetree/bindings/mtd/mtd.yaml
+++ b/Documentation/devicetree/bindings/mtd/mtd.yaml
@@ -21,6 +21,25 @@ properties:
based name) in order to ease flash device identification and/or
describe what they are used for.
+patternProperties:
+ "^otp(-[0-9]+)?$":
+type: object
+$ref: ../nvmem/nvmem.yaml#
+
+description: |
+ An OTP memory region. Some flashes provide a one-time-programmable
+ memory whose content can either be programmed by a user or is already
+ pre-programmed by the factory. Some flashes might provide both.
+
+properties:
+ compatible:
+enum:
+ - mtd-user-otp
+ - mtd-factory-otp
+
+required:
+ - compatible
+
additionalProperties: true
examples:
@@ -36,4 +55,35 @@ examples:
};
};
+ - |
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+flash@0 {
+reg = <0>;
+compatible = "jedec,spi-nor";
+
+otp-1 {
+compatible = "mtd-factory-otp";
+#address-cells = <1>;
+#size-cells = <1>;
+
+electronic-serial-number@0 {
+reg = <0 8>;
+};
+};
+
+otp-2 {
+compatible = "mtd-user-otp";
+#address-cells = <1>;
+#size-cells = <1>;
+
+mac-address@0 {
+reg = <0 6>;
+};
+};
+};
+};
+
...
--
2.20.1
[PATCH 1/5] nvmem: core: allow specifying of_node
Until now, the of_node of the parent device is used. Some devices
provide more than just the nvmem provider. To avoid name space clashes,
add a way to allow specifying the nvmem cells in subnodes. Consider the
following example:
flash@0 {
compatible = "jedec,spi-nor";
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
reg = <0x00 0x01>;
};
};
otp {
compatible = "mtd-user-otp";
#address-cells = <1>;
#size-cells = <1>;
serial-number@0 {
reg = <0x0 0x8>;
};
};
};
There the nvmem provider might be the MTD partition or the OTP region of
the flash.
Add a new config->of_node parameter, which if set, will be used instead
of the parent's of_node.
Signed-off-by: Michael Walle
Acked-by: Srinivas Kandagatla
---
Changes since RFC:
- none
drivers/nvmem/core.c | 4 +++-
include/linux/nvmem-provider.h | 2 ++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index bca671ff4e54..62d363a399d3 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -789,7 +789,9 @@ struct nvmem_device *nvmem_register(const struct
nvmem_config *config)
nvmem->reg_write = config->reg_write;
nvmem->keepout = config->keepout;
nvmem->nkeepout = config->nkeepout;
- if (!config->no_of_node)
+ if (config->of_node)
+ nvmem->dev.of_node = config->of_node;
+ else if (!config->no_of_node)
nvmem->dev.of_node = config->dev->of_node;
switch (config->id) {
diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h
index e162b757b6d5..471cb7b9e896 100644
--- a/include/linux/nvmem-provider.h
+++ b/include/linux/nvmem-provider.h
@@ -57,6 +57,7 @@ struct nvmem_keepout {
* @type: Type of the nvmem storage
* @read_only: Device is read-only.
* @root_only: Device is accessibly to root only.
+ * @of_node: If given, this will be used instead of the parent's of_node.
* @no_of_node:Device should not use the parent's of_node even if it's
!NULL.
* @reg_read: Callback to read data.
* @reg_write: Callback to write data.
@@ -86,6 +87,7 @@ struct nvmem_config {
enum nvmem_type type;
boolread_only;
boolroot_only;
+ struct device_node *of_node;
boolno_of_node;
nvmem_reg_read_treg_read;
nvmem_reg_write_t reg_write;
--
2.20.1
[PATCH 0/5] mtd: core: OTP nvmem provider support
The goal is to fetch a (base) MAC address from the OTP region of a SPI NOR
flash.
This is the first part, where I try to add the nvmem provider support to
the MTD core.
I'm not sure about the device tree bindings. Consider the following two
variants:
(1)
flash@0 {
..
otp {
compatible = "mtd-user-otp";
#address-cells = <1>;
#size-cells = <1>;
serial-number@0 {
reg = <0x0 0x8>;
};
};
};
(2)
flash@0 {
..
otp {
compatible = "mtd-user-otp";
#address-cells = <1>;
#size-cells = <1>;
some-useful-name {
compatible = "nvmem-cells";
serial-number@0 {
reg = <0x0 0x8>;
};
};
};
};
Both bindings use a subnode "opt[-N]". We cannot have the nvmem cells as
children to the flash node because of the legacy partition binding.
(1) seems to be the form which is used almost everywhere in the kernel.
That is, the nvmem cells are just children of the parent node.
(2) seem to be more natural, because there might also be other properties
inside the otp subnode and might be more future-proof.
At the moment this patch implements (1).
Michael Walle (5):
nvmem: core: allow specifying of_node
dt-bindings: mtd: add YAML schema for the generic MTD bindings
dt-bindings: mtd: add OTP bindings
dt-bindings: mtd: spi-nor: add otp property
mtd: core: add OTP nvmem provider support
.../devicetree/bindings/mtd/common.txt| 16 +-
.../bindings/mtd/jedec,spi-nor.yaml | 6 +
.../devicetree/bindings/mtd/mtd.yaml | 89 +++
drivers/mtd/mtdcore.c | 149 ++
drivers/nvmem/core.c | 4 +-
include/linux/mtd/mtd.h | 2 +
include/linux/nvmem-provider.h| 2 +
7 files changed, 252 insertions(+), 16 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mtd/mtd.yaml
--
2.20.1
Re: x86/crash: fix crash_setup_memmap_entries() out-of-bounds access
On 04/16/21 at 01:28pm, Mike Galbraith wrote: > On Fri, 2021-04-16 at 19:07 +0800, Dave Young wrote: > > > > > We're excluding two ranges, allocate the scratch space we need to do that. > > > > I think 1 range should be fine, have you tested 1? > > Have now, and vzalloc(struct_size(cmem, ranges, 1)) worked just fine. Ok, thanks for your quick response. Care to resend and cc x86 list and Andrew? Andrew usually takes core kexec/kdump fixes, x86 usually go through x86 maintainer. Thanks Dave
Re: [PATCH net v3] net: sched: fix packet stuck problem for lockless qdisc
On Tue, 13 Apr 2021, Juergen Gross wrote: > > what Jiri said about "I am still planning to have Yunsheng Lin's > > (CCing) fix [1] tested in the coming days." is that Juergen has > > done the test and provide a "Tested-by" tag. > > Correct. And I did this after Jiri asking me to do so. Exactly, Juergen's setup is the one where this issue is being reproduced reliably for us, and Juergen verified that your patch fixes that issue. Seeing that you now also addressed the STATE_DEACTIVATED issue (which we don't have reproducer for though), I think your series should be good to go if the STATE_DEACTIVATED fix has been verified independently. Thanks! -- Jiri Kosina SUSE Labs
Re: [PATCH 09/13] Samples: Rust examples
Hi, On 14/04/2021 21:42, Miguel Ojeda wrote: > On Wed, Apr 14, 2021 at 9:34 PM Linus Torvalds > wrote: >> >> Honestly, I'd like to see a real example. This is fine for testing, >> but I'd like to see something a bit more real, and a bit less special >> than the Android "binder" WIP that comes a few patches later. >> >> Would there be some kind of real driver or something that people could >> use as a example of a real piece of code that actually does something >> meaningful? > > Yeah, we are planning to write a couple of drivers that talk to actual > hardware. Not sure which ones we will do, but we will have them > written. I’m curious what’s the procedure and approach in general to adding new APIs? I was thinking of trying to port my driver but it needs USB HID and either LEDs or hwrandom (depending on which part I start porting first), so obviously it’s not doable right now, but I’m thinking about maybe helping with at least some of those. -- Cheers, Andrej
Re: [PATCH v2 0/2] MCAN: Add support for implementing transceiver as a phy
Hi all, On 15/04/21 9:16 pm, Aswath Govindraju wrote: > The following series of patches add support for implementing the > transceiver as a phy of m_can_platform driver. > > TCAN1042 has a standby signal that needs to be pulled high for > sending/receiving messages[1]. TCAN1043 has a enable signal along with > standby signal that needs to be pulled up for sending/receiving > messages[2], and other combinations of the two lines can be used to put the > transceiver in different states to reduce power consumption. On boards > like the AM654-idk and J721e-evm these signals are controlled using gpios. > > These gpios are set in phy driver, and the transceiver can be put in > different states using phy API. The phy driver is added in the series [3]. > > This patch series is dependent on [4]. > > Changes since v1: > - Used the API devm_phy_get_optional() instead of > devm_of_phy_get_optional_by_index() > > [1] - https://www.ti.com/lit/ds/symlink/tcan1042h.pdf > [2] - https://www.ti.com/lit/ds/symlink/tcan1043-q1.pdf > [3] - https://lore.kernel.org/patchwork/project/lkml/list/?series=495365 > [4] - https://lore.kernel.org/patchwork/patch/1413286/ > Posted v3 for this series. Thanks, Aswath > Faiz Abbas (2): > dt-bindings: net: can: Document transceiver implementation as phy > can: m_can: Add support for transceiver as phy > > .../devicetree/bindings/net/can/bosch,m_can.yaml| 3 +++ > drivers/net/can/m_can/m_can.c | 10 ++ > drivers/net/can/m_can/m_can.h | 2 ++ > drivers/net/can/m_can/m_can_platform.c | 13 + > 4 files changed, 28 insertions(+) >
Re: [PATCH v4 0/3] CAN TRANSCEIVER: Add support for CAN transceivers
Hi all, On 16/04/21 10:56 am, Aswath Govindraju wrote: > The following series of patches add support for CAN transceivers. > > TCAN1042 has a standby signal that needs to be pulled high for > sending/receiving messages[1]. TCAN1043 has a enable signal along with > standby signal that needs to be pulled up for sending/receiving > messages[2], and other combinations of the two lines can be used to put the > transceiver in different states to reduce power consumption. On boards > like the AM654-idk and J721e-evm these signals are controlled using gpios. > > Patch 1 rewords the comment that restricts max_link_rate attribute to have > units of Mbps. > > Patch 2 models the transceiver as a phy device tree node with properties > for max bit rate supported, gpio properties for indicating gpio pin numbers > to which standby and enable signals are connected. > > Patch 2 adds a generic driver to support CAN transceivers. > > changes since v3: > - dropped patch 2(in v3) > - changed the node name property in patch 3(in v3) > - picked up Rob Herring's reviewed-by for patch 3(in v3) > > changes since v2: > - dropped 5 and 6 patches and to be sent via linux-can-next > - added static keyword for can_transceiver_phy_probe() > - changed enable gpio example to active high in patch 3 > - Rearranged the file names in alphabetical order in Makefile > and MAINTAINERS file > > changes since v1: > - Added patch 1 (in v2) that rewords the comment that restrict > max_link_rate attribute to have units of Mbps. > - Added patch 2 (in v2) that adds an API for > devm_of_phy_optional_get_by_index > - Patch 1 (in v1) > - updated MAINTAINERS file > - Patch 2 (in v1) > - replaced m_can with CAN to make the driver independent of CAN driver > - Added prefix CAN_TRANSCEIVER for EN_PRESENT and STB_PRESENT > - Added new line before return statements in power_on() and power_off > - Added error handling patch for devm_kzalloc() > - used the max_link_rate attribute directly instead of dividing it by > 100 > - removed the spaces before GPIOD_OUT_LOW in devm_gpiod_get() > - Corrected requested value for standby-gpios to GPIOD_OUT_HIGH > - Updated MAINTAINERS file > - Patch 3 (in v1) > - replaced minItems with maxItems > - Removed phy-names property as there is only one phy > - Patch 4 (in v1) > - replaced dev_warn with dev_info when no transceiver is found > - Added struct phy * field in m_can_classdev struct > - moved phy_power_on and phy_power_off to m_can_open and m_can_close > respectively > - Moved the check for max_bit_rate to generice transceiver driver > > [1] - https://www.ti.com/lit/ds/symlink/tcan1042h.pdf > [2] - https://www.ti.com/lit/ds/symlink/tcan1043-q1.pdf > > Posted v5 for this series. Thanks, Aswath > Aswath Govindraju (3): > phy: core: Reword the comment specifying the units of max_link_rate to > be Mbps > dt-bindings: phy: Add binding for TI TCAN104x CAN transceivers > phy: phy-can-transceiver: Add support for generic CAN transceiver > driver > > .../bindings/phy/ti,tcan104x-can.yaml | 56 +++ > MAINTAINERS | 2 + > drivers/phy/Kconfig | 9 ++ > drivers/phy/Makefile | 1 + > drivers/phy/phy-can-transceiver.c | 146 ++ > include/linux/phy/phy.h | 2 +- > 6 files changed, 215 insertions(+), 1 deletion(-) > create mode 100644 Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml > create mode 100644 drivers/phy/phy-can-transceiver.c >
Re: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved pages
On Thu, Apr 15, 2021 at 11:30:12AM +0200, David Hildenbrand wrote: > > Not sure we really need a new pagetype here, PG_Reserved seems to be quite > > enough to say "don't touch this". I generally agree that we could make > > PG_Reserved a PageType and then have several sub-types for reserved memory. > > This definitely will add clarity but I'm not sure that this justifies > > amount of churn and effort required to audit uses of PageResrved(). > > > Then, we could mostly avoid having to query memblock at runtime to figure > > > out that this is special memory. This would obviously be an extension to > > > this series. Just a thought. > > > > Stop pushing memblock out of kernel! ;-) > > Can't stop. Won't stop. :D > > It's lovely for booting up a kernel until we have other data-structures in > place ;) A bit more seriously, we don't have any data structure that reliably represents physical memory layout and arch-independent fashion. memblock is probably the best starting point for eventually having one. -- Sincerely yours, Mike.
Re: [PATCH bpf-next v4 6/6] selftests/bpf: Add a series of tests for bpf_snprintf
On Fri, Apr 16, 2021 at 1:20 AM Andrii Nakryiko
wrote:
>
> On Wed, Apr 14, 2021 at 11:54 AM Florent Revest wrote:
> > +/* Loads an eBPF object calling bpf_snprintf with up to 10 characters of
> > fmt */
> > +static int load_single_snprintf(char *fmt)
> > +{
> > + struct test_snprintf_single *skel;
> > + int ret;
> > +
> > + skel = test_snprintf_single__open();
> > + if (!skel)
> > + return -EINVAL;
> > +
> > + memcpy(skel->rodata->fmt, fmt, min(strlen(fmt) + 1, 10));
> > +
> > + ret = test_snprintf_single__load(skel);
> > + if (!ret)
> > + test_snprintf_single__destroy(skel);
>
> destroy unconditionally?
sweet!
> > +void test_snprintf_negative(void)
> > +{
> > + ASSERT_OK(load_single_snprintf("valid %d"), "valid usage");
> > +
> > + ASSERT_ERR(load_single_snprintf("0123456789"), "no terminating
> > zero");
> > + ASSERT_ERR(load_single_snprintf("%d %d"), "too many specifiers");
> > + ASSERT_ERR(load_single_snprintf("%pi5"), "invalid specifier 1");
> > + ASSERT_ERR(load_single_snprintf("%a"), "invalid specifier 2");
> > + ASSERT_ERR(load_single_snprintf("%"), "invalid specifier 3");
> > + ASSERT_ERR(load_single_snprintf("\x80"), "non ascii character");
> > + ASSERT_ERR(load_single_snprintf("\x1"), "non printable character");
>
> Some more cases that came up in my mind:
>
> 1. %123987129387192387 -- long and unterminated specified
> 2. similarly %--- or something like that
>
> Do you think they are worth checking?
well, it doesn't hurt :) and it's very easy to add so no problem
> > +++ b/tools/testing/selftests/bpf/progs/test_snprintf_single.c
> > @@ -0,0 +1,20 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/* Copyright (c) 2021 Google LLC. */
> > +
> > +#include
> > +#include
> > +
> > +// The format string is filled from the userspace side such that loading
> > fails
>
> C++ style format
Oopsie
[PATCH v3 1/2] dt-bindings: net: can: Document transceiver implementation as phy
From: Faiz Abbas Some transceivers need a configuration step (for example, pulling the standby or enable lines) for them to start sending messages. The transceiver can be implemented as a phy with the configuration done in the phy driver. The bit rate limitation can the be obtained by the driver using the phy node. Document the above implementation in the bosch mcan bindings Signed-off-by: Faiz Abbas Signed-off-by: Aswath Govindraju Acked-by: Rob Herring --- Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index 798fa5fb7bb2..25f74db46bae 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -109,6 +109,9 @@ properties: can-transceiver: $ref: can-transceiver.yaml# + phys: +maxItems: 1 + required: - compatible - reg -- 2.17.1
[PATCH v3 2/2] can: m_can: Add support for transceiver as phy
From: Faiz Abbas
Add support for implementing transceiver node as phy. The max_bitrate is
obtained by getting a phy attribute.
Signed-off-by: Faiz Abbas
Signed-off-by: Aswath Govindraju
---
drivers/net/can/m_can/m_can.c | 10 ++
drivers/net/can/m_can/m_can.h | 2 ++
drivers/net/can/m_can/m_can_platform.c | 13 +
3 files changed, 25 insertions(+)
diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 34073cd077e4..7d31250446c2 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include "m_can.h"
@@ -1514,6 +1515,7 @@ static void m_can_stop(struct net_device *dev)
static int m_can_close(struct net_device *dev)
{
struct m_can_classdev *cdev = netdev_priv(dev);
+ int err;
netif_stop_queue(dev);
@@ -1536,6 +1538,10 @@ static int m_can_close(struct net_device *dev)
close_candev(dev);
can_led_event(dev, CAN_LED_EVENT_STOP);
+ err = phy_power_off(cdev->transceiver);
+ if (err)
+ return err;
+
return 0;
}
@@ -1720,6 +1726,10 @@ static int m_can_open(struct net_device *dev)
struct m_can_classdev *cdev = netdev_priv(dev);
int err;
+ err = phy_power_on(cdev->transceiver);
+ if (err)
+ return err;
+
err = m_can_clk_start(cdev);
if (err)
return err;
diff --git a/drivers/net/can/m_can/m_can.h b/drivers/net/can/m_can/m_can.h
index ace071c3e58c..38cad068abad 100644
--- a/drivers/net/can/m_can/m_can.h
+++ b/drivers/net/can/m_can/m_can.h
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
/* m_can lec values */
enum m_can_lec_type {
@@ -82,6 +83,7 @@ struct m_can_classdev {
struct workqueue_struct *tx_wq;
struct work_struct tx_work;
struct sk_buff *tx_skb;
+ struct phy *transceiver;
struct can_bittiming_const *bit_timing;
struct can_bittiming_const *data_timing;
diff --git a/drivers/net/can/m_can/m_can_platform.c
b/drivers/net/can/m_can/m_can_platform.c
index 599de0e08cd7..f102d532b7f0 100644
--- a/drivers/net/can/m_can/m_can_platform.c
+++ b/drivers/net/can/m_can/m_can_platform.c
@@ -6,6 +6,7 @@
// Copyright (C) 2018-19 Texas Instruments Incorporated - http://www.ti.com/
#include
+#include
#include "m_can.h"
@@ -67,6 +68,7 @@ static int m_can_plat_probe(struct platform_device *pdev)
struct resource *res;
void __iomem *addr;
void __iomem *mram_addr;
+ struct phy *transceiver;
int irq, ret = 0;
mcan_class = m_can_class_allocate_dev(&pdev->dev,
@@ -101,6 +103,16 @@ static int m_can_plat_probe(struct platform_device *pdev)
goto probe_fail;
}
+ transceiver = devm_phy_optional_get(&pdev->dev, NULL);
+ if (IS_ERR(transceiver)) {
+ ret = PTR_ERR(transceiver);
+ dev_err_probe(&pdev->dev, ret, "failed to get phy\n");
+ return ret;
+ }
+
+ if (transceiver)
+ mcan_class->can.bitrate_max = transceiver->attrs.max_link_rate;
+
priv->base = addr;
priv->mram_base = mram_addr;
@@ -108,6 +120,7 @@ static int m_can_plat_probe(struct platform_device *pdev)
mcan_class->pm_clock_support = 1;
mcan_class->can.clock.freq = clk_get_rate(mcan_class->cclk);
mcan_class->dev = &pdev->dev;
+ mcan_class->transceiver = transceiver;
mcan_class->ops = &m_can_plat_ops;
--
2.17.1
[PATCH v3 0/2] MCAN: Add support for implementing transceiver as a phy
The following series of patches add support for implementing the transceiver as a phy of m_can_platform driver. TCAN1042 has a standby signal that needs to be pulled high for sending/receiving messages[1]. TCAN1043 has a enable signal along with standby signal that needs to be pulled up for sending/receiving messages[2], and other combinations of the two lines can be used to put the transceiver in different states to reduce power consumption. On boards like the AM654-idk and J721e-evm these signals are controlled using gpios. These gpios are set in phy driver, and the transceiver can be put in different states using phy API. The phy driver is added in the series [3]. This patch series is dependent on [4]. changes since v2: - changed dev_err to dev_err_probe in patch 2 - used mcan_class instead of priv to assign max bit rate - Picked up Rob Herring's acked-by for patch 1 changes since v1: - Used the API devm_phy_get_optional() instead of devm_of_phy_get_optional_by_index() [1] - https://www.ti.com/lit/ds/symlink/tcan1042h.pdf [2] - https://www.ti.com/lit/ds/symlink/tcan1043-q1.pdf [3] - https://lore.kernel.org/patchwork/project/lkml/list/?series=495511 [4] - https://lore.kernel.org/patchwork/patch/1413286/ Faiz Abbas (2): dt-bindings: net: can: Document transceiver implementation as phy can: m_can: Add support for transceiver as phy .../devicetree/bindings/net/can/bosch,m_can.yaml| 3 +++ drivers/net/can/m_can/m_can.c | 10 ++ drivers/net/can/m_can/m_can.h | 2 ++ drivers/net/can/m_can/m_can_platform.c | 13 + 4 files changed, 28 insertions(+) -- 2.17.1
Re: [PATCH v4] tools/power turbostat: Fix RAPL summary collection on AMD processors
Hi Calvin,
Thanks for the feedback. I'll begin making the change and testing. I'll
respond with V2 patch in this thread.
Regards,
Terry
On 4/14/21 9:13 PM, Calvin Walton wrote:
On Tue, 2021-03-30 at 21:38 +, Terry Bowman wrote:
+int idx_valid_amd(int idx)
+{
+ switch (idx) {
+ case IDX_PKG_ENERGY:
+ return do_rapl & MSR_PKG_ENERGY_STAT;
This isn't correct - MSR_PKG_ENERGY_STAT is the MSR offset, not a bit
mask for the do_rapl bit field.
The presence of MSR_PKG_ENERGY_STAT (along with MSR_RAPL_PWR_UNIT and
MSR_CORE_ENERGY_STAT) is indicated by the RAPL_AMD_F17H bit in do_rapl,
and can be checked with:
do_rapl & RAPL_AMD_F17H
[PATCH] MAINTAINERS: gemini: add missing dts pattern
The MAINTAINERS entry for cortina/gemini miss all dts of this platform. Signed-off-by: Corentin Labbe --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index f64a75945b06..927fa29f05ed 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1816,6 +1816,7 @@ F:Documentation/devicetree/bindings/arm/gemini.txt F: Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt F: Documentation/devicetree/bindings/pinctrl/cortina,gemini-pinctrl.txt F: Documentation/devicetree/bindings/rtc/faraday,ftrtc010.txt +F: arch/arm/boot/dts/gemini* F: arch/arm/mach-gemini/ F: drivers/net/ethernet/cortina/ F: drivers/pinctrl/pinctrl-gemini.c -- 2.26.3
Re: [RFC/RFT PATCH 2/3] arm64: decouple check whether pfn is normal memory from pfn_valid()
On Thu, Apr 15, 2021 at 11:31:26AM +0200, David Hildenbrand wrote:
> On 14.04.21 22:29, Mike Rapoport wrote:
> > On Wed, Apr 14, 2021 at 05:58:26PM +0200, David Hildenbrand wrote:
> > > On 08.04.21 07:14, Anshuman Khandual wrote:
> > > >
> > > > On 4/7/21 10:56 PM, Mike Rapoport wrote:
> > > > > From: Mike Rapoport
> > > > >
> > > > > The intended semantics of pfn_valid() is to verify whether there is a
> > > > > struct page for the pfn in question and nothing else.
> > > >
> > > > Should there be a comment affirming this semantics interpretation,
> > > > above the
> > > > generic pfn_valid() in include/linux/mmzone.h ?
> > > >
> > > > >
> > > > > Yet, on arm64 it is used to distinguish memory areas that are mapped
> > > > > in the
> > > > > linear map vs those that require ioremap() to access them.
> > > > >
> > > > > Introduce a dedicated pfn_is_memory() to perform such check and use it
> > > > > where appropriate.
> > > > >
> > > > > Signed-off-by: Mike Rapoport
> > > > > ---
> > > > >arch/arm64/include/asm/memory.h | 2 +-
> > > > >arch/arm64/include/asm/page.h | 1 +
> > > > >arch/arm64/kvm/mmu.c| 2 +-
> > > > >arch/arm64/mm/init.c| 6 ++
> > > > >arch/arm64/mm/ioremap.c | 4 ++--
> > > > >arch/arm64/mm/mmu.c | 2 +-
> > > > >6 files changed, 12 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm64/include/asm/memory.h
> > > > > b/arch/arm64/include/asm/memory.h
> > > > > index 0aabc3be9a75..7e77fdf71b9d 100644
> > > > > --- a/arch/arm64/include/asm/memory.h
> > > > > +++ b/arch/arm64/include/asm/memory.h
> > > > > @@ -351,7 +351,7 @@ static inline void *phys_to_virt(phys_addr_t x)
> > > > >#define virt_addr_valid(addr) ({
> > > > > \
> > > > > __typeof__(addr) __addr = __tag_reset(addr);
> > > > > \
> > > > > - __is_lm_address(__addr) && pfn_valid(virt_to_pfn(__addr));
> > > > > \
> > > > > + __is_lm_address(__addr) && pfn_is_memory(virt_to_pfn(__addr));
> > > > > \
> > > > >})
> > > > >void dump_mem_limit(void);
> > > > > diff --git a/arch/arm64/include/asm/page.h
> > > > > b/arch/arm64/include/asm/page.h
> > > > > index 012cffc574e8..32b485bcc6ff 100644
> > > > > --- a/arch/arm64/include/asm/page.h
> > > > > +++ b/arch/arm64/include/asm/page.h
> > > > > @@ -38,6 +38,7 @@ void copy_highpage(struct page *to, struct page
> > > > > *from);
> > > > >typedef struct page *pgtable_t;
> > > > >extern int pfn_valid(unsigned long);
> > > > > +extern int pfn_is_memory(unsigned long);
> > > > >#include
> > > > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > > > > index 8711894db8c2..ad2ea65a3937 100644
> > > > > --- a/arch/arm64/kvm/mmu.c
> > > > > +++ b/arch/arm64/kvm/mmu.c
> > > > > @@ -85,7 +85,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm)
> > > > >static bool kvm_is_device_pfn(unsigned long pfn)
> > > > >{
> > > > > - return !pfn_valid(pfn);
> > > > > + return !pfn_is_memory(pfn);
> > > > >}
> > > > >/*
> > > > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > > > > index 3685e12aba9b..258b1905ed4a 100644
> > > > > --- a/arch/arm64/mm/init.c
> > > > > +++ b/arch/arm64/mm/init.c
> > > > > @@ -258,6 +258,12 @@ int pfn_valid(unsigned long pfn)
> > > > >}
> > > > >EXPORT_SYMBOL(pfn_valid);
> > > > > +int pfn_is_memory(unsigned long pfn)
> > > > > +{
> > > > > + return memblock_is_map_memory(PFN_PHYS(pfn));
> > > > > +}
> > > > > +EXPORT_SYMBOL(pfn_is_memory);> +
> > > >
> > > > Should not this be generic though ? There is nothing platform or arm64
> > > > specific in here. Wondering as pfn_is_memory() just indicates that the
> > > > pfn is linear mapped, should not it be renamed as pfn_is_linear_memory()
> > > > instead ? Regardless, it's fine either way.
> > >
> > > TBH, I dislike (generic) pfn_is_memory(). It feels like we're mixing
> > > concepts.
> >
> > Yeah, at the moment NOMAP is very much arm specific so I'd keep it this way
> > for now.
> >
> > > NOMAP memory vs !NOMAP memory; even NOMAP is some kind of memory
> > > after all. pfn_is_map_memory() would be more expressive, although still
> > > sub-optimal.
> > >
> > > We'd actually want some kind of arm64-specific pfn_is_system_memory() or
> > > the
> > > inverse pfn_is_device_memory() -- to be improved.
> >
> > In my current version (to be posted soon) I've started with
> > pfn_lineary_mapped() but then ended up with pfn_mapped() to make it
> > "upward" compatible with architectures that use direct rather than linear
> > map :)
>
> And even that is moot. It doesn't tell you if a PFN is *actually* mapped
> (hello secretmem).
>
> I'd suggest to just use memblock_is_map_memory() in arch specific code. Then
> it's clear what we are querying exactly and what the semantics might be.
Ok, let's export memblock_is_map_memory() for the KEEP_MEMBLOCK case.
--
Sincerely
Re: [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC sub-driver
On 16/04/2021 11:58, Laurent Pinchart wrote: > Hi Neil, > > On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote: >> This adds DW-HDMI driver a glue option to disable loading of the CEC >> sub-driver. >> >> On some SoCs, the CEC functionality is enabled in the IP config bits, but the >> CEC bus is non-functional like on Amlogic SoCs, where the CEC config bit is >> set >> but the DW-HDMI CEC signal is not connected to a physical pin, leading to >> some >> confusion when the DW-HDMI CEC controller can't communicate on the bus. > > If we can't trust the CEC config bit, would it be better to not use it > at all, and instead let each platform glue logic tell whether to enable > CEC or not ? Actually, the CEC config bit is right, the HW exists and should be functional, but this bit doesn't tell if the CEC signal is connected to something. This lies in the IP integration, like other bits under the "amlogic,meson-*-dw-hdmi" umbrella. The first attempt was by Hans using DT, but adding a property in DT for a vendor specific compatible doesn't make sense. Another idea would be to describe the CEC signal endpoint like we do for video signal, but I think this is out of scope and this solution is much simpler and straightforward, and it's more an exception than a general use case to solve. Neil > >> Jernej Skrabec (1): >> drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC >> driver >> >> Neil Armstrong (1): >> drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver >> >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- >> drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 + >> include/drm/bridge/dw_hdmi.h | 2 ++ >> 3 files changed, 4 insertions(+), 1 deletion(-) >> >
Re: [PATCH] arm64: dts: fsl-ls1028a: Correct ECAM PCIE window ranges
Hi,
On Wed, Apr 7, 2021 at 2:35 PM Kornel Duleba wrote:
>
> Currently all PCIE windows point to bus address 0x0, which does not match
> the values obtained from hardware during EA.
> Replace those values with CPU addresses, since in reality we
> have a 1:1 mapping between the two.
>
> Signed-off-by: Kornel Duleba
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> index 262fbad8f0ec..85c62a6fabb6 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> @@ -994,19 +994,19 @@ pcie@1f000 { /* Integrated Endpoint Root Complex */
> msi-map = <0 &its 0x17 0xe>;
> iommu-map = <0 &smmu 0x17 0xe>;
> /* PF0-6 BAR0 - non-prefetchable memory */
> - ranges = <0x8200 0x0 0x 0x1 0xf800
> 0x0 0x16
> + ranges = <0x8200 0x1 0xf800 0x1 0xf800
> 0x0 0x16
> /* PF0-6 BAR2 - prefetchable memory */
> - 0xc200 0x0 0x 0x1 0xf816
> 0x0 0x07
> + 0xc200 0x1 0xf816 0x1 0xf816
> 0x0 0x07
> /* PF0: VF0-1 BAR0 - non-prefetchable
> memory */
> - 0x8200 0x0 0x 0x1 0xf81d
> 0x0 0x02
> + 0x8200 0x1 0xf81d 0x1 0xf81d
> 0x0 0x02
> /* PF0: VF0-1 BAR2 - prefetchable memory */
> - 0xc200 0x0 0x 0x1 0xf81f
> 0x0 0x02
> + 0xc200 0x1 0xf81f 0x1 0xf81f
> 0x0 0x02
> /* PF1: VF0-1 BAR0 - non-prefetchable
> memory */
> - 0x8200 0x0 0x 0x1 0xf821
> 0x0 0x02
> + 0x8200 0x1 0xf821 0x1 0xf821
> 0x0 0x02
> /* PF1: VF0-1 BAR2 - prefetchable memory */
> - 0xc200 0x0 0x 0x1 0xf823
> 0x0 0x02
> + 0xc200 0x1 0xf823 0x1 0xf823
> 0x0 0x02
> /* BAR4 (PF5) - non-prefetchable memory */
> - 0x8200 0x0 0x 0x1 0xfc00
> 0x0 0x40>;
> + 0x8200 0x1 0xfc00 0x1 0xfc00
> 0x0 0x40>;
>
> enetc_port0: ethernet@0,0 {
> compatible = "fsl,enetc";
> --
> 2.31.1
>
Have you had a chance to to review the patch? Any questions or remarks?
Regards,
Kornel
linux-next: Tree for Apr 16
Hi all,
Changes since 20210415:
New trees: cxl-fixes, cxl
The rust tree gained conflicts against the printk and char-misc trees.
Non-merge commits (relative to Linus' tree): 12231
10888 files changed, 590734 insertions(+), 269274 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).
Below is a summary of the state of the merge.
I am currently merging 340 trees (counting Linus' and 87 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (7e25f40eab52 Merge tag 'acpi-5.12-rc8' of
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm)
Merging fixes/fixes (e71ba9452f0b Linux 5.11-rc2)
Merging kbuild-current/fixes (bcbcf50f5218 kbuild: fix ld-version.sh to not be
affected by locale)
Merging arc-current/for-curr (163630b2d95b arc: Fix typos/spellos)
Merging arm-current/fixes (30e3b4f256b4 ARM: footbridge: fix PCI interrupt
mapping)
Merging arm64-fixes/for-next/fixes (22315a2296f4 arm64: alternatives: Move
length validation in alternative_{insn, endif})
Merging arm-soc-fixes/arm/fixes (b9a9786a13ea Merge tag
'omap-for-v5.12/fixes-rc6-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes)
Merging drivers-memory-fixes/fixes (a38fd8748464 Linux 5.12-rc2)
Merging m68k-current/for-linus (a65a802aadba m68k: Fix virt_addr_valid() W=1
compiler warnings)
Merging powerpc-fixes/fixes (791f9e36599d powerpc/vdso: Make sure
vdso_wrapper.o is rebuilt everytime vdso.so is rebuilt)
Merging s390-fixes/fixes (a994eddb947e s390/entry: save the caller of psw_idle)
Merging sparc/master (05a59d79793d Merge
git://git.kernel.org:/pub/scm/linux/kernel/git/netdev/net)
Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption
not used on new files)
Merging net/master (4e39a072a6a0 i40e: fix the panic when running bpf in xdpdrv
mode)
Merging bpf/master (afd0be729953 libbpf: Fix potential NULL pointer dereference)
Merging ipsec/master (6628ddfec758 net: geneve: check skb is large enough for
IPv4/IPv6 header)
Merging netfilter/master (ccb39c628558 Merge
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging ipvs/master (fbea31808ca1 netfilter: conntrack: do not print icmpv6 as
unknown via /proc)
Merging wireless-drivers/master (65db391dd874 iwlwifi: mvm: fix beacon
protection checks)
Merging mac80211/master (864db232dc70 net: ipv6: check for validity before
dereferencing cfg->fc_nlinfo.nlh)
Merging rdma-fixes/for-rc (d434405aaab7 Linux 5.12-rc7)
Merging sound-current/for-linus (c8426b2700b5 ALSA: hda/realtek: Fix speaker
amp setup on Acer Aspire E1)
Merging sound-asoc-fixes/for-linus (f655ede26d66 Merge remote-tracking branch
'asoc/for-5.12' into asoc-linus)
Merging regmap-fixes/for-linus (78d889705732 Merge remote-tracking branch
'regmap/for-5.12' into regmap-linus)
Merging regulator-fixes/for-linus (6068cc31dedd Merge remote-tracking branch
'regulator/for-5.12' into regulator-linus)
Merging spi-fixes/for-linus (49dff37f84d5 Merge remote-tracking branch
'spi/for-5.12' into spi-linus)
Merging pci-current/for-linus (cf673bd0cc97 PCI: switchtec: Fix Spectre v1
vulnerability)
Merging driver-core.current/driver-core-linus (d434405aaab7 Linux 5.12-rc7)
Merging tty.current/tty-linus (e49d033bddf5 Linux 5.12-rc6)
Merging usb.current/usb-linus (d434405aaab7 Linux 5.12-rc7)
Merging usb-gadget-fixes/fixes (e49d033bdd
Re: [PATCH] crypto: crc32-generic - Use SPDX-License-Identifier
On Sat, Apr 10, 2021 at 10:30:16PM +0200, Christophe JAILLET wrote: > Use SPDX-License-Identifier: GPL-2.0-only, instead of hand writing it. > > This also removes a reference to http://www.xyratex.com which seems to be > down. > > Signed-off-by: Christophe JAILLET > --- > crypto/crc32_generic.c | 24 +--- > 1 file changed, 1 insertion(+), 23 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v3] crypto: hisilicon/hpre - delete redundant log and return in advance
On Sat, Apr 10, 2021 at 05:50:32PM +0800, Hui Tang wrote: > 'hpre_cfg_by_dsm' has checked and printed error path internally. It is not > necessary to do it here, so remove it. > > It should return error immediately when return value of 'hpre_cfg_by_dsm' > is non-zero, and no need to execute the remaining sentences. > > Signed-off-by: Hui Tang > > --- > v1 -> v2: >- Return immediately when return value of 'hpre_cfg_by_dsm' is > non-zero. > v2 -> v3: >- Add description for return if function fails. > --- > drivers/crypto/hisilicon/hpre/hpre_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 4.14 00/68] 4.14.231-rc1 review
On Thu, 15 Apr 2021 at 20:27, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.231 release. > There are 68 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat, 17 Apr 2021 14:44:01 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.231-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing ## Build * kernel: 4.14.231-rc1 * git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git * git branch: linux-4.14.y * git commit: 520c87617485a8885f18d5cb9d70076199e37b43 * git describe: v4.14.230-69-g520c87617485 * test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.14.y/build/v4.14.230-69-g520c87617485 ## No regressions (compared to v4.14.230-60-g9c0b97ea1e55) ## No fixes (compared to v4.14.230-60-g9c0b97ea1e55) ## Test result summary total: 57382, pass: 47701, fail: 583, skip: 8861, xfail: 237, ## Build Summary * arm: 96 total, 96 passed, 0 failed * arm64: 23 total, 23 passed, 0 failed * dragonboard-410c: 1 total, 1 passed, 0 failed * hi6220-hikey: 1 total, 1 passed, 0 failed * i386: 13 total, 13 passed, 0 failed * juno-r2: 1 total, 1 passed, 0 failed * mips: 36 total, 36 passed, 0 failed * sparc: 9 total, 9 passed, 0 failed * x15: 1 total, 1 passed, 0 failed * x86: 1 total, 1 passed, 0 failed * x86_64: 13 total, 13 passed, 0 failed ## Test suites summary * fwts * igt-gpu-tools * install-android-platform-tools-r2600 * kselftest-android * kselftest-bpf * kselftest-capabilities * kselftest-cgroup * kselftest-clone3 * kselftest-core * kselftest-cpu-hotplug * kselftest-cpufreq * kselftest-efivarfs * kselftest-filesystems * kselftest-firmware * kselftest-fpu * kselftest-futex * kselftest-gpio * kselftest-intel_pstate * kselftest-ipc * kselftest-ir * kselftest-kcmp * kselftest-kexec * kselftest-kvm * kselftest-lib * kselftest-livepatch * kselftest-lkdtm * kselftest-membarrier * kselftest-net * kselftest-netfilter * kselftest-nsfs * kselftest-ptrace * kselftest-rseq * kselftest-rtc * kselftest-seccomp * kselftest-sigaltstack * kselftest-size * kselftest-splice * kselftest-static_keys * kselftest-sync * kselftest-sysctl * kselftest-tc-testing * kselftest-timens * kselftest-timers * kselftest-tmpfs * kselftest-tpm2 * kselftest-user * kselftest-vm * kselftest-x86 * kselftest-zram * kvm-unit-tests * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-open-posix-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-tracing-tests * network-basic-tests * perf * rcutorture * ssuite * v4l2-compliance -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH] crypto: arm/curve25519 - Move '.fpu' after '.arch'
On Fri, Apr 09, 2021 at 03:11:55PM -0700, Nathan Chancellor wrote:
> Debian's clang carries a patch that makes the default FPU mode
> 'vfp3-d16' instead of 'neon' for 'armv7-a' to avoid generating NEON
> instructions on hardware that does not support them:
>
> https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/raw/5a61ca6f21b4ad8c6ac4970e5ea5a7b5b4486d22/debian/patches/clang-arm-default-vfp3-on-armv7a.patch
> https://bugs.debian.org/841474
> https://bugs.debian.org/842142
> https://bugs.debian.org/914268
>
> This results in the following build error when clang's integrated
> assembler is used because the '.arch' directive overrides the '.fpu'
> directive:
>
> arch/arm/crypto/curve25519-core.S:25:2: error: instruction requires: NEON
> vmov.i32 q0, #1
> ^
> arch/arm/crypto/curve25519-core.S:26:2: error: instruction requires: NEON
> vshr.u64 q1, q0, #7
> ^
> arch/arm/crypto/curve25519-core.S:27:2: error: instruction requires: NEON
> vshr.u64 q0, q0, #8
> ^
> arch/arm/crypto/curve25519-core.S:28:2: error: instruction requires: NEON
> vmov.i32 d4, #19
> ^
>
> Shuffle the order of the '.arch' and '.fpu' directives so that the code
> builds regardless of the default FPU mode. This has been tested against
> both clang with and without Debian's patch and GCC.
>
> Cc: sta...@vger.kernel.org
> Fixes: d8f1308a025f ("crypto: arm/curve25519 - wire up NEON implementation")
> Link: https://github.com/ClangBuiltLinux/continuous-integration2/issues/118
> Reported-by: Arnd Bergmann
> Suggested-by: Arnd Bergmann
> Suggested-by: Jessica Clarke
> Signed-off-by: Nathan Chancellor
> ---
> arch/arm/crypto/curve25519-core.S | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: 08ed4efad6: stress-ng.sigsegv.ops_per_sec -41.9% regression
On Thu, Apr 08, 2021 at 01:44:43PM -0500, Eric W. Biederman wrote:
> Linus Torvalds writes:
>
> > On Thu, Apr 8, 2021 at 1:32 AM kernel test robot
> > wrote:
> >>
> >> FYI, we noticed a -41.9% regression of stress-ng.sigsegv.ops_per_sec due
> >> to commit
> >> 08ed4efad684 ("[PATCH v10 6/9] Reimplement RLIMIT_SIGPENDING on top of
> >> ucounts")
> >
> > Ouch.
>
> We were cautiously optimistic when no test problems showed up from
> the last posting that there was nothing to look at here.
>
> Unfortunately it looks like the bots just missed the last posting.
>
> So it seems we are finally pretty much at correct code in need
> of performance tuning.
>
> > I *think* this test may be testing "send so many signals that it
> > triggers the signal queue overflow case".
> >
> > And I *think* that the performance degradation may be due to lots of
> > unnecessary allocations, because ity looks like that commit changes
> > __sigqueue_alloc() to do
> >
> > struct sigqueue *q = kmem_cache_alloc(sigqueue_cachep, flags);
> >
> > *before* checking the signal limit, and then if the signal limit was
> > exceeded, it will just be free'd instead.
> >
> > The old code would check the signal count against RLIMIT_SIGPENDING
> > *first*, and if there were m ore pending signals then it wouldn't do
> > anything at all (including not incrementing that expensive atomic
> > count).
>
> This is an interesting test in a lot of ways as it is testing the
> synchronous signal delivery path caused by an exception. The test
> is either executing *ptr = 0 (where ptr points to a read-only page)
> or it executes an x86 instruction that is excessively long.
>
> I have found the code but I haven't figured out how it is being
> called yet. The core loop is just:
> for(;;) {
> sigaction(SIGSEGV, &action, NULL);
> sigaction(SIGILL, &action, NULL);
> sigaction(SIGBUS, &action, NULL);
>
> ret = sigsetjmp(jmp_env, 1);
> if (done())
> break;
> if (ret) {
> /* verify signal */
> } else {
> *ptr = 0;
> }
> }
>
> Code like that fundamentally can not be multi-threaded. So the only way
> the sigpending limit is being hit is if there are more processes running
> that code simultaneously than the size of the limit.
>
> Further it looks like stress-ng pushes RLIMIT_SIGPENDING as high as it
> will go before the test starts.
>
>
> > Also, the old code was very careful to only do the "get_user()" for
> > the *first* signal it added to the queue, and do the "put_user()" for
> > when removing the last signal. Exactly because those atomics are very
> > expensive.
> >
> > The new code just does a lot of these atomics unconditionally.
>
> Yes. That seems a likely culprit.
>
> > I dunno. The profile data in there is a bit hard to read, but there's
> > a lot more cachee misses, and a *lot* of node crossers:
> >
> >>5961544 +190.4% 17314361perf-stat.i.cache-misses
> >> 22107466 +119.2% 48457656perf-stat.i.cache-references
> >> 163292 ą 3% +4582.0%7645410perf-stat.i.node-load-misses
> >> 227388 ą 2% +3708.8%8660824perf-stat.i.node-loads
> >
> > and (probably as a result) average instruction costs have gone up
> > enormously:
> >
> >> 3.47 +66.8% 5.79perf-stat.overall.cpi
> >> 22849 -65.6% 7866
> >> perf-stat.overall.cycles-between-cache-misses
> >
> > and it does seem to be at least partly about "put_ucounts()":
> >
> >> 0.00+4.54.46
> >> perf-profile.calltrace.cycles-pp.put_ucounts.__sigqueue_free.get_signal.arch_do_signal_or_restart.exit_to_user_mode_prepare
> >
> > and a lot of "get_ucounts()".
> >
> > But it may also be that the new "get sigpending" is just *so* much
> > more expensive than it used to be.
>
> That too is possible.
>
> That node-load-misses number does look like something is bouncing back
> and forth between the nodes a lot more. So I suspect stress-ng is
> running multiple copies of the sigsegv test in different processes at
> once.
>
>
>
> That really suggests cache line ping pong from get_ucounts and
> incrementing sigpending.
>
> It surprises me that obtaining the cache lines exclusively is
> the dominant cost on this code path but obtaining two cache lines
> exclusively instead of one cache cache line exclusively is consistent
> with a causing the exception delivery to take nearly twice as long.
>
> For the optimization we only care about the leaf count so with a little
> care we can restore the optimization. So that is probably the thing
> to do here. The fewer changes to worry about the less likely to find
> surprises.
>
>
>
> That said for this specific case there is a lot of potential room for
> improvement. As this is a per thread signal
Re: [PATCH 0/3] crypto: hisilicon/hpre - add debug log
On Sat, Apr 10, 2021 at 05:46:58PM +0800, Hui Tang wrote: > This patchset adds the debug log and cleanup code style. > > Hui Tang (3): > crypto: hisilicon/hpre - delete the rudundant space after return > crypto: hisilicon/hpre - use the correct variable type > crypto: hisilicon/hpre - add debug log > > drivers/crypto/hisilicon/hpre/hpre_crypto.c | 11 +-- > drivers/crypto/hisilicon/hpre/hpre_main.c | 4 ++-- > 2 files changed, 11 insertions(+), 4 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v3 0/5] bug fix and clear coding style
On Fri, Apr 09, 2021 at 05:03:59PM +0800, Kai Ye wrote: > Fixup coding style such as delete unneeded variable > initialization. Add a comment for block size initialization. > Add a data cleared operation in sg buf unmap, and other misc fix. > > v1 -> v2: > 1. fix [PATCH v2] error in v1. > 2. v1 use a macro replace of magic number, v2 use a comment > for block size initialization. > v2 -> v3: > fix a sparse warning > > Kai Ye (5): > crypto: hisilicon/sgl - add a comment for block size initialization > crypto: hisilicon/sgl - delete unneeded variable initialization > crypto: hisilicon/sgl - add some dfx logs > crypto: hisilicon/sgl - fix the soft sg map to hardware sg > crypto: hisilicon/sgl - fix the sg buf unmap > > drivers/crypto/hisilicon/sgl.c | 37 +++-- > 1 file changed, 31 insertions(+), 6 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/2] crypto: correct the use of print format
On Thu, Apr 08, 2021 at 06:23:49PM +0800, Kai Ye wrote: > According to Documentation/core-api/printk-formats.rst, > Use the correct print format. Printing an unsigned int value should use %u > instead of %d. Otherwise printk() might end up displaying negative numbers. > > Kai Ye (2): > crypto/atmel - use the correct print format > crypto: hisilicon/sec_drv - use the correct print format > > drivers/crypto/atmel-i2c.c | 2 +- > drivers/crypto/atmel-sha.c | 4 ++-- > drivers/crypto/hisilicon/sec/sec_drv.c | 6 +++--- > 3 files changed, 6 insertions(+), 6 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH -next 1/7] crypto: sun4i-ss - Fix PM reference leak when pm_runtime_get_sync() fails
On Thu, Apr 08, 2021 at 03:18:31PM +0800, Shixin Liu wrote: > pm_runtime_get_sync will increment pm usage counter even it failed. > Forgetting to putting operation will result in reference leak here. > Fix it by replacing it with pm_runtime_resume_and_get to keep usage > counter balanced. > > Signed-off-by: Shixin Liu > --- > drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c | 2 +- > drivers/crypto/allwinner/sun4i-ss/sun4i-ss-core.c | 2 +- > drivers/crypto/allwinner/sun4i-ss/sun4i-ss-hash.c | 2 +- > drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c | 2 +- > 4 files changed, 4 insertions(+), 4 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH v5 0/3] CAN TRANSCEIVER: Add support for CAN transceivers
The following series of patches add support for CAN transceivers. TCAN1042 has a standby signal that needs to be pulled high for sending/receiving messages[1]. TCAN1043 has a enable signal along with standby signal that needs to be pulled up for sending/receiving messages[2], and other combinations of the two lines can be used to put the transceiver in different states to reduce power consumption. On boards like the AM654-idk and J721e-evm these signals are controlled using gpios. Patch 1 rewords the comment that restricts max_link_rate attribute to have units of Mbps. Patch 2 models the transceiver as a phy device tree node with properties for max bit rate supported, gpio properties for indicating gpio pin numbers to which standby and enable signals are connected. Patch 2 adds a generic driver to support CAN transceivers. changes since v4: - In patch 3 made the correction from mcan to CAN, in Kconfig help changes since v3: - dropped patch 2(in v3) - changed the node name property in patch 3(in v3) - picked up Rob Herring's reviewed-by for patch 3(in v3) changes since v2: - dropped 5 and 6 patches and to be sent via linux-can-next - added static keyword for can_transceiver_phy_probe() - changed enable gpio example to active high in patch 3 - Rearranged the file names in alphabetical order in Makefile and MAINTAINERS file changes since v1: - Added patch 1 (in v2) that rewords the comment that restrict max_link_rate attribute to have units of Mbps. - Added patch 2 (in v2) that adds an API for devm_of_phy_optional_get_by_index - Patch 1 (in v1) - updated MAINTAINERS file - Patch 2 (in v1) - replaced m_can with CAN to make the driver independent of CAN driver - Added prefix CAN_TRANSCEIVER for EN_PRESENT and STB_PRESENT - Added new line before return statements in power_on() and power_off - Added error handling patch for devm_kzalloc() - used the max_link_rate attribute directly instead of dividing it by 100 - removed the spaces before GPIOD_OUT_LOW in devm_gpiod_get() - Corrected requested value for standby-gpios to GPIOD_OUT_HIGH - Updated MAINTAINERS file - Patch 3 (in v1) - replaced minItems with maxItems - Removed phy-names property as there is only one phy - Patch 4 (in v1) - replaced dev_warn with dev_info when no transceiver is found - Added struct phy * field in m_can_classdev struct - moved phy_power_on and phy_power_off to m_can_open and m_can_close respectively - Moved the check for max_bit_rate to generice transceiver driver [1] - https://www.ti.com/lit/ds/symlink/tcan1042h.pdf [2] - https://www.ti.com/lit/ds/symlink/tcan1043-q1.pdf Aswath Govindraju (3): phy: core: Reword the comment specifying the units of max_link_rate to be Mbps dt-bindings: phy: Add binding for TI TCAN104x CAN transceivers phy: phy-can-transceiver: Add support for generic CAN transceiver driver .../bindings/phy/ti,tcan104x-can.yaml | 56 +++ MAINTAINERS | 2 + drivers/phy/Kconfig | 9 ++ drivers/phy/Makefile | 1 + drivers/phy/phy-can-transceiver.c | 146 ++ include/linux/phy/phy.h | 2 +- 6 files changed, 215 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml create mode 100644 drivers/phy/phy-can-transceiver.c -- 2.17.1
[PATCH v5 3/3] phy: phy-can-transceiver: Add support for generic CAN transceiver driver
The driver adds support for generic CAN transceivers. Currently
the modes supported by this driver are standby and normal modes for TI
TCAN1042 and TCAN1043 CAN transceivers.
The transceiver is modelled as a phy with pins controlled by gpios, to put
the transceiver in various device functional modes. It also gets the phy
attribute max_link_rate for the usage of CAN drivers.
Signed-off-by: Aswath Govindraju
---
MAINTAINERS | 1 +
drivers/phy/Kconfig | 9 ++
drivers/phy/Makefile | 1 +
drivers/phy/phy-can-transceiver.c | 146 ++
4 files changed, 157 insertions(+)
create mode 100644 drivers/phy/phy-can-transceiver.c
diff --git a/MAINTAINERS b/MAINTAINERS
index e666d33af10d..4e868f2a97c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4048,6 +4048,7 @@ T:git
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git
F: Documentation/devicetree/bindings/net/can/
F: Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
F: drivers/net/can/
+F: drivers/phy/phy-can-transceiver.c
F: include/linux/can/bittiming.h
F: include/linux/can/dev.h
F: include/linux/can/led.h
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 54c1f2f0985f..7dd35f1b9cc5 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -61,6 +61,15 @@ config USB_LGM_PHY
interface to interact with USB GEN-II and USB 3.x PHY that is part
of the Intel network SOC.
+config PHY_CAN_TRANSCEIVER
+ tristate "CAN transceiver PHY"
+ select GENERIC_PHY
+ help
+ This option enables support for CAN transceivers as a PHY. This
+ driver provides function for putting the transceivers in various
+ functional modes using gpios and sets the attribute max link
+ rate, for CAN drivers.
+
source "drivers/phy/allwinner/Kconfig"
source "drivers/phy/amlogic/Kconfig"
source "drivers/phy/broadcom/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index adac1b1a39d1..01e9efffc726 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -5,6 +5,7 @@
obj-$(CONFIG_GENERIC_PHY) += phy-core.o
obj-$(CONFIG_GENERIC_PHY_MIPI_DPHY)+= phy-core-mipi-dphy.o
+obj-$(CONFIG_PHY_CAN_TRANSCEIVER) += phy-can-transceiver.o
obj-$(CONFIG_PHY_LPC18XX_USB_OTG) += phy-lpc18xx-usb-otg.o
obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o
obj-$(CONFIG_PHY_PISTACHIO_USB)+= phy-pistachio-usb.o
diff --git a/drivers/phy/phy-can-transceiver.c
b/drivers/phy/phy-can-transceiver.c
new file mode 100644
index ..c24aa2eab9e4
--- /dev/null
+++ b/drivers/phy/phy-can-transceiver.c
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * phy-can-transceiver.c - phy driver for CAN transceivers
+ *
+ * Copyright (C) 2021 Texas Instruments Incorporated - http://www.ti.com
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+
+struct can_transceiver_data {
+ u32 flags;
+#define CAN_TRANSCEIVER_STB_PRESENTBIT(0)
+#define CAN_TRANSCEIVER_EN_PRESENT BIT(1)
+};
+
+struct can_transceiver_phy {
+ struct phy *generic_phy;
+ struct gpio_desc *standby_gpio;
+ struct gpio_desc *enable_gpio;
+};
+
+/* Power on function */
+static int can_transceiver_phy_power_on(struct phy *phy)
+{
+ struct can_transceiver_phy *can_transceiver_phy = phy_get_drvdata(phy);
+
+ if (can_transceiver_phy->standby_gpio)
+ gpiod_set_value_cansleep(can_transceiver_phy->standby_gpio, 0);
+ if (can_transceiver_phy->enable_gpio)
+ gpiod_set_value_cansleep(can_transceiver_phy->enable_gpio, 1);
+
+ return 0;
+}
+
+/* Power off function */
+static int can_transceiver_phy_power_off(struct phy *phy)
+{
+ struct can_transceiver_phy *can_transceiver_phy = phy_get_drvdata(phy);
+
+ if (can_transceiver_phy->standby_gpio)
+ gpiod_set_value_cansleep(can_transceiver_phy->standby_gpio, 1);
+ if (can_transceiver_phy->enable_gpio)
+ gpiod_set_value_cansleep(can_transceiver_phy->enable_gpio, 0);
+
+ return 0;
+}
+
+static const struct phy_ops can_transceiver_phy_ops = {
+ .power_on = can_transceiver_phy_power_on,
+ .power_off = can_transceiver_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+static const struct can_transceiver_data tcan1042_drvdata = {
+ .flags = CAN_TRANSCEIVER_STB_PRESENT,
+};
+
+static const struct can_transceiver_data tcan1043_drvdata = {
+ .flags = CAN_TRANSCEIVER_STB_PRESENT | CAN_TRANSCEIVER_EN_PRESENT,
+};
+
+static const struct of_device_id can_transceiver_phy_ids[] = {
+ {
+ .compatible = "ti,tcan1042",
+ .data = &tcan1042_drvdata
+ },
+ {
+ .compatible = "ti,tcan1043",
+ .data = &tcan1043_drvdata
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, can_transceiver_
[PATCH v5 2/3] dt-bindings: phy: Add binding for TI TCAN104x CAN transceivers
Add binding documentation for TI TCAN104x CAN transceivers.
Signed-off-by: Aswath Govindraju
Reviewed-by: Rob Herring
---
.../bindings/phy/ti,tcan104x-can.yaml | 56 +++
MAINTAINERS | 1 +
2 files changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
new file mode 100644
index ..6107880e5246
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/phy/ti,tcan104x-can.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: TCAN104x CAN TRANSCEIVER PHY
+
+maintainers:
+ - Aswath Govindraju
+
+properties:
+ $nodename:
+pattern: "^can-phy"
+
+ compatible:
+enum:
+ - ti,tcan1042
+ - ti,tcan1043
+
+ '#phy-cells':
+const: 0
+
+ standby-gpios:
+description:
+ gpio node to toggle standby signal on transceiver
+maxItems: 1
+
+ enable-gpios:
+description:
+ gpio node to toggle enable signal on transceiver
+maxItems: 1
+
+ max-bitrate:
+$ref: /schemas/types.yaml#/definitions/uint32
+description:
+ max bit rate supported in bps
+minimum: 1
+
+required:
+ - compatible
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+transceiver1: can-phy {
+ compatible = "ti,tcan1043";
+ #phy-cells = <0>;
+ max-bitrate = <500>;
+ standby-gpios = <&wakeup_gpio1 16 GPIO_ACTIVE_LOW>;
+ enable-gpios = <&main_gpio1 67 GPIO_ACTIVE_HIGH>;
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 84ef96a444c3..e666d33af10d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4046,6 +4046,7 @@ W:https://github.com/linux-can
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git
F: Documentation/devicetree/bindings/net/can/
+F: Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml
F: drivers/net/can/
F: include/linux/can/bittiming.h
F: include/linux/can/dev.h
--
2.17.1
[PATCH v5 1/3] phy: core: Reword the comment specifying the units of max_link_rate to be Mbps
In some subsystems (eg. CAN, SPI), the max link rate supported can be less
than 1 Mbps and if the unit for max_link_rate is Mbps then it can't be
used. Therefore, leave the decision of units to be used, to the producer
and consumer.
Signed-off-by: Aswath Govindraju
---
include/linux/phy/phy.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 0ed434d02196..f3286f4cd306 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -125,7 +125,7 @@ struct phy_ops {
/**
* struct phy_attrs - represents phy attributes
* @bus_width: Data path width implemented by PHY
- * @max_link_rate: Maximum link rate supported by PHY (in Mbps)
+ * @max_link_rate: Maximum link rate supported by PHY (units to be decided by
producer and consumer)
* @mode: PHY mode
*/
struct phy_attrs {
--
2.17.1
Re: [PATCH -next 0/5] Remove redundant dev_err call
On Wed, Apr 07, 2021 at 10:18:14PM +0800, YueHaibing wrote: > This patchset remove some redundant dev_err calls > > YueHaibing (5): > crypto: atmel-tdes - Remove redundant dev_err call in > atmel_tdes_probe() > crypto: img-hash - Remove redundant dev_err call in img_hash_probe() > crypto: ux500 - Remove redundant dev_err calls > crypto: keembay - Remove redundant dev_err calls > crypto: ccree - Remove redundant dev_err call in init_cc_resources() > > drivers/crypto/atmel-tdes.c | 1 - > drivers/crypto/ccree/cc_driver.c | 4 +--- > drivers/crypto/img-hash.c | 3 --- > drivers/crypto/keembay/keembay-ocs-aes-core.c | 4 +--- > drivers/crypto/keembay/keembay-ocs-hcu-core.c | 4 +--- > drivers/crypto/ux500/cryp/cryp_core.c | 1 - > drivers/crypto/ux500/hash/hash_core.c | 1 - > 7 files changed, 3 insertions(+), 15 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: hisilicon/trng - add version to adapt new algorithm
On Wed, Apr 07, 2021 at 05:44:33PM +0800, Weili Qian wrote: > Kunpeng930 supports trng and prng, but Kunpeng920 only supports trng. > > Therefore, version information is added to ensure that prng is not > registered to Crypto subsystem on Kunpeng920. > > Signed-off-by: Weili Qian > --- > drivers/crypto/hisilicon/trng/trng.c | 13 ++--- > 1 file changed, 10 insertions(+), 3 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] drm/rockchip: Cope with endpoints that haven't been registered yet
On Sun, Mar 21, 2021 at 07:58:13PM +0100, Heiko Stuebner wrote:
> Am Dienstag, 16. März 2021, 19:27:53 CET schrieb Jonathan McDowell:
> > The Rockchip RGB CRTC output driver attempts to avoid probing Rockchip
> > subdrivers to see if they're a connected panel or bridge. However part
> > of its checks assumes that if no OF platform device is found then it
> > can't be a valid bridge or panel. This causes issues with I2C controlled
> > bridges that have not yet been registered to the point they can be
> > found.
> >
> > Change this to return EPROBE_DEFER instead of ENODEV and don't ignore
> > such devices. The subsequent call to drm_of_find_panel_or_bridge() will
> > return EPROBE_DEFER as well if there's actually a valid device we should
> > wait for.
> >
> > Signed-off-by: Jonathan McDowell
> > ---
> > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 8 ++--
> > drivers/gpu/drm/rockchip/rockchip_rgb.c | 7 ---
> > 2 files changed, 10 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > index 212bd87c0c4a..b0d63a566501 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > @@ -270,11 +270,15 @@ int rockchip_drm_endpoint_is_subdriver(struct
> > device_node *ep)
> > if (!node)
> > return -ENODEV;
> >
> > - /* status disabled will prevent creation of platform-devices */
> > + /*
> > +* status disabled will prevent creation of platform-devices,
> > +* but equally we can't rely on the driver having been registered
> > +* yet (e.g. I2C bridges).
> > +*/
> > pdev = of_find_device_by_node(node);
> > of_node_put(node);
> > if (!pdev)
> > - return -ENODEV;
> > + return -EPROBE_DEFER;
>
> In general, how does that relate to i2c-bridge-drivers, as
> of_find_device_by_node supposedly only acts on platform-devices?
I think the problem here is that not finding the device node means we
return an error here, which means it's not actually possible to attach
an i2c bridge driver to the Rockchip RGB interface at present.
> Also if that points to a disabled bridge (hdmi, etc) that would likely make
> it probe-defer indefinitly, as that device will never become available?
>
> Maybe we could do something like of_device_is_available() which checks
> the status property of the node. So something like:
>
> pdev = of_find_device_by_node(node);
> if (!pdev) {
> bool avail = of_device_is_available(node);
>
> of_node_put(node);
>
> /* if disabled
> if (!avail)
> return -ENODEV;
> else
> return -EPROBE_DEFER;
> }
> of_node_put(node);
>
> Though I still do not understand how that should actually pick up on
> i2c devices at all.
of_find_device_by_node will fail here, as it's not a platform device,
but then of_device_is_available should return true so I think I can
actually just return false here rather than EPROBE_DEFER - because if
it's not a platform device then it's not a subdriver, which is what
we're checking for.
I'll re-roll and test this weekend and post an updated revision. Thanks
for the pointers.
J.
--
101 things you can't have too much of : 3 - Sleep.
Re: [PATCH] crypto: hisilicon/qm - add stop queue by hardware
On Tue, Apr 06, 2021 at 08:56:02PM +0800, Weili Qian wrote: > Kunpeng930 could be able to stop queue by writing hardware registers, > which will trigger tasks in device to be flushed out. > > In order to be compatible with the kunpeng920 driver, add 'qm_hw_ops_v3' to > adapt Kunpeng930. And 'stop_qp' callback is added in 'qm_hw_ops_v3' to > write hardware registers. Call 'stop_qp' to drain the tasks in device > before releasing queue. > > Signed-off-by: Weili Qian > Reviewed-by: Longfang Liu > --- > drivers/crypto/hisilicon/qm.c | 29 - > 1 file changed, 28 insertions(+), 1 deletion(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH -next] crypto: ixp4xx -: use DEFINE_SPINLOCK() for spinlock
On Tue, Apr 06, 2021 at 08:02:57PM +0800, Huang Guobin wrote: > From: Guobin Huang > > spinlock can be initialized automatically with DEFINE_SPINLOCK() > rather than explicitly calling spin_lock_init(). > > Reported-by: Hulk Robot > Signed-off-by: Guobin Huang > --- > drivers/crypto/ixp4xx_crypto.c | 7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH -next] crypto: geode -: use DEFINE_SPINLOCK() for spinlock
On Tue, Apr 06, 2021 at 08:00:03PM +0800, Huang Guobin wrote: > From: Guobin Huang > > spinlock can be initialized automatically with DEFINE_SPINLOCK() > rather than explicitly calling spin_lock_init(). > > Reported-by: Hulk Robot > Signed-off-by: Guobin Huang > --- > drivers/crypto/geode-aes.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] ecc: delete a useless function declaration
On Tue, Apr 06, 2021 at 10:32:59AM +0800, Meng Yu wrote: > This function declaration has been added in 'ecc_curve.h', > delete it in 'crypto/ecc.h'. > > Fixes: 4e6602916bc6(crypto: ecdsa - Add support for ECDSA ...) > Signed-off-by: Meng Yu > --- > > v1 -> v2: Modify the 'Fixes tag' from '14bb76768275' to '4e6602916bc6 '. > > --- > crypto/ecc.h | 8 > 1 file changed, 8 deletions(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: x86/crash: fix crash_setup_memmap_entries() out-of-bounds access
On Fri, 2021-04-16 at 19:07 +0800, Dave Young wrote: > > > We're excluding two ranges, allocate the scratch space we need to do that. > > I think 1 range should be fine, have you tested 1? Have now, and vzalloc(struct_size(cmem, ranges, 1)) worked just fine. -Mike
Re: [PATCH] powerpc/kdump: fix kdump kernel hangup issue with hot add CPUs
On 16/04/21 3:03 pm, Hari Bathini wrote:
On 16/04/21 12:17 pm, Sourabh Jain wrote:
With the kexec_file_load system call when system crashes on the hot add
CPU the capture kernel hangs and failed to collect the vmcore.
Kernel panic - not syncing: sysrq triggered crash
CPU: 24 PID: 6065 Comm: echo Kdump: loaded Not tainted
5.12.0-rc5upstream #54
Call Trace:
[c000e590fac0] [c07b2400] dump_stack+0xc4/0x114
(unreliable)
[c000e590fb00] [c0145290] panic+0x16c/0x41c
[c000e590fba0] [c08892e0] sysrq_handle_crash+0x30/0x40
[c000e590fc00] [c0889cdc] __handle_sysrq+0xcc/0x1f0
[c000e590fca0] [c088a538] write_sysrq_trigger+0xd8/0x178
[c000e590fce0] [c05e9b7c] proc_reg_write+0x10c/0x1b0
[c000e590fd10] [c04f26d0] vfs_write+0xf0/0x330
[c000e590fd60] [c04f2aec] ksys_write+0x7c/0x140
[c000e590fdb0] [c0031ee0]
system_call_exception+0x150/0x290
[c000e590fe10] [c000ca5c] system_call_common+0xec/0x278
--- interrupt: c00 at 0x7fff905b9664
NIP: 7fff905b9664 LR: 7fff905320c4 CTR:
REGS: c000e590fe80 TRAP: 0c00 Not tainted (5.12.0-rc5upstream)
MSR: 8280f033 CR:
28000242
XER:
IRQMASK: 0
GPR00: 0004 75fedf30 7fff906a7300
0001
GPR04: 01002a7355b0 0002 0001
75fef616
GPR08: 0001
GPR12: 7fff9073a160
GPR16:
GPR20: 7fff906a4ee0 0002
0001
GPR24: 7fff906a0898 0002
01002a7355b0
GPR28: 0002 7fff906a1790 01002a7355b0
0002
NIP [7fff905b9664] 0x7fff905b9664
LR [7fff905320c4] 0x7fff905320c4
--- interrupt: c00
I will update the commit message.
/**
* setup_new_fdt_ppc64 - Update the flattend device-tree of the kernel
* being loaded.
@@ -1020,6 +1113,13 @@ int setup_new_fdt_ppc64(const struct kimage
*image, void *fdt,
}
}
+ /* Update cpus nodes information to account hotplug CPUs. */
+ if (image->type == KEXEC_TYPE_CRASH) {
Shouldn't this apply to regular kexec_file_load case as well? Yeah,
there won't be a hang in regular kexec_file_load case but for
correctness, that kernel should also not see stale CPU info in FDT?
Yes better to update the fdt for both kexec and kdump.
Thanks for the review Hari.
- Sourabh Jain
Re: [PATCH] crypto: hisilicon/hpre - fix unmapping invalid dma address
On Sat, Apr 10, 2021 at 05:49:17PM +0800, Hui Tang wrote: > Currently, an invalid dma address may be unmapped when calling > 'xx_data_clr_all' in error path, so check dma address of sqe in/out > whether it has been mapped before calling 'dma_free_coherent' or > 'dma_unmap_single'. > > An abnormal case is as follows: > hpre_curve25519_compute_value > -> hpre_curve25519_src_init > -> hpre_curve25519_hw_data_clr_all > > Fixes: a9214b0b6ed2(crypto: hisilicon - fix the check on dma address) > Signed-off-by: Hui Tang > --- > drivers/crypto/hisilicon/hpre/hpre_crypto.c | 18 ++ > 1 file changed, 18 insertions(+) This triggers new sparse warnings. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 00/13] [RFC] Rust support
On Wed, Apr 14, 2021 at 08:45:51PM +0200, oj...@kernel.org wrote:
> - Featureful language: sum types, pattern matching, generics,
> RAII, lifetimes, shared & exclusive references, modules &
> visibility, powerful hygienic and procedural macros...
IMO RAII is over-valued, but just in case you care, the below seems to
work just fine. No fancy new language needed, works today. Similarly you
can create refcount_t guards, or with a little more work full blown
smart_ptr crud.
---
diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index e19323521f9c..f03a72dd8cea 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -197,4 +197,22 @@ extern void mutex_unlock(struct mutex *lock);
extern int atomic_dec_and_mutex_lock(atomic_t *cnt, struct mutex *lock);
+struct mutex_guard {
+ struct mutex *mutex;
+};
+
+static inline struct mutex_guard mutex_guard_lock(struct mutex *mutex)
+{
+ mutex_lock(mutex);
+ return (struct mutex_guard){ .mutex = mutex, };
+}
+
+static inline void mutex_guard_unlock(struct mutex_guard *guard)
+{
+ mutex_unlock(guard->mutex);
+}
+
+#define DEFINE_MUTEX_GUARD(name, lock) \
+ struct mutex_guard __attribute__((__cleanup__(mutex_guard_unlock)))
name = mutex_guard_lock(lock)
+
#endif /* __LINUX_MUTEX_H */
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 8ee3249de2f0..603d197a83b8 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5715,16 +5715,15 @@ static long perf_compat_ioctl(struct file *file,
unsigned int cmd,
int perf_event_task_enable(void)
{
+ DEFINE_MUTEX_GUARD(event_mutex, ¤t->perf_event_mutex);
struct perf_event_context *ctx;
struct perf_event *event;
- mutex_lock(¤t->perf_event_mutex);
list_for_each_entry(event, ¤t->perf_event_list, owner_entry) {
ctx = perf_event_ctx_lock(event);
perf_event_for_each_child(event, _perf_event_enable);
perf_event_ctx_unlock(event, ctx);
}
- mutex_unlock(¤t->perf_event_mutex);
return 0;
}
[PATCH v9 8/8] arm64/Kconfig: Introduce ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE
Enable arm64 platform to use the MHP_MEMMAP_ON_MEMORY feature. Signed-off-by: Oscar Salvador Reviewed-by: David Hildenbrand --- arch/arm64/Kconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index e4e1b6550115..68735831b236 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -309,6 +309,9 @@ config ARCH_ENABLE_MEMORY_HOTPLUG config ARCH_ENABLE_MEMORY_HOTREMOVE def_bool y +config ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE + def_bool y + config SMP def_bool y -- 2.16.3
[PATCH v9 7/8] x86/Kconfig: Introduce ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE
Enable x86_64 platform to use the MHP_MEMMAP_ON_MEMORY feature. Signed-off-by: Oscar Salvador Reviewed-by: David Hildenbrand --- arch/x86/Kconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 2792879d398e..9f0211df1746 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2433,6 +2433,9 @@ config ARCH_ENABLE_MEMORY_HOTREMOVE def_bool y depends on MEMORY_HOTPLUG +config ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE + def_bool y + config USE_PERCPU_NUMA_NODE_ID def_bool y depends on NUMA -- 2.16.3
[PATCH v9 6/8] mm,memory_hotplug: Add kernel boot option to enable memmap_on_memory
Self stored memmap leads to a sparse memory situation which is unsuitable
for workloads that requires large contiguous memory chunks, so make this
an opt-in which needs to be explicitly enabled.
To control this, let memory_hotplug have its own memory space, as suggested
by David, so we can add memory_hotplug.memmap_on_memory parameter.
Signed-off-by: Oscar Salvador
Reviewed-by: David Hildenbrand
Acked-by: Michal Hocko
---
Documentation/admin-guide/kernel-parameters.txt | 17 +
mm/Makefile | 5 -
mm/memory_hotplug.c | 10 +-
3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 04545725f187..af32c17cd4eb 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2794,6 +2794,23 @@
seconds. Use this parameter to check at some
other rate. 0 disables periodic checking.
+ memory_hotplug.memmap_on_memory
+ [KNL,X86,ARM] Boolean flag to enable this feature.
+ Format: {on | off (default)}
+ When enabled, runtime hotplugged memory will
+ allocate its internal metadata (struct pages)
+ from the hotadded memory which will allow to
+ hotadd a lot of memory without requiring
+ additional memory to do so.
+ This feature is disabled by default because it
+ has some implication on large (e.g. GB)
+ allocations in some configurations (e.g. small
+ memory blocks).
+ The state of the flag can be read in
+ /sys/module/memory_hotplug/parameters/memmap_on_memory.
+ Note that even when enabled, there are a few cases where
+ the feature is not effective.
+
memtest=[KNL,X86,ARM,PPC] Enable memtest
Format:
default : 0
diff --git a/mm/Makefile b/mm/Makefile
index 72227b24a616..82ae9482f5e3 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -58,9 +58,13 @@ obj-y:= filemap.o mempool.o
oom_kill.o fadvise.o \
page-alloc-y := page_alloc.o
page-alloc-$(CONFIG_SHUFFLE_PAGE_ALLOCATOR) += shuffle.o
+# Give 'memory_hotplug' its own module-parameter namespace
+memory-hotplug-$(CONFIG_MEMORY_HOTPLUG) += memory_hotplug.o
+
obj-y += page-alloc.o
obj-y += init-mm.o
obj-y += memblock.o
+obj-y += $(memory-hotplug-y)
ifdef CONFIG_MMU
obj-$(CONFIG_ADVISE_SYSCALLS) += madvise.o
@@ -83,7 +87,6 @@ obj-$(CONFIG_SLUB) += slub.o
obj-$(CONFIG_KASAN)+= kasan/
obj-$(CONFIG_KFENCE) += kfence/
obj-$(CONFIG_FAILSLAB) += failslab.o
-obj-$(CONFIG_MEMORY_HOTPLUG) += memory_hotplug.o
obj-$(CONFIG_MEMTEST) += memtest.o
obj-$(CONFIG_MIGRATION) += migrate.o
obj-$(CONFIG_TRANSPARENT_HUGEPAGE) += huge_memory.o khugepaged.o
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 5ef626926449..b93949a84d4a 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -42,7 +42,15 @@
#include "internal.h"
#include "shuffle.h"
-static bool memmap_on_memory;
+
+/*
+ * memory_hotplug.memmap_on_memory parameter
+ */
+static bool memmap_on_memory __ro_after_init;
+#ifdef CONFIG_MHP_MEMMAP_ON_MEMORY
+module_param(memmap_on_memory, bool, 0444);
+MODULE_PARM_DESC(memmap_on_memory, "Enable memmap on memory for memory
hotplug");
+#endif
/*
* online_page_callback contains pointer to current page onlining function.
--
2.16.3
[PATCH v9 5/8] acpi,memhotplug: Enable MHP_MEMMAP_ON_MEMORY when supported
Let the caller check whether it can pass MHP_MEMMAP_ON_MEMORY by checking mhp_supports_memmap_on_memory(). MHP_MEMMAP_ON_MEMORY can only be set in case ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE is enabled, the architecture supports altmap, and the range to be added spans a single memory block. Signed-off-by: Oscar Salvador Reviewed-by: David Hildenbrand Acked-by: Michal Hocko --- drivers/acpi/acpi_memhotplug.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c index b02fd51e5589..8cc195c4c861 100644 --- a/drivers/acpi/acpi_memhotplug.c +++ b/drivers/acpi/acpi_memhotplug.c @@ -171,6 +171,7 @@ static int acpi_memory_enable_device(struct acpi_memory_device *mem_device) acpi_handle handle = mem_device->device->handle; int result, num_enabled = 0; struct acpi_memory_info *info; + mhp_t mhp_flags = MHP_NONE; int node; node = acpi_get_node(handle); @@ -194,8 +195,10 @@ static int acpi_memory_enable_device(struct acpi_memory_device *mem_device) if (node < 0) node = memory_add_physaddr_to_nid(info->start_addr); + if (mhp_supports_memmap_on_memory(info->length)) + mhp_flags |= MHP_MEMMAP_ON_MEMORY; result = __add_memory(node, info->start_addr, info->length, - MHP_NONE); + mhp_flags); /* * If the memory block has been used by the kernel, add_memory() -- 2.16.3
[PATCH v9 4/8] mm,memory_hotplug: Allocate memmap from the added memory range
Physical memory hotadd has to allocate a memmap (struct page array) for
the newly added memory section. Currently, alloc_pages_node() is used
for those allocations.
This has some disadvantages:
a) an existing memory is consumed for that purpose
(eg: ~2MB per 128MB memory section on x86_64)
b) if the whole node is movable then we have off-node struct pages
which has performance drawbacks.
c) It might be there are no PMD_ALIGNED chunks so memmap array gets
populated with base pages.
This can be improved when CONFIG_SPARSEMEM_VMEMMAP is enabled.
Vmemap page tables can map arbitrary memory.
That means that we can simply use the beginning of each memory section and
map struct pages there.
struct pages which back the allocated space then just need to be treated
carefully.
Implementation wise we will reuse vmem_altmap infrastructure to override
the default allocator used by __populate_section_memmap.
Part of the implementation also relies on memory_block structure gaining
a new field which specifies the number of vmemmap_pages at the beginning.
This patch also introduces the following functions:
- mhp_init_memmap_on_memory:
Initializes vmemmap pages by calling
move_pfn_range_to_zone(),
calls kasan_add_zero_shadow(), and onlines as many
sections
as vmemmap pages fully span.
- mhp_deinit_memmap_on_memory:
Undoes what mhp_init_memmap_on_memory.
The new function memory_block_online() calls mhp_init_memmap_on_memory() before
doing the actual online_pages(). Should online_pages() fail, we clean up
by calling mhp_deinit_memmap_on_memory().
Adjusting of present_pages is done at the end once we know that online_pages()
succedeed.
On offline, memory_block_offline() needs to unaccount vmemmap pages from
present_pages() before calling offline_pages().
This is necessary because offline_pages() tears down some structures based
on the fact whether the node or the zone become empty.
If offline_pages() fails, we account back vmemmap pages.
If it succeeds, we call mhp_deinit_memmap_on_memory().
Hot-remove:
We need to be careful when removing memory, as adding and
removing memory needs to be done with the same granularity.
To check that this assumption is not violated, we check the
memory range we want to remove and if a) any memory block has
vmemmap pages and b) the range spans more than a single memory
block, we scream out loud and refuse to proceed.
If all is good and the range was using memmap on memory (aka vmemmap pages),
we construct an altmap structure so free_hugepage_table does the right
thing and calls vmem_altmap_free instead of free_pagetable.
Signed-off-by: Oscar Salvador
Reviewed-by: David Hildenbrand
---
drivers/base/memory.c | 71 --
include/linux/memory.h | 8 ++-
include/linux/memory_hotplug.h | 15 +++-
include/linux/memremap.h | 2 +-
include/linux/mmzone.h | 7 +-
mm/Kconfig | 5 ++
mm/memory_hotplug.c| 159 ++---
mm/sparse.c| 2 -
8 files changed, 247 insertions(+), 22 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index f209925a5d4e..2e2b2f654f0a 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -173,16 +173,72 @@ static int memory_block_online(struct memory_block *mem)
{
unsigned long start_pfn = section_nr_to_pfn(mem->start_section_nr);
unsigned long nr_pages = PAGES_PER_SECTION * sections_per_block;
+ unsigned long nr_vmemmap_pages = mem->nr_vmemmap_pages;
+ struct zone *zone;
+ int ret;
+
+ zone = zone_for_pfn_range(mem->online_type, mem->nid, start_pfn,
nr_pages);
+
+ /*
+* Although vmemmap pages have a different lifecycle than the pages
+* they describe (they remain until the memory is unplugged), doing
+* their initialization and accounting at memory onlining/offlining
+* stage simplifies things a lot.
+*/
+ if (nr_vmemmap_pages) {
+ ret = mhp_init_memmap_on_memory(start_pfn, nr_vmemmap_pages,
zone);
+ if (ret)
+ return ret;
+ }
+
+ ret = online_pages(start_pfn + nr_vmemmap_pages,
+ nr_pages - nr_vmemmap_pages, zone);
+ if (ret) {
+ if (nr_vmemmap_pages)
+ mhp_deinit_memmap_on_memory(start_pfn,
nr_vmemmap_pages);
+ return ret;
+ }
+
+ /*
+* Account once onlining succeeded. If the zone was unpopulated, it is
+* now already properly populated.
+*/
+ if (nr_vmemmap_pages)
+ adjust_present_page_count(zone, nr_vmemmap_pages);
- return online_pages(start_pfn, nr_pages, mem->online_type, mem->nid);
+ return ret;
}
static int memory_block_offline(struct memory_block *mem)
{
un
[PATCH v9 3/8] mm,memory_hotplug: Factor out adjusting present pages into adjust_present_page_count()
From: David Hildenbrand
Let's have a single place (inspired by adjust_managed_page_count()) where
we adjust present pages.
In contrast to adjust_managed_page_count(), only memory onlining/offlining
is allowed to modify the number of present pages.
Signed-off-by: David Hildenbrand
Signed-off-by: Oscar Salvador
Reviewed-by: Oscar Salvador
---
mm/memory_hotplug.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 25e59d5dc13c..d05056b3c173 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -829,6 +829,16 @@ struct zone * zone_for_pfn_range(int online_type, int nid,
unsigned start_pfn,
return default_zone_for_pfn(nid, start_pfn, nr_pages);
}
+static void adjust_present_page_count(struct zone *zone, long nr_pages)
+{
+ unsigned long flags;
+
+ zone->present_pages += nr_pages;
+ pgdat_resize_lock(zone->zone_pgdat, &flags);
+ zone->zone_pgdat->node_present_pages += nr_pages;
+ pgdat_resize_unlock(zone->zone_pgdat, &flags);
+}
+
int __ref online_pages(unsigned long pfn, unsigned long nr_pages,
int online_type, int nid)
{
@@ -882,11 +892,7 @@ int __ref online_pages(unsigned long pfn, unsigned long
nr_pages,
}
online_pages_range(pfn, nr_pages);
- zone->present_pages += nr_pages;
-
- pgdat_resize_lock(zone->zone_pgdat, &flags);
- zone->zone_pgdat->node_present_pages += nr_pages;
- pgdat_resize_unlock(zone->zone_pgdat, &flags);
+ adjust_present_page_count(zone, nr_pages);
node_states_set_node(nid, &arg);
if (need_zonelists_rebuild)
@@ -1701,11 +1707,7 @@ int __ref offline_pages(unsigned long start_pfn,
unsigned long nr_pages)
/* removal success */
adjust_managed_page_count(pfn_to_page(start_pfn), -nr_pages);
- zone->present_pages -= nr_pages;
-
- pgdat_resize_lock(zone->zone_pgdat, &flags);
- zone->zone_pgdat->node_present_pages -= nr_pages;
- pgdat_resize_unlock(zone->zone_pgdat, &flags);
+ adjust_present_page_count(zone, -nr_pages);
init_per_zone_wmark_min();
--
2.16.3
[PATCH v9 0/8] Allocate memmap from hotadded memory (per device)
Hi Andrew,
Please, consider pulling out the patch that sits currently in linux-mm and
put this one instead.
I would still like to hear Michal's opinion but it should be safe
enough to let it sit in the mmotm/linux-next for a while.
Thanks
Changes from v8 -> v9:
- Change order of kasan calls and offline_mem_sections
- Collect Reviewed-by
Changes from v7 -> v8:
- Addressed feedback from David for patch#4
Changes from v6 -> v7:
- Fix check from "mm,memory_hotplug: Relax fully spanned sections check"
- Add fixup from "mm,memory_hotplug: Allocate memmap from the added memory
range"
- Add Reviewed-by from David for patch#2
- Fix changelog in "mm,memory_hotplug: Factor out adjusting present pages into
adjust_present_page_count()"
Changes from v5 -> v6:
- Create memory_block_{online,offline} functions
- Create vmemmap_* functions to deal with vmemmap stuff, so
{online,offline}_pages remain untouched
- Add adjust_present_page_count's patch from David
- Relax check in {offline,online}_pages
- Rework changelogs
Changes from v4 -> v5:
- Addressed feedback from David (patch#1)
- Tested on x86_64 with different struct page sizes and on large/small memory
blocks
- Tested on arm64 with 4K, 64K (with and without THP) and with different struct
page sizes
NOTE: We might need to make this feature and hugetlb-vmemmap feature [1]
mutually
exclusive. I raised an issue I see in [2].
Hugetlb-vmemmap feature has been withdrawn for the time being due to the
need
in further changes wrt. locking/freeing context.
I will keep an eye, and when the time comes again I will see how the two
features play together and how one another can be disabled when needed.
Changes from v3 -> v4:
- Addressed feedback from David
- Wrap memmap_on_memory module thingy with #ifdef
on MHP_MEMMAP_ON_MEMORY
- Move "depend on MEMORY_HOTPLUG" to MHP_MEMMAP_ON_MEMORY
in generic mm/Kconfig
- Collect David's Reviewed-bys
Changes from v2 -> v3:
- Addressed feedback from David
- Squash former patch#4 and and patch#5 into patch#1
- Fix config dependency CONFIR_SPARSE_VMEMMAP vs CONFIG_SPARSE_VMEMMAP_ENABLE
- Simplify module parameter functions
Changes from v1 -> v2
- Addressed feedback from David
- Fence off the feature in case struct page size is not
multiple of PMD size or pageblock alignment cannot be guaranted
- Tested on x86_64 small and large memory_blocks
- Tested on arm64 4KB and 64KB page sizes (for some reason I cannot boot
my VM with 16KB page size).
Arm64 with 4KB page size behaves like x86_64 after [1], which made section
size smaller.
With 64KB, the feature gets fenced off due to pageblock alignment.
Changes from RFCv3 -> v1:
- Addressed feedback from David
- Re-order patches
Changes from v2 -> v3 (RFC):
- Re-order patches (Michal)
- Fold "mm,memory_hotplug: Introduce MHP_MEMMAP_ON_MEMORY" in patch#1
- Add kernel boot option to enable this feature (Michal)
Changes from v1 -> v2 (RFC):
- Addressed feedback provided by David
- Add a arch_support_memmap_on_memory to be called
from mhp_supports_memmap_on_memory, as atm,
only ARM, powerpc and x86_64 have altmat support.
[1] https://lore.kernel.org/lkml/cover.1611206601.git.sudaraj...
Original cover letter:
The primary goal of this patchset is to reduce memory overhead of the
hot-added memory (at least for SPARSEMEM_VMEMMAP memory model).
The current way we use to populate memmap (struct page array) has two main
drawbacks:
a) it consumes an additional memory until the hotadded memory itself is
onlined and
b) memmap might end up on a different numa node which is especially true
for movable_node configuration.
c) due to fragmentation we might end up populating memmap with base
pages
One way to mitigate all these issues is to simply allocate memmap array
(which is the largest memory footprint of the physical memory hotplug)
from the hot-added memory itself. SPARSEMEM_VMEMMAP memory model allows
us to map any pfn range so the memory doesn't need to be online to be
usable for the array. See patch 4 for more details.
This feature is only usable when CONFIG_SPARSEMEM_VMEMMAP is set.
[Overall design]:
Implementation wise we reuse vmem_altmap infrastructure to override
the default allocator used by vmemap_populate.
memory_block structure gains a new field called nr_vmemmap_pages,
which accounts for the number of vmemmap pages used by that memory_block.
E.g: On x86_64, that is 512 vmemmap pages on small memory bloks and 4096
on large memory blocks (1GB)
We also introduce new two functions: memory_block_{online,offline}.
These functions take care of initializing/unitializing vmemmap pages
prior to calling {online,offline}_pages, so the latter functions can
remain totally untouched.
More details can be found in the respective changelogs.
David Hildenbrand (1):
mm,memory_hotplug: Factor out adjusting present pages into
adjust_present_page_count(
[PATCH v9 2/8] mm,memory_hotplug: Relax fully spanned sections check
When using self-hosted vmemmap pages, the number of pages passed to
{online,offline}_pages might not fully span sections, but they always
fully span pageblocks.
Relax the check account for that case.
Signed-off-by: Oscar Salvador
Reviewed-by: David Hildenbrand
---
mm/memory_hotplug.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 0cdbbfbc5757..25e59d5dc13c 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -838,9 +838,14 @@ int __ref online_pages(unsigned long pfn, unsigned long
nr_pages,
int ret;
struct memory_notify arg;
- /* We can only online full sections (e.g., SECTION_IS_ONLINE) */
+ /* We can only offline full sections (e.g., SECTION_IS_ONLINE).
+* However, when using e.g: memmap_on_memory, some pages are initialized
+* prior to calling in here. The remaining amount of pages must be
+* pageblock aligned.
+*/
if (WARN_ON_ONCE(!nr_pages ||
-!IS_ALIGNED(pfn | nr_pages, PAGES_PER_SECTION)))
+!IS_ALIGNED(pfn, pageblock_nr_pages) ||
+!IS_ALIGNED(pfn + nr_pages, PAGES_PER_SECTION)))
return -EINVAL;
mem_hotplug_begin();
@@ -1573,9 +1578,14 @@ int __ref offline_pages(unsigned long start_pfn,
unsigned long nr_pages)
int ret, node;
char *reason;
- /* We can only offline full sections (e.g., SECTION_IS_ONLINE) */
+ /* We can only offline full sections (e.g., SECTION_IS_ONLINE).
+* However, when using e.g: memmap_on_memory, some pages are initialized
+* prior to calling in here. The remaining amount of pages must be
+* pageblock aligned.
+*/
if (WARN_ON_ONCE(!nr_pages ||
-!IS_ALIGNED(start_pfn | nr_pages, PAGES_PER_SECTION)))
+!IS_ALIGNED(start_pfn, pageblock_nr_pages) ||
+!IS_ALIGNED(start_pfn + nr_pages, PAGES_PER_SECTION)))
return -EINVAL;
mem_hotplug_begin();
--
2.16.3
[PATCH v9 1/8] drivers/base/memory: Introduce memory_block_{online,offline}
This is a preparatory patch that introduces two new functions:
memory_block_online() and memory_block_offline().
For now, these functions will only call online_pages() and offline_pages()
respectively, but they will be later in charge of preparing the vmemmap
pages, carrying out the initialization and proper accounting of such
pages.
Since memory_block struct contains all the information, pass this struct
down the chain till the end functions.
Signed-off-by: Oscar Salvador
Reviewed-by: David Hildenbrand
---
drivers/base/memory.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index f35298425575..f209925a5d4e 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -169,30 +169,41 @@ int memory_notify(unsigned long val, void *v)
return blocking_notifier_call_chain(&memory_chain, val, v);
}
+static int memory_block_online(struct memory_block *mem)
+{
+ unsigned long start_pfn = section_nr_to_pfn(mem->start_section_nr);
+ unsigned long nr_pages = PAGES_PER_SECTION * sections_per_block;
+
+ return online_pages(start_pfn, nr_pages, mem->online_type, mem->nid);
+}
+
+static int memory_block_offline(struct memory_block *mem)
+{
+ unsigned long start_pfn = section_nr_to_pfn(mem->start_section_nr);
+ unsigned long nr_pages = PAGES_PER_SECTION * sections_per_block;
+
+ return offline_pages(start_pfn, nr_pages);
+}
+
/*
* MEMORY_HOTPLUG depends on SPARSEMEM in mm/Kconfig, so it is
* OK to have direct references to sparsemem variables in here.
*/
static int
-memory_block_action(unsigned long start_section_nr, unsigned long action,
- int online_type, int nid)
+memory_block_action(struct memory_block *mem, unsigned long action)
{
- unsigned long start_pfn;
- unsigned long nr_pages = PAGES_PER_SECTION * sections_per_block;
int ret;
- start_pfn = section_nr_to_pfn(start_section_nr);
-
switch (action) {
case MEM_ONLINE:
- ret = online_pages(start_pfn, nr_pages, online_type, nid);
+ ret = memory_block_online(mem);
break;
case MEM_OFFLINE:
- ret = offline_pages(start_pfn, nr_pages);
+ ret = memory_block_offline(mem);
break;
default:
WARN(1, KERN_WARNING "%s(%ld, %ld) unknown action: "
-"%ld\n", __func__, start_section_nr, action, action);
+"%ld\n", __func__, mem->start_section_nr, action, action);
ret = -EINVAL;
}
@@ -210,9 +221,7 @@ static int memory_block_change_state(struct memory_block
*mem,
if (to_state == MEM_OFFLINE)
mem->state = MEM_GOING_OFFLINE;
- ret = memory_block_action(mem->start_section_nr, to_state,
- mem->online_type, mem->nid);
-
+ ret = memory_block_action(mem, to_state);
mem->state = ret ? from_state_req : to_state;
return ret;
--
2.16.3
Re: [PATCH v1 2/2] dt-bindings: arm: add property for coresight component name
Tao Zhang writes: > Add property "coresight-name" for coresight component name. This > allows coresight driver to read device name from device entries. > > Signed-off-by: Tao Zhang > --- > Documentation/devicetree/bindings/arm/coresight.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/coresight.txt > b/Documentation/devicetree/bindings/arm/coresight.txt > index d711676..0e980ce 100644 > --- a/Documentation/devicetree/bindings/arm/coresight.txt > +++ b/Documentation/devicetree/bindings/arm/coresight.txt > @@ -103,6 +103,8 @@ its hardware characteristcs. > powers down the coresight component also powers down and loses its > context. This property is currently only used for the ETM 4.x driver. > > + * coresight-name: the name of the coresight devices. Which devices? Also, is it a common practice to extend device tree definitions based on arbitrary driver needs, or should there be some sort of a discussion first? Regards, -- Alex
Re: [PATCH v3 1/2] perf/core: Share an event with multiple cgroups
On Fri, Apr 16, 2021 at 7:28 PM Peter Zijlstra wrote: > > On Fri, Apr 16, 2021 at 11:29:30AM +0200, Peter Zijlstra wrote: > > > > So I think we've had proposals for being able to close fds in the past; > > > while preserving groups etc. We've always pushed back on that because of > > > the resource limit issue. By having each counter be a filedesc we get a > > > natural limit on the amount of resources you can consume. And in that > > > respect, having to use 400k fds is things working as designed. > > > > > > Anyway, there might be a way around this.. > > So how about we flip the whole thing sideways, instead of doing one > event for multiple cgroups, do an event for multiple-cpus. > > Basically, allow: > > perf_event_open(.pid=fd, cpu=-1, .flag=PID_CGROUP); > > Which would have the kernel create nr_cpus events [the corrolary is that > we'd probably also allow: (.pid=-1, cpu=-1) ]. Do you mean it'd have separate perf_events per cpu internally? >From a cpu's perspective, there's nothing changed, right? Then it will have the same performance problem as of now. > > Output could be done by adding FORMAT_PERCPU, which takes the current > read() format and writes a copy for each CPU event. (p)read(v)() could > be used to explode or partial read that. Yeah, I think it's good for read. But what about mmap? I don't think we can use file offset since it's taken for auxtrace. Maybe we can simply disallow that.. > > This gets rid of the nasty variadic nature of the > 'get-me-these-n-cgroups'. While still getting rid of the n*m fd issue > you're facing. As I said, it's not just a file descriptor problem. In fact, performance is more concerning. Thanks, Namhyung
