* [GIT PULL 1/3] ARM: dts: exynos: DT for v4.10
From: Krzysztof Kozlowski @ 2016-11-08 18:26 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, Kevin Hilman, arm
Cc: Krzysztof Kozlowski, Kukjin Kim, linux-arm-kernel,
linux-samsung-soc, linux-kernel, Javier Martinez Canillas
In-Reply-To: <1478629589-7520-1-git-send-email-krzk@kernel.org>
Hi,
Hurray! New board! ... Exynos4415 slowly is going away.
Best regards,
Krzysztof
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-4.10
for you to fetch changes up to 05a3589f46f913fbe91704f12fdca46a0eb0a27b:
ARM: dts: exynos: Add SCU device node to exynos4.dtsi (2016-11-05 17:39:50 +0200)
----------------------------------------------------------------
Samsung DeviceTree update for v4.10:
1. Add TOPEET itop core and Elite boards, based on Exynos4412.
2. Remove the Exynos4415 DTSI. We did not have any mainlined boards
using it. I am also not aware of any popular out-of-tree boards using it.
3. Add Snoop Control Unit node for Exynos4.
4. Minor cleanups.
----------------------------------------------------------------
Javier Martinez Canillas (1):
ARM: dts: exynos: Document eMMC/SD/SDIO devices in Snow and Peach boards
Krzysztof Kozlowski (1):
ARM: dts: exynos: Remove exynos4415.dtsi
Pankaj Dubey (1):
ARM: dts: exynos: Add SCU device node to exynos4.dtsi
Randy Li (2):
ARM: dts: exynos: Add TOPEET itop core board SCP package version
ARM: dts: exynos: Add TOPEET itop elite based board
Sylwester Nawrocki (2):
ARM: dts: exynos: Remove "simple-bus" compatible from fimc-is node
ARM: dts: exynos: Add entries for sound support on Odroid-XU board
.../bindings/arm/samsung/samsung-boards.txt | 3 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/exynos4.dtsi | 5 +
arch/arm/boot/dts/exynos4412-itop-elite.dts | 240 ++++++++
arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi | 501 ++++++++++++++++
arch/arm/boot/dts/exynos4415-pinctrl.dtsi | 575 ------------------
arch/arm/boot/dts/exynos4415.dtsi | 650 ---------------------
arch/arm/boot/dts/exynos4x12.dtsi | 2 +-
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 +
arch/arm/boot/dts/exynos5410-odroidxu.dts | 69 +++
arch/arm/boot/dts/exynos5410-pinctrl.dtsi | 9 +
arch/arm/boot/dts/exynos5410.dtsi | 59 ++
arch/arm/boot/dts/exynos5420-peach-pit.dts | 3 +
arch/arm/boot/dts/exynos5800-peach-pi.dts | 3 +
14 files changed, 898 insertions(+), 1226 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4412-itop-elite.dts
create mode 100644 arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
delete mode 100644 arch/arm/boot/dts/exynos4415-pinctrl.dtsi
delete mode 100644 arch/arm/boot/dts/exynos4415.dtsi
^ permalink raw reply
* [GIT PULL 2/3] ARM64: dts: exynos: DT for v4.10
From: Krzysztof Kozlowski @ 2016-11-08 18:26 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, Kevin Hilman, arm
Cc: Krzysztof Kozlowski, Kukjin Kim, linux-arm-kernel,
linux-samsung-soc, linux-kernel, Javier Martinez Canillas
In-Reply-To: <1478629589-7520-1-git-send-email-krzk@kernel.org>
Hi,
Exynos5433 + two boards using it. Mobile boards! :)
I am really happy to push it. I know that it has been a lot of effort
in Samsung to mainline this.
Best regards,
Krzysztof
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-4.10
for you to fetch changes up to 8ac46fc57df82efbc19194dddd335b6c7a960c31:
arm64: dts: exynos: Add dts file for Exynos5433-based TM2E board (2016-11-03 22:19:57 +0200)
----------------------------------------------------------------
Finally, I am really pleased to announce adding support for Exynos5433 ARMv8
SoC along with two boards. A lot of Samsung people contributed into this
but the final work and commits were done by Chanwoo Choi.
This means that for v4.10 we got:
1. Exynos5433 DTSI.
2. Two boards: TM2 and TM2E. These are (almost fully) working mobile phones.
----------------------------------------------------------------
Chanwoo Choi (3):
arm64: dts: exynos: Add dtsi files for Samsung Exynos5433 64bit SoC
arm64: dts: exynos: Add dts file for Exynos5433-based TM2 board
arm64: dts: exynos: Add dts file for Exynos5433-based TM2E board
.../bindings/arm/samsung/samsung-boards.txt | 2 +
arch/arm64/boot/dts/exynos/Makefile | 5 +-
arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 794 ++++++++++++
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 974 ++++++++++++++
arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 41 +
.../dts/exynos/exynos5433-tmu-g3d-sensor-conf.dtsi | 23 +
.../dts/exynos/exynos5433-tmu-sensor-conf.dtsi | 22 +
arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi | 296 +++++
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 1356 ++++++++++++++++++++
9 files changed, 3512 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tmu-g3d-sensor-conf.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tmu-sensor-conf.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433.dtsi
^ permalink raw reply
* Re: [PATCH] perf/x86: Fix overlap counter scheduling bug
From: Peter Zijlstra @ 2016-11-08 18:27 UTC (permalink / raw)
To: Liang, Kan
Cc: Andi Kleen, Jiri Olsa, Vince Weaver, Robert Richter, lkml,
Ingo Molnar
In-Reply-To: <37D7C6CF3E00A74B8858931C1DB2F07750C8DA4F@SHSMSX103.ccr.corp.intel.com>
On Tue, Nov 08, 2016 at 05:25:34PM +0000, Liang, Kan wrote:
> > I think all the 0x3 mask need the overlap flag set, since they clearly overlap
> > with the 0x1 masks. That would improve the scheduling.
> >
>
> How much the overlap hint can improve the scheduling?
> Because there is not only snbep_uncore_cbox, but also other uncore events
> which have overlapping masks.
Hurm, not much. We're saved by the fact that we schedule from wwin to
wmax, which means that we first place the 0x01 events, and then try and
fit the 0x03 events on top. That should already be good.
/me ponders more..
The comment with EVENT_CONSTRAINT_OVERLAP states: "This is the case if
the counter mask of such an event is not a subset of any other counter
mask of a constraint with an equal or higher weight".
Esp. that latter part is of interest here I think, our overlapping mask
is 0x0e, that has 3 bits set and is the highest weight mask in on the
PMU, therefore it will be placed last. Can we still create a scenario
where we would need to rewind that?
The scenario for AMD Fam15h is we're having masks like:
0x3F -- 111111
0x38 -- 111000
0x07 -- 000111
0x09 -- 001001
And we mark 0x09 as overlapping, because it is not a direct subset of
0x38 or 0x07 and has less weight than either of those. This means we'll
first try and place the 0x09 event, then try and place 0x38/0x07 events.
Now imagine we have:
3 * 0x07 + 0x09
and the initial pick for the 0x09 event is counter 0, then we'll fail to
place all 0x07 events. So we'll pop back, try counter 4 for the 0x09
event, and then re-try all 0x07 events, which will now work.
But given, that in the uncore case, the overlapping event is the
heaviest mask, I don't think this can happen. Or did I overlook
something.... takes a bit to page all this back in.
^ permalink raw reply
* Re: [PATCH kernel v4 7/7] virtio-balloon: tell host vm's unused page info
From: Dave Hansen @ 2016-11-08 18:30 UTC (permalink / raw)
To: Li, Liang Z, mst@redhat.com
Cc: virtio-dev@lists.oasis-open.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, qemu-devel@nongnu.org,
dgilbert@redhat.com, linux-mm@kvack.org, amit.shah@redhat.com,
pbonzini@redhat.com, virtualization@lists.linux-foundation.org,
mgorman@techsingularity.net
In-Reply-To: <F2CBF3009FA73547804AE4C663CAB28E3A108196@shsmsx102.ccr.corp.intel.com>
On 11/07/2016 09:50 PM, Li, Liang Z wrote:
> Sounds good. Should we ignore some of the order-0 pages in step 4 if the bitmap is full?
> Or should retry to get a complete list of order-0 pages?
I think that's a pretty reasonable thing to do.
>>> It seems the benefit we get for this feature is not as big as that in fast
>> balloon inflating/deflating.
>>>>
>>>> You should not be using get_max_pfn(). Any patch set that continues
>>>> to use it is not likely to be using a proper algorithm.
>>>
>>> Do you have any suggestion about how to avoid it?
>>
>> Yes: get the pfns from the page free lists alone. Don't derive
>> them from the pfn limits of the system or zones.
>
> The ' get_max_pfn()' can be avoid in this patch, but I think we can't
> avoid it completely. We need it as a hint for allocating a proper
> size bitmap. No?
If you start with higher-order pages, you'll be unlikely to get anywhere
close to filling up a bitmap that was sized to hold all possible order-0
pages on the system. Any use of max_pfn also means that you'll
completely mis-size bitmaps on sparse systems with large holes.
I think you should size it based on the size of the free lists, if anything.
^ permalink raw reply
* Re: [PATCH kernel v4 7/7] virtio-balloon: tell host vm's unused page info
From: Dave Hansen @ 2016-11-08 18:30 UTC (permalink / raw)
To: Li, Liang Z, mst@redhat.com
Cc: pbonzini@redhat.com, amit.shah@redhat.com, quintela@redhat.com,
dgilbert@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org,
virtio-dev@lists.oasis-open.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
mgorman@techsingularity.net, cornelia.huck@de.ibm.com
In-Reply-To: <F2CBF3009FA73547804AE4C663CAB28E3A108196@shsmsx102.ccr.corp.intel.com>
On 11/07/2016 09:50 PM, Li, Liang Z wrote:
> Sounds good. Should we ignore some of the order-0 pages in step 4 if the bitmap is full?
> Or should retry to get a complete list of order-0 pages?
I think that's a pretty reasonable thing to do.
>>> It seems the benefit we get for this feature is not as big as that in fast
>> balloon inflating/deflating.
>>>>
>>>> You should not be using get_max_pfn(). Any patch set that continues
>>>> to use it is not likely to be using a proper algorithm.
>>>
>>> Do you have any suggestion about how to avoid it?
>>
>> Yes: get the pfns from the page free lists alone. Don't derive
>> them from the pfn limits of the system or zones.
>
> The ' get_max_pfn()' can be avoid in this patch, but I think we can't
> avoid it completely. We need it as a hint for allocating a proper
> size bitmap. No?
If you start with higher-order pages, you'll be unlikely to get anywhere
close to filling up a bitmap that was sized to hold all possible order-0
pages on the system. Any use of max_pfn also means that you'll
completely mis-size bitmaps on sparse systems with large holes.
I think you should size it based on the size of the free lists, if anything.
^ permalink raw reply
* Re: [PATCH kernel v4 7/7] virtio-balloon: tell host vm's unused page info
From: Dave Hansen @ 2016-11-08 18:30 UTC (permalink / raw)
To: Li, Liang Z, mst@redhat.com
Cc: pbonzini@redhat.com, amit.shah@redhat.com, quintela@redhat.com,
dgilbert@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org,
virtio-dev@lists.oasis-open.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
mgorman@techsingularity.net, cornelia.huck@de.ibm.com
In-Reply-To: <F2CBF3009FA73547804AE4C663CAB28E3A108196@shsmsx102.ccr.corp.intel.com>
On 11/07/2016 09:50 PM, Li, Liang Z wrote:
> Sounds good. Should we ignore some of the order-0 pages in step 4 if the bitmap is full?
> Or should retry to get a complete list of order-0 pages?
I think that's a pretty reasonable thing to do.
>>> It seems the benefit we get for this feature is not as big as that in fast
>> balloon inflating/deflating.
>>>>
>>>> You should not be using get_max_pfn(). Any patch set that continues
>>>> to use it is not likely to be using a proper algorithm.
>>>
>>> Do you have any suggestion about how to avoid it?
>>
>> Yes: get the pfns from the page free lists alone. Don't derive
>> them from the pfn limits of the system or zones.
>
> The ' get_max_pfn()' can be avoid in this patch, but I think we can't
> avoid it completely. We need it as a hint for allocating a proper
> size bitmap. No?
If you start with higher-order pages, you'll be unlikely to get anywhere
close to filling up a bitmap that was sized to hold all possible order-0
pages on the system. Any use of max_pfn also means that you'll
completely mis-size bitmaps on sparse systems with large holes.
I think you should size it based on the size of the free lists, if anything.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH kernel v4 7/7] virtio-balloon: tell host vm's unused page info
From: Dave Hansen @ 2016-11-08 18:30 UTC (permalink / raw)
To: Li, Liang Z, mst@redhat.com
Cc: pbonzini@redhat.com, amit.shah@redhat.com, quintela@redhat.com,
dgilbert@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org,
virtio-dev@lists.oasis-open.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
mgorman@techsingularity.net, cornelia.huck@de.ibm.com
In-Reply-To: <F2CBF3009FA73547804AE4C663CAB28E3A108196@shsmsx102.ccr.corp.intel.com>
On 11/07/2016 09:50 PM, Li, Liang Z wrote:
> Sounds good. Should we ignore some of the order-0 pages in step 4 if the bitmap is full?
> Or should retry to get a complete list of order-0 pages?
I think that's a pretty reasonable thing to do.
>>> It seems the benefit we get for this feature is not as big as that in fast
>> balloon inflating/deflating.
>>>>
>>>> You should not be using get_max_pfn(). Any patch set that continues
>>>> to use it is not likely to be using a proper algorithm.
>>>
>>> Do you have any suggestion about how to avoid it?
>>
>> Yes: get the pfns from the page free lists alone. Don't derive
>> them from the pfn limits of the system or zones.
>
> The ' get_max_pfn()' can be avoid in this patch, but I think we can't
> avoid it completely. We need it as a hint for allocating a proper
> size bitmap. No?
If you start with higher-order pages, you'll be unlikely to get anywhere
close to filling up a bitmap that was sized to hold all possible order-0
pages on the system. Any use of max_pfn also means that you'll
completely mis-size bitmaps on sparse systems with large holes.
I think you should size it based on the size of the free lists, if anything.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 5/6] blockjob: refactor backup_start as backup_job_create
From: Jeff Cody @ 2016-11-08 18:30 UTC (permalink / raw)
To: John Snow
Cc: Kevin Wolf, vsementsov, qemu-block, qemu-devel, stefanha,
pbonzini
In-Reply-To: <73cec3f4-72aa-3007-e33f-36552b75ff26@redhat.com>
On Tue, Nov 08, 2016 at 10:24:50AM -0500, John Snow wrote:
>
>
> On 11/08/2016 04:11 AM, Kevin Wolf wrote:
> >Am 08.11.2016 um 06:41 hat John Snow geschrieben:
> >>On 11/03/2016 09:17 AM, Kevin Wolf wrote:
> >>>Am 02.11.2016 um 18:50 hat John Snow geschrieben:
> >>>>Refactor backup_start as backup_job_create, which only creates the job,
> >>>>but does not automatically start it. The old interface, 'backup_start',
> >>>>is not kept in favor of limiting the number of nearly-identical interfaces
> >>>>that would have to be edited to keep up with QAPI changes in the future.
> >>>>
> >>>>Callers that wish to synchronously start the backup_block_job can
> >>>>instead just call block_job_start immediately after calling
> >>>>backup_job_create.
> >>>>
> >>>>Transactions are updated to use the new interface, calling block_job_start
> >>>>only during the .commit phase, which helps prevent race conditions where
> >>>>jobs may finish before we even finish building the transaction. This may
> >>>>happen, for instance, during empty block backup jobs.
> >>>>
> >>>>Reported-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> >>>>Signed-off-by: John Snow <jsnow@redhat.com>
> >>>
> >>>>+static void drive_backup_commit(BlkActionState *common)
> >>>>+{
> >>>>+ DriveBackupState *state = DO_UPCAST(DriveBackupState, common, common);
> >>>>+ if (state->job) {
> >>>>+ block_job_start(state->job);
> >>>>+ }
> >>>>}
> >>>
> >>>How could state->job ever be NULL?
> >>>
> >>
> >>Mechanical thinking. It can't. (I definitely didn't copy paste from
> >>the .abort routines. Definitely.)
> >>
> >>>Same question for abort, and for blockdev_backup_commit/abort.
> >>>
> >>
> >>Abort ... we may not have created the job successfully. Abort gets
> >>called whether or not we made it to or through the matching
> >>.prepare.
> >
> >Ah, yes, I always forget about this. It's so counterintuitive (and
> >bdrv_reopen() actually works differently, it only aborts entries that
> >have successfully been prepared).
> >
> >Is there a good reason why qmp_transaction() works this way, especially
> >since we have a separate .clean function?
> >
> >Kevin
> >
>
> We just don't track which actions have succeeded or not, so we loop through
> all actions on each phase regardless.
>
> I could add a little state enumeration (or boolean) to each action and I
> could adjust abort to only run on actions that either completed or failed,
> but in this case I think it still wouldn't change the text for .abort,
> because an action may fail before it got to creating the job, for instance.
>
As far as this part goes, couldn't we just do it without any flags, by not
inserting the state into the snap_bdrv_states list unless it was successful
(assuming _prepare cleans up itself on failure)? E.g.:
- QSIMPLEQ_INSERT_TAIL(&snap_bdrv_states, state, entry);
state->ops->prepare(state, &local_err);
if (local_err) {
error_propagate(errp, local_err);
+ g_free(state);
goto delete_and_fail;
}
+ QSIMPLEQ_INSERT_TAIL(&snap_bdrv_states, state, entry);
}
> Unless you'd propose undoing .prepare IN .prepare in failure cases, but why
> write abort code twice? I don't mind it living in .abort, personally.
>
Doing it the above way would indeed require prepare functions to clean up
after themselves on failure.
The bdrv_reopen() model does it this way, and I think it makes sense. With
most APIs, on failure you wouldn't have a way of knowing what has or has not
been done, so it leaves everything in a clean state. I think this is a good
model to follow.
It is also what most QEMU block interfaces currently do, iirc (.bdrv_open,
etc.) - if it fails, it is assumed that it frees all resources it allocated.
I guess it doesn't have to be done this way, and the complexity can just be
pushed into the _abort() function. After all, with these transactional
models, there exists an abort function, which differentiates it from most
other APIs. But the downfall is that we have different ways of handling
essentially the same sort of transactional model in the block layer (between
bdrv_reopen and qmp_transaction), and it trips up reviewers / authors.
(I don't think changing how qmp_transaction handles this is something that
needs to be handled in this series - but it would be nice in the future
sometime).
Jeff
^ permalink raw reply
* [Intel-wired-lan] [PATCH] igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr
From: Hisashi T Fujinaka @ 2016-11-08 18:32 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <alpine.NEB.2.20.17.1611080910530.6177@chris.i8u.org>
On Tue, 8 Nov 2016, Hisashi T Fujinaka wrote:
>> Incidentally we're just looking for a solution to that problem too.
>> Do three patches to fix the same problem at rougly the same time already
>> qualify as freak accident?
>>
>> FTR, I attached my current patch, which I was planning to submit after
>> some external testing.
>>
>> However, all three patches have one thing in common: They workaround
>> a somewhat dubious resetting of the hardware address to NULL in case
>> reading from a register failed.
>>
>> That makes me wonder if setting the hardware address to NULL in
>> rd32/igb_rd32 is really such a good idea. It's performed in a function
>> which return value is *never* tested for validity in the calling
>> functions and leads to subsequent crashes since no tests for hw_addr ==
>> NULL are performed.
>>
>> Maybe commit 22a8b2915 should be reconsidered? Isn't there some more
>> graceful way to handle the "surprise removal"?
>
> Answering this from my home account because, well, work is Outlook.
>
> "Reconsidering" would be great. In fact, revert if if you'd like. I'm
> uncertain that the surprise removal code actually works the way I
> thought previously and I think I took a lot of it out of my local code.
>
> Unfortuantely I don't have any equipment that I can use to reproduce
> surprise removal any longer so that means I wouldn't be able to test
> anything. I have to defer to you or Cao Jin.
Whoops. Never mind. I was just told that I had a bug that Alex Duyck and
Cao Jin just fixed. I'd stick to listening to Alex.
--
Hisashi T Fujinaka - htodd at twofifty.com
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH] igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr
From: Hisashi T Fujinaka @ 2016-11-08 18:32 UTC (permalink / raw)
To: Corinna Vinschen
Cc: Cao jin, netdev, intel-wired-lan, linux-kernel, izumi.taku
In-Reply-To: <alpine.NEB.2.20.17.1611080910530.6177@chris.i8u.org>
On Tue, 8 Nov 2016, Hisashi T Fujinaka wrote:
>> Incidentally we're just looking for a solution to that problem too.
>> Do three patches to fix the same problem at rougly the same time already
>> qualify as freak accident?
>>
>> FTR, I attached my current patch, which I was planning to submit after
>> some external testing.
>>
>> However, all three patches have one thing in common: They workaround
>> a somewhat dubious resetting of the hardware address to NULL in case
>> reading from a register failed.
>>
>> That makes me wonder if setting the hardware address to NULL in
>> rd32/igb_rd32 is really such a good idea. It's performed in a function
>> which return value is *never* tested for validity in the calling
>> functions and leads to subsequent crashes since no tests for hw_addr ==
>> NULL are performed.
>>
>> Maybe commit 22a8b2915 should be reconsidered? Isn't there some more
>> graceful way to handle the "surprise removal"?
>
> Answering this from my home account because, well, work is Outlook.
>
> "Reconsidering" would be great. In fact, revert if if you'd like. I'm
> uncertain that the surprise removal code actually works the way I
> thought previously and I think I took a lot of it out of my local code.
>
> Unfortuantely I don't have any equipment that I can use to reproduce
> surprise removal any longer so that means I wouldn't be able to test
> anything. I have to defer to you or Cao Jin.
Whoops. Never mind. I was just told that I had a bug that Alex Duyck and
Cao Jin just fixed. I'd stick to listening to Alex.
--
Hisashi T Fujinaka - htodd@twofifty.com
^ permalink raw reply
* [PATCH 3/4] fpga mgr: zynq: Add support for encrypted bitstreams
From: Sören Brinkmann @ 2016-11-08 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107001326.7395-4-moritz.fischer@ettus.com>
On Sun, 2016-11-06 at 17:13:25 -0700, Moritz Fischer wrote:
> Add new flag FPGA_MGR_DECRYPT_BISTREAM as well as a matching
> capability FPGA_MGR_CAP_DECRYPT to allow for on-the-fly
> decryption of an encrypted bitstream.
>
> If the system is not booted in secure mode AES & HMAC units
> are disabled by the boot ROM, therefore the capability
> is not available.
>
> Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
> Cc: Alan Tull <atull@opensource.altera.com>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Cc: S?ren Brinkmann <soren.brinkmann@xilinx.com>
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> ---
> drivers/fpga/fpga-mgr.c | 7 +++++++
> drivers/fpga/zynq-fpga.c | 21 +++++++++++++++++++--
> include/linux/fpga/fpga-mgr.h | 2 ++
> 3 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> index 98230b7..e4d08e1 100644
> --- a/drivers/fpga/fpga-mgr.c
> +++ b/drivers/fpga/fpga-mgr.c
> @@ -61,6 +61,12 @@ int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags, const char *buf,
> return -ENOTSUPP;
> }
>
> + if (flags & FPGA_MGR_DECRYPT_BITSTREAM &&
> + !fpga_mgr_has_cap(FPGA_MGR_CAP_DECRYPT, mgr->caps)) {
> + dev_err(dev, "Bitstream decryption not supported\n");
> + return -ENOTSUPP;
> + }
> +
> /*
> * Call the low level driver's write_init function. This will do the
> * device-specific things to get the FPGA into the state where it is
> @@ -170,6 +176,7 @@ static const char * const state_str[] = {
> static const char * const cap_str[] = {
> [FPGA_MGR_CAP_FULL_RECONF] = "Full reconfiguration",
> [FPGA_MGR_CAP_PARTIAL_RECONF] = "Partial reconfiguration",
> + [FPGA_MGR_CAP_DECRYPT] = "Decrypt bitstream on the fly",
> };
>
> static ssize_t name_show(struct device *dev,
> diff --git a/drivers/fpga/zynq-fpga.c b/drivers/fpga/zynq-fpga.c
> index 1d37ff0..0aa4705 100644
> --- a/drivers/fpga/zynq-fpga.c
> +++ b/drivers/fpga/zynq-fpga.c
> @@ -71,6 +71,10 @@
> #define CTRL_PCAP_PR_MASK BIT(27)
> /* Enable PCAP */
> #define CTRL_PCAP_MODE_MASK BIT(26)
> +/* Needed to reduce clock rate for secure config */
> +#define CTRL_PCAP_RATE_EN_MASK BIT(25)
> +/* System booted in secure mode */
> +#define CTRL_SEC_EN_MASK BIT(7)
>
> /* Miscellaneous Control Register bit definitions */
> /* Internal PCAP loopback */
> @@ -252,12 +256,20 @@ static int zynq_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
>
> /* set configuration register with following options:
> * - enable PCAP interface
> - * - set throughput for maximum speed
> + * - set throughput for maximum speed (if we're not decrypting)
> * - set CPU in user mode
> */
> ctrl = zynq_fpga_read(priv, CTRL_OFFSET);
> - zynq_fpga_write(priv, CTRL_OFFSET,
> + if (flags & FPGA_MGR_DECRYPT_BITSTREAM) {
> + zynq_fpga_write(priv, CTRL_OFFSET,
> + (CTRL_PCAP_PR_MASK | CTRL_PCAP_MODE_MASK |
> + CTRL_PCAP_RATE_EN_MASK | ctrl));
> +
> + } else {
> + ctrl &= ~CTRL_PCAP_RATE_EN_MASK;
> + zynq_fpga_write(priv, CTRL_OFFSET,
> (CTRL_PCAP_PR_MASK | CTRL_PCAP_MODE_MASK | ctrl));
> + }
Minor nit:
Assuming that there may be more caps to check to come, wouldn't it be
slightly easier to write this in a way like?:
if (flags & SOME_FLAG)
ctrl |= FOO;
if (flags & SOME_OTHER_FLAG)
ctrl |= BAR;
zynq_fpga_write(priv, CTRL_OFFSET, ctrl);
i.e. moving the fpga_write outside of the conditionals.
S?ren
^ permalink raw reply
* Re: [PATCH] spi: rspi: avoid uninitialized variable access
From: Geert Uytterhoeven @ 2016-11-08 18:35 UTC (permalink / raw)
To: Chris Brandt
Cc: Arnd Bergmann, Mark Brown, Hiep Cao Minh,
linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <SG2PR06MB11655C10710B5FDDEAEA48218AA60@SG2PR06MB1165.apcprd06.prod.outlook.com>
On Tue, Nov 8, 2016 at 6:20 PM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> However....
>
> On 11/8/2016, Arnd Bergmann wrote:
>> This simplifies it again by keeping the two separate, which then ends up
>> avoiding that warning.
>
> I agree with Arnd's method of NOT adding a new "rspi_pio_transfer_in_or_our"
> function and instead just doing it in the existing qspi_transfer_ functions.
>
> Side note: The RSPI in the RZ/A1 devices also have FIFOs which can be used
> to reduce the number of interrupts in pio transfers, so maybe someday I'll
> make a similar change for non-qspi devices as well.
At which point we probably want to extract the functionality into two separate
functions again, instead of inlining into qspi_transfer_{in,out}()...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [Printing-architecture] Last OP Meeting - Tue - 8 Nov 2016 - The Recording
From: Till Kamppeter @ 2016-11-08 18:35 UTC (permalink / raw)
To: Open Printing, Printing-japan
In-Reply-To: <e395be80811270817n502ccd16wf6cc90f85364f5ae@mail.gmail.com>
Hi,
I have uploaded the recording of the last OpenPrinting meeting to the
OpenPrinting server:
http://www.openprinting.org/download/meetingnotes/op-telecons/OP-Meeting-20161108.mp3
In general, recorded meetings I will upload to
http://www.openprinting.org/download/meetingnotes/
Till
P. S.: The MP3 is 22 MB long, 47 minutes of talking.
^ permalink raw reply
* [Intel-wired-lan] I am looking for a specific driver - 3.4.8-k
From: Hisashi T Fujinaka @ 2016-11-08 18:36 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <F6FB0E698C9B3143BDF729DF2228664696B0DB64@ORSMSX116.amr.corp.intel.com>
On Tue, 8 Nov 2016, Skidmore, Donald C wrote:
>
>
>> -----Original Message-----
>> From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On
>> Behalf Of Jeff Kirsher
>> Sent: Tuesday, November 08, 2016 9:45 AM
>> To: SKahn at graco.com; intel-wired-lan at lists.osuosl.org
>> Subject: Re: [Intel-wired-lan] I am looking for a specific driver - 3.4.8-k
>>
>> On Tue, 2016-11-08 at 08:46 -0600, SKahn at graco.com wrote:
>>> I am trying to locate a driver for X520 Dual Port 10 G Ethernet PICe
>>> Adapter, this version specifically - Manufacturer = Intel Adapter
>>> Driver = 3.4.8-k .
>>>
>>> This is for a Cisco UCSC system with RedHat Linux 5.8 64 bit
>>
>> You should be able to find the version of ixgbe driver you are looking for on
>> e1000.sf.net.
>
> Also the "-k" at the end of the version means the driver is an in-kernel driver. This is further complicated by how RedHat can backport patches into its driver without it reflecting in the driver version number. So why you can go to source forge to get a similarly versioned driver and it should be close it however will not be exactly the same as was in RedHat Linux 5.8. It will contain kcompat code and not contain patches than may have be back ported by RedHat, along with other possible differences. These might not be that important by I thought I would mention it.
>
> Thanks,
> -Don <donald.c.skidmore@intel.com>
What Don said. The -k means it's the in-kernel driver so find out where
you got the kernel from and get the sources from there.
CentOS is trickier; they seem to delete old kernel SRPMs but you should
be able to find the RHEL version of the kernel instead.
Hope that helps.
--
Hisashi T Fujinaka - htodd at twofifty.com
^ permalink raw reply
* Re: [PATCH libdrm] xf86drm: Parse the separate files to retrieve the vendor/device info
From: Mauro Santos @ 2016-11-08 18:36 UTC (permalink / raw)
To: Emil Velikov; +Cc: Michel Dänzer, ML dri-devel
In-Reply-To: <ea00eca4-cf2d-bac5-ab2e-976b877e587b@gmail.com>
On 08-11-2016 18:08, Mauro Santos wrote:
> On 08-11-2016 17:13, Emil Velikov wrote:
>> On 8 November 2016 at 16:57, Mauro Santos <registo.mailling@gmail.com> wrote:
>>> On 08-11-2016 15:57, Emil Velikov wrote:
>>>> On 8 November 2016 at 15:27, Mauro Santos <registo.mailling@gmail.com> wrote:
>>>>> On 08-11-2016 15:00, Emil Velikov wrote:
>>>>>> On 8 November 2016 at 13:38, Mauro Santos <registo.mailling@gmail.com> wrote:
>>>>>>> On 08-11-2016 11:06, Emil Velikov wrote:
>>>>>>>> On 1 November 2016 at 18:47, Mauro Santos <registo.mailling@gmail.com> wrote:
>>>>>>>>> On 01-11-2016 18:13, Emil Velikov wrote:
>>>>>>>>>> From: Emil Velikov <emil.velikov@collabora.com>
>>>>>>>>>>
>>>>>>>>>> Parsing config sysfs file wakes up the device. The latter of which may
>>>>>>>>>> be slow and isn't required to begin with.
>>>>>>>>>>
>>>>>>>>>> Reading through config is/was required since the revision is not
>>>>>>>>>> available by other means, although with a kernel patch in the way we can
>>>>>>>>>> 'cheat' temporarily.
>>>>>>>>>>
>>>>>>>>>> That should be fine, since no open-source project has ever used the
>>>>>>>>>> value.
>>>>>>>>>>
>>>>>>>>>> Cc: Michel Dänzer <michel.daenzer@amd.com>
>>>>>>>>>> Cc: Mauro Santos <registo.mailling@gmail.com>
>>>>>>>>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98502
>>>>>>>>>> Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
>>>>>>>>>> ---
>>>>>>>>>> Mauro can you apply this against libdrm and rebuild it. You do _not_
>>>>>>>>>> need to rebuild mesa afterwords.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> ---
>>>>>>>>>> xf86drm.c | 50 +++++++++++++++++++++++++++++++++++---------------
>>>>>>>>>> 1 file changed, 35 insertions(+), 15 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/xf86drm.c b/xf86drm.c
>>>>>>>>>> index 52add5e..5a5100c 100644
>>>>>>>>>> --- a/xf86drm.c
>>>>>>>>>> +++ b/xf86drm.c
>>>>>>>>>> @@ -2950,25 +2950,45 @@ static int drmParsePciDeviceInfo(const char *d_name,
>>>>>>>>>> drmPciDeviceInfoPtr device)
>>>>>>>>>> {
>>>>>>>>>> #ifdef __linux__
>>>>>>>>>> +#define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
>>>>>>>>>> + static const char *attrs[] = {
>>>>>>>>>> + "revision", /* XXX: make sure it's always first, see note below */
>>>>>>>>>> + "vendor",
>>>>>>>>>> + "device",
>>>>>>>>>> + "subsystem_vendor",
>>>>>>>>>> + "subsystem_device",
>>>>>>>>>> + };
>>>>>>>>>> char path[PATH_MAX + 1];
>>>>>>>>>> - unsigned char config[64];
>>>>>>>>>> - int fd, ret;
>>>>>>>>>> + unsigned int data[ARRAY_SIZE(attrs)];
>>>>>>>>>> + FILE *fp;
>>>>>>>>>> + int ret;
>>>>>>>>>>
>>>>>>>>>> - snprintf(path, PATH_MAX, "/sys/class/drm/%s/device/config", d_name);
>>>>>>>>>> - fd = open(path, O_RDONLY);
>>>>>>>>>> - if (fd < 0)
>>>>>>>>>> - return -errno;
>>>>>>>>>> + for (unsigned i = 0; i < ARRAY_SIZE(attrs); i++) {
>>>>>>>>>> + snprintf(path, PATH_MAX, "/sys/class/drm/%s/device/%s",
>>>>>>>>>> + d_name, attrs[i]);
>>>>>>>>>> + fp = fopen(path, "r");
>>>>>>>>>> + if (!fp) {
>>>>>>>>>> + /* Note: First we check the revision, since older kernels
>>>>>>>>>> + * may not have it. Default to zero in such cases. */
>>>>>>>>>> + if (i == 0) {
>>>>>>>>>> + data[i] = 0;
>>>>>>>>>> + continue;
>>>>>>>>>> + }
>>>>>>>>>> + return -errno;
>>>>>>>>>> + }
>>>>>>>>>>
>>>>>>>>>> - ret = read(fd, config, sizeof(config));
>>>>>>>>>> - close(fd);
>>>>>>>>>> - if (ret < 0)
>>>>>>>>>> - return -errno;
>>>>>>>>>> + ret = fscanf(fp, "%x", &data[i]);
>>>>>>>>>> + fclose(fp);
>>>>>>>>>> + if (ret != 1)
>>>>>>>>>> + return -errno;
>>>>>>>>>> +
>>>>>>>>>> + }
>>>>>>>>>>
>>>>>>>>>> - device->vendor_id = config[0] | (config[1] << 8);
>>>>>>>>>> - device->device_id = config[2] | (config[3] << 8);
>>>>>>>>>> - device->revision_id = config[8];
>>>>>>>>>> - device->subvendor_id = config[44] | (config[45] << 8);
>>>>>>>>>> - device->subdevice_id = config[46] | (config[47] << 8);
>>>>>>>>>> + device->revision_id = data[0] & 0xff;
>>>>>>>>>> + device->vendor_id = data[1] & 0xffff;
>>>>>>>>>> + device->device_id = data[2] & 0xffff;
>>>>>>>>>> + device->subvendor_id = data[3] & 0xffff;
>>>>>>>>>> + device->subdevice_id = data[4] & 0xffff;
>>>>>>>>>>
>>>>>>>>>> return 0;
>>>>>>>>>> #else
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I have applied this against libdrm 2.4.71 and I don't see any delays
>>>>>>>>> when starting firefox/chromium/thunderbird/glxgears.
>>>>>>>>>
>>>>>>>>> There is also no indication in dmesg that the dGPU is being
>>>>>>>>> reinitialized when starting the programs where I've detected the problem.
>>>>>>>>>
>>>>>>>> Thanks Mauro. Can you give this a try alongside the kernel fix [1] ?
>>>>>>>> I'd love to get the latter merged soon(ish).
>>>>>>>> Independent of the kernel side, I might need to go another way for
>>>>>>>> libdrm/mesa so I'll CC you on future patches.
>>>>>>>>
>>>>>>>> Your help is greatly appreciated !
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Emil
>>>>>>>>
>>>>>>>> [1] http://patchwork.ozlabs.org/patch/689975/
>>>>>>>>
>>>>>>>
>>>>>>> I have applied the patch on top of kernel 4.8.6 and I'm using the libdrm
>>>>>>> with the patch you sent me previously.
>>>>>>>
>>>>>>> With this patch things still seem work fine, I don't see any of the
>>>>>>> problems I've seen before, but I don't know how to confirm that the
>>>>>>> value from sysfs is now being used by libdrm instead of defaulting to zero.
>>>>>>>
>>>>>> Grr my bad. $libdrm_builddir/tests/drmdevice should do it. You might
>>>>>> need to explicitly build it (cd tests && make drmdevice)
>>>>>>
>>>>>
>>>>> When running drmdevice as my user it still wakes up the dGPU. The
>>>>> correct device revisions are being reported by I suppose that is not
>>>>> being read from sysfs.
>>>>>
>>>> Based on the output you're spot on - doesn't seem like the revision
>>>> sysfs gets used. Most likely drmdevice is linked/using the pre-patch
>>>> (system/local?) libdrm.so ?
>>>>
>>>
>>> I've been using the patched libdrm.so ever since you sent me the patch
>>> for libdrm and I've recompiled libdrm today to get drmdevice so both the
>>> system's and in-tree libdrm.so should have the patch. Arch's PKGBUILD
>>> does have a non default --enable-udev configure parameter, could that
>>> make any difference?
>>>
>> The --enable-udev does not make any difference.
>>
>> The rest does not make sense - the exact same functions are used by
>> drmdevice and mesa, yet it two different results are produced :-\
>> Or something very funny is happening and reading the device/vendor
>> file does _not_ wake the device, while the revision one does.
>>
>
> If I do 'cat revision' for the dGPU it does not wake up the device so I
> guess we can scratch that.
>
>> Can you pull out the kernel patch and check drmdevice/dmesg with
>> patched libdrm ?
>>
>
> Same behavior as before, both versions of drmdevice wake up the dGPU.
> Could it be that some other lib called by drmdevice and not called by
> other programs is doing something to wake up the dGPU?
>
>> Thanks
>> Emil
>>
>
>
Well, I _think_ I might have found the problem and it's not with libdrm
if I'm correct.
I was now thinking and trying to check if drmdevice might be trying to
read some other information that would wake up the dGPU, and it does.
If you check the mixed output of drmdevice/dmesg I have posted(?) before
you can see that it wakes up the device when this message is shown:
Opening device 0 node /dev/dri/card1
Note the path is /dev/dri/card1. I've tried a 'cat /dev/dri/card1' and
sure enough the dGPU woke up, so I'd say libdrm and the kernel patch are
working just fine as they don't touch anything in /dev but only in /sys.
The initial output without the kernel patch says:
device[0]
available_nodes 0007
nodes
nodes[0] /dev/dri/card1
nodes[1] /dev/dri/controlD65
nodes[2] /dev/dri/renderD129
bustype 0000
businfo
pci
domain 0000
bus 03
dev 00
func 0
deviceinfo
pci
vendor_id 1002
device_id 6600
subvendor_id 17aa
subdevice_id 5049
revision_id 00
If you recheck what I have posted previously after applying the kernel
patch it says revision_id 81, so I'd say it's working and we've been
following a red herring all along.
I suppose I have unintentionally misled you, I'm sorry for that.
--
Mauro Santos
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: CPUID improvements (phase 2) Design Doc
From: Andrew Cooper @ 2016-11-08 18:36 UTC (permalink / raw)
To: Jan Beulich
Cc: Lan Tianyu, Wei Liu, Ian Jackson, Xen-devel, Joao Martins,
Roger Pau Monne
In-Reply-To: <58220C39020000780011D247@prv-mh.provo.novell.com>
On 08/11/16 16:32, Jan Beulich wrote:
>>>> On 08.11.16 at 16:35, <andrew.cooper3@citrix.com> wrote:
>> Please find inline the design doc for further CPUID improvements, planned for
>> development during the 4.9 timeframe.
> Looks good, just a couple of minor remarks.
>
>> ## Changes in hypercall behaviour
>>
>> During domain construction, some pieces of information critical to the
>> determination of the domains maximum acceptable CPUID policy are available
>> right from the very start (Most notably, the HVM and HAP flags from the
>> `XEN_DOMCTL_createdomain`).
>>
>> However, some other parameters are not available at convenient points.
>>
>> 1. The disable flag from `XEN_DOMCTL_disable_migrate` is used to set
>> `d->disable_migrate`, whose only purpose is to avoid the unconditional
>> clobbering of the Invariant TSC flag. This flag cannot even be queried by
>> the toolstack once set.
>>
>> There are other facilities which should be restricted based on whether a
>> VM might migrate or not. (e.g. The use of LBR, whose record format is
>> hardware specific.)
> Not really - the LBR format only limits the set of hosts the VM can
> migrate to. I.e. this is just like a CPUID flag which needs to be set
> on the target host in order for the VM to be permitted to migrate
> there.
It is more complicated than that. The LBR format also depends on
whether TSX is enabled or not, which on Haswell-WS CPUs depends on
whether hyperthreading is enabled.
ITSC itself is complicated. If the toolstack can guarantee it only
migrates to hosts which support full TSC scaling, ITSC is still safe to
expose to the guest.
For situations like this, Xen should default safe (i.e. disable those
features), but still permit the toolstack to enable them on migrateable
VMs. By having the toolstack explicitly opt in to enabling the unsafe
features for migratable VMs, it is taking on the added responsibility of
ensuring destination compatibility.
From an implementation point of view, this would work exactly like
choosing to use experiential features. All we do in Xen is audit
against the maximum allowable featureset for a domain, not the default.
>
>> 2. The use of `XEN_DOMCTL_set_address_size` switches a PV guest between
>> native (64bit) and compat (32bit) mode. The current behaviour for 32bit
>> PV guests is to hide all 64bit-only features.
>>
>> Using this hypercall once to switch from native to compat is fairly easy
>> to cope with, feature wise, but using the hypercall a second time to
>> switch back causes the same ordering problems with respect to
>> `XEN_DOMCTL_set_address_size`.
>>
>> The preferred option here is to avoid hiding 32bit features. This is more
>> architecturally correct, as a 32bit kernel running on 64bit-capable
>> hardware will see 64bit-only features.
> But the upside of hiding them is that the guest won't even try to play
> any long / 64-bit mode games (which wouldn't work anyway).
A PV guest already understands that it is running under Xen and can't
change its mode. As such, not hiding the long mode features won't
affect the guest (even more so because we were never doing it
consistently before).
>
>> Other options would be to modify
>> the API to make `XEN_DOMCTL_set_address_size` a single-shot hypercall
>> (which, given the existing restrictions, shouldn't impact any usecase),
> There must have been a reason why we had made it bi-directional,
> but I don't recall what it was. As long as no existing functionality is
> impacted, I think making this single-shot would be fine.
I am still hesitant of this route, because it is far less easy to be
confident that it is a safe change to make than to revert to
architectural feature behaviour.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [Buildroot] [PATCH 1/2] wget: fix ssl detection in static libs configuration
From: Rahul Bedarkar @ 2016-11-08 18:36 UTC (permalink / raw)
To: buildroot
When building wget with openssl in static libs configuration, wget
build system fails detect openssl because it doesn't specify LD flags
for private libs used by openssl. This specifically happens when we
pass --with-libssl-prefix to configure which tries to find ssl using
custom flags. If we don't specify --with-libssl-prefix, it relies on
pkg-config files to detect ssl and it's LD flags which helps with static
linking.
This commit removes --with-libssl-prefix conf opts. Since this case is
similar to gnutls, we remove same conf opts for gnutls as well.
wget can be built with either gnutls or openssl crypto libraries, so
separate optional support for both is not required. This commit also
does minor optimization by checking for either gnutls or openssl while
at it.
Fixes:
http://autobuild.buildroot.net/results/c6a/c6abdff37b86471cf8b0ceffeff5472042923de0/
Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com>
---
package/wget/wget.mk | 19 +++++--------------
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/package/wget/wget.mk b/package/wget/wget.mk
index 9cda76b..c9efc03 100644
--- a/package/wget/wget.mk
+++ b/package/wget/wget.mk
@@ -17,26 +17,17 @@ WGET_DEPENDENCIES += busybox
endif
ifeq ($(BR2_PACKAGE_GNUTLS),y)
-WGET_CONF_OPTS += \
- --with-ssl=gnutls \
- --with-libgnutls-prefix=$(STAGING_DIR)
+WGET_CONF_OPTS += --with-ssl=gnutls
WGET_DEPENDENCIES += gnutls
-endif
-
-ifeq ($(BR2_PACKAGE_OPENSSL),y)
-WGET_CONF_OPTS += --with-ssl=openssl --with-libssl-prefix=$(STAGING_DIR)
+else ifeq ($(BR2_PACKAGE_OPENSSL),y)
+WGET_CONF_OPTS += --with-ssl=openssl
WGET_DEPENDENCIES += openssl
+else
+WGET_CONF_OPTS += --without-ssl
endif
ifeq ($(BR2_PACKAGE_UTIL_LINUX_LIBUUID),y)
WGET_DEPENDENCIES += util-linux
endif
-# --with-ssl is default
-ifneq ($(BR2_PACKAGE_GNUTLS),y)
-ifneq ($(BR2_PACKAGE_OPENSSL),y)
-WGET_CONF_OPTS += --without-ssl
-endif
-endif
-
$(eval $(autotools-package))
--
2.6.2
^ permalink raw reply related
* [Buildroot] [PATCH 2/2] wget: fix static link with gnutls
From: Rahul Bedarkar @ 2016-11-08 18:36 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1478630202-1630-1-git-send-email-rahul.bedarkar@imgtec.com>
When statically linking with gnutls, we get definition clash error for
base64_encode which is also defined by gnutls.
This commit adds patch to rename base64_{encode,decode} defined in wget.
Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com>
---
.../0001-utils-rename-base64_-encode-decode.patch | 134 +++++++++++++++++++++
1 file changed, 134 insertions(+)
create mode 100644 package/wget/0001-utils-rename-base64_-encode-decode.patch
diff --git a/package/wget/0001-utils-rename-base64_-encode-decode.patch b/package/wget/0001-utils-rename-base64_-encode-decode.patch
new file mode 100644
index 0000000..f219afa
--- /dev/null
+++ b/package/wget/0001-utils-rename-base64_-encode-decode.patch
@@ -0,0 +1,134 @@
+From 9e68787576fec304da23af26dca963a4cdea7765 Mon Sep 17 00:00:00 2001
+From: Rahul Bedarkar <rahul.bedarkar@imgtec.com>
+Date: Tue, 8 Nov 2016 23:42:53 +0530
+Subject: [PATCH] utils: rename base64_{encode,decode}
+
+When statically linking with gnutls, we get definition clash error for
+base64_encode which is also defined by gnutls.
+
+/home/rahul.bedarkar/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libgnutls.a(base64.o): In function `base64_encode':
+base64.c:(.text+0x148): multiple definition of `base64_encode'
+utils.o:utils.c:(.text+0x4378): first defined here
+collect2: error: ld returned 1 exit status
+
+To prevent definition clash, rename base64_{encode,decode}
+
+Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com>
+---
+ src/http-ntlm.c | 6 +++---
+ src/http.c | 4 ++--
+ src/utils.c | 8 ++++----
+ src/utils.h | 4 ++--
+ 4 files changed, 11 insertions(+), 11 deletions(-)
+
+diff --git a/src/http-ntlm.c b/src/http-ntlm.c
+index 56c40ae..87f5a37 100644
+--- a/src/http-ntlm.c
++++ b/src/http-ntlm.c
+@@ -122,7 +122,7 @@ ntlm_input (struct ntlmdata *ntlm, const char *header)
+
+ DEBUGP (("Received a type-2 NTLM message.\n"));
+
+- size = base64_decode (header, buffer);
++ size = wget_base64_decode (header, buffer);
+ if (size < 0)
+ return false; /* malformed base64 from server */
+
+@@ -411,7 +411,7 @@ ntlm_output (struct ntlmdata *ntlm, const char *user, const char *passwd,
+ size = 32 + hostlen + domlen;
+
+ base64 = (char *) alloca (BASE64_LENGTH (size) + 1);
+- base64_encode (ntlmbuf, size, base64);
++ wget_base64_encode (ntlmbuf, size, base64);
+
+ output = concat_strings ("NTLM ", base64, (char *) 0);
+ break;
+@@ -584,7 +584,7 @@ ntlm_output (struct ntlmdata *ntlm, const char *user, const char *passwd,
+
+ /* convert the binary blob into base64 */
+ base64 = (char *) alloca (BASE64_LENGTH (size) + 1);
+- base64_encode (ntlmbuf, size, base64);
++ wget_base64_encode (ntlmbuf, size, base64);
+
+ output = concat_strings ("NTLM ", base64, (char *) 0);
+
+diff --git a/src/http.c b/src/http.c
+index 7e60a07..368d30d 100644
+--- a/src/http.c
++++ b/src/http.c
+@@ -2818,7 +2818,7 @@ metalink_from_http (const struct response *resp, const struct http_stat *hs,
+ char *bin_hash = alloca (dig_hash_str_len * 3 / 4 + 1);
+ size_t hash_bin_len;
+
+- hash_bin_len = base64_decode (dig_hash, bin_hash);
++ hash_bin_len = wget_base64_decode (dig_hash, bin_hash);
+
+ /* One slot for me, one for zero-termination. */
+ mfile->checksums =
+@@ -4546,7 +4546,7 @@ basic_authentication_encode (const char *user, const char *passwd)
+ sprintf (t1, "%s:%s", user, passwd);
+
+ t2 = (char *)alloca (BASE64_LENGTH (len1) + 1);
+- base64_encode (t1, len1, t2);
++ wget_base64_encode (t1, len1, t2);
+
+ return concat_strings ("Basic ", t2, (char *) 0);
+ }
+diff --git a/src/utils.c b/src/utils.c
+index b07da9f..355f0ce 100644
+--- a/src/utils.c
++++ b/src/utils.c
+@@ -2140,7 +2140,7 @@ xsleep (double seconds)
+ base64 data. */
+
+ size_t
+-base64_encode (const void *data, size_t length, char *dest)
++wget_base64_encode (const void *data, size_t length, char *dest)
+ {
+ /* Conversion table. */
+ static const char tbl[64] = {
+@@ -2208,7 +2208,7 @@ base64_encode (const void *data, size_t length, char *dest)
+ This function originates from Free Recode. */
+
+ ssize_t
+-base64_decode (const char *base64, void *dest)
++wget_base64_decode (const char *base64, void *dest)
+ {
+ /* Table of base64 values for first 128 characters. Note that this
+ assumes ASCII (but so does Wget in other places). */
+@@ -2588,7 +2588,7 @@ wg_pubkey_pem_to_der (const char *pem, unsigned char **der, size_t *der_len)
+
+ base64data = xmalloc (BASE64_LENGTH(stripped_pem_count));
+
+- size = base64_decode (stripped_pem, base64data);
++ size = wget_base64_decode (stripped_pem, base64data);
+
+ if (size < 0) {
+ xfree (base64data); /* malformed base64 from server */
+@@ -2651,7 +2651,7 @@ wg_pin_peer_pubkey (const char *pinnedpubkey, const char *pubkey, size_t pubkeyl
+ end_pos[0] = '\0';
+
+ /* decode base64 pinnedpubkey, 8 is length of "sha256//" */
+- decoded_hash_length = base64_decode (begin_pos + 8, expectedsha256sumdigest);
++ decoded_hash_length = wget_base64_decode (begin_pos + 8, expectedsha256sumdigest);
+ /* if valid base64, compare sha256 digests directly */
+ if (SHA256_DIGEST_SIZE == decoded_hash_length &&
+ !memcmp (sha256sumdigest, expectedsha256sumdigest, SHA256_DIGEST_SIZE)) {
+diff --git a/src/utils.h b/src/utils.h
+index f224b73..aaac730 100644
+--- a/src/utils.h
++++ b/src/utils.h
+@@ -140,8 +140,8 @@ void xsleep (double);
+ /* How many bytes it will take to store LEN bytes in base64. */
+ #define BASE64_LENGTH(len) (4 * (((len) + 2) / 3))
+
+-size_t base64_encode (const void *, size_t, char *);
+-ssize_t base64_decode (const char *, void *);
++size_t wget_base64_encode (const void *, size_t, char *);
++ssize_t wget_base64_decode (const char *, void *);
+
+ #ifdef HAVE_LIBPCRE
+ void *compile_pcre_regex (const char *);
+--
+2.6.2
+
--
2.6.2
^ permalink raw reply related
* [Intel-wired-lan] [PATCH] igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr
From: Corinna Vinschen @ 2016-11-08 18:37 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <alpine.NEB.2.20.17.1611080910530.6177@chris.i8u.org>
On Nov 8 09:16, Hisashi T Fujinaka wrote:
> On Tue, 8 Nov 2016, Corinna Vinschen wrote:
> > On Nov 8 15:06, Cao jin wrote:
> > > When running as guest, under certain condition, it will oops as following.
> > > writel() in igb_configure_tx_ring() results in oops, because hw->hw_addr
> > > is NULL. While other register access won't oops kernel because they use
> > > wr32/rd32 which have a defense against NULL pointer.
> > > [...]
> >
> > Incidentally we're just looking for a solution to that problem too.
> > Do three patches to fix the same problem at rougly the same time already
> > qualify as freak accident?
> >
> > FTR, I attached my current patch, which I was planning to submit after
> > some external testing.
> >
> > However, all three patches have one thing in common: They workaround
> > a somewhat dubious resetting of the hardware address to NULL in case
> > reading from a register failed.
> >
> > That makes me wonder if setting the hardware address to NULL in
> > rd32/igb_rd32 is really such a good idea. It's performed in a function
> > which return value is *never* tested for validity in the calling
> > functions and leads to subsequent crashes since no tests for hw_addr ==
> > NULL are performed.
> >
> > Maybe commit 22a8b2915 should be reconsidered? Isn't there some more
> > graceful way to handle the "surprise removal"?
>
> Answering this from my home account because, well, work is Outlook.
>
> "Reconsidering" would be great. In fact, revert if if you'd like. I'm
> uncertain that the surprise removal code actually works the way I
> thought previously and I think I took a lot of it out of my local code.
>
> Unfortuantely I don't have any equipment that I can use to reproduce
> surprise removal any longer so that means I wouldn't be able to test
> anything. I have to defer to you or Cao Jin.
I'm not too keen to rip out a PCIe NIC under power from my locale
desktop machine, but I think an actual surprise removal is not the
problem.
As described in my git log entry, the error condition in igb_rd32 can be
triggered during a suspend. The HW has been put into a sleep state but
some register read requests are apparently not guarded against that
situation. Reading a register in this state returns -1, thus a suspend
is erroneously triggering the "surprise removal" sequence.
Here's a raw idea:
- Note that device is suspended in e1000_hw struct. Don't trigger
error sequence in igb_rd32 if so (...and return a 0 value???)
- Otherwise assume it's actually a surprise removal. In theory that
should somehow trigger a device removal sequence, kind of like
calling igb_remove, no?
Thanks,
Corinna
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20161108/13180795/attachment-0001.asc>
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH] igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr
From: Corinna Vinschen @ 2016-11-08 18:37 UTC (permalink / raw)
To: Hisashi T Fujinaka
Cc: Cao jin, netdev, intel-wired-lan, linux-kernel, izumi.taku
In-Reply-To: <alpine.NEB.2.20.17.1611080910530.6177@chris.i8u.org>
[-- Attachment #1: Type: text/plain, Size: 2724 bytes --]
On Nov 8 09:16, Hisashi T Fujinaka wrote:
> On Tue, 8 Nov 2016, Corinna Vinschen wrote:
> > On Nov 8 15:06, Cao jin wrote:
> > > When running as guest, under certain condition, it will oops as following.
> > > writel() in igb_configure_tx_ring() results in oops, because hw->hw_addr
> > > is NULL. While other register access won't oops kernel because they use
> > > wr32/rd32 which have a defense against NULL pointer.
> > > [...]
> >
> > Incidentally we're just looking for a solution to that problem too.
> > Do three patches to fix the same problem at rougly the same time already
> > qualify as freak accident?
> >
> > FTR, I attached my current patch, which I was planning to submit after
> > some external testing.
> >
> > However, all three patches have one thing in common: They workaround
> > a somewhat dubious resetting of the hardware address to NULL in case
> > reading from a register failed.
> >
> > That makes me wonder if setting the hardware address to NULL in
> > rd32/igb_rd32 is really such a good idea. It's performed in a function
> > which return value is *never* tested for validity in the calling
> > functions and leads to subsequent crashes since no tests for hw_addr ==
> > NULL are performed.
> >
> > Maybe commit 22a8b2915 should be reconsidered? Isn't there some more
> > graceful way to handle the "surprise removal"?
>
> Answering this from my home account because, well, work is Outlook.
>
> "Reconsidering" would be great. In fact, revert if if you'd like. I'm
> uncertain that the surprise removal code actually works the way I
> thought previously and I think I took a lot of it out of my local code.
>
> Unfortuantely I don't have any equipment that I can use to reproduce
> surprise removal any longer so that means I wouldn't be able to test
> anything. I have to defer to you or Cao Jin.
I'm not too keen to rip out a PCIe NIC under power from my locale
desktop machine, but I think an actual surprise removal is not the
problem.
As described in my git log entry, the error condition in igb_rd32 can be
triggered during a suspend. The HW has been put into a sleep state but
some register read requests are apparently not guarded against that
situation. Reading a register in this state returns -1, thus a suspend
is erroneously triggering the "surprise removal" sequence.
Here's a raw idea:
- Note that device is suspended in e1000_hw struct. Don't trigger
error sequence in igb_rd32 if so (...and return a 0 value???)
- Otherwise assume it's actually a surprise removal. In theory that
should somehow trigger a device removal sequence, kind of like
calling igb_remove, no?
Thanks,
Corinna
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: compile error for handwritten "perl-RPM2", 'RPM_GNUC_NULL_TERMINATED' error
From: Tim Orling @ 2016-11-08 18:37 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: OE Core mailing list
In-Reply-To: <alpine.LFD.2.20.1611080556150.4555@ca624034.mitel.com>
[-- Attachment #1: Type: text/plain, Size: 7328 bytes --]
NOTE: by convention, OE perl recipes follow debian naming so this should be
librpm2-perl_1.3.bb
Obviously, in your own layer you are free to do what you want, but it will
require the name change if you want it to go into meta-perl.
For dependencies, since you are looking at CentOS rpms, you can look at,
e.g. [0] to see the DEPENDS (BuildRequires:) and RDEPENDS (Requires:).
This would have shown you the need for rpm-devel.
I also use metacpan, e.g. [1], to look for dependencies in perl modules. It
also has a very slick ElasticSearch JSON API that you can use to
automatically query data [2].
To pass in the extra variables, for 'inherit cpan' you probably need to set
EXTRA_CPANFLAGS [3] or for 'inherit cpan_build' EXTRA_CPAN_BUILD_FLAGS [4],
e.g. [5].
You might want to file a documentation bug for the next release?
[0]
http://pkgs.fedoraproject.org/cgit/rpms/perl-RPM2.git/tree/perl-RPM2.spec?h=epel7
[1] https://metacpan.org/pod/RPM2
[2] https://github.com/metacpan/metacpan-api/blob/master/docs/API-docs.md
[3]
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/cpan.bbclass#n20
[4]
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/cpan_build.bbclass#n21
[5]
http://git.openembedded.org/meta-openembedded/tree/meta-perl/recipes-perl/libxml/libxml-libxml-perl_2.0121.bb#n37
On Tue, Nov 8, 2016 at 3:17 AM, Robert P. J. Day <rpjday@crashcourse.ca>
wrote:
>
> replying to my earlier post with additional info ... man, i want to
> debug this ...
>
> On Tue, 8 Nov 2016, Robert P. J. Day wrote:
>
> > following on my earlier post, here's the specific issue i'm
> > tackling. having found no existing OE recipe equivalent to a centos
> > "perl-RPM2" RPM, i wrote my own. here's the info about that RH RPM on
> > my fedora system, so i know what the final result should look like:
> >
> > $ rpm -ql perl-RPM2
> > /usr/lib64/perl5/vendor_perl/RPM2.pm
> > /usr/lib64/perl5/vendor_perl/auto/RPM2
> > /usr/lib64/perl5/vendor_perl/auto/RPM2/RPM2.so
> > /usr/share/doc/perl-RPM2
> > /usr/share/doc/perl-RPM2/Changes
> > /usr/share/doc/perl-RPM2/README
> > /usr/share/man/man3/RPM2.3pm.gz
> > $
> >
> > so, as before, track down the source at cpan:
> >
> > https://metacpan.org/pod/RPM2
> >
> > and write a boilerplate recipe, "perl-rpm2", containing the following
> > line since it's an older style recipe:
> >
> > inherit cpan_build
> >
> > fetching works fine:
> >
> > $ bitbake -c fetchall perl-rpm2
> >
> > but here's the problem:
> >
> > $ bitbake perl-rpm2
> >
> > ... snip ...
> >
> > | DEBUG: Executing shell function do_compile
> > | Copying lib/RPM2.pm -> blib/lib/RPM2.pm
> > | lib/RPM2.xs -> lib/RPM2.c
> > | powerpc-poky-linux-gcc -m32 -mhard-float -mcpu=7400 -mno-spe
> > --sysroot=/home/rpjday/oe/builds/msm_qemuppc/tmp/sysroots/qemuppc
> > -I/home/rpjday/oe/builds/msm_qemuppc/tmp/sysroots/qemuppc/
> usr/lib/perl/5.22.1/CORE
> > -DVERSION="1.3" -DXS_VERSION="1.3" -fPIC -DRPM2_API=5004
> > -I/home/rpjday/oe/builds/msm_qemuppc/tmp/sysroots/qemuppc/
> usr/include/rpm
> > -c -O2 -pipe -g -feliminate-unused-debug-types
> > -fdebug-prefix-map=/home/rpjday/oe/builds/msm_qemuppc/
> tmp/work/ppc7400-poky-linux/perl/5.22.1-r0=/usr/src/debug/perl/5.22.1-r0
> > -fdebug-prefix-map=/home/rpjday/oe/builds/msm_qemuppc/
> tmp/sysroots/x86_64-linux=
> > -fdebug-prefix-map=/home/rpjday/oe/builds/msm_qemuppc/
> tmp/sysroots/qemuppc=
> > -DDEBIAN -D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe
> > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -O2
> > -pipe -g -feliminate-unused-debug-types
> > -fdebug-prefix-map=/home/rpjday/oe/builds/msm_qemuppc/
> tmp/work/ppc7400-poky-linux/perl-rpm2/1.3-r0=/usr/src/
> debug/perl-rpm2/1.3-r0
> > -fdebug-prefix-map=/home/rpjday/oe/builds/msm_qemuppc/
> tmp/sysroots/x86_64-linux=
> > -fdebug-prefix-map=/home/rpjday/oe/builds/msm_qemuppc/
> tmp/sysroots/qemuppc=
> > -O2 -o lib/RPM2.o lib/RPM2.c
> > | In file included from
> > /home/rpjday/oe/builds/msm_qemuppc/tmp/sysroots/qemuppc/
> usr/include/rpm/rpmcli.h:9:0,
> > | from lib/RPM2.xs:3:
> > |
> > /home/rpjday/oe/builds/msm_qemuppc/tmp/sysroots/qemuppc/
> usr/include/rpm/rpmmacro.h:
> > In function 'rpmExpand':
> > |
> > /home/rpjday/oe/builds/msm_qemuppc/tmp/sysroots/qemuppc/
> usr/include/rpm/rpmmacro.h:249:2:
> > error: expected declaration specifiers before
> > 'RPM_GNUC_NULL_TERMINATED'
> > | RPM_GNUC_NULL_TERMINATED
> > | ^~~~~~~~~~~~~~~~~~~~~~~~
> > |
> > /home/rpjday/oe/builds/msm_qemuppc/tmp/sysroots/qemuppc/
> usr/include/rpm/rpmmacro.h:260:2:
> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
> > 'RPM_GNUC_NULL_TERMINATED'
> > | RPM_GNUC_NULL_TERMINATED
> > | ^~~~~~~~~~~~~~~~~~~~~~~~
> >
> > ... big snip, lots more errors ...
>
> ok, here's my wildly-uneducated record of what is going on:
>
> first, unpacking and configuring perl-RPM2 source (and running XS
> processor) gives me the source file "lib/RPM2.c" (which is what is
> generating the first build error above), which includes the header
> file:
>
> #include <rpm/rpmcli.h>
>
> next, wander over to the qemuppc sysroot, to usr/include/rpm/, to
> check out that header file, which contains (among other things):
>
> #include <popt.h>
> #include <rpmmacro.h> <----- there
> #include <rpmtypes.h>
> #include <rpmtag.h>
> #include <rpmps.h>
> #include <rpmrc.h>
> #include <rpmfi.h> /* XXX rpmfileAttrs */
> #include <rpmts.h> /* XXX rpmdepFlags *
>
> next, in the same directory, examine rpmmacro.h, which contains:
>
> #if defined(_MACRO_INTERNAL)
> #include <rpmiotypes.h>
> ... snip ...
>
> at this point, inclusion is now conditional on _MACRO_INTERNAL, so
> move on to rpmiotypes.h, which contains:
>
> #include <rpmutil.h>
>
> and finally visit that header file in the qemuppc sysroot to find:
>
> #if __GNUC__ >= 4
> #define RPM_GNUC_NULL_TERMINATED __attribute__((__sentinel__))
> #else
> #define RPM_GNUC_NULL_TERMINATED
> #endif
>
> where we find the definition of that macro.
>
> now, is it my imagination, or could a lot of this compile-time error
> be resolved by simply defining the macro "_MACRO_INTERNAL" for the
> build? and if so, what is the proper way to add that setting to the
> compile step for this recipe?
>
> would i use the standard EXTRA_* variables? or are there
> perl-specific variables one would use when build CPAN recipes? or am i
> totally off-track here?
>
> rday
>
> --
>
> ========================================================================
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter: http://twitter.com/rpjday
> LinkedIn: http://ca.linkedin.com/in/rpjday
> ========================================================================
>
>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
[-- Attachment #2: Type: text/html, Size: 10037 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/pseries: implement nmi ipi with H_SIGNAL_SYS_RESET
From: kbuild test robot @ 2016-11-08 18:38 UTC (permalink / raw)
To: Nicholas Piggin
Cc: kbuild-all, linuxppc-dev, Alistair Popple, Nicholas Piggin
In-Reply-To: <20161108140125.21455-4-npiggin@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1658 bytes --]
Hi Nicholas,
[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.9-rc4]
[cannot apply to next-20161108]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Nicholas-Piggin/powerpc-NMI-IPIs/20161109-005049
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
arch/powerpc/platforms/pseries/smp.c: In function 'pseries_cause_nmi_ipi':
>> arch/powerpc/platforms/pseries/smp.c:202:7: error: implicit declaration of function 'plapr_signal_sys_reset' [-Werror=implicit-function-declaration]
if (plapr_signal_sys_reset(cpu) == H_SUCCESS)
^~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/plapr_signal_sys_reset +202 arch/powerpc/platforms/pseries/smp.c
196 xics_cause_ipi(cpu, data);
197 }
198
199 static int pseries_cause_nmi_ipi(int cpu, int type)
200 {
201 if (type == SMP_OP_NMI_TYPE_HARD) {
> 202 if (plapr_signal_sys_reset(cpu) == H_SUCCESS)
203 return 1;
204 }
205
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 22506 bytes --]
^ permalink raw reply
* Re: [PATCH] mm: only enable sys_pkey* when ARCH_HAS_PKEYS
From: Dave Hansen @ 2016-11-08 18:39 UTC (permalink / raw)
To: Heiko Carstens, Russell King - ARM Linux
Cc: Mark Rutland, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andrew Morton,
Mel Gorman, Thomas Gleixner, linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-arch-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
In-Reply-To: <20161108112400.GE3528@osiris>
On 11/08/2016 03:24 AM, Heiko Carstens wrote:
> Something like this:
>
> diff --git a/mm/mprotect.c b/mm/mprotect.c
> index 11936526b08b..9fb86b107e49 100644
> --- a/mm/mprotect.c
> +++ b/mm/mprotect.c
> @@ -484,6 +484,8 @@ SYSCALL_DEFINE3(mprotect, unsigned long, start, size_t, len,
> return do_mprotect_pkey(start, len, prot, -1);
> }
>
> +#ifdef CONFIG_ARCH_HAS_PKEYS
> +
> SYSCALL_DEFINE4(pkey_mprotect, unsigned long, start, size_t, len,
> unsigned long, prot, int, pkey)
> {
> @@ -534,3 +536,4 @@ SYSCALL_DEFINE1(pkey_free, int, pkey)
> */
> return ret;
> }
> +#endif /* CONFIG_ARCH_HAS_PKEYS */
That's fine with me, fwiw. It ends up meaning that the config option
changes whether we get -ENOSPC vs. -ENOSYS, so the x86_32 behavior will
change, for instance. But, I _think_ that's OK.
^ permalink raw reply
* Re: [PATCH] mm: only enable sys_pkey* when ARCH_HAS_PKEYS
From: Dave Hansen @ 2016-11-08 18:39 UTC (permalink / raw)
To: Heiko Carstens, Russell King - ARM Linux
Cc: Mark Rutland, linux-kernel, Andrew Morton, Mel Gorman,
Thomas Gleixner, linux-api, linux-arch, linux-mm, torvalds
In-Reply-To: <20161108112400.GE3528@osiris>
On 11/08/2016 03:24 AM, Heiko Carstens wrote:
> Something like this:
>
> diff --git a/mm/mprotect.c b/mm/mprotect.c
> index 11936526b08b..9fb86b107e49 100644
> --- a/mm/mprotect.c
> +++ b/mm/mprotect.c
> @@ -484,6 +484,8 @@ SYSCALL_DEFINE3(mprotect, unsigned long, start, size_t, len,
> return do_mprotect_pkey(start, len, prot, -1);
> }
>
> +#ifdef CONFIG_ARCH_HAS_PKEYS
> +
> SYSCALL_DEFINE4(pkey_mprotect, unsigned long, start, size_t, len,
> unsigned long, prot, int, pkey)
> {
> @@ -534,3 +536,4 @@ SYSCALL_DEFINE1(pkey_free, int, pkey)
> */
> return ret;
> }
> +#endif /* CONFIG_ARCH_HAS_PKEYS */
That's fine with me, fwiw. It ends up meaning that the config option
changes whether we get -ENOSPC vs. -ENOSYS, so the x86_32 behavior will
change, for instance. But, I _think_ that's OK.
^ permalink raw reply
* Re: [PATCH] mm: only enable sys_pkey* when ARCH_HAS_PKEYS
From: Dave Hansen @ 2016-11-08 18:39 UTC (permalink / raw)
To: Heiko Carstens, Russell King - ARM Linux
Cc: Mark Rutland, linux-kernel, Andrew Morton, Mel Gorman,
Thomas Gleixner, linux-api, linux-arch, linux-mm, torvalds
In-Reply-To: <20161108112400.GE3528@osiris>
On 11/08/2016 03:24 AM, Heiko Carstens wrote:
> Something like this:
>
> diff --git a/mm/mprotect.c b/mm/mprotect.c
> index 11936526b08b..9fb86b107e49 100644
> --- a/mm/mprotect.c
> +++ b/mm/mprotect.c
> @@ -484,6 +484,8 @@ SYSCALL_DEFINE3(mprotect, unsigned long, start, size_t, len,
> return do_mprotect_pkey(start, len, prot, -1);
> }
>
> +#ifdef CONFIG_ARCH_HAS_PKEYS
> +
> SYSCALL_DEFINE4(pkey_mprotect, unsigned long, start, size_t, len,
> unsigned long, prot, int, pkey)
> {
> @@ -534,3 +536,4 @@ SYSCALL_DEFINE1(pkey_free, int, pkey)
> */
> return ret;
> }
> +#endif /* CONFIG_ARCH_HAS_PKEYS */
That's fine with me, fwiw. It ends up meaning that the config option
changes whether we get -ENOSPC vs. -ENOSYS, so the x86_32 behavior will
change, for instance. But, I _think_ that's OK.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ 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.