* Re: [PATCH v2 2/2] scsi: ufs: Use the resource-managed function to add devfreq device
From: Martin K. Petersen @ 2016-11-09 0:17 UTC (permalink / raw)
To: Chanwoo Choi
Cc: myungjoo.ham, kyungmin.park, rjw, subhashj, linux-pm,
linux-kernel, Vinayak Holikatti, James E.J. Bottomley,
Martin K. Petersen, linux-scsi
In-Reply-To: <1478596408-2958-3-git-send-email-cw00.choi@samsung.com>
>>>>> "Chanwoo" == Chanwoo Choi <cw00.choi@samsung.com> writes:
Chanwoo> This patch uses the resource-managed to add the devfreq device.
Chanwoo> This function will make it easy to handle the devfreq device.
Applied to 4.10/scsi-queue.
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: [PATCH V3 1/9] Documentation: devicetree: input: additions for da9061 onkey driver
From: Dmitry Torokhov @ 2016-11-09 0:17 UTC (permalink / raw)
To: Steve Twiss
Cc: DEVICETREE, LINUX-INPUT, LINUX-KERNEL, Mark Rutland, Rob Herring,
Eduardo Valentin, Guenter Roeck, LINUX-PM, LINUX-WATCHDOG,
Lee Jones, Liam Girdwood, Mark Brown, Support Opensource,
Wim Van Sebroeck, Zhang Rui
In-Reply-To: <48abf6ce51f8ef02421ea2dd4f4e309b440efc85.1477929725.git.stwiss.opensource@diasemi.com>
On Mon, Oct 31, 2016 at 04:02:02PM +0000, Steve Twiss wrote:
> From: Steve Twiss <stwiss.opensource@diasemi.com>
>
> Add binding information for DA9061 onkey.
>
> This patch updates the compatible string "dlg,da9061-onkey" to support
> DA9061, removes the reference to KEY_SLEEP (which the driver no longer
> supports) and fixes a typo in the example for DA9063.
>
> Supporting KEY_SLEEP was not the general convention and the typical
> solution should have been for KEY_POWER to support both cases of suspend
> and S/W power off. This change was sent to the DA9063 ONKEY device
> driver in a separate patch, but the documentation was not updated at
> that time.
> - f889bea Report KEY_POWER instead of KEY_SLEEP during power key-press
>
> This patch also adds two new examples, one for DA9062 and one for DA9061.
> The DA9061 examples uses a fall-back compatible string for the DA9062
> onkey driver.
>
> Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
Applied, thank you.
>
> ---
> This patch applies against linux-next and v4.8
>
> v2 -> v3
> - Patch renamed from [PATCH V2 01/10] to [PATCH V3 1/9]
> - Each compatible line should be a valid combination of compatible
> strings, alter DA9061 line to include the fall back compatible string
> - Update the commit message to include KEY_SLEEP removal explanation and
> a link back to the original device driver commit. This will allow full
> traceability back to the original patch change
> - Link in information about associated patches from this set without
> describing them as being explicitly dependent on this binding
>
> v1 -> v2
> - Patch renamed from [PATCH V1 06/10] to [PATCH V2 01/10] -- these
> changes were made to fix checkpatch warnings caused by the patch
> set dependency order
> - Typo s/ther/the/ in commit message
> - Explanation about why KEY_SLEEP was removed (see below)
> - Addition of DA9062 example
> - Addition of a DA9061 example to follow the driver fall-back compatible
> convention being applied for this device driver
>
> Hi,
>
> There is also new binding examples for DA9062 and DA9061. Importantly,
> the Linux device driver changes for DA9061 were rejected because the
> DA9062 device driver can be reused. For this reason, the DA9061 example
> uses a fall-back compatible string.
>
> Other information:
> The device driver from this patch set (associated with this binding) was
> applied by Dmitry Torokhov on 26-Oct-2016. See:
> - [PATCH V2 07/10] Input: da9061: onkey driver.
> - https://lkml.org/lkml/2016/10/26/1169
>
> Regards,
> Steve Twiss, Dialog Semiconductor Ltd.
>
>
> .../devicetree/bindings/input/da9062-onkey.txt | 45 ++++++++++++++--------
> 1 file changed, 30 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/da9062-onkey.txt b/Documentation/devicetree/bindings/input/da9062-onkey.txt
> index ab0e048..5f9fbc6 100644
> --- a/Documentation/devicetree/bindings/input/da9062-onkey.txt
> +++ b/Documentation/devicetree/bindings/input/da9062-onkey.txt
> @@ -1,32 +1,47 @@
> -* Dialog DA9062/63 OnKey Module
> +* Dialog DA9061/62/63 OnKey Module
>
> -This module is part of the DA9062/DA9063. For more details about entire
> -chips see Documentation/devicetree/bindings/mfd/da9062.txt and
> -Documentation/devicetree/bindings/mfd/da9063.txt
> +This module is part of the DA9061/DA9062/DA9063. For more details about entire
> +DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
> +For DA9063 see Documentation/devicetree/bindings/mfd/da9063.txt
>
> -This module provides KEY_POWER, KEY_SLEEP and events.
> +This module provides the KEY_POWER event.
>
> Required properties:
>
> -- compatible: should be one of:
> - dlg,da9062-onkey
> - dlg,da9063-onkey
> +- compatible: should be one of the following valid compatible string lines:
> + "dlg,da9061-onkey", "dlg,da9062-onkey"
> + "dlg,da9062-onkey"
> + "dlg,da9063-onkey"
>
> Optional properties:
>
> - - dlg,disable-key-power : Disable power-down using a long key-press. If this
> +- dlg,disable-key-power : Disable power-down using a long key-press. If this
> entry exists the OnKey driver will remove support for the KEY_POWER key
> - press. If this entry does not exist then by default the key-press
> - triggered power down is enabled and the OnKey will support both KEY_POWER
> - and KEY_SLEEP.
> + press when triggered using a long press of the OnKey.
>
> -Example:
> -
> - pmic0: da9062@58 {
> +Example: DA9063
>
> + pmic0: da9063@58 {
> onkey {
> compatible = "dlg,da9063-onkey";
> dlg,disable-key-power;
> };
> + };
> +
> +Example: DA9062
> +
> + pmic0: da9062@58 {
> + onkey {
> + compatible = "dlg,da9062-onkey";
> + dlg,disable-key-power;
> + };
> + };
> +
> +Example: DA9061 using a fall-back compatible for the DA9062 onkey driver
>
> + pmic0: da9061@58 {
> + onkey {
> + compatible = "dlg,da9061-onkey", "dlg,da9062-onkey";
> + dlg,disable-key-power;
> + };
> };
> --
> end-of-patch for PATCH V3
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH V3 1/9] Documentation: devicetree: input: additions for da9061 onkey driver
From: Dmitry Torokhov @ 2016-11-09 0:17 UTC (permalink / raw)
To: Steve Twiss
Cc: DEVICETREE, LINUX-INPUT, LINUX-KERNEL, Mark Rutland, Rob Herring,
Eduardo Valentin, Guenter Roeck, LINUX-PM, LINUX-WATCHDOG,
Lee Jones, Liam Girdwood, Mark Brown, Support Opensource,
Wim Van Sebroeck, Zhang Rui
In-Reply-To: <48abf6ce51f8ef02421ea2dd4f4e309b440efc85.1477929725.git.stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
On Mon, Oct 31, 2016 at 04:02:02PM +0000, Steve Twiss wrote:
> From: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
>
> Add binding information for DA9061 onkey.
>
> This patch updates the compatible string "dlg,da9061-onkey" to support
> DA9061, removes the reference to KEY_SLEEP (which the driver no longer
> supports) and fixes a typo in the example for DA9063.
>
> Supporting KEY_SLEEP was not the general convention and the typical
> solution should have been for KEY_POWER to support both cases of suspend
> and S/W power off. This change was sent to the DA9063 ONKEY device
> driver in a separate patch, but the documentation was not updated at
> that time.
> - f889bea Report KEY_POWER instead of KEY_SLEEP during power key-press
>
> This patch also adds two new examples, one for DA9062 and one for DA9061.
> The DA9061 examples uses a fall-back compatible string for the DA9062
> onkey driver.
>
> Signed-off-by: Steve Twiss <stwiss.opensource-WBD+wuPFNBhBDgjK7y7TUQ@public.gmane.org>
Applied, thank you.
>
> ---
> This patch applies against linux-next and v4.8
>
> v2 -> v3
> - Patch renamed from [PATCH V2 01/10] to [PATCH V3 1/9]
> - Each compatible line should be a valid combination of compatible
> strings, alter DA9061 line to include the fall back compatible string
> - Update the commit message to include KEY_SLEEP removal explanation and
> a link back to the original device driver commit. This will allow full
> traceability back to the original patch change
> - Link in information about associated patches from this set without
> describing them as being explicitly dependent on this binding
>
> v1 -> v2
> - Patch renamed from [PATCH V1 06/10] to [PATCH V2 01/10] -- these
> changes were made to fix checkpatch warnings caused by the patch
> set dependency order
> - Typo s/ther/the/ in commit message
> - Explanation about why KEY_SLEEP was removed (see below)
> - Addition of DA9062 example
> - Addition of a DA9061 example to follow the driver fall-back compatible
> convention being applied for this device driver
>
> Hi,
>
> There is also new binding examples for DA9062 and DA9061. Importantly,
> the Linux device driver changes for DA9061 were rejected because the
> DA9062 device driver can be reused. For this reason, the DA9061 example
> uses a fall-back compatible string.
>
> Other information:
> The device driver from this patch set (associated with this binding) was
> applied by Dmitry Torokhov on 26-Oct-2016. See:
> - [PATCH V2 07/10] Input: da9061: onkey driver.
> - https://lkml.org/lkml/2016/10/26/1169
>
> Regards,
> Steve Twiss, Dialog Semiconductor Ltd.
>
>
> .../devicetree/bindings/input/da9062-onkey.txt | 45 ++++++++++++++--------
> 1 file changed, 30 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/da9062-onkey.txt b/Documentation/devicetree/bindings/input/da9062-onkey.txt
> index ab0e048..5f9fbc6 100644
> --- a/Documentation/devicetree/bindings/input/da9062-onkey.txt
> +++ b/Documentation/devicetree/bindings/input/da9062-onkey.txt
> @@ -1,32 +1,47 @@
> -* Dialog DA9062/63 OnKey Module
> +* Dialog DA9061/62/63 OnKey Module
>
> -This module is part of the DA9062/DA9063. For more details about entire
> -chips see Documentation/devicetree/bindings/mfd/da9062.txt and
> -Documentation/devicetree/bindings/mfd/da9063.txt
> +This module is part of the DA9061/DA9062/DA9063. For more details about entire
> +DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
> +For DA9063 see Documentation/devicetree/bindings/mfd/da9063.txt
>
> -This module provides KEY_POWER, KEY_SLEEP and events.
> +This module provides the KEY_POWER event.
>
> Required properties:
>
> -- compatible: should be one of:
> - dlg,da9062-onkey
> - dlg,da9063-onkey
> +- compatible: should be one of the following valid compatible string lines:
> + "dlg,da9061-onkey", "dlg,da9062-onkey"
> + "dlg,da9062-onkey"
> + "dlg,da9063-onkey"
>
> Optional properties:
>
> - - dlg,disable-key-power : Disable power-down using a long key-press. If this
> +- dlg,disable-key-power : Disable power-down using a long key-press. If this
> entry exists the OnKey driver will remove support for the KEY_POWER key
> - press. If this entry does not exist then by default the key-press
> - triggered power down is enabled and the OnKey will support both KEY_POWER
> - and KEY_SLEEP.
> + press when triggered using a long press of the OnKey.
>
> -Example:
> -
> - pmic0: da9062@58 {
> +Example: DA9063
>
> + pmic0: da9063@58 {
> onkey {
> compatible = "dlg,da9063-onkey";
> dlg,disable-key-power;
> };
> + };
> +
> +Example: DA9062
> +
> + pmic0: da9062@58 {
> + onkey {
> + compatible = "dlg,da9062-onkey";
> + dlg,disable-key-power;
> + };
> + };
> +
> +Example: DA9061 using a fall-back compatible for the DA9062 onkey driver
>
> + pmic0: da9061@58 {
> + onkey {
> + compatible = "dlg,da9061-onkey", "dlg,da9062-onkey";
> + dlg,disable-key-power;
> + };
> };
> --
> end-of-patch for PATCH V3
>
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: add GCC plugins Makefile
From: Kees Cook @ 2016-11-09 0:16 UTC (permalink / raw)
To: Andrew Donnellan
Cc: kernel-hardening@lists.openwall.com, linux-kbuild, Emese Revfy,
Michal Marek, LKML
In-Reply-To: <20161102065241.985-1-andrew.donnellan@au1.ibm.com>
On Tue, Nov 1, 2016 at 11:52 PM, Andrew Donnellan
<andrew.donnellan@au1.ibm.com> wrote:
> Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4012c2f..76049e0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5202,6 +5202,7 @@ L: kernel-hardening@lists.openwall.com
> S: Maintained
> F: scripts/gcc-plugins/
> F: scripts/gcc-plugin.sh
> +F: scripts/Makefile.gcc-plugins
> F: Documentation/gcc-plugins.txt
>
> GCOV BASED KERNEL PROFILING
Ah, good call. I've added this for -next now. Thanks!
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply
* [kernel-hardening] Re: [PATCH] MAINTAINERS: add GCC plugins Makefile
From: Kees Cook @ 2016-11-09 0:16 UTC (permalink / raw)
To: Andrew Donnellan
Cc: kernel-hardening@lists.openwall.com, linux-kbuild, Emese Revfy,
Michal Marek, LKML
In-Reply-To: <20161102065241.985-1-andrew.donnellan@au1.ibm.com>
On Tue, Nov 1, 2016 at 11:52 PM, Andrew Donnellan
<andrew.donnellan@au1.ibm.com> wrote:
> Signed-off-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4012c2f..76049e0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5202,6 +5202,7 @@ L: kernel-hardening@lists.openwall.com
> S: Maintained
> F: scripts/gcc-plugins/
> F: scripts/gcc-plugin.sh
> +F: scripts/Makefile.gcc-plugins
> F: Documentation/gcc-plugins.txt
>
> GCOV BASED KERNEL PROFILING
Ah, good call. I've added this for -next now. Thanks!
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply
* Re: [PATCH] video: mxsfb: get supply regulator optionally
From: Stefan Agner @ 2016-11-09 0:16 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: plagnioj-sclMFOaUSTBWk0Htik3J/w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Brown
In-Reply-To: <1812b2bf-bd66-3553-4c2d-3d2b08603ca0-l0cyMroinI0@public.gmane.org>
Hi Tomi,
I vote to merge this patch, see below:
On 2016-09-07 00:20, Tomi Valkeinen wrote:
> On 06/09/16 21:23, Stefan Agner wrote:
>> On 2016-09-06 01:21, Tomi Valkeinen wrote:
>>> Hi,
>>>
>>> On 04/09/16 07:26, Stefan Agner wrote:
>>>> The lcd-supply is meant to be optional, there are several device-
>>>> trees not specifying it and the code handles error values silently.
>>>> Therefor, avoid creating a dummy regulator (and the associated
>>>> warning) by using devm_regulator_get_optional.
>>>>
>>>> While at it, document that fact also in the device-tree bindings.
>>>
>>> The binding change looks correct, but using
>>> devm_regulator_get_optional() does not sound correct.
>>>
>>> devm_regulator_get_optional() is to be used when the device in question
>>> truly can function without the power supply. But if the supply is there,
>>> it's just not controlled by the SW, devm_regulator_get() is to be used.
>>
>> The framebuffer device can even function without a display, no problem
>> there.. Probably not really useful...
>
> Yes. Of course, the question then becomes, why is the fb driver even
> dealing with the LCD's regulator. But yes, I know the answer: because
> that's how it has been done =).
Agreed, this property really shouldn't be part of the display controller
node.
The device tree should describe the hardware, and that is clearly not
how the hardware is wired up...
The DRM solution to this is having a separate panel node with a
(mandatory) power-supply property.
>
>> devm_regulator_get creates a dummy regulator and a warning. Afaik, the
>> dummy regulator was meant to be as an aid during development, but not as
>> a permanent solution. This is what the initial commit of the dummy
>> regulator says:
>
> Yep, the fixed regulator is afaik the correct solution to represent
> non-controllable regulators.
>
>>> In order to ease transitions with drivers are boards start using regulators
>>> provide an option to cause all regulator_get() calls to succeed, with a
>>> dummy always on regulator being supplied where one has not been configured.
>>> A warning is printed whenever the dummy regulator is used to aid system
>>> development.
>>
>> I think we should either make the property mandatory and fix the device
>> trees or we should fix the driver to support an optional regulator. The
>> code already supports the reg_lcd being NULL, which is probably mostly
>> pointless right now as devm_regulator_get always returns a dummy
>> regulator.
>
> To really clean this up, the LCD driver should be separated from the fb
> driver. But that's pointless work on a framework that should be
> deprecated (is there a DRM driver for this in the works? =).
Not that I am aware of, but I am considering it actually...
>
> I'm fine with the _optional version, that's the easiest cleanup here.
> And, I guess, it could be even argued that it's correct in some cases,
> as the fb output could go outside the board, to some externally powered
> display.
>
> I'm fine with doing more cleanups too, if it eases the maintenance
> burden in the future. But I don't see what the cleanups for the device
> trees would really give us here.
>
> Mark, what do you say?
So this is what mark said:
On 2016-09-12 16:47, Mark Brown wrote:
> On Wed, Sep 07, 2016 at 10:20:25AM +0300, Tomi Valkeinen wrote:
>
>> I'm fine with the _optional version, that's the easiest cleanup here.
>> And, I guess, it could be even argued that it's correct in some cases,
>> as the fb output could go outside the board, to some externally powered
>> display.
>
> I'd *prefer* to see the supplies being specified, if only for the
> encouragement of the others. But if you want to do the optional thing
> anyway...
In this case we really don't want people encourage using this
property... Making it optional is not the solution, but a band aid until
we have a proper solution (and deprecate the property...)
--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] video: mxsfb: get supply regulator optionally
From: Stefan Agner @ 2016-11-09 0:16 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: plagnioj-sclMFOaUSTBWk0Htik3J/w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Brown
In-Reply-To: <1812b2bf-bd66-3553-4c2d-3d2b08603ca0-l0cyMroinI0@public.gmane.org>
Hi Tomi,
I vote to merge this patch, see below:
On 2016-09-07 00:20, Tomi Valkeinen wrote:
> On 06/09/16 21:23, Stefan Agner wrote:
>> On 2016-09-06 01:21, Tomi Valkeinen wrote:
>>> Hi,
>>>
>>> On 04/09/16 07:26, Stefan Agner wrote:
>>>> The lcd-supply is meant to be optional, there are several device-
>>>> trees not specifying it and the code handles error values silently.
>>>> Therefor, avoid creating a dummy regulator (and the associated
>>>> warning) by using devm_regulator_get_optional.
>>>>
>>>> While at it, document that fact also in the device-tree bindings.
>>>
>>> The binding change looks correct, but using
>>> devm_regulator_get_optional() does not sound correct.
>>>
>>> devm_regulator_get_optional() is to be used when the device in question
>>> truly can function without the power supply. But if the supply is there,
>>> it's just not controlled by the SW, devm_regulator_get() is to be used.
>>
>> The framebuffer device can even function without a display, no problem
>> there.. Probably not really useful...
>
> Yes. Of course, the question then becomes, why is the fb driver even
> dealing with the LCD's regulator. But yes, I know the answer: because
> that's how it has been done =).
Agreed, this property really shouldn't be part of the display controller
node.
The device tree should describe the hardware, and that is clearly not
how the hardware is wired up...
The DRM solution to this is having a separate panel node with a
(mandatory) power-supply property.
>
>> devm_regulator_get creates a dummy regulator and a warning. Afaik, the
>> dummy regulator was meant to be as an aid during development, but not as
>> a permanent solution. This is what the initial commit of the dummy
>> regulator says:
>
> Yep, the fixed regulator is afaik the correct solution to represent
> non-controllable regulators.
>
>>> In order to ease transitions with drivers are boards start using regulators
>>> provide an option to cause all regulator_get() calls to succeed, with a
>>> dummy always on regulator being supplied where one has not been configured.
>>> A warning is printed whenever the dummy regulator is used to aid system
>>> development.
>>
>> I think we should either make the property mandatory and fix the device
>> trees or we should fix the driver to support an optional regulator. The
>> code already supports the reg_lcd being NULL, which is probably mostly
>> pointless right now as devm_regulator_get always returns a dummy
>> regulator.
>
> To really clean this up, the LCD driver should be separated from the fb
> driver. But that's pointless work on a framework that should be
> deprecated (is there a DRM driver for this in the works? =).
Not that I am aware of, but I am considering it actually...
>
> I'm fine with the _optional version, that's the easiest cleanup here.
> And, I guess, it could be even argued that it's correct in some cases,
> as the fb output could go outside the board, to some externally powered
> display.
>
> I'm fine with doing more cleanups too, if it eases the maintenance
> burden in the future. But I don't see what the cleanups for the device
> trees would really give us here.
>
> Mark, what do you say?
So this is what mark said:
On 2016-09-12 16:47, Mark Brown wrote:
> On Wed, Sep 07, 2016 at 10:20:25AM +0300, Tomi Valkeinen wrote:
>
>> I'm fine with the _optional version, that's the easiest cleanup here.
>> And, I guess, it could be even argued that it's correct in some cases,
>> as the fb output could go outside the board, to some externally powered
>> display.
>
> I'd *prefer* to see the supplies being specified, if only for the
> encouragement of the others. But if you want to do the optional thing
> anyway...
In this case we really don't want people encourage using this
property... Making it optional is not the solution, but a band aid until
we have a proper solution (and deprecate the property...)
--
Stefan
^ permalink raw reply
* Re: [PATCH] u-boot: mkimage: Fix build of u-boot-mkimage
From: Burton, Ross @ 2016-11-09 0:15 UTC (permalink / raw)
To: Marek Vasut; +Cc: OE-core
In-Reply-To: <20161107182006.4207-1-marex@denx.de>
[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]
On 7 November 2016 at 18:20, Marek Vasut <marex@denx.de> wrote:
> -EXTRA_OEMAKE = 'CROSS_COMPILE="${TARGET_PREFIX}" CC="${CC} ${CFLAGS}
> ${LDFLAGS}" STRIP=true V=1'
> +EXTRA_OEMAKE = 'HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"'
> +EXTRA_OEMAKE_append_class-target = 'CROSS_COMPILE="${TARGET_PREFIX}"
> CC="${CC} ${CFLAGS} ${LDFLAGS}" STRIP=true V=1'
> +EXTRA_OEMAKE_append_class-native = 'CC="${BUILD_CC} ${BUILD_CFLAGS}
> ${BUILD_LDFLAGS}" STRIP=true V=1'
> +EXTRA_OEMAKE_append_class-nativesdk = 'CC="${BUILD_CC} ${BUILD_CFLAGS}
> ${BUILD_LDFLAGS}" STRIP=true V=1'
>
You're going to start hating u-boot...
Fails on the autobuilder if you're building for a 32-bit x86 target on a
64-bit x86 host:
ERROR: QA Issue: Architecture did not match (x86-64, expected x86) on
/work/i586-poky-linux-musl/u-boot-mkimage/1_2016.09.01-r0/packages-split/u-boot-mkimage/usr/bin/uboot-mkimage
[arch]
I'm guessing that it is using the host compiler instead of the cross
compiler.
Ross
[-- Attachment #2: Type: text/html, Size: 1677 bytes --]
^ permalink raw reply
* Re: [PATCH v7 00/17] port branch.c to use ref-filter's printing options
From: Jacob Keller @ 2016-11-09 0:15 UTC (permalink / raw)
To: Karthik Nayak; +Cc: Git mailing list
In-Reply-To: <20161108201211.25213-1-Karthik.188@gmail.com>
On Tue, Nov 8, 2016 at 12:11 PM, Karthik Nayak <karthik.188@gmail.com> wrote:
> This is part of unification of the commands 'git tag -l, git branch -l
> and git for-each-ref'. This ports over branch.c to use ref-filter's
> printing options.
>
> Initially posted here: $(gmane/279226). It was decided that this series
> would follow up after refactoring ref-filter parsing mechanism, which
> is now merged into master (9606218b32344c5c756f7c29349d3845ef60b80c).
>
> v1 can be found here: $(gmane/288342)
> v2 can be found here: $(gmane/288863)
> v3 can be found here: $(gmane/290299)
> v4 can be found here: $(gmane/291106)
> v5b can be found here: $(gmane/292467)
> v6 can be found here: http://marc.info/?l=git&m=146330914118766&w=2
>
I reviewed the full series. I found a few minor things I would have
done differently, but overall I think it looks good. Thanks for the
hard work and the time invested here. I remember seeing this on the
list quite some time ago, so it's nice to see it finally come
together.
Thanks,
Jake
> Changes in this version:
>
> 1. Rebased on top of master.
>
> Karthik Nayak (17):
> ref-filter: implement %(if), %(then), and %(else) atoms
> ref-filter: include reference to 'used_atom' within 'atom_value'
> ref-filter: implement %(if:equals=<string>) and
> %(if:notequals=<string>)
> ref-filter: modify "%(objectname:short)" to take length
> ref-filter: move get_head_description() from branch.c
> ref-filter: introduce format_ref_array_item()
> ref-filter: make %(upstream:track) prints "[gone]" for invalid
> upstreams
> ref-filter: add support for %(upstream:track,nobracket)
> ref-filter: make "%(symref)" atom work with the ':short' modifier
> ref-filter: introduce refname_atom_parser_internal()
> ref-filter: introduce symref_atom_parser() and refname_atom_parser()
> ref-filter: make remote_ref_atom_parser() use
> refname_atom_parser_internal()
> ref-filter: add `:dir` and `:base` options for ref printing atoms
> ref-filter: allow porcelain to translate messages in the output
> branch, tag: use porcelain output
> branch: use ref-filter printing APIs
> branch: implement '--format' option
>
> Documentation/git-branch.txt | 7 +-
> Documentation/git-for-each-ref.txt | 82 ++++++-
> builtin/branch.c | 277 +++++++---------------
> builtin/tag.c | 2 +
> ref-filter.c | 456 +++++++++++++++++++++++++++++++------
> ref-filter.h | 7 +
> t/t3203-branch-output.sh | 16 +-
> t/t6040-tracking-info.sh | 2 +-
> t/t6300-for-each-ref.sh | 73 +++++-
> t/t6302-for-each-ref-filter.sh | 94 ++++++++
> 10 files changed, 725 insertions(+), 291 deletions(-)
>
> --
> 2.10.2
>
^ permalink raw reply
* ceph
From: shi lei @ 2016-11-09 0:15 UTC (permalink / raw)
To: ceph-devel
subscribe ceph-devel
^ permalink raw reply
* Re: [PATCH 0/2] qla2xxx: fix errors in PCI device remove with ongoing I/O
From: Martin K. Petersen @ 2016-11-09 0:14 UTC (permalink / raw)
To: Mauricio Faria de Oliveira
Cc: qla2xxx-upstream, jejb, martin.petersen, linux-scsi, linux-kernel
In-Reply-To: <1478548411-17932-1-git-send-email-mauricfo@linux.vnet.ibm.com>
>>>>> "Mauricio" == Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> writes:
Mauricio> This patchset addresses a couple of errors that might happen
Mauricio> during PCI device remove (e.g., PCI hotplug, PowerVM DLPAR),
Mauricio> which prevent the successful removal and re-addition of the
Mauricio> adapter to the system, and cause an oops and/or invalid DMA
Mauricio> access (triggers an EEH event).
Applied to 4.9/scsi-fixes.
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* linux-next: build failure after merge of the drm-misc tree
From: Stephen Rothwell @ 2016-11-09 0:14 UTC (permalink / raw)
To: Daniel Vetter, Intel Graphics, DRI; +Cc: linux-next, linux-kernel
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "depot_save_stack" [drivers/gpu/drm/drm.ko] undefined!
ERROR: "depot_fetch_stack" [drivers/gpu/drm/drm.ko] undefined!
Caused by commit
5705670d0463 ("drm: Track drm_mm allocators and show leaks on shutdown")
I hate used the drm-misc tree from next-20161108 for today.
--
Cheers,
Stephen Rothwell
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [Patch v2 12/14] ltp: Reduce duplication in MIPS variants.
From: Burton, Ross @ 2016-11-09 0:13 UTC (permalink / raw)
To: Zubair Lutfullah Kakakhel; +Cc: OE-core
In-Reply-To: <20161108171235.41837-13-Zubair.Kakakhel@imgtec.com>
[-- Attachment #1: Type: text/plain, Size: 324 bytes --]
On 8 November 2016 at 17:12, Zubair Lutfullah Kakakhel <
Zubair.Kakakhel@imgtec.com> wrote:
> Reduce duplication in MIPS variants now that the MACHINEOVERRIDES
> variable is defined
>
I'm guessing that this is the cause of this error for qemumips64:
http://errors.yoctoproject.org/Errors/Details/99744/
Ross
[-- Attachment #2: Type: text/html, Size: 959 bytes --]
^ permalink raw reply
* Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a process to migrate other tasks between cgroups
From: Andy Lutomirski @ 2016-11-09 0:12 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Andy Lutomirski, John Stultz, Mickaël Salaün,
Daniel Mack, David S. Miller, kafai, fw, Harald Hoyer,
Network Development, Sargun Dhillon, Pablo Neira Ayuso, lkml,
Tejun Heo, Li Zefan, Jonathan Corbet,
open list:CONTROL GROUP (CGROUP), Android Kernel Team,
Rom Lemarchand, Colin Cross, Dmitry Shmidt, Todd Kjos,
Christian Poetzsch, Amit Pundir, Dmitry Torokhov, Kees Cook,
Serge E . Hallyn, Linux API
In-Reply-To: <20161109000342.GA42532@ast-mbp.thefacebook.com>
On Tue, Nov 8, 2016 at 4:03 PM, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Tue, Nov 08, 2016 at 03:51:40PM -0800, Andy Lutomirski wrote:
>> On Tue, Nov 8, 2016 at 3:28 PM, John Stultz <john.stultz@linaro.org> wrote:
>> > This patch adds logic to allows a process to migrate other tasks
>> > between cgroups if they have CAP_SYS_RESOURCE.
>> >
>> > In Android (where this feature originated), the ActivityManager tracks
>> > various application states (TOP_APP, FOREGROUND, BACKGROUND, SYSTEM,
>> > etc), and then as applications change states, the SchedPolicy logic
>> > will migrate the application tasks between different cgroups used
>> > to control the different application states (for example, there is a
>> > background cpuset cgroup which can limit background tasks to stay
>> > on one low-power cpu, and the bg_non_interactive cpuctrl cgroup can
>> > then further limit those background tasks to a small percentage of
>> > that one cpu's cpu time).
>> >
>> > However, for security reasons, Android doesn't want to make the
>> > system_server (the process that runs the ActivityManager and
>> > SchedPolicy logic), run as root. So in the Android common.git
>> > kernel, they have some logic to allow cgroups to loosen their
>> > permissions so CAP_SYS_NICE tasks can migrate other tasks between
>> > cgroups.
>> >
>> > I feel the approach taken there overloads CAP_SYS_NICE a bit much
>> > for non-android environments.
>> >
>> > So this patch, as suggested by Michael Kerrisk, simply adds a
>> > check for CAP_SYS_RESOURCE.
>> >
>> > I've tested this with AOSP master, and this seems to work well
>> > as Zygote and system_server already use CAP_SYS_RESOURCE. I've
>> > also submitted patches against the android-4.4 kernel to change
>> > it to use CAP_SYS_RESOURCE, and the Android developers just merged
>> > it.
>> >
>>
>> I hate to say it, but I think I may see a problem. Current
>> developments are afoot to make cgroups do more than resource control.
>> For example, there's Landlock and there's Daniel's ingress/egress
>> filter thing. Current cgroup controllers can mostly just DoS their
>> controlled processes. These new controllers (or controller-like
>> things) can exfiltrate data and change semantics.
>>
>> Does anyone have a security model in mind for these controllers and
>> the cgroups that they're attached to? I'm reasonably confident that
>> CAP_SYS_RESOURCE is not the answer...
>
> and specifically the answer is... ?
> Also would be great if you start with specifying the question first
> and the problem you're trying to solve.
>
I don't have a good answer right now. Here are some constraints, though:
1. An insufficiently privileged process should not be able to move a
victim into a dangerous cgroup.
2. An insufficiently privileged process should not be able to move
itself into a dangerous cgroup and then use execve to gain privilege
such that the execve'd program can be compromised.
3. An insufficiently privileged process should not be able to make an
existing cgroup dangerous in a way that could compromise a victim in
that cgroup.
4. An insufficiently privileged process should not be able to make a
cgroup dangerous in a way that bypasses protections that would
otherwise protect execve() as used by itself or some other process in
that cgroup.
Keep in mind that "dangerous" may apply to a cgroup's descendents in
addition to the cgroup being controlled.
^ permalink raw reply
* Re: [RESEND][PATCH v4] cgroup: Use CAP_SYS_RESOURCE to allow a process to migrate other tasks between cgroups
From: Andy Lutomirski @ 2016-11-09 0:12 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Andy Lutomirski, John Stultz, Mickaël Salaün,
Daniel Mack, David S. Miller, kafai, fw, Harald Hoyer,
Network Development, Sargun Dhillon, Pablo Neira Ayuso, lkml,
Tejun Heo, Li Zefan, Jonathan Corbet,
open list:CONTROL GROUP (CGROUP), Android Kernel Team,
Rom Lemarchand, Colin Cross, Dmitry Shmidt, Todd Kjos
In-Reply-To: <20161109000342.GA42532@ast-mbp.thefacebook.com>
On Tue, Nov 8, 2016 at 4:03 PM, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Tue, Nov 08, 2016 at 03:51:40PM -0800, Andy Lutomirski wrote:
>> On Tue, Nov 8, 2016 at 3:28 PM, John Stultz <john.stultz@linaro.org> wrote:
>> > This patch adds logic to allows a process to migrate other tasks
>> > between cgroups if they have CAP_SYS_RESOURCE.
>> >
>> > In Android (where this feature originated), the ActivityManager tracks
>> > various application states (TOP_APP, FOREGROUND, BACKGROUND, SYSTEM,
>> > etc), and then as applications change states, the SchedPolicy logic
>> > will migrate the application tasks between different cgroups used
>> > to control the different application states (for example, there is a
>> > background cpuset cgroup which can limit background tasks to stay
>> > on one low-power cpu, and the bg_non_interactive cpuctrl cgroup can
>> > then further limit those background tasks to a small percentage of
>> > that one cpu's cpu time).
>> >
>> > However, for security reasons, Android doesn't want to make the
>> > system_server (the process that runs the ActivityManager and
>> > SchedPolicy logic), run as root. So in the Android common.git
>> > kernel, they have some logic to allow cgroups to loosen their
>> > permissions so CAP_SYS_NICE tasks can migrate other tasks between
>> > cgroups.
>> >
>> > I feel the approach taken there overloads CAP_SYS_NICE a bit much
>> > for non-android environments.
>> >
>> > So this patch, as suggested by Michael Kerrisk, simply adds a
>> > check for CAP_SYS_RESOURCE.
>> >
>> > I've tested this with AOSP master, and this seems to work well
>> > as Zygote and system_server already use CAP_SYS_RESOURCE. I've
>> > also submitted patches against the android-4.4 kernel to change
>> > it to use CAP_SYS_RESOURCE, and the Android developers just merged
>> > it.
>> >
>>
>> I hate to say it, but I think I may see a problem. Current
>> developments are afoot to make cgroups do more than resource control.
>> For example, there's Landlock and there's Daniel's ingress/egress
>> filter thing. Current cgroup controllers can mostly just DoS their
>> controlled processes. These new controllers (or controller-like
>> things) can exfiltrate data and change semantics.
>>
>> Does anyone have a security model in mind for these controllers and
>> the cgroups that they're attached to? I'm reasonably confident that
>> CAP_SYS_RESOURCE is not the answer...
>
> and specifically the answer is... ?
> Also would be great if you start with specifying the question first
> and the problem you're trying to solve.
>
I don't have a good answer right now. Here are some constraints, though:
1. An insufficiently privileged process should not be able to move a
victim into a dangerous cgroup.
2. An insufficiently privileged process should not be able to move
itself into a dangerous cgroup and then use execve to gain privilege
such that the execve'd program can be compromised.
3. An insufficiently privileged process should not be able to make an
existing cgroup dangerous in a way that could compromise a victim in
that cgroup.
4. An insufficiently privileged process should not be able to make a
cgroup dangerous in a way that bypasses protections that would
otherwise protect execve() as used by itself or some other process in
that cgroup.
Keep in mind that "dangerous" may apply to a cgroup's descendents in
addition to the cgroup being controlled.
^ permalink raw reply
* Re: [PATCH 4.9/scsi-fixes] libcxgbi: fix incorrect DDP resource cleanup
From: Martin K. Petersen @ 2016-11-09 0:12 UTC (permalink / raw)
To: Varun Prakash; +Cc: martin.petersen, jejb, linux-scsi, indranil
In-Reply-To: <1478362768-19895-1-git-send-email-varun@chelsio.com>
>>>>> "Varun" == Varun Prakash <varun@chelsio.com> writes:
Varun> Before calling task_release_itt() task data is memset to zero
Varun> because of which DDP context information is lost resulting in
Varun> incorrect DDP resource cleanup, to fix this call
Varun> task_release_itt() before memset.
Applied to 4.9/scsi-fixes.
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* bluestore SMR update?
From: Darrell Enns @ 2016-11-09 0:12 UTC (permalink / raw)
To: 'ceph-devel@vger.kernel.org'
In-Reply-To: <04EA9170BFDB1B4BB5C8DF4AA2815C11BE932B5D@KNEX2.knc.local>
Is there any update on the GSOC Bluestore SMR project? It seems that the progress report wiki page has not been updated since May. I'm very interested in the findings and what (if anything) has yet to be done to improve bluestore SMR support.
Thanks,
Darrell
^ permalink raw reply
* [PATCH] perf tools pt: Remove obsolete paragraph in intel-pt.c
From: Andi Kleen @ 2016-11-09 0:11 UTC (permalink / raw)
To: acme; +Cc: linux-kernel, Andi Kleen, adrian.hunter
From: Andi Kleen <ak@linux.intel.com>
Since the unprivileged sched switch event was added in perf,
PT doesn't need need perf_event_paranoid=-1 anymore for
per cpu decoding. So remove the obsolete paragraph in
the documentation.
Cc: adrian.hunter@intel.com
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
tools/perf/Documentation/intel-pt.txt | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/tools/perf/Documentation/intel-pt.txt b/tools/perf/Documentation/intel-pt.txt
index c6c8318e38a2..c7f817fd3611 100644
--- a/tools/perf/Documentation/intel-pt.txt
+++ b/tools/perf/Documentation/intel-pt.txt
@@ -550,16 +550,6 @@ Unless /proc/sys/kernel/perf_event_paranoid is set to -1, unprivileged users
have memory limits imposed upon them. That affects what buffer sizes they can
have as outlined above.
-Unless /proc/sys/kernel/perf_event_paranoid is set to -1, unprivileged users are
-not permitted to use tracepoints which means there is insufficient side-band
-information to decode Intel PT in per-cpu mode, and potentially workload-only
-mode too if the workload creates new processes.
-
-Note also, that to use tracepoints, read-access to debugfs is required. So if
-debugfs is not mounted or the user does not have read-access, it will again not
-be possible to decode Intel PT in per-cpu mode.
-
-
sched_switch tracepoint
-----------------------
--
2.5.5
^ permalink raw reply related
* [PATCH 2/2] systemtap: fix native linking on recent Ubuntu
From: Ross Burton @ 2016-11-09 0:10 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1478650244-7002-1-git-send-email-ross.burton@intel.com>
The latest Ubuntu uses yet more aggressive hardening options, which causes the
unconventional build order used by systemtap to fail.
[ YOCTO #10521 ]
Signed-off-by: Ross Burton <ross.burton@intel.com>
---
.../systemtap/systemtap/fix-monitor-linking.patch | 41 ++++++++++++++++++++++
meta/recipes-kernel/systemtap/systemtap_git.inc | 1 +
2 files changed, 42 insertions(+)
create mode 100644 meta/recipes-kernel/systemtap/systemtap/fix-monitor-linking.patch
diff --git a/meta/recipes-kernel/systemtap/systemtap/fix-monitor-linking.patch b/meta/recipes-kernel/systemtap/systemtap/fix-monitor-linking.patch
new file mode 100644
index 0000000..2bf0742a1
--- /dev/null
+++ b/meta/recipes-kernel/systemtap/systemtap/fix-monitor-linking.patch
@@ -0,0 +1,41 @@
+Upstream-Status: Submitted
+Signed-off-by: Ross Burton <ross.burton@intel.com>
+
+From d940aa0079c253b958cf9158e9ec7922ecf464f9 Mon Sep 17 00:00:00 2001
+From: Ross Burton <ross.burton@intel.com>
+Date: Wed, 9 Nov 2016 00:00:48 +0000
+Subject: [PATCH] staprun: fix linking if monitor is enabled
+
+If the monitor is enabled, monitor.c needs to link against json-c and ncurses.
+Instead of adding these linker flags to AM_CFLAGS (global CC flags) add them to
+stapio_LDADD.
+
+Apart from being the "right" thing to do, this fixes build failures on systems
+such as current Ubuntu (which defaults to using --as-needed and similar) where
+link order is important.
+---
+ staprun/Makefile.am | 7 +++----
+ 1 file changed, 3 insertions(+), 4 deletions(-)
+
+diff --git a/staprun/Makefile.am b/staprun/Makefile.am
+index 63d4088..66b3e21 100644
+--- a/staprun/Makefile.am
++++ b/staprun/Makefile.am
+@@ -42,12 +42,11 @@ staprun_CXXFLAGS += $(nss_CFLAGS)
+ staprun_LDADD += $(nss_LIBS)
+ endif
+
+-if HAVE_MONITOR_LIBS
+-AM_CFLAGS += $(jsonc_LIBS) $(ncurses_LIBS)
+-endif
+-
+ stapio_SOURCES = stapio.c mainloop.c common.c ctl.c relay.c relay_old.c monitor.c
+ stapio_LDADD = libstrfloctime.a -lpthread
++if HAVE_MONITOR_LIBS
++stapio_LDADD += $(jsonc_LIBS) $(ncurses_LIBS)
++endif
+
+ man_MANS = staprun.8
+
+--
+2.8.1
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.inc b/meta/recipes-kernel/systemtap/systemtap_git.inc
index 34cf227..a0f0e68 100644
--- a/meta/recipes-kernel/systemtap/systemtap_git.inc
+++ b/meta/recipes-kernel/systemtap/systemtap_git.inc
@@ -10,6 +10,7 @@ SRC_URI = "git://sourceware.org/git/systemtap.git \
file://x32_abi_time.patch \
file://monitor-option.patch \
file://no-msgfmt-check.patch \
+ file://fix-monitor-linking.patch \
"
# systemtap doesn't support mips
--
2.8.1
^ permalink raw reply related
* [PATCH 1/2] systemtap: remove explicit msgfmt check
From: Ross Burton @ 2016-11-09 0:10 UTC (permalink / raw)
To: openembedded-core
Passing --disable-nls should be enough to disable the requirement for a full
gettext to be present, but the upstream configure explicitly checks for msgfmt
even if it isn't going to be used. To avoid having to depend on gettext-native,
patch this check out.
Signed-off-by: Ross Burton <ross.burton@intel.com>
---
.../systemtap/systemtap/no-msgfmt-check.patch | 15 +++++++++++++++
meta/recipes-kernel/systemtap/systemtap_git.inc | 1 +
2 files changed, 16 insertions(+)
create mode 100644 meta/recipes-kernel/systemtap/systemtap/no-msgfmt-check.patch
diff --git a/meta/recipes-kernel/systemtap/systemtap/no-msgfmt-check.patch b/meta/recipes-kernel/systemtap/systemtap/no-msgfmt-check.patch
new file mode 100644
index 0000000..471e62c
--- /dev/null
+++ b/meta/recipes-kernel/systemtap/systemtap/no-msgfmt-check.patch
@@ -0,0 +1,15 @@
+There is no need to explicitly check that msgfmt was found as the gettext macros
+handle this for us if NLS is enabled.
+
+Upstream-Status: Pending
+Signed-off-by: Ross Burton <ross.burton@intel.com>
+
+diff --git a/configure.ac b/configure.ac
+index e56079a..284bbe0 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -39,4 +38,0 @@ AM_GNU_GETTEXT_VERSION([0.19.4])
+-if test "x$GMSGFMT" = "x:"; then
+- AC_MSG_ERROR([missing gnu /usr/bin/msgfmt])
+-fi
+-
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.inc b/meta/recipes-kernel/systemtap/systemtap_git.inc
index 304eb99..34cf227 100644
--- a/meta/recipes-kernel/systemtap/systemtap_git.inc
+++ b/meta/recipes-kernel/systemtap/systemtap_git.inc
@@ -9,6 +9,7 @@ SRC_URI = "git://sourceware.org/git/systemtap.git \
file://configure-allow-to-disable-libvirt.patch \
file://x32_abi_time.patch \
file://monitor-option.patch \
+ file://no-msgfmt-check.patch \
"
# systemtap doesn't support mips
--
2.8.1
^ permalink raw reply related
* Re: [PATCH 1/2] Input: gpio_keys - Also send release events for ABS codes
From: Dmitry Torokhov @ 2016-11-09 0:09 UTC (permalink / raw)
To: Paul Cercueil
Cc: Laxman Dewangan, linux-input, linux-kernel, Maarten ter Huurne
In-Reply-To: <56a0750b-c0f6-1fad-c730-11213dd64a97@crapouillou.net>
On Sat, Nov 05, 2016 at 12:58:00PM +0100, Paul Cercueil wrote:
> On 03/11/2016 17:21, Dmitry Torokhov wrote:
> >On Tue, Nov 01, 2016 at 11:25:03AM +0100, Paul Cercueil wrote:
> >>Right now, the gpio-keys driver is mostly used with EV_KEY event types.
> >>However, this driver (and its devicetree bindings) support specifying
> >>a different input type, like EV_ABS, even though this doesn't work in
> >>practice: "key pressed" events are correctly received and treated, but
> >>"key released" are silently ignored.
> >>
> >>With this commit, keys configured as EV_ABS will inject an event with
> >>the value 0 when released.
> >No, this will break setups like this:
> >
> >gpio0 - ABS_X - 0
> >gpio1 - ABS_X - 1
> >gpio2 - ABS_X - 2
> >...
> >gpio7 - ABS_X - 7
> >
> >- something like a slider built on top of gpios.
>
> So what would you suggest for the implementation of a hat / d-pad on
> top of GPIOs?
Maybe we should allow specifying "release" value for ABS GPIOs.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: Question regarding PWM types in AST2500
From: Anton D. Kachalov @ 2016-11-09 0:01 UTC (permalink / raw)
To: Jaghathiswari Rankappagounder Natarajan, OpenBMC Maillist
In-Reply-To: <CANsWYUXcJ6zKwJ2R2maOJLHxMGjMCPELvFatW5F6nUNzf1Lf6A@mail.gmail.com>
[-- Attachment #1: Type: text/html, Size: 1535 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/6] qedi: Add QLogic FastLinQ offload iSCSI driver framework.
From: Martin K. Petersen @ 2016-11-09 0:07 UTC (permalink / raw)
To: Arun Easi
Cc: Martin K. Petersen, kbuild test robot, Manish Rangankar,
kbuild-all, James Bottomley, lduncan, cleech, linux-scsi, netdev,
QLogic-Storage-Upstream, Yuval Mintz
In-Reply-To: <alpine.LRH.2.00.1611081555110.28058@mvluser05.qlc.com>
>>>>> "Arun" == Arun Easi <arun.easi@cavium.com> writes:
>> It's fine to post the patches split up to ease the review
>> process. But whatever we commit must obviously be bisectable.
Arun> If it is alright with you, we would like to have all of our
Arun> initial patches for the driver (qedi) squashed as a single commit
Arun> to the tree. We will ensure that this single combined commit
Arun> compiles clean.
That's fine with me.
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* [Buildroot] [PATCH for/next] krb5: new package
From: Daniel Price @ 2016-11-09 0:07 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161108005032.11340-1-arnout@mind.be>
Thanks! Based on the earlier recipe, we have krb5 and pam-krb5 at least
compiling. We will get it installed and work on some testing. I'll see if
I can get us rebased onto this patch.
Thank-you to the community. I really appreciate the help.
-dp
On Mon, Nov 7, 2016 at 4:50 PM, Arnout Vandecappelle (Essensium/Mind) <
arnout@mind.be> wrote:
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> Cc: Daniel Price <daniel.price@gmail.com>
> Cc: Charles Hardin <ckhardin@exablox.com>
> ---
> Note: I do NOT want to be added to DEVELOPERS for this package, it's
> just something I cobbled together quickly.
> ---
> package/Config.in | 1 +
> package/krb5/Config.in | 13 ++++++++++++
> package/krb5/krb5.hash | 2 ++
> package/krb5/krb5.mk | 55 ++++++++++++++++++++++++++++++
> ++++++++++++++++++++
> 4 files changed, 71 insertions(+)
> create mode 100644 package/krb5/Config.in
> create mode 100644 package/krb5/krb5.hash
> create mode 100644 package/krb5/krb5.mk
>
> diff --git a/package/Config.in b/package/Config.in
> index 0d449dc..83ce629 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -1189,6 +1189,7 @@ menu "Networking"
> source "package/gupnp-dlna/Config.in"
> source "package/ibrcommon/Config.in"
> source "package/ibrdtn/Config.in"
> + source "package/krb5/Config.in"
> source "package/libcgi/Config.in"
> source "package/libcgicc/Config.in"
> source "package/libcoap/Config.in"
> diff --git a/package/krb5/Config.in b/package/krb5/Config.in
> new file mode 100644
> index 0000000..43fd799
> --- /dev/null
> +++ b/package/krb5/Config.in
> @@ -0,0 +1,13 @@
> +config BR2_PACKAGE_KRB5
> + bool "krb5"
> + depends on BR2_USE_MMU # fork()
> + help
> + KRB5 is the MIT Kerberos Version 5 implementation
> +
> + Kerberos is a network authentication protocol. It is designed
> + to provide strong authentication for client/server
> + applications by using secret-key cryptography. A free
> + implementation of this protocol is available from the
> + Massachusetts Institute of Technology.
> +
> + http://web.mit.edu/Kerberos
> diff --git a/package/krb5/krb5.hash b/package/krb5/krb5.hash
> new file mode 100644
> index 0000000..22cd970
> --- /dev/null
> +++ b/package/krb5/krb5.hash
> @@ -0,0 +1,2 @@
> +# Locally calculated after checking pgp signature from
> https://web.mit.edu/kerberos/krb5-1.14/krb5-1.14.4.sig
> +sha256 03a61a4280c9161771fb39019085dbe6a57aa602080515ff93b43cd6137e0b95
> krb5-1.14.4.tar.gz
> diff --git a/package/krb5/krb5.mk b/package/krb5/krb5.mk
> new file mode 100644
> index 0000000..59603c5
> --- /dev/null
> +++ b/package/krb5/krb5.mk
> @@ -0,0 +1,55 @@
> +###########################################################
> #####################
> +#
> +# krb5
> +#
> +###########################################################
> #####################
> +
> +KRB5_VERSION_MAJOR = 1.14
> +KRB5_VERSION = $(KRB5_VERSION_MAJOR).4
> +KRB5_SITE = http://web.mit.edu/kerberos/dist/krb5/$(KRB5_VERSION_MAJOR)
> +KRB5_LICENSE = BSD-2c, others
> +KRB5_LICENSE_FILES = NOTICE
> +KRB5_SUBDIR = src
> +KRB5_INSTALL_STAGING = YES
> +
> +KRB5_CONF_ENV = \
> + krb5_cv_attr_constructor_destructor=yes,yes \
> + ac_cv_func_regcomp=yes \
> + krb5_cv_sys_rcdir=/tmp \
> + ac_cv_printf_positional=yes \
> + WARN_CFLAGS='-Wall'
> +
> +KRB5_CONF_OPTS = \
> + --without-tcl \
> + --without-hesiod \
> + --without-ldap \
> + --without-libedit \
> + --without-libreadline
> +
> +# No buildroot packages exist for these so use the bundled ones.
> +KRB5_CONF_OPTS += \
> + --without-system-libverto \
> + --without-system-ss \
> + --without-system-et
> +
> +# Buildroot's berkeleydb does not provide API 1.85
> +KRB5_CONF_OPTS += --without-system-db
> +
> +ifeq ($(BR2_TOOLCHAIN_HAS_THREADS),y)
> +KRB5_CONF_OPTS += --enable-thread-support
> +else
> +KRB5_CONF_OPTS += --disable-thread-support
> +endif
> +
> +ifeq ($(BR2_PACKAGE_OPENSSL),y)
> +KRB5_CONF_OPTS += --with-crypto-impl=openssl
> +KRB5_DEPENDENCIES += openssl
> +else ifeq ($(BR2_PACKAGE_LIBNSS),y)
> +KRB5_CONF_OPTS += --with-crypto-impl=nss
> +KRB5_DEPENDENCIES += libnss
> +else
> +KRB5_CONF_OPTS += --with-crypto-impl=builtin
> +endif
> +
> +
> +$(eval $(autotools-package))
> --
> 2.10.2
>
>
--
Daniel.Price at gmail.com; Twitter: @danielbprice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20161108/b474d382/attachment-0001.html>
^ permalink raw reply
* Re: stable-rc build: 72 warnings 1 failures (stable-rc/v4.4.30-35-gf821e08)
From: Arnd Bergmann @ 2016-11-09 0:07 UTC (permalink / raw)
To: Olof Johansson
Cc: Kernel Build Reports Mailman List, Olof's autobuilder, stable,
Greg KH, Eric W. Biederman
In-Reply-To: <CAOesGMjH1jGum3E08F2h5dH2dyq_ekwZ_4M7piAdsxDFvhXu8g@mail.gmail.com>
On Tuesday, November 8, 2016 3:26:52 PM CET Olof Johansson wrote:
> On Tue, Nov 8, 2016 at 2:17 PM, Olof Johansson <olof@lixom.net> wrote:
> > On Tue, Nov 8, 2016 at 2:14 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> On Tuesday, November 8, 2016 9:16:28 AM CET Olof's autobuilder wrote:
> >>> Here are the build results from automated periodic testing.
> >>>
> >>> The tree being built was stable-rc, found at:
> >>>
> >>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable-rc.git/
> >>>
> >>> Topmost commit:
> >>>
> >>> f821e08 Linux 4.4.31-rc1
> >>>
> >>> Build logs (stderr only) can be found at the following link (experimental):
> >>>
> >>> http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.30-35-gf821e08/
> >>
> >> These seem to be largely caused by building with gcc-6. It's probably
> >> a good idea to keep supporting that configuration though and
> >> backport the fixes. Here are the upstream commit IDs I've found.
> >
> > That's a lot of noise. I'll move back to build with gcc 4.9.2 instead, for now.
> >
> > It's not entirely reasonable to expect older releases to build with
> > new toolchains without warnings, and I'm not sure if it makes sense to
> > bring back those fixes to -stable (unless they fix real bugs, of
> > course).
>
> A lot less noise with older gcc:
>
> http://arm-soc.lixom.net/buildlogs/stable-rc/v4.4.30-44-gc5be865/
Out of the ones I mentioned earlier, that leaves
aaaab56dba9a ("of: silence warnings due to max() usage")
badbda53e505 ("mm/cma: silence warnings due to max() usage")
but adds a couple of others:
| arch/powerpc/relocs_check.sh: line 46: ccache /usr/local/cross-4.9.2/bin/powerpc64-linux-objdump: No such file or directory
| arch/arm64/Makefile:25: LSE atomics not supported by binutils
These seem to be caused by an older binutils release in your cross-4.9.2 build
| In file included from /work/build/batch/drivers/isdn/hardware/eicon/message.c:30:0:
| /work/build/batch/drivers/isdn/hardware/eicon/message.c: In function 'mixer_notify_update':
| /work/build/batch/drivers/isdn/hardware/eicon/platform.h:333:18: warning: array subscript is above array bounds [-Warray-bounds]
| *(__le16 *)addr = cpu_to_le16(v);
This looks like a false-positive bug caused by 4.9 that is no longer
present in newer compilers.
I assume this is the line
PUT_WORD(&(((CAPI_MSG *) msg)->info.facility_req.structs[1]), LI_REQ_SILENT_UPDATE);
Arnd
^ 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.