* [tip:irq/core] PCI: Remove the irq_affinity mask from struct pci_dev
From: tip-bot for Christoph Hellwig @ 2016-11-09 7:51 UTC (permalink / raw)
To: linux-tip-commits
Cc: bhelgaas, hch, tglx, mingo, jthumshirn, hpa, axboe, linux-kernel,
hare
In-Reply-To: <1478654107-7384-7-git-send-email-hch@lst.de>
Commit-ID: 0cf71b04467bc34063cecae577f12481da6cc565
Gitweb: http://git.kernel.org/tip/0cf71b04467bc34063cecae577f12481da6cc565
Author: Christoph Hellwig <hch@lst.de>
AuthorDate: Tue, 8 Nov 2016 17:15:06 -0800
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitDate: Wed, 9 Nov 2016 08:25:10 +0100
PCI: Remove the irq_affinity mask from struct pci_dev
This has never been used, and now is totally unreferenced. Nuke it.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Link: http://lkml.kernel.org/r/1478654107-7384-7-git-send-email-hch@lst.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
include/linux/pci.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 7090f5f..f2ba6ac 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -333,7 +333,6 @@ struct pci_dev {
* directly, use the values stored here. They might be different!
*/
unsigned int irq;
- struct cpumask *irq_affinity;
struct resource resource[DEVICE_COUNT_RESOURCE]; /* I/O and memory regions + expansion ROMs */
bool match_driver; /* Skip attaching driver */
^ permalink raw reply related
* Re: support for partial irq affinity assignment V3
From: Thomas Gleixner @ 2016-11-09 7:51 UTC (permalink / raw)
To: Jens Axboe; +Cc: Christoph Hellwig, linux-block, linux-pci, linux-kernel
In-Reply-To: <f5270fd9-488f-a954-ba3c-1f7800820731@kernel.dk>
On Tue, 8 Nov 2016, Jens Axboe wrote:
> On 11/08/2016 06:15 PM, Christoph Hellwig wrote:
> > This series adds support for automatic interrupt assignment to devices
> > that have a few vectors that are set aside for admin or config purposes
> > and thus should not fall into the general per-cpu assginment pool.
> >
> > The first patch adds that support to the core IRQ and PCI/msi code,
> > and the second is a small tweak to a block layer helper to make use
> > of it. I'd love to have both go into the same tree so that consumers
> > of this (e.g. the virtio, scsi and rdma trees) only need to pull in
> > one of these trees as dependency.
>
> Series looks good to me, you can add my Acked-by to all of them.
It's available from
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/for-block
for you to pull into the block tree so you can apply the block changes.
Thanks,
tglx
^ permalink raw reply
* [PATCH] libimxvpuapi: Update to version 0.10.3
From: Carlos Rafael Giani @ 2016-11-09 7:50 UTC (permalink / raw)
To: meta-freescale
Changes:
- properly pass on color format in simplified JPEG encoder interface
- add alternative write-callback-style encoding mode
also add encode example variant which uses write-callback style output
- add support for "fake grayscale mode" in encoders
this is done by using I420 internally and filling the U and V planes
with 0x80 bytes
- make sure JPEG quantization table is copied in standardized zig zag order
the VPU does not, so this has to be done explicitely
Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org>
---
.../libimxvpuapi/{libimxvpuapi_0.10.2.bb => libimxvpuapi_0.10.3.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename recipes-multimedia/libimxvpuapi/{libimxvpuapi_0.10.2.bb => libimxvpuapi_0.10.3.bb} (90%)
diff --git a/recipes-multimedia/libimxvpuapi/libimxvpuapi_0.10.2.bb b/recipes-multimedia/libimxvpuapi/libimxvpuapi_0.10.3.bb
similarity index 90%
rename from recipes-multimedia/libimxvpuapi/libimxvpuapi_0.10.2.bb
rename to recipes-multimedia/libimxvpuapi/libimxvpuapi_0.10.3.bb
index 26d46d5..2ad0c89 100644
--- a/recipes-multimedia/libimxvpuapi/libimxvpuapi_0.10.2.bb
+++ b/recipes-multimedia/libimxvpuapi/libimxvpuapi_0.10.3.bb
@@ -6,7 +6,7 @@ SECTION = "multimedia"
DEPENDS = "imx-vpu"
SRCBRANCH ?= "master"
-SRCREV = "4d919f4813b2288ed79a9026557326df0314ad07"
+SRCREV = "81a2bbd85ef2aaa56243dbf63a7352ca1758099b"
SRC_URI = "git://github.com/Freescale/libimxvpuapi.git;branch=${SRCBRANCH}"
S = "${WORKDIR}/git"
--
2.7.4
^ permalink raw reply related
* Re: multipath.rules placement
From: Hannes Reinecke @ 2016-11-09 7:52 UTC (permalink / raw)
To: Benjamin Marzinski; +Cc: dm-devel
In-Reply-To: <20161108195625.GQ1972@octiron.msp.redhat.com>
On 11/08/2016 08:56 PM, Benjamin Marzinski wrote:
> I'm looking through the multipath udev rules again to see if we can come
> closer to one consistent set, or at least understand why we need to
> agree to disagree and right now I'm trying to figure out why it's
> important for SUSE to have 56-multipath.rules run before
> 60-persistent-storage.rules.
>
> We use 62-multipath.rules in RHEL for two main reasons. First, scsi_id
> is run in 60-persistent-storage.rules, which is what sets ID_SERIAL, so
> if multipath.rules is run before that, we'll never be able to get our
> information from udev. I know that you've added code to cope with this,
> assuming the standard uid_attribute, but it seems better to me to just
> wait for udev to fill in these values itself.
>
> Second, 60-persistent-storage.rules runs blkid, which should set
> ID_FS_TYPE. Setting it in 56-multipath.rules just means that
> 60-persistent-storage.rules will overwrite it.
>
> So, what do we gain by running multipath.rules before
> 60-persistent-storage.rules?
>
Yeah, it's slightly inconsistent.
Actually we are using the rules from sg3_utils (55-scsi-sg_id.rules and
58-scsi-sg3_symlink.rules), which will set ID_SERIAL prior to calling
56-multipath.rules.
Hence it works for us :-)
The main idea here is to deprecate scsi_id, with the goal of eventually
dropping it from systemd/udev.
However, the idea of this particular placement is precisely that we do
_not_ call scsi_id and blkid in 60-persistent-storage.rules for any
devices which are found to be part of a multipath device.
Doing so would not only give pointless information, but also there's a
fair chance that it wouldn't get you any information whatsoever in the
case of standby paths or during failover.
Or even stall the entire rule as it's stuck doing I/O.
My plan is to split off the call to 'scsi_id' from
60-persistent-storage.rules, (eg to 56-scsi-scsi_id.rules), and my
multipath to 57.
Then we would have:
55-scsi-sg_id.rules
56-scsi-scsi_id.rules
-> ID_SERIAL is set from this point on
57-multipath.rules
58-sg3_symlink.rules
60-persistent-storage.rules
and then everything would be far more consistent.
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH 7/9] populate: discover XFS structure fields and fuzz verbs, and use them to fuzz fields
From: Darrick J. Wong @ 2016-11-09 7:52 UTC (permalink / raw)
To: Eryu Guan; +Cc: david, linux-xfs, fstests
In-Reply-To: <20161109033202.GP27776@eguan.usersys.redhat.com>
On Wed, Nov 09, 2016 at 11:32:02AM +0800, Eryu Guan wrote:
> On Fri, Nov 04, 2016 at 05:17:54PM -0700, Darrick J. Wong wrote:
> > Create some routines to help us perform targeted fuzzing of individual
> > fields in various XFS structures. Specifically, we want the caller to
> > drop the xfs_db iocursor on the victim field; from there, the scripts
> > should discover all available fields and fuzzing verbs, and try each
> > fuzz verb on every available field.
> >
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > ---
> > common/fuzzy | 191 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 191 insertions(+)
> >
> >
> > diff --git a/common/fuzzy b/common/fuzzy
> > index 20f1d29..6af47f1 100644
> > --- a/common/fuzzy
> > +++ b/common/fuzzy
> > @@ -81,3 +81,194 @@ _scratch_scrub() {
> > ;;
> > esac
> > }
> > +
> > +# Filter the xfs_db print command's field debug information
> > +# into field name and type.
> > +__filter_xfs_db_print_fields() {
> > + grep ' = ' | while read key equals value; do
> > + fuzzkey="$(echo "${key}" | sed -e 's/\([a-zA-Z0-9_]*\)\[\([0-9]*\)-[0-9]*\]/\1[\2]/g')"
> > + if [[ "${value}" == "["* ]]; then
> > + echo "${value}" | sed -e 's/^.//g' -e 's/.$//g' -e 's/,/\n/g' | while read subfield; do
> > + echo "${fuzzkey}.${subfield}"
> > + done
> > + else
> > + echo "${fuzzkey}"
> > + fi
> > + done
> > +}
> > +
> > +# Navigate to some part of the filesystem and print the field info.
> > +_scratch_xfs_list_metadata_fields() {
> > + if [ -n "${SCRATCH_XFS_LIST_METADATA_FIELDS}" ]; then
> > + echo "${SCRATCH_XFS_LIST_METADATA_FIELDS}" | sed -e 's/ /\n/g'
> > + return;
> > + fi
> > +
> > + (for arg in "$@"; do
> > + echo "${arg}"
> > + done
> > + echo "print") | _scratch_xfs_db | __filter_xfs_db_print_fields
> > +}
> > +
> > +# Get a metadata field
> > +_scratch_xfs_get_metadata_field() {
> > + key="$1"
> > + shift
> > +
> > + grep_key="$(echo "${key}" | tr '[]()' '....')"
> > + (for arg in "$@"; do
> > + echo "${arg}"
> > + done
> > + echo "print ${key}") | _scratch_xfs_db | grep "^${grep_key}" | \
> > + sed -e 's/^.* = //g'
> > +}
> > +
> > +# Set a metadata field
> > +_scratch_xfs_set_metadata_field() {
> > + key="$1"
> > + value="$2"
> > + shift; shift
> > + (for arg in "$@"; do
> > + echo "${arg}"
> > + done
> > + echo "write -d ${key} ${value}") | _scratch_xfs_db -x
> > + echo
> > +}
> > +
> > +# Fuzz a metadata field
> > +_scratch_xfs_fuzz_metadata_field() {
> > + key="$1"
> > + value="$2"
> > + shift; shift
> > +
> > + if [ "${key}" = "crc" ]; then
> > + fuzz_arg="-c"
> > + else
> > + fuzz_arg="-d"
> > + fi
> > + oldval="$(_scratch_xfs_get_metadata_field "${key}" "$@")"
> > + (for arg in "$@"; do
> > + echo "${arg}"
> > + done
> > + echo "fuzz ${fuzz_arg} ${key} ${value}") | _scratch_xfs_db -x
> > + echo
> > + newval="$(_scratch_xfs_get_metadata_field "${key}" "$@" 2> /dev/null)"
> > + if [ "${oldval}" = "${newval}" ]; then
> > + echo "Field ${key} already set to ${oldval}, skipping test."
> > + return 1
> > + fi
> > + return 0
> > +}
> > +
> > +# Try to forcibly unmount the scratch fs
> > +__scratch_xfs_fuzz_unmount()
> > +{
> > + while _scratch_unmount 2>/dev/null; do sleep 0.2; done
>
> Shouldn't this be
>
> while ! _scratch_unmount 2>/dev/null; do sleep 0.2; done
>
> so it only sleeps and try again if umount failed?
Err, yes, and now you've gotten me wondering just how that hasn't shown up...
--D
>
> Thanks,
> Eryu
>
> > +}
> > +
> > +# Restore metadata to scratch device prior to field-fuzzing.
> > +__scratch_xfs_fuzz_mdrestore()
> > +{
> > + test -e "${POPULATE_METADUMP}" || _fail "Need to set POPULATE_METADUMP"
> > +
> > + __scratch_xfs_fuzz_unmount
> > + xfs_mdrestore "${POPULATE_METADUMP}" "${SCRATCH_DEV}"
> > +}
> > +
> > +__fuzz_notify() {
> > + echo "$@"
> > + test -w /dev/ttyprintk && echo "$@" >> /dev/ttyprintk
> > +}
> > +
> > +# Fuzz one field of some piece of metadata
> > +__scratch_xfs_fuzz_field_test() {
> > + field="$1"
> > + fuzzverb="$2"
> > + shift; shift
> > +
> > + # Set the new field value
> > + __fuzz_notify "+ Fuzz ${field} = ${fuzzverb}"
> > + echo "========================"
> > + _scratch_xfs_fuzz_metadata_field "${field}" ${fuzzverb} "$@"
> > + res=$?
> > + test $res -ne 0 && return
> > +
> > + # Try to catch the error with scrub
> > + echo "+ Try to catch the error"
> > + _scratch_mount 2>&1
> > + res=$?
> > + if [ $res -eq 0 ]; then
> > + _scratch_scrub -a 1 -e continue 2>&1
> > + res=$?
> > + test $res -eq 0 && \
> > + (>&2 echo "scrub didn't fail with ${field} = ${fuzzverb}.")
> > +
> > + # Try modifying the filesystem!
> > + __fuzz_notify "++ Try to write filesystem"
> > + #_scratch_fuzz_modify 100 2>&1
> > + __scratch_xfs_fuzz_unmount
> > + fi
> > +
> > + # Repair the filesystem
> > + echo "+ Fix the error"
> > + _repair_scratch_fs 2>&1
> > + res=$?
> > + test $res -ne 0 && \
> > + (>&2 echo "repair failed ($res) with ${field} = ${fuzzverb}.")
> > +
> > + # See if scrub finds a clean fs
> > + echo "+ Make sure error is gone"
> > + _scratch_mount 2>&1
> > + res=$?
> > + if [ $res -eq 0 ]; then
> > + _scratch_scrub -e continue 2>&1
> > + res=$?
> > + test $res -ne 0 && \
> > + (>&2 echo "re-scrub ($res) with ${field} = ${fuzzverb}.")
> > +
> > + # Try modifying the filesystem again!
> > + __fuzz_notify "++ Try to write filesystem again"
> > + _scratch_fuzz_modify 100 2>&1
> > + __scratch_xfs_fuzz_unmount
> > + else
> > + (>&2 echo "re-mount failed ($res) with ${field} = ${fuzzverb}.")
> > + fi
> > +
> > + # See if repair finds a clean fs
> > + _scratch_xfs_repair -n 2>&1
> > + res=$?
> > + test $res -ne 0 && \
> > + (>&2 echo "re-repair failed ($res) with ${field} = ${fuzzverb}.")
> > +}
> > +
> > +# Make sure we have all the pieces we need for field fuzzing
> > +_require_scratch_xfs_fuzz_fields()
> > +{
> > + _require_scratch
> > + _require_scrub
> > + _require_populate_commands
> > + _require_command "$XFS_DB_PROG" "xfs_db"
> > + _scratch_mkfs_xfs >/dev/null 2>&1
> > + _scratch_xfs_db -x -c 'fuzz' 2>&1 | grep -q 'not found' && \
> > + _notrun "xfs_db does not have fuzz command"
> > +}
> > +
> > +# Grab the list of available fuzzing verbs
> > +_scratch_xfs_list_fuzz_verbs() {
> > + if [ -n "${SCRATCH_XFS_LIST_FUZZ_VERBS}" ]; then
> > + echo "${SCRATCH_XFS_LIST_FUZZ_VERBS}" | sed -e 's/ /\n/g'
> > + return;
> > + fi
> > + _scratch_xfs_db -x -c 'sb 0' -c 'fuzz' | grep '^Verbs:' | \
> > + sed -e 's/[,.]//g' -e 's/Verbs: //g' -e 's/ /\n/g'
> > +}
> > +
> > +# Fuzz the fields of some piece of metadata
> > +_scratch_xfs_fuzz_fields() {
> > + _scratch_xfs_list_metadata_fields "$@" | while read field; do
> > + _scratch_xfs_list_fuzz_verbs | while read fuzzverb; do
> > + __scratch_xfs_fuzz_mdrestore
> > + __scratch_xfs_fuzz_field_test "${field}" "${fuzzverb}" "$@"
> > + done
> > + done
> > +}
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 01/30] usb: dwc2: Deprecate g-use-dma binding
From: Felipe Balbi @ 2016-11-09 7:53 UTC (permalink / raw)
To: John Youn
In-Reply-To: <6e90b835-73b1-3970-24a4-eab72381b469-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3378 bytes --]
Hi,
John Youn <John.Youn-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> writes:
> 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.
legacy behavior can be changed if another 'policy' makes more
sense. IMHO, whatever can be discovered in runtime, should be enabled by
default. That way, we force people to use it and find bugs in certain
features.
> What do you think about enabling it by default now? I think most
> platforms already use DMA.
I think it should be discovered. Drop all these "*-use-dma" bindings
because they're not needed if you can probe a register to answer the
same question.
> We would still need a "disable" binding for IP validation purposes at
> least.
Yeah, could be a quirk.
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
^ permalink raw reply
* [PATCH 01/30] usb: dwc2: Deprecate g-use-dma binding
From: Felipe Balbi @ 2016-11-09 7:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6e90b835-73b1-3970-24a4-eab72381b469@synopsys.com>
Hi,
John Youn <John.Youn@synopsys.com> writes:
> 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.
legacy behavior can be changed if another 'policy' makes more
sense. IMHO, whatever can be discovered in runtime, should be enabled by
default. That way, we force people to use it and find bugs in certain
features.
> What do you think about enabling it by default now? I think most
> platforms already use DMA.
I think it should be discovered. Drop all these "*-use-dma" bindings
because they're not needed if you can probe a register to answer the
same question.
> We would still need a "disable" binding for IP validation purposes at
> least.
Yeah, could be a quirk.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161109/0691c4a0/attachment.sig>
^ permalink raw reply
* Re: [PATCH 7/9] populate: discover XFS structure fields and fuzz verbs, and use them to fuzz fields
From: Darrick J. Wong @ 2016-11-09 7:53 UTC (permalink / raw)
To: Eryu Guan; +Cc: david, linux-xfs, fstests
In-Reply-To: <20161109034411.GQ27776@eguan.usersys.redhat.com>
On Wed, Nov 09, 2016 at 11:44:11AM +0800, Eryu Guan wrote:
> [sorry, more comments on this patch]
>
> On Fri, Nov 04, 2016 at 05:17:54PM -0700, Darrick J. Wong wrote:
> > Create some routines to help us perform targeted fuzzing of individual
> > fields in various XFS structures. Specifically, we want the caller to
> > drop the xfs_db iocursor on the victim field; from there, the scripts
> > should discover all available fields and fuzzing verbs, and try each
> > fuzz verb on every available field.
> >
> > Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> > ---
> > common/fuzzy | 191 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 191 insertions(+)
> >
> >
> [snip]
> > +
> > +# Make sure we have all the pieces we need for field fuzzing
> > +_require_scratch_xfs_fuzz_fields()
> > +{
> > + _require_scratch
> > + _require_scrub
> > + _require_populate_commands
> > + _require_command "$XFS_DB_PROG" "xfs_db"
>
> This is included in _require_populate_commands, not needed here.
<nod>
> > + _scratch_mkfs_xfs >/dev/null 2>&1
> > + _scratch_xfs_db -x -c 'fuzz' 2>&1 | grep -q 'not found' && \
> > + _notrun "xfs_db does not have fuzz command"
>
> Does _require_xfs_db_command work here?
Apparently I forgot to update this after inventing _require_xfs_db_command.
Good catch!
--D
>
> Thanks,
> Eryu
>
> > +}
> > +
> > +# Grab the list of available fuzzing verbs
> > +_scratch_xfs_list_fuzz_verbs() {
> > + if [ -n "${SCRATCH_XFS_LIST_FUZZ_VERBS}" ]; then
> > + echo "${SCRATCH_XFS_LIST_FUZZ_VERBS}" | sed -e 's/ /\n/g'
> > + return;
> > + fi
> > + _scratch_xfs_db -x -c 'sb 0' -c 'fuzz' | grep '^Verbs:' | \
> > + sed -e 's/[,.]//g' -e 's/Verbs: //g' -e 's/ /\n/g'
> > +}
> > +
> > +# Fuzz the fields of some piece of metadata
> > +_scratch_xfs_fuzz_fields() {
> > + _scratch_xfs_list_metadata_fields "$@" | while read field; do
> > + _scratch_xfs_list_fuzz_verbs | while read fuzzverb; do
> > + __scratch_xfs_fuzz_mdrestore
> > + __scratch_xfs_fuzz_field_test "${field}" "${fuzzverb}" "$@"
> > + done
> > + done
> > +}
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* 1804 devicetree
From: sushildhimanphotography-/E1597aS9LQAvxtiuMwx3w @ 2016-11-09 7:54 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: MESSAGE_077122902700505_devicetree.zip --]
[-- Type: application/zip, Size: 2992 bytes --]
^ permalink raw reply
* [PATCH] nvme-rdma: stop and free io queues on connect failure
From: Sagi Grimberg @ 2016-11-09 7:54 UTC (permalink / raw)
In-Reply-To: <01cc01d23a01$f6465b30$e2d31190$@opengridcomputing.com>
Queued, thanks Steve, Pull request will come out shortly...
^ permalink raw reply
* [Bug 70390] [NV84] Repeated system crashes under graphics load, E[PFIFO] DMA_PUSHER 0x00406040 and lots of E[PGRAPH]
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2016-11-09 7:56 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <bug-70390-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
[-- Attachment #1.1: Type: text/plain, Size: 336 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=70390
--- Comment #23 from Mathieu Malaterre <mathieu.malaterre-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> ---
This can reproduce on PPC32 machines easily:
https://bugzilla.kernel.org/show_bug.cgi?id=187111
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1276 bytes --]
[-- Attachment #2: Type: text/plain, Size: 154 bytes --]
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
^ permalink raw reply
* [PATCH] cec-core.rst: improve documentation
From: Hans Verkuil @ 2016-11-09 8:00 UTC (permalink / raw)
To: Linux Media Mailing List
Improve the internal CEC documentation. In particular add a section that specifies that
transmit-related interrupts should be processed before receive interrupts.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
diff --git a/Documentation/media/kapi/cec-core.rst b/Documentation/media/kapi/cec-core.rst
index 88c33b5..8a88dd4 100644
--- a/Documentation/media/kapi/cec-core.rst
+++ b/Documentation/media/kapi/cec-core.rst
@@ -106,13 +106,13 @@ your driver:
int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr);
int (*adap_transmit)(struct cec_adapter *adap, u8 attempts,
u32 signal_free_time, struct cec_msg *msg);
- void (\*adap_log_status)(struct cec_adapter *adap);
+ void (*adap_status)(struct cec_adapter *adap, struct seq_file *file);
/* High-level callbacks */
...
};
-The three low-level ops deal with various aspects of controlling the CEC adapter
+The five low-level ops deal with various aspects of controlling the CEC adapter
hardware:
@@ -238,6 +238,18 @@ When a CEC message was received:
Speaks for itself.
+Implementing the interrupt handler
+----------------------------------
+
+Typically the CEC hardware provides interrupts that signal when a transmit
+finished and whether it was successful or not, and it provides and interrupt
+when a CEC message was received.
+
+The CEC driver should always process the transmit interrupts first before
+handling the receive interrupt. The framework expects to see the cec_transmit_done
+call before the cec_received_msg call, otherwise it can get confused if the
+received message was in reply to the transmitted message.
+
Implementing the High-Level CEC Adapter
---------------------------------------
@@ -247,11 +259,11 @@ CEC protocol driven. The following high-level callbacks are available:
.. code-block:: none
struct cec_adap_ops {
- /\* Low-level callbacks \*/
+ /* Low-level callbacks */
...
- /\* High-level CEC message callback \*/
- int (\*received)(struct cec_adapter \*adap, struct cec_msg \*msg);
+ /* High-level CEC message callback */
+ int (*received)(struct cec_adapter *adap, struct cec_msg *msg);
};
The received() callback allows the driver to optionally handle a newly
@@ -263,7 +275,7 @@ received CEC message
If the driver wants to process a CEC message, then it can implement this
callback. If it doesn't want to handle this message, then it should return
-ENOMSG, otherwise the CEC framework assumes it processed this message and
-it will not no anything with it.
+it will not do anything with it.
CEC framework functions
^ permalink raw reply related
* Re: [PATCH 1/2] kthread: don't use to_live_kthread() in kthread_stop()
From: Thomas Gleixner @ 2016-11-09 7:58 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Andy Lutomirski, Roman Pen, Andy Lutomirski, Peter Zijlstra,
Ingo Molnar, Tejun Heo, linux-kernel@vger.kernel.org,
Chunming Zhou, Alex Deucher
In-Reply-To: <20161031200754.GB19430@redhat.com>
On Mon, 31 Oct 2016, Oleg Nesterov wrote:
> kthread_stop() had to use to_live_kthread() simply because it was not
> possible to access kthread->exited after the exiting kthread clears
> task_struct->vfork_done. Now that to_kthread() is always valid we can
> do wake_up_process() + wait_for_completion() unconditionally, we don't
> care if it has already passed complete_vfork_done() or even dead.
>
> The exiting kthread can get the spurious wakeup after mm_release() but
> this is possible without this change too and this is fine, do_task_dead()
> ensures that this can't make any harm.
>
> Note: we can even change this function to use task_work_add() and avoid
> ->vfork_done altogether, probably we will do this later.
>
> Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
^ permalink raw reply
* Re: [PATCH v2 rdma-core 3/7] libhns: Add verbs of pd and mr support
From: oulijun @ 2016-11-09 8:01 UTC (permalink / raw)
To: Leon Romanovsky
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linuxarm-hv44wF8Li93QT0dZR+AlfA
In-Reply-To: <20161109073426.GL27883-2ukJVAZIZ/Y@public.gmane.org>
在 2016/11/9 15:34, Leon Romanovsky 写道:
> On Sat, Oct 29, 2016 at 05:03:42PM +0800, Lijun Ou wrote:
>> This patch mainly introduces the verbs with pd and mr,
>> included alloc_pd, dealloc_pd, reg_mr and dereg_mr.
>>
>> Signed-off-by: Lijun Ou <oulijun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>> Signed-off-by: Wei Hu <xavier.huwei-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>> ---
>> v2:
>> - No change over v1
>>
>> v1:
>> - The initial submit
>> ---
>> providers/hns/hns_roce_u.c | 4 ++
>> providers/hns/hns_roce_u.h | 18 +++++++++
>> providers/hns/hns_roce_u_abi.h | 6 +++
>> providers/hns/hns_roce_u_verbs.c | 79 ++++++++++++++++++++++++++++++++++++++++
>> 4 files changed, 107 insertions(+)
>
> <....>
>
>> +struct ibv_mr *hns_roce_u_reg_mr(struct ibv_pd *pd, void *addr, size_t length,
>> + int access)
>> +{
>> + int ret;
>> + struct ibv_mr *mr;
>> + struct ibv_reg_mr cmd;
>> + struct ibv_reg_mr_resp resp;
>> +
>> + if (addr == NULL) {
>
> It can be great if you use one style for all your code e.g. if(!addr) ....
>
ok, thanks your advice and i will consider to fix it.
>> + fprintf(stderr, "2nd parm addr is NULL!\n");
>> + return NULL;
>> + }
>> +
>> + if (length == 0) {
>> + fprintf(stderr, "3st parm length is 0!\n");
>> + return NULL;
>> + }
>> +
>> + mr = malloc(sizeof(*mr));
>> + if (mr)
>> + return NULL;
>
> It looks like bug and you wanted if(!mr) and not if(mr).
>
Yes, This is my careless for generating patch. my local server's code is if(!mr)
I will fix it.
Lijun Ou
--
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: BUG: 'list_empty(&vgdev->free_vbufs)' is true!
From: Gerd Hoffmann @ 2016-11-09 8:01 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: David Airlie, Jiri Slaby, Linux kernel mailing list, dri-devel,
virtualization
In-Reply-To: <20161108223153-mutt-send-email-mst@kernel.org>
On Di, 2016-11-08 at 22:37 +0200, Michael S. Tsirkin wrote:
> On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote:
> > Hi,
> >
> > I can relatively easily reproduce this bug:
How?
> > BUG: 'list_empty(&vgdev->free_vbufs)' is true!
> The following might be helpful for debugging - if kernel still will
> not stop panicing, we are looking at some kind
> of memory corruption.
Looking carefully through the code I think it isn't impossible to
trigger this, but you need for that:
(1) command queue full (quite possible),
(2) cursor queue full too (unlikely), and
(3) multiple threads trying to submit commands and waiting for free
space in the command queue (possible with virgl enabled).
Do things improve if you allocate some extra bufs?
int virtio_gpu_alloc_vbufs(struct virtio_gpu_device *vgdev)
{
struct virtio_gpu_vbuffer *vbuf;
- int i, size, count = 0;
+ int i, size, count = 16;
void *ptr;
INIT_LIST_HEAD(&vgdev->free_vbufs);
Memory corruption sounds plausible too.
Redirect console to ttyS0 for trouble-shooting, trying to dump the oops
to the display device which triggered the oops in the first place isn't
going to work very well ...
cheers,
Gerd
^ permalink raw reply
* [GIT PULL] nvme fabrics patches for the next round of 4.9 rc
From: Sagi Grimberg @ 2016-11-09 8:02 UTC (permalink / raw)
Hey Jens,
Mostly some stability fixes for fabrics:
- some memleaks, correctness and verbosity fixes from Bart
- fix command delivery during queue reconnect from Christoph
- nvme rdma reconnect vs io race fix from Christoph and steve
- nvme rdma queue cleanup on connection failure fix from Steve
- nvme rdma target error flow and queue teardown fixes
- nvme rdma queue size fix from Samuel
- nvmet namespace rcu race fix from Sasha
please pull from:
git://git.infradead.org/nvme-fabrics.git nvmf-4.9-rc
----------------------------------------------------------------
Bart Van Assche (6):
nvmet-rdma: Fix REJ status code
nvme/scsi: Remove set-but-not-used variables
nvme-fabrics: Adjust source code indentation
nvme-fabrics: Fix memory leaks in nvmf_parse_options()
nvme-fabrics: Fix a memory leak in an nvmf_create_ctrl() error path
nvmet-rdma: Fix possible NULL deref when handling rdma cm events
Christoph Hellwig (1):
nvme-rdma: reject non-connect commands before the queue is live
Sagi Grimberg (4):
nvme-rdma: remove redundant define
nvmet: Don't queue fatal error work if csts.cfs is set
nvmet-rdma: don't forget to delete a queue from the list of connection failed
nvmet-rdma: drain the queue-pair just before freeing it
Samuel Jones (1):
nvme-rdma: force queue size to respect controller capability
Solganik Alexander (1):
nvmet: Fix possible infinite loop triggered on hot namespace removal
Steve Wise (1):
nvme-rdma: stop and free io queues on connect failure
drivers/nvme/host/fabrics.c | 9 ++++----
drivers/nvme/host/rdma.c | 51 ++++++++++++++++++++++++++++++++++++++----
drivers/nvme/host/scsi.c | 11 ++-------
drivers/nvme/target/configfs.c | 6 ++---
drivers/nvme/target/core.c | 24 ++++++++++++--------
drivers/nvme/target/nvmet.h | 6 +----
drivers/nvme/target/rdma.c | 23 +++++++++++++++----
7 files changed, 92 insertions(+), 38 deletions(-)
^ permalink raw reply
* Re: BUG: 'list_empty(&vgdev->free_vbufs)' is true!
From: Gerd Hoffmann @ 2016-11-09 8:01 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jiri Slaby, virtualization, Linux kernel mailing list,
David Airlie, dri-devel
In-Reply-To: <20161108223153-mutt-send-email-mst@kernel.org>
On Di, 2016-11-08 at 22:37 +0200, Michael S. Tsirkin wrote:
> On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote:
> > Hi,
> >
> > I can relatively easily reproduce this bug:
How?
> > BUG: 'list_empty(&vgdev->free_vbufs)' is true!
> The following might be helpful for debugging - if kernel still will
> not stop panicing, we are looking at some kind
> of memory corruption.
Looking carefully through the code I think it isn't impossible to
trigger this, but you need for that:
(1) command queue full (quite possible),
(2) cursor queue full too (unlikely), and
(3) multiple threads trying to submit commands and waiting for free
space in the command queue (possible with virgl enabled).
Do things improve if you allocate some extra bufs?
int virtio_gpu_alloc_vbufs(struct virtio_gpu_device *vgdev)
{
struct virtio_gpu_vbuffer *vbuf;
- int i, size, count = 0;
+ int i, size, count = 16;
void *ptr;
INIT_LIST_HEAD(&vgdev->free_vbufs);
Memory corruption sounds plausible too.
Redirect console to ttyS0 for trouble-shooting, trying to dump the oops
to the display device which triggered the oops in the first place isn't
going to work very well ...
cheers,
Gerd
^ permalink raw reply
* Re: [PATCH] drivers: tca8418: Change the interrupt type
From: Maxime Ripard @ 2016-11-09 8:02 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <20161109000400.GA8719@dtor-ws>
[-- Attachment #1: Type: text/plain, Size: 862 bytes --]
Hello Dmitry,
On Tue, Nov 08, 2016 at 04:04:00PM -0800, Dmitry Torokhov wrote:
> On Mon, Nov 07, 2016 at 03:40:24PM +0100, Maxime Ripard wrote:
> > The TCA8418 interrupt has a level trigger, not a edge one.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> Hmm, maybe we could rely on OF data for trigger type?
We might, even though the i2c core doesn't change the trigger type
when it retrieves the interrupt from the DT.
However, I'm a bit worried about the other probing mechanims (ACPI,
board files) that should be supported as well, and removing the
trigger type from the flags might break those. There's no board files
using it though in the tree, but I don't know about ACPI systems.
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [Buildroot] [PATCH] package/e2fsprogs: backport build fix for rhel5 due to missing magic
From: Baruch Siach @ 2016-11-09 8:03 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1478677142-11627-1-git-send-email-jcmvbkbc@gmail.com>
Hi Max,
On Tue, Nov 08, 2016 at 11:39:02PM -0800, Max Filippov wrote:
> RHEL 5.x does have magic.h, but it does not define all expected symbols. In
> particular, the NO_CHECK symbols were only added in file 4.20 and RHEL 5.x
> is using 4.17.
Instead of relying on host libmagic that may or may not be installed, why not
add host-file to HOST_E2FSPROGS_DEPENDENCIES?
> Add substitute defines to allow continued usage of magic but without the
> requested exclude checks.
>
> Backported from: b003b2e6f9e54e7b2bde15828b97f5dc285b915e
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [meta-oe][PATCH 0/3] Upgrade 3 benchmark packages
From: kai.kang @ 2016-11-09 7:58 UTC (permalink / raw)
To: openembedded-devel
From: Kai Kang <kai.kang@windriver.com>
Build PASS on qemux86-64 qemuarm qemuppc and qemuarm64.
Build PASS iozone3 and phoronix-test-suite on qemumips64 that mips* are not compatible hosts for libhugetlbfs.
Kai Kang (3):
iozone3: 434 -> 465
libhugetlbfs: 1.19 -> 1.20
phoronix-test-suite: 6.0.1 -> 6.6.1
.../iozone3/{iozone3_434.bb => iozone3_465.bb} | 9 +++---
...ugetlbfs-avoid-using-restrict-as-var-name.patch | 34 ----------------------
.../libhugetlbfs/libhugetlbfs_git.bb | 5 ++--
...suite_6.0.1.bb => phoronix-test-suite_6.6.1.bb} | 5 ++--
4 files changed, 10 insertions(+), 43 deletions(-)
rename meta-oe/recipes-benchmark/iozone3/{iozone3_434.bb => iozone3_465.bb} (92%)
delete mode 100644 meta-oe/recipes-benchmark/libhugetlbfs/files/libhugetlbfs-avoid-using-restrict-as-var-name.patch
rename meta-oe/recipes-benchmark/phoronix-test-suite/{phoronix-test-suite_6.0.1.bb => phoronix-test-suite_6.6.1.bb} (89%)
--
2.10.1
^ permalink raw reply
* [PATCH 1/3] iozone3: 434 -> 465
From: kai.kang @ 2016-11-09 7:58 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <20161109075853.12636-1-kai.kang@windriver.com>
From: Kai Kang <kai.kang@windriver.com>
Update LIC_FILES_CHKSUM according to:
http://www.iozone.org/docs/Iozone_License.txt
Signed-off-by: Kai Kang <kai.kang@windriver.com>
---
.../recipes-benchmark/iozone3/{iozone3_434.bb => iozone3_465.bb} | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
rename meta-oe/recipes-benchmark/iozone3/{iozone3_434.bb => iozone3_465.bb} (92%)
diff --git a/meta-oe/recipes-benchmark/iozone3/iozone3_434.bb b/meta-oe/recipes-benchmark/iozone3/iozone3_465.bb
similarity index 92%
rename from meta-oe/recipes-benchmark/iozone3/iozone3_434.bb
rename to meta-oe/recipes-benchmark/iozone3/iozone3_465.bb
index daa36ee..67ce885 100644
--- a/meta-oe/recipes-benchmark/iozone3/iozone3_434.bb
+++ b/meta-oe/recipes-benchmark/iozone3/iozone3_465.bb
@@ -3,13 +3,14 @@ HOMEPAGE = "http://www.iozone.org/"
AUTHOR = "Don Capps <don.capps2@verizon.net>, William D. Norcott <wnorcott@us.oracle.com>"
SECTION = "console/tests"
LICENSE = "iozone3"
-LIC_FILES_CHKSUM = "file://iozone.c;beginline=268;endline=272;md5=ab42a6185fd0443978871f11a007ac0b"
-
+LIC_FILES_CHKSUM = "file://iozone.c;beginline=37;endline=48;md5=7331260091868dcad0f9edea735b5f4b \
+ file://iozone.c;beginline=260;endline=266;md5=77f9ee51e45b57a7e7519c4fa0b4f00b \
+"
SRC_URI = "http://www.iozone.org/src/current/${BPN}_${PV}.tar \
file://copyright.txt \
"
-SRC_URI[md5sum] = "3e8f4213581407225065b91774e970ed"
-SRC_URI[sha256sum] = "2c388d9db393a5505b31eca38951883744c69745f687f3c7df5185b4681d462a"
+SRC_URI[md5sum] = "c924e5e46fb1cf8145f420e8e57eb954"
+SRC_URI[sha256sum] = "2e3d72916e7d7340a7c505fc0c3d28553fcc5ff2daf41d811368e55bd4e6a293"
S = "${WORKDIR}/${BPN}_${PV}/src/current/"
--
2.10.1
^ permalink raw reply related
* [PATCH 2/3] libhugetlbfs: 1.19 -> 1.20
From: kai.kang @ 2016-11-09 7:58 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <20161109075853.12636-1-kai.kang@windriver.com>
From: Kai Kang <kai.kang@windriver.com>
Upgrade libhugetlbfs from 1.19 to 1.20.
* Remove libhugetlbfs-avoid-using-restrict-as-var-name.patch which is
fixed in upstream.
Signed-off-by: Kai Kang <kai.kang@windriver.com>
---
...ugetlbfs-avoid-using-restrict-as-var-name.patch | 34 ----------------------
.../libhugetlbfs/libhugetlbfs_git.bb | 5 ++--
2 files changed, 2 insertions(+), 37 deletions(-)
delete mode 100644 meta-oe/recipes-benchmark/libhugetlbfs/files/libhugetlbfs-avoid-using-restrict-as-var-name.patch
diff --git a/meta-oe/recipes-benchmark/libhugetlbfs/files/libhugetlbfs-avoid-using-restrict-as-var-name.patch b/meta-oe/recipes-benchmark/libhugetlbfs/files/libhugetlbfs-avoid-using-restrict-as-var-name.patch
deleted file mode 100644
index b77cfe1..0000000
--- a/meta-oe/recipes-benchmark/libhugetlbfs/files/libhugetlbfs-avoid-using-restrict-as-var-name.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-Avoid using keyword restrict as variable name which causes error with gcc 5.x:
-
-| hugeutils.c: In function '__lh_hugetlbfs_setup_env':
-| hugeutils.c:304:40: error: expected identifier or '(' before 'restrict'
-| char *p, *tok, *exe, buf[MAX_EXE+1], restrict[MAX_EXE];
-| ^
-
-Upstream-Status: Pending
-
-Signed-off-by: Kai Kang <kai.kang@windriver.com>
----
-diff --git a/hugeutils.c b/hugeutils.c
-index 53a7fbd..b9d7001 100644
---- a/hugeutils.c
-+++ b/hugeutils.c
-@@ -301,14 +301,14 @@ void hugetlbfs_setup_env()
-
- env = getenv("HUGETLB_RESTRICT_EXE");
- if (env) {
-- char *p, *tok, *exe, buf[MAX_EXE+1], restrict[MAX_EXE];
-+ char *p, *tok, *exe, buf[MAX_EXE+1], restricted[MAX_EXE];
- int found = 0;
-
- exe = get_exe_name(buf, sizeof buf);
- DEBUG("Found HUGETLB_RESTRICT_EXE, this exe is \"%s\"\n", exe);
-- strncpy(restrict, env, sizeof restrict);
-- restrict[sizeof(restrict)-1] = 0;
-- for (p = restrict; (tok = strtok(p, ":")) != NULL; p = NULL) {
-+ strncpy(restricted, env, sizeof restricted);
-+ restricted[sizeof(restricted)-1] = 0;
-+ for (p = restricted; (tok = strtok(p, ":")) != NULL; p = NULL) {
- DEBUG(" ...check exe match for \"%s\"\n", tok);
- if (strcmp(tok, exe) == 0) {
- found = 1;
diff --git a/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb b/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
index 301b550..72553cf 100644
--- a/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
+++ b/meta-oe/recipes-benchmark/libhugetlbfs/libhugetlbfs_git.bb
@@ -7,10 +7,10 @@ DEPENDS = "sysfsutils perl"
RDEPENDS_${PN} += "bash perl python python-io python-lang python-subprocess python-resource ${PN}-perl"
RDEPENDS_${PN}-tests += "bash"
-PV = "2.19"
+PV = "2.20"
PE = "1"
-SRCREV = "426c22d65415fcb8927f68fbc5887e075a8dc40a"
+SRCREV = "e44180072b796c0e28e53c4d01ef6279caaa2a99"
SRC_URI = " \
git://github.com/libhugetlbfs/libhugetlbfs.git;protocol=https \
file://skip-checking-LIB32-and-LIB64-if-they-point-to-the-s.patch \
@@ -18,7 +18,6 @@ SRC_URI = " \
file://tests-Makefile-install-static-4G-edge-testcases.patch \
file://0001-run_test.py-not-use-hard-coded-path-.-obj-hugeadm.patch \
file://libhugetlbfs-elf_i386-avoid-search-host-library-path.patch \
- file://libhugetlbfs-avoid-using-restrict-as-var-name.patch \
file://Force-text-segment-alignment-to-0x08000000-for-i386-.patch \
"
--
2.10.1
^ permalink raw reply related
* Re: [PATCH] mkefidisk.sh: add deprecation warning to the output
From: Ed Bartosh @ 2016-11-09 8:05 UTC (permalink / raw)
To: John Hawley; +Cc: openembedded-core
In-Reply-To: <77d63518-4bd4-0688-438b-07778f754733@intel.com>
On Tue, Nov 08, 2016 at 01:05:23PM -0800, John Hawley wrote:
> On 11/08/2016 12:44 PM, Randy Witt wrote:
> >>>> We should also document, the wic steps in wiki pages e.g.
> >>>> http://wiki.minnowboard.org/Yocto_Project
> >>> It's already documented in README.hardware:
> >>> https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/README.hardware
> >>>
> >>> And in Yocto manual:
> >>> http://www.yoctoproject.org/docs/2.2/mega-manual/mega-manual.html#building-an-image-for-hardware
> >>>
> >>
> >> Thanks, now can you also nudge the minnowboard.org to do the same ?
> >>
> >
> > Pinging you John. :)
>
> So two obvious questions in reading the documentation off the YP site:
>
> 1) Does WIC actually handle the EFI partition for booting off of UEFI
> systems? (guessing yes, but wanted to double check)
Yes, it does.
> 2) I assume it only creates MBR based images, seeing as the suggestion
> is to DD the image down, how does GPT based images work since you can't
> (exactly) DD a GPT image down and have it work "correctly"?
>
Please, elaborate on "correctly". Do you mean that kernel will complain
that backup GPT header is not at the end of disk? This is not handled by
wic obviously. However, even without this image is bootable and
functional.
> Sorry, I'm sure that's covered somewhere else, just want to double check
> this will be ok before I update the documentation on MB
--
Regards,
Ed
^ permalink raw reply
* [PATCH 3/3] phoronix-test-suite: 6.0.1 -> 6.6.1
From: kai.kang @ 2016-11-09 7:58 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <20161109075853.12636-1-kai.kang@windriver.com>
From: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Kai Kang <kai.kang@windriver.com>
---
.../{phoronix-test-suite_6.0.1.bb => phoronix-test-suite_6.6.1.bb} | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
rename meta-oe/recipes-benchmark/phoronix-test-suite/{phoronix-test-suite_6.0.1.bb => phoronix-test-suite_6.6.1.bb} (89%)
diff --git a/meta-oe/recipes-benchmark/phoronix-test-suite/phoronix-test-suite_6.0.1.bb b/meta-oe/recipes-benchmark/phoronix-test-suite/phoronix-test-suite_6.6.1.bb
similarity index 89%
rename from meta-oe/recipes-benchmark/phoronix-test-suite/phoronix-test-suite_6.0.1.bb
rename to meta-oe/recipes-benchmark/phoronix-test-suite/phoronix-test-suite_6.6.1.bb
index aab64a3..1f14048 100644
--- a/meta-oe/recipes-benchmark/phoronix-test-suite/phoronix-test-suite_6.0.1.bb
+++ b/meta-oe/recipes-benchmark/phoronix-test-suite/phoronix-test-suite_6.6.1.bb
@@ -6,8 +6,9 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
SECTION = "console/tests"
SRC_URI = "http://www.phoronix-test-suite.com/releases/${BP}.tar.gz"
-SRC_URI[md5sum] = "c3b26fcc57a3a253e558f759fdc1089f"
-SRC_URI[sha256sum] = "27add54f4ecb464549de580cece84b4a4945b99df3ef7ff7034eb7f23ffb3b39"
+SRC_URI[md5sum] = "5bcac5896a4a34fc6ae4ae94991e1637"
+SRC_URI[sha256sum] = "631ceb808d8bd6cebe69c8b711d55090d6880e906a65837f18fa8200fe7d2c4d"
+
S = "${WORKDIR}/phoronix-test-suite"
inherit systemd allarch
--
2.10.1
^ permalink raw reply related
* Re: [PATCH 6/9 v2] arm64: dts: m3ulcb: enable SDHI0
From: Vladimir Barinov @ 2016-11-09 8:06 UTC (permalink / raw)
To: Simon Horman
Cc: Magnus Damm, Rob Herring, Mark Rutland, devicetree,
linux-renesas-soc
In-Reply-To: <20161109074418.GC30093@verge.net.au>
Hi Simon,
On 09.11.2016 10:44, Simon Horman wrote:
> On Tue, Nov 08, 2016 at 05:14:21PM +0300, Vladimir Barinov wrote:
>> This supports SDHI0 on M3ULCB board SD card slot
>>
>> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>> Reviewed-off-by: Simon Horman <horms+renesas@verge.net.au>
> Thanks Vladimir,
>
> I have queued up the following patches:
>
> arm64: dts: h3ulcb: rename SDHI0 pins
> arm64: dts: h3ulcb: enable SDHI2
> arm64: dts: m3ulcb: enable SDHI2
> arm64: dts: m3ulcb: enable SDHI0
>
> For reference I would, however, like to make some comments regarding the
> way you have submitted these:
>
> 1. I did not provide a Reviewed-off-by tag or any other tag as far as I
> recall. So its not appropriate for you to add one when posting patches.
> I have removed it.
>
> 2. Not withstanding the above, Reviewed-off-by is an invalid tag.
> Perhaps you mean Reviewed-by.
>
> 3. When you repost patches I have a slight preference for you to repost
> them in a fresh thread. And if the patchset has more than one patch then
> with a fresh cover letter. This makes it a little easier for me
> to see what is going on. And gives a more natural place for
> me to respond to a patchset.
Thank you for these valuable comments!
I will follow them for further work.
Regards,
Vladimir
^ 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.