Re: linux-next: build failure after merge of the clockevents tree
Hi Stephen,
I dropped the patch from my tree.
Thanks
-- Daniel
On 03/06/2019 04:13, Stephen Rothwell wrote:
> Hi Daniel,
>
> After merging the clockevents tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/clocksource/timer-atmel-tcb.c: In function 'tcb_clksrc_init':
> drivers/clocksource/timer-atmel-tcb.c:448:17: error: invalid use of undefined
> type 'struct delay_timer'
>tc_delay_timer.read_current_timer = tc_delay_timer_read32;
> ^
> drivers/clocksource/timer-atmel-tcb.c:461:17: error: invalid use of undefined
> type 'struct delay_timer'
>tc_delay_timer.read_current_timer = tc_delay_timer_read;
> ^
> drivers/clocksource/timer-atmel-tcb.c:476:16: error: invalid use of undefined
> type 'struct delay_timer'
> tc_delay_timer.freq = divided_rate;
> ^
> drivers/clocksource/timer-atmel-tcb.c:477:2: error: implicit declaration of
> function 'register_current_timer_delay'; did you mean 'read_current_timer'?
> [-Werror=implicit-function-declaration]
> register_current_timer_delay(_delay_timer);
> ^~~~
> read_current_timer
> drivers/clocksource/timer-atmel-tcb.c: At top level:
> drivers/clocksource/timer-atmel-tcb.c:129:27: error: storage size of
> 'tc_delay_timer' isn't known
> static struct delay_timer tc_delay_timer;
>^~
> cc1: some warnings being treated as errors
>
> Caused by commit
>
> dd40f5020581 ("clocksource/drivers/tcb_clksrc: Register delay timer")
>
> I have reverted that commit for today.
>
--
Facebook |
Twitter |
RE: [PATCH] dt-bindings: thermal: Make cooling-maps property optional
Hi Edubezval, Rui, Any further comments? BR, Andy > -Original Message- > From: Yuantian Tang > Sent: 2019年5月15日 17:37 > To: rui.zh...@intel.com; edubez...@gmail.com > Cc: robh...@kernel.org; daniel.lezc...@linaro.org; mark.rutl...@arm.com; > linux...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; Andy Tang > Subject: [PATCH] dt-bindings: thermal: Make cooling-maps property optional > > There may be no cooling device on system, or there are no enough cooling > devices for each thermal zone in multiple thermal zone cases since cooling > devices can't be shared. > So make this property optional to remove such limitations. > > Signed-off-by: Yuantian Tang > --- > .../devicetree/bindings/thermal/thermal.txt|4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt > b/Documentation/devicetree/bindings/thermal/thermal.txt > index ca14ba9..694e834 100644 > --- a/Documentation/devicetree/bindings/thermal/thermal.txt > +++ b/Documentation/devicetree/bindings/thermal/thermal.txt > @@ -142,11 +142,11 @@ Required properties: > - trips: A sub-node which is a container of only trip point nodes >Type: sub-node required to describe the thermal zone. > > + > +Optional property: > - cooling-maps: A sub-node which is a container of only cooling > device >Type: sub-node map nodes, used to describe the relation between > trips > and cooling devices. > - > -Optional property: > - coefficients: An array of integers (one signed cell) > containing >Type: arraycoefficients to compose a linear relation > between >Elem size: one cellthe sensors listed in the thermal-sensors > property. > -- > 1.7.1
Re: [PATCH 5.1 00/40] 5.1.7-stable review
On Mon, Jun 03, 2019 at 10:17:28AM -0700, Guenter Roeck wrote: > On Mon, Jun 03, 2019 at 11:08:53AM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.1.7 release. > > There are 40 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 Wed 05 Jun 2019 09:04:46 AM UTC. > > Anything received after that time might be too late. > > > Build results: > total: 159 pass: 159 fail: 0 > Qemu test results: > total: 349 pass: 349 fail: 0 Wonderful, thanks for testing these and letting me know greg k-h
Re: [PATCH 1/3] clocksource/arm_arch_timer: mark arch_counter_get_* as notrace
Hi Anders,
thanks for your patch. As mentioned by Mark I already applied this fix
from Julien Thierry.
-- Daniel
On 03/06/2019 11:23, Marc Zyngier wrote:
> Hi Anders,
>
>
> On 03/06/2019 10:12, Anders Roxell wrote:
>> When CONFIG_FUNCTION_GRAPH_TRACER is enabled we end up in this circular
>> call trace since function arch_counter_get_cntvct() isn't marked with no
>> trace:
>>
>> [ 17.914934] Call trace:
>> [ 17.915211] ftrace_return_to_handler+0x194/0x288
>> [ 17.915551] return_to_handler+0x1c/0x38
>> [ 17.915855] trace_clock_local+0x38/0x88
>> [ 17.916159] function_graph_enter+0xf0/0x258
>> [ 17.916465] prepare_ftrace_return+0x60/0x90
>> [ 17.916772] ftrace_graph_caller+0x1c/0x24
>> [ 17.917093] arch_counter_get_cntvct+0x10/0x30
>> [ 17.917417] sched_clock+0x70/0x218
>> [ 17.917723] trace_clock_local+0x38/0x88
>> [ 17.918026] function_graph_enter+0xf0/0x258
>> [ 17.918332] prepare_ftrace_return+0x60/0x90
>> [ 17.918649] ftrace_graph_caller+0x1c/0x24
>> [ 17.918963] arch_counter_get_cntvct+0x10/0x30
>> [ 17.919286] sched_clock+0x70/0x218
>>
>> Rework so that function arch_counter_get_cntvct() is marked with notrace.
>>
>> Fixes: 0ea415390cd3 ("clocksource/arm_arch_timer: Use
>> arch_timer_read_counter to access stable counters")
>> Signed-off-by: Anders Roxell
>
> This has already been queued by Daniel, I believe [1].
>
> [1]
> https://lore.kernel.org/lkml/1558689025-50679-1-git-send-email-julien.thie...@arm.com/
--
Facebook |
Twitter |
Re: [PATCH 5.1 00/40] 5.1.7-stable review
On Tue, Jun 04, 2019 at 01:03:21AM +0530, Naresh Kamboju wrote: > On Mon, 3 Jun 2019 at 14:44, Greg Kroah-Hartman > wrote: > > > > This is the start of the stable review cycle for the 5.1.7 release. > > There are 40 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 Wed 05 Jun 2019 09:04:46 AM UTC. > > 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/v5.x/stable-review/patch-5.1.7-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-5.1.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Results from Linaro’s test farm. > No regressions on arm64, arm, x86_64, and i386. Great, thanks for testing these and letting me know. greg k-h
Re: [PATCH 5.1 00/40] 5.1.7-stable review
On Mon, Jun 03, 2019 at 07:34:09PM +0100, Jon Hunter wrote: > > On 03/06/2019 10:08, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.1.7 release. > > There are 40 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 Wed 05 Jun 2019 09:04:46 AM UTC. > > 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/v5.x/stable-review/patch-5.1.7-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-5.1.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > All tests are passing for Tegra ... > > Test results for stable-v5.1: > 12 builds:12 pass, 0 fail > 22 boots: 22 pass, 0 fail > 32 tests: 32 pass, 0 fail > > Linux version:5.1.7-rc1-ge674455 > Boards tested:tegra124-jetson-tk1, tegra186-p2771-, > tegra194-p2972-, tegra20-ventana, > tegra210-p2371-2180, tegra30-cardhu-a04 Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH 5.1 00/40] 5.1.7-stable review
On Mon, Jun 03, 2019 at 05:31:48PM -0600, shuah wrote: > On 6/3/19 3:08 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.1.7 release. > > There are 40 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 Wed 05 Jun 2019 09:04:46 AM UTC. > > 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/v5.x/stable-review/patch-5.1.7-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-5.1.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 of these and letting me know. greg k-h
Re: [PATCH 5.1 00/40] 5.1.7-stable review
On Mon, Jun 03, 2019 at 11:28:23AM -0700, Kevin Hilman wrote: > "kernelci.org bot" writes: > > > stable-rc/linux-5.1.y boot: 132 boots: 1 failed, 131 passed > > (v5.1.6-41-ge674455b9242) > > > > Full Boot Summary: > > https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.1.y/kernel/v5.1.6-41-ge674455b9242/ > > Full Build Summary: > > https://kernelci.org/build/stable-rc/branch/linux-5.1.y/kernel/v5.1.6-41-ge674455b9242/ > > > > Tree: stable-rc > > Branch: linux-5.1.y > > Git Describe: v5.1.6-41-ge674455b9242 > > Git Commit: e674455b924207b06e6527d961a4b617cf13e7a9 > > Git URL: > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > Tested: 73 unique boards, 23 SoC families, 14 builds out of 209 > > > > Boot Failure Detected: > > > > arm: > > multi_v7_defconfig: > > gcc-8: > > bcm4708-smartrg-sr400ac: 1 failed lab > > FYI, this one has been fixed and marked with Fixes tag[1], but it > appears the patch hasn't yet landed in mainline. A Fixes: tag will not guarantee it will make it into a stable release. It might, a month or so later, if we get bored. You should always use a Cc: stable@ tag instead, as that is the documented way to ensure that the patch makes it into a stable release. Once this hits Linus's tree, send me the SHA1 and I will be glad to queue it up. thanks, greg k-h
Re: [PATCH V4 1/6] csky: Init pmu as a device
Hello Mao,
On Tue, Jun 4, 2019 at 10:25 AM Mao Han wrote:
>
> This patch change the csky pmu initialization from arch init to
> device init. The pmu can be configued with information from
> device tree(pmu device name, irq number and etc.).
>
> Signed-off-by: Mao Han
> Cc: Guo Ren
> ---
> arch/csky/kernel/perf_event.c | 58
> ++-
> 1 file changed, 57 insertions(+), 1 deletion(-)
>
> diff --git a/arch/csky/kernel/perf_event.c b/arch/csky/kernel/perf_event.c
> index 376c972..c022acc 100644
> --- a/arch/csky/kernel/perf_event.c
> +++ b/arch/csky/kernel/perf_event.c
> @@ -21,6 +21,8 @@ struct csky_pmu_t {
> uint32_thpcr;
> } csky_pmu;
>
> +typedef int (*csky_pmu_init)(struct csky_pmu_t *);
Is the type of csky_pmu_init() the same with init_hw_perf_events ?
And I also think you should remove the hook style, because there
is only one init for the driver.
> +
> #define cprgr(reg) \
> ({ \
> unsigned int tmp; \
> @@ -1028,4 +1030,58 @@ int __init init_hw_perf_events(void)
>
> return perf_pmu_register(_pmu.pmu, "cpu", PERF_TYPE_RAW);
> }
> -arch_initcall(init_hw_perf_events);
> +
> +int csky_pmu_device_probe(struct platform_device *pdev,
> + const struct of_device_id *of_table)
> +{
> + const struct of_device_id *of_id;
> + csky_pmu_init init_fn;
> + struct device_node *node = pdev->dev.of_node;
> + int ret = -ENODEV;
> +
> + of_id = of_match_node(of_table, pdev->dev.of_node);
> + if (node && of_id) {
> + init_fn = of_id->data;
> + ret = init_fn(_pmu);
> + }
Ditto, all 7 lines above should be removed and use directly like:
ret = init_hw_perf_events();
> + if (ret) {
> + pr_notice("[perf] failed to probe PMU!\n");
> + return ret;
> + }
> +
> + return ret;
> +}
> +
> +const static struct of_device_id csky_pmu_of_device_ids[] = {
> + {.compatible = "csky,csky-pmu", .data = init_hw_perf_events},
Ditto, Nothing for .data.
Best Regards
Guo Ren
Re: [PATCHv6 3/3] vfio/mdev: Synchronize device create/remove with parent removal
On Mon, 3 Jun 2019 13:56:58 -0500
Parav Pandit wrote:
> In following sequences, child devices created while removing mdev parent
> device can be left out, or it may lead to race of removing half
> initialized child mdev devices.
>
> issue-1:
>
>cpu-0 cpu-1
>- -
> mdev_unregister_device()
> device_for_each_child()
> mdev_device_remove_cb()
> mdev_device_remove()
> create_store()
> mdev_device_create() [...]
> device_add()
> parent_remove_sysfs_files()
>
> /* BUG: device added by cpu-0
> * whose parent is getting removed
> * and it won't process this mdev.
> */
>
> issue-2:
>
> Below crash is observed when user initiated remove is in progress
> and mdev_unregister_driver() completes parent unregistration.
>
>cpu-0 cpu-1
>- -
> remove_store()
>mdev_device_remove()
>active = false;
> mdev_unregister_device()
> parent device removed.
>[...]
>parents->ops->remove()
> /*
> * BUG: Accessing invalid parent.
> */
>
> This is similar race like create() racing with mdev_unregister_device().
>
> BUG: unable to handle kernel paging request at c0585668
> PGD e8f618067 P4D e8f618067 PUD e8f61a067 PMD 85adca067 PTE 0
> Oops: [#1] SMP PTI
> CPU: 41 PID: 37403 Comm: bash Kdump: loaded Not tainted 5.1.0-rc6-vdevbus+ #6
> Hardware name: Supermicro SYS-6028U-TR4+/X10DRU-i+, BIOS 2.0b 08/09/2016
> RIP: 0010:mdev_device_remove+0xfa/0x140 [mdev]
> Call Trace:
> remove_store+0x71/0x90 [mdev]
> kernfs_fop_write+0x113/0x1a0
> vfs_write+0xad/0x1b0
> ksys_write+0x5a/0xe0
> do_syscall_64+0x5a/0x210
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Therefore, mdev core is improved as below to overcome above issues.
>
> Wait for any ongoing mdev create() and remove() to finish before
> unregistering parent device.
> This continues to allow multiple create and remove to progress in
> parallel for different mdev devices as most common case.
> At the same time guard parent removal while parent is being accessed by
> create() and remove() callbacks.
> create()/remove() and unregister_device() are synchronized by the rwsem.
>
> Refactor device removal code to mdev_device_remove_common() to avoid
> acquiring unreg_sem of the parent.
>
> Fixes: 7b96953bc640 ("vfio: Mediated device Core driver")
> Signed-off-by: Parav Pandit
> ---
> drivers/vfio/mdev/mdev_core.c| 71
> drivers/vfio/mdev/mdev_private.h | 2 +
> 2 files changed, 55 insertions(+), 18 deletions(-)
>
> @@ -265,6 +299,12 @@ int mdev_device_create(struct kobject *kobj,
>
> mdev->parent = parent;
>
Adding
/* Check if parent unregistration has started */
here as well might be nice, but no need to resend the patch for that.
> + if (!down_read_trylock(>unreg_sem)) {
> + mdev_device_free(mdev);
> + ret = -ENODEV;
> + goto mdev_fail;
> + }
> +
> device_initialize(>dev);
> mdev->dev.parent = dev;
> mdev->dev.bus = _bus_type;
Reviewed-by: Cornelia Huck
Re: [RESEND PATCH v3 00/30] Update cros_ec_commands.h
On Mon, 03 Jun 2019, Mark Brown wrote: > On Mon, Jun 03, 2019 at 11:33:31AM -0700, Gwendal Grignou wrote: > > The interface between CrosEC embedded controller and the host, > > described by cros_ec_commands.h, as diverged from what the embedded > > controller really support. > > I'm not clear why I keep getting copied on this series or why it's being > resent? Not sure why you're copied in, but I asked him to resend. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] timers: Fix up get_target_base() to use old base properly
On Mon, Jun 03, 2019 at 09:29:44PM +0800, Peter Xu wrote: > get_target_base() in the timer code is not using the "base" parameter > at all. My gut feeling is that instead of removing that extra > parameter, what we really want to do is "return the old base if it > does not suite for a new one". I'm trying to think of a detailed scenario of this patch: 1. setup a timer T1 with TIMER_PINNED on cpu 3 and arm it 2. on another cpu (e.g., cpu 4), call mod_timer() upon T1 before the timer fires itself 2.1. in __mod_timer(), lock_timer_base() will return cpu 3's timer base because it was pinned with cpu 3 2.2. in the same __mod_timer(), get_target_base() will return cpu 4's timer base if without this patch, and will return cpu 3's timer base if with this patch I don't know whether step 2 is easy to happen but I don't see why it was forbidden so I'm assuming it could still happen... Then IMHO if without this patch, the timer T1 will be queued on cpu 4's timer base rather than cpu 3's, which seems to break TIMER_PINNED. And just in case if this patch makes sense - get_timer_this_cpu_base() can be dropped together since not used any more. -- Peter Xu
Re: [PATCH V4 4/6] dt-bindings: csky: Add csky PMU bindings
Reviewed-by: Guo Ren
On Tue, Jun 4, 2019 at 10:25 AM Mao Han wrote:
>
> This patch adds the documentation to describe that how to add pmu node in
> dts.
>
> Signed-off-by: Mao Han
> Cc: Rob Herring
> Cc: Guo Ren
> ---
> Documentation/devicetree/bindings/csky/pmu.txt | 38
> ++
> 1 file changed, 38 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/csky/pmu.txt
>
> diff --git a/Documentation/devicetree/bindings/csky/pmu.txt
> b/Documentation/devicetree/bindings/csky/pmu.txt
> new file mode 100644
> index 000..53c3b0a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/csky/pmu.txt
> @@ -0,0 +1,38 @@
> +
> +C-SKY Performance Monitor Units
> +
> +
> +C-SKY 8xx series cores often have a PMU for counting cpu and cache events.
> +The C-SKY PMU representation in the device tree should be done as under:
> +
> +==
> +PMU node bindings definition
> +==
> +
> + Description: Describes PMU
> +
> + PROPERTIES
> +
> + - compatible
> + Usage: required
> + Value type:
> + Definition: must be "csky,csky-pmu"
> + - interrupts
> + Usage: required
> + Value type:
> + Definition: must be pmu irq num defined by soc
> + - count-width
> + Usage: optional
> + Value type:
> + Definition: the width of pmu counter
> +
> +Examples:
> +-
> +
> +pmu {
> +compatible = "csky,csky-pmu";
> +interrupts = <0x17 IRQ_TYPE_EDGE_RISING>;
> +interrupt-parent = <>;
> + count-width = <0x30>;
> +};
> +
> --
> 2.7.4
>
[PATCH] perf test 6: Fix missing kvm module load for s390
Command
# perf test -Fv 6
fails with error
running test 100 'kvm-s390:kvm_s390_create_vm' failed to parse
event 'kvm-s390:kvm_s390_create_vm', err -1, str 'unknown tracepoint'
event syntax error: 'kvm-s390:kvm_s390_create_vm'
\___ unknown tracepoint
when the kvm module is not loaded or not built in.
Fix this by adding a valid function which tests if the module
is loaded. Loaded modules (or builtin KVM support) have a
directory named
/sys/kernel/debug/tracing/events/kvm-s390
for this tracepoint.
Check for existence of this directory.
Signed-off-by: Thomas Richter
Reviewed-by: Christian Borntraeger
---
tools/perf/tests/parse-events.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/tools/perf/tests/parse-events.c b/tools/perf/tests/parse-events.c
index 4a69c07f4101..8f3c80e13584 100644
--- a/tools/perf/tests/parse-events.c
+++ b/tools/perf/tests/parse-events.c
@@ -18,6 +18,32 @@
#define PERF_TP_SAMPLE_TYPE (PERF_SAMPLE_RAW | PERF_SAMPLE_TIME | \
PERF_SAMPLE_CPU | PERF_SAMPLE_PERIOD)
+#if defined(__s390x__)
+/* Return true if kvm module is available and loaded. Test this
+ * and retun success when trace point kvm_s390_create_vm
+ * exists. Otherwise this test always fails.
+ */
+static bool kvm_s390_create_vm_valid(void)
+{
+ char *eventfile;
+ bool rc = false;
+
+ eventfile = get_events_file("kvm-s390");
+
+ if (eventfile) {
+ DIR *mydir = opendir(eventfile);
+
+ if (mydir) {
+ rc = true;
+ closedir(mydir);
+ }
+ put_events_file(eventfile);
+ }
+
+ return rc;
+}
+#endif
+
static int test__checkevent_tracepoint(struct perf_evlist *evlist)
{
struct perf_evsel *evsel = perf_evlist__first(evlist);
@@ -1642,6 +1668,7 @@ static struct evlist_test test__events[] = {
{
.name = "kvm-s390:kvm_s390_create_vm",
.check = test__checkevent_tracepoint,
+ .valid = kvm_s390_create_vm_valid,
.id= 100,
},
#endif
--
2.21.0
Re: [PATCH V4 2/6] csky: Add count-width property for csky pmu
Hi Mao,
On Tue, Jun 4, 2019 at 10:25 AM Mao Han wrote:
>
> The csky pmu counter may have different io width. When the counter is
> smaller then 64 bits and counter value is smaller than the old value, it
> will result to a extremely large delta value. So the sampled value should
> be extend to 64 bits to avoid this, the extension bits base on the
> count-width property from dts.
>
> Signed-off-by: Mao Han
> Cc: Guo Ren
> ---
> arch/csky/kernel/perf_event.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/arch/csky/kernel/perf_event.c b/arch/csky/kernel/perf_event.c
> index c022acc..36f7f20 100644
> --- a/arch/csky/kernel/perf_event.c
> +++ b/arch/csky/kernel/perf_event.c
> @@ -9,6 +9,7 @@
> #include
>
> #define CSKY_PMU_MAX_EVENTS 32
> +#define DEFAULT_COUNT_WIDTH 48
>
> #define HPCR "<0, 0x0>" /* PMU Control reg */
> #define HPCNTENR "<0, 0x4>" /* Count Enable reg */
> @@ -18,6 +19,7 @@ static void
> (*hw_raw_write_mapping[CSKY_PMU_MAX_EVENTS])(uint64_t val);
>
> struct csky_pmu_t {
> struct pmu pmu;
> + uint32_tcount_width;
> uint32_thpcr;
> } csky_pmu;
>
> @@ -806,7 +808,12 @@ static void csky_perf_event_update(struct perf_event
> *event,
>struct hw_perf_event *hwc)
> {
> uint64_t prev_raw_count = local64_read(>prev_count);
> - uint64_t new_raw_count = hw_raw_read_mapping[hwc->idx]();
> + /*
> +* Sign extend count value to 64bit, otherwise delta calculation
> +* would be incorrect when overflow occurs.
> +*/
> + uint64_t new_raw_count = sign_extend64(
> + hw_raw_read_mapping[hwc->idx](),
> csky_pmu.count_width);
csky_pmu.count_width - 1 ? we need index here.
Best Regards
Guo Ren
Re: [PATCH] driver core: show the error number when driver_sysfs_add() fails
On Tue, Jun 04, 2019 at 12:15:46PM +0800, Kefeng Wang wrote:
> If driver_sysfs_add() fails, kernel shows following message,
>
> really_probe: driver_sysfs_add(portman.0) failed
> ppdev: probe of portman.0 failed with error 0
>
> It's better to show the error number like other probe_failed path.
>
> Signed-off-by: Kefeng Wang
> ---
> drivers/base/dd.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 0df9b4461766..04ee4e196530 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -493,7 +493,8 @@ static int really_probe(struct device *dev, struct
> device_driver *drv)
> goto probe_failed;
> }
>
> - if (driver_sysfs_add(dev)) {
> + ret = driver_sysfs_add(dev);
> + if (ret) {
> printk(KERN_ERR "%s: driver_sysfs_add(%s) failed\n",
> __func__, dev_name(dev));
Shouldn't this be where the error number is shown? No need for all
callers to also show the same thing.
thanks,
greg k-h
Re: [PATCH 1/2] Input: synaptics-rmi4 - clear irqs before set irqs
On Tue, 2019-06-04 at 10:45 +0800, Aaron Ma wrote: > Hi Christopher: > > Have got time to review these 2 patches? > Users reported it works fine since I sent out this patch. Hi Aaron, I've been poking around with this off and on. Unfortunately, more off than on :-( but here's my current take: rmi_driver_set_irq_bits() isn't going to be called all that often, and it's not going to be called at all during normal operation, which is where the most serious problem would occur. I haven't entirely convinced myself that there couldn't be a problem during repeated spontaneous device resets (for example, due to ESD, a dodgy charger, or firmware bug, among other things). On the other hand, all the scenarios I have come up with are both unlikely and so contrived that the system is probably hosed regardless of what we do in the driver. Given that, I'm willing to accept the patch as is. Cheers, Chris > > Thanks, > Aaron > > On 4/3/19 9:58 PM, Aaron Ma wrote: > > Sure, take your time, if you have any questions let me know please. > > > > Thanks, > > Aaron
general protection fault in fib6_nh_init
Hello, syzbot found the following crash on: HEAD commit:c1e9e01d Merge git://git.kernel.org/pub/scm/linux/kernel/g.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=1319e05aa0 kernel config: https://syzkaller.appspot.com/x/.config?x=b7b54c66298f8420 dashboard link: https://syzkaller.appspot.com/bug?extid=1b2927fda48c5bf2e931 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+1b2927fda48c5bf2e...@syzkaller.appspotmail.com general protection fault: [#1] PREEMPT SMP KASAN CPU: 0 PID: 4498 Comm: syz-executor.4 Not tainted 5.2.0-rc2+ #10 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:ipv6_addr_any include/net/ipv6.h:626 [inline] RIP: 0010:ip6_route_check_nh_onlink net/ipv6/route.c:2910 [inline] RIP: 0010:ip6_validate_gw net/ipv6/route.c:3013 [inline] RIP: 0010:fib6_nh_init+0x47e/0x1c80 net/ipv6/route.c:3121 Code: 89 de e8 45 9f 4e fb 48 85 db 0f 84 fb 10 00 00 e8 97 9d 4e fb 48 8d 7b 40 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 bf 16 00 00 48 8d 7b 48 48 8b 4b 40 48 b8 00 00 RSP: 0018:888060e277c0 EFLAGS: 00010a02 RAX: dc00 RBX: ff8880a43d5cc000 RCX: c90012a9f000 RDX: 1ff1101487ab9808 RSI: 86220829 RDI: ff8880a43d5cc040 RBP: 888060e27840 R08: 8880659d2400 R09: ed1015d06be8 R10: ed1015d06be7 R11: 8880ae835f3b R12: 88809d123d3f R13: 888060e279b0 R14: 888085b9f6d8 R15: 888060e279c4 FS: 7f350a07c700() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 00606ed8 CR3: 92f12000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: ip6_route_info_create+0x922/0x1240 net/ipv6/route.c:3313 ip6_route_add+0x27/0xc0 net/ipv6/route.c:3349 ipv6_route_ioctl+0x2b9/0x360 net/ipv6/route.c:3875 inet6_ioctl+0x17c/0x1c0 net/ipv6/af_inet6.c:553 sock_do_ioctl+0xd8/0x2f0 net/socket.c:1049 sock_ioctl+0x3ed/0x780 net/socket.c:1200 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0xd5f/0x1380 fs/ioctl.c:696 ksys_ioctl+0xab/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x459279 Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f350a07bc78 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 0003 RCX: 00459279 RDX: 2000 RSI: 890b RDI: 0003 RBP: 0075bf20 R08: R09: R10: R11: 0246 R12: 7f350a07c6d4 R13: 004c4e0b R14: 004d8b50 R15: Modules linked in: ---[ end trace 72dad8f57a5b777a ]--- RIP: 0010:ipv6_addr_any include/net/ipv6.h:626 [inline] RIP: 0010:ip6_route_check_nh_onlink net/ipv6/route.c:2910 [inline] RIP: 0010:ip6_validate_gw net/ipv6/route.c:3013 [inline] RIP: 0010:fib6_nh_init+0x47e/0x1c80 net/ipv6/route.c:3121 Code: 89 de e8 45 9f 4e fb 48 85 db 0f 84 fb 10 00 00 e8 97 9d 4e fb 48 8d 7b 40 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 bf 16 00 00 48 8d 7b 48 48 8b 4b 40 48 b8 00 00 RSP: 0018:888060e277c0 EFLAGS: 00010a02 RAX: dc00 RBX: ff8880a43d5cc000 RCX: c90012a9f000 RDX: 1ff1101487ab9808 RSI: 86220829 RDI: ff8880a43d5cc040 RBP: 888060e27840 R08: 8880659d2400 R09: ed1015d06be8 R10: ed1015d06be7 R11: 8880ae835f3b R12: 88809d123d3f R13: 888060e279b0 R14: 888085b9f6d8 R15: 888060e279c4 FS: 7f350a07c700() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 00625208 CR3: 92f12000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
KASAN: slab-out-of-bounds Read in rt_cache_valid
Hello, syzbot found the following crash on: HEAD commit:9221dced Merge tag 'for-linus-20190601' of git://git.kerne.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=114cdc0ea0 kernel config: https://syzkaller.appspot.com/x/.config?x=1fa7e451a5cac069 dashboard link: https://syzkaller.appspot.com/bug?extid=a9e23ea2aa21044c2798 compiler: gcc (GCC) 9.0.0 20181231 (experimental) userspace arch: i386 Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+a9e23ea2aa21044c2...@syzkaller.appspotmail.com == BUG: KASAN: slab-out-of-bounds in rt_cache_valid+0x158/0x190 net/ipv4/route.c:1556 Read of size 2 at addr 8880654f3ac7 by task syz-executor.0/26603 CPU: 0 PID: 26603 Comm: syz-executor.0 Not tainted 5.2.0-rc2+ #9 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 print_address_description.cold+0x7c/0x20d mm/kasan/report.c:188 __kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317 kasan_report+0x12/0x20 mm/kasan/common.c:614 __asan_report_load2_noabort+0x14/0x20 mm/kasan/generic_report.c:130 rt_cache_valid+0x158/0x190 net/ipv4/route.c:1556 __mkroute_output net/ipv4/route.c:2332 [inline] ip_route_output_key_hash_rcu+0x819/0x2d50 net/ipv4/route.c:2564 ip_route_output_key_hash+0x1ef/0x360 net/ipv4/route.c:2393 __ip_route_output_key include/net/route.h:125 [inline] ip_route_output_flow+0x28/0xc0 net/ipv4/route.c:2651 ip_route_output_key include/net/route.h:135 [inline] sctp_v4_get_dst+0x467/0x1260 net/sctp/protocol.c:435 sctp_transport_route+0x12d/0x360 net/sctp/transport.c:297 sctp_assoc_add_peer+0x53e/0xfc0 net/sctp/associola.c:663 sctp_process_param net/sctp/sm_make_chunk.c:2531 [inline] sctp_process_init+0x2491/0x2b10 net/sctp/sm_make_chunk.c:2344 sctp_cmd_process_init net/sctp/sm_sideeffect.c:667 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1369 [inline] sctp_side_effects net/sctp/sm_sideeffect.c:1179 [inline] sctp_do_sm+0x3a30/0x50e0 net/sctp/sm_sideeffect.c:1150 sctp_assoc_bh_rcv+0x343/0x660 net/sctp/associola.c:1059 sctp_inq_push+0x1e4/0x280 net/sctp/inqueue.c:80 sctp_backlog_rcv+0x196/0xbe0 net/sctp/input.c:339 sk_backlog_rcv include/net/sock.h:945 [inline] __release_sock+0x129/0x390 net/core/sock.c:2412 release_sock+0x59/0x1c0 net/core/sock.c:2928 sctp_wait_for_connect+0x316/0x540 net/sctp/socket.c:9039 __sctp_connect+0xab2/0xcd0 net/sctp/socket.c:1226 __sctp_setsockopt_connectx+0x133/0x1a0 net/sctp/socket.c:1334 sctp_setsockopt_connectx_old net/sctp/socket.c:1350 [inline] sctp_setsockopt net/sctp/socket.c:4644 [inline] sctp_setsockopt+0x22c0/0x6d10 net/sctp/socket.c:4608 compat_sock_common_setsockopt+0x106/0x140 net/core/sock.c:3137 __compat_sys_setsockopt+0x185/0x380 net/compat.c:383 __do_compat_sys_setsockopt net/compat.c:396 [inline] __se_compat_sys_setsockopt net/compat.c:393 [inline] __ia32_compat_sys_setsockopt+0xbd/0x150 net/compat.c:393 do_syscall_32_irqs_on arch/x86/entry/common.c:337 [inline] do_fast_syscall_32+0x27b/0xd7d arch/x86/entry/common.c:408 entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139 RIP: 0023:0xf7ff5849 Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 14 24 c3 8b 3c 24 c3 90 90 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 002b:f5df10cc EFLAGS: 0296 ORIG_RAX: 016e RAX: ffda RBX: 0007 RCX: 0084 RDX: 006b RSI: 2055bfe4 RDI: 001c RBP: R08: R09: R10: R11: R12: R13: R14: R15: Allocated by task 480: save_stack+0x23/0x90 mm/kasan/common.c:71 set_track mm/kasan/common.c:79 [inline] __kasan_kmalloc mm/kasan/common.c:489 [inline] __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:462 kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:497 slab_post_alloc_hook mm/slab.h:437 [inline] slab_alloc mm/slab.c:3326 [inline] kmem_cache_alloc+0x11a/0x6f0 mm/slab.c:3488 dst_alloc+0x10e/0x200 net/core/dst.c:93 rt_dst_alloc+0x83/0x3f0 net/ipv4/route.c:1624 __mkroute_output net/ipv4/route.c:2337 [inline] ip_route_output_key_hash_rcu+0x8f3/0x2d50 net/ipv4/route.c:2564 ip_route_output_key_hash+0x1ef/0x360 net/ipv4/route.c:2393 __ip_route_output_key include/net/route.h:125 [inline] ip_route_output_flow+0x28/0xc0 net/ipv4/route.c:2651 ip_route_output_key include/net/route.h:135 [inline] sctp_v4_get_dst+0x467/0x1260 net/sctp/protocol.c:435 sctp_transport_route+0x12d/0x360 net/sctp/transport.c:297 sctp_assoc_add_peer+0x53e/0xfc0
KASAN: slab-out-of-bounds Read in fib6_purge_rt (2)
Hello, syzbot found the following crash on: HEAD commit:b33bc2b8 nexthop: Add entry to MAINTAINERS git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=1383c9baa0 kernel config: https://syzkaller.appspot.com/x/.config?x=1004db091673bbaf dashboard link: https://syzkaller.appspot.com/bug?extid=f4812f31edd866494c9f compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+f4812f31edd866494...@syzkaller.appspotmail.com == BUG: KASAN: slab-out-of-bounds in __read_once_size include/linux/compiler.h:194 [inline] BUG: KASAN: slab-out-of-bounds in __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:899 [inline] BUG: KASAN: slab-out-of-bounds in fib6_drop_pcpu_from net/ipv6/ip6_fib.c:920 [inline] BUG: KASAN: slab-out-of-bounds in fib6_purge_rt+0x5bf/0x630 net/ipv6/ip6_fib.c:928 Read of size 8 at addr 88809906c2b6 by task kworker/u4:6/8858 CPU: 1 PID: 8858 Comm: kworker/u4:6 Not tainted 5.2.0-rc2+ #13 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 print_address_description.cold+0x7c/0x20d mm/kasan/report.c:188 __kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317 kasan_report+0x12/0x20 mm/kasan/common.c:614 __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132 __read_once_size include/linux/compiler.h:194 [inline] __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:899 [inline] fib6_drop_pcpu_from net/ipv6/ip6_fib.c:920 [inline] fib6_purge_rt+0x5bf/0x630 net/ipv6/ip6_fib.c:928 fib6_del_route net/ipv6/ip6_fib.c:1811 [inline] fib6_del+0x9bd/0xeb0 net/ipv6/ip6_fib.c:1842 fib6_clean_node+0x3a5/0x590 net/ipv6/ip6_fib.c:2004 fib6_walk_continue+0x4a9/0x8e0 net/ipv6/ip6_fib.c:1926 fib6_walk+0x9d/0x100 net/ipv6/ip6_fib.c:1974 fib6_clean_tree+0xe0/0x120 net/ipv6/ip6_fib.c:2053 __fib6_clean_all+0x118/0x2a0 net/ipv6/ip6_fib.c:2069 fib6_clean_all+0x2b/0x40 net/ipv6/ip6_fib.c:2080 rt6_sync_down_dev+0x134/0x150 net/ipv6/route.c:4285 rt6_disable_ip+0x27/0x5f0 net/ipv6/route.c:4290 addrconf_ifdown+0xa2/0x1220 net/ipv6/addrconf.c:3707 addrconf_notify+0x5db/0x2370 net/ipv6/addrconf.c:3632 notifier_call_chain+0xc2/0x230 kernel/notifier.c:95 __raw_notifier_call_chain kernel/notifier.c:396 [inline] raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:403 call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1753 call_netdevice_notifiers_extack net/core/dev.c:1765 [inline] call_netdevice_notifiers net/core/dev.c:1779 [inline] dev_close_many+0x33f/0x6f0 net/core/dev.c:1522 rollback_registered_many+0x43b/0xfc0 net/core/dev.c:8159 unregister_netdevice_many.part.0+0x1b/0x1f0 net/core/dev.c:9290 unregister_netdevice_many+0x3b/0x50 net/core/dev.c:9289 sit_exit_batch_net+0x560/0x750 net/ipv6/sit.c:1895 ops_exit_list.isra.0+0xfc/0x150 net/core/net_namespace.c:157 cleanup_net+0x3fb/0x960 net/core/net_namespace.c:553 process_one_work+0x989/0x1790 kernel/workqueue.c:2269 worker_thread+0x98/0xe40 kernel/workqueue.c:2415 kthread+0x354/0x420 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Allocated by task 11059: save_stack+0x23/0x90 mm/kasan/common.c:71 set_track mm/kasan/common.c:79 [inline] __kasan_kmalloc mm/kasan/common.c:489 [inline] __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:462 kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:497 slab_post_alloc_hook mm/slab.h:437 [inline] slab_alloc mm/slab.c:3326 [inline] kmem_cache_alloc+0x11a/0x6f0 mm/slab.c:3488 dst_alloc+0x10e/0x200 net/core/dst.c:93 ip6_dst_alloc+0x34/0xa0 net/ipv6/route.c:356 ip6_rt_pcpu_alloc net/ipv6/route.c:1257 [inline] rt6_make_pcpu_route net/ipv6/route.c:1287 [inline] ip6_pol_route+0x649/0x1010 net/ipv6/route.c:2031 ip6_pol_route_output+0x54/0x70 net/ipv6/route.c:2204 fib6_rule_lookup+0x133/0x5a0 net/ipv6/fib6_rules.c:116 ip6_route_output_flags+0x2c4/0x350 net/ipv6/route.c:2233 ip6_route_output include/net/ip6_route.h:89 [inline] ip6_dst_lookup_tail+0xd10/0x1b30 net/ipv6/ip6_output.c:1027 ip6_dst_lookup_flow+0xa8/0x220 net/ipv6/ip6_output.c:1155 sctp_v6_get_dst+0x785/0x1d80 net/sctp/ipv6.c:278 sctp_transport_route+0x12d/0x360 net/sctp/transport.c:297 sctp_assoc_add_peer+0x53e/0xfc0 net/sctp/associola.c:663 sctp_process_param net/sctp/sm_make_chunk.c:2531 [inline] sctp_process_init+0x2491/0x2b10 net/sctp/sm_make_chunk.c:2344 sctp_sf_do_5_1D_ce+0x458/0x1390 net/sctp/sm_statefuns.c:767 sctp_do_sm+0x121/0x50e0 net/sctp/sm_sideeffect.c:1147 sctp_endpoint_bh_rcv+0x451/0x950 net/sctp/endpointola.c:443 sctp_inq_push+0x1e4/0x280 net/sctp/inqueue.c:80 sctp_rcv+0x2807/0x35c0 net/sctp/input.c:256 sctp6_rcv+0x17/0x30 net/sctp/ipv6.c:1049
KASAN: user-memory-access Write in fib6_purge_rt (2)
Hello, syzbot found the following crash on: HEAD commit:58e8b370 Merge branch 'net-phy-dp83867-add-some-fixes' git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=17bb8b9aa0 kernel config: https://syzkaller.appspot.com/x/.config?x=fc045131472947d7 dashboard link: https://syzkaller.appspot.com/bug?extid=420d3f70afb5d69d5a96 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+420d3f70afb5d69d5...@syzkaller.appspotmail.com == BUG: KASAN: user-memory-access in fib6_drop_pcpu_from net/ipv6/ip6_fib.c:925 [inline] BUG: KASAN: user-memory-access in fib6_purge_rt+0x1b3/0x5e0 net/ipv6/ip6_fib.c:937 Write of size 8 at addr ebb4 by task syz-executor.3/14149 CPU: 0 PID: 14149 Comm: syz-executor.3 Not tainted 5.2.0-rc1+ #33 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 __kasan_report.cold+0x5/0x40 mm/kasan/report.c:321 kasan_report+0x12/0x20 mm/kasan/common.c:614 check_memory_region_inline mm/kasan/generic.c:185 [inline] check_memory_region+0x123/0x190 mm/kasan/generic.c:191 kasan_check_write+0x14/0x20 mm/kasan/common.c:100 fib6_drop_pcpu_from net/ipv6/ip6_fib.c:925 [inline] fib6_purge_rt+0x1b3/0x5e0 net/ipv6/ip6_fib.c:937 fib6_del_route net/ipv6/ip6_fib.c:1812 [inline] fib6_del+0xac2/0x10a0 net/ipv6/ip6_fib.c:1843 fib6_clean_node+0x3a5/0x590 net/ipv6/ip6_fib.c:2005 fib6_walk_continue+0x4a9/0x8e0 net/ipv6/ip6_fib.c:1927 fib6_walk+0x9d/0x100 net/ipv6/ip6_fib.c:1975 fib6_clean_tree+0xe0/0x120 net/ipv6/ip6_fib.c:2054 __fib6_clean_all+0x118/0x2a0 net/ipv6/ip6_fib.c:2070 fib6_clean_all+0x2b/0x40 net/ipv6/ip6_fib.c:2081 rt6_sync_down_dev+0x134/0x150 net/ipv6/route.c:4169 rt6_disable_ip+0x27/0x5f0 net/ipv6/route.c:4174 addrconf_ifdown+0xa2/0x1220 net/ipv6/addrconf.c:3709 addrconf_notify+0x5db/0x2270 net/ipv6/addrconf.c:3634 notifier_call_chain+0xc2/0x230 kernel/notifier.c:95 __raw_notifier_call_chain kernel/notifier.c:396 [inline] raw_notifier_call_chain+0x2e/0x40 kernel/notifier.c:403 call_netdevice_notifiers_info+0x3f/0x90 net/core/dev.c:1753 call_netdevice_notifiers_extack net/core/dev.c:1765 [inline] call_netdevice_notifiers net/core/dev.c:1779 [inline] __dev_notify_flags+0x1e9/0x2c0 net/core/dev.c:7628 dev_change_flags+0x10d/0x170 net/core/dev.c:7664 devinet_ioctl+0x138a/0x1c50 net/ipv4/devinet.c:1104 inet_ioctl+0x1f4/0x340 net/ipv4/af_inet.c:952 sock_do_ioctl+0xd8/0x2f0 net/socket.c:1049 sock_ioctl+0x3ed/0x780 net/socket.c:1200 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0xd5f/0x1380 fs/ioctl.c:696 ksys_ioctl+0xab/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0xfd/0x680 arch/x86/entry/common.c:301 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x459279 Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f79b318dc78 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 0003 RCX: 00459279 RDX: 2080 RSI: 8914 RDI: 0003 RBP: 0075bf20 R08: R09: R10: R11: 0246 R12: 7f79b318e6d4 R13: 004c4c76 R14: 004d89b8 R15: == --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
KASAN: slab-out-of-bounds Read in icmpv6_xrlim_allow
Hello, syzbot found the following crash on: HEAD commit:0462eaac Merge git://git.kernel.org/pub/scm/linux/kernel/g.. git tree: bpf-next console output: https://syzkaller.appspot.com/x/log.txt?x=12c82772a0 kernel config: https://syzkaller.appspot.com/x/.config?x=b7b54c66298f8420 dashboard link: https://syzkaller.appspot.com/bug?extid=14536436e78408172703 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+14536436e78408172...@syzkaller.appspotmail.com == BUG: KASAN: slab-out-of-bounds in icmpv6_xrlim_allow+0x409/0x440 net/ipv6/icmp.c:216 Read of size 8 at addr 8880973ed8bf by task swapper/1/0 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.2.0-rc2+ #12 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 print_address_description.cold+0x7c/0x20d mm/kasan/report.c:188 __kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317 kasan_report+0x12/0x20 mm/kasan/common.c:614 __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132 icmpv6_xrlim_allow+0x409/0x440 net/ipv6/icmp.c:216 icmp6_send+0x1107/0x1e50 net/ipv6/icmp.c:540 icmpv6_send+0xec/0x230 net/ipv6/ip6_icmp.c:43 ip6_link_failure+0x2b/0x530 net/ipv6/route.c:2367 dst_link_failure include/net/dst.h:416 [inline] ndisc_error_report+0xce/0x1c0 net/ipv6/ndisc.c:712 neigh_invalidate+0x245/0x570 net/core/neighbour.c:1000 neigh_timer_handler+0xc33/0xf30 net/core/neighbour.c:1086 call_timer_fn+0x193/0x720 kernel/time/timer.c:1322 expire_timers kernel/time/timer.c:1366 [inline] __run_timers kernel/time/timer.c:1685 [inline] __run_timers kernel/time/timer.c:1653 [inline] run_timer_softirq+0x66f/0x1740 kernel/time/timer.c:1698 __do_softirq+0x25c/0x94c kernel/softirq.c:293 invoke_softirq kernel/softirq.c:374 [inline] irq_exit+0x180/0x1d0 kernel/softirq.c:414 exiting_irq arch/x86/include/asm/apic.h:536 [inline] smp_apic_timer_interrupt+0x13b/0x550 arch/x86/kernel/apic/apic.c:1068 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:806 RIP: 0010:__raw_spin_unlock_irq include/linux/spinlock_api_smp.h:169 [inline] RIP: 0010:_raw_spin_unlock_irq+0x54/0x90 kernel/locking/spinlock.c:199 Code: c0 00 74 b2 88 48 ba 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 33 48 83 3d 85 ee 94 01 00 74 20 fb 66 0f 1f 44 00 00 01 00 00 00 e8 52 f5 2f fa 65 8b 05 f3 77 e4 78 85 c0 74 06 41 RSP: 0018:8880a98e7c88 EFLAGS: 0286 ORIG_RAX: ff13 RAX: 11164e80 RBX: 8880a98d4340 RCX: RDX: dc00 RSI: 0006 RDI: 8880a98d4bbc RBP: 8880a98e7c90 R08: 8880a98d4340 R09: R10: R11: R12: 8880ae935080 R13: 888096ef0640 R14: R15: 0001 finish_lock_switch kernel/sched/core.c:2568 [inline] finish_task_switch+0x146/0x730 kernel/sched/core.c:2668 context_switch kernel/sched/core.c:2821 [inline] __schedule+0x7d3/0x1560 kernel/sched/core.c:3445 schedule_idle+0x58/0x80 kernel/sched/core.c:3537 do_idle+0x192/0x560 kernel/sched/idle.c:287 cpu_startup_entry+0x1b/0x20 kernel/sched/idle.c:354 start_secondary+0x34e/0x4c0 arch/x86/kernel/smpboot.c:265 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243 Allocated by task 0: save_stack+0x23/0x90 mm/kasan/common.c:71 set_track mm/kasan/common.c:79 [inline] __kasan_kmalloc mm/kasan/common.c:489 [inline] __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:462 kasan_slab_alloc+0xf/0x20 mm/kasan/common.c:497 slab_post_alloc_hook mm/slab.h:437 [inline] slab_alloc mm/slab.c:3326 [inline] kmem_cache_alloc+0x11a/0x6f0 mm/slab.c:3488 dst_alloc+0x10e/0x200 net/core/dst.c:93 ip6_dst_alloc+0x34/0xa0 net/ipv6/route.c:356 icmp6_dst_alloc+0x1a9/0x660 net/ipv6/route.c:2806 ndisc_send_skb+0xfc1/0x14a0 net/ipv6/ndisc.c:488 ndisc_send_rs+0x134/0x6d0 net/ipv6/ndisc.c:702 addrconf_rs_timer+0x30f/0x680 net/ipv6/addrconf.c:3880 call_timer_fn+0x193/0x720 kernel/time/timer.c:1322 expire_timers kernel/time/timer.c:1366 [inline] __run_timers kernel/time/timer.c:1685 [inline] __run_timers kernel/time/timer.c:1653 [inline] run_timer_softirq+0x66f/0x1740 kernel/time/timer.c:1698 __do_softirq+0x25c/0x94c kernel/softirq.c:293 Freed by task 0: save_stack+0x23/0x90 mm/kasan/common.c:71 set_track mm/kasan/common.c:79 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/common.c:451 kasan_slab_free+0xe/0x10 mm/kasan/common.c:459 __cache_free mm/slab.c:3432 [inline] kmem_cache_free+0x86/0x260 mm/slab.c:3698 dst_destroy+0x29e/0x3c0 net/core/dst.c:129 dst_destroy_rcu+0x16/0x19 net/core/dst.c:142 __rcu_reclaim kernel/rcu/rcu.h:222 [inline] rcu_do_batch
Re: [PATCH v1 3/4] mm: account nr_isolated_xxx in [isolate|putback]_lru_page
Hi Hillf,
On Tue, Jun 04, 2019 at 12:20:47PM +0800, Hillf Danton wrote:
>
> Hi Minchan
>
> On Mon, 3 Jun 2019 13:37:27 +0800 Minchan Kim wrote:
> > @@ -1181,10 +1179,17 @@ static ICE_noinline int unmap_and_move(new_page_t
> > get_new_page,
> > return -ENOMEM;
> >
> > if (page_count(page) == 1) {
> > + bool is_lru = !__PageMovable(page);
> > +
> > /* page was freed from under us. So we are done. */
> > ClearPageActive(page);
> > ClearPageUnevictable(page);
> > - if (unlikely(__PageMovable(page))) {
> > + if (likely(is_lru))
> > + mod_node_page_state(page_pgdat(page),
> > + NR_ISOLATED_ANON +
> > + page_is_file_cache(page),
> > + hpage_nr_pages(page));
That should be -hpage_nr_pages(page). It's a bug.
> > + else {
> > lock_page(page);
> > if (!PageMovable(page))
> > __ClearPageIsolated(page);
>
> As this page will go down the path only through the MIGRATEPAGE_SUCCESS
> branches,
> with no putback ahead, the current code is, I think, doing right things for
> this
> work to keep isolated stat balanced.
I guess that's the one you pointed out. Right?
Thanks for the review!
>
> > @@ -1210,15 +1215,6 @@ static ICE_noinline int unmap_and_move(new_page_t
> > get_new_page,
> > * restored.
> > */
> > list_del(>lru);
> > -
> > - /*
> > -* Compaction can migrate also non-LRU pages which are
> > -* not accounted to NR_ISOLATED_*. They can be recognized
> > -* as __PageMovable
> > -*/
> > - if (likely(!__PageMovable(page)))
> > - mod_node_page_state(page_pgdat(page), NR_ISOLATED_ANON +
> > - page_is_file_cache(page),
> > -hpage_nr_pages(page));
> > }
> >
>
> BR
> Hillf
>
Re: [PATCH v8 09/12] mm/sparsemem: Support sub-section hotplug
On Mon, May 13, 2019 at 6:55 AM Oscar Salvador wrote:
>
> On Mon, May 06, 2019 at 04:40:14PM -0700, Dan Williams wrote:
> >
> > +void subsection_mask_set(unsigned long *map, unsigned long pfn,
> > + unsigned long nr_pages)
> > +{
> > + int idx = subsection_map_index(pfn);
> > + int end = subsection_map_index(pfn + nr_pages - 1);
> > +
> > + bitmap_set(map, idx, end - idx + 1);
> > +}
> > +
> > void subsection_map_init(unsigned long pfn, unsigned long nr_pages)
> > {
> > int end_sec = pfn_to_section_nr(pfn + nr_pages - 1);
> > @@ -219,20 +235,17 @@ void subsection_map_init(unsigned long pfn, unsigned
> > long nr_pages)
> > return;
> >
> > for (i = start_sec; i <= end_sec; i++) {
> > - int idx, end;
> > - unsigned long pfns;
> > struct mem_section *ms;
> > + unsigned long pfns;
> >
> > - idx = subsection_map_index(pfn);
> > pfns = min(nr_pages, PAGES_PER_SECTION
> > - (pfn & ~PAGE_SECTION_MASK));
> > - end = subsection_map_index(pfn + pfns - 1);
> > -
> > ms = __nr_to_section(i);
> > - bitmap_set(ms->usage->subsection_map, idx, end - idx + 1);
> > + subsection_mask_set(ms->usage->subsection_map, pfn, pfns);
> >
> > pr_debug("%s: sec: %d pfns: %ld set(%d, %d)\n", __func__, i,
> > - pfns, idx, end - idx + 1);
> > + pfns, subsection_map_index(pfn),
> > + subsection_map_index(pfn + pfns - 1));
>
> I would definetely add subsection_mask_set() and above change to Patch#3.
> I think it suits there better than here.
Yes, done.
>
> >
> > pfn += pfns;
> > nr_pages -= pfns;
> > @@ -319,6 +332,15 @@ static void __meminit sparse_init_one_section(struct
> > mem_section *ms,
> > unsigned long pnum, struct page *mem_map,
> > struct mem_section_usage *usage)
> > {
> > + /*
> > + * Given that SPARSEMEM_VMEMMAP=y supports sub-section hotplug,
> > + * ->section_mem_map can not be guaranteed to point to a full
> > + * section's worth of memory. The field is only valid / used
> > + * in the SPARSEMEM_VMEMMAP=n case.
> > + */
> > + if (IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP))
> > + mem_map = NULL;
> > +
> > ms->section_mem_map &= ~SECTION_MAP_MASK;
> > ms->section_mem_map |= sparse_encode_mem_map(mem_map, pnum) |
> > SECTION_HAS_MEM_MAP;
> > @@ -724,10 +746,142 @@ static void free_map_bootmem(struct page *memmap)
> > #endif /* CONFIG_MEMORY_HOTREMOVE */
> > #endif /* CONFIG_SPARSEMEM_VMEMMAP */
> >
> > +#ifndef CONFIG_MEMORY_HOTREMOVE
> > +static void free_map_bootmem(struct page *memmap)
> > +{
> > +}
> > +#endif
> > +
> > +static bool is_early_section(struct mem_section *ms)
> > +{
> > + struct page *usage_page;
> > +
> > + usage_page = virt_to_page(ms->usage);
> > + if (PageSlab(usage_page) || PageCompound(usage_page))
> > + return false;
> > + else
> > + return true;
> > +}
> > +
> > +static void section_deactivate(unsigned long pfn, unsigned long nr_pages,
> > + int nid, struct vmem_altmap *altmap)
> > +{
> > + DECLARE_BITMAP(map, SUBSECTIONS_PER_SECTION) = { 0 };
> > + DECLARE_BITMAP(tmp, SUBSECTIONS_PER_SECTION) = { 0 };
> > + struct mem_section *ms = __pfn_to_section(pfn);
> > + bool early_section = is_early_section(ms);
> > + struct page *memmap = NULL;
> > + unsigned long *subsection_map = ms->usage
> > + ? >usage->subsection_map[0] : NULL;
> > +
> > + subsection_mask_set(map, pfn, nr_pages);
> > + if (subsection_map)
> > + bitmap_and(tmp, map, subsection_map, SUBSECTIONS_PER_SECTION);
> > +
> > + if (WARN(!subsection_map || !bitmap_equal(tmp, map,
> > SUBSECTIONS_PER_SECTION),
> > + "section already deactivated (%#lx + %ld)\n",
> > + pfn, nr_pages))
> > + return;
> > +
> > + if (WARN(!IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP)
> > + && nr_pages < PAGES_PER_SECTION,
> > + "partial memory section removal not
> > supported\n"))
> > + return;
> > +
> > + /*
> > + * There are 3 cases to handle across two configurations
> > + * (SPARSEMEM_VMEMMAP={y,n}):
> > + *
> > + * 1/ deactivation of a partial hot-added section (only possible
> > + * in the SPARSEMEM_VMEMMAP=y case).
> > + *a/ section was present at memory init
> > + *b/ section was hot-added post memory init
> > + * 2/ deactivation of a complete hot-added section
> > + * 3/ deactivation of a complete section from memory init
> > + *
> > + * For 1/, when subsection_map does not empty we
Re: [PATCH v1] KVM: x86: PMU Whitelist
On 06/04/2019 01:30 AM, Eric Hankland wrote: On Sat, Jun 1, 2019 at 3:50 AM Wei Wang wrote: My question is that have we proved that this indirect info leakage indeed happens? The spec states that the counter will count the related events generated by the logical CPU with AnyThread=0. I would be inclined to trust the hardware behavior documented in the spec unless we could prove there is a problem. I'm not disputing the spec with regards to AnyThread=0; my point is that LLC contention can be quantified using the PMU regardless of whether or not you are measuring only the logical CPU you are running on. So, I'm not sure if "quantifying LLC contention" has been proved to be a real issue. If this is considered to be an issue: - without PMU, we could also write a piece of software to run in the guest to quantify that contention (e.g. by analyzing the memory access latency). How do you prevent this? - the same thing could also happen with the L1 cache (e.g. a vCPU and a host thread run 2 logical CPUs on the same core). If this is disabled as well, we may have very few events usable, and would like to see what you have on the whitelist. Best, Wei
[PATCH v2] perf ioctl: Add check for the sample_period value
perf_event_open() limits the sample_period to 63 bits. See
commit 0819b2e30ccb ("perf: Limit perf_event_attr::sample_period
to 63 bits"). Make ioctl() consistent with it.
Also on powerpc, negative sample_period could cause a recursive
PMIs leading to a hang (reported when running perf-fuzzer).
Signed-off-by: Ravi Bangoria
---
kernel/events/core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index abbd4b3b96c2..e44c90378940 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5005,6 +5005,9 @@ static int perf_event_period(struct perf_event *event,
u64 __user *arg)
if (perf_event_check_period(event, value))
return -EINVAL;
+ if (!event->attr.freq && (value & (1ULL << 63)))
+ return -EINVAL;
+
event_function_call(event, __perf_event_period, );
return 0;
--
2.20.1
Re: [RFCv2 1/6] mm: introduce MADV_COLD
On Mon, Jun 03, 2019 at 09:16:07AM +0200, Michal Hocko wrote: > On Fri 31-05-19 23:34:07, Minchan Kim wrote: > > On Fri, May 31, 2019 at 04:03:32PM +0200, Michal Hocko wrote: > > > On Fri 31-05-19 22:39:04, Minchan Kim wrote: > > > > On Fri, May 31, 2019 at 10:47:52AM +0200, Michal Hocko wrote: > > > > > On Fri 31-05-19 15:43:08, Minchan Kim wrote: > > > > > > When a process expects no accesses to a certain memory range, it > > > > > > could > > > > > > give a hint to kernel that the pages can be reclaimed when memory > > > > > > pressure > > > > > > happens but data should be preserved for future use. This could > > > > > > reduce > > > > > > workingset eviction so it ends up increasing performance. > > > > > > > > > > > > This patch introduces the new MADV_COLD hint to madvise(2) syscall. > > > > > > MADV_COLD can be used by a process to mark a memory range as not > > > > > > expected > > > > > > to be used in the near future. The hint can help kernel in deciding > > > > > > which > > > > > > pages to evict early during memory pressure. > > > > > > > > > > > > Internally, it works via deactivating pages from active list to > > > > > > inactive's > > > > > > head if the page is private because inactive list could be full of > > > > > > used-once pages which are first candidate for the reclaiming and > > > > > > that's a > > > > > > reason why MADV_FREE move pages to head of inactive LRU list. > > > > > > Therefore, > > > > > > if the memory pressure happens, they will be reclaimed earlier than > > > > > > other > > > > > > active pages unless there is no access until the time. > > > > > > > > > > [I am intentionally not looking at the implementation because below > > > > > points should be clear from the changelog - sorry about nagging ;)] > > > > > > > > > > What kind of pages can be deactivated? Anonymous/File backed. > > > > > Private/shared? If shared, are there any restrictions? > > > > > > > > Both file and private pages could be deactived from each active LRU > > > > to each inactive LRU if the page has one map_count. In other words, > > > > > > > > if (page_mapcount(page) <= 1) > > > > deactivate_page(page); > > > > > > Why do we restrict to pages that are single mapped? > > > > Because page table in one of process shared the page would have access bit > > so finally we couldn't reclaim the page. The more process it is shared, > > the more fail to reclaim. > > So what? In other words why should it be restricted solely based on the > map count. I can see a reason to restrict based on the access > permissions because we do not want to simplify all sorts of side channel > attacks but memory reclaim is capable of reclaiming shared pages and so > far I haven't heard any sound argument why madvise should skip those. > Again if there are any reasons, then document them in the changelog. I will go with removing the part so that defer to decision to the VM reclaim based on the review. > > [...] > > > > Please document this, if this is really a desirable semantic because > > > then you have the same set of problems as we've had with the early > > > MADV_FREE implementation mentioned above. > > > > IIRC, the problem of MADV_FREE was that we couldn't discard freeable > > pages because VM never scan anonymous LRU with swapless system. > > However, it's not the our case because we should reclaim them, not > > discarding. > > Right. But there is still the page cache reclaim. Is it expected that > an explicitly cold memory doesn't get reclaimed because we have a > sufficient amount of page cache (a very common case) and we never age > anonymous memory because of that? If there are lots of used-once pages in file-LRU, I think there is no need to reclaim anonymous pages because it needs bigger overhead due to IO. It has been true for a long time in current VM policy. Reclaim preference model based on hints is as following based on cost: MADV_DONTNEED >> MADV_PAGEOUT > used-once pages > MADV_FREE >= MADV_COLD It is desirable for the new hints to be placed in the reclaiming preference order such that a) they don't overlap functionally with existing hints and b) we have a balanced ordering of disruptive and non-disruptive hints.
[PATCH 0/3] rtc: pcf8563: Fix unhandled interrupt storm
From: Chen-Yu Tsai Hi everyone, While bringing up my Pine H64, I encountered an interrupt storm from the pcf8563 RTC. The RTC chip's interrupt line is shared with the PMIC, and was not properly added to the device tree. Also, the driver was using an trigger method incompatible with the PMIC, preventing the interrupt line from being shared. Last, the driver only clears and masks the alarm interrupt, while leaving the timer interrupt untouched. This is a problem if previous systems left the timer interrupt enabled, and there was an interrupt pending. This patch set fixes all three issues, one per patch. Please have a look. Chen-Yu Tsai (3): rtc: pcf8563: Fix interrupt trigger method rtc: pcf8563: Clear event flags and disable interrupts before requesting irq arm64: dts: allwinner: h6: Pine H64: Add interrupt line for RTC .../arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts | 2 ++ drivers/rtc/rtc-pcf8563.c | 13 ++--- 2 files changed, 8 insertions(+), 7 deletions(-) -- 2.20.1
[PATCH 1/3] rtc: pcf8563: Fix interrupt trigger method
From: Chen-Yu Tsai
The PCF8563 datasheet says the interrupt line is active low and stays
active until the events are cleared, i.e. a level trigger interrupt.
Fix the flags used to request the interrupt.
Fixes: ede3e9d47cca ("drivers/rtc/rtc-pcf8563.c: add alarm support")
Signed-off-by: Chen-Yu Tsai
---
Not sure if this would cause issues for other platforms. Ideally we'd
take the flags from the device tree, but it seems not all platforms
support this.
---
drivers/rtc/rtc-pcf8563.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c
index 3efc86c25d27..e358313466f1 100644
--- a/drivers/rtc/rtc-pcf8563.c
+++ b/drivers/rtc/rtc-pcf8563.c
@@ -605,7 +605,7 @@ static int pcf8563_probe(struct i2c_client *client,
if (client->irq > 0) {
err = devm_request_threaded_irq(>dev, client->irq,
NULL, pcf8563_irq,
- IRQF_SHARED|IRQF_ONESHOT|IRQF_TRIGGER_FALLING,
+ IRQF_SHARED | IRQF_ONESHOT | IRQF_TRIGGER_LOW,
pcf8563_driver.driver.name, client);
if (err) {
dev_err(>dev, "unable to request IRQ %d\n",
--
2.20.1
[PATCH 3/3] arm64: dts: allwinner: h6: Pine H64: Add interrupt line for RTC
From: Chen-Yu Tsai
The external PCF8563 RTC chip's interrupt line is connected to the NMI
line on the SoC.
Add the interrupt line to the device tree.
Fixes: 17ebc33afc35 ("arm64: allwinner: h6: add PCF8563 RTC on Pine H64 board")
Signed-off-by: Chen-Yu Tsai
---
arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
index 9e464d40cbff..189834518391 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
@@ -249,6 +249,8 @@
pcf8563: rtc@51 {
compatible = "nxp,pcf8563";
reg = <0x51>;
+ interrupt-parent = <_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
#clock-cells = <0>;
};
};
--
2.20.1
[PATCH 2/3] rtc: pcf8563: Clear event flags and disable interrupts before requesting irq
From: Chen-Yu Tsai
Besides the alarm, the PCF8563 also has a timer triggered interrupt.
In cases where the previous system left the timer and interrupts on,
or somehow the bits got enabled, the interrupt would keep triggering
as the kernel doesn't know about it.
Clear both the alarm and timer event flags, and disable the interrupts,
before requesting the interrupt line.
Fixes: ede3e9d47cca ("drivers/rtc/rtc-pcf8563.c: add alarm support")
Fixes: a45d528aab8b ("rtc: pcf8563: clear expired alarm at boot time")
Signed-off-by: Chen-Yu Tsai
---
drivers/rtc/rtc-pcf8563.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c
index e358313466f1..d8adf69b6697 100644
--- a/drivers/rtc/rtc-pcf8563.c
+++ b/drivers/rtc/rtc-pcf8563.c
@@ -563,7 +563,6 @@ static int pcf8563_probe(struct i2c_client *client,
struct pcf8563 *pcf8563;
int err;
unsigned char buf;
- unsigned char alm_pending;
dev_dbg(>dev, "%s\n", __func__);
@@ -587,13 +586,13 @@ static int pcf8563_probe(struct i2c_client *client,
return err;
}
- err = pcf8563_get_alarm_mode(client, NULL, _pending);
- if (err) {
- dev_err(>dev, "%s: read error\n", __func__);
+ /* Clear flags and disable interrupts */
+ buf = 0;
+ err = pcf8563_write_block_data(client, PCF8563_REG_ST2, 1, );
+ if (err < 0) {
+ dev_err(>dev, "%s: write error\n", __func__);
return err;
}
- if (alm_pending)
- pcf8563_set_alarm_mode(client, 0);
pcf8563->rtc = devm_rtc_device_register(>dev,
pcf8563_driver.driver.name,
--
2.20.1
[PATCH v3 3/4] staging: rtl8712: removed unused variables from struct _adapter
This patch removed following unused variables from struct _adapter
IsrContent, xmitThread, evtThread, recvThread
Signed-off-by: Deepak Mishra
---
drivers/staging/rtl8712/drv_types.h | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/rtl8712/drv_types.h
b/drivers/staging/rtl8712/drv_types.h
index 0c722e9c2410..c36a5ef3ee5d 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -148,13 +148,9 @@ struct _adapter {
booldriver_stopped;
boolsurprise_removed;
boolsuspended;
- u32 IsrContent;
u8 eeprom_address_size;
u8 hw_init_completed;
struct task_struct *cmd_thread;
- pid_t evtThread;
- struct task_struct *xmitThread;
- pid_t recvThread;
uint (*dvobj_init)(struct _adapter *adapter);
void (*dvobj_deinit)(struct _adapter *adapter);
struct net_device *pnetdev;
--
2.19.1
[PATCH v3 0/4] staging: rtl8712: cleanup struct _adapter
In process of cleaning up rtl8712 struct _adapter in drv_types.h I have tried to remove some unused variables and redundant lines of code associated with those variables. I have also fixed some CamelCase reported by checkpatch.pl There are some other code like spinning on a random variable which I am investigating and will clean up in a different patch set. Deepak Mishra (4): staging: rtl8712: Fixed CamelCase for EepromAddressSize and removed unused variable staging: rtl8712: Fixed CamelCase cmdThread rename to cmd_thread staging: rtl8712: removed unused variables from struct _adapter staging: rtl8712: Fixed CamelCase wkFilterRxFF0 and lockRxFF0Filter drivers/staging/rtl8712/drv_types.h| 11 +++ drivers/staging/rtl8712/os_intfs.c | 6 +++--- drivers/staging/rtl8712/rtl871x_eeprom.c | 6 +++--- drivers/staging/rtl8712/rtl871x_mp_ioctl.c | 5 - drivers/staging/rtl8712/rtl871x_pwrctrl.h | 1 - drivers/staging/rtl8712/rtl871x_xmit.c | 2 +- drivers/staging/rtl8712/usb_intf.c | 4 ++-- drivers/staging/rtl8712/xmit_linux.c | 6 +++--- 8 files changed, 15 insertions(+), 26 deletions(-) -- 2.19.1
[PATCH v3 1/4] staging: rtl8712: Fixed CamelCase for EepromAddressSize and removed unused variable
This patch renames CamelCase EepromAddressSizefrom to eeprom_address_size in
struct _adapter and in related files drv_types.h, rtl871x_eeprom.c, usb_intf.c
CHECK: Avoid CamelCase:
This patch removed unused variable ImrContent from struct _adapter and
struct pwrctrl_priv and redundant lines from rtl871x_mp_ioctl.c
Signed-off-by: Deepak Mishra
---
drivers/staging/rtl8712/drv_types.h| 3 +--
drivers/staging/rtl8712/rtl871x_eeprom.c | 6 +++---
drivers/staging/rtl8712/rtl871x_mp_ioctl.c | 5 -
drivers/staging/rtl8712/rtl871x_pwrctrl.h | 1 -
drivers/staging/rtl8712/usb_intf.c | 2 +-
5 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/rtl8712/drv_types.h
b/drivers/staging/rtl8712/drv_types.h
index 9ae86631fa8b..9fbd19f03ca9 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -149,8 +149,7 @@ struct _adapter {
boolsurprise_removed;
boolsuspended;
u32 IsrContent;
- u32 ImrContent;
- u8 EepromAddressSize;
+ u8 eeprom_address_size;
u8 hw_init_completed;
struct task_struct *cmdThread;
pid_t evtThread;
diff --git a/drivers/staging/rtl8712/rtl871x_eeprom.c
b/drivers/staging/rtl8712/rtl871x_eeprom.c
index 0027d8eb22fa..221bf92e1b1c 100644
--- a/drivers/staging/rtl8712/rtl871x_eeprom.c
+++ b/drivers/staging/rtl8712/rtl871x_eeprom.c
@@ -150,7 +150,7 @@ void r8712_eeprom_write16(struct _adapter *padapter, u16
reg, u16 data)
x |= _EEM1 | _EECS;
r8712_write8(padapter, EE_9346CR, x);
shift_out_bits(padapter, EEPROM_EWEN_OPCODE, 5);
- if (padapter->EepromAddressSize == 8) /*CF+ and SDIO*/
+ if (padapter->eeprom_address_size == 8) /*CF+ and SDIO*/
shift_out_bits(padapter, 0, 6);
else/* USB */
shift_out_bits(padapter, 0, 4);
@@ -165,7 +165,7 @@ void r8712_eeprom_write16(struct _adapter *padapter, u16
reg, u16 data)
*/
shift_out_bits(padapter, EEPROM_WRITE_OPCODE, 3);
/* select which word in the EEPROM that we are writing to. */
- shift_out_bits(padapter, reg, padapter->EepromAddressSize);
+ shift_out_bits(padapter, reg, padapter->eeprom_address_size);
/* write the data to the selected EEPROM word. */
shift_out_bits(padapter, data, 16);
if (wait_eeprom_cmd_done(padapter)) {
@@ -207,7 +207,7 @@ u16 r8712_eeprom_read16(struct _adapter *padapter, u16 reg)
/*ReadEEprom*/
* The opcode is 3bits in length, reg is 6 bits long
*/
shift_out_bits(padapter, EEPROM_READ_OPCODE, 3);
- shift_out_bits(padapter, reg, padapter->EepromAddressSize);
+ shift_out_bits(padapter, reg, padapter->eeprom_address_size);
/* Now read the data (16 bits) in from the selected EEPROM word */
data = shift_in_bits(padapter);
eeprom_clean(padapter);
diff --git a/drivers/staging/rtl8712/rtl871x_mp_ioctl.c
b/drivers/staging/rtl8712/rtl871x_mp_ioctl.c
index 588346da1412..add6c18195d6 100644
--- a/drivers/staging/rtl8712/rtl871x_mp_ioctl.c
+++ b/drivers/staging/rtl8712/rtl871x_mp_ioctl.c
@@ -661,11 +661,6 @@ uint oid_rt_pro_write_register_hdl(struct oid_par_priv
*poid_par_priv)
status = RNDIS_STATUS_NOT_ACCEPTED;
break;
}
-
- if ((status == RNDIS_STATUS_SUCCESS) &&
- (RegRWStruct->offset == HIMR) &&
- (RegRWStruct->width == 4))
- Adapter->ImrContent = RegRWStruct->value;
}
return status;
}
diff --git a/drivers/staging/rtl8712/rtl871x_pwrctrl.h
b/drivers/staging/rtl8712/rtl871x_pwrctrl.h
index 11b5034f203d..2dd9f558d351 100644
--- a/drivers/staging/rtl8712/rtl871x_pwrctrl.h
+++ b/drivers/staging/rtl8712/rtl871x_pwrctrl.h
@@ -88,7 +88,6 @@ structpwrctrl_priv {
uint pwr_mode;
uint smart_ps;
uint alives;
- uint ImrContent;/* used to store original imr. */
uint bSleep; /* sleep -> active is different from active -> sleep. */
struct work_struct SetPSModeWorkItem;
diff --git a/drivers/staging/rtl8712/usb_intf.c
b/drivers/staging/rtl8712/usb_intf.c
index 7478bbd3de78..200a271c28e1 100644
--- a/drivers/staging/rtl8712/usb_intf.c
+++ b/drivers/staging/rtl8712/usb_intf.c
@@ -246,7 +246,7 @@ static uint r8712_usb_dvobj_init(struct _adapter *padapter)
struct usb_device *pusbd = pdvobjpriv->pusbdev;
pdvobjpriv->padapter = padapter;
- padapter->EepromAddressSize = 6;
+ padapter->eeprom_address_size = 6;
phost_iface = >altsetting[0];
piface_desc = _iface->desc;
pdvobjpriv->nr_endpoint = piface_desc->bNumEndpoints;
--
2.19.1
[PATCH v3 4/4] staging: rtl8712: Fixed CamelCase wkFilterRxFF0 and lockRxFF0Filter
This patch renames CamelCase variable wkFilterRxFF0 to wk_filter_rx_ff0
in drv_types.h and related files rtl871x_xmit.c and xmit_linux.c as
reported by checkpatch.pl
This patch renames CamelCase variable lockRxFF0Filter to lock_rx_ff0_filter
in drv_types.h and related files usb_intf.c and xmit_linux.c as
reported by checkpatch.pl
Signed-off-by: Deepak Mishra
---
drivers/staging/rtl8712/drv_types.h| 2 +-
drivers/staging/rtl8712/rtl871x_xmit.c | 2 +-
drivers/staging/rtl8712/usb_intf.c | 2 +-
drivers/staging/rtl8712/xmit_linux.c | 6 +++---
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8712/drv_types.h
b/drivers/staging/rtl8712/drv_types.h
index c36a5ef3ee5d..7838c945d622 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -158,7 +158,7 @@ struct _adapter {
struct net_device_stats stats;
struct iw_statistics iwstats;
int pid; /*process id from UI*/
- struct work_struct wkFilterRxFF0;
+ struct work_struct wk_filter_rx_ff0;
u8 blnEnableRxFF0Filter;
spinlock_t lockRxFF0Filter;
const struct firmware *fw;
diff --git a/drivers/staging/rtl8712/rtl871x_xmit.c
b/drivers/staging/rtl8712/rtl871x_xmit.c
index bfd5538a4652..5d63d2721eb6 100644
--- a/drivers/staging/rtl8712/rtl871x_xmit.c
+++ b/drivers/staging/rtl8712/rtl871x_xmit.c
@@ -139,7 +139,7 @@ sint _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv,
pxmitbuf++;
}
pxmitpriv->free_xmitbuf_cnt = NR_XMITBUFF;
- INIT_WORK(>wkFilterRxFF0, r8712_SetFilter);
+ INIT_WORK(>wk_filter_rx_ff0, r8712_SetFilter);
alloc_hwxmits(padapter);
init_hwxmits(pxmitpriv->hwxmits, pxmitpriv->hwxmit_entry);
tasklet_init(>xmit_tasklet,
diff --git a/drivers/staging/rtl8712/usb_intf.c
b/drivers/staging/rtl8712/usb_intf.c
index 200a271c28e1..d0daae0b8299 100644
--- a/drivers/staging/rtl8712/usb_intf.c
+++ b/drivers/staging/rtl8712/usb_intf.c
@@ -571,7 +571,7 @@ static int r871xu_drv_init(struct usb_interface *pusb_intf,
/* step 6. Load the firmware asynchronously */
if (rtl871x_load_fw(padapter))
goto error;
- spin_lock_init(>lockRxFF0Filter);
+ spin_lock_init(>lock_rx_ff0_filter);
mutex_init(>mutex_start);
return 0;
error:
diff --git a/drivers/staging/rtl8712/xmit_linux.c
b/drivers/staging/rtl8712/xmit_linux.c
index 8bcb0775411f..71100613aeb3 100644
--- a/drivers/staging/rtl8712/xmit_linux.c
+++ b/drivers/staging/rtl8712/xmit_linux.c
@@ -94,7 +94,7 @@ void r8712_set_qos(struct pkt_file *ppktfile, struct
pkt_attrib *pattrib)
void r8712_SetFilter(struct work_struct *work)
{
struct _adapter *padapter = container_of(work, struct _adapter,
- wkFilterRxFF0);
+ wk_filter_rx_ff0);
u8 oldvalue = 0x00, newvalue = 0x00;
unsigned long irqL;
@@ -102,9 +102,9 @@ void r8712_SetFilter(struct work_struct *work)
newvalue = oldvalue & 0xfe;
r8712_write8(padapter, 0x117, newvalue);
- spin_lock_irqsave(>lockRxFF0Filter, irqL);
+ spin_lock_irqsave(>lock_rx_ff0_filter, irqL);
padapter->blnEnableRxFF0Filter = 1;
- spin_unlock_irqrestore(>lockRxFF0Filter, irqL);
+ spin_unlock_irqrestore(>lock_rx_ff0_filter, irqL);
do {
msleep(100);
} while (padapter->blnEnableRxFF0Filter == 1);
--
2.19.1
[PATCH v3 2/4] staging: rtl8712: Fixed CamelCase cmdThread rename to cmd_thread
This patch renames CamelCase cmdThread to cmd_thread in struct _adapter and
related
files drv_types.h,os_intfs.c
CHECK: Avoid CamelCase:
Signed-off-by: Deepak Mishra
---
drivers/staging/rtl8712/drv_types.h | 2 +-
drivers/staging/rtl8712/os_intfs.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8712/drv_types.h
b/drivers/staging/rtl8712/drv_types.h
index 9fbd19f03ca9..0c722e9c2410 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -151,7 +151,7 @@ struct _adapter {
u32 IsrContent;
u8 eeprom_address_size;
u8 hw_init_completed;
- struct task_struct *cmdThread;
+ struct task_struct *cmd_thread;
pid_t evtThread;
struct task_struct *xmitThread;
pid_t recvThread;
diff --git a/drivers/staging/rtl8712/os_intfs.c
b/drivers/staging/rtl8712/os_intfs.c
index c962696c9822..1653b36c4bfd 100644
--- a/drivers/staging/rtl8712/os_intfs.c
+++ b/drivers/staging/rtl8712/os_intfs.c
@@ -221,9 +221,9 @@ struct net_device *r8712_init_netdev(void)
static u32 start_drv_threads(struct _adapter *padapter)
{
- padapter->cmdThread = kthread_run(r8712_cmd_thread, padapter, "%s",
+ padapter->cmd_thread = kthread_run(r8712_cmd_thread, padapter, "%s",
padapter->pnetdev->name);
- if (IS_ERR(padapter->cmdThread))
+ if (IS_ERR(padapter->cmd_thread))
return _FAIL;
return _SUCCESS;
}
@@ -235,7 +235,7 @@ void r8712_stop_drv_threads(struct _adapter *padapter)
/*Below is to terminate r8712_cmd_thread & event_thread...*/
complete(>cmdpriv.cmd_queue_comp);
- if (padapter->cmdThread)
+ if (padapter->cmd_thread)
wait_for_completion_interruptible(completion);
padapter->cmdpriv.cmd_seq = 1;
}
--
2.19.1
Re: [PATCH v2 8/9] staging: rtl8712: fixed enable_rx_ff0_filter as bool and CamelCase
On 02/06/19 10:44 PM, Greg KH wrote:
On Sun, Jun 02, 2019 at 03:55:37PM +0530, Deepak Mishra wrote:
This patch fixes CamelCase blnEnableRxFF0Filter by renaming it
to enable_rx_ff0_filter in drv_types.h and related files rtl871x_cmd.c
xmit_linux.c
It was reported by checkpatch.pl
This fix also makes enable_rx_ff0_filter a bool and uses true false than
previously used u8 as suggested by j...@perches.com
Signed-off-by: Deepak Mishra
---
drivers/staging/rtl8712/drv_types.h | 2 +-
drivers/staging/rtl8712/rtl871x_cmd.c | 2 +-
drivers/staging/rtl8712/xmit_linux.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8712/drv_types.h
b/drivers/staging/rtl8712/drv_types.h
index ddab6514a549..e3e2b32e964e 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -164,7 +164,7 @@ struct _adapter {
struct iw_statistics iwstats;
int pid; /*process id from UI*/
struct work_struct wk_filter_rx_ff0;
- u8 blnEnableRxFF0Filter;
+ bool enable_rx_ff0_filter;
spinlock_t lockRxFF0Filter;
const struct firmware *fw;
struct usb_interface *pusb_intf;
diff --git a/drivers/staging/rtl8712/rtl871x_cmd.c
b/drivers/staging/rtl8712/rtl871x_cmd.c
index 05a78ac24987..6a8d58d97873 100644
--- a/drivers/staging/rtl8712/rtl871x_cmd.c
+++ b/drivers/staging/rtl8712/rtl871x_cmd.c
@@ -238,7 +238,7 @@ u8 r8712_sitesurvey_cmd(struct _adapter *padapter,
mod_timer(>scan_to_timer,
jiffies + msecs_to_jiffies(SCANNING_TIMEOUT));
padapter->ledpriv.LedControlHandler(padapter, LED_CTL_SITE_SURVEY);
- padapter->blnEnableRxFF0Filter = 0;
+ padapter->enable_rx_ff0_filter = false;
return _SUCCESS;
}
diff --git a/drivers/staging/rtl8712/xmit_linux.c b/drivers/staging/rtl8712/xmit_linux.c
index e65a51c7f372..9fa1abcf5e50 100644
--- a/drivers/staging/rtl8712/xmit_linux.c
+++ b/drivers/staging/rtl8712/xmit_linux.c
@@ -103,11 +103,11 @@ void r8712_SetFilter(struct work_struct *work)
r8712_write8(padapter, 0x117, newvalue);
spin_lock_irqsave(>lockRxFF0Filter, irqL);
- padapter->blnEnableRxFF0Filter = 1;
+ padapter->enable_rx_ff0_filter = true;
spin_unlock_irqrestore(>lockRxFF0Filter, irqL);
do {
msleep(100);
- } while (padapter->blnEnableRxFF0Filter == 1);
+ } while (padapter->enable_rx_ff0_filter == true);
That is horrible, and I'm amazed it ever even works. Please fix this
properly, spinning on a random variable is not how you do
synchronization in the kernel.
I agree and will submit a different fix for this.
I am submitting a patchset v3 for removal of unused variables and
CamelCase fix for now.
Thanks.
Deepak Mishra
thanks,
greg k-h
Re: [PATCH v7 09/12] mm/sparsemem: Support sub-section hotplug
On Fri, May 3, 2019 at 5:56 AM Oscar Salvador wrote:
>
> On Wed, May 01, 2019 at 10:56:10PM -0700, Dan Williams wrote:
> > The libnvdimm sub-system has suffered a series of hacks and broken
> > workarounds for the memory-hotplug implementation's awkward
> > section-aligned (128MB) granularity. For example the following backtrace
> > is emitted when attempting arch_add_memory() with physical address
> > ranges that intersect 'System RAM' (RAM) with 'Persistent Memory' (PMEM)
> > within a given section:
> >
> > WARNING: CPU: 0 PID: 558 at kernel/memremap.c:300
> > devm_memremap_pages+0x3b5/0x4c0
> > devm_memremap_pages attempted on mixed region [mem 0x2-0x2fbff
> > flags 0x200]
> > [..]
> > Call Trace:
> >dump_stack+0x86/0xc3
> >__warn+0xcb/0xf0
> >warn_slowpath_fmt+0x5f/0x80
> >devm_memremap_pages+0x3b5/0x4c0
> >__wrap_devm_memremap_pages+0x58/0x70 [nfit_test_iomap]
> >pmem_attach_disk+0x19a/0x440 [nd_pmem]
> >
> > Recently it was discovered that the problem goes beyond RAM vs PMEM
> > collisions as some platform produce PMEM vs PMEM collisions within a
> > given section. The libnvdimm workaround for that case revealed that the
> > libnvdimm section-alignment-padding implementation has been broken for a
> > long while. A fix for that long-standing breakage introduces as many
> > problems as it solves as it would require a backward-incompatible change
> > to the namespace metadata interpretation. Instead of that dubious route
> > [1], address the root problem in the memory-hotplug implementation.
> >
> > [1]:
> > https://lore.kernel.org/r/155000671719.348031.2347363160141119237.st...@dwillia2-desk3.amr.corp.intel.com
> > Cc: Michal Hocko
> > Cc: Vlastimil Babka
> > Cc: Logan Gunthorpe
> > Signed-off-by: Dan Williams
> > ---
> > mm/sparse.c | 223
> > ---
> > 1 file changed, 150 insertions(+), 73 deletions(-)
> >
> > diff --git a/mm/sparse.c b/mm/sparse.c
> > index 198371e5fc87..419a3620af6e 100644
> > --- a/mm/sparse.c
> > +++ b/mm/sparse.c
> > @@ -83,8 +83,15 @@ static int __meminit sparse_index_init(unsigned long
> > section_nr, int nid)
> > unsigned long root = SECTION_NR_TO_ROOT(section_nr);
> > struct mem_section *section;
> >
> > + /*
> > + * An existing section is possible in the sub-section hotplug
> > + * case. First hot-add instantiates, follow-on hot-add reuses
> > + * the existing section.
> > + *
> > + * The mem_hotplug_lock resolves the apparent race below.
> > + */
> > if (mem_section[root])
> > - return -EEXIST;
> > + return 0;
>
> Just a sidenote: we do not bail out on -EEXIST, so it should be fine if we
> stick with it.
> But if not, I would then clean up sparse_add_section:
>
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -901,13 +901,12 @@ int __meminit sparse_add_section(int nid, unsigned long
> start_pfn,
> int ret;
>
> ret = sparse_index_init(section_nr, nid);
> - if (ret < 0 && ret != -EEXIST)
> + if (ret < 0)
> return ret;
>
> memmap = section_activate(nid, start_pfn, nr_pages, altmap);
> if (IS_ERR(memmap))
> return PTR_ERR(memmap);
> - ret = 0;
Good catch, folded the cleanup.
>
>
> > +
> > + if (!mask)
> > + rc = -EINVAL;
> > + else if (mask & ms->usage->map_active)
>
> else if (ms->usage->map_active) should be enough?
>
> > + rc = -EEXIST;
> > + else
> > + ms->usage->map_active |= mask;
> > +
> > + if (rc) {
> > + if (usage)
> > + ms->usage = NULL;
> > + kfree(usage);
> > + return ERR_PTR(rc);
> > + }
> > +
> > + /*
> > + * The early init code does not consider partially populated
> > + * initial sections, it simply assumes that memory will never be
> > + * referenced. If we hot-add memory into such a section then we
> > + * do not need to populate the memmap and can simply reuse what
> > + * is already there.
> > + */
>
> This puzzles me a bit.
> I think we cannot have partially populated early sections, can we?
Yes, at boot memory need not be section aligned it has historically
been handled as a un-removable section of memory with holes.
> And how we even come to hot-add memory into those?
>
> Could you please elaborate a bit here?
Those sections are excluded from add_memory_resource() adding more
memory, but arch_add_memory() with sub-section support can fill in the
subsection holes in mem_map.
>
> > + ms = __pfn_to_section(start_pfn);
> > section_mark_present(ms);
> > - sparse_init_one_section(ms, section_nr, memmap, usage);
> > + sparse_init_one_section(ms, section_nr, memmap, ms->usage);
> >
> > -out:
> > - if (ret < 0) {
> > - kfree(usage);
> > - depopulate_section_memmap(start_pfn, PAGES_PER_SECTION,
> >
[PATCH] driver core: show the error number when driver_sysfs_add() fails
If driver_sysfs_add() fails, kernel shows following message,
really_probe: driver_sysfs_add(portman.0) failed
ppdev: probe of portman.0 failed with error 0
It's better to show the error number like other probe_failed path.
Signed-off-by: Kefeng Wang
---
drivers/base/dd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 0df9b4461766..04ee4e196530 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -493,7 +493,8 @@ static int really_probe(struct device *dev, struct
device_driver *drv)
goto probe_failed;
}
- if (driver_sysfs_add(dev)) {
+ ret = driver_sysfs_add(dev);
+ if (ret) {
printk(KERN_ERR "%s: driver_sysfs_add(%s) failed\n",
__func__, dev_name(dev));
goto probe_failed;
--
2.20.1
Re: [block] 47cdee29ef: BUG:kernel_NULL_pointer_dereference,address
Hi Rong Chen,
Thanks for your test & report!
On Tue, Jun 04, 2019 at 10:09:56AM +0800, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 47cdee29ef9d94e485eb08f962c74943023a5271 ("block: move blk_exit_queue
> into __blk_release_queue")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> in testcase: trinity
> with following parameters:
>
> runtime: 300s
>
> test-description: Trinity is a linux system call fuzz tester.
> test-url: http://codemonkey.org.uk/projects/trinity/
>
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 2G
>
> caused below changes (please refer to attached dmesg/kmsg for entire
> log/backtrace):
>
>
> +-+++
> | | 31cb1d64da | 47cdee29ef |
> +-+++
> | boot_successes | 3 | 0 |
> | boot_failures | 13 | 8 |
> | BUG:kernel_reboot-without-warning_in_test_stage | 13 ||
> | BUG:kernel_NULL_pointer_dereference,address | 0 | 8 |
> | Oops:#[##] | 0 | 8 |
> | RIP:blk_mq_free_rqs | 0 | 8 |
> | Kernel_panic-not_syncing:Fatal_exception| 0 | 8 |
> +-+++
>
>
> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot
>
>
> [6.560544] BUG: kernel NULL pointer dereference, address: 0020
> [6.561658] #PF: supervisor read access in kernel mode
> [6.562495] #PF: error_code(0x) - not-present page
> [6.563277] PGD 0 P4D 0
> [6.563277] Oops: [#1] PTI
> [6.563277] CPU: 0 PID: 147 Comm: kworker/0:2 Tainted: GT
> 5.2.0-rc1-00387-g47cdee29 #1
> [6.563277] Workqueue: events __blk_release_queue
> [6.563277] RIP: 0010:blk_mq_free_rqs+0x2c/0xaf
Looks there is race between removing queue and switching elevator, and
which should be done by Trinity.
I guess that commit 47cdee29ef9d94e485eb08f962c74943023a5271 just
changes the timing and makes it easy to trigger.
Please test the following patch and see if difference can be made.
If the patch can't fix the issue, please enable KASAN and reproduce,
then more useful log may be got.
diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
index 75b5281cc577..400a2102a4e4 100644
--- a/block/blk-sysfs.c
+++ b/block/blk-sysfs.c
@@ -848,11 +848,13 @@ static void blk_exit_queue(struct request_queue *q)
* perform I/O scheduler exit before disassociating from the block
* cgroup controller.
*/
+ mutex_lock(>sysfs_lock);
if (q->elevator) {
ioc_clear_queue(q);
elevator_exit(q, q->elevator);
q->elevator = NULL;
}
+ mutex_unlock(>sysfs_lock);
/*
* Remove all references to @q from the block cgroup controller before
Thanks,
Ming
Re: [PATCH 0/2] cpufreq: brcmstb-avs-cpufreq: Couple fixes
On 03-06-19, 12:55, Markus Mayer wrote: > On Wed, 29 May 2019 at 10:02, Florian Fainelli wrote: > > > > On 5/27/19 3:51 AM, Rafael J. Wysocki wrote: > > > On Wednesday, May 22, 2019 8:45:45 PM CEST Florian Fainelli wrote: > > >> Hi Rafael, Viresh, > > >> > > >> These patch series contains two minor fixes for the brcmstb-avs-cpufreq > > >> driver. > > >> > > >> Florian Fainelli (2): > > >> cpufreq: brcmstb-avs-cpufreq: Fix initial command check > > >> cpufreq: brcmstb-avs-cpufreq: Fix types for voltage/frequency > > To both of these > > Acked-by: Markus Mayer Applied. Thanks. -- viresh
[PATCH] net: ipvlan: Fix ipvlan device tso disabled while NETIF_F_IP_CSUM is set
There's some NICs, such as hinic, with NETIF_F_IP_CSUM and NETIF_F_TSO
on but NETIF_F_HW_CSUM off. And ipvlan device features will be
NETIF_F_TSO on with NETIF_F_IP_CSUM and NETIF_F_IP_CSUM both off as
IPVLAN_FEATURES only care about NETIF_F_HW_CSUM. So TSO will be
disabled in netdev_fix_features.
For example:
Features for enp129s0f0:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: on
tx-checksum-ip-generic: off [fixed]
tx-checksum-ipv6: on
Fixes: a188222b6ed2 ("net: Rename NETIF_F_ALL_CSUM to NETIF_F_CSUM_MASK")
Signed-off-by: Miaohe Lin
---
drivers/net/ipvlan/ipvlan_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c
index bbeb1623e2d5..717fce6edeb7 100644
--- a/drivers/net/ipvlan/ipvlan_main.c
+++ b/drivers/net/ipvlan/ipvlan_main.c
@@ -112,7 +112,7 @@ static void ipvlan_port_destroy(struct net_device *dev)
}
#define IPVLAN_FEATURES \
- (NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_HIGHDMA | NETIF_F_FRAGLIST | \
+ (NETIF_F_SG | NETIF_F_CSUM_MASK | NETIF_F_HIGHDMA | NETIF_F_FRAGLIST | \
NETIF_F_GSO | NETIF_F_TSO | NETIF_F_GSO_ROBUST | \
NETIF_F_TSO_ECN | NETIF_F_TSO6 | NETIF_F_GRO | NETIF_F_RXCSUM | \
NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_STAG_FILTER)
--
2.21.GIT
Re: [PATCH v1 4/4] mm: introduce MADV_PAGEOUT
On Mon, Jun 03, 2019 at 04:39:11PM -0400, Johannes Weiner wrote:
> On Mon, Jun 03, 2019 at 02:36:55PM +0900, Minchan Kim wrote:
> > When a process expects no accesses to a certain memory range
> > for a long time, it could hint kernel that the pages can be
> > reclaimed instantly but data should be preserved for future use.
> > This could reduce workingset eviction so it ends up increasing
> > performance.
> >
> > This patch introduces the new MADV_PAGEOUT hint to madvise(2)
> > syscall. MADV_PAGEOUT can be used by a process to mark a memory
> > range as not expected to be used for a long time so that kernel
> > reclaims *any LRU* pages instantly. The hint can help kernel in deciding
> > which pages to evict proactively.
> >
> > All of error rule is same with MADV_DONTNEED.
> >
> > Note:
> > This hint works with only private pages(IOW, page_mapcount(page) < 2)
> > because shared page could have more chance to be accessed from other
> > processes sharing the page so that it could cause major fault soon,
> > which is inefficient.
> >
> > * RFC v2
> > * make reclaim_pages simple via factoring out isolate logic - hannes
> >
> > * RFCv1
> > * rename from MADV_COLD to MADV_PAGEOUT - hannes
> > * bail out if process is being killed - Hillf
> > * fix reclaim_pages bugs - Hillf
> >
> > Signed-off-by: Minchan Kim
> > ---
> > include/linux/swap.h | 1 +
> > include/uapi/asm-generic/mman-common.h | 1 +
> > mm/madvise.c | 126 +
> > mm/vmscan.c| 34 +++
> > 4 files changed, 162 insertions(+)
> >
> > diff --git a/include/linux/swap.h b/include/linux/swap.h
> > index 0ce997edb8bb..063c0c1e112b 100644
> > --- a/include/linux/swap.h
> > +++ b/include/linux/swap.h
> > @@ -365,6 +365,7 @@ extern int vm_swappiness;
> > extern int remove_mapping(struct address_space *mapping, struct page
> > *page);
> > extern unsigned long vm_total_pages;
> >
> > +extern unsigned long reclaim_pages(struct list_head *page_list);
> > #ifdef CONFIG_NUMA
> > extern int node_reclaim_mode;
> > extern int sysctl_min_unmapped_ratio;
> > diff --git a/include/uapi/asm-generic/mman-common.h
> > b/include/uapi/asm-generic/mman-common.h
> > index 1190f4e7f7b9..92e347a89ddc 100644
> > --- a/include/uapi/asm-generic/mman-common.h
> > +++ b/include/uapi/asm-generic/mman-common.h
> > @@ -44,6 +44,7 @@
> > #define MADV_WILLNEED 3 /* will need these pages */
> > #define MADV_DONTNEED 4 /* don't need these pages */
> > #define MADV_COLD 5 /* deactivatie these pages */
> > +#define MADV_PAGEOUT 6 /* reclaim these pages */
> >
> > /* common parameters: try to keep these consistent across architectures */
> > #define MADV_FREE 8 /* free pages only if memory pressure */
> > diff --git a/mm/madvise.c b/mm/madvise.c
> > index ab158766858a..b010249cb8b6 100644
> > --- a/mm/madvise.c
> > +++ b/mm/madvise.c
> > @@ -41,6 +41,7 @@ static int madvise_need_mmap_write(int behavior)
> > case MADV_WILLNEED:
> > case MADV_DONTNEED:
> > case MADV_COLD:
> > + case MADV_PAGEOUT:
> > case MADV_FREE:
> > return 0;
> > default:
> > @@ -415,6 +416,128 @@ static long madvise_cold(struct vm_area_struct *vma,
> > return 0;
> > }
> >
> > +static int madvise_pageout_pte_range(pmd_t *pmd, unsigned long addr,
> > + unsigned long end, struct mm_walk *walk)
> > +{
> > + pte_t *orig_pte, *pte, ptent;
> > + spinlock_t *ptl;
> > + LIST_HEAD(page_list);
> > + struct page *page;
> > + int isolated = 0;
> > + struct vm_area_struct *vma = walk->vma;
> > + unsigned long next;
> > +
> > + if (fatal_signal_pending(current))
> > + return -EINTR;
> > +
> > + next = pmd_addr_end(addr, end);
> > + if (pmd_trans_huge(*pmd)) {
> > + ptl = pmd_trans_huge_lock(pmd, vma);
> > + if (!ptl)
> > + return 0;
> > +
> > + if (is_huge_zero_pmd(*pmd))
> > + goto huge_unlock;
> > +
> > + page = pmd_page(*pmd);
> > + if (page_mapcount(page) > 1)
> > + goto huge_unlock;
> > +
> > + if (next - addr != HPAGE_PMD_SIZE) {
> > + int err;
> > +
> > + get_page(page);
> > + spin_unlock(ptl);
> > + lock_page(page);
> > + err = split_huge_page(page);
> > + unlock_page(page);
> > + put_page(page);
> > + if (!err)
> > + goto regular_page;
> > + return 0;
> > + }
> > +
> > + if (isolate_lru_page(page))
> > + goto huge_unlock;
> > +
> > + list_add(>lru, _list);
> > +huge_unlock:
> > + spin_unlock(ptl);
> > + reclaim_pages(_list);
> > +
Re: [PATCH] kbuild: use more portable 'command -v' for cc-cross-prefix
On Mon, Jun 3, 2019 at 9:43 PM David Laight wrote:
>
> From: Masahiro Yamada
> > Sent: 03 June 2019 12:45
> > On Mon, Jun 3, 2019 at 8:16 PM David Laight wrote:
> > >
> > > From: Masahiro Yamada
> > > > Sent: 03 June 2019 11:49
> > > >
> > > > To print the pathname that will be used by shell in the current
> > > > environment, 'command -v' is a standardized way. [1]
> > > >
> > > > 'which' is also often used in scripting, but it is not portable.
> > >
> > > All uses of 'which' should be expunged.
> > > It is a bourne shell script that is trying to emulate a csh builtin.
> > > It is doomed to fail in corner cases.
> > > ISTR it has serious problems with shell functions and aliases.
> >
> > OK, I do not have time to check it treewide.
> > I expect somebody will contribute to it.
> >
> >
> >
> > BTW, I see yet another way to get the command path.
> >
> > 'type -path' is bash-specific.
>
> 'type' itself should be supported by all shells, but the output
> format (esp for errors) probably varies.
>
> > Maybe, we should do this too:
> >
> > diff --git a/scripts/mkuboot.sh b/scripts/mkuboot.sh
> > index 4b1fe09e9042..77829ee4268e 100755
> > --- a/scripts/mkuboot.sh
> > +++ b/scripts/mkuboot.sh
> > @@ -1,14 +1,14 @@
> > -#!/bin/bash
> > +#!/bin/sh
>
> /bin/sh might be 'dash' - which is just plain broken in so many ways.
> Try (IIRC) ${foo%${foo#bar}}
> It might even be the original SYSV /bin/sh which doesn't support $((expr))
> or ${foo#bar} - but that may break too much, but $SHELL might fix it.
We cannot use any tool
if you start to argue like
"Hey, I know ancient implementation that did not work as expected".
Nobody can cover all corner-cases.
That's why we have standard.
I think the reliable source is the
Open Group Specification.
The behavior of /bin/sh is defined here:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_01
${parameter%[word]} and ${parameter#[word]} are defined,
so we can use them in /bin/sh scripts.
> dash probably has the rather obscure bug in stripping '\n' from $(...)
> output that I found and fixed in NetBSD's ash may years ago.
> Try: foo="$(jot -b "" 130)"
> All 130 '\n' should be deleted.
> Mostly it fails to delete all the '\n', but it can remove extra ones!
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1
> 1PT, UK
> Registration No: 1397386 (Wales)
--
Best Regards
Masahiro Yamada
Re: [PATCH] kbuild: use more portable 'command -v' for cc-cross-prefix
On Mon, Jun 3, 2019 at 10:09 PM David Laight wrote:
>
> From: Masahiro Yamada
> > Sent: 03 June 2019 12:38
> > Hi David,
> >
> > On Mon, Jun 3, 2019 at 8:14 PM David Laight wrote:
> > >
> > > From: Masahiro Yamada
> > > > Sent: 03 June 2019 11:49
> > > >
> > > > To print the pathname that will be used by shell in the current
> > > > environment, 'command -v' is a standardized way. [1]
> > > >
> > > > 'which' is also often used in scripting, but it is not portable.
> > > >
> > > > When I worked on commit bd55f96fa9fc ("kbuild: refactor cc-cross-prefix
> > > > implementation"), I was eager to use 'command -v' but it did not work.
> > > > (The reason is explained below.)
> > > >
> > > > I kept 'which' as before but got rid of '> /dev/null 2>&1' as I
> > > > thought it was no longer needed. Sorry, I was wrong.
> > > >
> > > > It works well on my Ubuntu machine, but Alexey Brodkin reports annoying
> > > > warnings from the 'which' on CentOS 7 when the given command is not
> > > > found in the PATH environment.
> > > >
> > > > $ which foo
> > > > which: no foo in
> > > > (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)
> > > >
> > > > Given that behavior of 'which' is different on environment, I want
> > > > to try 'command -v' again.
> > > >
> > > > The specification [1] clearly describes the behavior of 'command -v'
> > > > when the given command is not found:
> > > >
> > > > Otherwise, no output shall be written and the exit status shall
> > > > reflect
> > > > that the name was not found.
> > > >
> > > > However, we need a little magic to use 'command -v' from Make.
> > > >
> > > > $(shell ...) passes the argument to a subshell for execution, and
> > > > returns the standard output of the command.
> > > >
> > > > Here is a trick. GNU Make may optimize this by executing the command
> > > > directly instead of forking a subshell, if no shell special characters
> > > > are found in the command line and omitting the subshell will not
> > > > change the behavior.
> > > >
> > > > In this case, no shell special character is used. So, Make will try
> > > > to run the command directly. However, 'command' is a shell-builtin
> > > > command. In fact, Make has a table of shell-builtin commands because
> > > > it must spawn a subshell to execute them.
> > > >
> > > > Until recently, 'command' was missing in the table.
> > > >
> > > > This issue was fixed by the following commit:
> > > >
> > > > | commit 1af314465e5dfe3e8baa839a32a72e83c04f26ef
> > > > | Author: Paul Smith
> > > > | Date: Sun Nov 12 18:10:28 2017 -0500
> > > > |
> > > > | * job.c: Add "command" as a known shell built-in.
> > > > |
> > > > | This is not a POSIX shell built-in but it's common in UNIX shells.
> > > > | Reported by Nick Bowler .
> > > >
> > > > This is not included in any released versions of Make yet.
> > > > (But, some distributions may have back-ported the fix-up.)
> > > >
> > > > To trick Make and let it fork the subshell, I added a shell special
> > > > character '~'. We may be able to get rid of this workaround someday,
> > > > but it is very far into the future.
> > > >
> > > > [1]
> > > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html
> > > >
> > > > Fixes: bd55f96fa9fc ("kbuild: refactor cc-cross-prefix implementation")
> > > > Cc: linux-stable # 5.1
> > > > Reported-by: Alexey Brodkin
> > > > Signed-off-by: Masahiro Yamada
> > > > ---
> > > >
> > > > scripts/Kbuild.include | 5 -
> > > > 1 file changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
> > > > index 85d758233483..5a32ca80c3f6 100644
> > > > --- a/scripts/Kbuild.include
> > > > +++ b/scripts/Kbuild.include
> > > > @@ -74,8 +74,11 @@ endef
> > > > # Usage: CROSS_COMPILE := $(call cc-cross-prefix, m68k-linux-gnu-
> > > > m68k-linux-)
> > > > # Return first where a gcc is found in PATH.
> > > > # If no gcc found in PATH with listed prefixes return nothing
> > > > +#
> > > > +# Note: the special character '~' forces Make to invoke a shell. This
> > > > workaround
> > > > +# is needed because this issue was only fixed after GNU Make 4.2.1
> > > > release.
> > > > cc-cross-prefix = $(firstword $(foreach c, $(filter-out -%, $(1)), \
> > > > - $(if $(shell which $(c)gcc),
> > > > $(c
> > > > + $(if $(shell command -v $(c)gcc ~),
> > > > $(c
> > >
> > > I see a problem here:
> > > command -v foo bar
> > > could be deemed to be an error (extra argument).
> >
> > OK, the specification does not allow to pass arguments
> > with -v.
> >
> >
> > > You could use:
> > > $(shell sh -c "command -v $(c)gcc")
> > > or maybe:
> > > $(shell command$${x:+} -v $(c)gcc)
> >
> >
> > How about this?
> >
> > $(shell : ~; command -v $(c)gcc)
>
> Overcomplicated
>
> I've not looked at the list of 'special characters' in make,
> but I suspect any
Re: [PATCH v8 07/19] locking/rwsem: Implement lock handoff to prevent lock starvation
On Tue, 4 Jun 2019 at 11:03, Yuyang Du wrote: > > Hi Waiman, > > On Tue, 21 May 2019 at 05:01, Waiman Long wrote: > > > > Because of writer lock stealing, it is possible that a constant > > stream of incoming writers will cause a waiting writer or reader to > > wait indefinitely leading to lock starvation. > > > > This patch implements a lock handoff mechanism to disable lock stealing > > and force lock handoff to the first waiter or waiters (for readers) > > in the queue after at least a 4ms waiting period unless it is a RT > > writer task which doesn't need to wait. The waiting period is used to > > avoid discouraging lock stealing too much to affect performance. > > I was working on a patchset to solve read-write lock deadlock > detection problem (https://lkml.org/lkml/2019/5/16/93). > > One of the mistakes in that work is that I considered the following > case as deadlock: Sorry everyone, but let me rephrase: One of the mistakes in that work is that I considered the following case as no deadlock: > > T1T2 > ---- > > down_read1down_write2 > > down_write2 down_read1 > > So I was trying to understand what really went wrong and find the > problem is that if I understand correctly the current rwsem design > isn't showing real fairness but priority in favor of write locks, and > thus one of the bad effects is that read locks can be starved if write > locks keep coming. > > Luckily, I noticed you are revamping rwsem and seem to have thought > about it already. I am not crystal sure what is your work's > ramification on the above case, so hope that you can shed some light > and perhaps share your thoughts on this. > > Thanks, > Yuyang
Re: [PATCH 1/3] brcmfmac: re-enable command decode in sdio_aos for BRCM 4354
On 2019/5/29 上午 12:11, Arend Van Spriel wrote:
> On May 28, 2019 6:09:21 PM Arend Van Spriel
> wrote:
>
>> On May 28, 2019 5:52:10 PM Doug Anderson wrote:
>>
>>> Hi,
>>>
>>> On Tue, May 28, 2019 at 5:18 AM Kalle Valo wrote:
Douglas Anderson wrote:
> In commit 29f6589140a1 ("brcmfmac: disable command decode in
> sdio_aos") we disabled something called "command decode in sdio_aos"
> for a whole bunch of Broadcom SDIO WiFi parts.
>
> After that patch landed I find that my kernel log on
> rk3288-veyron-minnie and rk3288-veyron-speedy is filled with:
> brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep
state -110
>
> This seems to happen every time the Broadcom WiFi transitions out of
> sleep mode. Reverting the part of the commit that affects the
WiFi on
> my boards fixes the problem for me, so that's what this patch does.
>
> Note that, in general, the justification in the original commit
seemed
> a little weak. It looked like someone was testing on a SD card
> controller that would sometimes die if there were CRC errors on the
> bus. This used to happen back in early days of dw_mmc (the
controller
> on my boards), but we fixed it. Disabling a feature on all boards
> just because one SD card controller is broken seems bad. ...so
> instead of just this patch possibly the right thing to do is to fully
> revert the original commit.
>
Since the commit 29f6589140a1 ("brcmfmac: disable command decode in
sdio_aos") causes the regression on other SD card controller, it is
better to revert it as you mentioned.
Actually, without the commit, we hit MMC timeout(-110) and hanged
instead of CRC error in our test. Would you please share the analysis of
dw_mmc issue which you fixed? We'd like to compare whether we got the
same issue.
Regards,
Wright
> Fixes: 29f6589140a1 ("brcmfmac: disable command decode in sdio_aos")
> Signed-off-by: Douglas Anderson
I don't see patch 2 in patchwork and I assume discussion continues.
>>>
>>> Apologies. I made sure to CC you individually on all the patches but
>>> didn't think about the fact that you use patchwork to manage and so
>>> didn't ensure all patches made it to all lists (by default each patch
>>> gets recipients individually from get_maintainer). I'll make sure to
>>> fix for patch set #2. If you want to see all the patches, you can at
>>> least find them on lore.kernel.org linked from the cover:
>>>
>>> https://lore.kernel.org/patchwork/cover/1075373/
>>>
>>>
Please resend if/when I need to apply something.
2 patches set to Changes Requested.
10948785 [1/3] brcmfmac: re-enable command decode in sdio_aos for
BRCM 4354
>>>
>>> As per Arend I'll change patch #1 to a full revert instead of a
>>> partial revert. Arend: please yell if you want otherwise.
>>
>> No yelling here. If any it is expected from Cypress. Maybe good to add
>> them
>> specifically in Cc:
>
> Of the revert patch that is.
>
> Gr. AvS
>
>
Re: [PATCH bpf v2] bpf: preallocate a perf_sample_data per event fd
On Tue, 2019-06-04 at 02:43 +0200, Daniel Borkmann wrote: > On 06/04/2019 01:54 AM, Alexei Starovoitov wrote: > > On Mon, Jun 3, 2019 at 4:48 PM Daniel Borkmann wrote: > > > On 06/04/2019 01:27 AM, Alexei Starovoitov wrote: > > > > On Mon, Jun 3, 2019 at 3:59 PM Matt Mullins wrote: > > > > > > > > > > If these are invariably non-nested, I can easily keep bpf_misc_sd when > > > > > I resubmit. There was no technical reason other than keeping the two > > > > > codepaths as similar as possible. > > > > > > > > > > What resource gives you worry about doing this for the networking > > > > > codepath? > > > > > > > > my preference would be to keep tracing and networking the same. > > > > there is already minimal nesting in networking and probably we see > > > > more when reuseport progs will start running from xdp and clsbpf > > > > > > > > > > Aside from that it's also really bad to miss events like this as > > > > > > exporting > > > > > > through rb is critical. Why can't you have a per-CPU counter that > > > > > > selects a > > > > > > sample data context based on nesting level in tracing? (I don't see > > > > > > a discussion > > > > > > of this in your commit message.) > > > > > > > > > > This change would only drop messages if the same perf_event is > > > > > attempted to be used recursively (i.e. the same CPU on the same > > > > > PERF_EVENT_ARRAY map, as I haven't observed anything use index != > > > > > BPF_F_CURRENT_CPU in testing). > > > > > > > > > > I'll try to accomplish the same with a percpu nesting level and > > > > > allocating 2 or 3 perf_sample_data per cpu. I think that'll solve the > > > > > same problem -- a local patch keeping track of the nesting level is > > > > > how > > > > > I got the above stack trace, too. > > > > > > > > I don't think counter approach works. The amount of nesting is unknown. > > > > imo the approach taken in this patch is good. > > > > I don't see any issue when event_outputs will be dropped for valid > > > > progs. > > > > Only when user called the helper incorrectly without BPF_F_CURRENT_CPU. > > > > But that's an error anyway. > > > > > > My main worry with this xchg() trick is that we'll miss to export crucial > > > data with the EBUSY bailing out especially given nesting could increase in > > > future as you state, so users might have a hard time debugging this kind > > > of > > > issue if they share the same perf event map among these programs, and no > > > option to get to this data otherwise. Supporting nesting up to a certain > > > level would still be better than a lost event which is also not reported > > > through the usual way aka perf rb. Tracing can already be lossy: trace_call_bpf() silently simply doesn't call the prog and instead returns zero if bpf_prog_active != 1. > > > > I simply don't see this 'miss to export data' in all but contrived > > conditions. > > Say two progs share the same perf event array. > > One prog calls event_output and while rb logic is working > > another prog needs to start executing and use the same event array > > Correct. > > > slot. Today it's only possible for tracing prog combined with networking, > > but having two progs use the same event output array is pretty much > > a user bug. Just like not passing BPF_F_CURRENT_CPU. > > I don't see the user bug part, why should that be a user bug? It's the same > as if we would say that sharing a BPF hash map between networking programs > attached to different hooks or networking and tracing would be a user bug > which it is not. One concrete example would be cilium monitor where we > currently expose skb trace and drop events a well as debug data through > the same rb. This should be usable from any type that has perf_event_output > helper enabled (e.g. XDP and tc/BPF) w/o requiring to walk yet another per > cpu mmap rb from user space. Neither of these solutions would affect the behavior of sharing the perf array between networking programs -- since they're never called in a nested fashion, then you'll never hit the "xchg() returned NULL" at all. That said, I think I can logically limit nesting in tracing to 3 levels: - a kprobe or raw tp or perf event, - another one of the above that irq context happens to run, and - if we're really unlucky, the same in nmi at most one of which can be a kprobe or perf event. There is also a comment /* * bpf_raw_tp_regs are separate from bpf_pt_regs used from skb/xdp * to avoid potential recursive reuse issue when/if tracepoints are added * inside bpf_*_event_output, bpf_get_stackid and/or bpf_get_stack */ that suggests that one day bpf_perf_event_output might grow a static tracepoint. However, if the program attached to such a hypothetical tracepoint were to call bpf_perf_event_output, that would infinitely recurse ... it seems fine to let that case return -EBUSY as well. It does make me wonder if I should do the same nesting for the pt_regs. I've now got an experiment running with the counter
Re: [mm/vmalloc.c] 728e0fbf26: kernel_BUG_at_mm/vmalloc.c
Hi all,
On Tue, 4 Jun 2019 10:13:56 +0800 kernel test robot wrote:
>
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 728e0fbf263e3ed359c10cb13623390564102881 ("mm/vmalloc.c: get rid of
> one single unlink_va() when merge")
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
This has been widely reported and a fixed version of the patch is
included in today's linux-next.
--
Cheers,
Stephen Rothwell
pgpuf3xYg57SF.pgp
Description: OpenPGP digital signature
RE: [EXT] Re: [4.20 PATCH] Revert "mwifiex: restructure rx_reorder_tbl_lock usage"
Hi Brian, > >netif_rx_ni+0xe8/0x120 > >mwifiex_recv_packet+0xfc/0x10c [mwifiex] > >mwifiex_process_rx_packet+0x1d4/0x238 [mwifiex] > >mwifiex_11n_dispatch_pkt+0x190/0x1ac [mwifiex] > >mwifiex_11n_rx_reorder_pkt+0x28c/0x354 [mwifiex] > > TL;DR: the problem was right here ^^^ > where you started running mwifiex_11n_dispatch_pkt() (via > mwifiex_11n_scan_and_dispatch()) while holding a spinlock. > > When you do that, you eventually call netif_rx_ni(), which specifically defers > to softirq contexts. Then, if you happen to have your flush timer expiring > just > before that, you end up in mwifiex_flush_data(), which also needs that > spinlock. Understood; Thanks for this detail; > > There are a few possible ways to handle this: > (a) prevent processing softirqs in that context; e.g., with > local_bh_disable(). This seems somewhat of a hack. > (Side note: I think most of the locks in this driver really could be > spin_lock_bh(), not spin_lock_irqsave() -- we don't really care > about hardirq context for 99% of these locks.) > (b) restructure so that packet processing (e.g., netif_rx_ni()) is done > outside of the spinlock. > > It's actually not that hard to do (b). You can just queue your skb's up in a > temporary sk_buff_head list and process them all at once after you've > finished processing the reorder table. I have a local patch to do this, and I > might send it your way if I can give it a bit more testing. OK; That will be good; We will run a complete test after the patch; (OR we can work on this, share for review); Regards, Ganapathi
Re: [PATCH v8 07/19] locking/rwsem: Implement lock handoff to prevent lock starvation
Hi Waiman, On Tue, 21 May 2019 at 05:01, Waiman Long wrote: > > Because of writer lock stealing, it is possible that a constant > stream of incoming writers will cause a waiting writer or reader to > wait indefinitely leading to lock starvation. > > This patch implements a lock handoff mechanism to disable lock stealing > and force lock handoff to the first waiter or waiters (for readers) > in the queue after at least a 4ms waiting period unless it is a RT > writer task which doesn't need to wait. The waiting period is used to > avoid discouraging lock stealing too much to affect performance. I was working on a patchset to solve read-write lock deadlock detection problem (https://lkml.org/lkml/2019/5/16/93). One of the mistakes in that work is that I considered the following case as deadlock: T1T2 ---- down_read1down_write2 down_write2 down_read1 So I was trying to understand what really went wrong and find the problem is that if I understand correctly the current rwsem design isn't showing real fairness but priority in favor of write locks, and thus one of the bad effects is that read locks can be starved if write locks keep coming. Luckily, I noticed you are revamping rwsem and seem to have thought about it already. I am not crystal sure what is your work's ramification on the above case, so hope that you can shed some light and perhaps share your thoughts on this. Thanks, Yuyang
[PATCH] thermal: qoriq: add thermal monitor unit version 2 support
Thermal Monitor Unit v2 is introduced on new Layscape SoC.
Compared to v1, TMUv2 has a little different register layout
and digital output is fairly linear.
Signed-off-by: Yuantian Tang
---
drivers/thermal/qoriq_thermal.c | 122 +---
1 file changed, 98 insertions(+), 24 deletions(-)
diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c
index 3b5f5b3fb1bc..0df6dfddf804 100644
--- a/drivers/thermal/qoriq_thermal.c
+++ b/drivers/thermal/qoriq_thermal.c
@@ -13,6 +13,15 @@
#include "thermal_core.h"
#define SITES_MAX 16
+#define TMR_DISABLE0x0
+#define TMR_ME 0x8000
+#define TMR_ALPF 0x0c00
+#define TMR_ALPF_V20x0300
+#define TMTMIR_DEFAULT 0x000f
+#define TIER_DISABLE 0x0
+#define TEUMR0_V2 0x51009C00
+#define TMU_VER1 0x1
+#define TMU_VER2 0x2
/*
* QorIQ TMU Registers
@@ -23,17 +32,55 @@ struct qoriq_tmu_site_regs {
u8 res0[0x8];
};
-struct qoriq_tmu_regs {
+struct qoriq_tmu_regs_v2 {
+ u32 tmr;/* Mode Register */
+ u32 tsr;/* Status Register */
+ u32 tmsr; /* monitor site register */
+ u32 tmtmir; /* Temperature measurement interval Register */
+ u8 res0[0x10];
+ u32 tier; /* Interrupt Enable Register */
+ u32 tidr; /* Interrupt Detect Register */
+ u8 res1[0x8];
+ u32 tiiscr; /* interrupt immediate site capture register */
+ u32 tiascr; /* interrupt average site capture register */
+ u32 ticscr; /* Interrupt Critical Site Capture Register */
+ u32 res2;
+ u32 tmhtcr; /* monitor high temperature capture register */
+ u32 tmltcr; /* monitor low temperature capture register */
+ u32 tmrtrcr;/* monitor rising temperature rate capture register */
+ u32 tmftrcr;/* monitor falling temperature rate capture register */
+ u32 tmhtitr;/* High Temperature Immediate Threshold */
+ u32 tmhtatr;/* High Temperature Average Threshold */
+ u32 tmhtactr; /* High Temperature Average Crit Threshold */
+ u32 res3;
+ u32 tmltitr;/* monitor low temperature immediate threshold */
+ u32 tmltatr;/* monitor low temperature average threshold register */
+ u32 tmltactr; /* monitor low temperature average critical threshold */
+ u32 res4;
+ u32 tmrtrctr; /* monitor rising temperature rate critical threshold */
+ u32 tmftrctr; /* monitor falling temperature rate critical threshold*/
+ u8 res5[0x8];
+ u32 ttcfgr; /* Temperature Configuration Register */
+ u32 tscfgr; /* Sensor Configuration Register */
+ u8 res6[0x78];
+ struct qoriq_tmu_site_regs site[SITES_MAX];
+ u8 res7[0x9f8];
+ u32 ipbrr0; /* IP Block Revision Register 0 */
+ u32 ipbrr1; /* IP Block Revision Register 1 */
+ u8 res8[0x300];
+ u32 teumr0;
+ u32 teumr1;
+ u32 teumr2;
+ u32 res9;
+ u32 ttrcr[4]; /* Temperature Range Control Register */
+};
+
+struct qoriq_tmu_regs_v1 {
u32 tmr;/* Mode Register */
-#define TMR_DISABLE0x0
-#define TMR_ME 0x8000
-#define TMR_ALPF 0x0c00
u32 tsr;/* Status Register */
u32 tmtmir; /* Temperature measurement interval Register */
-#define TMTMIR_DEFAULT 0x000f
u8 res0[0x14];
u32 tier; /* Interrupt Enable Register */
-#define TIER_DISABLE 0x0
u32 tidr; /* Interrupt Detect Register */
u32 tiscr; /* Interrupt Site Capture Register */
u32 ticscr; /* Interrupt Critical Site Capture Register */
@@ -53,10 +100,7 @@ struct qoriq_tmu_regs {
u32 ipbrr0; /* IP Block Revision Register 0 */
u32 ipbrr1; /* IP Block Revision Register 1 */
u8 res6[0x310];
- u32 ttr0cr; /* Temperature Range 0 Control Register */
- u32 ttr1cr; /* Temperature Range 1 Control Register */
- u32 ttr2cr; /* Temperature Range 2 Control Register */
- u32 ttr3cr; /* Temperature Range 3 Control Register */
+ u32 ttrcr[4]; /* Temperature Range Control Register */
};
struct qoriq_tmu_data;
@@ -71,7 +115,9 @@ struct qoriq_sensor {
};
struct qoriq_tmu_data {
- struct qoriq_tmu_regs __iomem *regs;
+ int ver;
+ struct qoriq_tmu_regs_v1 __iomem *regs;
+ struct qoriq_tmu_regs_v2 __iomem *regv2;
bool little_endian;
struct qoriq_sensor *sensor[SITES_MAX];
};
@@ -111,7 +157,7 @@ static const struct thermal_zone_of_device_ops tmu_tz_ops =
{
static int qoriq_tmu_register_tmu_zone(struct platform_device *pdev)
{
struct qoriq_tmu_data
Re: [RFC V2 2/2] sched/fair: Fallback to sched-idle CPU if idle CPU isn't found
On 25-04-19, 15:07, Viresh Kumar wrote: > We target for an idle CPU in select_idle_sibling() to run the next task, > but in case we don't find idle CPUs it is better to pick a CPU which > will run the task the soonest, for performance reason. A CPU which isn't > idle but has only SCHED_IDLE activity queued on it should be a good > target based on this criteria as any normal fair task will most likely > preempt the currently running SCHED_IDLE task immediately. In fact, > choosing a SCHED_IDLE CPU shall give better results as it should be able > to run the task sooner than an idle CPU (which requires to be woken up > from an idle state). > > This patch updates the fast path to fallback to a sched-idle CPU if the > idle CPU isn't found, the slow path can be updated separately later. > > Following is the order in which select_idle_sibling() picks up next CPU > to run the task now: > > 1. idle_cpu(target) OR sched_idle_cpu(target) > 2. idle_cpu(prev) OR sched_idle_cpu(prev) > 3. idle_cpu(recent_used_cpu) OR sched_idle_cpu(recent_used_cpu) > 4. idle core(sd) > 5. idle_cpu(sd) > 6. sched_idle_cpu(sd) > 7. idle_cpu(p) - smt > 8. sched_idle_cpu(p)- smt > > Though the policy can be tweaked a bit if we want to have different > priorities. > > Signed-off-by: Viresh Kumar > --- > kernel/sched/fair.c | 28 +--- > 1 file changed, 21 insertions(+), 7 deletions(-) Hi Peter, I was looking to send V3 with the changes you suggested for the patch 1/2, are there any changes that I should be doing in this patch along with it ? -- viresh
Re: [PATCH 1/2] Input: synaptics-rmi4 - clear irqs before set irqs
Hi Christopher: Have got time to review these 2 patches? Users reported it works fine since I sent out this patch. Thanks, Aaron On 4/3/19 9:58 PM, Aaron Ma wrote: > Sure, take your time, if you have any questions let me know please. > > Thanks, > Aaron
Re: [PATCH 2/9] dt-bindings: mmc: sprd: Add another optional clock documentation
Hi Ulf, On Mon, 3 Jun 2019 at 21:34, Ulf Hansson wrote: > > On Mon, 20 May 2019 at 12:12, Baolin Wang wrote: > > > > For some Spreadtrum platforms like SC9860 platform, we should enable another > > gate clock '2x_enable' to make the SD host controller work well. Thus add > > documentation for this optional clock. > > > > Signed-off-by: Baolin Wang > > --- > > .../devicetree/bindings/mmc/sdhci-sprd.txt |1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/devicetree/bindings/mmc/sdhci-sprd.txt > > b/Documentation/devicetree/bindings/mmc/sdhci-sprd.txt > > index 45c9978..a285c77 100644 > > --- a/Documentation/devicetree/bindings/mmc/sdhci-sprd.txt > > +++ b/Documentation/devicetree/bindings/mmc/sdhci-sprd.txt > > @@ -14,6 +14,7 @@ Required properties: > > - clock-names: Should contain the following: > > "sdio" - SDIO source clock (required) > > "enable" - gate clock which used for enabling/disabling the device > > (required) > > + "2x_enable" - gate clock controlling the device for some special > > platforms (optional) > > This is a bit vague, could you please elaborate (and fold in that > information to the doc) on what kind of clock this is? Sorry for confusing. For some Spreadtrum platfroms like SC9860 platform, we should enable 2 gate clocks to enable SD host controller, that means we have 2 serialized clock gates. I know that's a little weird, but that's our clock's design. -- Baolin Wang Best Regards
RE: [v2, PATCH 3/4] net: stmmac: modify default value of tx-frames
On Mon, 2019-06-03 at 11:40 +, Jose Abreu wrote: > From: Biao Huang > > > the default value of tx-frames is 25, it's too late when > > passing tstamp to stack, then the ptp4l will fail: > > > > ptp4l -i eth0 -f gPTP.cfg -m > > ptp4l: selected /dev/ptp0 as PTP clock > > ptp4l: port 1: INITIALIZING to LISTENING on INITIALIZE > > ptp4l: port 0: INITIALIZING to LISTENING on INITIALIZE > > ptp4l: port 1: link up > > ptp4l: timed out while polling for tx timestamp > > ptp4l: increasing tx_timestamp_timeout may correct this issue, > >but it is likely caused by a driver bug > > ptp4l: port 1: send peer delay response failed > > ptp4l: port 1: LISTENING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) > > > > ptp4l tests pass when changing the tx-frames from 25 to 1 with > > ethtool -C option. > > It should be fine to set tx-frames default value to 1, so ptp4l will pass > > by default. > > I'm not sure if this is the right approach ... What's the timeout value > you have for TX Timestamp ? I use the default tx_timestamp_timeout value 1, which represents 1ms. do you try ptp4l on your side? performance test is done in https://lkml.org/lkml/2019/5/30/1617 and seems no performance degradation. > > Thanks, > Jose Miguel Abreu
[PATCH V4 5/6] csky: Fixup some error count in 810 & 860.
From: Guo Ren
CK810 pmu only support event with index 0-8 and 0xd; CK860 only
support event 1~4, 0xa~0x1b. So do not register unsupport event
to hardware cache event, which may leader to unknown behavior.
Signed-off-by: Guo Ren
Signed-off-by: Mao Han
Cc: Guo Ren
Cc: linux-c...@vger.kernel.org
---
arch/csky/kernel/perf_event.c | 60 ++-
1 file changed, 54 insertions(+), 6 deletions(-)
diff --git a/arch/csky/kernel/perf_event.c b/arch/csky/kernel/perf_event.c
index af09885..dc84dc7 100644
--- a/arch/csky/kernel/perf_event.c
+++ b/arch/csky/kernel/perf_event.c
@@ -737,6 +737,20 @@ static const int csky_pmu_hw_map[PERF_COUNT_HW_MAX] = {
#define CACHE_OP_UNSUPPORTED 0x
static const int csky_pmu_cache_map[C(MAX)][C(OP_MAX)][C(RESULT_MAX)] = {
[C(L1D)] = {
+#ifdef CONFIG_CPU_CK810
+ [C(OP_READ)] = {
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)]= CACHE_OP_UNSUPPORTED,
+ },
+ [C(OP_WRITE)] = {
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)]= CACHE_OP_UNSUPPORTED,
+ },
+ [C(OP_PREFETCH)] = {
+ [C(RESULT_ACCESS)] = 0x5,
+ [C(RESULT_MISS)]= 0x6,
+ },
+#else
[C(OP_READ)] = {
[C(RESULT_ACCESS)] = 0x14,
[C(RESULT_MISS)]= 0x15,
@@ -746,9 +760,10 @@ static const int
csky_pmu_cache_map[C(MAX)][C(OP_MAX)][C(RESULT_MAX)] = {
[C(RESULT_MISS)]= 0x17,
},
[C(OP_PREFETCH)] = {
- [C(RESULT_ACCESS)] = 0x5,
- [C(RESULT_MISS)]= 0x6,
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)]= CACHE_OP_UNSUPPORTED,
},
+#endif
},
[C(L1I)] = {
[C(OP_READ)] = {
@@ -765,6 +780,20 @@ static const int
csky_pmu_cache_map[C(MAX)][C(OP_MAX)][C(RESULT_MAX)] = {
},
},
[C(LL)] = {
+#ifdef CONFIG_CPU_CK810
+ [C(OP_READ)] = {
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)]= CACHE_OP_UNSUPPORTED,
+ },
+ [C(OP_WRITE)] = {
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)]= CACHE_OP_UNSUPPORTED,
+ },
+ [C(OP_PREFETCH)] = {
+ [C(RESULT_ACCESS)] = 0x7,
+ [C(RESULT_MISS)]= 0x8,
+ },
+#else
[C(OP_READ)] = {
[C(RESULT_ACCESS)] = 0x18,
[C(RESULT_MISS)]= 0x19,
@@ -774,29 +803,48 @@ static const int
csky_pmu_cache_map[C(MAX)][C(OP_MAX)][C(RESULT_MAX)] = {
[C(RESULT_MISS)]= 0x1b,
},
[C(OP_PREFETCH)] = {
- [C(RESULT_ACCESS)] = 0x7,
- [C(RESULT_MISS)]= 0x8,
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)]= CACHE_OP_UNSUPPORTED,
},
+#endif
},
[C(DTLB)] = {
+#ifdef CONFIG_CPU_CK810
[C(OP_READ)] = {
- [C(RESULT_ACCESS)] = 0x5,
- [C(RESULT_MISS)]= 0xb,
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)]= CACHE_OP_UNSUPPORTED,
},
[C(OP_WRITE)] = {
[C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
[C(RESULT_MISS)]= CACHE_OP_UNSUPPORTED,
},
+#else
+ [C(OP_READ)] = {
+ [C(RESULT_ACCESS)] = 0x14,
+ [C(RESULT_MISS)]= 0xb,
+ },
+ [C(OP_WRITE)] = {
+ [C(RESULT_ACCESS)] = 0x16,
+ [C(RESULT_MISS)]= 0xb,
+ },
+#endif
[C(OP_PREFETCH)] = {
[C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
[C(RESULT_MISS)]= CACHE_OP_UNSUPPORTED,
},
},
[C(ITLB)] = {
+#ifdef CONFIG_CPU_CK810
+ [C(OP_READ)] = {
+ [C(RESULT_ACCESS)] = CACHE_OP_UNSUPPORTED,
+ [C(RESULT_MISS)]= CACHE_OP_UNSUPPORTED,
+ },
+#else
[C(OP_READ)] = {
[C(RESULT_ACCESS)] = 0x3,
[C(RESULT_MISS)]= 0xa,
[PATCH V4 6/6] csky: Fix perf record in kernel/user space
csky_pmu_event_init is called several times during the perf record
initialzation. After configure the event counter in either kernel
space or user space, csky_pmu_event_init is called twice with no
attr specified. Configuration will be overwritten with sampling in
both kernel space and user space. --all-kernel/--all-user is
useless without this patch applied.
Signed-off-by: Mao Han
Cc: Guo Ren
Cc: linux-c...@vger.kernel.org
---
arch/csky/kernel/perf_event.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/csky/kernel/perf_event.c b/arch/csky/kernel/perf_event.c
index dc84dc7..e3308ab 100644
--- a/arch/csky/kernel/perf_event.c
+++ b/arch/csky/kernel/perf_event.c
@@ -983,6 +983,12 @@ static int csky_pmu_event_init(struct perf_event *event)
struct hw_perf_event *hwc = >hw;
int ret;
+ if (event->attr.type != PERF_TYPE_HARDWARE &&
+ event->attr.type != PERF_TYPE_HW_CACHE &&
+ event->attr.type != PERF_TYPE_RAW) {
+ return -ENOENT;
+ }
+
if (event->attr.exclude_user)
csky_pmu.hpcr = BIT(2);
else if (event->attr.exclude_kernel)
--
2.7.4
[PATCH V4 2/6] csky: Add count-width property for csky pmu
The csky pmu counter may have different io width. When the counter is
smaller then 64 bits and counter value is smaller than the old value, it
will result to a extremely large delta value. So the sampled value should
be extend to 64 bits to avoid this, the extension bits base on the
count-width property from dts.
Signed-off-by: Mao Han
Cc: Guo Ren
---
arch/csky/kernel/perf_event.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/csky/kernel/perf_event.c b/arch/csky/kernel/perf_event.c
index c022acc..36f7f20 100644
--- a/arch/csky/kernel/perf_event.c
+++ b/arch/csky/kernel/perf_event.c
@@ -9,6 +9,7 @@
#include
#define CSKY_PMU_MAX_EVENTS 32
+#define DEFAULT_COUNT_WIDTH 48
#define HPCR "<0, 0x0>" /* PMU Control reg */
#define HPCNTENR "<0, 0x4>" /* Count Enable reg */
@@ -18,6 +19,7 @@ static void
(*hw_raw_write_mapping[CSKY_PMU_MAX_EVENTS])(uint64_t val);
struct csky_pmu_t {
struct pmu pmu;
+ uint32_tcount_width;
uint32_thpcr;
} csky_pmu;
@@ -806,7 +808,12 @@ static void csky_perf_event_update(struct perf_event
*event,
struct hw_perf_event *hwc)
{
uint64_t prev_raw_count = local64_read(>prev_count);
- uint64_t new_raw_count = hw_raw_read_mapping[hwc->idx]();
+ /*
+* Sign extend count value to 64bit, otherwise delta calculation
+* would be incorrect when overflow occurs.
+*/
+ uint64_t new_raw_count = sign_extend64(
+ hw_raw_read_mapping[hwc->idx](), csky_pmu.count_width);
int64_t delta = new_raw_count - prev_raw_count;
/*
@@ -1045,6 +1052,11 @@ int csky_pmu_device_probe(struct platform_device *pdev,
ret = init_fn(_pmu);
}
+ if (!of_property_read_u32(node, "count-width",
+ _pmu.count_width)) {
+ csky_pmu.count_width = DEFAULT_COUNT_WIDTH;
+ }
+
if (ret) {
pr_notice("[perf] failed to probe PMU!\n");
return ret;
--
2.7.4
[PATCH V4 4/6] dt-bindings: csky: Add csky PMU bindings
This patch adds the documentation to describe that how to add pmu node in
dts.
Signed-off-by: Mao Han
Cc: Rob Herring
Cc: Guo Ren
---
Documentation/devicetree/bindings/csky/pmu.txt | 38 ++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/csky/pmu.txt
diff --git a/Documentation/devicetree/bindings/csky/pmu.txt
b/Documentation/devicetree/bindings/csky/pmu.txt
new file mode 100644
index 000..53c3b0a
--- /dev/null
+++ b/Documentation/devicetree/bindings/csky/pmu.txt
@@ -0,0 +1,38 @@
+
+C-SKY Performance Monitor Units
+
+
+C-SKY 8xx series cores often have a PMU for counting cpu and cache events.
+The C-SKY PMU representation in the device tree should be done as under:
+
+==
+PMU node bindings definition
+==
+
+ Description: Describes PMU
+
+ PROPERTIES
+
+ - compatible
+ Usage: required
+ Value type:
+ Definition: must be "csky,csky-pmu"
+ - interrupts
+ Usage: required
+ Value type:
+ Definition: must be pmu irq num defined by soc
+ - count-width
+ Usage: optional
+ Value type:
+ Definition: the width of pmu counter
+
+Examples:
+-
+
+pmu {
+compatible = "csky,csky-pmu";
+interrupts = <0x17 IRQ_TYPE_EDGE_RISING>;
+interrupt-parent = <>;
+ count-width = <0x30>;
+};
+
--
2.7.4
[PATCH V4 3/6] csky: Add pmu interrupt support
This patch add interrupt request and handler for csky pmu.
perf can record on hardware event with this patch applied.
Signed-off-by: Mao Han
Cc: Guo Ren
---
arch/csky/kernel/perf_event.c | 292 +++---
1 file changed, 276 insertions(+), 16 deletions(-)
diff --git a/arch/csky/kernel/perf_event.c b/arch/csky/kernel/perf_event.c
index 36f7f20..af09885 100644
--- a/arch/csky/kernel/perf_event.c
+++ b/arch/csky/kernel/perf_event.c
@@ -11,18 +11,50 @@
#define CSKY_PMU_MAX_EVENTS 32
#define DEFAULT_COUNT_WIDTH 48
-#define HPCR "<0, 0x0>" /* PMU Control reg */
-#define HPCNTENR "<0, 0x4>" /* Count Enable reg */
+#define HPCR "<0, 0x0>" /* PMU Control reg */
+#define HPSPR "<0, 0x1>" /* Start PC reg */
+#define HPEPR "<0, 0x2>" /* End PC reg */
+#define HPSIR "<0, 0x3>" /* Soft Counter reg */
+#define HPCNTENR "<0, 0x4>" /* Count Enable reg */
+#define HPINTENR "<0, 0x5>" /* Interrupt Enable reg */
+#define HPOFSR "<0, 0x6>" /* Interrupt Status reg */
+
+/* The events for a given PMU register set. */
+struct pmu_hw_events {
+ /*
+* The events that are active on the PMU for the given index.
+*/
+ struct perf_event *events[CSKY_PMU_MAX_EVENTS];
+
+ /*
+* A 1 bit for an index indicates that the counter is being used for
+* an event. A 0 means that the counter can be used.
+*/
+ unsigned long used_mask[BITS_TO_LONGS(CSKY_PMU_MAX_EVENTS)];
+
+ /*
+* Hardware lock to serialize accesses to PMU registers. Needed for the
+* read/modify/write sequences.
+*/
+ raw_spinlock_t pmu_lock;
+};
static uint64_t (*hw_raw_read_mapping[CSKY_PMU_MAX_EVENTS])(void);
static void (*hw_raw_write_mapping[CSKY_PMU_MAX_EVENTS])(uint64_t val);
struct csky_pmu_t {
- struct pmu pmu;
- uint32_tcount_width;
- uint32_thpcr;
+ struct pmu pmu;
+ irqreturn_t (*handle_irq)(int irq_num);
+ void(*reset)(void *info);
+ struct pmu_hw_events __percpu *hw_events;
+ struct platform_device *plat_device;
+ uint32_tcount_width;
+ uint32_thpcr;
+ u64 max_period;
} csky_pmu;
+static int csky_pmu_irq;
+#define to_csky_pmu(p) (container_of(p, struct csky_pmu, pmu))
typedef int (*csky_pmu_init)(struct csky_pmu_t *);
#define cprgr(reg) \
@@ -804,6 +836,51 @@ static const int
csky_pmu_cache_map[C(MAX)][C(OP_MAX)][C(RESULT_MAX)] = {
},
};
+int csky_pmu_event_set_period(struct perf_event *event)
+{
+ struct hw_perf_event *hwc = >hw;
+ s64 left = local64_read(>period_left);
+ s64 period = hwc->sample_period;
+ int ret = 0;
+
+ if (unlikely(left <= -period)) {
+ left = period;
+ local64_set(>period_left, left);
+ hwc->last_period = period;
+ ret = 1;
+ }
+
+ if (unlikely(left <= 0)) {
+ left += period;
+ local64_set(>period_left, left);
+ hwc->last_period = period;
+ ret = 1;
+ }
+
+ if (left > (s64)csky_pmu.max_period)
+ left = csky_pmu.max_period;
+
+ /* Interrupt may lose when period is too small. */
+ if (left < 10)
+ left = 10;
+
+ /*
+* The hw event starts counting from this event offset,
+* mark it to be able to extract future "deltas":
+*/
+ local64_set(>prev_count, (u64)(-left));
+
+ if (hw_raw_write_mapping[hwc->idx] != NULL)
+ hw_raw_write_mapping[hwc->idx]((u64)(-left) &
+ csky_pmu.max_period);
+
+ cpwcr(HPOFSR, ~BIT(hwc->idx) & cprcr(HPOFSR));
+
+ perf_event_update_userpage(event);
+
+ return ret;
+}
+
static void csky_perf_event_update(struct perf_event *event,
struct hw_perf_event *hwc)
{
@@ -825,6 +902,11 @@ static void csky_perf_event_update(struct perf_event
*event,
local64_sub(delta, >period_left);
}
+static void csky_pmu_reset(void *info)
+{
+ cpwcr(HPCR, BIT(31) | BIT(30) | BIT(1));
+}
+
static void csky_pmu_read(struct perf_event *event)
{
csky_perf_event_update(event, >hw);
@@ -901,7 +983,9 @@ static void csky_pmu_disable(struct pmu *pmu)
static void csky_pmu_start(struct perf_event *event, int flags)
{
+ unsigned long irq_flags;
struct hw_perf_event *hwc = >hw;
+ struct pmu_hw_events *events = this_cpu_ptr(csky_pmu.hw_events);
int idx = hwc->idx;
if (WARN_ON_ONCE(idx == -1))
@@ -912,16 +996,35 @@ static void csky_pmu_start(struct perf_event *event, int
flags)
[PATCH V4 0/6] csky: Add pmu hardware sampling support
This patch set add hardware sampling support for csky-pmu, and also add some properties to pmu node definition. perf can record on hardware event with this patch applied. Cc: Guo Ren Changes since v3: - change reg-io-width to count-width - use macro sign_extend64 - update commit log Changes since v2: - update dt-binding(csky pmu use rising edge interrupt) - use cpuhp_setup_state to enable irq(fix irq enable on smp) Changes since v1: - do not update hpcr when event type is invalid(fix option --all-kernel/--all-user) Guo Ren (1): csky: Fixup some error count in 810 & 860. Mao Han (5): csky: Init pmu as a device csky: Add count-width property for csky pmu csky: Add pmu interrupt support dt-bindings: csky: Add csky PMU bindings csky: Fix perf record in kernel/user space Documentation/devicetree/bindings/csky/pmu.txt | 38 +++ arch/csky/kernel/perf_event.c | 424 +++-- 2 files changed, 441 insertions(+), 21 deletions(-) create mode 100644 Documentation/devicetree/bindings/csky/pmu.txt -- 2.7.4
[PATCH V4 1/6] csky: Init pmu as a device
This patch change the csky pmu initialization from arch init to
device init. The pmu can be configued with information from
device tree(pmu device name, irq number and etc.).
Signed-off-by: Mao Han
Cc: Guo Ren
---
arch/csky/kernel/perf_event.c | 58 ++-
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/arch/csky/kernel/perf_event.c b/arch/csky/kernel/perf_event.c
index 376c972..c022acc 100644
--- a/arch/csky/kernel/perf_event.c
+++ b/arch/csky/kernel/perf_event.c
@@ -21,6 +21,8 @@ struct csky_pmu_t {
uint32_thpcr;
} csky_pmu;
+typedef int (*csky_pmu_init)(struct csky_pmu_t *);
+
#define cprgr(reg) \
({ \
unsigned int tmp; \
@@ -1028,4 +1030,58 @@ int __init init_hw_perf_events(void)
return perf_pmu_register(_pmu.pmu, "cpu", PERF_TYPE_RAW);
}
-arch_initcall(init_hw_perf_events);
+
+int csky_pmu_device_probe(struct platform_device *pdev,
+ const struct of_device_id *of_table)
+{
+ const struct of_device_id *of_id;
+ csky_pmu_init init_fn;
+ struct device_node *node = pdev->dev.of_node;
+ int ret = -ENODEV;
+
+ of_id = of_match_node(of_table, pdev->dev.of_node);
+ if (node && of_id) {
+ init_fn = of_id->data;
+ ret = init_fn(_pmu);
+ }
+
+ if (ret) {
+ pr_notice("[perf] failed to probe PMU!\n");
+ return ret;
+ }
+
+ return ret;
+}
+
+const static struct of_device_id csky_pmu_of_device_ids[] = {
+ {.compatible = "csky,csky-pmu", .data = init_hw_perf_events},
+ {},
+};
+
+static int csky_pmu_dev_probe(struct platform_device *pdev)
+{
+ return csky_pmu_device_probe(pdev, csky_pmu_of_device_ids);
+}
+
+static struct platform_driver csky_pmu_driver = {
+ .driver = {
+ .name = "csky-pmu",
+ .of_match_table = csky_pmu_of_device_ids,
+ },
+ .probe = csky_pmu_dev_probe,
+};
+
+static int __init csky_pmu_probe(void)
+{
+ int ret;
+
+ ret = platform_driver_register(_pmu_driver);
+ if (ret)
+ pr_notice("[perf] PMU initialization failed\n");
+ else
+ pr_notice("[perf] PMU initialization done\n");
+
+ return ret;
+}
+
+device_initcall(csky_pmu_probe);
--
2.7.4
ATTENTION
-- Dear Beneficiary, The is to bring to your notice that the Department of Treasury Office in Nigeria in affiliation with the Federal Government of Nigeria,and the Office of Foreign Assets Control here in Nigeria has been authorized in their sanction programs to compensate 1,000 scam victims who has being a victim of internet scam. The Federal Government of Nigeria in collaboration with the Department of the Treasury Office has decided to pay $1,000.000.00 USD(One Million United States Dollars) each in order to restore the global economy to the enviable standard of respectable persons that was scammed. Your names and particulars was mentioned by one of the syndicates who was arrested as one of the victims of their operations. Although to issue payments to the right persons we need you to reconfirm your information's to compare with what was given to us. Most importantly you are hereby warned not to communicate or duplicate this message to anyone or whatsoever as investigations are still ongoing in trace of the other criminals so therefore this information's should remain confidential to you alone and the agencies involved in the exercise. Finally all payments are done by AUTOMATED TELLER MACHINE(ATM), loaded with $1,000.000.00 with your names on the ATM CARD waiting to be sent to you reconfirmation of your information's on our desk. Best Regards Mr. Adams Bello Secretary's Desk E-mail: officeinfo1...@gmail.com
Re: [PATCH 8/9] mmc: sdhci-sprd: Add PHY DLL delay configuration
Hi Adrian,
On Mon, 3 Jun 2019 at 21:03, Adrian Hunter wrote:
>
> On 20/05/19 1:12 PM, Baolin Wang wrote:
> > Set the PHY DLL delay for each timing mode, which is used to sample the
> > clock
> > accurately and make the clock more stable.
> >
> > Signed-off-by: Baolin Wang
>
> One comment, nevertheless:
>
> Acked-by: Adrian Hunter
>
> > ---
> > drivers/mmc/host/sdhci-sprd.c | 51
> > +
> > 1 file changed, 51 insertions(+)
> >
> > diff --git a/drivers/mmc/host/sdhci-sprd.c b/drivers/mmc/host/sdhci-sprd.c
> > index e6eda13..911a09b 100644
> > --- a/drivers/mmc/host/sdhci-sprd.c
> > +++ b/drivers/mmc/host/sdhci-sprd.c
> > @@ -29,6 +29,8 @@
> > #define SDHCI_SPRD_DLL_INIT_COUNT 0xc00
> > #define SDHCI_SPRD_DLL_PHASE_INTERNAL 0x3
> >
> > +#define SDHCI_SPRD_REG_32_DLL_DLY0x204
> > +
> > #define SDHCI_SPRD_REG_32_DLL_DLY_OFFSET 0x208
> > #define SDHCIBSPRD_IT_WR_DLY_INVBIT(5)
> > #define SDHCI_SPRD_BIT_CMD_DLY_INV BIT(13)
> > @@ -72,6 +74,24 @@ struct sdhci_sprd_host {
> > struct clk *clk_2x_enable;
> > u32 base_rate;
> > int flags; /* backup of host attribute */
> > + u32 phy_delay[MMC_TIMING_MMC_HS400 + 2];
> > +};
> > +
> > +struct sdhci_sprd_phy_cfg {
> > + const char *property;
> > + u8 timing;
> > +};
> > +
> > +static const struct sdhci_sprd_phy_cfg sdhci_sprd_phy_cfgs[] = {
> > + { "sprd,phy-delay-legacy", MMC_TIMING_LEGACY, },
> > + { "sprd,phy-delay-sd-highspeed", MMC_TIMING_MMC_HS, },
>
> Did you mean MMC_TIMING_SD_HS
Ah, yes, my copy mistake and will fix it in next version.
Thanks for your reviewing and comments.
--
Baolin Wang
Best Regards
Re: [PATCH] ARM: mm: remove unused variables
On 2019/6/4 2:45, Krzysztof Kozlowski wrote:
> On Sun, 12 May 2019 at 13:51, YueHaibing wrote:
>>
>> Fix gcc warnings:
>>
>> arch/arm/mm/init.c: In function 'mem_init':
>> arch/arm/mm/init.c:456:13: warning: unused variable 'itcm_end'
>> [-Wunused-variable]
>> extern u32 itcm_end;
>> ^
>> arch/arm/mm/init.c:455:13: warning: unused variable 'dtcm_end'
>> [-Wunused-variable]
>> extern u32 dtcm_end;
>> ^
>>
>> They are not used any more since
>> commit 1c31d4e96b8c ("ARM: 8820/1: mm: Stop printing the virtual memory
>> layout")
>>
>> Signed-off-by: YueHaibing
>> ---
>> arch/arm/mm/init.c | 6 --
>> 1 file changed, 6 deletions(-)
>
> Reviewed-by: Krzysztof Kozlowski
>
> Did you submit it to Russell's patch system?
Thanks for your reminder, I will send it.
>
> Best regards,
> Krzysztof
>
> .
>
[PATCH V3 3/4] clk: imx: Add support for i.MX8MN clock driver
From: Anson Huang
This patch adds i.MX8MN clock driver support.
Signed-off-by: Anson Huang
---
Changes since V2:
- use platform driver model for this clock driver;
- add "const" to clock mux arrays.
---
drivers/clk/imx/Kconfig | 6 +
drivers/clk/imx/Makefile | 1 +
drivers/clk/imx/clk-imx8mn.c | 630 +++
3 files changed, 637 insertions(+)
create mode 100644 drivers/clk/imx/clk-imx8mn.c
diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig
index 0eaf418..1ac0c79 100644
--- a/drivers/clk/imx/Kconfig
+++ b/drivers/clk/imx/Kconfig
@@ -14,6 +14,12 @@ config CLK_IMX8MM
help
Build the driver for i.MX8MM CCM Clock Driver
+config CLK_IMX8MN
+ bool "IMX8MN CCM Clock Driver"
+ depends on ARCH_MXC && ARM64
+ help
+ Build the driver for i.MX8MN CCM Clock Driver
+
config CLK_IMX8MQ
bool "IMX8MQ CCM Clock Driver"
depends on ARCH_MXC && ARM64
diff --git a/drivers/clk/imx/Makefile b/drivers/clk/imx/Makefile
index 05641c6..77a3d71 100644
--- a/drivers/clk/imx/Makefile
+++ b/drivers/clk/imx/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_MXC_CLK_SCU) += \
clk-lpcg-scu.o
obj-$(CONFIG_CLK_IMX8MM) += clk-imx8mm.o
+obj-$(CONFIG_CLK_IMX8MN) += clk-imx8mn.o
obj-$(CONFIG_CLK_IMX8MQ) += clk-imx8mq.o
obj-$(CONFIG_CLK_IMX8QXP) += clk-imx8qxp.o clk-imx8qxp-lpcg.o
diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
new file mode 100644
index 000..3f09974
--- /dev/null
+++ b/drivers/clk/imx/clk-imx8mn.c
@@ -0,0 +1,630 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2018-2019 NXP.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "clk.h"
+
+static u32 share_count_sai2;
+static u32 share_count_sai3;
+static u32 share_count_sai5;
+static u32 share_count_sai6;
+static u32 share_count_sai7;
+static u32 share_count_disp;
+static u32 share_count_pdm;
+static u32 share_count_nand;
+
+enum {
+ ARM_PLL,
+ GPU_PLL,
+ VPU_PLL,
+ SYS_PLL1,
+ SYS_PLL2,
+ SYS_PLL3,
+ DRAM_PLL,
+ AUDIO_PLL1,
+ AUDIO_PLL2,
+ VIDEO_PLL2,
+ NR_PLLS,
+};
+
+static const struct imx_pll14xx_rate_table imx8mn_pll1416x_tbl[] = {
+ PLL_1416X_RATE(18U, 225, 3, 0),
+ PLL_1416X_RATE(16U, 200, 3, 0),
+ PLL_1416X_RATE(12U, 300, 3, 1),
+ PLL_1416X_RATE(10U, 250, 3, 1),
+ PLL_1416X_RATE(8U, 200, 3, 1),
+ PLL_1416X_RATE(75000U, 250, 2, 2),
+ PLL_1416X_RATE(7U, 350, 3, 2),
+ PLL_1416X_RATE(6U, 300, 3, 2),
+};
+
+static const struct imx_pll14xx_rate_table imx8mn_audiopll_tbl[] = {
+ PLL_1443X_RATE(786432000U, 655, 5, 2, 23593),
+ PLL_1443X_RATE(722534400U, 301, 5, 1, 3670),
+};
+
+static const struct imx_pll14xx_rate_table imx8mn_videopll_tbl[] = {
+ PLL_1443X_RATE(65000U, 325, 3, 2, 0),
+ PLL_1443X_RATE(59400U, 198, 2, 2, 0),
+};
+
+static const struct imx_pll14xx_rate_table imx8mn_drampll_tbl[] = {
+ PLL_1443X_RATE(65000U, 325, 3, 2, 0),
+};
+
+static struct imx_pll14xx_clk imx8mn_audio_pll = {
+ .type = PLL_1443X,
+ .rate_table = imx8mn_audiopll_tbl,
+};
+
+static struct imx_pll14xx_clk imx8mn_video_pll = {
+ .type = PLL_1443X,
+ .rate_table = imx8mn_videopll_tbl,
+};
+
+static struct imx_pll14xx_clk imx8mn_dram_pll = {
+ .type = PLL_1443X,
+ .rate_table = imx8mn_drampll_tbl,
+};
+
+static struct imx_pll14xx_clk imx8mn_arm_pll = {
+ .type = PLL_1416X,
+ .rate_table = imx8mn_pll1416x_tbl,
+};
+
+static struct imx_pll14xx_clk imx8mn_gpu_pll = {
+ .type = PLL_1416X,
+ .rate_table = imx8mn_pll1416x_tbl,
+};
+
+static struct imx_pll14xx_clk imx8mn_vpu_pll = {
+ .type = PLL_1416X,
+ .rate_table = imx8mn_pll1416x_tbl,
+};
+
+static struct imx_pll14xx_clk imx8mn_sys_pll = {
+ .type = PLL_1416X,
+ .rate_table = imx8mn_pll1416x_tbl,
+};
+
+static const char * const pll_ref_sels[] = { "osc_24m", "dummy", "dummy",
"dummy", };
+static const char * const audio_pll1_bypass_sels[] = {"audio_pll1",
"audio_pll1_ref_sel", };
+static const char * const audio_pll2_bypass_sels[] = {"audio_pll2",
"audio_pll2_ref_sel", };
+static const char * const video_pll1_bypass_sels[] = {"video_pll1",
"video_pll1_ref_sel", };
+static const char * const dram_pll_bypass_sels[] = {"dram_pll",
"dram_pll_ref_sel", };
+static const char * const gpu_pll_bypass_sels[] = {"gpu_pll",
"gpu_pll_ref_sel", };
+static const char * const vpu_pll_bypass_sels[] = {"vpu_pll",
"vpu_pll_ref_sel", };
+static const char * const arm_pll_bypass_sels[] = {"arm_pll",
"arm_pll_ref_sel", };
+static const char * const sys_pll1_bypass_sels[] = {"sys_pll1",
[PATCH V3 1/4] dt-bindings: imx: Add clock binding doc for i.MX8MN
From: Anson Huang
Add the clock binding doc for i.MX8MN.
Signed-off-by: Anson Huang
---
No changes.
---
.../devicetree/bindings/clock/imx8mn-clock.txt | 29 +++
include/dt-bindings/clock/imx8mn-clock.h | 215 +
2 files changed, 244 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/imx8mn-clock.txt
create mode 100644 include/dt-bindings/clock/imx8mn-clock.h
diff --git a/Documentation/devicetree/bindings/clock/imx8mn-clock.txt
b/Documentation/devicetree/bindings/clock/imx8mn-clock.txt
new file mode 100644
index 000..d83db5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx8mn-clock.txt
@@ -0,0 +1,29 @@
+* Clock bindings for NXP i.MX8M Nano
+
+Required properties:
+- compatible: Should be "fsl,imx8mn-ccm"
+- reg: Address and length of the register set
+- #clock-cells: Should be <1>
+- clocks: list of clock specifiers, must contain an entry for each required
+ entry in clock-names
+- clock-names: should include the following entries:
+- "osc_32k"
+- "osc_24m"
+- "clk_ext1"
+- "clk_ext2"
+- "clk_ext3"
+- "clk_ext4"
+
+clk: clock-controller@3038 {
+ compatible = "fsl,imx8mn-ccm";
+ reg = <0x0 0x3038 0x0 0x1>;
+ #clock-cells = <1>;
+ clocks = <_32k>, <_24m>, <_ext1>, <_ext2>,
+<_ext3>, <_ext4>;
+ clock-names = "osc_32k", "osc_24m", "clk_ext1", "clk_ext2",
+ "clk_ext3", "clk_ext4";
+};
+
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8mn-clock.h
+for the full list of i.MX8M Nano clock IDs.
diff --git a/include/dt-bindings/clock/imx8mn-clock.h
b/include/dt-bindings/clock/imx8mn-clock.h
new file mode 100644
index 000..5255b1c
--- /dev/null
+++ b/include/dt-bindings/clock/imx8mn-clock.h
@@ -0,0 +1,215 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2018-2019 NXP
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_IMX8MN_H
+#define __DT_BINDINGS_CLOCK_IMX8MN_H
+
+#define IMX8MN_CLK_DUMMY 0
+#define IMX8MN_CLK_32K 1
+#define IMX8MN_CLK_24M 2
+#define IMX8MN_OSC_HDMI_CLK3
+#define IMX8MN_CLK_EXT14
+#define IMX8MN_CLK_EXT25
+#define IMX8MN_CLK_EXT36
+#define IMX8MN_CLK_EXT47
+#define IMX8MN_AUDIO_PLL1_REF_SEL 8
+#define IMX8MN_AUDIO_PLL2_REF_SEL 9
+#define IMX8MN_VIDEO_PLL1_REF_SEL 10
+#define IMX8MN_DRAM_PLL_REF_SEL11
+#define IMX8MN_GPU_PLL_REF_SEL 12
+#define IMX8MN_VPU_PLL_REF_SEL 13
+#define IMX8MN_ARM_PLL_REF_SEL 14
+#define IMX8MN_SYS_PLL1_REF_SEL15
+#define IMX8MN_SYS_PLL2_REF_SEL16
+#define IMX8MN_SYS_PLL3_REF_SEL17
+#define IMX8MN_AUDIO_PLL1 18
+#define IMX8MN_AUDIO_PLL2 19
+#define IMX8MN_VIDEO_PLL1 20
+#define IMX8MN_DRAM_PLL21
+#define IMX8MN_GPU_PLL 22
+#define IMX8MN_VPU_PLL 23
+#define IMX8MN_ARM_PLL 24
+#define IMX8MN_SYS_PLL125
+#define IMX8MN_SYS_PLL226
+#define IMX8MN_SYS_PLL327
+#define IMX8MN_AUDIO_PLL1_BYPASS 28
+#define IMX8MN_AUDIO_PLL2_BYPASS 29
+#define IMX8MN_VIDEO_PLL1_BYPASS 30
+#define IMX8MN_DRAM_PLL_BYPASS 31
+#define IMX8MN_GPU_PLL_BYPASS 32
+#define IMX8MN_VPU_PLL_BYPASS 33
+#define IMX8MN_ARM_PLL_BYPASS 34
+#define IMX8MN_SYS_PLL1_BYPASS 35
+#define IMX8MN_SYS_PLL2_BYPASS 36
+#define IMX8MN_SYS_PLL3_BYPASS 37
+#define IMX8MN_AUDIO_PLL1_OUT 38
+#define IMX8MN_AUDIO_PLL2_OUT 39
+#define IMX8MN_VIDEO_PLL1_OUT 40
+#define IMX8MN_DRAM_PLL_OUT41
+#define IMX8MN_GPU_PLL_OUT 42
+#define IMX8MN_VPU_PLL_OUT 43
+#define IMX8MN_ARM_PLL_OUT 44
+#define IMX8MN_SYS_PLL1_OUT45
+#define IMX8MN_SYS_PLL2_OUT46
+#define IMX8MN_SYS_PLL3_OUT47
+#define IMX8MN_SYS_PLL1_40M48
+#define IMX8MN_SYS_PLL1_80M49
+#define IMX8MN_SYS_PLL1_100M 50
+#define IMX8MN_SYS_PLL1_133M 51
+#define IMX8MN_SYS_PLL1_160M 52
+#define IMX8MN_SYS_PLL1_200M 53
+#define IMX8MN_SYS_PLL1_266M 54
+#define IMX8MN_SYS_PLL1_400M
[PATCH V3 2/4] clk: imx8mm: Make 1416X/1443X PLL macro definitions common for usage
From: Anson Huang
1416X/1443X PLL are used on i.MX8MM and i.MX8MN and maybe
other i.MX8M series SoC later, the macro definitions of
these PLLs' initialization should be common for usage.
Signed-off-by: Anson Huang
---
New patch.
---
drivers/clk/imx/clk-imx8mm.c | 17 -
drivers/clk/imx/clk.h| 17 +
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index eb9fcf0..fecb3b2 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -26,23 +26,6 @@ static u32 share_count_dcss;
static u32 share_count_pdm;
static u32 share_count_nand;
-#define PLL_1416X_RATE(_rate, _m, _p, _s) \
- { \
- .rate = (_rate),\
- .mdiv = (_m), \
- .pdiv = (_p), \
- .sdiv = (_s), \
- }
-
-#define PLL_1443X_RATE(_rate, _m, _p, _s, _k) \
- { \
- .rate = (_rate),\
- .mdiv = (_m), \
- .pdiv = (_p), \
- .sdiv = (_s), \
- .kdiv = (_k), \
- }
-
static const struct imx_pll14xx_rate_table imx8mm_pll1416x_tbl[] = {
PLL_1416X_RATE(18U, 225, 3, 0),
PLL_1416X_RATE(16U, 200, 3, 0),
diff --git a/drivers/clk/imx/clk.h b/drivers/clk/imx/clk.h
index 6dcdc91..ac8c4ae 100644
--- a/drivers/clk/imx/clk.h
+++ b/drivers/clk/imx/clk.h
@@ -81,6 +81,23 @@ enum imx_pllv3_type {
IMX_PLLV3_AV_IMX7,
};
+#define PLL_1416X_RATE(_rate, _m, _p, _s) \
+ { \
+ .rate = (_rate),\
+ .mdiv = (_m), \
+ .pdiv = (_p), \
+ .sdiv = (_s), \
+ }
+
+#define PLL_1443X_RATE(_rate, _m, _p, _s, _k) \
+ { \
+ .rate = (_rate),\
+ .mdiv = (_m), \
+ .pdiv = (_p), \
+ .sdiv = (_s), \
+ .kdiv = (_k), \
+ }
+
struct clk *imx_clk_pllv3(enum imx_pllv3_type type, const char *name,
const char *parent_name, void __iomem *base, u32 div_mask);
--
2.7.4
[PATCH V3 4/4] arm64: defconfig: Select CONFIG_CLK_IMX8MN by default
From: Anson Huang Enable CONFIG_CLK_IMX8MN to support i.MX8MN clock driver. Signed-off-by: Anson Huang --- Changes since V2: - follow alphabet sequence. --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 8d4f25c..ae17f45 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -655,6 +655,7 @@ CONFIG_COMMON_CLK_S2MPS11=y CONFIG_CLK_QORIQ=y CONFIG_COMMON_CLK_PWM=y CONFIG_CLK_IMX8MM=y +CONFIG_CLK_IMX8MN=y CONFIG_CLK_IMX8MQ=y CONFIG_CLK_IMX8QXP=y CONFIG_TI_SCI_CLK=y -- 2.7.4
Re: [RFC PATCH 0/9] security: x86/sgx: SGX vs. LSM
On Mon, Jun 03, 2019 at 11:30:54AM -0700, Xing, Cedric wrote: > > From: Christopherson, Sean J > > Sent: Monday, June 03, 2019 10:16 AM > > > > On Sun, Jun 02, 2019 at 12:29:35AM -0700, Xing, Cedric wrote: > > > Hi Sean, > > > > > > Generally I agree with your direction but think ALLOW_* flags are > > > completely internal to LSM because they can be both produced and > > > consumed inside an LSM module. So spilling them into SGX driver and > > > also user mode code makes the solution ugly and in some cases > > > impractical because not every enclave host process has a priori > > > knowledge on whether or not an enclave page would be EMODPE'd at > > runtime. > > > > In this case, the host process should tag *all* pages it *might* convert > > to executable as ALLOW_EXEC. LSMs can (and should/will) be written in > > such a way that denying ALLOW_EXEC is fatal to the enclave if and only > > if the enclave actually attempts mprotect(PROT_EXEC). > > What if those pages contain self-modifying code but the host doesn't know > ahead of time? Would it require ALLOW_WRITE|ALLOW_EXEC at EADD? Then would it > prevent those pages to start with PROT_EXEC? Without ALLOW_WRITE+ALLOW_EXEC, the enclave would build and launch, but fail at mprotect(..., PROT_WRITE), e.g. when it attempted to gain write access to do self-modifying code. And it would would fail irrespective of LSM restrictions. > Anyway, my point is that it is unnecessary even if it works. Unnecessary in an ideal world, yes. Realistically, it's the least bad option. > > Take the SELinux path for example. The only scenario in which > > PROT_WRITE is cleared from @allowed_prot is if the page *starts* with > > PROT_EXEC. > > If PROT_EXEC is denied on a page that starts RW, e.g. an EAUG'd page, > > then PROT_EXEC will be cleared from @allowed_prot. > > > > As Stephen pointed out, auditing the denials on @allowed_prot means the > > log will contain false positives of a sort. But this is more of a noise > > issue than true false positives. E.g. there are three possible outcomes > > for the enclave. > > > > - The enclave does not do EMODPE[PROT_EXEC] in any scenario, ever. > > Requesting ALLOW_EXEC is either a straightforward a userspace bug or > > a poorly written generic enclave loader. > > > > - The enclave conditionally performs EMODPE[PROT_EXEC]. In this case > > the denial is a true false positive. > > > > - The enclave does EMODPE[PROT_EXEC] and its host userspace then fails > > on mprotect(PROT_EXEC), i.e. the LSM denial is working as intended. > > The audit log will be noisy, but viewed as a whole the denials > > aren't > > false positives. > > What I was talking about was EMODPE[PROT_WRITE] on an RX page. As above, mprotect(..., PROT_WRITE) would fail without ALLOW_WRITE. > > The potential for noisy audit logs and/or false positives is unfortunate, > > but it's (by far) the lesser of many evils. > > > > > Theoretically speaking, what you really need is a per page flag (let's > > > name it WRITTEN?) indicating whether a page has ever been written to > > > (or more precisely, granted PROT_WRITE), which will be used to decide > > > whether to grant PROT_EXEC when requested in future. Given the fact > > > that all mprotect() goes through LSM and mmap() is limited to > > > PROT_NONE, it's easy for LSM to capture that flag by itself instead of > > asking user mode code to provide it. > > > > > > That said, here is the summary of what I think is a better approach. > > > * In hook security_file_alloc(), if @file is an enclave, allocate some > > data > > > structure to store for every page, the WRITTEN flag as described > > above. > > > WRITTEN is cleared initially for all pages. > > > > This would effectively require *every* LSM to duplicate the SGX driver's > > functionality, e.g. track per-page metadata, implement locking to > > prevent races between multiple mm structs, etc... > > Architecturally we shouldn't dictate how LSM makes decisions. ALLOW_* are no > difference than PROCESS__* or FILE__* flags, which are just artifacts to > assist particular LSMs in decision making. They are never considered part of > the LSM interface, even if other LSMs than SELinux may adopt the same/similar > approach. No, the flags are tracked and managed by SGX. We are not dictating LSM behavior in any way, e.g. an LSM could completely ignore @allowed_prot and nothing would break. > If code duplication is what you are worrying about, you can put them in a > library, or implement/export them in some new file (maybe > security/enclave.c?) as utility functions. Code duplication is the least of my concerns. Tracking file pointers would require a global list/tree of some form, along with a locking and/or RCU scheme to protect accesses to that container. Another lock would be needed to prevent races between mprotect() calls from different processes. > But spilling them into user mode is what I think is unacceptable. Why is
Re: [PATCH] extcon: gpio: Request reasonable interrupts
Hi Linus,
On 19. 5. 31. 오전 3:39, Linus Walleij wrote:
> The only thing that makes sense is to request a falling edge interrupt
> if the line is active low and a rising edge interrupt if the line is
> active high, so just do that and get rid of the assignment from
> platform data. The GPIO descriptor knows if the line is active high
> or low.
>
> Also make irq a local variable in probe(), it's not used anywhere else.
>
> Signed-off-by: Linus Walleij
> ---
> drivers/extcon/extcon-gpio.c | 27 ++-
> 1 file changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
> index 13ba3a6e81d5..a0674f1f3849 100644
> --- a/drivers/extcon/extcon-gpio.c
> +++ b/drivers/extcon/extcon-gpio.c
> @@ -30,26 +30,22 @@
> /**
> * struct gpio_extcon_data - A simple GPIO-controlled extcon device state
> container.
> * @edev:Extcon device.
> - * @irq: Interrupt line for the external connector.
> * @work:Work fired by the interrupt.
> * @debounce_jiffies:Number of jiffies to wait for the GPIO to
> stabilize, from the debounce
> * value.
> * @gpiod: GPIO descriptor for this external connector.
> * @extcon_id: The unique id of specific external connector.
> * @debounce:Debounce time for GPIO IRQ in ms.
> - * @irq_flags: IRQ Flags (e.g., IRQF_TRIGGER_LOW).
> * @check_on_resume: Boolean describing whether to check the state of gpio
> * while resuming from sleep.
> */
> struct gpio_extcon_data {
> struct extcon_dev *edev;
> - int irq;
> struct delayed_work work;
> unsigned long debounce_jiffies;
> struct gpio_desc *gpiod;
> unsigned int extcon_id;
> unsigned long debounce;
> - unsigned long irq_flags;
> bool check_on_resume;
> };
>
> @@ -77,6 +73,8 @@ static int gpio_extcon_probe(struct platform_device *pdev)
> {
> struct gpio_extcon_data *data;
> struct device *dev = >dev;
> + unsigned long irq_flags;
> + int irq;
> int ret;
>
> data = devm_kzalloc(dev, sizeof(struct gpio_extcon_data), GFP_KERNEL);
> @@ -96,9 +94,20 @@ static int gpio_extcon_probe(struct platform_device *pdev)
> data->gpiod = devm_gpiod_get(dev, "extcon", GPIOD_IN);
> if (IS_ERR(data->gpiod))
> return PTR_ERR(data->gpiod);
> - data->irq = gpiod_to_irq(data->gpiod);
> - if (data->irq <= 0)
> - return data->irq;
> + irq = gpiod_to_irq(data->gpiod);
> + if (irq <= 0)
> + return irq;
> +
> + /*
> + * It is unlikely that this is an acknowledged interrupt that goes
> + * away after handling, what we are looking for are falling edges
> + * if the signal is active low, and rising edges if the signal is
> + * active high.
> + */
> + if (gpiod_is_active_low(data->gpiod))
> + irq_flags = IRQF_TRIGGER_FALLING;
If gpiod_is_active_low(data->gpiod) is true, irq_flags might be
IRQF_TRIGGER_LOW instead of IRQF_TRIGGER_FALLING. How can we sure
that irq_flags is always IRQF_TRIGGER_FALLING?
> + else
> + irq_flags = IRQF_TRIGGER_RISING;
>
> /* Allocate the memory of extcon devie and register extcon device */
> data->edev = devm_extcon_dev_allocate(dev, >extcon_id);
> @@ -117,8 +126,8 @@ static int gpio_extcon_probe(struct platform_device *pdev)
>* Request the interrupt of gpio to detect whether external connector
>* is attached or detached.
>*/
> - ret = devm_request_any_context_irq(dev, data->irq,
> - gpio_irq_handler, data->irq_flags,
> + ret = devm_request_any_context_irq(dev, irq,
> + gpio_irq_handler, irq_flags,
> pdev->name, data);
> if (ret < 0)
> return ret;
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH] usbip: Replace unused kvec array with single variable in vhci_send_cmd_unlink()
On 6/3/19 9:02 AM, Suwan Kim wrote:
vhci_send_cmd_unlink() declears kvec array of size 3 but it actually
uses just one element of the array. So, remove kvec array and replace
it with single kvec variable.
Signed-off-by: Suwan Kim
---
drivers/usb/usbip/vhci_tx.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/usbip/vhci_tx.c b/drivers/usb/usbip/vhci_tx.c
index 9aed15a358b7..2fa26d0578d7 100644
--- a/drivers/usb/usbip/vhci_tx.c
+++ b/drivers/usb/usbip/vhci_tx.c
@@ -144,16 +144,14 @@ static int vhci_send_cmd_unlink(struct vhci_device *vdev)
struct vhci_unlink *unlink = NULL;
struct msghdr msg;
- struct kvec iov[3];
+ struct kvec iov;
size_t txsize;
-
size_t total_size = 0;
while ((unlink = dequeue_from_unlink_tx(vdev)) != NULL) {
int ret;
struct usbip_header pdu_header;
- txsize = 0;
memset(_header, 0, sizeof(pdu_header));
memset(, 0, sizeof(msg));
memset(, 0, sizeof(iov));
@@ -169,11 +167,11 @@ static int vhci_send_cmd_unlink(struct vhci_device *vdev)
usbip_header_correct_endian(_header, 1);
- iov[0].iov_base = _header;
- iov[0].iov_len = sizeof(pdu_header);
- txsize += sizeof(pdu_header);
+ iov.iov_base = _header;
+ iov.iov_len = sizeof(pdu_header);
+ txsize = sizeof(pdu_header);
- ret = kernel_sendmsg(vdev->ud.tcp_socket, , iov, 1, txsize);
+ ret = kernel_sendmsg(vdev->ud.tcp_socket, , , 1,
txsize);
if (ret != txsize) {
pr_err("sendmsg failed!, ret=%d for %zd\n", ret,
txsize);
Looks good to me.
Acked-by: Shuah Khan
thanks,
-- Shuah
Re: [PATCH 2/2] pinctrl: mediatek: Update cur_mask in mask/mask ops
On Mon, Jun 3, 2019 at 4:01 PM Chuanjia Liu wrote: > > On Fri, 2019-05-31 at 10:17 -0700, Evan Green wrote: > > On Fri, May 31, 2019 at 1:06 AM Chuanjia Liu > > wrote: > > > > > > On Thu, 2019-05-30 at 10:12 -0700, Evan Green wrote: > > > > On Wed, May 15, 2019 at 1:05 AM Nicolas Boichat > > > > wrote: > > > > > > > > > > On Wed, May 15, 2019 at 4:14 AM Stephen Boyd > > > > > wrote: > > > > > > > > > > > > Quoting Nicolas Boichat (2019-05-13 18:37:58) > > > > > > > On Tue, May 14, 2019 at 6:29 AM Stephen Boyd > > > > > > > wrote: > > > > > > > > > > > > > > > > Quoting Nicolas Boichat (2019-04-28 20:55:15) > > > > > > > > > During suspend/resume, mtk_eint_mask may be called while > > > > > > > > > wake_mask is active. For example, this happens if a > > > > > > > > > wake-source > > > > > > > > > with an active interrupt handler wakes the system: > > > > > > > > > irq/pm.c:irq_pm_check_wakeup would disable the interrupt, so > > > > > > > > > that it can be handled later on in the resume flow. > > > > > > > > > > > > > > > > > > However, this may happen before mtk_eint_do_resume is called: > > > > > > > > > in this case, wake_mask is loaded, and cur_mask is restored > > > > > > > > > from an older copy, re-enabling the interrupt, and causing > > > > > > > > > an interrupt storm (especially for level interrupts). > > > > > > > > > > > > > > > > > > Instead, we just record mask/unmask changes in cur_mask. This > > > > > > > > > also avoids the need to read the current mask in > > > > > > > > > eint_do_suspend, > > > > > > > > > and we can remove mtk_eint_chip_read_mask function. > > > > > > > > > > > > > > > > > > Signed-off-by: Nicolas Boichat > > > > > > > > > > > > > > > > It looks an awful lot like you should just use > > > > > > > > IRQCHIP_MASK_ON_SUSPEND > > > > > > > > here. Isn't that what's happening? All non-wake irqs should be > > > > > > > > masked at > > > > > > > > the hardware level so they can't cause a wakeup during suspend > > > > > > > > and on > > > > > > > > resume they can be unmasked? > > > > > > > > > > > > > > No, this is for an line that has both wake and interrupt enabled. > > > > > > > To > > > > > > > reword the commit message above: > > > > > > > > > > > > Is my understanding correct that there isn't a different "wake up" > > > > > > register that can be written to cause a GPIO to be configured to > > > > > > wake > > > > > > the system from suspend? The only way to do so is to leave the GPIO > > > > > > unmasked in the hardware by having EINT_EN[irq] = 1? And thus any > > > > > > interrupts that we don't want to wake us up during suspend should be > > > > > > masked in the hardware? > > > > > > > > > > Yes, that's my understanding as well. > > > > > > > > > > And then, what this driver does is to emulate the behaviour of a > > > > > controller that would actually have separate irq and wake enable > > > > > registers. > > > > > > > > > > > If that's true, the code here that's trying to keep track of enabled > > > > > > irqs and wakeup enabled irqs can be replaced with the irqchip flag > > > > > > so > > > > > > that wakeup irqs are not masked while non-wakeups are masked. > > > > > > > > > > Correct, but with the caveat that I don't see anything that definitely > > > > > requires an interrupt to be enabled to be a wake source. See below... > > > > > > > > > > > > > > > > > > 1. cur_mask[irq] = 1; wake_mask[irq] = 1; EINT_EN[irq] = 1 > > > > > > > (interrupt > > > > > > > enabled at hardware level) > > > > > > > 2. System suspends, resumes due to that line (at this stage > > > > > > > EINT_HW > > > > > > > == wake_mask) > > > > > > > 3. irq_pm_check_wakeup is called, and disables the interrupt => > > > > > > > EINT_EN[irq] = 0, but we still have cur_mask[irq] = 1 > > > > > > > 4. mtk_eint_do_resume is called, and restores EINT_EN = > > > > > > > cur_mask, so > > > > > > > it reenables EINT_EN[irq] = 1 => interrupt storm. > > > > > > > > > > > > > > This patch fixes the issue in step 3. So that the interrupt can be > > > > > > > re-enabled properly later on, sometimes after mtk_eint_do_resume, > > > > > > > when > > > > > > > the driver is ready to handle it. > > > > > > > > > > > > Right, we'd rather not see irqchip drivers working around the genirq > > > > > > layer to do these things like tracking cur_mask and wake_mask. That > > > > > > leads to subtle bugs and makes the driver maintain state across the > > > > > > irqchip callbacks and system suspend/resume. > > > > > > > > > > > > > > > > > > > > Also, IRQCHIP_MASK_ON_SUSPEND does not handle lines that are > > > > > > > enabled > > > > > > > as a wake source, but without interrupt enabled (e.g. cros_ec > > > > > > > driver > > > > > > > does that), which we do want to support. > > > > > > > > > > > > Hmm. I thought that even if the irq is disabled by a driver, that > > > > > > would > > > > > > be a lazy disable so it isn't really masked in the hardware. Then > > > > > > if an > > > > > >
Re: [PATCH bpf v2] bpf: preallocate a perf_sample_data per event fd
On Mon, Jun 3, 2019 at 5:44 PM Daniel Borkmann wrote: > > On 06/04/2019 01:54 AM, Alexei Starovoitov wrote: > > On Mon, Jun 3, 2019 at 4:48 PM Daniel Borkmann wrote: > >> On 06/04/2019 01:27 AM, Alexei Starovoitov wrote: > >>> On Mon, Jun 3, 2019 at 3:59 PM Matt Mullins wrote: > > If these are invariably non-nested, I can easily keep bpf_misc_sd when > I resubmit. There was no technical reason other than keeping the two > codepaths as similar as possible. > > What resource gives you worry about doing this for the networking > codepath? > >>> > >>> my preference would be to keep tracing and networking the same. > >>> there is already minimal nesting in networking and probably we see > >>> more when reuseport progs will start running from xdp and clsbpf > >>> > > Aside from that it's also really bad to miss events like this as > > exporting > > through rb is critical. Why can't you have a per-CPU counter that > > selects a > > sample data context based on nesting level in tracing? (I don't see a > > discussion > > of this in your commit message.) > > This change would only drop messages if the same perf_event is > attempted to be used recursively (i.e. the same CPU on the same > PERF_EVENT_ARRAY map, as I haven't observed anything use index != > BPF_F_CURRENT_CPU in testing). > > I'll try to accomplish the same with a percpu nesting level and > allocating 2 or 3 perf_sample_data per cpu. I think that'll solve the > same problem -- a local patch keeping track of the nesting level is how > I got the above stack trace, too. > >>> > >>> I don't think counter approach works. The amount of nesting is unknown. > >>> imo the approach taken in this patch is good. > >>> I don't see any issue when event_outputs will be dropped for valid progs. > >>> Only when user called the helper incorrectly without BPF_F_CURRENT_CPU. > >>> But that's an error anyway. > >> > >> My main worry with this xchg() trick is that we'll miss to export crucial > >> data with the EBUSY bailing out especially given nesting could increase in > >> future as you state, so users might have a hard time debugging this kind of > >> issue if they share the same perf event map among these programs, and no > >> option to get to this data otherwise. Supporting nesting up to a certain > >> level would still be better than a lost event which is also not reported > >> through the usual way aka perf rb. > > > > I simply don't see this 'miss to export data' in all but contrived > > conditions. > > Say two progs share the same perf event array. > > One prog calls event_output and while rb logic is working > > another prog needs to start executing and use the same event array > > Correct. > > > slot. Today it's only possible for tracing prog combined with networking, > > but having two progs use the same event output array is pretty much > > a user bug. Just like not passing BPF_F_CURRENT_CPU. > > I don't see the user bug part, why should that be a user bug? because I suspect that 'struct bpf_event_entry' is not reentrable (even w/o issues with 'struct perf_sample_data'). Even if we always use 'struct perf_sample_data' on stack, I suspect the same 'struct bpf_event_entry' cannot be reused in the nested way. > It's the same > as if we would say that sharing a BPF hash map between networking programs > attached to different hooks or networking and tracing would be a user bug > which it is not. One concrete example would be cilium monitor where we > currently expose skb trace and drop events a well as debug data through > the same rb. This should be usable from any type that has perf_event_output > helper enabled (e.g. XDP and tc/BPF) w/o requiring to walk yet another per > cpu mmap rb from user space. sure. those are valid use cases, but in all cases bpf_event_output() on particular 'struct bpf_event_entry' will end before another one will begin, no?
Re: [RFC PATCH 3/9] x86/sgx: Allow userspace to add multiple pages in single ioctl()
On Mon, Jun 03, 2019 at 04:48:47PM -0700, Xing, Cedric wrote:
> > How about this for the intermediate patch:
> >
> > struct sgx_enclave_add_region {
> > __u64 addr;
> > __u64 src;
> > __u64 size;
> > __u64 secinfo;
> > __u16 mrmask;
> > __u16 reserved16;
> > __u32 reserved;
> > }
> >
> > and with the flags field:
> >
> > struct sgx_enclave_add_region {
> > __u64 addr;
> > __u64 src;
> > __u64 size;
> > __u64 secinfo;
> > __u16 mrmask;
> > __u16 flags;
>
> What is "flags" here?
In the RFC, @flags holds SGX_ALLOW_{READ,WRITE,EXEC}.
>
> > __u32 reserved;
> > }
linux-next: manual merge of the nand tree with Linus' tree
Hi all,
Today's linux-next merge of the nand tree got a conflict in:
Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
between commit:
a5f2246fb913 ("dt: bindings: mtd: replace references to nand.txt with
nand-controller.yaml")
from Linus' tree and commit:
33cc5bd0b87a ("dt-bindings: mtd: brcmnand: Make nand-ecc-strength and
nand-ecc-step-size optional")
from the nand tree.
I fixed it up (the latter included the changes from the former, so I
just used that) and can carry the fix as necessary. This is now fixed
as far as linux-next is concerned, but any non trivial conflicts should
be mentioned to your upstream maintainer when your tree is submitted for
merging. You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpnrnfBoAEci.pgp
Description: OpenPGP digital signature
Re: [RFC PATCH 3/9] x86/sgx: Allow userspace to add multiple pages in single ioctl()
On Mon, Jun 03, 2019 at 04:45:45PM -0700, Xing, Cedric wrote:
> > From: Christopherson, Sean J
> > Sent: Monday, June 03, 2019 1:40 PM
> >
> > On Mon, Jun 03, 2019 at 01:08:04PM -0700, Sean Christopherson wrote:
> > > On Sun, Jun 02, 2019 at 11:26:09PM -0700, Xing, Cedric wrote:
> > > > > From: Christopherson, Sean J
> > > > > Sent: Friday, May 31, 2019 4:32 PM
> > > > >
> > > > > +/**
> > > > > + * sgx_ioc_enclave_add_pages - handler for
> > > > > +%SGX_IOC_ENCLAVE_ADD_PAGES
> > > > > + *
> > > > > + * @filep: open file to /dev/sgx
> > > > > + * @cmd: the command value
> > > > > + * @arg: pointer to an _enclave_add_page instance
> > > > > + *
> > > > > + * Add a range of pages to an uninitialized enclave (EADD), and
> > > > > +optionally
> > > > > + * extend the enclave's measurement with the contents of the page
> > (EEXTEND).
> > > > > + * The range of pages must be virtually contiguous. The SECINFO
> > > > > +and
> > > > > + * measurement maskare applied to all pages, i.e. pages with
> > > > > +different
> > > > > + * properties must be added in separate calls.
> > > > > + *
> > > > > + * EADD and EEXTEND are done asynchronously via worker threads.
> > > > > +A successful
> > > > > + * sgx_ioc_enclave_add_page() only indicates the pages have been
> > > > > +added to the
> > > > > + * work queue, it does not guarantee adding the pages to the
> > > > > +enclave will
> > > > > + * succeed.
> > > > > + *
> > > > > + * Return:
> > > > > + * 0 on success,
> > > > > + * -errno otherwise
> > > > > + */
> > > > > +static long sgx_ioc_enclave_add_pages(struct file *filep,
> > unsigned int cmd,
> > > > > + unsigned long arg)
> > > > > +{
> > > > > + struct sgx_enclave_add_pages *addp = (void *)arg;
> > > > > + struct sgx_encl *encl = filep->private_data;
> > > > > + struct sgx_secinfo secinfo;
> > > > > + unsigned int i;
> > > > > + int ret;
> > > > > +
> > > > > + if (copy_from_user(, (void __user *)addp->secinfo,
> > > > > +sizeof(secinfo)))
> > > > > + return -EFAULT;
> > > > > +
> > > > > + for (i = 0, ret = 0; i < addp->nr_pages && !ret; i++) {
> > > > > + if (signal_pending(current))
> > > > > + return -ERESTARTSYS;
> > > >
> > > > If interrupted, how would user mode code know how many pages have
> > been EADD'ed?
> > >
> > > Hmm, updating nr_pages would be fairly simple and shouldn't confuse
> > > userspace, e.g. as opposed to overloading the return value.
> >
> > Or maybe update @addr and @src as well? That would allow userspace to
> > re-invoke the ioctl() without having to modify the struct.
>
> How about returning the number of pages (or bytes) EADD'ed, similar to
> write() syscall?
I thought about that as well, but I think it'd be useful to update the
offset on any failure, not just -ERESTARTSYS.
Re: [PATCH v13 1/3] mfd: Add Renesas R-Car Gen3 RPC-IF MFD driver
Hi Jones,
> > +static int rpc_mfd_probe(struct platform_device *pdev)
>
> Remove the "mfd" from the nomenclature.
okay, will fix.
>
> > + struct device_node *flash;
> > + const struct mfd_cell *cell;
> > + struct resource *res;
> > + struct rpc_mfd *rpc;
> > + void __iomem *base;
> > +
> > + flash = of_get_next_child(pdev->dev.of_node, NULL);
> > + if (!flash) {
> > + dev_warn(>dev, "no flash node found\n");
> > + return -ENODEV;
> > + }
> > +
> > + if (of_device_is_compatible(flash, "jedec,spi-nor")) {
> > + cell = _spi_ctlr;
> > + } else if (of_device_is_compatible(flash, "cfi-flash")) {
> > + cell = _hf_ctlr;
> > + } else {
> > + dev_warn(>dev, "unknown flash type\n");
> > + return -ENODEV;
> > + }
>
> Are there going to be more children coming?
No, just spi-nor or cfi-flash.
The operation mode is decided at booting time by HW pin configuration.
Can't change spi-nor or cfi-flash mode at run-time.
>
> If not, I'd argue that this is not an MFD.
>
umm, agreed.
thanks & best regards,
Mason
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information
and/or personal data, which is protected by applicable laws. Please be
reminded that duplication, disclosure, distribution, or use of this e-mail
(and/or its attachments) or any part thereof is prohibited. If you receive
this e-mail in error, please notify us immediately and delete this mail as
well as its attachment(s) from your system. In addition, please be
informed that collection, processing, and/or use of personal data is
prohibited unless expressly permitted by personal data protection laws.
Thank you for your attention and cooperation.
Macronix International Co., Ltd.
=
CONFIDENTIALITY NOTE:
This e-mail and any attachments may contain confidential information and/or
personal data, which is protected by applicable laws. Please be reminded that
duplication, disclosure, distribution, or use of this e-mail (and/or its
attachments) or any part thereof is prohibited. If you receive this e-mail in
error, please notify us immediately and delete this mail as well as its
attachment(s) from your system. In addition, please be informed that
collection, processing, and/or use of personal data is prohibited unless
expressly permitted by personal data protection laws. Thank you for your
attention and cooperation.
Macronix International Co., Ltd.
=
Re: [PATCH v4 00/16] NVIDIA Tegra devfreq improvements and Tegra20/30 support
On 19. 6. 4. 오전 1:52, Dmitry Osipenko wrote: > 03.05.2019 3:52, Dmitry Osipenko пишет: >> 03.05.2019 3:31, Chanwoo Choi пишет: >>> Hi Dmitry, >>> >>> On 19. 5. 2. 오전 8:37, Dmitry Osipenko wrote: Changelog: v4: Addressed all review comments that were made by Chanwoo Choi to v3: - changed the driver removal order to match the probe exactly - added clarifying comment for 1/8 ratio to the Tegra20 driver Chanwoo, please also note that the clk patch that should fix compilation problem that was reported the kbuild-test-robot is already applied and available in the recent linux-next. >>> >>> I knew that Stephen picked up your path about clock. >> >> Hi Chanwoo, >> >> Okay, good. Thank you very much for reviewing this series! I assume it's >> too late now for v5.2, but it should be good to go for v5.3. >> > > Hello Chanwoo, > > Will be nice to see the patches in the linux-next before they'll hit > mainline. We have tested that > everything works fine on a selective devices, but won't hurt to get some > extra testing beforehand. > AFAIK, at least NVIDIA people are regularly testing -next on theirs dev > boards. Please note that > this not very important, so don't bother if there is some hurdle with pushing > to the tracking branch > for now. Also please let me know if you're expecting to see some ACK's on the > patches, I'm sure > we'll be able to work out that with Thierry and Jon if necessary. > > Hi Dmitry, I think that it is enough for applying to mainline branch. The devfreq.git is maintained by Myungjoo. He will be merged or reviewed if there are th remained review point. Hi Myungjoo, I reviewed the Dmitry's patches from v1 to v4 patches. And then I tested them on my testing branch[1] for catching the build warning and error. In result, it is clean. [1] https://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/linux.git/log/?h=devfreq-testing Please review or apply these patches for v5.3. -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH bpf v2] bpf: preallocate a perf_sample_data per event fd
On 06/04/2019 01:54 AM, Alexei Starovoitov wrote: > On Mon, Jun 3, 2019 at 4:48 PM Daniel Borkmann wrote: >> On 06/04/2019 01:27 AM, Alexei Starovoitov wrote: >>> On Mon, Jun 3, 2019 at 3:59 PM Matt Mullins wrote: If these are invariably non-nested, I can easily keep bpf_misc_sd when I resubmit. There was no technical reason other than keeping the two codepaths as similar as possible. What resource gives you worry about doing this for the networking codepath? >>> >>> my preference would be to keep tracing and networking the same. >>> there is already minimal nesting in networking and probably we see >>> more when reuseport progs will start running from xdp and clsbpf >>> > Aside from that it's also really bad to miss events like this as exporting > through rb is critical. Why can't you have a per-CPU counter that selects > a > sample data context based on nesting level in tracing? (I don't see a > discussion > of this in your commit message.) This change would only drop messages if the same perf_event is attempted to be used recursively (i.e. the same CPU on the same PERF_EVENT_ARRAY map, as I haven't observed anything use index != BPF_F_CURRENT_CPU in testing). I'll try to accomplish the same with a percpu nesting level and allocating 2 or 3 perf_sample_data per cpu. I think that'll solve the same problem -- a local patch keeping track of the nesting level is how I got the above stack trace, too. >>> >>> I don't think counter approach works. The amount of nesting is unknown. >>> imo the approach taken in this patch is good. >>> I don't see any issue when event_outputs will be dropped for valid progs. >>> Only when user called the helper incorrectly without BPF_F_CURRENT_CPU. >>> But that's an error anyway. >> >> My main worry with this xchg() trick is that we'll miss to export crucial >> data with the EBUSY bailing out especially given nesting could increase in >> future as you state, so users might have a hard time debugging this kind of >> issue if they share the same perf event map among these programs, and no >> option to get to this data otherwise. Supporting nesting up to a certain >> level would still be better than a lost event which is also not reported >> through the usual way aka perf rb. > > I simply don't see this 'miss to export data' in all but contrived conditions. > Say two progs share the same perf event array. > One prog calls event_output and while rb logic is working > another prog needs to start executing and use the same event array Correct. > slot. Today it's only possible for tracing prog combined with networking, > but having two progs use the same event output array is pretty much > a user bug. Just like not passing BPF_F_CURRENT_CPU. I don't see the user bug part, why should that be a user bug? It's the same as if we would say that sharing a BPF hash map between networking programs attached to different hooks or networking and tracing would be a user bug which it is not. One concrete example would be cilium monitor where we currently expose skb trace and drop events a well as debug data through the same rb. This should be usable from any type that has perf_event_output helper enabled (e.g. XDP and tc/BPF) w/o requiring to walk yet another per cpu mmap rb from user space.
Re: [PATCH v4 0/2] introduction of migration_version attribute for VFIO live migration
On Tue, Jun 04, 2019 at 03:29:32AM +0800, Alex Williamson wrote: > On Thu, 30 May 2019 20:44:38 -0400 > Yan Zhao wrote: > > > This patchset introduces a migration_version attribute under sysfs of VFIO > > Mediated devices. > > > > This migration_version attribute is used to check migration compatibility > > between two mdev devices of the same mdev type. > > > > Patch 1 defines migration_version attribute in > > Documentation/vfio-mediated-device.txt > > > > Patch 2 uses GVT as an example to show how to expose migration_version > > attribute and check migration compatibility in vendor driver. > > Thanks for iterating through this, it looks like we've settled on > something reasonable, but now what? This is one piece of the puzzle to > supporting mdev migration, but I don't think it makes sense to commit > this upstream on its own without also defining the remainder of how we > actually do migration, preferably with more than one working > implementation and at least prototyped, if not final, QEMU support. I > hope that was the intent, and maybe it's now time to look at the next > piece of the puzzle. Thanks, > > Alex Got it. Also thank you and all for discussing and guiding all along:) We'll move to the next episode now. Thanks Yan
Re: [PATCH] ARC: build: Try to guess CROSS_COMPILE with cc-cross-prefix
On Tue, Jun 4, 2019 at 1:27 AM Vineet Gupta wrote:
>
> On 6/2/19 11:31 PM, Alexey Brodkin wrote:
> > For a long time we used to hard-code CROSS_COMPILE prefix
> > for ARC until it started to cause problems, so we decided to
> > solely rely on CROSS_COMPILE externally set by a user:
> > commit 40660f1fcee8 ("ARC: build: Don't set CROSS_COMPILE in arch's
> > Makefile").
> >
> > While it works perfectly fine for build-systems where the prefix
> > gets defined anyways for us human beings it's quite an annoying
> > requirement especially given most of time the same one prefix
> > "arc-linux-" is all what we need.
> >
> > It looks like finally we're getting the best of both worlds:
> > 1. W/o cross-toolchain we still may install headers, build .dtb etc
> > 2. W/ cross-toolchain get the kerne built with only ARCH=arc
> >
> > Inspired by [1] & [2].
> >
> > [1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-May/005788.html
> > [2]
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc2b47b55f17
> >
> > A side note: even though "cc-cross-prefix" does its job it pollutes
> > console with output of "which" for all the prefixes it didn't manage to find
> > a matching cross-compiler for like that:
> > | # ARCH=arc make defconfig
> > | which: no arceb-linux-gcc in (~/.local/bin:~/bin:/usr/bin:/usr/sbin)
> > | *** Default configuration is based on 'nsim_hs_defconfig'
> >
> > Signed-off-by: Alexey Brodkin
> > Cc: Masahiro Yamada
> > Cc: Vineet Gupta
>
> Not a big deal but I'd propose we add "Suggested-by: vgupta" since that is
> where
> it came from.
>
> @Masahiro san I suppose you are OK with this, so perhaps an Ack etc would be
> nice
> to have.
FWIW,
Reviewed-by: Masahiro Yamada
--
Best Regards
Masahiro Yamada
[RESEND PATCH v1 2/5] driver core: Add device links support for pending links to suppliers
When consumer devices are added, they might not have a supplier device
to link to despite needing mandatory resources/functionality from one
or more suppliers. Add a waiting_for_suppliers list to track such
consumers and add helper functions to manage the list.
Marking/unmarking a consumer device as waiting for suppliers is
generally expected to be done by the entity that's creating the
device.
Signed-off-by: Saravana Kannan
---
drivers/base/core.c| 67 ++
include/linux/device.h | 5
2 files changed, 72 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index fd7511e04e62..9ab6782dda1c 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -44,6 +44,8 @@ early_param("sysfs.deprecated", sysfs_deprecated_setup);
#endif
/* Device links support. */
+static LIST_HEAD(wait_for_suppliers);
+static DEFINE_MUTEX(wfs_lock);
#ifdef CONFIG_SRCU
static DEFINE_MUTEX(device_links_lock);
@@ -401,6 +403,53 @@ struct device_link *device_link_add(struct device
*consumer,
}
EXPORT_SYMBOL_GPL(device_link_add);
+/**
+ * device_link_wait_for_supplier - Mark device as waiting for supplier
+ * @consumer: Consumer device
+ *
+ * Marks the consumer device as waiting for suppliers to become available. The
+ * consumer device will never be probed until it's unmarked as waiting for
+ * suppliers. The caller is responsible for adding the link to the supplier
+ * once the supplier device is present.
+ *
+ * This function is NOT meant to be called from the probe function of the
+ * consumer but rather from code that creates the consumer device.
+ */
+void device_link_wait_for_supplier(struct device *consumer)
+{
+ mutex_lock(_lock);
+ list_add_tail(>links.needs_suppliers, _for_suppliers);
+ mutex_unlock(_lock);
+}
+
+/**
+ * device_link_check_waiting_consumers - Try to unmark waiting consumers
+ * @add_suppliers: Callback function to add suppliers to waiting consumer
+ *
+ * Loops through all consumers waiting on suppliers and tries to add all their
+ * supplier links. If that succeeds, the consumer device is unmarked as waiting
+ * for suppliers. Otherwise, they are left marked as waiting on suppliers,
+ *
+ * The add_suppliers callback is expected to return 0 if it has found and added
+ * all the supplier links for the consumer device. It should return an error if
+ * it isn't able to do so.
+ *
+ * The caller of device_link_wait_for_supplier() is expected to call this once
+ * it's aware of potential suppliers becoming available.
+ */
+void device_link_check_waiting_consumers(
+ int (*add_suppliers)(struct device *consumer))
+{
+ struct device *dev, *tmp;
+
+ mutex_lock(_lock);
+ list_for_each_entry_safe(dev, tmp, _for_suppliers,
+links.needs_suppliers)
+ if (!add_suppliers(dev))
+ list_del_init(>links.needs_suppliers);
+ mutex_unlock(_lock);
+}
+
static void device_link_free(struct device_link *link)
{
while (refcount_dec_not_one(>rpm_active))
@@ -535,6 +584,19 @@ int device_links_check_suppliers(struct device *dev)
struct device_link *link;
int ret = 0;
+ /*
+* If a device is waiting for one or more suppliers (in
+* wait_for_suppliers list), it is not ready to probe yet. So just
+* return -EPROBE_DEFER without having to check the links with existing
+* suppliers.
+*/
+ mutex_lock(_lock);
+ if (!list_empty(>links.needs_suppliers)) {
+ mutex_unlock(_lock);
+ return -EPROBE_DEFER;
+ }
+ mutex_unlock(_lock);
+
device_links_write_lock();
list_for_each_entry(link, >links.suppliers, c_node) {
@@ -812,6 +874,10 @@ static void device_links_purge(struct device *dev)
{
struct device_link *link, *ln;
+ mutex_lock(_lock);
+ list_del(>links.needs_suppliers);
+ mutex_unlock(_lock);
+
/*
* Delete all of the remaining links from this device to any other
* devices (either consumers or suppliers).
@@ -1673,6 +1739,7 @@ void device_initialize(struct device *dev)
#endif
INIT_LIST_HEAD(>links.consumers);
INIT_LIST_HEAD(>links.suppliers);
+ INIT_LIST_HEAD(>links.needs_suppliers);
dev->links.status = DL_DEV_NO_DRIVER;
}
EXPORT_SYMBOL_GPL(device_initialize);
diff --git a/include/linux/device.h b/include/linux/device.h
index e85264fb6616..4e71e5386aae 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -887,11 +887,13 @@ enum dl_dev_state {
* struct dev_links_info - Device data related to device links.
* @suppliers: List of links to supplier devices.
* @consumers: List of links to consumer devices.
+ * @needs_suppliers: Hook to global list of devices waiting for suppliers.
* @status: Driver status information.
*/
struct dev_links_info {
struct list_head suppliers;
struct
[RESEND PATCH v1 5/5] driver core: Add sync_state driver/bus callback
This sync_state driver/bus callback is called once all the consumers
of a supplier have probed successfully.
This allows the supplier device's driver/bus to sync the supplier
device's state to the software state with the guarantee that all the
consumers are actively managing the resources provided by the supplier
device.
To maintain backwards compatibility and ease transition from existing
frameworks and resource cleanup schemes, late_initcall_sync is the
earliest when the sync_state callback might be called.
There is no upper bound on the time by which the sync_state callback
has to be called. This is because if a consumer device never probes,
the supplier has to maintain its resources in the state left by the
bootloader. For example, if the bootloader leaves the display
backlight at a fixed voltage and the backlight driver is never probed,
you don't want the backlight to ever be turned off after boot up.
Signed-off-by: Saravana Kannan
---
drivers/base/core.c| 39 +++
drivers/of/platform.c | 9 +
include/linux/device.h | 19 +++
3 files changed, 67 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 9ab6782dda1c..7a8777a33e8c 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -46,6 +46,7 @@ early_param("sysfs.deprecated", sysfs_deprecated_setup);
/* Device links support. */
static LIST_HEAD(wait_for_suppliers);
static DEFINE_MUTEX(wfs_lock);
+static bool supplier_sync_state_enabled;
#ifdef CONFIG_SRCU
static DEFINE_MUTEX(device_links_lock);
@@ -616,6 +617,41 @@ int device_links_check_suppliers(struct device *dev)
return ret;
}
+static void __device_links_supplier_sync_state(struct device *dev)
+{
+ struct device_link *link;
+
+ if (dev->state_synced)
+ return;
+
+ list_for_each_entry(link, >links.consumers, s_node) {
+ if (link->flags & DL_FLAG_STATELESS)
+ continue;
+ if (link->status != DL_STATE_ACTIVE)
+ return;
+ }
+
+ if (dev->bus->sync_state)
+ dev->bus->sync_state(dev);
+ else if (dev->driver && dev->driver->sync_state)
+ dev->driver->sync_state(dev);
+
+ dev->state_synced = true;
+}
+
+int device_links_supplier_sync_state(struct device *dev, void *data)
+{
+ device_links_write_lock();
+ __device_links_supplier_sync_state(dev);
+ device_links_write_unlock();
+ return 0;
+}
+
+void device_links_supplier_sync_state_enable(void)
+{
+ supplier_sync_state_enabled = true;
+}
+
/**
* device_links_driver_bound - Update device links after probing its driver.
* @dev: Device to update the links for.
@@ -660,6 +696,9 @@ void device_links_driver_bound(struct device *dev)
WARN_ON(link->status != DL_STATE_CONSUMER_PROBE);
WRITE_ONCE(link->status, DL_STATE_ACTIVE);
+
+ if (supplier_sync_state_enabled)
+ __device_links_supplier_sync_state(link->supplier);
}
dev->links.status = DL_DEV_DRIVER_BOUND;
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index da1aa52b310a..b5cce0c2496a 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -604,6 +604,15 @@ static int __init of_platform_default_populate_init(void)
return 0;
}
arch_initcall_sync(of_platform_default_populate_init);
+
+static int __init of_platform_sync_state_init(void)
+{
+ device_links_supplier_sync_state_enable();
+ bus_for_each_dev(_bus_type, NULL, NULL,
+device_links_supplier_sync_state);
+ return 0;
+}
+late_initcall_sync(of_platform_sync_state_init);
#endif
int of_platform_device_destroy(struct device *dev, void *data)
diff --git a/include/linux/device.h b/include/linux/device.h
index 4e71e5386aae..f6d5bba098df 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -79,6 +79,13 @@ extern void bus_remove_file(struct bus_type *, struct
bus_attribute *);
* that generate uevents to add the environment variables.
* @probe: Called when a new device or driver add to this bus, and callback
* the specific driver's probe to initial the matched device.
+ * @sync_state:Called to sync device state to software state after all
the
+ * state tracking consumers linked to this device (present at
+ * the time of late_initcall) have successfully bound to a
+ * driver. If the device has no consumers, this function will
+ * be called at late_initcall_sync level. If the device has
+ * consumers that are never bound to a driver, this function
+ * will never get called until they do.
* @remove:Called when a device removed from this bus.
* @shutdown: Called at shut-down time to quiesce the device.
*
@@ -122,6 +129,7 @@ struct bus_type {
int (*match)(struct
[RESEND PATCH v1 3/5] dt-bindings: Add depends-on property
The depends-on property is used to list the mandatory functional
dependencies of a consumer device on zero or more supplier devices.
Signed-off-by: Saravana Kannan
---
.../devicetree/bindings/depends-on.txt| 26 +++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/depends-on.txt
diff --git a/Documentation/devicetree/bindings/depends-on.txt
b/Documentation/devicetree/bindings/depends-on.txt
new file mode 100644
index ..1cbddd11cf17
--- /dev/null
+++ b/Documentation/devicetree/bindings/depends-on.txt
@@ -0,0 +1,26 @@
+Functional dependency linking
+=
+
+Apart from parent-child relationships, devices (consumers) often have
+functional dependencies on other devices (suppliers). Common examples of
+suppliers are clock, regulators, pinctrl, etc. However not all of them are
+dependencies with well defined devicetree bindings. Also, not all functional
+dependencies are mandatory as the device might be able to operate in a limited
+mode without some of the dependencies.
+
+The depends-on property allows marking these mandatory functional dependencies
+between one or more devices. The depends-on property is used by the consumer
+device to point to all its mandatory supplier devices.
+
+Optional properties:
+- depends-on: A list of phandles to mandatory suppliers of the device.
+
+
+Examples:
+Here, the device is dependent on only 2 of the 3 clock providers
+dev@40031000 {
+ compatible = "name";
+ reg = <0x40031000 0x1000>;
+ clocks = <_1 1>, <_2 7> <_3 5>;
+ depends-on = <_1>, <_3>;
+};
--
2.22.0.rc1.257.g3120a18244-goog
[RESEND PATCH v1 4/5] of/platform: Add functional dependency link from "depends-on" property
Add device-links after the devices are created (but before they are
probed) by looking at the "depends-on" DT property that allows
specifying mandatory functional dependencies between devices.
This property is used instead of existing DT properties that specify
phandles of other devices (Eg: clocks, pinctrl, regulators, etc). This
is because not all resources referred to by existing DT properties are
mandatory functional dependencies. Some devices/drivers might be able
to operate with reduced functionality when some of the resources
aren't available. For example, a device could operate in polling mode
if no IRQ is available, a device could skip doing power management if
clock or voltage control isn't available and they are left on, etc.
Automatically adding device-links for functional dependencies at the
framework level provides the following benefits:
- Optimizes device probe order and avoids the useless work of
attempting probes of devices that will not probe successfully
(because their suppliers aren't present or haven't probed yet).
For example, in a commonly available mobile SoC, registering just one
consumer device's driver at an initcall level earlier than the
supplier device's driver causes 11 failed probe attempts before the
consumer device probes successfully. This was with a kernel with all
the drivers statically compiled in. This problem gets a lot worse if
all the drivers are loaded as modules without direct symbol
dependencies.
- Supplier devices like clock providers, regulators providers, etc
need to keep the resources they provide active and at a particular
state(s) during boot up even if their current set of consumers don't
request the resource to be active. This is because the rest of the
consumers might not have probed yet and turning off the resource
before all the consumers have probed could lead to a hang or
undesired user experience.
Some frameworks (Eg: regulator) handle this today by turning off
"unused" resources at late_initcall_sync and hoping all the devices
have probed by then. This is not a valid assumption for systems with
loadable modules. Other frameworks (Eg: clock) just don't handle
this due to the lack of a clear signal for when they can turn off
resources. This leads to downstream hacks to handle cases like this
that can easily be solved in the upstream kernel.
By linking devices before they are probed, we give suppliers a clear
count of the number of dependent consumers. Once all of the consumers
are active, the suppliers can turn off the unused resources without
making assumptions about the number of consumers.
By default we just add device-links to track "driver presence" (probe
succeeded) of the supplier device. If any other functionality provided
by device-links are needed, it is left to the consumer/supplier devices
to change the link when they probe.
Signed-off-by: Saravana Kannan
---
drivers/of/platform.c | 46 +++
1 file changed, 46 insertions(+)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 1115a8d80a33..da1aa52b310a 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -74,6 +74,45 @@ struct platform_device *of_find_device_by_node(struct
device_node *np)
EXPORT_SYMBOL(of_find_device_by_node);
#ifdef CONFIG_OF_ADDRESS
+static int of_link_to_suppliers(struct device *dev)
+{
+ struct device_node *sup_node;
+ struct platform_device *sup_dev;
+ unsigned int i = 0, links = 0;
+ u32 dl_flags = DL_FLAG_AUTOPROBE_CONSUMER;
+
+ if (unlikely(!dev->of_node))
+ return 0;
+
+ while ((sup_node = of_parse_phandle(dev->of_node, "depends-on", i))) {
+ i++;
+ sup_dev = of_find_device_by_node(sup_node);
+ if (!sup_dev)
+ continue;
+ if (device_link_add(dev, _dev->dev, dl_flags))
+ links++;
+ put_device(_dev->dev);
+ }
+ if (links < i)
+ return -ENODEV;
+ return 0;
+}
+
+static void link_waiting_consumers_func(struct work_struct *work)
+{
+ device_link_check_waiting_consumers(of_link_to_suppliers);
+}
+static DECLARE_WORK(link_waiting_consumers_work, link_waiting_consumers_func);
+
+static bool link_waiting_consumers_enable;
+static void link_waiting_consumers_trigger(void)
+{
+ if (!link_waiting_consumers_enable)
+ return;
+
+ schedule_work(_waiting_consumers_work);
+}
+
/*
* The following routines scan a subtree and registers a device for
* each applicable node.
@@ -205,11 +244,14 @@ static struct platform_device
*of_platform_device_create_pdata(
dev->dev.platform_data = platform_data;
of_msi_configure(>dev, dev->dev.of_node);
+ if (of_link_to_suppliers(>dev))
+ device_link_wait_for_supplier(>dev);
if (of_device_add(dev) != 0) {
[RESEND PATCH v1 0/5] Solve postboot supplier cleanup and optimize probe ordering
Add a generic "depends-on" property that allows specifying mandatory functional dependencies between devices. Add device-links after the devices are created (but before they are probed) by looking at this "depends-on" property. This property is used instead of existing DT properties that specify phandles of other devices (Eg: clocks, pinctrl, regulators, etc). This is because not all resources referred to by existing DT properties are mandatory functional dependencies. Some devices/drivers might be able to operate with reduced functionality when some of the resources aren't available. For example, a device could operate in polling mode if no IRQ is available, a device could skip doing power management if clock or voltage control isn't available and they are left on, etc. So, adding mandatory functional dependency links between devices by looking at referred phandles in DT properties won't work as it would prevent probing devices that could be probed. By having an explicit depends-on property, we can handle these cases correctly. Having functional dependencies explicitly called out in DT and automatically added before the devices are probed, provides the following benefits: - Optimizes device probe order and avoids the useless work of attempting probes of devices that will not probe successfully (because their suppliers aren't present or haven't probed yet). For example, in a commonly available mobile SoC, registering just one consumer device's driver at an initcall level earlier than the supplier device's driver causes 11 failed probe attempts before the consumer device probes successfully. This was with a kernel with all the drivers statically compiled in. This problem gets a lot worse if all the drivers are loaded as modules without direct symbol dependencies. - Supplier devices like clock providers, regulators providers, etc need to keep the resources they provide active and at a particular state(s) during boot up even if their current set of consumers don't request the resource to be active. This is because the rest of the consumers might not have probed yet and turning off the resource before all the consumers have probed could lead to a hang or undesired user experience. Some frameworks (Eg: regulator) handle this today by turning off "unused" resources at late_initcall_sync and hoping all the devices have probed by then. This is not a valid assumption for systems with loadable modules. Other frameworks (Eg: clock) just don't handle this due to the lack of a clear signal for when they can turn off resources. This leads to downstream hacks to handle cases like this that can easily be solved in the upstream kernel. By linking devices before they are probed, we give suppliers a clear count of the number of dependent consumers. Once all of the consumers are active, the suppliers can turn off the unused resources without making assumptions about the number of consumers. By default we just add device-links to track "driver presence" (probe succeeded) of the supplier device. If any other functionality provided by device-links are needed, it is left to the consumer/supplier devices to change the link when they probe. Saravana Kannan (5): of/platform: Speed up of_find_device_by_node() driver core: Add device links support for pending links to suppliers dt-bindings: Add depends-on property of/platform: Add functional dependency link from "depends-on" property driver core: Add sync_state driver/bus callback .../devicetree/bindings/depends-on.txt| 26 + drivers/base/core.c | 106 ++ drivers/of/platform.c | 75 - include/linux/device.h| 24 include/linux/of.h| 3 + 5 files changed, 233 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/depends-on.txt -- 2.22.0.rc1.257.g3120a18244-goog
[RESEND PATCH v1 1/5] of/platform: Speed up of_find_device_by_node()
Add a pointer from device tree node to the device created from it.
This allows us to find the device corresponding to a device tree node
without having to loop through all the platform devices.
However, fallback to looping through the platform devices to handle
any devices that might set their own of_node.
Signed-off-by: Saravana Kannan
---
drivers/of/platform.c | 20 +++-
include/linux/of.h| 3 +++
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 04ad312fd85b..1115a8d80a33 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -42,6 +42,8 @@ static int of_dev_node_match(struct device *dev, void *data)
return dev->of_node == data;
}
+static DEFINE_SPINLOCK(of_dev_lock);
+
/**
* of_find_device_by_node - Find the platform_device associated with a node
* @np: Pointer to device tree node
@@ -55,7 +57,18 @@ struct platform_device *of_find_device_by_node(struct
device_node *np)
{
struct device *dev;
- dev = bus_find_device(_bus_type, NULL, np, of_dev_node_match);
+ /*
+* Spinlock needed to make sure np->dev doesn't get freed between NULL
+* check inside and kref count increment inside get_device(). This is
+* achieved by grabbing the spinlock before setting np->dev = NULL in
+* of_platform_device_destroy().
+*/
+ spin_lock(_dev_lock);
+ dev = get_device(np->dev);
+ spin_unlock(_dev_lock);
+ if (!dev)
+ dev = bus_find_device(_bus_type, NULL, np,
+ of_dev_node_match);
return dev ? to_platform_device(dev) : NULL;
}
EXPORT_SYMBOL(of_find_device_by_node);
@@ -196,6 +209,7 @@ static struct platform_device
*of_platform_device_create_pdata(
platform_device_put(dev);
goto err_clear_flag;
}
+ np->dev = >dev;
return dev;
@@ -556,6 +570,10 @@ int of_platform_device_destroy(struct device *dev, void
*data)
if (of_node_check_flag(dev->of_node, OF_POPULATED_BUS))
device_for_each_child(dev, NULL, of_platform_device_destroy);
+ /* Spinlock is needed for of_find_device_by_node() to work */
+ spin_lock(_dev_lock);
+ dev->of_node->dev = NULL;
+ spin_unlock(_dev_lock);
of_node_clear_flag(dev->of_node, OF_POPULATED);
of_node_clear_flag(dev->of_node, OF_POPULATED_BUS);
diff --git a/include/linux/of.h b/include/linux/of.h
index 0cf857012f11..f2b4912cbca1 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -48,6 +48,8 @@ struct property {
struct of_irq_controller;
#endif
+struct device;
+
struct device_node {
const char *name;
phandle phandle;
@@ -68,6 +70,7 @@ struct device_node {
unsigned int unique_id;
struct of_irq_controller *irq_trans;
#endif
+ struct device *dev; /* Device created from this node */
};
#define MAX_PHANDLE_ARGS 16
--
2.22.0.rc1.257.g3120a18244-goog
linux-next: manual merge of the net-next tree with Linus' tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/isdn/hisax/hfc_usb.c
between commit:
de6cc6515a44 ("treewide: Replace GPLv2 boilerplate/reference with SPDX - rule
153")
from Linus' tree and commit:
85993b8c9786 ("isdn: remove hisax driver")
from the net-next tree.
I fixed it up (I just removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgp_lVd0GtPsw.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the net-next tree with Linus' tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/isdn/gigaset/i4l.c
between commit:
2874c5fd2842 ("treewide: Replace GPLv2 boilerplate/reference with SPDX - rule
152")
from Linus' tree and commit:
8e6c8aa3b52e ("isdn: gigaset: remove i4l support")
from the net-next tree.
I fixed it up (I just removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpIZ7t5e2eTt.pgp
Description: OpenPGP digital signature
Re: [PATCH v2] scripts/checkstack.pl: Fix arm64 wrong or unknown architecture
On Mon, Jun 3, 2019 at 11:31 PM George G. Davis wrote:
>
> The following error occurs for the `make ARCH=arm64 checkstack` case:
>
> aarch64-linux-gnu-objdump -d vmlinux $(find . -name '*.ko') | \
> perl ./scripts/checkstack.pl arm64
> wrong or unknown architecture "arm64"
>
> As suggested by Masahiro Yamada, fix the above error using regular
> expressions in the same way it was fixed for the `ARCH=x86` case via
> commit fda9f9903be6 ("scripts/checkstack.pl: automatically handle
> 32-bit and 64-bit mode for ARCH=x86").
>
> Suggested-by: Masahiro Yamada
> Signed-off-by: George G. Davis
> ---
Applied to linux-kbuild/fixes. Thanks.
> v1:
> - https://patchwork.kernel.org/patch/10970393/
> v2:
> - Updates as Suggested-by: Masahiro Yamada
> - Update commit subject due to moving the fix from Makefile to
> checkstack.pl
> ---
> scripts/checkstack.pl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/checkstack.pl b/scripts/checkstack.pl
> index 122aef5e4e14..371bd17a4983 100755
> --- a/scripts/checkstack.pl
> +++ b/scripts/checkstack.pl
> @@ -46,7 +46,7 @@ my (@stack, $re, $dre, $x, $xs, $funcre);
> $x = "[0-9a-f]"; # hex character
> $xs = "[0-9a-f ]"; # hex character or space
> $funcre = qr/^$x* <(.*)>:$/;
> - if ($arch eq 'aarch64') {
> + if ($arch =~ '^(aarch|arm)64$') {
> #ffc0006325cc: a9bb7bfdstp x29, x30,
> [sp, #-80]!
> #a110: d11643ffsub sp, sp, #0x590
> $re = qr/^.*stp.*sp, \#-([0-9]{1,8})\]\!/o;
> --
> 2.7.4
>
--
Best Regards
Masahiro Yamada
Re: [PATCH 5/7] scsi: mac_scsi: Fix pseudo DMA implementation, take 2
On Tue, 4 Jun 2019, Michael Schmitz wrote: > Hi Finn, > > On 3/06/19 7:40 PM, Finn Thain wrote: > > > > > There are several other drivers that contain pieces of assembler code. > > > > > Does any driver contain assembler code for multiple architectures? I was > > trying to avoid that -- though admittedly I don't yet have actual code for > > the PDMA implementation for mac_scsi for Nubus PowerMacs. > > > I've seen that once, for one of the ESP drivers that were supported on both > m68k and ppc (APUS, PPC upgrade to Amiga computers). But that driver was > removed long ago (after 2.6?). > > In that case, the assembly file did reside in drivers/scsi/. That still > appears to be current practice (see drivers/scsi/arm/acornscsi-io.S). > The presence of that file would be an argument for adding drivers/scsi/m68k/. This seems to be begging the question. Since there's no clear policy, I'll combine the two files and avoid the question for now. -- > Cheers, > > ??? Michael > > >
Re: [PATCH v2] PCI: rpaphp: Avoid a sometimes-uninitialized warning
On 06/03/2019 03:11 PM, Nathan Chancellor wrote:
> When building with -Wsometimes-uninitialized, clang warns:
>
> drivers/pci/hotplug/rpaphp_core.c:243:14: warning: variable 'fndit' is
> used uninitialized whenever 'for' loop exits because its condition is
> false [-Wsometimes-uninitialized]
> for (j = 0; j < entries; j++) {
> ^~~
> drivers/pci/hotplug/rpaphp_core.c:256:6: note: uninitialized use occurs
> here
> if (fndit)
> ^
> drivers/pci/hotplug/rpaphp_core.c:243:14: note: remove the condition if
> it is always true
> for (j = 0; j < entries; j++) {
> ^~~
> drivers/pci/hotplug/rpaphp_core.c:233:14: note: initialize the variable
> 'fndit' to silence this warning
> int j, fndit;
> ^
> = 0
>
> fndit is only used to gate a sprintf call, which can be moved into the
> loop to simplify the code and eliminate the local variable, which will
> fix this warning.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/504
> Fixes: 2fcf3ae508c2 ("hotplug/drc-info: Add code to search ibm,drc-info
> property")
> Suggested-by: Nick Desaulniers
> Signed-off-by: Nathan Chancellor
Acked-by: Tyrel Datwyler
[PATCH v2 2/8] regulator: core: Parse max-spread value per regulator couple
Parse and validate max-spread value per regulator couple. Now regulator
core can take multiple regulator couples, although balancing is still
limited to a single couple.
Signed-off-by: Dmitry Osipenko
---
drivers/regulator/core.c | 13
drivers/regulator/of_regulator.c | 49 +--
include/linux/regulator/machine.h | 3 +-
3 files changed, 43 insertions(+), 22 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 3b2d10a46bb5..c148dd7d306e 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3435,7 +3435,7 @@ static int regulator_get_optimal_voltage(struct
regulator_dev *rdev,
struct coupling_desc *c_desc = >coupling_desc;
struct regulator_dev **c_rdevs = c_desc->coupled_rdevs;
struct regulation_constraints *constraints = rdev->constraints;
- int max_spread = constraints->max_spread;
+ int max_spread = constraints->max_spread[0];
int desired_min_uV = 0, desired_max_uV = INT_MAX;
int max_current_uV = 0, min_current_uV = INT_MAX;
int highest_min_uV = 0, target_uV, possible_uV;
@@ -3597,6 +3597,12 @@ static int regulator_balance_voltage(struct
regulator_dev *rdev,
if (coupler && coupler->balance_voltage)
return coupler->balance_voltage(coupler, rdev, state);
+ if (n_coupled > 2) {
+ rdev_err(rdev,
+"Voltage balancing for multiple regulator couples is
unimplemented\n");
+ return -EPERM;
+ }
+
for (i = 0; i < n_coupled; i++)
c_rdev_done[i] = false;
@@ -4849,11 +4855,6 @@ static int regulator_init_coupling(struct regulator_dev
*rdev)
return -EPERM;
}
- if (rdev->constraints->max_spread <= 0) {
- rdev_err(rdev, "wrong max_spread value\n");
- return -EPERM;
- }
-
if (!of_check_coupling_data(rdev))
return -EPERM;
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 0ead1164e4d6..41cf8819f60a 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -30,8 +30,14 @@ static void of_get_regulation_constraints(struct device_node
*np,
struct device_node *suspend_np;
unsigned int mode;
int ret, i, len;
+ int n_phandles;
+ u32 pvals[MAX_COUPLED];
u32 pval;
+ n_phandles = of_count_phandle_with_args(np, "regulator-coupled-with",
+ NULL);
+ n_phandles = max(n_phandles, 0);
+
constraints->name = of_get_property(np, "regulator-name", NULL);
if (!of_property_read_u32(np, "regulator-min-microvolt", ))
@@ -163,9 +169,12 @@ static void of_get_regulation_constraints(struct
device_node *np,
if (!of_property_read_u32(np, "regulator-system-load", ))
constraints->system_load = pval;
- if (!of_property_read_u32(np, "regulator-coupled-max-spread",
- ))
- constraints->max_spread = pval;
+ if (!of_property_read_u32_array(np, "regulator-coupled-max-spread",
+ pvals, n_phandles)) {
+
+ for (i = 0; i < n_phandles; i++)
+ constraints->max_spread[i] = pvals[i];
+ }
if (!of_property_read_u32(np, "regulator-max-step-microvolt",
))
@@ -473,7 +482,8 @@ int of_get_n_coupled(struct regulator_dev *rdev)
/* Looks for "to_find" device_node in src's "regulator-coupled-with" property
*/
static bool of_coupling_find_node(struct device_node *src,
- struct device_node *to_find)
+ struct device_node *to_find,
+ int *index)
{
int n_phandles, i;
bool found = false;
@@ -495,8 +505,10 @@ static bool of_coupling_find_node(struct device_node *src,
of_node_put(tmp);
- if (found)
+ if (found) {
+ *index = i;
break;
+ }
}
return found;
@@ -517,22 +529,28 @@ static bool of_coupling_find_node(struct device_node *src,
*/
bool of_check_coupling_data(struct regulator_dev *rdev)
{
- int max_spread = rdev->constraints->max_spread;
struct device_node *node = rdev->dev.of_node;
int n_phandles = of_get_n_coupled(rdev);
struct device_node *c_node;
+ int index;
int i;
bool ret = true;
- if (max_spread <= 0) {
- dev_err(>dev, "max_spread value invalid\n");
+ if (n_phandles >= MAX_COUPLED) {
+ dev_err(>dev, "please bump MAX_COUPLED number\n");
return false;
}
/* iterate over rdev's phandles */
for (i = 0; i < n_phandles; i++) {
+ int
[PATCH v2 6/8] regulator: core: Don't attach generic coupler to Tegra SoC regulators
Today generic coupler can't handle regulators coupling that is specific to
NVIDIA Tegra SoC's, hence don't allow generic coupler to attach to those
regulators. Later on it should be possible to switch at least Tegra20 to a
generic coupler, once all prerequisite bits will get resolved in upstream
(voltage management support by all drivers, etc).
Signed-off-by: Dmitry Osipenko
---
drivers/regulator/core.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 5a5b86d3edfb..68cccaf2e8f2 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -4866,6 +4866,16 @@ static int regulator_init_coupling(struct regulator_dev
*rdev)
static int generic_coupler_attach(struct regulator_coupler *coupler,
struct regulator_dev *rdev)
{
+ /*
+* Generic coupler isn't suitable for NVIVIA Tegra SoC's, at least
+* for now. Hence filter out the unwanted regulators as they shall be
+* managed by a platform-specific coupler.
+*/
+ if (of_property_read_bool(rdev->dev.of_node, "tegra-core-regulator") ||
+ of_property_read_bool(rdev->dev.of_node, "tegra-rtc-regulator") ||
+ of_property_read_bool(rdev->dev.of_node, "tegra-cpu-regulator"))
+ return -EPERM;
+
return 0;
}
--
2.21.0
[PATCH v2 3/8] regulator: core: Expose some of core functions
Expose some of internal functions that are required for implementation of
customized regulator couplers.
Signed-off-by: Dmitry Osipenko
---
drivers/regulator/core.c | 58 +++-
include/linux/regulator/driver.h | 11 ++
2 files changed, 38 insertions(+), 31 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index c148dd7d306e..5a5b86d3edfb 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -94,7 +94,6 @@ struct regulator_supply_alias {
static int _regulator_is_enabled(struct regulator_dev *rdev);
static int _regulator_disable(struct regulator *regulator);
-static int _regulator_get_voltage(struct regulator_dev *rdev);
static int _regulator_get_current_limit(struct regulator_dev *rdev);
static unsigned int _regulator_get_mode(struct regulator_dev *rdev);
static int _notifier_call_chain(struct regulator_dev *rdev,
@@ -103,15 +102,12 @@ static int _regulator_do_set_voltage(struct regulator_dev
*rdev,
int min_uV, int max_uV);
static int regulator_balance_voltage(struct regulator_dev *rdev,
suspend_state_t state);
-static int regulator_set_voltage_rdev(struct regulator_dev *rdev,
- int min_uV, int max_uV,
- suspend_state_t state);
static struct regulator *create_regulator(struct regulator_dev *rdev,
struct device *dev,
const char *supply_name);
static void _regulator_put(struct regulator *regulator);
-static const char *rdev_get_name(struct regulator_dev *rdev)
+const char *rdev_get_name(struct regulator_dev *rdev)
{
if (rdev->constraints && rdev->constraints->name)
return rdev->constraints->name;
@@ -425,8 +421,8 @@ static struct device_node *of_get_regulator(struct device
*dev, const char *supp
}
/* Platform voltage constraint check */
-static int regulator_check_voltage(struct regulator_dev *rdev,
- int *min_uV, int *max_uV)
+int regulator_check_voltage(struct regulator_dev *rdev,
+ int *min_uV, int *max_uV)
{
BUG_ON(*min_uV > *max_uV);
@@ -458,9 +454,9 @@ static int regulator_check_states(suspend_state_t state)
/* Make sure we select a voltage that suits the needs of all
* regulator consumers
*/
-static int regulator_check_consumers(struct regulator_dev *rdev,
-int *min_uV, int *max_uV,
-suspend_state_t state)
+int regulator_check_consumers(struct regulator_dev *rdev,
+ int *min_uV, int *max_uV,
+ suspend_state_t state)
{
struct regulator *regulator;
struct regulator_voltage *voltage;
@@ -571,7 +567,7 @@ static ssize_t regulator_uV_show(struct device *dev,
ssize_t ret;
regulator_lock(rdev);
- ret = sprintf(buf, "%d\n", _regulator_get_voltage(rdev));
+ ret = sprintf(buf, "%d\n", regulator_get_voltage_rdev(rdev));
regulator_unlock(rdev);
return ret;
@@ -942,7 +938,7 @@ static int drms_uA_update(struct regulator_dev *rdev)
rdev_err(rdev, "failed to set load %d\n", current_uA);
} else {
/* get output voltage */
- output_uV = _regulator_get_voltage(rdev);
+ output_uV = regulator_get_voltage_rdev(rdev);
if (output_uV <= 0) {
rdev_err(rdev, "invalid output voltage found\n");
return -EINVAL;
@@ -1055,7 +1051,7 @@ static void print_constraints(struct regulator_dev *rdev)
if (!constraints->min_uV ||
constraints->min_uV != constraints->max_uV) {
- ret = _regulator_get_voltage(rdev);
+ ret = regulator_get_voltage_rdev(rdev);
if (ret > 0)
count += scnprintf(buf + count, len - count,
"at %d mV ", ret / 1000);
@@ -1114,7 +1110,7 @@ static int machine_constraints_voltage(struct
regulator_dev *rdev,
if (rdev->constraints->apply_uV &&
rdev->constraints->min_uV && rdev->constraints->max_uV) {
int target_min, target_max;
- int current_uV = _regulator_get_voltage(rdev);
+ int current_uV = regulator_get_voltage_rdev(rdev);
if (current_uV == -ENOTRECOVERABLE) {
/* This regulator can't be read and must be initialized
*/
@@ -1124,7 +1120,7 @@ static int machine_constraints_voltage(struct
regulator_dev *rdev,
_regulator_do_set_voltage(rdev,
rdev->constraints->min_uV,
rdev->constraints->max_uV);
-
[PATCH v2 5/8] dt-bindings: regulator: Document regulators coupling of NVIDIA Tegra20/30 SoC's
There is voltage coupling between three regulators on Tegra20 boards and
between two on Tegra30. The voltage coupling is a SoC-level feature and
thus it is mandatory and common for all of the Tegra boards.
Signed-off-by: Dmitry Osipenko
---
.../nvidia,tegra-regulators-coupling.txt | 65 +++
1 file changed, 65 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/nvidia,tegra-regulators-coupling.txt
diff --git
a/Documentation/devicetree/bindings/regulator/nvidia,tegra-regulators-coupling.txt
b/Documentation/devicetree/bindings/regulator/nvidia,tegra-regulators-coupling.txt
new file mode 100644
index ..4bf2dbf7c6cc
--- /dev/null
+++
b/Documentation/devicetree/bindings/regulator/nvidia,tegra-regulators-coupling.txt
@@ -0,0 +1,65 @@
+NVIDIA Tegra Regulators Coupling
+
+
+NVIDIA Tegra SoC's have a mandatory voltage-coupling between regulators.
+Thus on Tegra20 there are 3 coupled regulators and on NVIDIA Tegra30
+there are 2.
+
+Tegra20 voltage coupling
+
+
+On Tegra20 SoC's there are 3 coupled regulators: CORE, RTC and CPU.
+The CORE and RTC voltages shall be in a range of 170mV from each other
+and they both shall be higher than the CPU voltage by at least 120mV.
+
+Tegra30 voltage coupling
+
+
+On Tegra30 SoC's there are 2 coupled regulators: CORE and CPU. The CORE
+and CPU voltages shall be in a range of 300mV from each other and CORE
+voltage shall be higher than the CPU by N mV, where N depends on the CPU
+voltage.
+
+Required properties:
+- nvidia,tegra-core-regulator: Boolean property that designates regulator
+ as the "Core domain" voltage regulator.
+- nvidia,tegra-rtc-regulator: Boolean property that designates regulator
+ as the "RTC domain" voltage regulator.
+- nvidia,tegra-cpu-regulator: Boolean property that designates regulator
+ as the "CPU domain" voltage regulator.
+
+Example:
+
+ pmic {
+ regulators {
+ core_vdd_reg: core {
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <95>;
+ regulator-max-microvolt = <130>;
+ regulator-coupled-with = <_vdd_reg
_vdd_reg>;
+ regulator-coupled-max-spread = <17 55>;
+
+ nvidia,tegra-core-regulator;
+ };
+
+ rtc_vdd_reg: rtc {
+ regulator-name = "vdd_rtc";
+ regulator-min-microvolt = <95>;
+ regulator-max-microvolt = <130>;
+ regulator-coupled-with = <_vdd_reg
_vdd_reg>;
+ regulator-coupled-max-spread = <17 55>;
+
+ nvidia,tegra-rtc-regulator;
+ };
+
+ cpu_vdd_reg: cpu {
+ regulator-name = "vdd_cpu";
+ regulator-min-microvolt = <75>;
+ regulator-max-microvolt = <1125000>;
+ regulator-coupled-with = <_vdd_reg
_vdd_reg>;
+ regulator-coupled-max-spread = <55 55>;
+
+ nvidia,tegra-cpu-regulator;
+ };
+ };
+ };
--
2.21.0
[PATCH v2 7/8] soc/tegra: regulators: Add regulators coupler for Tegra20
Add regulators coupler for Tegra20 SoC's that performs voltage balancing
of a coupled regulators and thus provides voltage scaling functionality.
There are 3 coupled regulators on all Tegra20 SoC's: CORE, RTC and CPU.
The CORE and RTC voltages shall be in range of 170mV from each other and
they both shall be higher than the CPU voltage by at least 120mV. This
sounds like it could be handle by a generic voltage balancer, but the CORE
voltage scaling isn't implemented in any of the upstream drivers yet.
It will take quite some time and effort to hook up voltage scaling for
all of the drivers, hence we will use a custom coupler that will manage
the CPU voltage scaling for the starter.
Signed-off-by: Dmitry Osipenko
---
drivers/soc/tegra/Kconfig | 6 +
drivers/soc/tegra/Makefile | 1 +
drivers/soc/tegra/regulators-tegra20.c | 348 +
3 files changed, 355 insertions(+)
create mode 100644 drivers/soc/tegra/regulators-tegra20.c
diff --git a/drivers/soc/tegra/Kconfig b/drivers/soc/tegra/Kconfig
index fbfce48ffb0d..4453c982c0b9 100644
--- a/drivers/soc/tegra/Kconfig
+++ b/drivers/soc/tegra/Kconfig
@@ -16,6 +16,7 @@ config ARCH_TEGRA_2x_SOC
select SOC_TEGRA_FLOWCTRL
select SOC_TEGRA_PMC
select TEGRA_TIMER
+ select SOC_TEGRA20_VOLTAGE_COUPLER if REGULATOR
help
Support for NVIDIA Tegra AP20 and T20 processors, based on the
ARM CortexA9MP CPU and the ARM PL310 L2 cache controller
@@ -134,3 +135,8 @@ config SOC_TEGRA_POWERGATE_BPMP
def_bool y
depends on PM_GENERIC_DOMAINS
depends on TEGRA_BPMP
+
+config SOC_TEGRA20_VOLTAGE_COUPLER
+ bool "Voltage scaling support for Tegra20 SoC's"
+ depends on ARCH_TEGRA_2x_SOC
+ depends on REGULATOR
diff --git a/drivers/soc/tegra/Makefile b/drivers/soc/tegra/Makefile
index 902759fe5f4d..9f0bdd53bef8 100644
--- a/drivers/soc/tegra/Makefile
+++ b/drivers/soc/tegra/Makefile
@@ -5,3 +5,4 @@ obj-y += common.o
obj-$(CONFIG_SOC_TEGRA_FLOWCTRL) += flowctrl.o
obj-$(CONFIG_SOC_TEGRA_PMC) += pmc.o
obj-$(CONFIG_SOC_TEGRA_POWERGATE_BPMP) += powergate-bpmp.o
+obj-$(CONFIG_SOC_TEGRA20_VOLTAGE_COUPLER) += regulators-tegra20.o
diff --git a/drivers/soc/tegra/regulators-tegra20.c
b/drivers/soc/tegra/regulators-tegra20.c
new file mode 100644
index ..a64138f2e092
--- /dev/null
+++ b/drivers/soc/tegra/regulators-tegra20.c
@@ -0,0 +1,348 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Voltage regulators coupling resolver for NVIDIA Tegra20
+ *
+ * Copyright (C) 2019 GRATE-DRIVER project
+ */
+
+#define pr_fmt(fmt)"tegra voltage-coupler: " fmt
+
+#include
+#include
+#include
+#include
+#include
+
+struct tegra_regulator_coupler {
+ struct regulator_coupler coupler;
+ struct regulator_dev *core_rdev;
+ struct regulator_dev *cpu_rdev;
+ struct regulator_dev *rtc_rdev;
+ int core_min_uV;
+};
+
+static inline struct tegra_regulator_coupler *
+to_tegra_coupler(struct regulator_coupler *coupler)
+{
+ return container_of(coupler, struct tegra_regulator_coupler, coupler);
+}
+
+static int tegra20_core_limit(struct tegra_regulator_coupler *tegra,
+ struct regulator_dev *core_rdev)
+{
+ int core_min_uV = 0;
+ int core_max_uV;
+ int core_cur_uV;
+ int err;
+
+ if (tegra->core_min_uV > 0)
+ return tegra->core_min_uV;
+
+ core_cur_uV = regulator_get_voltage_rdev(core_rdev);
+ if (core_cur_uV < 0)
+ return core_cur_uV;
+
+ core_max_uV = max(core_cur_uV, 120);
+
+ err = regulator_check_voltage(core_rdev, _min_uV, _max_uV);
+ if (err)
+ return err;
+
+ /*
+* Limit minimum CORE voltage to a value left from bootloader or,
+* if it's unreasonably low value, to the most common 1.2v or to
+* whatever maximum value defined via board's device-tree.
+*/
+ tegra->core_min_uV = core_max_uV;
+
+ pr_info("core minimum voltage limited to %duV\n", tegra->core_min_uV);
+
+ return tegra->core_min_uV;
+}
+
+static int tegra20_core_rtc_max_spread(struct regulator_dev *core_rdev,
+ struct regulator_dev *rtc_rdev)
+{
+ struct coupling_desc *c_desc = _rdev->coupling_desc;
+ struct regulator_dev *rdev;
+ int max_spread;
+ unsigned int i;
+
+ for (i = 1; i < c_desc->n_coupled; i++) {
+ max_spread = core_rdev->constraints->max_spread[i - 1];
+ rdev = c_desc->coupled_rdevs[i];
+
+ if (rdev == rtc_rdev && max_spread)
+ return max_spread;
+ }
+
+ pr_err_once("rtc-core max-spread is undefined in device-tree\n");
+
+ return 15;
+}
+
+static int tegra20_core_rtc_update(struct tegra_regulator_coupler *tegra,
+ struct regulator_dev *core_rdev,
+
[PATCH v2 8/8] soc/tegra: regulators: Add regulators coupler for Tegra30
Add regulators coupler for Tegra30 SoC's that performs voltage balancing
of a coupled regulators and thus provides voltage scaling functionality.
There are 2 coupled regulators on all Tegra30 SoC's: CORE and CPU. The
coupled regulator voltages shall be in a range of 300mV from each other
and CORE voltage shall be higher than the CPU by N mV, where N depends
on the CPU voltage.
Signed-off-by: Dmitry Osipenko
---
drivers/soc/tegra/Kconfig | 6 +
drivers/soc/tegra/Makefile | 1 +
drivers/soc/tegra/regulators-tegra30.c | 300 +
3 files changed, 307 insertions(+)
create mode 100644 drivers/soc/tegra/regulators-tegra30.c
diff --git a/drivers/soc/tegra/Kconfig b/drivers/soc/tegra/Kconfig
index 4453c982c0b9..6909c9433369 100644
--- a/drivers/soc/tegra/Kconfig
+++ b/drivers/soc/tegra/Kconfig
@@ -30,6 +30,7 @@ config ARCH_TEGRA_3x_SOC
select SOC_TEGRA_FLOWCTRL
select SOC_TEGRA_PMC
select TEGRA_TIMER
+ select SOC_TEGRA30_VOLTAGE_COUPLER if REGULATOR
help
Support for NVIDIA Tegra T30 processor family, based on the
ARM CortexA9MP CPU and the ARM PL310 L2 cache controller
@@ -140,3 +141,8 @@ config SOC_TEGRA20_VOLTAGE_COUPLER
bool "Voltage scaling support for Tegra20 SoC's"
depends on ARCH_TEGRA_2x_SOC
depends on REGULATOR
+
+config SOC_TEGRA30_VOLTAGE_COUPLER
+ bool "Voltage scaling support for Tegra30 SoC's"
+ depends on ARCH_TEGRA_3x_SOC
+ depends on REGULATOR
diff --git a/drivers/soc/tegra/Makefile b/drivers/soc/tegra/Makefile
index 9f0bdd53bef8..9c809c1814bd 100644
--- a/drivers/soc/tegra/Makefile
+++ b/drivers/soc/tegra/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_SOC_TEGRA_FLOWCTRL) += flowctrl.o
obj-$(CONFIG_SOC_TEGRA_PMC) += pmc.o
obj-$(CONFIG_SOC_TEGRA_POWERGATE_BPMP) += powergate-bpmp.o
obj-$(CONFIG_SOC_TEGRA20_VOLTAGE_COUPLER) += regulators-tegra20.o
+obj-$(CONFIG_SOC_TEGRA30_VOLTAGE_COUPLER) += regulators-tegra30.o
diff --git a/drivers/soc/tegra/regulators-tegra30.c
b/drivers/soc/tegra/regulators-tegra30.c
new file mode 100644
index ..26330f14126c
--- /dev/null
+++ b/drivers/soc/tegra/regulators-tegra30.c
@@ -0,0 +1,300 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Voltage regulators coupling resolver for NVIDIA Tegra30
+ *
+ * Copyright (C) 2019 GRATE-DRIVER project
+ */
+
+#define pr_fmt(fmt)"tegra voltage-coupler: " fmt
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct tegra_regulator_coupler {
+ struct regulator_coupler coupler;
+ struct regulator_dev *core_rdev;
+ struct regulator_dev *cpu_rdev;
+ int core_min_uV;
+};
+
+static inline struct tegra_regulator_coupler *
+to_tegra_coupler(struct regulator_coupler *coupler)
+{
+ return container_of(coupler, struct tegra_regulator_coupler, coupler);
+}
+
+static int tegra30_core_limit(struct tegra_regulator_coupler *tegra,
+ struct regulator_dev *core_rdev)
+{
+ int core_min_uV = 0;
+ int core_max_uV;
+ int core_cur_uV;
+ int err;
+
+ if (tegra->core_min_uV > 0)
+ return tegra->core_min_uV;
+
+ core_cur_uV = regulator_get_voltage_rdev(core_rdev);
+ if (core_cur_uV < 0)
+ return core_cur_uV;
+
+ core_max_uV = max(core_cur_uV, 120);
+
+ err = regulator_check_voltage(core_rdev, _min_uV, _max_uV);
+ if (err)
+ return err;
+
+ /*
+* Limit minimum CORE voltage to a value left from bootloader or,
+* if it's unreasonably low value, to the most common 1.2v or to
+* whatever maximum value defined via board's device-tree.
+*/
+ tegra->core_min_uV = core_max_uV;
+
+ pr_info("core minimum voltage limited to %duV\n", tegra->core_min_uV);
+
+ return tegra->core_min_uV;
+}
+
+static int tegra30_core_cpu_limit(int cpu_uV)
+{
+ if (cpu_uV < 80)
+ return 95;
+
+ if (cpu_uV < 90)
+ return 100;
+
+ if (cpu_uV < 100)
+ return 110;
+
+ if (cpu_uV < 110)
+ return 120;
+
+ if (cpu_uV < 125) {
+ switch (tegra_sku_info.cpu_speedo_id) {
+ case 0 ... 1:
+ case 4:
+ case 7 ... 8:
+ return 120;
+
+ default:
+ return 130;
+ }
+ }
+
+ return -EINVAL;
+}
+
+static int tegra30_voltage_update(struct tegra_regulator_coupler *tegra,
+ struct regulator_dev *cpu_rdev,
+ struct regulator_dev *core_rdev)
+{
+ int core_min_uV, core_max_uV = INT_MAX;
+ int cpu_min_uV, cpu_max_uV = INT_MAX;
+ int core_min_limited_uV;
+ int core_target_uV;
+ int cpu_target_uV;
+ int core_max_step;
+ int cpu_max_step;
+ int
