Hi,
On Fri, Aug 10, 2018 at 9:13 AM, Mark Brown wrote:
> On Fri, Aug 10, 2018 at 08:40:17AM -0700, Doug Anderson wrote:
>> On Fri, Aug 10, 2018 at 3:52 AM, Mark Brown wrote:
>
>> > This is more about matching the data rate between the two drivers - the
>> > clock framework could (and possibly
Hi,
On Fri, Aug 10, 2018 at 9:13 AM, Mark Brown wrote:
> On Fri, Aug 10, 2018 at 08:40:17AM -0700, Doug Anderson wrote:
>> On Fri, Aug 10, 2018 at 3:52 AM, Mark Brown wrote:
>
>> > This is more about matching the data rate between the two drivers - the
>> > clock framework could (and possibly
Hi Peter,
On 8/8/2018 10:33 AM, Reinette Chatre wrote:
> On 8/8/2018 12:51 AM, Peter Zijlstra wrote:
>> On Tue, Aug 07, 2018 at 03:47:15PM -0700, Reinette Chatre wrote:
- I don't much fancy people accessing the guts of events like that;
would not an inline function like:
Hi Peter,
On 8/8/2018 10:33 AM, Reinette Chatre wrote:
> On 8/8/2018 12:51 AM, Peter Zijlstra wrote:
>> On Tue, Aug 07, 2018 at 03:47:15PM -0700, Reinette Chatre wrote:
- I don't much fancy people accessing the guts of events like that;
would not an inline function like:
For as low as 2000 USD Study in Aurora College
Aurora college is giving easy admission to 500 international students. We
provide VISAs for international students to LIVE and WORK while they study
here.
Aurora College is a private co-educational institution dedicated to academic
excellence
On 08/10/2018 07:16 AM, Cornelia Huck wrote:
On Fri, 10 Aug 2018 12:49:08 +0200
Pierre Morel wrote:
On 10/08/2018 11:14, Cornelia Huck wrote:
On Wed, 8 Aug 2018 10:44:27 -0400
Tony Krowiak wrote:
From: Tony Krowiak
Let's call PAPQ(ZAPQ) to zeroize a queue:
* For each queue
For as low as 2000 USD Study in Aurora College
Aurora college is giving easy admission to 500 international students. We
provide VISAs for international students to LIVE and WORK while they study
here.
Aurora College is a private co-educational institution dedicated to academic
excellence
On 08/10/2018 07:16 AM, Cornelia Huck wrote:
On Fri, 10 Aug 2018 12:49:08 +0200
Pierre Morel wrote:
On 10/08/2018 11:14, Cornelia Huck wrote:
On Wed, 8 Aug 2018 10:44:27 -0400
Tony Krowiak wrote:
From: Tony Krowiak
Let's call PAPQ(ZAPQ) to zeroize a queue:
* For each queue
From: Masayoshi Mizuma
There are some exceptional cases that the padding used for the physical
memory mapping section is not enough.
For example of the cases:
- As Baoquan reported in the following, SGI UV system.
https://lkml.org/lkml/2017/9/7/87
- Each node of physical memory layout has
From: Masayoshi Mizuma
There are some exceptional cases that the padding used for the physical
memory mapping section is not enough.
For example of the cases:
- As Baoquan reported in the following, SGI UV system.
https://lkml.org/lkml/2017/9/7/87
- Each node of physical memory layout has
From: Masayoshi Mizuma
This kernel parameter allows to change the padding used for the physical
memory mapping section when KASLR memory is enabled.
For some systems, the default value, CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING,
is not enough. The option is useful to adjust the padding size to
From: Masayoshi Mizuma
This kernel parameter allows to change the padding used for the physical
memory mapping section when KASLR memory is enabled.
For some systems, the default value, CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING,
is not enough. The option is useful to adjust the padding size to
This is another ashmem lockdep splat. Forwarding to the appropriate ashmem
people.
On Fri, Aug 10, 2018 at 04:59:02AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:4110b42356f3 Add linux-next specific files for 20180810
> git
This is another ashmem lockdep splat. Forwarding to the appropriate ashmem
people.
On Fri, Aug 10, 2018 at 04:59:02AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:4110b42356f3 Add linux-next specific files for 20180810
> git
On Fri, Aug 10 2018 at 09:06 -0600, Stephen Boyd wrote:
Quoting Marc Zyngier (2018-08-10 00:45:12)
On Thu, 09 Aug 2018 18:30:53 +0100,
Stephen Boyd wrote:
>
> Quoting Marc Zyngier (2018-08-07 23:26:32)
> >
> > Level interrupts should be taken care of without doing anything, by the
> > very
On Fri, Aug 10 2018 at 09:06 -0600, Stephen Boyd wrote:
Quoting Marc Zyngier (2018-08-10 00:45:12)
On Thu, 09 Aug 2018 18:30:53 +0100,
Stephen Boyd wrote:
>
> Quoting Marc Zyngier (2018-08-07 23:26:32)
> >
> > Level interrupts should be taken care of without doing anything, by the
> > very
Hi Daniel,
A kernel bug report was opened against Ubuntu [0]. It was found the
following patch introduced the regression:
da9970668948 ("usb: xhci: Add XHCI_TRUST_TX_LENGTH for Renesas uPD720201")
The bug reporter claims there is a typo in the patch that caused the
regression. I built a test
Hi Daniel,
A kernel bug report was opened against Ubuntu [0]. It was found the
following patch introduced the regression:
da9970668948 ("usb: xhci: Add XHCI_TRUST_TX_LENGTH for Renesas uPD720201")
The bug reporter claims there is a typo in the patch that caused the
regression. I built a test
On 08/09/2018 01:58 AM, Janosch Frank wrote:
On 08.08.2018 16:44, Tony Krowiak wrote:
From: Tony Krowiak
This patch refactors the code that initializes and sets up the
crypto configuration for a guest. The following changes are
implemented via this patch:
1. Prior to the introduction of AP
On 08/09/2018 01:58 AM, Janosch Frank wrote:
On 08.08.2018 16:44, Tony Krowiak wrote:
From: Tony Krowiak
This patch refactors the code that initializes and sets up the
crypto configuration for a guest. The following changes are
implemented via this patch:
1. Prior to the introduction of AP
On Fri, Aug 10, 2018 at 08:40:17AM -0700, Doug Anderson wrote:
> On Fri, Aug 10, 2018 at 3:52 AM, Mark Brown wrote:
> > This is more about matching the data rate between the two drivers - the
> > clock framework could (and possibly should) reasonably return an error
> > here, we're trying to
On Fri, Aug 10, 2018 at 08:40:17AM -0700, Doug Anderson wrote:
> On Fri, Aug 10, 2018 at 3:52 AM, Mark Brown wrote:
> > This is more about matching the data rate between the two drivers - the
> > clock framework could (and possibly should) reasonably return an error
> > here, we're trying to
This is more an RFC in the original sense: is this basically
the correct approach? (as I had to tweak the API a bit).
In particular the code does not detect interrupts and exception
frames, and does not yet check whether the code address is valid.
The latter check would also have to be omitted
This is more an RFC in the original sense: is this basically
the correct approach? (as I had to tweak the API a bit).
In particular the code does not detect interrupts and exception
frames, and does not yet check whether the code address is valid.
The latter check would also have to be omitted
Based on ftrace with regs, do the usual thing. Also allocate a
task flag for whatever consistency handling is implemented.
Watch out for interactions with the graph tracer.
This code has been compile-tested, but has not yet seen any
heavy livepatching.
Signed-off-by: Torsten Duwe
diff --git
Based on ftrace with regs, do the usual thing. Also allocate a
task flag for whatever consistency handling is implemented.
Watch out for interactions with the graph tracer.
This code has been compile-tested, but has not yet seen any
heavy livepatching.
Signed-off-by: Torsten Duwe
diff --git
Check for compiler support of -fpatchable-function-entry and use it
to intercept functions immediately on entry, saving the LR in x9.
Disable ftracing in efi/libstub, because this triggers cross-section
linker errors now (-pg used to be disabled already).
Add an ftrace_caller which can handle LR
Check for compiler support of -fpatchable-function-entry and use it
to intercept functions immediately on entry, saving the LR in x9.
Disable ftracing in efi/libstub, because this triggers cross-section
linker errors now (-pg used to be disabled already).
Add an ftrace_caller which can handle LR
Hi all,
with gcc-8 now being out which includes the patchable-function-entries feature,
I can now propose the live patching framework based on it. The series consists
of 3 parts:
1st: Implement ftrace with regs -- uses gcc-8's nop insertions to patch in
ftrace calls.
2nd: "Classic" live
Hi all,
with gcc-8 now being out which includes the patchable-function-entries feature,
I can now propose the live patching framework based on it. The series consists
of 3 parts:
1st: Implement ftrace with regs -- uses gcc-8's nop insertions to patch in
ftrace calls.
2nd: "Classic" live
On 08/10/2018 05:37 AM, Harald Freudenberger wrote:
On 10.08.2018 10:49, Cornelia Huck wrote:
On Thu, 9 Aug 2018 12:06:56 -0400
Tony Krowiak wrote:
On 08/09/2018 05:17 AM, Harald Freudenberger wrote:
On 09.08.2018 11:06, Cornelia Huck wrote:
On Wed, 8 Aug 2018 10:44:14 -0400
Tony Krowiak
On 08/10/2018 05:37 AM, Harald Freudenberger wrote:
On 10.08.2018 10:49, Cornelia Huck wrote:
On Thu, 9 Aug 2018 12:06:56 -0400
Tony Krowiak wrote:
On 08/09/2018 05:17 AM, Harald Freudenberger wrote:
On 09.08.2018 11:06, Cornelia Huck wrote:
On Wed, 8 Aug 2018 10:44:14 -0400
Tony Krowiak
On 08/10/2018 04:49 AM, Cornelia Huck wrote:
On Thu, 9 Aug 2018 12:06:56 -0400
Tony Krowiak wrote:
On 08/09/2018 05:17 AM, Harald Freudenberger wrote:
On 09.08.2018 11:06, Cornelia Huck wrote:
On Wed, 8 Aug 2018 10:44:14 -0400
Tony Krowiak wrote:
From: Harald Freudenberger
Move all
On 08/10/2018 04:49 AM, Cornelia Huck wrote:
On Thu, 9 Aug 2018 12:06:56 -0400
Tony Krowiak wrote:
On 08/09/2018 05:17 AM, Harald Freudenberger wrote:
On 09.08.2018 11:06, Cornelia Huck wrote:
On Wed, 8 Aug 2018 10:44:14 -0400
Tony Krowiak wrote:
From: Harald Freudenberger
Move all
On Fri, Aug 10, 2018 at 01:17:14PM +1000, NeilBrown wrote:
> On Thu, Aug 09 2018, J. Bruce Fields wrote:
>
> > On Fri, Aug 10, 2018 at 11:50:58AM +1000, NeilBrown wrote:
> >> You're good at this game!
> >
> > Everybody's got to have a hobby, mine is pathological posix locking
> > cases
> >
>
On Fri, Aug 10, 2018 at 01:17:14PM +1000, NeilBrown wrote:
> On Thu, Aug 09 2018, J. Bruce Fields wrote:
>
> > On Fri, Aug 10, 2018 at 11:50:58AM +1000, NeilBrown wrote:
> >> You're good at this game!
> >
> > Everybody's got to have a hobby, mine is pathological posix locking
> > cases
> >
>
Add setup_platform_service_irq hook to struct pci_host_bridge.
Some platforms have dedicated interrupt line from root complex to
interrupt controller for PCIe services like AER/PME etc.
This hook is to register platform IRQ's to PCIe port services.
Signed-off-by: Bharat Kumar Gogada
---
Add nwl_setup_service_irqs hook to setup_platform_service_irq IRQs to
register platform provided IRQ number to kernel AER service.
Signed-off-by: Bharat Kumar Gogada
---
drivers/pci/controller/pcie-xilinx-nwl.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff
Add setup_platform_service_irq hook to struct pci_host_bridge.
Some platforms have dedicated interrupt line from root complex to
interrupt controller for PCIe services like AER/PME etc.
This hook is to register platform IRQ's to PCIe port services.
Signed-off-by: Bharat Kumar Gogada
---
Add nwl_setup_service_irqs hook to setup_platform_service_irq IRQs to
register platform provided IRQ number to kernel AER service.
Signed-off-by: Bharat Kumar Gogada
---
drivers/pci/controller/pcie-xilinx-nwl.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff
Some platforms have dedicated IRQ lines for PCIe services like
AER/PME etc. The root complex on these platform will use these seperate
IRQ lines to report AER/PME etc., interrupts and will not generate
MSI/MSI-X/INTx interrupts for these services.
These patches will add new method for these kind
Some platforms have dedicated IRQ lines for PCIe services like
AER/PME etc. The root complex on these platform will use these seperate
IRQ lines to report AER/PME etc., interrupts and will not generate
MSI/MSI-X/INTx interrupts for these services.
These patches will add new method for these kind
Platforms may have dedicated IRQ lines for PCIe services like
AER/PME etc., check for such IRQ lines.
Check mask and fill legacy irq line for services other than
platform supported service IRQ number.
Signed-off-by: Bharat Kumar Gogada
---
drivers/pci/pcie/portdrv_core.c | 19
Adding method pci_check_platform_service_irqs to check if platform
has registered method to proivde dedicated IRQ lines for PCIe services
like AER/PME etc.
Signed-off-by: Bharat Kumar Gogada
---
include/linux/pci.h | 24
1 files changed, 24 insertions(+), 0
Platforms may have dedicated IRQ lines for PCIe services like
AER/PME etc., check for such IRQ lines.
Check mask and fill legacy irq line for services other than
platform supported service IRQ number.
Signed-off-by: Bharat Kumar Gogada
---
drivers/pci/pcie/portdrv_core.c | 19
Adding method pci_check_platform_service_irqs to check if platform
has registered method to proivde dedicated IRQ lines for PCIe services
like AER/PME etc.
Signed-off-by: Bharat Kumar Gogada
---
include/linux/pci.h | 24
1 files changed, 24 insertions(+), 0
x86_pmu_{format,events,attr,caps}_group is written to in
init_hw_perf_events and not modified after. This makes them suitable
candidates for annotating as __ro_after_init.
Signed-off-by: Zubin Mithra
---
arch/x86/events/core.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff
x86_pmu_{format,events,attr,caps}_group is written to in
init_hw_perf_events and not modified after. This makes them suitable
candidates for annotating as __ro_after_init.
Signed-off-by: Zubin Mithra
---
arch/x86/events/core.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff
Hi,
On Fri, Aug 10, 2018 at 3:52 AM, Mark Brown wrote:
> On Thu, Aug 09, 2018 at 11:03:55AM -0700, Doug Anderson wrote:
>> On Fri, Aug 3, 2018 at 5:18 AM, wrote:
>
>> > Also, spi core framework will set the transfer speed to controller max
>> > frequency
>> > if transfer frequency is greater
Hi,
On Fri, Aug 10, 2018 at 3:52 AM, Mark Brown wrote:
> On Thu, Aug 09, 2018 at 11:03:55AM -0700, Doug Anderson wrote:
>> On Fri, Aug 3, 2018 at 5:18 AM, wrote:
>
>> > Also, spi core framework will set the transfer speed to controller max
>> > frequency
>> > if transfer frequency is greater
On 08/09/2018 08:11 PM, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2018-08-09-20-10 has been uploaded to
>
>http://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of
On 08/09/2018 08:11 PM, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2018-08-09-20-10 has been uploaded to
>
>http://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of
On Mon, 30 Jul 2018 15:24:22 -0700
Joel Fernandes wrote:
> From: "Joel Fernandes (Google)"
>
> In recent tests with IRQ on/off tracepoints, a large performance
> overhead ~10% is noticed when running hackbench. This is root caused to
> calls to rcu_irq_enter_irqson and rcu_irq_exit_irqson from
On Mon, 30 Jul 2018 15:24:22 -0700
Joel Fernandes wrote:
> From: "Joel Fernandes (Google)"
>
> In recent tests with IRQ on/off tracepoints, a large performance
> overhead ~10% is noticed when running hackbench. This is root caused to
> calls to rcu_irq_enter_irqson and rcu_irq_exit_irqson from
From: Oscar Salvador
unregister_memory_section() calls remove_memory_section()
with three arguments:
* node_id
* section
* phys_device
Neither node_id nor phys_device are used.
Let us drop them from the function.
Signed-off-by: Oscar Salvador
---
drivers/base/memory.c | 5 ++---
1 file
From: Oscar Salvador
unregister_memory_section() calls remove_memory_section()
with three arguments:
* node_id
* section
* phys_device
Neither node_id nor phys_device are used.
Let us drop them from the function.
Signed-off-by: Oscar Salvador
---
drivers/base/memory.c | 5 ++---
1 file
From: Oscar Salvador
This patchset is about cleaning up/refactoring a few functions
from the memory-hotplug code.
The first and the second patch are pretty straightforward, as they
only remove unused arguments/checks.
The third one change the layout of the unregister_mem_sect_under_nodes a bit.
From: Oscar Salvador
This patchset is about cleaning up/refactoring a few functions
from the memory-hotplug code.
The first and the second patch are pretty straightforward, as they
only remove unused arguments/checks.
The third one change the layout of the unregister_mem_sect_under_nodes a bit.
From: Oscar Salvador
Before calling to unregister_mem_sect_under_nodes(),
remove_memory_section() already checks if we got a valid
memory_block.
No need to check that again in unregister_mem_sect_under_nodes().
Signed-off-by: Oscar Salvador
---
drivers/base/node.c | 4
1 file changed, 4
From: Oscar Salvador
Before calling to unregister_mem_sect_under_nodes(),
remove_memory_section() already checks if we got a valid
memory_block.
No need to check that again in unregister_mem_sect_under_nodes().
Signed-off-by: Oscar Salvador
---
drivers/base/node.c | 4
1 file changed, 4
From: Oscar Salvador
With the assumption that the relationship between
memory_block <-> node is 1:1, we can refactor this function a bit.
This assumption is being taken from register_mem_sect_under_node()
code.
register_mem_sect_under_node() takes the mem_blk's nid, and compares it
to the
From: Oscar Salvador
With the assumption that the relationship between
memory_block <-> node is 1:1, we can refactor this function a bit.
This assumption is being taken from register_mem_sect_under_node()
code.
register_mem_sect_under_node() takes the mem_blk's nid, and compares it
to the
Hi Jacek,
On 9 August 2018 at 21:21, Jacek Anaszewski wrote:
> Hi Baolin,
>
> On 08/09/2018 07:48 AM, Baolin Wang wrote:
> [...]
>> +static int pattern_trig_start_pattern(struct pattern_trig_data *data,
>> + struct led_classdev *led_cdev)
>> +{
Hi Jacek,
On 9 August 2018 at 21:21, Jacek Anaszewski wrote:
> Hi Baolin,
>
> On 08/09/2018 07:48 AM, Baolin Wang wrote:
> [...]
>> +static int pattern_trig_start_pattern(struct pattern_trig_data *data,
>> + struct led_classdev *led_cdev)
>> +{
On Fri, Aug 10, 2018 at 11:11:55AM +, Leonard Crestez wrote:
[...]
> This needs further clarification: without the reset patch this will
> hang on imx7 suspend/resume but this is the current behavior anyway.
>
> Both patches are required for imx7 pci suspend and including them out
> of
On Fri, Aug 10, 2018 at 11:11:55AM +, Leonard Crestez wrote:
[...]
> This needs further clarification: without the reset patch this will
> hang on imx7 suspend/resume but this is the current behavior anyway.
>
> Both patches are required for imx7 pci suspend and including them out
> of
Quoting Bjorn Andersson (2018-08-09 15:01:19)
> From: Rajendra Nayak
>
> Add a few missing gcc clks for msm8996
>
> Signed-off-by: Rajendra Nayak
> [bjorn: omit aggre0_noc_qosgen_extref_clk]
> Signed-off-by: Bjorn Andersson
> ---
This is still going on?! I'm going to ignore Rob's auto email
Quoting Bjorn Andersson (2018-08-09 15:01:19)
> From: Rajendra Nayak
>
> Add a few missing gcc clks for msm8996
>
> Signed-off-by: Rajendra Nayak
> [bjorn: omit aggre0_noc_qosgen_extref_clk]
> Signed-off-by: Bjorn Andersson
> ---
This is still going on?! I'm going to ignore Rob's auto email
Quoting Marc Zyngier (2018-08-10 00:45:12)
> On Thu, 09 Aug 2018 18:30:53 +0100,
> Stephen Boyd wrote:
> >
> > Quoting Marc Zyngier (2018-08-07 23:26:32)
> > >
> > > Level interrupts should be taken care of without doing anything, by the
> > > very nature of being a level signal.
> >
> >
Quoting Marc Zyngier (2018-08-10 00:45:12)
> On Thu, 09 Aug 2018 18:30:53 +0100,
> Stephen Boyd wrote:
> >
> > Quoting Marc Zyngier (2018-08-07 23:26:32)
> > >
> > > Level interrupts should be taken care of without doing anything, by the
> > > very nature of being a level signal.
> >
> >
Instead of open-coding pos & (PAGE_SIZE - 1) and pos & ~PAGE_MASK, use
the offset_in_page macro.
Signed-off-by: Andreas Gruenbacher
---
fs/iomap.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/fs/iomap.c b/fs/iomap.c
index 13cdcf33e6c0..ae317ac7e925
Instead of open-coding pos & (PAGE_SIZE - 1) and pos & ~PAGE_MASK, use
the offset_in_page macro.
Signed-off-by: Andreas Gruenbacher
---
fs/iomap.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/fs/iomap.c b/fs/iomap.c
index 13cdcf33e6c0..ae317ac7e925
Note: It is a part time job that won't interrupt your present work or business.
Looking forward to your response.
Best Regards,
Liu Nianzu
HR(Representative Manager)
Beijing Shougang Company Ltd.
No 15,Pingguoyuan Road,Shijingshan District,Beijing
Website: www.sggf.com.cn
Note: It is a part time job that won't interrupt your present work or business.
Looking forward to your response.
Best Regards,
Liu Nianzu
HR(Representative Manager)
Beijing Shougang Company Ltd.
No 15,Pingguoyuan Road,Shijingshan District,Beijing
Website: www.sggf.com.cn
Currently we support only platform data for specifying the interconnect
endpoints. As now the endpoints are hard-coded into the consumer driver
this may lead to complications when a single driver is used by multiple
SoCs, which may have different interconnect topology.
To avoid cluttering the
On some Qualcomm SoCs, there is a remote processor, which controls some of
the Network-On-Chip interconnect resources. Other CPUs express their needs
by communicating with this processor. Add a driver to handle communication
with this remote processor.
Signed-off-by: Georgi Djakov
Reviewed-by:
Currently we support only platform data for specifying the interconnect
endpoints. As now the endpoints are hard-coded into the consumer driver
this may lead to complications when a single driver is used by multiple
SoCs, which may have different interconnect topology.
To avoid cluttering the
On some Qualcomm SoCs, there is a remote processor, which controls some of
the Network-On-Chip interconnect resources. Other CPUs express their needs
by communicating with this processor. Add a driver to handle communication
with this remote processor.
Signed-off-by: Georgi Djakov
Reviewed-by:
Add myself as the maintainer of the interconnect API.
Signed-off-by: Georgi Djakov
---
MAINTAINERS | 10 ++
1 file changed, 10 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 32fbc6f732d4..ed1b534c901b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7420,6 +7420,16 @@ L:
Document the device-tree bindings of the Network-On-Chip interconnect
hardware found on Qualcomm msm8916 platforms.
Signed-off-by: Georgi Djakov
Reviewed-by: Evan Green
---
.../bindings/interconnect/qcom-msm8916.txt| 41
include/dt-bindings/interconnect/qcom.h | 98
Add driver for the Qualcomm interconnect buses found in msm8916 based
platforms.
Signed-off-by: Georgi Djakov
---
drivers/interconnect/Kconfig| 5 +
drivers/interconnect/Makefile | 1 +
drivers/interconnect/qcom/Kconfig | 9 +
drivers/interconnect/qcom/Makefile | 2 +
Add myself as the maintainer of the interconnect API.
Signed-off-by: Georgi Djakov
---
MAINTAINERS | 10 ++
1 file changed, 10 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 32fbc6f732d4..ed1b534c901b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7420,6 +7420,16 @@ L:
Document the device-tree bindings of the Network-On-Chip interconnect
hardware found on Qualcomm msm8916 platforms.
Signed-off-by: Georgi Djakov
Reviewed-by: Evan Green
---
.../bindings/interconnect/qcom-msm8916.txt| 41
include/dt-bindings/interconnect/qcom.h | 98
Add driver for the Qualcomm interconnect buses found in msm8916 based
platforms.
Signed-off-by: Georgi Djakov
---
drivers/interconnect/Kconfig| 5 +
drivers/interconnect/Makefile | 1 +
drivers/interconnect/qcom/Kconfig | 9 +
drivers/interconnect/qcom/Makefile | 2 +
Modern SoCs have multiple processors and various dedicated cores (video, gpu,
graphics, modem). These cores are talking to each other and can generate a
lot of data flowing through the on-chip interconnects. These interconnect
buses could form different topologies such as crossbar, point to point
This binding is intended to represent the relations between the interconnect
controllers (providers) and consumer device nodes. It will allow creating links
between consumers and interconnect paths (exposed by interconnect providers).
Signed-off-by: Georgi Djakov
---
This patch introduces a new API to get requirements and configure the
interconnect buses across the entire chipset to fit with the current
demand.
The API is using a consumer/provider-based model, where the providers are
the interconnect buses and the consumers could be various drivers.
The
Add a functionality to provide information about the current constraints
per each node and provider.
Signed-off-by: Georgi Djakov
Reviewed-by: Evan Green
---
drivers/interconnect/core.c | 78 +
1 file changed, 78 insertions(+)
diff --git
Modern SoCs have multiple processors and various dedicated cores (video, gpu,
graphics, modem). These cores are talking to each other and can generate a
lot of data flowing through the on-chip interconnects. These interconnect
buses could form different topologies such as crossbar, point to point
This binding is intended to represent the relations between the interconnect
controllers (providers) and consumer device nodes. It will allow creating links
between consumers and interconnect paths (exposed by interconnect providers).
Signed-off-by: Georgi Djakov
---
This patch introduces a new API to get requirements and configure the
interconnect buses across the entire chipset to fit with the current
demand.
The API is using a consumer/provider-based model, where the providers are
the interconnect buses and the consumers could be various drivers.
The
Add a functionality to provide information about the current constraints
per each node and provider.
Signed-off-by: Georgi Djakov
Reviewed-by: Evan Green
---
drivers/interconnect/core.c | 78 +
1 file changed, 78 insertions(+)
diff --git
My mistake. Initially, I thought that this line signals about errors
in the code, but now I see that this is about the tool's internal
error. However, this doesn't change the fact that coccicheck returns
the improper error code.
I will reformulate the commit message and send the v2 patch with the
My mistake. Initially, I thought that this line signals about errors
in the code, but now I see that this is about the tool's internal
error. However, this doesn't change the fact that coccicheck returns
the improper error code.
I will reformulate the commit message and send the v2 patch with the
Hello,
syzbot found the following crash on:
HEAD commit:8c8399e0a3fb Add linux-next specific files for 20180806
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16c6b8e240
kernel config: https://syzkaller.appspot.com/x/.config?x=1b6bc1781e49e93e
Hello,
syzbot found the following crash on:
HEAD commit:8c8399e0a3fb Add linux-next specific files for 20180806
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16c6b8e240
kernel config: https://syzkaller.appspot.com/x/.config?x=1b6bc1781e49e93e
On Fri, 10 Aug 2018, Denis Efremov wrote:
> > Do you mean that there is an error in the behavior of coccicheck or that
> > coccicheck finds an error in the source code?
>
> An error in the source code.
>
> Here is an example of how the patch changes the behavior of 'make
> coccicheck' (my
On Fri, 10 Aug 2018, Denis Efremov wrote:
> > Do you mean that there is an error in the behavior of coccicheck or that
> > coccicheck finds an error in the source code?
>
> An error in the source code.
>
> Here is an example of how the patch changes the behavior of 'make
> coccicheck' (my
On Fri, Aug 10, 2018 at 11:00 PM, Michal Hocko wrote:
> On Fri 10-08-18 16:55:40, Rashmica Gupta wrote:
> [...]
>> Most memory hotplug/hotremove seems to be block or section based, and
>> always adds and removes memory at the same place.
>
> Yes and that is hard wired to the memory hotplug code.
On Fri, Aug 10, 2018 at 11:00 PM, Michal Hocko wrote:
> On Fri 10-08-18 16:55:40, Rashmica Gupta wrote:
> [...]
>> Most memory hotplug/hotremove seems to be block or section based, and
>> always adds and removes memory at the same place.
>
> Yes and that is hard wired to the memory hotplug code.
401 - 500 of 854 matches
Mail list logo
