On Tue, Jun 19, 2018 at 08:07:55AM +0200, Michal Kubecek wrote:
> In v4.18-rc1, /proc/$pid/cmdline is missing final null byte which used
> to be there in v4.17 and older kernels:
>
> 4.17.1:
> tweed:~ # cat /proc/self/cmdline | od -t c
> 000 c a t \0 / p r o c / s e l
On 2018/6/19 17:12, Borislav Petkov wrote:
On Tue, Jun 19, 2018 at 12:49:40PM +0800, Zhenzhong Duan wrote:
Imagine kernel already found a microcode blob A with extended sig/pf
matching current cpu, then another microcode B is checked which doesn't
match current cpu...
Do you see the
if
On 12-06-18, 16:32, Taniya Das wrote:
> +static int qcom_get_related_cpus(struct device_node *np, struct cpumask *m)
> +{
> + struct device_node *cpu_np, *freq_np;
> + int cpu;
> +
> + for_each_possible_cpu(cpu) {
> + cpu_np = of_cpu_device_node_get(cpu);
> + if
We must return the selector from pinmux_generic_add_function() so
pin controller device drivers can remove the right group if needed
for deferred probe for example. And we now must make sure that a
proper name is passed so we can use it to check if the entry already
exists.
Note that fixes are als
With no users left for these functions let's remove them.
Reported-by: H. Nikolaus Schaller
Cc: Andy Shevchenko
Cc: Christ van Willegen
Cc: Haojian Zhuang
Cc: Jacopo Mondi
Cc: Paul Cercueil
Cc: Sean Wang
Signed-off-by: Tony Lindgren
---
drivers/pinctrl/core.h | 6 --
drivers/pinctrl
We must use a mutex around the generic_add functions and save the
function and group selector in case we need to remove them. Otherwise
the selector use will be racy for deferred probe at least.
Fixes: 5a49b644b307 ("pinctrl: Renesas RZ/A1 pin and gpio controller")
Reported-by: H. Nikolaus Schalle
Here are fixes to the race issues for generic group and functions
reported by H. Nikolaus Schaller . I have not seen
the issue here myself, so please test to see if this is sufficient.
I've also fixed rza1 in addition to pinctrl-single. Please also check
the drivers pinctrl-mt7622.c and pinctrl-in
We must use a mutex around the generic_add functions and save the
function and group selector in case we need to remove them. Otherwise
the selector use will be racy for deferred probe at least.
Note that struct device_node *np is unused in pcs_add_function() we
remove that too and fix a checkpatc
We must return the selector from pinctrl_generic_add_group() so
pin controller device drivers can remove the right group if needed
for deferred probe for example. And we now must make sure that a
proper name is passed so we can use it to check if the entry already
exists.
Note that fixes are also
On Mon 2018-06-18 15:23:06, Sergey Senozhatsky wrote:
> On (06/18/18 15:15), Sergey Senozhatsky wrote:
> >
> > On (06/01/18 14:26), Maninder Singh wrote:
> > >
> > > Signed-off-by: Vaneet Narang
> > > Signed-off-by: Maninder Singh
> >
> > Reviewed-by: Sergey Senozhatsky
>
> OK, we probably ne
Currently the enable GPIO is being looked up on the regulator
device itself but that does not have its own DT node, this causes
the lookup to fail and the regulator not to get its GPIO. The DT
node is shared across the whole MFD and as such the lookup needs
to happen on that parent device. Moving t
On 19/06/18 08:53, Taniya Das wrote:
>
>
> On 6/18/2018 2:51 PM, Sudeep Holla wrote:
>>
>>
>> On 15/06/18 18:40, Taniya Das wrote:
>>>
>>>
>>> On 6/15/2018 5:29 PM, Amit Kucheria wrote:
>>
>> [...]
>>
A future version of the HW engine, or more likely, a firmware
revision, will make m
On Tue, Jun 19, 2018 at 05:24:20PM +0800, Zhenzhong Duan wrote:
> On 2018/6/19 17:12, Borislav Petkov wrote:
> > On Tue, Jun 19, 2018 at 12:49:40PM +0800, Zhenzhong Duan wrote:
> > > Imagine kernel already found a microcode blob A with extended sig/pf
> > > matching current cpu, then another microc
On 18/06/18 21:53, Rob Herring wrote:
On Mon, Jun 18, 2018 at 2:08 PM, Niklas Cassel wrote:
On Mon, Jun 18, 2018 at 08:48:32AM -0600, Rob Herring wrote:
On Mon, Jun 18, 2018 at 6:39 AM, Niklas Cassel wrote:
On Mon, Jun 18, 2018 at 12:06:42PM +0100, Mark Brown wrote:
On Thu, Jun 14, 2018
The type bits are part of the per-device status word. So it's natural to
consider an error in the type bits as a status error instead of only
resulting in an unsynced state.
Signed-off-by: Uwe Kleine-König
---
drivers/siox/siox-core.c | 20 ++--
1 file changed, 10 insertions(+),
Hi Pavan,
On Tuesday 19 Jun 2018 at 14:48:41 (+0530), Pavan Kondeti wrote:
> On Mon, May 21, 2018 at 03:25:05PM +0100, Quentin Perret wrote:
>
>
>
> > +static void start_eas_workfn(struct work_struct *work);
> > +static DECLARE_WORK(start_eas_work, start_eas_workfn);
> > +
> > static int
> >
Clean-up from the build system point of view.
The archpreapre and archclean for the x86 purgatory are unnecessary.
Kbuild can handle them in a normal way.
Masahiro Yamada (2):
Revert "kexec: purgatory: add clean-up for purgatory directory"
x86/build: remove unnecessary preparation for purgat
This reverts commit b0108f9e93d0d39050eaa11358852f349bdccb71.
Commit b0108f9e93d0 ("kexec: purgatory: add clean-up for purgatory
directory") stated that the kexec-purgatory.c and purgatory.ro files
were not removed after make mrproper.
In fact, they are. You can confirm it after reverting it.
kexec-purgatory.c is properly generated when Kbuild descend into
the arch/x86/purgatory/.
The archprepare target is redundant.
Signed-off-by: Masahiro Yamada
---
arch/x86/Makefile | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 246a979..a08e8
On Thu, Jun 14, 2018 at 07:08:26AM -0500, Brijesh Singh wrote:
> I think depends should look like this:
>
> config KVM_AMD_SEV
> def_bool y
> bool "AMD Secure Encrypted Virtualization (SEV) support"
> depends KVM_AMD && X86_64
> depends CRYPTO_DEV_SP_PSP && !(KVM_AMD=y && CRYPTO_DE
On 19/06/18 10:40, Quentin Perret wrote:
> Hi Pavan,
>
> On Tuesday 19 Jun 2018 at 14:48:41 (+0530), Pavan Kondeti wrote:
[...]
> > There seems to be a sysfs interface exposed by this driver to change
> > cpu_scale.
> > Should we worry about it? I don't know what is the usecase for changing the
On (06/19/18 11:32), Petr Mladek wrote:
> > - if (suppress_message_printing(msg->level)) {
> > + if (!ignore_loglevel && (msg->flags & LOG_NOCONS)) {
> >
> >
> > `ignore_loglevel' is a module param and can change any time via
> > /sys/module/printk/parameters/ignor
On Mon, May 21, 2018 at 03:25:02PM +0100, Quentin Perret wrote:
>
> +/*
> + * Returns the util of "cpu" if "p" wakes up on "dst_cpu".
> + */
> +static unsigned long cpu_util_next(int cpu, struct task_struct *p, int
> dst_cpu)
> +{
> + unsigned long util, util_est;
> + struct cfs_rq *c
On Tuesday 19 Jun 2018 at 15:21:40 (+0530), Pavan Kondeti wrote:
> On Mon, May 21, 2018 at 03:25:02PM +0100, Quentin Perret wrote:
>
>
>
> >
> > +/*
> > + * Returns the util of "cpu" if "p" wakes up on "dst_cpu".
> > + */
> > +static unsigned long cpu_util_next(int cpu, struct task_struct *p,
On 14-06-18, 11:56, Rajendra Nayak wrote:
> On 06/14/2018 03:42 AM, David Collins wrote:
> > Could you please add an example consumer DT node as well which uses
> > "SDM845 Power Domain Indexes" from qcom-rpmhpd.h? It isn't clear how a
> > specific power domain (e.g. SDM845_CX) is specified from t
On Tue, Jun 19, 2018 at 07:34:16AM +0800, Yang Shi wrote:
> diff --git a/mm/mmap.c b/mm/mmap.c
> index fc41c05..e84f80c 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2686,6 +2686,141 @@ int split_vma(struct mm_struct *mm, struct
> vm_area_struct *vma,
> return __split_vma(mm, vma, addr,
On Tuesday 19 Jun 2018 at 11:47:14 (+0200), Juri Lelli wrote:
> On 19/06/18 10:40, Quentin Perret wrote:
> > Hi Pavan,
> >
> > On Tuesday 19 Jun 2018 at 14:48:41 (+0530), Pavan Kondeti wrote:
>
> [...]
>
> > > There seems to be a sysfs interface exposed by this driver to change
> > > cpu_scale.
On 14-06-18, 12:05, Rajendra Nayak wrote:
> On 06/14/2018 03:58 AM, David Collins wrote:
> > Hello Rajendra,
> >
> > On 06/11/2018 09:40 PM, Rajendra Nayak wrote:
> >> As we move from no clients/consumers in kernel voting on corners,
> >> to *some* voting and some not voting, we might end up in a
Stephen Rothwell writes:
> Hi all,
>
> Today's linux-next merge of the userns tree got conflicts in:
>
> fs/proc/inode.c
> fs/proc/root.c
>
> between commits:
>
> 0223e0999be2 ("procfs: Move proc_fill_super() to fs/proc/root.c")
> 83cd45075c36 ("proc: Add fs_context support to procfs")
>
Each PMU has a set of 32bit event counters. But in some
special cases, the events could be counted using counters
which are effectively 64bit wide.
e.g, Arm V8 PMUv3 has a 64 bit cycle counter which can count
only the CPU cycles. Also, the PMU can chain the event counters
to effectively count as a
Each PMU defines their max_period of the counter as the maximum
value that can be counted. Since all the PMU backends support
32bit counters by default, let us remove the redundant field.
No functional changes.
Cc: Mark Rutland
Cc: Will Deacon
Reviewed-by: Julien Thierry
Signed-off-by: Suzuki
The armpmu uses get_event_idx callback to allocate an event
counter for a given event, which marks the selected counter
as "used". Now, when we delete the counter, the arm_pmu goes
ahead and clears the "used" bit and then invokes the "clear_event_idx"
call back, which kind of splits the job between
armv8pmu_select_counter always returns the passed idx. So
let us make that void and get rid of the pointless checks.
Suggested-by: Mark Rutland
Cc: Will Deacon
Signed-off-by: Suzuki K Poulose
---
arch/arm64/kernel/perf_event.c | 29 +++--
1 file changed, 19 insertions(+
The arm64 PMU updates the event counters and reprograms the
counters in the overflow IRQ handler without disabling the
PMU. This could potentially cause skews in for group counters,
where the overflowed counters may potentially loose some event
counts, while they are reprogrammed. To prevent this,
Add support for 64bit event by using chained event counters
and 64bit cycle counters.
PMUv3 allows chaining a pair of adjacent 32-bit counters, effectively
forming a 64-bit counter. The low/even counter is programmed to count
the event of interest, and the high/odd counter is programmed to count
t
This series adds support for counting PMU events using 64bit counters
for arm64 PMU.
The Arm v8 PMUv3 supports combining two adjacent 32bit counters
(low even and hig odd counters) to count a given "event" in 64bit mode.
This series adds the support for 64bit events in the core arm_pmu driver
infr
Convert the {read/write}_counter APIs to handle 64bit values
to enable supporting chained event counters.
Cc: Mark Rutland
Cc: Will Deacon
Reviewed-by: Julien Thierry
Signed-off-by: Suzuki K Poulose
---
- No changes since v2
---
arch/arm/kernel/perf_event_v6.c | 4 ++--
arch/arm/kernel/p
On Mon, Jun 18, 2018 at 08:21:27PM +0100, Mark Rutland wrote:
> On Mon, Jun 18, 2018 at 05:38:06PM +0100, Will Deacon wrote:
> > On Mon, Jun 18, 2018 at 11:19:01AM +0100, Mark Rutland wrote:
> > > This series contains a few cleanups of the atomic API, fixing
> > > inconsistencies between atomic_* a
On 19/06/18 11:02, Quentin Perret wrote:
> On Tuesday 19 Jun 2018 at 11:47:14 (+0200), Juri Lelli wrote:
> > On 19/06/18 10:40, Quentin Perret wrote:
> > > Hi Pavan,
> > >
> > > On Tuesday 19 Jun 2018 at 14:48:41 (+0530), Pavan Kondeti wrote:
> >
> > [...]
> >
> > > > There seems to be a sysfs i
On Tue, Jun 19, 2018 at 11:18:01AM +0100, Mark Rutland wrote:
> On Mon, Jun 18, 2018 at 08:21:27PM +0100, Mark Rutland wrote:
> > On Mon, Jun 18, 2018 at 05:38:06PM +0100, Will Deacon wrote:
> > > On Mon, Jun 18, 2018 at 11:19:01AM +0100, Mark Rutland wrote:
> > > > This series contains a few clean
Hi Hugo,
sorry for the late response and thank you for all that deep
investigation in the pi433 driver!
> According to the datasheet[0], the deviation should always be smaller
> than 300kHz, and the following equation should be respected:
>
> (1) FDA + BRF/2 =< 500 kHz
>
> Why did you choose
On 6/19/2018 2:24 PM, Viresh Kumar wrote:
Sorry for being late..
On 07-06-18, 12:48, Taniya Das wrote:
On 6/6/2018 11:31 AM, Viresh Kumar wrote:
On 04-06-18, 16:16, Taniya Das wrote:
+static struct cpufreq_driver cpufreq_qcom_fw_driver = {
+ .flags = CPUFREQ_STICKY | CPUFR
On Tuesday 19 Jun 2018 at 12:19:01 (+0200), Juri Lelli wrote:
> On 19/06/18 11:02, Quentin Perret wrote:
> > On Tuesday 19 Jun 2018 at 11:47:14 (+0200), Juri Lelli wrote:
> > > On 19/06/18 10:40, Quentin Perret wrote:
> > > > Hi Pavan,
> > > >
> > > > On Tuesday 19 Jun 2018 at 14:48:41 (+0530), Pa
On 06/19/2018 09:01 AM, Pavan Kondeti wrote:
On Mon, May 21, 2018 at 03:25:01PM +0100, Quentin Perret wrote:
[...]
@@ -8152,6 +8176,9 @@ static inline void update_sg_lb_stats(struct lb_env *env,
if (nr_running > 1)
*overload = true;
+ if (cpu_overut
On 19/06/18 11:25, Quentin Perret wrote:
> On Tuesday 19 Jun 2018 at 12:19:01 (+0200), Juri Lelli wrote:
> > On 19/06/18 11:02, Quentin Perret wrote:
> > > On Tuesday 19 Jun 2018 at 11:47:14 (+0200), Juri Lelli wrote:
> > > > On 19/06/18 10:40, Quentin Perret wrote:
> > > > > Hi Pavan,
> > > > >
>
On Wed, May 30, 2018 at 11:26:32AM +0200, Borislav Petkov wrote:
> > In "x86/mce: Exit properly when no banks to poll" you
> > leap right to the end. I'm wondering whether this can
> > ever happen? I mean, if there are no machine check banks,
> > then how did we get a machine check?
>
> Right, so
On 19-06-18, 15:55, Taniya Das wrote:
> Yes, Viresh, earlier code was updating the table frequency as I was marking
> the table frequency INVALID.
> if (core_count != c->max_cores)
> c->table[i].frequency = CPUFREQ_ENTRY_INVALID;
>
> And thus I had to update the table freque
On 19.06.2018 04:12, Shawn Guo wrote:
> Hi Stefan,
>
> Can you take a look at the patch? Thanks.
>
> Shawn
>
> On Tue, Jun 05, 2018 at 10:43:26PM +0100, Suzuki K Poulose wrote:
>> Switch to the updated coresight bindings.
Looks good to me.
Reviewed-by: Stefan Agner
--
Stefan
>>
>> Cc: Shaw
On Tue, Jun 19, 2018 at 11:20:49AM +0100, Will Deacon wrote:
> On Tue, Jun 19, 2018 at 11:18:01AM +0100, Mark Rutland wrote:
> > On Mon, Jun 18, 2018 at 08:21:27PM +0100, Mark Rutland wrote:
> > > On Mon, Jun 18, 2018 at 05:38:06PM +0100, Will Deacon wrote:
> > > > On Mon, Jun 18, 2018 at 11:19:01A
On Tue 19-06-18 02:02:55, Matthew Wilcox wrote:
> On Tue, Jun 19, 2018 at 10:29:49AM +0200, Jan Kara wrote:
> > And for record, the problem with page cache pages is not only that
> > try_to_unmap() may unmap them. It is also that page_mkclean() can
> > write-protect them. And once PTEs are write-pr
Hi,
I'm hitting this panic when running ltp/read_all_sys on kernel-v4.18-rc1.
Test env:
FUJITSU PRIMERGY RX200 S6 GS01
Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
16384 MB memory, 598 GB disk space
[ 5915.705844] BUG: unable to handle kernel NULL pointer dereference
at 00b8
[ 5915.714587]
On Tue, Jun 19, 2018 at 11:15:41AM +0100, Suzuki K Poulose wrote:
> The arm64 PMU updates the event counters and reprograms the
> counters in the overflow IRQ handler without disabling the
> PMU. This could potentially cause skews in for group counters,
> where the overflowed counters may potential
On Mon 18-06-18 18:11:26, Mikulas Patocka wrote:
[...]
> I grepped the kernel for __GFP_NORETRY and triaged them. I found 16 cases
> without a fallback - those are bugs that make various functions randomly
> return -ENOMEM.
Well, maybe those are just optimistic attempts to allocate memory and
ha
On Mon, Jun 18, 2018 at 11:11:36PM -0400, Hugo Lefeuvre wrote:
> Hi Dan,
>
> > We need to decrement device->users-- on the error paths as well.
> > This function was already slightly broken with respect to counting the
> > users, but let's not make it worse.
> >
> > I think it's still a tiny bit
On 6/19/2018 3:04 PM, Sudeep Holla wrote:
On 19/06/18 08:53, Taniya Das wrote:
On 6/18/2018 2:51 PM, Sudeep Holla wrote:
On 15/06/18 18:40, Taniya Das wrote:
On 6/15/2018 5:29 PM, Amit Kucheria wrote:
[...]
A future version of the HW engine, or more likely, a firmware
revision,
On 06/19/2018 11:44 AM, Peter Zijlstra wrote:
On Tue, Jun 19, 2018 at 10:24:43AM +0200, Thomas Hellstrom wrote:
From: Peter Ziljstra
Make the WW mutex code more readable by adding comments, splitting up
functions and pointing out that we're actually using the Wait-Die
algorithm.
Cc: Ingo Moln
On Tue, Jun 19, 2018 at 11:15:36AM +0100, Suzuki K Poulose wrote:
> Each PMU defines their max_period of the counter as the maximum
> value that can be counted. Since all the PMU backends support
> 32bit counters by default, let us remove the redundant field.
>
> No functional changes.
>
> Cc: Ma
Am Dienstag, 19. Juni 2018, 10:07:26 CEST schrieb Masahiro Yamada:
> Hi Boris,
>
>
> 2018-06-18 16:46 GMT+09:00 Boris Brezillon :
> > On Mon, 18 Jun 2018 09:09:02 +0200
> > Richard Weinberger wrote:
> >
> >> Am Freitag, 15. Juni 2018, 03:18:50 CEST schrieb Masahiro Yamada:
> >> > According to th
On Thu, Jun 14, 2018 at 10:20:22PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 12, 2018 at 10:51:15AM +0300, Alexander Shishkin wrote:
> > +static unsigned long perf_aux_sample_size(struct perf_event *event,
> > + struct perf_sample_data *data,
> > +
Hi,
On Tue, 2018-06-19 at 11:38 +0200, Uwe Kleine-König wrote:
> The type bits are part of the per-device status word. So it's natural to
> consider an error in the type bits as a status error instead of only
> resulting in an unsynced state.
>
> Signed-off-by: Uwe Kleine-König
Acked-by: Gavin S
On Tuesday 19 Jun 2018 at 12:31:08 (+0200), Juri Lelli wrote:
> On 19/06/18 11:25, Quentin Perret wrote:
> > On Tuesday 19 Jun 2018 at 12:19:01 (+0200), Juri Lelli wrote:
> > > On 19/06/18 11:02, Quentin Perret wrote:
> > > > On Tuesday 19 Jun 2018 at 11:47:14 (+0200), Juri Lelli wrote:
> > > > > O
On Tue, Jun 19, 2018 at 11:15:37AM +0100, Suzuki K Poulose wrote:
> Convert the {read/write}_counter APIs to handle 64bit values
> to enable supporting chained event counters.
It might be worth a note that the underlying helpers will still only
write 32-bit values, and we'll only pass those 32-bit
On Thu, Jun 14, 2018 at 09:39:17PM +0200, Peter Zijlstra wrote:
> On Thu, Jun 14, 2018 at 09:25:13PM +0200, Peter Zijlstra wrote:
> > On Tue, Jun 12, 2018 at 10:51:15AM +0300, Alexander Shishkin wrote:
> > > @@ -882,6 +890,7 @@ struct perf_sample_data {
> > >*/
> > > u64
On Tue 2018-06-19 18:49:53, Sergey Senozhatsky wrote:
> On (06/19/18 11:32), Petr Mladek wrote:
> > > - if (suppress_message_printing(msg->level)) {
> > > + if (!ignore_loglevel && (msg->flags & LOG_NOCONS)) {
> > >
> > >
> > > `ignore_loglevel' is a module param and c
Hi Miquel,
Sorry for the late reply.
Currently I am addressing the comments that you gave to pl353_nand driver.
And done with those, but this is pending.
> -Original Message-
> From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
> Sent: Thursday, June 7, 2018 9:37 PM
> To: Naga Suresh
Support BD71837 gateable 32768 Hz clock.
Signed-off-by: Matti Vaittinen
---
drivers/clk/Kconfig | 6 ++
drivers/clk/Makefile | 1 +
drivers/clk/clk-bd71837.c | 146 ++
3 files changed, 153 insertions(+)
create mode 100644 drivers/clk/cl
On Tue, Jun 19, 2018 at 11:15:38AM +0100, Suzuki K Poulose wrote:
> Each PMU has a set of 32bit event counters. But in some
> special cases, the events could be counted using counters
> which are effectively 64bit wide.
>
> e.g, Arm V8 PMUv3 has a 64 bit cycle counter which can count
> only the CP
ROHM BD71837 PMIC power button driver providing power-key press
information to user-space.
Signed-off-by: Matti Vaittinen
---
drivers/input/misc/Kconfig | 10 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/bd718xx-pwrkey.c | 90 +
ROHM BD71837 PMIC MFD driver providing interrupts and support
for two subsystems:
- clk
- Regulators
Signed-off-by: Matti Vaittinen
---
drivers/mfd/Kconfig | 13 ++
drivers/mfd/Makefile| 1 +
drivers/mfd/bd71837.c | 221 ++
include/linux/mfd/bd718
Patch series adding support for ROHM BD71837 PMIC.
BD71837 is a programmable Power Management IC for powering single-core,
dual-core, and quad-core SoC’s such as NXP-i.MX 8M. It is optimized for
low BOM cost and compact solution footprint. It integrates 8 buck
regulators and 7 LDO’s to provide all
On Thu, Jun 14, 2018 at 09:47:20PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 12, 2018 at 10:51:15AM +0300, Alexander Shishkin wrote:
> > @@ -6112,6 +6219,32 @@ void perf_prepare_sample(struct perf_event_header
> > *header,
> >
> > if (sample_type & PERF_SAMPLE_PHYS_ADDR)
> > dat
Document devicetree bindings for ROHM BD71837 PMIC MFD.
Signed-off-by: Matti Vaittinen
Reviewed-by: Rob Herring
---
.../devicetree/bindings/mfd/rohm,bd71837-pmic.txt | 67 ++
1 file changed, 67 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd7
Add a helper that provides information about whether Trusted Foundations
firmware operations have been registered.
Signed-off-by: Dmitry Osipenko
---
arch/arm/firmware/trusted_foundations.c| 5 +
arch/arm/include/asm/trusted_foundations.h | 7 +++
2 files changed, 12 insertions(+)
d
CPU always jumps into the reset handler in ARM-mode from the Trusted
Foundations firmware, hence make CPU to always jump into kernel in
ARM-mode regardless of the firmware presence to support Thumb2 kernel + TF
case.
Signed-off-by: Dmitry Osipenko
---
arch/arm/mach-tegra/reset-handler.S | 1 +
a
Hello,
This series of patches brings initial support of Trusted Foundations to
Tegra30, that is to the consumer-grade Tegra30 devices which do not allow
to easily replace the proprietary bootloader. Support is initial because
this series implements only a proper CPU boot-up (main + secondary cores
CPU isn't allowed to touch secure registers while running under secure
monitor. Hence skip applying CPU erratas in the reset handler if Trusted
Foundations firmware presents.
Signed-off-by: Dmitry Osipenko
---
arch/arm/mach-tegra/reset-handler.S | 24
arch/arm/mach-tegra
On Tegra20/30 L2 cache must be initialized using firmware call if CPU
is running in insecure mode. Initialize L2 cache and setup the outer-cache
callbacks in early boot using the firmware API.
Signed-off-by: Dmitry Osipenko
---
arch/arm/mach-tegra/tegra.c | 15 +++
1 file changed, 15
Implement L2 cache initialization firmware callback that should be invoked
early in boot to enable cache HW.
Signed-off-by: Dmitry Osipenko
---
arch/arm/firmware/trusted_foundations.c | 27 +
1 file changed, 27 insertions(+)
diff --git a/arch/arm/firmware/trusted_foundat
On Mon, May 21, 2018 at 03:24:58PM +0100, Quentin Perret wrote:
> +struct em_freq_domain {
> + struct em_cs_table *cs_table;
> + cpumask_t cpus;
> +};
https://lkml.kernel.org/r/20180612125930.gp12...@hirez.programming.kicks-ass.net
On 2018/06/16 4:40, Tetsuo Handa wrote:
> Hmm, there might be other locations calling percpu_rwsem_release() ?
There are other locations calling percpu_rwsem_release(), but quite few.
include/linux/fs.h:1494:#define __sb_writers_release(sb, lev) \
include/linux/fs.h-1495-
percpu_rwsem_r
On 6/19/2018 11:36 AM, Tero Kristo wrote:
On 19/06/18 07:28, Keerthy wrote:
The default restore context function enables or disables
the clock based on the enable_count. This is done in cases
where the clock context is lost and based on the enable_count
the clock either needs to be enabled/di
Hi Martin,
Commit
508fbc44bbb7 ("scsi: be2iscsi: Include null char in SET_HOST_DATA")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
pgp4IyFUYsQoF.pgp
Description: OpenPGP digital signature
Am Freitag, 15. Juni 2018, 03:18:52 CEST schrieb Masahiro Yamada:
> This commit improves the ->setup_data_interface() hook.
>
> The denali_setup_data_interface() needs the frequency of clk_x
> and the ratio of clk_x / clk.
>
> The latter is currently hardcoded in the driver, like this:
>
> #de
Fixes: 17a867cdd048 ("drm/panel: Add support for Olimex LCD-OLinuXino panel")
Signed-off-by: kbuild test robot
---
panel-olimex-lcd-olinuxino.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c
b/drivers/gpu/drm/panel/pane
Am Freitag, 15. Juni 2018, 03:18:51 CEST schrieb Masahiro Yamada:
> The probe function references &pdev->dev many times. Add 'dev' as
> a shorthand.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> drivers/mtd/nand/raw/denali_dt.c | 25 +--
Commit 51bc085d6454 ("PCI: Improve host drivers compile test coverage")
added configuration options to allow PCI host controller drivers to be
compile tested on all architectures.
Some host controller drivers (eg PCIE_ALTERA) config entries select
the PCI_DOMAINS config option to enable PCI domain
Linus,
Please pull the userns-linus branch from the git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
userns-linus
HEAD: 04035aa33a1258ca3c30f58138897ca3e97485f1 proc: Don't change mount
options on remount failure.
Mount options for proc have been som
From: Mike Galbraith
> Sent: 17 June 2018 14:39
...
> > > Is dinky patchlet suggesting cryptomgr is being naughty?
...
> > diff --git a/arch/x86/crypto/aegis128-aesni-asm.S
> > b/arch/x86/crypto/aegis128-aesni-asm.S
> > index 9254e0b6cc06..717bf0776421 100644
> > --- a/arch/x86/crypto/aegis128-aes
Hi Masahiro,
On Fri, 15 Jun 2018 10:18:50 +0900
Masahiro Yamada wrote:
> According to the Denali User's Guide, this IP needs three clocks:
>
> - clk: controller core clock
>
> - clk_x: bus interface clock
>
> - ecc_clk: clock at which ECC circuitry is run
>
> Currently, denali_dt.c requir
On Mon, May 21, 2018 at 03:24:58PM +0100, Quentin Perret wrote:
> + read_lock_irqsave(&em_data_lock, flags);
> + for_each_cpu(cpu, cpu_possible_mask) {
I know we're likely to only use this on small systems, but this pattern
is a very bad, Please look at alternatives.
On Mon, May 21, 2018 at 03:24:58PM +0100, Quentin Perret wrote:
> +struct em_freq_domain *em_cpu_get(int cpu)
> +{
> + struct em_freq_domain *fd;
> + unsigned long flags;
> +
> + read_lock_irqsave(&em_data_lock, flags);
> + fd = per_cpu(em_data, cpu);
> + read_unlock_irqrestore(
On 14/06/18 08:38, Manish Narani wrote:
> Ping for RFC
What is eemi? Why aren't there patches for that?
>
>> -Original Message-
>> From: Manish Narani [mailto:manish.nar...@xilinx.com]
>> Sent: Thursday, June 7, 2018 5:42 PM
>> To: robh...@kernel.org; mark.rutl...@arm.com; catalin.mari.
From: Andy Lutomirski
> Sent: 15 June 2018 19:54
> On Fri, Jun 15, 2018 at 11:50 AM Dave Hansen
> wrote:
> >
> > On 06/15/2018 11:31 AM, Andy Lutomirski wrote:
> > > for (thing) {
> > > kernel_fpu_begin();
> > > encrypt(thing);
> > > kernel_fpu_end();
> > > }
> >
> > Don't forget that the pr
This bug report is getting no feedback, but I guess that this bug is in
block or mm or locking layer rather than fs layer.
NMI backtrace for this bug tends to report that sb_bread() from fill_super()
from mount_bdev() is stalling is the cause of keep holding s_umount_key for
more than 120 seconds
On Tue, Jun 19, 2018 at 1:10 PM, Tetsuo Handa
wrote:
> On 2018/06/16 4:40, Tetsuo Handa wrote:
>> Hmm, there might be other locations calling percpu_rwsem_release() ?
>
> There are other locations calling percpu_rwsem_release(), but quite few.
>
> include/linux/fs.h:1494:#define __sb_writers_relea
On Tue, Jun 19, 2018 at 1:44 PM, Tetsuo Handa
wrote:
> This bug report is getting no feedback, but I guess that this bug is in
> block or mm or locking layer rather than fs layer.
>
> NMI backtrace for this bug tends to report that sb_bread() from fill_super()
> from mount_bdev() is stalling is t
From: Yang Yingliang
On a NUMA system, if an ITS is local to an offline node, the ITS
driver may pick an offline CPU to bind the LPI. In this case,
we need to pick an online CPU (and the first one will do).
But on some systems, binding an LPI to non-local node CPU may
cause deadlock (see Cavium
Similarily to the SYNC operation, we need to verify that the VPE
targetted by a VLPI is backed by a valid collection in the
GIC driver data structures.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3-its.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff
We're missing the IRQCHIP_SUPPORTS_LEVEL_MSI debug entry, making
debugfs slightly less useful. Take this opportunity to also add
a missing comment in the definition of IRQCHIP_SUPPORTS_LEVEL_MSI.
Fixes: 6988e0e0d283 ("genirq/msi: Limit level-triggered MSI to platform
devices")
Signed-off-by: Marc
It is possible, under obscure circumstances, to convince the ITS
driver to emit a SYNC operation that targets a collection that is
not bound to any redistributor (and the target_address field is
zero) because the corresponding CPU has not been seen yet (the
system has been booted with max_cpus="som
101 - 200 of 877 matches
Mail list logo
