4.152-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git branch: 4.4.152-rc1-hikey-20180823-268
git commit: 986fb599d866b6dd9ac53fa1db463d8e6c691e2c
git describe: 4.4.152-rc1-hikey-20180823-268
Test details:
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.1
It seems like you only sent out 6 our of the actual 11 patches according
to the numbering, please resend the full series.
4.152-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git branch: 4.4.152-rc1-hikey-20180823-268
git commit: 986fb599d866b6dd9ac53fa1db463d8e6c691e2c
git describe: 4.4.152-rc1-hikey-20180823-268
Test details:
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.1
It seems like you only sent out 6 our of the actual 11 patches according
to the numbering, please resend the full series.
Hi Randy,
On 08/24/2018 12:28 AM, Randy Dunlap wrote:
> On 08/20/2018 10:44 PM, Roy Im wrote:
> > diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> > index ca59a2b..6e0de69 100644
> > --- a/drivers/input/misc/Kconfig
> > +++ b/drivers/input/misc/Kconfig
> > @@ -851,4 +851,16
Hi Randy,
On 08/24/2018 12:28 AM, Randy Dunlap wrote:
> On 08/20/2018 10:44 PM, Roy Im wrote:
> > diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> > index ca59a2b..6e0de69 100644
> > --- a/drivers/input/misc/Kconfig
> > +++ b/drivers/input/misc/Kconfig
> > @@ -851,4 +851,16
/linux/commits/Weikang-Shi/fs-fix-local-var-type/20180823-180758
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
fs/seq_file.c:210:21: sparse: expression using sizeof(void)
/linux/commits/Weikang-Shi/fs-fix-local-var-type/20180823-180758
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
fs/seq_file.c:210:21: sparse: expression using sizeof(void)
On 23 August 2018 at 13:21, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 4.9.124 release.
> There are 130 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
>
On 23 August 2018 at 13:21, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 4.9.124 release.
> There are 130 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
>
Hi Linus,
On Tue, 21 Aug 2018 19:09:31 -0700 Linus Torvalds
wrote:
>
> For some unfathomable reason, you have based it on the libnvdimm tree.
> I don't understand at all wjhy you did that.
That was partly my fault for giving not very good advice when the
(quite complex) merge conflict turned
Hi Linus,
On Tue, 21 Aug 2018 19:09:31 -0700 Linus Torvalds
wrote:
>
> For some unfathomable reason, you have based it on the libnvdimm tree.
> I don't understand at all wjhy you did that.
That was partly my fault for giving not very good advice when the
(quite complex) merge conflict turned
On 23 August 2018 at 13:21, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 4.14.67 release.
> There are 217 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
>
On 23 August 2018 at 13:21, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 4.14.67 release.
> There are 217 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
>
On 23 August 2018 at 13:21, Greg Kroah-Hartman
wrote:
> NOTE, this is going to be the LAST 4.17.y kernel release. Please move
> to the 4.18.y tree at this point in time if you have not already. After
> this release, 4.17.y will be end-of-life.
>
> This is the start of the stable review cycle
On 23 August 2018 at 13:21, Greg Kroah-Hartman
wrote:
> NOTE, this is going to be the LAST 4.17.y kernel release. Please move
> to the 4.18.y tree at this point in time if you have not already. After
> this release, 4.17.y will be end-of-life.
>
> This is the start of the stable review cycle
The touchpads on both T25 and T480 are accessible over SMBUS/RMI.
---
v2
Only a tag change.
The original author wants to use a pseudonym, and agrees with the usurpation of
the signed-off-by tag. See https://patchwork.kernel.org/patch/10512751/
Reported-by: kitsunyan
Signed-off-by: Teika
The touchpads on both T25 and T480 are accessible over SMBUS/RMI.
---
v2
Only a tag change.
The original author wants to use a pseudonym, and agrees with the usurpation of
the signed-off-by tag. See https://patchwork.kernel.org/patch/10512751/
Reported-by: kitsunyan
Signed-off-by: Teika
On 23 August 2018 at 13:26, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 4.18.5 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
>
On 23 August 2018 at 13:26, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 4.18.5 release.
> There are 22 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
>
Hi Randy,
2018-08-24 3:13 GMT+09:00 Randy Dunlap :
> From: Randy Dunlap
>
> When $DEPMOD is not found, only print a warning instead of exiting
> with an error message and error status.
Could you add the motivation of this change
(as Nikolaus reported) ?
Without the reason recorded in
Hi Randy,
2018-08-24 3:13 GMT+09:00 Randy Dunlap :
> From: Randy Dunlap
>
> When $DEPMOD is not found, only print a warning instead of exiting
> with an error message and error status.
Could you add the motivation of this change
(as Nikolaus reported) ?
Without the reason recorded in
On Thu, Aug 16, 2018 at 08:13:03AM +0200, Heiner Kallweit wrote:
> Recently I started to get warning "NOHZ: local_softirq_pending 202" and
> I think it's related to mentioned commit (didn't bisect it yet).
> See log from suspending.
>
> I have no reason to think the fix is wrong, it may just have
On Thu, Aug 16, 2018 at 08:13:03AM +0200, Heiner Kallweit wrote:
> Recently I started to get warning "NOHZ: local_softirq_pending 202" and
> I think it's related to mentioned commit (didn't bisect it yet).
> See log from suspending.
>
> I have no reason to think the fix is wrong, it may just have
delete redundant semicolon
Signed-off-by: Ding Xiang
---
fs/ubifs/sb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ubifs/sb.c b/fs/ubifs/sb.c
index bf17f58..d5c55e2 100644
--- a/fs/ubifs/sb.c
+++ b/fs/ubifs/sb.c
@@ -603,7 +603,7 @@ int ubifs_read_superblock(struct
delete redundant semicolon
Signed-off-by: Ding Xiang
---
fs/ubifs/sb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ubifs/sb.c b/fs/ubifs/sb.c
index bf17f58..d5c55e2 100644
--- a/fs/ubifs/sb.c
+++ b/fs/ubifs/sb.c
@@ -603,7 +603,7 @@ int ubifs_read_superblock(struct
Hi all,
Please do not add any v4.20 material to your linux-next included
branches until after v4.19-rc1 has been released.
Changes since 20180823:
The kbuild tree lost its build failure.
The mips tree gained a conflict against Linus' tree.
The nios2 tree gained a conflict against Linus' tree
Hi all,
Please do not add any v4.20 material to your linux-next included
branches until after v4.19-rc1 has been released.
Changes since 20180823:
The kbuild tree lost its build failure.
The mips tree gained a conflict against Linus' tree.
The nios2 tree gained a conflict against Linus' tree
On Fri, Aug 24, 2018 at 04:22:57AM +0200, Andre Tomt wrote:
> On 23. aug. 2018 17:44, Andi Kleen wrote:
> > On Thu, Aug 23, 2018 at 03:44:18PM +0200, Vlastimil Babka wrote:
> > > Two users have reported [1] that they have an "extremely unlikely" system
> > > with more than MAX_PA/2 memory and L1TF
On Fri, Aug 24, 2018 at 04:22:57AM +0200, Andre Tomt wrote:
> On 23. aug. 2018 17:44, Andi Kleen wrote:
> > On Thu, Aug 23, 2018 at 03:44:18PM +0200, Vlastimil Babka wrote:
> > > Two users have reported [1] that they have an "extremely unlikely" system
> > > with more than MAX_PA/2 memory and L1TF
RK809 and RK817 are power management IC chips for multimedia products.
most of their functions and registers are same, including the clkout
funciton.
Signed-off-by: Tony Xie
---
drivers/clk/Kconfig | 9 ---
drivers/clk/clk-rk808.c | 62 -
RK809 and RK817 are power management IC chips for multimedia products.
most of their functions and registers are same, including the clkout
funciton.
Signed-off-by: Tony Xie
---
drivers/clk/Kconfig | 9 ---
drivers/clk/clk-rk808.c | 62 -
RK809 and RK817 are power management IC chips for multimedia products.
Most of their functions and registers are same, including the rtc.
Signed-off-by: Tony Xie
---
drivers/rtc/Kconfig | 4 +--
drivers/rtc/rtc-rk808.c | 68 +++--
2 files
RK809 and RK817 are power management IC chips for multimedia products.
Most of their functions and registers are same, including the rtc.
Signed-off-by: Tony Xie
---
drivers/rtc/Kconfig | 4 +--
drivers/rtc/rtc-rk808.c | 68 +++--
2 files
Hi all,
After merging the origin tree, today's linux-next build (powerpc
allyesconfig) produced these warnings:
ld: warning: orphan section `.data..LPBX1' from
`kernel/trace/trace_selftest_dynamic.o' being placed in section `.data..LPBX1'
ld: warning: orphan section `.data..LPBX1' from
Hi all,
After merging the origin tree, today's linux-next build (powerpc
allyesconfig) produced these warnings:
ld: warning: orphan section `.data..LPBX1' from
`kernel/trace/trace_selftest_dynamic.o' being placed in section `.data..LPBX1'
ld: warning: orphan section `.data..LPBX1' from
Add device tree bindings documentation for Rockchip's RK809 & RK817 PMIC.
Signed-off-by: Tony Xie
---
Documentation/devicetree/bindings/mfd/rk808.txt | 56 +
1 file changed, 56 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/rk808.txt
Add device tree bindings documentation for Rockchip's RK809 & RK817 PMIC.
Signed-off-by: Tony Xie
---
Documentation/devicetree/bindings/mfd/rk808.txt | 56 +
1 file changed, 56 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/rk808.txt
Add support for the rk809 and rk817 regulator driver.
Their specifications are as follows：
1、The RK809 and RK809 consist of 5 DCDCs, 9 LDOs
and have the same registers for these components except dcdc5.
2、The dcdc5 is a boost dcdc for RK817 and is a buck for RK809.
3、The
RK809 and RK817 are power management IC chips for multimedia products.
Most of their functions and registers are same, including the rtc.
Signed-off-by: Tony Xie
---
drivers/rtc/Kconfig | 4 +--
drivers/rtc/rtc-rk808.c | 68 +++--
2 files
RK809 and RK817 are power management IC chips for multimedia products.
Most of their functions and registers are same, including the rtc.
Signed-off-by: Tony Xie
---
drivers/rtc/Kconfig | 4 +--
drivers/rtc/rtc-rk808.c | 68 +++--
2 files
Add support for the rk809 and rk817 regulator driver.
Their specifications are as follows：
1、The RK809 and RK809 consist of 5 DCDCs, 9 LDOs
and have the same registers for these components except dcdc5.
2、The dcdc5 is a boost dcdc for RK817 and is a buck for RK809.
3、The
The rk809 and rk817 are a Power Management IC (PMIC) for multimedia
and handheld devices. It contains the following components:
- Regulators
- RTC
- Clocking
Both RK809 and RK817 chips are using a similar register map,
so we can reuse the RTC and Clocking
Most of functions and registers of the rk817 and rk808 are the same,
so they can share allmost all codes.
Their specifications are as follows：
1) The RK809 and RK809 consist of 5 DCDCs, 9 LDOs and have the same registers
for these components except dcdc5.
2) The dcdc5 is a boost dcdc for
The rk809 and rk817 are a Power Management IC (PMIC) for multimedia
and handheld devices. It contains the following components:
- Regulators
- RTC
- Clocking
Both RK809 and RK817 chips are using a similar register map,
so we can reuse the RTC and Clocking
Most of functions and registers of the rk817 and rk808 are the same,
so they can share allmost all codes.
Their specifications are as follows：
1) The RK809 and RK809 consist of 5 DCDCs, 9 LDOs and have the same registers
for these components except dcdc5.
2) The dcdc5 is a boost dcdc for
On Thu, Aug 23, 2018 at 01:59:17PM -0700, Mike Kravetz wrote:
> When fixing an issue with PMD sharing and migration, it was discovered
> via code inspection that other callers of huge_pmd_unshare potentially
> have an issue with cache and tlb flushing.
>
> Use the routine
On Thu, Aug 23, 2018 at 01:59:17PM -0700, Mike Kravetz wrote:
> When fixing an issue with PMD sharing and migration, it was discovered
> via code inspection that other callers of huge_pmd_unshare potentially
> have an issue with cache and tlb flushing.
>
> Use the routine
ATTENZIONE;
La cassetta postale ha superato il limite di archiviazione, che è 5 GB come
definiti dall'amministratore, che è attualmente in esecuzione su 10.9GB, non si
può essere in grado di inviare o ricevere nuovi messaggi fino a ri-convalidare
la tua mailbox. Per rinnovare la vostra casella
ATTENZIONE;
La cassetta postale ha superato il limite di archiviazione, che è 5 GB come
definiti dall'amministratore, che è attualmente in esecuzione su 10.9GB, non si
può essere in grado di inviare o ricevere nuovi messaggi fino a ri-convalidare
la tua mailbox. Per rinnovare la vostra casella
On Thu, Aug 23, 2018 at 01:59:16PM -0700, Mike Kravetz wrote:
> The page migration code employs try_to_unmap() to try and unmap the
> source page. This is accomplished by using rmap_walk to find all
> vmas where the page is mapped. This search stops when page mapcount
> is zero. For shared PMD
On Thu, Aug 23, 2018 at 01:59:16PM -0700, Mike Kravetz wrote:
> The page migration code employs try_to_unmap() to try and unmap the
> source page. This is accomplished by using rmap_walk to find all
> vmas where the page is mapped. This search stops when page mapcount
> is zero. For shared PMD
When getting rid of the general ipc_lock(), this was missed
furthermore, making the comment around the ipc object validity
check bogus. Under EIDRM conditions, callers will in turn not
see the error and continue with the operation.
Fixes: 82061c57ce9 (ipc: drop ipc_lock())
Signed-off-by:
When getting rid of the general ipc_lock(), this was missed
furthermore, making the comment around the ipc object validity
check bogus. Under EIDRM conditions, callers will in turn not
see the error and continue with the operation.
Fixes: 82061c57ce9 (ipc: drop ipc_lock())
Signed-off-by:
Signed-off-by: Peng Hao
---
Documentation/virtual/kvm/00-INDEX | 2 ++
Documentation/virtual/kvm/coalesced-pio.txt | 14 ++
2 files changed, 16 insertions(+)
create mode 100644 Documentation/virtual/kvm/coalesced-pio.txt
diff --git a/Documentation/virtual/kvm/00-INDEX
Signed-off-by: Peng Hao
---
Documentation/virtual/kvm/00-INDEX | 2 ++
Documentation/virtual/kvm/coalesced-pio.txt | 14 ++
2 files changed, 16 insertions(+)
create mode 100644 Documentation/virtual/kvm/coalesced-pio.txt
diff --git a/Documentation/virtual/kvm/00-INDEX
Signed-off-by: Peng Hao
---
include/uapi/linux/kvm.h | 5 +++--
virt/kvm/coalesced_mmio.c | 8 +---
virt/kvm/kvm_main.c | 2 ++
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index b6270a3..9cc56d3 100644
---
Coalesced pio is base on coalesced mmio and can be used for some port
like rtc port, pci-host config port, virtio-pci config port and so on.
Specially in case of rtc as coalesced pio, some versions of windows guest
access rtc frequently because of rtc as system tick. guest access rtc like
this:
Coalesced pio is base on coalesced mmio and can be used for some port
like rtc port, pci-host config port, virtio-pci config port and so on.
Specially in case of rtc as coalesced pio, some versions of windows guest
access rtc frequently because of rtc as system tick. guest access rtc like
this:
Signed-off-by: Peng Hao
---
include/uapi/linux/kvm.h | 5 +++--
virt/kvm/coalesced_mmio.c | 8 +---
virt/kvm/kvm_main.c | 2 ++
3 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index b6270a3..9cc56d3 100644
---
On Thu, Aug 23, 2018 at 6:17 PM, Gustavo A. R. Silva
wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
>
On Thu, Aug 23, 2018 at 6:17 PM, Gustavo A. R. Silva
wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
>
On Thu, Aug 23, 2018 at 6:09 PM, Gustavo A. R. Silva
wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
>
On Thu, Aug 23, 2018 at 6:09 PM, Gustavo A. R. Silva
wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
>
On Thu, Aug 23, 2018 at 6:07 PM, Gustavo A. R. Silva
wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
>
On Thu, Aug 23, 2018 at 6:07 PM, Gustavo A. R. Silva
wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
>
If fw is null then fw->size will trigger null pointer dereference
Signed-off-by: Ding Xiang
---
drivers/staging/greybus/bootrom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/greybus/bootrom.c
b/drivers/staging/greybus/bootrom.c
index e85ffae..3af28a0
If fw is null then fw->size will trigger null pointer dereference
Signed-off-by: Ding Xiang
---
drivers/staging/greybus/bootrom.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/greybus/bootrom.c
b/drivers/staging/greybus/bootrom.c
index e85ffae..3af28a0
ACPI driver should make sure all the processor IDs in their ACPI Namespace
are unique. the driver performs a depth-first walk of the namespace tree
and calls the acpi_processor_ids_walk() to check the duplicate IDs.
But, the acpi_processor_ids_walk() mistakes the return value. If a
processor is
ACPI driver should make sure all the processor IDs in their ACPI Namespace
are unique. the driver performs a depth-first walk of the namespace tree
and calls the acpi_processor_ids_walk() to check the duplicate IDs.
But, the acpi_processor_ids_walk() mistakes the return value. If a
processor is
Hi,
Please pull these apparmor changes for v4.19. There is nothing major this time
just 4 bug fixes and a patch to remove so dead code.
Thanks!
- John
The following changes since commit fb7d1bcf1602b46f37ada72178516c01a250e434:
Merge tag 'pci-v4.18-fixes-3' of
Hi,
Please pull these apparmor changes for v4.19. There is nothing major this time
just 4 bug fixes and a patch to remove so dead code.
Thanks!
- John
The following changes since commit fb7d1bcf1602b46f37ada72178516c01a250e434:
Merge tag 'pci-v4.18-fixes-3' of
Geert,
> With gcc 4.1.2:
>
> drivers/ata/libata-core.c:7396:33: warning: no newline at end of file
Applied to 4.19/scsi-fixes, thanks!
--
Martin K. Petersen Oracle Linux Engineering
Geert,
> With gcc 4.1.2:
>
> drivers/ata/libata-core.c:7396:33: warning: no newline at end of file
Applied to 4.19/scsi-fixes, thanks!
--
Martin K. Petersen Oracle Linux Engineering
On 23. aug. 2018 17:44, Andi Kleen wrote:
On Thu, Aug 23, 2018 at 03:44:18PM +0200, Vlastimil Babka wrote:
Two users have reported [1] that they have an "extremely unlikely" system
with more than MAX_PA/2 memory and L1TF mitigation is not effective. In fact
it's a CPU with 36bits phys limit
On 23. aug. 2018 17:44, Andi Kleen wrote:
On Thu, Aug 23, 2018 at 03:44:18PM +0200, Vlastimil Babka wrote:
Two users have reported [1] that they have an "extremely unlikely" system
with more than MAX_PA/2 memory and L1TF mitigation is not effective. In fact
it's a CPU with 36bits phys limit
Now that the 68k Mac port has adopted the via-pmu driver, it must decode
the PMU response accordingly otherwise the date and time will be wrong.
Signed-off-by: Finn Thain
---
I mistakenly omitted this change from my PMU patch series when I
dropped "[PATCH v3 10/12] macintosh: Use common code to
Now that the 68k Mac port has adopted the via-pmu driver, it must decode
the PMU response accordingly otherwise the date and time will be wrong.
Signed-off-by: Finn Thain
---
I mistakenly omitted this change from my PMU patch series when I
dropped "[PATCH v3 10/12] macintosh: Use common code to
Hi,
This patch series adds a driver and DT binding using the interconnect (ICC)
framework [1] to describe the Qualcomm SDM845 platform's topology of its
interconnected buses and internal aggregation nodes known as
Bus Clock Managers(BCM). The SDM845 ICC provider driver would aggregate and
satisfy
Hi,
This patch series adds a driver and DT binding using the interconnect (ICC)
framework [1] to describe the Qualcomm SDM845 platform's topology of its
interconnected buses and internal aggregation nodes known as
Bus Clock Managers(BCM). The SDM845 ICC provider driver would aggregate and
satisfy
Introduce Qualcomm SDM845 specific provider driver using the
interconnect framework.
Change-Id: I716b39068b4a211b8203b2a52d3037a5b84594ea
Signed-off-by: David Dai
---
.../bindings/interconnect/qcom-sdm845.txt | 22 +
drivers/interconnect/qcom/Kconfig | 8 +
Introduce Qualcomm SDM845 specific provider driver using the
interconnect framework.
Change-Id: I716b39068b4a211b8203b2a52d3037a5b84594ea
Signed-off-by: David Dai
---
.../bindings/interconnect/qcom-sdm845.txt | 22 +
drivers/interconnect/qcom/Kconfig | 8 +
Add RSC(Resource State Coordinator) provider
dictating network-on-chip interconnect bus performance
found on SDM845-based platforms.
Change-Id: I58f0bfc3ed484d7b45064dceb94dcfda507e9333
Signed-off-by: David Dai
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 5 +
1 file changed, 5 insertions(+)
Add RSC(Resource State Coordinator) provider
dictating network-on-chip interconnect bus performance
found on SDM845-based platforms.
Change-Id: I58f0bfc3ed484d7b45064dceb94dcfda507e9333
Signed-off-by: David Dai
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 5 +
1 file changed, 5 insertions(+)
The MIO DMAC (Media IO DMA Controller) is used in UniPhier LD4,
Pro4, and sLD8 SoCs.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Use platform_irq_count() to get the number of channels
MAINTAINERS | 1 +
drivers/dma/Kconfig | 11 +
drivers/dma/Makefile
The MIO DMAC (Media IO DMA Controller) is used in UniPhier LD4,
Pro4, and sLD8 SoCs.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Use platform_irq_count() to get the number of channels
MAINTAINERS | 1 +
drivers/dma/Kconfig | 11 +
drivers/dma/Makefile
The MIO DMAC (Media IO DMA Controller) is used in UniPhier LD4,
Pro4, and sLD8 SoCs.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Rename the node "dmac" to "dma-controller"
- Remove dma-channels property
.../devicetree/bindings/dma/uniphier-mio-dmac.txt | 25 ++
1/2: DT-binding
2/2: driver
Masahiro Yamada (2):
dt-bindings: dmaengine: add DT binding for UniPhier MIO DMAC
dmaengine: uniphier-mdmac: add UniPhier MIO DMAC driver
.../devicetree/bindings/dma/uniphier-mio-dmac.txt | 25 ++
MAINTAINERS| 1 +
The MIO DMAC (Media IO DMA Controller) is used in UniPhier LD4,
Pro4, and sLD8 SoCs.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Rename the node "dmac" to "dma-controller"
- Remove dma-channels property
.../devicetree/bindings/dma/uniphier-mio-dmac.txt | 25 ++
1/2: DT-binding
2/2: driver
Masahiro Yamada (2):
dt-bindings: dmaengine: add DT binding for UniPhier MIO DMAC
dmaengine: uniphier-mdmac: add UniPhier MIO DMAC driver
.../devicetree/bindings/dma/uniphier-mio-dmac.txt | 25 ++
MAINTAINERS| 1 +
On Fri, 24 Aug 2018 02:16:12 +0900
Masami Hiramatsu wrote:
> Dump of assembler code from 0xa000207a to 0xa00020ea:
> 54 push %rsp
> ...
> 48 83 c4 08 add$0x8,%rsp
> 9d popfq
> 48 89 f0mov%rsi,%rax
> 8b 35 82 7d db e2
On Fri, 24 Aug 2018 02:16:12 +0900
Masami Hiramatsu wrote:
> Dump of assembler code from 0xa000207a to 0xa00020ea:
> 54 push %rsp
> ...
> 48 83 c4 08 add$0x8,%rsp
> 9d popfq
> 48 89 f0mov%rsi,%rax
> 8b 35 82 7d db e2
Signed-off-by: Ryan Lee
---
Changes since v1 : Applied usleep_range intead of using mdelay
Changes : Applied 10ms delay after amp software reset.
10ms guard time is required for stability.
sound/soc/codecs/max98373.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
Signed-off-by: Ryan Lee
---
Changes since v1 : Applied usleep_range intead of using mdelay
Changes : Applied 10ms delay after amp software reset.
10ms guard time is required for stability.
sound/soc/codecs/max98373.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
Hi Rob, Jassi,
2018-08-23 23:12 GMT+09:00 Jassi Brar :
> On 23 August 2018 at 18:51, Rob Herring wrote:
>> On Thu, Aug 23, 2018 at 12:38 AM Jassi Brar
>> wrote:
>>> On 23 August 2018 at 10:48, Masahiro Yamada
>
>>> >
>>> > If desired, I will export of_irq_count()
>>> > and use it from my
Hi Rob, Jassi,
2018-08-23 23:12 GMT+09:00 Jassi Brar :
> On 23 August 2018 at 18:51, Rob Herring wrote:
>> On Thu, Aug 23, 2018 at 12:38 AM Jassi Brar
>> wrote:
>>> On 23 August 2018 at 10:48, Masahiro Yamada
>
>>> >
>>> > If desired, I will export of_irq_count()
>>> > and use it from my
In ubifs_log_start_commit, the value of c->lhead_offs is zero or set
to zero by code bellow.
/* Switch to the next log LEB */
if (c->lhead_offs) {
c->lhead_lnum = ubifs_next_log_lnum(c, c->lhead_lnum);
ubifs_assert(c->lhead_lnum != c->ltail_lnum);
In ubifs_log_start_commit, the value of c->lhead_offs is zero or set
to zero by code bellow.
/* Switch to the next log LEB */
if (c->lhead_offs) {
c->lhead_lnum = ubifs_next_log_lnum(c, c->lhead_lnum);
ubifs_assert(c->lhead_lnum != c->ltail_lnum);
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance =
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance =
1 - 100 of 2464 matches
Mail list logo
