On Fri, Jul 13, 2018 at 03:58:25PM +0800, Anson Huang wrote:
> Enable pwm1 module on i.MX6SLL EVK board to make
> backlight driver really work with LCD panel connected.
>
> Signed-off-by: Anson Huang
Applied all, thanks.
On Fri, Jul 13, 2018 at 03:58:25PM +0800, Anson Huang wrote:
> Enable pwm1 module on i.MX6SLL EVK board to make
> backlight driver really work with LCD panel connected.
>
> Signed-off-by: Anson Huang
Applied all, thanks.
Hello Matthias,
Thanks for your review comments.
On 7/13/2018 5:49 AM, Matthias Kaehlcke wrote:
Hi,
On Thu, Jul 12, 2018 at 11:35:45PM +0530, Taniya Das wrote:
The CPUfreq HW present in some QCOM chipsets offloads the steps necessary
for changing the frequency of CPUs. The driver implements
Hello Matthias,
Thanks for your review comments.
On 7/13/2018 5:49 AM, Matthias Kaehlcke wrote:
Hi,
On Thu, Jul 12, 2018 at 11:35:45PM +0530, Taniya Das wrote:
The CPUfreq HW present in some QCOM chipsets offloads the steps necessary
for changing the frequency of CPUs. The driver implements
Hi,
* Neil Armstrong [180716 20:42]:
> Add the missing fck clock to all timer nodes of the AM33XX dtsi.
>
> Signed-off-by: Neil Armstrong
> ---
> arch/arm/boot/dts/am33xx.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi
Hi,
* Neil Armstrong [180716 20:42]:
> Add the missing fck clock to all timer nodes of the AM33XX dtsi.
>
> Signed-off-by: Neil Armstrong
> ---
> arch/arm/boot/dts/am33xx.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi
There's a race condition between soft offline and hugetlb_fault which
causes unexpected process killing and/or hugetlb allocation failure.
The process killing is caused by the following flow:
CPU 0 CPU 1 CPU 2
soft offline
get_any_page
// find the hugetlb
I've updated the patchset based on feedbacks:
- updated comments (from Andrew),
- moved calling set_hwpoison_free_buddy_page() from mm/migrate.c to
mm/memory-failure.c,
which is necessary to check the return code of set_hwpoison_free_buddy_page(),
- lkp bot reported a build error when only 1/2
A process can be killed with SIGBUS(BUS_MCEERR_AR) when it tries to
allocate a page that was just freed on the way of soft-offline.
This is undesirable because soft-offline (which is about corrected error)
is less aggressive than hard-offline (which is about uncorrected error),
and we can make
A process can be killed with SIGBUS(BUS_MCEERR_AR) when it tries to
allocate a page that was just freed on the way of soft-offline.
This is undesirable because soft-offline (which is about corrected error)
is less aggressive than hard-offline (which is about uncorrected error),
and we can make
There's a race condition between soft offline and hugetlb_fault which
causes unexpected process killing and/or hugetlb allocation failure.
The process killing is caused by the following flow:
CPU 0 CPU 1 CPU 2
soft offline
get_any_page
// find the hugetlb
I've updated the patchset based on feedbacks:
- updated comments (from Andrew),
- moved calling set_hwpoison_free_buddy_page() from mm/migrate.c to
mm/memory-failure.c,
which is necessary to check the return code of set_hwpoison_free_buddy_page(),
- lkp bot reported a build error when only 1/2
On Mon, 16 Jul 2018, Bueso wrote:
In order for load/store tearing to work, _all_ accesses to
^ prevention
On Mon, 16 Jul 2018, Bueso wrote:
In order for load/store tearing to work, _all_ accesses to
^ prevention
In order for load/store tearing to work, _all_ accesses to
the variable in question need to be done around READ and
WRITE_ONCE() macros. Ensure everyone does so for q->status
variable for semtimedop().
Signed-off-by: Davidlohr Bueso
---
ipc/sem.c | 2 +-
1 file changed, 1 insertion(+), 1
In order for load/store tearing to work, _all_ accesses to
the variable in question need to be done around READ and
WRITE_ONCE() macros. Ensure everyone does so for q->status
variable for semtimedop().
Signed-off-by: Davidlohr Bueso
---
ipc/sem.c | 2 +-
1 file changed, 1 insertion(+), 1
On i.MX6SLL EVK board, pfuze100 sw4 supplies
LPDDR3 which is critical for system, must be
always on.
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6sll-evk.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/imx6sll-evk.dts
b/arch/arm/boot/dts/imx6sll-evk.dts
index
On i.MX6SLL EVK board, pfuze100 sw4 supplies
LPDDR3 which is critical for system, must be
always on.
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6sll-evk.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/imx6sll-evk.dts
b/arch/arm/boot/dts/imx6sll-evk.dts
index
From: Robin Gong
On i.MX6SL EVK board, pfuze100 sw4 supplies
LPDDR2 which is critical for system, must be
always on.
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6sl-evk.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/imx6sl-evk.dts
From: Robin Gong
On i.MX6SL EVK board, pfuze100 sw4 supplies
LPDDR2 which is critical for system, must be
always on.
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6sl-evk.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/imx6sl-evk.dts
On i.MX6SX SDB Rev-A board, pfuze100 sw4 supplies
csi, audio codec and i2c etc., these modules do NOT
implement power domain control, so pfuze100 sw4
needs to be always on to make sure these modules
work normally.
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6sx-sdb-reva.dts | 1 +
1
On i.MX6SX SDB Rev-A board, pfuze100 sw4 supplies
csi, audio codec and i2c etc., these modules do NOT
implement power domain control, so pfuze100 sw4
needs to be always on to make sure these modules
work normally.
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6sx-sdb-reva.dts | 1 +
1
On i.MX6QDL Sabre-SD board, pfuze100 sw4 supplies
GPS, touch and RGMII etc., these modules do NOT
implement power domain control, so pfuze100 sw4
needs to be always on to make sure these modules
work normally.
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 1 +
1 file
On i.MX6QDL Sabre-SD board, pfuze100 sw4 supplies
GPS, touch and RGMII etc., these modules do NOT
implement power domain control, so pfuze100 sw4
needs to be always on to make sure these modules
work normally.
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 1 +
1 file
On 7/10/2018 4:37 PM, Adrian Hunter wrote:
On 21/06/18 15:23, Vijay Viswanath wrote:
Some controllers can have internal mechanism to inform the SW that it
is ready for voltage switching. For such controllers, changing voltage
before the HW is ready can result in various issues.
Add a quirk,
On 7/10/2018 4:37 PM, Adrian Hunter wrote:
On 21/06/18 15:23, Vijay Viswanath wrote:
Some controllers can have internal mechanism to inform the SW that it
is ready for voltage switching. For such controllers, changing voltage
before the HW is ready can result in various issues.
Add a quirk,
On Tue, 17 Jul 2018, jiang.bi...@zte.com.cn wrote:
> > On 07/15/2018 09:03 PM, Jiang Biao wrote:
> >> diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
> >> index 4d418e7..be9e5bc 100644
> >> --- a/arch/x86/mm/pti.c
> >> +++ b/arch/x86/mm/pti.c
> >> @@ -195,8 +195,10 @@ static p4d_t
On Tue, 17 Jul 2018, jiang.bi...@zte.com.cn wrote:
> > On 07/15/2018 09:03 PM, Jiang Biao wrote:
> >> diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
> >> index 4d418e7..be9e5bc 100644
> >> --- a/arch/x86/mm/pti.c
> >> +++ b/arch/x86/mm/pti.c
> >> @@ -195,8 +195,10 @@ static p4d_t
On Mon, 2018-07-16 at 07:55 -0600, Rob Herring wrote:
> If that data is one set per SoC, then i'm not that concerned having
> platform-specific data in the driver. That doesn't mean the driver is
> not "generic". It's still not clear to me in this thread, how much of
> this is board specific, but
On Mon, 2018-07-16 at 07:55 -0600, Rob Herring wrote:
> If that data is one set per SoC, then i'm not that concerned having
> platform-specific data in the driver. That doesn't mean the driver is
> not "generic". It's still not clear to me in this thread, how much of
> this is board specific, but
Hi all,
After merging the integrity tree, today's linux-next build (x86_64
allmodconfig) failed like this:
security/integrity/ima/ima_main.c:549:5: error: redefinition of 'ima_load_data'
int ima_load_data(enum kernel_load_data_id id)
^
security/integrity/ima/ima_main.c:506:5:
Hi all,
After merging the integrity tree, today's linux-next build (x86_64
allmodconfig) failed like this:
security/integrity/ima/ima_main.c:549:5: error: redefinition of 'ima_load_data'
int ima_load_data(enum kernel_load_data_id id)
^
security/integrity/ima/ima_main.c:506:5:
Upper layer users of SPI device drivers may rely on 'actual_length',
so it is important that information is correctly reported. One such
example is spi_mem_exec_op() function that will fail if
'actual_length' of the data transferred is not what was requested. Add
necessary code to populate
Upper layer users of SPI device drivers may rely on 'actual_length',
so it is important that information is correctly reported. One such
example is spi_mem_exec_op() function that will fail if
'actual_length' of the data transferred is not what was requested. Add
necessary code to populate
FYI, we noticed the following commit (built with gcc-7):
commit: 5b86d4ff5dce3271dff54119e06174dc22422903 ("afs: Implement network
namespacing")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: trinity
with following parameters:
runtime: 300s
FYI, we noticed the following commit (built with gcc-7):
commit: 5b86d4ff5dce3271dff54119e06174dc22422903 ("afs: Implement network
namespacing")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
in testcase: trinity
with following parameters:
runtime: 300s
On Sat, 14 Jul 2018, Tetsuo Handa wrote:
> David is making changes using timeout based back off (in linux-next.git)
> which is inappropriately trying to use MMF_UNSTABLE for two purposes.
>
If you believe there is a problem with the use of MMF_UNSTABLE as it sits
in -mm, please follow up
In the quest to remove all stack VLA usage from the kernel[1], this
uses the upper bounds on blocksize. Since this is always a cipher
blocksize, use the existing cipher max blocksize.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by:
In the quest to remove all stack VLA usage from the kernel[1], this uses
the newly defined max alignment to perform unaligned hashing to avoid
VLAs, and drops the helper function while adding sanity checks on the
resulting buffer sizes. Additionally, the __aligned_largest macro is
removed since
On Sat, 14 Jul 2018, Tetsuo Handa wrote:
> David is making changes using timeout based back off (in linux-next.git)
> which is inappropriately trying to use MMF_UNSTABLE for two purposes.
>
If you believe there is a problem with the use of MMF_UNSTABLE as it sits
in -mm, please follow up
In the quest to remove all stack VLA usage from the kernel[1], this
uses the upper bounds on blocksize. Since this is always a cipher
blocksize, use the existing cipher max blocksize.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by:
In the quest to remove all stack VLA usage from the kernel[1], this uses
the newly defined max alignment to perform unaligned hashing to avoid
VLAs, and drops the helper function while adding sanity checks on the
resulting buffer sizes. Additionally, the __aligned_largest macro is
removed since
In the quest to remove all stack VLA usage from the kernel[1], this uses
the maximum blocksize and adds a sanity check. For xcbc, the blocksize
must always be 16, so use that, since it's already being enforced during
instantiation.
[1]
In the quest to remove all stack VLA usage from the kernel[1], this uses
the maximum blocksize and adds a sanity check. For xcbc, the blocksize
must always be 16, so use that, since it's already being enforced during
instantiation.
[1]
On Fri, 13 Jul 2018, Michal Hocko wrote:
> > diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> > index 0fe4087d5151..e6328cef090f 100644
> > --- a/mm/oom_kill.c
> > +++ b/mm/oom_kill.c
> > @@ -488,9 +488,11 @@ void __oom_reap_task_mm(struct mm_struct *mm)
> > * Tell all users of
On Fri, 13 Jul 2018, Michal Hocko wrote:
> > diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> > index 0fe4087d5151..e6328cef090f 100644
> > --- a/mm/oom_kill.c
> > +++ b/mm/oom_kill.c
> > @@ -488,9 +488,11 @@ void __oom_reap_task_mm(struct mm_struct *mm)
> > * Tell all users of
On Mon, 2018-07-16 at 09:33 -0600, Rob Herring wrote:
> On Thu, Jul 12, 2018 at 01:48:43PM +1000, Benjamin Herrenschmidt wrote:
> > This isn't per-se a real device, it's a pseudo-device that
> > represents the use of the Aspeed built-in ColdFire to
> > implement the FSI protocol by bitbanging the
On Mon, 2018-07-16 at 09:33 -0600, Rob Herring wrote:
> On Thu, Jul 12, 2018 at 01:48:43PM +1000, Benjamin Herrenschmidt wrote:
> > This isn't per-se a real device, it's a pseudo-device that
> > represents the use of the Aspeed built-in ColdFire to
> > implement the FSI protocol by bitbanging the
On Mon, Jul 16, 2018 at 4:26 AM Mark Brown wrote:
>
> On Sun, Jul 15, 2018 at 11:25:08PM -0700, Andrey Smirnov wrote:
> > Users of SPI device drivers may rely on 'actual_length', so it is
> > important that information is correctly reported. One example would be
> > spi_mem_exec_op() which will
From: Salvatore Mesoraca
We avoid 2 VLAs by using a pre-allocated field in dsa_switch. We also
try to avoid dynamic allocation whenever possible (when using fewer than
bits-per-long ports, which is the common case).
Link:
On Mon, Jul 16, 2018 at 4:26 AM Mark Brown wrote:
>
> On Sun, Jul 15, 2018 at 11:25:08PM -0700, Andrey Smirnov wrote:
> > Users of SPI device drivers may rely on 'actual_length', so it is
> > important that information is correctly reported. One example would be
> > spi_mem_exec_op() which will
From: Salvatore Mesoraca
We avoid 2 VLAs by using a pre-allocated field in dsa_switch. We also
try to avoid dynamic allocation whenever possible (when using fewer than
bits-per-long ports, which is the common case).
Link:
On 7/17/18 1:41 AM, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
>> On Sun, Jul 15, 2018 at 04:36:17PM -0700, tip-bot for Xunlei Pang wrote:
>>> Commit-ID: 8d4c00dc38a8aa30dae8402955e55e7b34e74bc8
>>> Gitweb:
>>> https://git.kernel.org/tip/8d4c00dc38a8aa30dae8402955e55e7b34e74bc8
>>>
On 7/17/18 1:41 AM, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
>> On Sun, Jul 15, 2018 at 04:36:17PM -0700, tip-bot for Xunlei Pang wrote:
>>> Commit-ID: 8d4c00dc38a8aa30dae8402955e55e7b34e74bc8
>>> Gitweb:
>>> https://git.kernel.org/tip/8d4c00dc38a8aa30dae8402955e55e7b34e74bc8
>>>
Add support for Zodiac Inflight Innovations SSMB SPU3
board (VF610-based).
Cc: Shawn Guo
Cc: Fabio Estevam
Cc: cphe...@gmail.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrew Lunn
Signed-off-by: Andrey Smirnov
Add support for Zodiac Inflight Innovations SSMB SPU3
board (VF610-based).
Cc: Shawn Guo
Cc: Fabio Estevam
Cc: cphe...@gmail.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrew Lunn
Signed-off-by: Andrey Smirnov
On Mon, 16 Jul 2018, Roman Gushchin wrote:
> Hello, David!
>
> I think that there is an inconsistency in the memory.oom_policy definition.
> "none" and "cgroup" policies defining how the OOM scoped to this particular
> memory cgroup (or system, if set on root) is handled. And all sub-tree
>
On Mon, 16 Jul 2018, Roman Gushchin wrote:
> Hello, David!
>
> I think that there is an inconsistency in the memory.oom_policy definition.
> "none" and "cgroup" policies defining how the OOM scoped to this particular
> memory cgroup (or system, if set on root) is handled. And all sub-tree
>
On Tue, Jul 17, 2018 at 09:44:52AM +0800, kbuild test robot wrote:
>
> Fixes: 07809ecaa895 ("rcutorture: Dump reader protection sequence if failures
> or close calls")
> Signed-off-by: kbuild test robot
Good catch! I have folded this in with attribution.
On Tue, Jul 17, 2018 at 09:44:52AM +0800, kbuild test robot wrote:
>
> Fixes: 07809ecaa895 ("rcutorture: Dump reader protection sequence if failures
> or close calls")
> Signed-off-by: kbuild test robot
Good catch! I have folded this in with attribution.
On Sun, 15 Jul 2018, 禹舟键 wrote:
> Hi David
> Could I use use plain old %d? Just like this,
> pr_cont(",task=%s,pid=%d,uid=%d\n", p->comm, p->pid,
> from_kuid(_user_ns, task_uid(p)));
>
Yes please!
On Sun, 15 Jul 2018, 禹舟键 wrote:
> Hi David
> Could I use use plain old %d? Just like this,
> pr_cont(",task=%s,pid=%d,uid=%d\n", p->comm, p->pid,
> from_kuid(_user_ns, task_uid(p)));
>
Yes please!
On Thu, Jul 12, 2018 at 12:59:41PM +0200, Stefan Agner wrote:
> Use the the DRM driver for MXSFB LCD controller (used in i.MX23/
> i.MX28/i.MX6SX or i.MX7). Remove CONFIG_FB_MXS which will soon be
> removed.
>
> Note that this does not remove CONFIG_FB. CONFIG_FB gets selected
> implicity by
On Thu, Jul 12, 2018 at 12:59:41PM +0200, Stefan Agner wrote:
> Use the the DRM driver for MXSFB LCD controller (used in i.MX23/
> i.MX28/i.MX6SX or i.MX7). Remove CONFIG_FB_MXS which will soon be
> removed.
>
> Note that this does not remove CONFIG_FB. CONFIG_FB gets selected
> implicity by
On Tue, 2018-07-17 at 11:26 +0800, AceLan Kao wrote:
> Tested-by: AceLan Kao
Thanks Kao for the test.
-Srinivas
>
> The patches help the power consumption a little bit on my test
> system,
> and no obvious issue I can observe.
>
> 2018-07-03 3:01 GMT+08:00 Srinivas Pandruvada
On Tue, 2018-07-17 at 11:26 +0800, AceLan Kao wrote:
> Tested-by: AceLan Kao
Thanks Kao for the test.
-Srinivas
>
> The patches help the power consumption a little bit on my test
> system,
> and no obvious issue I can observe.
>
> 2018-07-03 3:01 GMT+08:00 Srinivas Pandruvada
On Thu, Jul 12, 2018 at 10:20:34AM +0200, Alex Gonzalez wrote:
> Alex Gonzalez (2):
> ARM: dts: imx6ul: Add DTS for ConnectCore 6UL System-On-Module (SOM)
> ARM: dts: imx6ul: Add DTS for ConnectCore 6UL SBC Express
Applied both, thanks.
On Thu, Jul 12, 2018 at 10:20:34AM +0200, Alex Gonzalez wrote:
> Alex Gonzalez (2):
> ARM: dts: imx6ul: Add DTS for ConnectCore 6UL System-On-Module (SOM)
> ARM: dts: imx6ul: Add DTS for ConnectCore 6UL SBC Express
Applied both, thanks.
GPC registers are NOT continuous, some registers are
reserved and accessing them from userspace will trigger
external abort, add regmap register access table to
avoid below abort:
root@imx6slevk:~# cat /sys/kernel/debug/regmap/20dc000.gpc/registers
[ 108.480477] Unhandled fault: imprecise
GPC registers are NOT continuous, some registers are
reserved and accessing them from userspace will trigger
external abort, add regmap register access table to
avoid below abort:
root@imx6slevk:~# cat /sys/kernel/debug/regmap/20dc000.gpc/registers
[ 108.480477] Unhandled fault: imprecise
Hi, folks
On 2018/7/4 上午11:27, 王贇 wrote:
Although we can rely on cpuacct to present the cpu usage of task
group, it is hard to tell how intense the competition is between
these groups on cpu resources.
Monitoring the wait time of each process or sched_debug could cost
too much, and there is no
Hi, folks
On 2018/7/4 上午11:27, 王贇 wrote:
Although we can rely on cpuacct to present the cpu usage of task
group, it is hard to tell how intense the competition is between
these groups on cpu resources.
Monitoring the wait time of each process or sched_debug could cost
too much, and there is no
This series introduces a new SPI mode flag, SPI_CS_WORD, that indicates that
the chip select line should be toggled after each word sent. This series
includes examples of how this can be implemented for both an SPI controller
and an SPI device.
The motivation here is to take advantage of DMA
This series introduces a new SPI mode flag, SPI_CS_WORD, that indicates that
the chip select line should be toggled after each word sent. This series
includes examples of how this can be implemented for both an SPI controller
and an SPI device.
The motivation here is to take advantage of DMA
This changes the data type of the flags field in struct spi_bitbang from
u8 to u16. This matches the size of the mode field of struct spi_device
where these flags are also used.
This is done in preparation of adding a new SPI mode flag that will be
used with this field that would otherwise not
This changes the data type of the flags field in struct spi_bitbang from
u8 to u16. This matches the size of the mode field of struct spi_device
where these flags are also used.
This is done in preparation of adding a new SPI mode flag that will be
used with this field that would otherwise not
This changes how the SPI message for the triggered buffer is setup in
the TI ADS7950 A/DC driver. By using the SPI_CS_WORD flag, we can read
multiple samples in a single SPI transfer. If the SPI controller
supports DMA transfers, we can see a significant reduction in CPU usage.
For example, on an
This adds a new SPI mode flag, SPI_CS_WORD, that is used to indicate
that a SPI device requires the chip select to be toggled after each
word that is transferred.
Signed-off-by: David Lechner
---
include/linux/spi/spi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
This adds support for the SPI_CS_WORD flag to the TI DaVinci SPI
driver. This mode can be used as long as we are using the hardware
chip select and not a GPIO chip select.
Signed-off-by: David Lechner
---
drivers/spi/spi-davinci.c | 11 ---
1 file changed, 8 insertions(+), 3
This changes how the SPI message for the triggered buffer is setup in
the TI ADS7950 A/DC driver. By using the SPI_CS_WORD flag, we can read
multiple samples in a single SPI transfer. If the SPI controller
supports DMA transfers, we can see a significant reduction in CPU usage.
For example, on an
This adds a new SPI mode flag, SPI_CS_WORD, that is used to indicate
that a SPI device requires the chip select to be toggled after each
word that is transferred.
Signed-off-by: David Lechner
---
include/linux/spi/spi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
This adds support for the SPI_CS_WORD flag to the TI DaVinci SPI
driver. This mode can be used as long as we are using the hardware
chip select and not a GPIO chip select.
Signed-off-by: David Lechner
---
drivers/spi/spi-davinci.c | 11 ---
1 file changed, 8 insertions(+), 3
Use a similar way like fixed width integer types in inttypes.h.
For the ELF, the Elf32_Addr is int type and Elf64_Addr is long long
type. It is opposite to definition of inttypes.h, so the Elf_Addr cannot
re-use the header.
In many architectures, the module loader only print the message of
HI Jerome
On 07/16/18 17:54, Jerome Brunet wrote:
>
+/* uart_ao_a_ee */
+static const unsigned int uart_ao_rx_a_c2_pins[]= { GPIOC_2 };
+static const unsigned int uart_ao_tx_a_c3_pins[]= { GPIOC_3 };
>>>
>>> Same comment as Martin about naming consistency ... drop c2
Use a similar way like fixed width integer types in inttypes.h.
For the ELF, the Elf32_Addr is int type and Elf64_Addr is long long
type. It is opposite to definition of inttypes.h, so the Elf_Addr cannot
re-use the header.
In many architectures, the module loader only print the message of
HI Jerome
On 07/16/18 17:54, Jerome Brunet wrote:
>
+/* uart_ao_a_ee */
+static const unsigned int uart_ao_rx_a_c2_pins[]= { GPIOC_2 };
+static const unsigned int uart_ao_tx_a_c3_pins[]= { GPIOC_3 };
>>>
>>> Same comment as Martin about naming consistency ... drop c2
On 7/16/2018 10:42 AM, Viresh Kumar wrote:
On 12-07-18, 23:35, Taniya Das wrote:
+static int qcom_cpu_resources_init(struct platform_device *pdev,
+ struct device_node *np, unsigned int cpu)
+{
+ struct cpufreq_qcom *c;
+ struct resource res;
+
On 7/16/2018 10:42 AM, Viresh Kumar wrote:
On 12-07-18, 23:35, Taniya Das wrote:
+static int qcom_cpu_resources_init(struct platform_device *pdev,
+ struct device_node *np, unsigned int cpu)
+{
+ struct cpufreq_qcom *c;
+ struct resource res;
+
Hello Evan,
Thank you for testing the patch.
On 7/17/2018 4:32 AM, Evan Green wrote:
Hi Taniya,
On Thu, Jul 12, 2018 at 11:06 AM Taniya Das wrote:
The CPUfreq HW present in some QCOM chipsets offloads the steps necessary
for changing the frequency of CPUs. The driver implements the cpufreq
Hello Evan,
Thank you for testing the patch.
On 7/17/2018 4:32 AM, Evan Green wrote:
Hi Taniya,
On Thu, Jul 12, 2018 at 11:06 AM Taniya Das wrote:
The CPUfreq HW present in some QCOM chipsets offloads the steps necessary
for changing the frequency of CPUs. The driver implements the cpufreq
On Fri, Jul 13, 2018 at 02:16:55AM +, Anson Huang wrote:
> Hi, Shawn
> Although the commit 5fe156f1cab4 ("regulator: pfuze100: add
> enable/disable for switch") is reverted to avoid the boot failure on some
> i.MX platforms, but adding the "regulator-always-on" property for those
>
On Fri, Jul 13, 2018 at 02:16:55AM +, Anson Huang wrote:
> Hi, Shawn
> Although the commit 5fe156f1cab4 ("regulator: pfuze100: add
> enable/disable for switch") is reverted to avoid the boot failure on some
> i.MX platforms, but adding the "regulator-always-on" property for those
>
On Wed, 2018-07-11 at 13:29 +0200, Joerg Roedel wrote:
> Hi,
>
> here is version 7 of my patches to enable PTI on x86-32.
> Changes to the previous version are:
>
> * Rebased to v4.18-rc4
>
> * Introduced pti_finalize() which is called after
> mark_readonly() and used to
On Wed, 2018-07-11 at 13:29 +0200, Joerg Roedel wrote:
> Hi,
>
> here is version 7 of my patches to enable PTI on x86-32.
> Changes to the previous version are:
>
> * Rebased to v4.18-rc4
>
> * Introduced pti_finalize() which is called after
> mark_readonly() and used to
From: Todd Poynor
Fix typo in log message.
Signed-off-by: Zhongze Hu
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/apex_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/gasket/apex_driver.c
b/drivers/staging/gasket/apex_driver.c
index
From: Todd Poynor
Fix typo in log message.
Signed-off-by: Zhongze Hu
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/apex_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/gasket/apex_driver.c
b/drivers/staging/gasket/apex_driver.c
index
From: Todd Poynor
Return -ETIMEDOUT, not -EINVAL, on timeout, including callers.
Reported-by: Dmitry Torokhov
Signed-off-by: Zhongze Hu
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/apex_driver.c | 8
drivers/staging/gasket/gasket_core.c | 2 +-
2 files changed, 5
From: Todd Poynor
gasket_sysfs_create_mapping() return EBUSY if sysfs mapping already in
use.
Signed-off-by: Zhongze Hu
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Todd Poynor
If class_create() fails, remove the gasket driver from the global
registration table.
Signed-off-by: Zhongze Hu
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/gasket_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
From: Todd Poynor
Return -ETIMEDOUT, not -EINVAL, on timeout, including callers.
Reported-by: Dmitry Torokhov
Signed-off-by: Zhongze Hu
Signed-off-by: Todd Poynor
---
drivers/staging/gasket/apex_driver.c | 8
drivers/staging/gasket/gasket_core.c | 2 +-
2 files changed, 5
1 - 100 of 1772 matches
Mail list logo
