Re: Linux 4.18-rc7
On Tue, Jul 31, 2018 at 12:10:06PM +0530, Amit Pundir wrote: > On Tue, 31 Jul 2018 at 09:55, John Stultz wrote: > > > > On Mon, Jul 30, 2018 at 8:26 PM, Hugh Dickins wrote: > > > On Mon, 30 Jul 2018, Linus Torvalds wrote: > > >> On Mon, Jul 30, 2018 at 2:53 PM Hugh Dickins wrote: > > >> > > > >> > I have no problem with reverting -rc7's vma_is_anonymous() series. > > >> > > >> I don't think we need to revert the whole series: I think the rest are > > >> all fairly obvious cleanups, and shouldn't really have any semantic > > >> changes. > > > > > > Okay. > > > > > >> > > >> It's literally only that last patch in the series that then changes > > >> that meaning of "vm_ops". And I don't really _mind_ that last step > > >> either, but since we don't know exactly what it was that it broke, and > > >> we're past rc7, I don't think we really have any option but the revert > > >> it. > > > > > > It took me a long time to grasp what was happening, that that last > > > patch bfd40eaff5ab was fixing. Not quite explained in the commit. > > > > > > I think it was that by mistakenly passing the vma_is_anonymous() test, > > > create_huge_pmd() gave the MAP_PRIVATE kcov mapping a THP (instead of > > > COWing pages from kcov); which the truncate then had to split, and in > > > going to do so, again hit the mistaken vma_is_anonymous() test, BUG. > > > > > >> > > >> And if we revert it, I think we need to just remove the > > >> VM_BUG_ON_VMA() that it was supposed to fix. Because I do think that > > >> it is quite likely that the real bug is that overzealous BUG_ON(), > > >> since I can't see any reason why anonymous mappings should be special > > >> there. > > > > > > Yes, that probably has to go: but it's not clear what state it leaves > > > us in, with an anon THP being split by a truncate, without the expected > > > locking; I don't remember offhand, probably a subtler bug than that BUG, > > > which you may or may not consider an improvement. > > > > > > I fear that Kirill has not missed inserting a vma_set_anonymous() from > > > somewhere that it should be, but rather that zygote is working with some > > > special mapping which used to satisfy vma_is_anonymous(), faults supplying > > > backing pages, but now comes out as !vma_is_anonymous(), so do_fault() > > > finds !dummy_vm_ops.fault hence SIGBUS. > > > > I've been only casually following this thread (mostly just glad Amit > > caught it and I could avoid having to bisect the issue in my own > > Android testing), but this bit starting to shake a few old cobwebs > > loose in my brain. > > > > I'm wondering if Zygote is utilizing ashmem here, and we're somehow > > traversing ashmem purged memory, or due to some setup issue the > > initial traverse isn't being zero-filled as expected? > > > > ashmem ranges are created using: shmem_file_setup() and shmem_zero_setup() > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/android/ashmem.c#n377 > > > > > > If we purge pages, it punches it out with: > > vfs_fallocate(range->asma->file, > > FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, > > start, end - start); > > here: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/android/ashmem.c#n447 > > > > But in ashmem_pin(), we don't do anything other then returning if we > > purged any page in the range. > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/android/ashmem.c#n577 > > > > And I believe the future assumption is the if we traverse those pages > > they will be zero filled (if purged or even during the initial > > traversal after mmap) > > > > Its been a long time, and I've not looked at the code in question but > > it sounds from Hugh's comments above that we might instead get a > > SIGBUS here. > > > > Looking more at the problematic patch.. > > Amit: Does adding something like (whitespace damaged, apologies): > > > > index a1a0025..1af6915 100644 > > --- a/drivers/staging/android/ashmem.c > > +++ b/drivers/staging/android/ashmem.c > > @@ -402,7 +402,8 @@ static int ashmem_mmap(struct file *file, struct > > vm_area_struct *vma) > > fput(asma->file); > > goto out; > > } > > - } > > + } else > > + vma_set_anonymous(vma); > > > > if (vma->vm_file) > > fput(vma->vm_file); > > > > This ashmem change ^^ worked too. Okay. It makes sense. But I'm not convinced that's a legitimate way to get an anonymous mapping. I don't know how ashmem suppose to work. Looks like we get a shmem file associated with the mapping, even if user asked for private mapping. Shouldn't in this case vm_ops point to shmem_vm_ops? Note, we have only one other case when MAP_PRIVATE on a file gets you an anonymous mapping -- /dev/zero. -- Kirill A. Shutemov
[PATCH 2/5] regulator: rk808: add RK809 and RK817 support.
Add support for the rk809 and rk817 regulator driver.
Their specifications are as follows：
1、The RK809 and RK809 consist of 5 DCDCs, 9 LDOs
and have the same registers for these components except dcdc5.
2、The dcdc5 is a boost dcdc for RK817 and is a buck for RK809.
3、The RK817 has one switch but The Rk809 has two.
The output voltages are configurable and are meant to supply power
to the main processor and other components.
Signed-off-by: Tony Xie
---
drivers/regulator/Kconfig | 4 +-
drivers/regulator/rk808-regulator.c | 633 +++-
include/linux/mfd/rk808.h | 3 +
3 files changed, 637 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 5dbccf5..27ff89f 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -716,11 +716,11 @@ config REGULATOR_RC5T583
outputs which can be controlled by i2c communication.
config REGULATOR_RK808
- tristate "Rockchip RK805/RK808/RK818 Power regulators"
+ tristate "Rockchip RK805/RK808/RK809/RK817/RK818 Power regulators"
depends on MFD_RK808
help
Select this option to enable the power regulator of ROCKCHIP
- PMIC RK805,RK808 and RK818.
+ PMIC RK805,RK809&RK817,RK808 and RK818.
This driver supports the control of different power rails of device
through regulator interface. The device supports multiple DCDC/LDO
outputs which can be controlled by i2c communication.
diff --git a/drivers/regulator/rk808-regulator.c
b/drivers/regulator/rk808-regulator.c
index 213b687..9edce22 100644
--- a/drivers/regulator/rk808-regulator.c
+++ b/drivers/regulator/rk808-regulator.c
@@ -36,6 +36,12 @@
#define RK808_BUCK4_VSEL_MASK 0xf
#define RK808_LDO_VSEL_MASK0x1f
+#define RK809_BUCK5_VSEL_MASK 0x7
+
+#define RK817_LDO_VSEL_MASK0x7f
+#define RK817_BOOST_VSEL_MASK 0x7
+#define RK817_BUCK_VSEL_MASK 0x7f
+
#define RK818_BUCK_VSEL_MASK 0x3f
#define RK818_BUCK4_VSEL_MASK 0x1f
#define RK818_LDO_VSEL_MASK0x1f
@@ -65,6 +71,9 @@
/* max steps for increase voltage of Buck1/2, equal 100mv*/
#define MAX_STEPS_ONE_TIME 8
+#define ENABLE_MASK(id)(BIT(id) | BIT(4 + (id)))
+#define DISABLE_VAL(id)(BIT(4 + (id)))
+
#define RK805_DESC(_id, _match, _supply, _min, _max, _step, _vreg, \
_vmask, _ereg, _emask, _etime) \
[_id] = { \
@@ -86,6 +95,70 @@
.ops= &rk805_reg_ops, \
}
+#define RK817_DESC(_id, _match, _supply, _min, _max, _step, _vreg, \
+ _vmask, _ereg, _emask, _enval, _disval, _etime) \
+ { \
+ .name = (_match), \
+ .supply_name= (_supply),\
+ .of_match = of_match_ptr(_match), \
+ .regulators_node = of_match_ptr("regulators"), \
+ .type = REGULATOR_VOLTAGE,\
+ .id = (_id),\
+ .n_voltages = (((_max) - (_min)) / (_step) + 1),\
+ .owner = THIS_MODULE, \
+ .min_uV = (_min) * 1000,\
+ .uV_step= (_step) * 1000, \
+ .vsel_reg = (_vreg), \
+ .vsel_mask = (_vmask), \
+ .enable_reg = (_ereg), \
+ .enable_mask= (_emask), \
+ .enable_val = (_enval), \
+ .disable_val = (_disval), \
+ .enable_time= (_etime), \
+ .ops= &rk817_reg_ops, \
+ }
+
+#define RK817_BOOST_DESC(_id, _match, _supply, _min, _max, _step, _vreg,\
+ _vmask, _ereg, _emask, _enval, _disval, _etime, m_drop) \
+ { \
+ .name = (_match), \
+ .supply_name= (_supply),\
+ .of_match = of_match_ptr(_match), \
+ .regulators_node = of_match_ptr("regulators"), \
+ .type = REGULATOR_VOLTAGE,\
+ .id = (_id),\
+ .n_voltag
[PATCH 3/5] dt-bindings: mfd: rk808: Add binding informations for RK809 and RK817.
Add device tree bindings documentation for Rockchip's RK809 & RK817 PMIC. Signed-off-by: Tony Xie --- Documentation/devicetree/bindings/mfd/rk808.txt | 55 + 1 file changed, 55 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/rk808.txt b/Documentation/devicetree/bindings/mfd/rk808.txt index 91b6522..31c9f3d 100644 --- a/Documentation/devicetree/bindings/mfd/rk808.txt +++ b/Documentation/devicetree/bindings/mfd/rk808.txt @@ -3,11 +3,15 @@ RK8XX Power Management Integrated Circuit The rk8xx family current members: rk805 rk808 +rk809 +rk817 rk818 Required properties: - compatible: "rockchip,rk805" - compatible: "rockchip,rk808" +- compatible: "rockchip,rk809" +- compatible: "rockchip,rk817" - compatible: "rockchip,rk818" - reg: I2C slave address - interrupt-parent: The parent interrupt controller. @@ -46,6 +50,28 @@ Optional RK808 properties: the gpio controller. If DVS GPIOs aren't present, voltage changes will happen very quickly with no slow ramp time. +Optional RK809 properties: +- vcc1-supply: The input supply for DCDC_REG1 +- vcc2-supply: The input supply for DCDC_REG2 +- vcc3-supply: The input supply for DCDC_REG3 +- vcc4-supply: The input supply for DCDC_REG4 +- vcc5-supply: The input supply for LDO_REG1, LDO_REG2, LDO_REG3 +- vcc6-supply: The input supply for LDO_REG4, LDO_REG5, LDO_REG6 +- vcc7-supply: The input supply for LDO_REG7, LDO_REG8, LDO_REG9 +- vcc8-supply: The input supply for SWITCH_REG1 +- vcc9-supply: The input supply for DCDC_REG5, SWITCH_REG2 + +Optional RK817 properties: +- vcc1-supply: The input supply for DCDC_REG1 +- vcc2-supply: The input supply for DCDC_REG2 +- vcc3-supply: The input supply for DCDC_REG3 +- vcc4-supply: The input supply for DCDC_REG4 +- vcc5-supply: The input supply for LDO_REG1, LDO_REG2, LDO_REG3 +- vcc6-supply: The input supply for LDO_REG4, LDO_REG5, LDO_REG6 +- vcc7-supply: The input supply for LDO_REG7, LDO_REG8, LDO_REG9 +- vcc8-supply: The input supply for BOOST +- vcc9-supply: The input supply for OTG_SWITCH + Optional RK818 properties: - vcc1-supply: The input supply for DCDC_REG1 - vcc2-supply: The input supply for DCDC_REG2 @@ -87,6 +113,28 @@ number as described in RK808 datasheet. - SWITCH_REGn - valid values for n are 1 to 2 +Following regulators of the RK809 PMIC block are supported. Note that +the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or LDO +number as described in RK808 datasheet. + + - DCDC_REGn + - valid values for n are 1 to 5. + - LDO_REGn + - valid values for n are 1 to 9. + - SWITCH_REGn + - valid values for n are 1 to 2. + +Following regulators of the RK817 PMIC block are supported. Note that +the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or LDO +number as described in RK818 datasheet. + + - DCDC_REGn + - valid values for n are 1 to 4. + - LDO_REGn + - valid values for n are 1 to 9. + - BOOST + - OTG_SWITCH + Following regulators of the RK818 PMIC block are supported. Note that the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or LDO number as described in RK818 datasheet. @@ -99,6 +147,13 @@ number as described in RK818 datasheet. - HDMI_SWITCH - OTG_SWITCH +There are three pins needed to config, named "gpio_ts" "gpio_gt" "gpio_slp". + The gpio_gt and gpio_ts pins support the gpio function. + The gpio_slp pin is for controlling the pmic states, as below: + - reset + - power down + - sleep + Standard regulator bindings are used inside regulator subnodes. Check Documentation/devicetree/bindings/regulator/regulator.txt for more details -- 1.9.1
[PATCH 2/5] regulator: rk808: Add regulator driver for RK809 and RK817.
Add support for the rk809 and rk817 regulator driver.
Their specifications are as follows：
1、The RK809 and RK809 consist of 5 DCDCs, 9 LDOs
and have the same registers for these components except dcdc5.
2、The dcdc5 is a boost dcdc for RK817 and is a buck for RK809.
3、The RK817 has one switch but The Rk809 has two.
The output voltages are configurable and are meant to supply power
to the main processor and other components.
Signed-off-by: Tony Xie
---
drivers/regulator/Kconfig | 4 +-
drivers/regulator/rk808-regulator.c | 633 +++-
include/linux/mfd/rk808.h | 3 +
3 files changed, 637 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 5dbccf5..27ff89f 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -716,11 +716,11 @@ config REGULATOR_RC5T583
outputs which can be controlled by i2c communication.
config REGULATOR_RK808
- tristate "Rockchip RK805/RK808/RK818 Power regulators"
+ tristate "Rockchip RK805/RK808/RK809/RK817/RK818 Power regulators"
depends on MFD_RK808
help
Select this option to enable the power regulator of ROCKCHIP
- PMIC RK805,RK808 and RK818.
+ PMIC RK805,RK809&RK817,RK808 and RK818.
This driver supports the control of different power rails of device
through regulator interface. The device supports multiple DCDC/LDO
outputs which can be controlled by i2c communication.
diff --git a/drivers/regulator/rk808-regulator.c
b/drivers/regulator/rk808-regulator.c
index 213b687..9edce22 100644
--- a/drivers/regulator/rk808-regulator.c
+++ b/drivers/regulator/rk808-regulator.c
@@ -36,6 +36,12 @@
#define RK808_BUCK4_VSEL_MASK 0xf
#define RK808_LDO_VSEL_MASK0x1f
+#define RK809_BUCK5_VSEL_MASK 0x7
+
+#define RK817_LDO_VSEL_MASK0x7f
+#define RK817_BOOST_VSEL_MASK 0x7
+#define RK817_BUCK_VSEL_MASK 0x7f
+
#define RK818_BUCK_VSEL_MASK 0x3f
#define RK818_BUCK4_VSEL_MASK 0x1f
#define RK818_LDO_VSEL_MASK0x1f
@@ -65,6 +71,9 @@
/* max steps for increase voltage of Buck1/2, equal 100mv*/
#define MAX_STEPS_ONE_TIME 8
+#define ENABLE_MASK(id)(BIT(id) | BIT(4 + (id)))
+#define DISABLE_VAL(id)(BIT(4 + (id)))
+
#define RK805_DESC(_id, _match, _supply, _min, _max, _step, _vreg, \
_vmask, _ereg, _emask, _etime) \
[_id] = { \
@@ -86,6 +95,70 @@
.ops= &rk805_reg_ops, \
}
+#define RK817_DESC(_id, _match, _supply, _min, _max, _step, _vreg, \
+ _vmask, _ereg, _emask, _enval, _disval, _etime) \
+ { \
+ .name = (_match), \
+ .supply_name= (_supply),\
+ .of_match = of_match_ptr(_match), \
+ .regulators_node = of_match_ptr("regulators"), \
+ .type = REGULATOR_VOLTAGE,\
+ .id = (_id),\
+ .n_voltages = (((_max) - (_min)) / (_step) + 1),\
+ .owner = THIS_MODULE, \
+ .min_uV = (_min) * 1000,\
+ .uV_step= (_step) * 1000, \
+ .vsel_reg = (_vreg), \
+ .vsel_mask = (_vmask), \
+ .enable_reg = (_ereg), \
+ .enable_mask= (_emask), \
+ .enable_val = (_enval), \
+ .disable_val = (_disval), \
+ .enable_time= (_etime), \
+ .ops= &rk817_reg_ops, \
+ }
+
+#define RK817_BOOST_DESC(_id, _match, _supply, _min, _max, _step, _vreg,\
+ _vmask, _ereg, _emask, _enval, _disval, _etime, m_drop) \
+ { \
+ .name = (_match), \
+ .supply_name= (_supply),\
+ .of_match = of_match_ptr(_match), \
+ .regulators_node = of_match_ptr("regulators"), \
+ .type = REGULATOR_VOLTAGE,\
+ .id = (_id),\
+ .n_voltag
[PATCH 1/5] mfd: rk808: Add RK817 and RK809 support
The rk809 and rk817 are a Power Management IC (PMIC) for multimedia
and handheld devices. It contains the following components:
- Regulators
- RTC
- Clocking
Both RK809 and RK817 chips are using a similar register map,
so we can reuse the RTC and Clocking and regulators functionality.
Signed-off-by: Tony Xie
---
drivers/mfd/Kconfig | 6 +-
drivers/mfd/rk808.c | 218 +-
include/linux/mfd/rk808.h | 172
kernel/reboot.c | 1 +
4 files changed, 391 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b860eb5..84f2f22 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -967,14 +967,14 @@ config MFD_RC5T583
different functionality of the device.
config MFD_RK808
- tristate "Rockchip RK805/RK808/RK818 Power Management Chip"
+ tristate "Rockchip RK805/RK808/RK809/RK817/RK818 Power Management Chip"
depends on I2C && OF
select MFD_CORE
select REGMAP_I2C
select REGMAP_IRQ
help
- If you say yes here you get support for the RK805, RK808 and RK818
- Power Management chips.
+ If you say yes here you get support for the RK805, RK809 and RK817,
+ RK808 and RK818 Power Management chips.
This driver provides common support for accessing the device
through I2C interface. The device supports multiple sub-devices
including interrupts, RTC, LDO & DCDC regulators, and onkey.
diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
index 216fbf6..62e2fe1 100644
--- a/drivers/mfd/rk808.c
+++ b/drivers/mfd/rk808.c
@@ -62,6 +62,29 @@ static bool rk808_is_volatile_reg(struct device *dev,
unsigned int reg)
return false;
}
+static bool rk817_is_volatile_reg(struct device *dev, unsigned int reg)
+{
+ /*
+* Notes:
+* - Technically the ROUND_30s bit makes RTC_CTRL_REG volatile, but
+* we don't use that feature. It's better to cache.
+* - It's unlikely we care that RK808_DEVCTRL_REG is volatile since
+* bits are cleared in case when we shutoff anyway, but better safe.
+*/
+
+ switch (reg) {
+ case RK817_SECONDS_REG ... RK817_WEEKS_REG:
+ case RK817_RTC_STATUS_REG:
+ case RK817_INT_STS_REG0:
+ case RK817_INT_STS_REG1:
+ case RK817_INT_STS_REG2:
+ case RK817_SYS_STS:
+ return true;
+ }
+
+ return true;
+}
+
static const struct regmap_config rk818_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -86,6 +109,14 @@ static bool rk808_is_volatile_reg(struct device *dev,
unsigned int reg)
.volatile_reg = rk808_is_volatile_reg,
};
+static const struct regmap_config rk817_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = RK817_GPIO_INT_CFG,
+ .cache_type = REGCACHE_NONE,
+ .volatile_reg = rk817_is_volatile_reg,
+};
+
static struct resource rtc_resources[] = {
{
.start = RK808_IRQ_RTC_ALARM,
@@ -94,6 +125,13 @@ static bool rk808_is_volatile_reg(struct device *dev,
unsigned int reg)
}
};
+static struct resource rk817_rtc_resources[] = {
+ {
+ .start = RK817_IRQ_RTC_ALARM,
+ .end= RK817_IRQ_RTC_ALARM,
+ .flags = IORESOURCE_IRQ,
+ }
+};
static struct resource rk805_key_resources[] = {
{
.start = RK805_IRQ_PWRON_FALL,
@@ -107,6 +145,19 @@ static bool rk808_is_volatile_reg(struct device *dev,
unsigned int reg)
}
};
+static struct resource rk817_pwrkey_resources[] = {
+ {
+ .start = RK817_IRQ_PWRON_RISE,
+ .end= RK817_IRQ_PWRON_RISE,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = RK817_IRQ_PWRON_FALL,
+ .end= RK817_IRQ_PWRON_FALL,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
static const struct mfd_cell rk805s[] = {
{ .name = "rk808-clkout", },
{ .name = "rk808-regulator", },
@@ -132,6 +183,21 @@ static bool rk808_is_volatile_reg(struct device *dev,
unsigned int reg)
},
};
+static const struct mfd_cell rk817s[] = {
+ { .name = "rk808-clkout",},
+ { .name = "rk808-regulator",},
+ {
+ .name = "rk8xx-pwrkey",
+ .num_resources = ARRAY_SIZE(rk817_pwrkey_resources),
+ .resources = &rk817_pwrkey_resources[0],
+ },
+ {
+ .name = "rk808-rtc",
+ .num_resources = ARRAY_SIZE(rk817_rtc_resources),
+ .resources = &rk817_rtc_resources[0],
+ },
+};
+
static const struct mfd_cell rk818s[] = {
{ .name = "rk808-clkout", },
{ .name = "rk808-regulator", },
@@ -167,6 +233,13 @@ static bool rk808_is_volatile_reg(struct device *dev,
unsig
Re: [LKP] [mm, oom] c1e4c54f9c: BUG:KASAN:null-ptr-deref_in_d
On Mon 30-07-18 19:05:50, David Rientjes wrote:
> On Mon, 30 Jul 2018, Michal Hocko wrote:
>
> > On Mon 30-07-18 17:03:20, kernel test robot wrote:
> > [...]
> > > [9.034310] BUG: KASAN: null-ptr-deref in dump_header+0x10c/0x448
> >
> > Could you faddr2line on the offset please?
> >
>
> It's possible that p is NULL when calling dump_header(). In this case we
> do not want to print any line concerning a victim because no oom kill has
> occurred.
You are right. I have missed those.
> This code shouldn't be part of dump_header(), which is called from
> multiple contexts even when an oom kill has not occurred, and is
> ratelimited. The single line output should be the canonical way that
> userspace parses the log for oom victims, we can't ratelimit it.
>
> The following would be a fix patch, but it will be broken if the cgroup
> aware oom killer is removed from -mm so that the oom_group stuff can be
> merged.
cgroup aware oom killer is going to be replaced by a new implementation
IIUC so the fix should be based on the yuzhoujian patch. Ideally to be
resubmitted.
I would just suggest adding it into a function
dump_oom_summary(struct oom_control *oc, struct task_struct *p)
yuzhoujian could you take care of that please?
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -438,14 +438,6 @@ static void dump_header(struct oom_control *oc, struct
> task_struct *p)
>
> dump_stack();
>
> - /* one line summary of the oom killer context. */
> - pr_info("oom-kill:constraint=%s,nodemask=%*pbl",
> - oom_constraint_text[oc->constraint],
> - nodemask_pr_args(oc->nodemask));
> - cpuset_print_current_mems_allowed();
> - mem_cgroup_print_oom_context(oc->memcg, p);
> - pr_cont(",task=%s,pid=%d,uid=%d\n", p->comm, p->pid,
> - from_kuid(&init_user_ns, task_uid(p)));
> if (is_memcg_oom(oc))
> mem_cgroup_print_oom_meminfo(oc->memcg);
> else {
> @@ -836,7 +828,8 @@ static bool task_will_free_mem(struct task_struct *task)
> return ret;
> }
>
> -static void __oom_kill_process(struct task_struct *victim)
> +static void __oom_kill_process(struct task_struct *victim,
> +struct oom_control *oc)
> {
> struct task_struct *p;
> struct mm_struct *mm;
> @@ -883,6 +876,18 @@ static void __oom_kill_process(struct task_struct
> *victim)
> K(get_mm_counter(victim->mm, MM_ANONPAGES)),
> K(get_mm_counter(victim->mm, MM_FILEPAGES)),
> K(get_mm_counter(victim->mm, MM_SHMEMPAGES)));
> +
> + if (oc) {
> + /* One line summary for non-group oom kills */
> + pr_info("oom-kill: constraint=%s, nodemask=%*pbl",
> + oom_constraint_text[oc->constraint],
> + nodemask_pr_args(oc->nodemask));
> + cpuset_print_current_mems_allowed();
> + mem_cgroup_print_oom_context(oc->memcg, victim);
> + pr_cont(", task=%s, pid=%d, uid=%d\n",
> + victim->comm, victim->pid,
> + from_kuid(&init_user_ns, task_uid(victim)));
> + }
> task_unlock(victim);
>
> /*
> @@ -986,13 +991,13 @@ static void oom_kill_process(struct oom_control *oc,
> const char *message)
> }
> read_unlock(&tasklist_lock);
>
> - __oom_kill_process(victim);
> + __oom_kill_process(victim, oc);
> }
>
> static int oom_kill_memcg_member(struct task_struct *task, void *unused)
> {
> get_task_struct(task);
> - __oom_kill_process(task);
> + __oom_kill_process(task, NULL);
> return 0;
> }
>
> @@ -1020,7 +1025,7 @@ static bool oom_kill_memcg_victim(struct oom_control
> *oc)
> oc->chosen_task == INFLIGHT_VICTIM)
> goto out;
>
> - __oom_kill_process(oc->chosen_task);
> + __oom_kill_process(oc->chosen_task, oc);
> }
>
> out:
--
Michal Hocko
SUSE Labs
Re: [PATCH 1/2] leds: core: Introduce LED pattern trigger
On 31 July 2018 at 14:22, Baolin Wang wrote: > Hi Bjorn, > > On 31 July 2018 at 11:54, Bjorn Andersson wrote: >> On Mon 30 Jul 05:29 PDT 2018, Baolin Wang wrote: >> >>> Some LED controllers have support for autonomously controlling >>> brightness over time, according to some preprogrammed pattern or >>> function. >>> >>> This patch adds pattern trigger that LED device can configure the >>> pattern and trigger it. >>> >>> Signed-off-by: Raphael Teysseyre >>> Signed-off-by: Baolin Wang >>> --- >>> .../ABI/testing/sysfs-class-led-trigger-pattern| 21 ++ >>> drivers/leds/trigger/Kconfig | 10 + >>> drivers/leds/trigger/Makefile |1 + >>> drivers/leds/trigger/ledtrig-pattern.c | 349 >>> >>> include/linux/leds.h | 19 ++ >>> 5 files changed, 400 insertions(+) >>> create mode 100644 >>> Documentation/ABI/testing/sysfs-class-led-trigger-pattern >>> create mode 100644 drivers/leds/trigger/ledtrig-pattern.c >>> >>> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern >>> b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern >>> new file mode 100644 >>> index 000..c52da34 >>> --- /dev/null >>> +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern >>> @@ -0,0 +1,21 @@ >>> +What:/sys/class/leds//pattern >>> +Date:August 2018 >>> +KernelVersion: 4.19 >>> +Description: >>> + Specify a pattern for the LED, for LED hardware that support >>> + altering the brightness as a function of time. >>> + >>> + The pattern is given by a series of tuples, of brightness and >>> + duration (ms). The LED is expected to traverse the series and >>> + each brightness value for the specified duration. Duration of >>> + 0 means brightness should immediately change to new value. >>> + >>> + The format of the pattern values should be: >>> + "brightness_1 duration_1, brightness_2 duration_2, >>> brightness_3 >>> + duration_3, ...". >>> + >>> +What:/sys/class/leds//repeat >>> +Date:August 2018 >>> +KernelVersion: 4.19 >>> +Description: >>> + Specify a pattern repeat number. 0 means repeat indefinitely. >> >> If 0 means infinity, does 1 mean "repeat 1 time"? If so how would I > > Right. > >> specify that I want the pattern to run one time (i.e. 0 repetitions). > > If you set repeat to 1 to make the driver clear the is_indefinite > flag. So when the repeat number decreases to 0, it will stop. > >> >>> diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig >>> index a2559b4..a03afcd 100644 >>> --- a/drivers/leds/trigger/Kconfig >>> +++ b/drivers/leds/trigger/Kconfig >>> @@ -125,6 +125,16 @@ config LEDS_TRIGGER_CAMERA >>> This enables direct flash/torch on/off by the driver, kernel space. >>> If unsure, say Y. >>> >>> +config LEDS_TRIGGER_PATTERN >>> + tristate "LED Pattern Trigger" >>> + depends on LEDS_TRIGGERS >>> + help >>> + This allows LEDs blinking with an arbitrary pattern. Can be useful >>> + on embedded systems with no screen to give out a status code to >>> + a human. >> >> While the pattern mechanism could be used to communicate some message >> the use cases we've seen so far is all about enabling hardware to pulse >> LEDs instead of blinking them... > > Right. I will improve the message here. > >> >>> + >>> + If unsure, say N >>> + >>> config LEDS_TRIGGER_PANIC >>> bool "LED Panic Trigger" >>> depends on LEDS_TRIGGERS >>> diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile >>> index f3cfe19..c5d180e 100644 >>> --- a/drivers/leds/trigger/Makefile >>> +++ b/drivers/leds/trigger/Makefile >>> @@ -13,3 +13,4 @@ obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT)+= >>> ledtrig-transient.o >>> obj-$(CONFIG_LEDS_TRIGGER_CAMERA)+= ledtrig-camera.o >>> obj-$(CONFIG_LEDS_TRIGGER_PANIC) += ledtrig-panic.o >>> obj-$(CONFIG_LEDS_TRIGGER_NETDEV)+= ledtrig-netdev.o >>> +obj-$(CONFIG_LEDS_TRIGGER_PATTERN) += ledtrig-pattern.o >>> diff --git a/drivers/leds/trigger/ledtrig-pattern.c >>> b/drivers/leds/trigger/ledtrig-pattern.c >>> new file mode 100644 >>> index 000..b709aa1 >>> --- /dev/null >>> +++ b/drivers/leds/trigger/ledtrig-pattern.c >>> @@ -0,0 +1,349 @@ >>> +// SPDX-License-Identifier: GPL-2.0 >>> + >>> +/* >>> + * LED pattern trigger >>> + * >>> + * Idea discussed with Pavel Machek. Raphael Teysseyre implemented >>> + * the first version, Baolin Wang simplified and improved the approach. >> >> Might be a coincidence, but parts of this patch looks pretty close to >> mine... >> >>> + */ >>> + >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> +#include >>> + >>> +/* >>> + * The "pattern" attribute contains at most PAGE_SIZE
Re: [PATCH] kernel.h: Disable -Wreturn-stack-address for _THIS_IP_
Hi Nick, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.18-rc7 next-20180727] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Nick-Desaulniers/kernel-h-Disable-Wreturn-stack-address-for-_THIS_IP_/20180731-135818 config: i386-tinyconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 All warnings (new ones prefixed by >>): In file included from include/linux/spinlock.h:58:0, from include/linux/mmzone.h:8, from include/linux/gfp.h:6, from include/linux/slab.h:15, from include/linux/crypto.h:24, from arch/x86/kernel/asm-offsets.c:9: include/linux/bottom_half.h: In function 'local_bh_disable': >> include/linux/bottom_half.h:19:0: warning: ignoring #pragma clang diagnostic >> [-Wunknown-pragmas] __local_bh_disable_ip(_THIS_IP_, SOFTIRQ_DISABLE_OFFSET); >> include/linux/bottom_half.h:19:0: warning: ignoring #pragma clang diagnostic >> [-Wunknown-pragmas] >> include/linux/bottom_half.h:19:0: warning: ignoring #pragma clang diagnostic >> [-Wunknown-pragmas] include/linux/bottom_half.h: In function 'local_bh_enable': include/linux/bottom_half.h:32:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas] __local_bh_enable_ip(_THIS_IP_, SOFTIRQ_DISABLE_OFFSET); include/linux/bottom_half.h:32:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas] include/linux/bottom_half.h:32:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas] In file included from include/linux/mmzone.h:8:0, from include/linux/gfp.h:6, from include/linux/slab.h:15, from include/linux/crypto.h:24, from arch/x86/kernel/asm-offsets.c:9: include/linux/spinlock.h: In function 'spin_lock_bh': >> include/linux/spinlock.h:315:0: warning: ignoring #pragma clang diagnostic >> [-Wunknown-pragmas] raw_spin_lock_bh(&lock->rlock); >> include/linux/spinlock.h:315:0: warning: ignoring #pragma clang diagnostic >> [-Wunknown-pragmas] >> include/linux/spinlock.h:315:0: warning: ignoring #pragma clang diagnostic >> [-Wunknown-pragmas] include/linux/spinlock.h: In function 'spin_unlock_bh': include/linux/spinlock.h:355:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas] raw_spin_unlock_bh(&lock->rlock); include/linux/spinlock.h:355:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas] include/linux/spinlock.h:355:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas] include/linux/spinlock.h: In function 'spin_trylock_bh': include/linux/spinlock.h:370:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas] return raw_spin_trylock_bh(&lock->rlock); include/linux/spinlock.h:370:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas] include/linux/spinlock.h:370:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas] -- In file included from include/linux/rcupdate.h:41:0, from include/linux/rculist.h:11, from include/linux/pid.h:5, from include/linux/sched.h:14, from kernel//sched/sched.h:5, from kernel//sched/core.c:8: include/linux/bottom_half.h: In function 'local_bh_disable': >> include/linux/bottom_half.h:19:0: warning: ignoring #pragma clang diagnostic >> [-Wunknown-pragmas] __local_bh_disable_ip(_THIS_IP_, SOFTIRQ_DISABLE_OFFSET); >> include/linux/bottom_half.h:19:0: warning: ignoring #pragma clang diagnostic >> [-Wunknown-pragmas] >> include/linux/bottom_half.h:19:0: warning: ignoring #pragma clang diagnostic >> [-Wunknown-pragmas] include/linux/bottom_half.h: In function 'local_bh_enable': include/linux/bottom_half.h:32:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas] __local_bh_enable_ip(_THIS_IP_, SOFTIRQ_DISABLE_OFFSET); include/linux/bottom_half.h:32:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas] include/linux/bottom_half.h:32:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas] In file included from include/linux/seqlock.h:36:0, from include/linux/time.h:6, from include/linux/ktime.h:24, from include/linux/rcutiny.h:28, from include/linux/rcupdate.h:210, from include/linux/rculist.h:11, from include/linux/pid.h:5, from include/linux/sched.h:14, from kernel//sched/sched.h:5, from kernel//sched/core.c:8: include/lin
Re: checkpatch: SPDX integration breaks --root
> OK. How about:
>
> though this might not work on a path with spaces
> or some such...
>
> ---
> scripts/checkpatch.pl | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index f25f708cd2a7..afb9fb27908c 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -852,9 +852,10 @@ sub is_maintained_obsolete {
> sub is_SPDX_License_valid {
> my ($license) = @_;
>
> - return 1 if (!$tree || which("python") eq "" || !(-e
> "$root/scripts/spdxcheck.py"));
> + return 1 if (!$tree || which("python") eq "" || !(-e
> "$root/scripts/spdxcheck.py") || !(-e "$root/.git"));
>
> - my $status = `echo "$license" | python $root/scripts/spdxcheck.py -`;
> + my $root_path = abs_path($root);
> + my $status = `cd $root_path; echo "$license" | python
> scripts/spdxcheck.py -`;
> return 0 if ($status ne "");
> return 1;
> }
Thanks, works at least for me. Maybe use
cd "$root_path"
to get it working with paths that include spaces.
Tested-by: Charlemagne Lasse
Re: Linux 4.18-rc7
On Tue, 31 Jul 2018 at 09:55, John Stultz wrote: > > On Mon, Jul 30, 2018 at 8:26 PM, Hugh Dickins wrote: > > On Mon, 30 Jul 2018, Linus Torvalds wrote: > >> On Mon, Jul 30, 2018 at 2:53 PM Hugh Dickins wrote: > >> > > >> > I have no problem with reverting -rc7's vma_is_anonymous() series. > >> > >> I don't think we need to revert the whole series: I think the rest are > >> all fairly obvious cleanups, and shouldn't really have any semantic > >> changes. > > > > Okay. > > > >> > >> It's literally only that last patch in the series that then changes > >> that meaning of "vm_ops". And I don't really _mind_ that last step > >> either, but since we don't know exactly what it was that it broke, and > >> we're past rc7, I don't think we really have any option but the revert > >> it. > > > > It took me a long time to grasp what was happening, that that last > > patch bfd40eaff5ab was fixing. Not quite explained in the commit. > > > > I think it was that by mistakenly passing the vma_is_anonymous() test, > > create_huge_pmd() gave the MAP_PRIVATE kcov mapping a THP (instead of > > COWing pages from kcov); which the truncate then had to split, and in > > going to do so, again hit the mistaken vma_is_anonymous() test, BUG. > > > >> > >> And if we revert it, I think we need to just remove the > >> VM_BUG_ON_VMA() that it was supposed to fix. Because I do think that > >> it is quite likely that the real bug is that overzealous BUG_ON(), > >> since I can't see any reason why anonymous mappings should be special > >> there. > > > > Yes, that probably has to go: but it's not clear what state it leaves > > us in, with an anon THP being split by a truncate, without the expected > > locking; I don't remember offhand, probably a subtler bug than that BUG, > > which you may or may not consider an improvement. > > > > I fear that Kirill has not missed inserting a vma_set_anonymous() from > > somewhere that it should be, but rather that zygote is working with some > > special mapping which used to satisfy vma_is_anonymous(), faults supplying > > backing pages, but now comes out as !vma_is_anonymous(), so do_fault() > > finds !dummy_vm_ops.fault hence SIGBUS. > > I've been only casually following this thread (mostly just glad Amit > caught it and I could avoid having to bisect the issue in my own > Android testing), but this bit starting to shake a few old cobwebs > loose in my brain. > > I'm wondering if Zygote is utilizing ashmem here, and we're somehow > traversing ashmem purged memory, or due to some setup issue the > initial traverse isn't being zero-filled as expected? > > ashmem ranges are created using: shmem_file_setup() and shmem_zero_setup() > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/android/ashmem.c#n377 > > > If we purge pages, it punches it out with: > vfs_fallocate(range->asma->file, > FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, > start, end - start); > here: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/android/ashmem.c#n447 > > But in ashmem_pin(), we don't do anything other then returning if we > purged any page in the range. > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/android/ashmem.c#n577 > > And I believe the future assumption is the if we traverse those pages > they will be zero filled (if purged or even during the initial > traversal after mmap) > > Its been a long time, and I've not looked at the code in question but > it sounds from Hugh's comments above that we might instead get a > SIGBUS here. > > Looking more at the problematic patch.. > Amit: Does adding something like (whitespace damaged, apologies): > > index a1a0025..1af6915 100644 > --- a/drivers/staging/android/ashmem.c > +++ b/drivers/staging/android/ashmem.c > @@ -402,7 +402,8 @@ static int ashmem_mmap(struct file *file, struct > vm_area_struct *vma) > fput(asma->file); > goto out; > } > - } > + } else > + vma_set_anonymous(vma); > > if (vma->vm_file) > fput(vma->vm_file); > This ashmem change ^^ worked too. Regards, Amit Pundir > > Seem to resolve it? (Sorry, I'd test it myself, but I'm away from my > desk for the night). > thanks > -john
Re: [PATCH v5] PCI: Check for PCIe downtraining conditions
On 7/24/2018 12:52 AM, Tal Gilboa wrote:
On 7/24/2018 12:01 AM, Jakub Kicinski wrote:
On Mon, 23 Jul 2018 15:03:38 -0500, Alexandru Gagniuc wrote:
PCIe downtraining happens when both the device and PCIe port are
capable of a larger bus width or higher speed than negotiated.
Downtraining might be indicative of other problems in the system, and
identifying this from userspace is neither intuitive, nor
straightforward.
The easiest way to detect this is with pcie_print_link_status(),
since the bottleneck is usually the link that is downtrained. It's not
a perfect solution, but it works extremely well in most cases.
Signed-off-by: Alexandru Gagniuc
---
For the sake of review, I've created a __pcie_print_link_status() which
takes a 'verbose' argument. If we agree want to go this route, and
update
the users of pcie_print_link_status(), I can split this up in two
patches.
I prefer just printing this information in the core functions, and
letting
drivers not have to worry about this. Though there seems to be strong
for
not going that route, so here it goes:
FWIW the networking drivers print PCIe BW because sometimes the network
bandwidth is simply over-provisioned on multi port cards, e.g. 80Gbps
card on a x8 link.
Sorry to bike shed, but currently the networking cards print the info
during probe. Would it make sense to move your message closer to probe
time? Rather than when device is added. If driver structure is
available, we could also consider adding a boolean to struct pci_driver
to indicate if driver wants the verbose message? This way we avoid
duplicated prints.
I have no objection to current patch, it LGTM. Just a thought.
I don't see the reason for having two functions. What's the problem with
adding the verbose argument to the original function?
drivers/pci/pci.c | 22 ++
drivers/pci/probe.c | 21 +
include/linux/pci.h | 1 +
3 files changed, 40 insertions(+), 4 deletions(-) >>
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 316496e99da9..414ad7b3abdb 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5302,14 +5302,15 @@ u32 pcie_bandwidth_capable(struct pci_dev
*dev, enum pci_bus_speed *speed,
}
/**
- * pcie_print_link_status - Report the PCI device's link speed and
width
+ * __pcie_print_link_status - Report the PCI device's link speed and
width
* @dev: PCI device to query
+ * @verbose: Be verbose -- print info even when enough bandwidth is
available.
*
* Report the available bandwidth at the device. If this is less
than the
* device is capable of, report the device's maximum possible
bandwidth and
* the upstream link that limits its performance to less than that.
*/
-void pcie_print_link_status(struct pci_dev *dev)
+void __pcie_print_link_status(struct pci_dev *dev, bool verbose)
{
enum pcie_link_width width, width_cap;
enum pci_bus_speed speed, speed_cap;
@@ -5319,11 +5320,11 @@ void pcie_print_link_status(struct pci_dev *dev)
bw_cap = pcie_bandwidth_capable(dev, &speed_cap, &width_cap);
bw_avail = pcie_bandwidth_available(dev, &limiting_dev, &speed,
&width);
- if (bw_avail >= bw_cap)
+ if (bw_avail >= bw_cap && verbose)
pci_info(dev, "%u.%03u Gb/s available PCIe bandwidth (%s
x%d link)\n",
bw_cap / 1000, bw_cap % 1000,
PCIE_SPEED2STR(speed_cap), width_cap);
- else
+ else if (bw_avail < bw_cap)
pci_info(dev, "%u.%03u Gb/s available PCIe bandwidth,
limited by %s x%d link at %s (capable of %u.%03u Gb/s with %s x%d
link)\n",
bw_avail / 1000, bw_avail % 1000,
PCIE_SPEED2STR(speed), width,
@@ -5331,6 +5332,19 @@ void pcie_print_link_status(struct pci_dev *dev)
bw_cap / 1000, bw_cap % 1000,
PCIE_SPEED2STR(speed_cap), width_cap);
}
+
+/**
+ * pcie_print_link_status - Report the PCI device's link speed and
width
+ * @dev: PCI device to query
+ *
+ * Report the available bandwidth at the device. If this is less
than the
+ * device is capable of, report the device's maximum possible
bandwidth and
+ * the upstream link that limits its performance to less than that.
+ */
+void pcie_print_link_status(struct pci_dev *dev)
+{
+ __pcie_print_link_status(dev, true);
+}
EXPORT_SYMBOL(pcie_print_link_status);
/**
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ac876e32de4b..1f7336377c3b 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2205,6 +2205,24 @@ static struct pci_dev *pci_scan_device(struct
pci_bus *bus, int devfn)
return dev;
}
+static void pcie_check_upstream_link(struct pci_dev *dev)
+{
+ if (!pci_is_pcie(dev))
+ return;
+
+ /* Look from the device up to avoid downstream ports with no
devices. */
+ if ((pci_pcie_type(dev) != PCI_EXP_TYPE_ENDPOINT) &&
+ (pci_pcie_type(dev) != PCI_EXP_TYPE_LEG_END) &&
+ (pci_pcie_type(dev) != PCI_EXP_TYPE_UPSTREAM))
Re: [PATCH v2 2/4] power: bq25890_charger.c: Remove unused table
On 27 July 2018 at 17:26, Angus Ainslie wrote: > Hi Krzysztof, > > On 2018-07-26 00:51, Krzysztof Kozlowski wrote: >> >> On 25 July 2018 at 21:46, Angus Ainslie (Purism) wrote: >>> >>> The BATCMP table isn't used so drop it >> >> >> TBL_VCLAMP also looks unused. TBL_IPRECHG does not have table entry. >> > > I as looking to drop the tables that would be problematic to the new part. > Would you like me to resolve these 2 as well ? Yes. Since you are removing some entry then let's remove all unneeded entries. Krzysztof
Re: [PATCH 1/3] ext4: super: Fix spectre gadget in ext4_quota_on
> On Jul 27, 2018, at 11:46 AM, Josh Poimboeuf wrote:
>
> On Fri, Jul 27, 2018 at 04:23:55PM +, Jeremy Cline wrote:
>> 'type' is a user-controlled value used to index into 's_qf_names', which
>> can be used in a Spectre v1 attack. Clamp 'type' to the size of the
>> array to avoid a speculative out-of-bounds read.
>>
>> Cc: Josh Poimboeuf
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Jeremy Cline
>> ---
>> fs/ext4/super.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
>> index 6480e763080f..c04a09b51742 100644
>> --- a/fs/ext4/super.c
>> +++ b/fs/ext4/super.c
>> @@ -40,6 +40,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>>
>> @@ -5559,6 +5560,7 @@ static int ext4_quota_on(struct super_block *sb, int
>> type, int format_id,
>> if (path->dentry->d_sb != sb)
>> return -EXDEV;
>> /* Journaling quota? */
>> +type = array_index_nospec(type, EXT4_MAXQUOTAS);
This check just papers over the issue, but AFAICS doesn't actually
solve any problems. It ends up squashing an invalid value to be
the same as EXT4_MAXQUOTAS, rather than returning an error to the
caller as it should.
>> if (EXT4_SB(sb)->s_qf_names[type]) {
>> /* Quotafile not in fs root? */
>> if (path->dentry->d_parent != sb->s_root)
>
> Generally we try to put the array_index_nospec() close to the bounds
> check for which it's trying to prevent speculation past.
>
> In this case, I'd expect the EXT4_MAXQUOTAS bounds check to be in
> do_quotactl(), but it seems to be missing:
>
> if (type >= (XQM_COMMAND(cmd) ? XQM_MAXQUOTAS : MAXQUOTAS))
> return -EINVAL;
Agreed that this should be checked at the highest layer possible.
IMHO, this means one check in the VFS/quota layer, and a separate
check in the filesystem layer.
> Also it looks like XQM_MAXQUOTAS, MAXQUOTAS, and EXT4_MAXQUOTAS all have the
> same value (3). Maybe they can be consolidated to just use
> MAXQUOTAS everywhere?
No, the filesystem-specific MAXQUOTAS values were separated from
the kernel MAXQUOTAS value for a good reason. This allows some
filesystems to support new quota types (e.g. project quotas) that
not all other filesystems can handle. This may potentially change
again in the future, so they shouldn't be tightly coupled.
> Then the nospec would be simple:
>
> if (type >= MAXQUOTAS)
> return -EINVAL;
> type = array_index_nospec(type, MAXQUOTAS);
>
> Otherwise I think we may need to disperse the array_index_nospec calls
> deeper in the callchain.
>
> --
> Josh
Cheers, Andreas
signature.asc
Description: Message signed with OpenPGP
[char-misc-next 05/12] mei: define dma ring buffer sizes for PCH12 HW and newer
From: Alexander Usyskin
Define dma ring buffer sizes for PCH12 (CLN HW and newer)
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/hw-me.c | 13 +
drivers/misc/mei/hw-me.h | 4
2 files changed, 17 insertions(+)
diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index 0e3c31595dda..0759c3a668de 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include "mei_dev.h"
#include "hbm.h"
@@ -1389,6 +1390,11 @@ static bool mei_me_fw_type_sps(struct pci_dev *pdev)
.fw_status.status[4] = PCI_CFG_HFS_5, \
.fw_status.status[5] = PCI_CFG_HFS_6
+#define MEI_CFG_DMA_128 \
+ .dma_size[DMA_DSCR_HOST] = SZ_128K, \
+ .dma_size[DMA_DSCR_DEVICE] = SZ_128K, \
+ .dma_size[DMA_DSCR_CTRL] = PAGE_SIZE
+
/* ICH Legacy devices */
static const struct mei_cfg mei_me_ich_cfg = {
MEI_CFG_ICH_HFS,
@@ -1421,6 +1427,12 @@ static const struct mei_cfg mei_me_pch8_sps_cfg = {
MEI_CFG_FW_SPS,
};
+/* Cannon Lake and newer devices */
+static const struct mei_cfg mei_me_pch12_cfg = {
+ MEI_CFG_PCH8_HFS,
+ MEI_CFG_DMA_128,
+};
+
/*
* mei_cfg_list - A list of platform platform specific configurations.
* Note: has to be synchronized with enum mei_cfg_idx.
@@ -1433,6 +1445,7 @@ static const struct mei_cfg *const mei_cfg_list[] = {
[MEI_ME_PCH_CPT_PBG_CFG] = &mei_me_pch_cpt_pbg_cfg,
[MEI_ME_PCH8_CFG] = &mei_me_pch8_cfg,
[MEI_ME_PCH8_SPS_CFG] = &mei_me_pch8_sps_cfg,
+ [MEI_ME_PCH12_CFG] = &mei_me_pch12_cfg,
};
const struct mei_cfg *mei_me_get_cfg(kernel_ulong_t idx)
diff --git a/drivers/misc/mei/hw-me.h b/drivers/misc/mei/hw-me.h
index 0c6fe71d1212..bbcc5fc106cd 100644
--- a/drivers/misc/mei/hw-me.h
+++ b/drivers/misc/mei/hw-me.h
@@ -31,10 +31,12 @@
*
* @fw_status: FW status
* @quirk_probe: device exclusion quirk
+ * @dma_size: device DMA buffers size
*/
struct mei_cfg {
const struct mei_fw_status fw_status;
bool (*quirk_probe)(struct pci_dev *pdev);
+ size_t dma_size[DMA_DSCR_NUM];
};
@@ -80,6 +82,7 @@ struct mei_me_hw {
* @MEI_ME_PCH8_SPS_CFG: Platform Controller Hub Gen8 and newer
* servers platforms with quirk for
* SPS firmware exclusion.
+ * @MEI_ME_PCH12_CFG: Platform Controller Hub Gen12 and newer
* @MEI_ME_NUM_CFG:Upper Sentinel.
*/
enum mei_cfg_idx {
@@ -90,6 +93,7 @@ enum mei_cfg_idx {
MEI_ME_PCH_CPT_PBG_CFG,
MEI_ME_PCH8_CFG,
MEI_ME_PCH8_SPS_CFG,
+ MEI_ME_PCH12_CFG,
MEI_ME_NUM_CFG,
};
--
2.14.4
[char-misc-next 11/12] mei: bump hbm version to 2.1
From: Alexander Usyskin Bump HBM version to 2.1 to indicate DMA transfer support. Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler --- drivers/misc/mei/hw.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/misc/mei/hw.h b/drivers/misc/mei/hw.h index acbccb8dba34..2b7f7677f8cc 100644 --- a/drivers/misc/mei/hw.h +++ b/drivers/misc/mei/hw.h @@ -35,7 +35,7 @@ /* * MEI Version */ -#define HBM_MINOR_VERSION 0 +#define HBM_MINOR_VERSION 1 #define HBM_MAJOR_VERSION 2 /* -- 2.14.4
[char-misc-next 12/12] mei: me: mark CNP devices as having dma support
From: Alexander Usyskin
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/pci-me.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c
index ea4e152270a3..73ace2d59dea 100644
--- a/drivers/misc/mei/pci-me.c
+++ b/drivers/misc/mei/pci-me.c
@@ -98,9 +98,9 @@ static const struct pci_device_id mei_me_pci_tbl[] = {
{MEI_PCI_DEVICE(MEI_DEV_ID_KBP, MEI_ME_PCH8_CFG)},
{MEI_PCI_DEVICE(MEI_DEV_ID_KBP_2, MEI_ME_PCH8_CFG)},
- {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_LP, MEI_ME_PCH8_CFG)},
+ {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_LP, MEI_ME_PCH12_CFG)},
{MEI_PCI_DEVICE(MEI_DEV_ID_CNP_LP_4, MEI_ME_PCH8_CFG)},
- {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_H, MEI_ME_PCH8_CFG)},
+ {MEI_PCI_DEVICE(MEI_DEV_ID_CNP_H, MEI_ME_PCH12_CFG)},
{MEI_PCI_DEVICE(MEI_DEV_ID_CNP_H_4, MEI_ME_PCH8_CFG)},
/* required last entry */
--
2.14.4
[char-misc-next 04/12] mei: restrict dma ring support to hbm version 2.1
Only a firmware with version 2.1 and above supports dma ring feature.
Signed-off-by: Tomas Winkler
Signed-off-by: Alexander Usyskin
---
drivers/misc/mei/debugfs.c | 2 ++
drivers/misc/mei/hbm.c | 6 ++
drivers/misc/mei/hw.h | 6 ++
drivers/misc/mei/mei_dev.h | 2 ++
4 files changed, 16 insertions(+)
diff --git a/drivers/misc/mei/debugfs.c b/drivers/misc/mei/debugfs.c
index c815da91089c..7b5df8fd6c5a 100644
--- a/drivers/misc/mei/debugfs.c
+++ b/drivers/misc/mei/debugfs.c
@@ -183,6 +183,8 @@ static ssize_t mei_dbgfs_read_devstate(struct file *fp,
char __user *ubuf,
dev->hbm_f_fa_supported);
pos += scnprintf(buf + pos, bufsz - pos, "\tOS: %01d\n",
dev->hbm_f_os_supported);
+ pos += scnprintf(buf + pos, bufsz - pos, "\tDR: %01d\n",
+dev->hbm_f_dr_supported);
}
pos += scnprintf(buf + pos, bufsz - pos, "pg: %s, %s\n",
diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c
index b0086c4aefe4..09e233d4c0de 100644
--- a/drivers/misc/mei/hbm.c
+++ b/drivers/misc/mei/hbm.c
@@ -1007,6 +1007,12 @@ static void mei_hbm_config_features(struct mei_device
*dev)
/* OS ver message Support */
if (dev->version.major_version >= HBM_MAJOR_VERSION_OS)
dev->hbm_f_os_supported = 1;
+
+ /* DMA Ring Support */
+ if (dev->version.major_version > HBM_MAJOR_VERSION_DR ||
+ (dev->version.major_version == HBM_MAJOR_VERSION_DR &&
+dev->version.minor_version >= HBM_MINOR_VERSION_DR))
+ dev->hbm_f_dr_supported = 1;
}
/**
diff --git a/drivers/misc/mei/hw.h b/drivers/misc/mei/hw.h
index 5fb8844a6db5..65655925791a 100644
--- a/drivers/misc/mei/hw.h
+++ b/drivers/misc/mei/hw.h
@@ -80,6 +80,12 @@
#define HBM_MINOR_VERSION_OS 0
#define HBM_MAJOR_VERSION_OS 2
+/*
+ * MEI version with dma ring support
+ */
+#define HBM_MINOR_VERSION_DR 1
+#define HBM_MAJOR_VERSION_DR 2
+
/* Host bus message command opcode */
#define MEI_HBM_CMD_OP_MSK 0x7f
/* Host bus message command RESPONSE */
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index 975afaa38a66..377397e1b5a5 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -418,6 +418,7 @@ struct mei_fw_version {
* @hbm_f_fa_supported : hbm feature fixed address client
* @hbm_f_ie_supported : hbm feature immediate reply to enum request
* @hbm_f_os_supported : hbm feature support OS ver message
+ * @hbm_f_dr_supported : hbm feature dma ring supported
*
* @fw_ver : FW versions
*
@@ -495,6 +496,7 @@ struct mei_device {
unsigned int hbm_f_fa_supported:1;
unsigned int hbm_f_ie_supported:1;
unsigned int hbm_f_os_supported:1;
+ unsigned int hbm_f_dr_supported:1;
struct mei_fw_version fw_ver[MEI_MAX_FW_VER_BLOCKS];
--
2.14.4
[char-misc-next 10/12] mei: dma ring: implement transmit flow
Implement a circular buffer on allocated system memory. Read and write
indices are stored on the control block which is also shared between the
device and the host.
Two new functions are exported from the DMA module: mei_dma_ring_write,
and mei_dma_ring_empty_slots. The former simply copy a packet on the TX
DMA circular buffer and later, returns the number of empty slots on the
TX DMA circular buffer.
Signed-off-by: Tomas Winkler
Signed-off-by: Alexander Usyskin
---
drivers/misc/mei/client.c | 56 ++--
drivers/misc/mei/dma-ring.c | 91 +
drivers/misc/mei/mei_dev.h | 2 +
3 files changed, 138 insertions(+), 11 deletions(-)
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index 859a5e1469c9..9dbf2ac1ca4b 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -1573,10 +1573,13 @@ int mei_cl_irq_write(struct mei_cl *cl, struct
mei_cl_cb *cb,
struct mei_msg_hdr mei_hdr;
size_t hdr_len = sizeof(mei_hdr);
size_t len;
- size_t hbuf_len;
+ size_t hbuf_len, dr_len;
int hbuf_slots;
+ u32 dr_slots;
+ u32 dma_len;
int rets;
bool first_chunk;
+ const void *data;
if (WARN_ON(!cl || !cl->dev))
return -ENODEV;
@@ -1597,6 +1600,7 @@ int mei_cl_irq_write(struct mei_cl *cl, struct mei_cl_cb
*cb,
}
len = buf->size - cb->buf_idx;
+ data = buf->data + cb->buf_idx;
hbuf_slots = mei_hbuf_empty_slots(dev);
if (hbuf_slots < 0) {
rets = -EOVERFLOW;
@@ -1604,6 +1608,8 @@ int mei_cl_irq_write(struct mei_cl *cl, struct mei_cl_cb
*cb,
}
hbuf_len = mei_slots2data(hbuf_slots);
+ dr_slots = mei_dma_ring_empty_slots(dev);
+ dr_len = mei_slots2data(dr_slots);
mei_msg_hdr_init(&mei_hdr, cb);
@@ -1614,23 +1620,32 @@ int mei_cl_irq_write(struct mei_cl *cl, struct
mei_cl_cb *cb,
if (len + hdr_len <= hbuf_len) {
mei_hdr.length = len;
mei_hdr.msg_complete = 1;
+ } else if (dr_slots && hbuf_len >= hdr_len + sizeof(dma_len)) {
+ mei_hdr.dma_ring = 1;
+ if (len > dr_len)
+ len = dr_len;
+ else
+ mei_hdr.msg_complete = 1;
+
+ mei_hdr.length = sizeof(dma_len);
+ dma_len = len;
+ data = &dma_len;
} else if ((u32)hbuf_slots == mei_hbuf_depth(dev)) {
mei_hdr.length = hbuf_len - hdr_len;
} else {
return 0;
}
- cl_dbg(dev, cl, "buf: size = %zu idx = %zu\n",
- cb->buf.size, cb->buf_idx);
+ if (mei_hdr.dma_ring)
+ mei_dma_ring_write(dev, buf->data + cb->buf_idx, len);
- rets = mei_write_message(dev, &mei_hdr, hdr_len,
-buf->data + cb->buf_idx, mei_hdr.length);
+ rets = mei_write_message(dev, &mei_hdr, hdr_len, data, mei_hdr.length);
if (rets)
goto err;
cl->status = 0;
cl->writing_state = MEI_WRITING;
- cb->buf_idx += mei_hdr.length;
+ cb->buf_idx += len;
if (first_chunk) {
if (mei_cl_tx_flow_ctrl_creds_reduce(cl)) {
@@ -1665,11 +1680,13 @@ ssize_t mei_cl_write(struct mei_cl *cl, struct
mei_cl_cb *cb)
struct mei_msg_data *buf;
struct mei_msg_hdr mei_hdr;
size_t hdr_len = sizeof(mei_hdr);
- size_t len;
- size_t hbuf_len;
+ size_t len, hbuf_len, dr_len;
int hbuf_slots;
+ u32 dr_slots;
+ u32 dma_len;
ssize_t rets;
bool blocking;
+ const void *data;
if (WARN_ON(!cl || !cl->dev))
return -ENODEV;
@@ -1681,10 +1698,12 @@ ssize_t mei_cl_write(struct mei_cl *cl, struct
mei_cl_cb *cb)
buf = &cb->buf;
len = buf->size;
- blocking = cb->blocking;
cl_dbg(dev, cl, "len=%zd\n", len);
+ blocking = cb->blocking;
+ data = buf->data;
+
rets = pm_runtime_get(dev->dev);
if (rets < 0 && rets != -EINPROGRESS) {
pm_runtime_put_noidle(dev->dev);
@@ -1721,16 +1740,31 @@ ssize_t mei_cl_write(struct mei_cl *cl, struct
mei_cl_cb *cb)
}
hbuf_len = mei_slots2data(hbuf_slots);
+ dr_slots = mei_dma_ring_empty_slots(dev);
+ dr_len = mei_slots2data(dr_slots);
if (len + hdr_len <= hbuf_len) {
mei_hdr.length = len;
mei_hdr.msg_complete = 1;
+ } else if (dr_slots && hbuf_len >= hdr_len + sizeof(dma_len)) {
+ mei_hdr.dma_ring = 1;
+ if (len > dr_len)
+ len = dr_len;
+ else
+ mei_hdr.msg_complete = 1;
+
+ mei_hdr.length = sizeof(dma_len);
+ dma_len = len;
+ data = &dma_len;
} else {
[char-misc-next 07/12] mei: hbm: setup dma ring
DMA ring is allocated upon HBM handshake and the ring parameters are set
via dedicated HBM_DMA_SETUP request command. The firmware will perform
its setup and respond with a status. On failure the DMA buffers are
released.
Signed-off-by: Tomas Winkler
Signed-off-by: Alexander Usyskin
---
drivers/misc/mei/hbm.c | 87 --
drivers/misc/mei/hbm.h | 2 ++
2 files changed, 86 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c
index 09e233d4c0de..a3cdffb9ef62 100644
--- a/drivers/misc/mei/hbm.c
+++ b/drivers/misc/mei/hbm.c
@@ -65,6 +65,7 @@ const char *mei_hbm_state_str(enum mei_hbm_state state)
MEI_HBM_STATE(IDLE);
MEI_HBM_STATE(STARTING);
MEI_HBM_STATE(STARTED);
+ MEI_HBM_STATE(DR_SETUP);
MEI_HBM_STATE(ENUM_CLIENTS);
MEI_HBM_STATE(CLIENT_PROPERTIES);
MEI_HBM_STATE(STOPPED);
@@ -295,6 +296,47 @@ int mei_hbm_start_req(struct mei_device *dev)
return 0;
}
+/**
+ * mei_hbm_dma_setup_req - setup DMA request
+ *
+ * @dev: the device structure
+ *
+ * Return: 0 on success and < 0 on failure
+ */
+static int mei_hbm_dma_setup_req(struct mei_device *dev)
+{
+ struct mei_msg_hdr mei_hdr;
+ struct hbm_dma_setup_request req;
+ const size_t len = sizeof(struct hbm_dma_setup_request);
+ unsigned int i;
+ int ret;
+
+ mei_hbm_hdr(&mei_hdr, len);
+
+ memset(&req, 0, len);
+ req.hbm_cmd = MEI_HBM_DMA_SETUP_REQ_CMD;
+ for (i = 0; i < DMA_DSCR_NUM; i++) {
+ phys_addr_t paddr;
+
+ paddr = dev->dr_dscr[i].daddr;
+ req.dma_dscr[i].addr_hi = upper_32_bits(paddr);
+ req.dma_dscr[i].addr_lo = lower_32_bits(paddr);
+ req.dma_dscr[i].size = dev->dr_dscr[i].size;
+ }
+
+ ret = mei_hbm_write_message(dev, &mei_hdr, &req);
+ if (ret) {
+ dev_err(dev->dev, "dma setup request write failed: ret = %d.\n",
+ ret);
+ return ret;
+ }
+
+ dev->hbm_state = MEI_HBM_DR_SETUP;
+ dev->init_clients_timer = MEI_CLIENTS_INIT_TIMEOUT;
+ mei_schedule_stall_timer(dev);
+ return 0;
+}
+
/**
* mei_hbm_enum_clients_req - sends enumeration client request message.
*
@@ -1044,6 +1086,7 @@ int mei_hbm_dispatch(struct mei_device *dev, struct
mei_msg_hdr *hdr)
struct hbm_host_version_response *version_res;
struct hbm_props_response *props_res;
struct hbm_host_enum_response *enum_res;
+ struct hbm_dma_setup_response *dma_setup_res;
struct hbm_add_client_request *add_cl_req;
int ret;
@@ -1108,14 +1151,52 @@ int mei_hbm_dispatch(struct mei_device *dev, struct
mei_msg_hdr *hdr)
return -EPROTO;
}
- if (mei_hbm_enum_clients_req(dev)) {
- dev_err(dev->dev, "hbm: start: failed to send
enumeration request\n");
- return -EIO;
+ if (dev->hbm_f_dr_supported) {
+ if (mei_dmam_ring_alloc(dev))
+ dev_info(dev->dev, "running w/o dma ring\n");
+ if (mei_dma_ring_is_allocated(dev)) {
+ if (mei_hbm_dma_setup_req(dev))
+ return -EIO;
+
+ wake_up(&dev->wait_hbm_start);
+ break;
+ }
}
+ dev->hbm_f_dr_supported = 0;
+ mei_dmam_ring_free(dev);
+
+ if (mei_hbm_enum_clients_req(dev))
+ return -EIO;
+
wake_up(&dev->wait_hbm_start);
break;
+ case MEI_HBM_DMA_SETUP_RES_CMD:
+ dev_dbg(dev->dev, "hbm: dma setup response: message
received.\n");
+
+ dev->init_clients_timer = 0;
+
+ if (dev->hbm_state != MEI_HBM_DR_SETUP) {
+ dev_err(dev->dev, "hbm: dma setup response: state
mismatch, [%d, %d]\n",
+ dev->dev_state, dev->hbm_state);
+ return -EPROTO;
+ }
+
+ dma_setup_res = (struct hbm_dma_setup_response *)mei_msg;
+
+ if (dma_setup_res->status) {
+ dev_info(dev->dev, "hbm: dma setup response: failure =
%d %s\n",
+dma_setup_res->status,
+mei_hbm_status_str(dma_setup_res->status));
+ dev->hbm_f_dr_supported = 0;
+ mei_dmam_ring_free(dev);
+ }
+
+ if (mei_hbm_enum_clients_req(dev))
+ return -EIO;
+ break;
+
case CLIENT_CONNECT_RES_CMD:
dev_dbg(dev->dev, "hbm: client connect response: message
received.\n");
mei_hbm_cl_res(dev, cl_cmd, MEI_FO
[char-misc-next 08/12] mei: hw: add dma ring control block
The DMA ring control block contains write and read
indices for host and device circular buffers.
Signed-off-by: Tomas Winkler
Signed-off-by: Alexander Usyskin
---
drivers/misc/mei/dma-ring.c | 21 +
drivers/misc/mei/hbm.c | 2 ++
drivers/misc/mei/hw.h | 23 +++
drivers/misc/mei/mei_dev.h | 1 +
4 files changed, 47 insertions(+)
diff --git a/drivers/misc/mei/dma-ring.c b/drivers/misc/mei/dma-ring.c
index 368012116196..70901319534e 100644
--- a/drivers/misc/mei/dma-ring.c
+++ b/drivers/misc/mei/dma-ring.c
@@ -101,3 +101,24 @@ bool mei_dma_ring_is_allocated(struct mei_device *dev)
{
return !!dev->dr_dscr[DMA_DSCR_HOST].vaddr;
}
+
+static inline
+struct hbm_dma_ring_ctrl *mei_dma_ring_ctrl(struct mei_device *dev)
+{
+ return (struct hbm_dma_ring_ctrl *)dev->dr_dscr[DMA_DSCR_CTRL].vaddr;
+}
+
+/**
+ * mei_dma_ring_reset - reset the dma control block
+ *
+ * @dev: mei device
+ */
+void mei_dma_ring_reset(struct mei_device *dev)
+{
+ struct hbm_dma_ring_ctrl *ctrl = mei_dma_ring_ctrl(dev);
+
+ if (!ctrl)
+ return;
+
+ memset(ctrl, 0, sizeof(*ctrl));
+}
diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c
index a3cdffb9ef62..f15d44bda28e 100644
--- a/drivers/misc/mei/hbm.c
+++ b/drivers/misc/mei/hbm.c
@@ -324,6 +324,8 @@ static int mei_hbm_dma_setup_req(struct mei_device *dev)
req.dma_dscr[i].size = dev->dr_dscr[i].size;
}
+ mei_dma_ring_reset(dev);
+
ret = mei_hbm_write_message(dev, &mei_hdr, &req);
if (ret) {
dev_err(dev->dev, "dma setup request write failed: ret = %d.\n",
diff --git a/drivers/misc/mei/hw.h b/drivers/misc/mei/hw.h
index 65655925791a..4f09bbcdbc2a 100644
--- a/drivers/misc/mei/hw.h
+++ b/drivers/misc/mei/hw.h
@@ -512,4 +512,27 @@ struct hbm_dma_setup_response {
u8 reserved[2];
} __packed;
+/**
+ * struct mei_dma_ring_ctrl - dma ring control block
+ *
+ * @hbuf_wr_idx: host circular buffer write index in slots
+ * @reserved1: reserved for alignment
+ * @hbuf_rd_idx: host circular buffer read index in slots
+ * @reserved2: reserved for alignment
+ * @dbuf_wr_idx: device circular buffer write index in slots
+ * @reserved3: reserved for alignment
+ * @dbuf_rd_idx: device circular buffer read index in slots
+ * @reserved4: reserved for alignment
+ */
+struct hbm_dma_ring_ctrl {
+ u32 hbuf_wr_idx;
+ u32 reserved1;
+ u32 hbuf_rd_idx;
+ u32 reserved2;
+ u32 dbuf_wr_idx;
+ u32 reserved3;
+ u32 dbuf_rd_idx;
+ u32 reserved4;
+} __packed;
+
#endif
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index a6796e3f712b..033b5eff8e59 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -597,6 +597,7 @@ void mei_cancel_work(struct mei_device *dev);
int mei_dmam_ring_alloc(struct mei_device *dev);
void mei_dmam_ring_free(struct mei_device *dev);
bool mei_dma_ring_is_allocated(struct mei_device *dev);
+void mei_dma_ring_reset(struct mei_device *dev);
/*
* MEI interrupt functions prototype
--
2.14.4
[char-misc-next 00/12] mei: Add DMA ring
This series adds an alternative method for transferring data between the mei driver and the device via a DMA ring. The DMA ring allows transferring data in bigger chunks, up to 128K, than the HW ring 512B. The actual sizes depend on particular MEI generations. The HW ring is faster for packets that fits into the HW ring while a packet that would require fragmentation is faster to send via the DMA ring. Alexander Usyskin (3): mei: define dma ring buffer sizes for PCH12 HW and newer mei: bump hbm version to 2.1 mei: me: mark CNP devices as having dma support Tomas Winkler (9): mei: add support for variable length mei headers. mei: hbm: define dma ring setup protocol mei: hbm: introduce dma bit in the message header mei: restrict dma ring support to hbm version 2.1 mei: dma ring buffers allocation mei: hbm: setup dma ring mei: hw: add dma ring control block mei: dma ring: implement rx circular buffer logic mei: dma ring: implement transmit flow drivers/misc/mei/Makefile| 1 + drivers/misc/mei/client.c| 84 + drivers/misc/mei/debugfs.c | 2 + drivers/misc/mei/dma-ring.c | 278 +++ drivers/misc/mei/hbm.c | 126 ++-- drivers/misc/mei/hbm.h | 2 + drivers/misc/mei/hw-me.c | 53 ++--- drivers/misc/mei/hw-me.h | 4 + drivers/misc/mei/hw-txe.c| 42 +++ drivers/misc/mei/hw.h| 98 ++- drivers/misc/mei/init.c | 2 +- drivers/misc/mei/interrupt.c | 45 --- drivers/misc/mei/mei_dev.h | 57 +++-- drivers/misc/mei/pci-me.c| 4 +- 14 files changed, 700 insertions(+), 98 deletions(-) create mode 100644 drivers/misc/mei/dma-ring.c -- 2.14.4
[char-misc-next 03/12] mei: hbm: introduce dma bit in the message header
Add dma_ring bit in the mei message header for conveying
that the message data itself are on the dma ring.
Signed-off-by: Tomas Winkler
Signed-off-by: Alexander Usyskin
---
drivers/misc/mei/client.c | 1 +
drivers/misc/mei/hbm.c | 1 +
drivers/misc/mei/hw.h | 16
drivers/misc/mei/mei_dev.h | 4 ++--
4 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index 0a9173827461..4ab6251d418e 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -1551,6 +1551,7 @@ static void mei_msg_hdr_init(struct mei_msg_hdr *mei_hdr,
struct mei_cl_cb *cb)
mei_hdr->length = 0;
mei_hdr->reserved = 0;
mei_hdr->msg_complete = 0;
+ mei_hdr->dma_ring = 0;
mei_hdr->internal = cb->internal;
}
diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c
index 8b3fd9ff6566..b0086c4aefe4 100644
--- a/drivers/misc/mei/hbm.c
+++ b/drivers/misc/mei/hbm.c
@@ -145,6 +145,7 @@ static inline void mei_hbm_hdr(struct mei_msg_hdr *hdr,
size_t length)
hdr->me_addr = 0;
hdr->length = length;
hdr->msg_complete = 1;
+ hdr->dma_ring = 0;
hdr->reserved = 0;
hdr->internal = 0;
}
diff --git a/drivers/misc/mei/hw.h b/drivers/misc/mei/hw.h
index 76fb502e6f71..5fb8844a6db5 100644
--- a/drivers/misc/mei/hw.h
+++ b/drivers/misc/mei/hw.h
@@ -190,19 +190,27 @@ enum mei_cl_disconnect_status {
MEI_CL_DISCONN_SUCCESS = MEI_HBMS_SUCCESS
};
-/*
- * MEI BUS Interface Section
+/**
+ * struct mei_msg_hdr - MEI BUS Interface Section
+ *
+ * @me_addr: device address
+ * @host_addr: host address
+ * @length: message length
+ * @reserved: reserved
+ * @dma_ring: message is on dma ring
+ * @internal: message is internal
+ * @msg_complete: last packet of the message
*/
struct mei_msg_hdr {
u32 me_addr:8;
u32 host_addr:8;
u32 length:9;
- u32 reserved:5;
+ u32 reserved:4;
+ u32 dma_ring:1;
u32 internal:1;
u32 msg_complete:1;
} __packed;
-
struct mei_bus_message {
u8 hbm_cmd;
u8 data[0];
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index 06fb5fc67fe9..975afaa38a66 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -714,10 +714,10 @@ static inline void mei_dbgfs_deregister(struct mei_device
*dev) {}
int mei_register(struct mei_device *dev, struct device *parent);
void mei_deregister(struct mei_device *dev);
-#define MEI_HDR_FMT "hdr:host=%02d me=%02d len=%d internal=%1d comp=%1d"
+#define MEI_HDR_FMT "hdr:host=%02d me=%02d len=%d dma=%1d internal=%1d
comp=%1d"
#define MEI_HDR_PRM(hdr) \
(hdr)->host_addr, (hdr)->me_addr, \
- (hdr)->length, (hdr)->internal, (hdr)->msg_complete
+ (hdr)->length, (hdr)->dma_ring, (hdr)->internal, (hdr)->msg_complete
ssize_t mei_fw_status2str(struct mei_fw_status *fw_sts, char *buf, size_t len);
/**
--
2.14.4
[char-misc-next 06/12] mei: dma ring buffers allocation
Allocate DMA ring buffers from managed coherent memory.
Signed-off-by: Tomas Winkler
Signed-off-by: Alexander Usyskin
---
drivers/misc/mei/Makefile | 1 +
drivers/misc/mei/dma-ring.c | 103
drivers/misc/mei/hw-me.c| 6 +++
drivers/misc/mei/mei_dev.h | 20 +
4 files changed, 130 insertions(+)
create mode 100644 drivers/misc/mei/dma-ring.c
diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile
index cd6825afa8e1..d9215fc4e499 100644
--- a/drivers/misc/mei/Makefile
+++ b/drivers/misc/mei/Makefile
@@ -9,6 +9,7 @@ mei-objs += hbm.o
mei-objs += interrupt.o
mei-objs += client.o
mei-objs += main.o
+mei-objs += dma-ring.o
mei-objs += bus.o
mei-objs += bus-fixup.o
mei-$(CONFIG_DEBUG_FS) += debugfs.o
diff --git a/drivers/misc/mei/dma-ring.c b/drivers/misc/mei/dma-ring.c
new file mode 100644
index ..368012116196
--- /dev/null
+++ b/drivers/misc/mei/dma-ring.c
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0
+/*
+ * Copyright(c) 2016 - 2018 Intel Corporation. All rights reserved.
+ */
+#include
+#include
+
+#include "mei_dev.h"
+
+/**
+ * mei_dmam_dscr_alloc - allocate a managed coherent buffer
+ * for the dma descriptor
+ *
+ * @dev: mei_device
+ * @dscr: dma descriptor
+ *
+ * Return: 0 on success or zero allocation request
+ * -EINVAL if size is not power of 2
+ * -ENOMEM of allocation has failed
+ */
+static int mei_dmam_dscr_alloc(struct mei_device *dev,
+ struct mei_dma_dscr *dscr)
+{
+ if (!dscr->size)
+ return 0;
+
+ if (WARN_ON(!is_power_of_2(dscr->size)))
+ return -EINVAL;
+
+ if (dscr->vaddr)
+ return 0;
+
+ dscr->vaddr = dmam_alloc_coherent(dev->dev, dscr->size, &dscr->daddr,
+ GFP_KERNEL);
+ if (!dscr->vaddr)
+ return -ENOMEM;
+
+ return 0;
+}
+
+/**
+ * mei_dmam_dscr_free - free a managed coherent buffer
+ * from the dma descriptor
+ *
+ * @dev: mei_device
+ * @dscr: dma descriptor
+ */
+static void mei_dmam_dscr_free(struct mei_device *dev,
+ struct mei_dma_dscr *dscr)
+{
+ if (!dscr->vaddr)
+ return;
+
+ dmam_free_coherent(dev->dev, dscr->size, dscr->vaddr, dscr->daddr);
+ dscr->vaddr = NULL;
+}
+
+/**
+ * mei_dmam_ring_free - free dma ring buffers
+ *
+ * @dev: mei device
+ */
+void mei_dmam_ring_free(struct mei_device *dev)
+{
+ int i;
+
+ for (i = 0; i < DMA_DSCR_NUM; i++)
+ mei_dmam_dscr_free(dev, &dev->dr_dscr[i]);
+}
+
+/**
+ * mei_dmam_ring_alloc - allocate dma ring buffers
+ *
+ * @dev: mei device
+ *
+ * Return: -ENOMEM on allocation failure 0 otherwise
+ */
+int mei_dmam_ring_alloc(struct mei_device *dev)
+{
+ int i;
+
+ for (i = 0; i < DMA_DSCR_NUM; i++)
+ if (mei_dmam_dscr_alloc(dev, &dev->dr_dscr[i]))
+ goto err;
+
+ return 0;
+
+err:
+ mei_dmam_ring_free(dev);
+ return -ENOMEM;
+}
+
+/**
+ * mei_dma_ring_is_allocated - check if dma ring is allocated
+ *
+ * @dev: mei device
+ *
+ * Return: true if dma ring is allocated
+ */
+bool mei_dma_ring_is_allocated(struct mei_device *dev)
+{
+ return !!dev->dr_dscr[DMA_DSCR_HOST].vaddr;
+}
diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index 0759c3a668de..3fbbadfa2ae1 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -1471,15 +1471,21 @@ struct mei_device *mei_me_dev_init(struct pci_dev *pdev,
{
struct mei_device *dev;
struct mei_me_hw *hw;
+ int i;
dev = devm_kzalloc(&pdev->dev, sizeof(struct mei_device) +
sizeof(struct mei_me_hw), GFP_KERNEL);
if (!dev)
return NULL;
+
hw = to_me_hw(dev);
+ for (i = 0; i < DMA_DSCR_NUM; i++)
+ dev->dr_dscr[i].size = cfg->dma_size[i];
+
mei_device_init(dev, &pdev->dev, &mei_me_hw_ops);
hw->cfg = cfg;
+
return dev;
}
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index 377397e1b5a5..a6796e3f712b 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -122,6 +122,19 @@ struct mei_msg_data {
unsigned char *data;
};
+/**
+ * struct mei_dma_dscr - dma address descriptor
+ *
+ * @vaddr: dma buffer virtual address
+ * @daddr: dma buffer physical address
+ * @size : dma buffer size
+ */
+struct mei_dma_dscr {
+ void *vaddr;
+ dma_addr_t daddr;
+ size_t size;
+};
+
/* Maximum number of processed FW status registers */
#define MEI_FW_STATUS_MAX 6
/* Minimal buffer for FW status string (8 bytes in dw + space or '\0') */
@@ -409,6 +422,7 @@ struct mei_fw_version {
* @rd_msg_hdr : read message header storage
*
* @hbuf_is_ready : query if the host host/write buffer is ready
+ * @dr_dscr: DMA ring descriptors: TX
[char-misc-next 01/12] mei: add support for variable length mei headers.
Remove header size knowledge from me and txe hw layers,
this requires to change the write handler to accept
header and its length as well as data and its length.
HBM messages are fixed to use basic header, hence we add mei_hbm2slots()
that converts HBM message length and mei message header,
while mei_data2slots() converts data length directly to the slots.
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/client.c| 31 ++-
drivers/misc/mei/hbm.c | 30 ++
drivers/misc/mei/hw-me.c | 34 --
drivers/misc/mei/hw-txe.c| 42 +-
drivers/misc/mei/interrupt.c | 4 ++--
drivers/misc/mei/mei_dev.h | 25 +++--
6 files changed, 102 insertions(+), 64 deletions(-)
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index 207d2f5d5702..0a9173827461 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -863,7 +863,7 @@ int mei_cl_irq_disconnect(struct mei_cl *cl, struct
mei_cl_cb *cb,
int slots;
int ret;
- msg_slots = mei_data2slots(sizeof(struct hbm_client_connect_request));
+ msg_slots = mei_hbm2slots(sizeof(struct hbm_client_connect_request));
slots = mei_hbuf_empty_slots(dev);
if (slots < 0)
return -EOVERFLOW;
@@ -1055,11 +1055,10 @@ int mei_cl_irq_connect(struct mei_cl *cl, struct
mei_cl_cb *cb,
int slots;
int rets;
- msg_slots = mei_data2slots(sizeof(struct hbm_client_connect_request));
-
if (mei_cl_is_other_connecting(cl))
return 0;
+ msg_slots = mei_hbm2slots(sizeof(struct hbm_client_connect_request));
slots = mei_hbuf_empty_slots(dev);
if (slots < 0)
return -EOVERFLOW;
@@ -1299,7 +1298,7 @@ int mei_cl_irq_notify(struct mei_cl *cl, struct mei_cl_cb
*cb,
int ret;
bool request;
- msg_slots = mei_data2slots(sizeof(struct hbm_client_connect_request));
+ msg_slots = mei_hbm2slots(sizeof(struct hbm_client_connect_request));
slots = mei_hbuf_empty_slots(dev);
if (slots < 0)
return -EOVERFLOW;
@@ -1571,6 +1570,7 @@ int mei_cl_irq_write(struct mei_cl *cl, struct mei_cl_cb
*cb,
struct mei_device *dev;
struct mei_msg_data *buf;
struct mei_msg_hdr mei_hdr;
+ size_t hdr_len = sizeof(mei_hdr);
size_t len;
size_t hbuf_len;
int hbuf_slots;
@@ -1601,7 +1601,8 @@ int mei_cl_irq_write(struct mei_cl *cl, struct mei_cl_cb
*cb,
rets = -EOVERFLOW;
goto err;
}
- hbuf_len = mei_slots2data(hbuf_slots) - sizeof(struct mei_msg_hdr);
+
+ hbuf_len = mei_slots2data(hbuf_slots);
mei_msg_hdr_init(&mei_hdr, cb);
@@ -1609,11 +1610,11 @@ int mei_cl_irq_write(struct mei_cl *cl, struct
mei_cl_cb *cb,
* Split the message only if we can write the whole host buffer
* otherwise wait for next time the host buffer is empty.
*/
- if (hbuf_len >= len) {
+ if (len + hdr_len <= hbuf_len) {
mei_hdr.length = len;
mei_hdr.msg_complete = 1;
} else if ((u32)hbuf_slots == mei_hbuf_depth(dev)) {
- mei_hdr.length = hbuf_len;
+ mei_hdr.length = hbuf_len - hdr_len;
} else {
return 0;
}
@@ -1621,7 +1622,8 @@ int mei_cl_irq_write(struct mei_cl *cl, struct mei_cl_cb
*cb,
cl_dbg(dev, cl, "buf: size = %zu idx = %zu\n",
cb->buf.size, cb->buf_idx);
- rets = mei_write_message(dev, &mei_hdr, buf->data + cb->buf_idx);
+ rets = mei_write_message(dev, &mei_hdr, hdr_len,
+buf->data + cb->buf_idx, mei_hdr.length);
if (rets)
goto err;
@@ -1661,6 +1663,7 @@ ssize_t mei_cl_write(struct mei_cl *cl, struct mei_cl_cb
*cb)
struct mei_device *dev;
struct mei_msg_data *buf;
struct mei_msg_hdr mei_hdr;
+ size_t hdr_len = sizeof(mei_hdr);
size_t len;
size_t hbuf_len;
int hbuf_slots;
@@ -1716,15 +1719,17 @@ ssize_t mei_cl_write(struct mei_cl *cl, struct
mei_cl_cb *cb)
goto out;
}
- hbuf_len = mei_slots2data(hbuf_slots) - sizeof(struct mei_msg_hdr);
- if (hbuf_len >= len) {
+ hbuf_len = mei_slots2data(hbuf_slots);
+
+ if (len + hdr_len <= hbuf_len) {
mei_hdr.length = len;
mei_hdr.msg_complete = 1;
} else {
- mei_hdr.length = hbuf_len;
+ mei_hdr.length = hbuf_len - hdr_len;
}
- rets = mei_write_message(dev, &mei_hdr, buf->data);
+ rets = mei_write_message(dev, &mei_hdr, hdr_len,
+buf->data, mei_hdr.length);
if (rets)
goto err;
@@ -1761,7 +1766,7 @@ ssize_t mei_cl_write(struct m
[char-misc-next 02/12] mei: hbm: define dma ring setup protocol
The protocol defines how to setup an I/O ring on top of host
memory to utilize the device DMA engine for faster transport.
Three memory buffers are allocated.
A Host circular buffer for from the Host to Device communication.
A Device circular buffer for from Device to the Host communication.
And finally a Control block where the pointers for the both
circular buffers are managed.
Signed-off-by: Tomas Winkler
Signed-off-by: Alexander Usyskin
---
drivers/misc/mei/hw.h | 49 +
1 file changed, 49 insertions(+)
diff --git a/drivers/misc/mei/hw.h b/drivers/misc/mei/hw.h
index 3b325d955fbe..76fb502e6f71 100644
--- a/drivers/misc/mei/hw.h
+++ b/drivers/misc/mei/hw.h
@@ -122,6 +122,9 @@
#define MEI_HBM_NOTIFY_RES_CMD 0x90
#define MEI_HBM_NOTIFICATION_CMD0x11
+#define MEI_HBM_DMA_SETUP_REQ_CMD 0x12
+#define MEI_HBM_DMA_SETUP_RES_CMD 0x92
+
/*
* MEI Stop Reason
* used by hbm_host_stop_request.reason
@@ -449,4 +452,50 @@ struct hbm_notification {
u8 reserved[1];
} __packed;
+/**
+ * struct hbm_dma_mem_dscr - dma ring
+ *
+ * @addr_hi: the high 32bits of 64 bit address
+ * @addr_lo: the low 32bits of 64 bit address
+ * @size : size in bytes (must be power of 2)
+ */
+struct hbm_dma_mem_dscr {
+ u32 addr_hi;
+ u32 addr_lo;
+ u32 size;
+} __packed;
+
+enum {
+ DMA_DSCR_HOST = 0,
+ DMA_DSCR_DEVICE = 1,
+ DMA_DSCR_CTRL = 2,
+ DMA_DSCR_NUM,
+};
+
+/**
+ * struct hbm_dma_setup_request - dma setup request
+ *
+ * @hbm_cmd: bus message command header
+ * @reserved: reserved for alignment
+ * @dma_dscr: dma descriptor for HOST, DEVICE, and CTRL
+ */
+struct hbm_dma_setup_request {
+ u8 hbm_cmd;
+ u8 reserved[3];
+ struct hbm_dma_mem_dscr dma_dscr[DMA_DSCR_NUM];
+} __packed;
+
+/**
+ * struct hbm_dma_setup_response - dma setup response
+ *
+ * @hbm_cmd: bus message command header
+ * @status: 0 on success; otherwise DMA setup failed.
+ * @reserved: reserved for alignment
+ */
+struct hbm_dma_setup_response {
+ u8 hbm_cmd;
+ u8 status;
+ u8 reserved[2];
+} __packed;
+
#endif
--
2.14.4
[char-misc-next 09/12] mei: dma ring: implement rx circular buffer logic
Implement circular buffer protocol over receive dma
buffer. Add extension to the mei message header that holds
length of the buffer on the dma buffer.
Signed-off-by: Tomas Winkler
Signed-off-by: Alexander Usyskin
---
drivers/misc/mei/client.c| 2 +-
drivers/misc/mei/dma-ring.c | 63
drivers/misc/mei/hw.h| 4 +++
drivers/misc/mei/init.c | 2 +-
drivers/misc/mei/interrupt.c | 41 +++-
drivers/misc/mei/mei_dev.h | 3 ++-
6 files changed, 100 insertions(+), 15 deletions(-)
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index 4ab6251d418e..859a5e1469c9 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -478,7 +478,7 @@ struct mei_cl_cb *mei_cl_alloc_cb(struct mei_cl *cl, size_t
length,
if (length == 0)
return cb;
- cb->buf.data = kmalloc(length, GFP_KERNEL);
+ cb->buf.data = kmalloc(roundup(length, MEI_SLOT_SIZE), GFP_KERNEL);
if (!cb->buf.data) {
mei_io_cb_free(cb);
return NULL;
diff --git a/drivers/misc/mei/dma-ring.c b/drivers/misc/mei/dma-ring.c
index 70901319534e..2d2ce6f4ef3b 100644
--- a/drivers/misc/mei/dma-ring.c
+++ b/drivers/misc/mei/dma-ring.c
@@ -122,3 +122,66 @@ void mei_dma_ring_reset(struct mei_device *dev)
memset(ctrl, 0, sizeof(*ctrl));
}
+
+/**
+ * mei_dma_ring_reset - copy from dma ring into buffer
+ *
+ * @dev: mei device
+ * @buf: data buffer
+ * @offset: offset in slots.
+ * @n: number of slots to copy.
+ */
+static size_t mei_dma_copy_from(struct mei_device *dev, unsigned char *buf,
+ u32 offset, u32 n)
+{
+ unsigned char *dbuf = dev->dr_dscr[DMA_DSCR_DEVICE].vaddr;
+
+ size_t b_offset = offset << 2;
+ size_t b_n = n << 2;
+
+ memcpy(buf, dbuf + b_offset, b_n);
+
+ return b_n;
+}
+
+/**
+ * mei_dma_ring_read - read data from the ring
+ *
+ * @dev: mei device
+ * @buf: buffer to read into: may be NULL in case of droping the data.
+ * @len: length to read.
+ */
+void mei_dma_ring_read(struct mei_device *dev, unsigned char *buf, u32 len)
+{
+ struct hbm_dma_ring_ctrl *ctrl = mei_dma_ring_ctrl(dev);
+ u32 dbuf_depth;
+ u32 rd_idx, rem, slots;
+
+ if (WARN_ON(!ctrl))
+ return;
+
+ dev_dbg(dev->dev, "reading from dma %u bytes\n", len);
+
+ if (!len)
+ return;
+
+ dbuf_depth = dev->dr_dscr[DMA_DSCR_DEVICE].size >> 2;
+ rd_idx = READ_ONCE(ctrl->dbuf_rd_idx) & (dbuf_depth - 1);
+ slots = mei_data2slots(len);
+
+ /* if buf is NULL we drop the packet by advancing the pointer.*/
+ if (!buf)
+ goto out;
+
+ if (rd_idx + slots > dbuf_depth) {
+ buf += mei_dma_copy_from(dev, buf, rd_idx, dbuf_depth - rd_idx);
+ rem = slots - (dbuf_depth - rd_idx);
+ rd_idx = 0;
+ } else {
+ rem = slots;
+ }
+
+ mei_dma_copy_from(dev, buf, rd_idx, rem);
+out:
+ WRITE_ONCE(ctrl->dbuf_rd_idx, ctrl->dbuf_rd_idx + slots);
+}
diff --git a/drivers/misc/mei/hw.h b/drivers/misc/mei/hw.h
index 4f09bbcdbc2a..acbccb8dba34 100644
--- a/drivers/misc/mei/hw.h
+++ b/drivers/misc/mei/hw.h
@@ -206,6 +206,7 @@ enum mei_cl_disconnect_status {
* @dma_ring: message is on dma ring
* @internal: message is internal
* @msg_complete: last packet of the message
+ * @extension: extension of the header
*/
struct mei_msg_hdr {
u32 me_addr:8;
@@ -215,8 +216,11 @@ struct mei_msg_hdr {
u32 dma_ring:1;
u32 internal:1;
u32 msg_complete:1;
+ u32 extension[0];
} __packed;
+#define MEI_MSG_HDR_MAX 2
+
struct mei_bus_message {
u8 hbm_cmd;
u8 data[0];
diff --git a/drivers/misc/mei/init.c b/drivers/misc/mei/init.c
index 4888ebc076b7..eb026e2a0537 100644
--- a/drivers/misc/mei/init.c
+++ b/drivers/misc/mei/init.c
@@ -151,7 +151,7 @@ int mei_reset(struct mei_device *dev)
mei_hbm_reset(dev);
- dev->rd_msg_hdr = 0;
+ memset(dev->rd_msg_hdr, 0, sizeof(dev->rd_msg_hdr));
if (ret) {
dev_err(dev->dev, "hw_reset failed ret = %d\n", ret);
diff --git a/drivers/misc/mei/interrupt.c b/drivers/misc/mei/interrupt.c
index 5a661cbdf2ae..055c2d89b310 100644
--- a/drivers/misc/mei/interrupt.c
+++ b/drivers/misc/mei/interrupt.c
@@ -75,6 +75,8 @@ static inline int mei_cl_hbm_equal(struct mei_cl *cl,
*/
static void mei_irq_discard_msg(struct mei_device *dev, struct mei_msg_hdr
*hdr)
{
+ if (hdr->dma_ring)
+ mei_dma_ring_read(dev, NULL, hdr->extension[0]);
/*
* no need to check for size as it is guarantied
* that length fits into rd_msg_buf
@@ -100,6 +102,7 @@ static int mei_cl_irq_read_msg(struct mei_cl *cl,
struct mei_device *dev = cl->dev;
struct mei_cl_cb *cb;
size_t buf_sz;
+ u32 length;
cb = list
Re: [PATCH] pwm: pwm-omap-dmtimer: fix probing problems by returning EPROBE_DEFER
> Am 31.07.2018 um 00:56 schrieb David Rivshin : > > On Sun, 29 Jul 2018 20:19:08 +0200 > "H. Nikolaus Schaller" wrote: > >> Hi, >> >>> Am 29.07.2018 um 20:08 schrieb Ladislav Michl : >>> >>> On Sun, Jul 29, 2018 at 08:32:41AM +0200, H. Nikolaus Schaller wrote: Hi, > Am 28.07.2018 um 22:35 schrieb Ladislav Michl : > > Hi Andreas, > > On Sat, Jul 28, 2018 at 06:59:14PM +0200, Andreas Kemnade wrote: >> I got this in the kernel log: >> [0.756042] omap-dmtimer-pwm dmtimer-pwm: dmtimer pdata structure NULL >> [0.756134] omap-dmtimer-pwm: probe of dmtimer-pwm failed with error >> -22 >> >> the probe function has to wait until omap_dm_timer_probe() in >> clocksource/timer-ti-dm.c has initialized pdata, so defer probing > > There already is a patch by David Rivshin addressing the same issue... Here it is: https://patchwork.ozlabs.org/patch/943148/ but hasn't arrived in linux-next. >>> >>> That's because there'll be v3. >>> But it is questionable if a driver should dev_info() about doing deferred probing. IMHO, it should just do it which is how Andreas' patch works. >>> >>> See here: https://patchwork.ozlabs.org/patch/949659/ >> >> Ah, I see (neither Andreas nor me did follow the original discussions >> and therefore came up independently with the same thoughts). > > Seems a lot of us have tripped over this problem at roughly the same > time. I'm hoping Thierry picks it up in time for the 4.19 merge window. Well, if possible it should be backported to 4.18 and 4.17. > >> So we will wait for the v3. > > FYI, v3 has been posted: https://patchwork.ozlabs.org/patch/951299/ > Let me know if you feel strongly enough about having no message > (vs dev_dbg) for me to spin a quick v4. I am fine with dev_dbg. > Seems like each additional > pair of eyes leans in that direction. > > Ladislav, I realized just after I sent that I forgot to add your ack > to the commit message. Sorry for the oversight. > BR and thanks, Nikolaus
Re: [PATCH 01/13] staging: gasket: core: hold reference to pci_dev while used
On Mon, Jul 30, 2018 at 11:19 PM Dmitry Torokhov wrote: > > On Sun, Jul 29, 2018 at 12:37 PM Todd Poynor wrote: > > > > From: Todd Poynor > > > > Hold a reference on the struct pci_dev while a pointer to it is held in > > the gasket data structures. > > > > Signed-off-by: Todd Poynor > > --- > > drivers/staging/gasket/gasket_core.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/staging/gasket/gasket_core.c > > b/drivers/staging/gasket/gasket_core.c > > index 2b484d067c38a..b832a4f529f27 100644 > > --- a/drivers/staging/gasket/gasket_core.c > > +++ b/drivers/staging/gasket/gasket_core.c > > @@ -488,6 +488,7 @@ static void gasket_free_dev(struct gasket_dev > > *gasket_dev) > > internal_desc->devs[gasket_dev->dev_idx] = NULL; > > mutex_unlock(&internal_desc->mutex); > > put_device(gasket_dev->dev); > > + pci_dev_put(gasket_dev->pci_dev); > > gasket_free_dev() is called only from driver PCI probe and remove > function. I can assure you that that pci_dev structure is not going > anywhere, there is no need to take this additional reference. WIll fix, thanks. > > Thanks, > Dmitry
Re: Linux 4.18-rc7
On Mon, Jul 30, 2018 at 06:01:26PM -0700, Linus Torvalds wrote: > On Mon, Jul 30, 2018 at 2:53 PM Hugh Dickins wrote: > > > > I have no problem with reverting -rc7's vma_is_anonymous() series. > > I don't think we need to revert the whole series: I think the rest are > all fairly obvious cleanups, and shouldn't really have any semantic > changes. > > It's literally only that last patch in the series that then changes > that meaning of "vm_ops". And I don't really _mind_ that last step > either, but since we don't know exactly what it was that it broke, and > we're past rc7, I don't think we really have any option but the revert > it. > > And if we revert it, I think we need to just remove the > VM_BUG_ON_VMA() that it was supposed to fix. Because I do think that > it is quite likely that the real bug is that overzealous BUG_ON(), > since I can't see any reason why anonymous mappings should be special > there. > > But I'm certainly also ok with re-visiting that commit later. I just > think that right _now_ the above is my preferred plan. > > Kirill? Considering the timing, I'm okay with reverting the last patch with dropping the VM_BUG_ON_VMA(). But in the end I would like to see strong vma_is_anonymous(). The VM_BUG_ON_VMA() is only triggerable by the test case because vma_is_anonymous() false-positive in fault path and we get anon-THP allocated in file-private mapping. I don't see immediately how this may trigger other crashes. But it definitely looks wrong. > > I'm all for deleting that VM_BUG_ON_VMA() in zap_pmd_range(), it was > > just a compromise with those who wanted to keep something there; > > I don't think we even need a WARN_ON_ONCE() now. > > So to me it looks like a historical check that simply doesn't > "normally" trigger, but there's no reason I can see why we should care > about the case it tests against. I'll think more on what could go wrong with __split_huge_pmd() called on anon-THP page without mmap_sem(). It's not yet clear cut to me. -- Kirill A. Shutemov
Re: [PATCH 1/2] leds: core: Introduce LED pattern trigger
Hi Bjorn, On 31 July 2018 at 11:54, Bjorn Andersson wrote: > On Mon 30 Jul 05:29 PDT 2018, Baolin Wang wrote: > >> Some LED controllers have support for autonomously controlling >> brightness over time, according to some preprogrammed pattern or >> function. >> >> This patch adds pattern trigger that LED device can configure the >> pattern and trigger it. >> >> Signed-off-by: Raphael Teysseyre >> Signed-off-by: Baolin Wang >> --- >> .../ABI/testing/sysfs-class-led-trigger-pattern| 21 ++ >> drivers/leds/trigger/Kconfig | 10 + >> drivers/leds/trigger/Makefile |1 + >> drivers/leds/trigger/ledtrig-pattern.c | 349 >> >> include/linux/leds.h | 19 ++ >> 5 files changed, 400 insertions(+) >> create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-pattern >> create mode 100644 drivers/leds/trigger/ledtrig-pattern.c >> >> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern >> b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern >> new file mode 100644 >> index 000..c52da34 >> --- /dev/null >> +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern >> @@ -0,0 +1,21 @@ >> +What:/sys/class/leds//pattern >> +Date:August 2018 >> +KernelVersion: 4.19 >> +Description: >> + Specify a pattern for the LED, for LED hardware that support >> + altering the brightness as a function of time. >> + >> + The pattern is given by a series of tuples, of brightness and >> + duration (ms). The LED is expected to traverse the series and >> + each brightness value for the specified duration. Duration of >> + 0 means brightness should immediately change to new value. >> + >> + The format of the pattern values should be: >> + "brightness_1 duration_1, brightness_2 duration_2, brightness_3 >> + duration_3, ...". >> + >> +What:/sys/class/leds//repeat >> +Date:August 2018 >> +KernelVersion: 4.19 >> +Description: >> + Specify a pattern repeat number. 0 means repeat indefinitely. > > If 0 means infinity, does 1 mean "repeat 1 time"? If so how would I Right. > specify that I want the pattern to run one time (i.e. 0 repetitions). If you set repeat to 1 to make the driver clear the is_indefinite flag. So when the repeat number decreases to 0, it will stop. > >> diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig >> index a2559b4..a03afcd 100644 >> --- a/drivers/leds/trigger/Kconfig >> +++ b/drivers/leds/trigger/Kconfig >> @@ -125,6 +125,16 @@ config LEDS_TRIGGER_CAMERA >> This enables direct flash/torch on/off by the driver, kernel space. >> If unsure, say Y. >> >> +config LEDS_TRIGGER_PATTERN >> + tristate "LED Pattern Trigger" >> + depends on LEDS_TRIGGERS >> + help >> + This allows LEDs blinking with an arbitrary pattern. Can be useful >> + on embedded systems with no screen to give out a status code to >> + a human. > > While the pattern mechanism could be used to communicate some message > the use cases we've seen so far is all about enabling hardware to pulse > LEDs instead of blinking them... Right. I will improve the message here. > >> + >> + If unsure, say N >> + >> config LEDS_TRIGGER_PANIC >> bool "LED Panic Trigger" >> depends on LEDS_TRIGGERS >> diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile >> index f3cfe19..c5d180e 100644 >> --- a/drivers/leds/trigger/Makefile >> +++ b/drivers/leds/trigger/Makefile >> @@ -13,3 +13,4 @@ obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT)+= >> ledtrig-transient.o >> obj-$(CONFIG_LEDS_TRIGGER_CAMERA)+= ledtrig-camera.o >> obj-$(CONFIG_LEDS_TRIGGER_PANIC) += ledtrig-panic.o >> obj-$(CONFIG_LEDS_TRIGGER_NETDEV)+= ledtrig-netdev.o >> +obj-$(CONFIG_LEDS_TRIGGER_PATTERN) += ledtrig-pattern.o >> diff --git a/drivers/leds/trigger/ledtrig-pattern.c >> b/drivers/leds/trigger/ledtrig-pattern.c >> new file mode 100644 >> index 000..b709aa1 >> --- /dev/null >> +++ b/drivers/leds/trigger/ledtrig-pattern.c >> @@ -0,0 +1,349 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> + >> +/* >> + * LED pattern trigger >> + * >> + * Idea discussed with Pavel Machek. Raphael Teysseyre implemented >> + * the first version, Baolin Wang simplified and improved the approach. > > Might be a coincidence, but parts of this patch looks pretty close to > mine... > >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +/* >> + * The "pattern" attribute contains at most PAGE_SIZE characters. Each line >> + * in this attribute is at least 4 characters long (a 1-digit number for the >> + * led brighntess, a space, a 1-digit number for the time, a semi-colon). >> + * Theref
Re: [PATCH v4 03/10] arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and Makefile
On Tue, 31 Jul 2018 06:38:00 +0100,
Erin Lo wrote:
>
> From: Ben Ho
>
> Add basic chip support for Mediatek 8183
>
> Signed-off-by: Ben Ho
> Signed-off-by: Erin Lo
> ---
> arch/arm64/boot/dts/mediatek/Makefile | 1 +
> arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 23 +
> arch/arm64/boot/dts/mediatek/mt8183.dtsi| 146
>
> 3 files changed, 170 insertions(+)
> create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> create mode 100644 arch/arm64/boot/dts/mediatek/mt8183.dtsi
>
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile
> b/arch/arm64/boot/dts/mediatek/Makefile
> index 7506b0d..a91d462 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -6,3 +6,4 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> new file mode 100644
> index 000..2a3dd5a
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright (c) 2018 MediaTek Inc.
> + * Author: Ben Ho
> + * Erin Lo
> + */
> +
> +/dts-v1/;
> +#include "mt8183.dtsi"
> +
> +/ {
> + model = "MediaTek MT8183 evaluation board";
> + compatible = "mediatek,mt8183-evb", "mediatek,mt8183";
> +
> + memory@4000 {
> + device_type = "memory";
> + reg = <0 0x4000 0 0x8000>;
> + };
> +
> + chosen {
> + stdout-path = "serial0:921600n8";
> + };
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> new file mode 100644
> index 000..1553265
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -0,0 +1,146 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Copyright (c) 2018 MediaTek Inc.
> + * Author: Ben Ho
> + * Erin Lo
> + */
> +
> +#include
> +#include
> +
> +/ {
> + compatible = "mediatek,mt8183";
> + interrupt-parent = <&sysirq>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu-map {
> + cluster0 {
> + core0 {
> + cpu = <&cpu0>;
> + };
> + core1 {
> + cpu = <&cpu1>;
> + };
> + core2 {
> + cpu = <&cpu2>;
> + };
> + core3 {
> + cpu = <&cpu3>;
> + };
> + };
> +
> + cluster1 {
> + core0 {
> + cpu = <&cpu4>;
> + };
> + core1 {
> + cpu = <&cpu5>;
> + };
> + core2 {
> + cpu = <&cpu6>;
> + };
> + core3 {
> + cpu = <&cpu7>;
> + };
> + };
> + };
> +
> + cpu0: cpu@000 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x000>;
> + enable-method = "psci";
> + };
> +
> + cpu1: cpu@001 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x001>;
> + enable-method = "psci";
> + };
> +
> + cpu2: cpu@002 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x002>;
> + enable-method = "psci";
> + };
> +
> + cpu3: cpu@003 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x003>;
> + enable-method = "psci";
> + };
> +
> + cpu4: cpu@100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a73";
> + reg = <0x100>;
> + enable-method = "psci";
> + };
> +
> + cpu5: cpu@101 {
> + device_type = "cpu";
> + compatible = "arm,cor
Re: [PATCH 01/13] staging: gasket: core: hold reference to pci_dev while used
On Sun, Jul 29, 2018 at 12:37 PM Todd Poynor wrote: > > From: Todd Poynor > > Hold a reference on the struct pci_dev while a pointer to it is held in > the gasket data structures. > > Signed-off-by: Todd Poynor > --- > drivers/staging/gasket/gasket_core.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/gasket/gasket_core.c > b/drivers/staging/gasket/gasket_core.c > index 2b484d067c38a..b832a4f529f27 100644 > --- a/drivers/staging/gasket/gasket_core.c > +++ b/drivers/staging/gasket/gasket_core.c > @@ -488,6 +488,7 @@ static void gasket_free_dev(struct gasket_dev *gasket_dev) > internal_desc->devs[gasket_dev->dev_idx] = NULL; > mutex_unlock(&internal_desc->mutex); > put_device(gasket_dev->dev); > + pci_dev_put(gasket_dev->pci_dev); gasket_free_dev() is called only from driver PCI probe and remove function. I can assure you that that pci_dev structure is not going anywhere, there is no need to take this additional reference. Thanks, Dmitry
[PATCH] Improve code readability
Merge the duplicated complex conditions to improve code readability.
Signed-off-by: Liu Song
Reviewed-by: Jiang Biao
---
fs/ext4/inode.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 7d6c100..c2bc1fd 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -4946,17 +4946,15 @@ struct inode *ext4_iget(struct super_block *sb,
unsigned long ino)
ret = -EFSCORRUPTED;
goto bad_inode;
} else if (!ext4_has_inline_data(inode)) {
- if (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS)) {
- if ((S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode) ||
- (S_ISLNK(inode->i_mode) &&
-!ext4_inode_is_fast_symlink(inode
+ if (S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode) ||
+ (S_ISLNK(inode->i_mode) &&
+ !ext4_inode_is_fast_symlink(inode))) {
+ if (ext4_test_inode_flag(inode, EXT4_INODE_EXTENTS))
/* Validate extent which is part of inode */
ret = ext4_ext_check_inode(inode);
- } else if (S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode) ||
- (S_ISLNK(inode->i_mode) &&
- !ext4_inode_is_fast_symlink(inode))) {
+ else
/* Validate block references which are part of inode */
- ret = ext4_ind_check_inode(inode);
+ ret = ext4_ind_check_inode(inode);
}
}
if (ret)
--
1.8.3.1
Re: [PATCH] PCI: let pci_request_irq properly deal with threaded interrupts
On Mon, 30 Jul 2018 23:36:57 +0100,
Thomas Gleixner wrote:
>
> On Mon, 30 Jul 2018, Bjorn Helgaas wrote:
>
> > [+cc Thomas, Christoph, LKML]
>
> + Marc
>
> > On Mon, Jul 30, 2018 at 12:03:42AM +0200, Heiner Kallweit wrote:
> > > If we have a threaded interrupt with the handler being NULL, then
> > > request_threaded_irq() -> __setup_irq() will complain and bail out
> > > if the IRQF_ONESHOT flag isn't set. Therefore check for the handler
> > > being NULL and set IRQF_ONESHOT in this case.
> > >
> > > This change is needed to migrate the mei_me driver to
> > > pci_alloc_irq_vectors() and pci_request_irq().
> > >
> > > Signed-off-by: Heiner Kallweit
> >
> > I'd like an ack from Thomas because this requirement about IRQF_ONESHOT
> > usage isn't mentioned in the request_threaded_irq() function doc or
> > Documentation/
>
> Right. The documentation really needs some love and care. :(
>
> Yes, request for pure threaded interrupts are rejected if the oneshot flag
> is not set. The reason is that this would be deadly especially with level
> triggered interrupts because the primary default handler just wakes the
> thread and then reenables interrupts, which will make the interrupt come
> back immediately and the thread won't have a chance to actually shut it up
> in the device.
>
> That made me look into that code again and I found that we added a flag for
> irq chips to tell the core that the interrupt is one shot safe, i.e. that
> it can be requested w/o IRQF_ONESHOT. That was initially added to optimize
> MSI based interrupts which are oneshot safe by implementation.
>
> dc9b229a58dc ("genirq: Allow irq chips to mark themself oneshot safe")
>
> The original patch added that flag to the x86 MSI irqchip code, but that
> part was not applied for reasons which slipped from memory. It might be
> worthwhile to revisit that in order to avoid the mask/unmask overhead for
> such cases.
Yup, that would actually be beneficial to a range of interrupt
controllers (only an obscure GPIO driver makes use of this flag).
We could also consider extending this to support interrupt
hierarchies, as __setup_irq() seems only concerned with the top of the
stack (an IRQ provided by a generic MSI stack and backed by an irqchip
providing IRQCHIP_ONESHOT_SAFE would go unnoticed).
M.
--
Jazz is not dead, it just smell funny.
[PATCH v5 11/11] hugetlb: Introduce generic version of huge_ptep_get
ia64, mips, parisc, powerpc, sh, sparc, x86 architectures use the
same version of huge_ptep_get, so move this generic implementation into
asm-generic/hugetlb.h.
Signed-off-by: Alexandre Ghiti
Reviewed-by: Mike Kravetz
---
arch/arm/include/asm/hugetlb-3level.h | 1 +
arch/arm64/include/asm/hugetlb.h | 1 +
arch/ia64/include/asm/hugetlb.h | 5 -
arch/mips/include/asm/hugetlb.h | 5 -
arch/parisc/include/asm/hugetlb.h | 5 -
arch/powerpc/include/asm/hugetlb.h| 5 -
arch/sh/include/asm/hugetlb.h | 5 -
arch/sparc/include/asm/hugetlb.h | 5 -
arch/x86/include/asm/hugetlb.h| 5 -
include/asm-generic/hugetlb.h | 7 +++
10 files changed, 9 insertions(+), 35 deletions(-)
diff --git a/arch/arm/include/asm/hugetlb-3level.h
b/arch/arm/include/asm/hugetlb-3level.h
index 54e4b097b1f5..0d9f3918fa7e 100644
--- a/arch/arm/include/asm/hugetlb-3level.h
+++ b/arch/arm/include/asm/hugetlb-3level.h
@@ -29,6 +29,7 @@
* ptes.
* (The valid bit is automatically cleared by set_pte_at for PROT_NONE ptes).
*/
+#define __HAVE_ARCH_HUGE_PTEP_GET
static inline pte_t huge_ptep_get(pte_t *ptep)
{
pte_t retval = *ptep;
diff --git a/arch/arm64/include/asm/hugetlb.h b/arch/arm64/include/asm/hugetlb.h
index 80887abcef7f..fb6609875455 100644
--- a/arch/arm64/include/asm/hugetlb.h
+++ b/arch/arm64/include/asm/hugetlb.h
@@ -20,6 +20,7 @@
#include
+#define __HAVE_ARCH_HUGE_PTEP_GET
static inline pte_t huge_ptep_get(pte_t *ptep)
{
return READ_ONCE(*ptep);
diff --git a/arch/ia64/include/asm/hugetlb.h b/arch/ia64/include/asm/hugetlb.h
index e9b42750fdf5..36cc0396b214 100644
--- a/arch/ia64/include/asm/hugetlb.h
+++ b/arch/ia64/include/asm/hugetlb.h
@@ -27,11 +27,6 @@ static inline void huge_ptep_clear_flush(struct
vm_area_struct *vma,
{
}
-static inline pte_t huge_ptep_get(pte_t *ptep)
-{
- return *ptep;
-}
-
static inline void arch_clear_hugepage_flags(struct page *page)
{
}
diff --git a/arch/mips/include/asm/hugetlb.h b/arch/mips/include/asm/hugetlb.h
index 120adc3b2ffd..425bb6fc3bda 100644
--- a/arch/mips/include/asm/hugetlb.h
+++ b/arch/mips/include/asm/hugetlb.h
@@ -82,11 +82,6 @@ static inline int huge_ptep_set_access_flags(struct
vm_area_struct *vma,
return changed;
}
-static inline pte_t huge_ptep_get(pte_t *ptep)
-{
- return *ptep;
-}
-
static inline void arch_clear_hugepage_flags(struct page *page)
{
}
diff --git a/arch/parisc/include/asm/hugetlb.h
b/arch/parisc/include/asm/hugetlb.h
index 165b4e5a6f32..7cb595dcb7d7 100644
--- a/arch/parisc/include/asm/hugetlb.h
+++ b/arch/parisc/include/asm/hugetlb.h
@@ -48,11 +48,6 @@ int huge_ptep_set_access_flags(struct vm_area_struct *vma,
unsigned long addr, pte_t *ptep,
pte_t pte, int dirty);
-static inline pte_t huge_ptep_get(pte_t *ptep)
-{
- return *ptep;
-}
-
static inline void arch_clear_hugepage_flags(struct page *page)
{
}
diff --git a/arch/powerpc/include/asm/hugetlb.h
b/arch/powerpc/include/asm/hugetlb.h
index 658bf7136a3c..33a2d9e3ea9e 100644
--- a/arch/powerpc/include/asm/hugetlb.h
+++ b/arch/powerpc/include/asm/hugetlb.h
@@ -142,11 +142,6 @@ extern int huge_ptep_set_access_flags(struct
vm_area_struct *vma,
unsigned long addr, pte_t *ptep,
pte_t pte, int dirty);
-static inline pte_t huge_ptep_get(pte_t *ptep)
-{
- return *ptep;
-}
-
static inline void arch_clear_hugepage_flags(struct page *page)
{
}
diff --git a/arch/sh/include/asm/hugetlb.h b/arch/sh/include/asm/hugetlb.h
index c87195ae0cfa..6f025fe18146 100644
--- a/arch/sh/include/asm/hugetlb.h
+++ b/arch/sh/include/asm/hugetlb.h
@@ -32,11 +32,6 @@ static inline void huge_ptep_clear_flush(struct
vm_area_struct *vma,
{
}
-static inline pte_t huge_ptep_get(pte_t *ptep)
-{
- return *ptep;
-}
-
static inline void arch_clear_hugepage_flags(struct page *page)
{
clear_bit(PG_dcache_clean, &page->flags);
diff --git a/arch/sparc/include/asm/hugetlb.h b/arch/sparc/include/asm/hugetlb.h
index 028a1465fbe7..3963f80d1cb3 100644
--- a/arch/sparc/include/asm/hugetlb.h
+++ b/arch/sparc/include/asm/hugetlb.h
@@ -53,11 +53,6 @@ static inline int huge_ptep_set_access_flags(struct
vm_area_struct *vma,
return changed;
}
-static inline pte_t huge_ptep_get(pte_t *ptep)
-{
- return *ptep;
-}
-
static inline void arch_clear_hugepage_flags(struct page *page)
{
}
diff --git a/arch/x86/include/asm/hugetlb.h b/arch/x86/include/asm/hugetlb.h
index 574d42eb081e..7469d321f072 100644
--- a/arch/x86/include/asm/hugetlb.h
+++ b/arch/x86/include/asm/hugetlb.h
@@ -13,11 +13,6 @@ static inline int is_hugepage_only_range(struct mm_struct
*mm,
return 0;
}
-static inline pte_t huge_ptep_get(pte_t *ptep)
-{
- return *ptep;
-}
-
static inline void arch_clear_hugepage_flags(st
[tip:perf/urgent] perf/x86/intel/uncore: Fix hardcoded index of Broadwell extra PCI devices
Commit-ID: 156c8b58ef5cfd97245928c95669fd4cb0f9c388
Gitweb: https://git.kernel.org/tip/156c8b58ef5cfd97245928c95669fd4cb0f9c388
Author: Kan Liang
AuthorDate: Mon, 30 Jul 2018 08:28:08 -0400
Committer: Ingo Molnar
CommitDate: Tue, 31 Jul 2018 07:43:37 +0200
perf/x86/intel/uncore: Fix hardcoded index of Broadwell extra PCI devices
Masayoshi Mizuma reported that a warning message is shown while a CPU is
hot-removed on Broadwell servers:
WARNING: CPU: 126 PID: 6 at arch/x86/events/intel/uncore.c:988
uncore_pci_remove+0x10b/0x150
Call Trace:
pci_device_remove+0x42/0xd0
device_release_driver_internal+0x148/0x220
pci_stop_bus_device+0x76/0xa0
pci_stop_root_bus+0x44/0x60
acpi_pci_root_remove+0x1f/0x80
acpi_bus_trim+0x57/0x90
acpi_bus_trim+0x2e/0x90
acpi_device_hotplug+0x2bc/0x4b0
acpi_hotplug_work_fn+0x1a/0x30
process_one_work+0x174/0x3a0
worker_thread+0x4c/0x3d0
kthread+0xf8/0x130
This bug was introduced by:
commit 15a3e845b01c ("perf/x86/intel/uncore: Fix SBOX support for Broadwell
CPUs")
The index of "QPI Port 2 filter" was hardcode to 2, but this conflicts with the
index of "PCU.3" which is "HSWEP_PCI_PCU_3", which equals to 2 as well.
To fix the conflict, the hardcoded index needs to be cleaned up:
- introduce a new enumerator "BDX_PCI_QPI_PORT2_FILTER" for "QPI Port 2
filter" on Broadwell,
- increase UNCORE_EXTRA_PCI_DEV_MAX by one,
- clean up the hardcoded index.
Debugged-by: Masayoshi Mizuma
Suggested-by: Ingo Molnar
Reported-by: Masayoshi Mizuma
Tested-by: Masayoshi Mizuma
Signed-off-by: Kan Liang
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Thomas Gleixner
Cc: Vince Weaver
Cc: msys.miz...@gmail.com
Cc: sta...@vger.kernel.org
Fixes: 15a3e845b01c ("perf/x86/intel/uncore: Fix SBOX support for Broadwell
CPUs")
Link:
http://lkml.kernel.org/r/1532953688-15008-1-git-send-email-kan.li...@linux.intel.com
Signed-off-by: Ingo Molnar
---
arch/x86/events/intel/uncore.h | 2 +-
arch/x86/events/intel/uncore_snbep.c | 10 +++---
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/x86/events/intel/uncore.h b/arch/x86/events/intel/uncore.h
index c9e1e0bef3c3..e17ab885b1e9 100644
--- a/arch/x86/events/intel/uncore.h
+++ b/arch/x86/events/intel/uncore.h
@@ -28,7 +28,7 @@
#define UNCORE_PCI_DEV_TYPE(data) ((data >> 8) & 0xff)
#define UNCORE_PCI_DEV_IDX(data) (data & 0xff)
#define UNCORE_EXTRA_PCI_DEV 0xff
-#define UNCORE_EXTRA_PCI_DEV_MAX 3
+#define UNCORE_EXTRA_PCI_DEV_MAX 4
#define UNCORE_EVENT_CONSTRAINT(c, n) EVENT_CONSTRAINT(c, n, 0xff)
diff --git a/arch/x86/events/intel/uncore_snbep.c
b/arch/x86/events/intel/uncore_snbep.c
index 87dc0263a2e1..51d7c117e3c7 100644
--- a/arch/x86/events/intel/uncore_snbep.c
+++ b/arch/x86/events/intel/uncore_snbep.c
@@ -1029,6 +1029,7 @@ void snbep_uncore_cpu_init(void)
enum {
SNBEP_PCI_QPI_PORT0_FILTER,
SNBEP_PCI_QPI_PORT1_FILTER,
+ BDX_PCI_QPI_PORT2_FILTER,
HSWEP_PCI_PCU_3,
};
@@ -3286,15 +3287,18 @@ static const struct pci_device_id bdx_uncore_pci_ids[]
= {
},
{ /* QPI Port 0 filter */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x6f86),
- .driver_data = UNCORE_PCI_DEV_DATA(UNCORE_EXTRA_PCI_DEV, 0),
+ .driver_data = UNCORE_PCI_DEV_DATA(UNCORE_EXTRA_PCI_DEV,
+ SNBEP_PCI_QPI_PORT0_FILTER),
},
{ /* QPI Port 1 filter */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x6f96),
- .driver_data = UNCORE_PCI_DEV_DATA(UNCORE_EXTRA_PCI_DEV, 1),
+ .driver_data = UNCORE_PCI_DEV_DATA(UNCORE_EXTRA_PCI_DEV,
+ SNBEP_PCI_QPI_PORT1_FILTER),
},
{ /* QPI Port 2 filter */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x6f46),
- .driver_data = UNCORE_PCI_DEV_DATA(UNCORE_EXTRA_PCI_DEV, 2),
+ .driver_data = UNCORE_PCI_DEV_DATA(UNCORE_EXTRA_PCI_DEV,
+ BDX_PCI_QPI_PORT2_FILTER),
},
{ /* PCU.3 (for Capability registers) */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x6fc0),
[tip:perf/urgent] perf tools: Fix the build on the alpine:edge distro
Commit-ID: 44fe619b1418ff4e9d2f9518a940fbe2fb686a08 Gitweb: https://git.kernel.org/tip/44fe619b1418ff4e9d2f9518a940fbe2fb686a08 Author: Arnaldo Carvalho de Melo AuthorDate: Mon, 30 Jul 2018 13:15:03 -0300 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 30 Jul 2018 13:15:03 -0300 perf tools: Fix the build on the alpine:edge distro The UAPI file byteorder/little_endian.h uses the __always_inline define without including the header where it is defined, linux/stddef.h, this ends up working in all the other distros because that file gets included seemingly by luck from one of the files included from little_endian.h. But not on Alpine:edge, that fails for all files where perf_event.h is included but linux/stddef.h isn't include before that. Adding the missing linux/stddef.h file where it breaks on Alpine:edge to fix that, in all other distros, that is just a very small header anyway. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link: https://lkml.kernel.org/n/tip-9r1pifftxvuxms8l7ir73...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/arch/x86/util/pmu.c | 1 + tools/perf/arch/x86/util/tsc.c | 1 + tools/perf/perf.h | 1 + tools/perf/util/header.h | 1 + tools/perf/util/namespaces.h | 1 + 5 files changed, 5 insertions(+) diff --git a/tools/perf/arch/x86/util/pmu.c b/tools/perf/arch/x86/util/pmu.c index 63a74c32ddc5..e33ef5bc31c5 100644 --- a/tools/perf/arch/x86/util/pmu.c +++ b/tools/perf/arch/x86/util/pmu.c @@ -1,6 +1,7 @@ // SPDX-License-Identifier: GPL-2.0 #include +#include #include #include "../../util/intel-pt.h" diff --git a/tools/perf/arch/x86/util/tsc.c b/tools/perf/arch/x86/util/tsc.c index 06bae7023a51..950539f9a4f7 100644 --- a/tools/perf/arch/x86/util/tsc.c +++ b/tools/perf/arch/x86/util/tsc.c @@ -2,6 +2,7 @@ #include #include +#include #include #include "../../perf.h" diff --git a/tools/perf/perf.h b/tools/perf/perf.h index a1a97956136f..d215714f48df 100644 --- a/tools/perf/perf.h +++ b/tools/perf/perf.h @@ -5,6 +5,7 @@ #include #include #include +#include #include extern bool test_attr__enabled; diff --git a/tools/perf/util/header.h b/tools/perf/util/header.h index 90d4577a92dc..6d7fe44aadc0 100644 --- a/tools/perf/util/header.h +++ b/tools/perf/util/header.h @@ -2,6 +2,7 @@ #ifndef __PERF_HEADER_H #define __PERF_HEADER_H +#include #include #include #include diff --git a/tools/perf/util/namespaces.h b/tools/perf/util/namespaces.h index 760558dcfd18..cae1a9a39722 100644 --- a/tools/perf/util/namespaces.h +++ b/tools/perf/util/namespaces.h @@ -10,6 +10,7 @@ #define __PERF_NAMESPACES_H #include +#include #include #include #include
[tip:perf/urgent] tools arch: Update arch/x86/lib/memcpy_64.S copy used in 'perf bench mem memcpy'
Commit-ID: 1f27a050fc679d16e68a40e0bb575364a89fad66
Gitweb: https://git.kernel.org/tip/1f27a050fc679d16e68a40e0bb575364a89fad66
Author: Arnaldo Carvalho de Melo
AuthorDate: Mon, 30 Jul 2018 12:26:54 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 30 Jul 2018 12:36:51 -0300
tools arch: Update arch/x86/lib/memcpy_64.S copy used in 'perf bench mem memcpy'
To cope with the changes in:
12c89130a56a ("x86/asm/memcpy_mcsafe: Add write-protection-fault handling")
60622d68227d ("x86/asm/memcpy_mcsafe: Return bytes remaining")
bd131544aa7e ("x86/asm/memcpy_mcsafe: Add labels for __memcpy_mcsafe() write
fault handling")
da7bc9c57eb0 ("x86/asm/memcpy_mcsafe: Remove loop unrolling")
This needed introducing a file with a copy of the mcsafe_handle_tail()
function, that is used in the new memcpy_64.S file, as well as a dummy
mcsafe_test.h header.
Testing it:
$ nm ~/bin/perf | grep mcsafe
00484130 T mcsafe_handle_tail
00484300 T __memcpy_mcsafe
$
$ perf bench mem memcpy
# Running 'mem/memcpy' benchmark:
# function 'default' (Default memcpy() provided by glibc)
# Copying 1MB bytes ...
44.389205 GB/sec
# function 'x86-64-unrolled' (unrolled memcpy() in arch/x86/lib/memcpy_64.S)
# Copying 1MB bytes ...
22.710756 GB/sec
# function 'x86-64-movsq' (movsq-based memcpy() in arch/x86/lib/memcpy_64.S)
# Copying 1MB bytes ...
42.459239 GB/sec
# function 'x86-64-movsb' (movsb-based memcpy() in arch/x86/lib/memcpy_64.S)
# Copying 1MB bytes ...
42.459239 GB/sec
$
This silences this perf tools build warning:
Warning: Kernel ABI header at 'tools/arch/x86/lib/memcpy_64.S' differs from
latest version at 'arch/x86/lib/memcpy_64.S'
Cc: Adrian Hunter
Cc: Dan Williams
Cc: David Ahern
Cc: Jiri Olsa
Cc: Mika Penttilä
Cc: Namhyung Kim
Cc: Tony Luck
Cc: Wang Nan
Link: https://lkml.kernel.org/n/tip-igdpciheradk3gb3qqal5...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/arch/x86/include/asm/mcsafe_test.h | 13
tools/arch/x86/lib/memcpy_64.S | 112 +++
tools/perf/bench/Build | 1 +
tools/perf/bench/mem-memcpy-x86-64-asm.S | 1 +
tools/perf/bench/mem-memcpy-x86-64-lib.c | 24 +++
5 files changed, 93 insertions(+), 58 deletions(-)
diff --git a/tools/arch/x86/include/asm/mcsafe_test.h
b/tools/arch/x86/include/asm/mcsafe_test.h
new file mode 100644
index ..2ccd588fbad4
--- /dev/null
+++ b/tools/arch/x86/include/asm/mcsafe_test.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _MCSAFE_TEST_H_
+#define _MCSAFE_TEST_H_
+
+.macro MCSAFE_TEST_CTL
+.endm
+
+.macro MCSAFE_TEST_SRC reg count target
+.endm
+
+.macro MCSAFE_TEST_DST reg count target
+.endm
+#endif /* _MCSAFE_TEST_H_ */
diff --git a/tools/arch/x86/lib/memcpy_64.S b/tools/arch/x86/lib/memcpy_64.S
index 9a53a06e5a3e..298ef1479240 100644
--- a/tools/arch/x86/lib/memcpy_64.S
+++ b/tools/arch/x86/lib/memcpy_64.S
@@ -3,6 +3,7 @@
#include
#include
#include
+#include
#include
#include
@@ -183,12 +184,15 @@ ENTRY(memcpy_orig)
ENDPROC(memcpy_orig)
#ifndef CONFIG_UML
+
+MCSAFE_TEST_CTL
+
/*
- * memcpy_mcsafe_unrolled - memory copy with machine check exception handling
+ * __memcpy_mcsafe - memory copy with machine check exception handling
* Note that we only catch machine checks when reading the source addresses.
* Writes to target are posted and don't generate machine checks.
*/
-ENTRY(memcpy_mcsafe_unrolled)
+ENTRY(__memcpy_mcsafe)
cmpl $8, %edx
/* Less than 8 bytes? Go to byte copy loop */
jb .L_no_whole_words
@@ -204,58 +208,33 @@ ENTRY(memcpy_mcsafe_unrolled)
subl $8, %ecx
negl %ecx
subl %ecx, %edx
-.L_copy_leading_bytes:
+.L_read_leading_bytes:
movb (%rsi), %al
+ MCSAFE_TEST_SRC %rsi 1 .E_leading_bytes
+ MCSAFE_TEST_DST %rdi 1 .E_leading_bytes
+.L_write_leading_bytes:
movb %al, (%rdi)
incq %rsi
incq %rdi
decl %ecx
- jnz .L_copy_leading_bytes
+ jnz .L_read_leading_bytes
.L_8byte_aligned:
- /* Figure out how many whole cache lines (64-bytes) to copy */
- movl %edx, %ecx
- andl $63, %edx
- shrl $6, %ecx
- jz .L_no_whole_cache_lines
-
- /* Loop copying whole cache lines */
-.L_cache_w0: movq (%rsi), %r8
-.L_cache_w1: movq 1*8(%rsi), %r9
-.L_cache_w2: movq 2*8(%rsi), %r10
-.L_cache_w3: movq 3*8(%rsi), %r11
- movq %r8, (%rdi)
- movq %r9, 1*8(%rdi)
- movq %r10, 2*8(%rdi)
- movq %r11, 3*8(%rdi)
-.L_cache_w4: movq 4*8(%rsi), %r8
-.L_cache_w5: movq 5*8(%rsi), %r9
-.L_cache_w6: movq 6*8(%rsi), %r10
-.L_cache_w7: movq 7*8(%rsi), %r11
- movq %r8, 4*8(%rdi)
- movq %r9, 5*8(%rdi)
- movq %r10, 6*8(%rdi)
- movq %r11, 7*8(%rdi)
- leaq 64(%rsi), %rsi
- leaq 64(%rdi), %rdi
- decl %ecx
- jnz .L_cache_w0
-
- /* Are there any trailing
[tip:perf/urgent] tools headers uapi: Refresh linux/bpf.h copy
Commit-ID: fc73bfd6005c7fe5c3a2f04d4db7fa5d37cd3ebd
Gitweb: https://git.kernel.org/tip/fc73bfd6005c7fe5c3a2f04d4db7fa5d37cd3ebd
Author: Arnaldo Carvalho de Melo
AuthorDate: Mon, 30 Jul 2018 11:56:13 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 30 Jul 2018 12:35:45 -0300
tools headers uapi: Refresh linux/bpf.h copy
To get the changes in:
4c79579b44b1 ("bpf: Change bpf_fib_lookup to return lookup status")
That do not entail changes in tools/perf/ use of it, elliminating the
following perf build warning:
Warning: Kernel ABI header at 'tools/include/uapi/linux/bpf.h' differs from
latest version at 'include/uapi/linux/bpf.h'
Cc: Adrian Hunter
Cc: Daniel Borkmann
Cc: David Ahern
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Wang Nan
Link: https://lkml.kernel.org/n/tip-yei494y6b3mn6bjzz9g0w...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/include/uapi/linux/bpf.h | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 59b19b6a40d7..b7db3261c62d 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -1857,7 +1857,8 @@ union bpf_attr {
* is resolved), the nexthop address is returned in ipv4_dst
* or ipv6_dst based on family, smac is set to mac address of
* egress device, dmac is set to nexthop mac address, rt_metric
- * is set to metric from route (IPv4/IPv6 only).
+ * is set to metric from route (IPv4/IPv6 only), and ifindex
+ * is set to the device index of the nexthop from the FIB lookup.
*
* *plen* argument is the size of the passed in struct.
* *flags* argument can be a combination of one or more of the
@@ -1873,9 +1874,10 @@ union bpf_attr {
* *ctx* is either **struct xdp_md** for XDP programs or
* **struct sk_buff** tc cls_act programs.
* Return
- * Egress device index on success, 0 if packet needs to continue
- * up the stack for further processing or a negative error in case
- * of failure.
+ * * < 0 if any input argument is invalid
+ * * 0 on success (packet is forwarded, nexthop neighbor exists)
+ * * > 0 one of **BPF_FIB_LKUP_RET_** codes explaining why the
+ * * packet is not forwarded or needs assist from full stack
*
* int bpf_sock_hash_update(struct bpf_sock_ops_kern *skops, struct bpf_map
*map, void *key, u64 flags)
* Description
@@ -2612,6 +2614,18 @@ struct bpf_raw_tracepoint_args {
#define BPF_FIB_LOOKUP_DIRECT BIT(0)
#define BPF_FIB_LOOKUP_OUTPUT BIT(1)
+enum {
+ BPF_FIB_LKUP_RET_SUCCESS, /* lookup successful */
+ BPF_FIB_LKUP_RET_BLACKHOLE,/* dest is blackholed; can be dropped */
+ BPF_FIB_LKUP_RET_UNREACHABLE, /* dest is unreachable; can be dropped */
+ BPF_FIB_LKUP_RET_PROHIBIT, /* dest not allowed; can be dropped */
+ BPF_FIB_LKUP_RET_NOT_FWDED,/* packet is not forwarded */
+ BPF_FIB_LKUP_RET_FWD_DISABLED, /* fwding is not enabled on ingress */
+ BPF_FIB_LKUP_RET_UNSUPP_LWT, /* fwd requires encapsulation */
+ BPF_FIB_LKUP_RET_NO_NEIGH, /* no neighbor entry for nh */
+ BPF_FIB_LKUP_RET_FRAG_NEEDED, /* fragmentation required to fwd */
+};
+
struct bpf_fib_lookup {
/* input: network family for lookup (AF_INET, AF_INET6)
* output: network family of egress nexthop
@@ -2625,7 +2639,11 @@ struct bpf_fib_lookup {
/* total length of packet from network header - used for MTU check */
__u16 tot_len;
- __u32 ifindex; /* L3 device index for lookup */
+
+ /* input: L3 device index for lookup
+* output: device index from FIB lookup
+*/
+ __u32 ifindex;
union {
/* inputs to lookup */
[tip:perf/urgent] tools headers powerpc: Update asm/unistd.h copy to pick new
Commit-ID: 7def16d1d2668a4a3663291c9ace307b81934704
Gitweb: https://git.kernel.org/tip/7def16d1d2668a4a3663291c9ace307b81934704
Author: Arnaldo Carvalho de Melo
AuthorDate: Mon, 30 Jul 2018 11:48:19 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 30 Jul 2018 11:51:13 -0300
tools headers powerpc: Update asm/unistd.h copy to pick new
The new 'io_pgetevents' syscall was wired up in PowerPC in the following
cset:
b2f82565f2ca ("powerpc: Wire up io_pgetevents")
Update tools/arch/powerpc/ copy of the asm/unistd.h file so that 'perf
trace' on PowerPC gets it in its syscall table.
This elliminated the following perf build warning:
Warning: Kernel ABI header at 'tools/arch/powerpc/include/uapi/asm/unistd.h'
differs from latest version at 'arch/powerpc/include/uapi/asm/unistd.h'
Cc: Alexander Shishkin
Cc: Breno Leitao
Cc: Hendrik Brueckner
Cc: Jiri Olsa
Cc: linuxppc-...@lists.ozlabs.org
Cc: Michael Ellerman
Cc: Namhyung Kim
Cc: Ravi Bangoria
Cc: Thomas Richter
Link: https://lkml.kernel.org/n/tip-9uvu7tz4ud3bxxfyxwryu...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/arch/powerpc/include/uapi/asm/unistd.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/arch/powerpc/include/uapi/asm/unistd.h
b/tools/arch/powerpc/include/uapi/asm/unistd.h
index ac5ba55066dd..985534d0b448 100644
--- a/tools/arch/powerpc/include/uapi/asm/unistd.h
+++ b/tools/arch/powerpc/include/uapi/asm/unistd.h
@@ -399,5 +399,6 @@
#define __NR_pkey_free 385
#define __NR_pkey_mprotect 386
#define __NR_rseq 387
+#define __NR_io_pgetevents 388
#endif /* _UAPI_ASM_POWERPC_UNISTD_H_ */
[tip:perf/urgent] tools headers uapi: Update tools's copy of linux/perf_event.h
Commit-ID: 2c3ee0e1779d2e08bc08734bc8475daaf94d0ba4
Gitweb: https://git.kernel.org/tip/2c3ee0e1779d2e08bc08734bc8475daaf94d0ba4
Author: Arnaldo Carvalho de Melo
AuthorDate: Mon, 30 Jul 2018 11:41:56 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 30 Jul 2018 11:41:56 -0300
tools headers uapi: Update tools's copy of linux/perf_event.h
To get the changes in:
6cbc304f2f36 ("perf/x86/intel: Fix unwind errors from PEBS entries (mk-II)")
That do not imply any changes in the tooling side, the (ab)use of
sample_type is entirely done in kernel space, nothing for userspace to
witness here.
This cures the following warning during perf's build:
Warning: Kernel ABI header at 'tools/include/uapi/linux/perf_event.h' differs
from latest version at 'include/uapi/linux/perf_event.h'
Cc: Adrian Hunter
Cc: Alexander Shishkin
Cc: David Ahern
Cc: Jiri Olsa
Cc: Josh Poimboeuf
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Prashant Bhole
Cc: Stephane Eranian
Cc: Thomas Gleixner
Cc: Vince Weaver
Cc: Wang Nan
Link: https://lkml.kernel.org/n/tip-o64mjoy35s9gd1gitunw1...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/include/uapi/linux/perf_event.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/include/uapi/linux/perf_event.h
b/tools/include/uapi/linux/perf_event.h
index b8e288a1f740..eeb787b1c53c 100644
--- a/tools/include/uapi/linux/perf_event.h
+++ b/tools/include/uapi/linux/perf_event.h
@@ -143,6 +143,8 @@ enum perf_event_sample_format {
PERF_SAMPLE_PHYS_ADDR = 1U << 19,
PERF_SAMPLE_MAX = 1U << 20, /* non-ABI */
+
+ __PERF_SAMPLE_CALLCHAIN_EARLY = 1ULL << 63,
};
/*
[PATCH v4 4/4] arm64: dts: rockchip: add sdmmc UHS support for roc-rk3328-cc
From: Levin Du
In roc-rk3328-cc board, the signal voltage of sdmmc is supplied by the
vcc_sdio regulator, which is a mux between 1.8V and 3.3V, controlled by
a special output only gpio pin labeled "gpiomut_pmuio_iout",
corresponding bit 1 of the syscon GRF_SOC_CON10.
This special pin can now be reference as <&grf_gpio 0>, thanks to the
gpio-syscon driver, which makes writing regulator-gpio possible.
If the signal voltage changes, the io domain needs to change
correspondingly.
To use this feature, the following options are required in kernel config:
- CONFIG_GPIO_SYSCON=y
- CONFIG_POWER_AVS=y
- CONFIG_ROCKCHIP_IODOMAIN=y
Signed-off-by: Levin Du
---
Changes in v4:
- Use <&grf_gpio 0> to refer to the GPIO_MUTE pin.
Changes in v3:
- Use <&gpio_mute 0> instead of <&gpio_mute 1> to refer to the GPIO_MUTE pin.
Changes in v2:
- Rename gpio_syscon10 to gpio_mute in rk3328-roc-cc.dts
Changes in v1:
- Split into small patches
- Sort dts properties in sdmmc node
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
index b983abd..1edb39a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
@@ -41,6 +41,19 @@
vin-supply = <&vcc_io>;
};
+ vcc_sdio: sdmmcio-regulator {
+ compatible = "regulator-gpio";
+ gpios = <&grf_gpio 0 GPIO_ACTIVE_HIGH>;
+ states = <180 0x1
+ 330 0x0>;
+ regulator-name = "vcc_sdio";
+ regulator-type = "voltage";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ vin-supply = <&vcc_sys>;
+ };
+
vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {
compatible = "regulator-fixed";
enable-active-high;
@@ -213,7 +226,7 @@
vccio1-supply = <&vcc_io>;
vccio2-supply = <&vcc18_emmc>;
- vccio3-supply = <&vcc_io>;
+ vccio3-supply = <&vcc_sdio>;
vccio4-supply = <&vcc_18>;
vccio5-supply = <&vcc_io>;
vccio6-supply = <&vcc_io>;
@@ -242,7 +255,12 @@
max-frequency = <15000>;
pinctrl-names = "default";
pinctrl-0 = <&sdmmc0_clk &sdmmc0_cmd &sdmmc0_dectn &sdmmc0_bus4>;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
vmmc-supply = <&vcc_sd>;
+ vqmmc-supply = <&vcc_sdio>;
status = "okay";
};
@@ -277,3 +295,7 @@
&usb_host0_ohci {
status = "okay";
};
+
+&grf_gpio {
+ status = "okay";
+};
--
2.7.4
Re: [PATCH 0/2] dt: thermal: Fix broken cooling-maps
On 二, 2018-07-31 at 10:21 +0530, Viresh Kumar wrote: > On 05-07-18, 10:39, Viresh Kumar wrote: > > > > Hi, > > > > This is an attempt to fix the broken or partially defined DT > > bindings > > for cooling-maps. We should list every device that participates in > > cooling down at a certain trip point, instead of just the first in > > the > > list as that depends on certain ordering of events to work > > properly. > > > > The first patch extends the binding to allow a list of phandles in > > "cooling-device" property and the second patch fixes one of the > > platform's DT. > > > > This will be followed up by fixing all platform DT bindings that > > have > > these issues after this set is accepted. > > > > The kernel also requires some changes to handle the phandle list, > > but > > wouldn't break with these changes as it reads the first phandle in > > the > > list for now. We can update that separately. > @Zhang: Are you going to apply this for 4.19-rc1 ? There are lot of > patches that > I am holding up until this gets merged, > I suppose this patch should go via Eduardo' tree. Eduardo, can you please take a look at this patch set? thanks, rui
[PATCH v4 3/4] arm64: dts: rockchip: add io-domain to roc-rk3328-cc
From: Levin Du
It is necessary for the io domain setting of the SoC to match the voltage
supplied by the regulators.
Signed-off-by: Levin Du
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
Changes in v1:
- Split from V0.
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
index 246c317..b983abd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
@@ -208,6 +208,18 @@
};
};
+&io_domains {
+ status = "okay";
+
+ vccio1-supply = <&vcc_io>;
+ vccio2-supply = <&vcc18_emmc>;
+ vccio3-supply = <&vcc_io>;
+ vccio4-supply = <&vcc_18>;
+ vccio5-supply = <&vcc_io>;
+ vccio6-supply = <&vcc_io>;
+ pmuio-supply = <&vcc_io>;
+};
+
&pinctrl {
pmic {
pmic_int_l: pmic-int-l {
--
2.7.4
[PATCH v4 2/4] arm64: dts: rockchip: add GRF GPIO controller to rk3328
From: Levin Du
Adding a GRF GPIO controller labled "grf_gpio" to rk3328, currently
providing access to the GPIO_MUTE pin, which is manupulated by the
GRF_SOC_CON10 register.
The GPIO_MUTE pin is referred to as <&grf_gpio 0>.
Signed-off-by: Levin Du
---
Changes in v4:
- Use binding of "rockchip,rk3328-grf-gpio"
Changes in v3:
- Use dedicated "rockchip,rk3328-gpio-mute" driver
Changes in v2:
- Rename gpio_syscon10 to gpio_mute in rk3328.dtsi
Changes in v1:
- Split from V0 and add to rk3328.dtsi for general use.
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 3f5a294..bf5656d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -275,6 +275,12 @@
mode-loader = ;
};
+ grf_gpio: grf-gpio {
+ compatible = "rockchip,rk3328-grf-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ status = "disabled";
+ };
};
uart0: serial@ff11 {
--
2.7.4
[PATCH v4 0/4] Add sdmmc UHS support to ROC-RK3328-CC board.
From: Levin Du Hi all, this is an attemp to add sdmmc UHS support to the ROC-RK3328-CC board. This patch series adds a new compatible `rockchip,rk3328-grf-gpio` to the gpio-syscon driver, which currently only support for the access of the GPIO_MUTE pin in RK3328. Support for HDMI pins can be added later on perhaps by writing a standalone driver. A new GRF GPIO controller named `grf_gpio` is defined in rk3328.dtsi so that all RK3328 boards has access to it. The ROC-RK3328-CC board use the new gpio <&grf_gpio 0> in gpio-regulator to control the signal voltage of the sdmmc. It is essential for UHS support which requires 1.8V signal voltage. Many thanks to the Linux people! Changes in v4: - Use binding of "rockchip,rk3328-grf-gpio" - Use <&grf_gpio 0> to refer to the GPIO_MUTE pin. Changes in v3: - Change from general gpio-syscon to specific rk3328-gpio-mute - Use dedicated "rockchip,rk3328-gpio-mute" driver - Use <&gpio_mute 0> instead of <&gpio_mute 1> to refer to the GPIO_MUTE pin. Changes in v2: - Rename gpio_syscon10 to gpio_mute in doc - Rename gpio_syscon10 to gpio_mute in rk3328.dtsi - Rename gpio_syscon10 to gpio_mute in rk3328-roc-cc.dts Changes in v1: - Refactured for general gpio-syscon usage for Rockchip SoCs. - Add doc rockchip,gpio-syscon.txt - Split from V0 and add to rk3328.dtsi for general use. - Split from V0. - Split into small patches - Sort dts properties in sdmmc node Levin Du (4): gpio: syscon: rockchip: add GRF GPIO support for rk3328 arm64: dts: rockchip: add GRF GPIO controller to rk3328 arm64: dts: rockchip: add io-domain to roc-rk3328-cc arm64: dts: rockchip: add sdmmc UHS support for roc-rk3328-cc .../bindings/gpio/rockchip,rk3328-grf-gpio.txt | 32 arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 34 ++ arch/arm64/boot/dts/rockchip/rk3328.dtsi | 6 drivers/gpio/gpio-syscon.c | 31 4 files changed, 103 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.txt -- 2.7.4
[PATCH v4 1/4] gpio: syscon: rockchip: add GRF GPIO support for rk3328
From: Levin Du
In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec
mute control, can also be used for general purpose. It is manipulated by
the GRF_SOC_CON10 register in GRF. Aside from the GPIO_MUTE pin, the HDMI
pins can also be set in the same way.
Currently this GRF GPIO controller only supports the mute pin. If needed
in the future, the HDMI pins support can also be added.
Signed-off-by: Levin Du
---
Changes in v4:
- Rename the GPIO binding to "rockchip,rk3328-grf-gpio"
Changes in v3:
- Change from general gpio-syscon to specific rk3328-gpio-mute
Changes in v2:
- Rename gpio_syscon10 to gpio_mute in doc
Changes in v1:
- Refactured for general gpio-syscon usage for Rockchip SoCs.
- Add doc rockchip,gpio-syscon.txt
.../bindings/gpio/rockchip,rk3328-grf-gpio.txt | 32 ++
drivers/gpio/gpio-syscon.c | 31 +
2 files changed, 63 insertions(+)
create mode 100644
Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.txt
diff --git
a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.txt
b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.txt
new file mode 100644
index 000..f9231df
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.txt
@@ -0,0 +1,32 @@
+Rockchip RK3328 GRF (General Register Files) GPIO controller.
+
+In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec mute
+control, can also be used for general purpose. It is manipulated by the
+GRF_SOC_CON10 register in GRF. Aside from the GPIO_MUTE pin, the HDMI pins can
+also be set in the same way.
+
+Currently this GPIO controller only supports the mute pin. If needed in the
+future, the HDMI pins support can also be added.
+
+Required properties:
+- compatible: Should contain "rockchip,rk3328-grf-gpio".
+- gpio-controller: Marks the device node as a gpio controller.
+- #gpio-cells: Should be 2. The first cell is the pin number and
+ the second cell is used to specify the gpio polarity:
+0 = Active high,
+1 = Active low.
+
+Example:
+
+ grf: syscon@ff10 {
+ compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
+
+ grf_gpio: grf-gpio {
+ compatible = "rockchip,rk3328-grf-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+
+Note: The grf_gpio node should be declared as the child of the GRF (General
+Register File) node. The GPIO_MUTE pin is referred to as <&grf_gpio 0>.
diff --git a/drivers/gpio/gpio-syscon.c b/drivers/gpio/gpio-syscon.c
index 8b0a69c..b9b5842 100644
--- a/drivers/gpio/gpio-syscon.c
+++ b/drivers/gpio/gpio-syscon.c
@@ -135,6 +135,33 @@ static const struct syscon_gpio_data clps711x_mctrl_gpio =
{
.dat_bit_offset = 0x40 * 8 + 8,
};
+static void rockchip_gpio_set(struct gpio_chip *chip, unsigned int offset,
+ int val)
+{
+ struct syscon_gpio_priv *priv = gpiochip_get_data(chip);
+ unsigned int offs;
+ u8 bit;
+ u32 data;
+ int ret;
+
+ offs = priv->dreg_offset + priv->data->dat_bit_offset + offset;
+ bit = offs % SYSCON_REG_BITS;
+ data = (val ? BIT(bit) : 0) | BIT(bit + 16);
+ ret = regmap_write(priv->syscon,
+ (offs / SYSCON_REG_BITS) * SYSCON_REG_SIZE,
+ data);
+ if (ret < 0)
+ dev_err(chip->parent, "gpio write failed ret(%d)\n", ret);
+}
+
+static const struct syscon_gpio_data rockchip_rk3328_gpio_mute = {
+ /* RK3328 GPIO_MUTE is an output only pin at GRF_SOC_CON10[1] */
+ .flags = GPIO_SYSCON_FEAT_OUT,
+ .bit_count = 1,
+ .dat_bit_offset = 0x0428 * 8 + 1,
+ .set= rockchip_gpio_set,
+};
+
#define KEYSTONE_LOCK_BIT BIT(0)
static void keystone_gpio_set(struct gpio_chip *chip, unsigned offset, int val)
@@ -175,6 +202,10 @@ static const struct of_device_id syscon_gpio_ids[] = {
.compatible = "ti,keystone-dsp-gpio",
.data = &keystone_dsp_gpio,
},
+ {
+ .compatible = "rockchip,rk3328-grf-gpio",
+ .data = &rockchip_rk3328_gpio_mute,
+ },
{ }
};
MODULE_DEVICE_TABLE(of, syscon_gpio_ids);
--
2.7.4
[PATCH] clk: scmi: Fix the rounding of clock rate
This fix rounds the clock rate properly by using quotient and not
remainder in the calculation. This issue was found while testing HDMI
in the Juno platform.
Fixes: 6d6a1d82eaef7 ("clk: add support for clocks provided by SCMI")
Acked-by: Sudeep Holla
Signed-off-by: Amit Daniel Kachhap
---
drivers/clk/clk-scmi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c
index bb2a6f2..a985bf5 100644
--- a/drivers/clk/clk-scmi.c
+++ b/drivers/clk/clk-scmi.c
@@ -38,7 +38,6 @@ static unsigned long scmi_clk_recalc_rate(struct clk_hw *hw,
static long scmi_clk_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *parent_rate)
{
- int step;
u64 fmin, fmax, ftmp;
struct scmi_clk *clk = to_scmi_clk(hw);
@@ -60,9 +59,9 @@ static long scmi_clk_round_rate(struct clk_hw *hw, unsigned
long rate,
ftmp = rate - fmin;
ftmp += clk->info->range.step_size - 1; /* to round up */
- step = do_div(ftmp, clk->info->range.step_size);
+ do_div(ftmp, clk->info->range.step_size);
- return step * clk->info->range.step_size + fmin;
+ return ftmp * clk->info->range.step_size + fmin;
}
static int scmi_clk_set_rate(struct clk_hw *hw, unsigned long rate,
--
2.7.4
Re: [PATCH mmc-next v2 3/3] mmc: sdhci-of-dwcmshc: solve 128MB DMA boundary limitation
On Tue, 31 Jul 2018 11:29:24 +0800 Jisheng Zhang wrote: > Hi Robin, > > On Mon, 30 Jul 2018 12:06:08 +0100 Robin Murphy wrote: > > > Hi Jisheng, > > > > On 26/07/18 08:14, Jisheng Zhang wrote: > > > When using DMA, if the DMA addr spans 128MB boundary, we have to split > > > the DMA transfer into two so that each one doesn't exceed the boundary. > > > > > > > Out of interest, is the driver already setting its segment boundary mask > > appropriately? This sounds like the exact kind of hardware restriction > > that dma_parms is intended to describe, which scatterlist-generating > > code is *supposed* to already respect. > > Thanks for the nice input. It may provide an elegant solution for this > limitation. > > To simplify the situation, let's assume no iommu, only swiotlb. And > the DDR is less than 4GB so swiotlb on arm64 doesn't init. > > There's no dma range limitation with the HW, the only limitation > is boundary, while dma_capable() doesn't check the boundary mask, so if > we taking this solution, we need to teach dma_capable() about the boundary > mask, I'm not sure whether this is acceptable. > > Another problem is swiotlb initialization. When to init swiotlb, we dunno > there's such boundary limitation HW. Is there any elegant solution for > this problem? > One more problem is: swiotlb isn't available on all platforms, e.g arm? How to solve this SDHCI HW's limitation on arm soc w/o iommu? Thanks
Re: [QUESTION] llist: Comment releasing 'must delete' restriction before traversing
Byungchul Park writes: > On Tue, Jul 31, 2018 at 09:37:50AM +0800, Huang, Ying wrote: >> Byungchul Park writes: >> >> > Hello folks, >> > >> > I'm careful in saying.. and curious about.. >> > >> > In restrictive cases like only addtions happen but never deletion, can't >> > we safely traverse a llist? I believe llist can be more useful if we can >> > release the restriction. Can't we? >> > >> > If yes, we may add another function traversing starting from a head. Or >> > just use existing funtion with head->first. >> > >> > Thank a lot for your answers in advance :) >> >> What's the use case? I don't know how it is useful that items are never >> deleted from the llist. >> >> Some other locks could be used to provide mutual exclusive between >> >> - llist add, llist traverse > > Hello Huang, Hello Byungchul, > In my use case, I only do adding and traversing on a llist. Can you provide more details about your use case? Best Regards, Huang, Ying >> >> and >> >> - llist delete > > Of course, I will use a lock when deletion is needed. > > So.. in the case only adding into and traversing a llist is needed, > can't we safely traverse a llist in the way I thought? Or am I missing > something? > > Thank you. > >> Is this your use case? >> >> Best Regards, >> Huang, Ying
linux-next: manual merge of the pinctrl tree with the devicetree tree
Hi all,
Today's linux-next merge of the pinctrl tree got a conflict in:
Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
between commit:
791d3ef2e111 ("dt-bindings: remove 'interrupt-parent' from bindings")
from the devicetree tree and commit:
de1d08b22974 ("dt-bindings: pinctrl: add syscfg mask parameter")
from the pinctrl 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 Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
index a8bb36b4f9fd,046a3de026d4..
--- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
@@@ -37,9 -37,12 +37,10 @@@ Required properties
Optional properties:
- reset: : Reference to the reset controller
- - st,syscfg: Should be phandle/offset pair. The phandle to the syscon node
-which includes IRQ mux selection register, and the offset of the IRQ mux
-selection register.
- - interrupt-parent: phandle of the interrupt parent to which the external
- GPIO interrupts are forwarded to.
+ - st,syscfg: Should be phandle/offset/mask.
+ -The phandle to the syscon node which includes IRQ mux selection
register.
+ -The offset of the IRQ mux selection register
+ -The field mask of IRQ mux, needed if different of 0xf.
- gpio-ranges: Define a dedicated mapping between a pin-controller and
a gpio controller. Format is <&phandle a b c> with:
-(phandle): phandle of pin-controller.
pgpfMdD2St4cR.pgp
Description: OpenPGP digital signature
[PATCH v4 03/10] arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and Makefile
From: Ben Ho
Add basic chip support for Mediatek 8183
Signed-off-by: Ben Ho
Signed-off-by: Erin Lo
---
arch/arm64/boot/dts/mediatek/Makefile | 1 +
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 23 +
arch/arm64/boot/dts/mediatek/mt8183.dtsi| 146
3 files changed, 170 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-evb.dts
create mode 100644 arch/arm64/boot/dts/mediatek/mt8183.dtsi
diff --git a/arch/arm64/boot/dts/mediatek/Makefile
b/arch/arm64/boot/dts/mediatek/Makefile
index 7506b0d..a91d462 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -6,3 +6,4 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt8183-evb.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
new file mode 100644
index 000..2a3dd5a
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Ben Ho
+ *Erin Lo
+ */
+
+/dts-v1/;
+#include "mt8183.dtsi"
+
+/ {
+ model = "MediaTek MT8183 evaluation board";
+ compatible = "mediatek,mt8183-evb", "mediatek,mt8183";
+
+ memory@4000 {
+ device_type = "memory";
+ reg = <0 0x4000 0 0x8000>;
+ };
+
+ chosen {
+ stdout-path = "serial0:921600n8";
+ };
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
new file mode 100644
index 000..1553265
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -0,0 +1,146 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Ben Ho
+ *Erin Lo
+ */
+
+#include
+#include
+
+/ {
+ compatible = "mediatek,mt8183";
+ interrupt-parent = <&sysirq>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+ core1 {
+ cpu = <&cpu1>;
+ };
+ core2 {
+ cpu = <&cpu2>;
+ };
+ core3 {
+ cpu = <&cpu3>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&cpu4>;
+ };
+ core1 {
+ cpu = <&cpu5>;
+ };
+ core2 {
+ cpu = <&cpu6>;
+ };
+ core3 {
+ cpu = <&cpu7>;
+ };
+ };
+ };
+
+ cpu0: cpu@000 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x000>;
+ enable-method = "psci";
+ };
+
+ cpu1: cpu@001 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x001>;
+ enable-method = "psci";
+ };
+
+ cpu2: cpu@002 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x002>;
+ enable-method = "psci";
+ };
+
+ cpu3: cpu@003 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53";
+ reg = <0x003>;
+ enable-method = "psci";
+ };
+
+ cpu4: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a73";
+ reg = <0x100>;
+ enable-method = "psci";
+ };
+
+ cpu5: cpu@101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a73";
+ reg = <0x101>;
+ enable-method = "psci";
+ };
+
+ cpu6: cpu@102 {
+ device_type = "cpu";
+
[PATCH v4 09/10] dt-bindings: serial: Add compatible for Mediatek MT8183
This adds dt-binding documentation of uart for Mediatek MT8183 SoC Platform. Signed-off-by: Erin Lo Acked-by: Rob Herring --- Documentation/devicetree/bindings/serial/mtk-uart.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt b/Documentation/devicetree/bindings/serial/mtk-uart.txt index f73abff..4783336 100644 --- a/Documentation/devicetree/bindings/serial/mtk-uart.txt +++ b/Documentation/devicetree/bindings/serial/mtk-uart.txt @@ -15,6 +15,7 @@ Required properties: * "mediatek,mt8127-uart" for MT8127 compatible UARTS * "mediatek,mt8135-uart" for MT8135 compatible UARTS * "mediatek,mt8173-uart" for MT8173 compatible UARTS + * "mediatek,mt8183-uart", "mediatek,mt6577-uart" for MT8183 compatible UARTS * "mediatek,mt6577-uart" for MT6577 and all of the above - reg: The base address of the UART register bank. -- 1.9.1
[PATCH v4 05/10] clk: mediatek: Add dt-bindings for MT8183 clocks
From: Weiyi Lu Add MT8183 clock dt-bindings, include topckgen, apmixedsys, infracfg and subsystem clocks. Signed-off-by: Weiyi Lu Signed-off-by: Erin Lo --- include/dt-bindings/clock/mt8183-clk.h | 413 + 1 file changed, 413 insertions(+) create mode 100644 include/dt-bindings/clock/mt8183-clk.h diff --git a/include/dt-bindings/clock/mt8183-clk.h b/include/dt-bindings/clock/mt8183-clk.h new file mode 100644 index 000..bacad53 --- /dev/null +++ b/include/dt-bindings/clock/mt8183-clk.h @@ -0,0 +1,413 @@ +/* SPDX-License-Identifier: GPL-2.0 + * + * Copyright (c) 2018 MediaTek Inc. + * Author: Weiyi Lu + */ + +#ifndef _DT_BINDINGS_CLK_MT8183_H +#define _DT_BINDINGS_CLK_MT8183_H + +/* APMIXED */ +#define CLK_APMIXED_ARMPLL_LL 0 +#define CLK_APMIXED_ARMPLL_L 1 +#define CLK_APMIXED_CCIPLL 2 +#define CLK_APMIXED_MAINPLL3 +#define CLK_APMIXED_UNIV2PLL 4 +#define CLK_APMIXED_MSDCPLL5 +#define CLK_APMIXED_MMPLL 6 +#define CLK_APMIXED_MFGPLL 7 +#define CLK_APMIXED_TVDPLL 8 +#define CLK_APMIXED_APLL1 9 +#define CLK_APMIXED_APLL2 10 +#define CLK_APMIXED_SSUSB_26M 11 +#define CLK_APMIXED_APPLL_26M 12 +#define CLK_APMIXED_MIPIC0_26M 13 +#define CLK_APMIXED_MDPLLGP_26M14 +#define CLK_APMIXED_MMSYS_26M 15 +#define CLK_APMIXED_UFS_26M16 +#define CLK_APMIXED_MIPIC1_26M 17 +#define CLK_APMIXED_MEMPLL_26M 18 +#define CLK_APMIXED_CLKSQ_LVPLL_26M19 +#define CLK_APMIXED_MIPID0_26M 20 +#define CLK_APMIXED_MIPID1_26M 21 +#define CLK_APMIXED_NR_CLK 22 + +/* TOPCKGEN */ +#define CLK_TOP_MUX_AXI0 +#define CLK_TOP_MUX_MM 1 +#define CLK_TOP_MUX_CAM2 +#define CLK_TOP_MUX_MFG3 +#define CLK_TOP_MUX_CAMTG 4 +#define CLK_TOP_MUX_UART 5 +#define CLK_TOP_MUX_SPI6 +#define CLK_TOP_MUX_MSDC50_0_HCLK 7 +#define CLK_TOP_MUX_MSDC50_0 8 +#define CLK_TOP_MUX_MSDC30_1 9 +#define CLK_TOP_MUX_MSDC30_2 10 +#define CLK_TOP_MUX_AUDIO 11 +#define CLK_TOP_MUX_AUD_INTBUS 12 +#define CLK_TOP_MUX_FPWRAP_ULPOSC 13 +#define CLK_TOP_MUX_SCP14 +#define CLK_TOP_MUX_ATB15 +#define CLK_TOP_MUX_SSPM 16 +#define CLK_TOP_MUX_DPI0 17 +#define CLK_TOP_MUX_SCAM 18 +#define CLK_TOP_MUX_AUD_1 19 +#define CLK_TOP_MUX_AUD_2 20 +#define CLK_TOP_MUX_DISP_PWM 21 +#define CLK_TOP_MUX_SSUSB_TOP_XHCI 22 +#define CLK_TOP_MUX_USB_TOP23 +#define CLK_TOP_MUX_SPM24 +#define CLK_TOP_MUX_I2C25 +#define CLK_TOP_MUX_F52M_MFG 26 +#define CLK_TOP_MUX_SENINF 27 +#define CLK_TOP_MUX_DXCC 28 +#define CLK_TOP_MUX_CAMTG2 29 +#define CLK_TOP_MUX_AUD_ENG1 30 +#define CLK_TOP_MUX_AUD_ENG2 31 +#define CLK_TOP_MUX_FAES_UFSFDE32 +#define CLK_TOP_MUX_FUFS 33 +#define CLK_TOP_MUX_IMG34 +#define CLK_TOP_MUX_DSP35 +#define CLK_TOP_MUX_DSP1 36 +#define CLK_TOP_MUX_DSP2 37 +#define CLK_TOP_MUX_IPU_IF 38 +#define CLK_TOP_MUX_CAMTG3 39 +#define CLK_TOP_MUX_CAMTG4 40 +#define CLK_TOP_MUX_PMICSPI41 +#define CLK_TOP_SYSPLL_CK 42 +#define CLK_TOP_SYSPLL_D2 43 +#define CLK_TOP_SYSPLL_D3 44 +#define CLK_TOP_SYSPLL_D5 45 +#define CLK_TOP_SYSPLL_D7 46 +#define CLK_TOP_SYSPLL_D2_D2 47 +#define CLK_TOP_SYSPLL_D2_D4 48 +#define CLK_TOP_SYSPLL_D2_D8 49 +#define CLK_TOP_SYSPLL_D2_D16 50 +#define CLK_TOP_SYSPLL_D3_D2 51 +#define CLK_TOP_SYSPLL_D3_D4 52 +#define CLK_TOP_SYSPLL_D3_D8 53 +#define CLK_TOP_SYSPLL_D5_D2 54 +#define CLK_TOP_SYSPLL_D5_D4 55 +#define CLK_TOP_SYSPLL_D7_D2 56 +#define CLK_TOP_SYSPLL_D7_D4 57 +#define CLK_TOP_UNIVPLL_CK 58 +#define CLK_TOP_UNIVPLL_D2 59 +#define CLK_TOP_UNIVPLL_D3 60 +#define CLK_TOP_UNIVPLL_D5 61 +#define CLK_TOP_UNIVPLL_D7 62 +#define CLK_TOP_UNIVPLL_D2_D2 63 +#define CLK_TOP_UNIVPLL_D2_D4 64 +#define CLK_TOP_UNIVPLL_D2_D8 65 +#define CLK_TOP_UNIVPLL_D3_D2 66 +#define CLK_TOP_UNIVPLL_D3_D4 67 +#define CLK_TOP_UNIVPLL_D3_D8 68 +#define CLK_TOP_UNIVPLL_D5_D2 69 +#define CLK_TOP_UNIVPLL_D5_D4 70 +#define CLK_TOP_UNIVPLL_D5_D8 71 +#define CLK_TOP_APLL1_CK 72 +#define CLK_TOP_APLL1_D2
[PATCH v4 08/10] arm64: dts: mt8183: Add clock controller device nodes
From: Weiyi Lu
Add clock controller nodes for MT8183, include topckgen, infracfg,
apmixedsys and subsystem.
Signed-off-by: Weiyi Lu
Signed-off-by: Erin Lo
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 92
1 file changed, 92 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 1553265..6b87a24 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -5,6 +5,7 @@
*Erin Lo
*/
+#include
#include
#include
@@ -112,6 +113,13 @@
method = "smc";
};
+ clk26m: oscillator@0 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2600>;
+ clock-output-names = "clk26m";
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupt-parent = <&gic>;
@@ -143,4 +151,88 @@
interrupt-parent = <&gic>;
reg = <0 0x0c530a80 0 0x50>;
};
+
+ topckgen: syscon@1000 {
+ compatible = "mediatek,mt8183-topckgen", "syscon";
+ reg = <0 0x1000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ infracfg: syscon@10001000 {
+ compatible = "mediatek,mt8183-infracfg", "syscon";
+ reg = <0 0x10001000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ apmixedsys: syscon@1000c000 {
+ compatible = "mediatek,mt8183-apmixedsys", "syscon";
+ reg = <0 0x1000c000 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ audiosys: syscon@1122 {
+ compatible = "mediatek,mt8183-audiosys", "syscon";
+ reg = <0 0x1122 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ mfgcfg: syscon@1300 {
+ compatible = "mediatek,mt8183-mfgcfg", "syscon";
+ reg = <0 0x1300 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ mmsys: syscon@1400 {
+ compatible = "mediatek,mt8183-mmsys", "syscon";
+ reg = <0 0x1400 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ imgsys: syscon@1502 {
+ compatible = "mediatek,mt8183-imgsys", "syscon";
+ reg = <0 0x1502 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ vdecsys: syscon@1600 {
+ compatible = "mediatek,mt8183-vdecsys", "syscon";
+ reg = <0 0x1600 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ vencsys: syscon@1700 {
+ compatible = "mediatek,mt8183-vencsys", "syscon";
+ reg = <0 0x1700 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ ipu_conn: syscon@1900 {
+ compatible = "mediatek,mt8183-ipu_conn", "syscon";
+ reg = <0 0x1900 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ ipu_adl: syscon@1901 {
+ compatible = "mediatek,mt8183-ipu_adl", "syscon";
+ reg = <0 0x1901 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ ipu_core0: syscon@1918 {
+ compatible = "mediatek,mt8183-ipu_core0", "syscon";
+ reg = <0 0x1918 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ ipu_core1: syscon@1928 {
+ compatible = "mediatek,mt8183-ipu_core1", "syscon";
+ reg = <0 0x1928 0 0x1000>;
+ #clock-cells = <1>;
+ };
+
+ camsys: syscon@1a00 {
+ compatible = "mediatek,mt8183-camsys", "syscon";
+ reg = <0 0x1a00 0 0x1000>;
+ #clock-cells = <1>;
+ };
};
--
1.9.1
[PATCH v4 06/10] clk: mediatek: Add flags support for mtk_gate data
From: Weiyi Lu
On some Mediatek platforms, there are critical clocks of
clock gate type.
To register clock gate with flags CLK_IS_CRITICAL,
we need to add the flags field in mtk_gate data and register APIs.
Signed-off-by: Weiyi Lu
Signed-off-by: Erin Lo
---
drivers/clk/mediatek/clk-gate.c | 5 +++--
drivers/clk/mediatek/clk-gate.h | 3 ++-
drivers/clk/mediatek/clk-mtk.c | 3 ++-
drivers/clk/mediatek/clk-mtk.h | 1 +
4 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/mediatek/clk-gate.c b/drivers/clk/mediatek/clk-gate.c
index 934bf0e..25d25c3 100644
--- a/drivers/clk/mediatek/clk-gate.c
+++ b/drivers/clk/mediatek/clk-gate.c
@@ -157,7 +157,8 @@ struct clk *mtk_clk_register_gate(
int clr_ofs,
int sta_ofs,
u8 bit,
- const struct clk_ops *ops)
+ const struct clk_ops *ops,
+ unsigned int flags)
{
struct mtk_clk_gate *cg;
struct clk *clk;
@@ -168,7 +169,7 @@ struct clk *mtk_clk_register_gate(
return ERR_PTR(-ENOMEM);
init.name = name;
- init.flags = CLK_SET_RATE_PARENT;
+ init.flags = flags | CLK_SET_RATE_PARENT;
init.parent_names = parent_name ? &parent_name : NULL;
init.num_parents = parent_name ? 1 : 0;
init.ops = ops;
diff --git a/drivers/clk/mediatek/clk-gate.h b/drivers/clk/mediatek/clk-gate.h
index 72ef89b..631cd3a 100644
--- a/drivers/clk/mediatek/clk-gate.h
+++ b/drivers/clk/mediatek/clk-gate.h
@@ -47,6 +47,7 @@ struct clk *mtk_clk_register_gate(
int clr_ofs,
int sta_ofs,
u8 bit,
- const struct clk_ops *ops);
+ const struct clk_ops *ops,
+ unsigned int flags);
#endif /* __DRV_CLK_GATE_H */
diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
index 50becd0..15310f8 100644
--- a/drivers/clk/mediatek/clk-mtk.c
+++ b/drivers/clk/mediatek/clk-mtk.c
@@ -131,7 +131,8 @@ int mtk_clk_register_gates(struct device_node *node,
gate->regs->set_ofs,
gate->regs->clr_ofs,
gate->regs->sta_ofs,
- gate->shift, gate->ops);
+ gate->shift, gate->ops,
+ gate->flags);
if (IS_ERR(clk)) {
pr_err("Failed to register clk %s: %ld\n",
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index 61693f6..c3285ff 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -217,6 +217,7 @@ struct mtk_gate {
const struct mtk_gate_regs *regs;
int shift;
const struct clk_ops *ops;
+ unsigned int flags;
};
int mtk_clk_register_gates(struct device_node *node,
--
1.9.1
[PATCH v4 04/10] dt-bindings: ARM: Mediatek: Document bindings for MT8183
From: Weiyi Lu This patch adds the binding documentation for apmixedsys, audiosys, camsys, imgsys, infracfg, mfgcfg, mmsys, topckgen, vdecsys, vencsys and ipu for Mediatek MT8183. Signed-off-by: Weiyi Lu Signed-off-by: Erin Lo --- .../bindings/arm/mediatek/mediatek,apmixedsys.txt | 1 + .../bindings/arm/mediatek/mediatek,audsys.txt | 1 + .../bindings/arm/mediatek/mediatek,camsys.txt | 1 + .../bindings/arm/mediatek/mediatek,imgsys.txt | 1 + .../bindings/arm/mediatek/mediatek,infracfg.txt| 1 + .../bindings/arm/mediatek/mediatek,ipu.txt | 43 ++ .../bindings/arm/mediatek/mediatek,mfgcfg.txt | 1 + .../bindings/arm/mediatek/mediatek,mmsys.txt | 1 + .../bindings/arm/mediatek/mediatek,topckgen.txt| 1 + .../bindings/arm/mediatek/mediatek,vdecsys.txt | 1 + .../bindings/arm/mediatek/mediatek,vencsys.txt | 1 + 11 files changed, 53 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,ipu.txt diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt index 44eaeac..fddcec8 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt @@ -13,6 +13,7 @@ Required Properties: - "mediatek,mt7622-apmixedsys" - "mediatek,mt8135-apmixedsys" - "mediatek,mt8173-apmixedsys" + - "mediatek,mt8183-apmixedsys", "syscon" - #clock-cells: Must be 1 The apmixedsys controller uses the common clk binding from diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt index 9a8672a..63dcc82 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt @@ -9,6 +9,7 @@ Required Properties: - "mediatek,mt2701-audsys", "syscon" - "mediatek,mt6765-audsys", "syscon" - "mediatek,mt7622-audsys", "syscon" + - "mediatek,mt8183-audiosys", "syscon" - #clock-cells: Must be 1 The AUDSYS controller uses the common clk binding from diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt index dc75783..918ccb6 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,camsys.txt @@ -7,6 +7,7 @@ Required Properties: - compatible: Should be one of: - "mediatek,mt6765-camsys", "syscon" + - "mediatek,mt8183-camsys", "syscon" - #clock-cells: Must be 1 The AUDSYS controller uses the common clk binding from diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt index c7057d0..aeee5c8 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt @@ -11,6 +11,7 @@ Required Properties: - "mediatek,mt6765-imgsys", "syscon" - "mediatek,mt6797-imgsys", "syscon" - "mediatek,mt8173-imgsys", "syscon" + - "mediatek,mt8183-imgsys", "syscon" - #clock-cells: Must be 1 The imgsys controller uses the common clk binding from diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt index ac6aae5..1b292ec 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt @@ -14,6 +14,7 @@ Required Properties: - "mediatek,mt7622-infracfg", "syscon" - "mediatek,mt8135-infracfg", "syscon" - "mediatek,mt8173-infracfg", "syscon" + - "mediatek,mt8183-infracfg", "syscon" - #clock-cells: Must be 1 - #reset-cells: Must be 1 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ipu.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ipu.txt new file mode 100644 index 000..aabc8c5 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ipu.txt @@ -0,0 +1,43 @@ +Mediatek IPU controller + + +The Mediatek ipu controller provides various clocks to the system. + +Required Properties: + +- compatible: Should be one of: + - "mediatek,mt8183-ipu_conn", "syscon" + - "mediatek,mt8183-ipu_adl", "syscon" + - "mediatek,mt8183-ipu_core0", "syscon" + - "mediatek,mt8183-ipu_core1", "syscon" +- #clock-cells: Must be 1 + +The ipu controller uses the common clk binding from +Documentation/devicetree/bindings/clock/clock-bindings.txt +The available clocks are defined in dt-bindings/clock/mt*-clk.h. + +Example: +
[PATCH v4 02/10] dt-bindings: mtk-sysirq: Add compatible for Mediatek MT8183
This adds dt-binding documentation of SYSIRQ for Mediatek MT8183 SoC Platform. Signed-off-by: Erin Lo Acked-by: Rob Herring --- .../devicetree/bindings/interrupt-controller/mediatek,sysirq.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt index 07bf0b9..5ff48a8 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt @@ -5,6 +5,7 @@ interrupt. Required properties: - compatible: should be + "mediatek,mt8183-sysirq", "mediatek,mt6577-sysirq": for MT8183 "mediatek,mt8173-sysirq", "mediatek,mt6577-sysirq": for MT8173 "mediatek,mt8135-sysirq", "mediatek,mt6577-sysirq": for MT8135 "mediatek,mt8127-sysirq", "mediatek,mt6577-sysirq": for MT8127 -- 1.9.1
[PATCH v4 07/10] clk: mediatek: Add MT8183 clock support
From: Weiyi Lu Add MT8183 clock support, include topckgen, apmixedsys, infracfg and subsystem clocks. Signed-off-by: Weiyi Lu Signed-off-by: Erin Lo --- drivers/clk/mediatek/Kconfig | 74 ++ drivers/clk/mediatek/Makefile | 12 + drivers/clk/mediatek/clk-mt8183-audio.c| 112 +++ drivers/clk/mediatek/clk-mt8183-cam.c | 75 ++ drivers/clk/mediatek/clk-mt8183-img.c | 75 ++ drivers/clk/mediatek/clk-mt8183-ipu0.c | 68 ++ drivers/clk/mediatek/clk-mt8183-ipu1.c | 68 ++ drivers/clk/mediatek/clk-mt8183-ipu_adl.c | 66 ++ drivers/clk/mediatek/clk-mt8183-ipu_conn.c | 155 drivers/clk/mediatek/clk-mt8183-mfgcfg.c | 66 ++ drivers/clk/mediatek/clk-mt8183-mm.c | 128 +++ drivers/clk/mediatek/clk-mt8183-vdec.c | 84 ++ drivers/clk/mediatek/clk-mt8183-venc.c | 71 ++ drivers/clk/mediatek/clk-mt8183.c | 1230 14 files changed, 2284 insertions(+) create mode 100644 drivers/clk/mediatek/clk-mt8183-audio.c create mode 100644 drivers/clk/mediatek/clk-mt8183-cam.c create mode 100644 drivers/clk/mediatek/clk-mt8183-img.c create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu0.c create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu1.c create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu_adl.c create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu_conn.c create mode 100644 drivers/clk/mediatek/clk-mt8183-mfgcfg.c create mode 100644 drivers/clk/mediatek/clk-mt8183-mm.c create mode 100644 drivers/clk/mediatek/clk-mt8183-vdec.c create mode 100644 drivers/clk/mediatek/clk-mt8183-venc.c create mode 100644 drivers/clk/mediatek/clk-mt8183.c diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig index 95e5e52..e70c164 100644 --- a/drivers/clk/mediatek/Kconfig +++ b/drivers/clk/mediatek/Kconfig @@ -194,6 +194,80 @@ config COMMON_CLK_MT8173 ---help--- This driver supports MediaTek MT8173 clocks. +config COMMON_CLK_MT8183 + bool "Clock driver for MediaTek MT8183" + depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST + select COMMON_CLK_MEDIATEK + default ARCH_MEDIATEK && ARM64 + help + This driver supports MediaTek MT8183 basic clocks. + +config COMMON_CLK_MT8183_AUDIOSYS + bool "Clock driver for MediaTek MT8183 audiosys" + depends on COMMON_CLK_MT8183 + help + This driver supports MediaTek MT8183 audiosys clocks. + +config COMMON_CLK_MT8183_CAMSYS + bool "Clock driver for MediaTek MT8183 camsys" + depends on COMMON_CLK_MT8183 + help + This driver supports MediaTek MT8183 camsys clocks. + +config COMMON_CLK_MT8183_IMGSYS + bool "Clock driver for MediaTek MT8183 imgsys" + depends on COMMON_CLK_MT8183 + help + This driver supports MediaTek MT8183 imgsys clocks. + +config COMMON_CLK_MT8183_IPU_CORE0 + bool "Clock driver for MediaTek MT8183 ipu_core0" + depends on COMMON_CLK_MT8183 + help + This driver supports MediaTek MT8183 ipu_core0 clocks. + +config COMMON_CLK_MT8183_IPU_CORE1 + bool "Clock driver for MediaTek MT8183 ipu_core1" + depends on COMMON_CLK_MT8183 + help + This driver supports MediaTek MT8183 ipu_core1 clocks. + +config COMMON_CLK_MT8183_IPU_ADL + bool "Clock driver for MediaTek MT8183 ipu_adl" + depends on COMMON_CLK_MT8183 + help + This driver supports MediaTek MT8183 ipu_adl clocks. + +config COMMON_CLK_MT8183_IPU_CONN + bool "Clock driver for MediaTek MT8183 ipu_conn" + depends on COMMON_CLK_MT8183 + help + This driver supports MediaTek MT8183 ipu_conn clocks. + +config COMMON_CLK_MT8183_MFGCFG + bool "Clock driver for MediaTek MT8183 mfgcfg" + depends on COMMON_CLK_MT8183 + help + This driver supports MediaTek MT8183 mfgcfg clocks. + +config COMMON_CLK_MT8183_MMSYS + bool "Clock driver for MediaTek MT8183 mmsys" + depends on COMMON_CLK_MT8183 + help + This driver supports MediaTek MT8183 mmsys clocks. + +config COMMON_CLK_MT8183_VDECSYS + bool "Clock driver for MediaTek MT8183 vdecsys" + depends on COMMON_CLK_MT8183 + help + This driver supports MediaTek MT8183 vdecsys clocks. + +config COMMON_CLK_MT8183_VENCSYS + bool "Clock driver for MediaTek MT8183 vencsys" + depends on COMMON_CLK_MT8183 + help + This driver supports MediaTek MT8183 vencsys clocks. + config COMMON_CLK_MT6765 bool "Clock driver for MediaTek MT6765" depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile index b455a8e..13e6919 100644 --- a/drivers/clk/mediatek/Makefile +++ b/drivers/clk/mediatek/Makefile @@ -35,3 +35,15 @@ obj-$(CONFIG_COMMON_CLK_MT7622_HIFSYS) += clk-mt7622-hif.o obj-$(CONFIG_COMMON_CLK_MT7622_AUDSYS) += clk-mt7622-aud.o obj-$(CONFIG_COMMON_C
[PATCH v4 10/10] dts: arm64: mt8183: add uart node
From: Weiyi Lu
Add uart node with correct uart clocks.
Signed-off-by: Erin Lo
Signed-off-by: Weiyi Lu
---
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 8
arch/arm64/boot/dts/mediatek/mt8183.dtsi| 30 +
2 files changed, 38 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
index 2a3dd5a..9b52559 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8183-evb.dts
@@ -12,6 +12,10 @@
model = "MediaTek MT8183 evaluation board";
compatible = "mediatek,mt8183-evb", "mediatek,mt8183";
+ aliases {
+ serial0 = &uart0;
+ };
+
memory@4000 {
device_type = "memory";
reg = <0 0x4000 0 0x8000>;
@@ -21,3 +25,7 @@
stdout-path = "serial0:921600n8";
};
};
+
+&uart0 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 6b87a24..c22a2dc 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -170,6 +170,36 @@
#clock-cells = <1>;
};
+ uart0: serial@11002000 {
+ compatible = "mediatek,mt8183-uart",
+"mediatek,mt6577-uart";
+ reg = <0 0x11002000 0 0x1000>;
+ interrupts = ;
+ clocks = <&clk26m>, <&infracfg CLK_INFRA_UART0>;
+ clock-names = "baud", "bus";
+ status = "disabled";
+ };
+
+ uart1: serial@11003000 {
+ compatible = "mediatek,mt8183-uart",
+"mediatek,mt6577-uart";
+ reg = <0 0x11003000 0 0x1000>;
+ interrupts = ;
+ clocks = <&clk26m>, <&infracfg CLK_INFRA_UART1>;
+ clock-names = "baud", "bus";
+ status = "disabled";
+ };
+
+ uart2: serial@11004000 {
+ compatible = "mediatek,mt8183-uart",
+"mediatek,mt6577-uart";
+ reg = <0 0x11004000 0 0x1000>;
+ interrupts = ;
+ clocks = <&clk26m>, <&infracfg CLK_INFRA_UART2>;
+ clock-names = "baud", "bus";
+ status = "disabled";
+ };
+
audiosys: syscon@1122 {
compatible = "mediatek,mt8183-audiosys", "syscon";
reg = <0 0x1122 0 0x1000>;
--
1.9.1
[PATCH v4 00/10] Add basic and clock support for Mediatek MT8183 SoC
MT8183 is a SoC based on 64bit ARMv8 architecture. It contains 4 CA53 and 4 CA73 cores. MT8183 share many HW IP with MT65xx series. This patchset was tested on MT8183 evaluation board and use correct clock to shell. This series contains document bindings, device tree including interrupt, uart, clock. Based on v4.18-rc1 and https://patchwork.kernel.org/patch/10528515/ Composed of clock control (PATCH 5-8) and device tree (PATCH 9-10) Change in v4: 1. Correct syntax error in dtsi 2. Add MT8183 clock support Change in v3: 1. Fill out GICC, GICH, GICV regions 2. Update Copyright to 2018 Change in v2: 1. Split dt-bindings into different patches 2. Correct bindings for supported SoCs (mtk-uart.txt) Ben Ho (1): arm64: dts: Add Mediatek SoC MT8183 and evaluation board dts and Makefile Erin Lo (3): dt-bindings: arm: Add bindings for Mediatek MT8183 SoC Platform dt-bindings: mtk-sysirq: Add compatible for Mediatek MT8183 dt-bindings: serial: Add compatible for Mediatek MT8183 Weiyi Lu (6): dt-bindings: ARM: Mediatek: Document bindings for MT8183 clk: mediatek: Add dt-bindings for MT8183 clocks clk: mediatek: Add flags support for mtk_gate data clk: mediatek: Add MT8183 clock support arm64: dts: mt8183: Add clock controller device nodes dts: arm64: mt8183: add uart node Documentation/devicetree/bindings/arm/mediatek.txt |4 + .../bindings/arm/mediatek/mediatek,apmixedsys.txt |1 + .../bindings/arm/mediatek/mediatek,audsys.txt |1 + .../bindings/arm/mediatek/mediatek,camsys.txt |1 + .../bindings/arm/mediatek/mediatek,imgsys.txt |1 + .../bindings/arm/mediatek/mediatek,infracfg.txt|1 + .../bindings/arm/mediatek/mediatek,ipu.txt | 43 + .../bindings/arm/mediatek/mediatek,mfgcfg.txt |1 + .../bindings/arm/mediatek/mediatek,mmsys.txt |1 + .../bindings/arm/mediatek/mediatek,topckgen.txt|1 + .../bindings/arm/mediatek/mediatek,vdecsys.txt |1 + .../bindings/arm/mediatek/mediatek,vencsys.txt |1 + .../interrupt-controller/mediatek,sysirq.txt |1 + .../devicetree/bindings/serial/mtk-uart.txt|1 + arch/arm64/boot/dts/mediatek/Makefile |1 + arch/arm64/boot/dts/mediatek/mt8183-evb.dts| 31 + arch/arm64/boot/dts/mediatek/mt8183.dtsi | 268 + drivers/clk/mediatek/Kconfig | 74 ++ drivers/clk/mediatek/Makefile | 12 + drivers/clk/mediatek/clk-gate.c|5 +- drivers/clk/mediatek/clk-gate.h|3 +- drivers/clk/mediatek/clk-mt8183-audio.c| 112 ++ drivers/clk/mediatek/clk-mt8183-cam.c | 75 ++ drivers/clk/mediatek/clk-mt8183-img.c | 75 ++ drivers/clk/mediatek/clk-mt8183-ipu0.c | 68 ++ drivers/clk/mediatek/clk-mt8183-ipu1.c | 68 ++ drivers/clk/mediatek/clk-mt8183-ipu_adl.c | 66 ++ drivers/clk/mediatek/clk-mt8183-ipu_conn.c | 155 +++ drivers/clk/mediatek/clk-mt8183-mfgcfg.c | 66 ++ drivers/clk/mediatek/clk-mt8183-mm.c | 128 ++ drivers/clk/mediatek/clk-mt8183-vdec.c | 84 ++ drivers/clk/mediatek/clk-mt8183-venc.c | 71 ++ drivers/clk/mediatek/clk-mt8183.c | 1230 drivers/clk/mediatek/clk-mtk.c |3 +- drivers/clk/mediatek/clk-mtk.h |1 + include/dt-bindings/clock/mt8183-clk.h | 413 +++ 36 files changed, 3064 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,ipu.txt create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-evb.dts create mode 100644 arch/arm64/boot/dts/mediatek/mt8183.dtsi create mode 100644 drivers/clk/mediatek/clk-mt8183-audio.c create mode 100644 drivers/clk/mediatek/clk-mt8183-cam.c create mode 100644 drivers/clk/mediatek/clk-mt8183-img.c create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu0.c create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu1.c create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu_adl.c create mode 100644 drivers/clk/mediatek/clk-mt8183-ipu_conn.c create mode 100644 drivers/clk/mediatek/clk-mt8183-mfgcfg.c create mode 100644 drivers/clk/mediatek/clk-mt8183-mm.c create mode 100644 drivers/clk/mediatek/clk-mt8183-vdec.c create mode 100644 drivers/clk/mediatek/clk-mt8183-venc.c create mode 100644 drivers/clk/mediatek/clk-mt8183.c create mode 100644 include/dt-bindings/clock/mt8183-clk.h -- 1.9.1
[PATCH v4 01/10] dt-bindings: arm: Add bindings for Mediatek MT8183 SoC Platform
This adds dt-binding documentation of cpu for Mediatek MT8183. Signed-off-by: Erin Lo Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/arm/mediatek.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt b/Documentation/devicetree/bindings/arm/mediatek.txt index 7d21ab3..2754535 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.txt +++ b/Documentation/devicetree/bindings/arm/mediatek.txt @@ -19,6 +19,7 @@ compatible: Must contain one of "mediatek,mt8127" "mediatek,mt8135" "mediatek,mt8173" + "mediatek,mt8183" Supported boards: @@ -73,3 +74,6 @@ Supported boards: - MTK mt8173 tablet EVB: Required root node properties: - compatible = "mediatek,mt8173-evb", "mediatek,mt8173"; +- Evaluation board for MT8183: +Required root node properties: + - compatible = "mediatek,mt8183-evb", "mediatek,mt8183"; -- 1.9.1
Contact my secretary in Burkina-Faso
Dear Friend, Good day, this is Mr. Henri Zongo, I'm happy to inform you about my success in getting the fund $29.6Million transferred under the co-operation of a new partner from Dubai, Presently I'm in Dubai for investment projects with my own share of the total sum. Meanwhile,I didn't forget your past efforts and attempts to assist me in transferring those funds despite that it failed us some how. Now contact my secretary in Burkina-Faso, his name is Mr. Leonard Kabore and his email address is (leonard_kab...@outlook.com) and ask him to send you VISA ATM CARD which has loaded the sum of USD$1,000,000.00 (One Million United States Dollars issued in your name by our Bank (BOA) headquarter, this is for your compensation for all the past efforts and attempts to assist me in this matter. Note, you will withdraw your money in an ATM MACHINE in any part of the world, but the maximum is ($5,000) Fifteen Thousand Us Dollars in three transactions per day. So feel free and get in touched with my secretary and instruct him where to send the VISA ATM CARD to you. Please do let me know immediately you receive the ATM CARD so that we can share the joy. Please my main reason to compensate you with this amount is for you to keep your mouth shut, do not allow anybody to know about this deal ever, let it to be sealed between us because I don't want to have any problem in the future please!. This is how we contributed for your compensation, I contributed $600,000 dollars out of my own share while my new partner contributed, $400,000 dollars to make the total of $1,000,000.00 USD,please let the deal be sealed ok! delete every message you received so far concerning this deal in your mailbox. In the moment, I am very busy here because of the investment projects which me and the new partner are having at hand, finally, remember that I had forwarded instruction to my secretary on your behalf to receive that VISA ATM CARD, so feel free to get in touch with him and he will help you to send it to your address. I will be traveling to Qatar this evening with my partner for an investment project. Regards, Mr. Henri Zongo. Contact my secretary in Burkina-Faso
Re: [alsa-devel] [PATCH] ASoC: soc-pcm: Use delay set in pointer function
On Tue, 31 Jul 2018 03:25:06 +0200, Agrawal, Akshu wrote: > > > > On 7/30/2018 9:20 PM, Mark Brown wrote: > > On Mon, Jul 30, 2018 at 05:32:21PM +0200, Takashi Iwai wrote: > > > >> That said, if delay callback of CPU dai provides the additional delay, > >> the patch does correct thing. OTOH, if CPU dai provides the base > >> delay instead, we need to clarify that it's rather a must; the delay > >> calculation in pointer callback becomes bogus in this scenario. > > > > Part of the theory here is that every component might have a delay > > independently of the rest and we need to add them all together to figure > > out what the system as a whole will see. Personally I'd rather just > > have everything use a callack consistently to avoid confusion. > > > > For consistency we can add a delay callback in snd_pcm_ops and modify > the drivers which directly assigning runtime->delay to use the callback. No, ALSA PCM ops definition is fine. The delay calculation is basically tied with the position, hence it has to be set together, and that's the pointer callback. Judging from the call pattern, the current design of ASoC delay callback implies that the return value is more or less constant, which can be accumulated on top of the base value. So your patch is natural from that POV. OTOH, if the CPU dai can really provide a dynamic value that is strictly tied with pointer, CPU dai itself should provide the pointer callback that covers both the pointer and the base delay, and it should be used instead of component pointer callback. > Apart from the 2 drivers mentioned in commit message I also found > sound/usb to be doing the same and its delay getting lost. The USB driver hasn't been used in ASoC, no? thanks, Takashi
Re: [QUESTION] llist: Comment releasing 'must delete' restriction before traversing
On Tue, Jul 31, 2018 at 09:37:50AM +0800, Huang, Ying wrote: > Byungchul Park writes: > > > Hello folks, > > > > I'm careful in saying.. and curious about.. > > > > In restrictive cases like only addtions happen but never deletion, can't > > we safely traverse a llist? I believe llist can be more useful if we can > > release the restriction. Can't we? > > > > If yes, we may add another function traversing starting from a head. Or > > just use existing funtion with head->first. > > > > Thank a lot for your answers in advance :) > > What's the use case? I don't know how it is useful that items are never > deleted from the llist. > > Some other locks could be used to provide mutual exclusive between > > - llist add, llist traverse Hello Huang, In my use case, I only do adding and traversing on a llist. > > and > > - llist delete Of course, I will use a lock when deletion is needed. So.. in the case only adding into and traversing a llist is needed, can't we safely traverse a llist in the way I thought? Or am I missing something? Thank you. > Is this your use case? > > Best Regards, > Huang, Ying
Re: [PATCH] clk: scmi: Fix the rounding of clock rate
On Mon, Jul 30, 2018 at 5:10 PM, Sudeep Holla wrote:
> On Mon, Jul 30, 2018 at 11:03:51AM +0530, Amit Daniel Kachhap wrote:
>> Hi,
>>
>> On Fri, Jul 27, 2018 at 10:07 PM, Stephen Boyd wrote:
>> > Quoting Amit Daniel Kachhap (2018-07-27 07:01:52)
>> >> This fix rounds the clock rate properly by using quotient and not
>> >> remainder in the calculation. This issue was found while testing HDMI
>> >> in the Juno platform.
>> >>
>> >> Signed-off-by: Amit Daniel Kachhap
>> >
>> > Any Fixes: tag here?
>> Yes, This patch is tested with Linux v4.18-rc6 tag.
>>
>
> No Stephen meant the commit that this fixes, something like below:
>
> Fixes: 6d6a1d82eaef ("clk: add support for clocks provided by SCMI")
>
> so that it can get backported if required.
ok my mistake. Thanks for the clarification.
>
> --
> Regards,
> Sudeep
linux-next: manual merge of the mux tree with the battery tree
Hi all,
Today's linux-next merge of the mux tree got a conflict in:
MAINTAINERS
between commit:
fe8e81b7e899 ("adp5061: New driver for ADP5061 I2C battery charger")
from the battery tree and commit:
703160ff3e50 ("dt-bindings: mux: add adi,adgs1408")
from the mux 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 MAINTAINERS
index db24b8939ed4,eaa2b55a0e9b..
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -829,13 -810,12 +829,19 @@@ L: linux-me...@vger.kernel.or
S:Maintained
F:drivers/media/i2c/ad9389b*
+ ANALOG DEVICES INC ADGS1408 DRIVER
+ M:Mircea Caprioru
+ S:Supported
+ F:drivers/mux/adgs1408.c
+ F:Documentation/devicetree/bindings/mux/adgs1408.txt
+
+ANALOG DEVICES INC ADP5061 DRIVER
+M:Stefan Popa
+L:linux...@vger.kernel.org
+W:http://ez.analog.com/community/linux-device-drivers
+S:Supported
+F:drivers/power/supply/adp5061.c
+
ANALOG DEVICES INC ADV7180 DRIVER
M:Lars-Peter Clausen
L:linux-me...@vger.kernel.org
pgpHFmoGP9bOt.pgp
Description: OpenPGP digital signature
[tip:perf/urgent] perf/x86/intel/uncore: Fix hardcoded index of Broadwell extra PCI devices
Commit-ID: 99811294b063eb44185df9a58923928fccdbe122
Gitweb: https://git.kernel.org/tip/99811294b063eb44185df9a58923928fccdbe122
Author: Kan Liang
AuthorDate: Mon, 30 Jul 2018 08:28:08 -0400
Committer: Ingo Molnar
CommitDate: Mon, 30 Jul 2018 20:13:58 +0200
perf/x86/intel/uncore: Fix hardcoded index of Broadwell extra PCI devices
Masayoshi Mizuma reported that a warning message is shown while a CPU is
hot-removed on Broadwell servers:
WARNING: CPU: 126 PID: 6 at arch/x86/events/intel/uncore.c:988
uncore_pci_remove+0x10b/0x150
Call Trace:
pci_device_remove+0x42/0xd0
device_release_driver_internal+0x148/0x220
pci_stop_bus_device+0x76/0xa0
pci_stop_root_bus+0x44/0x60
acpi_pci_root_remove+0x1f/0x80
acpi_bus_trim+0x57/0x90
acpi_bus_trim+0x2e/0x90
acpi_device_hotplug+0x2bc/0x4b0
acpi_hotplug_work_fn+0x1a/0x30
process_one_work+0x174/0x3a0
worker_thread+0x4c/0x3d0
kthread+0xf8/0x130
This bug was introduced by:
commit 15a3e845b01c ("perf/x86/intel/uncore: Fix SBOX support for Broadwell
CPUs")
The index of "QPI Port 2 filter" was hardcode to 2, but this conflicts with the
index of "PCU.3" which is "HSWEP_PCI_PCU_3", which equals to 2 as well.
To fix the conflict, the hardcoded index needs to be cleaned up:
- introduce a new enumerator "BDX_PCI_QPI_PORT2_FILTER" for "QPI Port 2
filter" on Broadwell,
- increase UNCORE_EXTRA_PCI_DEV_MAX by one,
- clean up the hardcoded index.
Debugged-by: Masayoshi Mizuma
Suggested-by: Ingo Molnar
Reported-by: Masayoshi Mizuma
Tested-by: Masayoshi Mizuma
Signed-off-by: Kan Liang
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Thomas Gleixner
Cc: Vince Weaver
Cc: msys.miz...@gmail.com
Cc: sta...@vger.kernel.org
Fixes: 15a3e845b01c ("perf/x86/intel/uncore: Fix SBOX support for Broadwell
CPUs")
Link:
http://lkml.kernel.org/r/1532953688-15008-1-git-send-email-kan.li...@linux.intel.com
Signed-off-by: Ingo Molnar
---
arch/x86/events/intel/uncore.h | 2 +-
arch/x86/events/intel/uncore_snbep.c | 10 +++---
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/x86/events/intel/uncore.h b/arch/x86/events/intel/uncore.h
index c9e1e0bef3c3..e17ab885b1e9 100644
--- a/arch/x86/events/intel/uncore.h
+++ b/arch/x86/events/intel/uncore.h
@@ -28,7 +28,7 @@
#define UNCORE_PCI_DEV_TYPE(data) ((data >> 8) & 0xff)
#define UNCORE_PCI_DEV_IDX(data) (data & 0xff)
#define UNCORE_EXTRA_PCI_DEV 0xff
-#define UNCORE_EXTRA_PCI_DEV_MAX 3
+#define UNCORE_EXTRA_PCI_DEV_MAX 4
#define UNCORE_EVENT_CONSTRAINT(c, n) EVENT_CONSTRAINT(c, n, 0xff)
diff --git a/arch/x86/events/intel/uncore_snbep.c
b/arch/x86/events/intel/uncore_snbep.c
index 87dc0263a2e1..51d7c117e3c7 100644
--- a/arch/x86/events/intel/uncore_snbep.c
+++ b/arch/x86/events/intel/uncore_snbep.c
@@ -1029,6 +1029,7 @@ void snbep_uncore_cpu_init(void)
enum {
SNBEP_PCI_QPI_PORT0_FILTER,
SNBEP_PCI_QPI_PORT1_FILTER,
+ BDX_PCI_QPI_PORT2_FILTER,
HSWEP_PCI_PCU_3,
};
@@ -3286,15 +3287,18 @@ static const struct pci_device_id bdx_uncore_pci_ids[]
= {
},
{ /* QPI Port 0 filter */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x6f86),
- .driver_data = UNCORE_PCI_DEV_DATA(UNCORE_EXTRA_PCI_DEV, 0),
+ .driver_data = UNCORE_PCI_DEV_DATA(UNCORE_EXTRA_PCI_DEV,
+ SNBEP_PCI_QPI_PORT0_FILTER),
},
{ /* QPI Port 1 filter */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x6f96),
- .driver_data = UNCORE_PCI_DEV_DATA(UNCORE_EXTRA_PCI_DEV, 1),
+ .driver_data = UNCORE_PCI_DEV_DATA(UNCORE_EXTRA_PCI_DEV,
+ SNBEP_PCI_QPI_PORT1_FILTER),
},
{ /* QPI Port 2 filter */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x6f46),
- .driver_data = UNCORE_PCI_DEV_DATA(UNCORE_EXTRA_PCI_DEV, 2),
+ .driver_data = UNCORE_PCI_DEV_DATA(UNCORE_EXTRA_PCI_DEV,
+ BDX_PCI_QPI_PORT2_FILTER),
},
{ /* PCU.3 (for Capability registers) */
PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x6fc0),
Re: [RFC] blk-mq: clean up the hctx restart
Hi Ming On 07/31/2018 12:58 PM, Ming Lei wrote: > On Tue, Jul 31, 2018 at 12:02:15PM +0800, Jianchao Wang wrote: >> Currently, we will always set SCHED_RESTART whenever there are >> requests in hctx->dispatch, then when request is completed and >> freed the hctx queues will be restarted to avoid IO hang. This >> is unnecessary most of time. Especially when there are lots of >> LUNs attached to one host, the RR restart loop could be very >> expensive. > > The big RR restart loop has been killed in the following commit: > > commit 97889f9ac24f8d2fc8e703ea7f80c162bab10d4d > Author: Ming Lei > Date: Mon Jun 25 19:31:48 2018 +0800 > > blk-mq: remove synchronize_rcu() from blk_mq_del_queue_tag_set() > > Oh, sorry, I didn't look into this patch due to its title when iterated the mail list, therefore I didn't realize the RR restart loop has already been killed. :) The RR restart loop could ensure the fairness of sharing some LLDD resource, not just avoid IO hung. Is it OK to kill it totally ? Thanks Jianchao
Re: [PATCH] mm,page_alloc: PF_WQ_WORKER threads must sleep at should_reclaim_retry().
On Tue 31-07-18 06:01:48, Tetsuo Handa wrote:
> On 2018/07/31 4:10, Michal Hocko wrote:
> > Since should_reclaim_retry() should be a natural reschedule point,
> > let's do the short sleep for PF_WQ_WORKER threads unconditionally in
> > order to guarantee that other pending work items are started. This will
> > workaround this problem and it is less fragile than hunting down when
> > the sleep is missed. E.g. we used to have a sleeping point in the oom
> > path but this has been removed recently because it caused other issues.
> > Having a single sleeping point is more robust.
>
> linux.git has not removed the sleeping point in the OOM path yet. Since
> removing the
> sleeping point in the OOM path can mitigate CVE-2016-10723, please do so
> immediately.
is this an {Acked,Reviewed,Tested}-by?
I will send the patch to Andrew if the patch is ok.
> (And that change will conflict with Roman's cgroup aware OOM killer patchset.
> But it
> should be easy to rebase.)
That is still a WIP so I would lose sleep over it.
--
Michal Hocko
SUSE Labs
Re: [PATCH 0/2] dt: thermal: Fix broken cooling-maps
On 05-07-18, 10:39, Viresh Kumar wrote: > Hi, > > This is an attempt to fix the broken or partially defined DT bindings > for cooling-maps. We should list every device that participates in > cooling down at a certain trip point, instead of just the first in the > list as that depends on certain ordering of events to work properly. > > The first patch extends the binding to allow a list of phandles in > "cooling-device" property and the second patch fixes one of the > platform's DT. > > This will be followed up by fixing all platform DT bindings that have > these issues after this set is accepted. > > The kernel also requires some changes to handle the phandle list, but > wouldn't break with these changes as it reads the first phandle in the > list for now. We can update that separately. @Zhang: Are you going to apply this for 4.19-rc1 ? There are lot of patches that I am holding up until this gets merged. -- viresh
Re: [PATCH v7 0/4] ARM: davinci: complete the conversion to using the reset framework
On Mon 02 Jul 05:08 PDT 2018, Sekhar Nori wrote: > Hi Bjorn, > > On Thursday 21 June 2018 05:11 PM, Bartosz Golaszewski wrote: > > 2018-06-21 12:52 GMT+02:00 Sekhar Nori : > >> Hi Bartosz, > >> > >> On Thursday 21 June 2018 01:07 PM, Bartosz Golaszewski wrote: > >>> From: Bartosz Golaszewski > >>> > >>> These are the remaining patches that still need to be merged in order > >>> to complete the conversion of the davinci dsp driver to using the reset > >>> framework. > >>> > >>> They apply on top of v4.18-rc1 with David Lechner's remaining patches > >>> merged. > >> > >> Series looks good to me. > >> > >> To preserve bisect, shouldn't the order of applying be patch #3, #4, #1 > >> and #2 ? > >> > >> Given the dependencies and to preserve bisect its easiest if I take the > >> series with acks from remoteproc and clock maintainers. > >> > >> Open to other suggestions as well. > >> > >> Thanks, > >> Sekhar > > > > Oops you're right about the order. Do you want me to resend? > > With your ack, I can queue 1/4 for v4.19 and provide an immutable commit > to you (on top of v4.18-rc1) for you to merge any further changes you > want to queue from your tree. > I'm not sure why I didn't see your request earlier, sorry about that. I seem to have one other davinci patch from Suman, which should be possible to merge without any conflicts. So there's no need for an immutable branch at this time. Regards, Bjorn
Re: [QUESTION] llist: Comment releasing 'must delete' restriction before traversing
On Tue, Jul 31, 2018 at 09:58:36AM +0900, Byungchul Park wrote: > Hello folks, > > I'm careful in saying.. and curious about.. > > In restrictive cases like only addtions happen but never deletion, can't > we safely traverse a llist? I believe llist can be more useful if we can > release the restriction. Can't we? Yes, but please give a thought to the people looking at your code some time down the line. If you are doing this, lots of comments, please. Here are the approaches that I am aware of: 1. Normal RCU. Use list_add_rcu(), list_del_rcu(), and friends. 2. Things are added but never deleted. Use list_add_rcu() and friends, but since you don't ever delete anything, you never use list_del_rcu(), synchronize_rcu(), call_rcu(), and friends. 3. Things are added, but deletion deletes the entire list. You need to use something like list_del_rcu() to handle this, and you need synchronize_rcu(), call_rcu(), and friends. So really not all that much different than #1. 4. Things are added, but deletions happen during some sort of maintenance phase during which there are no readers. This is really easy to get wrong -- all you have to do is let one little reader slip in and all is broken. Also the maintenance phases often take longer than planned. (We used a trick somewhat like this back when I worked on the dormitory system back at university the first time around, but we had the advantage of everyone using the system being in the same timezone and the system being taken down every night anyway.) 5. Just mark the deleted elements, but leave them in the list. Actually remove them using one of the above techniques. There are probably others, but those come to mind immediately. I suggest that such special cases stay in the subsystem in question. If a given technique gains wider use, then it might be time to update header comments. > If yes, we may add another function traversing starting from a head. Or > just use existing funtion with head->first. If you start with head->first, then you need to make sure that a concurrent add of an element at the head of the list works. You need at least a READ_ONCE() and preferably an rcu_dereference() or similar. > Thank a lot for your answers in advance :) You did ask! Thanx, Paul > ->8- > >From 1e73882799b269cd86e7a7c955021e3a18d1e6cf Mon Sep 17 00:00:00 2001 > From: Byungchul Park > Date: Tue, 31 Jul 2018 09:31:57 +0900 > Subject: [QUESTION] llist: Comment releasing 'must delete' restriction before > traversing > > llist traversing can run without deletion in restrictive cases all > items are added but never deleted like a rculist traversing such as > list_for_each_entry_lockless. So add the comment. > > Signed-off-by: Byungchul Park > --- > include/linux/llist.h | 24 ++-- > 1 file changed, 18 insertions(+), 6 deletions(-) > > diff --git a/include/linux/llist.h b/include/linux/llist.h > index 85abc29..d012d3e 100644 > --- a/include/linux/llist.h > +++ b/include/linux/llist.h > @@ -32,8 +32,12 @@ > * operation, with "-" being no lock needed, while "L" being lock is needed. > * > * The list entries deleted via llist_del_all can be traversed with > - * traversing function such as llist_for_each etc. But the list > - * entries can not be traversed safely before deleted from the list. > + * traversing function such as llist_for_each etc. Normally the list > + * entries cannot be traversed safely before deleted from the list > + * except the cases items are added to the list but never deleted. In > + * that restrictive cases the list may be safely traversed concurrently > + * with llist_add. > + * > * The order of deleted entries is from the newest to the oldest added > * one. If you want to traverse from the oldest to the newest, you > * must reverse the order by yourself before traversing. > @@ -116,7 +120,9 @@ static inline void init_llist_head(struct llist_head > *list) > * > * In general, some entries of the lock-less list can be traversed > * safely only after being deleted from list, so start with an entry > - * instead of list head. > + * instead of list head. But in restrictive cases items are added to > + * the list but never deleted, the list may be safely traversed > + * concurrently with llist_add. > * > * If being used on entries deleted from lock-less list directly, the > * traverse order is from the newest to the oldest added entry. If > @@ -135,7 +141,9 @@ static inline void init_llist_head(struct llist_head > *list) > * > * In general, some entries of the lock-less list can be traversed > * safely only after being deleted from list, so start with an entry > - * instead of list head. > + * instead of list head. But in restrictive cases items are added to > + * the list but never de
Re: [RFC] dmaengine: Add metadat_ops for dma_async_tx_descriptor
On 30-07-18, 12:46, Peter Ujfalusi wrote: > Vinod, > > On 2018-07-24 14:14, Vinod wrote: > Clients must not mix the two way of handling the metadata. > The set_len() is intended to tell the DMA driver the client provided > metadata size (in MEM_TO_DEV case mostly). > > MEM_TO_DEV flow on client side: > get_ptr() > fill in the metadata to the pointer (not exceeding max_len) > set_len() to tell the DMA driver the amount of valid bytes written > > DEV_TO_MEM flow on client side: > In the completion callback, get_ptr() > the metadata is payload_len bytes and can be accessed in the return > pointer. > >>> > >>> I would think to unify this.. > >> > >> I have tried it, but the attach mode and the pointer mode is hard to > >> handle with a generic API. > >> I will try to find a way to unify things in a sane way. > > > > Hmmm, looking from the description they will be for different methods, > > so lets make them orthogonal and not allow driver to register both. > > I would allow DMA drivers to register both, but somehow enforce that > clients are not mixing the two distinct way of dealing with the metadata. > > The reason for that is for example the attach mode is the simplest (I > implemented it first and I have a client using it), but if the pointer > mode is found to be more efficient and feasible for the DMA then the DMA > driver can implement that mode and the client can move as well w/o > breaking anything. Sounds reasonable... -- ~Vinod
Re: [PATCH] timers: Clear must_forward_clk inside base lock
Hi John, Thomas,
Can you please review below patch and update your comments:
Regards
Gaurav
On 7/26/2018 2:12 PM, Gaurav Kohli wrote:
While migrating timer to new base, there is a need
to update base clk by calling forward_timer_base to
avoid stale clock , but at the same time if run_timer
is exectuing in new core it may set must_forward_clk
to false and due to this forward base logic may fail as
per below check:
if (likely(!base->must_forward_clk))
return;
So preventing the same by putting must_forward_clk inside
base lock.
Signed-off-by: Gaurav Kohli
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index cc2d23e..675241d 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1657,6 +1657,19 @@ static inline void __run_timers(struct timer_base *base)
raw_spin_lock_irq(&base->lock);
+ /*
+* must_forward_clk must be cleared before running timers so that any
+* timer functions that call mod_timer will not try to forward the
+* base. idle trcking / clock forwarding logic is only used with
+* BASE_STD timers.
+*
+* The deferrable base does not do idle tracking at all, so we do
+* not forward it. This can result in very large variations in
+* granularity for deferrable timers, but they can be deferred for
+* long periods due to idle.
+*/
+ base->must_forward_clk = false;
+
while (time_after_eq(jiffies, base->clk)) {
levels = collect_expired_timers(base, heads);
@@ -1676,19 +1689,6 @@ static __latent_entropy void run_timer_softirq(struct
softirq_action *h)
{
struct timer_base *base = this_cpu_ptr(&timer_bases[BASE_STD]);
- /*
-* must_forward_clk must be cleared before running timers so that any
-* timer functions that call mod_timer will not try to forward the
-* base. idle trcking / clock forwarding logic is only used with
-* BASE_STD timers.
-*
-* The deferrable base does not do idle tracking at all, so we do
-* not forward it. This can result in very large variations in
-* granularity for deferrable timers, but they can be deferred for
-* long periods due to idle.
-*/
- base->must_forward_clk = false;
-
__run_timers(base);
if (IS_ENABLED(CONFIG_NO_HZ_COMMON))
__run_timers(this_cpu_ptr(&timer_bases[BASE_DEF]));
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
Re: [PATCH v7 1/4] remoteproc/davinci: use the reset framework
On Thu 21 Jun 00:37 PDT 2018, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Switch to using the reset framework instead of handcoded reset routines
> we used so far.
>
> Signed-off-by: Bartosz Golaszewski
> Reviewed-by: Sekhar Nori
> Reviewed-by: Philipp Zabel
Acked-by: Bjorn Andersson
Regards,
Bjorn
> ---
> drivers/remoteproc/da8xx_remoteproc.c | 34 +++
> 1 file changed, 29 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/remoteproc/da8xx_remoteproc.c
> b/drivers/remoteproc/da8xx_remoteproc.c
> index b668e32996e2..76c06b70a1c6 100644
> --- a/drivers/remoteproc/da8xx_remoteproc.c
> +++ b/drivers/remoteproc/da8xx_remoteproc.c
> @@ -10,6 +10,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -20,8 +21,6 @@
> #include
> #include
>
> -#include/* for davinci_clk_reset_assert/deassert() */
> -
> #include "remoteproc_internal.h"
>
> static char *da8xx_fw_name;
> @@ -72,6 +71,7 @@ struct da8xx_rproc {
> struct da8xx_rproc_mem *mem;
> int num_mems;
> struct clk *dsp_clk;
> + struct reset_control *dsp_reset;
> void (*ack_fxn)(struct irq_data *data);
> struct irq_data *irq_data;
> void __iomem *chipsig;
> @@ -138,6 +138,7 @@ static int da8xx_rproc_start(struct rproc *rproc)
> struct device *dev = rproc->dev.parent;
> struct da8xx_rproc *drproc = (struct da8xx_rproc *)rproc->priv;
> struct clk *dsp_clk = drproc->dsp_clk;
> + struct reset_control *dsp_reset = drproc->dsp_reset;
> int ret;
>
> /* hw requires the start (boot) address be on 1KB boundary */
> @@ -155,7 +156,12 @@ static int da8xx_rproc_start(struct rproc *rproc)
> return ret;
> }
>
> - davinci_clk_reset_deassert(dsp_clk);
> + ret = reset_control_deassert(dsp_reset);
> + if (ret) {
> + dev_err(dev, "reset_control_deassert() failed: %d\n", ret);
> + clk_disable_unprepare(dsp_clk);
> + return ret;
> + }
>
> return 0;
> }
> @@ -163,8 +169,15 @@ static int da8xx_rproc_start(struct rproc *rproc)
> static int da8xx_rproc_stop(struct rproc *rproc)
> {
> struct da8xx_rproc *drproc = rproc->priv;
> + struct device *dev = rproc->dev.parent;
> + int ret;
> +
> + ret = reset_control_assert(drproc->dsp_reset);
> + if (ret) {
> + dev_err(dev, "reset_control_assert() failed: %d\n", ret);
> + return ret;
> + }
>
> - davinci_clk_reset_assert(drproc->dsp_clk);
> clk_disable_unprepare(drproc->dsp_clk);
>
> return 0;
> @@ -232,6 +245,7 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
> struct resource *bootreg_res;
> struct resource *chipsig_res;
> struct clk *dsp_clk;
> + struct reset_control *dsp_reset;
> void __iomem *chipsig;
> void __iomem *bootreg;
> int irq;
> @@ -268,6 +282,15 @@ static int da8xx_rproc_probe(struct platform_device
> *pdev)
> return PTR_ERR(dsp_clk);
> }
>
> + dsp_reset = devm_reset_control_get_exclusive(dev, NULL);
> + if (IS_ERR(dsp_reset)) {
> + if (PTR_ERR(dsp_reset) != -EPROBE_DEFER)
> + dev_err(dev, "unable to get reset control: %ld\n",
> + PTR_ERR(dsp_reset));
> +
> + return PTR_ERR(dsp_reset);
> + }
> +
> if (dev->of_node) {
> ret = of_reserved_mem_device_init(dev);
> if (ret) {
> @@ -287,6 +310,7 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
> drproc = rproc->priv;
> drproc->rproc = rproc;
> drproc->dsp_clk = dsp_clk;
> + drproc->dsp_reset = dsp_reset;
> rproc->has_iommu = false;
>
> ret = da8xx_rproc_get_internal_memories(pdev, drproc);
> @@ -309,7 +333,7 @@ static int da8xx_rproc_probe(struct platform_device *pdev)
>* *not* in reset, but da8xx_rproc_start() needs the DSP to be
>* held in reset at the time it is called.
>*/
> - ret = davinci_clk_reset_assert(drproc->dsp_clk);
> + ret = reset_control_assert(dsp_reset);
> if (ret)
> goto free_rproc;
>
> --
> 2.17.1
>
Re: Linux 4.18-rc7
On Mon, Jul 30, 2018 at 8:26 PM, Hugh Dickins wrote: > On Mon, 30 Jul 2018, Linus Torvalds wrote: >> On Mon, Jul 30, 2018 at 2:53 PM Hugh Dickins wrote: >> > >> > I have no problem with reverting -rc7's vma_is_anonymous() series. >> >> I don't think we need to revert the whole series: I think the rest are >> all fairly obvious cleanups, and shouldn't really have any semantic >> changes. > > Okay. > >> >> It's literally only that last patch in the series that then changes >> that meaning of "vm_ops". And I don't really _mind_ that last step >> either, but since we don't know exactly what it was that it broke, and >> we're past rc7, I don't think we really have any option but the revert >> it. > > It took me a long time to grasp what was happening, that that last > patch bfd40eaff5ab was fixing. Not quite explained in the commit. > > I think it was that by mistakenly passing the vma_is_anonymous() test, > create_huge_pmd() gave the MAP_PRIVATE kcov mapping a THP (instead of > COWing pages from kcov); which the truncate then had to split, and in > going to do so, again hit the mistaken vma_is_anonymous() test, BUG. > >> >> And if we revert it, I think we need to just remove the >> VM_BUG_ON_VMA() that it was supposed to fix. Because I do think that >> it is quite likely that the real bug is that overzealous BUG_ON(), >> since I can't see any reason why anonymous mappings should be special >> there. > > Yes, that probably has to go: but it's not clear what state it leaves > us in, with an anon THP being split by a truncate, without the expected > locking; I don't remember offhand, probably a subtler bug than that BUG, > which you may or may not consider an improvement. > > I fear that Kirill has not missed inserting a vma_set_anonymous() from > somewhere that it should be, but rather that zygote is working with some > special mapping which used to satisfy vma_is_anonymous(), faults supplying > backing pages, but now comes out as !vma_is_anonymous(), so do_fault() > finds !dummy_vm_ops.fault hence SIGBUS. I've been only casually following this thread (mostly just glad Amit caught it and I could avoid having to bisect the issue in my own Android testing), but this bit starting to shake a few old cobwebs loose in my brain. I'm wondering if Zygote is utilizing ashmem here, and we're somehow traversing ashmem purged memory, or due to some setup issue the initial traverse isn't being zero-filled as expected? ashmem ranges are created using: shmem_file_setup() and shmem_zero_setup() https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/android/ashmem.c#n377 If we purge pages, it punches it out with: vfs_fallocate(range->asma->file, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, start, end - start); here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/android/ashmem.c#n447 But in ashmem_pin(), we don't do anything other then returning if we purged any page in the range. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/android/ashmem.c#n577 And I believe the future assumption is the if we traverse those pages they will be zero filled (if purged or even during the initial traversal after mmap) Its been a long time, and I've not looked at the code in question but it sounds from Hugh's comments above that we might instead get a SIGBUS here. Looking more at the problematic patch.. Amit: Does adding something like (whitespace damaged, apologies): index a1a0025..1af6915 100644 --- a/drivers/staging/android/ashmem.c +++ b/drivers/staging/android/ashmem.c @@ -402,7 +402,8 @@ static int ashmem_mmap(struct file *file, struct vm_area_struct *vma) fput(asma->file); goto out; } - } + } else + vma_set_anonymous(vma); if (vma->vm_file) fput(vma->vm_file); Seem to resolve it? (Sorry, I'd test it myself, but I'm away from my desk for the night). thanks -john
linux-next: manual merge of the kvms390 tree with the kvm-arm tree
Hi all,
Today's linux-next merge of the kvms390 tree got a conflict in:
include/uapi/linux/kvm.h
between commit:
be26b3a73413 ("arm64: KVM: export the capability to set guest SError
syndrome")
from the kvm-arm tree and commit:
a449938297e5 ("KVM: s390: Add huge page enablement control")
from the kvms390 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 include/uapi/linux/kvm.h
index a7d9bc4e4068,b955b986b341..
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -949,7 -949,7 +949,8 @@@ struct kvm_ppc_resize_hpt
#define KVM_CAP_GET_MSR_FEATURES 153
#define KVM_CAP_HYPERV_EVENTFD 154
#define KVM_CAP_HYPERV_TLBFLUSH 155
-#define KVM_CAP_S390_HPAGE_1M 156
+#define KVM_CAP_ARM_INJECT_SERROR_ESR 156
++#define KVM_CAP_S390_HPAGE_1M 157
#ifdef KVM_CAP_IRQ_ROUTING
pgpJN026N_IXn.pgp
Description: OpenPGP digital signature
Re: [PATCH v0 3/4] drivers: edac: Add cache erp driver for Last Level Cache Controller (LLCC)
On Mon, Jul 30, 2018 at 02:38:01PM -0700, vnkgu...@codeaurora.org wrote: > Do you mean the Signed-off-by lines above? That's because > Channagoud is the one who is the original author of this driver, > and I'm the one who did the incremental changes (changes in llcc) > and uploading it upstream. > That's why the Signed-off is like that. > Which way do you think it should be? Then you need to figure out between you two who the author should be because we have single authorship. When you do, commit it in git with git commit --amend --author=... so that that is reflected properly. For expressing stuff like co-authorship we have Co-Developed-by: All explained in submitting-patches.rst. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --
Re: [PATCH] remoteproc: qcom: fix Q6V5_WCSS dependencies
On Wed 18 Jul 04:16 PDT 2018, Arnd Bergmann wrote:
> A new driver got added that depends on QCOM_SMD and fails to link
> as built-in with CONFIG_QCOM_SMD=m:
>
> drivers/remoteproc/qcom_common.o: In function `smd_subdev_stop':
> qcom_common.c:(.text+0x674): undefined reference to `qcom_smd_unregister_edge'
> drivers/remoteproc/qcom_common.o: In function `smd_subdev_start':
> qcom_common.c:(.text+0x700): undefined reference to `qcom_smd_register_edge'
>
> We've fixed the same thing several times before, so use the same
> dependency here.
>
I have a change where I remove this inherited dependency, so I asked
Sricharan to only depend on the ones he actually uses - but I forgot
that I haven't pushed this.
Sorry about screwing this up again. Thanks for catching it!
Regards,
Bjorn
> Fixes: 3a3d4163e0bf ("remoteproc: qcom: Introduce Hexagon V5 based WCSS
> driver")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/remoteproc/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 0dde3753c3a5..052d4dd347f9 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -127,6 +127,7 @@ config QCOM_Q6V5_WCSS
> tristate "Qualcomm Hexagon based WCSS Peripheral Image Loader"
> depends on OF && ARCH_QCOM
> depends on QCOM_SMEM
> + depends on RPMSG_QCOM_SMD || (COMPILE_TEST && RPMSG_QCOM_SMD=n)
> depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n
> depends on QCOM_SYSMON || QCOM_SYSMON=n
> select MFD_SYSCON
> --
> 2.9.0
>
Re: [PATCH 2/2] net/9p: add a per-client fcall kmem_cache
Matthew Wilcox wrote on Mon, Jul 30, 2018:
> On Mon, Jul 30, 2018 at 11:34:23AM +0200, Dominique Martinet wrote:
> > -static int p9_fcall_alloc(struct p9_fcall *fc, int alloc_msize)
> > +static int p9_fcall_alloc(struct p9_client *c, struct p9_fcall *fc,
> > + int alloc_msize)
> > {
> > - fc->sdata = kmalloc(alloc_msize, GFP_NOFS);
> > + if (c->fcall_cache && alloc_msize == c->msize)
> > + fc->sdata = kmem_cache_alloc(c->fcall_cache, GFP_NOFS);
> > + else
> > + fc->sdata = kmalloc(alloc_msize, GFP_NOFS);
>
> Could you simplify this by initialising c->msize to 0 and then this
> can simply be:
>
> > + if (alloc_msize == c->msize)
> ...
Hmm, this is rather tricky with the current flow of things;
p9_client_version() has multiple uses for that msize field.
Basically what happens is:
- init client struct, set clip msize to mount option/transport-specific
max
- p9_client_version() uses current c->msize to send a suggested value
to the server
- p9_client_rpc() uses current c->msize to allocate that first rpc,
this is pretty much hard-coded and will be quite intrusive to make an
exception for
- p9_client_version() looks at the msize the server suggested and clips
c->msize if the reply's is smaller than c->msize
I kind of agree it'd be nice to remove that check being done all the
time for just startup, but I don't see how to do this easily with the
current code.
Making p9_client_version take an extra argument would be easy but we'd
need to actually hardcode in p9_client_rpc that "if the message type is
TVERSION then use [page size or whatever] for allocation" and that kinds
of kills the point... The alternative being having p9_client_rpc takes
the actual size as argument itself but this once again is pretty
intrusive even if it could be done mechanically...
I'll think about this some more
> > +void p9_fcall_free(struct p9_client *c, struct p9_fcall *fc)
> > +{
> > + /* sdata can be NULL for interrupted requests in trans_rdma,
> > +* and kmem_cache_free does not do NULL-check for us
> > +*/
> > + if (unlikely(!fc->sdata))
> > + return;
> > +
> > + if (c->fcall_cache && fc->capacity == c->msize)
> > + kmem_cache_free(c->fcall_cache, fc->sdata);
> > + else
> > + kfree(fc->sdata);
> > +}
>
> Is it possible for fcall_cache to be allocated before fcall_free is
> called? I'm concerned we might do this:
>
> allocate message A
> allocate message B
> receive response A
> allocate fcall_cache
> receive response B
>
> and then we'd call kmem_cache_free() for something allocated by kmalloc(),
> which works with slab and slub, but doesn't work with slob (alas).
Bleh, I checked this would work for slab and didn't really check
others..
This cannot happen right now because we only return the client struct
from p9_client_create after the first message is done (and, right now,
freed) but when we start adding refcounting to requests it'd be possible
to free the very first response after fcall_cache is allocated with a
"bad" server like syzcaller does sending the version reply before the
request came in.
I can't see any work-around around this other than storing how the fcall
was allocated in the struct itself though...
I guess I might as well do that now, unless you have a better idea.
> > @@ -980,6 +1000,9 @@ struct p9_client *p9_client_create(const char
> > *dev_name, char *options)
> > if (err)
> > goto close_trans;
> >
> > + clnt->fcall_cache = kmem_cache_create("9p-fcall-cache", clnt->msize,
> > + 0, 0, NULL);
> > +
>
> If we have slab merging turned off, or we have two mounts from servers
> with different msizes, we'll end up with two slabs called 9p-fcall-cache.
> I'm OK with that, but are you?
Yeah, the reason I didn't make it global like p9_req_cache is precisely
to get two separate caches if the msizes are different.
I actually considered adding msize to the string with snprintf or
something but someone looking at it through slabinfo or similar will
have the sizes anyway so I don't think this would bring anything, do you
know if/think that tools will choke on multiple caches with the same
name?
I'm not sure about slab merging being disabled though, from the little I
understand I do not see why anyone would do that except for debugging,
and I'm fine with that.
Please let me know if I'm missing something though!
Thanks for the review,
--
Dominique Martinet
Re: [PATCH 34/38] vfs: syscall: Add fsinfo() to query filesystem information [ver #10]
On Fri, Jul 27, 2018 at 06:35:10PM +0100, David Howells wrote: > params->request indicates the attribute/attributes to be queried. This can > be one of: > > fsinfo_attr_statfs - statfs-style info > fsinfo_attr_fsinfo - Information about fsinfo() > fsinfo_attr_ids - Filesystem IDs > fsinfo_attr_limits - Filesystem limits > fsinfo_attr_supports- What's supported in statx(), IOC flags > fsinfo_attr_capabilities- Filesystem capabilities > fsinfo_attr_timestamp_info - Inode timestamp info > fsinfo_attr_volume_id - Volume ID (string) > fsinfo_attr_volume_uuid - Volume UUID > fsinfo_attr_volume_name - Volume name (string) > fsinfo_attr_cell_name - Cell name (string) > fsinfo_attr_domain_name - Domain name (string) > fsinfo_attr_realm_name - Realm name (string) > fsinfo_attr_server_name - Name of the Nth server (string) > fsinfo_attr_server_address - Mth address of the Nth server > fsinfo_attr_parameter - Nth mount parameter (string) > fsinfo_attr_source - Nth mount source name (string) > fsinfo_attr_name_encoding - Filename encoding (string) > fsinfo_attr_name_codepage - Filename codepage (string) > fsinfo_attr_io_size - I/O size hints Umm... What's so special about cell/volume/domain/realm? And what do we do when a random filesystem gets added - should its parameters go into catch-all pile (attr_parameter), or should they get classes of their own? For Cthulhu sake, who's going to maintain that enum in face of random out-of-tree filesystems, each wanting a class or two its own? We'd tried that with device numbers; ask hpa how well has that worked and how much did he love the whole experience...
Re: [PATCH] remoteproc: Reset table_ptr in rproc_start() failure paths
On Thu 26 Jul 18:15 PDT 2018, Suman Anna wrote:
> Unwind the modified table_ptr and restore it to the local copy
> upon any subsequent failures in the rproc_start() function. This
> keeps the function to remain balanced on failures without the need
> to balance any modified variables elsewhere.
>
Good catch.
> While at this, do some minor cleanup of the extra lines between
> the failure labels as well.
>
> Signed-off-by: Suman Anna
> ---
> drivers/remoteproc/remoteproc_core.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> index eadff6ce2f7f..afef2d491c5b 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -953,7 +953,7 @@ static int rproc_start(struct rproc *rproc, const struct
> firmware *fw)
> if (ret) {
> dev_err(dev, "failed to prepare subdevices for %s: %d\n",
> rproc->name, ret);
> - return ret;
> + goto reset_table_ptr;
> }
>
> /* power up the remote processor */
> @@ -979,10 +979,11 @@ static int rproc_start(struct rproc *rproc, const
> struct firmware *fw)
>
> stop_rproc:
> rproc->ops->stop(rproc);
> -
> unprepare_subdevices:
> rproc_unprepare_subdevices(rproc);
> -
> +reset_table_ptr:
> + if (loaded_table)
Regardless of us having a loaded_table it should have the same value as
cached_table when we return - which might be NULL if we don't have a
resource table.
So I applied this without the conditional, please object if I missed
something.
Regards,
Bjorn
> + rproc->table_ptr = rproc->cached_table;
> return ret;
> }
>
> --
> 2.18.0
>
What is the best way for car care? B1A336FA-3326-49FF-9579-DDD500C851D3
Dear Manager, Are you interested in clean car through below way? 1. Clean one car just using 2 liters water, 2. Just using water for car cleaning, no chemical, 3. Killing car bacteria and bad smelling in the car, 4. 360o comprehensive cleaning car, include car interior and exterior. GOCLEAN steam car washing machine can achieve above items, please contact us for more details. Best regards Lotus CHAN Mob.: +86 138 7319 2942 (Whatsapp, Skype, Viber, Wechat)
RE: [PATCH V2] x86/speculation: Support Enhanced IBRS on future CPUs
> There is no reason not to use indentation and quotation marks in a changelog. > Squeezing it into square brackets does not really improve readability. > > From the specification [1]: > > "With enhanced IBRS, the predicted targets of indirect branches executed >cannot be controlled by software that was executed in a less privileged > >to entering a sleep state such as MWAIT or HLT." > > Hmm? Yes, this looks good. I have changed commit message in V3 accordingly. > > x86_spec_ctrl_set_guest() before entering guest and > > x86_spec_ctrl_restore_host() after leaving guest. So, the guest view > > of SPEC_CTRL MSR is restored before entering guest and the host view > > of SPEC_CTRL MSR is restored before entering host and hence IBRS will > > be set after VMEXIT. > > What you are trying to say here is: > > If Enhanced IBRS is selected as mitigation mechanism the IBRS bit is set > once at > boot time and never cleared. This also has to be ensured after a VMEXIT > because the guest might have cleared the bit. This is already covered by the > existing x86_spec_ctrl_set_guest() and > x86_spec_ctrl_restore_host() speculation control functions. > > Hmm? Yes, that's correct. It's simple and concise. I have updated commit message as suggested. > > > Intel's white paper on Retpoline [2] says that "Retpoline is known to > > be an effective branch target injection (Spectre variant 2) mitigation > > on Intel processors belonging to family 6 (enumerated by the CPUID > > instruction) that do not have support for enhanced IBRS. On processors > > that support enhanced IBRS, it should be used for mitigation instead > > of retpoline." > > > > This means, Intel recommends using Enhanced IBRS over Retpoline where > > available and it also means that retpoline provides less mitigation on > > processors with enhanced IBRS compared to those without. > > The cited part of the white paper does not say that its a broader mitigation > than > what Retpoline covers. It merely recommends to use enhanced IBRS without > providing a reason. > > But chapter 4.3 contains the real reason for using Emhanced IBRS: The > processors which support it also support CET and CET does not work well with > Retpoline. > > Please provide facts and not interpretations. Sorry! got it. > If you have additional knowledge > about a broader mitigation scope, then clearly say so: > Hmm.. no.. not really. I just learned it from Dave. > > Hence, on processors that support Enhanced IBRS, this patch makes > > Enhanced IBRS as > > Please search Documentation/process/submitting-patches.rst for 'This patch' > > Yes, got it. Will refrain myself from using 'This patch' further. > The reason why 'Enhanced IBRS is the recommended mitigation on processors > which support it is that these processors also support CET which provides a > defense against ROP attacks. Retpoline is very similar to ROP techniques and > might trigger false positives in the CET defense. > > Enhanced IBRS still requires IBPB for full mitigation. > > See? You might have noticed that aside of restructuring and enhancing the > information I also got rid of all 'we' instances. Using 'we' is a form of > impersonation which IMO blurs the technicality of a changelog. Makes sense. Will stop using 'we' further. > > > > [1] > > https://software.intel.com/sites/default/files/managed/c5/63/336996-Sp > > eculative-Execution-Side-Channel-Mitigations.pdf > > [2] > > https://software.intel.com/sites/default/files/managed/1d/46/Retpoline > > -A-Branch-Target-Injection-Mitigation.pdf > > These links are not really useful as sooner than later they are going to be > invalid. > We recently started to put copies of such documents into the kernel.org > bugzilla > and I'm pretty sure we have at least one of them already in one of the > speculation mess related BZs. Could you please track that down and make sure > that both files are available there in the latest version. Then provide links > to the > BZ entry which are more likely to survive than content on a corporate website. > Sure! Makes sense. I have updated Bugzilla link that has these documents and also updated commit message in V3. > > @@ -219,6 +219,7 @@ > > #define X86_FEATURE_IBPB ( 7*32+26) /* Indirect Branch > Prediction Barrier */ > > #define X86_FEATURE_STIBP ( 7*32+27) /* Single Thread Indirect > Branch Predictors */ > > #define X86_FEATURE_ZEN( 7*32+28) /* "" CPU is AMD > family 0x17 (Zen) */ > > +#define X86_FEATURE_IBRS_ENHANCED ( 7*32+29) /* > "ibrs_enhanced" Use Enhanced IBRS in kernel */ > > That "ibrs_enhanced" part is not needed. Just wanted to confirm with you before removing it, Presently, on platforms that support features like arch_capabilities, stibp, ibrs and ibpb /proc/cpuinfo does show them. Do you think we should really skip showing Enhanced IBRS capability? > And 'Use' is also wrong. The feature > merily reflects the a
Do you know how long we need to clean carbon? D92EA61E-DAC1-400F-A050-3730030563A3
Dear， Do you know what is a HHO Carbon Cleaner ? We combine HHO carbon machine with HHO carbon cleaning. Thus achieving： 1. Reduce clean time, only 20 minutes. 2. Thoroughly clean the clean parts. 3. Cleaning effect increased by more than 30%. 4. Achieve the dual purpose of cleaning and maintenance. Now it's time to move on and we'll work together to win and win. New business and new distributor are waiting for you. P. S. A picture worth a thousand words.Please tell me your whatsapp or skype so we can sent you pictures and video. Looking forward to your reply! Best regards Lea
Re: [PATCH] arch/x86: Fix boot_cpu_data.microcode version output
On Mon, Jul 30, 2018 at 01:53:50PM -0400, Prarit Bhargava wrote: > I think this has to be > > boot_cpu_data.microcode = mc_amd->hdr.patch_id; Yes, it does. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --
Re: [PATCH] hwspinlock: Fix incorrect return pointers
On Mon 30 Jul 04:34 PDT 2018, Baolin Wang wrote:
> Hi Bjorn,
>
> On 28 June 2018 at 10:32, Baolin Wang wrote:
> > The commit 4f1acd758b08 ("hwspinlock: Add devm_xxx() APIs to request/free
> > hwlock") introduces one bug, that will return one error pointer if failed
> > to request one hwlock, but we expect NULL pointer on error for consumers.
> > This patch will fix this issue.
> >
> > Reported-by: Dan Carpenter
> > Signed-off-by: Baolin Wang
>
> Could you pick up this patch which fixes the incorrect return value
> issue? Thanks.
>
I thought I had picked this already, it's applied now. Sorry about the
delay.
Regards,
Bjorn
> > ---
> > drivers/hwspinlock/hwspinlock_core.c |8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/hwspinlock/hwspinlock_core.c
> > b/drivers/hwspinlock/hwspinlock_core.c
> > index e16d648..2bad40d 100644
> > --- a/drivers/hwspinlock/hwspinlock_core.c
> > +++ b/drivers/hwspinlock/hwspinlock_core.c
> > @@ -877,10 +877,10 @@ struct hwspinlock *devm_hwspin_lock_request(struct
> > device *dev)
> >
> > ptr = devres_alloc(devm_hwspin_lock_release, sizeof(*ptr),
> > GFP_KERNEL);
> > if (!ptr)
> > - return ERR_PTR(-ENOMEM);
> > + return NULL;
> >
> > hwlock = hwspin_lock_request();
> > - if (!IS_ERR(hwlock)) {
> > + if (hwlock) {
> > *ptr = hwlock;
> > devres_add(dev, ptr);
> > } else {
> > @@ -913,10 +913,10 @@ struct hwspinlock
> > *devm_hwspin_lock_request_specific(struct device *dev,
> >
> > ptr = devres_alloc(devm_hwspin_lock_release, sizeof(*ptr),
> > GFP_KERNEL);
> > if (!ptr)
> > - return ERR_PTR(-ENOMEM);
> > + return NULL;
> >
> > hwlock = hwspin_lock_request_specific(id);
> > - if (!IS_ERR(hwlock)) {
> > + if (hwlock) {
> > *ptr = hwlock;
> > devres_add(dev, ptr);
> > } else {
> > --
> > 1.7.9.5
> >
>
>
>
> --
> Baolin Wang
> Best Regards
[PATCH v7 2/6] Uprobe: Additional argument arch_uprobe to uprobe_write_opcode()
Add addition argument 'arch_uprobe' to uprobe_write_opcode().
We need this in later set of patches.
Signed-off-by: Ravi Bangoria
---
arch/arm/probes/uprobes/core.c | 2 +-
arch/mips/kernel/uprobes.c | 2 +-
include/linux/uprobes.h| 2 +-
kernel/events/uprobes.c| 9 +
4 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/arch/arm/probes/uprobes/core.c b/arch/arm/probes/uprobes/core.c
index d1329f1ba4e4..bf992264060e 100644
--- a/arch/arm/probes/uprobes/core.c
+++ b/arch/arm/probes/uprobes/core.c
@@ -32,7 +32,7 @@ bool is_swbp_insn(uprobe_opcode_t *insn)
int set_swbp(struct arch_uprobe *auprobe, struct mm_struct *mm,
unsigned long vaddr)
{
- return uprobe_write_opcode(mm, vaddr,
+ return uprobe_write_opcode(auprobe, mm, vaddr,
__opcode_to_mem_arm(auprobe->bpinsn));
}
diff --git a/arch/mips/kernel/uprobes.c b/arch/mips/kernel/uprobes.c
index f7a0645ccb82..4aaff3b3175c 100644
--- a/arch/mips/kernel/uprobes.c
+++ b/arch/mips/kernel/uprobes.c
@@ -224,7 +224,7 @@ unsigned long arch_uretprobe_hijack_return_addr(
int __weak set_swbp(struct arch_uprobe *auprobe, struct mm_struct *mm,
unsigned long vaddr)
{
- return uprobe_write_opcode(mm, vaddr, UPROBE_SWBP_INSN);
+ return uprobe_write_opcode(auprobe, mm, vaddr, UPROBE_SWBP_INSN);
}
void arch_uprobe_copy_ixol(struct page *page, unsigned long vaddr,
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index 0a294e950df8..bb9d2084af03 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -121,7 +121,7 @@ extern bool is_swbp_insn(uprobe_opcode_t *insn);
extern bool is_trap_insn(uprobe_opcode_t *insn);
extern unsigned long uprobe_get_swbp_addr(struct pt_regs *regs);
extern unsigned long uprobe_get_trap_addr(struct pt_regs *regs);
-extern int uprobe_write_opcode(struct mm_struct *mm, unsigned long vaddr,
uprobe_opcode_t);
+extern int uprobe_write_opcode(struct arch_uprobe *auprobe, struct mm_struct
*mm, unsigned long vaddr, uprobe_opcode_t);
extern int uprobe_register(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc);
extern int uprobe_apply(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc, bool);
extern void uprobe_unregister(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc);
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 471eac896635..c0418ba52ba8 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -299,8 +299,8 @@ static int verify_opcode(struct page *page, unsigned long
vaddr, uprobe_opcode_t
* Called with mm->mmap_sem held for write.
* Return 0 (success) or a negative errno.
*/
-int uprobe_write_opcode(struct mm_struct *mm, unsigned long vaddr,
- uprobe_opcode_t opcode)
+int uprobe_write_opcode(struct arch_uprobe *auprobe, struct mm_struct *mm,
+ unsigned long vaddr, uprobe_opcode_t opcode)
{
struct page *old_page, *new_page;
struct vm_area_struct *vma;
@@ -351,7 +351,7 @@ int uprobe_write_opcode(struct mm_struct *mm, unsigned long
vaddr,
*/
int __weak set_swbp(struct arch_uprobe *auprobe, struct mm_struct *mm,
unsigned long vaddr)
{
- return uprobe_write_opcode(mm, vaddr, UPROBE_SWBP_INSN);
+ return uprobe_write_opcode(auprobe, mm, vaddr, UPROBE_SWBP_INSN);
}
/**
@@ -366,7 +366,8 @@ int __weak set_swbp(struct arch_uprobe *auprobe, struct
mm_struct *mm, unsigned
int __weak
set_orig_insn(struct arch_uprobe *auprobe, struct mm_struct *mm, unsigned long
vaddr)
{
- return uprobe_write_opcode(mm, vaddr, *(uprobe_opcode_t
*)&auprobe->insn);
+ return uprobe_write_opcode(auprobe, mm, vaddr,
+ *(uprobe_opcode_t *)&auprobe->insn);
}
static struct uprobe *get_uprobe(struct uprobe *uprobe)
--
2.14.4
[PATCH v7 0/6] Uprobes: Support SDT markers having reference count (semaphore)
v7 changes:
- Don't allow both zero and non-zero reference counter offset at
the same time. It's painful and error prone.
- Don't call delayed_uprobe_install() if vma->vm_mm does not have
any breakpoint installed.
v6: https://lkml.org/lkml/2018/7/16/353
Description:
Userspace Statically Defined Tracepoints[1] are dtrace style markers
inside userspace applications. Applications like PostgreSQL, MySQL,
Pthread, Perl, Python, Java, Ruby, Node.js, libvirt, QEMU, glib etc
have these markers embedded in them. These markers are added by developer
at important places in the code. Each marker source expands to a single
nop instruction in the compiled code but there may be additional
overhead for computing the marker arguments which expands to couple of
instructions. In case the overhead is more, execution of it can be
omitted by runtime if() condition when no one is tracing on the marker:
if (reference_counter > 0) {
Execute marker instructions;
}
Default value of reference counter is 0. Tracer has to increment the
reference counter before tracing on a marker and decrement it when
done with the tracing.
Currently, perf tool has limited supports for SDT markers. I.e. it
can not trace markers surrounded by reference counter. Also, it's
not easy to add reference counter logic in userspace tool like perf,
so basic idea for this patchset is to add reference counter logic in
the a uprobe infrastructure. Ex,[2]
# cat tick.c
...
for (i = 0; i < 100; i++) {
DTRACE_PROBE1(tick, loop1, i);
if (TICK_LOOP2_ENABLED()) {
DTRACE_PROBE1(tick, loop2, i);
}
printf("hi: %d\n", i);
sleep(1);
}
...
Here tick:loop1 is marker without reference counter where as tick:loop2
is surrounded by reference counter condition.
# perf buildid-cache --add /tmp/tick
# perf probe sdt_tick:loop1
# perf probe sdt_tick:loop2
# perf stat -e sdt_tick:loop1,sdt_tick:loop2 -- /tmp/tick
hi: 0
hi: 1
hi: 2
^C
Performance counter stats for '/tmp/tick':
3 sdt_tick:loop1
0 sdt_tick:loop2
2.747086086 seconds time elapsed
Perf failed to record data for tick:loop2. Same experiment with this
patch series:
# ./perf buildid-cache --add /tmp/tick
# ./perf probe sdt_tick:loop2
# ./perf stat -e sdt_tick:loop2 /tmp/tick
hi: 0
hi: 1
hi: 2
^C
Performance counter stats for '/tmp/tick':
3 sdt_tick:loop2
2.561851452 seconds time elapsed
Ravi Bangoria (6):
Uprobes: Simplify uprobe_register() body
Uprobe: Additional argument arch_uprobe to uprobe_write_opcode()
Uprobes: Support SDT markers having reference count (semaphore)
Uprobes/sdt: Prevent multiple reference counter for same uprobe
trace_uprobe/sdt: Prevent multiple reference counter for same uprobe
perf probe: Support SDT markers having reference counter (semaphore)
arch/arm/probes/uprobes/core.c | 2 +-
arch/mips/kernel/uprobes.c | 2 +-
include/linux/uprobes.h| 7 +-
kernel/events/uprobes.c| 315 +++--
kernel/trace/trace.c | 2 +-
kernel/trace/trace_uprobe.c| 75 +-
tools/perf/util/probe-event.c | 39 -
tools/perf/util/probe-event.h | 1 +
tools/perf/util/probe-file.c | 34 -
tools/perf/util/probe-file.h | 1 +
tools/perf/util/symbol-elf.c | 46 --
tools/perf/util/symbol.h | 7 +
12 files changed, 459 insertions(+), 72 deletions(-)
--
2.14.4
[PATCH v7 5/6] trace_uprobe/sdt: Prevent multiple reference counter for same uprobe
We assume to have only one reference counter for one uprobe.
Don't allow user to add multiple trace_uprobe entries having
same inode+offset but different reference counter.
Ex,
# echo "p:sdt_tick/loop2 /home/ravi/tick:0x6e4(0x10036)" > uprobe_events
# echo "p:sdt_tick/loop2_1 /home/ravi/tick:0x6e4(0xf)" >> uprobe_events
bash: echo: write error: Invalid argument
# dmesg
trace_kprobe: Reference counter offset mismatch.
There is one exception though:
When user is trying to replace the old entry with the new
one, we allow this if the new entry does not conflict with
any other existing entries.
Signed-off-by: Ravi Bangoria
---
kernel/trace/trace_uprobe.c | 37 +++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index bf2be098eb08..be64d943d7ea 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -324,6 +324,35 @@ static int unregister_trace_uprobe(struct trace_uprobe *tu)
return 0;
}
+/*
+ * Uprobe with multiple reference counter is not allowed. i.e.
+ * If inode and offset matches, reference counter offset *must*
+ * match as well. Though, there is one exception: If user is
+ * replacing old trace_uprobe with new one(same group/event),
+ * then we allow same uprobe with new reference counter as far
+ * as the new one does not conflict with any other existing
+ * ones.
+ */
+static struct trace_uprobe *find_old_trace_uprobe(struct trace_uprobe *new)
+{
+ struct trace_uprobe *tmp, *old = NULL;
+ struct inode *new_inode = d_real_inode(new->path.dentry);
+
+ old = find_probe_event(trace_event_name(&new->tp.call),
+ new->tp.call.class->system);
+
+ list_for_each_entry(tmp, &uprobe_list, list) {
+ if ((old ? old != tmp : true) &&
+ new_inode == d_real_inode(tmp->path.dentry) &&
+ new->offset == tmp->offset &&
+ new->ref_ctr_offset != tmp->ref_ctr_offset) {
+ pr_warn("Reference counter offset mismatch.");
+ return ERR_PTR(-EINVAL);
+ }
+ }
+ return old;
+}
+
/* Register a trace_uprobe and probe_event */
static int register_trace_uprobe(struct trace_uprobe *tu)
{
@@ -333,8 +362,12 @@ static int register_trace_uprobe(struct trace_uprobe *tu)
mutex_lock(&uprobe_lock);
/* register as an event */
- old_tu = find_probe_event(trace_event_name(&tu->tp.call),
- tu->tp.call.class->system);
+ old_tu = find_old_trace_uprobe(tu);
+ if (IS_ERR(old_tu)) {
+ ret = PTR_ERR(old_tu);
+ goto end;
+ }
+
if (old_tu) {
/* delete old event */
ret = unregister_trace_uprobe(old_tu);
--
2.14.4
[PATCH v7 1/6] Uprobes: Simplify uprobe_register() body
Simplify uprobe_register() function body and let __uprobe_register()
handle everything. Also move dependency functions around to fix build
failures.
Signed-off-by: Ravi Bangoria
---
kernel/events/uprobes.c | 69 ++---
1 file changed, 36 insertions(+), 33 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index ccc579a7d32e..471eac896635 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -840,13 +840,8 @@ register_for_each_vma(struct uprobe *uprobe, struct
uprobe_consumer *new)
return err;
}
-static int __uprobe_register(struct uprobe *uprobe, struct uprobe_consumer *uc)
-{
- consumer_add(uprobe, uc);
- return register_for_each_vma(uprobe, uc);
-}
-
-static void __uprobe_unregister(struct uprobe *uprobe, struct uprobe_consumer
*uc)
+static void
+__uprobe_unregister(struct uprobe *uprobe, struct uprobe_consumer *uc)
{
int err;
@@ -860,24 +855,46 @@ static void __uprobe_unregister(struct uprobe *uprobe,
struct uprobe_consumer *u
}
/*
- * uprobe_register - register a probe
+ * uprobe_unregister - unregister a already registered probe.
+ * @inode: the file in which the probe has to be removed.
+ * @offset: offset from the start of the file.
+ * @uc: identify which probe if multiple probes are colocated.
+ */
+void uprobe_unregister(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc)
+{
+ struct uprobe *uprobe;
+
+ uprobe = find_uprobe(inode, offset);
+ if (WARN_ON(!uprobe))
+ return;
+
+ down_write(&uprobe->register_rwsem);
+ __uprobe_unregister(uprobe, uc);
+ up_write(&uprobe->register_rwsem);
+ put_uprobe(uprobe);
+}
+EXPORT_SYMBOL_GPL(uprobe_unregister);
+
+/*
+ * __uprobe_register - register a probe
* @inode: the file in which the probe has to be placed.
* @offset: offset from the start of the file.
* @uc: information on howto handle the probe..
*
- * Apart from the access refcount, uprobe_register() takes a creation
+ * Apart from the access refcount, __uprobe_register() takes a creation
* refcount (thro alloc_uprobe) if and only if this @uprobe is getting
* inserted into the rbtree (i.e first consumer for a @inode:@offset
* tuple). Creation refcount stops uprobe_unregister from freeing the
* @uprobe even before the register operation is complete. Creation
* refcount is released when the last @uc for the @uprobe
- * unregisters. Caller of uprobe_register() is required to keep @inode
+ * unregisters. Caller of __uprobe_register() is required to keep @inode
* (and the containing mount) referenced.
*
* Return errno if it cannot successully install probes
* else return 0 (success)
*/
-int uprobe_register(struct inode *inode, loff_t offset, struct uprobe_consumer
*uc)
+static int __uprobe_register(struct inode *inode, loff_t offset,
+struct uprobe_consumer *uc)
{
struct uprobe *uprobe;
int ret;
@@ -904,7 +921,8 @@ int uprobe_register(struct inode *inode, loff_t offset,
struct uprobe_consumer *
down_write(&uprobe->register_rwsem);
ret = -EAGAIN;
if (likely(uprobe_is_active(uprobe))) {
- ret = __uprobe_register(uprobe, uc);
+ consumer_add(uprobe, uc);
+ ret = register_for_each_vma(uprobe, uc);
if (ret)
__uprobe_unregister(uprobe, uc);
}
@@ -915,6 +933,12 @@ int uprobe_register(struct inode *inode, loff_t offset,
struct uprobe_consumer *
goto retry;
return ret;
}
+
+int uprobe_register(struct inode *inode, loff_t offset,
+ struct uprobe_consumer *uc)
+{
+ return __uprobe_register(inode, offset, uc);
+}
EXPORT_SYMBOL_GPL(uprobe_register);
/*
@@ -946,27 +970,6 @@ int uprobe_apply(struct inode *inode, loff_t offset,
return ret;
}
-/*
- * uprobe_unregister - unregister a already registered probe.
- * @inode: the file in which the probe has to be removed.
- * @offset: offset from the start of the file.
- * @uc: identify which probe if multiple probes are colocated.
- */
-void uprobe_unregister(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc)
-{
- struct uprobe *uprobe;
-
- uprobe = find_uprobe(inode, offset);
- if (WARN_ON(!uprobe))
- return;
-
- down_write(&uprobe->register_rwsem);
- __uprobe_unregister(uprobe, uc);
- up_write(&uprobe->register_rwsem);
- put_uprobe(uprobe);
-}
-EXPORT_SYMBOL_GPL(uprobe_unregister);
-
static int unapply_uprobe(struct uprobe *uprobe, struct mm_struct *mm)
{
struct vm_area_struct *vma;
--
2.14.4
[PATCH v7 4/6] Uprobes/sdt: Prevent multiple reference counter for same uprobe
We assume to have only one reference counter for one uprobe.
Don't allow user to register multiple uprobes having same
inode+offset but different reference counter.
Signed-off-by: Ravi Bangoria
---
kernel/events/uprobes.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index ad92fed11526..c27546929ae7 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -679,6 +679,12 @@ static struct uprobe *alloc_uprobe(struct inode *inode,
loff_t offset,
cur_uprobe = insert_uprobe(uprobe);
/* a uprobe exists for this inode:offset combination */
if (cur_uprobe) {
+ if (cur_uprobe->ref_ctr_offset != uprobe->ref_ctr_offset) {
+ pr_warn("Reference counter offset mismatch.\n");
+ put_uprobe(cur_uprobe);
+ kfree(uprobe);
+ return ERR_PTR(-EINVAL);
+ }
kfree(uprobe);
uprobe = cur_uprobe;
}
@@ -1093,6 +1099,9 @@ static int __uprobe_register(struct inode *inode, loff_t
offset,
uprobe = alloc_uprobe(inode, offset, ref_ctr_offset);
if (!uprobe)
return -ENOMEM;
+ if (IS_ERR(uprobe))
+ return PTR_ERR(uprobe);
+
/*
* We can race with uprobe_unregister()->delete_uprobe().
* Check uprobe_is_active() and retry if it is false.
--
2.14.4
[PATCH v7 6/6] perf probe: Support SDT markers having reference counter (semaphore)
With this, perf buildid-cache will save SDT markers with reference
counter in probe cache. Perf probe will be able to probe markers
having reference counter. Ex,
# readelf -n /tmp/tick | grep -A1 loop2
Name: loop2
... Semaphore: 0x10020036
# ./perf buildid-cache --add /tmp/tick
# ./perf probe sdt_tick:loop2
# ./perf stat -e sdt_tick:loop2 /tmp/tick
hi: 0
hi: 1
hi: 2
^C
Performance counter stats for '/tmp/tick':
3 sdt_tick:loop2
2.561851452 seconds time elapsed
Signed-off-by: Ravi Bangoria
Acked-by: Masami Hiramatsu
Acked-by: Srikar Dronamraju
---
tools/perf/util/probe-event.c | 39
tools/perf/util/probe-event.h | 1 +
tools/perf/util/probe-file.c | 34 ++--
tools/perf/util/probe-file.h | 1 +
tools/perf/util/symbol-elf.c | 46 ---
tools/perf/util/symbol.h | 7 +++
6 files changed, 106 insertions(+), 22 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index f119eb628dbb..e86f8be89157 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -1819,6 +1819,12 @@ int parse_probe_trace_command(const char *cmd, struct
probe_trace_event *tev)
tp->offset = strtoul(fmt2_str, NULL, 10);
}
+ if (tev->uprobes) {
+ fmt2_str = strchr(p, '(');
+ if (fmt2_str)
+ tp->ref_ctr_offset = strtoul(fmt2_str + 1, NULL, 0);
+ }
+
tev->nargs = argc - 2;
tev->args = zalloc(sizeof(struct probe_trace_arg) * tev->nargs);
if (tev->args == NULL) {
@@ -2012,6 +2018,22 @@ static int synthesize_probe_trace_arg(struct
probe_trace_arg *arg,
return err;
}
+static int
+synthesize_uprobe_trace_def(struct probe_trace_event *tev, struct strbuf *buf)
+{
+ struct probe_trace_point *tp = &tev->point;
+ int err;
+
+ err = strbuf_addf(buf, "%s:0x%lx", tp->module, tp->address);
+
+ if (err >= 0 && tp->ref_ctr_offset) {
+ if (!uprobe_ref_ctr_is_supported())
+ return -1;
+ err = strbuf_addf(buf, "(0x%lx)", tp->ref_ctr_offset);
+ }
+ return err >= 0 ? 0 : -1;
+}
+
char *synthesize_probe_trace_command(struct probe_trace_event *tev)
{
struct probe_trace_point *tp = &tev->point;
@@ -2041,15 +2063,17 @@ char *synthesize_probe_trace_command(struct
probe_trace_event *tev)
}
/* Use the tp->address for uprobes */
- if (tev->uprobes)
- err = strbuf_addf(&buf, "%s:0x%lx", tp->module, tp->address);
- else if (!strncmp(tp->symbol, "0x", 2))
+ if (tev->uprobes) {
+ err = synthesize_uprobe_trace_def(tev, &buf);
+ } else if (!strncmp(tp->symbol, "0x", 2)) {
/* Absolute address. See try_to_find_absolute_address() */
err = strbuf_addf(&buf, "%s%s0x%lx", tp->module ?: "",
tp->module ? ":" : "", tp->address);
- else
+ } else {
err = strbuf_addf(&buf, "%s%s%s+%lu", tp->module ?: "",
tp->module ? ":" : "", tp->symbol, tp->offset);
+ }
+
if (err)
goto error;
@@ -2633,6 +2657,13 @@ static void warn_uprobe_event_compat(struct
probe_trace_event *tev)
{
int i;
char *buf = synthesize_probe_trace_command(tev);
+ struct probe_trace_point *tp = &tev->point;
+
+ if (tp->ref_ctr_offset && !uprobe_ref_ctr_is_supported()) {
+ pr_warning("A semaphore is associated with %s:%s and "
+ "seems your kernel doesn't support it.\n",
+ tev->group, tev->event);
+ }
/* Old uprobe event doesn't support memory dereference */
if (!tev->uprobes || tev->nargs == 0 || !buf)
diff --git a/tools/perf/util/probe-event.h b/tools/perf/util/probe-event.h
index 45b14f020558..15a98c3a2a2f 100644
--- a/tools/perf/util/probe-event.h
+++ b/tools/perf/util/probe-event.h
@@ -27,6 +27,7 @@ struct probe_trace_point {
char*symbol;/* Base symbol */
char*module;/* Module name */
unsigned long offset; /* Offset from symbol */
+ unsigned long ref_ctr_offset; /* SDT reference counter offset */
unsigned long address;/* Actual address of the trace point */
boolretprobe; /* Return probe flag */
};
diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index b76088fadf3d..aac7817d9e14 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -696,8 +696,16 @@ int probe_cache__add_entry(struct probe_cache *pcache,
#ifdef HAVE_GELF_GETNOTE_SUPPORT
static unsigned long long sdt_note__get_addr(struct sdt_note *note)
{
- return note->bit32 ?
[PATCH v7 3/6] Uprobes: Support SDT markers having reference count (semaphore)
Userspace Statically Defined Tracepoints[1] are dtrace style markers
inside userspace applications. Applications like PostgreSQL, MySQL,
Pthread, Perl, Python, Java, Ruby, Node.js, libvirt, QEMU, glib etc
have these markers embedded in them. These markers are added by developer
at important places in the code. Each marker source expands to a single
nop instruction in the compiled code but there may be additional
overhead for computing the marker arguments which expands to couple of
instructions. In case the overhead is more, execution of it can be
omitted by runtime if() condition when no one is tracing on the marker:
if (reference_counter > 0) {
Execute marker instructions;
}
Default value of reference counter is 0. Tracer has to increment the
reference counter before tracing on a marker and decrement it when
done with the tracing.
Implement the reference counter logic in core uprobe. User will be
able to use it from trace_uprobe as well as from kernel module. New
trace_uprobe definition with reference counter will now be:
:[(ref_ctr_offset)]
where ref_ctr_offset is an optional field. For kernel module, new
variant of uprobe_register() has been introduced:
uprobe_register_refctr(inode, offset, ref_ctr_offset, consumer)
No new variant for uprobe_unregister() because it's assumed to have
only one reference counter for one uprobe.
[1] https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
Note: 'reference counter' is called as 'semaphore' in original Dtrace
(or Systemtap, bcc and even in ELF) documentation and code. But the
term 'semaphore' is misleading in this context. This is just a counter
used to hold number of tracers tracing on a marker. This is not really
used for any synchronization. So we are referring it as 'reference
counter' in kernel / perf code.
Signed-off-by: Ravi Bangoria
Reviewed-by: Masami Hiramatsu
[Only trace_uprobe.c]
---
include/linux/uprobes.h | 5 +
kernel/events/uprobes.c | 232 ++--
kernel/trace/trace.c| 2 +-
kernel/trace/trace_uprobe.c | 38 +++-
4 files changed, 267 insertions(+), 10 deletions(-)
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index bb9d2084af03..103a48a48872 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -123,6 +123,7 @@ extern unsigned long uprobe_get_swbp_addr(struct pt_regs
*regs);
extern unsigned long uprobe_get_trap_addr(struct pt_regs *regs);
extern int uprobe_write_opcode(struct arch_uprobe *auprobe, struct mm_struct
*mm, unsigned long vaddr, uprobe_opcode_t);
extern int uprobe_register(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc);
+extern int uprobe_register_refctr(struct inode *inode, loff_t offset, loff_t
ref_ctr_offset, struct uprobe_consumer *uc);
extern int uprobe_apply(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc, bool);
extern void uprobe_unregister(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc);
extern int uprobe_mmap(struct vm_area_struct *vma);
@@ -160,6 +161,10 @@ uprobe_register(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc)
{
return -ENOSYS;
}
+static inline int uprobe_register_refctr(struct inode *inode, loff_t offset,
loff_t ref_ctr_offset, struct uprobe_consumer *uc)
+{
+ return -ENOSYS;
+}
static inline int
uprobe_apply(struct inode *inode, loff_t offset, struct uprobe_consumer *uc,
bool add)
{
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index c0418ba52ba8..ad92fed11526 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -73,6 +73,7 @@ struct uprobe {
struct uprobe_consumer *consumers;
struct inode*inode; /* Also hold a ref to inode */
loff_t offset;
+ loff_t ref_ctr_offset;
unsigned long flags;
/*
@@ -88,6 +89,15 @@ struct uprobe {
struct arch_uprobe arch;
};
+struct delayed_uprobe {
+ struct list_head list;
+ struct uprobe *uprobe;
+ struct mm_struct *mm;
+};
+
+static DEFINE_MUTEX(delayed_uprobe_lock);
+static LIST_HEAD(delayed_uprobe_list);
+
/*
* Execute out of line area: anonymous executable mapping installed
* by the probed task to execute the copy of the original instruction
@@ -282,6 +292,154 @@ static int verify_opcode(struct page *page, unsigned long
vaddr, uprobe_opcode_t
return 1;
}
+static struct delayed_uprobe *
+delayed_uprobe_check(struct uprobe *uprobe, struct mm_struct *mm)
+{
+ struct delayed_uprobe *du;
+
+ list_for_each_entry(du, &delayed_uprobe_list, list)
+ if (du->uprobe == uprobe && du->mm == mm)
+ return du;
+ return NULL;
+}
+
+static int delayed_uprobe_add(struct uprobe *uprobe, struct mm_struct *mm)
+{
+ struct delayed_uprobe *du;
+
+ if (delayed_uprobe_check(uprobe, mm))
+ retu
Re: [PATCH 1/2] leds: core: Introduce LED pattern trigger
On Mon 30 Jul 05:29 PDT 2018, Baolin Wang wrote:
> Some LED controllers have support for autonomously controlling
> brightness over time, according to some preprogrammed pattern or
> function.
>
> This patch adds pattern trigger that LED device can configure the
> pattern and trigger it.
>
> Signed-off-by: Raphael Teysseyre
> Signed-off-by: Baolin Wang
> ---
> .../ABI/testing/sysfs-class-led-trigger-pattern| 21 ++
> drivers/leds/trigger/Kconfig | 10 +
> drivers/leds/trigger/Makefile |1 +
> drivers/leds/trigger/ledtrig-pattern.c | 349
>
> include/linux/leds.h | 19 ++
> 5 files changed, 400 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-pattern
> create mode 100644 drivers/leds/trigger/ledtrig-pattern.c
>
> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
> b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
> new file mode 100644
> index 000..c52da34
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
> @@ -0,0 +1,21 @@
> +What:/sys/class/leds//pattern
> +Date:August 2018
> +KernelVersion: 4.19
> +Description:
> + Specify a pattern for the LED, for LED hardware that support
> + altering the brightness as a function of time.
> +
> + The pattern is given by a series of tuples, of brightness and
> + duration (ms). The LED is expected to traverse the series and
> + each brightness value for the specified duration. Duration of
> + 0 means brightness should immediately change to new value.
> +
> + The format of the pattern values should be:
> + "brightness_1 duration_1, brightness_2 duration_2, brightness_3
> + duration_3, ...".
> +
> +What:/sys/class/leds//repeat
> +Date:August 2018
> +KernelVersion: 4.19
> +Description:
> + Specify a pattern repeat number. 0 means repeat indefinitely.
If 0 means infinity, does 1 mean "repeat 1 time"? If so how would I
specify that I want the pattern to run one time (i.e. 0 repetitions).
> diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
> index a2559b4..a03afcd 100644
> --- a/drivers/leds/trigger/Kconfig
> +++ b/drivers/leds/trigger/Kconfig
> @@ -125,6 +125,16 @@ config LEDS_TRIGGER_CAMERA
> This enables direct flash/torch on/off by the driver, kernel space.
> If unsure, say Y.
>
> +config LEDS_TRIGGER_PATTERN
> + tristate "LED Pattern Trigger"
> + depends on LEDS_TRIGGERS
> + help
> + This allows LEDs blinking with an arbitrary pattern. Can be useful
> + on embedded systems with no screen to give out a status code to
> + a human.
While the pattern mechanism could be used to communicate some message
the use cases we've seen so far is all about enabling hardware to pulse
LEDs instead of blinking them...
> +
> + If unsure, say N
> +
> config LEDS_TRIGGER_PANIC
> bool "LED Panic Trigger"
> depends on LEDS_TRIGGERS
> diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
> index f3cfe19..c5d180e 100644
> --- a/drivers/leds/trigger/Makefile
> +++ b/drivers/leds/trigger/Makefile
> @@ -13,3 +13,4 @@ obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT)+=
> ledtrig-transient.o
> obj-$(CONFIG_LEDS_TRIGGER_CAMERA)+= ledtrig-camera.o
> obj-$(CONFIG_LEDS_TRIGGER_PANIC) += ledtrig-panic.o
> obj-$(CONFIG_LEDS_TRIGGER_NETDEV)+= ledtrig-netdev.o
> +obj-$(CONFIG_LEDS_TRIGGER_PATTERN) += ledtrig-pattern.o
> diff --git a/drivers/leds/trigger/ledtrig-pattern.c
> b/drivers/leds/trigger/ledtrig-pattern.c
> new file mode 100644
> index 000..b709aa1
> --- /dev/null
> +++ b/drivers/leds/trigger/ledtrig-pattern.c
> @@ -0,0 +1,349 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * LED pattern trigger
> + *
> + * Idea discussed with Pavel Machek. Raphael Teysseyre implemented
> + * the first version, Baolin Wang simplified and improved the approach.
Might be a coincidence, but parts of this patch looks pretty close to
mine...
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * The "pattern" attribute contains at most PAGE_SIZE characters. Each line
> + * in this attribute is at least 4 characters long (a 1-digit number for the
> + * led brighntess, a space, a 1-digit number for the time, a semi-colon).
> + * Therefore, there is at most PAGE_SIZE/4 patterns.
> + */
The brightness is a number between 0 and LED_FULL (or max_brightness)
and delta_t is measured in ms. So neither of these are likely to be a
single digit very often.
> +#define MAX_PATTERNS (PAGE_SIZE / 4)
> +#define PATTERN_SEPARATOR","
> +
> +struct pattern_trig_data {
> + struct led_classdev *led
Re: [PATCH 06/11] sched/irq: add irq utilization tracking
On Tue, 31 Jul 2018 at 00:43, Vincent Guittot wrote: > > Hi Wanpeng, > > On Thu, 26 Jul 2018 at 05:09, Wanpeng Li wrote: > > > > Hi Vincent, > > On Fri, 29 Jun 2018 at 03:07, Vincent Guittot > > wrote: > > > > > > interrupt and steal time are the only remaining activities tracked by > > > rt_avg. Like for sched classes, we can use PELT to track their average > > > utilization of the CPU. But unlike sched class, we don't track when > > > entering/leaving interrupt; Instead, we take into account the time spent > > > under interrupt context when we update rqs' clock (rq_clock_task). > > > This also means that we have to decay the normal context time and account > > > for interrupt time during the update. > > > > > > That's also important to note that because > > > rq_clock == rq_clock_task + interrupt time > > > and rq_clock_task is used by a sched class to compute its utilization, the > > > util_avg of a sched class only reflects the utilization of the time spent > > > in normal context and not of the whole time of the CPU. The utilization of > > > interrupt gives an more accurate level of utilization of CPU. > > > The CPU utilization is : > > > avg_irq + (1 - avg_irq / max capacity) * /Sum avg_rq > > > > > > Most of the time, avg_irq is small and neglictible so the use of the > > > approximation CPU utilization = /Sum avg_rq was enough > > > > > > Cc: Ingo Molnar > > > Cc: Peter Zijlstra > > > Signed-off-by: Vincent Guittot > > > --- > > > kernel/sched/core.c | 4 +++- > > > kernel/sched/fair.c | 13 ++--- > > > kernel/sched/pelt.c | 40 > > > kernel/sched/pelt.h | 16 > > > kernel/sched/sched.h | 3 +++ > > > 5 files changed, 72 insertions(+), 4 deletions(-) > > > > > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > > > index 78d8fac..e5263a4 100644 > > > --- a/kernel/sched/core.c > > > +++ b/kernel/sched/core.c > > > @@ -18,6 +18,8 @@ > > > #include "../workqueue_internal.h" > > > #include "../smpboot.h" > > > > > > +#include "pelt.h" > > > + > > > #define CREATE_TRACE_POINTS > > > #include > > > > > > @@ -186,7 +188,7 @@ static void update_rq_clock_task(struct rq *rq, s64 > > > delta) > > > > > > #if defined(CONFIG_IRQ_TIME_ACCOUNTING) || > > > defined(CONFIG_PARAVIRT_TIME_ACCOUNTING) > > > if ((irq_delta + steal) && sched_feat(NONTASK_CAPACITY)) > > > - sched_rt_avg_update(rq, irq_delta + steal); > > > + update_irq_load_avg(rq, irq_delta + steal); > > > > I think we should not add steal time into irq load tracking, steal > > time is always 0 on native kernel which doesn't matter, what will > > happen when guest disables IRQ_TIME_ACCOUNTING and enables > > PARAVIRT_TIME_ACCOUNTING? Steal time is not the real irq util_avg. In > > addition, we haven't exposed power management for performance which > > means that e.g. schedutil governor can not cooperate with passive mode > > intel_pstate driver to tune the OPP. To decay the old steal time avg > > and add the new one just wastes cpu cycles. > > In fact, I have kept the same behavior as with rt_avg, which was > already adding steal time when computing scale_rt_capacity, which is > used to reflect the remaining capacity for FAIR tasks and is used in > load balance. I'm not sure that it's worth using different variables > for irq and steal. > That being said, I see a possible optimization in schedutil when > PARAVIRT_TIME_ACCOUNTING is enable and IRQ_TIME_ACCOUNTING is disable. > With this kind of config, scale_irq_capacity can be a nop for > schedutil but scales the utilization for scale_rt_capacity Yeah, this is what in my mind before, you can make a patch for that. :) Regards, Wanpeng Li
Re: [PATCH mmc-next v2 3/3] mmc: sdhci-of-dwcmshc: solve 128MB DMA boundary limitation
Hi Robin,
On Mon, 30 Jul 2018 12:06:08 +0100 Robin Murphy wrote:
> Hi Jisheng,
>
> On 26/07/18 08:14, Jisheng Zhang wrote:
> > When using DMA, if the DMA addr spans 128MB boundary, we have to split
> > the DMA transfer into two so that each one doesn't exceed the boundary.
>
> Out of interest, is the driver already setting its segment boundary mask
> appropriately? This sounds like the exact kind of hardware restriction
> that dma_parms is intended to describe, which scatterlist-generating
> code is *supposed* to already respect.
Thanks for the nice input. It may provide an elegant solution for this
limitation.
To simplify the situation, let's assume no iommu, only swiotlb. And
the DDR is less than 4GB so swiotlb on arm64 doesn't init.
There's no dma range limitation with the HW, the only limitation
is boundary, while dma_capable() doesn't check the boundary mask, so if
we taking this solution, we need to teach dma_capable() about the boundary
mask, I'm not sure whether this is acceptable.
Another problem is swiotlb initialization. When to init swiotlb, we dunno
there's such boundary limitation HW. Is there any elegant solution for
this problem?
Thanks
>
> Robin.
>
> > Signed-off-by: Jisheng Zhang
> > ---
> > drivers/mmc/host/sdhci-of-dwcmshc.c | 42 +
> > 1 file changed, 42 insertions(+)
> >
> > diff --git a/drivers/mmc/host/sdhci-of-dwcmshc.c
> > b/drivers/mmc/host/sdhci-of-dwcmshc.c
> > index 1b7cd144fb01..7e189514bc83 100644
> > --- a/drivers/mmc/host/sdhci-of-dwcmshc.c
> > +++ b/drivers/mmc/host/sdhci-of-dwcmshc.c
> > @@ -8,21 +8,51 @@
> >*/
> >
> > #include
> > +#include
> > #include
> > #include
> >
> > #include "sdhci-pltfm.h"
> >
> > +#define BOUNDARY_OK(addr, len) \
> > + ((addr | (SZ_128M - 1)) == ((addr + len - 1) | (SZ_128M - 1)))
> > +
> > struct dwcmshc_priv {
> > struct clk *bus_clk;
> > };
> >
> > +/*
> > + * if DMA addr spans 128MB boundary, we split the DMA transfer into two
> > + * so that the DMA transfer doesn't exceed the boundary.
> > + */
> > +static unsigned int dwcmshc_adma_write_desc(struct sdhci_host *host,
> > + void *desc, dma_addr_t addr,
> > + int len, unsigned int cmd)
> > +{
> > + int tmplen, offset;
> > +
> > + if (BOUNDARY_OK(addr, len) || !len)
> > + return _sdhci_adma_write_desc(host, desc, addr, len, cmd);
> > +
> > + offset = addr & (SZ_128M - 1);
> > + tmplen = SZ_128M - offset;
> > + _sdhci_adma_write_desc(host, desc, addr, tmplen, cmd);
> > +
> > + addr += tmplen;
> > + len -= tmplen;
> > + desc += host->desc_sz;
> > + _sdhci_adma_write_desc(host, desc, addr, len, cmd);
> > +
> > + return host->desc_sz * 2;
> > +}
> > +
> > static const struct sdhci_ops sdhci_dwcmshc_ops = {
> > .set_clock = sdhci_set_clock,
> > .set_bus_width = sdhci_set_bus_width,
> > .set_uhs_signaling = sdhci_set_uhs_signaling,
> > .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> > .reset = sdhci_reset,
> > + .adma_write_desc= dwcmshc_adma_write_desc,
> > };
> >
> > static const struct sdhci_pltfm_data sdhci_dwcmshc_pdata = {
> > @@ -36,12 +66,24 @@ static int dwcmshc_probe(struct platform_device *pdev)
> > struct sdhci_host *host;
> > struct dwcmshc_priv *priv;
> > int err;
> > + u32 extra;
> >
> > host = sdhci_pltfm_init(pdev, &sdhci_dwcmshc_pdata,
> > sizeof(struct dwcmshc_priv));
> > if (IS_ERR(host))
> > return PTR_ERR(host);
> >
> > + /*
> > +* The DMA descriptor table number is calculated as the maximum
> > +* number of segments times 2, to allow for an alignment
> > +* descriptor for each segment, plus 1 for a nop end descriptor,
> > +* plus extra number for cross 128M boundary handling.
> > +*/
> > + extra = DIV_ROUND_UP(totalram_pages, SZ_128M / PAGE_SIZE);
> > + if (extra > SDHCI_MAX_SEGS)
> > + extra = SDHCI_MAX_SEGS;
> > + host->adma_table_num = SDHCI_MAX_SEGS * 2 + 1 + extra;
> > +
> > pltfm_host = sdhci_priv(host);
> > priv = sdhci_pltfm_priv(pltfm_host);
> >
> >
Re: Linux 4.18-rc7
On Mon, 30 Jul 2018, Linus Torvalds wrote: > On Mon, Jul 30, 2018 at 2:53 PM Hugh Dickins wrote: > > > > I have no problem with reverting -rc7's vma_is_anonymous() series. > > I don't think we need to revert the whole series: I think the rest are > all fairly obvious cleanups, and shouldn't really have any semantic > changes. Okay. > > It's literally only that last patch in the series that then changes > that meaning of "vm_ops". And I don't really _mind_ that last step > either, but since we don't know exactly what it was that it broke, and > we're past rc7, I don't think we really have any option but the revert > it. It took me a long time to grasp what was happening, that that last patch bfd40eaff5ab was fixing. Not quite explained in the commit. I think it was that by mistakenly passing the vma_is_anonymous() test, create_huge_pmd() gave the MAP_PRIVATE kcov mapping a THP (instead of COWing pages from kcov); which the truncate then had to split, and in going to do so, again hit the mistaken vma_is_anonymous() test, BUG. > > And if we revert it, I think we need to just remove the > VM_BUG_ON_VMA() that it was supposed to fix. Because I do think that > it is quite likely that the real bug is that overzealous BUG_ON(), > since I can't see any reason why anonymous mappings should be special > there. Yes, that probably has to go: but it's not clear what state it leaves us in, with an anon THP being split by a truncate, without the expected locking; I don't remember offhand, probably a subtler bug than that BUG, which you may or may not consider an improvement. I fear that Kirill has not missed inserting a vma_set_anonymous() from somewhere that it should be, but rather that zygote is working with some special mapping which used to satisfy vma_is_anonymous(), faults supplying backing pages, but now comes out as !vma_is_anonymous(), so do_fault() finds !dummy_vm_ops.fault hence SIGBUS. If that's so, perhaps dummy_vm_ops needs to be given a back-compatible fault handler; or the driver(?) in question given vm_ops and that fault handler. But when I say "back-compatible", I don't think it should ever go so far as to supply a THP. > > But I'm certainly also ok with re-visiting that commit later. I just > think that right _now_ the above is my preferred plan. > > Kirill? > > > I'm all for deleting that VM_BUG_ON_VMA() in zap_pmd_range(), it was > > just a compromise with those who wanted to keep something there; > > I don't think we even need a WARN_ON_ONCE() now. > > So to me it looks like a historical check that simply doesn't > "normally" trigger, but there's no reason I can see why we should care > about the case it tests against. > > > (It remains quite interesting how exit_mmap() does not come that way, > > and most syscalls split the vma beforehand in vma_adjust(): it's mostly > > about madvise(,,MADV_DONTNEED), perhaps others now, which zap ptes > > without prior splitting.) > > Well, in this case it's the ftruncate() path, which fundamentally > doesn't split the vma at all (prior *or* later). But yes, madvise() is > in the same boat - it doesn't change the vma at all, it just changes > the contents of the vma. > > And exit_mmap() is special because it just tears down everything. > > So we do have three very distinct cases: > > (a) changing and thus splitting the vma itself (mprotect, munmap/mmap, > mlock), Yes. > > (b) not changing the vma, but changing the underlying mapping > (truncate and madvise(MADV_DONTNEED) Yes, though I think I would distinguish the truncate & hole-punch case from the madvise zap case, they have different characteristics in other ways (or did, before that awkward case of truncating an anon THP surfaced). > > (c) tearing down everything, and no locking needed because it's the > last user (exit_mmap). Yes; and it goes linearly from start to finish, never jumping into the middle of a vma, so never needing to split a THP. > > that are different for what I think are good reasons. > >Linus
Re: [PATCH 7/9] irqchip: add a RISC-V PLIC driver
On 7/27/18 5:04 PM, Atish Patra wrote: On 7/26/18 7:38 AM, Christoph Hellwig wrote: This patch adds a driver for the Platform Level Interrupt Controller (PLIC) specified as part of the RISC-V supervisor level ISA manual, in the memory layout implemented by SiFive and qemu. The PLIC connects global interrupt sources to the local interrupt controller on each hart. This driver is based on the driver in the RISC-V tree from Palmer Dabbelt, but has been almost entirely rewritten since. Signed-off-by: Christoph Hellwig I tried to boot HighFive Unleashed with the patch series after applying all the patches from riscv-all branch except timer & irq patches. It gets stuck pretty early. Here is my github repo with all the changes: https://github.com/atishp04/riscv-linux/commits/master_chris_cleanup_hifive I am still looking into it. I found the issue. As per PLIC documentation, a hart context is a given privilege mode on a given hart. Thus, cpu context ID & cpu numbers are not same. Here is the PLIC register Maps in U54 core: Ref: https://static.dev.sifive.com/U54-MC-RVCoreIP.pdf Memory address for Interrupt enable Address 0x0C00-2080 Hart 1 M-mode enables 0x0C00 2094 End of Hart 1 M-mode enables 0x0C00-2100 Hart 1 S-mode enables 0x0C00-2114 End of Hart 1 S-mode enables Memory map Claim/Threshold Address 0x0C20-1000 4B M-mode priority threshold 0x0C20-1004 4B M-mode claim/complete 0x0C20-2000 4B S-mode priority threshold 0x0C20-2004 4B S-mode claim/complete The original PLIC patch was calculating based on handle->contextid which will assume numbers on a HighFive Unleashed board as 2 4 6 8. In this patch, context id is assigned as cpu numbers which will be 1 2 3 4. Thus it will lead to incorrect plic address access as shown below. CPU1 enable register: plic: plic_toggle: In for hwirq = [1] ctxid [1] reg = [0x2080] plic: plic_toggle: In for hwirq = [32] ctxid [1] reg = [0x2084] Palmer: Did I miss something? FWIW, here is the boot log. - Boot log --- [0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=5 [0.00] NR_IRQS: 0, nr_irqs: 0, preallocated irqs: 0 [0.00] plic: mapped 53 interrupts to 4 (out of 9) handlers. [0.00] clocksource: riscv_clocksource: mask: 0x max_cycles: 0x1d854df40, max_idle_ns: 3526361616960 ns [0.00] Calibrating delay loop (skipped), value calculated using timer frequency.. 2.00 BogoMIPS (lpj=1) [0.01] pid_max: default: 32768 minimum: 301 [0.01] Mount-cache hash table entries: 16384 (order: 5, 131072 bytes) [0.02] Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes) [0.02] Hierarchical SRCU implementation. [0.03] smp: Bringing up secondary CPUs ... --- drivers/irqchip/Kconfig | 13 ++ drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-riscv-plic.c | 219 +++ 3 files changed, 233 insertions(+) create mode 100644 drivers/irqchip/irq-riscv-plic.c diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig index e9233db16e03..5ac6dd922a0d 100644 --- a/drivers/irqchip/Kconfig +++ b/drivers/irqchip/Kconfig @@ -372,3 +372,16 @@ config QCOM_PDC IRQs for Qualcomm Technologies Inc (QTI) mobile chips. endmenu + +config RISCV_PLIC + bool "Platform-Level Interrupt Controller" + depends on RISCV + default y + help + This enables support for the PLIC chip found in standard RISC-V + systems. The PLIC controls devices interrupts and connects them to + each core's local interrupt controller. Aside from timer and + software interrupts, all other interrupt sources (MSI, GPIO, etc) + are subordinate to the PLIC. + + If you don't know what to do here, say Y. diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile index 15f268f646bf..bf9238da8a31 100644 --- a/drivers/irqchip/Makefile +++ b/drivers/irqchip/Makefile @@ -87,3 +87,4 @@ obj-$(CONFIG_MESON_IRQ_GPIO) += irq-meson-gpio.o obj-$(CONFIG_GOLDFISH_PIC) += irq-goldfish-pic.o obj-$(CONFIG_NDS32) += irq-ativic32.o obj-$(CONFIG_QCOM_PDC) += qcom-pdc.o +obj-$(CONFIG_RISCV_PLIC) += irq-riscv-plic.o diff --git a/drivers/irqchip/irq-riscv-plic.c b/drivers/irqchip/irq-riscv-plic.c new file mode 100644 index ..274fe2cba544 --- /dev/null +++ b/drivers/irqchip/irq-riscv-plic.c @@ -0,0 +1,219 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2017 SiFive + * Copyright (C) 2018 Christoph Hellwig + */ +#define pr_fmt(fmt) "plic: " fmt +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* + * From the RISC-V Priviledged Spec v1.10: + * + * Global interrupt sources are assigned small unsigned integer identifie
