Re: [PATCH 1/2] acpi, spcr: Make SPCR avialable to other architectures

On 12/07/2017 01:05 PM, Prarit Bhargava wrote: Please give us a chance to test this patch before merging. We've had a lot of problems with our E44 work-around, and we need to make sure that qdf2400_erratum_44_present function is called before the pl011 driver is probed. Timor, do you know of

Re: [PATCH 2/2] acpi, x86: Use SPCR table for earlycon on x86

On Thu, Dec 7, 2017 at 11:29 AM, Prarit Bhargava wrote: > -int __init acpi_parse_spcr(bool earlycon) > +int __init acpi_parse_spcr(bool earlycon, bool enable_console) > { > static char opts[ACPI_SPCR_OPTS_SIZE]; > static char uart[ACPI_SPCR_BUF_SIZE]; > @@

Re: [PATCH 2/2] acpi, x86: Use SPCR table for earlycon on x86

On Thu, Dec 7, 2017 at 11:29 AM, Prarit Bhargava wrote: > -int __init acpi_parse_spcr(bool earlycon) > +int __init acpi_parse_spcr(bool earlycon, bool enable_console) > { > static char opts[ACPI_SPCR_OPTS_SIZE]; > static char uart[ACPI_SPCR_BUF_SIZE]; > @@ -113,7 +113,8 @@ int

Re: [PATCH 1/2] acpi, spcr: Make SPCR avialable to other architectures

On Thu, Dec 7, 2017 at 11:29 AM, Prarit Bhargava wrote: > Other architectures can use SPCR to setup an early console or console but > the current code is ARM64 specific. > > Change the name of parse_spcr() to acpi_parse_spcr(). Add a weak > function acpi_arch_setup_console()

Re: [PATCH 1/2] acpi, spcr: Make SPCR avialable to other architectures

On Thu, Dec 7, 2017 at 11:29 AM, Prarit Bhargava wrote: > Other architectures can use SPCR to setup an early console or console but > the current code is ARM64 specific. > > Change the name of parse_spcr() to acpi_parse_spcr(). Add a weak > function acpi_arch_setup_console() that can be used for

Re: [PATCH 0/3] tty/serial/ucc_uart: Adjustments for two functions

a typo in a comment line All three: Acked-by: Timur Tabi <ti...@tabi.org>

Re: [PATCH 0/3] tty/serial/ucc_uart: Adjustments for two functions

a typo in a comment line All three: Acked-by: Timur Tabi

Re: [PATCH 04/10] ASoC: fsl_ssi: Refine all comments

On 12/4/17 2:46 PM, Nicolin Chen wrote: This patch refines the comments by: 1) Removing all out-of-date comments 2) Removing all not-so-useful comments 3) Unifying the styles of all comments 4) Simplifying over-descriptive comments 5) Adding comments to improve code readablity 6) Moving all

Re: [PATCH 04/10] ASoC: fsl_ssi: Refine all comments

On 12/4/17 2:46 PM, Nicolin Chen wrote: This patch refines the comments by: 1) Removing all out-of-date comments 2) Removing all not-so-useful comments 3) Unifying the styles of all comments 4) Simplifying over-descriptive comments 5) Adding comments to improve code readablity 6) Moving all

Re: [PATCH] video: fsl-diu-fb: Delete an error message for a failed memory allocation in fsl_diu_init()

Markus Elfring<elfr...@users.sourceforge.net> Acked-by: Timur Tabi <ti...@tabi.org>

Re: [PATCH] video: fsl-diu-fb: Delete an error message for a failed memory allocation in fsl_diu_init()

On 11/27/17 3:00 AM, SF Markus Elfring wrote: From: Markus Elfring Date: Mon, 27 Nov 2017 09:56:09 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring Acked-by: Timur Tabi

Re: [PATCH 30/30] PCI: remove pci_get_bus_and_slot() function

On 11/22/17 1:51 AM, Greg KH wrote: Ick, no, why? What is wrong with removing this function as is? Don't mark something as __depreciated if there are no in-kernel users, just delete it and move on. If you have out-of-tree drivers, then yes, they can make a wrapper for this function like this

Re: [PATCH 30/30] PCI: remove pci_get_bus_and_slot() function

On 11/22/17 1:51 AM, Greg KH wrote: Ick, no, why? What is wrong with removing this function as is? Don't mark something as __depreciated if there are no in-kernel users, just delete it and move on. If you have out-of-tree drivers, then yes, they can make a wrapper for this function like this

