On Sat, 06 Oct 2018 08:28:11 +0100,
Lokesh Vutla wrote:
>
> Add the DT binding documentation for Interrupt router driver.
>
> Signed-off-by: Lokesh Vutla
> ---
> .../interrupt-controller/ti,sci-intr.txt | 83 +++
> MAINTAINERS | 1 +
> 2
On Sat, 06 Oct 2018 08:28:11 +0100,
Lokesh Vutla wrote:
>
> Add the DT binding documentation for Interrupt router driver.
>
> Signed-off-by: Lokesh Vutla
> ---
> .../interrupt-controller/ti,sci-intr.txt | 83 +++
> MAINTAINERS | 1 +
> 2
Hi Lokesh,
On Sat, 06 Oct 2018 08:28:12 +0100,
Lokesh Vutla wrote:
>
> Texas Instruments' K3 generation SoCs has an IP Interrupt Router
> that does allows for multiplexing of input interrupts to host
> interrupt controller. Interrupt Router inputs are either from a
> peripheral or from an
Hi Lokesh,
On Sat, 06 Oct 2018 08:28:12 +0100,
Lokesh Vutla wrote:
>
> Texas Instruments' K3 generation SoCs has an IP Interrupt Router
> that does allows for multiplexing of input interrupts to host
> interrupt controller. Interrupt Router inputs are either from a
> peripheral or from an
When an invalid mount option is passed to jffs2, jffs2_parse_options()
will fail and jffs2_sb_info will be freed, but then jffs2_sb_info will
be used (use-after-free) and freeed (double-free) in jffs2_kill_sb().
Fix it by removing the buggy invocation of kfree() when getting invalid
mount
When an invalid mount option is passed to jffs2, jffs2_parse_options()
will fail and jffs2_sb_info will be freed, but then jffs2_sb_info will
be used (use-after-free) and freeed (double-free) in jffs2_kill_sb().
Fix it by removing the buggy invocation of kfree() when getting invalid
mount
I'm trying to get a new system and running with kernel 4.18.12, but run
into an APIC error as seen in [1].
It is a new system, never tried older kernels till now.
The kernel command line "noapic" doesn't help, now I do wonder what else
I can do.
The same kernel config was fine for 2 years with
On Fri, Oct 05, 2018 at 08:14:34PM -0700, Joel Fernandes wrote:
On Fri, Oct 05, 2018 at 05:22:35PM -0700, Greg KH wrote:
On Fri, Oct 05, 2018 at 05:04:16PM -0700, Kees Cook wrote:
> On Fri, Oct 5, 2018 at 4:51 PM, Greg KH wrote:
> > On Fri, Oct 05, 2018 at 04:35:59PM -0700, Kees Cook wrote:
>
I'm trying to get a new system and running with kernel 4.18.12, but run
into an APIC error as seen in [1].
It is a new system, never tried older kernels till now.
The kernel command line "noapic" doesn't help, now I do wonder what else
I can do.
The same kernel config was fine for 2 years with
On Fri, Oct 05, 2018 at 08:14:34PM -0700, Joel Fernandes wrote:
On Fri, Oct 05, 2018 at 05:22:35PM -0700, Greg KH wrote:
On Fri, Oct 05, 2018 at 05:04:16PM -0700, Kees Cook wrote:
> On Fri, Oct 5, 2018 at 4:51 PM, Greg KH wrote:
> > On Fri, Oct 05, 2018 at 04:35:59PM -0700, Kees Cook wrote:
>
On Saturday 06 October 2018 16:33:10 chen.chenchacha wrote:
> On Thu, 2018-10-04 at 19:33 +0200, Pali Rohár wrote:
> > On Friday 05 October 2018 01:21:00 chenchacha wrote:
> > > Signed-off-by: chenchacha
> > > ---
> > > fs/fat/file.c | 22 ++
> > >
On Saturday 06 October 2018 16:33:10 chen.chenchacha wrote:
> On Thu, 2018-10-04 at 19:33 +0200, Pali Rohár wrote:
> > On Friday 05 October 2018 01:21:00 chenchacha wrote:
> > > Signed-off-by: chenchacha
> > > ---
> > > fs/fat/file.c | 22 ++
> > >
Arnd,
On Fri, 5 Oct 2018 at 09:17, Arnd Bergmann wrote:
>
> The check for __HAVE_ARCH_HUGE_PTEP_GET comes before the definition,
> leading to an extraneous definition of huge_ptep_get:
>
> In file included from arch/arm/include/asm/hugetlb.h:28,
> from
Arnd,
On Fri, 5 Oct 2018 at 09:17, Arnd Bergmann wrote:
>
> The check for __HAVE_ARCH_HUGE_PTEP_GET comes before the definition,
> leading to an extraneous definition of huge_ptep_get:
>
> In file included from arch/arm/include/asm/hugetlb.h:28,
> from
Texas Instruments' K3 generation SoCs has an IP Interrupt Router
that does allows for multiplexing of input interrupts to host
interrupt controller. Interrupt Router inputs are either from a
peripheral or from an Interrupt Aggregator which is another
interrupt controller.
Configuration of the
This series adds irqchip driver for Texas Instruments' K3 based
Interrupt Router.
This series depends on TISCI IRQ management support posted here[1]
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-October/605784.html
Lokesh Vutla (2):
dt-bindings: irqchip: Introduce TISCI
Add the DT binding documentation for Interrupt router driver.
Signed-off-by: Lokesh Vutla
---
.../interrupt-controller/ti,sci-intr.txt | 83 +++
MAINTAINERS | 1 +
2 files changed, 84 insertions(+)
create mode 100644
Add the DT binding documentation for Interrupt router driver.
Signed-off-by: Lokesh Vutla
---
.../interrupt-controller/ti,sci-intr.txt | 83 +++
MAINTAINERS | 1 +
2 files changed, 84 insertions(+)
create mode 100644
Texas Instruments' K3 generation SoCs has an IP Interrupt Router
that does allows for multiplexing of input interrupts to host
interrupt controller. Interrupt Router inputs are either from a
peripheral or from an Interrupt Aggregator which is another
interrupt controller.
Configuration of the
This series adds irqchip driver for Texas Instruments' K3 based
Interrupt Router.
This series depends on TISCI IRQ management support posted here[1]
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-October/605784.html
Lokesh Vutla (2):
dt-bindings: irqchip: Introduce TISCI
Fixed all meaningful sparse errors:
1. Added static to udc_controller
2. Added mising __iomem modifier to handle p_regs
3. Added missing le16_to_cpu
Signed-off-by: Tamir Carmeli
---
drivers/staging/emxx_udc/emxx_udc.c | 69 +++--
Fixed all meaningful sparse errors:
1. Added static to udc_controller
2. Added mising __iomem modifier to handle p_regs
3. Added missing le16_to_cpu
Signed-off-by: Tamir Carmeli
---
drivers/staging/emxx_udc/emxx_udc.c | 69 +++--
Thanks for the review.
> On 31-07-18, 23:16, Radhey Shyam Pandey wrote:
> > struct xilinx_dma_config {
> > @@ -402,6 +470,7 @@ struct xilinx_dma_config {
> > int (*clk_init)(struct platform_device *pdev, struct clk **axi_clk,
> > struct clk **tx_clk, struct clk **txs_clk,
Thanks for the review.
> On 31-07-18, 23:16, Radhey Shyam Pandey wrote:
> > struct xilinx_dma_config {
> > @@ -402,6 +470,7 @@ struct xilinx_dma_config {
> > int (*clk_init)(struct platform_device *pdev, struct clk **axi_clk,
> > struct clk **tx_clk, struct clk **txs_clk,
On Sat, Oct 06, 2018 at 11:31:04AM +0800, peng.h...@zte.com.cn wrote:
>>On Thu, Oct 04, 2018 at 01:47:18PM -0400, Peng Hao wrote:
>>>
>>>From: Peng Hao
>>>
>>> modify AVIC_LOGICAL_ID_ENTRY_VALID_MASK to unsigned
>>>
>>>Signed-off-by: Peng Hao
>>>---
>>> arch/x86/kvm/svm.c | 2 +-
>>> 1 file
On Sat, Oct 06, 2018 at 11:31:04AM +0800, peng.h...@zte.com.cn wrote:
>>On Thu, Oct 04, 2018 at 01:47:18PM -0400, Peng Hao wrote:
>>>
>>>From: Peng Hao
>>>
>>> modify AVIC_LOGICAL_ID_ENTRY_VALID_MASK to unsigned
>>>
>>>Signed-off-by: Peng Hao
>>>---
>>> arch/x86/kvm/svm.c | 2 +-
>>> 1 file
This adds support to show the Latency Tolerance Reporting for the IPs on
the PCH as reported by the PMC. The format shown here is raw LTR data
payload that can further be decoded as per the PCI specification.
This also fixes some minor alignment issues in the header file by
removing spaces and
On Mon 24 Sep 04:07 PDT 2018, Rohit kumar wrote:
> This adds Non PAS ADSP PIL driver for Qualcomm
> Technologies Inc SoCs.
> Added initial support for SDM845 with ADSP bootup and
> shutdown operation handled from Application Processor
> SubSystem(APSS).
>
> Signed-off-by: Rohit kumar
Sorry for
This adds support to show the Latency Tolerance Reporting for the IPs on
the PCH as reported by the PMC. The format shown here is raw LTR data
payload that can further be decoded as per the PCI specification.
This also fixes some minor alignment issues in the header file by
removing spaces and
On Mon 24 Sep 04:07 PDT 2018, Rohit kumar wrote:
> This adds Non PAS ADSP PIL driver for Qualcomm
> Technologies Inc SoCs.
> Added initial support for SDM845 with ADSP bootup and
> shutdown operation handled from Application Processor
> SubSystem(APSS).
>
> Signed-off-by: Rohit kumar
Sorry for
On some Goldmont based systems such as ASRock J3455M the BIOS may not
enable the IPC1 device that provides access to the PMC and PUNIT. In
such scenarios, the IOSS and PSS resources from the platform device can
not be obtained and result in a invalid telemetry_plt_config which is an
internal data
The LTR values follow PCIE LTR encoding format and can be decoded as per
https://pcisig.com/sites/default/files/specification_documents/ECN_LatencyTolnReporting_14Aug08.pdf
This adds support to translate the raw LTR values as read from the PMC
to meaningful values in nanosecond units of time.
On some Goldmont based systems such as ASRock J3455M the BIOS may not
enable the IPC1 device that provides access to the PMC and PUNIT. In
such scenarios, the IOSS and PSS resources from the platform device can
not be obtained and result in a invalid telemetry_plt_config which is an
internal data
The LTR values follow PCIE LTR encoding format and can be decoded as per
https://pcisig.com/sites/default/files/specification_documents/ECN_LatencyTolnReporting_14Aug08.pdf
This adds support to translate the raw LTR values as read from the PMC
to meaningful values in nanosecond units of time.
Cannonlake PCH allows us to ignore LTR from more IPs than Sunrisepoint
PCH so make the LTR ignore platform specific.
Signed-off-by: Rajneesh Bhardwaj
---
drivers/platform/x86/intel_pmc_core.c | 4 +++-
drivers/platform/x86/intel_pmc_core.h | 4 +++-
2 files changed, 6 insertions(+), 2
Cannonlake PCH allows us to ignore LTR from more IPs than Sunrisepoint
PCH so make the LTR ignore platform specific.
Signed-off-by: Rajneesh Bhardwaj
---
drivers/platform/x86/intel_pmc_core.c | 4 +++-
drivers/platform/x86/intel_pmc_core.h | 4 +++-
2 files changed, 6 insertions(+), 2
On Mon 10 Sep 20:54 PDT 2018, Rohit kumar wrote:
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp-pil.txt
> b/Documentation/devicetree/bindings/remoteproc/qcom,adsp-pil.txt
[..]
> += EXAMPLE
> +The following example describes the resources needed to boot control the
> +ADSP,
On Mon 10 Sep 20:54 PDT 2018, Rohit kumar wrote:
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp-pil.txt
> b/Documentation/devicetree/bindings/remoteproc/qcom,adsp-pil.txt
[..]
> += EXAMPLE
> +The following example describes the resources needed to boot control the
> +ADSP,
On Mon 24 Sep 23:50 PDT 2018, Sibi Sankar wrote:
> On 2018-09-20 07:21, Bjorn Andersson wrote:
> > In the case that the interrupts fail to result because of the
> > interrupt-controller not yet being registered the
> > platform_get_irq_byname() call will fail with -EPROBE_DEFER, but passing
> >
On Mon 24 Sep 23:50 PDT 2018, Sibi Sankar wrote:
> On 2018-09-20 07:21, Bjorn Andersson wrote:
> > In the case that the interrupts fail to result because of the
> > interrupt-controller not yet being registered the
> > platform_get_irq_byname() call will fail with -EPROBE_DEFER, but passing
> >
On Thu 27 Sep 23:27 PDT 2018, Sibi Sankar wrote:
> On 2018-09-28 00:33, Bjorn Andersson wrote:
> > Add compatibles for the three PAS based remote processors found in
> > QCS404.
> >
> > Signed-off-by: Bjorn Andersson
> > ---
> >
>
> Reviewed-by: Sibi Sankar
>
Thanks for the review Sibi,
On Thu 27 Sep 23:27 PDT 2018, Sibi Sankar wrote:
> On 2018-09-28 00:33, Bjorn Andersson wrote:
> > Add compatibles for the three PAS based remote processors found in
> > QCS404.
> >
> > Signed-off-by: Bjorn Andersson
> > ---
> >
>
> Reviewed-by: Sibi Sankar
>
Thanks for the review Sibi,
On Mon 01 Oct 07:25 PDT 2018, Sibi Sankar wrote:
> Currently with GLINK_SSR enabled each fatal crash results in servicing
> a crash from wdog as well. This is due to a race that occurs in setting
> the running flag in the shutdown path. Fix this by moving the running
> flag to the end of fatal
On Mon 01 Oct 07:25 PDT 2018, Sibi Sankar wrote:
> Currently with GLINK_SSR enabled each fatal crash results in servicing
> a crash from wdog as well. This is due to a race that occurs in setting
> the running flag in the shutdown path. Fix this by moving the running
> flag to the end of fatal
On Tue 11 Sep 10:46 PDT 2018, Suman Anna wrote:
> The current rpmsg_client_sample uses a fixed number of messages to
> be sent to each instance. This is currently set at 100. Introduce
> an optional module parameter 'count' so that the number of messages
> to be exchanged can be made flexible.
>
On Tue 11 Sep 10:46 PDT 2018, Suman Anna wrote:
> The current rpmsg_client_sample uses a fixed number of messages to
> be sent to each instance. This is currently set at 100. Introduce
> an optional module parameter 'count' so that the number of messages
> to be exchanged can be made flexible.
>
On Fri 14 Sep 17:37 PDT 2018, Suman Anna wrote:
> The commit ddf711872c9d ("remoteproc: Introduce auto-boot flag")
> introduced the auto-boot flag but missed adding the corresponding
> kernel-doc comment. Add the same.
>
> Signed-off-by: Suman Anna
Applied.
Thanks,
Bjorn
> ---
>
On Fri 14 Sep 17:37 PDT 2018, Suman Anna wrote:
> The commit ddf711872c9d ("remoteproc: Introduce auto-boot flag")
> introduced the auto-boot flag but missed adding the corresponding
> kernel-doc comment. Add the same.
>
> Signed-off-by: Suman Anna
Applied.
Thanks,
Bjorn
> ---
>
On Fri 14 Sep 17:37 PDT 2018, Suman Anna wrote:
> The remoteproc framework provides a sysfs file 'firmware'
> for modifying the firmware image name from userspace. Add
> an additional check to ensure NULL firmwares are errored
> out right away, rather than getting a delayed error while
>
On Fri 14 Sep 17:37 PDT 2018, Suman Anna wrote:
> The remoteproc framework provides a sysfs file 'firmware'
> for modifying the firmware image name from userspace. Add
> an additional check to ensure NULL firmwares are errored
> out right away, rather than getting a delayed error while
>
On Fri 14 Sep 17:37 PDT 2018, Suman Anna wrote:
> The remoteproc core performs automatic boot and shutdown of a remote
> processor during rproc_add() and rproc_del() for remote processors
> supporting 'auto-boot'. The remoteproc devices not using 'auto-boot'
> require either a remoteproc client
On Fri 14 Sep 17:37 PDT 2018, Suman Anna wrote:
> The remoteproc core performs automatic boot and shutdown of a remote
> processor during rproc_add() and rproc_del() for remote processors
> supporting 'auto-boot'. The remoteproc devices not using 'auto-boot'
> require either a remoteproc client
On Thu, Oct 04, 2018 at 12:50:22AM +0200, Laurent Vivier wrote:
> This patch allows to have a different binfmt_misc configuration
> for each new user namespace. By default, the binfmt_misc configuration
> is the one of the host, but if the binfmt_misc filesystem is mounted
> in the new namespace a
On Thu, Oct 04, 2018 at 12:50:22AM +0200, Laurent Vivier wrote:
> This patch allows to have a different binfmt_misc configuration
> for each new user namespace. By default, the binfmt_misc configuration
> is the one of the host, but if the binfmt_misc filesystem is mounted
> in the new namespace a
On Tue, Sep 11, 2018 at 01:02:00PM +, mario.limoncie...@dell.com wrote:
> > I tried 9370 and it detects the adapter correctly. IIRC I did the same
> > for 5530 and it worked as well.
>
> Thanks for confirming that. Hopefully the same change can be ported to PD
> controller
> firmware then
On Tue, Sep 11, 2018 at 01:02:00PM +, mario.limoncie...@dell.com wrote:
> > I tried 9370 and it detects the adapter correctly. IIRC I did the same
> > for 5530 and it worked as well.
>
> Thanks for confirming that. Hopefully the same change can be ported to PD
> controller
> firmware then
201 - 256 of 256 matches
Mail list logo
