* Re: [PATCH v3 1/4] dt-bindings: soc: qcom: Add device tree binding for GENI SE
From: Rob Herring @ 2018-03-05 23:58 UTC (permalink / raw)
To: Karthikeyan Ramasubramanian
Cc: corbet, andy.gross, david.brown, mark.rutland, wsa, gregkh,
linux-doc, linux-arm-msm, devicetree, linux-i2c, linux-serial,
jslaby, evgreen, acourbot, Sagar Dharia, Girish Mahadevan
In-Reply-To: <1519781889-16117-2-git-send-email-kramasub@codeaurora.org>
On Tue, Feb 27, 2018 at 06:38:06PM -0700, Karthikeyan Ramasubramanian wrote:
> Add device tree binding support for the QCOM GENI SE driver.
>
> Signed-off-by: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
> Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
> Signed-off-by: Girish Mahadevan <girishm@codeaurora.org>
> ---
> .../devicetree/bindings/soc/qcom/qcom,geni-se.txt | 89 ++++++++++++++++++++++
> 1 file changed, 89 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
>
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
> new file mode 100644
> index 0000000..fe6a0c0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
> @@ -0,0 +1,89 @@
> +Qualcomm Technologies, Inc. GENI Serial Engine QUP Wrapper Controller
> +
> +Generic Interface (GENI) based Qualcomm Universal Peripheral (QUP) wrapper
> +is a programmable module for supporting a wide range of serial interfaces
> +like UART, SPI, I2C, I3C, etc. A single QUP module can provide upto 8 Serial
> +Interfaces, using its internal Serial Engines. The GENI Serial Engine QUP
> +Wrapper controller is modeled as a node with zero or more child nodes each
> +representing a serial engine.
> +
> +Required properties:
> +- compatible: Must be "qcom,geni-se-qup".
> +- reg: Must contain QUP register address and length.
> +- clock-names: Must contain "m-ahb" and "s-ahb".
> +- clocks: AHB clocks needed by the device.
> +
> +Required properties if child node exists:
> +- #address-cells: Must be <1> for Serial Engine Address
> +- #size-cells: Must be <1> for Serial Engine Address Size
> +- ranges: Must be present
> +
> +Properties for children:
> +
> +A GENI based QUP wrapper controller node can contain 0 or more child nodes
> +representing serial devices. These serial devices can be a QCOM UART, I2C
> +controller, spi controller, or some combination of aforementioned devices.
s/spi/SPI/
Where's the SPI binding?
> +Please refer below the child node definitions for the supported serial
> +interface protocols.
> +
> +Qualcomm Technologies Inc. GENI Serial Engine based I2C Controller
> +
> +Required properties:
> +- compatible: Must be "qcom,geni-i2c".
> +- reg: Must contain QUP register address and length.
> +- interrupts: Must contain I2C interrupt.
> +- clock-names: Must contain "se".
> +- clocks: Serial engine core clock needed by the device.
> +- #address-cells: Must be <1> for i2c device address.
> +- #size-cells: Must be <0> as i2c addresses have no size component.
> +
> +Optional property:
> +- clock-frequency: Desired I2C bus clock frequency in Hz.
> + When missing default to 400000Hz.
> +
> +Child nodes should conform to i2c bus binding as described in i2c.txt.
> +
> +Qualcomm Technologies Inc. GENI Serial Engine based UART Controller
> +
> +Required properties:
> +- compatible: Must be "qcom,geni-debug-uart".
> +- reg: Must contain UART register location and length.
> +- interrupts: Must contain UART core interrupts.
> +- clock-names: Must contain "se".
> +- clocks: Serial engine core clock needed by the device.
> +
> +Example:
> + geniqup@8c0000 {
> + compatible = "qcom,geni-se-qup";
> + reg = <0x8c0000 0x6000>;
> + clock-names = "m-ahb", "s-ahb";
> + clocks = <&clock_gcc GCC_QUPV3_WRAP_0_M_AHB_CLK>,
> + <&clock_gcc GCC_QUPV3_WRAP_0_S_AHB_CLK>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + i2c0: i2c@a94000 {
> + compatible = "qcom,geni-i2c";
> + reg = <0xa94000 0x4000>;
> + interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
> + clock-names = "se";
> + clocks = <&clock_gcc GCC_QUPV3_WRAP0_S5_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_1_i2c_5_active>;
> + pinctrl-1 = <&qup_1_i2c_5_sleep>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + uart0: serial@a88000 {
> + compatible = "qcom,geni-debug-uart";
> + reg = <0xa88000 0x7000>;
> + interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
> + clock-names = "se";
> + clocks = <&clock_gcc GCC_QUPV3_WRAP0_S0_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_1_uart_3_active>;
> + pinctrl-1 = <&qup_1_uart_3_sleep>;
> + };
> + }
> --
> Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v12 10/11] sparc64: Add support for ADI (Application Data Integrity)
From: Khalid Aziz @ 2018-03-05 22:55 UTC (permalink / raw)
To: Dave Hansen, davem, akpm
Cc: corbet, steven.sistare, pasha.tatashin, mike.kravetz, rob.gardner,
mingo, nitin.m.gupta, anthony.yznaga, kirill.shutemov,
tom.hromatka, allen.pais, tklauser, shannon.nelson,
vijay.ac.kumar, mhocko, jack, punit.agrawal, hughd, thomas.tai,
ross.zwisler, dave.jiang, willy, minchan, imbrenda, aarcange,
kstewart, pombredanne, tglx, gregkh, nagarathnam.muthusamy, linux,
jane.chu, dan.j.williams, jglisse, ktkhai, linux-doc,
linux-kernel, linux-mm, sparclinux, Khalid Aziz
In-Reply-To: <8b0edd2e-3e9b-1148-6309-38b61307a523@linux.intel.com>
On 03/05/2018 02:31 PM, Dave Hansen wrote:
> On 03/05/2018 01:14 PM, Khalid Aziz wrote:
>> Are you suggesting that vma returned by find_vma() could be split or
>> merged underneath me if I do not hold mmap_sem and thus make the flag
>> check invalid? If so, that is a good point.
>
> This part does make me think that this code hasn't been tested very
> thoroughly. Could you describe the testing that you have done? For MPX
> and protection keys, I added something to tools/testing/selftests/x86,
> for instance.
This code was tested by a QA team and I ran a number of tests myself. I
wrote tests to exercise all of the API, induce exceptions for
invalid/illegal accesses and swapping was tested by allocating memory
2-4 times of the system RAM available across 4-8 threads and
reading/writing to this memory with ADI enabled. QA team wrote unit
tests to test each API with valid and invalid combinations of arguments
to the API. Stress tests that allocate and free ADI tagged memory were
also run. A version of database server was created that uses ADI tagged
memory for in-memory copy of database to test database workload. 100's
of hours of tests were run across these tests over the last 1+ year
these patches have been under review for. Cover letter includes
description of most of these tests. This code has held up through all of
these tests. It is entirely feasible some race conditions have not been
uncovered yet, just like any other piece of software. Pulling this code
into mainline kernel and having lot more people exercise this code will
help shake out any remaining issues.
Thanks,
Khalid
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v12 10/11] sparc64: Add support for ADI (Application Data Integrity)
From: Dave Hansen @ 2018-03-05 21:50 UTC (permalink / raw)
To: Khalid Aziz, davem, akpm
Cc: corbet, bob.picco, steven.sistare, pasha.tatashin, mike.kravetz,
rob.gardner, mingo, nitin.m.gupta, anthony.yznaga,
kirill.shutemov, tom.hromatka, allen.pais, tklauser,
shannon.nelson, vijay.ac.kumar, mhocko, jack, punit.agrawal,
hughd, thomas.tai, ross.zwisler, dave.jiang, willy, minchan,
imbrenda, aarcange, kstewart, pombredanne, tglx, gregkh,
nagarathnam.muthusamy, linux, jane.chu, dan.j.williams, jglisse,
ktkhai, linux-doc, linux-kernel, linux-mm, sparclinux,
Khalid Aziz
In-Reply-To: <b241c894-7751-bd01-2658-4cb6b89f7454@oracle.com>
On 03/05/2018 01:37 PM, Khalid Aziz wrote:
>> How big can this storage get, btw? Superficially it seems like it might
>> be able to be gigantic for a large, sparse VMA.
>>
> Tags are stored only for the pages being swapped out, not for the pages
> in entire vma. Each tag storage page can hold tags for 128 pages (each
> page has 128 4-bit tags, hence 64 bytes are needed to store tags for an
> entire page allowing each page to store tags for 128 pages). Sparse VMA
> does not cause any problems since holes do not have corresponding pages
> that will be swapped out. Tag storage pages are freed once all the pages
> they store tags for have been swapped back in, except for a small number
> of pages (maximum of 8) marked for emergency tag storage.
With a linear scan holding a process-wide spinlock? If you have a fast
swap device, does this become the bottleneck when swapping ADI-tagged
memory?
FWIW, this tag storage is complex and subtle enough code that it
deserves to be in its own well-documented patch, not buried in a
thousand-line patch.
> +tag_storage_desc_t *find_tag_store(struct mm_struct *mm,
> + struct vm_area_struct *vma,
> + unsigned long addr)
> +{
> + tag_storage_desc_t *tag_desc = NULL;
> + unsigned long i, max_desc, flags;
> +
> + /* Check if this vma already has tag storage descriptor
> + * allocated for it.
> + */
> + max_desc = PAGE_SIZE/sizeof(tag_storage_desc_t);
> + if (mm->context.tag_store) {
> + tag_desc = mm->context.tag_store;
> + spin_lock_irqsave(&mm->context.tag_lock, flags);
> + for (i = 0; i < max_desc; i++) {
> + if ((addr >= tag_desc->start) &&
> + ((addr + PAGE_SIZE - 1) <= tag_desc->end))
> + break;
> + tag_desc++;
> + }
> + spin_unlock_irqrestore(&mm->context.tag_lock, flags);
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v12 10/11] sparc64: Add support for ADI (Application Data Integrity)
From: Khalid Aziz @ 2018-03-05 21:37 UTC (permalink / raw)
To: Dave Hansen, davem, akpm
Cc: corbet, bob.picco, steven.sistare, pasha.tatashin, mike.kravetz,
rob.gardner, mingo, nitin.m.gupta, anthony.yznaga,
kirill.shutemov, tom.hromatka, allen.pais, tklauser,
shannon.nelson, vijay.ac.kumar, mhocko, jack, punit.agrawal,
hughd, thomas.tai, ross.zwisler, dave.jiang, willy, minchan,
imbrenda, aarcange, kstewart, pombredanne, tglx, gregkh,
nagarathnam.muthusamy, linux, jane.chu, dan.j.williams, jglisse,
ktkhai, linux-doc, linux-kernel, linux-mm, sparclinux,
Khalid Aziz
In-Reply-To: <08ef65c1-16b3-44e7-5cc3-7b6bde7bd5a4@linux.intel.com>
On 03/05/2018 02:26 PM, Dave Hansen wrote:
> On 02/21/2018 09:15 AM, Khalid Aziz wrote:
>> +tag_storage_desc_t *alloc_tag_store(struct mm_struct *mm,
>> + struct vm_area_struct *vma,
>> + unsigned long addr)
> ...
>> + tags = kzalloc(size, GFP_NOWAIT|__GFP_NOWARN);
>> + if (tags == NULL) {
>> + tag_desc->tag_users = 0;
>> + tag_desc = NULL;
>> + goto out;
>> + }
>> + tag_desc->start = addr;
>> + tag_desc->tags = tags;
>> + tag_desc->end = end_addr;
>> +
>> +out:
>> + spin_unlock_irqrestore(&mm->context.tag_lock, flags);
>> + return tag_desc;
>> +}
>
> OK, sorry, I missed this. I do see that you now have per-ADI-block tag
> storage and it is not per-page.
>
> How big can this storage get, btw? Superficially it seems like it might
> be able to be gigantic for a large, sparse VMA.
>
Tags are stored only for the pages being swapped out, not for the pages
in entire vma. Each tag storage page can hold tags for 128 pages (each
page has 128 4-bit tags, hence 64 bytes are needed to store tags for an
entire page allowing each page to store tags for 128 pages). Sparse VMA
does not cause any problems since holes do not have corresponding pages
that will be swapped out. Tag storage pages are freed once all the pages
they store tags for have been swapped back in, except for a small number
of pages (maximum of 8) marked for emergency tag storage.
--
Khalid
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v12 10/11] sparc64: Add support for ADI (Application Data Integrity)
From: Dave Hansen @ 2018-03-05 21:31 UTC (permalink / raw)
To: Khalid Aziz, davem, akpm
Cc: corbet, bob.picco, steven.sistare, pasha.tatashin, mike.kravetz,
rob.gardner, mingo, nitin.m.gupta, anthony.yznaga,
kirill.shutemov, tom.hromatka, allen.pais, tklauser,
shannon.nelson, vijay.ac.kumar, mhocko, jack, punit.agrawal,
hughd, thomas.tai, ross.zwisler, dave.jiang, willy, minchan,
imbrenda, aarcange, kstewart, pombredanne, tglx, gregkh,
nagarathnam.muthusamy, linux, jane.chu, dan.j.williams, jglisse,
ktkhai, linux-doc, linux-kernel, linux-mm, sparclinux,
Khalid Aziz
In-Reply-To: <84931753-9a84-8624-adb8-95bd05d87d56@oracle.com>
On 03/05/2018 01:14 PM, Khalid Aziz wrote:
> Are you suggesting that vma returned by find_vma() could be split or
> merged underneath me if I do not hold mmap_sem and thus make the flag
> check invalid? If so, that is a good point.
This part does make me think that this code hasn't been tested very
thoroughly. Could you describe the testing that you have done? For MPX
and protection keys, I added something to tools/testing/selftests/x86,
for instance.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v12 10/11] sparc64: Add support for ADI (Application Data Integrity)
From: Dave Hansen @ 2018-03-05 21:26 UTC (permalink / raw)
To: Khalid Aziz, davem, akpm
Cc: corbet, bob.picco, steven.sistare, pasha.tatashin, mike.kravetz,
rob.gardner, mingo, nitin.m.gupta, anthony.yznaga,
kirill.shutemov, tom.hromatka, allen.pais, tklauser,
shannon.nelson, vijay.ac.kumar, mhocko, jack, punit.agrawal,
hughd, thomas.tai, ross.zwisler, dave.jiang, willy, minchan,
imbrenda, aarcange, kstewart, pombredanne, tglx, gregkh,
nagarathnam.muthusamy, linux, jane.chu, dan.j.williams, jglisse,
ktkhai, linux-doc, linux-kernel, linux-mm, sparclinux,
Khalid Aziz
In-Reply-To: <84931753-9a84-8624-adb8-95bd05d87d56@oracle.com>
On 03/05/2018 01:14 PM, Khalid Aziz wrote:
> On 03/05/2018 12:22 PM, Dave Hansen wrote:
>> On 02/21/2018 09:15 AM, Khalid Aziz wrote:
>>> +#define arch_validate_prot(prot, addr) sparc_validate_prot(prot, addr)
>>> +static inline int sparc_validate_prot(unsigned long prot, unsigned
>>> long addr)
>>> +{
>>> + if (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM |
>>> PROT_ADI))
>>> + return 0;
>>> + if (prot & PROT_ADI) {
>>> + if (!adi_capable())
>>> + return 0;
>>> +
>>> + if (addr) {
>>> + struct vm_area_struct *vma;
>>> +
>>> + vma = find_vma(current->mm, addr);
>>> + if (vma) {
>>> + /* ADI can not be enabled on PFN
>>> + * mapped pages
>>> + */
>>> + if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP))
>>> + return 0;
>>
>> You don't hold mmap_sem here. How can this work?
>>
> Are you suggesting that vma returned by find_vma() could be split or
> merged underneath me if I do not hold mmap_sem and thus make the flag
> check invalid? If so, that is a good point.
Um, yes. You can't walk the vma tree without holding mmap_sem.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v12 10/11] sparc64: Add support for ADI (Application Data Integrity)
From: Dave Hansen @ 2018-03-05 21:26 UTC (permalink / raw)
To: Khalid Aziz, davem, akpm
Cc: corbet, bob.picco, steven.sistare, pasha.tatashin, mike.kravetz,
rob.gardner, mingo, nitin.m.gupta, anthony.yznaga,
kirill.shutemov, tom.hromatka, allen.pais, tklauser,
shannon.nelson, vijay.ac.kumar, mhocko, jack, punit.agrawal,
hughd, thomas.tai, ross.zwisler, dave.jiang, willy, minchan,
imbrenda, aarcange, kstewart, pombredanne, tglx, gregkh,
nagarathnam.muthusamy, linux, jane.chu, dan.j.williams, jglisse,
ktkhai, linux-doc, linux-kernel, linux-mm, sparclinux,
Khalid Aziz
In-Reply-To: <d8602e35e65c8bf6df1a85166bf181536a6f3664.1519227112.git.khalid.aziz@oracle.com>
On 02/21/2018 09:15 AM, Khalid Aziz wrote:
> +tag_storage_desc_t *alloc_tag_store(struct mm_struct *mm,
> + struct vm_area_struct *vma,
> + unsigned long addr)
...
> + tags = kzalloc(size, GFP_NOWAIT|__GFP_NOWARN);
> + if (tags == NULL) {
> + tag_desc->tag_users = 0;
> + tag_desc = NULL;
> + goto out;
> + }
> + tag_desc->start = addr;
> + tag_desc->tags = tags;
> + tag_desc->end = end_addr;
> +
> +out:
> + spin_unlock_irqrestore(&mm->context.tag_lock, flags);
> + return tag_desc;
> +}
OK, sorry, I missed this. I do see that you now have per-ADI-block tag
storage and it is not per-page.
How big can this storage get, btw? Superficially it seems like it might
be able to be gigantic for a large, sparse VMA.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] docs: add Co-Developed-by docs
From: Tobin C. Harding @ 2018-03-05 21:24 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Tobin C. Harding, Andrew Morton, Greg Kroah-Hartman, Joe Perches,
Randy Dunlap, Dominik Brodowski, Thomas Gleixner, Jonathan Corbet,
linux-kernel, linux-doc
In-Reply-To: <20180305121135.GA15079@bombadil.infradead.org>
On Mon, Mar 05, 2018 at 04:11:35AM -0800, Matthew Wilcox wrote:
> On Mon, Mar 05, 2018 at 02:58:21PM +1100, Tobin C. Harding wrote:
> > -12) When to use Acked-by: and Cc:
> > ----------------------------------
> > +12) When to use Acked-by: and Cc:, and Co-Developed-by:
> > +-------------------------------------------------------
>
> +12) When to use Acked-by:, Cc:, and Co-Developed-by:
thanks, sloppy work by me :)
Tobin
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v12 10/11] sparc64: Add support for ADI (Application Data Integrity)
From: Khalid Aziz @ 2018-03-05 21:14 UTC (permalink / raw)
To: Dave Hansen, davem, akpm
Cc: corbet, bob.picco, steven.sistare, pasha.tatashin, mike.kravetz,
rob.gardner, mingo, nitin.m.gupta, anthony.yznaga,
kirill.shutemov, tom.hromatka, allen.pais, tklauser,
shannon.nelson, vijay.ac.kumar, mhocko, jack, punit.agrawal,
hughd, thomas.tai, ross.zwisler, dave.jiang, willy, minchan,
imbrenda, aarcange, kstewart, pombredanne, tglx, gregkh,
nagarathnam.muthusamy, linux, jane.chu, dan.j.williams, jglisse,
ktkhai, linux-doc, linux-kernel, linux-mm, sparclinux,
Khalid Aziz
In-Reply-To: <a59ece97-ba1f-dfb1-bfc8-b44ffd8edbca@linux.intel.com>
On 03/05/2018 12:22 PM, Dave Hansen wrote:
> On 02/21/2018 09:15 AM, Khalid Aziz wrote:
>> +#define arch_validate_prot(prot, addr) sparc_validate_prot(prot, addr)
>> +static inline int sparc_validate_prot(unsigned long prot, unsigned long addr)
>> +{
>> + if (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM | PROT_ADI))
>> + return 0;
>> + if (prot & PROT_ADI) {
>> + if (!adi_capable())
>> + return 0;
>> +
>> + if (addr) {
>> + struct vm_area_struct *vma;
>> +
>> + vma = find_vma(current->mm, addr);
>> + if (vma) {
>> + /* ADI can not be enabled on PFN
>> + * mapped pages
>> + */
>> + if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP))
>> + return 0;
>
> You don't hold mmap_sem here. How can this work?
>
Are you suggesting that vma returned by find_vma() could be split or
merged underneath me if I do not hold mmap_sem and thus make the flag
check invalid? If so, that is a good point.
Thanks,
Khalid
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] checkpatch: add check for tag Co-Developed-by
From: Joe Perches @ 2018-03-05 19:29 UTC (permalink / raw)
To: Tobin C. Harding, Andrew Morton, Greg Kroah-Hartman
Cc: Randy Dunlap, Dominik Brodowski, Thomas Gleixner, Jonathan Corbet,
linux-kernel, linux-doc
In-Reply-To: <1520222301-11874-2-git-send-email-me@tobin.cc>
On Mon, 2018-03-05 at 14:58 +1100, Tobin C. Harding wrote:
> From: Joe Perches <joe@perches.com>
I still think this "Co-Developed-by" stuff is unnecessary.
> Recently signature tag Co-Developed-by was added to the
> kernel (Documentation/process/5.Posting.rst). checkpatch.pl doesn't know
> about it yet. All prior tags used all lowercase characters except for first
> character. Checks for this format had to be re-worked to allow for the
> new tag.
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Tobin C. Harding <me@tobin.cc>
> ---
> scripts/checkpatch.pl | 58 +++++++++++++++++++++++++++++++--------------------
> 1 file changed, 35 insertions(+), 23 deletions(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 3d4040322ae1..fbe2ae2d035f 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -461,16 +461,18 @@ our $logFunctions = qr{(?x:
> seq_vprintf|seq_printf|seq_puts
> )};
>
> -our $signature_tags = qr{(?xi:
> - Signed-off-by:|
> - Acked-by:|
> - Tested-by:|
> - Reviewed-by:|
> - Reported-by:|
> - Suggested-by:|
> - To:|
> - Cc:
> -)};
> +our @valid_signatures = (
> + "Signed-off-by:",
> + "Acked-by:",
> + "Tested-by:",
> + "Reviewed-by:",
> + "Reported-by:",
> + "Suggested-by:",
> + "Co-Developed-by:",
> + "To:",
> + "Cc:"
> +);
> +my $signature_tags = "(?x:" . join('|', @valid_signatures) . ")";
>
> our @typeListMisordered = (
> qr{char\s+(?:un)?signed},
> @@ -2193,6 +2195,17 @@ sub pos_last_openparen {
> return length(expand_tabs(substr($line, 0, $last_openparen))) + 1;
> }
>
> +sub get_preferred_sign_off {
> + my ($sign_off) = @_;
> +
> + foreach my $sig (@valid_signatures) {
> + if (lc($sign_off) eq lc($sig)) {
> + return $sig;
> + }
> + }
> + return "";
> +}
> +
> sub process {
> my $filename = shift;
>
> @@ -2499,35 +2512,34 @@ sub process {
> my $sign_off = $2;
> my $space_after = $3;
> my $email = $4;
> - my $ucfirst_sign_off = ucfirst(lc($sign_off));
> + my $preferred_sign_off = ucfirst(lc($sign_off));
>
> - if ($sign_off !~ /$signature_tags/) {
> + if ($sign_off !~ /$signature_tags/i) {
> WARN("BAD_SIGN_OFF",
> "Non-standard signature: $sign_off\n" . $herecurr);
> - }
> - if (defined $space_before && $space_before ne "") {
> + } elsif ($sign_off !~ /$signature_tags/) {
> + $preferred_sign_off = get_preferred_sign_off($sign_off);
> if (WARN("BAD_SIGN_OFF",
> - "Do not use whitespace before $ucfirst_sign_off\n" . $herecurr) &&
> + "'$preferred_sign_off' is the preferred signature form\n" . $herecurr) &&
> $fix) {
> - $fixed[$fixlinenr] =
> - "$ucfirst_sign_off $email";
> + $fixed[$fixlinenr] = "$preferred_sign_off $email";
> }
> }
> - if ($sign_off =~ /-by:$/i && $sign_off ne $ucfirst_sign_off) {
> + if (defined $space_before && $space_before ne "") {
> if (WARN("BAD_SIGN_OFF",
> - "'$ucfirst_sign_off' is the preferred signature form\n" . $herecurr) &&
> + "Do not use whitespace before $preferred_sign_off\n" . $herecurr) &&
> $fix) {
> $fixed[$fixlinenr] =
> - "$ucfirst_sign_off $email";
> + "$preferred_sign_off $email";
> }
> -
> }
> +
> if (!defined $space_after || $space_after ne " ") {
> if (WARN("BAD_SIGN_OFF",
> - "Use a single space after $ucfirst_sign_off\n" . $herecurr) &&
> + "Use a single space after $preferred_sign_off\n" . $herecurr) &&
> $fix) {
> $fixed[$fixlinenr] =
> - "$ucfirst_sign_off $email";
> + "$preferred_sign_off $email";
> }
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v12 10/11] sparc64: Add support for ADI (Application Data Integrity)
From: Dave Hansen @ 2018-03-05 19:22 UTC (permalink / raw)
To: Khalid Aziz, davem, akpm
Cc: corbet, bob.picco, steven.sistare, pasha.tatashin, mike.kravetz,
rob.gardner, mingo, nitin.m.gupta, anthony.yznaga,
kirill.shutemov, tom.hromatka, allen.pais, tklauser,
shannon.nelson, vijay.ac.kumar, mhocko, jack, punit.agrawal,
hughd, thomas.tai, ross.zwisler, dave.jiang, willy, minchan,
imbrenda, aarcange, kstewart, pombredanne, tglx, gregkh,
nagarathnam.muthusamy, linux, jane.chu, dan.j.williams, jglisse,
ktkhai, linux-doc, linux-kernel, linux-mm, sparclinux,
Khalid Aziz
In-Reply-To: <d8602e35e65c8bf6df1a85166bf181536a6f3664.1519227112.git.khalid.aziz@oracle.com>
On 02/21/2018 09:15 AM, Khalid Aziz wrote:
> +#define arch_validate_prot(prot, addr) sparc_validate_prot(prot, addr)
> +static inline int sparc_validate_prot(unsigned long prot, unsigned long addr)
> +{
> + if (prot & ~(PROT_READ | PROT_WRITE | PROT_EXEC | PROT_SEM | PROT_ADI))
> + return 0;
> + if (prot & PROT_ADI) {
> + if (!adi_capable())
> + return 0;
> +
> + if (addr) {
> + struct vm_area_struct *vma;
> +
> + vma = find_vma(current->mm, addr);
> + if (vma) {
> + /* ADI can not be enabled on PFN
> + * mapped pages
> + */
> + if (vma->vm_flags & (VM_PFNMAP | VM_MIXEDMAP))
> + return 0;
You don't hold mmap_sem here. How can this work?
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] kbuild: remove command line interface LDFLAGS_MODULE from makefiles.txt
From: Masahiro Yamada @ 2018-03-05 15:01 UTC (permalink / raw)
To: Linux Kbuild mailing list
Cc: Sam Ravnborg, Randy Dunlap, Josh Poimboeuf, Robin Jarry,
Masahiro Yamada, open list:DOCUMENTATION,
Linux Kernel Mailing List, Jonathan Corbet, Michal Marek
In-Reply-To: <1519812864-852-1-git-send-email-yamada.masahiro@socionext.com>
2018-02-28 19:14 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> Documentation/kbuild/makefiles.txt lists variables used in Makefile
> whereas Documentation/kbuild/kbuild.txt describes user assignable
> parameters given via environments or the command line.
>
> LDFLAGS_MODULE is a command line interface, so it should be dropped
> from makefiles.txt.
>
> Some lines below in this file, it is clearly explained that
> KBUILD_LDFLAGS_MODULE is the right one for the internal use:
>
> KBUILD_LDFLAGS_MODULE Options for $(LD) when linking modules
>
> $(KBUILD_LDFLAGS_MODULE) is used to add arch-specific options
> used when linking modules. This is often a linker script.
> From commandline LDFLAGS_MODULE shall be used (see kbuild.txt).
>
> Then, kbuild.txt explains LDFLAGS_MODULE, like follows:
>
> LDFLAGS_MODULE
> --------------------------------------------------
> Additional options used for $(LD) when linking modules.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> Documentation/kbuild/makefiles.txt | 6 ------
> 1 file changed, 6 deletions(-)
Both applied to linux-kbuild/kbuild.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] docs: add Co-Developed-by docs
From: Matthew Wilcox @ 2018-03-05 12:11 UTC (permalink / raw)
To: Tobin C. Harding
Cc: Andrew Morton, Greg Kroah-Hartman, Joe Perches, Randy Dunlap,
Dominik Brodowski, Thomas Gleixner, Jonathan Corbet, linux-kernel,
linux-doc
In-Reply-To: <1520222301-11874-3-git-send-email-me@tobin.cc>
On Mon, Mar 05, 2018 at 02:58:21PM +1100, Tobin C. Harding wrote:
> -12) When to use Acked-by: and Cc:
> ----------------------------------
> +12) When to use Acked-by: and Cc:, and Co-Developed-by:
> +-------------------------------------------------------
+12) When to use Acked-by:, Cc:, and Co-Developed-by:
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] crypto: doc - clarify hash callbacks state machine
From: Horia Geantă @ 2018-03-05 10:39 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Jonathan Corbet
Cc: linux-crypto, linux-doc, linux-kernel
Even though it doesn't make too much sense, it is perfectly legal to:
- call .init() and then (as many times) .update()
- subseqently _not_ call any of .final(), .finup() or .export()
Update documentation since this is an important issue to consider
from resource management perspective.
Link: https://lkml.kernel.org/r/20180222114741.GA27631@gondor.apana.org.au
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
---
Documentation/crypto/devel-algos.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/crypto/devel-algos.rst b/Documentation/crypto/devel-algos.rst
index 66f50d32dcec..0f4617019227 100644
--- a/Documentation/crypto/devel-algos.rst
+++ b/Documentation/crypto/devel-algos.rst
@@ -236,6 +236,14 @@ when used from another part of the kernel.
|
'---------------> HASH2
+Note that it is perfectly legal to:
+- call .init() and then (as many times) .update()
+- subseqently _not_ call any of .final(), .finup() or .export()
+
+In other words mind the resource allocation and clean-up,
+since this basically means no resources can remain allocated
+after a call to .init() or .update().
+
Specifics Of Asynchronous HASH Transformation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
2.16.2
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 1/2] checkpatch: add check for tag Co-Developed-by
From: Tobin C. Harding @ 2018-03-05 3:58 UTC (permalink / raw)
To: Andrew Morton, Greg Kroah-Hartman
Cc: Tobin C. Harding, Joe Perches, Randy Dunlap, Dominik Brodowski,
Thomas Gleixner, Jonathan Corbet, linux-kernel, linux-doc
In-Reply-To: <1520222301-11874-1-git-send-email-me@tobin.cc>
From: Joe Perches <joe@perches.com>
Recently signature tag Co-Developed-by was added to the
kernel (Documentation/process/5.Posting.rst). checkpatch.pl doesn't know
about it yet. All prior tags used all lowercase characters except for first
character. Checks for this format had to be re-worked to allow for the
new tag.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
scripts/checkpatch.pl | 58 +++++++++++++++++++++++++++++++--------------------
1 file changed, 35 insertions(+), 23 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 3d4040322ae1..fbe2ae2d035f 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -461,16 +461,18 @@ our $logFunctions = qr{(?x:
seq_vprintf|seq_printf|seq_puts
)};
-our $signature_tags = qr{(?xi:
- Signed-off-by:|
- Acked-by:|
- Tested-by:|
- Reviewed-by:|
- Reported-by:|
- Suggested-by:|
- To:|
- Cc:
-)};
+our @valid_signatures = (
+ "Signed-off-by:",
+ "Acked-by:",
+ "Tested-by:",
+ "Reviewed-by:",
+ "Reported-by:",
+ "Suggested-by:",
+ "Co-Developed-by:",
+ "To:",
+ "Cc:"
+);
+my $signature_tags = "(?x:" . join('|', @valid_signatures) . ")";
our @typeListMisordered = (
qr{char\s+(?:un)?signed},
@@ -2193,6 +2195,17 @@ sub pos_last_openparen {
return length(expand_tabs(substr($line, 0, $last_openparen))) + 1;
}
+sub get_preferred_sign_off {
+ my ($sign_off) = @_;
+
+ foreach my $sig (@valid_signatures) {
+ if (lc($sign_off) eq lc($sig)) {
+ return $sig;
+ }
+ }
+ return "";
+}
+
sub process {
my $filename = shift;
@@ -2499,35 +2512,34 @@ sub process {
my $sign_off = $2;
my $space_after = $3;
my $email = $4;
- my $ucfirst_sign_off = ucfirst(lc($sign_off));
+ my $preferred_sign_off = ucfirst(lc($sign_off));
- if ($sign_off !~ /$signature_tags/) {
+ if ($sign_off !~ /$signature_tags/i) {
WARN("BAD_SIGN_OFF",
"Non-standard signature: $sign_off\n" . $herecurr);
- }
- if (defined $space_before && $space_before ne "") {
+ } elsif ($sign_off !~ /$signature_tags/) {
+ $preferred_sign_off = get_preferred_sign_off($sign_off);
if (WARN("BAD_SIGN_OFF",
- "Do not use whitespace before $ucfirst_sign_off\n" . $herecurr) &&
+ "'$preferred_sign_off' is the preferred signature form\n" . $herecurr) &&
$fix) {
- $fixed[$fixlinenr] =
- "$ucfirst_sign_off $email";
+ $fixed[$fixlinenr] = "$preferred_sign_off $email";
}
}
- if ($sign_off =~ /-by:$/i && $sign_off ne $ucfirst_sign_off) {
+ if (defined $space_before && $space_before ne "") {
if (WARN("BAD_SIGN_OFF",
- "'$ucfirst_sign_off' is the preferred signature form\n" . $herecurr) &&
+ "Do not use whitespace before $preferred_sign_off\n" . $herecurr) &&
$fix) {
$fixed[$fixlinenr] =
- "$ucfirst_sign_off $email";
+ "$preferred_sign_off $email";
}
-
}
+
if (!defined $space_after || $space_after ne " ") {
if (WARN("BAD_SIGN_OFF",
- "Use a single space after $ucfirst_sign_off\n" . $herecurr) &&
+ "Use a single space after $preferred_sign_off\n" . $herecurr) &&
$fix) {
$fixed[$fixlinenr] =
- "$ucfirst_sign_off $email";
+ "$preferred_sign_off $email";
}
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/2] docs: add Co-Developed-by docs
From: Tobin C. Harding @ 2018-03-05 3:58 UTC (permalink / raw)
To: Andrew Morton, Greg Kroah-Hartman
Cc: Tobin C. Harding, Joe Perches, Randy Dunlap, Dominik Brodowski,
Thomas Gleixner, Jonathan Corbet, linux-kernel, linux-doc
In-Reply-To: <1520222301-11874-1-git-send-email-me@tobin.cc>
When Co-Developed-by tag was added, docs were only added to
Documention/process/5.Posting.rst and were not added to
Documention/process/submitting-patches.rst
Add documentation to Documention/process/submitting-patches.rst
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
The text in this patch is copied basically verbatim from
Documentation/process/submitting-patches.rst
Documentation/process/submitting-patches.rst | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index 1ef19d3a3eee..698360641ecd 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -510,8 +510,8 @@ tracking your trees, and to people trying to troubleshoot bugs in your
tree.
-12) When to use Acked-by: and Cc:
----------------------------------
+12) When to use Acked-by: and Cc:, and Co-Developed-by:
+-------------------------------------------------------
The Signed-off-by: tag indicates that the signer was involved in the
development of the patch, or that he/she was in the patch's delivery path.
@@ -543,6 +543,11 @@ person it names - but it should indicate that this person was copied on the
patch. This tag documents that potentially interested parties
have been included in the discussion.
+A Co-Developed-by: states that the patch was also created by another developer
+along with the original author. This is useful at times when multiple people
+work on a single patch. Note, this person also needs to have a Signed-off-by:
+line in the patch as well.
+
13) Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes:
--------------------------------------------------------------------------
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] documentation: add my name to kernel driver statement
From: Aaro Koskinen @ 2018-03-04 20:18 UTC (permalink / raw)
To: Jonathan Corbet, Greg Kroah-Hartman, linux-doc, linux-kernel
Cc: Aaro Koskinen
Add my name to kernel driver statement.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
---
Documentation/process/kernel-driver-statement.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/process/kernel-driver-statement.rst b/Documentation/process/kernel-driver-statement.rst
index 60d9d86..e78452c2 100644
--- a/Documentation/process/kernel-driver-statement.rst
+++ b/Documentation/process/kernel-driver-statement.rst
@@ -103,6 +103,7 @@ today, have in the past, or will in the future.
- Auke Kok
- Peter Korsgaard
- Jiri Kosina
+ - Aaro Koskinen
- Mariusz Kozlowski
- Greg Kroah-Hartman
- Michael Krufky
--
2.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2] earlycon: Allow specifying a uartclk in options
From: Aaron Durbin @ 2018-03-03 19:27 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Daniel Kurtz, Aaron Durbin, Brian Norris, Jonathan Corbet,
Greg Kroah-Hartman, Jiri Slaby, Ingo Molnar, Thomas Gleixner,
Christoffer Dall, Paul McKenney, Marc Zyngier,
Frederic Weisbecker, David Woodhouse, Tom Saeger, Mimi Zohar,
Levin, Alexander (Sasha Levin), Linux Documentation List,
Linux Kernel Mailing List, open list:SERIAL DRIVERS
In-Reply-To: <CAHp75Veu=0w2sWpgn0mNFa0G3Gwp2SpHv55vPgLiWjrCAzaiGw@mail.gmail.com>
On Sat, Mar 3, 2018 at 8:56 AM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Fri, Mar 2, 2018 at 8:35 PM, Daniel Kurtz <djkurtz@chromium.org> wrote:
>> On Thu, Mar 1, 2018 at 1:02 PM Andy Shevchenko <andy.shevchenko@gmail.com>
>> wrote:
>>> On Thu, Mar 1, 2018 at 9:22 PM, Daniel Kurtz <djkurtz@chromium.org> wrote:
>>> > On Thu, Mar 1, 2018 at 11:47 AM Andy Shevchenko <
>> andy.shevchenko@gmail.com>
>>> > wrote:
>
>> the UART bitclock
>> is
>>> > always "BASE_BAUD * 16" (1843200). While this may be true for many
>> UARTs,
>>> > it isn't true for AMD's CZ/ST which has a 8250_dw and uses a fixed 48
>> MHz
>>> > clock. The main 8250_dw driver uses devm_clk_get to get the "baudclk"
>> and
>>> > uses its rate to initialize uartclk. For AMD CZ/ST, this "baudclk" is
>>> > actually a set up in acpi_apd.c when there is an acpi match for
>> "AMD0020",
>>> > with a rate read from the .fixed_clk_rate param of the corresponding
>>> > apd_device_desc.
>
>> As
>>> > noted above, the information is actually already in the kernel and used
>> by
>>> > 8250_dw - I would happy be to hear recommendations for wiring this data
>>> > into earlycon that doesn't require adding another command line arg.
>
> Brief look at the code shows that ->setup() call back is executed
> after setting initial (which is hardcoded) clock.
>
> What you need is to either create another type of earlycon for your
> device with accompanied ->setup() callback, or patch 8250_early.c.
If I'm understand you correctly, you are suggesting new driver code
that sets the clock accordingly within the port structure such that
the baud rate calculation actually works based on the correct input
clock? Why wouldn't we just extened the generic earlycon driver like
the original patch to support providing the clock? Anything in the
earlycon path that tries to set a baud rate will fail once the
hard-coded input clock assumption doesn't hold true. Why not provide
the ability to correct the assumption for platforms that need it?
>
>>> > I see that support was also added recently to earlycon to let it use
>> ACPI
>>> > SPCR to choose a console and configure its parameters... but AFAICT,
>> this
>>> > path also doesn't allow specifying the uart clock.
>
> It does specify baudrate. It means it's _firmware_ responsibility to
> configure UART device properly.
baudrate != input clock. The issue is that once the driver code
attempts to set a baud rate w/o having the correct input clock then
things break.
>
>>> Fix your firmware then. It should set console to 115200 like (almost)
>>> everyone does.
>>> Okay, configures a necessary IPs to feed UART with expected 1.8432M clock.
>>
>> The console is 115200 when it is enabled. However, the firmware does not
>> always enable it by default.
>
> Another firmware bug.
It's more complex than that. You seem to take the stance that the
firmware should bring every IP block out of reset and/or clock and
power gating. That then subsequently requires the kernel to enable all
those soc drivers that put those devices in power or clock gated state
to reach the maximum power savings. While that's certainly possible,
it just leads to bloated kernels. That is orthogonal to the problem of
setting baud rate w/o knowing the proper input clock frequency,
though.
If we do make the assumption the firmware sets up the uart, but the
kernel earlycon has a different baud rate specified than what firmware
set up then the baud rate calculation would be wrong as well since the
input clock isn't known. As such one cannot use earlycon when: 1.
firmware doesn't set up uart 2. firmware baud rate != earlycon
specified baud rate. Providing the proper input clock for the device
in question solves both 1 and 2.
>
>> The problem is that the UART IP block has a fixed 48 MHz input clock, but
>> earlycon assumes this clock is always 1843200.
>
>> I looked a bit further, and I think this patch (or something similar) is
>> still required to teach generic earlycon how to handle an explicit
>> port->uartclk (ie, one that is not 1843200).
>> The extended string can then be explicitly set on the kernel command line
>> for this kind of hardware.
>
> No.
>
>> In addition, we can add another patch with a new quirk detector in
>> drivers/acpi/spcr.c:acpi_parse_spcr() to handle this hardware.
>> acpi_parse_spcr() can then use the extended option string to pass in the
>> appropriate UART clock to setup_eralycon().
>
> Definitely no. It's not defined in SPCR spec.
>
>> This would again allow a user to just use the simple command line parameter
>> "earlycon" if the device's firmware has a correctly confiured ACPI SPCR
>> table.
>
> NAK to the patch, see above alternatives.
>
> --
> With Best Regards,
> Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] earlycon: Allow specifying a uartclk in options
From: Aaron Durbin @ 2018-03-03 19:12 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Aaron Durbin, Daniel Kurtz, Brian Norris, Jonathan Corbet,
Greg Kroah-Hartman, Jiri Slaby, Ingo Molnar, Thomas Gleixner,
Christoffer Dall, Paul E. McKenney, Marc Zyngier,
Frederic Weisbecker, David Woodhouse, Tom Saeger, Mimi Zohar,
Levin, Alexander (Sasha Levin), Linux Documentation List,
Linux Kernel Mailing List, open list:SERIAL DRIVERS
In-Reply-To: <CAHp75Vcnuc48xb167hu5nz3iv9uSp2jRw+M-w=yBihex6RTXYQ@mail.gmail.com>
On Sat, Mar 3, 2018 at 8:38 AM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Thu, Mar 1, 2018 at 11:24 PM, Aaron Durbin <adurbin@chromium.org> wrote:
>> On Thu, Mar 1, 2018 at 1:02 PM, Andy Shevchenko
>> <andy.shevchenko@gmail.com> wrote:
>>> On Thu, Mar 1, 2018 at 9:22 PM, Daniel Kurtz <djkurtz@chromium.org> wrote:
>>>> On Thu, Mar 1, 2018 at 11:47 AM Andy Shevchenko <andy.shevchenko@gmail.com>
>>>> wrote:
>>>
>>>> "earlycon simply does not utilize the information".
>>>>
>>>> earlycon parses iotype, mapbase and baud (from options). However, it is
>>>> hard-coded to assume that the clock used to generate the UART bitclock is
>>>> always "BASE_BAUD * 16" (1843200). While this may be true for many UARTs,
>>>> it isn't true for AMD's CZ/ST which has a 8250_dw and uses a fixed 48 MHz
>>>> clock. The main 8250_dw driver uses devm_clk_get to get the "baudclk" and
>>>> uses its rate to initialize uartclk. For AMD CZ/ST, this "baudclk" is
>>>> actually a set up in acpi_apd.c when there is an acpi match for "AMD0020",
>>>> with a rate read from the .fixed_clk_rate param of the corresponding
>>>> apd_device_desc.
>>>>
>>>> This patch attempts to add a way to inform earlycon about this clock. As
>>>> noted above, the information is actually already in the kernel and used by
>>>> 8250_dw - I would happy be to hear recommendations for wiring this data
>>>> into earlycon that doesn't require adding another command line arg.
>>>
>>> And it should not require that for sure!
>>
>> But it does require that. There's an input clock to the uart ip block.
>> That is a design constraint by the hardware and is required to make
>> baud calculation work.
>
> I mean it should not be user's headache to provide this information to
> the system.
>
>> It's not a firmware problem.
>
> If it's ACPI, then it's definitely firmware issue, since SPCR provides
> a baudrate.
>
earlycon is another implemetnation of driver binding/settings that is
done before the rest of the kernel driver stack. SPCR provides
baudrate, but that's only one piece to the puzzle. You need to know
the UART input clock which you admit is hard coded in the current
driver. It's not possible to configure the divisor in the UART without
knowing the external clock. That's a real dependency that can't be
worked around. The moment the code attempts to configure the baud it
has to know the input clock -- otherwise the calculation is inherently
wrong. Or are you suggesting to lie about the baud such that the the
math works out even though the values are not real?
>> Its the driver's problem in that it
>> assumes an input clock to the uart block that does not reflect
>> reality.
>
> So, driver can't get this info from device tree or what?
There is no device tree on x86. And ACPI driver binding is not fully
initialized when earlycon is being processed. Yes, this can be solved
by getting up the entire ACPI stack, but then that's not really
'early' in the kernel's initialization sequence.
>
>>> Okay, configures a necessary IPs to feed UART with expected 1.8432M clock.
>>
>> That's only possible if there is a clock divider on the front end of
>> the uart block. For this hardware that's not the case. I actually did
>> this very thing on intel chromebook devices, but it was only possible
>> because there was a hardware divider that could be tuned to reach the
>> assumed clock that the code currently assumes.
>
> OK.
>
> --
> With Best Regards,
> Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] earlycon: Allow specifying a uartclk in options
From: Andy Shevchenko @ 2018-03-03 15:56 UTC (permalink / raw)
To: Daniel Kurtz
Cc: Aaron Durbin, Brian Norris, Jonathan Corbet, Greg Kroah-Hartman,
Jiri Slaby, Ingo Molnar, Thomas Gleixner, Christoffer Dall,
Paul McKenney, Marc Zyngier, Frederic Weisbecker, David Woodhouse,
Tom Saeger, Mimi Zohar, Levin, Alexander (Sasha Levin),
Linux Documentation List, Linux Kernel Mailing List,
open list:SERIAL DRIVERS
In-Reply-To: <CAGS+omB76qbiuYjs7Rakff2JB7263_m5TRYDgvKM+wdBpaedNA@mail.gmail.com>
On Fri, Mar 2, 2018 at 8:35 PM, Daniel Kurtz <djkurtz@chromium.org> wrote:
> On Thu, Mar 1, 2018 at 1:02 PM Andy Shevchenko <andy.shevchenko@gmail.com>
> wrote:
>> On Thu, Mar 1, 2018 at 9:22 PM, Daniel Kurtz <djkurtz@chromium.org> wrote:
>> > On Thu, Mar 1, 2018 at 11:47 AM Andy Shevchenko <
> andy.shevchenko@gmail.com>
>> > wrote:
> the UART bitclock
> is
>> > always "BASE_BAUD * 16" (1843200). While this may be true for many
> UARTs,
>> > it isn't true for AMD's CZ/ST which has a 8250_dw and uses a fixed 48
> MHz
>> > clock. The main 8250_dw driver uses devm_clk_get to get the "baudclk"
> and
>> > uses its rate to initialize uartclk. For AMD CZ/ST, this "baudclk" is
>> > actually a set up in acpi_apd.c when there is an acpi match for
> "AMD0020",
>> > with a rate read from the .fixed_clk_rate param of the corresponding
>> > apd_device_desc.
> As
>> > noted above, the information is actually already in the kernel and used
> by
>> > 8250_dw - I would happy be to hear recommendations for wiring this data
>> > into earlycon that doesn't require adding another command line arg.
Brief look at the code shows that ->setup() call back is executed
after setting initial (which is hardcoded) clock.
What you need is to either create another type of earlycon for your
device with accompanied ->setup() callback, or patch 8250_early.c.
>> > I see that support was also added recently to earlycon to let it use
> ACPI
>> > SPCR to choose a console and configure its parameters... but AFAICT,
> this
>> > path also doesn't allow specifying the uart clock.
It does specify baudrate. It means it's _firmware_ responsibility to
configure UART device properly.
>> Fix your firmware then. It should set console to 115200 like (almost)
>> everyone does.
>> Okay, configures a necessary IPs to feed UART with expected 1.8432M clock.
>
> The console is 115200 when it is enabled. However, the firmware does not
> always enable it by default.
Another firmware bug.
> The problem is that the UART IP block has a fixed 48 MHz input clock, but
> earlycon assumes this clock is always 1843200.
> I looked a bit further, and I think this patch (or something similar) is
> still required to teach generic earlycon how to handle an explicit
> port->uartclk (ie, one that is not 1843200).
> The extended string can then be explicitly set on the kernel command line
> for this kind of hardware.
No.
> In addition, we can add another patch with a new quirk detector in
> drivers/acpi/spcr.c:acpi_parse_spcr() to handle this hardware.
> acpi_parse_spcr() can then use the extended option string to pass in the
> appropriate UART clock to setup_eralycon().
Definitely no. It's not defined in SPCR spec.
> This would again allow a user to just use the simple command line parameter
> "earlycon" if the device's firmware has a correctly confiured ACPI SPCR
> table.
NAK to the patch, see above alternatives.
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] earlycon: Allow specifying a uartclk in options
From: Andy Shevchenko @ 2018-03-03 15:38 UTC (permalink / raw)
To: Aaron Durbin
Cc: Daniel Kurtz, Brian Norris, Jonathan Corbet, Greg Kroah-Hartman,
Jiri Slaby, Ingo Molnar, Thomas Gleixner, Christoffer Dall,
Paul E. McKenney, Marc Zyngier, Frederic Weisbecker,
David Woodhouse, Tom Saeger, Mimi Zohar,
Levin, Alexander (Sasha Levin), Linux Documentation List,
Linux Kernel Mailing List, open list:SERIAL DRIVERS
In-Reply-To: <CAE2855vbQyMwu8pmH-Sq1kA+=h5TJPWddTWPQoVdEqOn6sAyBw@mail.gmail.com>
On Thu, Mar 1, 2018 at 11:24 PM, Aaron Durbin <adurbin@chromium.org> wrote:
> On Thu, Mar 1, 2018 at 1:02 PM, Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
>> On Thu, Mar 1, 2018 at 9:22 PM, Daniel Kurtz <djkurtz@chromium.org> wrote:
>>> On Thu, Mar 1, 2018 at 11:47 AM Andy Shevchenko <andy.shevchenko@gmail.com>
>>> wrote:
>>
>>> "earlycon simply does not utilize the information".
>>>
>>> earlycon parses iotype, mapbase and baud (from options). However, it is
>>> hard-coded to assume that the clock used to generate the UART bitclock is
>>> always "BASE_BAUD * 16" (1843200). While this may be true for many UARTs,
>>> it isn't true for AMD's CZ/ST which has a 8250_dw and uses a fixed 48 MHz
>>> clock. The main 8250_dw driver uses devm_clk_get to get the "baudclk" and
>>> uses its rate to initialize uartclk. For AMD CZ/ST, this "baudclk" is
>>> actually a set up in acpi_apd.c when there is an acpi match for "AMD0020",
>>> with a rate read from the .fixed_clk_rate param of the corresponding
>>> apd_device_desc.
>>>
>>> This patch attempts to add a way to inform earlycon about this clock. As
>>> noted above, the information is actually already in the kernel and used by
>>> 8250_dw - I would happy be to hear recommendations for wiring this data
>>> into earlycon that doesn't require adding another command line arg.
>>
>> And it should not require that for sure!
>
> But it does require that. There's an input clock to the uart ip block.
> That is a design constraint by the hardware and is required to make
> baud calculation work.
I mean it should not be user's headache to provide this information to
the system.
> It's not a firmware problem.
If it's ACPI, then it's definitely firmware issue, since SPCR provides
a baudrate.
> Its the driver's problem in that it
> assumes an input clock to the uart block that does not reflect
> reality.
So, driver can't get this info from device tree or what?
>> Okay, configures a necessary IPs to feed UART with expected 1.8432M clock.
>
> That's only possible if there is a clock divider on the front end of
> the uart block. For this hardware that's not the case. I actually did
> this very thing on intel chromebook devices, but it was only possible
> because there was a hardware divider that could be tuned to reach the
> assumed clock that the code currently assumes.
OK.
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v10 4/5] ACPI / APEI: Add SEI notification type support for ARMv8
From: Dongjiu Geng @ 2018-03-03 16:09 UTC (permalink / raw)
To: rkrcmar, corbet, christoffer.dall, marc.zyngier, james.morse,
linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc,
linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel
Cc: gengdongjiu, huangshaoyu
In-Reply-To: <1520093380-42577-1-git-send-email-gengdongjiu@huawei.com>
ACPI 6.x adds support for NOTIFY_SEI as a GHES notification
mechanism, so add new GHES notification handling functions.
Expose API ghes_notify_sei() to arch code, arch code will call
this API when it gets this NOTIFY_SEI.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
---
drivers/acpi/apei/Kconfig | 15 ++++++++++++++
drivers/acpi/apei/ghes.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++
include/acpi/ghes.h | 1 +
3 files changed, 69 insertions(+)
diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig
index 52ae543..ff4afc3 100644
--- a/drivers/acpi/apei/Kconfig
+++ b/drivers/acpi/apei/Kconfig
@@ -55,6 +55,21 @@ config ACPI_APEI_SEA
option allows the OS to look for such hardware error record, and
take appropriate action.
+config ACPI_APEI_SEI
+ bool "APEI SError(System Error) Interrupt logging/recovering support"
+ depends on ARM64 && ACPI_APEI_GHES
+ default y
+ help
+ This option should be enabled if the system supports
+ firmware first handling of SEI (SError interrupt).
+
+ SEI happens with asynchronous external abort for errors on device
+ memory reads on ARMv8 systems. If a system supports firmware first
+ handling of SEI, the platform analyzes and handles hardware error
+ notifications from SEI, and it may then form a hardware error record for
+ the OS to parse and handle. This option allows the OS to look for
+ such hardware error record, and take appropriate action.
+
config ACPI_APEI_MEMORY_FAILURE
bool "APEI memory error recovering support"
depends on ACPI_APEI && MEMORY_FAILURE
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 1efefe9..33f77ae 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -827,6 +827,46 @@ static inline void ghes_sea_add(struct ghes *ghes) { }
static inline void ghes_sea_remove(struct ghes *ghes) { }
#endif /* CONFIG_ACPI_APEI_SEA */
+#ifdef CONFIG_ACPI_APEI_SEI
+static LIST_HEAD(ghes_sei);
+
+/*
+ * Return 0 only if one of the SEI error sources successfully reported an error
+ * record sent from the firmware.
+ */
+int ghes_notify_sei(void)
+{
+ struct ghes *ghes;
+ int ret = -ENOENT;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(ghes, &ghes_sei, list) {
+ if (!ghes_proc(ghes))
+ ret = 0;
+ }
+ rcu_read_unlock();
+ return ret;
+}
+
+static void ghes_sei_add(struct ghes *ghes)
+{
+ mutex_lock(&ghes_list_mutex);
+ list_add_rcu(&ghes->list, &ghes_sei);
+ mutex_unlock(&ghes_list_mutex);
+}
+
+static void ghes_sei_remove(struct ghes *ghes)
+{
+ mutex_lock(&ghes_list_mutex);
+ list_del_rcu(&ghes->list);
+ mutex_unlock(&ghes_list_mutex);
+ synchronize_rcu();
+}
+#else /* CONFIG_ACPI_APEI_SEI */
+static inline void ghes_sei_add(struct ghes *ghes) { }
+static inline void ghes_sei_remove(struct ghes *ghes) { }
+#endif /* CONFIG_ACPI_APEI_SEI */
+
#ifdef CONFIG_HAVE_ACPI_APEI_NMI
/*
* printk is not safe in NMI context. So in NMI handler, we allocate
@@ -1055,6 +1095,13 @@ static int ghes_probe(struct platform_device *ghes_dev)
goto err;
}
break;
+ case ACPI_HEST_NOTIFY_SEI:
+ if (!IS_ENABLED(CONFIG_ACPI_APEI_SEI)) {
+ pr_warn(GHES_PFX "Generic hardware error source: %d notified via SEI is not supported!\n",
+ generic->header.source_id);
+ goto err;
+ }
+ break;
case ACPI_HEST_NOTIFY_NMI:
if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) {
pr_warn(GHES_PFX "Generic hardware error source: %d notified via NMI interrupt is not supported!\n",
@@ -1126,6 +1173,9 @@ static int ghes_probe(struct platform_device *ghes_dev)
case ACPI_HEST_NOTIFY_SEA:
ghes_sea_add(ghes);
break;
+ case ACPI_HEST_NOTIFY_SEI:
+ ghes_sei_add(ghes);
+ break;
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_add(ghes);
break;
@@ -1179,6 +1229,9 @@ static int ghes_remove(struct platform_device *ghes_dev)
case ACPI_HEST_NOTIFY_SEA:
ghes_sea_remove(ghes);
break;
+ case ACPI_HEST_NOTIFY_SEI:
+ ghes_sei_remove(ghes);
+ break;
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_remove(ghes);
break;
diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h
index 8feb0c8..9ba59e2 100644
--- a/include/acpi/ghes.h
+++ b/include/acpi/ghes.h
@@ -120,5 +120,6 @@ static inline void *acpi_hest_get_next(struct acpi_hest_generic_data *gdata)
section = acpi_hest_get_next(section))
int ghes_notify_sea(void);
+int ghes_notify_sei(void);
#endif /* GHES_H */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v10 5/5] arm64: handle NOTIFY_SEI notification by the APEI driver
From: Dongjiu Geng @ 2018-03-03 16:09 UTC (permalink / raw)
To: rkrcmar, corbet, christoffer.dall, marc.zyngier, james.morse,
linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc,
linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel
Cc: gengdongjiu, huangshaoyu
In-Reply-To: <1520093380-42577-1-git-send-email-gengdongjiu@huawei.com>
Add a helper to handle the NOTIFY_SEI notification, when kernel
gets the NOTIFY_SEI notification, call this helper and let APEI
driver to handle this notification.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
---
arch/arm64/include/asm/system_misc.h | 1 +
arch/arm64/kernel/traps.c | 4 ++++
arch/arm64/mm/fault.c | 10 ++++++++++
3 files changed, 15 insertions(+)
diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
index 07aa8e3..9ee13ad 100644
--- a/arch/arm64/include/asm/system_misc.h
+++ b/arch/arm64/include/asm/system_misc.h
@@ -57,6 +57,7 @@ void hook_debug_fault_code(int nr, int (*fn)(unsigned long, unsigned int,
})
int handle_guest_sea(phys_addr_t addr, unsigned int esr);
+int handle_guest_sei(void);
#endif /* __ASSEMBLY__ */
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index e88096a..6cb280f 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -681,6 +681,10 @@ bool arm64_is_fatal_ras_serror(struct pt_regs *regs, unsigned int esr)
{
u32 aet = arm64_ras_serror_get_severity(esr);
+ /* The APEI driver may handle this RAS error. */
+ if (!handle_guest_sei())
+ return false;
+
switch (aet) {
case ESR_ELx_AET_CE: /* corrected error */
case ESR_ELx_AET_UEO: /* restartable, not yet consumed */
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index f76bb2c..8f29bd8 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -683,6 +683,16 @@ int handle_guest_sea(phys_addr_t addr, unsigned int esr)
return ret;
}
+int handle_guest_sei(void)
+{
+ int ret = -ENOENT;
+
+ if (IS_ENABLED(CONFIG_ACPI_APEI_SEI))
+ ret = ghes_notify_sei();
+
+ return ret;
+}
+
asmlinkage void __exception do_mem_abort(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v10 2/5] arm64: KVM: export the capability to set guest SError syndrome
From: Dongjiu Geng @ 2018-03-03 16:09 UTC (permalink / raw)
To: rkrcmar, corbet, christoffer.dall, marc.zyngier, james.morse,
linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc,
linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel
Cc: gengdongjiu, huangshaoyu
In-Reply-To: <1520093380-42577-1-git-send-email-gengdongjiu@huawei.com>
Before user space injects a SError, it needs to know whether it can
specify the guest Exception Syndrome, so KVM should tell user space
whether it has such capability.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
---
Documentation/virtual/kvm/api.txt | 11 +++++++++++
arch/arm64/kvm/reset.c | 3 +++
include/uapi/linux/kvm.h | 1 +
3 files changed, 15 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index fc3ae95..8a3d708 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -4415,3 +4415,14 @@ Parameters: none
This capability indicates if the flic device will be able to get/set the
AIS states for migration via the KVM_DEV_FLIC_AISM_ALL attribute and allows
to discover this without having to create a flic device.
+
+8.14 KVM_CAP_ARM_SET_SERROR_ESR
+
+Architectures: arm, arm64
+
+This capability indicates that userspace can specify syndrome value reported to
+guest OS when guest takes a virtual SError interrupt exception.
+If KVM has this capability, userspace can only specify the ISS field for the ESR
+syndrome, can not specify the EC field which is not under control by KVM.
+If this virtual SError is taken to EL1 using AArch64, this value will be reported
+into ISS filed of ESR_EL1.
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 3256b92..38c8a64 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_ARM_PMU_V3:
r = kvm_arm_support_pmu_v3();
break;
+ case KVM_CAP_ARM_INJECT_SERROR_ESR:
+ r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN);
+ break;
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
r = 1;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 8fb90a0..3587b33 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -934,6 +934,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_S390_AIS_MIGRATION 150
#define KVM_CAP_PPC_GET_CPU_CHAR 151
#define KVM_CAP_S390_BPB 152
+#define KVM_CAP_ARM_INJECT_SERROR_ESR 153
#ifdef KVM_CAP_IRQ_ROUTING
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v10 1/5] arm64: KVM: Prepare set virtual SEI syndrome value
From: Dongjiu Geng @ 2018-03-03 16:09 UTC (permalink / raw)
To: rkrcmar, corbet, christoffer.dall, marc.zyngier, james.morse,
linux, catalin.marinas, rjw, bp, lenb, kvm, linux-doc,
linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, devel
Cc: gengdongjiu, huangshaoyu
In-Reply-To: <1520093380-42577-1-git-send-email-gengdongjiu@huawei.com>
Export one API to specify virtual SEI syndrome value
for guest, and add a helper to get the VSESR_EL2 value.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
---
arch/arm64/include/asm/kvm_emulate.h | 5 +++++
arch/arm64/include/asm/kvm_host.h | 2 ++
arch/arm64/kvm/inject_fault.c | 5 +++++
3 files changed, 12 insertions(+)
diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 413dc82..3294885 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -71,6 +71,11 @@ static inline void vcpu_set_hcr(struct kvm_vcpu *vcpu, unsigned long hcr)
vcpu->arch.hcr_el2 = hcr;
}
+static inline unsigned long vcpu_get_vsesr(struct kvm_vcpu *vcpu)
+{
+ return vcpu->arch.vsesr_el2;
+}
+
static inline void vcpu_set_vsesr(struct kvm_vcpu *vcpu, u64 vsesr)
{
vcpu->arch.vsesr_el2 = vsesr;
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index a73f63a..3dc49b7 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -354,6 +354,8 @@ void handle_exit_early(struct kvm_vcpu *vcpu, struct kvm_run *run,
int kvm_perf_init(void);
int kvm_perf_teardown(void);
+void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome);
+
struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
static inline void __cpu_init_hyp_mode(phys_addr_t pgd_ptr,
diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
index 60666a0..78ecb28 100644
--- a/arch/arm64/kvm/inject_fault.c
+++ b/arch/arm64/kvm/inject_fault.c
@@ -186,3 +186,8 @@ void kvm_inject_vabt(struct kvm_vcpu *vcpu)
{
pend_guest_serror(vcpu, ESR_ELx_ISV);
}
+
+void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome)
+{
+ pend_guest_serror(vcpu, syndrome & ESR_ELx_ISS_MASK);
+}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox