* Re: [Patch v2 00/14] MIPS: Use MACHINEOVERRIDES and reduce duplication
From: Khem Raj @ 2016-11-08 17:44 UTC (permalink / raw)
To: Zubair Lutfullah Kakakhel, openembedded-core
In-Reply-To: <20161108171235.41837-1-Zubair.Kakakhel@imgtec.com>
[-- Attachment #1.1: Type: text/plain, Size: 2516 bytes --]
On 11/8/16 9:12 AM, Zubair Lutfullah Kakakhel wrote:
> Hi,
>
> This patch series adds a few MACHINEOVERRIDES options in arch-mips
> to reduce duplicate configurations in various recipes.
>
> Further info in
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10404
>
This series looks good to me.
Thanks for doing this.
> Regards,
> ZubairLK
>
> V1 -> V2
> Added more options for endian independent and big/little endian
> Added another patch for o32 in TUNE_FEATURES for MIPS32R6.
>
> Zubair Lutfullah Kakakhel (14):
> arch-mips: Add o32 in TUNE_FEATURES for MIPS32R6
> arch-mips: Add MACHINEOVERRIDES variables to reduce duplication
> bitbake.conf: Reduce duplication in MIPS variants
> fts: Reduce duplication in MIPS variants.
> glibc: Reduce duplication in MIPS variants
> packagegroup: Reduce duplication in MIPS variants.
> gcc-runtime: Reduce duplication in MIPS variants.
> gdb: Reduce duplication in MIPS variants.
> mmc-utils: Reduce duplication in MIPS variants.
> valgrind: Reduce duplication in MIPS variants.
> ghostscript: Reduce duplication in MIPS variants.
> ltp: Reduce duplication in MIPS variants.
> mdadm: Reduce duplication in MIPS variants.
> webkit: Reduce duplication in MIPS variants.
>
> meta/conf/bitbake.conf | 11 +----------
> meta/conf/machine/include/mips/README | 3 +++
> meta/conf/machine/include/mips/arch-mips.inc | 12 ++++++++++++
> meta/conf/machine/include/tune-mips32r6.inc | 8 ++++----
> meta/recipes-core/fts/fts.bb | 5 +----
> meta/recipes-core/glibc/glibc-ld.inc | 17 ++---------------
> .../recipes-core/packagegroups/packagegroup-core-sdk.bb | 5 +----
> .../packagegroups/packagegroup-core-tools-profile.bb | 10 ++--------
> meta/recipes-devtools/gcc/gcc-runtime.inc | 9 +--------
> meta/recipes-devtools/gdb/gdb-common.inc | 7 +------
> meta/recipes-devtools/mmc/mmc-utils_git.bb | 4 ++--
> meta/recipes-devtools/valgrind/valgrind_3.12.0.bb | 3 +--
> meta/recipes-extended/ghostscript/ghostscript_9.19.bb | 3 +--
> meta/recipes-extended/ltp/ltp_20160126.bb | 2 +-
> meta/recipes-extended/mdadm/mdadm_3.4.bb | 4 ++--
> meta/recipes-sato/webkit/webkitgtk_2.14.1.bb | 3 +--
> 16 files changed, 36 insertions(+), 70 deletions(-)
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply
* [Intel-wired-lan] I am looking for a specific driver - 3.4.8-k
From: Jeff Kirsher @ 2016-11-08 17:44 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <OFBF794E37.EA201181-ON86258065.0050FFD1-86258065.0051242C@graco.com>
On Tue, 2016-11-08 at 08:46 -0600, SKahn at graco.com wrote:
> I am trying to locate a driver for X520 Dual Port 10 G Ethernet PICe
> Adapter, this version specifically - Manufacturer = Intel
> Adapter Driver = 3.4.8-k .
>
> This is for a Cisco UCSC system with RedHat Linux 5.8 64 bit
You should be able to find the version of ixgbe driver you are looking for
on e1000.sf.net.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20161108/413faf58/attachment.asc>
^ permalink raw reply
* ✗ Fi.CI.BAT: warning for drm/i915: Add a per-pipe plane identifier enum (rev3)
From: Patchwork @ 2016-11-08 17:45 UTC (permalink / raw)
To: ville.syrjala; +Cc: intel-gfx
In-Reply-To: <1478616439-10150-1-git-send-email-ville.syrjala@linux.intel.com>
== Series Details ==
Series: drm/i915: Add a per-pipe plane identifier enum (rev3)
URL : https://patchwork.freedesktop.org/series/14978/
State : warning
== Summary ==
Series 14978v3 drm/i915: Add a per-pipe plane identifier enum
https://patchwork.freedesktop.org/api/1.0/series/14978/revisions/3/mbox/
Test drv_module_reload_basic:
dmesg-warn -> PASS (fi-skl-6770hq)
Test gem_exec_suspend:
Subgroup basic-s3:
pass -> DMESG-WARN (fi-skl-6260u)
pass -> DMESG-WARN (fi-skl-6700hq)
pass -> DMESG-WARN (fi-skl-6770hq)
pass -> DMESG-WARN (fi-skl-6700k)
pass -> DMESG-WARN (fi-kbl-7200u)
Test kms_busy:
Subgroup basic-flip-default-c:
pass -> DMESG-WARN (fi-bxt-t5700)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-busy-flip-before-cursor-varying-size:
pass -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-flip-after-cursor-legacy:
pass -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-flip-after-cursor-varying-size:
pass -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-flip-before-cursor-legacy:
pass -> DMESG-WARN (fi-skl-6770hq)
Subgroup basic-flip-before-cursor-varying-size:
pass -> DMESG-WARN (fi-skl-6770hq)
fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15
fi-bxt-t5700 total:244 pass:215 dwarn:1 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:221 dwarn:1 dfail:0 fail:0 skip:22
fi-skl-6260u total:244 pass:229 dwarn:1 dfail:0 fail:0 skip:14
fi-skl-6700hq total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21
fi-skl-6700k total:244 pass:221 dwarn:2 dfail:0 fail:0 skip:21
fi-skl-6770hq total:244 pass:223 dwarn:7 dfail:0 fail:0 skip:14
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
9435ffb9ffbfecfa5a429a46af96b1b3fda41d6c drm-intel-nightly: 2016y-11m-08d-13h-53m-48s UTC integration manifest
ee2cdee drm/i915: Don't populate plane->plane for cursors and sprites
f43966f drm/i915: Rename the local 'plane' variable to 'plane_id' in primary plane code
04a0e37 drm/i915: Use enum plane_id in VLV/CHV wm code
db5553c drm/i915: Use enum plane_id in VLV/CHV sprite code
6a71330 drm/i915: Use enum plane_id in SKL plane code
e88c3fb drm/i915: Use enum plane_id in SKL wm code
cc004ca drm/i915: Add crtc->plane_ids_mask
616c141 drm/i915: Add per-pipe plane identifier
49d3701 drm/i915: Remove some duplicated plane swapping logic
== Logs ==
For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2935/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v11 11/22] vfio iommu: Add blocking notifier to notify DMA_UNMAP
From: Alex Williamson @ 2016-11-08 17:46 UTC (permalink / raw)
To: Kirti Wankhede
Cc: pbonzini, kraxel, cjia, qemu-devel, kvm, kevin.tian, jike.song,
bjsdjshi, linux-kernel
In-Reply-To: <a2e3a1dd-696f-2d2b-023d-ccc662e90e95@nvidia.com>
On Tue, 8 Nov 2016 21:56:29 +0530
Kirti Wankhede <kwankhede@nvidia.com> wrote:
> On 11/8/2016 5:15 AM, Alex Williamson wrote:
> > On Sat, 5 Nov 2016 02:40:45 +0530
> > Kirti Wankhede <kwankhede@nvidia.com> wrote:
> >
> ...
> >>
> >> +int vfio_register_notifier(struct device *dev, struct notifier_block *nb)
> >
> > Is the expectation here that this is a generic notifier for all
> > vfio->mdev signaling? That should probably be made clear in the mdev
> > API to avoid vendor drivers assuming their notifier callback only
> > occurs for unmaps, even if that's currently the case.
> >
>
> Ok. Adding comment about notifier callback in mdev_device which is part
> of next patch.
>
> ...
>
> >> mutex_lock(&iommu->lock);
> >>
> >> - if (!iommu->external_domain) {
> >> + /* Fail if notifier list is empty */
> >> + if ((!iommu->external_domain) || (!iommu->notifier.head)) {
> >> ret = -EINVAL;
> >> goto pin_done;
> >> }
> >> @@ -867,6 +870,11 @@ unlock:
> >> /* Report how much was unmapped */
> >> unmap->size = unmapped;
> >>
> >> + if (unmapped && iommu->external_domain)
> >> + blocking_notifier_call_chain(&iommu->notifier,
> >> + VFIO_IOMMU_NOTIFY_DMA_UNMAP,
> >> + unmap);
> >
> > This is after the fact, there's already a gap here where pages are
> > unpinned and the mdev device is still running.
>
> Oh, there is a bug here, now unpin_pages() take user_pfn as argument and
> find vfio_dma. If its not found, it doesn't unpin pages. We have to call
> this notifier before vfio_remove_dma(). But if we call this before
> vfio_remove_dma() there will be deadlock since iommu->lock is already
> held here and vfio_iommu_type1_unpin_pages() will also try to hold
> iommu->lock.
> If we want to call blocking_notifier_call_chain() before
> vfio_remove_dma(), sequence should be:
>
> unmapped += dma->size;
> mutex_unlock(&iommu->lock);
> if (iommu->external_domain)) {
> struct vfio_iommu_type1_dma_unmap nb_unmap;
>
> nb_unmap.iova = dma->iova;
> nb_unmap.size = dma->size;
> blocking_notifier_call_chain(&iommu->notifier,
> VFIO_IOMMU_NOTIFY_DMA_UNMAP,
> &nb_unmap);
> }
> mutex_lock(&iommu->lock);
> vfio_remove_dma(iommu, dma);
It seems like it would be worthwhile to have the rb-tree rooted in the
vfio-dma, then we only need to call the notifier if there are pages
pinned within that vfio-dma (ie. the rb-tree is not empty). We can
then release the lock call the notifier, re-acquire the lock, and
BUG_ON if the rb-tree still is not empty. We might get duplicate pfns
between separate vfio_dma structs, but as I mentioned in other replies,
that seems like an exception that we don't need to optimize for.
> > The notifier needs to
> > happen prior to that and I suspect that we need to validate that we
> > have no remaining external pfn references within this vfio_dma block.
> > It seems like we need to root our pfn tracking in the vfio_dma so that
> > we can see that it's empty after the notifier chain and BUG_ON if not.
>
> There is no way to find pfns from that iova range with current
> implementation. We can have this validate if we go with linear array of
> iova to track pfns.
Right, I was still hoping to avoid storing the pfn even with the
array/page-table approach though, ask the mm layer for the mapping
again. Is that too much overhead? Maybe the page table could store
the phys addr and we could use PAGE_MASK to store the reference count
so that each entry is still only 8bytes(?)
> > I would also add some enforcement that external pinning is only enabled
> > when vfio_iommu_type1 is configured for v2 semantics (ie. we only
> > support unmaps exactly matching previous maps).
> >
>
> Ok I'll add that check.
>
> Thanks,
> Kirti
^ permalink raw reply
* [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
From: Russell King - ARM Linux @ 2016-11-08 17:46 UTC (permalink / raw)
To: linus-amlogic
In-Reply-To: <fb4348a8-197c-2219-ff01-8716e2a0b955@arm.com>
On Tue, Nov 08, 2016 at 05:37:25PM +0000, Sudeep Holla wrote:
>
>
> On 08/11/16 16:06, Russell King - ARM Linux wrote:
> >On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
> >>As it contains a zero sized Image and .dtb files, I tried copying my
> >>Image and .dtb over, and also copied my original config.txt (only
> >>change is AUTORUN: FALSE). It still doesn't appear to boot beyond
> >>this point.
> >
> >Well, it seems that I can't even go back to my original set of firmware
> >as UEFI has stopped working:
> >
> >NOTICE: Booting Trusted Firmware
> >NOTICE: BL1: v1.0(release):14b6608
> >NOTICE: BL1: Built : 14:15:51, Sep 1 2014
> >NOTICE: BL1: Booting BL2
> >NOTICE: BL2: v1.0(release):14b6608
> >NOTICE: BL2: Built : 14:15:51, Sep 1 2014
> >NOTICE: BL1: Booting BL3-1
> >NOTICE: BL3-1: v1.0(release):14b6608
> >NOTICE: BL3-1: Built : 14:15:53, Sep 1 2014
> >UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
> >Warning: Fail to load FDT file 'juno.dtb'.
> >
>
> This again because of incompatibility of the configuration data saved in
> NOR flash. The erase command I gave early is to erase that when you
> switched between the UEFI binaries. It's really horrible mess UEFI
> created in the initial days of Juno, and hopefully they have moved to
> some standard format these days.
Yea, what it means is I've no possibility to go back to what was
originally working now, since I don't understand how to get UEFI to
behave (Will set the machine up for me, I don't have any information
on how it was originally configured other than what was on the uSD
card, which appears incomplete.)
> >and UEFI is the most unfriendly thing going - the "boot manager" thing
> >doesn't let you view the configuration:
> >
>
> I completely agree. I had real bad times in past dealing with such
> things in UEFI.
>
> >[1] Linux from NOR Flash
> >[2] Shell
> >[3] Boot Manager
> >Start: 3
> >[1] Add Boot Device Entry
> >[2] Update Boot Device Entry
> >[3] Remove Boot Device Entry
> >[4] Reorder Boot Device Entries
> >[5] Update FDT path
> >[6] Set Boot Timeout
> >[7] Return to main menu
> >Choice:
> >
> >and dropping into the shell... well, I've no idea how to get a listing
> >of what it thinks is in the NOR device (or even how to refer to the
> >NOR device.) "devices" shows nothing that's even remotely English.
> >
>
> I think startup.nsh needs some edits. Just replace it with something like:
>
> "norkern dtb=board.dtb console=ttyAMA0,115200n8 root=/dev/nfs rw
> rootwait ip=dhcp systemd.log_target=null nfsroot=..." or something
> alike. Currently it just echos and stops.
>
> Regarding the new firmware stopping abruptly, I have no clue, except
> asking you to erase the flash completely when switching between the
> firmware versions. That has worked for me for all UEFI related issues in
> the past. It's really annoying I understand.
>
> flash> eraseall
I've tried that, it still stops at the same point, after:
FV2 Hob 0xFE07B000 - 0xFE8253BF
and remains unresponsive.
I do notice that the uSD card becomes visible through USB at this point
though.
Okay, well, I'm going to have to disable Juno from the nightly boots
until we get some kind of resolution on this, as my Juno is now
incapable of booting anything.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
From: Russell King - ARM Linux @ 2016-11-08 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fb4348a8-197c-2219-ff01-8716e2a0b955@arm.com>
On Tue, Nov 08, 2016 at 05:37:25PM +0000, Sudeep Holla wrote:
>
>
> On 08/11/16 16:06, Russell King - ARM Linux wrote:
> >On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
> >>As it contains a zero sized Image and .dtb files, I tried copying my
> >>Image and .dtb over, and also copied my original config.txt (only
> >>change is AUTORUN: FALSE). It still doesn't appear to boot beyond
> >>this point.
> >
> >Well, it seems that I can't even go back to my original set of firmware
> >as UEFI has stopped working:
> >
> >NOTICE: Booting Trusted Firmware
> >NOTICE: BL1: v1.0(release):14b6608
> >NOTICE: BL1: Built : 14:15:51, Sep 1 2014
> >NOTICE: BL1: Booting BL2
> >NOTICE: BL2: v1.0(release):14b6608
> >NOTICE: BL2: Built : 14:15:51, Sep 1 2014
> >NOTICE: BL1: Booting BL3-1
> >NOTICE: BL3-1: v1.0(release):14b6608
> >NOTICE: BL3-1: Built : 14:15:53, Sep 1 2014
> >UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
> >Warning: Fail to load FDT file 'juno.dtb'.
> >
>
> This again because of incompatibility of the configuration data saved in
> NOR flash. The erase command I gave early is to erase that when you
> switched between the UEFI binaries. It's really horrible mess UEFI
> created in the initial days of Juno, and hopefully they have moved to
> some standard format these days.
Yea, what it means is I've no possibility to go back to what was
originally working now, since I don't understand how to get UEFI to
behave (Will set the machine up for me, I don't have any information
on how it was originally configured other than what was on the uSD
card, which appears incomplete.)
> >and UEFI is the most unfriendly thing going - the "boot manager" thing
> >doesn't let you view the configuration:
> >
>
> I completely agree. I had real bad times in past dealing with such
> things in UEFI.
>
> >[1] Linux from NOR Flash
> >[2] Shell
> >[3] Boot Manager
> >Start: 3
> >[1] Add Boot Device Entry
> >[2] Update Boot Device Entry
> >[3] Remove Boot Device Entry
> >[4] Reorder Boot Device Entries
> >[5] Update FDT path
> >[6] Set Boot Timeout
> >[7] Return to main menu
> >Choice:
> >
> >and dropping into the shell... well, I've no idea how to get a listing
> >of what it thinks is in the NOR device (or even how to refer to the
> >NOR device.) "devices" shows nothing that's even remotely English.
> >
>
> I think startup.nsh needs some edits. Just replace it with something like:
>
> "norkern dtb=board.dtb console=ttyAMA0,115200n8 root=/dev/nfs rw
> rootwait ip=dhcp systemd.log_target=null nfsroot=..." or something
> alike. Currently it just echos and stops.
>
> Regarding the new firmware stopping abruptly, I have no clue, except
> asking you to erase the flash completely when switching between the
> firmware versions. That has worked for me for all UEFI related issues in
> the past. It's really annoying I understand.
>
> flash> eraseall
I've tried that, it still stops at the same point, after:
FV2 Hob 0xFE07B000 - 0xFE8253BF
and remains unresponsive.
I do notice that the uSD card becomes visible through USB at this point
though.
Okay, well, I'm going to have to disable Juno from the nightly boots
until we get some kind of resolution on this, as my Juno is now
incapable of booting anything.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
From: Russell King - ARM Linux @ 2016-11-08 17:46 UTC (permalink / raw)
To: Sudeep Holla
Cc: Philippe Robin, devicetree, Neil Armstrong, linux-kernel,
Olof Johansson, linux-amlogic, linux-arm-kernel
In-Reply-To: <fb4348a8-197c-2219-ff01-8716e2a0b955@arm.com>
On Tue, Nov 08, 2016 at 05:37:25PM +0000, Sudeep Holla wrote:
>
>
> On 08/11/16 16:06, Russell King - ARM Linux wrote:
> >On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
> >>As it contains a zero sized Image and .dtb files, I tried copying my
> >>Image and .dtb over, and also copied my original config.txt (only
> >>change is AUTORUN: FALSE). It still doesn't appear to boot beyond
> >>this point.
> >
> >Well, it seems that I can't even go back to my original set of firmware
> >as UEFI has stopped working:
> >
> >NOTICE: Booting Trusted Firmware
> >NOTICE: BL1: v1.0(release):14b6608
> >NOTICE: BL1: Built : 14:15:51, Sep 1 2014
> >NOTICE: BL1: Booting BL2
> >NOTICE: BL2: v1.0(release):14b6608
> >NOTICE: BL2: Built : 14:15:51, Sep 1 2014
> >NOTICE: BL1: Booting BL3-1
> >NOTICE: BL3-1: v1.0(release):14b6608
> >NOTICE: BL3-1: Built : 14:15:53, Sep 1 2014
> >UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
> >Warning: Fail to load FDT file 'juno.dtb'.
> >
>
> This again because of incompatibility of the configuration data saved in
> NOR flash. The erase command I gave early is to erase that when you
> switched between the UEFI binaries. It's really horrible mess UEFI
> created in the initial days of Juno, and hopefully they have moved to
> some standard format these days.
Yea, what it means is I've no possibility to go back to what was
originally working now, since I don't understand how to get UEFI to
behave (Will set the machine up for me, I don't have any information
on how it was originally configured other than what was on the uSD
card, which appears incomplete.)
> >and UEFI is the most unfriendly thing going - the "boot manager" thing
> >doesn't let you view the configuration:
> >
>
> I completely agree. I had real bad times in past dealing with such
> things in UEFI.
>
> >[1] Linux from NOR Flash
> >[2] Shell
> >[3] Boot Manager
> >Start: 3
> >[1] Add Boot Device Entry
> >[2] Update Boot Device Entry
> >[3] Remove Boot Device Entry
> >[4] Reorder Boot Device Entries
> >[5] Update FDT path
> >[6] Set Boot Timeout
> >[7] Return to main menu
> >Choice:
> >
> >and dropping into the shell... well, I've no idea how to get a listing
> >of what it thinks is in the NOR device (or even how to refer to the
> >NOR device.) "devices" shows nothing that's even remotely English.
> >
>
> I think startup.nsh needs some edits. Just replace it with something like:
>
> "norkern dtb=board.dtb console=ttyAMA0,115200n8 root=/dev/nfs rw
> rootwait ip=dhcp systemd.log_target=null nfsroot=..." or something
> alike. Currently it just echos and stops.
>
> Regarding the new firmware stopping abruptly, I have no clue, except
> asking you to erase the flash completely when switching between the
> firmware versions. That has worked for me for all UEFI related issues in
> the past. It's really annoying I understand.
>
> flash> eraseall
I've tried that, it still stops at the same point, after:
FV2 Hob 0xFE07B000 - 0xFE8253BF
and remains unresponsive.
I do notice that the uSD card becomes visible through USB at this point
though.
Okay, well, I'm going to have to disable Juno from the nightly boots
until we get some kind of resolution on this, as my Juno is now
incapable of booting anything.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH kvm-unit-tests 06/17] pci: introduce struct pci_dev
From: Alexander Gordeev @ 2016-11-08 17:54 UTC (permalink / raw)
To: Andrew Jones; +Cc: Peter Xu, kvm, rkrcmar, jan.kiszka, pbonzini
In-Reply-To: <20161108173554.mxzmva2qsa6gu5e4@kamzik.brq.redhat.com>
On Tue, Nov 08, 2016 at 06:35:54PM +0100, Andrew Jones wrote:
> On Tue, Nov 08, 2016 at 10:48:32AM -0500, Peter Xu wrote:
> > On Tue, Nov 08, 2016 at 01:27:31PM +0100, Alexander Gordeev wrote:
> > > On Fri, Nov 04, 2016 at 05:41:01PM +0100, Andrew Jones wrote:
> > > > > /* Scan bus look for a specific device. Only bus 0 scanned for now. */
> > > > > -pcidevaddr_t pci_find_dev(uint16_t vendor_id, uint16_t device_id)
> > > > > +int pci_find_dev(struct pci_dev *pci_dev, uint16_t vendor_id, uint16_t device_id)
> > > > > {
> > > > > pcidevaddr_t dev;
> > > > >
> > > > > - for (dev = 0; dev < 256; ++dev) {
> > > > > + for (dev = 0; dev < PCI_DEVFN_MAX; ++dev) {
> > > >
> > > > Why introduce this PCI_DEVFN_MAX define?
> > > >
> > > > > if (pci_config_readw(dev, PCI_VENDOR_ID) == vendor_id &&
> > > > > - pci_config_readw(dev, PCI_DEVICE_ID) == device_id)
> > > > > - return dev;
> > > > > + pci_config_readw(dev, PCI_DEVICE_ID) == device_id) {
> > > > > + pci_dev_init(pci_dev, dev);
> > > > > + return 0;
> > > > > + }
> > > > > }
> > > > >
> > > > > - return PCIDEVADDR_INVALID;
> > > > > + return -1;
> > > >
> > > > Why not use bool for the ret type; true=good, false=bad?
> > >
> > > Both ways look strange to me. I would leave pci_find_dev() as is (low-
> > > level) and move pci_dev_init() outside - so a usage would be i.e.:
> > >
> > > dev = pci_find_dev(PCI_VENDOR_ID_REDHAT, PCI_DEVICE_ID_REDHAT_TEST);
> > > if (dev == PCIDEVADDR_INVALID)
> > > ...
> > > pci_dev_init(&pci_dev, dev);
> >
> > IMHO actually it'll be nicer with:
> >
> > struct pci_dev *pci_find_dev(uint16_t vendor_id, uint16_t device_id);
>
> Yes, I was going to suggest this too, but then...
>
> >
> > But this needs dynamic allocation of memory, which might be an
> > overkill for kvm-unit-test. So I chose to allocate the pci_dev on
> > caller stack.
>
> ...saw the value of avoiding the alloc. That said, we do have precedent
> for allocating in lib/* code already (virtio_bind), and I am currently
> reworking x86's memory management code in order to enable malloc/calloc
> use within lib code for x86. So we could go the alloc way as well...
>
> >
> > Anyway, I take the interface issue as a matter of taste.
>
> Not quite. I see Alex's reasoning. Perhaps users want to simply query
> if a device is there (pci_find_dev), but not actually init a pci_dev
> struct each time they call it. Alex's proposal keeps pci_find_dev more
> generally useful.
Yep. So in the end of the day I would kept pci_find_dev() and added
pci_dev_alloc()/pci_dev_free() helpers (not sure about naming though).
The former would have to initialize pci_dev data to be consistent
and safely used by any other PCI API that takes pci_dev pointer.
> Thanks,
> drew
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v11 11/22] vfio iommu: Add blocking notifier to notify DMA_UNMAP
From: Alex Williamson @ 2016-11-08 17:46 UTC (permalink / raw)
To: Kirti Wankhede
Cc: pbonzini, kraxel, cjia, qemu-devel, kvm, kevin.tian, jike.song,
bjsdjshi, linux-kernel
In-Reply-To: <a2e3a1dd-696f-2d2b-023d-ccc662e90e95@nvidia.com>
On Tue, 8 Nov 2016 21:56:29 +0530
Kirti Wankhede <kwankhede@nvidia.com> wrote:
> On 11/8/2016 5:15 AM, Alex Williamson wrote:
> > On Sat, 5 Nov 2016 02:40:45 +0530
> > Kirti Wankhede <kwankhede@nvidia.com> wrote:
> >
> ...
> >>
> >> +int vfio_register_notifier(struct device *dev, struct notifier_block *nb)
> >
> > Is the expectation here that this is a generic notifier for all
> > vfio->mdev signaling? That should probably be made clear in the mdev
> > API to avoid vendor drivers assuming their notifier callback only
> > occurs for unmaps, even if that's currently the case.
> >
>
> Ok. Adding comment about notifier callback in mdev_device which is part
> of next patch.
>
> ...
>
> >> mutex_lock(&iommu->lock);
> >>
> >> - if (!iommu->external_domain) {
> >> + /* Fail if notifier list is empty */
> >> + if ((!iommu->external_domain) || (!iommu->notifier.head)) {
> >> ret = -EINVAL;
> >> goto pin_done;
> >> }
> >> @@ -867,6 +870,11 @@ unlock:
> >> /* Report how much was unmapped */
> >> unmap->size = unmapped;
> >>
> >> + if (unmapped && iommu->external_domain)
> >> + blocking_notifier_call_chain(&iommu->notifier,
> >> + VFIO_IOMMU_NOTIFY_DMA_UNMAP,
> >> + unmap);
> >
> > This is after the fact, there's already a gap here where pages are
> > unpinned and the mdev device is still running.
>
> Oh, there is a bug here, now unpin_pages() take user_pfn as argument and
> find vfio_dma. If its not found, it doesn't unpin pages. We have to call
> this notifier before vfio_remove_dma(). But if we call this before
> vfio_remove_dma() there will be deadlock since iommu->lock is already
> held here and vfio_iommu_type1_unpin_pages() will also try to hold
> iommu->lock.
> If we want to call blocking_notifier_call_chain() before
> vfio_remove_dma(), sequence should be:
>
> unmapped += dma->size;
> mutex_unlock(&iommu->lock);
> if (iommu->external_domain)) {
> struct vfio_iommu_type1_dma_unmap nb_unmap;
>
> nb_unmap.iova = dma->iova;
> nb_unmap.size = dma->size;
> blocking_notifier_call_chain(&iommu->notifier,
> VFIO_IOMMU_NOTIFY_DMA_UNMAP,
> &nb_unmap);
> }
> mutex_lock(&iommu->lock);
> vfio_remove_dma(iommu, dma);
It seems like it would be worthwhile to have the rb-tree rooted in the
vfio-dma, then we only need to call the notifier if there are pages
pinned within that vfio-dma (ie. the rb-tree is not empty). We can
then release the lock call the notifier, re-acquire the lock, and
BUG_ON if the rb-tree still is not empty. We might get duplicate pfns
between separate vfio_dma structs, but as I mentioned in other replies,
that seems like an exception that we don't need to optimize for.
> > The notifier needs to
> > happen prior to that and I suspect that we need to validate that we
> > have no remaining external pfn references within this vfio_dma block.
> > It seems like we need to root our pfn tracking in the vfio_dma so that
> > we can see that it's empty after the notifier chain and BUG_ON if not.
>
> There is no way to find pfns from that iova range with current
> implementation. We can have this validate if we go with linear array of
> iova to track pfns.
Right, I was still hoping to avoid storing the pfn even with the
array/page-table approach though, ask the mm layer for the mapping
again. Is that too much overhead? Maybe the page table could store
the phys addr and we could use PAGE_MASK to store the reference count
so that each entry is still only 8bytes(?)
> > I would also add some enforcement that external pinning is only enabled
> > when vfio_iommu_type1 is configured for v2 semantics (ie. we only
> > support unmaps exactly matching previous maps).
> >
>
> Ok I'll add that check.
>
> Thanks,
> Kirti
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 2/3] target-i386: Add Intel HAX files
From: Paolo Bonzini @ 2016-11-08 17:46 UTC (permalink / raw)
To: Vincent Palatin, qemu-devel
In-Reply-To: <dc1f10ce25eab9d517675e0bdecfc6f4f65d77af.1478619442.git.vpalatin@chromium.org>
On 08/11/2016 16:39, Vincent Palatin wrote:
> + /* need tcg for non-UG platform in real mode */
> + if (!hax_ug_platform())
> + tcg_exec_init(tcg_tb_size * 1024 * 1024);
> +
Oh, it does support unrestricted guest, and in fact without unrestricted
guest you don't even have SMP!
Would you post a v2 that removes (after this patch 2) as much code as
possible related to non-UG platforms?
Paolo
^ permalink raw reply
* [ceph-client:testing 2/2] fs/ceph/file.c:615:2: warning: format '%ld' expects argument of type 'long int', but argument 2 has type 'ssize_t'
From: kbuild test robot @ 2016-11-08 17:47 UTC (permalink / raw)
To: Yan, Zheng; +Cc: kbuild-all, ceph-devel
[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]
tree: https://github.com/ceph/ceph-client.git testing
head: cf30eb1d9821be4e575321a518221172b222d893
commit: cf30eb1d9821be4e575321a518221172b222d893 [2/2] ceph: fix splice read for no Fc capability case
config: i386-randconfig-c0-11090107 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout cf30eb1d9821be4e575321a518221172b222d893
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
fs/ceph/file.c: In function 'ceph_sync_read':
>> fs/ceph/file.c:615:2: warning: format '%ld' expects argument of type 'long int', but argument 2 has type 'ssize_t' [-Wformat=]
dout("sync_read result %ld\n", ret);
^
vim +615 fs/ceph/file.c
599 l = copy_page_to_iter(pages[k++], page_off,
600 copy, to);
601 off += l;
602 left -= l;
603 if (l < copy)
604 break;
605 }
606 }
607 ceph_release_page_vector(pages, num_pages);
608 }
609
610 if (off > iocb->ki_pos) {
611 ret = off - iocb->ki_pos;
612 iocb->ki_pos = off;
613 }
614
> 615 dout("sync_read result %ld\n", ret);
616 return ret;
617 }
618
619 struct ceph_aio_request {
620 struct kiocb *iocb;
621 size_t total_len;
622 int write;
623 int error;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29253 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] qla2xxx: fix errors in PCI device remove with ongoing I/O
From: Madhani, Himanshu @ 2016-11-08 17:47 UTC (permalink / raw)
To: Mauricio Faria de Oliveira, qla2xxx-upstream@qlogic.com
Cc: jejb@linux.vnet.ibm.com, martin.petersen@oracle.com,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1478548411-17932-1-git-send-email-mauricfo@linux.vnet.ibm.com>
On 11/7/16, 11:53 AM, "Mauricio Faria de Oliveira" <mauricfo@linux.vnet.ibm.com> wrote:
>This patchset addresses a couple of errors that might happen during
>PCI device remove (e.g., PCI hotplug, PowerVM DLPAR), which prevent
>the successful removal and re-addition of the adapter to the system,
>and cause an oops and/or invalid DMA access (triggers an EEH event).
>
>It allowed several cycles of PCI device add/remove with ongoing I/O,
>to complete successfully without triggering oopses or EEH events.
>
>Verified on v4.9-rc3.
>
>Test-case:
>---
> # lspci
> <...>
> 001d:70:00.0 Fibre Channel: QLogic Corp. ISP2532-based ...
> 001d:70:00.1 Fibre Channel: QLogic Corp. ISP2532-based ...
> <...>
>
> # for sd in $(find /sys/bus/pci/devices/001d:70:00.*/ \
> -name 'sd*' -printf "%f\n"); do \
> dd if=/dev/$sd of=/dev/null iflag=nocache & done
>
> # echo 1 | tee /sys/bus/pci/devices/001d:70:00.*/remove
> (this either works or not)
>
> # echo 1 > /sys/bus/pci/rescan
>
>Before:
>---
> <...>
> EEH: Frozen PHB#1d-PE#700000 detected
> qla2xxx [001d:70:00.1]-8042:2: PCI/Register disconnect, exiting.
> <...>
> EEH: Detected PCI bus error on PHB#29-PE#700000
> <...>
> (and/or)
> Unable to handle kernel paging request for data at address 0x00000138
> <...>
> NIP [d000000004700a40] qla2xxx_queuecommand+0x80/0x3f0 [qla2xxx]
> LR [d000000004700a10] qla2xxx_queuecommand+0x50/0x3f0 [qla2xxx]
>
> (command does not return; adapter cannot be re-added)
>
>After:
>---
> <...>
> qla2xxx [001d:70:00.0]-801c:1: Abort command issued nexus=1:0:0 -- 1 2003.
> <...>
> qla2xxx [001d:70:00.1]-801c:2: Abort command issued nexus=2:3:0 -- 1 2003.
> <...>
>
> (command does return; adapter can be re-added correctly)
>
>
>Mauricio Faria de Oliveira (2):
> qla2xxx: do not queue commands when unloading
> qla2xxx: fix invalid DMA access after command aborts in PCI device
> remove
>
> drivers/scsi/qla2xxx/qla_os.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
>--
>1.8.3.1
>
Thanks for the patches. Series Looks Good.
Acked-by: Himanshu Madhani <himanshu.madhani@cavium.com>
>
^ permalink raw reply
* [U-Boot] [PATCH v3] rpi: passthrough of the firmware provided FDT blob
From: Cédric Schieli @ 2016-11-08 17:47 UTC (permalink / raw)
To: u-boot
Raspberry firmware used to pass a FDT blob at a fixed address (0x100),
but this is not true anymore. The address now depends on both the
memory size and the blob size [1].
If one wants to passthrough this FDT blob to the kernel, the most
reliable way is to save its address from the r2/x0 register in the
U-Boot entry point and expose it in a environment variable for
further processing.
This patch just does this:
- save the provided address in the global variable fw_dtb_pointer
- expose it in ${fdt_addr} if it points to a a valid FDT blob
There are many different ways to use it. One can, for example, use
the following script which will extract from the tree the command
line built by the firmware, then hand over the blob to a previously
loaded kernel:
fdt addr ${fdt_addr}
fdt get value bootargs /chosen bootargs
bootz ${kernel_addr_r} - ${fdt_addr}
Alternatively, users relying on sysboot/pxe can simply omit any FDT
statement in their extlinux.conf file, U-Boot will automagically pick
${fdt_addr} and pass it to the kernel.
[1] https://www.raspberrypi.org/forums//viewtopic.php?f=107&t=134018
Signed-off-by: C?dric Schieli <cschieli@gmail.com>
---
Changes in v3:
- revert back to assembly for save_boot_params()
Changes in v2:
- merge the series in a single patch
- convert the save_boot_params() function to C code
- add a board_get_usable_ram_top() function to protect the blob
during relocation
- remove the (obsolete) extern declaration from include/configs/rpi.h
- rename the global variable to fw_dtb_pointer
- rename the environment variable to ${fdt_addr}
- fix 64-bits compatibility issues
- document possible uses of ${fdt_addr}
board/raspberrypi/rpi/Makefile | 1 +
board/raspberrypi/rpi/lowlevel_init.S | 36 +++++++++++++++++++++++++++++++++++
board/raspberrypi/rpi/rpi.c | 29 ++++++++++++++++++++++++++++
3 files changed, 66 insertions(+)
create mode 100644 board/raspberrypi/rpi/lowlevel_init.S
diff --git a/board/raspberrypi/rpi/Makefile b/board/raspberrypi/rpi/Makefile
index 4ce2c98..dcb25ac 100644
--- a/board/raspberrypi/rpi/Makefile
+++ b/board/raspberrypi/rpi/Makefile
@@ -5,3 +5,4 @@
#
obj-y := rpi.o
+obj-y += lowlevel_init.o
diff --git a/board/raspberrypi/rpi/lowlevel_init.S b/board/raspberrypi/rpi/lowlevel_init.S
new file mode 100644
index 0000000..cdbd8e1
--- /dev/null
+++ b/board/raspberrypi/rpi/lowlevel_init.S
@@ -0,0 +1,36 @@
+/*
+ * (C) Copyright 2016
+ * C?dric Schieli <cschieli@gmail.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include <config.h>
+
+.align 8
+.global fw_dtb_pointer
+fw_dtb_pointer:
+#ifdef CONFIG_ARM64
+ .dword 0x0
+#else
+ .word 0x0
+#endif
+
+/*
+ * Routine: save_boot_params (called after reset from start.S)
+ * Description: save ATAG/FDT address provided by the firmware at boot time
+ */
+
+.global save_boot_params
+save_boot_params:
+
+ /* The firmware provided ATAG/FDT address can be found in r2/x0 */
+#ifdef CONFIG_ARM64
+ adr x8, fw_dtb_pointer
+ str x0, [x8]
+#else
+ str r2, fw_dtb_pointer
+#endif
+
+ /* Returns */
+ b save_boot_params_ret
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 6245b36..ffd6d31 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -25,6 +25,9 @@
DECLARE_GLOBAL_DATA_PTR;
+/* From lowlevel_init.S */
+extern unsigned long fw_dtb_pointer;
+
static const struct bcm2835_gpio_platdata gpio_platdata = {
.base = BCM2835_GPIO_BASE,
};
@@ -285,6 +288,31 @@ static void set_fdtfile(void)
setenv("fdtfile", fdtfile);
}
+/*
+ * If the firmware provided a valid FDT at boot time, let's expose it in
+ * ${fdt_addr} so it may be passed unmodified to the kernel.
+ */
+static void set_fdt_addr(void)
+{
+ if (getenv("fdt_addr"))
+ return;
+
+ if (fdt_magic(fw_dtb_pointer) != FDT_MAGIC)
+ return;
+
+ setenv_hex("fdt_addr", fw_dtb_pointer);
+}
+
+/*
+ * Prevent relocation from stomping on a firmware provided FDT blob.
+ */
+unsigned long board_get_usable_ram_top(unsigned long total_size)
+{
+ if ((gd->ram_top - fw_dtb_pointer) > SZ_64M)
+ return gd->ram_top;
+ return fw_dtb_pointer & ~0xffff;
+}
+
static void set_usbethaddr(void)
{
ALLOC_CACHE_ALIGN_BUFFER(struct msg_get_mac_address, msg, 1);
@@ -356,6 +384,7 @@ static void set_serial_number(void)
int misc_init_r(void)
{
+ set_fdt_addr();
set_fdtfile();
set_usbethaddr();
#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
--
2.7.3
^ permalink raw reply related
* Re: [PATCH 01/30] usb: dwc2: Deprecate g-use-dma binding
From: John Youn @ 2016-11-08 17:48 UTC (permalink / raw)
To: Felipe Balbi, John Youn, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Caesar Wang,
Shawn Lin, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Russell King,
Matthias Brugger, Wei Xu, Andy Yan, Mark Rutland, Will Deacon,
Catalin Marinas, Heiko Stuebner
In-Reply-To: <87wpgeibdh.fsf-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On 11/8/2016 1:12 AM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> writes:
>> Add a vendor prefix and make the name more consistent by renaming it to
>> "snps,gadget-dma-enable".
>>
>> Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/usb/dwc2.txt | 5 ++++-
>> arch/arm/boot/dts/rk3036.dtsi | 2 +-
>> arch/arm/boot/dts/rk3288.dtsi | 2 +-
>> arch/arm/boot/dts/rk3xxx.dtsi | 2 +-
>> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 2 +-
>> arch/arm64/boot/dts/rockchip/rk3368.dtsi | 2 +-
>> drivers/usb/dwc2/params.c | 9 ++++++++-
>> drivers/usb/dwc2/pci.c | 2 +-
>> 8 files changed, 18 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
>> index 9472111..389a461 100644
>> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
>> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
>> @@ -26,11 +26,14 @@ Refer to phy/phy-bindings.txt for generic phy consumer properties
>> - dr_mode: shall be one of "host", "peripheral" and "otg"
>> Refer to usb/generic.txt
>> - snps,host-dma-disable: disable host DMA mode.
>> -- g-use-dma: enable dma usage in gadget driver.
>> +- snps,gadget-dma-enable: enable gadget DMA mode.
>
> I don't see why you even have this binding. Looking through the code,
> you have:
>
> #define GHWCFG2_SLAVE_ONLY_ARCH 0
> #define GHWCFG2_EXT_DMA_ARCH 1
> #define GHWCFG2_INT_DMA_ARCH 2
>
> void dwc2_set_param_dma_enable(struct dwc2_hsotg *hsotg, int val)
> {
> int valid = 1;
>
> if (val > 0 && hsotg->hw_params.arch == GHWCFG2_SLAVE_ONLY_ARCH)
> valid = 0;
> if (val < 0)
> valid = 0;
>
> if (!valid) {
> if (val >= 0)
> dev_err(hsotg->dev,
> "%d invalid for dma_enable parameter. Check HW configuration.\n",
> val);
> val = hsotg->hw_params.arch != GHWCFG2_SLAVE_ONLY_ARCH;
> dev_dbg(hsotg->dev, "Setting dma_enable to %d\n", val);
> }
>
> hsotg->core_params->dma_enable = val;
> }
>
> which seems to hint that DMA support is discoverable. If there is DMA,
> why would disable it?
>
Yes that's the case and I would prefer to make it discoverable and
enabled by default.
But the legacy behavior has always been like this because DMA was
never fully implemented in the gadget driver and it was an opt-in
feature. Periodic support was only added recently.
What do you think about enabling it by default now? I think most
platforms already use DMA.
We would still need a "disable" binding for IP validation purposes at
least.
Regards,
John
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* [PATCH 01/30] usb: dwc2: Deprecate g-use-dma binding
From: John Youn @ 2016-11-08 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87wpgeibdh.fsf@linux.intel.com>
On 11/8/2016 1:12 AM, Felipe Balbi wrote:
>
> Hi,
>
> John Youn <johnyoun@synopsys.com> writes:
>> Add a vendor prefix and make the name more consistent by renaming it to
>> "snps,gadget-dma-enable".
>>
>> Signed-off-by: John Youn <johnyoun@synopsys.com>
>> ---
>> Documentation/devicetree/bindings/usb/dwc2.txt | 5 ++++-
>> arch/arm/boot/dts/rk3036.dtsi | 2 +-
>> arch/arm/boot/dts/rk3288.dtsi | 2 +-
>> arch/arm/boot/dts/rk3xxx.dtsi | 2 +-
>> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 2 +-
>> arch/arm64/boot/dts/rockchip/rk3368.dtsi | 2 +-
>> drivers/usb/dwc2/params.c | 9 ++++++++-
>> drivers/usb/dwc2/pci.c | 2 +-
>> 8 files changed, 18 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
>> index 9472111..389a461 100644
>> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
>> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
>> @@ -26,11 +26,14 @@ Refer to phy/phy-bindings.txt for generic phy consumer properties
>> - dr_mode: shall be one of "host", "peripheral" and "otg"
>> Refer to usb/generic.txt
>> - snps,host-dma-disable: disable host DMA mode.
>> -- g-use-dma: enable dma usage in gadget driver.
>> +- snps,gadget-dma-enable: enable gadget DMA mode.
>
> I don't see why you even have this binding. Looking through the code,
> you have:
>
> #define GHWCFG2_SLAVE_ONLY_ARCH 0
> #define GHWCFG2_EXT_DMA_ARCH 1
> #define GHWCFG2_INT_DMA_ARCH 2
>
> void dwc2_set_param_dma_enable(struct dwc2_hsotg *hsotg, int val)
> {
> int valid = 1;
>
> if (val > 0 && hsotg->hw_params.arch == GHWCFG2_SLAVE_ONLY_ARCH)
> valid = 0;
> if (val < 0)
> valid = 0;
>
> if (!valid) {
> if (val >= 0)
> dev_err(hsotg->dev,
> "%d invalid for dma_enable parameter. Check HW configuration.\n",
> val);
> val = hsotg->hw_params.arch != GHWCFG2_SLAVE_ONLY_ARCH;
> dev_dbg(hsotg->dev, "Setting dma_enable to %d\n", val);
> }
>
> hsotg->core_params->dma_enable = val;
> }
>
> which seems to hint that DMA support is discoverable. If there is DMA,
> why would disable it?
>
Yes that's the case and I would prefer to make it discoverable and
enabled by default.
But the legacy behavior has always been like this because DMA was
never fully implemented in the gadget driver and it was an opt-in
feature. Periodic support was only added recently.
What do you think about enabling it by default now? I think most
platforms already use DMA.
We would still need a "disable" binding for IP validation purposes at
least.
Regards,
John
^ permalink raw reply
* [PATCH v2] spi: atmel: use managed resource for gpio chip select
From: Nicolas Ferre @ 2016-11-08 17:48 UTC (permalink / raw)
To: linux, Mark Brown, Alexandre Belloni, Boris BREZILLON, linux-spi,
geert
Cc: Ludovic Desroches, linux-arm-kernel, linux-kernel,
Cyrille Pitchen, Wenyou Yang, Nicolas Ferre
Use the managed gpio CS pin request so that we avoid having trouble
in the cleanup code.
In fact, if module was configured with DT, cleanup code released
invalid pin. Since resource wasn't freed, module cannot be reinserted.
This require to extract the gpio request call from the "setup" function
and call it in the appropriate probe function.
Reported-by: Alexander Morozov <linux@meltdown.ru>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
v2: fix devm_gpio_request location: the setup code for device was not proper
location. Move it to the probe function and add needed DT routines to
handle all CS gpio specified.
drivers/spi/spi-atmel.c | 50 ++++++++++++++++++++++++++++++++++++++-----------
1 file changed, 39 insertions(+), 11 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 32683a13dd60..a60925614480 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -24,6 +24,7 @@
#include <linux/io.h>
#include <linux/gpio.h>
+#include <linux/of_gpio.h>
#include <linux/pinctrl/consumer.h>
#include <linux/pm_runtime.h>
@@ -1204,7 +1205,6 @@ static int atmel_spi_setup(struct spi_device *spi)
u32 csr;
unsigned int bits = spi->bits_per_word;
unsigned int npcs_pin;
- int ret;
as = spi_master_get_devdata(spi->master);
@@ -1247,16 +1247,9 @@ static int atmel_spi_setup(struct spi_device *spi)
if (!asd)
return -ENOMEM;
- if (as->use_cs_gpios) {
- ret = gpio_request(npcs_pin, dev_name(&spi->dev));
- if (ret) {
- kfree(asd);
- return ret;
- }
-
+ if (as->use_cs_gpios)
gpio_direction_output(npcs_pin,
!(spi->mode & SPI_CS_HIGH));
- }
asd->npcs_pin = npcs_pin;
spi->controller_state = asd;
@@ -1471,13 +1464,11 @@ static int atmel_spi_transfer_one_message(struct spi_master *master,
static void atmel_spi_cleanup(struct spi_device *spi)
{
struct atmel_spi_device *asd = spi->controller_state;
- unsigned gpio = (unsigned long) spi->controller_data;
if (!asd)
return;
spi->controller_state = NULL;
- gpio_free(gpio);
kfree(asd);
}
@@ -1499,6 +1490,39 @@ static void atmel_get_caps(struct atmel_spi *as)
}
/*-------------------------------------------------------------------------*/
+static int atmel_spi_gpio_cs(struct platform_device *pdev)
+{
+ struct spi_master *master = platform_get_drvdata(pdev);
+ struct atmel_spi *as = spi_master_get_devdata(master);
+ struct device_node *np = master->dev.of_node;
+ int i;
+ int ret = 0;
+ int nb = 0;
+
+ if (!as->use_cs_gpios)
+ return 0;
+
+ if (!np)
+ return 0;
+
+ nb = of_gpio_named_count(np, "cs-gpios");
+ for (i = 0; i < nb; i++) {
+ int cs_gpio = of_get_named_gpio(pdev->dev.of_node,
+ "cs-gpios", i);
+
+ if (cs_gpio == -EPROBE_DEFER)
+ return cs_gpio;
+
+ if (gpio_is_valid(cs_gpio)) {
+ ret = devm_gpio_request(&pdev->dev, cs_gpio,
+ dev_name(&pdev->dev));
+ if (ret)
+ return ret;
+ }
+ }
+
+ return 0;
+}
static int atmel_spi_probe(struct platform_device *pdev)
{
@@ -1577,6 +1601,10 @@ static int atmel_spi_probe(struct platform_device *pdev)
master->num_chipselect = 4;
}
+ ret = atmel_spi_gpio_cs(pdev);
+ if (ret)
+ goto out_unmap_regs;
+
as->use_dma = false;
as->use_pdc = false;
if (as->caps.has_dma_support) {
--
2.9.0
^ permalink raw reply related
* [PATCH v2] spi: atmel: use managed resource for gpio chip select
From: Nicolas Ferre @ 2016-11-08 17:48 UTC (permalink / raw)
To: linux-arm-kernel
Use the managed gpio CS pin request so that we avoid having trouble
in the cleanup code.
In fact, if module was configured with DT, cleanup code released
invalid pin. Since resource wasn't freed, module cannot be reinserted.
This require to extract the gpio request call from the "setup" function
and call it in the appropriate probe function.
Reported-by: Alexander Morozov <linux@meltdown.ru>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
v2: fix devm_gpio_request location: the setup code for device was not proper
location. Move it to the probe function and add needed DT routines to
handle all CS gpio specified.
drivers/spi/spi-atmel.c | 50 ++++++++++++++++++++++++++++++++++++++-----------
1 file changed, 39 insertions(+), 11 deletions(-)
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 32683a13dd60..a60925614480 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -24,6 +24,7 @@
#include <linux/io.h>
#include <linux/gpio.h>
+#include <linux/of_gpio.h>
#include <linux/pinctrl/consumer.h>
#include <linux/pm_runtime.h>
@@ -1204,7 +1205,6 @@ static int atmel_spi_setup(struct spi_device *spi)
u32 csr;
unsigned int bits = spi->bits_per_word;
unsigned int npcs_pin;
- int ret;
as = spi_master_get_devdata(spi->master);
@@ -1247,16 +1247,9 @@ static int atmel_spi_setup(struct spi_device *spi)
if (!asd)
return -ENOMEM;
- if (as->use_cs_gpios) {
- ret = gpio_request(npcs_pin, dev_name(&spi->dev));
- if (ret) {
- kfree(asd);
- return ret;
- }
-
+ if (as->use_cs_gpios)
gpio_direction_output(npcs_pin,
!(spi->mode & SPI_CS_HIGH));
- }
asd->npcs_pin = npcs_pin;
spi->controller_state = asd;
@@ -1471,13 +1464,11 @@ static int atmel_spi_transfer_one_message(struct spi_master *master,
static void atmel_spi_cleanup(struct spi_device *spi)
{
struct atmel_spi_device *asd = spi->controller_state;
- unsigned gpio = (unsigned long) spi->controller_data;
if (!asd)
return;
spi->controller_state = NULL;
- gpio_free(gpio);
kfree(asd);
}
@@ -1499,6 +1490,39 @@ static void atmel_get_caps(struct atmel_spi *as)
}
/*-------------------------------------------------------------------------*/
+static int atmel_spi_gpio_cs(struct platform_device *pdev)
+{
+ struct spi_master *master = platform_get_drvdata(pdev);
+ struct atmel_spi *as = spi_master_get_devdata(master);
+ struct device_node *np = master->dev.of_node;
+ int i;
+ int ret = 0;
+ int nb = 0;
+
+ if (!as->use_cs_gpios)
+ return 0;
+
+ if (!np)
+ return 0;
+
+ nb = of_gpio_named_count(np, "cs-gpios");
+ for (i = 0; i < nb; i++) {
+ int cs_gpio = of_get_named_gpio(pdev->dev.of_node,
+ "cs-gpios", i);
+
+ if (cs_gpio == -EPROBE_DEFER)
+ return cs_gpio;
+
+ if (gpio_is_valid(cs_gpio)) {
+ ret = devm_gpio_request(&pdev->dev, cs_gpio,
+ dev_name(&pdev->dev));
+ if (ret)
+ return ret;
+ }
+ }
+
+ return 0;
+}
static int atmel_spi_probe(struct platform_device *pdev)
{
@@ -1577,6 +1601,10 @@ static int atmel_spi_probe(struct platform_device *pdev)
master->num_chipselect = 4;
}
+ ret = atmel_spi_gpio_cs(pdev);
+ if (ret)
+ goto out_unmap_regs;
+
as->use_dma = false;
as->use_pdc = false;
if (as->caps.has_dma_support) {
--
2.9.0
^ permalink raw reply related
* [PATCH v3 00/10] Move ARC timer code into drivers/clocksource/
From: Vineet Gupta @ 2016-11-08 17:49 UTC (permalink / raw)
To: linux-snps-arc
In-Reply-To: <1478216015-18931-1-git-send-email-vgupta@synopsys.com>
On 11/03/2016 04:33 PM, Vineet Gupta wrote:
> Hi,
>
> This series addresses the long pending move of ARC timer code into
> drivers/clocksource/.
>
> Thx,
> -Vineet
>
> v2 -> v3
>
> - Fixed a bunch of typos in changelogs [Daniel]
>
> - aux.h: stubs for {read,write}_aux_reg() inline functions(vs. macros)
> to cleanly avoid warnings in !ARC builds [Daniel]
>
> - Remove __maybe_used in driver given above [Daniel]
>
> - Ran checkpatch and fixed some space/tab issues
>
> v1 -> v2
>
> - Now 10 patches instead of 9 to handle BIG ENDIAN in arch agnostic way
>
> - Moved fix for RTC (v1 2/9) ahead of queue (v2 1/10) to allow for easier
> stable backport
>
> - Folded the Kconfig items for RTC and GFRC into single ARC_TIMERS_64BIT
> So no special casing for UP/SMP in Kconfig.
> Driver already handles the UP vs. SMP at runtime as needed
>
> - convert WARN() to pr_warn() [Daniel]
> - Use of _BITUL() vs. constant 0x8000_0000 [Daniel]
> - changelog spellos: [Daniel]
> s/depedency/dependency/
> s/seperate/separate/
>
>
> v2: http://lists.infradead.org/pipermail/linux-snps-arc/2016-November/001724.html
> v1: http://lists.infradead.org/pipermail/linux-snps-arc/2016-October/001676.html
>
> Vineet Gupta (10):
> ARC: timer: rtc: implement read loop in "C" vs. inline asm
> ARC: timer: gfrc, rtc: deuglify big endian code
> ARC: timer: gfrc, rtc: Read BCR to detect whether hardware exists ...
> ARC: timer: gfrc: boot print alongside other timers
> ARC: time: move time_init() out of the driver
> ARC: timer: Build gfrc, rtc under same option (64-bit timers)
> ARC: breakout aux handling into a separate header
> ARC: move mcip.h into include/soc and adjust the includes
> ARC: breakout timer include code into separate header ...
> clocksource: import ARC timer driver
>
> MAINTAINERS | 1 +
> arch/arc/Kconfig | 13 +--
> arch/arc/configs/nsimosci_hs_smp_defconfig | 2 +-
> arch/arc/configs/vdk_hs38_smp_defconfig | 2 +-
> arch/arc/include/asm/arcregs.h | 94 +---------------
> arch/arc/kernel/Makefile | 2 +-
> arch/arc/kernel/mcip.c | 2 +-
> arch/arc/kernel/setup.c | 17 ++-
> arch/arc/plat-axs10x/axs10x.c | 2 +-
> drivers/clocksource/Kconfig | 19 ++++
> drivers/clocksource/Makefile | 1 +
> .../time.c => drivers/clocksource/arc_timer.c | 125 +++++++--------------
> include/soc/arc/aux.h | 63 +++++++++++
> {arch/arc/include/asm => include/soc/arc}/mcip.h | 10 +-
> include/soc/arc/timers.h | 38 +++++++
> include/soc/nps/common.h | 4 +-
> 16 files changed, 191 insertions(+), 204 deletions(-)
> rename arch/arc/kernel/time.c => drivers/clocksource/arc_timer.c (72%)
> create mode 100644 include/soc/arc/aux.h
> rename {arch/arc/include/asm => include/soc/arc}/mcip.h (95%)
> create mode 100644 include/soc/arc/timers.h
>
Gentle ping. @Daniel can we please try to get closure on this sometime this week.
I've sent a fixup (patch v4) for the build failure reported by o-dat test robot.
Thx,
-Vineet
^ permalink raw reply
* [xen-unstable test] 102027: regressions - FAIL
From: osstest service owner @ 2016-11-08 17:49 UTC (permalink / raw)
To: xen-devel, osstest-admin
[-- Attachment #1: Type: text/plain, Size: 13921 bytes --]
flight 102027 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102027/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat fail REGR. vs. 102008
test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail REGR. vs. 102008
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 102008
test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail like 102008
test-armhf-armhf-libvirt 13 saverestore-support-check fail like 102008
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 102008
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 102008
test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check fail like 102008
test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail like 102008
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 102008
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 102008
test-amd64-amd64-xl-rtds 9 debian-install fail like 102008
Tests which did not succeed, but are not blocking:
test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a
test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a
test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass
build-amd64-rumprun 7 xen-build fail never pass
test-amd64-amd64-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-i386-libvirt 12 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
build-i386-rumprun 7 xen-build fail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl 12 migrate-support-check fail never pass
test-armhf-armhf-xl 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass
test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt 12 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail never pass
test-armhf-armhf-libvirt-raw 11 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 12 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 12 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-vhd 11 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 12 saverestore-support-check fail never pass
version targeted for testing:
xen bcb13635fa503113c981c6ea7423f930c1548452
baseline version:
xen 8a35a95615b1a64c98c30195f343bc2c58054d9d
Last test of basis 102008 2016-11-07 16:52:13 Z 1 days
Testing same since 102027 2016-11-08 04:30:42 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Jan Beulich <jbeulich@suse.com>
Roger Pau Monne <roger.pau@citrix.com>
Roger Pau Monné <roger.pau@citrix.com>
Wei Liu <wei.liu2@citrix.com>
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64-xtf pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-prev pass
build-i386-prev pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumprun fail
build-i386-rumprun fail
test-xtf-amd64-amd64-1 pass
test-xtf-amd64-amd64-2 pass
test-xtf-amd64-amd64-3 pass
test-xtf-amd64-amd64-4 pass
test-xtf-amd64-amd64-5 pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm fail
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-armhf-armhf-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvh-amd fail
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-rumprun-amd64 blocked
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-armhf-armhf-xl-arndale fail
test-amd64-amd64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumprun-i386 blocked
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvh-intel fail
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-migrupgrade pass
test-amd64-i386-migrupgrade pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub pass
test-armhf-armhf-libvirt-qcow2 pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds fail
test-armhf-armhf-xl-rtds fail
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
test-amd64-amd64-xl-qemut-winxpsp3 pass
test-amd64-i386-xl-qemut-winxpsp3 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3 pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
commit bcb13635fa503113c981c6ea7423f930c1548452
Author: Roger Pau Monne <roger.pau@citrix.com>
Date: Mon Nov 7 16:32:01 2016 +0100
libxc: set rsdp pointer for PVHv2 guests
Set the address of the RSDP in the HVM start info structure for PVHv2 DomUs
that have ACPI tables.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
commit fac7f77b69797d0659489e49dfb3f35f8acf2b97
Author: Roger Pau Monne <roger.pau@citrix.com>
Date: Mon Nov 7 16:32:00 2016 +0100
libxc: properly account for the page offset when copying ACPI data
Or else ACPI data is always copied at the start of the page pointed by
guest_addr_out, ignoring the page offset.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-and-Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
commit 712db0f3013425aeb4e29fb4f03315c466b696c1
Author: Jan Beulich <JBeulich@suse.com>
Date: Mon Nov 7 08:29:15 2016 -0700
IOMMU: release lock on new exit path
This was overlooked in 7b2842a414 ("IOMMU: replace ASSERT()s checking
for NULL").
Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
commit c96b6ae4eea852aef395ce4e931a1d8fa82ca42e
Author: Wei Liu <wei.liu2@citrix.com>
Date: Mon Nov 7 11:12:19 2016 +0000
Config.mk: update seabios to 1.10.0
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
(qemu changes not included)
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH v2] spi: atmel: use managed resource for gpio chip select
From: Alexandre Belloni @ 2016-11-08 17:49 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Boris BREZILLON, Ludovic Desroches, linux-kernel, linux-spi,
linux, Mark Brown, geert, Cyrille Pitchen, Wenyou Yang,
linux-arm-kernel
In-Reply-To: <20161108174852.14311-1-nicolas.ferre@atmel.com>
On 08/11/2016 at 18:48:52 +0100, Nicolas Ferre wrote :
> Use the managed gpio CS pin request so that we avoid having trouble
> in the cleanup code.
> In fact, if module was configured with DT, cleanup code released
> invalid pin. Since resource wasn't freed, module cannot be reinserted.
>
> This require to extract the gpio request call from the "setup" function
> and call it in the appropriate probe function.
>
> Reported-by: Alexander Morozov <linux@meltdown.ru>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
I think that's fine but I still have that item on my todo list
(discussion in july 2014 with Mark):
---
>> Mark: maybe it would make sense to do devm_gpio_request_one() in
>> of_spi_register_master(), after of_get_named_gpio.
> You need to transition all the drivers doing things manually but yes.
> As I keep saying all the GPIO handling needs to be completely
> refactored.
---
> ---
> v2: fix devm_gpio_request location: the setup code for device was not proper
> location. Move it to the probe function and add needed DT routines to
> handle all CS gpio specified.
>
> drivers/spi/spi-atmel.c | 50 ++++++++++++++++++++++++++++++++++++++-----------
> 1 file changed, 39 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> index 32683a13dd60..a60925614480 100644
> --- a/drivers/spi/spi-atmel.c
> +++ b/drivers/spi/spi-atmel.c
> @@ -24,6 +24,7 @@
>
> #include <linux/io.h>
> #include <linux/gpio.h>
> +#include <linux/of_gpio.h>
> #include <linux/pinctrl/consumer.h>
> #include <linux/pm_runtime.h>
>
> @@ -1204,7 +1205,6 @@ static int atmel_spi_setup(struct spi_device *spi)
> u32 csr;
> unsigned int bits = spi->bits_per_word;
> unsigned int npcs_pin;
> - int ret;
>
> as = spi_master_get_devdata(spi->master);
>
> @@ -1247,16 +1247,9 @@ static int atmel_spi_setup(struct spi_device *spi)
> if (!asd)
> return -ENOMEM;
>
> - if (as->use_cs_gpios) {
> - ret = gpio_request(npcs_pin, dev_name(&spi->dev));
> - if (ret) {
> - kfree(asd);
> - return ret;
> - }
> -
> + if (as->use_cs_gpios)
> gpio_direction_output(npcs_pin,
> !(spi->mode & SPI_CS_HIGH));
> - }
>
> asd->npcs_pin = npcs_pin;
> spi->controller_state = asd;
> @@ -1471,13 +1464,11 @@ static int atmel_spi_transfer_one_message(struct spi_master *master,
> static void atmel_spi_cleanup(struct spi_device *spi)
> {
> struct atmel_spi_device *asd = spi->controller_state;
> - unsigned gpio = (unsigned long) spi->controller_data;
>
> if (!asd)
> return;
>
> spi->controller_state = NULL;
> - gpio_free(gpio);
> kfree(asd);
> }
>
> @@ -1499,6 +1490,39 @@ static void atmel_get_caps(struct atmel_spi *as)
> }
>
> /*-------------------------------------------------------------------------*/
> +static int atmel_spi_gpio_cs(struct platform_device *pdev)
> +{
> + struct spi_master *master = platform_get_drvdata(pdev);
> + struct atmel_spi *as = spi_master_get_devdata(master);
> + struct device_node *np = master->dev.of_node;
> + int i;
> + int ret = 0;
> + int nb = 0;
> +
> + if (!as->use_cs_gpios)
> + return 0;
> +
> + if (!np)
> + return 0;
> +
> + nb = of_gpio_named_count(np, "cs-gpios");
> + for (i = 0; i < nb; i++) {
> + int cs_gpio = of_get_named_gpio(pdev->dev.of_node,
> + "cs-gpios", i);
> +
> + if (cs_gpio == -EPROBE_DEFER)
> + return cs_gpio;
> +
> + if (gpio_is_valid(cs_gpio)) {
> + ret = devm_gpio_request(&pdev->dev, cs_gpio,
> + dev_name(&pdev->dev));
> + if (ret)
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
>
> static int atmel_spi_probe(struct platform_device *pdev)
> {
> @@ -1577,6 +1601,10 @@ static int atmel_spi_probe(struct platform_device *pdev)
> master->num_chipselect = 4;
> }
>
> + ret = atmel_spi_gpio_cs(pdev);
> + if (ret)
> + goto out_unmap_regs;
> +
> as->use_dma = false;
> as->use_pdc = false;
> if (as->caps.has_dma_support) {
> --
> 2.9.0
>
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2] spi: atmel: use managed resource for gpio chip select
From: Alexandre Belloni @ 2016-11-08 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108174852.14311-1-nicolas.ferre@atmel.com>
On 08/11/2016 at 18:48:52 +0100, Nicolas Ferre wrote :
> Use the managed gpio CS pin request so that we avoid having trouble
> in the cleanup code.
> In fact, if module was configured with DT, cleanup code released
> invalid pin. Since resource wasn't freed, module cannot be reinserted.
>
> This require to extract the gpio request call from the "setup" function
> and call it in the appropriate probe function.
>
> Reported-by: Alexander Morozov <linux@meltdown.ru>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
I think that's fine but I still have that item on my todo list
(discussion in july 2014 with Mark):
---
>> Mark: maybe it would make sense to do devm_gpio_request_one() in
>> of_spi_register_master(), after of_get_named_gpio.
> You need to transition all the drivers doing things manually but yes.
> As I keep saying all the GPIO handling needs to be completely
> refactored.
---
> ---
> v2: fix devm_gpio_request location: the setup code for device was not proper
> location. Move it to the probe function and add needed DT routines to
> handle all CS gpio specified.
>
> drivers/spi/spi-atmel.c | 50 ++++++++++++++++++++++++++++++++++++++-----------
> 1 file changed, 39 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> index 32683a13dd60..a60925614480 100644
> --- a/drivers/spi/spi-atmel.c
> +++ b/drivers/spi/spi-atmel.c
> @@ -24,6 +24,7 @@
>
> #include <linux/io.h>
> #include <linux/gpio.h>
> +#include <linux/of_gpio.h>
> #include <linux/pinctrl/consumer.h>
> #include <linux/pm_runtime.h>
>
> @@ -1204,7 +1205,6 @@ static int atmel_spi_setup(struct spi_device *spi)
> u32 csr;
> unsigned int bits = spi->bits_per_word;
> unsigned int npcs_pin;
> - int ret;
>
> as = spi_master_get_devdata(spi->master);
>
> @@ -1247,16 +1247,9 @@ static int atmel_spi_setup(struct spi_device *spi)
> if (!asd)
> return -ENOMEM;
>
> - if (as->use_cs_gpios) {
> - ret = gpio_request(npcs_pin, dev_name(&spi->dev));
> - if (ret) {
> - kfree(asd);
> - return ret;
> - }
> -
> + if (as->use_cs_gpios)
> gpio_direction_output(npcs_pin,
> !(spi->mode & SPI_CS_HIGH));
> - }
>
> asd->npcs_pin = npcs_pin;
> spi->controller_state = asd;
> @@ -1471,13 +1464,11 @@ static int atmel_spi_transfer_one_message(struct spi_master *master,
> static void atmel_spi_cleanup(struct spi_device *spi)
> {
> struct atmel_spi_device *asd = spi->controller_state;
> - unsigned gpio = (unsigned long) spi->controller_data;
>
> if (!asd)
> return;
>
> spi->controller_state = NULL;
> - gpio_free(gpio);
> kfree(asd);
> }
>
> @@ -1499,6 +1490,39 @@ static void atmel_get_caps(struct atmel_spi *as)
> }
>
> /*-------------------------------------------------------------------------*/
> +static int atmel_spi_gpio_cs(struct platform_device *pdev)
> +{
> + struct spi_master *master = platform_get_drvdata(pdev);
> + struct atmel_spi *as = spi_master_get_devdata(master);
> + struct device_node *np = master->dev.of_node;
> + int i;
> + int ret = 0;
> + int nb = 0;
> +
> + if (!as->use_cs_gpios)
> + return 0;
> +
> + if (!np)
> + return 0;
> +
> + nb = of_gpio_named_count(np, "cs-gpios");
> + for (i = 0; i < nb; i++) {
> + int cs_gpio = of_get_named_gpio(pdev->dev.of_node,
> + "cs-gpios", i);
> +
> + if (cs_gpio == -EPROBE_DEFER)
> + return cs_gpio;
> +
> + if (gpio_is_valid(cs_gpio)) {
> + ret = devm_gpio_request(&pdev->dev, cs_gpio,
> + dev_name(&pdev->dev));
> + if (ret)
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
>
> static int atmel_spi_probe(struct platform_device *pdev)
> {
> @@ -1577,6 +1601,10 @@ static int atmel_spi_probe(struct platform_device *pdev)
> master->num_chipselect = 4;
> }
>
> + ret = atmel_spi_gpio_cs(pdev);
> + if (ret)
> + goto out_unmap_regs;
> +
> as->use_dma = false;
> as->use_pdc = false;
> if (as->caps.has_dma_support) {
> --
> 2.9.0
>
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v3 00/10] Move ARC timer code into drivers/clocksource/
From: Vineet Gupta @ 2016-11-08 17:49 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Noam Camus, Alexey.Brodkin, linux-kernel, tglx, linux-snps-arc
In-Reply-To: <1478216015-18931-1-git-send-email-vgupta@synopsys.com>
On 11/03/2016 04:33 PM, Vineet Gupta wrote:
> Hi,
>
> This series addresses the long pending move of ARC timer code into
> drivers/clocksource/.
>
> Thx,
> -Vineet
>
> v2 -> v3
>
> - Fixed a bunch of typos in changelogs [Daniel]
>
> - aux.h: stubs for {read,write}_aux_reg() inline functions(vs. macros)
> to cleanly avoid warnings in !ARC builds [Daniel]
>
> - Remove __maybe_used in driver given above [Daniel]
>
> - Ran checkpatch and fixed some space/tab issues
>
> v1 -> v2
>
> - Now 10 patches instead of 9 to handle BIG ENDIAN in arch agnostic way
>
> - Moved fix for RTC (v1 2/9) ahead of queue (v2 1/10) to allow for easier
> stable backport
>
> - Folded the Kconfig items for RTC and GFRC into single ARC_TIMERS_64BIT
> So no special casing for UP/SMP in Kconfig.
> Driver already handles the UP vs. SMP at runtime as needed
>
> - convert WARN() to pr_warn() [Daniel]
> - Use of _BITUL() vs. constant 0x8000_0000 [Daniel]
> - changelog spellos: [Daniel]
> s/depedency/dependency/
> s/seperate/separate/
>
>
> v2: http://lists.infradead.org/pipermail/linux-snps-arc/2016-November/001724.html
> v1: http://lists.infradead.org/pipermail/linux-snps-arc/2016-October/001676.html
>
> Vineet Gupta (10):
> ARC: timer: rtc: implement read loop in "C" vs. inline asm
> ARC: timer: gfrc, rtc: deuglify big endian code
> ARC: timer: gfrc, rtc: Read BCR to detect whether hardware exists ...
> ARC: timer: gfrc: boot print alongside other timers
> ARC: time: move time_init() out of the driver
> ARC: timer: Build gfrc, rtc under same option (64-bit timers)
> ARC: breakout aux handling into a separate header
> ARC: move mcip.h into include/soc and adjust the includes
> ARC: breakout timer include code into separate header ...
> clocksource: import ARC timer driver
>
> MAINTAINERS | 1 +
> arch/arc/Kconfig | 13 +--
> arch/arc/configs/nsimosci_hs_smp_defconfig | 2 +-
> arch/arc/configs/vdk_hs38_smp_defconfig | 2 +-
> arch/arc/include/asm/arcregs.h | 94 +---------------
> arch/arc/kernel/Makefile | 2 +-
> arch/arc/kernel/mcip.c | 2 +-
> arch/arc/kernel/setup.c | 17 ++-
> arch/arc/plat-axs10x/axs10x.c | 2 +-
> drivers/clocksource/Kconfig | 19 ++++
> drivers/clocksource/Makefile | 1 +
> .../time.c => drivers/clocksource/arc_timer.c | 125 +++++++--------------
> include/soc/arc/aux.h | 63 +++++++++++
> {arch/arc/include/asm => include/soc/arc}/mcip.h | 10 +-
> include/soc/arc/timers.h | 38 +++++++
> include/soc/nps/common.h | 4 +-
> 16 files changed, 191 insertions(+), 204 deletions(-)
> rename arch/arc/kernel/time.c => drivers/clocksource/arc_timer.c (72%)
> create mode 100644 include/soc/arc/aux.h
> rename {arch/arc/include/asm => include/soc/arc}/mcip.h (95%)
> create mode 100644 include/soc/arc/timers.h
>
Gentle ping. @Daniel can we please try to get closure on this sometime this week.
I've sent a fixup (patch v4) for the build failure reported by o-dat test robot.
Thx,
-Vineet
^ permalink raw reply
* RE: [PATCH rdma-next 0/4] Add packet pacing support for IB verbs
From: Hefty, Sean @ 2016-11-08 17:49 UTC (permalink / raw)
To: Leon Romanovsky, dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1477909297-14491-1-git-send-email-leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> When sending from a 10G host to a 1G host, it is easy to overrun the
> receiver,
> leading to packet loss and traffic backing off. Similar problems occur
> when
> a 10G host sends data to a sub-10G virtual circuit, or a 40G host
> sending
> to a 10G host. Packet pacing could control packet injection rate and
> reduces
> network congestion to maximize throughput & minimize network latency.
Why isn't the path record data and existing mechanisms sufficient to handle this?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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: [PATCH 1/2] clk: pxa mark dummy helper as 'inline'
From: Robert Jarzmik @ 2016-11-08 17:50 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Stephen Boyd, Michael Turquette, linux-clk, linux-kernel
In-Reply-To: <20161108144950.3472058-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> The dummy_clk_set_parent function is marked as 'static' but is
> no longer referenced from the pxa25x clk driver after the last use
> of the RATE_RO_OPS() macro is gone from this file, causing a
> harmless build warning:
>
> In file included from drivers/clk/pxa/clk-pxa25x.c:24:0:
> drivers/clk/pxa/clk-pxa.h:146:12: error: 'dummy_clk_set_parent' defined but not used [-Werror=unused-function]
>
> This marks the functon as 'inline', which lets the compiler simply
> drop it when it gets referenced.
>
> Fixes: 9fe694295098 ("clk: pxa: transfer CPU clock setting from pxa2xx-cpufreq")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Cheers.
--
Robert
^ permalink raw reply
* [PATCH 1/4] gpu: host1x: Store device address to all bufs
From: Mikko Perttunen @ 2016-11-08 17:51 UTC (permalink / raw)
To: thierry.reding-Re5JQEeQqe8AvxtiuMwx3w
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Arto Merilainen,
Andrew Chew, Mikko Perttunen
From: Arto Merilainen <amerilainen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Currently job pinning is optimized to handle only the first buffer
using a certain host1x_bo object and all subsequent buffers using
the same host1x_bo are considered done.
In most cases this is correct, however, in case the same host1x_bo
is used in multiple gathers inside the same job, we skip also
storing the device address (physical or iova) to this buffer.
This patch reworks the host1x_job_pin() to store the device address
to all gathers.
Signed-off-by: Andrew Chew <achew-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Arto Merilainen <amerilainen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Mikko Perttunen <mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
drivers/gpu/host1x/job.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index a91b7c4..92c3df9 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -1,7 +1,7 @@
/*
* Tegra host1x Job
*
- * Copyright (c) 2010-2013, NVIDIA Corporation.
+ * Copyright (c) 2010-2015, NVIDIA Corporation.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
@@ -539,9 +539,12 @@ int host1x_job_pin(struct host1x_job *job, struct device *dev)
g->base = job->gather_addr_phys[i];
- for (j = i + 1; j < job->num_gathers; j++)
- if (job->gathers[j].bo == g->bo)
+ for (j = i + 1; j < job->num_gathers; j++) {
+ if (job->gathers[j].bo == g->bo) {
job->gathers[j].handled = true;
+ job->gathers[j].base = g->base;
+ }
+ }
err = do_relocs(job, g->bo);
if (err)
--
2.9.3
^ permalink raw reply related
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.