* [PATCH 2/3] mfd: arizona: Disable IRQs during driver remove
From: Charles Keepax @ 2016-11-14 17:15 UTC (permalink / raw)
To: lee.jones; +Cc: linux-kernel, patches
In-Reply-To: <1479143757-30531-1-git-send-email-ckeepax@opensource.wolfsonmicro.com>
As DCVDD will often be supplied by a child node of the MFD, we
can't call mfd_remove_devices as the first step in arizona_dev_exit
as might be expected (tidy up the children before we tidy up the
MFD). We need to disable and put the DCVDD regulator before we call
mfd_remove_devices, to prevent PM runtime from turning this back on we
also need to disable the PM runtime before we do this. Finally we can
not clean up the IRQs until all the MFD children have been removed, as
they may have registered IRQs themselves.
This creates a window of time where the interrupts are enabled but
the PM runtime, on which the IRQ handler depends, is not available,
any interrupts in this window will go unhandled and fill the log with
failed to resume device messages. To avoid this we simply disable the
main IRQ at the start of arizona_dev_exit, we don't need to actually
handle any IRQs in this window as we are removing the driver.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
---
drivers/mfd/arizona-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index 41767f7..b6d4bc6 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -1553,6 +1553,7 @@ EXPORT_SYMBOL_GPL(arizona_dev_init);
int arizona_dev_exit(struct arizona *arizona)
{
+ disable_irq(arizona->irq);
pm_runtime_disable(arizona->dev);
regulator_disable(arizona->dcvdd);
--
2.1.4
^ permalink raw reply related
* Patch procedure
From: feas @ 2016-11-14 17:16 UTC (permalink / raw)
To: devel, gregkh, linux-kernel
Here is how I am going about making the patches. It is basically
what I have picked up from kernel newbies among other sites
and videos on making patches. I would be greatful for any
pointers on what seems to be the problem(s) with why it does
not produce a proper patch.
I will use drivers/staging/xgifb/vb_setmode.c as the example
as it was one of my latest and largest.
I run:
./scripts/checkpatch.pl --terse --strict --file drivers/staging/xgifb/vb_setmode.c
Patch submissions needed
CHECK: spaces preferred around that '+' (ctx:VxV) 1
CHECK: Alignment should match open parenthesis 9
CHECK: No space is necessary after a cast 7
CHECK: Logical continuations should be on the previous line 1
WARNING: braces {} are not necessary for single statement blocks 1
Spelling 1
0 errors, 2 warnings, 538 checks, 5526 lines checked
I count each occurance for each type of warning/check I will work on
and figure how many patches will be needed for each.
i.e 90 CHECK: Alignment should match open parenthesis comes to 9 patches.
This example would be 20 total patches in the series.
I check for spelling errors to add a patch or not.
I check to see if non checkpatch type fixes are needed.
i.e. columns/comments need to aligned
I check the mailing list to see if the same type if patches have been
submitted in the last year.
I make all edits needed for one issue
(save Alignment should match open parenthesis for last as other changes
will effect it.)
I open git gui, select rescan, then add hunks to a size that is not
too big and edit the subject, commit message and signed off by.
(It is easier to see how long the patch will be from the hunks and how
many more I have left to fit into the allotted patch series.)
[STYLE 1/20]staging:vb_setmode.c Align to parenthesis
Make suggested modification from checkpatch in reference
to: CHECK: Alignment should match open parenthesis
Signed-off-by: Walt Feasel <waltfeasel@gmail.com>
Commit it
perl scripts/get_maintainer.pl --nogit-fallback --norolestats
-f drivers/staging/xgifb/vb_setmode.c
Arnaud Patard <arnaud.patard@rtp-net.org>
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
devel@driverdev.osuosl.org
linux-kernel@vger.kernel.org
I also check the TODO list to see if there are any others that
need to copied for the patches.
(The very first patches I used had a option that was removing
the mailing list for some but not others. I dont know why.
it was just what I had copied from a site telling me how to
get the emails to send too.)
git send-email --annotate HEAD^ --to arnaud.patard@rtp-net.org
--cc gregkh@linuxfoundation.org -cc devel@driverdev.osuosl.org
--cc linux-kernel@vger.kernel.org
Verify the message info and press ctrl-x
Send this email? ([y]es|[n]o|[q]uit|[a]ll): y
repeat for remaining hunks.
When all hunks are done start next issue.
I will remove [STYLE] (thought it would make easier to skip if
you did not have time to review just style changes).
New subject example would be:
staging: xgifb: vb_setmode.c Align to parenthesis
In the beginning I made all of the edits at one time per file,
now I only do one type cause I cant separate if two different
issues are part of the same hunk.
The numbering of sequence I will add leading 0 when needed in the
[PATCH v2 09/20]
New subject line would read as:
[PATCH v2 09/20] staging: xgifb: vb_setmode.c Align to parenthesis
The subject lines are the same for the same type of fix except for
the series number.
The patch would be too large if I sent them all in one. I don't know
how else you would want me to name them when there may be 9 patches
for the same issue to keep file size/length down.
Walt
^ permalink raw reply
* Re: [Qemu-devel] [RFC 0/3] aio: experimental virtio-blk polling mode
From: Paolo Bonzini @ 2016-11-14 17:15 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Karl Rister, Stefan Hajnoczi, qemu-devel, Andrew Theurer,
Fam Zheng
In-Reply-To: <20161114170611.GE1352@stefanha-x1.localdomain>
[-- Attachment #1: Type: text/plain, Size: 908 bytes --]
On 14/11/2016 18:06, Stefan Hajnoczi wrote:
>>> > > Very interesting that QEMU_AIO_POLL_MAX_NS=1 performs so well without
>>> > > much CPU overhead.
>> >
>> > That basically means "avoid a syscall if you already know there's
>> > something to do", so in retrospect it's not that surprising. Still
>> > interesting though, and it means that the feature is useful even if you
>> > don't have CPU to waste.
> Can you spell out which syscall you mean? Reading the ioeventfd?
I mean ppoll. If ppoll succeeds without ever going to sleep, you can
achieve the same result with QEMU_AIO_POLL_MAX_NS=1, but cheaper.
Paolo
> The benchmark uses virtio-blk dataplane and iodepth=1 so there shouldn't
> be much IOThread event loop activity besides the single I/O request.
>
> The reason this puzzles me is that I wouldn't expect poll to succeed
> with QEMU_AIO_POLL_MAX_NS and iodepth=1.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* [PATCH v2 1/3] mfd: arizona: Correctly clean up after IRQs
From: Charles Keepax @ 2016-11-14 17:15 UTC (permalink / raw)
To: lee.jones; +Cc: linux-kernel, patches
Currently we leak a lot of things when tearing down the IRQs this patch
fixes this cleaning up both the IRQ mappings and the IRQ domain itself.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
---
Changes since v1:
- Correct handling of ret and error messages from irq_create_mapping
Thanks,
Charles
drivers/mfd/arizona-irq.c | 54 +++++++++++++++++++++++++++++++++++------------
1 file changed, 40 insertions(+), 14 deletions(-)
diff --git a/drivers/mfd/arizona-irq.c b/drivers/mfd/arizona-irq.c
index 2e01975..bc3b342 100644
--- a/drivers/mfd/arizona-irq.c
+++ b/drivers/mfd/arizona-irq.c
@@ -207,6 +207,7 @@ int arizona_irq_init(struct arizona *arizona)
int ret, i;
const struct regmap_irq_chip *aod, *irq;
struct irq_data *irq_data;
+ unsigned int virq;
arizona->ctrlif_error = true;
@@ -318,24 +319,34 @@ int arizona_irq_init(struct arizona *arizona)
}
if (aod) {
- ret = regmap_add_irq_chip(arizona->regmap,
- irq_create_mapping(arizona->virq, 0),
- IRQF_ONESHOT, 0, aod,
- &arizona->aod_irq_chip);
+ virq = irq_create_mapping(arizona->virq, 0);
+ if (!virq) {
+ dev_err(arizona->dev, "Failed to map AOD IRQs\n");
+ ret = -EINVAL;
+ goto err_domain;
+ }
+
+ ret = regmap_add_irq_chip(arizona->regmap, virq, IRQF_ONESHOT,
+ 0, aod, &arizona->aod_irq_chip);
if (ret != 0) {
dev_err(arizona->dev,
"Failed to add AOD IRQs: %d\n", ret);
- goto err;
+ goto err_map_aod;
}
}
- ret = regmap_add_irq_chip(arizona->regmap,
- irq_create_mapping(arizona->virq, 1),
- IRQF_ONESHOT, 0, irq,
- &arizona->irq_chip);
+ virq = irq_create_mapping(arizona->virq, 1);
+ if (!virq) {
+ dev_err(arizona->dev, "Failed to map main IRQs\n");
+ ret = -EINVAL;
+ goto err_aod;
+ }
+
+ ret = regmap_add_irq_chip(arizona->regmap, virq, IRQF_ONESHOT,
+ 0, irq, &arizona->irq_chip);
if (ret != 0) {
dev_err(arizona->dev, "Failed to add main IRQs: %d\n", ret);
- goto err_aod;
+ goto err_map_main_irq;
}
/* Used to emulate edge trigger and to work around broken pinmux */
@@ -400,23 +411,38 @@ int arizona_irq_init(struct arizona *arizona)
err_main_irq:
regmap_del_irq_chip(irq_find_mapping(arizona->virq, 1),
arizona->irq_chip);
+err_map_main_irq:
+ irq_dispose_mapping(irq_find_mapping(arizona->virq, 1));
err_aod:
regmap_del_irq_chip(irq_find_mapping(arizona->virq, 0),
arizona->aod_irq_chip);
+err_map_aod:
+ irq_dispose_mapping(irq_find_mapping(arizona->virq, 0));
+err_domain:
+ irq_domain_remove(arizona->virq);
err:
return ret;
}
int arizona_irq_exit(struct arizona *arizona)
{
+ unsigned int virq;
+
if (arizona->ctrlif_error)
free_irq(arizona_map_irq(arizona, ARIZONA_IRQ_CTRLIF_ERR),
arizona);
free_irq(arizona_map_irq(arizona, ARIZONA_IRQ_BOOT_DONE), arizona);
- regmap_del_irq_chip(irq_find_mapping(arizona->virq, 1),
- arizona->irq_chip);
- regmap_del_irq_chip(irq_find_mapping(arizona->virq, 0),
- arizona->aod_irq_chip);
+
+ virq = irq_find_mapping(arizona->virq, 1);
+ regmap_del_irq_chip(virq, arizona->irq_chip);
+ irq_dispose_mapping(virq);
+
+ virq = irq_find_mapping(arizona->virq, 0);
+ regmap_del_irq_chip(virq, arizona->aod_irq_chip);
+ irq_dispose_mapping(virq);
+
+ irq_domain_remove(arizona->virq);
+
free_irq(arizona->irq, arizona);
return 0;
--
2.1.4
^ permalink raw reply related
* [PATCH 3/3] mfd: arizona: Use arizona_map_irq instead of hard coding it
From: Charles Keepax @ 2016-11-14 17:15 UTC (permalink / raw)
To: lee.jones; +Cc: linux-kernel, patches
In-Reply-To: <1479143757-30531-1-git-send-email-ckeepax@opensource.wolfsonmicro.com>
We have arizona_map_irq we might as well use it rather than hard coding
it in several places.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
---
drivers/mfd/arizona-irq.c | 21 +++++++++------------
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/mfd/arizona-irq.c b/drivers/mfd/arizona-irq.c
index bc3b342..22f96c9 100644
--- a/drivers/mfd/arizona-irq.c
+++ b/drivers/mfd/arizona-irq.c
@@ -204,7 +204,7 @@ static const struct irq_domain_ops arizona_domain_ops = {
int arizona_irq_init(struct arizona *arizona)
{
int flags = IRQF_ONESHOT;
- int ret, i;
+ int ret;
const struct regmap_irq_chip *aod, *irq;
struct irq_data *irq_data;
unsigned int virq;
@@ -379,9 +379,8 @@ int arizona_irq_init(struct arizona *arizona)
}
/* Make sure the boot done IRQ is unmasked for resumes */
- i = arizona_map_irq(arizona, ARIZONA_IRQ_BOOT_DONE);
- ret = request_threaded_irq(i, NULL, arizona_boot_done, IRQF_ONESHOT,
- "Boot done", arizona);
+ ret = arizona_request_irq(arizona, ARIZONA_IRQ_BOOT_DONE, "Boot done",
+ arizona_boot_done, arizona);
if (ret != 0) {
dev_err(arizona->dev, "Failed to request boot done %d: %d\n",
arizona->irq, ret);
@@ -390,10 +389,9 @@ int arizona_irq_init(struct arizona *arizona)
/* Handle control interface errors in the core */
if (arizona->ctrlif_error) {
- i = arizona_map_irq(arizona, ARIZONA_IRQ_CTRLIF_ERR);
- ret = request_threaded_irq(i, NULL, arizona_ctrlif_err,
- IRQF_ONESHOT,
- "Control interface error", arizona);
+ ret = arizona_request_irq(arizona, ARIZONA_IRQ_CTRLIF_ERR,
+ "Control interface error",
+ arizona_ctrlif_err, arizona);
if (ret != 0) {
dev_err(arizona->dev,
"Failed to request CTRLIF_ERR %d: %d\n",
@@ -405,7 +403,7 @@ int arizona_irq_init(struct arizona *arizona)
return 0;
err_ctrlif:
- free_irq(arizona_map_irq(arizona, ARIZONA_IRQ_BOOT_DONE), arizona);
+ arizona_free_irq(arizona, ARIZONA_IRQ_BOOT_DONE, arizona);
err_boot_done:
free_irq(arizona->irq, arizona);
err_main_irq:
@@ -429,9 +427,8 @@ int arizona_irq_exit(struct arizona *arizona)
unsigned int virq;
if (arizona->ctrlif_error)
- free_irq(arizona_map_irq(arizona, ARIZONA_IRQ_CTRLIF_ERR),
- arizona);
- free_irq(arizona_map_irq(arizona, ARIZONA_IRQ_BOOT_DONE), arizona);
+ arizona_free_irq(arizona, ARIZONA_IRQ_CTRLIF_ERR, arizona);
+ arizona_free_irq(arizona, ARIZONA_IRQ_BOOT_DONE, arizona);
virq = irq_find_mapping(arizona->virq, 1);
regmap_del_irq_chip(virq, arizona->irq_chip);
--
2.1.4
^ permalink raw reply related
* Re: [RFC PATCH v3 01/20] x86: Documentation for AMD Secure Memory Encryption (SME)
From: Tom Lendacky @ 2016-11-14 17:15 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-arch, linux-efi, kvm, linux-doc, x86, linux-kernel,
kasan-dev, linux-mm, iommu, Rik van Riel,
Radim Krčmář, Arnd Bergmann, Jonathan Corbet,
Matt Fleming, Joerg Roedel, Konrad Rzeszutek Wilk, Paolo Bonzini,
Larry Woodman, Ingo Molnar, Andy Lutomirski, H. Peter Anvin,
Andrey Ryabinin, Alexander Potapenko, Thomas Gleixner,
Dmitry Vyukov
In-Reply-To: <20161110105114.oiwcgpb436dxrdpb@pd.tnic>
On 11/10/2016 4:51 AM, Borislav Petkov wrote:
> On Wed, Nov 09, 2016 at 06:34:39PM -0600, Tom Lendacky wrote:
>> This patch adds a Documenation entry to decribe the AMD Secure Memory
>> Encryption (SME) feature.
>>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>> ---
>> Documentation/kernel-parameters.txt | 5 +++
>> Documentation/x86/amd-memory-encryption.txt | 40 +++++++++++++++++++++++++++
>> 2 files changed, 45 insertions(+)
>> create mode 100644 Documentation/x86/amd-memory-encryption.txt
>>
>> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
>> index 030e9e9..4c730b0 100644
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -2282,6 +2282,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>> memory contents and reserves bad memory
>> regions that are detected.
>>
>> + mem_encrypt= [X86-64] Enable AMD Secure Memory Encryption (SME)
>> + Memory encryption is disabled by default, using this
>> + switch, memory encryption can be enabled.
>
> I'd say here:
>
> "Force-enable memory encryption if it is disabled in the
> BIOS."
Good suggestion, that will make this clearer.
>
>> + on: enable memory encryption
>> +
>> meye.*= [HW] Set MotionEye Camera parameters
>> See Documentation/video4linux/meye.txt.
>>
>> diff --git a/Documentation/x86/amd-memory-encryption.txt b/Documentation/x86/amd-memory-encryption.txt
>> new file mode 100644
>> index 0000000..788d871
>> --- /dev/null
>> +++ b/Documentation/x86/amd-memory-encryption.txt
>> @@ -0,0 +1,40 @@
>> +Secure Memory Encryption (SME) is a feature found on AMD processors.
>> +
>> +SME provides the ability to mark individual pages of memory as encrypted using
>> +the standard x86 page tables. A page that is marked encrypted will be
>> +automatically decrypted when read from DRAM and encrypted when written to
>> +DRAM. SME can therefore be used to protect the contents of DRAM from physical
>> +attacks on the system.
>> +
>> +A page is encrypted when a page table entry has the encryption bit set (see
>> +below how to determine the position of the bit). The encryption bit can be
>> +specified in the cr3 register, allowing the PGD table to be encrypted. Each
>> +successive level of page tables can also be encrypted.
>> +
>> +Support for SME can be determined through the CPUID instruction. The CPUID
>> +function 0x8000001f reports information related to SME:
>> +
>> + 0x8000001f[eax]:
>> + Bit[0] indicates support for SME
>> + 0x8000001f[ebx]:
>> + Bit[5:0] pagetable bit number used to enable memory encryption
>> + Bit[11:6] reduction in physical address space, in bits, when
>> + memory encryption is enabled (this only affects system
>> + physical addresses, not guest physical addresses)
>> +
>> +If support for SME is present, MSR 0xc00100010 (SYS_CFG) can be used to
>> +determine if SME is enabled and/or to enable memory encryption:
>> +
>> + 0xc0010010:
>> + Bit[23] 0 = memory encryption features are disabled
>> + 1 = memory encryption features are enabled
>> +
>> +Linux relies on BIOS to set this bit if BIOS has determined that the reduction
>> +in the physical address space as a result of enabling memory encryption (see
>> +CPUID information above) will not conflict with the address space resource
>> +requirements for the system. If this bit is not set upon Linux startup then
>> +Linux itself will not set it and memory encryption will not be possible.
>> +
>> +SME support is configurable through the AMD_MEM_ENCRYPT config option.
>> +Additionally, the mem_encrypt=on command line parameter is required to activate
>> +memory encryption.
>
> So how am I to understand this? We won't have TSME or we will but it
> will be off by default and users will have to enable it in the BIOS or
> will have to boot with mem_encrypt=on...?
>
> Can you please expand on all the possible options there would be
> available to users?
Yup, I'll try to expand on the documentation to include all the
possibilities for this.
Thanks,
Tom
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC PATCH v3 01/20] x86: Documentation for AMD Secure Memory Encryption (SME)
From: Tom Lendacky @ 2016-11-14 17:15 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-arch, linux-efi, kvm, linux-doc, x86, linux-kernel,
kasan-dev, linux-mm, iommu, Rik van Riel,
Radim Krčmář, Arnd Bergmann, Jonathan Corbet,
Matt Fleming, Joerg Roedel, Konrad Rzeszutek Wilk, Paolo Bonzini,
Larry Woodman, Ingo Molnar, Andy Lutomirski, H. Peter Anvin,
Andrey Ryabinin, Alexander Potapenko, Thomas Gleixner,
Dmitry Vyukov
In-Reply-To: <20161110105114.oiwcgpb436dxrdpb@pd.tnic>
On 11/10/2016 4:51 AM, Borislav Petkov wrote:
> On Wed, Nov 09, 2016 at 06:34:39PM -0600, Tom Lendacky wrote:
>> This patch adds a Documenation entry to decribe the AMD Secure Memory
>> Encryption (SME) feature.
>>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>> ---
>> Documentation/kernel-parameters.txt | 5 +++
>> Documentation/x86/amd-memory-encryption.txt | 40 +++++++++++++++++++++++++++
>> 2 files changed, 45 insertions(+)
>> create mode 100644 Documentation/x86/amd-memory-encryption.txt
>>
>> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
>> index 030e9e9..4c730b0 100644
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -2282,6 +2282,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>> memory contents and reserves bad memory
>> regions that are detected.
>>
>> + mem_encrypt= [X86-64] Enable AMD Secure Memory Encryption (SME)
>> + Memory encryption is disabled by default, using this
>> + switch, memory encryption can be enabled.
>
> I'd say here:
>
> "Force-enable memory encryption if it is disabled in the
> BIOS."
Good suggestion, that will make this clearer.
>
>> + on: enable memory encryption
>> +
>> meye.*= [HW] Set MotionEye Camera parameters
>> See Documentation/video4linux/meye.txt.
>>
>> diff --git a/Documentation/x86/amd-memory-encryption.txt b/Documentation/x86/amd-memory-encryption.txt
>> new file mode 100644
>> index 0000000..788d871
>> --- /dev/null
>> +++ b/Documentation/x86/amd-memory-encryption.txt
>> @@ -0,0 +1,40 @@
>> +Secure Memory Encryption (SME) is a feature found on AMD processors.
>> +
>> +SME provides the ability to mark individual pages of memory as encrypted using
>> +the standard x86 page tables. A page that is marked encrypted will be
>> +automatically decrypted when read from DRAM and encrypted when written to
>> +DRAM. SME can therefore be used to protect the contents of DRAM from physical
>> +attacks on the system.
>> +
>> +A page is encrypted when a page table entry has the encryption bit set (see
>> +below how to determine the position of the bit). The encryption bit can be
>> +specified in the cr3 register, allowing the PGD table to be encrypted. Each
>> +successive level of page tables can also be encrypted.
>> +
>> +Support for SME can be determined through the CPUID instruction. The CPUID
>> +function 0x8000001f reports information related to SME:
>> +
>> + 0x8000001f[eax]:
>> + Bit[0] indicates support for SME
>> + 0x8000001f[ebx]:
>> + Bit[5:0] pagetable bit number used to enable memory encryption
>> + Bit[11:6] reduction in physical address space, in bits, when
>> + memory encryption is enabled (this only affects system
>> + physical addresses, not guest physical addresses)
>> +
>> +If support for SME is present, MSR 0xc00100010 (SYS_CFG) can be used to
>> +determine if SME is enabled and/or to enable memory encryption:
>> +
>> + 0xc0010010:
>> + Bit[23] 0 = memory encryption features are disabled
>> + 1 = memory encryption features are enabled
>> +
>> +Linux relies on BIOS to set this bit if BIOS has determined that the reduction
>> +in the physical address space as a result of enabling memory encryption (see
>> +CPUID information above) will not conflict with the address space resource
>> +requirements for the system. If this bit is not set upon Linux startup then
>> +Linux itself will not set it and memory encryption will not be possible.
>> +
>> +SME support is configurable through the AMD_MEM_ENCRYPT config option.
>> +Additionally, the mem_encrypt=on command line parameter is required to activate
>> +memory encryption.
>
> So how am I to understand this? We won't have TSME or we will but it
> will be off by default and users will have to enable it in the BIOS or
> will have to boot with mem_encrypt=on...?
>
> Can you please expand on all the possible options there would be
> available to users?
Yup, I'll try to expand on the documentation to include all the
possibilities for this.
Thanks,
Tom
>
^ permalink raw reply
* Re: [RFC PATCH v3 01/20] x86: Documentation for AMD Secure Memory Encryption (SME)
From: Tom Lendacky @ 2016-11-14 17:15 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-arch, linux-efi, kvm, linux-doc, x86, linux-kernel,
kasan-dev, linux-mm, iommu, Rik van Riel,
Radim Krčmář, Arnd Bergmann, Jonathan Corbet,
Matt Fleming, Joerg Roedel, Konrad Rzeszutek Wilk, Paolo Bonzini,
Larry Woodman, Ingo Molnar, Andy Lutomirski, H. Peter Anvin,
Andrey Ryabinin
In-Reply-To: <20161110105114.oiwcgpb436dxrdpb@pd.tnic>
On 11/10/2016 4:51 AM, Borislav Petkov wrote:
> On Wed, Nov 09, 2016 at 06:34:39PM -0600, Tom Lendacky wrote:
>> This patch adds a Documenation entry to decribe the AMD Secure Memory
>> Encryption (SME) feature.
>>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
>> ---
>> Documentation/kernel-parameters.txt | 5 +++
>> Documentation/x86/amd-memory-encryption.txt | 40 +++++++++++++++++++++++++++
>> 2 files changed, 45 insertions(+)
>> create mode 100644 Documentation/x86/amd-memory-encryption.txt
>>
>> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
>> index 030e9e9..4c730b0 100644
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -2282,6 +2282,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>> memory contents and reserves bad memory
>> regions that are detected.
>>
>> + mem_encrypt= [X86-64] Enable AMD Secure Memory Encryption (SME)
>> + Memory encryption is disabled by default, using this
>> + switch, memory encryption can be enabled.
>
> I'd say here:
>
> "Force-enable memory encryption if it is disabled in the
> BIOS."
Good suggestion, that will make this clearer.
>
>> + on: enable memory encryption
>> +
>> meye.*= [HW] Set MotionEye Camera parameters
>> See Documentation/video4linux/meye.txt.
>>
>> diff --git a/Documentation/x86/amd-memory-encryption.txt b/Documentation/x86/amd-memory-encryption.txt
>> new file mode 100644
>> index 0000000..788d871
>> --- /dev/null
>> +++ b/Documentation/x86/amd-memory-encryption.txt
>> @@ -0,0 +1,40 @@
>> +Secure Memory Encryption (SME) is a feature found on AMD processors.
>> +
>> +SME provides the ability to mark individual pages of memory as encrypted using
>> +the standard x86 page tables. A page that is marked encrypted will be
>> +automatically decrypted when read from DRAM and encrypted when written to
>> +DRAM. SME can therefore be used to protect the contents of DRAM from physical
>> +attacks on the system.
>> +
>> +A page is encrypted when a page table entry has the encryption bit set (see
>> +below how to determine the position of the bit). The encryption bit can be
>> +specified in the cr3 register, allowing the PGD table to be encrypted. Each
>> +successive level of page tables can also be encrypted.
>> +
>> +Support for SME can be determined through the CPUID instruction. The CPUID
>> +function 0x8000001f reports information related to SME:
>> +
>> + 0x8000001f[eax]:
>> + Bit[0] indicates support for SME
>> + 0x8000001f[ebx]:
>> + Bit[5:0] pagetable bit number used to enable memory encryption
>> + Bit[11:6] reduction in physical address space, in bits, when
>> + memory encryption is enabled (this only affects system
>> + physical addresses, not guest physical addresses)
>> +
>> +If support for SME is present, MSR 0xc00100010 (SYS_CFG) can be used to
>> +determine if SME is enabled and/or to enable memory encryption:
>> +
>> + 0xc0010010:
>> + Bit[23] 0 = memory encryption features are disabled
>> + 1 = memory encryption features are enabled
>> +
>> +Linux relies on BIOS to set this bit if BIOS has determined that the reduction
>> +in the physical address space as a result of enabling memory encryption (see
>> +CPUID information above) will not conflict with the address space resource
>> +requirements for the system. If this bit is not set upon Linux startup then
>> +Linux itself will not set it and memory encryption will not be possible.
>> +
>> +SME support is configurable through the AMD_MEM_ENCRYPT config option.
>> +Additionally, the mem_encrypt=on command line parameter is required to activate
>> +memory encryption.
>
> So how am I to understand this? We won't have TSME or we will but it
> will be off by default and users will have to enable it in the BIOS or
> will have to boot with mem_encrypt=on...?
>
> Can you please expand on all the possible options there would be
> available to users?
Yup, I'll try to expand on the documentation to include all the
possibilities for this.
Thanks,
Tom
>
^ permalink raw reply
* [Buildroot] [PATCH] config: bump linux kernel to 4.8.6 in synopsys defconfigs
From: Yann E. MORIN @ 2016-11-14 17:15 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1479134749.4408.54.camel@synopsys.com>
Alexey, All,
On 2016-11-14 14:46 +0000, Alexey Brodkin spake thusly:
[--SNIP--]
> The point is we were sitting on the patch for quite some time and when we saw
> RC1 was cut (as always unexpectedly :)) simply sent out what we had in our tree.
"Unexpectedly" is a bit of untrue: we've been doing releases every three
months since February 2009, 7 years ago, with a one-month freeze before
the release.
So, anything that comes on-or-after the first day of the release month is
not guaranteed to go in master, unless it is a fix.
This is far from "unexpected". ;-)
Granted, the rc1 tag can be (and has often been) delayed by a few days,
but this is a minor delay; it has never been guaranteed the first few
days of the stabilisation month would still be open for merging into
master...
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply
* Re: [WireGuard] [PATCH v3] ip6_output: ensure flow saddr actually belongs to device
From: David Ahern @ 2016-11-14 17:17 UTC (permalink / raw)
To: Hannes Frederic Sowa, Jason A. Donenfeld, Netdev,
WireGuard mailing list, LKML, YOSHIFUJI Hideaki
In-Reply-To: <7d8c0210-9132-c755-9053-6ec19409e343@stressinduktion.org>
On 11/14/16 10:04 AM, Hannes Frederic Sowa wrote:
> On 14.11.2016 17:55, David Ahern wrote:
>> On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote:
>>> On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote:
>>>> This puts the IPv6 routing functions in parity with the IPv4 routing
>>>> functions. Namely, we now check in v6 that if a flowi6 requests an
>>>> saddr, the returned dst actually corresponds to a net device that has
>>>> that saddr. This mirrors the v4 logic with __ip_dev_find in
>>>> __ip_route_output_key_hash. In the event that the returned dst is not
>>>> for a dst with a dev that has the saddr, we return -EINVAL, just like
>>>> v4; this makes it easy to use the same error handlers for both cases.
>>>>
>>>> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
>>>> Cc: David Ahern <dsa@cumulusnetworks.com>
>>>> ---
>>>> Changes from v2:
>>>> It turns out ipv6_chk_addr already has the device enumeration
>>>> logic that we need by simply passing NULL.
>>>>
>>>> net/ipv6/ip6_output.c | 4 ++++
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
>>>> index 6001e78..b3b5cb6 100644
>>>> --- a/net/ipv6/ip6_output.c
>>>> +++ b/net/ipv6/ip6_output.c
>>>> @@ -926,6 +926,10 @@ static int ip6_dst_lookup_tail(struct net *net,
>>>> const struct sock *sk,
>>>> int err;
>>>> int flags = 0;
>>>>
>>>> + if (!ipv6_addr_any(&fl6->saddr) &&
>>>> + !ipv6_chk_addr(net, &fl6->saddr, NULL, 1))
>>>> + return -EINVAL;
>>>
>>> Hmm, this check is too permissive, no?
>>>
>>> E.g. what happens if you move a link local address from one interface to
>>> another? In this case this code would still allow the saddr to be used.
>>
>> This check -- like the ipv4 variant -- only verifies the saddr is locally assigned. If the address moves interfaces it should be fine.
>
> But in this case we should actually bail out, no?
>
> Let's say, user assumes we are on ifindex eth0 with LL address from
> eth0. Suddenly the LL address from eth0 is moved to eth1, we can't
> accept this source address anymore and need to return -EINVAL, too.
so you mean if rt6_need_strict(&fl6->saddr) then the dev needs to be considered.
>
>>> I just also quickly read up on the history (sorry was travelling last
>>> week) and wonder if you ever saw a user space facing bug or if this is
>>> basically some difference you saw while writing out of tree code?
>>
>> I checked the userspace API this morning. bind and cmsg for example check that the address is valid with calls to ipv6_chk_addr.
>
> Hmm, so it fixes no real bug.
>
> Because of translations of flowi6_oif we actually can't do a correct
> check of source address for cases like the one I outlined above? Hmm,
> maybe we should simply depend on user space checks.
I believe Jason's case is forwarding path and the ipv6_stub->ipv6_dst_lookup API.
^ permalink raw reply
* Re: [PATCH] cpufreq: intel_pstate: fix intel_pstate_use_acpi_profile helper
From: Srinivas Pandruvada @ 2016-11-14 17:14 UTC (permalink / raw)
To: Arnd Bergmann, Rafael J. Wysocki
Cc: Len Brown, Viresh Kumar, Philippe Longepe, Stephane Gasparini,
linux-pm, linux-kernel
In-Reply-To: <20161114164216.2657919-1-arnd@arndb.de>
On Mon, 2016-11-14 at 17:41 +0100, Arnd Bergmann wrote:
> The newly added function uses two different prototypes depending
> on configuration, and one of them does not match the caller:
>
> drivers/cpufreq/intel_pstate.c: In function ‘copy_cpu_funcs’:
> drivers/cpufreq/intel_pstate.c:1798:2: error: too few arguments to
> function ‘intel_pstate_use_acpi_profile’
>
> This changes it to look like the other one.
Sorry about that.
>
> Fixes: 3bea6a285476 ("cpufreq: intel_pstate: Use cpu load based
> algorithm for mobile class devices")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> ---
> drivers/cpufreq/intel_pstate.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/intel_pstate.c
> b/drivers/cpufreq/intel_pstate.c
> index 65832f8eacdc..7153cf2d8e11 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -1779,7 +1779,7 @@ static void intel_pstate_use_acpi_profile(void)
> get_target_pstate_use_cpu_load;
> }
> #else
> -static inline void intel_pstate_use_acpi_profile(struct pstate_funcs
> *funcs)
> +static inline void intel_pstate_use_acpi_profile(void)
> {
> }
> #endif
^ permalink raw reply
* Re: [RESEND][PATCH 5/6] dt-bindings: gpio: Update gpio bindings for LS2088A
From: Rob Herring @ 2016-11-14 17:14 UTC (permalink / raw)
To: Abhimanyu Saini
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, scott.wood-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Priyanka Jain,
Ashish Kumar
In-Reply-To: <1478597664-14799-6-git-send-email-abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
On Tue, Nov 08, 2016 at 03:04:23PM +0530, Abhimanyu Saini wrote:
> Signed-off-by: Priyanka Jain <priyanka.jain-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Ashish Kumar <ashish.kumar-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Abhimanyu Saini <abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
> ---
> Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RESEND][PATCH 5/6] dt-bindings: gpio: Update gpio bindings for LS2088A
From: Rob Herring @ 2016-11-14 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478597664-14799-6-git-send-email-abhimanyu.saini@nxp.com>
On Tue, Nov 08, 2016 at 03:04:23PM +0530, Abhimanyu Saini wrote:
> Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
> Signed-off-by: Ashish Kumar <ashish.kumar@nxp.com>
> Signed-off-by: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> ---
> Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH linux v6 18/18] drivers/fsi: Add SCOM FSI client device driver
From: Christopher Bostic @ 2016-11-14 17:13 UTC (permalink / raw)
To: Alistair Popple; +Cc: OpenBMC Maillist, xxpetri, zahrens
In-Reply-To: <1518766.oRRvze06Vl@new-mexico>
On Sun, Nov 13, 2016 at 5:44 PM, Alistair Popple <alistair@popple.id.au> wrote:
> Hi Chris,
>
> Is there a similar device driver for the CFAM/FSI that I missed? That is will
> there be a chardev for read/writing FSI addresses directly (ie. a chardev to
> call fsi_device_read/write)? Probably not critical for an initial release but
> we will need one at some point as I'm pretty sure the cronus server for
> example has get/putcfam commands as some registers aren't available via SCOM.
>
> Regards,
>
> Alistair
>
Hi Alistair,
No there isn't a driver like you describe in the set as it is now. I
agree that would be important to have for general bringup debug.
Once this set is accepted I'll add that.
Thanks
> On Sun, 30 Oct 2016 05:09:20 PM christopher.lee.bostic@gmail.com wrote:
>> From: Chris Bostic <cbostic@us.ibm.com>
>>
>> Create a simple SCOM engine device driver that reads and writes
>> across an FSI bus.
>>
>> Signed-off-by: Chris Bostic <cbostic@us.ibm.com>
>>
>> ---
>>
>> V4 - Add put_scom and get_scom operations
>>
>> V5 - Add character device registration and fill in read/write
>> syscalls.
>>
>> V6 - Add multi scom engine support. Add list of devices.
>> Use file private data to store and hand off scom structures.
>>
>> - Add lseek, open, close
>>
>> - Remove data/address structure to pass from user space to
>> kernel. Use offset provided by read/write and pass data
>>
>> - Added list setup in init and so did not add the macro
>> module_fsi_driver
>>
>> - Global structs made static where possible.
>>
>> - Change from char dev to use misc device api as shown
>> in examples from Jeremy Kere.
>> ---
>> drivers/fsi/Kconfig | 6 ++
>> drivers/fsi/Makefile | 1 +
>> drivers/fsi/fsi-scom.c | 238
> +++++++++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 245 insertions(+)
>> create mode 100644 drivers/fsi/fsi-scom.c
>>
>> diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig
>> index b21fe3c..1fa9bc0 100644
>> --- a/drivers/fsi/Kconfig
>> +++ b/drivers/fsi/Kconfig
>> @@ -23,6 +23,12 @@ config FSI_MASTER_GPIO
>> depends on FSI
>> ---help---
>> This option enables a FSI master driver using GPIO lines.
>> +
>> +config FSI_SCOM
>> + tristate "SCOM FSI client"
>> + depends on FSI
>> + ---help---
>> + This option enables the SCOM FSI client device driver.
>> endif
>>
>> endmenu
>> diff --git a/drivers/fsi/Makefile b/drivers/fsi/Makefile
>> index 2021ce5..3e31d9a 100644
>> --- a/drivers/fsi/Makefile
>> +++ b/drivers/fsi/Makefile
>> @@ -2,3 +2,4 @@
>> obj-$(CONFIG_FSI) += fsi-core.o
>> obj-$(CONFIG_FSI_MASTER_FAKE) += fsi-master-fake.o
>> obj-$(CONFIG_FSI_MASTER_GPIO) += fsi-master-gpio.o
>> +obj-$(CONFIG_FSI_SCOM) += fsi-scom.o
>> diff --git a/drivers/fsi/fsi-scom.c b/drivers/fsi/fsi-scom.c
>> new file mode 100644
>> index 0000000..27be082
>> --- /dev/null
>> +++ b/drivers/fsi/fsi-scom.c
>> @@ -0,0 +1,238 @@
>> +/*
>> + * SCOM FSI Client device driver
>> + *
>> + * Copyright (C) IBM Corporation 2016
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERGCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include <linux/fsi.h>
>> +#include <linux/module.h>
>> +#include <linux/cdev.h>
>> +#include <linux/delay.h>
>> +#include <linux/fs.h>
>> +#include <linux/uaccess.h>
>> +#include <linux/slab.h>
>> +#include <linux/miscdevice.h>
>> +#include <linux/list.h>
>> +
>> +#define FSI_ENGID_SCOM 0x5
>> +
>> +#define SCOM_FSI2PIB_DELAY 50
>> +
>> +/* SCOM engine register set */
>> +#define SCOM_DATA0_REG 0x00
>> +#define SCOM_DATA1_REG 0x04
>> +#define SCOM_CMD_REG 0x08
>> +#define SCOM_RESET_REG 0x1C
>> +
>> +#define SCOM_RESET_CMD 0x80000000
>> +#define SCOM_WRITE_CMD 0x80000000
>> +
>> +struct scom_device {
>> + struct list_head link;
>> + struct fsi_device *fsi_dev;
>> + struct miscdevice mdev;
>> + char name[32];
>> +};
>> +
>> +#define to_scom_dev(x) container_of((x), struct scom_device,
> mdev)
>> +
>> +static struct list_head scom_devices;
>> +static atomic_t scom_idx = ATOMIC_INIT(0);
>> +static int scom_probe(struct device *);
>> +
>> +static int put_scom(struct scom_device *scom_dev, uint64_t value,
>> + uint32_t addr)
>> +{
>> + int rc;
>> + uint32_t data = SCOM_RESET_CMD;
>> +
>> + rc = fsi_device_write(scom_dev->fsi_dev, SCOM_RESET_REG, &data,
>> + sizeof(uint32_t));
>> + if (rc)
>> + return rc;
>> +
>> + data = (value >> 32) & 0xffffffff;
>> + rc = fsi_device_write(scom_dev->fsi_dev, SCOM_DATA0_REG, &data,
>> + sizeof(uint32_t));
>> + if (rc)
>> + return rc;
>> +
>> + data = value & 0xffffffff;
>> + rc = fsi_device_write(scom_dev->fsi_dev, SCOM_DATA1_REG, &data,
>> + sizeof(uint32_t));
>> + if (rc)
>> + return rc;
>> +
>> + data = SCOM_WRITE_CMD | addr;
>> + return fsi_device_write(scom_dev->fsi_dev, SCOM_CMD_REG, &data,
>> + sizeof(uint32_t));
>> +}
>> +
>> +static int get_scom(struct scom_device *scom_dev, uint64_t *value,
>> + uint32_t addr)
>> +{
>> + uint32_t result, data;
>> + int rc;
>> +
>> + udelay(SCOM_FSI2PIB_DELAY);
>> +
>> + data = addr;
>> + rc = fsi_device_write(scom_dev->fsi_dev, SCOM_CMD_REG, &data,
>> + sizeof(uint32_t));
>> + if (rc)
>> + return rc;
>> +
>> + rc = fsi_device_read(scom_dev->fsi_dev, SCOM_DATA0_REG, &result,
>> + sizeof(uint32_t));
>> + if (rc)
>> + return rc;
>> +
>> + *value |= (uint64_t) result << 32;
>> + rc = fsi_device_read(scom_dev->fsi_dev, SCOM_DATA1_REG, &result,
>> + sizeof(uint32_t));
>> + if (rc)
>> + return rc;
>> +
>> + *value |= result;
>> +
>> + return 0;
>> +}
>> +
>> +static loff_t scom_llseek(struct file *filep, loff_t offset, int whence)
>> +{
>> + if (whence != 0) /* SEEK_SET */
>> + return -EINVAL;
>> +
>> + filep->f_pos = offset;
>> + return offset;
>> +}
>> +
>> +static ssize_t scom_read(struct file *filep, char __user *buf, size_t len,
>> + loff_t *offset)
>> +{
>> + int rc = 0;
>> + struct miscdevice *mdev =
>> + (struct miscdevice *)filep->private_data;
>> + struct scom_device *scom = to_scom_dev(mdev);
>> + struct device *dev = &scom->fsi_dev->dev;
>> + uint64_t val;
>> +
>> + if (len != sizeof(uint64_t))
>> + return -EINVAL;
>> +
>> + rc = get_scom(scom, &val, *offset);
>> + if (rc) {
>> + dev_dbg(dev, "get_scom fail:%d\n", rc);
>> + return rc;
>> + }
>> +
>> + rc = copy_to_user(buf, &val, len);
>> + if (rc)
>> + dev_dbg(dev, "copy to user failed:%d\n", rc);
>> +
>> + return rc ? rc : len;
>> +}
>> +
>> +static ssize_t scom_write(struct file *filep, const char __user *buf,
>> + size_t len, loff_t *offset)
>> +{
>> + int rc = 0;
>> + struct miscdevice *mdev =
>> + (struct miscdevice *)filep->private_data;
>> + struct scom_device *scom = to_scom_dev(mdev);
>> + struct device *dev = &scom->fsi_dev->dev;
>> + uint64_t val;
>> +
>> + if (len != sizeof(uint64_t))
>> + return -EINVAL;
>> +
>> + rc = copy_from_user(&val, buf, len);
>> + if (rc) {
>> + dev_dbg(dev, "copy from user failed:%d\n", rc);
>> + return -EINVAL;
>> + }
>> +
>> + rc = put_scom(scom, val, *offset);
>> + if (rc)
>> + dev_dbg(dev, "put_scom failed with:%d\n", rc);
>> +
>> +
>> + return rc ? rc : len;
>> +}
>> +
>> +static const struct file_operations scom_fops = {
>> + .owner = THIS_MODULE,
>> + .llseek = scom_llseek,
>> + .read = scom_read,
>> + .write = scom_write,
>> +};
>> +
>> +static int scom_probe(struct device *dev)
>> +{
>> + struct fsi_device *fsi_dev = to_fsi_dev(dev);
>> + struct scom_device *scom = NULL;
>> +
>> + scom = devm_kzalloc(dev, sizeof(*scom), GFP_KERNEL);
>> + if (!scom)
>> + return -ENOMEM;
>> +
>> + snprintf(scom->name, sizeof(scom->name),
>> + "scom%d", atomic_inc_return(&scom_idx));
>> + scom->fsi_dev = fsi_dev;
>> + scom->mdev.minor = MISC_DYNAMIC_MINOR;
>> + scom->mdev.fops = &scom_fops;
>> + scom->mdev.name = scom->name;
>> + scom->mdev.parent = dev;
>> + list_add(&scom->link, &scom_devices);
>> +
>> + return misc_register(&scom->mdev);
>> +}
>> +
>> +static struct fsi_device_id scom_ids[] = {
>> + {
>> + .engine_type = FSI_ENGID_SCOM,
>> + .version = FSI_VERSION_ANY,
>> + },
>> + { 0 }
>> +};
>> +
>> +static struct fsi_driver scom_drv = {
>> + .id_table = scom_ids,
>> + .drv = {
>> + .name = "scom",
>> + .bus = &fsi_bus_type,
>> + .probe = scom_probe,
>> + }
>> +};
>> +
>> +static int scom_init(void)
>> +{
>> + INIT_LIST_HEAD(&scom_devices);
>> + return fsi_driver_register(&scom_drv);
>> +}
>> +
>> +static void scom_exit(void)
>> +{
>> + struct list_head *pos;
>> + struct scom_device *scom = NULL;
>> +
>> + list_for_each(pos, &scom_devices) {
>> + scom = list_entry(pos, struct scom_device, link);
>> + misc_deregister(&scom->mdev);
>> + devm_kfree(&scom->fsi_dev->dev, scom);
>> + }
>> + fsi_driver_unregister(&scom_drv);
>> +}
>> +
>> +module_init(scom_init);
>> +module_exit(scom_exit);
>> +MODULE_LICENSE("GPL");
>>
>
^ permalink raw reply
* Re: [Qemu-devel] [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration
From: Marcelo Tosatti @ 2016-11-14 17:13 UTC (permalink / raw)
To: Paolo Bonzini
Cc: kvm, qemu-devel, Dr. David Alan Gilbert, Juan Quintela,
Radim Krcmar, Eduardo Habkost
In-Reply-To: <cbcac3d2-88aa-3cb4-7257-e70061a22a2c@redhat.com>
On Mon, Nov 14, 2016 at 05:43:33PM +0100, Paolo Bonzini wrote:
>
>
> On 14/11/2016 16:40, Marcelo Tosatti wrote:
> > static bool kvmclock_src_use_reliable_get_clock(void *opaque)
> > {
> > KVMClockState *s = opaque;
> >
> > /*
> > * On machine types that support reliable KVM_GET_CLOCK,
> > * if host kernel does provide reliable KVM_GET_CLOCK,
> > * set src_use_reliable_get_clock=true so that destination
> > * avoids reading kvmclock from memory.
> > */
> > if (s->mach_use_reliable_get_clock && kvm_has_adjust_clock_stable())
> > {
> > s->src_use_reliable_get_clock = true;
> > }
> >
> > return s->mach_use_reliable_get_clock;
> > }
> >
> >
> > Ah, OK, done.
>
> s->src_use_reliable_get_clock should not be set with
> KVM_CHECK_EXTENSION, but rather from the flags returned by KVM_GET_CLOCK.
Well, thats not right: What matters is the presence of get_kvmclock_ns
which returns a value that the guest sees.
get_kernel_monotonic_clock() + kvmclock_offset +
(rdtsc() - tsc_timestamp)
IOW what the guest sees. And you changed that in
commit 108b249c453dd7132599ab6dc7e435a7036c193f
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Thu Sep 1 14:21:03 2016 +0200
KVM: x86: introduce get_kvmclock_ns
And the correct behaviour (once KVM_GET_CLOCK is fixed per
previous message to return rdtsc - tsc_timestamp for the
non masterclock case) depends on this commit above,
not on masterclock.
> > So s->src_use_reliable_get_clock is only used to indicate
> > to the destination that: "you can use KVM_GET_CLOCK value,
> > its safe".
>
> Yes, we agree. I was listing all the points, not just those where we
> disagree. Actually I'm not sure where we disagree, except on using
> flags from KVM_CHECK_EXTENSION vs. flags from KVM_GET_CLOCK...
>
> Paolo
^ permalink raw reply
* Re: [RESEND][PATCH 4/6] dt-bindings: spi: Update dspi bindings for LS2088A
From: Rob Herring @ 2016-11-14 17:13 UTC (permalink / raw)
To: Abhimanyu Saini
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, scott.wood-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Priyanka Jain,
Ashish Kumar
In-Reply-To: <1478597664-14799-5-git-send-email-abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
On Tue, Nov 08, 2016 at 03:04:22PM +0530, Abhimanyu Saini wrote:
> Signed-off-by: Priyanka Jain <priyanka.jain-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Ashish Kumar <ashish.kumar-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Abhimanyu Saini <abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
> ---
> Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RESEND][PATCH 4/6] dt-bindings: spi: Update dspi bindings for LS2088A
From: Rob Herring @ 2016-11-14 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478597664-14799-5-git-send-email-abhimanyu.saini@nxp.com>
On Tue, Nov 08, 2016 at 03:04:22PM +0530, Abhimanyu Saini wrote:
> Signed-off-by: Priyanka Jain <priyanka.jain@nxp.com>
> Signed-off-by: Ashish Kumar <ashish.kumar@nxp.com>
> Signed-off-by: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> ---
> Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration
From: Marcelo Tosatti @ 2016-11-14 17:13 UTC (permalink / raw)
To: Paolo Bonzini
Cc: kvm, qemu-devel, Dr. David Alan Gilbert, Juan Quintela,
Radim Krcmar, Eduardo Habkost
In-Reply-To: <cbcac3d2-88aa-3cb4-7257-e70061a22a2c@redhat.com>
On Mon, Nov 14, 2016 at 05:43:33PM +0100, Paolo Bonzini wrote:
>
>
> On 14/11/2016 16:40, Marcelo Tosatti wrote:
> > static bool kvmclock_src_use_reliable_get_clock(void *opaque)
> > {
> > KVMClockState *s = opaque;
> >
> > /*
> > * On machine types that support reliable KVM_GET_CLOCK,
> > * if host kernel does provide reliable KVM_GET_CLOCK,
> > * set src_use_reliable_get_clock=true so that destination
> > * avoids reading kvmclock from memory.
> > */
> > if (s->mach_use_reliable_get_clock && kvm_has_adjust_clock_stable())
> > {
> > s->src_use_reliable_get_clock = true;
> > }
> >
> > return s->mach_use_reliable_get_clock;
> > }
> >
> >
> > Ah, OK, done.
>
> s->src_use_reliable_get_clock should not be set with
> KVM_CHECK_EXTENSION, but rather from the flags returned by KVM_GET_CLOCK.
Well, thats not right: What matters is the presence of get_kvmclock_ns
which returns a value that the guest sees.
get_kernel_monotonic_clock() + kvmclock_offset +
(rdtsc() - tsc_timestamp)
IOW what the guest sees. And you changed that in
commit 108b249c453dd7132599ab6dc7e435a7036c193f
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Thu Sep 1 14:21:03 2016 +0200
KVM: x86: introduce get_kvmclock_ns
And the correct behaviour (once KVM_GET_CLOCK is fixed per
previous message to return rdtsc - tsc_timestamp for the
non masterclock case) depends on this commit above,
not on masterclock.
> > So s->src_use_reliable_get_clock is only used to indicate
> > to the destination that: "you can use KVM_GET_CLOCK value,
> > its safe".
>
> Yes, we agree. I was listing all the points, not just those where we
> disagree. Actually I'm not sure where we disagree, except on using
> flags from KVM_CHECK_EXTENSION vs. flags from KVM_GET_CLOCK...
>
> Paolo
^ permalink raw reply
* [PATCH 14/14] xfs: remove NULLEXTNUM
From: Christoph Hellwig @ 2016-11-14 17:12 UTC (permalink / raw)
To: linux-xfs
In-Reply-To: <1479143565-30615-1-git-send-email-hch@lst.de>
We only ever set a field to this constant for an impossible to reach
error case in xfs_bmap_search_extents. That functions has been removed,
so we can remove the constant as well.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
fs/xfs/libxfs/xfs_bmap.c | 2 +-
fs/xfs/libxfs/xfs_types.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c
index 856d98d..3ab68db 100644
--- a/fs/xfs/libxfs/xfs_bmap.c
+++ b/fs/xfs/libxfs/xfs_bmap.c
@@ -4260,7 +4260,7 @@ xfs_bmapi_allocate(
if (bma->wasdel) {
bma->length = (xfs_extlen_t)bma->got.br_blockcount;
bma->offset = bma->got.br_startoff;
- if (bma->idx != NULLEXTNUM && bma->idx) {
+ if (bma->idx) {
xfs_bmbt_get_all(xfs_iext_get_ext(ifp, bma->idx - 1),
&bma->prev);
}
diff --git a/fs/xfs/libxfs/xfs_types.h b/fs/xfs/libxfs/xfs_types.h
index cf044c0..717909f 100644
--- a/fs/xfs/libxfs/xfs_types.h
+++ b/fs/xfs/libxfs/xfs_types.h
@@ -57,7 +57,6 @@ typedef __int64_t xfs_sfiloff_t; /* signed block number in a file */
#define NULLAGBLOCK ((xfs_agblock_t)-1)
#define NULLAGNUMBER ((xfs_agnumber_t)-1)
-#define NULLEXTNUM ((xfs_extnum_t)-1)
#define NULLCOMMITLSN ((xfs_lsn_t)-1)
--
2.1.4
^ permalink raw reply related
* [PATCH 13/14] xfs: remove xfs_bmap_search_extents
From: Christoph Hellwig @ 2016-11-14 17:12 UTC (permalink / raw)
To: linux-xfs
In-Reply-To: <1479143565-30615-1-git-send-email-hch@lst.de>
Now that all users are gone.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
fs/xfs/libxfs/xfs_bmap.c | 91 ------------------------------------------------
fs/xfs/libxfs/xfs_bmap.h | 4 ---
2 files changed, 95 deletions(-)
diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c
index 4aa9c07..856d98d 100644
--- a/fs/xfs/libxfs/xfs_bmap.c
+++ b/fs/xfs/libxfs/xfs_bmap.c
@@ -1370,97 +1370,6 @@ xfs_bmap_read_extents(
return -EFSCORRUPTED;
}
-
-/*
- * Search the extent records for the entry containing block bno.
- * If bno lies in a hole, point to the next entry. If bno lies
- * past eof, *eofp will be set, and *prevp will contain the last
- * entry (null if none). Else, *lastxp will be set to the index
- * of the found entry; *gotp will contain the entry.
- */
-STATIC xfs_bmbt_rec_host_t * /* pointer to found extent entry */
-xfs_bmap_search_multi_extents(
- xfs_ifork_t *ifp, /* inode fork pointer */
- xfs_fileoff_t bno, /* block number searched for */
- int *eofp, /* out: end of file found */
- xfs_extnum_t *lastxp, /* out: last extent index */
- xfs_bmbt_irec_t *gotp, /* out: extent entry found */
- xfs_bmbt_irec_t *prevp) /* out: previous extent entry found */
-{
- xfs_bmbt_rec_host_t *ep; /* extent record pointer */
- xfs_extnum_t lastx; /* last extent index */
-
- /*
- * Initialize the extent entry structure to catch access to
- * uninitialized br_startblock field.
- */
- gotp->br_startoff = 0xffa5a5a5a5a5a5a5LL;
- gotp->br_blockcount = 0xa55a5a5a5a5a5a5aLL;
- gotp->br_state = XFS_EXT_INVALID;
- gotp->br_startblock = 0xffffa5a5a5a5a5a5LL;
- prevp->br_startoff = NULLFILEOFF;
-
- ep = xfs_iext_bno_to_ext(ifp, bno, &lastx);
- if (lastx > 0) {
- xfs_bmbt_get_all(xfs_iext_get_ext(ifp, lastx - 1), prevp);
- }
- if (lastx < xfs_iext_count(ifp)) {
- xfs_bmbt_get_all(ep, gotp);
- *eofp = 0;
- } else {
- if (lastx > 0) {
- *gotp = *prevp;
- }
- *eofp = 1;
- ep = NULL;
- }
- *lastxp = lastx;
- return ep;
-}
-
-/*
- * Search the extents list for the inode, for the extent containing bno.
- * If bno lies in a hole, point to the next entry. If bno lies past eof,
- * *eofp will be set, and *prevp will contain the last entry (null if none).
- * Else, *lastxp will be set to the index of the found
- * entry; *gotp will contain the entry.
- */
-xfs_bmbt_rec_host_t * /* pointer to found extent entry */
-xfs_bmap_search_extents(
- xfs_inode_t *ip, /* incore inode pointer */
- xfs_fileoff_t bno, /* block number searched for */
- int fork, /* data or attr fork */
- int *eofp, /* out: end of file found */
- xfs_extnum_t *lastxp, /* out: last extent index */
- xfs_bmbt_irec_t *gotp, /* out: extent entry found */
- xfs_bmbt_irec_t *prevp) /* out: previous extent entry found */
-{
- xfs_ifork_t *ifp; /* inode fork pointer */
- xfs_bmbt_rec_host_t *ep; /* extent record pointer */
-
- XFS_STATS_INC(ip->i_mount, xs_look_exlist);
- ifp = XFS_IFORK_PTR(ip, fork);
-
- ep = xfs_bmap_search_multi_extents(ifp, bno, eofp, lastxp, gotp, prevp);
-
- if (unlikely(!(gotp->br_startblock) && (*lastxp != NULLEXTNUM) &&
- !(XFS_IS_REALTIME_INODE(ip) && fork == XFS_DATA_FORK))) {
- xfs_alert_tag(ip->i_mount, XFS_PTAG_FSBLOCK_ZERO,
- "Access to block zero in inode %llu "
- "start_block: %llx start_off: %llx "
- "blkcnt: %llx extent-state: %x lastx: %x",
- (unsigned long long)ip->i_ino,
- (unsigned long long)gotp->br_startblock,
- (unsigned long long)gotp->br_startoff,
- (unsigned long long)gotp->br_blockcount,
- gotp->br_state, *lastxp);
- *lastxp = NULLEXTNUM;
- *eofp = 1;
- return NULL;
- }
- return ep;
-}
-
/*
* Returns the file-relative block number of the first unused block(s)
* in the file with at least "len" logically contiguous blocks free.
diff --git a/fs/xfs/libxfs/xfs_bmap.h b/fs/xfs/libxfs/xfs_bmap.h
index e3c2b5a..ffed1f9 100644
--- a/fs/xfs/libxfs/xfs_bmap.h
+++ b/fs/xfs/libxfs/xfs_bmap.h
@@ -237,10 +237,6 @@ int xfs_bmap_shift_extents(struct xfs_trans *tp, struct xfs_inode *ip,
struct xfs_defer_ops *dfops, enum shift_direction direction,
int num_exts);
int xfs_bmap_split_extent(struct xfs_inode *ip, xfs_fileoff_t split_offset);
-struct xfs_bmbt_rec_host *
- xfs_bmap_search_extents(struct xfs_inode *ip, xfs_fileoff_t bno,
- int fork, int *eofp, xfs_extnum_t *lastxp,
- struct xfs_bmbt_irec *gotp, struct xfs_bmbt_irec *prevp);
int xfs_bmapi_reserve_delalloc(struct xfs_inode *ip, int whichfork,
xfs_fileoff_t aoff, xfs_filblks_t len,
struct xfs_bmbt_irec *got, xfs_extnum_t *lastx, int eof);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v2] i2c: mux: fix up dependencies
From: Jonathan Cameron @ 2016-11-14 17:13 UTC (permalink / raw)
To: Peter Rosin, Linus Walleij, Wolfram Sang, linux-i2c; +Cc: stable
In-Reply-To: <6094de61-8745-fbff-e516-db95392aa142@axentia.se>
On 14 November 2016 14:39:54 GMT+00:00, Peter Rosin <peda@axentia.se> wrote:
>On 2016-11-14 15:34, Linus Walleij wrote:
>> We get the following build error from UM Linux after adding
>> an entry to drivers/iio/gyro/Kconfig that issues "select I2C_MUX":
>>
>> ERROR: "devm_ioremap_resource"
>> [drivers/i2c/muxes/i2c-mux-reg.ko] undefined!
>> ERROR: "of_address_to_resource"
>> [drivers/i2c/muxes/i2c-mux-reg.ko] undefined!
>>
>> It appears that the I2C mux core code depends on HAS_IOMEM
>> for historical reasons, while CONFIG_I2C_MUX_REG does *not*
>> have a direct dependency on HAS_IOMEM.
>>
>> This creates a situation where a allyesconfig or allmodconfig
>> for UM Linux will select I2C_MUX, and will implicitly enable
>> I2C_MUX_REG as well, and the compilation will fail for the
>> register driver.
>>
>> Fix this up by making I2C_MUX_REG depend on HAS_IOMEM and
>> removing the dependency from I2C_MUX.
>>
>> Cc: stable@vger.kernel.org
>> Reported-by: kbuild test robot <fengguang.wu@intel.com>
>> Reported-by: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
>> Cc: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
>> Cc: Peter Rosin <peda@axentia.se>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>
>Acked-by: Peter Rosin <peda@axentia.se>
>
>Thanks!
Thanks for sorting this.
Acked-by: Jonathan Cameron <jic23@kernel.org>
>
>Cheers,
>Peter
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* [PATCH 12/14] xfs: use new extent lookup helpers in xfs_reflink_end_cow
From: Christoph Hellwig @ 2016-11-14 17:12 UTC (permalink / raw)
To: linux-xfs
In-Reply-To: <1479143565-30615-1-git-send-email-hch@lst.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
fs/xfs/xfs_reflink.c | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c
index a878d42..4b024e7 100644
--- a/fs/xfs/xfs_reflink.c
+++ b/fs/xfs/xfs_reflink.c
@@ -615,13 +615,13 @@ xfs_reflink_end_cow(
xfs_off_t count)
{
struct xfs_ifork *ifp = XFS_IFORK_PTR(ip, XFS_COW_FORK);
- struct xfs_bmbt_irec got, prev, del;
+ struct xfs_bmbt_irec got, del;
struct xfs_trans *tp;
xfs_fileoff_t offset_fsb;
xfs_fileoff_t end_fsb;
xfs_fsblock_t firstfsb;
struct xfs_defer_ops dfops;
- int error, eof = 0;
+ int error;
unsigned int resblks;
xfs_filblks_t rlen;
xfs_extnum_t idx;
@@ -645,13 +645,11 @@ xfs_reflink_end_cow(
xfs_ilock(ip, XFS_ILOCK_EXCL);
xfs_trans_ijoin(tp, ip, 0);
- xfs_bmap_search_extents(ip, end_fsb - 1, XFS_COW_FORK, &eof, &idx,
- &got, &prev);
-
/* If there is a hole at end_fsb - 1 go to the previous extent */
- if (eof || got.br_startoff > end_fsb) {
+ if (!xfs_iext_lookup_extent(ip, ifp, end_fsb - 1, &idx, &got) ||
+ got.br_startoff > end_fsb) {
ASSERT(idx > 0);
- xfs_bmbt_get_all(xfs_iext_get_ext(ifp, --idx), &got);
+ xfs_iext_get_extent(ifp, --idx, &got);
}
/* Walk backwards until we're out of the I/O range... */
@@ -699,11 +697,9 @@ xfs_reflink_end_cow(
error = xfs_defer_finish(&tp, &dfops, ip);
if (error)
goto out_defer;
-
next_extent:
- if (idx < 0)
+ if (!xfs_iext_get_extent(ifp, idx, &got))
break;
- xfs_bmbt_get_all(xfs_iext_get_ext(ifp, idx), &got);
}
error = xfs_trans_commit(tp);
--
2.1.4
^ permalink raw reply related
* [PATCH 11/14] xfs: use new extent lookup helpers in xfs_reflink_cancel_cow_blocks
From: Christoph Hellwig @ 2016-11-14 17:12 UTC (permalink / raw)
To: linux-xfs
In-Reply-To: <1479143565-30615-1-git-send-email-hch@lst.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
fs/xfs/xfs_reflink.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c
index 0668490..a878d42 100644
--- a/fs/xfs/xfs_reflink.c
+++ b/fs/xfs/xfs_reflink.c
@@ -493,18 +493,15 @@ xfs_reflink_cancel_cow_blocks(
xfs_fileoff_t end_fsb)
{
struct xfs_ifork *ifp = XFS_IFORK_PTR(ip, XFS_COW_FORK);
- struct xfs_bmbt_irec got, prev, del;
+ struct xfs_bmbt_irec got, del;
xfs_extnum_t idx;
xfs_fsblock_t firstfsb;
struct xfs_defer_ops dfops;
- int error = 0, eof = 0;
+ int error = 0;
if (!xfs_is_reflink_inode(ip))
return 0;
-
- xfs_bmap_search_extents(ip, offset_fsb, XFS_COW_FORK, &eof, &idx,
- &got, &prev);
- if (eof)
+ if (!xfs_iext_lookup_extent(ip, ifp, offset_fsb, &idx, &got))
return 0;
while (got.br_startoff < end_fsb) {
@@ -547,9 +544,8 @@ xfs_reflink_cancel_cow_blocks(
xfs_bmap_del_extent_cow(ip, &idx, &got, &del);
}
- if (++idx >= xfs_iext_count(ifp))
+ if (!xfs_iext_get_extent(ifp, ++idx, &got))
break;
- xfs_bmbt_get_all(xfs_iext_get_ext(ifp, idx), &got);
}
/* clear tag if cow fork is emptied */
--
2.1.4
^ permalink raw reply related
* [PATCH 10/14] xfs: use new extent lookup helpers in xfs_reflink_trim_irec_to_next_cow
From: Christoph Hellwig @ 2016-11-14 17:12 UTC (permalink / raw)
To: linux-xfs
In-Reply-To: <1479143565-30615-1-git-send-email-hch@lst.de>
And remove the unused return value.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
fs/xfs/xfs_reflink.c | 33 ++++++++++++---------------------
fs/xfs/xfs_reflink.h | 2 +-
2 files changed, 13 insertions(+), 22 deletions(-)
diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c
index 6056fd1..0668490 100644
--- a/fs/xfs/xfs_reflink.c
+++ b/fs/xfs/xfs_reflink.c
@@ -452,43 +452,34 @@ xfs_reflink_find_cow_mapping(
/*
* Trim an extent to end at the next CoW reservation past offset_fsb.
*/
-int
+void
xfs_reflink_trim_irec_to_next_cow(
struct xfs_inode *ip,
xfs_fileoff_t offset_fsb,
struct xfs_bmbt_irec *imap)
{
- struct xfs_bmbt_irec irec;
- struct xfs_ifork *ifp;
- struct xfs_bmbt_rec_host *gotp;
+ struct xfs_ifork *ifp = XFS_IFORK_PTR(ip, XFS_COW_FORK);
+ struct xfs_bmbt_irec got;
xfs_extnum_t idx;
if (!xfs_is_reflink_inode(ip))
- return 0;
+ return;
/* Find the extent in the CoW fork. */
- ifp = XFS_IFORK_PTR(ip, XFS_COW_FORK);
- gotp = xfs_iext_bno_to_ext(ifp, offset_fsb, &idx);
- if (!gotp)
- return 0;
- xfs_bmbt_get_all(gotp, &irec);
+ if (!xfs_iext_lookup_extent(ip, ifp, offset_fsb, &idx, &got))
+ return;
/* This is the extent before; try sliding up one. */
- if (irec.br_startoff < offset_fsb) {
- idx++;
- if (idx >= xfs_iext_count(ifp))
- return 0;
- gotp = xfs_iext_get_ext(ifp, idx);
- xfs_bmbt_get_all(gotp, &irec);
+ if (got.br_startoff < offset_fsb) {
+ if (!xfs_iext_get_extent(ifp, idx + 1, &got))
+ return;
}
- if (irec.br_startoff >= imap->br_startoff + imap->br_blockcount)
- return 0;
+ if (got.br_startoff >= imap->br_startoff + imap->br_blockcount)
+ return;
- imap->br_blockcount = irec.br_startoff - imap->br_startoff;
+ imap->br_blockcount = got.br_startoff - imap->br_startoff;
trace_xfs_reflink_trim_irec(ip, imap);
-
- return 0;
}
/*
diff --git a/fs/xfs/xfs_reflink.h b/fs/xfs/xfs_reflink.h
index cff5fc3..aa6a4d6 100644
--- a/fs/xfs/xfs_reflink.h
+++ b/fs/xfs/xfs_reflink.h
@@ -32,7 +32,7 @@ extern int xfs_reflink_allocate_cow_range(struct xfs_inode *ip,
xfs_off_t offset, xfs_off_t count);
extern bool xfs_reflink_find_cow_mapping(struct xfs_inode *ip, xfs_off_t offset,
struct xfs_bmbt_irec *imap);
-extern int xfs_reflink_trim_irec_to_next_cow(struct xfs_inode *ip,
+extern void xfs_reflink_trim_irec_to_next_cow(struct xfs_inode *ip,
xfs_fileoff_t offset_fsb, struct xfs_bmbt_irec *imap);
extern int xfs_reflink_cancel_cow_blocks(struct xfs_inode *ip,
--
2.1.4
^ permalink raw reply related
* Re: [RESEND][PATCH 3/6] dt-bindings: mtd: fsl-quadspi: Update qspi bindings for LS2088A
From: Rob Herring @ 2016-11-14 17:13 UTC (permalink / raw)
To: Abhimanyu Saini
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, mark.rutland-5wv7dgnIgG8,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, scott.wood-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Priyanka Jain,
Ashish Kumar
In-Reply-To: <1478597664-14799-4-git-send-email-abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
On Tue, Nov 08, 2016 at 03:04:21PM +0530, Abhimanyu Saini wrote:
> Signed-off-by: Priyanka Jain <priyanka.jain-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Ashish Kumar <ashish.kumar-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Abhimanyu Saini <abhimanyu.saini-3arQi8VN3Tc@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.