On 30/05/18 17:43, Georgi Djakov wrote:
> Now we have a proper implementation for the power irq handling and this
> quirk is not needed anymore. In fact, it is causing card detection delays
> on apq8096 platforms and the following error is displayed:
> sdhci_msm 74a4900.sdhci: mmc0: pwr_irq for
Le 31/05/2018 à 07:54, Michael Ellerman a écrit :
Christophe LEROY writes:
Le 29/05/2018 à 11:05, Geert Uytterhoeven a écrit :
Hi Christophe,
On Tue, May 29, 2018 at 10:56 AM, Christophe LEROY
wrote:
Le 29/05/2018 à 09:47, Geert Uytterhoeven a écrit :
On Tue, May 29, 2018 at 8:03 AM,
On 30/05/18 17:43, Georgi Djakov wrote:
> Now we have a proper implementation for the power irq handling and this
> quirk is not needed anymore. In fact, it is causing card detection delays
> on apq8096 platforms and the following error is displayed:
> sdhci_msm 74a4900.sdhci: mmc0: pwr_irq for
Le 31/05/2018 à 07:54, Michael Ellerman a écrit :
Christophe LEROY writes:
Le 29/05/2018 à 11:05, Geert Uytterhoeven a écrit :
Hi Christophe,
On Tue, May 29, 2018 at 10:56 AM, Christophe LEROY
wrote:
Le 29/05/2018 à 09:47, Geert Uytterhoeven a écrit :
On Tue, May 29, 2018 at 8:03 AM,
Hi Olaf,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17-rc7]
[cannot apply to next-20180530]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
Hi Olaf,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17-rc7]
[cannot apply to next-20180530]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
eagle board x15
> https://bugs.linaro.org/show_bug.cgi?id=3863
This bug still happening on 4.17.0-rc7-next-20180530 on beagle board x15.
Linux version 4.17.0-rc7-next-20180530 (buildslave@x86-64-07) (gcc version
6.2.1 20161016 (Linaro GCC 6.2-2016.11)) #1 SMP Wed May 30 12:38:23 UTC 2018
- Naresh
eagle board x15
> https://bugs.linaro.org/show_bug.cgi?id=3863
This bug still happening on 4.17.0-rc7-next-20180530 on beagle board x15.
Linux version 4.17.0-rc7-next-20180530 (buildslave@x86-64-07) (gcc version
6.2.1 20161016 (Linaro GCC 6.2-2016.11)) #1 SMP Wed May 30 12:38:23 UTC 2018
- Naresh
On 5/31/2018 1:43 AM, Andi Kleen wrote:
On Wed, May 30, 2018 at 10:20:45PM +0800, Jin Yao wrote:
When doing pmu sampling and then running a script with
perf script -s script.py, the process_event function gets
dictionary with some fields from the perf ring buffer
(like ip, sym, callchain
On 5/31/2018 1:43 AM, Andi Kleen wrote:
On Wed, May 30, 2018 at 10:20:45PM +0800, Jin Yao wrote:
When doing pmu sampling and then running a script with
perf script -s script.py, the process_event function gets
dictionary with some fields from the perf ring buffer
(like ip, sym, callchain
Currently, DEVFREQ reevaluates the device state periodically and/or
based on the OPP list changes. Private API has to be exposed to allow
the device driver to alert/notify the governor to reevaluate when a new
set of data is available. This makes the governor more coupled to a
particular device
Currently, DEVFREQ reevaluates the device state periodically and/or
based on the OPP list changes. Private API has to be exposed to allow
the device driver to alert/notify the governor to reevaluate when a new
set of data is available. This makes the governor more coupled to a
particular device
On Wed, May 30 2018, Trond Myklebust wrote:
> Hi Stephen,
>
> Thanks for noticing and apologies for missing that. I'll take that
> patch out until Neil can update it.
>
Thanks for noticing that Stephen,
I've sent and updated version.
Thanks,
NeilBrown
> Cheers
> Trond
> On Wed, 30 May 2018
On Wed, May 30 2018, Trond Myklebust wrote:
> Hi Stephen,
>
> Thanks for noticing and apologies for missing that. I'll take that
> patch out until Neil can update it.
>
Thanks for noticing that Stephen,
I've sent and updated version.
Thanks,
NeilBrown
> Cheers
> Trond
> On Wed, 30 May 2018
There are 3 places where we walk the list of delegations
for an nfs_client.
In each case there are two nested loops, one for nfs_servers
and one for nfs_delegations.
When we find an interesting delegation we try to get an active
reference to the server. If that fails, it is pointless to
There are 3 places where we walk the list of delegations
for an nfs_client.
In each case there are two nested loops, one for nfs_servers
and one for nfs_delegations.
When we find an interesting delegation we try to get an active
reference to the server. If that fails, it is pointless to
On 30-05-18, 14:32, Krzysztof Kozlowski wrote:
> OK, I see the possibility although it is still far away from use
> cases. You cannot hotplug booting CPU (CPU0) on Exynos kernels. It
> never worked. Strictly speaking - offlining will work. But bringing it
> online will likely hang the system.
On 30-05-18, 14:32, Krzysztof Kozlowski wrote:
> OK, I see the possibility although it is still far away from use
> cases. You cannot hotplug booting CPU (CPU0) on Exynos kernels. It
> never worked. Strictly speaking - offlining will work. But bringing it
> online will likely hang the system.
On 30-05-18, 18:49, Krzysztof Kozlowski wrote:
> Secondary CPUs should have the same information in DeviceTree as booting
> CPU from both correctness point of view and for possible hotplug
> scenarios.
>
> Suggested-by: Viresh Kumar
> Signed-off-by: Krzysztof Kozlowski
> ---
>
On 30-05-18, 18:49, Krzysztof Kozlowski wrote:
> Secondary CPUs should have the same information in DeviceTree as booting
> CPU from both correctness point of view and for possible hotplug
> scenarios.
>
> Suggested-by: Viresh Kumar
> Signed-off-by: Krzysztof Kozlowski
> ---
>
On Wed, May 30 2018, Arnd Bergmann wrote:
> Something in recent linux-next kernels caused linux/highmem.h to
> no longer be included implicitly from o2iblnd_cb.c, causing a build
> failure:
>
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c: In function
> 'kiblnd_kvaddr_to_page':
>
On Wed, May 30 2018, Arnd Bergmann wrote:
> Something in recent linux-next kernels caused linux/highmem.h to
> no longer be included implicitly from o2iblnd_cb.c, causing a build
> failure:
>
> drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c: In function
> 'kiblnd_kvaddr_to_page':
>
On Mon, May 21, 2018 at 11:47 PM, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler. For now,
> this is just documenting that the function returns a
> VM_FAULT value rather than an errno. Once all instances are
> converted, vm_fault_t will become a distinct type.
>
>
On Mon, May 21, 2018 at 11:47 PM, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler. For now,
> this is just documenting that the function returns a
> VM_FAULT value rather than an errno. Once all instances are
> converted, vm_fault_t will become a distinct type.
>
>
From: Levin Du
In roc-rk3328-cc board, the signal voltage of sdmmc is supplied by
the vcc_sdio regulator, which is a mux between 1.8V and 3.3V,
controlled by a special output only gpio pin labeled
"gpiomut_pmuio_iout", corresponding bit 1 of the syscon GRF_SOC_CON10.
This special pin can now be
For the migrating VMs, user space may need to know the exception
state. For example, in the machine A, KVM make an SError pending,
when migrate to B, KVM also needs to pend an SError.
This new IOCTL exports user-invisible states related to SError.
Together with appropriate user space changes,
From: Levin Du
In roc-rk3328-cc board, the signal voltage of sdmmc is supplied by
the vcc_sdio regulator, which is a mux between 1.8V and 3.3V,
controlled by a special output only gpio pin labeled
"gpiomut_pmuio_iout", corresponding bit 1 of the syscon GRF_SOC_CON10.
This special pin can now be
For the migrating VMs, user space may need to know the exception
state. For example, in the machine A, KVM make an SError pending,
when migrate to B, KVM also needs to pend an SError.
This new IOCTL exports user-invisible states related to SError.
Together with appropriate user space changes,
On Wed, May 30, 2018 at 08:23:16PM -0700, Hugh Dickins wrote:
> George Boole would have noticed a slight error in 4.16 commit 69d763fc6d3a
> ("mm: pin address_space before dereferencing it while isolating an LRU page").
> Fix it, to match both the comment above it, and the original behaviour.
>
>
On Wed, May 30, 2018 at 08:23:16PM -0700, Hugh Dickins wrote:
> George Boole would have noticed a slight error in 4.16 commit 69d763fc6d3a
> ("mm: pin address_space before dereferencing it while isolating an LRU page").
> Fix it, to match both the comment above it, and the original behaviour.
>
>
Hi Stephen,
On 5/30/2018 9:25 PM, Stephen Boyd wrote:
> Quoting Sricharan R (2018-05-24 22:40:11)
>> Hi Bjorn,
>>
>> On 5/24/2018 11:09 PM, Bjorn Andersson wrote:
>>> On Tue 06 Mar 06:38 PST 2018, Sricharan R wrote:
>>>
From: Stephen Boyd
Krait CPUs have a handful of L2 cache
Hi Stephen,
On 5/30/2018 9:25 PM, Stephen Boyd wrote:
> Quoting Sricharan R (2018-05-24 22:40:11)
>> Hi Bjorn,
>>
>> On 5/24/2018 11:09 PM, Bjorn Andersson wrote:
>>> On Tue 06 Mar 06:38 PST 2018, Sricharan R wrote:
>>>
From: Stephen Boyd
Krait CPUs have a handful of L2 cache
On Wed, May 30, 2018 at 08:32:41PM +0200, Lukas Wunner wrote:
> On Wed, May 30, 2018 at 12:54:15PM -0500, Bjorn Helgaas wrote:
> > void aer_print_port_info(struct pci_dev *dev, struct aer_err_info *info)
> > {
> > - pci_info(dev, "AER: %s%s error received: id=%04x\n",
> > + u8 bus = info->id
On Wed, May 30, 2018 at 08:32:41PM +0200, Lukas Wunner wrote:
> On Wed, May 30, 2018 at 12:54:15PM -0500, Bjorn Helgaas wrote:
> > void aer_print_port_info(struct pci_dev *dev, struct aer_err_info *info)
> > {
> > - pci_info(dev, "AER: %s%s error received: id=%04x\n",
> > + u8 bus = info->id
Reviewed-by: Sagi Grimberg
Reviewed-by: Sagi Grimberg
On Thursday 31 May 2018 01:39 AM, Michael Turquette wrote:
> Hi David,
>
> Quoting David Lechner (2018-05-25 11:11:41)
>> This is a resend of all of the outstanding DaVinci clock patches plus one new
>> patch. All of the patches (except the new one) have been reviewed and tested
>> by someone
On Thursday 31 May 2018 01:39 AM, Michael Turquette wrote:
> Hi David,
>
> Quoting David Lechner (2018-05-25 11:11:41)
>> This is a resend of all of the outstanding DaVinci clock patches plus one new
>> patch. All of the patches (except the new one) have been reviewed and tested
>> by someone
On Wed, May 30, 2018 at 11:41:23AM -0700, Rajat Jain wrote:
> On Wed, May 30, 2018 at 10:54 AM Bjorn Helgaas wrote:
>
> > From: Bjorn Helgaas
>
> > Decode the Requester ID from the AER Error Source Register into domain/
> > bus/device/function format to match other logging. In cases where the
On Wed, May 30, 2018 at 11:41:23AM -0700, Rajat Jain wrote:
> On Wed, May 30, 2018 at 10:54 AM Bjorn Helgaas wrote:
>
> > From: Bjorn Helgaas
>
> > Decode the Requester ID from the AER Error Source Register into domain/
> > bus/device/function format to match other logging. In cases where the
Hi Jens,
On Wed, 30 May 2018 22:35:40 -0600 Jens Axboe wrote:
>
> I’ll drop the last patch, we can do that at the end of the merge window
> instead.
Thanks.
--
Cheers,
Stephen Rothwell
pgpPUddo5Ay6c.pgp
Description: OpenPGP digital signature
Hi Jens,
On Wed, 30 May 2018 22:35:40 -0600 Jens Axboe wrote:
>
> I’ll drop the last patch, we can do that at the end of the merge window
> instead.
Thanks.
--
Cheers,
Stephen Rothwell
pgpPUddo5Ay6c.pgp
Description: OpenPGP digital signature
This series patch is separated from
https://www.spinics.net/lists/kvm/msg168917.html
1. CPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so
this patch supports this
notification in software
Dongjiu Geng (2):
ACPI / APEI: Add SEI notification type support for ARMv8
This series patch is separated from
https://www.spinics.net/lists/kvm/msg168917.html
1. CPI 6.1 adds support for NOTIFY_SEI as a GHES notification mechanism, so
this patch supports this
notification in software
Dongjiu Geng (2):
ACPI / APEI: Add SEI notification type support for ARMv8
ACPI 6.x adds support for NOTIFY_SEI as a GHES notification
mechanism, so add new GHES notification handling functions.
Expose API ghes_notify_sei() to arch code, arch code will call
this API when it gets this NOTIFY_SEI.
Signed-off-by: Dongjiu Geng
---
Note:
Firmware will follow the SError mask
When kernel or KVM gets the NOTIFY_SEI notification, it firstly
calls the APEI driver to handle this notification.
Signed-off-by: Dongjiu Geng
---
arch/arm64/kernel/traps.c | 15 +++
1 file changed, 15 insertions(+)
---
change since https://www.spinics.net/lists/kvm/msg168919.html
When kernel or KVM gets the NOTIFY_SEI notification, it firstly
calls the APEI driver to handle this notification.
Signed-off-by: Dongjiu Geng
---
arch/arm64/kernel/traps.c | 15 +++
1 file changed, 15 insertions(+)
---
change since https://www.spinics.net/lists/kvm/msg168919.html
ACPI 6.x adds support for NOTIFY_SEI as a GHES notification
mechanism, so add new GHES notification handling functions.
Expose API ghes_notify_sei() to arch code, arch code will call
this API when it gets this NOTIFY_SEI.
Signed-off-by: Dongjiu Geng
---
Note:
Firmware will follow the SError mask
On May 30, 2018, at 10:23 PM, Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the device-mapper tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/md/dm-writecache.c: In function 'writecache_dtr':
> drivers/md/dm-writecache.c:1799:3: error: implicit
On May 30, 2018, at 10:23 PM, Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the device-mapper tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/md/dm-writecache.c: In function 'writecache_dtr':
> drivers/md/dm-writecache.c:1799:3: error: implicit
Hi all,
Today's linux-next merge of the md tree got a conflict in:
drivers/md/md.c
between commit:
afeee514ce7f ("md: convert to bioset_init()/mempool_init()")
from the block tree and commit:
5a409b4f56d5 ("MD: fix lock contention for flush bios")
from the md tree.
I fixed it up (see
Hi all,
Today's linux-next merge of the md tree got a conflict in:
drivers/md/md.c
between commit:
afeee514ce7f ("md: convert to bioset_init()/mempool_init()")
from the block tree and commit:
5a409b4f56d5 ("MD: fix lock contention for flush bios")
from the md tree.
I fixed it up (see
On Thu, May 31, 2018 at 12:05 AM, Vivek Goyal wrote:
> On Tue, May 29, 2018 at 04:46:00PM +0200, Miklos Szeredi wrote:
>> From: Vivek Goyal
>>
>> Metacopy dentry/inode is internal to overlay and is never exposed outside
>> of it. Exception is metacopy upper file used for fsync(). Modify
On Thu, May 31, 2018 at 12:05 AM, Vivek Goyal wrote:
> On Tue, May 29, 2018 at 04:46:00PM +0200, Miklos Szeredi wrote:
>> From: Vivek Goyal
>>
>> Metacopy dentry/inode is internal to overlay and is never exposed outside
>> of it. Exception is metacopy upper file used for fsync(). Modify
Hi all,
After merging the device-mapper tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/md/dm-writecache.c: In function 'writecache_dtr':
drivers/md/dm-writecache.c:1799:3: error: implicit declaration of function
'bioset_free'; did you mean 'bvec_free'?
Hi all,
After merging the device-mapper tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/md/dm-writecache.c: In function 'writecache_dtr':
drivers/md/dm-writecache.c:1799:3: error: implicit declaration of function
'bioset_free'; did you mean 'bvec_free'?
On 05/30/2018 06:14 PM, Ulf Hansson wrote:
> [...]
>
+
+static DEFINE_MUTEX(rpmpd_lock);
+
+/* msm8996 RPM powerdomains */
+DEFINE_RPMPD_CORN_SMPA(msm8996, vddcx, vddcx_ao, 1);
+DEFINE_RPMPD_CORN_SMPA(msm8996, vddmx, vddmx_ao, 2);
On 05/30/2018 06:14 PM, Ulf Hansson wrote:
> [...]
>
+
+static DEFINE_MUTEX(rpmpd_lock);
+
+/* msm8996 RPM powerdomains */
+DEFINE_RPMPD_CORN_SMPA(msm8996, vddcx, vddcx_ao, 1);
+DEFINE_RPMPD_CORN_SMPA(msm8996, vddmx, vddmx_ao, 2);
On Wed, May 30, 2018 at 10:35:36AM +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang
>
> The MTCMOS of PCIe Host for MT2712 will be off when system suspend, and all
> the internel control register will be reset after system resume. The PCIe
> link should be re-established and the
On 11/05/18 16:12, Alastair D'Silva wrote:
From: Alastair D'Silva
Switch the use of TIDR on it's CPU feature, rather than assuming it
is available based on architecture.
Signed-off-by: Alastair D'Silva
Reviewed-by: Andrew Donnellan
--
Andrew Donnellan OzLabs, ADL Canberra
On Wed, May 30, 2018 at 10:35:36AM +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang
>
> The MTCMOS of PCIe Host for MT2712 will be off when system suspend, and all
> the internel control register will be reset after system resume. The PCIe
> link should be re-established and the
On 11/05/18 16:12, Alastair D'Silva wrote:
From: Alastair D'Silva
Switch the use of TIDR on it's CPU feature, rather than assuming it
is available based on architecture.
Signed-off-by: Alastair D'Silva
Reviewed-by: Andrew Donnellan
--
Andrew Donnellan OzLabs, ADL Canberra
Hi everyone,
My apologies if this has already been reported in some capacity, I
searched the mailing list and patchwork but I didn't see anything.
With GCC 8.1.0, I am starting to see the following warnings from
Kconfig:
CCscripts/kconfig/zconf.tab.c
LEX scripts/kconfig/zconf.lex.c
Hi everyone,
My apologies if this has already been reported in some capacity, I
searched the mailing list and patchwork but I didn't see anything.
With GCC 8.1.0, I am starting to see the following warnings from
Kconfig:
CCscripts/kconfig/zconf.tab.c
LEX scripts/kconfig/zconf.lex.c
On 05/31/2018 09:01 AM, Rob Herring wrote:
> On Fri, May 25, 2018 at 03:31:20PM +0530, Rajendra Nayak wrote:
>> The RPMh powerdomain driver aggregates the corner votes from various
>> consumers for the ARC resources and communicates it to RPMh.
>>
>> We also add data for all powerdomains on
On 05/31/2018 09:01 AM, Rob Herring wrote:
> On Fri, May 25, 2018 at 03:31:20PM +0530, Rajendra Nayak wrote:
>> The RPMh powerdomain driver aggregates the corner votes from various
>> consumers for the ARC resources and communicates it to RPMh.
>>
>> We also add data for all powerdomains on
On 05/31/2018 08:57 AM, Rob Herring wrote:
> On Fri, May 25, 2018 at 03:31:16PM +0530, Rajendra Nayak wrote:
>> The powerdomains for corners just pass the performance state set by the
>> consumers to the RPM (Remote Power manager) which then takes care
>> of setting the appropriate voltage on
On 05/31/2018 08:57 AM, Rob Herring wrote:
> On Fri, May 25, 2018 at 03:31:16PM +0530, Rajendra Nayak wrote:
>> The powerdomains for corners just pass the performance state set by the
>> consumers to the RPM (Remote Power manager) which then takes care
>> of setting the appropriate voltage on
On Wed, May 30, 2018 at 07:41:31PM +0530, Faiz Abbas wrote:
> The dra76x MCAN generic interconnect module has a its own
> format for the bits in the control registers.
>
> Therefore add a new module type, new regbits and new capabilities
> specific to the MCAN module.
>
> CC: Tony Lindgren
>
On Wed, May 30, 2018 at 07:41:31PM +0530, Faiz Abbas wrote:
> The dra76x MCAN generic interconnect module has a its own
> format for the bits in the control registers.
>
> Therefore add a new module type, new regbits and new capabilities
> specific to the MCAN module.
>
> CC: Tony Lindgren
>
On Wed, May 30, 2018 at 07:41:32PM +0530, Faiz Abbas wrote:
> The ti-sysc driver provides support for manipulating the idlemodes
> and interconnect level resets.
>
> Add the generic interconnect target module node for MCAN to support
> the same.
>
> CC: Tony Lindgren
> Signed-off-by: Faiz Abbas
On Wed, May 30, 2018 at 07:41:32PM +0530, Faiz Abbas wrote:
> The ti-sysc driver provides support for manipulating the idlemodes
> and interconnect level resets.
>
> Add the generic interconnect target module node for MCAN to support
> the same.
>
> CC: Tony Lindgren
> Signed-off-by: Faiz Abbas
On Wed, May 30, 2018 at 4:01 PM Jason Gunthorpe wrote:
> On Thu, May 31, 2018 at 12:40:54AM +0200, Arnd Bergmann wrote:
> > > On 5/30/2018 5:25 PM, Jason Gunthorpe wrote:
> > >> On Wed, May 30, 2018 at 05:10:35PM -0500, Steve Wise wrote:
> > >>>
> > >>> On 5/30/2018 5:04 PM, Jason Gunthorpe
On Wed, May 30, 2018 at 07:41:30PM +0530, Faiz Abbas wrote:
> Add clkctrl data for the m_can clocks and register it within the
> clkctrl driver
>
> CC: Tero Kristo
> Signed-off-by: Faiz Abbas
> ---
> drivers/clk/ti/clk-7xx.c | 1 +
> include/dt-bindings/clock/dra7.h | 1 +
> 2 files
On Wed, May 30, 2018 at 4:01 PM Jason Gunthorpe wrote:
> On Thu, May 31, 2018 at 12:40:54AM +0200, Arnd Bergmann wrote:
> > > On 5/30/2018 5:25 PM, Jason Gunthorpe wrote:
> > >> On Wed, May 30, 2018 at 05:10:35PM -0500, Steve Wise wrote:
> > >>>
> > >>> On 5/30/2018 5:04 PM, Jason Gunthorpe
On Wed, May 30, 2018 at 07:41:30PM +0530, Faiz Abbas wrote:
> Add clkctrl data for the m_can clocks and register it within the
> clkctrl driver
>
> CC: Tero Kristo
> Signed-off-by: Faiz Abbas
> ---
> drivers/clk/ti/clk-7xx.c | 1 +
> include/dt-bindings/clock/dra7.h | 1 +
> 2 files
On Wed, May 30, 2018 at 12:32:38PM +0200, Johan Hovold wrote:
> Add binding for u-blox GNSS receivers.
>
> Note that the u-blox product names encodes form factor (e.g. "neo"),
> chipset (e.g. "8") and variant (e.g. "q"), but that only formfactor and
> chipset is used for the compatible strings
On Wed, May 30, 2018 at 12:32:38PM +0200, Johan Hovold wrote:
> Add binding for u-blox GNSS receivers.
>
> Note that the u-blox product names encodes form factor (e.g. "neo"),
> chipset (e.g. "8") and variant (e.g. "q"), but that only formfactor and
> chipset is used for the compatible strings
On Tue, May 29, 2018 at 02:15:37PM +0100, Suzuki K Poulose wrote:
> Now that we can dynamically switch between contiguous memory and
> SG table depending on the trace buffer size, provide the support
> for selecting an appropriate buffer size.
>
> Cc: Mathieu Poirier
> Signed-off-by: Suzuki K
On Tue, May 29, 2018 at 02:15:37PM +0100, Suzuki K Poulose wrote:
> Now that we can dynamically switch between contiguous memory and
> SG table depending on the trace buffer size, provide the support
> for selecting an appropriate buffer size.
>
> Cc: Mathieu Poirier
> Signed-off-by: Suzuki K
On Tue, May 29, 2018 at 12:04:17PM +0200, Ulf Hansson wrote:
> To be able to describe topologies where devices are partitioned across
> multiple power domains, let's extend the power-domain property to allow
> being a list of PM domain specifiers.
>
> Cc: Rob Herring
> Cc:
Hi David,
On 05/30/2018 11:57 PM, David Collins wrote:
> Hello Rajendra,
>
> On 05/30/2018 03:14 AM, Rajendra Nayak wrote:
>> On 05/30/2018 02:47 PM, Ulf Hansson wrote:
>>> On 25 May 2018 at 12:01, Rajendra Nayak wrote:
> ...
+ pm_genpd_init([i]->pd, NULL, true);
>>>
>>>
On Tue, May 29, 2018 at 12:04:17PM +0200, Ulf Hansson wrote:
> To be able to describe topologies where devices are partitioned across
> multiple power domains, let's extend the power-domain property to allow
> being a list of PM domain specifiers.
>
> Cc: Rob Herring
> Cc:
Hi David,
On 05/30/2018 11:57 PM, David Collins wrote:
> Hello Rajendra,
>
> On 05/30/2018 03:14 AM, Rajendra Nayak wrote:
>> On 05/30/2018 02:47 PM, Ulf Hansson wrote:
>>> On 25 May 2018 at 12:01, Rajendra Nayak wrote:
> ...
+ pm_genpd_init([i]->pd, NULL, true);
>>>
>>>
Yamada
>> Date: Mon May 28 18:22:07 2018 +0900
>>
>> gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST
>>
>>
>>
>> CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL was previously disabled
>> for COMPILE_TEST, which is now enabled.
>
> W
Yamada
>> Date: Mon May 28 18:22:07 2018 +0900
>>
>> gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST
>>
>>
>>
>> CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL was previously disabled
>> for COMPILE_TEST, which is now enabled.
>
> W
On Tue, May 29, 2018 at 03:22:40PM +0530, Vijay Viswanath wrote:
> From: Sayali Lokhande
>
> For SDCC version 5.0.0 and higher, new compatible string
> "qcom,sdhci-msm-v5" is added.
>
> Signed-off-by: Sayali Lokhande
> Signed-off-by: Vijay Viswanath
> ---
>
On Tue, May 29, 2018 at 03:22:40PM +0530, Vijay Viswanath wrote:
> From: Sayali Lokhande
>
> For SDCC version 5.0.0 and higher, new compatible string
> "qcom,sdhci-msm-v5" is added.
>
> Signed-off-by: Sayali Lokhande
> Signed-off-by: Vijay Viswanath
> ---
>
Hi Jens,
After merging the block tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/md/md.c: In function 'mddev_put':
drivers/md/md.c:543:1: warning: the frame size of 2080 bytes is larger than
2048 bytes [-Wframe-larger-than=]
}
^
This is caused because
Hi Jens,
After merging the block tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/md/md.c: In function 'mddev_put':
drivers/md/md.c:543:1: warning: the frame size of 2080 bytes is larger than
2048 bytes [-Wframe-larger-than=]
}
^
This is caused because
On Mon, May 28, 2018 at 12:23:54AM +0200, Miquel Raynal wrote:
> Hi Stefan,
>
> On Sun, 27 May 2018 23:54:38 +0200, Stefan Agner
> wrote:
>
> > From: Lucas Stach
> >
> > This adds the devicetree binding for the Tegra 2 NAND flash
> > controller.
> >
> > Signed-off-by: Lucas Stach
> >
On Mon, May 28, 2018 at 12:23:54AM +0200, Miquel Raynal wrote:
> Hi Stefan,
>
> On Sun, 27 May 2018 23:54:38 +0200, Stefan Agner
> wrote:
>
> > From: Lucas Stach
> >
> > This adds the devicetree binding for the Tegra 2 NAND flash
> > controller.
> >
> > Signed-off-by: Lucas Stach
> >
On 05/28/2018 05:03 AM, Abhishek Goel wrote:
> The names of the idle states in the output of cpupower monitor command are
> truncated to 4 characters. On POWER9, this creates ambiguity as the states
> are named "stop0", "stop1", etc.
>
> root:~# cpupower monitor
> |Idle_Stats
> PKG
On 05/28/2018 05:03 AM, Abhishek Goel wrote:
> The names of the idle states in the output of cpupower monitor command are
> truncated to 4 characters. On POWER9, this creates ambiguity as the states
> are named "stop0", "stop1", etc.
>
> root:~# cpupower monitor
> |Idle_Stats
> PKG
On Fri, May 25, 2018 at 12:15:46PM +0100, Srinivas Kandagatla wrote:
> This patch adds bindings for Qualcomm SLIMBus NGD controller.
> SLIMBus NGD controller is a light-weight driver responsible for
> communicating with SLIMBus slaves directly over the bus using messaging
> interface and
On Fri, May 25, 2018 at 12:15:46PM +0100, Srinivas Kandagatla wrote:
> This patch adds bindings for Qualcomm SLIMBus NGD controller.
> SLIMBus NGD controller is a light-weight driver responsible for
> communicating with SLIMBus slaves directly over the bus using messaging
> interface and
On Fri, May 25, 2018 at 03:31:20PM +0530, Rajendra Nayak wrote:
> The RPMh powerdomain driver aggregates the corner votes from various
> consumers for the ARC resources and communicates it to RPMh.
>
> We also add data for all powerdomains on sdm845 as part of the patch.
> The driver can be
On Fri, May 25, 2018 at 03:31:20PM +0530, Rajendra Nayak wrote:
> The RPMh powerdomain driver aggregates the corner votes from various
> consumers for the ARC resources and communicates it to RPMh.
>
> We also add data for all powerdomains on sdm845 as part of the patch.
> The driver can be
From: Levin Du
Hi all, this is an attemp to add sdmmc UHS support to the
ROC-RK3328-CC board.
This patch series adds a new compatible `rockchip,rk3328-gpio-mute` to
the gpio-syscon driver for the access of the GPIO_MUTE pin in rk3328.
A new gpio controller named `gpio_mute` is defined in
From: Levin Du
It is necessary for the io domain setting of the SoC to match
the voltage supplied by the regulators.
Signed-off-by: Levin Du
---
Changes in v3: None
Changes in v2: None
Changes in v1:
- Split from V0.
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 12
1 file
1 - 100 of 1682 matches
Mail list logo
