* [RFC PATCH 2/4] audit: kernel generated netlink traffic should have a portid of 0
From: Paul Moore @ 2017-03-21 18:58 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <149012253566.14936.15800724055046569015.stgit@sifl>
From: Paul Moore <paul@paul-moore.com>
We were setting the portid incorrectly in the netlink message headers,
fix that to always be 0 (nlmsg_pid = 0).
Signed-off-by: Paul Moore <paul@paul-moore.com>
---
include/linux/audit.h | 3 +--
kernel/audit.c | 23 ++++++-----------------
kernel/audit.h | 3 +--
kernel/auditfilter.c | 14 ++++++--------
4 files changed, 14 insertions(+), 29 deletions(-)
diff --git a/include/linux/audit.h b/include/linux/audit.h
index 504e784b7ffa..cc0497c39472 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -163,8 +163,7 @@ extern void audit_log_task_info(struct audit_buffer *ab,
extern int audit_update_lsm_rules(void);
/* Private API (for audit.c only) */
-extern int audit_rule_change(int type, __u32 portid, int seq,
- void *data, size_t datasz);
+extern int audit_rule_change(int type, int seq, void *data, size_t datasz);
extern int audit_list_rules_send(struct sk_buff *request_skb, int seq);
extern u32 audit_enabled;
diff --git a/kernel/audit.c b/kernel/audit.c
index 4037869b4b64..6cbf47a372e8 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -251,14 +251,6 @@ static struct sock *audit_get_sk(const struct net *net)
return aunet->sk;
}
-static void audit_set_portid(struct audit_buffer *ab, __u32 portid)
-{
- if (ab) {
- struct nlmsghdr *nlh = nlmsg_hdr(ab->skb);
- nlh->nlmsg_pid = portid;
- }
-}
-
void audit_panic(const char *message)
{
switch (audit_failure) {
@@ -819,7 +811,7 @@ int audit_send_list(void *_dest)
return 0;
}
-struct sk_buff *audit_make_reply(__u32 portid, int seq, int type, int done,
+struct sk_buff *audit_make_reply(int seq, int type, int done,
int multi, const void *payload, int size)
{
struct sk_buff *skb;
@@ -832,7 +824,7 @@ struct sk_buff *audit_make_reply(__u32 portid, int seq, int type, int done,
if (!skb)
return NULL;
- nlh = nlmsg_put(skb, portid, seq, t, size, flags);
+ nlh = nlmsg_put(skb, 0, seq, t, size, flags);
if (!nlh)
goto out_kfree_skb;
data = nlmsg_data(nlh);
@@ -876,7 +868,6 @@ static int audit_send_reply_thread(void *arg)
static void audit_send_reply(struct sk_buff *request_skb, int seq, int type, int done,
int multi, const void *payload, int size)
{
- u32 portid = NETLINK_CB(request_skb).portid;
struct net *net = sock_net(NETLINK_CB(request_skb).sk);
struct sk_buff *skb;
struct task_struct *tsk;
@@ -886,12 +877,12 @@ static void audit_send_reply(struct sk_buff *request_skb, int seq, int type, int
if (!reply)
return;
- skb = audit_make_reply(portid, seq, type, done, multi, payload, size);
+ skb = audit_make_reply(seq, type, done, multi, payload, size);
if (!skb)
goto out;
reply->net = get_net(net);
- reply->portid = portid;
+ reply->portid = NETLINK_CB(request_skb).portid;
reply->skb = skb;
tsk = kthread_run(audit_send_reply_thread, reply, "audit_send_reply");
@@ -1075,7 +1066,7 @@ static int audit_replace(pid_t pid)
{
struct sk_buff *skb;
- skb = audit_make_reply(0, 0, AUDIT_REPLACE, 0, 0, &pid, sizeof(pid));
+ skb = audit_make_reply(0, AUDIT_REPLACE, 0, 0, &pid, sizeof(pid));
if (!skb)
return -ENOMEM;
return auditd_send_unicast_skb(skb);
@@ -1245,7 +1236,6 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
size--;
audit_log_n_untrustedstring(ab, data, size);
}
- audit_set_portid(ab, NETLINK_CB(skb).portid);
audit_log_end(ab);
}
break;
@@ -1259,8 +1249,7 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
audit_log_end(ab);
return -EPERM;
}
- err = audit_rule_change(msg_type, NETLINK_CB(skb).portid,
- seq, data, nlmsg_len(nlh));
+ err = audit_rule_change(msg_type, seq, data, nlmsg_len(nlh));
break;
case AUDIT_LIST_RULES:
err = audit_list_rules_send(skb, seq);
diff --git a/kernel/audit.h b/kernel/audit.h
index 0f1cf6d1878a..c21b74dd7ff2 100644
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -237,8 +237,7 @@ extern int audit_uid_comparator(kuid_t left, u32 op, kuid_t right);
extern int audit_gid_comparator(kgid_t left, u32 op, kgid_t right);
extern int parent_len(const char *path);
extern int audit_compare_dname_path(const char *dname, const char *path, int plen);
-extern struct sk_buff *audit_make_reply(__u32 portid, int seq, int type,
- int done, int multi,
+extern struct sk_buff *audit_make_reply(int seq, int type, int done, int multi,
const void *payload, int size);
extern void audit_panic(const char *message);
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index 880519d6cf2a..81cdf8d8f319 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -1033,7 +1033,7 @@ int audit_del_rule(struct audit_entry *entry)
}
/* List rules using struct audit_rule_data. */
-static void audit_list_rules(__u32 portid, int seq, struct sk_buff_head *q)
+static void audit_list_rules(int seq, struct sk_buff_head *q)
{
struct sk_buff *skb;
struct audit_krule *r;
@@ -1048,15 +1048,15 @@ static void audit_list_rules(__u32 portid, int seq, struct sk_buff_head *q)
data = audit_krule_to_data(r);
if (unlikely(!data))
break;
- skb = audit_make_reply(portid, seq, AUDIT_LIST_RULES,
- 0, 1, data,
+ skb = audit_make_reply(seq, AUDIT_LIST_RULES, 0, 1,
+ data,
sizeof(*data) + data->buflen);
if (skb)
skb_queue_tail(q, skb);
kfree(data);
}
}
- skb = audit_make_reply(portid, seq, AUDIT_LIST_RULES, 1, 1, NULL, 0);
+ skb = audit_make_reply(seq, AUDIT_LIST_RULES, 1, 1, NULL, 0);
if (skb)
skb_queue_tail(q, skb);
}
@@ -1085,13 +1085,11 @@ static void audit_log_rule_change(char *action, struct audit_krule *rule, int re
/**
* audit_rule_change - apply all rules to the specified message type
* @type: audit message type
- * @portid: target port id for netlink audit messages
* @seq: netlink audit message sequence (serial) number
* @data: payload data
* @datasz: size of payload data
*/
-int audit_rule_change(int type, __u32 portid, int seq, void *data,
- size_t datasz)
+int audit_rule_change(int type, int seq, void *data, size_t datasz)
{
int err = 0;
struct audit_entry *entry;
@@ -1150,7 +1148,7 @@ int audit_list_rules_send(struct sk_buff *request_skb, int seq)
skb_queue_head_init(&dest->q);
mutex_lock(&audit_filter_mutex);
- audit_list_rules(portid, seq, &dest->q);
+ audit_list_rules(seq, &dest->q);
mutex_unlock(&audit_filter_mutex);
tsk = kthread_run(audit_send_list, dest, "audit_send_list");
^ permalink raw reply related
* Re: [PATCH v2 09/16] tag: add more incompatibles mode tests
From: Ævar Arnfjörð Bjarmason @ 2017-03-21 18:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Lars Hjemli, Jeff King, Christian Couder,
Carlos Rica, Samuel Tardieu, Tom Grennan, Karthik Nayak
In-Reply-To: <xmqqshm6pjja.fsf@gitster.mtv.corp.google.com>
On Tue, Mar 21, 2017 at 7:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> Amend the test suite to test for more invalid uses like "-l -a"
>> etc. This mainly tests the `(argc == 0 && !cmdmode)` ->
>> `((create_tag_object || force) && (cmdmode != 0))` code path in
>> builtin/tag.c.
>
> The second sentence is now stale, isn't it?
I've reworded this in WIP v3 to split out the code from the text,
making this less confusing.
>>
>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>> ---
>> t/t7004-tag.sh | 13 +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
>> index 63ee2cf727..958c77ab86 100755
>> --- a/t/t7004-tag.sh
>> +++ b/t/t7004-tag.sh
>> @@ -1455,6 +1455,19 @@ test_expect_success 'checking that initial commit is in all tags' "
>>
>> test_expect_success 'mixing incompatibles modes and options is forbidden' '
>> test_must_fail git tag -a &&
>> + test_must_fail git tag -a -l &&
>> + test_must_fail git tag -s &&
>> + test_must_fail git tag -s -l &&
>> + test_must_fail git tag -m &&
>> + test_must_fail git tag -m -l &&
>> + test_must_fail git tag -m "hlagh" &&
>> + test_must_fail git tag -m "hlagh" -l &&
>> + test_must_fail git tag -F &&
>> + test_must_fail git tag -F -l &&
>> + test_must_fail git tag -f &&
>> + test_must_fail git tag -f -l &&
>> + test_must_fail git tag -a -s -m -F &&
>> + test_must_fail git tag -a -s -m -F -l &&
>> test_must_fail git tag -l -v &&
>> test_must_fail git tag -n 100 &&
>> test_must_fail git tag -l -m msg &&
^ permalink raw reply
* [RFC PATCH 1/4] audit: combine audit_receive() and audit_receive_skb()
From: Paul Moore @ 2017-03-21 18:58 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <149012253566.14936.15800724055046569015.stgit@sifl>
From: Paul Moore <paul@paul-moore.com>
There is no reason to have both of these functions, combine the two.
Signed-off-by: Paul Moore <paul@paul-moore.com>
---
kernel/audit.c | 19 ++++++++-----------
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 2f4964cfde0b..4037869b4b64 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1381,11 +1381,14 @@ static int audit_receive_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
return err < 0 ? err : 0;
}
-/*
- * Get message from skb. Each message is processed by audit_receive_msg.
- * Malformed skbs with wrong length are discarded silently.
+/**
+ * audit_receive - receive messages from a netlink control socket
+ * @skb: the message buffer
+ *
+ * Parse the provided skb and deal with any messages that may be present,
+ * malformed skbs are discarded.
*/
-static void audit_receive_skb(struct sk_buff *skb)
+static void audit_receive(struct sk_buff *skb)
{
struct nlmsghdr *nlh;
/*
@@ -1398,6 +1401,7 @@ static void audit_receive_skb(struct sk_buff *skb)
nlh = nlmsg_hdr(skb);
len = skb->len;
+ mutex_lock(&audit_cmd_mutex);
while (nlmsg_ok(nlh, len)) {
err = audit_receive_msg(skb, nlh);
/* if err or if this message says it wants a response */
@@ -1406,13 +1410,6 @@ static void audit_receive_skb(struct sk_buff *skb)
nlh = nlmsg_next(nlh, &len);
}
-}
-
-/* Receive messages from netlink socket. */
-static void audit_receive(struct sk_buff *skb)
-{
- mutex_lock(&audit_cmd_mutex);
- audit_receive_skb(skb);
mutex_unlock(&audit_cmd_mutex);
}
^ permalink raw reply related
* [RFC PATCH 0/4] Assorted audit fixes/improvements
From: Paul Moore @ 2017-03-21 18:58 UTC (permalink / raw)
To: linux-audit
Some miscellaneous audit patches that layer on top of the lock/queue
patch I posted earlier today. Unlike the lock/queue fix patch these
patches would go into the next branch and not the stable-4.11 branch.
I'll probably need to rebase the audit/next branch to merge these
patches, but that is something we'll worry about when the time comes.
---
Paul Moore (4):
audit: combine audit_receive() and audit_receive_skb()
audit: kernel generated netlink traffic should have a portid of 0
audit: store the auditd PID as a pid struct instead of pid_t
audit: use kmem_cache to manage the audit_buffer cache
include/linux/audit.h | 3 -
kernel/audit.c | 190 ++++++++++++++++++++++---------------------------
kernel/audit.h | 5 +
kernel/auditfilter.c | 14 ++--
4 files changed, 96 insertions(+), 116 deletions(-)
^ permalink raw reply
* Re: [RESEND PATCH 1/7] time: Delete do_sys_setimeofday()
From: Deepa Dinamani @ 2017-03-21 18:57 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, Thomas Gleixner, Linux Kernel Mailing List,
John Stultz, Arnd Bergmann, y2038 Mailman List
In-Reply-To: <201703220106.PQI3enpR%fengguang.wu@intel.com>
> arch/alpha/kernel/osf_sys.c: In function 'SYSC_osf_settimeofday':
>>> arch/alpha/kernel/osf_sys.c:1032:9: error: implicit declaration of function 'do_sys_settimeofday' [-Werror=implicit-function-declaration]
> return do_sys_settimeofday(tv ? &kts : NULL, tz ? &ktz : NULL);
> ^~~~~~~~~~~~~~~~~~~
> cc1: some warnings being treated as errors
>
> vim +/do_sys_settimeofday +1032 arch/alpha/kernel/osf_sys.c
I missed this do_sys_settimeofday() call.
I will fix this in v2.
Thanks,
Deepa
^ permalink raw reply
* Re: Telit LE910V1 - LTE only modem
From: Denis Kenzior @ 2017-03-21 18:57 UTC (permalink / raw)
To: ofono
In-Reply-To: <4d3d4e53-474b-55ec-b364-242c7e8b67d1@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]
Hi Lukasz,
> I am still a little bit confused about ofono_gprs_cid_activated(). As far as I can see only atmodem calls it. No other driver does that.
That's because only the ublox devices have been properly enabled for LTE :)
> I am not sure if a context is automatically created. I can see that the sim card has a few profiles, and the user can select which APN to use, start/stop ip network, etc.
Yes, that's how LTE works. An initial context (default bearer) is
always activated on LTE. The device can provide an initial attach APN
(see doc/lte-api.txt) which is used to tell the modem which APN to
attach to by default. From what I recall, the device can provide an
empty APN (in which case the network assigns one).
The default bearer varies by the carrier. Some use it for IMS, some use
it for the internet context. So the modem/firmware behavior is often
tweaked for a particular carrier. Some modems might not report the
default context at all in which case the device acts more like a 3G
modem than an lte one.
Regards,
-Denis
^ permalink raw reply
* Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson
From: Emil Velikov @ 2017-03-21 18:56 UTC (permalink / raw)
To: Matt Turner; +Cc: ML mesa-dev, ML dri-devel, Jason Ekstrand, Dylan Baker
In-Reply-To: <CAEdQ38GfgCic6_ACCidF8CALg3Q_mNrhee0fdYcV_yheTAXy4g@mail.gmail.com>
On 21 March 2017 at 18:06, Matt Turner <mattst88@gmail.com> wrote:
> On Tue, Mar 21, 2017 at 10:16 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>> On 21 March 2017 at 15:57, Matt Turner <mattst88@gmail.com> wrote:
>>> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>>> On 20 March 2017 at 18:30, Matt Turner <mattst88@gmail.com> wrote:
>>>>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>>>>> Seems like we ended up all over the place, so let me try afresh.
>>>>>>
>>>>>> Above all:
>>>>>> - Saying "I don't care" about your users is arrogant - let us _not_
>>>>>> do that, please ?
>>>>>
>>>>> Let's be honest, the OpenBSD is subjecting itself to some pretty
>>>>> arbitrary restrictions caused including Mesa in its core: 10+ year old
>>>>> GCC,
>>>> IIRC Brian was using old MinGW GCC, which was one of the blockers - it
>>>> wasn't OpenBSD to blame here ;-)
>>>>
>>>>> non-GNU Make, and now no Meson. I don't believe either FreeBSD or
>>>>> NetBSD keep Mesa as part of the core operating system, and as such
>>>>> don't suffer from these problems.
>>>>>
>>>>> For better or worse, they have made their choices and they get to live
>>>>> with them. We are not beholden to them.
>>>>>
>>>> Overall this hunk seems misplaced. I go agree that we should not cater
>>>> for all their needs. At the same time, intentionally, breaking things
>>>> while we all can coexist is very strange.
>>>>
>>>>>> Even Linux distribution maintainers have responded that "upstream does
>>>>>> not care us", which is indicative that we should be more careful what
>>>>>> we say.
>>>>>
>>>>> Citation needed.
>>>>>
>>>> https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
>>>> couple of instances where I've been contacted in private.
>>>>
>>>>>> For the rest - we're dealing with two orthogonal issues here:
>>>>>>
>>>>>> * Multiple build systems
>>>>>> I believe we'll all agree that I might be the person who's been in all
>>>>>> the build systems the most.
>>>>>> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>>>>>
>>>>> No one is advocating dropping all of the existing build systems yet.
>>>>>
>>>>> This patch is an RFC for a smaller project to start the discussion about Mesa.
>>>>>
>>>>>> - [currently] there is no viable solution for Android
>>>>>
>>>>> Acknowledged. Dylan is going to see if this is something that can be
>>>>> solved in upstream Meson.
>>>>>
>>>> I would suggest checking with Android people as well, as Meson.
>>>> There's some plans on moving to yet another build system - Blueprint.
>>>>
>>>>>> - dropping the Autotools will lead to OpenBSD and NetBSD having to
>>>>>> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
>>>>>> boat.
>>>>>
>>>>> Solaris is a closed source operating system whose developers do not
>>>>> contribute to the project. We do not need to base our decisions on
>>>>> them.
>>>>>
>>>>> Mesa is not subject to ridiculous requirements (like in the case of
>>>>> OpenBSD) in FreeBSD and NetBSD.
>>>> Again - not a requirement, but coexistence.
>>>>
>>>>> Mesa depends on gmake in FreeBSD's
>>>>> ports, for instance.
>>>>>
>>>> That amongst others is a bug in their packaging.
>>>
>>> That is not even remotely the point.
>>>
>>> My point is that they are not subjecting themselves (and us by
>>> extension, since you want to let them) to such ridiculous
>>> requirements.
>>>
>> I will kindly ask you to keep these adjectives outside of what aims to
>> be (?) technical discussion.
>
> Huh?
>
> Didn't you call us arrogant in this very thread? Didn't you suggest
> we're immature?
>
Should I was unclear previously - I'm not trying to belittle, insult
or otherwise offend your/anyone's contribution or input.
I'm hoping to have a technical discussion, which does not have phrases
such as "slow as mud" "i don't care", "X is ridiculous" and friends.
>> And on your question - 50-100 lines worth of compatibility changes
>> across a 6.5kloc of build system is not that unreasonable, right ?
>
> You're still not understanding my point.
>
>>>>> So I don't think any of this is true.
>>>>>
>>>> I'd suggest giving it a try then - grab a non-GNU make, a release
>>>> tarball and let me know if you spot any issues.
>>>>
>>>>>> These projects have been getting closer to upstream and "forcing" the
>>>>>> extra obstacle is effectively giving them the middle finger.
>>>>>
>>>>> No. Requiring us to compile with a 10 year old GCC is giving a middle finger.
>>>>>
>>>> Can we stop with the GCC thing ? Can we point to a place where we want
>>>> to use feature A introduced with GCC B and we don't ?
>>>
>>> Are you freaking serious?!
>>>
>>> This happens *all* the time. It happened like two days ago with commit
>>> 28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
>>> happened at least once in the previous month, and every month before
>>> that.
>>>
>> Considering none of the ANV code is built outside of Linux, why you
>> guys will restrict yourself is beyond me.
>
> I think you're confused.
>
Can you elaborate ?
You pointed out that we're restricting ourselves to old GCC version
due to OpenBSD. Yet the example given is not code that is build, or
expected to build soon on said platform.
Hence, If you guys want to use functionality from GCC 4.7 [which I
would encourage you to do] it would be better to add a 3 line
configure check - just like st/nine and st/clover already do.
>> Nine requires GCC 4.6 and Clover GCC 4.7 for a long time.
>>
>>>> The anonymous unions/structs for example require newer GCC and we use
>>>> them extensively. If anything we have the workaround(s) for MSVC's
>>>> lack of designated initializers.
>>>
>>> We actually have
>>>
>>> if test "x$USE_GNU99" = xyes; then
>>> CFLAGS="$CFLAGS -std=gnu99"
>>> else
>>> CFLAGS="$CFLAGS -std=c99"
>>> fi
>>>
>>> in configure.ac to work around gcc-4.4 incompatibilities.
>>>
>> 5-10 lines of configure code is not that much of a burden, right ?
>
> You're missing the point again.
>
>>>> Not to mention that some/many of the restrictions are imposed by very
>>>> older enterprise linuxes.
>>>
>>> which eventually go out of support and those requirements disappear.
>>> Unlike OpenBSD's insistence on using the last GPLv2 GCC.
>>>
>> At which point we can reconsider, right - perhaps they have the
>> functionality backported, have moved to new version/another compiler
>> etc.
>
> You're missing the point again.
>
Can you/anyone elaborate on this/other points that I'm missing ? Please ?
>>>>>> * Slow build times
>>>>>> Before we jump into "the next cool thing", let us properly utilise
>>>>>> what we have at the moment.
>>>>>
>>>>> It cannot be properly utilized. There is a patch on the list *today*
>>>>> that is attempting to workaround the *design* of libtool. It's an
>>>>> issue that's existed... since libtool?
>>>>>
>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=58664
>>>>> https://lists.gnu.org/archive/html/libtool/2003-06/msg00068.html
>>>>>
>>>> Yes design is ..., but I'm talking about utilising all the X cores on $platform.
>>>>
>>>>>> - I've asked multiple times about numbers behind those "let's make
>>>>>> the build faster" patches, but never got any :-\
>>>>>
>>>>> What patches? The patches in this thread? What is your question?
>>>>>
>>>> Nearly every time we had a "let's remove this recursive Makefile"
>>>> patch I asked "what improvement are we talking about here - how long
>>>> does it take before/after this patch to build mesa".
>>>> I'm yet to see any numbers :-\
>>>
>>> Because it's basically always small.
>> IIRC Jason, mentioned something similar to "loads" with the recent ANV
>> move - silly me cannot find the quote :-\
>>
>> Found another one though (from the glsl/nir move to compiler/)
>>
>> On 16 December 2015 at 20:24, Matt Turner <mattst88@gmail.com> wrote:
>>> On Wed, Dec 16, 2015 at 8:53 AM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>
>>> > Can anyone confirm how much of a penalty are we talking about (single
>>> > vs separate makefiles) ?
>>>
>>> I'm not going to take the time to quantify it. Just do a clean build
>>> and watch as 7 of your 8 cores sit idle as format_srgb.c is generated
>>> or shared-glapi/libglapi.la is linked. (A dual-core system is not
>>> going to demonstrate this issue properly)
>>
>> This is where I should have said - "I don't have a 8 core system, so I
>> cannot measure it", although on your end one could have let it compile
>> [say, during your lunch] and share with some numbers.
>> Your reply is quite provocative and even if I've had an full-retard
>> moment, I'm not sure that this is the way to reply.
>>
>>> The whole project needs to be
>>> non-recursive, otherwise you get lots of little directories and stalls
>>> (generating format_srgb comes to mind). All the work making things
>>> non-recursive are opportunistic, and don't really address the
>>> completely intractable nature of the problem: there are still 95
>>> Makefile.ams.
>>>
>> Fully agree - those can be reworked, but I simply cannot measure any
>> difference on the systems I have access to.
>> Hence, cannot estimate the severity of the problem.
>>
>>>> Some cases that come to mind - mapi (gles1/2), glsl, nir and the latest ANV.
>>>>
>>>>>> - I can improve things but would need access to a fancy XX core
>>>>>> system to do rudimentary benchmarks/checks and test patches.
>>>>>
>>>>> Have you ever seen an autotools build system for a project as complex
>>>>> as Mesa that is both non-recursive and comprehensible? I have not, and
>>>>> I did a lot of searching. In my opinion, this is an intractable
>>>>> problem.
>>>>>
>>>> Haven't looked at all really - off the top of my head openvswitch comes to mind.
>>>> Then again, It's not as extensive as mesa :-\
>>>
>>> Just looked -- you know what their last commit to Makefile.am is?
>>>
>>> Makefile: Drop vestiges of support for non-GNU Make.
>>>
>> That's their decision. I am pointing out that one can have a sane
>> project w/o recursive makefiles, yet perfectly readable.
>>
>>>>> ... and with Meson it is tractable. And it doesn't use libtool. And it
>>>>> can replace at least 2 and maybe all three of our build systems.
>>>>>
>>>>> Those all seem extremely compelling to me, and I think I've done
>>>>> enough work on Mesa's build system and on a downstream distribution to
>>>>> have a valuable opinion on the matter.
>>>> Yes you did a lot of work on the autotools side, with less so on scons
>>>> and android.
>>>>
>>>> What I'm saying is - let us be mature and stop it with the [reasonable
>>>> or not] hatred towards autotools.
>>>
>>> Troll bait.
>>>
>> ? You're saying that nobody is bashing on autotools/friends... ok.
>
> They are not my favorite pieces of software and I think there are
> sound technical arguments in favor of Meson in comparison to them,
> which I and others have made repeatedly in this thread.
>
> None of that is immature.
>
Disagreeing with something/someone is fine, calling it names seems
immature... at least for me.
>>>> It is far from perfect, yet we can improve things on our end rather
>>>> than throwing everything in the bin.
>>>
>>> I have. Again, I think I have done enough of that that I have some
>>> credibility on the matter.
>>
>> Not trying to belittle any of your work, but this does not parse in
>> reply to my suggestion, sorry.
>>
>>
>> Overall your replies seem quite spontaneous/emotional. If I'm making
>> you upset - I do apologise.
>> I'm simply trying to get as much technical details, which I seems to
>> be tailing at.
>
> Let me try one last time:
>
> (1) Non-recursive automake is necessary for parallel build performance
Fully agree
> (2) Non-recursive automake is intractably unmaintainable for
> sufficiently large projects
Not sure I agree here. Do the src/intel/Makefile* files, seem unmaintainable ?
> (3) Mesa is a sufficiently large project
>
Again - fully agree.
> Therefore using automake will be either bad for parallel build
> performance, unmaintainable, or both.
>
> Meson aims to be a build system actually capable of replacing
> autotools (IMO unlike cmake, scons, waf, et al.). It offers a much
> cleaner domain specific language for writing the build rules, while
> generating non-recursive ninja build files. It does not use libtool.
> It supports Windows. It supports cross compilation.
>
Does it support, Darwin/MacOSX, Cygwin, any of the BSDs, Solaris (and
alike) platforms,
How about Android - Android.mk or Blueprint.
Does it have "dist", "check", "distcheck" or less commonly used
"ctags" "cscope" targets ?
> And it has momentum: libepoxy already has a Meson build system. Others
> in the X.Org community are experimenting with it for libinput, Wayland
> and Weston, and the xserver.
>
> All of that makes Meson very compelling.
That's the thing - I'm never said that it's _not_ a very compelling project.
I'm saying that it's not there yet - mostly due to the list above.
Thanks
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 net-next] net: fix dma operation mode config for older versions
From: Florian Fainelli @ 2017-03-21 18:56 UTC (permalink / raw)
To: Joao Pinto, davem
Cc: peppe.cavallaro, alexandre.torgue, clabbe.montjoie,
thierry.reding, sergei.shtylyov, netdev
In-Reply-To: <3b8aeab69d2987db68c74f48a3ac13c7241e1542.1490118934.git.jpinto@synopsys.com>
On 03/21/2017 11:02 AM, Joao Pinto wrote:
> This patch fixes a bug introduced in:
> commit 6deee2221e11 ("net: stmmac: prepare dma op mode config for multiple
> queues")
So even though this is against net-next which is the only tree so far
having the offending commit, it is nice to see this appear later in the
commit messages as:
Fixes: 6deee2221e11 ("net: stmmac: prepare dma op mode config for
multiple queues")
Also, your subject for this patch should be:
net: stmmac: fix dma operation mode config for older versions
>
> The dma operation mode configuration routine was wrongly moved to a
> function (stmmac_mtl_configuration) that is only executed if the
> core version is >= 4.00.
>
> Reported-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index d3a2151..225a3a3 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -1945,9 +1945,6 @@ static void stmmac_mtl_configuration(struct stmmac_priv *priv)
> /* Enable MAC RX Queues */
> if (rx_queues_count > 1 && priv->hw->mac->rx_queue_enable)
> stmmac_mac_enable_rx_queues(priv);
> -
> - /* Set the HW DMA mode and the COE */
> - stmmac_dma_operation_mode(priv);
> }
>
> /**
> @@ -2014,6 +2011,9 @@ static int stmmac_hw_setup(struct net_device *dev, bool init_ptp)
> else
> stmmac_set_mac(priv->ioaddr, true);
>
> + /* Set the HW DMA mode and the COE */
> + stmmac_dma_operation_mode(priv);
> +
> stmmac_mmc_setup(priv);
>
> if (init_ptp) {
>
--
Florian
^ permalink raw reply
* [U-Boot] [PATCH 2/2] net: gmac_rockchip: Add phy supply support
From: Joe Hershberger @ 2017-03-21 18:56 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1489570124-26724-2-git-send-email-jacob2.chen@rock-chips.com>
On Wed, Mar 15, 2017 at 4:28 AM, Jacob Chen <jacob2.chen@rock-chips.com> wrote:
> Some board need a regulator for gmac phy, so add this code to handle it.
>
> Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
> ---
>
> drivers/net/gmac_rockchip.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/net/gmac_rockchip.c b/drivers/net/gmac_rockchip.c
> index e9b202a..63cccc9 100644
> --- a/drivers/net/gmac_rockchip.c
> +++ b/drivers/net/gmac_rockchip.c
> @@ -17,6 +17,7 @@
> #include <asm/arch/grf_rk3288.h>
> #include <dm/pinctrl.h>
> #include <dt-bindings/clock/rk3288-cru.h>
> +#include <power/regulator.h>
> #include "designware.h"
>
> DECLARE_GLOBAL_DATA_PTR;
> @@ -79,6 +80,22 @@ static int gmac_rockchip_probe(struct udevice *dev)
> struct clk clk;
> int ret;
>
> +#if defined(CONFIG_DM_REGULATOR)
> + struct udevice *phy_supply;
> +
> + ret = device_get_supply_regulator(dev, "phy-supply",
> + &phy_supply);
> + if (ret) {
> + debug("%s: No phy supply\n", dev->name);
> + } else {
> + ret = regulator_set_enable(phy_supply, true);
> + if (ret) {
> + puts("Error enabling phy supply\n");
> + return ret;
> + }
> + }
> +#endif
> +
This seems pretty generic. Is there maybe a more common place this
could live? Or is the phy-supply binding in DT only defined for
rockchip?
> ret = clk_get_by_index(dev, 0, &clk);
> if (ret)
> return ret;
> --
> 1.9.1
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
^ permalink raw reply
* [U-Boot] [PATCH] zynq: Move ENV location selection from zynq-common.h to config files.
From: Philip Balister @ 2017-03-21 18:56 UTC (permalink / raw)
To: u-boot
The ifdef's in zynq-common.h do a partial selection of the u-boot environment
storage location. As u-boot added more, the ifdefs no longe cope with all
possible cases. Rather than correct the logic there, move the selection
options into the board specific config files.
Signed-off-by: Philip Balister <philip@opensdr.com>
---
configs/zynq_microzed_defconfig | 1 +
configs/zynq_picozed_defconfig | 1 +
configs/zynq_zc702_defconfig | 1 +
configs/zynq_zc706_defconfig | 1 +
configs/zynq_zc770_xm010_defconfig | 2 +-
configs/zynq_zc770_xm011_defconfig | 2 +-
configs/zynq_zc770_xm012_defconfig | 2 +-
configs/zynq_zc770_xm013_defconfig | 2 +-
configs/zynq_zed_defconfig | 1 +
configs/zynq_zybo_defconfig | 2 ++
include/configs/zynq-common.h | 10 ----------
11 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/configs/zynq_microzed_defconfig b/configs/zynq_microzed_defconfig
index 4093618..b95c7d3 100644
--- a/configs/zynq_microzed_defconfig
+++ b/configs/zynq_microzed_defconfig
@@ -5,6 +5,7 @@ CONFIG_DEFAULT_DEVICE_TREE="zynq-microzed"
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_FIT_VERBOSE=y
+CONFIG_SYS_EXTRA_OPTIONS="ENV_IS_IN_SPI_FLASH"
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL=y
CONFIG_SPL_OS_BOOT=y
diff --git a/configs/zynq_picozed_defconfig b/configs/zynq_picozed_defconfig
index 3c3a5b2..53e9a3e 100644
--- a/configs/zynq_picozed_defconfig
+++ b/configs/zynq_picozed_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
CONFIG_ARCH_ZYNQ=y
CONFIG_SYS_TEXT_BASE=0x4000000
CONFIG_DEFAULT_DEVICE_TREE="zynq-picozed"
+CONFIG_SYS_EXTRA_OPTIONS="ENV_IS_NOWHERE"
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL=y
CONFIG_SPL_OS_BOOT=y
diff --git a/configs/zynq_zc702_defconfig b/configs/zynq_zc702_defconfig
index c59d7f5..62a96fd 100644
--- a/configs/zynq_zc702_defconfig
+++ b/configs/zynq_zc702_defconfig
@@ -6,6 +6,7 @@ CONFIG_DEFAULT_DEVICE_TREE="zynq-zc702"
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_FIT_VERBOSE=y
+CONFIG_SYS_EXTRA_OPTIONS="ENV_IS_IN_SPI_FLASH"
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL=y
CONFIG_SPL_OS_BOOT=y
diff --git a/configs/zynq_zc706_defconfig b/configs/zynq_zc706_defconfig
index c73bacb..348f9fd 100644
--- a/configs/zynq_zc706_defconfig
+++ b/configs/zynq_zc706_defconfig
@@ -6,6 +6,7 @@ CONFIG_DEFAULT_DEVICE_TREE="zynq-zc706"
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_FIT_VERBOSE=y
+CONFIG_SYS_EXTRA_OPTIONS="ENV_IS_IN_SPI_FLASH"
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL=y
CONFIG_SPL_OS_BOOT=y
diff --git a/configs/zynq_zc770_xm010_defconfig b/configs/zynq_zc770_xm010_defconfig
index ececcb4..3a8caba 100644
--- a/configs/zynq_zc770_xm010_defconfig
+++ b/configs/zynq_zc770_xm010_defconfig
@@ -5,7 +5,7 @@ CONFIG_DEFAULT_DEVICE_TREE="zynq-zc770-xm010"
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_FIT_VERBOSE=y
-CONFIG_SYS_EXTRA_OPTIONS="ZC770_XM010"
+CONFIG_SYS_EXTRA_OPTIONS="ZC770_XM010,ENV_IS_IN_SPI_FLASH"
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL=y
CONFIG_SPL_OS_BOOT=y
diff --git a/configs/zynq_zc770_xm011_defconfig b/configs/zynq_zc770_xm011_defconfig
index 980382c..7a6d2af 100644
--- a/configs/zynq_zc770_xm011_defconfig
+++ b/configs/zynq_zc770_xm011_defconfig
@@ -5,7 +5,7 @@ CONFIG_DEFAULT_DEVICE_TREE="zynq-zc770-xm011"
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_FIT_VERBOSE=y
-CONFIG_SYS_EXTRA_OPTIONS="ZC770_XM011"
+CONFIG_SYS_EXTRA_OPTIONS="ZC770_XM011,ENV_IS_NOWHERE"
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL=y
CONFIG_SPL_OS_BOOT=y
diff --git a/configs/zynq_zc770_xm012_defconfig b/configs/zynq_zc770_xm012_defconfig
index 48caf31..8d23bd9 100644
--- a/configs/zynq_zc770_xm012_defconfig
+++ b/configs/zynq_zc770_xm012_defconfig
@@ -5,7 +5,7 @@ CONFIG_DEFAULT_DEVICE_TREE="zynq-zc770-xm012"
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_FIT_VERBOSE=y
-CONFIG_SYS_EXTRA_OPTIONS="ZC770_XM012"
+CONFIG_SYS_EXTRA_OPTIONS="ZC770_XM012,ENV_IS_IN_FLASH"
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL=y
CONFIG_SPL_OS_BOOT=y
diff --git a/configs/zynq_zc770_xm013_defconfig b/configs/zynq_zc770_xm013_defconfig
index 23bcb0e..3a0b9e6 100644
--- a/configs/zynq_zc770_xm013_defconfig
+++ b/configs/zynq_zc770_xm013_defconfig
@@ -5,7 +5,7 @@ CONFIG_DEFAULT_DEVICE_TREE="zynq-zc770-xm013"
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_FIT_VERBOSE=y
-CONFIG_SYS_EXTRA_OPTIONS="ZC770_XM013"
+CONFIG_SYS_EXTRA_OPTIONS="ZC770_XM013,ENV_IS_IN_SPI_FLASH"
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL=y
CONFIG_SPL_OS_BOOT=y
diff --git a/configs/zynq_zed_defconfig b/configs/zynq_zed_defconfig
index 26a5320..3f54495 100644
--- a/configs/zynq_zed_defconfig
+++ b/configs/zynq_zed_defconfig
@@ -5,6 +5,7 @@ CONFIG_DEFAULT_DEVICE_TREE="zynq-zed"
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_FIT_VERBOSE=y
+CONFIG_SYS_EXTRA_OPTIONS="ENV_IS_IN_SPI_FLASH"
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL=y
CONFIG_SPL_OS_BOOT=y
diff --git a/configs/zynq_zybo_defconfig b/configs/zynq_zybo_defconfig
index af7fe65..ed85319 100644
--- a/configs/zynq_zybo_defconfig
+++ b/configs/zynq_zybo_defconfig
@@ -6,6 +6,7 @@ CONFIG_DEFAULT_DEVICE_TREE="zynq-zybo"
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_FIT_VERBOSE=y
+CONFIG_SYS_EXTRA_OPTIONS="ENV_IS_IN_SPI_FLASH"
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL=y
CONFIG_SPL_OS_BOOT=y
@@ -56,3 +57,4 @@ CONFIG_USB_GADGET_DOWNLOAD=y
CONFIG_G_DNL_MANUFACTURER="Xilinx"
CONFIG_G_DNL_VENDOR_NUM=0x03fd
CONFIG_G_DNL_PRODUCT_NUM=0x0300
+CONFIG_SYS_EXTRA_OPTIONS="ENV_IS_IN_SPI_FLASH"
diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
index 431d6c4..94e49fb 100644
--- a/include/configs/zynq-common.h
+++ b/include/configs/zynq-common.h
@@ -162,16 +162,6 @@
/* Environment */
#ifndef CONFIG_ENV_IS_NOWHERE
-# ifdef CONFIG_MTD_NOR_FLASH
-/* Environment in NOR flash */
-# define CONFIG_ENV_IS_IN_FLASH
-# elif defined(CONFIG_ZYNQ_QSPI)
-/* Environment in Serial Flash */
-# define CONFIG_ENV_IS_IN_SPI_FLASH
-# elif !defined(CONFIG_MTD_NOR_FLASH)
-# define CONFIG_ENV_IS_NOWHERE
-# endif
-
# define CONFIG_ENV_SECT_SIZE CONFIG_ENV_SIZE
# define CONFIG_ENV_OFFSET 0xE0000
#endif
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 2/2] doc/SubmittingPatches: show how to get a CLI commit summary
From: Ævar Arnfjörð Bjarmason @ 2017-03-21 18:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: SZEDER Gábor, Git Mailing List
In-Reply-To: <xmqqvar2qzof.fsf@gitster.mtv.corp.google.com>
On Tue, Mar 21, 2017 at 6:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
> SZEDER Gábor <szeder.dev@gmail.com> writes:
>
>>> The "Copy commit summary" command of gitk can be used to obtain this
>>> -format.
>>> +format, or this invocation of "git show":
>>>
>>> + git show -s --date=short --pretty='format:%h ("%s", %ad)' <commit>
>>> +
>>> +To turn that into a handy alias:
>>> +
>>> + git config --global alias.git-commit-summary "show -s --date=short --pretty='format:%h (\"%s\", %ad)'"
>>> +
>>> +And then to get the commit summary:
>>> +
>>> + git git-commit-summary <commit>
>>
>> - 'tformat:' is a better fit than 'format:' in this case, because it
>> adds a trailing newline.
>
> That depends on what you use it for. I most often use mine to
> insert the reference that flows in a sentence, not as a separate
> displayed material, e.g.
>
> 1f6b1afe ("Git 2.12.1", 2017-03-20)
>
> so for that purpose, not adding a trailing newline is a feature.
I agree with tformat. I didn't notice this because I've been screwing
around with my pager settings and my configuration was implicitly
adding a newline. Do you mind fixing that up Junio, or should I
re-send it?
>> - I find that the two subsequent 'git's in 'git git-<whatever>' look
>> strange. However, to make this point moot right away:
>>
>> - I don't think SubmittingPatches is the right place to show how to
>> create and use a command alias.
>
> These two I do agree with.
I don't think it disturbs the flow of the document, and since someone
going through SubmittingPatches is likely about to submit a patch,
providing that one-liner is handy, not as some "here's how to add
aliases" tutorial, but so you don't need to go and copy/paste it, add
\'s for the "'s etc.
^ permalink raw reply
* Re: [PATCH v2 11/16] tag: implicitly supply --list given another list-like option
From: Junio C Hamano @ 2017-03-21 18:48 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Lars Hjemli, Jeff King, Christian Couder, Carlos Rica,
Samuel Tardieu, Tom Grennan, Karthik Nayak
In-Reply-To: <20170321125901.10652-12-avarab@gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> Spelunking through the history via:
>
> git log --reverse -p -G'only allowed with' -- '*builtin*tag*c'
>
> Reveals that there was no good reason for not allowing this in the
> first place. The --contains option added in 32c35cfb1e ("git-tag: Add
> --contains option", 2009-01-26) made this an error,. All the other
s/,././
> subsequent list-like options that were added copied its pattern of
> making this usage an error.
Good digging, and I do agree that this is a good change.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 14/16] ref-filter: reflow recently changed branch/tag/for-each-ref docs
From: Junio C Hamano @ 2017-03-21 18:53 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Lars Hjemli, Jeff King, Christian Couder, Carlos Rica,
Samuel Tardieu, Tom Grennan, Karthik Nayak
In-Reply-To: <20170321125901.10652-15-avarab@gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> Reflow the recently changed branch/tag-for-each-ref
> documentation. This change shows no changes under --word-diff, except
> the innocuous change of moving git-tag.txt's "[--sort=<key>]" around
> slightly.
> ---
Thanks.
Needs sign-off (I could just add it back in if you tell me so ;)
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 2/2] configure: use pkg-config for obtaining xen version
From: Stefano Stabellini @ 2017-03-21 18:54 UTC (permalink / raw)
To: Juergen Gross
Cc: Stefano Stabellini, qemu-devel, xen-devel, anthony.perard, kraxel,
paul.durrant
In-Reply-To: <da852b5f-2490-c483-984d-c7be4f83b9a7@suse.com>
On Tue, 21 Mar 2017, Juergen Gross wrote:
> On 17/03/17 19:33, Stefano Stabellini wrote:
> > On Fri, 17 Mar 2017, Juergen Gross wrote:
> >> On 16/03/17 21:20, Stefano Stabellini wrote:
> >>> On Thu, 16 Mar 2017, Juergen Gross wrote:
> >>>> Instead of trying to guess the Xen version to use by compiling various
> >>>> test programs first just ask the system via pkg-config. Only if it
> >>>> can't return the version fall back to the test program scheme.
> >>>
> >>> That's OK, but why did you remove the Xen unstable test?
> >>
> >> >From Xen 4.9 on pkg-config will return the needed information. There is
> >> no longer a need for a test program to determine the Xen version. After
> >> all this was the main objective of my series adding the pkg-config
> >> files to Xen.
> >
> > I was going to say something like "yeah, but is pkg-config always
> > available?" In reality, QEMU already has pkg-config as build
> > dependency, so I guess there is no problem with that.
> >
> > Please add a note about this to the commit message.
> >
>
> Okay.
Sorry to point this out only now, and I realize that it might be
unimportant for production builds, but it is important to me, and
developers in general, to be able to test a single QEMU tree against a
number of Xen trees (all releases from 4.3 onward).
With this change (specifically dropping the 4.9 build test), out of tree
builds don't work anymore. I would like to be able to do:
./configure --enable-xen --target-list=i386-softmmu \
--extra-cflags="-I$DIR/tools/include \
-I$DIR/tools/libs/toollog/include \
-I$DIR/tools/libs/evtchn/include \
-I$DIR/tools/libs/gnttab/include \
-I$DIR/tools/libs/foreignmemory/include \
-I$DIR/tools/libs/devicemodel/include \
-I$DIR/tools/libxc/include \
-I$DIR/tools/xenstore/include \
-I$DIR/tools/xenstore/compat/include" \
--extra-ldflags="-L$DIR/tools/libxc \
-L$DIR/tools/xenstore \
-L$DIR/tools/libs/evtchn \
-L$DIR/tools/libs/gnttab \
-L$DIR/tools/libs/foreignmemory \
-L$DIR/tools/libs/devicemodel \
-Wl,-rpath-link=$DIR/tools/libs/toollog \
-Wl,-rpath-link=$DIR/tools/libs/evtchn \
-Wl,-rpath-link=$DIR/tools/libs/gnttab \
-Wl,-rpath-link=$DIR/tools/libs/call \
-Wl,-rpath-link=$DIR/tools/libs/foreignmemory \
-Wl,-rpath-link=$DIR/tools/libs/devicemodel" \
--disable-kvm
make
And the make should succeed. Is there a way to do that with pkg-config?
If not, I think we should keep the existing tests (and only add
pkg-config tests in addition to them, not in alternative).
^ permalink raw reply
* Re: [PATCH 2/2] configure: use pkg-config for obtaining xen version
From: Stefano Stabellini @ 2017-03-21 18:54 UTC (permalink / raw)
To: Juergen Gross
Cc: Stefano Stabellini, qemu-devel, paul.durrant, kraxel,
anthony.perard, xen-devel
In-Reply-To: <da852b5f-2490-c483-984d-c7be4f83b9a7@suse.com>
On Tue, 21 Mar 2017, Juergen Gross wrote:
> On 17/03/17 19:33, Stefano Stabellini wrote:
> > On Fri, 17 Mar 2017, Juergen Gross wrote:
> >> On 16/03/17 21:20, Stefano Stabellini wrote:
> >>> On Thu, 16 Mar 2017, Juergen Gross wrote:
> >>>> Instead of trying to guess the Xen version to use by compiling various
> >>>> test programs first just ask the system via pkg-config. Only if it
> >>>> can't return the version fall back to the test program scheme.
> >>>
> >>> That's OK, but why did you remove the Xen unstable test?
> >>
> >> >From Xen 4.9 on pkg-config will return the needed information. There is
> >> no longer a need for a test program to determine the Xen version. After
> >> all this was the main objective of my series adding the pkg-config
> >> files to Xen.
> >
> > I was going to say something like "yeah, but is pkg-config always
> > available?" In reality, QEMU already has pkg-config as build
> > dependency, so I guess there is no problem with that.
> >
> > Please add a note about this to the commit message.
> >
>
> Okay.
Sorry to point this out only now, and I realize that it might be
unimportant for production builds, but it is important to me, and
developers in general, to be able to test a single QEMU tree against a
number of Xen trees (all releases from 4.3 onward).
With this change (specifically dropping the 4.9 build test), out of tree
builds don't work anymore. I would like to be able to do:
./configure --enable-xen --target-list=i386-softmmu \
--extra-cflags="-I$DIR/tools/include \
-I$DIR/tools/libs/toollog/include \
-I$DIR/tools/libs/evtchn/include \
-I$DIR/tools/libs/gnttab/include \
-I$DIR/tools/libs/foreignmemory/include \
-I$DIR/tools/libs/devicemodel/include \
-I$DIR/tools/libxc/include \
-I$DIR/tools/xenstore/include \
-I$DIR/tools/xenstore/compat/include" \
--extra-ldflags="-L$DIR/tools/libxc \
-L$DIR/tools/xenstore \
-L$DIR/tools/libs/evtchn \
-L$DIR/tools/libs/gnttab \
-L$DIR/tools/libs/foreignmemory \
-L$DIR/tools/libs/devicemodel \
-Wl,-rpath-link=$DIR/tools/libs/toollog \
-Wl,-rpath-link=$DIR/tools/libs/evtchn \
-Wl,-rpath-link=$DIR/tools/libs/gnttab \
-Wl,-rpath-link=$DIR/tools/libs/call \
-Wl,-rpath-link=$DIR/tools/libs/foreignmemory \
-Wl,-rpath-link=$DIR/tools/libs/devicemodel" \
--disable-kvm
make
And the make should succeed. Is there a way to do that with pkg-config?
If not, I think we should keep the existing tests (and only add
pkg-config tests in addition to them, not in alternative).
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH v2 12/16] tag: change --point-at to default to HEAD
From: Junio C Hamano @ 2017-03-21 18:48 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Lars Hjemli, Jeff King, Christian Couder, Carlos Rica,
Samuel Tardieu, Tom Grennan, Karthik Nayak
In-Reply-To: <20170321125901.10652-13-avarab@gmail.com>
Makes sense. Thanks.
^ permalink raw reply
* [PATCH nft] src: allow update of net base w. meta l4proto icmpv6
From: Florian Westphal @ 2017-03-21 18:54 UTC (permalink / raw)
To: netfilter-devel; +Cc: Florian Westphal
nft add rule ip6 f i meta l4proto ipv6-icmp icmpv6 type nd-router-advert
<cmdline>:1:50-60: Error: conflicting protocols specified: unknown vs. icmpv6
add icmpv6 to nexthdr list so base gets updated correctly.
Reported-by: Thomas Woerner <twoerner@redhat.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
NB: This is STILL not correct.
nft add rule ip6 f i meta l4proto ipv6-icmp icmpv6 type nd-router-advert
gets listed as
icmpv6 type nd-router-advert
because post processing removes the l3 dependency.
However, "icmpv6 type nd-router-advert" uses dependency
ip6 nexthdr icmpv6
which isn't the same as meta l4proto icmpv6.
I suspect nft should always generate implicit l4 dependencies
via meta in the ipv6 case, what do others think
(and not autoremove 'nexthdr' check)?
diff --git a/src/proto.c b/src/proto.c
index 79e9dbf2b33e..fcdfbe73c735 100644
--- a/src/proto.c
+++ b/src/proto.c
@@ -779,6 +779,7 @@ const struct proto_desc proto_inet_service = {
PROTO_LINK(IPPROTO_TCP, &proto_tcp),
PROTO_LINK(IPPROTO_DCCP, &proto_dccp),
PROTO_LINK(IPPROTO_SCTP, &proto_sctp),
+ PROTO_LINK(IPPROTO_ICMPV6, &proto_icmp6),
},
.templates = {
[0] = PROTO_META_TEMPLATE("l4proto", &inet_protocol_type, NFT_META_L4PROTO, 8),
--
2.10.2
^ permalink raw reply related
* Re: [Outreachy kernel] [PATCH] staging: ade7754: Replace mlock with buf_lock and refactor code
From: Alison Schofield @ 2017-03-21 18:54 UTC (permalink / raw)
To: Gargi Sharma, Lars-Peter Clausen
Cc: outreachy-kernel, linux-iio, Michael Hennerich, Jonathan Cameron,
Hartmut Knaack, Peter Meerwald-Stadler, Greg KH
In-Reply-To: <CAOCi2DF0nhFpNsWKm5oJc7v_W59GzhaEOWGhTEPDWp3jbs8F+A@mail.gmail.com>
On Tue, Mar 21, 2017 at 11:48:27PM +0530, Gargi Sharma wrote:
> On Tue, Mar 21, 2017 at 11:42 PM, Alison Schofield <amsfield22@gmail.com> wrote:
> > On Tue, Mar 21, 2017 at 11:18:23PM +0530, Gargi Sharma wrote:
> >> On Tue, Mar 21, 2017 at 10:54 PM, Alison Schofield <amsfield22@gmail.com> wrote:
> >> > On Mon, Mar 20, 2017 at 01:09:21PM +0530, Gargi Sharma wrote:
> >> >> The IIO subsystem is redefining iio_dev->mlock to be used by
> >> >> the IIO core only for protecting device operating mode changes.
> >> >> ie. Changes between INDIO_DIRECT_MODE, INDIO_BUFFER_* modes.
> >> >>
> >> >> In this driver, mlock was being used to protect hardware state
> >> >> changes. Replace it with buf_lock in the devices global data.
> >> >>
> >> >> As buf_lock already protects operations in ade7754_write_frequency,
> >> >> there isn't a need to acquire the lock inside ade7754_spi_write_reg_8
> >> >> when writing to the register.
> >> >
> >> > Hi Gargi,
> >> >
> >> > Looks like something went wrong in your patch below. It doesn't do what
> >> > you say it'll do...Instead of removing the lock from _write_reg_8()
> >> > it inserts a bunch of code. Anyway, it seems that w_rite_reg_8() is used
> >> > in multiple places, so removing that lock doesn't appear to be an
> >> > option.
> >> >
> >> > See below...
> >> >
> >> > alisons
> >> >
> >> >>
> >> >> Signed-off-by: Gargi Sharma <gs051095@gmail.com>
> >> >> ---
> >> >> drivers/staging/iio/meter/ade7754.c | 13 +++++++++++--
> >> >> 1 file changed, 11 insertions(+), 2 deletions(-)
> >> >>
> >> >> diff --git a/drivers/staging/iio/meter/ade7754.c b/drivers/staging/iio/meter/ade7754.c
> >> >> index 024463a..eb03469 100644
> >> >> --- a/drivers/staging/iio/meter/ade7754.c
> >> >> +++ b/drivers/staging/iio/meter/ade7754.c
> >> >> @@ -29,6 +29,15 @@ static int ade7754_spi_write_reg_8(struct device *dev, u8 reg_address, u8 val)
> >> >> struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> >> >> struct ade7754_state *st = iio_priv(indio_dev);
> >> >>
> >> >> + if (reg_address == ADE7754_WAVMODE) {
> >> >> + st->tx[0] = ADE7754_WRITE_REG(reg_address);
> >> >> + st->tx[1] = val;
> >> >> +
> >> >> + ret = spi_write(st->us, st->tx, 2);
> >> >> +
> >> >> + return ret;
> >> >> + }
> >> >> +
> >> > What's this?
> >>
> >> When the function ade_spi_write_reg_8() is called inside
> >> ade7754_write_frequency(), we are writing to this( ADE7754_WAVMODE)
> >> register. When writing to this register we don't need to hold the
> >> buf_lock since ade7754_write_frequency() already takes care of that.
> >
> > Oh! I see it now. You created a special 'no lock needed' case
> > inside of --write_reg_8 for writing frequency. That works,
> > but it's...ummm...sneaky ;) Let's see if there's another way.
> >
> > Look back at Lars suggestion on a similar patch. Maybe that
> > will apply here.
> > http://marc.info/?l=linux-kernel&m=148940648615743&w=2
> >
>
> I did look at the patch you suggested for inspiration :) What I could
> not understand was the part where Lars wrote about "doing a
> read-modify-write cycle in a protected section." I can write a
> separate function for --write_reg_8 that does not take the lock, but
> do not know how to do a "read-modify-write cycle in a protected
> section" :(
>
> Gargi
Gargi - That's a great, specific question! Let's pop that back to Lars.
Lars - Can you explain further or perhaps point to a driver that does
something similar?
alisons
> > alisons
> >
> >
> >>
> >> >
> >> >> mutex_lock(&st->buf_lock);
> >> >> st->tx[0] = ADE7754_WRITE_REG(reg_address);
> >> >> st->tx[1] = val;
> >> >> @@ -430,7 +439,7 @@ static ssize_t ade7754_write_frequency(struct device *dev,
> >> >> if (!val)
> >> >> return -EINVAL;
> >> >>
> >> >> - mutex_lock(&indio_dev->mlock);
> >> >> + mutex_lock(&st->buf_lock);
> >> >>
> >> >> t = 26000 / val;
> >> >> if (t > 0)
> >> >> @@ -451,7 +460,7 @@ static ssize_t ade7754_write_frequency(struct device *dev,
> >> >> ret = ade7754_spi_write_reg_8(dev, ADE7754_WAVMODE, reg);
> >> >>
> >> >> out:
> >> >> - mutex_unlock(&indio_dev->mlock);
> >> >> + mutex_unlock(&st->buf_lock);
> >> >>
> >> >> return ret ? ret : len;
> >> >> }
> >>
> >> The buf_lock inside ade7754_write_frequency() takes into account that
> >> when using the function ade7754_spi_write_reg_8, lock is already held
> >> and locking is no longer required inside the ade7754_spi_write_reg_8()
> >> function.
> >>
> >> Let me know if this sounds okay, I can perhaps edit the commit log to
> >> make this clearer.
> >>
> >> Thanks,
> >> Gargi
> >>
> >> >> --
> >> >> 2.7.4
> >> >>
> >> >> --
> >> >> You received this message because you are subscribed to the Google Groups "outreachy-kernel" group.
> >> >> To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@googlegroups.com.
> >> >> To post to this group, send email to outreachy-kernel@googlegroups.com.
> >> >> To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/1489995561-6988-1-git-send-email-gs051095%40gmail.com.
> >> >> For more options, visit https://groups.google.com/d/optout.
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google Groups "outreachy-kernel" group.
> >> > To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@googlegroups.com.
> >> > To post to this group, send email to outreachy-kernel@googlegroups.com.
> >> > To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/20170321172438.GC2793%40d830.WORKGROUP.
> >> > For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > You received this message because you are subscribed to the Google Groups "outreachy-kernel" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to outreachy-kernel+unsubscribe@googlegroups.com.
> > To post to this group, send email to outreachy-kernel@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/msgid/outreachy-kernel/20170321181207.GA10699%40d830.WORKGROUP.
> > For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [U-Boot] [ PATCH 2/2] net: move Broadcom SF2 driver to Kconfig
From: Joe Hershberger @ 2017-03-21 18:53 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1488589596-1987-2-git-send-email-steve.rae@raedomain.com>
On Fri, Mar 3, 2017 at 7:06 PM, Steve Rae <steve.rae@raedomain.com> wrote:
> From: Suji Velupillai <suji.velupillai@broadcom.com>
>
> move to Kconfig:
> CONFIG_BCM_SF2_ETH
> CONFIG_BCM_SF2_ETH_GMAC
>
> Also modified defconfigs of all platforms that use these configs.
>
> Signed-off-by: Suji Velupillai <suji.velupillai@broadcom.com>
> Tested-by: Suji Velupillai <suji.velupillai@broadcom.com>
> Reviewed-by: JD Zheng <jiandong.zheng@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> Signed-off-by: Steve Rae <steve.rae@raedomain.com>
> ---
>
> arch/arm/include/asm/arch-bcmcygnus/configs.h | 6 +-----
> configs/bcm28155_w1d_defconfig | 5 +++--
> configs/bcm911360_entphn-ns_defconfig | 3 +++
> configs/bcm911360_entphn_defconfig | 3 +++
> configs/bcm911360k_defconfig | 3 +++
> configs/bcm958300k-ns_defconfig | 3 +++
> configs/bcm958300k_defconfig | 3 +++
> configs/bcm958305k_defconfig | 3 +++
> drivers/net/Kconfig | 15 +++++++++++++++
> scripts/config_whitelist.txt | 2 --
> 10 files changed, 37 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-bcmcygnus/configs.h b/arch/arm/include/asm/arch-bcmcygnus/configs.h
> index af7f3bf..92b1c5e 100644
> --- a/arch/arm/include/asm/arch-bcmcygnus/configs.h
> +++ b/arch/arm/include/asm/arch-bcmcygnus/configs.h
> @@ -1,5 +1,5 @@
> /*
> - * Copyright 2014 Broadcom Corporation.
> + * Copyright 2014-2017 Broadcom.
> *
> * SPDX-License-Identifier: GPL-2.0+
> */
> @@ -23,10 +23,6 @@
> #define CONFIG_SYS_NS16550_COM3 0x18023000
>
> /* Ethernet */
> -#define CONFIG_BCM_SF2_ETH
> -#define CONFIG_BCM_SF2_ETH_GMAC
> -
> -#define CONFIG_PHYLIB
> #define CONFIG_PHY_BROADCOM
> #define CONFIG_PHY_RESET_DELAY 10000 /* PHY reset delay in us*/
>
> diff --git a/configs/bcm28155_w1d_defconfig b/configs/bcm28155_w1d_defconfig
> index aa5216e..4adbce6 100644
> --- a/configs/bcm28155_w1d_defconfig
> +++ b/configs/bcm28155_w1d_defconfig
> @@ -1,7 +1,6 @@
> CONFIG_ARM=y
> CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK=y
> CONFIG_TARGET_BCM28155_AP=y
> -CONFIG_SYS_EXTRA_OPTIONS="BCM_SF2_ETH,BCM_SF2_ETH_GMAC"
> CONFIG_VERSION_VARIABLE=y
> # CONFIG_DISPLAY_CPUINFO is not set
> # CONFIG_DISPLAY_BOARDINFO is not set
> @@ -15,7 +14,6 @@ CONFIG_CMD_MMC=y
> CONFIG_CMD_I2C=y
> CONFIG_CMD_GPIO=y
> # CONFIG_CMD_SETEXPR is not set
> -# CONFIG_CMD_NET is not set
> # CONFIG_CMD_NFS is not set
> CONFIG_CMD_CACHE=y
> CONFIG_CMD_FAT=y
> @@ -33,3 +31,6 @@ CONFIG_USB_GADGET_DOWNLOAD=y
> CONFIG_G_DNL_MANUFACTURER="Broadcom Corporation"
> CONFIG_G_DNL_VENDOR_NUM=0x18d1
> CONFIG_G_DNL_PRODUCT_NUM=0x0d02
> +CONFIG_NETDEVICES=y
> +CONFIG_BCM_SF2_ETH=y
> +CONFIG_BCM_SF2_ETH_GMAC=y
> diff --git a/configs/bcm911360_entphn-ns_defconfig b/configs/bcm911360_entphn-ns_defconfig
> index adcc152..f1df78a 100644
> --- a/configs/bcm911360_entphn-ns_defconfig
> +++ b/configs/bcm911360_entphn-ns_defconfig
> @@ -19,3 +19,6 @@ CONFIG_CMD_TIME=y
> CONFIG_CMD_FAT=y
> CONFIG_SYS_NS16550=y
> CONFIG_OF_LIBFDT=y
> +CONFIG_NETDEVICES=y
> +CONFIG_BCM_SF2_ETH=y
> +CONFIG_BCM_SF2_ETH_GMAC=y
> diff --git a/configs/bcm911360_entphn_defconfig b/configs/bcm911360_entphn_defconfig
> index e49071d..22da69e 100644
> --- a/configs/bcm911360_entphn_defconfig
> +++ b/configs/bcm911360_entphn_defconfig
> @@ -19,3 +19,6 @@ CONFIG_CMD_TIME=y
> CONFIG_CMD_FAT=y
> CONFIG_SYS_NS16550=y
> CONFIG_OF_LIBFDT=y
> +CONFIG_NETDEVICES=y
> +CONFIG_BCM_SF2_ETH=y
> +CONFIG_BCM_SF2_ETH_GMAC=y
> diff --git a/configs/bcm911360k_defconfig b/configs/bcm911360k_defconfig
> index 8077c4a..0281fc8 100644
> --- a/configs/bcm911360k_defconfig
> +++ b/configs/bcm911360k_defconfig
> @@ -19,3 +19,6 @@ CONFIG_CMD_TIME=y
> CONFIG_CMD_FAT=y
> CONFIG_SYS_NS16550=y
> CONFIG_OF_LIBFDT=y
> +CONFIG_NETDEVICES=y
> +CONFIG_BCM_SF2_ETH=y
> +CONFIG_BCM_SF2_ETH_GMAC=y
> diff --git a/configs/bcm958300k-ns_defconfig b/configs/bcm958300k-ns_defconfig
> index 26d0b0b..c837721 100644
> --- a/configs/bcm958300k-ns_defconfig
> +++ b/configs/bcm958300k-ns_defconfig
> @@ -19,3 +19,6 @@ CONFIG_CMD_TIME=y
> CONFIG_CMD_FAT=y
> CONFIG_SYS_NS16550=y
> CONFIG_OF_LIBFDT=y
> +CONFIG_NETDEVICES=y
> +CONFIG_BCM_SF2_ETH=y
> +CONFIG_BCM_SF2_ETH_GMAC=y
> diff --git a/configs/bcm958300k_defconfig b/configs/bcm958300k_defconfig
> index 8077c4a..0281fc8 100644
> --- a/configs/bcm958300k_defconfig
> +++ b/configs/bcm958300k_defconfig
> @@ -19,3 +19,6 @@ CONFIG_CMD_TIME=y
> CONFIG_CMD_FAT=y
> CONFIG_SYS_NS16550=y
> CONFIG_OF_LIBFDT=y
> +CONFIG_NETDEVICES=y
> +CONFIG_BCM_SF2_ETH=y
> +CONFIG_BCM_SF2_ETH_GMAC=y
> diff --git a/configs/bcm958305k_defconfig b/configs/bcm958305k_defconfig
> index 8077c4a..0281fc8 100644
> --- a/configs/bcm958305k_defconfig
> +++ b/configs/bcm958305k_defconfig
> @@ -19,3 +19,6 @@ CONFIG_CMD_TIME=y
> CONFIG_CMD_FAT=y
> CONFIG_SYS_NS16550=y
> CONFIG_OF_LIBFDT=y
> +CONFIG_NETDEVICES=y
> +CONFIG_BCM_SF2_ETH=y
> +CONFIG_BCM_SF2_ETH_GMAC=y
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 70e3661..34c4f23 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -40,6 +40,21 @@ config ALTERA_TSE
> Please find details on the "Triple-Speed Ethernet MegaCore Function
> Resource Center" of Altera.
>
> +config BCM_SF2_ETH
> + bool "Broadcom SF2 (Starfighter2) Ethernet support"
> + select PHYLIB
> + help
> + This driver provides a MAC and DMA abstraction framework to
> + support multiple Broadcom SoCs.
> +
> +config BCM_SF2_ETH_GMAC
> + bool "Broadcom SF2 (Starfighter2) GMAC Ethernet support"
> + depends on BCM_SF2_ETH
> + help
> + This driver provides support to ethernet for bcmcygnus specific
Odd that the config doesn't include "cygnus" in it if that's what it applies to.
> + based platforms only and it is based on the framework provided
> + by the Starfighter2 driver.
> +
> config DWC_ETH_QOS
> bool "Synopsys DWC Ethernet QOS device support"
> depends on DM_ETH
> diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
> index f6c9101..21ece38 100644
> --- a/scripts/config_whitelist.txt
> +++ b/scripts/config_whitelist.txt
> @@ -250,9 +250,7 @@ CONFIG_BCH_CONST_PARAMS
> CONFIG_BCH_CONST_T
> CONFIG_BCM2835_GPIO
> CONFIG_BCM283X_MU_SERIAL
> -CONFIG_BCM_SF2_ETH
> CONFIG_BCM_SF2_ETH_DEFAULT_PORT
Any reason not to move this along with the driver enable?
> -CONFIG_BCM_SF2_ETH_GMAC
> CONFIG_BD_NUM_CPUS
> CONFIG_BF506_UART0_PORTF
> CONFIG_BF506_UART1_PORTG
> --
> 2.7.4
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/listinfo/u-boot
^ permalink raw reply
* Re: [PATCH v2 08/16] for-each-ref: partly change <object> to <commit> in help
From: Ævar Arnfjörð Bjarmason @ 2017-03-21 18:50 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Lars Hjemli, Jeff King, Christian Couder,
Carlos Rica, Samuel Tardieu, Tom Grennan, Karthik Nayak
In-Reply-To: <xmqqwpbipjk9.fsf@gitster.mtv.corp.google.com>
On Tue, Mar 21, 2017 at 7:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> Change mentions of <object> to <commit> in the help output of
>> for-each-ref as appropriate.
>>
>> Both --[no-]merged and --contains only take commits, but --points-at
>> can take any object, such as a tag pointing to a tree or blob.
>>
>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>> ---
>
> This definitely is a correction worth doing.
>
> Do these strictly require commit, or does any commit-ish also do?
commit-ish, but that's a good point, and could be the subject of a
future follow-up patch. Right now most of the things that say <commit>
really mean <commit-ish>:
$ git grep '<commit>' -- builtin|wc -l
18
$ git grep '<commit.*ish>' -- builtin|wc -l
3
>> builtin/for-each-ref.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
>> index df41fa0350..1a5ed20f59 100644
>> --- a/builtin/for-each-ref.c
>> +++ b/builtin/for-each-ref.c
>> @@ -8,8 +8,8 @@
>> static char const * const for_each_ref_usage[] = {
>> N_("git for-each-ref [<options>] [<pattern>]"),
>> N_("git for-each-ref [--points-at <object>]"),
>> - N_("git for-each-ref [(--merged | --no-merged) [<object>]]"),
>> - N_("git for-each-ref [--contains [<object>]]"),
>> + N_("git for-each-ref [(--merged | --no-merged) [<commit>]]"),
>> + N_("git for-each-ref [--contains [<commit>]]"),
>> NULL
>> };
^ permalink raw reply
* [PATCH 12/14] arm64: kill acpi_set_mailbox_entry()
From: Mark Rutland @ 2017-03-21 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170321183755.GA2976@red-moon>
On Tue, Mar 21, 2017 at 06:37:55PM +0000, Lorenzo Pieralisi wrote:
> On Tue, Mar 21, 2017 at 06:15:54PM +0000, Mark Rutland wrote:
> > On Tue, Mar 21, 2017 at 06:00:40PM +0000, Lorenzo Pieralisi wrote:
> > > On Fri, Mar 10, 2017 at 11:04:49AM +0000, Mark Rutland wrote:
> >
> > > > +static struct parking_protocol_mailbox __iomem *mailboxes[NR_CPUS];
> > >
> > > Nit: If I am not mistaken it can be made a percpu pointer.
> >
> > Unfortunately, we don't set up the percpu areas until we know how many
> > CPUs are possible (i.e. after we've parsed the MADT).
> >
> > The flow looks like:
> >
> > start_kernel()
> > setup_arch()
> > smp_init_cpus()
> > acpi_table_parse_madt()
> > acpi_parse_gic_cpu_interface()
> > acpi_map_gic_cpu_interface() // setup cpu mailbox here
>
> The mailbox data yes, not the pointer at which it is mapped (which
> is what gets stashed in mailboxes[]).
Sorry, I got myself confused here between this and the MADT GICC
stashing to which the above does apply.
You are correct that this can and should be a percpu pointer.
I'll fix this up. I just need to figure out where the __iomem attribute
is supposed to live on a percpu definition.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH v2 13/16] ref-filter: add --no-contains option to tag/branch/for-each-ref
From: Junio C Hamano @ 2017-03-21 18:51 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Lars Hjemli, Jeff King, Christian Couder, Carlos Rica,
Samuel Tardieu, Tom Grennan, Karthik Nayak
In-Reply-To: <20170321125901.10652-14-avarab@gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> Change the tag, branch & for-each-ref commands to have a --no-contains
> option in addition to their longstanding --contains options.
>
> This allows for finding the last-good rollout tag given a known-bad
> <commit>. Given a hypothetically bad commit cf5c7253e0, the git
> version to revert to can be found with this hacky two-liner:
>
> (git tag -l 'v[0-9]*'; git tag -l --contains cf5c7253e0 'v[0-9]*') |
> sort | uniq -c | grep -E '^ *1 ' | awk '{print $2}' | tail -n 10
>
> With this new --no-contains option the same can be achieved with:
>
> git tag -l --no-contains cf5c7253e0 'v[0-9]*' | sort | tail -n 10
>
> As the filtering machinery is shared between the tag, branch &
> for-each-ref commands, implement this for those commands too. A
> practical use for this with "branch" is e.g. finding branches which
> were branched off between v2.8.0 and v2.10.0:
>
> git branch --contains v2.8.0 --no-contains v2.10.0
>
> The "describe" command also has a --contains option, but its semantics
> are unrelated to what tag/branch/for-each-ref use --contains for. A
> --no-contains option for "describe" wouldn't make any sense, other
> than being exactly equivalent to not supplying --contains at all,
> which would be confusing at best.
Nicely explained. Thanks.
> diff --git a/parse-options.h b/parse-options.h
> index dcd8a0926c..0eac90b510 100644
> --- a/parse-options.h
> +++ b/parse-options.h
> @@ -258,7 +258,9 @@ extern int parse_opt_passthru_argv(const struct option *, const char *, int);
> PARSE_OPT_LASTARG_DEFAULT | flag, \
> parse_opt_commits, (intptr_t) "HEAD" \
> }
> -#define OPT_CONTAINS(v, h) _OPT_CONTAINS_OR_WITH("contains", v, h, 0)
> +#define OPT_CONTAINS(v, h) _OPT_CONTAINS_OR_WITH("contains", v, h, PARSE_OPT_NONEG)
> +#define OPT_NO_CONTAINS(v, h) _OPT_CONTAINS_OR_WITH("no-contains", v, h, PARSE_OPT_NONEG)
> #define OPT_WITH(v, h) _OPT_CONTAINS_OR_WITH("with", v, h, PARSE_OPT_HIDDEN)
> +#define OPT_WITHOUT(v, h) _OPT_CONTAINS_OR_WITH("without", v, h, PARSE_OPT_HIDDEN)
Doesn't OPT_WITHOUT() need PARSE_OPT_NONEG (in addition to HIDDEN),
just like OPT_NO_CONTAINS() uses one to reject "--no-no-contains"?
Does the code do a sensible thing when --no-without is given?
^ permalink raw reply
* [PATCH] builtin/describe: introduce --broken flag
From: Stefan Beller @ 2017-03-21 18:51 UTC (permalink / raw)
To: gitster; +Cc: git, jrnieder, mfick, Stefan Beller
In-Reply-To: <xmqq37e7t902.fsf@gitster.mtv.corp.google.com>
git-describe tells you the version number you're at, or errors out, e.g.
when you run it outside of a repository, which may happen when downloading
a tar ball instead of using git to obtain the source code.
To keep this property of only erroring out, when not in a repository,
severe (submodule) errors must be downgraded to reporting them gently
instead of having git-describe error out completely.
To achieve that a flag '--broken' is introduced, which is in the same
vein as '--dirty' but uses an actual child process to check for dirtiness.
When that child dies unexpectedly, we'll append '-broken' instead of
'-dirty'.
This patch helps to fix the root cause in [1], which tries to work around
this situation.
[1] ("Work around git describe bug for build.")
https://gerrit-review.googlesource.com/#/c/99851/
Signed-off-by: Stefan Beller <sbeller@google.com>
---
> I probably would
>
> - introduce a new "git describe --possibly-broken" option;
>
> - instead of running "diff-index" internally to decide the "-dirty"
> state, spawn "diff-index" as a separate process;
>
> - observe the exit status from "diff-index" and add "-dirty" suffix
This is what this patch does. It doesn't need any preceeding refactor
patches, but comes on its own; developed on origin/master.
Thanks,
Stefan
Documentation/git-describe.txt | 7 +++++
builtin/describe.c | 59 ++++++++++++++++++++++++++++++------------
t/t6120-describe.sh | 20 ++++++++++++++
3 files changed, 70 insertions(+), 16 deletions(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index 8755f3af7b..b71fa7a4ad 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -34,6 +34,13 @@ OPTIONS
It means describe HEAD and appends <mark> (`-dirty` by
default) if the working tree is dirty.
+--broken[=<mark>]::
+ Describe the working tree.
+ It means describe HEAD and appends <mark> (`-broken` by
+ default) if the working tree cannot be examined for dirtiness.
+ This implies `--dirty`, which is the fallback behavior when
+ the working tree examination works.
+
--all::
Instead of using only the annotated tags, use any ref
found in `refs/` namespace. This option enables matching
diff --git a/builtin/describe.c b/builtin/describe.c
index 76c18059bf..37a83520c9 100644
--- a/builtin/describe.c
+++ b/builtin/describe.c
@@ -9,6 +9,7 @@
#include "diff.h"
#include "hashmap.h"
#include "argv-array.h"
+#include "run-command.h"
#define SEEN (1u << 0)
#define MAX_TAGS (FLAG_BITS - 1)
@@ -31,12 +32,7 @@ static int have_util;
static struct string_list patterns = STRING_LIST_INIT_NODUP;
static struct string_list exclude_patterns = STRING_LIST_INIT_NODUP;
static int always;
-static const char *dirty;
-
-/* diff-index command arguments to check if working tree is dirty. */
-static const char *diff_index_args[] = {
- "diff-index", "--quiet", "HEAD", "--", NULL
-};
+static const char *append, *dirty, *broken;
struct commit_name {
struct hashmap_entry entry;
@@ -292,8 +288,8 @@ static void describe(const char *arg, int last_one)
display_name(n);
if (longformat)
show_suffix(0, n->tag ? &n->tag->tagged->oid : &oid);
- if (dirty)
- printf("%s", dirty);
+ if (append)
+ printf("%s", append);
printf("\n");
return;
}
@@ -369,8 +365,8 @@ static void describe(const char *arg, int last_one)
struct object_id *oid = &cmit->object.oid;
if (always) {
printf("%s", find_unique_abbrev(oid->hash, abbrev));
- if (dirty)
- printf("%s", dirty);
+ if (append)
+ printf("%s", append);
printf("\n");
return;
}
@@ -413,8 +409,8 @@ static void describe(const char *arg, int last_one)
display_name(all_matches[0].name);
if (abbrev)
show_suffix(all_matches[0].depth, &cmit->object.oid);
- if (dirty)
- printf("%s", dirty);
+ if (append)
+ printf("%s", append);
printf("\n");
if (!last_one)
@@ -445,6 +441,9 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
{OPTION_STRING, 0, "dirty", &dirty, N_("mark"),
N_("append <mark> on dirty working tree (default: \"-dirty\")"),
PARSE_OPT_OPTARG, NULL, (intptr_t) "-dirty"},
+ {OPTION_STRING, 0, "broken", &broken, N_("mark"),
+ N_("append <mark> on broken working tree (default: \"-broken\")"),
+ PARSE_OPT_OPTARG, NULL, (intptr_t) "-broken"},
OPT_END(),
};
@@ -493,10 +492,35 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
die(_("No names found, cannot describe anything."));
if (argc == 0) {
- if (dirty) {
+ if (broken) {
+ struct child_process cp = CHILD_PROCESS_INIT;
+ argv_array_pushl(&cp.args, "diff-index", "--quiet", "HEAD", "--", NULL);
+ cp.git_cmd = 1;
+ cp.no_stdin = 1;
+ cp.no_stdout = 1;
+
+ if (!dirty)
+ dirty = "-dirty";
+
+ switch (run_command(&cp)) {
+ case 0:
+ append = NULL;
+ break;
+ case 1:
+ /* keep dirty as is */
+ append = dirty;
+ break;
+ default:
+ /* diff-index aborted abnormally */
+ append = broken;
+ }
+ } else if (dirty) {
+ struct argv_array args = ARGV_ARRAY_INIT;
static struct lock_file index_lock;
int fd;
+ argv_array_pushl(&args, "diff-index", "--quiet", "HEAD", "--", NULL);
+
read_cache_preload(NULL);
refresh_index(&the_index, REFRESH_QUIET|REFRESH_UNMERGED,
NULL, NULL, NULL);
@@ -504,13 +528,16 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
if (0 <= fd)
update_index_if_able(&the_index, &index_lock);
- if (!cmd_diff_index(ARRAY_SIZE(diff_index_args) - 1,
- diff_index_args, prefix))
- dirty = NULL;
+ if (cmd_diff_index(args.argc, args.argv, prefix))
+ append = dirty;
+ else
+ append = NULL;
}
describe("HEAD", 1);
} else if (dirty) {
die(_("--dirty is incompatible with commit-ishes"));
+ } else if (broken) {
+ die(_("--broken is incompatible with commit-ishes"));
} else {
while (argc-- > 0)
describe(*argv++, argc == 0);
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index 167491fd5b..16952e44fc 100755
--- a/t/t6120-describe.sh
+++ b/t/t6120-describe.sh
@@ -233,4 +233,24 @@ test_expect_success 'describe --contains and --no-match' '
test_cmp expect actual
'
+test_expect_success 'setup and absorb a submodule' '
+ test_create_repo sub1 &&
+ test_commit -C sub1 initial &&
+ git submodule add ./sub1 &&
+ git submodule absorbgitdirs &&
+ git commit -a -m "add submodule" &&
+ git describe --dirty >expect &&
+ git describe --broken >out &&
+ test_cmp expect out
+'
+
+test_expect_success 'describe chokes on severly broken submodules' '
+ mv .git/modules/sub1/ .git/modules/sub_moved &&
+ test_must_fail git describe --dirty
+'
+test_expect_success 'describe ignoring a borken submodule' '
+ git describe --broken >out &&
+ grep broken out
+'
+
test_done
--
2.12.0.402.g0501f7a28e.dirty
^ permalink raw reply related
* [U-Boot] [PATCH] ARM: keystone: Pass SPI MTD partition table via kernel command line
From: Franklin S Cooper Jr @ 2017-03-21 18:52 UTC (permalink / raw)
To: u-boot
In-Reply-To: <00eaf68a-5f3d-6eb6-7d7f-a246951abdac@ti.com>
On 03/20/2017 11:57 PM, Vignesh R wrote:
>
>
> On Saturday 18 March 2017 08:04 PM, Tom Rini wrote:
>>>> And can we not move towards the "normal" method of SPL loading
>>>> the u-boot.img (or FIT) from? I guess the current architecture here is
>>>> confusing me.
>>> This has been same for all k2 platforms. I guess we have single image so
>>> that user don't have to bother flashing multiple images for spi boot
>>> given the fact that all other boot modes have single image.
>>>
>>>> Regardless, I still see the DT problem as the bigger one long term, and
>>>> dra7xx shows that. And I agree we need to re-size how the flash is
>>>> partitioned.
>>> True.
>> The next question is, given that Franklin is talking about being able to
>> load the right DTB for any K2 platform basically, is the layout in
>> https://patchwork.ozlabs.org/patch/736498/ really looking like it will
>> be enough?
>>
>
> I will leave Franklin to comment here. I dont think he has plans to do
> changes for all K2 platforms (I guess his plans are mostly limited to K2G)
I'm not sure if there is any real solution other than providing a
generous amount of storage for U-boot in the flash memory. I don't think
atleast within our TI SDK use cases we even use the misc partition. So I
don't see a reason why we couldn't give U-boot's partition 3 or 4 MB of
space.
Also has there been any thoughts of compressing dtbs? These dtbs are
relatively massive and compressed they are around 1/5 the size.
Personally I'm not a fan of U-boot performing all these fix ups before
passing things to the kernel. It forces so much coupling between
bootloader versions and kernel. And things become more painful when
changes in the kernel causes U-boot fix ups to break.
>
^ permalink raw reply
* Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()
From: hpa @ 2017-03-21 18:51 UTC (permalink / raw)
To: Cyrill Gorcunov, Dmitry Safonov
Cc: Andy Lutomirski, linux-kernel@vger.kernel.org, Dmitry Safonov,
Adam Borowski, linux-mm@kvack.org, Andrei Vagin, Borislav Petkov,
Kirill A. Shutemov, X86 ML, Andy Lutomirski, Ingo Molnar,
Thomas Gleixner
In-Reply-To: <20170321184058.GD21564@uranus.lan>
On March 21, 2017 11:40:58 AM PDT, Cyrill Gorcunov <gorcunov@gmail.com> wrote:
>On Tue, Mar 21, 2017 at 09:09:40PM +0300, Dmitry Safonov wrote:
>>
>> I guess the question comes from that we're releasing CRIU 3.0 with
>> 32-bit C/R and some other cool stuff, but we don't support x32 yet.
>> As we don't want release a thing that we aren't properly testing.
>> So for a while we should error on dumping x32 applications.
>
>yes
>
>> I think, the best way for now is to check physicall address of vdso
>> from /proc/.../pagemap. If it's CONFIG_VDSO=n kernel, I guess we
>could
>> also add check for %ds from ptrace's register set. For x32 it's set
>to
>> __USER_DS, while for native it's 0 (looking at start_thread() and
>> compat_start_thread()). The application can simply change it without
>> any consequence - so it's not very reliable, we could only warn at
>> catching it, not rely on this.
>
>indeed, thanks!
I proposed to the ptrace people a virtual register for this and a few other things, but it got bikeshed to death.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.