* [PATCH v5 4/5] USB: ohci: da8xx: Add devicetree bindings
From: Axel Haslam @ 2016-11-14 14:41 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
khilman-DgEjT+Ai2ygdnm+yROfE0A, kishon-l0cyMroinI0
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Axel Haslam,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161114144103.12120-1-ahaslam-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
This patch documents the device tree bindings required for
the ohci controller found in TI da8xx family of SoC's
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Axel Haslam <ahaslam-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
.../devicetree/bindings/usb/ohci-da8xx.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/ohci-da8xx.txt
diff --git a/Documentation/devicetree/bindings/usb/ohci-da8xx.txt b/Documentation/devicetree/bindings/usb/ohci-da8xx.txt
new file mode 100644
index 0000000..2dc8f67
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ohci-da8xx.txt
@@ -0,0 +1,23 @@
+DA8XX USB OHCI controller
+
+Required properties:
+
+ - compatible: Should be "ti,da830-ohci"
+ - reg: Should contain one register range i.e. start and length
+ - interrupts: Description of the interrupt line
+ - phys: Phandle for the PHY device
+ - phy-names: Should be "usb-phy"
+
+Optional properties:
+ - vbus-supply: phandle of regulator that controls vbus power / over-current
+
+Example:
+
+ohci: usb@0225000 {
+ compatible = "ti,da830-ohci";
+ reg = <0x225000 0x1000>;
+ interrupts = <59>;
+ phys = <&usb_phy 1>;
+ phy-names = "usb-phy";
+ vbus-supply = <®_usb_ohci>;
+};
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v3 11/14] HACK drm/i915/scheduler: emulate a scheduler for guc
From: Chris Wilson @ 2016-11-14 14:40 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: intel-gfx
In-Reply-To: <473eaa91-b372-f7f1-3f86-284159308aa7@linux.intel.com>
On Mon, Nov 14, 2016 at 11:31:11AM +0000, Tvrtko Ursulin wrote:
>
> On 14/11/2016 08:57, Chris Wilson wrote:
> >This emulates execlists on top of the GuC in order to defer submission of
> >requests to the hardware. This deferral allows time for high priority
> >requests to gazump their way to the head of the queue, however it nerfs
> >the GuC by converting it back into a simple execlist (where the CPU has
> >to wake up after every request to feed new commands into the GuC).
>
> Don't know what to do with this one. It feels like it should be a
> separate patch so it can be performance evaluated properly?
Yes. It is not clear if this is the right approach for the guc, since
the firmware may have other ideas on how to do scheduling. It is an
interesting thought experiment into how easy it would be to add
scheduling on top!
> It is also not clear to me why we don't need any similar limiting
> for the execlists request merging?
This uses exactly the same merging strategy as execlists (with the
exception of not supporting gvt's single request dispatch), so we should
be merging a ringfill of requests from one context if available. Which
of course has it's downsides wrt to scheduling latency without preemption,
and I'm not if there is even a right answer without preemption +
timeslicing - the choice is more or less merge everything, or merge
nothing, so we stick with the status quo of merge everything until
proven otherwise.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH ethtool v2 2/2] Ethtool: Implements ETHTOOL_PHY_GTUNABLE/ETHTOOL_PHY_STUNABLE and PHY downshift
From: Andrew Lunn @ 2016-11-14 14:03 UTC (permalink / raw)
To: Allan W. Nielsen; +Cc: netdev, raju.lakkaraju
In-Reply-To: <1479115787-1265-3-git-send-email-allan.nielsen@microsemi.com>
> +.B \-\-get\-phy\-tunable
> +Gets the PHY tunable parameters.
> +.RS 4
> +.TP
> +.B downshift
> +For operation in cabling environments that are incompatible with 1000BAST-T,
BASE
> +PHY device provides an automatic link speed downshift operation.
> +Link speed downshift after N failed 1000BASE-T auto-negotiation attempts.
> +
> +Gets the PHY downshift count/status.
> +.RE
> .SH BUGS
> Not supported (in part or whole) on all network drivers.
> .SH AUTHOR
> diff --git a/ethtool.c b/ethtool.c
> index 49ac94e..3b7ea4e 100644
> --- a/ethtool.c
> +++ b/ethtool.c
> @@ -4520,6 +4520,146 @@ static int do_seee(struct cmd_context *ctx)
> return 0;
> }
>
> +static int do_get_phy_tunable(struct cmd_context *ctx)
> +{
> + int argc = ctx->argc;
> + char **argp = ctx->argp;
> + int err, i;
> + u8 downshift_changed = 0;
> +
> + if (argc < 1)
> + exit_bad_args();
> + for (i = 0; i < argc; i++) {
> + if (!strcmp(argp[i], "downshift")) {
> + downshift_changed = 1;
> + i += 1;
> + } else {
> + exit_bad_args();
> + }
> + }
> +
> + if (downshift_changed) {
> + struct ethtool_tunable ds;
> + u8 count = 0;
> +
> + ds.cmd = ETHTOOL_PHY_GTUNABLE;
> + ds.id = ETHTOOL_PHY_DOWNSHIFT;
> + ds.type_id = ETHTOOL_TUNABLE_U8;
> + ds.len = 1;
> + ds.data[0] = &count;
> + err = send_ioctl(ctx, &ds);
> + if (err < 0) {
> + perror("Cannot Get PHY downshift count");
> + err = 87;
> + }
> + count = *((u8 *)&ds.data[0]);
> + if (count)
> + fprintf(stdout, " Downshift count: %d\n",
> + count);
> + else
> + fprintf(stdout, " Downshift disabled\n");
Please be consistent with the spaces.
Also, if send_ioctl() returns an error, you print the error message,
and then still print the value of count. You look to be missing a
return or an else.
Andrew
^ permalink raw reply
* [PATCH nf-next] netfilter: nf_log: do not assume ethernet header in netdev family
From: Liping Zhang @ 2016-11-14 14:39 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, Liping Zhang
From: Liping Zhang <zlpnobody@gmail.com>
In netdev family, we will handle non ethernet packets, so using
eth_hdr(skb)->h_proto is incorrect.
Meanwhile, we can use socket(AF_PACKET...) to sending packets, so
skb->protocol is not always set in bridge family.
Add an extra parameter into nf_log_l2packet to solve this issue.
Fixes: 1fddf4bad0ac ("netfilter: nf_log: add packet logging for netdev family")
Signed-off-by: Liping Zhang <zlpnobody@gmail.com>
---
include/net/netfilter/nf_log.h | 4 +++-
net/bridge/netfilter/nf_log_bridge.c | 3 ++-
net/netfilter/nf_log_common.c | 3 ++-
net/netfilter/nf_log_netdev.c | 3 ++-
4 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/include/net/netfilter/nf_log.h b/include/net/netfilter/nf_log.h
index a559aa4..450f87f 100644
--- a/include/net/netfilter/nf_log.h
+++ b/include/net/netfilter/nf_log.h
@@ -109,7 +109,9 @@ void nf_log_dump_packet_common(struct nf_log_buf *m, u_int8_t pf,
const struct net_device *out,
const struct nf_loginfo *loginfo,
const char *prefix);
-void nf_log_l2packet(struct net *net, u_int8_t pf, unsigned int hooknum,
+void nf_log_l2packet(struct net *net, u_int8_t pf,
+ __be16 protocol,
+ unsigned int hooknum,
const struct sk_buff *skb,
const struct net_device *in,
const struct net_device *out,
diff --git a/net/bridge/netfilter/nf_log_bridge.c b/net/bridge/netfilter/nf_log_bridge.c
index c197b1f..bd2b3c7 100644
--- a/net/bridge/netfilter/nf_log_bridge.c
+++ b/net/bridge/netfilter/nf_log_bridge.c
@@ -24,7 +24,8 @@ static void nf_log_bridge_packet(struct net *net, u_int8_t pf,
const struct nf_loginfo *loginfo,
const char *prefix)
{
- nf_log_l2packet(net, pf, hooknum, skb, in, out, loginfo, prefix);
+ nf_log_l2packet(net, pf, eth_hdr(skb)->h_proto, hooknum, skb,
+ in, out, loginfo, prefix);
}
static struct nf_logger nf_bridge_logger __read_mostly = {
diff --git a/net/netfilter/nf_log_common.c b/net/netfilter/nf_log_common.c
index ed9b808..dc61399 100644
--- a/net/netfilter/nf_log_common.c
+++ b/net/netfilter/nf_log_common.c
@@ -177,6 +177,7 @@ EXPORT_SYMBOL_GPL(nf_log_dump_packet_common);
/* bridge and netdev logging families share this code. */
void nf_log_l2packet(struct net *net, u_int8_t pf,
+ __be16 protocol,
unsigned int hooknum,
const struct sk_buff *skb,
const struct net_device *in,
@@ -184,7 +185,7 @@ void nf_log_l2packet(struct net *net, u_int8_t pf,
const struct nf_loginfo *loginfo,
const char *prefix)
{
- switch (eth_hdr(skb)->h_proto) {
+ switch (protocol) {
case htons(ETH_P_IP):
nf_log_packet(net, NFPROTO_IPV4, hooknum, skb, in, out,
loginfo, "%s", prefix);
diff --git a/net/netfilter/nf_log_netdev.c b/net/netfilter/nf_log_netdev.c
index 1f64594..350eb14 100644
--- a/net/netfilter/nf_log_netdev.c
+++ b/net/netfilter/nf_log_netdev.c
@@ -23,7 +23,8 @@ static void nf_log_netdev_packet(struct net *net, u_int8_t pf,
const struct nf_loginfo *loginfo,
const char *prefix)
{
- nf_log_l2packet(net, pf, hooknum, skb, in, out, loginfo, prefix);
+ nf_log_l2packet(net, pf, skb->protocol, hooknum, skb, in, out,
+ loginfo, prefix);
}
static struct nf_logger nf_netdev_logger __read_mostly = {
--
2.5.5
^ permalink raw reply related
* Re: [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU
From: Arnd Bergmann @ 2016-11-14 14:37 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Russell King - ARM Linux, Andrew Lunn, Heiko Stuebner,
geert+renesas, Linus Walleij, Liviu Dudau, Patrice Chotard,
Wei Xu, Jisheng Zhang, pankaj.dubey, magnus.damm, Michal Simek,
krzk, thomas.ab, cpgs ., Stephen Warren, Ray Jui, horms, Jun Nie,
shiraz.linux.kernel, linux-kernel, vireshk, Dinh Nguyen,
Shawn Guo
In-Reply-To: <20161114135018.GL1041@n2100.armlinux.org.uk>
On Monday, November 14, 2016 1:50:18 PM CET Russell King - ARM Linux wrote:
> On Mon, Nov 14, 2016 at 01:03:09PM +0100, Arnd Bergmann wrote:
> > On Monday, November 14, 2016 2:10:16 PM CET pankaj.dubey wrote:
> > > >> + scu_base = of_iomap(np, 0);
> > > >> + of_node_put(np);
> > > >> + if (!scu_base) {
> > > >> + pr_err("%s failed to map scu_base via DT\n", __func__);
> > > >
> > > > For non-ca5, non-ca9 based SoCs, we'll see this error msg. We understand
> > > > what does it mean, but it may confuse normal users. In current version,
> > > > berlin doesn't complain like this for non-ca9 SoCs
> > > >
> > >
> > > OK, let me see other reviewer's comment on this. Then we will decide if
> > > this error message is required or can be omitted.
> >
> > We need to look at all callers here, to see if the function ever gets
> > called for a CPU that doesn't have an SCU. I'd say we should warn if
> > we know there is an SCU but we cannot map it, but never warn on
> > any of the CPU cores that don't support an SCU.
>
> Maybe there should be two helpers:
>
> of_scu_enable() which _only_ looks up the SCU address in DT and enables
> it if it finds it, otherwise returning failure.
>
> a9_scu_enable() which tries to use the A9 provided SCU address and
> enables it if it finds it, otherwise returning failure.
>
> Then callers can decide which of these to call, and what error messages
> to print on their failures.
Splitting the function in two is probably simpler overall, but
we may still have to look at all the callers: Any platform that
currently tries to map it on any CPU and doesn't warn about the
absence of the device node (or about scu_a9_has_base() == false)
should really continue not to warn about that.
If all platforms only call these on SMP machines with an
ARM11MPcore, Cortex-A5 or Cortex-A9, everything should be
fine here, otherwise we can leave the warning in the caller
after checking the return code of the new APIs.
Arnd
^ permalink raw reply
* Re: [PATHCv10 1/2] usb: USB Type-C connector class
From: Heikki Krogerus @ 2016-11-14 14:39 UTC (permalink / raw)
To: Greg KH
Cc: Guenter Roeck, Oliver Neukum, Felipe Balbi, Bin Gao, linux-kernel,
linux-usb
In-Reply-To: <20161114141123.GA21395@kroah.com>
On Mon, Nov 14, 2016 at 03:11:23PM +0100, Greg KH wrote:
> On Mon, Nov 14, 2016 at 02:32:35PM +0200, Heikki Krogerus wrote:
> > > > +static void __exit typec_exit(void)
> > > > +{
> > > > + class_unregister(&typec_class);
> > >
> > > You forgot to clean up your idr :(
> >
> > Sorry, what idr? The port ids get removed in typec_release().
>
> You have a static idr structure in the driver, right? You have to clean
> it up when your code is going away so that it will free any memory it
> had allocated with a call to idr_destroy() on module exit.
Ok.
Regarding the DEVICE_ATTR* macros. So I have attributes with same
names for different device types. I may be able to identify the device
types and deal with the correct attribute based on that, but for
example the attribute "active" with alternate modes is writable, but
with cables it's not. How do I handle those?
Thanks,
--
heikki
^ permalink raw reply
* bcache by-label / by-uuid symlinks missing after upgrade from debian wheezy to jessie
From: Stefan Priebe - Profihost AG @ 2016-11-14 14:33 UTC (permalink / raw)
To: linux-bcache@vger.kernel.org; +Cc: Eric Wheeler
Hello,
after upgrading from debian wheezy to jessie i no longer have the
/dev/bcache/by-uuid | by-label entries on my system.
I already google'd around but didn't find a solution.
# ls -la /dev/bcache*
brw-rw---- 1 root disk 254, 0 Nov 14 15:25 /dev/bcache0
brw-rw---- 1 root disk 254, 1 Nov 14 15:10 /dev/bcache1
brw-rw---- 1 root disk 254, 2 Nov 14 15:10 /dev/bcache2
brw-rw---- 1 root disk 254, 3 Nov 14 15:10 /dev/bcache3
# cat /lib/udev/rules.d/69-bcache.rules
# register bcache devices as they come up
# man 7 udev for syntax
SUBSYSTEM!="block", GOTO="bcache_end"
ACTION=="remove", GOTO="bcache_end"
ENV{DM_UDEV_DISABLE_OTHER_RULES_FLAG}=="1", GOTO="bcache_end"
KERNEL=="fd*|sr*", GOTO="bcache_end"
# blkid was run by the standard udev rules
# It recognised bcache (util-linux 2.24+)
ENV{ID_FS_TYPE}=="bcache", GOTO="bcache_backing_found"
# It recognised something else; bail
ENV{ID_FS_TYPE}=="?*", GOTO="bcache_backing_end"
# Backing devices: scan, symlink, register
IMPORT{program}="probe-bcache -o udev $tempnode"
ENV{ID_FS_TYPE}!="bcache", GOTO="bcache_backing_end"
ENV{ID_FS_UUID_ENC}=="?*", SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}"
LABEL="bcache_backing_found"
RUN{builtin}+="kmod load bcache"
RUN+="bcache-register $tempnode"
LABEL="bcache_backing_end"
# Cached devices: symlink
DRIVER=="bcache", ENV{CACHED_UUID}=="?*", \
SYMLINK+="bcache/by-uuid/$env{CACHED_UUID}"
DRIVER=="bcache", ENV{CACHED_LABEL}=="?*", \
SYMLINK+="bcache/by-label/$env{CACHED_LABEL}"
LABEL="bcache_end"
I've no idea why those symlinks are not created but i'm also not a udev
expert.
Has anybody seen this before?
Greets,
Stefan
^ permalink raw reply
* Re: [PATCH v2 00/10] wic: bugfixes & --fixed-size support, tests, selftest: minor fixes
From: Maciej Borzęcki @ 2016-11-14 14:37 UTC (permalink / raw)
To: Burton, Ross; +Cc: Paul Eggleton, Maciej Borzecki, OE-core
In-Reply-To: <CAJTo0Lby4RLXxxe8cG_Kr8Uq-srb8nv2tZCTCuQxBYD8hY5YyA@mail.gmail.com>
On Mon, Nov 14, 2016 at 3:07 PM, Burton, Ross <ross.burton@intel.com> wrote:
>
> 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.
I suppose that settles it then. I will stick with HOST_ARCH in v3 of the series.
--
Maciej Borzecki
RnDity
^ permalink raw reply
* [PATCH 01/16] ARM: scu: Provide support for parsing SCU device node to enable SCU
From: Arnd Bergmann @ 2016-11-14 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114135018.GL1041@n2100.armlinux.org.uk>
On Monday, November 14, 2016 1:50:18 PM CET Russell King - ARM Linux wrote:
> On Mon, Nov 14, 2016 at 01:03:09PM +0100, Arnd Bergmann wrote:
> > On Monday, November 14, 2016 2:10:16 PM CET pankaj.dubey wrote:
> > > >> + scu_base = of_iomap(np, 0);
> > > >> + of_node_put(np);
> > > >> + if (!scu_base) {
> > > >> + pr_err("%s failed to map scu_base via DT\n", __func__);
> > > >
> > > > For non-ca5, non-ca9 based SoCs, we'll see this error msg. We understand
> > > > what does it mean, but it may confuse normal users. In current version,
> > > > berlin doesn't complain like this for non-ca9 SoCs
> > > >
> > >
> > > OK, let me see other reviewer's comment on this. Then we will decide if
> > > this error message is required or can be omitted.
> >
> > We need to look at all callers here, to see if the function ever gets
> > called for a CPU that doesn't have an SCU. I'd say we should warn if
> > we know there is an SCU but we cannot map it, but never warn on
> > any of the CPU cores that don't support an SCU.
>
> Maybe there should be two helpers:
>
> of_scu_enable() which _only_ looks up the SCU address in DT and enables
> it if it finds it, otherwise returning failure.
>
> a9_scu_enable() which tries to use the A9 provided SCU address and
> enables it if it finds it, otherwise returning failure.
>
> Then callers can decide which of these to call, and what error messages
> to print on their failures.
Splitting the function in two is probably simpler overall, but
we may still have to look at all the callers: Any platform that
currently tries to map it on any CPU and doesn't warn about the
absence of the device node (or about scu_a9_has_base() == false)
should really continue not to warn about that.
If all platforms only call these on SMP machines with an
ARM11MPcore, Cortex-A5 or Cortex-A9, everything should be
fine here, otherwise we can leave the warning in the caller
after checking the return code of the new APIs.
Arnd
^ permalink raw reply
* Re: [PATCH 1/3] tools build: Add CFLAGS_REMOVE_* support
From: Arnaldo Carvalho de Melo @ 2016-11-14 14:37 UTC (permalink / raw)
To: Jiri Olsa
Cc: lkml, Ingo Molnar, Peter Zijlstra, Andi Kleen, William Cohen,
Stephane Eranian, Namhyung Kim, David Ahern
In-Reply-To: <20161114143614.GE27058@kernel.org>
Em Mon, Nov 14, 2016 at 11:36:14AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, Nov 02, 2016 at 02:35:47PM +0100, Jiri Olsa escreveu:
> > Adding support to remove options from final CFLAGS
> > for both object file and build target. It's now
> > possible to remove CFLAGS options like:
> >
> > CFLAGS_REMOVE_krava.o += -Wstrict-prototypes
>
> That is cool, and I just looked and this comes from the kernel sources,
> is there some place where the subset of such features that is supported
> in tools/build is being documented?
>
> Applying it, thanks.
Duh, yeah:
tools/build/Documentation/Build.txt
Nevermind, I'll add a note to the cset log.
- Arnaldo
> - Arnaldo
>
> > Link: http://lkml.kernel.org/n/tip-0t59dihg30fh035xo69df3m8@git.kernel.org
> > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > ---
> > tools/build/Build.include | 4 +++-
> > tools/build/Documentation/Build.txt | 6 ++++--
> > 2 files changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/tools/build/Build.include b/tools/build/Build.include
> > index 1dcb95e76f70..c4ae12a5d0a5 100644
> > --- a/tools/build/Build.include
> > +++ b/tools/build/Build.include
> > @@ -89,7 +89,9 @@ if_changed = $(if $(strip $(any-prereq) $(arg-check)), \
> > # - per target C flags
> > # - per object C flags
> > # - BUILD_STR macro to allow '-D"$(variable)"' constructs
> > -c_flags = -Wp,-MD,$(depfile),-MT,$@ $(CFLAGS) -D"BUILD_STR(s)=\#s" $(CFLAGS_$(basetarget).o) $(CFLAGS_$(obj))
> > +c_flags_1 = -Wp,-MD,$(depfile),-MT,$@ $(CFLAGS) -D"BUILD_STR(s)=\#s" $(CFLAGS_$(basetarget).o) $(CFLAGS_$(obj))
> > +c_flags_2 = $(filter-out $(CFLAGS_REMOVE_$(basetarget).o), $(c_flags_1))
> > +c_flags = $(filter-out $(CFLAGS_REMOVE_$(obj)), $(c_flags_2))
> > cxx_flags = -Wp,-MD,$(depfile),-MT,$@ $(CXXFLAGS) -D"BUILD_STR(s)=\#s" $(CXXFLAGS_$(basetarget).o) $(CXXFLAGS_$(obj))
> >
> > ###
> > diff --git a/tools/build/Documentation/Build.txt b/tools/build/Documentation/Build.txt
> > index a47bffbae159..a22587475dbe 100644
> > --- a/tools/build/Documentation/Build.txt
> > +++ b/tools/build/Documentation/Build.txt
> > @@ -135,8 +135,10 @@ CFLAGS
> >
> > It's possible to alter the standard object C flags in the following way:
> >
> > - CFLAGS_perf.o += '...' - alters CFLAGS for perf.o object
> > - CFLAGS_gtk += '...' - alters CFLAGS for gtk build object
> > + CFLAGS_perf.o += '...' - adds CFLAGS for perf.o object
> > + CFLAGS_gtk += '...' - adds CFLAGS for gtk build object
> > + CFLAGS_REMOVE_perf.o += '...' - removes CFLAGS for perf.o object
> > + CFLAGS_REMOVE_gtk += '...' - removes CFLAGS for gtk build object
> >
> > This C flags changes has the scope of the Build makefile they are defined in.
> >
> > --
> > 2.7.4
^ permalink raw reply
* Re: [PATCH 1/3] tools build: Add CFLAGS_REMOVE_* support
From: Arnaldo Carvalho de Melo @ 2016-11-14 14:36 UTC (permalink / raw)
To: Jiri Olsa
Cc: lkml, Ingo Molnar, Peter Zijlstra, Andi Kleen, William Cohen,
Stephane Eranian, Namhyung Kim, David Ahern
In-Reply-To: <1478093749-5602-2-git-send-email-jolsa@kernel.org>
Em Wed, Nov 02, 2016 at 02:35:47PM +0100, Jiri Olsa escreveu:
> Adding support to remove options from final CFLAGS
> for both object file and build target. It's now
> possible to remove CFLAGS options like:
>
> CFLAGS_REMOVE_krava.o += -Wstrict-prototypes
That is cool, and I just looked and this comes from the kernel sources,
is there some place where the subset of such features that is supported
in tools/build is being documented?
Applying it, thanks.
- Arnaldo
> Link: http://lkml.kernel.org/n/tip-0t59dihg30fh035xo69df3m8@git.kernel.org
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> ---
> tools/build/Build.include | 4 +++-
> tools/build/Documentation/Build.txt | 6 ++++--
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/tools/build/Build.include b/tools/build/Build.include
> index 1dcb95e76f70..c4ae12a5d0a5 100644
> --- a/tools/build/Build.include
> +++ b/tools/build/Build.include
> @@ -89,7 +89,9 @@ if_changed = $(if $(strip $(any-prereq) $(arg-check)), \
> # - per target C flags
> # - per object C flags
> # - BUILD_STR macro to allow '-D"$(variable)"' constructs
> -c_flags = -Wp,-MD,$(depfile),-MT,$@ $(CFLAGS) -D"BUILD_STR(s)=\#s" $(CFLAGS_$(basetarget).o) $(CFLAGS_$(obj))
> +c_flags_1 = -Wp,-MD,$(depfile),-MT,$@ $(CFLAGS) -D"BUILD_STR(s)=\#s" $(CFLAGS_$(basetarget).o) $(CFLAGS_$(obj))
> +c_flags_2 = $(filter-out $(CFLAGS_REMOVE_$(basetarget).o), $(c_flags_1))
> +c_flags = $(filter-out $(CFLAGS_REMOVE_$(obj)), $(c_flags_2))
> cxx_flags = -Wp,-MD,$(depfile),-MT,$@ $(CXXFLAGS) -D"BUILD_STR(s)=\#s" $(CXXFLAGS_$(basetarget).o) $(CXXFLAGS_$(obj))
>
> ###
> diff --git a/tools/build/Documentation/Build.txt b/tools/build/Documentation/Build.txt
> index a47bffbae159..a22587475dbe 100644
> --- a/tools/build/Documentation/Build.txt
> +++ b/tools/build/Documentation/Build.txt
> @@ -135,8 +135,10 @@ CFLAGS
>
> It's possible to alter the standard object C flags in the following way:
>
> - CFLAGS_perf.o += '...' - alters CFLAGS for perf.o object
> - CFLAGS_gtk += '...' - alters CFLAGS for gtk build object
> + CFLAGS_perf.o += '...' - adds CFLAGS for perf.o object
> + CFLAGS_gtk += '...' - adds CFLAGS for gtk build object
> + CFLAGS_REMOVE_perf.o += '...' - removes CFLAGS for perf.o object
> + CFLAGS_REMOVE_gtk += '...' - removes CFLAGS for gtk build object
>
> This C flags changes has the scope of the Build makefile they are defined in.
>
> --
> 2.7.4
^ permalink raw reply
* Re: [x86/copy_user] adb402cd14: will-it-scale.per_process_ops -12.7% regression
From: Ye Xiaolong @ 2016-11-14 14:37 UTC (permalink / raw)
To: lkp
In-Reply-To: <20161107095631.truqvpqong3ixwp3@pd.tnic>
[-- Attachment #1: Type: text/plain, Size: 2580 bytes --]
On 11/07, Borislav Petkov wrote:
>On Mon, Nov 07, 2016 at 10:50:38AM +0800, kernel test robot wrote:
>> To reproduce:
>>
>> git clone git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
>> cd lkp-tests
>> bin/lkp install job.yaml # job file is attached in this email
>
>./bin/lkp install job.yaml
>Use: /root/lkp/lkp-tests/distro/installer/debian install bc gawk time kmod gzip make automake gcc build-essential libtool patch git openssl ca-certificates rsync cpio wget libklibc-dev linux-libc-dev linux-libc-dev:i386 libc6-dev libc6-dev:i386
>Reading package lists... Done
>Building dependency tree
>Reading state information... Done
>E: Unable to locate package linux-libc-dev
>E: Unable to locate package libc6-dev
>Cannot install some packages in /root/lkp/lkp-tests/distro/depends/lkp
>
>This wants i386 flavors and can't find them for some reason...
>
Below cmd should help on it:
dpkg --add-architecture i386 && apt-get update
>> bin/lkp run job.yaml
>
>With your scripts I get:
>
>$ ./bin/lkp run job.yaml
>/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- git (LoadError)
> from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
> from /root/lkp/lkp-tests/lib/git_ext.rb:7:in `<top (required)>'
> from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
> from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
> from /root/lkp/lkp-tests/lib/lkp_git.rb:14:in `<top (required)>'
> from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
> from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
> from /root/lkp/lkp-tests/lib/stats.rb:9:in `<top (required)>'
> from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
> from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
> from /root/lkp/lkp-tests/bin/run-local:15:in `<main>'
>
>and that line is:
>
>require 'git'
>
It requires to install ruby-git package, try
sudo apt-get install ruby-git
Thanks,
Xiaolong
>but I already have ruby git bindings installed.
>
>So how can I run the benchmark directly, without the ruby glue? I
>already have a debian partition on this SNB box so I can run it
>natively.
>
>Thanks.
>
>--
>Regards/Gruss,
> Boris.
>
>Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* Re: Correct way to build patched kernel modules
From: Bruce Ashfield @ 2016-11-14 14:36 UTC (permalink / raw)
To: mert.ergun, yocto
In-Reply-To: <8a556f5733a5ed58345b4d907f7b5cbb.squirrel@mail.mikro-tasarim.com.tr>
On 2016-11-14 10:01 AM, Mert Can Ergun wrote:
> Hi!
>
> I am currently using a kernel bbappend file to build my kernel and kernel
> modules. My bbappend file looks like this:
>
> linux-imx_%.bbappend
> SUMMARY = "Patches applied to Freescale kernel"
> DESCRIPTION = "blank"
>
> FILESPATH_prepend := "${THISDIR}/patches:"
>
> SRC_URI += " \
> file://defconfig-mt \
> **patches for kernel modules appear here**
> "
>
> do_configure_prepend() {
> cp ${WORKDIR}/defconfig-mt ${WORKDIR}/defconfig
> }
>
> However, this approach doesn't feel right and I want to seperate kernel
> and its modules from each other at build.
If the kernel modules that you are patching and building are in-tree,
there's no problem with the architecture of what you have above. The
build process for in-tree modules is integrated with the main kernel
build.
>
> What I tried to do is remove patches from the bbappend file and keep
> defconfig file intact. Create a new bb file and put patches inside there
> instead. So new architecture looks like this:
>
> linux-imx_%.bbappend
> SUMMARY = "Patches applied to Freescale kernel"
> DESCRIPTION = "MT6415CA"
>
> FILESPATH_prepend := "${THISDIR}/patches:"
>
> SRC_URI += " \
> file://defconfig-mt \
> "
>
> do_configure_prepend() {
> cp ${WORKDIR}/defconfig-mt ${WORKDIR}/defconfig
> }
>
> mt-module_0.1.bb
> SUMMARY = "Patches applied to Freescale kernel"
> DESCRIPTION = "blank"
> LICENSE = "GPLv2"
>
> inherit module
>
> FILESPATH_prepend := "${THISDIR}/patches:"
>
> SRC_URI += " \
> **patches appear here**
> "
>
> Now my kernel append module doesn't even apply defconfig changes and new
> bb file doesn't do anything either. What's the right way to do this?
If you are patching the kernel source with this recipe, it needs to
match the name of your kernel recipe.
Bruce
>
> -------------------------------
> Mert Can Ergun
> Yazilim Gelistirme Muhendisi
>
> Mikro-Tasarim Ltd.
> ODTU-Teknokent ODTU-MET Alani
> A-1 Blok 4. Bolum Ofis 3/A
> TR-06530 Ankara
> T: +90 312 286 0103
> F: +90 312 286 0104
> U: www.mikro-tasarim.com.tr
> E: mert.ergun@mikro-tasarim.com.tr
> -------------------------------
>
^ permalink raw reply
* RE: [PATCH] NTB: Register and offset values fix for memory window
From: Allen Hubbe @ 2016-11-14 14:35 UTC (permalink / raw)
To: 'Shyam Sundar S K', 'Yu, Xiangliang', jdmason
Cc: dave.jiang, linux-ntb, 'Sen, Pankaj',
'Shah, Nehal-bakulchandra',
'Agrawal, Nitesh-kumar', 'Subramaniyan, Ramkumar',
Richard1.Su
In-Reply-To: <c44465a3-780b-3dbd-22dc-4be241009e3c@amd.com>
From: Shyam Sundar S K
> Due to incorrect limit and translation register values, NTB link was
> going down when the memory window translation was setup. Made appropriate
> changes as per spec.
>
> Also, fixed the limit register values for BAR1, which was overlapping
> with the BAR23 address.
>
> Reviewed-by: Sen, Pankaj <Pankaj.Sen@amd.com>
> Reviewed-by: Shah, Nehal-bakulchandra <Nehal-bakulchandra.Shah@amd.com>
> Acked-by: Xiangliang Yu <Xiangliang.Yu@amd.com>
> Signed-off-by: S-k, Shyam-sundar <Shyam-sundar.S-k@amd.com>
> ---
> @@ -376,13 +371,11 @@ static u32 amd_ntb_spad_read(struct ntb_dev *ntb, int idx)
> {
> struct amd_ntb_dev *ndev = ntb_ndev(ntb);
> void __iomem *mmio = ndev->self_mmio;
> - u32 offset;
>
> - if (idx < 0 || idx >= ndev->spad_count)
> + if (idx < 0 || idx >= (ndev->spad_count + 4))
Why does this change add four to the upper end of the range check? Does spad_count have the wrong number of spads?
> return 0;
>
> - offset = ndev->self_spad + (idx << 2);
> - return readl(mmio + AMD_SPAD_OFFSET + offset);
> + return readl(mmio + AMD_SPAD_OFFSET + (idx << 2));
The self_spad is used for sharing the spads of a single ntb. It is the offset of the first or second half of the spads, and the peer self_spad is the other half. From this change, can we assume that a single-ntb topology will not be supported?
^ permalink raw reply
* Re: [PATCH net-next v5] cadence: Add LSO support.
From: Eric Dumazet @ 2016-11-14 14:35 UTC (permalink / raw)
To: Rafal Ozieblo
Cc: David Miller, nicolas.ferre@atmel.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <BN3PR07MB2516C30913D2FB8D4788071AC9BC0@BN3PR07MB2516.namprd07.prod.outlook.com>
On Mon, 2016-11-14 at 09:32 +0000, Rafal Ozieblo wrote:
> From: David Miller [mailto:davem@davemloft.net]
> Sent: 10 listopada 2016 18:01
> To: Rafal Ozieblo
> Cc: nicolas.ferre@atmel.com; netdev@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net-next v5]] cadence: Add LSO support.
>
> From: Rafal Ozieblo <rafalo@cadence.com>
> Date: Wed, 9 Nov 2016 13:41:02 +0000
>
> > First, please remove the spurious closing bracket in your Subject line in future submittions.
> >
> >> + if (is_udp) /* is_udp is only set when (is_lso) is checked */
> >> + /* zero UDP checksum, not calculated by h/w for UFO */
> >> + udp_hdr(skb)->check = 0;
> >
> > This is really not ok.
> >
> > If UFO is in use it should not silently disable UDP checksums.
> >
> > If you cannot support UFO with proper checksumming, then you cannot enable support for that feature.
>
> According Cadence Gigabit Ethernet MAC documentation:
>
> "Hardware will not calculate the UDP checksum or modify the UDP checksum field. Therefore software
> must set a value of zero in the checksum field in the UDP header (in the first payload buffer)
> to indicate to the receiver that the UDP datagram does not include a checksum."
>
> It is hardware requirement.
Then do not claim NETIF_F_UFO suport in the driver, if hardware is
absolutely not capable of handling this.
Linux stack will provide proper udp checksum.
Almost no driver sets NETIF_F_UFO.
^ permalink raw reply
* RE: [PATCH] ARCv2: MCIP: Deprecate setting of affinity in Device Tree
From: Yuriy Kolerov @ 2016-11-14 14:35 UTC (permalink / raw)
To: Marc Zyngier, Yuriy Kolerov, linux-snps-arc@lists.infradead.org
Cc: Vineet.Gupta1@synopsys.com, Alexey.Brodkin@synopsys.com,
tglx@linutronix.de, linux-kernel@vger.kernel.org
In-Reply-To: <d5cb9467-a6d7-e47d-7b25-15396c4d65cb@arm.com>
Hi Marc,
> -----Original Message-----
> From: Marc Zyngier [mailto:marc.zyngier@arm.com]
> Sent: Friday, November 11, 2016 6:29 PM
> To: Yuriy Kolerov <yuriy.kolerov@synopsys.com>; linux-snps-
> arc@lists.infradead.org
> Cc: Vineet.Gupta1@synopsys.com; Alexey.Brodkin@synopsys.com;
> tglx@linutronix.de; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] ARCv2: MCIP: Deprecate setting of affinity in Device
> Tree
>
> Hi Yuriy,
>
> On 11/11/16 14:38, Yuriy Kolerov wrote:
> > Ignore value of interrupt distribution mode for common interrupts in
> > IDU since setting of affinity using value from Device Tree is
> > deprecated in ARC. Originally it is done in idu_irq_xlate() function
> > and it is semantically wrong and does not guaranty that an affinity
> > value will be set properly.
> >
> > However it is necessary to set a default affinity value manually for
> > all common interrupts since initially all of them are disabled by IDU
> > (a CPU mask for common interrupts is set to 0 after CPU reset) and in
> > some cases the kernel cannot do it itself after initialization of
> > endpoint devices (e.g. when IRQ chip below of IDU does not support
> > setting of affinity and it cannot propagate an affinity value to IDU).
> >
> > By default send all common interrupts to the first online CPU.
> > Usually it is a boot CPU. If the kernel is built without support of
> > SMP then idu_irq_set_affinity() must be called manually since
> > irq_set_affinity() does nothing in this case.
> >
> > Signed-off-by: Yuriy Kolerov <yuriy.kolerov@synopsys.com>
> > ---
> > .../interrupt-controller/snps,archs-idu-intc.txt | 3 ++
> > arch/arc/kernel/mcip.c | 51 +++++++++-------------
> > 2 files changed, 24 insertions(+), 30 deletions(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/interrupt-controller/snps,archs-id
> > u-intc.txt
> > b/Documentation/devicetree/bindings/interrupt-controller/snps,archs-id
> > u-intc.txt
> > index 0dcb7c7..0607bab 100644
> > ---
> > a/Documentation/devicetree/bindings/interrupt-controller/snps,archs-id
> > u-intc.txt
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/snps,arch
> > +++ s-idu-intc.txt
> > @@ -15,6 +15,9 @@ Properties:
> > Second cell specifies the irq distribution mode to cores
> > 0=Round Robin; 1=cpu0, 2=cpu1, 4=cpu2, 8=cpu3
> >
> > + The second cell in interrupts property is deprecated and ignored.
> > + All common interrupts are sent to the boot CPU core by default.
> > +
>
> <pedantic hat on>
> This comment only affects the behaviour of the driver, and not the
> hardware. I'd rather see something along the lines of:
>
> "The second cell is only a hint, and an operating system is free to ignore it."
>
> > intc accessed via the special ARC AUX register interface, hence "reg"
> property
> > is not specified.
> >
> > diff --git a/arch/arc/kernel/mcip.c b/arch/arc/kernel/mcip.c index
> > 6d90e4b..f36b8d7 100644
> > --- a/arch/arc/kernel/mcip.c
> > +++ b/arch/arc/kernel/mcip.c
> > @@ -174,7 +174,6 @@ static void idu_irq_unmask(struct irq_data *data)
> > raw_spin_unlock_irqrestore(&mcip_lock, flags); }
> >
> > -#ifdef CONFIG_SMP
> > static int
> > idu_irq_set_affinity(struct irq_data *data, const struct cpumask
> *cpumask,
> > bool force)
> > @@ -204,7 +203,6 @@ idu_irq_set_affinity(struct irq_data *data, const
> > struct cpumask *cpumask,
> >
> > return IRQ_SET_MASK_OK;
> > }
> > -#endif
> >
> > static struct irq_chip idu_irq_chip = {
> > .name = "MCIP IDU Intc",
> > @@ -228,9 +226,24 @@ static void idu_cascade_isr(struct irq_desc
> > *desc)
> >
> > static int idu_irq_map(struct irq_domain *d, unsigned int virq,
> > irq_hw_number_t hwirq) {
> > + cpumask_t affinity;
> > +
> > irq_set_chip_and_handler(virq, &idu_irq_chip, handle_level_irq);
> > irq_set_status_flags(virq, IRQ_MOVE_PCNTXT);
> >
> > + /* By default send all common interrupts to the first online CPU.
> > + * Usually it is a boot CPU. If the kernel is built without support
> > + * of SMP then idu_irq_set_affinity() must be called manually since
> > + * irq_set_affinity() does nothing in this case.
> > + */
> > + cpumask_copy(&affinity,
> cpumask_of(cpumask_first(cpu_online_mask)));
> > +
> > +#ifdef CONFIG_SMP
> > + irq_set_affinity(virq, &affinity);
>
> Ghhhaaaaahhhh. Please don't do that. You are now re-entering the IRQ
> framework, and there is no guarantee that this is safe (what locks are being
> held???). At that stage, you don't even know if the irq_desc exists yet. And
> since you're not testing the return value, you can't even know if that worked.
However functions like irq_set_chip_and_handler() and irq_set_status_flags() which are used above set a lock on irq_desc and seems like this structure must exists on this stage. And irq_set_affinity() has the same behavior - it locks irq_desc and modifies it. I know that no one calls irq_set_affinity() in such situations (I mean in irq_map() function) but:
1. The default affinity on ARC is always 0xf. I don't know why... By the way that's why we always check an affinity value in idu_irq_set_affinity():
if (!cpumask_and(&online, cpumask, cpu_online_mask)) return -EINVAL;
And by default affinity will never be set to just boot core. Moreover I am not sure that an affinity value in irq_desc will always match a real affinity of common interrupts. May be this is the root problem?
2. The kernel will not call idu_irq_set_affinity() for IDU interrupt controller in some cases. It happens when the top interrupt controller does not support setting of the affinity and does not even support propagating of it (e.g. a GPIO interrupt controller on top of IDU which funnels all interrupts in one line). However idu_irq_set_affinity() must be called to unmask common interrupts in IDU. And if I want to make an affinity in irq_desc to match a real affinity I must call irq_set_affinity() instead of just idu_irq_set_affinity() .
> In general, you don't even need this, because the kernel will set the affinity
> to the first CPU (see the setup_affinity call from __setup_irq).
>
> > +#else
> > + idu_irq_set_affinity(irq_get_irq_data(virq), &affinity, false);
> > +#endif
> > +
>
> This should be the only course of action.
>
> > return 0;
> > }
> >
> > @@ -238,36 +251,14 @@ static int idu_irq_xlate(struct irq_domain *d,
> struct device_node *n,
> > const u32 *intspec, unsigned int intsize,
> > irq_hw_number_t *out_hwirq, unsigned int
> *out_type) {
> > - irq_hw_number_t hwirq = *out_hwirq = intspec[0];
> > - int distri = intspec[1];
> > - unsigned long flags;
> > -
> > + /*
> > + * Ignore value of interrupt distribution mode for common interrupts
> in
> > + * IDU which resides in intspec[1] since setting an affinity using value
> > + * from Device Tree is deprecated in ARC.
> > + */
> > + *out_hwirq = intspec[0];
> > *out_type = IRQ_TYPE_NONE;
> >
> > - /* XXX: validate distribution scheme again online cpu mask */
> > - if (distri == 0) {
> > - /* 0 - Round Robin to all cpus, otherwise 1 bit per core */
> > - raw_spin_lock_irqsave(&mcip_lock, flags);
> > - idu_set_dest(hwirq, BIT(num_online_cpus()) - 1);
> > - idu_set_mode(hwirq, IDU_M_TRIG_LEVEL,
> IDU_M_DISTRI_RR);
> > - raw_spin_unlock_irqrestore(&mcip_lock, flags);
> > - } else {
> > - /*
> > - * DEST based distribution for Level Triggered intr can only
> > - * have 1 CPU, so generalize it to always contain 1 cpu
> > - */
> > - int cpu = ffs(distri);
> > -
> > - if (cpu != fls(distri))
> > - pr_warn("IDU irq %lx distri mode set to cpu %x\n",
> > - hwirq, cpu);
> > -
> > - raw_spin_lock_irqsave(&mcip_lock, flags);
> > - idu_set_dest(hwirq, cpu);
> > - idu_set_mode(hwirq, IDU_M_TRIG_LEVEL,
> IDU_M_DISTRI_DEST);
> > - raw_spin_unlock_irqrestore(&mcip_lock, flags);
> > - }
> > -
> > return 0;
> > }
> >
> >
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] ARCv2: MCIP: Deprecate setting of affinity in Device Tree
From: Yuriy Kolerov @ 2016-11-14 14:35 UTC (permalink / raw)
To: linux-snps-arc
In-Reply-To: <d5cb9467-a6d7-e47d-7b25-15396c4d65cb@arm.com>
Hi Marc,
> -----Original Message-----
> From: Marc Zyngier [mailto:marc.zyngier at arm.com]
> Sent: Friday, November 11, 2016 6:29 PM
> To: Yuriy Kolerov <yuriy.kolerov at synopsys.com>; linux-snps-
> arc at lists.infradead.org
> Cc: Vineet.Gupta1 at synopsys.com; Alexey.Brodkin at synopsys.com;
> tglx at linutronix.de; linux-kernel at vger.kernel.org
> Subject: Re: [PATCH] ARCv2: MCIP: Deprecate setting of affinity in Device
> Tree
>
> Hi Yuriy,
>
> On 11/11/16 14:38, Yuriy Kolerov wrote:
> > Ignore value of interrupt distribution mode for common interrupts in
> > IDU since setting of affinity using value from Device Tree is
> > deprecated in ARC. Originally it is done in idu_irq_xlate() function
> > and it is semantically wrong and does not guaranty that an affinity
> > value will be set properly.
> >
> > However it is necessary to set a default affinity value manually for
> > all common interrupts since initially all of them are disabled by IDU
> > (a CPU mask for common interrupts is set to 0 after CPU reset) and in
> > some cases the kernel cannot do it itself after initialization of
> > endpoint devices (e.g. when IRQ chip below of IDU does not support
> > setting of affinity and it cannot propagate an affinity value to IDU).
> >
> > By default send all common interrupts to the first online CPU.
> > Usually it is a boot CPU. If the kernel is built without support of
> > SMP then idu_irq_set_affinity() must be called manually since
> > irq_set_affinity() does nothing in this case.
> >
> > Signed-off-by: Yuriy Kolerov <yuriy.kolerov at synopsys.com>
> > ---
> > .../interrupt-controller/snps,archs-idu-intc.txt | 3 ++
> > arch/arc/kernel/mcip.c | 51 +++++++++-------------
> > 2 files changed, 24 insertions(+), 30 deletions(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/interrupt-controller/snps,archs-id
> > u-intc.txt
> > b/Documentation/devicetree/bindings/interrupt-controller/snps,archs-id
> > u-intc.txt
> > index 0dcb7c7..0607bab 100644
> > ---
> > a/Documentation/devicetree/bindings/interrupt-controller/snps,archs-id
> > u-intc.txt
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/snps,arch
> > +++ s-idu-intc.txt
> > @@ -15,6 +15,9 @@ Properties:
> > Second cell specifies the irq distribution mode to cores
> > 0=Round Robin; 1=cpu0, 2=cpu1, 4=cpu2, 8=cpu3
> >
> > + The second cell in interrupts property is deprecated and ignored.
> > + All common interrupts are sent to the boot CPU core by default.
> > +
>
> <pedantic hat on>
> This comment only affects the behaviour of the driver, and not the
> hardware. I'd rather see something along the lines of:
>
> "The second cell is only a hint, and an operating system is free to ignore it."
>
> > intc accessed via the special ARC AUX register interface, hence "reg"
> property
> > is not specified.
> >
> > diff --git a/arch/arc/kernel/mcip.c b/arch/arc/kernel/mcip.c index
> > 6d90e4b..f36b8d7 100644
> > --- a/arch/arc/kernel/mcip.c
> > +++ b/arch/arc/kernel/mcip.c
> > @@ -174,7 +174,6 @@ static void idu_irq_unmask(struct irq_data *data)
> > raw_spin_unlock_irqrestore(&mcip_lock, flags); }
> >
> > -#ifdef CONFIG_SMP
> > static int
> > idu_irq_set_affinity(struct irq_data *data, const struct cpumask
> *cpumask,
> > bool force)
> > @@ -204,7 +203,6 @@ idu_irq_set_affinity(struct irq_data *data, const
> > struct cpumask *cpumask,
> >
> > return IRQ_SET_MASK_OK;
> > }
> > -#endif
> >
> > static struct irq_chip idu_irq_chip = {
> > .name = "MCIP IDU Intc",
> > @@ -228,9 +226,24 @@ static void idu_cascade_isr(struct irq_desc
> > *desc)
> >
> > static int idu_irq_map(struct irq_domain *d, unsigned int virq,
> > irq_hw_number_t hwirq) {
> > + cpumask_t affinity;
> > +
> > irq_set_chip_and_handler(virq, &idu_irq_chip, handle_level_irq);
> > irq_set_status_flags(virq, IRQ_MOVE_PCNTXT);
> >
> > + /* By default send all common interrupts to the first online CPU.
> > + * Usually it is a boot CPU. If the kernel is built without support
> > + * of SMP then idu_irq_set_affinity() must be called manually since
> > + * irq_set_affinity() does nothing in this case.
> > + */
> > + cpumask_copy(&affinity,
> cpumask_of(cpumask_first(cpu_online_mask)));
> > +
> > +#ifdef CONFIG_SMP
> > + irq_set_affinity(virq, &affinity);
>
> Ghhhaaaaahhhh. Please don't do that. You are now re-entering the IRQ
> framework, and there is no guarantee that this is safe (what locks are being
> held???). At that stage, you don't even know if the irq_desc exists yet. And
> since you're not testing the return value, you can't even know if that worked.
However functions like irq_set_chip_and_handler() and irq_set_status_flags() which are used above set a lock on irq_desc and seems like this structure must exists on this stage. And irq_set_affinity() has the same behavior - it locks irq_desc and modifies it. I know that no one calls irq_set_affinity() in such situations (I mean in irq_map() function) but:
1. The default affinity on ARC is always 0xf. I don't know why... By the way that's why we always check an affinity value in idu_irq_set_affinity():
if (!cpumask_and(&online, cpumask, cpu_online_mask)) return -EINVAL;
And by default affinity will never be set to just boot core. Moreover I am not sure that an affinity value in irq_desc will always match a real affinity of common interrupts. May be this is the root problem?
2. The kernel will not call idu_irq_set_affinity() for IDU interrupt controller in some cases. It happens when the top interrupt controller does not support setting of the affinity and does not even support propagating of it (e.g. a GPIO interrupt controller on top of IDU which funnels all interrupts in one line). However idu_irq_set_affinity() must be called to unmask common interrupts in IDU. And if I want to make an affinity in irq_desc to match a real affinity I must call irq_set_affinity() instead of just idu_irq_set_affinity() .
> In general, you don't even need this, because the kernel will set the affinity
> to the first CPU (see the setup_affinity call from __setup_irq).
>
> > +#else
> > + idu_irq_set_affinity(irq_get_irq_data(virq), &affinity, false);
> > +#endif
> > +
>
> This should be the only course of action.
>
> > return 0;
> > }
> >
> > @@ -238,36 +251,14 @@ static int idu_irq_xlate(struct irq_domain *d,
> struct device_node *n,
> > const u32 *intspec, unsigned int intsize,
> > irq_hw_number_t *out_hwirq, unsigned int
> *out_type) {
> > - irq_hw_number_t hwirq = *out_hwirq = intspec[0];
> > - int distri = intspec[1];
> > - unsigned long flags;
> > -
> > + /*
> > + * Ignore value of interrupt distribution mode for common interrupts
> in
> > + * IDU which resides in intspec[1] since setting an affinity using value
> > + * from Device Tree is deprecated in ARC.
> > + */
> > + *out_hwirq = intspec[0];
> > *out_type = IRQ_TYPE_NONE;
> >
> > - /* XXX: validate distribution scheme again online cpu mask */
> > - if (distri == 0) {
> > - /* 0 - Round Robin to all cpus, otherwise 1 bit per core */
> > - raw_spin_lock_irqsave(&mcip_lock, flags);
> > - idu_set_dest(hwirq, BIT(num_online_cpus()) - 1);
> > - idu_set_mode(hwirq, IDU_M_TRIG_LEVEL,
> IDU_M_DISTRI_RR);
> > - raw_spin_unlock_irqrestore(&mcip_lock, flags);
> > - } else {
> > - /*
> > - * DEST based distribution for Level Triggered intr can only
> > - * have 1 CPU, so generalize it to always contain 1 cpu
> > - */
> > - int cpu = ffs(distri);
> > -
> > - if (cpu != fls(distri))
> > - pr_warn("IDU irq %lx distri mode set to cpu %x\n",
> > - hwirq, cpu);
> > -
> > - raw_spin_lock_irqsave(&mcip_lock, flags);
> > - idu_set_dest(hwirq, cpu);
> > - idu_set_mode(hwirq, IDU_M_TRIG_LEVEL,
> IDU_M_DISTRI_DEST);
> > - raw_spin_unlock_irqrestore(&mcip_lock, flags);
> > - }
> > -
> > return 0;
> > }
> >
> >
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH v5 3/3] clocksource: Add clockevent support to NPS400 driver
From: Daniel Lezcano @ 2016-11-14 14:34 UTC (permalink / raw)
To: Noam Camus
Cc: robh+dt@kernel.org, mark.rutland@arm.com, tglx@linutronix.de,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <DB6PR0501MB25183C670A48F44DB916D7FEAABC0@DB6PR0501MB2518.eurprd05.prod.outlook.com>
On Mon, Nov 14, 2016 at 01:58:15PM +0000, Noam Camus wrote:
> > From: Daniel Lezcano [mailto:daniel.lezcano@linaro.org]
> > Sent: Monday, November 14, 2016 1:23 PM
>
>
> >> + */
> >> +static void nps_clkevent_rm_thread(bool remove_thread) {
> >> + unsigned int cflags;
> >> + unsigned int enabled_threads = 0;
> >> + int thread;
> >> +
> >> + hw_schd_save(&cflags);
>
> >I'm not used with hardware scheduling. Can you explain why this is needed
> >here ? What >window race we want to close ?
> We are using HW scheduling off/on in order to keep consistency of auxiliary
> registers shared among HW threads within the same core. Example to such
> registers NPS_REG_TIMER0_TSI and NPS_REG_TIMER0_CTRL. Since update procedure
> of these registers is not atomic we use save/restore macros to turn off/on
> the HW scheduling. This way we insure that no HW scheduling occurs and
> another HW thread (represented as another CPU) will execute in this same
> critical code path. If we take for example nps_clkevent_add_thread() we can
> see that we are doing some read modify write to NPS_REG_TIMER0_TSI and
> optionally writing to NPS_REG_TIMER0_CTRL. This flow should be atomic and is
> protected by our save/restore macros. Do note that interrupts are disabled
> at this point so we are safe from all asynchronous events.
The function nps_clkevent_timer_event_setup() writes into the NPS_REG_TIMER0_CTRL
register but there is no critical section there. What prevents another HW thread
to write this register at the same time ?
I do believe we have a framework to access shared registers, otherwise a simple
spinlock would be simpler and perhaps faster than disabling the entire hardware
scheduling for the system, no ?
> >> +static void nps_clkevent_add_thread(bool set_event) {
> >> + int thread;
> >> + unsigned int cflags, enabled_threads;
> >> +
> >> + hw_schd_save(&cflags);
> >> +
> >> + /* add thread to TSI1 */
> >> + thread = read_aux_reg(CTOP_AUX_THREAD_ID);
> >> + enabled_threads = read_aux_reg(NPS_REG_TIMER0_TSI);
> >> + enabled_threads |= (1 << thread);
> >> + write_aux_reg(NPS_REG_TIMER0_TSI, enabled_threads);
> >> +
> >> + /* set next timer event */
> >> + if (set_event)
> >> + write_aux_reg(NPS_REG_TIMER0_CTRL,
> >> + TIMER0_CTRL_IE | TIMER0_CTRL_NH);
> >> +
> >> + hw_schd_restore(cflags);
> >> +}
>
> >Not sure the boolean parameters for *_rm_thread and *_add_thread helps to
> >clarify the code. Depending on the race window with hw_schd_save/restore We
> >should be able to simplify it.
> I am not sure I am following you here, how race window may simplify this
> code? If those routines will get no parameter I can't determine when to add
> or not (same as remove). ...
Regarding the comment I did above, it is possible the critical section is
reduced and moved into the shutdown function. Thus, the boolean wouldn't be
needed anymore, well that is conditional to the above comment. Discard the
comment for the moment, until the hw sched vs spinlock vs NPS_REG_TIMER0_CTRL
is sorted out.
> >> +static DEFINE_PER_CPU(struct clock_event_device, nps_clockevent_device) = {
> >> + .name = "NPS Timer0",
> >> + .features = CLOCK_EVT_FEAT_ONESHOT |
> >> + CLOCK_EVT_FEAT_PERIODIC,
> >> + .rating = 300,
> >> + .set_next_event = nps_clkevent_set_next_event,
> >> + .set_state_periodic = nps_clkevent_set_periodic,
> >> + .set_state_oneshot = nps_clkevent_set_oneshot,
> >> + .set_state_oneshot_stopped = nps_clkevent_timer_shutdown,
> >> + .set_state_shutdown = nps_clkevent_timer_shutdown,
>
> >Doesn't set_state_shutdown and set_state_oneshot_stopped need to remove the HW thread from the TSI ?
> You are correct, I will fix that.
And tick_resume. Perhaps, that is the reason why NO_HZ hangs.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH] dma: cpp41: Fix handling of error path
From: Johan Hovold @ 2016-11-14 14:34 UTC (permalink / raw)
To: Tony Lindgren
Cc: Dan Williams, Vinod Koul, Bin Liu, Daniel Mack, Felipe Balbi,
George Cherian, Johan Hovold, Peter Ujfalusi,
Sebastian Andrzej Siewior, dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161111192852.25399-1-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On Fri, Nov 11, 2016 at 11:28:52AM -0800, Tony Lindgren wrote:
> If we return early on pm_runtime_get() error, we need to also call
> pm_runtime_put_noidle() as pointed out in a musb related thread
> by Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>. This is to keep the PM runtime
> use counts happy.
>
> Fixes: fdea2d09b997 ("dmaengine: cppi41: Add basic PM runtime support")
> Cc: Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> ---
> drivers/dma/cppi41.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
> @@ -466,6 +472,7 @@ static void cppi41_dma_issue_pending(struct dma_chan *chan)
>
> error = pm_runtime_get(cdd->ddev.dev);
> if ((error != -EINPROGRESS) && error < 0) {
> + pm_runtime_put_noidle(cdd->ddev.dev);
> dev_err(cdd->ddev.dev, "Failed to pm_runtime_get: %i\n",
> error);
Will this chunk not introduce rather than fix an imbalance, though? An
error is never returned above, and the corresponding put is done
unconditionally as far as I can tell.
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATHCv10 1/2] usb: USB Type-C connector class
From: Guenter Roeck @ 2016-11-14 14:34 UTC (permalink / raw)
To: Heikki Krogerus, Greg KH
Cc: Oliver Neukum, Felipe Balbi, Bin Gao, linux-kernel, linux-usb
In-Reply-To: <20161114123235.GD22706@kuha.fi.intel.com>
On 11/14/2016 04:32 AM, Heikki Krogerus wrote:
> Hi Greg,
>
> On Mon, Nov 14, 2016 at 10:51:48AM +0100, Greg KH wrote:
>> On Mon, Sep 19, 2016 at 02:16:56PM +0300, Heikki Krogerus wrote:
>>> The purpose of USB Type-C connector class is to provide
>>> unified interface for the user space to get the status and
>>> basic information about USB Type-C connectors on a system,
>>> control over data role swapping, and when the port supports
>>> USB Power Delivery, also control over power role swapping
>>> and Alternate Modes.
>>>
>>> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
>>> Tested-by: Guenter Roeck <linux@roeck-us.net>
>>> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
[ ... ]
>>> +
>>> +int typec_connect(struct typec_port *port, struct typec_connection *con)
>>> +{
>>> + int ret;
>>> +
>>> + if (!con->partner && !con->cable)
>>> + return -EINVAL;
>>> +
>>> + port->connected = 1;
>>> + port->data_role = con->data_role;
>>> + port->pwr_role = con->pwr_role;
>>> + port->vconn_role = con->vconn_role;
>>> + port->pwr_opmode = con->pwr_opmode;
>>> +
>>> + kobject_uevent(&port->dev.kobj, KOBJ_CHANGE);
>>
>> This worries me. Who is listening for it? What will you do with it?
>> Shouldn't you just poll on an attribute file instead?
>
> Oliver! Did you need this or can we remove it?
>
I'll also have to make sure that the Android folks don't use it.
Guenter
^ permalink raw reply
* [PATCH v2] i2c: mux: fix up dependencies
From: Linus Walleij @ 2016-11-14 14:34 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c
Cc: Linus Walleij, stable, Jonathan Cameron, Peter Rosin
We get the following build error from UM Linux after adding
an entry to drivers/iio/gyro/Kconfig that issues "select I2C_MUX":
ERROR: "devm_ioremap_resource"
[drivers/i2c/muxes/i2c-mux-reg.ko] undefined!
ERROR: "of_address_to_resource"
[drivers/i2c/muxes/i2c-mux-reg.ko] undefined!
It appears that the I2C mux core code depends on HAS_IOMEM
for historical reasons, while CONFIG_I2C_MUX_REG does *not*
have a direct dependency on HAS_IOMEM.
This creates a situation where a allyesconfig or allmodconfig
for UM Linux will select I2C_MUX, and will implicitly enable
I2C_MUX_REG as well, and the compilation will fail for the
register driver.
Fix this up by making I2C_MUX_REG depend on HAS_IOMEM and
removing the dependency from I2C_MUX.
Cc: stable@vger.kernel.org
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Reported-by: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
Cc: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
Cc: Peter Rosin <peda@axentia.se>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Drop the assumed dependency on OF from I2C_MUX
---
drivers/i2c/Kconfig | 1 -
drivers/i2c/muxes/Kconfig | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index d223650a97e4..11edabf425ae 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -59,7 +59,6 @@ config I2C_CHARDEV
config I2C_MUX
tristate "I2C bus multiplexing support"
- depends on HAS_IOMEM
help
Say Y here if you want the I2C core to support the ability to
handle multiplexed I2C bus topologies, by presenting each
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index e280c8ecc0b5..96de9ce5669b 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -63,6 +63,7 @@ config I2C_MUX_PINCTRL
config I2C_MUX_REG
tristate "Register-based I2C multiplexer"
+ depends on HAS_IOMEM
help
If you say yes to this option, support will be included for a
register based I2C multiplexer. This driver provides access to
--
2.7.4
^ permalink raw reply related
* [PATCH 4/4] sanity.bbclass: fix check_connectivity() for BB_NO_NETWORK = "0"
From: Robert Yang @ 2016-11-14 14:34 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1479133967.git.liezhi.yang@windriver.com>
The old code:
network_enabled = not d.getVar('BB_NO_NETWORK', True)
It is True only when BB_NO_NETWORK is not set (None),
but BB_NO_NETWORK = "0" should also be True while "1" means no network,
"0" means need network in a normal case.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
meta/classes/sanity.bbclass | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 7e383f9..c5e3809 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -363,15 +363,19 @@ def check_connectivity(d):
test_uris = (d.getVar('CONNECTIVITY_CHECK_URIS', True) or "").split()
retval = ""
+ bbn = d.getVar('BB_NO_NETWORK', True)
+ if bbn not in (None, '0', '1'):
+ return 'BB_NO_NETWORK should be "0" or "1", but it is "%s"' % bbn
+
# Only check connectivity if network enabled and the
# CONNECTIVITY_CHECK_URIS are set
- network_enabled = not d.getVar('BB_NO_NETWORK', True)
+ network_enabled = not (bbn == '1')
check_enabled = len(test_uris)
- # Take a copy of the data store and unset MIRRORS and PREMIRRORS
- data = bb.data.createCopy(d)
- data.delVar('PREMIRRORS')
- data.delVar('MIRRORS')
if check_enabled and network_enabled:
+ # Take a copy of the data store and unset MIRRORS and PREMIRRORS
+ data = bb.data.createCopy(d)
+ data.delVar('PREMIRRORS')
+ data.delVar('MIRRORS')
try:
fetcher = bb.fetch2.Fetch(test_uris, data)
fetcher.checkstatus()
--
2.10.2
^ permalink raw reply related
* [PATCH 3/4] sanity.bbclass:check_connectivity(): print more error messages
From: Robert Yang @ 2016-11-14 14:34 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1479133967.git.liezhi.yang@windriver.com>
This can help fix the problem when the error happens.
Now the error message is:
Fetcher failure for URL: 'https://www.example.com/'. URL https://www.example.com/ doesn't work.
Please ensure your host's network is configured correctly,
or set BB_NO_NETWORK = "1" to disable network access if
all required sources are on local disk.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
meta/classes/sanity.bbclass | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 7682ffb..7e383f9 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -380,7 +380,10 @@ def check_connectivity(d):
# pointed to a support mechanism.
msg = data.getVar('CONNECTIVITY_CHECK_MSG', True) or ""
if len(msg) == 0:
- msg = "%s. Please ensure your network is configured correctly.\n" % err
+ msg = "%s.\n" % err
+ msg += " Please ensure your host's network is configured correctly,\n"
+ msg += " or set BB_NO_NETWORK = \"1\" to disable network access if\n"
+ msg += " all required sources are on local disk.\n"
retval = msg
return retval
--
2.10.2
^ permalink raw reply related
* [PATCH 2/4] testsdk.bbclass: print which file is not found
From: Robert Yang @ 2016-11-14 14:34 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1479133967.git.liezhi.yang@windriver.com>
This is helpful when debug.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
meta/classes/testsdk.bbclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/classes/testsdk.bbclass b/meta/classes/testsdk.bbclass
index 43342b1..06b4c50 100644
--- a/meta/classes/testsdk.bbclass
+++ b/meta/classes/testsdk.bbclass
@@ -59,7 +59,7 @@ def testsdk_main(d):
tcname = d.expand("${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh")
if not os.path.exists(tcname):
- bb.fatal("The toolchain is not built. Build it before running the tests: 'bitbake <image> -c populate_sdk' .")
+ bb.fatal("The toolchain %s is not built. Build it before running the tests: 'bitbake <image> -c populate_sdk' ." % tcname)
sdktestdir = d.expand("${WORKDIR}/testimage-sdk/")
bb.utils.remove(sdktestdir, True)
@@ -109,8 +109,8 @@ def testsdkext_main(d):
tcname = d.expand("${SDK_DEPLOY}/${TOOLCHAINEXT_OUTPUTNAME}.sh")
if not os.path.exists(tcname):
- bb.fatal("The toolchain ext is not built. Build it before running the" \
- " tests: 'bitbake <image> -c populate_sdk_ext' .")
+ bb.fatal("The toolchain ext %s is not built. Build it before running the" \
+ " tests: 'bitbake <image> -c populate_sdk_ext' ." % tcname)
testdir = d.expand("${WORKDIR}/testsdkext/")
bb.utils.remove(testdir, True)
--
2.10.2
^ permalink raw reply related
* [PATCH 1/4] populate_sdk_ext.bbclass: use weak assignment for TOOLCHAINEXT_OUTPUTNAME
From: Robert Yang @ 2016-11-14 14:34 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <cover.1479133967.git.liezhi.yang@windriver.com>
The TOOLCHAINEXT_OUTPUTNAME is different from TOOLCHAIN_OUTPUTNAME, it
is used for eSDK only, so that it doesn't mix with SDK, use "?=" for it
so that other conf file can define it.
If we don't use "?=" here, then we need use forcevariable to redfine it:
TOOLCHAINEXT_OUTPUTNAME_forcevariable = "foo"
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
---
meta/classes/populate_sdk_ext.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/populate_sdk_ext.bbclass b/meta/classes/populate_sdk_ext.bbclass
index a0856d4..2c9def6 100644
--- a/meta/classes/populate_sdk_ext.bbclass
+++ b/meta/classes/populate_sdk_ext.bbclass
@@ -77,7 +77,7 @@ COREBASE_FILES ?= " \
SDK_DIR_task-populate-sdk-ext = "${WORKDIR}/sdk-ext"
B_task-populate-sdk-ext = "${SDK_DIR}"
-TOOLCHAINEXT_OUTPUTNAME = "${SDK_NAME}-toolchain-ext-${SDK_VERSION}"
+TOOLCHAINEXT_OUTPUTNAME ?= "${SDK_NAME}-toolchain-ext-${SDK_VERSION}"
TOOLCHAIN_OUTPUTNAME_task-populate-sdk-ext = "${TOOLCHAINEXT_OUTPUTNAME}"
SDK_EXT_TARGET_MANIFEST = "${SDK_DEPLOY}/${TOOLCHAINEXT_OUTPUTNAME}.target.manifest"
--
2.10.2
^ 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.