* RE: [PATCH] remote-curl: don't hang when a server dies before any output
From: David Turner @ 2016-11-14 23:25 UTC (permalink / raw)
To: 'Jeff King'; +Cc: git@vger.kernel.org, spearce@spearce.org
In-Reply-To: <20161114194049.mktpsvgdhex2f4zv@sigill.intra.peff.net>
> -----Original Message-----
> From: Jeff King [mailto:peff@peff.net]
> Sent: Monday, November 14, 2016 2:41 PM
> To: David Turner
> Cc: git@vger.kernel.org; spearce@spearce.org
> Subject: Re: [PATCH] remote-curl: don't hang when a server dies before any
> output
>
> On Mon, Nov 14, 2016 at 01:24:31PM -0500, Jeff King wrote:
>
> > 2. Have remote-curl understand enough of the protocol that it can
> > abort rather than hang.
> >
> > I think that's effectively the approach of your patch, but for one
> > specific case. But could we, for example, make sure that everything
> > we proxy is a complete set of pktlines and ends with a flush? And
> > if not, then we hang up on fetch-pack.
> >
> > I _think_ that would work, because even the pack is always encased
> > in pktlines for smart-http.
>
> So something like this. It turned out to be a lot uglier than I had hoped
> because we get fed the data from curl in odd-sized chunks, so we need a
> state machine.
>
> But it does seem to work. At least it doesn't seem to break anything in
> the test suite, and it fixes the new tests you added. I'd worry that
> there's some obscure case where the response isn't packetized in the same
> way.
Overall, this looks good to me. The state machine is pretty clean. I think I would have used a tiny buffer for the length field, and then I would have regretted it. Your way looks nicer than my unwritten patch would have looked.
> +#define READ_ONE_HEX(shift) do { \
> + int val = hexval(buf[0]); \
> + if (val < 0) { \
> + warning("error on %d", *buf); \
> + rpc->pktline_state = RPC_PKTLINE_ERROR; \
> + return; \
> + } \
> + rpc->pktline_len |= val << shift; \
Nit: parenthesize shift here, since it is a parameter to a macro.
^ permalink raw reply
* Re: [ath9k-devel] [NOT FOR MERGE] ath9k: work around key cache corruption
From: Adrian Chadd @ 2016-11-14 23:25 UTC (permalink / raw)
To: Stam, Michel [FINT]
Cc: Johannes Berg, Sebastian Gottschall, Kalle Valo,
Antonio Quartulli, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org, Antonio Quartulli
In-Reply-To: <4fd6af4b02474a3eb4acfbe421bd6a24@nldataex02.ad.fugro.com>
Hiya,
maybe the right thing to do is to set a flag that says "please
replumb", then do a reset, and have the reset path see if we need to
replumb keys and do so?
To make locking less terrible, maybe we need to cache the keys in the
ath9k driver somewhere so replumbing doesn't require reaching into
mac82011.
-adrian
^ permalink raw reply
* [ath9k-devel] [NOT FOR MERGE] ath9k: work around key cache corruption
From: Adrian Chadd @ 2016-11-14 23:25 UTC (permalink / raw)
To: ath9k-devel
In-Reply-To: <4fd6af4b02474a3eb4acfbe421bd6a24@nldataex02.ad.fugro.com>
Hiya,
maybe the right thing to do is to set a flag that says "please
replumb", then do a reset, and have the reset path see if we need to
replumb keys and do so?
To make locking less terrible, maybe we need to cache the keys in the
ath9k driver somewhere so replumbing doesn't require reaching into
mac82011.
-adrian
^ permalink raw reply
* linux-next: BUG: unable to handle kernel NULL pointer dereference in __sk_mem_raise_allocated()
From: Andrei Vagin @ 2016-11-14 23:24 UTC (permalink / raw)
To: Linux Kernel Network Developers, Paolo Abeni
Hi Paolo,
Our test system detected a kernel oops. Looks like a problem in the
"udp: refactor memory accounting" series.
# good: [f970bd9e3a06f06df8d8ecf1f8ad2c8615cc17eb] udp: implement
memory accounting helpers
git bisect good f970bd9e3a06f06df8d8ecf1f8ad2c8615cc17eb
# bad: [2d0e30c30f84d08dc16f0f2af41f1b8a85f0755e] bpf: add helper for
retrieving current numa node id
git bisect bad 2d0e30c30f84d08dc16f0f2af41f1b8a85f0755e
# bad: [a10b91b8b81c29b87ff5a6d58c1402898337b956] Merge branch 'udpmem'
git bisect bad a10b91b8b81c29b87ff5a6d58c1402898337b956
# good: [850cbaddb52dfd4e0c7cabe2c168dd34b44ae0b9] udp: use it's own
memory accounting schema
git bisect good 850cbaddb52dfd4e0c7cabe2c168dd34b44ae0b9
# first bad commit: [a10b91b8b81c29b87ff5a6d58c1402898337b956] Merge
branch 'udpmem'
[ 112.472363] BUG: unable to handle kernel NULL pointer dereference
at (null)
[ 112.473360] IP: [<ffffffffb76f8031>] __sk_mem_raise_allocated+0x31/0x3f0
[ 112.474156] PGD 62a08067 [ 112.474455] PUD 2b8bf067
PMD 0 [ 112.474856]
[ 112.475054] Oops: 0002 [#1] SMP
[ 112.475431] Modules linked in: nf_conntrack_netlink udp_diag
tcp_diag inet_diag netlink_diag af_packet_diag unix_diag binfmt_misc
nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4
xt_conntrack nf_conntrack nfnetlink ip6table_filter ip6_tables ppdev
sunrpc crc32c_intel joydev virtio_balloon virtio_net i2c_piix4
parport_pc parport acpi_cpufreq tpm_tis tpm_tis_core tpm virtio_blk
serio_raw virtio_pci virtio_ring virtio ata_generic pata_acpi
[ 112.480594] CPU: 1 PID: 7405 Comm: socket_udplite Not tainted 4.8.0+ #84
[ 112.481377] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.9.1-1.fc24 04/01/2014
[ 112.482375] task: ffff928a5b5fa540 task.stack: ffffb3b484a0c000
[ 112.483059] RIP: 0010:[<ffffffffb76f8031>] [<ffffffffb76f8031>]
__sk_mem_raise_allocated+0x31/0x3f0
[ 112.484135] RSP: 0018:ffff928abfd03b18 EFLAGS: 00010296
[ 112.484758] RAX: 0000000000000001 RBX: ffff928aa293cfc0 RCX: 0000000000000001
[ 112.485585] RDX: 0000000000000000 RSI: 0000000000001000 RDI: ffff928aa293cfc0
[ 112.486414] RBP: ffff928abfd03b48 R08: 0de4c53600000000 R09: 0000000000000000
[ 112.487241] R10: 000000006226b971 R11: 0000000000000000 R12: ffff928aa293cfc0
[ 112.488064] R13: 0000000000000001 R14: ffffffffb7f0d5a0 R15: 0000000000001000
[ 112.488893] FS: 00007f058067a700(0000) GS:ffff928abfd00000(0000)
knlGS:0000000000000000
[ 112.489807] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 112.490447] CR2: 0000000000000000 CR3: 000000002b8f5000 CR4: 00000000000006e0
[ 112.491248] DR0: 00000000000100a0 DR1: 0000000000000000 DR2: 0000000000000000
[ 112.492025] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
[ 112.492808] Stack:
[ 112.493038] 0000000100000300 ffff928aa293cfc0 ffff928a651b9c00
0000000000000300
[ 112.493912] ffff928aa293d108 0000000000001000 ffff928abfd03b88
ffffffffb779e094
[ 112.494782] ffff928abfd03b70 ffff928a651b9c00 ffff928aa293cfc0
0000000000000000
[ 112.495653] Call Trace:
[ 112.495930] <IRQ> [ 112.496154] [<ffffffffb779e094>]
__udp_enqueue_schedule_skb+0xc4/0x170
[ 112.496896] [<ffffffffb77a15b4>] udp_queue_rcv_skb+0x1a4/0x5b0
[ 112.497551] [<ffffffffb77a1f3e>] __udp4_lib_rcv+0x57e/0xe30
[ 112.498173] [<ffffffffb77a2cfa>] udplite_rcv+0x1a/0x20
[ 112.498761] [<ffffffffb776799f>] ip_local_deliver_finish+0xdf/0x370
[ 112.499466] [<ffffffffb77678ef>] ? ip_local_deliver_finish+0x2f/0x370
[ 112.500184] [<ffffffffb77683c4>] ip_local_deliver+0x74/0x210
[ 112.500825] [<ffffffffb77683ec>] ? ip_local_deliver+0x9c/0x210
[ 112.501482] [<ffffffffb77678c0>] ? inet_del_offload+0x40/0x40
[ 112.502122] [<ffffffffb7767daa>] ip_rcv_finish+0x17a/0x540
[ 112.502749] [<ffffffffb77687f3>] ip_rcv+0x293/0x4d0
[ 112.503305] [<ffffffffb776882f>] ? ip_rcv+0x2cf/0x4d0
[ 112.503873] [<ffffffffb7767c30>] ? ip_local_deliver_finish+0x370/0x370
[ 112.504607] [<ffffffffb771683b>] __netif_receive_skb_core+0x34b/0xca0
[ 112.505327] [<ffffffffb77180e4>] ? process_backlog+0xd4/0x240
[ 112.505967] [<ffffffffb77180e4>] ? process_backlog+0xd4/0x240
[ 112.506617] [<ffffffffb77171a8>] __netif_receive_skb+0x18/0x60
[ 112.507277] [<ffffffffb7718088>] process_backlog+0x78/0x240
[ 112.507904] [<ffffffffb77180e4>] ? process_backlog+0xd4/0x240
[ 112.508552] [<ffffffffb7717e01>] net_rx_action+0x1d1/0x3e0
[ 112.509165] [<ffffffffb7873b3d>] __do_softirq+0xcd/0x471
[ 112.509765] [<ffffffffb776d312>] ? ip_finish_output2+0x242/0x640
[ 112.510446] [<ffffffffb7871ecc>] do_softirq_own_stack+0x1c/0x30
[ 112.511106] <EOI> [ 112.511336] [<ffffffffb709c956>]
do_softirq.part.14+0x46/0x70
[ 112.511990] [<ffffffffb709ca39>] __local_bh_enable_ip+0xb9/0xc0
[ 112.512661] [<ffffffffb776d33b>] ip_finish_output2+0x26b/0x640
[ 112.513319] [<ffffffffb776d177>] ? ip_finish_output2+0xa7/0x640
[ 112.513979] [<ffffffffb776e27f>] ip_finish_output+0x19f/0x330
[ 112.514627] [<ffffffffb776f533>] ip_output+0x83/0x270
[ 112.515204] [<ffffffffb776f55b>] ? ip_output+0xab/0x270
[ 112.515794] [<ffffffffb776e0e0>] ? ip_fragment.constprop.51+0x80/0x80
[ 112.516521] [<ffffffffb776e699>] ip_local_out+0x39/0x70
[ 112.517107] [<ffffffffb7770069>] ip_send_skb+0x19/0x40
[ 112.517689] [<ffffffffb779dd22>] udp_send_skb+0x172/0x260
[ 112.518299] [<ffffffffb779f4b0>] udp_sendmsg+0x340/0xb30
[ 112.518893] [<ffffffffb779de70>] ? udp_push_pending_frames+0x60/0x60
[ 112.519605] [<ffffffffb77aeff8>] inet_sendmsg+0xf8/0x1c0
[ 112.520197] [<ffffffffb77aef05>] ? inet_sendmsg+0x5/0x1c0
[ 112.520807] [<ffffffffb76f4b98>] sock_sendmsg+0x38/0x50
[ 112.521397] [<ffffffffb76f51b1>] SYSC_sendto+0x101/0x190
[ 112.521993] [<ffffffffb70efc0f>] ? up_read+0x1f/0x40
[ 112.522563] [<ffffffffb7054dfd>] ? __do_page_fault+0x26d/0x4f0
[ 112.523221] [<ffffffffb70f3f55>] ? trace_hardirqs_on_caller+0xf5/0x1b0
[ 112.523950] [<ffffffffb700201a>] ? trace_hardirqs_on_thunk+0x1a/0x1c
[ 112.524664] [<ffffffffb76f60fe>] SyS_sendto+0xe/0x10
[ 112.525230] [<ffffffffb7870e01>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 112.525939] Code: 48 89 e5 41 57 41 56 41 55 41 54 4c 63 ea 53 49
89 fc 41 89 f7 4c 89 e8 48 83 ec 08 4c 8b 77 28 44 89 6d d4 49 8b 96
d0 00 00 00 <f0> 48 0f c1 02 49 8d 5c 05 00 e9 41 00 00 00 49 8b 44 24
28 48
[ 112.528965] RIP [<ffffffffb76f8031>] __sk_mem_raise_allocated+0x31/0x3f0
[ 112.529732] RSP <ffff928abfd03b18>
[ 112.530122] CR2: 0000000000000000
[ 112.530504] ---[ end trace ed0c680ae4317de5 ]---
[ 112.531019] Kernel panic - not syncing: Fatal exception in interrupt
[ 112.550850] Kernel Offset: 0x36000000 from 0xffffffff81000000
(relocation rang
^ permalink raw reply
* Re: [PATCH v2 06/10] pinctrl: rockchip: add support for rk1108
From: Heiko Stuebner @ 2016-11-14 23:23 UTC (permalink / raw)
To: Andy Yan; +Cc: shawn.lin, linux-rockchip, linus.walleij, linux-gpio,
linux-kernel
In-Reply-To: <1479125447-24406-1-git-send-email-andy.yan@rock-chips.com>
Am Montag, 14. November 2016, 20:10:47 CET schrieb Andy Yan:
> This add pinctrl support for Rockchip RK1108 Soc.
>
> Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
still looks mostly good. I think I've now compared every register offset with
the TRM - they all look good. I've noticed two styling issues below, with
those fixed:
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
> ---
> Changes in v2:
> - add pull and drive-strength functionality
>
> drivers/pinctrl/pinctrl-rockchip.c | 87
> +++++++++++++++++++++++++++++++++++++- 1 file changed, 86 insertions(+), 1
> deletion(-)
>
> diff --git a/drivers/pinctrl/pinctrl-rockchip.c
> b/drivers/pinctrl/pinctrl-rockchip.c index 49bf7dc..fcc89fb 100644
> --- a/drivers/pinctrl/pinctrl-rockchip.c
> +++ b/drivers/pinctrl/pinctrl-rockchip.c
> @@ -59,6 +59,7 @@
> #define GPIO_LS_SYNC 0x60
>
> enum rockchip_pinctrl_type {
> + RK1108,
> RK2928,
> RK3066B,
> RK3188,
> @@ -624,6 +625,65 @@ static int rockchip_set_mux(struct rockchip_pin_bank
> *bank, int pin, int mux) return ret;
> }
>
> +#define RK1108_PULL_PMU_OFFSET 0x10
> +#define RK1108_PULL_OFFSET 0x110
> +#define RK1108_PULL_PINS_PER_REG 8
> +#define RK1108_PULL_BITS_PER_PIN 2
> +#define RK1108_PULL_BANK_STRIDE 16
> +
> +static void rk1108_calc_pull_reg_and_bit(struct rockchip_pin_bank *bank,
> + int pin_num, struct regmap **regmap,
> + int *reg, u8 *bit)
> +{
> + struct rockchip_pinctrl *info = bank->drvdata;
> +
> + /* The first 24 pins of the first bank are located in PMU */
> + if (bank->bank_num == 0) {
> + *regmap = info->regmap_pmu;
> + *reg = RK1108_PULL_PMU_OFFSET;
> + } else {
> + *reg = RK1108_PULL_OFFSET;
> + *regmap = info->regmap_base;
> + /* correct the offset, as we're starting with the 2nd bank */
> + *reg -= 0x10;
> + *reg += bank->bank_num * RK1108_PULL_BANK_STRIDE;
> + }
> +
> + *reg += ((pin_num / RK1108_PULL_PINS_PER_REG) * 4);
> + *bit = (pin_num % RK1108_PULL_PINS_PER_REG);
> + *bit *= RK1108_PULL_BITS_PER_PIN;
> +}
> +
> +#define RK1108_DRV_PMU_OFFSET 0x20
> +#define RK1108_DRV_GRF_OFFSET 0x210
> +#define RK1108_DRV_BITS_PER_PIN 2
> +#define RK1108_DRV_PINS_PER_REG 8
> +#define RK1108_DRV_BANK_STRIDE 16
styling nitpick, spaces instead of tabs between name and value. The pull
constants are correct though and only the drv constants need a fixup.
> +
> +static void rk1108_calc_drv_reg_and_bit(struct rockchip_pin_bank *bank,
> + int pin_num, struct regmap **regmap,
> + int *reg, u8 *bit)
> +{
> + struct rockchip_pinctrl *info = bank->drvdata;
> +
> + /* The first 24 pins of the first bank are located in PMU */
> + if (bank->bank_num == 0) {
> + *regmap = info->regmap_pmu;
> + *reg = RK1108_DRV_PMU_OFFSET;
> + } else {
> + *regmap = info->regmap_base;
> + *reg = RK1108_DRV_GRF_OFFSET;
> +
> + /* correct the offset, as we're starting with the 2nd bank */
> + *reg -= 0x10;
> + *reg += bank->bank_num * RK1108_DRV_BANK_STRIDE;
> + }
> +
> + *reg += ((pin_num / RK1108_DRV_PINS_PER_REG) * 4);
> + *bit = pin_num % RK1108_DRV_PINS_PER_REG;
> + *bit *= RK1108_DRV_BITS_PER_PIN;
> +}
> +
> #define RK2928_PULL_OFFSET 0x118
> #define RK2928_PULL_PINS_PER_REG 16
> #define RK2928_PULL_BANK_STRIDE 8
[...]
> @@ -1385,7 +1448,6 @@ static int rockchip_pinconf_set(struct pinctrl_dev
> *pctldev, unsigned int pin, for (i = 0; i < num_configs; i++) {
> param = pinconf_to_config_param(configs[i]);
> arg = pinconf_to_config_argument(configs[i]);
> -
unrelated change that should be removed.
> switch (param) {
> case PIN_CONFIG_BIAS_DISABLE:
> rc = rockchip_set_pull(bank, pin - bank->pin_base,
^ permalink raw reply
* Re: [RFC v2 3/8] iommu/dma: Allow MSI-only cookies
From: Auger Eric @ 2016-11-14 23:23 UTC (permalink / raw)
To: Robin Murphy, eric.auger.pro, christoffer.dall, marc.zyngier,
alex.williamson, will.deacon, joro, tglx, jason, linux-arm-kernel
Cc: drjones, kvm, punit.agrawal, linux-kernel, diana.craciun, iommu,
pranav.sawargaonkar
In-Reply-To: <5f93ebfd-edf4-0b5a-b54a-b96937a588b8@arm.com>
Hi Robin,
On 14/11/2016 13:36, Robin Murphy wrote:
> On 04/11/16 11:24, Eric Auger wrote:
>> From: Robin Murphy <robin.murphy@arm.com>
>>
>> IOMMU domain users such as VFIO face a similar problem to DMA API ops
>> with regard to mapping MSI messages in systems where the MSI write is
>> subject to IOMMU translation. With the relevant infrastructure now in
>> place for managed DMA domains, it's actually really simple for other
>> users to piggyback off that and reap the benefits without giving up
>> their own IOVA management, and without having to reinvent their own
>> wheel in the MSI layer.
>>
>> Allow such users to opt into automatic MSI remapping by dedicating a
>> region of their IOVA space to a managed cookie.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>
> OK, following the discussion elsewhere I've had a go at the less stupid,
> but more involved, version. Thoughts?
Conceptually I don't have any major objection with the minimalist
allocation scheme all the more so it follows Joerg's guidance. Maybe the
only thing is we do not check we don't overshoot the reserved msi-region.
Besides there are 2 issues reported below.
>
> Robin.
>
> ----->8-----
> From: Robin Murphy <robin.murphy@arm.com>
> Subject: [RFC PATCH] iommu/dma: Allow MSI-only cookies
>
> IOMMU domain users such as VFIO face a similar problem to DMA API ops
> with regard to mapping MSI messages in systems where the MSI write is
> subject to IOMMU translation. With the relevant infrastructure now in
> place for managed DMA domains, it's actually really simple for other
> users to piggyback off that and reap the benefits without giving up
> their own IOVA management, and without having to reinvent their own
> wheel in the MSI layer.
>
> Allow such users to opt into automatic MSI remapping by dedicating a
> region of their IOVA space to a managed cookie, and extend the mapping
> routine to implement a trivial linear allocator in such cases, to avoid
> the needless overhead of a full-blown IOVA domain.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/dma-iommu.c | 118 ++++++++++++++++++++++++++++++++++++----------
> include/linux/dma-iommu.h | 6 +++
> 2 files changed, 100 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index c5ab8667e6f2..33d66a8273c6 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -37,10 +37,19 @@ struct iommu_dma_msi_page {
> phys_addr_t phys;
> };
>
> +enum iommu_dma_cookie_type {
> + IOMMU_DMA_IOVA_COOKIE,
> + IOMMU_DMA_MSI_COOKIE,
> +};
> +
> struct iommu_dma_cookie {
> - struct iova_domain iovad;
> - struct list_head msi_page_list;
> - spinlock_t msi_lock;
> + union {
> + struct iova_domain iovad;
> + dma_addr_t msi_iova;
> + };
> + struct list_head msi_page_list;
> + spinlock_t msi_lock;
> + enum iommu_dma_cookie_type type;
> };
>
> static inline struct iova_domain *cookie_iovad(struct iommu_domain *domain)
> @@ -53,6 +62,19 @@ int iommu_dma_init(void)
> return iova_cache_get();
> }
>
> +static struct iommu_dma_cookie *__cookie_alloc(enum iommu_dma_cookie_type type)
> +{
> + struct iommu_dma_cookie *cookie;
> +
> + cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
> + if (cookie) {
> + spin_lock_init(&cookie->msi_lock);
> + INIT_LIST_HEAD(&cookie->msi_page_list);
> + cookie->type = type;
> + }
> + return cookie;
> +}
> +
> /**
> * iommu_get_dma_cookie - Acquire DMA-API resources for a domain
> * @domain: IOMMU domain to prepare for DMA-API usage
> @@ -62,25 +84,53 @@ int iommu_dma_init(void)
> */
> int iommu_get_dma_cookie(struct iommu_domain *domain)
> {
> - struct iommu_dma_cookie *cookie;
> -
> if (domain->iova_cookie)
> return -EEXIST;
>
> - cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
> - if (!cookie)
> + domain->iova_cookie = __cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
> + if (!domain->iova_cookie)
> return -ENOMEM;
>
> - spin_lock_init(&cookie->msi_lock);
> - INIT_LIST_HEAD(&cookie->msi_page_list);
> - domain->iova_cookie = cookie;
> return 0;
> }
> EXPORT_SYMBOL(iommu_get_dma_cookie);
>
> /**
> + * iommu_get_msi_cookie - Acquire just MSI remapping resources
> + * @domain: IOMMU domain to prepare
> + * @base: Start address of IOVA region for MSI mappings
> + *
> + * Users who manage their own IOVA allocation and do not want DMA API support,
> + * but would still like to take advantage of automatic MSI remapping, can use
> + * this to initialise their own domain appropriately. Users should reserve a
> + * contiguous IOVA region, starting at @base, large enough to accommodate the
> + * number of PAGE_SIZE mappings necessary to cover every MSI doorbell address
> + * used by the devices attached to @domain.
> + */
> +int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
> +{
> + struct iommu_dma_cookie *cookie;
> +
> + if (domain->type != IOMMU_DOMAIN_UNMANAGED)
> + return -EINVAL;
> +
> + if (domain->iova_cookie)
> + return -EEXIST;
> +
> + cookie = __cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
must be IOMMU_DMA_MSI_COOKIE else it has bad consequences.
> + if (!cookie)
> + return -ENOMEM;
> +
> + cookie->msi_iova = base;
> + domain->iova_cookie = cookie;
> + return 0;
> +}
> +EXPORT_SYMBOL(iommu_get_msi_cookie);
> +
> +/**
> * iommu_put_dma_cookie - Release a domain's DMA mapping resources
> - * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie()
> + * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie() or
> + * iommu_get_msi_cookie()
> *
> * IOMMU drivers should normally call this from their domain_free callback.
> */
> @@ -92,7 +142,7 @@ void iommu_put_dma_cookie(struct iommu_domain *domain)
> if (!cookie)
> return;
>
> - if (cookie->iovad.granule)
> + if (cookie->type == IOMMU_DMA_IOVA_COOKIE && cookie->iovad.granule)
> put_iova_domain(&cookie->iovad);
>
> list_for_each_entry_safe(msi, tmp, &cookie->msi_page_list, list) {
> @@ -137,11 +187,12 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
> int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
> u64 size, struct device *dev)
> {
> - struct iova_domain *iovad = cookie_iovad(domain);
> + struct iommu_dma_cookie *cookie = domain->iova_cookie;
> + struct iova_domain *iovad = &cookie->iovad;
> unsigned long order, base_pfn, end_pfn;
>
> - if (!iovad)
> - return -ENODEV;
> + if (!cookie || cookie->type != IOMMU_DMA_IOVA_COOKIE)
> + return -EINVAL;
>
> /* Use the smallest supported page size for IOVA granularity */
> order = __ffs(domain->pgsize_bitmap);
> @@ -644,11 +695,21 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
> {
> struct iommu_dma_cookie *cookie = domain->iova_cookie;
> struct iommu_dma_msi_page *msi_page;
> - struct iova_domain *iovad = &cookie->iovad;
> + struct iova_domain *iovad;
> struct iova *iova;
> int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
> + size_t size;
> +
> + if (cookie->type == IOMMU_DMA_IOVA_COOKIE) {
> + iovad = &cookie->iovad;
> + size = iovad->granule;
> + } else {
> + iovad = NULL;
> + size = PAGE_SIZE;
> + }
> +
> + msi_addr &= ~(phys_addr_t)(size - 1);
>
> - msi_addr &= ~(phys_addr_t)iova_mask(iovad);
> list_for_each_entry(msi_page, &cookie->msi_page_list, list)
> if (msi_page->phys == msi_addr)
> return msi_page;
> @@ -657,13 +718,18 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
> if (!msi_page)
> return NULL;
>
> - iova = __alloc_iova(domain, iovad->granule, dma_get_mask(dev));
> - if (!iova)
> - goto out_free_page;
> -
> msi_page->phys = msi_addr;
> - msi_page->iova = iova_dma_addr(iovad, iova);
> - if (iommu_map(domain, msi_page->iova, msi_addr, iovad->granule, prot))
> + if (iovad) {
> + iova = __alloc_iova(domain, size, dma_get_mask(dev));
> + if (!iova)
> + goto out_free_page;
> + msi_page->iova = iova_dma_addr(iovad, iova);
> + } else {
> + msi_page->iova = cookie->msi_iova;
> + cookie->msi_iova += size;
> + }
> +
> + if (iommu_map(domain, msi_page->iova, msi_addr, size, prot))
> goto out_free_iova;
>
> INIT_LIST_HEAD(&msi_page->list);
> @@ -671,7 +737,10 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
> return msi_page;
>
> out_free_iova:
> - __free_iova(iovad, iova);
> + if (iovad)
> + __free_iova(iovad, iova);
> + else
> + cookie->msi_iova -= size;
> out_free_page:
> kfree(msi_page);
> return NULL;
> @@ -716,3 +785,4 @@ void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg)
> msg->address_lo += lower_32_bits(msi_page->iova);
> }
> }
in iommu_dma_map_msi_msg there is another issue at:
msg->address_lo &= iova_mask(&cookie->iovad);
iovad might not exist
Thanks
Eric
> +
> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
> index 32c589062bd9..d69932474576 100644
> --- a/include/linux/dma-iommu.h
> +++ b/include/linux/dma-iommu.h
> @@ -27,6 +27,7 @@ int iommu_dma_init(void);
>
> /* Domain management interface for IOMMU drivers */
> int iommu_get_dma_cookie(struct iommu_domain *domain);
> +int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base);
> void iommu_put_dma_cookie(struct iommu_domain *domain);
>
> /* Setup call for arch DMA mapping code */
> @@ -82,6 +83,11 @@ static inline int iommu_get_dma_cookie(struct iommu_domain *domain)
> return -ENODEV;
> }
>
> +static inline int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
> +{
> + return -ENODEV;
> +}
> +
> static inline void iommu_put_dma_cookie(struct iommu_domain *domain)
> {
> }
>
^ permalink raw reply
* Re: [PATCH 1/4] fpga mgr: Introduce FPGA capabilities
From: atull @ 2016-11-14 23:23 UTC (permalink / raw)
To: Moritz Fischer
Cc: Linux Kernel Mailing List, moritz.fischer.private, Michal Simek,
Sören Brinkmann, linux-arm-kernel, Julia Cartwright
In-Reply-To: <CAAtXAHeX08ZxGceXvqkdNwsVHdOpczxx5fvFapLy74n1_4R-CA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3009 bytes --]
On Mon, 14 Nov 2016, Moritz Fischer wrote:
Hi Moritz,
> Hi Alan,
>
> On Mon, Nov 14, 2016 at 6:06 AM, atull <atull@opensource.altera.com> wrote:
> > On Mon, 7 Nov 2016, Moritz Fischer wrote:
> >
> >> Add FPGA capabilities as a way to express the capabilities
> >> of a given FPGA manager.
> >>
> >> Removes code duplication by comparing the low-level driver's
> >> capabilities at the framework level rather than having each driver
> >> check for supported operations in the write_init() callback.
> >>
> >> This allows for extending with additional capabilities, similar
> >> to the the dmaengine framework's implementation.
> >>
> >> Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
> >> Cc: Alan Tull <atull@opensource.altera.com>
> >> Cc: Michal Simek <michal.simek@xilinx.com>
> >> Cc: Sören Brinkmann <soren.brinkmann@xilinx.com>
> >> Cc: linux-kernel@vger.kernel.org
> >> Cc: linux-arm-kernel@lists.infradead.org
> >> ---
> >>
> >> Changes from RFC:
> >> * in the RFC the caps weren't actually stored into the struct fpga_mgr
> >>
> >> Note:
> >>
> >> If people disagree on the typedef being a 'false positive' I can fix
> >> that in a future rev of the patchset.
> >>
> >> Thanks,
> >>
> >> Moritz
> >>
> >> ---
> >> drivers/fpga/fpga-mgr.c | 15 ++++++++++++++
> >> drivers/fpga/socfpga.c | 10 +++++-----
> >> drivers/fpga/zynq-fpga.c | 7 ++++++-
> >> include/linux/fpga/fpga-mgr.h | 46 ++++++++++++++++++++++++++++++++++++++++++-
> >> 4 files changed, 71 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> >> index 953dc91..ed57c17 100644
> >> --- a/drivers/fpga/fpga-mgr.c
> >> +++ b/drivers/fpga/fpga-mgr.c
> >> @@ -49,6 +49,18 @@ int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags, const char *buf,
> >> struct device *dev = &mgr->dev;
> >> int ret;
> >>
> >> + if (flags & FPGA_MGR_PARTIAL_RECONFIG &&
> >> + !fpga_mgr_has_cap(FPGA_MGR_CAP_PARTIAL_RECONF, mgr->caps)) {
> >> + dev_err(dev, "Partial reconfiguration not supported\n");
> >> + return -ENOTSUPP;
> >> + }
> >> +
> >> + if (flags & FPGA_MGR_FULL_RECONFIG &&
> >> + !fpga_mgr_has_cap(FPGA_MGR_CAP_FULL_RECONF, mgr->caps)) {
> >> + dev_err(dev, "Full reconfiguration not supported\n");
> >> + return -ENOTSUPP;
> >> + }
> >> +
> >
> > Could you move the checks to their own function like
> > 'fpga_mgr_check_caps()' or something? I really like it if we can keep
> > the functions short, like a screen or so where it's practicle to do
> > so and I could see the number of caps growing here.
>
> Absolutely. Great suggestion.
>
> > The only counter argument I could think of is if a cap affects the sequence
> > in this function. Hmmm...
>
> Oh you mean the cap being there affecting the sequence in *this* function?
> I'd suggest we address that when we run into a cap that requires this.
Yes, I agree.
Alan
>
> Cheers,
>
> Moritz
>
^ permalink raw reply
* [RFC v2 3/8] iommu/dma: Allow MSI-only cookies
From: Auger Eric @ 2016-11-14 23:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5f93ebfd-edf4-0b5a-b54a-b96937a588b8@arm.com>
Hi Robin,
On 14/11/2016 13:36, Robin Murphy wrote:
> On 04/11/16 11:24, Eric Auger wrote:
>> From: Robin Murphy <robin.murphy@arm.com>
>>
>> IOMMU domain users such as VFIO face a similar problem to DMA API ops
>> with regard to mapping MSI messages in systems where the MSI write is
>> subject to IOMMU translation. With the relevant infrastructure now in
>> place for managed DMA domains, it's actually really simple for other
>> users to piggyback off that and reap the benefits without giving up
>> their own IOVA management, and without having to reinvent their own
>> wheel in the MSI layer.
>>
>> Allow such users to opt into automatic MSI remapping by dedicating a
>> region of their IOVA space to a managed cookie.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>
> OK, following the discussion elsewhere I've had a go at the less stupid,
> but more involved, version. Thoughts?
Conceptually I don't have any major objection with the minimalist
allocation scheme all the more so it follows Joerg's guidance. Maybe the
only thing is we do not check we don't overshoot the reserved msi-region.
Besides there are 2 issues reported below.
>
> Robin.
>
> ----->8-----
> From: Robin Murphy <robin.murphy@arm.com>
> Subject: [RFC PATCH] iommu/dma: Allow MSI-only cookies
>
> IOMMU domain users such as VFIO face a similar problem to DMA API ops
> with regard to mapping MSI messages in systems where the MSI write is
> subject to IOMMU translation. With the relevant infrastructure now in
> place for managed DMA domains, it's actually really simple for other
> users to piggyback off that and reap the benefits without giving up
> their own IOVA management, and without having to reinvent their own
> wheel in the MSI layer.
>
> Allow such users to opt into automatic MSI remapping by dedicating a
> region of their IOVA space to a managed cookie, and extend the mapping
> routine to implement a trivial linear allocator in such cases, to avoid
> the needless overhead of a full-blown IOVA domain.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/dma-iommu.c | 118 ++++++++++++++++++++++++++++++++++++----------
> include/linux/dma-iommu.h | 6 +++
> 2 files changed, 100 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index c5ab8667e6f2..33d66a8273c6 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -37,10 +37,19 @@ struct iommu_dma_msi_page {
> phys_addr_t phys;
> };
>
> +enum iommu_dma_cookie_type {
> + IOMMU_DMA_IOVA_COOKIE,
> + IOMMU_DMA_MSI_COOKIE,
> +};
> +
> struct iommu_dma_cookie {
> - struct iova_domain iovad;
> - struct list_head msi_page_list;
> - spinlock_t msi_lock;
> + union {
> + struct iova_domain iovad;
> + dma_addr_t msi_iova;
> + };
> + struct list_head msi_page_list;
> + spinlock_t msi_lock;
> + enum iommu_dma_cookie_type type;
> };
>
> static inline struct iova_domain *cookie_iovad(struct iommu_domain *domain)
> @@ -53,6 +62,19 @@ int iommu_dma_init(void)
> return iova_cache_get();
> }
>
> +static struct iommu_dma_cookie *__cookie_alloc(enum iommu_dma_cookie_type type)
> +{
> + struct iommu_dma_cookie *cookie;
> +
> + cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
> + if (cookie) {
> + spin_lock_init(&cookie->msi_lock);
> + INIT_LIST_HEAD(&cookie->msi_page_list);
> + cookie->type = type;
> + }
> + return cookie;
> +}
> +
> /**
> * iommu_get_dma_cookie - Acquire DMA-API resources for a domain
> * @domain: IOMMU domain to prepare for DMA-API usage
> @@ -62,25 +84,53 @@ int iommu_dma_init(void)
> */
> int iommu_get_dma_cookie(struct iommu_domain *domain)
> {
> - struct iommu_dma_cookie *cookie;
> -
> if (domain->iova_cookie)
> return -EEXIST;
>
> - cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
> - if (!cookie)
> + domain->iova_cookie = __cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
> + if (!domain->iova_cookie)
> return -ENOMEM;
>
> - spin_lock_init(&cookie->msi_lock);
> - INIT_LIST_HEAD(&cookie->msi_page_list);
> - domain->iova_cookie = cookie;
> return 0;
> }
> EXPORT_SYMBOL(iommu_get_dma_cookie);
>
> /**
> + * iommu_get_msi_cookie - Acquire just MSI remapping resources
> + * @domain: IOMMU domain to prepare
> + * @base: Start address of IOVA region for MSI mappings
> + *
> + * Users who manage their own IOVA allocation and do not want DMA API support,
> + * but would still like to take advantage of automatic MSI remapping, can use
> + * this to initialise their own domain appropriately. Users should reserve a
> + * contiguous IOVA region, starting at @base, large enough to accommodate the
> + * number of PAGE_SIZE mappings necessary to cover every MSI doorbell address
> + * used by the devices attached to @domain.
> + */
> +int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
> +{
> + struct iommu_dma_cookie *cookie;
> +
> + if (domain->type != IOMMU_DOMAIN_UNMANAGED)
> + return -EINVAL;
> +
> + if (domain->iova_cookie)
> + return -EEXIST;
> +
> + cookie = __cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
must be IOMMU_DMA_MSI_COOKIE else it has bad consequences.
> + if (!cookie)
> + return -ENOMEM;
> +
> + cookie->msi_iova = base;
> + domain->iova_cookie = cookie;
> + return 0;
> +}
> +EXPORT_SYMBOL(iommu_get_msi_cookie);
> +
> +/**
> * iommu_put_dma_cookie - Release a domain's DMA mapping resources
> - * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie()
> + * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie() or
> + * iommu_get_msi_cookie()
> *
> * IOMMU drivers should normally call this from their domain_free callback.
> */
> @@ -92,7 +142,7 @@ void iommu_put_dma_cookie(struct iommu_domain *domain)
> if (!cookie)
> return;
>
> - if (cookie->iovad.granule)
> + if (cookie->type == IOMMU_DMA_IOVA_COOKIE && cookie->iovad.granule)
> put_iova_domain(&cookie->iovad);
>
> list_for_each_entry_safe(msi, tmp, &cookie->msi_page_list, list) {
> @@ -137,11 +187,12 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
> int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
> u64 size, struct device *dev)
> {
> - struct iova_domain *iovad = cookie_iovad(domain);
> + struct iommu_dma_cookie *cookie = domain->iova_cookie;
> + struct iova_domain *iovad = &cookie->iovad;
> unsigned long order, base_pfn, end_pfn;
>
> - if (!iovad)
> - return -ENODEV;
> + if (!cookie || cookie->type != IOMMU_DMA_IOVA_COOKIE)
> + return -EINVAL;
>
> /* Use the smallest supported page size for IOVA granularity */
> order = __ffs(domain->pgsize_bitmap);
> @@ -644,11 +695,21 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
> {
> struct iommu_dma_cookie *cookie = domain->iova_cookie;
> struct iommu_dma_msi_page *msi_page;
> - struct iova_domain *iovad = &cookie->iovad;
> + struct iova_domain *iovad;
> struct iova *iova;
> int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
> + size_t size;
> +
> + if (cookie->type == IOMMU_DMA_IOVA_COOKIE) {
> + iovad = &cookie->iovad;
> + size = iovad->granule;
> + } else {
> + iovad = NULL;
> + size = PAGE_SIZE;
> + }
> +
> + msi_addr &= ~(phys_addr_t)(size - 1);
>
> - msi_addr &= ~(phys_addr_t)iova_mask(iovad);
> list_for_each_entry(msi_page, &cookie->msi_page_list, list)
> if (msi_page->phys == msi_addr)
> return msi_page;
> @@ -657,13 +718,18 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
> if (!msi_page)
> return NULL;
>
> - iova = __alloc_iova(domain, iovad->granule, dma_get_mask(dev));
> - if (!iova)
> - goto out_free_page;
> -
> msi_page->phys = msi_addr;
> - msi_page->iova = iova_dma_addr(iovad, iova);
> - if (iommu_map(domain, msi_page->iova, msi_addr, iovad->granule, prot))
> + if (iovad) {
> + iova = __alloc_iova(domain, size, dma_get_mask(dev));
> + if (!iova)
> + goto out_free_page;
> + msi_page->iova = iova_dma_addr(iovad, iova);
> + } else {
> + msi_page->iova = cookie->msi_iova;
> + cookie->msi_iova += size;
> + }
> +
> + if (iommu_map(domain, msi_page->iova, msi_addr, size, prot))
> goto out_free_iova;
>
> INIT_LIST_HEAD(&msi_page->list);
> @@ -671,7 +737,10 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
> return msi_page;
>
> out_free_iova:
> - __free_iova(iovad, iova);
> + if (iovad)
> + __free_iova(iovad, iova);
> + else
> + cookie->msi_iova -= size;
> out_free_page:
> kfree(msi_page);
> return NULL;
> @@ -716,3 +785,4 @@ void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg)
> msg->address_lo += lower_32_bits(msi_page->iova);
> }
> }
in iommu_dma_map_msi_msg there is another issue at:
msg->address_lo &= iova_mask(&cookie->iovad);
iovad might not exist
Thanks
Eric
> +
> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
> index 32c589062bd9..d69932474576 100644
> --- a/include/linux/dma-iommu.h
> +++ b/include/linux/dma-iommu.h
> @@ -27,6 +27,7 @@ int iommu_dma_init(void);
>
> /* Domain management interface for IOMMU drivers */
> int iommu_get_dma_cookie(struct iommu_domain *domain);
> +int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base);
> void iommu_put_dma_cookie(struct iommu_domain *domain);
>
> /* Setup call for arch DMA mapping code */
> @@ -82,6 +83,11 @@ static inline int iommu_get_dma_cookie(struct iommu_domain *domain)
> return -ENODEV;
> }
>
> +static inline int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
> +{
> + return -ENODEV;
> +}
> +
> static inline void iommu_put_dma_cookie(struct iommu_domain *domain)
> {
> }
>
^ permalink raw reply
* Re: [RFC v2 3/8] iommu/dma: Allow MSI-only cookies
From: Auger Eric @ 2016-11-14 23:23 UTC (permalink / raw)
To: Robin Murphy, eric.auger.pro-Re5JQEeQqe8AvxtiuMwx3w,
christoffer.dall-QSEj5FYQhm4dnm+yROfE0A, marc.zyngier-5wv7dgnIgG8,
alex.williamson-H+wXaHxf7aLQT0dZR+AlfA, will.deacon-5wv7dgnIgG8,
joro-zLv9SwRftAIdnm+yROfE0A, tglx-hfZtesqFncYOwBW4kG4KsQ,
jason-NLaQJdtUoK4Be96aLqz0jA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: drjones-H+wXaHxf7aLQT0dZR+AlfA, kvm-u79uwXL29TY76Z2rM5mHXA,
punit.agrawal-5wv7dgnIgG8, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
pranav.sawargaonkar-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <5f93ebfd-edf4-0b5a-b54a-b96937a588b8-5wv7dgnIgG8@public.gmane.org>
Hi Robin,
On 14/11/2016 13:36, Robin Murphy wrote:
> On 04/11/16 11:24, Eric Auger wrote:
>> From: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
>>
>> IOMMU domain users such as VFIO face a similar problem to DMA API ops
>> with regard to mapping MSI messages in systems where the MSI write is
>> subject to IOMMU translation. With the relevant infrastructure now in
>> place for managed DMA domains, it's actually really simple for other
>> users to piggyback off that and reap the benefits without giving up
>> their own IOVA management, and without having to reinvent their own
>> wheel in the MSI layer.
>>
>> Allow such users to opt into automatic MSI remapping by dedicating a
>> region of their IOVA space to a managed cookie.
>>
>> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
>> Signed-off-by: Eric Auger <eric.auger-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>
> OK, following the discussion elsewhere I've had a go at the less stupid,
> but more involved, version. Thoughts?
Conceptually I don't have any major objection with the minimalist
allocation scheme all the more so it follows Joerg's guidance. Maybe the
only thing is we do not check we don't overshoot the reserved msi-region.
Besides there are 2 issues reported below.
>
> Robin.
>
> ----->8-----
> From: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> Subject: [RFC PATCH] iommu/dma: Allow MSI-only cookies
>
> IOMMU domain users such as VFIO face a similar problem to DMA API ops
> with regard to mapping MSI messages in systems where the MSI write is
> subject to IOMMU translation. With the relevant infrastructure now in
> place for managed DMA domains, it's actually really simple for other
> users to piggyback off that and reap the benefits without giving up
> their own IOVA management, and without having to reinvent their own
> wheel in the MSI layer.
>
> Allow such users to opt into automatic MSI remapping by dedicating a
> region of their IOVA space to a managed cookie, and extend the mapping
> routine to implement a trivial linear allocator in such cases, to avoid
> the needless overhead of a full-blown IOVA domain.
>
> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> ---
> drivers/iommu/dma-iommu.c | 118 ++++++++++++++++++++++++++++++++++++----------
> include/linux/dma-iommu.h | 6 +++
> 2 files changed, 100 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index c5ab8667e6f2..33d66a8273c6 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -37,10 +37,19 @@ struct iommu_dma_msi_page {
> phys_addr_t phys;
> };
>
> +enum iommu_dma_cookie_type {
> + IOMMU_DMA_IOVA_COOKIE,
> + IOMMU_DMA_MSI_COOKIE,
> +};
> +
> struct iommu_dma_cookie {
> - struct iova_domain iovad;
> - struct list_head msi_page_list;
> - spinlock_t msi_lock;
> + union {
> + struct iova_domain iovad;
> + dma_addr_t msi_iova;
> + };
> + struct list_head msi_page_list;
> + spinlock_t msi_lock;
> + enum iommu_dma_cookie_type type;
> };
>
> static inline struct iova_domain *cookie_iovad(struct iommu_domain *domain)
> @@ -53,6 +62,19 @@ int iommu_dma_init(void)
> return iova_cache_get();
> }
>
> +static struct iommu_dma_cookie *__cookie_alloc(enum iommu_dma_cookie_type type)
> +{
> + struct iommu_dma_cookie *cookie;
> +
> + cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
> + if (cookie) {
> + spin_lock_init(&cookie->msi_lock);
> + INIT_LIST_HEAD(&cookie->msi_page_list);
> + cookie->type = type;
> + }
> + return cookie;
> +}
> +
> /**
> * iommu_get_dma_cookie - Acquire DMA-API resources for a domain
> * @domain: IOMMU domain to prepare for DMA-API usage
> @@ -62,25 +84,53 @@ int iommu_dma_init(void)
> */
> int iommu_get_dma_cookie(struct iommu_domain *domain)
> {
> - struct iommu_dma_cookie *cookie;
> -
> if (domain->iova_cookie)
> return -EEXIST;
>
> - cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
> - if (!cookie)
> + domain->iova_cookie = __cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
> + if (!domain->iova_cookie)
> return -ENOMEM;
>
> - spin_lock_init(&cookie->msi_lock);
> - INIT_LIST_HEAD(&cookie->msi_page_list);
> - domain->iova_cookie = cookie;
> return 0;
> }
> EXPORT_SYMBOL(iommu_get_dma_cookie);
>
> /**
> + * iommu_get_msi_cookie - Acquire just MSI remapping resources
> + * @domain: IOMMU domain to prepare
> + * @base: Start address of IOVA region for MSI mappings
> + *
> + * Users who manage their own IOVA allocation and do not want DMA API support,
> + * but would still like to take advantage of automatic MSI remapping, can use
> + * this to initialise their own domain appropriately. Users should reserve a
> + * contiguous IOVA region, starting at @base, large enough to accommodate the
> + * number of PAGE_SIZE mappings necessary to cover every MSI doorbell address
> + * used by the devices attached to @domain.
> + */
> +int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
> +{
> + struct iommu_dma_cookie *cookie;
> +
> + if (domain->type != IOMMU_DOMAIN_UNMANAGED)
> + return -EINVAL;
> +
> + if (domain->iova_cookie)
> + return -EEXIST;
> +
> + cookie = __cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
must be IOMMU_DMA_MSI_COOKIE else it has bad consequences.
> + if (!cookie)
> + return -ENOMEM;
> +
> + cookie->msi_iova = base;
> + domain->iova_cookie = cookie;
> + return 0;
> +}
> +EXPORT_SYMBOL(iommu_get_msi_cookie);
> +
> +/**
> * iommu_put_dma_cookie - Release a domain's DMA mapping resources
> - * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie()
> + * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie() or
> + * iommu_get_msi_cookie()
> *
> * IOMMU drivers should normally call this from their domain_free callback.
> */
> @@ -92,7 +142,7 @@ void iommu_put_dma_cookie(struct iommu_domain *domain)
> if (!cookie)
> return;
>
> - if (cookie->iovad.granule)
> + if (cookie->type == IOMMU_DMA_IOVA_COOKIE && cookie->iovad.granule)
> put_iova_domain(&cookie->iovad);
>
> list_for_each_entry_safe(msi, tmp, &cookie->msi_page_list, list) {
> @@ -137,11 +187,12 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
> int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
> u64 size, struct device *dev)
> {
> - struct iova_domain *iovad = cookie_iovad(domain);
> + struct iommu_dma_cookie *cookie = domain->iova_cookie;
> + struct iova_domain *iovad = &cookie->iovad;
> unsigned long order, base_pfn, end_pfn;
>
> - if (!iovad)
> - return -ENODEV;
> + if (!cookie || cookie->type != IOMMU_DMA_IOVA_COOKIE)
> + return -EINVAL;
>
> /* Use the smallest supported page size for IOVA granularity */
> order = __ffs(domain->pgsize_bitmap);
> @@ -644,11 +695,21 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
> {
> struct iommu_dma_cookie *cookie = domain->iova_cookie;
> struct iommu_dma_msi_page *msi_page;
> - struct iova_domain *iovad = &cookie->iovad;
> + struct iova_domain *iovad;
> struct iova *iova;
> int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
> + size_t size;
> +
> + if (cookie->type == IOMMU_DMA_IOVA_COOKIE) {
> + iovad = &cookie->iovad;
> + size = iovad->granule;
> + } else {
> + iovad = NULL;
> + size = PAGE_SIZE;
> + }
> +
> + msi_addr &= ~(phys_addr_t)(size - 1);
>
> - msi_addr &= ~(phys_addr_t)iova_mask(iovad);
> list_for_each_entry(msi_page, &cookie->msi_page_list, list)
> if (msi_page->phys == msi_addr)
> return msi_page;
> @@ -657,13 +718,18 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
> if (!msi_page)
> return NULL;
>
> - iova = __alloc_iova(domain, iovad->granule, dma_get_mask(dev));
> - if (!iova)
> - goto out_free_page;
> -
> msi_page->phys = msi_addr;
> - msi_page->iova = iova_dma_addr(iovad, iova);
> - if (iommu_map(domain, msi_page->iova, msi_addr, iovad->granule, prot))
> + if (iovad) {
> + iova = __alloc_iova(domain, size, dma_get_mask(dev));
> + if (!iova)
> + goto out_free_page;
> + msi_page->iova = iova_dma_addr(iovad, iova);
> + } else {
> + msi_page->iova = cookie->msi_iova;
> + cookie->msi_iova += size;
> + }
> +
> + if (iommu_map(domain, msi_page->iova, msi_addr, size, prot))
> goto out_free_iova;
>
> INIT_LIST_HEAD(&msi_page->list);
> @@ -671,7 +737,10 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
> return msi_page;
>
> out_free_iova:
> - __free_iova(iovad, iova);
> + if (iovad)
> + __free_iova(iovad, iova);
> + else
> + cookie->msi_iova -= size;
> out_free_page:
> kfree(msi_page);
> return NULL;
> @@ -716,3 +785,4 @@ void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg)
> msg->address_lo += lower_32_bits(msi_page->iova);
> }
> }
in iommu_dma_map_msi_msg there is another issue at:
msg->address_lo &= iova_mask(&cookie->iovad);
iovad might not exist
Thanks
Eric
> +
> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
> index 32c589062bd9..d69932474576 100644
> --- a/include/linux/dma-iommu.h
> +++ b/include/linux/dma-iommu.h
> @@ -27,6 +27,7 @@ int iommu_dma_init(void);
>
> /* Domain management interface for IOMMU drivers */
> int iommu_get_dma_cookie(struct iommu_domain *domain);
> +int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base);
> void iommu_put_dma_cookie(struct iommu_domain *domain);
>
> /* Setup call for arch DMA mapping code */
> @@ -82,6 +83,11 @@ static inline int iommu_get_dma_cookie(struct iommu_domain *domain)
> return -ENODEV;
> }
>
> +static inline int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
> +{
> + return -ENODEV;
> +}
> +
> static inline void iommu_put_dma_cookie(struct iommu_domain *domain)
> {
> }
>
^ permalink raw reply
* [PATCH 1/4] fpga mgr: Introduce FPGA capabilities
From: atull @ 2016-11-14 23:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAtXAHeX08ZxGceXvqkdNwsVHdOpczxx5fvFapLy74n1_4R-CA@mail.gmail.com>
On Mon, 14 Nov 2016, Moritz Fischer wrote:
Hi Moritz,
> Hi Alan,
>
> On Mon, Nov 14, 2016 at 6:06 AM, atull <atull@opensource.altera.com> wrote:
> > On Mon, 7 Nov 2016, Moritz Fischer wrote:
> >
> >> Add FPGA capabilities as a way to express the capabilities
> >> of a given FPGA manager.
> >>
> >> Removes code duplication by comparing the low-level driver's
> >> capabilities at the framework level rather than having each driver
> >> check for supported operations in the write_init() callback.
> >>
> >> This allows for extending with additional capabilities, similar
> >> to the the dmaengine framework's implementation.
> >>
> >> Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
> >> Cc: Alan Tull <atull@opensource.altera.com>
> >> Cc: Michal Simek <michal.simek@xilinx.com>
> >> Cc: S?ren Brinkmann <soren.brinkmann@xilinx.com>
> >> Cc: linux-kernel at vger.kernel.org
> >> Cc: linux-arm-kernel at lists.infradead.org
> >> ---
> >>
> >> Changes from RFC:
> >> * in the RFC the caps weren't actually stored into the struct fpga_mgr
> >>
> >> Note:
> >>
> >> If people disagree on the typedef being a 'false positive' I can fix
> >> that in a future rev of the patchset.
> >>
> >> Thanks,
> >>
> >> Moritz
> >>
> >> ---
> >> drivers/fpga/fpga-mgr.c | 15 ++++++++++++++
> >> drivers/fpga/socfpga.c | 10 +++++-----
> >> drivers/fpga/zynq-fpga.c | 7 ++++++-
> >> include/linux/fpga/fpga-mgr.h | 46 ++++++++++++++++++++++++++++++++++++++++++-
> >> 4 files changed, 71 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> >> index 953dc91..ed57c17 100644
> >> --- a/drivers/fpga/fpga-mgr.c
> >> +++ b/drivers/fpga/fpga-mgr.c
> >> @@ -49,6 +49,18 @@ int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags, const char *buf,
> >> struct device *dev = &mgr->dev;
> >> int ret;
> >>
> >> + if (flags & FPGA_MGR_PARTIAL_RECONFIG &&
> >> + !fpga_mgr_has_cap(FPGA_MGR_CAP_PARTIAL_RECONF, mgr->caps)) {
> >> + dev_err(dev, "Partial reconfiguration not supported\n");
> >> + return -ENOTSUPP;
> >> + }
> >> +
> >> + if (flags & FPGA_MGR_FULL_RECONFIG &&
> >> + !fpga_mgr_has_cap(FPGA_MGR_CAP_FULL_RECONF, mgr->caps)) {
> >> + dev_err(dev, "Full reconfiguration not supported\n");
> >> + return -ENOTSUPP;
> >> + }
> >> +
> >
> > Could you move the checks to their own function like
> > 'fpga_mgr_check_caps()' or something? I really like it if we can keep
> > the functions short, like a screen or so where it's practicle to do
> > so and I could see the number of caps growing here.
>
> Absolutely. Great suggestion.
>
> > The only counter argument I could think of is if a cap affects the sequence
> > in this function. Hmmm...
>
> Oh you mean the cap being there affecting the sequence in *this* function?
> I'd suggest we address that when we run into a cap that requires this.
Yes, I agree.
Alan
>
> Cheers,
>
> Moritz
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v7 00/10] Convert msix_init() to error
From: Michael S. Tsirkin @ 2016-11-14 23:22 UTC (permalink / raw)
To: Cao jin
Cc: qemu-devel, Jiri Pirko, Gerd Hoffmann, Dmitry Fleytman,
Jason Wang, Hannes Reinecke, Paolo Bonzini, Alex Williamson,
Markus Armbruster, Marcel Apfelbaum
In-Reply-To: <1479108340-3453-1-git-send-email-caoj.fnst@cn.fujitsu.com>
On Mon, Nov 14, 2016 at 03:25:30PM +0800, Cao jin wrote:
> v7 changelog:
> 1. fix the segfaut bug in patch 2. So drop the all the R-b of it,
> please take a look, there is detailed description in the patch.
> 2. add the R-b from Hannes Reinecke
Pls remember to ping after release.
> Test:
> 1. make check: pass
> 2. After applied all the patch, command line test for all the
> affected devices, just make sure device realize process is ok,
> no crash, but no further use of device.
> CC: Jiri Pirko <jiri@resnulli.us>
> CC: Gerd Hoffmann <kraxel@redhat.com>
> CC: Dmitry Fleytman <dmitry@daynix.com>
> CC: Jason Wang <jasowang@redhat.com>
> CC: Michael S. Tsirkin <mst@redhat.com>
> CC: Hannes Reinecke <hare@suse.de>
> CC: Paolo Bonzini <pbonzini@redhat.com>
> CC: Alex Williamson <alex.williamson@redhat.com>
> CC: Markus Armbruster <armbru@redhat.com>
> CC: Marcel Apfelbaum <marcel@redhat.com>
>
> Cao jin (10):
> msix: Follow CODING_STYLE
> hcd-xhci: check & correct param before using it
> pci: Convert msix_init() to Error and fix callers to check it
> megasas: change behaviour of msix switch
> hcd-xhci: change behaviour of msix switch
> megasas: remove unnecessary megasas_use_msix()
> megasas: undo the overwrites of msi user configuration
> vmxnet3: fix reference leak issue
> vmxnet3: remove unnecessary internal msix flag
> msi_init: convert assert to return -errno
>
> hw/block/nvme.c | 5 +++-
> hw/misc/ivshmem.c | 8 +++---
> hw/net/e1000e.c | 6 ++++-
> hw/net/rocker/rocker.c | 7 ++++-
> hw/net/vmxnet3.c | 46 +++++++++++++++------------------
> hw/pci/msi.c | 9 ++++---
> hw/pci/msix.c | 42 +++++++++++++++++++++++++-----
> hw/scsi/megasas.c | 49 ++++++++++++++++++++---------------
> hw/usb/hcd-xhci.c | 69 ++++++++++++++++++++++++++++++--------------------
> hw/vfio/pci.c | 8 ++++--
> hw/virtio/virtio-pci.c | 11 ++++----
> include/hw/pci/msix.h | 5 ++--
> 12 files changed, 164 insertions(+), 101 deletions(-)
>
> --
> 2.1.0
>
>
^ permalink raw reply
* Re: [PATCH v2 09/12] mm: hwpoison: soft offline supports thp migration
From: Balbir Singh @ 2016-11-14 23:22 UTC (permalink / raw)
To: Naoya Horiguchi
Cc: linux-mm@kvack.org, Kirill A. Shutemov, Hugh Dickins,
Andrew Morton, Dave Hansen, Andrea Arcangeli, Mel Gorman,
Michal Hocko, Vlastimil Babka, Pavel Emelyanov, Zi Yan,
linux-kernel@vger.kernel.org, Naoya Horiguchi
In-Reply-To: <20161110235853.GB22792@hori1.linux.bs1.fc.nec.co.jp>
On 11/11/16 10:58, Naoya Horiguchi wrote:
> On Thu, Nov 10, 2016 at 09:31:10PM +1100, Balbir Singh wrote:
>>
>>
>> On 08/11/16 10:31, Naoya Horiguchi wrote:
>>> This patch enables thp migration for soft offline.
>>>
>>> Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>>> ---
>>> mm/memory-failure.c | 31 ++++++++++++-------------------
>>> 1 file changed, 12 insertions(+), 19 deletions(-)
>>>
>>> diff --git v4.9-rc2-mmotm-2016-10-27-18-27/mm/memory-failure.c v4.9-rc2-mmotm-2016-10-27-18-27_patched/mm/memory-failure.c
>>> index 19e796d..6cc8157 100644
>>> --- v4.9-rc2-mmotm-2016-10-27-18-27/mm/memory-failure.c
>>> +++ v4.9-rc2-mmotm-2016-10-27-18-27_patched/mm/memory-failure.c
>>> @@ -1485,7 +1485,17 @@ static struct page *new_page(struct page *p, unsigned long private, int **x)
>>> if (PageHuge(p))
>>> return alloc_huge_page_node(page_hstate(compound_head(p)),
>>> nid);
>>> - else
>>> + else if (thp_migration_supported() && PageTransHuge(p)) {
>>> + struct page *thp;
>>> +
>>> + thp = alloc_pages_node(nid,
>>> + (GFP_TRANSHUGE | __GFP_THISNODE) & ~__GFP_RECLAIM,
>>> + HPAGE_PMD_ORDER);
>>> + if (!thp)
>>> + return NULL;
>>
>> Just wondering if new_page() fails, migration of that entry fails. Do we then
>> split and migrate? I guess this applies to THP migration in general.
>
> Yes, that's not implemented yet, but can be helpful.
>
> I think that there are 2 types of callers of page migration,
> one is a caller that specifies the target pages individually (like move_pages
> and soft offline), and another is a caller that specifies the target pages
> by (physical/virtual) address range basis.
> Maybe the former ones want to fall back immediately to split and retry if
> thp migration fails, and the latter ones want to retry thp migration more.
> If this makes sense, we can make some more changes on retry logic to fit
> the situation.
>
I think we definitely need the retry with split option, but may be we can
build it on top of this series.
Balbir Singh.
^ permalink raw reply
* Re: [PATCH v2 09/12] mm: hwpoison: soft offline supports thp migration
From: Balbir Singh @ 2016-11-14 23:22 UTC (permalink / raw)
To: Naoya Horiguchi
Cc: linux-mm@kvack.org, Kirill A. Shutemov, Hugh Dickins,
Andrew Morton, Dave Hansen, Andrea Arcangeli, Mel Gorman,
Michal Hocko, Vlastimil Babka, Pavel Emelyanov, Zi Yan,
linux-kernel@vger.kernel.org, Naoya Horiguchi
In-Reply-To: <20161110235853.GB22792@hori1.linux.bs1.fc.nec.co.jp>
On 11/11/16 10:58, Naoya Horiguchi wrote:
> On Thu, Nov 10, 2016 at 09:31:10PM +1100, Balbir Singh wrote:
>>
>>
>> On 08/11/16 10:31, Naoya Horiguchi wrote:
>>> This patch enables thp migration for soft offline.
>>>
>>> Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>>> ---
>>> mm/memory-failure.c | 31 ++++++++++++-------------------
>>> 1 file changed, 12 insertions(+), 19 deletions(-)
>>>
>>> diff --git v4.9-rc2-mmotm-2016-10-27-18-27/mm/memory-failure.c v4.9-rc2-mmotm-2016-10-27-18-27_patched/mm/memory-failure.c
>>> index 19e796d..6cc8157 100644
>>> --- v4.9-rc2-mmotm-2016-10-27-18-27/mm/memory-failure.c
>>> +++ v4.9-rc2-mmotm-2016-10-27-18-27_patched/mm/memory-failure.c
>>> @@ -1485,7 +1485,17 @@ static struct page *new_page(struct page *p, unsigned long private, int **x)
>>> if (PageHuge(p))
>>> return alloc_huge_page_node(page_hstate(compound_head(p)),
>>> nid);
>>> - else
>>> + else if (thp_migration_supported() && PageTransHuge(p)) {
>>> + struct page *thp;
>>> +
>>> + thp = alloc_pages_node(nid,
>>> + (GFP_TRANSHUGE | __GFP_THISNODE) & ~__GFP_RECLAIM,
>>> + HPAGE_PMD_ORDER);
>>> + if (!thp)
>>> + return NULL;
>>
>> Just wondering if new_page() fails, migration of that entry fails. Do we then
>> split and migrate? I guess this applies to THP migration in general.
>
> Yes, that's not implemented yet, but can be helpful.
>
> I think that there are 2 types of callers of page migration,
> one is a caller that specifies the target pages individually (like move_pages
> and soft offline), and another is a caller that specifies the target pages
> by (physical/virtual) address range basis.
> Maybe the former ones want to fall back immediately to split and retry if
> thp migration fails, and the latter ones want to retry thp migration more.
> If this makes sense, we can make some more changes on retry logic to fit
> the situation.
>
I think we definitely need the retry with split option, but may be we can
build it on top of this series.
Balbir Singh.
--
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
* [base][PATCH] setup-environment: Keep sources/base files in sync automatically
From: Tom Hochstein @ 2016-11-14 16:43 UTC (permalink / raw)
To: meta-freescale
In-Reply-To: <1479141809-11114-1-git-send-email-tom.hochstein@nxp.com>
Currently setup-environment tries to keep the files in sources/base
in sync with the files copied by the manifest. When the files do
get out of sync, the script fails with an error message that many
users will not understand.
We avoid the sync issue in the manifest by linking to the files.
Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com>
---
setup-environment | 19 -------------------
1 file changed, 19 deletions(-)
diff --git a/setup-environment b/setup-environment
index a04ffae..9a3bdc2 100755
--- a/setup-environment
+++ b/setup-environment
@@ -135,25 +135,6 @@ if [ -e $PWD/sources/oe-core ]; then
OEROOT=$PWD/sources/oe-core
fi
-# Ensure all files in sources/base are kept in sync with project root
-updated=
-for f in $CWD/sources/base/*; do
- file="$(basename $f)"
- if [ "$file" = "conf" ] || echo $file | grep -q '~$'; then
- continue
- fi
-
- if ! cmp -s "$file" "$f"; then
- updated="true"
- [ -e $file ] && chmod u+w $file
- cp $f $file
- fi
-done
-if [ "$updated" = "true" ]; then
- echo "The project root content has been updated. Please run '$PROGNAME' again."
- return
-fi
-
. $OEROOT/oe-init-build-env $CWD/$1 > /dev/null
# if conf/local.conf not generated, no need to go further
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v7 4/5] of/fdt: mark hotpluggable memory
From: Balbir Singh @ 2016-11-14 23:20 UTC (permalink / raw)
To: Reza Arbab, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Andrew Morton, Rob Herring, Frank Rowand,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin
Cc: linuxppc-dev, linux-mm, devicetree, Bharata B Rao,
Nathan Fontenot, Stewart Smith, Alistair Popple, Aneesh Kumar K.V,
linux-kernel
In-Reply-To: <1479160961-25840-5-git-send-email-arbab@linux.vnet.ibm.com>
On 15/11/16 09:02, Reza Arbab wrote:
> When movable nodes are enabled, any node containing only hotpluggable
> memory is made movable at boot time.
>
> On x86, hotpluggable memory is discovered by parsing the ACPI SRAT,
> making corresponding calls to memblock_mark_hotplug().
>
> If we introduce a dt property to describe memory as hotpluggable,
> configs supporting early fdt may then also do this marking and use
> movable nodes.
>
> Signed-off-by: Reza Arbab <arbab@linux.vnet.ibm.com>
> Tested-by: Balbir Singh <bsingharora@gmail.com>
Also
Acked-by: Balbir Singh <bsingharora@gmail.com>
^ permalink raw reply
* Re: [PATCH v7 4/5] of/fdt: mark hotpluggable memory
From: Balbir Singh @ 2016-11-14 23:20 UTC (permalink / raw)
To: Reza Arbab, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Andrew Morton, Rob Herring, Frank Rowand,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin
Cc: linuxppc-dev, linux-mm, devicetree, Bharata B Rao,
Nathan Fontenot, Stewart Smith, Alistair Popple, Aneesh Kumar K.V,
linux-kernel
In-Reply-To: <1479160961-25840-5-git-send-email-arbab@linux.vnet.ibm.com>
On 15/11/16 09:02, Reza Arbab wrote:
> When movable nodes are enabled, any node containing only hotpluggable
> memory is made movable at boot time.
>
> On x86, hotpluggable memory is discovered by parsing the ACPI SRAT,
> making corresponding calls to memblock_mark_hotplug().
>
> If we introduce a dt property to describe memory as hotpluggable,
> configs supporting early fdt may then also do this marking and use
> movable nodes.
>
> Signed-off-by: Reza Arbab <arbab@linux.vnet.ibm.com>
> Tested-by: Balbir Singh <bsingharora@gmail.com>
Also
Acked-by: Balbir Singh <bsingharora@gmail.com>
--
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: [PATCH v7 2/5] mm: remove x86-only restriction of movable_node
From: Balbir Singh @ 2016-11-14 23:20 UTC (permalink / raw)
To: Reza Arbab, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Andrew Morton, Rob Herring, Frank Rowand,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin
Cc: linuxppc-dev, linux-mm, devicetree, Bharata B Rao,
Nathan Fontenot, Stewart Smith, Alistair Popple, Aneesh Kumar K.V,
linux-kernel
In-Reply-To: <1479160961-25840-3-git-send-email-arbab@linux.vnet.ibm.com>
On 15/11/16 09:02, Reza Arbab wrote:
> In commit c5320926e370 ("mem-hotplug: introduce movable_node boot
> option"), the memblock allocation direction is changed to bottom-up and
> then back to top-down like this:
>
> 1. memblock_set_bottom_up(true), called by cmdline_parse_movable_node().
> 2. memblock_set_bottom_up(false), called by x86's numa_init().
>
> Even though (1) occurs in generic mm code, it is wrapped by #ifdef
> CONFIG_MOVABLE_NODE, which depends on X86_64.
>
> This means that when we extend CONFIG_MOVABLE_NODE to non-x86 arches,
> things will be unbalanced. (1) will happen for them, but (2) will not.
>
> This toggle was added in the first place because x86 has a delay between
> adding memblocks and marking them as hotpluggable. Since other arches do
> this marking either immediately or not at all, they do not require the
> bottom-up toggle.
>
> So, resolve things by moving (1) from cmdline_parse_movable_node() to
> x86's setup_arch(), immediately after the movable_node parameter has
> been parsed.
>
> Signed-off-by: Reza Arbab <arbab@linux.vnet.ibm.com>
Acked-by: Balbir Singh <bsingharora@gmail.com>
--
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: [PATCH v7 2/5] mm: remove x86-only restriction of movable_node
From: Balbir Singh @ 2016-11-14 23:20 UTC (permalink / raw)
To: Reza Arbab, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Andrew Morton, Rob Herring, Frank Rowand,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin
Cc: linuxppc-dev, linux-mm, devicetree, Bharata B Rao,
Nathan Fontenot, Stewart Smith, Alistair Popple, Aneesh Kumar K.V,
linux-kernel
In-Reply-To: <1479160961-25840-3-git-send-email-arbab@linux.vnet.ibm.com>
On 15/11/16 09:02, Reza Arbab wrote:
> In commit c5320926e370 ("mem-hotplug: introduce movable_node boot
> option"), the memblock allocation direction is changed to bottom-up and
> then back to top-down like this:
>
> 1. memblock_set_bottom_up(true), called by cmdline_parse_movable_node().
> 2. memblock_set_bottom_up(false), called by x86's numa_init().
>
> Even though (1) occurs in generic mm code, it is wrapped by #ifdef
> CONFIG_MOVABLE_NODE, which depends on X86_64.
>
> This means that when we extend CONFIG_MOVABLE_NODE to non-x86 arches,
> things will be unbalanced. (1) will happen for them, but (2) will not.
>
> This toggle was added in the first place because x86 has a delay between
> adding memblocks and marking them as hotpluggable. Since other arches do
> this marking either immediately or not at all, they do not require the
> bottom-up toggle.
>
> So, resolve things by moving (1) from cmdline_parse_movable_node() to
> x86's setup_arch(), immediately after the movable_node parameter has
> been parsed.
>
> Signed-off-by: Reza Arbab <arbab@linux.vnet.ibm.com>
Acked-by: Balbir Singh <bsingharora@gmail.com>
^ permalink raw reply
* Re: [PATCH v7 2/5] mm: remove x86-only restriction of movable_node
From: Balbir Singh @ 2016-11-14 23:20 UTC (permalink / raw)
To: Reza Arbab, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Andrew Morton, Rob Herring, Frank Rowand,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin
Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
devicetree-u79uwXL29TY76Z2rM5mHXA, Bharata B Rao, Nathan Fontenot,
Stewart Smith, Alistair Popple, Aneesh Kumar K.V,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479160961-25840-3-git-send-email-arbab-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
On 15/11/16 09:02, Reza Arbab wrote:
> In commit c5320926e370 ("mem-hotplug: introduce movable_node boot
> option"), the memblock allocation direction is changed to bottom-up and
> then back to top-down like this:
>
> 1. memblock_set_bottom_up(true), called by cmdline_parse_movable_node().
> 2. memblock_set_bottom_up(false), called by x86's numa_init().
>
> Even though (1) occurs in generic mm code, it is wrapped by #ifdef
> CONFIG_MOVABLE_NODE, which depends on X86_64.
>
> This means that when we extend CONFIG_MOVABLE_NODE to non-x86 arches,
> things will be unbalanced. (1) will happen for them, but (2) will not.
>
> This toggle was added in the first place because x86 has a delay between
> adding memblocks and marking them as hotpluggable. Since other arches do
> this marking either immediately or not at all, they do not require the
> bottom-up toggle.
>
> So, resolve things by moving (1) from cmdline_parse_movable_node() to
> x86's setup_arch(), immediately after the movable_node parameter has
> been parsed.
>
> Signed-off-by: Reza Arbab <arbab-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Acked-by: Balbir Singh <bsingharora-Re5JQEeQqe8AvxtiuMwx3w@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
* Re: [Qemu-devel] [PULL v2 00/34] virtio, vhost, pc, pci: tests, documentation, fixes and cleanups
From: Michael S. Tsirkin @ 2016-11-14 23:19 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: qemu-devel, Peter Maydell
In-Reply-To: <20161114155258.GC26664@stefanha-x1.localdomain>
On Mon, Nov 14, 2016 at 03:52:58PM +0000, Stefan Hajnoczi wrote:
> On Fri, Nov 11, 2016 at 08:09:58PM +0200, Michael S. Tsirkin wrote:
> > libvhost-user is the only thing that might be controvertial here, but it's only
> > affecting contrib/ and tests so I think it's still fair game, and several
> > people were asking for it.
>
> I am being firm about the freeze policy. Only fixes are allowed.
> Please send a v3 without libvhost-user.
What's a fix is at some level in the eye of the beholder.
Consider Igor's patch removing an unused fw cfg file, is this
a fix? In the past it was maintainer's decision.
This one cleans up test code.
> I understand that people want libvhost-user. Please merge it in a -next
> branch and have them base their work on that.
>
> Stefan
Well I feel bad about it.
It was ready in time, I deferred it because there was so much other
stuff that I did not want it to interfere with.
I was sure it's ok - it's just a test change, I don't really see why we
need to enforce policy for tests, they are not used in production.
Let's make an exception for once?
--
MST
^ permalink raw reply
* Re: [PATCH 1/2] libselinux, libsemanage: fall back to gcc in exception.sh
From: Nicolas Iooss @ 2016-11-14 23:18 UTC (permalink / raw)
To: William Roberts; +Cc: selinux@tycho.nsa.gov
In-Reply-To: <CAFftDdodmRSq8FmFrYi+YyJWaw8s0KMU-nUTJ40F7ZtaP8Jh8Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1930 bytes --]
On Tue, Nov 15, 2016 at 12:06 AM, William Roberts <bill.c.roberts@gmail.com>
wrote:
> On Mon, Nov 14, 2016 at 3:00 PM, Nicolas Iooss <nicolas.iooss@m4x.org>
> wrote:
> > The SWIG wrapper already includes the header files using #include (look
> at
> > the beginning of libselinux/src/selinuxswig_python.i [1] for example).
> The
> > script exception.h reads the header files (through gcc -aux-info) to
> > generate some SWIG code for almost every interface returning an integer
> > (this code converts a negative return value to the raising of a Python
> > OSError exception).
> >
> > In SWIG documentation [2] I have not found a way to automatically apply a
> > %exception block to all functions matched by the pattern "it returns an
> > integer". As you seem to believe I missed something,
>
> I don't think you did.
>
> could you please
> > explain how you would proceed here?
>
> Yeah that script is just generating a bunch of interface code, I would
> just remove that script
> and write it by hand. The only downfall is that you would have to add
> a stub if you add something
> to the header file, but I don't consider that a downside, I prefer to
> be explicit. Especially
> considering they already had to put a function in the script to skip.
> I don't think the script provides
> much value.
This kind of question is about the way maintainers want to manage the
maintenance and development of the code. I understand the need to keep
things simple, but how replacing the script with a "static file"
(selinuxswig_python_exception.i, or its integration into
selinuxswig_python.i) would keep working on the project simple or make it
more complex is something I do not know.
An alternative approach would be something like projects using autotools
do: keep the script in the git tree but package releases with
selinuxswig_python_exception.i (and semanage...exception.i) so that end
users do not have to build it.
Nicolas
[-- Attachment #2: Type: text/html, Size: 2547 bytes --]
^ permalink raw reply
* [U-Boot] [PATCH v4 5/7] apalis/colibri_imx7/pxa270/t20/t30/vf: integrate config block handling
From: Stefan Agner @ 2016-11-14 23:18 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1478525794-20867-6-git-send-email-marcel.ziswiler@toradex.com>
Hi Marcel,
Just found an issue with this patch.
On 2016-11-07 05:36, Marcel Ziswiler wrote:
> With our common code in place actually make use of it across all our
> modules.
>
> Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> Acked-by: Max Krummenacher <max.krummenacher@toradex.com>
>
> ---
>
> Changes in v4: None
> Changes in v3:
> - use checkboard() rather than checkboard_fallback()
> - drop CUSTOM_BOARDINFO
>
> Changes in v2: None
>
> board/toradex/apalis_t30/Kconfig | 18 ++++++++++++++++++
> board/toradex/apalis_t30/apalis_t30.c | 12 +++++++++++-
> board/toradex/colibri_imx7/Kconfig | 16 ++++++++++++++++
> board/toradex/colibri_pxa270/Kconfig | 11 +++++++++++
> board/toradex/colibri_pxa270/colibri_pxa270.c | 8 ++++++++
> board/toradex/colibri_t20/Kconfig | 11 +++++++++++
> board/toradex/colibri_t20/colibri_t20.c | 13 +++++++++++++
> board/toradex/colibri_t30/Kconfig | 18 ++++++++++++++++++
> board/toradex/colibri_t30/colibri_t30.c | 9 ++++++++-
> board/toradex/colibri_vf/Kconfig | 14 ++++++++++++++
> configs/colibri_vf_defconfig | 1 +
> include/configs/apalis_t30.h | 4 ++--
> include/configs/colibri_imx7.h | 6 +++++-
> include/configs/colibri_pxa270.h | 6 +++++-
> include/configs/colibri_t20.h | 2 +-
> include/configs/colibri_t30.h | 4 ++--
> include/configs/colibri_vf.h | 6 ++++--
> 17 files changed, 148 insertions(+), 11 deletions(-)
>
> diff --git a/board/toradex/apalis_t30/Kconfig b/board/toradex/apalis_t30/Kconfig
> index f1dcda5..16224da 100644
> --- a/board/toradex/apalis_t30/Kconfig
> +++ b/board/toradex/apalis_t30/Kconfig
> @@ -9,4 +9,22 @@ config SYS_VENDOR
> config SYS_CONFIG_NAME
> default "apalis_t30"
>
> +config TDX_CFG_BLOCK
> + default y
> +
> +config TDX_HAVE_MMC
> + default y
> +
> +config TDX_CFG_BLOCK_DEV
> + default "0"
> +
> +config TDX_CFG_BLOCK_PART
> + default "1"
> +
> +# Toradex config block in eMMC, at the end of 1st "boot sector"
> +config TDX_CFG_BLOCK_OFFSET
> + default "-512"
> +
> +source "board/toradex/common/Kconfig"
Sourcing the common Kconfig in every board file leads to multiple
entries (e.g. make menuconfig looks rather crowded).
I just checked Documentation/kbuild/kconfig-language.txt, you can't
conditionally include a Kconfig file. It will always include it, that
seems to cause the issue.
I suggest to just add it to arch/arm/Kconfig once, there are some other
"common" includes already.
--
Stefan
> +
> endif
> diff --git a/board/toradex/apalis_t30/apalis_t30.c
> b/board/toradex/apalis_t30/apalis_t30.c
> index 3f56971..3d83491 100644
> --- a/board/toradex/apalis_t30/apalis_t30.c
> +++ b/board/toradex/apalis_t30/apalis_t30.c
> @@ -1,5 +1,5 @@
> /*
> - * (C) Copyright 2014
> + * (C) Copyright 2014-2016
> * Marcel Ziswiler <marcel@ziswiler.com>
> *
> * SPDX-License-Identifier: GPL-2.0+
> @@ -17,6 +17,8 @@
>
> #include "pinmux-config-apalis_t30.h"
>
> +DECLARE_GLOBAL_DATA_PTR;
> +
> #define PMU_I2C_ADDRESS 0x2D
> #define MAX_I2C_RETRY 3
>
> @@ -29,6 +31,14 @@ int arch_misc_init(void)
> return 0;
> }
>
> +int checkboard(void)
> +{
> + printf("Model: Toradex Apalis T30 %dGB\n",
> + (gd->ram_size == 0x40000000) ? 1 : 2);
> +
> + return 0;
> +}
> +
> /*
> * Routine: pinmux_init
> * Description: Do individual peripheral pinmux configs
> diff --git a/board/toradex/colibri_imx7/Kconfig
> b/board/toradex/colibri_imx7/Kconfig
> index 7bba26b..414a600 100644
> --- a/board/toradex/colibri_imx7/Kconfig
> +++ b/board/toradex/colibri_imx7/Kconfig
> @@ -16,5 +16,21 @@ config COLIBRI_IMX7_EXT_PHYCLK
> clock source.
> default y
>
> +config TDX_CFG_BLOCK
> + default y
> +
> +config TDX_HAVE_NAND
> + default y
> +
> +config TDX_CFG_BLOCK_OFFSET
> + default "2048"
> +
> +config TDX_CFG_BLOCK_OFFSET2
> + default "133120"
> +
> +config TDX_CFG_BLOCK_2ND_ETHADDR
> + default y
> +
> +source "board/toradex/common/Kconfig"
>
> endif
> diff --git a/board/toradex/colibri_pxa270/Kconfig
> b/board/toradex/colibri_pxa270/Kconfig
> index 949407a..f646baa 100644
> --- a/board/toradex/colibri_pxa270/Kconfig
> +++ b/board/toradex/colibri_pxa270/Kconfig
> @@ -9,4 +9,15 @@ config SYS_VENDOR
> config SYS_CONFIG_NAME
> default "colibri_pxa270"
>
> +config TDX_CFG_BLOCK
> + default y
> +
> +config TDX_HAVE_NOR
> + default y
> +
> +config TDX_CFG_BLOCK_OFFSET
> + default "262144"
> +
> +source "board/toradex/common/Kconfig"
> +
> endif
> diff --git a/board/toradex/colibri_pxa270/colibri_pxa270.c
> b/board/toradex/colibri_pxa270/colibri_pxa270.c
> index 3def0a6..de8cb28 100644
> --- a/board/toradex/colibri_pxa270/colibri_pxa270.c
> +++ b/board/toradex/colibri_pxa270/colibri_pxa270.c
> @@ -2,6 +2,7 @@
> * Toradex Colibri PXA270 Support
> *
> * Copyright (C) 2010 Marek Vasut <marek.vasut@gmail.com>
> + * Copyright (C) 2016 Marcel Ziswiler <marcel.ziswiler@toradex.com>
> *
> * SPDX-License-Identifier: GPL-2.0+
> */
> @@ -32,6 +33,13 @@ int board_init(void)
> return 0;
> }
>
> +int checkboard(void)
> +{
> + puts("Model: Toradex Colibri PXA270\n");
> +
> + return 0;
> +}
> +
> int dram_init(void)
> {
> pxa2xx_dram_init();
> diff --git a/board/toradex/colibri_t20/Kconfig
> b/board/toradex/colibri_t20/Kconfig
> index 7f373b2..a43acdd 100644
> --- a/board/toradex/colibri_t20/Kconfig
> +++ b/board/toradex/colibri_t20/Kconfig
> @@ -9,4 +9,15 @@ config SYS_VENDOR
> config SYS_CONFIG_NAME
> default "colibri_t20"
>
> +config TDX_CFG_BLOCK
> + default y
> +
> +config TDX_HAVE_NAND
> + default y
> +
> +config TDX_CFG_BLOCK_OFFSET
> + default "3145728"
> +
> +source "board/toradex/common/Kconfig"
> +
> endif
> diff --git a/board/toradex/colibri_t20/colibri_t20.c
> b/board/toradex/colibri_t20/colibri_t20.c
> index 68fbf49..01b55be 100644
> --- a/board/toradex/colibri_t20/colibri_t20.c
> +++ b/board/toradex/colibri_t20/colibri_t20.c
> @@ -14,6 +14,9 @@
> #include <asm/gpio.h>
> #include <asm/io.h>
> #include <i2c.h>
> +#include <nand.h>
> +
> +DECLARE_GLOBAL_DATA_PTR;
>
> #define PMU_I2C_ADDRESS 0x34
> #define MAX_I2C_RETRY 3
> @@ -61,6 +64,16 @@ int arch_misc_init(void)
> return 0;
> }
>
> +int checkboard(void)
> +{
> + printf("Model: Toradex Colibri T20 %dMB V%s\n",
> + (gd->ram_size == 0x10000000) ? 256 : 512,
> + (nand_info[0]->erasesize >> 10 == 512) ?
> + ((gd->ram_size == 0x10000000) ? "1.1B" : "1.1C") : "1.2A");
> +
> + return 0;
> +}
> +
> #ifdef CONFIG_TEGRA_MMC
> /*
> * Routine: pin_mux_mmc
> diff --git a/board/toradex/colibri_t30/Kconfig
> b/board/toradex/colibri_t30/Kconfig
> index 3e436a2..68ef82b 100644
> --- a/board/toradex/colibri_t30/Kconfig
> +++ b/board/toradex/colibri_t30/Kconfig
> @@ -9,4 +9,22 @@ config SYS_VENDOR
> config SYS_CONFIG_NAME
> default "colibri_t30"
>
> +config TDX_CFG_BLOCK
> + default y
> +
> +config TDX_HAVE_MMC
> + default y
> +
> +config TDX_CFG_BLOCK_DEV
> + default "0"
> +
> +config TDX_CFG_BLOCK_PART
> + default "1"
> +
> +# Toradex config block in eMMC, at the end of 1st "boot sector"
> +config TDX_CFG_BLOCK_OFFSET
> + default "-512"
> +
> +source "board/toradex/common/Kconfig"
> +
> endif
> diff --git a/board/toradex/colibri_t30/colibri_t30.c
> b/board/toradex/colibri_t30/colibri_t30.c
> index e32362a..707d07e 100644
> --- a/board/toradex/colibri_t30/colibri_t30.c
> +++ b/board/toradex/colibri_t30/colibri_t30.c
> @@ -1,5 +1,5 @@
> /*
> - * (C) Copyright 2014
> + * (C) Copyright 2014-2016
> * Stefan Agner <stefan@agner.ch>
> *
> * SPDX-License-Identifier: GPL-2.0+
> @@ -24,6 +24,13 @@ int arch_misc_init(void)
> return 0;
> }
>
> +int checkboard(void)
> +{
> + puts("Model: Toradex Colibri T30 1GB\n");
> +
> + return 0;
> +}
> +
> /*
> * Routine: pinmux_init
> * Description: Do individual peripheral pinmux configs
> diff --git a/board/toradex/colibri_vf/Kconfig b/board/toradex/colibri_vf/Kconfig
> index 2c3cb30..bf9bb01 100644
> --- a/board/toradex/colibri_vf/Kconfig
> +++ b/board/toradex/colibri_vf/Kconfig
> @@ -15,4 +15,18 @@ config SYS_SOC
> config SYS_CONFIG_NAME
> default "colibri_vf"
>
> +config TDX_CFG_BLOCK
> + default y
> +
> +config TDX_HAVE_NAND
> + default y
> +
> +config TDX_CFG_BLOCK_OFFSET
> + default "2048"
> +
> +config TDX_CFG_BLOCK_2ND_ETHADDR
> + default y
> +
> +source "board/toradex/common/Kconfig"
> +
> endif
> diff --git a/configs/colibri_vf_defconfig b/configs/colibri_vf_defconfig
> index 1020e44..54d3581 100644
> --- a/configs/colibri_vf_defconfig
> +++ b/configs/colibri_vf_defconfig
> @@ -4,6 +4,7 @@ CONFIG_DEFAULT_DEVICE_TREE="vf610-colibri"
>
> CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/colibri_vf/imximage.cfg,ENV_IS_IN_NAND,IMX_NAND"
> CONFIG_BOOTDELAY=1
> CONFIG_VERSION_VARIABLE=y
> +# CONFIG_DISPLAY_BOARDINFO is not set
> CONFIG_HUSH_PARSER=y
> CONFIG_SYS_PROMPT="Colibri VFxx # "
> CONFIG_CMD_BOOTZ=y
> diff --git a/include/configs/apalis_t30.h b/include/configs/apalis_t30.h
> index d38302d..069ed20 100644
> --- a/include/configs/apalis_t30.h
> +++ b/include/configs/apalis_t30.h
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2014-2015 Marcel Ziswiler
> + * Copyright (c) 2014-2016 Marcel Ziswiler
> *
> * Configuration settings for the Toradex Apalis T30 modules.
> *
> @@ -16,7 +16,7 @@
> #define CONFIG_ARCH_MISC_INIT
>
> /* High-level configuration options */
> -#define CONFIG_TEGRA_BOARD_STRING "Toradex Apalis T30"
> +#define CONFIG_DISPLAY_BOARDINFO_LATE /* Calls show_board_info() */
>
> /* Board-specific serial config */
> #define CONFIG_TEGRA_ENABLE_UARTA
> diff --git a/include/configs/colibri_imx7.h b/include/configs/colibri_imx7.h
> index 309aef8..5ce0a34 100644
> --- a/include/configs/colibri_imx7.h
> +++ b/include/configs/colibri_imx7.h
> @@ -21,10 +21,14 @@
> /*#define CONFIG_DBG_MONITOR*/
> #define PHYS_SDRAM_SIZE SZ_512M
>
> +#define CONFIG_ARCH_MISC_INIT
> #define CONFIG_BOARD_EARLY_INIT_F
> #define CONFIG_BOARD_LATE_INIT
>
> -#define CONFIG_DISPLAY_BOARDINFO_LATE
> +#define CONFIG_DISPLAY_BOARDINFO_LATE /* Calls show_board_info() */
> +
> +#define CONFIG_ENV_VARS_UBOOT_CONFIG
> +#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
>
> /* Size of malloc() pool */
> #define CONFIG_SYS_MALLOC_LEN (32 * SZ_1M)
> diff --git a/include/configs/colibri_pxa270.h b/include/configs/colibri_pxa270.h
> index e44a847..b15ed72 100644
> --- a/include/configs/colibri_pxa270.h
> +++ b/include/configs/colibri_pxa270.h
> @@ -2,7 +2,7 @@
> * Toradex Colibri PXA270 configuration file
> *
> * Copyright (C) 2010 Marek Vasut <marek.vasut@gmail.com>
> - * Copyright (C) 2015 Marcel Ziswiler <marcel@ziswiler.com>
> + * Copyright (C) 2015-2016 Marcel Ziswiler <marcel@ziswiler.com>
> *
> * SPDX-License-Identifier: GPL-2.0+
> */
> @@ -21,10 +21,14 @@
> /* We will never enable dcache because we have to setup MMU first */
> #define CONFIG_SYS_DCACHE_OFF
>
> +#define CONFIG_DISPLAY_BOARDINFO_LATE /* Calls show_board_info() */
> +
> /*
> * Environment settings
> */
> #define CONFIG_ENV_OVERWRITE
> +#define CONFIG_ENV_VARS_UBOOT_CONFIG
> +#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
> #define CONFIG_SYS_MALLOC_LEN (128 * 1024)
> #define CONFIG_ARCH_CPU_INIT
> #define CONFIG_BOOTCOMMAND \
> diff --git a/include/configs/colibri_t20.h b/include/configs/colibri_t20.h
> index 4634989..6a52869 100644
> --- a/include/configs/colibri_t20.h
> +++ b/include/configs/colibri_t20.h
> @@ -14,7 +14,7 @@
> #define CONFIG_ARCH_MISC_INIT
>
> /* High-level configuration options */
> -#define CONFIG_TEGRA_BOARD_STRING "Toradex Colibri T20"
> +#define CONFIG_DISPLAY_BOARDINFO_LATE /* Calls show_board_info() */
>
> /* Board-specific serial config */
> #define CONFIG_TEGRA_ENABLE_UARTA
> diff --git a/include/configs/colibri_t30.h b/include/configs/colibri_t30.h
> index e2a2549..1ab5c41 100644
> --- a/include/configs/colibri_t30.h
> +++ b/include/configs/colibri_t30.h
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2013-2015 Stefan Agner
> + * Copyright (c) 2013-2016 Stefan Agner
> *
> * Configuration settings for the Toradex Colibri T30 modules.
> *
> @@ -16,7 +16,7 @@
> #define CONFIG_ARCH_MISC_INIT
>
> /* High-level configuration options */
> -#define CONFIG_TEGRA_BOARD_STRING "Toradex Colibri T30"
> +#define CONFIG_DISPLAY_BOARDINFO_LATE /* Calls show_board_info() */
>
> /* Board-specific serial config */
> #define CONFIG_TEGRA_ENABLE_UARTA
> diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
> index be773a3..0e622fb 100644
> --- a/include/configs/colibri_vf.h
> +++ b/include/configs/colibri_vf.h
> @@ -1,7 +1,7 @@
> /*
> - * Copyright 2015 Toradex, Inc.
> + * Copyright 2015-2016 Toradex, Inc.
> *
> - * Configuration settings for the Toradex VF50/VF61 module.
> + * Configuration settings for the Toradex VF50/VF61 modules.
> *
> * Based on vf610twr.h:
> * Copyright 2013 Freescale Semiconductor, Inc.
> @@ -21,6 +21,7 @@
> #define CONFIG_SYS_FSL_CLK
>
> #define CONFIG_ARCH_MISC_INIT
> +#define CONFIG_DISPLAY_BOARDINFO_LATE /* Calls show_board_info() */
>
> #define CONFIG_SKIP_LOWLEVEL_INIT
>
> @@ -36,6 +37,7 @@
>
> /* Allow to overwrite serial and ethaddr */
> #define CONFIG_ENV_OVERWRITE
> +#define CONFIG_ENV_VARS_UBOOT_CONFIG
> #define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
> #define CONFIG_BAUDRATE 115200
^ permalink raw reply
* Re: [PATCH] EDAC, xgene: fix spelling mistake in error messages
From: Loc Ho @ 2016-11-14 23:18 UTC (permalink / raw)
To: Colin King
Cc: Borislav Petkov, Mauro Carvalho Chehab, linux-edac,
Linux Kernel Mailing List
In-Reply-To: <20161114231104.5585-1-colin.king@canonical.com>
Hi,
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake "Mutilple" to "Multiple"
> in error messages
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/edac/xgene_edac.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/edac/xgene_edac.c b/drivers/edac/xgene_edac.c
> index bf19b6e..5569391 100644
> --- a/drivers/edac/xgene_edac.c
> +++ b/drivers/edac/xgene_edac.c
> @@ -1602,16 +1602,16 @@ static void xgene_edac_pa_report(struct edac_device_ctl_info *edac_dev)
> dev_err(edac_dev->dev, "IOB PA read data RAM error\n");
> if (reg & IOBPA_M_RDATA_CORRUPT_MASK)
> dev_err(edac_dev->dev,
> - "Mutilple IOB PA read data RAM error\n");
> + "Multiple IOB PA read data RAM error\n");
> if (reg & IOBPA_WDATA_CORRUPT_MASK)
> dev_err(edac_dev->dev, "IOB PA write data RAM error\n");
> if (reg & IOBPA_M_WDATA_CORRUPT_MASK)
> dev_err(edac_dev->dev,
> - "Mutilple IOB PA write data RAM error\n");
> + "Multiple IOB PA write data RAM error\n");
> if (reg & IOBPA_TRANS_CORRUPT_MASK)
> dev_err(edac_dev->dev, "IOB PA transaction error\n");
> if (reg & IOBPA_M_TRANS_CORRUPT_MASK)
> - dev_err(edac_dev->dev, "Mutilple IOB PA transaction error\n");
> + dev_err(edac_dev->dev, "Multiple IOB PA transaction error\n");
> if (reg & IOBPA_REQIDRAM_CORRUPT_MASK)
> dev_err(edac_dev->dev, "IOB PA transaction ID RAM error\n");
> if (reg & IOBPA_M_REQIDRAM_CORRUPT_MASK)
Reviewed-by: Loc Ho <lho@apm.com>
-Loc
^ permalink raw reply
* [Buildroot] [PATCH v1] qt5base: fix eglfs compile for odroid-mali
From: Peter Seiderer @ 2016-11-14 23:16 UTC (permalink / raw)
To: buildroot
Avoid duplicated struct fbdev_window definition (introduced by [1]) by
renaming struct fbdev_window to shadow_fbdev_window.
Fixes [2]:
qeglfsmaliintegration.cpp:45:8: error: redefinition of 'struct fbdev_window'
struct fbdev_window {
^
In file included from /accts/mlweber1/rc-buildroot-test/scripts/instance-0/output/host/usr/aarch64-buildroot-linux-gnu/sysroot/usr/include/EGL/eglplatform.h:28:0,
from /accts/mlweber1/rc-buildroot-test/scripts/instance-0/output/host/usr/aarch64-buildroot-linux-gnu/sysroot/usr/include/EGL/egl.h:36,
from ../../../eglfs/qeglfsglobal.h:45,
from ../../../eglfs/qeglfsdeviceintegration.h:48,
from qeglfsmaliintegration.h:37,
from qeglfsmaliintegration.cpp:34:
[1] https://code.qt.io/cgit/qt/qtbase.git/commit/?h=dev&id=58bed4cda98e8e25db8adc61c7db73b6853077dc
[2] http://autobuild.buildroot.net/results/48c/48c458c035162169e8ca7c34ae65e9064822f25a
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
---
...fs-fix-eglfs_mali-compile-for-odroid-mali.patch | 53 ++++++++++++++++++++++
1 file changed, 53 insertions(+)
create mode 100644 package/qt5/qt5base/0007-eglfs-fix-eglfs_mali-compile-for-odroid-mali.patch
diff --git a/package/qt5/qt5base/0007-eglfs-fix-eglfs_mali-compile-for-odroid-mali.patch b/package/qt5/qt5base/0007-eglfs-fix-eglfs_mali-compile-for-odroid-mali.patch
new file mode 100644
index 0000000..cbafb39
--- /dev/null
+++ b/package/qt5/qt5base/0007-eglfs-fix-eglfs_mali-compile-for-odroid-mali.patch
@@ -0,0 +1,53 @@
+From b6c602e4264021f98ec2c72316e2a2000bf35e82 Mon Sep 17 00:00:00 2001
+From: Peter Seiderer <ps.report@gmx.net>
+Date: Mon, 14 Nov 2016 23:42:25 +0100
+Subject: [PATCH] eglfs: fix eglfs_mali compile for odroid-mali
+
+Avoid duplicated struct fbdev_window definition (introduced by [1]) by
+renaming struct fbdev_window to shadow_fbdev_window.
+
+Fixes the following buildroot compile failure ([2]):
+
+qeglfsmaliintegration.cpp:45:8: error: redefinition of 'struct fbdev_window'
+ struct fbdev_window {
+ ^
+In file included from /accts/mlweber1/rc-buildroot-test/scripts/instance-0/output/host/usr/aarch64-buildroot-linux-gnu/sysroot/usr/include/EGL/eglplatform.h:28:0,
+ from /accts/mlweber1/rc-buildroot-test/scripts/instance-0/output/host/usr/aarch64-buildroot-linux-gnu/sysroot/usr/include/EGL/egl.h:36,
+ from ../../../eglfs/qeglfsglobal.h:45,
+ from ../../../eglfs/qeglfsdeviceintegration.h:48,
+ from qeglfsmaliintegration.h:37,
+ from qeglfsmaliintegration.cpp:34:
+
+[1] https://code.qt.io/cgit/qt/qtbase.git/commit/?h=dev&id=58bed4cda98e8e25db8adc61c7db73b6853077dc
+[2] http://autobuild.buildroot.net/results/48c/48c458c035162169e8ca7c34ae65e9064822f25a
+
+Signed-off-by: Peter Seiderer <ps.report@gmx.net>
+---
+ .../eglfs/deviceintegration/eglfs_mali/qeglfsmaliintegration.cpp | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/plugins/platforms/eglfs/deviceintegration/eglfs_mali/qeglfsmaliintegration.cpp b/src/plugins/platforms/eglfs/deviceintegration/eglfs_mali/qeglfsmaliintegration.cpp
+index 43decdf..aeba83f 100644
+--- a/src/plugins/platforms/eglfs/deviceintegration/eglfs_mali/qeglfsmaliintegration.cpp
++++ b/src/plugins/platforms/eglfs/deviceintegration/eglfs_mali/qeglfsmaliintegration.cpp
+@@ -42,7 +42,7 @@
+
+ QT_BEGIN_NAMESPACE
+
+-struct fbdev_window {
++struct shadow_fbdev_window {
+ unsigned short width;
+ unsigned short height;
+ };
+@@ -85,7 +85,7 @@ EGLNativeWindowType QEglFSMaliIntegration::createNativeWindow(QPlatformWindow *w
+ Q_UNUSED(window);
+ Q_UNUSED(format);
+
+- fbdev_window *fbwin = reinterpret_cast<fbdev_window *>(malloc(sizeof(fbdev_window)));
++ shadow_fbdev_window *fbwin = reinterpret_cast<shadow_fbdev_window *>(malloc(sizeof(shadow_fbdev_window)));
+ if (NULL == fbwin)
+ return 0;
+
+--
+2.8.1
+
--
2.8.1
^ permalink raw reply related
* ✓ Fi.CI.BAT: success for drm/i915: cleanup use of INSTR_CLIENT_MASK
From: Patchwork @ 2016-11-14 23:15 UTC (permalink / raw)
To: Matthew Auld; +Cc: intel-gfx
In-Reply-To: <1479163174-29686-1-git-send-email-matthew.auld@intel.com>
== Series Details ==
Series: drm/i915: cleanup use of INSTR_CLIENT_MASK
URL : https://patchwork.freedesktop.org/series/15306/
State : success
== Summary ==
Series 15306v1 drm/i915: cleanup use of INSTR_CLIENT_MASK
https://patchwork.freedesktop.org/api/1.0/series/15306/revisions/1/mbox/
fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15
fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40
fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28
fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28
fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32
fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20
fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20
fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53
fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14
fi-skl-6700hq total:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21
fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32
fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33
2f21978cfd8984c79e4cbd77ce63d9f73fe226ef drm-intel-nightly: 2016y-11m-14d-21h-23m-10s UTC integration manifest
ee0d578 drm/i915: cleanup use of INSTR_CLIENT_MASK
== Logs ==
For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2991/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ 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.