Re: [PATCH v3 07/16] iio: adc: axp20x_adc: add support for AXP813 ADC
On Mon, 22 Jan 2018 09:22:25 +0100
Quentin Schulz wrote:
> Hi Jonathan,
>
> On Sun, Jan 21, 2018 at 12:26:55PM +, Jonathan Cameron wrote:
> > On Mon, 15 Jan 2018 11:33:41 +0100
> > Quentin Schulz wrote:
> >
> > > The X-Powers AXP813 PMIC is really close to what is already done for
> > > AXP20X/AXP22X.
> > >
> > > There are two pairs of bits to set the rate (one for Voltage and Current
> > > measurements and one for TS/GPIO0 voltage measurements) instead of one.
> > >
> > > The register to set the ADC rates is different from the one for
> > > AXP20X/AXP22X.
> > >
> > > GPIO0 can be used as an ADC (measuring Volts) unlike for AXP22X.
> > >
> > > The scales to apply to the different inputs are unlike the ones from
> > > AXP20X and AXP22X.
> > >
> > > Signed-off-by: Quentin Schulz
> > > Acked-by: Jonathan Cameron
> > Applied to the togreg branch of iio.git and pushed out as testing
> > for the autobuilders to play with it.
> >
> > One thing that might be nice to tidy up in this driver though.
> >
> > CHECK drivers/iio/adc/axp20x_adc.c
> > drivers/iio/adc/axp20x_adc.c:548:26: warning: dubious: !x & y
> > drivers/iio/adc/axp20x_adc.c:553:26: warning: dubious: !x & y
> >
> > Those are 'interesting' code constructions. It may be worth being
> > a little more verbose to keep sparse happy and suppress the
> > warning.
> >
>
> Would adding a val = !!val; before the call to the macro be "verbose"
> enough for you?
>
> Sparse does not complain anymore after that.
I'd just use a good old fashioned if statement. Few more lines of
code but clearer and will keep sparse happy.
Jonathan
>
> Thanks,
> Quentin
>
> > Thanks,
> >
> > Jonathan
> >
> > > ---
> > > drivers/iio/adc/axp20x_adc.c | 123 -
> > > include/linux/mfd/axp20x.h | 2 +-
> > > 2 files changed, 125 insertions(+)
> > >
> > > diff --git a/drivers/iio/adc/axp20x_adc.c b/drivers/iio/adc/axp20x_adc.c
> > > index 3968053..7cdb8bc 100644
> > > --- a/drivers/iio/adc/axp20x_adc.c
> > > +++ b/drivers/iio/adc/axp20x_adc.c
> > > @@ -35,8 +35,13 @@
> > > #define AXP20X_GPIO10_IN_RANGE_GPIO1_VAL(x) (((x) & BIT(0)) << 1)
> > >
> > > #define AXP20X_ADC_RATE_MASK GENMASK(7, 6)
> > > +#define AXP813_V_I_ADC_RATE_MASK GENMASK(5, 4)
> > > +#define AXP813_ADC_RATE_MASK (AXP20X_ADC_RATE_MASK |
> > > AXP813_V_I_ADC_RATE_MASK)
> > > #define AXP20X_ADC_RATE_HZ(x)((ilog2((x) / 25) << 6)
> > > & AXP20X_ADC_RATE_MASK)
> > > #define AXP22X_ADC_RATE_HZ(x)((ilog2((x) / 100) <<
> > > 6) & AXP20X_ADC_RATE_MASK)
> > > +#define AXP813_TS_GPIO0_ADC_RATE_HZ(x) AXP20X_ADC_RATE_HZ(x)
> > > +#define AXP813_V_I_ADC_RATE_HZ(x)((ilog2((x) / 100) <<
> > > 4) & AXP813_V_I_ADC_RATE_MASK)
> > > +#define AXP813_ADC_RATE_HZ(x)(AXP20X_ADC_RATE_HZ(x)
> > > | AXP813_V_I_ADC_RATE_HZ(x))
> > >
> > > #define AXP20X_ADC_CHANNEL(_channel, _name, _type, _reg) \
> > > { \
> > > @@ -95,6 +100,12 @@ enum axp22x_adc_channel_i {
> > > AXP22X_BATT_DISCHRG_I,
> > > };
> > >
> > > +enum axp813_adc_channel_v {
> > > + AXP813_TS_IN = 0,
> > > + AXP813_GPIO0_V,
> > > + AXP813_BATT_V,
> > > +};
> > > +
> > > static struct iio_map axp20x_maps[] = {
> > > {
> > > .consumer_dev_name = "axp20x-usb-power-supply",
> > > @@ -197,6 +208,25 @@ static const struct iio_chan_spec
> > > axp22x_adc_channels[] = {
> > > AXP20X_BATT_DISCHRG_I_H),
> > > };
> > >
> > > +static const struct iio_chan_spec axp813_adc_channels[] = {
> > > + {
> > > + .type = IIO_TEMP,
> > > + .address = AXP22X_PMIC_TEMP_H,
> > > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> > > + BIT(IIO_CHAN_INFO_SCALE) |
> > > + BIT(IIO_CHAN_INFO_OFFSET),
> > > + .datasheet_name = "pmic_temp",
> > > + },
> > > + AXP20X_ADC_CHANNEL(AXP813_GPIO0_V, "gpio0_v", IIO_VOLTAGE,
> > > +AXP288_GP_ADC_H),
> > > + AXP20X_ADC_CHANNEL(AXP813_BATT_V, "batt_v", IIO_VOLTAGE,
> > > +AXP20X_BATT_V_H),
> > > + AXP20X_ADC_CHANNEL(AXP22X_BATT_CHRG_I, "batt_chrg_i", IIO_CURRENT,
> > > +AXP20X_BATT_CHRG_I_H),
> > > + AXP20X_ADC_CHANNEL(AXP22X_BATT_DISCHRG_I, "batt_dischrg_i", IIO_CURRENT,
> > > +AXP20X_BATT_DISCHRG_I_H),
> > > +};
> > > +
> > > static int axp20x_adc_raw(struct iio_dev *indio_dev,
> > > struct iio_chan_spec const *chan, int *val)
> > > {
> > > @@ -243,6 +273,18 @@ static int axp22x_adc_raw(struct iio_dev *indio_dev,
> > > return IIO_VAL_INT;
> > > }
> > >
> > > +static int axp813_adc_raw(struct iio_dev *indio_dev,
> > > + struct iio_chan_spec const *chan, int *val)
> > > +{
> > > + struct axp20x_adc_iio *info = iio_priv(indio_dev);
> > > +
> > >
Re: [PATCH] iio: adc: stm32: fix stm32h7_adc_enable error handling
On Tue, 23 Jan 2018 17:04:56 +0100
Fabrice Gasnier wrote:
> Error handling in stm32h7_adc_enable routine doesn't unwind enable
> sequence correctly. ADEN can only be cleared by hardware (e.g. by
> writing one to ADDIS).
> It's also better to clear ADRDY just after it's been set by hardware.
>
> Fixes: 95e339b6e85d ("iio: adc: stm32: add support for STM32H7")
>
> Signed-off-by: Fabrice Gasnier
Applied to fixes-togreg-post-rc1 branch of iio.git and marked for
stable.
Thanks,
Jonathan
> ---
> drivers/iio/adc/stm32-adc.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
> index ca3b865..8177a92 100644
> --- a/drivers/iio/adc/stm32-adc.c
> +++ b/drivers/iio/adc/stm32-adc.c
> @@ -735,8 +735,6 @@ static int stm32h7_adc_enable(struct stm32_adc *adc)
> int ret;
> u32 val;
>
> - /* Clear ADRDY by writing one, then enable ADC */
> - stm32_adc_set_bits(adc, STM32H7_ADC_ISR, STM32H7_ADRDY);
> stm32_adc_set_bits(adc, STM32H7_ADC_CR, STM32H7_ADEN);
>
> /* Poll for ADRDY to be set (after adc startup time) */
> @@ -744,8 +742,11 @@ static int stm32h7_adc_enable(struct stm32_adc *adc)
> val & STM32H7_ADRDY,
> 100, STM32_ADC_TIMEOUT_US);
> if (ret) {
> - stm32_adc_clr_bits(adc, STM32H7_ADC_CR, STM32H7_ADEN);
> + stm32_adc_set_bits(adc, STM32H7_ADC_CR, STM32H7_ADDIS);
> dev_err(&indio_dev->dev, "Failed to enable ADC\n");
> + } else {
> + /* Clear ADRDY by writing one */
> + stm32_adc_set_bits(adc, STM32H7_ADC_ISR, STM32H7_ADRDY);
> }
>
> return ret;
[PATCH v2] tpm: add longer timeouts for creation commands.
TPM2_CC_Create(0x153) and TPM2_CC_CreatePrimary (0x131) involve generation
of crypto keys which can be a computationally intensive task.
The timeout is set to 3min.
Signed-off-by: Tomas Winkler
---
V2: resent
drivers/char/tpm/tpm-interface.c | 4
drivers/char/tpm/tpm.h | 27 ---
drivers/char/tpm/tpm2-cmd.c | 8 +---
3 files changed, 25 insertions(+), 14 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 0c493f885a9e..e9488aa43959 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -673,6 +673,10 @@ int tpm_get_timeouts(struct tpm_chip *chip)
msecs_to_jiffies(TPM2_DURATION_MEDIUM);
chip->duration[TPM_LONG] =
msecs_to_jiffies(TPM2_DURATION_LONG);
+ chip->duration[TPM_LONG_LONG] =
+ msecs_to_jiffies(TPM2_DURATION_LONG_LONG);
+ chip->duration[TPM_UNDEFINED] =
+ msecs_to_jiffies(TPM2_DURATION_DEFAULT);
chip->flags |= TPM_CHIP_FLAG_HAVE_TIMEOUTS;
return 0;
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index f895fba4e20d..192ba68b39c2 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -67,7 +67,9 @@ enum tpm_duration {
TPM_SHORT = 0,
TPM_MEDIUM = 1,
TPM_LONG = 2,
- TPM_UNDEFINED,
+ TPM_LONG_LONG = 3,
+ TPM_UNDEFINED = 4,
+ TPM_DURATION_MAX,
};
#define TPM_WARN_RETRY 0x800
@@ -79,15 +81,17 @@ enum tpm_duration {
#define TPM_HEADER_SIZE10
enum tpm2_const {
- TPM2_PLATFORM_PCR = 24,
- TPM2_PCR_SELECT_MIN = ((TPM2_PLATFORM_PCR + 7) / 8),
- TPM2_TIMEOUT_A = 750,
- TPM2_TIMEOUT_B = 2000,
- TPM2_TIMEOUT_C = 200,
- TPM2_TIMEOUT_D = 30,
- TPM2_DURATION_SHORT = 20,
- TPM2_DURATION_MEDIUM= 750,
- TPM2_DURATION_LONG = 2000,
+ TPM2_PLATFORM_PCR = 24,
+ TPM2_PCR_SELECT_MIN = ((TPM2_PLATFORM_PCR + 7) / 8),
+ TPM2_TIMEOUT_A =750,
+ TPM2_TIMEOUT_B = 2000,
+ TPM2_TIMEOUT_C =200,
+ TPM2_TIMEOUT_D = 30,
+ TPM2_DURATION_SHORT = 20,
+ TPM2_DURATION_MEDIUM=750,
+ TPM2_DURATION_LONG = 2000,
+ TPM2_DURATION_LONG_LONG = 30,
+ TPM2_DURATION_DEFAULT = 12,
};
enum tpm2_structures {
@@ -123,6 +127,7 @@ enum tpm2_algorithms {
enum tpm2_command_codes {
TPM2_CC_FIRST = 0x011F,
+ TPM2_CC_CREATE_PRIMARY = 0x0131,
TPM2_CC_SELF_TEST = 0x0143,
TPM2_CC_STARTUP = 0x0144,
TPM2_CC_SHUTDOWN= 0x0145,
@@ -227,7 +232,7 @@ struct tpm_chip {
unsigned long timeout_c; /* jiffies */
unsigned long timeout_d; /* jiffies */
bool timeout_adjusted;
- unsigned long duration[3]; /* jiffies */
+ unsigned long duration[TPM_DURATION_MAX]; /* jiffies */
bool duration_adjusted;
struct dentry *bios_dir[TPM_NUM_EVENT_LOG_FILES];
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index c17e75348a99..aaa17e982b37 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -90,6 +90,8 @@ static struct tpm2_hash tpm2_hash_map[] = {
* of time the chip could take to return the result. The values
* of the SHORT, MEDIUM, and LONG durations are taken from the
* PC Client Profile (PTP) specification.
+ * LONG_LONG is for commands that generates keys which empirically
+ * takes longer time on some systems.
*/
static const u8 tpm2_ordinal_duration[TPM2_CC_LAST - TPM2_CC_FIRST + 1] = {
TPM_UNDEFINED, /* 11F */
@@ -110,7 +112,7 @@ static const u8 tpm2_ordinal_duration[TPM2_CC_LAST -
TPM2_CC_FIRST + 1] = {
TPM_UNDEFINED, /* 12e */
TPM_UNDEFINED, /* 12f */
TPM_UNDEFINED, /* 130 */
- TPM_UNDEFINED, /* 131 */
+ TPM_LONG_LONG, /* 131 */
TPM_UNDEFINED, /* 132 */
TPM_UNDEFINED, /* 133 */
TPM_UNDEFINED, /* 134 */
@@ -144,7 +146,7 @@ static const u8 tpm2_ordinal_duration[TPM2_CC_LAST -
TPM2_CC_FIRST + 1] = {
TPM_UNDEFINED, /* 150 */
TPM_UNDEFINED, /* 151 */
TPM_UNDEFINED, /* 152 */
- TPM_UNDEFINED, /* 153 */
+ TPM_LONG_LONG, /* 153 */
TPM_UNDEFINED, /* 154 */
TPM_UNDEFINED, /* 155 */
TPM_UNDEFINED, /* 156 */
@@ -817,7 +819,7 @@ unsigned long tpm2_calc_ordinal_duration(struct tpm_chip
*chip, u32 ordinal)
duration = chip->duration[index];
if (duration <= 0)
- duration = 2 * 60 * HZ;
+ duration = msecs_to_jiffies(TPM2_DURATION
[tip:x86/urgent] x86/ftrace: Add one more ENDPROC annotation
Commit-ID: dd085168a74c99c3ebe7f813069e412eb8444243
Gitweb: https://git.kernel.org/tip/dd085168a74c99c3ebe7f813069e412eb8444243
Author: Josh Poimboeuf
AuthorDate: Sat, 27 Jan 2018 20:21:50 -0600
Committer: Thomas Gleixner
CommitDate: Sun, 28 Jan 2018 09:19:12 +0100
x86/ftrace: Add one more ENDPROC annotation
When ORC support was added for the ftrace_64.S code, an ENDPROC
for function_hook() was missed. This results in the following warning:
arch/x86/kernel/ftrace_64.o: warning: objtool: .entry.text+0x0: unreachable
instruction
Fixes: e2ac83d74a4d ("x86/ftrace: Fix ORC unwinding from ftrace handlers")
Reported-by: Steven Rostedt
Reported-by: Borislav Petkov
Signed-off-by: Josh Poimboeuf
Signed-off-by: Thomas Gleixner
Acked-by: Ingo Molnar
Cc: Linus Torvalds
Link: https://lkml.kernel.org/r/20180128022150.dqierscqmt3uwwsr@treble
---
arch/x86/kernel/ftrace_64.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S
index 7cb8ba0..8774fd2 100644
--- a/arch/x86/kernel/ftrace_64.S
+++ b/arch/x86/kernel/ftrace_64.S
@@ -291,7 +291,7 @@ trace:
restore_mcount_regs
jmp fgraph_trace
-END(function_hook)
+ENDPROC(function_hook)
#endif /* CONFIG_DYNAMIC_FTRACE */
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
Re: [PATCH v2] Staging: iio: ade7758: expand buf_lock to cover both buffer and state protection
On Thu, 25 Jan 2018 22:10:08 +0530
Shreeya Patel wrote:
> iio_dev->mlock is to be used only by the IIO core for protecting
> device mode changes between INDIO_DIRECT and INDIO_BUFFER.
>
> This patch replaces the use of mlock with the already established
> buf_lock mutex.
>
> Introducing 'unlocked' __ade7758_spi_write_reg_8 and
> __ade7758_spi_read_reg_8 functions to be used by ade7758_write_samp_freq
> and ade7758_read_samp_freq which avoids nested locks and maintains
> atomicity between bus and device frequency changes.
>
> Signed-off-by: Shreeya Patel
Hi Shreeya,
This is now technically correct which is great.
I would make one minor change to make it slightly easier to read.
The read / write frequency functions now require the buf_lock to
be held. That's not obvious so I would avoid this but moving
the locking inside the functions where it is then clear that
they are taking the unlocked forms of the register read/ write.
This would also then make it clear why the normal locked form
of _read_reg_8 is fine in the read_freq case but not the
write_freq case. (Hence just use the normal locked form
for the read and don't explicitly take the locks when
reading the frequency - leave it to the register read function)
Thanks,
Jonathan
> ---
>
> Changes in v2
> -Add static keyword to newly introduced functions and remove some
> added comments which are not required.
>
>
> drivers/staging/iio/meter/ade7758.h | 2 +-
> drivers/staging/iio/meter/ade7758_core.c | 47
> +++-
> 2 files changed, 35 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/staging/iio/meter/ade7758.h
> b/drivers/staging/iio/meter/ade7758.h
> index 6ae78d8..2de81b5 100644
> --- a/drivers/staging/iio/meter/ade7758.h
> +++ b/drivers/staging/iio/meter/ade7758.h
> @@ -111,7 +111,7 @@
> * @trig:data ready trigger registered with iio
> * @tx: transmit buffer
> * @rx: receive buffer
> - * @buf_lock:mutex to protect tx and rx
> + * @buf_lock:mutex to protect tx, rx, read and write
> frequency
> **/
> struct ade7758_state {
> struct spi_device *us;
> diff --git a/drivers/staging/iio/meter/ade7758_core.c
> b/drivers/staging/iio/meter/ade7758_core.c
> index 7b7ffe5..fed4684 100644
> --- a/drivers/staging/iio/meter/ade7758_core.c
> +++ b/drivers/staging/iio/meter/ade7758_core.c
> @@ -24,17 +24,25 @@
> #include "meter.h"
> #include "ade7758.h"
>
> -int ade7758_spi_write_reg_8(struct device *dev, u8 reg_address, u8 val)
> +static int __ade7758_spi_write_reg_8(struct device *dev, u8 reg_address, u8
> val)
> {
> - int ret;
> struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> struct ade7758_state *st = iio_priv(indio_dev);
>
> - mutex_lock(&st->buf_lock);
> st->tx[0] = ADE7758_WRITE_REG(reg_address);
> st->tx[1] = val;
>
> - ret = spi_write(st->us, st->tx, 2);
> + return spi_write(st->us, st->tx, 2);
> +}
> +
> +int ade7758_spi_write_reg_8(struct device *dev, u8 reg_address, u8 val)
> +{
> + int ret;
> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> + struct ade7758_state *st = iio_priv(indio_dev);
> +
> + mutex_lock(&st->buf_lock);
> + ret = __ade7758_spi_write_reg_8(dev, reg_address, val);
> mutex_unlock(&st->buf_lock);
>
> return ret;
> @@ -91,7 +99,7 @@ static int ade7758_spi_write_reg_24(struct device *dev, u8
> reg_address,
> return ret;
> }
>
> -int ade7758_spi_read_reg_8(struct device *dev, u8 reg_address, u8 *val)
> +static int __ade7758_spi_read_reg_8(struct device *dev, u8 reg_address, u8
> *val)
> {
> struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> struct ade7758_state *st = iio_priv(indio_dev);
> @@ -111,7 +119,6 @@ int ade7758_spi_read_reg_8(struct device *dev, u8
> reg_address, u8 *val)
> },
> };
>
> - mutex_lock(&st->buf_lock);
> st->tx[0] = ADE7758_READ_REG(reg_address);
> st->tx[1] = 0;
>
> @@ -124,7 +131,19 @@ int ade7758_spi_read_reg_8(struct device *dev, u8
> reg_address, u8 *val)
> *val = st->rx[0];
>
> error_ret:
> + return ret;
> +}
> +
> +int ade7758_spi_read_reg_8(struct device *dev, u8 reg_address, u8 *val)
> +{
> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> + struct ade7758_state *st = iio_priv(indio_dev);
> + int ret;
> +
> + mutex_lock(&st->buf_lock);
> + ret = __ade7758_spi_read_reg_8(dev, reg_address, val);
> mutex_unlock(&st->buf_lock);
> +
> return ret;
> }
>
> @@ -470,7 +489,7 @@ static int ade7758_read_samp_freq(struct device *dev, int
> *val)
> int ret;
> u8 t;
>
> - ret = ade7758_spi_read_reg_8(dev, ADE7758_WAVMODE, &t);
> + ret = __ade7758_spi_read_reg_8(dev, ADE7758_WAVMODE, &t);
> if (ret)
> return ret;
>
> @@ -503,14 +522,14 @@ static int ade7758_write_samp_freq(struct device *dev,
> int val)
>
Re: [PATCH 03/16] iio: adc: sun4i-gpadc-iio: rename A33-specified registers to contain A33
On Fri, 26 Jan 2018 16:19:28 +0100
Philipp Rossak wrote:
> From: Icenowy Zheng
>
> As the H3 SoC, which is also in sun8i line, has totally different
> register map for the thermal sensor (a cut down version of GPADC), we
> should rename A23/A33-specified registers to contain A33, in order to
> prevent obfuscation with H3 registers. Currently these registers are
> only prefixed "SUN8I", not "SUN8I_A33".
>
> Add "_A33" after "SUN8I" on the register names.
>
> Signed-off-by: Icenowy Zheng
> Reviewed-by: Chen-Yu Tsai
> Acked-by: Maxime Ripard
> Acked-by: Lee Jones
Acked-by: Jonathan Cameron
(for the trivial change in the IIO driver)
> ---
> drivers/iio/adc/sun4i-gpadc-iio.c | 2 +-
> include/linux/mfd/sun4i-gpadc.h | 6 +++---
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
> b/drivers/iio/adc/sun4i-gpadc-iio.c
> index 04d7147e0110..03804ff9c006 100644
> --- a/drivers/iio/adc/sun4i-gpadc-iio.c
> +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
> @@ -88,7 +88,7 @@ static const struct gpadc_data sun6i_gpadc_data = {
> static const struct gpadc_data sun8i_a33_gpadc_data = {
> .temp_offset = -1662,
> .temp_scale = 162,
> - .tp_mode_en = SUN8I_GPADC_CTRL1_CHOP_TEMP_EN,
> + .tp_mode_en = SUN8I_A33_GPADC_CTRL1_CHOP_TEMP_EN,
> };
>
> struct sun4i_gpadc_iio {
> diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
> index 139872c2e0fe..78d31984a222 100644
> --- a/include/linux/mfd/sun4i-gpadc.h
> +++ b/include/linux/mfd/sun4i-gpadc.h
> @@ -38,9 +38,9 @@
> #define SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(x) (GENMASK(3, 0) & BIT(x))
> #define SUN6I_GPADC_CTRL1_ADC_CHAN_MASK GENMASK(3, 0)
>
> -/* TP_CTRL1 bits for sun8i SoCs */
> -#define SUN8I_GPADC_CTRL1_CHOP_TEMP_EN BIT(8)
> -#define SUN8I_GPADC_CTRL1_GPADC_CALI_EN BIT(7)
> +/* TP_CTRL1 bits for A33 */
> +#define SUN8I_A33_GPADC_CTRL1_CHOP_TEMP_EN BIT(8)
> +#define SUN8I_A33_GPADC_CTRL1_GPADC_CALI_EN BIT(7)
>
> #define SUN4I_GPADC_CTRL20x08
>
Re: crash binary for latest unreleased kernel
I happen to look at the patches for the crash binary and came across this log entry from Jan 19. I am also using 4.15-rc kernel. Not knowing anything about crash it is hard to even attempt to fix it. Initial pass for support of kernel page table isolation. The x86_64 "bt" command may indicate "bt: cannot transition from exception stack to current process stack" if the crash callback NMI occurred while an active task was running on the new entry trampoline stack. This has only been tested on the RHEL7 backport of the upstream patch because as of this commit, crash does not run on 4.15-rc kernels. Further changes may be required for upstream kernels, and distributions that implement the kernel changes differently than upstream. (ander...@redhat.com) On Fri, Jan 26, 2018 at 8:48 PM, Mike Galbraith wrote: > On Fri, 2018-01-26 at 20:38 -0800, Randy Dunlap wrote: >> On 01/26/2018 08:32 PM, Mike Galbraith wrote: >> > On Fri, 2018-01-26 at 12:52 -0800, Joe Smith wrote: >> >> Hi, >> >> >> >> I am doing development on the latest unreleased kernel on a system >> >> running ubuntu 16.04. I can not get crash dump to be saved or use >> >> crash on the live system. I have tried compiling crash on the system. >> >> >> >> What is the trick to do development on the latest kernel using a >> >> system installed with old release. >> > >> > You have to either be motivated enough to fix crash and friends up as >> > they get busted, or lazy enough to wait for maintainers to do so for >> > you. I've done a bit of both, but the later is my favorite :) >> >> :) >> >> Is it mostly structure updates or is it partly randomized layout of >> structs? or something totally different? > > The stuff I've fixed up has been trivial renames and whatnot, operative > word being trivial, easy to find based on gripage. If I don't find it > quickly, I usually decide to not need it _that_ badly, go with plan B. > > -Mike -- JS
Re: [RFP] iio: Support of gesture sensor as a standard IIO sensor
hi! > > > Correct. This will depend on the firmware expected format . I > > > think > > > ultimately it will be standardized. > > Is it fair to say that "expected" format is some kind of bytecode for > > CPU in the gesture sensor? > Not necessarily a byte code to execute on the CPU in the gesture > sensor, but a format the code running on that CPU understands the way > gestures are formatted. > But it can be byte code for some manufacturers, so idea is just pass to > the firmware and let it process it an opaque format. It would be really good to figure out common format for different sensors. Otherwise kernel is not providing proper hardware abstraction. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH 04/16] iio: adc: sun4i-gpadc-iio: rework: sampling start/end code readout reg
On Fri, 26 Jan 2018 16:19:29 +0100
Philipp Rossak wrote:
> For adding newer sensor some basic rework of the code is necessary.
>
> This commit reworks the code and allows the sampling start/end code and
> the position of value readout register to be altered. Later the start/end
> functions will be used to configure the ths and start/stop the
> sampling.
>
> Signed-off-by: Icenowy Zheng
> Signed-off-by: Philipp Rossak
Hmm. It almost always turns out to be a bad idea to assume a particular
set of registers will be consistent across a hardware family. Usual convention
is just to prefix them with the first supported device and use them across
the variants where they are correct. I.e. don't use wild cards or generic
names as they often end up implying a wider range of applicability than
we want.
A few other comments inline. Reworking code to make it ready for later
patches is fine, but this also adds a lot of new code which isn't used until
much later in the series. Move it there...
> ---
> drivers/iio/adc/sun4i-gpadc-iio.c | 87
> +++
> include/linux/mfd/sun4i-gpadc.h | 19 +++--
> 2 files changed, 94 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
> b/drivers/iio/adc/sun4i-gpadc-iio.c
> index 03804ff9c006..363936b37c5a 100644
> --- a/drivers/iio/adc/sun4i-gpadc-iio.c
> +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
> @@ -49,6 +49,18 @@ static unsigned int sun6i_gpadc_chan_select(unsigned int
> chan)
> return SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(chan);
> }
>
> +struct sun4i_gpadc_iio;
> +
> +/*
> + * Prototypes for these functions, which enable these functions to be
> + * referenced in gpadc_data structures.
> + */
> +static int sun4i_gpadc_sample_start(struct sun4i_gpadc_iio *info);
> +static int sun4i_gpadc_sample_end(struct sun4i_gpadc_iio *info);
> +
> +static int sunxi_ths_sample_start(struct sun4i_gpadc_iio *info);
Superficially this appears to be introduced but not used... Patch 9
is first to use it I think? Introduce it then rather than here.
> +static int sunxi_ths_sample_end(struct sun4i_gpadc_iio *info);
> +
> struct gpadc_data {
> int temp_offset;
> int temp_scale;
> @@ -56,6 +68,13 @@ struct gpadc_data {
> unsigned inttp_adc_select;
> unsigned int(*adc_chan_select)(unsigned int chan);
> unsigned intadc_chan_mask;
> + unsigned inttemp_data;
> + int (*sample_start)(struct sun4i_gpadc_iio *info);
> + int (*sample_end)(struct sun4i_gpadc_iio *info);
> + u32 ctrl0_map;
> + u32 ctrl2_map;
> + u32 sensor_en_map;
> + u32 filter_map;
> };
>
> static const struct gpadc_data sun4i_gpadc_data = {
> @@ -65,6 +84,9 @@ static const struct gpadc_data sun4i_gpadc_data = {
> .tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
> .adc_chan_select = &sun4i_gpadc_chan_select,
> .adc_chan_mask = SUN4I_GPADC_CTRL1_ADC_CHAN_MASK,
> + .temp_data = SUN4I_GPADC_TEMP_DATA,
> + .sample_start = sun4i_gpadc_sample_start,
> + .sample_end = sun4i_gpadc_sample_end,
> };
>
> static const struct gpadc_data sun5i_gpadc_data = {
> @@ -74,6 +96,9 @@ static const struct gpadc_data sun5i_gpadc_data = {
> .tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
> .adc_chan_select = &sun4i_gpadc_chan_select,
> .adc_chan_mask = SUN4I_GPADC_CTRL1_ADC_CHAN_MASK,
> + .temp_data = SUN4I_GPADC_TEMP_DATA,
> + .sample_start = sun4i_gpadc_sample_start,
> + .sample_end = sun4i_gpadc_sample_end,
> };
>
> static const struct gpadc_data sun6i_gpadc_data = {
> @@ -83,12 +108,18 @@ static const struct gpadc_data sun6i_gpadc_data = {
> .tp_adc_select = SUN6I_GPADC_CTRL1_TP_ADC_SELECT,
> .adc_chan_select = &sun6i_gpadc_chan_select,
> .adc_chan_mask = SUN6I_GPADC_CTRL1_ADC_CHAN_MASK,
> + .temp_data = SUN4I_GPADC_TEMP_DATA,
> + .sample_start = sun4i_gpadc_sample_start,
> + .sample_end = sun4i_gpadc_sample_end,
> };
>
> static const struct gpadc_data sun8i_a33_gpadc_data = {
> .temp_offset = -1662,
> .temp_scale = 162,
> .tp_mode_en = SUN8I_A33_GPADC_CTRL1_CHOP_TEMP_EN,
> + .temp_data = SUN4I_GPADC_TEMP_DATA,
> + .sample_start = sun4i_gpadc_sample_start,
> + .sample_end = sun4i_gpadc_sample_end,
> };
>
> struct sun4i_gpadc_iio {
> @@ -277,7 +308,7 @@ static int sun4i_gpadc_temp_read(struct iio_dev
> *indio_dev, int *val)
> if (info->no_irq) {
> pm_runtime_get_sync(indio_dev->dev.parent);
>
> - regmap_read(info->regmap, SUN4I_GPADC_TEMP_DATA, val);
> + regmap_read(info->regmap, info->data->temp_data, val);
>
> pm_runtime_mark_last_busy(indio_dev->dev.parent);
> pm_runtime_put_autosuspend(indio_dev->dev.parent);
> @@ -382,10 +413,8 @@ static irqreturn_t sun4i_gpadc_fifo_data_irq_handler(int
> irq,
Re: arch/x86/kernel/ftrace_64.o: warning: objtool: .entry.text+0x0: unreachable instruction
On Sat, Jan 27, 2018 at 08:21:50PM -0600, Josh Poimboeuf wrote: > Yeah, Steven reported it a few days ago but I was in backport lala land. > It's a simple fix: Thanks dude, yap warning is gone with it. :-) -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH 05/16] iio: adc: sun4i-gpadc-iio: rework: support clocks and reset
On Fri, 26 Jan 2018 16:19:30 +0100
Philipp Rossak wrote:
> For adding newer sensor some basic rework of the code is necessary.
>
> The SoCs after H3 has newer thermal sensor ADCs, which have two clock
> inputs (bus clock and sampling clock) and a reset. The registers are
> also re-arranged.
>
> This commit reworks the code, adds the process of the clocks and
> resets.
>
> Signed-off-by: Philipp Rossak
> Signed-off-by: Icenowy Zheng
Both clock and reset code is safe against null parameters, so you can
drop a lot of 'is it here' checks in this. They could be argued to
act as documentation of the fact we really don't expect them in some cases
I suppose...
> ---
> drivers/iio/adc/sun4i-gpadc-iio.c | 80
> +++
> 1 file changed, 80 insertions(+)
>
> diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
> b/drivers/iio/adc/sun4i-gpadc-iio.c
> index 363936b37c5a..1a80744bd472 100644
> --- a/drivers/iio/adc/sun4i-gpadc-iio.c
> +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
> @@ -22,6 +22,7 @@
> * shutdown for not being used.
> */
>
> +#include
> #include
> #include
> #include
> @@ -31,6 +32,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -75,6 +77,9 @@ struct gpadc_data {
> u32 ctrl2_map;
> u32 sensor_en_map;
> u32 filter_map;
> + boolhas_bus_clk;
> + boolhas_bus_rst;
> + boolhas_mod_clk;
> };
>
> static const struct gpadc_data sun4i_gpadc_data = {
> @@ -134,6 +139,9 @@ struct sun4i_gpadc_iio {
> atomic_tignore_temp_data_irq;
> const struct gpadc_data *data;
> boolno_irq;
> + struct clk *bus_clk;
> + struct clk *mod_clk;
> + struct reset_control*reset;
> /* prevents concurrent reads of temperature and ADC */
> struct mutexmutex;
> struct thermal_zone_device *tzd;
> @@ -435,6 +443,12 @@ static int sun4i_gpadc_runtime_suspend(struct device
> *dev)
> {
> struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev));
>
> + if (info->data->has_mod_clk)
> + clk_disable(info->mod_clk);
Safe against null parameter... (see below)
> +
> + if (info->data->has_bus_clk)
> + clk_disable(info->bus_clk);
> +
> return info->data->sample_end(info);
> }
>
> @@ -483,6 +497,12 @@ static int sun4i_gpadc_runtime_resume(struct device *dev)
> {
> struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev));
>
> + if (info->data->has_mod_clk)
> + clk_enable(info->mod_clk);
clk_enable is safe against null parameter so could do without the checks.
> +
> + if (info->data->has_bus_clk)
> + clk_enable(info->bus_clk);
> +
> return info->data->sample_start(info);
> }
>
> @@ -597,10 +617,61 @@ static int sun4i_gpadc_probe_dt(struct platform_device
> *pdev,
> return ret;
> }
>
> + if (info->data->has_bus_rst) {
> + info->reset = devm_reset_control_get(&pdev->dev, NULL);
> + if (IS_ERR(info->reset)) {
> + ret = PTR_ERR(info->reset);
> + return ret;
> + }
> +
> + ret = reset_control_deassert(info->reset);
> + if (ret)
> + return ret;
> + }
> +
> + if (info->data->has_bus_clk) {
> + info->bus_clk = devm_clk_get(&pdev->dev, "bus");
> + if (IS_ERR(info->bus_clk)) {
> + ret = PTR_ERR(info->bus_clk);
> + goto assert_reset;
> + }
> +
> + ret = clk_prepare_enable(info->bus_clk);
> + if (ret)
> + goto assert_reset;
> + }
> +
> + if (info->data->has_mod_clk) {
> + info->mod_clk = devm_clk_get(&pdev->dev, "mod");
> + if (IS_ERR(info->mod_clk)) {
> + ret = PTR_ERR(info->mod_clk);
> + goto disable_bus_clk;
> + }
> +
> + /* Running at 6MHz */
> + ret = clk_set_rate(info->mod_clk, 400);
> + if (ret)
> + goto disable_bus_clk;
> +
> + ret = clk_prepare_enable(info->mod_clk);
> + if (ret)
> + goto disable_bus_clk;
> + }
> +
> if (IS_ENABLED(CONFIG_THERMAL_OF))
> info->sensor_device = &pdev->dev;
>
> return 0;
> +
> +disable_bus_clk:
> + if (info->data->has_bus_clk)
> + clk_disable_unprepare(info->bus_clk);
> +
> +assert_reset:
> + if (info->data->has_bus_rst)
> + reset_control_assert(info->reset);
> +
> + return ret;
> }
>
> static int sun4i_gpadc_probe_mfd(struct platform_device *pdev,
> @@ -766,6 +837,15 @@ static int sun4i_gpadc_remove(struct platform_devic
Re: [PATCH v5 02/12] array_idx: sanitize speculative array de-references
Firstly, I only got a few patches of this series so I couldn't review all of
them
- please Cc: me to all future Meltdown and Spectre related patches!
* Dan Williams wrote:
> 'array_idx' is proposed as a generic mechanism to mitigate against
> Spectre-variant-1 attacks, i.e. an attack that bypasses boundary checks
> via speculative execution). The 'array_idx' implementation is expected
> to be safe for current generation cpus across multiple architectures
> (ARM, x86).
nit: Stray closing parenthesis
s/cpus/CPUs
> Based on an original implementation by Linus Torvalds, tweaked to remove
> speculative flows by Alexei Starovoitov, and tweaked again by Linus to
> introduce an x86 assembly implementation for the mask generation.
>
> Co-developed-by: Linus Torvalds
> Co-developed-by: Alexei Starovoitov
> Suggested-by: Cyril Novikov
> Cc: Russell King
> Cc: Peter Zijlstra
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: x...@kernel.org
> Signed-off-by: Dan Williams
> ---
> include/linux/nospec.h | 64
>
> 1 file changed, 64 insertions(+)
> create mode 100644 include/linux/nospec.h
>
> diff --git a/include/linux/nospec.h b/include/linux/nospec.h
> new file mode 100644
> index ..f59f81889ba3
> --- /dev/null
> +++ b/include/linux/nospec.h
> @@ -0,0 +1,64 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright(c) 2018 Intel Corporation. All rights reserved.
Given the close similarity of Linus's array_access() prototype pseudocode there
should probably also be:
Copyright (C) 2018 Linus Torvalds
in that file?
> +
> +#ifndef __NOSPEC_H__
> +#define __NOSPEC_H__
> +
> +/*
> + * When idx is out of bounds (idx >= sz), the sign bit will be set.
> + * Extend the sign bit to all bits and invert, giving a result of zero
> + * for an out of bounds idx, or ~0UL if within bounds [0, sz).
> + */
> +#ifndef array_idx_mask
> +static inline unsigned long array_idx_mask(unsigned long idx, unsigned long
> sz)
> +{
> + /*
> + * Warn developers about inappropriate array_idx usage.
> + *
> + * Even if the cpu speculates past the WARN_ONCE branch, the
s/cpu/CPU
> + * sign bit of idx is taken into account when generating the
> + * mask.
> + *
> + * This warning is compiled out when the compiler can infer that
> + * idx and sz are less than LONG_MAX.
Please use 'idx' and 'sz' in quotes, to make sure they stand out more in free
flowing comment text. Also please use '()' to denote functions/methods.
I.e. something like:
* Warn developers about inappropriate array_idx() usage.
*
* Even if the CPU speculates past the WARN_ONCE() branch, the
* sign bit of 'idx' is taken into account when generating the
* mask.
*
* This warning is compiled out when the compiler can infer that
* 'idx' and 'sz' are less than LONG_MAX.
That's just one example - please apply it to all comments consistently.
> + */
> + if (WARN_ONCE(idx > LONG_MAX || sz > LONG_MAX,
> + "array_idx limited to range of [0, LONG_MAX]\n"))
Same in user facing messages:
"array_idx() limited to range of [0, LONG_MAX]\n"))
> + * For a code sequence like:
> + *
> + * if (idx < sz) {
> + * idx = array_idx(idx, sz);
> + * val = array[idx];
> + * }
> + *
> + * ...if the cpu speculates past the bounds check then array_idx() will
> + * clamp the index within the range of [0, sz).
s/cpu/CPU
> + */
> +#define array_idx(idx, sz) \
> +({ \
> + typeof(idx) _i = (idx); \
> + typeof(sz) _s = (sz); \
> + unsigned long _mask = array_idx_mask(_i, _s); \
> + \
> + BUILD_BUG_ON(sizeof(_i) > sizeof(long));\
> + BUILD_BUG_ON(sizeof(_s) > sizeof(long));\
> + \
> + _i &= _mask;\
> + _i; \
> +})
> +#endif /* __NOSPEC_H__ */
For heaven's sake, please name a size variable as 'size', not 'sz'. We don't
have
a shortage of characters and can deobfuscate common primitives, can we?
Also, beyond the nits, I also hate the namespace here. We have a new generic
header providing two new methods:
#include
array_idx_mask()
array_idx()
which is then optimized for x86 in asm/barrier.h. That's already a non-sequitor.
Then we introduce uaccess API variants with a _nospec() postfix.
Then we add ifence() to x86.
There's n
Re: [PATCH 07/16] iio: adc: sun4i-gpadc-iio: rework: support nvmem calibration data
On Fri, 26 Jan 2018 16:19:32 +0100
Philipp Rossak wrote:
> This patch reworks the driver to support nvmem calibration cells.
> The driver checks if the nvmem calibration is supported and reads out
> the nvmem. At the beginning of the startup process the calibration data
> is written to the related registers.
>
> Signed-off-by: Philipp Rossak
A few minor suggestions inline.
Jonathan
> ---
> drivers/iio/adc/sun4i-gpadc-iio.c | 52
> +++
> include/linux/mfd/sun4i-gpadc.h | 2 ++
> 2 files changed, 54 insertions(+)
>
> diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
> b/drivers/iio/adc/sun4i-gpadc-iio.c
> index bff06f2798e8..7b12666cdd9e 100644
> --- a/drivers/iio/adc/sun4i-gpadc-iio.c
> +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -81,6 +82,7 @@ struct gpadc_data {
> boolhas_bus_rst;
> boolhas_mod_clk;
> int sensor_count;
> + boolsupports_nvmem;
> };
>
> static const struct gpadc_data sun4i_gpadc_data = {
> @@ -94,6 +96,7 @@ static const struct gpadc_data sun4i_gpadc_data = {
> .sample_start = sun4i_gpadc_sample_start,
> .sample_end = sun4i_gpadc_sample_end,
> .sensor_count = 1,
> + .supports_nvmem = false,
> };
>
> static const struct gpadc_data sun5i_gpadc_data = {
> @@ -107,6 +110,7 @@ static const struct gpadc_data sun5i_gpadc_data = {
> .sample_start = sun4i_gpadc_sample_start,
> .sample_end = sun4i_gpadc_sample_end,
> .sensor_count = 1,
> + .supports_nvmem = false,
> };
>
> static const struct gpadc_data sun6i_gpadc_data = {
> @@ -120,6 +124,7 @@ static const struct gpadc_data sun6i_gpadc_data = {
> .sample_start = sun4i_gpadc_sample_start,
> .sample_end = sun4i_gpadc_sample_end,
> .sensor_count = 1,
> + .supports_nvmem = false,
> };
>
> static const struct gpadc_data sun8i_a33_gpadc_data = {
> @@ -130,6 +135,7 @@ static const struct gpadc_data sun8i_a33_gpadc_data = {
> .sample_start = sun4i_gpadc_sample_start,
> .sample_end = sun4i_gpadc_sample_end,
> .sensor_count = 1,
> + .supports_nvmem = false,
> };
>
> struct sun4i_gpadc_iio {
> @@ -148,6 +154,8 @@ struct sun4i_gpadc_iio {
> struct clk *mod_clk;
> struct reset_control*reset;
> int sensor_id;
> + u32 calibration_data[2];
> + boolhas_calibration_data[2];
> /* prevents concurrent reads of temperature and ADC */
> struct mutexmutex;
> struct thermal_zone_device *tzd;
> @@ -459,6 +467,17 @@ static int sun4i_gpadc_runtime_suspend(struct device
> *dev)
> return info->data->sample_end(info);
> }
>
> +static void sunxi_calibrate(struct sun4i_gpadc_iio *info)
> +{
> + if (info->has_calibration_data[0])
> + regmap_write(info->regmap, SUNXI_THS_CDATA_0_1,
> + info->calibration_data[0]);
> +
> + if (info->has_calibration_data[1])
> + regmap_write(info->regmap, SUNXI_THS_CDATA_2_3,
> + info->calibration_data[1]);
> +}
> +
> static int sun4i_gpadc_sample_start(struct sun4i_gpadc_iio *info)
> {
> /* clkin = 6MHz */
> @@ -481,6 +500,7 @@ static int sun4i_gpadc_sample_start(struct
> sun4i_gpadc_iio *info)
> static int sunxi_ths_sample_start(struct sun4i_gpadc_iio *info)
> {
> u32 value;
> + sunxi_calibrate(info);
>
> if (info->data->ctrl0_map)
> regmap_write(info->regmap, SUNXI_THS_CTRL0,
> @@ -602,6 +622,9 @@ static int sun4i_gpadc_probe_dt(struct platform_device
> *pdev,
> struct resource *mem;
> void __iomem *base;
> int ret;
> + struct nvmem_cell *cell;
> + ssize_t cell_size;
> + u64 *cell_data;
>
> info->data = of_device_get_match_data(&pdev->dev);
> if (!info->data)
> @@ -616,6 +639,35 @@ static int sun4i_gpadc_probe_dt(struct platform_device
> *pdev,
> if (IS_ERR(base))
> return PTR_ERR(base);
>
> + info->has_calibration_data[0] = false;
> + info->has_calibration_data[1] = false;
> +
> + if (!info->data->supports_nvmem)
> + goto no_nvmem;
> +
> + cell = devm_nvmem_cell_get(&pdev->dev, "calibration");
> + if (IS_ERR(cell)) {
> + if (PTR_ERR(cell) == -EPROBE_DEFER)
> + return PTR_ERR(cell);
Use a goto here to no_nvmem.
Then you can drop the below else to make things more readable.
> + } else {
> + cell_data = (u64 *)nvmem_cell_read(cell, &cell_size);
> + devm_nvmem_cell_put(&pdev->dev, cell);
I'm really not keen on use of devm for things we are intending
to drop almost immediately. Just use the non managed versions
and clean up properly in the error paths (if the
Re: [PATCH 08/16] iio: adc: sun4i-gpadc-iio: rework: add interrupt support
On Fri, 26 Jan 2018 16:19:33 +0100
Philipp Rossak wrote:
> This patch rewors the driver to support interrupts for the thermal part
> of the sensor.
>
> This is only available for the newer sensor (currently H3 and A83T).
> The interrupt will be trigerd on data available and triggers the update
> for the thermal sensors. All newer sensors have different amount of
> sensors and different interrupts for each device the reset of the
> interrupts need to be done different
>
> For the newer sensors is the autosuspend disabled.
>
> Signed-off-by: Philipp Rossak
Really minor point inline, otherwise this looks fine to me.
Acked-by: Jonathan Cameron
> ---
> drivers/iio/adc/sun4i-gpadc-iio.c | 68
> +++
> include/linux/mfd/sun4i-gpadc.h | 33 +++
> 2 files changed, 95 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
> b/drivers/iio/adc/sun4i-gpadc-iio.c
> index 7b12666cdd9e..77e07f042730 100644
> --- a/drivers/iio/adc/sun4i-gpadc-iio.c
> +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
> @@ -78,11 +78,14 @@ struct gpadc_data {
> u32 ctrl2_map;
> u32 sensor_en_map;
> u32 filter_map;
> + u32 irq_clear_map;
> + u32 irq_control_map;
> boolhas_bus_clk;
> boolhas_bus_rst;
> boolhas_mod_clk;
> int sensor_count;
> boolsupports_nvmem;
> + boolsupport_irq;
> };
>
> static const struct gpadc_data sun4i_gpadc_data = {
> @@ -97,6 +100,7 @@ static const struct gpadc_data sun4i_gpadc_data = {
> .sample_end = sun4i_gpadc_sample_end,
> .sensor_count = 1,
> .supports_nvmem = false,
> + .support_irq = false,
> };
>
> static const struct gpadc_data sun5i_gpadc_data = {
> @@ -111,6 +115,7 @@ static const struct gpadc_data sun5i_gpadc_data = {
> .sample_end = sun4i_gpadc_sample_end,
> .sensor_count = 1,
> .supports_nvmem = false,
> + .support_irq = false,
> };
>
> static const struct gpadc_data sun6i_gpadc_data = {
> @@ -125,6 +130,7 @@ static const struct gpadc_data sun6i_gpadc_data = {
> .sample_end = sun4i_gpadc_sample_end,
> .sensor_count = 1,
> .supports_nvmem = false,
> + .support_irq = false,
> };
>
> static const struct gpadc_data sun8i_a33_gpadc_data = {
> @@ -136,6 +142,7 @@ static const struct gpadc_data sun8i_a33_gpadc_data = {
> .sample_end = sun4i_gpadc_sample_end,
> .sensor_count = 1,
> .supports_nvmem = false,
> + .support_irq = false,
> };
>
> struct sun4i_gpadc_iio {
> @@ -339,6 +346,11 @@ static int sun4i_gpadc_temp_read(struct iio_dev
> *indio_dev, int *val,
> return 0;
> }
>
> + if (info->data->support_irq) {
> + regmap_read(info->regmap, info->data->temp_data[sensor], val);
> + return 0;
> + }
> +
> return sun4i_gpadc_read(indio_dev, 0, val, info->temp_data_irq);
> }
>
> @@ -436,6 +448,17 @@ static irqreturn_t sun4i_gpadc_fifo_data_irq_handler(int
> irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> +static irqreturn_t sunxi_irq_thread(int irq, void *data)
> +{
> + struct sun4i_gpadc_iio *info = data;
> +
> + regmap_write(info->regmap, SUNXI_THS_STAT, info->data->irq_clear_map);
> +
> + thermal_zone_device_update(info->tzd, THERMAL_EVENT_TEMP_SAMPLE);
> +
> + return IRQ_HANDLED;
> +}
> +
> static int sun4i_gpadc_sample_end(struct sun4i_gpadc_iio *info)
> {
> /* Disable the ADC on IP */
> @@ -448,6 +471,8 @@ static int sun4i_gpadc_sample_end(struct sun4i_gpadc_iio
> *info)
>
> static int sunxi_ths_sample_end(struct sun4i_gpadc_iio *info)
> {
> + /* Disable ths interrupt*/
Space before */
> + regmap_write(info->regmap, SUNXI_THS_INTC, 0x0);
> /* Disable temperature sensor */
> regmap_write(info->regmap, SUNXI_THS_CTRL2, 0x0);
>
> @@ -509,9 +534,15 @@ static int sunxi_ths_sample_start(struct sun4i_gpadc_iio
> *info)
> regmap_write(info->regmap, SUNXI_THS_CTRL2,
> info->data->ctrl2_map);
>
> + regmap_write(info->regmap, SUNXI_THS_STAT,
> + info->data->irq_clear_map);
> +
> regmap_write(info->regmap, SUNXI_THS_FILTER,
> info->data->filter_map);
>
> + regmap_write(info->regmap, SUNXI_THS_INTC,
> + info->data->irq_control_map);
> +
> regmap_read(info->regmap, SUNXI_THS_CTRL2, &value);
>
> regmap_write(info->regmap, SUNXI_THS_CTRL2,
> @@ -625,12 +656,29 @@ static int sun4i_gpadc_probe_dt(struct platform_device
> *pdev,
> struct nvmem_cell *cell;
> ssize_t cell_size;
> u64 *cell_data;
> + int irq;
>
> info->data = of_device_get_match_data(&pdev->dev);
> if (!info->data)
> return -ENODEV;
>
> - info->no_irq = true;
> + if (info->data->support_irq) {
> +
Re: [PATCH 06/16] iio: adc: sun4i-gpadc-iio: rework: support multible sensors
On Fri, 26 Jan 2018 16:19:31 +0100
Philipp Rossak wrote:
multible -> multiple
> For adding newer sensor some basic rework of the code is necessary.
>
> This patch reworks the driver to be able to handle more than one
> thermal sensor. Newer SoC like the A80 have 4 thermal sensors.
> Because of this the maximal sensor count value was set to 4.
>
> The sensor_id value is set during sensor registration and is for each
> registered sensor indiviual. This makes it able to differntiate the
> sensors when the value is read from the register.
>
> Signed-off-by: Philipp Rossak
Question inline about why you aren't exposing the additional temperature
sensors as IIO channels?
Fine to not do so I suppose, but needs justifying.
Jonathan
> ---
> drivers/iio/adc/sun4i-gpadc-iio.c | 36 +++-
> include/linux/mfd/sun4i-gpadc.h | 6 ++
> 2 files changed, 29 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
> b/drivers/iio/adc/sun4i-gpadc-iio.c
> index 1a80744bd472..bff06f2798e8 100644
> --- a/drivers/iio/adc/sun4i-gpadc-iio.c
> +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
> @@ -70,7 +70,7 @@ struct gpadc_data {
> unsigned inttp_adc_select;
> unsigned int(*adc_chan_select)(unsigned int chan);
> unsigned intadc_chan_mask;
> - unsigned inttemp_data;
> + unsigned inttemp_data[MAX_SENSOR_COUNT];
> int (*sample_start)(struct sun4i_gpadc_iio *info);
> int (*sample_end)(struct sun4i_gpadc_iio *info);
> u32 ctrl0_map;
> @@ -80,6 +80,7 @@ struct gpadc_data {
> boolhas_bus_clk;
> boolhas_bus_rst;
> boolhas_mod_clk;
> + int sensor_count;
> };
>
> static const struct gpadc_data sun4i_gpadc_data = {
> @@ -89,9 +90,10 @@ static const struct gpadc_data sun4i_gpadc_data = {
> .tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
> .adc_chan_select = &sun4i_gpadc_chan_select,
> .adc_chan_mask = SUN4I_GPADC_CTRL1_ADC_CHAN_MASK,
> - .temp_data = SUN4I_GPADC_TEMP_DATA,
> + .temp_data = {SUN4I_GPADC_TEMP_DATA, 0, 0, 0},
> .sample_start = sun4i_gpadc_sample_start,
> .sample_end = sun4i_gpadc_sample_end,
> + .sensor_count = 1,
> };
>
> static const struct gpadc_data sun5i_gpadc_data = {
> @@ -101,9 +103,10 @@ static const struct gpadc_data sun5i_gpadc_data = {
> .tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
> .adc_chan_select = &sun4i_gpadc_chan_select,
> .adc_chan_mask = SUN4I_GPADC_CTRL1_ADC_CHAN_MASK,
> - .temp_data = SUN4I_GPADC_TEMP_DATA,
> + .temp_data = {SUN4I_GPADC_TEMP_DATA, 0, 0, 0},
> .sample_start = sun4i_gpadc_sample_start,
> .sample_end = sun4i_gpadc_sample_end,
> + .sensor_count = 1,
> };
>
> static const struct gpadc_data sun6i_gpadc_data = {
> @@ -113,18 +116,20 @@ static const struct gpadc_data sun6i_gpadc_data = {
> .tp_adc_select = SUN6I_GPADC_CTRL1_TP_ADC_SELECT,
> .adc_chan_select = &sun6i_gpadc_chan_select,
> .adc_chan_mask = SUN6I_GPADC_CTRL1_ADC_CHAN_MASK,
> - .temp_data = SUN4I_GPADC_TEMP_DATA,
> + .temp_data = {SUN4I_GPADC_TEMP_DATA, 0, 0, 0},
> .sample_start = sun4i_gpadc_sample_start,
> .sample_end = sun4i_gpadc_sample_end,
> + .sensor_count = 1,
> };
>
> static const struct gpadc_data sun8i_a33_gpadc_data = {
> .temp_offset = -1662,
> .temp_scale = 162,
> .tp_mode_en = SUN8I_A33_GPADC_CTRL1_CHOP_TEMP_EN,
> - .temp_data = SUN4I_GPADC_TEMP_DATA,
> + .temp_data = {SUN4I_GPADC_TEMP_DATA, 0, 0, 0},
> .sample_start = sun4i_gpadc_sample_start,
> .sample_end = sun4i_gpadc_sample_end,
> + .sensor_count = 1,
> };
>
> struct sun4i_gpadc_iio {
> @@ -142,6 +147,7 @@ struct sun4i_gpadc_iio {
> struct clk *bus_clk;
> struct clk *mod_clk;
> struct reset_control*reset;
> + int sensor_id;
> /* prevents concurrent reads of temperature and ADC */
> struct mutexmutex;
> struct thermal_zone_device *tzd;
> @@ -309,14 +315,15 @@ static int sun4i_gpadc_adc_read(struct iio_dev
> *indio_dev, int channel,
> return sun4i_gpadc_read(indio_dev, channel, val, info->fifo_data_irq);
> }
>
> -static int sun4i_gpadc_temp_read(struct iio_dev *indio_dev, int *val)
> +static int sun4i_gpadc_temp_read(struct iio_dev *indio_dev, int *val,
> + int sensor)
> {
> struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
>
> if (info->no_irq) {
> pm_runtime_get_sync(indio_dev->dev.parent);
>
> - regmap_read(info->regmap, info->data->temp_data, val);
> + regmap_read(info->regmap, info->data->temp_data[sensor], val);
>
> pm_runtime_mark_last_busy(indio_dev->dev.parent);
> pm_run
Re: [PATCH v2] Staging: iio: ade7758: expand buf_lock to cover both buffer and state protection
On Sun, 2018-01-28 at 08:31 +, Jonathan Cameron wrote:
> On Thu, 25 Jan 2018 22:10:08 +0530
> Shreeya Patel wrote:
>
> >
> > iio_dev->mlock is to be used only by the IIO core for protecting
> > device mode changes between INDIO_DIRECT and INDIO_BUFFER.
> >
> > This patch replaces the use of mlock with the already established
> > buf_lock mutex.
> >
> > Introducing 'unlocked' __ade7758_spi_write_reg_8 and
> > __ade7758_spi_read_reg_8 functions to be used by
> > ade7758_write_samp_freq
> > and ade7758_read_samp_freq which avoids nested locks and maintains
> > atomicity between bus and device frequency changes.
> >
> > Signed-off-by: Shreeya Patel
> Hi Shreeya,
>
> This is now technically correct which is great.
> I would make one minor change to make it slightly easier to read.
>
> The read / write frequency functions now require the buf_lock to
> be held. That's not obvious so I would avoid this but moving
> the locking inside the functions where it is then clear that
> they are taking the unlocked forms of the register read/ write.
>
> This would also then make it clear why the normal locked form
> of _read_reg_8 is fine in the read_freq case but not the
> write_freq case. (Hence just use the normal locked form
> for the read and don't explicitly take the locks when
> reading the frequency - leave it to the register read function)
>
Hi,
I have introduced unlocked form of the _read_reg_8 also, which is wrong
on my side. I should have discarded the mlocks in the read_freq case
first, then there would have been no need of having unlocked form of
the _read_reg_8 :(
Please discard this patch and I'll send two patches in which first I'll
remove the mlocks from the read case and then I'll have only the
unlocked form of the _write_reg_8. In this way, there won't be any
useless code in the file for the read case.
Sorry, it took me a bit more time to understand.
Thanks
> Thanks,
>
> Jonathan
> >
> > ---
> >
> > Changes in v2
> > -Add static keyword to newly introduced functions and remove some
> > added comments which are not required.
> >
> >
> > drivers/staging/iio/meter/ade7758.h | 2 +-
> > drivers/staging/iio/meter/ade7758_core.c | 47
> > +++-
> > 2 files changed, 35 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/staging/iio/meter/ade7758.h
> > b/drivers/staging/iio/meter/ade7758.h
> > index 6ae78d8..2de81b5 100644
> > --- a/drivers/staging/iio/meter/ade7758.h
> > +++ b/drivers/staging/iio/meter/ade7758.h
> > @@ -111,7 +111,7 @@
> > * @trig: data ready trigger registered with iio
> > * @tx:transmit buffer
> > * @rx:receive buffer
> > - * @buf_lock: mutex to protect tx and rx
> > + * @buf_lock: mutex to protect tx, rx, read and
> > write frequency
> > **/
> > struct ade7758_state {
> > struct spi_device *us;
> > diff --git a/drivers/staging/iio/meter/ade7758_core.c
> > b/drivers/staging/iio/meter/ade7758_core.c
> > index 7b7ffe5..fed4684 100644
> > --- a/drivers/staging/iio/meter/ade7758_core.c
> > +++ b/drivers/staging/iio/meter/ade7758_core.c
> > @@ -24,17 +24,25 @@
> > #include "meter.h"
> > #include "ade7758.h"
> >
> > -int ade7758_spi_write_reg_8(struct device *dev, u8 reg_address, u8
> > val)
> > +static int __ade7758_spi_write_reg_8(struct device *dev, u8
> > reg_address, u8 val)
> > {
> > - int ret;
> > struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> > struct ade7758_state *st = iio_priv(indio_dev);
> >
> > - mutex_lock(&st->buf_lock);
> > st->tx[0] = ADE7758_WRITE_REG(reg_address);
> > st->tx[1] = val;
> >
> > - ret = spi_write(st->us, st->tx, 2);
> > + return spi_write(st->us, st->tx, 2);
> > +}
> > +
> > +int ade7758_spi_write_reg_8(struct device *dev, u8 reg_address, u8
> > val)
> > +{
> > + int ret;
> > + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> > + struct ade7758_state *st = iio_priv(indio_dev);
> > +
> > + mutex_lock(&st->buf_lock);
> > + ret = __ade7758_spi_write_reg_8(dev, reg_address, val);
> > mutex_unlock(&st->buf_lock);
> >
> > return ret;
> > @@ -91,7 +99,7 @@ static int ade7758_spi_write_reg_24(struct device
> > *dev, u8 reg_address,
> > return ret;
> > }
> >
> > -int ade7758_spi_read_reg_8(struct device *dev, u8 reg_address, u8
> > *val)
> > +static int __ade7758_spi_read_reg_8(struct device *dev, u8
> > reg_address, u8 *val)
> > {
> > struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> > struct ade7758_state *st = iio_priv(indio_dev);
> > @@ -111,7 +119,6 @@ int ade7758_spi_read_reg_8(struct device *dev,
> > u8 reg_address, u8 *val)
> > },
> > };
> >
> > - mutex_lock(&st->buf_lock);
> > st->tx[0] = ADE7758_READ_REG(reg_address);
> > st->tx[1] = 0;
> >
> > @@ -124,7 +131,19 @@ int ade7758_spi_read_reg_8(struct device *dev,
> > u8 reg_address, u8 *val)
> > *val = st->rx[0];
> >
> > error_ret:
> > + r
Re: [PATCH v5 04/12] x86: introduce __uaccess_begin_nospec and ifence
* Dan Williams wrote:
> --- a/arch/x86/include/asm/uaccess.h
> +++ b/arch/x86/include/asm/uaccess.h
> @@ -124,6 +124,11 @@ extern int __get_user_bad(void);
>
> #define __uaccess_begin() stac()
> #define __uaccess_end() clac()
> +#define __uaccess_begin_nospec() \
> +({ \
> + stac(); \
> + ifence(); \
> +})
BTW., wouldn't it be better to switch the barrier order here, i.e. to do:
ifence(); \
stac(); \
?
The reason is that stac()/clac() is usually paired, so there's a chance with
short
sequences that it would resolve with 'no externally visible changes to flags'.
Also, there's many cases where flags are modified _inside_ the STAC/CLAC
section,
so grouping them together inside a speculation atom could be beneficial.
The flip side is that if the MFENCE stalls the STAC that is ahead of it could
be
processed for 'free' - while it's always post barrier with my suggestion.
But in any case it would be nice to see a discussion of this aspect in the
changelog, even if the patch does not change.
Thanks,
Ingo
Re: [PATCH v5 03/12] x86: implement array_idx_mask
* Dan Williams wrote:
> 'array_idx' uses a mask to sanitize user controllable array indexes,
> i.e. generate a 0 mask if idx >= sz, and a ~0 mask otherwise. While the
> default array_idx_mask handles the carry-bit from the (index - size)
> result in software. The x86 'array_idx_mask' does the same, but the
> carry-bit is handled in the processor CF flag without conditional
> instructions in the control flow.
Same style comments apply as for patch 02.
> Suggested-by: Linus Torvalds
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: x...@kernel.org
> Signed-off-by: Dan Williams
> ---
> arch/x86/include/asm/barrier.h | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
> index 01727dbc294a..30419b674ebd 100644
> --- a/arch/x86/include/asm/barrier.h
> +++ b/arch/x86/include/asm/barrier.h
> @@ -24,6 +24,28 @@
> #define wmb()asm volatile("sfence" ::: "memory")
> #endif
>
> +/**
> + * array_idx_mask - generate a mask for array_idx() that is ~0UL when
> + * the bounds check succeeds and 0 otherwise
> + *
> + * mask = 0 - (idx < sz);
> + */
> +#define array_idx_mask array_idx_mask
> +static inline unsigned long array_idx_mask(unsigned long idx, unsigned long
> sz)
Please put an extra newline between definitions (even if they are closely
related
as these).
> +{
> + unsigned long mask;
> +
> +#ifdef CONFIG_X86_32
> + asm ("cmpl %1,%2; sbbl %0,%0;"
> +#else
> + asm ("cmpq %1,%2; sbbq %0,%0;"
> +#endif
Wouldn't this suffice:
asm ("cmp %1,%2; sbb %0,%0;"
... as the word width should automatically be 32 bits on 32-bit kernels and 64
bits on 64-bit kernels?
Thanks,
Ingo
Re: [PATCH] Nokia N9: add support for up/down keys in the dts
Hi! > > > > This adds support for volume up/down keys in the dts. > > > > > > > > Signed-off-by: Pavel Machek > > > > > > Reviewed-by: Sebastian Reichel > > > > Tony, ping? Can I get you to apply this one? > > OK applying that for v4.16 so we have some kind of control of the > device without having to rely on the touch screen :) Thanks :-). > > [PATCHv2] nokia N9: Add support for magnetometer > > > > should be good to go, too... > > I have that tagged for next after -rc1 thanks. Actually, if you could get that one to v4.16, too. There's still lot of work to be done to get N9 into usable state, and delaying here does not do any good. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v5 05/12] x86, __get_user: use __uaccess_begin_nospec
* Dan Williams wrote:
> Quoting Linus:
>
> I do think that it would be a good idea to very expressly document
> the fact that it's not that the user access itself is unsafe. I do
> agree that things like "get_user()" want to be protected, but not
> because of any direct bugs or problems with get_user() and friends,
> but simply because get_user() is an excellent source of a pointer
> that is obviously controlled from a potentially attacking user
> space. So it's a prime candidate for then finding _subsequent_
> accesses that can then be used to perturb the cache.
>
> '__uaccess_begin_nospec' covers '__get_user' and 'copy_from_iter' where
> the limit check is far away from the user pointer de-reference. In those
> cases an 'lfence' prevents speculation with a potential pointer to
> privileged memory.
(Same style comments as for the previous patches)
>
> Suggested-by: Linus Torvalds
> Suggested-by: Andi Kleen
> Cc: Al Viro
> Cc: Kees Cook
> Cc: Thomas Gleixner
> Cc: "H. Peter Anvin"
> Cc: Ingo Molnar
> Cc: x...@kernel.org
> Signed-off-by: Dan Williams
> ---
> arch/x86/include/asm/uaccess.h|6 +++---
> arch/x86/include/asm/uaccess_32.h |6 +++---
> arch/x86/include/asm/uaccess_64.h | 12 ++--
> arch/x86/lib/usercopy_32.c|8
> 4 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
> index 626caf58183a..a930585fa3b5 100644
> --- a/arch/x86/include/asm/uaccess.h
> +++ b/arch/x86/include/asm/uaccess.h
> @@ -450,7 +450,7 @@ do {
> \
> ({ \
> int __gu_err; \
> __inttype(*(ptr)) __gu_val; \
> - __uaccess_begin(); \
> + __uaccess_begin_nospec(); \
> __get_user_size(__gu_val, (ptr), (size), __gu_err, -EFAULT);\
> __uaccess_end();\
> (x) = (__force __typeof__(*(ptr)))__gu_val; \
> @@ -557,7 +557,7 @@ struct __large_struct { unsigned long buf[100]; };
> * get_user_ex(...);
> * } get_user_catch(err)
> */
> -#define get_user_try uaccess_try
> +#define get_user_try uaccess_try_nospec
> #define get_user_catch(err) uaccess_catch(err)
>
> #define get_user_ex(x, ptr) do {\
> @@ -591,7 +591,7 @@ extern void __cmpxchg_wrong_size(void)
> __typeof__(ptr) __uval = (uval);\
> __typeof__(*(ptr)) __old = (old); \
> __typeof__(*(ptr)) __new = (new); \
> - __uaccess_begin(); \
> + __uaccess_begin_nospec(); \
> else
> n = __copy_user_intel(to, from, n);
> - clac();
> + __uaccess_end();
> return n;
> }
> EXPORT_SYMBOL(__copy_user_ll);
> @@ -344,7 +344,7 @@ EXPORT_SYMBOL(__copy_user_ll);
> unsigned long __copy_from_user_ll_nocache_nozero(void *to, const void __user
> *from,
> unsigned long n)
> {
> - stac();
> + __uaccess_begin_nospec();
> #ifdef CONFIG_X86_INTEL_USERCOPY
> if (n > 64 && static_cpu_has(X86_FEATURE_XMM2))
> n = __copy_user_intel_nocache(to, from, n);
> @@ -353,7 +353,7 @@ unsigned long __copy_from_user_ll_nocache_nozero(void
> *to, const void __user *fr
> #else
> __copy_user(to, from, n);
> #endif
> - clac();
> + __uaccess_end();
> return n;
> }
> EXPORT_SYMBOL(__copy_from_user_ll_nocache_nozero);
>
These three chunks appears to be unrelated changes changing open-coded clac()s
to
__uaccess_end() calls correctly: please split these out into a separate patch.
Thanks,
Ingo
Re: crash binary for latest unreleased kernel
On Sun, 2018-01-28 at 00:37 -0800, Joe Smith wrote: > I happen to look at the patches for the crash binary and came across > this log entry from Jan 19. I am also using 4.15-rc kernel. Not > knowing anything about crash it is hard to even attempt to fix it. It may not work all that well if box does something new/creative, but mundane manual crash, and live rummaging seem to work well enough. KERNEL: vmlinux-4.15.0.gc4e0ca7-master.gz DUMPFILE: vmcore CPUS: 8 DATE: Sun Jan 28 10:00:17 2018 UPTIME: 00:02:29 LOAD AVERAGE: 1.72, 1.12, 0.45 TASKS: 445 NODENAME: homer RELEASE: 4.15.0.gc4e0ca7-master VERSION: #563 SMP Sun Jan 28 04:07:36 CET 2018 MACHINE: x86_64 (3591 Mhz) MEMORY: 16 GB PANIC: "sysrq: SysRq : Trigger a crash" PID: 0 COMMAND: "swapper/2" TASK: 880187fd2940 (1 of 8) [THREAD_INFO: 880187fd2940] CPU: 2 STATE: TASK_RUNNING (SYSRQ) crash> bt PID: 0 TASK: 880187fd2940 CPU: 2 COMMAND: "swapper/2" #0 [88041ec83880] machine_kexec at 81041079 #1 [88041ec838d0] __crash_kexec at 810deede #2 [88041ec83988] crash_kexec at 810dfbbd #3 [88041ec839a0] oops_end at 8101c36e #4 [88041ec839c0] no_context at 8104f94d #5 [88041ec83a18] __do_page_fault at 81050068 #6 [88041ec83a80] do_page_fault at 81050492 #7 [88041ec83ab0] page_fault at 8160148c [exception RIP: sysrq_handle_crash+18] RIP: 81390892 RSP: 88041ec83b60 RFLAGS: 00010096 RAX: 81390880 RBX: 0063 RCX: 083f RDX: RSI: 00f6 RDI: 0063 RBP: 81e91960 R8: 036c R9: 00aa R10: ea000fe45bc0 R11: R12: 0001 R13: 0001 R14: 8803f4c521e0 R15: 8803f4c521f8 ORIG_RAX: CS: 0010 SS: 0018 #8 [88041ec83b60] __handle_sysrq at 81390f28 #9 [88041ec83b88] sysrq_filter at 81391097 #10 [88041ec83bb8] input_to_handler at 81419ceb #11 [88041ec83bf0] input_pass_values at 8141ae1d #12 [88041ec83c18] input_handle_event at 8141cdf4 #13 [88041ec83c48] input_event at 8141d2da #14 [88041ec83c80] hidinput_report_event at 81466e93 #15 [88041ec83c98] hid_report_raw_event at 8
Re: [PATCH v5 06/12] x86, get_user: use pointer masking to limit speculation
* Dan Williams wrote: > Quoting Linus: > > I do think that it would be a good idea to very expressly document > the fact that it's not that the user access itself is unsafe. I do > agree that things like "get_user()" want to be protected, but not > because of any direct bugs or problems with get_user() and friends, > but simply because get_user() is an excellent source of a pointer > that is obviously controlled from a potentially attacking user > space. So it's a prime candidate for then finding _subsequent_ > accesses that can then be used to perturb the cache. > > Unlike the '__get_user' case 'get_user' includes the address limit check > near the pointer de-reference. With that locality the speculation can be > mitigated with pointer narrowing rather than a barrier. Where the > narrowing is performed by: > > cmp %limit, %ptr > sbb %mask, %mask > and %mask, %ptr > > With respect to speculation the value of %ptr is either less than %limit > or NULL. (The style problems/inconsistencies of the #2 patch are repeated here too.) > --- a/arch/x86/lib/getuser.S > +++ b/arch/x86/lib/getuser.S > @@ -40,6 +40,8 @@ ENTRY(__get_user_1) > mov PER_CPU_VAR(current_task), %_ASM_DX > cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX > jae bad_get_user > + sbb %_ASM_DX, %_ASM_DX /* 0 - (uptr < addr_limit) */ > + and %_ASM_DX, %_ASM_AX > ASM_STAC > 1: movzbl (%_ASM_AX),%edx > xor %eax,%eax > @@ -54,6 +56,8 @@ ENTRY(__get_user_2) > mov PER_CPU_VAR(current_task), %_ASM_DX > cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX > jae bad_get_user > + sbb %_ASM_DX, %_ASM_DX /* 0 - (uptr < addr_limit) */ > + and %_ASM_DX, %_ASM_AX > ASM_STAC > 2: movzwl -1(%_ASM_AX),%edx > xor %eax,%eax > @@ -68,6 +72,8 @@ ENTRY(__get_user_4) > mov PER_CPU_VAR(current_task), %_ASM_DX > cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX > jae bad_get_user > + sbb %_ASM_DX, %_ASM_DX /* 0 - (uptr < addr_limit) */ > + and %_ASM_DX, %_ASM_AX > ASM_STAC > 3: movl -3(%_ASM_AX),%edx > xor %eax,%eax > @@ -83,6 +89,8 @@ ENTRY(__get_user_8) > mov PER_CPU_VAR(current_task), %_ASM_DX > cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX > jae bad_get_user > + sbb %_ASM_DX, %_ASM_DX /* 0 - (uptr < addr_limit) */ > + and %_ASM_DX, %_ASM_AX > ASM_STAC > 4: movq -7(%_ASM_AX),%rdx > xor %eax,%eax > @@ -94,6 +102,8 @@ ENTRY(__get_user_8) > mov PER_CPU_VAR(current_task), %_ASM_DX > cmp TASK_addr_limit(%_ASM_DX),%_ASM_AX > jae bad_get_user_8 > + sbb %_ASM_DX, %_ASM_DX /* 0 - (uptr < addr_limit) */ > + and %_ASM_DX, %_ASM_AX Please make it clear in the comments that these are essentially open-coded assembly versions of array_idx_mask_nospec(), that the purpose here is to provide as a partial speculation barrier against the value range of user-provided pointers. In a couple of years this sequence will be too obscure to understand at first glance. It would also make it easier to find these spots if someone wants to tweak (or backport) array_idx_mask_nospec() related changes. Thanks, Ingo
Re: [PATCH v5 07/12] x86: remove the syscall_64 fast-path
* Dan Williams wrote: > Quoting Linus: > > "Honestly, I'd rather get rid of the fast-path entirely. Compared to >all the PTI mess, it's not even noticeable. > >And if we ever get CPU's that have this all fixed, we can re-visit >introducing the fastpath. But this is all very messy and it doesn't >seem worth it right now. > >If we get rid of the fastpath, we can lay out the slow path slightly >better, and get rid of some of those jump-overs. And we'd get rid of >the ptregs hooks entirely. > >So we can try to make the "slow" path better while at it, but I >really don't think it matters much now in the post-PTI era. Sadly." Please fix the title to have the proper prefix and to reference the function that is actually modified by the patch, i.e. something like: s/ x86: remove the syscall_64 fast-path / x86/entry/64: Remove the entry_SYSCALL_64() fast-path With the title fixed: Reviewed-by: Ingo Molnar Thanks, Ingo
Re: [RFP] iio: Support of gesture sensor as a standard IIO sensor
On Sun, 28 Jan 2018 09:40:03 +0100 Pavel Machek wrote: > hi! > > > > > Correct. This will depend on the firmware expected format . I > > > > think > > > > ultimately it will be standardized. > > > Is it fair to say that "expected" format is some kind of bytecode for > > > CPU in the gesture sensor? > > Not necessarily a byte code to execute on the CPU in the gesture > > sensor, but a format the code running on that CPU understands the way > > gestures are formatted. > > But it can be byte code for some manufacturers, so idea is just pass to > > the firmware and let it process it an opaque format. > > It would be really good to figure out common format for different > sensors. Otherwise kernel is not providing proper hardware > abstraction. > > Pavel A common format, if it is byte code, would require in kernel compilers for the various sensors. Not going to happen. Common format for everything other than the 'load magic firmware' part might be doable. As in we can describe what the magic firmware is doing... Jonathan
Re: [PATCH v2] iio: accel: bmc150: Check for a second ACPI device for BOSC0200
On Sun, 14 Jan 2018 10:43:30 + Jonathan Cameron wrote: > On Tue, 9 Jan 2018 21:24:01 + > Jeremy Cline wrote: > > > On 12/10/2017 12:21 PM, Jonathan Cameron wrote: > > > On Wed, 6 Dec 2017 17:52:34 + > > > Jeremy Cline wrote: > > > > > >> Some BOSC0200 acpi_device-s describe two accelerometers in a single ACPI > > >> device. Check for a companion device and handle a second i2c_client > > >> if it is present. > > >> > > >> Signed-off-by: Jeremy Cline > > > The requirement for this is still horrible, but you have done a nice > > > clean job on implementing it. > > > > > > I'll let this sit for a few more days though before applying it. > > > Probably next weekend if we don't get any feedback before then. > > > > Hey, > > > > I didn't see this land anywhere (I was looking in > > git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git, maybe that's not > > the right place?) and I just wanted to make sure this didn't get lost in > > the holiday shuffle. > It did indeed get lost - thanks for the reminder. Now applied to the > togreg branch of iio.git. However, unfortunately we may be too near > to the merge window opening for it to make it. Depends on what Linus > says later today when rc8 comes out. I've added some #ifdef CONFIG_ACPI defenses against the case of no ACPI support being compiled in. Alternative would be to add stubs for those functions that don't have them... probably just acpi_device_hid. But that would take much longer. Feel free to propose it and a patch removing the ifdef fun if you like! Jonathan > > Jonathan > > > > > Regards, > > Jeremy > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] x86/ibpb: Skip IBPB when we switch back to same user process
* Tim Chen wrote: > Thanks to the reviewers and Andy Lutomirski for the suggestion of > using ctx_id which got rid of the problem of mm pointer recycling. > Here's an update of this patch based on Andy's suggestion. > > We could switch to a kernel idle thread and then back to the original > process such as: > process A -> idle -> process A > > In such scenario, we do not have to do IBPB here even though the process is > non-dumpable, as we are switching back to the same process after > an hiatus. > > We track the last mm user context id before we switch to init_mm by calling > leave_mm when tlb_defer_switch_to_init_mm returns false (pcid available). > > The cost is to have an extra u64 mm context id to track the last mm we were > using before > switching to the init_mm used by idle. Avoiding the extra IBPB > is probably worth the extra memory for this common scenario. > > For those cases where tlb_defer_switch_to_init_mm returns true (non pcid), > lazy tlb will defer switch to init_mm, so we will not be changing > the mm for the process A -> idle -> process A switch. So > IBPB will be skipped for this case. > > v2: > 1. Save last user context id instead of last user mm to avoid the problem of > recycled mm > > Signed-off-by: Tim Chen > --- > arch/x86/include/asm/tlbflush.h | 2 ++ > arch/x86/mm/tlb.c | 23 --- > 2 files changed, 18 insertions(+), 7 deletions(-) What tree is this patch against? It doesn't apply to linus's latest, nor to tip:master. Thanks, Ingo
Re: crash binary for latest unreleased kernel
On Sun, 2018-01-28 at 10:20 +0100, Mike Galbraith wrote: > On Sun, 2018-01-28 at 00:37 -0800, Joe Smith wrote: > > I happen to look at the patches for the crash binary and came across > > this log entry from Jan 19. I am also using 4.15-rc kernel. Not > > knowing anything about crash it is hard to even attempt to fix it. > > It may not work all that well if box does something new/creative, but > mundane manual crash, and live rummaging seem to work well enough. And looking through my modified makedumpfile package, looks like I've replaced everything I had ever done do it with backports from newer versions, so you should be able to get kdump working with nothing more than an update to makefumpfile, plus virgin upstream crash source. -Mike
Re: Ping Re: [PATCH] virtio: make VIRTIO a menuconfig to ease disabling it all
Vincent Legoll writes: > On 1/23/18, Michael Ellerman wrote: >> This has been broken in linux-next for ~6 weeks now, can we please merge >> this and get it fixed. > > Added Stephen Rothwell to cc It should be fixed in the virtio tree, which the other Michael and Jason maintain AFAIK. cheers
[GIT pull] locking: Fixes for 4.15
Linus,
please pull the latest locking-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
locking-urgent-for-linus
Two final fixes for 4.15:
- Repair the OWNER_DIED logic in the futex code which got wreckaged with the
recent fix for a subtle race condition.
- Prevent the hard lockup detector from triggering when dumping all held
locks in the system.
Thanks,
tglx
-->
Peter Zijlstra (1):
futex: Fix OWNER_DEAD fixup
Tejun Heo (1):
locking/lockdep: Avoid triggering hardlockup from debug_show_all_locks()
kernel/futex.c | 6 +++---
kernel/locking/lockdep.c | 2 ++
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index 8c5424dd5924..7f719d110908 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2311,9 +2311,6 @@ static int fixup_pi_state_owner(u32 __user *uaddr, struct
futex_q *q,
raw_spin_lock_irq(&pi_state->pi_mutex.wait_lock);
oldowner = pi_state->owner;
- /* Owner died? */
- if (!pi_state->owner)
- newtid |= FUTEX_OWNER_DIED;
/*
* We are here because either:
@@ -2374,6 +2371,9 @@ static int fixup_pi_state_owner(u32 __user *uaddr, struct
futex_q *q,
}
newtid = task_pid_vnr(newowner) | FUTEX_WAITERS;
+ /* Owner died? */
+ if (!pi_state->owner)
+ newtid |= FUTEX_OWNER_DIED;
if (get_futex_value_locked(&uval, uaddr))
goto handle_fault;
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 5fa1324a4f29..521659044719 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -49,6 +49,7 @@
#include
#include
#include
+#include
#include
@@ -4490,6 +4491,7 @@ void debug_show_all_locks(void)
if (!unlock)
if (read_trylock(&tasklist_lock))
unlock = 1;
+ touch_nmi_watchdog();
} while_each_thread(g, p);
pr_warn("\n");
[GIT pull] perf fixes for 4.15
Linus,
please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
Four patches which all address lock inversions and deadlocks in the perf
core code and the Intel debug store.
Thanks,
tglx
-->
Peter Zijlstra (4):
perf/core: Fix lock inversion between perf,trace,cpuhp
perf/core: Fix another perf,trace,cpuhp lock inversion
perf/core: Fix ctx::mutex deadlock
perf/x86: Fix perf,x86,cpuhp deadlock
arch/x86/events/intel/ds.c | 33 +---
kernel/events/core.c | 47 +-
2 files changed, 60 insertions(+), 20 deletions(-)
diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
index 8156e47da7ba..18c25ab28557 100644
--- a/arch/x86/events/intel/ds.c
+++ b/arch/x86/events/intel/ds.c
@@ -372,10 +372,9 @@ static int alloc_pebs_buffer(int cpu)
static void release_pebs_buffer(int cpu)
{
struct cpu_hw_events *hwev = per_cpu_ptr(&cpu_hw_events, cpu);
- struct debug_store *ds = hwev->ds;
void *cea;
- if (!ds || !x86_pmu.pebs)
+ if (!x86_pmu.pebs)
return;
kfree(per_cpu(insn_buffer, cpu));
@@ -384,7 +383,6 @@ static void release_pebs_buffer(int cpu)
/* Clear the fixmap */
cea = &get_cpu_entry_area(cpu)->cpu_debug_buffers.pebs_buffer;
ds_clear_cea(cea, x86_pmu.pebs_buffer_size);
- ds->pebs_buffer_base = 0;
dsfree_pages(hwev->ds_pebs_vaddr, x86_pmu.pebs_buffer_size);
hwev->ds_pebs_vaddr = NULL;
}
@@ -419,16 +417,14 @@ static int alloc_bts_buffer(int cpu)
static void release_bts_buffer(int cpu)
{
struct cpu_hw_events *hwev = per_cpu_ptr(&cpu_hw_events, cpu);
- struct debug_store *ds = hwev->ds;
void *cea;
- if (!ds || !x86_pmu.bts)
+ if (!x86_pmu.bts)
return;
/* Clear the fixmap */
cea = &get_cpu_entry_area(cpu)->cpu_debug_buffers.bts_buffer;
ds_clear_cea(cea, BTS_BUFFER_SIZE);
- ds->bts_buffer_base = 0;
dsfree_pages(hwev->ds_bts_vaddr, BTS_BUFFER_SIZE);
hwev->ds_bts_vaddr = NULL;
}
@@ -454,16 +450,22 @@ void release_ds_buffers(void)
if (!x86_pmu.bts && !x86_pmu.pebs)
return;
- get_online_cpus();
- for_each_online_cpu(cpu)
+ for_each_possible_cpu(cpu)
+ release_ds_buffer(cpu);
+
+ for_each_possible_cpu(cpu) {
+ /*
+* Again, ignore errors from offline CPUs, they will no longer
+* observe cpu_hw_events.ds and not program the DS_AREA when
+* they come up.
+*/
fini_debug_store_on_cpu(cpu);
+ }
for_each_possible_cpu(cpu) {
release_pebs_buffer(cpu);
release_bts_buffer(cpu);
- release_ds_buffer(cpu);
}
- put_online_cpus();
}
void reserve_ds_buffers(void)
@@ -483,8 +485,6 @@ void reserve_ds_buffers(void)
if (!x86_pmu.pebs)
pebs_err = 1;
- get_online_cpus();
-
for_each_possible_cpu(cpu) {
if (alloc_ds_buffer(cpu)) {
bts_err = 1;
@@ -521,11 +521,14 @@ void reserve_ds_buffers(void)
if (x86_pmu.pebs && !pebs_err)
x86_pmu.pebs_active = 1;
- for_each_online_cpu(cpu)
+ for_each_possible_cpu(cpu) {
+ /*
+* Ignores wrmsr_on_cpu() errors for offline CPUs they
+* will get this call through intel_pmu_cpu_starting().
+*/
init_debug_store_on_cpu(cpu);
+ }
}
-
- put_online_cpus();
}
/*
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 4df5b695bf0d..5d8f4031f8d5 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -1231,6 +1231,10 @@ static void put_ctx(struct perf_event_context *ctx)
* perf_event_context::lock
* perf_event::mmap_mutex
* mmap_sem
+ *
+ *cpu_hotplug_lock
+ * pmus_lock
+ * cpuctx->mutex / perf_event_context::mutex
*/
static struct perf_event_context *
perf_event_ctx_lock_nested(struct perf_event *event, int nesting)
@@ -4196,6 +4200,7 @@ int perf_event_release_kernel(struct perf_event *event)
{
struct perf_event_context *ctx = event->ctx;
struct perf_event *child, *tmp;
+ LIST_HEAD(free_list);
/*
* If we got here through err_file: fput(event_file); we will not have
@@ -4268,8 +4273,7 @@ int perf_event_release_kernel(struct perf_event *event)
struct perf_event, child_list);
if (tmp == child) {
perf_remove_from_context(child, DETACH_GROUP);
- list_del(&ch
[GIT pull] scheduler fix for 4.15
Linus,
please pull the latest sched-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-for-linus
A single bug fix to prevent a subtle deadlock in the scheduler core code
vs. cpu hotplug.
Thanks,
tglx
-->
Peter Zijlstra (1):
sched/core: Fix cpu.max vs. cpuhotplug deadlock
include/linux/jump_label.h | 7 +++
kernel/jump_label.c| 12 +---
kernel/sched/fair.c| 4 ++--
3 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index c7b368c734af..e0340ca08d98 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -160,6 +160,8 @@ extern void arch_jump_label_transform_static(struct
jump_entry *entry,
extern int jump_label_text_reserved(void *start, void *end);
extern void static_key_slow_inc(struct static_key *key);
extern void static_key_slow_dec(struct static_key *key);
+extern void static_key_slow_inc_cpuslocked(struct static_key *key);
+extern void static_key_slow_dec_cpuslocked(struct static_key *key);
extern void jump_label_apply_nops(struct module *mod);
extern int static_key_count(struct static_key *key);
extern void static_key_enable(struct static_key *key);
@@ -222,6 +224,9 @@ static inline void static_key_slow_dec(struct static_key
*key)
atomic_dec(&key->enabled);
}
+#define static_key_slow_inc_cpuslocked(key) static_key_slow_inc(key)
+#define static_key_slow_dec_cpuslocked(key) static_key_slow_dec(key)
+
static inline int jump_label_text_reserved(void *start, void *end)
{
return 0;
@@ -416,6 +421,8 @@ extern bool wrong_branch_error(void);
#define static_branch_inc(x) static_key_slow_inc(&(x)->key)
#define static_branch_dec(x) static_key_slow_dec(&(x)->key)
+#define static_branch_inc_cpuslocked(x)
static_key_slow_inc_cpuslocked(&(x)->key)
+#define static_branch_dec_cpuslocked(x)
static_key_slow_dec_cpuslocked(&(x)->key)
/*
* Normal usage; boolean enable/disable.
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 8594d24e4adc..b4517095db6a 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -79,7 +79,7 @@ int static_key_count(struct static_key *key)
}
EXPORT_SYMBOL_GPL(static_key_count);
-static void static_key_slow_inc_cpuslocked(struct static_key *key)
+void static_key_slow_inc_cpuslocked(struct static_key *key)
{
int v, v1;
@@ -180,7 +180,7 @@ void static_key_disable(struct static_key *key)
}
EXPORT_SYMBOL_GPL(static_key_disable);
-static void static_key_slow_dec_cpuslocked(struct static_key *key,
+static void __static_key_slow_dec_cpuslocked(struct static_key *key,
unsigned long rate_limit,
struct delayed_work *work)
{
@@ -211,7 +211,7 @@ static void __static_key_slow_dec(struct static_key *key,
struct delayed_work *work)
{
cpus_read_lock();
- static_key_slow_dec_cpuslocked(key, rate_limit, work);
+ __static_key_slow_dec_cpuslocked(key, rate_limit, work);
cpus_read_unlock();
}
@@ -229,6 +229,12 @@ void static_key_slow_dec(struct static_key *key)
}
EXPORT_SYMBOL_GPL(static_key_slow_dec);
+void static_key_slow_dec_cpuslocked(struct static_key *key)
+{
+ STATIC_KEY_CHECK_USE(key);
+ __static_key_slow_dec_cpuslocked(key, 0, NULL);
+}
+
void static_key_slow_dec_deferred(struct static_key_deferred *key)
{
STATIC_KEY_CHECK_USE(key);
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 2fe3aa853e4d..26a71ebcd3c2 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4365,12 +4365,12 @@ static inline bool cfs_bandwidth_used(void)
void cfs_bandwidth_usage_inc(void)
{
- static_key_slow_inc(&__cfs_bandwidth_used);
+ static_key_slow_inc_cpuslocked(&__cfs_bandwidth_used);
}
void cfs_bandwidth_usage_dec(void)
{
- static_key_slow_dec(&__cfs_bandwidth_used);
+ static_key_slow_dec_cpuslocked(&__cfs_bandwidth_used);
}
#else /* HAVE_JUMP_LABEL */
static bool cfs_bandwidth_used(void)
[GIT pull] timer fix for 4.15
Linus,
please pull the latest timers-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers-urgent-for-linus
A single fix for a ~10 years old problem which causes high resolution
timers to stop after a CPU unplug/plug cycle due to a stale flag in the per
CPU hrtimer base struct. Paul McKenney was hunting this for about a year,
but the heisenbug nature made it resistant against debug attempts for quite
some time.
Thanks,
tglx
-->
Thomas Gleixner (1):
hrtimer: Reset hrtimer cpu base proper on CPU hotplug
kernel/time/hrtimer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index d32520840fde..aa9d2a2b1210 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -655,7 +655,9 @@ static void hrtimer_reprogram(struct hrtimer *timer,
static inline void hrtimer_init_hres(struct hrtimer_cpu_base *base)
{
base->expires_next = KTIME_MAX;
+ base->hang_detected = 0;
base->hres_active = 0;
+ base->next_timer = NULL;
}
/*
@@ -1589,6 +1591,7 @@ int hrtimers_prepare_cpu(unsigned int cpu)
timerqueue_init_head(&cpu_base->clock_base[i].active);
}
+ cpu_base->active_bases = 0;
cpu_base->cpu = cpu;
hrtimer_init_hres(cpu_base);
return 0;
Re: [RFC] apparent bogosity in unregister_ftrace_function_probe_func()
On Sat, 27 Jan 2018 17:07:48 +
Al Viro wrote:
Hi Al,
> On Sat, Jan 27, 2018 at 01:59:56PM +, Dmitry Safonov wrote:
> >
> > > Incidentally, shouldn't filter_parse_regex("*[ab]", 5, &s, ¬)
> > > end up with s = "*[ab]"? We are returning MATCH_GLOB, after all,
> > > so we want the entire pattern there... I would've assumed that
> > > this is what the code in unregister_ftrace_function_probe_func()
> > > is trying to compensate for, the first oddity predates MATCH_GLOB...
> >
> > No, I don't think filter_parse_regex() should return the full regex..
> > ftrace_match() expects search would be processed string, not a glob.
> > So, this unnecessary assignment broke unregistering multiple kprobs
> > with a middle/end pattern..
>
> For substring - sure, but what about something like "*a*b" and "a*b"?
> AFAICS, filter_parse_regex() ends up with identical results in both
> cases - MATCH_GLOB and *search = "a*b". And no way for the caller
> to tell one from another.
>
> IOW, it's a different bug sometimes obscured by the one in
> unregister_ftrace_function_probe_func(). filter_parse_regex()
> ought to revert to *search = buff; when it decides to return
> MATCH_GLOB. Or something like
> for (i = 0; i < len; i++) {
> if (buff[i] == '*') {
> if (!i) {
> type = MATCH_END_ONLY;
> } else if (i == len - 1) {
> if (type == MATCH_END_ONLY)
> type = MATCH_MIDDLE_ONLY;
> else
> type = MATCH_FRONT_ONLY;
> buff[i] = 0;
> break;
> } else {/* pattern continues, use full glob */
> return MATCH_GLOB;
> }
> } else if (strchr("[?\\", buff[i])) {
> return MATCH_GLOB;
> }
> }
> if (buff[0] == '*')
> *search = buff + 1;
> for that matter - i.e. delay that "we want everything past the first
> character"
> until we are certain it's not a MATCH_GLOB.
>
> That one was introduced by "ftrace: Support full glob matching" in 2016,
> AFAICS...
Yep, I totally agree. This code is one of those places that haven't had
the loving it deserved. It was one of our neglected children.
Thanks for taking a look here. I'm a bit embarrassed by this, and
should have audited it more. I'll have to rip into it and see what else
may be incorrect.
-- Steve
[GIT pull] x86 fixes for 4.15
Linus,
please pull the latest x86-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-urgent-for-linus
A set of small fixes for 4.15:
- Fix vmapped stack synchronization on systems with 4-level paging and a
large amount of memory caused by a missing 5-level folding which made
the pgd synchronization logic to fail and causing double faults.
- Add a missing sanity check in the vmalloc_fault() logic on 5-level
paging systems.
- Bring back protection against accessing a freed initrd in the microcode
loader which was lost by a wrong merge conflict resolution.
- Extend the Broadwell micro code loading sanity check.
- Add a missing ENDPROC annotation in ftrace assembly code which makes ORC
unhappy.
- Prevent loading the AMD power module on !AMD platforms. The load itself
is uncritical, but an unload attempt results in a kernel crash.
- Update Peter Anvins role in the MAINTAINERS file.
Thanks,
tglx
-->
Andy Lutomirski (2):
x86/mm/64: Fix vmapped stack syncing on very-large-memory 4-level systems
x86/mm/64: Tighten up vmalloc_fault() sanity checks on 5-level kernels
Borislav Petkov (1):
x86/microcode: Fix again accessing initrd after having been freed
H. Peter Anvin (1):
x86: Mark hpa as a "Designated Reviewer" for the time being
Jia Zhang (1):
x86/microcode/intel: Extend BDW late-loading further with LLC size check
Josh Poimboeuf (1):
x86/ftrace: Add one more ENDPROC annotation
Xiao Liang (1):
perf/x86/amd/power: Do not load AMD power module on !AMD platforms
MAINTAINERS | 12 +---
arch/x86/events/amd/power.c | 2 +-
arch/x86/kernel/cpu/microcode/core.c | 2 +-
arch/x86/kernel/cpu/microcode/intel.c | 20 ++--
arch/x86/kernel/ftrace_64.S | 2 +-
arch/x86/mm/fault.c | 22 +-
arch/x86/mm/tlb.c | 34 +-
7 files changed, 60 insertions(+), 34 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e3581413420c..94976349ff61 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6609,16 +6609,6 @@ L: linux-...@vger.kernel.org
S: Maintained
F: drivers/i2c/i2c-stub.c
-i386 BOOT CODE
-M: "H. Peter Anvin"
-S: Maintained
-F: arch/x86/boot/
-
-i386 SETUP CODE / CPU ERRATA WORKAROUNDS
-M: "H. Peter Anvin"
-T: git
git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git
-S: Maintained
-
IA64 (Itanium) PLATFORM
M: Tony Luck
M: Fenghua Yu
@@ -14858,7 +14848,7 @@ F: net/x25/
X86 ARCHITECTURE (32-BIT AND 64-BIT)
M: Thomas Gleixner
M: Ingo Molnar
-M: "H. Peter Anvin"
+R: "H. Peter Anvin"
M: x...@kernel.org
L: linux-kernel@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/core
diff --git a/arch/x86/events/amd/power.c b/arch/x86/events/amd/power.c
index a6eee5ac4f58..2aefacf5c5b2 100644
--- a/arch/x86/events/amd/power.c
+++ b/arch/x86/events/amd/power.c
@@ -277,7 +277,7 @@ static int __init amd_power_pmu_init(void)
int ret;
if (!x86_match_cpu(cpu_match))
- return 0;
+ return -ENODEV;
if (!boot_cpu_has(X86_FEATURE_ACC_POWER))
return -ENODEV;
diff --git a/arch/x86/kernel/cpu/microcode/core.c
b/arch/x86/kernel/cpu/microcode/core.c
index c4fa4a85d4cb..e4fc595cd6ea 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -239,7 +239,7 @@ static int __init save_microcode_in_initrd(void)
break;
case X86_VENDOR_AMD:
if (c->x86 >= 0x10)
- return save_microcode_in_initrd_amd(cpuid_eax(1));
+ ret = save_microcode_in_initrd_amd(cpuid_eax(1));
break;
default:
break;
diff --git a/arch/x86/kernel/cpu/microcode/intel.c
b/arch/x86/kernel/cpu/microcode/intel.c
index d9e460fc7a3b..f7c55b0e753a 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -45,6 +45,9 @@ static const char ucode_path[] =
"kernel/x86/microcode/GenuineIntel.bin";
/* Current microcode patch used in early patching on the APs. */
static struct microcode_intel *intel_ucode_patch;
+/* last level cache size per core */
+static int llc_size_per_core;
+
static inline bool cpu_signatures_match(unsigned int s1, unsigned int p1,
unsigned int s2, unsigned int p2)
{
@@ -912,12 +915,14 @@ static bool is_blacklisted(unsigned int cpu)
/*
* Late loading on model 79 with microcode revision less than 0x0b21
-* may result in a system hang. This behavior is documented in item
-* BDF90, #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family).
+* and LLC size per core bigg
Re: [PATCH v2] x86/ibpb: Skip IBPB when we switch back to same user process
On Sun, 2018-01-28 at 10:56 +0100, Ingo Molnar wrote: > > What tree is this patch against? It doesn't apply to linus's latest, nor to > tip:master. It's in my tree at http://git.infradead.org/users/dwmw2/linux-retpoline.git/shortlog/refs/heads/ibpb which is gradually being finalized and flushed via tip/x86/pti. The IBPB on context switch parts are currently the first three patches there, which roughly suggests they might be the next to get sent out for real, if we have reached a consensus. The three patches there probably want collapsing into one, but I've left them as-is for now while we're discussing it. The other thing that's next on the list is exposing the MSRs to guests. The IBPB one is fairly simple, and Karim is working on exposing IBRS to guests too, using Paolo's per-vCPU MSR bitmap to do the same trick we've done in Xen, to expose it only after the guest first touches it (to avoid the cost of swapping it when it's always 0←→0 in the common case). I think Ashok was talking about doing the same thing? We'll see who gets there first :) smime.p7s Description: S/MIME cryptographic signature
[GIT pull] x86/pti fix for 4.15
Linus, please pull the latest x86-pti-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-pti-for-linus Remove the ESP/RSP thunks for retpoline as they cannot ever work. Remove them before they show up in a release. Thanks, tglx --> Waiman Long (1): x86/retpoline: Remove the esp/rsp thunk arch/x86/include/asm/asm-prototypes.h | 1 - arch/x86/lib/retpoline.S | 1 - 2 files changed, 2 deletions(-) diff --git a/arch/x86/include/asm/asm-prototypes.h b/arch/x86/include/asm/asm-prototypes.h index 0927cdc4f946..1908214b9125 100644 --- a/arch/x86/include/asm/asm-prototypes.h +++ b/arch/x86/include/asm/asm-prototypes.h @@ -38,5 +38,4 @@ INDIRECT_THUNK(dx) INDIRECT_THUNK(si) INDIRECT_THUNK(di) INDIRECT_THUNK(bp) -INDIRECT_THUNK(sp) #endif /* CONFIG_RETPOLINE */ diff --git a/arch/x86/lib/retpoline.S b/arch/x86/lib/retpoline.S index dfb2ba91b670..c909961e678a 100644 --- a/arch/x86/lib/retpoline.S +++ b/arch/x86/lib/retpoline.S @@ -36,7 +36,6 @@ GENERATE_THUNK(_ASM_DX) GENERATE_THUNK(_ASM_SI) GENERATE_THUNK(_ASM_DI) GENERATE_THUNK(_ASM_BP) -GENERATE_THUNK(_ASM_SP) #ifdef CONFIG_64BIT GENERATE_THUNK(r8) GENERATE_THUNK(r9)
Re: [PATCH 05/16] iio: adc: sun4i-gpadc-iio: rework: support clocks and reset
On 28.01.2018 09:50, Jonathan Cameron wrote:
On Fri, 26 Jan 2018 16:19:30 +0100
Philipp Rossak wrote:
For adding newer sensor some basic rework of the code is necessary.
The SoCs after H3 has newer thermal sensor ADCs, which have two clock
inputs (bus clock and sampling clock) and a reset. The registers are
also re-arranged.
This commit reworks the code, adds the process of the clocks and
resets.
Signed-off-by: Philipp Rossak
Signed-off-by: Icenowy Zheng
Both clock and reset code is safe against null parameters, so you can
drop a lot of 'is it here' checks in this. They could be argued to
act as documentation of the fact we really don't expect them in some cases
I suppose...
Ok, this sounds good for me!
I will fix that in the next version of this patch series.
---
drivers/iio/adc/sun4i-gpadc-iio.c | 80 +++
1 file changed, 80 insertions(+)
diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
b/drivers/iio/adc/sun4i-gpadc-iio.c
index 363936b37c5a..1a80744bd472 100644
--- a/drivers/iio/adc/sun4i-gpadc-iio.c
+++ b/drivers/iio/adc/sun4i-gpadc-iio.c
@@ -22,6 +22,7 @@
* shutdown for not being used.
*/
+#include
#include
#include
#include
@@ -31,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -75,6 +77,9 @@ struct gpadc_data {
u32 ctrl2_map;
u32 sensor_en_map;
u32 filter_map;
+ boolhas_bus_clk;
+ boolhas_bus_rst;
+ boolhas_mod_clk;
};
static const struct gpadc_data sun4i_gpadc_data = {
@@ -134,6 +139,9 @@ struct sun4i_gpadc_iio {
atomic_tignore_temp_data_irq;
const struct gpadc_data *data;
boolno_irq;
+ struct clk *bus_clk;
+ struct clk *mod_clk;
+ struct reset_control*reset;
/* prevents concurrent reads of temperature and ADC */
struct mutexmutex;
struct thermal_zone_device *tzd;
@@ -435,6 +443,12 @@ static int sun4i_gpadc_runtime_suspend(struct device *dev)
{
struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev));
+ if (info->data->has_mod_clk)
+ clk_disable(info->mod_clk);
Safe against null parameter... (see below)
+
+ if (info->data->has_bus_clk)
+ clk_disable(info->bus_clk);
+
return info->data->sample_end(info);
}
@@ -483,6 +497,12 @@ static int sun4i_gpadc_runtime_resume(struct device *dev)
{
struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev));
+ if (info->data->has_mod_clk)
+ clk_enable(info->mod_clk);
clk_enable is safe against null parameter so could do without the checks.
+
+ if (info->data->has_bus_clk)
+ clk_enable(info->bus_clk);
+
return info->data->sample_start(info);
}
@@ -597,10 +617,61 @@ static int sun4i_gpadc_probe_dt(struct platform_device *pdev,
return ret;
}
+ if (info->data->has_bus_rst) {
+ info->reset = devm_reset_control_get(&pdev->dev, NULL);
+ if (IS_ERR(info->reset)) {
+ ret = PTR_ERR(info->reset);
+ return ret;
+ }
+
+ ret = reset_control_deassert(info->reset);
+ if (ret)
+ return ret;
+ }
+
+ if (info->data->has_bus_clk) {
+ info->bus_clk = devm_clk_get(&pdev->dev, "bus");
+ if (IS_ERR(info->bus_clk)) {
+ ret = PTR_ERR(info->bus_clk);
+ goto assert_reset;
+ }
+
+ ret = clk_prepare_enable(info->bus_clk);
+ if (ret)
+ goto assert_reset;
+ }
+
+ if (info->data->has_mod_clk) {
+ info->mod_clk = devm_clk_get(&pdev->dev, "mod");
+ if (IS_ERR(info->mod_clk)) {
+ ret = PTR_ERR(info->mod_clk);
+ goto disable_bus_clk;
+ }
+
+ /* Running at 6MHz */
+ ret = clk_set_rate(info->mod_clk, 400);
+ if (ret)
+ goto disable_bus_clk;
+
+ ret = clk_prepare_enable(info->mod_clk);
+ if (ret)
+ goto disable_bus_clk;
+ }
+
if (IS_ENABLED(CONFIG_THERMAL_OF))
info->sensor_device = &pdev->dev;
return 0;
+
+disable_bus_clk:
+ if (info->data->has_bus_clk)
+ clk_disable_unprepare(info->bus_clk);
+
+assert_reset:
+ if (info->data->has_bus_rst)
+ reset_control_assert(info->reset);
+
+ return ret;
}
static int sun4i_gpadc_probe_mfd(struct platform_device *pdev,
@@ -766,6 +837,15 @@ static int sun4i_gpadc_remove(struct platform_d
Re: [PATCH v5 02/12] array_idx: sanitize speculative array de-references
On Sun, 28 Jan 2018, Ingo Molnar wrote:
> * Dan Williams wrote:
> > +
> > +#ifndef __NOSPEC_H__
> > +#define __NOSPEC_H__
_LINUX_NOSPEC_H
We have an established practice for those header guards...
> > +/*
> > + * When idx is out of bounds (idx >= sz), the sign bit will be set.
> > + * Extend the sign bit to all bits and invert, giving a result of zero
> > + * for an out of bounds idx, or ~0UL if within bounds [0, sz).
> > + */
> > +#ifndef array_idx_mask
> > +static inline unsigned long array_idx_mask(unsigned long idx, unsigned
> > long sz)
> > +{
> > + /*
> > +* Warn developers about inappropriate array_idx usage.
> > +*
> > +* Even if the cpu speculates past the WARN_ONCE branch, the
>
> s/cpu/CPU
>
> > +* sign bit of idx is taken into account when generating the
> > +* mask.
> > +*
> > +* This warning is compiled out when the compiler can infer that
> > +* idx and sz are less than LONG_MAX.
>
> Please use 'idx' and 'sz' in quotes, to make sure they stand out more in free
> flowing comment text. Also please use '()' to denote functions/methods.
>
> I.e. something like:
>
>* Warn developers about inappropriate array_idx() usage.
>*
>* Even if the CPU speculates past the WARN_ONCE() branch, the
>* sign bit of 'idx' is taken into account when generating the
>* mask.
>*
>* This warning is compiled out when the compiler can infer that
>* 'idx' and 'sz' are less than LONG_MAX.
I rather prefer to have a proper kernel doc instead of the comment above
the function and then use @idx and @sz in the code comments.
Thanks,
tglx
Re: [PATCH 4.9] usbip: vhci_hcd: clear just the USB_PORT_STAT_POWER bit
On Fri, Jan 26, 2018 at 11:54:35AM -0700, Shuah Khan wrote:
> Upstream commit 1c9de5bf4286 ("usbip: vhci-hcd: Add USB3 SuperSpeed
> support")
Hm, I think you have the wrong commit id here.
I don't see any commit upstream with the Subject you have here, what are
you referring to?
thanks,
greg k-h
[PATCH] IB/mthca: remove mthca_user.h
mthca_user.h is unused since commit 486f60954c71 ("IB/mthca: Move user vendor
structures")
Remove it from tree.
Signed-off-by: Corentin Labbe
---
drivers/infiniband/hw/mthca/mthca_user.h | 112 ---
1 file changed, 112 deletions(-)
delete mode 100644 drivers/infiniband/hw/mthca/mthca_user.h
diff --git a/drivers/infiniband/hw/mthca/mthca_user.h
b/drivers/infiniband/hw/mthca/mthca_user.h
deleted file mode 100644
index 5fe56e810739..
--- a/drivers/infiniband/hw/mthca/mthca_user.h
+++ /dev/null
@@ -1,112 +0,0 @@
-/*
- * Copyright (c) 2005 Topspin Communications. All rights reserved.
- * Copyright (c) 2005, 2006 Cisco Systems. All rights reserved.
- *
- * This software is available to you under a choice of one of two
- * licenses. You may choose to be licensed under the terms of the GNU
- * General Public License (GPL) Version 2, available from the file
- * COPYING in the main directory of this source tree, or the
- * OpenIB.org BSD license below:
- *
- * Redistribution and use in source and binary forms, with or
- * without modification, are permitted provided that the following
- * conditions are met:
- *
- * - Redistributions of source code must retain the above
- *copyright notice, this list of conditions and the following
- *disclaimer.
- *
- * - Redistributions in binary form must reproduce the above
- *copyright notice, this list of conditions and the following
- *disclaimer in the documentation and/or other materials
- *provided with the distribution.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
- * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
- * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
- * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
- * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
- * SOFTWARE.
- */
-
-#ifndef MTHCA_USER_H
-#define MTHCA_USER_H
-
-#include
-
-/*
- * Increment this value if any changes that break userspace ABI
- * compatibility are made.
- */
-#define MTHCA_UVERBS_ABI_VERSION 1
-
-/*
- * Make sure that all structs defined in this file remain laid out so
- * that they pack the same way on 32-bit and 64-bit architectures (to
- * avoid incompatibility between 32-bit userspace and 64-bit kernels).
- * In particular do not use pointer types -- pass pointers in __u64
- * instead.
- */
-
-struct mthca_alloc_ucontext_resp {
- __u32 qp_tab_size;
- __u32 uarc_size;
-};
-
-struct mthca_alloc_pd_resp {
- __u32 pdn;
- __u32 reserved;
-};
-
-struct mthca_reg_mr {
-/*
- * Mark the memory region with a DMA attribute that causes
- * in-flight DMA to be flushed when the region is written to:
- */
-#define MTHCA_MR_DMASYNC 0x1
- __u32 mr_attrs;
- __u32 reserved;
-};
-
-struct mthca_create_cq {
- __u32 lkey;
- __u32 pdn;
- __u64 arm_db_page;
- __u64 set_db_page;
- __u32 arm_db_index;
- __u32 set_db_index;
-};
-
-struct mthca_create_cq_resp {
- __u32 cqn;
- __u32 reserved;
-};
-
-struct mthca_resize_cq {
- __u32 lkey;
- __u32 reserved;
-};
-
-struct mthca_create_srq {
- __u32 lkey;
- __u32 db_index;
- __u64 db_page;
-};
-
-struct mthca_create_srq_resp {
- __u32 srqn;
- __u32 reserved;
-};
-
-struct mthca_create_qp {
- __u32 lkey;
- __u32 reserved;
- __u64 sq_db_page;
- __u64 rq_db_page;
- __u32 sq_db_index;
- __u32 rq_db_index;
-};
-
-#endif /* MTHCA_USER_H */
--
2.13.6
Re: [PATCH] drm/radeon: adjust tested variable
Am 27.01.2018 um 15:28 schrieb Julia Lawall: Check the variable that was most recently initialized. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @@ expression x, y, f, g, e, m; statement S1,S2,S3,S4; @@ x = f(...); if (\(<+...x...+>\&e\)) S1 else S2 ( x = g(...); | m = g(...,&x,...); | y = g(...); *if (e) S3 else S4 ) // Signed-off-by: Julia Lawall Good catch, added my rb and pushed it into our to-be-upstreamed branch. Thanks, Christian. --- drivers/gpu/drm/radeon/radeon_uvd.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c b/drivers/gpu/drm/radeon/radeon_uvd.c index d34d1cf..95f4db7 100644 --- a/drivers/gpu/drm/radeon/radeon_uvd.c +++ b/drivers/gpu/drm/radeon/radeon_uvd.c @@ -995,7 +995,7 @@ int radeon_uvd_calc_upll_dividers(struct radeon_device *rdev, /* calc dclk divider with current vco freq */ dclk_div = radeon_uvd_calc_upll_post_div(vco_freq, dclk, pd_min, pd_even); - if (vclk_div > pd_max) + if (dclk_div > pd_max) break; /* vco is too big, it has to stop */ /* calc score with current vco freq */
Re: [PATCH 04/16] iio: adc: sun4i-gpadc-iio: rework: sampling start/end code readout reg
On 28.01.2018 09:43, Jonathan Cameron wrote:
On Fri, 26 Jan 2018 16:19:29 +0100
Philipp Rossak wrote:
For adding newer sensor some basic rework of the code is necessary.
This commit reworks the code and allows the sampling start/end code and
the position of value readout register to be altered. Later the start/end
functions will be used to configure the ths and start/stop the
sampling.
Signed-off-by: Icenowy Zheng
Signed-off-by: Philipp Rossak
Hmm. It almost always turns out to be a bad idea to assume a particular
set of registers will be consistent across a hardware family. Usual convention
is just to prefix them with the first supported device and use them across
the variants where they are correct. I.e. don't use wild cards or generic
names as they often end up implying a wider range of applicability than
we want.
The new THS sensors seems to use the same THS ip core, only configured
with different amount of sensors. So for H3, A83T, H5, A80 and A64 the
registers are all the same.
I think the big question is, do we want to have a few very big patches.
Or more small patches with code that is used in later patches.
A few other comments inline. Reworking code to make it ready for later
patches is fine, but this also adds a lot of new code which isn't used until
much later in the series. Move it there...
please see comments below.
---
drivers/iio/adc/sun4i-gpadc-iio.c | 87 +++
include/linux/mfd/sun4i-gpadc.h | 19 +++--
2 files changed, 94 insertions(+), 12 deletions(-)
diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
b/drivers/iio/adc/sun4i-gpadc-iio.c
index 03804ff9c006..363936b37c5a 100644
--- a/drivers/iio/adc/sun4i-gpadc-iio.c
+++ b/drivers/iio/adc/sun4i-gpadc-iio.c
@@ -49,6 +49,18 @@ static unsigned int sun6i_gpadc_chan_select(unsigned int
chan)
return SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(chan);
}
+struct sun4i_gpadc_iio;
+
+/*
+ * Prototypes for these functions, which enable these functions to be
+ * referenced in gpadc_data structures.
+ */
+static int sun4i_gpadc_sample_start(struct sun4i_gpadc_iio *info);
+static int sun4i_gpadc_sample_end(struct sun4i_gpadc_iio *info);
+
+static int sunxi_ths_sample_start(struct sun4i_gpadc_iio *info);
Superficially this appears to be introduced but not used... Patch 9
is first to use it I think? Introduce it then rather than here.
You are right, this function is used first in Patch 9. In an very early
version, I had this together with Patch 9. But then I had the feeling
that everything got too messy... Right now this is a very big patch
series and I wanted to have a clear structure in it and easy to review.
If I would rework this it will end up in squashing, Patch 4, Parts of
Patch 7, Patch 8 and Patch 9.
+static int sunxi_ths_sample_end(struct sun4i_gpadc_iio *info);
+
struct gpadc_data {
int temp_offset;
int temp_scale;
@@ -56,6 +68,13 @@ struct gpadc_data {
unsigned inttp_adc_select;
unsigned int(*adc_chan_select)(unsigned int chan);
unsigned intadc_chan_mask;
+ unsigned inttemp_data;
+ int (*sample_start)(struct sun4i_gpadc_iio *info);
+ int (*sample_end)(struct sun4i_gpadc_iio *info);
+ u32 ctrl0_map;
+ u32 ctrl2_map;
+ u32 sensor_en_map;
+ u32 filter_map;
};
static const struct gpadc_data sun4i_gpadc_data = {
@@ -65,6 +84,9 @@ static const struct gpadc_data sun4i_gpadc_data = {
.tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
.adc_chan_select = &sun4i_gpadc_chan_select,
.adc_chan_mask = SUN4I_GPADC_CTRL1_ADC_CHAN_MASK,
+ .temp_data = SUN4I_GPADC_TEMP_DATA,
+ .sample_start = sun4i_gpadc_sample_start,
+ .sample_end = sun4i_gpadc_sample_end,
};
static const struct gpadc_data sun5i_gpadc_data = {
@@ -74,6 +96,9 @@ static const struct gpadc_data sun5i_gpadc_data = {
.tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
.adc_chan_select = &sun4i_gpadc_chan_select,
.adc_chan_mask = SUN4I_GPADC_CTRL1_ADC_CHAN_MASK,
+ .temp_data = SUN4I_GPADC_TEMP_DATA,
+ .sample_start = sun4i_gpadc_sample_start,
+ .sample_end = sun4i_gpadc_sample_end,
};
static const struct gpadc_data sun6i_gpadc_data = {
@@ -83,12 +108,18 @@ static const struct gpadc_data sun6i_gpadc_data = {
.tp_adc_select = SUN6I_GPADC_CTRL1_TP_ADC_SELECT,
.adc_chan_select = &sun6i_gpadc_chan_select,
.adc_chan_mask = SUN6I_GPADC_CTRL1_ADC_CHAN_MASK,
+ .temp_data = SUN4I_GPADC_TEMP_DATA,
+ .sample_start = sun4i_gpadc_sample_start,
+ .sample_end = sun4i_gpadc_sample_end,
};
static const struct gpadc_data sun8i_a33_gpadc_data = {
.temp_offset = -1662,
.temp_scale = 162,
.tp_mode_en = SUN8I_A33_GPADC_CTRL1_CHOP_TEMP_EN,
+ .temp_data = SUN
Re: [PATCH 04/16] iio: adc: sun4i-gpadc-iio: rework: sampling start/end code readout reg
于 2018年1月28日 GMT+08:00 下午9:34:17, Philipp Rossak 写到:
>
>
>On 28.01.2018 09:43, Jonathan Cameron wrote:
>> On Fri, 26 Jan 2018 16:19:29 +0100
>> Philipp Rossak wrote:
>>
>>> For adding newer sensor some basic rework of the code is necessary.
>>>
>>> This commit reworks the code and allows the sampling start/end code
>and
>>> the position of value readout register to be altered. Later the
>start/end
>>> functions will be used to configure the ths and start/stop the
>>> sampling.
>>>
>>> Signed-off-by: Icenowy Zheng
>>> Signed-off-by: Philipp Rossak
>> Hmm. It almost always turns out to be a bad idea to assume a
>particular
>> set of registers will be consistent across a hardware family. Usual
>convention
>> is just to prefix them with the first supported device and use them
>across
>> the variants where they are correct. I.e. don't use wild cards or
>generic
>> names as they often end up implying a wider range of applicability
>than
>> we want.
>>
>
>The new THS sensors seems to use the same THS ip core, only configured
>with different amount of sensors. So for H3, A83T, H5, A80 and A64 the
>registers are all the same.
>
>I think the big question is, do we want to have a few very big patches.
>
>Or more small patches with code that is used in later patches.
Allwinner H6 has changed the THS core again.
Please consider this :-)
>
>> A few other comments inline. Reworking code to make it ready for
>later
>> patches is fine, but this also adds a lot of new code which isn't
>used until
>> much later in the series. Move it there...
>
>please see comments below.
>
>>> ---
>>> drivers/iio/adc/sun4i-gpadc-iio.c | 87
>+++
>>> include/linux/mfd/sun4i-gpadc.h | 19 +++--
>>> 2 files changed, 94 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
>b/drivers/iio/adc/sun4i-gpadc-iio.c
>>> index 03804ff9c006..363936b37c5a 100644
>>> --- a/drivers/iio/adc/sun4i-gpadc-iio.c
>>> +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
>>> @@ -49,6 +49,18 @@ static unsigned int
>sun6i_gpadc_chan_select(unsigned int chan)
>>> return SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(chan);
>>> }
>>>
>>> +struct sun4i_gpadc_iio;
>>> +
>>> +/*
>>> + * Prototypes for these functions, which enable these functions to
>be
>>> + * referenced in gpadc_data structures.
>>> + */
>>> +static int sun4i_gpadc_sample_start(struct sun4i_gpadc_iio *info);
>>> +static int sun4i_gpadc_sample_end(struct sun4i_gpadc_iio *info);
>>> +
>>> +static int sunxi_ths_sample_start(struct sun4i_gpadc_iio *info);
>>
>> Superficially this appears to be introduced but not used... Patch 9
>> is first to use it I think? Introduce it then rather than here.
>>
>
>You are right, this function is used first in Patch 9. In an very early
>
>version, I had this together with Patch 9. But then I had the feeling
>that everything got too messy... Right now this is a very big patch
>series and I wanted to have a clear structure in it and easy to review.
>
>If I would rework this it will end up in squashing, Patch 4, Parts of
>Patch 7, Patch 8 and Patch 9.
>
>>> +static int sunxi_ths_sample_end(struct sun4i_gpadc_iio *info);
>>> +
>>> struct gpadc_data {
>>> int temp_offset;
>>> int temp_scale;
>>> @@ -56,6 +68,13 @@ struct gpadc_data {
>>> unsigned inttp_adc_select;
>>> unsigned int(*adc_chan_select)(unsigned int chan);
>>> unsigned intadc_chan_mask;
>>> + unsigned inttemp_data;
>>> + int (*sample_start)(struct sun4i_gpadc_iio *info);
>>> + int (*sample_end)(struct sun4i_gpadc_iio *info);
>>> + u32 ctrl0_map;
>>> + u32 ctrl2_map;
>>> + u32 sensor_en_map;
>>> + u32 filter_map;
>>> };
>>>
>>> static const struct gpadc_data sun4i_gpadc_data = {
>>> @@ -65,6 +84,9 @@ static const struct gpadc_data sun4i_gpadc_data =
>{
>>> .tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
>>> .adc_chan_select = &sun4i_gpadc_chan_select,
>>> .adc_chan_mask = SUN4I_GPADC_CTRL1_ADC_CHAN_MASK,
>>> + .temp_data = SUN4I_GPADC_TEMP_DATA,
>>> + .sample_start = sun4i_gpadc_sample_start,
>>> + .sample_end = sun4i_gpadc_sample_end,
>>> };
>>>
>>> static const struct gpadc_data sun5i_gpadc_data = {
>>> @@ -74,6 +96,9 @@ static const struct gpadc_data sun5i_gpadc_data =
>{
>>> .tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
>>> .adc_chan_select = &sun4i_gpadc_chan_select,
>>> .adc_chan_mask = SUN4I_GPADC_CTRL1_ADC_CHAN_MASK,
>>> + .temp_data = SUN4I_GPADC_TEMP_DATA,
>>> + .sample_start = sun4i_gpadc_sample_start,
>>> + .sample_end = sun4i_gpadc_sample_end,
>>> };
>>>
>>> static const struct gpadc_data sun6i_gpadc_data = {
>>> @@ -83,12 +108,18 @@ static const struct gpadc_data sun6i_gpadc_data
>= {
>>> .tp_adc_select = SUN6I_GPADC_CTRL1_TP_ADC_SELECT,
>>> .adc_chan_select = &sun6i_gpadc_chan_select,
>>> .adc_chan_ma
Re: [PATCH 07/16] iio: adc: sun4i-gpadc-iio: rework: support nvmem calibration data
On 28.01.2018 10:02, Jonathan Cameron wrote:
On Fri, 26 Jan 2018 16:19:32 +0100
Philipp Rossak wrote:
This patch reworks the driver to support nvmem calibration cells.
The driver checks if the nvmem calibration is supported and reads out
the nvmem. At the beginning of the startup process the calibration data
is written to the related registers.
Signed-off-by: Philipp Rossak
A few minor suggestions inline.
Jonathan
---
drivers/iio/adc/sun4i-gpadc-iio.c | 52 +++
include/linux/mfd/sun4i-gpadc.h | 2 ++
2 files changed, 54 insertions(+)
diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
b/drivers/iio/adc/sun4i-gpadc-iio.c
index bff06f2798e8..7b12666cdd9e 100644
--- a/drivers/iio/adc/sun4i-gpadc-iio.c
+++ b/drivers/iio/adc/sun4i-gpadc-iio.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -81,6 +82,7 @@ struct gpadc_data {
boolhas_bus_rst;
boolhas_mod_clk;
int sensor_count;
+ boolsupports_nvmem;
};
static const struct gpadc_data sun4i_gpadc_data = {
@@ -94,6 +96,7 @@ static const struct gpadc_data sun4i_gpadc_data = {
.sample_start = sun4i_gpadc_sample_start,
.sample_end = sun4i_gpadc_sample_end,
.sensor_count = 1,
+ .supports_nvmem = false,
};
static const struct gpadc_data sun5i_gpadc_data = {
@@ -107,6 +110,7 @@ static const struct gpadc_data sun5i_gpadc_data = {
.sample_start = sun4i_gpadc_sample_start,
.sample_end = sun4i_gpadc_sample_end,
.sensor_count = 1,
+ .supports_nvmem = false,
};
static const struct gpadc_data sun6i_gpadc_data = {
@@ -120,6 +124,7 @@ static const struct gpadc_data sun6i_gpadc_data = {
.sample_start = sun4i_gpadc_sample_start,
.sample_end = sun4i_gpadc_sample_end,
.sensor_count = 1,
+ .supports_nvmem = false,
};
static const struct gpadc_data sun8i_a33_gpadc_data = {
@@ -130,6 +135,7 @@ static const struct gpadc_data sun8i_a33_gpadc_data = {
.sample_start = sun4i_gpadc_sample_start,
.sample_end = sun4i_gpadc_sample_end,
.sensor_count = 1,
+ .supports_nvmem = false,
};
struct sun4i_gpadc_iio {
@@ -148,6 +154,8 @@ struct sun4i_gpadc_iio {
struct clk *mod_clk;
struct reset_control*reset;
int sensor_id;
+ u32 calibration_data[2];
+ boolhas_calibration_data[2];
/* prevents concurrent reads of temperature and ADC */
struct mutexmutex;
struct thermal_zone_device *tzd;
@@ -459,6 +467,17 @@ static int sun4i_gpadc_runtime_suspend(struct device *dev)
return info->data->sample_end(info);
}
+static void sunxi_calibrate(struct sun4i_gpadc_iio *info)
+{
+ if (info->has_calibration_data[0])
+ regmap_write(info->regmap, SUNXI_THS_CDATA_0_1,
+ info->calibration_data[0]);
+
+ if (info->has_calibration_data[1])
+ regmap_write(info->regmap, SUNXI_THS_CDATA_2_3,
+ info->calibration_data[1]);
+}
+
static int sun4i_gpadc_sample_start(struct sun4i_gpadc_iio *info)
{
/* clkin = 6MHz */
@@ -481,6 +500,7 @@ static int sun4i_gpadc_sample_start(struct sun4i_gpadc_iio
*info)
static int sunxi_ths_sample_start(struct sun4i_gpadc_iio *info)
{
u32 value;
+ sunxi_calibrate(info);
if (info->data->ctrl0_map)
regmap_write(info->regmap, SUNXI_THS_CTRL0,
@@ -602,6 +622,9 @@ static int sun4i_gpadc_probe_dt(struct platform_device
*pdev,
struct resource *mem;
void __iomem *base;
int ret;
+ struct nvmem_cell *cell;
+ ssize_t cell_size;
+ u64 *cell_data;
info->data = of_device_get_match_data(&pdev->dev);
if (!info->data)
@@ -616,6 +639,35 @@ static int sun4i_gpadc_probe_dt(struct platform_device
*pdev,
if (IS_ERR(base))
return PTR_ERR(base);
+ info->has_calibration_data[0] = false;
+ info->has_calibration_data[1] = false;
+
+ if (!info->data->supports_nvmem)
+ goto no_nvmem;
+
+ cell = devm_nvmem_cell_get(&pdev->dev, "calibration");
+ if (IS_ERR(cell)) {
+ if (PTR_ERR(cell) == -EPROBE_DEFER)
+ return PTR_ERR(cell);
Use a goto here to no_nvmem.
Then you can drop the below else to make things more readable.
+ } else {
+ cell_data = (u64 *)nvmem_cell_read(cell, &cell_size);
+ devm_nvmem_cell_put(&pdev->dev, cell);
I'm really not keen on use of devm for things we are intending
to drop almost immediately. Just use the non managed versions
and clean up properly in the error paths (if there are any
where it is needed - which there aren't that I can
Re: [PATCH 08/16] iio: adc: sun4i-gpadc-iio: rework: add interrupt support
On 28.01.2018 10:06, Jonathan Cameron wrote:
On Fri, 26 Jan 2018 16:19:33 +0100
Philipp Rossak wrote:
This patch rewors the driver to support interrupts for the thermal part
of the sensor.
This is only available for the newer sensor (currently H3 and A83T).
The interrupt will be trigerd on data available and triggers the update
for the thermal sensors. All newer sensors have different amount of
sensors and different interrupts for each device the reset of the
interrupts need to be done different
For the newer sensors is the autosuspend disabled.
Signed-off-by: Philipp Rossak
Really minor point inline, otherwise this looks fine to me.
Acked-by: Jonathan Cameron
---
drivers/iio/adc/sun4i-gpadc-iio.c | 68 +++
include/linux/mfd/sun4i-gpadc.h | 33 +++
2 files changed, 95 insertions(+), 6 deletions(-)
diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
b/drivers/iio/adc/sun4i-gpadc-iio.c
index 7b12666cdd9e..77e07f042730 100644
--- a/drivers/iio/adc/sun4i-gpadc-iio.c
+++ b/drivers/iio/adc/sun4i-gpadc-iio.c
@@ -78,11 +78,14 @@ struct gpadc_data {
u32 ctrl2_map;
u32 sensor_en_map;
u32 filter_map;
+ u32 irq_clear_map;
+ u32 irq_control_map;
boolhas_bus_clk;
boolhas_bus_rst;
boolhas_mod_clk;
int sensor_count;
boolsupports_nvmem;
+ boolsupport_irq;
};
static const struct gpadc_data sun4i_gpadc_data = {
@@ -97,6 +100,7 @@ static const struct gpadc_data sun4i_gpadc_data = {
.sample_end = sun4i_gpadc_sample_end,
.sensor_count = 1,
.supports_nvmem = false,
+ .support_irq = false,
};
static const struct gpadc_data sun5i_gpadc_data = {
@@ -111,6 +115,7 @@ static const struct gpadc_data sun5i_gpadc_data = {
.sample_end = sun4i_gpadc_sample_end,
.sensor_count = 1,
.supports_nvmem = false,
+ .support_irq = false,
};
static const struct gpadc_data sun6i_gpadc_data = {
@@ -125,6 +130,7 @@ static const struct gpadc_data sun6i_gpadc_data = {
.sample_end = sun4i_gpadc_sample_end,
.sensor_count = 1,
.supports_nvmem = false,
+ .support_irq = false,
};
static const struct gpadc_data sun8i_a33_gpadc_data = {
@@ -136,6 +142,7 @@ static const struct gpadc_data sun8i_a33_gpadc_data = {
.sample_end = sun4i_gpadc_sample_end,
.sensor_count = 1,
.supports_nvmem = false,
+ .support_irq = false,
};
struct sun4i_gpadc_iio {
@@ -339,6 +346,11 @@ static int sun4i_gpadc_temp_read(struct iio_dev
*indio_dev, int *val,
return 0;
}
+ if (info->data->support_irq) {
+ regmap_read(info->regmap, info->data->temp_data[sensor], val);
+ return 0;
+ }
+
return sun4i_gpadc_read(indio_dev, 0, val, info->temp_data_irq);
}
@@ -436,6 +448,17 @@ static irqreturn_t sun4i_gpadc_fifo_data_irq_handler(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static irqreturn_t sunxi_irq_thread(int irq, void *data)
+{
+ struct sun4i_gpadc_iio *info = data;
+
+ regmap_write(info->regmap, SUNXI_THS_STAT, info->data->irq_clear_map);
+
+ thermal_zone_device_update(info->tzd, THERMAL_EVENT_TEMP_SAMPLE);
+
+ return IRQ_HANDLED;
+}
+
static int sun4i_gpadc_sample_end(struct sun4i_gpadc_iio *info)
{
/* Disable the ADC on IP */
@@ -448,6 +471,8 @@ static int sun4i_gpadc_sample_end(struct sun4i_gpadc_iio
*info)
static int sunxi_ths_sample_end(struct sun4i_gpadc_iio *info)
{
+ /* Disable ths interrupt*/
Space before */
^^ Ok, I will rework that.
+ regmap_write(info->regmap, SUNXI_THS_INTC, 0x0);
/* Disable temperature sensor */
regmap_write(info->regmap, SUNXI_THS_CTRL2, 0x0);
@@ -509,9 +534,15 @@ static int sunxi_ths_sample_start(struct sun4i_gpadc_iio *info)
regmap_write(info->regmap, SUNXI_THS_CTRL2,
info->data->ctrl2_map);
+ regmap_write(info->regmap, SUNXI_THS_STAT,
+ info->data->irq_clear_map);
+
regmap_write(info->regmap, SUNXI_THS_FILTER,
info->data->filter_map);
+ regmap_write(info->regmap, SUNXI_THS_INTC,
+ info->data->irq_control_map);
+
regmap_read(info->regmap, SUNXI_THS_CTRL2, &value);
regmap_write(info->regmap, SUNXI_THS_CTRL2,
@@ -625,12 +656,29 @@ static int sun4i_gpadc_probe_dt(struct platform_device
*pdev,
struct nvmem_cell *cell;
ssize_t cell_size;
u64 *cell_data;
+ int irq;
info->data = of_device_get_match_data(&pdev->dev);
if (!info->data)
return -ENODEV;
- info->no_irq = true;
+ if (info->data->support_irq) {
+ /* only the new versions of ths support right now irqs */
+
Re: [PATCH 07/16] iio: adc: sun4i-gpadc-iio: rework: support nvmem calibration data
于 2018年1月28日 GMT+08:00 下午9:46:18, Philipp Rossak 写到:
>
>
>On 28.01.2018 10:02, Jonathan Cameron wrote:
>> On Fri, 26 Jan 2018 16:19:32 +0100
>> Philipp Rossak wrote:
>>
>>> This patch reworks the driver to support nvmem calibration cells.
>>> The driver checks if the nvmem calibration is supported and reads
>out
>>> the nvmem. At the beginning of the startup process the calibration
>data
>>> is written to the related registers.
>>>
>>> Signed-off-by: Philipp Rossak
>>
>> A few minor suggestions inline.
>>
>> Jonathan
>>
>>> ---
>>> drivers/iio/adc/sun4i-gpadc-iio.c | 52
>+++
>>> include/linux/mfd/sun4i-gpadc.h | 2 ++
>>> 2 files changed, 54 insertions(+)
>>>
>>> diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
>b/drivers/iio/adc/sun4i-gpadc-iio.c
>>> index bff06f2798e8..7b12666cdd9e 100644
>>> --- a/drivers/iio/adc/sun4i-gpadc-iio.c
>>> +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
>>> @@ -27,6 +27,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -81,6 +82,7 @@ struct gpadc_data {
>>> boolhas_bus_rst;
>>> boolhas_mod_clk;
>>> int sensor_count;
>>> + boolsupports_nvmem;
>>> };
>>>
>>> static const struct gpadc_data sun4i_gpadc_data = {
>>> @@ -94,6 +96,7 @@ static const struct gpadc_data sun4i_gpadc_data =
>{
>>> .sample_start = sun4i_gpadc_sample_start,
>>> .sample_end = sun4i_gpadc_sample_end,
>>> .sensor_count = 1,
>>> + .supports_nvmem = false,
>>> };
>>>
>>> static const struct gpadc_data sun5i_gpadc_data = {
>>> @@ -107,6 +110,7 @@ static const struct gpadc_data sun5i_gpadc_data
>= {
>>> .sample_start = sun4i_gpadc_sample_start,
>>> .sample_end = sun4i_gpadc_sample_end,
>>> .sensor_count = 1,
>>> + .supports_nvmem = false,
>>> };
>>>
>>> static const struct gpadc_data sun6i_gpadc_data = {
>>> @@ -120,6 +124,7 @@ static const struct gpadc_data sun6i_gpadc_data
>= {
>>> .sample_start = sun4i_gpadc_sample_start,
>>> .sample_end = sun4i_gpadc_sample_end,
>>> .sensor_count = 1,
>>> + .supports_nvmem = false,
>>> };
>>>
>>> static const struct gpadc_data sun8i_a33_gpadc_data = {
>>> @@ -130,6 +135,7 @@ static const struct gpadc_data
>sun8i_a33_gpadc_data = {
>>> .sample_start = sun4i_gpadc_sample_start,
>>> .sample_end = sun4i_gpadc_sample_end,
>>> .sensor_count = 1,
>>> + .supports_nvmem = false,
BTW A33 claims to support calibration data according to the manual.
>>> };
>>>
>>> struct sun4i_gpadc_iio {
>>> @@ -148,6 +154,8 @@ struct sun4i_gpadc_iio {
>>> struct clk *mod_clk;
>>> struct reset_control*reset;
>>> int sensor_id;
>>> + u32 calibration_data[2];
>>> + boolhas_calibration_data[2];
>>> /* prevents concurrent reads of temperature and ADC */
>>> struct mutexmutex;
>>> struct thermal_zone_device *tzd;
>>> @@ -459,6 +467,17 @@ static int sun4i_gpadc_runtime_suspend(struct
>device *dev)
>>> return info->data->sample_end(info);
>>> }
>>>
>>> +static void sunxi_calibrate(struct sun4i_gpadc_iio *info)
>>> +{
>>> + if (info->has_calibration_data[0])
>>> + regmap_write(info->regmap, SUNXI_THS_CDATA_0_1,
>>> + info->calibration_data[0]);
>>> +
>>> + if (info->has_calibration_data[1])
>>> + regmap_write(info->regmap, SUNXI_THS_CDATA_2_3,
>>> + info->calibration_data[1]);
>>> +}
>>> +
>>> static int sun4i_gpadc_sample_start(struct sun4i_gpadc_iio *info)
>>> {
>>> /* clkin = 6MHz */
>>> @@ -481,6 +500,7 @@ static int sun4i_gpadc_sample_start(struct
>sun4i_gpadc_iio *info)
>>> static int sunxi_ths_sample_start(struct sun4i_gpadc_iio *info)
>>> {
>>> u32 value;
>>> + sunxi_calibrate(info);
>>>
>>> if (info->data->ctrl0_map)
>>> regmap_write(info->regmap, SUNXI_THS_CTRL0,
>>> @@ -602,6 +622,9 @@ static int sun4i_gpadc_probe_dt(struct
>platform_device *pdev,
>>> struct resource *mem;
>>> void __iomem *base;
>>> int ret;
>>> + struct nvmem_cell *cell;
>>> + ssize_t cell_size;
>>> + u64 *cell_data;
>>>
>>> info->data = of_device_get_match_data(&pdev->dev);
>>> if (!info->data)
>>> @@ -616,6 +639,35 @@ static int sun4i_gpadc_probe_dt(struct
>platform_device *pdev,
>>> if (IS_ERR(base))
>>> return PTR_ERR(base);
>>>
>>> + info->has_calibration_data[0] = false;
>>> + info->has_calibration_data[1] = false;
>>> +
>>> + if (!info->data->supports_nvmem)
>>> + goto no_nvmem;
>>> +
>>> + cell = devm_nvmem_cell_get(&pdev->dev, "calibration");
>>> + if (IS_ERR(cell)) {
>>> + if (PTR_ERR(cell) == -EPROBE_DEFER)
>>> + return PTR_ERR(cell);
>> Use a goto here to no_nvmem.
>>
>> Then you can drop
[PATCH 0/6] MAINTAINERS: Update initial defective F: patterns
Fix the first few missing or defective patterns shown by ./scripts/get_maintainer.pl --self-test=patterns Joe Perches (6): MAINTAINERS: Remove ANDROID ION pattern MAINTAINERS: Remove ARM/CLKDEV SUPPORT file pattern MAINTAINERS: Update Cortina/Gemini patterns MAINTAINERS: Update "ARM/OXNAS platform support" patterns MAINTAINERS: Update various PALM patterns MAINTAINERS: Update ARM/QUALCOMM SUPPORT patterns MAINTAINERS | 21 +++-- 1 file changed, 7 insertions(+), 14 deletions(-) -- 2.15.0
[PATCH 6/6] MAINTAINERS: Update ARM/QUALCOMM SUPPORT patterns
commit 321737416c72d ("tty: serial: msm: Move header file into driver")
removed the .h file, update the patterns.
Signed-off-by: Joe Perches
cc: Stephen Boyd
cc: Andy Gross
cc: David Brown
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3efa83cfe73d..f95c79678fd8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1786,7 +1786,6 @@ F:drivers/clk/qcom/
F: drivers/dma/qcom/
F: drivers/soc/qcom/
F: drivers/spi/spi-qup.c
-F: drivers/tty/serial/msm_serial.h
F: drivers/tty/serial/msm_serial.c
F: drivers/*/pm8???-*
F: drivers/mfd/ssbi.c
--
2.15.0
[PATCH 5/6] MAINTAINERS: Update various PALM patterns
commit 4c25c5d2985c ("ARM: pxa: make more mach/*.h files local")
moved the files around, update the patterns.
Signed-off-by: Joe Perches
cc: Arnd Bergmann
cc: Marek Vasut
cc: Tomas Cech
---
MAINTAINERS | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index decb2be59e54..3efa83cfe73d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1736,8 +1736,7 @@ M:Tomas Cech
L: linux-arm-ker...@lists.infradead.org
W: http://hackndev.com
S: Maintained
-F: arch/arm/mach-pxa/include/mach/palmtreo.h
-F: arch/arm/mach-pxa/palmtreo.c
+F: arch/arm/mach-pxa/palmtreo.*
ARM/PALMTX,PALMT5,PALMLD,PALMTE2,PALMTC SUPPORT
M: Marek Vasut
@@ -1746,12 +1745,10 @@ W: http://hackndev.com
S: Maintained
F: arch/arm/mach-pxa/include/mach/palmtx.h
F: arch/arm/mach-pxa/palmtx.c
-F: arch/arm/mach-pxa/include/mach/palmt5.h
-F: arch/arm/mach-pxa/palmt5.c
+F: arch/arm/mach-pxa/palmt5.*
F: arch/arm/mach-pxa/include/mach/palmld.h
F: arch/arm/mach-pxa/palmld.c
-F: arch/arm/mach-pxa/include/mach/palmte2.h
-F: arch/arm/mach-pxa/palmte2.c
+F: arch/arm/mach-pxa/palmte2.*
F: arch/arm/mach-pxa/include/mach/palmtc.h
F: arch/arm/mach-pxa/palmtc.c
@@ -1760,8 +1757,7 @@ M:Sergey Lapin
L: linux-arm-ker...@lists.infradead.org
W: http://hackndev.com
S: Maintained
-F: arch/arm/mach-pxa/include/mach/palmz72.h
-F: arch/arm/mach-pxa/palmz72.c
+F: arch/arm/mach-pxa/palmz72.*
ARM/PLEB SUPPORT
M: Peter Chubb
--
2.15.0
[PATCH 3/6] MAINTAINERS: Update Cortina/Gemini patterns
commit 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet")
added invalid patterns. Fix it.
Signed-off-by: Joe Perches
cc: Linus Walleij
cc: Hans Ulli Kroll
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index e92ab5e64ddf..58300e66dae6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1349,7 +1349,7 @@ F:
Documentation/devicetree/bindings/pinctrl/cortina,gemini-pinctrl.txt
F: Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt
F: Documentation/devicetree/bindings/rtc/faraday,ftrtc010.txt
F: arch/arm/mach-gemini/
-F: drivers/net/ethernet/cortina/gemini/*
+F: drivers/net/ethernet/cortina/
F: drivers/pinctrl/pinctrl-gemini.c
F: drivers/rtc/rtc-ftrtc010.c
--
2.15.0
[PATCH 4/6] MAINTAINERS: Update "ARM/OXNAS platform support" patterns
commit 9e6c62b05c1b ("ARM: dts: rename oxnas dts files") renamed
the files, update the patterns.
Signed-off-by: Joe Perches
cc: Daniel Golle
cc: Arnd Bergmann
cc: Neil Armstrong
---
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 58300e66dae6..decb2be59e54 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1727,8 +1727,8 @@ L:linux-ox...@lists.tuxfamily.org (moderated for
non-subscribers)
S: Maintained
F: arch/arm/mach-oxnas/
F: arch/arm/boot/dts/ox8*.dtsi
-F: arch/arm/boot/dts/wd-mbwe.dts
-F: arch/arm/boot/dts/cloudengines-pogoplug-series-3.dts
+F: arch/arm/boot/dts/ox810se-wd-mbwe.dts
+F: arch/arm/boot/dts/ox820-cloudengines-pogoplug-series-3.dts
N: oxnas
ARM/PALM TREO SUPPORT
--
2.15.0
[PATCH 2/6] MAINTAINERS: Remove ARM/CLKDEV SUPPORT file pattern
commit 34d2f4d3a4d6 ("ARM: Use generic clkdev.h header") removed
the file, remove the pattern.
Signed-off-by: Joe Perches
cc: Russell King
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 89c2e7752eab..e92ab5e64ddf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1299,7 +1299,6 @@ M:Russell King
L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
S: Maintained
T: git git://git.armlinux.org.uk/~rmk/linux-arm.git clkdev
-F: arch/arm/include/asm/clkdev.h
F: drivers/clk/clkdev.c
ARM/COMPULAB CM-X270/EM-X270 and CM-X300 MACHINE SUPPORT
--
2.15.0
[PATCH 1/6] MAINTAINERS: Remove ANDROID ION pattern
File drivers/staging/android/uapi/ion_test.h was removed by
commit 9828282e33a0 ("staging: android: ion: Remove old platform support")
Remove the pattern.
Signed-off-by: Joe Perches
cc: Laura Abbott
cc: Sumit Semwal
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index c90687ec8fc6..89c2e7752eab 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -895,7 +895,6 @@ L: de...@driverdev.osuosl.org
S: Supported
F: drivers/staging/android/ion
F: drivers/staging/android/uapi/ion.h
-F: drivers/staging/android/uapi/ion_test.h
AOA (Apple Onboard Audio) ALSA DRIVER
M: Johannes Berg
--
2.15.0
Re: [PATCH 1/6] MAINTAINERS: Remove ANDROID ION pattern
On 01/28/2018 05:56 AM, Joe Perches wrote:
File drivers/staging/android/uapi/ion_test.h was removed by
commit 9828282e33a0 ("staging: android: ion: Remove old platform support")
Remove the pattern.
Acked-by: Laura Abbott
Signed-off-by: Joe Perches
cc: Laura Abbott
cc: Sumit Semwal
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index c90687ec8fc6..89c2e7752eab 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -895,7 +895,6 @@ L: de...@driverdev.osuosl.org
S:Supported
F:drivers/staging/android/ion
F:drivers/staging/android/uapi/ion.h
-F: drivers/staging/android/uapi/ion_test.h
AOA (Apple Onboard Audio) ALSA DRIVER
M:Johannes Berg
Re: [PATCH 06/16] iio: adc: sun4i-gpadc-iio: rework: support multible sensors
On 28.01.2018 10:08, Jonathan Cameron wrote:
On Fri, 26 Jan 2018 16:19:31 +0100
Philipp Rossak wrote:
multible -> multiple
^^ Ok, I will fix that.
For adding newer sensor some basic rework of the code is necessary.
This patch reworks the driver to be able to handle more than one
thermal sensor. Newer SoC like the A80 have 4 thermal sensors.
Because of this the maximal sensor count value was set to 4.
The sensor_id value is set during sensor registration and is for each
registered sensor indiviual. This makes it able to differntiate the
sensors when the value is read from the register.
Signed-off-by: Philipp Rossak
Question inline about why you aren't exposing the additional temperature
sensors as IIO channels?
Fine to not do so I suppose, but needs justifying.
^^ Ok, I will rework the commit mesage. Detailed explanation see below.
Jonathan
---
drivers/iio/adc/sun4i-gpadc-iio.c | 36 +++-
include/linux/mfd/sun4i-gpadc.h | 6 ++
2 files changed, 29 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
b/drivers/iio/adc/sun4i-gpadc-iio.c
index 1a80744bd472..bff06f2798e8 100644
--- a/drivers/iio/adc/sun4i-gpadc-iio.c
+++ b/drivers/iio/adc/sun4i-gpadc-iio.c
@@ -70,7 +70,7 @@ struct gpadc_data {
unsigned inttp_adc_select;
unsigned int(*adc_chan_select)(unsigned int chan);
unsigned intadc_chan_mask;
- unsigned inttemp_data;
+ unsigned inttemp_data[MAX_SENSOR_COUNT];
int (*sample_start)(struct sun4i_gpadc_iio *info);
int (*sample_end)(struct sun4i_gpadc_iio *info);
u32 ctrl0_map;
@@ -80,6 +80,7 @@ struct gpadc_data {
boolhas_bus_clk;
boolhas_bus_rst;
boolhas_mod_clk;
+ int sensor_count;
};
static const struct gpadc_data sun4i_gpadc_data = {
@@ -89,9 +90,10 @@ static const struct gpadc_data sun4i_gpadc_data = {
.tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
.adc_chan_select = &sun4i_gpadc_chan_select,
.adc_chan_mask = SUN4I_GPADC_CTRL1_ADC_CHAN_MASK,
- .temp_data = SUN4I_GPADC_TEMP_DATA,
+ .temp_data = {SUN4I_GPADC_TEMP_DATA, 0, 0, 0},
.sample_start = sun4i_gpadc_sample_start,
.sample_end = sun4i_gpadc_sample_end,
+ .sensor_count = 1,
};
static const struct gpadc_data sun5i_gpadc_data = {
@@ -101,9 +103,10 @@ static const struct gpadc_data sun5i_gpadc_data = {
.tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
.adc_chan_select = &sun4i_gpadc_chan_select,
.adc_chan_mask = SUN4I_GPADC_CTRL1_ADC_CHAN_MASK,
- .temp_data = SUN4I_GPADC_TEMP_DATA,
+ .temp_data = {SUN4I_GPADC_TEMP_DATA, 0, 0, 0},
.sample_start = sun4i_gpadc_sample_start,
.sample_end = sun4i_gpadc_sample_end,
+ .sensor_count = 1,
};
static const struct gpadc_data sun6i_gpadc_data = {
@@ -113,18 +116,20 @@ static const struct gpadc_data sun6i_gpadc_data = {
.tp_adc_select = SUN6I_GPADC_CTRL1_TP_ADC_SELECT,
.adc_chan_select = &sun6i_gpadc_chan_select,
.adc_chan_mask = SUN6I_GPADC_CTRL1_ADC_CHAN_MASK,
- .temp_data = SUN4I_GPADC_TEMP_DATA,
+ .temp_data = {SUN4I_GPADC_TEMP_DATA, 0, 0, 0},
.sample_start = sun4i_gpadc_sample_start,
.sample_end = sun4i_gpadc_sample_end,
+ .sensor_count = 1,
};
static const struct gpadc_data sun8i_a33_gpadc_data = {
.temp_offset = -1662,
.temp_scale = 162,
.tp_mode_en = SUN8I_A33_GPADC_CTRL1_CHOP_TEMP_EN,
- .temp_data = SUN4I_GPADC_TEMP_DATA,
+ .temp_data = {SUN4I_GPADC_TEMP_DATA, 0, 0, 0},
[*] ^^
.sample_start = sun4i_gpadc_sample_start,
.sample_end = sun4i_gpadc_sample_end,
+ .sensor_count = 1,
};
struct sun4i_gpadc_iio {
@@ -142,6 +147,7 @@ struct sun4i_gpadc_iio {
struct clk *bus_clk;
struct clk *mod_clk;
struct reset_control*reset;
+ int sensor_id;
/* prevents concurrent reads of temperature and ADC */
struct mutexmutex;
struct thermal_zone_device *tzd;
@@ -309,14 +315,15 @@ static int sun4i_gpadc_adc_read(struct iio_dev
*indio_dev, int channel,
return sun4i_gpadc_read(indio_dev, channel, val, info->fifo_data_irq);
}
-static int sun4i_gpadc_temp_read(struct iio_dev *indio_dev, int *val)
+static int sun4i_gpadc_temp_read(struct iio_dev *indio_dev, int *val,
+ int sensor)
{
struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
if (info->no_irq) {
pm_runtime_get_sync(indio_dev->dev.parent);
- regmap_read(info->regmap, info->data->temp_data, val);
+ regmap_read(info->regmap, info->data->temp_data[sensor],
Re: [PATCH 04/16] iio: adc: sun4i-gpadc-iio: rework: sampling start/end code readout reg
On 28.01.2018 14:37, Icenowy Zheng wrote:
于 2018年1月28日 GMT+08:00 下午9:34:17, Philipp Rossak 写到:
On 28.01.2018 09:43, Jonathan Cameron wrote:
On Fri, 26 Jan 2018 16:19:29 +0100
Philipp Rossak wrote:
For adding newer sensor some basic rework of the code is necessary.
This commit reworks the code and allows the sampling start/end code
and
the position of value readout register to be altered. Later the
start/end
functions will be used to configure the ths and start/stop the
sampling.
Signed-off-by: Icenowy Zheng
Signed-off-by: Philipp Rossak
Hmm. It almost always turns out to be a bad idea to assume a
particular
set of registers will be consistent across a hardware family. Usual
convention
is just to prefix them with the first supported device and use them
across
the variants where they are correct. I.e. don't use wild cards or
generic
names as they often end up implying a wider range of applicability
than
we want.
The new THS sensors seems to use the same THS ip core, only configured
with different amount of sensors. So for H3, A83T, H5, A80 and A64 the
registers are all the same.
I think the big question is, do we want to have a few very big patches.
Or more small patches with code that is used in later patches.
Allwinner H6 has changed the THS core again.
Please consider this :-)
Yes you are right the core is different! But it is already considered it.
They dropped ACQ1, the IRQs control/status are split in separate
registers. I already have a good idea how to implement it, but I would
like to add this in the second part of this patch series (containing
support for A80, A64, and H5) or even later since the initial support
and the CCU driver is missing right now.
A few other comments inline. Reworking code to make it ready for
later
patches is fine, but this also adds a lot of new code which isn't
used until
much later in the series. Move it there...
please see comments below.
---
drivers/iio/adc/sun4i-gpadc-iio.c | 87
+++
include/linux/mfd/sun4i-gpadc.h | 19 +++--
2 files changed, 94 insertions(+), 12 deletions(-)
diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
b/drivers/iio/adc/sun4i-gpadc-iio.c
index 03804ff9c006..363936b37c5a 100644
--- a/drivers/iio/adc/sun4i-gpadc-iio.c
+++ b/drivers/iio/adc/sun4i-gpadc-iio.c
@@ -49,6 +49,18 @@ static unsigned int
sun6i_gpadc_chan_select(unsigned int chan)
return SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(chan);
}
+struct sun4i_gpadc_iio;
+
+/*
+ * Prototypes for these functions, which enable these functions to
be
+ * referenced in gpadc_data structures.
+ */
+static int sun4i_gpadc_sample_start(struct sun4i_gpadc_iio *info);
+static int sun4i_gpadc_sample_end(struct sun4i_gpadc_iio *info);
+
+static int sunxi_ths_sample_start(struct sun4i_gpadc_iio *info);
Superficially this appears to be introduced but not used... Patch 9
is first to use it I think? Introduce it then rather than here.
You are right, this function is used first in Patch 9. In an very early
version, I had this together with Patch 9. But then I had the feeling
that everything got too messy... Right now this is a very big patch
series and I wanted to have a clear structure in it and easy to review.
If I would rework this it will end up in squashing, Patch 4, Parts of
Patch 7, Patch 8 and Patch 9.
+static int sunxi_ths_sample_end(struct sun4i_gpadc_iio *info);
+
struct gpadc_data {
int temp_offset;
int temp_scale;
@@ -56,6 +68,13 @@ struct gpadc_data {
unsigned inttp_adc_select;
unsigned int(*adc_chan_select)(unsigned int chan);
unsigned intadc_chan_mask;
+ unsigned inttemp_data;
+ int (*sample_start)(struct sun4i_gpadc_iio *info);
+ int (*sample_end)(struct sun4i_gpadc_iio *info);
+ u32 ctrl0_map;
+ u32 ctrl2_map;
+ u32 sensor_en_map;
+ u32 filter_map;
};
static const struct gpadc_data sun4i_gpadc_data = {
@@ -65,6 +84,9 @@ static const struct gpadc_data sun4i_gpadc_data =
{
.tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
.adc_chan_select = &sun4i_gpadc_chan_select,
.adc_chan_mask = SUN4I_GPADC_CTRL1_ADC_CHAN_MASK,
+ .temp_data = SUN4I_GPADC_TEMP_DATA,
+ .sample_start = sun4i_gpadc_sample_start,
+ .sample_end = sun4i_gpadc_sample_end,
};
static const struct gpadc_data sun5i_gpadc_data = {
@@ -74,6 +96,9 @@ static const struct gpadc_data sun5i_gpadc_data =
{
.tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
.adc_chan_select = &sun4i_gpadc_chan_select,
.adc_chan_mask = SUN4I_GPADC_CTRL1_ADC_CHAN_MASK,
+ .temp_data = SUN4I_GPADC_TEMP_DATA,
+ .sample_start = sun4i_gpadc_sample_start,
+ .sample_end = sun4i_gpadc_sample_end,
};
static const struct gpadc_data
Re: [PATCH] Carrier detect ok, don't turn off negotiation
Denis Du writes: >>From the above code, I can get that only Carrier have some change, it > will restart the protocol by hdlc_proto_start(dev);and thus the timer, > the previous timer expired due to protocol fail. > > If carrier keep no change by if (hdlc->carrier == on) > goto carrier_exit; /* no change in DCD line level */It will do > nothing, not start any new protocol and thus the timer. Sorry about being late, just returned home and am trying to get all the backlogs under control. I remember the PPP standard is a bit cloudy about the possible issue, but the latter indeed exists (the PPP state machine was written directly to STD-51). There is related (more visible in practice, though we aren't affected) issue of "active" vs "passive" mode (hdlc_ppp.c is "active", and two "passives" wouldn't negotiate at all). Anyway the problem is real (though not very visible in practice, especially on relatively modern links rather than 300 or 1200 bps dialup connections) and should be fixed. Looking at the patch, my first impression is it makes the code differ from STD-51 a little bit. On the other hand, perhaps applying it as is and forgetting about the issue is the way to go. Ideally, I think the negotiation failure should end up (optionally, in addition to the current behavior) in some configurable sleep, then the negotiation should restart. If it's worth the effort at this point, I don't know. Perhaps I could look at this later, but no promises (this requires pulling on and setting up some legacy hardware). Anyway, since the patch is safe and can solve an existing problem: Acked-by: Krzysztof Halasa -- Krzysztof Halasa
Re: [PATCH 07/16] iio: adc: sun4i-gpadc-iio: rework: support nvmem calibration data
On 28.01.2018 14:52, Icenowy Zheng wrote:
于 2018年1月28日 GMT+08:00 下午9:46:18, Philipp Rossak 写到:
On 28.01.2018 10:02, Jonathan Cameron wrote:
On Fri, 26 Jan 2018 16:19:32 +0100
Philipp Rossak wrote:
This patch reworks the driver to support nvmem calibration cells.
The driver checks if the nvmem calibration is supported and reads
out
the nvmem. At the beginning of the startup process the calibration
data
is written to the related registers.
Signed-off-by: Philipp Rossak
A few minor suggestions inline.
Jonathan
---
drivers/iio/adc/sun4i-gpadc-iio.c | 52
+++
include/linux/mfd/sun4i-gpadc.h | 2 ++
2 files changed, 54 insertions(+)
diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c
b/drivers/iio/adc/sun4i-gpadc-iio.c
index bff06f2798e8..7b12666cdd9e 100644
--- a/drivers/iio/adc/sun4i-gpadc-iio.c
+++ b/drivers/iio/adc/sun4i-gpadc-iio.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -81,6 +82,7 @@ struct gpadc_data {
boolhas_bus_rst;
boolhas_mod_clk;
int sensor_count;
+ boolsupports_nvmem;
};
static const struct gpadc_data sun4i_gpadc_data = {
@@ -94,6 +96,7 @@ static const struct gpadc_data sun4i_gpadc_data =
{
.sample_start = sun4i_gpadc_sample_start,
.sample_end = sun4i_gpadc_sample_end,
.sensor_count = 1,
+ .supports_nvmem = false,
};
static const struct gpadc_data sun5i_gpadc_data = {
@@ -107,6 +110,7 @@ static const struct gpadc_data sun5i_gpadc_data
= {
.sample_start = sun4i_gpadc_sample_start,
.sample_end = sun4i_gpadc_sample_end,
.sensor_count = 1,
+ .supports_nvmem = false,
};
static const struct gpadc_data sun6i_gpadc_data = {
@@ -120,6 +124,7 @@ static const struct gpadc_data sun6i_gpadc_data
= {
.sample_start = sun4i_gpadc_sample_start,
.sample_end = sun4i_gpadc_sample_end,
.sensor_count = 1,
+ .supports_nvmem = false,
};
static const struct gpadc_data sun8i_a33_gpadc_data = {
@@ -130,6 +135,7 @@ static const struct gpadc_data
sun8i_a33_gpadc_data = {
.sample_start = sun4i_gpadc_sample_start,
.sample_end = sun4i_gpadc_sample_end,
.sensor_count = 1,
+ .supports_nvmem = false,
BTW A33 claims to support calibration data according to the manual.
Yes that's true, but I haven't seen a sid/nvmem driver for the a33. If
that is available, we can change this for true (same on a83t).
};
struct sun4i_gpadc_iio {
@@ -148,6 +154,8 @@ struct sun4i_gpadc_iio {
struct clk *mod_clk;
struct reset_control*reset;
int sensor_id;
+ u32 calibration_data[2];
+ boolhas_calibration_data[2];
/* prevents concurrent reads of temperature and ADC */
struct mutexmutex;
struct thermal_zone_device *tzd;
@@ -459,6 +467,17 @@ static int sun4i_gpadc_runtime_suspend(struct
device *dev)
return info->data->sample_end(info);
}
+static void sunxi_calibrate(struct sun4i_gpadc_iio *info)
+{
+ if (info->has_calibration_data[0])
+ regmap_write(info->regmap, SUNXI_THS_CDATA_0_1,
+ info->calibration_data[0]);
+
+ if (info->has_calibration_data[1])
+ regmap_write(info->regmap, SUNXI_THS_CDATA_2_3,
+ info->calibration_data[1]);
+}
+
static int sun4i_gpadc_sample_start(struct sun4i_gpadc_iio *info)
{
/* clkin = 6MHz */
@@ -481,6 +500,7 @@ static int sun4i_gpadc_sample_start(struct
sun4i_gpadc_iio *info)
static int sunxi_ths_sample_start(struct sun4i_gpadc_iio *info)
{
u32 value;
+ sunxi_calibrate(info);
if (info->data->ctrl0_map)
regmap_write(info->regmap, SUNXI_THS_CTRL0,
@@ -602,6 +622,9 @@ static int sun4i_gpadc_probe_dt(struct
platform_device *pdev,
struct resource *mem;
void __iomem *base;
int ret;
+ struct nvmem_cell *cell;
+ ssize_t cell_size;
+ u64 *cell_data;
info->data = of_device_get_match_data(&pdev->dev);
if (!info->data)
@@ -616,6 +639,35 @@ static int sun4i_gpadc_probe_dt(struct
platform_device *pdev,
if (IS_ERR(base))
return PTR_ERR(base);
+ info->has_calibration_data[0] = false;
+ info->has_calibration_data[1] = false;
+
+ if (!info->data->supports_nvmem)
+ goto no_nvmem;
+
+ cell = devm_nvmem_cell_get(&pdev->dev, "calibration");
+ if (IS_ERR(cell)) {
+ if (PTR_ERR(cell) == -EPROBE_DEFER)
+ return PTR_ERR(cell);
Use a goto here to no_nvmem.
Then you can drop the below else to make things more readable.
+ } e
Re: [PATCH v2] i2c: i801: Register optional lis3lv02d i2c device on Dell machines
On Sat, Jan 27, 2018 at 3:32 PM, Pali Rohár wrote:
> Dell platform team told us that some (DMI whitelisted) Dell Latitude
> machines have ST microelectronics accelerometer at i2c address 0x29.
>
> Presence of that ST microelectronics accelerometer is verified by existence
> of SMO88xx ACPI device which represent that accelerometer. Unfortunately
> ACPI device does not specify i2c address.
>
> This patch registers lis3lv02d device for selected Dell Latitude machines
> at i2c address 0x29 after detection. And for Dell Vostro V131 machine at
> i2c address 0x1d which was manually detected.
>
> Finally commit a7ae81952cda ("i2c: i801: Allow ACPI SystemIO OpRegion to
> conflict with PCI BAR") allowed to use i2c-i801 driver on Dell machines so
> lis3lv02d correctly initialize accelerometer.
>
> Tested on Dell Latitude E6440.
> +static acpi_status check_acpi_smo88xx_device(acpi_handle obj_handle,
> +u32 nesting_level,
> +void *context,
> +void **return_value)
> +{
> + struct acpi_device_info *info;
> + acpi_status status;
> + char *hid;
> +
> + status = acpi_get_object_info(obj_handle, &info);
> + if (!ACPI_SUCCESS(status) || !(info->valid & ACPI_VALID_HID))
> + return AE_OK;
> +
> + hid = info->hardware_id.string;
> + if (!hid)
> + return AE_OK;
> +
> + if (strlen(hid) < 7)
> + return AE_OK;
> +
> + if (memcmp(hid, "SMO88", 5) != 0)
> + return AE_OK;
> +
> + *((bool *)return_value) = true;
> + return AE_CTRL_TERMINATE;
> +}
> +
> +static bool is_dell_system_with_lis3lv02d(void)
> +{
> + /*
> +* Check that ACPI device SMO88xx exists and is enabled. That ACPI
> +* device represent our ST microelectronics lis3lv02d accelerometer
> but
> +* unfortunately without any other information (like i2c address).
> +*/
Isn't it simple
return acpi_dev_present("SMO88", NULL, -1);
call?
> + found = false;
> + status = acpi_get_devices(NULL, check_acpi_smo88xx_device, NULL,
> + (void **)&found);
> + if (!ACPI_SUCCESS(status) || !found)
> + return false;
> +
> + return true;
> +}
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 0/3] IB-iSER: Adjustments for three function implementations
On 1/27/2018 8:17 PM, SF Markus Elfring wrote: From: Markus Elfring Date: Sat, 27 Jan 2018 19:02:34 +0100 Three update suggestions were taken into account from static source code analysis. Markus Elfring (3): Delete an error message for a failed memory allocation in iser_send_data_out() Delete an unnecessary variable initialisation in iser_send_data_out() Combine substrings for three messages drivers/infiniband/ulp/iser/iser_initiator.c | 16 ++-- 1 file changed, 6 insertions(+), 10 deletions(-) This series looks good to me, Reviewed-by: Max Gurtovoy
Re: [PATCH stable] cifs: empty TargetInfo leads to crash on recovery
On Sat, Jan 27, 2018 at 10:07:41PM +0200, Dan Aloni wrote:
> commit cabfb3680f78 upstream.
Are you sure?
$ gsr cabfb3680f78
cabfb3680f78 ("CIFS: Enable encryption during session setup phase")
Doesn't seem to match up at all here :(
totally confused,
greg k-h
Re: [PATCH v2] i2c: i801: Register optional lis3lv02d i2c device on Dell machines
On Sunday 28 January 2018 16:39:25 Andy Shevchenko wrote:
> On Sat, Jan 27, 2018 at 3:32 PM, Pali Rohár wrote:
> > +static bool is_dell_system_with_lis3lv02d(void)
> > +{
>
> > + /*
> > +* Check that ACPI device SMO88xx exists and is enabled. That ACPI
> > +* device represent our ST microelectronics lis3lv02d accelerometer
> > but
> > +* unfortunately without any other information (like i2c address).
> > +*/
>
> Isn't it simple
>
> return acpi_dev_present("SMO88", NULL, -1);
>
> call?
ACPI device name is SMO8800, SMO8810, ... Will that acpi_dev_present
function match only prefix and not exact string?
> > + found = false;
> > + status = acpi_get_devices(NULL, check_acpi_smo88xx_device, NULL,
> > + (void **)&found);
> > + if (!ACPI_SUCCESS(status) || !found)
> > + return false;
> > +
> > + return true;
> > +}
>
>
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: PGP signature
Re: [PATCH v3 bpf] bpf: introduce BPF_JIT_ALWAYS_ON config
On Wed, Jan 24, 2018 at 11:10:50AM +0100, Daniel Borkmann wrote: > On 01/24/2018 11:07 AM, David Woodhouse wrote: > > On Tue, 2018-01-09 at 22:39 +0100, Daniel Borkmann wrote: > >> On 01/09/2018 07:04 PM, Alexei Starovoitov wrote: > >>> > >>> The BPF interpreter has been used as part of the spectre 2 attack > >>> CVE-2017-5715. > >>> > >>> A quote from goolge project zero blog: > >>> "At this point, it would normally be necessary to locate gadgets in > >>> the host kernel code that can be used to actually leak data by reading > >>> from an attacker-controlled location, shifting and masking the result > >>> appropriately and then using the result of that as offset to an > >>> attacker-controlled address for a load. But piecing gadgets together > >>> and figuring out which ones work in a speculation context seems annoying. > >>> So instead, we decided to use the eBPF interpreter, which is built into > >>> the host kernel - while there is no legitimate way to invoke it from > >>> inside > >>> a VM, the presence of the code in the host kernel's text section is > >>> sufficient > >>> to make it usable for the attack, just like with ordinary ROP gadgets." > >>> > >>> To make attacker job harder introduce BPF_JIT_ALWAYS_ON config > >>> option that removes interpreter from the kernel in favor of JIT-only mode. > >>> So far eBPF JIT is supported by: > >>> x64, arm64, arm32, sparc64, s390, powerpc64, mips64 > >>> > >>> The start of JITed program is randomized and code page is marked as > >>> read-only. > >>> In addition "constant blinding" can be turned on with > >>> net.core.bpf_jit_harden > >>> > >>> v2->v3: > >>> - move __bpf_prog_ret0 under ifdef (Daniel) > >>> > >>> v1->v2: > >>> - fix init order, test_bpf and cBPF (Daniel's feedback) > >>> - fix offloaded bpf (Jakub's feedback) > >>> - add 'return 0' dummy in case something can invoke prog->bpf_func > >>> - retarget bpf tree. For bpf-next the patch would need one extra hunk. > >>> It will be sent when the trees are merged back to net-next > >>> > >>> Considered doing: > >>> int bpf_jit_enable __read_mostly = BPF_EBPF_JIT_DEFAULT; > >>> but it seems better to land the patch as-is and in bpf-next remove > >>> bpf_jit_enable global variable from all JITs, consolidate in one place > >>> and remove this jit_init() function. > >>> > >>> Signed-off-by: Alexei Starovoitov > >> > >> Applied to bpf tree, thanks Alexei! > > > > For stable too? > > Yes, this will go into stable as well; batch of backports will come Thurs/Fri. Any word on these? Worse case, a simple list of git commit ids to backport is all I need. thanks, greg k-h
Re: [PATCH] IB/mthca: remove mthca_user.h
On Sun, Jan 28, 2018 at 12:39:43PM +, Corentin Labbe wrote:
> mthca_user.h is unused since commit 486f60954c71 ("IB/mthca: Move user vendor
> structures")
> Remove it from tree.
>
> Signed-off-by: Corentin Labbe
> ---
> drivers/infiniband/hw/mthca/mthca_user.h | 112
> ---
> 1 file changed, 112 deletions(-)
> delete mode 100644 drivers/infiniband/hw/mthca/mthca_user.h
>
Thanks,
Reviewed-by: Leon Romanovsky
signature.asc
Description: PGP signature
Re: [PATCH stable] cifs: empty TargetInfo leads to crash on recovery
On Sun, Jan 28, 2018 at 03:43:48PM +0100, Greg KH wrote:
> On Sat, Jan 27, 2018 at 10:07:41PM +0200, Dan Aloni wrote:
> > commit cabfb3680f78 upstream.
>
> Are you sure?
> $ gsr cabfb3680f78
> cabfb3680f78 ("CIFS: Enable encryption during session setup phase")
>
> Doesn't seem to match up at all here :(
That's only because it fixed the issue unknownly, accordingly to
git-bisectings I've done. Should I have not added 'commit
upstream.' in that case? stable_kernel_rules.txt is not so clear
about it.
--
Dan Aloni
Re: [PATCH v2] i2c: i801: Register optional lis3lv02d i2c device on Dell machines
On Sun, Jan 28, 2018 at 4:45 PM, Pali Rohár wrote:
> On Sunday 28 January 2018 16:39:25 Andy Shevchenko wrote:
>> On Sat, Jan 27, 2018 at 3:32 PM, Pali Rohár wrote:
>> > +static bool is_dell_system_with_lis3lv02d(void)
>> > +{
>>
>> > + /*
>> > +* Check that ACPI device SMO88xx exists and is enabled. That ACPI
>> > +* device represent our ST microelectronics lis3lv02d
>> > accelerometer but
>> > +* unfortunately without any other information (like i2c address).
>> > +*/
>>
>> Isn't it simple
>>
>> return acpi_dev_present("SMO88", NULL, -1);
>>
>> call?
>
> ACPI device name is SMO8800, SMO8810, ... Will that acpi_dev_present
> function match only prefix and not exact string?
OK, fair enough.
Do we have more users of such pattern? If so, it might make sense to
introduce a generic helper for that which takes a list of HIDs on
input.
(Yes, I do not like matching pattern like "XYZhh*", I prefer explicit
list of HIDs. Rationale to do so: a) any new potential collision is
excluded, b) we can easily grep kernel for a users per HID)
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v2 1/2] x86/acpi: add retrieval function for rsdp address
On Fri, Jan 26, 2018 at 8:21 PM, Juergen Gross wrote: > On 26/01/18 19:08, Andy Shevchenko wrote: >> On Thu, Jan 25, 2018 at 4:36 PM, Juergen Gross wrote: >>> Add a function to get the address of the RSDP table. Per default use a >>> __weak annotated function being a nop. >> >> The problem with weak functions that we can't have more than one >> implementation per kernel while we would like to built several code >> paths. >> >> I have stumbled on the similar stuff and realize that. >> >> Perhaps, one of the solution is to have an additional struct under >> x86_init to alternate ACPI related stuff. > > I think we can go that route when another user of that interface is > appearing. Why not to establish the struct? At least this route I would like to go with [1]. [1]: https://lkml.org/lkml/2018/1/17/834 -- With Best Regards, Andy Shevchenko
[PATCH] IB/qib: remove qib_keys.c
qib_keys.c was left uncompilable in commit 7c2e11fe2dbe ("IB/qib: Remove qp and
mr functionality from qib")
Since nothing need it, remove it from tree.
Signed-off-by: Corentin Labbe
---
drivers/infiniband/hw/qib/qib_keys.c | 235 ---
1 file changed, 235 deletions(-)
delete mode 100644 drivers/infiniband/hw/qib/qib_keys.c
diff --git a/drivers/infiniband/hw/qib/qib_keys.c
b/drivers/infiniband/hw/qib/qib_keys.c
deleted file mode 100644
index 8fdf79f8d4e4..
--- a/drivers/infiniband/hw/qib/qib_keys.c
+++ /dev/null
@@ -1,235 +0,0 @@
-/*
- * Copyright (c) 2006, 2007, 2009 QLogic Corporation. All rights reserved.
- * Copyright (c) 2005, 2006 PathScale, Inc. All rights reserved.
- *
- * This software is available to you under a choice of one of two
- * licenses. You may choose to be licensed under the terms of the GNU
- * General Public License (GPL) Version 2, available from the file
- * COPYING in the main directory of this source tree, or the
- * OpenIB.org BSD license below:
- *
- * Redistribution and use in source and binary forms, with or
- * without modification, are permitted provided that the following
- * conditions are met:
- *
- * - Redistributions of source code must retain the above
- *copyright notice, this list of conditions and the following
- *disclaimer.
- *
- * - Redistributions in binary form must reproduce the above
- *copyright notice, this list of conditions and the following
- *disclaimer in the documentation and/or other materials
- *provided with the distribution.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
- * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
- * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
- * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
- * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
- * SOFTWARE.
- */
-
-#include "qib.h"
-
-/**
- * qib_alloc_lkey - allocate an lkey
- * @mr: memory region that this lkey protects
- * @dma_region: 0->normal key, 1->restricted DMA key
- *
- * Returns 0 if successful, otherwise returns -errno.
- *
- * Increments mr reference count as required.
- *
- * Sets the lkey field mr for non-dma regions.
- *
- */
-
-int qib_alloc_lkey(struct rvt_mregion *mr, int dma_region)
-{
- unsigned long flags;
- u32 r;
- u32 n;
- int ret = 0;
- struct qib_ibdev *dev = to_idev(mr->pd->device);
- struct rvt_lkey_table *rkt = &dev->lk_table;
-
- spin_lock_irqsave(&rkt->lock, flags);
-
- /* special case for dma_mr lkey == 0 */
- if (dma_region) {
- struct rvt_mregion *tmr;
-
- tmr = rcu_access_pointer(dev->dma_mr);
- if (!tmr) {
- qib_get_mr(mr);
- rcu_assign_pointer(dev->dma_mr, mr);
- mr->lkey_published = 1;
- }
- goto success;
- }
-
- /* Find the next available LKEY */
- r = rkt->next;
- n = r;
- for (;;) {
- if (rkt->table[r] == NULL)
- break;
- r = (r + 1) & (rkt->max - 1);
- if (r == n)
- goto bail;
- }
- rkt->next = (r + 1) & (rkt->max - 1);
- /*
-* Make sure lkey is never zero which is reserved to indicate an
-* unrestricted LKEY.
-*/
- rkt->gen++;
- /*
-* bits are capped in qib_verbs.c to insure enough bits
-* for generation number
-*/
- mr->lkey = (r << (32 - ib_rvt_lkey_table_size)) |
- 1 << (24 - ib_rvt_lkey_table_size)) - 1) & rkt->gen)
-<< 8);
- if (mr->lkey == 0) {
- mr->lkey |= 1 << 8;
- rkt->gen++;
- }
- qib_get_mr(mr);
- rcu_assign_pointer(rkt->table[r], mr);
- mr->lkey_published = 1;
-success:
- spin_unlock_irqrestore(&rkt->lock, flags);
-out:
- return ret;
-bail:
- spin_unlock_irqrestore(&rkt->lock, flags);
- ret = -ENOMEM;
- goto out;
-}
-
-/**
- * qib_free_lkey - free an lkey
- * @mr: mr to free from tables
- */
-void qib_free_lkey(struct rvt_mregion *mr)
-{
- unsigned long flags;
- u32 lkey = mr->lkey;
- u32 r;
- struct qib_ibdev *dev = to_idev(mr->pd->device);
- struct rvt_lkey_table *rkt = &dev->lk_table;
-
- spin_lock_irqsave(&rkt->lock, flags);
- if (!mr->lkey_published)
- goto out;
- if (lkey == 0)
- RCU_INIT_POINTER(dev->dma_mr, NULL);
- else {
- r = lkey >> (32 - ib_rvt_lkey_table_size);
- RCU_INIT_POINTER(rkt->table[r], NULL);
- }
- qib_put_mr(mr);
- mr->lkey_
Re: [ANNOUNCE] v4.14.15-rt12
Hi On Thu, Jan 25, 2018 at 04:17:06PM +0100, Sebastian Andrzej Siewior wrote: > Dear RT folks! > > I'm pleased to announce the v4.14.15-rt12 patch set. > > Changes since v4.14.15-rt11: > > - Drop ping-sysrq. Since it won't reach mainline in its current shape, > lets drop. Suggested by Carsten Emde. [...] > The split quilt queue is available at: > > > https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.14/older/patches-4.14.15-rt12.tar.xz Just a small heads-up: Whilst ping-sysrq.patch was dropped the included series file still contains: # NETWORK DEBUGGING AID ping-sysrq.patch Regards, Salvatore
[PATCH] IB/cxgb3: remove cxio_dbg.c
cxio_dbg.c is uncompiled since commit 2b540355cd2f ("RDMA/cxgb3: cleanups")
10 years after, we could remove it.
Signed-off-by: Corentin Labbe
---
drivers/infiniband/hw/cxgb3/cxio_dbg.c | 206 -
1 file changed, 206 deletions(-)
delete mode 100644 drivers/infiniband/hw/cxgb3/cxio_dbg.c
diff --git a/drivers/infiniband/hw/cxgb3/cxio_dbg.c
b/drivers/infiniband/hw/cxgb3/cxio_dbg.c
deleted file mode 100644
index 97dbe728520a..
--- a/drivers/infiniband/hw/cxgb3/cxio_dbg.c
+++ /dev/null
@@ -1,206 +0,0 @@
-/*
- * Copyright (c) 2006 Chelsio, Inc. All rights reserved.
- *
- * This software is available to you under a choice of one of two
- * licenses. You may choose to be licensed under the terms of the GNU
- * General Public License (GPL) Version 2, available from the file
- * COPYING in the main directory of this source tree, or the
- * OpenIB.org BSD license below:
- *
- * Redistribution and use in source and binary forms, with or
- * without modification, are permitted provided that the following
- * conditions are met:
- *
- * - Redistributions of source code must retain the above
- *copyright notice, this list of conditions and the following
- *disclaimer.
- *
- * - Redistributions in binary form must reproduce the above
- *copyright notice, this list of conditions and the following
- *disclaimer in the documentation and/or other materials
- *provided with the distribution.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
- * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
- * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
- * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
- * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
- * SOFTWARE.
- */
-#ifdef DEBUG
-#include
-#include
-#include "common.h"
-#include "cxgb3_ioctl.h"
-#include "cxio_hal.h"
-#include "cxio_wr.h"
-
-void cxio_dump_tpt(struct cxio_rdev *rdev, u32 stag)
-{
- struct ch_mem_range *m;
- u64 *data;
- int rc;
- int size = 32;
-
- m = kmalloc(sizeof(*m) + size, GFP_ATOMIC);
- if (!m)
- return;
-
- m->mem_id = MEM_PMRX;
- m->addr = (stag>>8) * 32 + rdev->rnic_info.tpt_base;
- m->len = size;
- pr_debug("%s TPT addr 0x%x len %d\n", __func__, m->addr, m->len);
- rc = rdev->t3cdev_p->ctl(rdev->t3cdev_p, RDMA_GET_MEM, m);
- if (rc) {
- pr_debug("%s toectl returned error %d\n", __func__, rc);
- kfree(m);
- return;
- }
-
- data = (u64 *)m->buf;
- while (size > 0) {
- pr_debug("TPT %08x: %016llx\n",
-m->addr, (unsigned long long)*data);
- size -= 8;
- data++;
- m->addr += 8;
- }
- kfree(m);
-}
-
-void cxio_dump_pbl(struct cxio_rdev *rdev, u32 pbl_addr, uint len, u8 shift)
-{
- struct ch_mem_range *m;
- u64 *data;
- int rc;
- int size, npages;
-
- shift += 12;
- npages = (len + (1ULL << shift) - 1) >> shift;
- size = npages * sizeof(u64);
-
- m = kmalloc(sizeof(*m) + size, GFP_ATOMIC);
- if (!m)
- return;
-
- m->mem_id = MEM_PMRX;
- m->addr = pbl_addr;
- m->len = size;
- pr_debug("%s PBL addr 0x%x len %d depth %d\n",
-__func__, m->addr, m->len, npages);
- rc = rdev->t3cdev_p->ctl(rdev->t3cdev_p, RDMA_GET_MEM, m);
- if (rc) {
- pr_debug("%s toectl returned error %d\n", __func__, rc);
- kfree(m);
- return;
- }
-
- data = (u64 *)m->buf;
- while (size > 0) {
- pr_debug("PBL %08x: %016llx\n",
-m->addr, (unsigned long long)*data);
- size -= 8;
- data++;
- m->addr += 8;
- }
- kfree(m);
-}
-
-void cxio_dump_wqe(union t3_wr *wqe)
-{
- __be64 *data = (__be64 *)wqe;
- uint size = (uint)(be64_to_cpu(*data) & 0xff);
-
- if (size == 0)
- size = 8;
- while (size > 0) {
- pr_debug("WQE %p: %016llx\n",
-data, (unsigned long long)be64_to_cpu(*data));
- size--;
- data++;
- }
-}
-
-void cxio_dump_wce(struct t3_cqe *wce)
-{
- __be64 *data = (__be64 *)wce;
- int size = sizeof(*wce);
-
- while (size > 0) {
- pr_debug("WCE %p: %016llx\n",
-data, (unsigned long long)be64_to_cpu(*data));
- size -= 8;
- data++;
- }
-}
-
-void cxio_dump_rqt(struct cxio_rdev *rdev, u32 hwtid, int nents)
-{
- struct ch_mem_range *m;
- int size = nents * 64;
-
Re: [PATCH v5 07/12] x86: remove the syscall_64 fast-path
> On Jan 28, 2018, at 1:29 AM, Ingo Molnar wrote: > > > * Dan Williams wrote: > >> Quoting Linus: >> >> "Honestly, I'd rather get rid of the fast-path entirely. Compared to >> all the PTI mess, it's not even noticeable. >> >> And if we ever get CPU's that have this all fixed, we can re-visit >> introducing the fastpath. But this is all very messy and it doesn't >> seem worth it right now. >> >> If we get rid of the fastpath, we can lay out the slow path slightly >> better, and get rid of some of those jump-overs. And we'd get rid of >> the ptregs hooks entirely. >> >> So we can try to make the "slow" path better while at it, but I >> really don't think it matters much now in the post-PTI era. Sadly." > > Please fix the title to have the proper prefix and to reference the function > that > is actually modified by the patch, i.e. something like: > > s/ x86: remove the syscall_64 fast-path > / x86/entry/64: Remove the entry_SYSCALL_64() fast-path > > With the title fixed: > > Reviewed-by: Ingo Molnar I have a very similar but not quite identical version I'll send out shortly. The difference is that I fixed the silly prologue. > > Thanks, > >Ingo
Re: [PATCH] block: aoenet: Replace GFP_ATOMIC with GFP_KERNEL in aoenet_rcv
Good luck in your efforts, and thanks for your work on static analysis. > On Jan 27, 2018, at 9:12 PM, Jia-Ju Bai wrote: > > > >> On 2018/1/28 1:48, Ed Cashin wrote: >> If the tool cannot tell whether the protected state is manipulated by >> *another* piece of code called in atomic context, then it's insufficient. >> >>> On Jan 26, 2018, at 4:37 AM, Jia-Ju Bai wrote: >>> >>> After checking all possible call chains to aoenet_rcv(), >>> my tool finds that aoenet_rcv() is never called in atomic context, >>> namely never in an interrupt handler or holding a spinlock. >>> Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL. >>> >>> This is found by a static analysis tool named DCNS written by myself. >>> >>> Signed-off-by: Jia-Ju Bai >>> --- >>> drivers/block/aoe/aoenet.c |2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/block/aoe/aoenet.c b/drivers/block/aoe/aoenet.c >>> index 63773a9..d5fff7a 100644 >>> --- a/drivers/block/aoe/aoenet.c >>> +++ b/drivers/block/aoe/aoenet.c >>> @@ -138,7 +138,7 @@ static int __init aoe_iflist_setup(char *str) >>>if (dev_net(ifp) != &init_net) >>>goto exit; >>> >>> -skb = skb_share_check(skb, GFP_ATOMIC); >>> +skb = skb_share_check(skb, GFP_KERNEL); >>>if (skb == NULL) >>>return 0; >>>if (!is_aoe_netif(ifp)) >>> -- >>> 1.7.9.5 >>> >>> > > Sorry, I find my report is false positive after I manually check the code. > aoenet_rcv() is used as function pointer via "->func", and it is called in > dev_queue_xmit_nit() in net/core/dev.c. > dev_queue_xmit_nit() calls a rcu_read_lock() before it calls pt_prev->func(). > Thus it is right to use GFP_ATOMIC in aoenet_rcv(). > Sorry again for my incorrect report... > > Thanks, > Jia-Ju Bai
Re: [RESEND PATCH 3/6] ARM: dts: imx7s: add CAAM device node
Hi, Thanks for the report. On Sat 27 Jan 2018 at 15:49, kbuild test robot wrote: > Hi Rui, > > I love your patch! Yet something to improve: > > [auto build test ERROR on crypto/master] > [also build test ERROR on v4.15-rc9 next-20180126] > [cannot apply to cryptodev/master] > [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/Bryan-O-Donoghue/Enable-CAAM-on-i-MX7s-fix-TrustZone-issues/20180127-185422 > base: > https://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git master > config: arm-u8500_defconfig (attached as .config) > compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0 > reproduce: > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > make.cross ARCH=arm > > Note: the > linux-review/Bryan-O-Donoghue/Enable-CAAM-on-i-MX7s-fix-TrustZone-issues/20180127-185422 > HEAD f907a172373d2c61dd7bf25a88621abc6e410f15 builds fine. > It only hurts bisectibility. Yeah, the order of the patches in the series were wrong and break bisectibility. V2 of this series already sent, besides other fixes, also fix this. Once again many thanks. --- Cheers, Rui
Re: [PATCH] kbuild: clang: Disable -Wunused-const-variable warnings
On Fri, Jan 26, 2018 at 04:59:46PM -0800, Prasad Sodagudi wrote: > Disable -Wunused-const-variable warnings instead of > disabling -Wunused-variable warnings, So that in both > clang and GCC -Wunused-const-variable gets disabled. Why would you disable -Wunused-const-variable on GCC? You do not explain why. Segher
staging: ion: ION allocation fall back order depends on heap linkage order
Hi,
According to my understanding, the allocation fall back order
completely depends on heap->id that is assigned during the heap
creation:
plist_for_each_entry(heap, &dev->heaps, node) {
/* if the caller didn't specify this heap id */
if (!((1 << heap->id) & heap_id_mask))
continue;
buffer = ion_buffer_create(heap, dev, len, flags);
if (!IS_ERR(buffer))
break;
}
On creation, each heap is added to the priority list according to the
priority assigned:
...
static int heap_id;
...
void ion_device_add_heap(struct ion_heap *heap)
{
...
heap->id = heap_id++;
...
}
The order of creation is the order of linkage defined in the Makefile.
Thus, by default, we have:
heap id 2, type ION_HEAP_TYPE_DMA
heap id 1, type ION_HEAP_TYPE_SYSTEM
heap id 0, type ION_HEAP_TYPE_SYSTEM_CONTIG
Changing the linkage order:
diff --git a/drivers/staging/android/ion/Makefile
b/drivers/staging/android/ion/Makefile
index bb30bf8..e05052c 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_ION) += ion.o ion-ioctl.o ion_heap.o
-obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o ion_page_pool.o
obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
+obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o ion_page_pool.o
I get the following order:
heap id 2, type ION_HEAP_TYPE_SYSTEM
heap id 1, type ION_HEAP_TYPE_SYSTEM_CONTIG
heap id 0, type ION_HEAP_TYPE_DMA
So, if the user specifies more than 1 heap in the heap_id_mask during
allocation, the allocation fall back order completely depends on the
order of linkage. Probably, it's better to let the user to define the
fall back order (and NOT to be dependent on the linkage order at all)
?
Thanks,
Alexey
Re: [PATCH] IB/cxgb3: remove cxio_dbg.c
On Sun, 2018-01-28 at 15:11 +, Corentin Labbe wrote:
> cxio_dbg.c is uncompiled since commit 2b540355cd2f ("RDMA/cxgb3: cleanups")
> 10 years after, we could remove it.
OK, now you could remove the prototypes and probably
CONFIG_INFINIBAND_CXGB3_DEBUG too.
There is a DEBUG test and many uses of pr_debug
that would have modified behavior.
The pr_debug uses would only be emitted via a
dynamic_debug enable and the #ifdef DEBUG is
probably not necessary or useful as it guards
a BUG_ON.
---
drivers/infiniband/hw/cxgb3/Kconfig| 9 -
drivers/infiniband/hw/cxgb3/Makefile | 2 --
drivers/infiniband/hw/cxgb3/cxio_hal.h | 9 -
drivers/infiniband/hw/cxgb3/iwch_cq.c | 7 ---
4 files changed, 27 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/Kconfig
b/drivers/infiniband/hw/cxgb3/Kconfig
index 431be733fbbe..a7b77cb3d5d5 100644
--- a/drivers/infiniband/hw/cxgb3/Kconfig
+++ b/drivers/infiniband/hw/cxgb3/Kconfig
@@ -16,12 +16,3 @@ config INFINIBAND_CXGB3
To compile this driver as a module, choose M here: the module
will be called iw_cxgb3.
-
-config INFINIBAND_CXGB3_DEBUG
- bool "Verbose debugging output"
- depends on INFINIBAND_CXGB3
- default n
- ---help---
- This option causes the Chelsio RDMA driver to produce copious
- amounts of debug messages. Select this if you are developing
- the driver or trying to diagnose a problem.
diff --git a/drivers/infiniband/hw/cxgb3/Makefile
b/drivers/infiniband/hw/cxgb3/Makefile
index 2c66d35d19bd..66fe0917aba0 100644
--- a/drivers/infiniband/hw/cxgb3/Makefile
+++ b/drivers/infiniband/hw/cxgb3/Makefile
@@ -5,5 +5,3 @@ obj-$(CONFIG_INFINIBAND_CXGB3) += iw_cxgb3.o
iw_cxgb3-y := iwch_cm.o iwch_ev.o iwch_cq.o iwch_qp.o iwch_mem.o \
iwch_provider.o iwch.o cxio_hal.o cxio_resource.o
-
-ccflags-$(CONFIG_INFINIBAND_CXGB3_DEBUG) += -DDEBUG
diff --git a/drivers/infiniband/hw/cxgb3/cxio_hal.h
b/drivers/infiniband/hw/cxgb3/cxio_hal.h
index 7e70c5492262..c64e50b5a548 100644
--- a/drivers/infiniband/hw/cxgb3/cxio_hal.h
+++ b/drivers/infiniband/hw/cxgb3/cxio_hal.h
@@ -202,13 +202,4 @@ int iwch_cxgb3_ofld_send(struct t3cdev *tdev, struct
sk_buff *skb);
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-#ifdef DEBUG
-void cxio_dump_tpt(struct cxio_rdev *rev, u32 stag);
-void cxio_dump_pbl(struct cxio_rdev *rev, u32 pbl_addr, uint len, u8 shift);
-void cxio_dump_wqe(union t3_wr *wqe);
-void cxio_dump_wce(struct t3_cqe *wce);
-void cxio_dump_rqt(struct cxio_rdev *rdev, u32 hwtid, int nents);
-void cxio_dump_tcb(struct cxio_rdev *rdev, u32 hwtid);
-#endif
-
#endif
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cq.c
b/drivers/infiniband/hw/cxgb3/iwch_cq.c
index dd5348e48806..f4979a505b3c 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_cq.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_cq.c
@@ -200,10 +200,6 @@ int iwch_poll_cq(struct ib_cq *ibcq, int num_entries,
struct ib_wc *wc)
spin_lock_irqsave(&chp->lock, flags);
for (npolled = 0; npolled < num_entries; ++npolled) {
-#ifdef DEBUG
- int i=0;
-#endif
-
/*
* Because T3 can post CQEs that are _not_ associated
* with a WR, we might have to poll again after removing
@@ -211,9 +207,6 @@ int iwch_poll_cq(struct ib_cq *ibcq, int num_entries,
struct ib_wc *wc)
*/
do {
err = iwch_poll_cq_one(rhp, chp, wc + npolled);
-#ifdef DEBUG
- BUG_ON(++i > 1000);
-#endif
} while (err == -EAGAIN);
if (err <= 0)
break;
Re: [PATCH v5 02/12] array_idx: sanitize speculative array de-references
On Sun, Jan 28, 2018 at 12:55 AM, Ingo Molnar wrote:
>
> Firstly, I only got a few patches of this series so I couldn't review all of
> them
> - please Cc: me to all future Meltdown and Spectre related patches!
>
> * Dan Williams wrote:
>
>> 'array_idx' is proposed as a generic mechanism to mitigate against
>> Spectre-variant-1 attacks, i.e. an attack that bypasses boundary checks
>> via speculative execution). The 'array_idx' implementation is expected
>> to be safe for current generation cpus across multiple architectures
>> (ARM, x86).
>
> nit: Stray closing parenthesis
>
> s/cpus/CPUs
>
>> Based on an original implementation by Linus Torvalds, tweaked to remove
>> speculative flows by Alexei Starovoitov, and tweaked again by Linus to
>> introduce an x86 assembly implementation for the mask generation.
>>
>> Co-developed-by: Linus Torvalds
>> Co-developed-by: Alexei Starovoitov
>> Suggested-by: Cyril Novikov
>> Cc: Russell King
>> Cc: Peter Zijlstra
>> Cc: Catalin Marinas
>> Cc: Will Deacon
>> Cc: Thomas Gleixner
>> Cc: Ingo Molnar
>> Cc: "H. Peter Anvin"
>> Cc: x...@kernel.org
>> Signed-off-by: Dan Williams
>> ---
>> include/linux/nospec.h | 64
>>
>> 1 file changed, 64 insertions(+)
>> create mode 100644 include/linux/nospec.h
>>
>> diff --git a/include/linux/nospec.h b/include/linux/nospec.h
>> new file mode 100644
>> index ..f59f81889ba3
>> --- /dev/null
>> +++ b/include/linux/nospec.h
>> @@ -0,0 +1,64 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +// Copyright(c) 2018 Intel Corporation. All rights reserved.
>
> Given the close similarity of Linus's array_access() prototype pseudocode
> there
> should probably also be:
>
> Copyright (C) 2018 Linus Torvalds
>
> in that file?
Yes, and Alexei as well.
>
>> +
>> +#ifndef __NOSPEC_H__
>> +#define __NOSPEC_H__
>> +
>> +/*
>> + * When idx is out of bounds (idx >= sz), the sign bit will be set.
>> + * Extend the sign bit to all bits and invert, giving a result of zero
>> + * for an out of bounds idx, or ~0UL if within bounds [0, sz).
>> + */
>> +#ifndef array_idx_mask
>> +static inline unsigned long array_idx_mask(unsigned long idx, unsigned long
>> sz)
>> +{
>> + /*
>> + * Warn developers about inappropriate array_idx usage.
>> + *
>> + * Even if the cpu speculates past the WARN_ONCE branch, the
>
> s/cpu/CPU
>
>> + * sign bit of idx is taken into account when generating the
>> + * mask.
>> + *
>> + * This warning is compiled out when the compiler can infer that
>> + * idx and sz are less than LONG_MAX.
>
> Please use 'idx' and 'sz' in quotes, to make sure they stand out more in free
> flowing comment text. Also please use '()' to denote functions/methods.
>
> I.e. something like:
>
> * Warn developers about inappropriate array_idx() usage.
> *
> * Even if the CPU speculates past the WARN_ONCE() branch, the
> * sign bit of 'idx' is taken into account when generating the
> * mask.
> *
> * This warning is compiled out when the compiler can infer that
> * 'idx' and 'sz' are less than LONG_MAX.
>
> That's just one example - please apply it to all comments consistently.
>
>> + */
>> + if (WARN_ONCE(idx > LONG_MAX || sz > LONG_MAX,
>> + "array_idx limited to range of [0, LONG_MAX]\n"))
>
> Same in user facing messages:
>
> "array_idx() limited to range of [0, LONG_MAX]\n"))
>
>> + * For a code sequence like:
>> + *
>> + * if (idx < sz) {
>> + * idx = array_idx(idx, sz);
>> + * val = array[idx];
>> + * }
>> + *
>> + * ...if the cpu speculates past the bounds check then array_idx() will
>> + * clamp the index within the range of [0, sz).
>
> s/cpu/CPU
>
>> + */
>> +#define array_idx(idx, sz) \
>> +({ \
>> + typeof(idx) _i = (idx); \
>> + typeof(sz) _s = (sz); \
>> + unsigned long _mask = array_idx_mask(_i, _s); \
>> + \
>> + BUILD_BUG_ON(sizeof(_i) > sizeof(long));\
>> + BUILD_BUG_ON(sizeof(_s) > sizeof(long));\
>> + \
>> + _i &= _mask;\
>> + _i; \
>> +})
>> +#endif /* __NOSPEC_H__ */
>
> For heaven's sake, please name a size variable as 'size', not 'sz'. We don't
> have
> a shortage of characters and can deobfuscate common primitives, can we?
>
> Also, beyond the nits, I also hate the namespace here. We have a new generic
> header providing two new methods:
>
>
Re: [PATCH v18 03/10] video: backlight: Add of_find_backlight helper in backlight.c
On Mon, Jan 22, 2018 at 4:51 PM, Meghana Madhyastha wrote: > Add of_find_backlight, a helper function which is a generic version > of tinydrm_of_find_backlight that can be used by other drivers to avoid > repetition of code and simplify things. > +struct backlight_device *of_find_backlight(struct device *dev) It looks strange that of_ prefixed function takes struct device instead of struct device_node. -- With Best Regards, Andy Shevchenko
Re: [PATCH 4/6] x86: Consolidate PCI_MMCONFIG configs
On Mon, Jan 22, 2018 at 8:12 AM, Jan Kiszka wrote: > From: Jan Kiszka > > Not sure if those two worked by design or just by chance so far. In any > case, it's at least cleaner and clearer to express this in a single > config statement. Congrats! You found by the way a bug in commit e279b6c1d329e50b766bce96aacc197eae8a053b Author: Sam Ravnborg Date: Tue Nov 6 20:41:05 2007 +0100 x86: start unification of arch/x86/Kconfig.* ...and proper fix seems to split PCI stuff to common + X86_32 only + X86_64 only -- With Best Regards, Andy Shevchenko
Re: [PATCH v2 3/6] gpio: Add GPIO driver for Nintendo Wii
On Mon, Jan 22, 2018 at 7:04 AM, Jonathan Neuschäfer
wrote:
Style issues below.
> +#define HW_GPIO_OWNER 0x3c
> +
> +
> +struct hlwd_gpio {
No need extra empty line in between.
> + struct gpio_chip gpioc;
> + void __iomem *regs;
> + struct device *dev;
> +};
> +
> +static int hlwd_gpio_probe(struct platform_device *pdev)
> +{
> + struct hlwd_gpio *hlwd;
> + struct resource *regs_resource;
> + u32 ngpios;
> + int res;
> +
> + hlwd = devm_kzalloc(&pdev->dev, sizeof(*hlwd), GFP_KERNEL);
> + if (!hlwd)
> + return -ENOMEM;
> +
> + /* Save the struct device pointer so dev_info, etc. can be used. */
Useless.
> + hlwd->dev = &pdev->dev;
> +
> + regs_resource = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (IS_ERR(regs_resource))
> + return PTR_ERR(regs_resource);
> +
This is redundant. Below does it for ya.
> + hlwd->regs = devm_ioremap_resource(&pdev->dev, regs_resource);
> + if (IS_ERR(hlwd->regs))
> + return PTR_ERR(hlwd->regs);
> + res = bgpio_init(&hlwd->gpioc, &pdev->dev, 4,
> + hlwd->regs + HW_GPIOB_IN, hlwd->regs + HW_GPIOB_OUT,
> + NULL, hlwd->regs + HW_GPIOB_DIR, NULL,
> + BGPIOF_BIG_ENDIAN_BYTE_ORDER);
> +
Remove this extra line.
> + if (res < 0) {
> + dev_warn(hlwd->dev, "bgpio_init failed: %d\n", res);
> + return res;
> + }
> + if (of_property_read_u32(pdev->dev.of_node, "ngpios", &ngpios))
> + ngpios = 32;
A nit: I would rather go with
res = of_property_read(...);
if (res)
ngpios = 32;
--
With Best Regards,
Andy Shevchenko
Re: [RESEND][PATCH] tools/power: Don't make man pages executable
Applied. thanks! -Len On Tue, Dec 19, 2017 at 11:02 PM, Laura Abbott wrote: > rpm-lint flagged these as being executable: > > kernel-tools.x86_64: W: spurious-executable-perm > /usr/share/man/man8/turbostat.8.gz > kernel-tools.x86_64: W: spurious-executable-perm > /usr/share/man/man8/x86_energy_perf_policy.8.gz > > Fix this > > Signed-off-by: Laura Abbott > --- > Resent for linux-pm cc > --- > tools/power/x86/turbostat/Makefile | 2 +- > tools/power/x86/x86_energy_perf_policy/Makefile | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tools/power/x86/turbostat/Makefile > b/tools/power/x86/turbostat/Makefile > index a9bc914a8fe8..2ab25aa38263 100644 > --- a/tools/power/x86/turbostat/Makefile > +++ b/tools/power/x86/turbostat/Makefile > @@ -25,4 +25,4 @@ install : turbostat > install -d $(DESTDIR)$(PREFIX)/bin > install $(BUILD_OUTPUT)/turbostat $(DESTDIR)$(PREFIX)/bin/turbostat > install -d $(DESTDIR)$(PREFIX)/share/man/man8 > - install turbostat.8 $(DESTDIR)$(PREFIX)/share/man/man8 > + install -m 644 turbostat.8 $(DESTDIR)$(PREFIX)/share/man/man8 > diff --git a/tools/power/x86/x86_energy_perf_policy/Makefile > b/tools/power/x86/x86_energy_perf_policy/Makefile > index 2447b1bbaacf..f4534fb8b951 100644 > --- a/tools/power/x86/x86_energy_perf_policy/Makefile > +++ b/tools/power/x86/x86_energy_perf_policy/Makefile > @@ -24,5 +24,5 @@ install : x86_energy_perf_policy > install -d $(DESTDIR)$(PREFIX)/bin > install $(BUILD_OUTPUT)/x86_energy_perf_policy > $(DESTDIR)$(PREFIX)/bin/x86_energy_perf_policy > install -d $(DESTDIR)$(PREFIX)/share/man/man8 > - install x86_energy_perf_policy.8 $(DESTDIR)$(PREFIX)/share/man/man8 > + install -m 644 x86_energy_perf_policy.8 > $(DESTDIR)$(PREFIX)/share/man/man8 > > -- > 2.14.3 > -- Len Brown, Intel Open Source Technology Center
Re: [PATCH v5 02/12] array_idx: sanitize speculative array de-references
* Dan Williams wrote: > Thomas, Peter, and Alexei wanted s/nospec_barrier/ifence/ and I just checked past discussions, and I cannot find that part, got any links or message-IDs? PeterZ's feedback on Jan 8 was: > On Sun, Jan 07, 2018 at 06:24:11PM -0800, Alexei Starovoitov wrote: > > How about: > > CONFIG_SPECTRE1_WORKAROUND_INDEX_MASK > > CONFIG_SPECTRE1_WORKAROUND_LOAD_FENCE > > INSTRUCTION_FENCE if anything. LFENCE for Intel (and now also for AMD as > per 0592b0bce169) is a misnomer, IFENCE would be a better name for it. Which in that context clearly talked about the config space and how to name the instruction semantics in light of the confusion of LFENCE and MFENCE opcodes on Intel and AMD CPUs... Also, those early reviews were fundamentally low level feedback related to the actual functionality of the barriers and their mapping to the hardware. But the fact is, the current series introduces an inconsistent barrier namespace extension of: barrier() barrier_data() mb() rmb() wmb() store_mb() read_barrier_depends() ... + ifence() + array_idx() + array_idx_mask() This isn't bikeshed painting: _ALL_ existing barrier API names have 'barrier' or its abbreviation 'mb' (memory barrier) somewhere in their names, which makes it pretty easy to recognize them at a glance. I'm giving you high level API naming feedback because we are now growing the size of the barrier API. array_idx() on the other hand is pretty much close to a 'worst possible' name: - it's named in an overly generic, opaque fashion - doesn't indicate it at all that it's a barrier for something ... and since we want all kernel developers to use these facilities correctly, we want the names to be good and suggestive as well. I'd accept pretty much anything else that adds 'barrier' or 'nospec' to the name: array_idx_barrier() or array_idx_nospec(). (I'm slightly leaning towards 'nospec' because it's more indicative of what is being done, and it also is what we do for get uaccess APIs.) ifence() is a similar departure from existing barrier naming nomenclature, and I'd accept pretty much any other variant: barrier_nospec() ifence_nospec() The kernel namespace cleanliness rules are clear and consistent, and there's nothing new about them: - the name of the API should unambiguously refer back to the API category. For barriers this common reference is 'barrier' or 'mb'. - use postfixes or prefixes consistently: pick one and don't mix them. If we go with a _nospec() variant for the uaccess API names then we should use a similar naming for array_idx() and for the new barrier as well - no mixing. > You can always follow on with a patch to fix up the names and placements to > your > liking. While they'll pick on my name choices, they won't pick on yours, > because > I simply can't be bothered to care about a bikeshed color at this point after > being bounced around for 5 revisions of this patch set. Sorry, this kind of dismissive and condescending attitude won't cut it. Thanks, Ingo
Re: [PATCH 20/21] Kbuild, lto: Add Link Time Optimization support
> > kallsyms failure: relative symbol value 0x8100 out of > range in relative mode > > I seem to get that all the time here, and have also disabled it for now, > but it sounds important (and breaks the build). Need to take a look at it. I had some patches that completely revamped kallsyms as part of the single pass linking, but I dropped them again because they still had too many issues. -Andi
Re: [PATCH v5 02/12] array_idx: sanitize speculative array de-references
On Sun, 28 Jan 2018, Dan Williams wrote:
> On Sun, Jan 28, 2018 at 12:55 AM, Ingo Molnar wrote:
> >> + */
> >> +#define array_idx(idx, sz) \
> >> +({ \
> >> + typeof(idx) _i = (idx); \
> >> + typeof(sz) _s = (sz); \
> >> + unsigned long _mask = array_idx_mask(_i, _s); \
> >> + \
> >> + BUILD_BUG_ON(sizeof(_i) > sizeof(long));\
> >> + BUILD_BUG_ON(sizeof(_s) > sizeof(long));\
> >> + \
> >> + _i &= _mask;\
> >> + _i; \
> >> +})
> >> +#endif /* __NOSPEC_H__ */
> >
> > For heaven's sake, please name a size variable as 'size', not 'sz'. We
> > don't have
> > a shortage of characters and can deobfuscate common primitives, can we?
> >
> > Also, beyond the nits, I also hate the namespace here. We have a new generic
> > header providing two new methods:
> >
> > #include
> >
> > array_idx_mask()
> > array_idx()
> >
> > which is then optimized for x86 in asm/barrier.h. That's already a
> > non-sequitor.
> >
> > Then we introduce uaccess API variants with a _nospec() postfix.
> >
> > Then we add ifence() to x86.
> >
> > There's no naming coherency to this.
>
> Ingo, I love you, but please take the incredulity down a bit,
> especially when I had 'nospec' in all the names in v1. Thomas, Peter,
> and Alexei wanted s/nospec_barrier/ifence/ and
Sorry, I never was involved in that discussion.
> s/array_idx_nospec/array_idx/. You can always follow on with a patch
> to fix up the names and placements to your liking. While they'll pick
> on my name choices, they won't pick on yours, because I simply can't
> be bothered to care about a bikeshed color at this point after being
> bounced around for 5 revisions of this patch set.
Oh well, we really need this kind of attitude right now. We are all fed up
with that mess, but Ingo and I care about the details, consistency and
general code quality beyond the current rush to get stuff solved. It's our
damned job as maintainers.
If you decide you don't care anymore, please let me know, so I can try to
free up some cycles to pick up the stuff from where you decided to dump it.
Thanks,
tglx
[PATCH 1/3] x86/entry/64: Remove the SYSCALL64 fast path
The SYCALLL64 fast path was a nice, if small, optimization back in the good old days when syscalls were actually reasonably fast. Now we have PTI to slow everything down, and indirect branches are verboten, making everything messier. The retpoline code in the fast path was particularly nasty. Just get rid of the fast path. The slow path is barely slower. Signed-off-by: Andy Lutomirski --- This isn't quite identical to Linus' patch. I cleaned up the SYSCALL64 entry code to use all pushes rather than pushing all but 6 regs and moving the rest. arch/x86/entry/entry_64.S | 127 +++- arch/x86/entry/syscall_64.c | 7 +-- 2 files changed, 9 insertions(+), 125 deletions(-) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index 4f8e1d35a97c..7fd98c8b5907 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -236,91 +236,20 @@ GLOBAL(entry_SYSCALL_64_after_hwframe) pushq %r9 /* pt_regs->r9 */ pushq %r10/* pt_regs->r10 */ pushq %r11/* pt_regs->r11 */ - sub $(6*8), %rsp/* pt_regs->bp, bx, r12-15 not saved */ - UNWIND_HINT_REGS extra=0 - - TRACE_IRQS_OFF - - /* -* If we need to do entry work or if we guess we'll need to do -* exit work, go straight to the slow path. -*/ - movqPER_CPU_VAR(current_task), %r11 - testl $_TIF_WORK_SYSCALL_ENTRY|_TIF_ALLWORK_MASK, TASK_TI_flags(%r11) - jnz entry_SYSCALL64_slow_path - -entry_SYSCALL_64_fastpath: - /* -* Easy case: enable interrupts and issue the syscall. If the syscall -* needs pt_regs, we'll call a stub that disables interrupts again -* and jumps to the slow path. -*/ - TRACE_IRQS_ON - ENABLE_INTERRUPTS(CLBR_NONE) -#if __SYSCALL_MASK == ~0 - cmpq$__NR_syscall_max, %rax -#else - andl$__SYSCALL_MASK, %eax - cmpl$__NR_syscall_max, %eax -#endif - ja 1f /* return -ENOSYS (already in pt_regs->ax) */ - movq%r10, %rcx - - /* -* This call instruction is handled specially in stub_ptregs_64. -* It might end up jumping to the slow path. If it jumps, RAX -* and all argument registers are clobbered. -*/ -#ifdef CONFIG_RETPOLINE - movqsys_call_table(, %rax, 8), %rax - call__x86_indirect_thunk_rax -#else - call*sys_call_table(, %rax, 8) -#endif -.Lentry_SYSCALL_64_after_fastpath_call: - - movq%rax, RAX(%rsp) -1: + pushq %rbx/* pt_regs->rbx */ + pushq %rbp/* pt_regs->rbp */ + pushq %r12/* pt_regs->r12 */ + pushq %r13/* pt_regs->r13 */ + pushq %r14/* pt_regs->r14 */ + pushq %r15/* pt_regs->r15 */ + UNWIND_HINT_REGS - /* -* If we get here, then we know that pt_regs is clean for SYSRET64. -* If we see that no exit work is required (which we are required -* to check with IRQs off), then we can go straight to SYSRET64. -*/ - DISABLE_INTERRUPTS(CLBR_ANY) TRACE_IRQS_OFF - movqPER_CPU_VAR(current_task), %r11 - testl $_TIF_ALLWORK_MASK, TASK_TI_flags(%r11) - jnz 1f - LOCKDEP_SYS_EXIT - TRACE_IRQS_ON /* user mode is traced as IRQs on */ - movqRIP(%rsp), %rcx - movqEFLAGS(%rsp), %r11 - addq$6*8, %rsp /* skip extra regs -- they were preserved */ - UNWIND_HINT_EMPTY - jmp .Lpop_c_regs_except_rcx_r11_and_sysret - -1: - /* -* The fast path looked good when we started, but something changed -* along the way and we need to switch to the slow path. Calling -* raise(3) will trigger this, for example. IRQs are off. -*/ - TRACE_IRQS_ON - ENABLE_INTERRUPTS(CLBR_ANY) - SAVE_EXTRA_REGS - movq%rsp, %rdi - callsyscall_return_slowpath /* returns with IRQs disabled */ - jmp return_from_SYSCALL_64 - -entry_SYSCALL64_slow_path: /* IRQs are off. */ - SAVE_EXTRA_REGS movq%rsp, %rdi calldo_syscall_64 /* returns with IRQs disabled */ -return_from_SYSCALL_64: TRACE_IRQS_IRETQ/* we're about to change IF */ /* @@ -393,7 +322,6 @@ syscall_return_via_sysret: /* rcx and r11 are already restored (see code above) */ UNWIND_HINT_EMPTY POP_EXTRA_REGS -.Lpop_c_regs_except_rcx_r11_and_sysret: popq%rsi/* skip r11 */ popq%r10 popq%r9 @@ -424,47 +352,6 @@ syscall_return_via_sysret: USERGS_SYSRET64 END(entry_SYSCALL_64)
[PATCH 3/3] syscalls: Add a bit of documentation to __SYSCALL_DEFINE
__SYSCALL_DEFINE is rather magical. Add a bit of documentation. Signed-off-by: Andy Lutomirski --- include/linux/syscalls.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h index a78186d826d7..d3f244a447c5 100644 --- a/include/linux/syscalls.h +++ b/include/linux/syscalls.h @@ -207,6 +207,16 @@ static inline int is_syscall_trace_event(struct trace_event_call *tp_event) __SYSCALL_DEFINEx(x, sname, __VA_ARGS__) #define __PROTECT(...) asmlinkage_protect(__VA_ARGS__) + +/* + * For a syscall like long foo(void *a, long long b), this defines: + * + * static inline long SYSC_foo(void *a, long long b): the actual code + * + * asmlinkage long SyS_foo(long a, long long b): wrapper that calls SYSC_foo + * + * asmlinkage long sys_foo(void *a, long long b): alias of SyS_foo + */ #define __SYSCALL_DEFINEx(x, name, ...) \ asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \ __attribute__((alias(__stringify(SyS##name; \ -- 2.14.3
[PATCH 0/3] x86/pti-ish syscall cleanups
Three changes in here: - Get rid of the SYSCALL64 fast path as suggested by Linus. - Move TS_COMPAT into the same cacheline as thread_info::flags, also suggested by Linus. - Document SYSCALL_DEFINE a bit better. Andy Lutomirski (3): x86/entry/64: Remove the SYSCALL64 fast path x86/asm: Move 'status' from thread_struct to thread_info syscalls: Add a bit of documentation to __SYSCALL_DEFINE arch/x86/entry/common.c| 4 +- arch/x86/entry/entry_64.S | 127 ++--- arch/x86/entry/syscall_64.c| 7 +- arch/x86/include/asm/processor.h | 2 - arch/x86/include/asm/syscall.h | 6 +- arch/x86/include/asm/thread_info.h | 3 +- arch/x86/kernel/process_64.c | 4 +- arch/x86/kernel/ptrace.c | 2 +- arch/x86/kernel/signal.c | 2 +- include/linux/syscalls.h | 10 +++ 10 files changed, 30 insertions(+), 137 deletions(-) -- 2.14.3
[PATCH 2/3] x86/asm: Move 'status' from thread_struct to thread_info
The TS_COMPAT bit is very hot and is accessed from code paths that
mostly also touch thread_info::flags. Move it into struct
thread_info to improve cache locality.
The only reason it was in thread_struct is that there was a brief
period during which we didn't allow arch-specific fields in struct
thread_info.
Linus suggested further changing:
ti->status &= ~(TS_COMPAT|TS_I386_REGS_POKED);
to:
if (unlikely(ti->status & (TS_COMPAT|TS_I386_REGS_POKED)))
ti->status &= ~(TS_COMPAT|TS_I386_REGS_POKED);
on the theory that frequently dirtying the cacheline even in pure
64-bit code that never needs to modify status hurts performance.
That could be a reasonable followup patch, but I suspect it matters
less on top of this patch.
Suggested-by: Linus Torvalds
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/common.c| 4 ++--
arch/x86/include/asm/processor.h | 2 --
arch/x86/include/asm/syscall.h | 6 +++---
arch/x86/include/asm/thread_info.h | 3 ++-
arch/x86/kernel/process_64.c | 4 ++--
arch/x86/kernel/ptrace.c | 2 +-
arch/x86/kernel/signal.c | 2 +-
7 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index d7d3cc24baf4..99081340d19a 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -206,7 +206,7 @@ __visible inline void prepare_exit_to_usermode(struct
pt_regs *regs)
* special case only applies after poking regs and before the
* very next return to user mode.
*/
- current->thread.status &= ~(TS_COMPAT|TS_I386_REGS_POKED);
+ ti->status &= ~(TS_COMPAT|TS_I386_REGS_POKED);
#endif
user_enter_irqoff();
@@ -304,7 +304,7 @@ static __always_inline void do_syscall_32_irqs_on(struct
pt_regs *regs)
unsigned int nr = (unsigned int)regs->orig_ax;
#ifdef CONFIG_IA32_EMULATION
- current->thread.status |= TS_COMPAT;
+ ti->status |= TS_COMPAT;
#endif
if (READ_ONCE(ti->flags) & _TIF_WORK_SYSCALL_ENTRY) {
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index d3a67fba200a..99799fbd0f7e 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -460,8 +460,6 @@ struct thread_struct {
unsigned short gsindex;
#endif
- u32 status; /* thread synchronous flags */
-
#ifdef CONFIG_X86_64
unsigned long fsbase;
unsigned long gsbase;
diff --git a/arch/x86/include/asm/syscall.h b/arch/x86/include/asm/syscall.h
index e3c95e8e61c5..03eedc21246d 100644
--- a/arch/x86/include/asm/syscall.h
+++ b/arch/x86/include/asm/syscall.h
@@ -60,7 +60,7 @@ static inline long syscall_get_error(struct task_struct *task,
* TS_COMPAT is set for 32-bit syscall entries and then
* remains set until we return to user mode.
*/
- if (task->thread.status & (TS_COMPAT|TS_I386_REGS_POKED))
+ if (task->thread_info.status & (TS_COMPAT|TS_I386_REGS_POKED))
/*
* Sign-extend the value so (int)-EFOO becomes (long)-EFOO
* and will match correctly in comparisons.
@@ -116,7 +116,7 @@ static inline void syscall_get_arguments(struct task_struct
*task,
unsigned long *args)
{
# ifdef CONFIG_IA32_EMULATION
- if (task->thread.status & TS_COMPAT)
+ if (task->thread_info.status & TS_COMPAT)
switch (i) {
case 0:
if (!n--) break;
@@ -177,7 +177,7 @@ static inline void syscall_set_arguments(struct task_struct
*task,
const unsigned long *args)
{
# ifdef CONFIG_IA32_EMULATION
- if (task->thread.status & TS_COMPAT)
+ if (task->thread_info.status & TS_COMPAT)
switch (i) {
case 0:
if (!n--) break;
diff --git a/arch/x86/include/asm/thread_info.h
b/arch/x86/include/asm/thread_info.h
index 0022821a..eda3b6823ca4 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -55,6 +55,7 @@ struct task_struct;
struct thread_info {
unsigned long flags; /* low level flags */
+ u32 status; /* thread synchronous flags */
};
#define INIT_THREAD_INFO(tsk) \
@@ -221,7 +222,7 @@ static inline int arch_within_stack_frames(const void *
const stack,
#define in_ia32_syscall() true
#else
#define in_ia32_syscall() (IS_ENABLED(CONFIG_IA32_EMULATION) && \
- current->thread.status & TS_COMPAT)
+ current_thread_info()->status & TS_COMPAT)
#endif
/*
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index c75466232016..9eb448c7859d 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -557,7 +557,7 @@ static void
[PATCH] btrfs: fix err_cast.cocci warnings
From: Fengguang Wu
fs/btrfs/volumes.c:742:10-17: WARNING: ERR_CAST can be used with fs_devices
Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...))
Generated by: scripts/coccinelle/api/err_cast.cocci
Fixes: bf155c98d312 ("btrfs: get device pointer from device_list_add()")
CC: Anand Jain
Signed-off-by: Fengguang Wu
---
volumes.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -739,7 +739,7 @@ static noinline struct btrfs_device *dev
if (!fs_devices) {
fs_devices = alloc_fs_devices(disk_super->fsid);
if (IS_ERR(fs_devices))
- return ERR_PTR(PTR_ERR(fs_devices));
+ return ERR_CAST(fs_devices);
list_add(&fs_devices->list, &fs_uuids);
RE: [PATCH] IB/cxgb3: remove cxio_dbg.c
>
> cxio_dbg.c is uncompiled since commit 2b540355cd2f ("RDMA/cxgb3:
> cleanups")
> 10 years after, we could remove it.
>
> Signed-off-by: Corentin Labbe
Acked-by: Steve Wise
Re: [PATCH 1/3] x86/entry/64: Remove the SYSCALL64 fast path
* Andy Lutomirski wrote: > The SYCALLL64 fast path was a nice, if small, optimization back in > the good old days when syscalls were actually reasonably fast. Now > we have PTI to slow everything down, and indirect branches are > verboten, making everything messier. The retpoline code in the fast > path was particularly nasty. > > Just get rid of the fast path. The slow path is barely slower. > > Signed-off-by: Andy Lutomirski > --- > > This isn't quite identical to Linus' patch. I cleaned up the > SYSCALL64 entry code to use all pushes rather than pushing all but 6 > regs and moving the rest. Hm, could we please have this in two parts please, out of general paranoia? One patch doing the easy fast path removal, the other doing the mov/push conversion? Bisectability, reviewability and all that. Exact same patch result. Thanks, Ingo
Re: [PATCH 2/3] x86/asm: Move 'status' from thread_struct to thread_info
* Andy Lutomirski wrote: > The TS_COMPAT bit is very hot and is accessed from code paths that > mostly also touch thread_info::flags. Move it into struct > thread_info to improve cache locality. > > The only reason it was in thread_struct is that there was a brief > period during which we didn't allow arch-specific fields in struct > thread_info. > > Linus suggested further changing: > > ti->status &= ~(TS_COMPAT|TS_I386_REGS_POKED); > > to: > > if (unlikely(ti->status & (TS_COMPAT|TS_I386_REGS_POKED))) > ti->status &= ~(TS_COMPAT|TS_I386_REGS_POKED); > > on the theory that frequently dirtying the cacheline even in pure > 64-bit code that never needs to modify status hurts performance. > That could be a reasonable followup patch, but I suspect it matters > less on top of this patch. > > Suggested-by: Linus Torvalds > Signed-off-by: Andy Lutomirski > --- > arch/x86/entry/common.c| 4 ++-- > arch/x86/include/asm/processor.h | 2 -- > arch/x86/include/asm/syscall.h | 6 +++--- > arch/x86/include/asm/thread_info.h | 3 ++- > arch/x86/kernel/process_64.c | 4 ++-- > arch/x86/kernel/ptrace.c | 2 +- > arch/x86/kernel/signal.c | 2 +- > 7 files changed, 11 insertions(+), 12 deletions(-) Reviewed-by: Ingo Molnar Thanks, Ingo
Re: [PATCH 3/3] syscalls: Add a bit of documentation to __SYSCALL_DEFINE
On Sun, Jan 28, 2018 at 10:38 AM, Andy Lutomirski wrote:
> __SYSCALL_DEFINE is rather magical. Add a bit of documentation.
Ack.
Is that "long long" part of the example on purpose? Because that's
likely the only really nasty part about any ptregs wrapper: some
arguments aren't _one_ register, they are two. And "long long" is the
simplest example, even though in practice the type is most often
"loff_t".
You won't see this on 64-bit architectures, but it's visible on 32-bit ones.
We may have to do wrappers for those, and error out for 'long long'.
We already do that for some cases, for compat system calls. See for
example
COMPAT_SYSCALL_DEFINE5(preadv, compat_ulong_t, fd,
const struct compat_iovec __user *,vec,
compat_ulong_t, vlen, u32, pos_low, u32, pos_high)
{
loff_t pos = ((loff_t)pos_high << 32) | pos_low;
return do_compat_preadv64(fd, vec, vlen, pos, 0);
}
where we have the issue of a 64-bit value being split over two
registers even on 64-bit, due to it being a compat interface for 32
bit.
But if we pick up the values by hand from ptregs in a wrapper, we'll
have this issue even for native calls on 32-bit.
Linus
Re: [PATCH 2/3] x86/asm: Move 'status' from thread_struct to thread_info
On Sun, Jan 28, 2018 at 10:38 AM, Andy Lutomirski wrote: > > Linus suggested further changing: > > ti->status &= ~(TS_COMPAT|TS_I386_REGS_POKED); > > to: > > if (unlikely(ti->status & (TS_COMPAT|TS_I386_REGS_POKED))) > ti->status &= ~(TS_COMPAT|TS_I386_REGS_POKED); > > on the theory that frequently dirtying the cacheline even in pure > 64-bit code that never needs to modify status hurts performance. > That could be a reasonable followup patch, but I suspect it matters > less on top of this patch. Ack, that should be done separately from the movement anyway. And yes, it's possible that once it's in the same cacheline with the thread flags, you can't even see the issue anyway. Although I *think* all those early fields are normally mostly read-only, so that "read before clear" may end up being a good idea regardless. Linus
Re: [PATCH 3/3] syscalls: Add a bit of documentation to __SYSCALL_DEFINE
* Andy Lutomirski wrote:
> __SYSCALL_DEFINE is rather magical. Add a bit of documentation.
>
> Signed-off-by: Andy Lutomirski
> ---
> include/linux/syscalls.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> index a78186d826d7..d3f244a447c5 100644
> --- a/include/linux/syscalls.h
> +++ b/include/linux/syscalls.h
> @@ -207,6 +207,16 @@ static inline int is_syscall_trace_event(struct
> trace_event_call *tp_event)
> __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
>
> #define __PROTECT(...) asmlinkage_protect(__VA_ARGS__)
> +
> +/*
> + * For a syscall like long foo(void *a, long long b), this defines:
> + *
> + * static inline long SYSC_foo(void *a, long long b): the actual code
> + *
> + * asmlinkage long SyS_foo(long a, long long b): wrapper that calls SYSC_foo
> + *
> + * asmlinkage long sys_foo(void *a, long long b): alias of SyS_foo
> + */
Nit, would it be more readable to write this as pseudo-code, i.e. something
like:
/*
* For a syscall like long foo(void *a, long long b), this defines:
*
* static inline long SYSC_foo(void *a, long long b) { /* the actual code
following */ }
*
* asmlinkage long SyS_foo(long a, long long b) { /* wrapper that calls
SYSC_foo() */ }
* asmlinkage long sys_foo(void *a, long long b); /* as GCC alias of SyS_foo()
*/
*/
Also, I wanted to suggest to also document that in practice the three methods
map
to the very same function in the end, with the SYSC_ variant being eliminated
due
to inlining - but when double checking an x86-64 defconfig that does not appear
to
be so for all system calls:
triton:~/tip> grep accept4 System.map
8170d710 t SYSC_accept4
8170f940 T SyS_accept4
8170f940 T sys_accept4
While for others there's just 2:
triton:~/tip> grep sched_getattr System.map
8107b9a0 T SyS_sched_getattr
8107b9a0 T sys_sched_getattr
The only difference appears to be that accept4() is called internally within
the
kernel, by socketcall:
SYSCALL_DEFINE3(accept, int, fd, struct sockaddr __user *, upeer_sockaddr,
int __user *, upeer_addrlen)
{
return sys_accept4(fd, upeer_sockaddr, upeer_addrlen, 0);
}
But why does that result in SYSC_accept4() being a different symbol?
The difference between the two appears to be rather dumb as well:
8170f940 :
8170f940: e9 cb dd ff ff jmpq 8170d710
Using GCC 7.2.0.
What am I missing?
Thanks,
Ingo
Re: selftests/x86/fsgsbase_64 test problem
On Fri, Jan 26, 2018 at 2:42 PM, Andy Lutomirski wrote: > On Fri, Jan 26, 2018 at 2:38 PM, Andy Lutomirski wrote: >> On Fri, Jan 26, 2018 at 11:46 AM, Andy Lutomirski wrote: >>> On Fri, Jan 26, 2018 at 10:59 AM, Andy Lutomirski wrote: On Fri, Jan 26, 2018 at 8:22 AM, Andy Lutomirski wrote: > On Fri, Jan 26, 2018 at 7:36 AM, Dan Rue wrote: >> >> We've noticed that fsgsbase_64 can fail intermittently with the >> following error: >> >> [RUN] ARCH_SET_GS(0x0) and clear gs, then schedule to 0x1 >> Before schedule, set selector to 0x1 >> other thread: ARCH_SET_GS(0x1) -- sel is 0x0 >> [FAIL] GS/BASE changed from 0x1/0x0 to 0x0/0x0 >> >> This can be reliably reproduced by running fsgsbase_64 in a loop. i.e. >> >> for i in $(seq 1 1); do ./fsgsbase_64 || break; done >> >> This problem isn't new - I've reproduced it on latest mainline and every >> release going back to v4.12 (I did not try earlier). This was tested on >> a Supermicro board with a Xeon E3-1220 as well as an Intel Nuc with an >> i3-5010U. >> > > Hmm, I can reproduce it, too. I'll look in a bit. I'm triggering a different error, and I think what's going on is that the kernel doesn't currently re-save GSBASE when a task switches out and that task has save gsbase != 0 and in-register GS == 0. This is arguably a bug, but it's not an infoleak, and fixing it could be a wee bit expensive. I'm not sure what, if anything, to do about this. I suppose I could add some gross perf hackery to the test to detect this case and suppress the error. I can also trigger the problem you're seeing, and I don't know what's up. It may be related to and old problem I've seen that causes signal delivery to sometimes corrupt %gs. It's deterministic, but it depends in some odd way on register state. I can currently reproduce that issue 100% of the time, and I'm trying to see if I can figure out what's happening. >>> >>> I think it's a CPU bug, and I'm a bit mystified. I can trigger the >>> following, plausibly related issue: >>> >>> Write a program that writes %gs = 1. >>> Run that program under gdb >>> break in which %gs == 1 >>> display/x $gs >>> si >>> >>> Under QEMU TCG, gs stays equal to 1. On native or KVM, on Skylake, it >>> changes to 0. >>> >>> On KVM or native, I do not observe do_debug getting called with %gs == >>> 1. On TCG, I do. I don't think that's precisely the problem that's >>> causing the test to fail, since the test doesn't use TF or ptrace, but >>> I wouldn't be shocked if it's related. >>> >>> hpa, any insight? >>> >>> (NB: if you want to play with this as I've described it, you may need >>> to make invalid_selector() in ptrace.c always return false. The >>> current implementation is too strict and causes problems.) >> >> Much simpler test. Run the attached program (gs1). It more or less >> just sets %gs to 1 and spins until it stops being 1. Do it on a >> kernel with the attached patch applied. I see stuff like this: >> >> # ./gs1 >> PID = 129 >> [ 15.703015] pid 129 saved gs = 1 >> [ 15.703517] pid 129 loaded gs = 1 >> [ 15.703973] pid 129 prepare_exit_to_usermode: gs = 1 >> ax = 0, cx = 0, dx = 0 >> >> So we're interrupting the program, switching out, switching back in, >> setting %gs to 1, observing that %gs is *still* 1 in >> prepare_exit_to_usermode(), returning to usermode, and observing %gs >> == 0. >> >> Presumably what's happening is that the IRET microcode matches the >> SDM's pseudocode, which says: >> >> RETURN-TO-OUTER-PRIVILEGE-LEVEL: >> ... >> FOR each SegReg in (ES, FS, GS, and DS) >> DO >> tempDesc ← descriptor cache for SegReg (* hidden part of segment >> register *) >> IF tempDesc(DPL) < CPL AND tempDesc(Type) is data or non-conforming code >> THEN (* Segment register invalid *) >> SegReg ← NULL; >> FI; >> OD; >> >> But this is very odd. The actual permission checks (in the docs for MOV) >> are: >> >> IF DS, ES, FS, or GS is loaded with non-NULL selector >> THEN >> IF segment selector index is outside descriptor table limits >> or segment is not a data or readable code segment >> or ((segment is a data or nonconforming code segment) >> or ((RPL > DPL) and (CPL > DPL)) >> THEN #GP(selector); FI; >> >> >> This makes no sense. This says that the data segments cannot be >> loaded with MOV. Empirically, it seems like MOV works if CPL <= DPL >> and RPL <= DPL, but I haven't checked that hard. > > Surely Intel meant: > > ... or ((segment is a data segment or nonconforming code segment) and > ((RPL > DPL) or (CPL > DPL)) > > This would be consistent with the AMD APM #GP condition of "The DS, > ES, FS, or GS register was loaded and the segment pointed to was a > data or non-conforming code segment, but the RPL or CPL was greater > than the DPL." > >> >
Re: selftests/x86/fsgsbase_64 test problem
On Fri, Jan 26, 2018 at 2:56 PM, Borislav Petkov wrote: > On Fri, Jan 26, 2018 at 02:38:28PM -0800, Andy Lutomirski wrote: >> Borislav, any chance you could run the attached program on an AMD >> machine to see what it does? > > [boris@pd: /tmp> ./gs1 > PID = 3420 > ax = 0, cx = 0, dx = 0 > > This is on 4.15-rc7-ish + tip/master from 2 wks ago. Phooey :(
[PATCH] x86: vmx: Allow direct access to MSR_IA32_SPEC_CTRL
Add direct access to MSR_IA32_SPEC_CTRL for guests. This is needed for guests
that will only mitigate Spectre V2 through IBRS+IBPB and will not be using a
retpoline+IBPB based approach.
To avoid the overhead of atomically saving and restoring the MSR_IA32_SPEC_CTRL
for guests that do not actually use the MSR, only add_atomic_switch_msr when a
non-zero is written to it.
Cc: Asit Mallick
Cc: Arjan Van De Ven
Cc: Dave Hansen
Cc: Andi Kleen
Cc: Andrea Arcangeli
Cc: Linus Torvalds
Cc: Tim Chen
Cc: Thomas Gleixner
Cc: Dan Williams
Cc: Jun Nakajima
Cc: Paolo Bonzini
Cc: David Woodhouse
Cc: Greg KH
Cc: Andy Lutomirski
Signed-off-by: KarimAllah Ahmed
Signed-off-by: Ashok Raj
---
arch/x86/kvm/cpuid.c | 4 +++-
arch/x86/kvm/cpuid.h | 1 +
arch/x86/kvm/vmx.c | 63
3 files changed, 67 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 0099e10..dc78095 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -70,6 +70,7 @@ u64 kvm_supported_xcr0(void)
/* These are scattered features in cpufeatures.h. */
#define KVM_CPUID_BIT_AVX512_4VNNIW 2
#define KVM_CPUID_BIT_AVX512_4FMAPS 3
+#define KVM_CPUID_BIT_SPEC_CTRL 26
#define KF(x) bit(KVM_CPUID_BIT_##x)
int kvm_update_cpuid(struct kvm_vcpu *vcpu)
@@ -392,7 +393,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2
*entry, u32 function,
/* cpuid 7.0.edx*/
const u32 kvm_cpuid_7_0_edx_x86_features =
- KF(AVX512_4VNNIW) | KF(AVX512_4FMAPS);
+ KF(AVX512_4VNNIW) | KF(AVX512_4FMAPS) | \
+ (boot_cpu_has(X86_FEATURE_SPEC_CTRL) ? KF(SPEC_CTRL) : 0);
/* all calls to cpuid_count() should be made on the same cpu */
get_cpu();
diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h
index cdc70a3..dcfe227 100644
--- a/arch/x86/kvm/cpuid.h
+++ b/arch/x86/kvm/cpuid.h
@@ -54,6 +54,7 @@ static const struct cpuid_reg reverse_cpuid[] = {
[CPUID_8000_000A_EDX] = {0x800a, 0, CPUID_EDX},
[CPUID_7_ECX] = { 7, 0, CPUID_ECX},
[CPUID_8000_0007_EBX] = {0x8007, 0, CPUID_EBX},
+ [CPUID_7_EDX] = { 7, 0, CPUID_EDX},
};
static __always_inline struct cpuid_reg x86_feature_cpuid(unsigned x86_feature)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index aa8638a..1b743a0 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -920,6 +920,9 @@ static void vmx_set_nmi_mask(struct kvm_vcpu *vcpu, bool
masked);
static bool nested_vmx_is_page_fault_vmexit(struct vmcs12 *vmcs12,
u16 error_code);
static void vmx_update_msr_bitmap(struct kvm_vcpu *vcpu);
+static void __always_inline vmx_disable_intercept_for_msr(unsigned long
*msr_bitmap,
+ u32 msr, int type);
+
static DEFINE_PER_CPU(struct vmcs *, vmxarea);
static DEFINE_PER_CPU(struct vmcs *, current_vmcs);
@@ -2007,6 +2010,28 @@ static void add_atomic_switch_msr(struct vcpu_vmx *vmx,
unsigned msr,
m->host[i].value = host_val;
}
+/* do not touch guest_val and host_val if the msr is not found */
+static int read_atomic_switch_msr(struct vcpu_vmx *vmx, unsigned msr,
+ u64 *guest_val, u64 *host_val)
+{
+ unsigned i;
+ struct msr_autoload *m = &vmx->msr_autoload;
+
+ for (i = 0; i < m->nr; ++i)
+ if (m->guest[i].index == msr)
+ break;
+
+ if (i == m->nr)
+ return 1;
+
+ if (guest_val)
+ *guest_val = m->guest[i].value;
+ if (host_val)
+ *host_val = m->host[i].value;
+
+ return 0;
+}
+
static bool update_transition_efer(struct vcpu_vmx *vmx, int efer_offset)
{
u64 guest_efer = vmx->vcpu.arch.efer;
@@ -3203,7 +3228,9 @@ static inline bool vmx_feature_control_msr_valid(struct
kvm_vcpu *vcpu,
*/
static int vmx_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
{
+ u64 spec_ctrl = 0;
struct shared_msr_entry *msr;
+ struct vcpu_vmx *vmx = to_vmx(vcpu);
switch (msr_info->index) {
#ifdef CONFIG_X86_64
@@ -3223,6 +3250,19 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct
msr_data *msr_info)
case MSR_IA32_TSC:
msr_info->data = guest_read_tsc(vcpu);
break;
+ case MSR_IA32_SPEC_CTRL:
+ if (!msr_info->host_initiated &&
+ !guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL))
+ return 1;
+
+ /*
+* If the MSR is not in the atomic list yet, then it was never
+* written to. So the MSR value will be '0'.
+*/
+ read_atomic_switch_msr(vmx, MSR_IA32_SPEC_CTRL, &spec_ctrl,
NULL);
+
+ msr_info->data = spec_ctrl;
+ break;
case MSR_IA32_SYSENTER_CS:
[PATCH] media: mantis: remove mantis_vp3028.c/mantis_vp3028.h
Thoses files are unused since commit b3b961448f70 ("V4L/DVB (13795):
[Mantis/Hopper] Code overhaul, add Hopper devices into the PCI ID list")
8 year after, we could remove it.
Signed-off-by: Corentin Labbe
---
drivers/media/pci/mantis/mantis_vp3028.c | 38
drivers/media/pci/mantis/mantis_vp3028.h | 33 ---
2 files changed, 71 deletions(-)
delete mode 100644 drivers/media/pci/mantis/mantis_vp3028.c
delete mode 100644 drivers/media/pci/mantis/mantis_vp3028.h
diff --git a/drivers/media/pci/mantis/mantis_vp3028.c
b/drivers/media/pci/mantis/mantis_vp3028.c
deleted file mode 100644
index 4155c838a18a..
--- a/drivers/media/pci/mantis/mantis_vp3028.c
+++ /dev/null
@@ -1,38 +0,0 @@
-/*
- Mantis VP-3028 driver
-
- Copyright (C) Manu Abraham (abraham.m...@gmail.com)
-
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
- (at your option) any later version.
-
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-*/
-
-#include "mantis_common.h"
-#include "mantis_vp3028.h"
-
-struct zl10353_config mantis_vp3028_config = {
- .demod_address = 0x0f,
-};
-
-#define MANTIS_MODEL_NAME "VP-3028"
-#define MANTIS_DEV_TYPE"DVB-T"
-
-struct mantis_hwconfig vp3028_mantis_config = {
- .model_name = MANTIS_MODEL_NAME,
- .dev_type = MANTIS_DEV_TYPE,
- .ts_size= MANTIS_TS_188,
- .baud_rate = MANTIS_BAUD_9600,
- .parity = MANTIS_PARITY_NONE,
- .bytes = 0,
-};
diff --git a/drivers/media/pci/mantis/mantis_vp3028.h
b/drivers/media/pci/mantis/mantis_vp3028.h
deleted file mode 100644
index 34130d29e0aa..
--- a/drivers/media/pci/mantis/mantis_vp3028.h
+++ /dev/null
@@ -1,33 +0,0 @@
-/*
- Mantis VP-3028 driver
-
- Copyright (C) Manu Abraham (abraham.m...@gmail.com)
-
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
- (at your option) any later version.
-
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-*/
-
-#ifndef __MANTIS_VP3028_H
-#define __MANTIS_VP3028_H
-
-#include
-#include "mantis_common.h"
-#include "zl10353.h"
-
-#define MANTIS_VP_3028_DVB_T 0x0028
-
-extern struct zl10353_config mantis_vp3028_config;
-extern struct mantis_hwconfig vp3028_mantis_config;
-
-#endif /* __MANTIS_VP3028_H */
--
2.13.6
Re: [PATCH 1/2 v2] tpm: cmd_ready command can be issued only after granting locality
On Sun, Jan 28, 2018 at 09:51:00AM +0200, Tomas Winkler wrote:
> diff --git a/include/linux/tpm.h b/include/linux/tpm.h
> index bcdd3790e94d..06639fb6ab85 100644
> +++ b/include/linux/tpm.h
> @@ -44,7 +44,7 @@ struct tpm_class_ops {
> bool (*update_timeouts)(struct tpm_chip *chip,
> unsigned long *timeout_cap);
> int (*request_locality)(struct tpm_chip *chip, int loc);
> - void (*relinquish_locality)(struct tpm_chip *chip, int loc);
> + int (*relinquish_locality)(struct tpm_chip *chip, int loc);
This seems wrong.. What is the core code supposed to do if relinquish
fails?
Just returning an error code from transmit doesn't really do anything
helpful from a broad subsytem perspective.
I think if a driver can fail reliquish then it needs some kind of
strategy to recover.
Suggest trying the reliquish again on every next request until
success, otherwise fail request locality, potentially permanently.
Jason
