Re: RE: Generous Grant
I Mikhail Fridman. has selected you specially as one of my beneficiaries for my Charitable Donation, Just as I have declared on May 23, 2016 to give my fortune as charity. Check the link below for confirmation: http://www.ibtimes.co.uk/russias-second-wealthiest-man-mikhail-fridman-plans-leaving-14-2bn-fortune-charity-1561604 Reply as soon as possible with further directives. Best Regards, Mikhail Fridman.
Re: [PATCH] proc: prevent a task from writing on its own /proc/*/mem
2018-06-04 18:57 GMT+02:00 Steve Kemp : >> A configurable LSM is probably the right way to do this. > > I wonder how many out of tree LSM there are? Looking at the mainline > kernel the only "small" LSM bundled is YAMA, and it seems that most of > the patches proposing new ones eventually die out. > > I appreciate that there are probably a lot of "toy" or "local" modules > out there for specific fields, companies, or products, but it does > seem odd that there are so few discussed publicly. > > (The last two I remember were S.A.R.A and something relating to > xattr-attributes being used to whitelist execution.) FWIW S.A.R.A. is not dead [1]. Unfortunately it needs infrastructure managed security blobs, so I didn't tried to get it upstream, yet. Of course, I can't give you any guarantees about when or if it will be upstreamed, but it's definitely still alive. [1] https://github.com/smeso/sara/releases/latest
Re: [PATCH] staging: comedi: Improved readability of function comedi_nsamples_left.
Hi Greg,
I've added changelog text to the patch below. Appreciate your
feedback!
Regards,
Chris Opperman
>8--8<
Improved the readability of comedi_nsamples_left:
a) Reduced nesting by using more return calls.
b) Separated variable declarations from code.
c) Using kernel integer types.
Signed-off-by: Chris Opperman
---
drivers/staging/comedi/drivers.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/comedi/drivers.c b/drivers/staging/comedi/drivers.c
index 9d73347..3207ae2 100644
--- a/drivers/staging/comedi/drivers.c
+++ b/drivers/staging/comedi/drivers.c
@@ -468,26 +468,25 @@ EXPORT_SYMBOL_GPL(comedi_nscans_left);
* Returns the number of samples remaining to complete the command, or the
* specified expected number of samples (@nsamples), whichever is fewer.
*/
-unsigned int comedi_nsamples_left(struct comedi_subdevice *s,
- unsigned int nsamples)
+u32 comedi_nsamples_left(struct comedi_subdevice *s, u32 nsamples)
{
struct comedi_async *async = s->async;
struct comedi_cmd *cmd = &async->cmd;
+ u32 scans_left;
+ u64 samples_left;
- if (cmd->stop_src == TRIG_COUNT) {
- unsigned int scans_left = __comedi_nscans_left(s,
cmd->stop_arg);
- unsigned int scan_pos =
- comedi_bytes_to_samples(s, async->scan_progress);
- unsigned long long samples_left = 0;
-
- if (scans_left) {
- samples_left = ((unsigned long long)scans_left *
- cmd->scan_end_arg) - scan_pos;
- }
+ if (cmd->stop_src != TRIG_COUNT)
+ return nsamples;
- if (samples_left < nsamples)
- nsamples = samples_left;
- }
+ scans_left = __comedi_nscans_left(s, cmd->stop_arg);
+ if (!scans_left)
+ return 0;
+
+ samples_left = ((u64)scans_left * cmd->scan_end_arg) -
+ comedi_bytes_to_samples(s, async->scan_progress);
+
+ if (samples_left < nsamples)
+ return samples_left;
return nsamples;
}
EXPORT_SYMBOL_GPL(comedi_nsamples_left);
--
2.1.4
Re: [PATCH 4.14 00/41] 4.14.49-stable review
On 9 June 2018 at 20:59, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.49 release. > There are 41 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 Mon Jun 11 15:29:07 UTC 2018. > 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.49-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 and x86_64. Summary kernel: 4.14.49-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.14.y git commit: 8a073119a25f3a91734d482e869c6f8203cd6171 git describe: v4.14.48-42-g8a073119a25f Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.48-42-g8a073119a25f No regressions (compared to build v4.14.48-43-gcb411db6da07) Ran 11405 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-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-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 4.16 00/48] 4.16.15-stable review
On 9 June 2018 at 20:59, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.16.15 release. > There are 48 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 Mon Jun 11 14:59:28 UTC 2018. > 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.16.15-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.16.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm and x86_64. Summary kernel: 4.16.15-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.16.y git commit: 0f447b621dc169007a7c7a87db5a5ca0b8070833 git describe: v4.16.14-49-g0f447b621dc1 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.16-oe/build/v4.16.14-49-g0f447b621dc1 No regressions (compared to build v4.16.14) Ran 11375 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-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-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH v3 1/3] nvmem: Update the OF binding to use a subnode for the cells list
On 08/06/18 18:07, Alban wrote:
On Fri, 8 Jun 2018 12:34:12 +0100
Srinivas Kandagatla wrote:
...
I looked into this. It would work fine for the cells but not so nicely
for the nvmem device API. The phandle for the nvmem device would have
to reference the node passed here and not the real device. We would end
up with a DT like this:
flash@0 {
compatible = "mtd";
...
nvmem_dev: nvmem-cells {
compatible = "nvmem-cells";
...
};
};
other-device@10 {
...
nvmem = <&nvmem_dev>;
};
Now if there is no cell defined we have this empty child node that make
very little sense, it is just there to accommodate the nvmem API.
NO. This just looks fine!
nvmem-cells is the nvmem provider node without which you would not have
any provider instance.
All this looks as expected!
Am not sure what is the problem here!
What I would suggest now is to just change the wording. We don't
deprecate the current binding, but we extend it to allow grouping the
cells in a child node if required. The code to support this is trivial,
(4 lines including error handling) so even if we expect very few
bindings to make use of it it is not going to be maintenance drag.
That would look like this:
diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.txt
b/Documentation/devicetree/bindings/nvmem/nvmem.txt
index fd06c09..085d042 100644
--- a/Documentation/devicetree/bindings/nvmem/nvmem.txt
+++ b/Documentation/devicetree/bindings/nvmem/nvmem.txt
@@ -19,7 +19,10 @@ Optional properties:
= Data cells =
These are the child nodes of the provider which contain data cell
-information like offset and size in nvmem provider.
+information like offset and size in nvmem provider. Alternatively the data
+cells can be grouped in a node that has a compatible property set to
+"nvmem-cells".
+
Required properties:
reg: specifies the offset in byte within the storage device.
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 4e94a78..3e1369c 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -859,6 +859,14 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node
*np,
if (!nvmem_np)
return ERR_PTR(-EINVAL);
+ /* bindings that already have anonymous child nodes can instead put
+* their cells in a child node with an nvmem-cells compatible. */
+ if (of_device_is_compatible(nvmem_np, "nvmem-cells")) {
+ nvmem_np = of_get_next_parent(nvmem_np);
+ if (!nvmem_np)
+ return ERR_PTR(-EINVAL);
+ }
+
nvmem = __nvmem_device_get(nvmem_np, NULL, NULL);
of_node_put(nvmem_np);
if (IS_ERR(nvmem))
What about it?
Let me repeat what I have said in my previous emails:
Having a subnode still sounds very fragile to me,
and this could be much specific case of MTD provider. We might have
instances where this could be sub-sub node of the the original provider
for other providers. Also I do not want to bring in Provider specifics
layout into nvmem bindings.
I can not make myself any clearer than this, Its going to be a NAK from
my side for the above reasons!
Also, patch I shared should give enough flexibility to various range of
providers which have different child node layouts without touching the
nvmem bindings. If it works please use it.
thanks,
srini
Alban
Re: [PATCH v2] irqchip/gic-v3-its: fix ITS queue timeout
Hi Hanjun, On Thu, 07 Jun 2018 13:25:26 +0100, Hanjun Guo wrote: > > Hi Marc, > > On 2018/6/6 17:13, Marc Zyngier wrote: > [...] > > > > Wouldn't it be better to just return that the affinity setting request > > is impossible to satisfy? And more to the point, how comes we end-up > > in such a case? > > The system is booted with a NUMA node has no memory attaching to it > (memory-less NUMA node), also with NR_CPUS less than CPUs presented > in MADT, so CPUs on this memory-less node are not brought up, and > this NUMA node will not be online too. But the ITS attaching to this NUMA > domain is still valid and represented via SRAT to ITS driver. > > This is really the corner case which is triggered by the boot testing > when enabling our D06 boards, but it's a bug :) I'm not debating the bringing up (or lack thereof) of the secondary CPUs. I'm questioning the affinity setting to unavailable CPUs, and I really wonder what the semantic of such a thing is (and how we end-up there). Anyway, I'll plug the "SYNC to unmapped collection" issue (which definitely needs fixing), but I'd like to understand the above. Thanks, M. -- Jazz is not dead, it just smell funny.
Re: [PATCH 2/2] IB/mad: Use IDR for agent IDs
On Sun, Jun 10, 2018 at 09:30:28AM +0300, Leon Romanovsky wrote: > 1. IBTA spec doesn't talk at all about the size of TransactionID, more > on that in section "13.4.6.4 TRANSACTION ID USAGE", the specification > says: "The contents of the TransactionID (TID) field are implementation- > dependent. So let's don't call it mlx4 bug. I was loosely paraphrasing the original bug report; suggested rewording of the comments gratefully accepted. > 2. The current implementation means that in mlx5-only network we will > still have upto (1 << 24) TIDs. I don't know if it is really important, > but worth to mention. Actually, the TIDs will be up to 2^56. We're limited to 2^24 clients, each of which can send up to 2^32 messages.
Re: [PATCH v5 4/4] kernel hacking: new config CC_OPTIMIZE_FOR_DEBUGGING to apply GCC -Og optimization
Hi Changbin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.17 next-20180608]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180606-001415
config: i386-randconfig-x079-06101602 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
In file included from arch/x86/include/asm/page_32.h:35:0,
from arch/x86/include/asm/page.h:14,
from arch/x86/include/asm/thread_info.h:12,
from include/linux/thread_info.h:38,
from arch/x86/include/asm/preempt.h:7,
from include/linux/preempt.h:81,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:36,
from include/linux/time.h:6,
from include/linux/stat.h:19,
from include/linux/module.h:10,
from net//bluetooth/mgmt.c:27:
net//bluetooth/mgmt.c: In function 'read_local_oob_ext_data_complete':
>> include/linux/string.h:345:9: warning: 'r256' may be used uninitialized in
>> this function [-Wmaybe-uninitialized]
return __builtin_memcpy(p, q, size);
^~~~
net//bluetooth/mgmt.c:5669:27: note: 'r256' was declared here
u8 *h192, *r192, *h256, *r256;
^~~~
--
In file included from arch/x86/include/asm/page_32.h:35:0,
from arch/x86/include/asm/page.h:14,
from arch/x86/include/asm/thread_info.h:12,
from include/linux/thread_info.h:38,
from arch/x86/include/asm/preempt.h:7,
from include/linux/preempt.h:81,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:36,
from include/linux/time.h:6,
from include/linux/stat.h:19,
from include/linux/module.h:10,
from net/bluetooth/mgmt.c:27:
net/bluetooth/mgmt.c: In function 'read_local_oob_ext_data_complete':
>> include/linux/string.h:345:9: warning: 'r256' may be used uninitialized in
>> this function [-Wmaybe-uninitialized]
return __builtin_memcpy(p, q, size);
^~~~
net/bluetooth/mgmt.c:5669:27: note: 'r256' was declared here
u8 *h192, *r192, *h256, *r256;
^~~~
vim +/r256 +345 include/linux/string.h
6974f0c4 Daniel Micay 2017-07-12 332
6974f0c4 Daniel Micay 2017-07-12 333 __FORTIFY_INLINE void *memcpy(void *p,
const void *q, __kernel_size_t size)
6974f0c4 Daniel Micay 2017-07-12 334 {
6974f0c4 Daniel Micay 2017-07-12 335 size_t p_size =
__builtin_object_size(p, 0);
6974f0c4 Daniel Micay 2017-07-12 336 size_t q_size =
__builtin_object_size(q, 0);
6974f0c4 Daniel Micay 2017-07-12 337 if (__builtin_constant_p(size)) {
6974f0c4 Daniel Micay 2017-07-12 338 if (p_size < size)
6974f0c4 Daniel Micay 2017-07-12 339 __write_overflow();
6974f0c4 Daniel Micay 2017-07-12 340 if (q_size < size)
6974f0c4 Daniel Micay 2017-07-12 341 __read_overflow2();
6974f0c4 Daniel Micay 2017-07-12 342 }
6974f0c4 Daniel Micay 2017-07-12 343 if (p_size < size || q_size < size)
6974f0c4 Daniel Micay 2017-07-12 344 fortify_panic(__func__);
6974f0c4 Daniel Micay 2017-07-12 @345 return __builtin_memcpy(p, q, size);
6974f0c4 Daniel Micay 2017-07-12 346 }
6974f0c4 Daniel Micay 2017-07-12 347
:: The code at line 345 was first introduced by commit
:: 6974f0c4555e285ab217cee58b6e874f776ff409 include/linux/string.h: add the
option of fortified string.h functions
:: TO: Daniel Micay
:: CC: Linus Torvalds
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v3 4/6] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver
On 09.06.2018 14:21, Dmitry Osipenko wrote: > On Saturday, 9 June 2018 00:51:01 MSK Stefan Agner wrote: >> On 01.06.2018 11:20, Dmitry Osipenko wrote: >> > On 01.06.2018 01:16, Stefan Agner wrote: >> >> Add support for the NAND flash controller found on NVIDIA >> >> Tegra 2 SoCs. This implementation does not make use of the >> >> command queue feature. Regular operations/data transfers are >> >> done in PIO mode. Page read/writes with hardware ECC make >> >> use of the DMA for data transfer. >> >> >> >> Signed-off-by: Lucas Stach >> >> Signed-off-by: Stefan Agner >> >> --- >> >> >> >> MAINTAINERS |7 + >> >> drivers/mtd/nand/raw/Kconfig |6 + >> >> drivers/mtd/nand/raw/Makefile |1 + >> >> drivers/mtd/nand/raw/tegra_nand.c | 1143 + >> >> 4 files changed, 1157 insertions(+) >> >> create mode 100644 drivers/mtd/nand/raw/tegra_nand.c >> >> >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> >> index 58b9861ccf99..c2e5571c85d4 100644 >> >> --- a/MAINTAINERS >> >> +++ b/MAINTAINERS >> >> @@ -13844,6 +13844,13 @@ M: Laxman Dewangan >> >> >> >> S: Supported >> >> F: drivers/input/keyboard/tegra-kbc.c >> >> >> >> +TEGRA NAND DRIVER >> >> +M: Stefan Agner >> >> +M: Lucas Stach >> >> +S: Maintained >> >> +F: Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt >> >> +F: drivers/mtd/nand/raw/tegra_nand.c >> >> + >> >> >> >> TEGRA PWM DRIVER >> >> M: Thierry Reding >> >> S: Supported >> >> >> >> diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig >> >> index 19a2b283fbbe..e9093f52371e 100644 >> >> --- a/drivers/mtd/nand/raw/Kconfig >> >> +++ b/drivers/mtd/nand/raw/Kconfig >> >> @@ -534,4 +534,10 @@ config MTD_NAND_MTK >> >> >> >> Enables support for NAND controller on MTK SoCs. >> >> This controller is found on mt27xx, mt81xx, mt65xx SoCs. >> >> >> >> +config MTD_NAND_TEGRA >> >> + tristate "Support for NAND controller on NVIDIA Tegra" >> >> + depends on ARCH_TEGRA || COMPILE_TEST >> >> + help >> >> + Enables support for NAND flash controller on NVIDIA Tegra SoC. >> >> + >> >> >> >> endif # MTD_NAND >> >> >> >> diff --git a/drivers/mtd/nand/raw/Makefile >> >> b/drivers/mtd/nand/raw/Makefile >> >> index 165b7ef9e9a1..d5a5f9832b88 100644 >> >> --- a/drivers/mtd/nand/raw/Makefile >> >> +++ b/drivers/mtd/nand/raw/Makefile >> >> @@ -56,6 +56,7 @@ obj-$(CONFIG_MTD_NAND_HISI504) += >> >> hisi504_nand.o >> >> >> >> obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmnand/ >> >> obj-$(CONFIG_MTD_NAND_QCOM) += qcom_nandc.o >> >> obj-$(CONFIG_MTD_NAND_MTK) += mtk_ecc.o mtk_nand.o >> >> >> >> +obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o >> >> >> >> nand-objs := nand_base.o nand_bbt.o nand_timings.o nand_ids.o >> >> nand-objs += nand_amd.o >> >> >> >> diff --git a/drivers/mtd/nand/raw/tegra_nand.c >> >> b/drivers/mtd/nand/raw/tegra_nand.c new file mode 100644 >> >> index ..e9664f2938a3 >> >> --- /dev/null >> >> +++ b/drivers/mtd/nand/raw/tegra_nand.c >> >> @@ -0,0 +1,1143 @@ >> >> +// SPDX-License-Identifier: GPL-2.0 >> >> +/* >> >> + * Copyright (C) 2018 Stefan Agner >> >> + * Copyright (C) 2014-2015 Lucas Stach >> >> + * Copyright (C) 2012 Avionic Design GmbH >> >> + */ >> >> + >> >> +#include >> >> +#include >> >> +#include >> >> +#include >> >> +#include >> >> +#include >> >> +#include >> >> +#include >> >> +#include >> >> +#include >> >> +#include >> >> +#include >> >> +#include >> >> +#include >> >> + >> >> +#define CMD 0x00 >> >> +#define CMD_GO BIT(31) >> >> +#define CMD_CLEBIT(30) >> >> +#define CMD_ALEBIT(29) >> >> +#define CMD_PIOBIT(28) >> >> +#define CMD_TX BIT(27) >> >> +#define CMD_RX BIT(26) >> >> +#define CMD_SEC_CMDBIT(25) >> >> +#define CMD_AFT_DATBIT(24) >> >> +#define CMD_TRANS_SIZE(x) (((x - 1) & 0xf) << 20) >> >> +#define CMD_A_VALIDBIT(19) >> >> +#define CMD_B_VALIDBIT(18) >> >> +#define CMD_RD_STATUS_CHK BIT(17) >> >> +#define CMD_RBSY_CHK BIT(16) >> >> +#define CMD_CE(x) BIT((8 + ((x) & 0x7))) >> >> +#define CMD_CLE_SIZE(x)(((x - 1) & 0x3) << 4) >> >> +#define CMD_ALE_SIZE(x)(((x - 1) & 0xf) << 0) >> >> + >> >> +#define STATUS 0x04 >> >> + >> >> +#define ISR 0x08 >> >> +#define ISR_CORRFAIL_ERR BIT(24) >> >> +#define ISR_UNDBIT(7) >> >> +#
Re: [PATCH v3 1/3] nvmem: Update the OF binding to use a subnode for the cells list
On Sun, 10 Jun 2018 11:32:36 +0100
Srinivas Kandagatla wrote:
> On 08/06/18 18:07, Alban wrote:
> > On Fri, 8 Jun 2018 12:34:12 +0100
> > Srinivas Kandagatla wrote:
> >
> ...
> >
> > I looked into this. It would work fine for the cells but not so nicely
> > for the nvmem device API. The phandle for the nvmem device would have
> > to reference the node passed here and not the real device. We would end
> > up with a DT like this:
> >
> > flash@0 {
> > compatible = "mtd";
> > ...
> > nvmem_dev: nvmem-cells {
> > compatible = "nvmem-cells";
> > ...
> > };
> > };
> >
> > other-device@10 {
> > ...
> > nvmem = <&nvmem_dev>;
> > };
> >
> > Now if there is no cell defined we have this empty child node that make
> > very little sense, it is just there to accommodate the nvmem API.
> >
> NO. This just looks fine!
> nvmem-cells is the nvmem provider node without which you would not have
> any provider instance.
> All this looks as expected!
> Am not sure what is the problem here!
The problem is that DT should represent the hardware, not the OS API.
What should be represented is that other drivers can access data stored
on this device. It is my understanding that this wouldn't be an
acceptable binding as the nvmem provider node would only exists because
of how the NVMEM API currently works, a correct binding would just
directly reference the storage device without this extra node.
> > What I would suggest now is to just change the wording. We don't
> > deprecate the current binding, but we extend it to allow grouping the
> > cells in a child node if required. The code to support this is trivial,
> > (4 lines including error handling) so even if we expect very few
> > bindings to make use of it it is not going to be maintenance drag.
> > That would look like this:
>
> >
> > diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.txt
> > b/Documentation/devicetree/bindings/nvmem/nvmem.txt
> > index fd06c09..085d042 100644
> > --- a/Documentation/devicetree/bindings/nvmem/nvmem.txt
> > +++ b/Documentation/devicetree/bindings/nvmem/nvmem.txt
> > @@ -19,7 +19,10 @@ Optional properties:
> >
> > = Data cells =
> > These are the child nodes of the provider which contain data cell
> > -information like offset and size in nvmem provider.
> > +information like offset and size in nvmem provider. Alternatively the data
> > +cells can be grouped in a node that has a compatible property set to
> > +"nvmem-cells".
> > +
> >
> > Required properties:
> > reg: specifies the offset in byte within the storage device.
> > diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> > index 4e94a78..3e1369c 100644
> > --- a/drivers/nvmem/core.c
> > +++ b/drivers/nvmem/core.c
> > @@ -859,6 +859,14 @@ struct nvmem_cell *of_nvmem_cell_get(struct
> > device_node *np,
> > if (!nvmem_np)
> > return ERR_PTR(-EINVAL);
> >
> > + /* bindings that already have anonymous child nodes can instead put
> > +* their cells in a child node with an nvmem-cells compatible. */
> > + if (of_device_is_compatible(nvmem_np, "nvmem-cells")) {
> > + nvmem_np = of_get_next_parent(nvmem_np);
> > + if (!nvmem_np)
> > + return ERR_PTR(-EINVAL);
> > + }
> > +
> > nvmem = __nvmem_device_get(nvmem_np, NULL, NULL);
> > of_node_put(nvmem_np);
> > if (IS_ERR(nvmem))
> >
> > What about it?
> Let me repeat what I have said in my previous emails:
>
> Having a subnode still sounds very fragile to me,
> and this could be much specific case of MTD provider. We might have
> instances where this could be sub-sub node of the the original provider
> for other providers. Also I do not want to bring in Provider specifics
> layout into nvmem bindings.
>
> I can not make myself any clearer than this, Its going to be a NAK from
> my side for the above reasons!
I fully understand you concern but I think they are overblown. First I
highly doubt that more layouts will ever be needed, using a compatible
string pretty much guarantee that we won't clash with another binding.
Furthermore even if you consider this extension "MTD specific" the
amount of code is very small, non intrusive and only run once at
registration time. I would understand if we were talking about pages of
code nesting in various place, but not really when it is a single small
if block with an obvious condition. And finally I don't see that as MTD
specific as any other device could use this feature without any code
change.
> Also, patch I shared should give enough flexibility to various range of
> providers which have different child node layouts without touching the
> nvmem bindings. If it works please use it.
It works from a code POV but it break the basic guidelines of DT
bindings. As I want to have this done, I'm going to do a patch as you
want, but I see a high chance that the binding is going
Re: [PATCH 2/2] IB/mad: Use IDR for agent IDs
On Sun, Jun 10, 2018 at 03:43:05AM -0700, Matthew Wilcox wrote: > On Sun, Jun 10, 2018 at 09:30:28AM +0300, Leon Romanovsky wrote: > > 1. IBTA spec doesn't talk at all about the size of TransactionID, more > > on that in section "13.4.6.4 TRANSACTION ID USAGE", the specification > > says: "The contents of the TransactionID (TID) field are implementation- > > dependent. So let's don't call it mlx4 bug. > > I was loosely paraphrasing the original bug report; suggested rewording > of the comments gratefully accepted. Just replace "mlx4 bug" with something like "to comply with mlx4 implementation". > > > 2. The current implementation means that in mlx5-only network we will > > still have upto (1 << 24) TIDs. I don't know if it is really important, > > but worth to mention. > > Actually, the TIDs will be up to 2^56. We're limited to 2^24 clients, > each of which can send up to 2^32 messages. It sounds like more than enough. Thanks > signature.asc Description: PGP signature
Re: [PATCH v7 1/9] MAINTAINERS: add generic resistive touchscreen adc
On Tue, 22 May 2018 10:52:31 +0300 Eugen Hristev wrote: > Add MAINTAINERS entry for generic resistive touchscreen adc > > Signed-off-by: Eugen Hristev Applied to the togreg branch of iio.git after a rebase brought in the missing fix that was stalling this. Note these are now going to be heading upstream at the next merge window, not the one currently open. Pushed out as testing for the autobuilders to play with it. Thanks, Jonathan > --- > Changes in v3: > - Changed source file name > > MAINTAINERS | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 3bdc260..ce9720f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -5943,6 +5943,12 @@ F: drivers/base/power/domain*.c > F: include/linux/pm_domain.h > F: Documentation/devicetree/bindings/power/power_domain.txt > > +GENERIC RESISTIVE TOUCHSCREEN ADC DRIVER > +M: Eugen Hristev > +L: linux-in...@vger.kernel.org > +S: Maintained > +F: drivers/input/touchscreen/resistive-adc-touch.c > + > GENERIC UIO DRIVER FOR PCI DEVICES > M: "Michael S. Tsirkin" > L: k...@vger.kernel.org
Re: [PATCH v7 2/9] iio: Add channel for Position Relative
On Tue, 22 May 2018 10:52:32 +0300
Eugen Hristev wrote:
> Add new channel type for relative position on a pad.
>
> These type of analog sensor offers the position of a pen
> on a touchpad, and is represented as a voltage, which can be
> converted to a position on X and Y axis on the pad.
> The channel will hand the relative position on the pad in both directions.
>
> The channel can then be consumed by a touchscreen driver or
> read as-is for a raw indication of the touchpen on a touchpad.
>
> Signed-off-by: Eugen Hristev
Applied - with a trivial amount of fuzz.
Thanks,
Jonathan
> ---
> Changes in v2:
> - modified channel name to relative position as suggested.
> - modified kernel version to 4.18 (presumable)
>
> Documentation/ABI/testing/sysfs-bus-iio | 12
> drivers/iio/industrialio-core.c | 1 +
> include/uapi/linux/iio/types.h | 1 +
> tools/iio/iio_event_monitor.c | 2 ++
> 4 files changed, 16 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 6a5f34b..42a9287 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -190,6 +190,18 @@ Description:
> but should match other such assignments on device).
> Units after application of scale and offset are m/s^2.
>
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_positionrelative_x_raw
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_positionrelative_y_raw
> +KernelVersion: 4.18
> +Contact: linux-...@vger.kernel.org
> +Description:
> + Relative position in direction x or y on a pad (may be
> + arbitrarily assigned but should match other such assignments on
> + device).
> + Units after application of scale and offset are milli percents
> + from the pad's size in both directions. Should be calibrated by
> + the consumer.
> +
> What:/sys/bus/iio/devices/iio:deviceX/in_anglvel_x_raw
> What:/sys/bus/iio/devices/iio:deviceX/in_anglvel_y_raw
> What:/sys/bus/iio/devices/iio:deviceX/in_anglvel_z_raw
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 19bdf3d..14bf3d24 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -85,6 +85,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_COUNT] = "count",
> [IIO_INDEX] = "index",
> [IIO_GRAVITY] = "gravity",
> + [IIO_POSITIONRELATIVE] = "positionrelative",
> };
>
> static const char * const iio_modifier_names[] = {
> diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> index 4213cdf..033c7d2 100644
> --- a/include/uapi/linux/iio/types.h
> +++ b/include/uapi/linux/iio/types.h
> @@ -44,6 +44,7 @@ enum iio_chan_type {
> IIO_COUNT,
> IIO_INDEX,
> IIO_GRAVITY,
> + IIO_POSITIONRELATIVE,
> };
>
> enum iio_modifier {
> diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> index b61245e..148f69d 100644
> --- a/tools/iio/iio_event_monitor.c
> +++ b/tools/iio/iio_event_monitor.c
> @@ -58,6 +58,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_PH] = "ph",
> [IIO_UVINDEX] = "uvindex",
> [IIO_GRAVITY] = "gravity",
> + [IIO_POSITIONRELATIVE] = "positionrelative",
> };
>
> static const char * const iio_ev_type_text[] = {
> @@ -151,6 +152,7 @@ static bool event_is_known(struct iio_event_data *event)
> case IIO_PH:
> case IIO_UVINDEX:
> case IIO_GRAVITY:
> + case IIO_POSITIONRELATIVE:
> break;
> default:
> return false;
Re: [PATCH v7 3/9] dt-bindings: input: touchscreen: add minimum pressure touchscreen property
On Tue, 22 May 2018 10:52:33 +0300 Eugen Hristev wrote: > Add a common touchscreen optional property that will specify > the minimum pressure applied to the screen that is needed > such that the driver will report the touch event. > > Signed-off-by: Eugen Hristev > Reviewed-by: Rob Herring Applied, Thanks, Jonathan > --- > Changes in v5: > - Modified property name to touchscreen-min-pressure from > touchscreen-threshold-property > > Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt > b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt > index 537643e..d092d5d 100644 > --- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt > +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt > @@ -7,6 +7,9 @@ Optional properties for Touchscreens: > (in pixels) > - touchscreen-max-pressure : maximum reported pressure (arbitrary range > dependent on the controller) > + - touchscreen-min-pressure : minimum pressure on the touchscreen to be > + achieved in order for the touchscreen > + driver to report a touch event. > - touchscreen-fuzz-x: horizontal noise value of the > absolute input > device (in pixels) > - touchscreen-fuzz-y: vertical noise value of the absolute > input
Re: [PATCH v7 4/9] dt-bindings: input: touchscreen: resistive-adc-touch: create bindings
On Tue, 22 May 2018 10:52:34 +0300
Eugen Hristev wrote:
> Added bindings for generic resistive touchscreen ADC.
>
> Signed-off-by: Eugen Hristev
> Reviewed-by: Rob Herring
Applied, thanks
Jonathan
> ---
> Changes in v5:
> - changed property name touchscreen-threshold-pressure to
> touchscreen-min-pressure
>
> Changes in v3:
> - renamed file and compatible to exclude "generic" keyword
> - removed the pressure threshold property, added it as a common
> touchscreen property in the touchscreen common bindings in a separate
> commit.
>
> Changes in v2:
> - modified bindings to have a generic resistive touchscreen adc driver
> instead of specific architecture one.
>
> .../input/touchscreen/resistive-adc-touch.txt | 30
> ++
> 1 file changed, 30 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.txt
>
> diff --git
> a/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.txt
> b/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.txt
> new file mode 100644
> index 000..51456c0
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.txt
> @@ -0,0 +1,30 @@
> +Generic resistive touchscreen ADC
> +
> +Required properties:
> +
> + - compatible: must be "resistive-adc-touch"
> +The device must be connected to an ADC device that provides channels for
> +position measurement and optional pressure.
> +Refer to ../iio/iio-bindings.txt for details
> + - iio-channels: must have at least two channels connected to an ADC device.
> +These should correspond to the channels exposed by the ADC device and should
> +have the right index as the ADC device registers them. These channels
> +represent the relative position on the "x" and "y" axes.
> + - iio-channel-names: must have all the channels' names. Mandatory channels
> +are "x" and "y".
> +
> +Optional properties:
> + - iio-channels: The third channel named "pressure" is optional and can be
> +used if the ADC device also measures pressure besides position.
> +If this channel is missing, pressure will be ignored and the touchscreen
> +will only report position.
> + - iio-channel-names: optional channel named "pressure".
> +
> +Example:
> +
> + resistive_touch: resistive_touch {
> + compatible = "resistive-adc-touch";
> + touchscreen-min-pressure = <5>;
> + io-channels = <&adc 24>, <&adc 25>, <&adc 26>;
> + io-channel-names = "x", "y", "pressure";
> + };
Re: [PATCH v7 5/9] iio: adc: at91-sama5d2_adc: add support for position and pressure channels
On Tue, 22 May 2018 14:22:44 +0200 Ludovic Desroches wrote: > On Tue, May 22, 2018 at 10:52:35AM +0300, Eugen Hristev wrote: > > This implements the support for position and pressure for the included > > touchscreen support in the SAMA5D2 SOC ADC block. > > Two position channels are added and one for pressure. > > They can be read in raw format, or through a buffer. > > A normal use case is for a consumer driver to register a callback buffer > > for these channels. > > When the touchscreen channels are in the active scan mask, > > the driver will start the touchscreen sampling and push the data to the > > buffer. > > > > Some parts of this patch are based on initial original work by > > Mohamed Jamsheeth Hajanajubudeen and Bandaru Venkateswara Swamy > > > > Signed-off-by: Eugen Hristev > Acked-by: Ludovic Desroches Applied, thanks. Jonathan > > > --- > > Changes in v6: > > - fixed a crash when issuing buffer enable from sysfs, if no trigger was > > previously configured. This is because now the driver can work in software > > buffer mode (to connect the callback buffer). So, when trying to enable the > > buffer, check if we are going indeed to a triggered mode or not. If not, do > > not allow buffer to be started (we do not have the right trigger). > > It's in buffer_postenable and predisable. > > > > Changes in v4: > > - use return value of at91_adc_configure_touch > > - rewrote some part of the read_info_raw according to Jonathan's > > suggestion > > > > Changes in v3: > > - prefix macros with AT91_SAMA5D2 > > - reworked the x_pos and y_pos functions into a single one with two > > additional wrappers > > - reworked pressure report to have it grow naturally and not top down > > - fixed some checks regarding IIO_VOLTAGE as suggested > > - added a comment explaining some code in trigger handling > > - reworked the frequency get handler to use the saved value instead of > > reading it from the hardware. > > - added comment on deffered work queueing > > - pulled out INFO_RAW function into a separate utility function as > > suggested > > - added iio_dev ops structure at all times . The functions are needed in > > case we do not have a hardware trigger attached, but we want to use the > > consumer touchscreen driver, thus a callback buffer is attached. Then we > > still > > need to have buffer preenable and postdisable to configure the touch IRQs > > (etc.) > > > > Changes in v2: > > - the support is now based on callback buffer. > > > > drivers/iio/adc/at91-sama5d2_adc.c | 609 > > + > > 1 file changed, 551 insertions(+), 58 deletions(-) > > > > diff --git a/drivers/iio/adc/at91-sama5d2_adc.c > > b/drivers/iio/adc/at91-sama5d2_adc.c > > index 8729d65..58c4c2b 100644 > > --- a/drivers/iio/adc/at91-sama5d2_adc.c > > +++ b/drivers/iio/adc/at91-sama5d2_adc.c > > @@ -102,14 +102,26 @@ > > #define AT91_SAMA5D2_LCDR 0x20 > > /* Interrupt Enable Register */ > > #define AT91_SAMA5D2_IER 0x24 > > +/* Interrupt Enable Register - TS X measurement ready */ > > +#define AT91_SAMA5D2_IER_XRDY BIT(20) > > +/* Interrupt Enable Register - TS Y measurement ready */ > > +#define AT91_SAMA5D2_IER_YRDY BIT(21) > > +/* Interrupt Enable Register - TS pressure measurement ready */ > > +#define AT91_SAMA5D2_IER_PRDY BIT(22) > > /* Interrupt Enable Register - general overrun error */ > > #define AT91_SAMA5D2_IER_GOVRE BIT(25) > > +/* Interrupt Enable Register - Pen detect */ > > +#define AT91_SAMA5D2_IER_PENBIT(29) > > +/* Interrupt Enable Register - No pen detect */ > > +#define AT91_SAMA5D2_IER_NOPEN BIT(30) > > /* Interrupt Disable Register */ > > #define AT91_SAMA5D2_IDR 0x28 > > /* Interrupt Mask Register */ > > #define AT91_SAMA5D2_IMR 0x2c > > /* Interrupt Status Register */ > > #define AT91_SAMA5D2_ISR 0x30 > > +/* Interrupt Status Register - Pen touching sense status */ > > +#define AT91_SAMA5D2_ISR_PENS BIT(31) > > /* Last Channel Trigger Mode Register */ > > #define AT91_SAMA5D2_LCTMR 0x34 > > /* Last Channel Compare Window Register */ > > @@ -131,8 +143,38 @@ > > #define AT91_SAMA5D2_CDR0 0x50 > > /* Analog Control Register */ > > #define AT91_SAMA5D2_ACR 0x94 > > +/* Analog Control Register - Pen detect sensitivity mask */ > > +#define AT91_SAMA5D2_ACR_PENDETSENS_MASKGENMASK(1, 0) > > + > > /* Touchscreen Mode Register */ > > #define AT91_SAMA5D2_TSMR 0xb0 > > +/* Touchscreen Mode Register - No touch mode */ > > +#define AT91_SAMA5D2_TSMR_TSMODE_NONE 0 > > +/* Touchscreen Mode Register - 4 wire screen, no pressure measurement */ > > +#define AT91_SAMA5D2_TSMR_TSMODE_4WIRE_NO_PRESS 1 > > +/* Touchscreen Mode Register - 4 wire screen, pressure measurement */ > > +#define AT91_SAMA5D2_TSMR_TSMODE_4WIRE_PRESS2 > > +/* Touchscreen Mode Register - 5 wire screen */ > > +#define AT91_SAMA5D2_TSMR_TSMODE_5WIRE 3 > > +/* Touchscreen Mode Register - Average samples mask */ > > +#define AT91
Re: [PATCH v7 6/9] input: touchscreen: resistive-adc-touch: add generic resistive ADC touchscreen
On Tue, 22 May 2018 10:52:36 +0300 Eugen Hristev wrote: > This adds a generic resistive touchscreen (GRTS) driver, which is based > on an IIO device (an ADC). It must be connected to the channels of an ADC > to receive touch data. Then it will feed the data into the input subsystem > where it registers an input device. > It uses an IIO callback buffer to register to the IIO device > > Some parts of this patch are based on initial original work by > Mohamed Jamsheeth Hajanajubudeen and Bandaru Venkateswara Swamy > > Signed-off-by: Eugen Hristev > Acked-by: Dmitry Torokhov Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to play with it. Thanks, Jonathan > --- > Changes in v7: > - cosmetic fixes as suggested by Dmitry: moved min pressure > property lookup below and only if pressure channel is available. > used the error variable in probe at some point, removed it at > different point. > > Changes in v6: > - changed a dev_err to dev_dbg which was forgotten in v5. > > Changes in v5: > - return error on probe if failed add_action_or_reset > - renamed property touchscreen-threshold-pressure to > touchscreen-min-pressure, changed variables accordingly > > Changes in v4: > - added a small description in file header > - changed MAX_POS_MASK to GRTS_MAX_POS_MASK > - initialized press with 0, as this value means no touch. > press has to be initialized because compiler/checkpatch complains > that can be used uninitialized. > - changed of_property_read_u32 to device_* > - set_abs_params for pressure will have range according to threshold > - changed evbit and keybit with set_capability call > - changed variable names to error instead of ret > - checked errors for add_action_or_reset > - cosmetic cleaning > > Changes in v3: > - pressure now reported naturally growing down-up > - using helpers from touchscreen.h to parse DT properties > - added devm_add_action_or_reset to handle callback buffer clean on exit > - changed compatible and threshold property to adapt to changed bindings > > Changes in v2: > - this is now a generic resistive adc touchscreen driver > > drivers/input/touchscreen/Kconfig | 13 ++ > drivers/input/touchscreen/Makefile | 1 + > drivers/input/touchscreen/resistive-adc-touch.c | 204 > > 3 files changed, 218 insertions(+) > create mode 100644 drivers/input/touchscreen/resistive-adc-touch.c > > diff --git a/drivers/input/touchscreen/Kconfig > b/drivers/input/touchscreen/Kconfig > index 4f15496..8f85d3a 100644 > --- a/drivers/input/touchscreen/Kconfig > +++ b/drivers/input/touchscreen/Kconfig > @@ -92,6 +92,19 @@ config TOUCHSCREEN_AD7879_SPI > To compile this driver as a module, choose M here: the > module will be called ad7879-spi. > > +config TOUCHSCREEN_ADC > + tristate "Generic ADC based resistive touchscreen" > + depends on IIO > + select IIO_BUFFER_CB > + help > + Say Y here if you want to use the generic ADC > + resistive touchscreen driver. > + > + If unsure, say N (but it's safe to say "Y"). > + > + To compile this driver as a module, choose M here: the > + module will be called resistive-adc-touch.ko. > + > config TOUCHSCREEN_AR1021_I2C > tristate "Microchip AR1020/1021 i2c touchscreen" > depends on I2C && OF > diff --git a/drivers/input/touchscreen/Makefile > b/drivers/input/touchscreen/Makefile > index dddae79..843c7f9 100644 > --- a/drivers/input/touchscreen/Makefile > +++ b/drivers/input/touchscreen/Makefile > @@ -13,6 +13,7 @@ obj-$(CONFIG_TOUCHSCREEN_AD7877)+= ad7877.o > obj-$(CONFIG_TOUCHSCREEN_AD7879) += ad7879.o > obj-$(CONFIG_TOUCHSCREEN_AD7879_I2C) += ad7879-i2c.o > obj-$(CONFIG_TOUCHSCREEN_AD7879_SPI) += ad7879-spi.o > +obj-$(CONFIG_TOUCHSCREEN_ADC)+= resistive-adc-touch.o > obj-$(CONFIG_TOUCHSCREEN_ADS7846)+= ads7846.o > obj-$(CONFIG_TOUCHSCREEN_AR1021_I2C) += ar1021_i2c.o > obj-$(CONFIG_TOUCHSCREEN_ATMEL_MXT) += atmel_mxt_ts.o > diff --git a/drivers/input/touchscreen/resistive-adc-touch.c > b/drivers/input/touchscreen/resistive-adc-touch.c > new file mode 100644 > index 000..cfc8bb4 > --- /dev/null > +++ b/drivers/input/touchscreen/resistive-adc-touch.c > @@ -0,0 +1,204 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * ADC generic resistive touchscreen (GRTS) > + * This is a generic input driver that connects to an ADC > + * given the channels in device tree, and reports events to the input > + * subsystem. > + * > + * Copyright (C) 2017,2018 Microchip Technology, > + * Author: Eugen Hristev > + * > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define DRIVER_NAME "resistive-adc-touch" > +#define GRTS_DEFAULT_PRESSURE_MIN5 > +#define GRTS_MAX_POS_MASKGENMASK(11, 0) > + > +/** >
Re: [PATCH v7 7/9] dt-bindings: iio: adc: at91-sama5d2_adc: add channel specific consumer info
On Tue, 22 May 2018 14:23:19 +0200
Ludovic Desroches wrote:
> On Tue, May 22, 2018 at 10:52:37AM +0300, Eugen Hristev wrote:
> > Added defines for channel consumer device-tree binding
> >
> > Signed-off-by: Eugen Hristev
> > Reviewed-by: Rob Herring
> Acked-by: Ludovic Desroches
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
>
> > ---
> > .../devicetree/bindings/iio/adc/at91-sama5d2_adc.txt | 9 +
> > include/dt-bindings/iio/adc/at91-sama5d2_adc.h | 16
> >
> > 2 files changed, 25 insertions(+)
> > create mode 100644 include/dt-bindings/iio/adc/at91-sama5d2_adc.h
> >
> > diff --git a/Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt
> > b/Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt
> > index 6469a4c..4a3c1d4 100644
> > --- a/Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt
> > +++ b/Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt
> > @@ -21,6 +21,14 @@ Optional properties:
> >- dmas: Phandle to dma channel for the ADC.
> >- dma-names: Must be "rx" when dmas property is being used.
> >See ../../dma/dma.txt for details.
> > + - #io-channel-cells: in case consumer drivers are attached, this must be
> > 1.
> > + See for details.
> > +
> > +Properties for consumer drivers:
> > + - Consumer drivers can be connected to this producer device, as specified
> > + in
> > + - Channels exposed are specified in:
> > +
> >
> > Example:
> >
> > @@ -38,4 +46,5 @@ adc: adc@fc03 {
> > atmel,trigger-edge-type = ;
> > dmas = <&dma0 (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
> > AT91_XDMAC_DT_PERID(25))>;
> > dma-names = "rx";
> > + #io-channel-cells = <1>;
> > }
> > diff --git a/include/dt-bindings/iio/adc/at91-sama5d2_adc.h
> > b/include/dt-bindings/iio/adc/at91-sama5d2_adc.h
> > new file mode 100644
> > index 000..70f99db
> > --- /dev/null
> > +++ b/include/dt-bindings/iio/adc/at91-sama5d2_adc.h
> > @@ -0,0 +1,16 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * This header provides constants for configuring the AT91 SAMA5D2 ADC
> > + */
> > +
> > +#ifndef _DT_BINDINGS_IIO_ADC_AT91_SAMA5D2_ADC_H
> > +#define _DT_BINDINGS_IIO_ADC_AT91_SAMA5D2_ADC_H
> > +
> > +/* X relative position channel index */
> > +#define AT91_SAMA5D2_ADC_X_CHANNEL 24
> > +/* Y relative position channel index */
> > +#define AT91_SAMA5D2_ADC_Y_CHANNEL 25
> > +/* pressure channel index */
> > +#define AT91_SAMA5D2_ADC_P_CHANNEL 26
> > +
> > +#endif
> > --
> > 2.7.4
> >
Re: [PATCH v7 8/9] ARM: dts: at91: sama5d2: add channel cells for ADC device
On Tue, 22 May 2018 10:52:38 +0300
Eugen Hristev wrote:
> Preparing the ADC device to connect channel consumer drivers
>
> Signed-off-by: Eugen Hristev
The driver for the touchscreen is no in the IIO tree, but it wasn't
early enough (due to a block on a fix working it's way in) for this
merge window. Will be going upstream in the next merge window.
Thanks,
Jonathan
> ---
> arch/arm/boot/dts/sama5d2.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
> index 61f68e5..f06ba99 100644
> --- a/arch/arm/boot/dts/sama5d2.dtsi
> +++ b/arch/arm/boot/dts/sama5d2.dtsi
> @@ -47,6 +47,7 @@
> #include
> #include
> #include
> +#include
>
> / {
> model = "Atmel SAMA5D2 family SoC";
> @@ -1437,6 +1438,7 @@
> atmel,max-sample-rate-hz = <2000>;
> atmel,startup-time-ms = <4>;
> atmel,trigger-edge-type =
> ;
> + #io-channel-cells = <1>;
> status = "disabled";
> };
>
Re: [PATCH v7 9/9] ARM: dts: at91: sama5d2: Add resistive touch device
On Tue, 22 May 2018 10:52:39 +0300
Eugen Hristev wrote:
> Add generic resistive touch device which is connected to ADC block
> inside the SAMA5D2 SoC
>
> Signed-off-by: Eugen Hristev
As with the previous patch, the driver side of things is working it's
way through the IIO tree, but will be the next merge window, not the
current one.
Thanks,
Jonathan
> ---
> Changes in v5:
> - renamed touchscreen-threshold-pressure to touchscreen-min-pressure
>
> arch/arm/boot/dts/sama5d2.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
> index f06ba99..a44f325 100644
> --- a/arch/arm/boot/dts/sama5d2.dtsi
> +++ b/arch/arm/boot/dts/sama5d2.dtsi
> @@ -1442,6 +1442,16 @@
> status = "disabled";
> };
>
> + resistive_touch: resistive-touch {
> + compatible = "resistive-adc-touch";
> + io-channels = <&adc AT91_SAMA5D2_ADC_X_CHANNEL>,
> + <&adc AT91_SAMA5D2_ADC_Y_CHANNEL>,
> + <&adc AT91_SAMA5D2_ADC_P_CHANNEL>;
> + io-channel-names = "x", "y", "pressure";
> + touchscreen-min-pressure = <5>;
> + status = "disabled";
> + };
> +
> pioA: pinctrl@fc038000 {
> compatible = "atmel,sama5d2-pinctrl";
> reg = <0xfc038000 0x600>;
Re: [PATCH] mtd: rawnand: mxc: set spare area size register explicitly
Hi Miquel, Thus wrote Miquel Raynal (miquel.ray...@bootlin.com): > > Usually, this register is updated from settings in the IIM fuses when > > the system is booting from nand flash. For other boot media, however, > s/nand/NAND ok > > + /* spare area size in 16bit words */ > I thought I understood the problem with your commit message but > then I don't get this comment. What's the link between 16-bit buses? Is > this preset valid for both 8 and 16-bit bus width? The register value is unrelated to the bus width. > > + writew(mtd->oobsize >> 1, NFC_V21_RSLTSPARE_AREA); > > + > If this is for dividing per two oobsize value, That's exactly what I wanted to do: mtd->oobsize is in bytes, the register value must be in 16bit words (the specification uses the term half-words, I'll update the comment while at it). > I would really prefer a '/ 2' and let the compiler optimize things. > Unless the spec is explicit about some shifting of course. Ok, I'll use / 2 and resend the patch shortly. Best regards, Martin
Re: [PATCH v3 1/3] nvmem: Update the OF binding to use a subnode for the cells list
On 10/06/18 12:36, Alban wrote:
On Sun, 10 Jun 2018 11:32:36 +0100
Srinivas Kandagatla wrote:
On 08/06/18 18:07, Alban wrote:
On Fri, 8 Jun 2018 12:34:12 +0100
Srinivas Kandagatla wrote:
...
I looked into this. It would work fine for the cells but not so nicely
for the nvmem device API. The phandle for the nvmem device would have
to reference the node passed here and not the real device. We would end
up with a DT like this:
flash@0 {
compatible = "mtd";
...
nvmem_dev: nvmem-cells {
compatible = "nvmem-cells";
...
};
};
other-device@10 {
...
nvmem = <&nvmem_dev>;
};
Now if there is no cell defined we have this empty child node that make
very little sense, it is just there to accommodate the nvmem API.
NO. This just looks fine!
nvmem-cells is the nvmem provider node without which you would not have
any provider instance.
All this looks as expected!
Am not sure what is the problem here!
The problem is that DT should represent the hardware, not the OS API.
Exactly!! flash/mtd has nvmem provider which should be represented in
the DT.
There is no change in DT side from your original patch vs the new
approach. You still are going to have the same subnode.
Isn't it?
AFAIU, the new approach will make it explicit that there is a nvmem
provider in the DT.
...
What should be represented is that other drivers can access data stored
on this device. It is my understanding that this wouldn't be an
acceptable binding as the nvmem provider node would only exists because
of how the NVMEM API currently works, a correct binding would just
directly reference the storage device without this extra node.
...
Having a subnode still sounds very fragile to me,
and this could be much specific case of MTD provider. We might have
instances where this could be sub-sub node of the the original provider
for other providers. Also I do not want to bring in Provider specifics
layout into nvmem bindings.
I can not make myself any clearer than this, Its going to be a NAK from
my side for the above reasons!
I fully understand you concern but I think they are overblown. First I
highly doubt that more layouts will ever be needed, using a compatible
string pretty much guarantee that we won't clash with another binding.
Furthermore even if you consider this extension "MTD specific" the
amount of code is very small, non intrusive and only run once at
registration time. I would understand if we were talking about pages of
code nesting in various place, but not really when it is a single small
if block with an obvious condition. And finally I don't see that as MTD
specific as any other device could use this feature without any code
change.
Also, patch I shared should give enough flexibility to various range of
providers which have different child node layouts without touching the
nvmem bindings. If it works please use it.
It works from a code POV but it break the basic guidelines of DT
bindings. As I want to have this done, I'm going to do a patch as you
want, but I see a high chance that the binding is going to be rejected
by the DT maintainers and we'll be back here again.
If you think the sub node is going to be a problem from MTD point of
view then that is worth discussing.
Adding subnode in nvmem bindings is not going to help or make the
situation any better.
Lets see how this goes!
thanks,
srini
Alban
Re: [PATCH] iio:dac:ad5686: Add AD5311R support
On Mon, 4 Jun 2018 17:22:07 +0300
Stefan Popa wrote:
> AD5311R is a single channel DAC with 10-bit precision and i2c interface.
> The device includes a 2.5V internal reference which is enabled by default.
>
> This device is similar to AD5691R/AD5692R/AD5693/AD5693R, the only
> difference is that it has 10-bit precision.
>
> Datasheet:
> http://www.analog.com/media/en/technical-documentation/data-sheets/AD5310R_5311R.pdf
>
> Signed-off-by: Stefan Popa
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/dac/ad5686.c | 7 +++
> drivers/iio/dac/ad5686.h | 1 +
> drivers/iio/dac/ad5696-i2c.c | 1 +
> 3 files changed, 9 insertions(+)
>
> diff --git a/drivers/iio/dac/ad5686.c b/drivers/iio/dac/ad5686.c
> index e136f0f..2ddbfc3 100644
> --- a/drivers/iio/dac/ad5686.c
> +++ b/drivers/iio/dac/ad5686.c
> @@ -221,6 +221,7 @@ static struct iio_chan_spec name[] = {
> \
> AD5868_CHANNEL(7, 7, bits, _shift), \
> }
>
> +DECLARE_AD5693_CHANNELS(ad5311r_channels, 10, 6);
> DECLARE_AD5676_CHANNELS(ad5672_channels, 12, 4);
> DECLARE_AD5676_CHANNELS(ad5676_channels, 16, 0);
> DECLARE_AD5686_CHANNELS(ad5684_channels, 12, 4);
> @@ -231,6 +232,12 @@ DECLARE_AD5693_CHANNELS(ad5692r_channels, 14, 2);
> DECLARE_AD5693_CHANNELS(ad5691r_channels, 12, 4);
>
> static const struct ad5686_chip_info ad5686_chip_info_tbl[] = {
> + [ID_AD5311R] = {
> + .channels = ad5311r_channels,
> + .int_vref_mv = 2500,
> + .num_channels = 1,
> + .regmap_type = AD5693_REGMAP,
> + },
> [ID_AD5671R] = {
> .channels = ad5672_channels,
> .int_vref_mv = 2500,
> diff --git a/drivers/iio/dac/ad5686.h b/drivers/iio/dac/ad5686.h
> index d05cda9..57b3c61 100644
> --- a/drivers/iio/dac/ad5686.h
> +++ b/drivers/iio/dac/ad5686.h
> @@ -45,6 +45,7 @@
> * ad5686_supported_device_ids:
> */
> enum ad5686_supported_device_ids {
> + ID_AD5311R,
> ID_AD5671R,
> ID_AD5672R,
> ID_AD5675R,
> diff --git a/drivers/iio/dac/ad5696-i2c.c b/drivers/iio/dac/ad5696-i2c.c
> index d18735d..7350d98 100644
> --- a/drivers/iio/dac/ad5696-i2c.c
> +++ b/drivers/iio/dac/ad5696-i2c.c
> @@ -71,6 +71,7 @@ static int ad5686_i2c_remove(struct i2c_client *i2c)
> }
>
> static const struct i2c_device_id ad5686_i2c_id[] = {
> + {"ad5311r", ID_AD5311R},
> {"ad5671r", ID_AD5671R},
> {"ad5675r", ID_AD5675R},
> {"ad5691r", ID_AD5691R},
[PATCH v2] mtd: rawnand: mxc: set spare area size register explicitly
The v21 version of the NAND flash controller contains a Spare Area Size Register (SPAS) at offset 0x10. Its setting defaults to the maximum spare area size of 218 bytes. The size that is set in this register is used by the controller when it calculates the ECC bytes internally in hardware. Usually, this register is updated from settings in the IIM fuses when the system is booting from NAND flash. For other boot media, however, the SPAS register remains at the default setting, which may not work for the particular flash chip on the board. The same goes for flash chips whose configuration cannot be set in the IIM fuses (e.g. chips with 2k sector size and 128 bytes spare area size can't be configured in the IIM fuses on imx25 systems). Set the SPAS register explicitly during the preset operation. Derive the register value from mtd->oobsize that was detected during probe by decoding the flash chip's ID bytes. While at it, rename the define for the spare area register's offset to NFC_V21_RSLTSPARE_AREA. The register at offset 0x10 on v1 controllers is different from the register on v21 controllers. Signed-off-by: Martin Kaiser Reviewed-by: Sascha Hauer Cc: sta...@vger.kernel.org --- changes in v2 - fix the commit message - use '/ 2' instead of shift operator for division BTW is it ok to keep a Reviewed-by tag when updating the patch? drivers/mtd/nand/raw/mxc_nand.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/mxc_nand.c b/drivers/mtd/nand/raw/mxc_nand.c index 45786e7..26cef21 100644 --- a/drivers/mtd/nand/raw/mxc_nand.c +++ b/drivers/mtd/nand/raw/mxc_nand.c @@ -48,7 +48,7 @@ #define NFC_V1_V2_CONFIG (host->regs + 0x0a) #define NFC_V1_V2_ECC_STATUS_RESULT(host->regs + 0x0c) #define NFC_V1_V2_RSLTMAIN_AREA(host->regs + 0x0e) -#define NFC_V1_V2_RSLTSPARE_AREA (host->regs + 0x10) +#define NFC_V21_RSLTSPARE_AREA (host->regs + 0x10) #define NFC_V1_V2_WRPROT (host->regs + 0x12) #define NFC_V1_UNLOCKSTART_BLKADDR (host->regs + 0x14) #define NFC_V1_UNLOCKEND_BLKADDR (host->regs + 0x16) @@ -1274,6 +1274,9 @@ static void preset_v2(struct mtd_info *mtd) writew(config1, NFC_V1_V2_CONFIG1); /* preset operation */ + /* spare area size in 16-bit half-words */ + writew(mtd->oobsize / 2, NFC_V21_RSLTSPARE_AREA); + /* Unlock the internal RAM Buffer */ writew(0x2, NFC_V1_V2_CONFIG); -- 2.1.4
Re: [PATCH 4/9] iio: cros_ec: Switch to SPDX identifier.
On Tue, 5 Jun 2018 11:22:04 +0200 Enric Balletbo i Serra wrote: > Adopt the SPDX license identifier headers to ease license compliance > management. > > Signed-off-by: Enric Balletbo i Serra This code has seen quite a few contributors, I'd like at least some of them to agree they are happy with this change. There hasn't been much general resistance in general to SPDX headers replacing text, but there has been some, so I've been asking this for all the IIO related SPDX patches. Thanks, Jonathan > --- > > drivers/iio/accel/cros_ec_accel_legacy.c | 23 -- > .../common/cros_ec_sensors/cros_ec_sensors.c | 24 ++- > .../cros_ec_sensors/cros_ec_sensors_core.c| 18 -- > .../cros_ec_sensors/cros_ec_sensors_core.h| 12 ++ > drivers/iio/light/cros_ec_light_prox.c| 18 -- > drivers/iio/pressure/cros_ec_baro.c | 18 -- > 6 files changed, 26 insertions(+), 87 deletions(-) > > diff --git a/drivers/iio/accel/cros_ec_accel_legacy.c > b/drivers/iio/accel/cros_ec_accel_legacy.c > index 063e89eff791..e7350ddec328 100644 > --- a/drivers/iio/accel/cros_ec_accel_legacy.c > +++ b/drivers/iio/accel/cros_ec_accel_legacy.c > @@ -1,21 +1,8 @@ > -/* > - * Driver for older Chrome OS EC accelerometer > - * > - * Copyright 2017 Google, Inc > - * > - * This software is licensed under the terms of the GNU General Public > - * License version 2, as published by the Free Software Foundation, and > - * may be copied, distributed, and modified under those terms. > - * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > - * > - * This driver uses the memory mapper cros-ec interface to communicate > - * with the Chrome OS EC about accelerometer data. > - * Accelerometer access is presented through iio sysfs. > - */ > +// SPDX-License-Identifier: GPL-2.0+ > +// Driver for older Chrome OS EC accelerometer > +// > +// Copyright (C) 2017 Google, Inc. > +// Author: Gwendal Grignou > > #include > #include > diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c > b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c > index 705cb3e72663..3dbc90baf6bb 100644 > --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c > +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c > @@ -1,20 +1,10 @@ > -/* > - * cros_ec_sensors - Driver for Chrome OS Embedded Controller sensors. > - * > - * Copyright (C) 2016 Google, Inc > - * > - * This software is licensed under the terms of the GNU General Public > - * License version 2, as published by the Free Software Foundation, and > - * may be copied, distributed, and modified under those terms. > - * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > - * > - * This driver uses the cros-ec interface to communicate with the Chrome OS > - * EC about sensors data. Data access is presented through iio sysfs. > - */ > +// SPDX-License-Identifier: GPL-2.0 > +// Driver for Chrome OS Embedded Controller sensors. > +// > +// Copyright (C) 2016 Google, Inc. > +// > +// This driver uses the cros-ec interface to communicate with the ChromeOS > +// EC about sensors data. Data access is presented through iio sysfs. > > #include > #include > diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c > b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c > index a620eb5ce202..05221994197c 100644 > --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c > +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c > @@ -1,17 +1,7 @@ > -/* > - * cros_ec_sensors_core - Common function for Chrome OS EC sensor driver. > - * > - * Copyright (C) 2016 Google, Inc > - * > - * This software is licensed under the terms of the GNU General Public > - * License version 2, as published by the Free Software Foundation, and > - * may be copied, distributed, and modified under those terms. > - * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > - */ > +// SPDX-License-Identifier: GPL-2.0 > +// Common functions for ChromeOS EC sensor driver. > +// > +// Copyright (C) 2016 Google, Inc. > > #include > #include > diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.h > b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.h > index 2edf68dc7336..a9935489030e 100644 > --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.h > +
Re: [PATCH v2 2/2] dt-bindings: iio: dac: Add docs for AD5758 DAC
On Thu, 7 Jun 2018 16:11:05 +0300
Stefan Popa wrote:
> Signed-off-by: Stefan Popa
Hmm. The first part number I've ever googled where the top hit has
been a flight number.
Rio de Janeiro to Campinas is apparently on time today.
> ---
> Changes in v2:
> - Nothing changed, just to follow the patch set version.
>
> .../devicetree/bindings/iio/dac/ad5758.txt | 84
> ++
> MAINTAINERS| 1 +
> 2 files changed, 85 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/dac/ad5758.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/dac/ad5758.txt
> b/Documentation/devicetree/bindings/iio/dac/ad5758.txt
> new file mode 100644
> index 000..75fff6c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/dac/ad5758.txt
> @@ -0,0 +1,84 @@
> +Analog Devices AD5758 DAC device driver
> +
> +Required properties for the AD5758:
> + - compatible: Must be "adi,ad5758"
> + - reg: SPI chip select number for the device
> + - spi-max-frequency: Max SPI frequency to use (< 5000)
> + - spi-cpha: is the only mode that is supported
> +
> +Optional properties:
> +
> + - adi,dc-dc-mode: Mode of operation of the dc-to-dc converter
> +The following values are currently supported:
> + * 0: DC-to-DC converter powered off
> + * 1: DPC current mode
Perhaps expand those acronyms?
Dynamic Power Control and perhaps a bit of explanation so people
who are ready DT files don't have to go find the data sheet to have
some idea of what these are?
Otherwise, binding is fine.
> + * 2: DPC voltage mode
> + * 3: PPC current mode
> +
> + - adi,dc-dc-ilim: The dc-to-dc converter current limit
> +The following values are currently supported [mA]:
Unit should be in the name.
adi,dc-dc-ilim_ma
> + * 150
> + * 200
> + * 250
> + * 300
> + * 350
> + * 400
> +
> + - adi,slew: Array of slewrate settings should contain 3 fields:
> + 1: Should be either 0 or 1 in order to enable or disable slewrate.
If it is disabled, why not just detect that as the 'not here' version
and then you can drop this element?
> + 2: Slew rate clock:
> + Valid values for the slew rate update frequency [Hz]:
> + * 24
> + * 20
> + * 15
> + * 128000
> + * 64000
> + * 32000
> + * 16000
> + * 8000
> + * 4000
> + * 2000
> + * 1000
> + * 512
> + * 256
> + * 128
> + * 64
> + * 16
> + 3: Slew rate step:
> + Defines by how much the output value changes at each update.
> + Valid values for the step size LSBs:
> + * 4
> + * 12
> + * 64
> + * 120
> + * 256
> + * 500
> + * 1820
> + * 2048
I think these last two are kind of separate parameters, would be interested
to hear if Rob thinks this should be separate or not. They are both
related to slew rate, but different elements that add up to it.
> +
> + - adi,range: The output range
> + The following values are currently supported:
> + * 0: 0 V to 5 V voltage range
> + * 1: 0 V to 10 V voltage range
> + * 2: ±5 V voltage range
> + * 3: ±10 V voltage range
> + * 8: 0 mA to 20 mA current range
> + * 9: 0 mA to 24 mA current range
> + * 10: 4 mA to 20 mA current range
> + * 11: ±20 mA current range
> + * 12: ±24 mA current range
> + * 13: −1 mA to +22 mA current range
Not sure if we can't represent this better. It's either
a current or voltage output device.
adi,voltage_output or something like that or use
adi,voltage_range_v = <0 5>
adi,current_range_ma = <-1 22> etc
with it only being valid to specify one or the other.
I much prefer DT elements that don't require looking
at the docs where possible.
Again, Rob's input on this would be good.
> +
> +AD5758 Example:
> +
> + ad5758@0 {
> + compatible = "adi,ad5758";
> + reg = <0>;
> + spi-max-frequency = <100>;
> + spi-cpha;
> +
> + adi,dc-dc-mode = <2>;
> + adi,dc-dc-ilim = <200>;
> + adi,slew = <1 20 12>;
> + adi,range = <1>;
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1993779..f640146 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -808,6 +808,7 @@ L:linux-...@vger.kernel.org
> W: http://ez.analog.com/community/linux-device-drivers
> S: Supported
> F: drivers/iio/dac/ad5758.c
> +F: Documentation/devicetree/bindings/iio
Re: [PATCH 4.16 00/48] 4.16.15-stable review
On Sun, Jun 10, 2018 at 02:37:39PM +0530, Naresh Kamboju wrote: > On 9 June 2018 at 20:59, Greg Kroah-Hartman > wrote: > > This is the start of the stable review cycle for the 4.16.15 release. > > There are 48 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 Mon Jun 11 14:59:28 UTC 2018. > > 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.16.15-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.16.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > Results from Linaro’s test farm. > No regressions on arm64, arm and x86_64. Wonderful, thanks for testing two of these and letting me know. Are you going to also test the 4.17.1-rc1 tree, or have you not set up a 4.17 test tree yet? thanks, greg k-h
[PATCH 1/1] ARM: dts: s5pv210: Add missing interrupt-controller property to gph2
This commit adds missing interrupt-controller property to gph2 block,
to silence following warnings during build
/soc/pinctrl@e020/gph2: Missing interrupt-controller or interrupt-map
property
Observed on not yet mainlined, an S5PV210 based
Samsung Galaxy S (i9000) phone.
Signed-off-by: Paweł Chmiel
---
arch/arm/boot/dts/s5pv210-pinctrl.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/s5pv210-pinctrl.dtsi
b/arch/arm/boot/dts/s5pv210-pinctrl.dtsi
index 3a79feab11c3..7f0c9d447871 100644
--- a/arch/arm/boot/dts/s5pv210-pinctrl.dtsi
+++ b/arch/arm/boot/dts/s5pv210-pinctrl.dtsi
@@ -258,6 +258,8 @@
gph2: gph2 {
gpio-controller;
#gpio-cells = <2>;
+
+ interrupt-controller;
#interrupt-cells = <2>;
};
--
2.7.4
Re: [PATCH v2 1/2] iio: dac: Add AD5758 support
On Thu, 7 Jun 2018 16:09:40 +0300 Stefan Popa wrote: > The AD5758 is a single channel DAC with 16-bit precision which uses the SPI > interface that operates at clock rates up to 50MHz. > > The output can be configured as voltage or current and is available on a > single terminal. > > Datasheet: > http://www.analog.com/media/en/technical-documentation/data-sheets/ad5758.pdf > > Signed-off-by: Stefan Popa Various things inline, but basically looks fine once we have those bindings sorted out. One that confused me though is that this can be a current output device, but you only provide a voltage channel? Thanks, Jonathan > --- > Changes in v2: > - removed unnecessary parenthesis in AD5758_REG_WRITE macro. > - added missing documentation fields of ad5758_state struct. > - changed the type of pwr_down attribute to bool. > - changed ad5758_dc_dc_ilimt[] to ad5758_dc_dc_ilim[]. > - ad5758_spi_reg_write() now returns spi_write(st->spi, > &st->data[0].d32, sizeof(st->data[0].d32)); > - removed unnecessary new line in ad5758_calib_mem_refresh(). > - changed the type of the mode parameter in > ad5758_set_dc_dc_conv_mode() from unsigned int to enum > ad5758_dc_dc_mode. > - removed unnecessary parenthesis in ad5758_slew_rate_config(). > - changed the type of the enable parameter in > ad5758_fault_prot_switch_en() from unsigned char to bool. > - the same as above, but for ad5758_internal_buffers_en(). > - added a missing mutex_unlock() in ad5758_reg_access(). > - moved the mutex_unlock() in ad5758_read_raw() and removed the > unreachable return. > - returned directly where it was possible in ad5758_write_raw(). > - removed the channel, scan_type and scan_index fields. > - in ad5758_parse_dt(), added missing "\n", and specified what the > default mode actually is. > - returned directly at the end of ad5758_init(). > - in ad5758_probe() used device managed for registering the device > and returned directly without the error message. > > MAINTAINERS | 7 + > drivers/iio/dac/Kconfig | 10 + > drivers/iio/dac/Makefile | 1 + > drivers/iio/dac/ad5758.c | 805 > +++ > 4 files changed, 823 insertions(+) > create mode 100644 drivers/iio/dac/ad5758.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 4b65225..1993779 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -802,6 +802,13 @@ S: Supported > F: drivers/iio/dac/ad5686* > F: drivers/iio/dac/ad5696* > > +ANALOG DEVICES INC AD5758 DRIVER > +M: Stefan Popa > +L: linux-...@vger.kernel.org > +W: http://ez.analog.com/community/linux-device-drivers > +S: Supported > +F: drivers/iio/dac/ad5758.c > + > ANALOG DEVICES INC AD9389B DRIVER > M: Hans Verkuil > L: linux-me...@vger.kernel.org > diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig > index 06e90de..80beb64 100644 > --- a/drivers/iio/dac/Kconfig > +++ b/drivers/iio/dac/Kconfig > @@ -167,6 +167,16 @@ config AD5755 > To compile this driver as a module, choose M here: the > module will be called ad5755. > > +config AD5758 > + tristate "Analog Devices AD5758 DAC driver" > + depends on SPI_MASTER > + help > + Say yes here to build support for Analog Devices AD5758 single channel > + Digital to Analog Converter. > + > + To compile this driver as a module, choose M here: the > + module will be called ad5758. > + > config AD5761 > tristate "Analog Devices AD5761/61R/21/21R DAC driver" > depends on SPI_MASTER > diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile > index 57aa230..e859f2d 100644 > --- a/drivers/iio/dac/Makefile > +++ b/drivers/iio/dac/Makefile > @@ -16,6 +16,7 @@ obj-$(CONFIG_AD5592R_BASE) += ad5592r-base.o > obj-$(CONFIG_AD5592R) += ad5592r.o > obj-$(CONFIG_AD5593R) += ad5593r.o > obj-$(CONFIG_AD5755) += ad5755.o > +obj-$(CONFIG_AD5758) += ad5758.o > obj-$(CONFIG_AD5761) += ad5761.o > obj-$(CONFIG_AD5764) += ad5764.o > obj-$(CONFIG_AD5791) += ad5791.o > diff --git a/drivers/iio/dac/ad5758.c b/drivers/iio/dac/ad5758.c > new file mode 100644 > index 000..3008a3a > --- /dev/null > +++ b/drivers/iio/dac/ad5758.c > @@ -0,0 +1,805 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * AD5758 Digital to analog converters driver > + * > + * Copyright 2018 Analog Devices Inc. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +/* AD5758 registers definition */ > +#define AD5758_NOP 0x00 > +#define AD5758_DAC_INPUT 0x01 > +#define AD5758_DAC_OUTPUT0x02 > +#define AD5758_CLEAR_CODE0x03 > +#define AD5758_USER_GAIN
Re: [PATCH v5 27/31] kcov: test compiler capability in Kconfig and correct dependency
2018-05-28 18:22 GMT+09:00 Masahiro Yamada :
> As Documentation/kbuild/kconfig-language.txt notes, 'select' should be
> be used with care - it forces a lower limit of another symbol, ignoring
> the dependency. Currently, KCOV can select GCC_PLUGINS even if arch
> does not select HAVE_GCC_PLUGINS. This could cause the unmet direct
> dependency.
>
> Now that Kconfig can test compiler capability, let's handle this in a
> more sophisticated way.
>
> There are two ways to enable KCOV; use the compiler that natively
> supports -fsanitize-coverage=trace-pc, or build the SANCOV plugin if
> the compiler has ability to build GCC plugins. Hence, the correct
> dependency for KCOV is:
>
> depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS
>
> You do not need to build the SANCOV plugin if the compiler already
> supports -fsanitize-coverage=trace-pc. Hence, the select should be:
>
> select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC
>
> With this, GCC_PLUGIN_SANCOV is selected only when necessary, so
> scripts/Makefile.gcc-plugins can be cleaner.
>
> I also cleaned up Kconfig and scripts/Makefile.kcov as well.
>
> Signed-off-by: Masahiro Yamada
> Reviewed-by: Kees Cook
> ---
>
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Replace the previous 'select -> imply' patch with
> a new approach
>
> Changes in v2:
> - Drop depends on GCC_VERSION
>
> Makefile | 2 +-
> lib/Kconfig.debug| 11 +++
> scripts/Makefile.gcc-plugins | 6 +-
> scripts/Makefile.kcov| 10 ++
> 4 files changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 80e0800..4b5a17a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -626,7 +626,7 @@ all: vmlinux
> CFLAGS_GCOV:= -fprofile-arcs -ftest-coverage \
> $(call cc-option,-fno-tree-loop-im) \
> $(call cc-disable-warning,maybe-uninitialized,)
> -export CFLAGS_GCOV CFLAGS_KCOV
> +export CFLAGS_GCOV
>
> # The arch Makefile can set ARCH_{CPP,A,C}FLAGS to override the default
> # values of the respective KBUILD_* variables
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index c40c7b7..b76cab2 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -736,12 +736,15 @@ config ARCH_HAS_KCOV
> only for x86_64. KCOV requires testing on other archs, and most
> likely
> disabling of instrumentation for some early boot code.
>
> +config CC_HAS_SANCOV_TRACE_PC
> + def_bool $(cc-option,-fsanitize-coverage=trace-pc)
> +
> config KCOV
> bool "Code coverage for fuzzing"
> depends on ARCH_HAS_KCOV
> + depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS
> select DEBUG_FS
> - select GCC_PLUGINS if !COMPILE_TEST
> - select GCC_PLUGIN_SANCOV if !COMPILE_TEST
> + select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC
> help
> KCOV exposes kernel code coverage information in a form suitable
> for coverage-guided fuzzing (randomized testing).
> @@ -755,7 +758,7 @@ config KCOV
> config KCOV_ENABLE_COMPARISONS
> bool "Enable comparison operands collection by KCOV"
> depends on KCOV
> - default n
> + depends on $(cc-option,-fsanitize-coverage=trace-cmp)
> help
> KCOV also exposes operands of every comparison in the instrumented
> code along with operand sizes and PCs of the comparison
> instructions.
> @@ -765,7 +768,7 @@ config KCOV_ENABLE_COMPARISONS
> config KCOV_INSTRUMENT_ALL
> bool "Instrument all code by default"
> depends on KCOV
> - default y if KCOV
> + default y
> help
> If you are doing generic system call fuzzing (like e.g. syzkaller),
> then you will want to instrument the whole kernel and you should
> diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
> index 7f5c862..0ce3802 100644
> --- a/scripts/Makefile.gcc-plugins
> +++ b/scripts/Makefile.gcc-plugins
> @@ -14,16 +14,12 @@ ifdef CONFIG_GCC_PLUGINS
>endif
>
>ifdef CONFIG_GCC_PLUGIN_SANCOV
> -ifeq ($(strip $(CFLAGS_KCOV)),)
># It is needed because of the gcc-plugin.sh and gcc version checks.
>gcc-plugin-$(CONFIG_GCC_PLUGIN_SANCOV) += sancov_plugin.so
>
> - ifneq ($(PLUGINCC),)
> -CFLAGS_KCOV := $(SANCOV_PLUGIN)
> - else
> + ifeq ($(PLUGINCC),)
> $(warning warning: cannot use CONFIG_KCOV:
> -fsanitize-coverage=trace-pc is not supported by compiler)
>endif
> -endif
>endif
>
>gcc-plugin-$(CONFIG_GCC_PLUGIN_STRUCTLEAK) += structleak_plugin.so
> diff --git a/scripts/Makefile.kcov b/scripts/Makefile.kcov
> index 5cc7203..d71ba73 100644
> --- a/scripts/Makefile.kcov
> +++ b/scripts/Makefile.kcov
> @@ -1,7 +1,9 @@
> ifdef CONFIG_KCOV
> -CFLAGS_KCOV:= $(call cc-option,-fsanitize-coverage=trace-pc,)
> -ifeq ($(CONFIG_KCOV_ENABLE_COMPARISONS),y)
> -CFLAGS_KCOV += $(call cc-option,-fsanitize-cove
Re: INFO: task hung in __sb_start_write
Hello.
Commits
401c636a0eeb0d51 "kernel/hung_task.c: show all hung tasks before panic"
8cc05c71ba5f7936 "locking/lockdep: Move sanity check to inside
lockdep_print_held_locks()"
arrived at linux.git and syzbot started giving us more hints.
Quoting from
https://syzkaller.appspot.com/text?tag=CrashReport&x=1477e81f80 :
2 locks held by rs:main Q:Reg/4416:
#0: dff3f899 (&f->f_pos_lock){+.+.}, at: __fdget_pos+0x1a9/0x1e0
fs/file.c:766
#1: c4a96cb8 (sb_writers#6){}, at: file_start_write
include/linux/fs.h:2737 [inline]
#1: c4a96cb8 (sb_writers#6){}, at: vfs_write+0x452/0x560
fs/read_write.c:548
1 lock held by rsyslogd/4418:
#0: 7f0c215c (&f->f_pos_lock){+.+.}, at: __fdget_pos+0x1a9/0x1e0
fs/file.c:766
syz-executor4 D4 4597 4588 0x
Call Trace:
context_switch kernel/sched/core.c:2856 [inline]
__schedule+0x801/0x1e30 kernel/sched/core.c:3498
schedule+0xef/0x430 kernel/sched/core.c:3542
__rwsem_down_read_failed_common kernel/locking/rwsem-xadd.c:269 [inline]
rwsem_down_read_failed+0x350/0x5e0 kernel/locking/rwsem-xadd.c:286
call_rwsem_down_read_failed+0x18/0x30 arch/x86/lib/rwsem.S:94
__down_read arch/x86/include/asm/rwsem.h:83 [inline]
__percpu_down_read+0x15d/0x200 kernel/locking/percpu-rwsem.c:85
percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:49 [inline]
percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
__sb_start_write+0x2d7/0x300 fs/super.c:1403
sb_start_write include/linux/fs.h:1552 [inline]
mnt_want_write+0x3f/0xc0 fs/namespace.c:386
do_unlinkat+0x2a3/0xa10 fs/namei.c:4026
__do_sys_unlink fs/namei.c:4091 [inline]
__se_sys_unlink fs/namei.c:4089 [inline]
__x64_sys_unlink+0x42/0x50 fs/namei.c:4089
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
1 lock held by syz-executor4/4597:
#0: c4a96cb8 (sb_writers#6){}, at: sb_start_write
include/linux/fs.h:1552 [inline]
#0: c4a96cb8 (sb_writers#6){}, at: mnt_want_write+0x3f/0xc0
fs/namespace.c:386
syz-executor6 D21536 4600 4591 0x
Call Trace:
context_switch kernel/sched/core.c:2856 [inline]
__schedule+0x801/0x1e30 kernel/sched/core.c:3498
schedule+0xef/0x430 kernel/sched/core.c:3542
__rwsem_down_read_failed_common kernel/locking/rwsem-xadd.c:269 [inline]
rwsem_down_read_failed+0x350/0x5e0 kernel/locking/rwsem-xadd.c:286
call_rwsem_down_read_failed+0x18/0x30 arch/x86/lib/rwsem.S:94
__down_read arch/x86/include/asm/rwsem.h:83 [inline]
__percpu_down_read+0x15d/0x200 kernel/locking/percpu-rwsem.c:85
percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:49 [inline]
percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
__sb_start_write+0x2d7/0x300 fs/super.c:1403
sb_start_write include/linux/fs.h:1552 [inline]
mnt_want_write+0x3f/0xc0 fs/namespace.c:386
do_unlinkat+0x2a3/0xa10 fs/namei.c:4026
__do_sys_unlink fs/namei.c:4091 [inline]
__se_sys_unlink fs/namei.c:4089 [inline]
__x64_sys_unlink+0x42/0x50 fs/namei.c:4089
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
1 lock held by syz-executor6/4600:
#0: c4a96cb8 (sb_writers#6){}, at: sb_start_write
include/linux/fs.h:1552 [inline]
#0: c4a96cb8 (sb_writers#6){}, at: mnt_want_write+0x3f/0xc0
fs/namespace.c:386
syz-executor3 D21536 7320 7261 0x
Call Trace:
context_switch kernel/sched/core.c:2856 [inline]
__schedule+0x801/0x1e30 kernel/sched/core.c:3498
schedule+0xef/0x430 kernel/sched/core.c:3542
__rwsem_down_read_failed_common kernel/locking/rwsem-xadd.c:269 [inline]
rwsem_down_read_failed+0x350/0x5e0 kernel/locking/rwsem-xadd.c:286
call_rwsem_down_read_failed+0x18/0x30 arch/x86/lib/rwsem.S:94
__down_read arch/x86/include/asm/rwsem.h:83 [inline]
__percpu_down_read+0x15d/0x200 kernel/locking/percpu-rwsem.c:85
percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:49 [inline]
percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
__sb_start_write+0x2d7/0x300 fs/super.c:1403
sb_start_write include/linux/fs.h:1552 [inline]
mnt_want_write+0x3f/0xc0 fs/namespace.c:386
do_unlinkat+0x2a3/0xa10 fs/namei.c:4026
__do_sys_unlink fs/namei.c:4091 [inline]
__se_sys_unlink fs/namei.c:4089 [inline]
__x64_sys_unlink+0x42/0x50 fs/namei.c:4089
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
1 lock held by syz-executor3/7320:
#0: c4a96cb8 (sb_writers#6){}, at: sb_start_write
include/linux/fs.h:1552 [inline]
#0: c4a96cb8 (sb_writers#6){}, at: mnt_want_write+0x3f/0xc0
fs/namespace.c:386
syz-executor2 D24032 13221 4593 0x0004
Call Trace:
context_switch kernel/sched/core.c:2856 [inline]
__schedule+0x801/0x1e30 kernel/sched/core.c:3498
schedule+0xef/0x430 kernel/sched/core.c:3542
__rwsem_down_read_failed_common kernel/locking/rwsem-xadd.c:269 [inline]
rwsem_down_read_failed+0
Re: [PATCH v3] mm: fix race between kmem_cache destroy, create and deactivate
On Sat, Jun 9, 2018 at 3:20 AM Vladimir Davydov wrote: > > On Tue, May 29, 2018 at 05:12:04PM -0700, Shakeel Butt wrote: > > The memcg kmem cache creation and deactivation (SLUB only) is > > asynchronous. If a root kmem cache is destroyed whose memcg cache is in > > the process of creation or deactivation, the kernel may crash. > > > > Example of one such crash: > > general protection fault: [#1] SMP PTI > > CPU: 1 PID: 1721 Comm: kworker/14:1 Not tainted 4.17.0-smp > > ... > > Workqueue: memcg_kmem_cache kmemcg_deactivate_workfn > > RIP: 0010:has_cpu_slab > > ... > > Call Trace: > > ? on_each_cpu_cond > > __kmem_cache_shrink > > kmemcg_cache_deact_after_rcu > > kmemcg_deactivate_workfn > > process_one_work > > worker_thread > > kthread > > ret_from_fork+0x35/0x40 > > > > To fix this race, on root kmem cache destruction, mark the cache as > > dying and flush the workqueue used for memcg kmem cache creation and > > deactivation. > > > @@ -845,6 +862,8 @@ void kmem_cache_destroy(struct kmem_cache *s) > > if (unlikely(!s)) > > return; > > > > + flush_memcg_workqueue(s); > > + > > This should definitely help against async memcg_kmem_cache_create(), > but I'm afraid it doesn't eliminate the race with async destruction, > unfortunately, because the latter uses call_rcu_sched(): > > memcg_deactivate_kmem_caches >__kmem_cache_deactivate > slab_deactivate_memcg_cache_rcu_sched > call_rcu_sched > kmem_cache_destroy > shutdown_memcg_caches > shutdown_cache > memcg_deactivate_rcufn > > > Can we somehow flush those pending rcu requests? You are right and thanks for catching that. Now I am wondering if synchronize_sched() just before flush_workqueue() should be enough. Otherwise we might have to replace call_sched_rcu with synchronize_sched() in kmemcg_deactivate_workfn which I would not prefer as that would holdup the kmem_cache workqueue. +Paul Paul, we have a situation something similar to the following pseudo code. CPU0: lock(l) if (!flag) call_rcu_sched(callback); unlock(l) -- CPU1: lock(l) flag = true unlock(l) synchronize_sched() -- If CPU0 has called already called call_rchu_sched(callback) then later if CPU1 calls synchronize_sched(). Is there any guarantee that on return from synchronize_sched(), the rcu callback scheduled by CPU0 has already been executed? thanks, Shakeel
[PATCH] parport: sunbpp: fix error return code
Return an error code on failure. Change leading spaces to tab on the
first if.
Problem found using Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/parport/parport_sunbpp.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/parport/parport_sunbpp.c b/drivers/parport/parport_sunbpp.c
index 01cf1c1..8de3295 100644
--- a/drivers/parport/parport_sunbpp.c
+++ b/drivers/parport/parport_sunbpp.c
@@ -286,12 +286,16 @@ static int bpp_probe(struct platform_device *op)
ops = kmemdup(&parport_sunbpp_ops, sizeof(struct parport_operations),
GFP_KERNEL);
-if (!ops)
+ if (!ops) {
+ err = -ENOMEM;
goto out_unmap;
+ }
dprintk(("register_port\n"));
- if (!(p = parport_register_port((unsigned long)base, irq, dma, ops)))
+ if (!(p = parport_register_port((unsigned long)base, irq, dma, ops))) {
+ err = -ENOMEM;
goto out_free_ops;
+ }
p->size = size;
p->dev = &op->dev;
[PATCH] clocksource/drivers/stm32: fix error return code
Return an error code on failure.
Problem found using Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/clocksource/timer-stm32.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clocksource/timer-stm32.c
b/drivers/clocksource/timer-stm32.c
index e5cdc3a..2717f88 100644
--- a/drivers/clocksource/timer-stm32.c
+++ b/drivers/clocksource/timer-stm32.c
@@ -304,8 +304,10 @@ static int __init stm32_timer_init(struct device_node
*node)
to->private_data = kzalloc(sizeof(struct stm32_timer_private),
GFP_KERNEL);
- if (!to->private_data)
+ if (!to->private_data) {
+ ret = -ENOMEM;
goto deinit;
+ }
rstc = of_reset_control_get(node, NULL);
if (!IS_ERR(rstc)) {
Re: [PATCH v3 4/6] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver
On Sunday, 10 June 2018 14:09:24 MSK Stefan Agner wrote: > On 09.06.2018 14:21, Dmitry Osipenko wrote: > > On Saturday, 9 June 2018 00:51:01 MSK Stefan Agner wrote: > >> On 01.06.2018 11:20, Dmitry Osipenko wrote: > >> > On 01.06.2018 01:16, Stefan Agner wrote: > >> >> Add support for the NAND flash controller found on NVIDIA > >> >> Tegra 2 SoCs. This implementation does not make use of the > >> >> command queue feature. Regular operations/data transfers are > >> >> done in PIO mode. Page read/writes with hardware ECC make > >> >> use of the DMA for data transfer. > >> >> > >> >> Signed-off-by: Lucas Stach > >> >> Signed-off-by: Stefan Agner > >> >> --- > >> >> > >> >> MAINTAINERS |7 + > >> >> drivers/mtd/nand/raw/Kconfig |6 + > >> >> drivers/mtd/nand/raw/Makefile |1 + > >> >> drivers/mtd/nand/raw/tegra_nand.c | 1143 > >> >> + > >> >> 4 files changed, 1157 insertions(+) > >> >> create mode 100644 drivers/mtd/nand/raw/tegra_nand.c > >> >> > >> >> diff --git a/MAINTAINERS b/MAINTAINERS > >> >> index 58b9861ccf99..c2e5571c85d4 100644 > >> >> --- a/MAINTAINERS > >> >> +++ b/MAINTAINERS > >> >> @@ -13844,6 +13844,13 @@ M: Laxman Dewangan > >> >> > >> >> S: Supported > >> >> F: drivers/input/keyboard/tegra-kbc.c > >> >> > >> >> +TEGRA NAND DRIVER > >> >> +M: Stefan Agner > >> >> +M: Lucas Stach > >> >> +S: Maintained > >> >> +F: Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt > >> >> +F: drivers/mtd/nand/raw/tegra_nand.c > >> >> + > >> >> > >> >> TEGRA PWM DRIVER > >> >> M: Thierry Reding > >> >> S: Supported > >> >> > >> >> diff --git a/drivers/mtd/nand/raw/Kconfig > >> >> b/drivers/mtd/nand/raw/Kconfig > >> >> index 19a2b283fbbe..e9093f52371e 100644 > >> >> --- a/drivers/mtd/nand/raw/Kconfig > >> >> +++ b/drivers/mtd/nand/raw/Kconfig > >> >> @@ -534,4 +534,10 @@ config MTD_NAND_MTK > >> >> > >> >> Enables support for NAND controller on MTK SoCs. > >> >> This controller is found on mt27xx, mt81xx, mt65xx SoCs. > >> >> > >> >> +config MTD_NAND_TEGRA > >> >> + tristate "Support for NAND controller on NVIDIA Tegra" > >> >> + depends on ARCH_TEGRA || COMPILE_TEST > >> >> + help > >> >> + Enables support for NAND flash controller on NVIDIA Tegra SoC. > >> >> + > >> >> > >> >> endif # MTD_NAND > >> >> > >> >> diff --git a/drivers/mtd/nand/raw/Makefile > >> >> b/drivers/mtd/nand/raw/Makefile > >> >> index 165b7ef9e9a1..d5a5f9832b88 100644 > >> >> --- a/drivers/mtd/nand/raw/Makefile > >> >> +++ b/drivers/mtd/nand/raw/Makefile > >> >> @@ -56,6 +56,7 @@ obj-$(CONFIG_MTD_NAND_HISI504)+= > >> >> hisi504_nand.o > >> >> > >> >> obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmnand/ > >> >> obj-$(CONFIG_MTD_NAND_QCOM)+= qcom_nandc.o > >> >> obj-$(CONFIG_MTD_NAND_MTK) += mtk_ecc.o mtk_nand.o > >> >> > >> >> +obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o > >> >> > >> >> nand-objs := nand_base.o nand_bbt.o nand_timings.o nand_ids.o > >> >> nand-objs += nand_amd.o > >> >> > >> >> diff --git a/drivers/mtd/nand/raw/tegra_nand.c > >> >> b/drivers/mtd/nand/raw/tegra_nand.c new file mode 100644 > >> >> index ..e9664f2938a3 > >> >> --- /dev/null > >> >> +++ b/drivers/mtd/nand/raw/tegra_nand.c > >> >> @@ -0,0 +1,1143 @@ > >> >> +// SPDX-License-Identifier: GPL-2.0 > >> >> +/* > >> >> + * Copyright (C) 2018 Stefan Agner > >> >> + * Copyright (C) 2014-2015 Lucas Stach > >> >> + * Copyright (C) 2012 Avionic Design GmbH > >> >> + */ > >> >> + > >> >> +#include > >> >> +#include > >> >> +#include > >> >> +#include > >> >> +#include > >> >> +#include > >> >> +#include > >> >> +#include > >> >> +#include > >> >> +#include > >> >> +#include > >> >> +#include > >> >> +#include > >> >> +#include > >> >> + > >> >> +#define CMD0x00 > >> >> +#define CMD_GO BIT(31) > >> >> +#define CMD_CLE BIT(30) > >> >> +#define CMD_ALE BIT(29) > >> >> +#define CMD_PIO BIT(28) > >> >> +#define CMD_TX BIT(27) > >> >> +#define CMD_RX BIT(26) > >> >> +#define CMD_SEC_CMD BIT(25) > >> >> +#define CMD_AFT_DAT BIT(24) > >> >> +#define CMD_TRANS_SIZE(x)(((x - 1) & 0xf) << 20) > >> >> +#define CMD_A_VALID BIT(19) > >> >> +#define CMD_B_VALID BIT(18) > >> >> +#define CMD_RD_STATUS_CHKBIT(17) > >> >> +#define CMD_RBSY_CHK BIT(16) > >> >> +#define CMD_CE(x)BIT((8 + ((x) & 0x7))) > >> >> +#define CMD_CLE_SIZE(x) (((x - 1) & 0x3) << 4) > >> >>
Re: [PATCH 4.14 00/41] 4.14.49-stable review
On Sat, Jun 09, 2018 at 05:29:32PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.49 release. > There are 41 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 Mon Jun 11 15:29:07 UTC 2018. > Anything received after that time might be too late. > Build results: total: 148 pass: 148 fail: 0 Qemu test results: total: 146 pass: 146 fail: 0 Details are available at http://kerneltests.org/builders/. Guenter
Re: [PATCH 4.17 00/15] 4.17.1-stable review
On Sat, Jun 09, 2018 at 05:29:35PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.17.1 release. > There are 15 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 Mon Jun 11 14:59:48 UTC 2018. > Anything received after that time might be too late. > Build results: total: 134 pass: 134 fail: 0 Qemu test results: total: 143 pass: 143 fail: 0 Deteails are available at http://kerneltests.org/builders/. Guenter
Re: [PATCH 4.16 00/48] 4.16.15-stable review
On Sat, Jun 09, 2018 at 05:29:12PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.16.15 release. > There are 48 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 Mon Jun 11 14:59:28 UTC 2018. > Anything received after that time might be too late. > Build results: total: 145 pass: 145 fail: 0 Qemu test results: total: 144 pass: 144 fail: 0 Details are available at http://kerneltests.org/builders/. Guenter
Re: [PATCH v3 4/6] mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver
On Sun, 10 Jun 2018 18:00:06 +0300 Dmitry Osipenko wrote: > > >> That seems a lot of work for a code path I do not intend to ever use :-) > > >> > > > > > > Are you sure that resetting HW resets the timing and other registers > > > configuration? Reset implementation is HW-specific, like for example in a > > > case of a video decoder the registers state is re-intialized on HW reset, > > > but registers configuration is untouched in a case of resetting GPU. I'd > > > suggest to check whether NAND controller resetting affects the HW > > > configuration. > > It seems all registers are set back to their documented reset value: > > > > [boot loader/ROM initialized values] > > [1.270253] tegra-nand 70008000.nand: Tegra NAND controller register > > dump > > [1.277051] tegra-nand 70008000.nand: COMMAND: 0x66880104 > > [1.282457] tegra-nand 70008000.nand: STATUS: 0x0101 > > [1.287763] tegra-nand 70008000.nand: ISR: 0x01000120 > > [1.292818] tegra-nand 70008000.nand: IER: 0x > > [1.297863] tegra-nand 70008000.nand: CONFIG: 0x0084 > > [1.303181] tegra-nand 70008000.nand: TIMING: 0x0504 > > [1.308486] tegra-nand 70008000.nand: TIMING2: 0x0003 > > [1.313897] tegra-nand 70008000.nand: CMD_REG1: 0x > > [1.319377] tegra-nand 70008000.nand: CMD_REG2: 0x0030 > > [1.324868] tegra-nand 70008000.nand: ADDR_REG1: 0x0300 > > [1.330435] tegra-nand 70008000.nand: ADDR_REG2: 0x > > [1.336011] tegra-nand 70008000.nand: DMA_MST_CTRL: 0x0414 > > [1.341838] tegra-nand 70008000.nand: DMA_CFG_A: 0x0fff > > [1.347415] tegra-nand 70008000.nand: DMA_CFG_B: 0x001b > > [1.352991] tegra-nand 70008000.nand: FIFO_CTRL: 0xaa00 > > [reset] > > [1.358559] tegra-nand 70008000.nand: Tegra NAND controller register > > dump > > [1.365352] tegra-nand 70008000.nand: COMMAND: 0x0084 > > [1.370744] tegra-nand 70008000.nand: STATUS: 0x0101 > > [1.376060] tegra-nand 70008000.nand: ISR: 0x0100 > > [1.381105] tegra-nand 70008000.nand: IER: 0x > > [1.386161] tegra-nand 70008000.nand: CONFIG: 0x1003 > > [1.391466] tegra-nand 70008000.nand: TIMING: 0x > > [1.396782] tegra-nand 70008000.nand: TIMING2: 0x > > [1.402174] tegra-nand 70008000.nand: CMD_REG1: 0x > > [1.407664] tegra-nand 70008000.nand: CMD_REG2: 0x > > [1.413156] tegra-nand 70008000.nand: ADDR_REG1: 0x > > [1.418722] tegra-nand 70008000.nand: ADDR_REG2: 0x > > [1.424297] tegra-nand 70008000.nand: DMA_MST_CTRL: 0x2400 > > [1.430123] tegra-nand 70008000.nand: DMA_CFG_A: 0x > > [1.435698] tegra-nand 70008000.nand: DMA_CFG_B: 0x > > [1.441264] tegra-nand 70008000.nand: FIFO_CTRL: 0xaa00 > > Alright, then indeed it's not really worth to bother with HW resetting here. > Probably only a kernel module reload or a reboot will help if HW is hung. > Maybe NAND controller / chip recovering is something that NAND core should be > handling in a such case by providing a nand_controller_reset() hook? > I don't see what the core could do to help with that. We'd end up with a new hook implemented by the controller that would be called by the controller driver when it knows it's safe to reset the controller. So, why bother exposing that in the core?
[PATCH] EDAC, altera: Fix an error handling path in 'mv64x60_pci_err_probe()'
IF 'regmap_write()' fails, we should release some resources as done in all
the other error handling paths of the function.
Fixes: e9918d7fafae ("EDAC, altera: Handle SDRAM Uncorrectable Errors on
Stratix10")
Signed-off-by: Christophe JAILLET
---
drivers/edac/altera_edac.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index d0d5c4dbe097..5762c3c383f2 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -730,7 +730,8 @@ static int altr_s10_sdram_probe(struct platform_device
*pdev)
S10_DDR0_IRQ_MASK)) {
edac_printk(KERN_ERR, EDAC_MC,
"Error clearing SDRAM ECC count\n");
- return -ENODEV;
+ ret = -ENODEV;
+ goto err2;
}
if (regmap_update_bits(drvdata->mc_vbase, priv->ecc_irq_en_offset,
--
2.17.0
Re: [PATCH v5 4/4] kernel hacking: new config CC_OPTIMIZE_FOR_DEBUGGING to apply GCC -Og optimization
Hi Changbin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.17 next-20180608]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/changbin-du-intel-com/kernel-hacking-GCC-optimization-for-better-debug-experience-Og/20180606-001415
config: i386-randconfig-x076-06101602 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers//usb/typec/fusb302/fusb302.c: In function
'fusb302_handle_togdone_src':
>> drivers//usb/typec/fusb302/fusb302.c:1413:10: warning: 'ra_comp' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
else if (ra_comp)
^
--
drivers/infiniband/ulp/ipoib/ipoib_main.c: In function 'ipoib_get_netdev':
>> drivers/infiniband/ulp/ipoib/ipoib_main.c:2021:30: warning: 'dev' may be
>> used uninitialized in this function [-Wmaybe-uninitialized]
if (!hca->alloc_rdma_netdev || PTR_ERR(dev) == -EOPNOTSUPP)
--
kernel//cgroup/cgroup-v1.c: In function 'cgroup1_mount':
>> kernel//cgroup/cgroup-v1.c:1268:3: warning: 'root' may be used uninitialized
>> in this function [-Wmaybe-uninitialized]
percpu_ref_reinit(&root->cgrp.self.refcnt);
^~
--
kernel//trace/bpf_trace.c: In function 'bpf_trace_printk':
>> kernel//trace/bpf_trace.c:226:20: warning: 'unsafe_addr' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
(void *) (long) unsafe_addr,
^~
kernel//trace/bpf_trace.c:170:6: note: 'unsafe_addr' was declared here
u64 unsafe_addr;
^~~
--
net//6lowpan/iphc.c: In function 'lowpan_header_decompress':
net//6lowpan/iphc.c:617:12: warning: 'iphc1' may be used uninitialized in
this function [-Wmaybe-uninitialized]
u8 iphc0, iphc1, cid = 0;
^
>> net//6lowpan/iphc.c:617:5: warning: 'iphc0' may be used uninitialized in
>> this function [-Wmaybe-uninitialized]
u8 iphc0, iphc1, cid = 0;
^
--
net//netfilter/nf_tables_api.c: In function 'nf_tables_dump_set':
>> net//netfilter/nf_tables_api.c:3625:2: warning: 'set' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
set->ops->walk(&dump_ctx->ctx, set, &args.iter);
^~~
--
drivers/media/dvb-frontends/mn88472.c: In function 'mn88472_set_frontend':
>> drivers/media/dvb-frontends/mn88472.c:339:27: warning: 'bandwidth_vals_ptr'
>> may be used uninitialized in this function [-Wmaybe-uninitialized]
bandwidth_vals_ptr[i]);
^
>> drivers/media/dvb-frontends/mn88472.c:320:8: warning: 'bandwidth_val' may be
>> used uninitialized in this function [-Wmaybe-uninitialized]
ret = regmap_write(dev->regmap[2], 0x04, bandwidth_val);
^
--
drivers/media/dvb-frontends/mn88473.c: In function 'mn88473_set_frontend':
>> drivers/media/dvb-frontends/mn88473.c:162:7: warning: 'conf_val_ptr' may be
>> used uninitialized in this function [-Wmaybe-uninitialized]
ret = regmap_bulk_write(dev->regmap[1], 0x10, conf_val_ptr, 6);
^~
--
net//netfilter/ipvs/ip_vs_sync.c: In function 'ip_vs_sync_conn':
>> net//netfilter/ipvs/ip_vs_sync.c:731:13: warning: 'm' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
m->nr_conns++;
~~~^~
--
drivers//hwspinlock/hwspinlock_core.c: In function 'of_hwspin_lock_get_id':
>> drivers//hwspinlock/hwspinlock_core.c:339:19: warning: 'id' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
return ret ? ret : id;
~~^~~~
--
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c: In function
'mlxsw_sp_nexthop_group_update':
>> drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3078:7: warning: 'err'
>> may be used uninitialized in this function [-Wmaybe-uninitialized]
if (err)
^
vim +/ra_comp +1413 drivers//usb/typec/fusb302/fusb302.c
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1359
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1360
static int fusb302_handle_togdone_src(struct fusb302_chip *chip,
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1361
u8 togdone_result)
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-27 1362 {
c034a43e drivers/staging/typec/fusb302/fusb302.c Yueyao Zhu 2017-04-
Re: [PATCH] EDAC, altera: Fix an error handling path in 'mv64x60_pci_err_probe()'
Le 10/06/2018 à 17:34, Christophe JAILLET a écrit :
IF 'regmap_write()' fails, we should release some resources as done in all
the other error handling paths of the function.
Fixes: e9918d7fafae ("EDAC, altera: Handle SDRAM Uncorrectable Errors on
Stratix10")
Signed-off-by: Christophe JAILLET
---
drivers/edac/altera_edac.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index d0d5c4dbe097..5762c3c383f2 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -730,7 +730,8 @@ static int altr_s10_sdram_probe(struct platform_device
*pdev)
S10_DDR0_IRQ_MASK)) {
edac_printk(KERN_ERR, EDAC_MC,
"Error clearing SDRAM ECC count\n");
- return -ENODEV;
+ ret = -ENODEV;
+ goto err2;
}
if (regmap_update_bits(drvdata->mc_vbase, priv->ecc_irq_en_offset,
Wrong subjet, will resend a v2 for that.
Re: [PATCH v3] mm: fix race between kmem_cache destroy, create and deactivate
On Sun, Jun 10, 2018 at 07:52:50AM -0700, Shakeel Butt wrote: > On Sat, Jun 9, 2018 at 3:20 AM Vladimir Davydov > wrote: > > > > On Tue, May 29, 2018 at 05:12:04PM -0700, Shakeel Butt wrote: > > > The memcg kmem cache creation and deactivation (SLUB only) is > > > asynchronous. If a root kmem cache is destroyed whose memcg cache is in > > > the process of creation or deactivation, the kernel may crash. > > > > > > Example of one such crash: > > > general protection fault: [#1] SMP PTI > > > CPU: 1 PID: 1721 Comm: kworker/14:1 Not tainted 4.17.0-smp > > > ... > > > Workqueue: memcg_kmem_cache kmemcg_deactivate_workfn > > > RIP: 0010:has_cpu_slab > > > ... > > > Call Trace: > > > ? on_each_cpu_cond > > > __kmem_cache_shrink > > > kmemcg_cache_deact_after_rcu > > > kmemcg_deactivate_workfn > > > process_one_work > > > worker_thread > > > kthread > > > ret_from_fork+0x35/0x40 > > > > > > To fix this race, on root kmem cache destruction, mark the cache as > > > dying and flush the workqueue used for memcg kmem cache creation and > > > deactivation. > > > > > @@ -845,6 +862,8 @@ void kmem_cache_destroy(struct kmem_cache *s) > > > if (unlikely(!s)) > > > return; > > > > > > + flush_memcg_workqueue(s); > > > + > > > > This should definitely help against async memcg_kmem_cache_create(), > > but I'm afraid it doesn't eliminate the race with async destruction, > > unfortunately, because the latter uses call_rcu_sched(): > > > > memcg_deactivate_kmem_caches > >__kmem_cache_deactivate > > slab_deactivate_memcg_cache_rcu_sched > > call_rcu_sched > > kmem_cache_destroy > > shutdown_memcg_caches > > shutdown_cache > > memcg_deactivate_rcufn > > > > > > Can we somehow flush those pending rcu requests? > > You are right and thanks for catching that. Now I am wondering if > synchronize_sched() just before flush_workqueue() should be enough. > Otherwise we might have to replace call_sched_rcu with > synchronize_sched() in kmemcg_deactivate_workfn which I would not > prefer as that would holdup the kmem_cache workqueue. > > +Paul > > Paul, we have a situation something similar to the following pseudo code. > > CPU0: > lock(l) > if (!flag) > call_rcu_sched(callback); > unlock(l) > -- > CPU1: > lock(l) > flag = true > unlock(l) > synchronize_sched() > -- > > If CPU0 has called already called call_rchu_sched(callback) then later > if CPU1 calls synchronize_sched(). Is there any guarantee that on > return from synchronize_sched(), the rcu callback scheduled by CPU0 > has already been executed? No. There is no such guarantee. You instead want rcu_barrier_sched(), which waits for the callbacks from all prior invocations of call_rcu_sched() to be invoked. Please note that synchronize_sched() is -not- sufficient. It is only guaranteed to wait for a grace period, not necessarily for all prior callbacks. This goes both directions because if there are no callbacks in the system, then rcu_barrier_sched() is within its rights to return immediately. So please make sure you use each of synchronize_sched() and rcu_barrier_sched() to do the job that it was intended to do! ;-) If your lock(l) is shorthand for spin_lock(&l), it looks to me like you actually only need rcu_barrier_sched(): CPU0: spin_lock(&l); if (!flag) call_rcu_sched(callback); spin_unlock(&l); CPU1: spin_lock(&l); flag = true; spin_unlock(&l); /* At this point, no more callbacks will be registered. */ rcu_barrier_sched(); /* At this point, all registered callbacks will have been invoked. */ On the other hand, if your "lock(l)" was instead shorthand for rcu_read_lock_sched(), then you need -both- synchronize_sched() -and- rcu_barrier(). And even then, you will be broken in -rt kernels. (Which might or might not be a concern, depending on whether your code matters to -rt kernels. Make sense? Thanx, Paul
Dear Talented
Dear Talented, I am Talent Scout For BLUE SKY FILM STUDIO, Present Blue sky Studio a Film Corporation Located in the United State, is Soliciting for the Right to use Your Photo/Face and Personality as One of the Semi -Major Role/ Character in our Upcoming ANIMATED Stereoscope 3D Movie-The Story of Spies in Disguise (Spies in Disguise 2019) The Movie is Currently Filming (In Production) Please Note That There Will Be No Auditions, Traveling or Any Special / Professional Acting Skills, Since the Production of This Movie Will Be Done with our State of Art Computer -Generating Imagery Equipment. We Are Prepared to Pay the Total Sum of $620,000.00 USD. For More Information/Understanding, Please Write us on the E-Mail Below. CONTACT EMAIL: bluesky.filmstu...@usa.com All Reply to: bluesky.filmstu...@usa.com Note: Only the Response send to this mail will be Given a Prior Consideration. Talent Scout Lisa Clement
Re: [PATCH 4.16 00/48] 4.16.15-stable review
On 10 June 2018 at 19:35, Greg Kroah-Hartman wrote: > On Sun, Jun 10, 2018 at 02:37:39PM +0530, Naresh Kamboju wrote: >> On 9 June 2018 at 20:59, Greg Kroah-Hartman >> wrote: >> > This is the start of the stable review cycle for the 4.16.15 release. >> > There are 48 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 Mon Jun 11 14:59:28 UTC 2018. >> > 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.16.15-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.16.y >> > and the diffstat can be found below. >> > >> > thanks, >> > >> > greg k-h >> >> Results from Linaro’s test farm. >> No regressions on arm64, arm and x86_64. > > Wonderful, thanks for testing two of these and letting me know. > > Are you going to also test the 4.17.1-rc1 tree, or have you not set up a > 4.17 test tree yet? 4.17 test tree setup not yet done. We will do it on Monday and let you know results. - Naresh > > thanks, > > greg k-h
Re: [PATCH v3] mm: fix race between kmem_cache destroy, create and deactivate
On Sun, Jun 10, 2018 at 9:32 AM Paul E. McKenney wrote: > > On Sun, Jun 10, 2018 at 07:52:50AM -0700, Shakeel Butt wrote: > > On Sat, Jun 9, 2018 at 3:20 AM Vladimir Davydov > > wrote: > > > > > > On Tue, May 29, 2018 at 05:12:04PM -0700, Shakeel Butt wrote: > > > > The memcg kmem cache creation and deactivation (SLUB only) is > > > > asynchronous. If a root kmem cache is destroyed whose memcg cache is in > > > > the process of creation or deactivation, the kernel may crash. > > > > > > > > Example of one such crash: > > > > general protection fault: [#1] SMP PTI > > > > CPU: 1 PID: 1721 Comm: kworker/14:1 Not tainted 4.17.0-smp > > > > ... > > > > Workqueue: memcg_kmem_cache kmemcg_deactivate_workfn > > > > RIP: 0010:has_cpu_slab > > > > ... > > > > Call Trace: > > > > ? on_each_cpu_cond > > > > __kmem_cache_shrink > > > > kmemcg_cache_deact_after_rcu > > > > kmemcg_deactivate_workfn > > > > process_one_work > > > > worker_thread > > > > kthread > > > > ret_from_fork+0x35/0x40 > > > > > > > > To fix this race, on root kmem cache destruction, mark the cache as > > > > dying and flush the workqueue used for memcg kmem cache creation and > > > > deactivation. > > > > > > > @@ -845,6 +862,8 @@ void kmem_cache_destroy(struct kmem_cache *s) > > > > if (unlikely(!s)) > > > > return; > > > > > > > > + flush_memcg_workqueue(s); > > > > + > > > > > > This should definitely help against async memcg_kmem_cache_create(), > > > but I'm afraid it doesn't eliminate the race with async destruction, > > > unfortunately, because the latter uses call_rcu_sched(): > > > > > > memcg_deactivate_kmem_caches > > >__kmem_cache_deactivate > > > slab_deactivate_memcg_cache_rcu_sched > > > call_rcu_sched > > > kmem_cache_destroy > > > shutdown_memcg_caches > > > shutdown_cache > > > memcg_deactivate_rcufn > > > > > > > > > Can we somehow flush those pending rcu requests? > > > > You are right and thanks for catching that. Now I am wondering if > > synchronize_sched() just before flush_workqueue() should be enough. > > Otherwise we might have to replace call_sched_rcu with > > synchronize_sched() in kmemcg_deactivate_workfn which I would not > > prefer as that would holdup the kmem_cache workqueue. > > > > +Paul > > > > Paul, we have a situation something similar to the following pseudo code. > > > > CPU0: > > lock(l) > > if (!flag) > > call_rcu_sched(callback); > > unlock(l) > > -- > > CPU1: > > lock(l) > > flag = true > > unlock(l) > > synchronize_sched() > > -- > > > > If CPU0 has called already called call_rchu_sched(callback) then later > > if CPU1 calls synchronize_sched(). Is there any guarantee that on > > return from synchronize_sched(), the rcu callback scheduled by CPU0 > > has already been executed? > > No. There is no such guarantee. > > You instead want rcu_barrier_sched(), which waits for the callbacks from > all prior invocations of call_rcu_sched() to be invoked. > > Please note that synchronize_sched() is -not- sufficient. It is only > guaranteed to wait for a grace period, not necessarily for all prior > callbacks. This goes both directions because if there are no callbacks > in the system, then rcu_barrier_sched() is within its rights to return > immediately. > > So please make sure you use each of synchronize_sched() and > rcu_barrier_sched() to do the job that it was intended to do! ;-) > > If your lock(l) is shorthand for spin_lock(&l), it looks to me like you > actually only need rcu_barrier_sched(): > > CPU0: > spin_lock(&l); > if (!flag) > call_rcu_sched(callback); > spin_unlock(&l); > > CPU1: > spin_lock(&l); > flag = true; > spin_unlock(&l); > /* At this point, no more callbacks will be registered. */ > rcu_barrier_sched(); > /* At this point, all registered callbacks will have been invoked. */ > > On the other hand, if your "lock(l)" was instead shorthand for > rcu_read_lock_sched(), then you need -both- synchronize_sched() -and- > rcu_barrier(). And even then, you will be broken in -rt kernels. > (Which might or might not be a concern, depending on whether your code > matters to -rt kernels. > > Make sense? > Thanks a lot, that was really helpful. The lock is actually mutex_lock. So, I think rcu_barrier_sched() should be sufficient. Shakeel
[PATCH V2] EDAC, altera: Fix an error handling path in 'altr_s10_sdram_probe()'
IF 'regmap_write()' fails, we should release some resources as done in all
the other error handling paths of the function.
Fixes: e9918d7fafae ("EDAC, altera: Handle SDRAM Uncorrectable Errors on
Stratix10")
Signed-off-by: Christophe JAILLET
---
v1 -> v2: Fix subject line
---
drivers/edac/altera_edac.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index d0d5c4dbe097..5762c3c383f2 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -730,7 +730,8 @@ static int altr_s10_sdram_probe(struct platform_device
*pdev)
S10_DDR0_IRQ_MASK)) {
edac_printk(KERN_ERR, EDAC_MC,
"Error clearing SDRAM ECC count\n");
- return -ENODEV;
+ ret = -ENODEV;
+ goto err2;
}
if (regmap_update_bits(drvdata->mc_vbase, priv->ecc_irq_en_offset,
--
2.17.0
Re: Perf record of mem event on kernel data address causing freeze
Sorry for the extreme delay for this reply.
If the expectation was to resolve the issue, the new patch failed to do so.
If this information helps, the system hung when WP tried to monitor an
address(0x88021f51a768) which was originally sampled by PEBS
inside rcu_nmi_exit.
On Fri, May 25, 2018 at 10:49 AM, Frederic Weisbecker
wrote:
> On Thu, May 17, 2018 at 04:38:52PM +0200, Jiri Olsa wrote:
>> On Fri, May 11, 2018 at 02:23:14PM -0400, Probir Roy wrote:
>> > I am using perf-tool to record memory access to some kernel addresses.
>> > For some kernel addresses it freezes/lockup the system.
>> >
>> > I am using kernel version 4.15.0 on x86_64 arch. I am running on an
>> > Intel Broadwell machine.
>> >
>> > I am using Intel's PEBS to sample kernel memory access while running a
>> > micro-benchmark (performs repeated file operation) using following
>> > command.
>> >
>> > $ sudo perf mem -t store record
>> >
>> > This records memory references. After that I run a script to set HW
>> > breakpoint at the reference addresses.
>> >
>> > $ sudo timeout 1s perf record -e mem:<0xaddress>:rw
>> >
>> > It causes system hang at some address (for many address perf reports
>> > correctly). Nothing is written in kern.log
>> >
>> >
>> > I have reported it on bugzilla with detail system information:
>> > https://bugzilla.kernel.org/show_bug.cgi?id=199697
>>
>> I managed to reproduce.. in my case it's caused by having rw
>> breakpoint on data which is touched within do_debug routine,
>> and after few nested do_debug I get double fault
>>
>> for example I can reproduce it immediately when setting breakpoint
>> on rdtp->dynticks_nmi_nesting, which is checked in rcu_nmi_enter
>>
>> I have some ugly patch so far that disables breakpoints during
>> do_debug processing.. it seems to fix it on my server, could you
>> try that?
>>
>> thanks,
>> jirka
>>
>>
>> ---
>> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
>> index 03f3d7695dac..14d41d59abeb 100644
>> --- a/arch/x86/kernel/traps.c
>> +++ b/arch/x86/kernel/traps.c
>> @@ -721,9 +721,12 @@ dotraplinkage void do_debug(struct pt_regs *regs, long
>> error_code)
>> {
>> struct task_struct *tsk = current;
>> int user_icebp = 0;
>> - unsigned long dr6;
>> + unsigned long dr6, dr7;
>> int si_code;
>>
>> + get_debugreg(dr7, 7);
>> + set_debugreg(0, 7);
>> +
>> ist_enter(regs);
>>
>> get_debugreg(dr6, 6);
>> @@ -818,6 +821,7 @@ dotraplinkage void do_debug(struct pt_regs *regs, long
>> error_code)
>>
>> exit:
>> ist_exit(regs);
>> + set_debugreg(dr7, 7);
>> }
>> NOKPROBE_SYMBOL(do_debug);
>
> I'm not sure how much we touch dr7 while in the do_debug() trap, so we may be
> leaking
> some modifications on exit.
>
> I think about a simple do_debug() recursion protection. The problem is where
> we store
> that recursion flag/counter. Ideally I would prefer to have the recursion
> protection
> before ist_enter() which already touches many key memory data (preempt_mask,
> rcu_data).
> But if we set that before ist_enter(), we need the recursion flag to be per
> task because
> preemption is disabled on ist_enter() only, although the comments suggest
> it's unsafe
> to schedule before anyway. So it could be a TIF_FLAG. But better yet, if we
> want to be
> able to set breakpoint on thread flags, we could add a new field in thread
> info.
>
> Anyway here is a very dumb version below. Can you test it Probir, to see if
> that's
> at least the right direction?
>
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index 03f3d76..873383b 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -693,6 +693,8 @@ static bool is_sysenter_singlestep(struct pt_regs *regs)
> #endif
> }
>
> +static DEFINE_PER_CPU(int, do_debug_recursion);
> +
> /*
> * Our handling of the processor debug registers is non-trivial.
> * We do not clear them on entry and exit from the kernel. Therefore
> @@ -725,6 +727,10 @@ dotraplinkage void do_debug(struct pt_regs *regs, long
> error_code)
> int si_code;
>
> ist_enter(regs);
> + if (__this_cpu_read(do_debug_recursion))
> + goto exit;
> +
> + __this_cpu_write(do_debug_recursion, 1);
>
> get_debugreg(dr6, 6);
> /*
> @@ -817,6 +823,7 @@ dotraplinkage void do_debug(struct pt_regs *regs, long
> error_code)
> debug_stack_usage_dec();
>
> exit:
> + __this_cpu_write(do_debug_recursion, 0);
> ist_exit(regs);
> }
> NOKPROBE_SYMBOL(do_debug);
--
Probir Roy
PhD Student
College of William and Mary
Phone: 7577531428
Re: [PATCH 3.16 183/410] mm: pin address_space before dereferencing it while isolating an LRU page
On Thu, 7 Jun 2018, Ben Hutchings wrote:
> 3.16.57-rc1 review patch. If anyone has any objections, please let me know.
Not an objection as such, but if you're including this one,
please be sure to add 145e1a71e090575c74969e3daa8136d1e5b99fc8
"mm: fix the NULL mapping case in __isolate_lru_page()"
Thanks,
Hugh
>
> --
>
> From: Mel Gorman
>
> commit 69d763fc6d3aee787a3e8c8c35092b4f4960fa5d upstream.
>
> Minchan Kim asked the following question -- what locks protects
> address_space destroying when race happens between inode trauncation and
> __isolate_lru_page? Jan Kara clarified by describing the race as follows
>
> CPU1CPU2
>
> truncate(inode) __isolate_lru_page()
> ...
> truncate_inode_page(mapping, page);
> delete_from_page_cache(page)
> spin_lock_irqsave(&mapping->tree_lock, flags);
> __delete_from_page_cache(page, NULL)
> page_cache_tree_delete(..)
> ... mapping =
> page_mapping(page);
> page->mapping = NULL;
> ...
> spin_unlock_irqrestore(&mapping->tree_lock, flags);
> page_cache_free_page(mapping, page)
> put_page(page)
> if (put_page_testzero(page)) -> false
> - inode now has no pages and can be freed including embedded address_space
>
> if (mapping &&
> !mapping->a_ops->migratepage)
> - we've dereferenced mapping which is potentially already free.
>
> The race is theoretically possible but unlikely. Before the
> delete_from_page_cache, truncate_cleanup_page is called so the page is
> likely to be !PageDirty or PageWriteback which gets skipped by the only
> caller that checks the mappping in __isolate_lru_page. Even if the race
> occurs, a substantial amount of work has to happen during a tiny window
> with no preemption but it could potentially be done using a virtual
> machine to artifically slow one CPU or halt it during the critical
> window.
>
> This patch should eliminate the race with truncation by try-locking the
> page before derefencing mapping and aborting if the lock was not
> acquired. There was a suggestion from Huang Ying to use RCU as a
> side-effect to prevent mapping being freed. However, I do not like the
> solution as it's an unconventional means of preserving a mapping and
> it's not a context where rcu_read_lock is obviously protecting rcu data.
>
> Link:
> http://lkml.kernel.org/r/20180104102512.2qos3h5vqzeis...@techsingularity.net
> Fixes: c82449352854 ("mm: compaction: make isolate_lru_page() filter-aware
> again")
> Signed-off-by: Mel Gorman
> Acked-by: Minchan Kim
> Cc: "Huang, Ying"
> Cc: Jan Kara
> Signed-off-by: Andrew Morton
> Signed-off-by: Linus Torvalds
> [bwh: Backported to 3.16: adjust context]
> Signed-off-by: Ben Hutchings
> ---
> mm/vmscan.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1206,6 +1206,7 @@ int __isolate_lru_page(struct page *page
>
> if (PageDirty(page)) {
> struct address_space *mapping;
> + bool migrate_dirty;
>
> /* ISOLATE_CLEAN means only clean pages */
> if (mode & ISOLATE_CLEAN)
> @@ -1214,10 +1215,19 @@ int __isolate_lru_page(struct page *page
> /*
>* Only pages without mappings or that have a
>* ->migratepage callback are possible to migrate
> - * without blocking
> + * without blocking. However, we can be racing with
> + * truncation so it's necessary to lock the page
> + * to stabilise the mapping as truncation holds
> + * the page lock until after the page is removed
> + * from the page cache.
>*/
> + if (!trylock_page(page))
> + return ret;
> +
> mapping = page_mapping(page);
> - if (mapping && !mapping->a_ops->migratepage)
> + migrate_dirty = mapping && mapping->a_ops->migratepage;
> + unlock_page(page);
> + if (!migrate_dirty)
> return ret;
> }
> }
>
>
Re: [PATCH 4.17 00/15] 4.17.1-stable review
On Sun, Jun 10, 2018 at 08:14:44AM -0700, Guenter Roeck wrote: > On Sat, Jun 09, 2018 at 05:29:35PM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.17.1 release. > > There are 15 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 Mon Jun 11 14:59:48 UTC 2018. > > Anything received after that time might be too late. > > > Build results: > total: 134 pass: 134 fail: 0 > Qemu test results: > total: 143 pass: 143 fail: 0 > > Deteails are available at http://kerneltests.org/builders/. Wonderful, thanks for testing all of these and letting me know. greg k-h
Re: [PATCH 2/2] IB/mad: Use IDR for agent IDs
On Sun, Jun 10, 2018 at 03:25:05PM +0300, Leon Romanovsky wrote: > On Sun, Jun 10, 2018 at 03:43:05AM -0700, Matthew Wilcox wrote: > > On Sun, Jun 10, 2018 at 09:30:28AM +0300, Leon Romanovsky wrote: > > > 1. IBTA spec doesn't talk at all about the size of TransactionID, more > > > on that in section "13.4.6.4 TRANSACTION ID USAGE", the specification > > > says: "The contents of the TransactionID (TID) field are implementation- > > > dependent. So let's don't call it mlx4 bug. > > > > I was loosely paraphrasing the original bug report; suggested rewording > > of the comments gratefully accepted. > > Just replace "mlx4 bug" with something like "to comply with mlx4 > implementation". Well, it is a bug. Blindly replacing the upper 8 bits of the TID in a driver without accommodation from the core is totally, bonkers wrong. The original concept was that the 1<<24 limit would come from the driver and only mlx4 would have less than 1<<32, because only mlx4 does this thing.. Thanks Matt, Jason
[GIT PULL] UBI/UBIFS updates for 4.18-rc1
Linus, The following changes since commit 29dcea88779c856c7dc92040a0c01233263101d4: Linux 4.17 (2018-06-03 14:15:21 -0700) are available in the git repository at: git://git.infradead.org/linux-ubifs.git tags/upstream-4.18-rc1 for you to fetch changes up to f5a926dd529870de4bd19199ce7b36985f130d70: mtd: ubi: Update ubi-media.h to dual license (2018-06-07 15:53:17 +0200) This pull request contains updates for both UBI and UBIFS: - The UBI on-disk format header file is now dual licensed - New way to detect Fastmap problems during runtime - Bugfix for Fastmap - Minor updates for UBIFS (spelling, comments, vm_fault_t, ...) Lionel Debieve (1): mtd: ubi: Update ubi-media.h to dual license Richard Weinberger (4): ubi: fastmap: Cancel work upon detach ubi: fastmap: Correctly handle interrupted erasures in EBA ubi: fastmap: Check each mapping only once ubi: fastmap: Detect EBA mismatches on-the-fly Sascha Hauer (6): ubifs: remove set but never used variable ubifs: journal: Remove wrong comment ubifs: Spelling fix someting -> something ubifs: log: Some spelling fixes ubifs: gc: Fix typo ubifs: lpt: Fix wrong pnode number range in comment Souptick Joarder (1): fs: ubifs: Adding new return type vm_fault_t Wang Shilong (1): ubifs, xattr: remove misguided quota flags drivers/mtd/ubi/build.c | 4 ++ drivers/mtd/ubi/eba.c | 111 +++- drivers/mtd/ubi/fastmap.c | 20 drivers/mtd/ubi/ubi-media.h | 22 ++--- drivers/mtd/ubi/ubi.h | 11 + drivers/mtd/ubi/vmt.c | 1 + drivers/mtd/ubi/vtbl.c | 16 ++- drivers/mtd/ubi/wl.c| 4 +- fs/ubifs/file.c | 11 ++--- fs/ubifs/gc.c | 2 +- fs/ubifs/journal.c | 5 +- fs/ubifs/log.c | 6 +-- fs/ubifs/lpt_commit.c | 2 +- fs/ubifs/replay.c | 5 +- fs/ubifs/ubifs.h| 2 - fs/ubifs/xattr.c| 2 +- 16 files changed, 178 insertions(+), 46 deletions(-)
[PATCH v3 9/9] x86: jump-labels: use macros instead of inline assembly
Use assembly macros for jump-labels and call them from inline assembly.
This not only makes the code more readable, but also improves
compilation decision, specifically inline decisions which GCC base on
the number of new lines in inline assembly.
As a result the code size is slightly increased.
textdata bss dec hex filename
18163528 10226300 2957312 31347140 1de51c4 ./vmlinux before
18163608 10227348 2957312 31348268 1de562c ./vmlinux after (+1128)
And functions such as intel_pstate_adjust_policy_max(),
kvm_cpu_accept_dm_intr(), kvm_register_read() are inlined.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Greg Kroah-Hartman
Cc: Kate Stewart
Cc: Philippe Ombredanne
Signed-off-by: Nadav Amit
---
arch/x86/include/asm/jump_label.h | 65 ++-
arch/x86/kernel/macros.S | 1 +
2 files changed, 39 insertions(+), 27 deletions(-)
diff --git a/arch/x86/include/asm/jump_label.h
b/arch/x86/include/asm/jump_label.h
index 8c0de4282659..ea0633a41122 100644
--- a/arch/x86/include/asm/jump_label.h
+++ b/arch/x86/include/asm/jump_label.h
@@ -2,19 +2,6 @@
#ifndef _ASM_X86_JUMP_LABEL_H
#define _ASM_X86_JUMP_LABEL_H
-#ifndef HAVE_JUMP_LABEL
-/*
- * For better or for worse, if jump labels (the gcc extension) are missing,
- * then the entire static branch patching infrastructure is compiled out.
- * If that happens, the code in here will malfunction. Raise a compiler
- * error instead.
- *
- * In theory, jump labels and the static branch patching infrastructure
- * could be decoupled to fix this.
- */
-#error asm/jump_label.h included on a non-jump-label kernel
-#endif
-
#define JUMP_LABEL_NOP_SIZE 5
#ifdef CONFIG_X86_64
@@ -28,18 +15,27 @@
#ifndef __ASSEMBLY__
+#ifndef HAVE_JUMP_LABEL
+/*
+ * For better or for worse, if jump labels (the gcc extension) are missing,
+ * then the entire static branch patching infrastructure is compiled out.
+ * If that happens, the code in here will malfunction. Raise a compiler
+ * error instead.
+ *
+ * In theory, jump labels and the static branch patching infrastructure
+ * could be decoupled to fix this.
+ */
+#error asm/jump_label.h included on a non-jump-label kernel
+#endif
+
#include
#include
static __always_inline bool arch_static_branch(struct static_key *key, bool
branch)
{
- asm_volatile_goto("1:"
- ".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t"
- ".pushsection __jump_table, \"aw\" \n\t"
- _ASM_ALIGN "\n\t"
- _ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t"
- ".popsection \n\t"
- : : "i" (key), "i" (branch) : : l_yes);
+ asm_volatile_goto("STATIC_BRANCH_GOTO l_yes=\"%l[l_yes]\" key=\"%c0\" "
+ "branch=\"%c1\""
+ : : "i" (key), "i" (branch) : : l_yes);
return false;
l_yes:
@@ -48,13 +44,8 @@ static __always_inline bool arch_static_branch(struct
static_key *key, bool bran
static __always_inline bool arch_static_branch_jump(struct static_key *key,
bool branch)
{
- asm_volatile_goto("1:"
- ".byte 0xe9\n\t .long %l[l_yes] - 2f\n\t"
- "2:\n\t"
- ".pushsection __jump_table, \"aw\" \n\t"
- _ASM_ALIGN "\n\t"
- _ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t"
- ".popsection \n\t"
+ asm_volatile_goto("STATIC_BRANCH_JUMP_GOTO l_yes=\"%l[l_yes]\"
key=\"%c0\" "
+ "branch=\"%c1\""
: : "i" (key), "i" (branch) : : l_yes);
return false;
@@ -108,6 +99,26 @@ struct jump_entry {
.popsection
.endm
+.macro STATIC_BRANCH_GOTO l_yes:req key:req branch:req
+1:
+ .byte STATIC_KEY_INIT_NOP
+ .pushsection __jump_table, "aw"
+ _ASM_ALIGN
+ _ASM_PTR 1b, \l_yes, \key + \branch
+ .popsection
+.endm
+
+.macro STATIC_BRANCH_JUMP_GOTO l_yes:req key:req branch:req
+1:
+ .byte 0xe9
+ .long \l_yes - 2f
+2:
+ .pushsection __jump_table, "aw"
+ _ASM_ALIGN
+ _ASM_PTR 1b, \l_yes, \key + \branch
+ .popsection
+.endm
+
#endif /* __ASSEMBLY__ */
#endif
diff --git a/arch/x86/kernel/macros.S b/arch/x86/kernel/macros.S
index bf8b9c93e255..161c95059044 100644
--- a/arch/x86/kernel/macros.S
+++ b/arch/x86/kernel/macros.S
@@ -13,3 +13,4 @@
#include
#include
#include
+#include
--
2.17.0
[PATCH v3 7/9] x86: extable: use macros instead of inline assembly
Use assembly macros for exception-tables and call them from inline
assembly. This not only makes the code more readable and allows to
avoid the duplicate implementation, but also improves compilation
decision, specifically inline decisions which GCC base on the number of
new lines in inline assembly.
textdata bss dec hex filename
18162555 10226288 2957312 31346155 1de4deb ./vmlinux before
18162879 10226256 2957312 31346447 1de4f0f ./vmlinux after (+292)
This allows to inline functions such as nested_vmx_exit_reflected(),
set_segment_reg(), __copy_xstate_to_user().
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Josh Poimboeuf
Signed-off-by: Nadav Amit
---
arch/x86/include/asm/asm.h | 61 +-
arch/x86/kernel/macros.S | 1 +
2 files changed, 28 insertions(+), 34 deletions(-)
diff --git a/arch/x86/include/asm/asm.h b/arch/x86/include/asm/asm.h
index 219faaec51df..30bc1b0058ef 100644
--- a/arch/x86/include/asm/asm.h
+++ b/arch/x86/include/asm/asm.h
@@ -58,28 +58,44 @@
# define CC_OUT(c) [_cc_ ## c] "=qm"
#endif
-/* Exception table entry */
#ifdef __ASSEMBLY__
# define _ASM_EXTABLE_HANDLE(from, to, handler)\
- .pushsection "__ex_table","a" ; \
- .balign 4 ; \
- .long (from) - . ; \
- .long (to) - . ;\
- .long (handler) - . ; \
- .popsection
+ ASM_EXTABLE_HANDLE from to handler
+
+#else /* __ASSEMBLY__ */
+
+# define _ASM_EXTABLE_HANDLE(from, to, handler)\
+ "ASM_EXTABLE_HANDLE from=" #from " to=" #to \
+ " handler=\"" #handler "\"\n\t"
+
+/* For C file, we already have NOKPROBE_SYMBOL macro */
+
+#endif /* __ASSEMBLY__ */
-# define _ASM_EXTABLE(from, to)\
+#define _ASM_EXTABLE(from, to) \
_ASM_EXTABLE_HANDLE(from, to, ex_handler_default)
-# define _ASM_EXTABLE_FAULT(from, to) \
+#define _ASM_EXTABLE_FAULT(from, to) \
_ASM_EXTABLE_HANDLE(from, to, ex_handler_fault)
-# define _ASM_EXTABLE_EX(from, to) \
+#define _ASM_EXTABLE_EX(from, to) \
_ASM_EXTABLE_HANDLE(from, to, ex_handler_ext)
-# define _ASM_EXTABLE_REFCOUNT(from, to) \
+#define _ASM_EXTABLE_REFCOUNT(from, to)\
_ASM_EXTABLE_HANDLE(from, to, ex_handler_refcount)
+/* Exception table entry */
+#ifdef __ASSEMBLY__
+
+.macro ASM_EXTABLE_HANDLE from:req to:req handler:req
+ .pushsection "__ex_table","a"
+ .balign 4
+ .long (\from) - .
+ .long (\to) - .
+ .long (\handler) - .
+ .popsection
+.endm
+
# define _ASM_NOKPROBE(entry) \
.pushsection "_kprobe_blacklist","aw" ; \
_ASM_ALIGN ;\
@@ -110,29 +126,6 @@
_ASM_EXTABLE(101b,103b)
.endm
-#else
-# define _EXPAND_EXTABLE_HANDLE(x) #x
-# define _ASM_EXTABLE_HANDLE(from, to, handler)\
- " .pushsection \"__ex_table\",\"a\"\n" \
- " .balign 4\n" \
- " .long (" #from ") - .\n" \
- " .long (" #to ") - .\n"\
- " .long (" _EXPAND_EXTABLE_HANDLE(handler) ") - .\n"\
- " .popsection\n"
-
-# define _ASM_EXTABLE(from, to)\
- _ASM_EXTABLE_HANDLE(from, to, ex_handler_default)
-
-# define _ASM_EXTABLE_FAULT(from, to) \
- _ASM_EXTABLE_HANDLE(from, to, ex_handler_fault)
-
-# define _ASM_EXTABLE_EX(from, to) \
- _ASM_EXTABLE_HANDLE(from, to, ex_handler_ext)
-
-# define _ASM_EXTABLE_REFCOUNT(from, to) \
- _ASM_EXTABLE_HANDLE(from, to, ex_handler_refcount)
-
-/* For C file, we already have NOKPROBE_SYMBOL macro */
#endif
#ifndef __ASSEMBLY__
diff --git a/arch/x86/kernel/macros.S b/arch/x86/kernel/macros.S
index 71d8b716b111..7baa40d5bf16 100644
--- a/arch/x86/kernel/macros.S
+++ b/arch/x86/kernel/macros.S
@@ -11,3 +11,4 @@
#include
#include
#include
+#include
--
2.17.0
[PATCH v3 8/9] x86: cpufeature: use macros instead of inline assembly
Use assembly macros for static_cpu_has() and call them from inline
assembly. This not only makes the code more readable, but also improves
compilation decision, specifically inline decisions which GCC base on
the number of new lines in inline assembly.
The patch slightly increases the kernel size:
textdata bss dec hex filename
18162879 10226256 2957312 31346447 1de4f0f ./vmlinux before
18163528 10226300 2957312 31347140 1de51c4 ./vmlinux after (+693)
And enables the inlining of function such as free_ldt_pgtables().
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Peter Zijlstra
Signed-off-by: Nadav Amit
---
arch/x86/include/asm/cpufeature.h | 82 ++-
arch/x86/kernel/macros.S | 1 +
2 files changed, 48 insertions(+), 35 deletions(-)
diff --git a/arch/x86/include/asm/cpufeature.h
b/arch/x86/include/asm/cpufeature.h
index aced6c9290d6..7d442722ef24 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -2,10 +2,10 @@
#ifndef _ASM_X86_CPUFEATURE_H
#define _ASM_X86_CPUFEATURE_H
-#include
-
-#if defined(__KERNEL__) && !defined(__ASSEMBLY__)
+#ifdef __KERNEL__
+#ifndef __ASSEMBLY__
+#include
#include
#include
@@ -161,37 +161,10 @@ extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned
int bit);
*/
static __always_inline __pure bool _static_cpu_has(u16 bit)
{
- asm_volatile_goto("1: jmp 6f\n"
-"2:\n"
-".skip -(((5f-4f) - (2b-1b)) > 0) * "
-"((5f-4f) - (2b-1b)),0x90\n"
-"3:\n"
-".section .altinstructions,\"a\"\n"
-" .long 1b - .\n" /* src offset */
-" .long 4f - .\n" /* repl offset */
-" .word %P[always]\n" /* always replace */
-" .byte 3b - 1b\n" /* src len */
-" .byte 5f - 4f\n" /* repl len */
-" .byte 3b - 2b\n" /* pad len */
-".previous\n"
-".section .altinstr_replacement,\"ax\"\n"
-"4: jmp %l[t_no]\n"
-"5:\n"
-".previous\n"
-".section .altinstructions,\"a\"\n"
-" .long 1b - .\n" /* src offset */
-" .long 0\n" /* no replacement */
-" .word %P[feature]\n" /* feature bit */
-" .byte 3b - 1b\n" /* src len */
-" .byte 0\n" /* repl len */
-" .byte 0\n" /* pad len */
-".previous\n"
-".section .altinstr_aux,\"ax\"\n"
-"6:\n"
-" testb %[bitnum],%[cap_byte]\n"
-" jnz %l[t_yes]\n"
-" jmp %l[t_no]\n"
-".previous\n"
+ asm_volatile_goto("STATIC_CPU_HAS bitnum=%[bitnum] "
+ "cap_byte=\"%[cap_byte]\" "
+ "feature=%P[feature] t_yes=%l[t_yes] "
+ "t_no=%l[t_no] always=%P[always]"
: : [feature] "i" (bit),
[always] "i" (X86_FEATURE_ALWAYS),
[bitnum] "i" (1 << (bit & 7)),
@@ -226,5 +199,44 @@ static __always_inline __pure bool _static_cpu_has(u16 bit)
#define CPU_FEATURE_TYPEVALboot_cpu_data.x86_vendor,
boot_cpu_data.x86, \
boot_cpu_data.x86_model
-#endif /* defined(__KERNEL__) && !defined(__ASSEMBLY__) */
+#else /* __ASSEMBLY__ */
+
+.macro STATIC_CPU_HAS bitnum:req cap_byte:req feature:req t_yes:req t_no:req
always:req
+1:
+ jmp 6f
+2:
+ .skip -(((5f-4f) - (2b-1b)) > 0) * ((5f-4f) - (2b-1b)),0x90
+3:
+ .section .altinstructions,"a"
+ .long 1b - ./* src offset */
+ .long 4f - ./* repl offset */
+ .word \always /* always replace */
+ .byte 3b - 1b /* src len */
+ .byte 5f - 4f /* repl len */
+ .byte 3b - 2b /* pad len */
+ .previous
+ .section .altinstr_replacement,"ax"
+4:
+ jmp \t_no
+5:
+ .previous
+ .section .altinstructions,"a"
+ .long 1b - ./* src offset */
+ .long 0 /* no replacement */
+ .word \feature /* feature bit */
+ .byte 3b - 1b /* src len */
+ .byte 0 /* repl len */
+ .byte 0 /* pad len */
+ .previous
+ .section .altinstr_aux,"ax"
+6:
+ testb \bitnum,\cap_byte
+ jnz \t_yes
+ jmp \t_no
+ .previous
+.endm
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __KERNEL__ */
#endif /* _ASM_X86_CPUFEATURE_H */
diff --git a/arch/x86/kernel/macros.S b/arch/x86/kernel/macros.S
index 7baa40d5bf16..bf8b9c93e255 100644
--- a/arch/x86/kernel/macros.S
+++
[PATCH v3 5/9] x86: bug: prevent gcc distortions
GCC considers the number of statements in inlined assembly blocks,
according to new-lines and semicolons, as an indication to the cost of
the block in time and space. This data is distorted by the kernel code,
which puts information in alternative sections. As a result, the
compiler may perform incorrect inlining and branch optimizations.
The solution is to set an assembly macro and call it from the inlinedv
assembly block. As a result GCC considers the inline assembly block as
a single instruction.
This patch increases the kernel size:
textdata bss dec hex filename
18146889 10225380 2957312 31329581 1de0d2d ./vmlinux before
18147336 10226688 2957312 31331336 1de1408 ./vmlinux after (+1755)
But enables more aggressive inlining (and probably branch decisions).
The number of static text symbols in vmlinux is lower.
Static text symbols:
Before: 40218
After: 40053 (-165)
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Peter Zijlstra
Cc: Josh Poimboeuf
Signed-off-by: Nadav Amit
---
arch/x86/include/asm/bug.h | 98 ++
arch/x86/kernel/macros.S | 1 +
include/asm-generic/bug.h | 8 ++--
3 files changed, 61 insertions(+), 46 deletions(-)
diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
index 6804d6642767..5090035e6d16 100644
--- a/arch/x86/include/asm/bug.h
+++ b/arch/x86/include/asm/bug.h
@@ -4,6 +4,8 @@
#include
+#ifndef __ASSEMBLY__
+
/*
* Despite that some emulators terminate on UD2, we use it for WARN().
*
@@ -20,53 +22,15 @@
#define LEN_UD22
-#ifdef CONFIG_GENERIC_BUG
-
-#ifdef CONFIG_X86_32
-# define __BUG_REL(val)".long " __stringify(val)
-#else
-# define __BUG_REL(val)".long " __stringify(val) " - 2b"
-#endif
-
-#ifdef CONFIG_DEBUG_BUGVERBOSE
-
-#define _BUG_FLAGS(ins, flags) \
-do { \
- asm volatile("1:\t" ins "\n"\
-".pushsection __bug_table,\"aw\"\n"\
-"2:\t" __BUG_REL(1b) "\t# bug_entry::bug_addr\n" \
-"\t" __BUG_REL(%c0) "\t# bug_entry::file\n" \
-"\t.word %c1""\t# bug_entry::line\n" \
-"\t.word %c2""\t# bug_entry::flags\n" \
-"\t.org 2b+%c3\n" \
-".popsection" \
-: : "i" (__FILE__), "i" (__LINE__),\
-"i" (flags), \
-"i" (sizeof(struct bug_entry))); \
-} while (0)
-
-#else /* !CONFIG_DEBUG_BUGVERBOSE */
-
#define _BUG_FLAGS(ins, flags) \
do { \
- asm volatile("1:\t" ins "\n"\
-".pushsection __bug_table,\"aw\"\n"\
-"2:\t" __BUG_REL(1b) "\t# bug_entry::bug_addr\n" \
-"\t.word %c0""\t# bug_entry::flags\n" \
-"\t.org 2b+%c1\n" \
-".popsection" \
-: : "i" (flags), \
+ asm volatile("ASM_BUG ins=\"" ins "\" file=%c0 line=%c1 " \
+"flags=%c2 size=%c3" \
+: : "i" (__FILE__), "i" (__LINE__),\
+"i" (flags), \
"i" (sizeof(struct bug_entry))); \
} while (0)
-#endif /* CONFIG_DEBUG_BUGVERBOSE */
-
-#else
-
-#define _BUG_FLAGS(ins, flags) asm volatile(ins)
-
-#endif /* CONFIG_GENERIC_BUG */
-
#define HAVE_ARCH_BUG
#define BUG() \
do { \
@@ -82,4 +46,54 @@ do {
\
#include
+#else /* __ASSEMBLY__ */
+
+#ifdef CONFIG_GENERIC_BUG
+
+#ifdef CONFIG_X86_32
+.macro __BUG_REL val:req
+ .long \val
+.endm
+#else
+.macro __BUG_REL val:req
+ .long \val - 2b
+.endm
+#endif
+
+#ifdef CONFIG_DEBUG_BUGVERBOSE
+
+.macro ASM_BUG ins:req file:req line:req flags:req size:req
+1: \ins
+ .pushsection __bug_table,"aw"
+2: __BUG_REL val=1b# bug_entry::bug_addr
+ __BUG_REL val=\file # bug_entry::file
+ .word \line # bug_entry::line
+ .word \flags# bug_entry::flags
+ .org 2b+\size
+ .popsection
+.endm
+
+#else /* !CONFIG_DEBUG_BUGVERBOSE */
+
+.macro ASM_BUG ins:req file:req line:req
[PATCH v3 0/9] x86: macrofying inline asm for better compilation
This patch-set deals with an interesting yet stupid problem: kernel code that does not get inlined despite its simplicity. There are several causes for this behavior: "cold" attribute on __init, different function optimization levels; conditional constant computations based on __builtin_constant_p(); and finally large inline assembly blocks. This patch-set deals with the inline assembly problem. I separated these patches from the others (that were sent in the RFC) for easier inclusion. I also separated the removal of unnecessary new-lines which would be sent separately. The problem with inline assembly is that inline assembly is often used by the kernel for things that are other than code - for example, assembly directives and data. GCC however is oblivious to the content of the blocks and assumes their cost in space and time is proportional to the number of the perceived assembly "instruction", according to the number of newlines and semicolons. Alternatives, paravirt and other mechanisms are affected, causing code not to be inlined, and degrading compilation quality in general. The solution that this patch-set carries for this problem is to create an assembly macro, and then call it from the inline assembly block. As a result, the compiler sees a single "instruction" and assigns the more appropriate cost to the code. To avoid uglification of the code, as many noted, the macros are first precompiled into an assembly file, which is later assembled together with the the C files. This also enables to avoid duplicate implementation that was set before for the asm and C code. This can be seen in the exception table changes. Overall this patch-set slightly increases the kernel size (my build was done using my Ubuntu 18.04 config + localyesconfig for the record): textdata bss dec hex filename 18140829 10224724 2957312 31322865 1ddf2f1 ./vmlinux before 18163608 10227348 2957312 31348268 1de562c ./vmlinux after (+0.1%) The number of static functions in the image is reduced by 379, but actually inlining is even better, which does not always shows in these numbers: a function may be inlined causing the calling function not to be inlined. The Makefile stuff may not be too clean. Ideas for improvements are welcome. v2->v3: * Several build issues resolved (0-day) * Wrong comments fix (Josh) * Change asm vs C order in refcount (Kees) v1->v2: * Compiling the macros into a separate .s file, improving readability (Linus) * Improving assembly formatting, applying most of the comments according to my judgment (Jan) * Adding exception-table, cpufeature and jump-labels * Removing new-line cleanup; to be submitted separately Cc: Alok Kataria Cc: Christopher Li Cc: Greg Kroah-Hartman Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jan Beulich Cc: Josh Poimboeuf Cc: Juergen Gross Cc: Kate Stewart Cc: Kees Cook Cc: linux-spa...@vger.kernel.org Cc: Peter Zijlstra Cc: Philippe Ombredanne Cc: Thomas Gleixner Cc: virtualizat...@lists.linux-foundation.org Cc: Linus Torvalds Cc: x...@kernel.org Nadav Amit (9): Makefile: Prepare for using macros for inline asm x86: objtool: use asm macro for better compiler decisions x86: refcount: prevent gcc distortions x86: alternatives: macrofy locks for better inlining x86: bug: prevent gcc distortions x86: prevent inline distortion by paravirt ops x86: extable: use macros instead of inline assembly x86: cpufeature: use macros instead of inline assembly x86: jump-labels: use macros instead of inline assembly Makefile | 9 ++- arch/x86/Makefile | 11 ++- arch/x86/include/asm/alternative-asm.h | 20 -- arch/x86/include/asm/alternative.h | 11 +-- arch/x86/include/asm/asm.h | 61 +++- arch/x86/include/asm/bug.h | 98 +++--- arch/x86/include/asm/cpufeature.h | 82 - arch/x86/include/asm/jump_label.h | 65 ++--- arch/x86/include/asm/paravirt_types.h | 54 +++--- arch/x86/include/asm/refcount.h| 74 +++ arch/x86/kernel/Makefile | 6 ++ arch/x86/kernel/macros.S | 16 + include/asm-generic/bug.h | 8 +-- include/linux/compiler.h | 56 +++ scripts/Kbuild.include | 4 +- 15 files changed, 347 insertions(+), 228 deletions(-) create mode 100644 arch/x86/kernel/macros.S -- 2.17.0
[PATCH v3 2/9] x86: objtool: use asm macro for better compiler decisions
GCC considers the number of statements in inlined assembly blocks,
according to new-lines and semicolons, as an indication to the cost of
the block in time and space. This data is distorted by the kernel code,
which puts information in alternative sections. As a result, the
compiler may perform incorrect inlining and branch optimizations.
In the case of objtool, this distortion is extreme, since anyhow the
annotations of objtool are discarded during linkage.
The solution is to set an assembly macro and call it from the inline
assembly block. As a result GCC considers the inline assembly block as
a single instruction.
This patch slightly increases the kernel size.
textdata bss dec hex filename
18140829 10224724 2957312 31322865 1ddf2f1 ./vmlinux before
18140970 10225412 2957312 31323694 1ddf62e ./vmlinux after (+829)
Static text symbols:
Before: 40321
After: 40302 (-19)
Cc: Christopher Li
Cc: linux-spa...@vger.kernel.org
Reviewed-by: Josh Poimboeuf
Signed-off-by: Nadav Amit
---
arch/x86/kernel/macros.S | 2 ++
include/linux/compiler.h | 56 ++--
2 files changed, 45 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/macros.S b/arch/x86/kernel/macros.S
index cfc1c7d1a6eb..cee28c3246dc 100644
--- a/arch/x86/kernel/macros.S
+++ b/arch/x86/kernel/macros.S
@@ -5,3 +5,5 @@
* commonly used. The macros are precompiled into assmebly file which is later
* assembled together with each compiled file.
*/
+
+#include
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index ab4711c63601..3efd85334774 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -99,22 +99,13 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int
val,
* unique, to convince GCC not to merge duplicate inline asm statements.
*/
#define annotate_reachable() ({
\
- asm volatile("%c0:\n\t" \
-".pushsection .discard.reachable\n\t" \
-".long %c0b - .\n\t" \
-".popsection\n\t" : : "i" (__COUNTER__)); \
+ asm volatile("ANNOTATE_REACHABLE counter=%c0" \
+: : "i" (__COUNTER__));\
})
#define annotate_unreachable() ({ \
- asm volatile("%c0:\n\t" \
-".pushsection .discard.unreachable\n\t"\
-".long %c0b - .\n\t" \
-".popsection\n\t" : : "i" (__COUNTER__)); \
+ asm volatile("ANNOTATE_UNREACHABLE counter=%c0" \
+: : "i" (__COUNTER__));\
})
-#define ASM_UNREACHABLE
\
- "999:\n\t" \
- ".pushsection .discard.unreachable\n\t" \
- ".long 999b - .\n\t"\
- ".popsection\n\t"
#else
#define annotate_reachable()
#define annotate_unreachable()
@@ -280,6 +271,45 @@ unsigned long read_word_at_a_time(const void *addr)
#endif /* __KERNEL__ */
+#else /* __ASSEMBLY__ */
+
+#ifdef __KERNEL__
+#ifndef LINKER_SCRIPT
+
+#ifdef CONFIG_STACK_VALIDATION
+.macro ANNOTATE_UNREACHABLE counter:req
+\counter:
+ .pushsection .discard.unreachable
+ .long \counter\()b -.
+ .popsection
+.endm
+
+.macro ANNOTATE_REACHABLE counter:req
+\counter:
+ .pushsection .discard.reachable
+ .long \counter\()b -.
+ .popsection
+.endm
+
+.macro ASM_UNREACHABLE
+999:
+ .pushsection .discard.unreachable
+ .long 999b - .
+ .popsection
+.endm
+#else /* CONFIG_STACK_VALIDATION */
+.macro ANNOTATE_UNREACHABLE counter:req
+.endm
+
+.macro ANNOTATE_REACHABLE counter:req
+.endm
+
+.macro ASM_UNREACHABLE
+.endm
+#endif /* CONFIG_STACK_VALIDATION */
+
+#endif /* LINKER_SCRIPT */
+#endif /* __KERNEL__ */
#endif /* __ASSEMBLY__ */
#ifndef __optimize
--
2.17.0
[PATCH v3 3/9] x86: refcount: prevent gcc distortions
GCC considers the number of statements in inlined assembly blocks,
according to new-lines and semicolons, as an indication to the cost of
the block in time and space. This data is distorted by the kernel code,
which puts information in alternative sections. As a result, the
compiler may perform incorrect inlining and branch optimizations.
The solution is to set an assembly macro and call it from the inlined
assembly block. As a result GCC considers the inline assembly block as
a single instruction.
This patch allows to inline functions such as __get_seccomp_filter().
Interestingly, this allows more aggressive inlining while reducing the
kernel size.
textdata bss dec hex filename
18140970 10225412 2957312 31323694 1ddf62e ./vmlinux before
18140140 10225284 2957312 31322736 1ddf270 ./vmlinux after (-958)
Static text symbols:
Before: 40302
After: 40286 (-16)
Functions such as kref_get(), free_user(), fuse_file_get() now get
inlined.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Kees Cook
Cc: Jan Beulich
Cc: Josh Poimboeuf
Signed-off-by: Nadav Amit
---
arch/x86/include/asm/refcount.h | 74 -
arch/x86/kernel/macros.S| 1 +
2 files changed, 46 insertions(+), 29 deletions(-)
diff --git a/arch/x86/include/asm/refcount.h b/arch/x86/include/asm/refcount.h
index 4cf11d88d3b3..6b2809a4d8e9 100644
--- a/arch/x86/include/asm/refcount.h
+++ b/arch/x86/include/asm/refcount.h
@@ -4,6 +4,41 @@
* x86-specific implementation of refcount_t. Based on PAX_REFCOUNT from
* PaX/grsecurity.
*/
+
+#ifdef __ASSEMBLY__
+
+#include
+#include
+
+.macro REFCOUNT_EXCEPTION counter:req
+ .pushsection .text..refcount
+111: lea \counter, %_ASM_CX
+112: ud2
+ ASM_UNREACHABLE
+ .popsection
+113: _ASM_EXTABLE_REFCOUNT(112b, 113b)
+.endm
+
+/* Trigger refcount exception if refcount result is negative. */
+.macro REFCOUNT_CHECK_LT_ZERO counter:req
+ js 111f
+ REFCOUNT_EXCEPTION counter="\counter"
+.endm
+
+/* Trigger refcount exception if refcount result is zero or negative. */
+.macro REFCOUNT_CHECK_LE_ZERO counter:req
+ jz 111f
+ REFCOUNT_CHECK_LT_ZERO counter="\counter"
+.endm
+
+/* Trigger refcount exception unconditionally. */
+.macro REFCOUNT_ERROR counter:req
+ jmp 111f
+ REFCOUNT_EXCEPTION counter="\counter"
+.endm
+
+#else /* __ASSEMBLY__ */
+
#include
/*
@@ -14,34 +49,11 @@
* central refcount exception. The fixup address for the exception points
* back to the regular execution flow in .text.
*/
-#define _REFCOUNT_EXCEPTION\
- ".pushsection .text..refcount\n"\
- "111:\tlea %[counter], %%" _ASM_CX "\n" \
- "112:\t" ASM_UD2 "\n" \
- ASM_UNREACHABLE \
- ".popsection\n" \
- "113:\n"\
- _ASM_EXTABLE_REFCOUNT(112b, 113b)
-
-/* Trigger refcount exception if refcount result is negative. */
-#define REFCOUNT_CHECK_LT_ZERO \
- "js 111f\n\t" \
- _REFCOUNT_EXCEPTION
-
-/* Trigger refcount exception if refcount result is zero or negative. */
-#define REFCOUNT_CHECK_LE_ZERO \
- "jz 111f\n\t" \
- REFCOUNT_CHECK_LT_ZERO
-
-/* Trigger refcount exception unconditionally. */
-#define REFCOUNT_ERROR \
- "jmp 111f\n\t" \
- _REFCOUNT_EXCEPTION
static __always_inline void refcount_add(unsigned int i, refcount_t *r)
{
asm volatile(LOCK_PREFIX "addl %1,%0\n\t"
- REFCOUNT_CHECK_LT_ZERO
+ "REFCOUNT_CHECK_LT_ZERO counter=\"%[counter]\""
: [counter] "+m" (r->refs.counter)
: "ir" (i)
: "cc", "cx");
@@ -50,7 +62,7 @@ static __always_inline void refcount_add(unsigned int i,
refcount_t *r)
static __always_inline void refcount_inc(refcount_t *r)
{
asm volatile(LOCK_PREFIX "incl %0\n\t"
- REFCOUNT_CHECK_LT_ZERO
+ "REFCOUNT_CHECK_LT_ZERO counter=\"%[counter]\""
: [counter] "+m" (r->refs.counter)
: : "cc", "cx");
}
@@ -58,7 +70,7 @@ static __always_inline void refcount_inc(refcount_t *r)
static __always_inline void refcount_dec(refcount_t *r)
{
asm volatile(LOCK_PREFIX "decl %0\n\t"
- REFCOUNT_CHECK_LE_ZERO
+ "REFCOUNT_CHECK_LE_ZERO counter=\"%[counter]\""
: [counter] "+m" (r->refs.counter)
: : "cc", "cx");
}
@@ -66,13 +78,15 @@ static __always_inline void refcount_dec(refcount_t *r)
static __always_inline __must_check
bool refcount_sub_and_test(unsigned int i, refcount_t *r)
{
- GEN_BINARY_SUFFIXED_RMWcc(LOCK_PREFIX
[PATCH v3 4/9] x86: alternatives: macrofy locks for better inlining
GCC considers the number of statements in inlined assembly blocks, according to new-lines and semicolons, as an indication to the cost of the block in time and space. This data is distorted by the kernel code, which puts information in alternative sections. As a result, the compiler may perform incorrect inlining and branch optimizations. The solution is to set an assembly macro and call it from the inlined assembly block. As a result GCC considers the inline assembly block as a single instruction. This patch handles the LOCK prefix, allowing more aggresive inlining. textdata bss dec hex filename 18140140 10225284 2957312 31322736 1ddf270 ./vmlinux before 18146889 10225380 2957312 31329581 1de0d2d ./vmlinux after (+6845) Static text symbols: Before: 40286 After: 40218 (-68) Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: Josh Poimboeuf Signed-off-by: Nadav Amit --- arch/x86/include/asm/alternative-asm.h | 20 ++-- arch/x86/include/asm/alternative.h | 11 ++- arch/x86/kernel/macros.S | 1 + 3 files changed, 17 insertions(+), 15 deletions(-) diff --git a/arch/x86/include/asm/alternative-asm.h b/arch/x86/include/asm/alternative-asm.h index 31b627b43a8e..8e4ea39e55d0 100644 --- a/arch/x86/include/asm/alternative-asm.h +++ b/arch/x86/include/asm/alternative-asm.h @@ -7,16 +7,24 @@ #include #ifdef CONFIG_SMP - .macro LOCK_PREFIX -672: lock +.macro LOCK_PREFIX_HERE .pushsection .smp_locks,"a" .balign 4 - .long 672b - . + .long 671f - . # offset .popsection - .endm +671: +.endm + +.macro LOCK_PREFIX insn:vararg + LOCK_PREFIX_HERE + lock \insn +.endm #else - .macro LOCK_PREFIX - .endm +.macro LOCK_PREFIX_HERE +.endm + +.macro LOCK_PREFIX insn:vararg +.endm #endif /* diff --git a/arch/x86/include/asm/alternative.h b/arch/x86/include/asm/alternative.h index 4cd6a3b71824..d7faa16622d8 100644 --- a/arch/x86/include/asm/alternative.h +++ b/arch/x86/include/asm/alternative.h @@ -31,15 +31,8 @@ */ #ifdef CONFIG_SMP -#define LOCK_PREFIX_HERE \ - ".pushsection .smp_locks,\"a\"\n" \ - ".balign 4\n" \ - ".long 671f - .\n" /* offset */ \ - ".popsection\n" \ - "671:" - -#define LOCK_PREFIX LOCK_PREFIX_HERE "\n\tlock; " - +#define LOCK_PREFIX_HERE "LOCK_PREFIX_HERE\n\t" +#define LOCK_PREFIX "LOCK_PREFIX " #else /* ! CONFIG_SMP */ #define LOCK_PREFIX_HERE "" #define LOCK_PREFIX "" diff --git a/arch/x86/kernel/macros.S b/arch/x86/kernel/macros.S index f1fe1d570365..852487a9fc56 100644 --- a/arch/x86/kernel/macros.S +++ b/arch/x86/kernel/macros.S @@ -8,3 +8,4 @@ #include #include +#include -- 2.17.0
[PATCH v3 1/9] Makefile: Prepare for using macros for inline asm
Using macros for inline assembly improves both readability and compilation decisions that are distorted by big assembly blocks that use alternative sections. Compile macros.S and use it to assemble all C files. Currently, only x86 will use it. Cc: Masahiro Yamada Cc: Michal Marek Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: linux-kbu...@vger.kernel.org Signed-off-by: Nadav Amit --- Makefile | 9 +++-- arch/x86/Makefile| 11 +-- arch/x86/kernel/Makefile | 6 ++ arch/x86/kernel/macros.S | 7 +++ scripts/Kbuild.include | 4 +++- 5 files changed, 32 insertions(+), 5 deletions(-) create mode 100644 arch/x86/kernel/macros.S diff --git a/Makefile b/Makefile index 554dcaddbce4..026586db2f26 100644 --- a/Makefile +++ b/Makefile @@ -1085,7 +1085,7 @@ scripts: scripts_basic include/config/auto.conf include/config/tristate.conf \ # version.h and scripts_basic is processed / created. # Listed in dependency order -PHONY += prepare archprepare prepare0 prepare1 prepare2 prepare3 +PHONY += prepare archprepare macroprepare prepare0 prepare1 prepare2 prepare3 # prepare3 is used to check if we are building in a separate output directory, # and if so do: @@ -1109,7 +1109,9 @@ prepare1: prepare2 $(version_h) $(autoksyms_h) include/generated/utsrelease.h \ include/config/auto.conf $(cmd_crmodverdir) -archprepare: archheaders archscripts prepare1 scripts_basic +macroprepare: prepare1 archmacros + +archprepare: archheaders archscripts macroprepare scripts_basic prepare0: archprepare gcc-plugins $(Q)$(MAKE) $(build)=. @@ -1214,6 +1216,9 @@ archheaders: PHONY += archscripts archscripts: +PHONY += archmacros +archmacros: + PHONY += __headers __headers: $(version_h) scripts_basic uapi-asm-generic archheaders archscripts $(Q)$(MAKE) $(build)=scripts build_unifdef diff --git a/arch/x86/Makefile b/arch/x86/Makefile index 60135cbd905c..6b82314776fd 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -235,8 +235,8 @@ ifdef CONFIG_X86_64 LDFLAGS += $(call ld-option, -z max-page-size=0x20) endif -# Speed up the build -KBUILD_CFLAGS += -pipe +# We cannot use -pipe flag since we give an additional .s file to the compiler +#KBUILD_CFLAGS += -pipe # Workaround for a gcc prelease that unfortunately was shipped in a suse release KBUILD_CFLAGS += -Wno-sign-compare # @@ -258,11 +258,18 @@ archscripts: scripts_basic archheaders: $(Q)$(MAKE) $(build)=arch/x86/entry/syscalls all +archmacros: + $(Q)$(MAKE) $(build)=arch/x86/kernel macros + archprepare: ifeq ($(CONFIG_KEXEC_FILE),y) $(Q)$(MAKE) $(build)=arch/x86/purgatory arch/x86/purgatory/kexec-purgatory.c endif +ASM_MACRO_FLAGS = -Wa,arch/x86/kernel/macros.s +export ASM_MACRO_FLAGS +KBUILD_CFLAGS += $(ASM_MACRO_FLAGS) + ### # Kernel objects diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index 02d6f5cf4e70..fdb6c5b2a922 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -9,6 +9,12 @@ extra-y+= ebda.o extra-y+= platform-quirks.o extra-y+= vmlinux.lds +$(obj)/macros.s: $(obj)/macros.S FORCE + $(call if_changed_dep,cpp_s_S) + +macros: $(obj)/macros.s + @: + CPPFLAGS_vmlinux.lds += -U$(UTS_MACHINE) ifdef CONFIG_FUNCTION_TRACER diff --git a/arch/x86/kernel/macros.S b/arch/x86/kernel/macros.S new file mode 100644 index ..cfc1c7d1a6eb --- /dev/null +++ b/arch/x86/kernel/macros.S @@ -0,0 +1,7 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +/* + * This file includes headers whose assembly part includes macros which are + * commonly used. The macros are precompiled into assmebly file which is later + * assembled together with each compiled file. + */ diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include index 50cee534fd64..ad2c02062aa4 100644 --- a/scripts/Kbuild.include +++ b/scripts/Kbuild.include @@ -189,7 +189,9 @@ __cc-option = $(call try-run-cached,\ # Do not attempt to build with gcc plugins during cc-option tests. # (And this uses delayed resolution so the flags will be up to date.) -CC_OPTION_CFLAGS = $(filter-out $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS)) +# In addition, do not include the asm macros which are built later. +CC_OPTION_FILTERED = $(GCC_PLUGINS_CFLAGS) $(ASM_MACRO_FLAGS) +CC_OPTION_CFLAGS = $(filter-out $(CC_OPTION_FILTERED),$(KBUILD_CFLAGS)) # cc-option # Usage: cflags-y += $(call cc-option,-march=winchip-c6,-march=i586) -- 2.17.0
Re: Grant-
I Mikhail Fridman. has selected you specially as one of my beneficiaries for my Charitable Donation, Just as I have declared on May 23, 2016 to give my fortune as charity. Check the link below for confirmation: http://www.ibtimes.co.uk/russias-second-wealthiest-man-mikhail-fridman-plans-leaving-14-2bn-fortune-charity-1561604 Reply as soon as possible with further directives. Best Regards, Mikhail Fridman.
[PATCH] staging:iio:accel: use sign extend function avoiding code duplication
Use sign_extend32 kernel function instead of code duplication. This function is also safe for 16 bits. Signed-off-by: Karim Eshapa --- drivers/staging/iio/accel/adis16201.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/staging/iio/accel/adis16201.c b/drivers/staging/iio/accel/adis16201.c index 0fae8aaf1cf4..fe4494e65395 100644 --- a/drivers/staging/iio/accel/adis16201.c +++ b/drivers/staging/iio/accel/adis16201.c @@ -227,9 +227,7 @@ static int adis16201_read_raw(struct iio_dev *indio_dev, ret = adis_read_reg_16(st, addr, &val16); if (ret) return ret; - val16 &= (1 << bits) - 1; - val16 = (s16)(val16 << (16 - bits)) >> (16 - bits); - *val = val16; + *val = sign_extend32(val16, bits); return IIO_VAL_INT; } -- 2.17.1
[GIT PULL] RTC for 4.18
Hi Linus, Here is the pull-request for the RTC subsystem for 4.18. Setting the supported range from drivers for RTCs failing soon has started. A few fixes are developed along the way. Some drivers have been switched to SPDX by their maintainers. The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/rtc-4.18 for you to fetch changes up to e4302aec8a0646828a701443e303eb5ef48b37f5: rtc: pxa: fix probe function (2018-06-07 20:11:08 +0200) RTC for 4.18 Subsystem: - rework of the rtc-test driver which allows to test the core more thoroughly - rtc_set_alarm() now fails early when alarms are not supported Drivers: - mktime is now replaced by mktime64 - RTC range added for 88pm80x, ab-b5ze-s3, at91rm9200, brcmstb-waketimer, ds1685, ftrtc010, ls1x, mxc_v2, rx8581, sprd, st-lpc, tps6586x, tps65910 and vr41xx - Fixed a possible race condition in probe functions - pxa: fix the probe function that is broken since v4.3 - stm32: now supports stm32mp1 Alexandre Belloni (49): rtc: nvmem: don't return an error when not enabled rtc: at91rm9200: add range rtc: 88pm80x: stop setting a default time rtc: 88pm80x: remove unused pm80x_rtc_info members rtc: 88pm80x: fix possible race condition rtc: 88pm80x: let the core handle the RTC range rtc: 88pm80x: convert to rtc_tm_to_time64/rtc_time64_to_tm rtc: ab-b5ze-s3: fix possible race conditions rtc: ab-b5ze-s3: let the core handle the RTC range rtc: tps65910: fix possible race condition rtc: tps65910: allow platform power up rtc: tps65910: add range rtc: rx8581: switch to rtc_register_device rtc: rx8581: add RTC range rtc: rx8581: let the core handle rtc range rtc: rx8581: remove useless indirection rtc: rx8581: remove useless declaration rtc: rx8581: error out when time invalid rtc: rx8581: switch to regmap rtc: vr41xx: fix possible race condition rtc: vr41xx: add range rtc: tps6586x: fix possible race condition rtc: tps6586x: let the core handle rtc range rtc: ls1x: switch to rtc_register_device rtc: ls1x: remove useless label and goto rtc: ls1x: add range rtc: mxc_v2: fix possible race condition rtc: mxc_v2: let the core handle rtc range rtc: mxc_v2: use rtc_time64_to_tm in mxc_rtc_read_alarm rtc: brcmstb-waketimer: switch to rtc_register_device rtc: brcmstb-waketimer: add range rtc: st-lpc: fix possible race condition rtc: st-lpc: add range rtc: test: remove obsolete .set_mmss rtc: ds1685: fix possible race condition rtc: ds1685: Add range rtc: test: remove useless proc info rtc: test: allow registering many devices rtc: test: store time as an offset to system time rtc: test: emulate alarms using timers rtc: test: remove irq sysfs file rtc: sunxi: fix possible race condition rtc: mrst: switch to devm functions rtc: ftrtc010: switch to devm_rtc_allocate_device rtc: ftrtc010: handle dates after 2106 rtc: ftrtc010: let the core handle range rtc: test: convert to devm_rtc_allocate_device rtc: test: remove alarm support from the first device rtc: ensure rtc_set_alarm fails when alarms are not supported Amelie Delaunay (8): rtc: stm32: fix copyright and adopt SPDX identifier rtc: stm32: fix alarm interrupt flags by removing IRQF_TRIGGER_RISING dt-bindings: rtc: update stm32-rtc documentation for st, syscfg property rtc: stm32: get DBP register and mask from DT st, syscfg property rtc: stm32: fix misspelling and misalignment issues rtc: stm32: rework register management to prepare other version of RTC dt-bindings: rtc: update stm32-rtc documentation for stm32mp1 rtc rtc: stm32: add stm32mp1 rtc support Andrea Greco (1): rtc: ds1340: Add support for trickle charger. Arnd Bergmann (3): rtc: vr41xx: remove mktime usage rtc: ls1x: remove mktime usage rtc: tps6586x: remove mktime usage Baolin Wang (3): rtc: sprd: Change to use devm_rtc_allocate_device() rtc: sprd: Add RTC hardware range rtc: sprd: Add new RTC power down check method Dan Carpenter (1): rtc: pxa: fix probe function Enric Balletbo i Serra (2): rtc: cros-ec: Make license text and module license match. rtc: cros-ec: Switch to SPDX identifier. Fabio Estevam (3): dt-bindings: rtc-2123: Make the node name generic rtc: snvs: Switch to SPDX identifier rtc: mxc: Switch to SPDX identifier Mathieu Malaterre (1): rtc: jz4740: Fix a typo in Kconfig Michael Trimarchi (1): rtc:
Re: [PATCH] staging:iio:accel: use sign extend function avoiding code duplication
On Mon, 2018-06-11 at 00:09 +0200, Karim Eshapa wrote: > Use sign_extend32 kernel function instead of code duplication. > This function is also safe for 16 bits. Firstly: This file is not in staging anymore. Please use the -next tree for patches. > diff --git a/drivers/staging/iio/accel/adis16201.c > b/drivers/staging/iio/accel/adis16201.c [] > @@ -227,9 +227,7 @@ static int adis16201_read_raw(struct iio_dev *indio_dev, > ret = adis_read_reg_16(st, addr, &val16); > if (ret) > return ret; > - val16 &= (1 << bits) - 1; > - val16 = (s16)(val16 << (16 - bits)) >> (16 - bits); > - *val = val16; > + *val = sign_extend32(val16, bits); > return IIO_VAL_INT; > } Secondly: A similar patch with a different bits value was already applied. Please verify the appropriate bits value. commit e7f3bfb7eb7d9307c0c157f82fceb228f0aec1d9 Author: Himanshu Jha Date: Sat Mar 17 01:36:23 2018 +0530 Staging: iio: accel: adis16201: Use sign_extend32 function Use sign_extned32() for 32 bit sign extending rather than hard coding. Signed-off-by: Himanshu Jha Signed-off-by: Jonathan Cameron --- drivers/staging/iio/accel/adis16201.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/staging/iio/accel/adis16201.c b/drivers/staging/iio/accel/adis16201.c index 87ad3d421c12..526dde481f84 100644 --- a/drivers/staging/iio/accel/adis16201.c +++ b/drivers/staging/iio/accel/adis16201.c @@ -173,9 +173,8 @@ static int adis16201_read_raw(struct iio_dev *indio_dev, ret = adis_read_reg_16(st, addr, &val16); if (ret) return ret; - val16 &= (1 << bits) - 1; - val16 = (s16)(val16 << (16 - bits)) >> (16 - bits); - *val = val16; + + *val = sign_extend32(val16, bits - 1); return IIO_VAL_INT; }
[PATCH 1/5] vt: perform safe console erase only once
Commit f8df13e0a9 ("tty: Clean console safely") added code to clear
both the scrollback buffer and the screen with "\e[3J", then execution
falls through into the code to simply clear the screen. This means
scr_memsetw() and the console driver update callback is called twice
on the whole screen buffer. Let's reorganize the code so the same work
is not performed twice.
Signed-off-by: Nicolas Pitre
---
drivers/tty/vt/vt.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index f97251f39c..1eb1a376a0 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1178,15 +1178,8 @@ static void csi_J(struct vc_data *vc, int vpar)
count = ((vc->vc_pos - vc->vc_origin) >> 1) + 1;
start = (unsigned short *)vc->vc_origin;
break;
- case 3: /* erase scroll-back buffer (and whole display) */
- scr_memsetw(vc->vc_screenbuf, vc->vc_video_erase_char,
- vc->vc_screenbuf_size);
- flush_scrollback(vc);
- set_origin(vc);
- if (con_is_visible(vc))
- update_screen(vc);
- /* fall through */
case 2: /* erase whole display */
+ case 3: /* (and scrollback buffer later) */
count = vc->vc_cols * vc->vc_rows;
start = (unsigned short *)vc->vc_origin;
break;
@@ -1194,7 +1187,12 @@ static void csi_J(struct vc_data *vc, int vpar)
return;
}
scr_memsetw(start, vc->vc_video_erase_char, 2 * count);
- if (con_should_update(vc))
+ if (vpar == 3) {
+ set_origin(vc);
+ flush_scrollback(vc);
+ if (con_is_visible(vc))
+ update_screen(vc);
+ } else if (con_should_update(vc))
do_update_region(vc, (unsigned long) start, count);
vc->vc_need_wrap = 0;
}
--
2.17.0
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] have the vt console preserve unicode characters
The vt code translates UTF-8 strings into glyph index values and stores those glyph values directly in the screen buffer. Because there can only be at most 512 glyphs, it is impossible to represent most unicode characters, in which case a default glyph (often '?') is displayed instead. The original unicode value is then lost. This also means that the /dev/vcs* devices only provide user space with glyph index values, and then user applications must get hold of the unicode-to-glyph table the kernel is using in order to back-translate those into actual characters. It is not possible to get back the original unicode value when multiple unicode characters map to the same glyph, especially for the vast majority that maps to the default replacement glyph. The 512-glyph limitation is inherent to VGA displays, but users of /dev/vcs* shouldn't have to be restricted to a narrow unicode space from lossy screen content because of that. This is especially true for accessibility applications such as BRLTTY that rely on /dev/vcs to rander screen content onto braille terminals. This patch series introduces unicode support to /dev/vcs* devices, allowing full unicode access from userspace to the vt console which can, amongst other purposes, appropriately translate actual unicode screen content into braille. Memory is allocated, and possible CPU overhead introduced, only if /dev/vcsu is read at least once. I'm a prime user of this feature, as well as the BRLTTY maintainer Dave Mielke who implemented support for this in BRLTTY. There is therefore a vested self interest to maintain this feature as necessary. Patch #1 has been picked up by Greg already (commit 4b4ecd9cb8 in linux-next) but it is included here as well, as the rest of the series depends on it to apply properly. Patch #5 was used for validation and is included for completeness, however if people think it is unappropriate for mainline then it can be dropped. This is also available on top of v4.17-rc7 here: git://git.linaro.org/people/nicolas.pitre/linux vt-unicode diffstat: drivers/tty/vt/vc_screen.c | 90 +++-- drivers/tty/vt/vt.c| 366 +-- include/linux/console_struct.h | 2 + include/linux/selection.h | 5 + 4 files changed, 429 insertions(+), 34 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-console" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] vt: coherence validation code for the unicode screen buffer
Make sure the unicode screen buffer matches the video screen content.
This is provided for debugging convenience and disabled by default.
Signed-off-by: Nicolas Pitre
---
drivers/tty/vt/vt.c | 40
1 file changed, 40 insertions(+)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index e7c3cabeb1..2f3d528082 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -571,6 +571,45 @@ void vc_uniscr_copy_line(struct vc_data *vc, void *dest,
int viewed,
}
}
+/* this is for validation and debugging only */
+static void vc_uniscr_debug_check(struct vc_data *vc)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+ unsigned short *p;
+ int x, y, mask;
+
+ if (true)
+ return;
+
+ if (!uniscr)
+ return;
+
+ WARN_CONSOLE_UNLOCKED();
+
+ /*
+* Make sure our unicode screen translates into the same glyphs
+* as the actual screen. This is brutal indeed.
+*/
+ p = (unsigned short *)vc->vc_origin;
+ mask = vc->vc_hi_font_mask | 0xff;
+ for (y = 0; y < vc->vc_rows; y++) {
+ char32_t *line = uniscr->lines[y];
+ for (x = 0; x < vc->vc_cols; x++) {
+ u16 glyph = scr_readw(p++) & mask;
+ char32_t uc = line[x];
+ int tc = conv_uni_to_pc(vc, uc);
+ if (tc == -4)
+ tc = conv_uni_to_pc(vc, 0xfffd);
+ if (tc == -4)
+ tc = conv_uni_to_pc(vc, '?');
+ if (tc != glyph)
+ pr_notice("%s: mismatch at %d,%d: "
+ "glyph=%#x tc=%#x\n", __func__,
+ x, y, glyph, tc);
+ }
+ }
+}
+
static void con_scroll(struct vc_data *vc, unsigned int t, unsigned int b,
enum con_scroll dir, unsigned int nr)
@@ -2719,6 +2758,7 @@ static int do_con_write(struct tty_struct *tty, const
unsigned char *buf, int co
do_con_trol(tty, vc, orig);
}
con_flush(vc, draw_from, draw_to, &draw_x);
+ vc_uniscr_debug_check(vc);
console_conditional_schedule();
console_unlock();
notify_update(vc);
--
2.17.0
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] vt: preserve unicode values corresponding to screen characters
The vt code translates UTF-8 strings into glyph index values and stores
those glyph values directly in the screen buffer. Because there can only
be at most 512 glyphs, it is impossible to represent most unicode
characters, in which case a default glyph (often '?') is displayed
instead. The original unicode value is then lost.
This patch implements the basic screen buffer handling to preserve unicode
values alongside corresponding display glyphs. It is not activated by
default, meaning that people not relying on that functionality won't get
the implied overhead.
Signed-off-by: Nicolas Pitre
Tested-by: Dave Mielke
---
drivers/tty/vt/vt.c| 222 +++--
include/linux/console_struct.h | 2 +
2 files changed, 213 insertions(+), 11 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 1eb1a376a0..3a801a60f4 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -317,6 +317,173 @@ void schedule_console_callback(void)
schedule_work(&console_work);
}
+/*
+ * Code to manage unicode-based screen buffers
+ */
+
+#ifdef NO_VC_UNI_SCREEN
+/* this disables and optimizes related code away at compile time */
+#define get_vc_uniscr(vc) NULL
+#else
+#define get_vc_uniscr(vc) vc->vc_uni_screen
+#endif
+
+typedef uint32_t char32_t;
+
+/*
+ * Our screen buffer is preceded by an array of line pointers so that
+ * scrolling only implies some pointer shuffling.
+ */
+struct uni_screen {
+ char32_t *lines[0];
+};
+
+static struct uni_screen *vc_uniscr_alloc(unsigned int cols, unsigned int rows)
+{
+ struct uni_screen *uniscr;
+ void *p;
+ unsigned int memsize, i;
+
+ /* allocate everything in one go */
+ memsize = cols * rows * sizeof(char32_t);
+ memsize += rows * sizeof(char32_t *);
+ p = kmalloc(memsize, GFP_KERNEL);
+ if (!p) {
+ pr_err("unable to allocate unicode screen buffer");
+ return NULL;
+ }
+
+ /* initial line pointers */
+ uniscr = p;
+ p = uniscr->lines + rows;
+ for (i = 0; i < rows; i++) {
+ uniscr->lines[i] = p;
+ p += cols * sizeof(char32_t);
+ }
+ return uniscr;
+}
+
+static void vc_uniscr_set(struct vc_data *vc, struct uni_screen *new_uniscr)
+{
+ kfree(vc->vc_uni_screen);
+ vc->vc_uni_screen = new_uniscr;
+}
+
+static void vc_uniscr_putc(struct vc_data *vc, char32_t uc)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr)
+ uniscr->lines[vc->vc_y][vc->vc_x] = uc;
+}
+
+static void vc_uniscr_insert(struct vc_data *vc, unsigned int nr)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr) {
+ char32_t *ln = uniscr->lines[vc->vc_y];
+ unsigned int x = vc->vc_x, cols = vc->vc_cols;
+
+ memmove(&ln[x + nr], &ln[x], (cols - x - nr) * sizeof(*ln));
+ memset32(&ln[x], ' ', nr);
+ }
+}
+
+static void vc_uniscr_delete(struct vc_data *vc, unsigned int nr)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr) {
+ char32_t *ln = uniscr->lines[vc->vc_y];
+ unsigned int x = vc->vc_x, cols = vc->vc_cols;
+
+ memcpy(&ln[x], &ln[x + nr], (cols - x - nr) * sizeof(*ln));
+ memset32(&ln[cols - nr], ' ', nr);
+ }
+}
+
+static void vc_uniscr_clear_line(struct vc_data *vc, unsigned int x,
+unsigned int nr)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr) {
+ char32_t *ln = uniscr->lines[vc->vc_y];
+
+ memset32(&ln[x], ' ', nr);
+ }
+}
+
+static void vc_uniscr_clear_lines(struct vc_data *vc, unsigned int y,
+ unsigned int nr)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr) {
+ unsigned int cols = vc->vc_cols;
+
+ while (nr--)
+ memset32(uniscr->lines[y++], ' ', cols);
+ }
+}
+
+static void vc_uniscr_scroll(struct vc_data *vc, unsigned int t, unsigned int
b,
+enum con_scroll dir, unsigned int nr)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr) {
+ unsigned int s, d, rescue, clear;
+ char32_t *save[nr];
+
+ s = clear = t;
+ d = t + nr;
+ rescue = b - nr;
+ if (dir == SM_UP) {
+ swap(s, d);
+ swap(clear, rescue);
+ }
+ memcpy(save, uniscr->lines + rescue, nr * sizeof(*save));
+ memmove(uniscr->lines + d, uniscr->lines + s,
+ (b - t - nr) * sizeof(*uniscr->lines));
+ memcpy(uniscr->lines + clear, save, nr * sizeof(*save));
+ vc_uniscr_clear_lines(vc, clear, nr);
+ }
+}
+
+static void vc_u
[PATCH 4/5] vt: unicode fallback for scrollback
There is currently no provision for scrollback content in the core code,
leaving that to backend video drivers where this can be highly optimized.
There is currently no common method for those drivers to tell the core
what part of the scrollback is actually displayed and what size the
scrollback buffer is either. Because of that, the unicode screen buffer
has no provision for any scrollback.
At least we can provide backtranslated glyph values when the scrollback
is active which should be plenty good enough for now.
Signed-off-by: Nicolas Pitre
Tested-by: Dave Mielke
---
drivers/tty/vt/vc_screen.c | 3 ++-
drivers/tty/vt/vt.c| 31 +--
include/linux/selection.h | 2 +-
3 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/vt/vc_screen.c b/drivers/tty/vt/vc_screen.c
index 9c44252e52..2384ea85ff 100644
--- a/drivers/tty/vt/vc_screen.c
+++ b/drivers/tty/vt/vc_screen.c
@@ -311,7 +311,8 @@ vcs_read(struct file *file, char __user *buf, size_t count,
loff_t *ppos)
do {
if (nr > this_round/4)
nr = this_round/4;
- vc_uniscr_copy_line(vc, con_buf0, row, col, nr);
+ vc_uniscr_copy_line(vc, con_buf0, viewed,
+ row, col, nr);
con_buf0 += nr * 4;
this_round -= nr * 4;
row++;
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 2cba6089ca..e7c3cabeb1 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -535,13 +535,40 @@ int vc_uniscr_check(struct vc_data *vc)
* This must be preceded by a successful call to vc_uniscr_check() once
* the console lock has been taken.
*/
-void vc_uniscr_copy_line(struct vc_data *vc, void *dest,
+void vc_uniscr_copy_line(struct vc_data *vc, void *dest, int viewed,
unsigned int row, unsigned int col, unsigned int nr)
{
struct uni_screen *uniscr = get_vc_uniscr(vc);
+ int offset = row * vc->vc_size_row + col * 2;
+ unsigned long pos;
BUG_ON(!uniscr);
- memcpy(dest, &uniscr->lines[row][col], nr * sizeof(char32_t));
+
+ pos = (unsigned long)screenpos(vc, offset, viewed);
+ if (pos >= vc->vc_origin && pos < vc->vc_scr_end) {
+ /*
+* Desired position falls in the main screen buffer.
+* However the actual row/col might be different if
+* scrollback is active.
+*/
+ row = (pos - vc->vc_origin) / vc->vc_size_row;
+ col = ((pos - vc->vc_origin) % vc->vc_size_row) / 2;
+ memcpy(dest, &uniscr->lines[row][col], nr * sizeof(char32_t));
+ } else {
+ /*
+* Scrollback is active. For now let's simply backtranslate
+* the screen glyphs until the unicode screen buffer does
+* synchronize with console display drivers for a scrollback
+* buffer of its own.
+*/
+ u16 *p = (u16 *)pos;
+ int mask = vc->vc_hi_font_mask | 0xff;
+ char32_t *uni_buf = dest;
+ while (nr--) {
+ u16 glyph = scr_readw(p++) & mask;
+ *uni_buf++ = inverse_translate(vc, glyph, true);
+ }
+ }
}
diff --git a/include/linux/selection.h b/include/linux/selection.h
index 2b34df9f1e..067d2e99c7 100644
--- a/include/linux/selection.h
+++ b/include/linux/selection.h
@@ -43,7 +43,7 @@ extern void vcs_scr_writew(struct vc_data *vc, u16 val, u16
*org);
extern void vcs_scr_updated(struct vc_data *vc);
extern int vc_uniscr_check(struct vc_data *vc);
-extern void vc_uniscr_copy_line(struct vc_data *vc, void *dest,
+extern void vc_uniscr_copy_line(struct vc_data *vc, void *dest, int viewed,
unsigned int row, unsigned int col,
unsigned int nr);
--
2.17.0
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] vt: introduce unicode mode for /dev/vcs
Now that the core vt code knows how to preserve unicode values for each
displayed character, it is then possible to let user space access it via
/dev/vcs*.
Unicode characters are presented as 32 bit values in native endianity
via the /dev/vcsu* devices, mimicking the simple /dev/vcs* devices.
Unicode with attributes (similarly to /dev/vcsa*) is not supported at
the moment.
Data is available only as long as the console is in UTF-8 mode. ENODATA
is returned otherwise.
This was tested with the latest development version (to become
version 5.7) of BRLTTY. Amongst other things, this allows ⠋⠕⠗ ⠞⠓⠊⠎
⠃⠗⠁⠊⠇⠇⠑⠀⠞⠑⠭⠞⠀to appear directly on braille displays regardless of the
console font being used.
Signed-off-by: Nicolas Pitre
Tested-by: Dave Mielke
---
drivers/tty/vt/vc_screen.c | 89 --
drivers/tty/vt/vt.c| 61 ++
include/linux/selection.h | 5 +++
3 files changed, 141 insertions(+), 14 deletions(-)
diff --git a/drivers/tty/vt/vc_screen.c b/drivers/tty/vt/vc_screen.c
index e4a66e1fd0..9c44252e52 100644
--- a/drivers/tty/vt/vc_screen.c
+++ b/drivers/tty/vt/vc_screen.c
@@ -10,6 +10,12 @@
* Attribute/character pair is in native endianity.
*[minor: N+128]
*
+ * /dev/vcsuN: similar to /dev/vcsaN but using 4-byte unicode values
+ * instead of 1-byte screen glyph values.
+ *[minor: N+64]
+ *
+ * /dev/vcsuaN: same idea as /dev/vcsaN for unicode (not yet implemented).
+ *
* This replaces screendump and part of selection, so that the system
* administrator can control access using file system permissions.
*
@@ -51,6 +57,26 @@
#define CON_BUF_SIZE (CONFIG_BASE_SMALL ? 256 : PAGE_SIZE)
+/*
+ * Our minor space:
+ *
+ * 0 ... 63 glyph mode without attributes
+ * 64 ... 127 unicode mode without attributes
+ * 128 ... 191 glyph mode with attributes
+ * 192 ... 255 unused (reserved for unicode with attributes)
+ *
+ * This relies on MAX_NR_CONSOLES being <= 63, meaning 63 actual consoles
+ * with minors 0, 64, 128 and 192 being proxies for the foreground console.
+ */
+#if MAX_NR_CONSOLES > 63
+#warning "/dev/vcs* devices may not accommodate more than 63 consoles"
+#endif
+
+#define console(inode) (iminor(inode) & 63)
+#define use_unicode(inode) (iminor(inode) & 64)
+#define use_attributes(inode) (iminor(inode) & 128)
+
+
struct vcs_poll_data {
struct notifier_block notifier;
unsigned int cons_num;
@@ -102,7 +128,7 @@ vcs_poll_data_get(struct file *file)
poll = kzalloc(sizeof(*poll), GFP_KERNEL);
if (!poll)
return NULL;
- poll->cons_num = iminor(file_inode(file)) & 127;
+ poll->cons_num = console(file_inode(file));
init_waitqueue_head(&poll->waitq);
poll->notifier.notifier_call = vcs_notifier;
if (register_vt_notifier(&poll->notifier) != 0) {
@@ -140,7 +166,7 @@ vcs_poll_data_get(struct file *file)
static struct vc_data*
vcs_vc(struct inode *inode, int *viewed)
{
- unsigned int currcons = iminor(inode) & 127;
+ unsigned int currcons = console(inode);
WARN_CONSOLE_UNLOCKED();
@@ -164,7 +190,6 @@ static int
vcs_size(struct inode *inode)
{
int size;
- int minor = iminor(inode);
struct vc_data *vc;
WARN_CONSOLE_UNLOCKED();
@@ -175,8 +200,12 @@ vcs_size(struct inode *inode)
size = vc->vc_rows * vc->vc_cols;
- if (minor & 128)
+ if (use_attributes(inode)) {
+ if (use_unicode(inode))
+ return -EOPNOTSUPP;
size = 2*size + HEADER_SIZE;
+ } else if (use_unicode(inode))
+ size *= 4;
return size;
}
@@ -197,12 +226,10 @@ static ssize_t
vcs_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
{
struct inode *inode = file_inode(file);
- unsigned int currcons = iminor(inode);
struct vc_data *vc;
struct vcs_poll_data *poll;
- long pos;
- long attr, read;
- int col, maxcol, viewed;
+ long pos, read;
+ int attr, uni_mode, row, col, maxcol, viewed;
unsigned short *org = NULL;
ssize_t ret;
char *con_buf;
@@ -218,7 +245,8 @@ vcs_read(struct file *file, char __user *buf, size_t count,
loff_t *ppos)
*/
console_lock();
- attr = (currcons & 128);
+ uni_mode = use_unicode(inode);
+ attr = use_attributes(inode);
ret = -ENXIO;
vc = vcs_vc(inode, &viewed);
if (!vc)
@@ -227,6 +255,10 @@ vcs_read(struct file *file, char __user *buf, size_t
count, loff_t *ppos)
ret = -EINVAL;
if (pos < 0)
goto unlock_out;
+ /* we enforce 32-bit alignment for pos and count in unicode mode */
+ if (uni_mode && (pos | count) & 3)
+ goto unlock_out;
+
poll = file->private_data;
if (count && poll)
poll->seen_last_update = true;
@@ -266,7 +298,27
Re: [PATCH v4 3/4] mm/sparse: Add a new parameter 'data_unit_size' for alloc_usemap_and_memmap
On 06/08/18 at 09:13am, Dave Hansen wrote: > On 06/08/2018 08:17 AM, Baoquan He wrote: > > > > Then inside alloc_usemap_and_memmap(), For each node, we get how many > > present sections on this node, call hook alloc_func(). Then we update > > the pointer to point at a new position of usemap_map[] or map_map[]. > > I think this is the key. > > alloc_usemap_and_memmap() is passed in a "void *" that it needs to > update as things get consumed. But, it knows only the quantity of > objects consumed and not the type. This effectively tells it enough > about the type to let it update the pointer as objects are consumed. > > Right? > > Can we get that in the changelog? Hmm, I like above sentences very much, thanks. Do you means putting it in changelog, but not commit log of patch 3/4, right? I can do this when repost. Thanks Baoquan
[PATCH 1/2] rcutorture: Disable RT throttling for boost tests
From: "Joel Fernandes (Google)"
Currently rcutorture is not able to torture RCU boosting properly. This
is because the rcutorture's boost threads which are doing the torturing
may be throttled due to RT throttling.
This patch makes rcutorture use the right torture technique (unthrottled
rcutorture boost tasks) for torturing RCU so that the test fails
correctly when no boost is available.
Currently this requires accessing sysctl_sched_rt_runtime directly, but
that should be Ok since rcutorture is test code. Such direct access is
also only possible if rcutorture is used as a built-in so make it
conditional on that.
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/rcutorture.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 5219e7ccd8a4..00e06349d7bb 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -55,6 +55,7 @@
#include
#include
#include
+#include
#include "rcu.h"
@@ -772,6 +773,32 @@ static void rcu_torture_boost_cb(struct rcu_head *head)
smp_store_release(&rbip->inflight, 0);
}
+static int old_rt_runtime = -1;
+
+static void rcu_torture_disable_rt_throttle(void)
+{
+ /*
+* Disable RT throttling so that rcutorture's boost threads don't get
+* throttled. Only possible if rcutorture is built-in otherwise the
+* user should manually do this by setting the sched_rt_period_us and
+* sched_rt_runtime sysctls.
+*/
+ if (!IS_BUILTIN(CONFIG_RCU_TORTURE_TEST) || old_rt_runtime != -1)
+ return;
+
+ old_rt_runtime = sysctl_sched_rt_runtime;
+ sysctl_sched_rt_runtime = -1;
+}
+
+static void rcu_torture_enable_rt_throttle(void)
+{
+ if (!IS_BUILTIN(CONFIG_RCU_TORTURE_TEST) || old_rt_runtime == -1)
+ return;
+
+ sysctl_sched_rt_runtime = old_rt_runtime;
+ old_rt_runtime = -1;
+}
+
static int rcu_torture_boost(void *arg)
{
unsigned long call_rcu_time;
@@ -1510,6 +1537,7 @@ static int rcutorture_booster_cleanup(unsigned int cpu)
mutex_lock(&boost_mutex);
t = boost_tasks[cpu];
boost_tasks[cpu] = NULL;
+ rcu_torture_enable_rt_throttle();
mutex_unlock(&boost_mutex);
/* This must be outside of the mutex, otherwise deadlock! */
@@ -1526,6 +1554,7 @@ static int rcutorture_booster_init(unsigned int cpu)
/* Don't allow time recalculation while creating a new task. */
mutex_lock(&boost_mutex);
+ rcu_torture_disable_rt_throttle();
VERBOSE_TOROUT_STRING("Creating rcu_torture_boost task");
boost_tasks[cpu] = kthread_create_on_node(rcu_torture_boost, NULL,
cpu_to_node(cpu),
--
2.18.0.rc1.242.g61856ae69a-goog
[PATCH 2/2] rcutorture: Make boost test more robust
From: "Joel Fernandes (Google)"
Currently, with RCU_BOOST disabled, I get no failures when forcing
rcutorture to test RCU boost priority inversion. The reason seems to be
that we don't check for failures if the callback never ran at all for
the duration of the boost-test loop.
Further, the 'rtb' and 'rtbf' counters seem to be used inconsistently.
'rtb' is incremented at the start of each test and 'rtbf' is incremented
per-cpu on each failure of call_rcu. So its possible 'rtbf' > 'rtb'.
To test the boost with rcutorture, I did following on a 4-CPU x86 machine:
modprobe rcutorture test_boost=2
sleep 20
rmmod rcutorture
With patch:
rtbf: 8 rtb: 12
Without patch:
rtbf: 0 rtb: 2
In summary this patch:
- Increments failed and total test counters once per boost-test.
- Checks for failure cases correctly.
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/rcutorture.c | 45 +++--
1 file changed, 39 insertions(+), 6 deletions(-)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 00e06349d7bb..0040cc2b836b 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -799,6 +799,18 @@ static void rcu_torture_enable_rt_throttle(void)
old_rt_runtime = -1;
}
+static bool rcu_torture_boost_failed(unsigned long start, unsigned long end)
+{
+ if (end - start > test_boost_duration * HZ - HZ / 2) {
+ VERBOSE_TOROUT_STRING("rcu_torture_boost boosting failed");
+ n_rcu_torture_boost_failure++;
+
+ return true; /* failed */
+ }
+
+ return false; /* passed */
+}
+
static int rcu_torture_boost(void *arg)
{
unsigned long call_rcu_time;
@@ -819,6 +831,21 @@ static int rcu_torture_boost(void *arg)
init_rcu_head_on_stack(&rbi.rcu);
/* Each pass through the following loop does one boost-test cycle. */
do {
+ /* Track if the test failed already in this test interval? */
+ bool failed = false;
+
+ /* Increment n_rcu_torture_boosts once per boost-test */
+ while (!kthread_should_stop()) {
+ if (mutex_trylock(&boost_mutex)) {
+ n_rcu_torture_boosts++;
+ mutex_unlock(&boost_mutex);
+ break;
+ }
+ schedule_timeout_uninterruptible(1);
+ }
+ if (kthread_should_stop())
+ goto checkwait;
+
/* Wait for the next test interval. */
oldstarttime = boost_starttime;
while (ULONG_CMP_LT(jiffies, oldstarttime)) {
@@ -837,11 +864,10 @@ static int rcu_torture_boost(void *arg)
/* RCU core before ->inflight = 1. */
smp_store_release(&rbi.inflight, 1);
call_rcu(&rbi.rcu, rcu_torture_boost_cb);
- if (jiffies - call_rcu_time >
-test_boost_duration * HZ - HZ / 2) {
-
VERBOSE_TOROUT_STRING("rcu_torture_boost boosting failed");
- n_rcu_torture_boost_failure++;
- }
+ /* Check if the boost test failed */
+ failed = failed ||
+rcu_torture_boost_failed(call_rcu_time,
+jiffies);
call_rcu_time = jiffies;
}
stutter_wait("rcu_torture_boost");
@@ -849,6 +875,14 @@ static int rcu_torture_boost(void *arg)
goto checkwait;
}
+ /*
+* If boost never happened, then inflight will always be 1, in
+* this case the boost check would never happen in the above
+* loop so do another one here.
+*/
+ if (!failed && smp_load_acquire(&rbi.inflight))
+ rcu_torture_boost_failed(call_rcu_time, jiffies);
+
/*
* Set the start time of the next test interval.
* Yes, this is vulnerable to long delays, but such
@@ -861,7 +895,6 @@ static int rcu_torture_boost(void *arg)
if (mutex_trylock(&boost_mutex)) {
boost_starttime = jiffies +
test_boost_interval * HZ;
- n_rcu_torture_boosts++;
mutex_unlock(&boost_mutex);
break;
}
--
2.18.0.rc1.242.g61856ae69a-goog
Re: [PATCH] ASoC: audio-graph-card: add hp and mic detect gpios same as simple-card
Hi Katsuhiro-san
Thank you for your patch
> This patch adds headphone and microphone jack detection gpios as same
> as simple-card driver. This feature move into simple-card-utils from
> simple-card to avoid the duplicating code.
>
> Signed-off-by: Katsuhiro Suzuki
> ---
I think it can be 2 patches ?
1. move function from simple-card to simple-card-utils
2. use it from audio-graph-card
> +static int asoc_graph_soc_card_probe(struct snd_soc_card *card)
> +{
> + struct graph_card_data *priv = snd_soc_card_get_drvdata(card);
> + int ret;
> +
> + ret = asoc_simple_card_init_hp(card, &priv->hp_jack, NULL);
> + if (ret < 0)
> + return ret;
> +
> + ret = asoc_simple_card_init_mic(card, &priv->mic_jack, NULL);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> static int asoc_graph_card_probe(struct platform_device *pdev)
> {
> struct graph_card_data *priv;
> @@ -319,6 +336,7 @@ static int asoc_graph_card_probe(struct platform_device
> *pdev)
> card->num_links = num;
> card->dapm_widgets = asoc_graph_card_dapm_widgets;
> card->num_dapm_widgets = ARRAY_SIZE(asoc_graph_card_dapm_widgets);
> + card->probe = asoc_graph_soc_card_probe;
Current simple-card is calling init_hp/init_mic from
asoc_simple_card_dai_init(), and audio-graph-card has
asoc_graph_card_dai_init().
simple/audio card are doing samethings in different style.
Thus, I want to synchronized whole simple/audio card.
Best regards
---
Kuninori Morimoto
Re: [PATCH v3] mm: fix race between kmem_cache destroy, create and deactivate
On Sun, Jun 10, 2018 at 10:40:17AM -0700, Shakeel Butt wrote: > On Sun, Jun 10, 2018 at 9:32 AM Paul E. McKenney > wrote: > > > > On Sun, Jun 10, 2018 at 07:52:50AM -0700, Shakeel Butt wrote: > > > On Sat, Jun 9, 2018 at 3:20 AM Vladimir Davydov > > > wrote: > > > > > > > > On Tue, May 29, 2018 at 05:12:04PM -0700, Shakeel Butt wrote: > > > > > The memcg kmem cache creation and deactivation (SLUB only) is > > > > > asynchronous. If a root kmem cache is destroyed whose memcg cache is > > > > > in > > > > > the process of creation or deactivation, the kernel may crash. > > > > > > > > > > Example of one such crash: > > > > > general protection fault: [#1] SMP PTI > > > > > CPU: 1 PID: 1721 Comm: kworker/14:1 Not tainted 4.17.0-smp > > > > > ... > > > > > Workqueue: memcg_kmem_cache kmemcg_deactivate_workfn > > > > > RIP: 0010:has_cpu_slab > > > > > ... > > > > > Call Trace: > > > > > ? on_each_cpu_cond > > > > > __kmem_cache_shrink > > > > > kmemcg_cache_deact_after_rcu > > > > > kmemcg_deactivate_workfn > > > > > process_one_work > > > > > worker_thread > > > > > kthread > > > > > ret_from_fork+0x35/0x40 > > > > > > > > > > To fix this race, on root kmem cache destruction, mark the cache as > > > > > dying and flush the workqueue used for memcg kmem cache creation and > > > > > deactivation. > > > > > > > > > @@ -845,6 +862,8 @@ void kmem_cache_destroy(struct kmem_cache *s) > > > > > if (unlikely(!s)) > > > > > return; > > > > > > > > > > + flush_memcg_workqueue(s); > > > > > + > > > > > > > > This should definitely help against async memcg_kmem_cache_create(), > > > > but I'm afraid it doesn't eliminate the race with async destruction, > > > > unfortunately, because the latter uses call_rcu_sched(): > > > > > > > > memcg_deactivate_kmem_caches > > > >__kmem_cache_deactivate > > > > slab_deactivate_memcg_cache_rcu_sched > > > > call_rcu_sched > > > > kmem_cache_destroy > > > > shutdown_memcg_caches > > > > shutdown_cache > > > > memcg_deactivate_rcufn > > > > > > > > > > > > Can we somehow flush those pending rcu requests? > > > > > > You are right and thanks for catching that. Now I am wondering if > > > synchronize_sched() just before flush_workqueue() should be enough. > > > Otherwise we might have to replace call_sched_rcu with > > > synchronize_sched() in kmemcg_deactivate_workfn which I would not > > > prefer as that would holdup the kmem_cache workqueue. > > > > > > +Paul > > > > > > Paul, we have a situation something similar to the following pseudo code. > > > > > > CPU0: > > > lock(l) > > > if (!flag) > > > call_rcu_sched(callback); > > > unlock(l) > > > -- > > > CPU1: > > > lock(l) > > > flag = true > > > unlock(l) > > > synchronize_sched() > > > -- > > > > > > If CPU0 has called already called call_rchu_sched(callback) then later > > > if CPU1 calls synchronize_sched(). Is there any guarantee that on > > > return from synchronize_sched(), the rcu callback scheduled by CPU0 > > > has already been executed? > > > > No. There is no such guarantee. > > > > You instead want rcu_barrier_sched(), which waits for the callbacks from > > all prior invocations of call_rcu_sched() to be invoked. > > > > Please note that synchronize_sched() is -not- sufficient. It is only > > guaranteed to wait for a grace period, not necessarily for all prior > > callbacks. This goes both directions because if there are no callbacks > > in the system, then rcu_barrier_sched() is within its rights to return > > immediately. > > > > So please make sure you use each of synchronize_sched() and > > rcu_barrier_sched() to do the job that it was intended to do! ;-) > > > > If your lock(l) is shorthand for spin_lock(&l), it looks to me like you > > actually only need rcu_barrier_sched(): > > > > CPU0: > > spin_lock(&l); > > if (!flag) > > call_rcu_sched(callback); > > spin_unlock(&l); > > > > CPU1: > > spin_lock(&l); > > flag = true; > > spin_unlock(&l); > > /* At this point, no more callbacks will be registered. */ > > rcu_barrier_sched(); > > /* At this point, all registered callbacks will have been invoked. > > */ > > > > On the other hand, if your "lock(l)" was instead shorthand for > > rcu_read_lock_sched(), then you need -both- synchronize_sched() -and- > > rcu_barrier(). And even then, you will be broken in -rt kernels. > > (Which might or might not be a concern, depending on whether your code > > matters to -rt kernels. > > > > Make sense? > > Thanks a lot, that was really helpful. The lock is actually > mutex_lock. So, I think rcu_barrier_sched() should be sufficient. Yes, with either spin_lock() or mutex_lock(), this should wo
tools/include/asm-generic/bitsperlong.h:14:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
Hi Alexei, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 1aaccb5fa0eac996adde53538ca4b87a0b229ab7 commit: 819dd92b9c0bc7bce9097d8c1f14240f471bb386 bpfilter: switch to CC from HOSTCC date: 5 days ago config: alpha-allyesconfig (attached as .config) compiler: alpha-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 819dd92b9c0bc7bce9097d8c1f14240f471bb386 # save the attached .config to linux build tree make.cross ARCH=alpha All errors (new ones prefixed by >>): In file included from tools/include/uapi/asm/bitsperlong.h:17:0, from /usr/alpha-linux-gnu/include/asm-generic/int-l64.h:11, from /usr/alpha-linux-gnu/include/asm/types.h:12, from tools/include/linux/types.h:10, from ./include/uapi/linux/bpf.h:11, from net//bpfilter/main.c:9: >> tools/include/asm-generic/bitsperlong.h:14:2: error: #error Inconsistent >> word size. Check asm/bitsperlong.h #error Inconsistent word size. Check asm/bitsperlong.h ^ vim +14 tools/include/asm-generic/bitsperlong.h bb970707 Arnaldo Carvalho de Melo 2016-07-12 12 2a00f026 Arnaldo Carvalho de Melo 2016-07-13 13 #if BITS_PER_LONG != __BITS_PER_LONG bb970707 Arnaldo Carvalho de Melo 2016-07-12 @14 #error Inconsistent word size. Check asm/bitsperlong.h bb970707 Arnaldo Carvalho de Melo 2016-07-12 15 #endif bb970707 Arnaldo Carvalho de Melo 2016-07-12 16 :: The code at line 14 was first introduced by commit :: bb9707077b4ee5f77bc9939b057ff8a0d410296f tools: Copy the bitsperlong.h files from the kernel :: TO: Arnaldo Carvalho de Melo :: CC: Arnaldo Carvalho de Melo --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Bad MAINTAINERS patterns
Given various renames and removals, the MAINTAINERS
file patterns get out of sync with the actual files.
It'd be nice if the various maintainers could fix
these file patterns.
$ ./scripts/get_maintainer.pl --self-test=patterns
./MAINTAINERS:1733: warning: no file matchesF:
include/dt-bindings/clock/nuvoton,npcm7xx-clks.h
./MAINTAINERS:1958: warning: no file matchesF:
arch/arm/plat-samsung/s5p-dev-mfc.c
./MAINTAINERS:2056: warning: no file matchesF:
arch/arm64/boot/dts/marvell/berlin*
./MAINTAINERS:2435: warning: no file matchesF:
include/media/atmel-isi.h
./MAINTAINERS:2973: warning: no file matchesF:
arch/arm64/boot/dts/broadcom/ns2*
./MAINTAINERS:3082: warning: no file matchesF:
Documentation/sound/alsa/Bt87x.txt
./MAINTAINERS:3378: warning: no file matchesF:
Documentation/module-signing.txt
./MAINTAINERS:3800: warning: no file matchesF:
drivers/media/i2c/cs3308.h
./MAINTAINERS:3831: warning: no file matchesF: include/media/cx2341x*
./MAINTAINERS:3938: warning: no file matchesF:
include/uapi/scsi/cxlflash_ioctls.h
./MAINTAINERS:3981: warning: no file matchesF:
drivers/input/dlink-dir685-touchkeys.c
./MAINTAINERS:4516: warning: no file matchesF:
Documentation/devicetree/bindings/display/ili9225.txt
./MAINTAINERS:4602: warning: no file matchesF:
Documentation/devicetree/bindings/display/st7586.txt
./MAINTAINERS:4608: warning: no file matchesF:
Documentation/devicetree/bindings/display/st7735r.txt
./MAINTAINERS:4641: warning: no file matchesF:
Documentation/devicetree/bindings/video/
./MAINTAINERS:4686: warning: no file matchesF:
Documentation/devicetree/bindings/drm/atmel/
./MAINTAINERS:4717: warning: no file matchesF:
Documentation/devicetree/bindings/display/panel/nec,nl4827hc19_05b.txt
./MAINTAINERS:4827: warning: no file matchesF:
Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt
./MAINTAINERS:5635: warning: no file matchesF: Documentation/fpga/
./MAINTAINERS:5738: warning: no file matchesF:
Documentation/devicetree/bindings/powerpc/fsl/fman.txt
./MAINTAINERS:6144: warning: no file matchesF:
drivers/staging/greybus/fw-managament.c
./MAINTAINERS:6157: warning: no file matchesF:
drivers/staging/greybus/timesync.c
./MAINTAINERS:6158: warning: no file matchesF:
drivers/staging/greybus/timesync_platform.c
./MAINTAINERS:6504: warning: no file matchesF: Documentation/vm/hmm.txt
./MAINTAINERS:6796: warning: no file matchesF:
drivers/crypto/nx/nx_debugfs.h
./MAINTAINERS:6817: warning: no file matchesF:
arch/powerpc/include/uapi/asm/vas.h
./MAINTAINERS:6969: warning: no file matchesF:
Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
./MAINTAINERS:7031: warning: no file matchesF:
Documentation/devicetree/bindings/i2c/ina209.txt
./MAINTAINERS:7313: warning: no file matchesF:
arch/x86/include/asm/pmc_core.h
./MAINTAINERS:7404: warning: no file matchesF:
Documentation/trace/intel_th.txt
./MAINTAINERS:7428: warning: no file matchesF:
Documentation/devicetree/bindings/iio/gyroscope/inv,mpu3050.txt
./MAINTAINERS:7499: warning: no file matchesF: drivers/staging/ipx/
./MAINTAINERS:7951: warning: no file matchesF: include/linux/keyctl.h
./MAINTAINERS:8426: warning: no file matchesF:
arch/*/include/asm/mutex*.h
./MAINTAINERS:8572: warning: no file matchesF:
linux/platform_data/mv88e6xxx.h
./MAINTAINERS:8680: warning: no file matchesF: drivers/hwmon/max20751.c
./MAINTAINERS:8703: warning: no file matchesF:
Documentation/devicetree/bindings/i2c/max6697.txt
./MAINTAINERS:9083: warning: no file matchesF:
Documentation/devicetree/bindings/video/bridge/megachips-stdp-ge-b850v3-fw.txt
./MAINTAINERS:9151: warning: no file matchesF:
drivers/net/ethernet/mellanox/mlx5/core/en_ipsec/*
./MAINTAINERS:9152: warning: no file matchesF:
drivers/net/ethernet/mellanox/mlx5/core/ipsec*
./MAINTAINERS:9346: warning: no file matchesF:
devicetree/bindings/media/atmel-isc.txt
./MAINTAINERS:9462: warning: no file matchesF:
arch/mips/loongson64/*{2e/2f}*
./MAINTAINERS:9465: warning: no file matchesF: drivers/*/*/*loongson2*
./MAINTAINERS:9474: warning: no file matchesF: drivers/*/*loongson3*
./MAINTAINERS:9475: warning: no file matchesF: drivers/*/*/*loongson3*
./MAINTAINERS:9666: warning: no file matchesF:
Documentation/ABI/testing/mux/sysfs-class-mux*
./MAINTAINERS:9668: warning: no file matchesF:
include/linux/dt-bindings/mux/
./MAINTAINERS:9697: warning: no file matchesF:
Documentation/devicetree/bindings/display/mxsfb-drm.txt
./MAINTAINERS:9733: warning: no file matchesF: drivers/staging/ncpfs/
./MAINTAINERS:9768: warning: no file matchesF:
include/linux/syscalls.h:211:18: error: 'sys_mmap2' alias between functions of incompatible types 'long int(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigne
Hi Al,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 1aaccb5fa0eac996adde53538ca4b87a0b229ab7
commit: ee076e81fc14ca79334d02970cea66604f183a14 sparc: trivial conversions to
{COMPAT_,}SYSCALL_DEFINE()
date: 3 months ago
config: sparc-defconfig (attached as .config)
compiler: sparc-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ee076e81fc14ca79334d02970cea66604f183a14
# save the attached .config to linux build tree
make.cross ARCH=sparc
All errors (new ones prefixed by >>):
In file included from arch/sparc/kernel/sys_sparc_32.c:21:
>> include/linux/syscalls.h:211:18: error: 'sys_mmap2' alias between functions
>> of incompatible types 'long int(long unsigned int, long unsigned int, long
>> unsigned int, long unsigned int, long unsigned int, long unsigned int)'
>> and 'long int(long int, long int, long int, long int, long int, long
>> int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:201:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:101:1: note: in expansion of macro
'SYSCALL_DEFINE6'
SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
^~~
include/linux/syscalls.h:215:18: note: aliased declaration here
asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:201:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:101:1: note: in expansion of macro
'SYSCALL_DEFINE6'
SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
^~~
>> include/linux/syscalls.h:211:18: error: 'sys_getdomainname' alias between
>> functions of incompatible types 'long int(char *, int)' and 'long int(long
>> int, long int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:197:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:205:1: note: in expansion of macro
'SYSCALL_DEFINE2'
SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
^~~
include/linux/syscalls.h:215:18: note: aliased declaration here
asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:197:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:205:1: note: in expansion of macro
'SYSCALL_DEFINE2'
SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
^~~
include/linux/syscalls.h:211:18: error: 'sys_rt_sigaction' alias between
functions of incompatible types 'long int(int, const struct sigaction *,
struct sigaction *, void *, size_t)' {aka 'long int(int, const struct
sigaction *, struct sigaction *, void *, unsigned int)'} and 'long int(long
int, long int, long int, long int, long int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:200:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE5(name, ...) SYSCALL_DEFINEx(5, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:176:1: note: in expansion of macro
'SYSCALL_DEFINE5'
SYSCALL_DEFINE5(rt_sigaction,
Re: what trees/branches to test on syzbot
On Sun, Jun 10, 2018 at 08:11:05AM +0200, Dmitry Vyukov wrote: > > The set of trees where a crash happened is visible on dashboard, so > one can see if it's only linux-next or whole set of trees. Potentially > syzbot can act differently depending on this predicate, but I don't > see what should be the difference. However, this does not fully save > from falsely assessing bugs as linux-next-only just because they > happened few times and only on linux-next so far. So how about this, only report something as being a linux-next regression if (a) there is a reproducer, and (b) the reproducer does not trigger any kind of crash on mainline? > There is also a problem with rebasing of linux-next: reported commit > hashes do not make sense and we can forget about bisection. If there is a valid reproducer, bisection should simply be a matter ofu running and if we know the reproducer doesn't trigger on mainline, then the bisection should only require no more than 8-10 VM runs. For Linux-next, this would be *super* valuable. Reporting the commit ID and the one-line commit summary will be enough for most maintainers, since even if they are using a rewinding head, so long as the bisection can be done quickly enough (e.g., within a few days), it will still be in their git repository. And if you have a reproducer, then once it's identified as a linux-next reproducer with a guilty commit, that can be confirmed by either (a) seeing if you can revert the commit and if it makes the problem go away, or (b) figure out which subsystem git tree the commit was introduced via, and then verify that the reproducer triggers on the tip of the subsystem git tree. All of this will require development effort, so I suspect it's not something we'll see from syzbot tomorrow --- but it's not *impossible*. I think though that sending e-mail about a linux-next syzbot crash if there is a reproducer and the reproducer doesn't trigger a crash on mainline should be really simple to implement, and it would add huge value without spamming the subsystem maintainers. - Ted
Re: [PATCH v3 9/9] x86: jump-labels: use macros instead of inline assembly
On June 10, 2018 7:19:11 AM PDT, Nadav Amit wrote:
>Use assembly macros for jump-labels and call them from inline assembly.
>This not only makes the code more readable, but also improves
>compilation decision, specifically inline decisions which GCC base on
>the number of new lines in inline assembly.
>
>As a result the code size is slightly increased.
>
> text data bss dec hex filename
>18163528 10226300 2957312 31347140 1de51c4 ./vmlinux before
>18163608 10227348 2957312 31348268 1de562c ./vmlinux after (+1128)
>
>And functions such as intel_pstate_adjust_policy_max(),
>kvm_cpu_accept_dm_intr(), kvm_register_read() are inlined.
>
>Cc: Thomas Gleixner
>Cc: Ingo Molnar
>Cc: "H. Peter Anvin"
>Cc: x...@kernel.org
>Cc: Greg Kroah-Hartman
>Cc: Kate Stewart
>Cc: Philippe Ombredanne
>
>Signed-off-by: Nadav Amit
>---
> arch/x86/include/asm/jump_label.h | 65 ++-
> arch/x86/kernel/macros.S | 1 +
> 2 files changed, 39 insertions(+), 27 deletions(-)
>
>diff --git a/arch/x86/include/asm/jump_label.h
>b/arch/x86/include/asm/jump_label.h
>index 8c0de4282659..ea0633a41122 100644
>--- a/arch/x86/include/asm/jump_label.h
>+++ b/arch/x86/include/asm/jump_label.h
>@@ -2,19 +2,6 @@
> #ifndef _ASM_X86_JUMP_LABEL_H
> #define _ASM_X86_JUMP_LABEL_H
>
>-#ifndef HAVE_JUMP_LABEL
>-/*
>- * For better or for worse, if jump labels (the gcc extension) are
>missing,
>- * then the entire static branch patching infrastructure is compiled
>out.
>- * If that happens, the code in here will malfunction. Raise a
>compiler
>- * error instead.
>- *
>- * In theory, jump labels and the static branch patching
>infrastructure
>- * could be decoupled to fix this.
>- */
>-#error asm/jump_label.h included on a non-jump-label kernel
>-#endif
>-
> #define JUMP_LABEL_NOP_SIZE 5
>
> #ifdef CONFIG_X86_64
>@@ -28,18 +15,27 @@
>
> #ifndef __ASSEMBLY__
>
>+#ifndef HAVE_JUMP_LABEL
>+/*
>+ * For better or for worse, if jump labels (the gcc extension) are
>missing,
>+ * then the entire static branch patching infrastructure is compiled
>out.
>+ * If that happens, the code in here will malfunction. Raise a
>compiler
>+ * error instead.
>+ *
>+ * In theory, jump labels and the static branch patching
>infrastructure
>+ * could be decoupled to fix this.
>+ */
>+#error asm/jump_label.h included on a non-jump-label kernel
>+#endif
>+
> #include
> #include
>
>static __always_inline bool arch_static_branch(struct static_key *key,
>bool branch)
> {
>- asm_volatile_goto("1:"
>- ".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t"
>- ".pushsection __jump_table, \"aw\" \n\t"
>- _ASM_ALIGN "\n\t"
>- _ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t"
>- ".popsection \n\t"
>- : : "i" (key), "i" (branch) : : l_yes);
>+ asm_volatile_goto("STATIC_BRANCH_GOTO l_yes=\"%l[l_yes]\" key=\"%c0\"
>"
>+"branch=\"%c1\""
>+ : : "i" (key), "i" (branch) : : l_yes);
>
> return false;
> l_yes:
>@@ -48,13 +44,8 @@ static __always_inline bool
>arch_static_branch(struct static_key *key, bool bran
>
>static __always_inline bool arch_static_branch_jump(struct static_key
>*key, bool branch)
> {
>- asm_volatile_goto("1:"
>- ".byte 0xe9\n\t .long %l[l_yes] - 2f\n\t"
>- "2:\n\t"
>- ".pushsection __jump_table, \"aw\" \n\t"
>- _ASM_ALIGN "\n\t"
>- _ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t"
>- ".popsection \n\t"
>+ asm_volatile_goto("STATIC_BRANCH_JUMP_GOTO l_yes=\"%l[l_yes]\"
>key=\"%c0\" "
>+"branch=\"%c1\""
> : : "i" (key), "i" (branch) : : l_yes);
>
> return false;
>@@ -108,6 +99,26 @@ struct jump_entry {
> .popsection
> .endm
>
>+.macro STATIC_BRANCH_GOTO l_yes:req key:req branch:req
>+1:
>+ .byte STATIC_KEY_INIT_NOP
>+ .pushsection __jump_table, "aw"
>+ _ASM_ALIGN
>+ _ASM_PTR 1b, \l_yes, \key + \branch
>+ .popsection
>+.endm
>+
>+.macro STATIC_BRANCH_JUMP_GOTO l_yes:req key:req branch:req
>+1:
>+ .byte 0xe9
>+ .long \l_yes - 2f
>+2:
>+ .pushsection __jump_table, "aw"
>+ _ASM_ALIGN
>+ _ASM_PTR 1b, \l_yes, \key + \branch
>+ .popsection
>+.endm
>+
> #endif/* __ASSEMBLY__ */
>
> #endif
>diff --git a/arch/x86/kernel/macros.S b/arch/x86/kernel/macros.S
>index bf8b9c93e255..161c95059044 100644
>--- a/arch/x86/kernel/macros.S
>+++ b/arch/x86/kernel/macros.S
>@@ -13,3 +13,4 @@
> #include
> #include
> #include
>+#include
If the code size increases, do you have any metrics for improvement?
That being said, I do like the readability improvements and the ability to use
gas macros in assembly as opposed to cpp macros wrapped in different ways for C
and assembly.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
[PATCH] hid: intel_ish-hid: ipc: register more pm callbacks to support hibernation
From: Even Xu
Current ish driver only register resume/suspend PM callbacks which
don't support hibernation (suspend to disk). Now use the
SIMPLE_DEV_PM_OPS() MACRO instead of struct dev_pm_ops directly.
The suspend and resume functions will now be used for both suspend
to RAM and hibernation.
If power management is disable, SIMPLE_DEV_PM_OPS will do nothing,
the suspend and resume related functions won't be used, so mark them
as __maybe_unused to clarify that this is intended behavior, and
remove #ifdefs for power management.
Signed-off-by: Even Xu
Acked-by: Srinivas Pandruvada
---
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
index 582e449be9fe..a2c53ea3b5ed 100644
--- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
+++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
@@ -205,8 +205,7 @@ static void ish_remove(struct pci_dev *pdev)
kfree(ishtp_dev);
}
-#ifdef CONFIG_PM
-static struct device *ish_resume_device;
+static struct device __maybe_unused *ish_resume_device;
/* 50ms to get resume response */
#define WAIT_FOR_RESUME_ACK_MS 50
@@ -220,7 +219,7 @@ static struct device *ish_resume_device;
* in that case a simple resume message is enough, others we need
* a reset sequence.
*/
-static void ish_resume_handler(struct work_struct *work)
+static void __maybe_unused ish_resume_handler(struct work_struct *work)
{
struct pci_dev *pdev = to_pci_dev(ish_resume_device);
struct ishtp_device *dev = pci_get_drvdata(pdev);
@@ -262,7 +261,7 @@ static void ish_resume_handler(struct work_struct *work)
*
* Return: 0 to the pm core
*/
-static int ish_suspend(struct device *device)
+static int __maybe_unused ish_suspend(struct device *device)
{
struct pci_dev *pdev = to_pci_dev(device);
struct ishtp_device *dev = pci_get_drvdata(pdev);
@@ -288,7 +287,7 @@ static int ish_suspend(struct device *device)
return 0;
}
-static DECLARE_WORK(resume_work, ish_resume_handler);
+static __maybe_unused DECLARE_WORK(resume_work, ish_resume_handler);
/**
* ish_resume() - ISH resume callback
* @device:device pointer
@@ -297,7 +296,7 @@ static DECLARE_WORK(resume_work, ish_resume_handler);
*
* Return: 0 to the pm core
*/
-static int ish_resume(struct device *device)
+static int __maybe_unused ish_resume(struct device *device)
{
struct pci_dev *pdev = to_pci_dev(device);
struct ishtp_device *dev = pci_get_drvdata(pdev);
@@ -311,21 +310,14 @@ static int ish_resume(struct device *device)
return 0;
}
-static const struct dev_pm_ops ish_pm_ops = {
- .suspend = ish_suspend,
- .resume = ish_resume,
-};
-#define ISHTP_ISH_PM_OPS (&ish_pm_ops)
-#else
-#define ISHTP_ISH_PM_OPS NULL
-#endif /* CONFIG_PM */
+static SIMPLE_DEV_PM_OPS(ish_pm_ops, ish_suspend, ish_resume);
static struct pci_driver ish_driver = {
.name = KBUILD_MODNAME,
.id_table = ish_pci_tbl,
.probe = ish_probe,
.remove = ish_remove,
- .driver.pm = ISHTP_ISH_PM_OPS,
+ .driver.pm = &ish_pm_ops,
};
module_pci_driver(ish_driver);
--
2.13.6
perfmon trouble
On Sat, Jun 09, 2018 at 04:51:08PM +0100, Al Viro wrote:
> Stephane, could you comment on the situation in there? I realize that you
> hadn't touched that thing in more than a decade, but I've no idea who else
> might be familiar with that thing and it's very inconveniently special...
Having looked through that code... ouch. It tries to have munmap-on-close,
of all things. Which has interesting consequences; consider, for example,
fd = perfctl(-1, PFM_CREATE_CONTEXT, &blah, 1); // create a context
pid = fork();
if (!pid) {
execve("/usr/bin/something_suid", ...);
...
}
with something_suid(8) doing an explicit "close each descriptor past stdout"
loop.
PFM_CREATE_CONTEXT has created a context, mmapped its buffer (and stored
the address of that mapping in ctx->ctx_smpl_vaddr) and, having opened
an associated file, sticks it into descriptor table and returns the descriptor.
On fork/exec we have
* descriptor table copied to child
* all mappings copied to child and then destroyed by execve
* execve ends up with the new binary (and libraries, etc.) mmapped
(in child)
Now, our careful suid-root binary does close(2) on its copy of descriptor.
pfm_flush() is called. ctx->task != current, so we proceed to
/*
* remove virtual mapping, if any, for the calling task.
* cannot reset ctx field until last user is calling close().
*
* ctx_smpl_vaddr must never be cleared because it is needed
* by every task with access to the context
*
* When called from do_exit(), the mm context is gone already, therefore
* mm is NULL, i.e., the VMA is already gone and we do not have to
* do anything here
*/
if (ctx->ctx_smpl_vaddr && current->mm) {
smpl_buf_vaddr = ctx->ctx_smpl_vaddr;
smpl_buf_size = ctx->ctx_smpl_size;
}
UNPROTECT_CTX(ctx, flags);
/*
* if there was a mapping, then we systematically remove it
* at this point. Cannot be done inside critical section
* because some VM function reenables interrupts.
*
*/
if (smpl_buf_vaddr) pfm_remove_smpl_mapping(smpl_buf_vaddr,
smpl_buf_size);
... with the last call doing vm_munmap() on the area in question. In the
address space of that suid-root binary, taking out whatever *it* had mapped
at that address range...
I wouldn't be surprised if that turned out to be realistically exploitable ;-/
Is there any documentation of that thing's semantics? perfmonctl(2) doesn't
mention the mapping at all and link to HP site in the arch/ia64/kernel/perfmon.c
is 404-compliant. Playing with archive.org brings a sourceforget reference,
but I hadn't been able to find anything ia64-related docs in there...
Re: [PATCH] ASoC: audio-graph-card: add hp and mic detect gpios same as simple-card
Hello Morimoto-san,
Thank you for your reviewing.
> -Original Message-
> From: Kuninori Morimoto
> Sent: Monday, June 11, 2018 8:53 AM
> To: Suzuki, Katsuhiro
> Cc: Mark Brown ; alsa-de...@alsa-project.org; Masami
Hiramatsu
> ; Jassi Brar ;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] ASoC: audio-graph-card: add hp and mic detect gpios same
as
> simple-card
>
>
> Hi Katsuhiro-san
>
> Thank you for your patch
>
> > This patch adds headphone and microphone jack detection gpios as same
> > as simple-card driver. This feature move into simple-card-utils from
> > simple-card to avoid the duplicating code.
> >
> > Signed-off-by: Katsuhiro Suzuki
> > ---
>
> I think it can be 2 patches ?
> 1. move function from simple-card to simple-card-utils
> 2. use it from audio-graph-card
>
OK, I'll split this patch.
> > +static int asoc_graph_soc_card_probe(struct snd_soc_card *card)
> > +{
> > + struct graph_card_data *priv = snd_soc_card_get_drvdata(card);
> > + int ret;
> > +
> > + ret = asoc_simple_card_init_hp(card, &priv->hp_jack, NULL);
> > + if (ret < 0)
> > + return ret;
> > +
> > + ret = asoc_simple_card_init_mic(card, &priv->mic_jack, NULL);
> > + if (ret < 0)
> > + return ret;
> > +
> > + return 0;
> > +}
> > +
> > static int asoc_graph_card_probe(struct platform_device *pdev)
> > {
> > struct graph_card_data *priv;
> > @@ -319,6 +336,7 @@ static int asoc_graph_card_probe(struct platform_device
> *pdev)
> > card->num_links = num;
> > card->dapm_widgets = asoc_graph_card_dapm_widgets;
> > card->num_dapm_widgets = ARRAY_SIZE(asoc_graph_card_dapm_widgets);
> > + card->probe = asoc_graph_soc_card_probe;
>
> Current simple-card is calling init_hp/init_mic from
> asoc_simple_card_dai_init(), and audio-graph-card has
> asoc_graph_card_dai_init().
> simple/audio card are doing samethings in different style.
> Thus, I want to synchronized whole simple/audio card.
>
Indeed. I need to add more one patch.
1. move function from simple-card to simple-card-utils
2. change calling init_hp/mic from soc_dai_link.init() to
soc_card.probe()
3. use it from audio-graph-card
Regards,
--
Katsuhiro Suzuki
> Best regards
> ---
> Kuninori Morimoto
Re: [PATCH v4 1/2] power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats
On 9/06/2018 06:36, Brian Norris wrote:
This driver was originally submitted for the TI BQ20Z75 battery IC
(commit a7640bfa10c5 ("power_supply: Add driver for TI BQ20Z75 gas gauge
IC")) and later renamed to express generic SBS support. While it's
mostly true that this driver implemented a standard SBS command set, it
takes liberties with the REG_MANUFACTURER_DATA register. This register
is specified in the SBS spec, but it doesn't make any mention of what
its actual contents are.
We've sort of noticed this optionality previously, with commit
17c6d3979e5b ("sbs-battery: make writes to ManufacturerAccess
optional"), where we found that some batteries NAK writes to this
register.
What this really means is that so far, we've just been lucky that most
batteries have either been compatible with the TI chip, or else at least
haven't reported highly-unexpected values.
For instance, one battery I have here seems to report either 0x or
0x0100 to the MANUFACTURER_ACCESS_STATUS command -- while this seems to
match either Wake Up (bits[11:8] = b) or Normal Discharge
(bits[11:8] = 0001b) status for the TI part [1], they don't seem to
actually correspond to real states (for instance, I never see 0101b =
Charge, even when charging).
On other batteries, I'm getting apparently random data in return, which
means that occasionally, we interpret this as "battery not present" or
"battery is not healthy".
All in all, it seems to be a really bad idea to make assumptions about
REG_MANUFACTURER_DATA, unless we already know what battery we're using.
Therefore, this patch reimplements the "present" and "health" checks to
the following on most SBS batteries:
1. HEALTH: report "unknown" -- I couldn't find a standard SBS command
that gives us much useful here
2. PRESENT: just send a REG_STATUS command; if it succeeds, then the
battery is present
Also, we stop sending MANUFACTURER_ACCESS_SLEEP to non-TI parts. I have
no proof that this is useful and supported.
If someone explicitly provided a 'ti,bq20z75' compatible property, then
we continue to use the existing TI command behaviors, and we effectively
revert commit 17c6d3979e5b ("sbs-battery: make writes to
ManufacturerAccess optional") to again make these commands required.
[1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf
Signed-off-by: Brian Norris
Reviewed-by: Guenter Roeck
Acked-by: Rhyland Klein
Reviewed-by: Phil Reid
---
v2:
* don't stub out POWER_SUPPLY_PROP_PRESENT from sbs_data[]
* use if/else instead of switch/case
v3:
* pull 'return 0' out of if/else, to satisfy braindead tooling
v4:
* make ManufacturerAccess non-optional for TI parts again
---
drivers/power/supply/sbs-battery.c | 67 --
1 file changed, 54 insertions(+), 13 deletions(-)
diff --git a/drivers/power/supply/sbs-battery.c
b/drivers/power/supply/sbs-battery.c
index 83d7b4115857..8ba6abf584de 100644
--- a/drivers/power/supply/sbs-battery.c
+++ b/drivers/power/supply/sbs-battery.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -156,6 +157,9 @@ static enum power_supply_property sbs_properties[] = {
POWER_SUPPLY_PROP_MODEL_NAME
};
+/* Supports special manufacturer commands from TI BQ20Z75 IC. */
+#define SBS_FLAGS_TI_BQ20Z75 BIT(0)
+
struct sbs_info {
struct i2c_client *client;
struct power_supply *power_supply;
@@ -168,6 +172,7 @@ struct sbs_info {
u32 poll_retry_count;
struct delayed_work work;
struct mutexmode_lock;
+ u32 flags;
};
static char model_name[I2C_SMBUS_BLOCK_MAX + 1];
@@ -315,17 +320,41 @@ static int sbs_status_correct(struct i2c_client *client,
int *intval)
static int sbs_get_battery_presence_and_health(
struct i2c_client *client, enum power_supply_property psp,
union power_supply_propval *val)
+{
+ int ret;
+
+ if (psp == POWER_SUPPLY_PROP_PRESENT) {
+ /* Dummy command; if it succeeds, battery is present. */
+ ret = sbs_read_word_data(client, sbs_data[REG_STATUS].addr);
+ if (ret < 0)
+ val->intval = 0; /* battery disconnected */
+ else
+ val->intval = 1; /* battery present */
+ } else { /* POWER_SUPPLY_PROP_HEALTH */
+ /* SBS spec doesn't have a general health command. */
+ val->intval = POWER_SUPPLY_HEALTH_UNKNOWN;
+ }
+
+ return 0;
+}
+
+static int sbs_get_ti_battery_presence_and_health(
+ struct i2c_client *client, enum power_supply_property psp,
+ union power_supply_propval *val)
{
s32 ret;
/*
* Write to ManufacturerAccess with ManufacturerAccess command
-* and then read the status. Do not check for error on the write
-* since not all batteries im
[PATCH] linux/linkage.h: replace VMLINUX_SYMBOL_STR() with __stringify()
With the special case handling for Blackfin and Metag was removed by
commit 94e58e0ac312 ("export.h: remove code for prefixing symbols with
underscore"), VMLINUX_SYMBOL_STR() is now equivalent to __stringify().
Replace some remaining usages in to prepare for the
entire removal of VMLINUX_SYMBOL_STR().
Signed-off-by: Masahiro Yamada
---
include/linux/linkage.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index f68db9e..d7618c4 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -24,16 +24,16 @@
#ifndef cond_syscall
#define cond_syscall(x)asm(\
- ".weak " VMLINUX_SYMBOL_STR(x) "\n\t" \
- ".set " VMLINUX_SYMBOL_STR(x) "," \
-VMLINUX_SYMBOL_STR(sys_ni_syscall))
+ ".weak " __stringify(x) "\n\t" \
+ ".set " __stringify(x) "," \
+__stringify(sys_ni_syscall))
#endif
#ifndef SYSCALL_ALIAS
#define SYSCALL_ALIAS(alias, name) asm(\
- ".globl " VMLINUX_SYMBOL_STR(alias) "\n\t" \
- ".set " VMLINUX_SYMBOL_STR(alias) "," \
- VMLINUX_SYMBOL_STR(name))
+ ".globl " __stringify(alias) "\n\t" \
+ ".set " __stringify(alias) ","\
+ __stringify(name))
#endif
#define __page_aligned_data__section(.data..page_aligned)
__aligned(PAGE_SIZE)
--
2.7.4
Re: [alsa-devel] [PATCH] ASoC: audio-graph-card: add hp and mic detect gpios same as simple-card
Hello Morimoto-san,
Thank you for your reviewing.
On 06/11/18 08:52, Kuninori Morimoto wrote:
Hi Katsuhiro-san
Thank you for your patch
This patch adds headphone and microphone jack detection gpios as same
as simple-card driver. This feature move into simple-card-utils from
simple-card to avoid the duplicating code.
Signed-off-by: Katsuhiro Suzuki
---
I think it can be 2 patches ?
1. move function from simple-card to simple-card-utils
2. use it from audio-graph-card
OK, I'll split this patch.
+static int asoc_graph_soc_card_probe(struct snd_soc_card *card)
+{
+ struct graph_card_data *priv = snd_soc_card_get_drvdata(card);
+ int ret;
+
+ ret = asoc_simple_card_init_hp(card, &priv->hp_jack, NULL);
+ if (ret < 0)
+ return ret;
+
+ ret = asoc_simple_card_init_mic(card, &priv->mic_jack, NULL);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
static int asoc_graph_card_probe(struct platform_device *pdev)
{
struct graph_card_data *priv;
@@ -319,6 +336,7 @@ static int asoc_graph_card_probe(struct platform_device
*pdev)
card->num_links = num;
card->dapm_widgets = asoc_graph_card_dapm_widgets;
card->num_dapm_widgets = ARRAY_SIZE(asoc_graph_card_dapm_widgets);
+ card->probe = asoc_graph_soc_card_probe;
Current simple-card is calling init_hp/init_mic from
asoc_simple_card_dai_init(), and audio-graph-card has
asoc_graph_card_dai_init().
simple/audio card are doing samethings in different style.
Thus, I want to synchronized whole simple/audio card.
Ah, right. I need to add more one patch.
1. move function from simple-card to simple-card-utils
2. change calling init_hp/mic from soc_dai_link.init() to
soc_card.probe()
3. use it from audio-graph-card
Regards,
--
Katsuhiro Suzuki
Best regards
---
Kuninori Morimoto
___
Alsa-devel mailing list
alsa-de...@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
[PATCH] staging: clocking-wizard: prefer 'help' in Kconfig
Fixes the checkpatch warning: WARNING: prefer 'help' over '---help---' for new help texts +config COMMON_CLK_XLNX_CLKWZRD Signed-off-by: Kyle Buzby --- drivers/staging/clocking-wizard/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/clocking-wizard/Kconfig b/drivers/staging/clocking-wizard/Kconfig index 357af02c562c..aa57a5865556 100644 --- a/drivers/staging/clocking-wizard/Kconfig +++ b/drivers/staging/clocking-wizard/Kconfig @@ -5,5 +5,5 @@ config COMMON_CLK_XLNX_CLKWZRD tristate "Xilinx Clocking Wizard" depends on COMMON_CLK && OF - ---help--- + help Support for the Xilinx Clocking Wizard IP core clock generator. -- 2.17.1
Re: [PATCH 1/2] arm64: avoid alloc memory on offline node
Hi Michal,
On 2018/6/7 20:21, Michal Hocko wrote:
> On Thu 07-06-18 19:55:53, Hanjun Guo wrote:
>> On 2018/6/7 18:55, Michal Hocko wrote:
> [...]
>>> I am not sure I have the full context but pci_acpi_scan_root calls
>>> kzalloc_node(sizeof(*info), GFP_KERNEL, node)
>>> and that should fall back to whatever node that is online. Offline node
>>> shouldn't keep any pages behind. So there must be something else going
>>> on here and the patch is not the right way to handle it. What does
>>> faddr2line __alloc_pages_nodemask+0xf0 tells on this kernel?
>>
>> The whole context is:
>>
>> The system is booted with a NUMA node has no memory attaching to it
>> (memory-less NUMA node), also with NR_CPUS less than CPUs presented
>> in MADT, so CPUs on this memory-less node are not brought up, and
>> this NUMA node will not be online (but SRAT presents this NUMA node);
>>
>> Devices attaching to this NUMA node such as PCI host bridge still
>> return the valid NUMA node via _PXM, but actually that valid NUMA node
>> is not online which lead to this issue.
>
> But we should have other numa nodes on the zonelists so the allocator
> should fall back to other node. If the zonelist is not intiailized
> properly, though, then this can indeed show up as a problem. Knowing
> which exact place has blown up would help get a better picture...
>
I specific a non-exist node to allocate memory using kzalloc_node,
and got this following error message.
And I found out there is just a VM_WARN, but it does not prevent the memory
allocation continue.
This nid would be use to access NODE_DADA(nid), so if nid is invalid,
it would cause oops here.
459 /*
460 * Allocate pages, preferring the node given as nid. The node must be valid
and
461 * online. For more general interface, see alloc_pages_node().
462 */
463 static inline struct page *
464 __alloc_pages_node(int nid, gfp_t gfp_mask, unsigned int order)
465 {
466 VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
467 VM_WARN_ON(!node_online(nid));
468
469 return __alloc_pages(gfp_mask, order, nid);
470 }
471
(I wrote a ko, to allocate memory on a non-exist node using kzalloc_node().)
[ 120.061693] WARNING: CPU: 6 PID: 3966 at ./include/linux/gfp.h:467
allocate_slab+0x5fd/0x7e0
[ 120.070095] Modules linked in: bench(OE+) nls_utf8 isofs loop xt_CHECKSUM
iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4
nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c
ipt_REJECT nf_reject_ipv4 tun bridge stp llc ebtable_filter ebtables
ip6table_filter ip6_tables iptable_filter dm_mirror dm_region_hash dm_log
dm_mod intel_rapl skx_edac nfit vfat libnvdimm fat x86_pkg_temp_thermal
coretemp kvm_intel kvm irqbypass iTCO_wdt crct10dif_pclmul iTCO_vendor_support
crc32_pclmul ghash_clmulni_intel ses pcbc enclosure aesni_intel
scsi_transport_sas crypto_simd cryptd sg glue_helper ipmi_si joydev mei_me
i2c_i801 ipmi_devintf ioatdma shpchp pcspkr ipmi_msghandler mei dca i2c_core
lpc_ich acpi_power_meter nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables
[ 120.140992] ext4 mbcache jbd2 sd_mod crc32c_intel i40e ahci libahci
megaraid_sas libata
[ 120.149053] CPU: 6 PID: 3966 Comm: insmod Tainted: G OE
4.17.0-rc2-RHEL74+ #5
[ 120.157369] Hardware name: Huawei 2288H V5/BC11SPSCB0, BIOS 0.62 03/26/2018
[ 120.164303] RIP: 0010:allocate_slab+0x5fd/0x7e0
[ 120.168817] RSP: 0018:881196947af0 EFLAGS: 00010246
[ 120.174022] RAX: RBX: 014012c0 RCX: b4bc8173
[ 120.181126] RDX: RSI: 0008 RDI: 8817aefa7868
[ 120.188233] RBP: 014000c0 R08: ed02f5df4f0e R09: ed02f5df4f0e
[ 120.195338] R10: ed02f5df4f0d R11: 8817aefa786f R12: 0055
[ 120.202444] R13: 0003 R14: 880107c0f800 R15:
[ 120.209550] FS: 7f6935d8c740() GS:8817aef8()
knlGS:
[ 120.217606] CS: 0010 DS: ES: CR0: 80050033
[ 120.223330] CR2: 00c21b88 CR3: 001197fd0006 CR4: 007606e0
[ 120.230435] DR0: DR1: DR2:
[ 120.237541] DR3: DR6: fffe0ff0 DR7: 0400
[ 120.244646] PKRU: 5554
[ 120.247346] Call Trace:
[ 120.249791] ? __kasan_slab_free+0xff/0x150
[ 120.253960] ? mpidr_init+0x20/0x30 [bench]
[ 120.258129] new_slab+0x3d/0x90
[ 120.261262] ___slab_alloc+0x371/0x640
[ 120.265002] ? __wake_up_common+0x8a/0x150
[ 120.269085] ? mpidr_init+0x20/0x30 [bench]
[ 120.273254] ? mpidr_init+0x20/0x30 [bench]
[ 120.277423] __slab_alloc+0x40/0x66
[ 120.280901] kmem_cache_alloc_node_trace+0xbc/0x270
[ 120.285762] ? mpidr_init+0x20/0x30 [bench]
[ 120.289931] ? 0xc074
[ 120.293236] mpidr_init+0x20/0x30 [bench]
[ 120.297236] do_one_initcall+0x4b/0x1f5
[ 120.301062] ? do_init_module+0x22/0x233
[ 120.304972] ? kmem_cache_alloc_trace+0xf
[RFC PATCH] kbuild: clean-up passing KCOV compiler flags
Now that the compiler support for KCOV is computed in the Kconfig phase, expensive $(call cc-option,...) calls no longer exist in scripts/Makefile.kcov . It shouldn't hurt to include scripts/Makefile.kcov everytime Kbuild descends into a sub-directory. Also, move ugly stuff from Makefile.lib to Makefile.kcov . Signed-off-by: Masahiro Yamada --- My hope is to do likewise for gcov, kasan, ubsan. gcov, kcov, kasan, ubsan need per-file (or per-directory) flag addition or removal. Currently, scripts/Makefile.lib is cluttered to handle this. If this clean-up is achieved, scripts/Makefile.lib will look like this: -->8-- include-$(CONFIG_GCOV_KERNEL) += scripts/Makefile.gcov include-$(CONFIG_KCOV)+= scripts/Makefile.kcov include-$(CONFIG_KASAN) += scripts/Makefile.kasan include-$(CONFIG_UBSAN) += scripts/Makefile.ubsan include $(include-y) -->8-- I will not apply this until some more cleanups are done (hence, RFC). At least, scripts/Makefile.kasan is so complicated for now. Makefile | 1 - scripts/Makefile.kcov | 8 +++- scripts/Makefile.lib | 8 +++- 3 files changed, 6 insertions(+), 11 deletions(-) diff --git a/Makefile b/Makefile index 73f0bb2..c99ca82 100644 --- a/Makefile +++ b/Makefile @@ -669,7 +669,6 @@ KBUILD_CFLAGS += $(call cc-ifversion, -lt, 0409, \ # Tell gcc to never replace conditional load with a non-conditional one KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0) -include scripts/Makefile.kcov include scripts/Makefile.gcc-plugins ifdef CONFIG_READABLE_ASM diff --git a/scripts/Makefile.kcov b/scripts/Makefile.kcov index 3d61c4b..408b776 100644 --- a/scripts/Makefile.kcov +++ b/scripts/Makefile.kcov @@ -1,9 +1,7 @@ -ifdef CONFIG_KCOV - kcov-flags-$(CONFIG_CC_HAS_SANCOV_TRACE_PC)+= -fsanitize-coverage=trace-pc kcov-flags-$(CONFIG_KCOV_ENABLE_COMPARISONS) += -fsanitize-coverage=trace-cmp kcov-flags-$(CONFIG_GCC_PLUGIN_SANCOV) += -fplugin=$(objtree)/scripts/gcc-plugins/sancov_plugin.so -export CFLAGS_KCOV := $(kcov-flags-y) - -endif +_c_flags += $(if $(patsubst n%,, \ + $(KCOV_INSTRUMENT_$(basetarget).o)$(KCOV_INSTRUMENT)$(CONFIG_KCOV_INSTRUMENT_ALL)), \ + $(kcov-flags-y)) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 5af34a2b..f5bd1d3 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -126,11 +126,9 @@ _c_flags += $(if $(patsubst n%,, \ $(CFLAGS_UBSAN)) endif -ifeq ($(CONFIG_KCOV),y) -_c_flags += $(if $(patsubst n%,, \ - $(KCOV_INSTRUMENT_$(basetarget).o)$(KCOV_INSTRUMENT)$(CONFIG_KCOV_INSTRUMENT_ALL)), \ - $(CFLAGS_KCOV)) -endif +include-$(CONFIG_KCOV) += scripts/Makefile.kcov + +include $(include-y) # If building the kernel in a separate objtree expand all occurrences # of -Idir to -I$(srctree)/dir except for absolute paths (starting with '/'). -- 2.7.4
Re: [PATCH v3 9/9] x86: jump-labels: use macros instead of inline assembly
at 6:29 PM, h...@zytor.com wrote:
> On June 10, 2018 7:19:11 AM PDT, Nadav Amit wrote:
>> Use assembly macros for jump-labels and call them from inline assembly.
>> This not only makes the code more readable, but also improves
>> compilation decision, specifically inline decisions which GCC base on
>> the number of new lines in inline assembly.
>>
>> As a result the code size is slightly increased.
>>
>> text data bss dec hex filename
>> 18163528 10226300 2957312 31347140 1de51c4 ./vmlinux before
>> 18163608 10227348 2957312 31348268 1de562c ./vmlinux after (+1128)
>>
>> And functions such as intel_pstate_adjust_policy_max(),
>> kvm_cpu_accept_dm_intr(), kvm_register_read() are inlined.
>>
>> Cc: Thomas Gleixner
>> Cc: Ingo Molnar
>> Cc: "H. Peter Anvin"
>> Cc: x...@kernel.org
>> Cc: Greg Kroah-Hartman
>> Cc: Kate Stewart
>> Cc: Philippe Ombredanne
>>
>> Signed-off-by: Nadav Amit
>> ---
>> arch/x86/include/asm/jump_label.h | 65 ++-
>> arch/x86/kernel/macros.S | 1 +
>> 2 files changed, 39 insertions(+), 27 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/jump_label.h
>> b/arch/x86/include/asm/jump_label.h
>> index 8c0de4282659..ea0633a41122 100644
>> --- a/arch/x86/include/asm/jump_label.h
>> +++ b/arch/x86/include/asm/jump_label.h
>> @@ -2,19 +2,6 @@
>> #ifndef _ASM_X86_JUMP_LABEL_H
>> #define _ASM_X86_JUMP_LABEL_H
>>
>> -#ifndef HAVE_JUMP_LABEL
>> -/*
>> - * For better or for worse, if jump labels (the gcc extension) are
>> missing,
>> - * then the entire static branch patching infrastructure is compiled
>> out.
>> - * If that happens, the code in here will malfunction. Raise a
>> compiler
>> - * error instead.
>> - *
>> - * In theory, jump labels and the static branch patching
>> infrastructure
>> - * could be decoupled to fix this.
>> - */
>> -#error asm/jump_label.h included on a non-jump-label kernel
>> -#endif
>> -
>> #define JUMP_LABEL_NOP_SIZE 5
>>
>> #ifdef CONFIG_X86_64
>> @@ -28,18 +15,27 @@
>>
>> #ifndef __ASSEMBLY__
>>
>> +#ifndef HAVE_JUMP_LABEL
>> +/*
>> + * For better or for worse, if jump labels (the gcc extension) are
>> missing,
>> + * then the entire static branch patching infrastructure is compiled
>> out.
>> + * If that happens, the code in here will malfunction. Raise a
>> compiler
>> + * error instead.
>> + *
>> + * In theory, jump labels and the static branch patching
>> infrastructure
>> + * could be decoupled to fix this.
>> + */
>> +#error asm/jump_label.h included on a non-jump-label kernel
>> +#endif
>> +
>> #include
>> #include
>>
>> static __always_inline bool arch_static_branch(struct static_key *key,
>> bool branch)
>> {
>> -asm_volatile_goto("1:"
>> -".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t"
>> -".pushsection __jump_table, \"aw\" \n\t"
>> -_ASM_ALIGN "\n\t"
>> -_ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t"
>> -".popsection \n\t"
>> -: : "i" (key), "i" (branch) : : l_yes);
>> +asm_volatile_goto("STATIC_BRANCH_GOTO l_yes=\"%l[l_yes]\" key=\"%c0\"
>> "
>> + "branch=\"%c1\""
>> +: : "i" (key), "i" (branch) : : l_yes);
>>
>> return false;
>> l_yes:
>> @@ -48,13 +44,8 @@ static __always_inline bool
>> arch_static_branch(struct static_key *key, bool bran
>>
>> static __always_inline bool arch_static_branch_jump(struct static_key
>> *key, bool branch)
>> {
>> -asm_volatile_goto("1:"
>> -".byte 0xe9\n\t .long %l[l_yes] - 2f\n\t"
>> -"2:\n\t"
>> -".pushsection __jump_table, \"aw\" \n\t"
>> -_ASM_ALIGN "\n\t"
>> -_ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t"
>> -".popsection \n\t"
>> +asm_volatile_goto("STATIC_BRANCH_JUMP_GOTO l_yes=\"%l[l_yes]\"
>> key=\"%c0\" "
>> + "branch=\"%c1\""
>> : : "i" (key), "i" (branch) : : l_yes);
>>
>> return false;
>> @@ -108,6 +99,26 @@ struct jump_entry {
>> .popsection
>> .endm
>>
>> +.macro STATIC_BRANCH_GOTO l_yes:req key:req branch:req
>> +1:
>> +.byte STATIC_KEY_INIT_NOP
>> +.pushsection __jump_table, "aw"
>> +_ASM_ALIGN
>> +_ASM_PTR 1b, \l_yes, \key + \branch
>> +.popsection
>> +.endm
>> +
>> +.macro STATIC_BRANCH_JUMP_GOTO l_yes:req key:req branch:req
>> +1:
>> +.byte 0xe9
>> +.long \l_yes - 2f
>> +2:
>> +.pushsection __jump_table, "aw"
>> +_ASM_ALIGN
>> +_ASM_PTR 1b, \l_yes, \key + \branch
>> +.popsection
>> +.endm
>> +
>> #endif /* __ASSEMBLY__ */
>>
>> #endif
>> diff --git a/arch/x86/kernel/macros.S b/arch/x86/kernel/macros.S
>> index bf8b9c93e255..161c95059044 100644
>> --- a/arch/x86/kernel/macros.S
>> +++ b/arch/x86/kernel/macros.S
>> @@ -13,3 +13,4 @@
>> #include
>> #include
>> #include
>> +#include
>
> If the code size increases, do you have any metrics for improvement?
>
> That being said, I do like the readability improvements and the abi
Re: [PATCH 0/7] Uprobes: Support SDT markers having reference count (semaphore)
Hi Oleg,
On 06/08/2018 10:06 PM, Oleg Nesterov wrote:
> Hello,
>
> I am travelling till the end of the next week, can't read this version
> until I return. Just one question,
>
> On 06/06, Ravi Bangoria wrote:
>>
>> 1. One of the major reason was the deadlock between uprobe_lock and
>> mm->mmap inside trace_uprobe_mmap(). That deadlock was not easy to fix
>
> Could you remind what exactly was wrong?
>
> I can't find your previous email about this problem, but iirc you didn't
> explain the deadlock in details, just copied some traces from lockdep...
The deadlock is between mm->mmap_sem and uprobe_lock.
Some existing code path is taking these locks in following order:
uprobe_lock
event_mutex
uprobe->register_rwsem
dup_mmap_sem
mm->mmap_sem
I've introduced new function trace_uprobe_mmap() which gets called
from mmap_region() / vma_adjust() with mm->mmap_sem already acquired.
And it has to take uprobe_lock to loop over all trace_uprobes. i.e.
the sequence is:
mm->mmap_sem
uprobe_lock
Why it's difficult to resolve is because trace_uprobe_mmap() does
not have control over mm->mmap_sem.
Detailed trace from lockdep:
[ 499.258006] ==
[ 499.258205] WARNING: possible circular locking dependency detected
[ 499.258409] 4.17.0-rc3+ #76 Not tainted
[ 499.258528] --
[ 499.258731] perf/6744 is trying to acquire lock:
[ 499.258895] e4895f49 (uprobe_lock){+.+.}, at:
trace_uprobe_mmap+0x78/0x130
[ 499.259147]
[ 499.259147] but task is already holding lock:
[ 499.259349] 9ec93a76 (&mm->mmap_sem){}, at:
vm_mmap_pgoff+0xe0/0x160
[ 499.259597]
[ 499.259597] which lock already depends on the new lock.
[ 499.259597]
[ 499.259848]
[ 499.259848] the existing dependency chain (in reverse order) is:
[ 499.260086]
[ 499.260086] -> #4 (&mm->mmap_sem){}:
[ 499.260277]__lock_acquire+0x53c/0x910
[ 499.260442]lock_acquire+0xf4/0x2f0
[ 499.260595]down_write_killable+0x6c/0x150
[ 499.260764]copy_process.isra.34.part.35+0x1594/0x1be0
[ 499.260967]_do_fork+0xf8/0x910
[ 499.261090]ppc_clone+0x8/0xc
[ 499.261209]
[ 499.261209] -> #3 (&dup_mmap_sem){}:
[ 499.261378]__lock_acquire+0x53c/0x910
[ 499.261540]lock_acquire+0xf4/0x2f0
[ 499.261669]down_write+0x6c/0x110
[ 499.261793]percpu_down_write+0x48/0x140
[ 499.261954]register_for_each_vma+0x6c/0x2a0
[ 499.262116]uprobe_register+0x230/0x320
[ 499.262277]probe_event_enable+0x1cc/0x540
[ 499.262435]perf_trace_event_init+0x1e0/0x350
[ 499.262587]perf_trace_init+0xb0/0x110
[ 499.262750]perf_tp_event_init+0x38/0x90
[ 499.262910]perf_try_init_event+0x10c/0x150
[ 499.263075]perf_event_alloc+0xbb0/0xf10
[ 499.263235]sys_perf_event_open+0x2a8/0xdd0
[ 499.263396]system_call+0x58/0x6c
[ 499.263516]
[ 499.263516] -> #2 (&uprobe->register_rwsem){}:
[ 499.263723]__lock_acquire+0x53c/0x910
[ 499.263884]lock_acquire+0xf4/0x2f0
[ 499.264002]down_write+0x6c/0x110
[ 499.264118]uprobe_register+0x1ec/0x320
[ 499.264283]probe_event_enable+0x1cc/0x540
[ 499.264442]perf_trace_event_init+0x1e0/0x350
[ 499.264603]perf_trace_init+0xb0/0x110
[ 499.264766]perf_tp_event_init+0x38/0x90
[ 499.264930]perf_try_init_event+0x10c/0x150
[ 499.265092]perf_event_alloc+0xbb0/0xf10
[ 499.265261]sys_perf_event_open+0x2a8/0xdd0
[ 499.265424]system_call+0x58/0x6c
[ 499.265542]
[ 499.265542] -> #1 (event_mutex){+.+.}:
[ 499.265738]__lock_acquire+0x53c/0x910
[ 499.265896]lock_acquire+0xf4/0x2f0
[ 499.266019]__mutex_lock+0xa0/0xab0
[ 499.266142]trace_add_event_call+0x44/0x100
[ 499.266310]create_trace_uprobe+0x4a0/0x8b0
[ 499.266474]trace_run_command+0xa4/0xc0
[ 499.266631]trace_parse_run_command+0xe4/0x200
[ 499.266799]probes_write+0x20/0x40
[ 499.266922]__vfs_write+0x6c/0x240
[ 499.267041]vfs_write+0xd0/0x240
[ 499.267166]ksys_write+0x6c/0x110
[ 499.267295]system_call+0x58/0x6c
[ 499.267413]
[ 499.267413] -> #0 (uprobe_lock){+.+.}:
[ 499.267591]validate_chain.isra.34+0xbd0/0x1000
[ 499.267747]__lock_acquire+0x53c/0x910
[ 499.267917]lock_acquire+0xf4/0x2f0
[ 499.268048]__mutex_lock+0xa0/0xab0
[ 499.268170]trace_uprobe_mmap+0x78/0x130
[ 499.268335]uprobe_mmap+0x80/0x3b0
[ 499.268464]mmap_region+0x290/0x660
[ 499.268590]do_mmap+0x40c/0x500
[ 499.268718]vm_mmap_pgoff+0x114/0x160
[ 499.268870]ksys_mmap_pgoff+0xe8/0x2e0
[ 499.269034]sys_mmap+0x84/0xf0
[ 499.269161]system_call+0x58/0x6c
[ 499.269279]
[ 499.2
Re: [RESEND v2] dmaengine: pxa: add a default requestor policy
On 09-06-18, 14:43, Robert Jarzmik wrote: > Robert Jarzmik writes: > > > As what former drcmr -1 value meant, add a this as a default to each > > channel, ie. that by default no requestor line is used. > > > > This is specifically used for network drivers smc91x and smc911x, and > > needed for their port to slave maps. > > > > Cc: Arnd Bergmann > > Signed-off-by: Robert Jarzmik > > --- > > Since v1: changed -1 to U32_MAX > Hi Vinod, > > Could I have your ack on this so that I add this one to the dma slave map > serie > after the merge window is closed please ? Sorry I was thinking it would go thru dmaengine tree, please do indicate if that is not the case. Nevertheless Acked-by: Vinod Koul -- ~Vinod
Re: [PATCH 0/7] Uprobes: Support SDT markers having reference count (semaphore)
Hi Masami, >>> Hmm, it sounds simple... maybe we can increment refctr in >>> install_breakpoint/ >>> remove_breakpoint? >> >> Not really, it would be simpler if I can put it inside install_breakpoint(). >> Consider an mmap() case. Probed instruction resides in the text section >> whereas >> reference counter resides in the data section. These sections gets mapped >> using >> separate mmap() calls. So, when process mmaps the text section we will >> change the >> instruction, but section holding the reference counter may not have been >> mapped >> yet in the virtual memory. If so, we will fail to update the reference >> counter. > > Got it. > In such case, maybe we can hook the target page mmapped and do > install_breakpoint() > at that point. Since the instruction is protected by a refctr, unless mmap the > page on where the refctr is, the program doesn't reach the tracepoint. Is > that right? > You mean, when mmap(text) happens, save the target page somewhere and when mmap(data) happens, update both instruction and ref_ctr? This sounds feasible. Let me think on it. Thanks for suggestion, Ravi
Re: [PATCH 2/2] IB/mad: Use IDR for agent IDs
On Sun, Jun 10, 2018 at 02:30:27PM -0600, Jason Gunthorpe wrote: > On Sun, Jun 10, 2018 at 03:25:05PM +0300, Leon Romanovsky wrote: > > On Sun, Jun 10, 2018 at 03:43:05AM -0700, Matthew Wilcox wrote: > > > On Sun, Jun 10, 2018 at 09:30:28AM +0300, Leon Romanovsky wrote: > > > > 1. IBTA spec doesn't talk at all about the size of TransactionID, more > > > > on that in section "13.4.6.4 TRANSACTION ID USAGE", the specification > > > > says: "The contents of the TransactionID (TID) field are implementation- > > > > dependent. So let's don't call it mlx4 bug. > > > > > > I was loosely paraphrasing the original bug report; suggested rewording > > > of the comments gratefully accepted. > > > > Just replace "mlx4 bug" with something like "to comply with mlx4 > > implementation". > > Well, it is a bug. Blindly replacing the upper 8 bits of the TID in a > driver without accommodation from the core is totally, bonkers wrong. I provided cite from spec that says that TID can be whatever you want as long as you success to do it unique. > > The original concept was that the 1<<24 limit would come from the > driver and only mlx4 would have less than 1<<32, because only mlx4 > does this thing.. > > Thanks Matt, > Jason > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html signature.asc Description: PGP signature
[PATCH] media: tm6000: add error handling for dvb_register_adapter
When dvb_register_adapter fails, the lack of error-handling code may
cause unexpected results.
This patch adds error-handling code after calling dvb_register_adapter.
Signed-off-by: Zhouyang Jia
---
drivers/media/usb/tm6000/tm6000-dvb.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/media/usb/tm6000/tm6000-dvb.c
b/drivers/media/usb/tm6000/tm6000-dvb.c
index c811fc6..ff35d4b 100644
--- a/drivers/media/usb/tm6000/tm6000-dvb.c
+++ b/drivers/media/usb/tm6000/tm6000-dvb.c
@@ -266,6 +266,11 @@ static int register_dvb(struct tm6000_core *dev)
ret = dvb_register_adapter(&dvb->adapter, "Trident TVMaster 6000 DVB-T",
THIS_MODULE, &dev->udev->dev,
adapter_nr);
+ if (ret < 0) {
+ printk(KERN_ERR "tm6000: couldn't register the adater!\n");
+ goto err;
+ }
+
dvb->adapter.priv = dev;
if (dvb->frontend) {
--
2.7.4
Re: [PATCH 0/5] can: enable multi-queue for SocketCAN devices
Hi, On 07.06.2018 17:14, Jonas Mark (BT-FIR/ENG1) wrote: > Hi Andy, > >>> The functionality bases on an external peripheral chip named Companion. >>> It offers two CAN interfaces, each has 8 prioritized transmit FIFOs as >>> well as one receive FIFO. Besides CAN, undisclosed additional functions >>> can be accessed through the char device. >>> >>> A standard SPI interface with two additional lines for flow control is >>> used. The Companion chip is the SPI slave. >> >> Can remoteproc API be utilized here? > > So far I wasn't aware of the remoteproc API. It appears to me that is > limited to power on/off and loading firmware in an AMP scenario. Here, > the Companion has a fixed firmware in it. It must already be running > quickly after power-up, even before the boot loader. yes, remoteproc is not quite suitable for this task. > Does remoteproc also contain a communication framework? it is using VirtIO > Do you mean rpmsg? Here, I do not see how we could benefit from it. using same message format instead of inventing new one will be really good step: https://github.com/OpenAMP/open-amp/wiki/RPMsg-Messaging-Protocol (less code duplicating same functionality) Looks like every company trying to solve the same problem over and over again. We have point to point link between two systems. Each system has multiple functionalities/applications so we should be able to address this functionality. So we end to some thing with source address and destination address. In all protocols used for inter processor/chip communication, the difference is only the layout of 3 common fields: source, destination and size. In many cases the ISO/OSI layer model is badly broken and > Can you point me to an example where rpmsg is used over SPI? RPMsg is just transport layer, 5 or 6 wire SPI is in this case Physical layer with flow control support. Currently i'm not sure if VirtIO with queue support do make sense here. > Greetings, > Mark signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/2] IB/mad: Use IDR for agent IDs
On Mon, Jun 11, 2018 at 07:34:25AM +0300, Leon Romanovsky wrote: > On Sun, Jun 10, 2018 at 02:30:27PM -0600, Jason Gunthorpe wrote: > > On Sun, Jun 10, 2018 at 03:25:05PM +0300, Leon Romanovsky wrote: > > > On Sun, Jun 10, 2018 at 03:43:05AM -0700, Matthew Wilcox wrote: > > > > On Sun, Jun 10, 2018 at 09:30:28AM +0300, Leon Romanovsky wrote: > > > > > 1. IBTA spec doesn't talk at all about the size of TransactionID, more > > > > > on that in section "13.4.6.4 TRANSACTION ID USAGE", the specification > > > > > says: "The contents of the TransactionID (TID) field are > > > > > implementation- > > > > > dependent. So let's don't call it mlx4 bug. > > > > > > > > I was loosely paraphrasing the original bug report; suggested rewording > > > > of the comments gratefully accepted. > > > > > > Just replace "mlx4 bug" with something like "to comply with mlx4 > > > implementation". > > > > Well, it is a bug. Blindly replacing the upper 8 bits of the TID in a > > driver without accommodation from the core is totally, bonkers wrong. > > I provided cite from spec that says that TID can be whatever you want as > long as you success to do it unique. Er, the spec has nothing to do with this. In Linux the TID is made unique because the core code provides 32 bits that are unique and the user provides another 32 bits that are unique. The driver cannot change any of those bits without risking non-uniquenes, which is exactly the bug mlx4 created when it stepped outside its bounds and improperly overrode bits in the TID for its own internal use. Jason
[PATCH] optoe: driver to read/write SFP/QSFP EEPROMs
optoe is an i2c based driver that supports read/write access to all the pages (tables) of MSA standard SFP and similar devices (conforming to the SFF-8472 spec) and MSA standard QSFP and similar devices (conforming to the SFF-8436 spec). These devices provide identification, operational status and control registers via an EEPROM model. These devices support one or 3 fixed pages (128 bytes) of data, and one page that is selected via a page register on the first fixed page. Thus the driver's main task is to map these pages onto a simple linear address space for user space management applications. See the driver code for a detailed layout. EEPROM data is accessible via a bin_attribute file called 'eeprom', e.g. /sys/bus/i2c/devices/24-0050/eeprom. Signed-off-by: Don Bollinger --- Why should this driver be in the Linux kernel? SFP and QSFP devices plug into switches to convert electrical to optical signals and drive the optical signal over fiber optic cables. They provide status and control registers through an i2c interface similar to to other EEPROMS. However, they have a paging mechanism that is unique, which requires a different driver from (for example) at24. Various drivers have been developed for this purpose, none of them support both SFP and QSFP, provide both read and write access, and access all 256 architected pages. optoe does all of these. optoe has been adopted and is shipping to customers as a base module, available to all platforms (switches) and used by multiple vendors and platforms on both ONL (Open Network Linux) and SONiC (Microsoft's 'Software for Open Networking in the Cloud'). This patch has been built on the latest staging-testing kernel. It has built and tested with SFP and QSFP devices on an ARM platform with a 4.9 kernel, and an x86 switch with a 3.16 kernel. This patch should install and build clean on any kernel from 3.16 up to the latest (as of 6/10/2018). Documentation/misc-devices/optoe.txt | 56 ++ drivers/misc/eeprom/Kconfig | 18 + drivers/misc/eeprom/Makefile |1 + drivers/misc/eeprom/optoe.c | 1141 ++ 4 files changed, 1216 insertions(+) create mode 100644 Documentation/misc-devices/optoe.txt create mode 100644 drivers/misc/eeprom/optoe.c diff --git a/Documentation/misc-devices/optoe.txt b/Documentation/misc-devices/optoe.txt new file mode 100644 index ..496134940147 --- /dev/null +++ b/Documentation/misc-devices/optoe.txt @@ -0,0 +1,56 @@ +optoe driver + +Author Don Bollinger (d...@thebollingers.org) + +Optoe is an i2c based driver that supports read/write access to all +the pages (tables) of MSA standard SFP and similar devices (conforming +to the SFF-8472 spec) and MSA standard QSFP and similar devices +(conforming to the SFF-8436 spec). + +i2c based optoelectronic transceivers (SPF, QSFP, etc) provide identification, +operational status, and control registers via an EEPROM model. Unlike the +EEPROMs that at24 supports, these devices access data beyond byte 256 via +a page select register, which must be managed by the driver. See the driver +code for a detailed explanation of how the linear address space provided +by the driver maps to the paged address space provided by the devices. + +The EEPROM data is accessible via a bin_attribute file called 'eeprom', +e.g. /sys/bus/i2c/devices/24-0050/eeprom + +This driver also reports the port number for each device, via a sysfs +attribute: 'port_name'. This is a read/write attribute. It should be +explicitly set as part of system initialization, ideally at the same time +the device is instantiated. Write an appropriate port name (any string, up +to 19 characters) to initialize. If not initialized explicitly, all ports +will have the port_name of 'unitialized'. Alternatively, if the driver is +called with platform_data, the port_name will be read from eeprom_data->label +(if the EEPROM CLASS driver is configured) or from platform_data.port_name. + +This driver can be instantiated with 'new_device', per the convention +described in Documentation/i2c/instantiating-devices. It wants one of +two possible device identifiers. Use 'optoe1' to indicate this is a device +with just one i2c address (all QSFP type devices). Use 'optoe2' to indicate +this is a device with two i2c addresses (all SFP type devices). + +Example: +# echo optoe1 0x50 > /sys/bus/i2c/devices/i2c-64/new_device +# echo port54 > /sys/bus/i2c/devices/i2c-64/port_name + +This will add a QSFP type device to i2c bus i2c-64, and name it 'port54' + +Example: +# echo optoe2 0x50 > /sys/bus/i2c/devices/i2c-11/new_device +# echo port1 > /sys/bus/i2c/devices/i2c-11/port_name + +This will add an SFP type device to i2c bus i2c-11, and name it 'port1' + +The second parameter to new_device is an i2c address, and MUST be 0x50 for +this driver to work properly. This is part of the spec for these devices. +(It is not necessary to create a device at 0x51 for SFP type devices