Re: [PATCH 30/30] PCI: remove pci_get_bus_and_slot() function

On 11/21/17 11:55 PM, Sinan Kaya wrote: For places where domain number information is available, I extracted domain number and added into pci_get_domain_bus_and_slot() call such as xen or bn drivers. My suggestion is that you restrict your first patch set to only these patches. The

Re: [PATCH 30/30] PCI: remove pci_get_bus_and_slot() function

On 11/21/17 11:55 PM, Sinan Kaya wrote: For places where domain number information is available, I extracted domain number and added into pci_get_domain_bus_and_slot() call such as xen or bn drivers. My suggestion is that you restrict your first patch set to only these patches. The

Re: [PATCH 30/30] PCI: remove pci_get_bus_and_slot() function

On 11/21/17 11:31 PM, Sinan Kaya wrote: Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't extract the domain number. Other places, use the actual domain number from the device. Now that all users of pci_get_bus_and_slot() switched to pci_get_domain_bus_and_slot(), it is

Re: [PATCH 30/30] PCI: remove pci_get_bus_and_slot() function

On 11/21/17 11:31 PM, Sinan Kaya wrote: Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't extract the domain number. Other places, use the actual domain number from the device. Now that all users of pci_get_bus_and_slot() switched to pci_get_domain_bus_and_slot(), it is

Re: [PATCH v3 2/2] arm64: Add software workaround for Falkor erratum 1041

On Tue, Nov 14, 2017 at 7:05 PM, Stephen Boyd wrote: > This also applies to Kryo CPUs. I have a patch[1] for the 1003 > Falkor errata that adds the Kryo MIDR check which can also be > used for this errata. > > [1] https://patchwork.kernel.org/patch/10048987/ Please submit

Re: [PATCH v3 2/2] arm64: Add software workaround for Falkor erratum 1041

On Tue, Nov 14, 2017 at 7:05 PM, Stephen Boyd wrote: > This also applies to Kryo CPUs. I have a patch[1] for the 1003 > Falkor errata that adds the Kryo MIDR check which can also be > used for this errata. > > [1] https://patchwork.kernel.org/patch/10048987/ Please submit a follow-up patch for

Re: [PATCH V2 2/3] dmaengine: qcom_hidma: add support for the new revision

On 11/10/2017 08:03 AM, Sinan Kaya wrote: I did post v3 with this approach. However, I could not really find a ACPI function that returns the driver data very similar to of_device_get_match_data(). The only thing that is closer is acpi_match_device(). This is what I do in the EMAC driver:

Re: [PATCH V2 2/3] dmaengine: qcom_hidma: add support for the new revision

On 11/10/2017 08:03 AM, Sinan Kaya wrote: I did post v3 with this approach. However, I could not really find a ACPI function that returns the driver data very similar to of_device_get_match_data(). The only thing that is closer is acpi_match_device(). This is what I do in the EMAC driver:

Re: [PATCH V2 2/3] dmaengine: qcom_hidma: add support for the new revision

On 11/08/2017 11:37 AM, Sinan Kaya wrote: I think we are talking styles here. I don't think my suggestions are stylistic. Your version wastes space. However, if you really insist on your approach, that's fine with me. I'm not the maintainer. -- Qualcomm Datacenter Technologies, Inc. as an

Re: [PATCH V2 2/3] dmaengine: qcom_hidma: add support for the new revision

On 11/08/2017 11:37 AM, Sinan Kaya wrote: I think we are talking styles here. I don't think my suggestions are stylistic. Your version wastes space. However, if you really insist on your approach, that's fine with me. I'm not the maintainer. -- Qualcomm Datacenter Technologies, Inc. as an

Re: [PATCH V2 2/3] dmaengine: qcom_hidma: add support for the new revision

On 11/08/2017 10:58 AM, Sinan Kaya wrote: Besides, C compiler also won't let me put two arrays together like this. struct my_struct { struct some_struct array1[] struct some_struct array2[] } Why not this: const struct of_device_id hidma_msi_of_ids[] = { {.compatible

Re: [PATCH V2 2/3] dmaengine: qcom_hidma: add support for the new revision

On 11/08/2017 10:58 AM, Sinan Kaya wrote: Besides, C compiler also won't let me put two arrays together like this. struct my_struct { struct some_struct array1[] struct some_struct array2[] } Why not this: const struct of_device_id hidma_msi_of_ids[] = { {.compatible

