Hi Morimoto-san
Thanks for your comments
On 2018/10/04 12:43, Kuninori Morimoto wrote:
Hi Jiada
Thank you for your feedback
in GEN3 SSI may use different BUSIF for data transfer,
this patch adds busif property to each dai stream,
to indicate the BUSIF used by playback/capture stream.
Also
On Thu, Oct 04, 2018 at 02:51:48PM +0800, Axel Lin wrote:
> All the fields in struct bd718xx_pmic are not really necessary.
> Remove struct bd718xx_pmic to simplify the code.
>
> Signed-off-by: Axel Lin
> Reviewed-by: Matti Vaittinen
> ---
> v3: Remove the references to struct bd718xx_pmic from
sn_sal_console_write() used spin_is_locked() + spin_lock() to get
achieve the same thing as a spin_trylock(), so simplify it by using that
instead. This is also a step towards possibly removing spin_is_locked().
Signed-off-by: Lance Roy
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc:
---
drivers/tt
On the OCSSD 2.0 spec, the device populates the metadata pointer (if
provided) when a chunk is reset. Implement this path in pblk. This is
the base for implementing wear-leveling and supporting variable size
chunks (e.g., due to the device mapping out certain sectors).
For 1.2, reset the write poi
Stephen Rothwell writes:
> Hi Eric,
>
> Today's linux-next merge of the userns tree got a conflict in:
>
> kernel/signal.c
>
> between commit:
>
> 49c39f8464a9 ("y2038: signal: Change rt_sigtimedwait to use
> __kernel_timespec")
>
> from the y2038 tree and commit:
>
> ae7795bc6187 ("signal
On Wed 12-09-18 15:28:52, Waiman Long wrote:
> From: Davidlohr Bueso
>
> Instead of the current O(N) implementation, at the cost
> of adding an atomic counter, we can convert the call to
> an atomic_read(). The counter only serves for accounting
> empty to non-empty transitions, and vice versa; t
On Wed, Oct 3, 2018 at 8:08 PM Leonard Crestez wrote:
> On Wed, 2018-10-03 at 13:10 +0100, Mark Brown wrote:
> > On Tue, Oct 02, 2018 at 01:42:38PM +, Leonard Crestez wrote:
> >
> > > This turns the phy off and on again instead of leaving it up from uboot
> > > and it doesn't work for some rea
All the fields in struct bd718xx_pmic are not really necessary.
Remove struct bd718xx_pmic to simplify the code.
Signed-off-by: Axel Lin
Reviewed-by: Matti Vaittinen
---
v4: Drop the pointer to struct bd718xx_pmic inside the struct bd718xx
v3: Remove the references to struct bd718xx_pmic from
i
On 2018-09-25 05:22, Stephen Boyd wrote:
We never really look at the 'ret' local variable in these functions, so
let's remove it to make way for shorter and simpler code. Furthermore,
we can shorten some lines by adding two local variables for the SE and
the message length so that everything fits
On Thu, 4 Oct 2018, Jia-Ju Bai wrote:
> > Why? Forcing all the report buffer to be limited to be non-sleeping
> > allocations just because of two drivers, looks like an overkill, and
> > actually calls for more issues (as GFP_ATOMIC is of course in principle
> > less likely to succeed).
>
> Okay,
Add device tree binding information for DA7280 haptic driver.
Example bindings for DA7280 are added.
Reviewed-by: Rob Herring .
Signed-off-by: Roy Im
---
v7: No changes.
v6: No changes.
v5: Updated descriptions and fixed errors.
v4: Fixed commit message, properties.
v3: Fixed subject format.
Adds support for the Dialog DA7280 LRA/ERM Haptic Driver with
multiple mode and integrated waveform memory and wideband support.
It communicates via an I2C bus to the device.
Signed-off-by: Roy Im
---
v7:
- Added more attributes to handle one value per file.
- Replaced and upd
This patch adds support for the Dialog DA7280 Haptic driver IC.
In this patch set the following is provided:
[PATCH V2 1/3] MAINTAINERS file update for DA7280
[PATCH V2 2/3] DA7280 DT Binding
[PATCH V2 3/3] DA7280 Driver
This patch applies against linux-next and v4.19-rc6
Thank you,
Roy Im, Dia
This patch adds the da7280 bindings doc and driver to the Dialog
Semiconductor support list.
Signed-off-by: Roy Im
---
v7: No changes.
v6: No changes.
v5: No changes.
v4: No changes.
v3: No changes.
v2: No changes.
MAINTAINERS |2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAI
+Julien, Zhengxunli and Mason from Macronix
Hi Yogesh,
On Thu, 4 Oct 2018 06:51:41 +
Yogesh Narayan Gaur wrote:
> Hi Vignesh,
>
> > -Original Message-
> > From: Vignesh R [mailto:vigne...@ti.com]
> > Sent: Wednesday, October 3, 2018 10:26 PM
> > To: Boris Brezillon ; Marek Vasut
>
The function get_loadavg() returns almost always zero. To be more
precise, statistically speaking for a total of 1023379 times passing
in the function, the load is equal to zero 1020728 times, greater than
100, 610 times, the remaining is between 0 and 5.
In 2011, the get_loadavg() was removed fro
The function nr_iowait_cpu() can be used directly by nr_iowait() instead
of duplicating code.
Call nr_iowait_cpu() from nr_iowait()
Signed-off-by: Daniel Lezcano
---
kernel/sched/core.c | 40 +++-
1 file changed, 19 insertions(+), 21 deletions(-)
diff --git
On (10/03/18 11:37), Daniel Wang wrote:
> When `softlockup_panic` is set (which is what my original repro had and
> what we use in production), without the backport patch, the expected panic
> would hit a seemingly deadlock. So even when the machine is configured
> to reboot immediately after the p
On Wed 03-10-18 19:15:18, Dan Williams wrote:
> Changes since v1:
> * Add support for shuffling hot-added memory (Andrew)
> * Update cover letter and commit message to clarify the performance impact
> and relevance to future platforms
I believe this hasn't addressed my questions in
http://lkml.k
On Wed, Oct 03, 2018 at 09:59:48PM -0700, Nadav Amit wrote:
> This patch proposes to do something different: break
> it into two. One part holds code+data that is needed for the entry
> (trampoline code, entry stack and TSS), which is mapped in the fixmap.
> The other part holds the exception_stac
On Wed, Oct 03, 2018 at 03:25:54PM +0200, Jan Kara wrote:
> On Wed 03-10-18 08:53:37, Linus Walleij wrote:
> > On Wed, Oct 3, 2018 at 8:29 AM Paolo Valente
> > wrote:
> >
> > > So, I do understand your need for conservativeness, but, after so much
> > > evidence on single-queue devices, and so m
On Thu, Oct 4, 2018 at 9:42 AM Daniel Lezcano wrote:
>
> The function nr_iowait_cpu() can be used directly by nr_iowait() instead
> of duplicating code.
>
> Call nr_iowait_cpu() from nr_iowait()
>
> Signed-off-by: Daniel Lezcano
Reviewed-by: Rafael J. Wysocki
> ---
> kernel/sched/core.c | 40
On 2018-09-26 03:19, Doug Anderson wrote:
Hi,
On Mon, Sep 24, 2018 at 4:52 PM Stephen Boyd
wrote:
We don't need to use goto here, we can just collapse the if statement
and goto chain into multiple branches and then combine some duplicate
completion calls into one big if statement. Let's do i
Add binding documentation for the True Random Number Generator
found on Samsung Exynos 5250+ SoCs.
Acked-by: Rob Herring
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Łukasz Stelmach
---
This time with proper tags, as requested.
Kind regards,
ŁS
.../bindings/rng/samsung,exynos5250-trng.tx
On Tue, Oct 02, 2018 at 11:44:06PM +0200, Rafael J. Wysocki wrote:
> idx = -1;
> - for (i = first_idx; i < drv->state_count; i++) {
> + for (i = 0; i < drv->state_count; i++) {
> struct cpuidle_state *s = &drv->states[i];
> struct cpuidle_state_usage *su =
On Wed 03-10-18 19:15:24, Dan Williams wrote:
> Some data exfiltration and return-oriented-programming attacks rely on
> the ability to infer the location of sensitive data objects. The kernel
> page allocator, especially early in system boot, has predictable
> first-in-first out behavior for physi
On Thu, Oct 04, 2018 at 05:11:17AM +0200, Paul Menzel wrote:
> Thank you for looking into this. On what board are you able to reproduce
> this? Do you build for 32-bit or 64-bit?
32-bit partition on an AMD F14h laptop.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posti
On Wed 2018-10-03 13:37:04, Steven Rostedt wrote:
> On Wed, 3 Oct 2018 10:16:08 -0700
> Daniel Wang wrote:
>
> > On Wed, Oct 3, 2018 at 2:14 AM Petr Mladek wrote:
> > >
> > > On Tue 2018-10-02 21:23:27, Steven Rostedt wrote:
> > > > I don't see the big deal of backporting this. The biggest com
This cleans up the directory a bit allowing just one place to look for
thermal related drivers for QCOM platforms instead of being scattered in
the root directory and the qcom/ subdirectory. Compile-tested with
ARCH=arm64 defconfig and the driver explicitly enabled with menuconfig.
Signed-off-by:
On Thu, Oct 04, 2018 at 08:55:45AM +0200, Rafael J. Wysocki wrote:
> On Tue, Oct 2, 2018 at 11:51 PM Rafael J. Wysocki wrote:
> >
> > Hi All,
> >
> > This series fixes a couple of issues with the menu governor, optimizes it
> > somewhat and makes a couple of cleanups in it. Please refer to the
>
Move the various drivers for Intel platforms into their own subdir. Also
consolidate Qualcomm drivers into the qcom subdir.
This cleans up the directory making it easier to find things.
There is no great time to send patches that move files around, but I'm told
that towards the end of the merge w
This cleans up the directory a bit, now that we have several other
platforms using platform-specific sub-directories. Compile-tested with
ARCH=x86 defconfig and the drivers explicitly enabled with menuconfig.
Signed-off-by: Amit Kucheria
Acked-by: Daniel Lezcano
---
drivers/thermal/Kconfig
On Thu, Oct 4, 2018 at 9:46 AM Peter Zijlstra wrote:
>
> On Tue, Oct 02, 2018 at 11:44:06PM +0200, Rafael J. Wysocki wrote:
> > idx = -1;
> > - for (i = first_idx; i < drv->state_count; i++) {
> > + for (i = 0; i < drv->state_count; i++) {
> > struct cpuidle_state *s =
* Nadav Amit wrote:
> GCC considers the number of statements in inlined assembly blocks,
> according to new-lines and semicolons, as an indication to the cost of
> the block in time and space. This data is distorted by the kernel code,
> which puts information in alternative sections. As a resu
On Thu, Oct 04, 2018 at 09:53:39AM +0200, Rafael J. Wysocki wrote:
> On Thu, Oct 4, 2018 at 9:46 AM Peter Zijlstra wrote:
> >
> > On Tue, Oct 02, 2018 at 11:44:06PM +0200, Rafael J. Wysocki wrote:
> > > idx = -1;
> > > - for (i = first_idx; i < drv->state_count; i++) {
> > > + for (i
On Wed, Oct 03, 2018 at 11:22:55PM +0200, Borislav Petkov wrote:
> On Fri, Sep 28, 2018 at 04:55:19PM +0200, Thomas Gleixner wrote:
> > Sorry for the delay and thanks for the data. A quick diff did not reveal
> > anything obvious. I'll have a closer look and we probably need more (other)
> > inform
Commit-ID: 995d5f64b62f20f05b8e0972f07ec4d6c2c9
Gitweb: https://git.kernel.org/tip/995d5f64b62f20f05b8e0972f07ec4d6c2c9
Author: Pu Wen
AuthorDate: Thu, 4 Oct 2018 09:21:43 +0800
Committer: Borislav Petkov
CommitDate: Thu, 4 Oct 2018 09:57:25 +0200
tools/cpupower: Add Hygon Dhya
On (10/04/18 16:44), Sergey Senozhatsky wrote:
> So... Just an idea. Can you try a very dirty hack? Forcibly increase
> oops_in_progress in panic() before console_flush_on_panic(), so 8250
> serial8250_console_write() will use spin_trylock_irqsave() and maybe
> avoid deadlock.
E.g. something like
On Thu, Oct 04, 2018 at 09:42:07AM +0200, Daniel Lezcano wrote:
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index b88a145..5605f03 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2873,25 +2873,12 @@ unsigned long long nr_context_switches(void)
>
> return
Hi Peter,
On 04/10/2018 09:57, Peter Zijlstra wrote:
> On Thu, Oct 04, 2018 at 09:42:07AM +0200, Daniel Lezcano wrote:
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index b88a145..5605f03 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -2873,25 +2873,12 @@ u
On Thu, Oct 04, 2018 at 10:03:21AM +0200, Joerg Roedel wrote:
> I also triggered this when working in the PTI-x32 code. It always
> happens on a 32-bit PAE kernel for me.
>
> Tracking it down I ended up in (iirc) arch/x86/mm/pageattr.c
> function static_protections():
>
> /*
>
Reviewed-by: Aurelien Aptel
--
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
On 02/10/2018 23:42, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> If the CPU exits the "polling" state due to the time limit in the
> loop in poll_idle(), this is not a real wakeup and it just means
> that the "polling" state selection was not adequate. The governor
> mispredicted shor
On 10/3/18 11:30 PM, Joe Perches wrote:
On Wed, 2018-10-03 at 22:43 +0200, Michael Straube wrote:
Cleanup array declaration to clear two 'line over 80 characters'
checkpatch warnings and improve readability.
[]
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
b/drivers/staging/rtl81
On 10/03/2018 11:03 AM, Clément Péron wrote:
> Hi,
>
> Saw this patch on the Altera OpenSource GitHub.
>
> But it's not mainlained can I propose it?
>
You sure can!
> How do you do when the patch is from someone else ? Do you keep the
> sign-off of the original author or do you just mention
On Thu, Oct 4, 2018 at 9:42 AM Daniel Lezcano wrote:
>
> The function get_loadavg() returns almost always zero. To be more
> precise, statistically speaking for a total of 1023379 times passing
> in the function, the load is equal to zero 1020728 times, greater than
> 100, 610 times, the remaining
On Thu, 4 Oct 2018 at 00:31, Jae Hyun Yoo wrote:
>
> This commit removes hard-coded bus timeout value setting so that
> it can be set by i2c-core-base.
>
> Signed-off-by: Jae Hyun Yoo
Reviewed-by: Joel Stanley
* Ingo Molnar wrote:
> I'm also somewhat annoyed at the fact that this series carries a boatload
> of reviewed-by's and acked-by's, yet none of those reviewers found it
> important to point out the large chasm that is gaping between description
> and reality.
Another problem I just realized is
When there is a mismatch in the CTR_EL0 field, we trap
access to CTR from EL0 on all CPUs to expose the safe
value. However, we could skip trapping on a CPU which
matches the safe value.
Cc: Mark Rutland
Cc: Will Deacon
Cc: Catalin Marinas
Signed-off-by: Suzuki K Poulose
---
arch/arm64/kernel
On Thu, Oct 4, 2018 at 12:27 AM Rob Herring wrote:
>
> It's convenient to use Travis-CI for doing kernel builds. Doing so
> requires a github repo, Travis-CI enabled for that repo, and a
> .travis.yml file in the repository. This commit addresses the last part.
> Each repository branch must have a
CTR_EL0.IDC reports the data cache clean requirements for instruction
to data coherence. However, if the field is 0, we need to check the
CLIDR_EL1 fields to detect the status of the feature. Currently we
don't do this and generate a warning with tainting the kernel, when
there is a mismatch in the
This series makes sure that we handle the CTR_EL0 field mismatches
properly, especially for the IDC field. Also, skip trapping CTR
accesses on a CPU if it matches the safe value.
Applies on arm64 for-next/core
Suzuki K Poulose (3):
arm64: cpufeature: ctr: Fix cpu capability check for late CPUs
The matches() routine for a capability must honor the "scope"
passed to it and return the proper results.
i.e, when passed with SCOPE_LOCAL_CPU, it should check the
status of the capability on the current CPU. This is used by
verify_local_cpu_capabilities() on a late secondary CPU to make
sure that
Hi all,
Changes since 20181003:
The bpf-next tree still had its build failure so I used the version
from next-20181002.
The kvm-arm tree gained conflicts against the arm64 tree.
The tty tree gained a build failure so I used the version from
next-20181003.
The slave-dma tree gained a build fail
On Wed, Oct 3, 2018 at 2:38 PM Sodagudi Prasad wrote:
> This is regarding the protected pins configuration reading and printing
> from non-secure operating systems.
I do not think anyone with security in mind should have debugfs
enabled. But maybe that is beside the point.
> GPIO framework is c
On Wed, Sep 12, 2018 at 10:13:06AM +0100, Quentin Perret wrote:
> +static unsigned long cpu_util_next(int cpu, struct task_struct *p, int
> dst_cpu)
> +{
> + struct cfs_rq *cfs_rq = &cpu_rq(cpu)->cfs;
> + unsigned long util_est, util = READ_ONCE(cfs_rq->avg.util_avg);
> +
> + /*
> +
HI Boris
On Thu, Oct 4, 2018 at 12:19 AM Boris Brezillon
wrote:
>
> On Thu, 4 Oct 2018 00:14:15 +0200
> Boris Brezillon wrote:
>
> > On Wed, 3 Oct 2018 23:53:27 +0200
> > Ricardo Ribalda Delgado wrote:
> >
> > > Hi Boris
> > > On Wed, Oct 3, 2018 at 11:27 PM Boris Brezillon
> > > wrote:
> > >
On Thu 2018-10-04 16:44:42, Sergey Senozhatsky wrote:
> On (10/03/18 11:37), Daniel Wang wrote:
> > When `softlockup_panic` is set (which is what my original repro had and
> > what we use in production), without the backport patch, the expected panic
> > would hit a seemingly deadlock. So even when
On 25-09-18, 14:43, Rob Herring wrote:
> On Tue, Sep 25, 2018 at 5:25 AM Rajendra Nayak wrote:
> >
> > Hi Rob,
> >
> > []...
> > > + rpmhpd_opp_table: opp-table {
> > > + compatible = "operating-points-v2-qcom-level";
> > > +
> > > + rpmhpd_opp_ret: opp1 {
> >
Hello!
On 10/3/2018 8:23 PM, Maksym Kokhan wrote:
CONFIG_BUILTIN_DTB selection is duplicated in menu
"Machine selection" under MIPS_MALTA.
Fixes: e81a8c7dabac ("MIPS: Malta: Setup RAM regions via DT")
Signed-off-by: Maksym Kokhan
Signed-off-by: Andrii Bordunov
---
arch/mips/Kconfig | 1 -
On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson wrote:
>
> I have digested the review comments so far, including a recent offlist chat
> with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I
> have a plan for how to move forward.
>
> However, to avoid re-posting non-changed patc
at 12:57 AM, Ingo Molnar wrote:
>
> * Nadav Amit wrote:
>
>> GCC considers the number of statements in inlined assembly blocks,
>> according to new-lines and semicolons, as an indication to the cost of
>> the block in time and space. This data is distorted by the kernel code,
>> which puts inf
Dear Borislav,
On 10/04/18 10:14, Borislav Petkov wrote:
> On Thu, Oct 04, 2018 at 10:03:21AM +0200, Joerg Roedel wrote:
>> I also triggered this when working in the PTI-x32 code. It always
>> happens on a 32-bit PAE kernel for me.
>>
>> Tracking it down I ended up in (iirc) arch/x86/mm/pageattr.
On 04/10/2018 10:22, Rafael J. Wysocki wrote:
> On Thu, Oct 4, 2018 at 9:42 AM Daniel Lezcano
> wrote:
>>
>> The function get_loadavg() returns almost always zero. To be more
>> precise, statistically speaking for a total of 1023379 times passing
>> in the function, the load is equal to zero 1020
On October 4, 2018 1:33:33 AM PDT, Ingo Molnar wrote:
>
>* Ingo Molnar wrote:
>
>> I'm also somewhat annoyed at the fact that this series carries a
>boatload
>> of reviewed-by's and acked-by's, yet none of those reviewers found it
>> important to point out the large chasm that is gaping between
>
Hi Heiner,
Here's the reply to your questions. Sorry for the delay.
On 28/09/2018 23:13, Heiner Kallweit wrote:
> On 29.09.2018 00:00, Chris Clayton wrote:
>> Thanks Maciej.
>>
>> On 28/09/2018 16:54, Maciej S. Szmigiero wrote:
>>> Hi,
>>>
Hi,
I upgraded my kernel to 4.18.10 recent
On 04.10.2018 01:02, gregkh wrote:
> On Wed, Oct 03, 2018 at 09:49:08PM +0200, Arnd Bergmann wrote:
>> On Wed, Oct 3, 2018 at 8:16 PM Greg Kroah-Hartman
>> wrote:
>>> On Wed, Oct 03, 2018 at 04:47:30PM +0200, Helge Deller wrote:
On 03.10.2018 00:24, Greg Kroah-Hartman wrote:
> On Tue, Oct
On Thu, Oct 04, 2018 at 10:14:38AM +0200, Borislav Petkov wrote:
> So looking at this, BIOS_BEGIN and BIOS_END is the same range as the ISA
> range:
>
> #define ISA_START_ADDRESS 0x000a
> #define ISA_END_ADDRESS 0x0010
>
> #define BIOS_BEGIN 0x000a
> #define
On Thu, Oct 4, 2018 at 10:40 AM Daniel Lezcano
wrote:
>
> On 04/10/2018 10:22, Rafael J. Wysocki wrote:
> > On Thu, Oct 4, 2018 at 9:42 AM Daniel Lezcano
> > wrote:
[cut]
> >> - interactivity_req = data->predicted_us /
> >> performance_multiplier(nr_iowaiters, cpu_load);
> >> +
Hi Boris,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Thursday, October 4, 2018 1:09 PM
> To: Yogesh Narayan Gaur
> Cc: Vignesh R ; Marek Vasut ; Rob
> Herring ; Brian Norris ;
> Linux ARM Mailing List ; linux-
> m...@lists.infradead.org; devi
On Thu, Oct 04, 2018 at 10:43:18AM +0200, Joerg Roedel wrote:
> Yeah, that's what I also found out back then, the region needs to be WX.
> So we can either leave with the warning, as we know it is harmless and
> where it comes from or implement an exception in the checking code for
> that region.
On Thu, Oct 04, 2018 at 10:40:49AM +0200, Paul Menzel wrote:
> Do you have a commit, I could test.
Not yet but I have a question for you: why are you running 32-bit and
haven't moved to 64-bit already?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the r
Add mode flags for octal I/O data transfer support.
NXP FlexSPI controller supports octal mode data transfer.
Signed-off-by: Yogesh Gaur
---
drivers/spi/spi-nxp-fspi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c
Add support for octal mode IO data transfer.
Micron flash, mt35xu512aba, supports octal mode data transfer and
NXP FlexSPI controller supports 8 data lines for data transfer (Rx/Tx).
Patch series
* Add support for octal mode flags and parsing of same in spi driver.
* Add octal data communication
Flash mt35xu512aba connected to FlexSPI controller supports
1-1-8 protocol.
Added flag spi-rx-bus-width and spi-tx-bus-width with values as
8 and 1 respectively for both flashes connected at CS0 and CS1.
Signed-off-by: Yogesh Gaur
---
arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 4
1
Add support for octal mode data transfer for Micron mt35xu512aba.
Unfortunately, this flash is only complaint to SFDP JESD216B and does
not seem to support newer JESD216C standard that provides auto detection
of Octal mode capabilities and opcodes. Therefore, this capability is
manually added usin
Add flags for Octal I/O data transfer
Required for the SPI controller which can do the data transfer (TX/RX)
on 8 data lines e.g. NXP FlexSPI controller.
SPI_TX_OCTAL: transmit with 8 wires
SPI_RX_OCTAL: receive with 8 wires
Signed-off-by: Yogesh Gaur
---
drivers/spi/spi.c | 6 ++
in
From: Dinh Nguyen
Turn on these ARM and PL310 errata for SoCFPGA:
ARM_ERRATA_754322
ARM_ERRATA_764369
ARM_ERRATA_775420
PL310_ERRATA_588369
PL310_ERRATA_727915
PL310_ERRATA_753970
PL310_ERRATA_769419
Fixes: 387798b37c8d ("ARM: initial multiplatform support")
Signed-off-by: Dinh Nguyen
Signed-
From: Dinh Nguyen
When doing a software reboot, all peripheral clocks must get turned on for the
L3 interconnect to work.
This code is needed when doing a "reboot" from user-space and a peripheral
clock as been gated off. Why would a peripheral clock get gated? An example
use case would be a .ko
These functions are unused externally, removed them and declare
the one used locally as static.
Signed-off-by: Clément Péron
---
arch/arm/mach-socfpga/core.h| 2 --
arch/arm/mach-socfpga/socfpga.c | 2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-socfpga/cor
On (10/04/18 10:36), Petr Mladek wrote:
>
> This looks like a reasonable explanation of what is happening here.
> It also explains why the console owner logic helped.
Well, I'm still a bit puzzled, frankly speaking. I've two theories.
Theory #1 [most likely]
Steven is a wizard and his code cu
* h...@zytor.com wrote:
> It's not just for working around a stupid GCC bug, but it also has a huge
> potential for
> cleaning up the inline asm in general.
Sorry but that's just plain false. For example this patch:
x86: cpufeature: use macros instead of inline assembly
... adds an extr
On Mon, Oct 01, 2018 at 09:42:37PM -0700, Guenter Roeck wrote:
> This reverts commit d76c74387e1c978b6c5524a146ab0f3f72206f98.
>
> While commit d76c74387e1c ("serial: 8250_dw: Fix runtime PM handling")
> fixes runtime PM handling when using kgdb, it introduces a traceback for
> everyone else.
Ack
at 1:40 AM, h...@zytor.com wrote:
> On October 4, 2018 1:33:33 AM PDT, Ingo Molnar wrote:
>> * Ingo Molnar wrote:
>>
>>> I'm also somewhat annoyed at the fact that this series carries a
>> boatload
>>> of reviewed-by's and acked-by's, yet none of those reviewers found it
>>> important to point
Dear Borislav,
On 10/04/18 10:49, Borislav Petkov wrote:
> On Thu, Oct 04, 2018 at 10:40:49AM +0200, Paul Menzel wrote:
>> Do you have a commit, I could test.
>
> Not yet
I meant just the test you did.
> but I have a question for you: why are you running 32-bit and
> haven't moved to 64-bit al
On 4 October 2018 at 10:39, Rafael J. Wysocki wrote:
> On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson wrote:
>>
>> I have digested the review comments so far, including a recent offlist chat
>> with with Lorenzo Pieralisi around the debatable PSCI changes. More or less I
>> have a plan for how to mov
Am Montag, den 01.10.2018, 22:53 +0300 schrieb Leonard Crestez:
> When the root complex suspends it must send a PME_Turn_Off TLP.
> Implement this by asserting the "turnoff" reset.
>
> On imx7d this is functionality is part of the SRC and exposed through
> the linux reset-controller subsystem. On
* Nadav Amit wrote:
> Finally, note that it’s not as if the binary always becomes smaller.
> Overall, with the full patch-set it is slightly bigger. But still, that’s
> how it was supposed to be if gcc wasn’t doing things badly.
So what I cited was the changelog for the refcount patch, which a
Hi Peter,
On Thursday 04 Oct 2018 at 10:34:57 (+0200), Peter Zijlstra wrote:
> On Wed, Sep 12, 2018 at 10:13:06AM +0100, Quentin Perret wrote:
> > +static unsigned long cpu_util_next(int cpu, struct task_struct *p, int
> > dst_cpu)
> > +{
> > + struct cfs_rq *cfs_rq = &cpu_rq(cpu)->cfs;
> > +
On Wed, Oct 3, 2018 at 1:49 PM Leonard Crestez wrote:
> On Tue, 2018-10-02 at 21:56 +0200, Linus Walleij wrote:
> > I guess I could hack to make "gpios" be ignored by the
> > regulator GPIO quirks in gpiolib, but I take it you probably
> > prefer to fix up the real issue like this.
>
> Maybe you
On October 4, 2018 1:56:37 AM PDT, Nadav Amit wrote:
>at 1:40 AM, h...@zytor.com wrote:
>
>> On October 4, 2018 1:33:33 AM PDT, Ingo Molnar
>wrote:
>>> * Ingo Molnar wrote:
>>>
I'm also somewhat annoyed at the fact that this series carries a
>>> boatload
of reviewed-by's and acked-by'
On 03/10/18 15:42, Steven Rostedt wrote:
> On Mon, 3 Sep 2018 16:28:00 +0200
> Juri Lelli wrote:
>
>
> > diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> > index 5b43f482fa0f..8dc26005bb1e 100644
> > --- a/kernel/cgroup/cpuset.c
> > +++ b/kernel/cgroup/cpuset.c
> > @@ -2410,6 +241
On Thursday, October 4, 2018 10:58:53 AM CEST Ulf Hansson wrote:
> On 4 October 2018 at 10:39, Rafael J. Wysocki wrote:
> > On Wed, Oct 3, 2018 at 4:39 PM Ulf Hansson wrote:
> >>
> >> I have digested the review comments so far, including a recent offlist chat
> >> with with Lorenzo Pieralisi arou
Hi Yogesh,
On Thu, 4 Oct 2018 14:18:37 +0530
Yogesh Gaur wrote:
> Add flags for Octal I/O data transfer
> Required for the SPI controller which can do the data transfer (TX/RX)
> on 8 data lines e.g. NXP FlexSPI controller.
> SPI_TX_OCTAL: transmit with 8 wires
> SPI_RX_OCTAL: receive with 8
The fixed regulator uses "gpio" (singularis) for the GPIO line
but the standard GPIO bindings recommend "gpios" (pluralis).
We have augmented the Linux kernel to handle both, so recommend
the best practice and deprecate the singularis variant.
Cc: devicet...@vger.kernel.org
Cc: Leonard Crestez
S
From: Rafael J. Wysocki
The comment related to nr_iowait_cpu() and get_iowait_load() confuses
cpufreq with cpuidle and is not very useful for this reason, so fix it.
Fixes: e33a9bba85a8 "sched/core: move IO scheduling accounting from
io_schedule_timeout() into scheduler"
Signed-off-by: Rafael J
From: Rafael J. Wysocki
If __device_suspend() returns early on an error or pending wakeup
and the power.direct_complete flag has been set for the device
already, the subsequent device_resume() will be confused by it
and it will call pm_runtime_enable() incorrectly, as runtime PM
has not been disa
On Wednesday 03 Oct 2018 at 18:27:19 (+0200), Peter Zijlstra wrote:
> On Wed, Sep 12, 2018 at 10:13:03AM +0100, Quentin Perret wrote:
> > @@ -288,6 +321,21 @@ static void build_perf_domains(const struct cpumask
> > *cpu_map)
> > goto free;
> > tmp->next = pd;
> >
On Thu, 4 Oct 2018 08:47:33 +
Yogesh Narayan Gaur wrote:
> >
> > Yogesh, you already sent "spi: add flags for octal I/O data
> > transfer" [3] which is only adding the new OCTAL flags but is not
> > patching spi.c and spi-mem.c to take those new flags into account.
> > Here is my version of
* Nadav Amit wrote:
> I can run some tests. (@hpa: I thought you asked about the -pipe overhead;
> perhaps I misunderstood).
Well, tests are unlikely to show the overhead of extra lines of this
magnitude, unless done very carefully, yet the added bloat exists and is not
even
mentioned by the
1 - 100 of 657 matches
Mail list logo
