pxrc_probe() calls usb_get_dev(), but there is no usb_put_dev()
anywhere in the driver.
The patch adds one to error handling code and to pxrc_disconnect().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/input/joystick/pxrc.c | 2 ++
pxrc_probe() calls usb_get_dev(), but there is no usb_put_dev()
anywhere in the driver.
The patch adds one to error handling code and to pxrc_disconnect().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/input/joystick/pxrc.c | 2 ++
Hi Baolin,
Thank you for the update.
On 07/13/2018 08:21 AM, Baolin Wang wrote:
From: Bjorn Andersson
Some LED controllers have support for autonomously controlling
brightness over time, according to some preprogrammed pattern or
function.
This adds a new optional operator that LED class
Hi Baolin,
Thank you for the update.
On 07/13/2018 08:21 AM, Baolin Wang wrote:
From: Bjorn Andersson
Some LED controllers have support for autonomously controlling
brightness over time, according to some preprogrammed pattern or
function.
This adds a new optional operator that LED class
On Fri, 13 Jul 2018 09:24:44 -0400 Pavel Tatashin
wrote:
> On 07/13/2018 09:17 AM, Oscar Salvador wrote:
> > On Thu, Jul 12, 2018 at 04:37:26PM -0400, Pavel Tatashin wrote:
> >> +static void *sparsemap_buf __meminitdata;
> >> +static void *sparsemap_buf_end __meminitdata;
> >> +
> >> +void
On Fri, 13 Jul 2018 09:24:44 -0400 Pavel Tatashin
wrote:
> On 07/13/2018 09:17 AM, Oscar Salvador wrote:
> > On Thu, Jul 12, 2018 at 04:37:26PM -0400, Pavel Tatashin wrote:
> >> +static void *sparsemap_buf __meminitdata;
> >> +static void *sparsemap_buf_end __meminitdata;
> >> +
> >> +void
Linus,
Please pull the latest timers-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers-urgent-for-linus
# HEAD: 5e18e412973d6bb1804de1d4d30a891c774b006e clocksource:
arm_arch_timer: Set arch_mem_timer cpumask to cpu_possible_mask
A
Linus,
Please pull the latest timers-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers-urgent-for-linus
# HEAD: 5e18e412973d6bb1804de1d4d30a891c774b006e clocksource:
arm_arch_timer: Set arch_mem_timer cpumask to cpu_possible_mask
A
Linus,
Please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
# HEAD: 6e1d33b24a2b4aebcb05782e937ebc9a7a4a3f50 Merge tag
'perf-urgent-for-mingo-4.18-20180711' of
Linus,
Please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
# HEAD: 6e1d33b24a2b4aebcb05782e937ebc9a7a4a3f50 Merge tag
'perf-urgent-for-mingo-4.18-20180711' of
On Fri, Jul 13, 2018 at 12:21 PM, Laura Abbott wrote:
> On 07/13/2018 08:30 AM, Olof Johansson wrote:
>>
>> Not all toolchains have the baremetal elf targets, RedHat/Fedora ones
>> in particular. So, probe for whether it's available and use the previous
>> (linux) targets if it isn't.
>>
>
>
>
On Fri, Jul 13, 2018 at 12:21 PM, Laura Abbott wrote:
> On 07/13/2018 08:30 AM, Olof Johansson wrote:
>>
>> Not all toolchains have the baremetal elf targets, RedHat/Fedora ones
>> in particular. So, probe for whether it's available and use the previous
>> (linux) targets if it isn't.
>>
>
>
>
Linus,
Please pull the latest efi-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
efi-urgent-for-linus
# HEAD: e296701800f30d260a66f8aa1971b5b1bc3d2f81 efi/x86: Fix mixed mode
reboot loop by removing pointless call to PciIo->Attributes()
Fix a
Linus,
Please pull the latest efi-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
efi-urgent-for-linus
# HEAD: e296701800f30d260a66f8aa1971b5b1bc3d2f81 efi/x86: Fix mixed mode
reboot loop by removing pointless call to PciIo->Attributes()
Fix a
On Fri, Jul 13, 2018 at 06:42:39PM +0200, Peter Zijlstra wrote:
>
> Hi Michael,
>
> On Fri, Jul 13, 2018 at 11:15:26PM +1000, Michael Ellerman wrote:
> > I reran some numbers today with some slightly updated tests.
> >
> > It varies quite a bit across machines and CPU revisions.
> >
> > On one
On Fri, Jul 13, 2018 at 06:42:39PM +0200, Peter Zijlstra wrote:
>
> Hi Michael,
>
> On Fri, Jul 13, 2018 at 11:15:26PM +1000, Michael Ellerman wrote:
> > I reran some numbers today with some slightly updated tests.
> >
> > It varies quite a bit across machines and CPU revisions.
> >
> > On one
On 07/13/2018 12:40 PM, Arjan van de Ven wrote:
> On 7/13/2018 12:19 PM, patrickg wrote:
>> This RFC patch is intended to allow bypass CPUID, MSR and QuickPIT
>> calibration methods should the user desire to.
>>
>> The current ordering in ML x86 tsc is to calibrate in the order listed
>>
On 07/13/2018 12:40 PM, Arjan van de Ven wrote:
> On 7/13/2018 12:19 PM, patrickg wrote:
>> This RFC patch is intended to allow bypass CPUID, MSR and QuickPIT
>> calibration methods should the user desire to.
>>
>> The current ordering in ML x86 tsc is to calibrate in the order listed
>>
On 07/13/2018 12:40 PM, Arjan van de Ven wrote:
> On 7/13/2018 12:19 PM, patrickg wrote:
>> This RFC patch is intended to allow bypass CPUID, MSR and QuickPIT
>> calibration methods should the user desire to.
>>
>> The current ordering in ML x86 tsc is to calibrate in the order listed
>>
On 07/13/2018 12:40 PM, Arjan van de Ven wrote:
> On 7/13/2018 12:19 PM, patrickg wrote:
>> This RFC patch is intended to allow bypass CPUID, MSR and QuickPIT
>> calibration methods should the user desire to.
>>
>> The current ordering in ML x86 tsc is to calibrate in the order listed
>>
This RFC patch is intended to allow bypass CPUID, MSR and QuickPIT calibration
methods should the user desire to.
The current ordering in ML x86 tsc is to calibrate in the order listed above;
returning whenever there's a successful calibration. However there are certain
BIOS/HW Designs for
This RFC patch is intended to allow bypass CPUID, MSR and QuickPIT calibration
methods should the user desire to.
The current ordering in ML x86 tsc is to calibrate in the order listed above;
returning whenever there's a successful calibration. However there are certain
BIOS/HW Designs for
On 7/13/2018 12:19 PM, patrickg wrote:
This RFC patch is intended to allow bypass CPUID, MSR and QuickPIT calibration
methods should the user desire to.
The current ordering in ML x86 tsc is to calibrate in the order listed above;
returning whenever there's a successful calibration. However
On 7/13/2018 12:19 PM, patrickg wrote:
This RFC patch is intended to allow bypass CPUID, MSR and QuickPIT calibration
methods should the user desire to.
The current ordering in ML x86 tsc is to calibrate in the order listed above;
returning whenever there's a successful calibration. However
On 7/12/2018 1:41 AM, Brendan Higgins wrote:
On Mon, Jul 2, 2018 at 2:40 PM Jae Hyun Yoo
wrote:
This patch adjusts spinlock scope to make it wrap the whole irq
handler using a single lock/unlock which covers both master and
slave handlers.
Signed-off-by: Jae Hyun Yoo
---
On 7/12/2018 1:41 AM, Brendan Higgins wrote:
On Mon, Jul 2, 2018 at 2:40 PM Jae Hyun Yoo
wrote:
This patch adjusts spinlock scope to make it wrap the whole irq
handler using a single lock/unlock which covers both master and
slave handlers.
Signed-off-by: Jae Hyun Yoo
---
On 07/13/2018 08:30 AM, Olof Johansson wrote:
Not all toolchains have the baremetal elf targets, RedHat/Fedora ones
in particular. So, probe for whether it's available and use the previous
(linux) targets if it isn't.
For the Fedora toolchains:
Tested-by: Laura Abbott
Reported-by: Laura
On 07/13/2018 08:30 AM, Olof Johansson wrote:
Not all toolchains have the baremetal elf targets, RedHat/Fedora ones
in particular. So, probe for whether it's available and use the previous
(linux) targets if it isn't.
For the Fedora toolchains:
Tested-by: Laura Abbott
Reported-by: Laura
>> Dell - Internal Use - Confidential
>Really? To a public mailing list? odd...
Ha yea sorry - I was so excited to show my support, that I jumped the gun :)
>> Dell - Internal Use - Confidential
>Really? To a public mailing list? odd...
Ha yea sorry - I was so excited to show my support, that I jumped the gun :)
On Fri, Jul 13, 2018 at 10:16:48AM -0700, Linus Torvalds wrote:
> On Fri, Jul 13, 2018 at 2:34 AM Will Deacon wrote:
> >
> > And, since we're stating preferences, I'll reiterate my preference towards:
> >
> > * RCsc unlock/lock
> > * RCpc release/acquire
>
> Yes, I think this
On Fri, Jul 13, 2018 at 10:16:48AM -0700, Linus Torvalds wrote:
> On Fri, Jul 13, 2018 at 2:34 AM Will Deacon wrote:
> >
> > And, since we're stating preferences, I'll reiterate my preference towards:
> >
> > * RCsc unlock/lock
> > * RCpc release/acquire
>
> Yes, I think this
On Fri, Jul 13, 2018 at 06:49:04PM +, eugene@dell.com wrote:
> Dell - Internal Use - Confidential
Really? To a public mailing list? odd...
On Fri, Jul 13, 2018 at 06:49:04PM +, eugene@dell.com wrote:
> Dell - Internal Use - Confidential
Really? To a public mailing list? odd...
On Wed, Jul 11, 2018 at 4:29 AM, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Warn the user in case the performance can be significantly
> improved by switching to a 64-bit kernel.
...
> +#ifdef CONFIG_X86_32
> + if (boot_cpu_has(X86_FEATURE_PCID)) {
I'm a bit confused. Wouldn't the
On Wed, Jul 11, 2018 at 4:29 AM, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Warn the user in case the performance can be significantly
> improved by switching to a 64-bit kernel.
...
> +#ifdef CONFIG_X86_32
> + if (boot_cpu_has(X86_FEATURE_PCID)) {
I'm a bit confused. Wouldn't the
On Fri, Jul 13, 2018 at 11:38:19AM -0700, Daniel Jordan wrote:
> On Fri, Jul 13, 2018 at 07:36:32AM +0800, Huang, Ying wrote:
> > @@ -1260,7 +1257,6 @@ static void swapcache_free(swp_entry_t entry)
> > }
> > }
> >
> > -#ifdef CONFIG_THP_SWAP
> > static void
On Fri, Jul 13, 2018 at 11:38:19AM -0700, Daniel Jordan wrote:
> On Fri, Jul 13, 2018 at 07:36:32AM +0800, Huang, Ying wrote:
> > @@ -1260,7 +1257,6 @@ static void swapcache_free(swp_entry_t entry)
> > }
> > }
> >
> > -#ifdef CONFIG_THP_SWAP
> > static void
On 7/13/2018 11:12 AM, Brendan Higgins wrote:
On Fri, Jul 13, 2018 at 10:22 AM Jae Hyun Yoo
wrote:
On 7/12/2018 11:21 AM, Jae Hyun Yoo wrote:
On 7/12/2018 2:33 AM, Brendan Higgins wrote:
On Wed, Jun 27, 2018 at 10:55 AM Jae Hyun Yoo
wrote:
+ for (;;) {
+ if
On 7/13/2018 11:12 AM, Brendan Higgins wrote:
On Fri, Jul 13, 2018 at 10:22 AM Jae Hyun Yoo
wrote:
On 7/12/2018 11:21 AM, Jae Hyun Yoo wrote:
On 7/12/2018 2:33 AM, Brendan Higgins wrote:
On Wed, Jun 27, 2018 at 10:55 AM Jae Hyun Yoo
wrote:
+ for (;;) {
+ if
On Fri, Jul 13, 2018 at 6:13 AM Will Deacon wrote:
>
> Catalin's out enjoying the sunshine, so I'm sending the fixes for a couple
> of weeks (although there hopefully won't be any more!).
Never fear, I'm sure there won't be more than a couple of weeks of
sunshine in the UK this summer.
That's
On Fri, Jul 06, 2018 at 03:14:28PM -0700, Joe Perches wrote:
> On Fri, 2018-07-06 at 15:09 -0700, Joe Perches wrote:
> > On Fri, 2018-07-06 at 17:58 -0400, Don Zickus wrote:
> > > We have an internal use case of multiple MAINTAINER files, some folks have
> > > more rights to patches than others so
On Fri, Jul 13, 2018 at 6:13 AM Will Deacon wrote:
>
> Catalin's out enjoying the sunshine, so I'm sending the fixes for a couple
> of weeks (although there hopefully won't be any more!).
Never fear, I'm sure there won't be more than a couple of weeks of
sunshine in the UK this summer.
That's
On Fri, Jul 06, 2018 at 03:14:28PM -0700, Joe Perches wrote:
> On Fri, 2018-07-06 at 15:09 -0700, Joe Perches wrote:
> > On Fri, 2018-07-06 at 17:58 -0400, Don Zickus wrote:
> > > We have an internal use case of multiple MAINTAINER files, some folks have
> > > more rights to patches than others so
On 7/13/2018 11:02 AM, Brendan Higgins wrote:
On Thu, Jul 12, 2018 at 11:21 AM Jae Hyun Yoo
wrote:
On 7/12/2018 2:33 AM, Brendan Higgins wrote:
On Wed, Jun 27, 2018 at 10:55 AM Jae Hyun Yoo
wrote:
+/* Timeout for bus busy checking */
+#define BUS_BUSY_CHECK_TIMEOUT
On 7/13/2018 11:02 AM, Brendan Higgins wrote:
On Thu, Jul 12, 2018 at 11:21 AM Jae Hyun Yoo
wrote:
On 7/12/2018 2:33 AM, Brendan Higgins wrote:
On Wed, Jun 27, 2018 at 10:55 AM Jae Hyun Yoo
wrote:
+/* Timeout for bus busy checking */
+#define BUS_BUSY_CHECK_TIMEOUT
Dell - Internal Use - Confidential
+1 from someone using Nuvoton's BMC SoC
-Original Message-
From: Alexander Amelkin [mailto:a.amel...@yadro.com]
Sent: Friday, July 13, 2018 10:14 AM
To: Andrew Jeffery; Benjamin Herrenschmidt; Rob Herring
Cc: Mark Rutland; devicet...@vger.kernel.org;
Dell - Internal Use - Confidential
+1 from someone using Nuvoton's BMC SoC
-Original Message-
From: Alexander Amelkin [mailto:a.amel...@yadro.com]
Sent: Friday, July 13, 2018 10:14 AM
To: Andrew Jeffery; Benjamin Herrenschmidt; Rob Herring
Cc: Mark Rutland; devicet...@vger.kernel.org;
Dear Sir/Madam,
How are you doing today? My name is Billy Wilfred. I am California, United
States of America. I am a broker of Project Financing Firm who has cutting edge
and group capital fund, they can finance any lucrative project and help you to
enhance your business plan. Are you in need
Dear Sir/Madam,
How are you doing today? My name is Billy Wilfred. I am California, United
States of America. I am a broker of Project Financing Firm who has cutting edge
and group capital fund, they can finance any lucrative project and help you to
enhance your business plan. Are you in need
On Fri, Jul 13, 2018 at 07:36:32AM +0800, Huang, Ying wrote:
> @@ -1260,7 +1257,6 @@ static void swapcache_free(swp_entry_t entry)
> }
> }
>
> -#ifdef CONFIG_THP_SWAP
> static void swapcache_free_cluster(swp_entry_t entry)
> {
> unsigned long offset = swp_offset(entry);
> @@
On Fri, Jul 13, 2018 at 07:36:32AM +0800, Huang, Ying wrote:
> @@ -1260,7 +1257,6 @@ static void swapcache_free(swp_entry_t entry)
> }
> }
>
> -#ifdef CONFIG_THP_SWAP
> static void swapcache_free_cluster(swp_entry_t entry)
> {
> unsigned long offset = swp_offset(entry);
> @@
> We bail out during patch registration for architectures, those don't
> support reliable stack trace.
Does anybody know if that change was intentional? I thought the plan
was to allow non-consistency-model arches to still use livepatch, and
that they'd just have to 'force' patches to completion
> We bail out during patch registration for architectures, those don't
> support reliable stack trace.
Does anybody know if that change was intentional? I thought the plan
was to allow non-consistency-model arches to still use livepatch, and
that they'd just have to 'force' patches to completion
Hi Anson,
On Tue, Jul 10, 2018 at 4:48 AM, Anson Huang wrote:
> GPIO registers could lose context on some i.MX SoCs,
> like on i.MX7D, when enter LPSR mode, the whole SoC
After further reviewing this patchI have a question: here you say that
i.MX7D needs to save some registers.
> will be
Hi Anson,
On Tue, Jul 10, 2018 at 4:48 AM, Anson Huang wrote:
> GPIO registers could lose context on some i.MX SoCs,
> like on i.MX7D, when enter LPSR mode, the whole SoC
After further reviewing this patchI have a question: here you say that
i.MX7D needs to save some registers.
> will be
On 07/13/2018 06:02 AM, Will Deacon wrote:
> On Tue, Jul 10, 2018 at 02:31:30PM -0400, Waiman Long wrote:
>> It was found that a constant stream of readers might cause the count to
>> go negative most of the time after an initial trigger by a writer even
>> if no writer was present afterward. As a
On 07/13/2018 06:02 AM, Will Deacon wrote:
> On Tue, Jul 10, 2018 at 02:31:30PM -0400, Waiman Long wrote:
>> It was found that a constant stream of readers might cause the count to
>> go negative most of the time after an initial trigger by a writer even
>> if no writer was present afterward. As a
On Fri, 13 Jul 2018, Metzger, Markus T wrote:
> Hello Hugh,
>
> > A little "optimization" crept into alloc_bts_buffer() along the way, which
> > now
> > places bts_interrupt_threshold not on a record boundary.
> > And Stephane has shown me the sentence in Vol 3B, 17.4.9, which says "This
> >
On Fri, 13 Jul 2018, Metzger, Markus T wrote:
> Hello Hugh,
>
> > A little "optimization" crept into alloc_bts_buffer() along the way, which
> > now
> > places bts_interrupt_threshold not on a record boundary.
> > And Stephane has shown me the sentence in Vol 3B, 17.4.9, which says "This
> >
It was discovered that a constant stream of readers might cause the
count to go negative most of the time after an initial trigger by a
writer even if no writer was present afterward. As a result, most of the
readers would have to go through the slowpath reducing their performance.
To avoid that
It was discovered that a constant stream of readers might cause the
count to go negative most of the time after an initial trigger by a
writer even if no writer was present afterward. As a result, most of the
readers would have to go through the slowpath reducing their performance.
To avoid that
This patch adds optional regulators, which can be used to power
up touchscreen. After enabling regulators, we need to wait 150msec.
This value is taken from official driver.
It was tested on Samsung Galaxy i9000 (based on Samsung S5PV210 SOC).
Signed-off-by: Paweł Chmiel
---
This patch adds optional regulators, which can be used to power
up touchscreen. After enabling regulators, we need to wait 150msec.
This value is taken from official driver.
It was tested on Samsung Galaxy i9000 (based on Samsung S5PV210 SOC).
Signed-off-by: Paweł Chmiel
---
Document new optional voltage regulators, which can be used
to power down/up touchscreen.
Signed-off-by: Paweł Chmiel
---
Documentation/devicetree/bindings/input/atmel,maxtouch.txt | 8
1 file changed, 8 insertions(+)
diff --git
Document new optional voltage regulators, which can be used
to power down/up touchscreen.
Signed-off-by: Paweł Chmiel
---
Documentation/devicetree/bindings/input/atmel,maxtouch.txt | 8
1 file changed, 8 insertions(+)
diff --git
This two patches add optional regulator support to atmel_mxt_ts.
First patch adds regulators to driver.
Second patch updates documentation.
Paweł Chmiel (2):
Input: atmel_mxt_ts: Add support for optional regulators.
Input: atmel_mxt_ts: Document optional voltage regulators
This two patches add optional regulator support to atmel_mxt_ts.
First patch adds regulators to driver.
Second patch updates documentation.
Paweł Chmiel (2):
Input: atmel_mxt_ts: Add support for optional regulators.
Input: atmel_mxt_ts: Document optional voltage regulators
Linus,
Please pull the latest core-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
core-urgent-for-linus
# HEAD: 8a46580128a02bdc18d7dcc0cba19d3cea4fb9c4 rseq/selftests: cleanup:
Update comment above rseq_prepare_unload
Various rseq ABI fixes
Linus,
Please pull the latest core-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
core-urgent-for-linus
# HEAD: 8a46580128a02bdc18d7dcc0cba19d3cea4fb9c4 rseq/selftests: cleanup:
Update comment above rseq_prepare_unload
Various rseq ABI fixes
Hi Jisheng,
I love your patch! Yet something to improve:
[auto build test ERROR on pinctrl/devel]
[also build test ERROR on v4.18-rc4 next-20180713]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Hi Jisheng,
I love your patch! Yet something to improve:
[auto build test ERROR on pinctrl/devel]
[also build test ERROR on v4.18-rc4 next-20180713]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
On Fri, Jul 13, 2018 at 10:22 AM Jae Hyun Yoo
wrote:
>
> On 7/12/2018 11:21 AM, Jae Hyun Yoo wrote:
> > On 7/12/2018 2:33 AM, Brendan Higgins wrote:
> >> On Wed, Jun 27, 2018 at 10:55 AM Jae Hyun Yoo
> >> wrote:
> >>
> > + for (;;) {
> > + if (!(readl(bus->base +
On Fri, Jul 13, 2018 at 10:22 AM Jae Hyun Yoo
wrote:
>
> On 7/12/2018 11:21 AM, Jae Hyun Yoo wrote:
> > On 7/12/2018 2:33 AM, Brendan Higgins wrote:
> >> On Wed, Jun 27, 2018 at 10:55 AM Jae Hyun Yoo
> >> wrote:
> >>
> > + for (;;) {
> > + if (!(readl(bus->base +
Remove custom is_multicast_mac_addr() and is_broadcast_mac_addr().
Use is_multicast_ether_addr() instead.
By definition the broadcast address is also a multicast address.
is_multicast_ether_addr() returns true for broadcast addresses.
Hence checking for multicast in the conditional is sufficient.
Remove custom is_multicast_mac_addr() and is_broadcast_mac_addr().
Use is_multicast_ether_addr() instead.
By definition the broadcast address is also a multicast address.
is_multicast_ether_addr() returns true for broadcast addresses.
Hence checking for multicast in the conditional is sufficient.
On Thu, Jul 12, 2018 at 11:21 AM Jae Hyun Yoo
wrote:
>
> On 7/12/2018 2:33 AM, Brendan Higgins wrote:
> > On Wed, Jun 27, 2018 at 10:55 AM Jae Hyun Yoo
> > wrote:
> >>
> >
> +/* Timeout for bus busy checking */
> +#define BUS_BUSY_CHECK_TIMEOUT 25 /* 250ms
On Thu, Jul 12, 2018 at 11:21 AM Jae Hyun Yoo
wrote:
>
> On 7/12/2018 2:33 AM, Brendan Higgins wrote:
> > On Wed, Jun 27, 2018 at 10:55 AM Jae Hyun Yoo
> > wrote:
> >>
> >
> +/* Timeout for bus busy checking */
> +#define BUS_BUSY_CHECK_TIMEOUT 25 /* 250ms
On Fri, Jul 13, 2018 at 4:58 AM, Anson Huang wrote:
> Enable SEIKO 43WVF1G lcdif panel for DRM driver,
> add necessary properties according to SEIKO 43WVF1G
> driver's requirement, such as "dvdd-supply", "avdd-supply"
> and "backlight" etc..
>
> Signed-off-by: Anson Huang
Reviewed-by: Fabio
On Fri, Jul 13, 2018 at 4:58 AM, Anson Huang wrote:
> Enable SEIKO 43WVF1G lcdif panel for DRM driver,
> add necessary properties according to SEIKO 43WVF1G
> driver's requirement, such as "dvdd-supply", "avdd-supply"
> and "backlight" etc..
>
> Signed-off-by: Anson Huang
Reviewed-by: Fabio
On Fri, Jul 13, 2018 at 4:58 AM, Anson Huang wrote:
> On i.MX6SLL EVK board, lcd regulator is controlled
> by GPIO4 IO03 using MX6SLL_PAD_KEY_ROW5__GPIO4_IO03 pin,
> NOT MX6SLL_PAD_ECSPI1_SCLK__GPIO4_IO08, correct it.
>
> Signed-off-by: Anson Huang
Reviewed-by: Fabio Estevam
On Fri, Jul 13, 2018 at 4:58 AM, Anson Huang wrote:
> On i.MX6SLL EVK board, lcd regulator is controlled
> by GPIO4 IO03 using MX6SLL_PAD_KEY_ROW5__GPIO4_IO03 pin,
> NOT MX6SLL_PAD_ECSPI1_SCLK__GPIO4_IO08, correct it.
>
> Signed-off-by: Anson Huang
Reviewed-by: Fabio Estevam
Hi Anson,
On Fri, Jul 13, 2018 at 4:55 AM, Anson Huang wrote:
> On i.MX6SL EVK board, the MX6SL_PAD_KEY_ROW5 pin is
> used as lcd 3v3 regulator control pin, need to make
> sure MX6SL_PAD_KEY_ROW5 is muxed as GPIO function
> for controlling lcd 3v3 regulator.
>
> Signed-off-by: Anson Huang
> ---
Hi Anson,
On Fri, Jul 13, 2018 at 4:55 AM, Anson Huang wrote:
> On i.MX6SL EVK board, the MX6SL_PAD_KEY_ROW5 pin is
> used as lcd 3v3 regulator control pin, need to make
> sure MX6SL_PAD_KEY_ROW5 is muxed as GPIO function
> for controlling lcd 3v3 regulator.
>
> Signed-off-by: Anson Huang
> ---
On Fri, Jul 13, 2018 at 4:58 AM, 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
Reviewed-by: Fabio Estevam
On Fri, Jul 13, 2018 at 4:58 AM, 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
Reviewed-by: Fabio Estevam
On Fri, Jul 13, 2018 at 4:11 AM, Linus Walleij wrote:
> On Tue, Jul 10, 2018 at 9:53 AM Anson Huang wrote:
>
>> GPIO registers could lose context on some i.MX SoCs,
>> like on i.MX7D, when enter LPSR mode, the whole SoC
>> will be powered off except LPSR domain, GPIO banks
>> will lose context
On Fri, Jul 13, 2018 at 4:11 AM, Linus Walleij wrote:
> On Tue, Jul 10, 2018 at 9:53 AM Anson Huang wrote:
>
>> GPIO registers could lose context on some i.MX SoCs,
>> like on i.MX7D, when enter LPSR mode, the whole SoC
>> will be powered off except LPSR domain, GPIO banks
>> will lose context
On Fri, Jul 13, 2018 at 2:30 PM, Andrey Smirnov
wrote:
> It looks like I made a nasty typo in the original patch which resulted
> in missing watchdog device. Fix it.
>
> Cc: Fabio Estevam
> Cc: Nikita Yushchenko
> Cc: Lucas Stach
> Cc: cphe...@gmail.com
> Cc: Shawn Guo
> Cc: Rob Herring
>
On Fri, Jul 13, 2018 at 2:30 PM, Andrey Smirnov
wrote:
> It looks like I made a nasty typo in the original patch which resulted
> in missing watchdog device. Fix it.
>
> Cc: Fabio Estevam
> Cc: Nikita Yushchenko
> Cc: Lucas Stach
> Cc: cphe...@gmail.com
> Cc: Shawn Guo
> Cc: Rob Herring
>
On Fri, Jul 13, 2018 at 2:30 PM, Andrey Smirnov
wrote:
> Instead of relying on default values, configure PAD_AUD3_BB_CK to be a
> GPIO explicitly. While at, it change the pad configuration to enable
> a 100K pull-down (the pin is used as IRQ_TYPE_LEVEL_HIGH).
>
> Cc: Fabio Estevam
> Cc: Nikita
For the ARM64 simd locking it would be easier to have local_lock_bh()
which grabs a local_lock with BH disabled and turns into a
local_bh_disable() on !RT.
Signed-off-by: Sebastian Andrzej Siewior
---
obviously required by the previous one…
include/linux/locallock.h | 33
On Fri, Jul 13, 2018 at 2:30 PM, Andrey Smirnov
wrote:
> Instead of relying on default values, configure PAD_AUD3_BB_CK to be a
> GPIO explicitly. While at, it change the pad configuration to enable
> a 100K pull-down (the pin is used as IRQ_TYPE_LEVEL_HIGH).
>
> Cc: Fabio Estevam
> Cc: Nikita
For the ARM64 simd locking it would be easier to have local_lock_bh()
which grabs a local_lock with BH disabled and turns into a
local_bh_disable() on !RT.
Signed-off-by: Sebastian Andrzej Siewior
---
obviously required by the previous one…
include/linux/locallock.h | 33
In v4.16-RT I noticed a number of warnings from task_fpsimd_load(). The
code disables BH and expects that it is not preemptible. On -RT the
task remains preemptible but remains the same CPU. This may corrupt the
content of the SIMD registers if the task is preempted during
saving/restoring those
In v4.16-RT I noticed a number of warnings from task_fpsimd_load(). The
code disables BH and expects that it is not preemptible. On -RT the
task remains preemptible but remains the same CPU. This may corrupt the
content of the SIMD registers if the task is preempted during
saving/restoring those
For now, that's arch/x86/boot/compressed/vmlinux.bin.zst but probably more
will come, thus let's be consistent with all other compressors.
Signed-off-by: Adam Borowski
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 97ba6b79834c..0d09cf1c053c
For now, that's arch/x86/boot/compressed/vmlinux.bin.zst but probably more
will come, thus let's be consistent with all other compressors.
Signed-off-by: Adam Borowski
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 97ba6b79834c..0d09cf1c053c
Shawn:
Here's a couple of fixes for things I missed in the
[original-submission]. Sorry about the inconvenience.
Changes since [v1]:
- Reword commit message for patch 2/2
Thanks,
Andrey Smirnov
[v1] lkml.kernel.org/r/20180712023337.30112-1-andrew.smir...@gmail.com
[original-submission]
Shawn:
Here's a couple of fixes for things I missed in the
[original-submission]. Sorry about the inconvenience.
Changes since [v1]:
- Reword commit message for patch 2/2
Thanks,
Andrey Smirnov
[v1] lkml.kernel.org/r/20180712023337.30112-1-andrew.smir...@gmail.com
[original-submission]
201 - 300 of 944 matches
Mail list logo
