* Re: [PATCH v2] ARM: dts: vfxxx: Enable DMA for DSPI2 and DSPI3
From: Shawn Guo @ 2016-11-14 14:02 UTC (permalink / raw)
To: Sanchayan Maity; +Cc: stefan, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20161114123701.4355-1-maitysanchayan@gmail.com>
On Mon, Nov 14, 2016 at 06:07:01PM +0530, Sanchayan Maity wrote:
> Enable DMA for DSPI2 and DSPI3 on Vybrid.
>
> Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Applied, thanks.
^ permalink raw reply
* [U-Boot] [PATCH 3/7] sunxi: Enable UBI and NAND support
From: Maxime Ripard @ 2016-11-14 14:09 UTC (permalink / raw)
To: u-boot
In-Reply-To: <49cb76e1-cd3c-c912-8acf-74e98377f199@redhat.com>
Hi,
On Mon, Nov 14, 2016 at 12:18:06PM +0100, Hans de Goede wrote:
> > #ifdef CONFIG_SPL_SPI_SUNXI
> > @@ -143,7 +157,14 @@
> > #define CONFIG_GENERIC_MMC
> > #define CONFIG_MMC_SUNXI
> > #define CONFIG_MMC_SUNXI_SLOT 0
> > -#define CONFIG_ENV_IS_IN_MMC
> > +#endif
> > +
> > +#if defined(CONFIG_ENV_IS_IN_NAND)
> > +#define CONFIG_ENV_OFFSET 0xc00000
> > +#define CONFIG_ENV_SIZE 0x400000
> > +#elif defined(CONFIG_ENV_IS_IN_MMC)
> > +#define CONFIG_ENV_OFFSET (544 << 10) /* (8 + 24 + 512) KiB */
> > +#define CONFIG_ENV_SIZE (128 << 10) /* 128 KiB */
> > #define CONFIG_SYS_MMC_ENV_DEV 0 /* first detected MMC controller */
> > #endif
> >
>
> I would greatly prefer putting the env in an UBI partition,
> I thought that we had agreed on doing that ?
That was mentionned a few times, but I didn't remember having a final
decision. I'm not really sure that putting the environment in UBI
would be a good idea.
Attaching the UBI volume takes a very significant time. Doing so
before the user can see that something is happening in the system
feels pretty bad.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161114/06e665bf/attachment.sig>
^ permalink raw reply
* [PATCH] s5p-mfc: Fix clock management in s5p_mfc_release function
From: Marek Szyprowski @ 2016-11-14 14:09 UTC (permalink / raw)
To: linux-media, linux-samsung-soc
Cc: Marek Szyprowski, Sylwester Nawrocki, Krzysztof Kozlowski,
Seung-Woo Kim, Bartlomiej Zolnierkiewicz,
Javier Martinez Canillas, Andrzej Hajda, Shuah Khan,
Luis de Bethencourt
In-Reply-To: <CGME20161114140941eucas1p259a5ef794e4349614f6212cc251b6995@eucas1p2.samsung.com>
Clock control indirectly requires access to MFC device, so call it only
if we are sure that the device exists in s5p_mfc_release function.
s5p_mfc_remove() calls s5p_mfc_final_pm(), which releases all PM related
resources, including clocks, so any call to clocks related functions
is not valid after s5p_mfc_final_pm().
Fixes: d695c12 ("[media] media: s5p-mfc fix invalid memory access from
s5p_mfc_release()")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 0c8a4616e827..a0a29194ccd1 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -940,10 +940,11 @@ static int s5p_mfc_release(struct file *file)
mfc_debug_enter();
if (dev)
mutex_lock(&dev->mfc_mutex);
- s5p_mfc_clock_on();
vb2_queue_release(&ctx->vq_src);
vb2_queue_release(&ctx->vq_dst);
if (dev) {
+ s5p_mfc_clock_on();
+
/* Mark context as idle */
clear_work_bit_irqsave(ctx);
/*
@@ -965,9 +966,9 @@ static int s5p_mfc_release(struct file *file)
if (s5p_mfc_power_off() < 0)
mfc_err("Power off failed\n");
}
+ mfc_debug(2, "Shutting down clock\n");
+ s5p_mfc_clock_off();
}
- mfc_debug(2, "Shutting down clock\n");
- s5p_mfc_clock_off();
if (dev)
dev->ctx[ctx->num] = NULL;
s5p_mfc_dec_ctrls_delete(ctx);
--
1.9.1
^ permalink raw reply related
* Re: [RFC] change mac80211_hwsim tx_rates to ieee80211_tx_rate
From: Johannes Berg @ 2016-11-14 14:09 UTC (permalink / raw)
To: Benjamin Beichler, linux-wireless
In-Reply-To: <faf081ea-18c6-8ad5-e336-aac9a79a0ce3@uni-rostock.de>
> I agree with that, but there exist also other code in hwsim, which is
> tightly coupled with the mac80211 API, as e.g., the usage of
> IEEE80211_TX_MAX_RATES, which already broke older versions of
> wmediumd or similar implementations. Maybe a review regarding such
> things would be good to decouple the userspace daemon from the
> special kernel version.
Agree. It'd be better if that were using nested attributes etc.
Although then again, to really decouple this we should make hwsim
behave towards wmediumd more like real hardware would, and have it pass
just a single rate to userspace, with only success/fail indication
coming back - if it fails, it could walk down the chain of rates
itself. Right now we let wmediumd do this, which is why we have all
these API internals exposed to it.
> > > but I think that will break up the communication to e.g. bob
> > > copelands
> > > wmediumd and similar simulations. I would like to have our
> > > Implementation working with mainline kernels and therefore ask
> > > how we
> > > could achieve this easily.
> > >
> > > Obviously, we could define another field in the hwsim messages,
> > > but
> > > as bob copeland already stated, significantly more information
> > > within
> > > the netlink messages could intensify the timing overhead of
> > > hwsim.
> > I don't think we have any other choice but add the relevant fields
> > as
> > proper attributes.
>
> I'm totally fine with that. Nonetheless, I would suggest to add the
> flags to "struct hwsim_tx_rate", since the flags are also tightly
> coupled to the rates and tries of a frame. To not break up things, we
> could add the flags as a separate attribute in the struct and not as
> part of the bitfield like in the original. This would be possible,
> due
> to the "__packed" flag, but I'm also unsure, whether this is a really
> good idea for a userspace API/ABI.
Changing the struct size itself would break ABI though?
johannes
^ permalink raw reply
* Re: [MINUTES] Linux Plumbers Audio Mini Conference - Santa Fe 2016
From: Mark Brown @ 2016-11-14 14:08 UTC (permalink / raw)
To: Patrick Lai
Cc: alsa-devel@alsa-project.org, mengdong.lin, Mauro Carvalho Chehab,
Koul, Vinod, Pierre-Louis Bossart, Lai, Patrick, Liam Girdwood,
Takashi Iwai, Lars-Peter Clausen, Ughreja, Rakesh A, Eric Laurent,
Charles Keepax, Takashi Sakamoto, Dylan Reid
In-Reply-To: <58289B1F.2010109@codeaurora.org>
[-- Attachment #1.1: Type: text/plain, Size: 594 bytes --]
On Sun, Nov 13, 2016 at 08:55:59AM -0800, Patrick Lai wrote:
> Can people upload their slides? Is there a central place to upload the
> slides? I am in process of preparing workshop presentation to Qualcomm team
> members.
There's no central place for uploading slides - guess sending them in
e-mail in followup to the minutes is as good as anything?
Please don't top post, reply in line with needed context. This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [ovmf baseline-only test] 68034: all pass
From: Platform Team regression test user @ 2016-11-14 14:08 UTC (permalink / raw)
To: xen-devel, osstest-admin
This run is configured for baseline tests only.
flight 68034 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68034/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b17d5507cfdfd10c4f1f5911ffe75fdc49fafa37
baseline version:
ovmf 8677a56af68ea7fc93938c710be2ec53752ae961
Last test of basis 68033 2016-11-14 09:16:38 Z 0 days
Testing same since 68034 2016-11-14 12:18:33 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Feng Tian <feng.tian@intel.com>
Richard Thomaiyar <richard.marian.thomaiyar@intel.com>
Thomaiyar, Richard Marian <richard.marian.thomaiyar@intel.com>
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
------------------------------------------------------------
sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images
Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Push not applicable.
------------------------------------------------------------
commit b17d5507cfdfd10c4f1f5911ffe75fdc49fafa37
Author: Feng Tian <feng.tian@intel.com>
Date: Mon Nov 7 15:46:16 2016 +0800
MdeModulePkg/UsbMass: Revert changes of removing retry logic
This patch is used to revert changes done in commit 17f3e942
bc527fbd75068d2d5752b6af54917487 - "MdeModulePkg/UsbMass: Not
retry if usb bot transfer execution fail"
It's because Usb Floppy will report DEVICE_ERROR for the first
several cmds when it need spin up. so retry logic makes sense.
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
commit f56ae7bf82bf32dd0ec9cafb9f632511813c823e
Author: Thomaiyar, Richard Marian <richard.marian.thomaiyar@intel.com>
Date: Tue Nov 8 17:45:25 2016 +0800
IntelFsp2Pkg: Support to return error status from FSP API done
Added FspMemoryInitDone2, FspTempRamExitDone2, FspSiliconInitDone2
to return error status to Boot Loader for FSP API calls.
To maintain backward compatibility existing functions
(FspMemoryInitDone, FspTempRamExitDone, FspSiliconInitDone)
declaration left untouched.
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Richard Thomaiyar <richard.marian.thomaiyar@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
commit d18f9699e7c98bf63f9d92f8e111bb3a6b3d0882
Author: Feng Tian <feng.tian@intel.com>
Date: Thu Nov 10 13:16:14 2016 +0800
MdePkg: Fix spec mismatch in string representation of EMMC dev node
Cc: Eric Jin <eric.jin@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [U-Boot] [PATCH] net: phy: micrel: Fix error handling
From: Marek Vasut @ 2016-11-14 14:08 UTC (permalink / raw)
To: u-boot
Fix the following error, the $ret variable handling must
be part of the loop, while due to the missing parenthesis
it was not.
drivers/net/phy/micrel.c: In function ?ksz9021_of_config?:
drivers/net/phy/micrel.c:303:2: warning: this ?for? clause does not guard... [-Wmisleading-indentation]
for (i = 0; i < ARRAY_SIZE(ofcfg); i++)
^~~
drivers/net/phy/micrel.c:305:3: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ?for?
if (ret)
^~
drivers/net/phy/micrel.c: In function ?ksz9031_of_config?:
drivers/net/phy/micrel.c:411:2: warning: this ?for? clause does not guard... [-Wmisleading-indentation]
for (i = 0; i < ARRAY_SIZE(ofcfg); i++)
^~~
drivers/net/phy/micrel.c:413:3: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ?for?
if (ret)
^~
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Joe Hershberger <joe.hershberger@ni.com>
---
drivers/net/phy/micrel.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 28a1401..7163fa2 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -300,10 +300,11 @@ static int ksz9021_of_config(struct phy_device *phydev)
};
int i, ret = 0;
- for (i = 0; i < ARRAY_SIZE(ofcfg); i++)
+ for (i = 0; i < ARRAY_SIZE(ofcfg); i++) {
ret = ksz90x1_of_config_group(phydev, &(ofcfg[i]));
if (ret)
return ret;
+ }
return 0;
}
@@ -408,10 +409,11 @@ static int ksz9031_of_config(struct phy_device *phydev)
};
int i, ret = 0;
- for (i = 0; i < ARRAY_SIZE(ofcfg); i++)
+ for (i = 0; i < ARRAY_SIZE(ofcfg); i++) {
ret = ksz90x1_of_config_group(phydev, &(ofcfg[i]));
if (ret)
return ret;
+ }
return 0;
}
--
2.10.2
^ permalink raw reply related
* Re: [Qemu-devel] [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration
From: Marcelo Tosatti @ 2016-11-14 14:00 UTC (permalink / raw)
To: Paolo Bonzini
Cc: kvm, qemu-devel, Dr. David Alan Gilbert, Juan Quintela,
Radim Krcmar, Eduardo Habkost
In-Reply-To: <a3e00c38-4d4d-d353-231d-9eb0233139e2@redhat.com>
On Mon, Nov 14, 2016 at 02:54:38PM +0100, Paolo Bonzini wrote:
>
>
> On 14/11/2016 13:36, Marcelo Tosatti wrote:
> > + /* local (running VM) restore */
> > + if (s->clock_valid) {
> > + /*
> > + * if host does not support reliable KVM_GET_CLOCK,
> > + * read kvmclock value from memory
> > + */
> > + if (!kvm_has_adjust_clock_stable()) {
> > + time_at_migration = kvmclock_current_nsec(s);
>
> Just assign to s->clock here...
If kvmclock is not enabled, you want to use s->clock,
rather than 0.
> > + }
> > + /* migration/savevm/init restore */
> > + } else {
> > + /*
> > + * use s->clock in case machine uses reliable
> > + * get clock and host where vm was executing
> > + * supported reliable get clock
> > + */
> > + if (!s->mach_use_reliable_get_clock ||
> > + !s->src_use_reliable_get_clock) {
> > + time_at_migration = kvmclock_current_nsec(s);
>
> ... and here, so that time_at_migration is not needed anymore.
Same as above.
> Also here it's enough to look at s->src_user_reliable_get_clock, because
> if s->mach_use_reliable_get_clock is false,
> s->src_use_reliable_get_clock will be false as well.
Yes, but i like the code annotation.
> > + }
> > + }
> >
> > - /* We can't rely on the migrated clock value, just discard it */
> > + /* We can't rely on the saved clock value, just discard it */
> > if (time_at_migration) {
> > s->clock = time_at_migration;
>
> [...]
>
> >
> > +static bool kvmclock_src_use_reliable_get_clock(void *opaque)
> > +{
> > + KVMClockState *s = opaque;
> > +
> > + /*
> > + * On machine types that support reliable KVM_GET_CLOCK,
> > + * if host kernel does provide reliable KVM_GET_CLOCK,
> > + * set src_use_reliable_get_clock=true so that destination
> > + * avoids reading kvmclock from memory.
> > + */
> > + if (s->mach_use_reliable_get_clock && kvm_has_adjust_clock_stable()) {
> > + s->src_use_reliable_get_clock = true;
> > + }
> > +
> > + return s->src_use_reliable_get_clock;
> > +}
>
> Here you can just return s->mach_use_reliable_get_clock.
mach_use_reliable_get_clock can be true but host might not support it.
> To set
> s->src_use_reliable_get_clock, after issuing KVM_GET_CLOCK you can look
> at the KVM_CLOCK_TSC_STABLE bit in the kvm_clock struct's flags.
KVM_CLOCK_TSC_STABLE bit in the kvmclock structure !=
KVM_GET_CLOCK returns reliable value, right?
> You don't actually need kvm_has_adjust_clock_stable(), but please place
> the KVM_GET_CLOCK code for kvmclock_pre_save and
> kvmclock_vm_state_change in a common function.
Sure.
> Also, just another small nit: please make your scripts use the "-p"
> option on diff. :)
Sure.
>
> Thanks,
>
> Paolo
^ permalink raw reply
* Re: [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration
From: Marcelo Tosatti @ 2016-11-14 14:00 UTC (permalink / raw)
To: Paolo Bonzini
Cc: kvm, qemu-devel, Dr. David Alan Gilbert, Juan Quintela,
Radim Krcmar, Eduardo Habkost
In-Reply-To: <a3e00c38-4d4d-d353-231d-9eb0233139e2@redhat.com>
On Mon, Nov 14, 2016 at 02:54:38PM +0100, Paolo Bonzini wrote:
>
>
> On 14/11/2016 13:36, Marcelo Tosatti wrote:
> > + /* local (running VM) restore */
> > + if (s->clock_valid) {
> > + /*
> > + * if host does not support reliable KVM_GET_CLOCK,
> > + * read kvmclock value from memory
> > + */
> > + if (!kvm_has_adjust_clock_stable()) {
> > + time_at_migration = kvmclock_current_nsec(s);
>
> Just assign to s->clock here...
If kvmclock is not enabled, you want to use s->clock,
rather than 0.
> > + }
> > + /* migration/savevm/init restore */
> > + } else {
> > + /*
> > + * use s->clock in case machine uses reliable
> > + * get clock and host where vm was executing
> > + * supported reliable get clock
> > + */
> > + if (!s->mach_use_reliable_get_clock ||
> > + !s->src_use_reliable_get_clock) {
> > + time_at_migration = kvmclock_current_nsec(s);
>
> ... and here, so that time_at_migration is not needed anymore.
Same as above.
> Also here it's enough to look at s->src_user_reliable_get_clock, because
> if s->mach_use_reliable_get_clock is false,
> s->src_use_reliable_get_clock will be false as well.
Yes, but i like the code annotation.
> > + }
> > + }
> >
> > - /* We can't rely on the migrated clock value, just discard it */
> > + /* We can't rely on the saved clock value, just discard it */
> > if (time_at_migration) {
> > s->clock = time_at_migration;
>
> [...]
>
> >
> > +static bool kvmclock_src_use_reliable_get_clock(void *opaque)
> > +{
> > + KVMClockState *s = opaque;
> > +
> > + /*
> > + * On machine types that support reliable KVM_GET_CLOCK,
> > + * if host kernel does provide reliable KVM_GET_CLOCK,
> > + * set src_use_reliable_get_clock=true so that destination
> > + * avoids reading kvmclock from memory.
> > + */
> > + if (s->mach_use_reliable_get_clock && kvm_has_adjust_clock_stable()) {
> > + s->src_use_reliable_get_clock = true;
> > + }
> > +
> > + return s->src_use_reliable_get_clock;
> > +}
>
> Here you can just return s->mach_use_reliable_get_clock.
mach_use_reliable_get_clock can be true but host might not support it.
> To set
> s->src_use_reliable_get_clock, after issuing KVM_GET_CLOCK you can look
> at the KVM_CLOCK_TSC_STABLE bit in the kvm_clock struct's flags.
KVM_CLOCK_TSC_STABLE bit in the kvmclock structure !=
KVM_GET_CLOCK returns reliable value, right?
> You don't actually need kvm_has_adjust_clock_stable(), but please place
> the KVM_GET_CLOCK code for kvmclock_pre_save and
> kvmclock_vm_state_change in a common function.
Sure.
> Also, just another small nit: please make your scripts use the "-p"
> option on diff. :)
Sure.
>
> Thanks,
>
> Paolo
^ permalink raw reply
* Re: [PATCH v2 00/10] wic: bugfixes & --fixed-size support, tests, selftest: minor fixes
From: Burton, Ross @ 2016-11-14 14:07 UTC (permalink / raw)
To: Maciej Borzęcki; +Cc: Paul Eggleton, Maciej Borzecki, OE-core
In-Reply-To: <CAD4b0_KC108KpwO3kvWqt7LCoqAQZ88_R0b_BXmmuSFAv_xVfQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 575 bytes --]
On 14 November 2016 at 14:03, Maciej Borzęcki <maciej.borzecki@rndity.com>
wrote:
> TARGET_ARCH is in fact not exported as you have indicated, there's this
> piece in meta/conf/bitbake.conf:
>
Ah yes there's a bit of bad interaction between unexport variables, the
hack that is -e, and the even greater hack that is get_bb_var.
I actually have a patch to change the -e output, I've just noticed that it
will break selftest as that makes assumptions about -e output, but it does
solve the problem that you can't reliably use get_bb_var() on unexport.
Ross
[-- Attachment #2: Type: text/html, Size: 1064 bytes --]
^ permalink raw reply
* [Buildroot] [PATCH] config: bump linux kernel to 4.8.6 in synopsys defconfigs
From: Thomas Petazzoni @ 2016-11-14 14:07 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1479126748.3874.28.camel@synopsys.com>
Hello,
On Mon, 14 Nov 2016 12:32:29 +0000, Vlad Zakharov wrote:
> We apologize for coming late with that update.
> But could you please apply it on master as it is important for us to come up with latest kernel in upcoming Buildroot release.
> Updated configs were build- and run tested on corresponding platforms, so there shouldn't be any regressions there.
Once -rc1 has passed, we don't apply version bumps (be it to packages
or defconfigs), unless they fix a specific issue.
What is the issue with having this update part of 2017.02 ?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [U-Boot] [PATCH] socfpga: add support for Terasic DE1-SoC board
From: Marek Vasut @ 2016-11-14 14:07 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1479131620-26313-1-git-send-email-agust@denx.de>
On 11/14/2016 02:53 PM, Anatolij Gustschin wrote:
> Add CycloneV based Terasic DE1-SoC board. The board boots
> from SD/MMC. Ethernet and USB host is supported.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> Cc: Marek Vasut <marex@denx.de>
[...]
> diff --git a/include/configs/socfpga_de1_soc.h b/include/configs/socfpga_de1_soc.h
> new file mode 100644
> index 0000000..9514b27
> --- /dev/null
> +++ b/include/configs/socfpga_de1_soc.h
> @@ -0,0 +1,60 @@
> +/*
> + * Copyright (C) 2016 Marek Vasut <marex@denx.de>
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +#ifndef __CONFIG_TERASIC_DE1_SOC_H__
> +#define __CONFIG_TERASIC_DE1_SOC_H__
> +
> +#include <asm/arch/base_addr_ac5.h>
> +
> +/* U-Boot Commands */
> +#define CONFIG_SYS_NO_FLASH
> +#define CONFIG_DOS_PARTITION
> +#define CONFIG_FAT_WRITE
> +#define CONFIG_HW_WATCHDOG
> +
> +/* Memory configurations */
> +#define PHYS_SDRAM_1_SIZE 0x40000000 /* 1GiB */
> +
> +/* Booting Linux */
> +#define CONFIG_BOOTFILE "fitImage"
> +#define CONFIG_BOOTARGS "console=ttyS0," __stringify(CONFIG_BAUDRATE)
> +#define CONFIG_BOOTCOMMAND "run mmcload; run mmcboot"
> +#define CONFIG_LOADADDR 0x01000000
> +#define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR
> +
> +/* Ethernet on SoC (EMAC) */
> +#if defined(CONFIG_CMD_NET)
> +#define CONFIG_PHY_MICREL
> +#define CONFIG_PHY_MICREL_KSZ9021
> +#endif
> +
> +#define CONFIG_ENV_IS_IN_MMC
> +
> +/* Extra Environment */
> +#define CONFIG_EXTRA_ENV_SETTINGS \
> + "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
> + "ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \
> + "bootm ${loadaddr} - ${fdtaddr}\0" \
> + "bootimage=zImage\0" \
> + "fdtaddr=100\0" \
> + "fdtimage=socfpga.dtb\0" \
> + "bootm ${loadaddr} - ${fdtaddr}\0" \
> + "mmcroot=/dev/mmcblk0p2\0" \
> + "mmcboot=setenv bootargs " CONFIG_BOOTARGS \
> + " root=${mmcroot} rw rootwait;" \
> + "bootz ${loadaddr} - ${fdtaddr}\0" \
> + "mmcload=mmc rescan;" \
> + "load mmc 0:1 ${loadaddr} ${bootimage};" \
> + "load mmc 0:1 ${fdtaddr} ${fdtimage}\0" \
> +
> +/* The rest of the configuration is shared */
> +#include <configs/socfpga_common.h>
> +
> +#undef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION
> +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION 2
Why is this needed ? Just start U-Boot from partition 1 as all the other
SoCFPGAs do , esp. since this is a devkit, please keep it consistent.
Looks great otherwise :)
> +#define CONFIG_SPL_ABORT_ON_RAW_IMAGE
> +
> +#endif /* __CONFIG_TERASIC_DE1_SOC_H__ */
>
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH v6 7/9] drm/hisilicon/hibmc: Add connector for VDAC
From: Rongrong Zou @ 2016-11-14 14:07 UTC (permalink / raw)
To: Sean Paul, Rongrong Zou
Cc: Mark Rutland, Archit, shenhui, Tomeu Vizoso, Jonathan Corbet,
Dave Airlie, catalin.marinas, Emil Velikov, linuxarm, dri-devel,
Xinliang Liu, james.xiong, Daniel Stone, Daniel Vetter,
Will Deacon, lijianhua, Linux ARM Kernel, Benjamin Gaignard
In-Reply-To: <CAOw6vbJA3Oe3GmRZBZjF24wtu_5hyTdVL2HK-1p3BLbiY1G7Tw@mail.gmail.com>
在 2016/11/11 9:45, Sean Paul 写道:
> On Fri, Oct 28, 2016 at 3:28 AM, Rongrong Zou <zourongrong@gmail.com> wrote:
>> Add connector funcs and helper funcs for VDAC.
>>
>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>> ---
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 8 +++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 +
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 76 ++++++++++++++++++++++++
>> 3 files changed, 86 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> index ba191e1..4253603 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> @@ -131,6 +131,14 @@ static int hibmc_kms_init(struct hibmc_drm_device *hidev)
>> return ret;
>> }
>>
>> + ret = hibmc_connector_init(hidev);
>> + if (ret) {
>> + DRM_ERROR("failed to init connector\n");
>> + return ret;
>> + }
>> +
>> + drm_mode_connector_attach_encoder(&hidev->connector,
>> + &hidev->encoder);
>
> The connector should be initialized in the vdac driver with the
> encoder, not in the drv file (same as plane/crtc)
applied, thanks.
>
>> return 0;
>> }
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> index 401cea4..450247d 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> @@ -48,6 +48,7 @@ struct hibmc_drm_device {
>> struct drm_plane plane;
>> struct drm_crtc crtc;
>> struct drm_encoder encoder;
>> + struct drm_connector connector;
>
> No need to keep track here
will allocate with devm_kzalloc(), thanks.
>
>> bool mode_config_initialized;
>>
>> /* ttm */
>> @@ -89,6 +90,7 @@ static inline struct hibmc_bo *gem_to_hibmc_bo(struct drm_gem_object *gem)
>> int hibmc_plane_init(struct hibmc_drm_device *hidev);
>> int hibmc_crtc_init(struct hibmc_drm_device *hidev);
>> int hibmc_encoder_init(struct hibmc_drm_device *hidev);
>> +int hibmc_connector_init(struct hibmc_drm_device *hidev);
>> int hibmc_fbdev_init(struct hibmc_drm_device *hidev);
>> void hibmc_fbdev_fini(struct hibmc_drm_device *hidev);
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
>> index 953f659..ebefcd1 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
>> @@ -87,3 +87,79 @@ int hibmc_encoder_init(struct hibmc_drm_device *hidev)
>> drm_encoder_helper_add(encoder, &hibmc_encoder_helper_funcs);
>> return 0;
>> }
>> +
>> +static int hibmc_connector_get_modes(struct drm_connector *connector)
>> +{
>> + int count;
>> +
>> + count = drm_add_modes_noedid(connector, 800, 600);
>> + drm_set_preferred_mode(connector, defx, defy);
>
> So you have defx/defy as module parameters, but then hardcode the
> 800x600 mode. If defx/defy is anything other than 800/600, this won't
> work. I think you should just remove the defx/defy module params and
> rely on userspace adding modes as appropriate.
will remove them, thanks.
>
>> + return count;
>> +}
>> +
>> +static int hibmc_connector_mode_valid(struct drm_connector *connector,
>> + struct drm_display_mode *mode)
>> +{
>> + struct hibmc_drm_device *hiprivate =
>> + container_of(connector, struct hibmc_drm_device, connector);
>> + unsigned long size = mode->hdisplay * mode->vdisplay * 4;
>
> Why * 4 here and why * 2 below? You support formats less than 32 bpp,
> so the * 4 isn't necessarily correct for all formats. Is the * 2 to
> account for front & back buffer?
>
it is from bochs, the original comments below:
/*
* Make sure we can fit two framebuffers into video memory.
* This allows up to 1600x1200 with 16 MB (default size).
* If you want more try this:
* 'qemu -vga std -global VGA.vgamem_mb=32 $otherargs'
*/
i think it is not necessary for hibmc, so will remove it and return
MODE_OK, thanks.
>
>> +
>> + if (size * 2 > hiprivate->fb_size)
>> + return MODE_BAD;
>> +
>> + return MODE_OK;
>> +}
>> +
>> +static struct drm_encoder *
>> +hibmc_connector_best_encoder(struct drm_connector *connector)
>> +{
>> + int enc_id = connector->encoder_ids[0];
>> +
>> + /* pick the encoder ids */
>> + if (enc_id)
>> + return drm_encoder_find(connector->dev, enc_id);
>
> Can't you just do return drm_encoder_find(connector->dev,
> connector->encoder_ids[0]); ?
>
> ie: won't drm_encoder_find do the right thing if you pass in id == 0?
hibmc_connector_best_encoder(struct drm_connector *connector)
{
return drm_encoder_find(connector->dev, connector->encoder_ids[0]);
}
looks more simple, i like it, thanks:)
>
>> +
>> + return NULL;
>> +}
>> +
>> +static enum drm_connector_status hibmc_connector_detect(struct drm_connector
>> + *connector, bool force)
>> +{
>> + return connector_status_connected;
>
> Perhaps this should be connector_status_unknown, since you don't
> necessarily know it's connected.
it is always connected in hibmc's scenario, usually it is used as a
management chip on server, we use KVM(keyboard, mouse, video) rather than
a directly connected monitor. I will modify if a phisical monitor
is connected later.
>
>> +}
>> +
>> +static const struct drm_connector_helper_funcs
>> + hibmc_connector_connector_helper_funcs = {
>> + .get_modes = hibmc_connector_get_modes,
>> + .mode_valid = hibmc_connector_mode_valid,
>> + .best_encoder = hibmc_connector_best_encoder,
>> +};
>> +
>> +static const struct drm_connector_funcs hibmc_connector_connector_funcs = {
>> + .dpms = drm_atomic_helper_connector_dpms,
>> + .detect = hibmc_connector_detect,
>> + .fill_modes = drm_helper_probe_single_connector_modes,
>> + .destroy = drm_connector_cleanup,
>> + .reset = drm_atomic_helper_connector_reset,
>> + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
>> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>> +};
>> +
>> +int hibmc_connector_init(struct hibmc_drm_device *hidev)
>> +{
>> + struct drm_device *dev = hidev->dev;
>> + struct drm_connector *connector = &hidev->connector;
>> + int ret;
>> +
>> + ret = drm_connector_init(dev, connector,
>> + &hibmc_connector_connector_funcs,
>> + DRM_MODE_CONNECTOR_VGA);
>> + if (ret) {
>> + DRM_ERROR("failed to init connector\n");
>> + return ret;
>> + }
>> + drm_connector_helper_add(connector,
>> + &hibmc_connector_connector_helper_funcs);
>> +
>> + return 0;
>> +}
>> --
>> 1.9.1
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> _______________________________________________
> linuxarm mailing list
> linuxarm@huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
>
> .
>
--
Regards, Rongrong
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 7/9] drm/hisilicon/hibmc: Add connector for VDAC
From: Rongrong Zou @ 2016-11-14 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOw6vbJA3Oe3GmRZBZjF24wtu_5hyTdVL2HK-1p3BLbiY1G7Tw@mail.gmail.com>
? 2016/11/11 9:45, Sean Paul ??:
> On Fri, Oct 28, 2016 at 3:28 AM, Rongrong Zou <zourongrong@gmail.com> wrote:
>> Add connector funcs and helper funcs for VDAC.
>>
>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>> ---
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 8 +++
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 +
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 76 ++++++++++++++++++++++++
>> 3 files changed, 86 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> index ba191e1..4253603 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> @@ -131,6 +131,14 @@ static int hibmc_kms_init(struct hibmc_drm_device *hidev)
>> return ret;
>> }
>>
>> + ret = hibmc_connector_init(hidev);
>> + if (ret) {
>> + DRM_ERROR("failed to init connector\n");
>> + return ret;
>> + }
>> +
>> + drm_mode_connector_attach_encoder(&hidev->connector,
>> + &hidev->encoder);
>
> The connector should be initialized in the vdac driver with the
> encoder, not in the drv file (same as plane/crtc)
applied, thanks.
>
>> return 0;
>> }
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> index 401cea4..450247d 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> @@ -48,6 +48,7 @@ struct hibmc_drm_device {
>> struct drm_plane plane;
>> struct drm_crtc crtc;
>> struct drm_encoder encoder;
>> + struct drm_connector connector;
>
> No need to keep track here
will allocate with devm_kzalloc(), thanks.
>
>> bool mode_config_initialized;
>>
>> /* ttm */
>> @@ -89,6 +90,7 @@ static inline struct hibmc_bo *gem_to_hibmc_bo(struct drm_gem_object *gem)
>> int hibmc_plane_init(struct hibmc_drm_device *hidev);
>> int hibmc_crtc_init(struct hibmc_drm_device *hidev);
>> int hibmc_encoder_init(struct hibmc_drm_device *hidev);
>> +int hibmc_connector_init(struct hibmc_drm_device *hidev);
>> int hibmc_fbdev_init(struct hibmc_drm_device *hidev);
>> void hibmc_fbdev_fini(struct hibmc_drm_device *hidev);
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
>> index 953f659..ebefcd1 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
>> @@ -87,3 +87,79 @@ int hibmc_encoder_init(struct hibmc_drm_device *hidev)
>> drm_encoder_helper_add(encoder, &hibmc_encoder_helper_funcs);
>> return 0;
>> }
>> +
>> +static int hibmc_connector_get_modes(struct drm_connector *connector)
>> +{
>> + int count;
>> +
>> + count = drm_add_modes_noedid(connector, 800, 600);
>> + drm_set_preferred_mode(connector, defx, defy);
>
> So you have defx/defy as module parameters, but then hardcode the
> 800x600 mode. If defx/defy is anything other than 800/600, this won't
> work. I think you should just remove the defx/defy module params and
> rely on userspace adding modes as appropriate.
will remove them, thanks.
>
>> + return count;
>> +}
>> +
>> +static int hibmc_connector_mode_valid(struct drm_connector *connector,
>> + struct drm_display_mode *mode)
>> +{
>> + struct hibmc_drm_device *hiprivate =
>> + container_of(connector, struct hibmc_drm_device, connector);
>> + unsigned long size = mode->hdisplay * mode->vdisplay * 4;
>
> Why * 4 here and why * 2 below? You support formats less than 32 bpp,
> so the * 4 isn't necessarily correct for all formats. Is the * 2 to
> account for front & back buffer?
>
it is from bochs, the original comments below:
/*
* Make sure we can fit two framebuffers into video memory.
* This allows up to 1600x1200 with 16 MB (default size).
* If you want more try this:
* 'qemu -vga std -global VGA.vgamem_mb=32 $otherargs'
*/
i think it is not necessary for hibmc, so will remove it and return
MODE_OK, thanks.
>
>> +
>> + if (size * 2 > hiprivate->fb_size)
>> + return MODE_BAD;
>> +
>> + return MODE_OK;
>> +}
>> +
>> +static struct drm_encoder *
>> +hibmc_connector_best_encoder(struct drm_connector *connector)
>> +{
>> + int enc_id = connector->encoder_ids[0];
>> +
>> + /* pick the encoder ids */
>> + if (enc_id)
>> + return drm_encoder_find(connector->dev, enc_id);
>
> Can't you just do return drm_encoder_find(connector->dev,
> connector->encoder_ids[0]); ?
>
> ie: won't drm_encoder_find do the right thing if you pass in id == 0?
hibmc_connector_best_encoder(struct drm_connector *connector)
{
return drm_encoder_find(connector->dev, connector->encoder_ids[0]);
}
looks more simple, i like it, thanks:)
>
>> +
>> + return NULL;
>> +}
>> +
>> +static enum drm_connector_status hibmc_connector_detect(struct drm_connector
>> + *connector, bool force)
>> +{
>> + return connector_status_connected;
>
> Perhaps this should be connector_status_unknown, since you don't
> necessarily know it's connected.
it is always connected in hibmc's scenario, usually it is used as a
management chip on server, we use KVM(keyboard, mouse, video) rather than
a directly connected monitor. I will modify if a phisical monitor
is connected later.
>
>> +}
>> +
>> +static const struct drm_connector_helper_funcs
>> + hibmc_connector_connector_helper_funcs = {
>> + .get_modes = hibmc_connector_get_modes,
>> + .mode_valid = hibmc_connector_mode_valid,
>> + .best_encoder = hibmc_connector_best_encoder,
>> +};
>> +
>> +static const struct drm_connector_funcs hibmc_connector_connector_funcs = {
>> + .dpms = drm_atomic_helper_connector_dpms,
>> + .detect = hibmc_connector_detect,
>> + .fill_modes = drm_helper_probe_single_connector_modes,
>> + .destroy = drm_connector_cleanup,
>> + .reset = drm_atomic_helper_connector_reset,
>> + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
>> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>> +};
>> +
>> +int hibmc_connector_init(struct hibmc_drm_device *hidev)
>> +{
>> + struct drm_device *dev = hidev->dev;
>> + struct drm_connector *connector = &hidev->connector;
>> + int ret;
>> +
>> + ret = drm_connector_init(dev, connector,
>> + &hibmc_connector_connector_funcs,
>> + DRM_MODE_CONNECTOR_VGA);
>> + if (ret) {
>> + DRM_ERROR("failed to init connector\n");
>> + return ret;
>> + }
>> + drm_connector_helper_add(connector,
>> + &hibmc_connector_connector_helper_funcs);
>> +
>> + return 0;
>> +}
>> --
>> 1.9.1
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> _______________________________________________
> linuxarm mailing list
> linuxarm at huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
>
> .
>
--
Regards, Rongrong
^ permalink raw reply
* Re: [PATCH 1/4] fpga mgr: Introduce FPGA capabilities
From: atull @ 2016-11-14 14:06 UTC (permalink / raw)
To: Moritz Fischer
Cc: linux-kernel, moritz.fischer.private, michal.simek,
soren.brinkmann, linux-arm-kernel, julia
In-Reply-To: <20161107001326.7395-2-moritz.fischer@ettus.com>
[-- Attachment #1: Type: text/plain, Size: 2357 bytes --]
On Mon, 7 Nov 2016, Moritz Fischer wrote:
> Add FPGA capabilities as a way to express the capabilities
> of a given FPGA manager.
>
> Removes code duplication by comparing the low-level driver's
> capabilities at the framework level rather than having each driver
> check for supported operations in the write_init() callback.
>
> This allows for extending with additional capabilities, similar
> to the the dmaengine framework's implementation.
>
> Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
> Cc: Alan Tull <atull@opensource.altera.com>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Cc: Sören Brinkmann <soren.brinkmann@xilinx.com>
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> ---
>
> Changes from RFC:
> * in the RFC the caps weren't actually stored into the struct fpga_mgr
>
> Note:
>
> If people disagree on the typedef being a 'false positive' I can fix
> that in a future rev of the patchset.
>
> Thanks,
>
> Moritz
>
> ---
> drivers/fpga/fpga-mgr.c | 15 ++++++++++++++
> drivers/fpga/socfpga.c | 10 +++++-----
> drivers/fpga/zynq-fpga.c | 7 ++++++-
> include/linux/fpga/fpga-mgr.h | 46 ++++++++++++++++++++++++++++++++++++++++++-
> 4 files changed, 71 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> index 953dc91..ed57c17 100644
> --- a/drivers/fpga/fpga-mgr.c
> +++ b/drivers/fpga/fpga-mgr.c
> @@ -49,6 +49,18 @@ int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags, const char *buf,
> struct device *dev = &mgr->dev;
> int ret;
>
> + if (flags & FPGA_MGR_PARTIAL_RECONFIG &&
> + !fpga_mgr_has_cap(FPGA_MGR_CAP_PARTIAL_RECONF, mgr->caps)) {
> + dev_err(dev, "Partial reconfiguration not supported\n");
> + return -ENOTSUPP;
> + }
> +
> + if (flags & FPGA_MGR_FULL_RECONFIG &&
> + !fpga_mgr_has_cap(FPGA_MGR_CAP_FULL_RECONF, mgr->caps)) {
> + dev_err(dev, "Full reconfiguration not supported\n");
> + return -ENOTSUPP;
> + }
> +
Could you move the checks to their own function like
'fpga_mgr_check_caps()' or something? I really like it if we can keep
the functions short, like a screen or so where it's practicle to do
so and I could see the number of caps growing here. The only
counter argument I could think of is if a cap affects the sequence
in this function. Hmmm...
Alan
^ permalink raw reply
* kvm: WARNING in kvm_arch_vcpu_ioctl_run
From: Dmitry Vyukov @ 2016-11-14 14:00 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, x86@kernel.org, KVM list, LKML,
Steve Rutherford
Cc: syzkaller
Hello,
The following program triggers WARNING in kvm_arch_vcpu_ioctl_run in
run in parallel loop:
https://gist.githubusercontent.com/dvyukov/08091eee6f38548ff9e6905c5e0eaaee/raw/8cae95f2e88eeb98c4ddc06d227670c1e248222f/gistfile1.txt
On commit e234832afb623fe5c7d1d5703d6619494d8d703f (Nov 13)
WARNING: CPU: 3 PID: 11141 at arch/x86/kvm/x86.c:6984
kvm_arch_vcpu_ioctl_run+0x1f0/0x4f50
CPU: 3 PID: 11141 Comm: syz-executor Not tainted 4.9.0-rc5+ #24
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffff880039cef698 ffffffff834c3959 ffffffff00000003 1ffff1000739de66
ffffed000739de5e 0000000041b58ab3 ffffffff89576450 ffffffff834c366b
0000000041b58ab3 ffffffff894d2830 ffffffff81590020 ffffffff810d90f0
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff834c3959>] dump_stack+0x2ee/0x3f5 lib/dump_stack.c:51
[<ffffffff81849908>] panic+0x200/0x425 kernel/panic.c:179
[<ffffffff813fd919>] __warn+0x1c9/0x1e0 kernel/panic.c:542
[<ffffffff813fdb81>] warn_slowpath_null+0x31/0x40 kernel/panic.c:585
[<ffffffff810ee930>] kvm_arch_vcpu_ioctl_run+0x1f0/0x4f50
arch/x86/kvm/x86.c:6984
[<ffffffff8107b328>] kvm_vcpu_ioctl+0x678/0x11c0
arch/x86/kvm/../../../virt/kvm/kvm_main.c:2557
[< inline >] vfs_ioctl fs/ioctl.c:43
[<ffffffff81abdb44>] do_vfs_ioctl+0x1c4/0x1630 fs/ioctl.c:679
[< inline >] SYSC_ioctl fs/ioctl.c:694
[<ffffffff81abf044>] SyS_ioctl+0x94/0xc0 fs/ioctl.c:685
[<ffffffff88144885>] entry_SYSCALL_64_fastpath+0x23/0xc6
^ permalink raw reply
* [PATCH 1/4] fpga mgr: Introduce FPGA capabilities
From: atull @ 2016-11-14 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107001326.7395-2-moritz.fischer@ettus.com>
On Mon, 7 Nov 2016, Moritz Fischer wrote:
> Add FPGA capabilities as a way to express the capabilities
> of a given FPGA manager.
>
> Removes code duplication by comparing the low-level driver's
> capabilities at the framework level rather than having each driver
> check for supported operations in the write_init() callback.
>
> This allows for extending with additional capabilities, similar
> to the the dmaengine framework's implementation.
>
> Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
> Cc: Alan Tull <atull@opensource.altera.com>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Cc: S?ren Brinkmann <soren.brinkmann@xilinx.com>
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> ---
>
> Changes from RFC:
> * in the RFC the caps weren't actually stored into the struct fpga_mgr
>
> Note:
>
> If people disagree on the typedef being a 'false positive' I can fix
> that in a future rev of the patchset.
>
> Thanks,
>
> Moritz
>
> ---
> drivers/fpga/fpga-mgr.c | 15 ++++++++++++++
> drivers/fpga/socfpga.c | 10 +++++-----
> drivers/fpga/zynq-fpga.c | 7 ++++++-
> include/linux/fpga/fpga-mgr.h | 46 ++++++++++++++++++++++++++++++++++++++++++-
> 4 files changed, 71 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> index 953dc91..ed57c17 100644
> --- a/drivers/fpga/fpga-mgr.c
> +++ b/drivers/fpga/fpga-mgr.c
> @@ -49,6 +49,18 @@ int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags, const char *buf,
> struct device *dev = &mgr->dev;
> int ret;
>
> + if (flags & FPGA_MGR_PARTIAL_RECONFIG &&
> + !fpga_mgr_has_cap(FPGA_MGR_CAP_PARTIAL_RECONF, mgr->caps)) {
> + dev_err(dev, "Partial reconfiguration not supported\n");
> + return -ENOTSUPP;
> + }
> +
> + if (flags & FPGA_MGR_FULL_RECONFIG &&
> + !fpga_mgr_has_cap(FPGA_MGR_CAP_FULL_RECONF, mgr->caps)) {
> + dev_err(dev, "Full reconfiguration not supported\n");
> + return -ENOTSUPP;
> + }
> +
Could you move the checks to their own function like
'fpga_mgr_check_caps()' or something? I really like it if we can keep
the functions short, like a screen or so where it's practicle to do
so and I could see the number of caps growing here. The only
counter argument I could think of is if a cap affects the sequence
in this function. Hmmm...
Alan
^ permalink raw reply
* Re: [Qemu-devel] virtIO question
From: Stefan Hajnoczi @ 2016-11-14 14:06 UTC (permalink / raw)
To: zhunxun@gmail.com; +Cc: qemu
In-Reply-To: <201611121643189598926@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]
On Sat, Nov 12, 2016 at 04:43:21PM +0800, zhunxun@gmail.com wrote:
> Thanks,the expression is not the key problem,I just write it wrong,the key problem is that what I get from the code is everytime dirver add a sg ,it will call virtqueue_kick,such as network driver,in start_xmit function ,it called xmit_skb generate a sg list and add it to the queue,then called virtqueue_kick ,why it handle like this??can you explain it to me??thank you very much!!!
I can see there *are* cases in Linux 4.9-rc1 virtio_net.c:start_xmit()
where virtqueue_kick() is skipped so that multiple tx packets can be
added to the virtqueue in a single kick.
static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
{
...
bool kick = !skb->xmit_more;
...
if (kick || netif_xmit_stopped(txq))
virtqueue_kick(sq->vq);
...
}
Also keep in mind that the virtio driver APIs in Linux are used by
multiple device drivers (virtio_net.ko, virtio_blk.ko, etc).
virtio_net.ko does not use all features offered by the API.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH -v4 1/8] locking/drm: Kill mutex trickery
From: Peter Zijlstra @ 2016-11-14 14:04 UTC (permalink / raw)
To: Ingo Molnar
Cc: Daniel Vetter, Linus Torvalds, Waiman Long, Jason Low,
Ding Tianhong, Thomas Gleixner, Will Deacon, Ingo Molnar,
Imre Deak, Linux Kernel Mailing List, Davidlohr Bueso, Tim Chen,
Terry Rudd, Paul E. McKenney, Jason Low, Chris Wilson, Rob Clark
In-Reply-To: <20161112105849.GA24520@gmail.com>
On Sat, Nov 12, 2016 at 11:58:49AM +0100, Ingo Molnar wrote:
> Could you send a final version of trylock_recursive() patch for me to apply?
The latest lives here:
lkml.kernel.org/r/20161109103813.GN3157@twins.programming.kicks-ass.net
But I would really like someone to actually test that before you stick
it in.
^ permalink raw reply
* Re: Xen like VirtualBox
From: Jason Long @ 2016-11-14 14:05 UTC (permalink / raw)
To: Dario Faggioli, Xen-devel@lists.xen.org
In-Reply-To: <1479131438.6046.17.camel@citrix.com>
Thank you but the problem is that "virt-manager" is for Redhat and Redhat don't like Xen anymore because of KVM. Another problem is that a program like VirtualBox has a nice GUI but virt-manager not.
On Monday, November 14, 2016 5:22 PM, Dario Faggioli <dario.faggioli@citrix.com> wrote:
On Thu, 2016-11-10 at 18:20 +0000, Jason Long wrote:
> I mean is a nice GUI like VirtualBox.
>
It's certainly possible, and it would be nice. It's "just" that no one
has stepped up and started to do it. :-)
Personally, I think that, rather than developing something from
scratch, it would be a lot better to use virt-manager
(https://virt-manager.org/), or other similar front-ends.
About virt-manager, it is built on top of libvirt, and Xen support in
libvirt has improved a lot during the past couple of years. Thath means
a bunch of things and features actually work already.
It would be really nice and useful if someone could actually try and
use it with Xen, and report here and to the libvir and virt-manager
communities what is missing/not working.
Thanks and Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH] ieee802154: check device type
From: Stefan Schmidt @ 2016-11-14 14:04 UTC (permalink / raw)
To: Alexander Aring, Vegard Nossum
Cc: linux-wpan, Marcel Holtmann, Alexander Aring
In-Reply-To: <6daeeb69-fc93-24b3-8218-bc483df65b45@pengutronix.de>
Hello Marcel,
could you apply this to bluetooth-next?
regards
Stefan Schmidt
On 23/07/16 14:21, Alexander Aring wrote:
>
> Hi,
>
> On 07/20/2016 10:43 AM, Vegard Nossum wrote:
>> I've observed a NULL pointer dereference in ieee802154_del_iface() during
>> netlink fuzzing. It's the ->wpan_phy dereference here:
>>
>> phy = dev->ieee802154_ptr->wpan_phy;
>>
>> My bet is that we're not checking that this is an IEEE802154 interface,
>> so let's do what ieee802154_nl_get_dev() is doing. (Maybe we should even
>> be calling this directly?)
>>
>> Cc: Lennert Buytenhek <buytenh@wantstofly.org>
>> Cc: Alexander Aring <alex.aring@gmail.com>
>> Cc: Marcel Holtmann <marcel@holtmann.org>
>> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>> Cc: Sergey Lapin <slapin@ossfans.org>
>> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
>
> Acked-by: Alexander Aring <aar@pengutronix.de>
>
> thanks for letting us known that this bug exists.
>
> Unfortunate I don't care much about this code. This code is part of the
> old UAPI for 802.15.4 subsystems and there are many bugs known.
>
> Nevertheless I added my ack here and would like that Marcel apply this
> patch into his bluetooth tree repository.
>
> The new netlink api exists since 3.19 and highly recommended to don't
> use the old stuff. The ieee802154 never got out the experimental state,
> there was a patch [0] which globally remove the experimental Kconfig
> entry, but no maintainer ever said that this branch isn't in
> experimental state anymore.
>
> I will prepare a RFC series to remove all deprecated handling which we
> have replacements for it, these are:
>
> - old netlink api
> - af_802154 raw sockets, will replaced by AF_PACKET RAW
>
> - Alex
>
> [0] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/net/ieee802154/Kconfig?id=f4671a90c418b5aae14b61a9fc9d79c629403ca0
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wpan" 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
* [LTP] [RFC] Cleanup of tools/ directory
From: Cyril Hrubis @ 2016-11-14 14:05 UTC (permalink / raw)
To: ltp
Hi!
I've stumbled upon the tools/ directory and there is quite a lot of
broken code that is not really useful for anything.
The Makefile skips netpipe*, pounder21 and top-LTP directories. Apart
from automatic changes nobody touched the top-LTP and netpipe* code for
more than six years, so I would say that it's safe enough to remove
these. The pounder21 had some fixes that looks like somebody is using
that so I guess that we should keep it.
Then there are files that looks like they could be removed as well:
* STPfailure_report.pl - most likely no change since 2004, looks useless o me
* ltp_master, ltp_check, README, ltpoutput*
- remnants of some automated framework that used ltprun script that
used runalltests.sh script, I will remove these since there is no
reason to keep them now
In short has anybody anything agains removal of netpipe*, top-LTP,
STPfailure_report.pl, ltp_master, ltp_check, README, and ltpoutput* from
the tools/ directory?
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply
* Re: [PATCH v4 2/3] PCI: qcom: add support to msm8996 PCIE controller
From: Vivek Gautam @ 2016-11-14 14:04 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: svarbanov, linux-pci, Bjorn Helgaas, robh+dt, linux-arm-msm,
devicetree@vger.kernel.org
In-Reply-To: <1479122155-13393-3-git-send-email-srinivas.kandagatla@linaro.org>
On Mon, Nov 14, 2016 at 4:45 PM, Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
> This patch adds support to msm8996/apq8096 pcie, MSM8996 supports
> Gen 1/2, One lane, 3 pcie root-complex with support to MSI and
> legacy interrupts and it conforms to PCI Express Base 2.1 specification.
>
> This patch adds post_init callback to qcom_pcie_ops, as this is pcie
> pipe clocks are only setup after the phy is powered on.
> It also adds ltssm_enable callback as it is very much different to other
> supported SOCs in the driver.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
Reviewed-by: Vivek Gautam <vivek.gautam@codeaurora.org>
Thanks
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH V3 3/5] arm64: hw_breakpoint: Handle inexact watchpoint addresses
From: Pratyush Anand @ 2016-11-14 14:02 UTC (permalink / raw)
To: will.deacon, Mark Rutland
Cc: linux-arm-kernel, labath, linux-kernel, jan.kratochvil, onestero,
Pavel Labath, Pratyush Anand
In-Reply-To: <cover.1479130617.git.panand@redhat.com>
From: Pavel Labath <test.tberghammer@gmail.com>
Arm64 hardware does not always report a watchpoint hit address that
matches one of the watchpoints set. It can also report an address
"near" the watchpoint if a single instruction access both watched and
unwatched addresses. There is no straight-forward way, short of
disassembling the offending instruction, to map that address back to
the watchpoint.
Previously, when the hardware reported a watchpoint hit on an address
that did not match our watchpoint (this happens in case of instructions
which access large chunks of memory such as "stp") the process would
enter a loop where we would be continually resuming it (because we did
not recognise that watchpoint hit) and it would keep hitting the
watchpoint again and again. The tracing process would never get
notified of the watchpoint hit.
This commit fixes the problem by looking at the watchpoints near the
address reported by the hardware. If the address does not exactly match
one of the watchpoints we have set, it attributes the hit to the
nearest watchpoint we have. This heuristic is a bit dodgy, but I don't
think we can do much more, given the hardware limitations.
[panand: reworked to rebase on his patches]
Signed-off-by: Pavel Labath <labath@google.com>
Signed-off-by: Pratyush Anand <panand@redhat.com>
---
arch/arm64/kernel/hw_breakpoint.c | 96 ++++++++++++++++++++++++++++-----------
1 file changed, 69 insertions(+), 27 deletions(-)
diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
index 3f7bc65e7ef6..f69bf368d916 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -664,11 +664,46 @@ static int breakpoint_handler(unsigned long unused, unsigned int esr,
}
NOKPROBE_SYMBOL(breakpoint_handler);
+/*
+ * Arm64 hardware does not always report a watchpoint hit address that matches
+ * one of the watchpoints set. It can also report an address "near" the
+ * watchpoint if a single instruction access both watched and unwatched
+ * addresses. There is no straight-forward way, short of disassembling the
+ * offending instruction, to map that address back to the watchpoint. This
+ * function computes the distance of the memory access from the watchpoint as a
+ * heuristic for the likelyhood that a given access triggered the watchpoint.
+ *
+ * See Section D2.10.5 "Determining the memory location that caused a Watchpoint
+ * exception" of ARMv8 Architecture Reference Manual for details.
+ *
+ * The function returns the distance of the address from the bytes watched by
+ * the watchpoint. In case of an exact match, it returns 0.
+ */
+static u64 get_distance_from_watchpoint(unsigned long addr, u64 val,
+ struct arch_hw_breakpoint_ctrl *ctrl)
+{
+ u64 wp_low, wp_high;
+ u32 lens, lene;
+
+ lens = ffs(ctrl->len) - 1;
+ lene = fls(ctrl->len) - 1;
+
+ wp_low = val + lens;
+ wp_high = val + lene;
+ if (addr < wp_low)
+ return wp_low - addr;
+ else if (addr > wp_high)
+ return addr - wp_high;
+ else
+ return 0;
+}
+
static int watchpoint_handler(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
{
- int i, step = 0, *kernel_step, access;
- u32 ctrl_reg, lens, lene;
+ int i, step = 0, *kernel_step, access, closest_match = 0;
+ u64 min_dist = -1, dist;
+ u32 ctrl_reg;
u64 val;
struct perf_event *wp, **slots;
struct debug_info *debug_info;
@@ -678,31 +713,15 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr,
slots = this_cpu_ptr(wp_on_reg);
debug_info = ¤t->thread.debug;
+ /*
+ * Find all watchpoints that match the reported address. If no exact
+ * match is found. Attribute the hit to the closest watchpoint.
+ */
+ rcu_read_lock();
for (i = 0; i < core_num_wrps; ++i) {
- rcu_read_lock();
-
wp = slots[i];
-
if (wp == NULL)
- goto unlock;
-
- info = counter_arch_bp(wp);
-
- /* Check if the watchpoint value and byte select match. */
- val = read_wb_reg(AARCH64_DBG_REG_WVR, i);
- ctrl_reg = read_wb_reg(AARCH64_DBG_REG_WCR, i);
- decode_ctrl_reg(ctrl_reg, &ctrl);
- lens = ffs(ctrl.len) - 1;
- lene = fls(ctrl.len) - 1;
- /*
- * FIXME: reported address can be anywhere between "the
- * lowest address accessed by the memory access that
- * triggered the watchpoint" and "the highest watchpointed
- * address accessed by the memory access". So, it may not
- * lie in the interval of watchpoint address range.
- */
- if (addr < val + lens || addr > val + lene)
- goto unlock;
+ continue;
/*
* Check that the access type matches.
@@ -711,18 +730,41 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr,
access = (esr & AARCH64_ESR_ACCESS_MASK) ? HW_BREAKPOINT_W :
HW_BREAKPOINT_R;
if (!(access & hw_breakpoint_type(wp)))
- goto unlock;
+ continue;
+ /* Check if the watchpoint value and byte select match. */
+ val = read_wb_reg(AARCH64_DBG_REG_WVR, i);
+ ctrl_reg = read_wb_reg(AARCH64_DBG_REG_WCR, i);
+ decode_ctrl_reg(ctrl_reg, &ctrl);
+ dist = get_distance_from_watchpoint(addr, val, &ctrl);
+ if (dist < min_dist) {
+ min_dist = dist;
+ closest_match = i;
+ }
+ /* Is this an exact match? */
+ if (dist != 0)
+ continue;
+
+ info = counter_arch_bp(wp);
info->trigger = addr;
perf_bp_event(wp, regs);
/* Do we need to handle the stepping? */
if (is_default_overflow_handler(wp))
step = 1;
+ }
+ if (min_dist > 0 && min_dist != -1) {
+ /* No exact match found. */
+ wp = slots[closest_match];
+ info = counter_arch_bp(wp);
+ info->trigger = addr;
+ perf_bp_event(wp, regs);
-unlock:
- rcu_read_unlock();
+ /* Do we need to handle the stepping? */
+ if (is_default_overflow_handler(wp))
+ step = 1;
}
+ rcu_read_unlock();
if (!step)
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH V3 4/5] arm64: Allow hw watchpoint of length 3,5,6 and 7
From: Pratyush Anand @ 2016-11-14 14:02 UTC (permalink / raw)
To: will.deacon, Mark Rutland
Cc: linux-arm-kernel, labath, linux-kernel, jan.kratochvil, onestero,
Pratyush Anand
In-Reply-To: <cover.1479130617.git.panand@redhat.com>
Since, arm64 can support all offset within a double word limit. Therefore,
now support other lengths within that range as well.
Signed-off-by: Pratyush Anand <panand@redhat.com>
---
arch/arm64/include/asm/hw_breakpoint.h | 4 ++++
arch/arm64/kernel/hw_breakpoint.c | 36 ++++++++++++++++++++++++++++++++++
2 files changed, 40 insertions(+)
diff --git a/arch/arm64/include/asm/hw_breakpoint.h b/arch/arm64/include/asm/hw_breakpoint.h
index d1c3b06ad307..b6b167ac082b 100644
--- a/arch/arm64/include/asm/hw_breakpoint.h
+++ b/arch/arm64/include/asm/hw_breakpoint.h
@@ -77,7 +77,11 @@ static inline void decode_ctrl_reg(u32 reg,
/* Lengths */
#define ARM_BREAKPOINT_LEN_1 0x1
#define ARM_BREAKPOINT_LEN_2 0x3
+#define ARM_BREAKPOINT_LEN_3 0x7
#define ARM_BREAKPOINT_LEN_4 0xf
+#define ARM_BREAKPOINT_LEN_5 0x1f
+#define ARM_BREAKPOINT_LEN_6 0x3f
+#define ARM_BREAKPOINT_LEN_7 0x7f
#define ARM_BREAKPOINT_LEN_8 0xff
/* Kernel stepping */
diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
index f69bf368d916..504d075a1351 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -317,9 +317,21 @@ static int get_hbp_len(u8 hbp_len)
case ARM_BREAKPOINT_LEN_2:
len_in_bytes = 2;
break;
+ case ARM_BREAKPOINT_LEN_3:
+ len_in_bytes = 3;
+ break;
case ARM_BREAKPOINT_LEN_4:
len_in_bytes = 4;
break;
+ case ARM_BREAKPOINT_LEN_5:
+ len_in_bytes = 5;
+ break;
+ case ARM_BREAKPOINT_LEN_6:
+ len_in_bytes = 6;
+ break;
+ case ARM_BREAKPOINT_LEN_7:
+ len_in_bytes = 7;
+ break;
case ARM_BREAKPOINT_LEN_8:
len_in_bytes = 8;
break;
@@ -381,9 +393,21 @@ int arch_bp_generic_fields(struct arch_hw_breakpoint_ctrl ctrl,
case ARM_BREAKPOINT_LEN_2:
*gen_len = HW_BREAKPOINT_LEN_2;
break;
+ case ARM_BREAKPOINT_LEN_3:
+ *gen_len = HW_BREAKPOINT_LEN_3;
+ break;
case ARM_BREAKPOINT_LEN_4:
*gen_len = HW_BREAKPOINT_LEN_4;
break;
+ case ARM_BREAKPOINT_LEN_5:
+ *gen_len = HW_BREAKPOINT_LEN_5;
+ break;
+ case ARM_BREAKPOINT_LEN_6:
+ *gen_len = HW_BREAKPOINT_LEN_6;
+ break;
+ case ARM_BREAKPOINT_LEN_7:
+ *gen_len = HW_BREAKPOINT_LEN_7;
+ break;
case ARM_BREAKPOINT_LEN_8:
*gen_len = HW_BREAKPOINT_LEN_8;
break;
@@ -427,9 +451,21 @@ static int arch_build_bp_info(struct perf_event *bp)
case HW_BREAKPOINT_LEN_2:
info->ctrl.len = ARM_BREAKPOINT_LEN_2;
break;
+ case HW_BREAKPOINT_LEN_3:
+ info->ctrl.len = ARM_BREAKPOINT_LEN_3;
+ break;
case HW_BREAKPOINT_LEN_4:
info->ctrl.len = ARM_BREAKPOINT_LEN_4;
break;
+ case HW_BREAKPOINT_LEN_5:
+ info->ctrl.len = ARM_BREAKPOINT_LEN_5;
+ break;
+ case HW_BREAKPOINT_LEN_6:
+ info->ctrl.len = ARM_BREAKPOINT_LEN_6;
+ break;
+ case HW_BREAKPOINT_LEN_7:
+ info->ctrl.len = ARM_BREAKPOINT_LEN_7;
+ break;
case HW_BREAKPOINT_LEN_8:
info->ctrl.len = ARM_BREAKPOINT_LEN_8;
break;
--
2.7.4
^ 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.