Re: [PATCH V2 2/3] dmaengine: qcom_hidma: add support for the new revision

On 11/08/2017 10:29 AM, Sinan Kaya wrote: +#define HIDMA_MAX_DEV_MATCH 10 + +struct hidma_cap { + const struct of_device_id of[HIDMA_MAX_DEV_MATCH]; + const struct acpi_device_id acpi[HIDMA_MAX_DEV_MATCH]; +}; This seems wrong. You're defining an array of size 10, but it only has

Re: [PATCH V2 2/3] dmaengine: qcom_hidma: add support for the new revision

On 11/08/2017 10:29 AM, Sinan Kaya wrote: +#define HIDMA_MAX_DEV_MATCH 10 + +struct hidma_cap { + const struct of_device_id of[HIDMA_MAX_DEV_MATCH]; + const struct acpi_device_id acpi[HIDMA_MAX_DEV_MATCH]; +}; This seems wrong. You're defining an array of size 10, but it only has

Re: [PATCH 1/4] arm64: defconfig: enable new trigger modes for leds

On 10/23/17 6:11 PM, Amit Kucheria wrote: This is great, thanks. Can I take this as an ACK? Sure, but I'm not a maintainer for the defconfig, so it's just my personal opinion. -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies,

Re: [PATCH 1/4] arm64: defconfig: enable new trigger modes for leds

On 10/23/17 6:11 PM, Amit Kucheria wrote: This is great, thanks. Can I take this as an ACK? Sure, but I'm not a maintainer for the defconfig, so it's just my personal opinion. -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies,

Re: [PATCH 1/4] arm64: defconfig: enable new trigger modes for leds

On 10/22/2017 11:56 PM, Amit Kucheria wrote: "Most development boards and devices have one or more LEDs. It is useful during debugging if they can be wired to show different behaviours such as disk or cpu activity or a load-average dependent heartbeat. Enable panic and disk activity triggers so

Re: [PATCH 1/4] arm64: defconfig: enable new trigger modes for leds

On 10/22/2017 11:56 PM, Amit Kucheria wrote: "Most development boards and devices have one or more LEDs. It is useful during debugging if they can be wired to show different behaviours such as disk or cpu activity or a load-average dependent heartbeat. Enable panic and disk activity triggers so

Re: [PATCH 1/4] arm64: defconfig: enable new trigger modes for leds

On 10/18/17 3:57 PM, Amit Kucheria wrote: Enable panic and disk activity triggers to tie to LED activity Could you provide some explanation as to why we want this enabled for ARM64? I don't have a problem with the change itself, but I think patch descriptions for defconfig changes should

Re: [PATCH 1/4] arm64: defconfig: enable new trigger modes for leds

On 10/18/17 3:57 PM, Amit Kucheria wrote: Enable panic and disk activity triggers to tie to LED activity Could you provide some explanation as to why we want this enabled for ARM64? I don't have a problem with the change itself, but I think patch descriptions for defconfig changes should

Re: [PATCH 3/3] arm64: cpuinfo: display product info in /proc/cpuinfo

