* [PATCH v2 1/6] mm: hugetlb: rename some allocation functions
From: Vlastimil Babka @ 2016-11-28 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479107259-2011-2-git-send-email-shijie.huang@arm.com>
On 11/14/2016 08:07 AM, Huang Shijie wrote:
> After a future patch, the __alloc_buddy_huge_page() will not necessarily
> use the buddy allocator.
>
> So this patch removes the "buddy" from these functions:
> __alloc_buddy_huge_page -> __alloc_huge_page
> __alloc_buddy_huge_page_no_mpol -> __alloc_huge_page_no_mpol
> __alloc_buddy_huge_page_with_mpol -> __alloc_huge_page_with_mpol
>
> This patch makes preparation for the later patch.
>
> Signed-off-by: Huang Shijie <shijie.huang@arm.com>
> ---
> mm/hugetlb.c | 24 ++++++++++++++----------
> 1 file changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 3edb759..496b703 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1157,6 +1157,10 @@ static int alloc_fresh_gigantic_page(struct hstate *h,
>
> static inline bool gigantic_page_supported(void) { return true; }
> #else
> +static inline struct page *alloc_gigantic_page(int nid, unsigned int order)
> +{
> + return NULL;
> +}
This hunk is not explained by the description. Could belong to a later
patch?
^ permalink raw reply
* Adding a .platform_init callback to sdhci_arasan_ops
From: Sebastian Frias @ 2016-11-28 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d1801c1e-cd74-b79c-0280-8fb5dc377c91@intel.com>
On 28/11/16 12:44, Adrian Hunter wrote:
> On 28/11/16 13:20, Sebastian Frias wrote:
>> Hi Adrian,
>>
>> On 28/11/16 11:30, Adrian Hunter wrote:
>>> On 28/11/16 09:32, Michal Simek wrote:
>>>> +Sai for Xilinx perspective.
>>>>
>>>> On 25.11.2016 16:24, Sebastian Frias wrote:
>>>>> Hi,
>>>>>
>>>>> When using the Arasan SDHCI HW IP, there is a set of parameters called
>>>>> "Hardware initialized registers"
>>>>>
>>>>> (Table 7, Section "Pin Signals", page 56 of Arasan "SD3.0/SDIO3.0/eMMC4.4
>>>>> AHB Host Controller", revision 6.0 document)
>>>>>
>>>>> In some platforms those signals are connected to registers that need to
>>>>> be programmed at some point for proper driver/HW initialisation.
>>>>>
>>>>> I found that the 'struct sdhci_ops' contains a '.platform_init' callback
>>>>> that is called from within 'sdhci_pltfm_init', and that seems a good
>>>>> candidate for a place to program those registers (*).
>>>>>
>>>>> Do you agree?
>>>
>>> We already killed .platform_init
>>
>> I just saw that, yet it was the perfect place for the HW initialisation I'm
>> talking about.
>> Any way we can restore it?
>
> It doesn't serve any purpose I am aware of.
It would serve (for me) if it was there :-)
>
>>
>>>
>>> What is wrong with sdhci_arasan_probe()?
>>
>> Well, in 4.7 sdhci_arasan_probe() did not call of_match_device(), so I had
>> put a call to it just before sdhci_pltfm_init(), something like:
>>
>> +static const struct of_device_id sdhci_arasan_of_match[] = {
>> + {
>> + .compatible = "arasan,sdhci-8.9a",
>> + .data = &sdhci_arasan_ops,
>> + },
>> + {
>> + .compatible = "arasan,sdhci-5.1",
>> + .data = &sdhci_arasan_ops,
>> + },
>> + {
>> + .compatible = "arasan,sdhci-4.9a",
>> + .data = &sdhci_arasan_ops,
>> + },
>> + {
>> + .compatible = "sigma,smp8734-sdio",
>> + .data = &sdhci_arasan_tango4_ops,
>> + },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(of, sdhci_arasan_of_match);
>>
>> ...
>>
>> + const struct of_device_id *match;
>> +
>> + match = of_match_device(sdhci_arasan_of_match, &pdev->dev);
>> + if (match)
>> + sdhci_arasan_pdata.ops = match->data;
>>
>> where 'sdhci_arasan_tango4_ops' contained a pointer to a .platform_init
>> callback.
>>
>> However, as I stated earlier, an upstream commit:
>>
>> commit 3ea4666e8d429223fbb39c1dccee7599ef7657d5
>> Author: Douglas Anderson <dianders@chromium.org>
>> Date: Mon Jun 20 10:56:47 2016 -0700
>>
>> mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399
>>
>> changed struct 'sdhci_arasan_of_match' to convey different data, which
>> means that instead of having a generic way of accessing such data (such
>> as 'of_match_device()' and ".data" field), one must also check for
>> specific "compatible" strings to make sense of the ".data" field, such as
>> "rockchip,rk3399-sdhci-5.1"
>>
>> With the current code:
>> - there's no 'of_match_device()' before 'sdhci_pltfm_init()'
>> - the sdhci_pltfm_init() call is made with a static 'sdhci_arasan_pdata'
>> struct (so it cannot be made dependent on the "compatible" string).
>> - since 'sdhci_arasan_pdata' is the same for all compatible devices, even
>> for those that require special handling, more "compatible" matching code is
>> required
>> - leading to spread "compatible" matching code; IMHO it would be cleaner if
>> the 'sdhci_arasan_probe()' code was generic, with just a generic "compatible"
>> matching, which then proceeded with specific initialisation and generic
>> initialisation.
>>
>> In a nutshell, IMHO it would be better if adding support for more SoCs only
>> involved changing just 'sdhci_arasan_of_match' without the need to change
>> 'sdhci_arasan_probe()'.
>> That would clearly separate the generic and "SoC"-specific code, thus allowing
>> better maintenance.
>>
>> Does that makes sense to you guys?
>
> If you want to do that, then why not define your match data with your own
> callbacks. e.g. something like
>
> struct sdhci_arasan_of_data {
> struct sdhci_arasan_soc_ctl_map *soc_ctl_map;
> void (*platform_init)(struct sdhci_arasan_data *sdhci_arasan);
> };
>
> struct sdhci_arasan_of_data *data;
>
> data = match->data;
> sdhci_arasan->soc_ctl_map = data->soc_ctl_map;
> if (data->platform_init)
> platform_init(sdhci_arasan);
Well, that adds a level in the hierarchy, but here is what it would look like:
diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
index 410a55b..1cb3861 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -382,22 +382,6 @@ static int sdhci_arasan_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(sdhci_arasan_dev_pm_ops, sdhci_arasan_suspend,
sdhci_arasan_resume);
-static const struct of_device_id sdhci_arasan_of_match[] = {
- /* SoC-specific compatible strings w/ soc_ctl_map */
- {
- .compatible = "rockchip,rk3399-sdhci-5.1",
- .data = &rk3399_soc_ctl_map,
- },
-
- /* Generic compatible below here */
- { .compatible = "arasan,sdhci-8.9a" },
- { .compatible = "arasan,sdhci-5.1" },
- { .compatible = "arasan,sdhci-4.9a" },
-
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, sdhci_arasan_of_match);
-
/**
* sdhci_arasan_sdcardclk_recalc_rate - Return the card clock rate
*
@@ -578,6 +562,53 @@ static void sdhci_arasan_unregister_sdclk(struct device *dev)
of_clk_del_provider(dev->of_node);
}
+static void sdhci_tango4_platform_init(struct sdhci_host *host)
+{
+ printk("%s\n", __func__);
+
+ /*
+ pad_mode[2:0]=0 must be 0
+ sel_sdio[3]=1 must be 1 for SDIO
+ inv_sdwp_pol[4]=0 if set inverts the SD write protect polarity
+ inv_sdcd_pol[5]=0 if set inverts the SD card present polarity
+ */
+ sdhci_writel(host, 0x00000008, 0x100 + 0x0);
+}
+
+struct sdhci_arasan_chip_specific_data {
+ const struct sdhci_arasan_soc_ctl_map *soc_ctl_map;
+ void (*platform_init)(struct sdhci_host *host);
+};
+
+static const struct sdhci_arasan_chip_specific_data sdhci_arasan_rockchip = {
+ .soc_ctl_map = &rk3399_soc_ctl_map,
+};
+
+static const struct sdhci_arasan_chip_specific_data sdhci_arasan_sigma = {
+ .platform_init = sdhci_tango4_platform_init,
+};
+
+static const struct of_device_id sdhci_arasan_of_match[] = {
+ /* SoC-specific compatible strings w/ soc_ctl_map */
+ {
+ .compatible = "rockchip,rk3399-sdhci-5.1",
+ .data = &sdhci_arasan_rockchip,
+ },
+ {
+ .compatible = "sigma,sdio-v1",
+ .data = &sdhci_arasan_sigma,
+ },
+
+ /* Generic compatible below here */
+ { .compatible = "arasan,sdhci-8.9a" },
+ { .compatible = "arasan,sdhci-5.1" },
+ { .compatible = "arasan,sdhci-4.9a" },
+
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, sdhci_arasan_of_match);
+
+
static int sdhci_arasan_probe(struct platform_device *pdev)
{
int ret;
@@ -587,6 +618,7 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
struct sdhci_host *host;
struct sdhci_pltfm_host *pltfm_host;
struct sdhci_arasan_data *sdhci_arasan;
+ struct sdhci_arasan_chip_specific_data *sdhci_arasan_chip_specific;
struct device_node *np = pdev->dev.of_node;
host = sdhci_pltfm_init(pdev, &sdhci_arasan_pdata,
@@ -599,7 +631,11 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
sdhci_arasan->host = host;
match = of_match_node(sdhci_arasan_of_match, pdev->dev.of_node);
- sdhci_arasan->soc_ctl_map = match->data;
+ sdhci_arasan_chip_specific = (struct sdhci_arasan_chip_specific_data *)match;
+ if (sdhci_arasan_chip_specific->soc_ctl_map)
+ sdhci_arasan->soc_ctl_map = sdhci_arasan_chip_specific->soc_ctl_map;
+ if (sdhci_arasan_chip_specific->platform_init)
+ sdhci_arasan_chip_specific->platform_init(host);
node = of_parse_phandle(pdev->dev.of_node, "arasan,soc-ctl-syscon", 0);
if (node) {
I will try to send another patch with what a different approach
^ permalink raw reply related
* [PATCH 4/4] crypto: arm/crct10dif - port x86 SSE implementation to ARM
From: Herbert Xu @ 2016-11-28 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8tPfX76ntdQmMz53waE73RHfB11oRs8w=Ufy7d=YqbGA@mail.gmail.com>
On Thu, Nov 24, 2016 at 05:32:42PM +0000, Ard Biesheuvel wrote:
> On 24 November 2016 at 15:43, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > This is a straight transliteration of the Intel algorithm implemented
> > using SSE and PCLMULQDQ instructions that resides under in the file
> > arch/x86/crypto/crct10dif-pcl-asm_64.S.
> >
> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > ---
> > arch/arm/crypto/Kconfig | 5 +
> > arch/arm/crypto/Makefile | 2 +
> > arch/{arm64 => arm}/crypto/crct10dif-ce-core.S | 457 +++++++++++---------
> > arch/{arm64 => arm}/crypto/crct10dif-ce-glue.c | 23 +-
> > 4 files changed, 277 insertions(+), 210 deletions(-)
> >
>
> This patch needs the following hunk folded in to avoid breaking the
> Thumb2 build:
>
> """
> diff --git a/arch/arm/crypto/crct10dif-ce-core.S
> b/arch/arm/crypto/crct10dif-ce-core.S
> index 30168b0f8581..4fdbca94dd0c 100644
> --- a/arch/arm/crypto/crct10dif-ce-core.S
> +++ b/arch/arm/crypto/crct10dif-ce-core.S
> @@ -152,7 +152,8 @@ CPU_LE( vrev64.8 q7, q7 )
> // XOR the initial_crc value
> veor.8 q0, q0, q10
>
> - adrl ip, rk3
> +ARM( adrl ip, rk3 )
> +THUMB( adr ip, rk3 )
> vld1.64 {q10}, [ip] // xmm10 has rk3 and rk4
> // type of pmull instruction
> // will determine which constant to use
> """
I'm sorry but this patch doesn't apply on top of the other four.
So please resend the whole series.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 2/2] net: dsa: mv88e6xxx: Add 88E6176 device tree support
From: Andrew Lunn @ 2016-11-28 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128080939.ippqlytvojitefkp@perseus.defre.kleine-koenig.org>
> I still wonder (and didn't get an answer back when I asked about this)
> why a comment is preferred here. For other devices I know it's usual and
> requested by the maintainers to use:
>
> compatible = "exact name", "earlyer device to match driver";
>
> . This is more robust, documents the situation more formally and makes
> it better greppable. The price to pay is only a few bytes in the dtb
> which IMO is ok.
We did discuss this a while back. The information is useless and
should to be ignored if present.
The switch has a register which contains its model and revision. Each
port has a set of registers, and register 3 contains the
model/version. For all devices compatible with the 6085, the port
registers start at address 0x10. For the 6190, the port registers
start at 0x0. So given one of these two compatible strings, we can
find the model of the device, from something which is burned into the
silicon.
Now, say we did add per device compatible strings. We look up the
model burned into the silicon, find it is different to what the device
tree is and do what? Fail the probe? Or just keep going using the
value in the silicon? It seems silly to fail the probe if the driver
does support the model, but that means the device tree is never
verified and hence probably wrong. Why have wrong information in the
device tree, especially wrong information which we never use. It is
better to not have that information in the device tree.
Linus has said he does not like ARM devices because of all the busses
which are not enumerable. Here we have a device which with a little
bit of help we can enumerate. So we should.
Andrew
^ permalink raw reply
* [PATCH v4] crypto: arm64/sha2: integrate OpenSSL implementations of SHA256/SHA512
From: Ard Biesheuvel @ 2016-11-28 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128120503.GC1485@arm.com>
On 28 November 2016 at 13:05, Will Deacon <will.deacon@arm.com> wrote:
> On Sun, Nov 20, 2016 at 11:42:01AM +0000, Ard Biesheuvel wrote:
>> This integrates both the accelerated scalar and the NEON implementations
>> of SHA-224/256 as well as SHA-384/512 from the OpenSSL project.
>>
>> Relative performance compared to the respective generic C versions:
>>
>> | SHA256-scalar | SHA256-NEON* | SHA512 |
>> ------------+-----------------+--------------+----------+
>> Cortex-A53 | 1.63x | 1.63x | 2.34x |
>> Cortex-A57 | 1.43x | 1.59x | 1.95x |
>> Cortex-A73 | 1.26x | 1.56x | ? |
>>
>> The core crypto code was authored by Andy Polyakov of the OpenSSL
>> project, in collaboration with whom the upstream code was adapted so
>> that this module can be built from the same version of sha512-armv8.pl.
>>
>> The version in this patch was taken from OpenSSL commit 32bbb62ea634
>> ("sha/asm/sha512-armv8.pl: fix big-endian support in __KERNEL__ case.")
>>
>> * The core SHA algorithm is fundamentally sequential, but there is a
>> secondary transformation involved, called the schedule update, which
>> can be performed independently. The NEON version of SHA-224/SHA-256
>> only implements this part of the algorithm using NEON instructions,
>> the sequential part is always done using scalar instructions.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>> arch/arm64/crypto/Kconfig | 8 +
>> arch/arm64/crypto/Makefile | 17 +
>> arch/arm64/crypto/sha256-core.S_shipped | 2061 ++++++++++++++++++++
>> arch/arm64/crypto/sha256-glue.c | 185 ++
>> arch/arm64/crypto/sha512-armv8.pl | 778 ++++++++
>> arch/arm64/crypto/sha512-core.S_shipped | 1085 +++++++++++
>> arch/arm64/crypto/sha512-glue.c | 94 +
>> 7 files changed, 4228 insertions(+)
>
> If I build a kernel with this applied and CRYPTO_SHA{256,512}_ARM64=y,
> then I end up with untracked .S files according to git:
>
> $ git status
> Untracked files:
> arch/arm64/crypto/sha256-core.S
> arch/arm64/crypto/sha512-core.S
>
Ah right, I forgot to add a .gitignore for these: that is required
with .S_shipped files. I didn't spot this myself because I always
build out of tree
Would you mind taking a separate patch for that?
^ permalink raw reply
* [PATCH v9 02/11] arm/arm64: vgic: Add distributor and redistributor access
From: Christoffer Dall @ 2016-11-28 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479906118-15832-3-git-send-email-vijay.kilari@gmail.com>
On Wed, Nov 23, 2016 at 06:31:49PM +0530, vijay.kilari at gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>
> VGICv3 Distributor and Redistributor registers are accessed using
> KVM_DEV_ARM_VGIC_GRP_DIST_REGS and KVM_DEV_ARM_VGIC_GRP_REDIST_REGS
> with KVM_SET_DEVICE_ATTR and KVM_GET_DEVICE_ATTR ioctls.
> These registers are accessed as 32-bit and cpu mpidr
> value passed along with register offset is used to identify the
> cpu for redistributor registers access.
>
> The version of VGIC v3 specification is define here
> Documentation/virtual/kvm/devices/arm-vgic-v3.txt
>
> Also update arch/arm/include/uapi/asm/kvm.h to compile for
> AArch32 mode.
>
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> ---
> arch/arm/include/uapi/asm/kvm.h | 4 +
> arch/arm64/include/uapi/asm/kvm.h | 4 +
> virt/kvm/arm/vgic/vgic-kvm-device.c | 144 ++++++++++++++++++++++++++++++++++--
> virt/kvm/arm/vgic/vgic-mmio-v2.c | 16 +---
> virt/kvm/arm/vgic/vgic-mmio-v3.c | 72 ++++++++++++++++++
> virt/kvm/arm/vgic/vgic-mmio.c | 22 ++++++
> virt/kvm/arm/vgic/vgic-mmio.h | 4 +
> virt/kvm/arm/vgic/vgic.h | 49 +++++++++++-
> 8 files changed, 292 insertions(+), 23 deletions(-)
>
> diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
> index af05f8e..0ae6035 100644
> --- a/arch/arm/include/uapi/asm/kvm.h
> +++ b/arch/arm/include/uapi/asm/kvm.h
> @@ -181,10 +181,14 @@ struct kvm_arch_memory_slot {
> #define KVM_DEV_ARM_VGIC_GRP_CPU_REGS 2
> #define KVM_DEV_ARM_VGIC_CPUID_SHIFT 32
> #define KVM_DEV_ARM_VGIC_CPUID_MASK (0xffULL << KVM_DEV_ARM_VGIC_CPUID_SHIFT)
> +#define KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT 32
> +#define KVM_DEV_ARM_VGIC_V3_MPIDR_MASK \
> + (0xffffffffULL << KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT)
> #define KVM_DEV_ARM_VGIC_OFFSET_SHIFT 0
> #define KVM_DEV_ARM_VGIC_OFFSET_MASK (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
> #define KVM_DEV_ARM_VGIC_GRP_NR_IRQS 3
> #define KVM_DEV_ARM_VGIC_GRP_CTRL 4
> +#define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
> #define KVM_DEV_ARM_VGIC_CTRL_INIT 0
>
> /* KVM_IRQ_LINE irq field index values */
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index 3051f86..56dc08d 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -201,10 +201,14 @@ struct kvm_arch_memory_slot {
> #define KVM_DEV_ARM_VGIC_GRP_CPU_REGS 2
> #define KVM_DEV_ARM_VGIC_CPUID_SHIFT 32
> #define KVM_DEV_ARM_VGIC_CPUID_MASK (0xffULL << KVM_DEV_ARM_VGIC_CPUID_SHIFT)
> +#define KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT 32
> +#define KVM_DEV_ARM_VGIC_V3_MPIDR_MASK \
> + (0xffffffffULL << KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT)
> #define KVM_DEV_ARM_VGIC_OFFSET_SHIFT 0
> #define KVM_DEV_ARM_VGIC_OFFSET_MASK (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
> #define KVM_DEV_ARM_VGIC_GRP_NR_IRQS 3
> #define KVM_DEV_ARM_VGIC_GRP_CTRL 4
> +#define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
> #define KVM_DEV_ARM_VGIC_CTRL_INIT 0
>
> /* Device Control API on vcpu fd */
> diff --git a/virt/kvm/arm/vgic/vgic-kvm-device.c b/virt/kvm/arm/vgic/vgic-kvm-device.c
> index fbe87a6..bc7de95 100644
> --- a/virt/kvm/arm/vgic/vgic-kvm-device.c
> +++ b/virt/kvm/arm/vgic/vgic-kvm-device.c
> @@ -235,7 +235,7 @@ struct vgic_reg_attr {
> gpa_t addr;
> };
>
> -static int parse_vgic_v2_attr(struct kvm_device *dev,
> +static int vgic_v2_parse_attr(struct kvm_device *dev,
> struct kvm_device_attr *attr,
> struct vgic_reg_attr *reg_attr)
> {
> @@ -292,14 +292,14 @@ static bool lock_all_vcpus(struct kvm *kvm)
> }
>
> /**
> - * vgic_attr_regs_access_v2 - allows user space to access VGIC v2 state
> + * vgic_v2_attr_regs_access - allows user space to access VGIC v2 state
> *
> * @dev: kvm device handle
> * @attr: kvm device attribute
> * @reg: address the value is read or written
> * @is_write: true if userspace is writing a register
> */
> -static int vgic_attr_regs_access_v2(struct kvm_device *dev,
> +static int vgic_v2_attr_regs_access(struct kvm_device *dev,
> struct kvm_device_attr *attr,
> u32 *reg, bool is_write)
> {
> @@ -308,7 +308,7 @@ static int vgic_attr_regs_access_v2(struct kvm_device *dev,
> struct kvm_vcpu *vcpu;
> int ret;
>
> - ret = parse_vgic_v2_attr(dev, attr, ®_attr);
> + ret = vgic_v2_parse_attr(dev, attr, ®_attr);
> if (ret)
> return ret;
>
> @@ -362,7 +362,7 @@ static int vgic_v2_set_attr(struct kvm_device *dev,
> if (get_user(reg, uaddr))
> return -EFAULT;
>
> - return vgic_attr_regs_access_v2(dev, attr, ®, true);
> + return vgic_v2_attr_regs_access(dev, attr, ®, true);
> }
> }
>
> @@ -384,7 +384,7 @@ static int vgic_v2_get_attr(struct kvm_device *dev,
> u32 __user *uaddr = (u32 __user *)(long)attr->addr;
> u32 reg = 0;
>
> - ret = vgic_attr_regs_access_v2(dev, attr, ®, false);
> + ret = vgic_v2_attr_regs_access(dev, attr, ®, false);
> if (ret)
> return ret;
> return put_user(reg, uaddr);
> @@ -428,16 +428,141 @@ struct kvm_device_ops kvm_arm_vgic_v2_ops = {
> .has_attr = vgic_v2_has_attr,
> };
>
> +static int vgic_v3_parse_attr(struct kvm_device *dev,
> + struct kvm_device_attr *attr,
> + struct vgic_reg_attr *reg_attr)
> +{
> + unsigned long vgic_mpidr, mpidr_reg;
> +
> + vgic_mpidr = (attr->attr & KVM_DEV_ARM_VGIC_V3_MPIDR_MASK) >>
> + KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT;
> +
> + mpidr_reg = VGIC_TO_MPIDR(vgic_mpidr);
> + reg_attr->vcpu = kvm_mpidr_to_vcpu(dev->kvm, mpidr_reg);
> + if (!reg_attr->vcpu)
> + return -EINVAL;
> +
> + reg_attr->addr = attr->attr & KVM_DEV_ARM_VGIC_OFFSET_MASK;
> +
> + return 0;
> +}
> +
> +/*
> + * vgic_v3_attr_regs_access - allows user space to access VGIC v3 state
> + *
> + * @dev: kvm device handle
> + * @attr: kvm device attribute
> + * @reg: address the value is read or written
> + * @is_write: true if userspace is writing a register
> + */
> +static int vgic_v3_attr_regs_access(struct kvm_device *dev,
> + struct kvm_device_attr *attr,
> + u64 *reg, bool is_write)
> +{
> + struct vgic_reg_attr reg_attr;
> + gpa_t addr;
> + struct kvm_vcpu *vcpu;
> + int ret;
> + u32 tmp32;
> +
> + ret = vgic_v3_parse_attr(dev, attr, ®_attr);
> + if (ret)
> + return ret;
> +
> + vcpu = reg_attr.vcpu;
> + addr = reg_attr.addr;
> +
> + mutex_lock(&dev->kvm->lock);
> +
> + if (unlikely(!vgic_initialized(dev->kvm))) {
> + ret = -EBUSY;
> + goto out;
> + }
> +
> + if (!lock_all_vcpus(dev->kvm)) {
> + ret = -EBUSY;
> + goto out;
> + }
> +
> + switch (attr->group) {
> + case KVM_DEV_ARM_VGIC_GRP_DIST_REGS:
> + if (is_write)
> + tmp32 = *reg;
> +
> + ret = vgic_v3_dist_uaccess(vcpu, is_write, addr, &tmp32);
> + if (!is_write)
> + *reg = tmp32;
> + break;
> + case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS:
> + if (is_write)
> + tmp32 = *reg;
> +
> + ret = vgic_v3_redist_uaccess(vcpu, is_write, addr, &tmp32);
> + if (!is_write)
> + *reg = tmp32;
> + break;
> + default:
> + ret = -EINVAL;
> + break;
> + }
> +
> + unlock_all_vcpus(dev->kvm);
> +out:
> + mutex_unlock(&dev->kvm->lock);
> + return ret;
> +}
> +
> static int vgic_v3_set_attr(struct kvm_device *dev,
> struct kvm_device_attr *attr)
> {
> - return vgic_set_common_attr(dev, attr);
> + int ret;
> +
> + ret = vgic_set_common_attr(dev, attr);
> + if (ret != -ENXIO)
> + return ret;
> +
> + switch (attr->group) {
> + case KVM_DEV_ARM_VGIC_GRP_DIST_REGS:
> + case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS: {
> + u32 __user *uaddr = (u32 __user *)(long)attr->addr;
> + u32 tmp32;
> + u64 reg;
> +
> + if (get_user(tmp32, uaddr))
> + return -EFAULT;
> +
> + reg = tmp32;
> + return vgic_v3_attr_regs_access(dev, attr, ®, true);
> + }
> + }
> + return -ENXIO;
> }
>
> static int vgic_v3_get_attr(struct kvm_device *dev,
> struct kvm_device_attr *attr)
> {
> - return vgic_get_common_attr(dev, attr);
> + int ret;
> +
> + ret = vgic_get_common_attr(dev, attr);
> + if (ret != -ENXIO)
> + return ret;
> +
> + switch (attr->group) {
> + case KVM_DEV_ARM_VGIC_GRP_DIST_REGS:
> + case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS: {
> + u32 __user *uaddr = (u32 __user *)(long)attr->addr;
> + u64 reg;
> + u32 tmp32;
> +
> + ret = vgic_v3_attr_regs_access(dev, attr, ®, false);
> + if (ret)
> + return ret;
> + tmp32 = reg;
> + return put_user(tmp32, uaddr);
> + }
> + }
> +
> + return -ENXIO;
> }
>
> static int vgic_v3_has_attr(struct kvm_device *dev,
> @@ -451,6 +576,9 @@ static int vgic_v3_has_attr(struct kvm_device *dev,
> return 0;
> }
> break;
> + case KVM_DEV_ARM_VGIC_GRP_DIST_REGS:
> + case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS:
> + return vgic_v3_has_attr_regs(dev, attr);
> case KVM_DEV_ARM_VGIC_GRP_NR_IRQS:
> return 0;
> case KVM_DEV_ARM_VGIC_GRP_CTRL:
> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v2.c b/virt/kvm/arm/vgic/vgic-mmio-v2.c
> index 0b32f40..2cb04b7 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio-v2.c
> +++ b/virt/kvm/arm/vgic/vgic-mmio-v2.c
> @@ -368,10 +368,9 @@ unsigned int vgic_v2_init_dist_iodev(struct vgic_io_device *dev)
>
> int vgic_v2_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr)
> {
> - int nr_irqs = dev->kvm->arch.vgic.nr_spis + VGIC_NR_PRIVATE_IRQS;
> const struct vgic_register_region *regions;
> gpa_t addr;
> - int nr_regions, i, len;
> + int nr_regions;
>
> addr = attr->attr & KVM_DEV_ARM_VGIC_OFFSET_MASK;
>
> @@ -392,18 +391,7 @@ int vgic_v2_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr)
> if (addr & 3)
> return -ENXIO;
>
> - for (i = 0; i < nr_regions; i++) {
> - if (regions[i].bits_per_irq)
> - len = (regions[i].bits_per_irq * nr_irqs) / 8;
> - else
> - len = regions[i].len;
> -
> - if (regions[i].reg_offset <= addr &&
> - regions[i].reg_offset + len > addr)
> - return 0;
> - }
> -
> - return -ENXIO;
> + return vgic_validate_mmio_region_addr(dev, regions, nr_regions, addr);
> }
>
> int vgic_v2_cpuif_uaccess(struct kvm_vcpu *vcpu, bool is_write,
> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> index 8e76d04..2a7cd62 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
> +++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> @@ -18,6 +18,8 @@
> #include <kvm/arm_vgic.h>
>
> #include <asm/kvm_emulate.h>
> +#include <asm/kvm_arm.h>
> +#include <asm/kvm_mmu.h>
>
> #include "vgic.h"
> #include "vgic-mmio.h"
> @@ -439,6 +441,9 @@ static void vgic_mmio_write_pendbase(struct kvm_vcpu *vcpu,
> REGISTER_DESC_WITH_LENGTH(GICD_CTLR,
> vgic_mmio_read_v3_misc, vgic_mmio_write_v3_misc, 16,
> VGIC_ACCESS_32bit),
> + REGISTER_DESC_WITH_LENGTH(GICD_STATUSR,
> + vgic_mmio_read_rao, vgic_mmio_write_wi, 4,
> + VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_IGROUPR,
> vgic_mmio_read_rao, vgic_mmio_write_wi, NULL, NULL, 1,
> VGIC_ACCESS_32bit),
> @@ -486,12 +491,18 @@ static void vgic_mmio_write_pendbase(struct kvm_vcpu *vcpu,
> REGISTER_DESC_WITH_LENGTH(GICR_CTLR,
> vgic_mmio_read_v3r_ctlr, vgic_mmio_write_v3r_ctlr, 4,
> VGIC_ACCESS_32bit),
> + REGISTER_DESC_WITH_LENGTH(GICR_STATUSR,
> + vgic_mmio_read_raz, vgic_mmio_write_wi, 4,
> + VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_LENGTH(GICR_IIDR,
> vgic_mmio_read_v3r_iidr, vgic_mmio_write_wi, 4,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_LENGTH(GICR_TYPER,
> vgic_mmio_read_v3r_typer, vgic_mmio_write_wi, 8,
> VGIC_ACCESS_64bit | VGIC_ACCESS_32bit),
> + REGISTER_DESC_WITH_LENGTH(GICR_WAKER,
> + vgic_mmio_read_raz, vgic_mmio_write_wi, 8,
> + VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_LENGTH(GICR_PROPBASER,
> vgic_mmio_read_propbase, vgic_mmio_write_propbase, 8,
> VGIC_ACCESS_64bit | VGIC_ACCESS_32bit),
> @@ -612,6 +623,34 @@ int vgic_register_redist_iodevs(struct kvm *kvm, gpa_t redist_base_address)
> return ret;
> }
>
> +int vgic_v3_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr)
> +{
> + const struct vgic_register_region *regions;
> + gpa_t addr;
> + int nr_regions;
> +
> + addr = attr->attr & KVM_DEV_ARM_VGIC_OFFSET_MASK;
> +
> + switch (attr->group) {
> + case KVM_DEV_ARM_VGIC_GRP_DIST_REGS:
> + regions = vgic_v3_dist_registers;
> + nr_regions = ARRAY_SIZE(vgic_v3_dist_registers);
> + break;
> + case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS:{
> + regions = vgic_v3_rdbase_registers;
> + nr_regions = ARRAY_SIZE(vgic_v3_rdbase_registers);
> + break;
> + }
> + default:
> + return -ENXIO;
> + }
> +
> + /* We only support aligned 32-bit accesses. */
> + if (addr & 3)
> + return -ENXIO;
> +
> + return vgic_validate_mmio_region_addr(dev, regions, nr_regions, addr);
> +}
> /*
> * Compare a given affinity (level 1-3 and a level 0 mask, from the SGI
> * generation register ICC_SGI1R_EL1) with a given VCPU.
> @@ -718,3 +757,36 @@ void vgic_v3_dispatch_sgi(struct kvm_vcpu *vcpu, u64 reg)
> vgic_put_irq(vcpu->kvm, irq);
> }
> }
> +
> +int vgic_v3_dist_uaccess(struct kvm_vcpu *vcpu, bool is_write,
> + int offset, u32 *val)
> +{
> + struct vgic_io_device dev = {
> + .regions = vgic_v3_dist_registers,
> + .nr_regions = ARRAY_SIZE(vgic_v3_dist_registers),
> + };
> +
> + return vgic_uaccess(vcpu, &dev, is_write, offset, val);
> +}
> +
> +int vgic_v3_redist_uaccess(struct kvm_vcpu *vcpu, bool is_write,
> + int offset, u32 *val)
> +{
> + struct vgic_io_device rd_dev = {
> + .regions = vgic_v3_rdbase_registers,
> + .nr_regions = ARRAY_SIZE(vgic_v3_rdbase_registers),
> + };
> +
> + struct vgic_io_device sgi_dev = {
> + .regions = vgic_v3_sgibase_registers,
> + .nr_regions = ARRAY_SIZE(vgic_v3_sgibase_registers),
> + };
> +
> + /* SGI_base is the next 64K frame after RD_base */
> + if (offset >= SZ_64K)
> + return vgic_uaccess(vcpu, &sgi_dev, is_write,
> + offset - SZ_64K, val);
> + else
> + return vgic_uaccess(vcpu, &rd_dev, is_write,
> + offset, val);
> +}
> diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
> index d5f3ee2..0d1bc98 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio.c
> +++ b/virt/kvm/arm/vgic/vgic-mmio.c
> @@ -394,6 +394,28 @@ static int match_region(const void *key, const void *elt)
> sizeof(region[0]), match_region);
> }
>
> +/* Check if address falls within the region */
> +int vgic_validate_mmio_region_addr(struct kvm_device *dev,
> + const struct vgic_register_region *regions,
> + int nr_regions, gpa_t addr)
> +{
> + int i, len;
> + int nr_irqs = dev->kvm->arch.vgic.nr_spis + VGIC_NR_PRIVATE_IRQS;
> +
> + for (i = 0; i < nr_regions; i++) {
> + if (regions[i].bits_per_irq)
> + len = (regions[i].bits_per_irq * nr_irqs) / 8;
> + else
> + len = regions[i].len;
> +
> + if (regions[i].reg_offset <= addr &&
> + regions[i].reg_offset + len > addr)
> + return 0;
> + }
> +
> + return -ENXIO;
> +}
> +
> /*
> * kvm_mmio_read_buf() returns a value in a format where it can be converted
> * to a byte array and be directly observed as the guest wanted it to appear
> diff --git a/virt/kvm/arm/vgic/vgic-mmio.h b/virt/kvm/arm/vgic/vgic-mmio.h
> index 7b30296..1cc7faf 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio.h
> +++ b/virt/kvm/arm/vgic/vgic-mmio.h
> @@ -177,6 +177,10 @@ void vgic_mmio_write_config(struct kvm_vcpu *vcpu,
> int vgic_uaccess(struct kvm_vcpu *vcpu, struct vgic_io_device *dev,
> bool is_write, int offset, u32 *val);
>
> +int vgic_validate_mmio_region_addr(struct kvm_device *dev,
> + const struct vgic_register_region *regions,
> + int nr_regions, gpa_t addr);
> +
> unsigned int vgic_v2_init_dist_iodev(struct vgic_io_device *dev);
>
> unsigned int vgic_v3_init_dist_iodev(struct vgic_io_device *dev);
> diff --git a/virt/kvm/arm/vgic/vgic.h b/virt/kvm/arm/vgic/vgic.h
> index 859f65c..91f58b2 100644
> --- a/virt/kvm/arm/vgic/vgic.h
> +++ b/virt/kvm/arm/vgic/vgic.h
> @@ -30,6 +30,49 @@
>
> #define vgic_irq_is_sgi(intid) ((intid) < VGIC_NR_SGIS)
>
> +#define VGIC_AFFINITY_0_SHIFT 0
> +#define VGIC_AFFINITY_0_MASK (0xffUL << VGIC_AFFINITY_0_SHIFT)
> +#define VGIC_AFFINITY_1_SHIFT 8
> +#define VGIC_AFFINITY_1_MASK (0xffUL << VGIC_AFFINITY_1_SHIFT)
> +#define VGIC_AFFINITY_2_SHIFT 16
> +#define VGIC_AFFINITY_2_MASK (0xffUL << VGIC_AFFINITY_2_SHIFT)
> +#define VGIC_AFFINITY_3_SHIFT 24
> +#define VGIC_AFFINITY_3_MASK (0xffUL << VGIC_AFFINITY_3_SHIFT)
> +
> +#define VGIC_AFFINITY_LEVEL(reg, level) \
> + ((((reg) & VGIC_AFFINITY_## level ##_MASK) \
> + >> VGIC_AFFINITY_## level ##_SHIFT) << MPIDR_LEVEL_SHIFT(level))
> +
> +/*
> + * The Userspace encodes the affinity differently from the MPIDR,
> + * Below macro converts vgic userspace format to MPIDR reg format.
> + */
> +#define VGIC_TO_MPIDR(val) (VGIC_AFFINITY_LEVEL(val, 0) | \
> + VGIC_AFFINITY_LEVEL(val, 1) | \
> + VGIC_AFFINITY_LEVEL(val, 2) | \
> + VGIC_AFFINITY_LEVEL(val, 3))
> +
> +/*
> + * As per Documentation/virtual/kvm/devices/arm-vgic-v3.txt,
> + * below macros are defined for CPUREG encoding.
> + */
> +#define KVM_REG_ARM_VGIC_SYSREG_OP0_MASK 0x000000000000c000
> +#define KVM_REG_ARM_VGIC_SYSREG_OP0_SHIFT 14
> +#define KVM_REG_ARM_VGIC_SYSREG_OP1_MASK 0x0000000000003800
> +#define KVM_REG_ARM_VGIC_SYSREG_OP1_SHIFT 11
> +#define KVM_REG_ARM_VGIC_SYSREG_CRN_MASK 0x0000000000000780
> +#define KVM_REG_ARM_VGIC_SYSREG_CRN_SHIFT 7
> +#define KVM_REG_ARM_VGIC_SYSREG_CRM_MASK 0x0000000000000078
> +#define KVM_REG_ARM_VGIC_SYSREG_CRM_SHIFT 3
> +#define KVM_REG_ARM_VGIC_SYSREG_OP2_MASK 0x0000000000000007
> +#define KVM_REG_ARM_VGIC_SYSREG_OP2_SHIFT 0
> +
> +#define KVM_DEV_ARM_VGIC_SYSREG_MASK (KVM_REG_ARM_VGIC_SYSREG_OP0_MASK | \
> + KVM_REG_ARM_VGIC_SYSREG_OP1_MASK | \
> + KVM_REG_ARM_VGIC_SYSREG_CRN_MASK | \
> + KVM_REG_ARM_VGIC_SYSREG_CRM_MASK | \
> + KVM_REG_ARM_VGIC_SYSREG_OP2_MASK)
> +
> struct vgic_vmcr {
> u32 ctlr;
> u32 abpr;
> @@ -89,7 +132,11 @@ static inline void vgic_get_irq_kref(struct vgic_irq *irq)
> int kvm_vgic_register_its_device(void);
> void vgic_enable_lpis(struct kvm_vcpu *vcpu);
> int vgic_its_inject_msi(struct kvm *kvm, struct kvm_msi *msi);
> -
> +int vgic_v3_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr);
> +int vgic_v3_dist_uaccess(struct kvm_vcpu *vcpu, bool is_write,
> + int offset, u32 *val);
> +int vgic_v3_redist_uaccess(struct kvm_vcpu *vcpu, bool is_write,
> + int offset, u32 *val);
> int kvm_register_vgic_device(unsigned long type);
> int vgic_lazy_init(struct kvm *kvm);
> int vgic_init(struct kvm *kvm);
> --
> 1.9.1
>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
^ permalink raw reply
* [PATCH v9 01/11] arm/arm64: vgic: Implement support for userspace access
From: Christoffer Dall @ 2016-11-28 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479906118-15832-2-git-send-email-vijay.kilari@gmail.com>
On Wed, Nov 23, 2016 at 06:31:48PM +0530, vijay.kilari at gmail.com wrote:
> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>
> Read and write of some registers like ISPENDR and ICPENDR
> from userspace requires special handling when compared to
> guest access for these registers.
>
> Refer to Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> for handling of ISPENDR, ICPENDR registers handling.
>
> Add infrastructure to support guest and userspace read
> and write for the required registers
> Also moved vgic_uaccess from vgic-mmio-v2.c to vgic-mmio.c
>
> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> ---
> virt/kvm/arm/vgic/vgic-mmio-v2.c | 25 ----------
> virt/kvm/arm/vgic/vgic-mmio-v3.c | 102 ++++++++++++++++++++++++++++++++-------
> virt/kvm/arm/vgic/vgic-mmio.c | 78 +++++++++++++++++++++++++++---
> virt/kvm/arm/vgic/vgic-mmio.h | 19 ++++++++
> 4 files changed, 175 insertions(+), 49 deletions(-)
>
> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v2.c b/virt/kvm/arm/vgic/vgic-mmio-v2.c
> index b44b359..0b32f40 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio-v2.c
> +++ b/virt/kvm/arm/vgic/vgic-mmio-v2.c
> @@ -406,31 +406,6 @@ int vgic_v2_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr)
> return -ENXIO;
> }
>
> -/*
> - * When userland tries to access the VGIC register handlers, we need to
> - * create a usable struct vgic_io_device to be passed to the handlers and we
> - * have to set up a buffer similar to what would have happened if a guest MMIO
> - * access occurred, including doing endian conversions on BE systems.
> - */
> -static int vgic_uaccess(struct kvm_vcpu *vcpu, struct vgic_io_device *dev,
> - bool is_write, int offset, u32 *val)
> -{
> - unsigned int len = 4;
> - u8 buf[4];
> - int ret;
> -
> - if (is_write) {
> - vgic_data_host_to_mmio_bus(buf, len, *val);
> - ret = kvm_io_gic_ops.write(vcpu, &dev->dev, offset, len, buf);
> - } else {
> - ret = kvm_io_gic_ops.read(vcpu, &dev->dev, offset, len, buf);
> - if (!ret)
> - *val = vgic_data_mmio_bus_to_host(buf, len);
> - }
> -
> - return ret;
> -}
> -
> int vgic_v2_cpuif_uaccess(struct kvm_vcpu *vcpu, bool is_write,
> int offset, u32 *val)
> {
> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> index 50f42f0..8e76d04 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
> +++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> @@ -207,6 +207,66 @@ static unsigned long vgic_mmio_read_v3_idregs(struct kvm_vcpu *vcpu,
> return 0;
> }
>
> +static unsigned long vgic_v3_uaccess_read_pending(struct kvm_vcpu *vcpu,
> + gpa_t addr, unsigned int len)
> +{
> + u32 intid = VGIC_ADDR_TO_INTID(addr, 1);
> + u32 value = 0;
> + int i;
> +
> + /*
> + * A level triggerred interrupt pending state is latched in both
> + * "soft_pending" and "line_level" variables. Userspace will save
> + * and restore soft_pending and line_level separately.
> + * Refer to Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> + * handling of ISPENDR and ICPENDR.
> + */
> + for (i = 0; i < len * 8; i++) {
> + struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
> +
> + if (irq->config == VGIC_CONFIG_LEVEL && irq->soft_pending)
> + value |= (1U << i);
> + if (irq->config == VGIC_CONFIG_EDGE && irq->pending)
> + value |= (1U << i);
> +
> + vgic_put_irq(vcpu->kvm, irq);
> + }
> +
> + return value;
> +}
> +
> +static void vgic_v3_uaccess_write_pending(struct kvm_vcpu *vcpu,
> + gpa_t addr, unsigned int len,
> + unsigned long val)
> +{
> + u32 intid = VGIC_ADDR_TO_INTID(addr, 1);
> + int i;
> +
> + for (i = 0; i < len * 8; i++) {
> + struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
> +
> + spin_lock(&irq->irq_lock);
> + if (test_bit(i, &val)) {
> + /* soft_pending is set irrespective of irq type
> + * (level or edge) to avoid dependency that VM should
> + * restore irq config before pending info.
> + */
nit: kernel commenting style
> + irq->pending = true;
> + irq->soft_pending = true;
> + vgic_queue_irq_unlock(vcpu->kvm, irq);
> + } else {
> + irq->soft_pending = false;
> + if (irq->config == VGIC_CONFIG_EDGE ||
> + (irq->config == VGIC_CONFIG_LEVEL &&
> + !irq->line_level))
> + irq->pending = false;
> + spin_unlock(&irq->irq_lock);
> + }
> +
> + vgic_put_irq(vcpu->kvm, irq);
> + }
> +}
> +
> /* We want to avoid outer shareable. */
> u64 vgic_sanitise_shareability(u64 field)
> {
> @@ -356,7 +416,7 @@ static void vgic_mmio_write_pendbase(struct kvm_vcpu *vcpu,
> * We take some special care here to fix the calculation of the register
> * offset.
> */
> -#define REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(off, rd, wr, bpi, acc) \
> +#define REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(off, rd, wr, ur, uw, bpi, acc) \
> { \
> .reg_offset = off, \
> .bits_per_irq = bpi, \
> @@ -371,6 +431,8 @@ static void vgic_mmio_write_pendbase(struct kvm_vcpu *vcpu,
> .access_flags = acc, \
> .read = rd, \
> .write = wr, \
> + .uaccess_read = ur, \
> + .uaccess_write = uw, \
> }
>
> static const struct vgic_register_region vgic_v3_dist_registers[] = {
> @@ -378,40 +440,42 @@ static void vgic_mmio_write_pendbase(struct kvm_vcpu *vcpu,
> vgic_mmio_read_v3_misc, vgic_mmio_write_v3_misc, 16,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_IGROUPR,
> - vgic_mmio_read_rao, vgic_mmio_write_wi, 1,
> + vgic_mmio_read_rao, vgic_mmio_write_wi, NULL, NULL, 1,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ISENABLER,
> - vgic_mmio_read_enable, vgic_mmio_write_senable, 1,
> + vgic_mmio_read_enable, vgic_mmio_write_senable, NULL, NULL, 1,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ICENABLER,
> - vgic_mmio_read_enable, vgic_mmio_write_cenable, 1,
> + vgic_mmio_read_enable, vgic_mmio_write_cenable, NULL, NULL, 1,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ISPENDR,
> - vgic_mmio_read_pending, vgic_mmio_write_spending, 1,
> + vgic_mmio_read_pending, vgic_mmio_write_spending,
> + vgic_v3_uaccess_read_pending, vgic_v3_uaccess_write_pending, 1,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ICPENDR,
> - vgic_mmio_read_pending, vgic_mmio_write_cpending, 1,
> + vgic_mmio_read_pending, vgic_mmio_write_cpending,
> + vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ISACTIVER,
> - vgic_mmio_read_active, vgic_mmio_write_sactive, 1,
> + vgic_mmio_read_active, vgic_mmio_write_sactive, NULL, NULL, 1,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ICACTIVER,
> - vgic_mmio_read_active, vgic_mmio_write_cactive, 1,
> + vgic_mmio_read_active, vgic_mmio_write_cactive, NULL, NULL, 1,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_IPRIORITYR,
> - vgic_mmio_read_priority, vgic_mmio_write_priority, 8,
> - VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
> + vgic_mmio_read_priority, vgic_mmio_write_priority, NULL, NULL,
> + 8, VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ITARGETSR,
> - vgic_mmio_read_raz, vgic_mmio_write_wi, 8,
> + vgic_mmio_read_raz, vgic_mmio_write_wi, NULL, NULL, 8,
> VGIC_ACCESS_32bit | VGIC_ACCESS_8bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_ICFGR,
> - vgic_mmio_read_config, vgic_mmio_write_config, 2,
> + vgic_mmio_read_config, vgic_mmio_write_config, NULL, NULL, 2,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_IGRPMODR,
> - vgic_mmio_read_raz, vgic_mmio_write_wi, 1,
> + vgic_mmio_read_raz, vgic_mmio_write_wi, NULL, NULL, 1,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED(GICD_IROUTER,
> - vgic_mmio_read_irouter, vgic_mmio_write_irouter, 64,
> + vgic_mmio_read_irouter, vgic_mmio_write_irouter, NULL, NULL, 64,
> VGIC_ACCESS_64bit | VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_LENGTH(GICD_IDREGS,
> vgic_mmio_read_v3_idregs, vgic_mmio_write_wi, 48,
> @@ -449,11 +513,13 @@ static void vgic_mmio_write_pendbase(struct kvm_vcpu *vcpu,
> REGISTER_DESC_WITH_LENGTH(GICR_ICENABLER0,
> vgic_mmio_read_enable, vgic_mmio_write_cenable, 4,
> VGIC_ACCESS_32bit),
> - REGISTER_DESC_WITH_LENGTH(GICR_ISPENDR0,
> - vgic_mmio_read_pending, vgic_mmio_write_spending, 4,
> + REGISTER_DESC_WITH_LENGTH_UACCESS(GICR_ISPENDR0,
> + vgic_mmio_read_pending, vgic_mmio_write_spending,
> + vgic_v3_uaccess_read_pending, vgic_v3_uaccess_write_pending, 4,
> VGIC_ACCESS_32bit),
> - REGISTER_DESC_WITH_LENGTH(GICR_ICPENDR0,
> - vgic_mmio_read_pending, vgic_mmio_write_cpending, 4,
> + REGISTER_DESC_WITH_LENGTH_UACCESS(GICR_ICPENDR0,
> + vgic_mmio_read_pending, vgic_mmio_write_cpending,
> + vgic_mmio_read_raz, vgic_mmio_write_wi, 4,
> VGIC_ACCESS_32bit),
> REGISTER_DESC_WITH_LENGTH(GICR_ISACTIVER0,
> vgic_mmio_read_active, vgic_mmio_write_sactive, 4,
> diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
> index ebe1b9f..d5f3ee2 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio.c
> +++ b/virt/kvm/arm/vgic/vgic-mmio.c
> @@ -484,6 +484,74 @@ static bool check_region(const struct kvm *kvm,
> return false;
> }
>
> +static const struct vgic_register_region *
> +vgic_get_mmio_region(struct kvm_vcpu *vcpu, struct vgic_io_device *iodev,
> + gpa_t addr, int len)
> +{
> + const struct vgic_register_region *region;
> +
> + region = vgic_find_mmio_region(iodev->regions, iodev->nr_regions,
> + addr - iodev->base_addr);
> + if (!region || !check_region(vcpu->kvm, region, addr, len))
> + return NULL;
> +
> + return region;
> +}
> +
> +static int vgic_uaccess_read(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
> + gpa_t addr, u32 *val)
> +{
> + struct vgic_io_device *iodev = kvm_to_vgic_iodev(dev);
> + const struct vgic_register_region *region;
> + struct kvm_vcpu *r_vcpu;
> +
> + region = vgic_get_mmio_region(vcpu, iodev, addr, sizeof(u32));
> + if (!region) {
> + *val = 0;
> + return 0;
> + }
> +
> + r_vcpu = iodev->redist_vcpu ? iodev->redist_vcpu : vcpu;
> + if (region->uaccess_read)
> + *val = region->uaccess_read(r_vcpu, addr, sizeof(u32));
> + else
> + *val = region->read(r_vcpu, addr, sizeof(u32));
> +
> + return 0;
> +}
> +
> +static int vgic_uaccess_write(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
> + gpa_t addr, const u32 *val)
> +{
> + struct vgic_io_device *iodev = kvm_to_vgic_iodev(dev);
> + const struct vgic_register_region *region;
> + struct kvm_vcpu *r_vcpu;
> +
> + region = vgic_get_mmio_region(vcpu, iodev, addr, sizeof(u32));
> + if (!region)
> + return 0;
> +
> + r_vcpu = iodev->redist_vcpu ? iodev->redist_vcpu : vcpu;
> + if (region->uaccess_write)
> + region->uaccess_write(r_vcpu, addr, sizeof(u32), *val);
> + else
> + region->write(r_vcpu, addr, sizeof(u32), *val);
> +
> + return 0;
> +}
> +
> +/*
> + * Userland access to VGIC registers.
> + */
> +int vgic_uaccess(struct kvm_vcpu *vcpu, struct vgic_io_device *dev,
> + bool is_write, int offset, u32 *val)
> +{
> + if (is_write)
> + return vgic_uaccess_write(vcpu, &dev->dev, offset, val);
> + else
> + return vgic_uaccess_read(vcpu, &dev->dev, offset, val);
> +}
> +
> static int dispatch_mmio_read(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
> gpa_t addr, int len, void *val)
> {
> @@ -491,9 +559,8 @@ static int dispatch_mmio_read(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
> const struct vgic_register_region *region;
> unsigned long data = 0;
>
> - region = vgic_find_mmio_region(iodev->regions, iodev->nr_regions,
> - addr - iodev->base_addr);
> - if (!region || !check_region(vcpu->kvm, region, addr, len)) {
> + region = vgic_get_mmio_region(vcpu, iodev, addr, len);
> + if (!region) {
> memset(val, 0, len);
> return 0;
> }
> @@ -524,9 +591,8 @@ static int dispatch_mmio_write(struct kvm_vcpu *vcpu, struct kvm_io_device *dev,
> const struct vgic_register_region *region;
> unsigned long data = vgic_data_mmio_bus_to_host(val, len);
>
> - region = vgic_find_mmio_region(iodev->regions, iodev->nr_regions,
> - addr - iodev->base_addr);
> - if (!region || !check_region(vcpu->kvm, region, addr, len))
> + region = vgic_get_mmio_region(vcpu, iodev, addr, len);
> + if (!region)
> return 0;
>
> switch (iodev->iodev_type) {
> diff --git a/virt/kvm/arm/vgic/vgic-mmio.h b/virt/kvm/arm/vgic/vgic-mmio.h
> index 84961b4..7b30296 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio.h
> +++ b/virt/kvm/arm/vgic/vgic-mmio.h
> @@ -34,6 +34,10 @@ struct vgic_register_region {
> gpa_t addr, unsigned int len,
> unsigned long val);
> };
> + unsigned long (*uaccess_read)(struct kvm_vcpu *vcpu, gpa_t addr,
> + unsigned int len);
> + void (*uaccess_write)(struct kvm_vcpu *vcpu, gpa_t addr,
> + unsigned int len, unsigned long val);
> };
>
> extern struct kvm_io_device_ops kvm_io_gic_ops;
> @@ -86,6 +90,18 @@ struct vgic_register_region {
> .write = wr, \
> }
>
> +#define REGISTER_DESC_WITH_LENGTH_UACCESS(off, rd, wr, urd, uwr, length, acc) \
> + { \
> + .reg_offset = off, \
> + .bits_per_irq = 0, \
> + .len = length, \
> + .access_flags = acc, \
> + .read = rd, \
> + .write = wr, \
> + .uaccess_read = urd, \
> + .uaccess_write = uwr, \
> + }
> +
> int kvm_vgic_register_mmio_region(struct kvm *kvm, struct kvm_vcpu *vcpu,
> struct vgic_register_region *reg_desc,
> struct vgic_io_device *region,
> @@ -158,6 +174,9 @@ void vgic_mmio_write_config(struct kvm_vcpu *vcpu,
> gpa_t addr, unsigned int len,
> unsigned long val);
>
> +int vgic_uaccess(struct kvm_vcpu *vcpu, struct vgic_io_device *dev,
> + bool is_write, int offset, u32 *val);
> +
> unsigned int vgic_v2_init_dist_iodev(struct vgic_io_device *dev);
>
> unsigned int vgic_v3_init_dist_iodev(struct vgic_io_device *dev);
> --
> 1.9.1
>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
^ permalink raw reply
* [GIT PULL]: ARM ARTPEC changes for 4.10
From: Arnd Bergmann @ 2016-11-28 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128123331.GO19016@axis.com>
On Monday, November 28, 2016 1:33:31 PM CET Jesper Nilsson wrote:
> > Hi Jesper and Niklas,
> >
> > I just found the old pull request while going through my mail backlog.
> >
> > A few things for you to remember for next time:
> >
> > - please send pull requests "To: arm at kernel.org" so we know they
> > are destined for arm-soc
>
> Ok, should we add that in the MAINTAINERS file so we can
> get it automatically from get_maintainer?
No, we don't want to get every single patch that people submit to
platform maintainers, only the consolidated pull requests that you
send.
Arnd
^ permalink raw reply
* [PATCH net-next v3 4/4] ARM64: dts: meson: odroidc2: disable advertisement EEE for GbE.
From: Jerome Brunet @ 2016-11-28 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9709dd57-e536-9281-6b56-5ff5f9e8035c@suse.de>
On Mon, 2016-11-28 at 13:31 +0100, Andreas F?rber wrote:
> Am 28.11.2016 um 10:46 schrieb Jerome Brunet:
> >
> > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> > ---
> > ?arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 16
> > ++++++++++++++++
> > ?1 file changed, 16 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > index e6e3491d48a5..5624714d2b16 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> > @@ -46,6 +46,7 @@
> > ?
> > ?#include "meson-gxbb.dtsi"
> > ?#include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/net/mdio.h>
> > ?
> > ?/ {
> > ? compatible = "hardkernel,odroid-c2", "amlogic,meson-gxbb";
> > @@ -98,3 +99,18 @@
> > ? pinctrl-0 = <&i2c_a_pins>;
> > ? pinctrl-names = "default";
> > ?};
> > +
> > +ðmac {
> > + phy-handle = <ð_phy0>;
> > +
> > + mdio {
> > + compatible = "snps,dwmac-mdio";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + eth_phy0: ethernet-phy at 0 {
> > + reg = <0>;
> > + eee-broken-modes = <MDIO_EEE_1000T>;
> > + };
> > + };
> > +};
>
6I've tested this hand-applied because it applies to neither amlogic
> v4.10/integ nor linux-next.git and will conflict if applied through
> the
> net-next tree.
I've rebased on net-next this morning. I just checked again and now
there is a conflict indeed. Something got applied between in the last 6
ours which conflict with patch 4.
>
> Note that there already is an ðmac node that you should be
> extending
> rather than duplicating:
>
> ðmac {
> status = "okay";
> pinctrl-0 = <ð_rgmii_pins>;
> pinctrl-names = "default";
> };
>
> If you or your colleagues could please fix the sort order of the
> nodes
> to be alphabetical again (ethmac after i2c_A here; between uart_A and
> ir
> in-tree) this wouldn't happen so easily again.
OK
>
> I therefore suggest to not apply this patch 4/4 through net-next but
> through the amlogic tree instead.
Agreed. The change is provided here so people can test.
If the other patches get accepted, I'll submit the dts change through
the amlogic tree.
>
> Thanks,
> Andreas
>
^ permalink raw reply
* [bug report v4.8] fs/locks.c: kernel oops during posix lock stress test
From: Ming Lei @ 2016-11-28 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128105254.GB1485@arm.com>
Hi Will,
On Mon, Nov 28, 2016 at 6:52 PM, Will Deacon <will.deacon@arm.com> wrote:
> Hi Ming,
>
> On Mon, Nov 28, 2016 at 11:10:14AM +0800, Ming Lei wrote:
>> When I run stress-ng via the following steps on one ARM64 dual
>> socket system(Cavium Thunder), the kernel oops[1] can often be
>> triggered after running the stress test for several hours(sometimes
>> it may take longer):
>>
>> - git clone git://kernel.ubuntu.com/cking/stress-ng.git
>> - apply the attachment patch which just makes the posix file
>> lock stress test more aggressive
>> - run the test via '~/git/stress-ng$./stress-ng --lockf 128 --aggressive'
>>
>>
>> From the oops log, looks one garbage file_lock node is got
>> from the linked list of 'ctx->flc_posix' when the issue happens.
>>
>> BTW, the issue isn't observed on single socket Cavium Thunder yet,
>> and the same issue can be seen on Ubuntu Xenial(v4.4 based kernel)
>> too.
>
> I've seen issues with the LSE atomics on the Thunder platform -- can you
> try disabling those (CONFIG_ARM64_LSE_ATOMICS) and see if the problem
> persists, please?
>
Ubuntu Xenial doesn't enable CONFIG_ARM64_LSE_ATOMICS, which
is disabled in my v4.8 kernel config too, please see that in the attachement.
Thanks,
Ming
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config-v4.8.tar.gz
Type: application/x-gzip
Size: 40134 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161128/32583ef0/attachment-0001.bin>
^ permalink raw reply
* [GIT PULL] STi defconfig updates for v4.10 round 3
From: Patrice Chotard @ 2016-11-28 12:37 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Arnd and Kevin,
Please consider this third round of multi_v7_defconfig updates for v4.10 :
The following changes since commit 57dae748959d0abae2b382ccee68621a82f827c8:
ARM: multi_v7_defconfig: Remove ST_THERMAL_SYSCFG Kconfig symbol (2016-10-21 17:05:54 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pchotard/sti.git tags/sti-defconfig-for-4.10-round3
for you to fetch changes up to 88d7658bf31f17296b8792e62268825d066d23c4:
ARM: multi_v7_defconfig: enable STMicroelectronics HVA driver (2016-11-28 13:02:14 +0100)
----------------------------------------------------------------
STi defconfig fix:
Enable HVA (Hardware Video Accelerator) video encoder
driver for STMicroelectronics SoC.
----------------------------------------------------------------
Patrice Chotard (1):
ARM: multi_v7_defconfig: enable STMicroelectronics HVA driver
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
^ permalink raw reply
* [GIT PULL]: ARM ARTPEC changes for 4.10
From: Jesper Nilsson @ 2016-11-28 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5317474.MXurzNW7Do@wuerfel>
On Sat, Nov 26, 2016 at 12:16:20AM +0100, Arnd Bergmann wrote:
> On Thursday, November 10, 2016 4:09:31 PM CET Jesper Nilsson wrote:
> > Please pull the below signed tag for a trio of minor changes
> > adding PCIe for the ARM ARTPEC SoC.
> >
> > Thanks!
> >
> > /Jesper
> >
> > The following changes since commit bc33b0ca11e3df467777a4fa7639ba488c9d4911:
> >
> > Linux 4.9-rc4 (2016-11-05 16:23:36 -0700)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/jesper/artpec.git tags/artpec-for-4.10
> >
> > for you to fetch changes up to fa5541fc806771a108cd2a48245a229f1ba539ea:
> >
> > ARM: dts: artpec: add pcie support (2016-11-10 15:51:10 +0100)
> >
> > ----------------------------------------------------------------
> > ARTPEC changes for 4.10
> >
> > ----------------------------------------------------------------
> > Niklas Cassel (3):
> > ARM: ARTPEC-6: add select MFD_SYSCON to MACH_ARTPEC6
> > ARM: ARTPEC-6: add pcie related options
> > ARM: dts: artpec: add pcie support
> >
> >
>
> Hi Jesper and Niklas,
>
> I just found the old pull request while going through my mail backlog.
>
> A few things for you to remember for next time:
>
> - please send pull requests "To: arm at kernel.org" so we know they
> are destined for arm-soc
Ok, should we add that in the MAINTAINERS file so we can
get it automatically from get_maintainer?
> - please split up changes to the platform code from dts changes,
> defconfig changes and driver changes. Each of them gets sent
> to Linus in a separate arm-soc branch, so we have to pull them
> in separately too
>
> - For the signed tag, please put in a cleartext description of
> the branch, just like you describe each commit in its changelog
> text. The tag comment becomes the merge commit text.
Ok, will do both in the future.
> - I've looked at the three patches individually and cherry-picked
> the first into next/soc and the third into next/dt. The patch
> "ARM: ARTPEC-6: add pcie related options" is no longer needed
> after commit e13688f ("ARM: select PCI_DOMAINS config from
> ARCH_MULTIPLATFORM"), so I dropped that.
Thanks!
> Arnd
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson at axis.com
^ permalink raw reply
* [PATCH net-next v3 4/4] ARM64: dts: meson: odroidc2: disable advertisement EEE for GbE.
From: Andreas Färber @ 2016-11-28 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480326409-25419-5-git-send-email-jbrunet@baylibre.com>
Am 28.11.2016 um 10:46 schrieb Jerome Brunet:
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index e6e3491d48a5..5624714d2b16 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -46,6 +46,7 @@
>
> #include "meson-gxbb.dtsi"
> #include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/net/mdio.h>
>
> / {
> compatible = "hardkernel,odroid-c2", "amlogic,meson-gxbb";
> @@ -98,3 +99,18 @@
> pinctrl-0 = <&i2c_a_pins>;
> pinctrl-names = "default";
> };
> +
> +ðmac {
> + phy-handle = <ð_phy0>;
> +
> + mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + eth_phy0: ethernet-phy at 0 {
> + reg = <0>;
> + eee-broken-modes = <MDIO_EEE_1000T>;
> + };
> + };
> +};
I've tested this hand-applied because it applies to neither amlogic
v4.10/integ nor linux-next.git and will conflict if applied through the
net-next tree.
Note that there already is an ðmac node that you should be extending
rather than duplicating:
ðmac {
status = "okay";
pinctrl-0 = <ð_rgmii_pins>;
pinctrl-names = "default";
};
If you or your colleagues could please fix the sort order of the nodes
to be alphabetical again (ethmac after i2c_A here; between uart_A and ir
in-tree) this wouldn't happen so easily again.
I therefore suggest to not apply this patch 4/4 through net-next but
through the amlogic tree instead.
Thanks,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [RFC PATCH 13/29] arm64/sve: Basic support for KERNEL_MODE_NEON
From: Dave Martin @ 2016-11-28 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128120623.GA17125@e104818-lin.cambridge.arm.com>
On Mon, Nov 28, 2016 at 12:06:24PM +0000, Catalin Marinas wrote:
> On Mon, Nov 28, 2016 at 11:47:26AM +0000, Dave P Martin wrote:
> > On Sat, Nov 26, 2016 at 11:30:42AM +0000, Catalin Marinas wrote:
> > > On Fri, Nov 25, 2016 at 08:45:02PM +0000, Ard Biesheuvel wrote:
> > > > On 25 November 2016 at 19:39, Dave Martin <Dave.Martin@arm.com> wrote:
> > > > > --- a/arch/arm64/kernel/fpsimd.c
> > > > > +++ b/arch/arm64/kernel/fpsimd.c
> > > > > @@ -282,11 +282,26 @@ static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate);
> > > > > */
> > > > > void kernel_neon_begin_partial(u32 num_regs)
> > > > > {
> > > > > + preempt_disable();
> > > > > +
> > > > > + /*
> > > > > + * For now, we have no special storage for SVE registers in
> > > > > + * interrupt context, so always save the userland SVE state
> > > > > + * if there is any, even for interrupts.
> > > > > + */
> > > > > + if (IS_ENABLED(CONFIG_ARM64_SVE) && (elf_hwcap & HWCAP_SVE) &&
> > > > > + current->mm &&
> > > > > + !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE)) {
> > > > > + fpsimd_save_state(¤t->thread.fpsimd_state);
> > > > > + this_cpu_write(fpsimd_last_state, NULL);
> > > > > + }
> > > > > +
> > > >
> > > > I am having trouble understanding why we need all of this if we don't
> > > > support SVE in the kernel. Could you elaborate?
> > >
> > > Dave knows all the details but a reason is that touching a Neon register
> > > zeros the upper SVE state in the same vector register. So we can't
> > > safely save/restore just the Neon part without corrupting the SVE state.
> >
> > This is right -- this also means that EFI services can trash the upper
> > bits of an SVE vector register (as a side-effect of FPSIMD/NEON usage).
> >
> > It's overkill to save/restore absolutely everything -- I ignore num_regs
> > for example -- but I wanted to keep things as simple as possible
> > initially.
>
> Without looking at your patches in detail, could we mandate in the ABI
> that the SVE state is lost on the user/kernel syscall boundary? I guess
> even for the PCS, the SVE state is caller-saved, so there shouldn't be
> an additional cost to user. On interrupts, however, we'd have to
> preserve the SVE state but if we do this on entry/exit points, the
> kernel_neon_*() functions would not have to deal with any SVE state (and
> even ignore it completely if in interrupt).
See [RFC PATCH 24/29] arm64/sve: Discard SVE state on system call.
Currently, kernel_neon_begin_partial() doesn't take advandage of this --
discarding the state is deferred until sched-out, and anyway I don't
check for TIF_SVE in kernel_neon_begin_partial(). There's definitely
some room for improvement.
> the requirements for syscall and sigcontext modifications.
Agreed -- I wanted to get this series posted so skipped that for now,
but I plan to include a Documentation patch alongside the final series.
Cheers
---Dave
^ permalink raw reply
* [PATCH net-next v3 3/4] dt: bindings: add ethernet phy eee-broken-modes option documentation
From: Andreas Färber @ 2016-11-28 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480326409-25419-4-git-send-email-jbrunet@baylibre.com>
Am 28.11.2016 um 10:46 schrieb Jerome Brunet:
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> Documentation/devicetree/bindings/net/phy.txt | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Andreas F?rber <afaerber@suse.de>
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [PATCH net-next v3 2/4] dt-bindings: net: add EEE capability constants
From: Andreas Färber @ 2016-11-28 12:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480326409-25419-3-git-send-email-jbrunet@baylibre.com>
Am 28.11.2016 um 10:46 schrieb Jerome Brunet:
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> include/dt-bindings/net/mdio.h | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
> create mode 100644 include/dt-bindings/net/mdio.h
Tested-by: Andreas F?rber <afaerber@suse.de>
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [PATCH net-next v3 1/4] net: phy: add an option to disable EEE advertisement
From: Andreas Färber @ 2016-11-28 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480326409-25419-2-git-send-email-jbrunet@baylibre.com>
Am 28.11.2016 um 10:46 schrieb Jerome Brunet:
> This patch adds an option to disable EEE advertisement in the generic PHY
> by providing a mask of prohibited modes corresponding to the value found in
> the MDIO_AN_EEE_ADV register.
>
> On some platforms, PHY Low power idle seems to be causing issues, even
> breaking the link some cases. The patch provides a convenient way for these
> platforms to disable EEE advertisement and work around the issue.
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> drivers/net/phy/phy.c | 3 ++
> drivers/net/phy/phy_device.c | 80 +++++++++++++++++++++++++++++++++++++++-----
> include/linux/phy.h | 3 ++
> 3 files changed, 77 insertions(+), 9 deletions(-)
Tested-by: Andreas F?rber <afaerber@suse.de>
With this and the corresponding .dts change, Odroid-C2 survived a
317-package zypper update for me.
Thanks,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [PATCH] arm64: Remove I-cache invalidation from flush_cache_range()
From: Catalin Marinas @ 2016-11-28 12:15 UTC (permalink / raw)
To: linux-arm-kernel
The flush_cache_range() function (similarly for flush_cache_page()) is
called when the kernel is changing an existing VA->PA mapping range to
either a new PA or to different attributes. Since ARMv8 has PIPT-like
D-caches, this function does not need to perform any D-cache
maintenance. The I-cache maintenance is already handled via set_pte_at()
and flush_cache_range() cannot anyway guarantee that there are no cache
lines left after invalidation due to the speculative loads.
This patch makes flush_cache_range() a no-op.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
Cc'ing Russell as well, I think we can remove the __flush_icache_all()
call in arch/arm for the VIPT (both aliasing and non-aliasing) caches
since we already handle the I-cache in __sync_icache_dcache(). Any
opinion?
arch/arm64/include/asm/cacheflush.h | 6 +++++-
arch/arm64/mm/flush.c | 7 -------
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/cacheflush.h b/arch/arm64/include/asm/cacheflush.h
index e9f64ecb75ce..5a2a6ee65f65 100644
--- a/arch/arm64/include/asm/cacheflush.h
+++ b/arch/arm64/include/asm/cacheflush.h
@@ -65,7 +65,6 @@
* - kaddr - page address
* - size - region size
*/
-extern void flush_cache_range(struct vm_area_struct *vma, unsigned long start, unsigned long end);
extern void flush_icache_range(unsigned long start, unsigned long end);
extern void __flush_dcache_area(void *addr, size_t len);
extern void __clean_dcache_area_poc(void *addr, size_t len);
@@ -82,6 +81,11 @@ static inline void flush_cache_page(struct vm_area_struct *vma,
{
}
+static inline void flush_cache_range(struct vm_area_struct *vma,
+ unsigned long start, unsigned long end)
+{
+}
+
/*
* Cache maintenance functions used by the DMA API. No to be used directly.
*/
diff --git a/arch/arm64/mm/flush.c b/arch/arm64/mm/flush.c
index 2d78d5a9b89f..554a2558c12e 100644
--- a/arch/arm64/mm/flush.c
+++ b/arch/arm64/mm/flush.c
@@ -25,13 +25,6 @@
#include <asm/cachetype.h>
#include <asm/tlbflush.h>
-void flush_cache_range(struct vm_area_struct *vma, unsigned long start,
- unsigned long end)
-{
- if (vma->vm_flags & VM_EXEC)
- __flush_icache_all();
-}
-
void sync_icache_aliases(void *kaddr, unsigned long len)
{
unsigned long addr = (unsigned long)kaddr;
^ permalink raw reply related
* [PATCH v2 2/2] ARM: dts: da850-lcdk: specify the maximum pixel clock rate for tilcdc
From: Bartosz Golaszewski @ 2016-11-28 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480335328-4010-1-git-send-email-bgolaszewski@baylibre.com>
Due to memory throughput constraints any display mode for which the
pixel clock rate exceeds the recommended value of 37500 KHz must be
filtered out.
Specify the max-pixelclock property for the display node for
da850-lcdk.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index d864f11..1283263 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -285,6 +285,7 @@
&display {
status = "okay";
+ max-pixelclock = <37500>;
};
&display_out {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/2] ARM: dts: da850-lcdk: add the dumb-vga-dac node
From: Bartosz Golaszewski @ 2016-11-28 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480335328-4010-1-git-send-email-bgolaszewski@baylibre.com>
Add the dumb-vga-dac node to the board DT together with corresponding
ports and vga connector. This allows to retrieve the edid info from
the display automatically.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 58 ++++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/da850.dtsi | 17 ++++++++++++
2 files changed, 75 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 711b9ad..d864f11 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -50,6 +50,53 @@
system-clock-frequency = <24576000>;
};
};
+
+ vga_bridge {
+ compatible = "dumb-vga-dac";
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ vga_bridge_in: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&display_out_vga>;
+ };
+ };
+
+ port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ vga_bridge_out: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&vga_con_in>;
+ };
+ };
+ };
+ };
+
+ vga {
+ compatible = "vga-connector";
+
+ ddc-i2c-bus = <&i2c0>;
+
+ port {
+ vga_con_in: endpoint {
+ remote-endpoint = <&vga_bridge_out>;
+ };
+ };
+ };
};
&pmx_core {
@@ -235,3 +282,14 @@
&memctrl {
status = "okay";
};
+
+&display {
+ status = "okay";
+};
+
+&display_out {
+ display_out_vga: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&vga_bridge_in>;
+ };
+};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 4070619..5f4ba2e 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -454,6 +454,23 @@
reg = <0x213000 0x1000>;
interrupts = <52>;
status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ display_in: port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ display_out: port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
};
};
aemif: aemif at 68000000 {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 0/2] ARM: dts: da850: tilcdc related DT changes
From: Bartosz Golaszewski @ 2016-11-28 12:15 UTC (permalink / raw)
To: linux-arm-kernel
This series contains the last DT changes required for LCDC support
on da850-lcdk. The first one adds the dumb-vga-dac nodes, the second
limits the maximum pixel clock rate.
v1 -> v2:
- drop patch 3/3 (already merged)
- use max-pixelclock instead of max-bandwidth for display mode limiting
Bartosz Golaszewski (2):
ARM: dts: da850-lcdk: add the dumb-vga-dac node
ARM: dts: da850-lcdk: specify the maximum pixel clock rate for tilcdc
arch/arm/boot/dts/da850-lcdk.dts | 59 ++++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/da850.dtsi | 17 ++++++++++++
2 files changed, 76 insertions(+)
--
2.9.3
^ permalink raw reply
* [GIT PULL] STi defconfig fix for v4.9-rcs
From: Patrice Chotard @ 2016-11-28 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6441620.Ib6HJmGOKY@wuerfel>
On 11/25/2016 10:40 PM, Arnd Bergmann wrote:
> On Wednesday, November 23, 2016 9:59:14 AM CET Patrice Chotard wrote:
>> STi defconfig fix:
>>
>> Enable HVA (Hardware Video Accelerator) video encoder
>> driver for STMicroelectronics SoC.
>
Hi Arnd
> Defconfig changes like this don't seem particularly urgent. Unless
> there is a good reason, I'd suggest putting this into v4.10 instead.
You are right, it's not a urgent update for STi.
I will send a pull request dedicated for v4.10.
Thanks
Patrice
>
> Arnd
>
^ permalink raw reply
* [RFC PATCH 13/29] arm64/sve: Basic support for KERNEL_MODE_NEON
From: Catalin Marinas @ 2016-11-28 12:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128114723.GG1574@e103592.cambridge.arm.com>
On Mon, Nov 28, 2016 at 11:47:26AM +0000, Dave P Martin wrote:
> On Sat, Nov 26, 2016 at 11:30:42AM +0000, Catalin Marinas wrote:
> > On Fri, Nov 25, 2016 at 08:45:02PM +0000, Ard Biesheuvel wrote:
> > > On 25 November 2016 at 19:39, Dave Martin <Dave.Martin@arm.com> wrote:
> > > > --- a/arch/arm64/kernel/fpsimd.c
> > > > +++ b/arch/arm64/kernel/fpsimd.c
> > > > @@ -282,11 +282,26 @@ static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate);
> > > > */
> > > > void kernel_neon_begin_partial(u32 num_regs)
> > > > {
> > > > + preempt_disable();
> > > > +
> > > > + /*
> > > > + * For now, we have no special storage for SVE registers in
> > > > + * interrupt context, so always save the userland SVE state
> > > > + * if there is any, even for interrupts.
> > > > + */
> > > > + if (IS_ENABLED(CONFIG_ARM64_SVE) && (elf_hwcap & HWCAP_SVE) &&
> > > > + current->mm &&
> > > > + !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE)) {
> > > > + fpsimd_save_state(¤t->thread.fpsimd_state);
> > > > + this_cpu_write(fpsimd_last_state, NULL);
> > > > + }
> > > > +
> > >
> > > I am having trouble understanding why we need all of this if we don't
> > > support SVE in the kernel. Could you elaborate?
> >
> > Dave knows all the details but a reason is that touching a Neon register
> > zeros the upper SVE state in the same vector register. So we can't
> > safely save/restore just the Neon part without corrupting the SVE state.
>
> This is right -- this also means that EFI services can trash the upper
> bits of an SVE vector register (as a side-effect of FPSIMD/NEON usage).
>
> It's overkill to save/restore absolutely everything -- I ignore num_regs
> for example -- but I wanted to keep things as simple as possible
> initially.
Without looking at your patches in detail, could we mandate in the ABI
that the SVE state is lost on the user/kernel syscall boundary? I guess
even for the PCS, the SVE state is caller-saved, so there shouldn't be
an additional cost to user. On interrupts, however, we'd have to
preserve the SVE state but if we do this on entry/exit points, the
kernel_neon_*() functions would not have to deal with any SVE state (and
even ignore it completely if in interrupt).
BTW, we will need an SVE ABI document in Documentation/arm64/ to specify
the requirements for syscall and sigcontext modifications.
--
Catalin
^ permalink raw reply
* [PATCH v4] crypto: arm64/sha2: integrate OpenSSL implementations of SHA256/SHA512
From: Will Deacon @ 2016-11-28 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479642121-17912-1-git-send-email-ard.biesheuvel@linaro.org>
On Sun, Nov 20, 2016 at 11:42:01AM +0000, Ard Biesheuvel wrote:
> This integrates both the accelerated scalar and the NEON implementations
> of SHA-224/256 as well as SHA-384/512 from the OpenSSL project.
>
> Relative performance compared to the respective generic C versions:
>
> | SHA256-scalar | SHA256-NEON* | SHA512 |
> ------------+-----------------+--------------+----------+
> Cortex-A53 | 1.63x | 1.63x | 2.34x |
> Cortex-A57 | 1.43x | 1.59x | 1.95x |
> Cortex-A73 | 1.26x | 1.56x | ? |
>
> The core crypto code was authored by Andy Polyakov of the OpenSSL
> project, in collaboration with whom the upstream code was adapted so
> that this module can be built from the same version of sha512-armv8.pl.
>
> The version in this patch was taken from OpenSSL commit 32bbb62ea634
> ("sha/asm/sha512-armv8.pl: fix big-endian support in __KERNEL__ case.")
>
> * The core SHA algorithm is fundamentally sequential, but there is a
> secondary transformation involved, called the schedule update, which
> can be performed independently. The NEON version of SHA-224/SHA-256
> only implements this part of the algorithm using NEON instructions,
> the sequential part is always done using scalar instructions.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/crypto/Kconfig | 8 +
> arch/arm64/crypto/Makefile | 17 +
> arch/arm64/crypto/sha256-core.S_shipped | 2061 ++++++++++++++++++++
> arch/arm64/crypto/sha256-glue.c | 185 ++
> arch/arm64/crypto/sha512-armv8.pl | 778 ++++++++
> arch/arm64/crypto/sha512-core.S_shipped | 1085 +++++++++++
> arch/arm64/crypto/sha512-glue.c | 94 +
> 7 files changed, 4228 insertions(+)
If I build a kernel with this applied and CRYPTO_SHA{256,512}_ARM64=y,
then I end up with untracked .S files according to git:
$ git status
Untracked files:
arch/arm64/crypto/sha256-core.S
arch/arm64/crypto/sha512-core.S
Will
^ permalink raw reply
* [PATCH v4] crypto: arm64/sha2: integrate OpenSSL implementations of SHA256/SHA512
From: Herbert Xu @ 2016-11-28 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9RVFQ4SNzbHbNCFSXy01b+_dCeRc4bXgZagovGy9BYtQ@mail.gmail.com>
On Mon, Nov 28, 2016 at 09:50:33AM +0000, Ard Biesheuvel wrote:
>
> Assuming that everyone is happy now (Will?), could we get this one
> queued for v4.10? The CRC stuff I sent over the past week can wait for
> v4.11 (and I should probably do a v2 roundup with everything
> combined), but this patch is good to go IMO
Sorry, I overlooked it because it wasn't in patchwork. I have
applied it now and will push it out soon.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
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