[RFC PATCH] iio: adc: at91-sama5d2_adc: add support for oversampling resolution
This is implements oversampling support for the SAMA5D2 ADC
device.
Enabling oversampling : OSR can improve resolution from 12 bits to
13 or 14 bits.
To not modify the scan element of the buffer , from 12 bits to 13 or 14,
I have added the extra bit(s) as MICRO values to the INT value from the
conversion.
Special care was required for the triggered buffer scenario (+ DMA).
Signed-off-by: Eugen Hristev
---
Hello Jonathan,
I marked this patch as RFC because I am not confident in the best way to handle
this oversampling support.
I modified the return value of the channels to use IIO_VALUE_INT_PLUS_MICRO
instead of IIO_VALUE_INT, so I can add an extra bit or two bits in there to the
INT value (0/50 or 0/25/50/750) .
You know of a better way to add this support?
Looks like the iio channel spec cannot be modified at
runtime. Would be best if the real bits in the channel spec would be changed to
13 or 14, but then, the buffer would be confused, as the buffer spec is now
le:u12/16>>0 so how can I change that to reflect oversampling, or,
IIO_VALUE_INT_PLUS_MICRO ?
And I am not sure how to handle this w.r.t ABI and userspace changes.
At this moment I added the micro values just to the software trigger readings,
and triggered buffer + DMA does not provide the extra bits, but, I need
to shift all values with 2 bits to the right . The code is rather ugly
right now, but I can change it to look prettier if this is the proper way
to do it.
Thanks for all the feedback,
Eugen
drivers/iio/adc/at91-sama5d2_adc.c | 198 -
1 file changed, 172 insertions(+), 26 deletions(-)
diff --git a/drivers/iio/adc/at91-sama5d2_adc.c
b/drivers/iio/adc/at91-sama5d2_adc.c
index 58c4c2b..f1a89b7 100644
--- a/drivers/iio/adc/at91-sama5d2_adc.c
+++ b/drivers/iio/adc/at91-sama5d2_adc.c
@@ -130,6 +130,15 @@
#define AT91_SAMA5D2_OVER 0x3c
/* Extended Mode Register */
#define AT91_SAMA5D2_EMR 0x40
+/* Extended Mode Register - Oversampling rate */
+#define AT91_SAMA5D2_EMR_OSR(V)((V) << 16)
+#define AT91_SAMA5D2_EMR_OSR_MASK GENMASK(17, 16)
+#define AT91_SAMA5D2_EMR_OSR_0SAMPLES 0
+#define AT91_SAMA5D2_EMR_OSR_4SAMPLES 1
+#define AT91_SAMA5D2_EMR_OSR_16SAMPLES 2
+
+/* Extended Mode Register - Averaging on single trigger event */
+#define AT91_SAMA5D2_EMR_ASTE(V) ((V) << 20)
/* Compare Window Register */
#define AT91_SAMA5D2_CWR 0x44
/* Channel Gain Register */
@@ -248,6 +257,14 @@
#define AT91_HWFIFO_MAX_SIZE_STR "128"
#define AT91_HWFIFO_MAX_SIZE 128
+/* Possible values for oversampling ratio, and the string equivalent */
+#define AT91_OSR_0SAMPLES 0
+#define AT91_OSR_0SAMPLES_STR "0"
+#define AT91_OSR_4SAMPLES 4
+#define AT91_OSR_4SAMPLES_STR "4"
+#define AT91_OSR_16SAMPLES 16
+#define AT91_OSR_16SAMPLES_STR "16"
+
#define AT91_SAMA5D2_CHAN_SINGLE(num, addr)\
{ \
.type = IIO_VOLTAGE,\
@@ -261,7 +278,8 @@
}, \
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
- .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ),\
+ .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ)|\
+ BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
.datasheet_name = "CH"#num, \
.indexed = 1, \
}
@@ -281,7 +299,8 @@
}, \
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
- .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ),\
+ .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ)|\
+ BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
.datasheet_name = "CH"#num"-CH"#num2, \
.indexed = 1, \
}
@@ -299,7 +318,8 @@
.storagebits = 16, \
}, \
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
- .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ),\
+ .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SAMP_FREQ)|\
+ BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
.datasheet_name = name, \
}
#define AT91_SAM
Re: [PATCH v1] aio: mark __aio_sigset::sigmask const
On Fri, Jun 08, 2018 at 05:55:05PM +0300, Avi Kivity wrote: > io_pgetevents() will not change the signal mask. Mark it const > to make it clear and to reduce the need for casts in user code. > > Signed-off-by: Avi Kivity Looks good, Reviewed-by: Christoph Hellwig
RE: [RFC v1 1/2] crypto/virtio-crypto: Read crypto services and algorithm masks
> -Original Message-
> From: Farhan Ali [mailto:al...@linux.ibm.com]
> Sent: Saturday, June 09, 2018 3:09 AM
> To: linux-kernel@vger.kernel.org; k...@vger.kernel.org
> Cc: m...@redhat.com; qemu-de...@nongnu.org; Gonglei (Arei)
> ; longpeng ;
> pa...@linux.ibm.com; fran...@linux.ibm.com; borntrae...@de.ibm.com;
> al...@linux.ibm.com
> Subject: [RFC v1 1/2] crypto/virtio-crypto: Read crypto services and algorithm
> masks
>
> Read the crypto services and algorithm masks which provides
> information about the services and algorithms supported by
> virtio-crypto backend.
>
> Signed-off-by: Farhan Ali
> ---
> drivers/crypto/virtio/virtio_crypto_common.h | 14 ++
> drivers/crypto/virtio/virtio_crypto_core.c | 29
>
> 2 files changed, 43 insertions(+)
>
> diff --git a/drivers/crypto/virtio/virtio_crypto_common.h
> b/drivers/crypto/virtio/virtio_crypto_common.h
> index 66501a5..05eca12e 100644
> --- a/drivers/crypto/virtio/virtio_crypto_common.h
> +++ b/drivers/crypto/virtio/virtio_crypto_common.h
> @@ -55,6 +55,20 @@ struct virtio_crypto {
> /* Number of queue currently used by the driver */
> u32 curr_queue;
>
> + /*
> + * Specifies the services mask which the device support,
> + * see VIRTIO_CRYPTO_SERVICE_* above
> + */
Pls update the above comments. Except that:
Acked-by: Gonglei
> + u32 crypto_services;
> +
> + /* Detailed algorithms mask */
> + u32 cipher_algo_l;
> + u32 cipher_algo_h;
> + u32 hash_algo;
> + u32 mac_algo_l;
> + u32 mac_algo_h;
> + u32 aead_algo;
> +
> /* Maximum length of cipher key */
> u32 max_cipher_key_len;
> /* Maximum length of authenticated key */
> diff --git a/drivers/crypto/virtio/virtio_crypto_core.c
> b/drivers/crypto/virtio/virtio_crypto_core.c
> index 8332698..8f745f2 100644
> --- a/drivers/crypto/virtio/virtio_crypto_core.c
> +++ b/drivers/crypto/virtio/virtio_crypto_core.c
> @@ -303,6 +303,13 @@ static int virtcrypto_probe(struct virtio_device *vdev)
> u32 max_data_queues = 0, max_cipher_key_len = 0;
> u32 max_auth_key_len = 0;
> u64 max_size = 0;
> + u32 cipher_algo_l = 0;
> + u32 cipher_algo_h = 0;
> + u32 hash_algo = 0;
> + u32 mac_algo_l = 0;
> + u32 mac_algo_h = 0;
> + u32 aead_algo = 0;
> + u32 crypto_services = 0;
>
> if (!virtio_has_feature(vdev, VIRTIO_F_VERSION_1))
> return -ENODEV;
> @@ -339,6 +346,20 @@ static int virtcrypto_probe(struct virtio_device *vdev)
> max_auth_key_len, &max_auth_key_len);
> virtio_cread(vdev, struct virtio_crypto_config,
> max_size, &max_size);
> + virtio_cread(vdev, struct virtio_crypto_config,
> + crypto_services, &crypto_services);
> + virtio_cread(vdev, struct virtio_crypto_config,
> + cipher_algo_l, &cipher_algo_l);
> + virtio_cread(vdev, struct virtio_crypto_config,
> + cipher_algo_h, &cipher_algo_h);
> + virtio_cread(vdev, struct virtio_crypto_config,
> + hash_algo, &hash_algo);
> + virtio_cread(vdev, struct virtio_crypto_config,
> + mac_algo_l, &mac_algo_l);
> + virtio_cread(vdev, struct virtio_crypto_config,
> + mac_algo_h, &mac_algo_h);
> + virtio_cread(vdev, struct virtio_crypto_config,
> + aead_algo, &aead_algo);
>
> /* Add virtio crypto device to global table */
> err = virtcrypto_devmgr_add_dev(vcrypto);
> @@ -358,6 +379,14 @@ static int virtcrypto_probe(struct virtio_device *vdev)
> vcrypto->max_cipher_key_len = max_cipher_key_len;
> vcrypto->max_auth_key_len = max_auth_key_len;
> vcrypto->max_size = max_size;
> + vcrypto->crypto_services = crypto_services;
> + vcrypto->cipher_algo_l = cipher_algo_l;
> + vcrypto->cipher_algo_h = cipher_algo_h;
> + vcrypto->mac_algo_l = mac_algo_l;
> + vcrypto->mac_algo_h = mac_algo_h;
> + vcrypto->hash_algo = hash_algo;
> + vcrypto->aead_algo = aead_algo;
> +
>
> dev_info(&vdev->dev,
> "max_queues: %u, max_cipher_key_len: %u, max_auth_key_len: %u,
> max_size 0x%llx\n",
> --
> 2.7.4
Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset
Hi, On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote: > * Faiz Abbas [180611 06:28]: >> Great. I thought I completely misunderstood you. But I don't see what >> adding another function will accomplish. A QUIRK flag used in the same >> function would work well enough> > Fine with me as long as the function stays simple for both > syss and sysc reset. > In general a reset status bit being in sysstatus is the norm and it being in sysconfig should be the "quirk" for which a flag needs to be added. What do you think? As an aside, naming bitshifts by the name of the platform they were originally added in seems weird. There should be some generic mask saying "soft reset is the 0th bit". Currently I am using SYSC_OMAP4_SOFTRESET for a dra76x module. I guess it depends on how many different sysconfig types we have. Thanks, Faiz
Re: [PATCH v2 1/2] media: v4l2-ctrl: Add control for VP9 profile
Hi, Hans. Thank you for the review. Your idea sounds good. However, I think that changing V4L2_CID_MPEG_VIDEO_VPX_PROFILE to an enum breaks both of s5p-mfc and venus drivers. This is because they call 'v4l2_ctrl_new_std' for it. For menu controls, 'v4l2_ctrl_new_std_menu' must be used. https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c#L2678 https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/qcom/venus/vdec_ctrls.c#L133 I can fix them within the commit for adding VP8_PROFILE control, but cannot confirm that it works on real devices since I don't have them. What should I do? Best regards, Keiichi On Fri, Jun 8, 2018 at 10:00 PM Nicolas Dufresne wrote: > > > > Le ven. 8 juin 2018 08:56, Stanimir Varbanov a > écrit : >> >> Hi Hans, >> >> On 06/08/2018 12:29 PM, Hans Verkuil wrote: >> > On 05/30/2018 09:16 AM, Keiichi Watanabe wrote: >> >> Add a new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE for selecting desired >> >> profile for VP9 encoder and querying for supported profiles by VP9 encoder >> >> or decoder. >> >> >> >> An existing control V4L2_CID_MPEG_VIDEO_VPX_PROFILE cannot be >> >> used for querying since it is not a menu control but an integer >> >> control, which cannot return an arbitrary set of supported profiles. >> >> >> >> The new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE is a menu control as >> >> with controls for other codec profiles. (e.g. H264) >> > >> > Please ignore my reply to patch 2/2. I looked at this a bit more and what >> > you >> > should do is to change the type of V4L2_CID_MPEG_VIDEO_VPX_PROFILE to enum. >> > >> > All other codec profile controls are all enums, so the fact that >> > VPX_PROFILE >> > isn't is a bug. Changing the type should not cause any problems since the >> > same >> > control value is used when you set the control. >> > >> > Sylwester: I see that s5p-mfc uses this control, but it is explicitly added >> > as an integer type control, so the s5p-mfc driver should not be affected by >> > changing the type of this control. >> > >> > Stanimir: this will slightly change the venus driver, but since it is a >> > very >> > recent driver I think we can get away with changing the core type of the >> > VPX_PROFILE control. I think that's better than ending up with two controls >> > that do the same thing. >> >> I agree. Actually the changes shouldn't be so much in venus driver. > > > Also fine on userspace side, since profiles enumeration isn't implemented yet > in FFMPEG, GStreamer, Chrome > > >> >> -- >> regards, >> Stan
[PATCH v3] clk: qcom: Enable clocks which needs to be always on for SDM845
There are certain clocks which needs to be always enabled for system
operation. Add support for the same by adding 'CLK_IS_CRITICAL' flag
for such clocks.
Signed-off-by: Amit Nischal
---
Changes in v3:
* Addressed review comments by Stephen to associate 'CLK_IS_CRITICAL'
flag for the clocks which are required to be always ON.
* Added two gcc_cpuss* critical clocks and remove direct clock enable
for them from gcc probe function.
Changes in v2:
* Fix target name in kernel configuration help text for SDM845 GCC
clock driver.
[v1]: https://lkml.org/lkml/2018/5/28/171
[v2]: https://lkml.org/lkml/2018/5/29/43
drivers/clk/qcom/gcc-sdm845.c | 43 ++---
include/dt-bindings/clock/qcom,gcc-sdm845.h | 2 ++
2 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
index e78e6f5..0f694ed 100644
--- a/drivers/clk/qcom/gcc-sdm845.c
+++ b/drivers/clk/qcom/gcc-sdm845.c
@@ -1103,6 +1103,7 @@ enum {
.enable_mask = BIT(0),
.hw.init = &(struct clk_init_data){
.name = "gcc_camera_ahb_clk",
+ .flags = CLK_IS_CRITICAL,
.ops = &clk_branch2_ops,
},
},
@@ -1129,6 +1130,7 @@ enum {
.enable_mask = BIT(0),
.hw.init = &(struct clk_init_data){
.name = "gcc_camera_xo_clk",
+ .flags = CLK_IS_CRITICAL,
.ops = &clk_branch2_ops,
},
},
@@ -1270,6 +1272,7 @@ enum {
.enable_mask = BIT(0),
.hw.init = &(struct clk_init_data){
.name = "gcc_disp_ahb_clk",
+ .flags = CLK_IS_CRITICAL,
.ops = &clk_branch2_ops,
},
},
@@ -1328,6 +1331,7 @@ enum {
.enable_mask = BIT(0),
.hw.init = &(struct clk_init_data){
.name = "gcc_disp_xo_clk",
+ .flags = CLK_IS_CRITICAL,
.ops = &clk_branch2_ops,
},
},
@@ -1397,6 +1401,7 @@ enum {
.enable_mask = BIT(0),
.hw.init = &(struct clk_init_data){
.name = "gcc_gpu_cfg_ahb_clk",
+ .flags = CLK_IS_CRITICAL,
.ops = &clk_branch2_ops,
},
},
@@ -2985,6 +2990,7 @@ enum {
.enable_mask = BIT(0),
.hw.init = &(struct clk_init_data){
.name = "gcc_video_ahb_clk",
+ .flags = CLK_IS_CRITICAL,
.ops = &clk_branch2_ops,
},
},
@@ -3011,6 +3017,7 @@ enum {
.enable_mask = BIT(0),
.hw.init = &(struct clk_init_data){
.name = "gcc_video_xo_clk",
+ .flags = CLK_IS_CRITICAL,
.ops = &clk_branch2_ops,
},
},
@@ -3049,6 +3056,36 @@ enum {
},
};
+static struct clk_branch gcc_cpuss_dvm_bus_clk = {
+ .halt_reg = 0x48190,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x48190,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "gcc_cpuss_dvm_bus_clk",
+ .flags = CLK_IS_CRITICAL,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch gcc_cpuss_gnoc_clk = {
+ .halt_reg = 0x48004,
+ .halt_check = BRANCH_HALT_VOTED,
+ .hwcg_reg = 0x48004,
+ .hwcg_bit = 1,
+ .clkr = {
+ .enable_reg = 0x52004,
+ .enable_mask = BIT(22),
+ .hw.init = &(struct clk_init_data){
+ .name = "gcc_cpuss_gnoc_clk",
+ .flags = CLK_IS_CRITICAL,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
static struct gdsc pcie_0_gdsc = {
.gdscr = 0x6b004,
.pd = {
@@ -3344,6 +3381,8 @@ enum {
[GPLL0] = &gpll0.clkr,
[GPLL0_OUT_EVEN] = &gpll0_out_even.clkr,
[GPLL4] = &gpll4.clkr,
+ [GCC_CPUSS_DVM_BUS_CLK] = &gcc_cpuss_dvm_bus_clk.clkr,
+ [GCC_CPUSS_GNOC_CLK] = &gcc_cpuss_gnoc_clk.clkr,
};
static const struct qcom_reset_map gcc_sdm845_resets[] = {
@@ -3433,10 +3472,6 @@ static int gcc_sdm845_probe(struct platform_device *pdev)
regmap_update_bits(regmap, 0x09ffc, 0x3, 0x3);
regmap_update_bits(regmap, 0x71028, 0x3, 0x3);
- /* Enable CPUSS clocks */
- regmap_update_bits(regmap, 0x48190, BIT(0), 0x1);
- regmap_update_bits(regmap, 0x52004, BIT(22), 0x1);
-
return qcom_cc_really_probe(pdev, &gcc_sdm845_desc, regmap);
}
diff --git a/include/dt-bindings/clock/qcom,gcc-sdm845.h
b/include/d
Re: [PATCH v5 08/14] mfd: da9063: Replace model with type
Hi Marek,
I love your patch! Yet something to improve:
[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on v4.17 next-20180608]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Marek-Vasut/mfd-da9063-Replace-regmap_add_irq_chip-with-devm-counterpart/20180607-152143
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: mips-allmodconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mips
All errors (new ones prefixed by >>):
drivers/input/joystick/analog.c:176:2: warning: #warning Precise timer not
defined for this architecture. [-Wcpp]
#warning Precise timer not defined for this architecture.
^~~
drivers/mfd/cros_ec_dev.c:265:13: warning: '__remove' defined but not used
[-Wunused-function]
static void __remove(struct device *dev) { }
^~~~
drivers/regulator/da9063-regulator.c: In function 'da9063_regulator_probe':
>> drivers/regulator/da9063-regulator.c:749:10: error: 'struct da9063' has no
>> member named 'model'
da9063->model);
^~
make[3]: *** [drivers/regulator/da9063-regulator.o] Error 1
make[3]: Target '__build' not remade because of errors.
make[2]: *** [drivers/regulator] Error 2
drivers/spi/spi-sh-msiof.c:77:0: warning: "STR" redefined
#define STR 0x40 /* Status Register */
In file included from arch/mips/include/asm/mach-generic/spaces.h:15:0,
from arch/mips/include/asm/addrspace.h:13,
from arch/mips/include/asm/barrier.h:11,
from include/linux/compiler.h:245,
from arch/mips/include/asm/bitops.h:16,
from include/linux/bitops.h:38,
from include/linux/bitmap.h:8,
from drivers/spi/spi-sh-msiof.c:14:
arch/mips/include/asm/mipsregs.h:29:0: note: this is the location of the
previous definition
#define STR(x) __STR(x)
In file included from arch/mips/include/asm/sibyte/sb1250.h:41:0,
from drivers/watchdog/sb_wdog.c:58:
arch/mips/include/asm/sibyte/bcm1480_scd.h:274:0: warning: "M_SPC_CFG_CLEAR"
redefined
#define M_SPC_CFG_CLEAR M_BCM1480_SPC_CFG_CLEAR
In file included from arch/mips/include/asm/sibyte/sb1250.h:40:0,
from drivers/watchdog/sb_wdog.c:58:
arch/mips/include/asm/sibyte/sb1250_scd.h:405:0: note: this is the location
of the previous definition
#define M_SPC_CFG_CLEAR _SB_MAKEMASK1(32)
In file included from arch/mips/include/asm/sibyte/sb1250.h:41:0,
from drivers/watchdog/sb_wdog.c:58:
arch/mips/include/asm/sibyte/bcm1480_scd.h:275:0: warning:
"M_SPC_CFG_ENABLE" redefined
#define M_SPC_CFG_ENABLE M_BCM1480_SPC_CFG_ENABLE
In file included from arch/mips/include/asm/sibyte/sb1250.h:40:0,
from drivers/watchdog/sb_wdog.c:58:
arch/mips/include/asm/sibyte/sb1250_scd.h:406:0: note: this is the location
of the previous definition
#define M_SPC_CFG_ENABLE _SB_MAKEMASK1(33)
make[2]: Target '__build' not remade because of errors.
vim +749 drivers/regulator/da9063-regulator.c
69ca3e58 Krystian Garbaciak 2013-07-29 715
69ca3e58 Krystian Garbaciak 2013-07-29 716 static int
da9063_regulator_probe(struct platform_device *pdev)
69ca3e58 Krystian Garbaciak 2013-07-29 717 {
69ca3e58 Krystian Garbaciak 2013-07-29 718 struct da9063 *da9063 =
dev_get_drvdata(pdev->dev.parent);
69ca3e58 Krystian Garbaciak 2013-07-29 719 struct da9063_pdata
*da9063_pdata = dev_get_platdata(da9063->dev);
0fdfd40a Geert Uytterhoeven 2013-09-09 720 struct of_regulator_match
*da9063_reg_matches = NULL;
69ca3e58 Krystian Garbaciak 2013-07-29 721 struct da9063_regulators_pdata
*regl_pdata;
69ca3e58 Krystian Garbaciak 2013-07-29 722 const struct da9063_dev_model
*model;
69ca3e58 Krystian Garbaciak 2013-07-29 723 struct da9063_regulators
*regulators;
69ca3e58 Krystian Garbaciak 2013-07-29 724 struct da9063_regulator *regl;
69ca3e58 Krystian Garbaciak 2013-07-29 725 struct regulator_config config;
69ca3e58 Krystian Garbaciak 2013-07-29 726 bool bcores_merged,
bmem_bio_merged;
69ca3e58 Krystian Garbaciak 2013-07-29 727 int id, irq, n, n_regulators,
ret, val;
69ca3e58 Krystian Garbaciak 2013-07-29 728 size_t size;
69ca3e58 Krystian Garbaciak 2013-07-29 729
69ca3e58 Krystian Garbaciak 2013-07-29 730 regl_pdata = da9063_pdata ?
da9063_pdata->regulators_pdata : NULL;
69ca3e58 Krystian Garbaciak 2013-07-29 731
69ca3e58 Krystian Garbaciak 2013-07-29 732 if
RE: [PATCH 03/11] spi: Add a driver for the Freescale/NXP QuadSPI controller
Hi Boris, -Original Message- From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] Sent: Friday, June 8, 2018 6:22 PM To: Yogesh Narayan Gaur Cc: Frieder Schrempf ; linux-...@lists.infradead.org; linux-...@vger.kernel.org; dw...@infradead.org; computersforpe...@gmail.com; marek.va...@gmail.com; rich...@nod.at; miquel.ray...@bootlin.com; broo...@kernel.org; David Wolfe ; Fabio Estevam ; Prabhakar Kushwaha ; Han Xu ; linux-kernel@vger.kernel.org Subject: Re: [PATCH 03/11] spi: Add a driver for the Freescale/NXP QuadSPI controller Hi Yogesh, On Fri, 8 Jun 2018 11:54:12 + Yogesh Narayan Gaur wrote: > Hi Frieder, > > I have tried to validate your patch on fsl,ls2080a target having 2 Spansion > NOR flash, S25FS512S, as slave device. > Below are my observations: > > Observation 1: > In Linux boot logs after driver probing is successful, getting below log > messages > [1.435986] m25p80 spi0.0: found s25fl512s, expected m25p80 > [1.441564] m25p80 spi0.0: s25fl512s (65536 Kbytes) > [1.446972] m25p80 spi0.1: found s25fl512s, expected m25p80 > [1.452548] m25p80 spi0.1: s25fl512s (65536 Kbytes) > > IMHO, we need to correct message as 'found s25fl512s, expected m25p80' as > final underlying connected flash device is s25fl512s. Not sure what you mean here. What would you like us to fix exactly? > > Observation 2: > I have observed data sanity issue after performing read/write > operations using MTD interface. Explained below > > root:~# mtd_debug erase /dev/mtd0 0x100 0x4 > Erased 262144 bytes from address 0x0100 in flash --> > Erase at address 0x100 of erase size 0x4 > root:~# mtd_debug read /dev/mtd0 0x0 0x100 rp > Copied 256 bytes from address 0x in flash to rp --> > Read 0x100 bytes from flash from address 0x0 in file rp > root:~# mtd_debug write /dev/mtd0 0x100 0x100 rp > Copied 256 bytes from rp to address 0x0100 in flash --> > Write 0x100 bytes to flash address 0x100 from file rp > root:~# mtd_debug read /dev/mtd0 0x100 0x100 wp > Copied 256 bytes from address 0x0100 in flash to wp --> > Read 0x100 bytes from flash from address 0x100 in file wp > root:~# diff rp wp >--> compare both rp and wp files, if they are > different output comes on console stating file are different > Files rp and wp differ > root:~# hexdump wp > 000 aa55 aa55 8010 541c 4000 0040 > 010 000a > 020 0030 11a0 00a0 2580 > 030 0040 005b > 040 > * > 100 > root:~# hexdump rp > 000 aa55 aa55 8010 541c 4000 0040 > 010 000a > 020 0030 11a0 00a0 2580 > 030 0040 005b > 040 2403 > 050 > * > 070 0011 09e7 4411 9555 0050 > 080 f9bc afa1 0404 31e0 > 090 0400 31e0 2010 08dc 31eb > 0a0 2880 0050 1300 31eb 4e20 8010 80ff > 0b0 beef dead beef dead beef dead > 0c0 beef dead beef dead beef dead beef dead > * > 100 > root:~# > > In hexdump output of the file which being read from address 0x100,wp, it > can be observed that only first 64 bytes (0x40) are written on the flash. > > Observation 3: > As we can support JFFS2 filesystem on NOR flash, so we can expect JFFS2 > commands should work fine on NOR flash. > But with this driver change my mount command is not working. > > In my target there are 2 flash slave devices connected, and I have given > argument to create MTD partition like > "mtdparts=20c.quadspi-1:5M(rcw),10M(test),46M(rootfs) " for 2nd flash. > Below is output for /proc/mtd commands > root@ls1012ardb:~# cat /proc/mtd > dev:size erasesize name > mtd0: 0400 0004 "20c.quadspi-0" --> First 64MB flash > mtd1: 0050 0004 "rcw" --> Second 64 > MB flash device, 3 MTD partition are created for it. > mtd2: 00a0 0004 "test" > mtd3: 02e0 0004 "rootfs" > > root@ls1012ardb:~# mkdir /media/ram ; flash_eraseall /dev/mtd3 > flash_eraseall has been replaced by `flash_erase 0 0`; please > use it > Erasing 256 Kibyte @ 0 -- 0 % complete [ 18.299929] random: crng init > done > Erasing 256 Kibyte @ 2dc -- 100 % complete > root@ls1012ardb:~# mount -t jffs2 /dev/mtdblock3 /media/ram/ > > This command didn't finish successfully and there are lot of messages coming > on console mentioning failure in jffs2_scan_eraseblock() > [ 187.118677] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not > found at 0x013c
Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset
* Faiz Abbas [180611 06:28]: > Great. I thought I completely misunderstood you. But I don't see what > adding another function will accomplish. A QUIRK flag used in the same > function would work well enough. Fine with me as long as the function stays simple for both syss and sysc reset. Regards, Tony
Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset
On Monday 11 June 2018 11:39 AM, Tony Lindgren wrote:
> * Faiz Abbas [180611 06:09]:
>> Hi Tony,
>>
>> On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:
>>> * Faiz Abbas [180607 10:24]:
Hi,
On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
> * Faiz Abbas [180606 06:14]:
>> +static int sysc_reset(struct sysc *ddata)
>> +{
>> +int offset = ddata->offsets[SYSC_SYSCONFIG];
>> +int val = sysc_read(ddata, offset);
>> +
>> +val |= (0x1 << ddata->cap->regbits->srst_shift);
>> +sysc_write(ddata, offset, val);
>> +
>> +/* Poll on reset status */
>> +if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
>> +offset = ddata->offsets[SYSC_SYSSTATUS];
>> +
>> +return readl_poll_timeout(ddata->module_va + offset,
>> val,
>> +(val & ddata->cfg.syss_mask) == 0x0,
>> +100, MAX_MODULE_SOFTRESET_WAIT);
>> +}
>> +
>> +return 0;
>> +}
>
> I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
> addition to SYSC_QUIRK_RESET status to make it easy to
> read the right register?
I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
the register. Are there layouts in which the reset status bit is in the
sysconfig register rather than the sysstatus register?
>>>
>>> Yes we can have reset status bit in either syss or syssconfig register.
>>
>> You mean sysstatus and sysconfig right?
>
> Yup.
>
>>> We detect that in sysc_init_syss_mask() but we should also set something
>>> at that point to make it clear which reset to use. But as we don't need
>>> the quirk flag, it's probably set a function pointer after the detection.
>>> So how about let's have two functions sysc_reset() and sysc_syss_reset()
>>> and then we can implement sysc_syss_reset() in a separate patch after
>>> testing it when we have a non-platform data using example for
>>> sysc_syss_reset().
>>>
>>
>> Shouldn't the function I add be called sysc_syss_reset()? The reset
>> status bit is in the sysstatus.
>
> Yes
>
Great. I thought I completely misunderstood you. But I don't see what
adding another function will accomplish. A QUIRK flag used in the same
function would work well enough.
Regards,
Faiz
Possible regression caused by commit a192aa923b66a
Hi Rafael,
There's a regression report [1] that says commit a192aa923b66a ("ACPI /
LPSS: Consolidate runtime PM and system sleep handling") is the first bad
commit.
From the looks of it, it didn't introduce any behavioral change. So your
help is appreciated.
[1] https://bugs.launchpad.net/bugs/1774950
Kai-Heng
Re: [PATCH 2/2] IB/mad: Use IDR for agent IDs
On Sun, 10 Jun 2018 22:42:03 -0600 Jason Gunthorpe wrote: > Er, the spec has nothing to do with this. In Linux the TID is made > unique because the core code provides 32 bits that are unique and the > user provides another 32 bits that are unique. The driver cannot > change any of those bits without risking non-uniquenes, which is > exactly the bug mlx4 created when it stepped outside its bounds and > improperly overrode bits in the TID for its own internal use. Actually, the opposite is true here. When SRIOV is active, each VM generates its *own* TIDs -- with 32 bits of agent number and 32 bits of counter. There is a chance that two different VMs can generate the same TID! Encoding the slave (VM) number in the packet actually guarantees uniqueness here. There is nothing wrong with modifying the TID in a reversible way in order to: a. guarantee uniqueness b. identify the VM which should receive the response packet The problem was created when the agent-id numbers started to use the most-significant byte (thus making the MSB slave-id addition impossible).
Re: [PATCH] proc: add proc_seq_release
On Sun, Jun 10, 2018 at 03:51:24AM +0800, Chunyu Hu wrote: > kmemleak reported some memory leak on reading proc files. After adding > some debug lines, find that proc_seq_fops is using seq_release as > release handler, which won't handle the free of 'private' field of > seq_file, while in fact the open handler proc_seq_open could create > the private data with __seq_open_private when state_size is greater > than zero. So after reading files created with proc_create_seq_private, > such as /proc/timer_list and /proc/vmallocinfo, the private mem of a > seq_file is not freed. Fix it by adding the paired proc_seq_release > as the default release handler of proc_seq_ops instead of seq_release. Indeed, thanks for the patch. Reviewed-by: Christoph Hellwig
Re: [PATCH v2] clk: qcom: Enable clocks which needs to be always on for SDM845
On 2018-06-01 22:06, Stephen Boyd wrote: Quoting Amit Nischal (2018-05-28 23:07:46) There are certain clocks which needs to be always enabled for system operation. Remove support for such clocks from the clock driver and enable them explicitly gcc driver probe. Also fix the target name in kernel configuration description for SDM845 gcc driver. This is why we have CLK_IS_CRITICAL. Signed-off-by: Amit Nischal --- diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig index fc3edd1..79e9144 100644 --- a/drivers/clk/qcom/Kconfig +++ b/drivers/clk/qcom/Kconfig @@ -231,7 +231,7 @@ config SDM_GCC_845 select QCOM_GDSC depends on COMMON_CLK_QCOM help - Support for the global clock controller on msm8998 devices. + Support for the global clock controller on SDM845 devices. Say Y if you want to use peripheral devices such as UART, SPI, I2C, USB, UFS, SDDC, PCIe, etc. This can be its own patch. Thanks for fixing above as this is already in the clk-next branch under commit "77122d". diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c index e78e6f5..b40aafc 100644 --- a/drivers/clk/qcom/gcc-sdm845.c +++ b/drivers/clk/qcom/gcc-sdm845.c @@ -3433,9 +3327,16 @@ static int gcc_sdm845_probe(struct platform_device *pdev) regmap_update_bits(regmap, 0x09ffc, 0x3, 0x3); regmap_update_bits(regmap, 0x71028, 0x3, 0x3); - /* Enable CPUSS clocks */ - regmap_update_bits(regmap, 0x48190, BIT(0), 0x1); - regmap_update_bits(regmap, 0x52004, BIT(22), 0x1); + /* Enable clocks which are required to be always ON */ + regmap_update_bits(regmap, 0xb004, BIT(0), BIT(0)); + regmap_update_bits(regmap, 0xb008, BIT(0), BIT(0)); + regmap_update_bits(regmap, 0xb00c, BIT(0), BIT(0)); + regmap_update_bits(regmap, 0xb028, BIT(0), BIT(0)); + regmap_update_bits(regmap, 0xb02c, BIT(0), BIT(0)); + regmap_update_bits(regmap, 0xb030, BIT(0), BIT(0)); + regmap_update_bits(regmap, 0x48190, BIT(0), BIT(0)); + regmap_update_bits(regmap, 0x52004, BIT(22), BIT(22)); + regmap_update_bits(regmap, 0x71004, BIT(0), BIT(0)); Let's do CLK_IS_CRITICAL flag instead. That has the added benefit of checking to make sure the halt bit toggles correctly so the clks are verified to be enabled. I will submit the next patch for all above-listed clocks with CLK_IS_CRITICAL flag. return qcom_cc_really_probe(pdev, &gcc_sdm845_desc, regmap); } diff --git a/include/dt-bindings/clock/qcom,gcc-sdm845.h b/include/dt-bindings/clock/qcom,gcc-sdm845.h index aca6126..6330c3f 100644 --- a/include/dt-bindings/clock/qcom,gcc-sdm845.h +++ b/include/dt-bindings/clock/qcom,gcc-sdm845.h @@ -13,185 +13,178 @@ #define GCC_AGGRE_USB3_PRIM_AXI_CLK3 #define GCC_AGGRE_USB3_SEC_AXI_CLK 4 #define GCC_BOOT_ROM_AHB_CLK 5 -#define GCC_CAMERA_AHB_CLK 6 Don't do this. Things should only be added to here, not removed or reshuffled. -#define GCC_CAMERA_AXI_CLK 7 -#define GCC_CAMERA_XO_CLK 8 -#define GCC_CE1_AHB_CLK 9 -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[git pull] drm next (msm) + fixes
Hi Linus, I looked at Rob's msm tree, he kept it small due to being late, and it was in -next for a while before he was ill, so I think it should be fine. Otherwise this contains a set of i915 fixes and a v3d build fix, and vc4 leak fix. Thanks, Dave. drm-next-2018-06-11: msm next, i915, vc4, v3d fixes The following changes since commit 568cf2e6aa0c762f14d2d0d481a006f93c63ab7a: Merge tag 'drm-amdkfd-next-2018-05-28' of git://people.freedesktop.org/~gabbayo/linux into drm-next (2018-05-30 11:12:22 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-next-2018-06-11 for you to fetch changes up to 33ce21d6a2491ef9adb8dc395e3f5bbbfcdc95b5: Merge tag 'drm-intel-next-fixes-2018-06-08-2' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2018-06-09 06:34:51 +1000) msm next, i915, vc4, v3d fixes Abhinav Kumar (3): drm/msm/dsi: check return value for video done waits drm/msm/dsi: check video mode engine status before waiting drm/msm/dsi: implement auto PHY timing calculator for 10nm PHY Archit Taneja (3): drm/msm/mdp5: Add global state as a private atomic object drm/msm/mdp5: Use the new private_obj state drm/msm: Don't subclass drm_atomic_state anymore Arnd Bergmann (1): drm/v3d: add CONFIG_MMU dependency Ben Hutchings (1): drm/msm: Fix possible null dereference on failure of get_pages() Changbin Du (2): drm/i915/gvt: Fix the validation on size field of dp aux header drm/i915/kvmgt: Check the pfn got from vfio_pin_pages Chris Wilson (2): drm/i915: Nul-terminate legacy debug string drm/i915: Remove stale asserts from i915_gem_find_active_request() Colin Ian King (1): drm/i915/gvt: fix memory leak of a cmd_entry struct on error exit path Daniel Mack (2): drm/msm: remove unbalanced mutex unlock drm/msm: use correct aspace pointer in msm_gem_put_iova() Dave Airlie (3): Merge tag 'drm-msm-next-2018-06-04' of git://people.freedesktop.org/~robclark/linux into drm-next Merge tag 'drm-misc-next-fixes-2018-05-31' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Merge tag 'drm-intel-next-fixes-2018-06-08-2' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Emil Velikov (1): drm/msm: don't deref error pointer in the msm_fbdev_create error path Eric Anholt (1): drm/vc4: Fix leak of the file_priv that stored the perfmon. Jani Nikula (2): Revert "drm/i915/edp: Allow alternate fixed mode for eDP if available." Merge tag 'gvt-fixes-2018-04-19' of https://github.com/intel/gvt-linux into drm-intel-next-fixes Jeykumar Sankaran (1): drm/msm: Add modifier to mdp_get_format arguments Mahesh Kumar (2): drm/i915/icl: fix icl_unmap/map_plls_to_ports drm/i915/icl: Don't update enabled dbuf slices struct until updated in hw Sean Paul (7): drm/msm: Mark the crtc->state->event consumed drm/msm: Refactor complete_commit() to look more the helpers drm/msm: Move implicit sync handling to prepare_fb drm/msm: Issue queued events when disabling crtc drm/msm: Remove msm_commit/worker, use atomic helper commit drm/msm: Switch to atomic_helper_commit() drm/msm: Fix NULL deref on bind/probe deferral Stefan Agner (1): drm/msm/dsi: use correct enum in dsi_get_cmd_fmt Ville Syrjälä (1): drm/i915: Remove bogus NV12 PLANE_COLOR_CTL setup Xiong Zhang (1): drm/i915/gvt: Dereference msi eventfd_ctx when it isn't used anymore Zhenyu Wang (1): Back merge 'drm-intel-fixes' into gvt-fixes drivers/gpu/drm/i915/gvt/cmd_parser.c | 1 + drivers/gpu/drm/i915/gvt/display.h | 2 +- drivers/gpu/drm/i915/gvt/handlers.c| 13 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 34 +++- drivers/gpu/drm/i915/i915_gem.c| 17 +- drivers/gpu/drm/i915/intel_ddi.c | 6 +- drivers/gpu/drm/i915/intel_display.c | 7 +- drivers/gpu/drm/i915/intel_dp.c| 38 + drivers/gpu/drm/i915/intel_drv.h | 2 - drivers/gpu/drm/i915/intel_dsi.c | 2 +- drivers/gpu/drm/i915/intel_dvo.c | 2 +- drivers/gpu/drm/i915/intel_engine_cs.c | 2 +- drivers/gpu/drm/i915/intel_lvds.c | 3 +- drivers/gpu/drm/i915/intel_panel.c | 6 - drivers/gpu/drm/i915/intel_pm.c| 1 - drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c | 17 +- drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 9 + drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 105 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h | 27 +-- drivers/gpu/drm/msm/disp/mdp5/mdp5_mixer.c | 12 +- drivers/gpu/drm/msm/disp/mdp5/mdp5_pipe.c | 20 ++- drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 16 +- drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c | 17 +- drivers/gpu/drm/msm/ds
Re: [GIT PULL] overlayfs update for 4.18
On Sun, Jun 10, 2018 at 06:54:38AM +0100, Al Viro wrote: > Umm... The worst of yours had been ->pre_mmap(), right? He *did* drop > that... Oh, hadn't notied that. Still odd to change a huge pull request after the end merge window.
[PATCH] microblaze: Remove architecture heart beat code
There is no reason to keep this gpio based code in architecture. Use
ledtrig-heartbeat.c instead which is much more flexible then this
ancient code.
Signed-off-by: Michal Simek
---
arch/microblaze/Kconfig.debug | 7
arch/microblaze/include/asm/setup.h | 3 --
arch/microblaze/kernel/Makefile | 2 --
arch/microblaze/kernel/heartbeat.c | 72 -
arch/microblaze/kernel/timer.c | 7
5 files changed, 91 deletions(-)
delete mode 100644 arch/microblaze/kernel/heartbeat.c
diff --git a/arch/microblaze/Kconfig.debug b/arch/microblaze/Kconfig.debug
index 331a3bb66297..93a737c8d1a6 100644
--- a/arch/microblaze/Kconfig.debug
+++ b/arch/microblaze/Kconfig.debug
@@ -8,11 +8,4 @@ config TRACE_IRQFLAGS_SUPPORT
source "lib/Kconfig.debug"
-config HEART_BEAT
- bool "Heart beat function for kernel"
- default n
- help
- This option turns on/off heart beat kernel functionality.
- First GPIO node is taken.
-
endmenu
diff --git a/arch/microblaze/include/asm/setup.h
b/arch/microblaze/include/asm/setup.h
index d5384f6f36f7..a38e4a56e3c6 100644
--- a/arch/microblaze/include/asm/setup.h
+++ b/arch/microblaze/include/asm/setup.h
@@ -19,9 +19,6 @@
extern char *klimit;
-void microblaze_heartbeat(void);
-void microblaze_setup_heartbeat(void);
-
# ifdef CONFIG_MMU
extern void mmu_reset(void);
# endif /* CONFIG_MMU */
diff --git a/arch/microblaze/kernel/Makefile b/arch/microblaze/kernel/Makefile
index 7e99cf6984a1..3a53378d66d9 100644
--- a/arch/microblaze/kernel/Makefile
+++ b/arch/microblaze/kernel/Makefile
@@ -8,7 +8,6 @@ ifdef CONFIG_FUNCTION_TRACER
CFLAGS_REMOVE_timer.o = -pg
CFLAGS_REMOVE_intc.o = -pg
CFLAGS_REMOVE_early_printk.o = -pg
-CFLAGS_REMOVE_heartbeat.o = -pg
CFLAGS_REMOVE_ftrace.o = -pg
CFLAGS_REMOVE_process.o = -pg
endif
@@ -22,7 +21,6 @@ obj-y += dma.o exceptions.o \
obj-y += cpu/
-obj-$(CONFIG_HEART_BEAT) += heartbeat.o
obj-$(CONFIG_MODULES) += microblaze_ksyms.o module.o
obj-$(CONFIG_MMU) += misc.o
obj-$(CONFIG_STACKTRACE) += stacktrace.o
diff --git a/arch/microblaze/kernel/heartbeat.c
b/arch/microblaze/kernel/heartbeat.c
deleted file mode 100644
index 2022130139d2..
--- a/arch/microblaze/kernel/heartbeat.c
+++ /dev/null
@@ -1,72 +0,0 @@
-/*
- * Copyright (C) 2007-2009 Michal Simek
- * Copyright (C) 2007-2009 PetaLogix
- * Copyright (C) 2006 Atmark Techno, Inc.
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file "COPYING" in the main directory of this archive
- * for more details.
- */
-
-#include
-#include
-#include
-
-#include
-#include
-#include
-
-static unsigned int base_addr;
-
-void microblaze_heartbeat(void)
-{
- static unsigned int cnt, period, dist;
-
- if (base_addr) {
- if (cnt == 0 || cnt == dist)
- out_be32(base_addr, 1);
- else if (cnt == 7 || cnt == dist + 7)
- out_be32(base_addr, 0);
-
- if (++cnt > period) {
- cnt = 0;
- /*
-* The hyperbolic function below modifies the heartbeat
-* period length in dependency of the current (5min)
-* load. It goes through the points f(0)=126, f(1)=86,
-* f(5)=51, f(inf)->30.
-*/
- period = ((672 << FSHIFT) / (5 * avenrun[0] +
- (7 << FSHIFT))) + 30;
- dist = period / 4;
- }
- }
-}
-
-void microblaze_setup_heartbeat(void)
-{
- struct device_node *gpio = NULL;
- int *prop;
- int j;
- const char * const gpio_list[] = {
- "xlnx,xps-gpio-1.00.a",
- NULL
- };
-
- for (j = 0; gpio_list[j] != NULL; j++) {
- gpio = of_find_compatible_node(NULL, NULL, gpio_list[j]);
- if (gpio)
- break;
- }
-
- if (gpio) {
- base_addr = be32_to_cpup(of_get_property(gpio, "reg", NULL));
- base_addr = (unsigned long) ioremap(base_addr, PAGE_SIZE);
- pr_notice("Heartbeat GPIO at 0x%x\n", base_addr);
-
- /* GPIO is configured as output */
- prop = (int *) of_get_property(gpio, "xlnx,is-bidir", NULL);
- if (prop)
- out_be32(base_addr + 4, 0);
- }
-}
diff --git a/arch/microblaze/kernel/timer.c b/arch/microblaze/kernel/timer.c
index 7de941cbbd94..a6683484b3a1 100644
--- a/arch/microblaze/kernel/timer.c
+++ b/arch/microblaze/kernel/timer.c
@@ -156,9 +156,6 @@ static inline void timer_ack(void)
static irqreturn_t timer_interrupt(int irq, void *dev_id)
{
struct clock_event_device *evt = &clockevent_xilinx_timer;
-#ifdef CONFIG_HEART_BEAT
- microblaze
Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset
* Faiz Abbas [180611 06:09]:
> Hi Tony,
>
> On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:
> > * Faiz Abbas [180607 10:24]:
> >> Hi,
> >>
> >> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
> >>> * Faiz Abbas [180606 06:14]:
> +static int sysc_reset(struct sysc *ddata)
> +{
> +int offset = ddata->offsets[SYSC_SYSCONFIG];
> +int val = sysc_read(ddata, offset);
> +
> +val |= (0x1 << ddata->cap->regbits->srst_shift);
> +sysc_write(ddata, offset, val);
> +
> +/* Poll on reset status */
> +if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
> +offset = ddata->offsets[SYSC_SYSSTATUS];
> +
> +return readl_poll_timeout(ddata->module_va + offset,
> val,
> +(val & ddata->cfg.syss_mask) == 0x0,
> +100, MAX_MODULE_SOFTRESET_WAIT);
> +}
> +
> +return 0;
> +}
> >>>
> >>> I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
> >>> addition to SYSC_QUIRK_RESET status to make it easy to
> >>> read the right register?
> >>
> >> I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
> >> the register. Are there layouts in which the reset status bit is in the
> >> sysconfig register rather than the sysstatus register?
> >
> > Yes we can have reset status bit in either syss or syssconfig register.
>
> You mean sysstatus and sysconfig right?
Yup.
> > We detect that in sysc_init_syss_mask() but we should also set something
> > at that point to make it clear which reset to use. But as we don't need
> > the quirk flag, it's probably set a function pointer after the detection.
> > So how about let's have two functions sysc_reset() and sysc_syss_reset()
> > and then we can implement sysc_syss_reset() in a separate patch after
> > testing it when we have a non-platform data using example for
> > sysc_syss_reset().
> >
>
> Shouldn't the function I add be called sysc_syss_reset()? The reset
> status bit is in the sysstatus.
Yes
Tony
Re: [GIT PULL] overlayfs update for 4.18
On Sat, Jun 09, 2018 at 02:42:20PM -0700, Linus Torvalds wrote: > And Christoph's copmmentary isn't really helping the situation. > Christoph, I haven't seen the NAK history, can you elaborate? Most of the bits just need a bit of refinement I think, instead of being forced through the overlayfs tree and are generally fine. The pre_mmap hook I think is a clear no-go. We've had this tried multiple times and always rejected it. Unlike previous uses the overlayfs use isn't outright broken, but still questionalable as it will still lead to a copyup that "leaks" if the actual mmap wasn't successfull. The whole discussion of how mmap happens, how we deal with mmap_sem and failures needs a broader discussion with all MM and VFS folks first.
[PATCH 1/2] pwm: pwm-tiehrpwm: Don't use emulation mode bits to control PWM output
As per AM335x TRM SPRUH73P "15.2.2.11 ePWM Behavior During Emulation",
TBCTL[15:14] only have effect during emulation suspend events (IOW,
to stop PWM when debugging using a debugger). These bits have no effect
on PWM output during normal running of system. Hence, remove code
accessing these bits as they have no role in enabling/disabling PWMs.
Fixes: 19891b20e7c2 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM")
Cc: sta...@vger.kernel.org
Signed-off-by: Vignesh R
---
drivers/pwm/pwm-tiehrpwm.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
index 4c22cb395040..768176f54d5e 100644
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@ -33,10 +33,6 @@
#define TBCTL 0x00
#define TBPRD 0x0A
-#define TBCTL_RUN_MASK (BIT(15) | BIT(14))
-#define TBCTL_STOP_NEXT0
-#define TBCTL_STOP_ON_CYCLEBIT(14)
-#define TBCTL_FREE_RUN (BIT(15) | BIT(14))
#define TBCTL_PRDLD_MASK BIT(3)
#define TBCTL_PRDLD_SHDW 0
#define TBCTL_PRDLD_IMDT BIT(3)
@@ -360,7 +356,7 @@ static int ehrpwm_pwm_enable(struct pwm_chip *chip, struct
pwm_device *pwm)
/* Channels polarity can be configured from action qualifier module */
configure_polarity(pc, pwm->hwpwm);
- /* Enable TBCLK before enabling PWM device */
+ /* Enable TBCLK */
ret = clk_enable(pc->tbclk);
if (ret) {
dev_err(chip->dev, "Failed to enable TBCLK for %s: %d\n",
@@ -368,9 +364,6 @@ static int ehrpwm_pwm_enable(struct pwm_chip *chip, struct
pwm_device *pwm)
return ret;
}
- /* Enable time counter for free_run */
- ehrpwm_modify(pc->mmio_base, TBCTL, TBCTL_RUN_MASK, TBCTL_FREE_RUN);
-
return 0;
}
@@ -400,9 +393,6 @@ static void ehrpwm_pwm_disable(struct pwm_chip *chip,
struct pwm_device *pwm)
/* Disabling TBCLK on PWM disable */
clk_disable(pc->tbclk);
- /* Stop Time base counter */
- ehrpwm_modify(pc->mmio_base, TBCTL, TBCTL_RUN_MASK, TBCTL_STOP_NEXT);
-
/* Disable clock on PWM disable */
pm_runtime_put_sync(chip->dev);
}
--
2.17.1
[PATCH 0/2] pwm-tiehrpwm: fixes for disabling PWMs
EHRPWM has two PWM outputs. Currently with pwm-tiehrpwm driver, if PWMA is enabled and then disabled, and then PWMB is enabled, it is seen that PWMA turns on automatically. This series fixes the bug. Vignesh R (2): pwm: pwm-tiehrpwm: Don't use emulation mode bits to control PWM output pwm: pwm-tiehrpwm: Fix disabling of output of PWMs drivers/pwm/pwm-tiehrpwm.c | 14 +++--- 1 file changed, 3 insertions(+), 11 deletions(-) -- 2.17.1
[PATCH 2/2] pwm: pwm-tiehrpwm: Fix disabling of output of PWMs
pwm-tiehrpwm driver disables PWM output by putting it in low output
state via active AQCSFRC register in ehrpwm_pwm_disable(). But, the
AQCSFRC shadow register is not updated. Therefore, when shadow AQCSFRC
register is re-enabled in ehrpwm_pwm_enable() (say to enable second PWM
output), previous settings are lost as shadow register value is loaded
into active register. This results in things like PWMA getting enabled
automatically, when PWMB is enabled and vice versa. Fix this by
updating AQCSFRC shadow register as well during ehrpwm_pwm_disable().
Fixes: 19891b20e7c2 ("pwm: pwm-tiehrpwm: PWM driver support for EHRPWM")
Cc: sta...@vger.kernel.org
Signed-off-by: Vignesh R
---
drivers/pwm/pwm-tiehrpwm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
index 768176f54d5e..f7b8a86fa5c5 100644
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@ -381,6 +381,8 @@ static void ehrpwm_pwm_disable(struct pwm_chip *chip,
struct pwm_device *pwm)
aqcsfrc_mask = AQCSFRC_CSFA_MASK;
}
+ /* Update shadow register first before modifying active register */
+ ehrpwm_modify(pc->mmio_base, AQCSFRC, aqcsfrc_mask, aqcsfrc_val);
/*
* Changes to immediate action on Action Qualifier. This puts
* Action Qualifier control on PWM output from next TBCLK
--
2.17.1
Re: [PATCH] mfd: cros_ec: remove unused __remove function
On Fri, 08 Jun 2018, Benson Leung wrote:
>
> On Fri, Jun 08, 2018 at 04:48:06PM +0200, Arnd Bergmann wrote:
> > This function is no longer called, so we get a harmless
> > warning until it is removed as well:
> >
> > drivers/mfd/cros_ec_dev.c:265:13: error: '__remove' defined but not used
> > [-Werror=unused-function]
> >
> > Fixes: 3aa2177e4787 ("mfd: cros_ec: Use devm_kzalloc for private data")
>
> Gwendal, in PATCH v2 of https://patchwork.kernel.org/patch/10439449/
> you mentioned that you readded the __remove to avoid a warning when built
> as a module. Can you explain what's going on?
Yes please, and quickly. I'm going to sent the patch-set today. If I
don't hear from you promptly, I'll probably pull the patch!
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset
Hi Tony,
On Friday 08 June 2018 11:51 AM, Tony Lindgren wrote:
> * Faiz Abbas [180607 10:24]:
>> Hi,
>>
>> On Thursday 07 June 2018 01:05 PM, Tony Lindgren wrote:
>>> * Faiz Abbas [180606 06:14]:
+static int sysc_reset(struct sysc *ddata)
+{
+ int offset = ddata->offsets[SYSC_SYSCONFIG];
+ int val = sysc_read(ddata, offset);
+
+ val |= (0x1 << ddata->cap->regbits->srst_shift);
+ sysc_write(ddata, offset, val);
+
+ /* Poll on reset status */
+ if (ddata->cfg.quirks & SYSC_QUIRK_RESET_STATUS) {
+ offset = ddata->offsets[SYSC_SYSSTATUS];
+
+ return readl_poll_timeout(ddata->module_va + offset, val,
+ (val & ddata->cfg.syss_mask) == 0x0,
+ 100, MAX_MODULE_SOFTRESET_WAIT);
+ }
+
+ return 0;
+}
>>>
>>> I wonder if we should also add SYSS_QUIRK_RESET_STATUS in
>>> addition to SYSC_QUIRK_RESET status to make it easy to
>>> read the right register?
>>
>> I assumed SYSC_QUIRK is the prefix to indicate the ti-sysc driver not
>> the register. Are there layouts in which the reset status bit is in the
>> sysconfig register rather than the sysstatus register?
>
> Yes we can have reset status bit in either syss or syssconfig register.
You mean sysstatus and sysconfig right?
> We detect that in sysc_init_syss_mask() but we should also set something
> at that point to make it clear which reset to use. But as we don't need
> the quirk flag, it's probably set a function pointer after the detection.
> So how about let's have two functions sysc_reset() and sysc_syss_reset()
> and then we can implement sysc_syss_reset() in a separate patch after
> testing it when we have a non-platform data using example for
> sysc_syss_reset().
>
Shouldn't the function I add be called sysc_syss_reset()? The reset
status bit is in the sysstatus.
Thanks,
Faiz
Re: [PATCH v7 0/6] Add ChromeOS EC CEC Support
On Fri, 08 Jun 2018, Hans Verkuil wrote: > On 08/06/18 10:17, Neil Armstrong wrote: > > On 08/06/2018 09:53, Hans Verkuil wrote: > >> On 06/01/2018 10:19 AM, Neil Armstrong wrote: > >>> Hi All, > >>> > >>> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support > >>> through it's Embedded Controller, to enable the Linux CEC Core to > >>> communicate > >>> with it and get the CEC Physical Address from the correct HDMI Connector, > >>> the > >>> following must be added/changed: > >>> - Add the CEC sub-device registration in the ChromeOS EC MFD Driver > >>> - Add the CEC related commands and events definitions into the EC MFD > >>> driver > >>> - Add a way to get a CEC notifier with it's (optional) connector name > >>> - Add the CEC notifier to the i915 HDMI driver > >>> - Add the proper ChromeOS EC CEC Driver > >>> > >>> The CEC notifier with the connector name is the tricky point, since even > >>> on > >>> Device-Tree platforms, there is no way to distinguish between multiple > >>> HDMI > >>> connectors from the same DRM driver. The solution I implemented is pretty > >>> simple and only adds an optional connector name to eventually distinguish > >>> an HDMI connector notifier from another if they share the same device. > >> > >> This looks good to me, which brings me to the next question: how to merge > >> this? > >> > >> It touches on three subsystems (media, drm, mfd), so that makes this > >> tricky. > >> > >> I think there are two options: either the whole series goes through the > >> media tree, or patches 1+2 go through drm and 3-6 through media. If there > >> is a high chance of conflicts in the mfd code, then it is also an option to > >> have patches 3-6 go through the mfd subsystem. > > > > I think patches 3-6 should go in the mfd tree, Lee is used to handle this, > > then I think the rest could go in the media tree. > > > > Lee, do you think it would be possible to have an immutable branch with > > patches 3-6 ? > > > > Could we have an immutable branch from media tree with patch 1 to be merged > > in > > the i915 tree for patch 2 ? > > > > Or patch 1+2 could me merged into the i915 tree and generate an immutable > > branch > > I think patches 1+2 can just go to the i915 tree. The i915 driver changes > often, > so going through that tree makes sense. The cec-notifier code is unlikely to > change, > and I am fine with that patch going through i915. > > > for media to merge the mfd branch + patch 7 ? > > Patch 7? I only count 6? > > If 1+2 go through drm and 3-6 go through mfd, then media isn't affected at > all. > There is chance of a conflict when this is eventually pushed to mainline for > the media Kconfig, but that's all. What are the *build* dependencies within the set? I'd be happy to send out a pull-request for either all of the patches, or just the MFD changes once I've had chance to review them. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: WARNING: kmalloc bug in xdp_umem_create
On Sun, Jun 10, 2018 at 3:03 PM, Björn Töpel wrote:
>> On 2018/06/10 20:52, Dmitry Vyukov wrote:
>> > On Sun, Jun 10, 2018 at 11:31 AM, Björn Töpel
>> > wrote:
>> >> Den sön 10 juni 2018 kl 04:53 skrev Tetsuo Handa
>> >> :
>> >>>
>> >>> On 2018/06/10 7:47, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:7d3bf613e99a Merge tag 'libnvdimm-for-4.18' of
>> git://git.k..
>> git tree: upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1073f68f80
>> kernel config:
>> https://syzkaller.appspot.com/x/.config?x=f04d8d0a2afb789a
>> dashboard link:
>> https://syzkaller.appspot.com/bug?extid=4abadc5d69117b346506
>> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>> syzkaller
>> repro:https://syzkaller.appspot.com/x/repro.syz?x=13c9756f80
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16366f9f80
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the
>> commit:
>> Reported-by: syzbot+4abadc5d69117b346...@syzkaller.appspotmail.com
>>
>> random: sshd: uninitialized urandom read (32 bytes read)
>> random: sshd: uninitialized urandom read (32 bytes read)
>> random: sshd: uninitialized urandom read (32 bytes read)
>> random: sshd: uninitialized urandom read (32 bytes read)
>> random: sshd: uninitialized urandom read (32 bytes read)
>> WARNING: CPU: 1 PID: 4537 at mm/slab_common.c:996
>> kmalloc_slab+0x56/0x70 mm/slab_common.c:996
>> Kernel panic - not syncing: panic_on_warn set ...
>> >>>
>> >>> syzbot gave up upon kmalloc(), but actually error handling path has
>> >>> NULL pointer dereference bug.
>> >>>
>> >>
>> >> Thanks Tetsuo! This crash has been fixed by Daniel Borkmann in commit
>> >> c09290c56376 ("bpf, xdp: fix crash in xdp_umem_unaccount_pages").
>> >
>> > Let's tell syzbot about this:
>> >
>> > #syz fix: bpf, xdp: fix crash in xdp_umem_unaccount_pages
>> >
>> >
>> Excuse me, but that patch fixes NULL pointer dereference which occurs after
>> kmalloc()'s
>> "WARNING: CPU: 1 PID: 4537 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70
>> mm/slab_common.c:996"
>> message. That is, "Too large memory allocation" itself is not yet fixed.
>
> The code relies on that the sl{u,a,o}b layer says no, and the
> setsockopt bails out. The warning could be opted out using
> __GFP_NOWARN. Is there another preferred way? Two get_user_pages
> calls, where the first call would set pages to NULL just to fault the
> region? Walk the process' VMAs? Something else?
Hi Björn,
Yes, either __GFP_NOWARN for allocations with user-controllable size
or stricter custom limit (if we don't want current sla/u/ob
implementation details to be part of public kernel interface).
arch/microblaze/kernel/heartbeat.c:17:10: fatal error: asm/prom.h: No such file or directory
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f0dc7f9c6dd99891611fca5849cbc4c6965b690e commit: 96f0e6fcc9add1f063984be32073fe8b1d39b664 microblaze: remove redundant early_printk support date: 7 weeks ago config: microblaze-allyesconfig (attached as .config) compiler: microblaze-linux-gcc (GCC) 8.1.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 96f0e6fcc9add1f063984be32073fe8b1d39b664 # save the attached .config to linux build tree GCC_VERSION=8.1.0 make.cross ARCH=microblaze All errors (new ones prefixed by >>): >> arch/microblaze/kernel/heartbeat.c:17:10: fatal error: asm/prom.h: No such >> file or directory #include ^~~~ compilation terminated. vim +17 arch/microblaze/kernel/heartbeat.c ecc6dfc8 Michal Simek 2009-03-27 14 ecc6dfc8 Michal Simek 2009-03-27 15 #include ecc6dfc8 Michal Simek 2009-03-27 16 #include ecc6dfc8 Michal Simek 2009-03-27 @17 #include ecc6dfc8 Michal Simek 2009-03-27 18 :: The code at line 17 was first introduced by commit :: ecc6dfc8adfc76d323c513bc88cb260344c11139 microblaze_v8: heartbeat file :: TO: Michal Simek :: CC: Michal Simek --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
WARNING in destroy_workqueue
Hello, syzbot found the following crash on: HEAD commit:a16afaf7928b Merge tag 'for-v4.18' of git://git.kernel.org.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=15f66f9f80 kernel config: https://syzkaller.appspot.com/x/.config?x=314f2150f36c16ca dashboard link: https://syzkaller.appspot.com/bug?extid=ed2b6bee3bb95389611d compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+ed2b6bee3bb953896...@syzkaller.appspotmail.com 3ed4096b: 00 00 00 00 00 ec 00 00 0c 09 0a 02 0c 00 00 00 XFS (loop5): SB validate failed with error -117. binder: 21818:21820 ioctl 40046207 0 returned -16 binder: 21818:21861 ioctl c0306201 2040 returned -22 binder: 21818:21820 BC_CLEAR_DEATH_NOTIFICATION death notification cookie mismatch != 0002 WARNING: CPU: 0 PID: 21819 at kernel/workqueue.c:4155 destroy_workqueue+0x2d2/0x9b0 kernel/workqueue.c:4155 binder: 21818:21864 ioctl 8 2000 returned -22 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 21819 Comm: syz-executor5 Not tainted 4.17.0+ #93 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b9/0x294 lib/dump_stack.c:113 panic+0x22f/0x4de kernel/panic.c:184 binder_alloc: 21818: binder_alloc_buf, no vma __warn.cold.8+0x163/0x1b3 kernel/panic.c:536 report_bug+0x252/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992 RIP: 0010:destroy_workqueue+0x2d2/0x9b0 kernel/workqueue.c:4155 Code: binder: 21818:21820 transaction failed 29189/-3, size 0-0 line 2967 0f 8e fe 05 00 00 48 8b 85 30 binder: undelivered TRANSACTION_ERROR: 29189 fe binder: undelivered TRANSACTION_ERROR: 29201 ff ff bf 01 00 00 00 8b 58 18 89 de e8 6c c4 2a 00 83 fb 01 0f 8e 91 00 00 00 e8 4e c3 2a 00 <0f> 0b e8 47 c3 2a 00 48 8b bd 18 fe ff ff e8 ab 13 32 06 e8 46 f3 RSP: 0018:8801b61276b0 EFLAGS: 00010216 RAX: 0004 RBX: 0002 RCX: c900036a8000 RDX: 0002824e RSI: 814f7a12 RDI: 0005 RBP: 8801b61278a0 R08: 8801c6fa6680 R09: ed003b5c46d6 R10: ed003b5c46d6 R11: 8801dae236b3 R12: 000f R13: dc00 R14: 8801d653cd40 R15: xfs_destroy_mount_workqueues+0x171/0x1c0 fs/xfs/xfs_super.c:936 xfs_fs_fill_super+0xa10/0x1700 fs/xfs/xfs_super.c:1777 mount_bdev+0x30c/0x3e0 fs/super.c:1174 xfs_fs_mount+0x34/0x40 fs/xfs/xfs_super.c:1825 mount_fs+0xae/0x328 fs/super.c:1277 vfs_kern_mount.part.34+0xd4/0x4d0 fs/namespace.c:1037 vfs_kern_mount fs/namespace.c:1027 [inline] do_new_mount fs/namespace.c:2518 [inline] do_mount+0x564/0x30b0 fs/namespace.c:2848 ksys_mount+0x12d/0x140 fs/namespace.c:3064 __do_sys_mount fs/namespace.c:3078 [inline] __se_sys_mount fs/namespace.c:3075 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3075 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x45842a Code: b8 a6 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 dd 8f fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 ba 8f fb ff c3 66 0f 1f 84 00 00 00 00 00 RSP: 002b:7f367396bba8 EFLAGS: 0202 ORIG_RAX: 00a5 RAX: ffda RBX: 2180 RCX: 0045842a RDX: 2180 RSI: 2140 RDI: 7f367396bbf0 RBP: 0001 R08: 2040 R09: 2180 R10: R11: 0202 R12: 0013 R13: 0001 R14: 004d2d70 R15: Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot.
KASAN: use-after-free Read in getname_kernel
Hello, syzbot found the following crash on: HEAD commit:3ca24ce9ff76 Merge branch 'proc-cmdline' git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=15ed37d780 kernel config: https://syzkaller.appspot.com/x/.config?x=314f2150f36c16ca dashboard link: https://syzkaller.appspot.com/bug?extid=abf707d7ccbb3244f34e compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+abf707d7ccbb3244f...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in memcpy include/linux/string.h:345 [inline] BUG: KASAN: use-after-free in getname_kernel+0x123/0x370 fs/namei.c:241 Read of size 11 at addr 8801d8053310 by task syz-executor5/15925 CPU: 0 PID: 15925 Comm: syz-executor5 Not tainted 4.17.0+ #94 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b9/0x294 lib/dump_stack.c:113 print_address_description+0x6c/0x20b mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412 check_memory_region_inline mm/kasan/kasan.c:260 [inline] check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267 memcpy+0x23/0x50 mm/kasan/kasan.c:302 memcpy include/linux/string.h:345 [inline] getname_kernel+0x123/0x370 fs/namei.c:241 kern_path+0x1e/0x40 fs/namei.c:2410 lookup_bdev+0xfa/0x240 fs/block_dev.c:2084 blkdev_get_by_path+0x1f/0xe0 fs/block_dev.c:1687 btrfs_get_bdev_and_sb+0x38/0x300 fs/btrfs/volumes.c:392 btrfs_open_one_device fs/btrfs/volumes.c:695 [inline] open_fs_devices+0x6a5/0xc60 fs/btrfs/volumes.c:1112 btrfs_open_devices+0xc0/0xd0 fs/btrfs/volumes.c:1155 btrfs_mount_root+0x91f/0x1e70 fs/btrfs/super.c:1568 mount_fs+0xae/0x328 fs/super.c:1277 vfs_kern_mount.part.34+0xd4/0x4d0 fs/namespace.c:1037 vfs_kern_mount+0x40/0x60 fs/namespace.c:1027 btrfs_mount+0x4a1/0x213e fs/btrfs/super.c:1661 mount_fs+0xae/0x328 fs/super.c:1277 vfs_kern_mount.part.34+0xd4/0x4d0 fs/namespace.c:1037 vfs_kern_mount fs/namespace.c:1027 [inline] do_new_mount fs/namespace.c:2518 [inline] do_mount+0x564/0x30b0 fs/namespace.c:2848 ksys_mount+0x12d/0x140 fs/namespace.c:3064 __do_sys_mount fs/namespace.c:3078 [inline] __se_sys_mount fs/namespace.c:3075 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3075 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x45842a Code: b8 a6 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 dd 8f fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 ba 8f fb ff c3 66 0f 1f 84 00 00 00 00 00 RSP: 002b:7fe10e408ba8 EFLAGS: 0202 ORIG_RAX: 00a5 RAX: ffda RBX: 2080 RCX: 0045842a RDX: 2080 RSI: 2100 RDI: 7fe10e408bf0 RBP: 0001 R08: 2240 R09: 2080 R10: R11: 0202 R12: 0014 R13: 0001 R14: 004d2bc0 R15: Allocated by task 15908: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553 __do_kmalloc mm/slab.c:3718 [inline] __kmalloc+0x14e/0x760 mm/slab.c:3727 kmalloc include/linux/slab.h:518 [inline] kzalloc include/linux/slab.h:706 [inline] rcu_string_strdup fs/btrfs/rcu-string.h:17 [inline] btrfs_prepare_close_one_device fs/btrfs/volumes.c:1031 [inline] close_fs_devices+0x497/0xfa0 fs/btrfs/volumes.c:1052 btrfs_close_devices+0x29/0x150 fs/btrfs/volumes.c:1085 open_ctree+0x589/0x7898 fs/btrfs/disk-io.c:3358 btrfs_fill_super fs/btrfs/super.c:1202 [inline] btrfs_mount_root+0x16df/0x1e70 fs/btrfs/super.c:1593 mount_fs+0xae/0x328 fs/super.c:1277 vfs_kern_mount.part.34+0xd4/0x4d0 fs/namespace.c:1037 vfs_kern_mount+0x40/0x60 fs/namespace.c:1027 btrfs_mount+0x4a1/0x213e fs/btrfs/super.c:1661 mount_fs+0xae/0x328 fs/super.c:1277 vfs_kern_mount.part.34+0xd4/0x4d0 fs/namespace.c:1037 vfs_kern_mount fs/namespace.c:1027 [inline] do_new_mount fs/namespace.c:2518 [inline] do_mount+0x564/0x30b0 fs/namespace.c:2848 ksys_mount+0x12d/0x140 fs/namespace.c:3064 __do_sys_mount fs/namespace.c:3078 [inline] __se_sys_mount fs/namespace.c:3075 [inline] __x64_sys_mount+0xbe/0x150 fs/namespace.c:3075 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 15922: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kfree+0xd9/0x260 mm/slab.c:3813 __rcu_reclaim kernel/rcu/rcu.h:173 [inline] rcu_do_batch ker
Re: [PATCH v2 2/3] ASoC: simple-card: move hp and mic detection to soc_card probe
Hi Katsuhiro > > > This patch moves headphone and microphone detection to probe() of > > > snd_soc_card from init() of snd_soc_dai_link. This is because init() > > > is called (and an input device /dev/input/eventX is created too) > > > twice or above if simple card has two or more DAI links. (snip) > It seems if simple card has multiple DAI links, it creates multiple input > devices. > > For example simple card has 3-links, 3 input devices /dev/input/event0, > event1, event2 are created. Is it correct? Oh, I see, fair enough. I'm sorry, it was my English skill error. Best regards --- Kuninori Morimoto
Re: [PATCH] arm: Initialize hrtimer-based broadcast clockevent
On 2018-04-04 17:54, Jan Kiszka wrote: > On 2018-03-01 07:04, Jan Kiszka wrote: >> On 2018-01-22 07:06, Jan Kiszka wrote: >>> Analogously to 9358d755bd5c, this registers a broadcast clockevent in >>> case no hardware broadcast timer is available and the per-CPU timers can >>> be stopped in deep power states. >>> >>> Partitions of the Jailhouse hypervisor fall in this category. >>> Registering the workaround timer allows to enter high-resolution mode in >>> that case. >>> >>> Signed-off-by: Jan Kiszka >>> --- >>> arch/arm/kernel/time.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c >>> index 629f8e9981f1..0a45d861ef8e 100644 >>> --- a/arch/arm/kernel/time.c >>> +++ b/arch/arm/kernel/time.c >>> @@ -12,6 +12,7 @@ >>> * reading the RTC at bootup, etc... >>> */ >>> #include >>> +#include >>> #include >>> #include >>> #include >>> @@ -121,5 +122,7 @@ void __init time_init(void) >>> of_clk_init(NULL); >>> #endif >>> timer_probe(); >>> + >>> + tick_setup_hrtimer_broadcast(); >>> } >>> } >>> >> >> Gentle ping, just to avoid that this falls through the cracks because >> it's so small. >> > > 2nd ping. Should this patch be routed via ARM or rather some tip/timers > tree? > 3rd try: Could someone have a look at this and merge it - or at least ack it in order to move forward? Thanks, Jan
Re: [PATCH v2 2/3] ASoC: simple-card: move hp and mic detection to soc_card probe
Hello Morimoto-san, > -Original Message- > From: Kuninori Morimoto > Sent: Monday, June 11, 2018 2:27 PM > To: Suzuki, Katsuhiro > Cc: Mark Brown ; alsa-de...@alsa-project.org; Masami Hiramatsu > ; Jassi Brar ; > linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v2 2/3] ASoC: simple-card: move hp and mic detection to soc_card > probe > > > Hi Katsuhiro-san > > > This patch moves headphone and microphone detection to probe() of > > snd_soc_card from init() of snd_soc_dai_link. This is because init() > > is called (and an input device /dev/input/eventX is created too) > > twice or above if simple card has two or more DAI links. > > > > Signed-off-by: Katsuhiro Suzuki > > or above ? > It seems if simple card has multiple DAI links, it creates multiple input devices. For example simple card has 3-links, 3 input devices /dev/input/event0, event1, event2 are created. Is it correct? > > - ret = asoc_simple_card_init_hp(rtd->card, &priv->hp_jack, PREFIX); > > - if (ret < 0) > > - return ret; > > - > > - ret = asoc_simple_card_init_mic(rtd->card, &priv->mic_jack, PREFIX); > > - if (ret < 0) > > - return ret; > (snip) > > + ret = asoc_simple_card_init_hp(card, &priv->hp_jack, NULL); > > + if (ret < 0) > > + return ret; > > + > > + ret = asoc_simple_card_init_mic(card, &priv->mic_jack, NULL); > > + if (ret < 0) > > + return ret; > > I think we want to keep "PREFIX" ? > Oops... Thank you. I'll fix it. Regards, -- Katsuhiro Suzuki > > Best regards > --- > Kuninori Morimoto
Re: [PATCH v3 1/3] cpufreq: imx6q: check speed grades for i.MX6ULL
On Tue, May 22, 2018 at 08:28:51AM +0200, Sébastien Szymanski wrote: > Check the max speed supported from the fuses for i.MX6ULL and update the > operating points table accordingly. > > Signed-off-by: Sébastien Szymanski Acked-by: Shawn Guo
Re: [PATCH v2 2/3] ASoC: simple-card: move hp and mic detection to soc_card probe
Hi Katsuhiro-san > This patch moves headphone and microphone detection to probe() of > snd_soc_card from init() of snd_soc_dai_link. This is because init() > is called (and an input device /dev/input/eventX is created too) > twice or above if simple card has two or more DAI links. > > Signed-off-by: Katsuhiro Suzuki or above ? > - ret = asoc_simple_card_init_hp(rtd->card, &priv->hp_jack, PREFIX); > - if (ret < 0) > - return ret; > - > - ret = asoc_simple_card_init_mic(rtd->card, &priv->mic_jack, PREFIX); > - if (ret < 0) > - return ret; (snip) > + ret = asoc_simple_card_init_hp(card, &priv->hp_jack, NULL); > + if (ret < 0) > + return ret; > + > + ret = asoc_simple_card_init_mic(card, &priv->mic_jack, NULL); > + if (ret < 0) > + return ret; I think we want to keep "PREFIX" ? Best regards --- Kuninori Morimoto
[PATCH] net: dsa: add error handling for pskb_trim_rcsum
When pskb_trim_rcsum fails, the lack of error-handling code may cause unexpected results. This patch adds error-handling code after calling pskb_trim_rcsum. Signed-off-by: Zhouyang Jia --- net/dsa/tag_trailer.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/dsa/tag_trailer.c b/net/dsa/tag_trailer.c index 7d20e1f..56197f0 100644 --- a/net/dsa/tag_trailer.c +++ b/net/dsa/tag_trailer.c @@ -75,7 +75,8 @@ static struct sk_buff *trailer_rcv(struct sk_buff *skb, struct net_device *dev, if (!skb->dev) return NULL; - pskb_trim_rcsum(skb, skb->len - 4); + if (pskb_trim_rcsum(skb, skb->len - 4)) + return NULL; return skb; } -- 2.7.4
Re: [PATCH 4.16 01/48] mmap: introduce sane default mmap limits
On Mon, Jun 11, 2018 at 08:12:45AM +1000, David Airlie wrote: > Can you make sure you pull in > > 76ef6b28ea4f81c3d511866a9b31392caa833126 (tag: > drm-fixes-for-v4.17-rc6-urgent) > Author: Dave Airlie > Date: Tue May 15 13:38:15 2018 +1000 > > drm: set FMODE_UNSIGNED_OFFSET for drm files > > Into anywhere this first patch goes? Thanks for pointing this out, now queued up. greg k-h
Re: [PATCH] ARM: dts: imx51-zii-rdu1: add rave-sp subdevices
On Thu, May 17, 2018 at 10:19:23PM +0300, Nikita Yushchenko wrote:
> This adds rave-sp powerbutton and backlight devices to RDU1 device tree.
>
> Signed-off-by: Nikita Yushchenko
> ---
> arch/arm/boot/dts/imx51-zii-rdu1.dts | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts
> b/arch/arm/boot/dts/imx51-zii-rdu1.dts
> index 0c99ac04ad08..98cc107098e0 100644
> --- a/arch/arm/boot/dts/imx51-zii-rdu1.dts
> +++ b/arch/arm/boot/dts/imx51-zii-rdu1.dts
> @@ -581,6 +581,14 @@
> watchdog {
> compatible = "zii,rave-sp-watchdog";
> };
> +
> + backlight {
> + compatible = "zii,rave-sp-backlight";
> + };
> +
> + pwrbutton {
> + compatible = "zii,rave-sp-pwrbutton";
> + };
Where are these compatibles documented?
Shawn
> };
> };
>
> --
> 2.11.0
>
[PATCH] Input: add error handling for da9052_reg_write
When da9052_reg_write fails, the lack of error-handling code may
cause unexpected results.
This patch adds error-handling code after calling da9052_reg_write.
Signed-off-by: Zhouyang Jia
---
drivers/input/touchscreen/da9052_tsi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/da9052_tsi.c
b/drivers/input/touchscreen/da9052_tsi.c
index b5dfd594..60c82a0 100644
--- a/drivers/input/touchscreen/da9052_tsi.c
+++ b/drivers/input/touchscreen/da9052_tsi.c
@@ -319,8 +319,11 @@ static int da9052_ts_probe(struct platform_device *pdev)
static int da9052_ts_remove(struct platform_device *pdev)
{
struct da9052_tsi *tsi = platform_get_drvdata(pdev);
+ int error;
- da9052_reg_write(tsi->da9052, DA9052_LDO9_REG, 0x19);
+ error = da9052_reg_write(tsi->da9052, DA9052_LDO9_REG, 0x19);
+ if (error < 0)
+ return error;
da9052_free_irq(tsi->da9052, DA9052_IRQ_TSIREADY, tsi);
da9052_free_irq(tsi->da9052, DA9052_IRQ_PENDOWN, tsi);
--
2.7.4
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
> On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote: > > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen > wrote: >> >> The Launch Enclave (LE) generates cryptographic launch tokens for user >> enclaves. A launch token is used by EINIT to check whether the enclave >> is authorized to launch or not. By having its own launch enclave, Linux >> has full control of the enclave launch process. >> >> LE is wrapped into a user space proxy program that reads enclave >> signatures outputs launch tokens. The kernel-side glue code is >> implemented by using the user space helper framework. The IPC between >> the LE proxy program and kernel is handled with an anonymous inode. >> >> The commit also adds enclave signing tool that is used by kbuild to >> measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY points >> to a PEM-file for the 3072-bit RSA key that is used as the LE public key >> pair. The default location is: >> >> drivers/platform/x86/intel_sgx/sgx_signing_key.pem >> >> If the default key does not exist kbuild will generate a random key and >> place it to this location. KBUILD_SGX_SIGN_PIN can be used to specify >> the passphrase for the LE public key. > > It seems to me that it might be more useful to just commit a key pair > into the kernel. As far as I know, there is no security whatsoever > gained by keeping the private key private, so why not make > reproducible builds easier by simply fixing the key? Having thought about this some more, I think that you should completely remove support for specifying a key. Provide a fixed key pair, hard code the cache, and call it a day. If you make the key configurable, every vendor that has any vendor keys (Debian, Ubuntu, Fedora, Red Hat, SuSE, Clear Linux, etc) will see that config option and set up their own key pair for no gain whatsoever. Instead, it'll give some illusion of security and it'll slow down operations in a VM guest due to swapping out the values of the MSRs. And, if the code to support a locked MSR that just happens to have the right value stays in the kernel, then we'll risk having vendors actually ship one distro's public key hash, and that will seriously suck. I'm going to try to get this code working tomorrow. I'll keep you posted on how that goes. Can you point me to the userspace bits (i.e. something buildable that will run on a kernel with your patches applied)? > > Also, this email is so long that gmail won't let me quote the relevant > code, but: what is the intended use case for supporting the mode where > the MSRs are locked but happen to contain the right value? I could > see the case for bundling a key with the kernel and literally > hard-coding the acceptable MSR values (as in literal values in the > code, not even autogenerated hashes). The only use case I've thought > of for the code as it stands is that $VENDOR could publish their LE > public key and some daft firmware vendor could get it into their head > that it would be a good idea to lock the MSRs to that value. This > would add no security at all, but it would add a considerable about of > annoyance and loss of value, so I still tend to think that we > shouldn't support it.
[PATCH v2 2/3] ASoC: simple-card: move hp and mic detection to soc_card probe
This patch moves headphone and microphone detection to probe() of
snd_soc_card from init() of snd_soc_dai_link. This is because init()
is called (and an input device /dev/input/eventX is created too)
twice or above if simple card has two or more DAI links.
Signed-off-by: Katsuhiro Suzuki
---
Changes from v1:
- Newly added
---
sound/soc/generic/simple-card.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 1bbd9e46bf2a..9eb26ee06892 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -149,14 +149,6 @@ static int asoc_simple_card_dai_init(struct
snd_soc_pcm_runtime *rtd)
if (ret < 0)
return ret;
- ret = asoc_simple_card_init_hp(rtd->card, &priv->hp_jack, PREFIX);
- if (ret < 0)
- return ret;
-
- ret = asoc_simple_card_init_mic(rtd->card, &priv->mic_jack, PREFIX);
- if (ret < 0)
- return ret;
-
return 0;
}
@@ -350,6 +342,22 @@ static int asoc_simple_card_parse_of(struct
simple_card_data *priv)
return ret;
}
+static int asoc_simple_soc_card_probe(struct snd_soc_card *card)
+{
+ struct simple_card_data *priv = snd_soc_card_get_drvdata(card);
+ int ret;
+
+ ret = asoc_simple_card_init_hp(card, &priv->hp_jack, NULL);
+ if (ret < 0)
+ return ret;
+
+ ret = asoc_simple_card_init_mic(card, &priv->mic_jack, NULL);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
static int asoc_simple_card_probe(struct platform_device *pdev)
{
struct simple_card_data *priv;
@@ -385,6 +393,7 @@ static int asoc_simple_card_probe(struct platform_device
*pdev)
card->dev = dev;
card->dai_link = priv->dai_link;
card->num_links = num;
+ card->probe = asoc_simple_soc_card_probe;
if (np && of_device_is_available(np)) {
--
2.17.1
[PATCH v2 1/3] ASoC: simple-card-utils: move hp and mic detect gpios from simple-card
This patch moves headphone and microphone jack detection gpios from
simple-card driver. It is preparing for using this feature from other
drivers.
Signed-off-by: Katsuhiro Suzuki
---
Changes from v1:
- Move changes of audio-graph-card to other patch
---
include/sound/simple_card_utils.h | 15 +++
sound/soc/generic/simple-card-utils.c | 59
sound/soc/generic/simple-card.c | 64 ---
3 files changed, 74 insertions(+), 64 deletions(-)
diff --git a/include/sound/simple_card_utils.h
b/include/sound/simple_card_utils.h
index 7e25afce6566..f82acef3b992 100644
--- a/include/sound/simple_card_utils.h
+++ b/include/sound/simple_card_utils.h
@@ -12,6 +12,11 @@
#include
+#define asoc_simple_card_init_hp(card, sjack, prefix) \
+ asoc_simple_card_init_jack(card, sjack, 1, prefix)
+#define asoc_simple_card_init_mic(card, sjack, prefix) \
+ asoc_simple_card_init_jack(card, sjack, 0, prefix)
+
struct asoc_simple_dai {
const char *name;
unsigned int sysclk;
@@ -28,6 +33,12 @@ struct asoc_simple_card_data {
u32 convert_channels;
};
+struct asoc_simple_jack {
+ struct snd_soc_jack jack;
+ struct snd_soc_jack_pin pin;
+ struct snd_soc_jack_gpio gpio;
+};
+
int asoc_simple_card_parse_daifmt(struct device *dev,
struct device_node *node,
struct device_node *codec,
@@ -107,4 +118,8 @@ int asoc_simple_card_of_parse_routing(struct snd_soc_card
*card,
int asoc_simple_card_of_parse_widgets(struct snd_soc_card *card,
char *prefix);
+int asoc_simple_card_init_jack(struct snd_soc_card *card,
+ struct asoc_simple_jack *sjack,
+ int is_hp, char *prefix);
+
#endif /* __SIMPLE_CARD_UTILS_H */
diff --git a/sound/soc/generic/simple-card-utils.c
b/sound/soc/generic/simple-card-utils.c
index 3751a07de6aa..4398c9580929 100644
--- a/sound/soc/generic/simple-card-utils.c
+++ b/sound/soc/generic/simple-card-utils.c
@@ -8,9 +8,13 @@
* published by the Free Software Foundation.
*/
#include
+#include
+#include
#include
#include
+#include
#include
+#include
#include
void asoc_simple_card_convert_fixup(struct asoc_simple_card_data *data,
@@ -419,6 +423,61 @@ int asoc_simple_card_of_parse_widgets(struct snd_soc_card
*card,
}
EXPORT_SYMBOL_GPL(asoc_simple_card_of_parse_widgets);
+int asoc_simple_card_init_jack(struct snd_soc_card *card,
+ struct asoc_simple_jack *sjack,
+ int is_hp, char *prefix)
+{
+ struct device *dev = card->dev;
+ enum of_gpio_flags flags;
+ char prop[128];
+ char *pin_name;
+ char *gpio_name;
+ int mask;
+ int det;
+
+ if (!prefix)
+ prefix = "";
+
+ sjack->gpio.gpio = -ENOENT;
+
+ if (is_hp) {
+ snprintf(prop, sizeof(prop), "%shp-det-gpio", prefix);
+ pin_name= "Headphones";
+ gpio_name = "Headphone detection";
+ mask= SND_JACK_HEADPHONE;
+ } else {
+ snprintf(prop, sizeof(prop), "%smic-det-gpio", prefix);
+ pin_name= "Mic Jack";
+ gpio_name = "Mic detection";
+ mask= SND_JACK_MICROPHONE;
+ }
+
+ det = of_get_named_gpio_flags(dev->of_node, prop, 0, &flags);
+ if (det == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ if (gpio_is_valid(det)) {
+ sjack->pin.pin = pin_name;
+ sjack->pin.mask = mask;
+
+ sjack->gpio.name= gpio_name;
+ sjack->gpio.report = mask;
+ sjack->gpio.gpio= det;
+ sjack->gpio.invert = !!(flags & OF_GPIO_ACTIVE_LOW);
+ sjack->gpio.debounce_time = 150;
+
+ snd_soc_card_jack_new(card, pin_name, mask,
+ &sjack->jack,
+ &sjack->pin, 1);
+
+ snd_soc_jack_add_gpios(&sjack->jack, 1,
+ &sjack->gpio);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(asoc_simple_card_init_jack);
+
/* Module information */
MODULE_AUTHOR("Kuninori Morimoto ");
MODULE_DESCRIPTION("ALSA SoC Simple Card Utils");
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 4a516c428b3d..1bbd9e46bf2a 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -10,23 +10,14 @@
*/
#include
#include
-#include
#include
#include
-#include
#include
#include
-#include
#include
#include
#include
-struct asoc_simple_jack {
- struct snd_soc_jack jack;
- struct snd_soc_jack_pin pin;
- struct snd_soc_jack_gpio gpio;
-};
-
struct simple
[PATCH] pcmcia: add error handling for pcmcia_enable_device
When pcmcia_enable_device fails, the lack of error-handling code may
cause unexpected results.
This patch adds error-handling code after calling pcmcia_enable_device.
Signed-off-by: Zhouyang Jia
---
drivers/scsi/pcmcia/qlogic_stub.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/pcmcia/qlogic_stub.c
b/drivers/scsi/pcmcia/qlogic_stub.c
index 0556054..9287d52 100644
--- a/drivers/scsi/pcmcia/qlogic_stub.c
+++ b/drivers/scsi/pcmcia/qlogic_stub.c
@@ -254,8 +254,14 @@ static void qlogic_release(struct pcmcia_device *link)
static int qlogic_resume(struct pcmcia_device *link)
{
scsi_info_t *info = link->priv;
+ int ret;
+
+ ret = pcmcia_enable_device(link);
+ if (ret) {
+ pcmcia_disable_device(link);
+ return -ENODEV;
+ }
- pcmcia_enable_device(link);
if ((info->manf_id == MANFID_MACNICA) ||
(info->manf_id == MANFID_PIONEER) ||
(info->manf_id == 0x0098)) {
--
2.7.4
[PATCH v2 3/3] ASoC: audio-graph-card: add hp and mic detect gpios same as simple-card
This patch adds headphone and microphone jack detection gpios as same
as simple-card driver.
Signed-off-by: Katsuhiro Suzuki
---
Changes from v1:
- Move changes of audio-graph-card to other patch
---
sound/soc/generic/audio-graph-card.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/sound/soc/generic/audio-graph-card.c
b/sound/soc/generic/audio-graph-card.c
index 1b6164249341..2baa60d3b3cc 100644
--- a/sound/soc/generic/audio-graph-card.c
+++ b/sound/soc/generic/audio-graph-card.c
@@ -21,7 +21,6 @@
#include
#include
#include
-#include
#include
struct graph_card_data {
@@ -32,6 +31,8 @@ struct graph_card_data {
unsigned int mclk_fs;
} *dai_props;
unsigned int mclk_fs;
+ struct asoc_simple_jack hp_jack;
+ struct asoc_simple_jack mic_jack;
struct snd_soc_dai_link *dai_link;
struct gpio_desc *pa_gpio;
};
@@ -278,6 +279,22 @@ static int asoc_graph_get_dais_count(struct device *dev)
return count;
}
+static int asoc_graph_soc_card_probe(struct snd_soc_card *card)
+{
+ struct graph_card_data *priv = snd_soc_card_get_drvdata(card);
+ int ret;
+
+ ret = asoc_simple_card_init_hp(card, &priv->hp_jack, NULL);
+ if (ret < 0)
+ return ret;
+
+ ret = asoc_simple_card_init_mic(card, &priv->mic_jack, NULL);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
static int asoc_graph_card_probe(struct platform_device *pdev)
{
struct graph_card_data *priv;
@@ -319,6 +336,7 @@ static int asoc_graph_card_probe(struct platform_device
*pdev)
card->num_links = num;
card->dapm_widgets = asoc_graph_card_dapm_widgets;
card->num_dapm_widgets = ARRAY_SIZE(asoc_graph_card_dapm_widgets);
+ card->probe = asoc_graph_soc_card_probe;
ret = asoc_graph_card_parse_of(priv);
if (ret < 0) {
--
2.17.1
Re: [PATCH v2] ARM: DTS: imx53: Add support for imx53 HSC/DDC boards from K+P
On Sat, May 19, 2018 at 02:15:06PM +0200, Lukasz Majewski wrote:
> This commit provides support for HSC and DDC boards from
> Kieback&Peter GmbH vendor.
>
> Signed-off-by: Lukasz Majewski
> ---
> Changes for v2:
>
> - Remove not needed #address-cells and #size-cells in
> the gpio_buttons node to pass make W=1
> - Rename button@{12} to button_{kalt|pwr} nodes to pass make W=1
> - Include #include to use KEY_F6|F7 directly
>
> ---
> arch/arm/boot/dts/Makefile | 2 +
> arch/arm/boot/dts/imx53-kp-ddc.dts | 146
> arch/arm/boot/dts/imx53-kp-hsc.dts | 51 ++
> arch/arm/boot/dts/imx53-kp.dtsi| 190
> +
> 4 files changed, 389 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx53-kp-ddc.dts
> create mode 100644 arch/arm/boot/dts/imx53-kp-hsc.dts
> create mode 100644 arch/arm/boot/dts/imx53-kp.dtsi
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index fbc04b0db781..00854a5b6ac4 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -360,6 +360,8 @@ dtb-$(CONFIG_SOC_IMX51) += \
> dtb-$(CONFIG_SOC_IMX53) += \
> imx53-ard.dtb \
> imx53-cx9020.dtb \
> + imx53-kp-ddc.dtb \
> + imx53-kp-hsc.dtb \
> imx53-m53evk.dtb \
> imx53-mba53.dtb \
> imx53-ppd.dtb \
> diff --git a/arch/arm/boot/dts/imx53-kp-ddc.dts
> b/arch/arm/boot/dts/imx53-kp-ddc.dts
> new file mode 100644
> index ..acaf477a52c5
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx53-kp-ddc.dts
> @@ -0,0 +1,146 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2018
> + * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
> + */
> +
> +/dts-v1/;
> +#include "imx53-kp.dtsi"
> +
> +/ {
> + model = "K+P imx53 DDC";
> + compatible = "kiebackpeter,imx53-ddc", "fsl,imx53";
> +
> + backlight_lcd: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm2 0 5>;
> + power-supply = <®_backlight>;
> + brightness-levels = <0 24 28 32 36
> + 40 44 48 52 56
> + 60 64 68 72 76
> + 80 84 88 92 96 100>;
> + default-brightness-level = <20>;
> + };
> +
> + lcd_display: disp1 {
display for node node.
> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interface-pix-fmt = "rgb24";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_disp>;
> +
> + port@0 {
> + reg = <0>;
> +
> + display1_in: endpoint {
> + remote-endpoint = <&ipu_di1_disp1>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + lcd_display_out: endpoint {
> + remote-endpoint = <&lcd_panel_in>;
> + };
> + };
> + };
> +
> + lcd_panel: lcd-panel {
> + compatible = "koe,tx14d24vm1bpa";
Undefined compatible?
> + backlight = <&backlight_lcd>;
> + power-supply = <®_3v3>;
> +
> + port {
> + lcd_panel_in: endpoint {
> + remote-endpoint = <&lcd_display_out>;
> + };
> + };
> + };
> +
> + reg_backlight: regulator-backlight {
> + compatible = "regulator-fixed";
> + regulator-name = "backlight-supply";
> + regulator-min-microvolt = <1500>;
> + regulator-max-microvolt = <1500>;
> + regulator-always-on;
> + };
> +};
> +
> +&i2c3 {
> + adc@48 {
> + compatible = "ti,ads1015";
> + reg = <0x48>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + channel@4 {
> + reg = <4>;
> + ti,gain = <2>;
> + ti,datarate = <4>;
> + };
> +
> + channel@6 {
> + reg = <6>;
> + ti,gain = <2>;
> + ti,datarate = <4>;
> + };
> + };
> +
> + gpio_expander2@21 {
Use hyphen instead of underscore in node name.
> + compatible = "nxp,pcf8574";
> + reg = <0x21>;
> + interrupts = <109>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + };
> +};
> +
> +&iomuxc {
> + imx53-kp-ddc {
> + pinctrl_disp: dispgrp {
> + fsl,pins = <
> + MX53_PAD_EIM_A16__IPU_DI1_DISP_CLK 0x4
> + MX53_PAD_EIM_DA10__IPU_DI1_PIN150x4
> + MX53_PAD_EIM_DA9__IPU_DISP1_DAT_0 0x4
> +
[PATCH] staging: gdm724x: add error handling for nlmsg_put
When nlmsg_put fails, the lack of error-handling code may cause unexpected results. This patch adds error-handling code after calling nlmsg_put. Signed-off-by: Zhouyang Jia --- drivers/staging/gdm724x/netlink_k.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/staging/gdm724x/netlink_k.c b/drivers/staging/gdm724x/netlink_k.c index abe2425..4623140 100644 --- a/drivers/staging/gdm724x/netlink_k.c +++ b/drivers/staging/gdm724x/netlink_k.c @@ -119,6 +119,9 @@ int netlink_send(struct sock *sock, int group, u16 type, void *msg, int len) seq++; nlh = nlmsg_put(skb, 0, seq, type, len, 0); + if (!nlh) + return -EMSGSIZE; + memcpy(NLMSG_DATA(nlh), msg, len); NETLINK_CB(skb).portid = 0; NETLINK_CB(skb).dst_group = 0; -- 2.7.4
Re: [PATCH] optoe: driver to read/write SFP/QSFP EEPROMs
Hi, On 06/10/2018 09:25 PM, Don Bollinger wrote: > diff --git a/drivers/misc/eeprom/Kconfig b/drivers/misc/eeprom/Kconfig > index 68a1ac929917..9a08e12756ee 100644 > --- a/drivers/misc/eeprom/Kconfig > +++ b/drivers/misc/eeprom/Kconfig > @@ -111,4 +111,22 @@ config EEPROM_IDT_89HPESX > This driver can also be built as a module. If so, the module > will be called idt_89hpesx. > > +config EEPROM_OPTOE > + tristate "read/write access to SFP* & QSFP* EEPROMs" > + depends on I2C && SYSFS > + help > + If you say yes here you get support for read and write access to > + the EEPROM of SFP and QSFP type optical and copper transceivers. > + Includes all devices which conform to the sff-8436 and sff-8472 This includes and then please s/sff/SFF/ (2 places). > + spec including SFP, SFP+, SFP28, SFP-DWDM, QSFP, QSFP+, QSFP28 > + or later. These devices are usually found in network switches. > + > + This driver only manages read/write access to the EEPROM, all > + other features should be accessed via i2c-dev. > + > + This driver can also be built as a module. If so, the module > + will be called optoe. > + > + If unsure, say N. > + > endmenu thanks, -- ~Randy
[PATCH] optoe: driver to read/write SFP/QSFP EEPROMs
optoe is an i2c based driver that supports read/write access to all the pages (tables) of MSA standard SFP and similar devices (conforming to the SFF-8472 spec) and MSA standard QSFP and similar devices (conforming to the SFF-8436 spec). These devices provide identification, operational status and control registers via an EEPROM model. These devices support one or 3 fixed pages (128 bytes) of data, and one page that is selected via a page register on the first fixed page. Thus the driver's main task is to map these pages onto a simple linear address space for user space management applications. See the driver code for a detailed layout. EEPROM data is accessible via a bin_attribute file called 'eeprom', e.g. /sys/bus/i2c/devices/24-0050/eeprom. Signed-off-by: Don Bollinger --- Why should this driver be in the Linux kernel? SFP and QSFP devices plug into switches to convert electrical to optical signals and drive the optical signal over fiber optic cables. They provide status and control registers through an i2c interface similar to to other EEPROMS. However, they have a paging mechanism that is unique, which requires a different driver from (for example) at24. Various drivers have been developed for this purpose, none of them support both SFP and QSFP, provide both read and write access, and access all 256 architected pages. optoe does all of these. optoe has been adopted and is shipping to customers as a base module, available to all platforms (switches) and used by multiple vendors and platforms on both ONL (Open Network Linux) and SONiC (Microsoft's 'Software for Open Networking in the Cloud'). This patch has been built on the latest staging-testing kernel. It has built and tested with SFP and QSFP devices on an ARM platform with a 4.9 kernel, and an x86 switch with a 3.16 kernel. This patch should install and build clean on any kernel from 3.16 up to the latest (as of 6/10/2018). Documentation/misc-devices/optoe.txt | 56 ++ drivers/misc/eeprom/Kconfig | 18 + drivers/misc/eeprom/Makefile |1 + drivers/misc/eeprom/optoe.c | 1141 ++ 4 files changed, 1216 insertions(+) create mode 100644 Documentation/misc-devices/optoe.txt create mode 100644 drivers/misc/eeprom/optoe.c diff --git a/Documentation/misc-devices/optoe.txt b/Documentation/misc-devices/optoe.txt new file mode 100644 index ..496134940147 --- /dev/null +++ b/Documentation/misc-devices/optoe.txt @@ -0,0 +1,56 @@ +optoe driver + +Author Don Bollinger (d...@thebollingers.org) + +Optoe is an i2c based driver that supports read/write access to all +the pages (tables) of MSA standard SFP and similar devices (conforming +to the SFF-8472 spec) and MSA standard QSFP and similar devices +(conforming to the SFF-8436 spec). + +i2c based optoelectronic transceivers (SPF, QSFP, etc) provide identification, +operational status, and control registers via an EEPROM model. Unlike the +EEPROMs that at24 supports, these devices access data beyond byte 256 via +a page select register, which must be managed by the driver. See the driver +code for a detailed explanation of how the linear address space provided +by the driver maps to the paged address space provided by the devices. + +The EEPROM data is accessible via a bin_attribute file called 'eeprom', +e.g. /sys/bus/i2c/devices/24-0050/eeprom + +This driver also reports the port number for each device, via a sysfs +attribute: 'port_name'. This is a read/write attribute. It should be +explicitly set as part of system initialization, ideally at the same time +the device is instantiated. Write an appropriate port name (any string, up +to 19 characters) to initialize. If not initialized explicitly, all ports +will have the port_name of 'unitialized'. Alternatively, if the driver is +called with platform_data, the port_name will be read from eeprom_data->label +(if the EEPROM CLASS driver is configured) or from platform_data.port_name. + +This driver can be instantiated with 'new_device', per the convention +described in Documentation/i2c/instantiating-devices. It wants one of +two possible device identifiers. Use 'optoe1' to indicate this is a device +with just one i2c address (all QSFP type devices). Use 'optoe2' to indicate +this is a device with two i2c addresses (all SFP type devices). + +Example: +# echo optoe1 0x50 > /sys/bus/i2c/devices/i2c-64/new_device +# echo port54 > /sys/bus/i2c/devices/i2c-64/port_name + +This will add a QSFP type device to i2c bus i2c-64, and name it 'port54' + +Example: +# echo optoe2 0x50 > /sys/bus/i2c/devices/i2c-11/new_device +# echo port1 > /sys/bus/i2c/devices/i2c-11/port_name + +This will add an SFP type device to i2c bus i2c-11, and name it 'port1' + +The second parameter to new_device is an i2c address, and MUST be 0x50 for +this driver to work properly. This is part of the spec for these devices. +(It is not necessary to create a device at 0x51 for SFP type devices
Re: [PATCH 2/2] IB/mad: Use IDR for agent IDs
On Mon, Jun 11, 2018 at 07:34:25AM +0300, Leon Romanovsky wrote: > On Sun, Jun 10, 2018 at 02:30:27PM -0600, Jason Gunthorpe wrote: > > On Sun, Jun 10, 2018 at 03:25:05PM +0300, Leon Romanovsky wrote: > > > On Sun, Jun 10, 2018 at 03:43:05AM -0700, Matthew Wilcox wrote: > > > > On Sun, Jun 10, 2018 at 09:30:28AM +0300, Leon Romanovsky wrote: > > > > > 1. IBTA spec doesn't talk at all about the size of TransactionID, more > > > > > on that in section "13.4.6.4 TRANSACTION ID USAGE", the specification > > > > > says: "The contents of the TransactionID (TID) field are > > > > > implementation- > > > > > dependent. So let's don't call it mlx4 bug. > > > > > > > > I was loosely paraphrasing the original bug report; suggested rewording > > > > of the comments gratefully accepted. > > > > > > Just replace "mlx4 bug" with something like "to comply with mlx4 > > > implementation". > > > > Well, it is a bug. Blindly replacing the upper 8 bits of the TID in a > > driver without accommodation from the core is totally, bonkers wrong. > > I provided cite from spec that says that TID can be whatever you want as > long as you success to do it unique. Er, the spec has nothing to do with this. In Linux the TID is made unique because the core code provides 32 bits that are unique and the user provides another 32 bits that are unique. The driver cannot change any of those bits without risking non-uniquenes, which is exactly the bug mlx4 created when it stepped outside its bounds and improperly overrode bits in the TID for its own internal use. Jason
Re: [PATCH 0/5] can: enable multi-queue for SocketCAN devices
Hi, On 07.06.2018 17:14, Jonas Mark (BT-FIR/ENG1) wrote: > Hi Andy, > >>> The functionality bases on an external peripheral chip named Companion. >>> It offers two CAN interfaces, each has 8 prioritized transmit FIFOs as >>> well as one receive FIFO. Besides CAN, undisclosed additional functions >>> can be accessed through the char device. >>> >>> A standard SPI interface with two additional lines for flow control is >>> used. The Companion chip is the SPI slave. >> >> Can remoteproc API be utilized here? > > So far I wasn't aware of the remoteproc API. It appears to me that is > limited to power on/off and loading firmware in an AMP scenario. Here, > the Companion has a fixed firmware in it. It must already be running > quickly after power-up, even before the boot loader. yes, remoteproc is not quite suitable for this task. > Does remoteproc also contain a communication framework? it is using VirtIO > Do you mean rpmsg? Here, I do not see how we could benefit from it. using same message format instead of inventing new one will be really good step: https://github.com/OpenAMP/open-amp/wiki/RPMsg-Messaging-Protocol (less code duplicating same functionality) Looks like every company trying to solve the same problem over and over again. We have point to point link between two systems. Each system has multiple functionalities/applications so we should be able to address this functionality. So we end to some thing with source address and destination address. In all protocols used for inter processor/chip communication, the difference is only the layout of 3 common fields: source, destination and size. In many cases the ISO/OSI layer model is badly broken and > Can you point me to an example where rpmsg is used over SPI? RPMsg is just transport layer, 5 or 6 wire SPI is in this case Physical layer with flow control support. Currently i'm not sure if VirtIO with queue support do make sense here. > Greetings, > Mark signature.asc Description: OpenPGP digital signature
[PATCH] media: tm6000: add error handling for dvb_register_adapter
When dvb_register_adapter fails, the lack of error-handling code may
cause unexpected results.
This patch adds error-handling code after calling dvb_register_adapter.
Signed-off-by: Zhouyang Jia
---
drivers/media/usb/tm6000/tm6000-dvb.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/media/usb/tm6000/tm6000-dvb.c
b/drivers/media/usb/tm6000/tm6000-dvb.c
index c811fc6..ff35d4b 100644
--- a/drivers/media/usb/tm6000/tm6000-dvb.c
+++ b/drivers/media/usb/tm6000/tm6000-dvb.c
@@ -266,6 +266,11 @@ static int register_dvb(struct tm6000_core *dev)
ret = dvb_register_adapter(&dvb->adapter, "Trident TVMaster 6000 DVB-T",
THIS_MODULE, &dev->udev->dev,
adapter_nr);
+ if (ret < 0) {
+ printk(KERN_ERR "tm6000: couldn't register the adater!\n");
+ goto err;
+ }
+
dvb->adapter.priv = dev;
if (dvb->frontend) {
--
2.7.4
Re: [PATCH 2/2] IB/mad: Use IDR for agent IDs
On Sun, Jun 10, 2018 at 02:30:27PM -0600, Jason Gunthorpe wrote: > On Sun, Jun 10, 2018 at 03:25:05PM +0300, Leon Romanovsky wrote: > > On Sun, Jun 10, 2018 at 03:43:05AM -0700, Matthew Wilcox wrote: > > > On Sun, Jun 10, 2018 at 09:30:28AM +0300, Leon Romanovsky wrote: > > > > 1. IBTA spec doesn't talk at all about the size of TransactionID, more > > > > on that in section "13.4.6.4 TRANSACTION ID USAGE", the specification > > > > says: "The contents of the TransactionID (TID) field are implementation- > > > > dependent. So let's don't call it mlx4 bug. > > > > > > I was loosely paraphrasing the original bug report; suggested rewording > > > of the comments gratefully accepted. > > > > Just replace "mlx4 bug" with something like "to comply with mlx4 > > implementation". > > Well, it is a bug. Blindly replacing the upper 8 bits of the TID in a > driver without accommodation from the core is totally, bonkers wrong. I provided cite from spec that says that TID can be whatever you want as long as you success to do it unique. > > The original concept was that the 1<<24 limit would come from the > driver and only mlx4 would have less than 1<<32, because only mlx4 > does this thing.. > > Thanks Matt, > Jason > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html signature.asc Description: PGP signature
Re: [PATCH 0/7] Uprobes: Support SDT markers having reference count (semaphore)
Hi Masami, >>> Hmm, it sounds simple... maybe we can increment refctr in >>> install_breakpoint/ >>> remove_breakpoint? >> >> Not really, it would be simpler if I can put it inside install_breakpoint(). >> Consider an mmap() case. Probed instruction resides in the text section >> whereas >> reference counter resides in the data section. These sections gets mapped >> using >> separate mmap() calls. So, when process mmaps the text section we will >> change the >> instruction, but section holding the reference counter may not have been >> mapped >> yet in the virtual memory. If so, we will fail to update the reference >> counter. > > Got it. > In such case, maybe we can hook the target page mmapped and do > install_breakpoint() > at that point. Since the instruction is protected by a refctr, unless mmap the > page on where the refctr is, the program doesn't reach the tracepoint. Is > that right? > You mean, when mmap(text) happens, save the target page somewhere and when mmap(data) happens, update both instruction and ref_ctr? This sounds feasible. Let me think on it. Thanks for suggestion, Ravi
Re: [RESEND v2] dmaengine: pxa: add a default requestor policy
On 09-06-18, 14:43, Robert Jarzmik wrote: > Robert Jarzmik writes: > > > As what former drcmr -1 value meant, add a this as a default to each > > channel, ie. that by default no requestor line is used. > > > > This is specifically used for network drivers smc91x and smc911x, and > > needed for their port to slave maps. > > > > Cc: Arnd Bergmann > > Signed-off-by: Robert Jarzmik > > --- > > Since v1: changed -1 to U32_MAX > Hi Vinod, > > Could I have your ack on this so that I add this one to the dma slave map > serie > after the merge window is closed please ? Sorry I was thinking it would go thru dmaengine tree, please do indicate if that is not the case. Nevertheless Acked-by: Vinod Koul -- ~Vinod
Re: [PATCH 0/7] Uprobes: Support SDT markers having reference count (semaphore)
Hi Oleg,
On 06/08/2018 10:06 PM, Oleg Nesterov wrote:
> Hello,
>
> I am travelling till the end of the next week, can't read this version
> until I return. Just one question,
>
> On 06/06, Ravi Bangoria wrote:
>>
>> 1. One of the major reason was the deadlock between uprobe_lock and
>> mm->mmap inside trace_uprobe_mmap(). That deadlock was not easy to fix
>
> Could you remind what exactly was wrong?
>
> I can't find your previous email about this problem, but iirc you didn't
> explain the deadlock in details, just copied some traces from lockdep...
The deadlock is between mm->mmap_sem and uprobe_lock.
Some existing code path is taking these locks in following order:
uprobe_lock
event_mutex
uprobe->register_rwsem
dup_mmap_sem
mm->mmap_sem
I've introduced new function trace_uprobe_mmap() which gets called
from mmap_region() / vma_adjust() with mm->mmap_sem already acquired.
And it has to take uprobe_lock to loop over all trace_uprobes. i.e.
the sequence is:
mm->mmap_sem
uprobe_lock
Why it's difficult to resolve is because trace_uprobe_mmap() does
not have control over mm->mmap_sem.
Detailed trace from lockdep:
[ 499.258006] ==
[ 499.258205] WARNING: possible circular locking dependency detected
[ 499.258409] 4.17.0-rc3+ #76 Not tainted
[ 499.258528] --
[ 499.258731] perf/6744 is trying to acquire lock:
[ 499.258895] e4895f49 (uprobe_lock){+.+.}, at:
trace_uprobe_mmap+0x78/0x130
[ 499.259147]
[ 499.259147] but task is already holding lock:
[ 499.259349] 9ec93a76 (&mm->mmap_sem){}, at:
vm_mmap_pgoff+0xe0/0x160
[ 499.259597]
[ 499.259597] which lock already depends on the new lock.
[ 499.259597]
[ 499.259848]
[ 499.259848] the existing dependency chain (in reverse order) is:
[ 499.260086]
[ 499.260086] -> #4 (&mm->mmap_sem){}:
[ 499.260277]__lock_acquire+0x53c/0x910
[ 499.260442]lock_acquire+0xf4/0x2f0
[ 499.260595]down_write_killable+0x6c/0x150
[ 499.260764]copy_process.isra.34.part.35+0x1594/0x1be0
[ 499.260967]_do_fork+0xf8/0x910
[ 499.261090]ppc_clone+0x8/0xc
[ 499.261209]
[ 499.261209] -> #3 (&dup_mmap_sem){}:
[ 499.261378]__lock_acquire+0x53c/0x910
[ 499.261540]lock_acquire+0xf4/0x2f0
[ 499.261669]down_write+0x6c/0x110
[ 499.261793]percpu_down_write+0x48/0x140
[ 499.261954]register_for_each_vma+0x6c/0x2a0
[ 499.262116]uprobe_register+0x230/0x320
[ 499.262277]probe_event_enable+0x1cc/0x540
[ 499.262435]perf_trace_event_init+0x1e0/0x350
[ 499.262587]perf_trace_init+0xb0/0x110
[ 499.262750]perf_tp_event_init+0x38/0x90
[ 499.262910]perf_try_init_event+0x10c/0x150
[ 499.263075]perf_event_alloc+0xbb0/0xf10
[ 499.263235]sys_perf_event_open+0x2a8/0xdd0
[ 499.263396]system_call+0x58/0x6c
[ 499.263516]
[ 499.263516] -> #2 (&uprobe->register_rwsem){}:
[ 499.263723]__lock_acquire+0x53c/0x910
[ 499.263884]lock_acquire+0xf4/0x2f0
[ 499.264002]down_write+0x6c/0x110
[ 499.264118]uprobe_register+0x1ec/0x320
[ 499.264283]probe_event_enable+0x1cc/0x540
[ 499.264442]perf_trace_event_init+0x1e0/0x350
[ 499.264603]perf_trace_init+0xb0/0x110
[ 499.264766]perf_tp_event_init+0x38/0x90
[ 499.264930]perf_try_init_event+0x10c/0x150
[ 499.265092]perf_event_alloc+0xbb0/0xf10
[ 499.265261]sys_perf_event_open+0x2a8/0xdd0
[ 499.265424]system_call+0x58/0x6c
[ 499.265542]
[ 499.265542] -> #1 (event_mutex){+.+.}:
[ 499.265738]__lock_acquire+0x53c/0x910
[ 499.265896]lock_acquire+0xf4/0x2f0
[ 499.266019]__mutex_lock+0xa0/0xab0
[ 499.266142]trace_add_event_call+0x44/0x100
[ 499.266310]create_trace_uprobe+0x4a0/0x8b0
[ 499.266474]trace_run_command+0xa4/0xc0
[ 499.266631]trace_parse_run_command+0xe4/0x200
[ 499.266799]probes_write+0x20/0x40
[ 499.266922]__vfs_write+0x6c/0x240
[ 499.267041]vfs_write+0xd0/0x240
[ 499.267166]ksys_write+0x6c/0x110
[ 499.267295]system_call+0x58/0x6c
[ 499.267413]
[ 499.267413] -> #0 (uprobe_lock){+.+.}:
[ 499.267591]validate_chain.isra.34+0xbd0/0x1000
[ 499.267747]__lock_acquire+0x53c/0x910
[ 499.267917]lock_acquire+0xf4/0x2f0
[ 499.268048]__mutex_lock+0xa0/0xab0
[ 499.268170]trace_uprobe_mmap+0x78/0x130
[ 499.268335]uprobe_mmap+0x80/0x3b0
[ 499.268464]mmap_region+0x290/0x660
[ 499.268590]do_mmap+0x40c/0x500
[ 499.268718]vm_mmap_pgoff+0x114/0x160
[ 499.268870]ksys_mmap_pgoff+0xe8/0x2e0
[ 499.269034]sys_mmap+0x84/0xf0
[ 499.269161]system_call+0x58/0x6c
[ 499.269279]
[ 499.2
Re: [PATCH v3 9/9] x86: jump-labels: use macros instead of inline assembly
at 6:29 PM, h...@zytor.com wrote:
> On June 10, 2018 7:19:11 AM PDT, Nadav Amit wrote:
>> Use assembly macros for jump-labels and call them from inline assembly.
>> This not only makes the code more readable, but also improves
>> compilation decision, specifically inline decisions which GCC base on
>> the number of new lines in inline assembly.
>>
>> As a result the code size is slightly increased.
>>
>> text data bss dec hex filename
>> 18163528 10226300 2957312 31347140 1de51c4 ./vmlinux before
>> 18163608 10227348 2957312 31348268 1de562c ./vmlinux after (+1128)
>>
>> And functions such as intel_pstate_adjust_policy_max(),
>> kvm_cpu_accept_dm_intr(), kvm_register_read() are inlined.
>>
>> Cc: Thomas Gleixner
>> Cc: Ingo Molnar
>> Cc: "H. Peter Anvin"
>> Cc: x...@kernel.org
>> Cc: Greg Kroah-Hartman
>> Cc: Kate Stewart
>> Cc: Philippe Ombredanne
>>
>> Signed-off-by: Nadav Amit
>> ---
>> arch/x86/include/asm/jump_label.h | 65 ++-
>> arch/x86/kernel/macros.S | 1 +
>> 2 files changed, 39 insertions(+), 27 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/jump_label.h
>> b/arch/x86/include/asm/jump_label.h
>> index 8c0de4282659..ea0633a41122 100644
>> --- a/arch/x86/include/asm/jump_label.h
>> +++ b/arch/x86/include/asm/jump_label.h
>> @@ -2,19 +2,6 @@
>> #ifndef _ASM_X86_JUMP_LABEL_H
>> #define _ASM_X86_JUMP_LABEL_H
>>
>> -#ifndef HAVE_JUMP_LABEL
>> -/*
>> - * For better or for worse, if jump labels (the gcc extension) are
>> missing,
>> - * then the entire static branch patching infrastructure is compiled
>> out.
>> - * If that happens, the code in here will malfunction. Raise a
>> compiler
>> - * error instead.
>> - *
>> - * In theory, jump labels and the static branch patching
>> infrastructure
>> - * could be decoupled to fix this.
>> - */
>> -#error asm/jump_label.h included on a non-jump-label kernel
>> -#endif
>> -
>> #define JUMP_LABEL_NOP_SIZE 5
>>
>> #ifdef CONFIG_X86_64
>> @@ -28,18 +15,27 @@
>>
>> #ifndef __ASSEMBLY__
>>
>> +#ifndef HAVE_JUMP_LABEL
>> +/*
>> + * For better or for worse, if jump labels (the gcc extension) are
>> missing,
>> + * then the entire static branch patching infrastructure is compiled
>> out.
>> + * If that happens, the code in here will malfunction. Raise a
>> compiler
>> + * error instead.
>> + *
>> + * In theory, jump labels and the static branch patching
>> infrastructure
>> + * could be decoupled to fix this.
>> + */
>> +#error asm/jump_label.h included on a non-jump-label kernel
>> +#endif
>> +
>> #include
>> #include
>>
>> static __always_inline bool arch_static_branch(struct static_key *key,
>> bool branch)
>> {
>> -asm_volatile_goto("1:"
>> -".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t"
>> -".pushsection __jump_table, \"aw\" \n\t"
>> -_ASM_ALIGN "\n\t"
>> -_ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t"
>> -".popsection \n\t"
>> -: : "i" (key), "i" (branch) : : l_yes);
>> +asm_volatile_goto("STATIC_BRANCH_GOTO l_yes=\"%l[l_yes]\" key=\"%c0\"
>> "
>> + "branch=\"%c1\""
>> +: : "i" (key), "i" (branch) : : l_yes);
>>
>> return false;
>> l_yes:
>> @@ -48,13 +44,8 @@ static __always_inline bool
>> arch_static_branch(struct static_key *key, bool bran
>>
>> static __always_inline bool arch_static_branch_jump(struct static_key
>> *key, bool branch)
>> {
>> -asm_volatile_goto("1:"
>> -".byte 0xe9\n\t .long %l[l_yes] - 2f\n\t"
>> -"2:\n\t"
>> -".pushsection __jump_table, \"aw\" \n\t"
>> -_ASM_ALIGN "\n\t"
>> -_ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t"
>> -".popsection \n\t"
>> +asm_volatile_goto("STATIC_BRANCH_JUMP_GOTO l_yes=\"%l[l_yes]\"
>> key=\"%c0\" "
>> + "branch=\"%c1\""
>> : : "i" (key), "i" (branch) : : l_yes);
>>
>> return false;
>> @@ -108,6 +99,26 @@ struct jump_entry {
>> .popsection
>> .endm
>>
>> +.macro STATIC_BRANCH_GOTO l_yes:req key:req branch:req
>> +1:
>> +.byte STATIC_KEY_INIT_NOP
>> +.pushsection __jump_table, "aw"
>> +_ASM_ALIGN
>> +_ASM_PTR 1b, \l_yes, \key + \branch
>> +.popsection
>> +.endm
>> +
>> +.macro STATIC_BRANCH_JUMP_GOTO l_yes:req key:req branch:req
>> +1:
>> +.byte 0xe9
>> +.long \l_yes - 2f
>> +2:
>> +.pushsection __jump_table, "aw"
>> +_ASM_ALIGN
>> +_ASM_PTR 1b, \l_yes, \key + \branch
>> +.popsection
>> +.endm
>> +
>> #endif /* __ASSEMBLY__ */
>>
>> #endif
>> diff --git a/arch/x86/kernel/macros.S b/arch/x86/kernel/macros.S
>> index bf8b9c93e255..161c95059044 100644
>> --- a/arch/x86/kernel/macros.S
>> +++ b/arch/x86/kernel/macros.S
>> @@ -13,3 +13,4 @@
>> #include
>> #include
>> #include
>> +#include
>
> If the code size increases, do you have any metrics for improvement?
>
> That being said, I do like the readability improvements and the abi
[RFC PATCH] kbuild: clean-up passing KCOV compiler flags
Now that the compiler support for KCOV is computed in the Kconfig phase, expensive $(call cc-option,...) calls no longer exist in scripts/Makefile.kcov . It shouldn't hurt to include scripts/Makefile.kcov everytime Kbuild descends into a sub-directory. Also, move ugly stuff from Makefile.lib to Makefile.kcov . Signed-off-by: Masahiro Yamada --- My hope is to do likewise for gcov, kasan, ubsan. gcov, kcov, kasan, ubsan need per-file (or per-directory) flag addition or removal. Currently, scripts/Makefile.lib is cluttered to handle this. If this clean-up is achieved, scripts/Makefile.lib will look like this: -->8-- include-$(CONFIG_GCOV_KERNEL) += scripts/Makefile.gcov include-$(CONFIG_KCOV)+= scripts/Makefile.kcov include-$(CONFIG_KASAN) += scripts/Makefile.kasan include-$(CONFIG_UBSAN) += scripts/Makefile.ubsan include $(include-y) -->8-- I will not apply this until some more cleanups are done (hence, RFC). At least, scripts/Makefile.kasan is so complicated for now. Makefile | 1 - scripts/Makefile.kcov | 8 +++- scripts/Makefile.lib | 8 +++- 3 files changed, 6 insertions(+), 11 deletions(-) diff --git a/Makefile b/Makefile index 73f0bb2..c99ca82 100644 --- a/Makefile +++ b/Makefile @@ -669,7 +669,6 @@ KBUILD_CFLAGS += $(call cc-ifversion, -lt, 0409, \ # Tell gcc to never replace conditional load with a non-conditional one KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0) -include scripts/Makefile.kcov include scripts/Makefile.gcc-plugins ifdef CONFIG_READABLE_ASM diff --git a/scripts/Makefile.kcov b/scripts/Makefile.kcov index 3d61c4b..408b776 100644 --- a/scripts/Makefile.kcov +++ b/scripts/Makefile.kcov @@ -1,9 +1,7 @@ -ifdef CONFIG_KCOV - kcov-flags-$(CONFIG_CC_HAS_SANCOV_TRACE_PC)+= -fsanitize-coverage=trace-pc kcov-flags-$(CONFIG_KCOV_ENABLE_COMPARISONS) += -fsanitize-coverage=trace-cmp kcov-flags-$(CONFIG_GCC_PLUGIN_SANCOV) += -fplugin=$(objtree)/scripts/gcc-plugins/sancov_plugin.so -export CFLAGS_KCOV := $(kcov-flags-y) - -endif +_c_flags += $(if $(patsubst n%,, \ + $(KCOV_INSTRUMENT_$(basetarget).o)$(KCOV_INSTRUMENT)$(CONFIG_KCOV_INSTRUMENT_ALL)), \ + $(kcov-flags-y)) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 5af34a2b..f5bd1d3 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -126,11 +126,9 @@ _c_flags += $(if $(patsubst n%,, \ $(CFLAGS_UBSAN)) endif -ifeq ($(CONFIG_KCOV),y) -_c_flags += $(if $(patsubst n%,, \ - $(KCOV_INSTRUMENT_$(basetarget).o)$(KCOV_INSTRUMENT)$(CONFIG_KCOV_INSTRUMENT_ALL)), \ - $(CFLAGS_KCOV)) -endif +include-$(CONFIG_KCOV) += scripts/Makefile.kcov + +include $(include-y) # If building the kernel in a separate objtree expand all occurrences # of -Idir to -I$(srctree)/dir except for absolute paths (starting with '/'). -- 2.7.4
Re: [PATCH 1/2] arm64: avoid alloc memory on offline node
Hi Michal,
On 2018/6/7 20:21, Michal Hocko wrote:
> On Thu 07-06-18 19:55:53, Hanjun Guo wrote:
>> On 2018/6/7 18:55, Michal Hocko wrote:
> [...]
>>> I am not sure I have the full context but pci_acpi_scan_root calls
>>> kzalloc_node(sizeof(*info), GFP_KERNEL, node)
>>> and that should fall back to whatever node that is online. Offline node
>>> shouldn't keep any pages behind. So there must be something else going
>>> on here and the patch is not the right way to handle it. What does
>>> faddr2line __alloc_pages_nodemask+0xf0 tells on this kernel?
>>
>> The whole context is:
>>
>> The system is booted with a NUMA node has no memory attaching to it
>> (memory-less NUMA node), also with NR_CPUS less than CPUs presented
>> in MADT, so CPUs on this memory-less node are not brought up, and
>> this NUMA node will not be online (but SRAT presents this NUMA node);
>>
>> Devices attaching to this NUMA node such as PCI host bridge still
>> return the valid NUMA node via _PXM, but actually that valid NUMA node
>> is not online which lead to this issue.
>
> But we should have other numa nodes on the zonelists so the allocator
> should fall back to other node. If the zonelist is not intiailized
> properly, though, then this can indeed show up as a problem. Knowing
> which exact place has blown up would help get a better picture...
>
I specific a non-exist node to allocate memory using kzalloc_node,
and got this following error message.
And I found out there is just a VM_WARN, but it does not prevent the memory
allocation continue.
This nid would be use to access NODE_DADA(nid), so if nid is invalid,
it would cause oops here.
459 /*
460 * Allocate pages, preferring the node given as nid. The node must be valid
and
461 * online. For more general interface, see alloc_pages_node().
462 */
463 static inline struct page *
464 __alloc_pages_node(int nid, gfp_t gfp_mask, unsigned int order)
465 {
466 VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES);
467 VM_WARN_ON(!node_online(nid));
468
469 return __alloc_pages(gfp_mask, order, nid);
470 }
471
(I wrote a ko, to allocate memory on a non-exist node using kzalloc_node().)
[ 120.061693] WARNING: CPU: 6 PID: 3966 at ./include/linux/gfp.h:467
allocate_slab+0x5fd/0x7e0
[ 120.070095] Modules linked in: bench(OE+) nls_utf8 isofs loop xt_CHECKSUM
iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4
nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c
ipt_REJECT nf_reject_ipv4 tun bridge stp llc ebtable_filter ebtables
ip6table_filter ip6_tables iptable_filter dm_mirror dm_region_hash dm_log
dm_mod intel_rapl skx_edac nfit vfat libnvdimm fat x86_pkg_temp_thermal
coretemp kvm_intel kvm irqbypass iTCO_wdt crct10dif_pclmul iTCO_vendor_support
crc32_pclmul ghash_clmulni_intel ses pcbc enclosure aesni_intel
scsi_transport_sas crypto_simd cryptd sg glue_helper ipmi_si joydev mei_me
i2c_i801 ipmi_devintf ioatdma shpchp pcspkr ipmi_msghandler mei dca i2c_core
lpc_ich acpi_power_meter nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables
[ 120.140992] ext4 mbcache jbd2 sd_mod crc32c_intel i40e ahci libahci
megaraid_sas libata
[ 120.149053] CPU: 6 PID: 3966 Comm: insmod Tainted: G OE
4.17.0-rc2-RHEL74+ #5
[ 120.157369] Hardware name: Huawei 2288H V5/BC11SPSCB0, BIOS 0.62 03/26/2018
[ 120.164303] RIP: 0010:allocate_slab+0x5fd/0x7e0
[ 120.168817] RSP: 0018:881196947af0 EFLAGS: 00010246
[ 120.174022] RAX: RBX: 014012c0 RCX: b4bc8173
[ 120.181126] RDX: RSI: 0008 RDI: 8817aefa7868
[ 120.188233] RBP: 014000c0 R08: ed02f5df4f0e R09: ed02f5df4f0e
[ 120.195338] R10: ed02f5df4f0d R11: 8817aefa786f R12: 0055
[ 120.202444] R13: 0003 R14: 880107c0f800 R15:
[ 120.209550] FS: 7f6935d8c740() GS:8817aef8()
knlGS:
[ 120.217606] CS: 0010 DS: ES: CR0: 80050033
[ 120.223330] CR2: 00c21b88 CR3: 001197fd0006 CR4: 007606e0
[ 120.230435] DR0: DR1: DR2:
[ 120.237541] DR3: DR6: fffe0ff0 DR7: 0400
[ 120.244646] PKRU: 5554
[ 120.247346] Call Trace:
[ 120.249791] ? __kasan_slab_free+0xff/0x150
[ 120.253960] ? mpidr_init+0x20/0x30 [bench]
[ 120.258129] new_slab+0x3d/0x90
[ 120.261262] ___slab_alloc+0x371/0x640
[ 120.265002] ? __wake_up_common+0x8a/0x150
[ 120.269085] ? mpidr_init+0x20/0x30 [bench]
[ 120.273254] ? mpidr_init+0x20/0x30 [bench]
[ 120.277423] __slab_alloc+0x40/0x66
[ 120.280901] kmem_cache_alloc_node_trace+0xbc/0x270
[ 120.285762] ? mpidr_init+0x20/0x30 [bench]
[ 120.289931] ? 0xc074
[ 120.293236] mpidr_init+0x20/0x30 [bench]
[ 120.297236] do_one_initcall+0x4b/0x1f5
[ 120.301062] ? do_init_module+0x22/0x233
[ 120.304972] ? kmem_cache_alloc_trace+0xf
[PATCH] staging: clocking-wizard: prefer 'help' in Kconfig
Fixes the checkpatch warning: WARNING: prefer 'help' over '---help---' for new help texts +config COMMON_CLK_XLNX_CLKWZRD Signed-off-by: Kyle Buzby --- drivers/staging/clocking-wizard/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/clocking-wizard/Kconfig b/drivers/staging/clocking-wizard/Kconfig index 357af02c562c..aa57a5865556 100644 --- a/drivers/staging/clocking-wizard/Kconfig +++ b/drivers/staging/clocking-wizard/Kconfig @@ -5,5 +5,5 @@ config COMMON_CLK_XLNX_CLKWZRD tristate "Xilinx Clocking Wizard" depends on COMMON_CLK && OF - ---help--- + help Support for the Xilinx Clocking Wizard IP core clock generator. -- 2.17.1
Re: [alsa-devel] [PATCH] ASoC: audio-graph-card: add hp and mic detect gpios same as simple-card
Hello Morimoto-san,
Thank you for your reviewing.
On 06/11/18 08:52, Kuninori Morimoto wrote:
Hi Katsuhiro-san
Thank you for your patch
This patch adds headphone and microphone jack detection gpios as same
as simple-card driver. This feature move into simple-card-utils from
simple-card to avoid the duplicating code.
Signed-off-by: Katsuhiro Suzuki
---
I think it can be 2 patches ?
1. move function from simple-card to simple-card-utils
2. use it from audio-graph-card
OK, I'll split this patch.
+static int asoc_graph_soc_card_probe(struct snd_soc_card *card)
+{
+ struct graph_card_data *priv = snd_soc_card_get_drvdata(card);
+ int ret;
+
+ ret = asoc_simple_card_init_hp(card, &priv->hp_jack, NULL);
+ if (ret < 0)
+ return ret;
+
+ ret = asoc_simple_card_init_mic(card, &priv->mic_jack, NULL);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
static int asoc_graph_card_probe(struct platform_device *pdev)
{
struct graph_card_data *priv;
@@ -319,6 +336,7 @@ static int asoc_graph_card_probe(struct platform_device
*pdev)
card->num_links = num;
card->dapm_widgets = asoc_graph_card_dapm_widgets;
card->num_dapm_widgets = ARRAY_SIZE(asoc_graph_card_dapm_widgets);
+ card->probe = asoc_graph_soc_card_probe;
Current simple-card is calling init_hp/init_mic from
asoc_simple_card_dai_init(), and audio-graph-card has
asoc_graph_card_dai_init().
simple/audio card are doing samethings in different style.
Thus, I want to synchronized whole simple/audio card.
Ah, right. I need to add more one patch.
1. move function from simple-card to simple-card-utils
2. change calling init_hp/mic from soc_dai_link.init() to
soc_card.probe()
3. use it from audio-graph-card
Regards,
--
Katsuhiro Suzuki
Best regards
---
Kuninori Morimoto
___
Alsa-devel mailing list
alsa-de...@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
[PATCH] linux/linkage.h: replace VMLINUX_SYMBOL_STR() with __stringify()
With the special case handling for Blackfin and Metag was removed by
commit 94e58e0ac312 ("export.h: remove code for prefixing symbols with
underscore"), VMLINUX_SYMBOL_STR() is now equivalent to __stringify().
Replace some remaining usages in to prepare for the
entire removal of VMLINUX_SYMBOL_STR().
Signed-off-by: Masahiro Yamada
---
include/linux/linkage.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/linkage.h b/include/linux/linkage.h
index f68db9e..d7618c4 100644
--- a/include/linux/linkage.h
+++ b/include/linux/linkage.h
@@ -24,16 +24,16 @@
#ifndef cond_syscall
#define cond_syscall(x)asm(\
- ".weak " VMLINUX_SYMBOL_STR(x) "\n\t" \
- ".set " VMLINUX_SYMBOL_STR(x) "," \
-VMLINUX_SYMBOL_STR(sys_ni_syscall))
+ ".weak " __stringify(x) "\n\t" \
+ ".set " __stringify(x) "," \
+__stringify(sys_ni_syscall))
#endif
#ifndef SYSCALL_ALIAS
#define SYSCALL_ALIAS(alias, name) asm(\
- ".globl " VMLINUX_SYMBOL_STR(alias) "\n\t" \
- ".set " VMLINUX_SYMBOL_STR(alias) "," \
- VMLINUX_SYMBOL_STR(name))
+ ".globl " __stringify(alias) "\n\t" \
+ ".set " __stringify(alias) ","\
+ __stringify(name))
#endif
#define __page_aligned_data__section(.data..page_aligned)
__aligned(PAGE_SIZE)
--
2.7.4
Re: [PATCH v4 1/2] power: supply: sbs-battery: don't assume MANUFACTURER_DATA formats
On 9/06/2018 06:36, Brian Norris wrote:
This driver was originally submitted for the TI BQ20Z75 battery IC
(commit a7640bfa10c5 ("power_supply: Add driver for TI BQ20Z75 gas gauge
IC")) and later renamed to express generic SBS support. While it's
mostly true that this driver implemented a standard SBS command set, it
takes liberties with the REG_MANUFACTURER_DATA register. This register
is specified in the SBS spec, but it doesn't make any mention of what
its actual contents are.
We've sort of noticed this optionality previously, with commit
17c6d3979e5b ("sbs-battery: make writes to ManufacturerAccess
optional"), where we found that some batteries NAK writes to this
register.
What this really means is that so far, we've just been lucky that most
batteries have either been compatible with the TI chip, or else at least
haven't reported highly-unexpected values.
For instance, one battery I have here seems to report either 0x or
0x0100 to the MANUFACTURER_ACCESS_STATUS command -- while this seems to
match either Wake Up (bits[11:8] = b) or Normal Discharge
(bits[11:8] = 0001b) status for the TI part [1], they don't seem to
actually correspond to real states (for instance, I never see 0101b =
Charge, even when charging).
On other batteries, I'm getting apparently random data in return, which
means that occasionally, we interpret this as "battery not present" or
"battery is not healthy".
All in all, it seems to be a really bad idea to make assumptions about
REG_MANUFACTURER_DATA, unless we already know what battery we're using.
Therefore, this patch reimplements the "present" and "health" checks to
the following on most SBS batteries:
1. HEALTH: report "unknown" -- I couldn't find a standard SBS command
that gives us much useful here
2. PRESENT: just send a REG_STATUS command; if it succeeds, then the
battery is present
Also, we stop sending MANUFACTURER_ACCESS_SLEEP to non-TI parts. I have
no proof that this is useful and supported.
If someone explicitly provided a 'ti,bq20z75' compatible property, then
we continue to use the existing TI command behaviors, and we effectively
revert commit 17c6d3979e5b ("sbs-battery: make writes to
ManufacturerAccess optional") to again make these commands required.
[1] http://www.ti.com/lit/er/sluu265a/sluu265a.pdf
Signed-off-by: Brian Norris
Reviewed-by: Guenter Roeck
Acked-by: Rhyland Klein
Reviewed-by: Phil Reid
---
v2:
* don't stub out POWER_SUPPLY_PROP_PRESENT from sbs_data[]
* use if/else instead of switch/case
v3:
* pull 'return 0' out of if/else, to satisfy braindead tooling
v4:
* make ManufacturerAccess non-optional for TI parts again
---
drivers/power/supply/sbs-battery.c | 67 --
1 file changed, 54 insertions(+), 13 deletions(-)
diff --git a/drivers/power/supply/sbs-battery.c
b/drivers/power/supply/sbs-battery.c
index 83d7b4115857..8ba6abf584de 100644
--- a/drivers/power/supply/sbs-battery.c
+++ b/drivers/power/supply/sbs-battery.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -156,6 +157,9 @@ static enum power_supply_property sbs_properties[] = {
POWER_SUPPLY_PROP_MODEL_NAME
};
+/* Supports special manufacturer commands from TI BQ20Z75 IC. */
+#define SBS_FLAGS_TI_BQ20Z75 BIT(0)
+
struct sbs_info {
struct i2c_client *client;
struct power_supply *power_supply;
@@ -168,6 +172,7 @@ struct sbs_info {
u32 poll_retry_count;
struct delayed_work work;
struct mutexmode_lock;
+ u32 flags;
};
static char model_name[I2C_SMBUS_BLOCK_MAX + 1];
@@ -315,17 +320,41 @@ static int sbs_status_correct(struct i2c_client *client,
int *intval)
static int sbs_get_battery_presence_and_health(
struct i2c_client *client, enum power_supply_property psp,
union power_supply_propval *val)
+{
+ int ret;
+
+ if (psp == POWER_SUPPLY_PROP_PRESENT) {
+ /* Dummy command; if it succeeds, battery is present. */
+ ret = sbs_read_word_data(client, sbs_data[REG_STATUS].addr);
+ if (ret < 0)
+ val->intval = 0; /* battery disconnected */
+ else
+ val->intval = 1; /* battery present */
+ } else { /* POWER_SUPPLY_PROP_HEALTH */
+ /* SBS spec doesn't have a general health command. */
+ val->intval = POWER_SUPPLY_HEALTH_UNKNOWN;
+ }
+
+ return 0;
+}
+
+static int sbs_get_ti_battery_presence_and_health(
+ struct i2c_client *client, enum power_supply_property psp,
+ union power_supply_propval *val)
{
s32 ret;
/*
* Write to ManufacturerAccess with ManufacturerAccess command
-* and then read the status. Do not check for error on the write
-* since not all batteries im
Re: [PATCH] ASoC: audio-graph-card: add hp and mic detect gpios same as simple-card
Hello Morimoto-san,
Thank you for your reviewing.
> -Original Message-
> From: Kuninori Morimoto
> Sent: Monday, June 11, 2018 8:53 AM
> To: Suzuki, Katsuhiro
> Cc: Mark Brown ; alsa-de...@alsa-project.org; Masami
Hiramatsu
> ; Jassi Brar ;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] ASoC: audio-graph-card: add hp and mic detect gpios same
as
> simple-card
>
>
> Hi Katsuhiro-san
>
> Thank you for your patch
>
> > This patch adds headphone and microphone jack detection gpios as same
> > as simple-card driver. This feature move into simple-card-utils from
> > simple-card to avoid the duplicating code.
> >
> > Signed-off-by: Katsuhiro Suzuki
> > ---
>
> I think it can be 2 patches ?
> 1. move function from simple-card to simple-card-utils
> 2. use it from audio-graph-card
>
OK, I'll split this patch.
> > +static int asoc_graph_soc_card_probe(struct snd_soc_card *card)
> > +{
> > + struct graph_card_data *priv = snd_soc_card_get_drvdata(card);
> > + int ret;
> > +
> > + ret = asoc_simple_card_init_hp(card, &priv->hp_jack, NULL);
> > + if (ret < 0)
> > + return ret;
> > +
> > + ret = asoc_simple_card_init_mic(card, &priv->mic_jack, NULL);
> > + if (ret < 0)
> > + return ret;
> > +
> > + return 0;
> > +}
> > +
> > static int asoc_graph_card_probe(struct platform_device *pdev)
> > {
> > struct graph_card_data *priv;
> > @@ -319,6 +336,7 @@ static int asoc_graph_card_probe(struct platform_device
> *pdev)
> > card->num_links = num;
> > card->dapm_widgets = asoc_graph_card_dapm_widgets;
> > card->num_dapm_widgets = ARRAY_SIZE(asoc_graph_card_dapm_widgets);
> > + card->probe = asoc_graph_soc_card_probe;
>
> Current simple-card is calling init_hp/init_mic from
> asoc_simple_card_dai_init(), and audio-graph-card has
> asoc_graph_card_dai_init().
> simple/audio card are doing samethings in different style.
> Thus, I want to synchronized whole simple/audio card.
>
Indeed. I need to add more one patch.
1. move function from simple-card to simple-card-utils
2. change calling init_hp/mic from soc_dai_link.init() to
soc_card.probe()
3. use it from audio-graph-card
Regards,
--
Katsuhiro Suzuki
> Best regards
> ---
> Kuninori Morimoto
perfmon trouble
On Sat, Jun 09, 2018 at 04:51:08PM +0100, Al Viro wrote:
> Stephane, could you comment on the situation in there? I realize that you
> hadn't touched that thing in more than a decade, but I've no idea who else
> might be familiar with that thing and it's very inconveniently special...
Having looked through that code... ouch. It tries to have munmap-on-close,
of all things. Which has interesting consequences; consider, for example,
fd = perfctl(-1, PFM_CREATE_CONTEXT, &blah, 1); // create a context
pid = fork();
if (!pid) {
execve("/usr/bin/something_suid", ...);
...
}
with something_suid(8) doing an explicit "close each descriptor past stdout"
loop.
PFM_CREATE_CONTEXT has created a context, mmapped its buffer (and stored
the address of that mapping in ctx->ctx_smpl_vaddr) and, having opened
an associated file, sticks it into descriptor table and returns the descriptor.
On fork/exec we have
* descriptor table copied to child
* all mappings copied to child and then destroyed by execve
* execve ends up with the new binary (and libraries, etc.) mmapped
(in child)
Now, our careful suid-root binary does close(2) on its copy of descriptor.
pfm_flush() is called. ctx->task != current, so we proceed to
/*
* remove virtual mapping, if any, for the calling task.
* cannot reset ctx field until last user is calling close().
*
* ctx_smpl_vaddr must never be cleared because it is needed
* by every task with access to the context
*
* When called from do_exit(), the mm context is gone already, therefore
* mm is NULL, i.e., the VMA is already gone and we do not have to
* do anything here
*/
if (ctx->ctx_smpl_vaddr && current->mm) {
smpl_buf_vaddr = ctx->ctx_smpl_vaddr;
smpl_buf_size = ctx->ctx_smpl_size;
}
UNPROTECT_CTX(ctx, flags);
/*
* if there was a mapping, then we systematically remove it
* at this point. Cannot be done inside critical section
* because some VM function reenables interrupts.
*
*/
if (smpl_buf_vaddr) pfm_remove_smpl_mapping(smpl_buf_vaddr,
smpl_buf_size);
... with the last call doing vm_munmap() on the area in question. In the
address space of that suid-root binary, taking out whatever *it* had mapped
at that address range...
I wouldn't be surprised if that turned out to be realistically exploitable ;-/
Is there any documentation of that thing's semantics? perfmonctl(2) doesn't
mention the mapping at all and link to HP site in the arch/ia64/kernel/perfmon.c
is 404-compliant. Playing with archive.org brings a sourceforget reference,
but I hadn't been able to find anything ia64-related docs in there...
[PATCH] hid: intel_ish-hid: ipc: register more pm callbacks to support hibernation
From: Even Xu
Current ish driver only register resume/suspend PM callbacks which
don't support hibernation (suspend to disk). Now use the
SIMPLE_DEV_PM_OPS() MACRO instead of struct dev_pm_ops directly.
The suspend and resume functions will now be used for both suspend
to RAM and hibernation.
If power management is disable, SIMPLE_DEV_PM_OPS will do nothing,
the suspend and resume related functions won't be used, so mark them
as __maybe_unused to clarify that this is intended behavior, and
remove #ifdefs for power management.
Signed-off-by: Even Xu
Acked-by: Srinivas Pandruvada
---
drivers/hid/intel-ish-hid/ipc/pci-ish.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
index 582e449be9fe..a2c53ea3b5ed 100644
--- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
+++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
@@ -205,8 +205,7 @@ static void ish_remove(struct pci_dev *pdev)
kfree(ishtp_dev);
}
-#ifdef CONFIG_PM
-static struct device *ish_resume_device;
+static struct device __maybe_unused *ish_resume_device;
/* 50ms to get resume response */
#define WAIT_FOR_RESUME_ACK_MS 50
@@ -220,7 +219,7 @@ static struct device *ish_resume_device;
* in that case a simple resume message is enough, others we need
* a reset sequence.
*/
-static void ish_resume_handler(struct work_struct *work)
+static void __maybe_unused ish_resume_handler(struct work_struct *work)
{
struct pci_dev *pdev = to_pci_dev(ish_resume_device);
struct ishtp_device *dev = pci_get_drvdata(pdev);
@@ -262,7 +261,7 @@ static void ish_resume_handler(struct work_struct *work)
*
* Return: 0 to the pm core
*/
-static int ish_suspend(struct device *device)
+static int __maybe_unused ish_suspend(struct device *device)
{
struct pci_dev *pdev = to_pci_dev(device);
struct ishtp_device *dev = pci_get_drvdata(pdev);
@@ -288,7 +287,7 @@ static int ish_suspend(struct device *device)
return 0;
}
-static DECLARE_WORK(resume_work, ish_resume_handler);
+static __maybe_unused DECLARE_WORK(resume_work, ish_resume_handler);
/**
* ish_resume() - ISH resume callback
* @device:device pointer
@@ -297,7 +296,7 @@ static DECLARE_WORK(resume_work, ish_resume_handler);
*
* Return: 0 to the pm core
*/
-static int ish_resume(struct device *device)
+static int __maybe_unused ish_resume(struct device *device)
{
struct pci_dev *pdev = to_pci_dev(device);
struct ishtp_device *dev = pci_get_drvdata(pdev);
@@ -311,21 +310,14 @@ static int ish_resume(struct device *device)
return 0;
}
-static const struct dev_pm_ops ish_pm_ops = {
- .suspend = ish_suspend,
- .resume = ish_resume,
-};
-#define ISHTP_ISH_PM_OPS (&ish_pm_ops)
-#else
-#define ISHTP_ISH_PM_OPS NULL
-#endif /* CONFIG_PM */
+static SIMPLE_DEV_PM_OPS(ish_pm_ops, ish_suspend, ish_resume);
static struct pci_driver ish_driver = {
.name = KBUILD_MODNAME,
.id_table = ish_pci_tbl,
.probe = ish_probe,
.remove = ish_remove,
- .driver.pm = ISHTP_ISH_PM_OPS,
+ .driver.pm = &ish_pm_ops,
};
module_pci_driver(ish_driver);
--
2.13.6
Re: [PATCH v3 9/9] x86: jump-labels: use macros instead of inline assembly
On June 10, 2018 7:19:11 AM PDT, Nadav Amit wrote:
>Use assembly macros for jump-labels and call them from inline assembly.
>This not only makes the code more readable, but also improves
>compilation decision, specifically inline decisions which GCC base on
>the number of new lines in inline assembly.
>
>As a result the code size is slightly increased.
>
> text data bss dec hex filename
>18163528 10226300 2957312 31347140 1de51c4 ./vmlinux before
>18163608 10227348 2957312 31348268 1de562c ./vmlinux after (+1128)
>
>And functions such as intel_pstate_adjust_policy_max(),
>kvm_cpu_accept_dm_intr(), kvm_register_read() are inlined.
>
>Cc: Thomas Gleixner
>Cc: Ingo Molnar
>Cc: "H. Peter Anvin"
>Cc: x...@kernel.org
>Cc: Greg Kroah-Hartman
>Cc: Kate Stewart
>Cc: Philippe Ombredanne
>
>Signed-off-by: Nadav Amit
>---
> arch/x86/include/asm/jump_label.h | 65 ++-
> arch/x86/kernel/macros.S | 1 +
> 2 files changed, 39 insertions(+), 27 deletions(-)
>
>diff --git a/arch/x86/include/asm/jump_label.h
>b/arch/x86/include/asm/jump_label.h
>index 8c0de4282659..ea0633a41122 100644
>--- a/arch/x86/include/asm/jump_label.h
>+++ b/arch/x86/include/asm/jump_label.h
>@@ -2,19 +2,6 @@
> #ifndef _ASM_X86_JUMP_LABEL_H
> #define _ASM_X86_JUMP_LABEL_H
>
>-#ifndef HAVE_JUMP_LABEL
>-/*
>- * For better or for worse, if jump labels (the gcc extension) are
>missing,
>- * then the entire static branch patching infrastructure is compiled
>out.
>- * If that happens, the code in here will malfunction. Raise a
>compiler
>- * error instead.
>- *
>- * In theory, jump labels and the static branch patching
>infrastructure
>- * could be decoupled to fix this.
>- */
>-#error asm/jump_label.h included on a non-jump-label kernel
>-#endif
>-
> #define JUMP_LABEL_NOP_SIZE 5
>
> #ifdef CONFIG_X86_64
>@@ -28,18 +15,27 @@
>
> #ifndef __ASSEMBLY__
>
>+#ifndef HAVE_JUMP_LABEL
>+/*
>+ * For better or for worse, if jump labels (the gcc extension) are
>missing,
>+ * then the entire static branch patching infrastructure is compiled
>out.
>+ * If that happens, the code in here will malfunction. Raise a
>compiler
>+ * error instead.
>+ *
>+ * In theory, jump labels and the static branch patching
>infrastructure
>+ * could be decoupled to fix this.
>+ */
>+#error asm/jump_label.h included on a non-jump-label kernel
>+#endif
>+
> #include
> #include
>
>static __always_inline bool arch_static_branch(struct static_key *key,
>bool branch)
> {
>- asm_volatile_goto("1:"
>- ".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t"
>- ".pushsection __jump_table, \"aw\" \n\t"
>- _ASM_ALIGN "\n\t"
>- _ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t"
>- ".popsection \n\t"
>- : : "i" (key), "i" (branch) : : l_yes);
>+ asm_volatile_goto("STATIC_BRANCH_GOTO l_yes=\"%l[l_yes]\" key=\"%c0\"
>"
>+"branch=\"%c1\""
>+ : : "i" (key), "i" (branch) : : l_yes);
>
> return false;
> l_yes:
>@@ -48,13 +44,8 @@ static __always_inline bool
>arch_static_branch(struct static_key *key, bool bran
>
>static __always_inline bool arch_static_branch_jump(struct static_key
>*key, bool branch)
> {
>- asm_volatile_goto("1:"
>- ".byte 0xe9\n\t .long %l[l_yes] - 2f\n\t"
>- "2:\n\t"
>- ".pushsection __jump_table, \"aw\" \n\t"
>- _ASM_ALIGN "\n\t"
>- _ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t"
>- ".popsection \n\t"
>+ asm_volatile_goto("STATIC_BRANCH_JUMP_GOTO l_yes=\"%l[l_yes]\"
>key=\"%c0\" "
>+"branch=\"%c1\""
> : : "i" (key), "i" (branch) : : l_yes);
>
> return false;
>@@ -108,6 +99,26 @@ struct jump_entry {
> .popsection
> .endm
>
>+.macro STATIC_BRANCH_GOTO l_yes:req key:req branch:req
>+1:
>+ .byte STATIC_KEY_INIT_NOP
>+ .pushsection __jump_table, "aw"
>+ _ASM_ALIGN
>+ _ASM_PTR 1b, \l_yes, \key + \branch
>+ .popsection
>+.endm
>+
>+.macro STATIC_BRANCH_JUMP_GOTO l_yes:req key:req branch:req
>+1:
>+ .byte 0xe9
>+ .long \l_yes - 2f
>+2:
>+ .pushsection __jump_table, "aw"
>+ _ASM_ALIGN
>+ _ASM_PTR 1b, \l_yes, \key + \branch
>+ .popsection
>+.endm
>+
> #endif/* __ASSEMBLY__ */
>
> #endif
>diff --git a/arch/x86/kernel/macros.S b/arch/x86/kernel/macros.S
>index bf8b9c93e255..161c95059044 100644
>--- a/arch/x86/kernel/macros.S
>+++ b/arch/x86/kernel/macros.S
>@@ -13,3 +13,4 @@
> #include
> #include
> #include
>+#include
If the code size increases, do you have any metrics for improvement?
That being said, I do like the readability improvements and the ability to use
gas macros in assembly as opposed to cpp macros wrapped in different ways for C
and assembly.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: what trees/branches to test on syzbot
On Sun, Jun 10, 2018 at 08:11:05AM +0200, Dmitry Vyukov wrote: > > The set of trees where a crash happened is visible on dashboard, so > one can see if it's only linux-next or whole set of trees. Potentially > syzbot can act differently depending on this predicate, but I don't > see what should be the difference. However, this does not fully save > from falsely assessing bugs as linux-next-only just because they > happened few times and only on linux-next so far. So how about this, only report something as being a linux-next regression if (a) there is a reproducer, and (b) the reproducer does not trigger any kind of crash on mainline? > There is also a problem with rebasing of linux-next: reported commit > hashes do not make sense and we can forget about bisection. If there is a valid reproducer, bisection should simply be a matter ofu running and if we know the reproducer doesn't trigger on mainline, then the bisection should only require no more than 8-10 VM runs. For Linux-next, this would be *super* valuable. Reporting the commit ID and the one-line commit summary will be enough for most maintainers, since even if they are using a rewinding head, so long as the bisection can be done quickly enough (e.g., within a few days), it will still be in their git repository. And if you have a reproducer, then once it's identified as a linux-next reproducer with a guilty commit, that can be confirmed by either (a) seeing if you can revert the commit and if it makes the problem go away, or (b) figure out which subsystem git tree the commit was introduced via, and then verify that the reproducer triggers on the tip of the subsystem git tree. All of this will require development effort, so I suspect it's not something we'll see from syzbot tomorrow --- but it's not *impossible*. I think though that sending e-mail about a linux-next syzbot crash if there is a reproducer and the reproducer doesn't trigger a crash on mainline should be really simple to implement, and it would add huge value without spamming the subsystem maintainers. - Ted
include/linux/syscalls.h:211:18: error: 'sys_mmap2' alias between functions of incompatible types 'long int(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigne
Hi Al,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 1aaccb5fa0eac996adde53538ca4b87a0b229ab7
commit: ee076e81fc14ca79334d02970cea66604f183a14 sparc: trivial conversions to
{COMPAT_,}SYSCALL_DEFINE()
date: 3 months ago
config: sparc-defconfig (attached as .config)
compiler: sparc-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ee076e81fc14ca79334d02970cea66604f183a14
# save the attached .config to linux build tree
make.cross ARCH=sparc
All errors (new ones prefixed by >>):
In file included from arch/sparc/kernel/sys_sparc_32.c:21:
>> include/linux/syscalls.h:211:18: error: 'sys_mmap2' alias between functions
>> of incompatible types 'long int(long unsigned int, long unsigned int, long
>> unsigned int, long unsigned int, long unsigned int, long unsigned int)'
>> and 'long int(long int, long int, long int, long int, long int, long
>> int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:201:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:101:1: note: in expansion of macro
'SYSCALL_DEFINE6'
SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
^~~
include/linux/syscalls.h:215:18: note: aliased declaration here
asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:201:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:101:1: note: in expansion of macro
'SYSCALL_DEFINE6'
SYSCALL_DEFINE6(mmap2, unsigned long, addr, unsigned long, len,
^~~
>> include/linux/syscalls.h:211:18: error: 'sys_getdomainname' alias between
>> functions of incompatible types 'long int(char *, int)' and 'long int(long
>> int, long int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:197:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:205:1: note: in expansion of macro
'SYSCALL_DEFINE2'
SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
^~~
include/linux/syscalls.h:215:18: note: aliased declaration here
asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:197:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:205:1: note: in expansion of macro
'SYSCALL_DEFINE2'
SYSCALL_DEFINE2(getdomainname, char __user *, name, int, len)
^~~
include/linux/syscalls.h:211:18: error: 'sys_rt_sigaction' alias between
functions of incompatible types 'long int(int, const struct sigaction *,
struct sigaction *, void *, size_t)' {aka 'long int(int, const struct
sigaction *, struct sigaction *, void *, unsigned int)'} and 'long int(long
int, long int, long int, long int, long int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
include/linux/syscalls.h:207:2: note: in expansion of macro
'__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:200:36: note: in expansion of macro
'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE5(name, ...) SYSCALL_DEFINEx(5, _##name, __VA_ARGS__)
^~~
arch/sparc/kernel/sys_sparc_32.c:176:1: note: in expansion of macro
'SYSCALL_DEFINE5'
SYSCALL_DEFINE5(rt_sigaction,
Bad MAINTAINERS patterns
Given various renames and removals, the MAINTAINERS
file patterns get out of sync with the actual files.
It'd be nice if the various maintainers could fix
these file patterns.
$ ./scripts/get_maintainer.pl --self-test=patterns
./MAINTAINERS:1733: warning: no file matchesF:
include/dt-bindings/clock/nuvoton,npcm7xx-clks.h
./MAINTAINERS:1958: warning: no file matchesF:
arch/arm/plat-samsung/s5p-dev-mfc.c
./MAINTAINERS:2056: warning: no file matchesF:
arch/arm64/boot/dts/marvell/berlin*
./MAINTAINERS:2435: warning: no file matchesF:
include/media/atmel-isi.h
./MAINTAINERS:2973: warning: no file matchesF:
arch/arm64/boot/dts/broadcom/ns2*
./MAINTAINERS:3082: warning: no file matchesF:
Documentation/sound/alsa/Bt87x.txt
./MAINTAINERS:3378: warning: no file matchesF:
Documentation/module-signing.txt
./MAINTAINERS:3800: warning: no file matchesF:
drivers/media/i2c/cs3308.h
./MAINTAINERS:3831: warning: no file matchesF: include/media/cx2341x*
./MAINTAINERS:3938: warning: no file matchesF:
include/uapi/scsi/cxlflash_ioctls.h
./MAINTAINERS:3981: warning: no file matchesF:
drivers/input/dlink-dir685-touchkeys.c
./MAINTAINERS:4516: warning: no file matchesF:
Documentation/devicetree/bindings/display/ili9225.txt
./MAINTAINERS:4602: warning: no file matchesF:
Documentation/devicetree/bindings/display/st7586.txt
./MAINTAINERS:4608: warning: no file matchesF:
Documentation/devicetree/bindings/display/st7735r.txt
./MAINTAINERS:4641: warning: no file matchesF:
Documentation/devicetree/bindings/video/
./MAINTAINERS:4686: warning: no file matchesF:
Documentation/devicetree/bindings/drm/atmel/
./MAINTAINERS:4717: warning: no file matchesF:
Documentation/devicetree/bindings/display/panel/nec,nl4827hc19_05b.txt
./MAINTAINERS:4827: warning: no file matchesF:
Documentation/devicetree/bindings/display/brcm,bcm-v3d.txt
./MAINTAINERS:5635: warning: no file matchesF: Documentation/fpga/
./MAINTAINERS:5738: warning: no file matchesF:
Documentation/devicetree/bindings/powerpc/fsl/fman.txt
./MAINTAINERS:6144: warning: no file matchesF:
drivers/staging/greybus/fw-managament.c
./MAINTAINERS:6157: warning: no file matchesF:
drivers/staging/greybus/timesync.c
./MAINTAINERS:6158: warning: no file matchesF:
drivers/staging/greybus/timesync_platform.c
./MAINTAINERS:6504: warning: no file matchesF: Documentation/vm/hmm.txt
./MAINTAINERS:6796: warning: no file matchesF:
drivers/crypto/nx/nx_debugfs.h
./MAINTAINERS:6817: warning: no file matchesF:
arch/powerpc/include/uapi/asm/vas.h
./MAINTAINERS:6969: warning: no file matchesF:
Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
./MAINTAINERS:7031: warning: no file matchesF:
Documentation/devicetree/bindings/i2c/ina209.txt
./MAINTAINERS:7313: warning: no file matchesF:
arch/x86/include/asm/pmc_core.h
./MAINTAINERS:7404: warning: no file matchesF:
Documentation/trace/intel_th.txt
./MAINTAINERS:7428: warning: no file matchesF:
Documentation/devicetree/bindings/iio/gyroscope/inv,mpu3050.txt
./MAINTAINERS:7499: warning: no file matchesF: drivers/staging/ipx/
./MAINTAINERS:7951: warning: no file matchesF: include/linux/keyctl.h
./MAINTAINERS:8426: warning: no file matchesF:
arch/*/include/asm/mutex*.h
./MAINTAINERS:8572: warning: no file matchesF:
linux/platform_data/mv88e6xxx.h
./MAINTAINERS:8680: warning: no file matchesF: drivers/hwmon/max20751.c
./MAINTAINERS:8703: warning: no file matchesF:
Documentation/devicetree/bindings/i2c/max6697.txt
./MAINTAINERS:9083: warning: no file matchesF:
Documentation/devicetree/bindings/video/bridge/megachips-stdp-ge-b850v3-fw.txt
./MAINTAINERS:9151: warning: no file matchesF:
drivers/net/ethernet/mellanox/mlx5/core/en_ipsec/*
./MAINTAINERS:9152: warning: no file matchesF:
drivers/net/ethernet/mellanox/mlx5/core/ipsec*
./MAINTAINERS:9346: warning: no file matchesF:
devicetree/bindings/media/atmel-isc.txt
./MAINTAINERS:9462: warning: no file matchesF:
arch/mips/loongson64/*{2e/2f}*
./MAINTAINERS:9465: warning: no file matchesF: drivers/*/*/*loongson2*
./MAINTAINERS:9474: warning: no file matchesF: drivers/*/*loongson3*
./MAINTAINERS:9475: warning: no file matchesF: drivers/*/*/*loongson3*
./MAINTAINERS:9666: warning: no file matchesF:
Documentation/ABI/testing/mux/sysfs-class-mux*
./MAINTAINERS:9668: warning: no file matchesF:
include/linux/dt-bindings/mux/
./MAINTAINERS:9697: warning: no file matchesF:
Documentation/devicetree/bindings/display/mxsfb-drm.txt
./MAINTAINERS:9733: warning: no file matchesF: drivers/staging/ncpfs/
./MAINTAINERS:9768: warning: no file matchesF:
tools/include/asm-generic/bitsperlong.h:14:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
Hi Alexei, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 1aaccb5fa0eac996adde53538ca4b87a0b229ab7 commit: 819dd92b9c0bc7bce9097d8c1f14240f471bb386 bpfilter: switch to CC from HOSTCC date: 5 days ago config: alpha-allyesconfig (attached as .config) compiler: alpha-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 819dd92b9c0bc7bce9097d8c1f14240f471bb386 # save the attached .config to linux build tree make.cross ARCH=alpha All errors (new ones prefixed by >>): In file included from tools/include/uapi/asm/bitsperlong.h:17:0, from /usr/alpha-linux-gnu/include/asm-generic/int-l64.h:11, from /usr/alpha-linux-gnu/include/asm/types.h:12, from tools/include/linux/types.h:10, from ./include/uapi/linux/bpf.h:11, from net//bpfilter/main.c:9: >> tools/include/asm-generic/bitsperlong.h:14:2: error: #error Inconsistent >> word size. Check asm/bitsperlong.h #error Inconsistent word size. Check asm/bitsperlong.h ^ vim +14 tools/include/asm-generic/bitsperlong.h bb970707 Arnaldo Carvalho de Melo 2016-07-12 12 2a00f026 Arnaldo Carvalho de Melo 2016-07-13 13 #if BITS_PER_LONG != __BITS_PER_LONG bb970707 Arnaldo Carvalho de Melo 2016-07-12 @14 #error Inconsistent word size. Check asm/bitsperlong.h bb970707 Arnaldo Carvalho de Melo 2016-07-12 15 #endif bb970707 Arnaldo Carvalho de Melo 2016-07-12 16 :: The code at line 14 was first introduced by commit :: bb9707077b4ee5f77bc9939b057ff8a0d410296f tools: Copy the bitsperlong.h files from the kernel :: TO: Arnaldo Carvalho de Melo :: CC: Arnaldo Carvalho de Melo --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v3] mm: fix race between kmem_cache destroy, create and deactivate
On Sun, Jun 10, 2018 at 10:40:17AM -0700, Shakeel Butt wrote: > On Sun, Jun 10, 2018 at 9:32 AM Paul E. McKenney > wrote: > > > > On Sun, Jun 10, 2018 at 07:52:50AM -0700, Shakeel Butt wrote: > > > On Sat, Jun 9, 2018 at 3:20 AM Vladimir Davydov > > > wrote: > > > > > > > > On Tue, May 29, 2018 at 05:12:04PM -0700, Shakeel Butt wrote: > > > > > The memcg kmem cache creation and deactivation (SLUB only) is > > > > > asynchronous. If a root kmem cache is destroyed whose memcg cache is > > > > > in > > > > > the process of creation or deactivation, the kernel may crash. > > > > > > > > > > Example of one such crash: > > > > > general protection fault: [#1] SMP PTI > > > > > CPU: 1 PID: 1721 Comm: kworker/14:1 Not tainted 4.17.0-smp > > > > > ... > > > > > Workqueue: memcg_kmem_cache kmemcg_deactivate_workfn > > > > > RIP: 0010:has_cpu_slab > > > > > ... > > > > > Call Trace: > > > > > ? on_each_cpu_cond > > > > > __kmem_cache_shrink > > > > > kmemcg_cache_deact_after_rcu > > > > > kmemcg_deactivate_workfn > > > > > process_one_work > > > > > worker_thread > > > > > kthread > > > > > ret_from_fork+0x35/0x40 > > > > > > > > > > To fix this race, on root kmem cache destruction, mark the cache as > > > > > dying and flush the workqueue used for memcg kmem cache creation and > > > > > deactivation. > > > > > > > > > @@ -845,6 +862,8 @@ void kmem_cache_destroy(struct kmem_cache *s) > > > > > if (unlikely(!s)) > > > > > return; > > > > > > > > > > + flush_memcg_workqueue(s); > > > > > + > > > > > > > > This should definitely help against async memcg_kmem_cache_create(), > > > > but I'm afraid it doesn't eliminate the race with async destruction, > > > > unfortunately, because the latter uses call_rcu_sched(): > > > > > > > > memcg_deactivate_kmem_caches > > > >__kmem_cache_deactivate > > > > slab_deactivate_memcg_cache_rcu_sched > > > > call_rcu_sched > > > > kmem_cache_destroy > > > > shutdown_memcg_caches > > > > shutdown_cache > > > > memcg_deactivate_rcufn > > > > > > > > > > > > Can we somehow flush those pending rcu requests? > > > > > > You are right and thanks for catching that. Now I am wondering if > > > synchronize_sched() just before flush_workqueue() should be enough. > > > Otherwise we might have to replace call_sched_rcu with > > > synchronize_sched() in kmemcg_deactivate_workfn which I would not > > > prefer as that would holdup the kmem_cache workqueue. > > > > > > +Paul > > > > > > Paul, we have a situation something similar to the following pseudo code. > > > > > > CPU0: > > > lock(l) > > > if (!flag) > > > call_rcu_sched(callback); > > > unlock(l) > > > -- > > > CPU1: > > > lock(l) > > > flag = true > > > unlock(l) > > > synchronize_sched() > > > -- > > > > > > If CPU0 has called already called call_rchu_sched(callback) then later > > > if CPU1 calls synchronize_sched(). Is there any guarantee that on > > > return from synchronize_sched(), the rcu callback scheduled by CPU0 > > > has already been executed? > > > > No. There is no such guarantee. > > > > You instead want rcu_barrier_sched(), which waits for the callbacks from > > all prior invocations of call_rcu_sched() to be invoked. > > > > Please note that synchronize_sched() is -not- sufficient. It is only > > guaranteed to wait for a grace period, not necessarily for all prior > > callbacks. This goes both directions because if there are no callbacks > > in the system, then rcu_barrier_sched() is within its rights to return > > immediately. > > > > So please make sure you use each of synchronize_sched() and > > rcu_barrier_sched() to do the job that it was intended to do! ;-) > > > > If your lock(l) is shorthand for spin_lock(&l), it looks to me like you > > actually only need rcu_barrier_sched(): > > > > CPU0: > > spin_lock(&l); > > if (!flag) > > call_rcu_sched(callback); > > spin_unlock(&l); > > > > CPU1: > > spin_lock(&l); > > flag = true; > > spin_unlock(&l); > > /* At this point, no more callbacks will be registered. */ > > rcu_barrier_sched(); > > /* At this point, all registered callbacks will have been invoked. > > */ > > > > On the other hand, if your "lock(l)" was instead shorthand for > > rcu_read_lock_sched(), then you need -both- synchronize_sched() -and- > > rcu_barrier(). And even then, you will be broken in -rt kernels. > > (Which might or might not be a concern, depending on whether your code > > matters to -rt kernels. > > > > Make sense? > > Thanks a lot, that was really helpful. The lock is actually > mutex_lock. So, I think rcu_barrier_sched() should be sufficient. Yes, with either spin_lock() or mutex_lock(), this should wo
Re: [PATCH] ASoC: audio-graph-card: add hp and mic detect gpios same as simple-card
Hi Katsuhiro-san
Thank you for your patch
> This patch adds headphone and microphone jack detection gpios as same
> as simple-card driver. This feature move into simple-card-utils from
> simple-card to avoid the duplicating code.
>
> Signed-off-by: Katsuhiro Suzuki
> ---
I think it can be 2 patches ?
1. move function from simple-card to simple-card-utils
2. use it from audio-graph-card
> +static int asoc_graph_soc_card_probe(struct snd_soc_card *card)
> +{
> + struct graph_card_data *priv = snd_soc_card_get_drvdata(card);
> + int ret;
> +
> + ret = asoc_simple_card_init_hp(card, &priv->hp_jack, NULL);
> + if (ret < 0)
> + return ret;
> +
> + ret = asoc_simple_card_init_mic(card, &priv->mic_jack, NULL);
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> static int asoc_graph_card_probe(struct platform_device *pdev)
> {
> struct graph_card_data *priv;
> @@ -319,6 +336,7 @@ static int asoc_graph_card_probe(struct platform_device
> *pdev)
> card->num_links = num;
> card->dapm_widgets = asoc_graph_card_dapm_widgets;
> card->num_dapm_widgets = ARRAY_SIZE(asoc_graph_card_dapm_widgets);
> + card->probe = asoc_graph_soc_card_probe;
Current simple-card is calling init_hp/init_mic from
asoc_simple_card_dai_init(), and audio-graph-card has
asoc_graph_card_dai_init().
simple/audio card are doing samethings in different style.
Thus, I want to synchronized whole simple/audio card.
Best regards
---
Kuninori Morimoto
[PATCH 1/2] rcutorture: Disable RT throttling for boost tests
From: "Joel Fernandes (Google)"
Currently rcutorture is not able to torture RCU boosting properly. This
is because the rcutorture's boost threads which are doing the torturing
may be throttled due to RT throttling.
This patch makes rcutorture use the right torture technique (unthrottled
rcutorture boost tasks) for torturing RCU so that the test fails
correctly when no boost is available.
Currently this requires accessing sysctl_sched_rt_runtime directly, but
that should be Ok since rcutorture is test code. Such direct access is
also only possible if rcutorture is used as a built-in so make it
conditional on that.
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/rcutorture.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 5219e7ccd8a4..00e06349d7bb 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -55,6 +55,7 @@
#include
#include
#include
+#include
#include "rcu.h"
@@ -772,6 +773,32 @@ static void rcu_torture_boost_cb(struct rcu_head *head)
smp_store_release(&rbip->inflight, 0);
}
+static int old_rt_runtime = -1;
+
+static void rcu_torture_disable_rt_throttle(void)
+{
+ /*
+* Disable RT throttling so that rcutorture's boost threads don't get
+* throttled. Only possible if rcutorture is built-in otherwise the
+* user should manually do this by setting the sched_rt_period_us and
+* sched_rt_runtime sysctls.
+*/
+ if (!IS_BUILTIN(CONFIG_RCU_TORTURE_TEST) || old_rt_runtime != -1)
+ return;
+
+ old_rt_runtime = sysctl_sched_rt_runtime;
+ sysctl_sched_rt_runtime = -1;
+}
+
+static void rcu_torture_enable_rt_throttle(void)
+{
+ if (!IS_BUILTIN(CONFIG_RCU_TORTURE_TEST) || old_rt_runtime == -1)
+ return;
+
+ sysctl_sched_rt_runtime = old_rt_runtime;
+ old_rt_runtime = -1;
+}
+
static int rcu_torture_boost(void *arg)
{
unsigned long call_rcu_time;
@@ -1510,6 +1537,7 @@ static int rcutorture_booster_cleanup(unsigned int cpu)
mutex_lock(&boost_mutex);
t = boost_tasks[cpu];
boost_tasks[cpu] = NULL;
+ rcu_torture_enable_rt_throttle();
mutex_unlock(&boost_mutex);
/* This must be outside of the mutex, otherwise deadlock! */
@@ -1526,6 +1554,7 @@ static int rcutorture_booster_init(unsigned int cpu)
/* Don't allow time recalculation while creating a new task. */
mutex_lock(&boost_mutex);
+ rcu_torture_disable_rt_throttle();
VERBOSE_TOROUT_STRING("Creating rcu_torture_boost task");
boost_tasks[cpu] = kthread_create_on_node(rcu_torture_boost, NULL,
cpu_to_node(cpu),
--
2.18.0.rc1.242.g61856ae69a-goog
[PATCH 2/2] rcutorture: Make boost test more robust
From: "Joel Fernandes (Google)"
Currently, with RCU_BOOST disabled, I get no failures when forcing
rcutorture to test RCU boost priority inversion. The reason seems to be
that we don't check for failures if the callback never ran at all for
the duration of the boost-test loop.
Further, the 'rtb' and 'rtbf' counters seem to be used inconsistently.
'rtb' is incremented at the start of each test and 'rtbf' is incremented
per-cpu on each failure of call_rcu. So its possible 'rtbf' > 'rtb'.
To test the boost with rcutorture, I did following on a 4-CPU x86 machine:
modprobe rcutorture test_boost=2
sleep 20
rmmod rcutorture
With patch:
rtbf: 8 rtb: 12
Without patch:
rtbf: 0 rtb: 2
In summary this patch:
- Increments failed and total test counters once per boost-test.
- Checks for failure cases correctly.
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/rcutorture.c | 45 +++--
1 file changed, 39 insertions(+), 6 deletions(-)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 00e06349d7bb..0040cc2b836b 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -799,6 +799,18 @@ static void rcu_torture_enable_rt_throttle(void)
old_rt_runtime = -1;
}
+static bool rcu_torture_boost_failed(unsigned long start, unsigned long end)
+{
+ if (end - start > test_boost_duration * HZ - HZ / 2) {
+ VERBOSE_TOROUT_STRING("rcu_torture_boost boosting failed");
+ n_rcu_torture_boost_failure++;
+
+ return true; /* failed */
+ }
+
+ return false; /* passed */
+}
+
static int rcu_torture_boost(void *arg)
{
unsigned long call_rcu_time;
@@ -819,6 +831,21 @@ static int rcu_torture_boost(void *arg)
init_rcu_head_on_stack(&rbi.rcu);
/* Each pass through the following loop does one boost-test cycle. */
do {
+ /* Track if the test failed already in this test interval? */
+ bool failed = false;
+
+ /* Increment n_rcu_torture_boosts once per boost-test */
+ while (!kthread_should_stop()) {
+ if (mutex_trylock(&boost_mutex)) {
+ n_rcu_torture_boosts++;
+ mutex_unlock(&boost_mutex);
+ break;
+ }
+ schedule_timeout_uninterruptible(1);
+ }
+ if (kthread_should_stop())
+ goto checkwait;
+
/* Wait for the next test interval. */
oldstarttime = boost_starttime;
while (ULONG_CMP_LT(jiffies, oldstarttime)) {
@@ -837,11 +864,10 @@ static int rcu_torture_boost(void *arg)
/* RCU core before ->inflight = 1. */
smp_store_release(&rbi.inflight, 1);
call_rcu(&rbi.rcu, rcu_torture_boost_cb);
- if (jiffies - call_rcu_time >
-test_boost_duration * HZ - HZ / 2) {
-
VERBOSE_TOROUT_STRING("rcu_torture_boost boosting failed");
- n_rcu_torture_boost_failure++;
- }
+ /* Check if the boost test failed */
+ failed = failed ||
+rcu_torture_boost_failed(call_rcu_time,
+jiffies);
call_rcu_time = jiffies;
}
stutter_wait("rcu_torture_boost");
@@ -849,6 +875,14 @@ static int rcu_torture_boost(void *arg)
goto checkwait;
}
+ /*
+* If boost never happened, then inflight will always be 1, in
+* this case the boost check would never happen in the above
+* loop so do another one here.
+*/
+ if (!failed && smp_load_acquire(&rbi.inflight))
+ rcu_torture_boost_failed(call_rcu_time, jiffies);
+
/*
* Set the start time of the next test interval.
* Yes, this is vulnerable to long delays, but such
@@ -861,7 +895,6 @@ static int rcu_torture_boost(void *arg)
if (mutex_trylock(&boost_mutex)) {
boost_starttime = jiffies +
test_boost_interval * HZ;
- n_rcu_torture_boosts++;
mutex_unlock(&boost_mutex);
break;
}
--
2.18.0.rc1.242.g61856ae69a-goog
Re: [PATCH v4 3/4] mm/sparse: Add a new parameter 'data_unit_size' for alloc_usemap_and_memmap
On 06/08/18 at 09:13am, Dave Hansen wrote: > On 06/08/2018 08:17 AM, Baoquan He wrote: > > > > Then inside alloc_usemap_and_memmap(), For each node, we get how many > > present sections on this node, call hook alloc_func(). Then we update > > the pointer to point at a new position of usemap_map[] or map_map[]. > > I think this is the key. > > alloc_usemap_and_memmap() is passed in a "void *" that it needs to > update as things get consumed. But, it knows only the quantity of > objects consumed and not the type. This effectively tells it enough > about the type to let it update the pointer as objects are consumed. > > Right? > > Can we get that in the changelog? Hmm, I like above sentences very much, thanks. Do you means putting it in changelog, but not commit log of patch 3/4, right? I can do this when repost. Thanks Baoquan
[PATCH 3/5] vt: introduce unicode mode for /dev/vcs
Now that the core vt code knows how to preserve unicode values for each
displayed character, it is then possible to let user space access it via
/dev/vcs*.
Unicode characters are presented as 32 bit values in native endianity
via the /dev/vcsu* devices, mimicking the simple /dev/vcs* devices.
Unicode with attributes (similarly to /dev/vcsa*) is not supported at
the moment.
Data is available only as long as the console is in UTF-8 mode. ENODATA
is returned otherwise.
This was tested with the latest development version (to become
version 5.7) of BRLTTY. Amongst other things, this allows ⠋⠕⠗ ⠞⠓⠊⠎
⠃⠗⠁⠊⠇⠇⠑⠀⠞⠑⠭⠞⠀to appear directly on braille displays regardless of the
console font being used.
Signed-off-by: Nicolas Pitre
Tested-by: Dave Mielke
---
drivers/tty/vt/vc_screen.c | 89 --
drivers/tty/vt/vt.c| 61 ++
include/linux/selection.h | 5 +++
3 files changed, 141 insertions(+), 14 deletions(-)
diff --git a/drivers/tty/vt/vc_screen.c b/drivers/tty/vt/vc_screen.c
index e4a66e1fd0..9c44252e52 100644
--- a/drivers/tty/vt/vc_screen.c
+++ b/drivers/tty/vt/vc_screen.c
@@ -10,6 +10,12 @@
* Attribute/character pair is in native endianity.
*[minor: N+128]
*
+ * /dev/vcsuN: similar to /dev/vcsaN but using 4-byte unicode values
+ * instead of 1-byte screen glyph values.
+ *[minor: N+64]
+ *
+ * /dev/vcsuaN: same idea as /dev/vcsaN for unicode (not yet implemented).
+ *
* This replaces screendump and part of selection, so that the system
* administrator can control access using file system permissions.
*
@@ -51,6 +57,26 @@
#define CON_BUF_SIZE (CONFIG_BASE_SMALL ? 256 : PAGE_SIZE)
+/*
+ * Our minor space:
+ *
+ * 0 ... 63 glyph mode without attributes
+ * 64 ... 127 unicode mode without attributes
+ * 128 ... 191 glyph mode with attributes
+ * 192 ... 255 unused (reserved for unicode with attributes)
+ *
+ * This relies on MAX_NR_CONSOLES being <= 63, meaning 63 actual consoles
+ * with minors 0, 64, 128 and 192 being proxies for the foreground console.
+ */
+#if MAX_NR_CONSOLES > 63
+#warning "/dev/vcs* devices may not accommodate more than 63 consoles"
+#endif
+
+#define console(inode) (iminor(inode) & 63)
+#define use_unicode(inode) (iminor(inode) & 64)
+#define use_attributes(inode) (iminor(inode) & 128)
+
+
struct vcs_poll_data {
struct notifier_block notifier;
unsigned int cons_num;
@@ -102,7 +128,7 @@ vcs_poll_data_get(struct file *file)
poll = kzalloc(sizeof(*poll), GFP_KERNEL);
if (!poll)
return NULL;
- poll->cons_num = iminor(file_inode(file)) & 127;
+ poll->cons_num = console(file_inode(file));
init_waitqueue_head(&poll->waitq);
poll->notifier.notifier_call = vcs_notifier;
if (register_vt_notifier(&poll->notifier) != 0) {
@@ -140,7 +166,7 @@ vcs_poll_data_get(struct file *file)
static struct vc_data*
vcs_vc(struct inode *inode, int *viewed)
{
- unsigned int currcons = iminor(inode) & 127;
+ unsigned int currcons = console(inode);
WARN_CONSOLE_UNLOCKED();
@@ -164,7 +190,6 @@ static int
vcs_size(struct inode *inode)
{
int size;
- int minor = iminor(inode);
struct vc_data *vc;
WARN_CONSOLE_UNLOCKED();
@@ -175,8 +200,12 @@ vcs_size(struct inode *inode)
size = vc->vc_rows * vc->vc_cols;
- if (minor & 128)
+ if (use_attributes(inode)) {
+ if (use_unicode(inode))
+ return -EOPNOTSUPP;
size = 2*size + HEADER_SIZE;
+ } else if (use_unicode(inode))
+ size *= 4;
return size;
}
@@ -197,12 +226,10 @@ static ssize_t
vcs_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)
{
struct inode *inode = file_inode(file);
- unsigned int currcons = iminor(inode);
struct vc_data *vc;
struct vcs_poll_data *poll;
- long pos;
- long attr, read;
- int col, maxcol, viewed;
+ long pos, read;
+ int attr, uni_mode, row, col, maxcol, viewed;
unsigned short *org = NULL;
ssize_t ret;
char *con_buf;
@@ -218,7 +245,8 @@ vcs_read(struct file *file, char __user *buf, size_t count,
loff_t *ppos)
*/
console_lock();
- attr = (currcons & 128);
+ uni_mode = use_unicode(inode);
+ attr = use_attributes(inode);
ret = -ENXIO;
vc = vcs_vc(inode, &viewed);
if (!vc)
@@ -227,6 +255,10 @@ vcs_read(struct file *file, char __user *buf, size_t
count, loff_t *ppos)
ret = -EINVAL;
if (pos < 0)
goto unlock_out;
+ /* we enforce 32-bit alignment for pos and count in unicode mode */
+ if (uni_mode && (pos | count) & 3)
+ goto unlock_out;
+
poll = file->private_data;
if (count && poll)
poll->seen_last_update = true;
@@ -266,7 +298,27
[PATCH 0/5] have the vt console preserve unicode characters
The vt code translates UTF-8 strings into glyph index values and stores those glyph values directly in the screen buffer. Because there can only be at most 512 glyphs, it is impossible to represent most unicode characters, in which case a default glyph (often '?') is displayed instead. The original unicode value is then lost. This also means that the /dev/vcs* devices only provide user space with glyph index values, and then user applications must get hold of the unicode-to-glyph table the kernel is using in order to back-translate those into actual characters. It is not possible to get back the original unicode value when multiple unicode characters map to the same glyph, especially for the vast majority that maps to the default replacement glyph. The 512-glyph limitation is inherent to VGA displays, but users of /dev/vcs* shouldn't have to be restricted to a narrow unicode space from lossy screen content because of that. This is especially true for accessibility applications such as BRLTTY that rely on /dev/vcs to rander screen content onto braille terminals. This patch series introduces unicode support to /dev/vcs* devices, allowing full unicode access from userspace to the vt console which can, amongst other purposes, appropriately translate actual unicode screen content into braille. Memory is allocated, and possible CPU overhead introduced, only if /dev/vcsu is read at least once. I'm a prime user of this feature, as well as the BRLTTY maintainer Dave Mielke who implemented support for this in BRLTTY. There is therefore a vested self interest to maintain this feature as necessary. Patch #1 has been picked up by Greg already (commit 4b4ecd9cb8 in linux-next) but it is included here as well, as the rest of the series depends on it to apply properly. Patch #5 was used for validation and is included for completeness, however if people think it is unappropriate for mainline then it can be dropped. This is also available on top of v4.17-rc7 here: git://git.linaro.org/people/nicolas.pitre/linux vt-unicode diffstat: drivers/tty/vt/vc_screen.c | 90 +++-- drivers/tty/vt/vt.c| 366 +-- include/linux/console_struct.h | 2 + include/linux/selection.h | 5 + 4 files changed, 429 insertions(+), 34 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-console" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] vt: coherence validation code for the unicode screen buffer
Make sure the unicode screen buffer matches the video screen content.
This is provided for debugging convenience and disabled by default.
Signed-off-by: Nicolas Pitre
---
drivers/tty/vt/vt.c | 40
1 file changed, 40 insertions(+)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index e7c3cabeb1..2f3d528082 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -571,6 +571,45 @@ void vc_uniscr_copy_line(struct vc_data *vc, void *dest,
int viewed,
}
}
+/* this is for validation and debugging only */
+static void vc_uniscr_debug_check(struct vc_data *vc)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+ unsigned short *p;
+ int x, y, mask;
+
+ if (true)
+ return;
+
+ if (!uniscr)
+ return;
+
+ WARN_CONSOLE_UNLOCKED();
+
+ /*
+* Make sure our unicode screen translates into the same glyphs
+* as the actual screen. This is brutal indeed.
+*/
+ p = (unsigned short *)vc->vc_origin;
+ mask = vc->vc_hi_font_mask | 0xff;
+ for (y = 0; y < vc->vc_rows; y++) {
+ char32_t *line = uniscr->lines[y];
+ for (x = 0; x < vc->vc_cols; x++) {
+ u16 glyph = scr_readw(p++) & mask;
+ char32_t uc = line[x];
+ int tc = conv_uni_to_pc(vc, uc);
+ if (tc == -4)
+ tc = conv_uni_to_pc(vc, 0xfffd);
+ if (tc == -4)
+ tc = conv_uni_to_pc(vc, '?');
+ if (tc != glyph)
+ pr_notice("%s: mismatch at %d,%d: "
+ "glyph=%#x tc=%#x\n", __func__,
+ x, y, glyph, tc);
+ }
+ }
+}
+
static void con_scroll(struct vc_data *vc, unsigned int t, unsigned int b,
enum con_scroll dir, unsigned int nr)
@@ -2719,6 +2758,7 @@ static int do_con_write(struct tty_struct *tty, const
unsigned char *buf, int co
do_con_trol(tty, vc, orig);
}
con_flush(vc, draw_from, draw_to, &draw_x);
+ vc_uniscr_debug_check(vc);
console_conditional_schedule();
console_unlock();
notify_update(vc);
--
2.17.0
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] vt: preserve unicode values corresponding to screen characters
The vt code translates UTF-8 strings into glyph index values and stores
those glyph values directly in the screen buffer. Because there can only
be at most 512 glyphs, it is impossible to represent most unicode
characters, in which case a default glyph (often '?') is displayed
instead. The original unicode value is then lost.
This patch implements the basic screen buffer handling to preserve unicode
values alongside corresponding display glyphs. It is not activated by
default, meaning that people not relying on that functionality won't get
the implied overhead.
Signed-off-by: Nicolas Pitre
Tested-by: Dave Mielke
---
drivers/tty/vt/vt.c| 222 +++--
include/linux/console_struct.h | 2 +
2 files changed, 213 insertions(+), 11 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 1eb1a376a0..3a801a60f4 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -317,6 +317,173 @@ void schedule_console_callback(void)
schedule_work(&console_work);
}
+/*
+ * Code to manage unicode-based screen buffers
+ */
+
+#ifdef NO_VC_UNI_SCREEN
+/* this disables and optimizes related code away at compile time */
+#define get_vc_uniscr(vc) NULL
+#else
+#define get_vc_uniscr(vc) vc->vc_uni_screen
+#endif
+
+typedef uint32_t char32_t;
+
+/*
+ * Our screen buffer is preceded by an array of line pointers so that
+ * scrolling only implies some pointer shuffling.
+ */
+struct uni_screen {
+ char32_t *lines[0];
+};
+
+static struct uni_screen *vc_uniscr_alloc(unsigned int cols, unsigned int rows)
+{
+ struct uni_screen *uniscr;
+ void *p;
+ unsigned int memsize, i;
+
+ /* allocate everything in one go */
+ memsize = cols * rows * sizeof(char32_t);
+ memsize += rows * sizeof(char32_t *);
+ p = kmalloc(memsize, GFP_KERNEL);
+ if (!p) {
+ pr_err("unable to allocate unicode screen buffer");
+ return NULL;
+ }
+
+ /* initial line pointers */
+ uniscr = p;
+ p = uniscr->lines + rows;
+ for (i = 0; i < rows; i++) {
+ uniscr->lines[i] = p;
+ p += cols * sizeof(char32_t);
+ }
+ return uniscr;
+}
+
+static void vc_uniscr_set(struct vc_data *vc, struct uni_screen *new_uniscr)
+{
+ kfree(vc->vc_uni_screen);
+ vc->vc_uni_screen = new_uniscr;
+}
+
+static void vc_uniscr_putc(struct vc_data *vc, char32_t uc)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr)
+ uniscr->lines[vc->vc_y][vc->vc_x] = uc;
+}
+
+static void vc_uniscr_insert(struct vc_data *vc, unsigned int nr)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr) {
+ char32_t *ln = uniscr->lines[vc->vc_y];
+ unsigned int x = vc->vc_x, cols = vc->vc_cols;
+
+ memmove(&ln[x + nr], &ln[x], (cols - x - nr) * sizeof(*ln));
+ memset32(&ln[x], ' ', nr);
+ }
+}
+
+static void vc_uniscr_delete(struct vc_data *vc, unsigned int nr)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr) {
+ char32_t *ln = uniscr->lines[vc->vc_y];
+ unsigned int x = vc->vc_x, cols = vc->vc_cols;
+
+ memcpy(&ln[x], &ln[x + nr], (cols - x - nr) * sizeof(*ln));
+ memset32(&ln[cols - nr], ' ', nr);
+ }
+}
+
+static void vc_uniscr_clear_line(struct vc_data *vc, unsigned int x,
+unsigned int nr)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr) {
+ char32_t *ln = uniscr->lines[vc->vc_y];
+
+ memset32(&ln[x], ' ', nr);
+ }
+}
+
+static void vc_uniscr_clear_lines(struct vc_data *vc, unsigned int y,
+ unsigned int nr)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr) {
+ unsigned int cols = vc->vc_cols;
+
+ while (nr--)
+ memset32(uniscr->lines[y++], ' ', cols);
+ }
+}
+
+static void vc_uniscr_scroll(struct vc_data *vc, unsigned int t, unsigned int
b,
+enum con_scroll dir, unsigned int nr)
+{
+ struct uni_screen *uniscr = get_vc_uniscr(vc);
+
+ if (uniscr) {
+ unsigned int s, d, rescue, clear;
+ char32_t *save[nr];
+
+ s = clear = t;
+ d = t + nr;
+ rescue = b - nr;
+ if (dir == SM_UP) {
+ swap(s, d);
+ swap(clear, rescue);
+ }
+ memcpy(save, uniscr->lines + rescue, nr * sizeof(*save));
+ memmove(uniscr->lines + d, uniscr->lines + s,
+ (b - t - nr) * sizeof(*uniscr->lines));
+ memcpy(uniscr->lines + clear, save, nr * sizeof(*save));
+ vc_uniscr_clear_lines(vc, clear, nr);
+ }
+}
+
+static void vc_u
[PATCH 4/5] vt: unicode fallback for scrollback
There is currently no provision for scrollback content in the core code,
leaving that to backend video drivers where this can be highly optimized.
There is currently no common method for those drivers to tell the core
what part of the scrollback is actually displayed and what size the
scrollback buffer is either. Because of that, the unicode screen buffer
has no provision for any scrollback.
At least we can provide backtranslated glyph values when the scrollback
is active which should be plenty good enough for now.
Signed-off-by: Nicolas Pitre
Tested-by: Dave Mielke
---
drivers/tty/vt/vc_screen.c | 3 ++-
drivers/tty/vt/vt.c| 31 +--
include/linux/selection.h | 2 +-
3 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/vt/vc_screen.c b/drivers/tty/vt/vc_screen.c
index 9c44252e52..2384ea85ff 100644
--- a/drivers/tty/vt/vc_screen.c
+++ b/drivers/tty/vt/vc_screen.c
@@ -311,7 +311,8 @@ vcs_read(struct file *file, char __user *buf, size_t count,
loff_t *ppos)
do {
if (nr > this_round/4)
nr = this_round/4;
- vc_uniscr_copy_line(vc, con_buf0, row, col, nr);
+ vc_uniscr_copy_line(vc, con_buf0, viewed,
+ row, col, nr);
con_buf0 += nr * 4;
this_round -= nr * 4;
row++;
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 2cba6089ca..e7c3cabeb1 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -535,13 +535,40 @@ int vc_uniscr_check(struct vc_data *vc)
* This must be preceded by a successful call to vc_uniscr_check() once
* the console lock has been taken.
*/
-void vc_uniscr_copy_line(struct vc_data *vc, void *dest,
+void vc_uniscr_copy_line(struct vc_data *vc, void *dest, int viewed,
unsigned int row, unsigned int col, unsigned int nr)
{
struct uni_screen *uniscr = get_vc_uniscr(vc);
+ int offset = row * vc->vc_size_row + col * 2;
+ unsigned long pos;
BUG_ON(!uniscr);
- memcpy(dest, &uniscr->lines[row][col], nr * sizeof(char32_t));
+
+ pos = (unsigned long)screenpos(vc, offset, viewed);
+ if (pos >= vc->vc_origin && pos < vc->vc_scr_end) {
+ /*
+* Desired position falls in the main screen buffer.
+* However the actual row/col might be different if
+* scrollback is active.
+*/
+ row = (pos - vc->vc_origin) / vc->vc_size_row;
+ col = ((pos - vc->vc_origin) % vc->vc_size_row) / 2;
+ memcpy(dest, &uniscr->lines[row][col], nr * sizeof(char32_t));
+ } else {
+ /*
+* Scrollback is active. For now let's simply backtranslate
+* the screen glyphs until the unicode screen buffer does
+* synchronize with console display drivers for a scrollback
+* buffer of its own.
+*/
+ u16 *p = (u16 *)pos;
+ int mask = vc->vc_hi_font_mask | 0xff;
+ char32_t *uni_buf = dest;
+ while (nr--) {
+ u16 glyph = scr_readw(p++) & mask;
+ *uni_buf++ = inverse_translate(vc, glyph, true);
+ }
+ }
}
diff --git a/include/linux/selection.h b/include/linux/selection.h
index 2b34df9f1e..067d2e99c7 100644
--- a/include/linux/selection.h
+++ b/include/linux/selection.h
@@ -43,7 +43,7 @@ extern void vcs_scr_writew(struct vc_data *vc, u16 val, u16
*org);
extern void vcs_scr_updated(struct vc_data *vc);
extern int vc_uniscr_check(struct vc_data *vc);
-extern void vc_uniscr_copy_line(struct vc_data *vc, void *dest,
+extern void vc_uniscr_copy_line(struct vc_data *vc, void *dest, int viewed,
unsigned int row, unsigned int col,
unsigned int nr);
--
2.17.0
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] vt: perform safe console erase only once
Commit f8df13e0a9 ("tty: Clean console safely") added code to clear
both the scrollback buffer and the screen with "\e[3J", then execution
falls through into the code to simply clear the screen. This means
scr_memsetw() and the console driver update callback is called twice
on the whole screen buffer. Let's reorganize the code so the same work
is not performed twice.
Signed-off-by: Nicolas Pitre
---
drivers/tty/vt/vt.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index f97251f39c..1eb1a376a0 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1178,15 +1178,8 @@ static void csi_J(struct vc_data *vc, int vpar)
count = ((vc->vc_pos - vc->vc_origin) >> 1) + 1;
start = (unsigned short *)vc->vc_origin;
break;
- case 3: /* erase scroll-back buffer (and whole display) */
- scr_memsetw(vc->vc_screenbuf, vc->vc_video_erase_char,
- vc->vc_screenbuf_size);
- flush_scrollback(vc);
- set_origin(vc);
- if (con_is_visible(vc))
- update_screen(vc);
- /* fall through */
case 2: /* erase whole display */
+ case 3: /* (and scrollback buffer later) */
count = vc->vc_cols * vc->vc_rows;
start = (unsigned short *)vc->vc_origin;
break;
@@ -1194,7 +1187,12 @@ static void csi_J(struct vc_data *vc, int vpar)
return;
}
scr_memsetw(start, vc->vc_video_erase_char, 2 * count);
- if (con_should_update(vc))
+ if (vpar == 3) {
+ set_origin(vc);
+ flush_scrollback(vc);
+ if (con_is_visible(vc))
+ update_screen(vc);
+ } else if (con_should_update(vc))
do_update_region(vc, (unsigned long) start, count);
vc->vc_need_wrap = 0;
}
--
2.17.0
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging:iio:accel: use sign extend function avoiding code duplication
On Mon, 2018-06-11 at 00:09 +0200, Karim Eshapa wrote: > Use sign_extend32 kernel function instead of code duplication. > This function is also safe for 16 bits. Firstly: This file is not in staging anymore. Please use the -next tree for patches. > diff --git a/drivers/staging/iio/accel/adis16201.c > b/drivers/staging/iio/accel/adis16201.c [] > @@ -227,9 +227,7 @@ static int adis16201_read_raw(struct iio_dev *indio_dev, > ret = adis_read_reg_16(st, addr, &val16); > if (ret) > return ret; > - val16 &= (1 << bits) - 1; > - val16 = (s16)(val16 << (16 - bits)) >> (16 - bits); > - *val = val16; > + *val = sign_extend32(val16, bits); > return IIO_VAL_INT; > } Secondly: A similar patch with a different bits value was already applied. Please verify the appropriate bits value. commit e7f3bfb7eb7d9307c0c157f82fceb228f0aec1d9 Author: Himanshu Jha Date: Sat Mar 17 01:36:23 2018 +0530 Staging: iio: accel: adis16201: Use sign_extend32 function Use sign_extned32() for 32 bit sign extending rather than hard coding. Signed-off-by: Himanshu Jha Signed-off-by: Jonathan Cameron --- drivers/staging/iio/accel/adis16201.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/staging/iio/accel/adis16201.c b/drivers/staging/iio/accel/adis16201.c index 87ad3d421c12..526dde481f84 100644 --- a/drivers/staging/iio/accel/adis16201.c +++ b/drivers/staging/iio/accel/adis16201.c @@ -173,9 +173,8 @@ static int adis16201_read_raw(struct iio_dev *indio_dev, ret = adis_read_reg_16(st, addr, &val16); if (ret) return ret; - val16 &= (1 << bits) - 1; - val16 = (s16)(val16 << (16 - bits)) >> (16 - bits); - *val = val16; + + *val = sign_extend32(val16, bits - 1); return IIO_VAL_INT; }
[GIT PULL] RTC for 4.18
Hi Linus, Here is the pull-request for the RTC subsystem for 4.18. Setting the supported range from drivers for RTCs failing soon has started. A few fixes are developed along the way. Some drivers have been switched to SPDX by their maintainers. The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338: Linux 4.17-rc1 (2018-04-15 18:24:20 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/rtc-4.18 for you to fetch changes up to e4302aec8a0646828a701443e303eb5ef48b37f5: rtc: pxa: fix probe function (2018-06-07 20:11:08 +0200) RTC for 4.18 Subsystem: - rework of the rtc-test driver which allows to test the core more thoroughly - rtc_set_alarm() now fails early when alarms are not supported Drivers: - mktime is now replaced by mktime64 - RTC range added for 88pm80x, ab-b5ze-s3, at91rm9200, brcmstb-waketimer, ds1685, ftrtc010, ls1x, mxc_v2, rx8581, sprd, st-lpc, tps6586x, tps65910 and vr41xx - Fixed a possible race condition in probe functions - pxa: fix the probe function that is broken since v4.3 - stm32: now supports stm32mp1 Alexandre Belloni (49): rtc: nvmem: don't return an error when not enabled rtc: at91rm9200: add range rtc: 88pm80x: stop setting a default time rtc: 88pm80x: remove unused pm80x_rtc_info members rtc: 88pm80x: fix possible race condition rtc: 88pm80x: let the core handle the RTC range rtc: 88pm80x: convert to rtc_tm_to_time64/rtc_time64_to_tm rtc: ab-b5ze-s3: fix possible race conditions rtc: ab-b5ze-s3: let the core handle the RTC range rtc: tps65910: fix possible race condition rtc: tps65910: allow platform power up rtc: tps65910: add range rtc: rx8581: switch to rtc_register_device rtc: rx8581: add RTC range rtc: rx8581: let the core handle rtc range rtc: rx8581: remove useless indirection rtc: rx8581: remove useless declaration rtc: rx8581: error out when time invalid rtc: rx8581: switch to regmap rtc: vr41xx: fix possible race condition rtc: vr41xx: add range rtc: tps6586x: fix possible race condition rtc: tps6586x: let the core handle rtc range rtc: ls1x: switch to rtc_register_device rtc: ls1x: remove useless label and goto rtc: ls1x: add range rtc: mxc_v2: fix possible race condition rtc: mxc_v2: let the core handle rtc range rtc: mxc_v2: use rtc_time64_to_tm in mxc_rtc_read_alarm rtc: brcmstb-waketimer: switch to rtc_register_device rtc: brcmstb-waketimer: add range rtc: st-lpc: fix possible race condition rtc: st-lpc: add range rtc: test: remove obsolete .set_mmss rtc: ds1685: fix possible race condition rtc: ds1685: Add range rtc: test: remove useless proc info rtc: test: allow registering many devices rtc: test: store time as an offset to system time rtc: test: emulate alarms using timers rtc: test: remove irq sysfs file rtc: sunxi: fix possible race condition rtc: mrst: switch to devm functions rtc: ftrtc010: switch to devm_rtc_allocate_device rtc: ftrtc010: handle dates after 2106 rtc: ftrtc010: let the core handle range rtc: test: convert to devm_rtc_allocate_device rtc: test: remove alarm support from the first device rtc: ensure rtc_set_alarm fails when alarms are not supported Amelie Delaunay (8): rtc: stm32: fix copyright and adopt SPDX identifier rtc: stm32: fix alarm interrupt flags by removing IRQF_TRIGGER_RISING dt-bindings: rtc: update stm32-rtc documentation for st, syscfg property rtc: stm32: get DBP register and mask from DT st, syscfg property rtc: stm32: fix misspelling and misalignment issues rtc: stm32: rework register management to prepare other version of RTC dt-bindings: rtc: update stm32-rtc documentation for stm32mp1 rtc rtc: stm32: add stm32mp1 rtc support Andrea Greco (1): rtc: ds1340: Add support for trickle charger. Arnd Bergmann (3): rtc: vr41xx: remove mktime usage rtc: ls1x: remove mktime usage rtc: tps6586x: remove mktime usage Baolin Wang (3): rtc: sprd: Change to use devm_rtc_allocate_device() rtc: sprd: Add RTC hardware range rtc: sprd: Add new RTC power down check method Dan Carpenter (1): rtc: pxa: fix probe function Enric Balletbo i Serra (2): rtc: cros-ec: Make license text and module license match. rtc: cros-ec: Switch to SPDX identifier. Fabio Estevam (3): dt-bindings: rtc-2123: Make the node name generic rtc: snvs: Switch to SPDX identifier rtc: mxc: Switch to SPDX identifier Mathieu Malaterre (1): rtc: jz4740: Fix a typo in Kconfig Michael Trimarchi (1): rtc:
[PATCH] staging:iio:accel: use sign extend function avoiding code duplication
Use sign_extend32 kernel function instead of code duplication. This function is also safe for 16 bits. Signed-off-by: Karim Eshapa --- drivers/staging/iio/accel/adis16201.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/staging/iio/accel/adis16201.c b/drivers/staging/iio/accel/adis16201.c index 0fae8aaf1cf4..fe4494e65395 100644 --- a/drivers/staging/iio/accel/adis16201.c +++ b/drivers/staging/iio/accel/adis16201.c @@ -227,9 +227,7 @@ static int adis16201_read_raw(struct iio_dev *indio_dev, ret = adis_read_reg_16(st, addr, &val16); if (ret) return ret; - val16 &= (1 << bits) - 1; - val16 = (s16)(val16 << (16 - bits)) >> (16 - bits); - *val = val16; + *val = sign_extend32(val16, bits); return IIO_VAL_INT; } -- 2.17.1
Re: Grant-
I Mikhail Fridman. has selected you specially as one of my beneficiaries for my Charitable Donation, Just as I have declared on May 23, 2016 to give my fortune as charity. Check the link below for confirmation: http://www.ibtimes.co.uk/russias-second-wealthiest-man-mikhail-fridman-plans-leaving-14-2bn-fortune-charity-1561604 Reply as soon as possible with further directives. Best Regards, Mikhail Fridman.
[PATCH v3 1/9] Makefile: Prepare for using macros for inline asm
Using macros for inline assembly improves both readability and compilation decisions that are distorted by big assembly blocks that use alternative sections. Compile macros.S and use it to assemble all C files. Currently, only x86 will use it. Cc: Masahiro Yamada Cc: Michal Marek Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: linux-kbu...@vger.kernel.org Signed-off-by: Nadav Amit --- Makefile | 9 +++-- arch/x86/Makefile| 11 +-- arch/x86/kernel/Makefile | 6 ++ arch/x86/kernel/macros.S | 7 +++ scripts/Kbuild.include | 4 +++- 5 files changed, 32 insertions(+), 5 deletions(-) create mode 100644 arch/x86/kernel/macros.S diff --git a/Makefile b/Makefile index 554dcaddbce4..026586db2f26 100644 --- a/Makefile +++ b/Makefile @@ -1085,7 +1085,7 @@ scripts: scripts_basic include/config/auto.conf include/config/tristate.conf \ # version.h and scripts_basic is processed / created. # Listed in dependency order -PHONY += prepare archprepare prepare0 prepare1 prepare2 prepare3 +PHONY += prepare archprepare macroprepare prepare0 prepare1 prepare2 prepare3 # prepare3 is used to check if we are building in a separate output directory, # and if so do: @@ -1109,7 +1109,9 @@ prepare1: prepare2 $(version_h) $(autoksyms_h) include/generated/utsrelease.h \ include/config/auto.conf $(cmd_crmodverdir) -archprepare: archheaders archscripts prepare1 scripts_basic +macroprepare: prepare1 archmacros + +archprepare: archheaders archscripts macroprepare scripts_basic prepare0: archprepare gcc-plugins $(Q)$(MAKE) $(build)=. @@ -1214,6 +1216,9 @@ archheaders: PHONY += archscripts archscripts: +PHONY += archmacros +archmacros: + PHONY += __headers __headers: $(version_h) scripts_basic uapi-asm-generic archheaders archscripts $(Q)$(MAKE) $(build)=scripts build_unifdef diff --git a/arch/x86/Makefile b/arch/x86/Makefile index 60135cbd905c..6b82314776fd 100644 --- a/arch/x86/Makefile +++ b/arch/x86/Makefile @@ -235,8 +235,8 @@ ifdef CONFIG_X86_64 LDFLAGS += $(call ld-option, -z max-page-size=0x20) endif -# Speed up the build -KBUILD_CFLAGS += -pipe +# We cannot use -pipe flag since we give an additional .s file to the compiler +#KBUILD_CFLAGS += -pipe # Workaround for a gcc prelease that unfortunately was shipped in a suse release KBUILD_CFLAGS += -Wno-sign-compare # @@ -258,11 +258,18 @@ archscripts: scripts_basic archheaders: $(Q)$(MAKE) $(build)=arch/x86/entry/syscalls all +archmacros: + $(Q)$(MAKE) $(build)=arch/x86/kernel macros + archprepare: ifeq ($(CONFIG_KEXEC_FILE),y) $(Q)$(MAKE) $(build)=arch/x86/purgatory arch/x86/purgatory/kexec-purgatory.c endif +ASM_MACRO_FLAGS = -Wa,arch/x86/kernel/macros.s +export ASM_MACRO_FLAGS +KBUILD_CFLAGS += $(ASM_MACRO_FLAGS) + ### # Kernel objects diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile index 02d6f5cf4e70..fdb6c5b2a922 100644 --- a/arch/x86/kernel/Makefile +++ b/arch/x86/kernel/Makefile @@ -9,6 +9,12 @@ extra-y+= ebda.o extra-y+= platform-quirks.o extra-y+= vmlinux.lds +$(obj)/macros.s: $(obj)/macros.S FORCE + $(call if_changed_dep,cpp_s_S) + +macros: $(obj)/macros.s + @: + CPPFLAGS_vmlinux.lds += -U$(UTS_MACHINE) ifdef CONFIG_FUNCTION_TRACER diff --git a/arch/x86/kernel/macros.S b/arch/x86/kernel/macros.S new file mode 100644 index ..cfc1c7d1a6eb --- /dev/null +++ b/arch/x86/kernel/macros.S @@ -0,0 +1,7 @@ +/* SPDX-License-Identifier: GPL-2.0 */ + +/* + * This file includes headers whose assembly part includes macros which are + * commonly used. The macros are precompiled into assmebly file which is later + * assembled together with each compiled file. + */ diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include index 50cee534fd64..ad2c02062aa4 100644 --- a/scripts/Kbuild.include +++ b/scripts/Kbuild.include @@ -189,7 +189,9 @@ __cc-option = $(call try-run-cached,\ # Do not attempt to build with gcc plugins during cc-option tests. # (And this uses delayed resolution so the flags will be up to date.) -CC_OPTION_CFLAGS = $(filter-out $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS)) +# In addition, do not include the asm macros which are built later. +CC_OPTION_FILTERED = $(GCC_PLUGINS_CFLAGS) $(ASM_MACRO_FLAGS) +CC_OPTION_CFLAGS = $(filter-out $(CC_OPTION_FILTERED),$(KBUILD_CFLAGS)) # cc-option # Usage: cflags-y += $(call cc-option,-march=winchip-c6,-march=i586) -- 2.17.0
[PATCH v3 3/9] x86: refcount: prevent gcc distortions
GCC considers the number of statements in inlined assembly blocks,
according to new-lines and semicolons, as an indication to the cost of
the block in time and space. This data is distorted by the kernel code,
which puts information in alternative sections. As a result, the
compiler may perform incorrect inlining and branch optimizations.
The solution is to set an assembly macro and call it from the inlined
assembly block. As a result GCC considers the inline assembly block as
a single instruction.
This patch allows to inline functions such as __get_seccomp_filter().
Interestingly, this allows more aggressive inlining while reducing the
kernel size.
textdata bss dec hex filename
18140970 10225412 2957312 31323694 1ddf62e ./vmlinux before
18140140 10225284 2957312 31322736 1ddf270 ./vmlinux after (-958)
Static text symbols:
Before: 40302
After: 40286 (-16)
Functions such as kref_get(), free_user(), fuse_file_get() now get
inlined.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Kees Cook
Cc: Jan Beulich
Cc: Josh Poimboeuf
Signed-off-by: Nadav Amit
---
arch/x86/include/asm/refcount.h | 74 -
arch/x86/kernel/macros.S| 1 +
2 files changed, 46 insertions(+), 29 deletions(-)
diff --git a/arch/x86/include/asm/refcount.h b/arch/x86/include/asm/refcount.h
index 4cf11d88d3b3..6b2809a4d8e9 100644
--- a/arch/x86/include/asm/refcount.h
+++ b/arch/x86/include/asm/refcount.h
@@ -4,6 +4,41 @@
* x86-specific implementation of refcount_t. Based on PAX_REFCOUNT from
* PaX/grsecurity.
*/
+
+#ifdef __ASSEMBLY__
+
+#include
+#include
+
+.macro REFCOUNT_EXCEPTION counter:req
+ .pushsection .text..refcount
+111: lea \counter, %_ASM_CX
+112: ud2
+ ASM_UNREACHABLE
+ .popsection
+113: _ASM_EXTABLE_REFCOUNT(112b, 113b)
+.endm
+
+/* Trigger refcount exception if refcount result is negative. */
+.macro REFCOUNT_CHECK_LT_ZERO counter:req
+ js 111f
+ REFCOUNT_EXCEPTION counter="\counter"
+.endm
+
+/* Trigger refcount exception if refcount result is zero or negative. */
+.macro REFCOUNT_CHECK_LE_ZERO counter:req
+ jz 111f
+ REFCOUNT_CHECK_LT_ZERO counter="\counter"
+.endm
+
+/* Trigger refcount exception unconditionally. */
+.macro REFCOUNT_ERROR counter:req
+ jmp 111f
+ REFCOUNT_EXCEPTION counter="\counter"
+.endm
+
+#else /* __ASSEMBLY__ */
+
#include
/*
@@ -14,34 +49,11 @@
* central refcount exception. The fixup address for the exception points
* back to the regular execution flow in .text.
*/
-#define _REFCOUNT_EXCEPTION\
- ".pushsection .text..refcount\n"\
- "111:\tlea %[counter], %%" _ASM_CX "\n" \
- "112:\t" ASM_UD2 "\n" \
- ASM_UNREACHABLE \
- ".popsection\n" \
- "113:\n"\
- _ASM_EXTABLE_REFCOUNT(112b, 113b)
-
-/* Trigger refcount exception if refcount result is negative. */
-#define REFCOUNT_CHECK_LT_ZERO \
- "js 111f\n\t" \
- _REFCOUNT_EXCEPTION
-
-/* Trigger refcount exception if refcount result is zero or negative. */
-#define REFCOUNT_CHECK_LE_ZERO \
- "jz 111f\n\t" \
- REFCOUNT_CHECK_LT_ZERO
-
-/* Trigger refcount exception unconditionally. */
-#define REFCOUNT_ERROR \
- "jmp 111f\n\t" \
- _REFCOUNT_EXCEPTION
static __always_inline void refcount_add(unsigned int i, refcount_t *r)
{
asm volatile(LOCK_PREFIX "addl %1,%0\n\t"
- REFCOUNT_CHECK_LT_ZERO
+ "REFCOUNT_CHECK_LT_ZERO counter=\"%[counter]\""
: [counter] "+m" (r->refs.counter)
: "ir" (i)
: "cc", "cx");
@@ -50,7 +62,7 @@ static __always_inline void refcount_add(unsigned int i,
refcount_t *r)
static __always_inline void refcount_inc(refcount_t *r)
{
asm volatile(LOCK_PREFIX "incl %0\n\t"
- REFCOUNT_CHECK_LT_ZERO
+ "REFCOUNT_CHECK_LT_ZERO counter=\"%[counter]\""
: [counter] "+m" (r->refs.counter)
: : "cc", "cx");
}
@@ -58,7 +70,7 @@ static __always_inline void refcount_inc(refcount_t *r)
static __always_inline void refcount_dec(refcount_t *r)
{
asm volatile(LOCK_PREFIX "decl %0\n\t"
- REFCOUNT_CHECK_LE_ZERO
+ "REFCOUNT_CHECK_LE_ZERO counter=\"%[counter]\""
: [counter] "+m" (r->refs.counter)
: : "cc", "cx");
}
@@ -66,13 +78,15 @@ static __always_inline void refcount_dec(refcount_t *r)
static __always_inline __must_check
bool refcount_sub_and_test(unsigned int i, refcount_t *r)
{
- GEN_BINARY_SUFFIXED_RMWcc(LOCK_PREFIX
[PATCH v3 4/9] x86: alternatives: macrofy locks for better inlining
GCC considers the number of statements in inlined assembly blocks, according to new-lines and semicolons, as an indication to the cost of the block in time and space. This data is distorted by the kernel code, which puts information in alternative sections. As a result, the compiler may perform incorrect inlining and branch optimizations. The solution is to set an assembly macro and call it from the inlined assembly block. As a result GCC considers the inline assembly block as a single instruction. This patch handles the LOCK prefix, allowing more aggresive inlining. textdata bss dec hex filename 18140140 10225284 2957312 31322736 1ddf270 ./vmlinux before 18146889 10225380 2957312 31329581 1de0d2d ./vmlinux after (+6845) Static text symbols: Before: 40286 After: 40218 (-68) Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: Josh Poimboeuf Signed-off-by: Nadav Amit --- arch/x86/include/asm/alternative-asm.h | 20 ++-- arch/x86/include/asm/alternative.h | 11 ++- arch/x86/kernel/macros.S | 1 + 3 files changed, 17 insertions(+), 15 deletions(-) diff --git a/arch/x86/include/asm/alternative-asm.h b/arch/x86/include/asm/alternative-asm.h index 31b627b43a8e..8e4ea39e55d0 100644 --- a/arch/x86/include/asm/alternative-asm.h +++ b/arch/x86/include/asm/alternative-asm.h @@ -7,16 +7,24 @@ #include #ifdef CONFIG_SMP - .macro LOCK_PREFIX -672: lock +.macro LOCK_PREFIX_HERE .pushsection .smp_locks,"a" .balign 4 - .long 672b - . + .long 671f - . # offset .popsection - .endm +671: +.endm + +.macro LOCK_PREFIX insn:vararg + LOCK_PREFIX_HERE + lock \insn +.endm #else - .macro LOCK_PREFIX - .endm +.macro LOCK_PREFIX_HERE +.endm + +.macro LOCK_PREFIX insn:vararg +.endm #endif /* diff --git a/arch/x86/include/asm/alternative.h b/arch/x86/include/asm/alternative.h index 4cd6a3b71824..d7faa16622d8 100644 --- a/arch/x86/include/asm/alternative.h +++ b/arch/x86/include/asm/alternative.h @@ -31,15 +31,8 @@ */ #ifdef CONFIG_SMP -#define LOCK_PREFIX_HERE \ - ".pushsection .smp_locks,\"a\"\n" \ - ".balign 4\n" \ - ".long 671f - .\n" /* offset */ \ - ".popsection\n" \ - "671:" - -#define LOCK_PREFIX LOCK_PREFIX_HERE "\n\tlock; " - +#define LOCK_PREFIX_HERE "LOCK_PREFIX_HERE\n\t" +#define LOCK_PREFIX "LOCK_PREFIX " #else /* ! CONFIG_SMP */ #define LOCK_PREFIX_HERE "" #define LOCK_PREFIX "" diff --git a/arch/x86/kernel/macros.S b/arch/x86/kernel/macros.S index f1fe1d570365..852487a9fc56 100644 --- a/arch/x86/kernel/macros.S +++ b/arch/x86/kernel/macros.S @@ -8,3 +8,4 @@ #include #include +#include -- 2.17.0
[PATCH v3 5/9] x86: bug: prevent gcc distortions
GCC considers the number of statements in inlined assembly blocks,
according to new-lines and semicolons, as an indication to the cost of
the block in time and space. This data is distorted by the kernel code,
which puts information in alternative sections. As a result, the
compiler may perform incorrect inlining and branch optimizations.
The solution is to set an assembly macro and call it from the inlinedv
assembly block. As a result GCC considers the inline assembly block as
a single instruction.
This patch increases the kernel size:
textdata bss dec hex filename
18146889 10225380 2957312 31329581 1de0d2d ./vmlinux before
18147336 10226688 2957312 31331336 1de1408 ./vmlinux after (+1755)
But enables more aggressive inlining (and probably branch decisions).
The number of static text symbols in vmlinux is lower.
Static text symbols:
Before: 40218
After: 40053 (-165)
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Peter Zijlstra
Cc: Josh Poimboeuf
Signed-off-by: Nadav Amit
---
arch/x86/include/asm/bug.h | 98 ++
arch/x86/kernel/macros.S | 1 +
include/asm-generic/bug.h | 8 ++--
3 files changed, 61 insertions(+), 46 deletions(-)
diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
index 6804d6642767..5090035e6d16 100644
--- a/arch/x86/include/asm/bug.h
+++ b/arch/x86/include/asm/bug.h
@@ -4,6 +4,8 @@
#include
+#ifndef __ASSEMBLY__
+
/*
* Despite that some emulators terminate on UD2, we use it for WARN().
*
@@ -20,53 +22,15 @@
#define LEN_UD22
-#ifdef CONFIG_GENERIC_BUG
-
-#ifdef CONFIG_X86_32
-# define __BUG_REL(val)".long " __stringify(val)
-#else
-# define __BUG_REL(val)".long " __stringify(val) " - 2b"
-#endif
-
-#ifdef CONFIG_DEBUG_BUGVERBOSE
-
-#define _BUG_FLAGS(ins, flags) \
-do { \
- asm volatile("1:\t" ins "\n"\
-".pushsection __bug_table,\"aw\"\n"\
-"2:\t" __BUG_REL(1b) "\t# bug_entry::bug_addr\n" \
-"\t" __BUG_REL(%c0) "\t# bug_entry::file\n" \
-"\t.word %c1""\t# bug_entry::line\n" \
-"\t.word %c2""\t# bug_entry::flags\n" \
-"\t.org 2b+%c3\n" \
-".popsection" \
-: : "i" (__FILE__), "i" (__LINE__),\
-"i" (flags), \
-"i" (sizeof(struct bug_entry))); \
-} while (0)
-
-#else /* !CONFIG_DEBUG_BUGVERBOSE */
-
#define _BUG_FLAGS(ins, flags) \
do { \
- asm volatile("1:\t" ins "\n"\
-".pushsection __bug_table,\"aw\"\n"\
-"2:\t" __BUG_REL(1b) "\t# bug_entry::bug_addr\n" \
-"\t.word %c0""\t# bug_entry::flags\n" \
-"\t.org 2b+%c1\n" \
-".popsection" \
-: : "i" (flags), \
+ asm volatile("ASM_BUG ins=\"" ins "\" file=%c0 line=%c1 " \
+"flags=%c2 size=%c3" \
+: : "i" (__FILE__), "i" (__LINE__),\
+"i" (flags), \
"i" (sizeof(struct bug_entry))); \
} while (0)
-#endif /* CONFIG_DEBUG_BUGVERBOSE */
-
-#else
-
-#define _BUG_FLAGS(ins, flags) asm volatile(ins)
-
-#endif /* CONFIG_GENERIC_BUG */
-
#define HAVE_ARCH_BUG
#define BUG() \
do { \
@@ -82,4 +46,54 @@ do {
\
#include
+#else /* __ASSEMBLY__ */
+
+#ifdef CONFIG_GENERIC_BUG
+
+#ifdef CONFIG_X86_32
+.macro __BUG_REL val:req
+ .long \val
+.endm
+#else
+.macro __BUG_REL val:req
+ .long \val - 2b
+.endm
+#endif
+
+#ifdef CONFIG_DEBUG_BUGVERBOSE
+
+.macro ASM_BUG ins:req file:req line:req flags:req size:req
+1: \ins
+ .pushsection __bug_table,"aw"
+2: __BUG_REL val=1b# bug_entry::bug_addr
+ __BUG_REL val=\file # bug_entry::file
+ .word \line # bug_entry::line
+ .word \flags# bug_entry::flags
+ .org 2b+\size
+ .popsection
+.endm
+
+#else /* !CONFIG_DEBUG_BUGVERBOSE */
+
+.macro ASM_BUG ins:req file:req line:req
[PATCH v3 0/9] x86: macrofying inline asm for better compilation
This patch-set deals with an interesting yet stupid problem: kernel code that does not get inlined despite its simplicity. There are several causes for this behavior: "cold" attribute on __init, different function optimization levels; conditional constant computations based on __builtin_constant_p(); and finally large inline assembly blocks. This patch-set deals with the inline assembly problem. I separated these patches from the others (that were sent in the RFC) for easier inclusion. I also separated the removal of unnecessary new-lines which would be sent separately. The problem with inline assembly is that inline assembly is often used by the kernel for things that are other than code - for example, assembly directives and data. GCC however is oblivious to the content of the blocks and assumes their cost in space and time is proportional to the number of the perceived assembly "instruction", according to the number of newlines and semicolons. Alternatives, paravirt and other mechanisms are affected, causing code not to be inlined, and degrading compilation quality in general. The solution that this patch-set carries for this problem is to create an assembly macro, and then call it from the inline assembly block. As a result, the compiler sees a single "instruction" and assigns the more appropriate cost to the code. To avoid uglification of the code, as many noted, the macros are first precompiled into an assembly file, which is later assembled together with the the C files. This also enables to avoid duplicate implementation that was set before for the asm and C code. This can be seen in the exception table changes. Overall this patch-set slightly increases the kernel size (my build was done using my Ubuntu 18.04 config + localyesconfig for the record): textdata bss dec hex filename 18140829 10224724 2957312 31322865 1ddf2f1 ./vmlinux before 18163608 10227348 2957312 31348268 1de562c ./vmlinux after (+0.1%) The number of static functions in the image is reduced by 379, but actually inlining is even better, which does not always shows in these numbers: a function may be inlined causing the calling function not to be inlined. The Makefile stuff may not be too clean. Ideas for improvements are welcome. v2->v3: * Several build issues resolved (0-day) * Wrong comments fix (Josh) * Change asm vs C order in refcount (Kees) v1->v2: * Compiling the macros into a separate .s file, improving readability (Linus) * Improving assembly formatting, applying most of the comments according to my judgment (Jan) * Adding exception-table, cpufeature and jump-labels * Removing new-line cleanup; to be submitted separately Cc: Alok Kataria Cc: Christopher Li Cc: Greg Kroah-Hartman Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jan Beulich Cc: Josh Poimboeuf Cc: Juergen Gross Cc: Kate Stewart Cc: Kees Cook Cc: linux-spa...@vger.kernel.org Cc: Peter Zijlstra Cc: Philippe Ombredanne Cc: Thomas Gleixner Cc: virtualizat...@lists.linux-foundation.org Cc: Linus Torvalds Cc: x...@kernel.org Nadav Amit (9): Makefile: Prepare for using macros for inline asm x86: objtool: use asm macro for better compiler decisions x86: refcount: prevent gcc distortions x86: alternatives: macrofy locks for better inlining x86: bug: prevent gcc distortions x86: prevent inline distortion by paravirt ops x86: extable: use macros instead of inline assembly x86: cpufeature: use macros instead of inline assembly x86: jump-labels: use macros instead of inline assembly Makefile | 9 ++- arch/x86/Makefile | 11 ++- arch/x86/include/asm/alternative-asm.h | 20 -- arch/x86/include/asm/alternative.h | 11 +-- arch/x86/include/asm/asm.h | 61 +++- arch/x86/include/asm/bug.h | 98 +++--- arch/x86/include/asm/cpufeature.h | 82 - arch/x86/include/asm/jump_label.h | 65 ++--- arch/x86/include/asm/paravirt_types.h | 54 +++--- arch/x86/include/asm/refcount.h| 74 +++ arch/x86/kernel/Makefile | 6 ++ arch/x86/kernel/macros.S | 16 + include/asm-generic/bug.h | 8 +-- include/linux/compiler.h | 56 +++ scripts/Kbuild.include | 4 +- 15 files changed, 347 insertions(+), 228 deletions(-) create mode 100644 arch/x86/kernel/macros.S -- 2.17.0
[PATCH v3 2/9] x86: objtool: use asm macro for better compiler decisions
GCC considers the number of statements in inlined assembly blocks,
according to new-lines and semicolons, as an indication to the cost of
the block in time and space. This data is distorted by the kernel code,
which puts information in alternative sections. As a result, the
compiler may perform incorrect inlining and branch optimizations.
In the case of objtool, this distortion is extreme, since anyhow the
annotations of objtool are discarded during linkage.
The solution is to set an assembly macro and call it from the inline
assembly block. As a result GCC considers the inline assembly block as
a single instruction.
This patch slightly increases the kernel size.
textdata bss dec hex filename
18140829 10224724 2957312 31322865 1ddf2f1 ./vmlinux before
18140970 10225412 2957312 31323694 1ddf62e ./vmlinux after (+829)
Static text symbols:
Before: 40321
After: 40302 (-19)
Cc: Christopher Li
Cc: linux-spa...@vger.kernel.org
Reviewed-by: Josh Poimboeuf
Signed-off-by: Nadav Amit
---
arch/x86/kernel/macros.S | 2 ++
include/linux/compiler.h | 56 ++--
2 files changed, 45 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/macros.S b/arch/x86/kernel/macros.S
index cfc1c7d1a6eb..cee28c3246dc 100644
--- a/arch/x86/kernel/macros.S
+++ b/arch/x86/kernel/macros.S
@@ -5,3 +5,5 @@
* commonly used. The macros are precompiled into assmebly file which is later
* assembled together with each compiled file.
*/
+
+#include
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index ab4711c63601..3efd85334774 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -99,22 +99,13 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int
val,
* unique, to convince GCC not to merge duplicate inline asm statements.
*/
#define annotate_reachable() ({
\
- asm volatile("%c0:\n\t" \
-".pushsection .discard.reachable\n\t" \
-".long %c0b - .\n\t" \
-".popsection\n\t" : : "i" (__COUNTER__)); \
+ asm volatile("ANNOTATE_REACHABLE counter=%c0" \
+: : "i" (__COUNTER__));\
})
#define annotate_unreachable() ({ \
- asm volatile("%c0:\n\t" \
-".pushsection .discard.unreachable\n\t"\
-".long %c0b - .\n\t" \
-".popsection\n\t" : : "i" (__COUNTER__)); \
+ asm volatile("ANNOTATE_UNREACHABLE counter=%c0" \
+: : "i" (__COUNTER__));\
})
-#define ASM_UNREACHABLE
\
- "999:\n\t" \
- ".pushsection .discard.unreachable\n\t" \
- ".long 999b - .\n\t"\
- ".popsection\n\t"
#else
#define annotate_reachable()
#define annotate_unreachable()
@@ -280,6 +271,45 @@ unsigned long read_word_at_a_time(const void *addr)
#endif /* __KERNEL__ */
+#else /* __ASSEMBLY__ */
+
+#ifdef __KERNEL__
+#ifndef LINKER_SCRIPT
+
+#ifdef CONFIG_STACK_VALIDATION
+.macro ANNOTATE_UNREACHABLE counter:req
+\counter:
+ .pushsection .discard.unreachable
+ .long \counter\()b -.
+ .popsection
+.endm
+
+.macro ANNOTATE_REACHABLE counter:req
+\counter:
+ .pushsection .discard.reachable
+ .long \counter\()b -.
+ .popsection
+.endm
+
+.macro ASM_UNREACHABLE
+999:
+ .pushsection .discard.unreachable
+ .long 999b - .
+ .popsection
+.endm
+#else /* CONFIG_STACK_VALIDATION */
+.macro ANNOTATE_UNREACHABLE counter:req
+.endm
+
+.macro ANNOTATE_REACHABLE counter:req
+.endm
+
+.macro ASM_UNREACHABLE
+.endm
+#endif /* CONFIG_STACK_VALIDATION */
+
+#endif /* LINKER_SCRIPT */
+#endif /* __KERNEL__ */
#endif /* __ASSEMBLY__ */
#ifndef __optimize
--
2.17.0
[PATCH v3 9/9] x86: jump-labels: use macros instead of inline assembly
Use assembly macros for jump-labels and call them from inline assembly.
This not only makes the code more readable, but also improves
compilation decision, specifically inline decisions which GCC base on
the number of new lines in inline assembly.
As a result the code size is slightly increased.
textdata bss dec hex filename
18163528 10226300 2957312 31347140 1de51c4 ./vmlinux before
18163608 10227348 2957312 31348268 1de562c ./vmlinux after (+1128)
And functions such as intel_pstate_adjust_policy_max(),
kvm_cpu_accept_dm_intr(), kvm_register_read() are inlined.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Greg Kroah-Hartman
Cc: Kate Stewart
Cc: Philippe Ombredanne
Signed-off-by: Nadav Amit
---
arch/x86/include/asm/jump_label.h | 65 ++-
arch/x86/kernel/macros.S | 1 +
2 files changed, 39 insertions(+), 27 deletions(-)
diff --git a/arch/x86/include/asm/jump_label.h
b/arch/x86/include/asm/jump_label.h
index 8c0de4282659..ea0633a41122 100644
--- a/arch/x86/include/asm/jump_label.h
+++ b/arch/x86/include/asm/jump_label.h
@@ -2,19 +2,6 @@
#ifndef _ASM_X86_JUMP_LABEL_H
#define _ASM_X86_JUMP_LABEL_H
-#ifndef HAVE_JUMP_LABEL
-/*
- * For better or for worse, if jump labels (the gcc extension) are missing,
- * then the entire static branch patching infrastructure is compiled out.
- * If that happens, the code in here will malfunction. Raise a compiler
- * error instead.
- *
- * In theory, jump labels and the static branch patching infrastructure
- * could be decoupled to fix this.
- */
-#error asm/jump_label.h included on a non-jump-label kernel
-#endif
-
#define JUMP_LABEL_NOP_SIZE 5
#ifdef CONFIG_X86_64
@@ -28,18 +15,27 @@
#ifndef __ASSEMBLY__
+#ifndef HAVE_JUMP_LABEL
+/*
+ * For better or for worse, if jump labels (the gcc extension) are missing,
+ * then the entire static branch patching infrastructure is compiled out.
+ * If that happens, the code in here will malfunction. Raise a compiler
+ * error instead.
+ *
+ * In theory, jump labels and the static branch patching infrastructure
+ * could be decoupled to fix this.
+ */
+#error asm/jump_label.h included on a non-jump-label kernel
+#endif
+
#include
#include
static __always_inline bool arch_static_branch(struct static_key *key, bool
branch)
{
- asm_volatile_goto("1:"
- ".byte " __stringify(STATIC_KEY_INIT_NOP) "\n\t"
- ".pushsection __jump_table, \"aw\" \n\t"
- _ASM_ALIGN "\n\t"
- _ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t"
- ".popsection \n\t"
- : : "i" (key), "i" (branch) : : l_yes);
+ asm_volatile_goto("STATIC_BRANCH_GOTO l_yes=\"%l[l_yes]\" key=\"%c0\" "
+ "branch=\"%c1\""
+ : : "i" (key), "i" (branch) : : l_yes);
return false;
l_yes:
@@ -48,13 +44,8 @@ static __always_inline bool arch_static_branch(struct
static_key *key, bool bran
static __always_inline bool arch_static_branch_jump(struct static_key *key,
bool branch)
{
- asm_volatile_goto("1:"
- ".byte 0xe9\n\t .long %l[l_yes] - 2f\n\t"
- "2:\n\t"
- ".pushsection __jump_table, \"aw\" \n\t"
- _ASM_ALIGN "\n\t"
- _ASM_PTR "1b, %l[l_yes], %c0 + %c1 \n\t"
- ".popsection \n\t"
+ asm_volatile_goto("STATIC_BRANCH_JUMP_GOTO l_yes=\"%l[l_yes]\"
key=\"%c0\" "
+ "branch=\"%c1\""
: : "i" (key), "i" (branch) : : l_yes);
return false;
@@ -108,6 +99,26 @@ struct jump_entry {
.popsection
.endm
+.macro STATIC_BRANCH_GOTO l_yes:req key:req branch:req
+1:
+ .byte STATIC_KEY_INIT_NOP
+ .pushsection __jump_table, "aw"
+ _ASM_ALIGN
+ _ASM_PTR 1b, \l_yes, \key + \branch
+ .popsection
+.endm
+
+.macro STATIC_BRANCH_JUMP_GOTO l_yes:req key:req branch:req
+1:
+ .byte 0xe9
+ .long \l_yes - 2f
+2:
+ .pushsection __jump_table, "aw"
+ _ASM_ALIGN
+ _ASM_PTR 1b, \l_yes, \key + \branch
+ .popsection
+.endm
+
#endif /* __ASSEMBLY__ */
#endif
diff --git a/arch/x86/kernel/macros.S b/arch/x86/kernel/macros.S
index bf8b9c93e255..161c95059044 100644
--- a/arch/x86/kernel/macros.S
+++ b/arch/x86/kernel/macros.S
@@ -13,3 +13,4 @@
#include
#include
#include
+#include
--
2.17.0
[PATCH v3 7/9] x86: extable: use macros instead of inline assembly
Use assembly macros for exception-tables and call them from inline
assembly. This not only makes the code more readable and allows to
avoid the duplicate implementation, but also improves compilation
decision, specifically inline decisions which GCC base on the number of
new lines in inline assembly.
textdata bss dec hex filename
18162555 10226288 2957312 31346155 1de4deb ./vmlinux before
18162879 10226256 2957312 31346447 1de4f0f ./vmlinux after (+292)
This allows to inline functions such as nested_vmx_exit_reflected(),
set_segment_reg(), __copy_xstate_to_user().
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Josh Poimboeuf
Signed-off-by: Nadav Amit
---
arch/x86/include/asm/asm.h | 61 +-
arch/x86/kernel/macros.S | 1 +
2 files changed, 28 insertions(+), 34 deletions(-)
diff --git a/arch/x86/include/asm/asm.h b/arch/x86/include/asm/asm.h
index 219faaec51df..30bc1b0058ef 100644
--- a/arch/x86/include/asm/asm.h
+++ b/arch/x86/include/asm/asm.h
@@ -58,28 +58,44 @@
# define CC_OUT(c) [_cc_ ## c] "=qm"
#endif
-/* Exception table entry */
#ifdef __ASSEMBLY__
# define _ASM_EXTABLE_HANDLE(from, to, handler)\
- .pushsection "__ex_table","a" ; \
- .balign 4 ; \
- .long (from) - . ; \
- .long (to) - . ;\
- .long (handler) - . ; \
- .popsection
+ ASM_EXTABLE_HANDLE from to handler
+
+#else /* __ASSEMBLY__ */
+
+# define _ASM_EXTABLE_HANDLE(from, to, handler)\
+ "ASM_EXTABLE_HANDLE from=" #from " to=" #to \
+ " handler=\"" #handler "\"\n\t"
+
+/* For C file, we already have NOKPROBE_SYMBOL macro */
+
+#endif /* __ASSEMBLY__ */
-# define _ASM_EXTABLE(from, to)\
+#define _ASM_EXTABLE(from, to) \
_ASM_EXTABLE_HANDLE(from, to, ex_handler_default)
-# define _ASM_EXTABLE_FAULT(from, to) \
+#define _ASM_EXTABLE_FAULT(from, to) \
_ASM_EXTABLE_HANDLE(from, to, ex_handler_fault)
-# define _ASM_EXTABLE_EX(from, to) \
+#define _ASM_EXTABLE_EX(from, to) \
_ASM_EXTABLE_HANDLE(from, to, ex_handler_ext)
-# define _ASM_EXTABLE_REFCOUNT(from, to) \
+#define _ASM_EXTABLE_REFCOUNT(from, to)\
_ASM_EXTABLE_HANDLE(from, to, ex_handler_refcount)
+/* Exception table entry */
+#ifdef __ASSEMBLY__
+
+.macro ASM_EXTABLE_HANDLE from:req to:req handler:req
+ .pushsection "__ex_table","a"
+ .balign 4
+ .long (\from) - .
+ .long (\to) - .
+ .long (\handler) - .
+ .popsection
+.endm
+
# define _ASM_NOKPROBE(entry) \
.pushsection "_kprobe_blacklist","aw" ; \
_ASM_ALIGN ;\
@@ -110,29 +126,6 @@
_ASM_EXTABLE(101b,103b)
.endm
-#else
-# define _EXPAND_EXTABLE_HANDLE(x) #x
-# define _ASM_EXTABLE_HANDLE(from, to, handler)\
- " .pushsection \"__ex_table\",\"a\"\n" \
- " .balign 4\n" \
- " .long (" #from ") - .\n" \
- " .long (" #to ") - .\n"\
- " .long (" _EXPAND_EXTABLE_HANDLE(handler) ") - .\n"\
- " .popsection\n"
-
-# define _ASM_EXTABLE(from, to)\
- _ASM_EXTABLE_HANDLE(from, to, ex_handler_default)
-
-# define _ASM_EXTABLE_FAULT(from, to) \
- _ASM_EXTABLE_HANDLE(from, to, ex_handler_fault)
-
-# define _ASM_EXTABLE_EX(from, to) \
- _ASM_EXTABLE_HANDLE(from, to, ex_handler_ext)
-
-# define _ASM_EXTABLE_REFCOUNT(from, to) \
- _ASM_EXTABLE_HANDLE(from, to, ex_handler_refcount)
-
-/* For C file, we already have NOKPROBE_SYMBOL macro */
#endif
#ifndef __ASSEMBLY__
diff --git a/arch/x86/kernel/macros.S b/arch/x86/kernel/macros.S
index 71d8b716b111..7baa40d5bf16 100644
--- a/arch/x86/kernel/macros.S
+++ b/arch/x86/kernel/macros.S
@@ -11,3 +11,4 @@
#include
#include
#include
+#include
--
2.17.0
[PATCH v3 8/9] x86: cpufeature: use macros instead of inline assembly
Use assembly macros for static_cpu_has() and call them from inline
assembly. This not only makes the code more readable, but also improves
compilation decision, specifically inline decisions which GCC base on
the number of new lines in inline assembly.
The patch slightly increases the kernel size:
textdata bss dec hex filename
18162879 10226256 2957312 31346447 1de4f0f ./vmlinux before
18163528 10226300 2957312 31347140 1de51c4 ./vmlinux after (+693)
And enables the inlining of function such as free_ldt_pgtables().
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Peter Zijlstra
Signed-off-by: Nadav Amit
---
arch/x86/include/asm/cpufeature.h | 82 ++-
arch/x86/kernel/macros.S | 1 +
2 files changed, 48 insertions(+), 35 deletions(-)
diff --git a/arch/x86/include/asm/cpufeature.h
b/arch/x86/include/asm/cpufeature.h
index aced6c9290d6..7d442722ef24 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -2,10 +2,10 @@
#ifndef _ASM_X86_CPUFEATURE_H
#define _ASM_X86_CPUFEATURE_H
-#include
-
-#if defined(__KERNEL__) && !defined(__ASSEMBLY__)
+#ifdef __KERNEL__
+#ifndef __ASSEMBLY__
+#include
#include
#include
@@ -161,37 +161,10 @@ extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned
int bit);
*/
static __always_inline __pure bool _static_cpu_has(u16 bit)
{
- asm_volatile_goto("1: jmp 6f\n"
-"2:\n"
-".skip -(((5f-4f) - (2b-1b)) > 0) * "
-"((5f-4f) - (2b-1b)),0x90\n"
-"3:\n"
-".section .altinstructions,\"a\"\n"
-" .long 1b - .\n" /* src offset */
-" .long 4f - .\n" /* repl offset */
-" .word %P[always]\n" /* always replace */
-" .byte 3b - 1b\n" /* src len */
-" .byte 5f - 4f\n" /* repl len */
-" .byte 3b - 2b\n" /* pad len */
-".previous\n"
-".section .altinstr_replacement,\"ax\"\n"
-"4: jmp %l[t_no]\n"
-"5:\n"
-".previous\n"
-".section .altinstructions,\"a\"\n"
-" .long 1b - .\n" /* src offset */
-" .long 0\n" /* no replacement */
-" .word %P[feature]\n" /* feature bit */
-" .byte 3b - 1b\n" /* src len */
-" .byte 0\n" /* repl len */
-" .byte 0\n" /* pad len */
-".previous\n"
-".section .altinstr_aux,\"ax\"\n"
-"6:\n"
-" testb %[bitnum],%[cap_byte]\n"
-" jnz %l[t_yes]\n"
-" jmp %l[t_no]\n"
-".previous\n"
+ asm_volatile_goto("STATIC_CPU_HAS bitnum=%[bitnum] "
+ "cap_byte=\"%[cap_byte]\" "
+ "feature=%P[feature] t_yes=%l[t_yes] "
+ "t_no=%l[t_no] always=%P[always]"
: : [feature] "i" (bit),
[always] "i" (X86_FEATURE_ALWAYS),
[bitnum] "i" (1 << (bit & 7)),
@@ -226,5 +199,44 @@ static __always_inline __pure bool _static_cpu_has(u16 bit)
#define CPU_FEATURE_TYPEVALboot_cpu_data.x86_vendor,
boot_cpu_data.x86, \
boot_cpu_data.x86_model
-#endif /* defined(__KERNEL__) && !defined(__ASSEMBLY__) */
+#else /* __ASSEMBLY__ */
+
+.macro STATIC_CPU_HAS bitnum:req cap_byte:req feature:req t_yes:req t_no:req
always:req
+1:
+ jmp 6f
+2:
+ .skip -(((5f-4f) - (2b-1b)) > 0) * ((5f-4f) - (2b-1b)),0x90
+3:
+ .section .altinstructions,"a"
+ .long 1b - ./* src offset */
+ .long 4f - ./* repl offset */
+ .word \always /* always replace */
+ .byte 3b - 1b /* src len */
+ .byte 5f - 4f /* repl len */
+ .byte 3b - 2b /* pad len */
+ .previous
+ .section .altinstr_replacement,"ax"
+4:
+ jmp \t_no
+5:
+ .previous
+ .section .altinstructions,"a"
+ .long 1b - ./* src offset */
+ .long 0 /* no replacement */
+ .word \feature /* feature bit */
+ .byte 3b - 1b /* src len */
+ .byte 0 /* repl len */
+ .byte 0 /* pad len */
+ .previous
+ .section .altinstr_aux,"ax"
+6:
+ testb \bitnum,\cap_byte
+ jnz \t_yes
+ jmp \t_no
+ .previous
+.endm
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __KERNEL__ */
#endif /* _ASM_X86_CPUFEATURE_H */
diff --git a/arch/x86/kernel/macros.S b/arch/x86/kernel/macros.S
index 7baa40d5bf16..bf8b9c93e255 100644
--- a/arch/x86/kernel/macros.S
+++
[GIT PULL] UBI/UBIFS updates for 4.18-rc1
Linus, The following changes since commit 29dcea88779c856c7dc92040a0c01233263101d4: Linux 4.17 (2018-06-03 14:15:21 -0700) are available in the git repository at: git://git.infradead.org/linux-ubifs.git tags/upstream-4.18-rc1 for you to fetch changes up to f5a926dd529870de4bd19199ce7b36985f130d70: mtd: ubi: Update ubi-media.h to dual license (2018-06-07 15:53:17 +0200) This pull request contains updates for both UBI and UBIFS: - The UBI on-disk format header file is now dual licensed - New way to detect Fastmap problems during runtime - Bugfix for Fastmap - Minor updates for UBIFS (spelling, comments, vm_fault_t, ...) Lionel Debieve (1): mtd: ubi: Update ubi-media.h to dual license Richard Weinberger (4): ubi: fastmap: Cancel work upon detach ubi: fastmap: Correctly handle interrupted erasures in EBA ubi: fastmap: Check each mapping only once ubi: fastmap: Detect EBA mismatches on-the-fly Sascha Hauer (6): ubifs: remove set but never used variable ubifs: journal: Remove wrong comment ubifs: Spelling fix someting -> something ubifs: log: Some spelling fixes ubifs: gc: Fix typo ubifs: lpt: Fix wrong pnode number range in comment Souptick Joarder (1): fs: ubifs: Adding new return type vm_fault_t Wang Shilong (1): ubifs, xattr: remove misguided quota flags drivers/mtd/ubi/build.c | 4 ++ drivers/mtd/ubi/eba.c | 111 +++- drivers/mtd/ubi/fastmap.c | 20 drivers/mtd/ubi/ubi-media.h | 22 ++--- drivers/mtd/ubi/ubi.h | 11 + drivers/mtd/ubi/vmt.c | 1 + drivers/mtd/ubi/vtbl.c | 16 ++- drivers/mtd/ubi/wl.c| 4 +- fs/ubifs/file.c | 11 ++--- fs/ubifs/gc.c | 2 +- fs/ubifs/journal.c | 5 +- fs/ubifs/log.c | 6 +-- fs/ubifs/lpt_commit.c | 2 +- fs/ubifs/replay.c | 5 +- fs/ubifs/ubifs.h| 2 - fs/ubifs/xattr.c| 2 +- 16 files changed, 178 insertions(+), 46 deletions(-)
Re: [PATCH 2/2] IB/mad: Use IDR for agent IDs
On Sun, Jun 10, 2018 at 03:25:05PM +0300, Leon Romanovsky wrote: > On Sun, Jun 10, 2018 at 03:43:05AM -0700, Matthew Wilcox wrote: > > On Sun, Jun 10, 2018 at 09:30:28AM +0300, Leon Romanovsky wrote: > > > 1. IBTA spec doesn't talk at all about the size of TransactionID, more > > > on that in section "13.4.6.4 TRANSACTION ID USAGE", the specification > > > says: "The contents of the TransactionID (TID) field are implementation- > > > dependent. So let's don't call it mlx4 bug. > > > > I was loosely paraphrasing the original bug report; suggested rewording > > of the comments gratefully accepted. > > Just replace "mlx4 bug" with something like "to comply with mlx4 > implementation". Well, it is a bug. Blindly replacing the upper 8 bits of the TID in a driver without accommodation from the core is totally, bonkers wrong. The original concept was that the 1<<24 limit would come from the driver and only mlx4 would have less than 1<<32, because only mlx4 does this thing.. Thanks Matt, Jason
Re: [PATCH 4.17 00/15] 4.17.1-stable review
On Sun, Jun 10, 2018 at 08:14:44AM -0700, Guenter Roeck wrote: > On Sat, Jun 09, 2018 at 05:29:35PM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.17.1 release. > > There are 15 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Mon Jun 11 14:59:48 UTC 2018. > > Anything received after that time might be too late. > > > Build results: > total: 134 pass: 134 fail: 0 > Qemu test results: > total: 143 pass: 143 fail: 0 > > Deteails are available at http://kerneltests.org/builders/. Wonderful, thanks for testing all of these and letting me know. greg k-h
Re: [PATCH 3.16 183/410] mm: pin address_space before dereferencing it while isolating an LRU page
On Thu, 7 Jun 2018, Ben Hutchings wrote:
> 3.16.57-rc1 review patch. If anyone has any objections, please let me know.
Not an objection as such, but if you're including this one,
please be sure to add 145e1a71e090575c74969e3daa8136d1e5b99fc8
"mm: fix the NULL mapping case in __isolate_lru_page()"
Thanks,
Hugh
>
> --
>
> From: Mel Gorman
>
> commit 69d763fc6d3aee787a3e8c8c35092b4f4960fa5d upstream.
>
> Minchan Kim asked the following question -- what locks protects
> address_space destroying when race happens between inode trauncation and
> __isolate_lru_page? Jan Kara clarified by describing the race as follows
>
> CPU1CPU2
>
> truncate(inode) __isolate_lru_page()
> ...
> truncate_inode_page(mapping, page);
> delete_from_page_cache(page)
> spin_lock_irqsave(&mapping->tree_lock, flags);
> __delete_from_page_cache(page, NULL)
> page_cache_tree_delete(..)
> ... mapping =
> page_mapping(page);
> page->mapping = NULL;
> ...
> spin_unlock_irqrestore(&mapping->tree_lock, flags);
> page_cache_free_page(mapping, page)
> put_page(page)
> if (put_page_testzero(page)) -> false
> - inode now has no pages and can be freed including embedded address_space
>
> if (mapping &&
> !mapping->a_ops->migratepage)
> - we've dereferenced mapping which is potentially already free.
>
> The race is theoretically possible but unlikely. Before the
> delete_from_page_cache, truncate_cleanup_page is called so the page is
> likely to be !PageDirty or PageWriteback which gets skipped by the only
> caller that checks the mappping in __isolate_lru_page. Even if the race
> occurs, a substantial amount of work has to happen during a tiny window
> with no preemption but it could potentially be done using a virtual
> machine to artifically slow one CPU or halt it during the critical
> window.
>
> This patch should eliminate the race with truncation by try-locking the
> page before derefencing mapping and aborting if the lock was not
> acquired. There was a suggestion from Huang Ying to use RCU as a
> side-effect to prevent mapping being freed. However, I do not like the
> solution as it's an unconventional means of preserving a mapping and
> it's not a context where rcu_read_lock is obviously protecting rcu data.
>
> Link:
> http://lkml.kernel.org/r/20180104102512.2qos3h5vqzeis...@techsingularity.net
> Fixes: c82449352854 ("mm: compaction: make isolate_lru_page() filter-aware
> again")
> Signed-off-by: Mel Gorman
> Acked-by: Minchan Kim
> Cc: "Huang, Ying"
> Cc: Jan Kara
> Signed-off-by: Andrew Morton
> Signed-off-by: Linus Torvalds
> [bwh: Backported to 3.16: adjust context]
> Signed-off-by: Ben Hutchings
> ---
> mm/vmscan.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1206,6 +1206,7 @@ int __isolate_lru_page(struct page *page
>
> if (PageDirty(page)) {
> struct address_space *mapping;
> + bool migrate_dirty;
>
> /* ISOLATE_CLEAN means only clean pages */
> if (mode & ISOLATE_CLEAN)
> @@ -1214,10 +1215,19 @@ int __isolate_lru_page(struct page *page
> /*
>* Only pages without mappings or that have a
>* ->migratepage callback are possible to migrate
> - * without blocking
> + * without blocking. However, we can be racing with
> + * truncation so it's necessary to lock the page
> + * to stabilise the mapping as truncation holds
> + * the page lock until after the page is removed
> + * from the page cache.
>*/
> + if (!trylock_page(page))
> + return ret;
> +
> mapping = page_mapping(page);
> - if (mapping && !mapping->a_ops->migratepage)
> + migrate_dirty = mapping && mapping->a_ops->migratepage;
> + unlock_page(page);
> + if (!migrate_dirty)
> return ret;
> }
> }
>
>
Re: Perf record of mem event on kernel data address causing freeze
Sorry for the extreme delay for this reply.
If the expectation was to resolve the issue, the new patch failed to do so.
If this information helps, the system hung when WP tried to monitor an
address(0x88021f51a768) which was originally sampled by PEBS
inside rcu_nmi_exit.
On Fri, May 25, 2018 at 10:49 AM, Frederic Weisbecker
wrote:
> On Thu, May 17, 2018 at 04:38:52PM +0200, Jiri Olsa wrote:
>> On Fri, May 11, 2018 at 02:23:14PM -0400, Probir Roy wrote:
>> > I am using perf-tool to record memory access to some kernel addresses.
>> > For some kernel addresses it freezes/lockup the system.
>> >
>> > I am using kernel version 4.15.0 on x86_64 arch. I am running on an
>> > Intel Broadwell machine.
>> >
>> > I am using Intel's PEBS to sample kernel memory access while running a
>> > micro-benchmark (performs repeated file operation) using following
>> > command.
>> >
>> > $ sudo perf mem -t store record
>> >
>> > This records memory references. After that I run a script to set HW
>> > breakpoint at the reference addresses.
>> >
>> > $ sudo timeout 1s perf record -e mem:<0xaddress>:rw
>> >
>> > It causes system hang at some address (for many address perf reports
>> > correctly). Nothing is written in kern.log
>> >
>> >
>> > I have reported it on bugzilla with detail system information:
>> > https://bugzilla.kernel.org/show_bug.cgi?id=199697
>>
>> I managed to reproduce.. in my case it's caused by having rw
>> breakpoint on data which is touched within do_debug routine,
>> and after few nested do_debug I get double fault
>>
>> for example I can reproduce it immediately when setting breakpoint
>> on rdtp->dynticks_nmi_nesting, which is checked in rcu_nmi_enter
>>
>> I have some ugly patch so far that disables breakpoints during
>> do_debug processing.. it seems to fix it on my server, could you
>> try that?
>>
>> thanks,
>> jirka
>>
>>
>> ---
>> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
>> index 03f3d7695dac..14d41d59abeb 100644
>> --- a/arch/x86/kernel/traps.c
>> +++ b/arch/x86/kernel/traps.c
>> @@ -721,9 +721,12 @@ dotraplinkage void do_debug(struct pt_regs *regs, long
>> error_code)
>> {
>> struct task_struct *tsk = current;
>> int user_icebp = 0;
>> - unsigned long dr6;
>> + unsigned long dr6, dr7;
>> int si_code;
>>
>> + get_debugreg(dr7, 7);
>> + set_debugreg(0, 7);
>> +
>> ist_enter(regs);
>>
>> get_debugreg(dr6, 6);
>> @@ -818,6 +821,7 @@ dotraplinkage void do_debug(struct pt_regs *regs, long
>> error_code)
>>
>> exit:
>> ist_exit(regs);
>> + set_debugreg(dr7, 7);
>> }
>> NOKPROBE_SYMBOL(do_debug);
>
> I'm not sure how much we touch dr7 while in the do_debug() trap, so we may be
> leaking
> some modifications on exit.
>
> I think about a simple do_debug() recursion protection. The problem is where
> we store
> that recursion flag/counter. Ideally I would prefer to have the recursion
> protection
> before ist_enter() which already touches many key memory data (preempt_mask,
> rcu_data).
> But if we set that before ist_enter(), we need the recursion flag to be per
> task because
> preemption is disabled on ist_enter() only, although the comments suggest
> it's unsafe
> to schedule before anyway. So it could be a TIF_FLAG. But better yet, if we
> want to be
> able to set breakpoint on thread flags, we could add a new field in thread
> info.
>
> Anyway here is a very dumb version below. Can you test it Probir, to see if
> that's
> at least the right direction?
>
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index 03f3d76..873383b 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -693,6 +693,8 @@ static bool is_sysenter_singlestep(struct pt_regs *regs)
> #endif
> }
>
> +static DEFINE_PER_CPU(int, do_debug_recursion);
> +
> /*
> * Our handling of the processor debug registers is non-trivial.
> * We do not clear them on entry and exit from the kernel. Therefore
> @@ -725,6 +727,10 @@ dotraplinkage void do_debug(struct pt_regs *regs, long
> error_code)
> int si_code;
>
> ist_enter(regs);
> + if (__this_cpu_read(do_debug_recursion))
> + goto exit;
> +
> + __this_cpu_write(do_debug_recursion, 1);
>
> get_debugreg(dr6, 6);
> /*
> @@ -817,6 +823,7 @@ dotraplinkage void do_debug(struct pt_regs *regs, long
> error_code)
> debug_stack_usage_dec();
>
> exit:
> + __this_cpu_write(do_debug_recursion, 0);
> ist_exit(regs);
> }
> NOKPROBE_SYMBOL(do_debug);
--
Probir Roy
PhD Student
College of William and Mary
Phone: 7577531428
[PATCH V2] EDAC, altera: Fix an error handling path in 'altr_s10_sdram_probe()'
IF 'regmap_write()' fails, we should release some resources as done in all
the other error handling paths of the function.
Fixes: e9918d7fafae ("EDAC, altera: Handle SDRAM Uncorrectable Errors on
Stratix10")
Signed-off-by: Christophe JAILLET
---
v1 -> v2: Fix subject line
---
drivers/edac/altera_edac.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index d0d5c4dbe097..5762c3c383f2 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -730,7 +730,8 @@ static int altr_s10_sdram_probe(struct platform_device
*pdev)
S10_DDR0_IRQ_MASK)) {
edac_printk(KERN_ERR, EDAC_MC,
"Error clearing SDRAM ECC count\n");
- return -ENODEV;
+ ret = -ENODEV;
+ goto err2;
}
if (regmap_update_bits(drvdata->mc_vbase, priv->ecc_irq_en_offset,
--
2.17.0
Re: [PATCH v3] mm: fix race between kmem_cache destroy, create and deactivate
On Sun, Jun 10, 2018 at 9:32 AM Paul E. McKenney wrote: > > On Sun, Jun 10, 2018 at 07:52:50AM -0700, Shakeel Butt wrote: > > On Sat, Jun 9, 2018 at 3:20 AM Vladimir Davydov > > wrote: > > > > > > On Tue, May 29, 2018 at 05:12:04PM -0700, Shakeel Butt wrote: > > > > The memcg kmem cache creation and deactivation (SLUB only) is > > > > asynchronous. If a root kmem cache is destroyed whose memcg cache is in > > > > the process of creation or deactivation, the kernel may crash. > > > > > > > > Example of one such crash: > > > > general protection fault: [#1] SMP PTI > > > > CPU: 1 PID: 1721 Comm: kworker/14:1 Not tainted 4.17.0-smp > > > > ... > > > > Workqueue: memcg_kmem_cache kmemcg_deactivate_workfn > > > > RIP: 0010:has_cpu_slab > > > > ... > > > > Call Trace: > > > > ? on_each_cpu_cond > > > > __kmem_cache_shrink > > > > kmemcg_cache_deact_after_rcu > > > > kmemcg_deactivate_workfn > > > > process_one_work > > > > worker_thread > > > > kthread > > > > ret_from_fork+0x35/0x40 > > > > > > > > To fix this race, on root kmem cache destruction, mark the cache as > > > > dying and flush the workqueue used for memcg kmem cache creation and > > > > deactivation. > > > > > > > @@ -845,6 +862,8 @@ void kmem_cache_destroy(struct kmem_cache *s) > > > > if (unlikely(!s)) > > > > return; > > > > > > > > + flush_memcg_workqueue(s); > > > > + > > > > > > This should definitely help against async memcg_kmem_cache_create(), > > > but I'm afraid it doesn't eliminate the race with async destruction, > > > unfortunately, because the latter uses call_rcu_sched(): > > > > > > memcg_deactivate_kmem_caches > > >__kmem_cache_deactivate > > > slab_deactivate_memcg_cache_rcu_sched > > > call_rcu_sched > > > kmem_cache_destroy > > > shutdown_memcg_caches > > > shutdown_cache > > > memcg_deactivate_rcufn > > > > > > > > > Can we somehow flush those pending rcu requests? > > > > You are right and thanks for catching that. Now I am wondering if > > synchronize_sched() just before flush_workqueue() should be enough. > > Otherwise we might have to replace call_sched_rcu with > > synchronize_sched() in kmemcg_deactivate_workfn which I would not > > prefer as that would holdup the kmem_cache workqueue. > > > > +Paul > > > > Paul, we have a situation something similar to the following pseudo code. > > > > CPU0: > > lock(l) > > if (!flag) > > call_rcu_sched(callback); > > unlock(l) > > -- > > CPU1: > > lock(l) > > flag = true > > unlock(l) > > synchronize_sched() > > -- > > > > If CPU0 has called already called call_rchu_sched(callback) then later > > if CPU1 calls synchronize_sched(). Is there any guarantee that on > > return from synchronize_sched(), the rcu callback scheduled by CPU0 > > has already been executed? > > No. There is no such guarantee. > > You instead want rcu_barrier_sched(), which waits for the callbacks from > all prior invocations of call_rcu_sched() to be invoked. > > Please note that synchronize_sched() is -not- sufficient. It is only > guaranteed to wait for a grace period, not necessarily for all prior > callbacks. This goes both directions because if there are no callbacks > in the system, then rcu_barrier_sched() is within its rights to return > immediately. > > So please make sure you use each of synchronize_sched() and > rcu_barrier_sched() to do the job that it was intended to do! ;-) > > If your lock(l) is shorthand for spin_lock(&l), it looks to me like you > actually only need rcu_barrier_sched(): > > CPU0: > spin_lock(&l); > if (!flag) > call_rcu_sched(callback); > spin_unlock(&l); > > CPU1: > spin_lock(&l); > flag = true; > spin_unlock(&l); > /* At this point, no more callbacks will be registered. */ > rcu_barrier_sched(); > /* At this point, all registered callbacks will have been invoked. */ > > On the other hand, if your "lock(l)" was instead shorthand for > rcu_read_lock_sched(), then you need -both- synchronize_sched() -and- > rcu_barrier(). And even then, you will be broken in -rt kernels. > (Which might or might not be a concern, depending on whether your code > matters to -rt kernels. > > Make sense? > Thanks a lot, that was really helpful. The lock is actually mutex_lock. So, I think rcu_barrier_sched() should be sufficient. Shakeel
