Re: [PATCH 2/5] mm/memory_hotplug: Create add/del_device_memory functions
On Wed, Oct 17, 2018 at 11:45:50AM +0200, David Hildenbrand wrote: > Here you go ;) > > Reviewed-by: David Hildenbrand thanks! > I'm planning to look into the other patches as well, but I'll be busy > with traveling and KVM forum the next 1.5 weeks. No need to hurry, this can wait. -- Oscar Salvador SUSE L3
[PATCH v3 2/2] selftests/memfd: Add tests for F_SEAL_FS_WRITE seal
Add tests to verify sealing memfds with the F_SEAL_FS_WRITE works as
expected.
Cc: dan...@google.com
Cc: minc...@kernel.org
Reviewed-by: John Stultz
Signed-off-by: Joel Fernandes (Google)
---
tools/testing/selftests/memfd/memfd_test.c | 74 ++
1 file changed, 74 insertions(+)
diff --git a/tools/testing/selftests/memfd/memfd_test.c
b/tools/testing/selftests/memfd/memfd_test.c
index 10baa1652fc2..32b207ca7372 100644
--- a/tools/testing/selftests/memfd/memfd_test.c
+++ b/tools/testing/selftests/memfd/memfd_test.c
@@ -692,6 +692,79 @@ static void test_seal_write(void)
close(fd);
}
+/*
+ * Test SEAL_FUTURE_WRITE
+ * Test whether SEAL_FUTURE_WRITE actually prevents modifications.
+ */
+static void test_seal_future_write(void)
+{
+ int fd;
+ void *p;
+
+ printf("%s SEAL-FUTURE-WRITE\n", memfd_str);
+
+ fd = mfd_assert_new("kern_memfd_seal_future_write",
+ mfd_def_size,
+ MFD_CLOEXEC | MFD_ALLOW_SEALING);
+
+ p = mfd_assert_mmap_shared(fd);
+
+ mfd_assert_has_seals(fd, 0);
+ /* Not adding grow/shrink seals makes the future write
+* seal fail to get added
+*/
+ mfd_fail_add_seals(fd, F_SEAL_FUTURE_WRITE);
+
+ mfd_assert_add_seals(fd, F_SEAL_GROW);
+ mfd_assert_has_seals(fd, F_SEAL_GROW);
+
+ /* Should still fail since shrink seal has
+* not yet been added
+*/
+ mfd_fail_add_seals(fd, F_SEAL_FUTURE_WRITE);
+
+ mfd_assert_add_seals(fd, F_SEAL_SHRINK);
+ mfd_assert_has_seals(fd, F_SEAL_GROW |
+F_SEAL_SHRINK);
+
+ /* Now should succeed, also verifies that the seal
+* could be added with an existing writable mmap
+*/
+ mfd_assert_add_seals(fd, F_SEAL_FUTURE_WRITE);
+ mfd_assert_has_seals(fd, F_SEAL_SHRINK |
+F_SEAL_GROW |
+F_SEAL_FUTURE_WRITE);
+
+ /* read should pass, writes should fail */
+ mfd_assert_read(fd);
+ mfd_fail_write(fd);
+
+ munmap(p, mfd_def_size);
+ close(fd);
+
+ /* Test adding all seals (grow, shrink, future write) at once */
+ fd = mfd_assert_new("kern_memfd_seal_future_write2",
+ mfd_def_size,
+ MFD_CLOEXEC | MFD_ALLOW_SEALING);
+
+ p = mfd_assert_mmap_shared(fd);
+
+ mfd_assert_has_seals(fd, 0);
+ mfd_assert_add_seals(fd, F_SEAL_SHRINK |
+F_SEAL_GROW |
+F_SEAL_FUTURE_WRITE);
+ mfd_assert_has_seals(fd, F_SEAL_SHRINK |
+F_SEAL_GROW |
+F_SEAL_FUTURE_WRITE);
+
+ /* read should pass, writes should fail */
+ mfd_assert_read(fd);
+ mfd_fail_write(fd);
+
+ munmap(p, mfd_def_size);
+ close(fd);
+}
+
/*
* Test SEAL_SHRINK
* Test whether SEAL_SHRINK actually prevents shrinking
@@ -945,6 +1018,7 @@ int main(int argc, char **argv)
test_basic();
test_seal_write();
+ test_seal_future_write();
test_seal_shrink();
test_seal_grow();
test_seal_resize();
--
2.19.1.331.ge82ca0e54c-goog
Attn: Sir
Attn: Sir, We have gone through your country’s investment profile and history and we are interested to invest in it, we will be willing to partner with you and invest a substantial amount of money in your company if you have an existing company or we can also partner with you to set up a new one, provided you have a substantial and complete feasibility study and a well prepared business plan on the business/company you will need us to partner with you. Our group is a major player in investment in the middle-east, Africa, Europe and the United States of America, we believe in pursuing a positive goal, in which your ideas can be enhanced potentially for mutual benefit. As we seek new frontier and opportunities, we look forward to partner with you. Your prompt reply will be most welcome. Best regards , May T. Lee. mayt@yandex.com
Re: [PATCH] Staging iio/adc: fixes parenthesis alignment
I feel like these are overly nit-picky... I understand that everyone is picky about different things. For example, I have a prefered style for error handling. So two days ago there was a new staging driver and it used label name like "goto kmalloc_failed;" and I looked until I found an error handling bug and then I said, "Here is a bug, plus your label names are bad." When people have bad style but it doesn't lead to bugs then I let them get away with it. regards, dan carpenter
[tip:perf/urgent] perf vendor events intel: Fix wrong filter_band* values for uncore events
Commit-ID: 94aafb74cee0002e2f2eb6dc5376f54d5951ab4d Gitweb: https://git.kernel.org/tip/94aafb74cee0002e2f2eb6dc5376f54d5951ab4d Author: Jiri Olsa AuthorDate: Wed, 10 Oct 2018 10:03:39 +0200 Committer: Arnaldo Carvalho de Melo CommitDate: Thu, 11 Oct 2018 11:13:23 -0300 perf vendor events intel: Fix wrong filter_band* values for uncore events Michael reported that he could not stat following event: $ perf stat -e unc_p_freq_ge_1200mhz_cycles -a -- ls event syntax error: '..e_1200mhz_cycles' \___ value too big for format, maximum is 255 Run 'perf list' for a list of valid events The event is unwrapped into: uncore_pcu/event=0xb,filter_band0=1200/ where filter_band0 format says it's one byte only: # cat uncore_pcu/format/filter_band0 config1:0-7 while JSON files specifies bigger number: "Filter": "filter_band0=1200", all the filter_band* formats show 1 byte width: # cat uncore_pcu/format/filter_band1 config1:8-15 # cat uncore_pcu/format/filter_band2 config1:16-23 # cat uncore_pcu/format/filter_band3 config1:24-31 The reason of the issue is that filter_band* values are supposed to be in 100Mhz units.. it's stated in the JSON help for the events, like: filter_band3=XXX, with XXX in 100Mhz units This patch divides the filter_band* values by 100, plus there's couple of changes that actually change the number completely, like: -"Filter": "edge=1,filter_band2=4000", +"Filter": "edge=1,filter_band2=30", Reported-by: Michael Petlan Signed-off-by: Jiri Olsa Acked-by: Andi Kleen Cc: Alexander Shishkin Cc: Kan Liang Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20181010080339.GB15790@krava Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/pmu-events/arch/x86/ivytown/uncore-power.json | 16 .../perf/pmu-events/arch/x86/jaketown/uncore-power.json | 16 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/tools/perf/pmu-events/arch/x86/ivytown/uncore-power.json b/tools/perf/pmu-events/arch/x86/ivytown/uncore-power.json index d40498f2cb1e..635c09fda1d9 100644 --- a/tools/perf/pmu-events/arch/x86/ivytown/uncore-power.json +++ b/tools/perf/pmu-events/arch/x86/ivytown/uncore-power.json @@ -188,7 +188,7 @@ "Counter": "0,1,2,3", "EventCode": "0xb", "EventName": "UNC_P_FREQ_GE_1200MHZ_CYCLES", -"Filter": "filter_band0=1200", +"Filter": "filter_band0=12", "MetricExpr": "(UNC_P_FREQ_GE_1200MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.", "MetricName": "freq_ge_1200mhz_cycles %", "PerPkg": "1", @@ -199,7 +199,7 @@ "Counter": "0,1,2,3", "EventCode": "0xc", "EventName": "UNC_P_FREQ_GE_2000MHZ_CYCLES", -"Filter": "filter_band1=2000", +"Filter": "filter_band1=20", "MetricExpr": "(UNC_P_FREQ_GE_2000MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.", "MetricName": "freq_ge_2000mhz_cycles %", "PerPkg": "1", @@ -210,7 +210,7 @@ "Counter": "0,1,2,3", "EventCode": "0xd", "EventName": "UNC_P_FREQ_GE_3000MHZ_CYCLES", -"Filter": "filter_band2=3000", +"Filter": "filter_band2=30", "MetricExpr": "(UNC_P_FREQ_GE_3000MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.", "MetricName": "freq_ge_3000mhz_cycles %", "PerPkg": "1", @@ -221,7 +221,7 @@ "Counter": "0,1,2,3", "EventCode": "0xe", "EventName": "UNC_P_FREQ_GE_4000MHZ_CYCLES", -"Filter": "filter_band3=4000", +"Filter": "filter_band3=40", "MetricExpr": "(UNC_P_FREQ_GE_4000MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.", "MetricName": "freq_ge_4000mhz_cycles %", "PerPkg": "1", @@ -232,7 +232,7 @@ "Counter": "0,1,2,3", "EventCode": "0xb", "EventName": "UNC_P_FREQ_GE_1200MHZ_TRANSITIONS", -"Filter": "edge=1,filter_band0=1200", +"Filter": "edge=1,filter_band0=12", "MetricExpr": "(UNC_P_FREQ_GE_1200MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.", "MetricName": "freq_ge_1200mhz_cycles %", "PerPkg": "1", @@ -243,7 +243,7 @@ "Counter": "0,1,2,3", "EventCode": "0xc", "EventName": "UNC_P_FREQ_GE_2000MHZ_TRANSITIONS", -"Filter": "edge=1,filter_band1=2000", +"Filter": "edge=1,filter_band1=20", "MetricExpr": "(UNC_P_FREQ_GE_2000MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.", "MetricName": "freq_ge_2000mhz_cycles %", "PerPkg": "1", @@ -254,7 +254,7 @@ "Counter": "0,1,2,3", "EventCode": "0xd", "EventName": "UNC_P_FREQ_GE_3000MHZ_TRANSITIONS", -"Filter": "edge=1,filter_band2=4000", +"Filter": "edge=1,filter_band2=30", "MetricExpr": "(UNC_P_FREQ_GE_3000MHZ_CYCLES / UNC_P_CLOCKTICKS) * 100.", "MetricName": "freq_ge_3000mhz_cycles %", "PerPkg": "1", @@ -265,7 +265,7 @@ "Counter":
[tip:perf/urgent] Revert "perf tools: Fix PMU term format max value calculation"
Commit-ID: 1b9caa10b31dda0866f4028e4bfb923fb6e4072f
Gitweb: https://git.kernel.org/tip/1b9caa10b31dda0866f4028e4bfb923fb6e4072f
Author: Jiri Olsa
AuthorDate: Wed, 3 Oct 2018 09:20:46 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 9 Oct 2018 10:48:55 -0300
Revert "perf tools: Fix PMU term format max value calculation"
This reverts commit ac0e2cd555373ae6f8f3a3ad3fbbf5b6d1e7.
Michael reported an issue with oversized terms values assignment
and I noticed there was actually a misunderstanding of the max
value check in the past.
The above commit's changelog says:
If bit 21 is set, there is parsing issues as below.
$ perf stat -a -e uncore_qpi_0/event=0x22,umask=0x8/
event syntax error: '..pi_0/event=0x22,umask=0x8/'
\___ value too big for format, maximum is
511
But there's no issue there, because the event value is distributed
along the value defined by the format. Even if the format defines
separated bit, the value is treated as a continual number, which
should follow the format definition.
In above case it's 9-bit value with last bit separated:
$ cat uncore_qpi_0/format/event
config:0-7,21
Hence the value 0x22 is correctly reported as format violation,
because it exceeds 9 bits. It should have been 0x102 instead, which
sets the 9th bit - the bit 21 of the format.
$ perf stat -vv -a -e uncore_qpi_0/event=0x102,umask=0x8/
Using CPUID GenuineIntel-6-2D
...
perf_event_attr:
type 10
size 112
config 0x200802
sample_type IDENTIFIER
...
Reported-by: Michael Petlan
Signed-off-by: Jiri Olsa
Cc: Alexander Shishkin
Cc: Andi Kleen
Cc: Kan Liang
Cc: Namhyung Kim
Cc: Peter Zijlstra
Fixes: ac0e2cd55537 ("perf tools: Fix PMU term format max value calculation")
Link: http://lkml.kernel.org/r/20181003072046.29276-1-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/pmu.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index afd68524ffa9..7799788f662f 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -930,13 +930,14 @@ static void pmu_format_value(unsigned long *format, __u64
value, __u64 *v,
static __u64 pmu_format_max_value(const unsigned long *format)
{
- __u64 w = 0;
- int fbit;
-
- for_each_set_bit(fbit, format, PERF_PMU_FORMAT_BITS)
- w |= (1ULL << fbit);
+ int w;
- return w;
+ w = bitmap_weight(format, PERF_PMU_FORMAT_BITS);
+ if (!w)
+ return 0;
+ if (w < 64)
+ return (1ULL << w) - 1;
+ return -1;
}
/*
Re: possible deadlock in ovl_copy_up_start
On Thu, Oct 18, 2018 at 7:48 AM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:c343db455eb3 Merge branch 'parisc-4.19-3' of git://git.ker..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=167d08ee40
> kernel config: https://syzkaller.appspot.com/x/.config?x=b3f55cb3dfcc6c33
> dashboard link: https://syzkaller.appspot.com/bug?extid=3ef5c0d1a5cb0b21e6be
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
Reproducer is simple:
link a non-copied-up file into a non-copied-up parent:
~/unionmount-testsuite# ./run --ov -s
~/unionmount-testsuite# ln /mnt/a/foo100 /mnt/a/dir100/
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+3ef5c0d1a5cb0b21e...@syzkaller.appspotmail.com
>
FYI, this is the fix:
diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
index 276914ae3c60..e1a55ecb7aba 100644
--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -663,6 +663,10 @@ static int ovl_link(struct dentry *old, struct
inode *newdir,
if (err)
goto out_drop_write;
+ err = ovl_copy_up(new->d_parent);
+ if (err)
+ goto out_drop_write;
+
if (ovl_is_metacopy_dentry(old)) {
err = ovl_set_redirect(old, false);
if (err)
> overlayfs: filesystem on './file0' not supported as upperdir
> XFS (loop3): unknown mount option [uid<].
>
> kobject: 'loop2' (ce85f3f9): kobject_uevent_env
>
> WARNING: possible recursive locking detected
> kobject: 'loop2' (ce85f3f9): fill_kobj_path: path
> = '/devices/virtual/block/loop2'
> 4.19.0-rc8+ #65 Not tainted
>
> syz-executor2/8184 is trying to acquire lock:
> d7157f3f (_i_lock_key[depth]){+.+.}, at:
> ovl_copy_up_start+0x9c/0x2e0 fs/overlayfs/util.c:528
>
> but task is already holding lock:
> 6f802695 (_i_lock_key[depth]){+.+.}, at:
> ovl_nlink_start+0xe0/0x350 fs/overlayfs/util.c:771
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
> CPU0
>
>lock(_i_lock_key[depth]);
>lock(_i_lock_key[depth]);
>
> *** DEADLOCK ***
>
Can someone tell me what the expected behavior of a nested
mutex_lock_interruptible(); ?
Why does the reproducer only warn and not really deadlock.
It is because that is considered the lesser evil?
and obviously, then inner unlock releases the outer lock?
Thanks,
Amir.
Re: [PATCH V2 5/5] Tools: hv: kvp: Fix a warning of buffer overflow with gcc 8.0.1
On Thu, Oct 18, 2018 at 05:09:32AM +, k...@linuxonhyperv.com wrote: > From: Dexuan Cui > > The patch fixes: > > hv_kvp_daemon.c: In function 'kvp_set_ip_info': > hv_kvp_daemon.c:1305:2: note: 'snprintf' output between 41 and 4136 bytes > into a destination of size 4096 > > The "(unsigned int)str_len" is to avoid: > > hv_kvp_daemon.c:1309:30: warning: comparison of integer expressions of > different signedness: 'int' and 'long unsigned int' [-Wsign-compare] > Ugh... Any tool with the most basic flow analysis would realize this was a false positive. We use at least three static analyzers which catch signedness bugs. Can we turn off GCC's warning on this until they improve it a bit? regards, dan carpenter
Re: [PATCH 4.14 000/109] 4.14.77-stable review
On 16/10/2018 18:04, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.77 release. > There are 109 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 Thu Oct 18 17:04:58 UTC 2018. > Anything received after that time might be too late. All tests are passing for Tegra ... Test results for stable-v4.14: 8 builds: 8 pass, 0 fail 16 boots: 16 pass, 0 fail 14 tests: 14 pass, 0 fail Linux version: 4.14.77-rc1-g3dbba66 Boards tested: tegra124-jetson-tk1, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04 Cheers Jon -- nvpublic
[PATCH] clocksource: imx-gpt: add support for ARM64
This patch allows building and compile-testing the i.MX
GPT driver also for ARM64. The delay_timer is only
supported on ARMv7.
Signed-off-by: Anson Huang
---
drivers/clocksource/Kconfig | 2 +-
drivers/clocksource/timer-imx-gpt.c | 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index a11f4ba..e519f1a 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -580,7 +580,7 @@ config H8300_TPU
config CLKSRC_IMX_GPT
bool "Clocksource using i.MX GPT" if COMPILE_TEST
- depends on ARM && CLKDEV_LOOKUP
+ depends on (ARM || ARM64) && CLKDEV_LOOKUP
select CLKSRC_MMIO
config CLKSRC_IMX_TPM
diff --git a/drivers/clocksource/timer-imx-gpt.c
b/drivers/clocksource/timer-imx-gpt.c
index 165fbbb..a3d6ccb 100644
--- a/drivers/clocksource/timer-imx-gpt.c
+++ b/drivers/clocksource/timer-imx-gpt.c
@@ -141,21 +141,25 @@ static u64 notrace mxc_read_sched_clock(void)
return sched_clock_reg ? readl_relaxed(sched_clock_reg) : 0;
}
+#if defined(CONFIG_ARM)
static struct delay_timer imx_delay_timer;
static unsigned long imx_read_current_timer(void)
{
return readl_relaxed(sched_clock_reg);
}
+#endif
static int __init mxc_clocksource_init(struct imx_timer *imxtm)
{
unsigned int c = clk_get_rate(imxtm->clk_per);
void __iomem *reg = imxtm->base + imxtm->gpt->reg_tcn;
+#if defined(CONFIG_ARM)
imx_delay_timer.read_current_timer = _read_current_timer;
imx_delay_timer.freq = c;
register_current_timer_delay(_delay_timer);
+#endif
sched_clock_reg = reg;
--
2.7.4
Re: [RFC PATCH] mm, proc: report PR_SET_THP_DISABLE in proc
On Wed 17-10-18 12:59:18, David Rientjes wrote: > On Wed, 17 Oct 2018, Michal Hocko wrote: > > > Do you know of any other userspace except your usecase? Is there > > anything fundamental that would prevent a proper API adoption for you? > > > > Yes, it would require us to go back in time and build patched binaries. I read that as there is a fundamental problem to update existing binaries. If that is the case then there surely is no way around it and another sad page in the screwed up APIs book we provide. But I was under impression that the SW stack which actually does the monitoring is under your controll. Moreover I was under impression that you do not use the current vanilla kernel so there is no need for an immediate change on your end. It is trivial to come up with a backward compatible way to check for the new flag (if it is not present then fallback to vma flags). I am sorry for pushing here but if this is just a matter of a _single_ user which _can_ be fixed with a reasonable effort then I would love to see the future api unscrewed. -- Michal Hocko SUSE Labs
linux-next: Tree for Oct 18
Hi all, News: I will not be doing linux-next releases next week. Unfortunately this will probably be the first week of the merge window. :-( Changes since 20181017: The kvm tree gained a conflict against Linus' tree. The kvm-arm tree gained a conflict against the kvm tree. The scsi-mkp tree gained a conflict against Linus' tree. The kselftest tree gained a conflict against the kvm tree. Non-merge commits (relative to Linus' tree): 11106 10089 files changed, 542121 insertions(+), 239599 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 291 trees (counting Linus' and 66 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (c343db455eb3 Merge branch 'parisc-4.19-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux) Merging fixes/master (eb81bfb224ce Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input) Merging kbuild-current/fixes (5318321d367c samples: disable CONFIG_SAMPLES for UML) Merging arc-current/for-curr (56d02dd9e794 ARC: IOC: panic if kernel was started with previously enabled IOC) Merging arm-current/fixes (3a58ac65e2d7 ARM: 8799/1: mm: fix pci_ioremap_io() offset check) Merging arm64-fixes/for-next/fixes (ca2b497253ad arm64: perf: Reject stand-alone CHAIN events for PMUv3) Merging m68k-current/for-linus (0986b16ab49b m68k/mac: Use correct PMU response format) Merging powerpc-fixes/fixes (ac1788cc7da4 powerpc/numa: Skip onlining a offline node in kdump path) Merging sparc/master (b955a910d7fd Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (0ac1077e3a54 sctp: get pr_assoc and pr_stream all status with SCTP_PR_SCTP_ALL instead) Merging bpf/master (bd8be2cf8b69 Merge branch 'nfp-fix-pedit-set-action-offloads') Merging ipsec/master (9d200fd1 xfrm: policy: use hlist rcu variants on insert) Merging netfilter/master (cb20f2d2c050 netfilter: xt_nat: fix DNAT target for shifted portmap ranges) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (3baafeffa48a iwlwifi: 1000: set the TFD queue size) Merging mac80211/master (8d0be26c781a mac80211_hwsim: fix module init error paths for netlink) Merging rdma-fixes/for-rc (a3671a4f973e RDMA/ucma: Fix Spectre v1 vulnerability) Merging sound-current/for-linus (709ae62e8e6d ALSA: hda/realtek - Cannot adjust speaker's volume on Dell XPS 27 7760) Merging sound-asoc-fixes/for-linus (98027961025e Merge branch 'asoc-4.19' into asoc-linus) Merging regmap-fixes/for-linus (7876320f8880 Linux 4.19-rc4) Merging regulator-fixes/for-linus (35a7f35ad1b1 Linux 4.19-rc8) Merging spi-fixes/for-linus (bc7a6ca6f446 Merge branch 'spi-4.19' into spi-linus) Merging pci-current/for-linus (2edab4df98d9 PCI: Expand the "PF" acronym in Kconfig help text) Merging driver-core.current/driver-core-linus (7876320f8880 Linux 4.19-rc4) Merging tty.current/tty-linus (202dc3cc10b4 serial: sh-sci: Fix receive on SCIFA/SCIFB variants with DMA) Merging usb.current/usb-linus (665c365a77fb USB: fix the usbfs flag sanitization for control transfers) Merging usb-gadget-fixes/fixes (d9707490077b usb: dwc2: Fix call location of
Re: [RFC PATCH 0/7] Introduce thermal pressure
On Thu, Oct 18, 2018 at 8:48 AM Ingo Molnar wrote: > > > * Thara Gopinath wrote: > > > On 10/16/2018 03:33 AM, Ingo Molnar wrote: > > > > > > * Thara Gopinath wrote: > > > > > Regarding testing, basic build, boot and sanity testing have been > > performed on hikey960 mainline kernel with debian file system. > > Further aobench (An occlusion renderer for benchmarking realworld > > floating point performance) showed the following results on hikey960 > > with debain. > > > > Result Standard > > Standard > > (Time secs) Error > > Deviation > > Hikey 960 - no thermal pressure applied 138.67 6.52 > > 11.52% > > Hikey 960 - thermal pressure applied 122.37 5.78 > > 11.57% > > >>> > > >>> Wow, +13% speedup, impressive! We definitely want this outcome. > > >>> > > >>> I'm wondering what happens if we do not track and decay the thermal > > >>> load at all at the PELT level, but instantaneously decrease/increase > > >>> effective CPU capacity in reaction to thermal events we receive from > > >>> the CPU. > > >> > > >> The problem with instantaneous update is that sometimes thermal events > > >> happen at a much faster pace than cpu_capacity is updated in the > > >> scheduler. This means that at the moment when scheduler uses the > > >> value, it might not be correct anymore. > > > > > > Let me offer a different interpretation: if we average throttling events > > > then we create a 'smooth' average of 'true CPU capacity' that doesn't > > > fluctuate much. This allows more stable yet asymmetric task placement if > > > the thermal characteristics of the different cores is different > > > (asymmetric). This, compared to instantaneous updates, would reduce > > > unnecessary task migrations between cores. > > > > > > Is that accurate? > > > > Yes. I think it is accurate. I will also add that if we don't average > > throttling events, we will miss the events that occur in between load > > balancing(LB) period. > > Yeah, so I'd definitely suggest to not integrate this averaging into > pelt.c in the fashion presented, because: > > - This couples your thermal throttling averaging to the PELT decay >half-time AFAICS, which would break the other user every time the >decay is changed/tuned. > > - The boolean flag that changes behavior in pelt.c is not particularly >clean either and complicates the code. > > - Instead maybe factor out a decaying average library into >kernel/sched/avg.h perhaps (if this truly improves the code), and use >those methods both in pelt.c and any future thermal.c - and maybe >other places where we do decaying averages. > > - But simple decaying averages are not that complex either, so I think >your original solution of open coding it is probably fine as well. > > Furthermore, any logic introduced by thermal.c and the resulting change > to load-balancing behavior would have to be in perfect sync with cpufreq > governor actions - one mechanism should not work against the other. Right, that really is required. > The only long term maintainable solution is to move all high level > cpufreq logic and policy handling code into kernel/sched/cpufreq*.c, > which has been done to a fair degree already in the past ~2 years - but > it's unclear to me to what extent this is true for thermal throttling > policy currently: there might be more governor surgery and code > reshuffling required? It doesn't cover thermal management directly ATM. The EAS work kind of hopes to make a connection in there by adding a common energy model to underlie both the performance scaling and thermal management, but it doesn't change the thermal decision making part AFAICS. So it is fair to say that additional governor surgery and code reshuffling will be required IMO. Thanks, Rafael
Re: [PATCH] pstore/ram: Clarify resource reservation labels
On Wed, Oct 17, 2018 at 5:49 PM, Dan Williams wrote: > On Wed, Oct 17, 2018 at 5:29 PM Kees Cook wrote: >> >> When ramoops reserved a memory region in the kernel, it had an unhelpful >> label of "persistent_memory". When reading /proc/iomem, it would be >> repeated many times, did not hint that it was ramoops in particular, >> and didn't clarify very much about what each was used for: >> >> 4-407ff : Persistent Memory (legacy) >> 4-40fff : persistent_memory >> 41000-41fff : persistent_memory >> ... >> 4000ff000-4000f : persistent_memory >> >> Instead, this adds meaningful labels for how the various regions are >> being used: >> >> 4-407ff : Persistent Memory (legacy) >> 4-40fff : ramoops:dump(0/252) >> 41000-41fff : ramoops:dump(1/252) >> ... >> 4000fc000-4000fcfff : ramoops:dump(252/252) >> 4000fd000-4000fdfff : ramoops:console >> 4000fe000-4000fe3ff : ramoops:ftrace(0/3) >> 4000fe400-4000fe7ff : ramoops:ftrace(1/3) >> 4000fe800-4000febff : ramoops:ftrace(2/3) >> 4000fec00-4000fefff : ramoops:ftrace(3/3) >> 4000ff000-4000f : ramoops:pmsg > > Hopefully ramoops is doing request_region() before trying to do > anything with its ranges, because it's going to collide with the pmem > driver doing a request_region(). If we want to have pstore use pmem as > a backing store that's a new drivers/nvdimm/ namespace personality > driver to turn around and register a persistent memory range with > pstore rather than the pmem block-device driver. Yup: it's using request_mem_region() (that's where the labels above are assigned). As for nvdimm specifically, yes, I'd love to get pstore hooked up correctly to nvdimm. How do the namespaces work? Right now pstore depends one of platform driver data, device tree specification, or manual module parameters. -Kees -- Kees Cook Pixel Security
Re: [PATCH v2] staging: iio: ad7816: Switch to the gpio descriptor interface
On 17/10/2018 10:47 PM, Nishad Kamdar wrote:
Use the gpiod interface for rdwr_pin, convert_pin and busy_pin
instead of the deprecated old non-descriptor interface.
Signed-off-by: Nishad Kamdar
---
Changes in v2:
- Correct the error messages as pin number being showed
has now been replaced by error code.
---
drivers/staging/iio/adc/ad7816.c | 80 ++--
1 file changed, 34 insertions(+), 46 deletions(-)
diff --git a/drivers/staging/iio/adc/ad7816.c b/drivers/staging/iio/adc/ad7816.c
index bf76a8620bdb..12c4e0ab4713 100644
--- a/drivers/staging/iio/adc/ad7816.c
+++ b/drivers/staging/iio/adc/ad7816.c
@@ -7,7 +7,7 @@
*/
#include
-#include
+#include
#include
#include
#include
@@ -44,9 +44,9 @@
struct ad7816_chip_info {
struct spi_device *spi_dev;
- u16 rdwr_pin;
- u16 convert_pin;
- u16 busy_pin;
+ struct gpio_desc *rdwr_pin;
+ struct gpio_desc *convert_pin;
+ struct gpio_desc *busy_pin;
u8 oti_data[AD7816_CS_MAX + 1];
u8 channel_id; /* 0 always be temperature */
u8 mode;
@@ -61,28 +61,28 @@ static int ad7816_spi_read(struct ad7816_chip_info *chip,
u16 *data)
int ret = 0;
__be16 buf;
- gpio_set_value(chip->rdwr_pin, 1);
- gpio_set_value(chip->rdwr_pin, 0);
+ gpiod_set_value(chip->rdwr_pin, 1);
+ gpiod_set_value(chip->rdwr_pin, 0);
ret = spi_write(spi_dev, >channel_id, sizeof(chip->channel_id));
if (ret < 0) {
dev_err(_dev->dev, "SPI channel setting error\n");
return ret;
}
- gpio_set_value(chip->rdwr_pin, 1);
+ gpiod_set_value(chip->rdwr_pin, 1);
if (chip->mode == AD7816_PD) { /* operating mode 2 */
- gpio_set_value(chip->convert_pin, 1);
- gpio_set_value(chip->convert_pin, 0);
+ gpiod_set_value(chip->convert_pin, 1);
+ gpiod_set_value(chip->convert_pin, 0);
} else { /* operating mode 1 */
- gpio_set_value(chip->convert_pin, 0);
- gpio_set_value(chip->convert_pin, 1);
+ gpiod_set_value(chip->convert_pin, 0);
+ gpiod_set_value(chip->convert_pin, 1);
}
- while (gpio_get_value(chip->busy_pin))
+ while (gpiod_get_value(chip->busy_pin))
cpu_relax();
- gpio_set_value(chip->rdwr_pin, 0);
- gpio_set_value(chip->rdwr_pin, 1);
+ gpiod_set_value(chip->rdwr_pin, 0);
+ gpiod_set_value(chip->rdwr_pin, 1);
ret = spi_read(spi_dev, , sizeof(*data));
if (ret < 0) {
dev_err(_dev->dev, "SPI data read error\n");
@@ -99,8 +99,8 @@ static int ad7816_spi_write(struct ad7816_chip_info *chip, u8
data)
struct spi_device *spi_dev = chip->spi_dev;
int ret = 0;
- gpio_set_value(chip->rdwr_pin, 1);
- gpio_set_value(chip->rdwr_pin, 0);
+ gpiod_set_value(chip->rdwr_pin, 1);
+ gpiod_set_value(chip->rdwr_pin, 0);
ret = spi_write(spi_dev, , sizeof(data));
if (ret < 0)
dev_err(_dev->dev, "SPI oti data write error\n");
@@ -129,10 +129,10 @@ static ssize_t ad7816_store_mode(struct device *dev,
struct ad7816_chip_info *chip = iio_priv(indio_dev);
if (strcmp(buf, "full")) {
- gpio_set_value(chip->rdwr_pin, 1);
+ gpiod_set_value(chip->rdwr_pin, 1);
chip->mode = AD7816_FULL;
} else {
- gpio_set_value(chip->rdwr_pin, 0);
+ gpiod_set_value(chip->rdwr_pin, 0);
chip->mode = AD7816_PD;
}
@@ -345,15 +345,9 @@ static int ad7816_probe(struct spi_device *spi_dev)
{
struct ad7816_chip_info *chip;
struct iio_dev *indio_dev;
- unsigned short *pins = dev_get_platdata(_dev->dev);
int ret = 0;
int i;
- if (!pins) {
- dev_err(_dev->dev, "No necessary GPIO platform data.\n");
- return -EINVAL;
- }
-
indio_dev = devm_iio_device_alloc(_dev->dev, sizeof(*chip));
if (!indio_dev)
return -ENOMEM;
@@ -364,34 +358,28 @@ static int ad7816_probe(struct spi_device *spi_dev)
chip->spi_dev = spi_dev;
for (i = 0; i <= AD7816_CS_MAX; i++)
chip->oti_data[i] = 203;
- chip->rdwr_pin = pins[0];
- chip->convert_pin = pins[1];
- chip->busy_pin = pins[2];
-
- ret = devm_gpio_request(_dev->dev, chip->rdwr_pin,
- spi_get_device_id(spi_dev)->name);
- if (ret) {
- dev_err(_dev->dev, "Fail to request rdwr gpio PIN %d.\n",
- chip->rdwr_pin);
+
+ chip->rdwr_pin = devm_gpiod_get(_dev->dev, "rdwr", GPIOD_IN);
+ if (IS_ERR(chip->rdwr_pin)) {
+ ret = PTR_ERR(chip->rdwr_pin);
+ dev_err(_dev->dev, "Failed to request rdwr GPIO: %d\n",
+ ret);
return ret;
Re: [PATCH 1/3] x86: baytrail/cherrytrail: Rework and move P-Unit PMIC bus semaphore code
On Thu, Oct 18, 2018 at 10:33 AM Rafael J. Wysocki wrote: > > On Sun, Sep 23, 2018 at 4:45 PM Hans de Goede wrote: > > > > On some BYT/CHT systems the SoC's P-Unit shares the I2C bus with the > > kernel. The P-Unit has a semaphore for the PMIC bus which we can take to > > block it from accessing the shared bus while the kernel wants to access it. > > > > Currently we have the I2C-controller driver acquiring and releasing the > > semaphore around each I2C transfer. There are 2 problems with this: > > > > 1) PMIC accesses often come in the form of a read-modify-write on one of > > the PMIC registers, we currently release the P-Unit's PMIC bus semaphore > > between the read and the write. If the P-Unit modifies the register during > > this window?, then we end up overwriting the P-Unit's changes. > > I believe that this is mostly an academic problem, but I'm not sure. > > > > 2) To safely access the shared I2C bus, we need to do 3 things: > > a) Notify the GPU driver that we are starting a window in which it may not > > access the P-Unit, since the P-Unit seems to ignore the semaphore for > > explicit power-level requests made by the GPU driver > > b) Make a pm_qos request to force all CPU cores out of C6/C7 since entering > > C6/C7 while we hold the semaphore hangs the SoC > > c) Finally take the P-Unit's PMIC bus semaphore > > All 3 these steps together are somewhat expensive, so ideally if we have > > a bunch of i2c transfers grouped together we only do this once for the > > entire group. > > > > Taking the read-modify-write on a PMIC register as example then ideally we > > would only do all 3 steps once at the beginning and undo all 3 steps once > > at the end. > > > > For this we need to be able to take the semaphore from within e.g. the PMIC > > opregion driver, yet we do not want to remove the taking of the semaphore > > from the I2C-controller driver, as that is still necessary to protect many > > other code-paths leading to accessing the shared I2C bus. > > > > This means that we first have the PMIC driver acquire the semaphore and > > then have the I2C controller driver trying to acquire it again. > > > > To make this possible this commit does the following: > > > > 1) Move the semaphore code from being private to the I2C controller driver > > into the generic iosf_mbi code, which already has other code to deal with > > the shared bus so that it can be accessed outside of the I2C bus driver. > > > > 2) Rework the code so that it can be called multiple times nested, while > > still blocking I2C accesses while e.g. the GPU driver has indicated the > > P-Unit needs the bus through a iosf_mbi_punit_acquire() call. > > > > Signed-off-by: Hans de Goede > > If there are no objections or concerns regarding this patch, I'm > inclined to take the entire series including it. Please, go ahead, it looks good to me. Thanks! > > > --- > > Note this commit deliberately limits the i2c-designware changes to > > only touch i2c-designware-baytrail.c, deliberately not doing some cleanups > > which become possible after removing the semaphore code from the > > i2c-designmware code. This is done so that this commit can be merged > > through the x86 tree without causing conflicts in the i2c tree. > > > > The cleanups to the i2c-designware tree will be done in a follow up > > patch which can be merged once this commit is in place. > > --- > > arch/x86/include/asm/iosf_mbi.h | 39 +++-- > > arch/x86/platform/intel/iosf_mbi.c | 161 +-- > > drivers/i2c/busses/i2c-designware-baytrail.c | 125 +- > > 3 files changed, 180 insertions(+), 145 deletions(-) > > > > diff --git a/arch/x86/include/asm/iosf_mbi.h > > b/arch/x86/include/asm/iosf_mbi.h > > index 3de0489deade..5270ff39b9af 100644 > > --- a/arch/x86/include/asm/iosf_mbi.h > > +++ b/arch/x86/include/asm/iosf_mbi.h > > @@ -105,8 +105,10 @@ int iosf_mbi_modify(u8 port, u8 opcode, u32 offset, > > u32 mdr, u32 mask); > > * the PMIC bus while another driver is also accessing the PMIC bus > > various bad > > * things happen. > > * > > - * To avoid these problems this function must be called before accessing > > the > > - * P-Unit or the PMIC, be it through iosf_mbi* functions or through other > > means. > > + * Call this function before sending requests to the P-Unit which may make > > it > > + * access the PMIC, be it through iosf_mbi* functions or through other > > means. > > + * This function will block all kernel access to the PMIC I2C bus, so that > > the > > + * P-Unit can safely access the PMIC over the shared I2C bus. > > * > > * Note on these systems the i2c-bus driver will request a sempahore from > > the > > * P-Unit for exclusive access to the PMIC bus when i2c drivers are > > accessing > > @@ -122,6 +124,31 @@ void iosf_mbi_punit_acquire(void); > > */ > > void iosf_mbi_punit_release(void); > > > > +/** > > + * iosf_mbi_block_punit_i2c_access() - Block P-Unit accesses to the PMIC > >
Re: [PATCH 3/3] i2c: designware: Cleanup bus lock handling
On Sun, Sep 23, 2018 at 04:45:10PM +0200, Hans de Goede wrote: > Now that most of the special Bay- / Cherry-Trail bus lock handling has > been moved to the iosf_mbi code we can simplify the remaining code a bit. > > Signed-off-by: Hans de Goede Acked-by: Wolfram Sang signature.asc Description: PGP signature
Re: statx(2) API and documentation
On Thu, Oct 18, 2018 at 12:22 AM, Florian Weimer wrote: > * Andreas Dilger: > >>> So what's the point exactly? >> >> Ah, I see your point... STATX_ALL seems to be mostly useful for the kernel >> to mask off flags that it doesn't currently understand. It doesn't make >> much sense for applications to specify STATX_ALL, since they don't have any >> way to know what each flag means unless they are hard-coded to check each of >> the STATX_* flags individually. They should build up a mask of STATX_* flags >> based on what they care about (e.g. "find" should only request attributes >> based on the command-line options given). > > Could you remove it from the UAPI header? I didn't want to put it > into the glibc header, but was overruled. To summarize Linus' rule of backward incompatibility: you can do it as long as nobody notices. So yeah, we could try removing STATX_ALL from the uapi header, but we'd have to put it back in, once somebody complains. Thanks, Miklos
Re: [driver-core PATCH v4 3/6] device core: Consolidate locking and unlocking of parent and device
On Mon, Oct 15, 2018 at 5:09 PM Alexander Duyck
wrote:
>
> This patch is meant to try and consolidate all of the locking and unlocking
> of both the parent and device when attaching or removing a driver from a
> given device.
>
> To do that I first consolidated the lock pattern into two functions
> __device_driver_lock and __device_driver_unlock. After doing that I then
> created functions specific to attaching and detaching the driver while
> acquiring this locks. By doing this I was able to reduce the number of
> spots where we touch need_parent_lock from 12 down to 4.
>
> Signed-off-by: Alexander Duyck
Reviewed-by: Rafael J. Wysocki
> ---
> drivers/base/base.h |2 +
> drivers/base/bus.c | 23 ++
> drivers/base/dd.c | 83
> ++-
> 3 files changed, 75 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/base/base.h b/drivers/base/base.h
> index 7a419a7a6235..3f22ebd6117a 100644
> --- a/drivers/base/base.h
> +++ b/drivers/base/base.h
> @@ -124,6 +124,8 @@ extern int driver_add_groups(struct device_driver *drv,
> const struct attribute_group **groups);
> extern void driver_remove_groups(struct device_driver *drv,
> const struct attribute_group **groups);
> +int device_driver_attach(struct device_driver *drv, struct device *dev);
> +void device_driver_detach(struct device *dev);
>
> extern char *make_class_name(const char *name, struct kobject *kobj);
>
> diff --git a/drivers/base/bus.c b/drivers/base/bus.c
> index 8bfd27ec73d6..8a630f9bd880 100644
> --- a/drivers/base/bus.c
> +++ b/drivers/base/bus.c
> @@ -184,11 +184,7 @@ static ssize_t unbind_store(struct device_driver *drv,
> const char *buf,
>
> dev = bus_find_device_by_name(bus, NULL, buf);
> if (dev && dev->driver == drv) {
> - if (dev->parent && dev->bus->need_parent_lock)
> - device_lock(dev->parent);
> - device_release_driver(dev);
> - if (dev->parent && dev->bus->need_parent_lock)
> - device_unlock(dev->parent);
> + device_driver_detach(dev);
> err = count;
> }
> put_device(dev);
> @@ -211,13 +207,7 @@ static ssize_t bind_store(struct device_driver *drv,
> const char *buf,
>
> dev = bus_find_device_by_name(bus, NULL, buf);
> if (dev && dev->driver == NULL && driver_match_device(drv, dev)) {
> - if (dev->parent && bus->need_parent_lock)
> - device_lock(dev->parent);
> - device_lock(dev);
> - err = driver_probe_device(drv, dev);
> - device_unlock(dev);
> - if (dev->parent && bus->need_parent_lock)
> - device_unlock(dev->parent);
> + err = device_driver_attach(drv, dev);
>
> if (err > 0) {
> /* success */
> @@ -769,13 +759,8 @@ int bus_rescan_devices(struct bus_type *bus)
> */
> int device_reprobe(struct device *dev)
> {
> - if (dev->driver) {
> - if (dev->parent && dev->bus->need_parent_lock)
> - device_lock(dev->parent);
> - device_release_driver(dev);
> - if (dev->parent && dev->bus->need_parent_lock)
> - device_unlock(dev->parent);
> - }
> + if (dev->driver)
> + device_driver_detach(dev);
> return bus_rescan_devices_helper(dev, NULL);
> }
> EXPORT_SYMBOL_GPL(device_reprobe);
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 169412ee4ae8..e845cd2a87af 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -864,6 +864,60 @@ void device_initial_probe(struct device *dev)
> __device_attach(dev, true);
> }
>
> +/*
> + * __device_driver_lock - acquire locks needed to manipulate dev->drv
> + * @dev: Device we will update driver info for
> + * @parent: Parent device needed if the bus requires parent lock
> + *
> + * This function will take the required locks for manipulating dev->drv.
> + * Normally this will just be the @dev lock, but when called for a USB
> + * interface, @parent lock will be held as well.
> + */
> +static void __device_driver_lock(struct device *dev, struct device *parent)
> +{
> + if (parent && dev->bus->need_parent_lock)
> + device_lock(parent);
> + device_lock(dev);
> +}
> +
> +/*
> + * __device_driver_lock - release locks needed to manipulate dev->drv
> + * @dev: Device we will update driver info for
> + * @parent: Parent device needed if the bus requires parent lock
> + *
> + * This function will release the required locks for manipulating dev->drv.
> + * Normally this will just be the the @dev lock, but when called for a
> + * USB interface, @parent lock will be released as well.
> + */
> +static void __device_driver_unlock(struct device *dev, struct device *parent)
> +{
> +
Re: [PATCH v2] Bluetooth: hci_qca: Add support for controller debug logs.
Hi Balakrishna,
> This patch will prevent error messages splashing on console.
> [ 78.426697] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL
> packet for unknown connection handle 3804
> [ 78.436682] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL
> packet for unknown connection handle 3804
> [ 78.446639] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL
> packet for unknown connection handle 3804
> [ 78.456596] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL
> packet for unknown connection handle 3804
> QCA wcn3990 will send the debug logs in the form of ACL packets.
> While decoding packet in qca_recv(), marking the received debug log
> packet as diagnostic packet.
> Signed-off-by: Harish Bandi
> Signed-off-by: Balakrishna Godavarthi
> ---
> v2:
> * Addressed reviewer comments.
> v1:
> * initial patch
> ---
> drivers/bluetooth/hci_qca.c | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index d98ed0442201..63ac3c6b4149 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -63,6 +63,10 @@
> /* susclk rate */
> #define SUSCLK_RATE_32KHZ 32768
> +/* Controller debug log header */
> +#define QCA_DEBUG_HDR_MSB0xDC
> +#define QCA_DEBUG_HDR_LSB0x2E
> +
since this is actually the ACL handle, why not call it
QCA_DEBUG_HANDLE.
>>> [Bala]: will update.
> /* HCI_IBS transmit side sleep protocol states */
> enum tx_ibs_states {
> HCI_IBS_TX_ASLEEP,
> @@ -849,6 +853,20 @@ static int qca_ibs_wake_ack(struct hci_dev
> *hdev, struct sk_buff *skb)
> return 0;
> }
> +static int qca_recv_acl_data(struct hci_dev *hdev, struct sk_buff
> *skb)
> +{
> + /* We receive debug logs from chip as an ACL packets.
> + * Instead of sending the data to ACL to decode the
> + * received data, we are pushing them to the above layers
> + * as a diagnostic packet.
> + */
> + if ((skb->len > 2) && (skb->data[0] == QCA_DEBUG_HDR_MSB) &&
> + (skb->data[1] == QCA_DEBUG_HDR_LSB))
Skip the individual () since they are not needed. Also the skb->len
check is not needed since the H4_RECV_ACL already ensures the proper
length of the header.
And just use get_unaligned_le16(skb->data) here (or be16 if that is
the byte order).
>>> [Bala] : will update condition with _le16()
> + return hci_recv_diag(hdev, skb);
Is there any reason to keep the 4 octets hci_acl_hdr with this SKB? Or
would it be better to be stripped off. Mainly asking are they any
other magic handles that we might want to feed through the diag
channel?
>>> [Bala]: yes we need header in the stack, to differentiate between
>>> actual diagnostic packet and debug packet.
>> please explain that a bit more. There is just one debug handle or do
>> you have more special handles?
> [Bala]: Qualcomm bluetooth chip sends the debug data of the chip with ACL
> header along with fixed handler i.e. 0x2edc..
> this handler is dedicated for the debug logs sent by qcomm bt chip
> and it is not used for any other connection handlers.
> so here we are checking this handler and sending to stack as an
> a diagnostic packet.. so during the log capture we will read this
> diagnostic packet and handler,to decode the debug packet.
> that is the reason why we don't remove handler during condition
> check, in future, if qualcomm chip sends diagnostic packet,
> then this will create an problem to upper layers to decide whether
> it is an diagnostic packet or the debug packet.
> this is how we do it.
>if( diagnostic packet && handler == 0x2edc)
> treat them as an ddebug packet
>else
>treat as diagnostic packet.
let me interpret this answer. Besides debug handle 0x2edc, there are
other handles that are not connection handles. And in future updates
you want to send these handles also via hci_recv_diag channel.
>>> No, 0x2edc is an dedicated handle for debug logs, i don't really think they
>>> we will have an new handle coming up.
>>> this is only the handle we will send via hci_recv_diag channel to the stack.
>>> what i mean in my previous answer was,we don't to remove debug connection
>>> handle from the skb, because in the stack
>>> we look for a diagnostic packet and debug connection handler to decode the
>>> message.
>> if
[PATCH 2/2] mfd: ab8500-core: Return zero in get_register_interruptible()
I just noticed this in review. The get_register_interruptible() should
return zero on success but it instead returns the value that it read.
I looked at all the places that called this directly and they check for
negatives and treat greater than or equal to zero as success. This
function is also called as the ->get_register() function pointer. Some
of the callers of that treat all non-zero returns as errors, so it's
possible that this bug causes some problems in real life.
I could not find any callers that rely on the current behavior, and this
makes the function align with the get_register_interruptible() in
ab3100-core.c.
Fixes: 47c1697508f2 ("mfd: Align ab8500 with the abx500 interface")
Signed-off-by: Dan Carpenter
---
drivers/mfd/ab8500-core.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
index 30d09d177171..66458a329127 100644
--- a/drivers/mfd/ab8500-core.c
+++ b/drivers/mfd/ab8500-core.c
@@ -252,16 +252,18 @@ static int get_register_interruptible(struct ab8500
*ab8500, u8 bank,
mutex_lock(>lock);
ret = ab8500->read(ab8500, addr);
- if (ret < 0)
+ if (ret < 0) {
dev_err(ab8500->dev, "failed to read reg %#x: %d\n",
addr, ret);
- else
- *value = ret;
+ return ret;
+ }
+
+ *value = ret;
mutex_unlock(>lock);
dev_vdbg(ab8500->dev, "rd: addr %#x => data %#x\n", addr, ret);
- return ret;
+ return 0;
}
static int ab8500_get_register(struct device *dev, u8 bank,
--
2.11.0
Re: [PATCH 3/5] dt-bindings: add more optional properties for elan_i2c touchpads
On Wed, Oct 17, 2018 at 10:15 PM Rob Herring wrote: > > On Fri, Oct 12, 2018 at 04:24:11PM +0200, Benjamin Tissoires wrote: > > Some new touchpads IC are connected through PS/2 and I2C. On some of these > > new IC, the I2C part doesn't have all of the information available. > > We need to be able to forward the touchpad parameters from PS/2 and > > thus, we need those new optional properties. > > > > Link: https://bugzilla.redhat.com/show_bug.cgi?id=1628715 > > Signed-off-by: Benjamin Tissoires > > --- > > Documentation/devicetree/bindings/input/elan_i2c.txt | 8 > > 1 file changed, 8 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/input/elan_i2c.txt > > b/Documentation/devicetree/bindings/input/elan_i2c.txt > > index 797607460735..ace6bcb0b4eb 100644 > > --- a/Documentation/devicetree/bindings/input/elan_i2c.txt > > +++ b/Documentation/devicetree/bindings/input/elan_i2c.txt > > @@ -13,6 +13,14 @@ Optional properties: > >pinctrl binding [1]). > > - vcc-supply: a phandle for the regulator supplying 3.3V power. > > - elan,trackpoint: touchpad can support a trackpoint (boolean) > > +- elan,clickpad: touchpad is a clickpad (the entire surface is a button) > > > +- elan,max_x: the maximum reported value on the X axis > > +- elan,max_y: the maximum reported value on the Y axis > > +- elan,min_x: the minimum reported value on the X axis > > +- elan,min_y: the minimum reported value on the Y axis > > +- elan,x_res: the resolution of the X axis (in units per mm) > > +- elan,y_res: the resolution of the Y axis (in units per mm) > > +- elan,width: max reported width of a blob > > Can't we use standard touchscreen properties here? (Yes, I get this is a > touchpad, not touchscreen). Hey Rob, Well, there is that (it's a touchpad driver) and we can't also really use the of_touchscreen.c implementation. If both concerns are not an issue, we can then move the [min/max/res] properties to the touchscreen ones. Regarding 'elan,width', this is something missing from the standard ts properties, and AFAICT, this controls the maximum reported width/height of a touch. I should probably rename them to max_width, max_height. Hans, do you think we should add such properties to of_touchscreen.c too? (the width/height ones) Cheers, Benjamin
Re: [RFC v4 PATCH 2/5] mm/__free_one_page: skip merge for order-0 page unless compaction failed
On 10/18/18 8:48 AM, Aaron Lu wrote: > On Wed, Oct 17, 2018 at 07:03:30PM +0200, Vlastimil Babka wrote: >> On 10/17/18 3:58 PM, Mel Gorman wrote: >>> Again, as compaction is not guaranteed to find the pageblocks, it would >>> be important to consider whether a) that matters or b) find an >>> alternative way of keeping unmerged buddies on separate lists so they >>> can be quickly discovered when a high-order allocation fails. >> >> Agree, unmerged buddies could be on separate freelist from regular >> order-0 freelist. That list could be also preferred to allocations >> before the regular one. Then one could e.g. try "direct merging" via >> this list when compaction fails, or prefer direct merging to compaction >> for non-costly-order allocations, do direct merging when allocation >> context doesn't even allow compaction (atomic etc). > > One concern regarding "direct merging" these unmerged pages via this > separate freelist(let's call it unmerged_free_list) is: adjacent > unmerged pages on the unmerged_free_list could be far away from each > other regarding their physical positions, so during the process of > merging them, the needed high order page may not be able to be formed > in a short time. Actually, the time could be unbound in a bad condition > when: > 1 unmerged pages adjacent on the unmerged_free_list happen to be far > away from each other regarding their physical positions; and I'm not sure I understand. Why should it matter for merging if pages are adjacent on the unmerged_free_list? The buddy for merging is found the usual way, no? > 2 there are a lot of unmerged pages on unmerged_free_list. That will affect allocation latency, yeah. Still might be faster than direct compaction. And possible to do in GFP_ATOMIC context, unlike direct compaction. > That's the reason I hooked the merging of unmerged pages in compaction > when isolate_migratepages_block() is scanning every page of a pageblock > in PFN order. > > OTOH, if there is a kernel thread trying to reduce fragmentation by > doing merges for these unmerged pages, I think it's perfect fine to let > it iterate all unmerged pages of that list and do_merge() for all of > them. > > So what about this: if kcompactd is running, let it handle these > unmerged pages on the list and after that, do its usual job of > compaction. If direct compaction is running, do not handle unmerged > pages on that list but rely on isolate_migratepages_block() to do the > merging as is done in this patchset. > > This of course has the effect of tying compaction with 'lazy merging'. > If it is not desirable, what about creating a new kernel thread to do > the merging of unmerged pages on the list while keeping the behaviour of > isolate_migratepages_block() in this patchset to improve compaction > success rate. Note that anything based on daemons will seem like reducing latency for allocations, but if we delay merging and then later do it from a daemon, the overall zone lock times will be essentially the same, right? The reduced zone lock benefits only happen when the unmerged pages get reallocated. >> Also I would definitely consider always merging pages freed to >> non-MOVABLE pageblocks. We really don't want to increase the >> fragmentation in those. However that means it probably won't help the >> netperf case? > > Yes, that would be unfortunate for all in-kernel users of page > allocator... In that case there should definitely be a direct merging possibility IMHO, even if only as a last resort before stealing from another pageblock.
Re: [PATCH v4 3/3] iio: magnetometer: Add driver support for PNI RM3100
On 2018/10/13 下午6:19, Jonathan Cameron wrote:
On Fri, 12 Oct 2018 15:35:36 +0800
Song Qiang wrote:
PNI RM3100 is a high resolution, large signal immunity magnetometer,
composed of 3 single sensors and a processing chip with a MagI2C
interface.
Following functions are available:
- Single-shot measurement from
/sys/bus/iio/devices/iio:deviceX/in_magn_{axis}_raw
- Triggerd buffer measurement.
- DRDY pin for data ready trigger.
- Both i2c and spi interface are supported.
- Both interrupt and polling measurement is supported, depends on if
the 'interrupts' in DT is declared.
Signed-off-by: Song Qiang
A few questions for you (getting very close to being good to go btw!)
Why do we have the 3second additional wait for conversions? I know we
rarely wait that long, but still seems excessive.
Few more comments inline.
Thanks,
Jonathan
Hi Jonathan,
The measurement time of this device varies from 1.7ms to 13 seconds, 3 seconds
is just a number in the middle between them. This may be worth discussing,
hoping to get a better solution from the community.
---
MAINTAINERS| 7 +
drivers/iio/magnetometer/Kconfig | 29 ++
drivers/iio/magnetometer/Makefile | 4 +
drivers/iio/magnetometer/rm3100-core.c | 627 +
drivers/iio/magnetometer/rm3100-i2c.c | 58 +++
drivers/iio/magnetometer/rm3100-spi.c | 64 +++
drivers/iio/magnetometer/rm3100.h | 17 +
7 files changed, 806 insertions(+)
create mode 100644 drivers/iio/magnetometer/rm3100-core.c
create mode 100644 drivers/iio/magnetometer/rm3100-i2c.c
create mode 100644 drivers/iio/magnetometer/rm3100-spi.c
create mode 100644 drivers/iio/magnetometer/rm3100.h
...
+static irqreturn_t rm3100_trigger_handler(int irq, void *p)
+{
+ struct iio_poll_func *pf = p;
+ struct iio_dev *indio_dev = pf->indio_dev;
+ unsigned long scan_mask = *indio_dev->active_scan_mask;
+ unsigned int mask_len = indio_dev->masklength;
+ struct rm3100_data *data = iio_priv(indio_dev);
+ struct regmap *regmap = data->regmap;
+ int ret, i, bit;
+
+ mutex_lock(>lock);
+ switch (scan_mask) {
+ case BIT(0) | BIT(1) | BIT(2):
+ ret = regmap_bulk_read(regmap, RM3100_REG_MX2, data->buffer, 9);
+ mutex_unlock(>lock);
+ if (ret < 0)
+ goto done;
+ break;
+ case BIT(0) | BIT(1):
+ ret = regmap_bulk_read(regmap, RM3100_REG_MX2, data->buffer, 6);
+ mutex_unlock(>lock);
+ if (ret < 0)
+ goto done;
+ break;
+ case BIT(1) | BIT(2):
+ ret = regmap_bulk_read(regmap, RM3100_REG_MY2, data->buffer, 6);
+ mutex_unlock(>lock);
+ if (ret < 0)
+ goto done;
+ break;
What about BIT(0) | BIT(2)?
Now you can do it like you have here and on that one corner case let the iio
core
demux code take care of it, but then you will need to provide
available_scan_masks
so the core knows it needs to handle this case.
This confused me a little. The available_scan_masks I was using is {BIT(0) |
BIT(1) | BIT(2), 0x0}. Apparently in this version of patch I would like it to
handle every circumstances like BIT(0), BIT(0) | BIT(2), BIT(1) | BIT(2), etc.
Since Phil mentioned he would like this to reduce bus usage as much as we can
and I want it, too, I think these three circumstances can be read consecutively
while others can be read one axis at a time. So I plan to let BIT(0) | BIT(2)
fall into the 'default' section, which reads axis one by one.
My question is, since this handles every possible combination, do I still need
to list every available scan masks in available_scan_masks?
All other problems will be fixed in the next patch.
yours,
Song Qiang
...
Re: INFO: rcu detected stall in do_idle
On 16/10/18 16:03, Peter Zijlstra wrote:
> On Tue, Oct 16, 2018 at 03:24:06PM +0200, Thomas Gleixner wrote:
> > It does reproduce here but with a kworker stall. Looking at the reproducer:
> >
> > *(uint32_t*)0x2000 = 0;
> > *(uint32_t*)0x2004 = 6;
> > *(uint64_t*)0x2008 = 0;
> > *(uint32_t*)0x2010 = 0;
> > *(uint32_t*)0x2014 = 0;
> > *(uint64_t*)0x2018 = 0x9917;
> > *(uint64_t*)0x2020 = 0x;
> > *(uint64_t*)0x2028 = 0;
> > syscall(__NR_sched_setattr, 0, 0x2000, 0);
> >
> > which means:
> >
> > struct sched_attr {
> > .size = 0,
> > .policy= 6,
> > .flags = 0,
> > .nice = 0,
> > .priority = 0,
> > .deadline = 0x9917,
> > .runtime = 0x,
> > .period= 0,
> > }
> >
> > policy 6 is SCHED_DEADLINE
> >
> > That makes the thread hog the CPU and prevents all kind of stuff to run.
> >
> > Peter, is that expected behaviour?
>
> Sorta, just like FIFO-99 while(1);. Except we should be rejecting the
> above configuration, because of the rule:
>
> runtime <= deadline <= period
>
> Juri, where were we supposed to check that?
OK, looks like the "which means" part above had me fooled, as
we actually have ([1], where the comment is wrong)
struct sched_attr {
.size = 0,
.policy = 6,
.flags = 0,
.nice = 0,
.priority = 0,
.runtime= 0x9917,
.deadline = 0x,
.period = 0,
}
So, we seem to be correctly (in theory, see below) accepting the task.
What seems to generate the problem here is that CONFIG_HZ=100 and
reproducer task has "tiny" runtime (~40us) and deadline (~66us)
parameters, combination that "bypasses" the enforcing mechanism
(performed at each tick).
Another side problem seems also to be that with such tiny parameters we
spend lot of time in the while (dl_se->runtime <= 0) loop of replenish_dl_
entity() (actually uselessly, as deadline is most probably going to
still be in the past when eventually runtime becomes positive again), as
delta_exec is huge w.r.t. runtime and runtime has to keep up with tiny
increments of dl_runtime. I guess we could ameliorate things here by
limiting the number of time we execute the loop before bailing out.
Enabling HRTICK makes a difference [2]. I played a bit with several
combinations and could verify that parameters in the ~50us range seem
usable. However, still to mention that when runtime gets close to
deadline (very high bandwidth) enforcing could be tricked again, as
hrtick overheads might make the task effectively executing for more than
the runtime, over passing the replenish instant (old deadline), so
replenish timer is not set, and letting the task continuing executing
after a replenishment.
This is all however very much platform and config dependent, of course.
So, I tend to think that we might want to play safe and put some higher
minimum value for dl_runtime (it's currently at 1ULL << DL_SCALE).
Guess the problem is to pick a reasonable value, though. Maybe link it
someway to HZ? Then we might add a sysctl (or similar) thing with which
knowledgeable users can do whatever they think their platform/config can
support?
Thoughts?
I'm adding more people on Cc as I'm not sure they are following this.
Thread starts here [3].
1 -
https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/sched/types.h#L70
2 - noticed that we don't actually start hrtick on setup_new_dl_entity()
and think we should
3 - https://lore.kernel.org/lkml/a4ee200578172...@google.com/
Re: [PATCH V9 12/21] csky: ELF and module probe
On Thu, Oct 18, 2018 at 4:49 AM Guo Ren wrote: > > On Wed, Oct 17, 2018 at 05:18:49PM +0200, Arnd Bergmann wrote: > > On Tue, Oct 16, 2018 at 5:02 AM Guo Ren wrote: > > > > > > This patch adds ELF definition and module relocate codes. > > > > > > Signed-off-by: Guo Ren > > > Cc: Arnd Bergmann > > > > > +#ifdef __cskyBE__ > > > +#define ELF_DATA ELFDATA2MSB > > > +#else > > > +#define ELF_DATA ELFDATA2LSB > > > +#endif > > > > You removed support for big-endian, right? I guess the #ifdef can also > > get removed here then. Aside from that, > Now, we only support little-endian and it could be removed. But maybe we > need support big-endian in future, so I keep it here. Ok, just made sure it was intentional. Arnd
Re: [PATCH 1/3] x86: baytrail/cherrytrail: Rework and move P-Unit PMIC bus semaphore code
On Thursday, October 18, 2018 10:34:57 AM CEST Hans de Goede wrote: > Hi, > > On 18-10-18 09:29, Rafael J. Wysocki wrote: > > On Sun, Sep 23, 2018 at 4:45 PM Hans de Goede wrote: > >> > >> On some BYT/CHT systems the SoC's P-Unit shares the I2C bus with the > >> kernel. The P-Unit has a semaphore for the PMIC bus which we can take to > >> block it from accessing the shared bus while the kernel wants to access it. > >> > >> Currently we have the I2C-controller driver acquiring and releasing the > >> semaphore around each I2C transfer. There are 2 problems with this: > >> > >> 1) PMIC accesses often come in the form of a read-modify-write on one of > >> the PMIC registers, we currently release the P-Unit's PMIC bus semaphore > >> between the read and the write. If the P-Unit modifies the register during > >> this window?, then we end up overwriting the P-Unit's changes. > >> I believe that this is mostly an academic problem, but I'm not sure. > >> > >> 2) To safely access the shared I2C bus, we need to do 3 things: > >> a) Notify the GPU driver that we are starting a window in which it may not > >> access the P-Unit, since the P-Unit seems to ignore the semaphore for > >> explicit power-level requests made by the GPU driver > >> b) Make a pm_qos request to force all CPU cores out of C6/C7 since entering > >> C6/C7 while we hold the semaphore hangs the SoC > >> c) Finally take the P-Unit's PMIC bus semaphore > >> All 3 these steps together are somewhat expensive, so ideally if we have > >> a bunch of i2c transfers grouped together we only do this once for the > >> entire group. > >> > >> Taking the read-modify-write on a PMIC register as example then ideally we > >> would only do all 3 steps once at the beginning and undo all 3 steps once > >> at the end. > >> > >> For this we need to be able to take the semaphore from within e.g. the PMIC > >> opregion driver, yet we do not want to remove the taking of the semaphore > >> from the I2C-controller driver, as that is still necessary to protect many > >> other code-paths leading to accessing the shared I2C bus. > >> > >> This means that we first have the PMIC driver acquire the semaphore and > >> then have the I2C controller driver trying to acquire it again. > >> > >> To make this possible this commit does the following: > >> > >> 1) Move the semaphore code from being private to the I2C controller driver > >> into the generic iosf_mbi code, which already has other code to deal with > >> the shared bus so that it can be accessed outside of the I2C bus driver. > >> > >> 2) Rework the code so that it can be called multiple times nested, while > >> still blocking I2C accesses while e.g. the GPU driver has indicated the > >> P-Unit needs the bus through a iosf_mbi_punit_acquire() call. > >> > >> Signed-off-by: Hans de Goede > > > > If there are no objections or concerns regarding this patch, I'm > > inclined to take the entire series including it. > > In that case let me send out a v4, with the following chunk added to the > 2nd patch: > > --- a/drivers/acpi/Kconfig > +++ b/drivers/acpi/Kconfig > @@ -515,7 +515,7 @@ config CRC_PMIC_OPREGION > > config XPOWER_PMIC_OPREGION > bool "ACPI operation region support for XPower AXP288 PMIC" > - depends on MFD_AXP20X_I2C > + depends on MFD_AXP20X_I2C && IOSF_MBI > help >This config adds ACPI operation region support for XPower AXP288 > PMIC. > > This is necessary to avoid compilation issues on non x86 systems (where the > asm/iosf_mbi.h header is not available) and on x86 systems in case > IOSF_MBI support is not enabled there. Note that the AXP288 PMIC is > connected through the LPSS i2c controller, so either we have IOSF_MBI support > selected through the X86_INTEL_LPSS option, or we have a kernel where the > opregion will never work anyways. I'd prefer to get an incremental patch for that at this point. Thanks, Rafael
[PATCH 4/5] rtc: sc27xx: Add check to see if need to enable the alarm interrupt
The RTC interrupt enable register is not put in always-power-on region
supplied by VDDRTC, so we should check if we need enable the alarm
interrupt when system booting.
Signed-off-by: Baolin Wang
---
drivers/rtc/rtc-sc27xx.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/rtc/rtc-sc27xx.c b/drivers/rtc/rtc-sc27xx.c
index 4ecabe6..72bb002 100644
--- a/drivers/rtc/rtc-sc27xx.c
+++ b/drivers/rtc/rtc-sc27xx.c
@@ -563,6 +563,32 @@ static int sprd_rtc_check_power_down(struct sprd_rtc *rtc)
return 0;
}
+static int sprd_rtc_check_alarm_int(struct sprd_rtc *rtc)
+{
+ u32 val;
+ int ret;
+
+ ret = regmap_read(rtc->regmap, rtc->base + SPRD_RTC_SPG_VALUE, );
+ if (ret)
+ return ret;
+
+ /*
+* The SPRD_RTC_INT_EN register is not put in always-power-on region
+* supplied by VDDRTC, so we should check if we need enable the alarm
+* interrupt when system booting.
+*
+* If we have set SPRD_RTC_POWEROFF_ALM_FLAG which is saved in
+* always-power-on region, that means we have set one alarm last time,
+* so we should enable the alarm interrupt to help RTC core to see if
+* there is an alarm already set in RTC hardware.
+*/
+ if (!(val & SPRD_RTC_POWEROFF_ALM_FLAG))
+ return 0;
+
+ return regmap_update_bits(rtc->regmap, rtc->base + SPRD_RTC_INT_EN,
+ SPRD_RTC_ALARM_EN, SPRD_RTC_ALARM_EN);
+}
+
static int sprd_rtc_probe(struct platform_device *pdev)
{
struct device_node *node = pdev->dev.of_node;
@@ -596,6 +622,13 @@ static int sprd_rtc_probe(struct platform_device *pdev)
rtc->dev = >dev;
platform_set_drvdata(pdev, rtc);
+ /* check if we need set the alarm interrupt */
+ ret = sprd_rtc_check_alarm_int(rtc);
+ if (ret) {
+ dev_err(>dev, "failed to check RTC alarm interrupt\n");
+ return ret;
+ }
+
/* check if RTC time values are valid */
ret = sprd_rtc_check_power_down(rtc);
if (ret) {
--
1.7.9.5
Re: [PATCH 3/5] dt-bindings: add more optional properties for elan_i2c touchpads
Hi, On 18-10-18 10:44, Benjamin Tissoires wrote: On Thu, Oct 18, 2018 at 10:39 AM Hans de Goede wrote: Hi, On 18-10-18 10:10, Benjamin Tissoires wrote: On Wed, Oct 17, 2018 at 10:15 PM Rob Herring wrote: On Fri, Oct 12, 2018 at 04:24:11PM +0200, Benjamin Tissoires wrote: Some new touchpads IC are connected through PS/2 and I2C. On some of these new IC, the I2C part doesn't have all of the information available. We need to be able to forward the touchpad parameters from PS/2 and thus, we need those new optional properties. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1628715 Signed-off-by: Benjamin Tissoires --- Documentation/devicetree/bindings/input/elan_i2c.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/input/elan_i2c.txt b/Documentation/devicetree/bindings/input/elan_i2c.txt index 797607460735..ace6bcb0b4eb 100644 --- a/Documentation/devicetree/bindings/input/elan_i2c.txt +++ b/Documentation/devicetree/bindings/input/elan_i2c.txt @@ -13,6 +13,14 @@ Optional properties: pinctrl binding [1]). - vcc-supply: a phandle for the regulator supplying 3.3V power. - elan,trackpoint: touchpad can support a trackpoint (boolean) +- elan,clickpad: touchpad is a clickpad (the entire surface is a button) +- elan,max_x: the maximum reported value on the X axis +- elan,max_y: the maximum reported value on the Y axis +- elan,min_x: the minimum reported value on the X axis +- elan,min_y: the minimum reported value on the Y axis +- elan,x_res: the resolution of the X axis (in units per mm) +- elan,y_res: the resolution of the Y axis (in units per mm) +- elan,width: max reported width of a blob Can't we use standard touchscreen properties here? (Yes, I get this is a touchpad, not touchscreen). Hey Rob, Well, there is that (it's a touchpad driver) and we can't also really use the of_touchscreen.c implementation. If both concerns are not an issue, we can then move the [min/max/res] properties to the touchscreen ones. Regarding 'elan,width', this is something missing from the standard ts properties, and AFAICT, this controls the maximum reported width/height of a touch. I should probably rename them to max_width, max_height. Hans, do you think we should add such properties to of_touchscreen.c too? (the width/height ones) Are there touchscreens which report finger/touch width / height ? if so then it probably does make sense. Well, it's pretty common for hid-multitouch touchscreens to report such properties (it's a way to indicate the palm). Don't know about the touchscreens that rely on of_touchscreen though. Now that you mention it I think some may also have some sort of pressure/weight value, but at least for the ones I wrote I do not think we do anything with it, since the actual meaning of the field is somewhat vague. This is all IIRC. Note that for historical reasons Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt Looks like your sentence is not finished here :) I actually deleted it, but not those 2 lines, what I had written there was that for historical reasons it uses touchscreen-size-x rather then max-x and that that might be a bit confusing vs max-width, but I could not come up with something better then max-width, so I deleted my rambling, but ended up not deleting all of it :) Also the touchscreen bindings have: touchscreen-x-mm and touchscreen-y-mm rather then res, which can then be used to calculate the resolution. yeah, that's fine, I would need to convert to mm, then go back to res. Extra effort, but that's the price to pay. Ack. Regards, Hans
[PATCH 0/5] Fix some issues for RTC alarm function
This patch set fixes some issues when setting one RTC alarm. Baolin Wang (5): rtc: sc27xx: Set wakeup capability before registering rtc device rtc: sc27xx: Clear SPG value update interrupt status rtc: sc27xx: Remove interrupts disable and clear in probe() rtc: sc27xx: Add check to see if need to enable the alarm interrupt rtc: sc27xx: Always read normal alarm when registering RTC device drivers/rtc/rtc-sc27xx.c | 60 ++ 1 file changed, 40 insertions(+), 20 deletions(-) -- 1.7.9.5
Re: [PATCH 3/4] irqchip/mbigen: add support for a MBIGEN generating SPIs
Hi Yang,
On 18/10/18 04:41, Yang Yingliang wrote:
> Hi, Marc
>
> On 2018/10/18 0:30, Marc Zyngier wrote:
>> On 16/10/18 10:15, Yang Yingliang wrote:
>>> Now with
>>> 5052875 ("irqchip/gic-v3: Add support for Message Based Interrupts as an
>>> MSI controller"),
>>> we can support MBIGEN to generate message based SPIs by writing
>>> GICD_SETSPIR.
>>>
>>> The first 64-pins of each MBIGEN chip is used to generate SPIs, and each
>>> MBIGEN chip has several MBIGEN nodes, every node has 128 pins for generating
>>> LPIs. The total pins are: 64(SPIs) + 128 * node_nr(LPIs). So we can
>>> translate
>>> the pin index in a unified way in mbigen_domain_translate().
>>>
>>> Also Add TYPE and VEC registers that used by generating SPIs, the driver can
>>> access them when MBIGEN is used to generate SPIs.
>>>
>>> Signed-off-by: Yang Yingliang
>>> ---
>>> drivers/irqchip/irq-mbigen.c | 21 +++--
>>> 1 file changed, 19 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
>>> index f05998f..37c1932 100644
>>> --- a/drivers/irqchip/irq-mbigen.c
>>> +++ b/drivers/irqchip/irq-mbigen.c
>>> @@ -48,6 +48,7 @@
>>> #define MBIGEN_NODE_OFFSET0x1000
>>>
>>> /* offset of vector register in mbigen node */
>>> +#define REG_MBIGEN_SPI_VEC_OFFSET 0x500
>>> #define REG_MBIGEN_LPI_VEC_OFFSET 0x200
>>>
>>> /**
>>> @@ -62,6 +63,7 @@
>>>* This register is used to configure interrupt
>>>* trigger type
>>>*/
>>> +#define REG_MBIGEN_SPI_TYPE_OFFSET 0x400
>>> #define REG_MBIGEN_LPI_TYPE_OFFSET0x0
>>>
>>> /**
>>> @@ -79,6 +81,9 @@ static inline unsigned int
>>> get_mbigen_vec_reg(irq_hw_number_t hwirq)
>>> {
>>> unsigned int nid, pin;
>>>
>>> + if (hwirq < SPI_NUM_PER_MBIGEN_CHIP)
>>> + return (hwirq * 4 + REG_MBIGEN_SPI_VEC_OFFSET);
>>> +
>>> hwirq -= SPI_NUM_PER_MBIGEN_CHIP;
>>> nid = hwirq / IRQS_PER_MBIGEN_NODE + 1;
>>> pin = hwirq % IRQS_PER_MBIGEN_NODE;
>>> @@ -92,6 +97,13 @@ static inline void get_mbigen_type_reg(irq_hw_number_t
>>> hwirq,
>>> {
>>> unsigned int nid, irq_ofst, ofst;
>>>
>>> + if (hwirq < SPI_NUM_PER_MBIGEN_CHIP) {
>>> + *mask = 1 << (hwirq % 32);
>>> + ofst = hwirq / 32 * 4;
>>> + *addr = ofst + REG_MBIGEN_SPI_TYPE_OFFSET;
>>> + return;
>>> + }
>>> +
>>> hwirq -= SPI_NUM_PER_MBIGEN_CHIP;
>>> nid = hwirq / IRQS_PER_MBIGEN_NODE + 1;
>>> irq_ofst = hwirq % IRQS_PER_MBIGEN_NODE;
>>> @@ -162,6 +174,12 @@ static void mbigen_write_msg(struct msi_desc *desc,
>>> struct msi_msg *msg)
>>> u32 val;
>>>
>>> base += get_mbigen_vec_reg(d->hwirq);
>>> +
>>> + if (d->hwirq < SPI_NUM_PER_MBIGEN_CHIP) {
>>> + writel_relaxed(msg->data, base);
>>> + return;
>>> + }
>> How is the GICD_SETSPI_NSR base address programmed if you're ignoring
>> the address stored in the message?
> Now, this base address is encoded in MBIGEN register by default.
OK. So let's move the comment in that function to the top, and indicate
that this also applies to the GICD_SETSPI_NSR register.
> In case this address isn't set to register in later SoCs, I think the
> MBIGEN driver set this base address would be better. I will add
> relative codes to handle both GICD_SETSPI_NSR and ITS Translate
> address.
>
>>
>> How do you deal with level interrupts, as you don't seem to use the
>> level MSI framework either?
> The MBIGEN driver need to clear active state in irq_eoi hook, when it
> dealing with level SPIs.
OK, so you're not taking advantage of the the CLEAR register here? Sad.
>
>>
>>> +
>>> val = readl_relaxed(base);
>>>
>>> val &= ~(IRQ_EVENT_ID_MASK << IRQ_EVENT_ID_SHIFT);
>>> @@ -182,8 +200,7 @@ static int mbigen_domain_translate(struct irq_domain *d,
>>> if (fwspec->param_count != 2)
>>> return -EINVAL;
>>>
>>> - if ((fwspec->param[0] > MAXIMUM_IRQ_PIN_NUM) ||
>>> - (fwspec->param[0] < SPI_NUM_PER_MBIGEN_CHIP))
>>> + if (fwspec->param[0] > MAXIMUM_IRQ_PIN_NUM)
>>> return -EINVAL;
>>> else
>>> *hwirq = fwspec->param[0];
>>>
>> Now, the biggest question of them all: how does it work with ACPI? Last
>> time I checked, there was no DT support for platforms using the MBIGEN.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/hisilicon/hip07.dtsi
> This DT describes how platform devices using the MBIGEN.
That's not how my own D05 boots. It is ACPI only. How is that going to
work on this platform?
>
>>
>> My gut feeling is that it would be so much better if the SPIs generated
>> by the MBIGEN were configured in firmware, and the devices behind it
>> would just describe the corresponding SPI...
> We need use this framework to clear active state in MBIGEN register, so
> configuring
> in firmware is not enough...
Fair
Re: [PATCH 9/9] [DO NOT MERGE] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check
Hi Icenowy,
Thank you for the patch.
On Thursday, 18 October 2018 10:33:27 EEST Icenowy Zheng wrote:
> From: Chen-Yu Tsai
>
> The panels shipped with Allwinner devices are very "generic", i.e.
> they do not have model numbers or reliable sources of information
> for the timings (that we know of) other than the fex files shipped
> on them. The dot clock frequency provided in the fex files have all
> been rounded to the nearest MHz, as that is the unit used in them.
>
> We were using the simple panel "urt,umsh-8596md-t" as a substitute
> for the A13 Q8 tablets in the absence of a specific model for what
> may be many different but otherwise timing compatible panels. This
> was usable without any visual artifacts or side effects, until the
> dot clock rate check was added in commit bb43d40d7c83 ("drm/sun4i:
> rgb: Validate the clock rate").
>
> The reason this check fails is because the dotclock frequency for
> this model is 33.26 MHz, which is not achievable with our dot clock
> hardware, and the rate returned by clk_round_rate deviates slightly,
> causing the driver to reject the display mode.
>
> The LCD panels have some tolerance on the dot clock frequency, even
> if it's not specified in their datasheets.
>
> This patch adds a 5% tolerence to the dot clock check.
Why do you think this shouldn't be merged ?
> Signed-off-by: Chen-Yu Tsai
> ---
> drivers/gpu/drm/sun4i/sun4i_rgb.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_rgb.c
> b/drivers/gpu/drm/sun4i/sun4i_rgb.c index bf068da6b12e..23bdc449eacc 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_rgb.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_rgb.c
> @@ -92,13 +92,14 @@ static enum drm_mode_status sun4i_rgb_mode_valid(struct
> drm_encoder *crtc,
>
> DRM_DEBUG_DRIVER("Vertical parameters OK\n");
>
> + /* Check against a 5% tolerance for the dot clock */
> tcon->dclk_min_div = 6;
> tcon->dclk_max_div = 127;
> rounded_rate = clk_round_rate(tcon->dclk, rate);
> - if (rounded_rate < rate)
> + if (rounded_rate < rate * 19 / 20 )
> return MODE_CLOCK_LOW;
>
> - if (rounded_rate > rate)
> + if (rounded_rate > rate * 21 / 20)
> return MODE_CLOCK_HIGH;
>
> DRM_DEBUG_DRIVER("Clock rate OK\n");
--
Regards,
Laurent Pinchart
[PATCH 0/3] nds32: Unaligned access handler fix
The patches are about unaligned access handler. We fix some bugs in unaligned access handler and add some kernel configs for unaligned access handler. Then we add the kernel unaligned access handled by software in handler. Nickhu (3): nds32: Fix instruction simulator bug for unaligned access handler. nds32: Add 'HAVE_EFFICIENT_UNALIGNED_ACCESS' config nds32: Add unaligned access in kernel space. arch/nds32/Kconfig.cpu| 3 ++- arch/nds32/kernel/traps.c | 4 +++- arch/nds32/mm/alignment.c | 43 +++ 3 files changed, 30 insertions(+), 20 deletions(-) -- 2.17.0
[PATCH v4 4/8] regulator: stpmic1: add stpmic1 regulator driver
From: pascal paillet
The stpmic1 PMIC embeds several regulators and switches with
different capabilities.
Signed-off-by: pascal paillet
---
changes in v4: nothing
drivers/regulator/Kconfig | 12 +
drivers/regulator/Makefile| 1 +
drivers/regulator/stpmic1_regulator.c | 674 ++
3 files changed, 687 insertions(+)
create mode 100644 drivers/regulator/stpmic1_regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 6e96ef1..026d480 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -803,6 +803,18 @@ config REGULATOR_STM32_VREFBUF
This driver can also be built as a module. If so, the module
will be called stm32-vrefbuf.
+config REGULATOR_STPMIC1
+ tristate "STMicroelectronics STPMIC1 PMIC Regulators"
+ depends on MFD_STPMIC1
+ help
+ This driver supports STMicroelectronics STPMIC1 PMIC voltage
+ regulators and switches. The STPMIC1 regulators supply power to
+ an application processor as well as to external system
+ peripherals such as DDR, Flash memories and system devices.
+
+ To compile this driver as a module, choose M here: the
+ module will be called stpmic1_regulator.
+
config REGULATOR_TI_ABB
tristate "TI Adaptive Body Bias on-chip LDO"
depends on ARCH_OMAP
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index eac4d79..300bc4c 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -101,6 +101,7 @@ obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
obj-$(CONFIG_REGULATOR_SC2731) += sc2731-regulator.o
obj-$(CONFIG_REGULATOR_SKY81452) += sky81452-regulator.o
obj-$(CONFIG_REGULATOR_STM32_VREFBUF) += stm32-vrefbuf.o
+obj-$(CONFIG_REGULATOR_STPMIC1) += stpmic1_regulator.o
obj-$(CONFIG_REGULATOR_STW481X_VMMC) += stw481x-vmmc.o
obj-$(CONFIG_REGULATOR_SY8106A) += sy8106a-regulator.o
obj-$(CONFIG_REGULATOR_TI_ABB) += ti-abb-regulator.o
diff --git a/drivers/regulator/stpmic1_regulator.c
b/drivers/regulator/stpmic1_regulator.c
new file mode 100644
index 000..96f1808
--- /dev/null
+++ b/drivers/regulator/stpmic1_regulator.c
@@ -0,0 +1,674 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) STMicroelectronics 2018
+// Author: Pascal Paillet for STMicroelectronics.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * stpmic1 regulator description
+ * @desc: regulator framework description
+ * @mask_reset_reg: mask reset register address
+ * @mask_reset_mask: mask rank and mask reset register mask
+ * @icc_reg: icc register address
+ * @icc_mask: icc register mask
+ */
+struct stpmic1_regulator_cfg {
+ struct regulator_desc desc;
+ u8 mask_reset_reg;
+ u8 mask_reset_mask;
+ u8 icc_reg;
+ u8 icc_mask;
+};
+
+/**
+ * stpmic1 regulator data: this structure is used as driver data
+ * @regul_id: regulator id
+ * @reg_node: DT node of regulator (unused on non-DT platforms)
+ * @cfg: stpmic specific regulator description
+ * @mask_reset: mask_reset bit value
+ * @irq_curlim: current limit interrupt number
+ * @regmap: point to parent regmap structure
+ */
+struct stpmic1_regulator {
+ unsigned int regul_id;
+ struct device_node *reg_node;
+ struct stpmic1_regulator_cfg *cfg;
+ u8 mask_reset;
+ int irq_curlim;
+ struct regmap *regmap;
+};
+
+static int stpmic1_set_mode(struct regulator_dev *rdev, unsigned int mode);
+static unsigned int stpmic1_get_mode(struct regulator_dev *rdev);
+static int stpmic1_set_icc(struct regulator_dev *rdev);
+static int stpmic1_regulator_parse_dt(void *driver_data);
+static unsigned int stpmic1_map_mode(unsigned int mode);
+
+enum {
+ STPMIC1_BUCK1 = 0,
+ STPMIC1_BUCK2 = 1,
+ STPMIC1_BUCK3 = 2,
+ STPMIC1_BUCK4 = 3,
+ STPMIC1_LDO1 = 4,
+ STPMIC1_LDO2 = 5,
+ STPMIC1_LDO3 = 6,
+ STPMIC1_LDO4 = 7,
+ STPMIC1_LDO5 = 8,
+ STPMIC1_LDO6 = 9,
+ STPMIC1_VREF_DDR = 10,
+ STPMIC1_BOOST = 11,
+ STPMIC1_VBUS_OTG = 12,
+ STPMIC1_SW_OUT = 13,
+};
+
+/* Enable time worst case is 5000mV/(2250uV/uS) */
+#define PMIC_ENABLE_TIME_US 2200
+
+#define STPMIC1_BUCK_MODE_NORMAL 0
+#define STPMIC1_BUCK_MODE_LP BUCK_HPLP_ENABLE_MASK
+
+struct regulator_linear_range buck1_ranges[] = {
+ REGULATOR_LINEAR_RANGE(60, 0, 30, 25000),
+ REGULATOR_LINEAR_RANGE(135, 31, 63, 0),
+};
+
+struct regulator_linear_range buck2_ranges[] = {
+ REGULATOR_LINEAR_RANGE(100, 0, 17, 0),
+ REGULATOR_LINEAR_RANGE(105, 18, 19, 0),
+ REGULATOR_LINEAR_RANGE(110, 20, 21, 0),
+ REGULATOR_LINEAR_RANGE(115, 22, 23, 0),
+ REGULATOR_LINEAR_RANGE(120, 24, 25, 0),
+ REGULATOR_LINEAR_RANGE(125, 26, 27, 0),
+ REGULATOR_LINEAR_RANGE(130, 28, 29, 0),
+ REGULATOR_LINEAR_RANGE(135, 30, 31,
[PATCH v4 1/8] dt-bindings: mfd: document stpmic1
From: pascal paillet
stpmic1 is a pmic from STMicroelectronics. The STPMIC1 integrates 10
regulators , 3 switches, a watchdog and an input for a power on key.
Signed-off-by: pascal paillet
---
changes in v4:
* remove interrupt-parent description
* pmic1@33 renamed to pmic@33
* fix indentation
.../devicetree/bindings/mfd/st,stpmic1.txt | 131 +
include/dt-bindings/mfd/st,stpmic1.h | 46
2 files changed, 177 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/st,stpmic1.txt
create mode 100644 include/dt-bindings/mfd/st,stpmic1.h
diff --git a/Documentation/devicetree/bindings/mfd/st,stpmic1.txt
b/Documentation/devicetree/bindings/mfd/st,stpmic1.txt
new file mode 100644
index 000..bb19cc8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/st,stpmic1.txt
@@ -0,0 +1,131 @@
+* STMicroelectronics STPMIC1 Power Management IC
+
+Required parent device properties:
+- compatible: "st,stpmic1"
+- reg: The I2C slave address for the STPMIC1 chip.
+- interrupts: The interrupt line the device is connected to.
+- #interrupt-cells:Should be 1.
+- interrupt-controller:Describes the STPMIC1 as an interrupt
+ controller (has its own domain). Interrupt number are the following:
+ /* Interrupt Register 1 (0x50 for latch) */
+ IT_SWOUT_R=0
+ IT_SWOUT_F=1
+ IT_VBUS_OTG_R=2
+ IT_VBUS_OTG_F=3
+ IT_WAKEUP_R=4
+ IT_WAKEUP_F=5
+ IT_PONKEY_R=6
+ IT_PONKEY_F=7
+ /* Interrupt Register 2 (0x51 for latch) */
+ IT_OVP_BOOST=8
+ IT_OCP_BOOST=9
+ IT_OCP_SWOUT=10
+ IT_OCP_OTG=11
+ IT_CURLIM_BUCK4=12
+ IT_CURLIM_BUCK3=13
+ IT_CURLIM_BUCK2=14
+ IT_CURLIM_BUCK1=15
+ /* Interrupt Register 3 (0x52 for latch) */
+ IT_SHORT_SWOUT=16
+ IT_SHORT_SWOTG=17
+ IT_CURLIM_LDO6=18
+ IT_CURLIM_LDO5=19
+ IT_CURLIM_LDO4=20
+ IT_CURLIM_LDO3=21
+ IT_CURLIM_LDO2=22
+ IT_CURLIM_LDO1=23
+ /* Interrupt Register 3 (0x52 for latch) */
+ IT_SWIN_R=24
+ IT_SWIN_F=25
+ IT_RESERVED_1=26
+ IT_RESERVED_2=27
+ IT_VINLOW_R=28
+ IT_VINLOW_F=29
+ IT_TWARN_R=30
+ IT_TWARN_F=31
+
+Optional parent device properties:
+- st,main-control-register:
+ -bit 1: Power cycling will be performed on turn OFF condition
+ -bit 2: PWRCTRL is functional
+ -bit 3: PWRCTRL active high
+- st,pads-pull-register:
+ -bit 1: WAKEUP pull down is not active
+ -bit 2: PWRCTRL pull up is active
+ -bit 3: PWRCTRL pull down is active
+ -bit 4: WAKEUP detector is disabled
+- st,vin-control-register:
+ -bit 0: VINLOW monitoring is enabled
+ -bit [1...3]: VINLOW rising threshold
+ 000 VINOK_f + 50mV
+ 001 VINOK_f + 100mV
+ 010 VINOK_f + 150mV
+ 011 VINOK_f + 200mV
+ 100 VINOK_f + 250mV
+ 101 VINOK_f + 300mV
+ 110 VINOK_f + 350mV
+ 111 VINOK_f + 400mV
+ -bit [4...5]: VINLOW hyst
+ 00 100mV
+ 01 200mV
+ 10 300mV
+ 11 400mV
+ -bit 6: SW_OUT detector is disabled
+ -bit 7: SW_IN detector is enabled.
+- st,usb-control-register:
+ -bit 3: SW_OUT current limit
+ 0: 600mA
+ 1: 1.1A
+ -bit 4: VBUS_OTG discharge is enabled
+ -bit 5: SW_OUT discharge is enabled
+ -bit 6: VBUS_OTG detection is enabled
+ -bit 7: BOOST_OVP is disabled
+
+STPMIC1 consists in a varied group of sub-devices.
+Each sub-device binding is be described in own documentation file.
+
+Device Description
+--
+st,stpmic1-onkey : Power on key, see ../input/st,stpmic1-onkey.txt
+st,stpmic1-regulators : Regulators, see ../regulator/st,stpmic1-regulator.txt
+st,stpmic1-wdt : Watchdog, see ../watchdog/st,stpmic1-wdt.txt
+
+Example:
+
+pmic: pmic@33 {
+ compatible = "st,stpmic1";
+ reg = <0x33>;
+ interrupt-parent = <>;
+ interrupts = <0 2>;
+ st,main-control-register=<0x0c>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ onkey {
+ compatible = "st,stpmic1-onkey";
+ interrupts = ,;
+ interrupt-names = "onkey-falling", "onkey-rising";
+ power-off-time-sec = <10>;
+ };
+
+ watchdog {
+ compatible = "st,stpmic1-wdt";
+ };
+
+ regulators {
+ compatible = "st,stpmic1-regulators";
+
+ vdd_core: buck1 {
+ regulator-name = "vdd_core";
+ regulator-boot-on;
+ regulator-min-microvolt = <70>;
+ regulator-max-microvolt = <120>;
+ };
+ vdd: buck3
[PATCH v4 2/8] mfd: stpmic1: add stpmic1 driver
From: pascal paillet
stpmic1 is a pmic from STMicroelectronics. The STPMIC1 integrates 10
regulators , 3 switches, a watchdog and an input for a power on key.
Signed-off-by: pascal paillet
---
changes in v4:
* rename PONKEY_PU_ACTIVE to PONKEY_PU_INACTIVE
drivers/mfd/Kconfig | 13 ++
drivers/mfd/Makefile| 1 +
drivers/mfd/stpmic1.c | 401
include/linux/mfd/stpmic1.h | 212 +++
4 files changed, 627 insertions(+)
create mode 100644 drivers/mfd/stpmic1.c
create mode 100644 include/linux/mfd/stpmic1.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 11841f4..b8dabc7 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1855,6 +1855,19 @@ config MFD_STM32_TIMERS
for PWM and IIO Timer. This driver allow to share the
registers between the others drivers.
+config MFD_STPMIC1
+ tristate "Support for STPMIC1 PMIC"
+ depends on (I2C=y && OF)
+ select REGMAP_I2C
+ select REGMAP_IRQ
+ select MFD_CORE
+ help
+ Support for ST Microelectronics STPMIC1 PMIC. STPMIC1 MFD driver is
+ the core driver for STPMIC1 component that mainly handles interrupts.
+
+ To compile this driver as a module, choose M here: the
+ module will be called stpmic1.
+
menu "Multimedia Capabilities Port drivers"
depends on ARCH_SA1100
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 5856a94..76fff14 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -232,6 +232,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI) +=
intel_soc_pmic_chtdc_ti.o
obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
+obj-$(CONFIG_MFD_STPMIC1) += stpmic1.o
obj-$(CONFIG_MFD_SUN4I_GPADC) += sun4i-gpadc.o
obj-$(CONFIG_MFD_STM32_LPTIMER)+= stm32-lptimer.o
diff --git a/drivers/mfd/stpmic1.c b/drivers/mfd/stpmic1.c
new file mode 100644
index 000..90dfee4
--- /dev/null
+++ b/drivers/mfd/stpmic1.c
@@ -0,0 +1,401 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) STMicroelectronics 2018
+// Author: Pascal Paillet
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define STPMIC1_MAIN_IRQ 0
+#define STPMIC1_WAKEUP_IRQ 1
+
+static bool stpmic1_reg_readable(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case TURN_ON_SR:
+ case TURN_OFF_SR:
+ case ICC_LDO_TURN_OFF_SR:
+ case ICC_BUCK_TURN_OFF_SR:
+ case RREQ_STATE_SR:
+ case VERSION_SR:
+ case SWOFF_PWRCTRL_CR:
+ case PADS_PULL_CR:
+ case BUCKS_PD_CR:
+ case LDO14_PD_CR:
+ case LDO56_VREF_PD_CR:
+ case VBUS_DET_VIN_CR:
+ case PKEY_TURNOFF_CR:
+ case BUCKS_MASK_RANK_CR:
+ case BUCKS_MASK_RESET_CR:
+ case LDOS_MASK_RANK_CR:
+ case LDOS_MASK_RESET_CR:
+ case WCHDG_CR:
+ case WCHDG_TIMER_CR:
+ case BUCKS_ICCTO_CR:
+ case LDOS_ICCTO_CR:
+ case BUCK1_ACTIVE_CR:
+ case BUCK2_ACTIVE_CR:
+ case BUCK3_ACTIVE_CR:
+ case BUCK4_ACTIVE_CR:
+ case VREF_DDR_ACTIVE_CR:
+ case LDO1_ACTIVE_CR:
+ case LDO2_ACTIVE_CR:
+ case LDO3_ACTIVE_CR:
+ case LDO4_ACTIVE_CR:
+ case LDO5_ACTIVE_CR:
+ case LDO6_ACTIVE_CR:
+ case BUCK1_STDBY_CR:
+ case BUCK2_STDBY_CR:
+ case BUCK3_STDBY_CR:
+ case BUCK4_STDBY_CR:
+ case VREF_DDR_STDBY_CR:
+ case LDO1_STDBY_CR:
+ case LDO2_STDBY_CR:
+ case LDO3_STDBY_CR:
+ case LDO4_STDBY_CR:
+ case LDO5_STDBY_CR:
+ case LDO6_STDBY_CR:
+ case BST_SW_CR:
+ case INT_PENDING_R1:
+ case INT_PENDING_R2:
+ case INT_PENDING_R3:
+ case INT_PENDING_R4:
+ case INT_DBG_LATCH_R1:
+ case INT_DBG_LATCH_R2:
+ case INT_DBG_LATCH_R3:
+ case INT_DBG_LATCH_R4:
+ case INT_CLEAR_R1:
+ case INT_CLEAR_R2:
+ case INT_CLEAR_R3:
+ case INT_CLEAR_R4:
+ case INT_MASK_R1:
+ case INT_MASK_R2:
+ case INT_MASK_R3:
+ case INT_MASK_R4:
+ case INT_SET_MASK_R1:
+ case INT_SET_MASK_R2:
+ case INT_SET_MASK_R3:
+ case INT_SET_MASK_R4:
+ case INT_CLEAR_MASK_R1:
+ case INT_CLEAR_MASK_R2:
+ case INT_CLEAR_MASK_R3:
+ case INT_CLEAR_MASK_R4:
+ case INT_SRC_R1:
+ case INT_SRC_R2:
+ case INT_SRC_R3:
+ case INT_SRC_R4:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static bool stpmic1_reg_writeable(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case SWOFF_PWRCTRL_CR:
+ case PADS_PULL_CR:
+ case BUCKS_PD_CR:
+ case LDO14_PD_CR:
+ case LDO56_VREF_PD_CR:
+ case VBUS_DET_VIN_CR:
+ case PKEY_TURNOFF_CR:
+ case BUCKS_MASK_RANK_CR:
+ case
[PATCH v4 8/8] watchdog: stpmic1: add stpmic1 watchdog driver
From: pascal paillet
The stpmic1 PMIC embeds a watchdog which is disabled by default. As soon
as the watchdog is started, it must be refreshed periodically otherwise
the PMIC goes off.
Signed-off-by: pascal paillet
---
changes in v4:
* fix stop watchdog function
* Kconfig: fix grammar issue
drivers/watchdog/Kconfig | 12
drivers/watchdog/Makefile | 1 +
drivers/watchdog/stpmic1_wdt.c | 139 +
3 files changed, 152 insertions(+)
create mode 100644 drivers/watchdog/stpmic1_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 5ea8909..6d2ffef 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -806,6 +806,18 @@ config STM32_WATCHDOG
To compile this driver as a module, choose M here: the
module will be called stm32_iwdg.
+config STPMIC1_WATCHDOG
+ tristate "STPMIC1 PMIC watchdog support"
+ depends on MFD_STPMIC1
+ select WATCHDOG_CORE
+ help
+ Say Y here to include watchdog support embedded into STPMIC1 PMIC.
+ If the watchdog timer expires, stpmic1 will shut down all its power
+ supplies.
+
+ To compile this driver as a module, choose M here: the
+ module will be called spmic1_wdt.
+
config UNIPHIER_WATCHDOG
tristate "UniPhier watchdog support"
depends on ARCH_UNIPHIER || COMPILE_TEST
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index bf92e7b..2649cf3 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -217,3 +217,4 @@ obj-$(CONFIG_SOFT_WATCHDOG) += softdog.o
obj-$(CONFIG_MENF21BMC_WATCHDOG) += menf21bmc_wdt.o
obj-$(CONFIG_MENZ069_WATCHDOG) += menz69_wdt.o
obj-$(CONFIG_RAVE_SP_WATCHDOG) += rave-sp-wdt.o
+obj-$(CONFIG_STPMIC1_WATCHDOG) += stpmic1_wdt.o
diff --git a/drivers/watchdog/stpmic1_wdt.c b/drivers/watchdog/stpmic1_wdt.c
new file mode 100644
index 000..a6cbc27
--- /dev/null
+++ b/drivers/watchdog/stpmic1_wdt.c
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) STMicroelectronics 2018
+// Author: Pascal Paillet for STMicroelectronics.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* WATCHDOG CONTROL REGISTER bit */
+#define WDT_START BIT(0)
+#define WDT_PING BIT(1)
+#define WDT_START_MASK BIT(0)
+#define WDT_PING_MASK BIT(1)
+#define WDT_STOP 0
+
+#define PMIC_WDT_MIN_TIMEOUT 1
+#define PMIC_WDT_MAX_TIMEOUT 256
+#define PMIC_WDT_DEFAULT_TIMEOUT 30
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout,
+ "Watchdog cannot be stopped once started (default="
+ __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+struct stpmic1_wdt {
+ struct stpmic1 *pmic;
+ struct watchdog_device wdtdev;
+};
+
+static int pmic_wdt_start(struct watchdog_device *wdd)
+{
+ struct stpmic1_wdt *wdt = watchdog_get_drvdata(wdd);
+
+ return regmap_update_bits(wdt->pmic->regmap,
+ WCHDG_CR, WDT_START_MASK, WDT_START);
+}
+
+static int pmic_wdt_stop(struct watchdog_device *wdd)
+{
+ struct stpmic1_wdt *wdt = watchdog_get_drvdata(wdd);
+
+ return regmap_update_bits(wdt->pmic->regmap,
+ WCHDG_CR, WDT_START_MASK, WDT_STOP);
+}
+
+static int pmic_wdt_ping(struct watchdog_device *wdd)
+{
+ struct stpmic1_wdt *wdt = watchdog_get_drvdata(wdd);
+
+ return regmap_update_bits(wdt->pmic->regmap,
+ WCHDG_CR, WDT_PING_MASK, WDT_PING);
+}
+
+static int pmic_wdt_set_timeout(struct watchdog_device *wdd,
+ unsigned int timeout)
+{
+ struct stpmic1_wdt *wdt = watchdog_get_drvdata(wdd);
+
+ wdd->timeout = timeout;
+ /* timeout is equal to register value + 1 */
+ return regmap_write(wdt->pmic->regmap, WCHDG_TIMER_CR, timeout - 1);
+}
+
+static const struct watchdog_info pmic_watchdog_info = {
+ .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE,
+ .identity = "STPMIC1 PMIC Watchdog",
+};
+
+static const struct watchdog_ops pmic_watchdog_ops = {
+ .owner = THIS_MODULE,
+ .start = pmic_wdt_start,
+ .stop = pmic_wdt_stop,
+ .ping = pmic_wdt_ping,
+ .set_timeout = pmic_wdt_set_timeout,
+};
+
+static int pmic_wdt_probe(struct platform_device *pdev)
+{
+ int ret;
+ struct stpmic1 *pmic;
+ struct stpmic1_wdt *wdt;
+
+ if (!pdev->dev.parent)
+ return -EINVAL;
+
+ pmic = dev_get_drvdata(pdev->dev.parent);
+ if (!pmic)
+ return -EINVAL;
+
+ wdt = devm_kzalloc(>dev, sizeof(struct stpmic1_wdt), GFP_KERNEL);
+ if (!wdt)
+ return -ENOMEM;
+
+ wdt->pmic = pmic;
+
+ wdt->wdtdev.info = _watchdog_info;
+ wdt->wdtdev.ops = _watchdog_ops;
+
Re: [kbuild-all] [PATCH RT] rt: convert mm/kasan/quarantine_lock to raw_spinlock
On 10/06/2018 12:37 AM, Sebastian Andrzej Siewior wrote: On 2018-09-19 04:34:50 [+0800], kbuild test robot wrote: Hi Clark, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linux-rt-devel/for-kbuild-bot/current-stable] url: https://github.com/0day-ci/linux/commits/Clark-Williams/rt-convert-mm-kasan-quarantine_lock-to-raw_spinlock/20180919-021343 base: https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git for-kbuild-bot/current-stable config: x86_64-allmodconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All warnings (new ones prefixed by >>): how is this related? Could someone please explain this. It Iooks like a kbuild issue, we will looking into it. Best Regards, Rong Chen
[PATCH v2] drm/sti: clean up after drm_atomic_helper_shutdown rework
Since drm_atomic_helper_shutdown() rework it is possible to do additional
clean up in sti driver: custom plane destroy functions become useless and
clean up encoder is no more needed.
Signed-off-by: Benjamin Gaignard
---
version 2:
- try to be more smart when unbinding tvout.
drivers/gpu/drm/sti/sti_cursor.c | 9 +
drivers/gpu/drm/sti/sti_gdp.c| 9 +
drivers/gpu/drm/sti/sti_hqvdp.c | 9 +
drivers/gpu/drm/sti/sti_tvout.c | 24
4 files changed, 11 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_cursor.c b/drivers/gpu/drm/sti/sti_cursor.c
index bc908453ffb3..e1ba253055c7 100644
--- a/drivers/gpu/drm/sti/sti_cursor.c
+++ b/drivers/gpu/drm/sti/sti_cursor.c
@@ -328,13 +328,6 @@ static const struct drm_plane_helper_funcs
sti_cursor_helpers_funcs = {
.atomic_disable = sti_cursor_atomic_disable,
};
-static void sti_cursor_destroy(struct drm_plane *drm_plane)
-{
- DRM_DEBUG_DRIVER("\n");
-
- drm_plane_cleanup(drm_plane);
-}
-
static int sti_cursor_late_register(struct drm_plane *drm_plane)
{
struct sti_plane *plane = to_sti_plane(drm_plane);
@@ -346,7 +339,7 @@ static int sti_cursor_late_register(struct drm_plane
*drm_plane)
static const struct drm_plane_funcs sti_cursor_plane_helpers_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
- .destroy = sti_cursor_destroy,
+ .destroy = drm_plane_cleanup,
.reset = sti_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
index 3c19614d3f75..87b50451afd7 100644
--- a/drivers/gpu/drm/sti/sti_gdp.c
+++ b/drivers/gpu/drm/sti/sti_gdp.c
@@ -879,13 +879,6 @@ static const struct drm_plane_helper_funcs
sti_gdp_helpers_funcs = {
.atomic_disable = sti_gdp_atomic_disable,
};
-static void sti_gdp_destroy(struct drm_plane *drm_plane)
-{
- DRM_DEBUG_DRIVER("\n");
-
- drm_plane_cleanup(drm_plane);
-}
-
static int sti_gdp_late_register(struct drm_plane *drm_plane)
{
struct sti_plane *plane = to_sti_plane(drm_plane);
@@ -897,7 +890,7 @@ static int sti_gdp_late_register(struct drm_plane
*drm_plane)
static const struct drm_plane_funcs sti_gdp_plane_helpers_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
- .destroy = sti_gdp_destroy,
+ .destroy = drm_plane_cleanup,
.reset = sti_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
index 23565f52dd71..065a5b08a702 100644
--- a/drivers/gpu/drm/sti/sti_hqvdp.c
+++ b/drivers/gpu/drm/sti/sti_hqvdp.c
@@ -1256,13 +1256,6 @@ static const struct drm_plane_helper_funcs
sti_hqvdp_helpers_funcs = {
.atomic_disable = sti_hqvdp_atomic_disable,
};
-static void sti_hqvdp_destroy(struct drm_plane *drm_plane)
-{
- DRM_DEBUG_DRIVER("\n");
-
- drm_plane_cleanup(drm_plane);
-}
-
static int sti_hqvdp_late_register(struct drm_plane *drm_plane)
{
struct sti_plane *plane = to_sti_plane(drm_plane);
@@ -1274,7 +1267,7 @@ static int sti_hqvdp_late_register(struct drm_plane
*drm_plane)
static const struct drm_plane_funcs sti_hqvdp_plane_helpers_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
- .destroy = sti_hqvdp_destroy,
+ .destroy = drm_plane_cleanup,
.reset = sti_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c
index ea4a3b87fa55..1a64bcad9630 100644
--- a/drivers/gpu/drm/sti/sti_tvout.c
+++ b/drivers/gpu/drm/sti/sti_tvout.c
@@ -788,21 +788,6 @@ static void sti_tvout_create_encoders(struct drm_device
*dev,
tvout->dvo = sti_tvout_create_dvo_encoder(dev, tvout);
}
-static void sti_tvout_destroy_encoders(struct sti_tvout *tvout)
-{
- if (tvout->hdmi)
- drm_encoder_cleanup(tvout->hdmi);
- tvout->hdmi = NULL;
-
- if (tvout->hda)
- drm_encoder_cleanup(tvout->hda);
- tvout->hda = NULL;
-
- if (tvout->dvo)
- drm_encoder_cleanup(tvout->dvo);
- tvout->dvo = NULL;
-}
-
static int sti_tvout_bind(struct device *dev, struct device *master, void
*data)
{
struct sti_tvout *tvout = dev_get_drvdata(dev);
@@ -819,8 +804,15 @@ static void sti_tvout_unbind(struct device *dev, struct
device *master,
void *data)
{
struct sti_tvout *tvout = dev_get_drvdata(dev);
+
[PATCH v4 6/8] input: stpmic1: add stpmic1 onkey driver
From: pascal paillet
The stpmic1 pmic is able to manage an onkey button. This driver exposes
the stpmic1 onkey as an input device. It can also be configured to
shut-down the power supplies on a long key-press with an adjustable
duration.
Signed-off-by: pascal paillet
---
changes in v4:
* remove remove function
* merge stpmic1_onkey_dt_params() in probe function
* suppresse struct pmic_onkey_config
* rename PONKEY_PU_ACTIVE to PONKEY_PU_INACTIVE
drivers/input/misc/Kconfig | 11 +++
drivers/input/misc/Makefile| 2 +
drivers/input/misc/stpmic1_onkey.c | 197 +
3 files changed, 210 insertions(+)
create mode 100644 drivers/input/misc/stpmic1_onkey.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ca59a2b..279fb02 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -851,4 +851,15 @@ config INPUT_SC27XX_VIBRA
To compile this driver as a module, choose M here. The module will
be called sc27xx_vibra.
+config INPUT_STPMIC1_ONKEY
+ tristate "STPMIC1 PMIC Onkey support"
+ depends on MFD_STPMIC1
+ help
+ Say Y to enable support of onkey embedded into STPMIC1 PMIC. onkey
+ can be used to wakeup from low power modes and force a shut-down on
+ long press.
+
+ To compile this driver as a module, choose M here: the
+ module will be called stpmic1_onkey.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 9d0f9d1..1b44202 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o
obj-$(CONFIG_INPUT_SIRFSOC_ONKEY) += sirfsoc-onkey.o
obj-$(CONFIG_INPUT_SOC_BUTTON_ARRAY) += soc_button_array.o
obj-$(CONFIG_INPUT_SPARCSPKR) += sparcspkr.o
+obj-$(CONFIG_INPUT_STPMIC1_ONKEY) += stpmic1_onkey.o
obj-$(CONFIG_INPUT_TPS65218_PWRBUTTON) += tps65218-pwrbutton.o
obj-$(CONFIG_INPUT_TWL4030_PWRBUTTON) += twl4030-pwrbutton.o
obj-$(CONFIG_INPUT_TWL4030_VIBRA) += twl4030-vibra.o
@@ -81,3 +82,4 @@ obj-$(CONFIG_INPUT_WM831X_ON) += wm831x-on.o
obj-$(CONFIG_INPUT_XEN_KBDDEV_FRONTEND)+= xen-kbdfront.o
obj-$(CONFIG_INPUT_YEALINK)+= yealink.o
obj-$(CONFIG_INPUT_IDEAPAD_SLIDEBAR) += ideapad_slidebar.o
+
diff --git a/drivers/input/misc/stpmic1_onkey.c
b/drivers/input/misc/stpmic1_onkey.c
new file mode 100644
index 000..6a7f08b
--- /dev/null
+++ b/drivers/input/misc/stpmic1_onkey.c
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) STMicroelectronics 2018
+// Author: Pascal Paillet for STMicroelectronics.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * struct stpmic1_onkey - OnKey data
+ * @input_dev: pointer to input device
+ * @irq_falling: irq that we are hooked on to
+ * @irq_rising:irq that we are hooked on to
+ */
+struct stpmic1_onkey {
+ struct input_dev *input_dev;
+ int irq_falling;
+ int irq_rising;
+};
+
+static irqreturn_t onkey_falling_irq(int irq, void *ponkey)
+{
+ struct stpmic1_onkey *onkey = ponkey;
+ struct input_dev *input_dev = onkey->input_dev;
+
+ input_report_key(input_dev, KEY_POWER, 1);
+ pm_wakeup_event(input_dev->dev.parent, 0);
+ input_sync(input_dev);
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t onkey_rising_irq(int irq, void *ponkey)
+{
+ struct stpmic1_onkey *onkey = ponkey;
+ struct input_dev *input_dev = onkey->input_dev;
+
+ input_report_key(input_dev, KEY_POWER, 0);
+ pm_wakeup_event(input_dev->dev.parent, 0);
+ input_sync(input_dev);
+
+ return IRQ_HANDLED;
+}
+
+static int stpmic1_onkey_probe(struct platform_device *pdev)
+{
+ struct stpmic1 *pmic = dev_get_drvdata(pdev->dev.parent);
+ struct device *dev = >dev;
+ struct input_dev *input_dev;
+ struct stpmic1_onkey *onkey;
+ unsigned int val, reg = 0;
+ int error;
+
+ onkey = devm_kzalloc(dev, sizeof(*onkey), GFP_KERNEL);
+ if (!onkey)
+ return -ENOMEM;
+
+ onkey->irq_falling = platform_get_irq_byname(pdev, "onkey-falling");
+ if (onkey->irq_falling < 0) {
+ dev_err(dev, "failed: request IRQ onkey-falling %d\n",
+ onkey->irq_falling);
+ return onkey->irq_falling;
+ }
+
+ onkey->irq_rising = platform_get_irq_byname(pdev, "onkey-rising");
+ if (onkey->irq_rising < 0) {
+ dev_err(dev, "failed: request IRQ onkey-rising %d\n",
+ onkey->irq_rising);
+ return onkey->irq_rising;
+ }
+
+ if (!device_property_read_u32(dev, "power-off-time-sec", )) {
+ if ((val > 0) && (val <= 16)) {
+ dev_dbg(dev, "power-off-time=%d seconds\n", val);
+ reg |=
Linux 4.9.134
I'm announcing the release of the 4.9.134 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/devicetree/bindings/net/macb.txt|1 Documentation/networking/ip-sysctl.txt| 13 Makefile |2 arch/arm/boot/dts/sama5d3_emac.dtsi |2 arch/x86/include/uapi/asm/kvm.h |1 arch/x86/kvm/lapic.c | 22 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c |2 drivers/i2c/busses/i2c-scmi.c |1 drivers/mfd/omap-usb-host.c | 11 drivers/net/bonding/bond_main.c | 43 - drivers/net/dsa/bcm_sf2.c | 12 drivers/net/ethernet/broadcom/bcmsysport.c| 22 drivers/net/ethernet/broadcom/bnxt/bnxt.c | 13 drivers/net/ethernet/cadence/macb.c |8 drivers/net/ethernet/hisilicon/hns/hnae.c |2 drivers/net/ethernet/hisilicon/hns/hns_enet.c | 30 drivers/net/ethernet/marvell/mvpp2.c | 10 drivers/net/ethernet/qlogic/qlcnic/qlcnic.h |8 drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c |3 drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.h |3 drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.h|3 drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c| 12 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c |5 drivers/net/team/team.c |5 drivers/net/usb/qmi_wwan.c|1 drivers/net/usb/smsc75xx.c|1 drivers/scsi/qla2xxx/qla_target.h |4 drivers/target/iscsi/iscsi_target.c | 22 drivers/usb/host/xhci-hub.c | 18 drivers/video/fbdev/aty/atyfb.h |3 drivers/video/fbdev/aty/atyfb_base.c |7 drivers/video/fbdev/aty/mach64_ct.c | 10 fs/ext4/xattr.c |2 include/linux/netdevice.h |7 include/linux/rhashtable.h|4 include/linux/skbuff.h| 34 - include/net/bonding.h |7 include/net/inet_frag.h | 133 +--- include/net/inet_sock.h |6 include/net/ip.h |1 include/net/ip_fib.h |1 include/net/ipv6.h| 26 include/uapi/linux/snmp.h |1 lib/rhashtable.c |5 mm/vmstat.c |1 net/core/dev.c| 28 net/core/rtnetlink.c |6 net/core/skbuff.c | 31 net/dccp/input.c |4 net/dccp/ipv4.c |4 net/ieee802154/6lowpan/6lowpan_i.h| 26 net/ieee802154/6lowpan/reassembly.c | 148 ++-- net/ipv4/fib_frontend.c | 12 net/ipv4/fib_semantics.c | 50 + net/ipv4/inet_connection_sock.c |5 net/ipv4/inet_fragment.c | 379 ++- net/ipv4/ip_fragment.c| 573 +- net/ipv4/ip_sockglue.c|3 net/ipv4/ip_tunnel.c |9 net/ipv4/proc.c |7 net/ipv4/tcp_input.c | 37 - net/ipv4/tcp_ipv4.c |4 net/ipv6/addrconf.c |4 net/ipv6/ip6_tunnel.c | 13 net/ipv6/netfilter/nf_conntrack_reasm.c | 100 +-- net/ipv6/proc.c |5 net/ipv6/raw.c| 29 net/ipv6/reassembly.c | 212 +++--- net/netlabel/netlabel_unlabeled.c |3 sound/hda/hdac_controller.c |8 sound/soc/codecs/sigmadsp.c |3 sound/soc/codecs/wm8804-i2c.c |
[PATCH v4 3/8] dt-bindings: regulator: document stpmic1 pmic regulators
From: pascal paillet
The STPMIC1 regulators supply power to the application processor as well as
to the external system peripherals such as DDR, Flash memories and system
devices.
Signed-off-by: pascal paillet
Reviewed-by: Rob Herring
---
changes in v4: nothing
.../bindings/regulator/st,stpmic1-regulator.txt| 68 ++
1 file changed, 68 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/st,stpmic1-regulator.txt
diff --git
a/Documentation/devicetree/bindings/regulator/st,stpmic1-regulator.txt
b/Documentation/devicetree/bindings/regulator/st,stpmic1-regulator.txt
new file mode 100644
index 000..a3f4762
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/st,stpmic1-regulator.txt
@@ -0,0 +1,68 @@
+STMicroelectronics STPMIC1 Voltage regulators
+
+Regulator Nodes are optional depending on needs.
+
+Available Regulators in STPMIC1 device are:
+ - buck1 for Buck BUCK1
+ - buck2 for Buck BUCK2
+ - buck3 for Buck BUCK3
+ - buck4 for Buck BUCK4
+ - ldo1 for LDO LDO1
+ - ldo2 for LDO LDO2
+ - ldo3 for LDO LDO3
+ - ldo4 for LDO LDO4
+ - ldo5 for LDO LDO5
+ - ldo6 for LDO LDO6
+ - vref_ddr for LDO Vref DDR
+ - boost for Buck BOOST
+ - pwr_sw1 for VBUS_OTG switch
+ - pwr_sw2 for SW_OUT switch
+
+Switches are fixed voltage regulators with only enable/disable capability.
+
+Optional properties:
+- st,mask-reset: mask reset for this regulator: the regulator configuration
+ is maintained during pmic reset.
+- regulator-pull-down: enable high pull down
+ if not specified light pull down is used
+- regulator-over-current-protection:
+if set, all regulators are switched off in case of over-current detection
+on this regulator,
+if not set, the driver only sends an over-current event.
+- interrupt-parent: phandle to the parent interrupt controller
+- interrupts: index of current limit detection interrupt
+- -supply: phandle to the parent supply/regulator node
+ each regulator supply can be described except vref_ddr.
+
+Example:
+regulators {
+ compatible = "st,stpmic1-regulators";
+
+ ldo6-supply = <>;
+
+ vdd_core: buck1 {
+ regulator-name = "vdd_core";
+ interrupts = ;
+ interrupt-parent = <>;
+ st,mask-reset;
+ regulator-pull-down;
+ regulator-min-microvolt = <70>;
+ regulator-max-microvolt = <120>;
+ };
+
+ v3v3: buck4 {
+ regulator-name = "v3v3";
+ interrupts = ;
+ interrupt-parent = <>;
+
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
+ v1v8: ldo6 {
+ regulator-name = "v1v8";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-over-current-protection;
+ };
+};
--
1.9.1
[PATCH v4 7/8] dt-bindings: watchdog: document stpmic1 pmic watchdog
From: pascal paillet
The stpmic1 PMIC embeds a watchdog which is disabled by default.
In case of watchdog, the PMIC goes off.
Signed-off-by: pascal paillet
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt | 11 +++
1 file changed, 11 insertions(+)
create mode 100644
Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt
b/Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt
new file mode 100644
index 000..7cc1407
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt
@@ -0,0 +1,11 @@
+STMicroelectronics STPMIC1 Watchdog
+
+Required properties:
+
+- compatible : should be "st,stpmic1-wdt"
+
+Example:
+
+watchdog {
+ compatible = "st,stpmic1-wdt";
+};
--
1.9.1
[no subject]
From: Stefan Popa To: ji...@kernel.org Cc: michael.henner...@analog.com, knaac...@gmx.de, l...@metafoo.de, pme...@pmeerw.net, gre...@linuxfoundation.org, linux-kernel@vger.kernel.org, linux-...@vger.kernel.org, de...@driverdev.osuosl.org, stefan.p...@analog.com Subject: [PATCH 1/2] staging: iio: ad7606: Move out of staging Date: Thu, 18 Oct 2018 12:08:32 +0300 Message-Id: <1539853712-26253-1-git-send-email-stefan.p...@analog.com> X-Mailer: git-send-email 2.7.4 Move ad7606 ADC driver out of staging and into the mainline. Signed-off-by: Stefan Popa --- MAINTAINERS | 7 + drivers/iio/adc/Kconfig | 34 +++ drivers/iio/adc/Makefile | 3 + drivers/iio/adc/ad7606.c | 565 +++ drivers/iio/adc/ad7606.h | 106 +++ drivers/iio/adc/ad7606_par.c | 113 +++ drivers/iio/adc/ad7606_spi.c | 79 + drivers/staging/iio/adc/Kconfig | 34 --- drivers/staging/iio/adc/Makefile | 3 - drivers/staging/iio/adc/ad7606.c | 565 --- drivers/staging/iio/adc/ad7606.h | 106 --- drivers/staging/iio/adc/ad7606_par.c | 113 --- drivers/staging/iio/adc/ad7606_spi.c | 79 - 13 files changed, 907 insertions(+), 900 deletions(-) create mode 100644 drivers/iio/adc/ad7606.c create mode 100644 drivers/iio/adc/ad7606.h create mode 100644 drivers/iio/adc/ad7606_par.c create mode 100644 drivers/iio/adc/ad7606_spi.c delete mode 100644 drivers/staging/iio/adc/ad7606.c delete mode 100644 drivers/staging/iio/adc/ad7606.h delete mode 100644 drivers/staging/iio/adc/ad7606_par.c delete mode 100644 drivers/staging/iio/adc/ad7606_spi.c diff --git a/MAINTAINERS b/MAINTAINERS index f642044..843545d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -839,6 +839,13 @@ S: Supported F: drivers/iio/dac/ad5758.c F: Documentation/devicetree/bindings/iio/dac/ad5758.txt +ANALOG DEVICES INC AD7606 DRIVER +M: Stefan Popa +L: linux-...@vger.kernel.org +W: http://ez.analog.com/community/linux-device-drivers +S: Supported +F: drivers/iio/adc/ad7606.c + ANALOG DEVICES INC AD9389B DRIVER M: Hans Verkuil L: linux-me...@vger.kernel.org diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index a52fea8..22bafdc 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -58,6 +58,40 @@ config AD7476 To compile this driver as a module, choose M here: the module will be called ad7476. +config AD7606 + tristate "Analog Devices AD7606 ADC driver" + depends on GPIOLIB || COMPILE_TEST + depends on HAS_IOMEM + select IIO_BUFFER + select IIO_TRIGGERED_BUFFER + help + Say yes here to build support for Analog Devices: + ad7605-4, ad7606, ad7606-6, ad7606-4 analog to digital converters (ADC). + + To compile this driver as a module, choose M here: the + module will be called ad7606. + +config AD7606_IFACE_PARALLEL + tristate "parallel interface support" + depends on AD7606 + help + Say yes here to include parallel interface support on the AD7606 + ADC driver. + + To compile this driver as a module, choose M here: the + module will be called ad7606_parallel. + +config AD7606_IFACE_SPI + tristate "spi interface support" + depends on AD7606 + depends on SPI + help + Say yes here to include parallel interface support on the AD7606 + ADC driver. + + To compile this driver as a module, choose M here: the + module will be called ad7606_spi. + config AD7766 tristate "Analog Devices AD7766/AD7767 ADC driver" depends on SPI_MASTER diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index a6e6a0b..b734f4f 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -8,6 +8,9 @@ obj-$(CONFIG_AD_SIGMA_DELTA) += ad_sigma_delta.o obj-$(CONFIG_AD7266) += ad7266.o obj-$(CONFIG_AD7291) += ad7291.o obj-$(CONFIG_AD7298) += ad7298.o +obj-$(CONFIG_AD7606_IFACE_PARALLEL) += ad7606_par.o +obj-$(CONFIG_AD7606_IFACE_SPI) += ad7606_spi.o +obj-$(CONFIG_AD7606) += ad7606.o obj-$(CONFIG_AD7923) += ad7923.o obj-$(CONFIG_AD7476) += ad7476.o obj-$(CONFIG_AD7766) += ad7766.o diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c new file mode 100644 index 000..0b728b6 --- /dev/null +++ b/drivers/iio/adc/ad7606.c @@ -0,0 +1,565 @@ +/* + * AD7606 SPI ADC driver + * + * Copyright 2011 Analog Devices Inc. + * + * Licensed under the GPL-2. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#include "ad7606.h" + +/* + * Scales are computed as 5000/32768 and 1/32768 respectively, + * so that when
Re: [PATCH] cacheinfo: Keep the old value if of_property_read_u32 fails
Hi Huacai, On Thu, Oct 18, 2018 at 09:28:11AM +0800, Huacai Chen wrote: > Hi, Sudeep, > > Please see this call-graph: > > static int detect_cache_attributes(unsigned int cpu) > > ret = populate_cache_leaves(cpu); > > ret = cache_shared_cpu_map_setup(cpu); --> > cache_setup_of_node() --> cache_of_set_props() --> > cache_size()/cache_nr_sets > > populate_cache_leaves() is arch-specific, All archs except arm64 have > provide initial values to cacheinfo:size and cacheinfo:number_of_sets. > > Related files: > arch/nds32/kernel/cacheinfo.c > arch/mips/kernel/cacheinfo.c Only above 2 could be affected, but I want to be sure. I wasn't aware of MIPS arch setting values elsewhere, assumed DT, my bad. You have still not answered my question. Which arch are you facing issue ? Or are you proposing this by code inspection ? I changes look fine, but want to be sure if the issue you are seeing is in above architectures. -- Regards, Sudeep
Re: [PATCH 1/4] Adds -Wshadow=local on KBUILD_HOSTCFLAGS
On Wed, Oct 17, 2018 at 09:40:53PM -0300, Leonardo Bras wrote: > The idea was to put it as default and fix all the shadowing warnings. > What do you think? I am open to suggestions. That's Masahiro's call. In the rest of the kernel, those warnings are behind the W=2 switch - i.e., not enabled by default. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH 4.18 000/135] 4.18.15-stable review
On Wed, Oct 17, 2018 at 12:30:28PM -0600, Shuah Khan wrote: > On 10/16/2018 11:03 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.18.15 release. > > There are 135 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 Thu Oct 18 17:04:43 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.18.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.18.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. Thanks for testing all three of these and letting me know. greg k-h
Re: statx(2) API and documentation
On Wed, Oct 17, 2018 at 10:22 PM, Andreas Dilger wrote: > On Oct 17, 2018, at 1:04 PM, Miklos Szeredi wrote: >> So what's the point exactly? > > Ah, I see your point... STATX_ALL seems to be mostly useful for the kernel > to mask off flags that it doesn't currently understand. And even there it's quite pointless, since no sane implementation would put the request mask into the result mask (aka. stx_mask) verbatim, without picking out bits which correspond to *supported* fields. So it's pointless across the board. But since it's already published in a userspace API, the best we can do is leave it at its current value, but with a comment to warn that it should not be updated when new flags are added. And remove all traces of it from the kernel. >> Right, OTOH I sort of see the value in NFS: no roundtrip to server if >> atime value is useless anyway. > > Well, "noatime" might be a client-only option, which doesn't mean that the > server or some other client isn't updating the atime. Returning an old > atime isn't the same as not returning anything at all. Fs is allowed (and in case of basic stats, required) to fill in dummy values for even unsupported fields. I understand your argument, since that was my first thought, but I also understand the reason behind clearing STATX_ATIME. And atime is something that very few applications care about anyway. But I do think such behavior should be clarified in the documentation and handled more consistently in the code. > To my thinking, if the user/app requests btime/ctime/size/blocks the kernel > should return these fields. If DONT_SYNC is set, it means the kernel can > return potentially stale values, but if the kernel doesn't have *any* > values for these fields at all it still should query the server instead of > just returning random garbage. I'm not saying it should return garbage, instead it can just not set the bit in the result mask to indicate that that field cannot be filled (without network traffic, in this case). This requires generalizing the definition of the result mask, because the above (clearing STATX_ATIME on ro/noatim or clearing STATX_BTIME on DONT_SYNC) don't fit the current "unsupported or unrepresentable" definition. > That said, it seems that it isn't even possible to get into nfs_getattr() > without the VFS having instantiated a dentry and inode (i.e. queried the > server via nfs_lookup() at some point), so the inode fields have already > been filled with *something*. There's no "i_btime" field. But it's hard to argue this point with btime, so lets instead think about a theoretical attribute that is: - hard to calculate, so filesystem will not want to cache it on inode initialization (because it's very unlikely to be actually needed) - isn't constant and can be cached, so all sync types make sense. I think the following semantics would be the most useful and sane: FORCE_SYNC or SYNC_AS_STAT would always retrieve the attribute if supported, and set the bit in the result mask; DONT_SYNC would only set the bit in the result mask if the attribute is already cached. Thanks, Miklos
Re: [v5 2/4] mpt3sas: Fix Sync cache command failure during driver unload
On Thu, Oct 18, 2018 at 10:11 AM Suganath Prabu Subramani
wrote:
>
>
>
> On Wed, Oct 17, 2018 at 2:02 PM Andy Shevchenko
> wrote:
>>
>> On Wed, Oct 17, 2018 at 8:59 AM Suganath Prabu
>> wrote:
>> >
>> > This is to fix Sync cache and start stop command
>> > failures with DID_NO_CONNECT during driver unload.
>> >
>> > 1) Release drives first from SML, then remove internally
>> > in driver.
>> > 2) And allow sync cache and Start stop commands to firmware,
>> > even when remove_host flag is set.
>>
>> > + if (ioc->hba_mpi_version_belonged == MPI2_VERSION) {
>> > + if (ioc->remove_host)
>> > + return false;
>> > +
>> > + return true;
>> > + }
>> > +
>> > + if (ioc->remove_host) {
>> > +
>> > + switch (scmd->cmnd[0]) {
>> > + case SYNCHRONIZE_CACHE:
>> > + case START_STOP:
>> > + return true;
>> > + default:
>> > + return false;
>> > + }
>> > + }
>> > +
>> > + return true;
>>
>> Wouldn't be the same as
>> Yes it is same, but i feel original code is more readable.
OK (I didn't compare assembly, but I assume this is slow path).
>> if (!ioc->remove_host || ioc->hba_mpi_version_belonged == MPI2_VERSION)
>>return !ioc->remove_host;
>>
>> switch (scmd->cmnd[0]) {
>> case SYNCHRONIZE_CACHE:
>> case START_STOP:
>>return true;
>> default:
>>return false;
>> }
>>
>> ?
>>
>> --
>> With Best Regards,
>> Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 0/2] [GIT PULL] tracing: Two fixes for 4.19
On Wed, Oct 17, 2018 at 03:49:39PM -0400, Steven Rostedt wrote: > > Linus (aka Greg), > > This fixes two bugs: > > - Fix size mismatch of tracepoint array > > - Have preemptirq test module use same clock source of the selftest Now pulled, thanks. greg k-h
Re: statx(2) API and documentation
* Jan Kara: > On Thu 18-10-18 01:15:13, Amir Goldstein wrote: >> FYI, I identified a similar anti-pattern in fanotify UAPI when I wanted to >> add new flags and did not want to change the UAPI _ALL_ constants. >> This is how we plan to solve it: >> https://github.com/amir73il/linux/commit/8c2b1acadb88ee4505ccc8bfdc665863111fb4cc > > Yeah, after fanotify experience I find foo_ALL constants useless if not > dangerous for userspace. Kernel internal constants like this are IMO > useful. There are also various *_MAX constants which are increased regularly. Some of them are part of the UAPI headers (INET_DIAG_MAX appears to be a relevant example), some are no longer in UAPI, but still in custom glibc headers (AF_MAX/PF_MAX). These appear to be equally useless.
[PATCH 2/2] dmaengine: mediatek: Add MediaTek Command-Queue DMA controller for MT6765 SoC
From: Shun-Chih Yu
MediaTek Command-Queue DMA controller (CQDMA) on MT6765 SoC is dedicated
to memory-to-memory transfer through queue based descriptor management.
There are only 3 physical channels inside CQDMA, while the driver is
extended to support 32 virtual channels for multiple dma users to issue
dma requests onto the CQDMA simultaneously.
Signed-off-by: Shun-Chih Yu
---
drivers/dma/mediatek/Kconfig | 13 +
drivers/dma/mediatek/Makefile|1 +
drivers/dma/mediatek/mtk-cqdma.c | 951 ++
3 files changed, 965 insertions(+)
create mode 100644 drivers/dma/mediatek/mtk-cqdma.c
diff --git a/drivers/dma/mediatek/Kconfig b/drivers/dma/mediatek/Kconfig
index 27bac0b..680fc05 100644
--- a/drivers/dma/mediatek/Kconfig
+++ b/drivers/dma/mediatek/Kconfig
@@ -11,3 +11,16 @@ config MTK_HSDMA
This controller provides the channels which is dedicated to
memory-to-memory transfer to offload from CPU through ring-
based descriptor management.
+
+config MTK_CQDMA
+ tristate "MediaTek Command-Queue DMA controller support"
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ select ASYNC_TX_ENABLE_CHANNEL_SWITCH
+ help
+ Enable support for Command-Queue DMA controller on MediaTek
+ SoCs.
+
+ This controller provides the channels which is dedicated to
+ memory-to-memory transfer to offload from CPU.
diff --git a/drivers/dma/mediatek/Makefile b/drivers/dma/mediatek/Makefile
index 6e778f8..41bb381 100644
--- a/drivers/dma/mediatek/Makefile
+++ b/drivers/dma/mediatek/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_MTK_HSDMA) += mtk-hsdma.o
+obj-$(CONFIG_MTK_CQDMA) += mtk-cqdma.o
diff --git a/drivers/dma/mediatek/mtk-cqdma.c b/drivers/dma/mediatek/mtk-cqdma.c
new file mode 100644
index 000..131f397
--- /dev/null
+++ b/drivers/dma/mediatek/mtk-cqdma.c
@@ -0,0 +1,951 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018-2019 MediaTek Inc.
+
+/*
+ * Driver for MediaTek Command-Queue DMA Controller
+ *
+ * Author: Shun-Chih Yu
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../virt-dma.h"
+
+#define MTK_CQDMA_USEC_POLL10
+#define MTK_CQDMA_TIMEOUT_POLL 1000
+#define MTK_CQDMA_DMA_BUSWIDTHSBIT(DMA_SLAVE_BUSWIDTH_4_BYTES)
+#define MTK_CQDMA_ALIGN_SIZE 1
+
+/* The default number of virtual channel */
+#define MTK_CQDMA_NR_VCHANS32
+
+/* The default number of physical channel */
+#define MTK_CQDMA_NR_PCHANS3
+
+/* Registers for underlying dma manipulation */
+#define MTK_CQDMA_INT_FLAG 0x0
+#define MTK_CQDMA_INT_EN 0x4
+#define MTK_CQDMA_EN 0x8
+#define MTK_CQDMA_RESET0xc
+#define MTK_CQDMA_FLUSH0x14
+#define MTK_CQDMA_SRC 0x1c
+#define MTK_CQDMA_DST 0x20
+#define MTK_CQDMA_LEN1 0x24
+#define MTK_CQDMA_LEN2 0x28
+#define MTK_CQDMA_SRC2 0x60
+#define MTK_CQDMA_DST2 0x64
+
+/* Registers setting */
+#define MTK_CQDMA_EN_BIT BIT(0)
+#define MTK_CQDMA_INT_FLAG_BIT BIT(0)
+#define MTK_CQDMA_INT_EN_BIT BIT(0)
+#define MTK_CQDMA_FLUSH_BITBIT(0)
+
+#define MTK_CQDMA_WARM_RST_BIT BIT(0)
+#define MTK_CQDMA_HARD_RST_BIT BIT(1)
+
+#define MTK_CQDMA_MAX_LEN GENMASK(27, 0)
+#define MTK_CQDMA_ADDR_LIMIT GENMASK(31, 0)
+#define MTK_CQDMA_ADDR2_SHFIT (32)
+
+/**
+ * struct mtk_cqdma_vdesc - The struct holding info describing virtual
+ * descriptor (CVD)
+ * @vd:An instance for struct virt_dma_desc
+ * @len: The total data size device wants to move
+ * @residue: The remaining data size device will move
+ * @dest: The destination address device wants to move to
+ * @src: The source address device wants to move from
+ * @ch:The pointer to the corresponding dma channel
+ * @node: The lise_head struct to build link-list for VDs
+ * @parent:The pointer to the parent CVD
+ */
+struct mtk_cqdma_vdesc {
+ struct virt_dma_desc vd;
+ size_t len;
+ size_t residue;
+ dma_addr_t dest;
+ dma_addr_t src;
+ struct dma_chan *ch;
+
+ struct list_head node;
+ struct mtk_cqdma_vdesc *parent;
+};
+
+/**
+ * struct mtk_cqdma_pchan - The struct holding info describing physical
+ * channel (PC)
+ * @queue: Queue for the PDs issued to this PC
+ * @base: The mapped register I/O base of this PC
+ * @irq: The
[PATCH v3] add support for Mediatek Command-Queue DMA controller on MT6765 SoC
Changes since v2: - fix build warning for kernel with DMA address in 32-bit Changes since v1: - remove unused macros, typos - leverage ASYNC_TX_ENABLE_CHANNEL_SWITCH to maintain DMA descriptor list Shun-Chih Yu (2): dt-bindings: dmaengine: Add MediaTek Command-Queue DMA controller bindings dmaengine: mediatek: Add MediaTek Command-Queue DMA controller for MT6765 SoC .../devicetree/bindings/dma/mtk-cqdma.txt | 31 + drivers/dma/mediatek/Kconfig | 13 + drivers/dma/mediatek/Makefile |1 + drivers/dma/mediatek/mtk-cqdma.c | 951 4 files changed, 996 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/mtk-cqdma.txt create mode 100644 drivers/dma/mediatek/mtk-cqdma.c
[PATCH 1/2] dt-bindings: dmaengine: Add MediaTek Command-Queue DMA controller bindings
From: Shun-Chih Yu
Document the devicetree bindings for MediaTek Command-Queue DMA controller
which could be found on MT6765 SoC or other similar Mediatek SoCs.
Signed-off-by: Shun-Chih Yu
Reviewed-by: Rob Herring
---
.../devicetree/bindings/dma/mtk-cqdma.txt | 31
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/mtk-cqdma.txt
diff --git a/Documentation/devicetree/bindings/dma/mtk-cqdma.txt
b/Documentation/devicetree/bindings/dma/mtk-cqdma.txt
new file mode 100644
index 000..fb12927
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/mtk-cqdma.txt
@@ -0,0 +1,31 @@
+MediaTek Command-Queue DMA Controller
+==
+
+Required properties:
+
+- compatible: Must be "mediatek,mt6765-cqdma" for MT6765.
+- reg: Should contain the base address and length for each channel.
+- interrupts: Should contain references to the interrupts for each channel.
+- clocks: Should be the clock specifiers corresponding to the entry in
+ clock-names property.
+- clock-names: Should contain "cqdma" entries.
+- dma-channels: The number of DMA channels supported by the controller.
+- dma-requests: The number of DMA request supported by the controller.
+- #dma-cells: The length of the DMA specifier, must be <1>. This one cell
+ in dmas property of a client device represents the channel
+ number.
+Example:
+
+cqdma: dma-controller@10212000 {
+ compatible = "mediatek,mt6765-cqdma";
+ reg = <0 0x10212000 0 0x1000>;
+ interrupts = ,
+ ;
+ clocks = < CLK_IFR_CQ_DMA>;
+ clock-names = "cqdma";
+ dma-channels = <2>;
+ dma-requests = <32>;
+ #dma-cells = <1>;
+ };
+
+DMA clients must use the format described in dma/dma.txt file.
--
1.7.9.5
Re: [RFC PATCH 0/7] Introduce thermal pressure
* Rafael J. Wysocki wrote: > > The only long term maintainable solution is to move all high level > > cpufreq logic and policy handling code into kernel/sched/cpufreq*.c, > > which has been done to a fair degree already in the past ~2 years - but > > it's unclear to me to what extent this is true for thermal throttling > > policy currently: there might be more governor surgery and code > > reshuffling required? > > It doesn't cover thermal management directly ATM. > > The EAS work kind of hopes to make a connection in there by adding a > common energy model to underlie both the performance scaling and > thermal management, but it doesn't change the thermal decision making > part AFAICS. > > So it is fair to say that additional governor surgery and code > reshuffling will be required IMO. BTW., when factoring out high level thermal management code it might make sense to increase the prominence of the cpufreq code within the scheduler and organize it a bit better, by introducing its own kernel/sched/cpufreq/ directory and renaming things the following way: kernel/sched/cpufreq.c=> kernel/sched/cpufreq/core.c kernel/sched/cpufreq_schedutil.c => kernel/sched/cpufreq/metrics.c kernel/sched/thermal.c=> kernel/sched/cpufreq/thermal.c ... or so? With no change to functionality, this is just a re-organization and expansion/preparation for the bright future. =B-) Thanks, Ingo
[PATCH] ARM: dts: imx: Add dummy PHYs for HSIC-only USB controllers
Some SOCs in the i.MX6 family have a USB host controller that is
only capable of the HSIC interface and has no on-board PHY.
To be able to use these controllers, we need to add "usb-nop-xceiv"
dummy PHYs.
Signed-off-by: Frieder Schrempf
---
arch/arm/boot/dts/imx6qdl.dtsi | 14 ++
arch/arm/boot/dts/imx6sl.dtsi | 7 +++
arch/arm/boot/dts/imx6sx.dtsi | 6 ++
3 files changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 61d2d26..d3404d1 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -139,6 +139,16 @@
interrupts = <0 94 IRQ_TYPE_LEVEL_HIGH>;
};
+ usbphynop1: usbphynop1 {
+ compatible = "usb-nop-xceiv";
+ #phy-cells = <0>;
+ };
+
+ usbphynop2: usbphynop2 {
+ compatible = "usb-nop-xceiv";
+ #phy-cells = <0>;
+ };
+
soc {
#address-cells = <1>;
#size-cells = <1>;
@@ -981,6 +991,8 @@
reg = <0x02184400 0x200>;
interrupts = <0 41 IRQ_TYPE_LEVEL_HIGH>;
clocks = < IMX6QDL_CLK_USBOH3>;
+ fsl,usbphy = <>;
+ phy_type = "hsic";
fsl,usbmisc = < 2>;
dr_mode = "host";
ahb-burst-config = <0x0>;
@@ -994,6 +1006,8 @@
reg = <0x02184600 0x200>;
interrupts = <0 42 IRQ_TYPE_LEVEL_HIGH>;
clocks = < IMX6QDL_CLK_USBOH3>;
+ fsl,usbphy = <>;
+ phy_type = "hsic";
fsl,usbmisc = < 3>;
dr_mode = "host";
ahb-burst-config = <0x0>;
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 7a4f5da..81edcdc 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -110,6 +110,11 @@
interrupts = <0 94 IRQ_TYPE_LEVEL_HIGH>;
};
+ usbphynop1: usbphynop1 {
+ compatible = "usb-nop-xceiv";
+ #phy-cells = <0>;
+ };
+
soc {
#address-cells = <1>;
#size-cells = <1>;
@@ -815,6 +820,8 @@
reg = <0x02184400 0x200>;
interrupts = <0 40 IRQ_TYPE_LEVEL_HIGH>;
clocks = < IMX6SL_CLK_USBOH3>;
+ fsl,usbphy = <>;
+ phy_type = "hsic";
fsl,usbmisc = < 2>;
dr_mode = "host";
ahb-burst-config = <0x0>;
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 844caa3..07ed417 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -159,6 +159,11 @@
interrupts = ;
};
+ usbphynop1: usbphynop1 {
+ compatible = "usb-nop-xceiv";
+ #phy-cells = <0>;
+ };
+
soc {
#address-cells = <1>;
#size-cells = <1>;
@@ -877,6 +882,7 @@
reg = <0x02184400 0x200>;
interrupts = ;
clocks = < IMX6SX_CLK_USBOH3>;
+ fsl,usbphy = <>;
fsl,usbmisc = < 2>;
phy_type = "hsic";
fsl,anatop = <>;
--
2.7.4
Re: [RFC PATCH 0/7] Introduce thermal pressure
On 10/17/2018 06:24 PM, Thara Gopinath wrote: > On 10/16/2018 01:11 PM, Vincent Guittot wrote: >> Hi Lukasz, >> >> On Thu, 11 Oct 2018 at 13:10, Lukasz Luba wrote: >>> >>> >>> >>> On 10/10/2018 07:30 PM, Thara Gopinath wrote: Hello Lukasz, On 10/10/2018 11:35 AM, Lukasz Luba wrote: > Hi Thara, > > I have run it on Exynos5433 mainline. > When it is enabled with step_wise thermal governor, > some of my tests are showing ~30-50% regression (i.e. hackbench), > dhrystone ~10%. That is interesting. If I understand correctly, dhrystone spawns 16 threads or so and floods the system. In "theory", such a test should not see any performance improvement and degradation. What is the thermal activity like in your system? I will try running one of these tests on hikey960. >>> I use this dhrystone implementation: >>> https://github.com/Keith-S-Thompson/dhrystone/blob/master/v2.2/dry.c >>> It does not span new threads/processes and I pinned it to a single cpu. >>> >>> My thermal setup is probably different than yours. >>> You have (on hikey960) probably 1 sensor for whole SoC and one thermal >>> zone (if it is this mainline file: >>> arch/arm64/boot/dts/hisilicon/hi3660.dtsi). >>> This thermal zone has two cooling devices - two clusters with dvfs. >>> Your temperature signal read out from that sensor is probably much >>> smoother. When you have sensor inside cluster, the rising factor >>> can be even 20deg/s (for big cores). >>> In my case, there are 4 thermal zones, each cluster has it's private >>> sensor and thermal zone. There is no 'SoC sensor' or 'PCB sensor', >>> which is recommended for IPA. > > Could you tell me which thermal governor was used in your case? > Please also share the name of that benchmark, i will give it a try. > Is it single threaded compute-intensive? Step-wise governor. I use aobench which is part of phoronix-test-suite. Regards Thara >>> I have built this aobench and run it pinned to single big cpu: >>> time taskset -c 4 ./aobench >> >> Why have you pinned the test only on CPU4 ? >> Goal of thermal pressure is to inform the scheduler of reduced compute >> capacity and help the scheduler to take better decision in tasks >> placement. > > Hi Lukasz, > > I agree with Vincent's observation. I had not seen this earlier. Pinning > a task to a cpu will obviously prevent migration. The performance > regression could be due to as Vincent mentioned below other tasks in the > system. On another note, which cpufreq governor are you using? Is the > core being bumped up to highest possible OPP during the test? The governor is ondemand. No, it is not at highest OPP. Could you send me the needed test configuration and condition? We would then align in this area. Regards, Lukasz > > Regards > Thara >> So I would not expect perf impact on your test as the bench will stay >> pinned on the cpu4 >> That being said you obviously have perf impact as shown below in your results >> And other tasks on the system are not pinned and might come and >> disturb your bench >> >>> The results: >>> 3min-5:30min [mainline] >>> 5:15min-5:50min [+patchset] >>> >>> The idea is definitely worth to investigate further. >> >> Yes I agree >> >> Vincent >>> >>> Regards, >>> Lukasz >>> >>> >>> > >
Re: [RFC PATCH 0/7] Introduce thermal pressure
On Thu, Oct 18, 2018 at 9:50 AM Ingo Molnar wrote: > > > * Rafael J. Wysocki wrote: > > > > The only long term maintainable solution is to move all high level > > > cpufreq logic and policy handling code into kernel/sched/cpufreq*.c, > > > which has been done to a fair degree already in the past ~2 years - but > > > it's unclear to me to what extent this is true for thermal throttling > > > policy currently: there might be more governor surgery and code > > > reshuffling required? > > > > It doesn't cover thermal management directly ATM. > > > > The EAS work kind of hopes to make a connection in there by adding a > > common energy model to underlie both the performance scaling and > > thermal management, but it doesn't change the thermal decision making > > part AFAICS. > > > > So it is fair to say that additional governor surgery and code > > reshuffling will be required IMO. > > BTW., when factoring out high level thermal management code it might make > sense to increase the prominence of the cpufreq code within the scheduler > and organize it a bit better, by introducing its own > kernel/sched/cpufreq/ directory and renaming things the following way: > > kernel/sched/cpufreq.c=> kernel/sched/cpufreq/core.c > kernel/sched/cpufreq_schedutil.c => kernel/sched/cpufreq/metrics.c > kernel/sched/thermal.c=> kernel/sched/cpufreq/thermal.c > > ... or so? > > With no change to functionality, this is just a re-organization and > expansion/preparation for the bright future. =B-) No disagreement here. :-) Cheers, Rafael
Re: [PATCH 1/3] x86: baytrail/cherrytrail: Rework and move P-Unit PMIC bus semaphore code
Hi, On 18-10-18 09:29, Rafael J. Wysocki wrote: On Sun, Sep 23, 2018 at 4:45 PM Hans de Goede wrote: On some BYT/CHT systems the SoC's P-Unit shares the I2C bus with the kernel. The P-Unit has a semaphore for the PMIC bus which we can take to block it from accessing the shared bus while the kernel wants to access it. Currently we have the I2C-controller driver acquiring and releasing the semaphore around each I2C transfer. There are 2 problems with this: 1) PMIC accesses often come in the form of a read-modify-write on one of the PMIC registers, we currently release the P-Unit's PMIC bus semaphore between the read and the write. If the P-Unit modifies the register during this window?, then we end up overwriting the P-Unit's changes. I believe that this is mostly an academic problem, but I'm not sure. 2) To safely access the shared I2C bus, we need to do 3 things: a) Notify the GPU driver that we are starting a window in which it may not access the P-Unit, since the P-Unit seems to ignore the semaphore for explicit power-level requests made by the GPU driver b) Make a pm_qos request to force all CPU cores out of C6/C7 since entering C6/C7 while we hold the semaphore hangs the SoC c) Finally take the P-Unit's PMIC bus semaphore All 3 these steps together are somewhat expensive, so ideally if we have a bunch of i2c transfers grouped together we only do this once for the entire group. Taking the read-modify-write on a PMIC register as example then ideally we would only do all 3 steps once at the beginning and undo all 3 steps once at the end. For this we need to be able to take the semaphore from within e.g. the PMIC opregion driver, yet we do not want to remove the taking of the semaphore from the I2C-controller driver, as that is still necessary to protect many other code-paths leading to accessing the shared I2C bus. This means that we first have the PMIC driver acquire the semaphore and then have the I2C controller driver trying to acquire it again. To make this possible this commit does the following: 1) Move the semaphore code from being private to the I2C controller driver into the generic iosf_mbi code, which already has other code to deal with the shared bus so that it can be accessed outside of the I2C bus driver. 2) Rework the code so that it can be called multiple times nested, while still blocking I2C accesses while e.g. the GPU driver has indicated the P-Unit needs the bus through a iosf_mbi_punit_acquire() call. Signed-off-by: Hans de Goede If there are no objections or concerns regarding this patch, I'm inclined to take the entire series including it. In that case let me send out a v4, with the following chunk added to the 2nd patch: --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -515,7 +515,7 @@ config CRC_PMIC_OPREGION config XPOWER_PMIC_OPREGION bool "ACPI operation region support for XPower AXP288 PMIC" - depends on MFD_AXP20X_I2C + depends on MFD_AXP20X_I2C && IOSF_MBI help This config adds ACPI operation region support for XPower AXP288 PMIC. This is necessary to avoid compilation issues on non x86 systems (where the asm/iosf_mbi.h header is not available) and on x86 systems in case IOSF_MBI support is not enabled there. Note that the AXP288 PMIC is connected through the LPSS i2c controller, so either we have IOSF_MBI support selected through the X86_INTEL_LPSS option, or we have a kernel where the opregion will never work anyways. Regards, Hans --- Note this commit deliberately limits the i2c-designware changes to only touch i2c-designware-baytrail.c, deliberately not doing some cleanups which become possible after removing the semaphore code from the i2c-designmware code. This is done so that this commit can be merged through the x86 tree without causing conflicts in the i2c tree. The cleanups to the i2c-designware tree will be done in a follow up patch which can be merged once this commit is in place. --- arch/x86/include/asm/iosf_mbi.h | 39 +++-- arch/x86/platform/intel/iosf_mbi.c | 161 +-- drivers/i2c/busses/i2c-designware-baytrail.c | 125 +- 3 files changed, 180 insertions(+), 145 deletions(-) diff --git a/arch/x86/include/asm/iosf_mbi.h b/arch/x86/include/asm/iosf_mbi.h index 3de0489deade..5270ff39b9af 100644 --- a/arch/x86/include/asm/iosf_mbi.h +++ b/arch/x86/include/asm/iosf_mbi.h @@ -105,8 +105,10 @@ int iosf_mbi_modify(u8 port, u8 opcode, u32 offset, u32 mdr, u32 mask); * the PMIC bus while another driver is also accessing the PMIC bus various bad * things happen. * - * To avoid these problems this function must be called before accessing the - * P-Unit or the PMIC, be it through iosf_mbi* functions or through other means. + * Call this function before sending requests to the P-Unit which may make it + * access the PMIC, be it through iosf_mbi* functions or through other means. + * This function will block all kernel
Re: [PATCH V9 00/21] C-SKY(csky) Linux Kernel Port
On Thu, Oct 18, 2018 at 6:11 AM Guo Ren wrote: > > On Wed, Oct 17, 2018 at 05:58:46PM +0200, Arnd Bergmann wrote: > > On Tue, Oct 16, 2018 at 4:58 AM Guo Ren wrote: > > > > > > This is the 9th version patchset to add the Linux kernel port for > > > C-SKY(csky) based on linux-4.19-rc3. > > > > > > There are only a few changes between V8 patchset. Hope it could be > > > merged into linux-4.20 and I'm very grateful for any help. > > > > I've gone through the entire series once more and saw no show-stoppers. > > The last patch looked like it introduced a bug, but with that one dropped, > > I'm happy for the architecture to get merged, unless anyone else > > has any last-minute concerns. (Alternatively, explain why I'm wrong > > and the code works correctly, of course). > Ok and thx for the job of csky subsystem. > > > > > I'd appreciate having someone else take another look at the signal > > handling code, the atomics, and the DT bindings and provide another > > Ack for those. > > > > The remaining open question is about the 32-bit time_t interfaces. > > With 4.20, I did not manage to get the required system calls in place > > for using 64-bit time_t in a new architecture, so you will at least > > start out using 32-bit time_t and likely have to keep supporting > > that going forward, unless we decide to break the ABI here later > > on .This is something we normally don't do, but we might make > > an exception here, under the assumption that there are no > > existing users with the ABI. We can debate that once we get there. > We support uclibc-ng and glibc. > > 1. For uclibc-ng, linux-4.20 could run with it. > > 2. For glibc, Maybe we could support 32-bit + 64-bit time_t with > KERNEL_VERSION, or just only 64-bit then linux-4.20 couldn't work with > the csky first glibc release. Yes, it is always an option to make glibc more restrictive than the kernel. We could also just make it a configuration option in the kernel whether the system calls are provided, so they don't use memory for the implementation. You will probably want musl support at some point. musl-1.x always uses 32-bit time_t today, but musl-2.x will use the 64-bit interfaces, so just waiting a bit will probably make it work out for you. Arnd
Re: [PATCH 1/3] x86: baytrail/cherrytrail: Rework and move P-Unit PMIC bus semaphore code
HI, On 18-10-18 10:38, Rafael J. Wysocki wrote: On Thursday, October 18, 2018 10:34:57 AM CEST Hans de Goede wrote: Hi, On 18-10-18 09:29, Rafael J. Wysocki wrote: On Sun, Sep 23, 2018 at 4:45 PM Hans de Goede wrote: On some BYT/CHT systems the SoC's P-Unit shares the I2C bus with the kernel. The P-Unit has a semaphore for the PMIC bus which we can take to block it from accessing the shared bus while the kernel wants to access it. Currently we have the I2C-controller driver acquiring and releasing the semaphore around each I2C transfer. There are 2 problems with this: 1) PMIC accesses often come in the form of a read-modify-write on one of the PMIC registers, we currently release the P-Unit's PMIC bus semaphore between the read and the write. If the P-Unit modifies the register during this window?, then we end up overwriting the P-Unit's changes. I believe that this is mostly an academic problem, but I'm not sure. 2) To safely access the shared I2C bus, we need to do 3 things: a) Notify the GPU driver that we are starting a window in which it may not access the P-Unit, since the P-Unit seems to ignore the semaphore for explicit power-level requests made by the GPU driver b) Make a pm_qos request to force all CPU cores out of C6/C7 since entering C6/C7 while we hold the semaphore hangs the SoC c) Finally take the P-Unit's PMIC bus semaphore All 3 these steps together are somewhat expensive, so ideally if we have a bunch of i2c transfers grouped together we only do this once for the entire group. Taking the read-modify-write on a PMIC register as example then ideally we would only do all 3 steps once at the beginning and undo all 3 steps once at the end. For this we need to be able to take the semaphore from within e.g. the PMIC opregion driver, yet we do not want to remove the taking of the semaphore from the I2C-controller driver, as that is still necessary to protect many other code-paths leading to accessing the shared I2C bus. This means that we first have the PMIC driver acquire the semaphore and then have the I2C controller driver trying to acquire it again. To make this possible this commit does the following: 1) Move the semaphore code from being private to the I2C controller driver into the generic iosf_mbi code, which already has other code to deal with the shared bus so that it can be accessed outside of the I2C bus driver. 2) Rework the code so that it can be called multiple times nested, while still blocking I2C accesses while e.g. the GPU driver has indicated the P-Unit needs the bus through a iosf_mbi_punit_acquire() call. Signed-off-by: Hans de Goede If there are no objections or concerns regarding this patch, I'm inclined to take the entire series including it. In that case let me send out a v4, with the following chunk added to the 2nd patch: --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -515,7 +515,7 @@ config CRC_PMIC_OPREGION config XPOWER_PMIC_OPREGION bool "ACPI operation region support for XPower AXP288 PMIC" - depends on MFD_AXP20X_I2C + depends on MFD_AXP20X_I2C && IOSF_MBI help This config adds ACPI operation region support for XPower AXP288 PMIC. This is necessary to avoid compilation issues on non x86 systems (where the asm/iosf_mbi.h header is not available) and on x86 systems in case IOSF_MBI support is not enabled there. Note that the AXP288 PMIC is connected through the LPSS i2c controller, so either we have IOSF_MBI support selected through the X86_INTEL_LPSS option, or we have a kernel where the opregion will never work anyways. I'd prefer to get an incremental patch for that at this point. Ok, then I will prepare and send out an incremental patch for that. Regards, Hans
[PATCH 1/3] nds32: Fix instruction simulator bug for unaligned access handler.
When emulating the 16 bits instructions, the mapping of general
purpose registers is not the same as 32 bits instructions.
Example:
'LWI450 r16, [r15]' 16-bit instruction will be decoded as
'1011010110001110', the target register field is decode as index=12.
But the index of target register should be 16. So the mapping of
register in unaligned access handler is wrong.
Signed-off-by: Nickhu
---
arch/nds32/mm/alignment.c | 37 +
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/arch/nds32/mm/alignment.c b/arch/nds32/mm/alignment.c
index e1aed9dc692d..66a556befd05 100644
--- a/arch/nds32/mm/alignment.c
+++ b/arch/nds32/mm/alignment.c
@@ -152,12 +152,16 @@ extern int va_writable(struct pt_regs *regs, unsigned
long addr);
int unalign_access_mode = 0, unalign_access_debug = 0;
-static inline unsigned long *idx_to_addr(struct pt_regs *regs, int idx)
+static inline unsigned long *idx_to_addr(struct pt_regs *regs, int idx,
+ int idx_mode)
{
/* this should be consistent with ptrace.h */
- if (idx >= 0 && idx <= 25) /* R0-R25 */
- return >uregs[0] + idx;
- else if (idx >= 28 && idx <= 30)/* FP, GP, LP */
+ if (idx >= 0 && idx <= 25) {/* R0-R25 */
+ if (idx_mode == 4 && idx > 11)
+ return >uregs[0] + idx + 4;
+ else
+ return >uregs[0] + idx;
+ } else if (idx >= 28 && idx <= 30) /* FP, GP, LP */
return >fp + (idx - 28);
else if (idx == 31) /* SP */
return >sp;
@@ -270,10 +274,10 @@ static inline int do_16(unsigned long inst, struct
pt_regs *regs)
}
if (addr_mode == 3) {
- unaligned_addr = *idx_to_addr(regs, RA3(inst));
+ unaligned_addr = *idx_to_addr(regs, RA3(inst), addr_mode);
source_idx = RA3(inst);
} else {
- unaligned_addr = *idx_to_addr(regs, RA5(inst));
+ unaligned_addr = *idx_to_addr(regs, RA5(inst), addr_mode);
source_idx = RA5(inst);
}
@@ -293,16 +297,17 @@ static inline int do_16(unsigned long inst, struct
pt_regs *regs)
return -EACCES;
get_data(unaligned_addr, _val, len);
- *idx_to_addr(regs, target_idx) = target_val;
+ *idx_to_addr(regs, target_idx, idx_mode) = target_val;
} else {
if (!access_ok(VERIFY_WRITE, (void *)unaligned_addr, len))
return -EACCES;
- target_val = *idx_to_addr(regs, target_idx);
+ target_val = *idx_to_addr(regs, target_idx, idx_mode);
set_data((void *)unaligned_addr, target_val, len);
}
if (!regular)
- *idx_to_addr(regs, source_idx) = unaligned_addr + shift;
+ *idx_to_addr(regs, source_idx, idx_mode) =
+ unaligned_addr + shift;
regs->ipc += 2;
return 0;
@@ -312,10 +317,10 @@ static inline int do_16(unsigned long inst, struct
pt_regs *regs)
static inline int do_32(unsigned long inst, struct pt_regs *regs)
{
- int imm, regular, load, len, sign_ext;
+ int imm, regular, load, len, sign_ext, idx_mode = 5;
unsigned long unaligned_addr, target_val, shift;
- unaligned_addr = *idx_to_addr(regs, RA(inst));
+ unaligned_addr = *idx_to_addr(regs, RA(inst), idx_mode);
switch ((inst >> 25) << 1) {
@@ -472,7 +477,7 @@ static inline int do_32(unsigned long inst, struct pt_regs
*regs)
if (imm)
shift = GET_IMMSVAL(IMM(inst)) * len;
else
- shift = *idx_to_addr(regs, RB(inst)) << SV(inst);
+ shift = *idx_to_addr(regs, RB(inst), idx_mode) << SV(inst);
if (regular)
unaligned_addr += shift;
@@ -485,21 +490,21 @@ static inline int do_32(unsigned long inst, struct
pt_regs *regs)
get_data(unaligned_addr, _val, len);
if (sign_ext)
- *idx_to_addr(regs, RT(inst)) =
+ *idx_to_addr(regs, RT(inst), idx_mode) =
sign_extend(target_val, len);
else
- *idx_to_addr(regs, RT(inst)) = target_val;
+ *idx_to_addr(regs, RT(inst), idx_mode) = target_val;
} else {
if (!access_ok(VERIFY_WRITE, (void *)unaligned_addr, len))
return -EACCES;
- target_val = *idx_to_addr(regs, RT(inst));
+ target_val = *idx_to_addr(regs, RT(inst), idx_mode);
set_data((void *)unaligned_addr, target_val, len);
}
if (!regular)
- *idx_to_addr(regs, RA(inst)) = unaligned_addr + shift;
+ *idx_to_addr(regs, RA(inst), idx_mode) = unaligned_addr +
[PATCH 3/3] nds32: Add unaligned access in kernel space.
As my colleague has encountered kernel panic when unaligned access
in kernel space. Here is the situation, the structure 'TP_STRUCT__entry':
TP_STRUCT__entry(
__field(u32,tb_id )
__field(int,err )
__field(int,oif )
__field(int,iif )
__field(__u8, tos )
__field(__u8, scope )
__field(__u8, flags )
__field(u8, proto )
__array(__u8, src,4 )
__array(__u8, dst,4 )
__array(__u8, gw, 4 )
__array(__u8, saddr, 4 )
__field(u16,sport )
__field(u16,dport )
__dynamic_array(char, name, IFNAMSIZ )
)
When he try to access the element in the structure, the kernel panic
happen. Although he has rearrange the order of the structure to fix
the problem, but we cannot ignore the fact that there still need
unaligned access in kernel space. It can help us to avoid kernel panic
when reasonable unaligned address access happen. The users need to have
the knowledge that some unreasonable unaligned address may cause the bug
in kernel.
The config 'HAVE_EFFICIENT_UNALIGNED_ACCESS' must be with the hw
unaligned access config 'HW_SUPPORT_UNALIGNMENT_ACCESS'. In sw
unalinged access handler, the code 'get_inst()' in arch/nds32/mm/
alignment.c:522 would be generate as load word instruction if
'HAVE_EFFICIENT_UNALIGNED_ACCESS' is set. This would cause the kernel
hang in loop if the address of the load word instruction is unaligned.
For example:
0xbc39e: lwi450 $r0, [$r1], if the $r1 cause unaligned access.
|
| unaligned
access handler
v
arch/nds32/mm/alignment.c:522: get_ints():0xb0874b7e lwi450 $r2, [$3],
$r3 is the address '0xbc39e', it would cause kernel unaligned access.
|
| unaligned
access handler
v
arch/nds32/mm/alignment.c:522: get_ints():0xb0874b7e lwi450 $r2, [$3],
$r3 is the address '0xb0874b7e', it would cause kernel unaligned access.
The kernel is hang in the loop.
Signed-off-by: Nickhu
---
arch/nds32/kernel/traps.c | 4 +++-
arch/nds32/mm/alignment.c | 6 --
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/nds32/kernel/traps.c b/arch/nds32/kernel/traps.c
index 1496aab48998..dcde7abc5515 100644
--- a/arch/nds32/kernel/traps.c
+++ b/arch/nds32/kernel/traps.c
@@ -331,6 +331,7 @@ void do_revinsn(struct pt_regs *regs)
#ifdef CONFIG_ALIGNMENT_TRAP
extern int unalign_access_mode;
extern int do_unaligned_access(unsigned long addr, struct pt_regs *regs);
+extern int va_kernel_present(unsigned long addr);
#endif
void do_dispatch_general(unsigned long entry, unsigned long addr,
unsigned long itype, struct pt_regs *regs,
@@ -341,7 +342,8 @@ void do_dispatch_general(unsigned long entry, unsigned long
addr,
if (type == ETYPE_ALIGNMENT_CHECK) {
#ifdef CONFIG_ALIGNMENT_TRAP
/* Alignment check */
- if (user_mode(regs) && unalign_access_mode) {
+ if ((user_mode(regs) && unalign_access_mode) ||
+ va_kernel_present(addr)) {
int ret;
ret = do_unaligned_access(addr, regs);
diff --git a/arch/nds32/mm/alignment.c b/arch/nds32/mm/alignment.c
index 66a556befd05..2d7a08af6622 100644
--- a/arch/nds32/mm/alignment.c
+++ b/arch/nds32/mm/alignment.c
@@ -524,8 +524,10 @@ int do_unaligned_access(unsigned long addr, struct pt_regs
*regs)
DEBUG((unalign_access_debug > 0), 1,
"Faulting addr: 0x%08lx, pc: 0x%08lx [inst: 0x%08lx ]\n", addr,
regs->ipc, inst);
-
- set_fs(USER_DS);
+ if ((user_mode(regs) && unalign_access_mode))
+ set_fs(USER_DS);
+ else if (va_kernel_present(addr))
+ set_fs(KERNEL_DS);
if (inst & NDS32_16BIT_INSTRUCTION)
ret = do_16((inst >> 16) & 0x, regs);
--
2.17.0
Re: [PATCH] kthread: finer-grained lockdep/cross-release completion
On Fri, Mar 16, 2018 at 12:26 AM Byungchul Park wrote: > > On 3/15/2018 9:41 PM, Peter Zijlstra wrote: > > On Thu, Mar 15, 2018 at 11:31:57AM +0100, Daniel Vetter wrote: > >> Is there any progress on getting cross-release enabled again? > > > > Not yet, I'm still fighting the meltdown/spectre induced backlog. > > > > We'll get to it eventually. > > Please let me know when you get available so that I can start. Hi Byungchul, Do you have a branch somewhere with latest/rebased cross-release patches? I'd be interested in resurrecting them, and least for local testing in drm. I'm still carrying around some patches to improve annotations here. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 1/1] nds32: Fix gcc 8.0 compiler option incompatible.
When the kernel configs of ftrace and frame pointer options are choosed, the compiler option of kernel will incompatible. Error message: nds32le-linux-gcc: error: -pg and -fomit-frame-pointer are incompatible Signed-off-by: Nickhu Signed-off-by: Zong Li --- arch/nds32/mm/Makefile | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/nds32/mm/Makefile b/arch/nds32/mm/Makefile index 6b6855852223..7c5c15ad854a 100644 --- a/arch/nds32/mm/Makefile +++ b/arch/nds32/mm/Makefile @@ -4,4 +4,8 @@ obj-y := extable.o tlb.o \ obj-$(CONFIG_ALIGNMENT_TRAP) += alignment.o obj-$(CONFIG_HIGHMEM) += highmem.o -CFLAGS_proc-n13.o += -fomit-frame-pointer + +ifdef CONFIG_FUNCTION_TRACER +CFLAGS_REMOVE_proc.o = $(CC_FLAGS_FTRACE) +endif +CFLAGS_proc.o += -fomit-frame-pointer -- 2.17.0
Re: [PATCH] arm: kernel: add support for detecting armv8 cpu cache information
On Thu, Oct 18, 2018 at 02:16:47PM +0800, Teng Fei Fan wrote: > This patch adds support for cacheinfo on 32bit ARMv8 platform. > Add support for detecting cpu cache information cpu cache information > via sysfs for 32bit armv8 platform. And export to sysfs then userspace > can get from /sys/devices/system/cpu/cpuX/cache. You don't explain why this is needed. We don't do this for previous 32-bit CPUs, so why should we do this for ARMv8 running on a 32-bit kernel? -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
[PATCH 2/3] nds32: Add 'HAVE_EFFICIENT_UNALIGNED_ACCESS' config
According to my understanding, this config will optimize the code generate. When there is an unaligned access happened, the load word instruction still can be used if there is unaligned access support or the load byte instruction is used. So this config need unaligned access support. 'HAVE_EFFICIENT_UNALIGNED_ACCESS' and 'HW_SUPPORT_UNALIGNMENT_ACCESS' are default configs in nds32. Signed-off-by: Nickhu --- arch/nds32/Kconfig.cpu | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/nds32/Kconfig.cpu b/arch/nds32/Kconfig.cpu index b8c8984d1456..b8eecd0cde6b 100644 --- a/arch/nds32/Kconfig.cpu +++ b/arch/nds32/Kconfig.cpu @@ -111,8 +111,9 @@ config ALIGNMENT_TRAP config HW_SUPPORT_UNALIGNMENT_ACCESS bool "Kernel support unaligned access handling by hw" + select HAVE_EFFICIENT_UNALIGNED_ACCESS depends on !ALIGNMENT_TRAP - default n + default y help Andes processors load/store world/half-word instructions can access unaligned memory locations without generating the Data Alignment -- 2.17.0
[PATCH 1/1] Perf: Compile failed when compile with libelf.
The error message:
=
util/symbol-elf.c:46:12: error: static declaration of 'elf_getphdrnum'
follows non-static declaration
static int elf_getphdrnum(Elf *elf, size_t *dst)
^~
In file included from util/symbol.h:20,
from util/symbol-elf.c:9:
/local/nickhu/build-system-3/toolchain/nds32le-linux-glibc-v3-upstream/
nds32le-linux/sysroot/usr/include/libelf.h:266:12: note: previous declaration
of 'elf_getphdrnum' was here
extern int elf_getphdrnum (Elf *__elf, size_t *__dst);
^~
util/symbol-elf.c:62:12: error: static declaration of 'elf_getshdrstrndx'
follows non-static declaration
static int elf_getshdrstrndx(Elf *elf __maybe_unused, size_t *dst __maybe
_unused)
^
In file included from util/symbol.h:20,
from util/symbol-elf.c:9:
/local/nickhu/build-system-3/toolchain/nds32le-linux-glibc-v3-upstream/
nds32le-linux/sysroot/usr/include/libelf.h:316:12: note: previous declaration
of 'elf_getshdrstrndx' was here
extern int elf_getshdrstrndx (Elf *__elf, size_t *__dst);
=
Fix it.
Signed-off-by: Nickhu
---
tools/perf/util/symbol-elf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 29770ea61768..3ccdfe603d67 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -43,7 +43,7 @@ static inline char *bfd_demangle(void __maybe_unused *v,
#endif
#ifndef HAVE_ELF_GETPHDRNUM_SUPPORT
-static int elf_getphdrnum(Elf *elf, size_t *dst)
+int elf_getphdrnum(Elf *elf, size_t *dst)
{
GElf_Ehdr gehdr;
GElf_Ehdr *ehdr;
@@ -59,7 +59,7 @@ static int elf_getphdrnum(Elf *elf, size_t *dst)
#endif
#ifndef HAVE_ELF_GETSHDRSTRNDX_SUPPORT
-static int elf_getshdrstrndx(Elf *elf __maybe_unused, size_t *dst
__maybe_unused)
+int elf_getshdrstrndx(Elf *elf __maybe_unused, size_t *dst __maybe_unused)
{
pr_err("%s: update your libelf to > 0.140, this one lacks
elf_getshdrstrndx().\n", __func__);
return -1;
--
2.17.0
[PATCH 0/1] nds32: Fix gcc 8.0 compiler option incompatible.
Fix gcc 8.0 compiler option incompatible When the kernel configs of ftrace and frame pointer options are choosed. Nickhu (1): nds32: Fix gcc 8.0 compiler option incompatible. arch/nds32/mm/Makefile | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) -- 2.17.0
[PATCH 0/1] Perf: Compile failed when compile with libelf.
Fix perf failed when compile with libelf. Nickhu (1): Perf: Compile failed when compile with libelf. tools/perf/util/symbol-elf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.17.0
Re: Linux 4.9.134
diff --git a/Documentation/devicetree/bindings/net/macb.txt
b/Documentation/devicetree/bindings/net/macb.txt
index 1506e948610c..d1f435c92912 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -10,6 +10,7 @@ Required properties:
Use "cdns,pc302-gem" for Picochip picoXcell pc302 and later devices based on
the Cadence GEM, or the generic form: "cdns,gem".
Use "atmel,sama5d2-gem" for the GEM IP (10/100) available on Atmel sama5d2
SoCs.
+ Use "atmel,sama5d3-macb" for the 10/100Mbit IP available on Atmel sama5d3
SoCs.
Use "atmel,sama5d3-gem" for the Gigabit IP available on Atmel sama5d3 SoCs.
Use "atmel,sama5d4-gem" for the GEM IP (10/100) available on Atmel sama5d4
SoCs.
Use "cdns,zynq-gem" Xilinx Zynq-7xxx SoC.
diff --git a/Documentation/networking/ip-sysctl.txt
b/Documentation/networking/ip-sysctl.txt
index 3db8c67d2c8d..dbdc4130e149 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -122,14 +122,11 @@ min_adv_mss - INTEGER
IP Fragmentation:
-ipfrag_high_thresh - INTEGER
- Maximum memory used to reassemble IP fragments. When
- ipfrag_high_thresh bytes of memory is allocated for this purpose,
- the fragment handler will toss packets until ipfrag_low_thresh
- is reached. This also serves as a maximum limit to namespaces
- different from the initial one.
-
-ipfrag_low_thresh - INTEGER
+ipfrag_high_thresh - LONG INTEGER
+ Maximum memory used to reassemble IP fragments.
+
+ipfrag_low_thresh - LONG INTEGER
+ (Obsolete since linux-4.17)
Maximum memory used to reassemble IP fragments before the kernel
begins to remove incomplete fragment queues to free up resources.
The kernel still accepts new fragments for defragmentation.
diff --git a/Makefile b/Makefile
index 18090f899a7c..46135e4333e6 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 133
+SUBLEVEL = 134
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/arch/arm/boot/dts/sama5d3_emac.dtsi
b/arch/arm/boot/dts/sama5d3_emac.dtsi
index 7cb235ef0fb6..6e9e1c2f9def 100644
--- a/arch/arm/boot/dts/sama5d3_emac.dtsi
+++ b/arch/arm/boot/dts/sama5d3_emac.dtsi
@@ -41,7 +41,7 @@
};
macb1: ethernet@f802c000 {
- compatible = "cdns,at91sam9260-macb",
"cdns,macb";
+ compatible = "atmel,sama5d3-macb",
"cdns,at91sam9260-macb", "cdns,macb";
reg = <0xf802c000 0x100>;
interrupts = <35 IRQ_TYPE_LEVEL_HIGH 3>;
pinctrl-names = "default";
diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
index 739c0c594022..1bb90fafcdc3 100644
--- a/arch/x86/include/uapi/asm/kvm.h
+++ b/arch/x86/include/uapi/asm/kvm.h
@@ -356,5 +356,6 @@ struct kvm_sync_regs {
#define KVM_X86_QUIRK_LINT0_REENABLED (1 << 0)
#define KVM_X86_QUIRK_CD_NW_CLEARED(1 << 1)
+#define KVM_X86_QUIRK_LAPIC_MMIO_HOLE (1 << 2)
#endif /* _ASM_X86_KVM_H */
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index a8a86be8cf15..69a81a7daa24 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1220,9 +1220,8 @@ EXPORT_SYMBOL_GPL(kvm_lapic_reg_read);
static int apic_mmio_in_range(struct kvm_lapic *apic, gpa_t addr)
{
- return kvm_apic_hw_enabled(apic) &&
- addr >= apic->base_address &&
- addr < apic->base_address + LAPIC_MMIO_LENGTH;
+ return addr >= apic->base_address &&
+ addr < apic->base_address + LAPIC_MMIO_LENGTH;
}
static int apic_mmio_read(struct kvm_vcpu *vcpu, struct kvm_io_device *this,
@@ -1234,6 +1233,15 @@ static int apic_mmio_read(struct kvm_vcpu *vcpu, struct
kvm_io_device *this,
if (!apic_mmio_in_range(apic, address))
return -EOPNOTSUPP;
+ if (!kvm_apic_hw_enabled(apic) || apic_x2apic_mode(apic)) {
+ if (!kvm_check_has_quirk(vcpu->kvm,
+KVM_X86_QUIRK_LAPIC_MMIO_HOLE))
+ return -EOPNOTSUPP;
+
+ memset(data, 0xff, len);
+ return 0;
+ }
+
kvm_lapic_reg_read(apic, offset, len, data);
return 0;
@@ -1646,6 +1654,14 @@ static int apic_mmio_write(struct kvm_vcpu *vcpu, struct
kvm_io_device *this,
if (!apic_mmio_in_range(apic, address))
return -EOPNOTSUPP;
+ if (!kvm_apic_hw_enabled(apic) || apic_x2apic_mode(apic)) {
+ if (!kvm_check_has_quirk(vcpu->kvm,
+KVM_X86_QUIRK_LAPIC_MMIO_HOLE))
+ return -EOPNOTSUPP;
+
+ return 0;
+ }
+
/*
* APIC register must be aligned on 128-bits boundary.
* 32/64/128 bits registers must be accessed thru 32 bits.
diff --git
Linux 4.14.77
I'm announcing the release of the 4.14.77 kernel. All users of the 4.14 kernel series must upgrade. The updated 4.14.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.14.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/devicetree/bindings/net/macb.txt|1 Makefile |2 arch/arm/boot/dts/sama5d3_emac.dtsi |2 arch/arm/include/asm/assembler.h | 12 + arch/arm/include/asm/barrier.h| 32 +++ arch/arm/include/asm/bugs.h |6 arch/arm/include/asm/cp15.h |3 arch/arm/include/asm/cputype.h|8 arch/arm/include/asm/kvm_asm.h|2 arch/arm/include/asm/kvm_host.h | 14 + arch/arm/include/asm/kvm_mmu.h| 23 ++ arch/arm/include/asm/proc-fns.h |4 arch/arm/include/asm/system_misc.h| 15 + arch/arm/include/asm/thread_info.h|4 arch/arm/include/asm/uaccess.h| 26 +- arch/arm/kernel/Makefile |1 arch/arm/kernel/bugs.c| 18 + arch/arm/kernel/entry-common.S| 18 - arch/arm/kernel/entry-header.S| 25 ++ arch/arm/kernel/signal.c | 58 +++--- arch/arm/kernel/smp.c |4 arch/arm/kernel/suspend.c |2 arch/arm/kernel/sys_oabi-compat.c |8 arch/arm/kvm/hyp/hyp-entry.S | 112 +++ arch/arm/lib/copy_from_user.S |9 arch/arm/mm/Kconfig | 23 ++ arch/arm/mm/Makefile |2 arch/arm/mm/fault.c |3 arch/arm/mm/proc-macros.S |3 arch/arm/mm/proc-v7-2level.S |6 arch/arm/mm/proc-v7-bugs.c| 174 ++ arch/arm/mm/proc-v7.S | 154 --- arch/arm/vfp/vfpmodule.c | 17 - arch/arm64/kernel/perf_event.c|7 arch/mips/include/asm/processor.h | 10 - arch/mips/kernel/process.c| 25 ++ arch/mips/kernel/vdso.c | 18 + arch/powerpc/include/asm/book3s/64/pgtable.h |4 arch/x86/include/asm/pgtable_types.h |2 arch/x86/include/uapi/asm/kvm.h |1 arch/x86/kvm/lapic.c | 22 +- drivers/bluetooth/hci_ldisc.c |2 drivers/clk/x86/clk-pmc-atom.c| 18 + drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c |2 drivers/i2c/busses/i2c-scmi.c |1 drivers/md/dm-cache-target.c |5 drivers/md/dm-flakey.c|2 drivers/md/dm-linear.c|8 drivers/md/dm.c | 27 ++ drivers/mfd/omap-usb-host.c | 11 - drivers/mmc/core/block.c | 10 + drivers/net/bonding/bond_main.c | 65 +++--- drivers/net/dsa/bcm_sf2.c | 12 - drivers/net/ethernet/aquantia/atlantic/aq_ring.c | 32 +-- drivers/net/ethernet/broadcom/bcmsysport.c| 22 +- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 23 +- drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c | 20 +- drivers/net/ethernet/cadence/macb_main.c |8 drivers/net/ethernet/hisilicon/hns/hnae.c |2 drivers/net/ethernet/hisilicon/hns/hns_enet.c | 30 +-- drivers/net/ethernet/marvell/mvpp2.c | 20 +- drivers/net/ethernet/mellanox/mlx5/core/en_tc.c |3 drivers/net/ethernet/mellanox/mlx5/core/eswitch.c |4 drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 17 + drivers/net/ethernet/qlogic/qlcnic/qlcnic.h |8 drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c |3 drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_hw.h |3 drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.h|3 drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c| 12 - drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |8 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c |5
Re: [PATCH V9 00/21] C-SKY(csky) Linux Kernel Port
On Thu, Oct 18, 2018 at 10:36:45AM +0200, Arnd Bergmann wrote: > On Thu, Oct 18, 2018 at 6:11 AM Guo Ren wrote: > > > > On Wed, Oct 17, 2018 at 05:58:46PM +0200, Arnd Bergmann wrote: > > > On Tue, Oct 16, 2018 at 4:58 AM Guo Ren wrote: > > > > > > > > This is the 9th version patchset to add the Linux kernel port for > > > > C-SKY(csky) based on linux-4.19-rc3. > > > > > > > > There are only a few changes between V8 patchset. Hope it could be > > > > merged into linux-4.20 and I'm very grateful for any help. > > > > > > I've gone through the entire series once more and saw no show-stoppers. > > > The last patch looked like it introduced a bug, but with that one dropped, > > > I'm happy for the architecture to get merged, unless anyone else > > > has any last-minute concerns. (Alternatively, explain why I'm wrong > > > and the code works correctly, of course). > > Ok and thx for the job of csky subsystem. > > > > > > > > I'd appreciate having someone else take another look at the signal > > > handling code, the atomics, and the DT bindings and provide another > > > Ack for those. > > > > > > The remaining open question is about the 32-bit time_t interfaces. > > > With 4.20, I did not manage to get the required system calls in place > > > for using 64-bit time_t in a new architecture, so you will at least > > > start out using 32-bit time_t and likely have to keep supporting > > > that going forward, unless we decide to break the ABI here later > > > on .This is something we normally don't do, but we might make > > > an exception here, under the assumption that there are no > > > existing users with the ABI. We can debate that once we get there. > > We support uclibc-ng and glibc. > > > > 1. For uclibc-ng, linux-4.20 could run with it. > > > > 2. For glibc, Maybe we could support 32-bit + 64-bit time_t with > > KERNEL_VERSION, or just only 64-bit then linux-4.20 couldn't work with > > the csky first glibc release. > > Yes, it is always an option to make glibc more restrictive than the kernel. > We could also just make it a configuration option in the kernel whether > the system calls are provided, so they don't use memory for the > implementation. Ok. > You will probably want musl support at some point. musl-1.x always > uses 32-bit time_t today, but musl-2.x will use the 64-bit interfaces, > so just waiting a bit will probably make it work out for you. Thx for the tips, we'll consider musl in the future. Best Regards Guo Ren
[PATCH v4 0/8] Introduce STPMIC1 PMIC Driver
The goal of this patch-set is to propose a driver for the STPMIC1 PMIC from STMicroelectronics. The STPMIC1 regulators supply power to an application processor as well as to external system peripherals such as DDR, Flash memories and system devices. It also features onkey button input and an hardware watchdog. The STPMIC1 is controlled via I2C. Main driver is drivers/mfd/stpmic1 that handle I2C regmap configuration and irqchip. stpmic1_regulator, stpmic1_onkey and stpmic1_wdt need stpmic1 mfd as parent. stpmic1 mfd and regulator drivers maybe mandatory at boot time. changes in v4: * fix watchdog stop function * rework onkey probe function * various fixes in bindings pascal paillet (8): dt-bindings: mfd: document stpmic1 mfd: stpmic1: add stpmic1 driver dt-bindings: regulator: document stpmic1 pmic regulators regulator: stpmic1: add stpmic1 regulator driver dt-bindings: input: document stpmic1 pmic onkey input: stpmic1: add stpmic1 onkey driver dt-bindings: watchdog: document stpmic1 pmic watchdog watchdog: stpmic1: add stpmic1 watchdog driver .../devicetree/bindings/input/st,stpmic1-onkey.txt | 28 + .../devicetree/bindings/mfd/st,stpmic1.txt | 131 .../bindings/regulator/st,stpmic1-regulator.txt| 68 +++ .../bindings/watchdog/st,stpmic1-wdt.txt | 11 + drivers/input/misc/Kconfig | 11 + drivers/input/misc/Makefile| 2 + drivers/input/misc/stpmic1_onkey.c | 197 ++ drivers/mfd/Kconfig| 13 + drivers/mfd/Makefile | 1 + drivers/mfd/stpmic1.c | 401 drivers/regulator/Kconfig | 12 + drivers/regulator/Makefile | 1 + drivers/regulator/stpmic1_regulator.c | 674 + drivers/watchdog/Kconfig | 12 + drivers/watchdog/Makefile | 1 + drivers/watchdog/stpmic1_wdt.c | 139 + include/dt-bindings/mfd/st,stpmic1.h | 46 ++ include/linux/mfd/stpmic1.h| 212 +++ 18 files changed, 1960 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/st,stpmic1-onkey.txt create mode 100644 Documentation/devicetree/bindings/mfd/st,stpmic1.txt create mode 100644 Documentation/devicetree/bindings/regulator/st,stpmic1-regulator.txt create mode 100644 Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt create mode 100644 drivers/input/misc/stpmic1_onkey.c create mode 100644 drivers/mfd/stpmic1.c create mode 100644 drivers/regulator/stpmic1_regulator.c create mode 100644 drivers/watchdog/stpmic1_wdt.c create mode 100644 include/dt-bindings/mfd/st,stpmic1.h create mode 100644 include/linux/mfd/stpmic1.h -- 1.9.1
Re: [PATCH 4.9 00/71] 4.9.134-stable review
On Wed, Oct 17, 2018 at 12:19:39PM -0700, Guenter Roeck wrote: > On Tue, Oct 16, 2018 at 07:08:57PM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.134 release. > > There are 71 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 Thu Oct 18 17:05:18 UTC 2018. > > Anything received after that time might be too late. > > > > For v4.9.133-70-gbc300460e99d: > > Build results: > total: 150 pass: 150 fail: 0 > Qemu test results: > total: 308 pass: 308 fail: 0 > > Details are available at https://kerneltests.org/builders/. Great, thanks for testing all three of these and letting me know. greg k-h
Re: [PATCH 4.14 000/109] 4.14.77-stable review
On Thu, Oct 18, 2018 at 07:43:02AM +0100, Jon Hunter wrote: > > On 16/10/2018 18:04, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.77 release. > > There are 109 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 Thu Oct 18 17:04:58 UTC 2018. > > Anything received after that time might be too late. > All tests are passing for Tegra ... > > Test results for stable-v4.14: > 8 builds: 8 pass, 0 fail > 16 boots: 16 pass, 0 fail > 14 tests: 14 pass, 0 fail > > Linux version:4.14.77-rc1-g3dbba66 > Boards tested:tegra124-jetson-tk1, tegra20-ventana, > tegra210-p2371-2180, tegra30-cardhu-a04 Great, thanks for testing and letting me know. greg k-h
Re: [PATCH v4] kernel/hung_task.c: disable on suspend
On Wed, Oct 17, 2018 at 1:24 PM Vitaly Kuznetsov wrote:
>
> It is possible to observe hung_task complaints when system goes to
> suspend-to-idle state:
>
> # echo freeze > /sys/power/state
>
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.001 seconds) done.
> OOM killer disabled.
> Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
> sd 0:0:0:0: [sda] Synchronizing SCSI cache
> INFO: task bash:1569 blocked for more than 120 seconds.
>Not tainted 4.19.0-rc3_+ #687
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> bashD0 1569604 0x
> Call Trace:
> ? __schedule+0x1fe/0x7e0
> schedule+0x28/0x80
> suspend_devices_and_enter+0x4ac/0x750
> pm_suspend+0x2c0/0x310
>
> Register a PM notifier to disable the detector on suspend and re-enable
> back on wakeup.
>
> Signed-off-by: Vitaly Kuznetsov
Thanks for your patience with this!
Are there any objections or concerns regarding this patch?
> ---
> Changes since v3:
> - Handle PM_RESTORE_PREPARE/PM_POST_RESTORE for completeness
> [Rafael J. Wysocki]
> ---
> kernel/hung_task.c | 30 +-
> 1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/hung_task.c b/kernel/hung_task.c
> index b9132d1269ef..cb8e3e8ac7b9 100644
> --- a/kernel/hung_task.c
> +++ b/kernel/hung_task.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -242,6 +243,28 @@ void reset_hung_task_detector(void)
> }
> EXPORT_SYMBOL_GPL(reset_hung_task_detector);
>
> +static bool hung_detector_suspended;
> +
> +static int hungtask_pm_notify(struct notifier_block *self,
> + unsigned long action, void *hcpu)
> +{
> + switch (action) {
> + case PM_SUSPEND_PREPARE:
> + case PM_HIBERNATION_PREPARE:
> + case PM_RESTORE_PREPARE:
> + hung_detector_suspended = true;
> + break;
> + case PM_POST_SUSPEND:
> + case PM_POST_HIBERNATION:
> + case PM_POST_RESTORE:
> + hung_detector_suspended = false;
> + break;
> + default:
> + break;
> + }
> + return NOTIFY_OK;
> +}
> +
> /*
> * kthread which checks for tasks stuck in D state
> */
> @@ -261,7 +284,8 @@ static int watchdog(void *dummy)
> interval = min_t(unsigned long, interval, timeout);
> t = hung_timeout_jiffies(hung_last_checked, interval);
> if (t <= 0) {
> - if (!atomic_xchg(_hung_task, 0))
> + if (!atomic_xchg(_hung_task, 0) &&
> + !hung_detector_suspended)
> check_hung_uninterruptible_tasks(timeout);
> hung_last_checked = jiffies;
> continue;
> @@ -275,6 +299,10 @@ static int watchdog(void *dummy)
> static int __init hung_task_init(void)
> {
> atomic_notifier_chain_register(_notifier_list, _block);
> +
> + /* Disable hung task detector on suspend */
> + pm_notifier(hungtask_pm_notify, 0);
> +
> watchdog_task = kthread_run(watchdog, NULL, "khungtaskd");
>
> return 0;
> --
> 2.17.1
>
Re: statx(2) API and documentation
* Miklos Szeredi: > On Thu, Oct 18, 2018 at 12:22 AM, Florian Weimer wrote: >> * Andreas Dilger: >> So what's the point exactly? >>> >>> Ah, I see your point... STATX_ALL seems to be mostly useful for the kernel >>> to mask off flags that it doesn't currently understand. It doesn't make >>> much sense for applications to specify STATX_ALL, since they don't have any >>> way to know what each flag means unless they are hard-coded to check each of >>> the STATX_* flags individually. They should build up a mask of STATX_* >>> flags >>> based on what they care about (e.g. "find" should only request attributes >>> based on the command-line options given). >> >> Could you remove it from the UAPI header? I didn't want to put it >> into the glibc header, but was overruled. > > To summarize Linus' rule of backward incompatibility: you can do it as > long as nobody notices. So yeah, we could try removing STATX_ALL from > the uapi header, but we'd have to put it back in, once somebody > complains. I don't recall a rule about backwards-incompatible API changes. This wouldn't impact ABI at all.
Re: [PATCH v2] staging: iio: ad7816: Switch to the gpio descriptor interface
On 10/18/2018 09:28 AM, Phil Reid wrote:
[...]
>> + chip->rdwr_pin = devm_gpiod_get(_dev->dev, "rdwr", GPIOD_IN);
>> + if (IS_ERR(chip->rdwr_pin)) {
>> + ret = PTR_ERR(chip->rdwr_pin);
>> + dev_err(_dev->dev, "Failed to request rdwr GPIO: %d\n",
>> + ret);
>> return ret;
>> }
>> - gpio_direction_input(chip->rdwr_pin);
>
> The RD/WR pin is an input to the AD78xx. So this doesn't make sense being
> GPIOD_IN.
One thing at a time. This patch is a straight forward conversion to the GPIO
descriptor interface. It keeps the existing semantics of the driver as they are.
Now these semantics are obviously wrong and should be fixed but that should
be a separate patch from changing the interface.
Re: statx(2) API and documentation
On Thu, Oct 18, 2018 at 9:39 AM, Florian Weimer wrote: > * Miklos Szeredi: > >> On Thu, Oct 18, 2018 at 12:22 AM, Florian Weimer wrote: >>> * Andreas Dilger: >>> > So what's the point exactly? Ah, I see your point... STATX_ALL seems to be mostly useful for the kernel to mask off flags that it doesn't currently understand. It doesn't make much sense for applications to specify STATX_ALL, since they don't have any way to know what each flag means unless they are hard-coded to check each of the STATX_* flags individually. They should build up a mask of STATX_* flags based on what they care about (e.g. "find" should only request attributes based on the command-line options given). >>> >>> Could you remove it from the UAPI header? I didn't want to put it >>> into the glibc header, but was overruled. >> >> To summarize Linus' rule of backward incompatibility: you can do it as >> long as nobody notices. So yeah, we could try removing STATX_ALL from >> the uapi header, but we'd have to put it back in, once somebody >> complains. > > I don't recall a rule about backwards-incompatible API changes. This > wouldn't impact ABI at all. Right, API rules maybe are softer. I'll do some patches... Thanks, Miklos
Re: statx(2) API and documentation
On Thu 18-10-18 01:15:13, Amir Goldstein wrote: > On Wed, Oct 17, 2018 at 10:12 PM Miklos Szeredi wrote: > > > >> - STATX_ALL definition is unclear, can this change, or is it fixed? > > >> If it's the former, than that's a backward compatibility nightmare. > > >> If it's the latter, then what's the point? > > > > > > The value can change over time. It is intended to reflect the current > > > state of affairs at the time the userspace program and kernel are > > > compiled. > > > The value sent from userspace lets the kernel know what fields are in > > > the userspace struct, so it doesn't try to set fields that aren't there. > > > > What's the point of a userspace program specifying STATX_ALL? Without > > a way to programmatically query the interface definition it's useless: > > there's no way to guess which mask bit corresponds to which field, and > > what that field represents. > > > > And there will be programs out there which specify STATX_ALL without > > considering that in the future it may become slower as it is now due > > to a recompile. > > > > So what's the point exactly? > > > > > The value in the kernel allows masking off new fields from userspace that > > > it doesn't understand. > > > > Okay, but that has nothing to do with the UAPI. Even as an internal > > flag we should be careful, as it might grow uses which can have > > similar issues as the userspace one above. > > > > FYI, I identified a similar anti-pattern in fanotify UAPI when I wanted to > add new flags and did not want to change the UAPI _ALL_ constants. > This is how we plan to solve it: > https://github.com/amir73il/linux/commit/8c2b1acadb88ee4505ccc8bfdc665863111fb4cc Yeah, after fanotify experience I find foo_ALL constants useless if not dangerous for userspace. Kernel internal constants like this are IMO useful. Honza -- Jan Kara SUSE Labs, CR
Re: [RFC PATCH 1/5] x86: introduce preemption disable prefix
On Wed, Oct 17, 2018 at 06:22:48PM -0700, Andy Lutomirski wrote: > > > On Oct 17, 2018, at 5:54 PM, Nadav Amit wrote: > > > > It is sometimes beneficial to prevent preemption for very few > > instructions, or prevent preemption for some instructions that precede > > a branch (this latter case will be introduced in the next patches). > > > > To provide such functionality on x86-64, we use an empty REX-prefix > > (opcode 0x40) as an indication that preemption is disabled for the > > following instruction. > > Nifty! > > That being said, I think you have a few bugs. > First, you can’t just ignore a rescheduling interrupt, as you > introduce unbounded latency when this happens — you’re effectively > emulating preempt_enable_no_resched(), which is not a drop-in > replacement for preempt_enable(). > To fix this, you may need to jump to a slow-path trampoline that calls > schedule() at the end or consider rewinding one instruction instead. > Or use TF, which is only a little bit terrifying... At which point we're very close to in-kernel rseq.
Re: [PATCH v3] mm: memcontrol: Don't flood OOM messages with no eligible task.
On Thu 18-10-18 15:10:18, Sergey Senozhatsky wrote: [...] > and let's hear from MM people what they can suggest. > > Michal, Andrew, Johannes, any thoughts? I have already stated my position. Let's not reinvent the wheel and use the standard printk throttling. If there are cases where oom reports cause more harm than good I am open to add a knob to allow disabling it altogether (it can be even fine grained one to control whether to dump show_mem, task_list etc.). But please let's stop this dubious one-off approaches. -- Michal Hocko SUSE Labs
Re: [PATCH 1/3] x86: baytrail/cherrytrail: Rework and move P-Unit PMIC bus semaphore code
On 10/18/2018 10:36 AM, Andy Shevchenko wrote: On Thu, Oct 18, 2018 at 10:33 AM Rafael J. Wysocki wrote: On Sun, Sep 23, 2018 at 4:45 PM Hans de Goede wrote: On some BYT/CHT systems the SoC's P-Unit shares the I2C bus with the kernel. The P-Unit has a semaphore for the PMIC bus which we can take to block it from accessing the shared bus while the kernel wants to access it. Currently we have the I2C-controller driver acquiring and releasing the semaphore around each I2C transfer. There are 2 problems with this: 1) PMIC accesses often come in the form of a read-modify-write on one of the PMIC registers, we currently release the P-Unit's PMIC bus semaphore between the read and the write. If the P-Unit modifies the register during this window?, then we end up overwriting the P-Unit's changes. I believe that this is mostly an academic problem, but I'm not sure. 2) To safely access the shared I2C bus, we need to do 3 things: a) Notify the GPU driver that we are starting a window in which it may not access the P-Unit, since the P-Unit seems to ignore the semaphore for explicit power-level requests made by the GPU driver b) Make a pm_qos request to force all CPU cores out of C6/C7 since entering C6/C7 while we hold the semaphore hangs the SoC c) Finally take the P-Unit's PMIC bus semaphore All 3 these steps together are somewhat expensive, so ideally if we have a bunch of i2c transfers grouped together we only do this once for the entire group. Taking the read-modify-write on a PMIC register as example then ideally we would only do all 3 steps once at the beginning and undo all 3 steps once at the end. For this we need to be able to take the semaphore from within e.g. the PMIC opregion driver, yet we do not want to remove the taking of the semaphore from the I2C-controller driver, as that is still necessary to protect many other code-paths leading to accessing the shared I2C bus. This means that we first have the PMIC driver acquire the semaphore and then have the I2C controller driver trying to acquire it again. To make this possible this commit does the following: 1) Move the semaphore code from being private to the I2C controller driver into the generic iosf_mbi code, which already has other code to deal with the shared bus so that it can be accessed outside of the I2C bus driver. 2) Rework the code so that it can be called multiple times nested, while still blocking I2C accesses while e.g. the GPU driver has indicated the P-Unit needs the bus through a iosf_mbi_punit_acquire() call. Signed-off-by: Hans de Goede If there are no objections or concerns regarding this patch, I'm inclined to take the entire series including it. Please, go ahead, it looks good to me. Thanks! Just in case note: please remember to take patches and tags from v3 of the series, not from this v1 thread. -- Jarkko
Re: possible deadlock in ovl_copy_up_start
On Thu, Oct 18, 2018 at 8:26 AM, Amir Goldstein wrote: > Can someone tell me what the expected behavior of a nested > mutex_lock_interruptible(); ? > > Why does the reproducer only warn and not really deadlock. > It is because that is considered the lesser evil? > and obviously, then inner unlock releases the outer lock? No, it's not the same lock, just the same lock class (first one is OVL_I(d_inode(old))->lock, the other is OVL_I(d_inode(new->d_parent)))->lock). So we could possibly get away with annotating with mutex_lock_nested(). Is this the only place that ovl_i_lock is nested? Thanks, Miklos
Re: [PATCH v11 1/5] venus: firmware: add routine to reset ARM9
Hi Joe,
On 10/18/2018 04:42 AM, Joe Perches wrote:
> On Wed, 2018-10-17 at 11:49 +0300, Stanimir Varbanov wrote:
>> On 10/08/2018 04:32 PM, Vikash Garodia wrote:
>>> Add routine to reset the ARM9 and brings it out of reset. Also
>>> abstract the Venus CPU state handling with a new function. This
>>> is in preparation to add PIL functionality in venus driver.
> []
>>> diff --git a/drivers/media/platform/qcom/venus/core.h
>>> b/drivers/media/platform/qcom/venus/core.h
> []
>>> @@ -129,6 +130,7 @@ struct venus_core {
>>> struct device *dev;
>>> struct device *dev_dec;
>>> struct device *dev_enc;
>>> + bool use_tz;
>>
>> could you make it unsigned? For more info please run checkpatch --strict.
>>
>> I know that we have structure members of type bool already - that should
>> be fixed with follow-up patches, I guess.
>
> That's probably not necessary.
>
> I personally have no issue with bool struct members that
> are only used on a transitory basis and not used by hardware
> or shared between multiple cpus with different hardware
> alignment requirements.
Thanks for the clarification. I personally have preference to 'unsigned'
for such flag, but let Hans decide which one to take.
>
> Nothing in this struct is saved or shared.
>
> Perhaps the checkpatch message should be expanded to
> enumerate when bool use in a struct is acceptable.
>
It'd be good to explain more, because it sounds imperative to every
structure.
--
regards,
Stan
Re: [PATCH 3/5] dt-bindings: add more optional properties for elan_i2c touchpads
Hi, On 18-10-18 10:10, Benjamin Tissoires wrote: On Wed, Oct 17, 2018 at 10:15 PM Rob Herring wrote: On Fri, Oct 12, 2018 at 04:24:11PM +0200, Benjamin Tissoires wrote: Some new touchpads IC are connected through PS/2 and I2C. On some of these new IC, the I2C part doesn't have all of the information available. We need to be able to forward the touchpad parameters from PS/2 and thus, we need those new optional properties. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1628715 Signed-off-by: Benjamin Tissoires --- Documentation/devicetree/bindings/input/elan_i2c.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/input/elan_i2c.txt b/Documentation/devicetree/bindings/input/elan_i2c.txt index 797607460735..ace6bcb0b4eb 100644 --- a/Documentation/devicetree/bindings/input/elan_i2c.txt +++ b/Documentation/devicetree/bindings/input/elan_i2c.txt @@ -13,6 +13,14 @@ Optional properties: pinctrl binding [1]). - vcc-supply: a phandle for the regulator supplying 3.3V power. - elan,trackpoint: touchpad can support a trackpoint (boolean) +- elan,clickpad: touchpad is a clickpad (the entire surface is a button) +- elan,max_x: the maximum reported value on the X axis +- elan,max_y: the maximum reported value on the Y axis +- elan,min_x: the minimum reported value on the X axis +- elan,min_y: the minimum reported value on the Y axis +- elan,x_res: the resolution of the X axis (in units per mm) +- elan,y_res: the resolution of the Y axis (in units per mm) +- elan,width: max reported width of a blob Can't we use standard touchscreen properties here? (Yes, I get this is a touchpad, not touchscreen). Hey Rob, Well, there is that (it's a touchpad driver) and we can't also really use the of_touchscreen.c implementation. If both concerns are not an issue, we can then move the [min/max/res] properties to the touchscreen ones. Regarding 'elan,width', this is something missing from the standard ts properties, and AFAICT, this controls the maximum reported width/height of a touch. I should probably rename them to max_width, max_height. Hans, do you think we should add such properties to of_touchscreen.c too? (the width/height ones) Are there touchscreens which report finger/touch width / height ? if so then it probably does make sense. Note that for historical reasons Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt Also the touchscreen bindings have: touchscreen-x-mm and touchscreen-y-mm rather then res, which can then be used to calculate the resolution. Regards, Hans
[PATCH v4 5/8] dt-bindings: input: document stpmic1 pmic onkey
From: pascal paillet
The stpmic1 pmic is able to manage an onkey button. It can be configured
to shut-down the power supplies on a long key-press with an adjustable
duration.
Signed-off-by: pascal paillet
Reviewed-by: Rob Herring
---
changes in v4:
* remove interrupt-parent description
* remove st,onkey-pwroff-enabled and power-off-time-sec properties
.../devicetree/bindings/input/st,stpmic1-onkey.txt | 28 ++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/st,stpmic1-onkey.txt
diff --git a/Documentation/devicetree/bindings/input/st,stpmic1-onkey.txt
b/Documentation/devicetree/bindings/input/st,stpmic1-onkey.txt
new file mode 100644
index 000..4494613
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/st,stpmic1-onkey.txt
@@ -0,0 +1,28 @@
+STMicroelectronics STPMIC1 Onkey
+
+Required properties:
+
+- compatible = "st,stpmic1-onkey";
+- interrupts: interrupt line to use
+- interrupt-names = "onkey-falling", "onkey-rising"
+ onkey-falling: happens when onkey is pressed; IT_PONKEY_F of pmic
+ onkey-rising: happens when onkey is released; IT_PONKEY_R of pmic
+
+Optional properties:
+
+- st,onkey-clear-cc-flag: onkey is able power on after an
+ over-current shutdown event.
+- st,onkey-pu-inactive: onkey pull up is not active
+- power-off-time-sec: Duration in seconds which the key should be kept
+pressed for device to power off automatically (from 1 to 16 seconds).
+see See Documentation/devicetree/bindings/input/keys.txt
+
+Example:
+
+onkey {
+ compatible = "st,stpmic1-onkey";
+ interrupt-parent = <>;
+ interrupts = ,;
+ interrupt-names = "onkey-falling", "onkey-rising";
+ power-off-time-sec = <10>;
+};
--
1.9.1
[PATCH 1/2] staging: iio: ad7606: Move out of staging
Move ad7606 ADC driver out of staging and into the mainline.
Signed-off-by: Stefan Popa
---
MAINTAINERS | 7 +
drivers/iio/adc/Kconfig | 34 +++
drivers/iio/adc/Makefile | 3 +
drivers/iio/adc/ad7606.c | 565 +++
drivers/iio/adc/ad7606.h | 106 +++
drivers/iio/adc/ad7606_par.c | 113 +++
drivers/iio/adc/ad7606_spi.c | 79 +
drivers/staging/iio/adc/Kconfig | 34 ---
drivers/staging/iio/adc/Makefile | 3 -
drivers/staging/iio/adc/ad7606.c | 565 ---
drivers/staging/iio/adc/ad7606.h | 106 ---
drivers/staging/iio/adc/ad7606_par.c | 113 ---
drivers/staging/iio/adc/ad7606_spi.c | 79 -
13 files changed, 907 insertions(+), 900 deletions(-)
create mode 100644 drivers/iio/adc/ad7606.c
create mode 100644 drivers/iio/adc/ad7606.h
create mode 100644 drivers/iio/adc/ad7606_par.c
create mode 100644 drivers/iio/adc/ad7606_spi.c
delete mode 100644 drivers/staging/iio/adc/ad7606.c
delete mode 100644 drivers/staging/iio/adc/ad7606.h
delete mode 100644 drivers/staging/iio/adc/ad7606_par.c
delete mode 100644 drivers/staging/iio/adc/ad7606_spi.c
diff --git a/MAINTAINERS b/MAINTAINERS
index f642044..843545d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -839,6 +839,13 @@ S: Supported
F: drivers/iio/dac/ad5758.c
F: Documentation/devicetree/bindings/iio/dac/ad5758.txt
+ANALOG DEVICES INC AD7606 DRIVER
+M: Stefan Popa
+L: linux-...@vger.kernel.org
+W: http://ez.analog.com/community/linux-device-drivers
+S: Supported
+F: drivers/iio/adc/ad7606.c
+
ANALOG DEVICES INC AD9389B DRIVER
M: Hans Verkuil
L: linux-me...@vger.kernel.org
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index a52fea8..22bafdc 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -58,6 +58,40 @@ config AD7476
To compile this driver as a module, choose M here: the
module will be called ad7476.
+config AD7606
+ tristate "Analog Devices AD7606 ADC driver"
+ depends on GPIOLIB || COMPILE_TEST
+ depends on HAS_IOMEM
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+ Say yes here to build support for Analog Devices:
+ ad7605-4, ad7606, ad7606-6, ad7606-4 analog to digital converters
(ADC).
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad7606.
+
+config AD7606_IFACE_PARALLEL
+ tristate "parallel interface support"
+ depends on AD7606
+ help
+ Say yes here to include parallel interface support on the AD7606
+ ADC driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad7606_parallel.
+
+config AD7606_IFACE_SPI
+ tristate "spi interface support"
+ depends on AD7606
+ depends on SPI
+ help
+ Say yes here to include parallel interface support on the AD7606
+ ADC driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad7606_spi.
+
config AD7766
tristate "Analog Devices AD7766/AD7767 ADC driver"
depends on SPI_MASTER
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index a6e6a0b..b734f4f 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -8,6 +8,9 @@ obj-$(CONFIG_AD_SIGMA_DELTA) += ad_sigma_delta.o
obj-$(CONFIG_AD7266) += ad7266.o
obj-$(CONFIG_AD7291) += ad7291.o
obj-$(CONFIG_AD7298) += ad7298.o
+obj-$(CONFIG_AD7606_IFACE_PARALLEL) += ad7606_par.o
+obj-$(CONFIG_AD7606_IFACE_SPI) += ad7606_spi.o
+obj-$(CONFIG_AD7606) += ad7606.o
obj-$(CONFIG_AD7923) += ad7923.o
obj-$(CONFIG_AD7476) += ad7476.o
obj-$(CONFIG_AD7766) += ad7766.o
diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c
new file mode 100644
index 000..0b728b6
--- /dev/null
+++ b/drivers/iio/adc/ad7606.c
@@ -0,0 +1,565 @@
+/*
+ * AD7606 SPI ADC driver
+ *
+ * Copyright 2011 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "ad7606.h"
+
+/*
+ * Scales are computed as 5000/32768 and 1/32768 respectively,
+ * so that when applied to the raw values they provide mV values
+ */
+static const unsigned int scale_avail[2][2] = {
+ {0, 152588}, {0, 305176}
+};
+
+static int ad7606_reset(struct ad7606_state *st)
+{
+ if (st->gpio_reset) {
+ gpiod_set_value(st->gpio_reset, 1);
+ ndelay(100); /* t_reset >= 100ns */
+ gpiod_set_value(st->gpio_reset, 0);
+ return 0;
+ }
+
+ return -ENODEV;
+}
+
+static int ad7606_read_samples(struct ad7606_state *st)
+{
+ unsigned int num =
hi
Please reply me back I am Sgt.Sherri,
Re: [PATCH] regulator: stpmic1: Return REGULATOR_MODE_INVALID for invalid mode
Hi Axel, Thank you for your comment. As the driver is merged, I will make the change in a future patch-set. Best regards, Pascal. Le 10/09/2018 10:52 AM, Axel Lin a écrit : > -EINVAL is not a valid return value for .of_map_mode, return > REGULATOR_MODE_INVALID instead. > > Signed-off-by: Axel Lin > --- > drivers/regulator/stpmic1_regulator.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/regulator/stpmic1_regulator.c > b/drivers/regulator/stpmic1_regulator.c > index 96f18083a3b6..e15634edb8ce 100644 > --- a/drivers/regulator/stpmic1_regulator.c > +++ b/drivers/regulator/stpmic1_regulator.c > @@ -441,7 +441,7 @@ static unsigned int stpmic1_map_mode(unsigned int mode) > case STPMIC1_BUCK_MODE_LP: > return REGULATOR_MODE_STANDBY; > default: > - return -EINVAL; > + return REGULATOR_MODE_INVALID; > } > } >
Re: [PATCH 0/7] staging: vc04_services: Some dead code removal
On Wed, 17 Oct 2018 at 17:51, Peter Robinson wrote: > > > >> > Drop various pieces of dead code from here and there to get rid of > > >> > the remaining users of VCHI_CONNECTION_T. After that we get to drop > > >> > entire header files worth of unused code. > > >> > > > >> > I've tested on a Raspberry Pi Model B (bcm2835_defconfig) that > > >> > snd-bcm2835 can still play analog audio just fine. > > >> > > > >> > > >> thanks and i'm fine with your patch series: > > >> > > >> Acked-by: Stefan Wahren > > >> > > >> Unfortunately this would break compilation of the downstream vchi > > >> drivers like vcsm [1]. Personally i don't want to maintain another > > >> one, because i cannot see the gain of the resulting effort. > > >> > > >> [1] - > > >> https://github.com/raspberrypi/linux/tree/rpi-4.14.y/drivers/char/broadcom/vc_sm > > > > > > > > > I feel like everyone else already knows the answer but why don't we just > > > merge that code into staging? > > > > Dave's been working on a new VCSM service where the firmware can call > > back into Linux to allocate (instead of just having a permanent carveout > > of system memory that the firmware allocates from), and lets us make > > dma-bufs out of those buffers. That driver makes a no-copies v4l2 media > > decode driver possible, which would then let Kodi and similar projects > > switch from downstream kernels with closed graphics to upstream kernels > > with open graphics. > > > > Given that the new VCSM service is a rewrite, it's not clear to me that > > importing the old VCSM driver is a win. But maybe we should go raid > > https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2a and grab > > the new drivers. Upstreaming the VCHI audio driver to staging has > > clearly been a win for it, so maybe other eyes on the new v4l2 codec > > could help Dave along in stabilizing it. > > I think that makes sense as long as the firmware side changes are in > place so it can actually be used. The firmware has supported the necessary for dmabuf import since Sept 2017. The new vcsm driver currently only supports importing from other kernel modules as I cut it back to the bare minimum to ease upstreaming. To be a complete replacement of the existing then it needs to support userspace alloc/free/import/mmap. I did have most of that working, but will add it in stages. The codec code is working for decode but something is off for setting formats on encode. Both drivers are loading through DT at the moment as I couldn't get Eric's platform driver stuff working. IIRC A combination of modules not getting loaded and getting the appropriate coherent DMA mask set (being under soc in DT gives the correct mappings, but being a platform driver didn't). I'm fire-fighting a networking issue at the moment, but hope to be back on codecs next week. Could you hold off raiding my trees until say Fri 26th Oct so I can ensure they are fully up to date? If I get a chance then I'll start the work of porting into staging before then. Dave
Re: [RFC][PATCH] perf: Rewrite core context handling
Hi,
On 17.10.2018 19:30, Peter Zijlstra wrote:
> On Wed, Oct 17, 2018 at 11:57:49AM +0300, Alexey Budankov wrote:
>> Hi,
>>
>> On 10.10.2018 13:45, Peter Zijlstra wrote:
>>
>>> -static bool perf_rotate_context(struct perf_cpu_context *cpuctx)
>>> +/*
>>> + * XXX somewhat completely buggered; this is in cpu_pmu_context, but we
>>> need
>>> + * event_pmu_context for rotations. We also need event_pmu_context specific
>>> + * scheduling routines. ARGH
>>> + *
>>> + * - fixed the cpu_pmu_context vs event_pmu_context thingy
>>> + *(cpu_pmu_context embeds an event_pmu_context)
>>> + *
>>> + * - need nr_events/nr_active in epc to do per epc rotation
>>> + *(done)
>>> + *
>>> + * - need cpu and task pmu ctx together...
>>> + *(cpc->task_epc)
>>> + */
>>> +static bool perf_rotate_context(struct perf_cpu_pmu_context *cpc)
>>
>> Since it reduces to single cpu context (and single task context) at all
>> times,
>> ideally, it would probably be coded as simple as this:
>>
>> perf_rotate_context()
>> {
>> cpu = this_cpu_ptr(_context)
>> for_every_pmu(pmu, cpu)
>
> Can't do that, because we have per PMU rotation periods..
Well, yes, the callback is already called per-cpu per-pmu,
so then this simplifies a bit, like this:
perf_rotate_context(pmu, cpu)
{
for_every_event_ctx(event_ctx, pmu)
rotate(event_ctx, pmu)
}
event_ctx
|
v
pmu (struct perf_cpu_pmu_context) -> ctx__0 -> ctx__1
| |
v v
sched_out -> fgroup00 fgroup01 -> event001 ->
event101 -> event201
| ^ | ^
v | v |
fgroup10 fgroup11
| | | |
v | v |
sched_in -> fgroup20 fgroup21
>
>> for_every_event_ctx(event_ctx, pmu)
>> rotate(event_ctx, pmu)
>> }
>
> I'm also not sure I get the rest that follows... you only have to rotate
> _one_ event per PMU.
Yes. One group per PMU. It could end up in several HW counters reprogramming.
Thanks,
Alexey
>
> I'll try and understand the rest of you email later; brain has checked
> out for the day.
>
Re: [PATCH v3 2/2] selftests/memfd: Add tests for F_SEAL_FS_WRITE seal
On Wed, Oct 17, 2018 at 11:59 PM, Joel Fernandes (Google)
wrote:
> Add tests to verify sealing memfds with the F_SEAL_FS_WRITE works as
> expected.
I messed the commit message it should be "F_SEAL_FUTURE_WRITE", but
otherwise this
patch itself is good and I'll resend it with the corrected commit
message after further review.
thanks,
- Joel
> Cc: dan...@google.com
> Cc: minc...@kernel.org
> Reviewed-by: John Stultz
> Signed-off-by: Joel Fernandes (Google)
> ---
> tools/testing/selftests/memfd/memfd_test.c | 74 ++
> 1 file changed, 74 insertions(+)
>
> diff --git a/tools/testing/selftests/memfd/memfd_test.c
> b/tools/testing/selftests/memfd/memfd_test.c
> index 10baa1652fc2..32b207ca7372 100644
> --- a/tools/testing/selftests/memfd/memfd_test.c
> +++ b/tools/testing/selftests/memfd/memfd_test.c
> @@ -692,6 +692,79 @@ static void test_seal_write(void)
> close(fd);
> }
>
> +/*
> + * Test SEAL_FUTURE_WRITE
> + * Test whether SEAL_FUTURE_WRITE actually prevents modifications.
> + */
> +static void test_seal_future_write(void)
> +{
> + int fd;
> + void *p;
> +
> + printf("%s SEAL-FUTURE-WRITE\n", memfd_str);
> +
> + fd = mfd_assert_new("kern_memfd_seal_future_write",
> + mfd_def_size,
> + MFD_CLOEXEC | MFD_ALLOW_SEALING);
> +
> + p = mfd_assert_mmap_shared(fd);
> +
> + mfd_assert_has_seals(fd, 0);
> + /* Not adding grow/shrink seals makes the future write
> +* seal fail to get added
> +*/
> + mfd_fail_add_seals(fd, F_SEAL_FUTURE_WRITE);
> +
> + mfd_assert_add_seals(fd, F_SEAL_GROW);
> + mfd_assert_has_seals(fd, F_SEAL_GROW);
> +
> + /* Should still fail since shrink seal has
> +* not yet been added
> +*/
> + mfd_fail_add_seals(fd, F_SEAL_FUTURE_WRITE);
> +
> + mfd_assert_add_seals(fd, F_SEAL_SHRINK);
> + mfd_assert_has_seals(fd, F_SEAL_GROW |
> +F_SEAL_SHRINK);
> +
> + /* Now should succeed, also verifies that the seal
> +* could be added with an existing writable mmap
> +*/
> + mfd_assert_add_seals(fd, F_SEAL_FUTURE_WRITE);
> + mfd_assert_has_seals(fd, F_SEAL_SHRINK |
> +F_SEAL_GROW |
> +F_SEAL_FUTURE_WRITE);
> +
> + /* read should pass, writes should fail */
> + mfd_assert_read(fd);
> + mfd_fail_write(fd);
> +
> + munmap(p, mfd_def_size);
> + close(fd);
> +
> + /* Test adding all seals (grow, shrink, future write) at once */
> + fd = mfd_assert_new("kern_memfd_seal_future_write2",
> + mfd_def_size,
> + MFD_CLOEXEC | MFD_ALLOW_SEALING);
> +
> + p = mfd_assert_mmap_shared(fd);
> +
> + mfd_assert_has_seals(fd, 0);
> + mfd_assert_add_seals(fd, F_SEAL_SHRINK |
> +F_SEAL_GROW |
> +F_SEAL_FUTURE_WRITE);
> + mfd_assert_has_seals(fd, F_SEAL_SHRINK |
> +F_SEAL_GROW |
> +F_SEAL_FUTURE_WRITE);
> +
> + /* read should pass, writes should fail */
> + mfd_assert_read(fd);
> + mfd_fail_write(fd);
> +
> + munmap(p, mfd_def_size);
> + close(fd);
> +}
> +
> /*
> * Test SEAL_SHRINK
> * Test whether SEAL_SHRINK actually prevents shrinking
> @@ -945,6 +1018,7 @@ int main(int argc, char **argv)
> test_basic();
>
> test_seal_write();
> + test_seal_future_write();
> test_seal_shrink();
> test_seal_grow();
> test_seal_resize();
> --
> 2.19.1.331.ge82ca0e54c-goog
>
Re: l1tf: Kernel suggests I throw away third of my memory. I'd rather not
On 10/18/18 12:21 AM, Dave Hansen wrote: > On 10/17/2018 04:32 AM, Pavel Machek wrote: >>> Well, that depends. Do you care about PROT_NONE attacks as well? If not >>> then no-swap would help you. But even then no-swap is rather theoretical >>> attack on a physical host unless you allow an arbitrary swapout to a >>> malicious user (e.g. allow a user controlled memcg hard limit that would >>> cause excessive local swapouts). >> PROT_NONE attack.. aha, so kernel stores not only information about >> swapped-out pages but also about file-backed pages that are currently >> not present? Hmm. That makes it more complex :-(. > > There are also migration PTE entries that are "swap-like". They can > exist even if you swapoff -a. > > Can we do better? Sure. I think we'd all be happy to review patches > that improve the situation if folks have simple ideas for improvement. I think if would be rather unfortunate changing this fundamentally due to a HW bug that should hopefully eventually go away with new CPUs, and with MAX_PA/2 being limited only on very old CPUs. I don't think using page table entries like this is a hack. The pte must IMHO always carry some information that identifies is as swap entry or prot_none or whatever. If we had to look up the swap offset (or pfn associated with PROT_NONE pte elsewhere), there would be additional overhead both for storing this mapping and for looking it up. PTEs seems just like a natural place for this IMHO, and it's defined that the bits can be used by the kernel however it likes for !present PTEs. Why rewrite it all just because some CPUs implementation is not as defined...
Re: [PATCH 1/3] x86: baytrail/cherrytrail: Rework and move P-Unit PMIC bus semaphore code
On Sun, Sep 23, 2018 at 4:45 PM Hans de Goede wrote: > > On some BYT/CHT systems the SoC's P-Unit shares the I2C bus with the > kernel. The P-Unit has a semaphore for the PMIC bus which we can take to > block it from accessing the shared bus while the kernel wants to access it. > > Currently we have the I2C-controller driver acquiring and releasing the > semaphore around each I2C transfer. There are 2 problems with this: > > 1) PMIC accesses often come in the form of a read-modify-write on one of > the PMIC registers, we currently release the P-Unit's PMIC bus semaphore > between the read and the write. If the P-Unit modifies the register during > this window?, then we end up overwriting the P-Unit's changes. > I believe that this is mostly an academic problem, but I'm not sure. > > 2) To safely access the shared I2C bus, we need to do 3 things: > a) Notify the GPU driver that we are starting a window in which it may not > access the P-Unit, since the P-Unit seems to ignore the semaphore for > explicit power-level requests made by the GPU driver > b) Make a pm_qos request to force all CPU cores out of C6/C7 since entering > C6/C7 while we hold the semaphore hangs the SoC > c) Finally take the P-Unit's PMIC bus semaphore > All 3 these steps together are somewhat expensive, so ideally if we have > a bunch of i2c transfers grouped together we only do this once for the > entire group. > > Taking the read-modify-write on a PMIC register as example then ideally we > would only do all 3 steps once at the beginning and undo all 3 steps once > at the end. > > For this we need to be able to take the semaphore from within e.g. the PMIC > opregion driver, yet we do not want to remove the taking of the semaphore > from the I2C-controller driver, as that is still necessary to protect many > other code-paths leading to accessing the shared I2C bus. > > This means that we first have the PMIC driver acquire the semaphore and > then have the I2C controller driver trying to acquire it again. > > To make this possible this commit does the following: > > 1) Move the semaphore code from being private to the I2C controller driver > into the generic iosf_mbi code, which already has other code to deal with > the shared bus so that it can be accessed outside of the I2C bus driver. > > 2) Rework the code so that it can be called multiple times nested, while > still blocking I2C accesses while e.g. the GPU driver has indicated the > P-Unit needs the bus through a iosf_mbi_punit_acquire() call. > > Signed-off-by: Hans de Goede If there are no objections or concerns regarding this patch, I'm inclined to take the entire series including it. > --- > Note this commit deliberately limits the i2c-designware changes to > only touch i2c-designware-baytrail.c, deliberately not doing some cleanups > which become possible after removing the semaphore code from the > i2c-designmware code. This is done so that this commit can be merged > through the x86 tree without causing conflicts in the i2c tree. > > The cleanups to the i2c-designware tree will be done in a follow up > patch which can be merged once this commit is in place. > --- > arch/x86/include/asm/iosf_mbi.h | 39 +++-- > arch/x86/platform/intel/iosf_mbi.c | 161 +-- > drivers/i2c/busses/i2c-designware-baytrail.c | 125 +- > 3 files changed, 180 insertions(+), 145 deletions(-) > > diff --git a/arch/x86/include/asm/iosf_mbi.h b/arch/x86/include/asm/iosf_mbi.h > index 3de0489deade..5270ff39b9af 100644 > --- a/arch/x86/include/asm/iosf_mbi.h > +++ b/arch/x86/include/asm/iosf_mbi.h > @@ -105,8 +105,10 @@ int iosf_mbi_modify(u8 port, u8 opcode, u32 offset, u32 > mdr, u32 mask); > * the PMIC bus while another driver is also accessing the PMIC bus various > bad > * things happen. > * > - * To avoid these problems this function must be called before accessing the > - * P-Unit or the PMIC, be it through iosf_mbi* functions or through other > means. > + * Call this function before sending requests to the P-Unit which may make it > + * access the PMIC, be it through iosf_mbi* functions or through other means. > + * This function will block all kernel access to the PMIC I2C bus, so that > the > + * P-Unit can safely access the PMIC over the shared I2C bus. > * > * Note on these systems the i2c-bus driver will request a sempahore from the > * P-Unit for exclusive access to the PMIC bus when i2c drivers are accessing > @@ -122,6 +124,31 @@ void iosf_mbi_punit_acquire(void); > */ > void iosf_mbi_punit_release(void); > > +/** > + * iosf_mbi_block_punit_i2c_access() - Block P-Unit accesses to the PMIC bus > + * > + * Call this function to block P-Unit access to the PMIC I2C bus, so that the > + * kernel can safely access the PMIC over the shared I2C bus. > + * > + * This function acquires the P-Unit bus semaphore and notifies > + * pmic_bus_access_notifier listeners that they may no longer access the > + * P-Unit in a way which
Re: [PATCH] dt-bindings: ufs: Fix the compatible string definition
On 10/17/2018 9:41 PM, Doug Anderson wrote:
Hi,
On Tue, Oct 16, 2018 at 11:28 PM Vivek Gautam
wrote:
Hi Doug,
On 10/16/2018 10:29 PM, Doug Anderson wrote:
Hi,
On Mon, Oct 15, 2018 at 10:51 PM Vivek Gautam
wrote:
P.S.: While you are at it, can you please move 'ufs-qcom.txt'
to Documentation/devicetree/bindings/phy/qcom,ufs-phy.txt.
The current name and file location is misleading.
I'd rather someone at Qualcomm do this. Do you have a suggested
person? The reason I feel that Qualcomm needs to get involved is that
I see that when I look at the file you refer to says it's for:
"qcom,ufs-phy-qmp-20nm" for 20nm ufs phy,
"qcom,ufs-phy-qmp-14nm" for legacy 14nm ufs phy,
"qcom,msm8996-ufs-phy-qmp-14nm" for 14nm ufs phy
present on MSM8996 chipset.
...but there's another Qualcomm file, 'qcom-qmp-phy.txt'. That
handles the compatible string:
"qcom,sdm845-qmp-ufs-phy" for UFS QMP phy on sdm845.
So I'm a little confused. Should the SDM845 UFS PHY been handled by
the older UFS PHY driver? ...or should all the older UFS PHYs be
moved to be handled by the newer QMP PHY driver? ...or are they
really different hardware blocks, in which case how would you describe
the difference (both are described as UFS QMP PHYs I think).
As you rightly said "ufs/ufs-qcom.txt" describes the bindings for
14nm, and 20nm ufs phy. These phys are however handled by the older
ufs phy driver present at:
drivers/phy/qualcomm/phy-qcom-ufs-qmp-{14nm,20nm}.c
The sdm845 UFS phy driver is handled by the new consolidated qmp phy
driver: drivers/phy/qualcomm/phy-qcom-qmp.c whose bindings are
described by 'qcom-qmp-phy.txt'.
We didn't attempt to move the 14nm phy to new driver as we already had
8996 using the bindings.
So, really these are two separate drivers with different bindings. I
believe it should be okay to move the file. If you are fine, I can
attempt to post a small patch to do that.
I guess what I should have said was that the new name you're proposing
"qcom,ufs-phy.txt" is confusing and opening the file doesn't help
clarify things. The name and the binding make it sound like this is
_the_ file to look at for Qualcomm UFS PHYs. ...and then you look in
the examples in the file and it seems that this even includes Qualcomm
QMP PHYs for UFS.
...so while I agree that the file "ufs-qcom.txt" needs to be moved to
the "PHY" directory, I think at the same time we need to change the
name of the file and maybe the contents to disambiguate which things
belong in this file vs. the "qcom-qmp-phy.txt". ...and I feel like
someone at Qualcomm will have the most information to properly do
that.
For instance, you could call the older bindings
"qcom-qmp-phy-14nm-20nm.txt" or something like that.
Sure, I get your point. I will propose something that removes the confusion.
One point of clarification I'd like to know is if there's really a
good reason to have two drivers here. Certainly if the hardware is
really different then a new driver can make sense, but if there are
two drivers for arbitrary reasons then maybe they should be combined
into one eventually?
Right, the 14nm phy driver can be happily merged into the new qmp-phy
driver.
But we should take care of older bindings. Removing the driver will break
things on targets with older bindings, precisely 8996.
20nm is bit tricky as it exported few APIs directly to ufs host
controller, and
that's the reason we have declared that as BROKEN after the ufs cleanup.
So, until we are really in a kill mode, the old ufs-phy driver will have
to live.
OK, sounds like a plan. I'll assume you're posting the patch to move
the old PHY bindings and add some of the above information to them so
people aren't confused.
...all this is sort off the original subject, though. ;-) Just a
quick summary here is that nothing suggests ${SUBJECT} patch shouldn't
land and all the additional discussion has been about making further
improvements to the bindings situation for UFS on Qualcomm.
Yes, this patch is good to go.
Thanks
Vivek
-Doug
Re: [PATCH v3] Bluetooth: hci_qca: Add support for controller debug logs.
Hi Balakrishna, > This patch will prevent error messages splashing on console. > > [ 78.426697] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL packet > for unknown connection handle 3804 > [ 78.436682] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL packet > for unknown connection handle 3804 > [ 78.446639] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL packet > for unknown connection handle 3804 > [ 78.456596] Bluetooth: hci_core.c:hci_acldata_packet() hci0: ACL packet > for unknown connection handle 3804 > > QCA wcn3990 will send the debug logs in the form of ACL packets. > While decoding packet in qca_recv(), marking the received debug log > packet as diagnostic packet. > > Signed-off-by: Harish Bandi > Signed-off-by: Balakrishna Godavarthi > --- > v3: > * used get_unaligned_le16() instead of checking individual bytes > v2: > * Addressed reviewer comments. > v1: > * initial patch > --- > drivers/bluetooth/hci_qca.c | 19 ++- > 1 file changed, 18 insertions(+), 1 deletion(-) patch has been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH v3 3/3] i2c: designware: Cleanup bus lock handling
On Mon, Oct 15, 2018 at 05:15:47PM +0300, Jarkko Nikula wrote: > On 10/11/2018 05:29 PM, Hans de Goede wrote: > > Now that most of the special Bay- / Cherry-Trail bus lock handling has > > been moved to the iosf_mbi code we can simplify the remaining code a bit. > > > > Signed-off-by: Hans de Goede > > --- > > drivers/i2c/busses/i2c-designware-baytrail.c | 18 ++ > > drivers/i2c/busses/i2c-designware-common.c | 4 ++-- > > drivers/i2c/busses/i2c-designware-core.h | 9 ++--- > > drivers/i2c/busses/i2c-designware-platdrv.c | 2 -- > > 4 files changed, 6 insertions(+), 27 deletions(-) > > > Acked-by: Jarkko Nikula > Tested-by: Jarkko Nikula Acked-by: Wolfram Sang signature.asc Description: PGP signature
[PATCH] RDMA/hns: Use 64-bit arithmetic instead of 32-bit
Cast *max_num_sg* to u64 in order to give the compiler complete
information about the proper arithmetic to use.
Notice that such variable is used in a context that expects an
expression of type u64 (64 bits, unsigned) and the following
expression is currently being evaluated using 32-bit
arithmetic:
length = max_num_sg * page_size;
Addresses-Coverity-ID: 1474517 ("Unintentional integer overflow")
Signed-off-by: Gustavo A. R. Silva
---
drivers/infiniband/hw/hns/hns_roce_mr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/hns/hns_roce_mr.c
b/drivers/infiniband/hw/hns/hns_roce_mr.c
index 521ad2a..d479d5e 100644
--- a/drivers/infiniband/hw/hns/hns_roce_mr.c
+++ b/drivers/infiniband/hw/hns/hns_roce_mr.c
@@ -1219,7 +1219,7 @@ struct ib_mr *hns_roce_alloc_mr(struct ib_pd *pd, enum
ib_mr_type mr_type,
int ret;
page_size = 1 << (hr_dev->caps.pbl_buf_pg_sz + PAGE_SHIFT);
- length = max_num_sg * page_size;
+ length = (u64)max_num_sg * page_size;
if (mr_type != IB_MR_TYPE_MEM_REG)
return ERR_PTR(-EINVAL);
--
2.7.4
