Re: [PATCH] regmap: Fix the null function of format_val on regmap_bulk_read.
On Wed, Aug 26, 2015 at 06:38:12PM +0100, Mark Brown wrote: > On Wed, Aug 26, 2015 at 03:22:46PM +0200, Markus Pargmann wrote: > > On Wed, Aug 26, 2015 at 01:35:56PM +0100, Mark Brown wrote: > > > On Wed, Aug 26, 2015 at 07:43:16PM +0800, Henry Chen wrote: > > > > Why are these format functions sensible? Converting a null pointer > > > dereference into data corruption wouldn't be ideal. The commit message > > > should really cover this. > > > The regmap_bulk_read() function worked before the following patch: > > 15b8d2c41fe5 (regmap: Fix regmap_bulk_read in BE mode) > > Define "worked" here. "worked" means here that it did not run into a null pointer and returned something that the user expected. I am not sure if someone actually complained about the previous use of memcpy? I also don't know how the behavior of regmap_bulk_read with reg_read() is defined. Best Regards, Markus > > > As far as I can see this patch fixes this issue by using simple format > > functions. Before the above mentioned patch, the code used memcpy. Now > > regmap_format_*_native is used which should result in the same behaviour > > but fixes the null pointer. > > Again, this sort of analysis needs to be in the commit message (and > really ought to explain why the resulting API makes sense). > > > I am not sure if there are other locations in the code where format_val > > is used in this setup so I don't know if this would change behavior in a > > different codepath. > > Which is another part of the concern, being able to format values is a > more general concept. -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: Digital signature
Re: [PATCH v2 8/8] zram: use decompress_noctx
On (08/27/15 13:07), Sergey Senozhatsky wrote:
[..]
> > -struct zcomp_strm *zcomp_strm_find(struct zcomp *comp)
> > +struct zcomp_strm *zcomp_strm_find(struct zcomp *comp, bool decomp)
> >
I think we can hide zcomp_strm_find()/_release (make them static),
and instead introduce:
a) zcomp_decompress_begin()/zcomp_decompress_end()
calls zcomp_strm_find()/zcomp_strm_release() for tfms that
require context for decompression; may return NULL, may sleep.
b) zcomp_compress_begin()/zcomp_compress_end()
always calls zcomp_strm_find()/zcomp_strm_release();
never return NULL; may sleep.
-ss
> > {
> > + /* We don't need decompression context so zstrm neither */
> > + if (decomp && test_bit(ZCOMP_DECOMPRESS_NOCTX, >flags))
> > + return NULL;
> > +
> > return comp->strm_find(comp);
> > }
>
> No. zcomp_strm_find() should never return NULL. And no, I don't like
> "if (decomp)" change.
>
>
> >
> > @@ -307,6 +311,11 @@ int zcomp_compress(struct zcomp *comp, struct
> > zcomp_strm *zstrm,
> > {
> > *dst_len = PAGE_SIZE << 1;
> >
> > + if (!zstrm) {
> > + return crypto_comp_compress_noctx(comp->alg, src, PAGE_SIZE,
> > + dst, dst_len);
> > + }
> > +
> > return crypto_comp_compress(zstrm->tfm, src, PAGE_SIZE, dst, dst_len);
> > }
> >
> > @@ -316,12 +325,18 @@ int zcomp_decompress(struct zcomp *comp, struct
> > zcomp_strm *zstrm,
> > {
> > unsigned int size = PAGE_SIZE;
> >
> > + if (!zstrm) {
> > + return crypto_comp_decompress_noctx(comp->alg, src, src_len,
> > + dst, );
> > + }
> > +
> > return crypto_comp_decompress(zstrm->tfm, src, src_len, dst, );
> > }
> >
> > void zcomp_destroy(struct zcomp *comp)
> > {
> > comp->destroy(comp);
> > + crypto_put_comp(comp->alg);
> > kfree(comp);
> > }
> >
> > @@ -344,12 +359,23 @@ struct zcomp *zcomp_create(const char *compress, int
> > max_strm)
> > return ERR_PTR(-ENOMEM);
> >
> > comp->name = compress;
> > + comp->alg = crypto_get_comp(compress, 0, 0);
> > + if (!comp->alg) {
> > + kfree(comp);
> > + return ERR_PTR(-EINVAL);
> > + }
> > +
> > + if (crypto_has_compress_noctx(comp->alg))
> > + set_bit(ZCOMP_COMPRESS_NOCTX, >flags);
>
> do you use ZCOMP_COMPRESS_NOCTX algs in this patch set?
>
>
> > + if (crypto_has_decompress_noctx(comp->alg))
> > + set_bit(ZCOMP_DECOMPRESS_NOCTX, >flags);
> >
> > if (max_strm > 1)
> > zcomp_strm_multi_create(comp, max_strm);
> > else
> > zcomp_strm_single_create(comp);
> > if (!comp->stream) {
> > + crypto_put_comp(comp->alg);
> > kfree(comp);
> > return ERR_PTR(-ENOMEM);
> > }
> > diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
> > index c47db4d..6c137c8 100644
> > --- a/drivers/block/zram/zcomp.h
> > +++ b/drivers/block/zram/zcomp.h
> > @@ -13,6 +13,11 @@
> > #include
> > #include
> >
> > +enum {
> > + ZCOMP_COMPRESS_NOCTX,
> > + ZCOMP_DECOMPRESS_NOCTX,
> > +};
>
> Can it be handled via crypto api? check if ->foo_noctx() is !NULL ?
>
> > struct zcomp_strm {
> > struct crypto_comp *tfm;
> >
> > @@ -27,6 +32,8 @@ struct zcomp_strm {
> > struct zcomp {
> > void *stream;
> > const char *name;
> > + struct crypto_alg *alg;
> > + unsigned long flags;
> >
> > struct zcomp_strm *(*strm_find)(struct zcomp *comp);
> > void (*strm_release)(struct zcomp *comp, struct zcomp_strm *zstrm);
> > @@ -39,7 +46,7 @@ ssize_t zcomp_available_show(const char *comp, char *buf);
> > struct zcomp *zcomp_create(const char *comp, int max_strm);
> > void zcomp_destroy(struct zcomp *comp);
> >
> > -struct zcomp_strm *zcomp_strm_find(struct zcomp *comp);
> > +struct zcomp_strm *zcomp_strm_find(struct zcomp *comp, bool decomp);
> > void zcomp_strm_release(struct zcomp *comp, struct zcomp_strm *zstrm);
> >
> > int zcomp_compress(struct zcomp *comp, struct zcomp_strm *zstrm,
> > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > index b3044d3..8283bd3 100644
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -623,7 +623,7 @@ static int zram_bvec_read(struct zram *zram, struct
> > bio_vec *bvec,
> > /* Use a temporary buffer to decompress the page */
> > uncmem = kmalloc(PAGE_SIZE, GFP_NOIO);
> >
> > - zstrm = zcomp_strm_find(zram->comp);
> > + zstrm = zcomp_strm_find(zram->comp, true);
>
> No, I don't like this.
>
> > user_mem = kmap_atomic(page);
> > if (!is_partial_io(bvec))
> > uncmem = user_mem;
> > @@ -647,7 +647,8 @@ static int zram_bvec_read(struct zram *zram, struct
> > bio_vec *bvec,
> > ret = 0;
> > out_cleanup:
> > kunmap_atomic(user_mem);
> > - zcomp_strm_release(zram->comp, zstrm);
> > + if
[PATCH v4] qcom: ipq4019: Add basic board/dts support for IPQ4019 SoC
Add initial dts files and SoC support for IPQ4019
Signed-off-by: Varadarajan Narayanan
---
All,
Missed linux-arm-msm mailing list last time and
incorrectly versioned the patch as v5.
Kindly excuse.
Changes in v2:
- Added devicetree bindings documentation
Changes in v3:
- Split 'gcnt' into a separate patch
- Added the new entries to Makefiles, Kconfig & board.c in sorted order
- Used "qcom,ipq40xx" instead of "qcom,ipq40xx-r3pc" in board.c
Changes in v4:
- Removed r3pc dts
- Removed timer frequency
arch/arm/boot/dts/qcom-ipq4019.dtsi | 72 +
1 file changed, 72 insertions(+)
create mode 100644 arch/arm/boot/dts/qcom-ipq4019.dtsi
diff --git a/arch/arm/boot/dts/qcom-ipq4019.dtsi
b/arch/arm/boot/dts/qcom-ipq4019.dtsi
new file mode 100644
index 000..668cc84
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019.dtsi
@@ -0,0 +1,72 @@
+/*
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/dts-v1/;
+
+#include "skeleton.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. IPQ4019";
+ compatible = "qcom,ipq4019";
+ interrupt-parent = <>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x0>;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x1>;
+ };
+
+ cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x2>;
+ };
+
+ cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x3>;
+ };
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ compatible = "simple-bus";
+
+ intc: interrupt-controller@b00 {
+ compatible = "qcom,msm-qgic2";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x0b00 0x1000>,
+ <0x0b002000 0x1000>;
+ };
+
+ serial@78b {
+ compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+ reg = <0x78b 0x200>;
+ interrupts = <0 108 0>;
+ status = "disabled";
+ };
+ };
+};
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] usb: chipidea: add xilinx zynq platform data
Hi,
On Wed, Aug 26, 2015 at 8:57 PM, Nathan Sullivan wrote:
> The Xilinx Zynq udc does not need the CI_HDRC_DISABLE_STREAMING flag,
> unlike the default platform data. Add platform data specific to the
> Zynq udc.
>
> Based on a patch by the same name from the Xilinx vendor tree.
I am that Xilinx guy who sent this patch :). It is in Xilinx tree as
temporary fix and
I did not debug further why UDC works only when streaming is enabled.
Probably this is right time to post my question here.
I was expecting like:
Streaming disabled - both low bandwidth and high bandwidth systems
should work fine
Streaming enabled - only for high bandwidth systems
but this is not the case, Zynq UDC works only when Streaming is enabled.
Please correct me if I am wrong.
Thanks,
Sundeep
>
> Signed-off-by: Nathan Sullivan
> ---
> drivers/usb/chipidea/ci_hdrc_usb2.c | 25 +++--
> 1 file changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/usb/chipidea/ci_hdrc_usb2.c
> b/drivers/usb/chipidea/ci_hdrc_usb2.c
> index 9eae1a1..4456d2c 100644
> --- a/drivers/usb/chipidea/ci_hdrc_usb2.c
> +++ b/drivers/usb/chipidea/ci_hdrc_usb2.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -30,18 +31,36 @@ static const struct ci_hdrc_platform_data
> ci_default_pdata = {
> .flags = CI_HDRC_DISABLE_STREAMING,
> };
>
> +static struct ci_hdrc_platform_data ci_zynq_pdata = {
> + .capoffset = DEF_CAPOFFSET,
> +};
> +
> +static const struct of_device_id ci_hdrc_usb2_of_match[] = {
> + { .compatible = "chipidea,usb2"},
> + { .compatible = "xlnx,zynq-usb-2.20a", .data = _zynq_pdata},
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, ci_hdrc_usb2_of_match);
> +
> static int ci_hdrc_usb2_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> struct ci_hdrc_usb2_priv *priv;
> struct ci_hdrc_platform_data *ci_pdata = dev_get_platdata(dev);
> int ret;
> + const struct of_device_id *match;
>
> if (!ci_pdata) {
> ci_pdata = devm_kmalloc(dev, sizeof(*ci_pdata), GFP_KERNEL);
> *ci_pdata = ci_default_pdata; /* struct copy */
> }
>
> + match = of_match_device(ci_hdrc_usb2_of_match, >dev);
> + if (match && match->data) {
> + /* struct copy */
> + *ci_pdata = *(struct ci_hdrc_platform_data *)match->data;
> + }
> +
> priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> if (!priv)
> return -ENOMEM;
> @@ -96,12 +115,6 @@ static int ci_hdrc_usb2_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> -static const struct of_device_id ci_hdrc_usb2_of_match[] = {
> - { .compatible = "chipidea,usb2" },
> - { }
> -};
> -MODULE_DEVICE_TABLE(of, ci_hdrc_usb2_of_match);
> -
> static struct platform_driver ci_hdrc_usb2_driver = {
> .probe = ci_hdrc_usb2_probe,
> .remove = ci_hdrc_usb2_remove,
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for DP
On 8/26/2015 7:59 PM, Benjamin Tissoires wrote: On Aug 26 2015 or thereabouts, Sivakumar Thulasimani wrote: On 8/18/2015 1:36 AM, Benjamin Tissoires wrote: On Aug 14 2015 or thereabouts, Stéphane Marchesin wrote: On Wed, Aug 5, 2015 at 12:34 PM, Benjamin Tissoires wrote: On Jul 30 2015 or thereabouts, Sivakumar Thulasimani wrote: On 7/29/2015 8:52 PM, Benjamin Tissoires wrote: On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote: why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you can identify both lane count and reversal state without touching anything in the link training code. i am yet to upstream my changes for CHT that i can share if required that does the same in intel_dp_detect without touching any line in link training path. With my current limited knowledge of the dp hotplug (and i915 driver) I am not sure we could detect the reversed state without trying to train 1 lane only. I'd be glad to look at your changes and test them on my system if you think that could help having a cleaner solution. Cheers, Benjamin No, what i recommended was to do link training but in intel_dp_detect. Since USB Type C cable also has its own lane count restriction (it can have different lane count than the one supported by panel) you might have to figure that out as well. so both reversal and lane count detection can be done outside the modeset path and keep the code free of type C changes outside detection path. Please find below the code to do the same. Do not waste time trying to apply this directly on nightly since this is based on a local tree and because this is pre- atomic changes code, so you might have to modify chv_upfront_link_train to work on top of the latest nightly code. we are supposed to upstream this and is in my todo list. [original patch snipped...] Hi Sivakumar, So I managed to manually re-apply your patch on top of drm-intel-nightly, and tried to port it to make Broadwell working too. It works OK if the system is already boot without any external DP used. In this case, the detection works and I can see my external monitor working properly. However, if the monitor is cold plugged, the cpu/GPU hangs and I can not understand why. I think I enabled all that is mentioned in the PRM to be able to train the DP link, but I am obviously missing something else. Can you have a look? Hi Benjamin, I would recommend against this approach. Some adapters will claim that they recovered a clock even when it isn't on the lanes you enabled, which means that the reversal detection doesn't always work. The only reliable way to do this is to go talk to the Chrome OS EC (you can find these patches later in the Chrome OS tree). It's not as generic, but we might be able to abstract that logic, maybe. Hi Stéphane, This is a very good news. I was afraid we would not have access to the hardware controller because the Intel controller hub spec was not public. I will try to have a look at it, but the latest chromeos branch (3.18) seems to differ quite a lot from the upstream one. Anyway, fingers crossed. Cheers, Benjamin Hi Benjamin/Stéphan, Hi Sivakumar, All Intel platforms (at-least those i inquired about) handle lane reversal in HW. That is the theory and what is written in the USB Type C spec IIRC. Problem is, the Chromebook Pixel 2 external display does not work when a USB Type-C adapter is in the reversed position (or believe me, I would definitively not have submitted a patch for the beauty of it). Everything else works (link training when 4 lanes are activated, or other communication channels). Only the order of the 4 data lanes matters in this situation and the USB controller does not reverse them for us on this laptop. your statement that link training will pass even on reversed lane seems to point to the same fact. in such a scenario why should the encoder/connector care if the lane is reversed or not ? Problem is that Stephane said some adapters are lying regarding the clock recovery. They claim everything is fine while in the end, the display doesn't show anything because the lanes are reversed. If this is just a chromebook Pixel 2 issue, that's better then. I won't have to try to put some generic interface to notify that the display port lanes have to be reversed. Cheers, Benjamin Thanks for the info :). There is no way in code to confirm if after link training display is working properly (other than short pulse for link related issues) so this has to be on a case by case basis. i would recommend if you plan to upstream it to restrict the changes for chromebook Pixel 2 alone. -- regards, Sivakumar -- regards, Sivakumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] leds: leds-cobalt-qube: Use devm_led_classdev_register
Use resource-managed function devm_led_classdev_register instead
of led_classdev_register to make the error-path simpler.
To be compatible with the change, goto is replaced with direct
return and unneeded label is dropped. Also, remove redundant
cobalt_qube_led_remove.
Signed-off-by: Vaishali Thakkar
---
drivers/leds/leds-cobalt-qube.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/leds/leds-cobalt-qube.c b/drivers/leds/leds-cobalt-qube.c
index d975220..59818df 100644
--- a/drivers/leds/leds-cobalt-qube.c
+++ b/drivers/leds/leds-cobalt-qube.c
@@ -49,31 +49,15 @@ static int cobalt_qube_led_probe(struct platform_device
*pdev)
led_value = LED_FRONT_LEFT | LED_FRONT_RIGHT;
writeb(led_value, led_port);
- retval = led_classdev_register(>dev, _front_led);
+ retval = devm_led_classdev_register(>dev, _front_led);
if (retval)
- goto err_null;
-
- return 0;
-
-err_null:
- led_port = NULL;
-
- return retval;
-}
-
-static int cobalt_qube_led_remove(struct platform_device *pdev)
-{
- led_classdev_unregister(_front_led);
-
- if (led_port)
- led_port = NULL;
+ return retval;
return 0;
}
static struct platform_driver cobalt_qube_led_driver = {
.probe = cobalt_qube_led_probe,
- .remove = cobalt_qube_led_remove,
.driver = {
.name = "cobalt-qube-leds",
},
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] mpt3sas: Reference counting fixes from in-flight mpt2sas
HI Nicholas & Calvin, Thanks for the patchset. Sure We will review and we do some unit testing on this patch series. Currently my bandwidth is occupied with some internal activity, so by end of next week I will acknowledge this series if all the thing are fine with this patch series. Thanks, Sreekanth On Thu, Aug 27, 2015 at 5:28 AM, Nicholas A. Bellinger wrote: > On Wed, 2015-08-26 at 16:54 -0700, Calvin Owens wrote: >> On Wednesday 08/26 at 04:09 +, Nicholas A. Bellinger wrote: >> > From: Nicholas Bellinger >> > >> > Hi James & Co, >> > >> > This series is a mpt3sas forward port of Calvin Owens' in-flight >> > reference counting bugfixes for mpt2sas LLD code here: >> > >> > [PATCH v4 0/2] Fixes for memory corruption in mpt2sas >> > http://marc.info/?l=linux-scsi=143951695904115=2 >> >> Nicholas, >> >> I'm glad to hear these fixes were helpful! I was planning on porting to >> mpt3sas in the near future, thanks for saving me the trouble :) >> > > Would you mind giving this series the once over, and add your > Reviewed-by as well..? > > Sreekanth + Avago folks, can you please do the same for Calvin's mpt2sas > series and this series..? > > This has been a long-standing issue with mpt*sas LLD code and really > needs to be addressed for upstream. > > Thank you, > > --nab > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/6] ARM: dts: qs600: add alias to serial0
On Tue, Aug 25, 2015 at 04:46:22PM -0500, Andy Gross wrote: > On Tue, Aug 18, 2015 at 02:10:27PM +0100, Srinivas Kandagatla wrote: > > This patch add alias node with serial0. > > > > Signed-off-by: Srinivas Kandagatla > > --- > > arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts | 4 > > 1 file changed, 4 insertions(+) > > Looks fine. Applied. Scratch that. I dropped it from the patch list due to stephen's set. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] timer: Reduce unnecessary sighand lock contention
On Wed, 2015-08-26 at 16:32 -0700, Jason Low wrote:
> Perhaps to be safer, we use something like load_acquire() and
> store_release() for accessing both the ->running and ->checking_timer
> fields?
Regarding using barriers, one option could be to pair them between
sig->cputime_expires and the sig->cputimer.checking_timer accesses.
fastpath_timer_check()
{
...
if (READ_ONCE(sig->cputimer.running))
struct task_cputime group_sample;
sample_cputime_atomic(_sample,
>cputimer.cputime_atomic);
if (task_cputime_expired(_sample, >cputime_expires))
{
/*
* Comments
*/
mb();
if (!READ_ONCE(sig->cputimer.checking_timer))
return 1;
}
}
}
check_process_timers()
{
...
WRITE_ONCE(sig->cputimer.checking_timer, 0);
/*
* Comments
*/
mb();
sig->cputime_expires.prof_exp = expires_to_cputime(prof_expires);
sig->cputime_expires.virt_exp = expires_to_cputime(virt_expires);
sig->cputime_expires.sched_exp = sched_expires;
...
}
By the time the cputime_expires fields get updated at the end of
check_process_timers(), other threads in the fastpath_timer_check()
should observe the value 0 for READ_ONCE(sig->cputimer.checking_timer).
In the case where threads in the fastpath don't observe the
WRITE_ONCE(checking_timer, 1) early enough, that's fine, since it will
just (unnecessarily) go through the slowpath which is what we also do in
the current code.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 05/16] x86/efi: Get entropy through EFI random number generator protocol
On Thu, Aug 20, 2015 at 03:47:06PM +0100, Matt Fleming wrote:
> On Tue, 11 Aug, at 02:16:25PM, Lee, Chun-Yi wrote:
> > To grab random numbers through EFI protocol as one of the entropies
> > source of swsusp key, this patch adds the logic for accessing EFI RNG
> > (random number generator) protocol that's introduced since UEFI 2.4.
> >
> > Signed-off-by: Lee, Chun-Yi
> > ---
> > arch/x86/boot/compressed/efi_random.c | 209
> > ++
> > include/linux/efi.h | 13 +++
> > 2 files changed, 222 insertions(+)
>
> [...]
>
> Most of this looks good.
>
> > +static unsigned long efi_get_rng(efi_system_table_t *sys_table)
> > +{
> > + const struct efi_config *efi_early = __efi_early();
> > + unsigned long random = 0;
> > + efi_status_t status;
> > + void **rng_handle = NULL;
> > +
> > + status = efi_locate_rng(sys_table, _handle);
> > + if (status != EFI_SUCCESS)
> > + return 0;
> > +
> > + if (efi_early->is64)
> > + random = efi_get_rng64(sys_table, rng_handle);
> > + else
> > + random = efi_get_rng32(sys_table, rng_handle);
> > +
> > + efi_call_early(free_pool, rng_handle);
> > +
> > + return random;
> > +}
>
> I think this function is named particularly poorly in the UEFI spec
> (GetRNG), can we maybe make this efi_get_rng_number(),
> efi_get_rng_value() or efi_get_rng_long() to match the existing
> naming?
>
Thanks for your suggestion, I will change the naming of functions.
> > diff --git a/include/linux/efi.h b/include/linux/efi.h
> > index 85ef051..8914d60 100644
> > --- a/include/linux/efi.h
> > +++ b/include/linux/efi.h
> > @@ -427,6 +427,16 @@ typedef struct {
> > #define EFI_PCI_IO_ATTRIBUTE_VGA_PALETTE_IO_16 0x2
> > #define EFI_PCI_IO_ATTRIBUTE_VGA_IO_16 0x4
> >
> > +typedef struct {
> > + u32 get_info;
> > + u32 get_rng;
> > +} efi_rng_protocol_32;
> > +
> > +typedef struct {
> > + u64 get_info;
> > + u64 get_rng;
> > +} efi_rng_protocol_64;
> > +
>
> We've been kinda slack with the naming conventions in efi.h but these
> should really both be 'efi_rng_protocol_*_t'.
>
I will also change the name of struct here.
> --
> Matt Fleming, Intel Open Source Technology Center
Thanks a lot!
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/10] ARM: dts: qcom: apq8084-mtp: Use stdout-path
On Tue, Jun 16, 2015 at 02:31:49PM -0700, Stephen Boyd wrote: > Use stdout-path so that we don't have to put the console on the > kernel command line. > > Signed-off-by: Stephen Boyd > --- > arch/arm/boot/dts/qcom-apq8084-mtp.dts | 8 > 1 file changed, 8 insertions(+) Applied. Thanks -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/10] ARM: dts: qcom: msm8974-sony-xperia-honami: Use stdout-path
On Tue, Jun 16, 2015 at 02:31:53PM -0700, Stephen Boyd wrote: > Use stdout-path so that we don't have to put the console on the > kernel command line. > > Cc: Tim Bird > Cc: Bjorn Andersson > Signed-off-by: Stephen Boyd > --- > arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts | 8 > 1 file changed, 8 insertions(+) > Applied. Thanks -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/10] ARM: dts: qcom: msm8660-surf: Use stdout-path
On Tue, Jun 16, 2015 at 02:31:51PM -0700, Stephen Boyd wrote: > Use stdout-path so that we don't have to put the console on the > kernel command line. > > Signed-off-by: Stephen Boyd > --- > arch/arm/boot/dts/qcom-msm8660-surf.dts | 8 > 1 file changed, 8 insertions(+) Applied. thanks -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/10] ARM: dts: qcom: Label serial nodes for aliasing and stdout-path
On Tue, Jun 16, 2015 at 02:31:44PM -0700, Stephen Boyd wrote: > Add a label to the serial nodes that are being used for the > console. > > Signed-off-by: Stephen Boyd > --- Applied. Thanks -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/10] ARM: dts: qcom: ipq8064-ap148: Use stdout-path
On Tue, Jun 16, 2015 at 02:31:50PM -0700, Stephen Boyd wrote: > Use stdout-path so that we don't have to put the console on the > kernel command line. > > Cc: Mathieu Olivari > Signed-off-by: Stephen Boyd > --- > arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 8 > 1 file changed, 8 insertions(+) Applied thanks -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/10] ARM: dts: qcom: apq8064-cm-qs600: Use stdout-path
On Tue, Jun 16, 2015 at 02:31:45PM -0700, Stephen Boyd wrote: > Use stdout-path so that we don't have to put the console on the > kernel command line. > > Cc: Mike Rapoport > Cc: Igor Grinberg > Signed-off-by: Stephen Boyd > --- > arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts | 8 > 1 file changed, 8 insertions(+) Applied. Thanks -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Seccomp questions for updates to seccomp(2) man page
On Wed, Aug 26, 2015 at 6:42 PM, Michael Kerrisk (man-pages) wrote: > Hello Kees, Will, > > In recent times I've been asked a couple of questions about seccomp(), > and it seems like it would be worthwhile to include these topics in > the seccomp(2) man page. Would you be able to help out with some > answers? > > === Use of the instruction pointer in seccomp filters === > > The seccomp_data describing the system call includes the process's > instruction pointer value. What use can be made of this information? Will may have some other history to add here, but it seemed like it was a handy thing to add, as it's a dynamic value attached to the execution environment. I'm actually not aware of any programs that build filters with reference to it. > My best guess is that you can use this information in conjunction with > /proc/PID/maps to introspect the process layout and thus construct > filters that conditionally operate based on which DSO is performing a > system call. Is that a reasonable use case? Are there others? That's reasonable. Filters limiting syscalls to certain memory ranges would likely also want to lock down mmap and mprotect calls, to stop anything malicious from trying to sneak into the protected range. > === Chained seccomp filters and SECCOMP_RET_KILL === > > The man page describes the behavior when multiple filter are installed > >If multiple filters exist, they are all executed, in reverse >order of their addition to the filter tree (i.e., the most >recently installed filter is executed first). The return value >for the evaluation of a given system call is the first-seen >SECCOMP_RET_ACTION value of highest precedence (along with its >accompanying data) returned by execution of all of the filters. > > The question is: suppose one of the early filters returns > SECCOMP_RET_KILL (which is the highest priority action), what is the > purpose of executing the remaining filters. My best guess is that this > about preventing the user from discovering which filter rule causes > the sandboxed program to fail. Is this correct, or is there another > reason? It's just because it would be an optimization that would only speed up the RET_KILL case, but it's the uncommon one and the one that doesn't benefit meaningfully from such a change (you need to kill the process really quickly?). We would speed up killing a program at the (albeit tiny) expense to all other filtered programs. Best to keep the filter execution logic clear, simple, and as fast as possible for all filters. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3] net: sunrpc: fix tracepoint Warning: unknown op '->'
`perf stat -e sunrpc:svc_xprt_do_enqueue true` results in
Warning: unknown op '->'
Warning: [sunrpc:svc_xprt_do_enqueue] unknown op '->'
Similar warning for svc_handle_xprt as well.
Actually TP_printk() should never dereference an address saved in the ring
buffer that points somewhere in the kernel. There's no guarantee that that
object still exists (with the exception of static strings).
Therefore change all the arguments for TP_printk(), so that it references
values existing in the ring buffer only.
While doing that, also fix another possible bug when argument xprt could be
NULL and TP_fast_assign() tries to access it's elements.
Signed-off-by: Pratyush Anand
Reviewed-by: Jeff Layton
Acked-by: Steven Rostedt
---
Changes since V2:
- removed storing of "rqst" now
- removed replacement of , to ; at the end of statement __entry->xprt =
xprt
Changes since V1:
- struct sockaddr memcopied to ring buffer so that its internal element can
be accessed while printing %pIS.
include/trace/events/sunrpc.h | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/include/trace/events/sunrpc.h b/include/trace/events/sunrpc.h
index fd1a02cb3c82..003dca933803 100644
--- a/include/trace/events/sunrpc.h
+++ b/include/trace/events/sunrpc.h
@@ -529,18 +529,21 @@ TRACE_EVENT(svc_xprt_do_enqueue,
TP_STRUCT__entry(
__field(struct svc_xprt *, xprt)
- __field(struct svc_rqst *, rqst)
+ __field_struct(struct sockaddr_storage, ss)
+ __field(int, pid)
+ __field(unsigned long, flags)
),
TP_fast_assign(
__entry->xprt = xprt;
- __entry->rqst = rqst;
+ xprt ? memcpy(&__entry->ss, >xpt_remote,
sizeof(__entry->ss)) : memset(&__entry->ss, 0, sizeof(__entry->ss));
+ __entry->pid = rqst? rqst->rq_task->pid : 0;
+ __entry->flags = xprt ? xprt->xpt_flags : 0;
),
TP_printk("xprt=0x%p addr=%pIScp pid=%d flags=%s", __entry->xprt,
- (struct sockaddr *)&__entry->xprt->xpt_remote,
- __entry->rqst ? __entry->rqst->rq_task->pid : 0,
- show_svc_xprt_flags(__entry->xprt->xpt_flags))
+ (struct sockaddr *)&__entry->ss,
+ __entry->pid, show_svc_xprt_flags(__entry->flags))
);
TRACE_EVENT(svc_xprt_dequeue,
@@ -589,16 +592,20 @@ TRACE_EVENT(svc_handle_xprt,
TP_STRUCT__entry(
__field(struct svc_xprt *, xprt)
__field(int, len)
+ __field_struct(struct sockaddr_storage, ss)
+ __field(unsigned long, flags)
),
TP_fast_assign(
__entry->xprt = xprt;
+ xprt ? memcpy(&__entry->ss, >xpt_remote,
sizeof(__entry->ss)) : memset(&__entry->ss, 0, sizeof(__entry->ss));
__entry->len = len;
+ __entry->flags = xprt ? xprt->xpt_flags : 0;
),
TP_printk("xprt=0x%p addr=%pIScp len=%d flags=%s", __entry->xprt,
- (struct sockaddr *)&__entry->xprt->xpt_remote, __entry->len,
- show_svc_xprt_flags(__entry->xprt->xpt_flags))
+ (struct sockaddr *)&__entry->ss,
+ __entry->len, show_svc_xprt_flags(__entry->flags))
);
#endif /* _TRACE_SUNRPC_H */
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/10] ARM: dts: qcom: msm8960-cdp: Use stdout-path
On Tue, Jun 16, 2015 at 02:31:52PM -0700, Stephen Boyd wrote: > Use stdout-path so that we don't have to put the console on the > kernel command line. > > Signed-off-by: Stephen Boyd > --- > arch/arm/boot/dts/qcom-msm8960-cdp.dts | 8 > 1 file changed, 8 insertions(+) Applied. Thanks -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/10] ARM: dts: qcom: apq8084-ifc6540: Use stdout-path
On Tue, Jun 16, 2015 at 02:31:48PM -0700, Stephen Boyd wrote: > Use stdout-path so that we don't have to put the console on the > kernel command line. > > Signed-off-by: Stephen Boyd > --- > arch/arm/boot/dts/qcom-apq8084-ifc6540.dts | 8 > 1 file changed, 8 insertions(+) Applied. Thanks -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] arm:dts:ls1021a: Add SiI902x dts node
The SiI902x is a HDMI transmitter.
Signed-off-by: Alison Wang
Signed-off-by: Xiubo Li
Signed-off-by: Jianwei Wang
---
arch/arm/boot/dts/ls1021a-twr.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/ls1021a-twr.dts
b/arch/arm/boot/dts/ls1021a-twr.dts
index a2c591e..c3140f0 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -79,6 +79,12 @@
{
status = "okay";
+
+ hdmi: sii9022a@39 {
+ compatible = "sii902x";
+ reg = <0x39>;
+ interrupts = ;
+ };
};
{
--
2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] drm/layerscape: Add HDMI support for DCU DRM driver
Some Freescale SoCs, there has an DVI/HDMI controller and a PHY,
attached to one of their display controller unit's LCDC interfaces.
This patch adds a driver for SiI902x. The SiI902x is a HDMI
transmitter It supports resolutions from standard definition
480i/p and 576i/p all the way to high-definition 720p, 1080i,
and 1080p, the highest resolution supported by HDTVs today.
Signed-off-by: Alison Wang
Signed-off-by: Xiubo Li
Signed-off-by: Jianwei Wang
---
.../devicetree/bindings/video/SiI902x.txt | 17 +
drivers/gpu/drm/fsl-dcu/Makefile | 1 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c | 639 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 10 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_output.h | 10 +
5 files changed, 677 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/SiI902x.txt
create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c
diff --git a/Documentation/devicetree/bindings/video/SiI902x.txt
b/Documentation/devicetree/bindings/video/SiI902x.txt
new file mode 100644
index 000..d304499
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/SiI902x.txt
@@ -0,0 +1,17 @@
+Device-Tree bindings for the SiI902x hdmi transmitter.
+
+Required properties:
+- compatible: Should be "sii902x".
+- reg: The I2C address of the device.
+- interrupts: Interrupt number to the cpu.
+
+Example:
+
+ {
+ status = "okay";
+ hdmi: sii9022a@39 {
+ compatible = "sii902x";
+ reg = <0x39>;
+ interrupts = ;
+ };
+};
diff --git a/drivers/gpu/drm/fsl-dcu/Makefile b/drivers/gpu/drm/fsl-dcu/Makefile
index 6ea1523..98cacc2 100644
--- a/drivers/gpu/drm/fsl-dcu/Makefile
+++ b/drivers/gpu/drm/fsl-dcu/Makefile
@@ -1,6 +1,7 @@
fsl-dcu-drm-y := fsl_dcu_drm_drv.o \
fsl_dcu_drm_kms.o \
fsl_dcu_drm_rgb.o \
+fsl_dcu_drm_hdmi.o \
fsl_dcu_drm_plane.o \
fsl_dcu_drm_crtc.o \
fsl_dcu_drm_fbdev.o
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c
new file mode 100644
index 000..b91c8ca
--- /dev/null
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_hdmi.c
@@ -0,0 +1,639 @@
+/*
+ * Copyright 2015 Freescale Semiconductor, Inc.
+ *
+ * Freescale DCU drm device driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "fsl_dcu_drm_drv.h"
+#include "fsl_dcu_drm_output.h"
+
+#define SII902X_INPUT_BUS_FMT 0x08
+#define SII902X_TPI_AVI_INPUT_FMT 0x09
+#define SII902X_TPI_AVI_OUTPUT_FMT 0x0A
+#define SII902X_SYS_CONTROL0x1A
+#define SII902X_SYS_CTR_DDC_REQBIT(2)
+#define SII902X_SYS_CTR_DDC_BUS_AVAI (BIT(2) | BIT(1))
+#define SII902X_TPI_FAMILY_DEV_ID 0x1B
+#define SII902X_TPI_DEV_REV_ID 0x1C
+#define SII902X_TPI_REV_LEVEL_ID 0x1D
+#define SII902X_POWER_STATE0x1E
+#define SII902X_TPI_AUDIO_CFG0 0x24
+#define SII902X_TPI_AUDIO_CFG1 0x25
+#define SII902X_TPI_AUDIO_CFG2 0x26
+#define SII902X_TPI_AUDIO_CFG3 0x27
+#define SII902X_TPI_HDCP_REV 0x30
+#define SII902X_TPI_INT_ENABLE 0x3C
+#define SII902X_TPI_INT_STATUS 0x3D
+#define SII902X_TPI_INT_PLUG_INBIT(2)
+#define SII902X_GENERAL_PURPOSE_IO00xBC
+#define SII902X_GENERAL_PURPOSE_IO10xBD
+#define SII902X_GENERAL_PURPOSE_IO20xBE
+#define SII902X_TRANS_MODE_DIFF0xC7
+
+bool g_enable_hdmi;
+
+struct sii902x_data {
+ struct i2c_client *client;
+ struct delayed_work det_work;
+ struct fb_info *fbi;
+ struct fsl_dcu_drm_hdmicon *hdmicon;
+} *sii902x;
+
+static struct i2c_client *sii902x_to_i2c(struct sii902x_data *sii902x)
+{
+ return sii902x->client;
+}
+
+static s32 sii902x_write(const struct i2c_client *client,
+u8 command, u8 value)
+{
+ return i2c_smbus_write_byte_data(client, command, value);
+}
+
+static s32 sii902x_read(const struct i2c_client *client, u8 command)
+{
+ int val;
+
+ val = i2c_smbus_read_word_data(client, command);
+
+ return val & 0xff;
+}
+
+static void sii902x_power_up_tx(struct sii902x_data *sii902x)
+{
+ struct i2c_client *client = sii902x_to_i2c(sii902x);
+ int val;
+
+ val = sii902x_read(client, SII902X_POWER_STATE);
+ val &= ~0x3;
+ sii902x_write(client, SII902X_POWER_STATE, val);
+}
+
+static int sii902x_get_edid_preconfig(void)
+{
+ int old, dat, ret = 0, cnt = 100;
+
+ old = sii902x_read(sii902x->client, SII902X_SYS_CONTROL);
+
+
Re: [PATCH 04/10] ARM: dts: qcom: apq8074-dragonboard: Use stdout-path
On Tue, Jun 16, 2015 at 02:31:47PM -0700, Stephen Boyd wrote: > Use stdout-path so that we don't have to put the console on the > kernel command line. > > Signed-off-by: Stephen Boyd > --- > arch/arm/boot/dts/qcom-apq8074-dragonboard.dts | 8 > 1 file changed, 8 insertions(+) Thanks. Applied. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/10] ARM: dts: qcom: apq8064-ifc6410: Use stdout-path
On Tue, Jun 16, 2015 at 02:31:46PM -0700, Stephen Boyd wrote: > Use stdout-path so that we don't have to put the console on the > kernel command line. > > Signed-off-by: Stephen Boyd > --- > arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 4 > 1 file changed, 4 insertions(+) > > diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts > b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts Thanks. Applied. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Allocating sys_membarrier syscall number on other archs
On Thu, 27 Aug 2015 04:04:42 + (UTC) Mathieu Desnoyers wrote: > Hi Andrew, > > The sys_membarrier patches you have in your tree target > x86 32-64 and generic, but I did not allocate the system call > number on other architectures to minimize the amount of > collisions, and because I do not have all those architectures > handy. > > How would you recommend to proceed to allocate those ? > I don't think you need to do anything. You've provided the selftest code for the arch maintainers and the arch maintainers will get "membarrier not implemented" warnings each time they build a kernel. The idea is that when they have time they'll wire it up, run the tests then ship it. If you want to help that process along a bit you could send patches to the arch maintainers along with instructions on how to test the syscall. The less work they have to do, the more likely they are to do it ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Allocating sys_membarrier syscall number on other archs
Hi Andrew, The sys_membarrier patches you have in your tree target x86 32-64 and generic, but I did not allocate the system call number on other architectures to minimize the amount of collisions, and because I do not have all those architectures handy. How would you recommend to proceed to allocate those ? sys_membarrier is pretty much architecture agnostic: it takes two integer parameters, and the only function it calls, synchronize_sched(), is available on all architectures. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Pls provide the following details ..
Dear Sir / Madam, I am interested in purchasing your products , which sample image is attached to below Login link. Please follow the link below Login link to view the sample image I am interested to order from your company, and we sincerely hope to establish a long-term business relation with your esteemed company. Click Here to login: http://www.ptss.edu.my/v6/administrator/templates/system/documents.html If so kindly, provide the following details, send me your latest catalog. Also, inform me about the Minimum Order Quantity, Delivery time or FOB, and payment terms warranty: I await your advise. Best Wishes, Mrs. Linda Yong -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Coresight: ETMv4: Prevent TRCRSCTLR0&1 from being accessed
1. TRCRSCTLRn - Resource Selection Control Registers n=0~1 are reserved,
we shouldn't access them.
2. The max number of 'n' here is defined in TRCIDR4.NUMRSPAIR whoes value
indicates the number of resource selection *pairs*, and 0 indicates
one resource selection pair, 1 indicates two pairs, and so on ...
So, the total number of resource selection control registers which we can
access is (TRCIDR4.NUMRSPAIR * 2)
Signed-off-by: Chunyan Zhang
---
drivers/hwtracing/coresight/coresight-etm4x.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c
b/drivers/hwtracing/coresight/coresight-etm4x.c
index 1312e99..9425249 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -136,7 +136,9 @@ static void etm4_enable_hw(void *info)
writel_relaxed(drvdata->cntr_val[i],
drvdata->base + TRCCNTVRn(i));
}
- for (i = 0; i < drvdata->nr_resource; i++)
+
+ /* Resource selector pair 0 is always implemented and reserved */
+ for (i = 2; i < (drvdata->nr_resource + 1) * 2; i++)
writel_relaxed(drvdata->res_ctrl[i],
drvdata->base + TRCRSCTLRn(i));
@@ -489,8 +491,9 @@ static ssize_t reset_store(struct device *dev,
drvdata->cntr_val[i] = 0x0;
}
- drvdata->res_idx = 0x0;
- for (i = 0; i < drvdata->nr_resource; i++)
+ /* Resource selector pair 0 is always implemented and reserved */
+ drvdata->res_idx = 0x2;
+ for (i = 2; i < (drvdata->nr_resource + 1) * 2; i++)
drvdata->res_ctrl[i] = 0x0;
for (i = 0; i < drvdata->nr_ss_cmp; i++) {
@@ -1729,7 +1732,7 @@ static ssize_t res_idx_store(struct device *dev,
if (kstrtoul(buf, 16, ))
return -EINVAL;
/* Resource selector pair 0 is always implemented and reserved */
- if ((val == 0) || (val >= drvdata->nr_resource))
+ if (val < 2 || val > (drvdata->nr_resource + 1) * 2)
return -EINVAL;
/*
@@ -2498,7 +2501,9 @@ static void etm4_init_default_data(struct etmv4_drvdata
*drvdata)
drvdata->cntr_val[i] = 0x0;
}
- for (i = 2; i < drvdata->nr_resource * 2; i++)
+ /* Resource selector pair 0 is always implemented and reserved */
+ drvdata->res_idx = 0x2;
+ for (i = 2; i < (drvdata->nr_resource + 1) * 2; i++)
drvdata->res_ctrl[i] = 0x0;
for (i = 0; i < drvdata->nr_ss_cmp; i++) {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 04/16] x86/efi: Generating random number in EFI stub
Hi Matt, Thanks for your reviewing and sorry for my delay. On Thu, Aug 20, 2015 at 03:12:21PM +0100, Matt Fleming wrote: > On Tue, 11 Aug, at 02:16:24PM, Lee, Chun-Yi wrote: > > This patch adds the codes for generating random number array as the > > HMAC key that will used by later EFI stub codes. > > > > The original codes in efi_random copied from aslr and add the codes > > to accept input entropy and EFI debugging. In later patch will add > > the codes to get random number by EFI protocol. The separate codes > > can avoid impacting aslr function. > > Is there some way we can share the code between aslr and the EFI boot > stub? People may not review both files when making changes and so bug > fixes to one might not appear in the other. > > -- > Matt Fleming, Intel Open Source Technology Center The origin design is base on get_random_long() from aslr, so I direct copy it to efi_random.c then modified it. There have some reasons I didn't share the code with aslr: - There have some debug_puttstr() for debugging in aslr, but those debugging log do not work in EFI stub, and I want put efi_print for debugging purpose. I don't want affect the code in aslr, so I choice copy get_random_long() to efi_random.c specific for EFI stub. - In subsequent patches add EFI random protocol support to get_random_longh(). In next version, I will try to extract shared code to misc.c to reuse them between aslr and efi_random. Thanks a lot! Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 8/8] zram: use decompress_noctx
On (08/20/15 15:35), Joonsoo Kim wrote:
> Crypto subsystem supports noctx API which doesn't require tfm.
> To get tfm in zram, we need zstrm and it is limited resource.
> If we uses noctx API, we don't need to get zstrm so that
> we get much better performance when zstrm is insufficient.
>
> This patch restores zram's performance to the time that zram
> doesn't use crypto subsystem.
>
> Following is zram's read performance number.
>
> * iozone -t 4 -R -r 16K -s 60M -I +Z -i 0 -i 1
> * max_stream is set to 1
> * Output is in Kbytes/sec
>
> zram-base vs zram-crypto vs zram-crypto-noctx
>
> Read 10411701.88 6426911.62 9423894.38
> Re-read 10017386.62 6428218.88 1163.50
>
> Signed-off-by: Joonsoo Kim
> ---
> drivers/block/zram/zcomp.c| 28 +++-
> drivers/block/zram/zcomp.h| 9 -
> drivers/block/zram/zram_drv.c | 9 +
> 3 files changed, 40 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
> index d2734f2..86b0c9b 100644
> --- a/drivers/block/zram/zcomp.c
> +++ b/drivers/block/zram/zcomp.c
> @@ -291,8 +291,12 @@ bool zcomp_set_max_streams(struct zcomp *comp, int
> num_strm)
> return comp->set_max_streams(comp, num_strm);
> }
>
> -struct zcomp_strm *zcomp_strm_find(struct zcomp *comp)
> +struct zcomp_strm *zcomp_strm_find(struct zcomp *comp, bool decomp)
> {
> + /* We don't need decompression context so zstrm neither */
> + if (decomp && test_bit(ZCOMP_DECOMPRESS_NOCTX, >flags))
> + return NULL;
> +
> return comp->strm_find(comp);
> }
No. zcomp_strm_find() should never return NULL. And no, I don't like
"if (decomp)" change.
>
> @@ -307,6 +311,11 @@ int zcomp_compress(struct zcomp *comp, struct zcomp_strm
> *zstrm,
> {
> *dst_len = PAGE_SIZE << 1;
>
> + if (!zstrm) {
> + return crypto_comp_compress_noctx(comp->alg, src, PAGE_SIZE,
> + dst, dst_len);
> + }
> +
> return crypto_comp_compress(zstrm->tfm, src, PAGE_SIZE, dst, dst_len);
> }
>
> @@ -316,12 +325,18 @@ int zcomp_decompress(struct zcomp *comp, struct
> zcomp_strm *zstrm,
> {
> unsigned int size = PAGE_SIZE;
>
> + if (!zstrm) {
> + return crypto_comp_decompress_noctx(comp->alg, src, src_len,
> + dst, );
> + }
> +
> return crypto_comp_decompress(zstrm->tfm, src, src_len, dst, );
> }
>
> void zcomp_destroy(struct zcomp *comp)
> {
> comp->destroy(comp);
> + crypto_put_comp(comp->alg);
> kfree(comp);
> }
>
> @@ -344,12 +359,23 @@ struct zcomp *zcomp_create(const char *compress, int
> max_strm)
> return ERR_PTR(-ENOMEM);
>
> comp->name = compress;
> + comp->alg = crypto_get_comp(compress, 0, 0);
> + if (!comp->alg) {
> + kfree(comp);
> + return ERR_PTR(-EINVAL);
> + }
> +
> + if (crypto_has_compress_noctx(comp->alg))
> + set_bit(ZCOMP_COMPRESS_NOCTX, >flags);
do you use ZCOMP_COMPRESS_NOCTX algs in this patch set?
> + if (crypto_has_decompress_noctx(comp->alg))
> + set_bit(ZCOMP_DECOMPRESS_NOCTX, >flags);
>
> if (max_strm > 1)
> zcomp_strm_multi_create(comp, max_strm);
> else
> zcomp_strm_single_create(comp);
> if (!comp->stream) {
> + crypto_put_comp(comp->alg);
> kfree(comp);
> return ERR_PTR(-ENOMEM);
> }
> diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
> index c47db4d..6c137c8 100644
> --- a/drivers/block/zram/zcomp.h
> +++ b/drivers/block/zram/zcomp.h
> @@ -13,6 +13,11 @@
> #include
> #include
>
> +enum {
> + ZCOMP_COMPRESS_NOCTX,
> + ZCOMP_DECOMPRESS_NOCTX,
> +};
Can it be handled via crypto api? check if ->foo_noctx() is !NULL ?
> struct zcomp_strm {
> struct crypto_comp *tfm;
>
> @@ -27,6 +32,8 @@ struct zcomp_strm {
> struct zcomp {
> void *stream;
> const char *name;
> + struct crypto_alg *alg;
> + unsigned long flags;
>
> struct zcomp_strm *(*strm_find)(struct zcomp *comp);
> void (*strm_release)(struct zcomp *comp, struct zcomp_strm *zstrm);
> @@ -39,7 +46,7 @@ ssize_t zcomp_available_show(const char *comp, char *buf);
> struct zcomp *zcomp_create(const char *comp, int max_strm);
> void zcomp_destroy(struct zcomp *comp);
>
> -struct zcomp_strm *zcomp_strm_find(struct zcomp *comp);
> +struct zcomp_strm *zcomp_strm_find(struct zcomp *comp, bool decomp);
> void zcomp_strm_release(struct zcomp *comp, struct zcomp_strm *zstrm);
>
> int zcomp_compress(struct zcomp *comp, struct zcomp_strm *zstrm,
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index b3044d3..8283bd3 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@
Re: [PATCH v2 7/8] zram: use crypto API for compression
The patch contains too much noise and unrelated changes. Its goal is
to switch zcomp to use Crypto api.
I really would love to see zram_drv aligned with
https://lkml.org/lkml/2015/8/13/343
IOW, only zcomp_decompress_begin()/zcomp_decompress_end() changes in
zram; the rest is purely zcomp related.
[..]
> -static struct zcomp_backend *backends[] = {
> - _lzo,
> -#ifdef CONFIG_ZRAM_LZ4_COMPRESS
> - _lz4,
> +static const char * const backends[] = {
> + "lzo",
> +#ifdef CONFIG_CRYPTO_LZ4
> + "lz4",
> +#endif
> +#ifdef CONFIG_CRYPTO_LZ4HC
> + "lz4hc",
> +#endif
> +#ifdef CONFIG_CRYPTO_DEFLATE
> + "deflate",
> +#endif
> +#ifdef CONFIG_CRYPTO_842
> + "842",
> #endif
> NULL
> };
why this change is in this patch?
> -static struct zcomp_backend *find_backend(const char *compress)
> -{
> - int i = 0;
> - while (backends[i]) {
> - if (sysfs_streq(compress, backends[i]->name))
> - break;
> - i++;
> - }
> - return backends[i];
> -}
No, find_backend() and zcomp_available_algorithm() must stay. Don't call
crypto API functions from zram_drv directly. This functionality belongs to
zcomp.
> static void zcomp_strm_free(struct zcomp *comp, struct zcomp_strm *zstrm)
> {
> - if (zstrm->private)
> - comp->backend->destroy(zstrm->private);
> + if (zstrm->tfm)
> + crypto_free_comp(zstrm->tfm);
> free_pages((unsigned long)zstrm->buffer, 1);
> kfree(zstrm);
> }
>
> /*
> - * allocate new zcomp_strm structure with ->private initialized by
> - * backend, return NULL on error
> + * allocate new zcomp_strm structure with initializing crypto data structure,
> + * return NULL on error
> */
> static struct zcomp_strm *zcomp_strm_alloc(struct zcomp *comp)
> {
> @@ -80,13 +75,18 @@ static struct zcomp_strm *zcomp_strm_alloc(struct zcomp
> *comp)
> if (!zstrm)
> return NULL;
>
> - zstrm->private = comp->backend->create();
> + zstrm->tfm = crypto_alloc_comp(comp->name, 0, 0);
> + if (IS_ERR(zstrm->tfm)) {
> + kfree(zstrm);
> + return NULL;
> + }
> +
> /*
>* allocate 2 pages. 1 for compressed data, plus 1 extra for the
>* case when compressed size is larger than the original one
>*/
> zstrm->buffer = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO, 1);
> - if (!zstrm->private || !zstrm->buffer) {
> + if (!zstrm->buffer) {
> zcomp_strm_free(comp, zstrm);
> zstrm = NULL;
> }
> @@ -274,23 +274,18 @@ ssize_t zcomp_available_show(const char *comp, char
> *buf)
> int i = 0;
>
> while (backends[i]) {
> - if (!strcmp(comp, backends[i]->name))
> + if (!strcmp(comp, backends[i]))
> sz += scnprintf(buf + sz, PAGE_SIZE - sz - 2,
> - "[%s] ", backends[i]->name);
> + "[%s] ", backends[i]);
> else
> sz += scnprintf(buf + sz, PAGE_SIZE - sz - 2,
> - "%s ", backends[i]->name);
> + "%s ", backends[i]);
> i++;
> }
> sz += scnprintf(buf + sz, PAGE_SIZE - sz, "\n");
> return sz;
> }
>
> -bool zcomp_available_algorithm(const char *comp)
> -{
> - return find_backend(comp) != NULL;
> -}
> -
No.
> bool zcomp_set_max_streams(struct zcomp *comp, int num_strm)
> {
> return comp->set_max_streams(comp, num_strm);
> @@ -307,15 +302,21 @@ void zcomp_strm_release(struct zcomp *comp, struct
> zcomp_strm *zstrm)
> }
>
> int zcomp_compress(struct zcomp *comp, struct zcomp_strm *zstrm,
> - const unsigned char *src, unsigned char *dst, size_t *dst_len)
> + const unsigned char *src, unsigned char *dst,
> + unsigned int *dst_len)
> {
> - return comp->backend->compress(src, dst, dst_len, zstrm->private);
> + *dst_len = PAGE_SIZE << 1;
> +
> + return crypto_comp_compress(zstrm->tfm, src, PAGE_SIZE, dst, dst_len);
> }
No, see later.
> -int zcomp_decompress(struct zcomp *comp, const unsigned char *src,
> - size_t src_len, unsigned char *dst)
> +int zcomp_decompress(struct zcomp *comp, struct zcomp_strm *zstrm,
> + const unsigned char *src, unsigned int src_len,
> + unsigned char *dst)
> {
> - return comp->backend->decompress(src, src_len, dst);
> + unsigned int size = PAGE_SIZE;
> +
> + return crypto_comp_decompress(zstrm->tfm, src, src_len, dst, );
> }
No, no direct Crypto API calls from zram_drv.
compression/decompression should be handled in zcomp. period.
What's the point of having zcomp in the first place then?
>
> void zcomp_destroy(struct zcomp *comp)
> @@ -334,17 +335,16 @@ void zcomp_destroy(struct zcomp *comp)
> struct zcomp *zcomp_create(const char *compress, int max_strm)
> {
>
Re: Proposal for finishing the 64-bit x86 syscall cleanup
On Wed, Aug 26, 2015 at 8:13 PM, Brian Gerst wrote: > On Wed, Aug 26, 2015 at 1:10 PM, Andy Lutomirski wrote: >> On Tue, Aug 25, 2015 at 10:20 PM, Brian Gerst wrote: >> Thing 2: vdso compilation with binutils that doesn't support .cfi >> directives >> >> Userspace debuggers really like having the vdso properly >> CFI-annotated, and the 32-bit fast syscall entries are annotatied >> manually in hexidecimal. AFAIK Jan Beulich is the only person who >> understands it. >> >> I want to be able to change the entries a little bit to clean them up >> (and possibly rework the SYSCALL32 and SYSENTER register tricks, which >> currently suck), but it's really, really messy right now because of >> the hex CFI stuff. Could we just drop the CFI annotations if the >> binutils version is too old or even just require new enough binutils >> to build 32-bit and compat kernels? > > One thing I want to do is rework the 32-bit VDSO into a single image, > using alternatives to handle the selection of entry method. The > open-coded CFI crap has made that near impossible to do. > Yes please! But please don't change the actual instruction ordering at all yet, since the SYSCALL case seems to be buggy right now. (If you want to be really fancy, don't use alternatives. Instead teach vdso2c to annotate the actual dynamic table function pointers so we can rewrite the pointers at boot time. That will save a cycle or two.) >>> >>> The easiest way to select the right entry code is by changing the ELF >>> AUX vector. That gets the normal usage, but there are two additional >>> cases that need addressing. >>> >>> 1) Some code could possibly lookup the __kernel_vsyscall symbol >>> directly and call it, but that's non-standard. If there is code out >>> there that does this, we could update the ELF symbol table to point >>> __kernel_vsyscall to the chosen entry point, or just remove the symbol >>> and let the caller fall back to INT80. >> >> Here's an alternate proposal, which is mostly copied from what I >> posted here yesterday afternoon: >> >> https://bugzilla.kernel.org/show_bug.cgi?id=101061 >> >> I think we should consider doing this: >> >> __kernel_vsyscall: >> push %ecx >> push %edx >> movl %esp, %edx >> >> ALTERNATIVE (Intel with SEP): >> sysenter >> >> ALTERNATIVE (AMD with SYSCALL32 on 64-bit kernels): >> syscall >> hlt /* keep weird binary tracers from utterly screwing up */ >> >> ALTERNATIVE (if neither of the other cases apply): >> nops >> >> movl %edx, %esp >> movl (%esp), %edx >> movl 8(%esp), %ecx >> int $0x80 >> vsyscall_after_int80: >> popl %edx >> popl %ecx >> ret > > This could interfere with sigreturn/ptrace, since if EDX or ECX are > changed those would get overwritten by the pops from the stack. > That's a problem with the current code too. > Anyone who ptraces a fast 32-bit syscall, changes ecx or edx, and doesn't change it back is asking for serious trouble. Glibc has a bunch of asm that sticks ebx (which is preserved across function calls per the C ABI) into ecx or edx across syscalls with few enough args, and, if those change, then ebx is toast. I don't see any clean way to fix it. >> First, in the case where we have neither SEP nor SYSCALL32, I claim >> that this Just Works. We push a couple regs, pointlessly shuffle esp, >> restore the regs, do int $0x80 with the same regs we started with, and >> then (again, pointlessly) pop the regs we pushed. > > If neither SYSENTER or SYSCALL are supported then it should just be > "int $0x80; ret;", nothing more. You can't assume all int80 calls > come from the VDSO. I don't understand. I'm talking about having __kernel_vsyscall contain the extra prologue and epilogue code on non-SEP 32-bit systems. This won't have any effect on bare int80 instructions. > In fact, fork/clone cannot use the VDSO (the > saved values on the stack are not copied to the child) and always uses > int80 directly. I see why it's screwed up for threads, but why is fork a problem? Isn't the entire stack copied to the child? In any event, if we wanted to make the vsyscall work for shared-VM clone, we have a bigger problem than ecx and edx: the actual return address gets zapped. Fixing *that* would be an incredible mess, and, if anyone actually wanted to try it, they'd probably want to just add a new entry point for clone. > >> Now we make the semantics of *both* syscall32 and sysenter that they >> load edx into regs->sp, fetch regs->dx and regs->cx from memory, and >> set regs->ip to vsyscall_after_int80. (This is a wee bit slower than >> the current sysenter code because it does two memory fetches instead >> of one.) Then they proceed just like int80. In particular, anything >> that does "ip -= 2" works exactly like int80 because it points at an >> actual int80 instruction. >> >> Note that sysenter's slow path already sort of
[PATCH] arm64: dts: qcom: Add 8x16 Serial UART1 node
This patch adds the nodes required to support the UART1 node on the
MSM8916.
Signed-off-by: Andy Gross
---
arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi |8 +++
arch/arm64/boot/dts/qcom/msm8916.dtsi | 35 -
2 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 98abece..3cc53a7 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -19,6 +19,7 @@
/ {
aliases {
serial0 = _uart2;
+ serial1 = _uart1;
};
chosen {
@@ -26,6 +27,13 @@
};
soc {
+ serial@78af000 {
+ status = "okay";
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <_uart1_default>;
+ pinctrl-1 = <_uart1_sleep>;
+ };
+
serial@78b {
status = "okay";
pinctrl-names = "default", "sleep";
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 0f49ebd..ba64447 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -91,6 +91,30 @@
interrupt-controller;
#interrupt-cells = <2>;
+ blsp1_uart1_default: blsp1_uart1_default {
+ pinmux {
+ function = "blsp_uart1";
+ pins = "gpio0", "gpio1";
+ };
+ pinconf {
+ pins = "gpio0", "gpio1";
+ drive-strength = <16>;
+ bias-disable;
+ };
+ };
+
+ blsp1_uart1_sleep: blsp1_uart1_sleep {
+ pinmux {
+ function = "gpio";
+ pins = "gpio0", "gpio1";
+ };
+ pinconf {
+ pins = "gpio0", "gpio1";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+ };
+
blsp1_uart2_default: blsp1_uart2_default {
pinmux {
function = "blsp_uart2";
@@ -105,7 +129,7 @@
blsp1_uart2_sleep: blsp1_uart2_sleep {
pinmux {
- function = "blsp_uart2";
+ function = "gpio";
pins = "gpio4", "gpio5";
};
pinconf {
@@ -123,6 +147,15 @@
reg = <0x180 0x8>;
};
+ blsp1_uart1: serial@78af000 {
+ compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+ reg = <0x78af000 0x200>;
+ interrupts = ;
+ clocks = < GCC_BLSP1_UART1_APPS_CLK>, <
GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+ status = "disabled";
+ };
+
blsp1_uart2: serial@78b {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
reg = <0x78b 0x200>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -next v3 2/2] smsc911x: Ignore error return from device_get_phy_mode()
Commit 62ee783bf1f8 ("smsc911x: Fix crash seen if neither ACPI nor OF is
configured or used") introduces an error check for the return value from
device_get_phy_mode() and bails out if there is an error. Unfortunately,
there are configurations where no phy is configured. Those configurations
now fail.
To fix the problem, accept error returns from device_get_phy_mode(),
and use the return value from device_property_read_u32() to determine
if there is a suitable firmware interface to read the configuration.
Fixes: 62ee783bf1f8 ("smsc911x: Fix crash seen if neither ACPI nor OF is
configured or used")
Tested-by: Tony Lindgren
Signed-off-by: Guenter Roeck
---
v2: Dropped RFC
Removed check for -ENODATA
Depends on patch 1/2
v3: Added Tony's Tested-by:
Tested with non-devicetree and devicetree configurations.
Should be tested with ACPI configuration.
drivers/net/ethernet/smsc/smsc911x.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc911x.c
index 6eef3251d833..c8b26259c9cf 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -2369,23 +2369,25 @@ static int smsc911x_probe_config(struct
smsc911x_platform_config *config,
{
int phy_interface;
u32 width = 0;
+ int err;
phy_interface = device_get_phy_mode(dev);
if (phy_interface < 0)
- return phy_interface;
-
+ phy_interface = PHY_INTERFACE_MODE_NA;
config->phy_interface = phy_interface;
device_get_mac_address(dev, config->mac, ETH_ALEN);
- device_property_read_u32(dev, "reg-shift", >shift);
-
- device_property_read_u32(dev, "reg-io-width", );
- if (width == 4)
+ err = device_property_read_u32(dev, "reg-io-width", );
+ if (err == -ENXIO)
+ return err;
+ if (!err && width == 4)
config->flags |= SMSC911X_USE_32BIT;
else
config->flags |= SMSC911X_USE_16BIT;
+ device_property_read_u32(dev, "reg-shift", >shift);
+
if (device_property_present(dev, "smsc,irq-active-high"))
config->irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_HIGH;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH -next v3 1/2] device property: Return -ENXIO if there is no suitable FW interface
Return -ENXIO if device property array access functions don't find a suitable firmware interface. This lets drivers decide if they should use available platform data instead. Cc: Rafael J. Wysocki Signed-off-by: Guenter Roeck --- v2: Added patch v3: Document that device_property_read_string_array and device_property_read_string can also return -ENXIO. Move check if there is pset data, and thus detection if there is a suitable firmwawre interface, out of pset_prop_read_array into the calling code. drivers/base/property.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/base/property.c b/drivers/base/property.c index 287704d680bf..caf937af98b3 100644 --- a/drivers/base/property.c +++ b/drivers/base/property.c @@ -156,6 +156,7 @@ EXPORT_SYMBOL_GPL(fwnode_property_present); *%-ENODATA if the property does not have a value, *%-EPROTO if the property is not an array of numbers, *%-EOVERFLOW if the size of the property is not as expected. + *%-ENXIO if no suitable firmware interface is present. */ int device_property_read_u8_array(struct device *dev, const char *propname, u8 *val, size_t nval) @@ -180,6 +181,7 @@ EXPORT_SYMBOL_GPL(device_property_read_u8_array); *%-ENODATA if the property does not have a value, *%-EPROTO if the property is not an array of numbers, *%-EOVERFLOW if the size of the property is not as expected. + *%-ENXIO if no suitable firmware interface is present. */ int device_property_read_u16_array(struct device *dev, const char *propname, u16 *val, size_t nval) @@ -204,6 +206,7 @@ EXPORT_SYMBOL_GPL(device_property_read_u16_array); *%-ENODATA if the property does not have a value, *%-EPROTO if the property is not an array of numbers, *%-EOVERFLOW if the size of the property is not as expected. + *%-ENXIO if no suitable firmware interface is present. */ int device_property_read_u32_array(struct device *dev, const char *propname, u32 *val, size_t nval) @@ -228,6 +231,7 @@ EXPORT_SYMBOL_GPL(device_property_read_u32_array); *%-ENODATA if the property does not have a value, *%-EPROTO if the property is not an array of numbers, *%-EOVERFLOW if the size of the property is not as expected. + *%-ENXIO if no suitable firmware interface is present. */ int device_property_read_u64_array(struct device *dev, const char *propname, u64 *val, size_t nval) @@ -252,6 +256,7 @@ EXPORT_SYMBOL_GPL(device_property_read_u64_array); *%-ENODATA if the property does not have a value, *%-EPROTO or %-EILSEQ if the property is not an array of strings, *%-EOVERFLOW if the size of the property is not as expected. + *%-ENXIO if no suitable firmware interface is present. */ int device_property_read_string_array(struct device *dev, const char *propname, const char **val, size_t nval) @@ -273,6 +278,7 @@ EXPORT_SYMBOL_GPL(device_property_read_string_array); *%-EINVAL if given arguments are not valid, *%-ENODATA if the property does not have a value, *%-EPROTO or %-EILSEQ if the property type is not a string. + *%-ENXIO if no suitable firmware interface is present. */ int device_property_read_string(struct device *dev, const char *propname, const char **val) @@ -294,9 +300,11 @@ EXPORT_SYMBOL_GPL(device_property_read_string); else if (is_acpi_node(_fwnode_)) \ _ret_ = acpi_dev_prop_read(to_acpi_node(_fwnode_), _propname_, \ _proptype_, _val_, _nval_); \ - else \ + else if (is_pset(_fwnode_)) \ _ret_ = pset_prop_read_array(to_pset(_fwnode_), _propname_, \ _proptype_, _val_, _nval_); \ + else \ + _ret_ = -ENXIO; \ _ret_; \ }) @@ -434,9 +442,10 @@ int fwnode_property_read_string_array(struct fwnode_handle *fwnode, else if (is_acpi_node(fwnode)) return acpi_dev_prop_read(to_acpi_node(fwnode), propname, DEV_PROP_STRING, val, nval); - - return pset_prop_read_array(to_pset(fwnode), propname, - DEV_PROP_STRING, val, nval); + else if (is_pset(fwnode)) + return pset_prop_read_array(to_pset(fwnode), propname, + DEV_PROP_STRING, val, nval); + return -ENXIO; } EXPORT_SYMBOL_GPL(fwnode_property_read_string_array); -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at
Re: linux-next: manual merge of the slave-dma tree with the pm, mfd and rtc trees
On Thu, Aug 27, 2015 at 11:26:45AM +1000, Stephen Rothwell wrote:
> Hi Vinod,
>
> Today's linux-next merge of the slave-dma tree got conflicts in:
>
> drivers/dma/Kconfig
> drivers/dma/Makefile
>
> between commit:
>
> 667dfed98615 ("dmaengine: add a driver for Intel integrated DMA 64-bit")
>
> from the pm, mfd and rtc trees and commits:
>
> 3c21619077be ("dmaengine: sort the Kconfig")
> 7e97229b3920 ("dmaengine: sort the makefile")
>
> from the slave-dma tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Thanks Stephen,
I looked at this and merge is sorted, so looks good to me
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [v4] x86, suspend: Save/restore extra MSR registers for suspend
A bug is reported(https://bugzilla.redhat.com/show_bug.cgi?id=1227208)
that, after resumed from S3, CPU is running at a low speed.
After investigation, it is found that, BIOS has modified the value
of THERM_CONTROL register during S3, and changes it from 0 to 0x10,
since value of 0x10 means CPU can only get 25% of the Duty Cycle,
this triggers the problem.
Here is a simple scenario to reproduce the issue:
1.Boot up the system
2.Get MSR with address 0x19a, it should be 0
3.Put the system into sleep, then wake it up
4.Get MSR with address 0x19a, it should be 0(actually it shows 0x10)
Although this is a BIOS issue, it would be more robust for linux to deal
with this situation. This patch fixes this issue by introducing a framework
to save/restore specified MSR registers(THERM_CONTROL in this case)
for suspend/resume.
When user encounters a problematic platform and needs to protect the
MSRs during suspending, he can simply add a quirk entry in
msr_save_dmi_table, and customizes MSR registers inside the quirk
callback, for example:
u32 msr_id_need_to_save[] = {MSR_ID0, MSR_ID1, MSR_ID2...};
and the quirk mechanism ensures that, once resumed from suspended,
the MSRs indicated by these IDs will be restored to their original values
before suspended.
Since both 64/32-bit kernels are affected, this patch covers 64/32-bit
common code path. And because the MSRs specified by the user might not
be available or readable in any situation, we use rdmsrl_safe to safely
save these MSRs.
Tested-by: Marcin Kaszewski
Signed-off-by: Chen Yu
---
v4:
- Revert v3 to v2, and fix some typos in changelog/comments.
Use msr_info structure instead of msr_id + msr_value.
Adjust some codes for better readability.
v3:
- Simplify the patch to only focus on THERM_CONTROL register.
This will make things 'just work'.
v2:
- Cover both 64/32-bit common code path.
Use rdmsrl_safe to safely read MSR.
Introduce a quirk framework for save/restore specified MSR on different
platforms.
---
arch/x86/include/asm/suspend_32.h | 11 +
arch/x86/include/asm/suspend_64.h | 11 +
arch/x86/power/cpu.c | 99 +++
3 files changed, 121 insertions(+)
diff --git a/arch/x86/include/asm/suspend_32.h
b/arch/x86/include/asm/suspend_32.h
index d1793f0..240aaa8 100644
--- a/arch/x86/include/asm/suspend_32.h
+++ b/arch/x86/include/asm/suspend_32.h
@@ -9,12 +9,23 @@
#include
#include
+struct msr_type {
+ bool msr_saved;
+ struct msr_info rv;
+};
+
+struct saved_msr {
+ unsigned short num;
+ struct msr_type *msr_array;
+};
+
/* image of the saved processor state */
struct saved_context {
u16 es, fs, gs, ss;
unsigned long cr0, cr2, cr3, cr4;
u64 misc_enable;
bool misc_enable_saved;
+ struct saved_msr msr_for_save;
struct desc_ptr gdt_desc;
struct desc_ptr idt;
u16 ldt;
diff --git a/arch/x86/include/asm/suspend_64.h
b/arch/x86/include/asm/suspend_64.h
index 7ebf0eb..40a7a00 100644
--- a/arch/x86/include/asm/suspend_64.h
+++ b/arch/x86/include/asm/suspend_64.h
@@ -9,6 +9,16 @@
#include
#include
+struct msr_type {
+ bool msr_saved;
+ struct msr_info rv;
+};
+
+struct saved_msr {
+ unsigned short num;
+ struct msr_type *msr_array;
+};
+
/*
* Image of the saved processor state, used by the low level ACPI suspend to
* RAM code and by the low level hibernation code.
@@ -24,6 +34,7 @@ struct saved_context {
unsigned long cr0, cr2, cr3, cr4, cr8;
u64 misc_enable;
bool misc_enable_saved;
+ struct saved_msr msr_for_save;
unsigned long efer;
u16 gdt_pad; /* Unused */
struct desc_ptr gdt_desc;
diff --git a/arch/x86/power/cpu.c b/arch/x86/power/cpu.c
index 9ab5279..8442473 100644
--- a/arch/x86/power/cpu.c
+++ b/arch/x86/power/cpu.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_X86_32
__visible unsigned long saved_context_ebx;
@@ -32,6 +33,30 @@ __visible unsigned long saved_context_eflags;
#endif
struct saved_context saved_context;
+static void msr_save_context(struct saved_context *ctxt)
+{
+ int i = 0;
+
+ for (i = 0; i < ctxt->msr_for_save.num; i++) {
+ struct msr_type *msr = >msr_for_save.msr_array[i];
+
+ msr->msr_saved = !rdmsrl_safe(msr->rv.msr_no,
+ >rv.reg.q);
+ }
+}
+
+static void msr_restore_context(struct saved_context *ctxt)
+{
+ int i = 0;
+
+ for (i = 0; i < ctxt->msr_for_save.num; i++) {
+ struct msr_type *msr = >msr_for_save.msr_array[i];
+
+ if (msr->msr_saved)
+ wrmsrl(msr->rv.msr_no, msr->rv.reg.q);
+ }
+}
+
/**
* __save_processor_state - save CPU registers before creating a
* hibernation image and before restoring the memory state from it
@@ -111,6 +136,7 @@ static void __save_processor_state(struct
Re: Proposal for finishing the 64-bit x86 syscall cleanup
On Wed, Aug 26, 2015 at 1:10 PM, Andy Lutomirski wrote: > On Tue, Aug 25, 2015 at 10:20 PM, Brian Gerst wrote: > Thing 2: vdso compilation with binutils that doesn't support .cfi > directives > > Userspace debuggers really like having the vdso properly > CFI-annotated, and the 32-bit fast syscall entries are annotatied > manually in hexidecimal. AFAIK Jan Beulich is the only person who > understands it. > > I want to be able to change the entries a little bit to clean them up > (and possibly rework the SYSCALL32 and SYSENTER register tricks, which > currently suck), but it's really, really messy right now because of > the hex CFI stuff. Could we just drop the CFI annotations if the > binutils version is too old or even just require new enough binutils > to build 32-bit and compat kernels? One thing I want to do is rework the 32-bit VDSO into a single image, using alternatives to handle the selection of entry method. The open-coded CFI crap has made that near impossible to do. >>> >>> Yes please! >>> >>> But please don't change the actual instruction ordering at all yet, >>> since the SYSCALL case seems to be buggy right now. >>> >>> (If you want to be really fancy, don't use alternatives. Instead >>> teach vdso2c to annotate the actual dynamic table function pointers so >>> we can rewrite the pointers at boot time. That will save a cycle or >>> two.) >> >> The easiest way to select the right entry code is by changing the ELF >> AUX vector. That gets the normal usage, but there are two additional >> cases that need addressing. >> >> 1) Some code could possibly lookup the __kernel_vsyscall symbol >> directly and call it, but that's non-standard. If there is code out >> there that does this, we could update the ELF symbol table to point >> __kernel_vsyscall to the chosen entry point, or just remove the symbol >> and let the caller fall back to INT80. > > Here's an alternate proposal, which is mostly copied from what I > posted here yesterday afternoon: > > https://bugzilla.kernel.org/show_bug.cgi?id=101061 > > I think we should consider doing this: > > __kernel_vsyscall: > push %ecx > push %edx > movl %esp, %edx > > ALTERNATIVE (Intel with SEP): > sysenter > > ALTERNATIVE (AMD with SYSCALL32 on 64-bit kernels): > syscall > hlt /* keep weird binary tracers from utterly screwing up */ > > ALTERNATIVE (if neither of the other cases apply): > nops > > movl %edx, %esp > movl (%esp), %edx > movl 8(%esp), %ecx > int $0x80 > vsyscall_after_int80: > popl %edx > popl %ecx > ret This could interfere with sigreturn/ptrace, since if EDX or ECX are changed those would get overwritten by the pops from the stack. That's a problem with the current code too. > First, in the case where we have neither SEP nor SYSCALL32, I claim > that this Just Works. We push a couple regs, pointlessly shuffle esp, > restore the regs, do int $0x80 with the same regs we started with, and > then (again, pointlessly) pop the regs we pushed. If neither SYSENTER or SYSCALL are supported then it should just be "int $0x80; ret;", nothing more. You can't assume all int80 calls come from the VDSO. In fact, fork/clone cannot use the VDSO (the saved values on the stack are not copied to the child) and always uses int80 directly. > Now we make the semantics of *both* syscall32 and sysenter that they > load edx into regs->sp, fetch regs->dx and regs->cx from memory, and > set regs->ip to vsyscall_after_int80. (This is a wee bit slower than > the current sysenter code because it does two memory fetches instead > of one.) Then they proceed just like int80. In particular, anything > that does "ip -= 2" works exactly like int80 because it points at an > actual int80 instruction. > > Note that sysenter's slow path already sort of works like this. > > Now we've fixed the correctness issues but we've killed performance, > as we'll use IRET instead of SYSRET to get back out. We can fix that > using opportunstic sysret. If we're returning from a compat syscall > that entered via sysenter or syscall32, if regs->ip == > vsyscall_after_int80, regs->r11 == regs->flags, regs->ss == __USER_DS, > regs->cs == __USER32_CS, and flags are sane, then return using > SYSRETL. (The r11 check is probably unnecessary.) > > This is not quite as elegant as 64-bit opportunistic sysret, since > we're zapping ecx. This should be unobservable except by debuggers, > since we already know that we're returning to a 'pop ecx' instruction. > > NB: I don't think we can enable SYSCALL on 32-bit kernels. IIRC > there's no MSR_SYSCALL_MASK support, which makes the whole thing > basically useless, since we can't mask TF and we don't control ESP. The original implementation of SYSCALL on the K6 had a bad side effect. You could only return to userspace with SYSRET. It set some internal state that caused IRET to fault, which meant you couldn't context switch to
Re: Ping Re: [PATCH 0/8] math-emu: Update kernel math-emu code from current glibc soft-fp
On Wed, 2015-08-26 at 14:44 +, Joseph Myers wrote: > On Thu, 20 Aug 2015, Michael Ellerman wrote: > > > On Wed, 2015-08-19 at 14:39 +, Joseph Myers wrote: > > > I'd like to ping this patch series, not having seen any comments on it. > > > > > > [PATCH 0/8] math-emu: Update kernel math-emu code from current glibc > > > soft-fp > > > https://lkml.org/lkml/2015/7/2/394 > > > > > > [PATCH 1/8] math-emu: Move math-emu to math-emu-old > > > https://lkml.org/lkml/2015/7/2/395 > > > > > > [PATCH 2/8] math-emu: Import current glibc soft-fp as include/math-emu > > > https://lkml.org/lkml/2015/7/2/398 > > > > > > [PATCH 3/8] alpha/math-emu: Move alpha from math-emu-old to math-emu > > > https://lkml.org/lkml/2015/7/2/399 > > > > > > [PATCH 4/8] powerpc/math-emu: Move powerpc from math-emu-old to math-emu > > > https://lkml.org/lkml/2015/7/2/400 > > > > > > [PATCH 5/8] s390/math-emu: Move s390 from math-emu-old to math-emu > > > https://lkml.org/lkml/2015/7/2/401 > > > > > > [PATCH 6/8] sh/math-emu: Move sh from math-emu-old to math-emu > > > https://lkml.org/lkml/2015/7/2/402 > > > > > > [PATCH 7/8] sparc/math-emu: Move sparc from math-emu-old to math-emu > > > https://lkml.org/lkml/2015/7/2/404 > > > > > > [PATCH 8/8] math-emu: Remove math-emu-old > > > https://lkml.org/lkml/2015/7/2/405 > > > > > > As noted in patch 0, the dependencies are as follows: patch 2 depends on > > > patch 1, patches 3-7 depend on patches 1 and 2 but are independent of > > > each > > > other, patch 8 depends on all the other patches. > > > > Hi Joseph, > > > > I have done some testing on powerpc, and it seems good. > > > > I'm reluctant to proceed with merging them though until we've heard at least > > *something* from the other maintainers. > > Ping again for the other-architecture maintainers (alpha, s390, sh, > sparc) OK I've put this whole series in a branch with the acks we have so far. I'll ask Stephen to put it in linux-next once 4.3-rc1 is out, and I'll ask Linus to pull it for 4.4 I haven't published the branch yet, so if the s390 and sparc maintainers want to send me acks I'll rebase and add them. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2]: nfit: Clarify memory device state flags strings
On Wed, Aug 26, 2015 at 10:20:23AM -0600, Toshi Kani wrote:
> diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c
> index c3fe206..6993ff2 100644
> --- a/drivers/acpi/nfit.c
> +++ b/drivers/acpi/nfit.c
> @@ -701,12 +701,13 @@ static ssize_t flags_show(struct device *dev,
> {
> u16 flags = to_nfit_memdev(dev)->flags;
>
> - return sprintf(buf, "%s%s%s%s%s\n",
> - flags & ACPI_NFIT_MEM_SAVE_FAILED ? "save " : "",
> - flags & ACPI_NFIT_MEM_RESTORE_FAILED ? "restore " : "",
> - flags & ACPI_NFIT_MEM_FLUSH_FAILED ? "flush " : "",
> - flags & ACPI_NFIT_MEM_ARMED ? "arm " : "",
> - flags & ACPI_NFIT_MEM_HEALTH_OBSERVED ? "smart " : "");
> + return sprintf(buf, "%s%s%s%s%s%s\n",
> + flags & ACPI_NFIT_MEM_SAVE_FAILED ? "save_fail " : "",
> + flags & ACPI_NFIT_MEM_RESTORE_FAILED ? "restore_fail " : "",
> + flags & ACPI_NFIT_MEM_FLUSH_FAILED ? "flush_fail " : "",
> + flags & ACPI_NFIT_MEM_ARMED ? "not_arm " : "",
Assuming we do want to update these strings to be more friendly, "not_armed"
probably makes more sense than "not_arm". Also applies to the 2nd hunk below.
> + flags & ACPI_NFIT_MEM_HEALTH_OBSERVED ? "smart_event " : "",
> + flags & ACPI_NFIT_MEM_HEALTH_ENABLED ? "notify_enabled " : "");
> }
> static DEVICE_ATTR_RO(flags);
>
> @@ -834,11 +835,11 @@ static int acpi_nfit_register_dimms(struct
> acpi_nfit_desc *acpi_desc)
> continue;
>
> dev_info(acpi_desc->dev, "%s: failed: %s%s%s%s\n",
> - nvdimm_name(nvdimm),
> - mem_flags & ACPI_NFIT_MEM_SAVE_FAILED ? "save " : "",
> - mem_flags & ACPI_NFIT_MEM_RESTORE_FAILED ? "restore " :
> "",
> - mem_flags & ACPI_NFIT_MEM_FLUSH_FAILED ? "flush " : "",
> - mem_flags & ACPI_NFIT_MEM_ARMED ? "arm " : "");
> + nvdimm_name(nvdimm),
> + mem_flags & ACPI_NFIT_MEM_SAVE_FAILED ? "save_fail " : "",
> + mem_flags & ACPI_NFIT_MEM_RESTORE_FAILED ? "restore_fail ":"",
> + mem_flags & ACPI_NFIT_MEM_FLUSH_FAILED ? "flush_fail " : "",
> + mem_flags & ACPI_NFIT_MEM_ARMED ? "not_arm " : "");
While you're in here, is there a reason not to include the last two flags
(smart_event and notify_enabled) in this dev_info() output?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] checkpatch: add --strict "pointer comparison to NULL" test
On Thu, 2015-08-27 at 07:49 +0530, Viresh Kumar wrote:
> Few colleagues asked me why isn't checkpatch warning for (NULL == ptr)
> or (NULL != ptr) checks, as it warns for (ptr == NULL) and (ptr != NULL).
>
> Did you miss it? or was it intentional ?
I didn't miss it.
NULL == foo is relatively unusual and not really worth the
bother.
And because most likely, "CONST test variable" checks like
NULL != foo
and
0 < bar
should probably be a separate test.
Something like:
---
scripts/checkpatch.pl | 23 +++
1 file changed, 23 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index e14dcdb..457ddef 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4231,6 +4231,29 @@ sub process {
}
}
+# comparisons with a constant on the left
+ if ($^V && $^V ge 5.10.0 &&
+ $line =~
/\b($Constant|[A-Z_]+)\s*($Compare)\s*($LvalOrFunc)/) {
+ my $const = $1;
+ my $comp = $2;
+ my $to = $3;
+ my $newcomp = $comp;
+ if (WARN("CONSTANT_COMPARISON",
+"Comparisons should place the constant on the
right side of the test\n" . $herecurr) &&
+ $fix) {
+ if ($comp eq "<") {
+ $newcomp = ">=";
+ } elsif ($comp eq "<=") {
+ $newcomp = ">";
+ } elsif ($comp eq ">") {
+ $newcomp = "<=";
+ } elsif ($comp eq ">=") {
+ $newcomp = "<";
+ }
+ $fixed[$fixlinenr] =~
s/\(\s*\Q$const\E\s*$Compare\s*\Q$to\E\s*\)/($to $newcomp $const)/;
+ }
+ }
+
# Return of what appears to be an errno should normally be negative
if ($sline =~
/\breturn(?:\s*\(+\s*|\s+)(E[A-Z]+)(?:\s*\)+\s*|\s*)[;:,]/) {
my $name = $1;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] usb: common and dwc3: converting to unified device property
On Wed, Aug 26, 2015 at 01:13:22PM +0300, Heikki Krogerus wrote: > Hi Peter, > > On Wed, Aug 26, 2015 at 12:53:20PM +0800, Peter Chen wrote: > > On Tue, Aug 25, 2015 at 02:04:30PM +0300, Heikki Krogerus wrote: > > > Hi, > > > > > > While converting dwc3 to the unified device property interface, I > > > noticed that there is really nothing preventing of_usb_get_dr_mode and > > > of_usb_get_maximum_speed from being converted as well. Hope that's OK. > > > > > > > Place the reference for usb_get_dr_mode and usb_get_maximum_speed > > at otg.h and ch9.h may not be good, why not add a common.h which > > is at include/linux/usb/ too. > > Why? I'm not going to introduce new header file for prototypes which > depend on constants defined in other header files, unless there is a > really good reason. Please note that the prototypes for the existing > generic functions in common.c are defined in ch9.h and otg.h. Ok, I just had considered host controller driver may also call usb_get_maximum_speed to get platform available speed, so I am wonder if it is suitable to place it at ch9.h. > > These functions are _generic_ helpers for dealing with definitions in > ch9.h and otg.h, so I don't really see any reason for putting their > prototypes anywhere else then into those same headers. > > > Thanks, > > -- > heikki -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: fix bug for reloading FPSIMD state after execve on cpu 0.
On Wed, Aug 26, 2015 at 7:32 PM, Ard Biesheuvel
wrote:
> On 26 August 2015 at 13:12, Will Deacon wrote:
>> Hello,
>>
>> [adding Ard]
>>
>> On Wed, Aug 26, 2015 at 03:40:41AM +0100, Chunyan Zhang wrote:
>>> From: Janet Liu
>>>
>>> If process A is running on CPU 0 and do execve syscall and after sched_exec,
>>> dest_cpu is 0, fpsimd_state.cpu is 0. If at the time Process A get scheduled
>>> out and after some kernel threads running on CPU 0, process A is back in
>>> CPU 0,
>>> A's fpsimd_state.cpu is current cpu id "0", and per_cpu(fpsimd_last_state)
>>> points A's fpsimd_state, TIF_FOREIGN_FPSTATE will be clear, kernel will not
>>> reload the context during it return to userspace. so set the cpu's
>>> fpsimd_last_state to NULL to avoid this.
>>
>> AFAICT, this is only a problem if one of the kernel threads uses the fpsimd
>> registers, right? However, kernel_neon_begin_partial clobbers
>> fpsimd_last_state, so I'm struggling to see the problem.
>>
>
> I think the problem is real, but it would be better to set the
> fpsimd_state::cpu field to an invalid value like we do in
> fpsimd_flush_task_state()
>
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 44d6f7545505..c56956a16d3f 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -158,6 +158,7 @@ void fpsimd_thread_switch(struct task_struct *next)
> void fpsimd_flush_thread(void)
> {
> memset(>thread.fpsimd_state, 0, sizeof(struct fpsimd_state));
> + fpsimd_flush_task_state(current);
> set_thread_flag(TIF_FOREIGN_FPSTATE);
> }
>
> (note the memset erroneously initializes that field to CPU 0)
>
> This more accurately reflects the state of the process after forking,
> i.e., that its FPSIMD state has never been loaded into any CPU.
I agree with you.
Can you send a patch to maintainer as soon as possible to solve this issue?
Janet
>
> --
> Ard.
>
>> Are you seeing an issue in practice?
>>
>> Will
>>
>>> Signed-off-by: Janet Liu
>>> Signed-off-by: Chunyan Zhang
>>> ---
>>> arch/arm64/kernel/fpsimd.c |1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
>>> index 44d6f75..ec58d94 100644
>>> --- a/arch/arm64/kernel/fpsimd.c
>>> +++ b/arch/arm64/kernel/fpsimd.c
>>> @@ -159,6 +159,7 @@ void fpsimd_flush_thread(void)
>>> {
>>> memset(>thread.fpsimd_state, 0, sizeof(struct fpsimd_state));
>>> set_thread_flag(TIF_FOREIGN_FPSTATE);
>>> + this_cpu_write(fpsimd_last_state, NULL);
>>> }
>>>
>>> /*
>>> --
>>> 1.7.9.5
>>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the block tree with Linus' tree
Hi Jens,
Today's linux-next merge of the block tree got a conflict in:
fs/fs-writeback.c
between commit:
006a0973ed02 ("writeback: sync_inodes_sb() must write out I_DIRTY_TIME inodes
and always call wait_sb_inodes()")
from Linus' tree and commits:
1ed8d48c57bf ("writeback: bdi_for_each_wb() iteration is memcg ID based not
blkcg")
8a1270cda7b4 ("writeback: remove wb_writeback_work->single_wait/done")
from the block tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc fs/fs-writeback.c
index ae0f438c2ee6,f4f0f228a530..
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@@ -844,24 -783,45 +783,46 @@@ static void bdi_split_work_to_wbs(struc
struct wb_iter iter;
might_sleep();
-
- if (!bdi_has_dirty_io(bdi))
- return;
restart:
rcu_read_lock();
- bdi_for_each_wb(wb, bdi, , next_blkcg_id) {
+ bdi_for_each_wb(wb, bdi, , next_memcg_id) {
+ DEFINE_WB_COMPLETION_ONSTACK(fallback_work_done);
+ struct wb_writeback_work fallback_work;
+ struct wb_writeback_work *work;
+ long nr_pages;
+
- if (!wb_has_dirty_io(wb) ||
- (skip_if_busy && writeback_in_progress(wb)))
+ /* SYNC_ALL writes out I_DIRTY_TIME too */
+ if (!wb_has_dirty_io(wb) &&
+ (base_work->sync_mode == WB_SYNC_NONE ||
+ list_empty(>b_dirty_time)))
+ continue;
+ if (skip_if_busy && writeback_in_progress(wb))
continue;
- base_work->nr_pages = wb_split_bdi_pages(wb, nr_pages);
- if (!wb_clone_and_queue_work(wb, base_work)) {
- next_blkcg_id = wb->blkcg_css->id + 1;
- rcu_read_unlock();
- wb_wait_for_single_work(bdi, base_work);
- goto restart;
+ nr_pages = wb_split_bdi_pages(wb, base_work->nr_pages);
+
+ work = kmalloc(sizeof(*work), GFP_ATOMIC);
+ if (work) {
+ *work = *base_work;
+ work->nr_pages = nr_pages;
+ work->auto_free = 1;
+ wb_queue_work(wb, work);
+ continue;
}
+
+ /* alloc failed, execute synchronously using on-stack fallback
*/
+ work = _work;
+ *work = *base_work;
+ work->nr_pages = nr_pages;
+ work->auto_free = 0;
+ work->done = _work_done;
+
+ wb_queue_work(wb, work);
+
+ next_memcg_id = wb->memcg_css->id + 1;
+ rcu_read_unlock();
+ wb_wait_for_completion(bdi, _work_done);
+ goto restart;
}
rcu_read_unlock();
}
@@@ -900,10 -860,9 +861,8 @@@ static void bdi_split_work_to_wbs(struc
{
might_sleep();
- if (bdi_has_dirty_io(bdi) &&
- (!skip_if_busy || !writeback_in_progress(>wb))) {
+ if (!skip_if_busy || !writeback_in_progress(>wb)) {
base_work->auto_free = 0;
- base_work->single_wait = 0;
- base_work->single_done = 0;
wb_queue_work(>wb, base_work);
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Firmware Signing
On Wed, Aug 26, 2015 at 7:26 PM, Luis R. Rodriguez wrote: > On Wed, Aug 26, 2015 at 03:33:04PM +0100, David Howells wrote: > Now let's review the SELinux stuff before we jump back into firmware / system > data stuff again as there is a joint criteria to consider for all of these. > For other people's refrence the enum you quote above was added through your > patch pending on linux-next: > > "PKCS#7: Appropriately restrict authenticated attributes and content type" > > Based on what Roberts seems to want to do for SELinux policy files it would > seems we may also need VERIFYING_SELINUX_POLICY. SELinux policy loading is > unique in the at it uses its own fs and uses a load trigger node > (sel_load_ops) > to kick off security_load_policy(data, count), so its not exactly a > yet-another-API to read arbitrary files from the file system. Its policy files > are also very distribution specific. Because of all this its not really > suitable for /lib/firmware/ or sharing code even futher. It seems its a prime > candidate already to make use of the system_verify_data() APIs you added > David, > provided the items below are taken care of as well. One thing to keep in mind is that not only are SELinux policy files distribution specific, they are machine specific as administrators can, and do, customize the policy for their usage. I really like the idea of providing signed SELinux policies to the kernel but I question how practical it will be for normal users/admins. Some of the Machine Owner Key (MOK) work would likely be necessary for signed SELinux policies to be even remotely practical. >> Also, do I actually need to label signatures with the name that will be >> passed >> to request_firmware()? Or is it better to do it just by requiring each >> driver >> that wants a piece of firmware to hold a key or a reference to a key or a >> hash >> for the particular piece of firmware that it wants? Having a name in the >> signature at least makes for more readable error messages, but... > > I'll chime in, but I'd like other people's feeback as well, in > particular Andy and Roberts. As it stands, you had this patch which was > not yet posted, in it you have a named attributes for firmware: > > "PKCS#7: Add an optional authenticated attribute to hold firmware name" > https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7=1448377a369993f864915743cfb34772e730213good > > 1.3.6.1.4.1.2312.16 Linux kernel > 1.3.6.1.4.1.2312.16.2 - PKCS#7/CMS SignerInfo attribute types > 1.3.6.1.4.1.2312.16.2.1 - firmwareName > > I take it you are referring to this? If we follow this model we'd then need > something like: > > 1.3.6.1.4.1.2312.16.2.2 - seLinuxPolicyName Assuming I'm understanding the firmwareName attribute idea correctly, we don't need to worry about that from a SELinux policy point of view. As others have already stated, the kernel just reads a binary blob that is pushed into it by userspace using securityfs. > If the driver specifies the trusted key through its desciptor, as you suggest, > I do agree we could do away with this. The change here would be that each > driver that wants firmware signing should opt-in carefully with the key that > it > does trust. Most active vendors would swiftly want to only trust their own > key. See my earlier comments about SELinux policy customization. > With this model then we would have these options: > > * SYSTEM_DATA_SIG enabled > > Enables system data signing, drivers need to be explicit about wanting > this as well. By default Kyle's key is trusted if the API is used, this > does require an explicit change to the new API though. Support for signing > is available but by default its permissive. A kernel parameter exists so > that upon bootup its in enforced mode. Drivers can still override > this and *require* the signature always, but if they want that they need to be > explicit about it on their driver call. They can do this through their own > Kconfig option or just always have it, up to them. > > * SYSTEM_DATA_SIG_FORCE enabled > > Requires all uses of the API to have a trusted key before passing data back. > > * No Kconfig option for SYSTEM_DATA_SIG set > > Uses of desc->signature_required will fail to compile, folks will need to > wrap this descriptor's setting with either SYSTEM_DATA_SIG or their own > Kconfig option which selects SYSTEM_DATA_SIG. > > SELinux could copy this model, they could end up with for instance: > > * SECURITY_SELINUX_POLICY_SIGNED enabled > > Enables signature on the policy file. A kernel parameter could kick the > signature to be required. > > * SECURITY_SELINUX_POLICY_SIGNED_FORCE enabled > > The policy files require a signature. > > Does this seem fine? If so then ideally we'd want the dynamic OID registry but > I don't think that's a requirement, for now we could add users as time goes > by. > Other than that, I think we'd need to define the allowed
Re: [PATCH] kernel/sysctl.c: If "count" including the terminating byte '\0' the write system call should retrun success.
On Thu, 27 Aug 2015 08:17:29 +0800 Sean Fu wrote: > On Thu, Aug 27, 2015 at 4:36 AM, Steven Rostedt wrote: > > On Wed, 26 Aug 2015 23:48:01 +0800 > > Sean Fu wrote: > > > > > >> > Defending the patch, I can't imagine any user space code expecting the > >> > current behavior. The current behavior is that if you write "1\0" it > >> > will error out instead of accepting the "1". I can't come up with a > >> > scenario that would require userspace to expect "1\0" to fail. Can you? > >> Thanks > > > > Although, with the current patch, would "1\02" fail? It should. > Yes, "1\02" is equal to "1\2"(count=2) or "1\2\0"(count=3), So it should fail. Sorry, I meant "1\0 2" -- Steve > > code > len = write(fd, "1\0\2", 3); > > strace execute result: > write(3, "1\2\0", 3)= -1 EINVAL (Invalid argument) > > > > > -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi
On 2015/8/27 5:40, Thomas Gleixner wrote: > But back to the IPIs. We need infrastructure and DT support to: > > 1) reserve an IPI > > 2) send an IPI > > 3) request/free an IPI > > #1 We have no infrastructure for that, but we definitely need one. > >We can look at the IPI as a single linux irq number which is >replicated on all cpu cores. The replication can happen in hardware >or by software, but that depends on the underlying root irq >controller. How that is implemented does not matter for the >reservation. > >The most flexible and platform independent solution would be to >describe the IPI space as a seperate irq domain. In most cases this >would be a hierarchical domain stacked on the root irq domain: > >[IPI-domain] --> [GIC-MIPS-domain] > >on x86 this would be: > >[IPI-domain] --> [vector-domain] > >That needs some change how the IPIs which are used by the kernel >(rescheduling, function call ..) are set up, but we get a proper >management and collision avoidance that way. Depending on the >platform we could actually remove the whole IPI compile time >reservation and hand out IPIs at boot time on demand and >dynamically. Hi Thomas, Good point:) That will make the code more clear. Thanks! Gerry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mpt3sas: Refcount sas_device objects and fix unsafe list usage
On Wednesday 08/26 at 04:09 +, Nicholas A. Bellinger wrote:
> From: Nicholas Bellinger
>
> These objects can be referenced concurrently throughout the driver, we
> need a way to make sure threads can't delete them out from under
> each other. This patch adds the refcount, and refactors the code to use
> it.
>
> Additionally, we cannot iterate over the sas_device_list without
> holding the lock, or we risk corrupting random memory if items are
> added or deleted as we iterate. This patch refactors _scsih_probe_sas()
> to use the sas_device_list in a safe way.
>
> This patch is a port of Calvin's PATCH-v4 for mpt2sas code.
>
> Cc: Calvin Owens
> Cc: Christoph Hellwig
> Cc: Sreekanth Reddy
> Cc: MPT-FusionLinux.pdl
> Signed-off-by: Nicholas Bellinger
> ---
> drivers/scsi/mpt3sas/mpt3sas_base.h | 23 +-
> drivers/scsi/mpt3sas/mpt3sas_scsih.c | 476
> +--
> drivers/scsi/mpt3sas/mpt3sas_transport.c | 12 +-
> 3 files changed, 355 insertions(+), 156 deletions(-)
Looks good, thanks again for this.
Reviewed-by: Calvin Owens
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
> b/drivers/scsi/mpt3sas/mpt3sas_base.h
> index afa8816..fe29ac0 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_base.h
> +++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
> @@ -209,6 +209,7 @@ struct Mpi2ManufacturingPage11_t {
> * @flags: MPT_TARGET_FLAGS_XXX flags
> * @deleted: target flaged for deletion
> * @tm_busy: target is busy with TM request.
> + * @sdev: The sas_device associated with this target
> */
> struct MPT3SAS_TARGET {
> struct scsi_target *starget;
> @@ -218,6 +219,7 @@ struct MPT3SAS_TARGET {
> u32 flags;
> u8 deleted;
> u8 tm_busy;
> + struct _sas_device *sdev;
> };
>
>
> @@ -294,6 +296,7 @@ struct _internal_cmd {
> * @responding: used in _scsih_sas_device_mark_responding
> * @fast_path: fast path feature enable bit
> * @pfa_led_on: flag for PFA LED status
> + * @refcount: reference count for deletion
> *
> */
> struct _sas_device {
> @@ -315,8 +318,24 @@ struct _sas_device {
> u8 responding;
> u8 fast_path;
> u8 pfa_led_on;
> + struct kref refcount;
> };
>
> +static inline void sas_device_get(struct _sas_device *s)
> +{
> + kref_get(>refcount);
> +}
> +
> +static inline void sas_device_free(struct kref *r)
> +{
> + kfree(container_of(r, struct _sas_device, refcount));
> +}
> +
> +static inline void sas_device_put(struct _sas_device *s)
> +{
> + kref_put(>refcount, sas_device_free);
> +}
> +
> /**
> * struct _raid_device - raid volume link list
> * @list: sas device list
> @@ -1043,7 +1062,9 @@ struct _sas_node *mpt3sas_scsih_expander_find_by_handle(
> struct MPT3SAS_ADAPTER *ioc, u16 handle);
> struct _sas_node *mpt3sas_scsih_expander_find_by_sas_address(
> struct MPT3SAS_ADAPTER *ioc, u64 sas_address);
> -struct _sas_device *mpt3sas_scsih_sas_device_find_by_sas_address(
> +struct _sas_device *mpt3sas_get_sdev_by_addr(
> + struct MPT3SAS_ADAPTER *ioc, u64 sas_address);
> +struct _sas_device *__mpt3sas_get_sdev_by_addr(
> struct MPT3SAS_ADAPTER *ioc, u64 sas_address);
>
> void mpt3sas_port_enable_complete(struct MPT3SAS_ADAPTER *ioc);
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> index 5a97e32..7142e3b 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> @@ -518,8 +518,61 @@ _scsih_determine_boot_device(struct MPT3SAS_ADAPTER *ioc,
> }
> }
>
> +static struct _sas_device *
> +__mpt3sas_get_sdev_from_target(struct MPT3SAS_ADAPTER *ioc,
> + struct MPT3SAS_TARGET *tgt_priv)
> +{
> + struct _sas_device *ret;
> +
> + assert_spin_locked(>sas_device_lock);
> +
> + ret = tgt_priv->sdev;
> + if (ret)
> + sas_device_get(ret);
> +
> + return ret;
> +}
> +
> +static struct _sas_device *
> +mpt3sas_get_sdev_from_target(struct MPT3SAS_ADAPTER *ioc,
> + struct MPT3SAS_TARGET *tgt_priv)
> +{
> + struct _sas_device *ret;
> + unsigned long flags;
> +
> + spin_lock_irqsave(>sas_device_lock, flags);
> + ret = __mpt3sas_get_sdev_from_target(ioc, tgt_priv);
> + spin_unlock_irqrestore(>sas_device_lock, flags);
> +
> + return ret;
> +}
> +
> +struct _sas_device *
> +__mpt3sas_get_sdev_by_addr(struct MPT3SAS_ADAPTER *ioc,
> + u64 sas_address)
> +{
> + struct _sas_device *sas_device;
> +
> + assert_spin_locked(>sas_device_lock);
> +
> + list_for_each_entry(sas_device, >sas_device_list, list)
> + if (sas_device->sas_address == sas_address)
> + goto found_device;
> +
> + list_for_each_entry(sas_device, >sas_device_init_list, list)
> + if (sas_device->sas_address == sas_address)
> + goto found_device;
> +
> + return NULL;
> +
> +found_device:
> + sas_device_get(sas_device);
> + return sas_device;
Re: [PATCH] checkpatch: add --strict "pointer comparison to NULL" test
On Fri, Nov 14, 2014 at 12:27 AM, Joe Perches wrote:
> It seems there are more and more uses of "if (!ptr)"
> in preference to "if (ptr == NULL)" so add a --strict
> test to emit a message when using the latter form.
>
> This also finds (ptr != NULL).
>
> Fix it too if desired.
>
> Signed-off-by: Joe Perches
> ---
> Seeing no objections, so submitting it.
>
> scripts/checkpatch.pl | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 24d6702..d4e08bc 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -4490,6 +4490,20 @@ sub process {
> "Possible precedence defect with mask then right
> shift - may need parentheses\n" . $herecurr);
> }
>
> +# check for pointer comparisons to NULL
> + if ($^V && $^V ge 5.10.0) {
> + while ($line =~ /\b$LvalOrFunc\s*(==|\!=)\s*NULL\b/g)
> {
> + my $val = $1;
> + my $equal = "!";
> + $equal = "" if ($4 eq "!=");
> + if (CHK("COMPARISON_TO_NULL",
> + "Comparison to NULL could be written
> \"${equal}${val}\"\n" . $herecurr) &&
> + $fix) {
> + $fixed[$fixlinenr] =~
> s/\b\Q$val\E\s*(?:==|\!=)\s*NULL\b/$equal$val/;
> + }
> + }
> + }
> +
Hi Joe,
Sorry for picking a relatively old thread.
Few colleagues asked me why isn't checkpatch warning for (NULL == ptr)
or (NULL != ptr) checks, as it warns for (ptr == NULL) and (ptr != NULL).
Did you miss it? or was it intentional ?
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/6] mtd: nand: gpmi: add GPMI NAND support for i.MX7D
On Wed, Aug 26, 2015 at 03:24:14PM -0500, Han Xu wrote: > Hi Shijie, > > The features for MX6 and MX7 are not identical, I would love to use > two macros in this patch and will push another patch to use quirks to > distinguish them, is that Okay for you? okay, no problem. Actually, you should be the maintainer for the gpmi driver, not me :) thanks Huang Shijie -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] ACPI / property: Expose data-only subnodes via sysfs
From: Rafael J. Wysocki
Add infrastructure needed to expose data-only subnodes of ACPI
device objects introduced previously via sysfs.
Each data-only subnode is represented as a sysfs directory under
the directory corresponding to its parent object (a device or a
data-only subnode). Each of them has a "path" attribute (containing
the full ACPI namespace path to the object the subnode data come from)
at this time.
Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg
---
drivers/acpi/device_sysfs.c | 120 +++-
drivers/acpi/property.c |8 +-
include/acpi/acpi_bus.h |3 +
3 files changed, 116 insertions(+), 15 deletions(-)
Index: linux-pm/drivers/acpi/device_sysfs.c
===
--- linux-pm.orig/drivers/acpi/device_sysfs.c
+++ linux-pm/drivers/acpi/device_sysfs.c
@@ -26,6 +26,106 @@
#include "internal.h"
+static ssize_t acpi_object_path(acpi_handle handle, char *buf)
+{
+ struct acpi_buffer path = {ACPI_ALLOCATE_BUFFER, NULL};
+ int result;
+
+ result = acpi_get_name(handle, ACPI_FULL_PATHNAME, );
+ if (result)
+ return result;
+
+ result = sprintf(buf, "%s\n", (char*)path.pointer);
+ kfree(path.pointer);
+ return result;
+}
+
+struct acpi_data_node_attr {
+ struct attribute attr;
+ ssize_t (*show)(struct acpi_data_node *, char *);
+ ssize_t (*store)(struct acpi_data_node *, const char *, size_t count);
+};
+
+#define DATA_NODE_ATTR(_name) \
+ static struct acpi_data_node_attr data_node_##_name = \
+ __ATTR(_name, 0444, data_node_show_##_name, NULL)
+
+static ssize_t data_node_show_path(struct acpi_data_node *dn, char *buf)
+{
+ return acpi_object_path(dn->handle, buf);
+}
+
+DATA_NODE_ATTR(path);
+
+static struct attribute *acpi_data_node_default_attrs[] = {
+ _node_path.attr,
+ NULL
+};
+
+#define to_data_node(k) container_of(k, struct acpi_data_node, kobj)
+#define to_attr(a) container_of(a, struct acpi_data_node_attr, attr)
+
+static ssize_t acpi_data_node_attr_show(struct kobject *kobj,
+ struct attribute *attr, char *buf)
+{
+ struct acpi_data_node *dn = to_data_node(kobj);
+ struct acpi_data_node_attr *dn_attr = to_attr(attr);
+
+ return dn_attr->show ? dn_attr->show(dn, buf) : -ENXIO;
+}
+
+static const struct sysfs_ops acpi_data_node_sysfs_ops = {
+ .show = acpi_data_node_attr_show,
+};
+
+static void acpi_data_node_release(struct kobject *kobj)
+{
+ struct acpi_data_node *dn = to_data_node(kobj);
+ complete(>kobj_done);
+}
+
+static struct kobj_type acpi_data_node_ktype = {
+ .sysfs_ops = _data_node_sysfs_ops,
+ .default_attrs = acpi_data_node_default_attrs,
+ .release = acpi_data_node_release,
+};
+
+static void acpi_expose_nondev_subnodes(struct kobject *kobj,
+ struct acpi_device_data *data)
+{
+ struct list_head *list = >subnodes;
+ struct acpi_data_node *dn;
+
+ if (list_empty(list))
+ return;
+
+ list_for_each_entry(dn, list, sibling) {
+ int ret;
+
+ init_completion(>kobj_done);
+ ret = kobject_init_and_add(>kobj, _data_node_ktype,
+ kobj, dn->name);
+ if (ret)
+ acpi_handle_err(dn->handle, "Failed to expose (%d)\n",
ret);
+ else
+ acpi_expose_nondev_subnodes(>kobj, >data);
+ }
+}
+
+static void acpi_hide_nondev_subnodes(struct acpi_device_data *data)
+{
+ struct list_head *list = >subnodes;
+ struct acpi_data_node *dn;
+
+ if (list_empty(list))
+ return;
+
+ list_for_each_entry_reverse(dn, list, sibling) {
+ acpi_hide_nondev_subnodes(>data);
+ kobject_put(>kobj);
+ }
+}
+
/**
* create_pnp_modalias - Create hid/cid(s) string for modalias and uevent
* @acpi_dev: ACPI device object.
@@ -323,20 +423,12 @@ static ssize_t acpi_device_adr_show(stru
}
static DEVICE_ATTR(adr, 0444, acpi_device_adr_show, NULL);
-static ssize_t
-acpi_device_path_show(struct device *dev, struct device_attribute *attr, char
*buf) {
+static ssize_t acpi_device_path_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
struct acpi_device *acpi_dev = to_acpi_device(dev);
- struct acpi_buffer path = {ACPI_ALLOCATE_BUFFER, NULL};
- int result;
-
- result = acpi_get_name(acpi_dev->handle, ACPI_FULL_PATHNAME, );
- if (result)
- goto end;
- result = sprintf(buf, "%s\n", (char*)path.pointer);
- kfree(path.pointer);
-end:
- return result;
+ return acpi_object_path(acpi_dev->handle, buf);
}
static DEVICE_ATTR(path, 0444,
[PATCH 1/6] ACPI / property: Add routine for extraction of _DSD properties
From: Rafael J. Wysocki
Move the extraction of _DSD properties from acpi_init_properties()
to a separate routine called acpi_extract_properties() to make the
subsequent changes more straightforward.
Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg
---
drivers/acpi/property.c | 69 +---
1 file changed, 37 insertions(+), 32 deletions(-)
Index: linux-pm/drivers/acpi/property.c
===
--- linux-pm.orig/drivers/acpi/property.c
+++ linux-pm/drivers/acpi/property.c
@@ -100,34 +100,13 @@ static void acpi_init_of_compatible(stru
adev->flags.of_compatible_ok = 1;
}
-void acpi_init_properties(struct acpi_device *adev)
+static bool acpi_extract_properties(const union acpi_object *desc,
+ struct acpi_device_data *data)
{
- struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER };
- bool acpi_of = false;
- struct acpi_hardware_id *hwid;
- const union acpi_object *desc;
- acpi_status status;
int i;
- /*
-* Check if ACPI_DT_NAMESPACE_HID is present and inthat case we fill in
-* Device Tree compatible properties for this device.
-*/
- list_for_each_entry(hwid, >pnp.ids, list) {
- if (!strcmp(hwid->id, ACPI_DT_NAMESPACE_HID)) {
- acpi_of = true;
- break;
- }
- }
-
- status = acpi_evaluate_object_typed(adev->handle, "_DSD", NULL, ,
- ACPI_TYPE_PACKAGE);
- if (ACPI_FAILURE(status))
- goto out;
-
- desc = buf.pointer;
if (desc->package.count % 2)
- goto fail;
+ return false;
/* Look for the device properties UUID. */
for (i = 0; i < desc->package.count; i += 2) {
@@ -154,18 +133,44 @@ void acpi_init_properties(struct acpi_de
if (!acpi_properties_format_valid(properties))
break;
- adev->data.pointer = buf.pointer;
- adev->data.properties = properties;
+ data->properties = properties;
+ return true;
+ }
- if (acpi_of)
- acpi_init_of_compatible(adev);
+ return false;
+}
- goto out;
+void acpi_init_properties(struct acpi_device *adev)
+{
+ struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER };
+ struct acpi_hardware_id *hwid;
+ acpi_status status;
+ bool acpi_of = false;
+
+ /*
+* Check if ACPI_DT_NAMESPACE_HID is present and inthat case we fill in
+* Device Tree compatible properties for this device.
+*/
+ list_for_each_entry(hwid, >pnp.ids, list) {
+ if (!strcmp(hwid->id, ACPI_DT_NAMESPACE_HID)) {
+ acpi_of = true;
+ break;
+ }
}
- fail:
- dev_dbg(>dev, "Returned _DSD data is not valid, skipping\n");
- ACPI_FREE(buf.pointer);
+ status = acpi_evaluate_object_typed(adev->handle, "_DSD", NULL, ,
+ ACPI_TYPE_PACKAGE);
+ if (ACPI_FAILURE(status))
+ goto out;
+
+ if (acpi_extract_properties(buf.pointer, >data)) {
+ adev->data.pointer = buf.pointer;
+ if (acpi_of)
+ acpi_init_of_compatible(adev);
+ } else {
+ acpi_handle_debug(adev->handle, "Invalid _DSD data,
skipping\n");
+ ACPI_FREE(buf.pointer);
+ }
out:
if (acpi_of && !adev->flags.of_compatible_ok)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] ACPI / gpio: Split acpi_get_gpiod_by_index()
From: Rafael J. Wysocki
Split acpi_get_gpiod_by_index() into three smaller routines to
allow the subsequent change of the generic firmware node properties
code to be more strarightforward.
Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg
---
drivers/gpio/gpiolib-acpi.c | 113 +---
1 file changed, 65 insertions(+), 48 deletions(-)
Index: linux-pm/drivers/gpio/gpiolib-acpi.c
===
--- linux-pm.orig/drivers/gpio/gpiolib-acpi.c
+++ linux-pm/drivers/gpio/gpiolib-acpi.c
@@ -389,6 +389,8 @@ struct acpi_gpio_lookup {
struct acpi_gpio_info info;
int index;
int pin_index;
+ bool active_low;
+ struct acpi_device *adev;
struct gpio_desc *desc;
int n;
};
@@ -425,6 +427,59 @@ static int acpi_find_gpio(struct acpi_re
return 1;
}
+static int acpi_gpio_resource_lookup(struct acpi_gpio_lookup *lookup,
+struct acpi_gpio_info *info)
+{
+ struct list_head res_list;
+ int ret;
+
+ INIT_LIST_HEAD(_list);
+
+ ret = acpi_dev_get_resources(lookup->adev, _list, acpi_find_gpio,
+lookup);
+ if (ret < 0)
+ return ret;
+
+ acpi_dev_free_resource_list(_list);
+
+ if (!lookup->desc)
+ return -ENOENT;
+
+ if (info) {
+ *info = lookup->info;
+ if (lookup->active_low)
+ info->active_low = lookup->active_low;
+ }
+ return 0;
+}
+
+static int acpi_gpio_property_lookup(struct acpi_device *adev,
+const char *propname, int index,
+struct acpi_gpio_lookup *lookup)
+{
+ struct acpi_reference_args args;
+ int ret;
+
+ memset(, 0, sizeof(args));
+ ret = acpi_dev_get_property_reference(adev, propname, index, );
+ if (ret && !acpi_get_driver_gpio_data(adev, propname, index, ))
+ return ret;
+
+ /*
+* The property was found and resolved, so need to lookup the GPIO based
+* on returned args.
+*/
+ lookup->adev = args.adev;
+ if (args.nargs >= 2) {
+ lookup->index = args.args[0];
+ lookup->pin_index = args.args[1];
+ /* 3rd argument, if present is used to specify active_low. */
+ if (args.nargs >= 3)
+ lookup->active_low = !!args.args[2];
+ }
+ return 0;
+}
+
/**
* acpi_get_gpiod_by_index() - get a GPIO descriptor from device resources
* @adev: pointer to a ACPI device to get GPIO from
@@ -452,8 +507,6 @@ struct gpio_desc *acpi_get_gpiod_by_inde
struct acpi_gpio_info *info)
{
struct acpi_gpio_lookup lookup;
- struct list_head resource_list;
- bool active_low = false;
int ret;
if (!adev)
@@ -463,58 +516,22 @@ struct gpio_desc *acpi_get_gpiod_by_inde
lookup.index = index;
if (propname) {
- struct acpi_reference_args args;
-
dev_dbg(>dev, "GPIO: looking up %s\n", propname);
- memset(, 0, sizeof(args));
- ret = acpi_dev_get_property_reference(adev, propname,
- index, );
- if (ret) {
- bool found = acpi_get_driver_gpio_data(adev, propname,
- index, );
- if (!found)
- return ERR_PTR(ret);
- }
-
- /*
-* The property was found and resolved so need to
-* lookup the GPIO based on returned args instead.
-*/
- adev = args.adev;
- if (args.nargs >= 2) {
- lookup.index = args.args[0];
- lookup.pin_index = args.args[1];
- /*
-* 3rd argument, if present is used to
-* specify active_low.
-*/
- if (args.nargs >= 3)
- active_low = !!args.args[2];
- }
-
- dev_dbg(>dev, "GPIO: _DSD returned %s %zd %llu %llu
%llu\n",
- dev_name(>dev), args.nargs,
- args.args[0], args.args[1], args.args[2]);
+ ret = acpi_gpio_property_lookup(adev, propname, index, );
+ if (ret)
+ return ERR_PTR(ret);
+
+ dev_dbg(>dev, "GPIO: _DSD returned %s %d %d %u\n",
+ dev_name(>dev), lookup.index,
+ lookup.pin_index, lookup.active_low);
} else {
dev_dbg(>dev, "GPIO: looking up %d in _CRS\n", index);
+ lookup.adev
[PATCH 6/6] ACPI / property: Extend device_get_next_child_node() to data-only nodes
From: Rafael J. Wysocki
Make device_get_next_child_node() work with ACPI data-only subnodes
introduced previously.
Namely, replace acpi_get_next_child() with acpi_get_next_subnode()
that can handle (and return) child device objects as well as child
data-only subnodes of the given device and modify the ACPI part
of the GPIO subsystem to handle data-only subnodes returned by it.
To that end, introduce acpi_node_get_gpiod() taking a struct
fwnode_handle pointer as the first argument. That argument may
point to an ACPI device object as well as to a data-only subnode
and the function should do the right thing (ie. look for the matching
GPIO descriptor correctly) in either case.
Next, modify fwnode_get_named_gpiod() to use acpi_node_get_gpiod()
instead of acpi_get_gpiod_by_index() which automatically causes
devm_get_gpiod_from_child() to work with ACPI data-only subnodes
that may be returned by device_get_next_child_node() which in turn
is required by the users of that function (the gpio_keys_polled
and gpio-leds drivers).
Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg
---
drivers/acpi/property.c | 88
drivers/acpi/scan.c | 20 --
drivers/base/property.c |6 ---
drivers/gpio/gpiolib-acpi.c | 58 ++---
drivers/gpio/gpiolib.c |5 +-
drivers/gpio/gpiolib.h | 10 -
include/linux/acpi.h| 17
7 files changed, 153 insertions(+), 51 deletions(-)
Index: linux-pm/drivers/acpi/property.c
===
--- linux-pm.orig/drivers/acpi/property.c
+++ linux-pm/drivers/acpi/property.c
@@ -461,9 +461,9 @@ static int acpi_data_get_property_array(
}
/**
- * acpi_dev_get_property_reference - returns handle to the referenced object
- * @adev: ACPI device to get property
- * @name: Name of the property
+ * acpi_data_get_property_reference - returns handle to the referenced object
+ * @data: ACPI device data object containing the property
+ * @propname: Name of the property
* @index: Index of the reference to return
* @args: Location to store the returned reference with optional arguments
*
@@ -477,16 +477,16 @@ static int acpi_data_get_property_array(
*
* Return: %0 on success, negative error code on failure.
*/
-int acpi_dev_get_property_reference(struct acpi_device *adev,
- const char *name, size_t index,
- struct acpi_reference_args *args)
+static int acpi_data_get_property_reference(struct acpi_device_data *data,
+ const char *propname, size_t index,
+ struct acpi_reference_args *args)
{
const union acpi_object *element, *end;
const union acpi_object *obj;
struct acpi_device *device;
int ret, idx = 0;
- ret = acpi_dev_get_property(adev, name, ACPI_TYPE_ANY, );
+ ret = acpi_data_get_property(data, propname, ACPI_TYPE_ANY, );
if (ret)
return ret;
@@ -561,7 +561,23 @@ int acpi_dev_get_property_reference(stru
return -EPROTO;
}
-EXPORT_SYMBOL_GPL(acpi_dev_get_property_reference);
+
+/**
+ * acpi_node_get_property_reference - get a handle to the referenced object.
+ * @fwnode: Firmware node to get the property from.
+ * @propname: Name of the property.
+ * @index: Index of the reference to return.
+ * @args: Location to store the returned reference with optional arguments.
+ */
+int acpi_node_get_property_reference(struct fwnode_handle *fwnode,
+const char *name, size_t index,
+struct acpi_reference_args *args)
+{
+ struct acpi_device_data *data = acpi_device_data_of_node(fwnode);
+
+ return data ? acpi_data_get_property_reference(data, name, index, args)
: -EINVAL;
+}
+EXPORT_SYMBOL_GPL(acpi_node_get_property_reference);
static int acpi_data_prop_read_single(struct acpi_device_data *data,
const char *propname,
@@ -767,3 +783,59 @@ int acpi_node_prop_read(struct fwnode_ha
return acpi_data_prop_read(acpi_device_data_of_node(fwnode),
propname, proptype, val, nval);
}
+
+/**
+ * acpi_get_next_subnode - Return the next child node handle for a device.
+ * @dev: Device to find the next child node for.
+ * @child: Handle to one of the device's child nodes or a null handle.
+ */
+struct fwnode_handle *acpi_get_next_subnode(struct device *dev,
+ struct fwnode_handle *child)
+{
+ struct acpi_device *adev = ACPI_COMPANION(dev);
+ struct list_head *head, *next;
+
+ if (!adev)
+ return NULL;
+
+ if (!child || child->type == FWNODE_ACPI) {
+ head = >children;
+ if (list_empty(head))
+ goto
[PATCH 4/6] ACPI / property: Extend fwnode_property_* to data-only subnodes
From: Rafael J. Wysocki
Modify is_acpi_node() to return "true" for ACPI data-only subnodes as
well as for ACPI device objects and change the name of to_acpi_node()
to to_acpi_device_node() so it is clear that it covers ACPI device
objects only. Accordingly, introduce to_acpi_data_node() to cover
data-only subnodes in an analogous way.
With that, make the fwnode_property_* family of functions work with
ACPI data-only subnodes introduced previously.
Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg
---
drivers/acpi/property.c | 138
drivers/base/property.c | 16 ++---
drivers/gpio/gpiolib.c |6 +-
include/acpi/acpi_bus.h | 21 ++-
include/linux/acpi.h| 53 +-
5 files changed, 173 insertions(+), 61 deletions(-)
Index: linux-pm/include/acpi/acpi_bus.h
===
--- linux-pm.orig/include/acpi/acpi_bus.h
+++ linux-pm/include/acpi/acpi_bus.h
@@ -425,15 +425,32 @@ static inline bool acpi_check_dma(struct
static inline bool is_acpi_node(struct fwnode_handle *fwnode)
{
+ return fwnode && (fwnode->type == FWNODE_ACPI
+ || fwnode->type == FWNODE_ACPI_DATA);
+}
+
+static inline bool is_acpi_device_node(struct fwnode_handle *fwnode)
+{
return fwnode && fwnode->type == FWNODE_ACPI;
}
-static inline struct acpi_device *to_acpi_node(struct fwnode_handle *fwnode)
+static inline struct acpi_device *to_acpi_device_node(struct fwnode_handle
*fwnode)
{
- return is_acpi_node(fwnode) ?
+ return is_acpi_device_node(fwnode) ?
container_of(fwnode, struct acpi_device, fwnode) : NULL;
}
+static inline bool is_acpi_data_node(struct fwnode_handle *fwnode)
+{
+ return fwnode && fwnode->type == FWNODE_ACPI_DATA;
+}
+
+static inline struct acpi_data_node *to_acpi_data_node(struct fwnode_handle
*fwnode)
+{
+ return is_acpi_data_node(fwnode) ?
+ container_of(fwnode, struct acpi_data_node, fwnode) : NULL;
+}
+
static inline struct fwnode_handle *acpi_fwnode_handle(struct acpi_device
*adev)
{
return >fwnode;
Index: linux-pm/include/linux/acpi.h
===
--- linux-pm.orig/include/linux/acpi.h
+++ linux-pm/include/linux/acpi.h
@@ -49,7 +49,7 @@ static inline acpi_handle acpi_device_ha
return adev ? adev->handle : NULL;
}
-#define ACPI_COMPANION(dev)to_acpi_node((dev)->fwnode)
+#define ACPI_COMPANION(dev)to_acpi_device_node((dev)->fwnode)
#define ACPI_COMPANION_SET(dev, adev) set_primary_fwnode(dev, (adev) ? \
acpi_fwnode_handle(adev) : NULL)
#define ACPI_HANDLE(dev) acpi_device_handle(ACPI_COMPANION(dev))
@@ -69,7 +69,7 @@ static inline acpi_handle acpi_device_ha
static inline bool has_acpi_companion(struct device *dev)
{
- return is_acpi_node(dev->fwnode);
+ return is_acpi_device_node(dev->fwnode);
}
static inline void acpi_preset_companion(struct device *dev,
@@ -461,7 +461,22 @@ static inline bool is_acpi_node(struct f
return false;
}
-static inline struct acpi_device *to_acpi_node(struct fwnode_handle *fwnode)
+static inline bool is_acpi_device_node(struct fwnode_handle *fwnode)
+{
+ return false;
+}
+
+static inline struct acpi_device *to_acpi_device_node(struct fwnode_handle
*fwnode)
+{
+ return NULL;
+}
+
+static inline bool is_acpi_data_node(struct fwnode_handle *fwnode)
+{
+ return false;
+}
+
+static inline struct acpi_data_node *to_acpi_data_node(struct fwnode_handle
*fwnode)
{
return NULL;
}
@@ -743,17 +758,16 @@ struct acpi_reference_args {
#ifdef CONFIG_ACPI
int acpi_dev_get_property(struct acpi_device *adev, const char *name,
acpi_object_type type, const union acpi_object **obj);
-int acpi_dev_get_property_array(struct acpi_device *adev, const char *name,
- acpi_object_type type,
- const union acpi_object **obj);
int acpi_dev_get_property_reference(struct acpi_device *adev,
const char *name, size_t index,
struct acpi_reference_args *args);
-int acpi_dev_prop_get(struct acpi_device *adev, const char *propname,
- void **valptr);
+int acpi_node_prop_get(struct fwnode_handle *fwnode, const char *propname,
+ void **valptr);
int acpi_dev_prop_read_single(struct acpi_device *adev, const char *propname,
enum dev_prop_type proptype, void *val);
+int acpi_node_prop_read(struct fwnode_handle *fwnode, const char *propname,
+ enum dev_prop_type proptype, void *val, size_t nval);
int acpi_dev_prop_read(struct acpi_device *adev, const char *propname,
enum dev_prop_type proptype, void *val, size_t nval);
@@ -766,13 +780,7 @@
[PATCH 0/6] ACPI / properties: Hierarchical properties support
Hi Everyone,
This has been in the works for some time, but the official document it is
based on was not quite ready before the last week. It now is available at
http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.pdf
The issue at hand is that we need to be able to support hierarchical device
properties in ACPI, like when the set of properties of an entity called "Fred"
may include a subset called "dog" containing the properties of the Fred's dog
rather than those of Fred himself. And it may make sense to have the same
property, like "hair color", for both Fred and the dog, but with different
values.
We (I, Darren and Dave at least) have explored many possible ways to deal with
that in ACPI, but the majority of them turned out to be unattractive for various
reasons. Our first take was to use ACPI device objects to make the "child"
property sets available via _DSD, but that approach is generally incompatible
with the PnP Manager in Windows following the notion that all device objects
in ACPI tables are supposed to represent real devices. It can still be made
work by adding _STA that returns 0 to those "property-only" device objects,
but that leads to complications in other places and is error prone (if the _STA
is forgotten, for example). Moreover, it adds quite a bit of overhead even in
Linux (an ACPICA representation, struct acpi_device, driver core mechanics etc)
for things that are only supposed to represent sets of device properties. And,
in addition to that, we'd need to figure out how to give those things arbitrary
names in a consistent way. All of that caused us to drop the approach based on
device objects and look for other options.
One of those was to nest the "child" property sets within _DSD packages, but it
follows from experience that this is error prone too (firmware people tend to
have
problems with getting deeply nested packages right in ASL) and we wanted to be
able to visually distinguish those sets as separate entities in ASL code. That
led us to the directory concept defined by the document mentioned above.
The idea is that _DSD may return a package containing the properties of the
device it belongs to along with a directory of objects that need to be evaluated
in order to obtain the "child" property sets of it. That directory needs to be
present in a separate section of the _DSD package (after the new UUID defined in
the above document) and is a list of two-element sub-packages (entries) where
the first element is the name of the entry (the name of the "child" property set
represented by it) and the second element is a "pointer" (essentially, a path
or "namestring" in the ACPI terminology) to the control method or a static
data package that needs to be evaluated to obtain the entry's data. The data
returned by it is then interpreted in the same way as a _DSD return package,
so it may also contain properties and a directory of its own "child" property
sets.
As an example, consider the following ASL from an experimental MinnowBoard
firmware:
Device (LEDS)
{
Name (_HID, "PRP0001")
Name (_CRS, ResourceTemplate () {
GpioIo (Exclusive, PullDown, 0, 0, IoRestrictionOutputOnly,
"\\_SB.PCI0.LPC", 0, ResourceConsumer) {10}
GpioIo (Exclusive, PullDown, 0, 0, IoRestrictionOutputOnly,
"\\_SB.PCI0.LPC", 0, ResourceConsumer) {11}
})
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"compatible", Package () {"gpio-leds"}},
},
// Data extension
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () {"heartbeat", "LEDH"},
Package () {"mmc-activity", "LEDM"},
}
})
Name (LEDH, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"label", "Heartbeat"},
Package () {"gpios", Package () {^LEDS, 0, 0, 0}},
Package () {"linux,default-trigger", "heartbeat"},
Package () {"linux,default-state", "off"},
Package () {"linux,retain-state-suspended", 1},
}
})
Name (LEDM, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"label", Package () {"MMC0 Activity"}},
Package () {"gpios", Package () {^LEDS, 1, 0, 0}},
Package () {"linux,default-trigger", Package () {"mmc0"}},
Package () {"linux,default-state", "off"},
Package () {"linux,retain-state-suspended", 1},
}
})
[PATCH 2/6] ACPI / property: Add support for data-only subnodes
From: Rafael J. Wysocki
In some cases, the information expressed via device properties is
hierarchical by nature. For example, the properties of a composite
device consisting of multiple semi-dependent components may need
to be represented in the form of a tree of property data sets
corresponding to specific components of the device.
Unfortunately, using ACPI device objects for this purpose turns out
to be problematic, mostly due to the assumption made by some operating
systems (that platform firmware generally needs to work with) that
each device object in the ACPI namespace represents a device requiring
a separate driver. That assumption leads to complications which
reportedly are impractically difficult to overcome and a different
approach is needed for the sake of interoperability.
The approach implemented here is based on extending _DSD via pointers
(links) to additional ACPI objects returning data packages formatted
in accordance with the _DSD formatting rules defined by Section 6.2.5
of ACPI 6. Those additional objects are referred to as data-only
subnodes of the device object containing the _DSD pointing to them.
The links to them need to be located in a separate section of the
_DSD data package following UUID dbb8e3e6-5886-4ba6-8795-1319f52a966b
referred to as the Hierarchical Data Extension UUID as defined in [1].
Each of them is represented by a package of two strings. The first
string in that package (the key) is regarded as the name of the
data-only subnode pointed to by the link. The second string in it
(the target) is expected to hold the ACPI namespace path (possibly
utilizing the usual ACPI namespace search rules) of an ACPI object
evaluating to a data package extending the _DSD.
The device properties initialization code follows those links,
creates a struct acpi_data_node object for each of them to store
the data returned by the ACPI object pointed to by it and processes
those data recursively (which may lead to the creation of more
struct acpi_data_node objects if the returned data package contains
the Hierarchical Data Extension UUID section with more links in it).
All of the struct acpi_data_node objects are present until the the
ACPI device object containing the _DSD with links to them is deleted
and they are deleted along with that object.
[1]:
http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.pdf
Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg
---
drivers/acpi/property.c | 133 +++-
include/acpi/acpi_bus.h |9 +++
include/linux/fwnode.h |1
3 files changed, 142 insertions(+), 1 deletion(-)
Index: linux-pm/include/acpi/acpi_bus.h
===
--- linux-pm.orig/include/acpi/acpi_bus.h
+++ linux-pm/include/acpi/acpi_bus.h
@@ -343,6 +343,7 @@ struct acpi_device_data {
const union acpi_object *pointer;
const union acpi_object *properties;
const union acpi_object *of_compatible;
+ struct list_head subnodes;
};
struct acpi_gpio_mapping;
@@ -378,6 +379,14 @@ struct acpi_device {
void (*remove)(struct acpi_device *);
};
+/* Non-device subnode */
+struct acpi_data_node {
+ const char *name;
+ struct fwnode_handle fwnode;
+ struct acpi_device_data data;
+ struct list_head sibling;
+};
+
static inline bool acpi_check_dma(struct acpi_device *adev, bool *coherent)
{
bool ret = false;
Index: linux-pm/include/linux/fwnode.h
===
--- linux-pm.orig/include/linux/fwnode.h
+++ linux-pm/include/linux/fwnode.h
@@ -16,6 +16,7 @@ enum fwnode_type {
FWNODE_INVALID = 0,
FWNODE_OF,
FWNODE_ACPI,
+ FWNODE_ACPI_DATA,
FWNODE_PDATA,
};
Index: linux-pm/drivers/acpi/property.c
===
--- linux-pm.orig/drivers/acpi/property.c
+++ linux-pm/drivers/acpi/property.c
@@ -24,6 +24,115 @@ static const u8 prp_uuid[16] = {
0x14, 0xd8, 0xff, 0xda, 0xba, 0x6e, 0x8c, 0x4d,
0x8a, 0x91, 0xbc, 0x9b, 0xbf, 0x4a, 0xa3, 0x01
};
+/* ACPI _DSD data subnodes UUID: dbb8e3e6-5886-4ba6-8795-1319f52a966b */
+static const u8 ads_uuid[16] = {
+ 0xe6, 0xe3, 0xb8, 0xdb, 0x86, 0x58, 0xa6, 0x4b,
+ 0x87, 0x95, 0x13, 0x19, 0xf5, 0x2a, 0x96, 0x6b
+};
+
+static bool acpi_enumerate_nondev_subnodes(acpi_handle scope,
+ const union acpi_object *desc,
+ struct acpi_device_data *data);
+static bool acpi_extract_properties(const union acpi_object *desc,
+ struct acpi_device_data *data);
+
+static bool acpi_nondev_subnode_ok(acpi_handle scope,
+ const union acpi_object *link,
+ struct list_head *list)
+{
+ struct acpi_buffer
Re: [PATCH v2 6/8] zram: change zcomp_compress interface
On (08/20/15 15:35), Joonsoo Kim wrote:
> zram regards zstrm's buffer as compression destination buffer, but,
> it is not intuitive and there is no document about it. Providing
> destination buffer to zcomp_compress() directly seems more intuitive
> interface to me so this patch changes zcomp_compress interface.
>
> Signed-off-by: Joonsoo Kim
> ---
> drivers/block/zram/zcomp.c| 5 ++---
> drivers/block/zram/zcomp.h| 2 +-
> drivers/block/zram/zram_drv.c | 2 +-
> 3 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
> index 965d1af..2ad504b 100644
> --- a/drivers/block/zram/zcomp.c
> +++ b/drivers/block/zram/zcomp.c
> @@ -307,10 +307,9 @@ void zcomp_strm_release(struct zcomp *comp, struct
> zcomp_strm *zstrm)
> }
>
> int zcomp_compress(struct zcomp *comp, struct zcomp_strm *zstrm,
> - const unsigned char *src, size_t *dst_len)
> + const unsigned char *src, unsigned char *dst, size_t *dst_len)
> {
> - return comp->backend->compress(src, zstrm->buffer, dst_len,
> - zstrm->private);
> + return comp->backend->compress(src, dst, dst_len, zstrm->private);
> }
>
> int zcomp_decompress(struct zcomp *comp, const unsigned char *src,
> diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
> index 46e2b9f..b2388e0 100644
> --- a/drivers/block/zram/zcomp.h
> +++ b/drivers/block/zram/zcomp.h
> @@ -60,7 +60,7 @@ struct zcomp_strm *zcomp_strm_find(struct zcomp *comp);
> void zcomp_strm_release(struct zcomp *comp, struct zcomp_strm *zstrm);
>
> int zcomp_compress(struct zcomp *comp, struct zcomp_strm *zstrm,
> - const unsigned char *src, size_t *dst_len);
> + const unsigned char *src, unsigned char *dst, size_t *dst_len);
>
> int zcomp_decompress(struct zcomp *comp, const unsigned char *src,
> size_t src_len, unsigned char *dst);
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index b088ca9..4801e4d 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -701,7 +701,7 @@ static int zram_bvec_write(struct zram *zram, struct
> bio_vec *bvec, u32 index,
> goto out;
> }
>
> - ret = zcomp_compress(zram->comp, zstrm, uncmem, );
> + ret = zcomp_compress(zram->comp, zstrm, uncmem, zstrm->buffer, );
No, this change is unreasonable. zcomp might want to do with zstrm
anything it wants to, because zstrm belongs there. Besides, you change
zcomp_decompress() to require `struct zcomp_strm *zstrm', so let's
stick with this -- pass `struct zcomp_strm *zstrm' to both compress and
decompress functions. It's up to zcomp to ignore passed zstrm or do
something sane; not up to zram_drv.
-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] mpt3sas: Refcount fw_events and fix unsafe list usage
On Wednesday 08/26 at 04:09 +, Nicholas A. Bellinger wrote: > From: Nicholas Bellinger > > The fw_event_work struct is concurrently referenced at shutdown, so > add a refcount to protect it, and refactor the code to use it. > > Additionally, refactor _scsih_fw_event_cleanup_queue() such that it > no longer iterates over the list without holding the lock, since > _firmware_event_work() concurrently deletes items from the list. > > This patch is a port of Calvin's PATCH-v4 for mpt2sas code. > > Cc: Calvin Owens > Cc: Christoph Hellwig > Cc: Sreekanth Reddy > Cc: MPT-FusionLinux.pdl > Signed-off-by: Nicholas Bellinger > --- > drivers/scsi/mpt3sas/mpt3sas_scsih.c | 116 > --- > 1 file changed, 94 insertions(+), 22 deletions(-) Looks good, thanks again for this. Reviewed-by: Calvin Owens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4] thermal: cpu_cooling: Add MAINTAINERS entry
None of the patches are reaching Viresh or Daniel directly as get_maintainers doesn't report us as maintainers. Looks like file header or history of commits isn't able to do that properly. Add a separate entry for cpu_cooling driver in MAINTAINERS. Acked-by: Eduardo Valentin Acked-by: Amit Daniel Kachhap Acked-by: Amit Daniel Kachhap Signed-off-by: Viresh Kumar --- V4: Adding Javi as well into maintainers. MAINTAINERS | 10 ++ 1 file changed, 10 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 5d8ab5c06c4f..12a47b8ad140 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10298,6 +10298,16 @@ F: include/uapi/linux/thermal.h F: include/linux/cpu_cooling.h F: Documentation/devicetree/bindings/thermal/ +THERMAL/CPU_COOLING +M: Amit Daniel Kachhap +M: Viresh Kumar +M: Javi Merino +L: linux...@vger.kernel.org +S: Supported +F: Documentation/thermal/cpu-cooling-api.txt +F: drivers/thermal/cpu_cooling.c +F: include/linux/cpu_cooling.h + THINGM BLINK(1) USB RGB LED DRIVER M: Vivien Didelot S: Maintained -- 2.4.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [RFC] security: smack: Add support automatic Smack labeling
Smack labeling is always done in user space, not in kernel space. Because kernel can't know which node or preocess should has the certain label and it shouldn't be neither. Therefore there is a distinct time gap between file creation and the labeling which might be about few miliseconds or even indefinite period. This unavoidable and imprecise time gap produces unintended Smack denial time to time. If it guerantees that labeling is done before any other access, the time gap doesn't make matter. However if not, the system will suffer from false alarm. I've already exeperienced the situation with specific cases. Mostly, it happens with devtmpfs where udevd applies xattr with defined udev rules. When kernel module is loaded, device node is newly created and it sends uevent and notification to processes in wait. However, somtimes uevent may be handled lately then other processes's access. So, Smack module checks the authority with uninitialized label, and prohibits the access even the access authority exists in Smack rule. At the first time of encounting the problem, I tries to fix the system and user process to prevent the accesses in ahead of labeling but it wasn't the solution. Performance is degraded because of compulsory delay. Another candidate of solution is given label from kernel side. However, kernel should not be aware of the label, the string, and the relationship between specific node and label. So I left it in user space. Label is still given from user space. Kernel only checks there is a pre-assigned labeling rule for the node. If so, the file will acquire the label as default at the creation. A file is created with pre-assigend label as like it's done automatically. So it's called 'Auto Smack labeling' Pre-assigned label can be given via additional file, 'autolabel' in smackfs. echo ' ' > /sys/fs/smackfs/autolabel The label only activates when the file isn't created yet. If file already exists, then just add the label relationship to table and deactivate it. When the label is applied, it'll also be deactivated. The label turns to be enabled again only when the file is removed. This is a candidate of solution for the specific problem, and might be buggy or hamful for system-wide security. So I gently request your opinion for more clear and wise solution for the case that I faced. Jonghwa Lee (1): security: smack: Add support automatic Smack labeling security/smack/Kconfig | 11 security/smack/smack.h | 23 security/smack/smack_lsm.c | 66 + security/smack/smackfs.c | 136 4 files changed, 236 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] security: smack: Add support automatic Smack labeling
Current Smack object's label is always given by userspace.
So there might be a certain gap between the time of file creation
and the time of applying actual label. And because of the time gap,
it results unintended Smack denial time to time.
If accessing a file occurs ahead of labeling, Smack module will check
the authority with uninitialized label and will prohibit the access
as a result. It shouldn't be happened labeling is done in proper time.
For the case that system can't gueratee that Smack labeling is done
before any other accesses to newly created file, this patch introdues
new interface called 'Automatic Smack labling'.
The label can be defined before file creation with absolute path.
Then, when target file is created in generic manner, the pre-defined
label is applied automatically at once.
Pre-defined label format follows below form.
And it can add new entry to autolabel table via 'autolabel' in smackfs.
echo ' ' > /sys/fs/smackfs/autolabel
To view entries of autolabel table,
$cat /sys/fs/smackfs/autolabel
/dev/device00 Label:A
/run/userfile0 Label:B
Signed-off-by: Jonghwa Lee
---
security/smack/Kconfig | 11
security/smack/smack.h | 23
security/smack/smack_lsm.c | 66 +
security/smack/smackfs.c | 136
4 files changed, 236 insertions(+)
diff --git a/security/smack/Kconfig b/security/smack/Kconfig
index 271adae..002aa01 100644
--- a/security/smack/Kconfig
+++ b/security/smack/Kconfig
@@ -30,6 +30,17 @@ config SECURITY_SMACK_BRINGUP
"permissive" mode of other systems.
If you are unsure how to answer this question, answer N.
+config SECURITY_SMACK_AUTOLABEL
+ bool "Enable Automatic Smack Labeling"
+ depends on SECURITY_SMACK
+ default n
+ help
+ To remove out the gap between file creation and actual labeling,
+ this option gives the additional interface for automatic labeling.
+ With this option enabled, a file will posseses the assigned label
+ in autolabel table at creation.
+ If you are unsure how to answer this question, answer N.
+
config SECURITY_SMACK_NETFILTER
bool "Packet marking using secmarks for netfilter"
depends on SECURITY_SMACK
diff --git a/security/smack/smack.h b/security/smack/smack.h
index fff0c61..8b7ee83 100644
--- a/security/smack/smack.h
+++ b/security/smack/smack.h
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
/*
* Use IPv6 port labeling if IPv6 is enabled and secmarks
@@ -106,6 +107,9 @@ struct inode_smack {
struct smack_known *smk_inode; /* label of the fso */
struct smack_known *smk_task; /* label of the task */
struct smack_known *smk_mmap; /* label of the mmap domain */
+#ifdef CONFIG_SECURITY_SMACK_AUTOLABEL
+ struct smack_auto_label *smk_auto;
+#endif
struct mutexsmk_lock; /* initialization lock */
int smk_flags; /* smack inode flags */
};
@@ -480,4 +484,23 @@ static inline void smk_ad_setfield_u_net_sk(struct
smk_audit_info *a,
}
#endif
+#ifdef CONFIG_SECURITY_SMACK_AUTOLABEL
+struct smack_auto_label {
+ bool disabled;
+ char *fpath;
+ struct list_head entry;
+ struct smack_known *label;
+ struct inode *inode;
+};
+
+extern struct list_head smack_autolabel_list;
+extern struct mutex smack_autolabel_lock;
+
+extern struct smack_known *smk_inode_bind_autolabel(struct inode *);
+extern void smk_inode_unbind_autolabel(struct inode *);
+#else
+#define smk_inode_bind_autolabel(inode)NULL
+#define smk_inode_unbind_autolabel(inode) do { } while (0)
+#endif /* CONFIG_SECURITY_SMACK_AUTOLABEL */
+
#endif /* _SECURITY_SMACK_H */
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 996c889..851e8b4 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -249,6 +249,65 @@ static int smk_bu_credfile(const struct cred *cred, struct
file *file,
#define smk_bu_credfile(cred, file, mode, RC) (RC)
#endif
+#ifdef CONFIG_SECURITY_SMACK_AUTOLABEL
+/**
+ * smk_inode_bind_autolabel - Check assigned label for this inode
+ * @ip : the object of inode
+ *
+ * Return pre-assigned smack_known when exists, NULL if not.
+ */
+struct smack_known *smk_inode_bind_autolabel(struct inode *ip)
+{
+ struct smack_auto_label *smk_auto;
+ struct inode_smack *isp;
+ struct smack_known *smk = NULL;
+ struct path p;
+
+ if (list_empty(_autolabel_list))
+ goto out;
+
+ mutex_lock(_autolabel_lock);
+ list_for_each_entry(smk_auto, _autolabel_list, entry) {
+ if (smk_auto->disabled)
+ continue;
+
+ if (!smk_auto->inode) {
+ if (kern_path(smk_auto->fpath, 0, ))
+ continue;
+
Re: [PATCH v2 4/8] crypto/lz4hc: support decompress_noctx
On (08/20/15 15:35), Joonsoo Kim wrote:
>
> lz4hc's decompression doesn't requires any scratch buffer so
> it doesn't need tfm context. Hence, it can support
> crypto compression noctx API and this patch implements it.
>
> Signed-off-by: Joonsoo Kim
> ---
> crypto/lz4hc.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/crypto/lz4hc.c b/crypto/lz4hc.c
> index bcf0baa..a529620 100644
> --- a/crypto/lz4hc.c
> +++ b/crypto/lz4hc.c
> @@ -76,6 +76,21 @@ static int lz4hc_decompress_crypto(struct crypto_tfm *tfm,
> const u8 *src,
> return err;
> }
>
> +static int lz4hc_decompress_noctx(const u8 *src, unsigned int slen,
> + u8 *dst, unsigned int *dlen)
> +{
> + int err;
> + size_t tmp_len = *dlen;
> + size_t __slen = slen;
> +
> + err = lz4_decompress_unknownoutputsize(src, __slen, dst, _len);
> + if (err < 0)
> + return -EINVAL;
> +
> + *dlen = tmp_len;
> + return err;
> +}
> +
same,
static int lz4hc_decompress_noctx(const u8 *src, unsigned int slen,
u8 *dst, unsigned int *dlen)
{
return lz4hc_decompress_crypto(NULL, );
}
?
-ss
> static struct crypto_alg alg_lz4hc = {
> .cra_name = "lz4hc",
> .cra_flags = CRYPTO_ALG_TYPE_COMPRESS,
> @@ -88,7 +103,7 @@ static struct crypto_alg alg_lz4hc = {
> .coa_compress = lz4hc_compress_crypto,
> .coa_decompress = lz4hc_decompress_crypto,
> .coa_compress_noctx = NULL,
> - .coa_decompress_noctx = NULL } }
> + .coa_decompress_noctx = lz4hc_decompress_noctx } }
> };
>
> static int __init lz4hc_mod_init(void)
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/2]: acpica/nfit: Rename not-armed bit definition
I don’t have any problem changing this in ACPICA if/when you all agree.
> -Original Message-
> From: Toshi Kani [mailto:toshi.k...@hp.com]
> Sent: Wednesday, August 26, 2015 4:36 PM
> To: Rafael J. Wysocki
> Cc: Williams, Dan J; Wysocki, Rafael J; Moore, Robert; linux-
> nvd...@lists.01.org; Linux ACPI; linux-kernel@vger.kernel.org; Elliott,
> Robert (Server Storage)
> Subject: Re: [PATCH 2/2]: acpica/nfit: Rename not-armed bit definition
>
> On Wed, 2015-08-26 at 17:29 -0600, Toshi Kani wrote:
> > On Thu, 2015-08-27 at 01:16 +0200, Rafael J. Wysocki wrote:
> > > On Wed, Aug 26, 2015 at 11:12 PM, Toshi Kani
> wrote:
> > > > On Wed, 2015-08-26 at 10:16 -0700, Dan Williams wrote:
> > > > > On Wed, Aug 26, 2015 at 9:20 AM, Toshi Kani
> > > > > wrote:
> > > > > > ACPI 6.0 NFIT Memory Device State Flags in Table 5-129 defines
> > > > > > bit 3 as follows.
> > > > > >
> > > > > > Bit [3] set to 1 to indicate that the Memory Device is
> observed
> > > > > > to be not armed prior to OSPM hand off. A Memory Device is
> > > > > > considered armed if it is able to accept persistent writes.
> > > > > >
> > > > > > This bit is currently defined as ACPI_NFIT_MEM_ARMED, which
> > > > > > can be confusing as if the Memory Device is armed when this bit
> is set.
> > > > > >
> > > > > > Change the name to ACPI_NFIT_MEM_NOT_ARMED per the spec.
> > > > > >
> > > > > > Signed-off-by: Toshi Kani
> > > > > > Cc: Dan Williams
> > > > > > Cc: Bob Moore
> > > > > > Cc: Rafael J. Wysocki
> > > > > > ---
> > > > > > drivers/acpi/nfit.c |6 +++---
> > > > > > drivers/acpi/nfit.h |2 +-
> > > > > > include/acpi/actbl1.h|2 +-
> > > > >
> > > > > This file "include/acpi/actbl1.h" is owned by the ACPICA project
> > > > > so any changes need to come through them. But that said, I'm
> > > > > not sure we need friendly names at this level.
> > > >
> > > > I think the name is misleading, but I agree with the process and
> > > > this
> > > > patch2 can be dropped. It'd be nice if the ACPICA project can
> > > > pick it up later when they have a chance, though.
> > >
> > > A good way to cause that to happen would be to send a patch to the
> > > ACPICA development list + maintainers as per MAINTAINERS.
> >
> > Oh, I see. I did run get_maintainer.pl for this patch, but
> > de...@acpica.org did not come out in output... So, I did not realize
> > this email list.
>
> Sorry, it was listed in the output. I was simply blinded... :-(
>
> $ scripts/get_maintainer.pl patches-nd-flags/02*
> :
> linux-nvd...@lists.01.org (open list:LIBNVDIMM BLK: MMIO-APERTURE DRIVER)
> linux-a...@vger.kernel.org (open list:ACPI) linux-kernel@vger.kernel.org
> (open list) de...@acpica.org (open list:ACPI COMPONENT ARCHITECTURE
> (ACPICA))
>
> Thanks!
> -Toshi
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH] thermal: cpu_cooling: Remove usage of devm functions
On Wed, Aug 19, 2015 at 11:52 AM, Vaishali Thakkar
wrote:
> In the function cpufreq_get_requested_power, the memory allocated
> for load_cpu is live within the function only. And after the
> allocation it is immediately freed with devm_kfree. There is no
> need to allocate memory for load_cpu with devm function so replace
> devm_kcalloc with kcalloc and devm_kfree with kfree.
>
> Signed-off-by: Vaishali Thakkar
> ---
> This patch is having one checkpatch.pl warning which suggests that
> kfree(NULL) is safe. But I think leaving code with if is nice
> because it reflects the fact that kcalloc was under an if. So, I
> have ignored checkpatch. If maintainer wants me to go for changing
> things, I am fine with it too.
> ---
> drivers/thermal/cpu_cooling.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 620dcd4..babf8b3 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -584,8 +584,7 @@ static int cpufreq_get_requested_power(struct
> thermal_cooling_device *cdev,
> if (trace_thermal_power_cpu_get_power_enabled()) {
> u32 ncpus = cpumask_weight(_device->allowed_cpus);
>
> - load_cpu = devm_kcalloc(>device, ncpus,
> sizeof(*load_cpu),
> - GFP_KERNEL);
> + load_cpu = kcalloc(ncpus, sizeof(*load_cpu), GFP_KERNEL);
> }
>
> for_each_cpu(cpu, _device->allowed_cpus) {
> @@ -609,7 +608,7 @@ static int cpufreq_get_requested_power(struct
> thermal_cooling_device *cdev,
> ret = get_static_power(cpufreq_device, tz, freq, _power);
> if (ret) {
> if (load_cpu)
> - devm_kfree(>device, load_cpu);
> + kfree(load_cpu);
> return ret;
> }
>
> @@ -618,7 +617,7 @@ static int cpufreq_get_requested_power(struct
> thermal_cooling_device *cdev,
> _device->allowed_cpus,
> freq, load_cpu, i, dynamic_power, static_power);
>
> - devm_kfree(>device, load_cpu);
> + kfree(load_cpu);
> }
>
> *power = static_power + dynamic_power;
Acked-by: Viresh Kumar
@Eduardo: Ignore V2 and apply this one :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/8] crypyo/lz4: support decompress_noctx
On (08/20/15 15:34), Joonsoo Kim wrote:
> lz4's decompression doesn't requires any scratch buffer so
> it doesn't need tfm context. Hence, it can support
> crypto compression noctx API and this patch implements it.
>
> Signed-off-by: Joonsoo Kim
> ---
> crypto/lz4.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/crypto/lz4.c b/crypto/lz4.c
> index 1848435..aa23da3 100644
> --- a/crypto/lz4.c
> +++ b/crypto/lz4.c
> @@ -76,6 +76,21 @@ static int lz4_decompress_crypto(struct crypto_tfm *tfm,
> const u8 *src,
> return err;
> }
>
> +static int lz4_decompress_noctx(const u8 *src, unsigned int slen,
> + u8 *dst, unsigned int *dlen)
> +{
> + int err;
> + size_t tmp_len = *dlen;
> + size_t __slen = slen;
> +
> + err = lz4_decompress_unknownoutputsize(src, __slen, dst, _len);
> + if (err < 0)
> + return -EINVAL;
> +
> + *dlen = tmp_len;
> + return err;
> +}
> +
same,
static int lz4_decompress_noctx(const u8 *src, unsigned int slen,
u8 *dst, unsigned int *dlen)
{
return lz4_decompress_crypto(NULL, );
}
?
> static struct crypto_alg alg_lz4 = {
> .cra_name = "lz4",
> .cra_flags = CRYPTO_ALG_TYPE_COMPRESS,
> @@ -88,7 +103,7 @@ static struct crypto_alg alg_lz4 = {
> .coa_compress = lz4_compress_crypto,
> .coa_decompress = lz4_decompress_crypto,
> .coa_compress_noctx = NULL,
> - .coa_decompress_noctx = NULL } }
> + .coa_decompress_noctx = lz4_decompress_noctx } }
> };
>
> static int __init lz4_mod_init(void)
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/8] crypto/lzo: support decompress_noctx
On (08/20/15 15:34), Joonsoo Kim wrote:
> lzo's decompression doesn't requires any scratch buffer so
> it doesn't need tfm context. Hence, it can support
> crypto compression noctx API and this patch implements it.
>
> Signed-off-by: Joonsoo Kim
> ---
> crypto/lzo.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/crypto/lzo.c b/crypto/lzo.c
> index 9ca516b..f1844dd 100644
> --- a/crypto/lzo.c
> +++ b/crypto/lzo.c
> @@ -80,6 +80,22 @@ static int lzo_decompress(struct crypto_tfm *tfm, const u8
> *src,
>
> }
>
> +static int lzo_decompress_noctx(const u8 *src, unsigned int slen,
> + u8 *dst, unsigned int *dlen)
> +{
> + int err;
> + size_t tmp_len = *dlen; /* size_t(ulong) <-> uint on 64 bit */
> +
> + err = lzo1x_decompress_safe(src, slen, dst, _len);
> +
> + if (err != LZO_E_OK)
> + return -EINVAL;
> +
> + *dlen = tmp_len;
> + return 0;
> +
just do
static int lzo_decompress_noctx(const u8 *src, unsigned int slen,
u8 *dst, unsigned int *dlen)
{
return lzo_decompress(NULL, src, len, dst, dlen);
}
?
-ss
> +}
> +
> static struct crypto_alg alg = {
> .cra_name = "lzo",
> .cra_flags = CRYPTO_ALG_TYPE_COMPRESS,
> @@ -91,7 +107,7 @@ static struct crypto_alg alg = {
> .coa_compress = lzo_compress,
> .coa_decompress = lzo_decompress,
> .coa_compress_noctx = NULL,
> - .coa_decompress_noctx = NULL } }
> + .coa_decompress_noctx = lzo_decompress_noctx } }
> };
>
> static int __init lzo_mod_init(void)
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Problems loading firmware using built-in drivers with kernels that use initramfs.
> -Original Message-
> From: Liam Girdwood [mailto:liam.r.girdw...@linux.intel.com]
> Sent: Wednesday, August 26, 2015 5:01 PM
> To: Jie, Yang
> Cc: Takashi Iwai; Dmitry Torokhov; Luis R. Rodriguez;
> joonas.lahti...@linux.intel.com; Tom Gundersen; Ming Lei; Al Viro; Greg
> Kroah-Hartman; Kay Sievers; Linus Torvalds; David Woodhouse; Luis Rodriguez;
> lkml; yalin wang; Lin, Mengdong
> Subject: Re: Problems loading firmware using built-in drivers with kernels
> that
> use initramfs.
>
> On Wed, 2015-08-26 at 08:29 +, Jie, Yang wrote:
> > > -Original Message-
> > > From: Liam Girdwood [mailto:liam.r.girdw...@linux.intel.com]
>
> > > I think the options are to either :-
> > >
> > > 1) Don not support audio DSP drivers using topology data as built-in
> drivers.
> > > Audio is not really a critical system required for booting anyway.
> > >
> > > 2) Create a default PCM for every driver that has topology data on
> > > the assumption that every sound card will at least 1 PCM. This PCM
> > > can then be re-configured when the FW is loaded.
> >
> > Yep, this case is quite similar with what Linus described.
> >
> > Is it possible that we can probe pcm device after firmware is loaded
> > for this case?
> >
>
> The PCM devices are defined in the topology data so it is only possible to
> create the PCM device *after* the firmware is loaded in these drivers.
>
> Liam
It seems this can prevent audio device driver in built-in mode to use topology
drivers.
If topology is present, the vendor driver also uses request_firmware() to load
the topology data file in the probe phase. Then ASoC core will create the sound
card and its PCM devices.
Shall we force the device drivers that depends on topology to be configured as
modules?
Thanks
Mengdong
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH v2][RESEND] perf, x86: Fix multi-segment problem of perf_event_intel_uncore
In multi-segment system, uncore devices may belong to buses whose segment
number is other than 0.
:ff:10.5 System peripheral: Intel Corporation Xeon E5 v3/Core i7
Scratchpad & Semaphore Registers (rev 03)
...
0001:7f:10.5 System peripheral: Intel Corporation Xeon E5 v3/Core i7
Scratchpad & Semaphore Registers (rev 03)
...
0001:bf:10.5 System peripheral: Intel Corporation Xeon E5 v3/Core i7
Scratchpad & Semaphore Registers (rev 03)
...
0001:ff:10.5 System peripheral: Intel Corporation Xeon E5 v3/Core i7
Scratchpad & Semaphore Registers (rev 03
...
In that case relation of bus number and physical id may be broken
because "uncore_pcibus_to_physid" doesn't take account of PCI segment.
For example, bus :ff and 0001:ff uses the same entry of
"uncore_pcibus_to_physid" array.
This patch fixes ths problem by introducing segment-aware pci2phy_map instead.
v1 -> v2:
- Extract method named uncore_pcibus_to_physid to avoid repetetion of
retrieving phys_id code
Signed-off-by: Taku Izumi
---
arch/x86/kernel/cpu/perf_event_intel_uncore.c | 25 --
arch/x86/kernel/cpu/perf_event_intel_uncore.h | 11 -
arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c | 23 +-
.../x86/kernel/cpu/perf_event_intel_uncore_snbep.c | 53 --
4 files changed, 94 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
index 21b5e38..0ed6f2b 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
@@ -7,7 +7,8 @@ struct intel_uncore_type **uncore_pci_uncores = empty_uncore;
static bool pcidrv_registered;
struct pci_driver *uncore_pci_driver;
/* pci bus to socket mapping */
-int uncore_pcibus_to_physid[256] = { [0 ... 255] = -1, };
+DEFINE_RAW_SPINLOCK(pci2phy_map_lock);
+struct list_head pci2phy_map_head = LIST_HEAD_INIT(pci2phy_map_head);
struct pci_dev
*uncore_extra_pci_dev[UNCORE_SOCKET_MAX][UNCORE_EXTRA_PCI_DEV_MAX];
static DEFINE_RAW_SPINLOCK(uncore_box_lock);
@@ -20,6 +21,23 @@ static struct event_constraint uncore_constraint_fixed =
struct event_constraint uncore_constraint_empty =
EVENT_CONSTRAINT(0, 0, 0);
+int uncore_pcibus_to_physid(struct pci_bus *bus)
+{
+ int phys_id = -1;
+ struct pci2phy_map *map;
+
+ raw_spin_lock(_map_lock);
+ list_for_each_entry(map, _map_head, list) {
+ if (map->segment == pci_domain_nr(bus)) {
+ phys_id = map->pbus_to_physid[bus->number];
+ break;
+ }
+ }
+ raw_spin_unlock(_map_lock);
+
+ return phys_id;
+}
+
ssize_t uncore_event_show(struct kobject *kobj,
struct kobj_attribute *attr, char *buf)
{
@@ -809,7 +827,7 @@ static int uncore_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *id
int phys_id;
bool first_box = false;
- phys_id = uncore_pcibus_to_physid[pdev->bus->number];
+ phys_id = uncore_pcibus_to_physid(pdev->bus);
if (phys_id < 0)
return -ENODEV;
@@ -856,9 +874,10 @@ static void uncore_pci_remove(struct pci_dev *pdev)
{
struct intel_uncore_box *box = pci_get_drvdata(pdev);
struct intel_uncore_pmu *pmu;
- int i, cpu, phys_id = uncore_pcibus_to_physid[pdev->bus->number];
+ int i, cpu, phys_id;
bool last_box = false;
+ phys_id = uncore_pcibus_to_physid(pdev->bus);
box = pci_get_drvdata(pdev);
if (!box) {
for (i = 0; i < UNCORE_EXTRA_PCI_DEV_MAX; i++) {
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.h
b/arch/x86/kernel/cpu/perf_event_intel_uncore.h
index 0f77f0a..6c96ee9 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore.h
+++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.h
@@ -117,6 +117,14 @@ struct uncore_event_desc {
const char *config;
};
+struct pci2phy_map {
+ struct list_head list;
+ int segment;
+ int pbus_to_physid[256];
+};
+
+int uncore_pcibus_to_physid(struct pci_bus *bus);
+
ssize_t uncore_event_show(struct kobject *kobj,
struct kobj_attribute *attr, char *buf);
@@ -317,7 +325,8 @@ u64 uncore_shared_reg_config(struct intel_uncore_box *box,
int idx);
extern struct intel_uncore_type **uncore_msr_uncores;
extern struct intel_uncore_type **uncore_pci_uncores;
extern struct pci_driver *uncore_pci_driver;
-extern int uncore_pcibus_to_physid[256];
+extern raw_spinlock_t pci2phy_map_lock;
+extern struct list_head pci2phy_map_head;
extern struct pci_dev
*uncore_extra_pci_dev[UNCORE_SOCKET_MAX][UNCORE_EXTRA_PCI_DEV_MAX];
extern struct event_constraint uncore_constraint_empty;
diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c
b/arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c
index b005a78..ccbc817 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_uncore_snb.c
+++
Re: [PATCH v2] Makefile: Fix detection of clang when cross-compiling
On 08/19/15 08:41, Michal Marek wrote:
On Mon, Jul 13, 2015 at 08:59:33PM +1000, Anton Blanchard wrote:
Hi,
> When the host's C compiler is clang, and when attempting to
> cross-compile Linux e.g. to MIPS with mipsel-linux-gcc, the
> Makefile would incorrectly detect the use of clang, which
> resulted in clang-specific flags being passed to
> mipsel-linux-gcc.
>
> This can be verified under Debian by installing the "clang"
> package, and then using it as the default compiler with:
> sudo update-alternatives --config cc
>
> This patch moves the detection of clang after the $(CC)
> variable is initialized to the name of the cross-compiler, so
> that the check applies
> to the cross-compiler and not the host's C compiler.
>
> v2: Move the detection of clang after the inclusion of the
> arch/*/Makefile (as they might set $(CROSS_COMPILE))
>
> Signed-off-by: Paul Cercueil mailto:p...@crapouillou.net>>
Applied to kbuild.git#kbuild. I will push it after v4.1-rc1
becomes available, though.
Drat. I wish I saw this earlier.
This breaks patches which check for the value of COMPILER in
arch/*/Makefile. This detection must be performed before the
inclusion of the arch Makefile.
Can I move this to after the initialization of CC but before the
include?
I'm not sure that being able to define the default compiler per arch
is necessary. But I know I need to be able to add arch specific flags
for clang.
I can confirm the patch breaks ppc64le clang builds.
Can you try the (untested) patch below?
From 49bb3e66a9a7fc3685fb070bdfd31f2c3d78cc87 Mon Sep 17 00:00:00 2001
From: Michal Marek
Date: Wed, 19 Aug 2015 17:36:41 +0200
Subject: [PATCH] kbuild: Fix clang detection
We cannot detect clang before including the arch Makefile, because that
can set the default cross compiler. We also cannot detect clang after
including the arch Makefile, because powerpc wants to know about clang.
Solve this by using an deferred variable. This costs us a few shell
invocations, but this is only a constant number.
Reported-by: Behan Webster
Reported-by: Anton Blanchard
Signed-off-by: Michal Marek
---
Makefile | 9 +
arch/powerpc/Makefile | 8
scripts/Kbuild.include | 4
scripts/Makefile.extrawarn | 2 +-
4 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/Makefile b/Makefile
index 13270c0..5ccbb58 100644
--- a/Makefile
+++ b/Makefile
@@ -661,14 +661,7 @@ endif
endif
KBUILD_CFLAGS += $(stackp-flag)
-ifeq ($(shell $(CC) -v 2>&1 | grep -c "clang version"), 1)
-COMPILER := clang
-else
-COMPILER := gcc
-endif
-export COMPILER
-
-ifeq ($(COMPILER),clang)
+ifeq ($(cc-name),clang)
KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,)
KBUILD_CPPFLAGS += $(call cc-option,-Wno-unknown-warning-option,)
KBUILD_CFLAGS += $(call cc-disable-warning, unused-variable)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 05f464e..dfe88896 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -67,7 +67,7 @@ UTS_MACHINE := $(OLDARCH)
ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
override CC += -mlittle-endian
-ifneq ($(COMPILER),clang)
+ifneq ($(cc-name),clang)
override CC += -mno-strict-align
endif
override AS += -mlittle-endian
@@ -333,7 +333,7 @@ TOUT:= .tmp_gas_check
# - Require gcc 4.0 or above on 64-bit
# - gcc-4.2.0 has issues compiling modules on 64-bit
checkbin:
- @if test "${COMPILER}" != "clang" \
+ @if test "$(cc-name)" != "clang" \
&& test "$(cc-version)" = "0304" ; then \
if ! /bin/echo mftb 5 | $(AS) -v -mppc -many -o $(TOUT) >/dev/null
2>&1 ; then \
echo -n '*** ${VERSION}.${PATCHLEVEL} kernels no longer
build '; \
@@ -342,14 +342,14 @@ checkbin:
false; \
fi ; \
fi
- @if test "${COMPILER}" != "clang" \
+ @if test "$(cc-name)" != "clang" \
&& test "$(cc-version)" -lt "0400" \
&& test "x${CONFIG_PPC64}" = "xy" ; then \
echo -n "Sorry, GCC v4.0 or above is required to build " ; \
echo "the 64-bit powerpc kernel." ; \
false ; \
fi
- @if test "${COMPILER}" != "clang" \
+ @if test "$(cc-name)" != "clang" \
&& test "$(cc-fullversion)" = "040200" \
&& test "x${CONFIG_MODULES}${CONFIG_PPC64}" = "xyy" ; then \
echo -n '*** GCC-4.2.0 cannot compile the 64-bit powerpc ' ; \
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index d3437b8..3523df6 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -128,6 +128,10 @@ cc-option-align = $(subst -functions=0,,\
cc-disable-warning = $(call try-run,\
$(CC) $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) -W$(strip $(1)) -c -x c /dev/null -o
"$$TMP",-Wno-$(strip
Seccomp questions for updates to seccomp(2) man page
Hello Kees, Will, In recent times I've been asked a couple of questions about seccomp(), and it seems like it would be worthwhile to include these topics in the seccomp(2) man page. Would you be able to help out with some answers? === Use of the instruction pointer in seccomp filters === The seccomp_data describing the system call includes the process's instruction pointer value. What use can be made of this information? My best guess is that you can use this information in conjunction with /proc/PID/maps to introspect the process layout and thus construct filters that conditionally operate based on which DSO is performing a system call. Is that a reasonable use case? Are there others? === Chained seccomp filters and SECCOMP_RET_KILL === The man page describes the behavior when multiple filter are installed If multiple filters exist, they are all executed, in reverse order of their addition to the filter tree (i.e., the most recently installed filter is executed first). The return value for the evaluation of a given system call is the first-seen SECCOMP_RET_ACTION value of highest precedence (along with its accompanying data) returned by execution of all of the filters. The question is: suppose one of the early filters returns SECCOMP_RET_KILL (which is the highest priority action), what is the purpose of executing the remaining filters. My best guess is that this about preventing the user from discovering which filter rule causes the sandboxed program to fail. Is this correct, or is there another reason? Thanks, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND V2 3/7] scsi: storvsc: Untangle the storage protocol negotiation from the vmbus protocol negotiation.
On Thu, 2015-08-13 at 08:43 -0700, K. Y. Srinivasan wrote:
> From: Keith Mange
>
> Currently we are making decisions based on vmbus protocol versions
> that have been negotiated; use storage potocol versions instead.
>
> Tested-by: Alex Ng
> Signed-off-by: Keith Mange
> Signed-off-by: K. Y. Srinivasan
> ---
> drivers/scsi/storvsc_drv.c | 109
> +++-
> 1 files changed, 87 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index 5f9d133..f29871e 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -56,14 +56,18 @@
> * V1 RC > 2008/1/31: 2.0
> * Win7: 4.2
> * Win8: 5.1
> + * Win8.1: 6.0
> + * Win10: 6.2
> */
>
> #define VMSTOR_PROTO_VERSION(MAJOR_, MINOR_) MAJOR_) & 0xff) << 8) | \
> (((MINOR_) & 0xff)))
>
> +#define VMSTOR_PROTO_VERSION_WIN6VMSTOR_PROTO_VERSION(2, 0)
> #define VMSTOR_PROTO_VERSION_WIN7VMSTOR_PROTO_VERSION(4, 2)
> #define VMSTOR_PROTO_VERSION_WIN8VMSTOR_PROTO_VERSION(5, 1)
> -
> +#define VMSTOR_PROTO_VERSION_WIN8_1 VMSTOR_PROTO_VERSION(6, 0)
> +#define VMSTOR_PROTO_VERSION_WIN10 VMSTOR_PROTO_VERSION(6, 2)
>
> /* Packet structure describing virtual storage requests. */
> enum vstor_packet_operation {
> @@ -205,6 +209,46 @@ struct vmscsi_request {
>
>
> /*
> + * The list of storage protocols in order of preference.
> + */
> +struct vmstor_protocol {
> + int protocol_version;
> + int sense_buffer_size;
> + int vmscsi_size_delta;
> +};
> +
> +#define VMSTOR_NUM_PROTOCOLS5
> +
> +const struct vmstor_protocol vmstor_protocols[VMSTOR_NUM_PROTOCOLS] = {
Sparse doesn't like this not being static:
CHECK drivers/scsi/storvsc_drv.c
drivers/scsi/storvsc_drv.c:221:30: warning: symbol 'vmstor_protocols'
was not declared. Should it be static?
I fixed it up.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 7/7] ipmi/kcs: Don't run the KCS state machine when it is KCS_IDLE
> From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey Minyard > > On 08/24/2015 10:53 PM, 河合英宏 / KAWAI，HIDEHIRO wrote: > >> From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey Minyard > >> > >> On 08/23/2015 08:52 PM, 河合英宏 / KAWAI，HIDEHIRO wrote: > From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey > Minyard > > On 08/17/2015 09:54 PM, 河合英宏 / KAWAI，HIDEHIRO wrote: > >> From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey > >> Minyard > >> > >> This patch will break ATN handling on the interfaces. So we can't do > >> this. > > I understand. So how about doing like this: > > > > /* All states wait for ibf, so just do it here. */ > > - if (!check_ibf(kcs, status, time)) > > + if (kcs->state != KCS_IDLE && !check_ibf(kcs, status, time)) > > return SI_SM_CALL_WITH_DELAY; > > > > I think it is not necessary to wait IBF when the state is IDLE. > > In this way, we can also handle the ATN case. > I think it would be more reliable to go up a level and add a timeout. > >>> It may be so, but we should address this issue separately (at least > >>> I think above solution reasonably solves the issue). > >>> > >>> This issue happens after all queued messages are processed or dropped > >>> by timeout. There is no current message. So what should we set > >>> a timeout against? We can add a timeout into my new flush_messages(), > >>> but that is meaningful only in panic context. That doesn't help > >>> in normal context; we would perform a busy loop of smi_event_handler() > >>> and schedule() in ipmi_thread(). > >> I'm a little confused here. Is the problem that the ATN bit is stuck > >> high? If so, it's going to be really hard to work around this without > >> breaking ATN handling. > > Sorry for my insufficient explanation. I assume the case where > > IBF bit is always 1. I don't know what happens when > > BMC hangs up, but I guess IBF stays in 1 because my server's > > BMC behaves as such while rebooting. > > > Ok, your patch above makes sense, then. IBF is irrelevant when in idle > state, > so ignore it then, and then in your case it will return KCS_IDLE and > cause that > operation to complete. I'm ok with the patch you posted above, I think > it will > work correctly and solve the problem. > > I would like a detailed comment, though, so people (forgetful people > like me :) > can figure out why it is there. Sure. I'll post the revised version with detailed comment and description later including PATCH 6/7. Thanks, Hidehiro Kawai
Re: [PATCH v2] thermal: cpu_cooling: Remove usage of devm functions
On Wed, Aug 26, 2015 at 6:44 PM, Viresh Kumar wrote: > On 26-08-15, 14:09, Javi Merino wrote: >> On Wed, Aug 26, 2015 at 01:51:58PM +0100, Viresh Kumar wrote: >> > On 26-08-15, 13:47, Javi Merino wrote: >> > > I missed this because I wasn't CCed :( Thankfully, I'll be in >> > > MAINTAINERS for this soon. >> > >> > Yeah, I need to resend that patch soon :) >> > >> > > > - devm_kfree(>device, load_cpu); >> > > >> > > This introduces a memory leak. Keep the kfree() here, you can't drop >> > > it. Cheers, >> > > Javi >> > > >> > > > - } >> > > > - >> > > > *power = static_power + dynamic_power; >> > > > return 0; > > So, the change I suggested on V1 removed this as well :) and Vaishali > missed it completely. Yes. I missed the point that kfree was called at 2 places previously. Would you like me to send v3 with changes having just new label with 'goto' at both of these places or you would like to apply v1 of the patch? >> > > > + >> > > > +free: >> > > > + kfree(load_cpu); >> > >> > Wouldn't this make that work ? >> >> Nope, you're not reaching that code path from there. Removing the >> "return 0" would work, but I don't like it, since we would be calling >> kfree() all the time, even when the trace is not enabled. I'd rather >> leave the kfree() where it is. > > Hmm.. > > -- > viresh -- Vaishali -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] timer: Reduce unnecessary sighand lock contention
> I can include your patch in the series and then use boolean for the new
> checking_timer field. However, it looks like this applies on an old
> kernel. For example, the spin_lock field has already been removed from
> the structure.
Apologies; that was 4.1.6. A 4.2-rc8 patch is appended (it's a pretty
trivial merge once you look at it).
> The spinlock call has already been removed from a previous patch. The
> issue now is with contention with the sighand lock.
I'll look some more and try to wrap my head around it.
>> Or is it basically okay if this is massively racey, since process-wide
>> CPU timers are inherently sloppy. A race will just cause an expiration
>> check to be missed, but it will be retried soon anyway.
> Yes, the worst case scenario is that we wait until the next thread to
> come along and handle the next expired timer. However, this "delay"
> already occurs now (for example: a timer can expire right after a thread
> exits check_process_timers()).
Ad is this polled, or is there some non-polled system that will trigger
another call to check_process_timers().
E.g. suppose a process fails to notice that it blew past a CPU time
timeout before blocking. Does anything guarantee that it will get
the timeout signal in finite real time?
>From 95349f9b16c30aea518ce79d72e8e0f0c5d12069 Mon Sep 17 00:00:00 2001
From: George Spelvin
Date: Wed, 26 Aug 2015 19:15:54 +
Subject: [PATCH] timer: Use bool more in kernel/time/posix-cpu-timers.c
This is mostly function return values, for documentation.
One structure field is changed (from int), but alignment
padding precludes any actual space saving.
Signed-off-by: George Spelvin
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 04b5ada4..0cd80f76 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -607,7 +607,7 @@ struct task_cputime_atomic {
/**
* struct thread_group_cputimer - thread group interval timer counts
* @cputime_atomic:atomic thread group interval timers.
- * @running: non-zero when there are timers running and
+ * @running: %true when there are timers running and
* @cputime receives updates.
*
* This structure contains the version of task_cputime, above, that is
@@ -615,7 +615,7 @@ struct task_cputime_atomic {
*/
struct thread_group_cputimer {
struct task_cputime_atomic cputime_atomic;
- int running;
+ bool running;
};
#include
diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c
index 892e3dae..106368c5 100644
--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -113,14 +113,12 @@ static void bump_cpu_timer(struct k_itimer *timer,
*
* @cputime: The struct to compare.
*
- * Checks @cputime to see if all fields are zero. Returns true if all fields
- * are zero, false if any field is nonzero.
+ * Checks @cputime to see if all fields are zero. Returns %true if all fields
+ * are zero, %false if any field is nonzero.
*/
-static inline int task_cputime_zero(const struct task_cputime *cputime)
+static inline bool task_cputime_zero(const struct task_cputime *cputime)
{
- if (!cputime->utime && !cputime->stime && !cputime->sum_exec_runtime)
- return 1;
- return 0;
+ return !cputime->utime && !cputime->stime && !cputime->sum_exec_runtime;
}
static inline unsigned long long prof_ticks(struct task_struct *p)
@@ -249,7 +247,7 @@ void thread_group_cputimer(struct task_struct *tsk, struct
task_cputime *times)
* but barriers are not required because update_gt_cputime()
* can handle concurrent updates.
*/
- WRITE_ONCE(cputimer->running, 1);
+ WRITE_ONCE(cputimer->running, true);
}
sample_cputime_atomic(times, >cputime_atomic);
}
@@ -458,8 +456,9 @@ void posix_cpu_timers_exit_group(struct task_struct *tsk)
cleanup_timers(tsk->signal->cpu_timers);
}
-static inline int expires_gt(cputime_t expires, cputime_t new_exp)
+static inline bool expires_gt(cputime_t expires, cputime_t new_exp)
{
+ /* Could also be written "expires - 1 >= new_exp" */
return expires == 0 || expires > new_exp;
}
@@ -911,7 +910,7 @@ static inline void stop_process_timers(struct signal_struct
*sig)
struct thread_group_cputimer *cputimer = >cputimer;
/* Turn off cputimer->running. This is done without locking. */
- WRITE_ONCE(cputimer->running, 0);
+ WRITE_ONCE(cputimer->running, false);
}
static u32 onecputick;
@@ -1088,20 +1087,20 @@ out:
* @expires: Expiration times, against which @sample will be checked.
*
* Checks @sample against @expires to see if any field of @sample has expired.
- * Returns true if any field of the former is greater than the corresponding
- * field of the latter if the latter field is set. Otherwise returns false.
+ * Returns %true if any field of the former is greater than the
linux-next: manual merge of the slave-dma tree with the pm, mfd and rtc trees
Hi Vinod,
Today's linux-next merge of the slave-dma tree got conflicts in:
drivers/dma/Kconfig
drivers/dma/Makefile
between commit:
667dfed98615 ("dmaengine: add a driver for Intel integrated DMA 64-bit")
from the pm, mfd and rtc trees and commits:
3c21619077be ("dmaengine: sort the Kconfig")
7e97229b3920 ("dmaengine: sort the makefile")
from the slave-dma tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/dma/Kconfig
index bdbbe5bcfb83,7ba2847a5077..
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@@ -131,79 -204,74 +204,82 @@@ config FSL_RAI
the capability to offload memcpy, xor and pq computation
for raid5/6.
- source "drivers/dma/hsu/Kconfig"
-
- config MPC512X_DMA
- tristate "Freescale MPC512x built-in DMA engine support"
- depends on PPC_MPC512x || PPC_MPC831x
++config IDMA64
++ tristate "Intel integrated DMA 64-bit support"
+ select DMA_ENGINE
- ---help---
- Enable support for the Freescale MPC512x built-in DMA engine.
-
- source "drivers/dma/bestcomm/Kconfig"
++ select DMA_VIRTUAL_CHANNELS
++ help
++Enable DMA support for Intel Low Power Subsystem such as found on
++Intel Skylake PCH.
+
- config MV_XOR
- bool "Marvell XOR engine support"
- depends on PLAT_ORION
+ config IMG_MDC_DMA
+ tristate "IMG MDC support"
+ depends on MIPS || COMPILE_TEST
+ depends on MFD_SYSCON
select DMA_ENGINE
- select DMA_ENGINE_RAID
- select ASYNC_TX_ENABLE_CHANNEL_SWITCH
- ---help---
- Enable support for the Marvell XOR engine.
+ select DMA_VIRTUAL_CHANNELS
+ help
+ Enable support for the IMG multi-threaded DMA controller (MDC).
- config MX3_IPU
- bool "MX3x Image Processing Unit support"
+ config IMX_DMA
+ tristate "i.MX DMA support"
depends on ARCH_MXC
select DMA_ENGINE
- default y
help
- If you plan to use the Image Processing unit in the i.MX3x, say
- Y here. If unsure, select Y.
+ Support the i.MX DMA engine. This engine is integrated into
+ Freescale i.MX1/21/27 chips.
- config MX3_IPU_IRQS
- int "Number of dynamically mapped interrupts for IPU"
- depends on MX3_IPU
- range 2 137
- default 4
+ config IMX_SDMA
+ tristate "i.MX SDMA support"
+ depends on ARCH_MXC
+ select DMA_ENGINE
help
- Out of 137 interrupt sources on i.MX31 IPU only very few are used.
- To avoid bloating the irq_desc[] array we allocate a sufficient
- number of IRQ slots and map them dynamically to specific sources.
+ Support the i.MX SDMA engine. This engine is integrated into
+ Freescale i.MX25/31/35/51/53/6 chips.
- config PXA_DMA
- bool "PXA DMA support"
- depends on (ARCH_MMP || ARCH_PXA)
+ config INTEL_IOATDMA
+ tristate "Intel I/OAT DMA support"
+ depends on PCI && X86_64
select DMA_ENGINE
- select DMA_VIRTUAL_CHANNELS
+ select DMA_ENGINE_RAID
+ select DCA
help
- Support the DMA engine for PXA. It is also compatible with MMP PDMA
- platform. The internal DMA IP of all PXA variants is supported, with
- 16 to 32 channels for peripheral to memory or memory to memory
- transfers.
+ Enable support for the Intel(R) I/OAT DMA engine present
+ in recent Intel Xeon chipsets.
- config TXX9_DMAC
- tristate "Toshiba TXx9 SoC DMA support"
- depends on MACH_TX49XX || MACH_TX39XX
+ Say Y here if you have such a chipset.
+
+ If unsure, say N.
+
+ config INTEL_IOP_ADMA
+ tristate "Intel IOP ADMA support"
+ depends on ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX
select DMA_ENGINE
+ select ASYNC_TX_ENABLE_CHANNEL_SWITCH
help
- Support the TXx9 SoC internal DMA controller. This can be
- integrated in chips such as the Toshiba TX4927/38/39.
+ Enable support for the Intel(R) IOP Series RAID engines.
- config TEGRA20_APB_DMA
- bool "NVIDIA Tegra20 APB DMA support"
- depends on ARCH_TEGRA
+ config INTEL_MIC_X100_DMA
+ tristate "Intel MIC X100 DMA Driver"
+ depends on 64BIT && X86 && INTEL_MIC_BUS
select DMA_ENGINE
help
- Support for the NVIDIA Tegra20 APB DMA controller driver. The
- DMA controller is having multiple DMA channel which can be
- configured for different peripherals like audio, UART, SPI,
- I2C etc which is in APB bus.
- This DMA controller transfers data from memory to peripheral fifo
- or vice versa. It does not support memory to memory data transfer.
+ This enables DMA support for the Intel Many Integrated Core
+ (MIC) family of PCIe form
Re: [PATCH v10 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others
On 2015-08-25 13:34, Brian Norris wrote:
> One more thing...
>
> On Mon, Aug 03, 2015 at 11:27:26AM +0200, Stefan Agner wrote:
>> --- /dev/null
>> +++ b/drivers/mtd/nand/vf610_nfc.c
>> @@ -0,0 +1,645 @@
> ...
>> +struct vf610_nfc {
>> +struct mtd_info mtd;
>> +struct nand_chip chip;
>> +struct device *dev;
>> +void __iomem *regs;
>> +struct completion cmd_done;
>> +uint buf_offset;
>> +int page_sz;
>
> AFAICT (even with the 2nd patch), you never really use this field. You
> just set it/increment it, but don't use it for anything. Kill it?
It is used in the write path, I think I meant to use it for subpage
writes, when I thought it would just mean to transfer only parts of the
page to the controller.
However, as the subpage discussion basically concluded in not using it
for now on this controller, we can as well transfer the complete page
(page_sz). Or is there another case in which vf610_nfc_write_buf could
be called with less than page_sz?
--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ubifs: Remove dead xattr code
On 08/26/2015 10:15 PM, Josh Cartwright wrote:
On Thu, Aug 20, 2015 at 10:48:38AM +0800, Dongsheng Yang wrote:
On 08/20/2015 04:35 AM, Richard Weinberger wrote:
This is a partial revert of commit d7f0b70d30ffb9bbe6b8a3e1035cf0b79965ef53
("UBIFS: Add security.* XATTR support for the UBIFS").
Hi Richard,
What about a full reverting of this commit. In ubifs, we
*can* support any namespace of xattr including user, trusted, security
or other anyone prefixed by any words. But we have a check_namespace()
in xattr.c to limit what we want to support. That said, if we want to
"Add security.* XATTR support for the UBIFS", what we need to do is
just extending the check_namespace() to allow security namespace pass.
And yes, check_namespace() have been supporting security namespace.
Is this good enough? Yes, it'd mean that the xattrs end up on disk, but
then who's responsible for invoking the selected LSMs inode_init_security()
hooks?
AFAICT, we'd still need to invoke security_inode_init_security for newly
created inodes (which, Richard's proposed commit still does).
OH, right. My bad I missed the security_inode_init_security().
Besides to allow security.* prefix in xattr, we still need to call
security_inode_init_security() in ubifs_create(). That's true.
So what we need to remove is only the ubifs_xattr_handlers.
Thanx Josh, you are right.
And Richard, sorry for my bad mind.
Reviewed-by: Dongsheng Yang
Thanx
Yang
Thanks,
Josh (who, admittedly, is neither a filesystem nor security module guy :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others
On 2015-08-25 13:16, Brian Norris wrote:
> A few more comments.
>
> On Mon, Aug 03, 2015 at 11:27:26AM +0200, Stefan Agner wrote:
>> diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
>> new file mode 100644
>> index 000..5c8dfe8
>> --- /dev/null
>> +++ b/drivers/mtd/nand/vf610_nfc.c
>> @@ -0,0 +1,645 @@
>
> ...
>
>> +/*
>> + * This function supports Vybrid only (MPC5125 would have full RB and four
>> CS)
>> + */
>> +static void vf610_nfc_select_chip(struct mtd_info *mtd, int chip)
>> +{
>> +#ifdef CONFIG_SOC_VF610
>
> Why the #ifdef? I don't see anything compile-time specific to SOC_VF610.
>
> If this is trying to handle the comment above ("This function supports
> Vybrid only (MPC5125 would have full RB and four CS)") then that's the
> wrong way of doing it, as you need to support multiplatform kernels.
> You'll need to have a way to differentiate the different platform
> support at runtime, not compile time.
Yes it is trying to handle the comment above. Well, the other two
platforms I am aware of are also different architectures... (PowerPC and
ColdFire). I think we won't have a multi-architecture kernel anytime
soon, hence I think removing the code at compile time is the right thing
todo.
However, probably CONFIG_SOC_VF610 is the wrong symbol then, I could
just use CONFIG_ARM and add a comment that this might be different on
another other ARM SoC than VF610.
Just checked CodingStyle, and I see that IS_ENABLED is the preferred way
for conditional compiling.
So my suggestion:
static void vf610_nfc_select_chip(struct mtd_info *mtd, int chip)
{
struct vf610_nfc *nfc = mtd_to_nfc(mtd);
u32 tmp = vf610_nfc_read(nfc, NFC_ROW_ADDR);
if (!IS_ENABLED(CONFIG_ARM))
return;
/*
* This code is only tested on the ARM platform VF610
* PowerPC based MPC5125 would have full RB and four CS
*/
With that the compiler should be able to remove this (currently) ARM
VF610 specific code on the other supported architectures...
What do you think?
>
>> +struct vf610_nfc *nfc = mtd_to_nfc(mtd);
>> +u32 tmp = vf610_nfc_read(nfc, NFC_ROW_ADDR);
>> +
>> +tmp &= ~(ROW_ADDR_CHIP_SEL_RB_MASK | ROW_ADDR_CHIP_SEL_MASK);
>> +tmp |= 1 << ROW_ADDR_CHIP_SEL_RB_SHIFT;
>> +
>> +if (chip == 0)
>> +tmp |= 1 << ROW_ADDR_CHIP_SEL_SHIFT;
>> +else if (chip == 1)
>> +tmp |= 2 << ROW_ADDR_CHIP_SEL_SHIFT;
>
> else ... ?
>
> Maybe you can write this as a formulaic pattern (e.g.:
>
> tmp |= (chip + 1) << ROW_ADDR_CHIP_SEL_SHIFT;
>
> ) and just do the "max # of chips" checks on a per-platform basis in the
> probe(). Then I'm guessing this same function can apply to both
> platforms. (I'm not looking at HW datasheets for this, BTW, just
> guessing based on the context here.)
It seems that MCP5125 is different than VF610. MCP5125 has 4 chip
selects and 4 R/B signals, whereas VF610 has only 2 chip selects and
just 1 R/B signals...
> But wait...I see that you call nand_scan_ident() with a max of 1 chip.
> So you won't ever see the chip > 0 case, right?
>
> So does this driver support multiple flash attached or not? Looks like
> you're assuming you'll only be using chip-select 0. (This is fine for
> now, but at least your code should acknowledge this. Perhaps a comment
> at the top under "limitations.")
>
Ok, will add that information under limitations.
>> +
>> +vf610_nfc_write(nfc, NFC_ROW_ADDR, tmp);
>> +#endif
>> +}
>
> ...
>
>> +static int vf610_nfc_probe(struct platform_device *pdev)
>> +{
>
> ...
>
>> +/* first scan to find the device and get the page size */
>> +if (nand_scan_ident(mtd, 1, NULL)) {
>> +err = -ENXIO;
>> +goto error;
>> +}
--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Problems loading firmware using built-in drivers with kernels that use initramfs.
On Thu, Aug 27, 2015 at 2:07 AM, Linus Torvalds wrote: > On Wed, Aug 26, 2015 at 1:06 AM, Liam Girdwood > wrote: >> >> I think the options are to either :- >> >> 1) Don not support audio DSP drivers using topology data as built-in >> drivers. Audio is not really a critical system required for booting >> anyway. > > Yes, forcing it to be a module and not letting people compile it in by > mistake (and then not have it work) is an option. > > That said, there are situations where people don't want to use > modules. I used to eschew them for security reasons, for example - now > I instead just do a one-time temporary key. But others may have other > reasons to try to avoid modules. > >> 2) Create a default PCM for every driver that has topology data on the >> assumption that every sound card will at least 1 PCM. This PCM can then >> be re-configured when the FW is loaded. > > That would seem to be the better option if it is reasonably implementable. > > Of course, some kind of timer-based retry (limited *somehow*) of the > fw loading could work too, but smells really really hacky. Yeah, years ago, we discussed to use -EPROBE_DEFER for the situation, which should be one kind of fix, but looks there were objections at that time. thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next v2 1/2] device property: Return -ENXIO if there is no suitable FW interface
On Wednesday, August 26, 2015 04:25:59 PM Guenter Roeck wrote: > On 08/26/2015 04:37 PM, Rafael J. Wysocki wrote: > > On Wednesday, August 26, 2015 01:20:44 PM Guenter Roeck wrote: > >> Return -ENXIO if device property array access functions don't find > >> a suitable firmware interface. > >> > >> This lets drivers decide if they should use available platform data > >> instead. > >> > >> Cc: Rafael J. Wysocki > >> Signed-off-by: Guenter Roeck > >> --- > >> v2: Added patch > >> > >> drivers/base/property.c | 7 +++ > >> 1 file changed, 7 insertions(+) > >> > >> diff --git a/drivers/base/property.c b/drivers/base/property.c > >> index 287704d680bf..9600b824d138 100644 > >> --- a/drivers/base/property.c > >> +++ b/drivers/base/property.c > >> @@ -69,6 +69,9 @@ static int pset_prop_read_array(struct property_set > >> *pset, const char *name, > >>struct property_entry *prop; > >>unsigned int item_size; > >> > >> + if (!pset) > >> + return -ENXIO; > >> + > > > > This isn't exactly straightforward, because it relies on the fact that > > pset_prop_read_array() is the last thing tried by FWNODE_PROP_READ_ARRAY() > > and fwnode_property_read_string_array(). A comment about that might be > > helpful. > > > I see two options: Add a comment above, or change the calling code to > > ... > else if (is_pset(fwnode)) > return pset_prop_read_array(to_pset(fwnode), propname, > DEV_PROP_STRING, val, nval); > return -ENXIO; > > which would make it obvious and avoid side effects if the code is changed > later on. Would you be ok with this ? The second option is obviously cleaner to me and I prefer cleaner code. :-) Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH][resent] PCI: rcar: Add PCIE_CONF_REGNO macro for PCIECAR register
From: Nobuhiro Iwamatsu The reg variable used when setting PCIECAR register need to be masked by 0xFC by restriction of the corresponding register. This adds PCIE_CONF_REGNO are macros for masking changes that PCIE_CONF_REGNO is used when setting PCIECAR register. Signed-off-by: Nobuhiro Iwamatsu --- This patch was posted to ML, but still no response. I re-sent it because original author has gone now. drivers/pci/host/pcie-rcar.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c index c086210..9fd39cd8b 100644 --- a/drivers/pci/host/pcie-rcar.c +++ b/drivers/pci/host/pcie-rcar.c @@ -104,6 +104,7 @@ #define PCIE_CONF_BUS(b) (((b) & 0xff) << 24) #define PCIE_CONF_DEV(d) (((d) & 0x1f) << 19) #define PCIE_CONF_FUNC(f) (((f) & 0x7) << 16) +#define PCIE_CONF_REGNO(r)(r & 0xfc) #define RCAR_PCI_MAX_RESOURCES 4 #define MAX_NR_INBOUND_MAPS 6 @@ -227,7 +228,8 @@ static int rcar_pcie_config_access(struct rcar_pcie *pcie, /* Set the PIO address */ rcar_pci_write_reg(pcie, PCIE_CONF_BUS(bus->number) | - PCIE_CONF_DEV(dev) | PCIE_CONF_FUNC(func) | reg, PCIECAR); + PCIE_CONF_DEV(dev) | PCIE_CONF_FUNC(func) | + PCIE_CONF_REGNO(reg), PCIECAR); /* Enable the configuration access */ if (bus->parent->number == pcie->root_bus_nr) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[lkp] [mm] 1732e8d84b: -6.4% will-it-scale.per_process_ops
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/andrea/aa.git master
commit 1732e8d84b5fa950d6533284dcc63dfee93e39f1 ("mm: gup: make
get_user_pages_fast and __get_user_pages_fast latency conscious")
=
tbox_group/testcase/rootfs/kconfig/compiler/test:
lkp-sb03/will-it-scale/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/futex1
commit:
7201f254ee6b51b1549ecec1cffe4d59b3e53935
1732e8d84b5fa950d6533284dcc63dfee93e39f1
7201f254ee6b51b1 1732e8d84b5fa950d6533284dc
--
%stddev %change %stddev
\ |\
5363330 ± 0% -6.4%5021398 ± 0% will-it-scale.per_process_ops
1810294 ± 0% -5.0%1720041 ± 0% will-it-scale.per_thread_ops
209850 ± 5% +13.0% 237196 ± 4% cpuidle.C1-SNB.usage
53.75 ± 62%-100.9% -0.50 ±-1300% numa-numastat.node0.other_node
0.00 ± -1% +Inf% 1.11 ± 3%
perf-profile.cpu-cycles.___might_sleep.get_user_pages_fast.get_futex_key.futex_wake.do_futex
2791 ± 2% +15.8% 3231 ± 1% vmstat.system.cs
290504 ± 2% +16.8% 339313 ± 1%
latency_stats.hits.pipe_wait.pipe_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
4203979 ± 0% +5.3%4424982 ± 2%
latency_stats.sum.pipe_wait.pipe_read.__vfs_read.vfs_read.SyS_read.entry_SYSCALL_64_fastpath
2941 ± 15% -23.0% 2266 ± 11% numa-vmstat.node0.nr_anon_pages
3377 ± 13% +19.7% 4040 ± 6% numa-vmstat.node1.nr_anon_pages
2090 ± 27% +49.7% 3129 ± 0% numa-vmstat.node1.nr_mapped
11769 ± 15% -22.9% 9070 ± 11% numa-meminfo.node0.AnonPages
13509 ± 13% +19.7% 16167 ± 6% numa-meminfo.node1.AnonPages
2457 ± 1% +8.9% 2675 ± 3% numa-meminfo.node1.KernelStack
8363 ± 27% +49.7% 12519 ± 0% numa-meminfo.node1.Mapped
11075 ± 24% +95.4% 21637 ± 17%
sched_debug.cfs_rq[24]:/.avg->runnable_avg_sum
37436 ± 10% +29.7% 48571 ± 11%
sched_debug.cfs_rq[24]:/.exec_clock
854911 ± 11% +25.9%1076265 ± 9%
sched_debug.cfs_rq[24]:/.min_vruntime
241.25 ± 24% +95.4% 471.50 ± 16%
sched_debug.cfs_rq[24]:/.tg_runnable_contrib
12705 ± 27% -32.3% 8597 ± 2%
sched_debug.cfs_rq[25]:/.avg->runnable_avg_sum
40588 ± 13% -13.7% 35043 ± 0%
sched_debug.cfs_rq[25]:/.exec_clock
276.00 ± 27% -32.3% 186.75 ± 2%
sched_debug.cfs_rq[25]:/.tg_runnable_contrib
631.75 ±101% -71.4% 180.75 ±164%
sched_debug.cfs_rq[3]:/.blocked_load_avg
689.75 ± 96% -68.1% 220.00 ±134%
sched_debug.cfs_rq[3]:/.tg_load_contrib
4.50 ± 57% -94.4% 0.25 ±173%
sched_debug.cfs_rq[6]:/.nr_spread_over
23334 ± 10% -41.3% 13699 ± 18%
sched_debug.cfs_rq[8]:/.avg->runnable_avg_sum
508.50 ± 10% -41.6% 296.75 ± 18%
sched_debug.cfs_rq[8]:/.tg_runnable_contrib
36.75 ± 1% +15.6% 42.50 ± 11% sched_debug.cpu#1.cpu_load[0]
7238 ± 31%+167.1% 19330 ± 16% sched_debug.cpu#1.nr_switches
8723 ± 23%+147.9% 21622 ± 10% sched_debug.cpu#1.sched_count
3283 ± 33%+179.5% 9179 ± 18% sched_debug.cpu#1.sched_goidle
31624 ± 30% -44.4% 17585 ± 12% sched_debug.cpu#11.sched_count
1170 ± 32% +84.8% 2163 ± 27% sched_debug.cpu#18.sched_goidle
8659 ± 35%+158.8% 22411 ± 18% sched_debug.cpu#2.nr_switches
10200 ± 44%+200.8% 30686 ± 38% sched_debug.cpu#2.sched_count
4063 ± 38%+167.8% 10881 ± 18% sched_debug.cpu#2.sched_goidle
2.00 ±154% +37.5% 2.75 ± 39%
sched_debug.cpu#21.nr_uninterruptible
57326 ± 6% +16.9% 67039 ± 7% sched_debug.cpu#24.nr_load_updates
62286 ± 4% -8.8% 56812 ± 4% sched_debug.cpu#25.nr_load_updates
5467 ± 46%+315.6% 22723 ± 49% sched_debug.cpu#26.nr_switches
5588 ± 45%+312.3% 23036 ± 48% sched_debug.cpu#26.sched_count
2274 ± 57%+357.8% 10412 ± 57% sched_debug.cpu#26.sched_goidle
2440 ± 29% -58.6% 1011 ± 20% sched_debug.cpu#27.ttwu_local
39.25 ± 1% +7.0% 42.00 ± 2% sched_debug.cpu#3.cpu_load[3]
4907 ± 50%+215.8% 15497 ± 49% sched_debug.cpu#5.nr_switches
2213 ± 53%+239.4% 7512 ± 51% sched_debug.cpu#5.sched_goidle
370.00 ± 13% +97.0% 728.75 ± 23% sched_debug.cpu#6.ttwu_local
882811 ± 2% +12.7% 995138 ± 0% sched_debug.cpu#9.avg_idle
lkp-sb03: Sandy Bridge-EP
Memory: 64G
will-it-scale.per_process_ops
5.4e+06 ++---+
*..*...*..*.. .*..*..*...*.. .*...*..*..*
Re: [PATCH 1/7] drm/vc4: Add devicetree bindings for VC4.
On Wed, Aug 26, 2015 at 3:59 PM, Dave Airlie wrote: > On 27 August 2015 at 00:30, Rob Herring wrote: >> On Wed, Aug 26, 2015 at 7:09 AM, Thierry Reding >> wrote: >>> On Wed, Aug 26, 2015 at 01:52:29PM +0200, Daniel Vetter wrote: On Tue, Aug 25, 2015 at 04:42:18PM -0400, Rob Clark wrote: > On Mon, Aug 24, 2015 at 9:47 AM, Rob Herring > wrote: > > On Mon, Aug 17, 2015 at 1:30 PM, Eric Anholt wrote: > >> Stephen Warren writes: > >> > >>> On 08/12/2015 06:56 PM, Eric Anholt wrote: > Signed-off-by: Eric Anholt [...] > +- hvss: List of references to HVS video scalers > +- encoders: List of references to output encoders (HDMI, SDTV) [...] > >>> Of course, this is only appropriate if the HW modules really are > >>> logically children of the VC4 HW module. Perhaps they aren't. If they > >>> aren't though, I wonder what this "vc4" module actually represents > >>> in HW? > >> > >> It's the subsystem, same as we use a subsystem node for msm, sti, > >> rockchip, imx, and exynos. This appears to be the common model of how > >> the collection of graphics-related components is represented in the > >> DT. > > > > I think most of these bindings are wrong. They are grouped together > > because that is what DRM wants not because that reflects the h/w. So > > convince me this is one block, not that it is what other people do. > > I think, when it comes to more complex driver subsystems (like drm in > particular) we have a bit of mismatch between how things look from the > "pure hw ignoring sw" perspective, and the "how sw and in particular > userspace expects things" perspective. Maybe it is less a problem in > other subsystems, where bindings map to things that are only visible > in the kernel, or well defined devices like uart or sata controller. > But when given the choice, I'm going to err on the side of not > confusing userspace and the large software stack that sits above > drm/kms, over dt purity. > > Maybe it would be nice to have a sort of dt overlay that adds the bits > needed to tie together hw blocks that should be assembled into a > single logical device for linux and userspace (but maybe not some > other hypothetical operating system). But so far that doesn't exist. > All we have is a hammer (devicetree), everything looks like a nail. > End result is we end up adding some things in the bindings which > aren't purely about the hw. Until someone invents a screwdriver, I'm > not sure what else to do. In the end, other hypothetical OS is free > to ignore those extra fields in the bindings if it doesn't need them. > So meh? I thought we agreed a while back that these kind of "pull everything for the logical device together" dt nodes which just have piles of phandles are totally accepted? At least that's the point behind the component helpers, and Eric even suggested to create dt-specific component helpers to cut down a bit on the usual boilerplate. dt maintainers are also fine with this approach afaik. From my understanding tegra with the host1x bus really is the odd one out and not the norm. >>> >>> I agree that in many aspects Tegra is somewhat special. But the same >>> principles that the host1x infrastructure uses could be implemented in a >>> similar way for other DRM drivers. You can easily collect information >>> about subdevices by walking the device tree and matching on known >>> compatible strings. And you can also instantiate the top-level device >>> from driver code rather than have it in DT. It should still be possible >>> to make this work without an artificial device node in DT. The component >>> and master infrastructure is largely orthogonal to that, and as far as I >>> remember the only blocker is the need for a top-level device. I wonder >>> if perhaps this could be made to work by binding the master to the top- >>> level SoC device. >>> >>> Obviously adding the node in DT is easier, but to my knowledge easy has >>> never been a good excuse for mangling DT. Perhaps that's different these >>> days... >> >> I agree we should avoid the virtual node if possible. It is certainly >> possible as I started out with one and removed it. At least in my >> case, it essentially required the drm_device and crtc to be a single >> driver rather than 2 components. However, I'm more concerned that we >> are consistent from platform to platform where it makes sense than >> whether we have a somewhat questionable node or not. >> > http://lists.freedesktop.org/archives/dri-devel/2013-July/041159.html > > So can we at least have some continuity of decision making, > bikeshedding this every time we submit a driver isn't giving me any > hope going forward. As I said, whether we have a virtual node or not is a minor part of
Re: [PATCH] kernel/sysctl.c: If "count" including the terminating byte '\0' the write system call should retrun success.
On Wed, Aug 26, 2015 at 4:39 AM, Heinrich Schuchardt wrote:
>
>
> On 24.08.2015 10:56, Sean Fu wrote:
>> when the input argument "count" including the terminating byte "\0",
>> The write system call return EINVAL on proc file.
>> But it return success on regular file.
>>
>> E.g. Writting two bytes ("1\0") to "/proc/sys/net/ipv4/conf/eth0/rp_filter".
>> write(fd, "1\0", 2) return EINVAL.
>
> Reading through kernel/sysctl.c it looks like you are allowing
> "1\01" to be used to pass two integers or two longs.
> This is not what you describe as target of your patch.
"1\01" actually is "1\1", So either of them will fail.
>
> Parameter tr returned from proc_get_long should be checked in
> __do_proc_dointvec,
> __do_proc_doulongvec_minmax.
>
> Best regards
>
> Heinrich Schuchardt
>
>>
>> Signed-off-by: Sean Fu
>> ---
>> kernel/sysctl.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
>> index 19b62b5..c2b0594 100644
>> --- a/kernel/sysctl.c
>> +++ b/kernel/sysctl.c
>> @@ -2004,7 +2004,7 @@ static int do_proc_dointvec_conv(bool *negp,
>> unsigned long *lvalp,
>> return 0;
>> }
>>
>> -static const char proc_wspace_sep[] = { ' ', '\t', '\n' };
>> +static const char proc_wspace_sep[] = { ' ', '\t', '\n', '\0' };
>>
>> static int __do_proc_dointvec(void *tbl_data, struct ctl_table *table,
>> int write, void __user *buffer,
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kernel/sysctl.c: If "count" including the terminating byte '\0' the write system call should retrun success.
On Thu, Aug 27, 2015 at 4:36 AM, Steven Rostedt wrote: > On Wed, 26 Aug 2015 23:48:01 +0800 > Sean Fu wrote: > > >> > Defending the patch, I can't imagine any user space code expecting the >> > current behavior. The current behavior is that if you write "1\0" it >> > will error out instead of accepting the "1". I can't come up with a >> > scenario that would require userspace to expect "1\0" to fail. Can you? >> Thanks > > Although, with the current patch, would "1\02" fail? It should. Yes, "1\02" is equal to "1\2"(count=2) or "1\2\0"(count=3), So it should fail. code len = write(fd, "1\0\2", 3); strace execute result: write(3, "1\2\0", 3)= -1 EINVAL (Invalid argument) > > -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND RESEND RESEND PATCH v2] mtd: nand_bbt: scan for next free bbt block if writing bbt fails
On Wed, Aug 26, 2015 at 03:57:00PM +, Bean Huo 霍斌斌 (beanhuo) wrote:
> > On Tue, Aug 25, 2015 at 12:49:26PM -0500, Xander Huff wrote:
> > > diff --git a/drivers/mtd/nand/nand_bbt.c b/drivers/mtd/nand/nand_bbt.c
> > > index 63a1a36..09f9e62 100644
> > > --- a/drivers/mtd/nand/nand_bbt.c
> > > +++ b/drivers/mtd/nand/nand_bbt.c
> > > -787,13 +788,42 @@ static int write_bbt(struct mtd_info *mtd, uint8_t
> > > *buf,
> > > einfo.addr = to;
> > > einfo.len = 1 << this->bbt_erase_shift;
> > > res = nand_erase_nand(mtd, , 1);
> > > - if (res < 0)
> > > + if (res == -EIO && einfo.state == MTD_ERASE_FAILED
> > > + && einfo.priv == NAND_ERASE_BLOCK_ERASE_FAILED) {
> >
> > Do you actually need that last condition? What's wrong with the first two?
> >
> > > + /* This block is bad. Mark it as such and see if
> > > + * there's another block available in the BBT area. */
> > > + int block = page >>
> > > + (this->bbt_erase_shift - this->page_shift);
> > > + pr_info("nand_bbt: failed to erase block %d when writing
> > BBT\n",
> > > + block);
> > > + bbt_mark_entry(this, block, BBT_BLOCK_WORN);
> > > +
> > > + res = this->block_markbad(mtd, block);
> > > + if (res)
> > > + pr_warn("nand_bbt: error %d while marking block
> > > %d
> > bad\n",
> > > + res, block);
> > > + goto next;
> > > + } else if (res < 0)
> > > goto outerr;
>
>
> For my knowledge , we don't directly mark this block be a bad block,
> Just like ubi layer,this block also need to further testing and verify if
> It is real bad block.right?
That's a good point...we might want some kind of separate function for a
torture test. Might look at UBI's torture_peb() for inspiration.
> > >
> > > res = scan_write_bbt(mtd, to, len, buf,
> > > td->options & NAND_BBT_NO_OOB ? NULL :
> > > [len]);
> > > - if (res < 0)
> > > + if (res == -EIO) {
> > > + /* This block is bad. Mark it as such and see if
> > > + * there's another block available in the BBT area. */
> > > + int block = page >>
> > > + (this->bbt_erase_shift - this->page_shift);
> > > + pr_info("nand_bbt: failed to erase block %d when writing
> > BBT\n",
> > > + block);
> > > + bbt_mark_entry(this, block, BBT_BLOCK_WORN);
> > > +
> > > + res = this->block_markbad(mtd, block);
> > > + if (res)
> > > + pr_warn("nand_bbt: error %d while marking block
> > > %d
> > bad\n",
> > > + res, block);
> > > + goto next;
> > > + } else if (res < 0)
> > > goto outerr;
> > >
> > > pr_info("Bad block table written to 0x%012llx, version
> > > 0x%02X\n",
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] mm: Check if section present during memory block registering
On Wed, 26 Aug 2015, Yinghai Lu wrote:
> Tony found on his setup, if memory block size 512M will cause crash
> during booting.
>
> BUG: unable to handle kernel paging request at ea007420
> IP: [] get_nid_for_pfn+0x17/0x40
> PGD 128ffcb067 PUD 128ffc9067 PMD 0
> Oops: [#1] SMP
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.2.0-rc8 #1
> ...
> Call Trace:
> [] ? register_mem_sect_under_node+0x66/0xe0
> [] register_one_node+0x17b/0x240
> [] ? pci_iommu_alloc+0x6e/0x6e
> [] topology_init+0x3c/0x95
> [] do_one_initcall+0xcd/0x1f0
>
> The system has non continuous RAM address:
> BIOS-e820: [mem 0x0013-0x001c] usable
> BIOS-e820: [mem 0x001d7000-0x001ec7ffefff] usable
> BIOS-e820: [mem 0x001f-0x002b] usable
> BIOS-e820: [mem 0x002c1800-0x002d6fffefff] usable
> BIOS-e820: [mem 0x002e-0x0039] usable
>
> So there are start sections in memory block not present.
> For example:
> memory block : [0x2c1800, 0x2c2000) 512M
> first three sections are not present.
>
> Current register_mem_sect_under_node() assume first section is present,
> but memory block section number range [start_section_nr, end_section_nr]
> would include not present section.
>
> For arch that support vmemmap, we don't setup memmap for struct page area
> within not present sections area.
>
> So skip the pfn range that belong to absent section.
>
> Reported-by: Tony Luck
> Tested-by: Tony Luck
> Fixes: bdee237c0343 ("x86: mm: Use 2GB memory block size on large memory
> x86-64 systems")
> Fixes: 982792c782ef ("x86, mm: probe memory block size for generic x86 64bit")
> Signed-off-by: Yinghai Lu
> Cc: sta...@vger.kernel.org #v3.15
With the fixes folded:
Tested-by: David Rientjes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] mpt3sas: Reference counting fixes from in-flight mpt2sas
On Wed, 2015-08-26 at 16:54 -0700, Calvin Owens wrote: > On Wednesday 08/26 at 04:09 +, Nicholas A. Bellinger wrote: > > From: Nicholas Bellinger > > > > Hi James & Co, > > > > This series is a mpt3sas forward port of Calvin Owens' in-flight > > reference counting bugfixes for mpt2sas LLD code here: > > > > [PATCH v4 0/2] Fixes for memory corruption in mpt2sas > > http://marc.info/?l=linux-scsi=143951695904115=2 > > Nicholas, > > I'm glad to hear these fixes were helpful! I was planning on porting to > mpt3sas in the near future, thanks for saving me the trouble :) > Would you mind giving this series the once over, and add your Reviewed-by as well..? Sreekanth + Avago folks, can you please do the same for Calvin's mpt2sas series and this series..? This has been a long-standing issue with mpt*sas LLD code and really needs to be addressed for upstream. Thank you, --nab -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] mpt3sas: Reference counting fixes from in-flight mpt2sas
On Wednesday 08/26 at 04:09 +, Nicholas A. Bellinger wrote: > From: Nicholas Bellinger > > Hi James & Co, > > This series is a mpt3sas forward port of Calvin Owens' in-flight > reference counting bugfixes for mpt2sas LLD code here: > > [PATCH v4 0/2] Fixes for memory corruption in mpt2sas > http://marc.info/?l=linux-scsi=143951695904115=2 Nicholas, I'm glad to hear these fixes were helpful! I was planning on porting to mpt3sas in the near future, thanks for saving me the trouble :) Calvin > The differences between mpt2sas + mpt3sas in this area are very, > very small, and is required to address a NULL pointer dereference > OOPsen in _scsih_probe_sas() -> mpt3sas_transport_port_add() -> > sas_port_add_phy() that I've been hitting occasionally on boot > during initial LUN scan. > > So far this code has been tested on v3.14.47 with a small cluster > using SAS3008 HBAs plus a few preceeding upstream mpt3sas patches > so these patches apply cleanly, and with the changes in place the > original OOPsen appears to be resolved. > > This patch series is cut atop v4.2-rc1 code, and barring any > objections from Avago folks et al., should be considered along > with Calvin's mpt2sas patch set for v4.3-rc1 code. > > Thank you, > > --nab > > Nicholas Bellinger (2): > mpt3sas: Refcount sas_device objects and fix unsafe list usage > mpt3sas: Refcount fw_events and fix unsafe list usage > > drivers/scsi/mpt3sas/mpt3sas_base.h | 23 +- > drivers/scsi/mpt3sas/mpt3sas_scsih.c | 592 > ++- > drivers/scsi/mpt3sas/mpt3sas_transport.c | 12 +- > 3 files changed, 449 insertions(+), 178 deletions(-) > > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] timer: Improve itimers scalability
On 08/26/2015 04:13 PM, Frederic Weisbecker wrote: On Wed, Aug 26, 2015 at 03:53:26PM -0700, Hideaki Kimura wrote: Sure, let me elaborate. Executive summary: Yes, enabling a process-wide timer in such a large machine is not wise, but sometimes users/applications cannot avoid it. The issue was observed actually not in a database itself but in a common library it links to; gperftools. The database itself is optimized for many-cores/sockets, so surely it avoids putting a process-wide timer or other unscalable things. It just links to libprofiler for an optional feature to profile performance bottleneck only when the user turns it on. We of course avoid turning the feature on unless while we debug/tune the database. However, libprofiler sets the timer even when the client program doesn't invoke any of its functions: libprofiler does it when the shared library is loaded. We requested the developer of libprofiler to change the behavior, but seems like there is a reason to keep that behavior: https://code.google.com/p/gperftools/issues/detail?id=133 Based on this, I think there are two reasons why we should ameliorate this issue in kernel layer. 1. In the particular case, it's hard to prevent or even detect the issue in user space. We (a team of low-level database and kernel experts) in fact spent huge amount of time to just figure out what's the bottleneck there because nothing measurable happens in user space. I pulled out countless hairs. Also, the user has to de-link the library from the application to prevent the itimer installation. Imagine a case where the software is proprietary. It won't fly. 2. This is just one example. There could be many other such binaries/libraries that do similar things somewhere in a complex software stack. Today we haven't heard of many such cases, but people will start hitting it once 100s~1,000s of cores become common. After applying this patchset, we have observed that the performance hit almost completely went away at least for 240 cores. So, it's quite beneficial in real world. I can easily imagine that many code incidentally use posix cpu timers when it's not strictly required. But it doesn't look right to fix the kernel for that. For this simple reason: posix cpu timers, even after your fix, should introduce noticeable overhead. All threads of a process with a timer enqueued in elapse the cputime in a shared atomic variable. Add to that the overhead of enqueuing the timer, firing it. There is a bunch of scalability issue there. I totally agree that this is not a perfect solution. If there are 10x more cores and sockets, just the atomic fetch_add might be too expensive. However, it's comparatively/realistically the best thing we can do without any drawbacks. We can't magically force all library developers to write the most scalable code always. My point is: this is a safety net, and a very effective one. -- Hideaki Kimura -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mtd: nand_bbt: separate struct nand_chip from nand_bbt.c
Hi Peter,
On Tue, Jul 07, 2015 at 06:02:52AM +, Peter Pan 潘栋 (peterpandong) wrote:
> Currently nand_bbt.c is tied with struct nand_chip, and it makes other
> NAND family chips hard to use nand_bbt.c. Maybe it's the reason why
> onenand has own bbt(onenand_bbt.c).
>
> Parameterize a few relevant device detail information into a new
> nand_bbt struct, and set some hooks for chip specified part. Allocate
> and initialize struct nand_bbt in nand_base.c.
>
> Most of the patch is borrowed from Brian Norris .
> http://git.infradead.org/users/norris/linux-mtd.git/shortlog/refs/heads/nand-bbt
>
> Signed-off-by: Peter Pan
> Signed-off-by: Brian Norris
> Tested-by: Kamil Debski
Sorry for the delays on this. Part of the reason for the delay comes
from my first criticism: this is an awfully big patch to review and
apply in one go. (I'm not the only one to say this; I know at least one
other who couldn't find the time to review this due to its size.) Is
there any way you can break it into more manageable parts that can be
reviewed and verified on their own? There's a good reason that this
patch was left in my WIP tree with a "not complete" tag, and part of
that is that I considered this to be a disorganized pile of related
changes that I'd need to sort out later.
Some possible categories that could be separated (use your judgment, but
many of these can probably be their own patch):
* migrating existing definitions to a new header (nand_bbt.h)
* BIG POINT (at least for me): what did you change from my WIP patch
that you "borrowed"?
* adding new definitions, with a good explanation of the design
(completely missing so far); e.g., what does the layering look like?
* add new API definitions (with no users), with an intermediate
implementation that existing users could use; the API should look the
same, except you'd do something like this at first:
struct nand_bbt {
struct nand_chip *chip; /* <-- this won't be here later, but it
helps at first */
struct mtd_info *mtd;
...
};
int nand_bbt_markbad(struct nand_bbt *bbt, loff_t offs)
{
/*
* FIXME: nand_markbad_bbt() still assumes mtd->priv is a struct
* nand_chip
*/
return nand_markbad_bbt(bbt->mtd, offs);
}
* convert existing nand_bbt users (i.e., nand_base) to use this new API
* convert nand_bbt.c implementation to actually be independent of
nand_chip
There may be more to split out, but it's a little hard to judge right
now. Please let me know if you don't understand what I'm asking for, or
if you have objections.
I have a few small comments buried below, but I expect I (and others)
will be able to review a little better once you address some of the
above.
> ---
> changelog:
> v1-v2:
> Address Kamil Debski's test
> Add necessary comments to nand_bbt struct
>
> drivers/mtd/nand/docg4.c | 8 +-
> drivers/mtd/nand/nand_base.c | 145 +++-
> drivers/mtd/nand/nand_bbt.c | 524
> +--
> include/linux/mtd/bbm.h | 96 +---
> include/linux/mtd/nand.h | 14 +-
> include/linux/mtd/nand_bbt.h | 172 ++
> 6 files changed, 533 insertions(+), 426 deletions(-)
> create mode 100644 include/linux/mtd/nand_bbt.h
>
> diff --git a/drivers/mtd/nand/docg4.c b/drivers/mtd/nand/docg4.c
> index e5d7bca..eb55a21 100644
> --- a/drivers/mtd/nand/docg4.c
> +++ b/drivers/mtd/nand/docg4.c
> @@ -1037,7 +1037,7 @@ static int __init read_factory_bbt(struct mtd_info *mtd)
>* operation after device power-up. The above read ensures it never is.
>* Ugly, I know.
>*/
> - if (nand->bbt == NULL) /* no memory-based bbt */
> + if (nand->nand_bbt == NULL) /* no memory-based bbt */
> goto exit;
>
> if (mtd->ecc_stats.failed > eccfailed_stats) {
> @@ -1064,7 +1064,11 @@ static int __init read_factory_bbt(struct mtd_info
> *mtd)
> unsigned long bits = ~buf[i];
> for_each_set_bit(bitnum, , 8) {
> int badblock = block + 7 - bitnum;
> - nand->bbt[badblock / 4] |=
> + /*
> + * Should we create a mark factory bad block interface
> + * for this?
> + */
This comment shouldn't be here. I guess that's a FIXME? Well fix it!
> + nand->nand_bbt->bbt[badblock / 4] |=
> 0x03 << ((badblock % 4) * 2);
Nope. To do this all right, we need to provide a proper abstraction for
what's being done here. No breaking the layering like this.
> mtd->ecc_stats.badblocks++;
> dev_notice(doc->dev, "factory-marked bad block: %d\n",
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index ceb68ca..eb94714 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++
[ANNOUNCE] Report of the thermal micro-conference in LPC 2015 - Seattle, WA
Hello, On Thu, Mar 26, 2015 at 08:02:49PM -0400, Eduardo Valentin wrote: > Hello all, > > > A initial proposal for the topics to be discussed are: > . Closed loop control governors > . Sensor API > . Thermal class: split of temperature sensor device and thermal driver > . Improvements on OF-thermal > . Devfreq vs. clock cooling > . Power model based policies > . User space tools > . User space governors > I want to thank you all who was present in Linux Plumbers 2015 this year for the thermal MC. Also, I want to thank the LPC organization to opening up the space, infrastructure, and time slot to make the first thermal mc within this event. I am writing a short summary of the discussion we had during the MC for those that were not present. You may find the MC minute note in Etherpad [1]. You may also find the slide set of each presentation in LPC webpage [2]. Key attendees: - Rui Zhang - Len Brown - Rafael J. Wysocki - Srinivas Pandruvada - Kristen Accardi - Javi Merino - Punit Agrawal - Kapileshwar Singh - Lina Iyer - Eduardo Valentin We started with a brief overview of the subsystem. I described the concepts involved and how they are represented in the subsystem: thermal zones, thermal sensors, trip points, cooling devices, and thermal governors. I also gave a snapshot of the supported SoCs. To open the discussion for the following presentations, I introduced the current open items. The list was restricted compared to our original proposal (above). Therefore, the MC focused more on the sensor API, thermal zone representation, and tools. On the sensor API, there were several proposals. First, there is an agreement within the community (at least those in the audience) that there is a need to have the representation of more than one sensor per zone. Use cases of extrapolating hotspots on package or on device surfaces are the typical application of this needed support. Still in the sensor API, specially what concerns the interactions with userspace, there is also an consensus that monitoring temperature from userspace using the thermal subsystem may be not optimal. Overhead and latencies are the main concerns. However, we do have thermal management solutions in userspace that needs to be supported. (open source) Examples of them are thermald, iTux, and DPTF. The proposal to improve in this front is to add a thermal -> iio bridge [3]. The audience also did not presented any resistance on this proposal. Related to the sensor API is the thermal topology representation. There are two major proposals here. First is to have a hierarchical representation of thermal zones. The hierarchy would be reflected in the sysfs representation of thermal. The hierarchy is linked to have multiple temperature sources into a single thermal zone, except that the source could be another thermal zone. This point brings up the idea of having aggregation functions on the temperature inputs. Examples of common aggregation functions are: maximum temperature, moving average window, linear extrapolation (linear coefficients). The idea would be to allow switching the aggregation function from userspace. The second proposal on thermal topology, on top of having hierarchical representation, would be to also add the knowledge of which devices the thermal zone covers. The motivation here is to have an API to get a temperature of a device using its struct device *. This type of query is useful while computing estimation of leakage power, for instance. We would need to have a list of struct device * within the thermal zone device struct. However, if you think about it, a device may also be covered by multiple thermal zones. Therefore, we may end up with a many to many relationship. We also had a presentation on assertion based thermal testing. The presented tool is able to produce automated testing using assertions on top of tracing produced by the thermal framework. The tool has been used to compare system behavior on the same workload across different thermal management solutions (say, between thermal governors). The tool has also been used to profile EAS behavior. I personally like the fact that the building blocks we have today inside the kernel enables us to deploy such kind of tools. The last, but not least, discussion was around the link between thermal and EAS. The idea is to close the loop and improve performance. Idea is to have thermal governor (such as power allocator) to talk to the scheduler, and use the thermal limit as a notion of capacity. However, at this point, not much data on which clear use cases the improvement would be seen. It would interesting to know the performance improvements, and also, the power and thermal benefits. I hope we keep having such opportunities to get the thermal community to discuss the current challenges and how we can better enhance the existing solutions. BR, Eduardo Valentin [1] - https://etherpad.openstack.org/p/LPC2015_Thermal [2] -
Re: [PATCH 3/3] timer: Reduce unnecessary sighand lock contention
On Wed, 2015-08-26 at 15:33 -0400, George Spelvin wrote:
> And some more comments on the series...
>
> > @@ -626,6 +628,7 @@ struct task_cputime_atomic {
> > struct thread_group_cputimer {
> > struct task_cputime_atomic cputime_atomic;
> > int running;
> >+int checking_timer;
> > };
>
> Why not make both running and checking_timer actual booleans, so the
> pair is only 16 bits rather than 64?
>
> I suppose since sum_exec_runtime in struct task_cputime_atomic is 64 bits,
> alignment means there's no actual improvement. It's just my personal
> preference (Linus disagrees with me!) for the bool type for documentation.
>
> (Compile-tested patch appended.)
I can include your patch in the series and then use boolean for the new
checking_timer field. However, it looks like this applies on an old
kernel. For example, the spin_lock field has already been removed from
the structure.
> But when it comes to really understanding this code, I'm struggling.
> It seems that this changes the return value of of fastpath_timer_check.
> I'm tryng to wrap my head around exactly why that is safe.
>
> Any time I see things like READ_ONCE and WRITE_ONCE, I wonder if there
> need to be memory barriers as well. (Because x86 has strong default
> memory ordering, testing there doesn't prove the code right on other
> platforms.)
>
> For the writes, the surrounding spinlock does the job.
>
> But on the read side (fastpath_timer_check), I'm not sure
> what the rules should be.
>
> Or is it basically okay if this is massively racey, since process-wide
> CPU timers are inherently sloppy. A race will just cause an expiration
> check to be missed, but it will be retried soon anyway.
Yes, the worst case scenario is that we wait until the next thread to
come along and handle the next expired timer. However, this "delay"
already occurs now (for example: a timer can expire right after a thread
exits check_process_timers()).
> Other half-baked thoughts that went through my head:
>
> If the problem is that you have contention for read access to
> sig->cputimer.cputime, can that be changed to a seqlock?
>
> Another possibility is to use a trylock before testing
> checking_timer:
>
> if (sig->cputimer.running) {
> struct task_cputime group_sample;
>
> - raw_spin_lock(>cputimer.lock);
> + if (!raw_spin_trylock(>cputimer.lock)) {
> + if (READ_ONCE(sig->cputimer.checking_timer))
> + return false; /* Lock holder's doing it for
> us */
> + raw_spin_lock(>cputimer.lock);
> + }
The spinlock call has already been removed from a previous patch. The
issue now is with contention with the sighand lock.
Thanks,
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [scsi 5/7 RESEND] scsi_debug: schedule_resp fix input variable check
On Tue, 2015-08-25 at 21:03 +, Winkler, Tomas wrote:
>
> > > + /* this should never happen */
> > > + if (WARN_ON(!cmnd))
> > > + return SCSI_MLQUEUE_HOST_BUSY;
> > >
> > > - if (NULL == cmnd || NULL == devip) {
> > > - pr_warn("called with NULL cmnd or devip pointer\n");
> > > + if (NULL == devip) {
> > > + pr_warn("called devip == NULL\n");
> > > /* no particularly good error to report back */
> > > return SCSI_MLQUEUE_HOST_BUSY;
> > > }
> >
> > Please refer to the patch I just posted, we can't return _HOST_BUSY here
> > if devip == NULL. I posted a fix against the current "misc" branch as
> > I don't see this patch applied, let me know if I need to update it.
>
>
> I'm just not sure why the patches are not merged or even rejected.
Because ideally I want a Maintainer ack. That's Doug Gilbert.
> I'm submitting patches to the Linux kernel for more than 10 years to
> various trees and I can agree that these are not some urgent fixes,
> but this is the first time my effort is ignored for such long time by
> the maintainer.
Well, OK, I trust martin, I'll override the lack of Maintainer ack if
you fix as Ewan suggests.
James
> Thanks
> Tomas
>
> NrybXǧv^){.n+{"{ay ʇڙ,jfhz w j:+vwjmzZ+ݢj"!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/5] mtd: nand: Qualcomm NAND controller driver
On 08/19, Archit Taneja wrote: > The Qualcomm NAND controller is found in SoCs like IPQ806x, MSM7xx, > MDM9x15 series. > > It exists as a sub block inside the IPs EBI2 (External Bus Interface 2) > and QPIC (Qualcomm Parallel Interface Controller). These IPs provide a > broader interface for external slow peripheral devices such as LCD and > NAND/NOR flash memory or SRAM like interfaces. > > We add support for the NAND controller found within EBI2. For the SoCs > of our interest, we only use the NAND controller within EBI2. Therefore, > it's safe for us to assume that the NAND controller is a standalone block > within the SoC. > > The controller supports 512B, 2kB, 4kB and 8kB page 8-bit and 16-bit NAND > flash devices. It contains a HW ECC block that supports BCH ECC (4, 8 and > 16 bit correction/step) and RS ECC(4 bit correction/step) that covers main > and spare data. The controller contains an internal 512 byte page buffer > to which we read/write via DMA. The EBI2 type NAND controller uses ADM DMA > for register read/write and data transfers. The controller performs page > reads and writes at a codeword/step level of 512 bytes. It can support up > to 2 external chips of different configurations. > > The driver prepares register read and write configuration descriptors for > each codeword, followed by data descriptors to read or write data from the > controller's internal buffer. It uses a single ADM DMA channel that we get > via dmaengine API. The controller requires 2 ADM CRCIs for command and > data flow control. These are passed via DT. > > The ecc layout used by the controller is syndrome like, but we can't use > the standard syndrome ecc ops because of several reasons. First, the amount > of data bytes covered by ecc isn't same in each step. Second, writing to > free oob space requires us writing to the entire step in which the oob > lies. This forces us to create our own ecc ops. > > One more difference is how the controller accesses the bad block marker. > The controller ignores reading the marker when ECC is enabled. ECC needs > to be explicity disabled to read or write to the bad block marker. For > this reason, we use the newly created flag NAND_BBT_ACCESS_BBM_RAW to > read the factory provided bad block markers. > > v4: > - Shrink submit_descs > - add desc list node at the end of dma_prep_desc > - Endianness and warning fixes > > Signed-off-by: Stephen Boyd > > v3: > - Refactor dma functions for maximum reuse > - Use dma_slave_confing on stack > - optimize and clean upempty_page_fixup using memchr_inv > - ensure portability with dma register reads using le32_* funcs > - use NAND_USE_BOUNCE_BUFFER instead of doing it ourselves > - fix handling of return values of dmaengine funcs > - constify wherever possible > - Remove dependency on ADM DMA in Kconfig > - Misc fixes and clean ups > > v2: > - Use new BBT flag that allows us to read BBM in raw mode > - reduce memcpy-s in the driver > - some refactor and clean ups because of above changes > > Reviewed-by: Andy Gross > Signed-off-by: Archit Taneja > --- Reviewed-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2]: acpica/nfit: Rename not-armed bit definition
On Wed, 2015-08-26 at 17:29 -0600, Toshi Kani wrote: > On Thu, 2015-08-27 at 01:16 +0200, Rafael J. Wysocki wrote: > > On Wed, Aug 26, 2015 at 11:12 PM, Toshi Kani wrote: > > > On Wed, 2015-08-26 at 10:16 -0700, Dan Williams wrote: > > > > On Wed, Aug 26, 2015 at 9:20 AM, Toshi Kani > > > > wrote: > > > > > ACPI 6.0 NFIT Memory Device State Flags in Table 5-129 defines > > > > > bit 3 as follows. > > > > > > > > > > Bit [3] set to 1 to indicate that the Memory Device is observed > > > > > to be not armed prior to OSPM hand off. A Memory Device is > > > > > considered armed if it is able to accept persistent writes. > > > > > > > > > > This bit is currently defined as ACPI_NFIT_MEM_ARMED, which can be > > > > > confusing as if the Memory Device is armed when this bit is set. > > > > > > > > > > Change the name to ACPI_NFIT_MEM_NOT_ARMED per the spec. > > > > > > > > > > Signed-off-by: Toshi Kani > > > > > Cc: Dan Williams > > > > > Cc: Bob Moore > > > > > Cc: Rafael J. Wysocki > > > > > --- > > > > > drivers/acpi/nfit.c |6 +++--- > > > > > drivers/acpi/nfit.h |2 +- > > > > > include/acpi/actbl1.h|2 +- > > > > > > > > This file "include/acpi/actbl1.h" is owned by the ACPICA project so > > > > any changes need to come through them. But that said, I'm not sure > > > > we > > > > need friendly names at this level. > > > > > > I think the name is misleading, but I agree with the process and this > > > patch2 can be dropped. It'd be nice if the ACPICA project can pick it > > > up later when they have a chance, though. > > > > A good way to cause that to happen would be to send a patch to the > > ACPICA development list + maintainers as per MAINTAINERS. > > Oh, I see. I did run get_maintainer.pl for this patch, but > de...@acpica.org did not come out in output... So, I did not realize this > email list. Sorry, it was listed in the output. I was simply blinded... :-( $ scripts/get_maintainer.pl patches-nd-flags/02* : linux-nvd...@lists.01.org (open list:LIBNVDIMM BLK: MMIO-APERTURE DRIVER) linux-a...@vger.kernel.org (open list:ACPI) linux-kernel@vger.kernel.org (open list) de...@acpica.org (open list:ACPI COMPONENT ARCHITECTURE (ACPICA)) Thanks! -Toshi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 4/5] mm: make compound_head() robust
On Wed, Aug 26, 2015 at 03:28:39PM -0700, Hugh Dickins wrote: > On Wed, 26 Aug 2015, Paul E. McKenney wrote: > > On Wed, Aug 26, 2015 at 11:18:45AM -0700, Hugh Dickins wrote: > > > On Tue, 25 Aug 2015, Paul E. McKenney wrote: > > > > On Tue, Aug 25, 2015 at 10:46:44PM +0200, Vlastimil Babka wrote: > > > > > On 25.8.2015 22:11, Paul E. McKenney wrote: > > > > > > On Tue, Aug 25, 2015 at 09:33:54PM +0300, Kirill A. Shutemov wrote: > > > > > >> On Tue, Aug 25, 2015 at 01:44:13PM +0200, Vlastimil Babka wrote: > > > > > >>> On 08/21/2015 02:10 PM, Kirill A. Shutemov wrote: > > > > > On Thu, Aug 20, 2015 at 04:36:43PM -0700, Andrew Morton wrote: > > > > > > On Wed, 19 Aug 2015 12:21:45 +0300 "Kirill A. Shutemov" > > > > > > wrote: > > > > > > > > > > > >> The patch introduces page->compound_head into third double > > > > > >> word block in > > > > > >> front of compound_dtor and compound_order. That means it > > > > > >> shares storage > > > > > >> space with: > > > > > >> > > > > > >> - page->lru.next; > > > > > >> - page->next; > > > > > >> - page->rcu_head.next; > > > > > >> - page->pmd_huge_pte; > > > > > >> > > > > > >>> > > > > > >>> We should probably ask Paul about the chances that rcu_head.next > > > > > >>> would like > > > > > >>> to use the bit too one day? > > > > > >> > > > > > >> +Paul. > > > > > > > > > > > > The call_rcu() function does stomp that bit, but if you stop using > > > > > > that > > > > > > bit before you invoke call_rcu(), no problem. > > > > > > > > > > You mean that it sets the bit 0 of rcu_head.next during its > > > > > processing? > > > > > > > > Not at the moment, though RCU will splat if given a misaligned rcu_head > > > > structure because of the possibility to use that bit to flag callbacks > > > > that do nothing but free memory. If RCU needs to do that (e.g., to > > > > promote energy efficiency), then that bit might well be set during > > > > RCU grace-period processing. > > > > > > But if you do one day implement that, wouldn't sl?b.c have to use > > > call_rcu_with_added_meaning() instead of call_rcu(), to be in danger > > > of getting that bit set? (No rcu_head is placed in a PageTail page.) > > > > Good point, call_rcu_lazy(), but yes. > > > > > So although it might be a little strange not to use a variant intended > > > for freeing memory when indeed that's what it's doing, it would not be > > > the end of the world for SLAB_DESTROY_BY_RCU to carry on using straight > > > call_rcu(), in defence of the struct page safety Kirill is proposing. > > > > As long as you are OK with the bottom bit being zero throughout the RCU > > processing, yes. > > That's exactly what we want: sounds like we have no problem, thanks Paul. Whew! ;-) Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] S390: add pci_iomap_wc() and pci_iomap_wc_range()
From: "Luis R. Rodriguez" S390 requires its own implementation of pcio_iomap*() calls is because it has its "BAR spaces are not disjunctive on s390 so we need the bar parameter of pci_iomap to find the corresponding device and create the mapping cookie" -- in summary, it has its own lookup/lock solution. It does not include asm-generic/pci_iomap.h Since it currenty maps ioremap_wc() to ioremap_nocache() and that's the architecture default we can easily just map the wc calls to the default calls as well. Cc: Guenter Roeck Cc: Jean-Christophe Plagniol-Villard Cc: Tomi Valkeinen Cc: linux-fb...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Borislav Petkov Cc: Ingo Molnar Cc: Fengguang Wu Cc: Andrew Morton Cc: Steven Rostedt Reported-by: 0 day bot Signed-off-by: Luis R. Rodriguez --- This broke through some series that went into Ingo's tip tree which I added. As such I *think* this should go through Ingo's tip tree. Let me know. Up to you guys. arch/s390/include/asm/io.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/s390/include/asm/io.h b/arch/s390/include/asm/io.h index cb5fdf3a78fc..437e9af96688 100644 --- a/arch/s390/include/asm/io.h +++ b/arch/s390/include/asm/io.h @@ -57,6 +57,8 @@ static inline void ioport_unmap(void __iomem *p) */ #define pci_iomap pci_iomap #define pci_iounmap pci_iounmap +#define pci_iomap_wc pci_iomap +#define pci_iomap_wc_range pci_iomap_range #define memcpy_fromio(dst, src, count) zpci_memcpy_fromio(dst, src, count) #define memcpy_toio(dst, src, count) zpci_memcpy_toio(dst, src, count) -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] timer: Reduce unnecessary sighand lock contention
On Thu, 2015-08-27 at 00:56 +0200, Frederic Weisbecker wrote:
> On Tue, Aug 25, 2015 at 08:17:48PM -0700, Jason Low wrote:
> > It was found while running a database workload on large systems that
> > significant time was spent trying to acquire the sighand lock.
> >
> > The issue was that whenever an itimer expired, many threads ended up
> > simultaneously trying to send the signal. Most of the time, nothing
> > happened after acquiring the sighand lock because another thread
> > had already sent the signal and updated the "next expire" time. The
> > fastpath_timer_check() didn't help much since the "next expire" time
> > was updated later.
> >
> > This patch addresses this by having the thread_group_cputimer structure
> > maintain a boolean to signify when a thread in the group is already
> > checking for process wide timers, and adds extra logic in the fastpath
> > to check the boolean.
> >
> > Signed-off-by: Jason Low
> > ---
> > include/linux/init_task.h |1 +
> > include/linux/sched.h |3 +++
> > kernel/time/posix-cpu-timers.c | 19 +--
> > 3 files changed, 21 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/init_task.h b/include/linux/init_task.h
> > index d0b380e..3350c77 100644
> > --- a/include/linux/init_task.h
> > +++ b/include/linux/init_task.h
> > @@ -53,6 +53,7 @@ extern struct fs_struct init_fs;
> > .cputimer = { \
> > .cputime_atomic = INIT_CPUTIME_ATOMIC, \
> > .running= 0,\
> > + .checking_timer = 0,\
> > }, \
> > INIT_PREV_CPUTIME(sig) \
> > .cred_guard_mutex = \
> > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > index 119823d..a6c8334 100644
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -619,6 +619,8 @@ struct task_cputime_atomic {
> > * @cputime_atomic:atomic thread group interval timers.
> > * @running: non-zero when there are timers running and
> > * @cputime receives updates.
> > + * @checking_timer:non-zero when a thread is in the process of
> > + * checking for thread group timers.
> > *
> > * This structure contains the version of task_cputime, above, that is
> > * used for thread group CPU timer calculations.
> > @@ -626,6 +628,7 @@ struct task_cputime_atomic {
> > struct thread_group_cputimer {
> > struct task_cputime_atomic cputime_atomic;
> > int running;
> > + int checking_timer;
>
> How about a flag in the "running" field instead?
>
> 1) Space in signal_struct is not as important as in task_strut but it
>still matters.
George Spelvin suggested that we convert them to booleans which would
make them take up 2 bytes.
> 2) We already read the "running" field locklessly. Adding a new field like
>checking_timer gets even more complicated. Ideally there should be at
>least a paired memory barrier between both. Let's just simplify that
>with a single field.
hmmm, so having 1 "flag" where we access bits for the "running" and
"checking_timer"?
> Now concerning the solution for your problem, I'm a bit uncomfortable with
> lockless magics like this. When the thread sets checking_timer to 1, there is
> no guarantee that the other threads in the process will see it "fast" enough
> to avoid the slow path checks. Then there is also the risk that the threads
> don't see "fast" enough that checking_timers has toggled to 0 and as a result
> a timer may expire late. Now the lockless access of "running" already induces
> such race. So if it really solves issues in practice, why not.
Perhaps to be safer, we use something like load_acquire() and
store_release() for accessing both the ->running and ->checking_timer
fields?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
