Re: [PATCH V4] thermal: Add cooling device's statistics in sysfs
Hi, Viresh,
I will queue it for 4.17, with just one minor fix below.
On 二, 2018-01-16 at 15:22 +0530, Viresh Kumar wrote:
> This extends the sysfs interface for thermal cooling devices and
> exposes
> some pretty useful statistics. These statistics have proven to be
> quite
> useful specially while doing benchmarks related to the task
> scheduler,
> where we want to make sure that nothing has disrupted the test,
> specially the cooling device which may have put constraints on the
> CPUs.
> The information exposed here tells us to what extent the CPUs were
> constrained by the thermal framework.
>
> The write-only "reset" file is used to reset the statistics.
>
> The read-only "time_in_state" file shows the clock_t time spent by
> the
> device in the respective cooling states, and it prints one line per
> cooling state.
>
> The read-only "total_trans" file shows single positive integer value
> showing the total number of cooling state transitions the device has
> gone through since the time the cooling device is registered or the
> time
> when statistics were reset last.
>
> The read-only "trans_table" file shows a two dimensional matrix,
> where
> an entry (row i, column j) represents the number of transitions
> from State_i to State_j.
>
> This is how the directory structure looks like for a single cooling
> device:
>
> $ ls -R /sys/class/thermal/cooling_device0/
> /sys/class/thermal/cooling_device0/:
> cur_state max_state power stats subsystem type uevent
>
> /sys/class/thermal/cooling_device0/power:
> autosuspend_delay_ms runtime_active_time runtime_suspended_time
> control runtime_status
>
> /sys/class/thermal/cooling_device0/stats:
> reset time_in_state total_trans trans_table
>
> This is tested on ARM 64-bit Hisilicon hikey620 board running Ubuntu
> and
> ARM 64-bit Hisilicon hikey960 board running Android.
>
> Signed-off-by: Viresh Kumar
[snip]
> +static void cooling_device_stats_setup(struct thermal_cooling_device
> *cdev)
> +{
> + struct cooling_dev_stats *stats;
> + unsigned long states;
> + int var;
> +
> + if (cdev->ops->get_max_state(cdev, &states))
> + return;
> +
> + states++; /* Total number of states is highest state + 1 */
> +
> + var = sizeof(*stats);
> + var += sizeof(*stats->time_in_state) * states;
> + var += sizeof(*stats->trans_table) * states * states;
> +
> + stats = kzalloc(var, GFP_KERNEL);
> + if (!stats)
> + return;
> +
> + stats->time_in_state = (ktime_t *)(stats + 1);
> + stats->trans_table = (unsigned int *)(stats->time_in_state +
> states);
> + cdev->stats = stats;
> + stats->last_time = ktime_get();
> + stats->max_states = states;
> + cdev->stats = stats;
> +
cdev->stats is set twice here, I will remove the first one.
thanks,
rui
Re: [PATCH v4 3/3 update] mm/free_pcppages_bulk: prefetch buddy while not holding lock
On Tue, Mar 13, 2018 at 11:35:19AM +0800, Aaron Lu wrote:
> On Mon, Mar 12, 2018 at 10:32:32AM -0700, Dave Hansen wrote:
> > On 03/09/2018 12:24 AM, Aaron Lu wrote:
> > > + /*
> > > + * We are going to put the page back to the global
> > > + * pool, prefetch its buddy to speed up later access
> > > + * under zone->lock. It is believed the overhead of
> > > + * an additional test and calculating buddy_pfn here
> > > + * can be offset by reduced memory latency later. To
> > > + * avoid excessive prefetching due to large count, only
> > > + * prefetch buddy for the last pcp->batch nr of pages.
> > > + */
> > > + if (count > pcp->batch)
> > > + continue;
> > > + pfn = page_to_pfn(page);
> > > + buddy_pfn = __find_buddy_pfn(pfn, 0);
> > > + buddy = page + (buddy_pfn - pfn);
> > > + prefetch(buddy);
> >
> > FWIW, I think this needs to go into a helper function. Is that possible?
>
> I'll give it a try.
>
> >
> > There's too much logic happening here. Also, 'count' going from
> > batch_size->0 is totally non-obvious from the patch context. It makes
> > this hunk look totally wrong by itself.
I tried to avoid adding one more local variable but looks like it caused
a lot of pain. What about the following? It doesn't use count any more
but prefetch_nr to indicate how many prefetches have happened.
Also, I think it's not worth the risk of disordering pages in free_list
by changing list_add_tail() to list_add() as Andrew reminded so I
dropped that change too.
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index dafdcdec9c1f..00ea4483f679 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1099,6 +1099,15 @@ static bool bulkfree_pcp_prepare(struct page *page)
}
#endif /* CONFIG_DEBUG_VM */
+static inline void prefetch_buddy(struct page *page)
+{
+ unsigned long pfn = page_to_pfn(page);
+ unsigned long buddy_pfn = __find_buddy_pfn(pfn, 0);
+ struct page *buddy = page + (buddy_pfn - pfn);
+
+ prefetch(buddy);
+}
+
/*
* Frees a number of pages from the PCP lists
* Assumes all pages on list are in same zone, and of same order.
@@ -1115,6 +1124,7 @@ static void free_pcppages_bulk(struct zone *zone, int
count,
{
int migratetype = 0;
int batch_free = 0;
+ int prefetch_nr = 0;
bool isolated_pageblocks;
struct page *page, *tmp;
LIST_HEAD(head);
@@ -1150,6 +1160,18 @@ static void free_pcppages_bulk(struct zone *zone, int
count,
continue;
list_add_tail(&page->lru, &head);
+
+ /*
+* We are going to put the page back to the global
+* pool, prefetch its buddy to speed up later access
+* under zone->lock. It is believed the overhead of
+* an additional test and calculating buddy_pfn here
+* can be offset by reduced memory latency later. To
+* avoid excessive prefetching due to large count, only
+* prefetch buddy for the first pcp->batch nr of pages.
+*/
+ if (prefetch_nr++ < pcp->batch)
+ prefetch_buddy(page);
} while (--count && --batch_free && !list_empty(list));
}
--
2.14.3
RE: Dell Inc. XPS 13 9343/0TM99H fails to boot v4.16-rc5
> -Original Message-
> From: Dominik Brodowski [mailto:li...@dominikbrodowski.net]
> Sent: Tuesday, March 13, 2018 2:44 PM
> To: Limonciello, Mario ; Darren Hart
>
> Cc: platform-driver-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: Dell Inc. XPS 13 9343/0TM99H fails to boot v4.16-rc5
>
> On Tue, Mar 13, 2018 at 06:12:04AM +, mario.limoncie...@dell.com wrote:
> > As long as they're ready before dell-laptop's initialization which uses
> > late_initcall that should be fine.
> >
> > Am I correct to presume you're going to propose a patch you can test and
> > confirm your hypothesis rather than Darren reverting my patch to bring
> > them together?
>
> Thanks for the input; a draft patch (which works fine on my system) is
> attached below.
>
> On Mon, Mar 12, 2018 at 11:32:13PM -0700, Darren Hart wrote:
> > There is one other caveat, which you'll find documented in
> > dell-laptop.c, namely that dell-laptop needs to init after dell-rbtn
> > (I'm starting to appreciate the monolithic thinkpad-acpi driver).
> >
> > We need things to init in this order (items on the same line have no
> > dependency):
> >
> > 1. DCDBAS, ACPI_WMI
> > 2. DELL_SMBIOS, DELL_RBTN
> > 3. DELL_LAPTOP, DELL_WMI
> >
> > Currently:
> > subsys_initcall: ACPI_WMI, DELL_SMBIOS
> > module_init: DCDBAS, DELL_WMI
> > late_initcall: DELL_LAPTOP
> >
> > From a quick naive glance, it appears as though we might be able to
> > address this as follows:
> >
> > subsys_initcall: DCDBAS, ACPI_WMI
> > module_init: DELL_SMBIOS, DELL_RBTN
> > late_initcall: DELL_LAPTOP, DELL_WMI
>
> Hmmm. I do not yet understand why you propose to
>
> a) advance the DCDBAS initialization to subsys_initcall, as only DELL_LAPTOP
>(running as a late_initcall) requires it to be up and running, and
Actually dell-smbios itself should require this too. The SMM backend will use
it during initialization to determine if WSMT is enabled. If it's not
operational
yet then we may get invalid results.
So considering this I think Darren's proposal is good to move DCDBAS to earlier.
>
> b) delay DELL_WMI to late_initcall, as it can safely be initialized as long
>as ACPI_WMI is ready.
Maybe Darren meant dell-wmi-descriptor not dell-wmi?
Otherwise I would agree that part isn't needed.
>
> What do I miss?
>
> Attached patch *seems* to work fine on my system.
At least to me, I think it's better to see
>
> Thanks,
> Dominik
>
>
> From: Dominik Brodowski
> Date: Tue, 13 Mar 2018 07:27:41 +0100
> Subject: [PATCH] platform/x86: dell-smbios: wait for WMI initialization
>
> If DELL_SMBIOS_WMI is enabled, the combined dell-smbios driver
> needs to wait for ACPI_WMI to be initialized, which occurs at the
> subsys_initcall() level. As the dell-smbios driver only needs to
> be up and running by the time the dell-laptop module is initialized,
> which occurs at the late_initcall() level, it is sufficient to
> initialize the dell-smbios driver at the default device_initcall()
> level.
>
> Fixes: 25d47027e100 ("platform/x86: dell-smbios: Link all dell-smbios-*
> modules
> together")
> Signed-off-by: Dominik Brodowski
>
> diff --git a/drivers/platform/x86/dell-smbios-base.c
> b/drivers/platform/x86/dell-
> smbios-base.c
> index 5bcf8a18f785..2485c80a9fdd 100644
> --- a/drivers/platform/x86/dell-smbios-base.c
> +++ b/drivers/platform/x86/dell-smbios-base.c
> @@ -637,7 +637,7 @@ static void __exit dell_smbios_exit(void)
> mutex_unlock(&smbios_mutex);
> }
>
> -subsys_initcall(dell_smbios_init);
> +module_init(dell_smbios_init);
> module_exit(dell_smbios_exit);
>
> MODULE_AUTHOR("Matthew Garrett ");
Re: [2/9] um/drivers/vector_user: Less checks in user_init_raw_fds() after error detection
> +set_error_code: > + err = -errno; > + os_close_file(rxfd); I have taken another look at this change idea. Now I notice that I should have preserved a sanity check there. if (rxfd >= 0) os_close_file(rxfd); Regards, Markus
[tip:timers/core] timekeeping: Add the new CLOCK_MONOTONIC_ACTIVE clock
Commit-ID: 72199320d49dbafa1a99f94f1cd60dc90035c154
Gitweb: https://git.kernel.org/tip/72199320d49dbafa1a99f94f1cd60dc90035c154
Author: Thomas Gleixner
AuthorDate: Thu, 1 Mar 2018 17:33:32 +0100
Committer: Ingo Molnar
CommitDate: Tue, 13 Mar 2018 07:34:21 +0100
timekeeping: Add the new CLOCK_MONOTONIC_ACTIVE clock
The planned change to unify the behaviour of the MONOTONIC and BOOTTIME
clocks vs. suspend removes the ability to retrieve the active
non-suspended time of a system.
Provide a new CLOCK_MONOTONIC_ACTIVE clock which returns the active
non-suspended time of the system via clock_gettime().
This preserves the old behaviour of CLOCK_MONOTONIC before the
BOOTTIME/MONOTONIC unification.
This new clock also allows applications to detect programmatically that
the MONOTONIC and BOOTTIME clocks are identical.
Signed-off-by: Thomas Gleixner
Cc: Dmitry Torokhov
Cc: John Stultz
Cc: Jonathan Corbet
Cc: Kevin Easton
Cc: Linus Torvalds
Cc: Mark Salyzyn
Cc: Michael Kerrisk
Cc: Peter Zijlstra
Cc: Petr Mladek
Cc: Prarit Bhargava
Cc: Sergey Senozhatsky
Cc: Steven Rostedt
Link: http://lkml.kernel.org/r/20180301165149.965235...@linutronix.de
Signed-off-by: Ingo Molnar
---
include/linux/timekeeper_internal.h | 2 ++
include/linux/timekeeping.h | 1 +
include/uapi/linux/time.h | 1 +
kernel/time/posix-stubs.c | 2 ++
kernel/time/posix-timers.c | 13 +
kernel/time/timekeeping.c | 36
6 files changed, 55 insertions(+)
diff --git a/include/linux/timekeeper_internal.h
b/include/linux/timekeeper_internal.h
index 7acb953298a7..4b3dca173e89 100644
--- a/include/linux/timekeeper_internal.h
+++ b/include/linux/timekeeper_internal.h
@@ -52,6 +52,7 @@ struct tk_read_base {
* @offs_real: Offset clock monotonic -> clock realtime
* @offs_boot: Offset clock monotonic -> clock boottime
* @offs_tai: Offset clock monotonic -> clock tai
+ * @time_suspended:Accumulated suspend time
* @tai_offset:The current UTC to TAI offset in seconds
* @clock_was_set_seq: The sequence number of clock was set events
* @cs_was_changed_seq:The sequence number of clocksource change events
@@ -94,6 +95,7 @@ struct timekeeper {
ktime_t offs_real;
ktime_t offs_boot;
ktime_t offs_tai;
+ ktime_t time_suspended;
s32 tai_offset;
unsigned intclock_was_set_seq;
u8 cs_was_changed_seq;
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index b17bcce58bc4..440b1935d3a5 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -32,6 +32,7 @@ extern void getrawmonotonic64(struct timespec64 *ts);
extern void ktime_get_ts64(struct timespec64 *ts);
extern time64_t ktime_get_seconds(void);
extern time64_t ktime_get_real_seconds(void);
+extern void ktime_get_active_ts64(struct timespec64 *ts);
extern int __getnstimeofday64(struct timespec64 *tv);
extern void getnstimeofday64(struct timespec64 *tv);
diff --git a/include/uapi/linux/time.h b/include/uapi/linux/time.h
index 53f8dd84beb5..61a187df8da2 100644
--- a/include/uapi/linux/time.h
+++ b/include/uapi/linux/time.h
@@ -61,6 +61,7 @@ struct itimerval {
*/
#define CLOCK_SGI_CYCLE10
#define CLOCK_TAI 11
+#define CLOCK_MONOTONIC_ACTIVE 12
#define MAX_CLOCKS 16
#define CLOCKS_MASK(CLOCK_REALTIME | CLOCK_MONOTONIC)
diff --git a/kernel/time/posix-stubs.c b/kernel/time/posix-stubs.c
index b258bee13b02..6259dbc0191a 100644
--- a/kernel/time/posix-stubs.c
+++ b/kernel/time/posix-stubs.c
@@ -73,6 +73,8 @@ int do_clock_gettime(clockid_t which_clock, struct timespec64
*tp)
case CLOCK_BOOTTIME:
get_monotonic_boottime64(tp);
break;
+ case CLOCK_MONOTONIC_ACTIVE:
+ ktime_get_active_ts64(tp);
default:
return -EINVAL;
}
diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
index 75043046914e..556fe02a47a4 100644
--- a/kernel/time/posix-timers.c
+++ b/kernel/time/posix-timers.c
@@ -263,6 +263,13 @@ static int posix_get_tai(clockid_t which_clock, struct
timespec64 *tp)
return 0;
}
+static int posix_get_monotonic_active(clockid_t which_clock,
+ struct timespec64 *tp)
+{
+ ktime_get_active_ts64(tp);
+ return 0;
+}
+
static int posix_get_hrtimer_res(clockid_t which_clock, struct timespec64 *tp)
{
tp->tv_sec = 0;
@@ -1330,6 +1337,11 @@ static const struct k_clock clock_boottime = {
.timer_arm = common_hrtimer_arm,
};
+static const struct k_clock clock_monotonic_active = {
+ .clock_getres = posix_get_hrtimer_res,
+ .clock_
[tip:timers/core] timekeeping: Make the MONOTONIC clock behave like the BOOTTIME clock
Commit-ID: d6ed449afdb38f89a7b38ec50e367559e1b8f71f
Gitweb: https://git.kernel.org/tip/d6ed449afdb38f89a7b38ec50e367559e1b8f71f
Author: Thomas Gleixner
AuthorDate: Thu, 1 Mar 2018 17:33:33 +0100
Committer: Ingo Molnar
CommitDate: Tue, 13 Mar 2018 07:34:22 +0100
timekeeping: Make the MONOTONIC clock behave like the BOOTTIME clock
The MONOTONIC clock is not fast forwarded by the time spent in suspend on
resume. This is only done for the BOOTTIME clock. The reason why the
MONOTONIC clock is not forwarded is historical: the original Linux
implementation was using jiffies as a base for the MONOTONIC clock and
jiffies have never been advanced after resume.
At some point when timekeeping was unified in the core code, the
MONONOTIC clock was advanced after resume which also advanced jiffies causing
interesting side effects. As a consequence the the MONOTONIC clock forwarding
was disabled again and the BOOTTIME clock was introduced, which allows to read
time since boot.
Back then it was not possible to completely distangle the MONOTONIC clock and
jiffies because there were still interfaces which exposed the MONOTONIC clock
behaviour based on the timer wheel and therefore jiffies.
As of today none of the MONOTONIC clock facilities depends on jiffies
anymore so the forwarding can be done seperately. This is achieved by
forwarding the variables which are used for the jiffies update after resume
before the tick is restarted,
In timekeeping resume, the change is rather simple. Instead of updating the
offset between the MONOTONIC clock and the REALTIME/BOOTTIME clocks, advance the
time keeper base for the MONOTONIC and the MONOTONIC_RAW clocks by the time
spent in suspend.
The MONOTONIC clock is now the same as the BOOTTIME clock and the offset between
the REALTIME and the MONOTONIC clocks is the same as before suspend.
There might be side effects in applications, which rely on the
(unfortunately) well documented behaviour of the MONOTONIC clock, but the
downsides of the existing behaviour are probably worse.
There is one obvious issue. Up to now it was possible to retrieve the time
spent in suspend by observing the delta between the MONOTONIC clock and the
BOOTTIME clock. This is not longer available, but the previously introduced
mechanism to read the active non-suspended monotonic time can mitigate that
in a detectable fashion.
Signed-off-by: Thomas Gleixner
Cc: Andrew Morton
Cc: Dmitry Torokhov
Cc: John Stultz
Cc: Jonathan Corbet
Cc: Kevin Easton
Cc: Linus Torvalds
Cc: Mark Salyzyn
Cc: Michael Kerrisk
Cc: Peter Zijlstra
Cc: Petr Mladek
Cc: Prarit Bhargava
Cc: Sergey Senozhatsky
Cc: Steven Rostedt
Link: http://lkml.kernel.org/r/20180301165150.062975...@linutronix.de
Signed-off-by: Ingo Molnar
---
kernel/time/tick-common.c | 15 +++
kernel/time/tick-internal.h | 6 ++
kernel/time/tick-sched.c| 9 +
kernel/time/timekeeping.c | 7 ---
4 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 49edc1c4f3e6..099572ca4a8f 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -419,6 +419,19 @@ void tick_suspend_local(void)
clockevents_shutdown(td->evtdev);
}
+static void tick_forward_next_period(void)
+{
+ ktime_t delta, now = ktime_get();
+ u64 n;
+
+ delta = ktime_sub(now, tick_next_period);
+ n = ktime_divns(delta, tick_period);
+ tick_next_period += n * tick_period;
+ if (tick_next_period < now)
+ tick_next_period += tick_period;
+ tick_sched_forward_next_period();
+}
+
/**
* tick_resume_local - Resume the local tick device
*
@@ -431,6 +444,8 @@ void tick_resume_local(void)
struct tick_device *td = this_cpu_ptr(&tick_cpu_device);
bool broadcast = tick_resume_check_broadcast();
+ tick_forward_next_period();
+
clockevents_tick_resume(td->evtdev);
if (!broadcast) {
if (td->mode == TICKDEV_MODE_PERIODIC)
diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h
index e277284c2831..21efab7485ca 100644
--- a/kernel/time/tick-internal.h
+++ b/kernel/time/tick-internal.h
@@ -141,6 +141,12 @@ static inline void
tick_check_oneshot_broadcast_this_cpu(void) { }
static inline bool tick_broadcast_oneshot_available(void) { return
tick_oneshot_possible(); }
#endif /* !(BROADCAST && ONESHOT) */
+#if defined(CONFIG_NO_HZ_COMMON) || defined(CONFIG_HIGH_RES_TIMERS)
+extern void tick_sched_forward_next_period(void);
+#else
+static inline void tick_sched_forward_next_period(void) { }
+#endif
+
/* NO_HZ_FULL internal */
#ifdef CONFIG_NO_HZ_FULL
extern void tick_nohz_init(void);
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 29a5733eff83..f53e37b5d248 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -51,6 +51,15 @@ struct tick_sched *tick_get_tick_sched(int cpu)
*/
static ktime_t last_jiff
[tip:timers/core] Input: Evdev - unify MONOTONIC and BOOTTIME clock behavior
Commit-ID: f2d6fdbfd2389a38598d448cb8dc09d946c1b87e
Gitweb: https://git.kernel.org/tip/f2d6fdbfd2389a38598d448cb8dc09d946c1b87e
Author: Thomas Gleixner
AuthorDate: Thu, 1 Mar 2018 17:33:34 +0100
Committer: Ingo Molnar
CommitDate: Tue, 13 Mar 2018 07:34:22 +0100
Input: Evdev - unify MONOTONIC and BOOTTIME clock behavior
Now that the MONOTONIC and BOOTTIME clocks are indentical, remove all the
special casing.
The user space visible interfaces still support both clocks, but their behavior
is identical.
Signed-off-by: Thomas Gleixner
Cc: Dmitry Torokhov
Cc: John Stultz
Cc: Jonathan Corbet
Cc: Kevin Easton
Cc: Linus Torvalds
Cc: Mark Salyzyn
Cc: Michael Kerrisk
Cc: Peter Zijlstra
Cc: Petr Mladek
Cc: Prarit Bhargava
Cc: Sergey Senozhatsky
Cc: Steven Rostedt
Cc: linux-in...@vger.kernel.org
Link: http://lkml.kernel.org/r/20180301165150.155899...@linutronix.de
Signed-off-by: Ingo Molnar
---
drivers/input/evdev.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index c81c79d01d93..46115a392098 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -31,7 +31,6 @@
enum evdev_clock_type {
EV_CLK_REAL = 0,
EV_CLK_MONO,
- EV_CLK_BOOT,
EV_CLK_MAX
};
@@ -198,12 +197,10 @@ static int evdev_set_clk_type(struct evdev_client
*client, unsigned int clkid)
case CLOCK_REALTIME:
clk_type = EV_CLK_REAL;
break;
+ case CLOCK_BOOTTIME:
case CLOCK_MONOTONIC:
clk_type = EV_CLK_MONO;
break;
- case CLOCK_BOOTTIME:
- clk_type = EV_CLK_BOOT;
- break;
default:
return -EINVAL;
}
@@ -314,8 +311,6 @@ static void evdev_events(struct input_handle *handle,
ev_time[EV_CLK_MONO] = ktime_get();
ev_time[EV_CLK_REAL] = ktime_mono_to_real(ev_time[EV_CLK_MONO]);
- ev_time[EV_CLK_BOOT] = ktime_mono_to_any(ev_time[EV_CLK_MONO],
-TK_OFFS_BOOT);
rcu_read_lock();
[tip:timers/core] timekeeping: Remove boot time specific code
Commit-ID: d6c7270e913db75ca5fdc79915ba780e97ae2857
Gitweb: https://git.kernel.org/tip/d6c7270e913db75ca5fdc79915ba780e97ae2857
Author: Thomas Gleixner
AuthorDate: Thu, 1 Mar 2018 17:33:35 +0100
Committer: Ingo Molnar
CommitDate: Tue, 13 Mar 2018 07:34:22 +0100
timekeeping: Remove boot time specific code
Now that the MONOTONIC and BOOTTIME clocks are the same, remove all the
special handling from timekeeping. Keep wrappers for the existing users of
the *boot* timekeeper interfaces.
Signed-off-by: Thomas Gleixner
Cc: Dmitry Torokhov
Cc: John Stultz
Cc: Jonathan Corbet
Cc: Kevin Easton
Cc: Linus Torvalds
Cc: Mark Salyzyn
Cc: Michael Kerrisk
Cc: Peter Zijlstra
Cc: Petr Mladek
Cc: Prarit Bhargava
Cc: Sergey Senozhatsky
Cc: Steven Rostedt
Link: http://lkml.kernel.org/r/20180301165150.236279...@linutronix.de
Signed-off-by: Ingo Molnar
---
include/linux/timekeeping.h | 42 +-
kernel/time/timekeeping.c | 31 ---
2 files changed, 17 insertions(+), 56 deletions(-)
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index 440b1935d3a5..abb396731332 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -38,15 +38,19 @@ extern int __getnstimeofday64(struct timespec64 *tv);
extern void getnstimeofday64(struct timespec64 *tv);
extern void getboottime64(struct timespec64 *ts);
-#define ktime_get_real_ts64(ts)getnstimeofday64(ts)
+#define ktime_get_real_ts64(ts)getnstimeofday64(ts)
+
+/* Clock BOOTTIME compatibility wrappers */
+static inline void get_monotonic_boottime64(struct timespec64 *ts)
+{
+ ktime_get_ts64(ts);
+}
/*
* ktime_t based interfaces
*/
-
enum tk_offsets {
TK_OFFS_REAL,
- TK_OFFS_BOOT,
TK_OFFS_TAI,
TK_OFFS_MAX,
};
@@ -57,6 +61,10 @@ extern ktime_t ktime_mono_to_any(ktime_t tmono, enum
tk_offsets offs);
extern ktime_t ktime_get_raw(void);
extern u32 ktime_get_resolution_ns(void);
+/* Clock BOOTTIME compatibility wrappers */
+static inline ktime_t ktime_get_boottime(void) { return ktime_get(); }
+static inline u64 ktime_get_boot_ns(void) { return ktime_get(); }
+
/**
* ktime_get_real - get the real (wall-) time in ktime_t format
*/
@@ -65,17 +73,6 @@ static inline ktime_t ktime_get_real(void)
return ktime_get_with_offset(TK_OFFS_REAL);
}
-/**
- * ktime_get_boottime - Returns monotonic time since boot in ktime_t format
- *
- * This is similar to CLOCK_MONTONIC/ktime_get, but also includes the
- * time spent in suspend.
- */
-static inline ktime_t ktime_get_boottime(void)
-{
- return ktime_get_with_offset(TK_OFFS_BOOT);
-}
-
/**
* ktime_get_clocktai - Returns the TAI time of day in ktime_t format
*/
@@ -102,11 +99,6 @@ static inline u64 ktime_get_real_ns(void)
return ktime_to_ns(ktime_get_real());
}
-static inline u64 ktime_get_boot_ns(void)
-{
- return ktime_to_ns(ktime_get_boottime());
-}
-
static inline u64 ktime_get_tai_ns(void)
{
return ktime_to_ns(ktime_get_clocktai());
@@ -119,17 +111,17 @@ static inline u64 ktime_get_raw_ns(void)
extern u64 ktime_get_mono_fast_ns(void);
extern u64 ktime_get_raw_fast_ns(void);
-extern u64 ktime_get_boot_fast_ns(void);
extern u64 ktime_get_real_fast_ns(void);
-/*
- * timespec64 interfaces utilizing the ktime based ones
- */
-static inline void get_monotonic_boottime64(struct timespec64 *ts)
+/* Clock BOOTTIME compatibility wrappers */
+static inline u64 ktime_get_boot_fast_ns(void)
{
- *ts = ktime_to_timespec64(ktime_get_boottime());
+ return ktime_get_mono_fast_ns();
}
+/*
+ * timespec64 interfaces utilizing the ktime based ones
+ */
static inline void timekeeping_clocktai64(struct timespec64 *ts)
{
*ts = ktime_to_timespec64(ktime_get_clocktai());
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index b509fe7acd64..8355c8803282 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -473,36 +473,6 @@ u64 ktime_get_raw_fast_ns(void)
}
EXPORT_SYMBOL_GPL(ktime_get_raw_fast_ns);
-/**
- * ktime_get_boot_fast_ns - NMI safe and fast access to boot clock.
- *
- * To keep it NMI safe since we're accessing from tracing, we're not using a
- * separate timekeeper with updates to monotonic clock and boot offset
- * protected with seqlocks. This has the following minor side effects:
- *
- * (1) Its possible that a timestamp be taken after the boot offset is updated
- * but before the timekeeper is updated. If this happens, the new boot offset
- * is added to the old timekeeping making the clock appear to update slightly
- * earlier:
- *CPU 0CPU 1
- *timekeeping_inject_sleeptime64()
- *__timekeeping_inject_sleeptime(tk, delta);
- * timestamp();
- *timekeeping_update(tk, TK_CLEAR_NTP...);
- *
- * (2) On 32-bit systems, the 64-bit boot offse
[tip:timers/core] posix-timers: Unify MONOTONIC and BOOTTIME clock behavior
Commit-ID: 7250a4047aa6106006c2c9b5aff91d7d3fb77962
Gitweb: https://git.kernel.org/tip/7250a4047aa6106006c2c9b5aff91d7d3fb77962
Author: Thomas Gleixner
AuthorDate: Thu, 1 Mar 2018 17:33:36 +0100
Committer: Ingo Molnar
CommitDate: Tue, 13 Mar 2018 07:34:22 +0100
posix-timers: Unify MONOTONIC and BOOTTIME clock behavior
Now that the MONOTONIC and BOOTTIME clocks are indentical remove all the special
casing.
The user space visible interfaces still support both clocks, but their behavior
is identical.
Signed-off-by: Thomas Gleixner
Cc: Dmitry Torokhov
Cc: John Stultz
Cc: Jonathan Corbet
Cc: Kevin Easton
Cc: Linus Torvalds
Cc: Mark Salyzyn
Cc: Michael Kerrisk
Cc: Peter Zijlstra
Cc: Petr Mladek
Cc: Prarit Bhargava
Cc: Sergey Senozhatsky
Cc: Steven Rostedt
Link: http://lkml.kernel.org/r/20180301165150.315745...@linutronix.de
Signed-off-by: Ingo Molnar
---
kernel/time/posix-timers.c | 23 +--
1 file changed, 1 insertion(+), 22 deletions(-)
diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
index 556fe02a47a4..8cf95bfee44f 100644
--- a/kernel/time/posix-timers.c
+++ b/kernel/time/posix-timers.c
@@ -251,12 +251,6 @@ static int posix_get_coarse_res(const clockid_t
which_clock, struct timespec64 *
return 0;
}
-static int posix_get_boottime(const clockid_t which_clock, struct timespec64
*tp)
-{
- get_monotonic_boottime64(tp);
- return 0;
-}
-
static int posix_get_tai(clockid_t which_clock, struct timespec64 *tp)
{
timekeeping_clocktai64(tp);
@@ -1322,21 +1316,6 @@ static const struct k_clock clock_tai = {
.timer_arm = common_hrtimer_arm,
};
-static const struct k_clock clock_boottime = {
- .clock_getres = posix_get_hrtimer_res,
- .clock_get = posix_get_boottime,
- .nsleep = common_nsleep,
- .timer_create = common_timer_create,
- .timer_set = common_timer_set,
- .timer_get = common_timer_get,
- .timer_del = common_timer_del,
- .timer_rearm= common_hrtimer_rearm,
- .timer_forward = common_hrtimer_forward,
- .timer_remaining= common_hrtimer_remaining,
- .timer_try_to_cancel= common_hrtimer_try_to_cancel,
- .timer_arm = common_hrtimer_arm,
-};
-
static const struct k_clock clock_monotonic_active = {
.clock_getres = posix_get_hrtimer_res,
.clock_get = posix_get_monotonic_active,
@@ -1350,7 +1329,7 @@ static const struct k_clock * const posix_clocks[] = {
[CLOCK_MONOTONIC_RAW] = &clock_monotonic_raw,
[CLOCK_REALTIME_COARSE] = &clock_realtime_coarse,
[CLOCK_MONOTONIC_COARSE]= &clock_monotonic_coarse,
- [CLOCK_BOOTTIME]= &clock_boottime,
+ [CLOCK_BOOTTIME]= &clock_monotonic,
[CLOCK_REALTIME_ALARM] = &alarm_clock,
[CLOCK_BOOTTIME_ALARM] = &alarm_clock,
[CLOCK_TAI] = &clock_tai,
[tip:timers/core] hrtimer: Unify MONOTONIC and BOOTTIME clock behavior
Commit-ID: 127bfa5f4342e63d83a0b07ece376c2e8878e4a5
Gitweb: https://git.kernel.org/tip/127bfa5f4342e63d83a0b07ece376c2e8878e4a5
Author: Thomas Gleixner
AuthorDate: Thu, 1 Mar 2018 17:33:37 +0100
Committer: Ingo Molnar
CommitDate: Tue, 13 Mar 2018 07:34:23 +0100
hrtimer: Unify MONOTONIC and BOOTTIME clock behavior
Now that th MONOTONIC and BOOTTIME clocks are indentical remove all the special
casing.
The user space visible interfaces still support both clocks, but their behavior
is identical.
Signed-off-by: Thomas Gleixner
Cc: Dmitry Torokhov
Cc: John Stultz
Cc: Jonathan Corbet
Cc: Kevin Easton
Cc: Linus Torvalds
Cc: Mark Salyzyn
Cc: Michael Kerrisk
Cc: Peter Zijlstra
Cc: Petr Mladek
Cc: Prarit Bhargava
Cc: Sergey Senozhatsky
Cc: Steven Rostedt
Link: http://lkml.kernel.org/r/20180301165150.410218...@linutronix.de
Signed-off-by: Ingo Molnar
---
include/linux/hrtimer.h | 2 --
kernel/time/hrtimer.c | 16 ++--
kernel/time/timekeeping.c | 4 +---
kernel/time/timekeeping.h | 1 -
4 files changed, 3 insertions(+), 20 deletions(-)
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index c7902ca7c9f4..78f456fcd242 100644
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -161,11 +161,9 @@ struct hrtimer_clock_base {
enum hrtimer_base_type {
HRTIMER_BASE_MONOTONIC,
HRTIMER_BASE_REALTIME,
- HRTIMER_BASE_BOOTTIME,
HRTIMER_BASE_TAI,
HRTIMER_BASE_MONOTONIC_SOFT,
HRTIMER_BASE_REALTIME_SOFT,
- HRTIMER_BASE_BOOTTIME_SOFT,
HRTIMER_BASE_TAI_SOFT,
HRTIMER_MAX_CLOCK_BASES,
};
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 23788100e214..9b082ce86325 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -90,11 +90,6 @@ DEFINE_PER_CPU(struct hrtimer_cpu_base, hrtimer_bases) =
.clockid = CLOCK_REALTIME,
.get_time = &ktime_get_real,
},
- {
- .index = HRTIMER_BASE_BOOTTIME,
- .clockid = CLOCK_BOOTTIME,
- .get_time = &ktime_get_boottime,
- },
{
.index = HRTIMER_BASE_TAI,
.clockid = CLOCK_TAI,
@@ -110,11 +105,6 @@ DEFINE_PER_CPU(struct hrtimer_cpu_base, hrtimer_bases) =
.clockid = CLOCK_REALTIME,
.get_time = &ktime_get_real,
},
- {
- .index = HRTIMER_BASE_BOOTTIME_SOFT,
- .clockid = CLOCK_BOOTTIME,
- .get_time = &ktime_get_boottime,
- },
{
.index = HRTIMER_BASE_TAI_SOFT,
.clockid = CLOCK_TAI,
@@ -129,7 +119,7 @@ static const int hrtimer_clock_to_base_table[MAX_CLOCKS] = {
[CLOCK_REALTIME]= HRTIMER_BASE_REALTIME,
[CLOCK_MONOTONIC] = HRTIMER_BASE_MONOTONIC,
- [CLOCK_BOOTTIME]= HRTIMER_BASE_BOOTTIME,
+ [CLOCK_BOOTTIME]= HRTIMER_BASE_MONOTONIC,
[CLOCK_TAI] = HRTIMER_BASE_TAI,
};
@@ -565,14 +555,12 @@ __hrtimer_get_next_event(struct hrtimer_cpu_base
*cpu_base, unsigned int active_
static inline ktime_t hrtimer_update_base(struct hrtimer_cpu_base *base)
{
ktime_t *offs_real = &base->clock_base[HRTIMER_BASE_REALTIME].offset;
- ktime_t *offs_boot = &base->clock_base[HRTIMER_BASE_BOOTTIME].offset;
ktime_t *offs_tai = &base->clock_base[HRTIMER_BASE_TAI].offset;
ktime_t now = ktime_get_update_offsets_now(&base->clock_was_set_seq,
- offs_real, offs_boot, offs_tai);
+ offs_real, offs_tai);
base->clock_base[HRTIMER_BASE_REALTIME_SOFT].offset = *offs_real;
- base->clock_base[HRTIMER_BASE_BOOTTIME_SOFT].offset = *offs_boot;
base->clock_base[HRTIMER_BASE_TAI_SOFT].offset = *offs_tai;
return now;
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 8355c8803282..ca90219a1e73 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -2195,7 +2195,6 @@ void do_timer(unsigned long ticks)
* ktime_get_update_offsets_now - hrtimer helper
* @cwsseq:pointer to check and store the clock was set sequence number
* @offs_real: pointer to storage for monotonic -> realtime offset
- * @offs_boot: pointer to storage for monotonic -> boottime offset
* @offs_tai: pointer to storage for monotonic -> clock tai offset
*
* Returns current monotonic time and updates the offsets if the
@@ -2205,7 +2204,7 @@ void do_timer(unsigned long ticks)
* Called from hrtimer_interrupt() or retrigger_next_event()
*/
ktime_t ktime_get_update_offsets_now(unsigned int *cwsseq, ktime_t *offs_real,
-ktime_t *offs_boot, ktime_t *offs_tai)
+
[tip:timers/core] tracing: Unify the "boot" and "mono" tracing clocks
Commit-ID: 92af4dcb4e1c5f58dc337bc97bdffd4e853dbc93
Gitweb: https://git.kernel.org/tip/92af4dcb4e1c5f58dc337bc97bdffd4e853dbc93
Author: Thomas Gleixner
AuthorDate: Thu, 1 Mar 2018 17:33:38 +0100
Committer: Ingo Molnar
CommitDate: Tue, 13 Mar 2018 07:34:23 +0100
tracing: Unify the "boot" and "mono" tracing clocks
Unify the "boot" and "mono" tracing clocks and document the new behaviour.
Signed-off-by: Thomas Gleixner
Cc: Dmitry Torokhov
Cc: John Stultz
Cc: Jonathan Corbet
Cc: Kevin Easton
Cc: Linus Torvalds
Cc: Mark Salyzyn
Cc: Michael Kerrisk
Cc: Peter Zijlstra
Cc: Petr Mladek
Cc: Prarit Bhargava
Cc: Sergey Senozhatsky
Cc: Steven Rostedt
Link: http://lkml.kernel.org/r/20180301165150.489635...@linutronix.de
Signed-off-by: Ingo Molnar
---
Documentation/trace/ftrace.txt | 14 +++---
include/linux/timekeeping.h| 6 --
kernel/trace/trace.c | 2 +-
3 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
index d4601df6e72e..bf89f98bfdb9 100644
--- a/Documentation/trace/ftrace.txt
+++ b/Documentation/trace/ftrace.txt
@@ -449,17 +449,9 @@ of ftrace. Here is a list of some of the key files:
which is montonic but is not subject to any rate adjustments
and ticks at the same rate as the hardware clocksource.
- boot: This is the boot clock (CLOCK_BOOTTIME) and is based on the
- fast monotonic clock, but also accounts for time spent in
- suspend. Since the clock access is designed for use in
- tracing in the suspend path, some side effects are possible
- if clock is accessed after the suspend time is accounted before
- the fast mono clock is updated. In this case, the clock update
- appears to happen slightly sooner than it normally would have.
- Also on 32-bit systems, it's possible that the 64-bit boot
offset
- sees a partial update. These effects are rare and post
- processing should be able to handle them. See comments in the
- ktime_get_boot_fast_ns() function for more information.
+ boot: Same as mono. Used to be a separate clock which accounted
+ for the time spent in suspend while CLOCK_MONOTONIC did
+ not.
To set a clock, simply echo the clock name into this file.
diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
index abb396731332..82c219dfd3bb 100644
--- a/include/linux/timekeeping.h
+++ b/include/linux/timekeeping.h
@@ -113,12 +113,6 @@ extern u64 ktime_get_mono_fast_ns(void);
extern u64 ktime_get_raw_fast_ns(void);
extern u64 ktime_get_real_fast_ns(void);
-/* Clock BOOTTIME compatibility wrappers */
-static inline u64 ktime_get_boot_fast_ns(void)
-{
- return ktime_get_mono_fast_ns();
-}
-
/*
* timespec64 interfaces utilizing the ktime based ones
*/
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 20a2300ae4e8..300f4ea39646 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -1164,7 +1164,7 @@ static struct {
{ trace_clock, "perf", 1 },
{ ktime_get_mono_fast_ns, "mono", 1 },
{ ktime_get_raw_fast_ns,"mono_raw", 1 },
- { ktime_get_boot_fast_ns, "boot", 1 },
+ { ktime_get_mono_fast_ns, "boot", 1 },
ARCH_TRACE_CLOCKS
};
Re: [v2 14/17 4/4] mfd: tps65910: Checking patch structures
> How have you managed to insert 4 patches into the x/17 thread? I dared to group the desired patch series into dedicated mail threads. Regards, Markus
Re: [PATCH] proc: reject "." and ".." as filenames
On Mon, Mar 12, 2018 at 04:00:18PM -0700, Andrew Morton wrote:
> - if (qstr.len == 1 && fn[0] == '.') {
> - WARN(1, "name '.'\n");
> + if (WARN(qstr.len == 1 && fn[0] == '.', "name '.'\n"))
> return NULL;
> - }
Oh, I hate this style of WARN.
For one thing it overlaps with comma operator.
Re: [PATCH 1/4] gpio: Remove VLA from gpiolib
On 2018-03-13 00:40, Laura Abbott wrote: > On 03/12/2018 08:00 AM, Rasmus Villemoes wrote: >> >> Hm, it seems you're now only clearing the first word of mask, not the >> entire allocation. Why not just use kcalloc() instead of kmalloc_array >> to have it automatically cleared? > > Bleh, I didn't think through that carefully. I'll just switch > to kcalloc, especially since it calls kmalloc_array. > >> Other random thoughts: maybe two allocations for each loop iteration is >> a bit much. Maybe do a first pass over the array and collect the maximal >> chip->ngpio, do the memory allocation and freeing outside the loop (then >> you'd of course need to preserve the memset() with appropriate length >> computed). And maybe even just do one allocation, making bits point at >> the second half. >> > > I was trying to make minimal changes and match the existing code. Well, textually you may be making the minimal changes (though the error handling adds some "boilerplate" kfree()s etc.), but semantically adding two kmallocs in a loop could be a big deal. Dunno, maybe in practice all the gpios (almost always) belong to the same chip, so there's only one iteration through the loop anyway. > Is this likely to be an actual hot path to optimize? No idea, it was just a drive-by comment, so also... >> Does the set function need to be updated to return an int to be able to >> inform the caller that memory allocation failed? > > That would involve changing the public API. I don't have a problem > doing so if that's what you want. ... I don't "want" anything, that'll be for the gpio maintainers to decide. Rasmus
Re: Regression from efi: call get_event_log before ExitBootServices
On Mon, Mar 12, 2018 at 10:03 PM Ard Biesheuvel wrote: > On 12 March 2018 at 19:55, Thiebaud Weksteen wrote: > > On Mon, Mar 12, 2018 at 7:33 PM Jeremy Cline wrote: > > > >> On 03/12/2018 02:29 PM, Thiebaud Weksteen wrote: > >> > On Mon, Mar 12, 2018 at 6:30 PM Ard Biesheuvel < > > ard.biesheu...@linaro.org> > >> > wrote: > >> > > >> >> On 12 March 2018 at 17:01, Jeremy Cline wrote: > >> >>> On 03/12/2018 10:56 AM, Ard Biesheuvel wrote: > >> On 12 March 2018 at 14:30, Jeremy Cline wrote: > >> > On 03/12/2018 07:08 AM, Ard Biesheuvel wrote: > >> >> On 10 March 2018 at 10:45, Thiebaud Weksteen > >> > wrote: > >> >>> On Fri, Mar 9, 2018 at 5:54 PM Jeremy Cline > >> > wrote: > >> >>> > >> On Fri, Mar 09, 2018 at 10:43:50AM +, Thiebaud Weksteen > > wrote: > >> > Thanks a lot for trying out the patch! > >> > > >> > Please don't modify your install at this stage, I think we are > >> > hitting a > >> > firmware bug and that would be awesome if we can fix how we are > >> >>> handling it. > >> > So, if we reach that stage in the function it could either be > >> > that: > >> > * The allocation did not succeed, somehow, but the firmware > > still > >> >>> returned > >> > EFI_SUCCEED. > >> > * The size requested is incorrect (I'm thinking something like a > >> > 1G of > >> > log). This would be due to either a miscalculation of log_size > >> >>> (possible) > >> > or; the returned values of GetEventLog are not correct. > >> > I'm sending a patch to add checks for these. Could you please > >> > apply and > >> > retest? > >> > Again, thanks for helping debugging this. > >> >>> > >> No problem, thanks for the help :) > >> >>> > >> With the new patch: > >> >>> > >> Locating the TCG2Protocol > >> Calling GetEventLog on TCG2Protocol > >> Log returned > >> log_location is not empty > >> log_size != 0 > >> log_size < 1M > >> Allocating memory for storing the logs > >> Returned from memory allocation > >> Copying log to new location > >> >>> > >> And then it hangs. I added a couple more print statements: > >> >>> > >> diff --git a/drivers/firmware/efi/libstub/tpm.c > >> >>> b/drivers/firmware/efi/libstub/tpm.c > >> index ee3fac109078..1ab5638bc50e 100644 > >> --- a/drivers/firmware/efi/libstub/tpm.c > >> +++ b/drivers/firmware/efi/libstub/tpm.c > >> @@ -148,8 +148,11 @@ void > >> >>> efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg) > >> efi_printk(sys_table_arg, "Copying log to new > >> > location\n"); > >> >>> > >> memset(log_tbl, 0, sizeof(*log_tbl) + log_size); > >> + efi_printk(sys_table_arg, "Successfully memset log_tbl to > >> > 0\n"); > >> log_tbl->size = log_size; > >> + efi_printk(sys_table_arg, "Set log_tbl->size\n"); > >> log_tbl->version = EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2; > >> + efi_printk(sys_table_arg, "Set log_tbl-version\n"); > >> memcpy(log_tbl->log, (void *) first_entry_addr, > > log_size); > >> >>> > >> efi_printk(sys_table_arg, "Installing the log into the > >> >>> configuration table\n"); > >> >>> > >> and it's hanging at "memset(log_tbl, 0, sizeof(*log_tbl) + > >> > log_size);" > >> >>> > >> >>> Thanks. Well, it looks like the memory that is supposedly > > allocated > >> > is not > >> >>> usable. I'm thinking this is a firmware bug. > >> >>> Ard, would you agree on this assumption? Thoughts on how to > > proceed? > >> >>> > >> >> > >> >> I am rather puzzled why the allocate_pool() should succeed and the > >> >> subsequent memset() should fail. This does not look like an issue > >> > that > >> >> is intimately related to TPM2 support, rather an issue in the > >> > firmware > >> >> that happens to get tickled after the change. > >> >> > >> >> Would you mind trying replacing EFI_LOADER_DATA with > >> >> EFI_BOOT_SERVICES_DATA in the allocate_pool() call? > >> > > >> > Replacing EFI_LOADER_DATA with EFI_BOOT_SERVICES_DATA still hangs at > >> > the > >> > memset() call. > >> > > >> > >> Could you try the following please? (attached as well in case gmail > >> > mangles it) > >> > >> diff --git a/drivers/firmware/efi/libstub/tpm.c > >> b/drivers/firmware/efi/libstub/tpm.c > >> index 2298560cea72..30d960a344b7 100644 > >> --- a/drivers/firmware/efi/libstub/tpm.c > >> +++ b/drivers/firmware/efi/libstub/tpm.c > >> @@ -70,6 +70,8 @@ void > >> efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg) > >> size_t log_size, last_entry_size; > >>
Re: [2/2] net/usb/ax88179_178a: Delete three unnecessary variables in ax88179_chk_eee()
>> Use three values directly for a condition check without assigning them >> to intermediate variables. > > Hi, > > what is the benefit of this? I proposed a small source code reduction. Other software design directions might become more interesting for this use case. Regards, Markus
[PATCH v6] usb: core: Add "quirks" parameter for usbcore
Trying quirks in usbcore needs to rebuild the driver or the entire kernel if it's builtin. It can save a lot of time if usbcore has similar ability like "usbhid.quirks=" and "usb-storage.quirks=". Rename the original quirk detection function to "static" as we introduce this new "dynamic" function. Now users can use "usbcore.quirks=" as short term workaround before the next kernel release. Also, the quirk parameter can XOR the builtin quirks for debugging purpose. This is inspired by usbhid and usb-storage. Signed-off-by: Kai-Heng Feng --- v6: Add missed header file . v5: Use module_param_cb() to get notified when parameter changes. Replace linked list with array. v4: Use kmalloc() to reduce memory usage. Remove tolower() so we can use capital character in the future. v3: Stop overridding static quirks. Use XOR for dynamic quirks. Save parsed quirk as a list to avoid parsing quirk table everytime. v2: Use in-kernel tolower() function. Documentation/admin-guide/kernel-parameters.txt | 55 drivers/usb/core/quirks.c | 178 +++- drivers/usb/core/usb.c | 1 + drivers/usb/core/usb.h | 1 + 4 files changed, 230 insertions(+), 5 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 1d1d53f85ddd..70a7398c20e2 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -4368,6 +4368,61 @@ usbcore.nousb [USB] Disable the USB subsystem + usbcore.quirks= + [USB] A list of quirks entries to supplement or + override the built-in usb core quirk list. List + entries are separated by commas. Each entry has + the form VID:PID:Flags where VID and PID are Vendor + and Product ID values (4-digit hex numbers) and + Flags is a set of characters, each corresponding + to a common usb core quirk flag as follows: + a = USB_QUIRK_STRING_FETCH_255 (string + descriptors must not be fetched using + a 255-byte read); + b = USB_QUIRK_RESET_RESUME (device can't resume + correctly so reset it instead); + c = USB_QUIRK_NO_SET_INTF (device can't handle + Set-Interface requests); + d = USB_QUIRK_CONFIG_INTF_STRINGS (device can't + handle its Configuration or Interface + strings); + e = USB_QUIRK_RESET (device can't be reset + (e.g morph devices), don't use reset); + f = USB_QUIRK_HONOR_BNUMINTERFACES (device has + more interface descriptions than the + bNumInterfaces count, and can't handle + talking to these interfaces); + g = USB_QUIRK_DELAY_INIT (device needs a pause + during initialization, after we read + the device descriptor); + h = USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL (For + high speed and super speed interrupt + endpoints, the USB 2.0 and USB 3.0 spec + require the interval in microframes (1 + microframe = 125 microseconds) to be + calculated as interval = 2 ^ + (bInterval-1). + Devices with this quirk report their + bInterval as the result of this + calculation instead of the exponent + variable used in the calculation); + i = USB_QUIRK_DEVICE_QUALIFIER (device can't + handle device_qualifier descriptor + requests); + j = USB_QUIRK_IGNORE_REMOTE_WAKEUP (device + generates spurious wakeup, ignore + remote wakeup capability); + k = USB_QUIRK_NO_LPM (device can't handle Link + Power Management); + l = USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL +
Re: [PATCH] ipmi:pci: Blacklist a Realtek "IPMI" device
Hi, On Mon, Feb 26, 2018 at 10:50 AM, wrote: > From: Corey Minyard > > Realtek has some sort of "Virtual" IPMI device on the PCI bus as a > KCS controller, but whatever it is, it's not one. Ignore it if seen. > > Reported-by: Chris Chiu > Signed-off-by: Corey Minyard > --- > > I haven't heard anything from you on this. Here is a patch that should > blacklist that device, though I don't have a way to easily test it. > If you would prefer this, could you test it? Sorry for the slow response, and thanks for the patch! We have tested it here and it seems to be working fine now - the IPMI stuff no longer initializes system interfaces, and hence doesn't get in the way when going into suspend or reboot later. This is a consumer desktop platform, so if some kind of IPMI functionality is really present in the hardware then it is not really going to be relevant for the ordinary user. So it should be fine to just ignore the hardware as you have done. Thanks Daniel
Re: [PATCH] dma-mapping: move dma configuration to bus infrastructure
On Tue, Mar 13, 2018 at 04:22:53AM +, Nipun Gupta wrote: > > Isn't this one or the other one but not both? > > > > Something like: > > > > if (dev->of_node) > > of_dma_deconfigure(dev); > > else > > acpi_dma_deconfigure(dev); > > > > should work. > > I understand your point. Seems reasonable as we should not expect > the 'of/acpi DMA deconfigure' API to not fail when they are not configured. > > But, here we would also need to get dma_device (just as we get in > 'pci_dma_configure') and need a check on it as for PCI there 'of_node' > is present in the dma_dev. Both of_dma_deconfigure and acpi_dma_deconfigure just end up calling arch_teardown_dma_ops. So my preference would be to just remove of_dma_deconfigure and acpi_dma_deconfigure and call arch_teardown_dma_ops as a prep patch before this one.
Re: [PATCH v2 12/13] i2c: qup: reorganization of driver code to remove polling for qup v1
Hi Abhishek,
On 3/12/2018 6:45 PM, Abhishek Sahu wrote:
> Following are the major issues in current driver code
>
> 1. The current driver simply assumes the transfer completion
>whenever its gets any non-error interrupts and then simply do the
>polling of available/free bytes in FIFO.
> 2. The block mode is not working properly since no handling in
>being done for OUT_BLOCK_WRITE_REQ and IN_BLOCK_READ_REQ.
>
> Because of above, i2c v1 transfers of size greater than 32 are failing
> with following error message
>
> i2c_qup 78b6000.i2c: timeout for fifo out full
>
> To make block mode working properly and move to use the interrupts
> instead of polling, major code reorganization is required. Following
> are the major changes done in this patch
>
> 1. Remove the polling of TX FIFO free space and RX FIFO available
>bytes and move to interrupts completely. QUP has QUP_MX_OUTPUT_DONE,
>QUP_MX_INPUT_DONE, OUT_BLOCK_WRITE_REQ and IN_BLOCK_READ_REQ
>interrupts to handle FIFO’s properly so check all these interrupts.
> 2. During write, For FIFO mode, TX FIFO can be directly written
>without checking for FIFO space. For block mode, the QUP will generate
>OUT_BLOCK_WRITE_REQ interrupt whenever it has block size of available
>space.
> 3. During read, both TX and RX FIFO will be used. TX will be used
>for writing tags and RX will be used for receiving the data. In QUP,
>TX and RX can operate in separate mode so configure modes accordingly.
> 4. For read FIFO mode, wait for QUP_MX_INPUT_DONE interrupt which
>will be generated after all the bytes have been copied in RX FIFO. For
>read Block mode, QUP will generate IN_BLOCK_READ_REQ interrupts
>whenever it has block size of available data.
>
> Signed-off-by: Abhishek Sahu
> ---
>
Reviewed-by: Sricharan R
Regards,
Sricharan
> * Changes from v1:
>
> 1. Fixed auto build test WARNING ‘idx' may be used uninitialized
>in this function
> 2. Removed event-based completion and changed transfer completion
>detection logic in interrupt handler
>
> drivers/i2c/busses/i2c-qup.c | 368
> ++-
> 1 file changed, 224 insertions(+), 144 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
> index 4ebd922..3bf3c34 100644
> --- a/drivers/i2c/busses/i2c-qup.c
> +++ b/drivers/i2c/busses/i2c-qup.c
> @@ -64,8 +64,11 @@
> #define QUP_IN_SVC_FLAG BIT(9)
> #define QUP_MX_OUTPUT_DONE BIT(10)
> #define QUP_MX_INPUT_DONEBIT(11)
> +#define OUT_BLOCK_WRITE_REQ BIT(12)
> +#define IN_BLOCK_READ_REQBIT(13)
>
> /* I2C mini core related values */
> +#define QUP_NO_INPUT BIT(7)
> #define QUP_CLOCK_AUTO_GATE BIT(13)
> #define I2C_MINI_CORE(2 << 8)
> #define I2C_N_VAL15
> @@ -137,13 +140,36 @@
> #define DEFAULT_CLK_FREQ 10
> #define DEFAULT_SRC_CLK 2000
>
> +/*
> + * count: no of blocks
> + * pos: current block number
> + * tx_tag_len: tx tag length for current block
> + * rx_tag_len: rx tag length for current block
> + * data_len: remaining data length for current message
> + * total_tx_len: total tx length including tag bytes for current QUP transfer
> + * total_rx_len: total rx length including tag bytes for current QUP transfer
> + * tx_fifo_free: number of free bytes in current QUP block write.
> + * fifo_available: number of available bytes in RX FIFO for current
> + * QUP block read
> + * rx_bytes_read: if all the bytes have been read from rx FIFO.
> + * is_tx_blk_mode: whether tx uses block or FIFO mode in case of non BAM
> xfer.
> + * is_rx_blk_mode: whether rx uses block or FIFO mode in case of non BAM
> xfer.
> + * tags: contains tx tag bytes for current QUP transfer
> + */
> struct qup_i2c_block {
> - int count;
> - int pos;
> - int tx_tag_len;
> - int rx_tag_len;
> - int data_len;
> - u8 tags[6];
> + int count;
> + int pos;
> + int tx_tag_len;
> + int rx_tag_len;
> + int data_len;
> + int total_tx_len;
> + int total_rx_len;
> + int tx_fifo_free;
> + int fifo_available;
> + boolrx_bytes_read;
> + boolis_tx_blk_mode;
> + boolis_rx_blk_mode;
> + u8 tags[6];
> };
>
> struct qup_i2c_tag {
> @@ -186,6 +212,7 @@ struct qup_i2c_dev {
>
> /* To check if this is the last msg */
> boolis_last;
> + boolis_qup_v1;
>
> /* To configure when bus is in run state */
> int config_run;
> @@ -202,11 +229,18 @@ struct qup_i2c_dev {
> struct qup_i2c_bam btx;
>
> struct completion xfer;
> + /* function to write data in tx fifo */
> + void (*write_tx_fifo)(struct qup_i2c_d
[tip:perf/core 36/37] kernel/events/core.c:2856:8: error: implicit declaration of function 'modify_user_hw_breakpoint_check'; did you mean 'modify_user_hw_breakpoint'?
tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf/core
head: 5acc575fec9f424f0b557844dbda8aed57baae1e
commit: f30b09b7f8aed3180d6e2f2984e32e91c7a7fcd1 [36/37] perf/core: Implement
fast breakpoint modification via _IOC_MODIFY_ATTRIBUTES
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout f30b09b7f8aed3180d6e2f2984e32e91c7a7fcd1
# save the attached .config to linux build tree
make.cross ARCH=sparc64
All errors (new ones prefixed by >>):
kernel/events/core.c: In function 'perf_event_modify_breakpoint':
>> kernel/events/core.c:2856:8: error: implicit declaration of function
>> 'modify_user_hw_breakpoint_check'; did you mean 'modify_user_hw_breakpoint'?
>> [-Werror=implicit-function-declaration]
err = modify_user_hw_breakpoint_check(bp, attr, true);
^~~
modify_user_hw_breakpoint
cc1: some warnings being treated as errors
vim +2856 kernel/events/core.c
2848
2849 static int perf_event_modify_breakpoint(struct perf_event *bp,
2850 struct perf_event_attr *attr)
2851 {
2852 int err;
2853
2854 _perf_event_disable(bp);
2855
> 2856 err = modify_user_hw_breakpoint_check(bp, attr, true);
2857 if (err) {
2858 if (!bp->attr.disabled)
2859 _perf_event_enable(bp);
2860
2861 return err;
2862 }
2863
2864 if (!attr->disabled)
2865 _perf_event_enable(bp);
2866 return 0;
2867 }
2868
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCHv2] staging: wilc1000: use pre-defined macro is_broadcast_ether_addr
Reviewed-by: Ajay Singh On Mon, 12 Mar 2018 15:09:03 +0530 wrote: > From: HariPrasath Elango > Please avoid use of 'From' tag specially when there is only one 'Signed-off-by' tag and its same. > Use the kernel pre-defined macro is_broadcast_ether_addr() instead of > doing a memcmp here. > > Signed-off-by: HariPrasath Elango > --- Regards, Ajay
linux-next: Tree for Mar 13
Hi all, Changes since 20180309: Removed tree: cris (the architecture is being removed) The qcom tree gained a conflict against the amlogic tree. The net-next tree gained conflicts against the net tree. The drm tree gained a conflict against Linus' tree and a build failure for which I reverted a patch. The sound-asoc tree gained a build failure for which I applied a patch. The tip tree gained a conflict against the arm-soc tree. The staging tree gained conflicts against the vfs tree. The akpm-current tree still had its build failure for which I reverted a commit. Non-merge commits (relative to Linus' tree): 6844 6974 files changed, 315028 insertions(+), 179044 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 259 trees (counting Linus' and 44 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (fc6eabbbf8ef Merge tag 'nfs-for-4.16-4' of git://git.linux-nfs.org/projects/trondmy/linux-nfs) Merging fixes/master (7928b2cbe55b Linux 4.16-rc1) Merging kbuild-current/fixes (55fe6da9efba kbuild: Handle builtin dtb file names containing hyphens) Merging arc-current/for-curr (661e50bc8532 Linux 4.16-rc4) Merging arm-current/fixes (091f02483df7 ARM: net: bpf: clarify tail_call index) Merging arm64-fixes/for-next/fixes (e21da1c99200 arm64: Relax ARM_SMCCC_ARCH_WORKAROUND_1 discovery) Merging m68k-current/for-linus (2334b1ac1235 MAINTAINERS: Add NuBus subsystem entry) Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups) Merging powerpc-fixes/fixes (b0c41b8b6e43 powerpc/pseries: Fix vector5 in ibm architecture vector table) Merging sparc/master (aebb48f5e465 sparc64: fix typo in CONFIG_CRYPTO_DES_SPARC64 => CONFIG_CRYPTO_CAMELLIA_SPARC64) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (38fbbc9c23d0 Merge branch 'l2tp-fix-races-with-ipv4-mapped-ipv6-addresses') Merging bpf/master (b6b76dd62c56 error-injection: Fix to prohibit jump optimization) Merging ipsec/master (87cdf3148b11 xfrm: Verify MAC header exists before overwriting eth_hdr(skb)->h_proto) Merging netfilter/master (b747594829aa Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf) Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook mask only if set) Merging wireless-drivers/master (87de1201ddaa Merge branch 'erspan-fixes') Merging mac80211/master (a78872363614 cfg80211: add missing dependency to CFG80211 suboptions) Merging rdma-fixes/for-rc (28e9091e3119 RDMA/mlx5: Fix integer overflow while resizing CQ) Merging sound-current/for-linus (db45dc9540ea Merge tag 'asoc-fix-v4.16-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging pci-current/for-linus (fc110ebdd014 PCI: dwc: Fix enumeration end when reaching root subordinate) Merging driver-core.current/driver-core-linus (661e50bc8532 Linux 4.16-rc4) Merging tty.current/tty-linus (5d7f77ec72d1 serial: imx: fix bogus dev_err) Merging usb.current/usb-linus (914a020d4a97 Merge tag 'phy-for-4.16-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-linus) Merging usb-gadget-fixes/fixes (c6ba5084ce0d usb: gadget: udc: renesas_usb3: add binging for r8a77965) Merging usb-serial-fixes/usb-linus (7920a87c40db USB: serial: cp210x: add ELDAT Easyw
Re: [PATCH] dma-mapping: move dma configuration to bus infrastructure
> +int amba_dma_configure(struct device *dev)
> +{
> + enum dev_dma_attr attr;
> + int ret = 0;
> +
> + if (dev->of_node) {
> + ret = of_dma_configure(dev, dev->of_node);
> + } else if (has_acpi_companion(dev)) {
> + attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
> + if (attr != DEV_DMA_NOT_SUPPORTED)
> + ret = acpi_dma_configure(dev, attr);
> + }
> +
> + return ret;
This code sniplet is duplicated so many times that I think we should
just have some sort of dma_common_configure() for it that the various
busses can use.
> +void amba_dma_deconfigure(struct device *dev)
> +{
> + of_dma_deconfigure(dev);
> + acpi_dma_deconfigure(dev);
> +}
As mention in my previous reply I think we don't even need a deconfigure
callback at this point - just remove the ACPI and OF wrappers and
clear the dma ops.
Also in this series we should replace the force_dma flag by use of the
proper method, e.g. give a force parameter to of_dma_configure and the
new dma_common_configure helper that the busses that want it can set.
Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible
On Tue, 2018-03-13 at 11:11 +0800, Dou Liyang wrote: > I also > met the situation that BIOS told to ACPI that it could support > physical > CPUs hotplug, But actually, there was no hardware slots in the > machine. > the ACPI tables like user inputs which should be validated when we > use. This is exactly what happens on Skylake Xeon systems. When I check dmesg or this file: /sys/devices/system/cpu/possible on 2S (two socket) and 4S (four socket) systems, I see the same number 432. This number comes from ACPI MADT. I will speculate (did not see myself) that 8S systems will report the same number as well, because of the Skylake-SP (Scalable Platform) architecture. Number 432 is good for 8S systems, but it is way too large for 2S and 4S systems - 4x or 2x larger than the theoretical maximum. I do not know why BIOSes have to report unrealistically high numbers, I am just sharing my observation. So yes, Linux kernel's possible CPU count knowledge may be too large. If we use that number to evenly spread IRQ vectors among the CPUs, we end up with wasted vectors, and even bugs, as I observe on a 2S Skylake. Artem.
Re: [PATCH] staging: wilc1000: Fix code block alignment
On Mon, 12 Mar 2018 18:30:44 +0530 wrote: > From: HariPrasath Elango > > Fix the code alignment for a block of code to adhere to coding > guidelines > > Signed-off-by: HariPrasath Elango Reviewed-by: Ajay Singh Regards, Ajay
Re: [PATCH] staging: wilc1000: Destroy mutex object in deinitialization
On Mon, 12 Mar 2018 18:49:49 +0530 wrote: > From: HariPrasath Elango > > Destroy the mutex object that is initialized in wlan_init_locks() > > Signed-off-by: HariPrasath Elango Reviewed-by: Ajay Singh Regards, Ajay
Re: [PATCH] staging: wilc1000: use kmemdup instead of kmalloc and memcpy
On Tue, 13 Mar 2018 11:50:48 +0530 wrote: > From: HariPrasath Elango > > Kmalloc followed by memcpy can be replaced by kmemdup. > > Signed-off-by: HariPrasath Elango Reviewed-by: Ajay Singh Regards, Ajay
Re: [pci PATCH v5 1/4] pci: Add pci_sriov_configure_simple for PFs that don't manage VF resources
On Mon, Mar 12, 2018 at 01:17:00PM -0700, Alexander Duyck wrote: > No, I am aware of those. The problem is they aren't accessed as > function pointers. As such converting them to static inline functions > is easy. As I am sure you are aware an "inline" function doesn't > normally generate a function pointer. I think Keith's original idea of defining them to NULL is right. That takes care of all the current trivial assign to struct cases. If someone wants to call these functions they'll still need the ifdef around the call as those won't otherwise compile, but they probably want the ifdef around the whole caller anyway.
Re: aio poll, io_pgetevents and a new in-kernel poll API V5
ping? On Mon, Mar 05, 2018 at 01:27:07PM -0800, Christoph Hellwig wrote: > Hi all, > > this series adds support for the IOCB_CMD_POLL operation to poll for the > readyness of file descriptors using the aio subsystem. The API is based > on patches that existed in RHAS2.1 and RHEL3, which means it already is > supported by libaio. To implement the poll support efficiently new > methods to poll are introduced in struct file_operations: get_poll_head > and poll_mask. The first one returns a wait_queue_head to wait on > (lifetime is bound by the file), and the second does a non-blocking > check for the POLL* events. This allows aio poll to work without > any additional context switches, unlike epoll. > > To make the interface fully useful a new io_pgetevents system call is > added, which atomically saves and restores the signal mask over the > io_pgetevents system call. It it the logical equivalent to pselect and > ppoll for io_pgetevents. > > The corresponding libaio changes for io_pgetevents support and > documentation, as well as a test case will be posted in a separate > series. > > The changes were sponsored by Scylladb, and improve performance > of the seastar framework up to 10%, while also removing the need > for a privileged SCHED_FIFO epoll listener thread. > > git://git.infradead.org/users/hch/vfs.git aio-poll.5 > > Gitweb: > > http://git.infradead.org/users/hch/vfs.git/shortlog/refs/heads/aio-poll.5 > > Libaio changes: > > https://pagure.io/libaio.git io-poll > > Seastar changes (not updated for the new io_pgetevens ABI yet): > > https://github.com/avikivity/seastar/commits/aio > > Changes since V4: > - rebased ontop of Linux 4.16-rc4 > > Changes since V3: > - remove the pre-sleep ->poll_mask call in vfs_poll, >allow ->get_poll_head to return POLL* values. > > Changes since V2: > - removed a double initialization > - new vfs_get_poll_head helper > - document that ->get_poll_head can return NULL > - call ->poll_mask before sleeping > - various ACKs > - add conversion of random to ->poll_mask > - add conversion of af_alg to ->poll_mask > - lacking ->poll_mask support now returns -EINVAL for IOCB_CMD_POLL > - reshuffled the series so that prep patches and everything not >requiring the new in-kernel poll API is in the beginning > > Changes since V1: > - handle the NULL ->poll case in vfs_poll > - dropped the file argument to the ->poll_mask socket operation > - replace the ->pre_poll socket operation with ->get_poll_head as >in the file operations ---end quoted text---
Re: [3/5] Bluetooth: btmrvl: One check less in btmrvl_sdio_card_to_host()
>> @@ -797,12 +792,18 @@ static int btmrvl_sdio_card_to_host(struct
>> btmrvl_private *priv)
>> break;
>> }
>>
>> -exit:
>> -if (ret) {
>> -hdev->stat.err_rx++;
>> -kfree_skb(skb);
>> -}
>> +return 0;
>> +
>> +free_skb:
>> +kfree_skb(skb);
>> +e_io:
>> +ret = -EIO;
>> +goto increment_counter;
>>
>> +e_inval:
>> +ret = -EINVAL;
>> +increment_counter:
>> +hdev->stat.err_rx++;
>> return ret;
>
> Nope!
>
> This is not easier to read for me. This goto exit jumping and I hate that.
Can the software design direction become feasible to omit the repeated check
for the variable “ret” (and further initialisations)?
Regards,
Markus
Re: Regression from efi: call get_event_log before ExitBootServices
Hi,
On 12-03-18 20:55, Thiebaud Weksteen wrote:
On Mon, Mar 12, 2018 at 7:33 PM Jeremy Cline wrote:
On 03/12/2018 02:29 PM, Thiebaud Weksteen wrote:
On Mon, Mar 12, 2018 at 6:30 PM Ard Biesheuvel <
ard.biesheu...@linaro.org>
wrote:
On 12 March 2018 at 17:01, Jeremy Cline wrote:
On 03/12/2018 10:56 AM, Ard Biesheuvel wrote:
On 12 March 2018 at 14:30, Jeremy Cline wrote:
On 03/12/2018 07:08 AM, Ard Biesheuvel wrote:
On 10 March 2018 at 10:45, Thiebaud Weksteen
wrote:
On Fri, Mar 9, 2018 at 5:54 PM Jeremy Cline
wrote:
On Fri, Mar 09, 2018 at 10:43:50AM +, Thiebaud Weksteen
wrote:
Thanks a lot for trying out the patch!
Please don't modify your install at this stage, I think we are
hitting a
firmware bug and that would be awesome if we can fix how we are
handling it.
So, if we reach that stage in the function it could either be
that:
* The allocation did not succeed, somehow, but the firmware
still
returned
EFI_SUCCEED.
* The size requested is incorrect (I'm thinking something like a
1G of
log). This would be due to either a miscalculation of log_size
(possible)
or; the returned values of GetEventLog are not correct.
I'm sending a patch to add checks for these. Could you please
apply and
retest?
Again, thanks for helping debugging this.
No problem, thanks for the help :)
With the new patch:
Locating the TCG2Protocol
Calling GetEventLog on TCG2Protocol
Log returned
log_location is not empty
log_size != 0
log_size < 1M
Allocating memory for storing the logs
Returned from memory allocation
Copying log to new location
And then it hangs. I added a couple more print statements:
diff --git a/drivers/firmware/efi/libstub/tpm.c
b/drivers/firmware/efi/libstub/tpm.c
index ee3fac109078..1ab5638bc50e 100644
--- a/drivers/firmware/efi/libstub/tpm.c
+++ b/drivers/firmware/efi/libstub/tpm.c
@@ -148,8 +148,11 @@ void
efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg)
efi_printk(sys_table_arg, "Copying log to new
location\n");
memset(log_tbl, 0, sizeof(*log_tbl) + log_size);
+ efi_printk(sys_table_arg, "Successfully memset log_tbl to
0\n");
log_tbl->size = log_size;
+ efi_printk(sys_table_arg, "Set log_tbl->size\n");
log_tbl->version = EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2;
+ efi_printk(sys_table_arg, "Set log_tbl-version\n");
memcpy(log_tbl->log, (void *) first_entry_addr,
log_size);
efi_printk(sys_table_arg, "Installing the log into the
configuration table\n");
and it's hanging at "memset(log_tbl, 0, sizeof(*log_tbl) +
log_size);"
Thanks. Well, it looks like the memory that is supposedly
allocated
is not
usable. I'm thinking this is a firmware bug.
Ard, would you agree on this assumption? Thoughts on how to
proceed?
I am rather puzzled why the allocate_pool() should succeed and the
subsequent memset() should fail. This does not look like an issue
that
is intimately related to TPM2 support, rather an issue in the
firmware
that happens to get tickled after the change.
Would you mind trying replacing EFI_LOADER_DATA with
EFI_BOOT_SERVICES_DATA in the allocate_pool() call?
Replacing EFI_LOADER_DATA with EFI_BOOT_SERVICES_DATA still hangs at
the
memset() call.
Could you try the following please? (attached as well in case gmail
mangles it)
diff --git a/drivers/firmware/efi/libstub/tpm.c
b/drivers/firmware/efi/libstub/tpm.c
index 2298560cea72..30d960a344b7 100644
--- a/drivers/firmware/efi/libstub/tpm.c
+++ b/drivers/firmware/efi/libstub/tpm.c
@@ -70,6 +70,8 @@ void
efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg)
size_t log_size, last_entry_size;
efi_bool_t truncated;
void *tcg2_protocol;
+ unsigned long num_pages;
+ efi_physical_addr_t log_tbl_alloc;
status = efi_call_early(locate_protocol, &tcg2_guid, NULL,
&tcg2_protocol);
@@ -104,9 +106,12 @@ void
efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg)
}
/* Allocate space for the logs and copy them. */
- status = efi_call_early(allocate_pool, EFI_LOADER_DATA,
- sizeof(*log_tbl) + log_size,
- (void **) &log_tbl);
+ num_pages = DIV_ROUND_UP(sizeof(*log_tbl) + log_size,
EFI_PAGE_SIZE);
+ status = efi_call_early(allocate_pages,
+ EFI_ALLOCATE_ANY_PAGES,
+ EFI_LOADER_DATA,
+ num_pages,
+ &log_tbl_alloc);
if (status != EFI_SUCCESS) {
efi_printk(sys_table_arg,
@@ -114,6 +119,7 @@ void
efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg)
return;
}
+ log_tbl = (struct linux_efi_tpm_eventlog *)(unsigned
long)log_tbl_alloc;
memset(log_tbl, 0, sizeof(*log_tbl) + log_size);
log_tbl->size
Re: [PATCH v2 13/13] i2c: qup: reorganization of driver code to remove polling for qup v2
Hi Abhishek, On 3/12/2018 6:45 PM, Abhishek Sahu wrote: > Following are the major issues in current driver code > > 1. The current driver simply assumes the transfer completion >whenever its gets any non-error interrupts and then simply do the >polling of available/free bytes in FIFO. > 2. The block mode is not working properly since no handling in >being done for OUT_BLOCK_WRITE_REQ and IN_BLOCK_READ_READ. > 3. An i2c transfer can contain multiple message and QUP v2 >supports reconfiguration during run in which the mode should be same >for all the sub transfer. Currently the mode is being programmed >before every sub transfer which is functionally wrong. If one message >is less than FIFO length and other message is greater than FIFO >length, then transfers will fail. > > Because of above, i2c v2 transfers of size greater than 64 are failing > with following error message > > i2c_qup 78b6000.i2c: timeout for fifo out full > > To make block mode working properly and move to use the interrupts > instead of polling, major code reorganization is required. Following > are the major changes done in this patch > > 1. Remove the polling of TX FIFO free space and RX FIFO available >bytes and move to interrupts completely. QUP has QUP_MX_OUTPUT_DONE, >QUP_MX_INPUT_DONE, OUT_BLOCK_WRITE_REQ and IN_BLOCK_READ_REQ >interrupts to handle FIFO’s properly so check all these interrupts. > 2. Determine the mode for transfer before starting by checking >all the tx/rx data length in each message. The complete message can be >transferred either in DMA mode or Programmed IO by FIFO/Block mode. >in DMA mode, both tx and rx uses same mode but in PIO mode, the TX and >RX can be in different mode. > 3. During write, For FIFO mode, TX FIFO can be directly written >without checking for FIFO space. For block mode, the QUP will generate >OUT_BLOCK_WRITE_REQ interrupt whenever it has block size of available >space. > 4. During read, both TX and RX FIFO will be used. TX will be used >for writing tags and RX will be used for receiving the data. In QUP, >TX and RX can operate in separate mode so configure modes accordingly. > 5. For read FIFO mode, wait for QUP_MX_INPUT_DONE interrupt which >will be generated after all the bytes have been copied in RX FIFO. For >read Block mode, QUP will generate IN_BLOCK_READ_REQ interrupts >whenever it has block size of available data. > 6. Split the transfer in chunk of one QUP block size(256 bytes) >and schedule each block separately. QUP v2 supports reconfiguration >during run in which QUP can transfer multiple blocks without issuing a >stop events. > 7. Port the SMBus block read support for new code changes. > > Signed-off-by: Abhishek Sahu > --- > Reviewed-by: Sricharan R Regards, Sricharan > * Changes from v1: > > 1. Removed event-based completion and changed transfer completion >detection logic in interrupt handler > 2. Fixed function comments as suggested in v1 review comments > 3. Removed blk_mode_threshold from global structure > 4. Improved determine mode logic for QUP v2 transfers > > drivers/i2c/busses/i2c-qup.c | 900 > +-- > 1 file changed, 515 insertions(+), 385 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c > index 3bf3c34..904dfec 100644 > --- a/drivers/i2c/busses/i2c-qup.c > +++ b/drivers/i2c/busses/i2c-qup.c > @@ -141,17 +141,40 @@ > #define DEFAULT_SRC_CLK 2000 > > /* > + * Max tags length (start, stop and maximum 2 bytes address) for each QUP > + * data transfer > + */ > +#define QUP_MAX_TAGS_LEN 4 > +/* Max data length for each DATARD tags */ > +#define RECV_MAX_DATA_LEN254 > +/* TAG length for DATA READ in RX FIFO */ > +#define READ_RX_TAGS_LEN 2 > + > +/* > * count: no of blocks > * pos: current block number > * tx_tag_len: tx tag length for current block > * rx_tag_len: rx tag length for current block > * data_len: remaining data length for current message > + * cur_blk_len: data length for current block > * total_tx_len: total tx length including tag bytes for current QUP transfer > * total_rx_len: total rx length including tag bytes for current QUP transfer > + * tx_fifo_data_pos: current byte number in TX FIFO word > * tx_fifo_free: number of free bytes in current QUP block write. > + * rx_fifo_data_pos: current byte number in RX FIFO word > * fifo_available: number of available bytes in RX FIFO for current > * QUP block read > + * tx_fifo_data: QUP TX FIFO write works on word basis (4 bytes). New byte > write > + *to TX FIFO will be appended in this data and will be written to > + *TX FIFO when all the 4 bytes are available. > + * rx_fifo_data: QUP RX FIFO read works on word basis (4 bytes). This will > + *contains the 4 bytes of RX data. > + * cur
Re: [PATCH AUTOSEL for 4.14 065/110] led: core: Fix brightness setting when setting delay_off=0
Hi!
> > At least 7b6af2c531 ("leds: core: Fix regression caused by commit
> > 2b83ff96f51d") is missing, causing visible regressions (LEDs not working at
> > all) on some OpenWrt devices. This was fixed in 4.4.121 by reverting the
> > offending commit, but if I followed the discussion correctly, 4.9 should
> > get the follow-up commit 7b6af2c531 instead (like 4.14 already did).
> >
> > Jacek's mail I replied to mentions that eb1610b4c273 ("led: core: Fix
> > blink_brightness setting race") should be included in 4.9 as well, but I
> > don't know the impact of the issue it fixes.
>
> It doesn't fix any reported issue, but is just an improvement
> aiming at preventing potential races while changing blink brightness.
>
> After taking closer look it turns out that for the patches in question
> to apply cleanly we need in 4.9 also a patch which introduces atomic
> bit fields for blink flags.
>
> Effectively, here is the list of patches required in 4.9 stable:
>
> Revert "led: core: Fix brightness setting when setting delay_off=0"
>
> followed by:
>
> a9c6ce57ec ("led: core: Use atomic bit-field for the blink-flags")
> eb1610b4c2 ("led: core: Fix blink_brightness setting race")
> 2b83ff96f5 ("led: core: Fix brightness setting when setting delay_off=0")
> 7b6af2c531 ("leds: core: Fix regression caused by commit 2b83ff96f51d")
For the record... there's no serious problem in LED subsystem in
v4.9. Just leave LED subsystem alone in v4.9-stable (reverting any
patches that were backported by some kind of bot that did not even
test them), and things will be fine.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH v3 0/2] kbuild: Fix corner caches with .cache.mk
Hi Douglas, 2018-03-13 15:11 GMT+09:00 Douglas Anderson : > This two-patches fixes two corner cases with .cache.mk that have been > reported. Neither problem was catastrophic, but certainly several > people ran into the problem solved by the first patch (can't build > after gcc upgrade) and wasted time debugging, so it's really a good > idea to fix. > > Sorry for the big delay between v2 and v3. I never quite caught up > with email after the holidays, but hopefully better late than never... If v3 had been sent in time for v4.15 I would have immediately queued it up. But, the situation has changed. The direction of the development is to move the compiler flags evaluation to the Kconfig phase, and remove the Kbuild cache. If you are interested in the background, here are some of resources: Linus' comment that finally moved this work forward: https://lkml.org/lkml/2018/2/7/527 Tons of discussion about the initial version: https://patchwork.kernel.org/patch/10207385/ The core patch in the latest version: https://patchwork.kernel.org/patch/10225355/ And, I am removing the Kbuild cache entirely: https://patchwork.kernel.org/patch/10225437/ I do not know how to handle your patches since I am removing the addressed code for 4.17-rc1, which is comming in a month or so. If this is a fatal problem, we can queue it up only for 4.16, but I do not hear problem reports these days... > Changes in v3: > - Fix as per Masahiro Yamada (move change to main Makefile) > - Use "uid 0" as the heuristic instead of install > - Do the checking in the main Makefile instead of Kbuild.include > > Changes in v2: > - Don't error if MAKECMDGOALS is blank. > > Douglas Anderson (2): > kbuild: Require a 'make clean' if we detect gcc changed underneath us > kbuild: Don't mess with the .cache.mk when root > > Makefile | 15 +++ > scripts/Kbuild.include | 2 ++ > 2 files changed, 17 insertions(+) > > -- > 2.16.2.660.g709887971b-goog > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best Regards Masahiro Yamada
Re: WARNING in kmalloc_slab (4)
On Tue, Mar 13, 2018 at 12:33:02AM -0700, syzbot wrote: > Hello, > > syzbot hit the following crash on net-next commit > f44b1886a5f876c87b5889df463ad7b97834ba37 (Fri Mar 9 18:10:06 2018 +) > Merge branch 's390-qeth-next' > > Unfortunately, I don't have any reproducer for this crash yet. > Raw console output is attached. > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+6a7e7ed886bde4346...@syzkaller.appspotmail.com > It will help syzbot understand when the bug is fixed. See footer for > details. > If you forward the report, please keep this part and the footer. > > WARNING: CPU: 1 PID: 27333 at mm/slab_common.c:1012 kmalloc_slab+0x5d/0x70 > mm/slab_common.c:1012 > Kernel panic - not syncing: panic_on_warn set ... > > syz-executor0: vmalloc: allocation failure: 17045651456 bytes, > mode:0x14080c0(GFP_KERNEL|__GFP_ZERO), nodemask=(null) > CPU: 1 PID: 27333 Comm: syz-executor2 Not tainted 4.16.0-rc4+ #260 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > __dump_stack lib/dump_stack.c:17 [inline] > dump_stack+0x194/0x24d lib/dump_stack.c:53 > panic+0x1e4/0x41c kernel/panic.c:183 > syz-executor0 cpuset= > __warn+0x1dc/0x200 kernel/panic.c:547 > / > mems_allowed=0 > report_bug+0x211/0x2d0 lib/bug.c:184 > fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178 > fixup_bug arch/x86/kernel/traps.c:247 [inline] > do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296 > do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315 > invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:986 > RIP: 0010:kmalloc_slab+0x5d/0x70 mm/slab_common.c:1012 > RSP: 0018:8801ccfc72f0 EFLAGS: 00010246 > RAX: RBX: 1018 RCX: 84ec4fc8 > RDX: 0ba7 RSI: RDI: 1018 > RBP: 8801ccfc72f0 R08: R09: 1100399f8e21 > R10: 8801ccfc7040 R11: 0001 R12: 0018 > R13: 8801ccfc7598 R14: 014080c0 R15: 8801aebaad80 > __do_kmalloc mm/slab.c:3700 [inline] > __kmalloc+0x25/0x760 mm/slab.c:3714 > kmalloc include/linux/slab.h:517 [inline] > kzalloc include/linux/slab.h:701 [inline] > xfrm_alloc_replay_state_esn net/xfrm/xfrm_user.c:442 [inline] This is likely fixed with: commit d97ca5d714a5334aecadadf696875da40f1fbf3e xfrm_user: uncoditionally validate esn replay attribute struct The patch is included in the ipsec pull request for the net tree I've sent this morning.
Re: [PATCH 5/5] Bluetooth: btmrvl: Use common error handling code in btmrvl_sdio_download_fw_w_helper()
>> Add a jump target so that the setting of a specific error code is stored
>> only once at the end of this function.
>>
>> Signed-off-by: Markus Elfring
>> ---
>> drivers/bluetooth/btmrvl_sdio.c | 13 +++--
>> 1 file changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/bluetooth/btmrvl_sdio.c
>> b/drivers/bluetooth/btmrvl_sdio.c
>> index 05c78fcc13ff..24ed62fe2aeb 100644
>> --- a/drivers/bluetooth/btmrvl_sdio.c
>> +++ b/drivers/bluetooth/btmrvl_sdio.c
>> @@ -601,8 +601,7 @@ static int btmrvl_sdio_download_fw_w_helper(struct
>> btmrvl_sdio_card *card)
>> " base0 = 0x%04X(%d)."
>> " Terminating download",
>> base0, base0);
>> -ret = -EIO;
>> -goto done;
>> +goto e_io;
>> }
>> base1 = sdio_readb(card->func,
>> card->reg->sq_read_base_addr_a1, &ret);
>> @@ -611,8 +610,7 @@ static int btmrvl_sdio_download_fw_w_helper(struct
>> btmrvl_sdio_card *card)
>> " base1 = 0x%04X(%d)."
>> " Terminating download",
>> base1, base1);
>> -ret = -EIO;
>> -goto done;
>> +goto e_io;
>> }
>>
>> len = (((u16) base1) << 8) | base0;
>> @@ -638,8 +636,7 @@ static int btmrvl_sdio_download_fw_w_helper(struct
>> btmrvl_sdio_card *card)
>> if (count > MAX_WRITE_IOMEM_RETRY) {
>> BT_ERR("FW download failure @%d, "
>> "over max retry count", offset);
>> -ret = -EIO;
>> -goto done;
>> +goto e_io;
>> }
>> BT_ERR("FW CRC error indicated by the helper: "
>> "len = 0x%04X, txlen = %d", len, txlen);
>> @@ -681,6 +678,10 @@ static int btmrvl_sdio_download_fw_w_helper(struct
>> btmrvl_sdio_card *card)
>> kfree(tmpfwbuf);
>> release_firmware(fw_firmware);
>> return ret;
>> +
>> +e_io:
>> +ret = -EIO;
>> +goto done;
>> }
>
> I am not applying this one. I see zero benefit in this change.
Would you care for a bit of object code reduction in this function
implementation.
> It is not even saving a single line since it actually is more code.
Should I fiddle with any other source code layout?
Do you find an extra blank line inappropriate before the added jump target
in this use case?
Regards,
Markus
Re: [PATCH v2 3/3] ALSA: hda: Disabled unused audio controller for Dell platforms with Switchable Graphics
On Mar 12, 2018, at 9:30 AM, mario.limoncie...@dell.com wrote: I think the missing aspect is that this is only used in AIO and laptop form factors where the discrete graphics is in a non-removable form factor. Why we are not checking if kernel is running on AIO or laptop form factor then? Or it is not possible? Kai Heng, can you please confirm if AIO sets chassis type properly? It should be 0Dh. If so, then I think as second check for chassis type should be possible for next version of this patch. The chassis type is correctly set as 0Dh on AIOs. Basically what I see there is that we need to detect if current HW platform has switchable graphics and check how is configured AUDIO MUX. But instead of directly checking hw state of audio MUX, we are trying to check something different which could get us information of state of the audio mux. I suspect that we do not have a way how to check audio MUX directly, so it needs to be done indirectly -- via some Dell SMBIOS call and some other heuristic. This is something which should be specified either in comment or in commit message (problem of type: we need X, but check for Y). And if we are doing this check indirectly, we should do the most specific test and not more general. Right. I think that PCI vendor ID check of audio device is more general test then checking if kernel is running on Dell laptop (check via DMI). And if we can check also if running on AIO or laptop form, then it would be more specific test. Running with your hypothetical though, what would happen is if it's on a non-Dell machine the PCI check would pass and then the code would not be executed by dell-laptop (since dell-smbios didn't load). Right. If it was on a Dell machine it would load but the BIOS would return either Switchable graphics turned off, or invalid token. Even though these aren't real for switchable graphics on Dell I don't see a problem with either of these situations if it ever came up. I see, this solution is working... ... but, I see there a very bad precedense. What would happen if another laptop manufactor comes with similar solution for hybrid graphics. Does it mean that hda audio driver would try to call for every one vendor its vendor dependent API function (EFI, SMM, WMI, whatever) to check if current HW has some switchable graphics and needs special checks? Those vendor dependent API functions (which Dell SMBIOS is) should be really called on vendor hardware. Otherwise audio drivers would load bunch of the other vendor dependent platform modules and all of those modules (except maximally one) just return error. Sure the more specific the check the less symbol requests needed that will fail. Kai Heng, Can you please use Alex Hung's OEM strings patch in your series to match "Dell System" in OEM strings too? Sure, but this probably need to wait till it gets merged in Linus' tree. Between chassis type, OEM strings match, and AMD vendor/Dell subsystem vendor that should satisfy all of Pali's concerns I think. If anyone thinks that's too much, please speak up. Compiling a whitelist is a wasted effort because it will have to change Every year for every new platform that has AMD switchable graphics. I agree, But see that this patch already uses vendor ID whitelisting. I mean making a whitelist of all individual affected Dell platforms will grow each year. I want to avoid that approach.
Re: [v2 14/17 4/4] mfd: tps65910: Checking patch structures
On Tue, 13 Mar 2018, SF Markus Elfring wrote: > > How have you managed to insert 4 patches into the x/17 thread? > > I dared to group the desired patch series into dedicated mail threads. Interesting. I've never seen that done before. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: Regression from efi: call get_event_log before ExitBootServices
On 13 March 2018 at 07:47, Hans de Goede wrote: > Hi, > > > On 12-03-18 20:55, Thiebaud Weksteen wrote: >> ... >> >> Hans, you said you configured the tablet to use the 32-bit version of grub >> instead >> of 64. Why's that? > > > Because this tablet, like (almost?) all Bay Trail hardware has a 32 bit > UEFI, > even though the processor is 64 bit capable (AFAIK 64 bit Windows drivers > were > not ready in time so all Bay Trail devices shipped with a 32 bit Windows). > > So this is running a 32 bit grub which boots a 64 bit kernel. > >> Jeremy, could you confirm if you are building the kernel in 64bit mode? Is >> your Android install working? (that is, what happens if you boot >> Boot)? > > > AFAIK the kernel on Jeremy's tablet (which I initially installed) is 64 bit. > > Could the problem perhaps be that the new code for the TPM event-log is > missing some handling to deal with running on a 32 bit firmware? I know the > rest of the kernel has special code to deal with this. > That is a very good point, and I missed that this is a 64-bit kernel running on 32-bit UEFI. The TPM code does use efi_call_proto() directly, and now I am thinking it is perhaps the allocate_pages() call that simply only initializes the low 32-bits of log_tbl. Jeremy, could you please try initializing tcg2_protocol and log_tbl to NULL at the start of the function?
Re: [PATCH v2 4/6] ASoC: sun4i-i2s: Add multi-lane functionality
On Mon, Mar 12, 2018 at 04:57:51PM +0100, codekip...@gmail.com wrote: > From: Marcus Cooper > > The i2s block supports multi-lane i2s output however this functionality > is only possible in earlier SoCs where the pins are exposed and for > the i2s block used for HDMI audio on the later SoCs. > > To enable this functionality, an optional property has been added to > the bindings. > > Signed-off-by: Marcus Cooper > --- > .../devicetree/bindings/sound/sun4i-i2s.txt| 3 ++ > sound/soc/sunxi/sun4i-i2s.c| 48 > +- > 2 files changed, 41 insertions(+), 10 deletions(-) > > diff --git a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt > b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt > index 48addef65b8f..3f966ac61b9e 100644 > --- a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt > +++ b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt > @@ -33,6 +33,9 @@ Optional properties: > configured to extend the slot width to the > value specified. Min 8, Max 32. > > +- allwinner,playback-channels: if this property is present then the number > + of available channels is extended and the > + outputs enabled. Isn't it something that is fixed for each generation of SoCs? Can't we attach it to the compatible? Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: Regression from efi: call get_event_log before ExitBootServices
On 13 March 2018 at 07:59, Ard Biesheuvel wrote: > On 13 March 2018 at 07:47, Hans de Goede wrote: >> Hi, >> >> >> On 12-03-18 20:55, Thiebaud Weksteen wrote: >>> > ... >>> >>> Hans, you said you configured the tablet to use the 32-bit version of grub >>> instead >>> of 64. Why's that? >> >> >> Because this tablet, like (almost?) all Bay Trail hardware has a 32 bit >> UEFI, >> even though the processor is 64 bit capable (AFAIK 64 bit Windows drivers >> were >> not ready in time so all Bay Trail devices shipped with a 32 bit Windows). >> >> So this is running a 32 bit grub which boots a 64 bit kernel. >> >>> Jeremy, could you confirm if you are building the kernel in 64bit mode? Is >>> your Android install working? (that is, what happens if you boot >>> Boot)? >> >> >> AFAIK the kernel on Jeremy's tablet (which I initially installed) is 64 bit. >> >> Could the problem perhaps be that the new code for the TPM event-log is >> missing some handling to deal with running on a 32 bit firmware? I know the >> rest of the kernel has special code to deal with this. >> > > That is a very good point, and I missed that this is a 64-bit kernel > running on 32-bit UEFI. > > The TPM code does use efi_call_proto() directly, *correctly* > and now I am thinking > it is perhaps the allocate_pages() call that simply only initializes > the low 32-bits of log_tbl. > > Jeremy, could you please try initializing tcg2_protocol and log_tbl to > NULL at the start of the function?
Re: Atheros 1525/QCA6174 BT issue
On Thu, 08 Mar 2018 10:16:46 +0100,
Takashi Iwai wrote:
>
> On Thu, 08 Mar 2018 10:06:51 +0100,
> Marcel Holtmann wrote:
> >
> > Hi Takashi,
> >
> > > we've got a but report about the broken Atheros BT on the recent
> > > kernels:
> > > http://bugzilla.opensuse.org/show_bug.cgi?id=1082504
> > >
> > > In short, btusb can't load the patch ar3k/AthrBT_0x0200.dfu, and
> > > this could be worked around by the patch to move 0cf3:3004 blacklist
> > > entry to use BTUSB_QCA_ROM instead of BTUSB_ATH3012.
> > >
> > > And this looks like a long-standing problem, at least for over two
> > > years. Many web pages suggest the same patch, but it's never merged
> > > to upstream.
> > >
> > > So this made me wonder what's going on. I see that the BTUSB_ATH3012
> > > quirk was originally introduced just for this chip id (0cf3:3004).
> > > Is it a different variant from the original chip that causes a
> > > problem?
> >
> > not all patches from distro kernel are sent upstream. I have not heard of
> > this specific issues, but happy to accept patches to get it fixed.
>
> OK, basically it's like below.
> But, as mentioned, this made me wonder whether it's the right fix.
> The BTUSB_ATH3012 quirk was introduced exactly for this chip ID
> (0cf3:3004), and now this chip is moved to another quirk...
>
> If this is the right move, I can re-submit via git-send-email, too.
> Just let me know.
Marcel, could you take a look at this?
If it sucks, let's seek for a better solution.
thanks,
Takashi
>
>
> thanks,
>
> Takashi
>
> -- 8< --
> From: Takashi Iwai
> Subject: [PATCH] Bluebooth: btusb: Fix quirk for Atheros 1525/QCA6174
>
> The Atheros 1525/QCA6174 BT doesn't seem working properly on the
> recent kernels, as it tries to load a wrong firmware
> ar3k/AthrBT_0x0200.dfu and it fails.
>
> This seems to have been a problem for some time, and the known
> workaround is to apply BTUSB_QCA_ROM quirk instead of BTUSB_ATH3012.
>
> The device in question is:
>
> T: Bus=01 Lev=01 Prnt=01 Port=09 Cnt=03 Dev#= 4 Spd=12 MxCh= 0
> D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=0cf3 ProdID=3004 Rev= 0.01
> C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
> I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
> E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
>
> Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=1082504
> Cc:
> Signed-off-by: Takashi Iwai
> ---
> drivers/bluetooth/btusb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 60bf04b8f103..c5c566fdc629 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -231,7 +231,6 @@ static const struct usb_device_id blacklist_table[] = {
> { USB_DEVICE(0x0930, 0x0227), .driver_info = BTUSB_ATH3012 },
> { USB_DEVICE(0x0b05, 0x17d0), .driver_info = BTUSB_ATH3012 },
> { USB_DEVICE(0x0cf3, 0x0036), .driver_info = BTUSB_ATH3012 },
> - { USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 },
> { USB_DEVICE(0x0cf3, 0x3008), .driver_info = BTUSB_ATH3012 },
> { USB_DEVICE(0x0cf3, 0x311d), .driver_info = BTUSB_ATH3012 },
> { USB_DEVICE(0x0cf3, 0x311e), .driver_info = BTUSB_ATH3012 },
> @@ -264,6 +263,7 @@ static const struct usb_device_id blacklist_table[] = {
> { USB_DEVICE(0x0489, 0xe03c), .driver_info = BTUSB_ATH3012 },
>
> /* QCA ROME chipset */
> + { USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_QCA_ROME },
> { USB_DEVICE(0x0cf3, 0xe007), .driver_info = BTUSB_QCA_ROME },
> { USB_DEVICE(0x0cf3, 0xe009), .driver_info = BTUSB_QCA_ROME },
> { USB_DEVICE(0x0cf3, 0xe010), .driver_info = BTUSB_QCA_ROME },
> --
> 2.16.2
>
Re: WARNING in kmalloc_slab (4)
On Tue, Mar 13, 2018 at 10:51 AM, Steffen Klassert wrote: > On Tue, Mar 13, 2018 at 12:33:02AM -0700, syzbot wrote: >> Hello, >> >> syzbot hit the following crash on net-next commit >> f44b1886a5f876c87b5889df463ad7b97834ba37 (Fri Mar 9 18:10:06 2018 +) >> Merge branch 's390-qeth-next' >> >> Unfortunately, I don't have any reproducer for this crash yet. >> Raw console output is attached. >> compiler: gcc (GCC) 7.1.1 20170620 >> .config is attached. >> >> IMPORTANT: if you fix the bug, please add the following tag to the commit: >> Reported-by: syzbot+6a7e7ed886bde4346...@syzkaller.appspotmail.com >> It will help syzbot understand when the bug is fixed. See footer for >> details. >> If you forward the report, please keep this part and the footer. >> >> WARNING: CPU: 1 PID: 27333 at mm/slab_common.c:1012 kmalloc_slab+0x5d/0x70 >> mm/slab_common.c:1012 >> Kernel panic - not syncing: panic_on_warn set ... >> >> syz-executor0: vmalloc: allocation failure: 17045651456 bytes, >> mode:0x14080c0(GFP_KERNEL|__GFP_ZERO), nodemask=(null) >> CPU: 1 PID: 27333 Comm: syz-executor2 Not tainted 4.16.0-rc4+ #260 >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS >> Google 01/01/2011 >> Call Trace: >> __dump_stack lib/dump_stack.c:17 [inline] >> dump_stack+0x194/0x24d lib/dump_stack.c:53 >> panic+0x1e4/0x41c kernel/panic.c:183 >> syz-executor0 cpuset= >> __warn+0x1dc/0x200 kernel/panic.c:547 >> / >> mems_allowed=0 >> report_bug+0x211/0x2d0 lib/bug.c:184 >> fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178 >> fixup_bug arch/x86/kernel/traps.c:247 [inline] >> do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296 >> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315 >> invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:986 >> RIP: 0010:kmalloc_slab+0x5d/0x70 mm/slab_common.c:1012 >> RSP: 0018:8801ccfc72f0 EFLAGS: 00010246 >> RAX: RBX: 1018 RCX: 84ec4fc8 >> RDX: 0ba7 RSI: RDI: 1018 >> RBP: 8801ccfc72f0 R08: R09: 1100399f8e21 >> R10: 8801ccfc7040 R11: 0001 R12: 0018 >> R13: 8801ccfc7598 R14: 014080c0 R15: 8801aebaad80 >> __do_kmalloc mm/slab.c:3700 [inline] >> __kmalloc+0x25/0x760 mm/slab.c:3714 >> kmalloc include/linux/slab.h:517 [inline] >> kzalloc include/linux/slab.h:701 [inline] >> xfrm_alloc_replay_state_esn net/xfrm/xfrm_user.c:442 [inline] > > This is likely fixed with: > > commit d97ca5d714a5334aecadadf696875da40f1fbf3e > xfrm_user: uncoditionally validate esn replay attribute struct > > The patch is included in the ipsec pull request for the net > tree I've sent this morning. Let's tell syzbot: #syz fix: xfrm_user: uncoditionally validate esn replay attribute struct
Re: Regression from efi: call get_event_log before ExitBootServices
Hi,
On 12-03-18 22:02, Ard Biesheuvel wrote:
On 12 March 2018 at 19:55, Thiebaud Weksteen wrote:
On Mon, Mar 12, 2018 at 7:33 PM Jeremy Cline wrote:
On 03/12/2018 02:29 PM, Thiebaud Weksteen wrote:
On Mon, Mar 12, 2018 at 6:30 PM Ard Biesheuvel <
ard.biesheu...@linaro.org>
wrote:
On 12 March 2018 at 17:01, Jeremy Cline wrote:
On 03/12/2018 10:56 AM, Ard Biesheuvel wrote:
On 12 March 2018 at 14:30, Jeremy Cline wrote:
On 03/12/2018 07:08 AM, Ard Biesheuvel wrote:
On 10 March 2018 at 10:45, Thiebaud Weksteen
wrote:
On Fri, Mar 9, 2018 at 5:54 PM Jeremy Cline
wrote:
On Fri, Mar 09, 2018 at 10:43:50AM +, Thiebaud Weksteen
wrote:
Thanks a lot for trying out the patch!
Please don't modify your install at this stage, I think we are
hitting a
firmware bug and that would be awesome if we can fix how we are
handling it.
So, if we reach that stage in the function it could either be
that:
* The allocation did not succeed, somehow, but the firmware
still
returned
EFI_SUCCEED.
* The size requested is incorrect (I'm thinking something like a
1G of
log). This would be due to either a miscalculation of log_size
(possible)
or; the returned values of GetEventLog are not correct.
I'm sending a patch to add checks for these. Could you please
apply and
retest?
Again, thanks for helping debugging this.
No problem, thanks for the help :)
With the new patch:
Locating the TCG2Protocol
Calling GetEventLog on TCG2Protocol
Log returned
log_location is not empty
log_size != 0
log_size < 1M
Allocating memory for storing the logs
Returned from memory allocation
Copying log to new location
And then it hangs. I added a couple more print statements:
diff --git a/drivers/firmware/efi/libstub/tpm.c
b/drivers/firmware/efi/libstub/tpm.c
index ee3fac109078..1ab5638bc50e 100644
--- a/drivers/firmware/efi/libstub/tpm.c
+++ b/drivers/firmware/efi/libstub/tpm.c
@@ -148,8 +148,11 @@ void
efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg)
efi_printk(sys_table_arg, "Copying log to new
location\n");
memset(log_tbl, 0, sizeof(*log_tbl) + log_size);
+ efi_printk(sys_table_arg, "Successfully memset log_tbl to
0\n");
log_tbl->size = log_size;
+ efi_printk(sys_table_arg, "Set log_tbl->size\n");
log_tbl->version = EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2;
+ efi_printk(sys_table_arg, "Set log_tbl-version\n");
memcpy(log_tbl->log, (void *) first_entry_addr,
log_size);
efi_printk(sys_table_arg, "Installing the log into the
configuration table\n");
and it's hanging at "memset(log_tbl, 0, sizeof(*log_tbl) +
log_size);"
Thanks. Well, it looks like the memory that is supposedly
allocated
is not
usable. I'm thinking this is a firmware bug.
Ard, would you agree on this assumption? Thoughts on how to
proceed?
I am rather puzzled why the allocate_pool() should succeed and the
subsequent memset() should fail. This does not look like an issue
that
is intimately related to TPM2 support, rather an issue in the
firmware
that happens to get tickled after the change.
Would you mind trying replacing EFI_LOADER_DATA with
EFI_BOOT_SERVICES_DATA in the allocate_pool() call?
Replacing EFI_LOADER_DATA with EFI_BOOT_SERVICES_DATA still hangs at
the
memset() call.
Could you try the following please? (attached as well in case gmail
mangles it)
diff --git a/drivers/firmware/efi/libstub/tpm.c
b/drivers/firmware/efi/libstub/tpm.c
index 2298560cea72..30d960a344b7 100644
--- a/drivers/firmware/efi/libstub/tpm.c
+++ b/drivers/firmware/efi/libstub/tpm.c
@@ -70,6 +70,8 @@ void
efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg)
size_t log_size, last_entry_size;
efi_bool_t truncated;
void *tcg2_protocol;
+ unsigned long num_pages;
+ efi_physical_addr_t log_tbl_alloc;
status = efi_call_early(locate_protocol, &tcg2_guid, NULL,
&tcg2_protocol);
@@ -104,9 +106,12 @@ void
efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg)
}
/* Allocate space for the logs and copy them. */
- status = efi_call_early(allocate_pool, EFI_LOADER_DATA,
- sizeof(*log_tbl) + log_size,
- (void **) &log_tbl);
+ num_pages = DIV_ROUND_UP(sizeof(*log_tbl) + log_size,
EFI_PAGE_SIZE);
+ status = efi_call_early(allocate_pages,
+ EFI_ALLOCATE_ANY_PAGES,
+ EFI_LOADER_DATA,
+ num_pages,
+ &log_tbl_alloc);
if (status != EFI_SUCCESS) {
efi_printk(sys_table_arg,
@@ -114,6 +119,7 @@ void
efi_retrieve_tpm2_eventlog_1_2(efi_system_table_t *sys_table_arg)
return;
}
+ log_tbl = (struct linux_efi_tpm_eventlog *)(unsigned
long)log_tbl_alloc;
memset(log_tbl, 0, si
Re: Atheros 1525/QCA6174 BT issue
Hi Takashi, we've got a but report about the broken Atheros BT on the recent kernels: http://bugzilla.opensuse.org/show_bug.cgi?id=1082504 In short, btusb can't load the patch ar3k/AthrBT_0x0200.dfu, and this could be worked around by the patch to move 0cf3:3004 blacklist entry to use BTUSB_QCA_ROM instead of BTUSB_ATH3012. And this looks like a long-standing problem, at least for over two years. Many web pages suggest the same patch, but it's never merged to upstream. So this made me wonder what's going on. I see that the BTUSB_ATH3012 quirk was originally introduced just for this chip id (0cf3:3004). Is it a different variant from the original chip that causes a problem? >>> >>> not all patches from distro kernel are sent upstream. I have not heard of >>> this specific issues, but happy to accept patches to get it fixed. >> >> OK, basically it's like below. >> But, as mentioned, this made me wonder whether it's the right fix. >> The BTUSB_ATH3012 quirk was introduced exactly for this chip ID >> (0cf3:3004), and now this chip is moved to another quirk... >> >> If this is the right move, I can re-submit via git-send-email, too. >> Just let me know. > > Marcel, could you take a look at this? > If it sucks, let's seek for a better solution. wasn’t the confusion that this is fixed with a recent kernel? I am lost in this thread. I mean if people add Tested-by, then I can take this as well. Otherwise we might need someone from Qualcomm to shed some light into these. Regards Marcel
RE: [PATCH v2 3/3] ALSA: hda: Disabled unused audio controller for Dell platforms with Switchable Graphics
> -Original Message- > From: Kai Heng Feng [mailto:kai.heng.f...@canonical.com] > Sent: Tuesday, March 13, 2018 3:56 PM > To: Limonciello, Mario > Cc: pali.ro...@gmail.com; mj...@srcf.ucam.org; dvh...@infradead.org; > a...@infradead.org; ti...@suse.com; platform-driver-...@vger.kernel.org; Linux > Kernel Mailing List ; > alsa-de...@alsa-project.org > Subject: Re: [PATCH v2 3/3] ALSA: hda: Disabled unused audio controller for > Dell > platforms with Switchable Graphics > > > > > On Mar 12, 2018, at 9:30 AM, mario.limoncie...@dell.com wrote: > > > >>> I think the missing aspect is that this is only used in AIO and laptop > >>> form > >>> factors where the discrete graphics is in a non-removable form factor. > >> > >> Why we are not checking if kernel is running on AIO or laptop form > >> factor then? Or it is not possible? > > > > Kai Heng, can you please confirm if AIO sets chassis type properly? > > It should be 0Dh. > > > > If so, then I think as second check for chassis type should be possible for > > next version of this patch. > > The chassis type is correctly set as 0Dh on AIOs. > > > > >> Basically what I see there is that we need to detect if current HW > >> platform has switchable graphics and check how is configured AUDIO MUX. > >> > >> But instead of directly checking hw state of audio MUX, we are trying to > >> check something different which could get us information of state of the > >> audio mux. > >> > >> I suspect that we do not have a way how to check audio MUX directly, so > >> it needs to be done indirectly -- via some Dell SMBIOS call and some > >> other heuristic. This is something which should be specified either in > >> comment or in commit message (problem of type: we need X, but check for > >> Y). > >> > >> And if we are doing this check indirectly, we should do the most > >> specific test and not more general. > > > > Right. > > > >> I think that PCI vendor ID check of audio device is more general test > >> then checking if kernel is running on Dell laptop (check via DMI). And > >> if we can check also if running on AIO or laptop form, then it would be > >> more specific test. > >> > >>> Running with your hypothetical though, what would happen is if it's > >>> on a non-Dell machine the PCI check would pass and then the code > >>> would not be executed by dell-laptop (since dell-smbios didn't load). > >> > >> Right. > >> > >>> If it was on a Dell machine it would load but the BIOS would return > >>> either Switchable graphics turned off, or invalid token. > >>> > >>> Even though these aren't real for switchable graphics on Dell I don't > >>> see a problem with either of these situations if it ever came up. > >> > >> I see, this solution is working... > >> > >> ... but, I see there a very bad precedense. What would happen if another > >> laptop manufactor comes with similar solution for hybrid graphics. Does > >> it mean that hda audio driver would try to call for every one vendor its > >> vendor dependent API function (EFI, SMM, WMI, whatever) to check if > >> current HW has some switchable graphics and needs special checks? > >> > >> Those vendor dependent API functions (which Dell SMBIOS is) should be > >> really called on vendor hardware. > >> > >> Otherwise audio drivers would load bunch of the other vendor dependent > >> platform modules and all of those modules (except maximally one) just > >> return error. > > > > Sure the more specific the check the less symbol requests needed that > > will fail. > > > > Kai Heng, > > > > Can you please use Alex Hung's OEM strings patch in your series to match > > "Dell System" in OEM strings too? > > Sure, but this probably need to wait till it gets merged in Linus' tree. > It's already in -next isn't it? Isn't that sufficient to indicate your patch depends on that? Or it could come through platform-x86 tree too if needed. During the merge window one of the duplicates will get dropped. > > > > Between chassis type, OEM strings match, and AMD vendor/Dell subsystem > > vendor that should satisfy all of Pali's concerns I think. > > > > If anyone thinks that's too much, please speak up. > > > >>> Compiling a whitelist is a wasted effort because it will have to change > >>> Every year for every new platform that has AMD switchable graphics. > >> > >> I agree, But see that this patch already uses vendor ID whitelisting. > > > > I mean making a whitelist of all individual affected Dell platforms will > > grow > > each year. I want to avoid that approach.
Re: [pci PATCH v5 3/4] ena: Migrate over to unmanaged SR-IOV support
On Mon, 2018-03-12 at 10:23 -0700, Alexander Duyck wrote: > > - .sriov_configure = ena_sriov_configure, > +#ifdef CONFIG_PCI_IOV > + .sriov_configure = pci_sriov_configure_simple, > +#endif > }; I'd like to see that ifdef go away, as discussed. I agree that just #define pci_sriov_configure_simple NULL should suffice. As Christoph points out, it's not going to compile if people try to just invoke it directly. I'd also *really* like to see a way to enable this for PFs which don't have (and don't need) a driver. We seem to have lost that along the way. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH v2 4/6] ASoC: sun4i-i2s: Add multi-lane functionality
On 13 March 2018 at 09:00, Maxime Ripard wrote: > On Mon, Mar 12, 2018 at 04:57:51PM +0100, codekip...@gmail.com wrote: >> From: Marcus Cooper >> >> The i2s block supports multi-lane i2s output however this functionality >> is only possible in earlier SoCs where the pins are exposed and for >> the i2s block used for HDMI audio on the later SoCs. >> >> To enable this functionality, an optional property has been added to >> the bindings. >> >> Signed-off-by: Marcus Cooper >> --- >> .../devicetree/bindings/sound/sun4i-i2s.txt| 3 ++ >> sound/soc/sunxi/sun4i-i2s.c| 48 >> +- >> 2 files changed, 41 insertions(+), 10 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt >> b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt >> index 48addef65b8f..3f966ac61b9e 100644 >> --- a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt >> +++ b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt >> @@ -33,6 +33,9 @@ Optional properties: >> configured to extend the slot width to the >> value specified. Min 8, Max 32. >> >> +- allwinner,playback-channels: if this property is present then the number >> + of available channels is extended and the >> + outputs enabled. > > Isn't it something that is fixed for each generation of SoCs? Can't we > attach it to the compatible? I'm not sure as the documentation is pretty poor. It looks like it is supported by all of the variations that we've seen but only exposed as pins on A10 and A20. I'm also not sure who would ever use it with external devices. The reason why I've added it is that it is required by HDMI for supporting surround sound on the newer SoCs. CK > > Maxime > > -- > Maxime Ripard, Bootlin (formerly Free Electrons) > Embedded Linux and Kernel engineering > https://bootlin.com
Re: [pci PATCH v5 3/4] ena: Migrate over to unmanaged SR-IOV support
On Tue, Mar 13, 2018 at 08:12:52AM +, David Woodhouse wrote: > I'd also *really* like to see a way to enable this for PFs which don't > have (and don't need) a driver. We seem to have lost that along the > way. We've been forth and back on that. I agree that not having any driver just seems dangerous. If your PF really does nothing we should just have a trivial pf_stub driver that does nothing but wiring up pci_sriov_configure_simple. We can then add PCI IDs to it either statically, or using the dynamic ids mechanism.
Re: [PATCH] hwmon/sch5627: Use common error handling code in sch5627_probe()
Hi,
On 12-03-18 22:23, SF Markus Elfring wrote:
From: Markus Elfring
Date: Mon, 12 Mar 2018 22:15:59 +0100
Adjust jump targets so that a bit of exception handling can be better
reused at the end of this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
So now we have a goto set_error_code with the code at the set_error_code
doing something and then doing another goto. No, just no. goto-s going to
a label calling another goto is completely unreadable.
I really do not see any reason for the proposed changes, they may remove
a small amount of code duplication, but at a hugh cost wrt readability.
TL;DR: NACK
Regards,
Hans
---
drivers/hwmon/sch5627.c | 60 -
1 file changed, 29 insertions(+), 31 deletions(-)
diff --git a/drivers/hwmon/sch5627.c b/drivers/hwmon/sch5627.c
index 91544f2312e6..e7a2a974ab74 100644
--- a/drivers/hwmon/sch5627.c
+++ b/drivers/hwmon/sch5627.c
@@ -480,72 +480,64 @@ static int sch5627_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, data);
val = sch56xx_read_virtual_reg(data->addr, SCH5627_REG_HWMON_ID);
- if (val < 0) {
- err = val;
- goto error;
- }
+ if (val < 0)
+ goto set_error_code;
+
if (val != SCH5627_HWMON_ID) {
pr_err("invalid %s id: 0x%02X (expected 0x%02X)\n", "hwmon",
val, SCH5627_HWMON_ID);
- err = -ENODEV;
- goto error;
+ goto e_nodev;
}
val = sch56xx_read_virtual_reg(data->addr, SCH5627_REG_COMPANY_ID);
- if (val < 0) {
- err = val;
- goto error;
- }
+ if (val < 0)
+ goto set_error_code;
+
if (val != SCH5627_COMPANY_ID) {
pr_err("invalid %s id: 0x%02X (expected 0x%02X)\n", "company",
val, SCH5627_COMPANY_ID);
- err = -ENODEV;
- goto error;
+ goto e_nodev;
}
val = sch56xx_read_virtual_reg(data->addr, SCH5627_REG_PRIMARY_ID);
- if (val < 0) {
- err = val;
- goto error;
- }
+ if (val < 0)
+ goto set_error_code;
+
if (val != SCH5627_PRIMARY_ID) {
pr_err("invalid %s id: 0x%02X (expected 0x%02X)\n", "primary",
val, SCH5627_PRIMARY_ID);
- err = -ENODEV;
- goto error;
+ goto e_nodev;
}
build_code = sch56xx_read_virtual_reg(data->addr,
SCH5627_REG_BUILD_CODE);
if (build_code < 0) {
err = build_code;
- goto error;
+ goto remove_device;
}
build_id = sch56xx_read_virtual_reg16(data->addr,
SCH5627_REG_BUILD_ID);
if (build_id < 0) {
err = build_id;
- goto error;
+ goto remove_device;
}
hwmon_rev = sch56xx_read_virtual_reg(data->addr,
SCH5627_REG_HWMON_REV);
if (hwmon_rev < 0) {
err = hwmon_rev;
- goto error;
+ goto remove_device;
}
val = sch56xx_read_virtual_reg(data->addr, SCH5627_REG_CTRL);
- if (val < 0) {
- err = val;
- goto error;
- }
+ if (val < 0)
+ goto set_error_code;
+
data->control = val;
if (!(data->control & 0x01)) {
pr_err("hardware monitoring not enabled\n");
- err = -ENODEV;
- goto error;
+ goto e_nodev;
}
/* Trigger a Vbat voltage measurement, so that we get a valid reading
the first time we read Vbat */
@@ -559,7 +551,7 @@ static int sch5627_probe(struct platform_device *pdev)
*/
err = sch5627_read_limits(data);
if (err)
- goto error;
+ goto remove_device;
pr_info("found %s chip at %#hx\n", DEVNAME, data->addr);
pr_info("firmware build: code 0x%02X, id 0x%04X, hwmon: rev 0x%02X\n",
@@ -568,13 +560,13 @@ static int sch5627_probe(struct platform_device *pdev)
/* Register sysfs interface files */
err = sysfs_create_group(&pdev->dev.kobj, &sch5627_group);
if (err)
- goto error;
+ goto remove_device;
data->hwmon_dev = hwmon_device_register(&pdev->dev);
if (IS_ERR(data->hwmon_dev)) {
err = PTR_ERR(data->hwmon_dev);
data->hwmon_dev = NULL;
- goto error;
+ goto remove_device;
}
/* Note failing to register the watchdog is not a fatal error */
@@ -584,7 +576,13 @@ static int sch5627_probe(struct platform_device *pdev)
return 0;
-error:
+set_error_
Re: [PATCH v2 3/6] ASoC: sun4i-i2s: Correct divider calculations
On Mon, Mar 12, 2018 at 04:57:50PM +0100, codekip...@gmail.com wrote:
> From: Marcus Cooper
>
> The clock division circuitry is different on the H3 and later SoCs.
> The division of bclk is now based on pll2.
You're doing too many things here.
> Signed-off-by: Marcus Cooper
> ---
> sound/soc/sunxi/sun4i-i2s.c | 76
> +++--
> 1 file changed, 52 insertions(+), 24 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> index 396b11346361..2bd0befa02a8 100644
> --- a/sound/soc/sunxi/sun4i-i2s.c
> +++ b/sound/soc/sunxi/sun4i-i2s.c
> @@ -129,10 +129,10 @@
> * @has_chsel_offset: SoC uses offset for selecting dai operational mode.
> * @reg_offset_txdata: offset of the tx fifo.
> * @sun4i_i2s_regmap: regmap config to use.
> - * @mclk_offset: Value by which mclkdiv needs to be adjusted.
> - * @bclk_offset: Value by which bclkdiv needs to be adjusted.
> * @fmt_offset: Value by which wss and sr needs to be adjusted.
> * @field_clkdiv_mclk_en: regmap field to enable mclk output.
> + * @field_clkdiv_mclk: regmap field for mclkdiv.
> + * @field_clkdiv_bclk: regmap field for bclkdiv.
> * @field_fmt_wss: regmap field to set word select size.
> * @field_fmt_sr: regmap field to set sample resolution.
> * @field_fmt_bclk: regmap field to set clk polarity.
> @@ -153,8 +153,6 @@ struct sun4i_i2s_quirks {
> boolhas_chsel_offset;
> unsigned intreg_offset_txdata; /* TX FIFO */
> const struct regmap_config *sun4i_i2s_regmap;
> - unsigned intmclk_offset;
> - unsigned intbclk_offset;
> unsigned intfmt_offset;
>
> /* Register fields for i2s */
> @@ -212,7 +210,25 @@ static const struct sun4i_i2s_clk_div
> sun4i_i2s_bclk_div[] = {
> { .div = 8, .val = 3 },
> { .div = 12, .val = 4 },
> { .div = 16, .val = 5 },
> - /* TODO - extend divide ratio supported by newer SoCs */
> +};
> +
> +static const struct sun4i_i2s_clk_div sun8i_i2s_clk_div[] = {
> + { .div = 0, .val = 0 },
> + { .div = 1, .val = 1 },
> + { .div = 2, .val = 2 },
> + { .div = 4, .val = 3 },
> + { .div = 6, .val = 4 },
> + { .div = 8, .val = 5 },
> + { .div = 12, .val = 6 },
> + { .div = 16, .val = 7 },
> + { .div = 24, .val = 8 },
> + { .div = 32, .val = 9 },
> + { .div = 48, .val = 10 },
> + { .div = 64, .val = 11 },
> + { .div = 96, .val = 12 },
> + { .div = 128, .val = 13 },
> + { .div = 176, .val = 14 },
> + { .div = 192, .val = 15 },
> };
>
> static const struct sun4i_i2s_clk_div sun4i_i2s_mclk_div[] = {
> @@ -224,21 +240,21 @@ static const struct sun4i_i2s_clk_div
> sun4i_i2s_mclk_div[] = {
> { .div = 12, .val = 5 },
> { .div = 16, .val = 6 },
> { .div = 24, .val = 7 },
> - /* TODO - extend divide ratio supported by newer SoCs */
> };
>
> static int sun4i_i2s_get_bclk_div(struct sun4i_i2s *i2s,
> unsigned int oversample_rate,
> - unsigned int word_size)
> + unsigned int word_size,
> + const struct sun4i_i2s_clk_div *bdiv,
> + unsigned int size)
> {
> int div = oversample_rate / word_size / 2;
> int i;
>
> - for (i = 0; i < ARRAY_SIZE(sun4i_i2s_bclk_div); i++) {
> - const struct sun4i_i2s_clk_div *bdiv = &sun4i_i2s_bclk_div[i];
> -
> + for (i = 0; i < size; i++) {
> if (bdiv->div == div)
> return bdiv->val;
> + bdiv++;
> }
>
> return -EINVAL;
> @@ -247,16 +263,17 @@ static int sun4i_i2s_get_bclk_div(struct sun4i_i2s *i2s,
> static int sun4i_i2s_get_mclk_div(struct sun4i_i2s *i2s,
> unsigned int oversample_rate,
> unsigned int module_rate,
> - unsigned int sampling_rate)
> + unsigned int sampling_rate,
> + const struct sun4i_i2s_clk_div *mdiv,
> + unsigned int size)
> {
> int div = module_rate / sampling_rate / oversample_rate;
> int i;
>
> - for (i = 0; i < ARRAY_SIZE(sun4i_i2s_mclk_div); i++) {
> - const struct sun4i_i2s_clk_div *mdiv = &sun4i_i2s_mclk_div[i];
> -
> + for (i = 0; i < size; i++) {
> if (mdiv->div == div)
> return mdiv->val;
> + mdiv++;
> }
>
> return -EINVAL;
> @@ -321,24 +338,37 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai
> *dai,
> return -EINVAL;
> }
>
> - bclk_div = sun4i_i2s_get_bclk_div(i2s, oversample_rate,
> - word_size);
> + if (i2s->variant->has_fmt_set_lrck_period)
> +
Re: [PATCH v2 4/6] ASoC: sun4i-i2s: Add multi-lane functionality
On Tue, Mar 13, 2018 at 09:15:49AM +0100, Code Kipper wrote: > On 13 March 2018 at 09:00, Maxime Ripard wrote: > > On Mon, Mar 12, 2018 at 04:57:51PM +0100, codekip...@gmail.com wrote: > >> From: Marcus Cooper > >> > >> The i2s block supports multi-lane i2s output however this functionality > >> is only possible in earlier SoCs where the pins are exposed and for > >> the i2s block used for HDMI audio on the later SoCs. > >> > >> To enable this functionality, an optional property has been added to > >> the bindings. > >> > >> Signed-off-by: Marcus Cooper > >> --- > >> .../devicetree/bindings/sound/sun4i-i2s.txt| 3 ++ > >> sound/soc/sunxi/sun4i-i2s.c| 48 > >> +- > >> 2 files changed, 41 insertions(+), 10 deletions(-) > >> > >> diff --git a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt > >> b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt > >> index 48addef65b8f..3f966ac61b9e 100644 > >> --- a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt > >> +++ b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt > >> @@ -33,6 +33,9 @@ Optional properties: > >> configured to extend the slot width to the > >> value specified. Min 8, Max 32. > >> > >> +- allwinner,playback-channels: if this property is present then the > >> number > >> + of available channels is extended and the > >> + outputs enabled. > > > > Isn't it something that is fixed for each generation of SoCs? Can't we > > attach it to the compatible? > > I'm not sure as the documentation is pretty poor. It looks like it is > supported by all of the variations that we've seen but only exposed as > pins on A10 and A20. I'm also not sure who would ever use it with > external devices. Well, you were saying that it was the case on the older SoCs in your commit log, so this needs to be figured out. > The reason why I've added it is that it is required by HDMI for > supporting surround sound on the newer SoCs. Why isn't that mentionned in your commit log? Can you post the whole set of changes needed for HDMI audio? this would make things much easier to see where you're going. Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [PATCH v2 3/3] ALSA: hda: Disabled unused audio controller for Dell platforms with Switchable Graphics
On Mar 10, 2018, at 2:50 PM, Lukas Wunner wrote: On Fri, Mar 09, 2018 at 05:30:15PM +0800, Kai Heng Feng wrote: On Thursday 08 March 2018 17:10:23 Kai-Heng Feng wrote: Some Dell platforms (Preicsion 7510/7710/7520/7720) have a BIOS option "Switchable Graphics" (SG). When SG is enabled, we have: 00:02.0 VGA compatible controller: Intel Corporation Device 591b (rev 04) 00:1f.3 Audio device: Intel Corporation CM238 HD Audio Controller (rev 31) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Polaris10] 01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 580] The Intel Audio outputs all the sound, including HDMI audio. The audio controller comes with AMD graphics doesn't get used. When SG is disabled, we have: 00:1f.3 Audio device: Intel Corporation CM238 HD Audio Controller (rev 31) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Polaris10] 01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 580] Now it's a typical discrete-only system. HDMI audio comes from AMD audio controller, others from Intel audio controller. When SG is enabled, the unused AMD audio controller still exposes its sysfs, so userspace still opens the control file and stream. If userspace tries to output sound through the stream, it hangs when runtime suspend kicks in: [ 12.796265] snd_hda_intel :01:00.1: Disabling via vga_switcheroo [ 12.796367] snd_hda_intel :01:00.1: Cannot lock devices! Since the discrete audio controller isn't useful when SG enabled, we should just disable the device. The platform does have a NVIDIA variant, but the discrete NVIDIA have a audio controller, hence it doesn't have the issue. Sorry, I don't quite understand: The AMD variant *also* has an audio controller, so what's the difference? Or did you mean the Nvidia variant *doesn't* have an audio controller? It does, but the audio controller only shows under SG disabled. Pretty much all modern Nvidia GPUs do have an integrated HDA controller, however it's possible to hide it by clearing a bit at offset 0x488 in the GPU's config space. Some BIOSes hide the HDA if no external display is attached. This is how the Nvidia variant works: When SG is enabled: One audio controller, the integrated one. All sounds comes from the integrated one, including DP/HDMI. When SG is disabled: Two audio controller. The DP/HDMI sounds come from the Nvidia audio controller. Others are from the integrated audio controller. I could imagine that the BIOS of the Dell machines in question hides the HDA if Switchable Graphics is enabled. If that is the case, be aware that there's an ongoing discussion to always expose the HDA controller because the behavior of some BIOSes to only expose the HDA when a display is attached causes massive problems with Linux' HDA driver: https://bugs.freedesktop.org/show_bug.cgi?id=75985 The system in the bug doesn't have "Switchable Graphics". Right now all sounds output are from integrated audio controller on SG enabled machines. If we decide to always expose the HDA controller on Nvidia cards, you may need to also match for the Nvidia vendor ID here. Thanks for the info, I'll also put Nvidia vendor ID on next patch version. Thanks, Lukas
Re: [PATCH V1] Input: pm8941-pwrkey: add resin key capabilities
Hi Dmitry,
On 3/10/2018 11:57 PM, Dmitry Torokhov wrote:
On Wed, Mar 07, 2018 at 12:21:47PM -0800, Dmitry Torokhov wrote:
Hi Tirupathi,
On Wed, Mar 07, 2018 at 01:39:33PM +0530, Tirupathi Reddy wrote:
Add resin key support to handle different types of key events
defined in different platforms.
Also, when you say "resin" key, I do not suppose it refers to teh
material of the key, but rather have something to so with "reset in"
signal or similar when is not actually used for resetting the device?
The resin is a "reset in" line to the "Power Management IC".
Usually in a regular usecase this line is used for "volume down key"
functionality and in other cases to reset the device on a long-press.
Signed-off-by: Tirupathi Reddy
---
.../bindings/input/qcom,pm8941-pwrkey.txt | 20 ++-
drivers/input/misc/pm8941-pwrkey.c | 63 +-
2 files changed, 81 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
index 07bf55f..1c437e9 100644
--- a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
+++ b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
@@ -20,6 +20,14 @@ PROPERTIES
defined by the binding document describing the node's
interrupt parent.
+- interrupt-names:
+ Usage: required
+ Value type:
+ Definition: Interrupt names. This list must match up 1-to-1 with the
+ interrupts specified in the 'interrupts' property. "kpdpwr"
+ must be specified. "resin" may be specified for some
+ platforms.
+
- debounce:
Usage: optional
Value type:
@@ -32,12 +40,22 @@ PROPERTIES
Definition: presence of this property indicates that the KPDPWR_N pin
should be configured for pull up.
+- linux,code:
+ Usage: required for "resin" key
+ Value type:
+ Definition: The input key-code associated with the resin key.
+ Use the linux event codes defined in
+ include/dt-bindings/input/linux-event-codes.h
+
EXAMPLE
pwrkey@800 {
compatible = "qcom,pm8941-pwrkey";
reg = <0x800>;
- interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
+ interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>,
+<0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>;
+ interrupt-names = "kpdpwr", "resin";
debounce = <15625>;
bias-pull-up;
+ linux,code = ;
};
diff --git a/drivers/input/misc/pm8941-pwrkey.c
b/drivers/input/misc/pm8941-pwrkey.c
index 18ad956..3f801cf 100644
--- a/drivers/input/misc/pm8941-pwrkey.c
+++ b/drivers/input/misc/pm8941-pwrkey.c
@@ -28,6 +28,7 @@
#define PON_RT_STS 0x10
#define PON_KPDPWR_N_SET BIT(0)
+#define PON_RESIN_N_SET BIT(1)
#define PON_PS_HOLD_RST_CTL 0x5a
#define PON_PS_HOLD_RST_CTL2 0x5b
@@ -46,6 +47,8 @@
struct pm8941_pwrkey {
struct device *dev;
int irq;
+ int resin_irq;
+ u32 resin_key_code;
u32 baseaddr;
struct regmap *regmap;
struct input_dev *input;
@@ -130,6 +133,24 @@ static irqreturn_t pm8941_pwrkey_irq(int irq, void *_data)
return IRQ_HANDLED;
}
+static irqreturn_t pm8941_resinkey_irq(int irq, void *_data)
+{
+ struct pm8941_pwrkey *pwrkey = _data;
+ unsigned int sts;
+ int error;
+
+ error = regmap_read(pwrkey->regmap,
+ pwrkey->baseaddr + PON_RT_STS, &sts);
+ if (error)
+ return IRQ_HANDLED;
It looks like you are reading the same register as the power on key.
Won't you lose events if both are pressed at the same time?
I think you need a unified interrupt handler...
We are reading the real-time status register where both these
bits would be set and the PMIC arb would dispatch 2 interrupts.
+
+ input_report_key(pwrkey->input, pwrkey->resin_key_code,
+!!(sts & PON_RESIN_N_SET));
+ input_sync(pwrkey->input);
+
+ return IRQ_HANDLED;
+}
+
static int __maybe_unused pm8941_pwrkey_suspend(struct device *dev)
{
struct pm8941_pwrkey *pwrkey = dev_get_drvdata(dev);
@@ -153,6 +174,35 @@ static int __maybe_unused pm8941_pwrkey_resume(struct
device *dev)
static SIMPLE_DEV_PM_OPS(pm8941_pwr_key_pm_ops,
pm8941_pwrkey_suspend, pm8941_pwrkey_resume);
+static int pm8941_resin_key_init(struct pm8941_pwrkey *pwrkey)
+{
+ int error;
+
+ /*
+* Get the standard-key parameters. This might not be
+* specified if there is no key mapping on the reset line.
+*/
+ error = of_property_read_u32(pwrkey->dev->of_node, "linux,code",
+ &pwrkey->resin_key_code);
+ if (erro
Re: hwmon/sch5627: Use common error handling code in sch5627_probe()
>> Adjust jump targets so that a bit of exception handling can be better >> reused at the end of this function. … > goto-s going to a label calling another goto is completely unreadable. I got an other software development view. > I really do not see any reason for the proposed changes, I suggest to look once more. > they may remove a small amount of code duplication, This was my software design goal in this case. > but at a hugh cost wrt readability. I proposed a different trade-off here. Regards, Markus
Re: [PATCH 3/5] arm64: dts: allwinner: a64: add simplefb for A64 SoC
On Mon, Mar 12, 2018 at 04:10:48PM +, Harald Geyer wrote:
> The A64 SoC features two display pipelines, one has a LCD output, the
> other has a HDMI output.
>
> Add support for simplefb for the LCD output. Tested on Teres I.
>
> This patch was inspired by work of Icenowy Zheng.
>
> Signed-off-by: Harald Geyer
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index ca1b365bc722..05d5e8def68a 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -52,6 +52,26 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> + chosen {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> +/*
> + * The pipeline mixer0-lcd0 depends on clock CLK_MIXER0 from DE2 CCU.
> + * However there is no support for this clock on A64 yet, so we depend
> + * on the upstream clocks here to keep them (and thus CLK_MIXER0) up.
> + */
There's definitely support for the CLK_MIXER0 clock in the DE2 CCU
driver, so I guess this would need to be amended / fixed
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
Re: [PATCH 4/5] arm64: dts: allwinner: a64: Add pwm device
On Mon, Mar 12, 2018 at 04:10:49PM +, Harald Geyer wrote:
> This device is compatible with A13, so no new driver is needed.
>
> Signed-off-by: Harald Geyer
> ---
> I saw that Andre Przywara has been working on A64 pwm too and has
> submitted some patches a few days ago. I think his patches are functionally
> equivalent to this one here, but clean up things a bit and thus are
> preferable. See:
>
> https://groups.google.com/forum/#!topic/linux-sunxi/hQFeteP591k
>
> I'm including my patch here mostly to have a consistent series for others
> to test. OTOH you might merge the device tree changes here and pick up
> the cleanup patches from him. Either way should work fine.
>
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 05d5e8def68a..95d52f6aa07f 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -364,6 +364,11 @@
> bias-pull-up;
> };
>
> + pwm_pin: pwm_pin {
> + pins = "PD22";
> + function = "pwm";
> + };
> +
> rmii_pins: rmii_pins {
> pins = "PD10", "PD11", "PD13", "PD14", "PD17",
> "PD18", "PD19", "PD20", "PD22", "PD23";
> @@ -629,6 +634,14 @@
> #interrupt-cells = <3>;
> };
>
> + pwm: pwm@1c21400 {
> + compatible = "allwinner,sun5i-a13-pwm";
Just like for the watchdog, you should have an A64 compatible there.
> + reg = <0x01c21400 0x8>;
And you should use the full memory range here.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
Re: [PATCH] rtc: mcp795: remove VLA usage
Hi, 2018-03-13 0:31 GMT+01:00 Alexandre Belloni : > Hi, > > On 13/03/2018 at 00:13:38 +0100, Stefano Manni wrote: >> In preparation to enabling -Wvla, remove VLAs and replace them with >> fixed-length arrays instead. >> >> rtc-mcp795.c uses a variable-length array declaration to contain >> the command to write the rtcc; this can be replaced by a fixed- >> size array of length 2 (instruction, address) + 32 (data out), >> assuming a maximum data length of 32 bytes before wrap up. >> >> This was prompted by https://lkml.org/lkml/2018/3/7/621 >> >> Signed-off-by: Stefano Manni >> --- >> drivers/rtc/rtc-mcp795.c | 8 +++- >> 1 file changed, 7 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/rtc/rtc-mcp795.c b/drivers/rtc/rtc-mcp795.c >> index 77f21331ae21..a5f504e2364c 100644 >> --- a/drivers/rtc/rtc-mcp795.c >> +++ b/drivers/rtc/rtc-mcp795.c >> @@ -61,6 +61,9 @@ >> >> #define SEC_PER_DAY (24 * 60 * 60) >> >> +/* Maximum length for data out in write operation to RTCC */ >> +#define MCP795_MAX_DATAOUT_LEN 32 >> + > > This is wrong, see https://marc.info/?l=linux-kernel&m=152046370320811&w=2 > > Also, > https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git/commit/?h=rtc-next&id=74ce1a932504da166cfbccf5567aa3751b6aa599 > You sure that the right value to use is 255 + 2? mcp795_rtcc_write() just writes into the RTCC that contains only 32 registers (table 4-1 of datasheet). I assumed 32 as the maximum length of data to write before wrapping up (start from reg 0x0). Probably 32 is just a wrong assumption but why did you choose 255? Another thing: don't we need also to check count against the array length? if (count > MCP795_MAX_DATAOUT_LEN) return -EINVAL;
Re: Atheros 1525/QCA6174 BT issue
On Tue, 13 Mar 2018 09:10:41 +0100, Marcel Holtmann wrote: > > Hi Takashi, > > we've got a but report about the broken Atheros BT on the recent > kernels: > http://bugzilla.opensuse.org/show_bug.cgi?id=1082504 > > In short, btusb can't load the patch ar3k/AthrBT_0x0200.dfu, and > this could be worked around by the patch to move 0cf3:3004 blacklist > entry to use BTUSB_QCA_ROM instead of BTUSB_ATH3012. > > And this looks like a long-standing problem, at least for over two > years. Many web pages suggest the same patch, but it's never merged > to upstream. > > So this made me wonder what's going on. I see that the BTUSB_ATH3012 > quirk was originally introduced just for this chip id (0cf3:3004). > Is it a different variant from the original chip that causes a > problem? > >>> > >>> not all patches from distro kernel are sent upstream. I have not heard of > >>> this specific issues, but happy to accept patches to get it fixed. > >> > >> OK, basically it's like below. > >> But, as mentioned, this made me wonder whether it's the right fix. > >> The BTUSB_ATH3012 quirk was introduced exactly for this chip ID > >> (0cf3:3004), and now this chip is moved to another quirk... > >> > >> If this is the right move, I can re-submit via git-send-email, too. > >> Just let me know. > > > > Marcel, could you take a look at this? > > If it sucks, let's seek for a better solution. > > wasn’t the confusion that this is fixed with a recent kernel? I am lost in > this thread. I mean if people add Tested-by, then I can take this as well. > Otherwise we might need someone from Qualcomm to shed some light into these. Well, *this* thread is likely different from the recent other threads. Isn't 4.15.7 recent enough? At least, it already contains the backport of relevant fixes: Revert "Bluetooth: btusb: fix QCA Rome suspend/resume" Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version (And it's not Yoga but MSI GS40 laptop, so DMI doesn't matter.) According to Ivan, the reporter of the bug (now Cc'ed), 4.15.7 didn't work without the patch, so the problem is still there, as it seems. In anyway, I'm going to build a kernel with my patch on top of 4.15.9 for testing again. Maybe also a patched 4.16-rc5 kernel, too. If it's confirmed, will report back with tested-by tag. thanks, Takashi
Re: [PATCH ghak21 V2 3/4] audit: add refused symlink to audit_names
On Mon, 12 Mar 2018 11:52:56 -0400
Richard Guy Briggs wrote:
> On 2018-03-12 11:53, Paul Moore wrote:
> > On Mon, Mar 12, 2018 at 11:26 AM, Richard Guy Briggs
> > wrote:
> > > On 2018-03-12 11:12, Paul Moore wrote:
> > >> On Mon, Mar 12, 2018 at 2:31 AM, Richard Guy Briggs
> > >> wrote:
> > >> > Audit link denied events for symlinks had duplicate PATH
> > >> > records rather than just updating the existing PATH record.
> > >> > Update the symlink's PATH record with the current dentry and
> > >> > inode information.
> > >> >
> > >> > See: https://github.com/linux-audit/audit-kernel/issues/21
> > >> > Signed-off-by: Richard Guy Briggs
> > >> > ---
> > >> > fs/namei.c | 1 +
> > >> > 1 file changed, 1 insertion(+)
> > >>
> > >> Why didn't you include this in patch 4/4 like I asked during the
> > >> previous review?
> > >
> > > Please see the last comment of:
> > > https://www.redhat.com/archives/linux-audit/2018-March/msg00070.html
> >
> > Yes, I just saw that ... I hadn't seen your replies on the v1
> > patches until I had finished reviewing v2. I just replied to that
> > mail in the v1 thread, but basically you need to figure out what is
> > necessary here and let us know. If I have to figure it out it
> > likely isn't going to get done with enough soak time prior to the
> > upcoming merge window.
>
> Steve? I was hoping you could chime in here.
If the CWD record will always be the same as the PARENT record, then we
do not need the parent record. Duplicate information is bad. Like all
the duplicate SYSCALL information.
-Steve
> I'd just include it for completeness unless Steve thinks it will stand
> on its own and doesn't want the overhead.
>
> > >> > diff --git a/fs/namei.c b/fs/namei.c
> > >> > index 50d2533..00f5041 100644
> > >> > --- a/fs/namei.c
> > >> > +++ b/fs/namei.c
> > >> > @@ -945,6 +945,7 @@ static inline int may_follow_link(struct
> > >> > nameidata *nd) if (nd->flags & LOOKUP_RCU)
> > >> > return -ECHILD;
> > >> >
> > >> > + audit_inode(nd->name, nd->stack[0].link.dentry, 0);
> > >> > audit_log_link_denied("follow_link",
> > >> > &nd->stack[0].link); return -EACCES;
> > >> > }
> > >>
> > >> paul moore
> > >
> > > - RGB
> >
> > paul moore
>
> - RGB
>
> --
> Richard Guy Briggs
> Sr. S/W Engineer, Kernel Security, Base Operating Systems
> Remote, Ottawa, Red Hat Canada
> IRC: rgb, SunRaycer
> Voice: +1.647.777.2635, Internal: (81) 32635
>
> --
> Linux-audit mailing list
> linux-au...@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
[PATCH V2] Input: pm8941-pwrkey: add resin key capabilities
Add resin key support to handle different types of key events
defined in different platforms.
Signed-off-by: Tirupathi Reddy
---
.../bindings/input/qcom,pm8941-pwrkey.txt | 20 ++-
drivers/input/misc/pm8941-pwrkey.c | 65 +-
2 files changed, 83 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
index 07bf55f..f499cf8 100644
--- a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
+++ b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
@@ -20,6 +20,14 @@ PROPERTIES
defined by the binding document describing the node's
interrupt parent.
+- interrupt-names:
+ Usage: required
+ Value type:
+ Definition: Interrupt names. This list must match up 1-to-1 with the
+ interrupts specified in the 'interrupts' property. "kpdpwr"
+ must be specified and should be the first entry of the list.
+ "resin" may be specified for some platforms.
+
- debounce:
Usage: optional
Value type:
@@ -32,12 +40,22 @@ PROPERTIES
Definition: presence of this property indicates that the KPDPWR_N pin
should be configured for pull up.
+- linux,code:
+ Usage: required for "resin" key
+ Value type:
+ Definition: The input key-code associated with the resin key.
+ Use the linux event codes defined in
+ include/dt-bindings/input/linux-event-codes.h
+
EXAMPLE
pwrkey@800 {
compatible = "qcom,pm8941-pwrkey";
reg = <0x800>;
- interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
+ interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>,
+<0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>;
+ interrupt-names = "kpdpwr", "resin";
debounce = <15625>;
bias-pull-up;
+ linux,code = ;
};
diff --git a/drivers/input/misc/pm8941-pwrkey.c
b/drivers/input/misc/pm8941-pwrkey.c
index 18ad956..2fffc7c 100644
--- a/drivers/input/misc/pm8941-pwrkey.c
+++ b/drivers/input/misc/pm8941-pwrkey.c
@@ -28,6 +28,7 @@
#define PON_RT_STS 0x10
#define PON_KPDPWR_N_SET BIT(0)
+#define PON_RESIN_N_SET BIT(1)
#define PON_PS_HOLD_RST_CTL0x5a
#define PON_PS_HOLD_RST_CTL2 0x5b
@@ -46,6 +47,7 @@
struct pm8941_pwrkey {
struct device *dev;
int irq;
+ u32 resin_key_code;
u32 baseaddr;
struct regmap *regmap;
struct input_dev *input;
@@ -130,6 +132,24 @@ static irqreturn_t pm8941_pwrkey_irq(int irq, void *_data)
return IRQ_HANDLED;
}
+static irqreturn_t pm8941_resinkey_irq(int irq, void *_data)
+{
+ struct pm8941_pwrkey *pwrkey = _data;
+ unsigned int sts;
+ int error;
+
+ error = regmap_read(pwrkey->regmap,
+ pwrkey->baseaddr + PON_RT_STS, &sts);
+ if (error)
+ return IRQ_HANDLED;
+
+ input_report_key(pwrkey->input, pwrkey->resin_key_code,
+!!(sts & PON_RESIN_N_SET));
+ input_sync(pwrkey->input);
+
+ return IRQ_HANDLED;
+}
+
static int __maybe_unused pm8941_pwrkey_suspend(struct device *dev)
{
struct pm8941_pwrkey *pwrkey = dev_get_drvdata(dev);
@@ -153,12 +173,40 @@ static int __maybe_unused pm8941_pwrkey_resume(struct
device *dev)
static SIMPLE_DEV_PM_OPS(pm8941_pwr_key_pm_ops,
pm8941_pwrkey_suspend, pm8941_pwrkey_resume);
+static int pm8941_resin_key_init(struct pm8941_pwrkey *pwrkey, int irq)
+{
+ int error;
+
+ /*
+* Get the standard-key parameters. This might not be
+* specified if there is no key mapping on the reset line.
+*/
+ error = of_property_read_u32(pwrkey->dev->of_node, "linux,code",
+ &pwrkey->resin_key_code);
+ if (error) {
+ dev_err(pwrkey->dev, "failed to read key-code for resin key\n");
+ return error;
+ }
+
+ /* Register key configuration */
+ input_set_capability(pwrkey->input, EV_KEY, pwrkey->resin_key_code);
+
+ error = devm_request_threaded_irq(pwrkey->dev, irq, NULL,
+ pm8941_resinkey_irq, IRQF_ONESHOT,
+ "pm8941_resinkey", pwrkey);
+ if (error)
+ dev_err(pwrkey->dev, "failed requesting resin key IRQ: %d\n",
+ error);
+
+ return error;
+}
+
static int pm8941_pwrkey_probe(struct platform_device *pdev)
{
struct pm8941_pwrkey *pwrkey;
bool pull_up;
u32 req_delay;
- int error;
+ int error, resin_irq;
if (of_property_read_u32(pdev->dev.of_node, "debounce", &req
Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible
On Tue, Mar 13, 2018 at 09:38:41AM +0200, Artem Bityutskiy wrote: > On Tue, 2018-03-13 at 11:11 +0800, Dou Liyang wrote: > > I also > > met the situation that BIOS told to ACPI that it could support > > physical > > CPUs hotplug, But actually, there was no hardware slots in the > > machine. > > the ACPI tables like user inputs which should be validated when we > > use. > > This is exactly what happens on Skylake Xeon systems. When I check > dmesg or this file: > > /sys/devices/system/cpu/possible > > on 2S (two socket) and 4S (four socket) systems, I see the same number > 432. > > This number comes from ACPI MADT. I will speculate (did not see myself) > that 8S systems will report the same number as well, because of the > Skylake-SP (Scalable Platform) architecture. > > Number 432 is good for 8S systems, but it is way too large for 2S and > 4S systems - 4x or 2x larger than the theoretical maximum. > > I do not know why BIOSes have to report unrealistically high numbers, I > am just sharing my observation. > > So yes, Linux kernel's possible CPU count knowledge may be too large. > If we use that number to evenly spread IRQ vectors among the CPUs, we > end up with wasted vectors, and even bugs, as I observe on a 2S > Skylake. Then looks this issue need to fix by making possible CPU count accurate because there are other resources allocated according to num_possible_cpus(), such as percpu variables. Thanks, Ming
Re: [PATCH V4] thermal: Add cooling device's statistics in sysfs
On 13-03-18, 15:02, Zhang Rui wrote: > Hi, Viresh, > > I will queue it for 4.17, with just one minor fix below. > > On 二, 2018-01-16 at 15:22 +0530, Viresh Kumar wrote: > > + cdev->stats = stats; > > + stats->last_time = ktime_get(); > > + stats->max_states = states; > > + cdev->stats = stats; > > + > > cdev->stats is set twice here, I will remove the first one. Thanks for catching that :) -- viresh
Re: Atheros 1525/QCA6174 BT issue
Hi Takashi, >> we've got a but report about the broken Atheros BT on the recent >> kernels: >> http://bugzilla.opensuse.org/show_bug.cgi?id=1082504 >> >> In short, btusb can't load the patch ar3k/AthrBT_0x0200.dfu, and >> this could be worked around by the patch to move 0cf3:3004 blacklist >> entry to use BTUSB_QCA_ROM instead of BTUSB_ATH3012. >> >> And this looks like a long-standing problem, at least for over two >> years. Many web pages suggest the same patch, but it's never merged >> to upstream. >> >> So this made me wonder what's going on. I see that the BTUSB_ATH3012 >> quirk was originally introduced just for this chip id (0cf3:3004). >> Is it a different variant from the original chip that causes a >> problem? > > not all patches from distro kernel are sent upstream. I have not heard of > this specific issues, but happy to accept patches to get it fixed. OK, basically it's like below. But, as mentioned, this made me wonder whether it's the right fix. The BTUSB_ATH3012 quirk was introduced exactly for this chip ID (0cf3:3004), and now this chip is moved to another quirk... If this is the right move, I can re-submit via git-send-email, too. Just let me know. >>> >>> Marcel, could you take a look at this? >>> If it sucks, let's seek for a better solution. >> >> wasn’t the confusion that this is fixed with a recent kernel? I am lost in >> this thread. I mean if people add Tested-by, then I can take this as well. >> Otherwise we might need someone from Qualcomm to shed some light into these. > > Well, *this* thread is likely different from the recent other > threads. > > Isn't 4.15.7 recent enough? At least, it already contains the > backport of relevant fixes: >Revert "Bluetooth: btusb: fix QCA Rome suspend/resume" >Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a > "rewritten" version > > (And it's not Yoga but MSI GS40 laptop, so DMI doesn't matter.) > According to Ivan, the reporter of the bug (now Cc'ed), 4.15.7 didn't > work without the patch, so the problem is still there, as it seems. > > In anyway, I'm going to build a kernel with my patch on top of 4.15.9 > for testing again. Maybe also a patched 4.16-rc5 kernel, too. If > it's confirmed, will report back with tested-by tag. I think there are two patches that are not yet in Linus’ tree and waiting in Dave’s net tree. We actually removed the Yoga DMI entry again since it was found that it is not needed. However there is a Dell OptiPlex entry that was needed. https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=0c6e526646c04ce31d4aaa280ed2237dd1cd774c Regards Marcel
Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible
On Tue, 2018-03-13 at 16:35 +0800, Ming Lei wrote: > Then looks this issue need to fix by making possible CPU count > accurate > because there are other resources allocated according to > num_possible_cpus(), > such as percpu variables. Short term the regression should be fixed. It is already v4.16-rc6, we have little time left. Longer term, yeah, I agree. Kernel's notion of possible CPU count should be realistic. Artem.
Re: [PATCH v3 5/5] linux/const.h: move BIT(_ULL) to linux/const.h for use in assembly
Hi Andrew,
2018-02-22 21:15 GMT+09:00 Masahiro Yamada :
> Commit 2fc016c5bd8a ("linux/const.h: Add _BITUL() and _BITULL()")
> introduced _BITUL() and _BITULL(). Its git-log says the difference
> from the already existing BIT() are:
>
> 1. The namespace is such that they can be used in uapi definitions.
> 2. The type is set with the _AC() macro to allow it to be used in
> assembly.
> 3. The type is explicitly specified to be UL or ULL.
>
> However, I found _BITUL() is mostly used in kernel-space since it is
> handy to share headers between C and assembly. If we only need '2.',
> we can improve the existing BIT() for use in assembly, allowing us to
> avoid unnecessary underscore prefixes.
>
> Signed-off-by: Masahiro Yamada
> ---
This patch conflicts with the one from Will Deacon.
(https://patchwork.kernel.org/patch/10242531/)
I think his patch is better than mine.
So, could you drop this one from your tree, please?
(only this one from the series.)
Thanks
> V2: https://patchwork.kernel.org/patch/9498271/
>
> Changes in v3: None
> Changes in v2: None
>
> include/linux/bitops.h | 3 +--
> include/linux/const.h | 3 +++
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/bitops.h b/include/linux/bitops.h
> index 4cac4e1..8a856be 100644
> --- a/include/linux/bitops.h
> +++ b/include/linux/bitops.h
> @@ -1,11 +1,10 @@
> /* SPDX-License-Identifier: GPL-2.0 */
> #ifndef _LINUX_BITOPS_H
> #define _LINUX_BITOPS_H
> +#include
> #include
>
> #ifdef __KERNEL__
> -#define BIT(nr)(1UL << (nr))
> -#define BIT_ULL(nr)(1ULL << (nr))
> #define BIT_MASK(nr) (1UL << ((nr) % BITS_PER_LONG))
> #define BIT_WORD(nr) ((nr) / BITS_PER_LONG)
> #define BIT_ULL_MASK(nr) (1ULL << ((nr) % BITS_PER_LONG_LONG))
> diff --git a/include/linux/const.h b/include/linux/const.h
> index 7b55a55..200892d 100644
> --- a/include/linux/const.h
> +++ b/include/linux/const.h
> @@ -6,4 +6,7 @@
> #define UL(x) (_UL(x))
> #define ULL(x) (_ULL(x))
>
> +#define BIT(x) (_BITUL(x))
> +#define BIT_ULL(x) (_BITULL(x))
> +
> #endif /* _LINUX_CONST_H */
> --
> 2.7.4
>
--
Best Regards
Masahiro Yamada
Re: [PATCH 5/5] arm64: allwinner: a64: Add support for TERES I laptop
Hi,
On Mon, Mar 12, 2018 at 04:10:50PM +, Harald Geyer wrote:
> The TERES I is an open hardware laptop built by Olimex using the
> Allwinner A64 SoC.
>
> Add the board specific .dts file, which includes the A64 .dtsi and
> enables the peripherals that we support so far.
>
> Signed-off-by: Harald Geyer
> ---
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 308
> +
> 2 files changed, 309 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> b/arch/arm64/boot/dts/allwinner/Makefile
> index f505227b0250..5f073f7423b7 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -5,6 +5,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-prime.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-zero-plus2.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> new file mode 100644
> index ..0d42b5111f0f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> @@ -0,0 +1,308 @@
> +/*
> + * Copyright (C) Harald Geyer
> + * based on sun50i-a64-olinuxino.dts by Jagan Teki
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
you should use an SPDX header here to define the license
> +
> +/dts-v1/;
> +
> +#include "sun50i-a64.dtsi"
> +
> +#include
> +#include
> +#include
> +
> +/ {
> + model = "Olimex Teres I A64";
It's called the Teres-I, there's no need for the A64 here
> + compatible = "olimex,a64-teres-i", "allwinner,sun50i-a64";
Or in the compatible
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm 0 5 0>;
> + brightness-levels = <0 10 20 30 40 50 60 70 100>;
> + default-brightness-level = <3>;
> + enable-gpios = <&pio 3 23 GPIO_ACTIVE_HIGH>; /* PD23 */
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> +
> + framebuffer-lcd {
> + eDP25-supply = <®_dldo2>;
> + eDP12-supply = <®_dldo3>;
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + lid-switch {
> + label = "Lid Switch";
> + gpios = <&r_pio 0 8 GPIO_ACTIVE_LOW>; /* PL8 */
> + linux,input-type = ;
> +
Re: [PATCH v2 10/10] board: Add STM32F769 SoC, discovery board support
Hi Yannick On 03/02/2018 04:44 PM, yannick fertre wrote: > Signed-off-by: yannick fertre Can you add a commit message explaining why you add a specific defconfig for this board. FYI, previously, the same defconfig was used for all STM32F7 boards (ie /stm32f746-disco_defconfig). You will also need to resync with the last master branch regarding defconfig content. Thanks Patrice > --- > configs/stm32f769-disco_defconfig | 63 > +++ > 1 file changed, 63 insertions(+) > create mode 100644 configs/stm32f769-disco_defconfig > > diff --git a/configs/stm32f769-disco_defconfig > b/configs/stm32f769-disco_defconfig > new file mode 100644 > index 000..ac34076 > --- /dev/null > +++ b/configs/stm32f769-disco_defconfig > @@ -0,0 +1,63 @@ > +CONFIG_ARM=y > +CONFIG_STM32=y > +CONFIG_SYS_MALLOC_F_LEN=0xC00 > +CONFIG_STM32F7=y > +CONFIG_TARGET_STM32F746_DISCO=y > +CONFIG_DEFAULT_DEVICE_TREE="stm32f769-disco" > +CONFIG_BOOTDELAY=3 > +CONFIG_USE_BOOTARGS=y > +CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk consoleblank=0 > ignore_loglevel" > +# CONFIG_DISPLAY_CPUINFO is not set > +# CONFIG_DISPLAY_BOARDINFO is not set > +CONFIG_BOARD_EARLY_INIT_F=y > +CONFIG_HUSH_PARSER=y > +CONFIG_SYS_PROMPT="U-Boot > " > +CONFIG_AUTOBOOT_KEYED=y > +CONFIG_AUTOBOOT_PROMPT="Hit SPACE in %d seconds to stop autoboot.\n" > +CONFIG_AUTOBOOT_STOP_STR=" " > +CONFIG_CMD_BOOTZ=y > +# CONFIG_CMD_FPGA is not set > +CONFIG_CMD_GPT=y > +# CONFIG_RANDOM_UUID is not set > +CONFIG_CMD_MMC=y > +CONFIG_CMD_SF=y > +# CONFIG_CMD_SETEXPR is not set > +CONFIG_CMD_DHCP=y > +CONFIG_CMD_MII=y > +CONFIG_CMD_PING=y > +CONFIG_CMD_SNTP=y > +CONFIG_CMD_DNS=y > +CONFIG_CMD_LINK_LOCAL=y > +CONFIG_CMD_BMP=y > +CONFIG_CMD_TIMER=y > +CONFIG_CMD_EXT2=y > +CONFIG_CMD_EXT4=y > +CONFIG_CMD_FAT=y > +CONFIG_CMD_FS_GENERIC=y > +# CONFIG_DOS_PARTITION is not set > +CONFIG_OF_CONTROL=y > +CONFIG_NET_RANDOM_ETHADDR=y > +CONFIG_NETCONSOLE=y > +# CONFIG_BLK is not set > +CONFIG_DM_MMC=y > +# CONFIG_SPL_DM_MMC is not set > +CONFIG_ARM_PL180_MMCI=y > +CONFIG_MTD=y > +CONFIG_MTD_NOR_FLASH=y > +CONFIG_DM_SPI_FLASH=y > +CONFIG_SPI_FLASH=y > +CONFIG_SPI_FLASH_STMICRO=y > +CONFIG_DM_ETH=y > +CONFIG_ETH_DESIGNWARE=y > +# CONFIG_PINCTRL_FULL is not set > +CONFIG_DM_SPI=y > +CONFIG_STM32_QSPI=y > +CONFIG_DM_VIDEO=y > +CONFIG_BACKLIGHT_GPIO=y > +CONFIG_VIDEO_LCD_ORISETECH_OTM8009A=y > +CONFIG_VIDEO_STM32=y > +CONFIG_VIDEO_STM32_DSI=y > +CONFIG_VIDEO_STM32_MAX_XRES=480 > +CONFIG_VIDEO_STM32_MAX_YRES=800 > +CONFIG_OF_LIBFDT_OVERLAY=y > +# CONFIG_EFI_LOADER is not set >
Re: [PATCH v2 01/10] video: stm32: stm32_ltdc: add bridge to display controller
Hi Yannick
On 03/02/2018 04:44 PM, yannick fertre wrote:
> Manage a bridge insert between the display controller & a panel.
>
> Signed-off-by: yannick fertre
> ---
> drivers/video/stm32/stm32_ltdc.c | 107
> ++-
> 1 file changed, 71 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/video/stm32/stm32_ltdc.c
> b/drivers/video/stm32/stm32_ltdc.c
> index e160c77..bd9c0de 100644
> --- a/drivers/video/stm32/stm32_ltdc.c
> +++ b/drivers/video/stm32/stm32_ltdc.c
> @@ -8,6 +8,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -15,12 +16,12 @@
> #include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> struct stm32_ltdc_priv {
> void __iomem *regs;
> - struct display_timing timing;
> enum video_log2_bpp l2bpp;
> u32 bg_col_argb;
> u32 crop_x, crop_y, crop_w, crop_h;
> @@ -210,23 +211,23 @@ static void stm32_ltdc_enable(struct stm32_ltdc_priv
> *priv)
> setbits_le32(priv->regs + LTDC_GCR, GCR_LTDCEN);
> }
>
> -static void stm32_ltdc_set_mode(struct stm32_ltdc_priv *priv)
> +static void stm32_ltdc_set_mode(struct stm32_ltdc_priv *priv,
> + struct display_timing *timings)
> {
> void __iomem *regs = priv->regs;
> - struct display_timing *timing = &priv->timing;
> u32 hsync, vsync, acc_hbp, acc_vbp, acc_act_w, acc_act_h;
> u32 total_w, total_h;
> u32 val;
>
> /* Convert video timings to ltdc timings */
> - hsync = timing->hsync_len.typ - 1;
> - vsync = timing->vsync_len.typ - 1;
> - acc_hbp = hsync + timing->hback_porch.typ;
> - acc_vbp = vsync + timing->vback_porch.typ;
> - acc_act_w = acc_hbp + timing->hactive.typ;
> - acc_act_h = acc_vbp + timing->vactive.typ;
> - total_w = acc_act_w + timing->hfront_porch.typ;
> - total_h = acc_act_h + timing->vfront_porch.typ;
> + hsync = timings->hsync_len.typ - 1;
> + vsync = timings->vsync_len.typ - 1;
> + acc_hbp = hsync + timings->hback_porch.typ;
> + acc_vbp = vsync + timings->vback_porch.typ;
> + acc_act_w = acc_hbp + timings->hactive.typ;
> + acc_act_h = acc_vbp + timings->vactive.typ;
> + total_w = acc_act_w + timings->hfront_porch.typ;
> + total_h = acc_act_h + timings->vfront_porch.typ;
>
> /* Synchronization sizes */
> val = (hsync << 16) | vsync;
> @@ -248,14 +249,14 @@ static void stm32_ltdc_set_mode(struct stm32_ltdc_priv
> *priv)
>
> /* Signal polarities */
> val = 0;
> - debug("%s: timing->flags 0x%08x\n", __func__, timing->flags);
> - if (timing->flags & DISPLAY_FLAGS_HSYNC_HIGH)
> + debug("%s: timing->flags 0x%08x\n", __func__, timings->flags);
> + if (timings->flags & DISPLAY_FLAGS_HSYNC_HIGH)
> val |= GCR_HSPOL;
> - if (timing->flags & DISPLAY_FLAGS_VSYNC_HIGH)
> + if (timings->flags & DISPLAY_FLAGS_VSYNC_HIGH)
> val |= GCR_VSPOL;
> - if (timing->flags & DISPLAY_FLAGS_DE_HIGH)
> + if (timings->flags & DISPLAY_FLAGS_DE_HIGH)
> val |= GCR_DEPOL;
> - if (timing->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
> + if (timings->flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
> val |= GCR_PCPOL;
> clrsetbits_le32(regs + LTDC_GCR,
> GCR_HSPOL | GCR_VSPOL | GCR_DEPOL | GCR_PCPOL, val);
> @@ -331,7 +332,11 @@ static int stm32_ltdc_probe(struct udevice *dev)
> struct video_uc_platdata *uc_plat = dev_get_uclass_platdata(dev);
> struct video_priv *uc_priv = dev_get_uclass_priv(dev);
> struct stm32_ltdc_priv *priv = dev_get_priv(dev);
> - struct udevice *panel;
> +#ifdef CONFIG_VIDEO_BRIDGE
> + struct udevice *bridge = NULL;
> +#endif
> + struct udevice *panel = NULL;
> + struct display_timing timings;
> struct clk pclk;
> struct reset_ctl rst;
> int rate, ret;
> @@ -364,63 +369,93 @@ static int stm32_ltdc_probe(struct udevice *dev)
> /* Reset */
> reset_deassert(&rst);
>
> - ret = uclass_first_device(UCLASS_PANEL, &panel);
> +#ifdef CONFIG_VIDEO_BRIDGE
> + ret = uclass_get_device(UCLASS_VIDEO_BRIDGE, 0, &bridge);
> if (ret) {
> - debug("%s: panel device error %d\n", __func__, ret);
> - return ret;
> + debug("%s: No video bridge, or no backlight on bridge\n",
> + __func__);
> }
>
> - ret = panel_enable_backlight(panel);
> + if (bridge) {
> + ret = video_bridge_attach(bridge);
> + if (ret) {
> + debug("%s: fail to attach bridge\n", __func__);
I would replace debug by dev_err() here.
> + return ret;
> + }
> + }
> +#endif
> + ret = uclass_first_device(UCLASS_PANEL, &panel);
> if (ret) {
> - debug("%s: panel %s enable backlight error %d\n",
> - __func__, panel->name, ret);
>
Re: [pci PATCH v5 3/4] ena: Migrate over to unmanaged SR-IOV support
On Tue, 2018-03-13 at 09:16 +0100, Christoph Hellwig wrote: > On Tue, Mar 13, 2018 at 08:12:52AM +, David Woodhouse wrote: > > > > I'd also *really* like to see a way to enable this for PFs which don't > > have (and don't need) a driver. We seem to have lost that along the > > way. > We've been forth and back on that. I agree that not having any driver > just seems dangerous. If your PF really does nothing we should just > have a trivial pf_stub driver that does nothing but wiring up > pci_sriov_configure_simple. We can then add PCI IDs to it either > statically, or using the dynamic ids mechanism. Or just add it to the existing pci-stub. What's the point in having a new driver? smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 1/5] arm64: dts: allwinner: a64: Add i2c0 pins
André Przywara writes:
> On 12/03/18 16:10, Harald Geyer wrote:
> > Add the proper pin group node to reference in board files.
> >
> > Signed-off-by: Harald Geyer
>
> That looks correct to me, so:
>
> Reviewed-by: Andre Przywara
>
> But out of curiosity, what is this used for? In patch 5/5 I see it being
> used, but without a clue for what? Shouldn't enabling an I2C node be
> accompanied by some child node, presenting the device on the bus?
> I guess this I2C is not on some kind of "header" on that laptop?
I enabled it because the ANX6345 eDP-bridge is on that bus. There is
no linux (mainline) driver for this chip at the moment, the bootloader
initializes it. However I'm using the i2c-dev driver to read (and maybe)
change some register values from user space.
i2cdetect sees devices at 0x38, 0x39 and 0x3d - all of which might
be the ANX6345. I haven't looked into this in detail.
Since you are asking: Actually the teres has a "header" with usb-otg,
spi, i2c1 and some gpios, but it isn't exposed on the exterior of the
case and nothing is connected to it. So I didn't bother with adding
nodes for this in DT. Curious what olimex are planning to do with that.
Thanks for your review,
Harald
> Cheers,
> Andre.
>
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > index 1b6dc31e7d91..64e452a758fa 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > @@ -309,6 +309,11 @@
> > interrupt-controller;
> > #interrupt-cells = <3>;
> >
> > + i2c0_pins: i2c0_pins {
> > + pins = "PH0", "PH1";
> > + function = "i2c0";
> > + };
> > +
> > i2c1_pins: i2c1_pins {
> > pins = "PH2", "PH3";
> > function = "i2c1";
> >
>
--
If you want to support my work:
see http://friends.ccbib.org/harald/supporting/
or donate via CLAM to xASPBtezLNqj4cUe8MT5nZjthRSEjrRQXN
or via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w
Re: linux-next: manual merge of the staging tree with the vfs tree
On Tue, Mar 13, 2018 at 03:22:40PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the staging tree got conflicts in:
>
> drivers/staging/lustre/lnet/libcfs/linux/linux-curproc.c
> drivers/staging/lustre/lnet/libcfs/linux/linux-prim.c
>
> between commit:
>
> 304ec482f562 ("get rid of pointless includes of fs_struct.h")
>
> from the vfs tree and commits:
>
> 37d3b407dc14 ("staging: lustre: remove linux-curproc.c")
> 6b7936ceefa7 ("staging: lustre: make signal-blocking functions inline")
>
> from the staging tree.
>
> I fixed it up (I just removed the files) and can carry the fix as
> necessary.
Sounds like the correct fix, thanks.
greg k-h
[PATCH 11/11] RISC-V: Add definition of relocation types
Signed-off-by: Zong Li --- arch/riscv/include/uapi/asm/elf.h | 24 1 file changed, 24 insertions(+) diff --git a/arch/riscv/include/uapi/asm/elf.h b/arch/riscv/include/uapi/asm/elf.h index a510edfa8226..5111c7c35e8b 100644 --- a/arch/riscv/include/uapi/asm/elf.h +++ b/arch/riscv/include/uapi/asm/elf.h @@ -79,5 +79,29 @@ typedef union __riscv_fp_state elf_fpregset_t; #define R_RISCV_TPREL_I49 #define R_RISCV_TPREL_S50 #define R_RISCV_RELAX 51 +#define R_RISCV_SUB6 52 +#define R_RISCV_SET6 53 +#define R_RISCV_SET8 54 +#define R_RISCV_SET16 55 +#define R_RISCV_SET32 56 +#define R_RISCV_32_PCREL 57 + +/* NDS V5*/ +#define R_RISCV_ALIGN_BTB 240 +#define R_RISCV_10_PCREL 241 +#define R_RISCV_DATA 242 +#define R_RISCV_LALO_HI20 243 +#define R_RISCV_LALO_LO12_I244 +#define R_RISCV_RELAX_ENTRY245 +#define R_RISCV_LGP18S0246 +#define R_RISCV_LGP17S1247 +#define R_RISCV_LGP17S2248 +#define R_RISCV_LGP17S3249 +#define R_RISCV_SGP18S0250 +#define R_RISCV_SGP17S1251 +#define R_RISCV_SGP17S2252 +#define R_RISCV_SGP17S3253 +#define R_RISCV_RELAX_REGION_BEGIN 254 +#define R_RISCV_RELAX_REGION_END 255 #endif /* _UAPI_ASM_ELF_H */ -- 2.16.1
[PATCH 01/11] RISC-V: Add sections of PLT and GOT for kernel module
The address of external symbols will locate more than 32-bit offset
in 64-bit kernel with sv39 or sv48 virtual addressing.
Module loader emits the GOT and PLT entries for data symbols and
function symbols respectively.
The PLT entry is a trampoline code for jumping to the 64-bit
real address. The GOT entry is just the data symbol address.
Signed-off-by: Zong Li
---
arch/riscv/Kconfig | 5 ++
arch/riscv/Makefile | 3 +
arch/riscv/include/asm/module.h | 102 ++
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/module-sections.c | 139
arch/riscv/kernel/module.lds| 7 ++
6 files changed, 257 insertions(+)
create mode 100644 arch/riscv/include/asm/module.h
create mode 100644 arch/riscv/kernel/module-sections.c
create mode 100644 arch/riscv/kernel/module.lds
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 310b9a5d6737..e2ff7c23dfe0 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -135,6 +135,9 @@ choice
bool "medium any code model"
endchoice
+config MODULE_SECTIONS
+ bool "Support GOT and PLT sections"
+
choice
prompt "Maximum Physical Memory"
default MAXPHYSMEM_2GB if 32BIT
@@ -145,6 +148,8 @@ choice
bool "2GiB"
config MAXPHYSMEM_128GB
depends on 64BIT && CMODEL_MEDANY
+ select MODULE_SECTIONS if MODULES
+ select HAVE_MOD_ARCH_SPECIFIC
bool "128GiB"
endchoice
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 26892daefa05..d8b4e5c9277f 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -56,6 +56,9 @@ endif
ifeq ($(CONFIG_CMODEL_MEDANY),y)
KBUILD_CFLAGS += -mcmodel=medany
endif
+ifeq ($(CONFIG_MODULE_SECTIONS),y)
+ KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/riscv/kernel/module.lds
+endif
# GCC versions that support the "-mstrict-align" option default to allowing
# unaligned accesses. While unaligned accesses are explicitly allowed in the
diff --git a/arch/riscv/include/asm/module.h b/arch/riscv/include/asm/module.h
new file mode 100644
index ..bcc48d113deb
--- /dev/null
+++ b/arch/riscv/include/asm/module.h
@@ -0,0 +1,102 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (C) 2017 Andes Technology Corporation */
+
+#ifndef _ASM_RISCV_MODULE_H
+#define _ASM_RISCV_MODULE_H
+
+#include
+
+#define MODULE_ARCH_VERMAGIC"riscv"
+
+#ifdef CONFIG_MODULE_SECTIONS
+struct mod_section {
+ struct elf64_shdr *shdr;
+ int num_entries;
+ int max_entries;
+};
+
+struct mod_arch_specific {
+ struct mod_section got;
+ struct mod_section plt;
+};
+#endif
+
+u64 module_emit_got_entry(struct module *mod, u64 val);
+u64 module_emit_plt_entry(struct module *mod, u64 val);
+
+struct got_entry {
+ u64 symbol_addr;/* the real variable address */
+};
+
+static inline struct got_entry emit_got_entry(u64 val)
+{
+ return (struct got_entry) {val};
+}
+
+static inline struct got_entry *get_got_entry(u64 val,
+ const struct mod_section *sec)
+{
+ struct got_entry *got = (struct got_entry *)sec->shdr->sh_addr;
+ int i;
+ for (i = 0; i < sec->num_entries; i++) {
+ if (got[i].symbol_addr == val)
+ return &got[i];
+ }
+ return NULL;
+}
+
+struct plt_entry {
+ /*
+* Trampoline code to real target address. The return address
+* should be the original (pc+4) before entring plt entry.
+* For 8 byte alignment of symbol_addr,
+* don't pack structure to remove the padding.
+*/
+ u32 insn_auipc; /* auipc t0, 0x0 */
+ u32 insn_ld;/* ldt1, 0x10(t0) */
+ u32 insn_jr;/* jrt1*/
+ u64 symbol_addr;/* the real jump target address*/
+};
+
+#define OPC_AUIPC 0x0017
+#define OPC_LD 0x3003
+#define OPC_JALR 0x0067
+#define REG_T0 0x5
+#define REG_T1 0x6
+#define IMM_OFFSET 0x10
+
+static inline struct plt_entry emit_plt_entry(u64 val)
+{
+ /*
+* U-Type encoding:
+* ++--+--+
+* | imm[31:12] | rd[11:7] | opc[6:0] |
+* ++--+--+
+*
+* I-Type encoding:
+* ++++--+--+
+* | imm[31:20] | rs1[19:15] | funct3 | rd[11:7] | opc[6:0] |
+* ++++--+--+
+*
+*/
+ return (struct plt_entry) {
+ OPC_AUIPC | (REG_T0 << 7),
+ OPC_LD | (IMM_OFFSET << 20) | (REG_T0 << 15) | (REG_T1 << 7),
+ OPC_JALR | (REG_T1 << 15),
+ val
+ };
+}
+
+static inline struct plt_entry *get_plt_entry(
Re: [PATCH v2 02/10] video: stm32: stm32_ltdc: update debug log
Hi Yannick
On 03/02/2018 04:44 PM, yannick fertre wrote:
> Replace macro debug by pr_error, pr_warn or pr_info.
>
> Signed-off-by: yannick fertre
> ---
> drivers/video/stm32/stm32_ltdc.c | 62
>
> 1 file changed, 31 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/video/stm32/stm32_ltdc.c
> b/drivers/video/stm32/stm32_ltdc.c
> index bd9c0de..e95f35c 100644
> --- a/drivers/video/stm32/stm32_ltdc.c
> +++ b/drivers/video/stm32/stm32_ltdc.c
> @@ -176,13 +176,13 @@ static u32 stm32_ltdc_get_pixel_format(enum
> video_log2_bpp l2bpp)
> case VIDEO_BPP2:
> case VIDEO_BPP4:
> default:
> - debug("%s: warning %dbpp not supported yet, %dbpp instead\n",
> - __func__, VNBITS(l2bpp), VNBITS(VIDEO_BPP16));
> + pr_warn("%s: warning %dbpp not supported yet, %dbpp instead\n",
> + __func__, VNBITS(l2bpp), VNBITS(VIDEO_BPP16));
> pf = PF_RGB565;
> break;
> }
>
> - debug("%s: %d bpp -> ltdc pf %d\n", __func__, VNBITS(l2bpp), pf);
> + pr_info("%s: %d bpp -> ltdc pf %d\n", __func__, VNBITS(l2bpp), pf);
>
> return (u32)pf;
> }
> @@ -249,7 +249,7 @@ static void stm32_ltdc_set_mode(struct stm32_ltdc_priv
> *priv,
>
> /* Signal polarities */
> val = 0;
> - debug("%s: timing->flags 0x%08x\n", __func__, timings->flags);
> + pr_info("%s: timing->flags 0x%08x\n", __func__, timings->flags);
> if (timings->flags & DISPLAY_FLAGS_HSYNC_HIGH)
> val |= GCR_HSPOL;
> if (timings->flags & DISPLAY_FLAGS_VSYNC_HIGH)
> @@ -343,26 +343,26 @@ static int stm32_ltdc_probe(struct udevice *dev)
>
> priv->regs = (void *)dev_read_addr(dev);
> if ((fdt_addr_t)priv->regs == FDT_ADDR_T_NONE) {
> - debug("%s: ltdc dt register address error\n", __func__);
> + pr_err("%s: ltdc dt register address error\n", __func__);
As you get access to the struct udevice, prefer dev_err() here.
> return -EINVAL;
> }
>
> ret = clk_get_by_index(dev, 0, &pclk);
> if (ret) {
> - debug("%s: peripheral clock get error %d\n", __func__, ret);
> + pr_err("%s: peripheral clock get error %d\n", __func__, ret);
ditto
> return ret;
> }
>
> ret = clk_enable(&pclk);
> if (ret) {
> - debug("%s: peripheral clock enable error %d\n",
> - __func__, ret);
> + pr_err("%s: peripheral clock enable error %d\n",
> +__func__, ret);
ditto
> return ret;
> }
>
> ret = reset_get_by_index(dev, 0, &rst);
> if (ret) {
> - debug("%s: missing ltdc hardware reset\n", __func__);
> + pr_err("%s: missing ltdc hardware reset\n", __func__);
ditto
> return -ENODEV;
> }
>
> @@ -372,41 +372,40 @@ static int stm32_ltdc_probe(struct udevice *dev)
> #ifdef CONFIG_VIDEO_BRIDGE
> ret = uclass_get_device(UCLASS_VIDEO_BRIDGE, 0, &bridge);
> if (ret) {
> - debug("%s: No video bridge, or no backlight on bridge\n",
> - __func__);
> + pr_info("%s: No video bridge, or no backlight on bridge\n",
> + __func__);
dev_info()
> }
>
> if (bridge) {
> ret = video_bridge_attach(bridge);
> if (ret) {
> - debug("%s: fail to attach bridge\n", __func__);
> + pr_err("%s: fail to attach bridge\n", __func__);
dev_err()
> return ret;
> }
> }
> #endif
> ret = uclass_first_device(UCLASS_PANEL, &panel);
> if (ret) {
> - debug("%s: panel device error %d\n", __func__, ret);
> + pr_err("%s: panel device error %d\n", __func__, ret);
ditto
> return ret;
> }
>
> ret = fdtdec_decode_display_timing(gd->fdt_blob, dev_of_offset(panel),
> 0, &timings);
> if (ret) {
> - debug("%s: decode display timing error %d\n",
> - __func__, ret);
> + pr_err("%s: decode display timing error %d\n", __func__, ret);
ditto
> return ret;
> }
>
> rate = clk_set_rate(&pclk, timings.pixelclock.typ);
> if (rate < 0) {
> - debug("%s: fail to set pixel clock %d hz %d hz\n",
> - __func__, timings.pixelclock.typ, rate);
> + pr_err("%s: fail to set pixel clock %d hz %d hz\n",
> +__func__, timings.pixelclock.typ, rate);
ditto
> return rate;
> }
>
> - debug("%s: Set pixel clock req %d hz get %d hz\n", __func__,
> - timings.pixelclock.typ, rate);
> + pr_info("%s: Set pixel clock req %d hz get %d hz\n", __func__,
> + timings.pixelclock.typ, rate);
>
> /* TODO Below
[PATCH 08/11] RISC-V: Support ADD32 relocation type in kernel module
Signed-off-by: Zong Li
---
arch/riscv/kernel/module.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
index 351bf2a518ee..2d14dff22861 100644
--- a/arch/riscv/kernel/module.c
+++ b/arch/riscv/kernel/module.c
@@ -246,6 +246,13 @@ static int apply_r_riscv_align_rela(struct module *me, u32
*location,
return 0;
}
+static int apply_r_riscv_add32_rela(struct module *me, u32 *location,
+ Elf_Addr v)
+{
+ *(u32 *)location += (*(u32 *)v);
+ return 0;
+}
+
static int (*reloc_handlers_rela[]) (struct module *me, u32 *location,
Elf_Addr v) = {
[R_RISCV_64]= apply_r_riscv_64_rela,
@@ -264,6 +271,7 @@ static int (*reloc_handlers_rela[]) (struct module *me, u32
*location,
[R_RISCV_CALL] = apply_r_riscv_call_rela,
[R_RISCV_RELAX] = apply_r_riscv_relax_rela,
[R_RISCV_ALIGN] = apply_r_riscv_align_rela,
+ [R_RISCV_ADD32] = apply_r_riscv_add32_rela,
};
int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
--
2.16.1
[PATCH 09/11] RISC-V: Support SUB32 relocation type in kernel module
Signed-off-by: Zong Li
---
arch/riscv/kernel/module.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
index 2d14dff22861..4228270efe93 100644
--- a/arch/riscv/kernel/module.c
+++ b/arch/riscv/kernel/module.c
@@ -253,6 +253,13 @@ static int apply_r_riscv_add32_rela(struct module *me, u32
*location,
return 0;
}
+static int apply_r_riscv_sub32_rela(struct module *me, u32 *location,
+ Elf_Addr v)
+{
+ *(u32 *)location -= (*(u32 *)v);
+ return 0;
+}
+
static int (*reloc_handlers_rela[]) (struct module *me, u32 *location,
Elf_Addr v) = {
[R_RISCV_64]= apply_r_riscv_64_rela,
@@ -272,6 +279,7 @@ static int (*reloc_handlers_rela[]) (struct module *me, u32
*location,
[R_RISCV_RELAX] = apply_r_riscv_relax_rela,
[R_RISCV_ALIGN] = apply_r_riscv_align_rela,
[R_RISCV_ADD32] = apply_r_riscv_add32_rela,
+ [R_RISCV_SUB32] = apply_r_riscv_sub32_rela,
};
int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
--
2.16.1
[PATCH 10/11] RISC-V: Enable module support in defconfig
Signed-off-by: Zong Li --- arch/riscv/configs/defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig index 92ff23586c11..07326466871b 100644 --- a/arch/riscv/configs/defconfig +++ b/arch/riscv/configs/defconfig @@ -74,3 +74,5 @@ CONFIG_NFS_V4_2=y CONFIG_ROOT_NFS=y # CONFIG_RCU_TRACE is not set CONFIG_CRYPTO_USER_API_HASH=y +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y -- 2.16.1
Re: [PATCH net-next] modules: allow modprobe load regular elf binaries
On Mon, Mar 12, 2018 at 10:22:00AM -0700, Alexei Starovoitov wrote: > On 3/10/18 7:34 AM, Luis R. Rodriguez wrote: > > Also, > > > > Alexei you never answered my questions out aliases with the umh modules. > > Long term this important to consider. > > aliases always felt like a crutch to me. > I can see an argument when they're used as 'alias pci:* foo' > but the way it's used in networking with ip_set_* and nf-* is > something I prefer not to ever do again. > Definitely no aliases for bpfilter umh. I agree, let's not do that if at all possible for these types of binaries. greg k-h
[PATCH 07/11] RISC-V: Support ALIGN relocation type in kernel module
Just ignore align type. The nop instructions cannot be removed in
kernel module. Kernel modules is not doing relax.
Signed-off-by: Zong Li
---
arch/riscv/kernel/module.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
index e23c051dfc62..351bf2a518ee 100644
--- a/arch/riscv/kernel/module.c
+++ b/arch/riscv/kernel/module.c
@@ -240,6 +240,12 @@ static int apply_r_riscv_relax_rela(struct module *me, u32
*location,
return 0;
}
+static int apply_r_riscv_align_rela(struct module *me, u32 *location,
+ Elf_Addr v)
+{
+ return 0;
+}
+
static int (*reloc_handlers_rela[]) (struct module *me, u32 *location,
Elf_Addr v) = {
[R_RISCV_64]= apply_r_riscv_64_rela,
@@ -257,6 +263,7 @@ static int (*reloc_handlers_rela[]) (struct module *me, u32
*location,
[R_RISCV_CALL_PLT] = apply_r_riscv_call_plt_rela,
[R_RISCV_CALL] = apply_r_riscv_call_rela,
[R_RISCV_RELAX] = apply_r_riscv_relax_rela,
+ [R_RISCV_ALIGN] = apply_r_riscv_align_rela,
};
int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
--
2.16.1
[PATCH 05/11] RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module
HI20 and LO12_I/LO12_S relocate the absolute address, the range of
offset must in 32-bit.
Signed-off-by: Zong Li
---
arch/riscv/kernel/module.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
index 7e85e5840b4d..654fe7dcd38d 100644
--- a/arch/riscv/kernel/module.c
+++ b/arch/riscv/kernel/module.c
@@ -92,6 +92,45 @@ static int apply_r_riscv_pcrel_lo12_s_rela(struct module
*me, u32 *location,
return 0;
}
+static int apply_r_riscv_hi20_rela(struct module *me, u32 *location,
+ Elf_Addr v)
+{
+ s32 hi20;
+
+ if (IS_ENABLED(CMODEL_MEDLOW)) {
+ pr_err(
+ "%s: target %016llx can not be addressed by the 32-bit offset
from PC = %p\n",
+ me->name, v, location);
+ return -EINVAL;
+ }
+
+ hi20 = ((s32)v + 0x800) & 0xf000;
+ *location = (*location & 0xfff) | hi20;
+ return 0;
+}
+
+static int apply_r_riscv_lo12_i_rela(struct module *me, u32 *location,
+Elf_Addr v)
+{
+ /* Skip medlow checking because of filtering by HI20 already */
+ s32 hi20 = ((s32)v + 0x800) & 0xf000;
+ s32 lo12 = ((s32)v - hi20);
+ *location = (*location & 0xf) | ((lo12 & 0xfff) << 20);
+ return 0;
+}
+
+static int apply_r_riscv_lo12_s_rela(struct module *me, u32 *location,
+Elf_Addr v)
+{
+ /* Skip medlow checking because of filtering by HI20 already */
+ s32 hi20 = ((s32)v + 0x800) & 0xf000;
+ s32 lo12 = ((s32)v - hi20);
+ u32 imm11_5 = (lo12 & 0xfe0) << (31 - 11);
+ u32 imm4_0 = (lo12 & 0x1f) << (11 - 4);
+ *location = (*location & 0x1fff07f) | imm11_5 | imm4_0;
+ return 0;
+}
+
static int apply_r_riscv_got_hi20_rela(struct module *me, u32 *location,
Elf_Addr v)
{
@@ -176,6 +215,9 @@ static int (*reloc_handlers_rela[]) (struct module *me, u32
*location,
[R_RISCV_PCREL_HI20]= apply_r_riscv_pcrel_hi20_rela,
[R_RISCV_PCREL_LO12_I] = apply_r_riscv_pcrel_lo12_i_rela,
[R_RISCV_PCREL_LO12_S] = apply_r_riscv_pcrel_lo12_s_rela,
+ [R_RISCV_HI20] = apply_r_riscv_hi20_rela,
+ [R_RISCV_LO12_I]= apply_r_riscv_lo12_i_rela,
+ [R_RISCV_LO12_S]= apply_r_riscv_lo12_s_rela,
[R_RISCV_GOT_HI20] = apply_r_riscv_got_hi20_rela,
[R_RISCV_CALL_PLT] = apply_r_riscv_call_plt_rela,
[R_RISCV_CALL] = apply_r_riscv_call_rela,
--
2.16.1
Re: [PATCH 1/2] infiniband: qplib_fp: fix pointer cast
On Wed, Mar 7, 2018 at 11:12 AM, Arnd Bergmann wrote: > On Wed, Mar 7, 2018 at 10:05 AM, Arnd Bergmann wrote: > >> A small complication is that I wrote the changelog for the build warning >> on 32-bit architectures, which is more elaborate. kernelci.org for >> some reasons currently skips the allmodconfig build on all 32-bit >> architectures (I should ask the kernelci maintainers to change that), > > I see that Olof's build bot does have build results for arm32 > allmodconfig, which is also big-endian, and reports the same > errors that I described in the patch changelog. > > See > > http://arm-soc.lixom.net/buildlogs/arm-soc/v4.16-rc4-25-g41c42fe/ > http://arm-soc.lixom.net/buildlogs/arm-soc/v4.16-rc4-25-g41c42fe/buildall.arm.allmodconfig.log.passed > > for today's results. > > This bot reports one other warning for arm32, but it's > specific to the toolchain version used on that bot. > I have a fix for that one as well, but there was some > discussion on what the best approach would be. Any update on this? This is now the only remaining gcc warning we get on allmodconfig builds for arm (both 32-bit and 64-bit) in linux-4.16-rc. Arnd
Re: [tip:locking/core 9/11] include/asm-generic/atomic-instrumented.h:288:24: sparse: cast truncates bits from constant value (100 becomes 0)
On Mon, Mar 12, 2018 at 6:17 PM, Dmitry Vyukov wrote:
> On Mon, Mar 12, 2018 at 5:52 PM, kbuild test robot
> wrote:
>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
>> locking/core
>> head: ac605bee0bfab40fd5d11964705e907d2d5a32de
>> commit: 8bf705d130396e69c04cd8e6e010244ad2ce71f4 [9/11] locking/atomic/x86:
>> Switch atomic.h to use atomic-instrumented.h
>> reproduce:
>> # apt-get install sparse
>> git checkout 8bf705d130396e69c04cd8e6e010244ad2ce71f4
>> make ARCH=x86_64 allmodconfig
>> make C=1 CF=-D__CHECK_ENDIAN__
>>
>>
>> sparse warnings: (new ones prefixed by >>)
>>
>>kernel/locking/qspinlock.c:418:22: sparse: incorrect type in assignment
>> (different modifiers) @@expected struct mcs_spinlock *prev @@got
>> struct struct mcs_spinlock *prev @@
>>kernel/locking/qspinlock.c:418:22:expected struct mcs_spinlock *prev
>>kernel/locking/qspinlock.c:418:22:got struct mcs_spinlock [pure] *
>>kernel/locking/qspinlock_paravirt.h:519:1: sparse: symbol
>> '__pv_queued_spin_unlock_slowpath' was not declared. Should it be static?
>>kernel/locking/qspinlock.c:418:22: sparse: incorrect type in assignment
>> (different modifiers) @@expected struct mcs_spinlock *prev @@got
>> struct struct mcs_spinlock *prev @@
>>kernel/locking/qspinlock.c:418:22:expected struct mcs_spinlock *prev
>>kernel/locking/qspinlock.c:418:22:got struct mcs_spinlock [pure] *
include/asm-generic/atomic-instrumented.h:288:24: sparse: cast truncates
bits from constant value (100 becomes 0)
>>
>> vim +288 include/asm-generic/atomic-instrumented.h
>>
>> b06ed71a6 Dmitry Vyukov 2018-01-29 282
>> b06ed71a6 Dmitry Vyukov 2018-01-29 283 static __always_inline unsigned long
>> b06ed71a6 Dmitry Vyukov 2018-01-29 284 cmpxchg_size(volatile void *ptr,
>> unsigned long old, unsigned long new, int size)
>> b06ed71a6 Dmitry Vyukov 2018-01-29 285 {
>> b06ed71a6 Dmitry Vyukov 2018-01-29 286 switch (size) {
>> b06ed71a6 Dmitry Vyukov 2018-01-29 287 case 1:
>> b06ed71a6 Dmitry Vyukov 2018-01-29 @288 return
>> arch_cmpxchg((u8 *)ptr, (u8)old, (u8)new);
>> b06ed71a6 Dmitry Vyukov 2018-01-29 289 case 2:
>> b06ed71a6 Dmitry Vyukov 2018-01-29 290 return
>> arch_cmpxchg((u16 *)ptr, (u16)old, (u16)new);
>> b06ed71a6 Dmitry Vyukov 2018-01-29 291 case 4:
>> b06ed71a6 Dmitry Vyukov 2018-01-29 292 return
>> arch_cmpxchg((u32 *)ptr, (u32)old, (u32)new);
>> b06ed71a6 Dmitry Vyukov 2018-01-29 293 case 8:
>> b06ed71a6 Dmitry Vyukov 2018-01-29 294
>> BUILD_BUG_ON(sizeof(unsigned long) != 8);
>> b06ed71a6 Dmitry Vyukov 2018-01-29 295 return
>> arch_cmpxchg((u64 *)ptr, (u64)old, (u64)new);
>> b06ed71a6 Dmitry Vyukov 2018-01-29 296 }
>> b06ed71a6 Dmitry Vyukov 2018-01-29 297 BUILD_BUG();
>> b06ed71a6 Dmitry Vyukov 2018-01-29 298 return 0;
>> b06ed71a6 Dmitry Vyukov 2018-01-29 299 }
>> b06ed71a6 Dmitry Vyukov 2018-01-29 300
>>
>> :: The code at line 288 was first introduced by commit
>> :: b06ed71a624ba088a3e3e3ac7d4185f48c7c1660 locking/atomic, asm-generic:
>> Add asm-generic/atomic-instrumented.h
>>
>> :: TO: Dmitry Vyukov
>> :: CC: Ingo Molnar
>
>
> I will take a look tomorrow.
It seems that this is due to this guy:
static __always_inline int trylock_clear_pending(struct qspinlock *lock)
{
struct __qspinlock *l = (void *)lock;
return !READ_ONCE(l->locked) &&
(cmpxchg_acquire(&l->locked_pending, _Q_PENDING_VAL,
_Q_LOCKED_VAL) == _Q_PENDING_VAL);
}
_Q_PENDING_VAL is 0x100. However, locked_pending is 2 bytes. So it
seems that compiler checks all switch cases, this inevitably will lead
to such warnings.
Any suggestion on how to resolve this? Leave as is?
Off the top of my head I can think of the following solution:
switch (size) {
case 1:
return arch_cmpxchg((u8 *)ptr, (u8)(old * (size !=
1)), (u8)(new * (size != 1)));
case 2:
return arch_cmpxchg((u16 *)ptr, (u16)(old * (size !=
2)), (u16)(new * (size != 2)));
But it's too ugly.
FTR, the following was helpful to find invocations with particular size:
#define cmpxchg(ptr, old, new) \
({ \
+ BUILD_BUG_ON(sizeof(*(ptr)) == 1); \
((__typeof__(*(ptr)))cmpxchg_size((ptr), (unsigned long)(old), \
(unsigned long)(new), sizeof(*(ptr; \
})
[PATCH] clk: Add driver for the si544 clock generator chip
This patch adds the driver and devicetree documentation for the
Silicon Labs SI544 clock generator chip. This is an I2C controlled
oscillator capable of generating clock signals ranging from 200kHz
to 1500MHz.
Signed-off-by: Mike Looijmans
---
.../devicetree/bindings/clock/silabs,si544.txt | 25 ++
drivers/clk/Kconfig| 10 +
drivers/clk/Makefile | 1 +
drivers/clk/clk-si544.c| 421 +
4 files changed, 457 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/silabs,si544.txt
create mode 100644 drivers/clk/clk-si544.c
diff --git a/Documentation/devicetree/bindings/clock/silabs,si544.txt
b/Documentation/devicetree/bindings/clock/silabs,si544.txt
new file mode 100644
index 000..eec1787
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/silabs,si544.txt
@@ -0,0 +1,25 @@
+Binding for Silicon Labs 544 programmable I2C clock generator.
+
+Reference
+This binding uses the common clock binding[1]. Details about the device can be
+found in the datasheet[2].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Si544 datasheet
+https://www.silabs.com/documents/public/data-sheets/si544-datasheet.pdf
+
+Required properties:
+ - compatible: One of "silabs,si514a", "silabs,si514b" "silabs,si514c"
according
+ to the speed grade of the chip.
+ - reg: I2C device address.
+ - #clock-cells: From common clock bindings: Shall be 0.
+
+Optional properties:
+ - clock-output-names: From common clock bindings. Recommended to be "si544".
+
+Example:
+ si544: clock-generator@55 {
+ reg = <0x55>;
+ #clock-cells = <0>;
+ compatible = "silabs,si544b";
+ };
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 98ce9fc..5c7dc8e 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -91,6 +91,16 @@ config COMMON_CLK_SI514
This driver supports the Silicon Labs 514 programmable clock
generator.
+config COMMON_CLK_SI544
+ tristate "Clock driver for SiLabs 544 devices"
+ depends on I2C
+ depends on OF
+ select REGMAP_I2C
+ help
+ ---help---
+ This driver supports the Silicon Labs 544 programmable clock
+ generator.
+
config COMMON_CLK_SI570
tristate "Clock driver for SiLabs 570 and compatible devices"
depends on I2C
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 71ec41e..bde614a 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
obj-$(CONFIG_COMMON_CLK_SCPI) += clk-scpi.o
obj-$(CONFIG_COMMON_CLK_SI5351)+= clk-si5351.o
obj-$(CONFIG_COMMON_CLK_SI514) += clk-si514.o
+obj-$(CONFIG_COMMON_CLK_SI544) += clk-si544.o
obj-$(CONFIG_COMMON_CLK_SI570) += clk-si570.o
obj-$(CONFIG_ARCH_STM32) += clk-stm32f4.o
obj-$(CONFIG_ARCH_STM32) += clk-stm32h7.o
diff --git a/drivers/clk/clk-si544.c b/drivers/clk/clk-si544.c
new file mode 100644
index 000..1947e48
--- /dev/null
+++ b/drivers/clk/clk-si544.c
@@ -0,0 +1,421 @@
+/*
+ * Driver for Silicon Labs Si544 Programmable Oscillator
+ *
+ * Copyright (C) 2018 Topic Embedded Products
+ *
+ * Author: Mike Looijmans
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* I2C registers (decimal as in datasheet) */
+#define SI544_REG_CONTROL 7
+#define SI544_REG_OE_STATE 17
+#define SI544_REG_HS_DIV 23
+#define SI544_REG_LS_HS_DIV24
+#define SI544_REG_FBDIV0 26
+#define SI544_REG_FBDIV8 27
+#define SI544_REG_FBDIV16 28
+#define SI544_REG_FBDIV24 29
+#define SI544_REG_FBDIV32 30
+#define SI544_REG_FBDIV40 31
+#define SI544_REG_FCAL_OVR 69
+#define SI544_REG_ADPLL_DELTA_M0 231
+#define SI544_REG_ADPLL_DELTA_M8 232
+#define SI544_REG_ADPLL_DELTA_M16 233
+#define SI544_REG_PAGE_SELECT 255
+
+/* Register values */
+#define SI544_CONTROL_RESETBIT(7)
+#define SI544_CONTROL_MS_ICAL2 BIT(3)
+
+#define SI544_OE_STATE_ODC_OE BIT(0)
+
+/* Max freq depends on speed grade */
+#define SI544_MIN_FREQ 20U
+
+/* Si544 Internal oscilator runs at 55.05 MHz */
+#define FXO 5505U
+
+/* VCO range is 10.8 .. 12.1 GHz, max depends on speed grade */
+#define FVCO_MIN 108ULL
+
+
Re: Atheros 1525/QCA6174 BT issue
On Tue, 13 Mar 2018 09:38:30 +0100, Marcel Holtmann wrote: > > Hi Takashi, > > >> we've got a but report about the broken Atheros BT on the recent > >> kernels: > >> http://bugzilla.opensuse.org/show_bug.cgi?id=1082504 > >> > >> In short, btusb can't load the patch ar3k/AthrBT_0x0200.dfu, and > >> this could be worked around by the patch to move 0cf3:3004 blacklist > >> entry to use BTUSB_QCA_ROM instead of BTUSB_ATH3012. > >> > >> And this looks like a long-standing problem, at least for over two > >> years. Many web pages suggest the same patch, but it's never merged > >> to upstream. > >> > >> So this made me wonder what's going on. I see that the BTUSB_ATH3012 > >> quirk was originally introduced just for this chip id (0cf3:3004). > >> Is it a different variant from the original chip that causes a > >> problem? > > > > not all patches from distro kernel are sent upstream. I have not heard > > of this specific issues, but happy to accept patches to get it fixed. > > OK, basically it's like below. > But, as mentioned, this made me wonder whether it's the right fix. > The BTUSB_ATH3012 quirk was introduced exactly for this chip ID > (0cf3:3004), and now this chip is moved to another quirk... > > If this is the right move, I can re-submit via git-send-email, too. > Just let me know. > >>> > >>> Marcel, could you take a look at this? > >>> If it sucks, let's seek for a better solution. > >> > >> wasn’t the confusion that this is fixed with a recent kernel? I am lost in > >> this thread. I mean if people add Tested-by, then I can take this as well. > >> Otherwise we might need someone from Qualcomm to shed some light into > >> these. > > > > Well, *this* thread is likely different from the recent other > > threads. > > > > Isn't 4.15.7 recent enough? At least, it already contains the > > backport of relevant fixes: > >Revert "Bluetooth: btusb: fix QCA Rome suspend/resume" > >Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a > > "rewritten" version > > > > (And it's not Yoga but MSI GS40 laptop, so DMI doesn't matter.) > > According to Ivan, the reporter of the bug (now Cc'ed), 4.15.7 didn't > > work without the patch, so the problem is still there, as it seems. > > > > In anyway, I'm going to build a kernel with my patch on top of 4.15.9 > > for testing again. Maybe also a patched 4.16-rc5 kernel, too. If > > it's confirmed, will report back with tested-by tag. > > I think there are two patches that are not yet in Linus’ tree and waiting in > Dave’s net tree. We actually removed the Yoga DMI entry again since it was > found that it is not needed. However there is a Dell OptiPlex entry that was > needed. > > https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=0c6e526646c04ce31d4aaa280ed2237dd1cd774c In our case, the target machine is a MSI laptop, so these changes should be irrelevant. Or do you suggest to try the same DMI reset quirk matching with the MSI machine? thanks, Takashi
[PATCH 03/11] RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module
For CALL_PLT, emit the plt entry only when offset is more than 32-bit.
For PCREL_LO12, it uses the location of corresponding HI20 to
get the address of external symbol. It should check the HI20 type
is the PCREL_HI20 or GOT_HI20, because sometime the location will
have two or more relocation types.
For example:
0: 0797auipc a5,0x0
0: R_RISCV_ALIGN*ABS*
0: R_RISCV_GOT_HI20 SYMBOL
4: 0007b783ld a5,0(a5) # 0
4: R_RISCV_PCREL_LO12_I .L0
4: R_RISCV_RELAX*ABS*
Signed-off-by: Zong Li
---
arch/riscv/kernel/module.c | 61 ++
1 file changed, 51 insertions(+), 10 deletions(-)
diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
index e0f05034fc21..242d3a14c210 100644
--- a/arch/riscv/kernel/module.c
+++ b/arch/riscv/kernel/module.c
@@ -92,6 +92,28 @@ static int apply_r_riscv_pcrel_lo12_s_rela(struct module
*me, u32 *location,
return 0;
}
+static int apply_r_riscv_got_hi20_rela(struct module *me, u32 *location,
+ Elf_Addr v)
+{
+ s64 offset = (void *)v - (void *)location;
+ s32 hi20;
+
+ /* Always emit the got entry */
+ if (IS_ENABLED(CONFIG_MODULE_SECTIONS)) {
+ offset = module_emit_got_entry(me, v);
+ offset = (void *)offset - (void *)location;
+ } else {
+ pr_err(
+ "%s: can not generate the GOT entry for symbol = %016llx from
PC = %p\n",
+ me->name, v, location);
+ return -EINVAL;
+ }
+
+ hi20 = (offset + 0x800) & 0xf000;
+ *location = (*location & 0xfff) | hi20;
+ return 0;
+}
+
static int apply_r_riscv_call_plt_rela(struct module *me, u32 *location,
Elf_Addr v)
{
@@ -100,10 +122,16 @@ static int apply_r_riscv_call_plt_rela(struct module *me,
u32 *location,
u32 hi20, lo12;
if (offset != fill_v) {
- pr_err(
- "%s: target %016llx can not be addressed by the 32-bit offset
from PC = %p\n",
- me->name, v, location);
- return -EINVAL;
+ /* Only emit the plt entry if offset over 32-bit range */
+ if (IS_ENABLED(CONFIG_MODULE_SECTIONS)) {
+ offset = module_emit_plt_entry(me, v);
+ offset = (void *)offset - (void *)location;
+ } else {
+ pr_err(
+ "%s: target %016llx can not be addressed by the
32-bit offset from PC = %p\n",
+ me->name, v, location);
+ return -EINVAL;
+ }
}
hi20 = (offset + 0x800) & 0xf000;
@@ -127,6 +155,7 @@ static int (*reloc_handlers_rela[]) (struct module *me, u32
*location,
[R_RISCV_PCREL_HI20]= apply_r_riscv_pcrel_hi20_rela,
[R_RISCV_PCREL_LO12_I] = apply_r_riscv_pcrel_lo12_i_rela,
[R_RISCV_PCREL_LO12_S] = apply_r_riscv_pcrel_lo12_s_rela,
+ [R_RISCV_GOT_HI20] = apply_r_riscv_got_hi20_rela,
[R_RISCV_CALL_PLT] = apply_r_riscv_call_plt_rela,
[R_RISCV_RELAX] = apply_r_riscv_relax_rela,
};
@@ -184,25 +213,37 @@ int apply_relocate_add(Elf_Shdr *sechdrs, const char
*strtab,
u64 hi20_loc =
sechdrs[sechdrs[relsec].sh_info].sh_addr
+ rel[j].r_offset;
- /* Find the corresponding HI20 PC-relative
relocation entry */
- if (hi20_loc == sym->st_value) {
+ u32 hi20_type = ELF_RISCV_R_TYPE(rel[j].r_info);
+
+ /* Find the corresponding HI20 relocation entry
*/
+ if (hi20_loc == sym->st_value
+ && (hi20_type == R_RISCV_PCREL_HI20
+ || hi20_type == R_RISCV_GOT_HI20)) {
+ s32 hi20, lo12;
Elf_Sym *hi20_sym =
(Elf_Sym
*)sechdrs[symindex].sh_addr
+
ELF_RISCV_R_SYM(rel[j].r_info);
u64 hi20_sym_val =
hi20_sym->st_value
+ rel[j].r_addend;
+
/* Calculate lo12 */
- s64 offset = hi20_sym_val - hi20_loc;
- s32 hi20 = (offset + 0x800) &
0xf000;
- s32 lo12 = offset - hi20;
+
[PATCH 06/11] RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq
Signed-off-by: Zong Li
---
arch/riscv/kernel/module.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
index 654fe7dcd38d..e23c051dfc62 100644
--- a/arch/riscv/kernel/module.c
+++ b/arch/riscv/kernel/module.c
@@ -49,6 +49,39 @@ static int apply_r_riscv_jal_rela(struct module *me, u32
*location,
return 0;
}
+static int apply_r_riscv_rcv_branch_rela(struct module *me, u32 *location,
+Elf_Addr v)
+{
+ s64 offset = (void *)v - (void *)location;
+ u16 imm8 = (offset & 0x100) << (12 - 8);
+ u16 imm7_6 = (offset & 0xc0) >> (6 - 5);
+ u16 imm5 = (offset & 0x20) >> (5 - 2);
+ u16 imm4_3 = (offset & 0x18) << (12 - 5);
+ u16 imm2_1 = (offset & 0x6) << (12 - 10);
+
+ *(u16 *)location = (*(u16 *)location & 0xe383) |
+ imm8 | imm7_6 | imm5 | imm4_3 | imm2_1;
+ return 0;
+}
+
+static int apply_r_riscv_rvc_jump_rela(struct module *me, u32 *location,
+ Elf_Addr v)
+{
+ s64 offset = (void *)v - (void *)location;
+ u16 imm11 = (offset & 0x800) << (12 - 11);
+ u16 imm10 = (offset & 0x400) >> (10 - 8);
+ u16 imm9_8 = (offset & 0x300) << (12 - 11);
+ u16 imm7 = (offset & 0x80) >> (7 - 6);
+ u16 imm6 = (offset & 0x40) << (12 - 11);
+ u16 imm5 = (offset & 0x20) >> (5 - 2);
+ u16 imm4 = (offset & 0x10) << (12 - 5);
+ u16 imm3_1 = (offset & 0xe) << (12 - 10);
+
+ *(u16 *)location = (*(u16 *)location & 0xe003) |
+ imm11 | imm10 | imm9_8 | imm7 | imm6 | imm5 | imm4 | imm3_1;
+ return 0;
+}
+
static int apply_r_riscv_pcrel_hi20_rela(struct module *me, u32 *location,
Elf_Addr v)
{
@@ -212,6 +245,8 @@ static int (*reloc_handlers_rela[]) (struct module *me, u32
*location,
[R_RISCV_64]= apply_r_riscv_64_rela,
[R_RISCV_BRANCH]= apply_r_riscv_branch_rela,
[R_RISCV_JAL] = apply_r_riscv_jal_rela,
+ [R_RISCV_RVC_BRANCH]= apply_r_riscv_rcv_branch_rela,
+ [R_RISCV_RVC_JUMP] = apply_r_riscv_rvc_jump_rela,
[R_RISCV_PCREL_HI20]= apply_r_riscv_pcrel_hi20_rela,
[R_RISCV_PCREL_LO12_I] = apply_r_riscv_pcrel_lo12_i_rela,
[R_RISCV_PCREL_LO12_S] = apply_r_riscv_pcrel_lo12_s_rela,
--
2.16.1
[PATCH 02/11] RISC-V: Add section of GOT.PLT for kernel module
Separate the function symbol address from .plt to .got.plt section.
The original plt entry has trampoline code with symbol address,
there is a 32-bit padding bwtween jar instruction and symbol address.
Extract the symbol address to .got.plt to reduce the module size.
Signed-off-by: Zong Li
---
arch/riscv/include/asm/module.h | 40 +++--
arch/riscv/kernel/module-sections.c | 21 +--
arch/riscv/kernel/module.lds| 1 +
3 files changed, 45 insertions(+), 17 deletions(-)
diff --git a/arch/riscv/include/asm/module.h b/arch/riscv/include/asm/module.h
index bcc48d113deb..016e6a618e83 100644
--- a/arch/riscv/include/asm/module.h
+++ b/arch/riscv/include/asm/module.h
@@ -18,6 +18,7 @@ struct mod_section {
struct mod_arch_specific {
struct mod_section got;
struct mod_section plt;
+ struct mod_section got_plt;
};
#endif
@@ -49,13 +50,10 @@ struct plt_entry {
/*
* Trampoline code to real target address. The return address
* should be the original (pc+4) before entring plt entry.
-* For 8 byte alignment of symbol_addr,
-* don't pack structure to remove the padding.
*/
u32 insn_auipc; /* auipc t0, 0x0 */
u32 insn_ld;/* ldt1, 0x10(t0) */
u32 insn_jr;/* jrt1*/
- u64 symbol_addr;/* the real jump target address*/
};
#define OPC_AUIPC 0x0017
@@ -63,9 +61,8 @@ struct plt_entry {
#define OPC_JALR 0x0067
#define REG_T0 0x5
#define REG_T1 0x6
-#define IMM_OFFSET 0x10
-static inline struct plt_entry emit_plt_entry(u64 val)
+static inline struct plt_entry emit_plt_entry(u64 val, u64 plt, u64 got_plt)
{
/*
* U-Type encoding:
@@ -79,24 +76,37 @@ static inline struct plt_entry emit_plt_entry(u64 val)
* ++++--+--+
*
*/
+ u64 offset = got_plt - plt;
+ u32 hi20 = (offset + 0x800) & 0xf000;
+ u32 lo12 = (offset - hi20);
return (struct plt_entry) {
- OPC_AUIPC | (REG_T0 << 7),
- OPC_LD | (IMM_OFFSET << 20) | (REG_T0 << 15) | (REG_T1 << 7),
- OPC_JALR | (REG_T1 << 15),
- val
+ OPC_AUIPC | (REG_T0 << 7) | hi20,
+ OPC_LD | (lo12 << 20) | (REG_T0 << 15) | (REG_T1 << 7),
+ OPC_JALR | (REG_T1 << 15)
};
}
-static inline struct plt_entry *get_plt_entry(u64 val,
- const struct mod_section *sec)
+static inline int get_got_plt_idx(u64 val, const struct mod_section *sec)
{
- struct plt_entry *plt = (struct plt_entry *)sec->shdr->sh_addr;
+ struct got_entry *got_plt = (struct got_entry *)sec->shdr->sh_addr;
int i;
for (i = 0; i < sec->num_entries; i++) {
- if (plt[i].symbol_addr == val)
- return &plt[i];
+ if (got_plt[i].symbol_addr == val)
+ return i;
}
- return NULL;
+ return -1;
+}
+
+static inline struct plt_entry *get_plt_entry(u64 val,
+ const struct mod_section *sec_plt,
+ const struct mod_section *sec_got_plt)
+{
+ struct plt_entry *plt = (struct plt_entry *)sec_plt->shdr->sh_addr;
+ int got_plt_idx = get_got_plt_idx(val, sec_got_plt);
+ if (got_plt_idx >= 0)
+ return plt + got_plt_idx;
+ else
+ return NULL;
}
#endif /* _ASM_RISCV_MODULE_H */
diff --git a/arch/riscv/kernel/module-sections.c
b/arch/riscv/kernel/module-sections.c
index 94ba1551eac3..bbbd26e19bfd 100644
--- a/arch/riscv/kernel/module-sections.c
+++ b/arch/riscv/kernel/module-sections.c
@@ -30,18 +30,23 @@ u64 module_emit_got_entry(struct module *mod, u64 val)
u64 module_emit_plt_entry(struct module *mod, u64 val)
{
+ struct mod_section *got_plt_sec = &mod->arch.got_plt;
+ struct got_entry *got_plt;
struct mod_section *plt_sec = &mod->arch.plt;
- struct plt_entry *plt = get_plt_entry(val, plt_sec);
+ struct plt_entry *plt = get_plt_entry(val, plt_sec, got_plt_sec);
int i = plt_sec->num_entries;
if (plt)
return (u64)plt;
/* There is no duplicate entry, create a new one */
+ got_plt = (struct got_entry *)got_plt_sec->shdr->sh_addr;
+ got_plt[i] = emit_got_entry(val);
plt = (struct plt_entry *)plt_sec->shdr->sh_addr;
- plt[i] = emit_plt_entry(val);
+ plt[i] = emit_plt_entry(val, (u64)&plt[i], (u64)&got_plt[i]);
plt_sec->num_entries++;
+ got_plt_sec->num_entries++;
BUG_ON(plt_sec->num_entries > plt_sec->max_entries);
return (u64)&plt[i];
@@ -94,6 +99,8 @@ int module_frob_arch_sections(Elf_Ehdr *ehdr, Elf_Shdr
*sec
[PATCH 04/11] RISC-V: Support CALL relocation type in kernel module
Signed-off-by: Zong Li
---
arch/riscv/kernel/module.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
index 242d3a14c210..7e85e5840b4d 100644
--- a/arch/riscv/kernel/module.c
+++ b/arch/riscv/kernel/module.c
@@ -141,6 +141,27 @@ static int apply_r_riscv_call_plt_rela(struct module *me,
u32 *location,
return 0;
}
+static int apply_r_riscv_call_rela(struct module *me, u32 *location,
+ Elf_Addr v)
+{
+ s64 offset = (void *)v - (void *)location;
+ s32 fill_v = offset;
+ u32 hi20, lo12;
+
+ if (offset != fill_v) {
+ pr_err(
+ "%s: target %016llx can not be addressed by the 32-bit offset
from PC = %p\n",
+ me->name, v, location);
+ return -EINVAL;
+ }
+
+ hi20 = (offset + 0x800) & 0xf000;
+ lo12 = (offset - hi20) & 0xfff;
+ *location = (*location & 0xfff) | hi20;
+ *(location + 1) = (*(location + 1) & 0xf) | (lo12 << 20);
+ return 0;
+}
+
static int apply_r_riscv_relax_rela(struct module *me, u32 *location,
Elf_Addr v)
{
@@ -157,6 +178,7 @@ static int (*reloc_handlers_rela[]) (struct module *me, u32
*location,
[R_RISCV_PCREL_LO12_S] = apply_r_riscv_pcrel_lo12_s_rela,
[R_RISCV_GOT_HI20] = apply_r_riscv_got_hi20_rela,
[R_RISCV_CALL_PLT] = apply_r_riscv_call_plt_rela,
+ [R_RISCV_CALL] = apply_r_riscv_call_rela,
[R_RISCV_RELAX] = apply_r_riscv_relax_rela,
};
--
2.16.1
[PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit
These patches resolve the some issues of loadable module. - symbol out of ranges - unknown relocation types The reference of external variable and function symbols cannot exceed 32-bit offset ranges in kernel module. The module only can work on the 32-bit OS or the 64-bit OS with sv32 virtual addressing. These patches will generate the .got, .got.plt and .plt sections during loading module, let it can refer to the symbol which locate more than 32-bit offset. These sections depend on the relocation types: - R_RISCV_GOT_HI20 - R_RISCV_CALL_PLT These patches also support more relocation types - R_RISCV_CALL - R_RISCV_HI20 - R_RISCV_LO12_I - R_RISCV_LO12_S - R_RISCV_RVC_BRANCH - R_RISCV_RVC_JUMP - R_RISCV_ALIGN - R_RISCV_ADD32 - R_RISCV_SUB32 Zong Li (11): RISC-V: Add sections of PLT and GOT for kernel module RISC-V: Add section of GOT.PLT for kernel module RISC-V: Support GOT_HI20/CALL_PLT relocation type in kernel module RISC-V: Support CALL relocation type in kernel module RISC-V: Support HI20/LO12_I/LO12_S relocation type in kernel module RISC-V: Support RVC_BRANCH/JUMP relocation type in kernel modulewq RISC-V: Support ALIGN relocation type in kernel module RISC-V: Support ADD32 relocation type in kernel module RISC-V: Support SUB32 relocation type in kernel module RISC-V: Enable module support in defconfig RISC-V: Add definition of relocation types arch/riscv/Kconfig | 5 ++ arch/riscv/Makefile | 3 + arch/riscv/configs/defconfig| 2 + arch/riscv/include/asm/module.h | 112 +++ arch/riscv/include/uapi/asm/elf.h | 24 + arch/riscv/kernel/Makefile | 1 + arch/riscv/kernel/module-sections.c | 156 arch/riscv/kernel/module.c | 175 ++-- arch/riscv/kernel/module.lds| 8 ++ 9 files changed, 480 insertions(+), 6 deletions(-) create mode 100644 arch/riscv/include/asm/module.h create mode 100644 arch/riscv/kernel/module-sections.c create mode 100644 arch/riscv/kernel/module.lds -- 2.16.1
RE: linux-next: build failure after merge of the sound-asoc tree
On 13 March 2018 06:09, Stephen Rothwell wrote:
> Hi all,
>
> After merging the sound-asoc tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> sound/soc/codecs/da7219.o: In function `.da7219_remove':
> da7219.c:(.text+0xcbc): undefined reference to `.clkdev_drop'
>
> Caused by commit
>
> fc8f7ea2d6c0 ("ASoC: da7219: Add common clock usage for providing DAI clks")
>
> CONFIG_CLKDEV_LOOKUP is not set for this build.
>
> I have reverted that commit for today.
My bad. Apologies for this. :(
Mark, I'll send a follow up patch to fix this ASAP.
Re: hwmon/sch5627: Use common error handling code in sch5627_probe()
Hi, On 13-03-18 09:25, SF Markus Elfring wrote: Adjust jump targets so that a bit of exception handling can be better reused at the end of this function. … goto-s going to a label calling another goto is completely unreadable. I got an other software development view. I really do not see any reason for the proposed changes, I suggest to look once more. they may remove a small amount of code duplication, This was my software design goal in this case. The diffstat of your patch is: 1 file changed, 29 insertions(+), 31 deletions(-) So you are asking people to review 60 changed lines to save 2, that alone should be the point where you stop yourself from *even* sending this patch. Review time is not an endless free resource and this patch is wasting it for very little gain. I see in the kernel git log that you've e.g. also send a lot of patches removing pr_err / dev_err calls from memory allocation failures. Those are good patches to have, they are easy to review and significantly shrink the compiled kernel size because of all the text strings you are removing. This patch however will likely result in a binary which is hardly smaller at all (if at all, the compiler does common code elimination itself) while it is a complex patch to review so comes with a large review cost. Next time before you send a patch please carefully think if the saving is worth the combination of reviewers time + the risk of regressions (and keep in mind that both the reviewers time and the risk of regressions cost increase for more complex changes). but at a hugh cost wrt readability. I proposed a different trade-off here. not this again. Cleanup patches are appreciated, but there always is a cost to making changes to perfectly working good code. You've had this same discussion with Jonathan Cameron, the IIO subsys maintainer at the end of 2017, it would be nice if you were to actually listen to what people are saying about this. As for this specific discussion, there are certain "design-patterns" in the kernel, goto style error handling is one of them, the pattern there ALWAYS is: error_cleanup4: cleanup4(); /* fall through to next cleanup */ error_cleanup3: cleanup3(); /* fall through to next cleanup */ error_cleanup2: cleanup2(); /* fall through to next cleanup */ error_cleanup1: cleanup1(); /* fall through to next cleanup */ return error; Notice the fall-thoughs those are ALWAYS there, never, ever is there a goto after a cleanup label. The idea is that resources are allocated in the order of resource1 (cleaned by cleanup1()) then resource2, etc. and the goto + fallthrough will cleanup all resources which have been allocated at the time of the goto in *reverse* order of allocation. The whole point of this design- pattern to be able to a) do partial cleanup if we fail halfway through; b) do it in reverse order. Your patches black goto magic completely messes this up and clearly falls under the CS101 rule: never use goto. Your proposed changes break how every experienced kernel developer is expecting the code to be / work, causing your proposed changes to have a HUGE cost wrt maintainability and readability, which means the trade-off you're suggesting is anything but worth-while. TL;DR: still NACK. Regards, Hans
Re: [PATCH v2 04/10] video: add support of panel OTM8009A
Hi Yannick On 03/02/2018 04:44 PM, yannick fertre wrote: > Support for Orise Tech otm8009a 480p dsi 2dl video mode panel. > > Signed-off-by: yannick fertre > --- > drivers/video/Kconfig | 8 + > drivers/video/Makefile | 1 + > drivers/video/orisetech_otm8009a.c | 329 > + > 3 files changed, 338 insertions(+) > create mode 100644 drivers/video/orisetech_otm8009a.c > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig > index 1981298..b5fc535 100644 > --- a/drivers/video/Kconfig > +++ b/drivers/video/Kconfig > @@ -320,6 +320,14 @@ config VIDEO_LCD_ANX9804 > from a parallel LCD interface and translate it on the fy into a DP > interface for driving eDP TFT displays. It uses I2C for configuration. > > +config VIDEO_LCD_ORISETECH_OTM8009A > + bool "OTM8009A DSI LCD panel support" > + depends on DM_VIDEO > + select VIDEO_MIPI_DSI > + default n > + ---help--- > + Support for Orise Tech otm8009a 480p dsi 2dl video mode panel. > + > config VIDEO_LCD_SSD2828 > bool "SSD2828 bridge chip" > default n > diff --git a/drivers/video/Makefile b/drivers/video/Makefile > index 6f42cca..65002af 100644 > --- a/drivers/video/Makefile > +++ b/drivers/video/Makefile > @@ -37,6 +37,7 @@ obj-$(CONFIG_VIDEO_COREBOOT) += coreboot.o > obj-$(CONFIG_VIDEO_DA8XX) += da8xx-fb.o videomodes.o > obj-$(CONFIG_VIDEO_LCD_ANX9804) += anx9804.o > obj-$(CONFIG_VIDEO_LCD_HITACHI_TX18D42VM) += hitachi_tx18d42vm_lcd.o > +obj-$(CONFIG_VIDEO_LCD_ORISETECH_OTM8009A) += orisetech_otm8009a.o > obj-$(CONFIG_VIDEO_LCD_SSD2828) += ssd2828.o > obj-$(CONFIG_VIDEO_MB862xx) += mb862xx.o videomodes.o > obj-$(CONFIG_VIDEO_MX3) += mx3fb.o videomodes.o > diff --git a/drivers/video/orisetech_otm8009a.c > b/drivers/video/orisetech_otm8009a.c > new file mode 100644 > index 000..79f2da8 > --- /dev/null > +++ b/drivers/video/orisetech_otm8009a.c > @@ -0,0 +1,329 @@ > +/* > + * Copyright (C) 2018 STMicroelectronics - All Rights Reserved > + * Author(s): Yannick Fertre for STMicroelectronics. > + * Philippe Cornu for STMicroelectronics. > + * > + * This otm8009a panel driver is based on the panel driver from > + * drivers/gpu/drm/panel/panel-orisetech-otm8009a.c (kernel linux) > + * > + * SPDX-License-Identifier: GPL-2.0 > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +DECLARE_GLOBAL_DATA_PTR; > + > +#define DRV_NAME "orisetech_otm8009a" > + > +#define OTM8009A_BACKLIGHT_DEFAULT 240 > +#define OTM8009A_BACKLIGHT_MAX 255 > + > +/* Manufacturer Command Set */ > +#define MCS_ADRSFT 0x /* Address Shift Function */ > +#define MCS_PANSET 0xB3A6 /* Panel Type Setting */ > +#define MCS_SD_CTRL 0xC0A2 /* Source Driver Timing Setting */ > +#define MCS_P_DRV_M 0xC0B4 /* Panel Driving Mode */ > +#define MCS_OSC_ADJ 0xC181 /* Oscillator Adjustment for Idle/Normal mode */ > +#define MCS_RGB_VID_SET 0xC1A1 /* RGB Video Mode Setting */ > +#define MCS_SD_PCH_CTRL 0xC480 /* Source Driver Precharge Control */ > +#define MCS_NO_DOC1 0xC48A /* Command not documented */ > +#define MCS_PWR_CTRL10xC580 /* Power Control Setting 1 */ > +#define MCS_PWR_CTRL20xC590 /* Power Control Setting 2 for Normal > Mode */ > +#define MCS_PWR_CTRL40xC5B0 /* Power Control Setting 4 for DC > Voltage */ > +#define MCS_PANCTRLSET1 0xCB80 /* Panel Control Setting 1 */ > +#define MCS_PANCTRLSET2 0xCB90 /* Panel Control Setting 2 */ > +#define MCS_PANCTRLSET3 0xCBA0 /* Panel Control Setting 3 */ > +#define MCS_PANCTRLSET4 0xCBB0 /* Panel Control Setting 4 */ > +#define MCS_PANCTRLSET5 0xCBC0 /* Panel Control Setting 5 */ > +#define MCS_PANCTRLSET6 0xCBD0 /* Panel Control Setting 6 */ > +#define MCS_PANCTRLSET7 0xCBE0 /* Panel Control Setting 7 */ > +#define MCS_PANCTRLSET8 0xCBF0 /* Panel Control Setting 8 */ > +#define MCS_PANU2D1 0xCC80 /* Panel U2D Setting 1 */ > +#define MCS_PANU2D2 0xCC90 /* Panel U2D Setting 2 */ > +#define MCS_PANU2D3 0xCCA0 /* Panel U2D Setting 3 */ > +#define MCS_PAND2U1 0xCCB0 /* Panel D2U Setting 1 */ > +#define MCS_PAND2U2 0xCCC0 /* Panel D2U Setting 2 */ > +#define MCS_PAND2U3 0xCCD0 /* Panel D2U Setting 3 */ > +#define MCS_GOAVST 0xCE80 /* GOA VST Setting */ > +#define MCS_GOACLKA1 0xCEA0 /* GOA CLKA1 Setting */ > +#define MCS_GOACLKA3 0xCEB0 /* GOA CLKA3 Setting */ > +#define MCS_GOAECLK 0xCFC0 /* GOA ECLK Setting */ > +#define MCS_NO_DOC2 0xCFD0 /* Command not documented */ > +#define MCS_GVDDSET 0xD800 /* GVDD/NGVDD */ > +#define MCS_VCOMDC 0xD900 /* VCOM Voltage Setting */ > +#define MCS_GMCT2_2P 0xE100 /* Gamma Correction 2.2+ Setting */ > +#define MCS_GMCT2_2N 0xE200 /* Gamma Correction 2.2- Setting */ > +#define MCS_NO_DOC3 0xF5B6 /* Command not documented */ > +#define MCS_CMD2_ENA10xFF00 /* Enable Acces
[PATCH] clk: clk-gpio: Allow GPIO to sleep in set/get_parent
When changing or retrieving clock parents, the caller is in a sleepable
state (like prepare) so the GPIO operation need not be atomic. Replace
gpiod_{g|s}et_value with gpiod_{g|s}et_value_cansleep in the {g|s}et_parent
calls for the GPIO based clock mux.
This fixes a "slowpath" warning when the GPIO controller is an I2C expander
or something similar.
Signed-off-by: Mike Looijmans
---
drivers/clk/clk-gpio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-gpio.c b/drivers/clk/clk-gpio.c
index 151513c..40af4fb 100644
--- a/drivers/clk/clk-gpio.c
+++ b/drivers/clk/clk-gpio.c
@@ -73,14 +73,14 @@ static u8 clk_gpio_mux_get_parent(struct clk_hw *hw)
{
struct clk_gpio *clk = to_clk_gpio(hw);
- return gpiod_get_value(clk->gpiod);
+ return gpiod_get_value_cansleep(clk->gpiod);
}
static int clk_gpio_mux_set_parent(struct clk_hw *hw, u8 index)
{
struct clk_gpio *clk = to_clk_gpio(hw);
- gpiod_set_value(clk->gpiod, index);
+ gpiod_set_value_cansleep(clk->gpiod, index);
return 0;
}
--
1.9.1
Re: [pci PATCH v5 3/4] ena: Migrate over to unmanaged SR-IOV support
On Tue, Mar 13, 2018 at 08:45:19AM +, David Woodhouse wrote: > > > On Tue, 2018-03-13 at 09:16 +0100, Christoph Hellwig wrote: > > On Tue, Mar 13, 2018 at 08:12:52AM +, David Woodhouse wrote: > > > > > > I'd also *really* like to see a way to enable this for PFs which don't > > > have (and don't need) a driver. We seem to have lost that along the > > > way. > > We've been forth and back on that. I agree that not having any driver > > just seems dangerous. If your PF really does nothing we should just > > have a trivial pf_stub driver that does nothing but wiring up > > pci_sriov_configure_simple. We can then add PCI IDs to it either > > statically, or using the dynamic ids mechanism. > > Or just add it to the existing pci-stub. What's the point in having a > new driver? Because binding to pci-stub means that you'd now enable the simple SR-IOV for any device bound to PCI stub. Which often might be the wrong thing.
Re: [PATCH V2] ZBOOT: fix stack protector in compressed boot phase
Hi, Yoshinori, Rich and SuperH developers,
I'm not familiar with SuperH assembly, but SuperH has the same bug
obviously. Could you please fix that?
Huacai
On Mon, Mar 12, 2018 at 10:04 AM, Huacai Chen wrote:
> Call __stack_chk_guard_setup() in decompress_kernel() is too late that
> stack checking always fails for decompress_kernel() itself. So remove
> __stack_chk_guard_setup() and initialize __stack_chk_guard before we
> call decompress_kernel().
>
> Original code comes from ARM but also used for MIPS and SH, so fix them
> together. If without this fix, compressed booting of these archs will
> fail because stack checking is enabled by default (>=4.16).
>
> V2: Fix build on ARM.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Huacai Chen
> ---
> arch/arm/boot/compressed/head.S| 4
> arch/arm/boot/compressed/misc.c| 7 ---
> arch/mips/boot/compressed/decompress.c | 7 ---
> arch/mips/boot/compressed/head.S | 4
> arch/sh/boot/compressed/head_32.S | 4
> arch/sh/boot/compressed/head_64.S | 4
> arch/sh/boot/compressed/misc.c | 7 ---
> 7 files changed, 16 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 45c8823..bae1fc6 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -547,6 +547,10 @@ not_relocated: mov r0, #0
> bic r4, r4, #1
> blnecache_on
>
> + ldr r0, =__stack_chk_guard
> + ldr r1, =0x000a0dff
> + str r1, [r0]
> +
> /*
> * The C runtime environment should now be setup sufficiently.
> * Set up some pointers, and start decompressing.
> diff --git a/arch/arm/boot/compressed/misc.c b/arch/arm/boot/compressed/misc.c
> index 16a8a80..e518ef5 100644
> --- a/arch/arm/boot/compressed/misc.c
> +++ b/arch/arm/boot/compressed/misc.c
> @@ -130,11 +130,6 @@ asmlinkage void __div0(void)
>
> unsigned long __stack_chk_guard;
>
> -void __stack_chk_guard_setup(void)
> -{
> - __stack_chk_guard = 0x000a0dff;
> -}
> -
> void __stack_chk_fail(void)
> {
> error("stack-protector: Kernel stack is corrupted\n");
> @@ -150,8 +145,6 @@ decompress_kernel(unsigned long output_start, unsigned
> long free_mem_ptr_p,
> {
> int ret;
>
> - __stack_chk_guard_setup();
> -
> output_data = (unsigned char *)output_start;
> free_mem_ptr= free_mem_ptr_p;
> free_mem_end_ptr= free_mem_ptr_end_p;
> diff --git a/arch/mips/boot/compressed/decompress.c
> b/arch/mips/boot/compressed/decompress.c
> index fdf99e9..5ba431c 100644
> --- a/arch/mips/boot/compressed/decompress.c
> +++ b/arch/mips/boot/compressed/decompress.c
> @@ -78,11 +78,6 @@ void error(char *x)
>
> unsigned long __stack_chk_guard;
>
> -void __stack_chk_guard_setup(void)
> -{
> - __stack_chk_guard = 0x000a0dff;
> -}
> -
> void __stack_chk_fail(void)
> {
> error("stack-protector: Kernel stack is corrupted\n");
> @@ -92,8 +87,6 @@ void decompress_kernel(unsigned long boot_heap_start)
> {
> unsigned long zimage_start, zimage_size;
>
> - __stack_chk_guard_setup();
> -
> zimage_start = (unsigned long)(&__image_begin);
> zimage_size = (unsigned long)(&__image_end) -
> (unsigned long)(&__image_begin);
> diff --git a/arch/mips/boot/compressed/head.S
> b/arch/mips/boot/compressed/head.S
> index 409cb48..00d0ee0 100644
> --- a/arch/mips/boot/compressed/head.S
> +++ b/arch/mips/boot/compressed/head.S
> @@ -32,6 +32,10 @@ start:
> bne a2, a0, 1b
> addiu a0, a0, 4
>
> + PTR_LA a0, __stack_chk_guard
> + PTR_LI a1, 0x000a0dff
> + sw a1, 0(a0)
> +
> PTR_LA a0, (.heap) /* heap address */
> PTR_LA sp, (.stack + 8192) /* stack address */
>
> diff --git a/arch/sh/boot/compressed/head_32.S
> b/arch/sh/boot/compressed/head_32.S
> index 7bb1681..a3fdb05 100644
> --- a/arch/sh/boot/compressed/head_32.S
> +++ b/arch/sh/boot/compressed/head_32.S
> @@ -76,6 +76,10 @@ l1:
> mov.l init_stack_addr, r0
> mov.l @r0, r15
>
> + mov.l __stack_chk_guard, r0
> + mov #0x000a0dff, r1
> + mov.l r1, @r0
> +
> /* Decompress the kernel */
> mov.l decompress_kernel_addr, r0
> jsr @r0
> diff --git a/arch/sh/boot/compressed/head_64.S
> b/arch/sh/boot/compressed/head_64.S
> index 9993113..8b4d540 100644
> --- a/arch/sh/boot/compressed/head_64.S
> +++ b/arch/sh/boot/compressed/head_64.S
> @@ -132,6 +132,10 @@ startup:
> addir22, 4, r22
> bne r22, r23, tr1
>
> + movidatalabel __stack_chk_guard, r0
> + movi0x000a0dff, r1
> + st.lr0, 0, r1
> +
> /*
> * Decompress the kernel.
> */
> diff --git a/arch/sh/boot/compressed/misc.c b/arch/sh/boot/compressed/misc.c
> index 6
[PATCH v9 3/5] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device
From: Sricharan R
The smmu device probe/remove and add/remove master device callbacks
gets called when the smmu is not linked to its master, that is without
the context of the master device. So calling runtime apis in those places
separately.
Signed-off-by: Sricharan R
[vivek: Cleanup pm runtime calls]
Signed-off-by: Vivek Gautam
Reviewed-by: Tomasz Figa
---
drivers/iommu/arm-smmu.c | 95
1 file changed, 87 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index d5873d545024..56a04ae80bf3 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -268,6 +268,20 @@ static struct arm_smmu_option_prop arm_smmu_options[] = {
{ 0, NULL},
};
+static inline int arm_smmu_rpm_get(struct arm_smmu_device *smmu)
+{
+ if (pm_runtime_enabled(smmu->dev))
+ return pm_runtime_get_sync(smmu->dev);
+
+ return 0;
+}
+
+static inline void arm_smmu_rpm_put(struct arm_smmu_device *smmu)
+{
+ if (pm_runtime_enabled(smmu->dev))
+ pm_runtime_put(smmu->dev);
+}
+
static struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom)
{
return container_of(dom, struct arm_smmu_domain, domain);
@@ -913,11 +927,15 @@ static void arm_smmu_destroy_domain_context(struct
iommu_domain *domain)
struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
struct arm_smmu_device *smmu = smmu_domain->smmu;
struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
- int irq;
+ int ret, irq;
if (!smmu || domain->type == IOMMU_DOMAIN_IDENTITY)
return;
+ ret = arm_smmu_rpm_get(smmu);
+ if (ret < 0)
+ return;
+
/*
* Disable the context bank and free the page tables before freeing
* it.
@@ -932,6 +950,8 @@ static void arm_smmu_destroy_domain_context(struct
iommu_domain *domain)
free_io_pgtable_ops(smmu_domain->pgtbl_ops);
__arm_smmu_free_bitmap(smmu->context_map, cfg->cbndx);
+
+ arm_smmu_rpm_put(smmu);
}
static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
@@ -1213,10 +1233,15 @@ static int arm_smmu_attach_dev(struct iommu_domain
*domain, struct device *dev)
return -ENODEV;
smmu = fwspec_smmu(fwspec);
+
+ ret = arm_smmu_rpm_get(smmu);
+ if (ret < 0)
+ return ret;
+
/* Ensure that the domain is finalised */
ret = arm_smmu_init_domain_context(domain, smmu);
if (ret < 0)
- return ret;
+ goto rpm_put;
/*
* Sanity check the domain. We don't support domains across
@@ -1230,29 +1255,47 @@ static int arm_smmu_attach_dev(struct iommu_domain
*domain, struct device *dev)
}
/* Looks ok, so add the device to the domain */
- return arm_smmu_domain_add_master(smmu_domain, fwspec);
+ ret = arm_smmu_domain_add_master(smmu_domain, fwspec);
+
+rpm_put:
+ arm_smmu_rpm_put(smmu);
+ return ret;
}
static int arm_smmu_map(struct iommu_domain *domain, unsigned long iova,
phys_addr_t paddr, size_t size, int prot)
{
struct io_pgtable_ops *ops = to_smmu_domain(domain)->pgtbl_ops;
+ struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+ struct arm_smmu_device *smmu = smmu_domain->smmu;
+ int ret;
if (!ops)
return -ENODEV;
- return ops->map(ops, iova, paddr, size, prot);
+ arm_smmu_rpm_get(smmu);
+ ret = ops->map(ops, iova, paddr, size, prot);
+ arm_smmu_rpm_put(smmu);
+
+ return ret;
}
static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned long iova,
size_t size)
{
struct io_pgtable_ops *ops = to_smmu_domain(domain)->pgtbl_ops;
+ struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+ struct arm_smmu_device *smmu = smmu_domain->smmu;
+ size_t ret;
if (!ops)
return 0;
- return ops->unmap(ops, iova, size);
+ arm_smmu_rpm_get(smmu);
+ ret = ops->unmap(ops, iova, size);
+ arm_smmu_rpm_put(smmu);
+
+ return ret;
}
static void arm_smmu_iotlb_sync(struct iommu_domain *domain)
@@ -1407,14 +1450,22 @@ static int arm_smmu_add_device(struct device *dev)
while (i--)
cfg->smendx[i] = INVALID_SMENDX;
+ ret = arm_smmu_rpm_get(smmu);
+ if (ret < 0)
+ goto out_cfg_free;
+
ret = arm_smmu_master_alloc_smes(dev);
if (ret)
- goto out_cfg_free;
+ goto out_rpm_put;
iommu_device_link(&smmu->iommu, dev);
+ arm_smmu_rpm_put(smmu);
+
return 0;
+out_rpm_put:
+ arm_smmu_rpm_put(smmu);
out_cfg_free:
kfree(cfg);
out_free:
@@ -1427,7 +1478,7 @@ static void arm_smmu_remove_device(struct device *dev)
struct iommu_fwspec
[PATCH v9 0/5] iommu/arm-smmu: Add runtime pm/sleep support
This series provides the support for turning on the arm-smmu's
clocks/power domains using runtime pm. This is done using the
recently introduced device links patches, which lets the smmu's
runtime to follow the master's runtime pm, so the smmu remains
powered only when the masters use it.
As not all implementations support clock/power gating, we are checking
for a valid 'smmu->dev's pm_domain' to conditionally enable the runtime
power management for such smmu implementations that can support it.
This series also adds support for Qcom's arm-smmu-v2 variant that
has different clocks and power requirements.
Took some reference from the exynos runtime patches [1].
With conditional runtime pm now, we avoid touching dev->power.lock
in fastpaths for smmu implementations that don't need to do anything
useful with pm_runtime.
This lets us to use the much-argued pm_runtime_get_sync/put_sync()
calls in map/unmap callbacks so that the clients do not have to
worry about handling any of the arm-smmu's power.
Previous version of this patch series is @ [5].
[v9]
* Removed 'rpm_supported' flag, instead checking on pm_domain
to enable runtime pm.
* Creating device link only when the runtime pm is enabled, as we
don't need a device link besides managing the power dependency
between supplier and consumer devices.
* Introducing a patch to add device_link_find() API that finds
and existing link between supplier and consumer devices.
Also, made necessary change to device_link_add() to use this API.
* arm_smmu_remove_device() now uses this device_link_find() to find
the device link between smmu device and the master device, and then
delete this link.
* Dropped the destroy_domain_context() fix [8] as it was rather,
introducing catastrophically bad problem by destroying
'good dev's domain context.
* Added 'Reviwed-by' tag for Tomasz's review.
[v8]
* Major change -
- Added a flag 'rpm_supported' which each platform that supports
runtime pm, can enable, and we enable runtime_pm over arm-smmu
only when this flag is set.
- Adding the conditional pm_runtime_get/put() calls to .map, .unmap
and .attach_dev ops.
- Dropped the patch [6] that exported pm_runtim_get/put_suupliers(),
and also dropped the user driver patch [7] for these APIs.
* Clock code further cleanup
- doing only clk_bulk_enable() and clk_bulk_disable() in runtime pm
callbacks. We shouldn't be taking a slow path (clk_prepare/unprepare())
from these runtime pm callbacks. Thereby, moved clk_bulk_prepare() to
arm_smmu_device_probe(), and clk_bulk_unprepare() to
arm_smmu_device_remove().
- clk data filling to a common method arm_smmu_fill_clk_data() that
fills the clock ids and number of clocks.
* Addressed other nits and comments
- device_link_add() error path fixed.
- Fix for checking negative error value from pm_runtime_get_sync().
- Documentation redo.
* Added another patch fixing the error path in arm_smmu_attach_dev()
to destroy allocated domain context.
[v7]
* Addressed review comments given by Robin Murphy -
- Added device_link_del() in .remove_device path.
- Error path cleanup in arm_smmu_add_device().
- Added pm_runtime_get/put_sync() in .remove path, and replaced
pm_runtime_force_suspend() with pm_runtime_disable().
- clk_names cleanup in arm_smmu_init_clks()
* Added 'Reviewed-by' given by Rob H.
[V6]
* Added Ack given by Rafael to first patch in the series.
* Addressed Rob Herring's comment for adding soc specific compatible
string as well besides 'qcom,smmu-v2'.
[V5]
* Dropped runtime pm calls from "arm_smmu_unmap" op as discussed over
the list [3] for the last patch series.
* Added a patch to export pm_runtime_get/put_suppliers() APIs to the
series as agreed with Rafael [4].
* Added the related patch for msm drm iommu layer to use
pm_runtime_get/put_suppliers() APIs in msm_mmu_funcs.
* Dropped arm-mmu500 clock patch since that would break existing
platforms.
* Changed compatible 'qcom,msm8996-smmu-v2' to 'qcom,smmu-v2' to reflect
the IP version rather than the platform on which it is used.
The same IP is used across multiple platforms including msm8996,
and sdm845 etc.
* Using clock bulk APIs to handle the clocks available to the IP as
suggested by Stephen Boyd.
* The first patch in v4 version of the patch-series:
("iommu/arm-smmu: Fix the error path in arm_smmu_add_device") has
already made it to mainline.
[V4]
* Reworked the clock handling part. We now take clock names as data
in the driver for supported compatible versions, and loop over them
to get, enable, and disable the clocks.
* Using qcom,msm8996 based compatibles for bindings instead of a generic
qcom compatible.
* Refactor MMU500 patch to just add the necessary clock names
[PATCH v9 5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant
qcom,smmu-v2 is an arm,smmu-v2 implementation with specific
clock and power requirements. This smmu core is used with
multiple masters on msm8996, viz. mdss, video, etc.
Add bindings for the same.
Signed-off-by: Vivek Gautam
Reviewed-by: Rob Herring
Reviewed-by: Tomasz Figa
---
.../devicetree/bindings/iommu/arm,smmu.txt | 42 ++
drivers/iommu/arm-smmu.c | 14
2 files changed, 56 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
index 8a6ffce12af5..7c71a6ed465a 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -17,10 +17,19 @@ conditions.
"arm,mmu-401"
"arm,mmu-500"
"cavium,smmu-v2"
+"qcom,-smmu-v2", "qcom,smmu-v2"
depending on the particular implementation and/or the
version of the architecture implemented.
+ A number of Qcom SoCs use qcom,smmu-v2 version of the IP.
+ "qcom,-smmu-v2" represents a soc specific compatible
+ string that should be present along with the "qcom,smmu-v2"
+ to facilitate SoC specific clocks/power connections and to
+ address specific bug fixes.
+ An example string would be -
+ "qcom,msm8996-smmu-v2", "qcom,smmu-v2".
+
- reg : Base address and size of the SMMU.
- #global-interrupts : The number of global interrupts exposed by the
@@ -71,6 +80,22 @@ conditions.
or using stream matching with #iommu-cells = <2>, and
may be ignored if present in such cases.
+- clock-names:List of the names of clocks input to the device. The
+ required list depends on particular implementation and
+ is as follows:
+ - for "qcom,smmu-v2":
+- "bus": clock required for downstream bus access and
+ for the smmu ptw,
+- "iface": clock required to access smmu's registers
+ through the TCU's programming interface.
+ - unspecified for other implementations.
+
+- clocks: Specifiers for all clocks listed in the clock-names property,
+ as per generic clock bindings.
+
+- power-domains: Specifiers for power domains required to be powered on for
+ the SMMU to operate, as per generic power domain bindings.
+
** Deprecated properties:
- mmu-masters (deprecated in favour of the generic "iommus" binding) :
@@ -137,3 +162,20 @@ conditions.
iommu-map = <0 &smmu3 0 0x400>;
...
};
+
+ /* Qcom's arm,smmu-v2 implementation */
+ smmu4: iommu {
+ compatible = "qcom,msm8996-smmu-v2", "qcom,smmu-v2";
+ reg = <0xd0 0x1>;
+
+ #global-interrupts = <1>;
+ interrupts = ,
+,
+;
+ #iommu-cells = <1>;
+ power-domains = <&mmcc MDSS_GDSC>;
+
+ clocks = <&mmcc SMMU_MDP_AXI_CLK>,
+<&mmcc SMMU_MDP_AHB_CLK>;
+ clock-names = "bus", "iface";
+ };
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 64953ff2281f..1ef6ac56a347 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -119,6 +119,7 @@ enum arm_smmu_implementation {
GENERIC_SMMU,
ARM_MMU500,
CAVIUM_SMMUV2,
+ QCOM_SMMUV2,
};
struct arm_smmu_s2cr {
@@ -2000,6 +2001,17 @@ ARM_SMMU_MATCH_DATA(arm_mmu401, ARM_SMMU_V1_64K,
GENERIC_SMMU);
ARM_SMMU_MATCH_DATA(arm_mmu500, ARM_SMMU_V2, ARM_MMU500);
ARM_SMMU_MATCH_DATA(cavium_smmuv2, ARM_SMMU_V2, CAVIUM_SMMUV2);
+static const char * const qcom_smmuv2_clks[] = {
+ "bus", "iface",
+};
+
+static const struct arm_smmu_match_data qcom_smmuv2 = {
+ .version = ARM_SMMU_V2,
+ .model = QCOM_SMMUV2,
+ .clks = qcom_smmuv2_clks,
+ .num_clks = ARRAY_SIZE(qcom_smmuv2_clks),
+};
+
static const struct of_device_id arm_smmu_of_match[] = {
{ .compatible = "arm,smmu-v1", .data = &smmu_generic_v1 },
{ .compatible = "arm,smmu-v2", .data = &smmu_generic_v2 },
@@ -2007,6 +2019,7 @@ static const struct of_device_id arm_smmu_of_match[] = {
{ .compatible = "arm,mmu-401", .data = &arm_mmu401 },
{ .compatible = "arm,mmu-500", .data = &arm_mmu500 },
{ .compatible = "cavium,smmu-v2", .data = &cavium_smmuv2 },
+ { .compatible = "qcom,smmu-v2", .data = &qcom_smmuv2 },
{ },
};
MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
@@ -2381,6 +2394,7 @@ IOMMU_OF_DECLARE(arm_mmu400, "arm,mmu-400");
IOMMU_OF_DECLARE(arm_mmu401, "
