[PATCH 0/9] Fix a bunch more W=1 warnings in Regulator
Attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. This is the last of them. Once applied, drivers/regulator will be clean of W=1 warnings. Lee Jones (9): regulator: max8998: Staticify internal function max8998_get_current_limit() regulator: qcom-rpmh-regulator: Repair dodgy kerneldoc header formatting regulator: pwm-regulator: Demote kerneldoc header to standard comment regulator: stpmic1_regulator: Properly document 'struct stpmic1_regulator_cfg' regulator: tps65217-regulator: Remove pointless 'is unsigned int <0' check regulator: tps65217-regulator: Use the returned value of tps65217_reg_read() regulator: tps65218-regulator: Remove pointless 'is unsigned int <0' check regulator: wm8400-regulator: Repair dodgy kerneldoc header formatting regulator: qcom_smd-regulator: Remove unused 'struct regulator_desc pmi8994_boost' drivers/regulator/max8998.c | 2 +- drivers/regulator/pwm-regulator.c | 2 +- drivers/regulator/qcom-rpmh-regulator.c | 14 +++--- drivers/regulator/qcom_smd-regulator.c | 9 - drivers/regulator/stpmic1_regulator.c | 2 +- drivers/regulator/tps65217-regulator.c | 7 +-- drivers/regulator/tps65218-regulator.c | 4 ++-- drivers/regulator/wm8400-regulator.c| 6 +++--- 8 files changed, 20 insertions(+), 26 deletions(-) -- 2.25.1
[PATCH 9/9] regulator: qcom_smd-regulator: Remove unused 'struct regulator_desc pmi8994_boost'
This was an upstreaming error. Remove it as it's not to be used.
Fixes the following W=1 kernel build warning:
drivers/regulator/qcom_smd-regulator.c:477:36: warning: ‘pmi8994_boost’
defined but not used [-Wunused-const-variable=]
Cc: Andy Gross
Cc: Bjorn Andersson
Cc: linux-arm-...@vger.kernel.org
Signed-off-by: Lee Jones
---
drivers/regulator/qcom_smd-regulator.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/regulator/qcom_smd-regulator.c
b/drivers/regulator/qcom_smd-regulator.c
index 53a64d856926f..4c0a469d8a115 100644
--- a/drivers/regulator/qcom_smd-regulator.c
+++ b/drivers/regulator/qcom_smd-regulator.c
@@ -474,15 +474,6 @@ static const struct regulator_desc pmi8994_bby = {
.ops = &rpm_bob_ops,
};
-static const struct regulator_desc pmi8994_boost = {
- .linear_ranges = (struct linear_range[]) {
- REGULATOR_LINEAR_RANGE(400, 0, 30, 5),
- },
- .n_linear_ranges = 1,
- .n_voltages = 31,
- .ops = &rpm_smps_ldo_ops,
-};
-
static const struct regulator_desc pm8998_ftsmps = {
.linear_ranges = (struct linear_range[]) {
REGULATOR_LINEAR_RANGE(32, 0, 258, 4000),
--
2.25.1
Re: [PATCH v2 0/4] Tegra Video Decoder driver power management corrections
On 26/06/2020 02:17, Dmitry Osipenko wrote: > 24.06.2020 18:23, Dmitry Osipenko пишет: >> 24.06.2020 18:16, Hans Verkuil пишет: >>> On 24/06/2020 17:08, Dmitry Osipenko wrote: Hello, This small series addresses a Runtime PM issue that was discovered during of Tegra VI driver reviewing by balancing RPM usage count on RPM resume failure. Secondly it fixes reboot on some Tegra devices due to bootloader expecting VDE power partition to be ON at the boot time, which wasn't happening in case of a warm re-booting (i.e. by PMC resetting). >>> >>> Can you rebase this on top of the media_tree master branch? I think a >>> variant >>> of patch 1 has already been applied. I found a mail today where you >>> mentioned >>> that you preferred your version (it looks like I missed that) so you'll >>> need to >>> rework patch 1. >> >> Hello Hans, >> >> I'll take a look at what patches has been applied, my bad for sending >> the v2 too late. Thank you for the heads up! >> > > I tested the already-applied variant of the patch 1 and it has the same > behaviour as my variant, so it's okay. > > Would you want me to send a v3 without the conflicting patch 1 or you > could apply the patches 2-4 from this series? > I'll mark 1/4 as superseded and will apply patches 2-4. No need for you to do anything. Regards, Hans
[PATCH 4/9] regulator: stpmic1_regulator: Properly document 'struct stpmic1_regulator_cfg'
In kerneldoc format, data structures have to start with 'struct' else the kerneldoc tooling/parsers/validators get confused. Fixes the following W=1 kernel build warning: drivers/regulator/stpmic1_regulator.c:25: warning: cannot understand function prototype: 'struct stpmic1_regulator_cfg ' Cc: Pascal Paillet Signed-off-by: Lee Jones --- drivers/regulator/stpmic1_regulator.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/regulator/stpmic1_regulator.c b/drivers/regulator/stpmic1_regulator.c index adc9973d1b2f7..73e0ab2baeaa6 100644 --- a/drivers/regulator/stpmic1_regulator.c +++ b/drivers/regulator/stpmic1_regulator.c @@ -15,7 +15,7 @@ #include /** - * stpmic1 regulator description: this structure is used as driver data + * struct stpmic1 regulator description: this structure is used as driver data * @desc: regulator framework description * @mask_reset_reg: mask reset register address * @mask_reset_mask: mask rank and mask reset register mask -- 2.25.1
[PATCH 1/9] regulator: max8998: Staticify internal function max8998_get_current_limit()
max8998_get_current_limit() is only used via the .get_current_limit,
so it doesn't need to be publicly supported, or to have its own
external prototype. Instead, we'll make it static.
Fixes the following W=1 warning:
drivers/regulator/max8998.c:418:5: warning: no previous prototype for
‘max8998_get_current_limit’ [-Wmissing-prototypes]
418 | int max8998_get_current_limit(struct regulator_dev *rdev)
| ^
Cc: Kyungmin Park
Cc: Marek Szyprowski
Signed-off-by: Lee Jones
---
drivers/regulator/max8998.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/max8998.c b/drivers/regulator/max8998.c
index 340413bba0c5f..ac69bdd398cb3 100644
--- a/drivers/regulator/max8998.c
+++ b/drivers/regulator/max8998.c
@@ -415,7 +415,7 @@ static int max8998_set_current_limit(struct regulator_dev
*rdev,
sel, rdev->desc->csel_mask);
}
-int max8998_get_current_limit(struct regulator_dev *rdev)
+static int max8998_get_current_limit(struct regulator_dev *rdev)
{
struct max8998_data *max8998 = rdev_get_drvdata(rdev);
struct i2c_client *i2c = max8998->iodev->i2c;
--
2.25.1
[PATCH 6/9] regulator: tps65217-regulator: Use the returned value of tps65217_reg_read()
Until now the aforementioned return value has been ignored. Previous and current calls to tps65217_reg_read() return instantly when the value is not 0, so let's do that. Fixes the following W=1 warning: drivers/regulator/tps65217-regulator.c: In function ‘tps65217_regulator_probe’: drivers/regulator/tps65217-regulator.c:227:9: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable] 227 | int i, ret; | ^~~ Cc: Russ Dill Cc: Keerthy Cc: AnilKumar Ch Cc: linux-o...@vger.kernel.org Signed-off-by: Lee Jones --- drivers/regulator/tps65217-regulator.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/regulator/tps65217-regulator.c b/drivers/regulator/tps65217-regulator.c index f2d3a4a9f3e77..3f5ea029e2e3f 100644 --- a/drivers/regulator/tps65217-regulator.c +++ b/drivers/regulator/tps65217-regulator.c @@ -254,6 +254,9 @@ static int tps65217_regulator_probe(struct platform_device *pdev) /* Store default strobe info */ ret = tps65217_reg_read(tps, regulators[i].bypass_reg, &val); + if (ret) + return ret; + tps->strobes[i] = val & regulators[i].bypass_mask; } -- 2.25.1
[PATCH 3/9] regulator: pwm-regulator: Demote kerneldoc header to standard comment
This particular comment doesn't have anything to do with documenting
functions or data structures. Instead it is used as a section header.
Fixes W=1 warning:
drivers/regulator/pwm-regulator.c:55: warning: Function parameter or member
'rdev' not described in 'pwm_regulator_init_state'
Signed-off-by: Lee Jones
---
drivers/regulator/pwm-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/pwm-regulator.c
b/drivers/regulator/pwm-regulator.c
index 638329bd0745e..3234b118b53ea 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -48,7 +48,7 @@ struct pwm_voltages {
unsigned int dutycycle;
};
-/**
+/*
* Voltage table call-backs
*/
static void pwm_regulator_init_state(struct regulator_dev *rdev)
--
2.25.1
[PATCH 2/9] regulator: qcom-rpmh-regulator: Repair dodgy kerneldoc header formatting
W=1 kernel builds report a lack of descriptions for various
enum properties and function arguments. In reality they are
documented, but the formatting was not as expected '@.*:'.
Instead, some weird arg identifiers were used or none at all.
This change fixes the following warnings:
drivers/regulator/qcom-rpmh-regulator.c:33: warning: Enum value 'VRM' not
described in enum 'rpmh_regulator_type'
drivers/regulator/qcom-rpmh-regulator.c:33: warning: Enum value 'XOB' not
described in enum 'rpmh_regulator_type'
drivers/regulator/qcom-rpmh-regulator.c:416: warning: Function parameter or
member 'vreg' not described in 'rpmh_regulator_init_vreg'
drivers/regulator/qcom-rpmh-regulator.c:416: warning: Function parameter or
member 'dev' not described in 'rpmh_regulator_init_vreg'
drivers/regulator/qcom-rpmh-regulator.c:416: warning: Function parameter or
member 'node' not described in 'rpmh_regulator_init_vreg'
drivers/regulator/qcom-rpmh-regulator.c:416: warning: Function parameter or
member 'pmic_id' not described in 'rpmh_regulator_init_vreg'
drivers/regulator/qcom-rpmh-regulator.c:416: warning: Function parameter or
member 'pmic_rpmh_data' not described in 'rpmh_regulator_init_vreg'
Cc: Andy Gross
Cc: Bjorn Andersson
Cc: linux-arm-...@vger.kernel.org
Signed-off-by: Lee Jones
---
drivers/regulator/qcom-rpmh-regulator.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/regulator/qcom-rpmh-regulator.c
b/drivers/regulator/qcom-rpmh-regulator.c
index 79bdc129cb504..08dcc614efa7f 100644
--- a/drivers/regulator/qcom-rpmh-regulator.c
+++ b/drivers/regulator/qcom-rpmh-regulator.c
@@ -22,9 +22,9 @@
/**
* enum rpmh_regulator_type - supported RPMh accelerator types
- * %VRM: RPMh VRM accelerator which supports voting on enable, voltage,
+ * @VRM: RPMh VRM accelerator which supports voting on enable, voltage,
* and mode of LDO, SMPS, and BOB type PMIC regulators.
- * %XOB: RPMh XOB accelerator which supports voting on the enable state
+ * @XOB: RPMh XOB accelerator which supports voting on the enable state
* of PMIC regulators.
*/
enum rpmh_regulator_type {
@@ -399,13 +399,13 @@ static const struct regulator_ops rpmh_regulator_xob_ops
= {
/**
* rpmh_regulator_init_vreg() - initialize all attributes of an rpmh-regulator
- * vreg: Pointer to the individual rpmh-regulator resource
- * dev:Pointer to the top level rpmh-regulator PMIC
device
- * node: Pointer to the individual rpmh-regulator resource
+ * @vreg: Pointer to the individual rpmh-regulator resource
+ * @dev: Pointer to the top level rpmh-regulator PMIC
device
+ * @node: Pointer to the individual rpmh-regulator resource
* device node
- * pmic_id:String used to identify the top level rpmh-regulator
+ * @pmic_id: String used to identify the top level rpmh-regulator
* PMIC device on the board
- * pmic_rpmh_data: Pointer to a null-terminated array of rpmh-regulator
+ * @pmic_rpmh_data:Pointer to a null-terminated array of rpmh-regulator
* resources defined for the top level PMIC device
*
* Return: 0 on success, errno on failure
--
2.25.1
[PATCH 7/9] regulator: tps65218-regulator: Remove pointless 'is unsigned int <0' check
'rid' is declared as unsigned int, so there is little point checking for <0. Removing these checks fixes the following W=1 warnings: drivers/regulator/tps65218-regulator.c: In function ‘tps65218_pmic_set_suspend_enable’: drivers/regulator/tps65218-regulator.c:131:10: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] 131 | if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1) | ^ drivers/regulator/tps65218-regulator.c: In function ‘tps65218_pmic_set_suspend_disable’: drivers/regulator/tps65218-regulator.c:144:10: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] 144 | if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1) | ^ Cc: Keerthy Cc: Tero Kristo Cc: Dave Gerlach Cc: linux-o...@vger.kernel.org Signed-off-by: Lee Jones --- drivers/regulator/tps65218-regulator.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/regulator/tps65218-regulator.c b/drivers/regulator/tps65218-regulator.c index 05d13f8079182..9133d0af793a7 100644 --- a/drivers/regulator/tps65218-regulator.c +++ b/drivers/regulator/tps65218-regulator.c @@ -128,7 +128,7 @@ static int tps65218_pmic_set_suspend_enable(struct regulator_dev *dev) struct tps65218 *tps = rdev_get_drvdata(dev); unsigned int rid = rdev_get_id(dev); - if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1) + if (rid > TPS65218_LDO_1) return -EINVAL; return tps65218_clear_bits(tps, dev->desc->bypass_reg, @@ -141,7 +141,7 @@ static int tps65218_pmic_set_suspend_disable(struct regulator_dev *dev) struct tps65218 *tps = rdev_get_drvdata(dev); unsigned int rid = rdev_get_id(dev); - if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1) + if (rid > TPS65218_LDO_1) return -EINVAL; /* -- 2.25.1
[PATCH 5/9] regulator: tps65217-regulator: Remove pointless 'is unsigned int <0' check
'rid' is declared as unsigned int, so there is little point checking for <0. Removing these checks fixes the following W=1 warnings: drivers/regulator/tps65217-regulator.c: In function ‘tps65217_pmic_set_suspend_enable’: drivers/regulator/tps65217-regulator.c:127:10: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] 127 | if (rid < TPS65217_DCDC_1 || rid > TPS65217_LDO_4) | ^ drivers/regulator/tps65217-regulator.c: In function ‘tps65217_pmic_set_suspend_disable’: drivers/regulator/tps65217-regulator.c:140:10: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] 140 | if (rid < TPS65217_DCDC_1 || rid > TPS65217_LDO_4) | ^ Cc: Russ Dill Cc: Keerthy Cc: AnilKumar Ch Cc: linux-o...@vger.kernel.org Signed-off-by: Lee Jones --- drivers/regulator/tps65217-regulator.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/regulator/tps65217-regulator.c b/drivers/regulator/tps65217-regulator.c index d27dbbafcf721..f2d3a4a9f3e77 100644 --- a/drivers/regulator/tps65217-regulator.c +++ b/drivers/regulator/tps65217-regulator.c @@ -124,7 +124,7 @@ static int tps65217_pmic_set_suspend_enable(struct regulator_dev *dev) struct tps65217 *tps = rdev_get_drvdata(dev); unsigned int rid = rdev_get_id(dev); - if (rid < TPS65217_DCDC_1 || rid > TPS65217_LDO_4) + if (rid > TPS65217_LDO_4) return -EINVAL; return tps65217_clear_bits(tps, dev->desc->bypass_reg, @@ -137,7 +137,7 @@ static int tps65217_pmic_set_suspend_disable(struct regulator_dev *dev) struct tps65217 *tps = rdev_get_drvdata(dev); unsigned int rid = rdev_get_id(dev); - if (rid < TPS65217_DCDC_1 || rid > TPS65217_LDO_4) + if (rid > TPS65217_LDO_4) return -EINVAL; if (!tps->strobes[rid]) -- 2.25.1
[PATCH 8/9] regulator: wm8400-regulator: Repair dodgy kerneldoc header formatting
W=1 kernel builds report a lack of descriptions for various
function arguments. In reality they are documented, but the
formatting was not as expected '@.*:'. Instead, some weird
arg identifiers were used.
This change fixes the following warnings:
drivers/regulator/wm8400-regulator.c:243: warning: Function parameter or
member 'dev' not described in 'wm8400_register_regulator'
drivers/regulator/wm8400-regulator.c:243: warning: Function parameter or
member 'reg' not described in 'wm8400_register_regulator'
drivers/regulator/wm8400-regulator.c:243: warning: Function parameter or
member 'initdata' not described in 'wm8400_register_regulator'
Cc: patc...@opensource.cirrus.com
Signed-off-by: Lee Jones
---
drivers/regulator/wm8400-regulator.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/wm8400-regulator.c
b/drivers/regulator/wm8400-regulator.c
index 4cb1fbb597227..e9fd137077213 100644
--- a/drivers/regulator/wm8400-regulator.c
+++ b/drivers/regulator/wm8400-regulator.c
@@ -234,9 +234,9 @@ static struct platform_driver wm8400_regulator_driver = {
* the regulator API. It is intended to be called from the
* platform_init() callback of the WM8400 MFD driver.
*
- * @param dev The WM8400 device to operate on.
- * @param reg The regulator to control.
- * @param initdata Regulator initdata for the regulator.
+ * @dev: The WM8400 device to operate on.
+ * @reg: The regulator to control.
+ * @initdata: Regulator initdata for the regulator.
*/
int wm8400_register_regulator(struct device *dev, int reg,
struct regulator_init_data *initdata)
--
2.25.1
Re: media/master bisection: v4l2-compliance-uvc.Buffer-ioctls-Input-0.VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF on rk3399-gru-kevin
Please see the bisection report below about a regression in v4l2-compliance with uvcvideo: [ 25.495039] uvcvideo: Failed to query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2). fail: v4l2-test-buffers.cpp(680): check_0(reqbufs.reserved, sizeof(reqbufs.reserved)) test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL as seen in the full job log: https://storage.kernelci.org/media/master/v5.8-rc1-64-ge30cc79cc80f/arm64/defconfig/gcc-8/lab-collabora/v4l2-compliance-uvc-rk3399-gru-kevin.html#L1713 with a few more details about the regression here: https://kernelci.org/test/case/id/5ef23169140826f73d97bf51/ and the same test case failure also seen with vivid: https://kernelci.org/test/case/id/5ef23699f641f7b3e597bf3f/ The bisection actually ran a couple of days ago but there was an email error when sending the report, so I'm sending it by hand now. I hope the issue hasn't spread too widely already, I know it's also affecting linux-next. Guillaume On 25/06/2020 23:19, kernelci.org bot wrote: > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > * This automated bisection report was sent to you on the basis * > * that you may be involved with the breaking commit it has * > * found. No manual investigation has been done to verify it, * > * and the root cause of the problem may be somewhere else. * > * * > * If you do send a fix, please include this trailer:* > * Reported-by: "kernelci.org bot" * > * * > * Hope this helps! * > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > > media/master bisection: > v4l2-compliance-uvc.Buffer-ioctls-Input-0.VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF > on rk3399-gru-kevin > > Summary: > Start: e30cc79cc80f media: media-request: Fix crash if memory > allocation fails > Plain log: > https://storage.kernelci.org/media/master/v5.8-rc1-64-ge30cc79cc80f/arm64/defconfig/gcc-8/lab-collabora/v4l2-compliance-uvc-rk3399-gru-kevin.txt > HTML log: > https://storage.kernelci.org/media/master/v5.8-rc1-64-ge30cc79cc80f/arm64/defconfig/gcc-8/lab-collabora/v4l2-compliance-uvc-rk3399-gru-kevin.html > Result: 1e0b2318fa75 media: videobuf2: handle > V4L2_FLAG_MEMORY_NON_CONSISTENT flag > > Checks: > revert: PASS > verify: PASS > > Parameters: > Tree: media > URL:https://git.linuxtv.org/media_tree.git > Branch: master > Target: rk3399-gru-kevin > CPU arch: arm64 > Lab:lab-collabora > Compiler: gcc-8 > Config: defconfig > Test case: > v4l2-compliance-uvc.Buffer-ioctls-Input-0.VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF > > Breaking commit found: > > --- > commit 1e0b2318fa75d186ee0d2be31843ce867385fcc4 > Author: Sergey Senozhatsky > Date: Thu May 14 18:01:45 2020 +0200 > > media: videobuf2: handle V4L2_FLAG_MEMORY_NON_CONSISTENT flag > > This patch lets user-space to request a non-consistent memory > allocation during CREATE_BUFS and REQBUFS ioctl calls. > > = CREATE_BUFS > > struct v4l2_create_buffers has seven 4-byte reserved areas, > so reserved[0] is renamed to ->flags. The struct, thus, now > has six reserved 4-byte regions. > > = CREATE_BUFS32 > > struct v4l2_create_buffers32 has seven 4-byte reserved areas, > so reserved[0] is renamed to ->flags. The struct, thus, now > has six reserved 4-byte regions. > > = REQBUFS > > We use one bit of a ->reserved[1] member of struct v4l2_requestbuffers, > which is now renamed to ->flags. Unlike v4l2_create_buffers, struct > v4l2_requestbuffers does not have enough reserved room. Therefore for > backward compatibility ->reserved and ->flags were put into anonymous > union. > > Signed-off-by: Sergey Senozhatsky > Signed-off-by: Hans Verkuil > Signed-off-by: Mauro Carvalho Chehab > > diff --git a/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst > b/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst > index e1afc5b504c2..f2a702870fad 100644 > --- a/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst > +++ b/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst > @@ -121,7 +121,12 @@ than the number requested. > other changes, then set ``count`` to 0, ``memory`` to > ``V4L2_MEMORY_MMAP`` and ``format.type`` to the buffer type. > * - __u32 > - - ``reserved``\ [7] > + - ``flags`` > + - Specifies additional buffer management attributes. > + See :ref:`memory-flags`. > + > +* - __u32 > + - ``reserved``\ [6] >- A place holder for future extensions. Drivers and applications > must set
Re: [PATCH v2 0/2] zone-append support in io-uring and aio
On 2020/06/26 15:37, javier.g...@samsung.com wrote:
> On 26.06.2020 03:11, Damien Le Moal wrote:
>> On 2020/06/26 2:18, Kanchan Joshi wrote:
>>> [Revised as per feedback from Damien, Pavel, Jens, Christoph, Matias,
>>> Wilcox]
>>>
>>> This patchset enables zone-append using io-uring/linux-aio, on block IO
>>> path.
>>> Purpose is to provide zone-append consumption ability to applications which
>>> are
>>> using zoned-block-device directly.
>>>
>>> The application may specify RWF_ZONE_APPEND flag with write when it wants to
>>> send zone-append. RWF_* flags work with a certain subset of APIs e.g. uring,
>>> aio, and pwritev2. An error is reported if zone-append is requested using
>>> pwritev2. It is not in the scope of this patchset to support pwritev2 or any
>>> other sync write API for reasons described later.
>>>
>>> Zone-append completion result --->
>>> With zone-append, where write took place can only be known after completion.
>>> So apart from usual return value of write, additional mean is needed to
>>> obtain
>>> the actual written location.
>>>
>>> In aio, this is returned to application using res2 field of io_event -
>>>
>>> struct io_event {
>>> __u64 data; /* the data field from the iocb */
>>> __u64 obj;/* what iocb this event came from */
>>> __s64 res;/* result code for this event */
>>> __s64 res2; /* secondary result */
>>> };
>>>
>>> In io-uring, cqe->flags is repurposed for zone-append result.
>>>
>>> struct io_uring_cqe {
>>> __u64 user_data; /* sqe->data submission passed back */
>>> __s32 res;/* result code for this event */
>>> __u32 flags;
>>> };
>>>
>>> Since 32 bit flags is not sufficient, we choose to return zone-relative
>>> offset
>>> in sector/512b units. This can cover zone-size represented by chunk_sectors.
>>> Applications will have the trouble to combine this with zone start to know
>>> disk-relative offset. But if more bits are obtained by pulling from res
>>> field
>>> that too would compel application to interpret res field differently, and it
>>> seems more painstaking than the former option.
>>> To keep uniformity, even with aio, zone-relative offset is returned.
>>
>> I am really not a fan of this, to say the least. The input is byte offset,
>> the
>> output is 512B relative sector count... Arg... We really cannot do better
>> than
>> that ?
>>
>> At the very least, byte relative offset ? The main reason is that this is
>> _somewhat_ acceptable for raw block device accesses since the "sector"
>> abstraction has a clear meaning, but once we add iomap/zonefs async zone
>> append
>> support, we really will want to have byte unit as the interface is regular
>> files, not block device file. We could argue that 512B sector unit is still
>> around even for files (e.g. block counts in file stat). Bu the different unit
>> for input and output of one operation is really ugly. This is not nice for
>> the user.
>>
>
> You can refer to the discussion with Jens, Pavel and Alex on the uring
> interface. With the bits we have and considering the maximun zone size
> supported, there is no space for a byte relative offset. We can take
> some bits from cqe->res, but we were afraid this is not very
> future-proof. Do you have a better idea?
If you can take 8 bits, that gives you 40 bits, enough to support byte relative
offsets for any zone size defined as a number of 512B sectors using an unsigned
int. Max zone size is 2^31 sectors in that case, so 2^40 bytes. Unless I am
already too tired and my math is failing me...
zone size is defined by chunk_sectors, which is used for raid and software raids
too. This has been an unsigned int forever. I do not see the need for changing
this to a 64bit anytime soon, if ever. A raid with a stripe size larger than 1TB
does not really make any sense. Same for zone size...
>
>
>>>
>>> Append using io_uring fixed-buffer --->
>>> This is flagged as not-supported at the moment. Reason being, for
>>> fixed-buffer
>>> io-uring sends iov_iter of bvec type. But current append-infra in
>>> block-layer
>>> does not support such iov_iter.
>>>
>>> Block IO vs File IO --->
>>> For now, the user zone-append interface is supported only for
>>> zoned-block-device.
>>> Regular files/block-devices are not supported. Regular file-system (e.g.
>>> F2FS)
>>> will not need this anyway, because zone peculiarities are abstracted within
>>> FS.
>>> At this point, ZoneFS also likes to use append implicitly rather than
>>> explicitly.
>>> But if/when ZoneFS starts supporting explicit/on-demand zone-append, the
>>> check
>>> allowing-only-block-device should be changed.
>>
>> Sure, but I think the interface is still a problem. I am not super happy
>> about
>> the 512B sector unit. Zonefs will be the only file system that will be
>> impacted
>> since other normal POSIX file system will not have
Re: [PATCH 2/2] xen/privcmd: Convert get_user_pages*() to pin_user_pages*()
On 2020-06-25 22:26, Souptick Joarder wrote:
On Thu, Jun 25, 2020 at 11:19 AM John Hubbard wrote:
On 2020-06-24 20:02, Souptick Joarder wrote:
...
@@ -612,13 +612,7 @@ static int lock_pages(
static void unlock_pages(struct page *pages[], unsigned int nr_pages)
{
- unsigned int i;
-
- for (i = 0; i < nr_pages; i++) {
- if (!PageDirty(page))
- set_page_dirty_lock(page);
- put_page(pages[i]);
- }
+ unpin_user_pages_dirty_lock(pages, nr_pages, 1);
"true", not "1", is the correct way to call that function.
Ok.
Also, this approach changes the behavior slightly, but I think it's
Correction, I forgot that I put that same if(!PageDirty(page)) check into
unpin_user_pages_dirty_lock(). So it doesn't change behavior. That's good.
reasonable to just set_page_dirty_lock() on the whole range--hard to
see much benefit in checking PageDirty first.
unpin_user_pages_dirty_lock() internally will do the same check after
patch [2/2]
So I thought to keep old and new code in sync. Shall we avoid this check ?
Just leave it as you have it, but of course use "true" instead of 1, please.
thanks,
--
John Hubbard
NVIDIA
Re: drivers/char/hw_random/npcm-rng.c:166:34: warning: unused variable 'rng_dt_id'
On Fri, Jun 26, 2020 at 04:42:25PM +1000, Herbert Xu wrote:
> On Tue, Jun 23, 2020 at 09:58:39PM +0800, kernel test robot wrote:
> >
> > >> drivers/char/hw_random/npcm-rng.c:166:34: warning: unused variable
> > >> 'rng_dt_id' [-Wunused-const-variable]
> >static const struct of_device_id rng_dt_id[] = {
> > ^
> >1 warning generated.
>
> The kernel is supposed to be built with -Wno-unused-const-variable,
> so I guess this is a deficiency in clang.
>
> Cheers,
> --
> Email: Herbert Xu
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>
No deficiency in clang, it's a W=1 build, which explicitly enables
-Wunused-const-variable per scripts/Kbuild.extrawarn. The 0day team
decided to enable W=1 for all build tests, hence the comment in the
reproduce notes. A thread with discussion:
https://lore.kernel.org/lkml/202005200123.gfjgzjeh%25...@intel.com/
Cheers,
Nathan
Re: [PATCH RFC 0/5] Introduced new Cadence USBSSP DRD Driver.
Hi, Pawel Laszczak writes: > This patch introduce new Cadence USBSS DRD driver to linux kernel. > > The Cadence USBSS DRD Controller is a highly configurable IP Core which > can be instantiated as Dual-Role Device (DRD), Peripheral Only and > Host Only (XHCI)configurations. > > The current driver has been validated with FPGA burned. We have support > for PCIe bus, which is used on FPGA prototyping. > > The host side of USBSS-DRD controller is compliance with XHCI > specification, so it works with standard XHCI Linux driver. > > The host side of USBSS DRD controller is compliant with XHCI. > The architecture for device side is almost the same as for host side, > and most of the XHCI specification can be used to understand how > this controller operates. > > This controller and driver support Full Speed, Hight Speed, Supper Speed > and Supper Speed Plus USB protocol. > > The prefix cdnsp used in driver has chosen by analogy to cdn3 driver. > The last letter of this acronym means PLUS. The formal name of controller > is USBSSP but it's to generic so I've decided to use CDNSP. > > The patch 1: adds DT binding. > The patch 2: adds PCI to platform wrapper used on Cadnece testing > platform. It is FPGA based on platform. > The patches 3-5: add the main part of driver and has been intentionally > split into 3 part. In my opinion such division should not > affect understanding and reviewing the driver, and cause that > main patch (4/5) is little smaller. Patch 3 introduces main > header file for driver, 4 is the main part that implements all > functionality of driver and 5 introduces tracepoints. I'm more interested in how is this different from CDNS3. Aren't they SW compatible? -- balbi signature.asc Description: PGP signature
Re: [PATCH 1/2] xen/privcmd: Corrected error handling path and mark pages dirty
On Fri, Jun 26, 2020 at 11:22 AM Jürgen Groß wrote:
>
> On 25.06.20 05:02, Souptick Joarder wrote:
> > Previously, if lock_pages() end up partially mapping pages, it used
> > to return -ERRNO due to which unlock_pages() have to go through
> > each pages[i] till *nr_pages* to validate them. This can be avoided
> > by passing correct number of partially mapped pages & -ERRNO separately,
> > while returning from lock_pages() due to error.
> >
> > With this fix unlock_pages() doesn't need to validate pages[i] till
> > *nr_pages* for error scenario and few condition checks can be ignored.
> >
> > As discussed, pages need to be marked as dirty before unpinned it in
> > unlock_pages() which was oversight.
> >
> > Signed-off-by: Souptick Joarder
> > Cc: John Hubbard
> > Cc: Boris Ostrovsky
> > Cc: Paul Durrant
> > ---
> > Hi,
> >
> > I'm compile tested this, but unable to run-time test, so any testing
> > help is much appriciated.
> >
> > drivers/xen/privcmd.c | 34 +++---
> > 1 file changed, 19 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> > index a250d11..0da417c 100644
> > --- a/drivers/xen/privcmd.c
> > +++ b/drivers/xen/privcmd.c
> > @@ -580,43 +580,44 @@ static long privcmd_ioctl_mmap_batch(
> >
> > static int lock_pages(
> > struct privcmd_dm_op_buf kbufs[], unsigned int num,
> > - struct page *pages[], unsigned int nr_pages)
> > + struct page *pages[], unsigned int nr_pages, int *pinned)
>
> unsigned int *pinned, please.
>
> > {
> > unsigned int i;
> > + int errno = 0, page_count = 0;
>
> Please drop the errno variable. It is misnamed (you never assign an
> errno value to it) and not needed, as you can ...
>
> >
> > for (i = 0; i < num; i++) {
> > unsigned int requested;
> > - int pinned;
> >
> > + *pinned += page_count;
> > requested = DIV_ROUND_UP(
> > offset_in_page(kbufs[i].uptr) + kbufs[i].size,
> > PAGE_SIZE);
> > if (requested > nr_pages)
> > return -ENOSPC;
> >
> > - pinned = get_user_pages_fast(
> > + page_count = get_user_pages_fast(
> > (unsigned long) kbufs[i].uptr,
> > requested, FOLL_WRITE, pages);
> > - if (pinned < 0)
> > - return pinned;
> > + if (page_count < 0) {
> > + errno = page_count;
> > + return errno;
>
> ... just return page_count her, and ...
>
> > + }
> >
> > - nr_pages -= pinned;
> > - pages += pinned;
> > + nr_pages -= page_count;
> > + pages += page_count;
> > }
> >
> > - return 0;
> > + return errno;
>
> ... leave this as it was.
>
> > }
> >
> > static void unlock_pages(struct page *pages[], unsigned int nr_pages)
> > {
> > unsigned int i;
> >
> > - if (!pages)
> > - return;
> > -
> > for (i = 0; i < nr_pages; i++) {
> > - if (pages[i])
> > - put_page(pages[i]);
> > + if (!PageDirty(page))
> > + set_page_dirty_lock(page);
>
> page? Not pages[i]?
I fixed it in compile branch, but missed it in patch creation work
space at the time of posting.
I think, this is the compile error Boris was pointing to.
Sorry about it. I will fix it and post the v2.
>
> > + put_page(pages[i]);
> > }
> > }
> >
> > @@ -630,6 +631,7 @@ static long privcmd_ioctl_dm_op(struct file *file, void
> > __user *udata)
> > struct xen_dm_op_buf *xbufs = NULL;
> > unsigned int i;
> > long rc;
> > + int pinned = 0;
> >
> > if (copy_from_user(&kdata, udata, sizeof(kdata)))
> > return -EFAULT;
> > @@ -683,9 +685,11 @@ static long privcmd_ioctl_dm_op(struct file *file,
> > void __user *udata)
> > goto out;
> > }
> >
> > - rc = lock_pages(kbufs, kdata.num, pages, nr_pages);
> > - if (rc)
> > + rc = lock_pages(kbufs, kdata.num, pages, nr_pages, &pinned);
> > + if (rc < 0) {
> > + nr_pages = pinned;
> > goto out;
> > + }
> >
> > for (i = 0; i < kdata.num; i++) {
> > set_xen_guest_handle(xbufs[i].h, kbufs[i].uptr);
> >
>
>
> Juergen
Re: drivers/char/hw_random/npcm-rng.c:166:34: warning: unused variable 'rng_dt_id'
On Tue, Jun 23, 2020 at 09:58:39PM +0800, kernel test robot wrote:
>
> >> drivers/char/hw_random/npcm-rng.c:166:34: warning: unused variable
> >> 'rng_dt_id' [-Wunused-const-variable]
>static const struct of_device_id rng_dt_id[] = {
> ^
>1 warning generated.
The kernel is supposed to be built with -Wno-unused-const-variable,
so I guess this is a deficiency in clang.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2 0/2] zone-append support in io-uring and aio
On 26.06.2020 03:11, Damien Le Moal wrote:
On 2020/06/26 2:18, Kanchan Joshi wrote:
[Revised as per feedback from Damien, Pavel, Jens, Christoph, Matias, Wilcox]
This patchset enables zone-append using io-uring/linux-aio, on block IO path.
Purpose is to provide zone-append consumption ability to applications which are
using zoned-block-device directly.
The application may specify RWF_ZONE_APPEND flag with write when it wants to
send zone-append. RWF_* flags work with a certain subset of APIs e.g. uring,
aio, and pwritev2. An error is reported if zone-append is requested using
pwritev2. It is not in the scope of this patchset to support pwritev2 or any
other sync write API for reasons described later.
Zone-append completion result --->
With zone-append, where write took place can only be known after completion.
So apart from usual return value of write, additional mean is needed to obtain
the actual written location.
In aio, this is returned to application using res2 field of io_event -
struct io_event {
__u64 data; /* the data field from the iocb */
__u64 obj;/* what iocb this event came from */
__s64 res;/* result code for this event */
__s64 res2; /* secondary result */
};
In io-uring, cqe->flags is repurposed for zone-append result.
struct io_uring_cqe {
__u64 user_data; /* sqe->data submission passed back */
__s32 res;/* result code for this event */
__u32 flags;
};
Since 32 bit flags is not sufficient, we choose to return zone-relative offset
in sector/512b units. This can cover zone-size represented by chunk_sectors.
Applications will have the trouble to combine this with zone start to know
disk-relative offset. But if more bits are obtained by pulling from res field
that too would compel application to interpret res field differently, and it
seems more painstaking than the former option.
To keep uniformity, even with aio, zone-relative offset is returned.
I am really not a fan of this, to say the least. The input is byte offset, the
output is 512B relative sector count... Arg... We really cannot do better than
that ?
At the very least, byte relative offset ? The main reason is that this is
_somewhat_ acceptable for raw block device accesses since the "sector"
abstraction has a clear meaning, but once we add iomap/zonefs async zone append
support, we really will want to have byte unit as the interface is regular
files, not block device file. We could argue that 512B sector unit is still
around even for files (e.g. block counts in file stat). Bu the different unit
for input and output of one operation is really ugly. This is not nice for the
user.
You can refer to the discussion with Jens, Pavel and Alex on the uring
interface. With the bits we have and considering the maximun zone size
supported, there is no space for a byte relative offset. We can take
some bits from cqe->res, but we were afraid this is not very
future-proof. Do you have a better idea?
Append using io_uring fixed-buffer --->
This is flagged as not-supported at the moment. Reason being, for fixed-buffer
io-uring sends iov_iter of bvec type. But current append-infra in block-layer
does not support such iov_iter.
Block IO vs File IO --->
For now, the user zone-append interface is supported only for
zoned-block-device.
Regular files/block-devices are not supported. Regular file-system (e.g. F2FS)
will not need this anyway, because zone peculiarities are abstracted within FS.
At this point, ZoneFS also likes to use append implicitly rather than
explicitly.
But if/when ZoneFS starts supporting explicit/on-demand zone-append, the check
allowing-only-block-device should be changed.
Sure, but I think the interface is still a problem. I am not super happy about
the 512B sector unit. Zonefs will be the only file system that will be impacted
since other normal POSIX file system will not have zone append interface for
users. So this is a limited problem. Still, even for raw block device files
accesses, POSIX system calls use Byte unit everywhere. Let's try to use that.
For aio, it is easy since res2 is unsigned long long. For io_uring, as discussed
already, we can still 8 bits from the cqe res. All you need is to add a small
helper function in userspace iouring.h to simplify the work of the application
to get that result.
Ok. See above. We can do this.
Jens: Do you see this as a problem in the future?
[...]
Javier
[PATCH] crypto: af_alg - Fix regression on empty requests
On Tue, Jun 23, 2020 at 10:02:17AM -0700, Eric Biggers wrote:
>
> The source code for the two failing AF_ALG tests is here:
>
> https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/crypto/af_alg02.c
> https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/crypto/af_alg05.c
>
> They use read() and write(), not send() and recv().
>
> af_alg02 uses read() to read from a "salsa20" request socket without writing
> anything to it. It is expected that this returns 0, i.e. that behaves like
> encrypting an empty message.
>
> af_alg05 uses write() to write 15 bytes to a "cbc(aes-generic)" request
> socket,
> then read() to read 15 bytes. It is expected that this fails with EINVAL,
> since
> the length is not aligned to the AES block size (16 bytes).
This patch should fix the regression:
---8<---
Some user-space programs rely on crypto requests that have no
control metadata. This broke when a check was added to require
the presence of control metadata with the ctx->init flag.
This patch fixes the regression by removing the ctx->init flag.
This means that we do not distinguish the case of no metadata
as opposed to an empty request. IOW it is always assumed that
if you call recv(2) before sending metadata that you are working
with an empty request.
Reported-by: Sachin Sant
Reported-by: Naresh Kamboju
Fixes: f3c802a1f300 ("crypto: algif_aead - Only wake up when...")
Signed-off-by: Herbert Xu
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 9fcb91ea10c4..2d391117c020 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -635,7 +635,6 @@ void af_alg_pull_tsgl(struct sock *sk, size_t used, struct
scatterlist *dst,
if (!ctx->used)
ctx->merge = 0;
- ctx->init = ctx->more;
}
EXPORT_SYMBOL_GPL(af_alg_pull_tsgl);
@@ -757,8 +756,7 @@ int af_alg_wait_for_data(struct sock *sk, unsigned flags,
unsigned min)
break;
timeout = MAX_SCHEDULE_TIMEOUT;
if (sk_wait_event(sk, &timeout,
- ctx->init && (!ctx->more ||
- (min && ctx->used >= min)),
+ !ctx->more || (min && ctx->used >= min),
&wait)) {
err = 0;
break;
@@ -847,7 +845,7 @@ int af_alg_sendmsg(struct socket *sock, struct msghdr *msg,
size_t size,
}
lock_sock(sk);
- if (ctx->init && (init || !ctx->more)) {
+ if (!ctx->more && ctx->used) {
err = -EINVAL;
goto unlock;
}
@@ -858,7 +856,6 @@ int af_alg_sendmsg(struct socket *sock, struct msghdr *msg,
size_t size,
memcpy(ctx->iv, con.iv->iv, ivsize);
ctx->aead_assoclen = con.aead_assoclen;
- ctx->init = true;
}
while (size) {
diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index d48d2156e621..749fe42315be 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -106,7 +106,7 @@ static int _aead_recvmsg(struct socket *sock, struct msghdr
*msg,
size_t usedpages = 0; /* [in] RX bufs to be used from user */
size_t processed = 0; /* [in] TX bufs to be consumed */
- if (!ctx->init || ctx->more) {
+ if (ctx->more) {
err = af_alg_wait_for_data(sk, flags, 0);
if (err)
return err;
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index a51ba22fef58..5b6fa5e8c00d 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -61,7 +61,7 @@ static int _skcipher_recvmsg(struct socket *sock, struct
msghdr *msg,
int err = 0;
size_t len = 0;
- if (!ctx->init || (ctx->more && ctx->used < bs)) {
+ if (ctx->more && ctx->used < bs) {
err = af_alg_wait_for_data(sk, flags, bs);
if (err)
return err;
diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
index ee6412314f8f..08c087cc89d6 100644
--- a/include/crypto/if_alg.h
+++ b/include/crypto/if_alg.h
@@ -135,7 +135,6 @@ struct af_alg_async_req {
* SG?
* @enc: Cryptographic operation to be performed when
* recvmsg is invoked.
- * @init: True if metadata has been sent.
* @len: Length of memory allocated for this data structure.
*/
struct af_alg_ctx {
@@ -152,7 +151,6 @@ struct af_alg_ctx {
bool more;
bool merge;
bool enc;
- bool init;
unsigned int len;
};
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v14 3/3] Input: new da7280 haptic driver
Hello,
from the PWM POV I'm happy now. Just a few minor comments that I noticed
while checking the PWM details.
On Thu, Jun 25, 2020 at 01:59:29AM +0900, Roy Im wrote:
> + val = haptics->ps_seq_id << DA7280_PS_SEQ_ID_SHIFT |
> + haptics->ps_seq_loop << DA7280_PS_SEQ_LOOP_SHIFT;
If you write this as:
val = FIELD_PREP(DA7280_PS_SEQ_ID_MASK, haptics->ps_seq_id) |
FIELD_PREP(DA7280_PS_SEQ_LOOP_MASK, haptics->ps_seq_loop);
you get some additional checks for free and can drop all defines for ..._SHIFT .
> +static u8 da7280_haptic_of_gpi_pol_str(struct device *dev,
> +const char *str)
> +{
> + if (!strcmp(str, "Rising-edge"))
> + return 0;
> + else if (!strcmp(str, "Falling-edge"))
> + return 1;
> + else if (!strcmp(str, "Both-edge"))
> + return 2;
> +
> + dev_warn(dev, "Invalid string - set to default\n");
Maybe mention "Rising-edge" being the default?
> + return 0;
> +}
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
Re: [PATCH v2] kbuild: buildtar: add arm64 dtbs support
On Fri, Jun 26, 2020 at 5:51 AM Domenico Andreoli
wrote:
>
> From: Domenico Andreoli
>
> Make 'make tar-pkg' install dtbs on arm64.
>
> Signed-off-by: Domenico Andreoli
>
> v2:
> - Destination path includes the kernel version, as expected
>
> ---
> scripts/package/buildtar |9 +
> 1 file changed, 9 insertions(+)
>
> Index: b/scripts/package/buildtar
> ===
> --- a/scripts/package/buildtar
> +++ b/scripts/package/buildtar
> @@ -125,6 +125,15 @@ case "${ARCH}" in
> ;;
> esac
>
> +#
> +# Install dtbs
> +#
> +case "${ARCH}" in
Instead of checking ${ARCH},
can you you do
if grep -q '^CONFIG_OF_EARLY_FLATTREE=y' include/config/auto.conf; then
?
This is what the deb package build does:
https://github.com/masahir0y/linux/blob/v5.7/scripts/package/builddeb#L145
> + arm64)
> + make ARCH="${ARCH}" -f ${srctree}/Makefile
> INSTALL_DTBS_PATH="${tmpdir}/boot/dtbs/${KERNELRELEASE}" dtbs_install
> + ;;
> +esac
> +
Or, you can use INSTALL_PATH="${tmpdir}/boot"
to make it shorter.
--
Best Regards
Masahiro Yamada
URGENT,
Dear Friend, How are you today with your family, Hope fine? Please, it’s my great pleasure to contact you today. I am Mr. Frank Nack a banker by profession from Burkina Faso. Please, I want our bank management to transfer an abandoned sum of (US$7.5M) into your bank account. This business is 100% risk free. Your share will be 40% while 60% for me. More details will be forwarded to you with copy of my bank working ID card, photos and direct phone number immediately I receive your urgent response indicating your interest to handle the business transaction with me. 1) Your Full Name... 2) Your Private Telephone Number 3) Your Receiving Country Do reply me urgent with this email address (frank_nack_2...@yahoo.com), (OR +226 51 81 51 94,) for quick spend Yours Sincerely, Best Regard. Mr. Frank Nack Tell; +226 51 81 51 94,
[RFC]PATCH] exfat: integrates dir-entry getting and validation
Add validation for num, bh and type on getting dir-entry.
('file' and 'stream-ext' dir-entries are pre-validated to ensure success)
Renamed exfat_get_dentry_cached() to exfat_get_validated_dentry() due to
a change in functionality.
Integrate type-validation with simplified.
This will also recognize a dir-entry set that contains 'benign secondary'
dir-entries.
And, rename TYPE_EXTEND to TYPE_NAME.
Suggested-by: Sungjong Seo
Signed-off-by: Tetsuhiro Kohada
---
fs/exfat/dir.c | 144 ++--
fs/exfat/exfat_fs.h | 15 +++--
fs/exfat/file.c | 4 +-
fs/exfat/inode.c| 6 +-
fs/exfat/namei.c| 4 +-
5 files changed, 73 insertions(+), 100 deletions(-)
diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c
index f4cea9a7fd02..e029e0986edc 100644
--- a/fs/exfat/dir.c
+++ b/fs/exfat/dir.c
@@ -33,6 +33,7 @@ static void exfat_get_uniname_from_ext_entry(struct
super_block *sb,
{
int i;
struct exfat_entry_set_cache *es;
+ struct exfat_dentry *ep;
es = exfat_get_dentry_set(sb, p_dir, entry, ES_ALL_ENTRIES);
if (!es)
@@ -44,13 +45,9 @@ static void exfat_get_uniname_from_ext_entry(struct
super_block *sb,
* Third entry : first file-name entry
* So, the index of first file-name dentry should start from 2.
*/
- for (i = 2; i < es->num_entries; i++) {
- struct exfat_dentry *ep = exfat_get_dentry_cached(es, i);
-
- /* end of name entry */
- if (exfat_get_entry_type(ep) != TYPE_EXTEND)
- break;
+ i = 2;
+ while ((ep = exfat_get_validated_dentry(es, i++, TYPE_NAME))) {
exfat_extract_uni_name(ep, uniname);
uniname += EXFAT_FILE_NAME_LEN;
}
@@ -372,7 +369,7 @@ unsigned int exfat_get_entry_type(struct exfat_dentry *ep)
if (ep->type == EXFAT_STREAM)
return TYPE_STREAM;
if (ep->type == EXFAT_NAME)
- return TYPE_EXTEND;
+ return TYPE_NAME;
if (ep->type == EXFAT_ACL)
return TYPE_ACL;
return TYPE_CRITICAL_SEC;
@@ -388,7 +385,7 @@ static void exfat_set_entry_type(struct exfat_dentry *ep,
unsigned int type)
ep->type &= EXFAT_DELETE;
} else if (type == TYPE_STREAM) {
ep->type = EXFAT_STREAM;
- } else if (type == TYPE_EXTEND) {
+ } else if (type == TYPE_NAME) {
ep->type = EXFAT_NAME;
} else if (type == TYPE_BITMAP) {
ep->type = EXFAT_BITMAP;
@@ -421,7 +418,7 @@ static void exfat_init_name_entry(struct exfat_dentry *ep,
{
int i;
- exfat_set_entry_type(ep, TYPE_EXTEND);
+ exfat_set_entry_type(ep, TYPE_NAME);
ep->dentry.name.flags = 0x0;
for (i = 0; i < EXFAT_FILE_NAME_LEN; i++) {
@@ -594,12 +591,12 @@ void exfat_update_dir_chksum_with_entry_set(struct
exfat_entry_set_cache *es)
struct exfat_dentry *ep;
for (i = 0; i < es->num_entries; i++) {
- ep = exfat_get_dentry_cached(es, i);
+ ep = exfat_get_validated_dentry(es, i, TYPE_ALL);
chksum = exfat_calc_chksum16(ep, DENTRY_SIZE, chksum,
chksum_type);
chksum_type = CS_DEFAULT;
}
- ep = exfat_get_dentry_cached(es, 0);
+ ep = exfat_get_validated_dentry(es, 0, TYPE_FILE);
ep->dentry.file.checksum = cpu_to_le16(chksum);
es->modified = true;
}
@@ -741,92 +738,66 @@ struct exfat_dentry *exfat_get_dentry(struct super_block
*sb,
return (struct exfat_dentry *)((*bh)->b_data + off);
}
-enum exfat_validate_dentry_mode {
- ES_MODE_STARTED,
- ES_MODE_GET_FILE_ENTRY,
- ES_MODE_GET_STRM_ENTRY,
- ES_MODE_GET_NAME_ENTRY,
- ES_MODE_GET_CRITICAL_SEC_ENTRY,
-};
-
-static bool exfat_validate_entry(unsigned int type,
- enum exfat_validate_dentry_mode *mode)
-{
- if (type == TYPE_UNUSED || type == TYPE_DELETED)
- return false;
-
- switch (*mode) {
- case ES_MODE_STARTED:
- if (type != TYPE_FILE && type != TYPE_DIR)
- return false;
- *mode = ES_MODE_GET_FILE_ENTRY;
- return true;
- case ES_MODE_GET_FILE_ENTRY:
- if (type != TYPE_STREAM)
- return false;
- *mode = ES_MODE_GET_STRM_ENTRY;
- return true;
- case ES_MODE_GET_STRM_ENTRY:
- if (type != TYPE_EXTEND)
- return false;
- *mode = ES_MODE_GET_NAME_ENTRY;
- return true;
- case ES_MODE_GET_NAME_ENTRY:
- if (type == TYPE_STREAM)
- return false;
- if (type != TYPE_EXTEND) {
- if (!(type & TYPE_CRITICAL_SEC))
-
Re: [PATCH v2 0/3] fixes and update to essiv support
On Sun, Jun 21, 2020 at 02:19:56PM +0300, Gilad Ben-Yossef wrote: > Small fixes and adapt essiv support to the new template format > > --- > Changes from v1: > - Incorporate coding style fixes suggested by Markus Elfring. > > Gilad Ben-Yossef (3): > crypto: ccree: fix resource leak on error path > crypto: ccree: adapt ccree essiv support to kcapi > crypto: ccree: remove unused field > > drivers/crypto/ccree/cc_cipher.c | 149 ++- > 1 file changed, 108 insertions(+), 41 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: ccp: remove redundant assignment to variable ret
On Thu, Jun 18, 2020 at 11:12:29AM +0100, Colin King wrote:
> From: Colin Ian King
>
> The variable ret is being assigned with a value that is never read
> and it is being updated later with a new value. The assignment is
> redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
> ---
> drivers/crypto/ccp/ccp-ops.c | 1 -
> 1 file changed, 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] crypto: img-hash: remove redundant initialization of variable err
On Thu, Jun 18, 2020 at 11:16:25AM +0100, Colin King wrote:
> From: Colin Ian King
>
> The variable err is being initialized with a value that is never read
> and it is being updated later with a new value. The initialization is
> redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
> ---
> drivers/crypto/img-hash.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 1/2] cpt-crypto: don't sleep of CRYPTO_TFM_REQ_MAY_SLEEP was not specified
On Wed, Jun 17, 2020 at 09:48:56AM -0400, Mikulas Patocka wrote:
> There is this call chain:
> cvm_encrypt -> cvm_enc_dec -> cptvf_do_request -> process_request -> kzalloc
> where we call sleeping allocator function even if CRYPTO_TFM_REQ_MAY_SLEEP
> was not specified.
>
> Signed-off-by: Mikulas Patocka
> Cc: sta...@vger.kernel.org# v4.11+
> Fixes: c694b233295b ("crypto: cavium - Add the Virtual Function driver for
> CPT")
>
> ---
> drivers/crypto/cavium/cpt/cptvf_algs.c |1 +
> drivers/crypto/cavium/cpt/cptvf_reqmanager.c | 12 ++--
> drivers/crypto/cavium/cpt/request_manager.h |2 ++
> 3 files changed, 9 insertions(+), 6 deletions(-)
All applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCHv3 0/2] Convert QCOM watchdog timer bindings to YAML
On 2020-06-26 02:48, Guenter Roeck wrote: On Fri, Jun 26, 2020 at 12:52:31AM +0530, Sai Prakash Ranjan wrote: > > > I don't think the watchdog mailing list has been copied on this series, > meaning I don't have a copy that I could apply if I wanted to. I kept you in CC for all the revisions but missed adding watchdog list. Will resend with the appropriate lists added. I use patchwork to track patches, tags, and my responses. No patchwork, no patch, no tags, and no tracking. Now resent with watchdog list added - https://lore.kernel.org/patchwork/cover/1263944/ Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v2] crypto: hisilicon - fix strncpy warning with strscpy
On Mon, Jun 15, 2020 at 11:38:37AM +0800, Zhangfei Gao wrote: > Use strscpy to fix the warning > warning: 'strncpy' specified bound 64 equals destination size > > Reported-by: kernel test robot > Signed-off-by: Zhangfei Gao > --- > v2: Use strscpy instead of strlcpy since better truncation handling > suggested by Herbert > Rebase to 5.8-rc1 > > drivers/crypto/hisilicon/qm.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH v7] hwmon: add Corsair Commander Pro driver
This is v7 of a driver for the Corsair Commander Pro.
It provides sysfs attributes for:
- Reading fan speed
- Reading temp sensors
- Reading voltage values
- Writing pwm and reading last written pwm
- Reading fan and temp connection status
It is an usb driver, so it needs to be ignored by usbhid.
The Corsair Commander Pro is a fan controller and provides
no means for user interaction.
The two device numbers are there, because there is a slightly
different version of the same device. (Only difference
seem to be in some presets.)
This is based on the staging/hwmon tree.
Signed-off-by: Marius Zachmann
---
Changes from v6
- used break after connection checks in ccp_is_visible
Changes from v5
- added bitmaps for temp_cnct and fan_cnct
- ccp_visible returns 0 when there is no connection
and removed tests for connection in other functions
- removed temp labels
- add define for fan and temp sensor count
- removed unneccesary mutex from get_temp_cnct and get_fan_cnct
and moved these functions directly above ccp_probe
- no more setting return values in ccp_read, ccp_read_string, ccp_write
just return directly instead of break
- get_data returns values (always >= 0) directly
- inlined get_temp
- removed first two error messages in send_usb_cmd and
changed last one to dev_dbg
- comment alignments and clarifications
- renamed goto label to "out_unlock"
Changes from v4
- squashed 3 commits into one.
Changes from v3
- add device ids to hid_ignore_list in hid-quirks.h
- removed unused update_interval
- ccp_disconnect is static
---
Documentation/hwmon/corsair-cpro.rst | 39 +++
Documentation/hwmon/index.rst| 1 +
MAINTAINERS | 6 +
drivers/hid/hid-quirks.c | 2 +
drivers/hwmon/Kconfig| 10 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/corsair-cpro.c | 456 +++
7 files changed, 515 insertions(+)
create mode 100644 Documentation/hwmon/corsair-cpro.rst
create mode 100644 drivers/hwmon/corsair-cpro.c
diff --git a/Documentation/hwmon/corsair-cpro.rst
b/Documentation/hwmon/corsair-cpro.rst
new file mode 100644
index ..5913e23d764c
--- /dev/null
+++ b/Documentation/hwmon/corsair-cpro.rst
@@ -0,0 +1,39 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver corsair-cpro
+==
+
+Supported devices:
+
+ * Corsair Commander Pro
+ * Corsair Commander Pro (1000D)
+
+Author: Marius Zachmann
+
+Description
+---
+
+This driver implements the sysfs interface for the Corsair Commander Pro.
+The Corsair Commander Pro is a USB device with 6 fan connectors,
+4 temperature sensor connectors and 2 Corsair LED connectors.
+It can read the voltage levels on the SATA power connector.
+
+Usage Notes
+---
+
+Since it is a USB device, hotswapping is possible. The device is autodetected.
+
+Sysfs entries
+-
+
+===
=
+in0_input Voltage on SATA 12v
+in1_input Voltage on SATA 5v
+in2_input Voltage on SATA 3.3v
+temp[1-4]_inputTemperature on connected temperature sensors
+fan[1-6]_input Connected fan rpm.
+fan[1-6]_label Shows fan type as detected by the device.
+pwm[1-6] Sets the fan speed. Values from 0-255.
+ When reading, it reports the last value if it was set
by the driver.
+ Otherwise returns 0.
+===
=
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 55ff4b7c5349..750d3a975d82 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -47,6 +47,7 @@ Hardware Monitoring Kernel Drivers
bel-pfe
bt1-pvt
coretemp
+ corsair-cpro
da9052
da9055
dell-smm-hwmon
diff --git a/MAINTAINERS b/MAINTAINERS
index 68f21d46614c..47b0361718f4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4400,6 +4400,12 @@ S: Maintained
F: Documentation/hwmon/coretemp.rst
F: drivers/hwmon/coretemp.c
+CORSAIR-CPRO HARDWARE MONITOR DRIVER
+M: Marius
+L: linux-hw...@vger.kernel.org
+S: Maintained
+F: drivers/hwmon/corsair-cpro.c
+
COSA/SRP SYNC SERIAL DRIVER
M: Jan "Yenya" Kasprzak
S: Maintained
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index ca8b5c261c7c..7b7bc7737c53 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -699,6 +699,8 @@ static const struct hid_device_id hid_ignore_list[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_AXENTIA, USB_DEVICE_ID_AXENTIA_FM_RADIO)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_BERKSHIRE, USB_DEVICE_ID_BERKSHIRE_PCWD)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_CIDC, 0x0103) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, 0x0c10) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_COR
Re: [Bug, sched, 5.8-rc2]: PREEMPT kernels crashing in check_preempt_wakeup() running fsx on XFS
On Fri, Jun 26, 2020 at 10:47:22AM +1000, Dave Chinner wrote: > Hi folks, > > I turned on CONFIG_PREEMPT=y yesterday to try to reproduce problems > Darrick was having with one of my patchsets. We've both been seeing > a dead stop panic on these configs, and I managed to find a > relatively reliable reproducer in fstests generic/127. It's > basically just single fsx process exercising a single file, and it > results in this happening within 15 minutes of starting the test > running in a loop: > > [ 1102.169209] BUG: kernel NULL pointer dereference, address: 0150 > [ 1102.171270] #PF: supervisor read access in kernel mode > [ 1102.172894] #PF: error_code(0x) - not-present page > [ 1102.174408] PGD 0 P4D 0 > [ 1102.175136] Oops: [#1] PREEMPT SMP > [ 1102.176293] CPU: 2 PID: 909 Comm: kworker/2:1H Not tainted 5.8.0-rc2-dgc+ > #2469 > [ 1102.178395] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > 1.12.0-1 04/01/2014 > [ 1102.180762] Workqueue: xfs-log/pmem0 xlog_ioend_work > [ 1102.182286] RIP: 0010:check_preempt_wakeup+0xc8/0x1e0 > [ 1102.183804] Code: 39 c2 75 f2 89 d0 39 d0 7d 20 83 ea 01 4d 8b a4 24 48 01 > 00 00 39 d0 75 f1 eb 0f 48 8b 9b 48 01 00 00 4d 8b a4 24 48 01 00 00 <48> 8b > bb 50 01 00 00 49 39 bc 24 b > [ 1102.189125] RSP: 0018:c971cea0 EFLAGS: 00010006 > [ 1102.190625] RAX: RBX: RCX: > 822305a0 > [ 1102.192737] RDX: RSI: 88853337cd80 RDI: > 88853ea2a940 > [ 1102.194827] RBP: c971ced8 R08: 822305a0 R09: > 88853ec2b2d0 > [ 1102.196886] R10: 88800f74b010 R11: 88853ec2a970 R12: > > [ 1102.199040] R13: 88853ea2a8c0 R14: 0001 R15: > 88853e3b > [ 1102.200883] FS: () GS:88853ea0() > knlGS: > [ 1102.203306] CS: 0010 DS: ES: CR0: 80050033 > [ 1102.205024] CR2: 0150 CR3: ae7b5004 CR4: > 00060ee0 > [ 1102.207117] Call Trace: > [ 1102.207895] > [ 1102.208500] ? enqueue_task_fair+0x1d7/0x9f0 > [ 1102.209709] check_preempt_curr+0x74/0x80 > [ 1102.210931] ttwu_do_wakeup+0x1e/0x170 > [ 1102.212064] ttwu_do_activate+0x5b/0x70 > [ 1102.213225] sched_ttwu_pending+0x94/0xe0 > [ 1102.214410] flush_smp_call_function_queue+0xf1/0x190 > [ 1102.215885] generic_smp_call_function_single_interrupt+0x13/0x20 > [ 1102.217790] __sysvec_call_function_single+0x2b/0xe0 > [ 1102.219375] asm_call_on_stack+0xf/0x20 > [ 1102.220599] > [ 1102.221280] sysvec_call_function_single+0x7e/0x90 > [ 1102.222854] asm_sysvec_call_function_single+0x12/0x20 > [ 1102.224515] RIP: 0010:_raw_spin_unlock_irqrestore+0x14/0x30 > [ 1102.226350] Code: e8 e8 20 25 ff 5d c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f > 1f 40 00 66 66 66 66 90 55 48 89 e5 53 48 89 f3 e8 5e 11 39 ff 53 9d <65> ff > 0d c5 72 26 7e 74 03 5b 5d f > [ 1102.232213] RSP: 0018:c900020b7cc8 EFLAGS: 0246 > [ 1102.233902] RAX: 0001 RBX: 0246 RCX: > > [ 1102.236134] RDX: 0002 RSI: 0246 RDI: > 88852679a400 > [ 1102.238402] RBP: c900020b7cd0 R08: 88852679a400 R09: > c900020b7ce8 > [ 1102.240598] R10: 88852a04e480 R11: 0001 R12: > > [ 1102.242906] R13: 0246 R14: R15: > 0003 > [ 1102.245191] __wake_up_common_lock+0x8a/0xc0 > [ 1102.246572] __wake_up+0x13/0x20 > [ 1102.247636] xlog_state_clean_iclog+0xf7/0x1a0 > [ 1102.249075] xlog_state_do_callback+0x257/0x300 > [ 1102.250548] xlog_state_done_syncing+0x69/0xb0 > [ 1102.251958] xlog_ioend_work+0x6c/0xc0 > [ 1102.253151] process_one_work+0x1a6/0x390 > [ 1102.254403] worker_thread+0x50/0x3b0 > [ 1102.255595] ? process_one_work+0x390/0x390 > [ 1102.256913] kthread+0x131/0x170 > [ 1102.257993] ? __kthread_create_on_node+0x1b0/0x1b0 > [ 1102.259546] ret_from_fork+0x1f/0x30 > [ 1102.260707] CR2: 0150 > [ 1102.261779] ---[ end trace d5f0aeef2eb333bd ]--- > [ 1102.263238] RIP: 0010:check_preempt_wakeup+0xc8/0x1e0 > [ 1102.264848] Code: 39 c2 75 f2 89 d0 39 d0 7d 20 83 ea 01 4d 8b a4 24 48 01 > 00 00 39 d0 75 f1 eb 0f 48 8b 9b 48 01 00 00 4d 8b a4 24 48 01 00 00 <48> 8b > bb 50 01 00 00 49 39 bc 24 b > [ 1102.270645] RSP: 0018:c971cea0 EFLAGS: 00010006 > [ 1102.272237] RAX: RBX: RCX: > 822305a0 > [ 1102.274439] RDX: RSI: 88853337cd80 RDI: > 88853ea2a940 > [ 1102.276613] RBP: c971ced8 R08: 822305a0 R09: > 88853ec2b2d0 > [ 1102.278797] R10: 88800f74b010 R11: 88853ec2a970 R12: > > [ 1102.280930] R13: 88853ea2a8c0 R14: 0001 R15: > 88853e3b > [ 1102.283094] FS: () GS:88853ea0() > knlGS: > [ 1102.285648] CS: 0010 DS: ES: CR0: 80050033 > [ 1102.287415] CR2: 00
Re: [PATCH 1/2] xen/privcmd: Corrected error handling path and mark pages dirty
On 25.06.20 05:02, Souptick Joarder wrote:
Previously, if lock_pages() end up partially mapping pages, it used
to return -ERRNO due to which unlock_pages() have to go through
each pages[i] till *nr_pages* to validate them. This can be avoided
by passing correct number of partially mapped pages & -ERRNO separately,
while returning from lock_pages() due to error.
With this fix unlock_pages() doesn't need to validate pages[i] till
*nr_pages* for error scenario and few condition checks can be ignored.
As discussed, pages need to be marked as dirty before unpinned it in
unlock_pages() which was oversight.
Signed-off-by: Souptick Joarder
Cc: John Hubbard
Cc: Boris Ostrovsky
Cc: Paul Durrant
---
Hi,
I'm compile tested this, but unable to run-time test, so any testing
help is much appriciated.
drivers/xen/privcmd.c | 34 +++---
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index a250d11..0da417c 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -580,43 +580,44 @@ static long privcmd_ioctl_mmap_batch(
static int lock_pages(
struct privcmd_dm_op_buf kbufs[], unsigned int num,
- struct page *pages[], unsigned int nr_pages)
+ struct page *pages[], unsigned int nr_pages, int *pinned)
unsigned int *pinned, please.
{
unsigned int i;
+ int errno = 0, page_count = 0;
Please drop the errno variable. It is misnamed (you never assign an
errno value to it) and not needed, as you can ...
for (i = 0; i < num; i++) {
unsigned int requested;
- int pinned;
+ *pinned += page_count;
requested = DIV_ROUND_UP(
offset_in_page(kbufs[i].uptr) + kbufs[i].size,
PAGE_SIZE);
if (requested > nr_pages)
return -ENOSPC;
- pinned = get_user_pages_fast(
+ page_count = get_user_pages_fast(
(unsigned long) kbufs[i].uptr,
requested, FOLL_WRITE, pages);
- if (pinned < 0)
- return pinned;
+ if (page_count < 0) {
+ errno = page_count;
+ return errno;
... just return page_count her, and ...
+ }
- nr_pages -= pinned;
- pages += pinned;
+ nr_pages -= page_count;
+ pages += page_count;
}
- return 0;
+ return errno;
... leave this as it was.
}
static void unlock_pages(struct page *pages[], unsigned int nr_pages)
{
unsigned int i;
- if (!pages)
- return;
-
for (i = 0; i < nr_pages; i++) {
- if (pages[i])
- put_page(pages[i]);
+ if (!PageDirty(page))
+ set_page_dirty_lock(page);
page? Not pages[i]?
+ put_page(pages[i]);
}
}
@@ -630,6 +631,7 @@ static long privcmd_ioctl_dm_op(struct file *file, void __user *udata)
struct xen_dm_op_buf *xbufs = NULL;
unsigned int i;
long rc;
+ int pinned = 0;
if (copy_from_user(&kdata, udata, sizeof(kdata)))
return -EFAULT;
@@ -683,9 +685,11 @@ static long privcmd_ioctl_dm_op(struct file *file, void
__user *udata)
goto out;
}
- rc = lock_pages(kbufs, kdata.num, pages, nr_pages);
- if (rc)
+ rc = lock_pages(kbufs, kdata.num, pages, nr_pages, &pinned);
+ if (rc < 0) {
+ nr_pages = pinned;
goto out;
+ }
for (i = 0; i < kdata.num; i++) {
set_xen_guest_handle(xbufs[i].h, kbufs[i].uptr);
Juergen
Re: [PATCH 1/2] xen/privcmd: Corrected error handling path and mark pages dirty
On Fri, Jun 26, 2020 at 5:01 AM Boris Ostrovsky
wrote:
>
> On 6/24/20 11:02 PM, Souptick Joarder wrote:
> > Previously, if lock_pages() end up partially mapping pages, it used
> > to return -ERRNO due to which unlock_pages() have to go through
> > each pages[i] till *nr_pages* to validate them. This can be avoided
> > by passing correct number of partially mapped pages & -ERRNO separately,
> > while returning from lock_pages() due to error.
> >
> > With this fix unlock_pages() doesn't need to validate pages[i] till
> > *nr_pages* for error scenario and few condition checks can be ignored.
> >
> > As discussed, pages need to be marked as dirty before unpinned it in
> > unlock_pages() which was oversight.
>
>
> There are two unrelated changes here (improving error path and marking
> pages dirty), they should be handled by separate patches.
Sure, will do it in v2.
>
>
> (I assume marking pages dirty is something you want to go to stable tree
> since otherwise there is no reason for making this change)
>
>
> >
> > Signed-off-by: Souptick Joarder
> > Cc: John Hubbard
> > Cc: Boris Ostrovsky
> > Cc: Paul Durrant
> > ---
> > Hi,
> >
> > I'm compile tested this,
>
>
> I don't think so.
I compile test it against ARM and it was fine.
Against which ARCH is it failing ?
>
>
> > but unable to run-time test, so any testing
> > help is much appriciated.
> >
> > drivers/xen/privcmd.c | 34 +++---
> > 1 file changed, 19 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> > index a250d11..0da417c 100644
> > --- a/drivers/xen/privcmd.c
> > +++ b/drivers/xen/privcmd.c
> > @@ -580,43 +580,44 @@ static long privcmd_ioctl_mmap_batch(
> >
> > static int lock_pages(
> > struct privcmd_dm_op_buf kbufs[], unsigned int num,
> > - struct page *pages[], unsigned int nr_pages)
> > + struct page *pages[], unsigned int nr_pages, int *pinned)
> > {
> > unsigned int i;
> > + int errno = 0, page_count = 0;
>
>
> No need for error, really --- you can return the value immediately.
yes, this is unnecessary.
>
>
> >
> > for (i = 0; i < num; i++) {
> > unsigned int requested;
> > - int pinned;
> >
> > + *pinned += page_count;
>
>
> I'd move this lower, after a successful call to get_user_pages_fast()
> (and then you won't need to initialize it)
Ok.
>
>
> > requested = DIV_ROUND_UP(
> > offset_in_page(kbufs[i].uptr) + kbufs[i].size,
> > PAGE_SIZE);
> > if (requested > nr_pages)
> > return -ENOSPC;
> >
> > - pinned = get_user_pages_fast(
> > + page_count = get_user_pages_fast(
> > (unsigned long) kbufs[i].uptr,
> > requested, FOLL_WRITE, pages);
> > - if (pinned < 0)
> > - return pinned;
> > + if (page_count < 0) {
> > + errno = page_count;
> > + return errno;
> > + }
> >
> > - nr_pages -= pinned;
> > - pages += pinned;
> > + nr_pages -= page_count;
> > + pages += page_count;
> > }
> >
> > - return 0;
> > + return errno;
> > }
> >
> > static void unlock_pages(struct page *pages[], unsigned int nr_pages)
> > {
> > unsigned int i;
> >
> > - if (!pages)
> > - return;
> > -
> > for (i = 0; i < nr_pages; i++) {
> > - if (pages[i])
> > - put_page(pages[i]);
> > + if (!PageDirty(page))
> > + set_page_dirty_lock(page);
> > + put_page(pages[i]);
> > }
>
>
> This won't compile.
>
>
> -boris
>
>
>
Re: [PATCH v2] ring-buffer: Have nested events still record running time stamp
Hi Steven, Thank you for the patch! Yet something to improve: [auto build test ERROR on tip/perf/core] [also build test ERROR on linux/master linus/master v5.8-rc2 next-20200625] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Steven-Rostedt/ring-buffer-Have-nested-events-still-record-running-time-stamp/20200626-105715 base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git bb42b3d39781d7fcd3be7f9f9bf11b6661b5fdf1 config: openrisc-allyesconfig (attached as .config) compiler: or1k-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): 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 COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=openrisc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): >> kernel/trace/ring_buffer.c:30:10: fatal error: asm/local64.h: No such file >> or directory 30 | #include | ^~~ compilation terminated. vim +30 kernel/trace/ring_buffer.c 28 29 #include > 30 #include 31 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH 2/2] xen/privcmd: Convert get_user_pages*() to pin_user_pages*()
On Thu, Jun 25, 2020 at 11:19 AM John Hubbard wrote:
>
> On 2020-06-24 20:02, Souptick Joarder wrote:
> > In 2019, we introduced pin_user_pages*() and now we are converting
> > get_user_pages*() to the new API as appropriate. [1] & [2] could
> > be referred for more information. This is case 5 as per document [1].
> >
> > [1] Documentation/core-api/pin_user_pages.rst
> >
> > [2] "Explicit pinning of user-space pages":
> > https://lwn.net/Articles/807108/
> >
> > Signed-off-by: Souptick Joarder
> > Cc: John Hubbard
> > Cc: Boris Ostrovsky
> > Cc: Paul Durrant
> > ---
> > Hi,
> >
> > I'm compile tested this, but unable to run-time test, so any testing
> > help is much appriciated.
> >
> > drivers/xen/privcmd.c | 10 ++
> > 1 file changed, 2 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> > index 0da417c..eb05254 100644
> > --- a/drivers/xen/privcmd.c
> > +++ b/drivers/xen/privcmd.c
> > @@ -595,7 +595,7 @@ static int lock_pages(
> > if (requested > nr_pages)
> > return -ENOSPC;
> >
> > - page_count = get_user_pages_fast(
> > + page_count = pin_user_pages_fast(
> > (unsigned long) kbufs[i].uptr,
> > requested, FOLL_WRITE, pages);
> > if (page_count < 0) {
> > @@ -612,13 +612,7 @@ static int lock_pages(
> >
> > static void unlock_pages(struct page *pages[], unsigned int nr_pages)
> > {
> > - unsigned int i;
> > -
> > - for (i = 0; i < nr_pages; i++) {
> > - if (!PageDirty(page))
> > - set_page_dirty_lock(page);
> > - put_page(pages[i]);
> > - }
> > + unpin_user_pages_dirty_lock(pages, nr_pages, 1);
>
> "true", not "1", is the correct way to call that function.
Ok.
>
> Also, this approach changes the behavior slightly, but I think it's
> reasonable to just set_page_dirty_lock() on the whole range--hard to
> see much benefit in checking PageDirty first.
unpin_user_pages_dirty_lock() internally will do the same check after
patch [2/2]
So I thought to keep old and new code in sync. Shall we avoid this check ?
>
>
> > }
> >
> > static long privcmd_ioctl_dm_op(struct file *file, void __user *udata)
> >
>
> thanks,
> --
> John Hubbard
> NVIDIA
Re: [Tee-dev] [PATCHv8 1/3] optee: use uuid for sysfs driver entry
On Thu, 25 Jun 2020 at 18:22, Maxim Uvarov wrote: > > On Wed, 24 Jun 2020 at 18:44, Jerome Forissier wrote: > > > > > > > > On 6/24/20 5:21 PM, James Bottomley wrote: > > > On Wed, 2020-06-24 at 16:17 +0530, Sumit Garg wrote: > > >> Apologies for delay in my reply as I was busy with some other stuff. > > >> > > >> On Fri, 19 Jun 2020 at 20:30, James Bottomley > > >> wrote: > > > [...] > > >>> it's about consistency with what the kernel types mean. When some > > >>> checker detects your using little endian operations on a big endian > > >>> structure (like in the prink for instance) they're going to keep > > >>> emailing you about it. > > >> > > >> As mentioned above, using different terminology is meant to cause > > >> more confusion than just difference in endianness which is manageable > > >> inside TEE. > > >> > > >> And I think it's safe to say that the kernel implements UUID in big > > >> endian format and thus uses %pUb whereas OP-TEE implements UUID in > > >> little endian format and thus uses %pUl. > > > > > > So what I think you're saying is that if we still had uuid_be and > > > uuid_le you'd use uuid_le, because that's exactly the structure > > > described in the docs. But because we renamed > > > > > > uuid_be -> uuid_t > > > uuid_le -> guid_t > > > > > > You can't use guid_t as a kernel type because it has the wrong name? > > > > Let me try to clear the confusion that I introduce myself I believe :-/ > > IMO: > > > > - optee_register_device(const uuid_t *device_uuid) *is* the correct > > prototype. > > - device_uuid is *guaranteed* to be BE because OP-TEE makes this > > guarantee (it converts from its internal LE representation to BE when > > enumerating the devices, but it doesn't matter to the kernel). > > - Therefore %pUb is the correct format. > > > > I'm sorry for doubting the BE order initially. I am so used to OP-TEE > > using LE internally, that I missed the fact that we have an explicit > > conversion... > > > > Does this sound good? > > > > Thanks, > > -- > > Jerome > > I think your description is correct. But I think this problem would > be solved outside of the current patchset. > All places should use one single format (LE): > - internal optee representation; > - device enumeration pta; > - this kernel driver which creates sysfs entry and sets > uid_copy(&optee_device->id.uuid, device_uuid); > - matching function; > - drivers use UUID_INIT(); > > In that way everything will be consistent. But it will require > changing other pieces, not just the kernel. While > these patches add functionality to support current device enumeration > in optee os. > So I think this version is ok to be applied. I guess here you meant v9 patch-set. If yes then it's fine with me as well. -Sumit > > Regards, > Maxim.
Re: [PATCH net-next v2] xfrm: introduce oseq-may-wrap flag
On Sat, May 30, 2020 at 02:39:12PM +0200, Petr Vaněk wrote: > RFC 4303 in section 3.3.3 suggests to disable anti-replay for manually > distributed ICVs in which case the sender does not need to monitor or > reset the counter. However, the sender still increments the counter and > when it reaches the maximum value, the counter rolls over back to zero. > > This patch introduces new extra_flag XFRM_SA_XFLAG_OSEQ_MAY_WRAP which > allows sequence number to cycle in outbound packets if set. This flag is > used only in legacy and bmp code, because esn should not be negotiated > if anti-replay is disabled (see note in 3.3.3 section). > > Signed-off-by: Petr Vaněk Now applied to ipsec-next, thanks a lot!
Re: linux-next: umh: fix processed error when UMH_WAIT_PROC is used seems to break linux bridge on s390x (bisected)
On 26.06.20 04:54, Luis Chamberlain wrote: > On Wed, Jun 24, 2020 at 08:37:55PM +0200, Christian Borntraeger wrote: >> >> >> On 24.06.20 20:32, Christian Borntraeger wrote: >> [...]> >>> So the translations look correct. But your change is actually a sematic >>> change >>> if(ret) will only trigger if there is an error >>> if (KWIFEXITED(ret)) will always trigger when the process ends. So we will >>> always overwrite -ECHILD >>> and we did not do it before. >>> >> >> So the right fix is >> >> diff --git a/kernel/umh.c b/kernel/umh.c >> index f81e8698e36e..a3a3196e84d1 100644 >> --- a/kernel/umh.c >> +++ b/kernel/umh.c >> @@ -154,7 +154,7 @@ static void call_usermodehelper_exec_sync(struct >> subprocess_info *sub_info) >> * the real error code is already in sub_info->retval or >> * sub_info->retval is 0 anyway, so don't mess with it then. >> */ >> - if (KWIFEXITED(ret)) >> + if (KWEXITSTATUS(ret)) >> sub_info->retval = KWEXITSTATUS(ret); >> } >> >> I think. > > Nope, the right form is to check for WIFEXITED() before using WEXITSTATUS(). But this IS a change over the previous code, no? I will test next week as I am travelling right now.
[rcu:rcu/urgent] BUILD SUCCESS b58e733fd774f3f4b49d9e7640d172a57e35200e
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/urgent branch HEAD: b58e733fd774f3f4b49d9e7640d172a57e35200e rcu: Fixup noinstr warnings elapsed time: 723m configs tested: 120 configs skipped: 5 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig arc haps_hs_smp_defconfig s390 allyesconfig powerpc g5_defconfig mipsjmr3927_defconfig sh se7751_defconfig arm imx_v6_v7_defconfig armxcep_defconfig arm pxa255-idp_defconfig arm tango4_defconfig arm mainstone_defconfig arm moxart_defconfig m68kq40_defconfig sh sdk7786_defconfig s390 allnoconfig armmps2_defconfig arm pxa_defconfig arm lpc18xx_defconfig mips ip27_defconfig arm eseries_pxa_defconfig mips loongson3_defconfig i386 alldefconfig nds32 allnoconfig sh se7724_defconfig mips loongson1b_defconfig pariscallnoconfig armlart_defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig powerpc defconfig i386 randconfig-a002-20200624 i386 randconfig-a006-20200624 i386 randconfig-a003-20200624 i386 randconfig-a001-20200624 i386 randconfig-a005-20200624 i386 randconfig-a004-20200624 i386 randconfig-a013-20200624 i386 randconfig-a016-20200624 i386 randconfig-a012-20200624 i386 randconfig-a014-20200624 i386 randconfig-a011-20200624 i386 randconfig-a015-20200624 x86_64 randconfig-a004-20200624 x86_64 randconfig-a002-20200624 x86_64 randconfig-a003-20200624 x86_64 randconfig-a005-20200624 x86_64 randconfig-a001-20200624 x86_64 randconfig-a006-20200624 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allmodconfig s390
[rcu:rcu/test] BUILD SUCCESS 12f2d29942ce0b140b8f03679d9f1d36d552fa70
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/test branch HEAD: 12f2d29942ce0b140b8f03679d9f1d36d552fa70 Merge remote-tracking branch 'linus/master' into HEAD elapsed time: 723m configs tested: 120 configs skipped: 5 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig arc haps_hs_smp_defconfig s390 allyesconfig powerpc g5_defconfig mipsjmr3927_defconfig sh se7751_defconfig arm imx_v6_v7_defconfig armxcep_defconfig arm pxa255-idp_defconfig arm tango4_defconfig arm mainstone_defconfig arm moxart_defconfig m68kq40_defconfig sh sdk7786_defconfig s390 allnoconfig armmps2_defconfig arm pxa_defconfig arm lpc18xx_defconfig mips ip27_defconfig arm eseries_pxa_defconfig i386 alldefconfig nds32 allnoconfig sh se7724_defconfig mips loongson1b_defconfig pariscallnoconfig armlart_defconfig mips loongson3_defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a002-20200624 i386 randconfig-a006-20200624 i386 randconfig-a003-20200624 i386 randconfig-a001-20200624 i386 randconfig-a005-20200624 i386 randconfig-a004-20200624 i386 randconfig-a013-20200624 i386 randconfig-a016-20200624 i386 randconfig-a012-20200624 i386 randconfig-a014-20200624 i386 randconfig-a011-20200624 i386 randconfig-a015-20200624 x86_64 randconfig-a004-20200624 x86_64 randconfig-a002-20200624 x86_64 randconfig-a003-20200624 x86_64 randconfig-a005-20200624 x86_64 randconfig-a001-20200624 x86_64 randconfig-a006-20200624 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 a
Re: [PATCH v6 0/6] workingset protection/detection on the anonymous LRU list
2020년 6월 17일 (수) 오후 2:26, 님이 작성: > > From: Joonsoo Kim > > Hello, > > This patchset implements workingset protection and detection on > the anonymous LRU list. > > * Changes on v6 > - rework to reflect a new LRU balance model > - remove memcg charge timing stuff on v5 since alternative is already > merged on mainline > - remove readahead stuff on v5 (reason is the same with above) > - clear shadow entry if corresponding swap entry is deleted > (mm/swapcache: support to handle the exceptional entries in swapcache) > - change experiment environment > (from ssd swap to ram swap, for fast evaluation and for reducing side-effect > of I/O) > - update performance number Hello, Johannes. Could you review the v6 patchset? Some minor things have changed so it's really welcome if you review the patchset again. Especially, "mm/swap: implement workingset detection for anonymous LRU" doesn't get any ack yet. :) Thanks.
Re: [Tee-dev] [PATCHv8 1/3] optee: use uuid for sysfs driver entry
On Thu, 25 Jun 2020 at 18:22, Maxim Uvarov wrote: > > On Wed, 24 Jun 2020 at 18:44, Jerome Forissier wrote: > > > > > > > > On 6/24/20 5:21 PM, James Bottomley wrote: > > > On Wed, 2020-06-24 at 16:17 +0530, Sumit Garg wrote: > > >> Apologies for delay in my reply as I was busy with some other stuff. > > >> > > >> On Fri, 19 Jun 2020 at 20:30, James Bottomley > > >> wrote: > > > [...] > > >>> it's about consistency with what the kernel types mean. When some > > >>> checker detects your using little endian operations on a big endian > > >>> structure (like in the prink for instance) they're going to keep > > >>> emailing you about it. > > >> > > >> As mentioned above, using different terminology is meant to cause > > >> more confusion than just difference in endianness which is manageable > > >> inside TEE. > > >> > > >> And I think it's safe to say that the kernel implements UUID in big > > >> endian format and thus uses %pUb whereas OP-TEE implements UUID in > > >> little endian format and thus uses %pUl. > > > > > > So what I think you're saying is that if we still had uuid_be and > > > uuid_le you'd use uuid_le, because that's exactly the structure > > > described in the docs. But because we renamed > > > > > > uuid_be -> uuid_t > > > uuid_le -> guid_t > > > > > > You can't use guid_t as a kernel type because it has the wrong name? > > > > Let me try to clear the confusion that I introduce myself I believe :-/ > > IMO: > > > > - optee_register_device(const uuid_t *device_uuid) *is* the correct > > prototype. > > - device_uuid is *guaranteed* to be BE because OP-TEE makes this > > guarantee (it converts from its internal LE representation to BE when > > enumerating the devices, but it doesn't matter to the kernel). > > - Therefore %pUb is the correct format. > > > > I'm sorry for doubting the BE order initially. I am so used to OP-TEE > > using LE internally, that I missed the fact that we have an explicit > > conversion... > > > > Does this sound good? > > > > Thanks, > > -- > > Jerome > > I think your description is correct. But I think this problem would > be solved outside of the current patchset. > All places should use one single format (LE): I guess you missed the point that uuid_t is implemented in BE format in the kernel which is compliant as per RFC 4122. > - internal optee representation; > - device enumeration pta; > - this kernel driver which creates sysfs entry and sets > uid_copy(&optee_device->id.uuid, device_uuid); > - matching function; > - drivers use UUID_INIT(); See carefully the implementation of UUID_INIT() which is in BE format. -Sumit > > In that way everything will be consistent. But it will require > changing other pieces, not just the kernel. While > these patches add functionality to support current device enumeration > in optee os. > So I think this version is ok to be applied. > > Regards, > Maxim.
Re: [Tee-dev] [PATCHv8 1/3] optee: use uuid for sysfs driver entry
On Fri, 26 Jun 2020 at 05:01, James Bottomley wrote: > > On Thu, 2020-06-25 at 19:54 +0530, Sumit Garg wrote: > > On Wed, 24 Jun 2020 at 20:51, James Bottomley > > wrote: > > > > > > On Wed, 2020-06-24 at 16:17 +0530, Sumit Garg wrote: > > > > Apologies for delay in my reply as I was busy with some other > > > > stuff. > > > > > > > > On Fri, 19 Jun 2020 at 20:30, James Bottomley > > > > wrote: > > > > > > [...] > > > > > it's about consistency with what the kernel types mean. When > > > > > some checker detects your using little endian operations on a > > > > > big endian structure (like in the prink for instance) they're > > > > > going to keep emailing you about it. > > > > > > > > As mentioned above, using different terminology is meant to cause > > > > more confusion than just difference in endianness which is > > > > manageable inside TEE. > > > > > > > > And I think it's safe to say that the kernel implements UUID in > > > > big endian format and thus uses %pUb whereas OP-TEE implements > > > > UUID in little endian format and thus uses %pUl. > > > > > > So what I think you're saying is that if we still had uuid_be and > > > uuid_le you'd use uuid_le, because that's exactly the structure > > > described in the docs. But because we renamed > > > > > > uuid_be -> uuid_t > > > uuid_le -> guid_t > > > > > > You can't use guid_t as a kernel type because it has the wrong > > > name? > > > > Isn't the rename commit description [1] pretty clear about which is > > the true UUID type from Linux point of view? > > I don't think the kernel code takes a position on eternal verity, just > on logical or arithmetic truth. We just have to deal with both LE and > BE UUIDs so we have appropriate types for them and the LE type is now > named guid_t. They're both equally correct to use provided the use > case matches the designed one. So does the name really matter? Yes it does. I guess I have provided enough reasoning for that. Also, the rename commit itself illustrates its importance and clarifies the use case for which they are meant to be used. > If we > did > > #define uuid_le_t guid_t > > would you be happy? (not that the kernel cares about karmic emotional > states either ...) It's not about me being happy but more about confusion and inconsistency it will bring. IMO, either kernel should be opinionated about UUID endianness like currently it is: uuid_t and its corresponding helpers (eg. UUID_INIT) follows BE format. or support both endianness for UUID (no common type: uuid_t) like we had earlier prior to rename commit: uuid_be_t and its corresponding helpers (eg. UUID_BE_INIT) follow BE format. uuid_le_t and its corresponding helpers (eg. UUID_LE_INIT) follow LE format. But even if we consider later case as well, I am still not sure if we can switch to uuid_le_t as it's been part of TEE core ABI (open_session) where UUID is passed in BE format (see LE to BE conversion in TEE client [1] and vice-versa in OP-TEE OS [2]) and won't be a backwards compatible change. [1] https://github.com/OP-TEE/optee_client/blob/master/libteec/src/tee_client_api.c#L595 [2] https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/kernel/ree_fs_ta.c#L92 -Sumit > > James >
Re: [PATCH 08/12] driver-core: Introduce DEVICE_ATTR_ADMIN_{RO,RW}
On Thu, Jun 25, 2020 at 10:06 PM Greg Kroah-Hartman
wrote:
>
> On Thu, Jun 25, 2020 at 04:51:03PM -0700, Dan Williams wrote:
> > A common pattern for using plain DEVICE_ATTR() instead of
> > DEVICE_ATTR_RO() and DEVICE_ATTR_RW() is for attributes that want to
> > limit read to only root. I.e. many users of DEVICE_ATTR() are
> > specifying 0400 or 0600 for permissions.
> >
> > Given the expectation that CAP_SYS_ADMIN is needed to access these
> > sensitive attributes and an explicit helper with the _ADMIN_ identifier
> > for DEVICE_ATTR_ADMIN_{RO,RW}.
> >
> > Cc: Greg Kroah-Hartman
> > Cc: "Rafael J. Wysocki"
> > Signed-off-by: Dan Williams
> > ---
> > include/linux/device.h |4
> > include/linux/sysfs.h |7 +++
> > 2 files changed, 11 insertions(+)
> >
> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index 15460a5ac024..d7c2570368fa 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -128,8 +128,12 @@ ssize_t device_store_bool(struct device *dev, struct
> > device_attribute *attr,
> > __ATTR_PREALLOC(_name, _mode, _show, _store)
> > #define DEVICE_ATTR_RW(_name) \
> > struct device_attribute dev_attr_##_name = __ATTR_RW(_name)
> > +#define DEVICE_ATTR_ADMIN_RW(_name) \
> > + struct device_attribute dev_attr_##_name = __ATTR_RW_MODE(_name, 0600)
> > #define DEVICE_ATTR_RO(_name) \
> > struct device_attribute dev_attr_##_name = __ATTR_RO(_name)
> > +#define DEVICE_ATTR_ADMIN_RO(_name) \
> > + struct device_attribute dev_attr_##_name = __ATTR_RO_MODE(_name, 0400)
> > #define DEVICE_ATTR_WO(_name) \
> > struct device_attribute dev_attr_##_name = __ATTR_WO(_name)
> > #define DEVICE_ULONG_ATTR(_name, _mode, _var) \
> > diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
> > index 86067dbe7745..34e84122f635 100644
> > --- a/include/linux/sysfs.h
> > +++ b/include/linux/sysfs.h
> > @@ -123,6 +123,13 @@ struct attribute_group {
> > .show = _name##_show, \
> > }
> >
> > +#define __ATTR_RW_MODE(_name, _mode) {
> > \
> > + .attr = { .name = __stringify(_name), \
> > + .mode = VERIFY_OCTAL_PERMISSIONS(_mode) }, \
> > + .show = _name##_show, \
> > + .store = _name##_store,\
> > +}
> > +
> > #define __ATTR_WO(_name) { \
> > .attr = { .name = __stringify(_name), .mode = 0200 }, \
> > .store = _name##_store,\
> >
>
> Nice! Want me to take this now, I know of many other places that could
> be cleaned up to use this (like the raw device bug that I just fixed...)
Sure, that'd be great.
> If not:
>
> Reviewed-by: Greg Kroah-Hartman
Thanks Greg.
Re: [PATCH v6 4/6] mm/swapcache: support to handle the exceptional entries in swapcache
2020년 6월 19일 (금) 오전 10:33, Joonsoo Kim 님이 작성:
>
> On Wed, Jun 17, 2020 at 05:17:17AM -0700, Matthew Wilcox wrote:
> > On Wed, Jun 17, 2020 at 02:26:21PM +0900, js1...@gmail.com wrote:
> > > From: Joonsoo Kim
> > >
> > > Swapcache doesn't handle the exceptional entries since there is no case
> >
> > Don't call them exceptional entries.
> >
> > The radix tree has/had the concecpt of exceptional entries. The swapcache
> > doesn't use the radix tree any more, it uses the XArray. The XArray
> > has value entries.
> >
> > But you shouldn't call them value entries either; that's an XArray
> > concept. The swap cache and indeed page cache use value entries to
> > implement shadow entries (they're also used to implement dax entries and
> > swap entries in the page cache). So just call them shadow entries here.
> >
> > I know there are still places which use the term 'nrexceptional' in
> > the kernel. I just haven't got round to replacing them yet. Please
> > don't add more.
>
> Okay! Thanks for commenting.
>
> >
> > > +void clear_shadow_from_swap_cache(int type, unsigned long begin,
> > > + unsigned long end)
> > > +{
> > > + unsigned long curr;
> > > + void *old;
> > > + swp_entry_t entry = swp_entry(type, begin);
> > > + struct address_space *address_space = swap_address_space(entry);
> > > + XA_STATE(xas, &address_space->i_pages, begin);
> > > +
> > > +retry:
> > > + xa_lock_irq(&address_space->i_pages);
> > > + for (curr = begin; curr <= end; curr++) {
> > > + entry = swp_entry(type, curr);
> > > + if (swap_address_space(entry) != address_space) {
> > > + xa_unlock_irq(&address_space->i_pages);
> > > + address_space = swap_address_space(entry);
> > > + begin = curr;
> > > + xas_set(&xas, begin);
> > > + goto retry;
> > > + }
> > > +
> > > + old = xas_load(&xas);
> > > + if (!xa_is_value(old))
> > > + continue;
> > > + xas_store(&xas, NULL);
> > > + address_space->nrexceptional--;
> > > + xas_next(&xas);
> > > + }
> > > + xa_unlock_irq(&address_space->i_pages);
> > > +}
> >
> > This is a very clunky loop. I'm not sure it's even right, given that
> > you change address space without changing the xas's address space. How
> > about this?
>
> You are correct. The xas's address space should be changed.
>
>
> > for (;;) {
> > XA_STATE(xas, &address_space->i_pages, begin);
> > unsigned long nr_shadows = 0;
> >
> > xas_lock_irq(&xas);
> > xas_for_each(&xas, entry, end) {
> > if (!xa_is_value(entry))
> > continue;
> > xas_store(&xas, NULL);
> > nr_shadows++;
> > }
> > address_space->nr_exceptionals -= nr_shadows;
> > xas_unlock_irq(&xas);
> >
> > if (xas.xa_index >= end)
> > break;
> > entry = swp_entry(type, xas.xa_index);
> > address_space = swap_address_space(entry);
> > }
>
> Thanks for suggestion.
>
> I make a patch based on your suggestion. IIUC about Xarray,
> after running xas_for_each(), xas.xa_index can be less than the end if
> there are empty slots on last portion of array. Handling this case is
> also considered in my patch.
Hello, Matthew.
Could you check if the following patch (Xarray part) is correct?
Since I made a patch based on your suggestion, I'd like to get your review. :)
Thanks.
> Thanks.
>
> --->8
> From 72e97600ea294372a13ab8e208ebd3c0e1889408 Mon Sep 17 00:00:00 2001
> From: Joonsoo Kim
> Date: Fri, 15 Nov 2019 09:48:32 +0900
> Subject: [PATCH v6 4/6] mm/swapcache: support to handle the shadow entries
>
> Workingset detection for anonymous page will be implemented in the
> following patch and it requires to store the shadow entries into the
> swapcache. This patch implements an infrastructure to store the shadow
> entry in the swapcache.
>
> Acked-by: Johannes Weiner
> Signed-off-by: Joonsoo Kim
> ---
> include/linux/swap.h | 17
> mm/shmem.c | 3 ++-
> mm/swap_state.c | 57
> ++--
> mm/swapfile.c| 2 ++
> mm/vmscan.c | 2 +-
> 5 files changed, 69 insertions(+), 12 deletions(-)
>
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index f4f5f94..901da54 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -416,9 +416,13 @@ extern struct address_space *swapper_spaces[];
> extern unsigned long total_swapcache_pages(void);
> extern void show_swap_cache_info(void);
> extern int add_to_swap(struct page *page);
> -extern int add_to_swap_cache(struct page *, swp_entry_t, gfp_t);
> -extern void __delete_from_swap_cache
Re: [PATCH 08/12] driver-core: Introduce DEVICE_ATTR_ADMIN_{RO,RW}
On Thu, Jun 25, 2020 at 04:51:03PM -0700, Dan Williams wrote:
> A common pattern for using plain DEVICE_ATTR() instead of
> DEVICE_ATTR_RO() and DEVICE_ATTR_RW() is for attributes that want to
> limit read to only root. I.e. many users of DEVICE_ATTR() are
> specifying 0400 or 0600 for permissions.
>
> Given the expectation that CAP_SYS_ADMIN is needed to access these
> sensitive attributes and an explicit helper with the _ADMIN_ identifier
> for DEVICE_ATTR_ADMIN_{RO,RW}.
>
> Cc: Greg Kroah-Hartman
> Cc: "Rafael J. Wysocki"
> Signed-off-by: Dan Williams
> ---
> include/linux/device.h |4
> include/linux/sysfs.h |7 +++
> 2 files changed, 11 insertions(+)
>
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 15460a5ac024..d7c2570368fa 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -128,8 +128,12 @@ ssize_t device_store_bool(struct device *dev, struct
> device_attribute *attr,
> __ATTR_PREALLOC(_name, _mode, _show, _store)
> #define DEVICE_ATTR_RW(_name) \
> struct device_attribute dev_attr_##_name = __ATTR_RW(_name)
> +#define DEVICE_ATTR_ADMIN_RW(_name) \
> + struct device_attribute dev_attr_##_name = __ATTR_RW_MODE(_name, 0600)
> #define DEVICE_ATTR_RO(_name) \
> struct device_attribute dev_attr_##_name = __ATTR_RO(_name)
> +#define DEVICE_ATTR_ADMIN_RO(_name) \
> + struct device_attribute dev_attr_##_name = __ATTR_RO_MODE(_name, 0400)
> #define DEVICE_ATTR_WO(_name) \
> struct device_attribute dev_attr_##_name = __ATTR_WO(_name)
> #define DEVICE_ULONG_ATTR(_name, _mode, _var) \
> diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
> index 86067dbe7745..34e84122f635 100644
> --- a/include/linux/sysfs.h
> +++ b/include/linux/sysfs.h
> @@ -123,6 +123,13 @@ struct attribute_group {
> .show = _name##_show, \
> }
>
> +#define __ATTR_RW_MODE(_name, _mode) {
> \
> + .attr = { .name = __stringify(_name), \
> + .mode = VERIFY_OCTAL_PERMISSIONS(_mode) }, \
> + .show = _name##_show, \
> + .store = _name##_store,\
> +}
> +
> #define __ATTR_WO(_name) { \
> .attr = { .name = __stringify(_name), .mode = 0200 }, \
> .store = _name##_store,\
>
Nice! Want me to take this now, I know of many other places that could
be cleaned up to use this (like the raw device bug that I just fixed...)
If not:
Reviewed-by: Greg Kroah-Hartman
Re: [PATCH v3 6/8] mm/gup: use a standard migration target allocation callback
2020년 6월 25일 (목) 오후 9:08, Michal Hocko 님이 작성: > > On Tue 23-06-20 15:13:46, Joonsoo Kim wrote: > > From: Joonsoo Kim > > > > There is a well-defined migration target allocation callback. > > It's mostly similar with new_non_cma_page() except considering CMA pages. > > > > This patch adds a CMA consideration to the standard migration target > > allocation callback and use it on gup.c. > > We already can express that by a missing __GFP_MOVABLE so I would rather > not introduce a duplication in form of another flag. I replied to this question in a previous email. Thanks.
Re: [PATCH v3 5/8] mm/migrate: make a standard migration target allocation function
2020년 6월 25일 (목) 오후 9:05, Michal Hocko 님이 작성:
>
> On Tue 23-06-20 15:13:45, Joonsoo Kim wrote:
> > From: Joonsoo Kim
> >
> > There are some similar functions for migration target allocation. Since
> > there is no fundamental difference, it's better to keep just one rather
> > than keeping all variants. This patch implements base migration target
> > allocation function. In the following patches, variants will be converted
> > to use this function.
> >
> > Note that PageHighmem() call in previous function is changed to open-code
> > "is_highmem_idx()" since it provides more readability.
>
> I was little bit surprised that alloc_migration_target still uses
> private argument while it only accepts migration_target_control
> structure pointer but then I have noticed that you are using it as a
> real callback in a later patch.
>
> > Signed-off-by: Joonsoo Kim
>
> Few questions inline
> [...]
>
> > diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> > index 47b8ccb..820ea5e 100644
> > --- a/mm/memory-failure.c
> > +++ b/mm/memory-failure.c
> > @@ -1648,9 +1648,13 @@ EXPORT_SYMBOL(unpoison_memory);
> >
> > static struct page *new_page(struct page *p, unsigned long private)
> > {
> > - int nid = page_to_nid(p);
> > + struct migration_target_control mtc = {
> > + .nid = page_to_nid(p),
> > + .nmask = &node_states[N_MEMORY],
>
> This could be .namsk = NULL, right? alloc_migration_target doesn't
> modify the node mask and NULL nodemask is always interpreted as all
> available nodes.
Will do.
> > + .gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_RETRY_MAYFAIL,
> > + };
> >
> > - return new_page_nodemask(p, nid, &node_states[N_MEMORY]);
> > + return alloc_migration_target(p, (unsigned long)&mtc);
> > }
> >
> [...]
> > diff --git a/mm/migrate.c b/mm/migrate.c
> > index 634f1ea..3afff59 100644
> > --- a/mm/migrate.c
> > +++ b/mm/migrate.c
> > @@ -1536,29 +1536,34 @@ int migrate_pages(struct list_head *from,
> > new_page_t get_new_page,
> > return rc;
> > }
> >
> > -struct page *new_page_nodemask(struct page *page,
> > - int preferred_nid, nodemask_t *nodemask)
> > +struct page *alloc_migration_target(struct page *page, unsigned long
> > private)
> > {
> > - gfp_t gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_RETRY_MAYFAIL;
> > + struct migration_target_control *mtc;
> > + gfp_t gfp_mask;
> > unsigned int order = 0;
> > struct page *new_page = NULL;
> > + int zidx;
> > +
> > + mtc = (struct migration_target_control *)private;
> > + gfp_mask = mtc->gfp_mask;
> >
> > if (PageHuge(page)) {
> > return alloc_huge_page_nodemask(
> > - page_hstate(compound_head(page)),
> > - preferred_nid, nodemask, 0, false);
> > + page_hstate(compound_head(page)), mtc->nid,
> > + mtc->nmask, gfp_mask, false);
> > }
> >
> > if (PageTransHuge(page)) {
> > + gfp_mask &= ~__GFP_RECLAIM;
>
> What's up with this gfp_mask modification?
THP page allocation uses a standard gfp masks, GFP_TRANSHUGE_LIGHT and
GFP_TRANHUGE. __GFP_RECLAIM flags is a big part of this standard mask design.
So, I clear it here so as not to disrupt the THP gfp mask.
> > gfp_mask |= GFP_TRANSHUGE;
> > order = HPAGE_PMD_ORDER;
> > }
> > -
> > - if (PageHighMem(page) || (zone_idx(page_zone(page)) == ZONE_MOVABLE))
> > + zidx = zone_idx(page_zone(page));
> > + if (is_highmem_idx(zidx) || zidx == ZONE_MOVABLE)
> > gfp_mask |= __GFP_HIGHMEM;
> >
> > new_page = __alloc_pages_nodemask(gfp_mask, order,
> > - preferred_nid, nodemask);
> > + mtc->nid, mtc->nmask);
> >
> > if (new_page && PageTransHuge(new_page))
> > prep_transhuge_page(new_page);
> > diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> > index aec26d9..adba031 100644
> > --- a/mm/page_isolation.c
> > +++ b/mm/page_isolation.c
> > @@ -309,7 +309,11 @@ int test_pages_isolated(unsigned long start_pfn,
> > unsigned long end_pfn,
> >
> > struct page *alloc_migrate_target(struct page *page, unsigned long private)
> > {
> > - int nid = page_to_nid(page);
> > + struct migration_target_control mtc = {
> > + .nid = page_to_nid(page),
> > + .nmask = &node_states[N_MEMORY],
>
> nmask = NULL again
Okay.
Thanks.
Re: [PATCH] mm/spase: never partially remove memmap for early section
> Am 26.06.2020 um 00:40 schrieb Wei Yang : > > On Thu, Jun 25, 2020 at 07:53:37AM +0200, David Hildenbrand wrote: >> >> Am 25.06.2020 um 01:47 schrieb Dan Williams : >>> >>> On Wed, Jun 24, 2020 at 3:44 PM Wei Yang >>> wrote: >>> [..] > So, you are right that there is a mismatch here, but I think the > comprehensive fix is to allow early sections to be partially > depopulated/repopulated rather than have section_activate() and > section_deacticate() special case early sections. The special casing > is problematic in retrospect as section_deactivate() can't be > maintained without understand special rules in section_activate(). Hmm... This means we need to adjust pfn_valid() too, which always return true for early sections. >>> >>> Right, rather than carry workarounds in 3 locations, and the bug that >>> has resulted from then getting out of sync, just teach early section >>> mapping to allow for the subsection populate/depopulate. >>> >> >> I prefer the easy fix first - IOW what we Here here. Especially, >> pfn_to_online_page() will need changes as well. >> > > Hi, David, > > Which part of pfn_to_online_page() needs to be changed? pfn_valid_within() > would call pfn_valid() to check the pfn first. This looks enough for me. Not for all configurations. For some (e.g., x86 iirc) it‘s just a nop.
[PATCH RFC 1/5] dt-bindings: add binding for CDNSP-DRD controller
This patch aim at documenting USB related dt-bindings for the
Cadence CDNSP-DRD controller.
Signed-off-by: Pawel Laszczak
---
.../devicetree/bindings/usb/cdns-cdnsp.yaml | 104 ++
1 file changed, 104 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/cdns-cdnsp.yaml
diff --git a/Documentation/devicetree/bindings/usb/cdns-cdnsp.yaml
b/Documentation/devicetree/bindings/usb/cdns-cdnsp.yaml
new file mode 100644
index ..83d353711e31
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/cdns-cdnsp.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/usb/cdns-cdnsp.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Device tree binding for Cadence CDNSP (Super Speed Plus) controller
+
+maintainers:
+ - Pawel Laszczak
+
+description:
+ The Cadence CDNSP controller support Host, Device and DRD mode.
+ It also supports Full Speed, Hight Speed, Super Speed and
+ Super Speed Plus protocols.
+
+properties:
+ compatible:
+items:
+ - enum:
+- cdns,usbssp
+
+ reg:
+description: Physical base address and size of the
+ controller's register areas. Controller has
+ three different regions.
+minItems: 2
+maxItems: 3
+items:
+ - description: HOST registers area.
+ - description: DEVICE registers area.
+ - description: OTG/DRD registers area.
+
+ reg-names:
+items:
+ - const: xhci
+ - const: dev
+ - const: otg
+
+ interrupts:
+minItems: 2
+maxItems: 3
+items:
+ - description: Interrupt used by XHCI driver.
+ - description: Interrupt used by device driver.
+ - description: Interrupt used by DRD part of driver.
+
+ interrupt-names:
+items:
+ - const: host
+ - const: peripheral
+ - const: otg
+
+ maximum-speed:
+enum:
+ - full-speed
+ - high-speed
+ - super-speed
+ - super-speed-plus
+
+ dr_mode:
+enum:
+ - host
+ - peripheral
+ - otg
+
+ phys:
+description:
+ Reference to the USB PHY.
+ Must contain an entry for each entry in phy-names.
+ See ../phy/phy-bindings.txt for details.
+
+ phy-names:
+items:
+ - const: cdnsp,usb2-phy
+ - const: cdnsp,usb3-phy
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - interrupt-names
+
+examples:
+ - |
+#include
+
+usb_otg: usb@f300 {
+ compatible = "cdns,usbssp";
+ reg = <0x00 0x01c13000 0x00 0x0400>,
+<0x00 0xf301 0x00 0x1>,
+<0x00 0xf302 0x00 0x1>;
+ reg-names = "xhci", "dev", "otg";
+ interrupts = ,
+ ,
+ ;
+ interrupt-names = "host", "peripheral", "otg";
+ phys = <&usbphy 0>;
+ phy-names = "cdnsp,usb2-phy", "cdnsp,usb3-phy";
+ dr_mode = "peripheral";
+};
+
+...
--
2.17.1
[PATCH RFC 3/5] usb: cdnsp: Device side header file for CDNSP driver
Patch defines macros, registers and structures used by
Device side driver.
Because the size of main patch is very big, I’ve decided to create
separate patch for gadget.h. It should simplify reviewing the code.
Signed-off-by: Pawel Laszczak
---
drivers/usb/cdnsp/gadget.h | 1446
1 file changed, 1446 insertions(+)
create mode 100644 drivers/usb/cdnsp/gadget.h
diff --git a/drivers/usb/cdnsp/gadget.h b/drivers/usb/cdnsp/gadget.h
new file mode 100644
index ..edc37763a3b7
--- /dev/null
+++ b/drivers/usb/cdnsp/gadget.h
@@ -0,0 +1,1446 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Cadence CDNSP DRD Driver.
+ *
+ * Copyright (C) 2020 Cadence.
+ *
+ * Author: Pawel Laszczak
+ *
+ * Code based on Linux XHCI driver.
+ * Origin: Copyright (C) 2008 Intel Corp.
+ */
+#ifndef __LINUX_CDNSP_GADGET_H
+#define __LINUX_CDNSP_GADGET_H
+
+#include
+#include
+#include
+
+/* Max number slots - only 1 is allowed. */
+#define CDNSP_DEV_MAX_SLOTS1
+
+#define CDNSP_EP0_SETUP_SIZE 512
+
+/*16 for in and 16 for out. */
+#define CDNSP_ENDPOINTS_NUM32
+
+/* Best Effort Service Latency. */
+#define CDNSP_DEFAULT_BESL 0
+
+/* Device Controller command default timeout value in us */
+#define CDNSP_CMD_TIMEOUT (15 * 1000)
+
+/* Up to 16 ms to halt an device controller */
+#define CDNSP_MAX_HALT_USEC(16 * 1000)
+
+/*
+ * Controller register interface.
+ */
+
+/**
+ * struct cdnsp_cap_regs - CDNSP Registers.
+ * @hc_capbase:Length of the capabilities register and controller
+ * version number
+ * @hcs_params1: HCSPARAMS1 - Structural Parameters 1
+ * @hcs_params2: HCSPARAMS2 - Structural Parameters 2
+ * @hcs_params3: HCSPARAMS3 - Structural Parameters 3
+ * @hcc_params: HCCPARAMS - Capability Parameters
+ * @db_off: DBOFF - Doorbell array offset
+ * @run_regs_off: RTSOFF - Runtime register space offset
+ * @hcc_params2: HCCPARAMS2 Capability Parameters 2,
+ */
+struct cdnsp_cap_regs {
+ __le32 hc_capbase;
+ __le32 hcs_params1;
+ __le32 hcs_params2;
+ __le32 hcs_params3;
+ __le32 hcc_params;
+ __le32 db_off;
+ __le32 run_regs_off;
+ __le32 hcc_params2;
+ /* Reserved up to (CAPLENGTH - 0x1C) */
+};
+
+/* hc_capbase bitmasks. */
+/* bits 7:0 - how long is the Capabilities register. */
+#define HC_LENGTH(p) (((p) >> 00) & GENMASK(7, 0))
+/* bits 31:16 */
+#define HC_VERSION(p) (((p) >> 16) & GENMASK(15, 1))
+
+/* HCSPARAMS1 - hcs_params1 - bitmasks */
+/* bits 0:7, Max Device Endpoints */
+#define HCS_ENDPOINTS_MASK GENMASK(7, 0)
+#define HCS_ENDPOINTS(p) (((p) & HCS_ENDPOINTS_MASK) >> 0)
+
+/* HCCPARAMS offset from PCI base address */
+#define HCC_PARAMS_OFFSET 0x10
+
+/* HCCPARAMS - hcc_params - bitmasks */
+/* true: device controller can use 64-bit address pointers. */
+#define HCC_64BIT_ADDR(p) ((p) & BIT(0))
+/* true: device controller uses 64-byte Device Context structures. */
+#define HCC_64BYTE_CONTEXT(p) ((p) & BIT(2))
+/* Max size for Primary Stream Arrays - 2^(n+1), where n is bits 12:15. */
+#define HCC_MAX_PSA(p) p) >> 12) & 0xf) + 1)
+/* Extended Capabilities pointer from PCI base. */
+#define HCC_EXT_CAPS(p)(((p) & GENMASK(31, 16)) >> 16)
+
+#define CTX_SIZE(_hcc) (HCC_64BYTE_CONTEXT(_hcc) ? 64 : 32)
+
+/* db_off bitmask - bits 0:1 reserved. */
+#define DBOFF_MASK GENMASK(31, 2)
+
+/* run_regs_off bitmask - bits 0:4 reserved. */
+#define RTSOFF_MASKGENMASK(31, 5)
+
+/**
+ * struct cdnsp_op_regs - Device Controller Operational Registers.
+ * @command: USBCMD - Controller command register.
+ * @status: USBSTS - Controller status register.
+ * @page_size: This indicates the page size that the device controller
supports.
+ * If bit n is set, the controller supports a page size of
2^(n+12),
+ * up to a 128MB page size. 4K is the minimum page size.
+ * @dnctrl: DNCTRL - Device notification control register.
+ * @cmd_ring: CRP - 64-bit Command Ring Pointer.
+ * @dcbaa_ptr: DCBAAP - 64-bit Device Context Base Address Array Pointer.
+ * @config_reg:CONFIG - Configure Register
+ * @port_reg_base: PORTSCn - base address for Port Status and Control
+ * Each port has a Port Status and Control register,
+ * followed by a Port Power Management Status and Control
+ * register, a Port Link Info register, and a reserved
+ * register.
+ */
+struct cdnsp_op_regs {
+ __le32 command;
+ __le32 status;
+ __le32 page_size;
+ __le32 reserved1;
+ __le32 reserved2;
+ __le32 dnctrl;
+ __le64 cmd_ring;
+ /* rsvd: offset 0x20-2F. */
+ __le32 reserved3[4];
+ __le64 dcbaa_ptr;
+ __le32 config_reg;
+ /* rsvd: offset 0x3C-3FF. */
+ __le32 reserved4[241];
+ /* port 1 registers, which serve as a base address for other ports. */
+ __le32 port
[PATCH RFC 2/5] usb:cdns3: Add pci to platform driver wrapper
Patch adds PCI specific glue driver that creates and registers in-system
cdns-usbssp platform device. Thanks to that we will be able to use
the cdns-usbssp platform driver for USBSS-DEV controller
build on PCI board.
Signed-off-by: Pawel Laszczak
---
drivers/usb/Kconfig | 1 +
drivers/usb/Makefile | 1 +
drivers/usb/cdnsp/Kconfig | 26 +
drivers/usb/cdnsp/Makefile| 3 +
drivers/usb/cdnsp/cdnsp-pci.c | 214 ++
5 files changed, 245 insertions(+)
create mode 100644 drivers/usb/cdnsp/Kconfig
create mode 100644 drivers/usb/cdnsp/Makefile
create mode 100644 drivers/usb/cdnsp/cdnsp-pci.c
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 26475b409b53..555c4a4cb465 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -112,6 +112,7 @@ source "drivers/usb/usbip/Kconfig"
endif
source "drivers/usb/cdns3/Kconfig"
+source "drivers/usb/cdnsp/Kconfig"
source "drivers/usb/mtu3/Kconfig"
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 1c1c1d659394..84727f7a4b92 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_USB_DWC2)+= dwc2/
obj-$(CONFIG_USB_ISP1760) += isp1760/
obj-$(CONFIG_USB_CDNS3)+= cdns3/
+obj-$(CONFIG_USB_CDNSP)+= cdnsp/
obj-$(CONFIG_USB_MON) += mon/
obj-$(CONFIG_USB_MTU3) += mtu3/
diff --git a/drivers/usb/cdnsp/Kconfig b/drivers/usb/cdnsp/Kconfig
new file mode 100644
index ..5796a19bb8a0
--- /dev/null
+++ b/drivers/usb/cdnsp/Kconfig
@@ -0,0 +1,26 @@
+config USB_CDNSP
+ tristate "Cadence CDNSP Dual-Role Controller"
+ depends on USB_SUPPORT && (USB || USB_GADGET) && HAS_DMA
+ select USB_XHCI_PLATFORM if USB_XHCI_HCD
+ select USB_ROLE_SWITCH
+ help
+ Say Y here if your system has a Cadence CDNSP dual-role controller.
+ It supports: dual-role switch Host-only, and Peripheral-only.
+
+ If you choose to build this driver is a dynamically linked
+ module, the module will be called cdnsp.ko.
+
+if USB_CDNSP
+
+config USB_CDNSP_PCI
+ tristate "Cadence CDNSP support on PCIe-based platforms"
+ depends on USB_PCI && ACPI
+ default USB_CDNSP
+ help
+ If you're using the CDNSP Core IP with a PCIe, please say
+ 'Y' or 'M' here.
+
+ If you choose to build this driver as module it will
+ be dynamically linked and module will be called cdnsp-pci.ko
+
+endif
diff --git a/drivers/usb/cdnsp/Makefile b/drivers/usb/cdnsp/Makefile
new file mode 100644
index ..21adf3eb2f7d
--- /dev/null
+++ b/drivers/usb/cdnsp/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_USB_CDNSP_PCI)+= cdnsp-pci.o
diff --git a/drivers/usb/cdnsp/cdnsp-pci.c b/drivers/usb/cdnsp/cdnsp-pci.c
new file mode 100644
index ..7e05d584d57c
--- /dev/null
+++ b/drivers/usb/cdnsp/cdnsp-pci.c
@@ -0,0 +1,214 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Cadence PCI Glue driver.
+ *
+ * Copyright (C) 2019 Cadence.
+ *
+ * Author: Pawel Laszczak
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct cdnsp_wrap {
+ struct platform_device *plat_dev;
+ struct resource dev_res[6];
+ int devfn;
+};
+
+#define RES_IRQ_HOST_ID0
+#define RES_IRQ_PERIPHERAL_ID 1
+#define RES_IRQ_OTG_ID 2
+#define RES_HOST_ID3
+#define RES_DEV_ID 4
+#define RES_DRD_ID 5
+
+#define PCI_BAR_HOST 0
+#define PCI_BAR_OTG0
+#define PCI_BAR_DEV2
+
+#define PCI_DEV_FN_HOST_DEVICE 0
+#define PCI_DEV_FN_OTG 1
+
+#define PCI_DRIVER_NAME"cdns-pci-usbssp"
+#define PLAT_DRIVER_NAME "cdns-usbssp"
+
+#define CDNS_VENDOR_ID 0x17cd
+#define CDNS_DEVICE_ID 0x0100
+#define CDNS_DRD_IF(PCI_CLASS_SERIAL_USB << 8 | 0x80)
+
+static struct pci_dev *cdnsp_get_second_fun(struct pci_dev *pdev)
+{
+ struct pci_dev *func;
+
+ /*
+* Gets the second function.
+* It's little tricky, but this platform has two function.
+* The fist keeps resources for Host/Device while the second
+* keeps resources for DRD/OTG.
+*/
+ func = pci_get_device(pdev->vendor, pdev->device, NULL);
+ if (unlikely(!func))
+ return NULL;
+
+ if (func->devfn == pdev->devfn) {
+ func = pci_get_device(pdev->vendor, pdev->device, func);
+ if (unlikely(!func))
+ return NULL;
+ }
+
+ return func;
+}
+
+static int cdnsp_pci_probe(struct pci_dev *pdev,
+ const struct pci_device_id *id)
+{
+ struct platform_device_info plat_info;
+ struct cdnsp_wrap *wrap;
+ struct resource *res;
+ struct pci_dev *func;
+ int err;
+
+ /*
+* For GADGET/HOST PC
[PATCH RFC 5/5] usb: cdnsp: Add tracepoints for CDNSP driver
Patch adds the series of tracepoints that can be used for
debugging issues detected in driver.
Signed-off-by: Pawel Laszczak
---
drivers/usb/cdnsp/Makefile | 5 +
drivers/usb/cdnsp/debug.h | 583 ++
drivers/usb/cdnsp/ep0.c| 24 +-
drivers/usb/cdnsp/gadget.c | 61 ++-
drivers/usb/cdnsp/gadget.h | 2 +
drivers/usb/cdnsp/mem.c| 15 +-
drivers/usb/cdnsp/ring.c | 75 +++-
drivers/usb/cdnsp/trace.c | 12 +
drivers/usb/cdnsp/trace.h | 839 +
9 files changed, 1604 insertions(+), 12 deletions(-)
create mode 100644 drivers/usb/cdnsp/debug.h
create mode 100644 drivers/usb/cdnsp/trace.c
create mode 100644 drivers/usb/cdnsp/trace.h
diff --git a/drivers/usb/cdnsp/Makefile b/drivers/usb/cdnsp/Makefile
index 386b6a7b8b4e..067005c5ac32 100644
--- a/drivers/usb/cdnsp/Makefile
+++ b/drivers/usb/cdnsp/Makefile
@@ -1,9 +1,14 @@
# SPDX-License-Identifier: GPL-2.0
+# define_trace.h needs to know how to find our header
+CFLAGS_trace.o := -I$(src)
cdnsp-y:= core.o drd.o
obj-$(CONFIG_USB_CDNSP)+= cdnsp.o
cdnsp-$(CONFIG_USB_CDNSP_GADGET) += ring.o gadget.o mem.o ep0.o
+ifneq ($(CONFIG_USB_CDNSP_GADGET),)
+cdnsp-$(CONFIG_TRACING)+= trace.o
+endif
cdnsp-$(CONFIG_USB_CDNSP_HOST) += host.o
diff --git a/drivers/usb/cdnsp/debug.h b/drivers/usb/cdnsp/debug.h
new file mode 100644
index ..d6345d4d2911
--- /dev/null
+++ b/drivers/usb/cdnsp/debug.h
@@ -0,0 +1,583 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Cadence CDNSP DRD Driver.
+ *
+ * Copyright (C) 2020 Cadence.
+ *
+ * Author: Pawel Laszczak
+ *
+ */
+#ifndef __LINUX_CDNSP_DEBUG
+#define __LINUX_CDNSP_DEBUG
+
+static inline const char *cdnsp_trb_comp_code_string(u8 status)
+{
+ switch (status) {
+ case COMP_INVALID:
+ return "Invalid";
+ case COMP_SUCCESS:
+ return "Success";
+ case COMP_DATA_BUFFER_ERROR:
+ return "Data Buffer Error";
+ case COMP_BABBLE_DETECTED_ERROR:
+ return "Babble Detected";
+ case COMP_TRB_ERROR:
+ return "TRB Error";
+ case COMP_RESOURCE_ERROR:
+ return "Resource Error";
+ case COMP_NO_SLOTS_AVAILABLE_ERROR:
+ return "No Slots Available Error";
+ case COMP_INVALID_STREAM_TYPE_ERROR:
+ return "Invalid Stream Type Error";
+ case COMP_SLOT_NOT_ENABLED_ERROR:
+ return "Slot Not Enabled Error";
+ case COMP_ENDPOINT_NOT_ENABLED_ERROR:
+ return "Endpoint Not Enabled Error";
+ case COMP_SHORT_PACKET:
+ return "Short Packet";
+ case COMP_RING_UNDERRUN:
+ return "Ring Underrun";
+ case COMP_RING_OVERRUN:
+ return "Ring Overrun";
+ case COMP_VF_EVENT_RING_FULL_ERROR:
+ return "VF Event Ring Full Error";
+ case COMP_PARAMETER_ERROR:
+ return "Parameter Error";
+ case COMP_CONTEXT_STATE_ERROR:
+ return "Context State Error";
+ case COMP_EVENT_RING_FULL_ERROR:
+ return "Event Ring Full Error";
+ case COMP_INCOMPATIBLE_DEVICE_ERROR:
+ return "Incompatible Device Error";
+ case COMP_MISSED_SERVICE_ERROR:
+ return "Missed Service Error";
+ case COMP_COMMAND_RING_STOPPED:
+ return "Command Ring Stopped";
+ case COMP_COMMAND_ABORTED:
+ return "Command Aborted";
+ case COMP_STOPPED:
+ return "Stopped";
+ case COMP_STOPPED_LENGTH_INVALID:
+ return "Stopped - Length Invalid";
+ case COMP_STOPPED_SHORT_PACKET:
+ return "Stopped - Short Packet";
+ case COMP_MAX_EXIT_LATENCY_TOO_LARGE_ERROR:
+ return "Max Exit Latency Too Large Error";
+ case COMP_ISOCH_BUFFER_OVERRUN:
+ return "Isoch Buffer Overrun";
+ case COMP_EVENT_LOST_ERROR:
+ return "Event Lost Error";
+ case COMP_UNDEFINED_ERROR:
+ return "Undefined Error";
+ case COMP_INVALID_STREAM_ID_ERROR:
+ return "Invalid Stream ID Error";
+ default:
+ return "Unknown!!";
+ }
+}
+
+static inline const char *cdnsp_trb_type_string(u8 type)
+{
+ switch (type) {
+ case TRB_NORMAL:
+ return "Normal";
+ case TRB_SETUP:
+ return "Setup Stage";
+ case TRB_DATA:
+ return "Data Stage";
+ case TRB_STATUS:
+ return "Status Stage";
+ case TRB_ISOC:
+ return "Isoch";
+ case TRB_LINK:
+ return "Link";
+ case TRB_EVENT_DATA:
+ return "Event Data";
+ case TRB_TR_NOOP:
+ return "No-Op";
+ case TRB_ENABLE_SLOT:
+ return "Enable Slot Command
[PATCH RFC 0/5] Introduced new Cadence USBSSP DRD Driver.
This patch introduce new Cadence USBSS DRD driver to linux kernel. The Cadence USBSS DRD Controller is a highly configurable IP Core which can be instantiated as Dual-Role Device (DRD), Peripheral Only and Host Only (XHCI)configurations. The current driver has been validated with FPGA burned. We have support for PCIe bus, which is used on FPGA prototyping. The host side of USBSS-DRD controller is compliance with XHCI specification, so it works with standard XHCI Linux driver. The host side of USBSS DRD controller is compliant with XHCI. The architecture for device side is almost the same as for host side, and most of the XHCI specification can be used to understand how this controller operates. This controller and driver support Full Speed, Hight Speed, Supper Speed and Supper Speed Plus USB protocol. The prefix cdnsp used in driver has chosen by analogy to cdn3 driver. The last letter of this acronym means PLUS. The formal name of controller is USBSSP but it's to generic so I've decided to use CDNSP. The patch 1: adds DT binding. The patch 2: adds PCI to platform wrapper used on Cadnece testing platform. It is FPGA based on platform. The patches 3-5: add the main part of driver and has been intentionally split into 3 part. In my opinion such division should not affect understanding and reviewing the driver, and cause that main patch (4/5) is little smaller. Patch 3 introduces main header file for driver, 4 is the main part that implements all functionality of driver and 5 introduces tracepoints. --- Pawel Laszczak (5): dt-bindings: add binding for CDNSP-DRD controller usb:cdns3: Add pci to platform driver wrapper usb: cdnsp: Device side header file for CDNSP driver usb: cdnsp: usb:cdns3 Add main part of Cadence USBSSP DRD Driver usb: cdnsp: Add tracepoints for CDNSP driver .../devicetree/bindings/usb/cdns-cdnsp.yaml | 104 + drivers/usb/Kconfig |1 + drivers/usb/Makefile |1 + drivers/usb/cdnsp/Kconfig | 49 + drivers/usb/cdnsp/Makefile| 15 + drivers/usb/cdnsp/cdnsp-pci.c | 214 ++ drivers/usb/cdnsp/core.c | 632 + drivers/usb/cdnsp/core.h | 90 + drivers/usb/cdnsp/debug.h | 583 drivers/usb/cdnsp/drd.c | 372 +++ drivers/usb/cdnsp/drd.h | 127 + drivers/usb/cdnsp/ep0.c | 482 drivers/usb/cdnsp/export.h| 36 + drivers/usb/cdnsp/gadget.c| 1990 ++ drivers/usb/cdnsp/gadget.h| 1586 +++ drivers/usb/cdnsp/host.c | 74 + drivers/usb/cdnsp/mem.c | 1340 + drivers/usb/cdnsp/ring.c | 2443 + drivers/usb/cdnsp/trace.c | 12 + drivers/usb/cdnsp/trace.h | 839 ++ 20 files changed, 10990 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/cdns-cdnsp.yaml create mode 100644 drivers/usb/cdnsp/Kconfig create mode 100644 drivers/usb/cdnsp/Makefile create mode 100644 drivers/usb/cdnsp/cdnsp-pci.c create mode 100644 drivers/usb/cdnsp/core.c create mode 100644 drivers/usb/cdnsp/core.h create mode 100644 drivers/usb/cdnsp/debug.h create mode 100644 drivers/usb/cdnsp/drd.c create mode 100644 drivers/usb/cdnsp/drd.h create mode 100644 drivers/usb/cdnsp/ep0.c create mode 100644 drivers/usb/cdnsp/export.h create mode 100644 drivers/usb/cdnsp/gadget.c create mode 100644 drivers/usb/cdnsp/gadget.h create mode 100644 drivers/usb/cdnsp/host.c create mode 100644 drivers/usb/cdnsp/mem.c create mode 100644 drivers/usb/cdnsp/ring.c create mode 100644 drivers/usb/cdnsp/trace.c create mode 100644 drivers/usb/cdnsp/trace.h -- 2.17.1
Re: [PATCH 06/10] media: mtk-vcodec: venc: specify supported formats per-chip
Hi Tiffany, On Tue, Jun 23, 2020 at 10:29 AM Tiffany Lin wrote: > > On Mon, 2020-06-22 at 21:44 +0900, Alexandre Courbot wrote: > > On Fri, Jun 19, 2020 at 4:26 PM Tiffany Lin > > wrote: > > > > > > On Wed, 2020-05-20 at 17:27 +0900, Alexandre Courbot wrote: > > > > Different chips have different supported bitrate ranges. Move the list > > > > of supported formats to the platform data, and split the output and > > > > capture formats into two lists to make it easier to find the default > > > > format for each queue. > > > > > > > > > > Does this patch pass v4l2 compliance test? > > > > This should not change the behavior towards userspace at all (it's > > just moving data around and making it more flexible), so the test > > results should not be affected either. > > > I remember that passing compliance tests is required for upstream. > The tests try to make sure that all V4L2 driver implement interfaces in > the same way. > So user space applications could find/enumerate HW capability. I have confirmed that this CL does not introduce any regression with v4l2-compliance.
Re: [PATCH v3 4/8] mm/hugetlb: make hugetlb migration callback CMA aware
2020년 6월 25일 (목) 오후 8:54, Michal Hocko 님이 작성: > > On Tue 23-06-20 15:13:44, Joonsoo Kim wrote: > > From: Joonsoo Kim > > > > new_non_cma_page() in gup.c which try to allocate migration target page > > requires to allocate the new page that is not on the CMA area. > > new_non_cma_page() implements it by removing __GFP_MOVABLE flag. This way > > works well for THP page or normal page but not for hugetlb page. > > Could you explain why? I mean why cannot you simply remove __GFP_MOVABLE > flag when calling alloc_huge_page_nodemask and check for it in dequeue > path? If we remove __GFP_MOVABLE when calling alloc_huge_page_nodemask, we cannot use the page in ZONE_MOVABLE on dequeing. __GFP_MOVABLE is not only used for CMA selector but also used for zone selector. If we clear it, we cannot use the page in the ZONE_MOVABLE even if it's not CMA pages. For THP page or normal page allocation, there is no way to avoid this weakness without introducing another flag or argument. For me, introducing another flag or argument for these functions looks over-engineering so I don't change them and leave them as they are (removing __GFP_MOVABLE). But, for alloc_huge_page_nodemask(), introducing a new argument doesn't seem to be a problem since it is not a general function but just a migration target allocation function. If you agree with this argument, I will add more description to the patch. Thanks.
Re: [PATCH] powerpc/fixmap: Fix FIX_EARLY_DEBUG_BASE when page size is 256k
On Mon, 15 Jun 2020 07:48:25 + (UTC), Christophe Leroy wrote: > FIX_EARLY_DEBUG_BASE reserves a 128k area for debuging. > > When page size is 256k, the calculation results in a 0 number of > pages, leading to the following failure: > > CC arch/powerpc/kernel/asm-offsets.s > In file included from ./arch/powerpc/include/asm/nohash/32/pgtable.h:77:0, > from ./arch/powerpc/include/asm/nohash/pgtable.h:8, > from ./arch/powerpc/include/asm/pgtable.h:20, > from ./include/linux/pgtable.h:6, > from ./arch/powerpc/include/asm/kup.h:42, > from ./arch/powerpc/include/asm/uaccess.h:9, > from ./include/linux/uaccess.h:11, > from ./include/linux/crypto.h:21, > from ./include/crypto/hash.h:11, > from ./include/linux/uio.h:10, > from ./include/linux/socket.h:8, > from ./include/linux/compat.h:15, > from arch/powerpc/kernel/asm-offsets.c:14: > ./arch/powerpc/include/asm/fixmap.h:75:2: error: overflow in enumeration > values > __end_of_permanent_fixed_addresses, > ^ > make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1 > > [...] Applied to powerpc/next. [1/1] powerpc/fixmap: Fix FIX_EARLY_DEBUG_BASE when page size is 256k https://git.kernel.org/powerpc/c/03fd42d458fb9cb69e712600bd69ff77ff3a45a8 cheers
Re: [PATCH v3 0/2] powerpc: CMDLINE config cleanup
On Fri, 12 Jun 2020 10:42:18 +1200, Chris Packham wrote: > This series cleans up the config options related to the boot command line. > > Chris Packham (2): > powerpc: Remove inaccessible CMDLINE default > powerpc: configs: remove CMDLINE_BOOL > > arch/powerpc/Kconfig | 6 +- > arch/powerpc/configs/44x/akebono_defconfig | 2 -- > arch/powerpc/configs/44x/arches_defconfig | 2 -- > arch/powerpc/configs/44x/bamboo_defconfig | 2 -- > arch/powerpc/configs/44x/bluestone_defconfig | 2 -- > arch/powerpc/configs/44x/canyonlands_defconfig | 2 -- > arch/powerpc/configs/44x/currituck_defconfig | 2 -- > arch/powerpc/configs/44x/eiger_defconfig | 2 -- > arch/powerpc/configs/44x/fsp2_defconfig| 1 - > arch/powerpc/configs/44x/icon_defconfig| 2 -- > arch/powerpc/configs/44x/iss476-smp_defconfig | 1 - > arch/powerpc/configs/44x/katmai_defconfig | 2 -- > arch/powerpc/configs/44x/rainier_defconfig | 2 -- > arch/powerpc/configs/44x/redwood_defconfig | 2 -- > arch/powerpc/configs/44x/sam440ep_defconfig| 2 -- > arch/powerpc/configs/44x/sequoia_defconfig | 2 -- > arch/powerpc/configs/44x/taishan_defconfig | 2 -- > arch/powerpc/configs/44x/warp_defconfig| 1 - > arch/powerpc/configs/holly_defconfig | 1 - > arch/powerpc/configs/mvme5100_defconfig| 3 +-- > arch/powerpc/configs/ps3_defconfig | 2 -- > arch/powerpc/configs/skiroot_defconfig | 1 - > arch/powerpc/configs/storcenter_defconfig | 1 - > 23 files changed, 2 insertions(+), 43 deletions(-) Applied to powerpc/next. [1/2] powerpc: Remove inaccessible CMDLINE default https://git.kernel.org/powerpc/c/f134a7cef1d7de45fab028a945b7f34c615718e1 [2/2] powerpc/configs: Remove CMDLINE_BOOL https://git.kernel.org/powerpc/c/0488d32530ecff973c40f2592a6eab2907d0a5cc cheers
Re: [PATCH 2/2] pci: Add parameter to disable attaching untrusted devices
On Thu, Jun 25, 2020 at 05:27:10PM -0700, Rajat Jain wrote: > Introduce a PCI parameter that disables the automatic attachment of > untrusted devices to their drivers. You didn't document this new api anywhere :(
Re: [PATCH] powerpc/8xx: Modify ptep_get()
On Thu, 18 Jun 2020 12:07:46 + (UTC), Christophe Leroy wrote: > Move ptep_get() close to pte_update(), in an ifdef section already > dedicated to powerpc 8xx. This section contains explanation about > the layout of page table entries. > > Also modify it to return 4 times the pte value instead of padding > with zeroes. Applied to powerpc/next. [1/1] powerpc/8xx: Modify ptep_get() https://git.kernel.org/powerpc/c/105fb38124a490f38e9c1e23bb4c4a0b6ba12fdb cheers
Re: [PATCH 0/3] powerpc/dt_cpu_ftrs: Make use of ISA_V3_* macros
On Wed, 10 Jun 2020 18:51:11 -0300, Murilo Opsfelder Araujo wrote: > The first patch removes unused macro ISA_V2_07B. The second and third > patches make use of macros ISA_V3_0B and ISA_V3_1, respectively, > instead their corresponding literals. > > Murilo Opsfelder Araujo (3): > powerpc/dt_cpu_ftrs: Remove unused macro ISA_V2_07B > powerpc/dt_cpu_ftrs: Make use of macro ISA_V3_0B > powerpc/dt_cpu_ftrs: Make use of macro ISA_V3_1 > > [...] Applied to powerpc/next. [1/3] powerpc/dt_cpu_ftrs: Remove unused macro ISA_V2_07B https://git.kernel.org/powerpc/c/f39eb5d8ac707fd59029a06c3f985f29b1aaa26b [2/3] powerpc/dt_cpu_ftrs: Make use of macro ISA_V3_0B https://git.kernel.org/powerpc/c/e781f12a60a7bddb50909d42478cca8724c8b113 [3/3] powerpc/dt_cpu_ftrs: Make use of macro ISA_V3_1 https://git.kernel.org/powerpc/c/7714394706c0309b3f3fc474b390463d60eb6cb1 cheers
Re: [PATCH 1/3] crypto: pass the flag CRYPTO_ALG_ALLOCATES_MEMORY
On Wed, Jun 17, 2020 at 11:09:28AM -0400, Mikulas Patocka wrote: > > Index: linux-2.6/include/linux/crypto.h > === > --- linux-2.6.orig/include/linux/crypto.h > +++ linux-2.6/include/linux/crypto.h > @@ -97,9 +97,18 @@ > #define CRYPTO_ALG_OPTIONAL_KEY 0x4000 > > /* > + * The driver may allocate memory during request processing, so it shouldn't > be > + * used in cases where memory allocation failures aren't acceptable, such as > + * during block device encryption. > + */ > +#define CRYPTO_ALG_ALLOCATES_MEMORY 0x8000 > + > +/* > * Don't trigger module loading > */ > -#define CRYPTO_NOLOAD0x8000 > +#define CRYPTO_NOLOAD0x0001 > + > +#define CRYPTO_ALG_INHERITED_FLAGS (CRYPTO_ALG_ASYNC | > CRYPTO_ALG_ALLOCATES_MEMORY) Any reason why you need to renumber NOLOAD? If not please keep the existing values. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH V2] powerpc/pseries/svm: Drop unused align argument in alloc_shared_lppaca() function
On Fri, 12 Jun 2020 19:59:53 +0530, Satheesh Rajendran wrote: > Argument "align" in alloc_shared_lppaca() was unused inside the > function. Let's drop it and update code comment for page alignment. Applied to powerpc/next. [1/1] powerpc/pseries/svm: Drop unused align argument in alloc_shared_lppaca() function https://git.kernel.org/powerpc/c/178748b6d14946f080d49bc7dcc47b7cc4437e4d cheers
Re: [PATCH] powerpc/mm: Fix typo in IS_ENABLED()
On Fri, 5 Jun 2020 07:18:06 -0700, Kees Cook wrote: > IS_ENABLED() matches names exactly, so the missing "CONFIG_" prefix > means this code would never be built. > > Also fixes a missing newline in pr_warn(). Applied to powerpc/next. [1/1] powerpc/mm: Fix typo in IS_ENABLED() https://git.kernel.org/powerpc/c/55bd9ac468397c4f12a33b7ec714b5d0362c3aa2 cheers
Re: [PATCH] powerpc/ptdump: Fix build failure in hashpagetable.c
On Mon, 15 Jun 2020 13:18:39 + (UTC), Christophe Leroy wrote: > H_SUCCESS is only defined when CONFIG_PPC_PSERIES is defined. > > != H_SUCCESS means != 0. Modify the test accordingly. Applied to powerpc/next. [1/1] powerpc/ptdump: Fix build failure in hashpagetable.c https://git.kernel.org/powerpc/c/7c466b0807960edc13e4b855be85ea765df9a6cd cheers
Re: [PATCH] arch: powerpc: ppc4xx compile flag optimizations
On Thu, 22 Dec 2016 09:06:08 +0100, John Crispin wrote: > This patch splits up the compile flags between ppc40x and ppc44x. Applied to powerpc/next. [1/1] powerpc/4xx: ppc4xx compile flag optimizations https://git.kernel.org/powerpc/c/548ad77d10f7ad6e5f84a0026978da2ed1df0dae cheers
Re: [PATCH] powerpc/fsl_booke/32: fix build with CONFIG_RANDOMIZE_BASE
On Sat, 13 Jun 2020 23:28:01 +0700, Arseny Solokha wrote: > Building the current 5.8 kernel for a e500 machine with > CONFIG_RANDOMIZE_BASE set yields the following failure: > > arch/powerpc/mm/nohash/kaslr_booke.c: In function 'kaslr_early_init': > arch/powerpc/mm/nohash/kaslr_booke.c:387:2: error: implicit declaration > of function 'flush_icache_range'; did you mean 'flush_tlb_range'? > [-Werror=implicit-function-declaration] > > [...] Applied to powerpc/fixes. [1/1] powerpc/fsl_booke/32: Fix build with CONFIG_RANDOMIZE_BASE https://git.kernel.org/powerpc/c/7e4773f73dcfb92e7e33532162f722ec291e75a4 cheers
Re: [fedora-arm] Banana Pi-R1 - kernel 5.6.0 and later broken - b43 DSA
On 6/25/2020 4:23 PM, Peter Robinson wrote: >> I'm having troubles with the Banana Pi-R1 router with newer kernels. No >> config changes, config works well since a lot of lernel updates ... >> Banana Pi-R1 is configured via systemd-networkd and uses the DSA >> (Distributed Switch Architecture) with b53 switch. No visible difference >> in interfaces, vlan config, bridge config, etc. Looks like actual >> configuration in the switch in the hardware is broken. >> >> # OK: Last good known version (booting that version is also ok) >> Linux bpi 5.5.18-200.fc31.armv7hl #1 SMP Fri Apr 17 17:25:00 UTC 2020 >> armv7l armv7l armv7l GNU/Linux >> >> # NOK: no network >> Linux bpi 5.6.8-200.fc31.armv7hl #1 SMP Wed Apr 29 19:05:06 UTC 2020 >> armv7l armv7l armv7l GNU/Linux >> >> # NOK: no network >> Linux bpi 5.6.0-300.fc32.armv7hl #1 SMP Mon Mar 30 16:37:50 UTC 2020 >> armv7l armv7l armv7l GNU/Linux >> >> # NOK: no network >> Linux bpi 5.6.19-200.fc31.armv7hl #1 SMP Wed Jun 17 17:10:22 UTC 2020 >> armv7l armv7l armv7l GNU/Linux >> >> # NOK: no network >> Linux bpi 5.7.4-200.fc32.armv7hl #1 SMP Fri Jun 19 00:52:22 UTC 2020 >> armv7l armv7l armv7l GNU/Linux >> >> >> Saw that there were a lot of changes in the near past in the b53 driver: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/net/dsa/b53?h=v5.8-rc1+ > > So from your notes above it looks like something regressed between the > 5.5.x series and the 5.6.0 release? If so I'm not sure what the > context of the changed in 5.8 are here. If there's more changes to the > driver in 5.8 dev cycle have you tried one of the Fedora rawhide 5.8 > rc1 or rc2 kernel builds to see if that resolves it? See my response to Gerhard, there are changes expected to how the network configuration should be done after: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8fab459e69abfd04a66d76423d18ba853fced4ab > > Failing that looking for the change in the 5.6 cycle would likely be > the better bet so we can work out what broke it and report it to the > upstream driver maintainer. Have you searched to see if others are > seeing a similar issue or have reported a similar issue upstream? > Gerhard is doing exactly this with his email. -- Florian
Re: [klibc] process '/usr/bin/rsync' started with executable stack
Le 25/06/2020 à 22:20, Kees Cook a écrit : On Thu, Jun 25, 2020 at 01:04:29PM +0300, Dan Carpenter wrote: On Wed, Jun 24, 2020 at 12:39:24PM -0700, Kees Cook wrote: On Wed, Jun 24, 2020 at 07:51:48PM +0300, Dan Carpenter wrote: In Debian testing the initrd triggers the warning. [ 34.529809] process '/usr/bin/fstype' started with executable stack Where does fstype come from there? I am going to guess it is either busybox or linked against klibc? klibc has known problems with executable stacks due to its trampoline implementation: https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks Yeah. It comes from klibc-utils. This is exactly what I was worried about back in Feb: https://lore.kernel.org/lkml/202002251341.48BC06E@keescook/ This warning, combined with klibc-based initrds, makes the whole thing pointless because it will always warn once on boot for the klibc stack, and then not warn about anything else after that. It looks like upstream klibc hasn't been touched in about 4 years, and it's been up to Ben to keep it alive in Debian. A couple ideas, in order of my preference: 1) stop using klibc-utils[1]. initramfs-tools-core is the only thing with a dependency on klibc-utils. Only a few things are missing from busybox. Does busybox cleanly build with klibc lib ? If it does, is the result as small ? 2) make the warning rate-limited instead? 3) fix the use of trampolines in klibc That's done, see https://git.kernel.org/pub/scm/libs/klibc/klibc.git/commit/?id=9d8d648e604026b32cad00a84ed6c29cbd157641 Discussed here https://lists.zytor.com/archives/klibc/2020-February/004271.html Christophe Thoughts? -Kees [1] Ben appears well aware of this idea, as he suggested it in 2018. :) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887159
Re: [PATCH] platform/chrome: Clarify SPDX license with GPL-2.0-only
On Thu, Jun 25, 2020 at 10:06:03PM +0300, Andy Shevchenko wrote: > On Thu, Jun 25, 2020 at 9:25 PM Enric Balletbo i Serra > wrote: > > > > Remove the ambiguity with GPL-2.0 and use an explicit GPL-2.0-only > > tag. > > Is there any? Last time IIRC Greg told me that in the kernel the old > and new variants are okay. They are just fine, leave it alone, the in-kernel LICENSES/ files show the valid SPDX tags that the kernel allows at this point in time. This is not worth the churn at all, once we get to complete coverage of all kernel files, then you can worry about trivial things like this. thanks, greg k-h
Re: [PATCH] fixing ERROR: Macros with complex values must be enclosed within parentheses.
On Thu, Jun 25, 2020 at 10:17:23PM -0400, B K Karthik wrote: > soc_camera.c: > > fixing ERROR: Macros with complex values must be enclused within parentheses. > > Signed-off-by: B K Karthik > --- > drivers/staging/media/soc_camera/soc_camera.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - You did not specify a description of why the patch is needed, or possibly, any description at all, in the email body. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what is needed in order to properly describe the change. - You did not write a descriptive Subject: for the patch, allowing Greg, and everyone else, to know what this patch is all about. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what a proper Subject: line should look like. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot
Re: [PATCH v2] ring-buffer: Have nested events still record running time stamp
Hi Steven,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tip/perf/core]
[also build test WARNING on linux/master linus/master v5.8-rc2 next-20200625]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Steven-Rostedt/ring-buffer-Have-nested-events-still-record-running-time-stamp/20200626-105715
base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
bb42b3d39781d7fcd3be7f9f9bf11b6661b5fdf1
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
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
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
kernel/trace/ring_buffer.c: In function '__rb_reserve_next':
kernel/trace/ring_buffer.c:2911:6: warning: unused variable 'delta'
[-Wunused-variable]
2911 | u64 delta, before, after;
| ^
>> kernel/trace/ring_buffer.c:2910:32: warning: variable 'next' set but not
>> used [-Wunused-but-set-variable]
2910 | unsigned long tail, write, w, next;
|^~~~
vim +/next +2910 kernel/trace/ring_buffer.c
2903
2904 static struct ring_buffer_event *
2905 __rb_reserve_next(struct ring_buffer_per_cpu *cpu_buffer,
2906struct rb_event_info *info)
2907 {
2908 struct ring_buffer_event *event;
2909 struct buffer_page *tail_page;
> 2910 unsigned long tail, write, w, next;
2911 u64 delta, before, after;
2912 bool abs = false;
2913
2914 /* Don't let the compiler play games with cpu_buffer->tail_page
*/
2915 tail_page = info->tail_page = READ_ONCE(cpu_buffer->tail_page);
2916
2917 /*A*/ w = local_read(&tail_page->write) & RB_WRITE_MASK;
2918 barrier();
2919 before = local64_read(&cpu_buffer->before_stamp);
2920 after = local64_read(&cpu_buffer->write_stamp);
2921 barrier();
2922 info->ts = rb_time_stamp(cpu_buffer->buffer);
2923
2924 if (ring_buffer_time_stamp_abs(cpu_buffer->buffer)) {
2925 info->delta = info->ts;
2926 abs = true;
2927 } else {
2928 info->delta = info->ts - after;
2929 }
2930
2931 if (unlikely(test_time_stamp(info->delta)))
2932 rb_handle_timestamp(cpu_buffer, info);
2933
2934 /*
2935 * If interrupting an event time update, we may need an
absolute timestamp.
2936 * Don't bother if this is the start of a new page (w == 0).
2937 */
2938 if (unlikely(before != after && w))
2939 info->add_timestamp = RB_ADD_STAMP_FORCE;
2940 /*
2941 * If the time delta since the last event is too big to
2942 * hold in the time field of the event, then we append a
2943 * TIME EXTEND event ahead of the data event.
2944 */
2945 if (unlikely(info->add_timestamp))
2946 info->length += RB_LEN_TIME_EXTEND;
2947
2948 next = READ_ONCE(cpu_buffer->next_write);
2949 WRITE_ONCE(cpu_buffer->next_write, w + info->length);
2950
2951 /*B*/ local64_set(&cpu_buffer->before_stamp, info->ts);
2952
2953 /*C*/ write = local_add_return(info->length, &tail_page->write);
2954
2955 /* set write to only the index of the write */
2956 write &= RB_WRITE_MASK;
2957
2958 tail = write - info->length;
2959
2960 /* See if we shot pass the end of this buffer page */
2961 if (unlikely(write > BUF_PAGE_SIZE)) {
2962 if (tail != w) {
2963 /* before and after may now different, fix it
up*/
2964 before =
local64_read(&cpu_buffer->before_stamp);
2965 after = local64_read(&cpu_buffer->write_stamp);
2966 if (before != after)
2967
(void)local64_cmpxchg(&cpu_buffer->before_stamp, before, after);
2968 }
2969 return rb_move_tail(cpu_buffer, tail, info);
2970 }
2971
2972
[git pull] drm fixes for v5.8-rc3
Hi Linus, Usual rc3 pickup, lots of little fixes all over, The core VT registration regression fix is probably the largest, otherwise ttm, amdgpu and tegra are the bulk, with some minor driver fixes. No i915 pull this week which may or may not mean I get 2x of it next week, we'll see how it goes. Regards, Dave. drm-fixes-2020-06-26: drm fixes for v5.8-rc3 core: - fix VT registration regression ttm: - fix two fence leaks amdgpu: - Fix missed mutex unlock in DC error path - Fix firmware leak for sdma5 - DC bpc property fixes amdkfd: - Fix memleak in an error path radeon: - Fix copy paste typo in NI DPM spll validation rcar-du: - build fix tegra: - add missing zpos property - child driver registration fix - debugfs cleanup fix - doc fix mcde: - reorder fbdev setup panel: - fix connector type - fix orientation for some panels sun4i: - fix dma/iommu configuration uvesafb: - respect blank flag The following changes since commit 48778464bb7d346b47157d21ffde2af6b2d39110: Linux 5.8-rc2 (2020-06-21 15:45:29 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-06-26 for you to fetch changes up to 687a0ed337367be5267652af5f6dbcfc954b8732: Merge tag 'drm-misc-fixes-2020-06-25' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2020-06-26 13:49:17 +1000) drm fixes for v5.8-rc3 core: - fix VT registration regression ttm: - fix two fence leaks amdgpu: - Fix missed mutex unlock in DC error path - Fix firmware leak for sdma5 - DC bpc property fixes amdkfd: - Fix memleak in an error path radeon: - Fix copy paste typo in NI DPM spll validation rcar-du: - build fix tegra: - add missing zpos property - child driver registration fix - debugfs cleanup fix - doc fix mcde: - reorder fbdev setup panel: - fix connector type - fix orientation for some panels sun4i: - fix dma/iommu configuration uvesafb: - respect blank flag Adam Ford (1): drm/panel-simple: fix connector type for LogicPD Type28 Display Bartlomiej Zolnierkiewicz (1): video: fbdev: uvesafb: fix "noblank" option handling Bernard Zhao (1): drm/amd: fix potential memleak in err branch Christophe JAILLET (1): gpu: host1x: Clean up debugfs in error handling path Colton Lewis (1): gpu: host1x: Correct trivial kernel-doc inconsistencies Daniel Gomez (1): drm: rcar-du: Fix build error Daniel Vetter (1): drm/fb-helper: Fix vt restore Dave Airlie (4): Merge tag 'du-fixes-20200621' of git://linuxtv.org/pinchartl/media into drm-fixes Merge tag 'drm/tegra/for-5.8-rc3' of git://anongit.freedesktop.org/tegra/linux into drm-fixes Merge tag 'amd-drm-fixes-5.8-2020-06-24' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'drm-misc-fixes-2020-06-25' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Denis Efremov (1): drm/radeon: fix fb_div check in ni_init_smc_spll_table() Hans de Goede (2): drm: panel-orientation-quirks: Add quirk for Asus T101HA panel drm: panel-orientation-quirks: Use generic orientation-data for Acer S1003 John van der Kamp (1): drm/amdgpu/display: Unlock mutex on error Linus Walleij (2): drm: mcde: Fix display initialization problem drm: mcde: Fix forgotten user of drm->dev_private Maxime Ripard (1): drm/sun4i: mixer: Call of_dma_configure if there's an IOMMU Nicolin Chen (1): drm/tegra: hub: Do not enable orphaned window group Stylon Wang (2): drm/amd/display: Enable output_bpc property on all outputs drm/amd/display: Fix ineffective setting of max bpc property Thierry Reding (4): gpu: host1x: Register child devices drm/tegra: hub: Register child devices gpu: host1x: Detach driver on unregister drm/tegra: Add zpos property for cursor planes Thomas Zimmermann (1): Merge v5.8-rc1 into drm-misc-fixes Tomi Valkeinen (1): drm/panel-simple: fix connector type for newhaven_nhd_43_480272ef_atxl Wenhui Sheng (1): drm/amdgpu: add fw release for sdma v5_0 Xiyu Yang (2): drm/ttm: Fix dma_fence refcnt leak in ttm_bo_vm_fault_reserved drm/ttm: Fix dma_fence refcnt leak when adding move fence drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 6 ++- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 1 + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +- .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 4 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_hdcp.c | 6 ++- drivers/gpu/drm/drm_fb_helper.c| 63 +- drivers/gpu/drm/drm_panel_orientation_quirks.c | 14 ++--- drivers/gpu/drm/mcde/mcde_display.c| 2 +- drivers/gpu/drm/mcde/mcde_drv.c| 3 +- drivers/gpu/drm/panel/panel-simple.c | 2 + drivers/gpu/drm/radeon/n
Re: [PATCH] Bluetooth: btusb: Comment on unbalanced pm reference
Hi Abhishek, > Add a comment clarifying that a PM reference in btusb_qca_cmd_timeout is > not unbalanced because it results in a device reset. > > Signed-off-by: Abhishek Pandit-Subedi > --- > > drivers/bluetooth/btusb.c | 1 + > 1 file changed, 1 insertion(+) patch has been applied to bluetooth-next tree. Regards Marcel
[PATCH v3 2/2] USB: serial: cp210x: Proper RTS control when buffers fill
From: Brant Merryman
CP210x hardware disables auto-RTS but leaves auto-CTS when
in hardware flow control mode and UART on cp210x hardware
is disabled. This allows data to flow out, but new data
will not come into the port. When re-opening the port, if
auto-CTS is enabled on the cp210x, then auto-RTS must be
re-enabled in the driver.
Signed-off-by: Phu Luu
Signed-off-by: Brant Merryman
---
06/09/2020: Patch v3 2/2 Modified based on feedback from Johan Hovold
12/18/2019: Patch v2 Broken into two patches and modified based on feedback
from Johan Hovold
12/09/2019: Initial submission of patch "Proper RTS control when buffers fill"
drivers/usb/serial/cp210x.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index bcceb4ad8be0..091441b1c5b9 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -917,6 +917,7 @@ static void cp210x_get_termios_port(struct usb_serial_port
*port,
u32 baud;
u16 bits;
u32 ctl_hs;
+ u32 flow_repl;
cp210x_read_u32_reg(port, CP210X_GET_BAUDRATE, &baud);
@@ -1017,6 +1018,23 @@ static void cp210x_get_termios_port(struct
usb_serial_port *port,
ctl_hs = le32_to_cpu(flow_ctl.ulControlHandshake);
if (ctl_hs & CP210X_SERIAL_CTS_HANDSHAKE) {
dev_dbg(dev, "%s - flow control = CRTSCTS\n", __func__);
+ /*
+* When the port is closed, the CP210x hardware disables
+* auto-RTS and RTS is deasserted but it leaves auto-CTS when
+* in hardware flow control mode. This prevents new data from
+* being received by the port. When re-opening the port, if
+* auto-CTS is enabled on the cp210x, then auto-RTS must be
+* re-enabled in the driver.
+*/
+ flow_repl = le32_to_cpu(flow_ctl.ulFlowReplace);
+ flow_repl &= ~CP210X_SERIAL_RTS_MASK;
+ flow_repl |=
CP210X_SERIAL_RTS_SHIFT(CP210X_SERIAL_RTS_FLOW_CTL);
+ flow_ctl.ulFlowReplace = cpu_to_le32(flow_repl);
+ cp210x_write_reg_block(port,
+ CP210X_SET_FLOW,
+ &flow_ctl,
+ sizeof(flow_ctl));
+
cflag |= CRTSCTS;
} else {
dev_dbg(dev, "%s - flow control = NONE\n", __func__);
--
2.17.0
[PATCH v3 1/2] USB: serial: cp210x: Enable usb generic throttle/unthrottle
From: Brant Merryman
Assign the .throttle and .unthrottle functions to be generic function
in the driver structure to prevent data loss that can otherwise occur
if the host does not enable USB throttling.
Signed-off-by: Phu Luu
Signed-off-by: Brant Merryman
---
06/09/2020: Patch v3 1/2 Modified based on feedback from Johan Hovold
12/18/2019: Patch v2 Broken into two patches and modified based on feedback
from Johan Hovold
12/09/2019: Initial submission of patch "Proper RTS control when buffers fill"
drivers/usb/serial/cp210x.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
index f5143eedbc48..bcceb4ad8be0 100644
--- a/drivers/usb/serial/cp210x.c
+++ b/drivers/usb/serial/cp210x.c
@@ -272,6 +272,8 @@ static struct usb_serial_driver cp210x_device = {
.break_ctl = cp210x_break_ctl,
.set_termios= cp210x_set_termios,
.tx_empty = cp210x_tx_empty,
+ .throttle = usb_serial_generic_throttle,
+ .unthrottle = usb_serial_generic_unthrottle,
.tiocmget = cp210x_tiocmget,
.tiocmset = cp210x_tiocmset,
.attach = cp210x_attach,
--
2.17.0
Re: [PATCH] cpufreq: schedutil: force frequency update when limits change
On Thu, Jun 25, 2020 at 7:32 PM Viresh Kumar wrote: > > On 26-06-20, 07:44, Viresh Kumar wrote: > > On 25-06-20, 13:47, Wei Wang wrote: > > > On Thu, Jun 25, 2020 at 3:23 AM Viresh Kumar > > > wrote: > > > > I am sorry but I am not fully sure of what the problem is. Can you > > > > describe that by giving an example with some random frequency, and > > > > tell the expected and actual behavior ? > > > > > > > The problem is sugov thought next_freq already updated (but actually > > > skipped by the rate limit thing) and all following updates will be > > > skipped. > > The rate-limiting thing is specific to android and not present in > mainline. Even in android I see next_freq getting updated only after > rate-limiting is verified. > > I think you maybe trying to fix an android only problem in mainline, > which may not be required at all. And I am not sure if Android has a > problem as well :) > Yes, that is Android specific, I added you to the Gerrit already. Thanks! -Wei > > I am sorry, can you please give a detailed example with existing > > frequency and limits, then the limits changed to new values, then what > > exactly happens ? > > > > > Actually this is specifically for Android common kernel 4.19's issue > > > which has sugov_up_down_rate_limit in sugov_update_next_freq, let's > > > continue discussion there. > > > > If it is a mainline problem, we will surely get it fixed here. Just > > that I am not able to understand the problem yet. Sorry about that. > > -- > viresh
[GIT RFC PULL rcu/urgent] Fix noinstr warnings for KCSAN
Hello! This pull request contains a single commit that uses "arch_" atomic operations to avoid the instrumentation that comes with the non-"arch_" versions. In preparation for that commit, it also has another commit that makes these "arch_" atomic operations available to generic code. Without these commits, KCSAN uses can see pointless errors. This pull request is currently RFC pending ongoing -next testing. This was not entirely free of drama, with Stephen needing to handle a merge conflict: https://lore.kernel.org/lkml/20200626131425.73ee4...@canb.auug.org.au/ However, the resolution looks straightforward to me. In addition, these two commits pass rcutorture testing and associated KCSAN testing. The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407: Linux 5.8-rc1 (2020-06-14 12:45:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/urgent for you to fetch changes up to b58e733fd774f3f4b49d9e7640d172a57e35200e: rcu: Fixup noinstr warnings (2020-06-25 08:24:32 -0700) Peter Zijlstra (2): locking/atomics: Provide the arch_atomic_ interface to generic code rcu: Fixup noinstr warnings include/linux/atomic-fallback.h | 236 +- include/linux/compiler.h | 2 +- kernel/rcu/tree.c | 32 - scripts/atomic/gen-atomic-fallback.sh | 31 + 4 files changed, 292 insertions(+), 9 deletions(-)
[PATCH net-next] bonding: Remove extraneous parentheses in bond_setup
Clang warns:
drivers/net/bonding/bond_main.c:4657:23: warning: equality comparison
with extraneous parentheses [-Wparentheses-equality]
if ((BOND_MODE(bond) == BOND_MODE_ACTIVEBACKUP))
^
drivers/net/bonding/bond_main.c:4681:23: warning: equality comparison
with extraneous parentheses [-Wparentheses-equality]
if ((BOND_MODE(bond) == BOND_MODE_ACTIVEBACKUP))
^
This warning occurs when a comparision has two sets of parentheses,
which is usually the convention for doing an assignment within an
if statement. Since equality comparisons do not need a second set of
parentheses, remove them to fix the warning.
Fixes: 18cb261afd7b ("bonding: support hardware encryption offload to slaves")
Link: https://github.com/ClangBuiltLinux/linux/issues/1066
Signed-off-by: Nathan Chancellor
---
drivers/net/bonding/bond_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 4ef99efc37f6..b3479584cc16 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4654,7 +4654,7 @@ void bond_setup(struct net_device *bond_dev)
#ifdef CONFIG_XFRM_OFFLOAD
/* set up xfrm device ops (only supported in active-backup right now) */
- if ((BOND_MODE(bond) == BOND_MODE_ACTIVEBACKUP))
+ if (BOND_MODE(bond) == BOND_MODE_ACTIVEBACKUP)
bond_dev->xfrmdev_ops = &bond_xfrmdev_ops;
bond->xs = NULL;
#endif /* CONFIG_XFRM_OFFLOAD */
@@ -4678,7 +4678,7 @@ void bond_setup(struct net_device *bond_dev)
bond_dev->hw_features |= NETIF_F_GSO_ENCAP_ALL | NETIF_F_GSO_UDP_L4;
#ifdef CONFIG_XFRM_OFFLOAD
- if ((BOND_MODE(bond) == BOND_MODE_ACTIVEBACKUP))
+ if (BOND_MODE(bond) == BOND_MODE_ACTIVEBACKUP)
bond_dev->hw_features |= BOND_XFRM_FEATURES;
#endif /* CONFIG_XFRM_OFFLOAD */
bond_dev->features |= bond_dev->hw_features;
base-commit: 7bed14551659875e1cd23a7c0266394a29a773b3
--
2.27.0
[PATCH V2] scsi: eesox: Fix different dev_id between 'request_irq()' and 'free_irq()'
The dev_id used in 'request_irq()' and 'free_irq()' should match.
So use 'info' in both cases.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Christophe JAILLET
---
V2: update free_irq instead of request_irq in order not to obviously break
code
---
drivers/scsi/arm/eesox.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/arm/eesox.c b/drivers/scsi/arm/eesox.c
index 6e204a2e0c8d..591ae2a6dd74 100644
--- a/drivers/scsi/arm/eesox.c
+++ b/drivers/scsi/arm/eesox.c
@@ -571,7 +571,7 @@ static int eesoxscsi_probe(struct expansion_card *ec, const
struct ecard_id *id)
if (info->info.scsi.dma != NO_DMA)
free_dma(info->info.scsi.dma);
- free_irq(ec->irq, host);
+ free_irq(ec->irq, info);
out_remove:
fas216_remove(host);
--
2.25.1
Re: [PATCH v3 3/8] mm/hugetlb: unify migration callbacks
2020년 6월 25일 (목) 오후 8:26, Michal Hocko 님이 작성: > > On Tue 23-06-20 15:13:43, Joonsoo Kim wrote: > > From: Joonsoo Kim > > > > There is no difference between two migration callback functions, > > alloc_huge_page_node() and alloc_huge_page_nodemask(), except > > __GFP_THISNODE handling. This patch adds an argument, gfp_mask, on > > alloc_huge_page_nodemask() and replace the callsite for > > alloc_huge_page_node() with the call to > > alloc_huge_page_nodemask(..., __GFP_THISNODE). > > > > It's safe to remove a node id check in alloc_huge_page_node() since > > there is no caller passing NUMA_NO_NODE as a node id. > > Yes this is indeed safe. alloc_huge_page_node used to be called from > other internal hugetlb allocation layer and that allowed NUMA_NO_NODE as > well. Now it is called only from the mempolicy migration callback and > that always specifies a node and want to stick with that node. > > But I have to say I really dislike the gfp semantic because it is > different from any other allocation function I can think of. It > specifies what to be added rather than what should be used. > > Removing the function is ok but please use the full gfp mask instead > or if that is impractical for some reason (wich shouldn't be the case > as htlb_alloc_mask should be trivial to make static inline) make it > explicit that this is not a gfp_mask but a gfp modifier and explicitly > state which modifiers are allowed. Okay. I will try to solve your concern. Concrete solution is not yet prepared but perhaps I will use full gfp_mask by using htlb_alloc_mask() in caller sites. Thanks.
[PATCH V2] scsi: powertec: Fix different dev_id between 'request_irq()' and 'free_irq()'
The dev_id used in 'request_irq()' and 'free_irq()' should match.
So use 'info' in both cases.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Christophe JAILLET
---
V2: update free_irq instead of request_irq in order not to obviously break
code
---
drivers/scsi/arm/powertec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/arm/powertec.c b/drivers/scsi/arm/powertec.c
index 772a13e5fd91..d99ef014528e 100644
--- a/drivers/scsi/arm/powertec.c
+++ b/drivers/scsi/arm/powertec.c
@@ -378,7 +378,7 @@ static int powertecscsi_probe(struct expansion_card *ec,
if (info->info.scsi.dma != NO_DMA)
free_dma(info->info.scsi.dma);
- free_irq(ec->irq, host);
+ free_irq(ec->irq, info);
out_release:
fas216_release(host);
--
2.25.1
Re: [PATCH 1/2] HID: wiimote: Initialize the controller LEDs with a device ID value
On Thursday, June 25, 2020 3:09:46 AM EDT David Rheinsberg wrote: > Hi > > On Thu, 25 Jun 2020 at 00:09, David Korth wrote: > > I've been manually setting the player IDs on Wii controllers when running > > multiplayer games by writing to the /sys/class/leds/ directory. Having the > > hid-wiimote driver do this itself significantly reduces setup time. > > What do you mean with "reduces setup time significantly"? Why would it > take that long to set the LEDs? > > Thanks > David The LED setup in this case is done entirely manually by me writing to the individual files in /sys/class/leds/. This has to be done when the controllers are connected initially, and if a controller has to be reconnected for some reason (e.g. it runs out of batteries). I don't know of any userspace tools that would make this easier to automate, except maybe a shell script, and I'd probably still need to run it manually. Both the Sixaxis and Xpad drivers appear to implement something similar, so perhaps a higher-level "player number" mechanism that works with all controllers would be worth looking into. This could in theory be done with a userspace daemon too (or a udev hook). As it is right now, I still think implementing it in the wiimote driver is the best method to keep it consistent with the rest of the drivers without having to install additional userspace tools. Thanks
Re: [PATCH] scsi: sd: add runtime pm to open / release
On 2020-06-25 01:16, Martin Kepplinger wrote:
> Also, why isn't "autopm" used in its ioctl() implementation
> (as opposed to in "sr")?
Some of the scsi_autopm_{get,put}_device() calls in the sr driver
have been introduced by me before I fully understood runtime pm.
I will have a another look to see whether these are really
necessary and if not, post a patch to remove these again.
Bart.
[PATCH] samples cn_test: fix cn leakage
From: liboling
Error return when add the second cn_test_id,
we need del the first cn_test_id.
Signed-off-by: liboling
---
samples/connector/cn_test.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/samples/connector/cn_test.c b/samples/connector/cn_test.c
index 0958a171d0..275e3f9082 100644
--- a/samples/connector/cn_test.c
+++ b/samples/connector/cn_test.c
@@ -151,6 +151,7 @@ static int cn_test_init(void)
cn_test_id.val++;
err = cn_add_callback(&cn_test_id, cn_test_name, cn_test_callback);
if (err) {
+ cn_test_id.val--;
cn_del_callback(&cn_test_id);
goto err_out;
}
--
2.17.1
[PATCH V3 1/3] cpufreq: Fix locking issues with governors
The locking around governors handling isn't adequate currently. The list
of governors should never be traversed without locking in place. Also we
must make sure the governor isn't removed while it is still referenced
by code.
Reported-by: Quentin Perret
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq.c | 59 ---
1 file changed, 36 insertions(+), 23 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 0128de3603df..e798a1193bdf 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -621,6 +621,24 @@ static struct cpufreq_governor *find_governor(const char
*str_governor)
return NULL;
}
+static struct cpufreq_governor *get_governor(const char *str_governor)
+{
+ struct cpufreq_governor *t;
+
+ mutex_lock(&cpufreq_governor_mutex);
+ t = find_governor(str_governor);
+ if (!t)
+ goto unlock;
+
+ if (!try_module_get(t->owner))
+ t = NULL;
+
+unlock:
+ mutex_unlock(&cpufreq_governor_mutex);
+
+ return t;
+}
+
static unsigned int cpufreq_parse_policy(char *str_governor)
{
if (!strncasecmp(str_governor, "performance", CPUFREQ_NAME_LEN))
@@ -640,28 +658,14 @@ static struct cpufreq_governor
*cpufreq_parse_governor(char *str_governor)
{
struct cpufreq_governor *t;
- mutex_lock(&cpufreq_governor_mutex);
-
- t = find_governor(str_governor);
- if (!t) {
- int ret;
-
- mutex_unlock(&cpufreq_governor_mutex);
-
- ret = request_module("cpufreq_%s", str_governor);
- if (ret)
- return NULL;
-
- mutex_lock(&cpufreq_governor_mutex);
+ t = get_governor(str_governor);
+ if (t)
+ return t;
- t = find_governor(str_governor);
- }
- if (t && !try_module_get(t->owner))
- t = NULL;
-
- mutex_unlock(&cpufreq_governor_mutex);
+ if (request_module("cpufreq_%s", str_governor))
+ return NULL;
- return t;
+ return get_governor(str_governor);
}
/**
@@ -815,12 +819,14 @@ static ssize_t show_scaling_available_governors(struct
cpufreq_policy *policy,
goto out;
}
+ mutex_lock(&cpufreq_governor_mutex);
for_each_governor(t) {
if (i >= (ssize_t) ((PAGE_SIZE / sizeof(char))
- (CPUFREQ_NAME_LEN + 2)))
- goto out;
+ break;
i += scnprintf(&buf[i], CPUFREQ_NAME_PLEN, "%s ", t->name);
}
+ mutex_unlock(&cpufreq_governor_mutex);
out:
i += sprintf(&buf[i], "\n");
return i;
@@ -1058,11 +1064,14 @@ static int cpufreq_init_policy(struct cpufreq_policy
*policy)
struct cpufreq_governor *def_gov = cpufreq_default_governor();
struct cpufreq_governor *gov = NULL;
unsigned int pol = CPUFREQ_POLICY_UNKNOWN;
+ bool put_governor = false;
+ int ret;
if (has_target()) {
/* Update policy governor to the one used before hotplug. */
- gov = find_governor(policy->last_governor);
+ gov = get_governor(policy->last_governor);
if (gov) {
+ put_governor = true;
pr_debug("Restoring governor %s for cpu %d\n",
policy->governor->name, policy->cpu);
} else if (def_gov) {
@@ -1089,7 +1098,11 @@ static int cpufreq_init_policy(struct cpufreq_policy
*policy)
return -ENODATA;
}
- return cpufreq_set_policy(policy, gov, pol);
+ ret = cpufreq_set_policy(policy, gov, pol);
+ if (put_governor)
+ module_put(gov->owner);
+
+ return ret;
}
static int cpufreq_add_policy_cpu(struct cpufreq_policy *policy, unsigned int
cpu)
--
2.25.0.rc1.19.g042ed3e048af
[PATCH V3 2/3] cpufreq: Register governors at core_initcall
From: Quentin Perret
Currently, most CPUFreq governors are registered at core_initcall time
when used as default, and module_init otherwise. In preparation for
letting users specify the default governor on the kernel command line,
change all of them to use core_initcall unconditionally, as is already
the case for schedutil and performance. This will enable us to assume
builtin governors have been registered before the builtin CPUFreq
drivers probe.
And since all governors now have similar init/exit patterns, introduce
two new macros cpufreq_governor_{init,exit}() to factorize the code.
Acked-by: Viresh Kumar
Signed-off-by: Quentin Perret
Signed-off-by: Viresh Kumar
---
.../platforms/cell/cpufreq_spudemand.c| 26 ++-
drivers/cpufreq/cpufreq_conservative.c| 22
drivers/cpufreq/cpufreq_ondemand.c| 24 +
drivers/cpufreq/cpufreq_performance.c | 14 ++
drivers/cpufreq/cpufreq_powersave.c | 18 +++--
drivers/cpufreq/cpufreq_userspace.c | 18 +++--
include/linux/cpufreq.h | 14 ++
kernel/sched/cpufreq_schedutil.c | 6 +
8 files changed, 36 insertions(+), 106 deletions(-)
diff --git a/arch/powerpc/platforms/cell/cpufreq_spudemand.c
b/arch/powerpc/platforms/cell/cpufreq_spudemand.c
index 55b31eadb3c8..ca7849e113d7 100644
--- a/arch/powerpc/platforms/cell/cpufreq_spudemand.c
+++ b/arch/powerpc/platforms/cell/cpufreq_spudemand.c
@@ -126,30 +126,8 @@ static struct cpufreq_governor spu_governor = {
.stop = spu_gov_stop,
.owner = THIS_MODULE,
};
-
-/*
- * module init and destoy
- */
-
-static int __init spu_gov_init(void)
-{
- int ret;
-
- ret = cpufreq_register_governor(&spu_governor);
- if (ret)
- printk(KERN_ERR "registration of governor failed\n");
- return ret;
-}
-
-static void __exit spu_gov_exit(void)
-{
- cpufreq_unregister_governor(&spu_governor);
-}
-
-
-module_init(spu_gov_init);
-module_exit(spu_gov_exit);
+cpufreq_governor_init(spu_governor);
+cpufreq_governor_exit(spu_governor);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Christian Krafft ");
-
diff --git a/drivers/cpufreq/cpufreq_conservative.c
b/drivers/cpufreq/cpufreq_conservative.c
index 737ff3b9c2c0..aa39ff31ec9f 100644
--- a/drivers/cpufreq/cpufreq_conservative.c
+++ b/drivers/cpufreq/cpufreq_conservative.c
@@ -322,17 +322,7 @@ static struct dbs_governor cs_governor = {
.start = cs_start,
};
-#define CPU_FREQ_GOV_CONSERVATIVE (&cs_governor.gov)
-
-static int __init cpufreq_gov_dbs_init(void)
-{
- return cpufreq_register_governor(CPU_FREQ_GOV_CONSERVATIVE);
-}
-
-static void __exit cpufreq_gov_dbs_exit(void)
-{
- cpufreq_unregister_governor(CPU_FREQ_GOV_CONSERVATIVE);
-}
+#define CPU_FREQ_GOV_CONSERVATIVE (cs_governor.gov)
MODULE_AUTHOR("Alexander Clouter ");
MODULE_DESCRIPTION("'cpufreq_conservative' - A dynamic cpufreq governor for "
@@ -343,11 +333,9 @@ MODULE_LICENSE("GPL");
#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE
struct cpufreq_governor *cpufreq_default_governor(void)
{
- return CPU_FREQ_GOV_CONSERVATIVE;
+ return &CPU_FREQ_GOV_CONSERVATIVE;
}
-
-core_initcall(cpufreq_gov_dbs_init);
-#else
-module_init(cpufreq_gov_dbs_init);
#endif
-module_exit(cpufreq_gov_dbs_exit);
+
+cpufreq_governor_init(CPU_FREQ_GOV_CONSERVATIVE);
+cpufreq_governor_exit(CPU_FREQ_GOV_CONSERVATIVE);
diff --git a/drivers/cpufreq/cpufreq_ondemand.c
b/drivers/cpufreq/cpufreq_ondemand.c
index 82a4d37ddecb..ac361a8b1d3b 100644
--- a/drivers/cpufreq/cpufreq_ondemand.c
+++ b/drivers/cpufreq/cpufreq_ondemand.c
@@ -408,7 +408,7 @@ static struct dbs_governor od_dbs_gov = {
.start = od_start,
};
-#define CPU_FREQ_GOV_ONDEMAND (&od_dbs_gov.gov)
+#define CPU_FREQ_GOV_ONDEMAND (od_dbs_gov.gov)
static void od_set_powersave_bias(unsigned int powersave_bias)
{
@@ -429,7 +429,7 @@ static void od_set_powersave_bias(unsigned int
powersave_bias)
continue;
policy = cpufreq_cpu_get_raw(cpu);
- if (!policy || policy->governor != CPU_FREQ_GOV_ONDEMAND)
+ if (!policy || policy->governor != &CPU_FREQ_GOV_ONDEMAND)
continue;
policy_dbs = policy->governor_data;
@@ -461,16 +461,6 @@ void od_unregister_powersave_bias_handler(void)
}
EXPORT_SYMBOL_GPL(od_unregister_powersave_bias_handler);
-static int __init cpufreq_gov_dbs_init(void)
-{
- return cpufreq_register_governor(CPU_FREQ_GOV_ONDEMAND);
-}
-
-static void __exit cpufreq_gov_dbs_exit(void)
-{
- cpufreq_unregister_governor(CPU_FREQ_GOV_ONDEMAND);
-}
-
MODULE_AUTHOR("Venkatesh Pallipadi ");
MODULE_AUTHOR("Alexey Starikovskiy ");
MODULE_DESCRIPTION("'cpufreq_ondemand' - A dynamic cpufreq governor for "
@@ -480,11 +470,9 @@ MODULE_LICENSE("GPL");
#ifdef CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND
struct cpufre
[PATCH V3 3/3] cpufreq: Specify default governor on command line
From: Quentin Perret
Currently, the only way to specify the default CPUfreq governor is via
Kconfig options, which suits users who can build the kernel themselves
perfectly.
However, for those who use a distro-like kernel (such as Android, with
the Generic Kernel Image project), the only way to use a different
default is to boot to userspace, and to then switch using the sysfs
interface. Being able to specify the default governor on the command
line, like is the case for cpuidle, would enable those users to specify
their governor of choice earlier on, and to simplify slighlty the
userspace boot procedure.
To support this use-case, add a kernel command line parameter enabling
to specify a default governor for CPUfreq, which takes precedence over
the builtin default.
This implementation has one notable limitation: the default governor
must be registered before the driver. This is solved for builtin
governors and drivers using appropriate *_initcall() functions. And in
the modular case, this must be reflected as a constraint on the module
loading order.
Signed-off-by: Quentin Perret
[ Viresh: Converted 'default_governor' to a string and parsing it only
at initcall level, and several updates to
cpufreq_init_policy(). ]
Signed-off-by: Viresh Kumar
---
.../admin-guide/kernel-parameters.txt | 5 +++
Documentation/admin-guide/pm/cpufreq.rst | 6 ++--
drivers/cpufreq/cpufreq.c | 36 ++-
3 files changed, 35 insertions(+), 12 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index fb95fad81c79..8deb5a89328a 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -703,6 +703,11 @@
cpufreq.off=1 [CPU_FREQ]
disable the cpufreq sub-system
+ cpufreq.default_governor=
+ [CPU_FREQ] Name of the default cpufreq governor or
+ policy to use. This governor must be registered in the
+ kernel before the cpufreq driver probes.
+
cpu_init_udelay=N
[X86] Delay for N microsec between assert and de-assert
of APIC INIT to start processors. This delay occurs
diff --git a/Documentation/admin-guide/pm/cpufreq.rst
b/Documentation/admin-guide/pm/cpufreq.rst
index 0c74a7784964..368e612145d2 100644
--- a/Documentation/admin-guide/pm/cpufreq.rst
+++ b/Documentation/admin-guide/pm/cpufreq.rst
@@ -147,9 +147,9 @@ CPUs in it.
The next major initialization step for a new policy object is to attach a
scaling governor to it (to begin with, that is the default scaling governor
-determined by the kernel configuration, but it may be changed later
-via ``sysfs``). First, a pointer to the new policy object is passed to the
-governor's ``->init()`` callback which is expected to initialize all of the
+determined by the kernel command line or configuration, but it may be changed
+later via ``sysfs``). First, a pointer to the new policy object is passed to
+the governor's ``->init()`` callback which is expected to initialize all of the
data structures necessary to handle the given policy and, possibly, to add
a governor ``sysfs`` interface to it. Next, the governor is started by
invoking its ``->start()`` callback.
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index e798a1193bdf..93c6399c1a42 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -50,6 +50,9 @@ static LIST_HEAD(cpufreq_governor_list);
#define for_each_governor(__governor) \
list_for_each_entry(__governor, &cpufreq_governor_list, governor_list)
+static char cpufreq_param_governor[CPUFREQ_NAME_LEN];
+static char default_governor[CPUFREQ_NAME_LEN];
+
/**
* The "cpufreq driver" - the arch- or hardware-dependent low
* level driver of CPUFreq support, and its spinlock. This lock
@@ -1061,7 +1064,6 @@ __weak struct cpufreq_governor
*cpufreq_default_governor(void)
static int cpufreq_init_policy(struct cpufreq_policy *policy)
{
- struct cpufreq_governor *def_gov = cpufreq_default_governor();
struct cpufreq_governor *gov = NULL;
unsigned int pol = CPUFREQ_POLICY_UNKNOWN;
bool put_governor = false;
@@ -1071,22 +1073,29 @@ static int cpufreq_init_policy(struct cpufreq_policy
*policy)
/* Update policy governor to the one used before hotplug. */
gov = get_governor(policy->last_governor);
if (gov) {
- put_governor = true;
pr_debug("Restoring governor %s for cpu %d\n",
-policy->governor->name, policy->cpu);
- } else if (def_gov) {
- gov = def_gov;
+gov->name, policy->cpu);
} else {
-
[PATCH v3 0/3] cpufreq: Allow default governor on cmdline and fix locking issues
Hi, I have picked Quentin's series over my patch, modified both and tested. V2->V3: - default_governor is a string now and we don't set it on governor registration or unregistration anymore. - Fixed locking issues in cpufreq_init_policy(). -- Viresh Original cover letter fro Quentin: This series enables users of prebuilt kernels (e.g. distro kernels) to specify their CPUfreq governor of choice using the kernel command line, instead of having to wait for the system to fully boot to userspace to switch using the sysfs interface. This is helpful for 2 reasons: 1. users get to choose the governor that runs during the actual boot; 2. it simplifies the userspace boot procedure a bit (one less thing to worry about). To enable this, the first patch moves all governor init calls to core_initcall, to make sure they are registered by the time the drivers probe. This should be relatively low impact as registering a governor is a simple procedure (it gets added to a llist), and all governors already load at core_initcall anyway when they're set as the default in Kconfig. This also allows to clean-up the governors' init/exit code, and reduces boilerplate. The second patch introduces the new command line parameter, inspired by its cpuidle counterpart. More details can be found in the respective patch headers. Changes in v2: - added Viresh's ack to patch 01 - moved the assignment of 'default_governor' in patch 02 to the governor registration path instead of the driver registration (Viresh) Quentin Perret (2): cpufreq: Register governors at core_initcall cpufreq: Specify default governor on command line Viresh Kumar (1): cpufreq: Fix locking issues with governors .../admin-guide/kernel-parameters.txt | 5 + Documentation/admin-guide/pm/cpufreq.rst | 6 +- .../platforms/cell/cpufreq_spudemand.c| 26 +- drivers/cpufreq/cpufreq.c | 93 --- drivers/cpufreq/cpufreq_conservative.c| 22 + drivers/cpufreq/cpufreq_ondemand.c| 24 ++--- drivers/cpufreq/cpufreq_performance.c | 14 +-- drivers/cpufreq/cpufreq_powersave.c | 18 +--- drivers/cpufreq/cpufreq_userspace.c | 18 +--- include/linux/cpufreq.h | 14 +++ kernel/sched/cpufreq_schedutil.c | 6 +- 11 files changed, 106 insertions(+), 140 deletions(-) -- 2.25.0.rc1.19.g042ed3e048af
RE: [PATCH v2 2/2] arm64: mm: reserve per-numa CMA after numa_init
> -Original Message- > From: Robin Murphy [mailto:robin.mur...@arm.com] > Sent: Thursday, June 25, 2020 11:16 PM > To: Song Bao Hua (Barry Song) ; h...@lst.de; > m.szyprow...@samsung.com; w...@kernel.org; > ganapatrao.kulka...@cavium.com; catalin.mari...@arm.com > Cc: io...@lists.linux-foundation.org; Linuxarm ; > linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Nicolas > Saenz Julienne ; Steve Capper > ; Andrew Morton ; > Mike Rapoport > Subject: Re: [PATCH v2 2/2] arm64: mm: reserve per-numa CMA after > numa_init > > On 2020-06-25 08:43, Barry Song wrote: > > Right now, smmu is using dma_alloc_coherent() to get memory to save > queues > > and tables. Typically, on ARM64 server, there is a default CMA located at > > node0, which could be far away from node2, node3 etc. > > with this patch, smmu will get memory from local numa node to save > command > > queues and page tables. that means dma_unmap latency will be shrunk > much. > > Meanwhile, when iommu.passthrough is on, device drivers which call dma_ > > alloc_coherent() will also get local memory and avoid the travel between > > numa nodes. > > > > Cc: Christoph Hellwig > > Cc: Marek Szyprowski > > Cc: Will Deacon > > Cc: Robin Murphy > > Cc: Ganapatrao Kulkarni > > Cc: Catalin Marinas > > Cc: Nicolas Saenz Julienne > > Cc: Steve Capper > > Cc: Andrew Morton > > Cc: Mike Rapoport > > Signed-off-by: Barry Song > > --- > > arch/arm64/mm/init.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > > index 1e93cfc7c47a..07d4d1fe7983 100644 > > --- a/arch/arm64/mm/init.c > > +++ b/arch/arm64/mm/init.c > > @@ -420,6 +420,8 @@ void __init bootmem_init(void) > > > > arm64_numa_init(); > > > > + dma_pernuma_cma_reserve(); > > + > > It might be worth putting this after the hugetlb_cma_reserve() call for > clarity, since the comment below applies equally to this call too. Yep, it looks even better though dma_pernuma_cma_reserve() is self-documenting by name. > > Robin. > > > /* > > * must be done after arm64_numa_init() which calls numa_init() to > > * initialize node_online_map that gets used in hugetlb_cma_reserve() > > Thanks Barry
[PATCH 1/1] drm/bridge: analogix_dp: Add enable_psr param
Add a toggle to enable/disable PSR from the kernel commandline.
This is useful in situations where PSR is supported by the hardware
but is not desired by the user. One such use case is working around
hardware errata.
Signed-off-by: Shawn Anastasio
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 76736fb8ed94..9735ab71fca7 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -35,6 +35,10 @@
static const bool verify_fast_training;
+static bool enable_psr = true;
+module_param(enable_psr, bool, 0644);
+MODULE_PARM_DESC(enable_psr, "PSR support (1 = enabled (default), 0 =
disabled)");
+
struct bridge_init {
struct i2c_client *client;
struct device_node *node;
@@ -979,7 +983,7 @@ static int analogix_dp_commit(struct analogix_dp_device *dp)
if (ret)
return ret;
- if (analogix_dp_detect_sink_psr(dp)) {
+ if (enable_psr && analogix_dp_detect_sink_psr(dp)) {
ret = analogix_dp_enable_sink_psr(dp);
if (ret)
return ret;
--
2.26.2
[PATCH 0/1] drm/bridge: analogix_dp: Add PSR toggle
This patch adds a commandline toggle for the Panel Self-Refresh feature to the analogix_dp bridge driver, much like the one in i915. This is required to work around a hardware fault in some Pinebook Pro units from the May 2020 batch whose display panels seem to behave sporadically when PSR is enabled. Shawn Anastasio (1): drm/bridge: analogix_dp: Add enable_psr param drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) -- 2.26.2
mmotm 2020-06-25-20-36 uploaded
The mm-of-the-moment snapshot 2020-06-25-20-36 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (5.x or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. https://github.com/hnaz/linux-mm The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is also available at https://github.com/hnaz/linux-mm This mmotm tree contains the following patches against 5.8-rc2: (patches marked "*" will be included in linux-next) origin.patch * openrisc-fix-boot-oops-when-debug_vm-is-enabled.patch * mm-do_swap_page-fix-up-the-error-code-instantiation.patch * mm-compaction-make-capture-control-handling-safe-wrt-interrupts.patch * kexec-do-not-verify-the-signature-without-the-lockdown-or-mandatory-signature.patch * ocfs2-avoid-inode-removed-while-nfsd-access-it.patch * ocfs2-load-global_inode_alloc.patch * ocfs2-fix-panic-on-nfs-server-over-ocfs2.patch * ocfs2-fix-value-of-ocfs2_invalid_slot.patch * lib-fix-test_hmmc-reference-after-free.patch * linux-bitsh-fix-unsigned-less-than-zero-warnings.patch * mm-slab-fix-sign-conversion-problem-in-memcg_uncharge_slab.patch * mm-slab-use-memzero_explicit-in-kzfree.patch * slub-cure-list_slab_objects-from-double-fix.patch * mm-fix-swap-cache-node-allocation-mask.patch * mm-memoryc-properly-pte_offset_map_lock-unlock-in-vm_insert_pages.patch * mm-debug_vm_pgtable-fix-build-failure-with-powerpc-8xx.patch * make-asm-generic-cacheflushh-more-standalone.patch * media-omap3isp-remove-cacheflushh.patch * mm-fix-a-warning-while-make-xmldocs.patch * mm-memcontrol-handle-div0-crash-race-condition-in-memorylow.patch * mm-memcontrol-fix-do-not-put-the-css-reference.patch * mm-memcg-prevent-missed-memorylow-load-tears.patch * docs-mm-gup-minor-documentation-update.patch * doc-thp-cow-fault-no-longer-allocate-thp.patch * mm-workingset-age-nonresident-information-alongside-anonymous-pages.patch * mm-swap-fix-for-mm-workingset-age-nonresident-information-alongside-anonymous-pages.patch * mm-memory-fix-io-cost-for-anonymous-page.patch * x86-hyperv-allocate-the-hypercall-page-with-only-read-and-execute-bits.patch * arm64-use-page_kernel_rox-directly-in-alloc_insn_page.patch * mm-remove-vmalloc_exec.patch * mm-fix-false-softlockup-during-pfn-range-removal.patch * maintainers-update-info-for-sparse.patch * mm-shuffle-dont-move-pages-between-zones-and-dont-read-garbage-memmaps.patch * mm-page_alloc-fix-documentation-error.patch * proc-kpageflags-prevent-an-integer-overflow-in-stable_page_flags.patch * proc-kpageflags-do-not-use-uninitialized-struct-pages.patch * checkpatch-test-git_dir-changes.patch * scripts-tagssh-collect-compiled-source-precisely.patch * bloat-o-meter-support-comparing-library-archives.patch * scripts-decode_stacktrace-skip-missing-symbols.patch * scripts-decode_stacktrace-guess-basepath-if-not-specified.patch * scripts-decode_stacktrace-guess-path-to-modules.patch * scripts-decode_stacktrace-guess-path-to-vmlinux-by-release-name.patch * ocfs2-clear-links-count-in-ocfs2_mknod-if-an-error-occurs.patch * ocfs2-fix-ocfs2-corrupt-when-iputting-an-inode.patch * ramfs-support-o_tmpfile.patch * kernel-watchdog-flush-all-printk-nmi-buffers-when-hardlockup-detected.patch mm.patch * mm-treewide-rename-kzfree-to-kfree_sensitive.patch * mm-ksize-should-silently-accept-a-null-pointer.patch * mm-expand-config_slab_freelist_hardened-to-include-slab.patch * slab-add-naive-detection-of-double-free.patch * mm-slub-extend-slub_debug-syntax-for-multiple-blocks.patch * mm-slub-make-some-slub_debug-related-attributes-read-only.patch * mm-slub-remove-runtime-allocation-order-changes.patch * mm-slub-make-remaining-slub_debug-related-attributes-read-only.patch * mm-slub-make-reclaim_account-attribute-read-only.patch * mm-slub-introduce-static-key-for-slub_debug.patch * mm-slub-introduce-kmem_cache_debug_flags.
Re: [RFC][PATCH] ring-buffer: Have nested events still record running time stamp
On Thu, 25 Jun 2020 22:36:11 -0400
Steven Rostedt wrote:
> +static void rb_time_set(rb_time_t *t, u64 val)
> +{
> + struct rb_time_read r;
> +
> + rb_time_read_set(&r, val);
> +
> + do {
> + r.start_cnt = local_inc_return(&t->start_cnt);
> + local_set(&t->top, r.top);
> + local_set(&t->bottom, r.bottom);
> + local_set(&t->end_cnt, r.start_cnt);
> + } while (r.start_cnt != local_read(&t->start_cnt));
> +}
> +
> +static bool rb_time_read_cmpxchg(local_t *l, unsigned long expect, unsigned
> long set)
> +{
> + unsigned long ret;
> +
> + ret = local_cmpxchg(l, expect, set);
> + return ret == expect;
> +}
> +
> +static bool rb_time_cmpxchg(rb_time_t *t, u64 expect, u64 set)
> +{
> + struct rb_time_read e, s;
> +
> + rb_time_read_set(&e, expect);
> + rb_time_read_set(&s, set);
> +
> + e.start_cnt = local_read(&t->start_cnt);
> + e.end_cnt = local_read(&t->end_cnt);
> +
> + s.start_cnt = e.start_cnt + 1;
> + s.end_cnt = e.start_cnt;
> +
> + if (!rb_time_read_cmpxchg(&t->start_cnt, e.start_cnt, s.start_cnt))
> + return false;
> + if (!rb_time_read_cmpxchg(&t->top, e.top, s.top))
> + return false;
> + if (!rb_time_read_cmpxchg(&t->bottom, e.bottom, s.bottom))
> + return false;
> + return rb_time_read_cmpxchg(&t->end_cnt, e.end_cnt, s.end_cnt);
> +}
> +
I have to think about this more, as I think there's a flaw in this
cmpxchg algorithm.
-- Steve
[PATCH v4] selftests: tpm: upgrade TPM2 tests from Python 2 to Python 3
Python 2 is no longer supported by the Python upstream project, so
upgrade TPM2 tests to Python 3.
Signed-off-by: Pengfei Xu
---
tools/testing/selftests/tpm2/test_smoke.sh | 4 +-
tools/testing/selftests/tpm2/test_space.sh | 2 +-
tools/testing/selftests/tpm2/tpm2.py | 56 +++---
tools/testing/selftests/tpm2/tpm2_tests.py | 39 +++
4 files changed, 52 insertions(+), 49 deletions(-)
diff --git a/tools/testing/selftests/tpm2/test_smoke.sh
b/tools/testing/selftests/tpm2/test_smoke.sh
index 663062701d5a..d05467f6d258 100755
--- a/tools/testing/selftests/tpm2/test_smoke.sh
+++ b/tools/testing/selftests/tpm2/test_smoke.sh
@@ -6,8 +6,8 @@ ksft_skip=4
[ -f /dev/tpm0 ] || exit $ksft_skip
-python -m unittest -v tpm2_tests.SmokeTest
-python -m unittest -v tpm2_tests.AsyncTest
+python3 -m unittest -v tpm2_tests.SmokeTest
+python3 -m unittest -v tpm2_tests.AsyncTest
CLEAR_CMD=$(which tpm2_clear)
if [ -n $CLEAR_CMD ]; then
diff --git a/tools/testing/selftests/tpm2/test_space.sh
b/tools/testing/selftests/tpm2/test_space.sh
index 36c9d030a1c6..151c64e8ee9f 100755
--- a/tools/testing/selftests/tpm2/test_space.sh
+++ b/tools/testing/selftests/tpm2/test_space.sh
@@ -6,4 +6,4 @@ ksft_skip=4
[ -f /dev/tpmrm0 ] || exit $ksft_skip
-python -m unittest -v tpm2_tests.SpaceTest
+python3 -m unittest -v tpm2_tests.SpaceTest
diff --git a/tools/testing/selftests/tpm2/tpm2.py
b/tools/testing/selftests/tpm2/tpm2.py
index d0fcb66a88a6..f34486cd7342 100644
--- a/tools/testing/selftests/tpm2/tpm2.py
+++ b/tools/testing/selftests/tpm2/tpm2.py
@@ -247,14 +247,14 @@ class ProtocolError(Exception):
class AuthCommand(object):
"""TPMS_AUTH_COMMAND"""
-def __init__(self, session_handle=TPM2_RS_PW, nonce='',
session_attributes=0,
- hmac=''):
+def __init__(self, session_handle=TPM2_RS_PW, nonce=bytes(),
+ session_attributes=0, hmac=bytes()):
self.session_handle = session_handle
self.nonce = nonce
self.session_attributes = session_attributes
self.hmac = hmac
-def __str__(self):
+def __bytes__(self):
fmt = '>I H%us B H%us' % (len(self.nonce), len(self.hmac))
return struct.pack(fmt, self.session_handle, len(self.nonce),
self.nonce, self.session_attributes, len(self.hmac),
@@ -268,11 +268,11 @@ class AuthCommand(object):
class SensitiveCreate(object):
"""TPMS_SENSITIVE_CREATE"""
-def __init__(self, user_auth='', data=''):
+def __init__(self, user_auth=bytes(), data=bytes()):
self.user_auth = user_auth
self.data = data
-def __str__(self):
+def __bytes__(self):
fmt = '>H%us H%us' % (len(self.user_auth), len(self.data))
return struct.pack(fmt, len(self.user_auth), self.user_auth,
len(self.data), self.data)
@@ -296,8 +296,9 @@ class Public(object):
return '>HHIH%us%usH%us' % \
(len(self.auth_policy), len(self.parameters), len(self.unique))
-def __init__(self, object_type, name_alg, object_attributes,
auth_policy='',
- parameters='', unique=''):
+def __init__(self, object_type, name_alg, object_attributes,
+ auth_policy=bytes(), parameters=bytes(),
+ unique=bytes()):
self.object_type = object_type
self.name_alg = name_alg
self.object_attributes = object_attributes
@@ -305,7 +306,7 @@ class Public(object):
self.parameters = parameters
self.unique = unique
-def __str__(self):
+def __bytes__(self):
return struct.pack(self.__fmt(),
self.object_type,
self.name_alg,
@@ -343,7 +344,7 @@ def get_algorithm(name):
def hex_dump(d):
d = [format(ord(x), '02x') for x in d]
-d = [d[i: i + 16] for i in xrange(0, len(d), 16)]
+d = [d[i: i + 16] for i in range(0, len(d), 16)]
d = [' '.join(x) for x in d]
d = os.linesep.join(d)
@@ -401,7 +402,7 @@ class Client:
pcrsel_len = max((i >> 3) + 1, 3)
pcrsel = [0] * pcrsel_len
pcrsel[i >> 3] = 1 << (i & 7)
-pcrsel = ''.join(map(chr, pcrsel))
+pcrsel = ''.join(map(chr, pcrsel)).encode()
fmt = '>HII IHB%us' % (pcrsel_len)
cmd = struct.pack(fmt,
@@ -443,7 +444,7 @@ class Client:
TPM2_CC_PCR_EXTEND,
i,
len(auth_cmd),
-str(auth_cmd),
+bytes(auth_cmd),
1, bank_alg, dig)
self.send_cmd(cmd)
@@ -457,7 +458,7 @@ class Client:
TPM2_RH_NULL,
TPM2_RH_NULL,
16,
- '\0' * 16,
+ ('\0' * 16).encode(),
0,
session_type,
TPM2_ALG_NULL,
@@ -472,7 +473,7 @@ class Client:
for i in pcrs
linux-next: manual merge of the usb tree with the usb.current tree
Hi all,
Today's linux-next merge of the usb tree got a conflict in:
drivers/usb/cdns3/ep0.c
between commit:
c0e2a0341cd8 ("usb: cdns3: ep0: fix the test mode set incorrectly")
from the usb.current tree and commit:
62fb45d317c5 ("USB: ch9: add "USB_" prefix in front of TEST defines")
from the usb tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/usb/cdns3/ep0.c
index 61ec5bb2b0ca,04a522f5ae58..
--- a/drivers/usb/cdns3/ep0.c
+++ b/drivers/usb/cdns3/ep0.c
@@@ -327,12 -327,11 +327,12 @@@ static int cdns3_ep0_feature_handle_dev
if (!set || (tmode & 0xff) != 0)
return -EINVAL;
- switch (tmode >> 8) {
+ tmode >>= 8;
+ switch (tmode) {
- case TEST_J:
- case TEST_K:
- case TEST_SE0_NAK:
- case TEST_PACKET:
+ case USB_TEST_J:
+ case USB_TEST_K:
+ case USB_TEST_SE0_NAK:
+ case USB_TEST_PACKET:
cdns3_set_register_bit(&priv_dev->regs->usb_cmd,
USB_CMD_STMODE |
USB_STS_TMODE_SEL(tmode - 1));
pgpCRdKSpjJz_.pgp
Description: OpenPGP digital signature
Re: [PATCH v3] selftests: tpm: upgrade TPM2 tests from Python 2 to Python 3
Hi Jarkko, I missed this improvement in previous mail. Will do. Thanks! BR. On 2020-06-26 at 00:51:45 +0300, Jarkko Sakkinen wrote: > On Fri, Jun 26, 2020 at 12:37:54AM +0800, Pengfei Xu wrote: > > Python 2 is no longer supported by the Python upstream project, so > > upgrade TPM2 tests to Python 3. > > > > Signed-off-by: Pengfei Xu > > --- > > tools/testing/selftests/tpm2/test_smoke.sh | 4 +- > > tools/testing/selftests/tpm2/test_space.sh | 2 +- > > tools/testing/selftests/tpm2/tpm2.py | 56 +++--- > > tools/testing/selftests/tpm2/tpm2_tests.py | 39 +++ > > 4 files changed, 52 insertions(+), 49 deletions(-) > > > > diff --git a/tools/testing/selftests/tpm2/test_smoke.sh > > b/tools/testing/selftests/tpm2/test_smoke.sh > > index 663062701d5a..d05467f6d258 100755 > > --- a/tools/testing/selftests/tpm2/test_smoke.sh > > +++ b/tools/testing/selftests/tpm2/test_smoke.sh > > @@ -6,8 +6,8 @@ ksft_skip=4 > > > > [ -f /dev/tpm0 ] || exit $ksft_skip > > > > -python -m unittest -v tpm2_tests.SmokeTest > > -python -m unittest -v tpm2_tests.AsyncTest > > +python3 -m unittest -v tpm2_tests.SmokeTest > > +python3 -m unittest -v tpm2_tests.AsyncTest > > > > CLEAR_CMD=$(which tpm2_clear) > > if [ -n $CLEAR_CMD ]; then > > diff --git a/tools/testing/selftests/tpm2/test_space.sh > > b/tools/testing/selftests/tpm2/test_space.sh > > index 36c9d030a1c6..151c64e8ee9f 100755 > > --- a/tools/testing/selftests/tpm2/test_space.sh > > +++ b/tools/testing/selftests/tpm2/test_space.sh > > @@ -6,4 +6,4 @@ ksft_skip=4 > > > > [ -f /dev/tpmrm0 ] || exit $ksft_skip > > > > -python -m unittest -v tpm2_tests.SpaceTest > > +python3 -m unittest -v tpm2_tests.SpaceTest > > diff --git a/tools/testing/selftests/tpm2/tpm2.py > > b/tools/testing/selftests/tpm2/tpm2.py > > index d0fcb66a88a6..88a0e7776a23 100644 > > --- a/tools/testing/selftests/tpm2/tpm2.py > > +++ b/tools/testing/selftests/tpm2/tpm2.py > > @@ -247,14 +247,14 @@ class ProtocolError(Exception): > > class AuthCommand(object): > > """TPMS_AUTH_COMMAND""" > > > > -def __init__(self, session_handle=TPM2_RS_PW, nonce='', > > session_attributes=0, > > - hmac=''): > > +def __init__(self, session_handle=TPM2_RS_PW, nonce=''.encode(), > > + session_attributes=0, hmac=''.encode()): > > Initialize these just directly as empty bytes objects (e.g. > nonce=bytes()) > > > self.session_handle = session_handle > > self.nonce = nonce > > self.session_attributes = session_attributes > > self.hmac = hmac > > > > -def __str__(self): > > +def __bytes__(self): > > fmt = '>I H%us B H%us' % (len(self.nonce), len(self.hmac)) > > return struct.pack(fmt, self.session_handle, len(self.nonce), > > self.nonce, self.session_attributes, > > len(self.hmac), > > @@ -268,11 +268,11 @@ class AuthCommand(object): > > class SensitiveCreate(object): > > """TPMS_SENSITIVE_CREATE""" > > > > -def __init__(self, user_auth='', data=''): > > +def __init__(self, user_auth=''.encode(), data=''.encode()): > > Ditto. > > > self.user_auth = user_auth > > self.data = data > > > > -def __str__(self): > > +def __bytes__(self): > > fmt = '>H%us H%us' % (len(self.user_auth), len(self.data)) > > return struct.pack(fmt, len(self.user_auth), self.user_auth, > > len(self.data), self.data) > > @@ -296,8 +296,9 @@ class Public(object): > > return '>HHIH%us%usH%us' % \ > > (len(self.auth_policy), len(self.parameters), len(self.unique)) > > > > -def __init__(self, object_type, name_alg, object_attributes, > > auth_policy='', > > - parameters='', unique=''): > > +def __init__(self, object_type, name_alg, object_attributes, > > + auth_policy=''.encode(), parameters=''.encode(), > > + unique=''.encode()): > > Ditto. > > > self.object_type = object_type > > self.name_alg = name_alg > > self.object_attributes = object_attributes > > @@ -305,7 +306,7 @@ class Public(object): > > self.parameters = parameters > > self.unique = unique > > > > -def __str__(self): > > +def __bytes__(self): > > return struct.pack(self.__fmt(), > > self.object_type, > > self.name_alg, > > @@ -343,7 +344,7 @@ def get_algorithm(name): > > > > def hex_dump(d): > > d = [format(ord(x), '02x') for x in d] > > -d = [d[i: i + 16] for i in xrange(0, len(d), 16)] > > +d = [d[i: i + 16] for i in range(0, len(d), 16)] > > d = [' '.join(x) for x in d] > > d = os.linesep.join(d) > > > > @@ -401,7 +402,7 @@ class Client: > > pcrsel_len = max((i >> 3) + 1, 3) > > pcrsel = [0] * pcrsel_len > > pcrsel[i >> 3] = 1 << (i & 7) > > -pcrse
linux-next: manual merge of the rcu tree with the tip tree
Hi all,
Today's linux-next merge of the rcu tree got a conflict in:
include/linux/compiler.h
between commit:
1d8fcbb76bb1 ("compiler.h: Move instrumentation_begin()/end() into new
header")
from the tip tree and commit:
3b9946ebaf2b ("rcu: Fixup noinstr warnings")
from the rcu tree.
I fixed it up (I used the tip version and added the following patch) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
From: Stephen Rothwell
Date: Fri, 26 Jun 2020 13:02:03 +1000
Subject: [PATCH] merge fix for "rcu: Fixup noinstr warnings"
Signed-off-by: Stephen Rothwell
---
include/linux/instrumentation.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/instrumentation.h b/include/linux/instrumentation.h
index 19cba99342c2..83d9a3c5204f 100644
--- a/include/linux/instrumentation.h
+++ b/include/linux/instrumentation.h
@@ -6,7 +6,7 @@
/* Begin/end of an instrumentation safe region */
#define instrumentation_begin() ({ \
- asm volatile("%c0:\n\t" \
+ asm volatile("%c0: nop\n\t" \
".pushsection .discard.instr_begin\n\t"\
".long %c0b - .\n\t" \
".popsection\n\t" : : "i" (__COUNTER__)); \
--
2.27.0
--
Cheers,
Stephen Rothwell
pgpHCi_2Ff6sg.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 0/2] zone-append support in io-uring and aio
On 2020/06/26 2:18, Kanchan Joshi wrote:
> [Revised as per feedback from Damien, Pavel, Jens, Christoph, Matias, Wilcox]
>
> This patchset enables zone-append using io-uring/linux-aio, on block IO path.
> Purpose is to provide zone-append consumption ability to applications which
> are
> using zoned-block-device directly.
>
> The application may specify RWF_ZONE_APPEND flag with write when it wants to
> send zone-append. RWF_* flags work with a certain subset of APIs e.g. uring,
> aio, and pwritev2. An error is reported if zone-append is requested using
> pwritev2. It is not in the scope of this patchset to support pwritev2 or any
> other sync write API for reasons described later.
>
> Zone-append completion result --->
> With zone-append, where write took place can only be known after completion.
> So apart from usual return value of write, additional mean is needed to obtain
> the actual written location.
>
> In aio, this is returned to application using res2 field of io_event -
>
> struct io_event {
> __u64 data; /* the data field from the iocb */
> __u64 obj;/* what iocb this event came from */
> __s64 res;/* result code for this event */
> __s64 res2; /* secondary result */
> };
>
> In io-uring, cqe->flags is repurposed for zone-append result.
>
> struct io_uring_cqe {
> __u64 user_data; /* sqe->data submission passed back */
> __s32 res;/* result code for this event */
> __u32 flags;
> };
>
> Since 32 bit flags is not sufficient, we choose to return zone-relative offset
> in sector/512b units. This can cover zone-size represented by chunk_sectors.
> Applications will have the trouble to combine this with zone start to know
> disk-relative offset. But if more bits are obtained by pulling from res field
> that too would compel application to interpret res field differently, and it
> seems more painstaking than the former option.
> To keep uniformity, even with aio, zone-relative offset is returned.
I am really not a fan of this, to say the least. The input is byte offset, the
output is 512B relative sector count... Arg... We really cannot do better than
that ?
At the very least, byte relative offset ? The main reason is that this is
_somewhat_ acceptable for raw block device accesses since the "sector"
abstraction has a clear meaning, but once we add iomap/zonefs async zone append
support, we really will want to have byte unit as the interface is regular
files, not block device file. We could argue that 512B sector unit is still
around even for files (e.g. block counts in file stat). Bu the different unit
for input and output of one operation is really ugly. This is not nice for the
user.
>
> Append using io_uring fixed-buffer --->
> This is flagged as not-supported at the moment. Reason being, for fixed-buffer
> io-uring sends iov_iter of bvec type. But current append-infra in block-layer
> does not support such iov_iter.
>
> Block IO vs File IO --->
> For now, the user zone-append interface is supported only for
> zoned-block-device.
> Regular files/block-devices are not supported. Regular file-system (e.g. F2FS)
> will not need this anyway, because zone peculiarities are abstracted within
> FS.
> At this point, ZoneFS also likes to use append implicitly rather than
> explicitly.
> But if/when ZoneFS starts supporting explicit/on-demand zone-append, the check
> allowing-only-block-device should be changed.
Sure, but I think the interface is still a problem. I am not super happy about
the 512B sector unit. Zonefs will be the only file system that will be impacted
since other normal POSIX file system will not have zone append interface for
users. So this is a limited problem. Still, even for raw block device files
accesses, POSIX system calls use Byte unit everywhere. Let's try to use that.
For aio, it is easy since res2 is unsigned long long. For io_uring, as discussed
already, we can still 8 bits from the cqe res. All you need is to add a small
helper function in userspace iouring.h to simplify the work of the application
to get that result.
>
> Semantics --->
> Zone-append, by its nature, may perform write on a different location than
> what
> was specified. It does not fit into POSIX, and trying to fit may just
> undermine
> its benefit. It may be better to keep semantics as close to zone-append as
> possible i.e. specify zone-start location, and obtain the actual-write
> location
> post completion. Towards that goal, existing async APIs seem to fit fine.
> Async APIs (uring, linux aio) do not work on implicit write-pointer and demand
> explicit write offset (which is what we need for append). Neither
> write-pointer
What do you mean by "implicit write pointer" ? Are you referring to the behavior
of AIO write with a block device file open with O_APPEND ? The yes, it does not
work. But that is perfectly fine for
