Hi Sebastian,
On 31 August 2018 at 05:27, Sebastian Reichel wrote:
> Hi,
>
> On Thu, Aug 30, 2018 at 11:08:59AM +0800, Baolin Wang wrote:
>> >> +static int sc2731_charger_hw_init(struct sc2731_charger_info *info)
>> >> +{
>> >> + int ret;
>> >> +
>> >> + /* Enable charger module */
Hi Sebastian,
On 31 August 2018 at 05:27, Sebastian Reichel wrote:
> Hi,
>
> On Thu, Aug 30, 2018 at 11:08:59AM +0800, Baolin Wang wrote:
>> >> +static int sc2731_charger_hw_init(struct sc2731_charger_info *info)
>> >> +{
>> >> + int ret;
>> >> +
>> >> + /* Enable charger module */
On Thu, Aug 30, 2018 at 09:11:11AM -0700, Atish Patra wrote:
> On 8/30/18 7:41 AM, Christoph Hellwig wrote:
> > > struct device_node *dn = NULL;
> > > - int hart, im_okay_therefore_i_am = 0;
> > > + int hart, found_boot_cpu = 0;
> >
> > If you rename this anyway please switch to use a
On Thu, Aug 30, 2018 at 09:11:11AM -0700, Atish Patra wrote:
> On 8/30/18 7:41 AM, Christoph Hellwig wrote:
> > > struct device_node *dn = NULL;
> > > - int hart, im_okay_therefore_i_am = 0;
> > > + int hart, found_boot_cpu = 0;
> >
> > If you rename this anyway please switch to use a
Hi Jacek,
On 31 August 2018 at 03:55, Jacek Anaszewski wrote:
> Hi Baolin,
>
> On 08/30/2018 09:40 AM, Baolin Wang wrote:
>> Some LED controllers have support for autonomously controlling
>> brightness over time, according to some preprogrammed pattern or
>> function.
>
> I think that this
Hi Jacek,
On 31 August 2018 at 03:55, Jacek Anaszewski wrote:
> Hi Baolin,
>
> On 08/30/2018 09:40 AM, Baolin Wang wrote:
>> Some LED controllers have support for autonomously controlling
>> brightness over time, according to some preprogrammed pattern or
>> function.
>
> I think that this
This patch introduces the managed version of clk_bulk_get_all.
Cc: Michael Turquette
Cc: Stephen Boyd
Tested-by: Thor Thayer
Signed-off-by: Dong Aisheng
---
v3->v4:
* improve 'devres->clks = *clks' according to Stephen's suggestion
v2->v3:
* a minor fix of build warning on PowerPC platform.
This patch introduces the managed version of clk_bulk_get_all.
Cc: Michael Turquette
Cc: Stephen Boyd
Tested-by: Thor Thayer
Signed-off-by: Dong Aisheng
---
v3->v4:
* improve 'devres->clks = *clks' according to Stephen's suggestion
v2->v3:
* a minor fix of build warning on PowerPC platform.
This patch introduces of_clk_bulk_get_all and clk_bulk_x_all APIs
to users who just want to handle all available clocks from device tree
without need to know the detailed clock information likes clock numbers
and names. This is useful in writing some generic drivers to handle clock
part.
Cc:
On Fri, 2018-08-31 at 14:35 +1000, Benjamin Herrenschmidt wrote:
>
> > If I force output with "-f", the resulting file has no occurrences
> > of "phandle".
>
> Are you booting with BootX or Open Firmware ?
Assuming you are using BootX (or miBoot), can you try this patch ?
---
This patch introduces of_clk_bulk_get_all and clk_bulk_x_all APIs
to users who just want to handle all available clocks from device tree
without need to know the detailed clock information likes clock numbers
and names. This is useful in writing some generic drivers to handle clock
part.
Cc:
On Fri, 2018-08-31 at 14:35 +1000, Benjamin Herrenschmidt wrote:
>
> > If I force output with "-f", the resulting file has no occurrences
> > of "phandle".
>
> Are you booting with BootX or Open Firmware ?
Assuming you are using BootX (or miBoot), can you try this patch ?
---
Switching to use clk_bulk API to simplify clock operations.
Cc: Hans de Goede
Cc: Bartlomiej Zolnierkiewicz
Cc: linux-fb...@vger.kernel.org
Cc: Masahiro Yamada
Cc: Stephen Boyd
Tested-by: Thor Thayer
Signed-off-by: Dong Aisheng
---
v5->v6:
* address Hans's comments
v4->v5:
* fix wrong
Switching to use clk_bulk API to simplify clock operations.
Cc: Hans de Goede
Cc: Bartlomiej Zolnierkiewicz
Cc: linux-fb...@vger.kernel.org
Cc: Masahiro Yamada
Cc: Stephen Boyd
Tested-by: Thor Thayer
Signed-off-by: Dong Aisheng
---
v5->v6:
* address Hans's comments
v4->v5:
* fix wrong
This patch series is a continue of discussion from here,
https://patchwork.kernel.org/patch/9986293/
that some users may want to handle all available clocks from device
tree without need to know the detailed clock information likes clock
numbers and names. This is useful in writing some generic
'clock-names' property is optional in DT, so of_clk_bulk_get() is
introduced here to handle this for DT users without 'clock-names'
specified. Later clk_bulk_get_all() will be implemented on top of
it and this API will be kept private until someone proves they need
it because they don't have a
On Fri, 31 Aug 2018 13:46:35 +0900
Masami Hiramatsu wrote:
> On Thu, 30 Aug 2018 10:32:12 -0700
> Nadav Amit wrote:
>
> > This patch-set addresses some issues that were raised in a recent
> > correspondence and might affect the security and the correctness of code
> > patching. (Note that
This patch series is a continue of discussion from here,
https://patchwork.kernel.org/patch/9986293/
that some users may want to handle all available clocks from device
tree without need to know the detailed clock information likes clock
numbers and names. This is useful in writing some generic
'clock-names' property is optional in DT, so of_clk_bulk_get() is
introduced here to handle this for DT users without 'clock-names'
specified. Later clk_bulk_get_all() will be implemented on top of
it and this API will be kept private until someone proves they need
it because they don't have a
On Fri, 31 Aug 2018 13:46:35 +0900
Masami Hiramatsu wrote:
> On Thu, 30 Aug 2018 10:32:12 -0700
> Nadav Amit wrote:
>
> > This patch-set addresses some issues that were raised in a recent
> > correspondence and might affect the security and the correctness of code
> > patching. (Note that
On Thu, 30 Aug 2018 10:32:12 -0700
Nadav Amit wrote:
> This patch-set addresses some issues that were raised in a recent
> correspondence and might affect the security and the correctness of code
> patching. (Note that patching performance is not addressed by this
> patch-set).
>
> The main
On Thu, 30 Aug 2018 10:32:12 -0700
Nadav Amit wrote:
> This patch-set addresses some issues that were raised in a recent
> correspondence and might affect the security and the correctness of code
> patching. (Note that patching performance is not addressed by this
> patch-set).
>
> The main
On Wed, 29 Aug 2018 18:59:52 -0700
Andy Lutomirski wrote:
>
>
> > On Aug 29, 2018, at 6:38 PM, Masami Hiramatsu wrote:
> >
> > On Wed, 29 Aug 2018 08:41:00 -0700
> > Andy Lutomirski wrote:
> >
> >>> On Wed, Aug 29, 2018 at 2:49 AM, Masami Hiramatsu
> >>> wrote:
> >>> On Wed, 29 Aug 2018
On Wed, 29 Aug 2018 18:59:52 -0700
Andy Lutomirski wrote:
>
>
> > On Aug 29, 2018, at 6:38 PM, Masami Hiramatsu wrote:
> >
> > On Wed, 29 Aug 2018 08:41:00 -0700
> > Andy Lutomirski wrote:
> >
> >>> On Wed, Aug 29, 2018 at 2:49 AM, Masami Hiramatsu
> >>> wrote:
> >>> On Wed, 29 Aug 2018
On Thu, Aug 30, 2018 at 6:49 PM Tony Luck wrote:
>
> Just checking "do we have a non-canonical address" at the bottom of that
> call stack and flipping bit 63 back on again seems like a bad idea.
You could literally do something like
/* Make it canonical in case we flipped the high bit */
On Thu, Aug 30, 2018 at 6:49 PM Tony Luck wrote:
>
> Just checking "do we have a non-canonical address" at the bottom of that
> call stack and flipping bit 63 back on again seems like a bad idea.
You could literally do something like
/* Make it canonical in case we flipped the high bit */
> > I am seeing userland corruption and application crashes on multiple
> > 32-bit machines with 4.19-rc1+git. The machines vary: PII, PIII, P4.
> > They are all Intel. AMD Duron/Athlon/AthlonMP have been fine in my tests
> > so far (may be configuration dependent).
>
> Thanks for the report!
> > I am seeing userland corruption and application crashes on multiple
> > 32-bit machines with 4.19-rc1+git. The machines vary: PII, PIII, P4.
> > They are all Intel. AMD Duron/Athlon/AthlonMP have been fine in my tests
> > so far (may be configuration dependent).
>
> Thanks for the report!
On Thu 30 Aug 20:57 PDT 2018, Frank Rowand wrote:
> Hi Bjorn,
>
>
> On 04/19/18 18:17, Bjorn Andersson wrote:
> > Attempt to acquire the APCS IPC through the mailbox framework and fall
> > back to the old syscon based approach, to allow us to move away from
> > using the syscon.
> >
> >
On Thu 30 Aug 20:57 PDT 2018, Frank Rowand wrote:
> Hi Bjorn,
>
>
> On 04/19/18 18:17, Bjorn Andersson wrote:
> > Attempt to acquire the APCS IPC through the mailbox framework and fall
> > back to the old syscon based approach, to allow us to move away from
> > using the syscon.
> >
> >
On 08/30/18 20:57, Frank Rowand wrote:
> Hi Bjorn,
>
>
> On 04/19/18 18:17, Bjorn Andersson wrote:
>> Attempt to acquire the APCS IPC through the mailbox framework and fall
>> back to the old syscon based approach, to allow us to move away from
>> using the syscon.
>>
>> Reviewed-by: Arun Kumar
On 08/30/18 20:57, Frank Rowand wrote:
> Hi Bjorn,
>
>
> On 04/19/18 18:17, Bjorn Andersson wrote:
>> Attempt to acquire the APCS IPC through the mailbox framework and fall
>> back to the old syscon based approach, to allow us to move away from
>> using the syscon.
>>
>> Reviewed-by: Arun Kumar
On 08/30/18 20:57, Frank Rowand wrote:
> Hi Bjorn,
>
>
> On 04/19/18 18:17, Bjorn Andersson wrote:
>> Attempt to acquire the APCS IPC through the mailbox framework and fall
>> back to the old syscon based approach, to allow us to move away from
>> using the syscon.
>>
>> Reviewed-by: Arun Kumar
On 08/30/18 20:57, Frank Rowand wrote:
> Hi Bjorn,
>
>
> On 04/19/18 18:17, Bjorn Andersson wrote:
>> Attempt to acquire the APCS IPC through the mailbox framework and fall
>> back to the old syscon based approach, to allow us to move away from
>> using the syscon.
>>
>> Reviewed-by: Arun Kumar
Hi Bjorn,
On 04/19/18 18:17, Bjorn Andersson wrote:
> Attempt to acquire the APCS IPC through the mailbox framework and fall
> back to the old syscon based approach, to allow us to move away from
> using the syscon.
>
> Reviewed-by: Arun Kumar Neelakantam
> Signed-off-by: Bjorn Andersson
>
Hi Bjorn,
On 04/19/18 18:17, Bjorn Andersson wrote:
> Attempt to acquire the APCS IPC through the mailbox framework and fall
> back to the old syscon based approach, to allow us to move away from
> using the syscon.
>
> Reviewed-by: Arun Kumar Neelakantam
> Signed-off-by: Bjorn Andersson
>
On Tue, 28 Aug 2018 15:00:14 +
Matteo Croce wrote:
> On Tue, Aug 28, 2018 at 2:35 PM Nicholas Piggin wrote:
> >
> > On Tue, 28 Aug 2018 12:54:08 +
> > Matteo Croce wrote:
> >
> > > With kernel 4.19.0-rc1 virtio_console hangs very often.
> > > I can always trigger the bug by pasting
On Tue, 28 Aug 2018 15:00:14 +
Matteo Croce wrote:
> On Tue, Aug 28, 2018 at 2:35 PM Nicholas Piggin wrote:
> >
> > On Tue, 28 Aug 2018 12:54:08 +
> > Matteo Croce wrote:
> >
> > > With kernel 4.19.0-rc1 virtio_console hangs very often.
> > > I can always trigger the bug by pasting
Hi Vineet,
Commit
c0a7bc6e5585 ("ARC: atomics: unbork atomic_fetch_##op()")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
pgp8axos1HTI4.pgp
Description: OpenPGP digital signature
On 03/08/2017 04:19 PM, Dinh Nguyen wrote:
>
>
> On 02/28/2017 09:52 AM, Florian Vaussard wrote:
>> Hi,
>>
>> These patches add suport for ARM Performance Monitor Units on Arria5 and
>> Cyclone5 SoCFPGA. This was tested on a Cyclone 5 SoC DK board.
>>
>> Side note: the same change can be
Hi Vineet,
Commit
c0a7bc6e5585 ("ARC: atomics: unbork atomic_fetch_##op()")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
pgp8axos1HTI4.pgp
Description: OpenPGP digital signature
On 03/08/2017 04:19 PM, Dinh Nguyen wrote:
>
>
> On 02/28/2017 09:52 AM, Florian Vaussard wrote:
>> Hi,
>>
>> These patches add suport for ARM Performance Monitor Units on Arria5 and
>> Cyclone5 SoCFPGA. This was tested on a Cyclone 5 SoC DK board.
>>
>> Side note: the same change can be
On Wed 29 Aug 02:25 PDT 2018, Niklas Cassel wrote:
> On Mon, Aug 27, 2018 at 10:12:03PM -0700, Bjorn Andersson wrote:
> > The Hexagon v5 ADSP driver is used for more than only the ADSP and
> > there's an upcoming non-PAS ADSP PIL for SDM845, so rename the driver to
> > qcom_q6v5_pas in order to
On Wed 29 Aug 02:25 PDT 2018, Niklas Cassel wrote:
> On Mon, Aug 27, 2018 at 10:12:03PM -0700, Bjorn Andersson wrote:
> > The Hexagon v5 ADSP driver is used for more than only the ADSP and
> > there's an upcoming non-PAS ADSP PIL for SDM845, so rename the driver to
> > qcom_q6v5_pas in order to
> On Aug 30, 2018, at 7:38 PM, Jann Horn wrote:
>
>> On Tue, 7 Aug 2018 Dave Hansen wrote:
>>
>>> On 08/07/2018 10:29 AM, Sean Christopherson wrote:
>>> if (unlikely(fault_in_kernel_space(address))) {
>>> + /*
>>> + * We should never encounter a protection keys
> On Aug 30, 2018, at 7:38 PM, Jann Horn wrote:
>
>> On Tue, 7 Aug 2018 Dave Hansen wrote:
>>
>>> On 08/07/2018 10:29 AM, Sean Christopherson wrote:
>>> if (unlikely(fault_in_kernel_space(address))) {
>>> + /*
>>> + * We should never encounter a protection keys
Hi all,
Changes since 20180830:
Dropped trees: xarray, ida (temporarily)
Non-merge commits (relative to Linus' tree): 1248
1497 files changed, 48772 insertions(+), 16144 deletions(-)
I have created today's linux
Hi all,
Changes since 20180830:
Dropped trees: xarray, ida (temporarily)
Non-merge commits (relative to Linus' tree): 1248
1497 files changed, 48772 insertions(+), 16144 deletions(-)
I have created today's linux
On Wed, Aug 29, 2018 at 11:16:30AM -0400, Masayoshi Mizuma wrote:
> Hi Horiguchi-san and Pavel
>
> Thank you for your comments!
> The Pavel's additional patch looks good to me, so I will add it to this
> series.
>
> However, unfortunately, the movable_node option has something wrong yet...
>
On Wed, Aug 29, 2018 at 11:16:30AM -0400, Masayoshi Mizuma wrote:
> Hi Horiguchi-san and Pavel
>
> Thank you for your comments!
> The Pavel's additional patch looks good to me, so I will add it to this
> series.
>
> However, unfortunately, the movable_node option has something wrong yet...
>
Hi Alexei,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 217c3e0196758662aa0429863b09d1c13da1c5d6
commit: 819dd92b9c0bc7bce9097d8c1f14240f471bb386 bpfilter: switch to CC from
HOSTCC
date: 3 months ago
config:
Hi Alexei,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 217c3e0196758662aa0429863b09d1c13da1c5d6
commit: 819dd92b9c0bc7bce9097d8c1f14240f471bb386 bpfilter: switch to CC from
HOSTCC
date: 3 months ago
config:
On Tue, 7 Aug 2018 Dave Hansen wrote:
>
> On 08/07/2018 10:29 AM, Sean Christopherson wrote:
> > if (unlikely(fault_in_kernel_space(address))) {
> > + /*
> > + * We should never encounter a protection keys fault on a
> > + * kernel address as kernel
On Tue, 7 Aug 2018 Dave Hansen wrote:
>
> On 08/07/2018 10:29 AM, Sean Christopherson wrote:
> > if (unlikely(fault_in_kernel_space(address))) {
> > + /*
> > + * We should never encounter a protection keys fault on a
> > + * kernel address as kernel
Dear Sir:
Good day
Simon greeting from Everbright international logistics co.,ltd,and we
specialize in overseas international logistics for 15 years,our major core
business scope cover:
International sea freight
International air freight
International courier service
Local logistics
Dear Sir:
Good day
Simon greeting from Everbright international logistics co.,ltd,and we
specialize in overseas international logistics for 15 years,our major core
business scope cover:
International sea freight
International air freight
International courier service
Local logistics
On Thu, Aug 30, 2018 at 02:10:32PM -0400, Steven Rostedt wrote:
> On Wed, 29 Aug 2018 15:20:29 -0700
> "Paul E. McKenney" wrote:
>
> > This commit also changes order of execution from this:
> >
> > rcu_dynticks_task_exit();
> > rcu_dynticks_eqs_exit();
> > trace_rcu_dyntick();
> >
On Thu, Aug 30, 2018 at 02:10:32PM -0400, Steven Rostedt wrote:
> On Wed, 29 Aug 2018 15:20:29 -0700
> "Paul E. McKenney" wrote:
>
> > This commit also changes order of execution from this:
> >
> > rcu_dynticks_task_exit();
> > rcu_dynticks_eqs_exit();
> > trace_rcu_dyntick();
> >
On Fri, Aug 31, 2018 at 01:34:26AM +0300, Igor Stoppa wrote:
> WARN_ON() already contains an unlikely(), so it's not necessary to
> wrap it into another.
>
> Signed-off-by: Igor Stoppa
> Cc: zijun_hu
> Cc: Tejun Heo
> Cc: Christoph Lameter
> Cc: Dennis Zhou
> ---
> mm/percpu.c | 2 +-
> 1
On Fri, Aug 31, 2018 at 01:34:26AM +0300, Igor Stoppa wrote:
> WARN_ON() already contains an unlikely(), so it's not necessary to
> wrap it into another.
>
> Signed-off-by: Igor Stoppa
> Cc: zijun_hu
> Cc: Tejun Heo
> Cc: Christoph Lameter
> Cc: Dennis Zhou
> ---
> mm/percpu.c | 2 +-
> 1
On Thu, Aug 30, 2018 at 6:30 PM Linus Torvalds
wrote:
>
> On Thu, Aug 30, 2018 at 2:45 PM Tony Luck wrote:
> >
> > Fix is to move one step at a time. First mark the page not present
> > (using the decoy address). Then it is safe to use the actual address
> > of the 1:1 mapping to mark it "uc",
On Thu, Aug 30, 2018 at 6:30 PM Linus Torvalds
wrote:
>
> On Thu, Aug 30, 2018 at 2:45 PM Tony Luck wrote:
> >
> > Fix is to move one step at a time. First mark the page not present
> > (using the decoy address). Then it is safe to use the actual address
> > of the 1:1 mapping to mark it "uc",
On 2018/8/30 21:59, Rob Herring wrote:
> On Thu, Aug 30, 2018 at 2:37 AM Hanjie Lin wrote:
>>
>>
>>
>> On 2018/8/29 8:41, Rob Herring wrote:
>>> On Mon, Aug 27, 2018 at 04:55:20PM +0800, Hanjie Lin wrote:
On 2018/8/24 16:22, Jerome Brunet wrote:
> On Fri, 2018-08-24 at 15:36
On 2018/8/30 21:59, Rob Herring wrote:
> On Thu, Aug 30, 2018 at 2:37 AM Hanjie Lin wrote:
>>
>>
>>
>> On 2018/8/29 8:41, Rob Herring wrote:
>>> On Mon, Aug 27, 2018 at 04:55:20PM +0800, Hanjie Lin wrote:
On 2018/8/24 16:22, Jerome Brunet wrote:
> On Fri, 2018-08-24 at 15:36
Hi, Stephen
Anson Huang
Best Regards!
> -Original Message-
> From: Stephen Boyd
> Sent: Friday, August 31, 2018 9:29 AM
> To: ker...@pengutronix.de; linux-arm-ker...@lists.infradead.org;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> mturque...@baylibre.com;
Hi, Stephen
Anson Huang
Best Regards!
> -Original Message-
> From: Stephen Boyd
> Sent: Friday, August 31, 2018 9:29 AM
> To: ker...@pengutronix.de; linux-arm-ker...@lists.infradead.org;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> mturque...@baylibre.com;
On 08/30/2018 05:41 PM, Greg Kroah-Hartman wrote:
On Thu, Aug 30, 2018 at 04:09:46PM -0700, Daniel Rosenberg wrote:
This patch is against 4.9. It does not apply to master due to a large
rework of ion in 4.12 which removed the affected functions altogther.
4c23cbff073f3b9b ("staging: android:
On 08/30/2018 05:41 PM, Greg Kroah-Hartman wrote:
On Thu, Aug 30, 2018 at 04:09:46PM -0700, Daniel Rosenberg wrote:
This patch is against 4.9. It does not apply to master due to a large
rework of ion in 4.12 which removed the affected functions altogther.
4c23cbff073f3b9b ("staging: android:
Hello,
syzbot found the following crash on:
HEAD commit:3f16503b7d22 Merge branch 'fixes' of git://git.kernel.org/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16c7df6a40
kernel config: https://syzkaller.appspot.com/x/.config?x=49927b422dcf0b29
Hello,
syzbot found the following crash on:
HEAD commit:3f16503b7d22 Merge branch 'fixes' of git://git.kernel.org/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16c7df6a40
kernel config: https://syzkaller.appspot.com/x/.config?x=49927b422dcf0b29
Quoting Colin King (2018-08-06 06:44:02)
> From: Colin Ian King
>
> Array audio_parents is declared but never used, hence it is redundant
> and can be removed.
>
> Cleans up clang warning:
> warning: 'audio_parents' defined but not used [-Wunused-const-variable=]
>
> Signed-off-by: Colin Ian
Quoting Colin King (2018-08-06 06:44:02)
> From: Colin Ian King
>
> Array audio_parents is declared but never used, hence it is redundant
> and can be removed.
>
> Cleans up clang warning:
> warning: 'audio_parents' defined but not used [-Wunused-const-variable=]
>
> Signed-off-by: Colin Ian
Quoting Peng Fan (2018-08-12 18:15:41)
> Hi Anson,
>
> > > > -Original Message-
> > > > From: Anson Huang
> > > > Sent: 2018年8月8日 12:39
> > > > To: shawn...@kernel.org; s.ha...@pengutronix.de;
> > > > ker...@pengutronix.de; Fabio Estevam ;
> > > > mturque...@baylibre.com;
On Thu, Aug 30, 2018 at 2:45 PM Tony Luck wrote:
>
> Fix is to move one step at a time. First mark the page not present
> (using the decoy address). Then it is safe to use the actual address
> of the 1:1 mapping to mark it "uc", and finally as present.
Can't we do it in one step, but make sure
Quoting Peng Fan (2018-08-12 18:15:41)
> Hi Anson,
>
> > > > -Original Message-
> > > > From: Anson Huang
> > > > Sent: 2018年8月8日 12:39
> > > > To: shawn...@kernel.org; s.ha...@pengutronix.de;
> > > > ker...@pengutronix.de; Fabio Estevam ;
> > > > mturque...@baylibre.com;
On Thu, Aug 30, 2018 at 2:45 PM Tony Luck wrote:
>
> Fix is to move one step at a time. First mark the page not present
> (using the decoy address). Then it is safe to use the actual address
> of the 1:1 mapping to mark it "uc", and finally as present.
Can't we do it in one step, but make sure
Quoting Amit Nischal (2018-08-08 03:47:19)
> Add support for the camera clock controller found on SDM845
> based devices. This would allow camera drivers to probe and
> control their clocks.
>
> Signed-off-by: Amit Nischal
> ---
Applied to clk-next
Quoting Amit Nischal (2018-08-08 03:47:19)
> Add support for the camera clock controller found on SDM845
> based devices. This would allow camera drivers to probe and
> control their clocks.
>
> Signed-off-by: Amit Nischal
> ---
Applied to clk-next
On Mon, 2018-08-27 at 19:02 +1000, Nicholas Piggin wrote:
> > More tlbies ? With the cost of the broadasts on the fabric ? I don't
> > think so.. or I'm not understanding your point...
>
> More tlbies are no good, but there will be some places where it works
> out much better (and fewer tlbies).
On Mon, 2018-08-27 at 19:02 +1000, Nicholas Piggin wrote:
> > More tlbies ? With the cost of the broadasts on the fabric ? I don't
> > think so.. or I'm not understanding your point...
>
> More tlbies are no good, but there will be some places where it works
> out much better (and fewer tlbies).
On Thu, 30 Aug 2018 17:15:43 +0100
Will Deacon wrote:
> It is common for architectures with hugepage support to require only a
> single TLB invalidation operation per hugepage during unmap(), rather than
> iterating through the mapping at a PAGE_SIZE increment. Currently,
> however, the level in
On Thu, 30 Aug 2018 17:15:43 +0100
Will Deacon wrote:
> It is common for architectures with hugepage support to require only a
> single TLB invalidation operation per hugepage during unmap(), rather than
> iterating through the mapping at a PAGE_SIZE increment. Currently,
> however, the level in
On Thu 30 Aug 18:07 PDT 2018, Stephen Boyd wrote:
> Quoting Bjorn Andersson (2018-08-29 16:15:02)
> > We're currently facing the issue that every new platform requires the
> > addition
> > of a compatible to the DT binding as well as the driver.
> >
> > The DT binding patch to allow us to use
On Thu 30 Aug 18:07 PDT 2018, Stephen Boyd wrote:
> Quoting Bjorn Andersson (2018-08-29 16:15:02)
> > We're currently facing the issue that every new platform requires the
> > addition
> > of a compatible to the DT binding as well as the driver.
> >
> > The DT binding patch to allow us to use
On Thu, Aug 30, 2018 at 3:07 PM Stephen Rothwell wrote:
>
> I am now mainly using gcc v8.2 for my builds and -Wstringop-truncation
> causes so many warnings that I am sure to miss others, so I have
> applied the below to my fixes tree until the noise reduces.
Applied.
If people want the warning
On Thu, Aug 30, 2018 at 3:07 PM Stephen Rothwell wrote:
>
> I am now mainly using gcc v8.2 for my builds and -Wstringop-truncation
> causes so many warnings that I am sure to miss others, so I have
> applied the below to my fixes tree until the noise reduces.
Applied.
If people want the warning
On Thu 30 Aug 03:44 PDT 2018, Vivek Gautam wrote:
> On Thu, Aug 30, 2018 at 11:46 AM Bjorn Andersson
> wrote:
> >
> > On Tue 31 Jul 03:09 PDT 2018, Can Guo wrote:
> >
> > > This patch series adds support for UFS QMP PHY on SDM845 and the
> > > compatible string for it. This patch series depends
On Thu 30 Aug 03:44 PDT 2018, Vivek Gautam wrote:
> On Thu, Aug 30, 2018 at 11:46 AM Bjorn Andersson
> wrote:
> >
> > On Tue 31 Jul 03:09 PDT 2018, Can Guo wrote:
> >
> > > This patch series adds support for UFS QMP PHY on SDM845 and the
> > > compatible string for it. This patch series depends
Quoting Bjorn Andersson (2018-08-29 16:15:02)
> We're currently facing the issue that every new platform requires the addition
> of a compatible to the DT binding as well as the driver.
>
> The DT binding patch to allow us to use qcom,scm for all these new platforms
> that doesn't require any
Quoting Bjorn Andersson (2018-08-29 16:15:02)
> We're currently facing the issue that every new platform requires the addition
> of a compatible to the DT binding as well as the driver.
>
> The DT binding patch to allow us to use qcom,scm for all these new platforms
> that doesn't require any
Quoting Bjorn Andersson (2018-08-29 16:15:05)
> Now that the compatible/clock handling is reworked add compatibles for
> MSM8998 and SDM845 to the SCM binding.
>
> Signed-off-by: Bjorn Andersson
> ---
Reviewed-by: Stephen Boyd
Quoting Bjorn Andersson (2018-08-29 16:15:04)
> At one point in time all "future" platforms required three clocks, so
> the binding and driver was written to treat this as the default case.
> But new platforms has no clock requirements, which currently makes them
> all a special case, causing the
Quoting Bjorn Andersson (2018-08-29 16:15:03)
> When the binding was written all "future" platforms required three
> clocks, so the default compatible (qcom,scm) was defined to require
> this. But as history shows all "future" platforms actually lack required
> clocks. Given how the binding is
Quoting Bjorn Andersson (2018-08-29 16:15:05)
> Now that the compatible/clock handling is reworked add compatibles for
> MSM8998 and SDM845 to the SCM binding.
>
> Signed-off-by: Bjorn Andersson
> ---
Reviewed-by: Stephen Boyd
Quoting Bjorn Andersson (2018-08-29 16:15:04)
> At one point in time all "future" platforms required three clocks, so
> the binding and driver was written to treat this as the default case.
> But new platforms has no clock requirements, which currently makes them
> all a special case, causing the
Quoting Bjorn Andersson (2018-08-29 16:15:03)
> When the binding was written all "future" platforms required three
> clocks, so the default compatible (qcom,scm) was defined to require
> this. But as history shows all "future" platforms actually lack required
> clocks. Given how the binding is
On Thu, Aug 30, 2018 at 6:01 PM Nicholas Piggin wrote:
>
> Well it would help if powerpc say wanted to start using them without a
> merge cycle lag. Not a huge issue because powerpc already does
> reasonably well here and there's other work that can be done.
Sure. If somebody wants to send the
On Thu, Aug 30, 2018 at 6:01 PM Nicholas Piggin wrote:
>
> Well it would help if powerpc say wanted to start using them without a
> merge cycle lag. Not a huge issue because powerpc already does
> reasonably well here and there's other work that can be done.
Sure. If somebody wants to send the
On Thu, 30 Aug 2018 09:39:38 -0700
Linus Torvalds wrote:
> On Thu, Aug 30, 2018 at 9:15 AM Will Deacon wrote:
> >
> > It's also had a lot more testing, but has held up nicely so far on arm64.
> > I haven't figured out how to merge this yet, but I'll probably end up
> > pulling
> > the core
On Thu, 30 Aug 2018 09:39:38 -0700
Linus Torvalds wrote:
> On Thu, Aug 30, 2018 at 9:15 AM Will Deacon wrote:
> >
> > It's also had a lot more testing, but has held up nicely so far on arm64.
> > I haven't figured out how to merge this yet, but I'll probably end up
> > pulling
> > the core
1 - 100 of 1378 matches
Mail list logo