On Tue, Sep 26, 2017 at 5:23 PM, Al Stone wrote: > + if (IS_ENABLED(CONFIG_DMI)) { > + seq_puts(m, "product name\t: "); > + > + if (!dmi_product_info) > + get_dmi_product_info(); > +

Re: [PATCH 3/3] arm64: cpuinfo: display product info in /proc/cpuinfo

On Tue, Sep 26, 2017 at 5:23 PM, Al Stone wrote: > + if (IS_ENABLED(CONFIG_DMI)) { > + seq_puts(m, "product name\t: "); > + > + if (!dmi_product_info) > + get_dmi_product_info(); > + if

Re: [PATCH 2/3] arm64: cpuinfo: add human readable CPU names to /proc/cpuinfo

On Tue, Sep 26, 2017 at 5:23 PM, Al Stone wrote: > In the interest of making things easier for humans to use, add a > "CPU name" line to /proc/cpuinfo for each CPU that uses plain old > words instead of hex values. For example, instead of printing only > CPU implementer 0x43 and

Re: [PATCH 2/3] arm64: cpuinfo: add human readable CPU names to /proc/cpuinfo

On Tue, Sep 26, 2017 at 5:23 PM, Al Stone wrote: > In the interest of making things easier for humans to use, add a > "CPU name" line to /proc/cpuinfo for each CPU that uses plain old > words instead of hex values. For example, instead of printing only > CPU implementer 0x43 and CPU part 0x0A1,

Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable

On Wed, Sep 27, 2017 at 5:34 AM, Mark Rutland wrote: > Hi Al, > > On Tue, Sep 26, 2017 at 04:23:21PM -0600, Al Stone wrote: >> As ARMv8 servers get deployed, I keep getting the same set of questions >> from end-users of those systems: what do all the hex numbers mean in >>

Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable

On Wed, Sep 27, 2017 at 5:34 AM, Mark Rutland wrote: > Hi Al, > > On Tue, Sep 26, 2017 at 04:23:21PM -0600, Al Stone wrote: >> As ARMv8 servers get deployed, I keep getting the same set of questions >> from end-users of those systems: what do all the hex numbers mean in >> /proc/cpuinfo and could

Re: [PATCH v3] irqchip/gicv3: Add support for Range Selector (RS) feature

On Thu, Oct 5, 2017 at 6:59 PM, Shanker Donthineni wrote: > +#define MPIDR_TO_SGI_CLUSTER_ID(mpidr) (mpidr & ~0xFUL) This should be "((mpidr) & 0xFUL)", just to be safe.

Re: [PATCH v3] irqchip/gicv3: Add support for Range Selector (RS) feature

On Thu, Oct 5, 2017 at 6:59 PM, Shanker Donthineni wrote: > +#define MPIDR_TO_SGI_CLUSTER_ID(mpidr) (mpidr & ~0xFUL) This should be "((mpidr) & 0xFUL)", just to be safe.

Re: [PATCH] net: qcom/emac: make function emac_isr static

On 10/05/2017 04:10 AM, Colin King wrote: From: Colin Ian King The function emac_isr is local to the source and does not need to be in global scope, so make it static. Cleans up sparse warnings: symbol 'emac_isr' was not declared. Should it be static? Signed-off-by:

Re: [PATCH] net: qcom/emac: make function emac_isr static

On 10/05/2017 04:10 AM, Colin King wrote: From: Colin Ian King The function emac_isr is local to the source and does not need to be in global scope, so make it static. Cleans up sparse warnings: symbol 'emac_isr' was not declared. Should it be static? Signed-off-by: Colin Ian King ACK --

Re: [RFC PATCH 1/2] arm64: mm: Use READ_ONCE/WRITE_ONCE when accessing page tables

On Wed, Sep 27, 2017 at 10:49 AM, Will Deacon wrote: > This patch consistently uses these macros in the arch > code, as well as explicitly namespacing pointers to page table entries > from the entries themselves by using adopting a 'p' suffix for the former > (as is sometimes

Re: [RFC PATCH 1/2] arm64: mm: Use READ_ONCE/WRITE_ONCE when accessing page tables

On Wed, Sep 27, 2017 at 10:49 AM, Will Deacon wrote: > This patch consistently uses these macros in the arch > code, as well as explicitly namespacing pointers to page table entries > from the entries themselves by using adopting a 'p' suffix for the former > (as is sometimes used elsewhere in

Proper way to allocate DMA buffer within a single 4GB block?

I have a device that requires I allocated a few buffers for DMA. The problem is that this device has only one register for the upper 32 bits of all of the buffers. That is, all of buffers must reside within the same 4GB block of memory. In order words, end = start + size - 1;

Proper way to allocate DMA buffer within a single 4GB block?

I have a device that requires I allocated a few buffers for DMA. The problem is that this device has only one register for the upper 32 bits of all of the buffers. That is, all of buffers must reside within the same 4GB block of memory. In order words, end = start + size - 1;

Re: Regression in next with gpiolib

On 08/30/2017 04:41 PM, Tony Lindgren wrote: It seems to be that we're now calling request and free on all gpios before they are properly configured? Yes, that's what my patch does. At the time, it seemed like a good idea -- request the GPIO before touching its hardware. But it appears that

Re: Regression in next with gpiolib

On 08/30/2017 04:41 PM, Tony Lindgren wrote: It seems to be that we're now calling request and free on all gpios before they are properly configured? Yes, that's what my patch does. At the time, it seemed like a good idea -- request the GPIO before touching its hardware. But it appears that

Re: [PATCH 05/11] serial: uuc_uart: constify uart_ops structures

Acked-by: Timur Tabi <ti...@tabi.org>

Re: [PATCH 05/11] serial: uuc_uart: constify uart_ops structures

On 8/13/17 1:21 AM, Julia Lawall wrote: These uart_ops structures are only stored in the ops field of a uart_port structure and this fields is const, so the uart_ops structures can also be const. Done with the help of Coccinelle. Signed-off-by: Julia Lawall Acked-by: Timur Tabi

Re: [PATCH] sound: fsl_dma: remove dma_object path member

On 7/18/17 4:43 PM, Rob Herring wrote: - dev_err(>dev, "could not determine resources for %s\n", - ssi_np->full_name); + dev_err(>dev, "could not determine resources for %pOF\n", + ssi_np); I think you meant to include

Re: [PATCH] sound: fsl_dma: remove dma_object path member

On 7/18/17 4:43 PM, Rob Herring wrote: - dev_err(>dev, "could not determine resources for %s\n", - ssi_np->full_name); + dev_err(>dev, "could not determine resources for %pOF\n", + ssi_np); I think you meant to include

Re: [PATCH 1/3] arm64: hugetlb: Fix huge_pte_offset to return poisoned page table entries

On Thu, May 4, 2017 at 10:55 AM, Punit Agrawal wrote: > Indeed - I was avoiding changing the function to drop contiguous > hugepage support which follows this hunk. > > I've made changes locally based on your suggestion and will post a > revised version after the merge

Re: [PATCH 1/3] arm64: hugetlb: Fix huge_pte_offset to return poisoned page table entries

On Thu, May 4, 2017 at 10:55 AM, Punit Agrawal wrote: > Indeed - I was avoiding changing the function to drop contiguous > hugepage support which follows this hunk. > > I've made changes locally based on your suggestion and will post a > revised version after the merge window. Punit, will you be

Re: [PATCH] MAINTAINERS: add a...@kernel.org as the list for arm64 defconfig changes

On 05/03/2017 12:39 PM, Olof Johansson wrote: > No, I'm not saying that, and there is a better way: Send it through > Andy if in doubt -- it should be his job as your platform maintainer > to help guide you through the system if needed. Will told me that defconfig patches should go to

Re: [PATCH] MAINTAINERS: add a...@kernel.org as the list for arm64 defconfig changes

On 05/03/2017 12:39 PM, Olof Johansson wrote: > No, I'm not saying that, and there is a better way: Send it through > Andy if in doubt -- it should be his job as your platform maintainer > to help guide you through the system if needed. Will told me that defconfig patches should go to

Re: [PATCH] MAINTAINERS: add a...@kernel.org as the list for arm64 defconfig changes

On 05/03/2017 12:26 PM, Olof Johansson wrote: > a...@kernel.org as an email alias will break down if it starts being > cc:d on large number of patches. Ideally we want the platform > maintainers as filters/reviewers in front to keep the volume down. So > far it's been kept to nearly only material

Re: [PATCH] MAINTAINERS: add a...@kernel.org as the list for arm64 defconfig changes

On 05/03/2017 12:26 PM, Olof Johansson wrote: > a...@kernel.org as an email alias will break down if it starts being > cc:d on large number of patches. Ideally we want the platform > maintainers as filters/reviewers in front to keep the volume down. So > far it's been kept to nearly only material

Re: [PATCH] MAINTAINERS: add a...@kernel.org as the list for arm64 defconfig changes

On 05/03/2017 12:01 PM, Catalin Marinas wrote: > On Wed, May 03, 2017 at 11:31:25AM -0500, Timur Tabi wrote: >> > Any changes to arch/arm64/configs/defconfig must be sent to >> > a...@kernel.org, >> > otherwise they will not get picked up. Add

Re: [PATCH] MAINTAINERS: add a...@kernel.org as the list for arm64 defconfig changes

On 05/03/2017 12:01 PM, Catalin Marinas wrote: > On Wed, May 03, 2017 at 11:31:25AM -0500, Timur Tabi wrote: >> > Any changes to arch/arm64/configs/defconfig must be sent to >> > a...@kernel.org, >> > otherwise they will not get picked up. Add

[PATCH] [v2] MAINTAINERS: arm64 defconfig changes should go to a...@kernel.org

Any changes to arch/arm64/configs/defconfig must be sent to a...@kernel.org, otherwise they will not get picked up. Add a MAINTAINERS entry to ensure the get_maintainers includes it. Signed-off-by: Timur Tabi <ti...@codeaurora.org> --- MAINTAINERS | 5 + 1 file changed, 5 inse

[PATCH] [v2] MAINTAINERS: arm64 defconfig changes should go to a...@kernel.org

Any changes to arch/arm64/configs/defconfig must be sent to a...@kernel.org, otherwise they will not get picked up. Add a MAINTAINERS entry to ensure the get_maintainers includes it. Signed-off-by: Timur Tabi --- MAINTAINERS | 5 + 1 file changed, 5 insertions(+) diff --git a/MAINTAINERS

[PATCH] MAINTAINERS: add a...@kernel.org as the list for arm64 defconfig changes

Any changes to arch/arm64/configs/defconfig must be sent to a...@kernel.org, otherwise they will not get picked up. Add a MAINTAINERS entry to ensure the get_maintainers includes it. Signed-off-by: Timur Tabi <ti...@codeaurora.org> --- MAINTAINERS | 7 +++ 1 file changed, 7 inse

[PATCH] MAINTAINERS: add a...@kernel.org as the list for arm64 defconfig changes

Any changes to arch/arm64/configs/defconfig must be sent to a...@kernel.org, otherwise they will not get picked up. Add a MAINTAINERS entry to ensure the get_maintainers includes it. Signed-off-by: Timur Tabi --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git

Re: [Openipmi-developer] [PATCH v2] ipmi: Fix kernel panic at ipmi_ssif_thread()

On Tue, Mar 28, 2017 at 7:18 AM, Corey Minyard wrote: > > Not a problem at all, thanks for sticking with this. > > This will be queued for the next release, and I'll request backports to > stable trees. So I'm a little confused with the status of this patch. Is this the final

Re: [Openipmi-developer] [PATCH v2] ipmi: Fix kernel panic at ipmi_ssif_thread()

On Tue, Mar 28, 2017 at 7:18 AM, Corey Minyard wrote: > > Not a problem at all, thanks for sticking with this. > > This will be queued for the next release, and I'll request backports to > stable trees. So I'm a little confused with the status of this patch. Is this the final commit that will

Re: ktest help

On 04/06/2017 01:50 PM, Steven Rostedt wrote: > Currently yes, but it shouldn't be hard to add a hook to intervene. I > just haven't had something that required it yet. If I understood Perl, I would add the feature myself. -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm

Re: ktest help

On 04/06/2017 01:50 PM, Steven Rostedt wrote: > Currently yes, but it shouldn't be hard to add a hook to intervene. I > just haven't had something that required it yet. If I understood Perl, I would add the feature myself. -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm

Re: ktest help

On 04/06/2017 12:05 PM, Steven Rostedt wrote: >> > Is there a way I can send a "boot" command after ktest connects to the >> > console? >> > > Not currently, but that is something I've been wanting to add for some > time. So are you saying that ktest depends on the target booting from power-on

Re: ktest help

On 04/06/2017 12:05 PM, Steven Rostedt wrote: >> > Is there a way I can send a "boot" command after ktest connects to the >> > console? >> > > Not currently, but that is something I've been wanting to add for some > time. So are you saying that ktest depends on the target booting from power-on

Re: ktest help

On 04/06/2017 11:49 AM, Steven Rostedt wrote: >> > >> > This tftp's the kernel image (Image.q) and then boots. I'm having >> > difficulty figuring out how to implement that in ktest. >> > > Can you make a script do this? If so, then you can simply tell ktest to > call that script. See the

Re: ktest help

On 04/06/2017 11:49 AM, Steven Rostedt wrote: >> > >> > This tftp's the kernel image (Image.q) and then boots. I'm having >> > difficulty figuring out how to implement that in ktest. >> > > Can you make a script do this? If so, then you can simply tell ktest to > call that script. See the

Re: [PATCH v23 00/11] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

gt; (3)Simplify ACPI code for arm_arch_timer > > (4)Add GTDT support for ARM memory-mapped timer. > > This patchset has been tested on the following platforms with ACPI enabled: > (1)ARM Foundation v8 model > > Changelog: > v23: https://lkml.org/lkml/2017

Re: [PATCH v23 00/11] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

gt; (3)Simplify ACPI code for arm_arch_timer > > (4)Add GTDT support for ARM memory-mapped timer. > > This patchset has been tested on the following platforms with ACPI enabled: > (1)ARM Foundation v8 model > > Changelog: > v23: https://lkml.org/lkml/2017/3/31/

Re: [PATCH] ACPI / IPMI: allow ACPI_IPMI with IPMI_SSIF

On 03/23/2017 10:53 AM, Sinan Kaya wrote: > + depends on IPMI_SI||IPMI_SSIF Blank spaces around ||. -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative

Re: [PATCH] ACPI / IPMI: allow ACPI_IPMI with IPMI_SSIF

On 03/23/2017 10:53 AM, Sinan Kaya wrote: > + depends on IPMI_SI||IPMI_SSIF Blank spaces around ||. -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative

Re: [PATCH V2] perf: qcom: Add L3 cache PMU driver

On 02/16/2017 09:03 AM, Agustin Vega-Frias wrote: +config QCOM_L3_PMU +bool "Qualcomm Technologies L3-cache PMU" +depends on ARCH_QCOM && ARM64 && PERF_EVENTS && ACPI + help + Provides support for the L3 cache performance monitor unit (PMU) + in

Re: [PATCH V2] perf: qcom: Add L3 cache PMU driver

On 02/16/2017 09:03 AM, Agustin Vega-Frias wrote: +config QCOM_L3_PMU +bool "Qualcomm Technologies L3-cache PMU" +depends on ARCH_QCOM && ARM64 && PERF_EVENTS && ACPI + help + Provides support for the L3 cache performance monitor unit (PMU) + in

Re: [PATCH v2] arm64: Fix the kernel panic() on QDF2400 platform

On 02/23/2017 03:05 PM, Shanker Donthineni wrote: Why do you want keep 'pre_ttbr0_update_workaround' in subject, nothing wrong with macro definition itself. Problem with the caller, not passing the right arguments. Ok, how about this: arm64: qcom: do not use x1 when calling

Re: [PATCH v2] arm64: Fix the kernel panic() on QDF2400 platform

On 02/23/2017 03:05 PM, Shanker Donthineni wrote: Why do you want keep 'pre_ttbr0_update_workaround' in subject, nothing wrong with macro definition itself. Problem with the caller, not passing the right arguments. Ok, how about this: arm64: qcom: do not use x1 when calling

Re: [PATCH v2] arm64: Fix the kernel panic() on QDF2400 platform

On 02/23/2017 02:02 PM, Shanker Donthineni wrote: The commit 38fd94b0275c 'arm64: Work around Falkor erratum 1003' has been added to fix the hardware bug but causing a system crash. The "causes" value of the register x1 which contains 'struct mm_struct *' should be preserved inside macro

Re: [PATCH v2] arm64: Fix the kernel panic() on QDF2400 platform

On 02/23/2017 02:02 PM, Shanker Donthineni wrote: The commit 38fd94b0275c 'arm64: Work around Falkor erratum 1003' has been added to fix the hardware bug but causing a system crash. The "causes" value of the register x1 which contains 'struct mm_struct *' should be preserved inside macro

Re: [PATCH] arm64: Fix the kernel panic() on QDF2400 platform

On Thu, Feb 23, 2017 at 8:45 AM, Will Deacon wrote: > > Whilst I'm pleased that you've sent a fix (and I'll pick it up), I have > to ask... did anybody actually test the original patch? If so, why wasn't > this found earlier? First, Shanker's going to post a V2 with an

Re: [PATCH] arm64: Fix the kernel panic() on QDF2400 platform

On Thu, Feb 23, 2017 at 8:45 AM, Will Deacon wrote: > > Whilst I'm pleased that you've sent a fix (and I'll pick it up), I have > to ask... did anybody actually test the original patch? If so, why wasn't > this found earlier? First, Shanker's going to post a V2 with an improved patch

Re: [PATCH] video: fbdev: fsl-diu-fb: fix spelling mistake "palette"

On 02/17/2017 02:23 PM, Colin King wrote: From: Colin Ian King <colin.k...@canonical.com> trivial fix to spelling mistakes of "palette" Signed-off-by: Colin Ian King <colin.k...@canonical.com> Acked-by: Timur Tabi <ti...@tabi.org>

Re: [PATCH] video: fbdev: fsl-diu-fb: fix spelling mistake "palette"

On 02/17/2017 02:23 PM, Colin King wrote: From: Colin Ian King trivial fix to spelling mistakes of "palette" Signed-off-by: Colin Ian King Acked-by: Timur Tabi

Re: [PATCH v3] tty: pl011: Work around QDF2400 E44 stuck BUSY bit

On 02/15/2017 12:01 PM, Christopher Covington wrote: Signed-off-by: Christopher Covington <c...@codeaurora.org> Acked-by: Russell King <rmk+ker...@armlinux.org.uk> Acked-by: Timur Tabi <ti...@codeaurora.org> It would great if we could get this into 4.11. As crazy it sound

Re: [PATCH v3] tty: pl011: Work around QDF2400 E44 stuck BUSY bit

On 02/15/2017 12:01 PM, Christopher Covington wrote: Signed-off-by: Christopher Covington Acked-by: Russell King Acked-by: Timur Tabi It would great if we could get this into 4.11. As crazy it sounds, it is the only critical patch in 4.11 that we need for our platform. -- Qualcomm

Re: [PATCH v2] tty: pl011: Work around QDF2400 E44 stuck BUSY bit

Christopher Covington wrote: Nothing needs QDF2400 erratum 44. Software should try to detect the presence of the erratum. So I think qdf2400_e44_detected or qdf2400_e44_present would make sense. But those suffixes don't add substantial value in my opinion. I'd be okay with qdf2400_e44_detected

Re: [PATCH v2] tty: pl011: Work around QDF2400 E44 stuck BUSY bit

Christopher Covington wrote: Nothing needs QDF2400 erratum 44. Software should try to detect the presence of the erratum. So I think qdf2400_e44_detected or qdf2400_e44_present would make sense. But those suffixes don't add substantial value in my opinion. I'd be okay with qdf2400_e44_detected

Re: [PATCH v2] tty: pl011: Work around QDF2400 E44 stuck BUSY bit

Christopher Covington wrote: The Qualcomm Datacenter Technologies QDF2400 family of SoCs contains a custom (non-PrimeCell) implementation of the SBSA UART. Occasionally the BUSY bit in the Flag Register gets stuck as 1, erratum 44 for both 2432v1 and 2400v1 SoCs. Checking that the Transmit FIFO

Re: [PATCH v2] tty: pl011: Work around QDF2400 E44 stuck BUSY bit

Christopher Covington wrote: The Qualcomm Datacenter Technologies QDF2400 family of SoCs contains a custom (non-PrimeCell) implementation of the SBSA UART. Occasionally the BUSY bit in the Flag Register gets stuck as 1, erratum 44 for both 2432v1 and 2400v1 SoCs. Checking that the Transmit FIFO

Re: [patch net-next] net: qcom/emac: fix a sizeof() typo

-by: Dan Carpenter <dan.carpen...@oracle.com> Acked-by: Timur Tabi <ti...@codeaurora.org> -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation.

Re: [patch net-next] net: qcom/emac: fix a sizeof() typo

Dan Carpenter wrote: We had intended to say "sizeof(u32)" but the "u" is missing. Fortunately, sizeof(32) is also 4, so the original code still works. Fixes: c4e7beea2192 ("net: qcom/emac: add ethtool support for reading hardware registers") Signed-off-by: Dan Car

Re: [patch net-next] net: qcom/emac: fix a sizeof() typo

walter harms wrote: The question is: why is a simple calculation const*const separated into a function ? This is a callback function. That's just how it's defined. It's rare, but there are drivers that use the parameter, like this one:

Re: [patch net-next] net: qcom/emac: fix a sizeof() typo

walter harms wrote: The question is: why is a simple calculation const*const separated into a function ? This is a callback function. That's just how it's defined. It's rare, but there are drivers that use the parameter, like this one:

Re: [patch net-next] net: qcom/emac: fix a sizeof() typo

walter harms wrote: We have a function where the argument is ignored and the rest is const ? emac_ethtool_get_regs_len seems the only user. So it would be fairly easy to move that into that function. @maintainer: Is there a deeper logic behind this ? I don't understand the question. The

Re: [patch net-next] net: qcom/emac: fix a sizeof() typo

walter harms wrote: We have a function where the argument is ignored and the rest is const ? emac_ethtool_get_regs_len seems the only user. So it would be fairly easy to move that into that function. @maintainer: Is there a deeper logic behind this ? I don't understand the question. The

Re: [PATCH 1/2] tty: pl011: Work around QDF2400 E44 stuck BUSY bit

On 02/08/2017 04:22 PM, Christopher Covington wrote: >> -while (pl011_read(uap, REG_FR) & uap->vendor->fr_busy) >> +while ((pl011_read(uap, REG_FR) ^ uap->vendor->inv_fr) >> +& uap->vendor->fr_busy) > > I really think the XOR logic needs to be documented wherever

<    1   2   3   4   5   6   7   8   9   10   >