[PATCH] net: systemport: Fix memleak in bcm_sysport_probe
When devm_kcalloc() fails, dev should be freed just
like what we've done in the subsequent error paths.
Fixes: 7b78be48a8eb6 ("net: systemport: Dynamically allocate number of TX
rings")
Signed-off-by: Dinghao Liu
---
drivers/net/ethernet/broadcom/bcmsysport.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c
b/drivers/net/ethernet/broadcom/bcmsysport.c
index dfed9ade6950..0762d5d1a810 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -2491,8 +2491,10 @@ static int bcm_sysport_probe(struct platform_device
*pdev)
priv->tx_rings = devm_kcalloc(>dev, txq,
sizeof(struct bcm_sysport_tx_ring),
GFP_KERNEL);
- if (!priv->tx_rings)
- return -ENOMEM;
+ if (!priv->tx_rings) {
+ ret = -ENOMEM;
+ goto err_free_netdev;
+ }
priv->is_lite = params->is_lite;
priv->num_rx_desc_words = params->num_rx_desc_words;
--
2.17.1
Re: [RESEND PATCH v3 7/8] mtd: spi-nor: Convert cadence-quadspi to use spi-mem framework
On 01.06.20 09:04, Vignesh Raghavendra wrote:
> From: Ramuthevar Vadivel Murugan
>
> Move cadence-quadspi driver to use spi-mem framework. This is required
> to make the driver support for SPI NAND flashes in future.
>
> Driver is feature compliant with existing SPI NOR version.
>
> Signed-off-by: Ramuthevar Vadivel Murugan
>
> Signed-off-by: Vignesh Raghavendra
> Reviewed-by: Tudor Ambarus
> ---
> .../mtd/spi-nor/controllers/cadence-quadspi.c | 476 +++---
> 1 file changed, 191 insertions(+), 285 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
> b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
> index 6b1cbad25e3f6..c12a1c0191b92 100644
> --- a/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
> +++ b/drivers/mtd/spi-nor/controllers/cadence-quadspi.c
> @@ -3,6 +3,8 @@
> * Driver for Cadence QSPI Controller
> *
> * Copyright Altera Corporation (C) 2012-2014. All rights reserved.
> + * Copyright Intel Corporation (C) 2019-2020. All rights reserved.
> + * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com
> */
> #include
> #include
> @@ -17,9 +19,6 @@
> #include
> #include
> #include
> -#include
> -#include
> -#include
> #include
> #include
> #include
> @@ -27,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #define CQSPI_NAME "cadence-qspi"
> @@ -36,16 +36,12 @@
> #define CQSPI_NEEDS_WR_DELAY BIT(0)
> #define CQSPI_DISABLE_DAC_MODE BIT(1)
>
> -/* Capabilities mask */
> -#define CQSPI_BASE_HWCAPS_MASK \
> - (SNOR_HWCAPS_READ | SNOR_HWCAPS_READ_FAST | \
> - SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 | \
> - SNOR_HWCAPS_PP)
> +/* Capabilities */
> +#define CQSPI_SUPPORTS_OCTAL BIT(0)
>
> struct cqspi_st;
>
> struct cqspi_flash_pdata {
> - struct spi_nor nor;
> struct cqspi_st *cqspi;
> u32 clk_rate;
> u32 read_delay;
> @@ -57,8 +53,6 @@ struct cqspi_flash_pdata {
> u8 addr_width;
> u8 data_width;
> u8 cs;
> - boolregistered;
> - booluse_direct_mode;
> };
>
> struct cqspi_st {
> @@ -71,7 +65,6 @@ struct cqspi_st {
> void __iomem*ahb_base;
> resource_size_t ahb_size;
> struct completion transfer_complete;
> - struct mutexbus_mutex;
>
> struct dma_chan *rx_chan;
> struct completion rx_dma_complete;
> @@ -85,6 +78,7 @@ struct cqspi_st {
> boolrclk_en;
> u32 trigger_address;
> u32 wr_delay;
> + booluse_direct_mode;
> struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
> };
>
> @@ -283,9 +277,8 @@ static irqreturn_t cqspi_irq_handler(int this_irq, void
> *dev)
> return IRQ_HANDLED;
> }
>
> -static unsigned int cqspi_calc_rdreg(struct spi_nor *nor)
> +static unsigned int cqspi_calc_rdreg(struct cqspi_flash_pdata *f_pdata)
> {
> - struct cqspi_flash_pdata *f_pdata = nor->priv;
> u32 rdreg = 0;
>
> rdreg |= f_pdata->inst_width << CQSPI_REG_RD_INSTR_TYPE_INSTR_LSB;
> @@ -352,19 +345,21 @@ static int cqspi_exec_flash_cmd(struct cqspi_st *cqspi,
> unsigned int reg)
> return cqspi_wait_idle(cqspi);
> }
>
> -static int cqspi_command_read(struct spi_nor *nor, u8 opcode,
> - u8 *rxbuf, size_t n_rx)
> +static int cqspi_command_read(struct cqspi_flash_pdata *f_pdata,
> + const struct spi_mem_op *op)
> {
> - struct cqspi_flash_pdata *f_pdata = nor->priv;
> struct cqspi_st *cqspi = f_pdata->cqspi;
> void __iomem *reg_base = cqspi->iobase;
> + u8 *rxbuf = op->data.buf.in;
> + u8 opcode = op->cmd.opcode;
> + size_t n_rx = op->data.nbytes;
> unsigned int rdreg;
> unsigned int reg;
> size_t read_len;
> int status;
>
> if (!n_rx || n_rx > CQSPI_STIG_DATA_LEN_MAX || !rxbuf) {
> - dev_err(nor->dev,
> + dev_err(>pdev->dev,
> "Invalid input argument, len %zu rxbuf 0x%p\n",
> n_rx, rxbuf);
> return -EINVAL;
> @@ -372,7 +367,7 @@ static int cqspi_command_read(struct spi_nor *nor, u8
> opcode,
>
> reg = opcode << CQSPI_REG_CMDCTRL_OPCODE_LSB;
>
> - rdreg = cqspi_calc_rdreg(nor);
> + rdreg = cqspi_calc_rdreg(f_pdata);
> writel(rdreg, reg_base + CQSPI_REG_RD_INSTR);
>
> reg |= (0x1 << CQSPI_REG_CMDCTRL_RD_EN_LSB);
> @@ -401,25 +396,36 @@ static int cqspi_command_read(struct spi_nor *nor, u8
> opcode,
> return 0;
> }
>
> -static int cqspi_command_write(struct spi_nor *nor, const u8 opcode,
> -const u8 *txbuf, size_t n_tx)
> +static int
[PATCH] iio: dac: ad5593r: Dynamically set AD5593R channel modes
To use ad5593r more flexibly, we use the module parameter to setting the
channel modes dynamically whenever the module probe up. Users can pass
the channel modes to the module parameter for allocating the
functionality of channels as desired.
For example:
* Use in the kernel command line:
Users can add the module parameter in the kernel command line such as
"ad5593r.ch_mode_cmdline=88001122"
"88001122" means the channel mode setting for each channel. The most
left side indicates the mode of channel 7, and the most right side
indicates the mode of channel 0.
* Use when manually probe the module:
Similar to the kernel command line usage, users can enter
"modprobe ad5593r ch_mode_probe=88001122"
to start the ad5593r module with the desired channel mode setting.
Signed-off-by: William Sung
---
drivers/iio/dac/ad5592r-base.c | 33 ++--
drivers/iio/dac/ad5592r-base.h | 4 +++
drivers/iio/dac/ad5593r.c | 55 ++
3 files changed, 89 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/dac/ad5592r-base.c b/drivers/iio/dac/ad5592r-base.c
index cc4875660a69..cd69a34fa21e 100644
--- a/drivers/iio/dac/ad5592r-base.c
+++ b/drivers/iio/dac/ad5592r-base.c
@@ -21,6 +21,10 @@
#include "ad5592r-base.h"
+/* Parameters for dynamic channel mode setting */
+static u8 update_channel_mode;
+static u8 new_channel_modes[AD559XR_CHANNEL_NR];
+
static int ad5592r_gpio_get(struct gpio_chip *chip, unsigned offset)
{
struct ad5592r_state *st = gpiochip_get_data(chip);
@@ -132,7 +136,7 @@ static int ad5592r_gpio_init(struct ad5592r_state *st)
st->gpiochip.label = dev_name(st->dev);
st->gpiochip.base = -1;
- st->gpiochip.ngpio = 8;
+ st->gpiochip.ngpio = AD559XR_CHANNEL_NR;
st->gpiochip.parent = st->dev;
st->gpiochip.can_sleep = true;
st->gpiochip.direction_input = ad5592r_gpio_direction_input;
@@ -287,6 +291,14 @@ static int ad5592r_set_channel_modes(struct ad5592r_state
*st)
return ret;
}
+static void ad5592r_set_def_channel_modes(struct ad5592r_state *st)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(st->channel_modes); i++)
+ st->channel_modes[i] = new_channel_modes[i];
+}
+
static int ad5592r_reset_channel_modes(struct ad5592r_state *st)
{
int i;
@@ -532,6 +544,10 @@ static int ad5592r_alloc_channels(struct iio_dev *iio_dev)
st->channel_offstate[reg] = tmp;
}
+ /* Update default channel modes set by external module */
+ if (update_channel_mode == 1)
+ ad5592r_set_def_channel_modes(st);
+
channels = devm_kcalloc(st->dev,
1 + 2 * num_channels, sizeof(*channels),
GFP_KERNEL);
@@ -567,7 +583,7 @@ static int ad5592r_alloc_channels(struct iio_dev *iio_dev)
}
channels[curr_channel].type = IIO_TEMP;
- channels[curr_channel].channel = 8;
+ channels[curr_channel].channel = AD559XR_CHANNEL_NR;
channels[curr_channel].info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
BIT(IIO_CHAN_INFO_SCALE) |
BIT(IIO_CHAN_INFO_OFFSET);
@@ -589,6 +605,17 @@ static void ad5592r_init_scales(struct ad5592r_state *st,
int vref_mV)
div_s64_rem(tmp * 2, 10LL, >scale_avail[1][1]);
}
+void ad5592r_update_default_channel_modes(u8 *new_modes)
+{
+ int idx = 0;
+
+ update_channel_mode = 1;
+ for (idx = 0; idx < AD559XR_CHANNEL_NR; idx++)
+ new_channel_modes[idx] = new_modes[idx];
+
+}
+EXPORT_SYMBOL_GPL(ad5592r_update_default_channel_modes);
+
int ad5592r_probe(struct device *dev, const char *name,
const struct ad5592r_rw_ops *ops)
{
@@ -603,7 +630,7 @@ int ad5592r_probe(struct device *dev, const char *name,
st = iio_priv(iio_dev);
st->dev = dev;
st->ops = ops;
- st->num_channels = 8;
+ st->num_channels = AD559XR_CHANNEL_NR;
dev_set_drvdata(dev, iio_dev);
st->reg = devm_regulator_get_optional(dev, "vref");
diff --git a/drivers/iio/dac/ad5592r-base.h b/drivers/iio/dac/ad5592r-base.h
index 23dac2f1ff8a..40ad6369e660 100644
--- a/drivers/iio/dac/ad5592r-base.h
+++ b/drivers/iio/dac/ad5592r-base.h
@@ -39,6 +39,9 @@ enum ad5592r_registers {
#define AD5592R_REG_CTRL_ADC_RANGE BIT(5)
#define AD5592R_REG_CTRL_DAC_RANGE BIT(4)
+/* Define quantity of channels of AD5592R/AD5593R */
+#define AD559XR_CHANNEL_NR 8
+
struct ad5592r_rw_ops {
int (*write_dac)(struct ad5592r_state *st, unsigned chan, u16 value);
int (*read_adc)(struct ad5592r_state *st, unsigned chan, u16 *value);
@@ -69,6 +72,7 @@ struct ad5592r_state {
__be16 spi_msg_nop;
};
+void ad5592r_update_default_channel_modes(u8 *new_modes);
int ad5592r_probe(struct device *dev, const char *name,
const struct ad5592r_rw_ops *ops);
int
Re: [PATCH 07/22] dt-bindings: serial: fsl-imx-uart: imx-pwm: Add i.MX 8M compatibles
The subject contains a "imx-pwm", presumably from the last patch.
Sascha
On Sun, Aug 23, 2020 at 06:15:35PM +0200, Krzysztof Kozlowski wrote:
> DTSes with new i.MX 8M SoCs introduce their own compatibles so add them
> to fix dtbs_check warnings like:
>
> arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: pwm@3066:
> compatible:0: 'fsl,imx8mm-pwm' is not one of ['fsl,imx1-pwm',
> 'fsl,imx27-pwm']
> From schema: Documentation/devicetree/bindings/pwm/imx-pwm.yaml
>
> arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: pwm@3066:
> compatible: ['fsl,imx8mm-pwm', 'fsl,imx27-pwm'] is too long
>
> arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: pwm@3066:
> compatible: Additional items are not allowed ('fsl,imx27-pwm' was
> unexpected)
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml
> b/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml
> index cba3f83ccd5f..3d896173b3b0 100644
> --- a/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml
> +++ b/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml
> @@ -36,6 +36,10 @@ properties:
> - fsl,imx6sx-uart
> - fsl,imx6ul-uart
> - fsl,imx7d-uart
> +- fsl,imx8mm-uart
> +- fsl,imx8mn-uart
> +- fsl,imx8mp-uart
> +- fsl,imx8mq-uart
>- const: fsl,imx6q-uart
>
>reg:
> --
> 2.17.1
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH] net: hns: Fix memleak in hns_nic_dev_probe
hns_nic_dev_probe allocates ndev, but not free it on
two error handling paths, which may lead to memleak.
Fixes: 63434888aaf1b ("net: hns: net: hns: enet adds support of acpi")
Signed-off-by: Dinghao Liu
---
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index 23f278e46975..22522f8a5299 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -2282,8 +2282,10 @@ static int hns_nic_dev_probe(struct platform_device
*pdev)
priv->enet_ver = AE_VERSION_1;
else if (acpi_dev_found(hns_enet_acpi_match[1].id))
priv->enet_ver = AE_VERSION_2;
- else
- return -ENXIO;
+ else {
+ ret = -ENXIO;
+ goto out_read_prop_fail;
+ }
/* try to find port-idx-in-ae first */
ret = acpi_node_get_property_reference(dev->fwnode,
@@ -2299,7 +2301,8 @@ static int hns_nic_dev_probe(struct platform_device *pdev)
priv->fwnode = args.fwnode;
} else {
dev_err(dev, "cannot read cfg data from OF or acpi\n");
- return -ENXIO;
+ ret = -ENXIO;
+ goto out_read_prop_fail;
}
ret = device_property_read_u32(dev, "port-idx-in-ae", _id);
--
2.17.1
Re: [RFC PATCH 1/5] printk: implement pr_cont_t
On (20/08/20 01:32), John Ogness wrote:
> +#define CONT_LINE_MAX LOG_LINE_MAX
> +#define CONT_BUF_COUNT 10
> +static char cont_buf[CONT_BUF_COUNT][CONT_LINE_MAX];
> +static DECLARE_BITMAP(cont_buf_map, CONT_BUF_COUNT);
> +
> +static int get_cont_buf(void)
> +{
> + int bit;
> +
> + do {
> + bit = find_first_zero_bit(cont_buf_map, CONT_BUF_COUNT);
> + if (bit == CONT_BUF_COUNT)
> + break;
> + } while (test_and_set_bit(bit, cont_buf_map));
> +
> + return bit;
> +}
> +static void put_cont_buf(int index)
> +{
> + if (WARN_ON(index >= CONT_BUF_COUNT))
> + return;
> + if (WARN_ON(!test_bit(index, cont_buf_map)))
> + return;
Doesn't WARN_ON() do pr_cont() print outs as well? I'm a bit worried by
the path that re-enters pr_cont() from "broken" pr_cont() path.
Just ideas, to keep the discussion alive:
Overall, I wonder if pr_cont buffers should hold more info, e.g. owner
context. If the same context does "normal" printk() while still owning
the unfinished cont buffer then we should flush cont buffer. I may be
in minority here, I don't see a very strong reason to keep the global
order of the messages - e.g. if pid 234 does printk on CPU1 then we
probably don't need to flush pid's 8889 cont buffer (which runs on CPU42,
for instance), but keeping the order of the messages within the context
is somehow much more important. That is, if pid 8889 starts pr_cont buffer
and then triggers a pr_warn() or pr_alert() or any other printk() then I
think we need to flush the cont buffer. Just 5 cents.
-ss
Re: [PATCH 02/22] dt-bindings: gpio: fsl-imx-gpio: Add gpio-ranges property
On Sun, Aug 23, 2020 at 06:15:30PM +0200, Krzysztof Kozlowski wrote: > The GPIO controller node can have gpio-ranges property. This fixes > dtbs_check warnings like: > > arch/arm64/boot/dts/freescale/imx8mm-evk.dt.yaml: gpio@3020: > 'gpio-ranges' does not match any of the regexes: 'pinctrl-[0-9]+' > From schema: Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml > > Signed-off-by: Krzysztof Kozlowski > --- > .../devicetree/bindings/gpio/fsl-imx-gpio.yaml| 15 +++ > 1 file changed, 15 insertions(+) > > diff --git a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml > b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml > index 454db20c2d1a..1fac69573bb9 100644 > --- a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml > +++ b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.yaml > @@ -51,6 +51,9 @@ properties: > >gpio-controller: true > > + gpio-ranges: > +maxItems: 1 > + > required: >- compatible >- reg > @@ -62,6 +65,18 @@ required: > > additionalProperties: false > > +allOf: > + - if: > + properties: > +compatible: > + contains: > +const: fsl,imx8mp-gpio > +then: > + properties: > +gpio-ranges: > + minItems: 1 > + maxItems: 2 Why do you limit this to fsl,imx8mp-gpio? The i.MX5,6,7 dtsi files use gpio-ranges as well and other i.MX dtsi files could also use it. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH] driver/pci: reduce the single block time in pci_read_config
From: Jiang Biao
pci_read_config() could block several ms in kernel space, mainly
caused by the while loop to call pci_user_read_config_dword().
Singel pci_user_read_config_dword() loop could consume 130us+,
|pci_user_read_config_dword() {
| _raw_spin_lock_irq() {
! 136.698 us |native_queued_spin_lock_slowpath();
! 137.582 us | }
| pci_read() {
|raw_pci_read() {
| pci_conf1_read() {
0.230 us|_raw_spin_lock_irqsave();
0.035 us|_raw_spin_unlock_irqrestore();
8.476 us| }
8.790 us|}
9.091 us| }
! 147.263 us |}
and dozens of the loop could consume ms+.
If we execute some lspci commands concurrently, ms+ scheduling
latency could be detected.
Add scheduling chance in the loop to improve the latency.
Reported-by: Bin Lai
Signed-off-by: Jiang Biao
---
drivers/pci/pci-sysfs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 6d78df9..3b9f63d 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -708,6 +708,7 @@ static ssize_t pci_read_config(struct file *filp, struct
kobject *kobj,
data[off - init_off + 3] = (val >> 24) & 0xff;
off += 4;
size -= 4;
+ cond_resched();
}
if (size >= 2) {
--
1.8.3.1
Re: [PATCH v1 09/10] powerpc/pseries/iommu: Make use of DDW even if it does not map the partition
On 18/08/2020 09:40, Leonardo Bras wrote:
> As of today, if the biggest DDW that can be created can't map the whole
> partition, it's creation is skipped and the default DMA window
> "ibm,dma-window" is used instead.
>
> DDW is 16x bigger than the default DMA window,
16x only under very specific circumstances which are
1. phyp
2. sriov
3. device class in hmc (or what that priority number is in the lpar config).
> having the same amount of
> pages, but increasing the page size to 64k.
> Besides larger DMA window,
"Besides being larger"?
> it performs better for allocations over 4k,
Better how?
> so it would be nice to use it instead.
I'd rather say something like:
===
So far we assumed we can map the guest RAM 1:1 to the bus which worked
with a small number of devices. SRIOV changes it as the user can
configure hundreds VFs and since phyp preallocates TCEs and does not
allow IOMMU pages bigger than 64K, it has to limit the number of TCEs
per a PE to limit waste of physical pages.
===
>
> The DDW created will be used for direct mapping by default.
> If it's not available, indirect mapping will be used instead.
>
> For indirect mapping, it's necessary to update the iommu_table so
> iommu_alloc() can use the DDW created. For this,
> iommu_table_update_window() is called when everything else succeeds
> at enable_ddw().
>
> Removing the default DMA window for using DDW with indirect mapping
> is only allowed if there is no current IOMMU memory allocated in
> the iommu_table. enable_ddw() is aborted otherwise.
>
> As there will never have both direct and indirect mappings at the same
> time, the same property name can be used for the created DDW.
>
> So renaming
> define DIRECT64_PROPNAME "linux,direct64-ddr-window-info"
> to
> define DMA64_PROPNAME "linux,dma64-ddr-window-info"
> looks the right thing to do.
I know I suggested this but this does not look so good anymore as I
suspect it breaks kexec (from older kernel to this one) so you either
need to check for both DT names or just keep the old one. Changing the
macro name is fine.
>
> To make sure the property differentiates both cases, a new u32 for flags
> was added at the end of the property, where BIT(0) set means direct
> mapping.
>
> Signed-off-by: Leonardo Bras
> ---
> arch/powerpc/platforms/pseries/iommu.c | 108 +++--
> 1 file changed, 84 insertions(+), 24 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/iommu.c
> b/arch/powerpc/platforms/pseries/iommu.c
> index 3a1ef02ad9d5..9544e3c91ced 100644
> --- a/arch/powerpc/platforms/pseries/iommu.c
> +++ b/arch/powerpc/platforms/pseries/iommu.c
> @@ -350,8 +350,11 @@ struct dynamic_dma_window_prop {
> __be64 dma_base; /* address hi,lo */
> __be32 tce_shift; /* ilog2(tce_page_size) */
> __be32 window_shift; /* ilog2(tce_window_size) */
> + __be32 flags; /* DDW properties, see bellow */
> };
>
> +#define DDW_FLAGS_DIRECT 0x01
This is set if ((1<= ddw_memory_hotplug_max()), you
could simply check window_shift and drop the flags.
> +
> struct direct_window {
> struct device_node *device;
> const struct dynamic_dma_window_prop *prop;
> @@ -377,7 +380,7 @@ static LIST_HEAD(direct_window_list);
> static DEFINE_SPINLOCK(direct_window_list_lock);
> /* protects initializing window twice for same device */
> static DEFINE_MUTEX(direct_window_init_mutex);
> -#define DIRECT64_PROPNAME "linux,direct64-ddr-window-info"
> +#define DMA64_PROPNAME "linux,dma64-ddr-window-info"
>
> static int tce_clearrange_multi_pSeriesLP(unsigned long start_pfn,
> unsigned long num_pfn, const void *arg)
> @@ -836,7 +839,7 @@ static void remove_ddw(struct device_node *np, bool
> remove_prop)
> if (ret)
> return;
>
> - win = of_find_property(np, DIRECT64_PROPNAME, NULL);
> + win = of_find_property(np, DMA64_PROPNAME, NULL);
> if (!win)
> return;
>
> @@ -852,7 +855,7 @@ static void remove_ddw(struct device_node *np, bool
> remove_prop)
> np, ret);
> }
>
> -static bool find_existing_ddw(struct device_node *pdn, u64 *dma_addr)
> +static bool find_existing_ddw(struct device_node *pdn, u64 *dma_addr, bool
> *direct_mapping)
> {
> struct direct_window *window;
> const struct dynamic_dma_window_prop *direct64;
> @@ -864,6 +867,7 @@ static bool find_existing_ddw(struct device_node *pdn,
> u64 *dma_addr)
> if (window->device == pdn) {
> direct64 = window->prop;
> *dma_addr = be64_to_cpu(direct64->dma_base);
> + *direct_mapping = be32_to_cpu(direct64->flags) &
> DDW_FLAGS_DIRECT;
> found = true;
> break;
> }
> @@ -901,8 +905,8 @@ static int find_existing_ddw_windows(void)
> if (!firmware_has_feature(FW_FEATURE_LPAR))
> return 0;
>
>
Re: [PATCH v2] KVM: LAPIC: Narrow down the kick target vCPU
On Mon, 24 Aug 2020 at 09:03, Wanpeng Li wrote:
>
> From: Wanpeng Li
>
> The kick after setting KVM_REQ_PENDING_TIMER is used to handle the timer
> fires on a different pCPU which vCPU is running on, this kick is expensive
> since memory barrier, rcu, preemption disable/enable operations. We don't
> need this kick when injecting already-expired timer, we also should call
> out the VMX preemption timer case, which also passes from_timer_fn=false
> but doesn't need a kick because kvm_lapic_expired_hv_timer() is called
> from the target vCPU.
>
I miss Sean's reviewed-by tag.
Reviewed-by: Sean Christopherson
> Signed-off-by: Wanpeng Li
> ---
> v1 -> v2:
> * update patch subject and changelog
> * open code kvm_set_pending_timer()
>
> arch/x86/kvm/lapic.c | 4 +++-
> arch/x86/kvm/x86.c | 6 --
> arch/x86/kvm/x86.h | 1 -
> 3 files changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 248095a..97f1dbf 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -1642,7 +1642,9 @@ static void apic_timer_expired(struct kvm_lapic *apic,
> bool from_timer_fn)
> }
>
> atomic_inc(>lapic_timer.pending);
> - kvm_set_pending_timer(vcpu);
> + kvm_make_request(KVM_REQ_PENDING_TIMER, vcpu);
> + if (from_timer_fn)
> + kvm_vcpu_kick(vcpu);
> }
>
> static void start_sw_tscdeadline(struct kvm_lapic *apic)
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 599d732..51b74d0 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1778,12 +1778,6 @@ static s64 get_kvmclock_base_ns(void)
> }
> #endif
>
> -void kvm_set_pending_timer(struct kvm_vcpu *vcpu)
> -{
> - kvm_make_request(KVM_REQ_PENDING_TIMER, vcpu);
> - kvm_vcpu_kick(vcpu);
> -}
> -
> static void kvm_write_wall_clock(struct kvm *kvm, gpa_t wall_clock)
> {
> int version;
> diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
> index 995ab69..ea20b8b 100644
> --- a/arch/x86/kvm/x86.h
> +++ b/arch/x86/kvm/x86.h
> @@ -246,7 +246,6 @@ static inline bool kvm_vcpu_latch_init(struct kvm_vcpu
> *vcpu)
> return is_smm(vcpu) || kvm_x86_ops.apic_init_signal_blocked(vcpu);
> }
>
> -void kvm_set_pending_timer(struct kvm_vcpu *vcpu);
> void kvm_inject_realmode_interrupt(struct kvm_vcpu *vcpu, int irq, int
> inc_eip);
>
> void kvm_write_tsc(struct kvm_vcpu *vcpu, struct msr_data *msr);
> --
> 2.7.4
>
Re: [patch RFC 23/38] x86/xen: Rework MSI teardown
On 21.08.20 02:24, Thomas Gleixner wrote:
X86 cannot store the irq domain pointer in struct device without breaking
XEN because the irq domain pointer takes precedence over arch_*_msi_irqs()
fallbacks.
XENs MSI teardown relies on default_teardown_msi_irqs() which invokes
arch_teardown_msi_irq(). default_teardown_msi_irqs() is a trivial iterator
over the msi entries associated to a device.
Implement this loop in xen_teardown_msi_irqs() to prepare for removal of
the fallbacks for X86.
This is a preparatory step to wrap XEN MSI alloc/free into a irq domain
which in turn allows to store the irq domain pointer in struct device and
to use the irq domain functions directly.
Signed-off-by: Thomas Gleixner
---
arch/x86/pci/xen.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -376,20 +376,31 @@ static void xen_initdom_restore_msi_irqs
static void xen_teardown_msi_irqs(struct pci_dev *dev)
{
struct msi_desc *msidesc;
+ int i;
+
+ for_each_pci_msi_entry(msidesc, dev) {
+ if (msidesc->irq) {
+ for (i = 0; i < msidesc->nvec_used; i++)
+ xen_destroy_irq(msidesc->irq + i);
+ }
+ }
+}
+
+static void xen_pv_teardown_msi_irqs(struct pci_dev *dev)
+{
+ struct msi_desc *msidesc = first_pci_msi_entry(dev);
- msidesc = first_pci_msi_entry(dev);
if (msidesc->msi_attrib.is_msix)
xen_pci_frontend_disable_msix(dev);
else
xen_pci_frontend_disable_msi(dev);
- /* Free the IRQ's and the msidesc using the generic code. */
- default_teardown_msi_irqs(dev);
+ xen_teardown_msi_irqs(dev);
}
static void xen_teardown_msi_irq(unsigned int irq)
{
- xen_destroy_irq(irq);
+ WARN_ON_ONCE(1);
}
#endif
@@ -412,7 +423,7 @@ int __init pci_xen_init(void)
#ifdef CONFIG_PCI_MSI
x86_msi.setup_msi_irqs = xen_setup_msi_irqs;
x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
- x86_msi.teardown_msi_irqs = xen_teardown_msi_irqs;
+ x86_msi.teardown_msi_irqs = xen_pv_teardown_msi_irqs;
pci_msi_ignore_mask = 1;
#endif
return 0;
@@ -436,6 +447,7 @@ static void __init xen_hvm_msi_init(void
}
x86_msi.setup_msi_irqs = xen_hvm_setup_msi_irqs;
+ x86_msi.teardown_msi_irqs = xen_teardown_msi_irqs;
x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
}
#endif
@@ -472,6 +484,7 @@ int __init pci_xen_initial_domain(void)
#ifdef CONFIG_PCI_MSI
x86_msi.setup_msi_irqs = xen_initdom_setup_msi_irqs;
x86_msi.teardown_msi_irq = xen_teardown_msi_irq;
+ x86_msi.teardown_msi_irqs = xen_teardown_msi_irqs;
This should be xen_pv_teardown_msi_irqs, as pci_xen_initial_domain() is
called only for the pv initial domain case today.
x86_msi.restore_msi_irqs = xen_initdom_restore_msi_irqs;
pci_msi_ignore_mask = 1;
#endif
Juergen
Re: [PATCH v1 08/10] powerpc/pseries/iommu: Add ddw_property_create() and refactor enable_ddw()
On 18/08/2020 09:40, Leonardo Bras wrote:
> Code used to create a ddw property that was previously scattered in
> enable_ddw() is now gathered in ddw_property_create(), which deals with
> allocation and filling the property, letting it ready for
> of_property_add(), which now occurs in sequence.
>
> This created an opportunity to reorganize the second part of enable_ddw():
>
> Without this patch enable_ddw() does, in order:
> kzalloc() property & members, create_ddw(), fill ddwprop inside property,
> ddw_list_add(), do tce_setrange_multi_pSeriesLP_walk in all memory,
> of_add_property().
>
> With this patch enable_ddw() does, in order:
> create_ddw(), ddw_property_create(), of_add_property(), ddw_list_add(),
> do tce_setrange_multi_pSeriesLP_walk in all memory.
>
> This change requires of_remove_property() in case anything fails after
> of_add_property(), but we get to do tce_setrange_multi_pSeriesLP_walk
> in all memory, which looks the most expensive operation, only if
> everything else succeeds.
>
> Signed-off-by: Leonardo Bras
> ---
> arch/powerpc/platforms/pseries/iommu.c | 97 +++---
> 1 file changed, 57 insertions(+), 40 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/iommu.c
> b/arch/powerpc/platforms/pseries/iommu.c
> index 4031127c9537..3a1ef02ad9d5 100644
> --- a/arch/powerpc/platforms/pseries/iommu.c
> +++ b/arch/powerpc/platforms/pseries/iommu.c
> @@ -1123,6 +1123,31 @@ static void reset_dma_window(struct pci_dev *dev,
> struct device_node *par_dn)
>ret);
> }
>
> +static int ddw_property_create(struct property **ddw_win, const char
> *propname,
@propname is always the same, do you really want to pass it every time?
> +u32 liobn, u64 dma_addr, u32 page_shift, u32
> window_shift)
> +{
> + struct dynamic_dma_window_prop *ddwprop;
> + struct property *win64;
> +
> + *ddw_win = win64 = kzalloc(sizeof(*win64), GFP_KERNEL);
> + if (!win64)
> + return -ENOMEM;
> +
> + win64->name = kstrdup(propname, GFP_KERNEL);
Not clear why "win64->name = DIRECT64_PROPNAME" would not work here, the
generic OF code does not try kfree() it but it is probably out of scope
here.
> + ddwprop = kzalloc(sizeof(*ddwprop), GFP_KERNEL);
> + win64->value = ddwprop;
> + win64->length = sizeof(*ddwprop);
> + if (!win64->name || !win64->value)
> + return -ENOMEM;
Up to 2 memory leaks here. I see the cleanup at "out_free_prop:" but
still looks fragile. Instead you could simply return win64 as the only
error possible here is -ENOMEM and returning NULL is equally good.
> +
> + ddwprop->liobn = cpu_to_be32(liobn);
> + ddwprop->dma_base = cpu_to_be64(dma_addr);
> + ddwprop->tce_shift = cpu_to_be32(page_shift);
> + ddwprop->window_shift = cpu_to_be32(window_shift);
> +
> + return 0;
> +}
> +
> /*
> * If the PE supports dynamic dma windows, and there is space for a table
> * that can map all pages in a linear offset, then setup such a table,
> @@ -1140,12 +1165,11 @@ static bool enable_ddw(struct pci_dev *dev, struct
> device_node *pdn)
> struct ddw_query_response query;
> struct ddw_create_response create;
> int page_shift;
> - u64 max_addr;
> + u64 max_addr, win_addr;
> struct device_node *dn;
> u32 ddw_avail[DDW_APPLICABLE_SIZE];
> struct direct_window *window;
> - struct property *win64;
> - struct dynamic_dma_window_prop *ddwprop;
> + struct property *win64 = NULL;
> struct failed_ddw_pdn *fpdn;
> bool default_win_removed = false;
>
> @@ -1244,38 +1268,34 @@ static bool enable_ddw(struct pci_dev *dev, struct
> device_node *pdn)
> goto out_failed;
> }
> len = order_base_2(max_addr);
> - win64 = kzalloc(sizeof(struct property), GFP_KERNEL);
> - if (!win64) {
> - dev_info(>dev,
> - "couldn't allocate property for 64bit dma window\n");
> +
> + ret = create_ddw(dev, ddw_avail, , page_shift, len);
> + if (ret != 0)
It is usually just "if (ret)"
> goto out_failed;
> - }
> - win64->name = kstrdup(DIRECT64_PROPNAME, GFP_KERNEL);
> - win64->value = ddwprop = kmalloc(sizeof(*ddwprop), GFP_KERNEL);
> - win64->length = sizeof(*ddwprop);
> - if (!win64->name || !win64->value) {
> +
> + dev_dbg(>dev, "created tce table LIOBN 0x%x for %pOF\n",
> + create.liobn, dn);
> +
> + win_addr = ((u64)create.addr_hi << 32) | create.addr_lo;
> + ret = ddw_property_create(, DIRECT64_PROPNAME, create.liobn,
> win_addr,
> + page_shift, len);
> + if (ret) {
> dev_info(>dev,
> - "couldn't allocate property name and value\n");
> + "couldn't allocate property, property name, or
> value\n");
> goto out_free_prop;
> }
>
> - ret = create_ddw(dev, ddw_avail,
Re: [patch RFC 24/38] x86/xen: Consolidate XEN-MSI init
On 21.08.20 02:24, Thomas Gleixner wrote:
X86 cannot store the irq domain pointer in struct device without breaking
XEN because the irq domain pointer takes precedence over arch_*_msi_irqs()
fallbacks.
To achieve this XEN MSI interrupt management needs to be wrapped into an
irq domain.
Move the x86_msi ops setup into a single function to prepare for this.
Signed-off-by: Thomas Gleixner
---
arch/x86/pci/xen.c | 51 ---
1 file changed, 32 insertions(+), 19 deletions(-)
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
@@ -371,7 +371,10 @@ static void xen_initdom_restore_msi_irqs
WARN(ret && ret != -ENOSYS, "restore_msi -> %d\n", ret);
}
}
-#endif
+#else /* CONFIG_XEN_DOM0 */
+#define xen_initdom_setup_msi_irqs NULL
+#define xen_initdom_restore_msi_irqs NULL
+#endif /* !CONFIG_XEN_DOM0 */
static void xen_teardown_msi_irqs(struct pci_dev *dev)
{
@@ -403,7 +406,31 @@ static void xen_teardown_msi_irq(unsigne
WARN_ON_ONCE(1);
}
-#endif
+static __init void xen_setup_pci_msi(void)
+{
+ if (xen_initial_domain()) {
+ x86_msi.setup_msi_irqs = xen_initdom_setup_msi_irqs;
+ x86_msi.teardown_msi_irqs = xen_teardown_msi_irqs;
+ x86_msi.restore_msi_irqs = xen_initdom_restore_msi_irqs;
+ pci_msi_ignore_mask = 1;
This is wrong, as a PVH initial domain shouldn't do the pv settings.
The "if (xen_initial_domain())" should be inside the pv case, like:
if (xen_pv_domain()) {
if (xen_initial_domain()) {
...
} else {
...
}
} else if (xen_hvm_domain()) {
...
Juergen
linux-next: Tree for Aug 24
Hi all, Changes since 20200821: The hwmon-staging tree gained a build failure so I used the version from next-20200821. The bpf-next tree still had its build failure for which I disabled BPF_PRELOAD. It also gained a conflict against Linus' tree. Non-merge commits (relative to Linus' tree): 2002 3598 files changed, 71575 insertions(+), 26584 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig and htmldocs. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 328 trees (counting Linus' and 86 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (d012a7190fc1 Linux 5.9-rc2) Merging fixes/master (9123e3a74ec7 Linux 5.9-rc1) Merging kbuild-current/fixes (510bc3cb1ddc kconfig: qconf: replace deprecated QString::sprintf() with QTextStream) Merging arc-current/for-curr (97363c07f023 ARC: show_regs: fix r12 printing and simplify) Merging arm-current/fixes (5c6360ee4a0e ARM: 8988/1: mmu: fix crash in EFI calls due to p4d typo in create_mapping_late()) Merging arm64-fixes/for-next/fixes (8d75785a8142 ARM64: vdso32: Install vdso32 from vdso_install) Merging arm-soc-fixes/arm/fixes (cabe3a137148 Merge tag 'zynqmp-dt-for-v5.9' of https://github.com/Xilinx/linux-xlnx into arm/fixes) Merging uniphier-fixes/fixes (48778464bb7d Linux 5.8-rc2) Merging drivers-memory-fixes/fixes (7ff3a2a626f7 memory: jz4780_nemc: Fix an error pointer vs NULL check in probe()) Merging m68k-current/for-linus (382f429bb559 m68k: defconfig: Update defconfigs for v5.8-rc3) Merging powerpc-fixes/fixes (64ef8f2c4791 powerpc/perf/hv-24x7: Move cpumask file to top folder of hv-24x7 driver) Merging s390-fixes/fixes (b97bf44f9915 s390/pci: fix PF/VF linking on hot plug) Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro) Merging fscrypt-current/for-stable (2b4eae95c736 fscrypt: don't evict dirty inodes after removing key) Merging net/master (cb95712138ec Merge tag 'powerpc-5.9-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux) Merging bpf/master (4af7b32f84aa Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf) Merging ipsec/master (4eb2e1341575 espintcp: restore IP CB before handing the packet to xfrm) Merging netfilter/master (1e105e6afa6c netfilter: nf_tables: fix destination register zeroing) Merging ipvs/master (7c7ab580db49 net: Convert to use the fallthrough macro) Merging wireless-drivers/master (9a2a0862d973 brcmfmac: reserve tx credit only when txctl is ready to send) Merging mac80211/master (fce2ff728f95 nl80211: fix NL80211_ATTR_HE_6GHZ_CAPABILITY usage) Merging rdma-fixes/for-rc (f6da70d99c96 MAINTAINERS: Update Mellanox and Cumulus Network addresses to new domain) Merging sound-current/for-linus (acd46a6b6de8 ALSA: firewire-digi00x: exclude Avid Adrenaline from detection) Merging sound-asoc-fixes/for-linus (c26a160782d9 Merge remote-tracking branch 'asoc/for-5.9' into asoc-linus) Merging regmap-fixes/for-linus (9123e3a74ec7 Linux 5.9-rc1) Merging regulator-fixes/for-linus (8d2335989a02 Merge remote-tracking branch 'regulator/for-5.9' into regulator-linus) Merging spi-fixes/for-linus (bd70f2c7c37c Merge remote-tracking branch 'spi/for-5.9' into spi-linus) Merging pci-current/for-linus (7c2308f79fc8 PCI/P2PDMA: Fix build without DMA ops) Merging driver-core.current/driver-core-linus (9123e3a74ec7 Linux 5.9-rc1) Merging
Re: [patch RFC 22/38] x86/xen: Make xen_msi_init() static and rename it to xen_hvm_msi_init()
On 21.08.20 02:24, Thomas Gleixner wrote: The only user is in the same file and the name is too generic because this function is only ever used for HVM domains. Signed-off-by: Thomas Gleixner Cc: Konrad Rzeszutek Wilk Cc:linux-...@vger.kernel.org Cc:xen-de...@lists.xenproject.org Cc: Juergen Gross Cc: Boris Ostrovsky Cc: Stefano Stabellini Reviewed-by: Juergen Gross Juergen
Re: [GIT PULL] irqchip fixes for 5.9, take #1
Hi, On 18/08/20 8:44 pm, Marc Zyngier wrote: > Hi Thomas, > > As -rc1 is out, here's the first batches of fixes for 5.9. The most > important one is a fix for a typo that broke modular irqchips using > the brand new set of macros. Oh hum... > > The rest of it is what I was hinting at when I sent the original 5.9 > pull request, with a bunch of TI updates that deal with the change of > their firmware interface. The handling of the dependencies was bad > enough that I couldn't send it before -rc1 was out... > > Please pull, I see rc2[0] is already tagged. Any reason why this PR is not merged? [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/ Thanks and regards, Lokesh > > M. > > The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5: > > Linux 5.9-rc1 (2020-08-16 13:04:57 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git > tags/irqchip-fixes-5.9-1 > > for you to fetch changes up to 7828a3ef8646fb2e69ed45616c8453a037ca7867: > > irqchip: Fix probing deferal when using IRQCHIP_PLATFORM_DRIVER helpers > (2020-08-17 08:06:11 +0100) > > > irqchip fixes for Linux 5.9, take #1 > > - Fix an embarassing typo in the new module helpers, leading > to the probe failing most of the time > > - The promised TI firmware rework that couldn't make it into > the merge window due to a very badly managed set of dependency > > > Lokesh Vutla (13): > firmware: ti_sci: Drop the device id to resource type translation > firmware: ti_sci: Drop unused structure ti_sci_rm_type_map > firmware: ti_sci: Add support for getting resource with subtype > dt-bindings: irqchip: ti, sci-intr: Update bindings to drop the usage > of gic as parent > dt-bindings: irqchip: Convert ti, sci-intr bindings to yaml > irqchip/ti-sci-intr: Add support for INTR being a parent to INTR > dt-bindings: irqchip: ti, sci-inta: Update docs to support different > parent. > dt-bindings: irqchip: Convert ti, sci-inta bindings to yaml > irqchip/ti-sci-inta: Do not store TISCI device id in platform device id > field > irqchip/ti-sci-inta: Add support for INTA directly connecting to GIC > arm64: dts: k3-j721e: ti-sci-inta/intr: Update to latest bindings > arm64: dts: k3-am65: ti-sci-inta/intr: Update to latest bindings > arm64: dts: k3-am65: Update the RM resource types > > Marc Zyngier (1): > irqchip: Fix probing deferal when using IRQCHIP_PLATFORM_DRIVER helpers > > .../bindings/interrupt-controller/ti,sci-inta.txt | 66 - > .../bindings/interrupt-controller/ti,sci-inta.yaml | 98 + > .../bindings/interrupt-controller/ti,sci-intr.txt | 82 --- > .../bindings/interrupt-controller/ti,sci-intr.yaml | 102 ++ > MAINTAINERS| 4 +- > arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 36 +++-- > arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi| 12 +- > arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi | 8 +- > arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 4 +- > .../boot/dts/ti/k3-j721e-common-proc-board.dts | 10 +- > arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 43 +++--- > arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi| 12 +- > drivers/firmware/ti_sci.c | 155 > + > drivers/irqchip/irq-ti-sci-inta.c | 95 ++--- > drivers/irqchip/irq-ti-sci-intr.c | 152 > drivers/irqchip/irqchip.c | 2 +- > include/linux/soc/ti/ti_sci_protocol.h | 13 ++ > 17 files changed, 517 insertions(+), 377 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt > create mode 100644 > Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml > delete mode 100644 > Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt > create mode 100644 > Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml >
Re: [PATCH V2] arm64/hotplug: Improve memory offline event notifier
On 08/24/2020 09:34 AM, Anshuman Khandual wrote: > This brings about three different changes to the sole memory event notifier > for arm64 platform and improves it's robustness while also enhancing debug > capabilities during potential memory offlining error conditions. > > This moves the memory notifier registration bit earlier in the boot process > from device_initcall() to setup_arch() which will help in guarding against > potential early boot memory offline requests. > > This enables MEM_OFFLINE memory event handling. It will help intercept any > possible error condition such as if boot memory some how still got offlined > even after an expilicit notifier failure, potentially by a future change in > generic hotplug framework. This would help detect such scenarious and help > debug further. > > It also adds a validation function which scans entire boot memory and makes > sure that early memory sections are online. This check is essential for the > memory notifier to work properly as it cannot prevent boot memory offlining > if they are not online to begin with. But this additional sanity check is > enabled only with DEBUG_VM. > > Cc: Catalin Marinas > Cc: Will Deacon Wrong email address here for Will. + Will Deacon s/w...@kernel.com/w...@kernel.org next time around.
Re: [PATCH] tools/power turbostat: call pread64 in kernel directly
On 8/24/20 04:54, Alexander Monakov wrote: > Hi, > > I am not the original submitter, but I have answers and a proper patch :) > > On Fri, 21 Aug 2020, Len Brown wrote: > >> Re: offset size >> >> The offsets on this file are the MSR offsets. >> What MSR are you trying to access at offset 0xc0010299? > > This MSR is particular is part of AMD RAPL (energy measurements) interface. > >> Re: pread vs pread64 >> >> If I take on faith that you have some kind of 32-bit execution >> environment that makes pread into pread32 instead of pread64, and that >> truncates an off_t to 32-bits from 64-bits, and it actually makes >> sense to request a read at this large offset... > > The problem here stems from the backward compatibility in Glibc: off_t is > 32-bit on 32-bit x86, unless compiled with -D_FILE_OFFSET_BITS=64. This > macro should be used for all new code. Distros should enable it for all > builds, but when one builds turbostat 'by hand', they hit the issue. > >> would we really have to invoke syscall() directly -- couldn't we >> invoke pread64() directly? (eg. below) > > No, the proper fix is to pass -D_FILE_OFFSET_BITS=64 to the compiler. > > Here's the patch: This path works with my case. Thanks, Liwei. > > ---8<--- > > From: Alexander Monakov > Date: Sun, 23 Aug 2020 23:27:02 +0300 > Subject: [PATCH] turbostat: build with _FILE_OFFSET_BITS=64 > > For compatibility reasons, Glibc off_t is a 32-bit type on 32-bit x86 > unless _FILE_OFFSET_BITS=64 is defined. Add this define, as otherwise > reading MSRs with index 0x8000 and above attempts a pread with a > negative offset, which fails. > > Signed-off-by: Alexander Monakov > --- > tools/power/x86/turbostat/Makefile | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tools/power/x86/turbostat/Makefile > b/tools/power/x86/turbostat/Makefile > index 2b6551269e43..40ae44402eec 100644 > --- a/tools/power/x86/turbostat/Makefile > +++ b/tools/power/x86/turbostat/Makefile > @@ -12,6 +12,7 @@ turbostat : turbostat.c > override CFLAGS += -O2 -Wall -I../../../include > override CFLAGS += > -DMSRHEADER='"../../../../arch/x86/include/asm/msr-index.h"' > override CFLAGS += > -DINTEL_FAMILY_HEADER='"../../../../arch/x86/include/asm/intel-family.h"' > +override CFLAGS += -D_FILE_OFFSET_BITS=64 > override CFLAGS += -D_FORTIFY_SOURCE=2 > > %: %.c >
[PATCH V2] arm64/hotplug: Improve memory offline event notifier
This brings about three different changes to the sole memory event notifier
for arm64 platform and improves it's robustness while also enhancing debug
capabilities during potential memory offlining error conditions.
This moves the memory notifier registration bit earlier in the boot process
from device_initcall() to setup_arch() which will help in guarding against
potential early boot memory offline requests.
This enables MEM_OFFLINE memory event handling. It will help intercept any
possible error condition such as if boot memory some how still got offlined
even after an expilicit notifier failure, potentially by a future change in
generic hotplug framework. This would help detect such scenarious and help
debug further.
It also adds a validation function which scans entire boot memory and makes
sure that early memory sections are online. This check is essential for the
memory notifier to work properly as it cannot prevent boot memory offlining
if they are not online to begin with. But this additional sanity check is
enabled only with DEBUG_VM.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Steve Capper
Cc: Mark Brown
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual
---
This applies on 5.9-rc2
Changes in V2:
- Dropped all generic changes wrt MEM_CANCEL_OFFLINE reasons enumeration
- Dropped all related (processing MEM_CANCEL_OFFLINE reasons) changes on arm64
- Added validate_boot_mem_online_state() that gets called with early_initcall()
- Added CONFIG_MEMORY_HOTREMOVE check before registering memory notifier
- Moved notifier registration i.e memory_hotremove_notifier into setup_arch()
Changes in V1:
(https://patchwork.kernel.org/project/linux-mm/list/?series=271237)
arch/arm64/include/asm/mmu.h | 8 +++
arch/arm64/kernel/setup.c| 8 +++
arch/arm64/mm/mmu.c | 108 ---
3 files changed, 116 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
index a7a5ecaa2e83..b7e99b528766 100644
--- a/arch/arm64/include/asm/mmu.h
+++ b/arch/arm64/include/asm/mmu.h
@@ -73,6 +73,14 @@ static inline struct bp_hardening_data
*arm64_get_bp_hardening_data(void)
static inline void arm64_apply_bp_hardening(void) { }
#endif /* CONFIG_HARDEN_BRANCH_PREDICTOR */
+#ifdef CONFIG_MEMORY_HOTPLUG
+extern void memory_hotremove_notifier(void);
+#else
+static inline void memory_hotremove_notifier(void)
+{
+}
+#endif /* CONFIG_MEMORY_HOTPLUG */
+
extern void arm64_memblock_init(void);
extern void paging_init(void);
extern void bootmem_init(void);
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 77c4c9bad1b8..44406c9f8d83 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -376,6 +376,14 @@ void __init __no_sanitize_address setup_arch(char
**cmdline_p)
"This indicates a broken bootloader or old kernel\n",
boot_args[1], boot_args[2], boot_args[3]);
}
+
+ /*
+* Register the memory notifier which will prevent boot
+* memory offlining requests - early enough. But there
+* should not be any actual offlinig request till memory
+* block devices are initialized with memory_dev_init().
+*/
+ memory_hotremove_notifier();
}
static inline bool cpu_can_disable(unsigned int cpu)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 75df62fea1b6..8cdb0b02089f 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1482,13 +1482,40 @@ static int prevent_bootmem_remove_notifier(struct
notifier_block *nb,
unsigned long end_pfn = arg->start_pfn + arg->nr_pages;
unsigned long pfn = arg->start_pfn;
- if (action != MEM_GOING_OFFLINE)
+ if ((action != MEM_GOING_OFFLINE) && (action != MEM_OFFLINE))
return NOTIFY_OK;
- for (; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
- ms = __pfn_to_section(pfn);
- if (early_section(ms))
- return NOTIFY_BAD;
+ if (action == MEM_GOING_OFFLINE) {
+ for (; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
+ ms = __pfn_to_section(pfn);
+ if (early_section(ms)) {
+ pr_warn("Boot memory offlining attempted\n");
+ return NOTIFY_BAD;
+ }
+ }
+ } else if (action == MEM_OFFLINE) {
+ for (; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
+ ms = __pfn_to_section(pfn);
+ if (early_section(ms)) {
+
+ /*
+* This should have never happened. Boot memory
+* offlining should have been prevented by this
+* very notifier. Probably some
Re: [PATCH v1 06/10] powerpc/pseries/iommu: Add ddw_list_add() helper
On 18/08/2020 09:40, Leonardo Bras wrote:
> There are two functions adding DDW to the direct_window_list in a
> similar way, so create a ddw_list_add() to avoid duplicity and
> simplify those functions.
>
> Also, on enable_ddw(), add list_del() on out_free_window to allow
> removing the window from list if any error occurs.
>
> Signed-off-by: Leonardo Bras
> ---
> arch/powerpc/platforms/pseries/iommu.c | 42 --
> 1 file changed, 26 insertions(+), 16 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/iommu.c
> b/arch/powerpc/platforms/pseries/iommu.c
> index 39617ce0ec83..fcdefcc0f365 100644
> --- a/arch/powerpc/platforms/pseries/iommu.c
> +++ b/arch/powerpc/platforms/pseries/iommu.c
> @@ -872,6 +872,24 @@ static u64 find_existing_ddw(struct device_node *pdn)
> return dma_addr;
> }
>
> +static struct direct_window *ddw_list_add(struct device_node *pdn,
> + const struct dynamic_dma_window_prop
> *dma64)
> +{
> + struct direct_window *window;
> +
> + window = kzalloc(sizeof(*window), GFP_KERNEL);
> + if (!window)
> + return NULL;
> +
> + window->device = pdn;
> + window->prop = dma64;
> + spin_lock(_window_list_lock);
> + list_add(>list, _window_list);
> + spin_unlock(_window_list_lock);
> +
> + return window;
> +}
> +
> static int find_existing_ddw_windows(void)
> {
> int len;
> @@ -887,18 +905,11 @@ static int find_existing_ddw_windows(void)
> if (!direct64)
> continue;
>
> - window = kzalloc(sizeof(*window), GFP_KERNEL);
> - if (!window || len < sizeof(struct dynamic_dma_window_prop)) {
> + window = ddw_list_add(pdn, direct64);
> + if (!window || len < sizeof(*direct64)) {
Since you are touching this code, it looks like the "len <
sizeof(*direct64)" part should go above to "if (!direct64)".
> kfree(window);
> remove_ddw(pdn, true);
> - continue;
> }
> -
> - window->device = pdn;
> - window->prop = direct64;
> - spin_lock(_window_list_lock);
> - list_add(>list, _window_list);
> - spin_unlock(_window_list_lock);
> }
>
> return 0;
> @@ -1261,7 +1272,8 @@ static u64 enable_ddw(struct pci_dev *dev, struct
> device_node *pdn)
> dev_dbg(>dev, "created tce table LIOBN 0x%x for %pOF\n",
> create.liobn, dn);
>
> - window = kzalloc(sizeof(*window), GFP_KERNEL);
> + /* Add new window to existing DDW list */
The comment seems to duplicate what the ddw_list_add name already suggests.
> + window = ddw_list_add(pdn, ddwprop);
> if (!window)
> goto out_clear_window;
>
> @@ -1280,16 +1292,14 @@ static u64 enable_ddw(struct pci_dev *dev, struct
> device_node *pdn)
> goto out_free_window;
> }
>
> - window->device = pdn;
> - window->prop = ddwprop;
> - spin_lock(_window_list_lock);
> - list_add(>list, _window_list);
> - spin_unlock(_window_list_lock);
I'd leave these 3 lines here and in find_existing_ddw_windows() (which
would make ddw_list_add -> ddw_prop_alloc). In general you want to have
less stuff to do on the failure path. kmalloc may fail and needs kfree
but you can safely delay list_add (which cannot fail) and avoid having
the lock help twice in the same function (one of them is hidden inside
ddw_list_add).
Not sure if this change is really needed after all. Thanks,
> -
> dma_addr = be64_to_cpu(ddwprop->dma_base);
> goto out_unlock;
>
> out_free_window:
> + spin_lock(_window_list_lock);
> + list_del(>list);
> + spin_unlock(_window_list_lock);
> +
> kfree(window);
>
> out_clear_window:
>
--
Alexey
Re: [PATCH v2] h8300: Replace by
On Wed, 19 Aug 2020 21:29:25 +0900, Geert Uytterhoeven wrote: > > The H8/300 platform code is not a clock provider, and just needs to call > of_clk_init(). > > Hence it can include instead of . > > Signed-off-by: Geert Uytterhoeven > Reviewed-by: Stephen Boyd > --- > v2: > - Add Reviewed-by. > --- > arch/h8300/kernel/setup.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/h8300/kernel/setup.c b/arch/h8300/kernel/setup.c > index 28ac88358a89a4f9..0ecaac7dd7e93d9f 100644 > --- a/arch/h8300/kernel/setup.c > +++ b/arch/h8300/kernel/setup.c > @@ -24,7 +24,7 @@ > #include > #include > #include > -#include > +#include > #include > #include > #include > -- > 2.17.1 > Applied h8300-next. Thanks. -- Yosinori Sato
Re: [PATCH v1 07/10] powerpc/pseries/iommu: Allow DDW windows starting at 0x00
On 18/08/2020 09:40, Leonardo Bras wrote:
> enable_ddw() currently returns the address of the DMA window, which is
> considered invalid if has the value 0x00.
>
> Also, it only considers valid an address returned from find_existing_ddw
> if it's not 0x00.
>
> Changing this behavior makes sense, given the users of enable_ddw() only
> need to know if direct mapping is possible. It can also allow a DMA window
> starting at 0x00 to be used.
>
> This will be helpful for using a DDW with indirect mapping, as the window
> address will be different than 0x00, but it will not map the whole
> partition.
>
> Signed-off-by: Leonardo Bras
> ---
> arch/powerpc/platforms/pseries/iommu.c | 30 --
> 1 file changed, 14 insertions(+), 16 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/iommu.c
> b/arch/powerpc/platforms/pseries/iommu.c
> index fcdefcc0f365..4031127c9537 100644
> --- a/arch/powerpc/platforms/pseries/iommu.c
> +++ b/arch/powerpc/platforms/pseries/iommu.c
> @@ -852,24 +852,25 @@ static void remove_ddw(struct device_node *np, bool
> remove_prop)
> np, ret);
> }
>
> -static u64 find_existing_ddw(struct device_node *pdn)
> +static bool find_existing_ddw(struct device_node *pdn, u64 *dma_addr)
> {
> struct direct_window *window;
> const struct dynamic_dma_window_prop *direct64;
> - u64 dma_addr = 0;
> + bool found = false;
>
> spin_lock(_window_list_lock);
> /* check if we already created a window and dupe that config if so */
> list_for_each_entry(window, _window_list, list) {
> if (window->device == pdn) {
> direct64 = window->prop;
> - dma_addr = be64_to_cpu(direct64->dma_base);
> + *dma_addr = be64_to_cpu(direct64->dma_base);
> + found = true;
> break;
> }
> }
> spin_unlock(_window_list_lock);
>
> - return dma_addr;
> + return found;
> }
>
> static struct direct_window *ddw_list_add(struct device_node *pdn,
> @@ -1131,15 +1132,15 @@ static void reset_dma_window(struct pci_dev *dev,
> struct device_node *par_dn)
> * pdn: the parent pe node with the ibm,dma_window property
> * Future: also check if we can remap the base window for our base page size
> *
> - * returns the dma offset for use by the direct mapped DMA code.
> + * returns true if can map all pages (direct mapping), false otherwise..
> */
> -static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
> +static bool enable_ddw(struct pci_dev *dev, struct device_node *pdn)
> {
> int len, ret;
> struct ddw_query_response query;
> struct ddw_create_response create;
> int page_shift;
> - u64 dma_addr, max_addr;
> + u64 max_addr;
> struct device_node *dn;
> u32 ddw_avail[DDW_APPLICABLE_SIZE];
> struct direct_window *window;
> @@ -1150,8 +1151,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct
> device_node *pdn)
>
> mutex_lock(_window_init_mutex);
>
> - dma_addr = find_existing_ddw(pdn);
> - if (dma_addr != 0)
> + if (find_existing_ddw(pdn, >dev.archdata.dma_offset))
> goto out_unlock;
>
> /*
> @@ -1292,7 +1292,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct
> device_node *pdn)
> goto out_free_window;
> }
>
> - dma_addr = be64_to_cpu(ddwprop->dma_base);
> + dev->dev.archdata.dma_offset = be64_to_cpu(ddwprop->dma_base);
Do not you need the same chunk in the find_existing_ddw() case above as
well? Thanks,
> goto out_unlock;
>
> out_free_window:
> @@ -1309,6 +1309,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct
> device_node *pdn)
> kfree(win64->name);
> kfree(win64->value);
> kfree(win64);
> + win64 = NULL;
>
> out_failed:
> if (default_win_removed)
> @@ -1322,7 +1323,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct
> device_node *pdn)
>
> out_unlock:
> mutex_unlock(_window_init_mutex);
> - return dma_addr;
> + return win64;
> }
>
> static void pci_dma_dev_setup_pSeriesLP(struct pci_dev *dev)
> @@ -1401,11 +1402,8 @@ static bool iommu_bypass_supported_pSeriesLP(struct
> pci_dev *pdev, u64 dma_mask)
> break;
> }
>
> - if (pdn && PCI_DN(pdn)) {
> - pdev->dev.archdata.dma_offset = enable_ddw(pdev, pdn);
> - if (pdev->dev.archdata.dma_offset)
> - return true;
> - }
> + if (pdn && PCI_DN(pdn))
> + return enable_ddw(pdev, pdn);
>
> return false;
> }
>
--
Alexey
[GIT PULL] fallthrough pseudo-keyword macro conversions for 5.9-rc3
Hi Linus, Not sure what the problem was with my pull-request for -rc2. So, I'm giving this a second try because I think it is worth it. I have build-tested this patch on 10 different architectures: x86_64, i386, arm64, powerpc, s390, sparc64, sh, m68k, powerpc64 and alpha (allyesconfig/ allmodconfig for all of them). This is in linux-next already and kernel test robot has also helped me to successfully build-test early versions of this patch[2][3][4][5]. This patch does not introduce any new warnings. Thank you -- Gustavo [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through [2] https://lore.kernel.org/lkml/5f3cc99a.hgvow3rh0md0rmkm%25...@intel.com/ [3] https://lore.kernel.org/lkml/5f3dd1d2.l1axczh+t4hmbz63%25...@intel.com/ [4] https://lore.kernel.org/lkml/5f3e977a.mwyhuiobbr4shr0b%25...@intel.com/ [5] https://lore.kernel.org/lkml/5f3f9e1c.qsyb%2fayskixnpko4%25...@intel.com/ The following changes since commit d012a7190fc1fd72ed48911e77ca97ba4521bccd: Linux 5.9-rc2 (2020-08-23 14:08:43 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux.git tags/fallthrough-pseudo-keyword-5.9-rc3 for you to fetch changes up to df561f6688fef775baa341a0f5d960becd248b11: treewide: Use fallthrough pseudo-keyword (2020-08-23 17:36:59 -0500) fallthrough pseudo-keyword macro conversions for 5.9-rc3 Hi Linus, Please, pull the following tree-wide patch that replaces tons (2484) of /* fall through */ comments, and its variants, with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. There are currently 1167 intances of this fallthrough pseudo-keyword macro in mainline (5.9-rc2), that have been introduced over the last couple of development cycles: $ git grep -nw 'fallthrough;' | wc -l 1167 The global adoption of the fallthrough pseudo-keyword is something certain to happen; so, better sooner than later. :) This will also save everybody's time and thousands of lines of unnecessarily repetitive changelog text. After applying this patch on top of 5.9-rc2, we'll have a total of 3651 instances of this macro: $ git grep -nw 'fallthrough;' | wc -l 3651 This treewide patch doesn't address ALL fall-through markings in all subsystems at once because I have previously sent out patches for some of such subsystems separately, and I will follow up on them; however, this definitely contributes most of the work needed to replace all the fall-through markings with the fallthrough pseudo-keyword macro in the whole codebase. I have build-tested this patch on 10 different architectures: x86_64, i386, arm64, powerpc, s390, sparc64, sh, m68k, powerpc64 and alpha (allyesconfig for all of them). This is in linux-next already and kernel test robot has also helped me to successfully build-test early versions of this patch[2][3][4][5]. Thanks -- [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through [2] https://lore.kernel.org/lkml/5f3cc99a.hgvow3rh0md0rmkm%25...@intel.com/ [3] https://lore.kernel.org/lkml/5f3dd1d2.l1axczh+t4hmbz63%25...@intel.com/ [4] https://lore.kernel.org/lkml/5f3e977a.mwyhuiobbr4shr0b%25...@intel.com/ [5] https://lore.kernel.org/lkml/5f3f9e1c.qsyb%2fayskixnpko4%25...@intel.com/ Gustavo A. R. Silva (1): treewide: Use fallthrough pseudo-keyword arch/alpha/kernel/module.c | 2 +- arch/alpha/kernel/signal.c | 2 +- arch/alpha/kernel/traps.c | 4 +- arch/arc/kernel/disasm.c | 2 +- arch/arc/kernel/signal.c | 2 +- arch/arc/kernel/unwind.c | 6 +- arch/arm/kernel/hw_breakpoint.c| 10 +- arch/arm/kernel/signal.c | 2 +- arch/arm/mach-ep93xx/crunch.c | 2 +- arch/arm/mach-mmp/pm-mmp2.c| 8 +- arch/arm/mach-mmp/pm-pxa910.c | 10 +- arch/arm/mach-omap2/id.c | 8 -- arch/arm/mach-omap2/omap_device.c | 2 +- arch/arm/mach-orion5x/dns323-setup.c | 2 +- arch/arm/mach-rpc/riscpc.c | 2 +- arch/arm/mach-tegra/reset.c| 2 +- arch/arm/mm/alignment.c| 4 +- arch/arm/mm/proc-v7-bugs.c | 2 +- arch/arm/plat-omap/dma.c | 6 +- arch/arm/probes/decode.c | 2 +- arch/arm/probes/kprobes/core.c | 2 +- arch/arm64/kernel/acpi.c | 2 +- arch/arm64/kernel/cpufeature.c | 2 +-
Re: [PATCH v2] h8300: dts: Fix /chosen:stdout-path
On Wed, 19 Aug 2020 21:28:38 +0900,
Geert Uytterhoeven wrote:
>
> arch/h8300/boot/dts/h8s_sim.dts:11.3-25: Warning
> (chosen_node_stdout_path): /chosen:stdout-path: property is not a string
> arch/h8300/boot/dts/h8300h_sim.dts:11.3-25: Warning
> (chosen_node_stdout_path): /chosen:stdout-path: property is not a string
>
> Drop the angle brackets to fix this.
>
> A similar fix was already applied to arch/h8300/boot/dts/edosk2674.dts
> in commit 780ffcd51cb28717 ("h8300: register address fix").
>
> Fixes: 38d6bded13084d50 ("h8300: devicetree source")
> Signed-off-by: Geert Uytterhoeven
> Reviewed-by: Masahiro Yamada
> ---
> v2:
> - Add Reviewed-by.
> ---
> arch/h8300/boot/dts/h8300h_sim.dts | 2 +-
> arch/h8300/boot/dts/h8s_sim.dts| 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/h8300/boot/dts/h8300h_sim.dts
> b/arch/h8300/boot/dts/h8300h_sim.dts
> index 595398b9d0180a80..e1d4d9b7f6b40c04 100644
> --- a/arch/h8300/boot/dts/h8300h_sim.dts
> +++ b/arch/h8300/boot/dts/h8300h_sim.dts
> @@ -8,7 +8,7 @@
>
> chosen {
> bootargs = "earlyprintk=h8300-sim";
> - stdout-path = <>;
> + stdout-path =
> };
> aliases {
> serial0 =
> diff --git a/arch/h8300/boot/dts/h8s_sim.dts b/arch/h8300/boot/dts/h8s_sim.dts
> index 932cc3c5a81bcdd2..4848e40e607ecc1d 100644
> --- a/arch/h8300/boot/dts/h8s_sim.dts
> +++ b/arch/h8300/boot/dts/h8s_sim.dts
> @@ -8,7 +8,7 @@
>
> chosen {
> bootargs = "earlyprintk=h8300-sim";
> - stdout-path = <>;
> + stdout-path =
> };
> aliases {
> serial0 =
> --
> 2.17.1
>
Applied h8300-next.
Thanks.
--
Yosinori Sato
[PATCH v10 2/2] Add PWM fan controller driver for LGM SoC
Intel Lightning Mountain(LGM) SoC contains a PWM fan controller.
This PWM controller does not have any other consumer, it is a
dedicated PWM controller for fan attached to the system. Add
driver for this PWM fan controller.
Signed-off-by: Rahul Tanwar
---
drivers/pwm/Kconfig | 11 ++
drivers/pwm/Makefile| 1 +
drivers/pwm/pwm-intel-lgm.c | 242
3 files changed, 254 insertions(+)
create mode 100644 drivers/pwm/pwm-intel-lgm.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 7dbcf6973d33..4949c51fe90b 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -232,6 +232,17 @@ config PWM_IMX_TPM
To compile this driver as a module, choose M here: the module
will be called pwm-imx-tpm.
+config PWM_INTEL_LGM
+ tristate "Intel LGM PWM support"
+ depends on HAS_IOMEM
+ depends on (OF && X86) || COMPILE_TEST
+ select REGMAP_MMIO
+ help
+ Generic PWM fan controller driver for LGM SoC.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-intel-lgm.
+
config PWM_IQS620A
tristate "Azoteq IQS620A PWM support"
depends on MFD_IQS62X || COMPILE_TEST
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 2c2ba0a03557..e9431b151694 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_PWM_IMG) += pwm-img.o
obj-$(CONFIG_PWM_IMX1) += pwm-imx1.o
obj-$(CONFIG_PWM_IMX27)+= pwm-imx27.o
obj-$(CONFIG_PWM_IMX_TPM) += pwm-imx-tpm.o
+obj-$(CONFIG_PWM_INTEL_LGM)+= pwm-intel-lgm.o
obj-$(CONFIG_PWM_IQS620A) += pwm-iqs620a.o
obj-$(CONFIG_PWM_JZ4740) += pwm-jz4740.o
obj-$(CONFIG_PWM_LP3943) += pwm-lp3943.o
diff --git a/drivers/pwm/pwm-intel-lgm.c b/drivers/pwm/pwm-intel-lgm.c
new file mode 100644
index ..bfe784be3809
--- /dev/null
+++ b/drivers/pwm/pwm-intel-lgm.c
@@ -0,0 +1,242 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Intel Corporation.
+ *
+ * Limitations:
+ * - The hardware supports fixed period which is dependent on 2/3 or 4
+ * wire fan mode.
+ * - Supports normal polarity. Does not support changing polarity.
+ * - When PWM is disabled, output of PWM will become 0(inactive). It doesn't
+ * keep track of running period.
+ * - When duty cycle is changed, PWM output may be a mix of previous setting
+ * and new setting for the first period. From second period, the output is
+ * based on new setting.
+ * - It is a dedicated PWM fan controller. There are no other consumers for
+ * this PWM controller.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LGM_PWM_FAN_CON0 0x0
+#define LGM_PWM_FAN_EN_EN BIT(0)
+#define LGM_PWM_FAN_EN_DIS 0x0
+#define LGM_PWM_FAN_EN_MSK BIT(0)
+#define LGM_PWM_FAN_MODE_2WIRE 0x0
+#define LGM_PWM_FAN_MODE_MSK BIT(1)
+#define LGM_PWM_FAN_DC_MSK GENMASK(23, 16)
+
+#define LGM_PWM_FAN_CON1 0x4
+#define LGM_PWM_FAN_MAX_RPM_MSKGENMASK(15, 0)
+
+#define LGM_PWM_MAX_RPM(BIT(16) - 1)
+#define LGM_PWM_DEFAULT_RPM4000
+#define LGM_PWM_MAX_DUTY_CYCLE (BIT(8) - 1)
+
+#define LGM_PWM_DC_BITS8
+
+#define LGM_PWM_PERIOD_2WIRE_NS(40 * NSEC_PER_MSEC)
+
+struct lgm_pwm_chip {
+ struct pwm_chip chip;
+ struct regmap *regmap;
+ struct clk *clk;
+ struct reset_control *rst;
+ u32 period;
+};
+
+static inline struct lgm_pwm_chip *to_lgm_pwm_chip(struct pwm_chip *chip)
+{
+ return container_of(chip, struct lgm_pwm_chip, chip);
+}
+
+static int lgm_pwm_enable(struct pwm_chip *chip, bool enable)
+{
+ struct lgm_pwm_chip *pc = to_lgm_pwm_chip(chip);
+ struct regmap *regmap = pc->regmap;
+
+ return regmap_update_bits(regmap, LGM_PWM_FAN_CON0, LGM_PWM_FAN_EN_MSK,
+ enable ? LGM_PWM_FAN_EN_EN :
LGM_PWM_FAN_EN_DIS);
+}
+
+static int lgm_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+const struct pwm_state *state)
+{
+ struct lgm_pwm_chip *pc = to_lgm_pwm_chip(chip);
+ u32 duty_cycle, val;
+ int ret;
+
+ /*
+* The hardware only supports
+* normal polarity and fixed period.
+*/
+ if (state->polarity != PWM_POLARITY_NORMAL || state->period <
pc->period)
+ return -EINVAL;
+
+ if (!state->enabled)
+ return lgm_pwm_enable(chip, 0);
+
+ duty_cycle = min_t(u64, state->duty_cycle, pc->period);
+ val = duty_cycle * LGM_PWM_MAX_DUTY_CYCLE / pc->period;
+
+ ret = regmap_update_bits(pc->regmap, LGM_PWM_FAN_CON0,
LGM_PWM_FAN_DC_MSK,
+FIELD_PREP(LGM_PWM_FAN_DC_MSK, val));
+ if (ret)
+
[PATCH v10 0/2] pwm: intel: Add PWM driver for a new SoC
Patch 1 adds dt binding document in YAML format. Patch 2 add PWM fan controller driver for LGM SoC. v10: - Removed unused of_device.h and added platform_device.h & mod_devicetable.h v9: - Address code quality related review concerns (Andy Shevchenko) - Use devm_add_action_or_reset() instead of explicit unwind calls. v8: - Remove fan related optional properties usage, keep them as default. If needed, change pwm-fan driver separately in future to add them as generic properties. v7: - Address code quality related review concerns. - Rename fan related property to pwm-*. - Fix one make dt_binding_check reported error. v6: - Readjust .apply op as per review feedback. - Add back pwm-cells property to resolve make dt_binding_check error. pwm-cells is a required property for PWM driver. - Add back fan related optional properties. v5: - Address below review concerns from Uwe Kleine-K�nig. * Improve comments about Limitations. * Use return value of regmap_update_bits if container function returns error code. * Modify .apply op to have strict checking for fixed period supported by PWM HW. * Use u64 as type when use min_t for duty_cycle. * Add reset_control_assert() in failure case in probe where it was missing earlier. - Remove fan specific optional properties from pwm dt binding document (Rob Herring) v4: - Address below review concerns from Uwe Kleine-K�nig. * Improve notes and limitations comments. * Add common prefixes for all #defines. * Modify/Improve logic in .apply & .get_state ops as advised. * Skip error messages in probe when error is -EPROBE_DEFER. * Add dependencies in Kconfig (OF & HAS_IOMEM) and add select REGMAP_MMIO. * Address other code quality related review concerns. - Fix make dt_binding_check reported error in YAML file. v3: - Address below review concerns from Uwe Kleine-K�nig. * Remove fan rpm calibration task from the driver. * Modify apply op as per the review feedback. * Add roundup & round down where necessary. * Address other misc code quality related review concerns. * Use devm_reset_control_get_exclusive(). (Philipp Zabel) * Improve dt binding document. v2: - Address below review concerns from Uwe Kleine-K�nig. * Add notes and limitations about PWM HW. * Rename all functions and structure to lgm_pwm_* * Readjust space aligninment in structure fields to single space. * Switch to using apply instead of config/enable/disable. * Address other code quality related concerns. * Rebase to 5.8-rc1. - Address review concerns in dt binding YAML from Rob Herring. v1: - Initial version. Rahul Tanwar (2): Add DT bindings YAML schema for PWM fan controller of LGM SoC Add PWM fan controller driver for LGM SoC .../devicetree/bindings/pwm/intel,lgm-pwm.yaml | 44 drivers/pwm/Kconfig| 11 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm-intel-lgm.c| 242 + 4 files changed, 298 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml create mode 100644 drivers/pwm/pwm-intel-lgm.c -- 2.11.0
[PATCH v10 1/2] Add DT bindings YAML schema for PWM fan controller of LGM SoC
Intel's LGM(Lightning Mountain) SoC contains a PWM fan controller
which is only used to control the fan attached to the system. This
PWM controller does not have any other consumer other than fan.
Add DT bindings documentation for this PWM fan controller.
Signed-off-by: Rahul Tanwar
---
.../devicetree/bindings/pwm/intel,lgm-pwm.yaml | 44 ++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml
diff --git a/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml
b/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml
new file mode 100644
index ..11a606536169
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/intel,lgm-pwm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LGM SoC PWM fan controller
+
+maintainers:
+ - Rahul Tanwar
+
+properties:
+ compatible:
+const: intel,lgm-pwm
+
+ reg:
+maxItems: 1
+
+ "#pwm-cells":
+const: 2
+
+ clocks:
+maxItems: 1
+
+ resets:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+
+additionalProperties: false
+
+examples:
+ - |
+pwm: pwm@e0d0 {
+compatible = "intel,lgm-pwm";
+reg = <0xe0d0 0x30>;
+#pwm-cells = <2>;
+clocks = < 126>;
+resets = < 0x30 21>;
+};
--
2.11.0
Re: [PATCH] media: staging/intel-ipu3: css: Correctly reset some memory
Thanks for the patch.
On 8/22/20 9:11 PM, Christophe JAILLET wrote:
> The intent here is to reset the whole 'scaler_coeffs_luma' array, not just
> the first element.
>
> Fixes:e0a5b744 ("media: staging/intel-ipu3: css: Compute and
> program ccs")
> Signed-off-by: Christophe JAILLET
> ---
> drivers/staging/media/ipu3/ipu3-css-params.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/ipu3/ipu3-css-params.c
> b/drivers/staging/media/ipu3/ipu3-css-params.c
> index fbd53d7c097c..e9d6bd9e9332 100644
> --- a/drivers/staging/media/ipu3/ipu3-css-params.c
> +++ b/drivers/staging/media/ipu3/ipu3-css-params.c
> @@ -159,7 +159,7 @@ imgu_css_scaler_calc(u32 input_width, u32 input_height,
> u32 target_width,
>
> memset(>scaler_coeffs_chroma, 0,
> sizeof(cfg->scaler_coeffs_chroma));
> - memset(>scaler_coeffs_luma, 0, sizeof(*cfg->scaler_coeffs_luma));
> + memset(>scaler_coeffs_luma, 0, sizeof(cfg->scaler_coeffs_luma));
> do {
> phase_step_correction++;
>
>
Reviewed-by: Bingbu Cao
--
Best regards,
Bingbu Cao
[PATCH RESEND 02/10] crypto: hisilicon/zip - unify naming style for functions and macros
1.Add prefix 'HZIP' for some macros
2.Add prefix 'hisi_zip' for some functions
Signed-off-by: Yang Shen
Reviewed-by: Zhou Wang
---
drivers/crypto/hisilicon/zip/zip_main.c | 35 +
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/crypto/hisilicon/zip/zip_main.c
b/drivers/crypto/hisilicon/zip/zip_main.c
index 445db04..058f744 100644
--- a/drivers/crypto/hisilicon/zip/zip_main.c
+++ b/drivers/crypto/hisilicon/zip/zip_main.c
@@ -29,18 +29,18 @@
#define DECOMP3_ENABLE BIT(5)
#define DECOMP4_ENABLE BIT(6)
#define DECOMP5_ENABLE BIT(7)
-#define ALL_COMP_DECOMP_EN (COMP0_ENABLE | COMP1_ENABLE | \
+#define HZIP_ALL_COMP_DECOMP_EN(COMP0_ENABLE | COMP1_ENABLE | \
DECOMP0_ENABLE | DECOMP1_ENABLE | \
DECOMP2_ENABLE | DECOMP3_ENABLE | \
DECOMP4_ENABLE | DECOMP5_ENABLE)
-#define DECOMP_CHECK_ENABLEBIT(16)
+#define HZIP_DECOMP_CHECK_ENABLE BIT(16)
#define HZIP_FSM_MAX_CNT 0x301008
#define HZIP_PORT_ARCA_CHE_0 0x301040
#define HZIP_PORT_ARCA_CHE_1 0x301044
#define HZIP_PORT_AWCA_CHE_0 0x301060
#define HZIP_PORT_AWCA_CHE_1 0x301064
-#define CACHE_ALL_EN 0x
+#define HZIP_CACHE_ALL_EN 0x
#define HZIP_BD_RUSER_32_630x301110
#define HZIP_SGL_RUSER_32_63 0x30111c
@@ -82,7 +82,7 @@
#define HZIP_PF_DEF_Q_BASE 0
#define HZIP_SOFT_CTRL_CNT_CLR_CE 0x301000
-#define SOFT_CTRL_CNT_CLR_CE_BIT BIT(0)
+#define HZIP_SOFT_CTRL_CNT_CLR_CE_BIT BIT(0)
#define HZIP_SOFT_CTRL_ZIP_CONTROL 0x30100C
#define HZIP_AXI_SHUTDOWN_ENABLE BIT(14)
#define HZIP_WR_PORT BIT(11)
@@ -264,10 +264,10 @@ static int hisi_zip_set_user_domain_and_cache(struct
hisi_qm *qm)
writel(PEH_AXUSER_CFG_ENABLE, base + QM_PEH_AXUSER_CFG_ENABLE);
/* cache */
- writel(CACHE_ALL_EN, base + HZIP_PORT_ARCA_CHE_0);
- writel(CACHE_ALL_EN, base + HZIP_PORT_ARCA_CHE_1);
- writel(CACHE_ALL_EN, base + HZIP_PORT_AWCA_CHE_0);
- writel(CACHE_ALL_EN, base + HZIP_PORT_AWCA_CHE_1);
+ writel(HZIP_CACHE_ALL_EN, base + HZIP_PORT_ARCA_CHE_0);
+ writel(HZIP_CACHE_ALL_EN, base + HZIP_PORT_ARCA_CHE_1);
+ writel(HZIP_CACHE_ALL_EN, base + HZIP_PORT_AWCA_CHE_0);
+ writel(HZIP_CACHE_ALL_EN, base + HZIP_PORT_AWCA_CHE_1);
/* user domain configurations */
writel(AXUSER_BASE, base + HZIP_BD_RUSER_32_63);
@@ -283,7 +283,7 @@ static int hisi_zip_set_user_domain_and_cache(struct
hisi_qm *qm)
}
/* let's open all compression/decompression cores */
- writel(DECOMP_CHECK_ENABLE | ALL_COMP_DECOMP_EN,
+ writel(HZIP_DECOMP_CHECK_ENABLE | HZIP_ALL_COMP_DECOMP_EN,
base + HZIP_CLOCK_GATE_CTRL);
/* enable sqc writeback */
@@ -390,7 +390,7 @@ static u32 clear_enable_read(struct ctrl_debug_file *file)
struct hisi_qm *qm = file_to_qm(file);
return readl(qm->io_base + HZIP_SOFT_CTRL_CNT_CLR_CE) &
- SOFT_CTRL_CNT_CLR_CE_BIT;
+HZIP_SOFT_CTRL_CNT_CLR_CE_BIT;
}
static int clear_enable_write(struct ctrl_debug_file *file, u32 val)
@@ -402,14 +402,14 @@ static int clear_enable_write(struct ctrl_debug_file
*file, u32 val)
return -EINVAL;
tmp = (readl(qm->io_base + HZIP_SOFT_CTRL_CNT_CLR_CE) &
- ~SOFT_CTRL_CNT_CLR_CE_BIT) | val;
+ ~HZIP_SOFT_CTRL_CNT_CLR_CE_BIT) | val;
writel(tmp, qm->io_base + HZIP_SOFT_CTRL_CNT_CLR_CE);
return 0;
}
-static ssize_t ctrl_debug_read(struct file *filp, char __user *buf,
- size_t count, loff_t *pos)
+static ssize_t hisi_zip_ctrl_debug_read(struct file *filp, char __user *buf,
+ size_t count, loff_t *pos)
{
struct ctrl_debug_file *file = filp->private_data;
char tbuf[HZIP_BUF_SIZE];
@@ -433,8 +433,9 @@ static ssize_t ctrl_debug_read(struct file *filp, char
__user *buf,
return simple_read_from_buffer(buf, count, pos, tbuf, ret);
}
-static ssize_t ctrl_debug_write(struct file *filp, const char __user *buf,
- size_t count, loff_t *pos)
+static ssize_t hisi_zip_ctrl_debug_write(struct file *filp,
+const char __user *buf,
+size_t count, loff_t *pos)
{
struct ctrl_debug_file *file = filp->private_data;
char tbuf[HZIP_BUF_SIZE];
@@ -483,8 +484,8 @@ static ssize_t ctrl_debug_write(struct file *filp, const
char __user *buf,
static const struct file_operations ctrl_debug_fops = {
.owner = THIS_MODULE,
.open = simple_open,
- .read =
[PATCH RESEND 06/10] crypto: hisilicon/zip - add print for error branch
Add print for some error branches.
Signed-off-by: Yang Shen
Reviewed-by: Zhou Wang
---
drivers/crypto/hisilicon/zip/zip_crypto.c | 68 +++
drivers/crypto/hisilicon/zip/zip_main.c | 8 ++--
2 files changed, 56 insertions(+), 20 deletions(-)
diff --git a/drivers/crypto/hisilicon/zip/zip_crypto.c
b/drivers/crypto/hisilicon/zip/zip_crypto.c
index c2ea849..7aa8a55 100644
--- a/drivers/crypto/hisilicon/zip/zip_crypto.c
+++ b/drivers/crypto/hisilicon/zip/zip_crypto.c
@@ -146,7 +146,7 @@ static int hisi_zip_start_qp(struct hisi_qp *qp, struct
hisi_zip_qp_ctx *ctx,
ret = hisi_qm_start_qp(qp, 0);
if (ret < 0) {
- dev_err(dev, "start qp failed!\n");
+ dev_err(dev, "Start qp failed (%d)!\n", ret);
return ret;
}
@@ -169,7 +169,7 @@ static int hisi_zip_ctx_init(struct hisi_zip_ctx
*hisi_zip_ctx, u8 req_type, int
ret = zip_create_qps(qps, HZIP_CTX_Q_NUM, node);
if (ret) {
- pr_err("Can not create zip qps!\n");
+ pr_err("Can not create zip qps (%d)!\n", ret);
return -ENODEV;
}
@@ -380,19 +380,28 @@ static int hisi_zip_acomp_init(struct crypto_acomp *tfm)
{
const char *alg_name = crypto_tfm_alg_name(>base);
struct hisi_zip_ctx *ctx = crypto_tfm_ctx(>base);
+ struct device *dev;
int ret;
ret = hisi_zip_ctx_init(ctx, COMP_NAME_TO_TYPE(alg_name),
tfm->base.node);
- if (ret)
+ if (ret) {
+ pr_err("Init ctx failed (%d)!\n", ret);
return ret;
+ }
+
+ dev = >qp_ctx[0].qp->qm->pdev->dev;
ret = hisi_zip_create_req_q(ctx);
- if (ret)
+ if (ret) {
+ dev_err(dev, "Create request queue failed (%d)!\n", ret);
goto err_ctx_exit;
+ }
ret = hisi_zip_create_sgl_pool(ctx);
- if (ret)
+ if (ret) {
+ dev_err(dev, "Create sgl pool failed (%d)!\n", ret);
goto err_release_req_q;
+ }
hisi_zip_set_acomp_cb(ctx, hisi_zip_acomp_cb);
@@ -422,8 +431,10 @@ static int add_comp_head(struct scatterlist *dst, u8
req_type)
int ret;
ret = sg_copy_from_buffer(dst, sg_nents(dst), head, head_size);
- if (ret != head_size)
+ if (ret != head_size) {
+ pr_err("The head size of buffer is wrong (%d)!\n", ret);
return -ENOMEM;
+ }
return head_size;
}
@@ -445,7 +456,7 @@ static size_t get_comp_head_size(struct scatterlist *src,
u8 req_type)
case HZIP_ALG_TYPE_GZIP:
return get_gzip_head_size(src);
default:
- pr_err("request type does not support!\n");
+ pr_err("Request type does not support!\n");
return -EINVAL;
}
}
@@ -464,7 +475,7 @@ static struct hisi_zip_req *hisi_zip_create_req(struct
acomp_req *req,
req_id = find_first_zero_bit(req_q->req_bitmap, req_q->size);
if (req_id >= req_q->size) {
write_unlock(_q->req_lock);
- dev_dbg(_ctx->qp->qm->pdev->dev, "req cache is full!\n");
+ dev_dbg(_ctx->qp->qm->pdev->dev, "Req cache is full!\n");
return ERR_PTR(-EBUSY);
}
set_bit(req_id, req_q->req_bitmap);
@@ -504,14 +515,19 @@ static int hisi_zip_do_work(struct hisi_zip_req *req,
req->hw_src = hisi_acc_sg_buf_map_to_hw_sgl(dev, a_req->src, pool,
req->req_id << 1, );
- if (IS_ERR(req->hw_src))
+ if (IS_ERR(req->hw_src)) {
+ dev_err(dev, "The src map to hw SGL failed (%ld)!\n",
+ PTR_ERR(req->hw_src));
return PTR_ERR(req->hw_src);
+ }
req->dma_src = input;
req->hw_dst = hisi_acc_sg_buf_map_to_hw_sgl(dev, a_req->dst, pool,
(req->req_id << 1) + 1,
);
if (IS_ERR(req->hw_dst)) {
+ dev_err(dev, "The dst map to hw SGL failed (%ld)!\n",
+ PTR_ERR(req->hw_dst));
ret = PTR_ERR(req->hw_dst);
goto err_unmap_input;
}
@@ -527,6 +543,7 @@ static int hisi_zip_do_work(struct hisi_zip_req *req,
ret = hisi_qp_send(qp, _sqe);
if (ret < 0) {
atomic64_inc(>send_busy_cnt);
+ dev_dbg_ratelimited(dev, "Send task message failed!\n");
goto err_unmap_output;
}
@@ -543,22 +560,32 @@ static int hisi_zip_acompress(struct acomp_req *acomp_req)
{
struct hisi_zip_ctx *ctx = crypto_tfm_ctx(acomp_req->base.tfm);
struct hisi_zip_qp_ctx *qp_ctx = >qp_ctx[HZIP_QPC_COMP];
+ struct device *dev = _ctx->qp->qm->pdev->dev;
struct hisi_zip_req *req;
int head_size;
int ret;
/* let's output compression head now
[PATCH RESEND 08/10] crypto: hisilicon/zip - move some private macros from 'zip.h' to 'zip_crypto.c'
Some macros which are defined in 'zip.h' are related to the struct
'hisi_zip_sqe' and are only used in 'zip_crypto.c'. So move them from
'zip.h' to 'zip_crypto.c'.
Signed-off-by: Yang Shen
Reviewed-by: Zhou Wang
---
drivers/crypto/hisilicon/zip/zip.h| 14 --
drivers/crypto/hisilicon/zip/zip_crypto.c | 14 ++
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/crypto/hisilicon/zip/zip.h
b/drivers/crypto/hisilicon/zip/zip.h
index 4b3aae8..92397f9 100644
--- a/drivers/crypto/hisilicon/zip/zip.h
+++ b/drivers/crypto/hisilicon/zip/zip.h
@@ -9,20 +9,6 @@
#include
#include "../qm.h"
-/* hisi_zip_sqe dw3 */
-#define HZIP_BD_STATUS_M GENMASK(7, 0)
-/* hisi_zip_sqe dw7 */
-#define HZIP_IN_SGE_DATA_OFFSET_M GENMASK(23, 0)
-/* hisi_zip_sqe dw8 */
-#define HZIP_OUT_SGE_DATA_OFFSET_M GENMASK(23, 0)
-/* hisi_zip_sqe dw9 */
-#define HZIP_REQ_TYPE_MGENMASK(7, 0)
-#define HZIP_ALG_TYPE_ZLIB 0x02
-#define HZIP_ALG_TYPE_GZIP 0x03
-#define HZIP_BUF_TYPE_MGENMASK(11, 8)
-#define HZIP_PBUFFER 0x0
-#define HZIP_SGL 0x1
-
enum hisi_zip_error_type {
/* negative compression */
HZIP_NC_ERR = 0x0d,
diff --git a/drivers/crypto/hisilicon/zip/zip_crypto.c
b/drivers/crypto/hisilicon/zip/zip_crypto.c
index fdc5bd3..7757e33 100644
--- a/drivers/crypto/hisilicon/zip/zip_crypto.c
+++ b/drivers/crypto/hisilicon/zip/zip_crypto.c
@@ -6,6 +6,20 @@
#include
#include "zip.h"
+/* hisi_zip_sqe dw3 */
+#define HZIP_BD_STATUS_M GENMASK(7, 0)
+/* hisi_zip_sqe dw7 */
+#define HZIP_IN_SGE_DATA_OFFSET_M GENMASK(23, 0)
+/* hisi_zip_sqe dw8 */
+#define HZIP_OUT_SGE_DATA_OFFSET_M GENMASK(23, 0)
+/* hisi_zip_sqe dw9 */
+#define HZIP_REQ_TYPE_MGENMASK(7, 0)
+#define HZIP_ALG_TYPE_ZLIB 0x02
+#define HZIP_ALG_TYPE_GZIP 0x03
+#define HZIP_BUF_TYPE_MGENMASK(11, 8)
+#define HZIP_PBUFFER 0x0
+#define HZIP_SGL 0x1
+
#define HZIP_ZLIB_HEAD_SIZE2
#define HZIP_GZIP_HEAD_SIZE10
--
2.7.4
[PATCH RESEND 03/10] crypto: hisilicon/zip - modify debugfs interface parameters
From: Shukun Tan
Update debugfs interface parameters
Signed-off-by: Shukun Tan
Signed-off-by: Yang Shen
Reviewed-by: Zhou Wang
---
drivers/crypto/hisilicon/zip/zip_main.c | 55 ++---
1 file changed, 24 insertions(+), 31 deletions(-)
diff --git a/drivers/crypto/hisilicon/zip/zip_main.c
b/drivers/crypto/hisilicon/zip/zip_main.c
index 058f744..df1a16f 100644
--- a/drivers/crypto/hisilicon/zip/zip_main.c
+++ b/drivers/crypto/hisilicon/zip/zip_main.c
@@ -156,7 +156,6 @@ struct ctrl_debug_file {
*/
struct hisi_zip_ctrl {
struct hisi_zip *hisi_zip;
- struct dentry *debug_root;
struct ctrl_debug_file files[HZIP_DEBUG_FILE_NUM];
};
@@ -509,10 +508,8 @@ static int zip_debugfs_atomic64_get(void *data, u64 *val)
DEFINE_DEBUGFS_ATTRIBUTE(zip_atomic64_ops, zip_debugfs_atomic64_get,
zip_debugfs_atomic64_set, "%llu\n");
-static int hisi_zip_core_debug_init(struct hisi_zip_ctrl *ctrl)
+static int hisi_zip_core_debug_init(struct hisi_qm *qm)
{
- struct hisi_zip *hisi_zip = ctrl->hisi_zip;
- struct hisi_qm *qm = _zip->qm;
struct device *dev = >pdev->dev;
struct debugfs_regset32 *regset;
struct dentry *tmp_d;
@@ -533,7 +530,7 @@ static int hisi_zip_core_debug_init(struct hisi_zip_ctrl
*ctrl)
regset->nregs = ARRAY_SIZE(hzip_dfx_regs);
regset->base = qm->io_base + core_offsets[i];
- tmp_d = debugfs_create_dir(buf, ctrl->debug_root);
+ tmp_d = debugfs_create_dir(buf, qm->debug.debug_root);
debugfs_create_regset32("regs", 0444, tmp_d, regset);
}
@@ -552,33 +549,32 @@ static void hisi_zip_dfx_debug_init(struct hisi_qm *qm)
for (i = 0; i < ARRAY_SIZE(zip_dfx_files); i++) {
data = (atomic64_t *)((uintptr_t)dfx + zip_dfx_files[i].offset);
debugfs_create_file(zip_dfx_files[i].name,
- 0644,
- tmp_dir,
- data,
- _atomic64_ops);
+ 0644, tmp_dir, data,
+ _atomic64_ops);
}
}
-static int hisi_zip_ctrl_debug_init(struct hisi_zip_ctrl *ctrl)
+static int hisi_zip_ctrl_debug_init(struct hisi_qm *qm)
{
+ struct hisi_zip *zip = container_of(qm, struct hisi_zip, qm);
int i;
for (i = HZIP_CURRENT_QM; i < HZIP_DEBUG_FILE_NUM; i++) {
- spin_lock_init(>files[i].lock);
- ctrl->files[i].ctrl = ctrl;
- ctrl->files[i].index = i;
+ spin_lock_init(>ctrl->files[i].lock);
+ zip->ctrl->files[i].ctrl = zip->ctrl;
+ zip->ctrl->files[i].index = i;
debugfs_create_file(ctrl_debug_file_name[i], 0600,
- ctrl->debug_root, ctrl->files + i,
+ qm->debug.debug_root,
+ zip->ctrl->files + i,
_debug_fops);
}
- return hisi_zip_core_debug_init(ctrl);
+ return hisi_zip_core_debug_init(qm);
}
-static int hisi_zip_debugfs_init(struct hisi_zip *hisi_zip)
+static int hisi_zip_debugfs_init(struct hisi_qm *qm)
{
- struct hisi_qm *qm = _zip->qm;
struct device *dev = >pdev->dev;
struct dentry *dev_d;
int ret;
@@ -593,8 +589,7 @@ static int hisi_zip_debugfs_init(struct hisi_zip *hisi_zip)
goto failed_to_create;
if (qm->fun_type == QM_HW_PF) {
- hisi_zip->ctrl->debug_root = dev_d;
- ret = hisi_zip_ctrl_debug_init(hisi_zip->ctrl);
+ ret = hisi_zip_ctrl_debug_init(qm);
if (ret)
goto failed_to_create;
}
@@ -608,10 +603,8 @@ static int hisi_zip_debugfs_init(struct hisi_zip *hisi_zip)
return ret;
}
-static void hisi_zip_debug_regs_clear(struct hisi_zip *hisi_zip)
+static void hisi_zip_debug_regs_clear(struct hisi_qm *qm)
{
- struct hisi_qm *qm = _zip->qm;
-
writel(0x0, qm->io_base + QM_DFX_MB_CNT_VF);
writel(0x0, qm->io_base + QM_DFX_DB_CNT_VF);
writel(0x0, qm->io_base + HZIP_SOFT_CTRL_CNT_CLR_CE);
@@ -619,14 +612,14 @@ static void hisi_zip_debug_regs_clear(struct hisi_zip
*hisi_zip)
hisi_qm_debug_regs_clear(qm);
}
-static void hisi_zip_debugfs_exit(struct hisi_zip *hisi_zip)
+static void hisi_zip_debugfs_exit(struct hisi_qm *qm)
{
- struct hisi_qm *qm = _zip->qm;
-
debugfs_remove_recursive(qm->debug.debug_root);
- if (qm->fun_type == QM_HW_PF)
- hisi_zip_debug_regs_clear(hisi_zip);
+ if (qm->fun_type == QM_HW_PF) {
+ hisi_zip_debug_regs_clear(qm);
+ qm->debug.curr_qm_qp_num = 0;
+ }
}
static void hisi_zip_log_hw_error(struct hisi_qm *qm, u32 err_sts)
@@ -733,7 +726,7 @@ static int hisi_zip_pf_probe_init(struct
[PATCH RESEND 04/10] crypto: hisilicon/zip - replace 'sprintf' with 'scnprintf'
Replace 'sprintf' with 'scnprintf' to avoid overrun.
Signed-off-by: Yang Shen
Reviewed-by: Zhou Wang
---
drivers/crypto/hisilicon/zip/zip_main.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/hisilicon/zip/zip_main.c
b/drivers/crypto/hisilicon/zip/zip_main.c
index df1a16f..1883d1b 100644
--- a/drivers/crypto/hisilicon/zip/zip_main.c
+++ b/drivers/crypto/hisilicon/zip/zip_main.c
@@ -428,7 +428,7 @@ static ssize_t hisi_zip_ctrl_debug_read(struct file *filp,
char __user *buf,
return -EINVAL;
}
spin_unlock_irq(>lock);
- ret = sprintf(tbuf, "%u\n", val);
+ ret = scnprintf(tbuf, HZIP_BUF_SIZE, "%u\n", val);
return simple_read_from_buffer(buf, count, pos, tbuf, ret);
}
@@ -514,13 +514,16 @@ static int hisi_zip_core_debug_init(struct hisi_qm *qm)
struct debugfs_regset32 *regset;
struct dentry *tmp_d;
char buf[HZIP_BUF_SIZE];
- int i;
+ int i, ret;
for (i = 0; i < HZIP_CORE_NUM; i++) {
if (i < HZIP_COMP_CORE_NUM)
- sprintf(buf, "comp_core%d", i);
+ ret = scnprintf(buf, HZIP_BUF_SIZE, "comp_core%d", i);
else
- sprintf(buf, "decomp_core%d", i - HZIP_COMP_CORE_NUM);
+ ret = scnprintf(buf, HZIP_BUF_SIZE, "decomp_core%d",
+ i - HZIP_COMP_CORE_NUM);
+ if (!ret)
+ return -ENOMEM;
regset = devm_kzalloc(dev, sizeof(*regset), GFP_KERNEL);
if (!regset)
--
2.7.4
[PATCH RESEND 07/10] crypto: hisilicon/zip - fix static check warning
Fix some code for PClint warning:
Warning - Suspicious Cast
Signed-off-by: Yang Shen
Reviewed-by: Zhou Wang
---
drivers/crypto/hisilicon/zip/zip_crypto.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/hisilicon/zip/zip_crypto.c
b/drivers/crypto/hisilicon/zip/zip_crypto.c
index 7aa8a55..fdc5bd3 100644
--- a/drivers/crypto/hisilicon/zip/zip_crypto.c
+++ b/drivers/crypto/hisilicon/zip/zip_crypto.c
@@ -16,7 +16,7 @@
#define GZIP_HEAD_FLG_SHIFT3
#define GZIP_HEAD_FEXTRA_SHIFT 10
-#define GZIP_HEAD_FEXTRA_XLEN 2
+#define GZIP_HEAD_FEXTRA_XLEN 2UL
#define GZIP_HEAD_FHCRC_SIZE 2
#define HZIP_GZIP_HEAD_BUF 256
@@ -51,13 +51,13 @@ enum {
struct hisi_zip_req {
struct acomp_req *req;
- int sskip;
- int dskip;
+ u32 sskip;
+ u32 dskip;
struct hisi_acc_hw_sgl *hw_src;
struct hisi_acc_hw_sgl *hw_dst;
dma_addr_t dma_src;
dma_addr_t dma_dst;
- int req_id;
+ u16 req_id;
};
struct hisi_zip_req_q {
@@ -119,7 +119,7 @@ static void hisi_zip_config_tag(struct hisi_zip_sqe *sqe,
u32 tag)
static void hisi_zip_fill_sqe(struct hisi_zip_sqe *sqe, u8 req_type,
dma_addr_t s_addr, dma_addr_t d_addr, u32 slen,
- u32 dlen, int sskip, int dskip)
+ u32 dlen, u32 sskip, u32 dskip)
{
memset(sqe, 0, sizeof(struct hisi_zip_sqe));
@@ -573,7 +573,7 @@ static int hisi_zip_acompress(struct acomp_req *acomp_req)
return head_size;
}
- req = hisi_zip_create_req(acomp_req, qp_ctx, (size_t)head_size, true);
+ req = hisi_zip_create_req(acomp_req, qp_ctx, head_size, true);
if (IS_ERR(req)) {
dev_err_ratelimited(dev, "Create request before compress failed
(%ld)!\n",
PTR_ERR(req));
--
2.7.4
[PATCH RESEND 10/10] crypto: hisilicon/zip - fix some coding styles
1.Unified alignment styles
2.Remove unnecessary goto branch
3.Remove address printf
Signed-off-by: Yang Shen
Reviewed-by: Zhou Wang
---
drivers/crypto/hisilicon/zip/zip_crypto.c | 13 ++---
drivers/crypto/hisilicon/zip/zip_main.c | 16
2 files changed, 10 insertions(+), 19 deletions(-)
diff --git a/drivers/crypto/hisilicon/zip/zip_crypto.c
b/drivers/crypto/hisilicon/zip/zip_crypto.c
index 7757e33..10b7adb 100644
--- a/drivers/crypto/hisilicon/zip/zip_crypto.c
+++ b/drivers/crypto/hisilicon/zip/zip_crypto.c
@@ -38,8 +38,10 @@
#define HZIP_SGL_SGE_NR10
static const u8 zlib_head[HZIP_ZLIB_HEAD_SIZE] = {0x78, 0x9c};
-static const u8 gzip_head[HZIP_GZIP_HEAD_SIZE] = {0x1f, 0x8b, 0x08, 0x0, 0x0,
- 0x0, 0x0, 0x0, 0x0, 0x03};
+static const u8 gzip_head[HZIP_GZIP_HEAD_SIZE] = {
+ 0x1f, 0x8b, 0x08, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x03
+};
+
enum hisi_zip_alg_type {
HZIP_ALG_TYPE_COMP = 0,
HZIP_ALG_TYPE_DECOMP = 1,
@@ -359,7 +361,6 @@ static void hisi_zip_acomp_cb(struct hisi_qp *qp, void
*data)
atomic64_inc(>recv_cnt);
status = sqe->dw3 & HZIP_BD_STATUS_M;
-
if (status != 0 && status != HZIP_NC_ERR) {
dev_err(dev, "%scompress fail in qp%u: %u, output: %u\n",
(qp->alg_type == 0) ? "" : "de", qp->qp_id, status,
@@ -520,8 +521,7 @@ static int hisi_zip_do_work(struct hisi_zip_req *req,
struct hisi_acc_sgl_pool *pool = qp_ctx->sgl_pool;
struct hisi_zip_dfx *dfx = _ctx->zip_dev->dfx;
struct hisi_zip_sqe zip_sqe;
- dma_addr_t input;
- dma_addr_t output;
+ dma_addr_t input, output;
int ret;
if (!a_req->src || !a_req->slen || !a_req->dst || !a_req->dlen)
@@ -540,9 +540,8 @@ static int hisi_zip_do_work(struct hisi_zip_req *req,
(req->req_id << 1) + 1,
);
if (IS_ERR(req->hw_dst)) {
- dev_err(dev, "The dst map to hw SGL failed (%ld)!\n",
- PTR_ERR(req->hw_dst));
ret = PTR_ERR(req->hw_dst);
+ dev_err(dev, "The dst map to hw SGL failed (%d)!\n", ret);
goto err_unmap_input;
}
req->dma_dst = output;
diff --git a/drivers/crypto/hisilicon/zip/zip_main.c
b/drivers/crypto/hisilicon/zip/zip_main.c
index 49fad18..8bbae28 100644
--- a/drivers/crypto/hisilicon/zip/zip_main.c
+++ b/drivers/crypto/hisilicon/zip/zip_main.c
@@ -258,6 +258,7 @@ static int hisi_zip_set_user_domain_and_cache(struct
hisi_qm *qm)
/* qm cache */
writel(AXI_M_CFG, base + QM_AXI_M_CFG);
writel(AXI_M_CFG_ENABLE, base + QM_AXI_M_CFG_ENABLE);
+
/* disable FLR triggered by BME(bus master enable) */
writel(PEH_AXUSER_CFG, base + QM_PEH_AXUSER_CFG);
writel(PEH_AXUSER_CFG_ENABLE, base + QM_PEH_AXUSER_CFG_ENABLE);
@@ -311,7 +312,7 @@ static void hisi_zip_hw_error_enable(struct hisi_qm *qm)
writel(0x1, qm->io_base + HZIP_CORE_INT_RAS_CE_ENB);
writel(0x0, qm->io_base + HZIP_CORE_INT_RAS_FE_ENB);
writel(HZIP_CORE_INT_RAS_NFE_ENABLE,
- qm->io_base + HZIP_CORE_INT_RAS_NFE_ENB);
+ qm->io_base + HZIP_CORE_INT_RAS_NFE_ENB);
/* enable ZIP hw error interrupts */
writel(0, qm->io_base + HZIP_CORE_INT_MASK_REG);
@@ -487,7 +488,6 @@ static const struct file_operations ctrl_debug_fops = {
.write = hisi_zip_ctrl_debug_write,
};
-
static int zip_debugfs_atomic64_set(void *data, u64 val)
{
if (val)
@@ -634,7 +634,7 @@ static void hisi_zip_log_hw_error(struct hisi_qm *qm, u32
err_sts)
while (err->msg) {
if (err->int_msk & err_sts) {
dev_err(dev, "%s [error status=0x%x] found\n",
-err->msg, err->int_msk);
+ err->msg, err->int_msk);
if (err->int_msk & HZIP_CORE_INT_STATUS_M_ECC) {
err_val = readl(qm->io_base +
@@ -642,9 +642,6 @@ static void hisi_zip_log_hw_error(struct hisi_qm *qm, u32
err_sts)
dev_err(dev, "hisi-zip multi ecc sram
num=0x%x\n",
((err_val >>
HZIP_SRAM_ECC_ERR_NUM_SHIFT) & 0xFF));
- dev_err(dev, "hisi-zip multi ecc sram
addr=0x%x\n",
- (err_val >>
- HZIP_SRAM_ECC_ERR_ADDR_SHIFT));
}
}
err++;
@@ -904,15 +901,10 @@ static int __init hisi_zip_init(void)
ret = pci_register_driver(_zip_pci_driver);
if (ret < 0) {
+ hisi_zip_unregister_debugfs();
pr_err("Failed to register pci driver.\n");
-
[PATCH RESEND 05/10] crypto: hisilicon/zip - use a enum parameter instead of some macros
Macros 'QPC_COMP', 'QPC_DECOMP' and 'HZIP_CTX_Q_NUM' are relative and
incremental. So, use an enum instead.
Signed-off-by: Yang Shen
Reviewed-by: Zhou Wang
---
drivers/crypto/hisilicon/zip/zip_crypto.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/hisilicon/zip/zip_crypto.c
b/drivers/crypto/hisilicon/zip/zip_crypto.c
index aba1600..c2ea849 100644
--- a/drivers/crypto/hisilicon/zip/zip_crypto.c
+++ b/drivers/crypto/hisilicon/zip/zip_crypto.c
@@ -19,7 +19,6 @@
#define GZIP_HEAD_FEXTRA_XLEN 2
#define GZIP_HEAD_FHCRC_SIZE 2
-#define HZIP_CTX_Q_NUM 2
#define HZIP_GZIP_HEAD_BUF 256
#define HZIP_ALG_PRIORITY 300
#define HZIP_SGL_SGE_NR10
@@ -32,6 +31,12 @@ enum hisi_zip_alg_type {
HZIP_ALG_TYPE_DECOMP = 1,
};
+enum {
+ HZIP_QPC_COMP,
+ HZIP_QPC_DECOMP,
+ HZIP_CTX_Q_NUM
+};
+
#define COMP_NAME_TO_TYPE(alg_name)\
(!strcmp((alg_name), "zlib-deflate") ? HZIP_ALG_TYPE_ZLIB : \
!strcmp((alg_name), "gzip") ? HZIP_ALG_TYPE_GZIP : 0) \
@@ -71,8 +76,6 @@ struct hisi_zip_qp_ctx {
};
struct hisi_zip_ctx {
-#define QPC_COMP 0
-#define QPC_DECOMP 1
struct hisi_zip_qp_ctx qp_ctx[HZIP_CTX_Q_NUM];
};
@@ -264,11 +267,11 @@ static int hisi_zip_create_req_q(struct hisi_zip_ctx *ctx)
return 0;
err_free_loop1:
- kfree(ctx->qp_ctx[QPC_DECOMP].req_q.req_bitmap);
+ kfree(ctx->qp_ctx[HZIP_QPC_DECOMP].req_q.req_bitmap);
err_free_loop0:
- kfree(ctx->qp_ctx[QPC_COMP].req_q.q);
+ kfree(ctx->qp_ctx[HZIP_QPC_COMP].req_q.q);
err_free_bitmap:
- kfree(ctx->qp_ctx[QPC_COMP].req_q.req_bitmap);
+ kfree(ctx->qp_ctx[HZIP_QPC_COMP].req_q.req_bitmap);
return ret;
}
@@ -303,8 +306,8 @@ static int hisi_zip_create_sgl_pool(struct hisi_zip_ctx
*ctx)
return 0;
err_free_sgl_pool0:
- hisi_acc_free_sgl_pool(>qp_ctx[QPC_COMP].qp->qm->pdev->dev,
- ctx->qp_ctx[QPC_COMP].sgl_pool);
+ hisi_acc_free_sgl_pool(>qp_ctx[HZIP_QPC_COMP].qp->qm->pdev->dev,
+ ctx->qp_ctx[HZIP_QPC_COMP].sgl_pool);
return -ENOMEM;
}
@@ -539,7 +542,7 @@ static int hisi_zip_do_work(struct hisi_zip_req *req,
static int hisi_zip_acompress(struct acomp_req *acomp_req)
{
struct hisi_zip_ctx *ctx = crypto_tfm_ctx(acomp_req->base.tfm);
- struct hisi_zip_qp_ctx *qp_ctx = >qp_ctx[QPC_COMP];
+ struct hisi_zip_qp_ctx *qp_ctx = >qp_ctx[HZIP_QPC_COMP];
struct hisi_zip_req *req;
int head_size;
int ret;
@@ -563,7 +566,7 @@ static int hisi_zip_acompress(struct acomp_req *acomp_req)
static int hisi_zip_adecompress(struct acomp_req *acomp_req)
{
struct hisi_zip_ctx *ctx = crypto_tfm_ctx(acomp_req->base.tfm);
- struct hisi_zip_qp_ctx *qp_ctx = >qp_ctx[QPC_DECOMP];
+ struct hisi_zip_qp_ctx *qp_ctx = >qp_ctx[HZIP_QPC_DECOMP];
struct hisi_zip_req *req;
size_t head_size;
int ret;
--
2.7.4
[PATCH RESEND 09/10] crypto: hisilicon/zip - supplement some comments
Supplement some comments.
Signed-off-by: Yang Shen
Reviewed-by: Zhou Wang
---
drivers/crypto/hisilicon/zip/zip_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/hisilicon/zip/zip_main.c
b/drivers/crypto/hisilicon/zip/zip_main.c
index 7697fa5..49fad18 100644
--- a/drivers/crypto/hisilicon/zip/zip_main.c
+++ b/drivers/crypto/hisilicon/zip/zip_main.c
@@ -285,7 +285,7 @@ static int hisi_zip_set_user_domain_and_cache(struct
hisi_qm *qm)
writel(HZIP_DECOMP_CHECK_ENABLE | HZIP_ALL_COMP_DECOMP_EN,
base + HZIP_CLOCK_GATE_CTRL);
- /* enable sqc writeback */
+ /* enable sqc,cqc writeback */
writel(SQC_CACHE_ENABLE | CQC_CACHE_ENABLE | SQC_CACHE_WB_ENABLE |
CQC_CACHE_WB_ENABLE | FIELD_PREP(SQC_CACHE_WB_THRD, 1) |
FIELD_PREP(CQC_CACHE_WB_THRD, 1), base + QM_CACHE_CTL);
@@ -358,7 +358,7 @@ static int current_qm_write(struct ctrl_debug_file *file,
u32 val)
if (val > qm->vfs_num)
return -EINVAL;
- /* Calculate curr_qm_qp_num and store */
+ /* According PF or VF Dev ID to calculation curr_qm_qp_num and store */
if (val == 0) {
qm->debug.curr_qm_qp_num = qm->qp_num;
} else {
--
2.7.4
[PATCH RESEND 00/10] crypto: hisilicon/zip - misc clean up
This patchset make some clean up: patch 1:remove useless parameters patch 4:replace 'sprintf' with 'scnprintf' patch 7:fix static check warning and the rest patch fix some coding style Resend this patch series because it depends on https://patchwork.kernel.org/cover/11715927/ (crypto: hisilicon/qm - misc fixes). Now the patch series(crypto: hisilicon/qm - misc fixes) has been applied. So this patch series will apply against cryptodev. Shukun Tan (1): crypto: hisilicon/zip - modify debugfs interface parameters Yang Shen (9): crypto: hisilicon/zip - remove some useless parameters crypto: hisilicon/zip - unify naming style for functions and macros crypto: hisilicon/zip - replace 'sprintf' with 'scnprintf' crypto: hisilicon/zip - use a enum parameter instead of some macros crypto: hisilicon/zip - add print for error branch crypto: hisilicon/zip - fix static check warning crypto: hisilicon/zip - move some private macros from 'zip.h' to 'zip_crypto.c' crypto: hisilicon/zip - supplement some comments crypto: hisilicon/zip - fix some coding styles drivers/crypto/hisilicon/zip/zip.h| 15 drivers/crypto/hisilicon/zip/zip_crypto.c | 126 - drivers/crypto/hisilicon/zip/zip_main.c | 130 ++ 3 files changed, 148 insertions(+), 123 deletions(-) -- 2.7.4
[PATCH RESEND 01/10] crypto: hisilicon/zip - remove some useless parameters
1.Remove the macro 'HZIP_VF_NUM'.
2.Remove 'list' of the struct 'hisi_zip'
Signed-off-by: Yang Shen
Reviewed-by: Zhou Wang
---
drivers/crypto/hisilicon/zip/zip.h | 1 -
drivers/crypto/hisilicon/zip/zip_main.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/crypto/hisilicon/zip/zip.h
b/drivers/crypto/hisilicon/zip/zip.h
index 4484be1..4b3aae8 100644
--- a/drivers/crypto/hisilicon/zip/zip.h
+++ b/drivers/crypto/hisilicon/zip/zip.h
@@ -39,7 +39,6 @@ struct hisi_zip_ctrl;
struct hisi_zip {
struct hisi_qm qm;
- struct list_head list;
struct hisi_zip_ctrl *ctrl;
struct hisi_zip_dfx dfx;
};
diff --git a/drivers/crypto/hisilicon/zip/zip_main.c
b/drivers/crypto/hisilicon/zip/zip_main.c
index 7e86b0f..445db04 100644
--- a/drivers/crypto/hisilicon/zip/zip_main.c
+++ b/drivers/crypto/hisilicon/zip/zip_main.c
@@ -17,7 +17,6 @@
#define PCI_DEVICE_ID_ZIP_PF 0xa250
#define PCI_DEVICE_ID_ZIP_VF 0xa251
-#define HZIP_VF_NUM63
#define HZIP_QUEUE_NUM_V1 4096
#define HZIP_QUEUE_NUM_V2 1024
--
2.7.4
[PATCH] [v2] watchdog: Use put_device on error
We should use put_device() instead of freeing device
directly after device_initialize().
Fixes: cb36e29bb0e4b ("watchdog: initialize device before misc_register")
Signed-off-by: Dinghao Liu
---
Changelog:
v2: - Use put_device() instead of just removing kfree.
Move the memleak part to a separate patch.
---
drivers/watchdog/watchdog_dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 6798addabd5a..b0fa7f31b1b6 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -1021,7 +1021,7 @@ static int watchdog_cdev_register(struct watchdog_device
*wdd)
pr_err("%s: a legacy watchdog module is
probably present.\n",
wdd->info->identity);
old_wd_data = NULL;
- kfree(wd_data);
+ put_device(_data->dev);
return err;
}
}
--
2.17.1
[PATCH] ceph: add column 'mds' to show caps in more user friendly
In multi-mds, the 'caps' debugfs file will have duplicate ino,
add the 'mds' column to indicate which mds session the cap belongs to.
Signed-off-by: Yanhu Cao
---
fs/ceph/debugfs.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/fs/ceph/debugfs.c b/fs/ceph/debugfs.c
index 97539b497e4c..47f8971a9c52 100644
--- a/fs/ceph/debugfs.c
+++ b/fs/ceph/debugfs.c
@@ -202,7 +202,8 @@ static int caps_show_cb(struct inode *inode, struct
ceph_cap *cap, void *p)
{
struct seq_file *s = p;
- seq_printf(s, "0x%-17lx%-17s%-17s\n", inode->i_ino,
+ seq_printf(s, "0x%-17lx%-3d%-17s%-17s\n", inode->i_ino,
+ cap->session->s_mds,
ceph_cap_string(cap->issued),
ceph_cap_string(cap->implemented));
return 0;
@@ -222,8 +223,8 @@ static int caps_show(struct seq_file *s, void *p)
"reserved\t%d\n"
"min\t\t%d\n\n",
total, avail, used, reserved, min);
- seq_printf(s, "inoissued implemented\n");
- seq_printf(s, "---\n");
+ seq_printf(s, "ino mds issued implemented\n");
+ seq_printf(s, "--\n");
mutex_lock(>mutex);
for (i = 0; i < mdsc->max_sessions; i++) {
--
2.24.3 (Apple Git-128)
RE: [PATCH -next] amdgpu: fix Documentation builds for pm/ file movement
[AMD Official Use Only - Internal Distribution Only]
Thanks for fixing this. The patch is reviewed-by: Evan Quan
BR
Evan
-Original Message-
From: Randy Dunlap
Sent: Monday, August 24, 2020 6:36 AM
To: dri-devel ; LKML
; amd-...@lists.freedesktop.org; Deucher,
Alexander
Cc: Quan, Evan ; Stephen Rothwell
Subject: [PATCH -next] amdgpu: fix Documentation builds for pm/ file movement
From: Randy Dunlap
Fix Documentation errors for amdgpu.rst due to file rename (moved to another
subdirectory).
Error: Cannot open file ../drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
WARNING: kernel-doc '../scripts/kernel-doc -rst -enable-lineno -function hwmon
../drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c' failed with return code 1
Fixes: e098bc9612c2 ("drm/amd/pm: optimize the power related source code
layout")
Signed-off-by: Randy Dunlap
Cc: Evan Quan
Cc: Alex Deucher
---
Documentation/gpu/amdgpu.rst | 24
1 file changed, 12 insertions(+), 12 deletions(-)
--- linux-next-20200821.orig/Documentation/gpu/amdgpu.rst
+++ linux-next-20200821/Documentation/gpu/amdgpu.rst
@@ -153,7 +153,7 @@ This section covers hwmon and power/ther HWMON Interfaces
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
:doc: hwmon
GPU sysfs Power State Interfaces
@@ -164,52 +164,52 @@ GPU power controls are exposed via sysfs power_dpm_state
~~~
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
:doc: power_dpm_state
power_dpm_force_performance_level
~
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
:doc: power_dpm_force_performance_level
pp_table
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
:doc: pp_table
pp_od_clk_voltage
~
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
:doc: pp_od_clk_voltage
pp_dpm_*
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
:doc: pp_dpm_sclk pp_dpm_mclk pp_dpm_socclk pp_dpm_fclk pp_dpm_dcefclk
pp_dpm_pcie
pp_power_profile_mode
~
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
:doc: pp_power_profile_mode
*_busy_percent
~~
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
:doc: gpu_busy_percent
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
:doc: mem_busy_percent
gpu_metrics
~
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
:doc: gpu_metrics
GPU Product Information
@@ -239,7 +239,7 @@ serial_number
unique_id
-
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
:doc: unique_id
GPU Memory Usage Information
@@ -289,7 +289,7 @@ PCIe Accounting Information pcie_bw
---
-.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
+.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
:doc: pcie_bw
pcie_replay_count
[PATCH] misc: rtsx: do not setting OC_POWER_DOWN reg in rtsx_pci_init_ocp()
From: Ricky Wu
this power saving action in rtsx_pci_init_ocp() cause INTEL-NUC6 platform
missing card reader
Signed-off-by: Ricky Wu
---
drivers/misc/cardreader/rtsx_pcr.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/misc/cardreader/rtsx_pcr.c
b/drivers/misc/cardreader/rtsx_pcr.c
index 37ccc67f4914..3a4a7b0cc098 100644
--- a/drivers/misc/cardreader/rtsx_pcr.c
+++ b/drivers/misc/cardreader/rtsx_pcr.c
@@ -1155,10 +1155,6 @@ void rtsx_pci_init_ocp(struct rtsx_pcr *pcr)
rtsx_pci_write_register(pcr, REG_OCPGLITCH,
SD_OCP_GLITCH_MASK, pcr->hw_param.ocp_glitch);
rtsx_pci_enable_ocp(pcr);
- } else {
- /* OC power down */
- rtsx_pci_write_register(pcr, FPDCTL, OC_POWER_DOWN,
- OC_POWER_DOWN);
}
}
}
--
2.17.1
[PATCH v5] kernel/trace: Add DISALLOW_TRACE_PRINTK make option
trace_printk is meant as a debugging tool, and should not be
compiled into production code without specific debug Kconfig
options enabled, or source code changes, as indicated by the
warning that shows up on boot if any trace_printk is called:
** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
** **
** trace_printk() being used. Allocating extra memory. **
** **
** This means that this is a DEBUG kernel and it is **
** unsafe for production use. **
If DISALLOW_TRACE_PRINTK=1 is passed on the make command
line, the kernel will generate a build-time error if
trace_printk is used. We expect distributors to set this
option for their production kernels.
Note that the code to handle trace_printk is still present,
so this does not prevent people from compiling out-of-tree
kernel modules, or BPF programs.
Also, we are not making this a kernel config option as we
want the developer convenience of being able to reuse a
production kernel config, add trace_printk for debugging,
and rebuild, without any config changes.
Signed-off-by: Nicolas Boichat
---
Changes since v4:
- Turns this into a make option, instead of a config
option, as suggested by Steven Rostedt .
Changes since v2/v3:
- Rebase only, v3 didn't exist as I just split out the other
necessary patches.
- Added patch 3/3 to fix atomisp_compat_css20.c
Changes since v1:
- Use static_assert instead of __static_assert (Jason Gunthorpe)
- Fix issues that can be detected by this patch (running some
randconfig in a loop, kernel test robot, or manual inspection),
by:
- Making some debug config options that use trace_printk depend
on the new config option.
- Adding 3 patches before this one.
Makefile | 14 ++
include/linux/kernel.h | 17 -
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index c4470a4e131f2ce..fb8b0d7fb4b2df7 100644
--- a/Makefile
+++ b/Makefile
@@ -100,6 +100,16 @@ endif
export quiet Q KBUILD_VERBOSE
+# Disallow use of trace_printk. Can be used by production kernels.
+ifeq ("$(origin DISALLOW_TRACE_PRINTK)", "command line")
+ KBUILD_DISALLOW_TRACE_PRINTK = $(DISALLOW_TRACE_PRINTK)
+endif
+ifndef KBUILD_DISALLOW_TRACE_PRINTK
+ KBUILD_DISALLOW_TRACE_PRINTK = 0
+endif
+
+export KBUILD_DISALLOW_TRACE_PRINTK
+
# Kbuild will save output files in the current working directory.
# This does not need to match to the root of the kernel source tree.
#
@@ -838,6 +848,10 @@ KBUILD_AFLAGS += -gz=zlib
KBUILD_LDFLAGS += --compress-debug-sections=zlib
endif
+ifeq ($(KBUILD_DISALLOW_TRACE_PRINTK),1)
+KBUILD_CFLAGS += -DDISALLOW_TRACE_PRINTK
+endif
+
KBUILD_CFLAGS += $(DEBUG_CFLAGS)
export DEBUG_CFLAGS
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 500def620d8f493..7b533b0375596af 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -687,6 +687,12 @@ do {
\
trace_printk_check_format(fmt, ##args); \
} while (0)
+#ifdef DISALLOW_TRACE_PRINTK
+#define ALLOW_TRACE_PRINTK 0
+#else
+#define ALLOW_TRACE_PRINTK 1
+#endif
+
/**
* trace_printk - printf formatting in the ftrace buffer
* @fmt: the printf format for printing
@@ -720,10 +726,13 @@ do {
\
#define trace_printk(fmt, ...) \
do { \
char ___STR[] = __stringify((__VA_ARGS__)); \
+ \
+ static_assert(ALLOW_TRACE_PRINTK, "trace_printk called."); \
+ \
if (sizeof(___STR) > 3) \
do_trace_printk(fmt, ##__VA_ARGS__);\
else\
- trace_puts(fmt);\
+ do_trace_puts(fmt); \
} while (0)
#define do_trace_printk(fmt, args...) \
@@ -772,6 +781,11 @@ int __trace_printk(unsigned long ip, const char *fmt, ...);
*/
#define trace_puts(str) ({ \
+ static_assert(ALLOW_TRACE_PRINTK, "trace_puts called.");\
+ do_trace_puts(str); \
+})
+
+#define do_trace_puts(str) ({ \
static const char *trace_printk_fmt __used \
__attribute__((section("__trace_printk_fmt"))) =\
__builtin_constant_p(str) ? str : NULL; \
@@ -793,6 +807,7 @@ extern void trace_dump_stack(int skip);
*/
#define ftrace_vprintk(fmt, vargs)
[PATCH] mtd: maps: physmap: Retain mtd-name property from dts
In physmap_flash_of_init() the maps[].name can be populated based on the optional 'linux,mtd-name' property in the dts. Make sure this is retained when filling in the rest of the map[] data. Signed-off-by: Chris Packham --- drivers/mtd/maps/physmap-core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/maps/physmap-core.c b/drivers/mtd/maps/physmap-core.c index 8f7f966fa9a7..6372197ad865 100644 --- a/drivers/mtd/maps/physmap-core.c +++ b/drivers/mtd/maps/physmap-core.c @@ -515,7 +515,8 @@ static int physmap_flash_probe(struct platform_device *dev) dev_notice(>dev, "physmap platform flash device: %pR\n", res); - info->maps[i].name = dev_name(>dev); + if (!info->maps[i].name) + info->maps[i].name = dev_name(>dev); if (!info->maps[i].phys) info->maps[i].phys = res->start; -- 2.28.0
[PATCH] staging: greybus: fix warnings detected by sparse
This patch fix the following warnings from sparse,
$ make C=2 drivers/staging/greybus/
drivers/staging/greybus/audio_codec.c:691:36: warning: incorrect type in
initializer (different base types)
drivers/staging/greybus/audio_codec.c:691:36:expected unsigned long long
[usertype] formats
drivers/staging/greybus/audio_codec.c:691:36:got restricted
snd_pcm_format_t [usertype]
drivers/staging/greybus/audio_codec.c:701:36: warning: incorrect type in
initializer (different base types)
drivers/staging/greybus/audio_codec.c:701:36:expected unsigned long long
[usertype] formats
drivers/staging/greybus/audio_codec.c:701:36:got restricted
snd_pcm_format_t [usertype]
drivers/staging/greybus/audio_module.c:222:25: warning: incorrect type in
assignment (different base types)
drivers/staging/greybus/audio_module.c:222:25:expected restricted __le16
[usertype] data_cport
drivers/staging/greybus/audio_module.c:222:25:got unsigned short [usertype]
intf_cport_id
drivers/staging/greybus/audio_topology.c:460:40: warning: restricted __le32
degrades to integer
drivers/staging/greybus/audio_topology.c:691:41: warning: incorrect type in
assignment (different base types)
drivers/staging/greybus/audio_topology.c:691:41:expected unsigned int access
drivers/staging/greybus/audio_topology.c:691:41:got restricted __le32
[usertype] access
drivers/staging/greybus/audio_topology.c:746:44: warning: incorrect type in
assignment (different base types)
drivers/staging/greybus/audio_topology.c:746:44:expected unsigned int
drivers/staging/greybus/audio_topology.c:746:44:got restricted __le32
drivers/staging/greybus/audio_topology.c:748:52: warning: incorrect type in
assignment (different base types)
drivers/staging/greybus/audio_topology.c:748:52:expected unsigned int
drivers/staging/greybus/audio_topology.c:748:52:got restricted __le32
drivers/staging/greybus/audio_topology.c:802:42: warning: restricted __le32
degrades to integer
drivers/staging/greybus/audio_topology.c:805:50: warning: incorrect type in
assignment (different base types)
drivers/staging/greybus/audio_topology.c:805:50:expected restricted __le32
drivers/staging/greybus/audio_topology.c:805:50:got unsigned int
drivers/staging/greybus/audio_topology.c:814:50: warning: restricted __le32
degrades to integer
drivers/staging/greybus/audio_topology.c:817:58: warning: incorrect type in
assignment (different base types)
drivers/staging/greybus/audio_topology.c:817:58:expected restricted __le32
drivers/staging/greybus/audio_topology.c:817:58:got unsigned int
drivers/staging/greybus/audio_topology.c:889:25: warning: incorrect type in
assignment (different base types)
drivers/staging/greybus/audio_topology.c:889:25:expected unsigned int access
drivers/staging/greybus/audio_topology.c:889:25:got restricted __le32
[usertype] access
Signed-off-by: Coiby Xu
---
drivers/staging/greybus/audio_codec.c| 4 ++--
drivers/staging/greybus/audio_module.c | 2 +-
drivers/staging/greybus/audio_topology.c | 18 +-
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/greybus/audio_codec.c
b/drivers/staging/greybus/audio_codec.c
index 74538f8c5fa4..494aa823e998 100644
--- a/drivers/staging/greybus/audio_codec.c
+++ b/drivers/staging/greybus/audio_codec.c
@@ -688,7 +688,7 @@ static struct snd_soc_dai_driver gbaudio_dai[] = {
.playback = {
.stream_name = "I2S 0 Playback",
.rates = SNDRV_PCM_RATE_48000,
- .formats = SNDRV_PCM_FORMAT_S16_LE,
+ .formats = SNDRV_PCM_FMTBIT_S16_LE,
.rate_max = 48000,
.rate_min = 48000,
.channels_min = 1,
@@ -698,7 +698,7 @@ static struct snd_soc_dai_driver gbaudio_dai[] = {
.capture = {
.stream_name = "I2S 0 Capture",
.rates = SNDRV_PCM_RATE_48000,
- .formats = SNDRV_PCM_FORMAT_S16_LE,
+ .formats = SNDRV_PCM_FMTBIT_S16_LE,
.rate_max = 48000,
.rate_min = 48000,
.channels_min = 1,
diff --git a/drivers/staging/greybus/audio_module.c
b/drivers/staging/greybus/audio_module.c
index 16f60256adb2..00848b84b022 100644
--- a/drivers/staging/greybus/audio_module.c
+++ b/drivers/staging/greybus/audio_module.c
@@ -219,7 +219,7 @@ static int gb_audio_add_data_connection(struct
gbaudio_module_info *gbmodule,
greybus_set_drvdata(bundle, gbmodule);
dai->id = 0;
- dai->data_cport = connection->intf_cport_id;
+ dai->data_cport = cpu_to_le16(connection->intf_cport_id);
dai->connection = connection;
list_add(>list, >data_list);
diff --git a/drivers/staging/greybus/audio_topology.c
b/drivers/staging/greybus/audio_topology.c
index
[PATCH] MAINTAINERS: Add maintenance information for MStar Interrupt Controller
Add entry for MStar Interrupt Controller. Signed-off-by: Mark-PK Tsai --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index deaafb617361..8ab08fccd915 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11754,6 +11754,13 @@ Q: http://patchwork.linuxtv.org/project/linux-media/list/ T: git git://linuxtv.org/anttip/media_tree.git F: drivers/media/usb/msi2500/ +MSTAR INTERRUPT CONTROLLER DRIVER +M: Mark-PK Tsai +M: Daniel Palmer +S: Maintained +F: Documentation/devicetree/bindings/interrupt-controller/mstar,mst-intc.yaml +F: drivers/irqchip/irq-mst-intc.c + MSYSTEMS DISKONCHIP G3 MTD DRIVER M: Robert Jarzmik L: linux-...@lists.infradead.org -- 2.18.0
Re: [RESEND PATCH 4/5] iommu: intel: Drop kerneldoc marker from regular comment
Hi, On 8/20/20 1:53 AM, Krzysztof Kozlowski wrote: Fix W=1 compile warnings (invalid kerneldoc): drivers/iommu/intel/dmar.c:389: warning: Function parameter or member 'header' not described in 'dmar_parse_one_drhd' Signed-off-by: Krzysztof Kozlowski Adjust the commit title to "iommu/vt-d: Drop kerneldoc marker from regular comment", Reviewed-by: Lu Baolu Best regards, baolu --- drivers/iommu/intel/dmar.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c index 93e6345f3414..ba47edf03941 100644 --- a/drivers/iommu/intel/dmar.c +++ b/drivers/iommu/intel/dmar.c @@ -380,7 +380,7 @@ dmar_find_dmaru(struct acpi_dmar_hardware_unit *drhd) return NULL; } -/** +/* * dmar_parse_one_drhd - parses exactly one DMA remapping hardware definition * structure which uniquely represent one DMA remapping hardware unit * present in the platform
Re: [mm] c566586818: BUG:kernel_hang_in_early-boot_stage,last_printk:Probing_EDD(edd=off_to_disable)...ok
On 8/21/20 9:01 AM, Qian Cai wrote:
On Tue, Aug 18, 2020 at 08:23:51AM +0800, kernel test robot wrote:
Greeting,
FYI, we noticed the following commit (built with gcc-9):
commit: c5665868183fec689dbab9fb8505188b2c4f0757 ("mm: kmemleak: use the memory pool
for early allocations")
I might see one of those early boot failure before. In my case, the bare-metal
system was reset. Can you try to narrow down to a smaller
CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE (assume 0 works if your bisecting was
correct) that works?
Hi Qian,
Adding CONFIG_EARLY_PRINTK=y to the kconfig file, and the boot hangs in
the below position:
[ 0.715834] Kernel command line: root=/dev/ram0 hung_task_panic=1
debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100
net.ifnames=0 printk.devkmsg=on panic=-1 softlockup_panic=1
nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0
drbd.minor_count=8
systemd.log_level=err ignore_loglevel console=tty0
earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw
rcuperf.shutdown=0 watchdog_thresh=60
[ 0.719688] sysrq: sysrq always enabled.
[ 0.801005] Dentry cache hash table entries: 2097152 (order: 12,
16777216 bytes, linear)
[ 0.805588] Inode-cache hash table entries: 1048576 (order: 11,
8388608 bytes, linear)
[ 0.806464] mem auto-init: stack:off, heap alloc:on, heap free:off
[ 1.080978] Memory: 12319196K/12680692K available (10243K kernel
code, 2414K rwdata, 8184K rodata, 856K init, 20772K bss, 361496K
reserved, 0K cma-reserved)
qemu-system-x86_64: terminating on signal 2
The problem disappeared if CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE=400:
[ 1.064575] Kernel command line: root=/dev/ram0 hung_task_panic=1
debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100
net.ifnames=0 printk.devkmsg=on panic=-1 softlockup_panic=1
nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0
drbd.minor_count=8
systemd.log_level=err ignore_loglevel console=tty0
earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw
rcuperf.shutdown=0 watchdog_thresh=60
[ 1.068883] sysrq: sysrq always enabled.
[ 1.108720] Dentry cache hash table entries: 2097152 (order: 12,
16777216 bytes, linear)
[ 1.148852] Inode-cache hash table entries: 1048576 (order: 11,
8388608 bytes, linear)
[ 1.150271] mem auto-init: stack:off, heap alloc:on, heap free:off
[ 1.835309] Memory: 12325340K/12680692K available (10243K kernel
code, 2414K rwdata, 8192K rodata, 856K init, 14628K bss, 355352K
reserved, 0K cma-reserved)
[ 3.487078] general protection fault: [#1] DEBUG_PAGEALLOC PTI
[ 3.488185] CPU: 0 PID: 0 Comm: swapper Not tainted
5.3.0-11792-gc5665868183fe #1
[ 3.489581] RIP: 0010:lookup_address_in_pgd+0xd1/0x158
[ 3.490566] Code: 80 e0 01 0f 84 a7 00 00 00 49 89 f0 b8 11 ff ff 01
48 21 f9 49 c1 e8 12 48 c1 e0 27 41 81 e0 f8 0f 00 00 49 01 c0 49 8d 04
08 <48> f7 00 9f ff ff ff 0f 84 34 ff ff ff c7 02 02 00 00 00 48 8b 38
[ 3.494020] RSP: :8239e700 EFLAGS: 00010086
[ 3.494959] RAX: 110302110d90 RBX: 0001 RCX:
88830211
[ 3.496222] RDX: 8239e72c RSI: 88833653b000 RDI:
88833653a000
[ 3.497363] RBP: 8239e808 R08: 88800d90 R09:
00346000
[ 3.498467] R10: 0001 R11: R12:
0001
[ 3.499554] R13: R14: 88833653b000 R15:
[ 3.500638] FS: () GS:8243d000()
knlGS:
[ 3.501863] CS: 0010 DS: ES: CR0: 80050033
[ 3.503036] CR2: 8883447ff000 CR3: 0242 CR4:
06b0
[ 3.504116] DR0: DR1: DR2:
[ 3.505156] DR3: DR6: fffe0ff0 DR7:
0400
[ 3.506225] Call Trace:
[ 3.506597] Modules linked in:
[ 3.507255] random: get_random_bytes called from
init_oops_id+0x1d/0x2c with crng_init=0
[ 3.508734] ---[ end trace ]---
Best Regards,
Rong Chen
Re: [PATCH] ntfs: add check for mft record size in superblock
Hi Andrew,
Can you please merge this patch? Thanks a lot in advance!
Rustam, thank you for the updated patch!
Best regards,
Anton
> On 24 Aug 2020, at 03:28, Rustam Kovhaev wrote:
>
> number of bytes allocated for mft record should be equal to the mft
> record size stored in ntfs superblock
> as reported by syzbot, userspace might trigger out-of-bounds read by
> dereferencing ctx->attr in ntfs_attr_find()
>
> Reported-and-tested-by: syzbot+aed06913f36eff9b5...@syzkaller.appspotmail.com
> Link: https://syzkaller.appspot.com/bug?extid=aed06913f36eff9b544e
> Signed-off-by: Rustam Kovhaev
> Acked-by: Anton Altaparmakov
> ---
> fs/ntfs/inode.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/fs/ntfs/inode.c b/fs/ntfs/inode.c
> index 9bb9f0952b18..caf563981532 100644
> --- a/fs/ntfs/inode.c
> +++ b/fs/ntfs/inode.c
> @@ -1810,6 +1810,12 @@ int ntfs_read_inode_mount(struct inode *vi)
> brelse(bh);
> }
>
> + if (le32_to_cpu(m->bytes_allocated) != vol->mft_record_size) {
> + ntfs_error(sb, "Incorrect mft record size %u in superblock,
> should be %u.",
> + le32_to_cpu(m->bytes_allocated),
> vol->mft_record_size);
> + goto err_out;
> + }
> +
> /* Apply the mst fixups. */
> if (post_read_mst_fixup((NTFS_RECORD*)m, vol->mft_record_size)) {
> /* FIXME: Try to use the $MFTMirr now. */
> --
> 2.28.0
>
--
Anton Altaparmakov (replace at with @)
Lead in File System Development, Tuxera Inc., http://www.tuxera.com/
Linux NTFS maintainer
Re: [PATCH v5 2/2] Add Intel LGM soc DMA support.
Hi Peter,
Thanks for the review comments. Please see my comments inline..
On 8/18/2020 6:16 PM, Peter Ujfalusi wrote:
Hi,
On 14/08/2020 8.26, Amireddy Mallikarjuna reddy wrote:
Add DMA controller driver for Lightning Mountain(LGM) family of SoCs.
The main function of the DMA controller is the transfer of data from/to any
DPlus compliant peripheral to/from the memory. A memory to memory copy
capability can also be configured.
This ldma driver is used for configure the device and channnels for data
and control paths.
Signed-off-by: Amireddy Mallikarjuna reddy
...
+static int ldma_chan_cfg(struct ldma_chan *c)
+{
+ struct ldma_dev *d = to_ldma_dev(c->vchan.chan.device);
+ u32 reg;
+
+ reg = c->pden ? DMA_CCTRL_PDEN : 0;
+ reg |= c->onoff ? DMA_CCTRL_ON : 0;
+ reg |= c->rst ? DMA_CCTRL_RST : 0;
+
+ ldma_chan_cctrl_cfg(c, reg);
+ ldma_chan_irq_init(c);
+
+ if (d->ver > DMA_VER22) {
+ ldma_chan_set_class(c, c->nr);
+ ldma_chan_byte_offset_cfg(c, c->boff_len);
+ ldma_chan_data_endian_cfg(c, c->data_endian_en, c->data_endian);
+ ldma_chan_desc_endian_cfg(c, c->desc_endian_en, c->desc_endian);
+ ldma_chan_hdr_mode_cfg(c, c->hdrm_len, c->hdrm_csum);
+ ldma_chan_rxwr_np_cfg(c, c->desc_rx_np);
+ ldma_chan_abc_cfg(c, c->abc_en);
Each of these functions will lock and unlock the same lock, would it
make sense to restructur things to have less activity with the spinlock?
Ok. Instead of lock & unlock at each function i will try to lock &
unlock only once from here.
+
+ if (ldma_chan_is_hw_desc(c))
+ ldma_chan_desc_hw_cfg(c, c->desc_phys, c->desc_cnt);
+ }
+
+ return 0;
+}
...
+static void dma_free_desc_resource(struct virt_dma_desc *vdesc)
+{
+ struct dw2_desc_sw *ds = to_lgm_dma_desc(vdesc);
+ struct ldma_chan *c = ds->chan;
+
+ dma_pool_free(c->desc_pool, ds->desc_hw, ds->desc_phys);
+ kfree(ds);
+ c->ds = NULL;
Is there a chance that c->ds != ds?
No, from the code i don't see any such scenario, let me know if you find
any corner case.
+}
+
+static struct dw2_desc_sw *
+dma_alloc_desc_resource(int num, struct ldma_chan *c)
+{
+ struct device *dev = c->vchan.chan.device->dev;
+ struct dw2_desc_sw *ds;
+
+ if (num > c->desc_num) {
+ dev_err(dev, "sg num %d exceed max %d\n", num, c->desc_num);
+ return NULL;
+ }
+
+ ds = kzalloc(sizeof(*ds), GFP_NOWAIT);
+ if (!ds)
+ return NULL;
+
+ ds->chan = c;
+
+ ds->desc_hw = dma_pool_zalloc(c->desc_pool, GFP_ATOMIC,
+ >desc_phys);
+ if (!ds->desc_hw) {
+ dev_dbg(dev, "out of memory for link descriptor\n");
+ kfree(ds);
+ return NULL;
+ }
+ ds->desc_cnt = num;
+
+ return ds;
+}
+
+static void ldma_chan_irq_en(struct ldma_chan *c)
+{
+ struct ldma_dev *d = to_ldma_dev(c->vchan.chan.device);
+ unsigned long flags;
+
+ spin_lock_irqsave(>dev_lock, flags);
+ writel(c->nr, d->base + DMA_CS);
+ writel(DMA_CI_EOP, d->base + DMA_CIE);
+ writel(BIT(c->nr), d->base + DMA_IRNEN);
+ spin_unlock_irqrestore(>dev_lock, flags);
+}
+
+static void dma_issue_pending(struct dma_chan *chan)
+{
+ struct ldma_chan *c = to_ldma_chan(chan);
+ struct ldma_dev *d = to_ldma_dev(c->vchan.chan.device);
+ unsigned long flags;
+
+ if (d->ver == DMA_VER22) {
+ spin_lock_irqsave(>vchan.lock, flags);
+ if (vchan_issue_pending(>vchan)) {
+ struct virt_dma_desc *vdesc;
+
+ /* Get the next descriptor */
+ vdesc = vchan_next_desc(>vchan);
+ if (!vdesc) {
+ c->ds = NULL;
+ return;
+ }
+ list_del(>node);
+ c->ds = to_lgm_dma_desc(vdesc);
you have set c->ds in dma_prep_slave_sg and the only way I can see that
you will not leak memory is that the client must terminate_sync() after
each transfer so that the synchronize callback is invoked between each
prep_sg/issue_pending/competion.
Yes, client must call dmaengine_synchronize after each transfer to make
sure free the memory assoicated with previously issued descriptors if any.
and also from the driver we are freeing up the descriptor from work
queue atfer each transfer.(addressed below comments **)
+ spin_unlock_irqrestore(>vchan.lock, flags);
+ ldma_chan_desc_hw_cfg(c, c->ds->desc_phys,
c->ds->desc_cnt);
+ ldma_chan_irq_en(c);
+ }
If there is nothing peding, you will leave the spinlock wide open...
Seems i misplaced the lock. i will fix it in next
Re: [PATCH] usb: hcd: fix the error check
On 20-08-20 20:20:38, Tang Bin wrote:
> In the function usb_add_hcd(), usb_phy_roothub_alloc()
> can return NULL in some cases, so IS_ERR() doesn't meet
> the requirements. Thus fix it.
> Signed-off-by: Zhang Shengju
> Signed-off-by: Tang Bin
> ---
> drivers/usb/core/hcd.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> index aa45840d8..b73a92ee1 100644
> --- a/drivers/usb/core/hcd.c
> +++ b/drivers/usb/core/hcd.c
> @@ -2633,8 +2633,9 @@ int usb_add_hcd(struct usb_hcd *hcd,
>
> if (!hcd->skip_phy_initialization && usb_hcd_is_primary_hcd(hcd)) {
> hcd->phy_roothub = usb_phy_roothub_alloc(hcd->self.sysdev);
> - if (IS_ERR(hcd->phy_roothub))
> - return PTR_ERR(hcd->phy_roothub);
> + if (IS_ERR_OR_NULL(hcd->phy_roothub))
> + return hcd->phy_roothub ?
> + PTR_ERR(hcd->phy_roothub) : -ENODEV;
Many (old) host controller drivers, their PHYs are not seen by software.
We may not consider NULL as error.
--
Thanks,
Peter Chen
[PATCH] watchdog: Fix memleak in watchdog_cdev_register
When watchdog_kworker is NULL, we should free wd_data
before the function returns to prevent memleak.
Fixes: 664a39236e718 ("watchdog: Introduce hardware maximum heartbeat in
watchdog core")
Signed-off-by: Dinghao Liu
---
drivers/watchdog/watchdog_dev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 6798addabd5a..785270ee337c 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -994,8 +994,10 @@ static int watchdog_cdev_register(struct watchdog_device
*wdd)
wd_data->wdd = wdd;
wdd->wd_data = wd_data;
- if (IS_ERR_OR_NULL(watchdog_kworker))
+ if (IS_ERR_OR_NULL(watchdog_kworker)) {
+ kfree(wd_data);
return -ENODEV;
+ }
device_initialize(_data->dev);
wd_data->dev.devt = MKDEV(MAJOR(watchdog_devt), wdd->id);
--
2.17.1
Re: [PATCH v2 1/2] irqchip: irq-mst: Add MStar interrupt controller support
From: Daniel Palmer >Hi Mark-PK, > >On Thu, 20 Aug 2020 at 00:38, Mark-PK Tsai wrote: >> >> Add MStar interrupt controller support using hierarchy irq >> domain. >> >> Signed-off-by: Mark-PK Tsai > >I've integrated this version into my MStar/SigmaStar tree and tested >on an MStar MSC313E >based board (BreadBee) and I'm happy to say it seems to be working: > >$ cat /proc/interrupts > CPU0 >17: 1219 GIC-0 29 Level arch_timer >18: 0 GIC-0 30 Level arch_timer >21: 0 GIC-0 42 Level arm-pmu >24: 0 mst-intc 44 Level 1f002400.rtc >30: 0 mst-intc 2 Level 1f006000.wdt >31: 0 mst-intc 0 Level 1f006040.timer >32: 0 mst-intc 1 Level 1f006080.timer >33: 0 mst-intc 12 Level 1f0060c0.timer >34: 0 mst-intc 40 Level 1f200400.bdma >35: 3977 mst-intc 41 Level 1f200400.bdma >37:196 mst-intc 34 Level ttyS0 >40: 0 mst-intc 30 Level soc:usbphy@0 > > >So here's my tested by: > >Tested-by: Daniel Palmer > Thanks for your test. >I don't think your series contained an update to MAINTAINERS. >If/when you add this could you add my address above as a reviewer so >I'm in the loop if anyone makes changes to this going forward? > Sure, I will add your address in there. :) Can I just add a patch in this thread which only contain MAINTAINERS update?
[PATCH] regulator: mp886x: use "mps,switch-frequency-hz"
As Rob suggested, use the "mps,switch-frequency-hz" instead of the "mps,switch-frequency" for switch frequency. Fortunately, the switch frequency support isn't released, so we can modify it now without any concern. Signed-off-by: Jisheng Zhang --- Documentation/devicetree/bindings/regulator/mp886x.txt | 2 +- drivers/regulator/mp886x.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/regulator/mp886x.txt b/Documentation/devicetree/bindings/regulator/mp886x.txt index e747000cebba..b05307bbb0d9 100644 --- a/Documentation/devicetree/bindings/regulator/mp886x.txt +++ b/Documentation/devicetree/bindings/regulator/mp886x.txt @@ -10,7 +10,7 @@ Required properties: values R1 and R2 of the feedback voltage divider in kilo ohms. Optional properties: -- mps,switch-frequency: The valid switch frequency in Hertz. Available values +- mps,switch-frequency-hz: The valid switch frequency in Hertz. Available values are: 50, 75, 100, 125, 150 Any property defined as part of the core regulator binding, defined in diff --git a/drivers/regulator/mp886x.c b/drivers/regulator/mp886x.c index 97dc44c0d663..a84fd74081de 100644 --- a/drivers/regulator/mp886x.c +++ b/drivers/regulator/mp886x.c @@ -349,7 +349,7 @@ static int mp886x_i2c_probe(struct i2c_client *client) config.driver_data = di; config.of_node = np; - if (!of_property_read_u32(np, "mps,switch-frequency", )) + if (!of_property_read_u32(np, "mps,switch-frequency-hz", )) mp886x_set_switch_freq(di, regmap, freq); ret = mp886x_regulator_register(di, ); -- 2.28.0
Re: [PATCH v2 4/9] iommu/ioasid: Add reference couting functions
Hi Jacob,
On 8/22/20 12:35 PM, Jacob Pan wrote:
There can be multiple users of an IOASID, each user could have hardware
contexts associated with the IOASID. In order to align lifecycles,
reference counting is introduced in this patch. It is expected that when
an IOASID is being freed, each user will drop a reference only after its
context is cleared.
Signed-off-by: Jacob Pan
---
drivers/iommu/ioasid.c | 113 +
include/linux/ioasid.h | 4 ++
2 files changed, 117 insertions(+)
diff --git a/drivers/iommu/ioasid.c b/drivers/iommu/ioasid.c
index f73b3dbfc37a..5f31d63c75b1 100644
--- a/drivers/iommu/ioasid.c
+++ b/drivers/iommu/ioasid.c
@@ -717,6 +717,119 @@ int ioasid_set_for_each_ioasid(struct ioasid_set *set,
EXPORT_SYMBOL_GPL(ioasid_set_for_each_ioasid);
/**
+ * IOASID refcounting rules
+ * - ioasid_alloc() set initial refcount to 1
+ *
+ * - ioasid_free() decrement and test refcount.
+ * If refcount is 0, ioasid will be freed. Deleted from the system-wide
+ * xarray as well as per set xarray. The IOASID will be returned to the
+ * pool and available for new allocations.
+ *
+ * If recount is non-zero, mark IOASID as IOASID_STATE_FREE_PENDING.
+ * No new reference can be added. The IOASID is not returned to the pool
+ * for reuse.
+ * After free, ioasid_get() will return error but ioasid_find() and other
+ * non refcount adding APIs will continue to work until the last reference
+ * is dropped
+ *
+ * - ioasid_get() get a reference on an active IOASID
+ *
+ * - ioasid_put() decrement and test refcount of the IOASID.
+ * If refcount is 0, ioasid will be freed. Deleted from the system-wide
+ * xarray as well as per set xarray. The IOASID will be returned to the
+ * pool and available for new allocations.
+ * Do nothing if refcount is non-zero.
+ *
+ * - ioasid_find() does not take reference, caller must hold reference
+ *
+ * ioasid_free() can be called multiple times without error until all refs are
+ * dropped.
+ */
+
+int ioasid_get_locked(struct ioasid_set *set, ioasid_t ioasid)
+{
+ struct ioasid_data *data;
+
+ data = xa_load(_allocator->xa, ioasid);
+ if (!data) {
+ pr_err("Trying to get unknown IOASID %u\n", ioasid);
+ return -EINVAL;
+ }
+ if (data->state == IOASID_STATE_FREE_PENDING) {
+ pr_err("Trying to get IOASID being freed%u\n", ioasid);
+ return -EBUSY;
+ }
+
+ if (set && data->set != set) {
+ pr_err("Trying to get IOASID not in set%u\n", ioasid);
+ /* data found but does not belong to the set */
+ return -EACCES;
+ }
+ refcount_inc(>users);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(ioasid_get_locked);
+
+/**
+ * ioasid_get - Obtain a reference of an ioasid
+ * @set
+ * @ioasid
+ *
+ * Check set ownership if @set is non-null.
+ */
+int ioasid_get(struct ioasid_set *set, ioasid_t ioasid)
+{
+ int ret = 0;
+
+ spin_lock(_allocator_lock);
+ ret = ioasid_get_locked(set, ioasid);
+ spin_unlock(_allocator_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(ioasid_get);
+
+void ioasid_put_locked(struct ioasid_set *set, ioasid_t ioasid)
+{
+ struct ioasid_data *data;
+
+ data = xa_load(_allocator->xa, ioasid);
+ if (!data) {
+ pr_err("Trying to put unknown IOASID %u\n", ioasid);
+ return;
+ }
+
+ if (set && data->set != set) {
+ pr_err("Trying to drop IOASID not in the set %u\n", ioasid);
+ return;
+ }
+
+ if (!refcount_dec_and_test(>users)) {
+ pr_debug("%s: IOASID %d has %d remainning users\n",
+ __func__, ioasid, refcount_read(>users));
+ return;
+ }
+ ioasid_do_free(data);
+}
+EXPORT_SYMBOL_GPL(ioasid_put_locked);
+
+/**
+ * ioasid_put - Drop a reference of an ioasid
+ * @set
+ * @ioasid
+ *
+ * Check set ownership if @set is non-null.
+ */
+void ioasid_put(struct ioasid_set *set, ioasid_t ioasid)
+{
+ spin_lock(_allocator_lock);
+ ioasid_put_locked(set, ioasid);
+ spin_unlock(_allocator_lock);
+}
+EXPORT_SYMBOL_GPL(ioasid_put);
+
+/**
* ioasid_find - Find IOASID data
* @set: the IOASID set
* @ioasid: the IOASID to find
Do you need to increase the refcount of the found ioasid and ask the
caller to drop it after use? Otherwise, the ioasid might be freed
elsewhere.
Best regards,
baolu
diff --git a/include/linux/ioasid.h b/include/linux/ioasid.h
index 412d025d440e..310abe4187a3 100644
--- a/include/linux/ioasid.h
+++ b/include/linux/ioasid.h
@@ -76,6 +76,10 @@ int ioasid_attach_data(ioasid_t ioasid, void *data);
int ioasid_register_allocator(struct ioasid_allocator_ops *allocator);
void ioasid_unregister_allocator(struct ioasid_allocator_ops *allocator);
void ioasid_is_in_set(struct ioasid_set *set, ioasid_t ioasid);
{standard input}:5973: Error: operand out of range (512 is not between -512 and 511)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: d012a7190fc1fd72ed48911e77ca97ba4521bccd
commit: de8f5e4f2dc1f032b46afda0a78cab5456974f89 lockdep: Introduce wait-type
checks
date: 5 months ago
config: arc-randconfig-r004-20200824 (attached as .config)
compiler: arc-elf-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout de8f5e4f2dc1f032b46afda0a78cab5456974f89
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
{standard input}: Assembler messages:
>> {standard input}:5973: Error: operand out of range (512 is not between -512
>> and 511)
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v2 3/9] iommu/ioasid: Introduce ioasid_set APIs
Hi Jacob,
On 8/22/20 12:35 PM, Jacob Pan wrote:
ioasid_set was introduced as an arbitrary token that are shared by a
group of IOASIDs. For example, if IOASID #1 and #2 are allocated via the
same ioasid_set*, they are viewed as to belong to the same set.
For guest SVA usages, system-wide IOASID resources need to be
partitioned such that VMs can have its own quota and being managed
separately. ioasid_set is the perfect candidate for meeting such
requirements. This patch redefines and extends ioasid_set with the
following new fields:
- Quota
- Reference count
- Storage of its namespace
- The token is stored in the new ioasid_set but with optional types
ioasid_set level APIs are introduced that wires up these new data.
Existing users of IOASID APIs are converted where a host IOASID set is
allocated for bare-metal usage.
Signed-off-by: Liu Yi L
Signed-off-by: Jacob Pan
---
drivers/iommu/intel/iommu.c | 27 ++-
drivers/iommu/intel/pasid.h | 1 +
drivers/iommu/intel/svm.c | 8 +-
drivers/iommu/ioasid.c | 390 +---
include/linux/ioasid.h | 82 --
5 files changed, 465 insertions(+), 43 deletions(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index a3a0b5c8921d..5813eeaa5edb 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -103,6 +104,9 @@
*/
#define INTEL_IOMMU_PGSIZES (~0xFFFUL)
+/* PASIDs used by host SVM */
+struct ioasid_set *host_pasid_set;
+
static inline int agaw_to_level(int agaw)
{
return agaw + 2;
@@ -3103,8 +3107,8 @@ static void intel_vcmd_ioasid_free(ioasid_t ioasid, void
*data)
* Sanity check the ioasid owner is done at upper layer, e.g. VFIO
* We can only free the PASID when all the devices are unbound.
*/
- if (ioasid_find(NULL, ioasid, NULL)) {
- pr_alert("Cannot free active IOASID %d\n", ioasid);
+ if (IS_ERR(ioasid_find(host_pasid_set, ioasid, NULL))) {
+ pr_err("Cannot free IOASID %d, not in system set\n", ioasid);
return;
}
vcmd_free_pasid(iommu, ioasid);
@@ -3288,6 +3292,19 @@ static int __init init_dmars(void)
if (ret)
goto free_iommu;
+ /* PASID is needed for scalable mode irrespective to SVM */
+ if (intel_iommu_sm) {
+ ioasid_install_capacity(intel_pasid_max_id);
+ /* We should not run out of IOASIDs at boot */
+ host_pasid_set = ioasid_alloc_set(NULL, PID_MAX_DEFAULT,
+ IOASID_SET_TYPE_NULL);
+ if (IS_ERR_OR_NULL(host_pasid_set)) {
+ pr_err("Failed to enable host PASID allocator %lu\n",
+ PTR_ERR(host_pasid_set));
+ intel_iommu_sm = 0;
+ }
+ }
+
/*
* for each drhd
* enable fault log
@@ -5149,7 +5166,7 @@ static void auxiliary_unlink_device(struct dmar_domain
*domain,
domain->auxd_refcnt--;
if (!domain->auxd_refcnt && domain->default_pasid > 0)
- ioasid_free(domain->default_pasid);
+ ioasid_free(host_pasid_set, domain->default_pasid);
}
static int aux_domain_add_dev(struct dmar_domain *domain,
@@ -5167,7 +5184,7 @@ static int aux_domain_add_dev(struct dmar_domain *domain,
int pasid;
/* No private data needed for the default pasid */
- pasid = ioasid_alloc(NULL, PASID_MIN,
+ pasid = ioasid_alloc(host_pasid_set, PASID_MIN,
pci_max_pasids(to_pci_dev(dev)) - 1,
NULL);
if (pasid == INVALID_IOASID) {
@@ -5210,7 +5227,7 @@ static int aux_domain_add_dev(struct dmar_domain *domain,
spin_unlock(>lock);
spin_unlock_irqrestore(_domain_lock, flags);
if (!domain->auxd_refcnt && domain->default_pasid > 0)
- ioasid_free(domain->default_pasid);
+ ioasid_free(host_pasid_set, domain->default_pasid);
return ret;
}
diff --git a/drivers/iommu/intel/pasid.h b/drivers/iommu/intel/pasid.h
index c9850766c3a9..ccdc23446015 100644
--- a/drivers/iommu/intel/pasid.h
+++ b/drivers/iommu/intel/pasid.h
@@ -99,6 +99,7 @@ static inline bool pasid_pte_is_present(struct pasid_entry
*pte)
}
extern u32 intel_pasid_max_id;
+extern struct ioasid_set *host_pasid_set;
int intel_pasid_alloc_id(void *ptr, int start, int end, gfp_t gfp);
void intel_pasid_free_id(int pasid);
void *intel_pasid_lookup_id(int pasid);
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index 37a9beabc0ca..634e191ca2c3 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -551,7 +551,7 @@ intel_svm_bind_mm(struct device *dev, int flags, struct
[PATCH] ntfs: add check for mft record size in superblock
number of bytes allocated for mft record should be equal to the mft
record size stored in ntfs superblock
as reported by syzbot, userspace might trigger out-of-bounds read by
dereferencing ctx->attr in ntfs_attr_find()
Reported-and-tested-by: syzbot+aed06913f36eff9b5...@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=aed06913f36eff9b544e
Signed-off-by: Rustam Kovhaev
Acked-by: Anton Altaparmakov
---
fs/ntfs/inode.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/ntfs/inode.c b/fs/ntfs/inode.c
index 9bb9f0952b18..caf563981532 100644
--- a/fs/ntfs/inode.c
+++ b/fs/ntfs/inode.c
@@ -1810,6 +1810,12 @@ int ntfs_read_inode_mount(struct inode *vi)
brelse(bh);
}
+ if (le32_to_cpu(m->bytes_allocated) != vol->mft_record_size) {
+ ntfs_error(sb, "Incorrect mft record size %u in superblock,
should be %u.",
+ le32_to_cpu(m->bytes_allocated),
vol->mft_record_size);
+ goto err_out;
+ }
+
/* Apply the mst fixups. */
if (post_read_mst_fixup((NTFS_RECORD*)m, vol->mft_record_size)) {
/* FIXME: Try to use the $MFTMirr now. */
--
2.28.0
Re: [PATCH v8 2/3] drm: bridge: Add support for Cadence MHDP DPI/DP bridge
Hi Tomi,
On Fri, Aug 14, 2020 at 12:29:35PM +0300, Tomi Valkeinen wrote:
> On 11/08/2020 05:36, Laurent Pinchart wrote:
>
> >> +static int cdns_mhdp_mailbox_write(struct cdns_mhdp_device *mhdp, u8 val)
> >> +{
> >> + int ret, full;
> >> +
> >> + WARN_ON(!mutex_is_locked(>mbox_mutex));
> >> +
> >> + ret = readx_poll_timeout(readl, mhdp->regs + CDNS_MAILBOX_FULL,
> >> + full, !full, MAILBOX_RETRY_US,
> >> + MAILBOX_TIMEOUT_US);
> >> + if (ret < 0)
> >> + return ret;
> >> +
> >> + writel(val, mhdp->regs + CDNS_MAILBOX_TX_DATA);
> >> +
> >> + return 0;
> >> +}
> >
> > As commented previously, I think there's room for optimization here. Two
> > options that I think should be investigated are using the mailbox
> > interrupts, and only polling for the first byte of the message
> > (depending on whether the firmware implementation can guarantee that
> > when the first byte is available, the rest of the message will be
> > immediately available too). This can be done on top of this patch
> > though.
>
> I made some tests on this.
>
> I cannot see mailbox_write ever looping, mailbox is never full. So in this
> case the
> readx_poll_timeout() call is there just for safety to catch the cases where
> something has gone
> totally wrong or perhaps once in a while the mbox can be full for a tiny
> moment. But we always do
> need to check CDNS_MAILBOX_FULL before each write to CDNS_MAILBOX_TX_DATA, so
> we can as well use
> readx_poll_timeout for that to catch the odd cases (afaics, there's no real
> overhead if the exit
> condition is true immediately).
>
> mailbox_read polls sometimes. Most often it does not poll, as the data is
> ready in the mbox, and in
> these cases the situation is the same as for mailbox_write.
>
> The cases where it does poll are related to things where the fw has to wait
> for something. The
> longest poll waits seemed to be EDID read (16 ms wait) and adjusting LT (1.7
> ms wait). And afaics,
> when the first byte of the received message is there, the rest of the bytes
> will be available
> without wait.
>
> For mailbox_write and for most mailbox_reads I think using interrupts makes
> no sense, as the
> overhead would be big.
>
> For those few long read operations, interrupts would make sense. I guess a
> simple way to handle this
> would be to add a new function, wait_for_mbox_data() or such, which would use
> the interrupts to wait
> for mbox not empty. This function could be used in selected functions (edid,
> LT) after
> cdns_mhdp_mailbox_send().
>
> Although I think it's not that bad currently, MAILBOX_RETRY_US is 1ms, so
> it's quite lazy polling,
> so perhaps this can be considered TODO optimization.
I'm fine with TODO optimization.
--
Regards,
Laurent Pinchart
Re: [PATCH v8 2/3] drm: bridge: Add support for Cadence MHDP DPI/DP bridge
Hi Tomi,
On Fri, Aug 14, 2020 at 11:22:09AM +0300, Tomi Valkeinen wrote:
> On 11/08/2020 05:36, Laurent Pinchart wrote:
>
> >> +static int cdns_mhdp_connector_init(struct cdns_mhdp_device *mhdp)
> >> +{
> >> + u32 bus_format = MEDIA_BUS_FMT_RGB121212_1X36;
> >> + struct drm_connector *conn = >connector;
> >> + struct drm_bridge *bridge = >bridge;
> >> + int ret;
> >> +
> >> + if (!bridge->encoder) {
> >> + DRM_ERROR("Parent encoder object not found");
> >> + return -ENODEV;
> >> + }
> >> +
> >> + conn->polled = DRM_CONNECTOR_POLL_HPD;
> >> +
> >> + ret = drm_connector_init(bridge->dev, conn, _mhdp_conn_funcs,
> >> + DRM_MODE_CONNECTOR_DisplayPort);
> >> + if (ret) {
> >> + DRM_ERROR("Failed to initialize connector with drm\n");
> >> + return ret;
> >> + }
> >> +
> >> + drm_connector_helper_add(conn, _mhdp_conn_helper_funcs);
> >> +
> >> + ret = drm_display_info_set_bus_formats(>display_info,
> >> + _format, 1);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + conn->display_info.bus_flags = DRM_BUS_FLAG_DE_HIGH;
> >
> > Aren't these supposed to be retrieved from the display ? Why do we need
> > to override them here ?
>
> DE_HIGH is meant for the display controller. I think this should be in
> bridge->timings->input_bus_flags
>
> >> +static int cdns_mhdp_atomic_check(struct drm_bridge *bridge,
> >> +struct drm_bridge_state *bridge_state,
> >> +struct drm_crtc_state *crtc_state,
> >> +struct drm_connector_state *conn_state)
> >> +{
> >> + struct cdns_mhdp_device *mhdp = bridge_to_mhdp(bridge);
> >> + const struct drm_display_mode *mode = _state->adjusted_mode;
> >> + int ret;
> >> +
> >> + if (!mhdp->plugged)
> >> + return 0;
> >> +
> >> + mutex_lock(>link_mutex);
> >> +
> >> + if (!mhdp->link_up) {
> >> + ret = cdns_mhdp_link_up(mhdp);
> >> + if (ret < 0)
> >> + goto err_check;
> >> + }
> >
> > atomic_check isn't supposed to access the hardware. Is there a reason
> > this is needed ?
>
> We have been going back and forth with this. The basic problem is that
> to understand which videomodes can be used, you need to do link
> training to see the bandwidth available.
>
> I'm not sure if we strictly need to do LT in atomic check, though...
> It would then pass modes that can't be used, but perhaps that's not a
> big issue.
>
> I think the main point with doing LT in certain places is to filter
> the list of video modes passed to userspace, as we can't pass the
> modes from EDID directly without filtering them based on the link
> bandwidth.
I've discussed this on #dri-devel with Daniel a week or two ago. His
advice was to drop LT from atomic check, relying on DPCD (DisplayPort
Configuration Data) instead. If LT then fails to negotiate a high-enough
bandwidth for the mode when enabling the output, the link-status
property should be set to bad, and userspace should retry. I think
you've seen the discussion, I can provide a log if needed.
--
Regards,
Laurent Pinchart
Re: Re: [PATCH] watchdog: Fix double-free in watchdog_cdev_register
> On 8/23/20 12:13 AM, Dinghao Liu wrote:
> > When misc_register() fails, wd_data will be released by the
> > release callback function watchdog_core_data_release(), so
> > we don't need to free it again. But when watchdog_kworker is
> > NULL, we should free wd_data to prevent memleak.
> >
> > Fixes: cb36e29bb0e4b ("watchdog: initialize device before misc_register")
> > Signed-off-by: Dinghao Liu
> > ---
> > drivers/watchdog/watchdog_dev.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/watchdog/watchdog_dev.c
> > b/drivers/watchdog/watchdog_dev.c
> > index 6798addabd5a..8ee78e26feb1 100644
> > --- a/drivers/watchdog/watchdog_dev.c
> > +++ b/drivers/watchdog/watchdog_dev.c
> > @@ -994,8 +994,10 @@ static int watchdog_cdev_register(struct
> > watchdog_device *wdd)
> > wd_data->wdd = wdd;
> > wdd->wd_data = wd_data;
> >
> > - if (IS_ERR_OR_NULL(watchdog_kworker))
> > + if (IS_ERR_OR_NULL(watchdog_kworker)) {
> > + kfree(wd_data);
>
> This should be a separate patch, with
>
> Fixes: 664a39236e718 ("watchdog: Introduce hardware maximum heartbeat in
> watchdog core")
>
Thank you for your advice. I will send a new patch to fix this soon.
> > return -ENODEV;
> > + }
> >
> > device_initialize(_data->dev);
> > wd_data->dev.devt = MKDEV(MAJOR(watchdog_devt), wdd->id);
> > @@ -1021,7 +1023,6 @@ static int watchdog_cdev_register(struct
> > watchdog_device *wdd)
> > pr_err("%s: a legacy watchdog module is
> > probably present.\n",
> > wdd->info->identity);
> > old_wd_data = NULL;
> > - kfree(wd_data);
>
> Are you sure about this ? put_device() isn't called on _data->dev
> (unlike the code further below). How do you trigger the double free,
> or, in other words, how is watchdog_core_data_release() ever called
> in this code path ?
>
> device_initialize() says:
> NOTE: Use put_device() to give up your reference instead of freeing
> @dev directly once you have called this function.
> so it looks like put_device() should be called instead of kfree().
>
You are right. The callback will free wd_data->dev after all references
have gone away. So we should use put_device() here. I will fix this soon.
Regards,
Dinghao
Re: [RFC PATCH 1/5] printk: implement pr_cont_t
On (20/08/20 12:16), Petr Mladek wrote: > Now that I think about it. This is the biggest problem with any temporary > buffer > for pr_cont() lines. I am more and more convinced that we should just > _keep the current behavior_. It is not ideal. But sometimes mixed > messages are always better than lost ones. Agreed. John, let's move this into a backlog for the time being? We can continue discussions, but first let's fix the empty lines for cont line print outs in the current dmesg output. -ss
[PATCH] regulator: rt4801: Fix W=1 build warning when CONFIG_OF=n
From: ChiYuan Huang
Fix below warning when CONFIG_OF=n:
drivers/regulator/rt4801-regulator.c:206:34: warning: unused variable
'rt4801_of_id' [-Wunused-const-variable]
206 | static const struct of_device_id rt4801_of_id[] = {
| ^~~~
Signed-off-by: ChiYuan Huang
Reported-by: kernel test robot
---
drivers/regulator/rt4801-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/rt4801-regulator.c
b/drivers/regulator/rt4801-regulator.c
index 0ddc670..2055a9c 100644
--- a/drivers/regulator/rt4801-regulator.c
+++ b/drivers/regulator/rt4801-regulator.c
@@ -203,7 +203,7 @@ static int rt4801_probe(struct i2c_client *i2c)
return 0;
}
-static const struct of_device_id rt4801_of_id[] = {
+static const struct of_device_id __maybe_unused rt4801_of_id[] = {
{ .compatible = "richtek,rt4801", },
{ },
};
--
2.7.4
Re: [PATCH] ntfs: add check for mft record size in superblock
Hi Rustam,
Thank you for the patch but it introduces an endianness bug - you have to us
le32_to_cpu(m->bytes_allocated) both when doing the comparison and then
printing the message.
Also, please drop the square brackets. Wherever the driver prints such things
it never uses brackets around the numbers and it would be better to have this
consistent throughout.
Can you please resend with the above issues addressed? You can then also add
to the commit message:
Acked-by: Anton Altaparmakov
Thanks!
Best regards,
Anton
> On 23 Aug 2020, at 16:21, Rustam Kovhaev wrote:
>
> number of bytes allocated for mft record should be equal to the mft
> record size stored in ntfs superblock
> as reported by syzbot, userspace might trigger out-of-bounds read by
> dereferencing ctx->attr in ntfs_attr_find()
>
> Reported-and-tested-by: syzbot+aed06913f36eff9b5...@syzkaller.appspotmail.com
> Link: https://syzkaller.appspot.com/bug?extid=aed06913f36eff9b544e
> Signed-off-by: Rustam Kovhaev
> ---
> fs/ntfs/inode.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/fs/ntfs/inode.c b/fs/ntfs/inode.c
> index 9bb9f0952b18..6407af7c2e4f 100644
> --- a/fs/ntfs/inode.c
> +++ b/fs/ntfs/inode.c
> @@ -1810,6 +1810,12 @@ int ntfs_read_inode_mount(struct inode *vi)
> brelse(bh);
> }
>
> + if (m->bytes_allocated != vol->mft_record_size) {
> + ntfs_error(sb, "Incorrect mft record size [%u] in superblock,
> should be [%u].",
> + m->bytes_allocated, vol->mft_record_size);
> + goto err_out;
> + }
> +
> /* Apply the mst fixups. */
> if (post_read_mst_fixup((NTFS_RECORD*)m, vol->mft_record_size)) {
> /* FIXME: Try to use the $MFTMirr now. */
> --
> 2.28.0
>
--
Anton Altaparmakov (replace at with @)
Lead in File System Development, Tuxera Inc., http://www.tuxera.com/
Linux NTFS maintainer
Re: [PATCH] ntfs: add check for mft record size in superblock
On Mon, Aug 24, 2020 at 01:44:06AM +, Anton Altaparmakov wrote: > Hi Rustam, > > Thank you for the patch but it introduces an endianness bug - you have to us > le32_to_cpu(m->bytes_allocated) both when doing the comparison and then > printing the message. > > Also, please drop the square brackets. Wherever the driver prints such > things it never uses brackets around the numbers and it would be better to > have this consistent throughout. > > Can you please resend with the above issues addressed? You can then also add > to the commit message: > > Acked-by: Anton Altaparmakov > > Thanks! > > Best regards, > > Anton > hi Anton, thank you for the review, my bad, i'll get it fixed and i'll resend the patch
Re: [PATCH] Add missing bound checks for software 842 decompressor
On 19.08.20 22:19, Kees Cook wrote:
On Sun, Aug 16, 2020 at 02:33:41AM +0200, Joan Bruguera wrote:
Any feedback?
Hi!
I just happened to see this email. I think this should likely be
directed to the crypto (which also handled compress/decompress APIs)
list and the original author...
Additional notes below...
Thanks for the review, much appreciated.
- Joan
On 05.06.20 17:44, Joan Bruguera wrote:
The software 842 decompressor receives, through the initial value of the
'olen' parameter, the capacity of the buffer pointed to by 'out'. If this
capacity is insufficient to decode the compressed bitstream, -ENOSPC
should be returned.
However, the bounds checks are missing for index references (for those
ops. where decomp_ops includes a I2, I4 or I8 subop.), and also for
OP_SHORT_DATA. Due to this, sw842_decompress can write past the capacity
of the 'out' buffer.
Eek. :(
It isn't much exploitable though, since AFAICT, compressed data can only
come from zram or pstore, not from userspace.
The case for index references can be triggered by compressing data that
follows a 16-byte periodic pattern (excluding special cases which are
better encoded by OP_ZEROS) and passing a 'olen' somewhat smaller than the
original length.
The case for OP_SHORT_DATA can be triggered by compressing an amount of
data that is not a multiple of 8, and then a slightly smaller 'olen' that
can't fit those last <8 bytes.
Following is a small test module to demonstrate the issue.
-
#include
#include
#include
static unsigned char workspace[100] = { 0 }; // Hacky
static void test_bound(const char *name, unsigned ibound, unsigned dbound)
{
uint8_t in[ibound], out[ibound * 4], decomp[ibound /* Overallocated */];
unsigned clen = ibound * 4, dlen = dbound, i;
int ret;
for (i = 0; i < ibound; i ++)
in[i] = i % 16; // 0, 1, 2, ..., 14, 15, 0, 1, 2, ...
for (i = dbound; i < ibound; i++)
decomp[i] = 0xFF; // Place guard bytes
ret = sw842_compress(in, ibound, out, , workspace);
BUG_ON(ret != 0);
ret = sw842_decompress(out, clen, decomp, );
if (ret != -ENOSPC) {
printk(KERN_ERR "%s: Expected ENOSPC to be returned\n", name);
}
for (i = dbound; i < ibound; i++) {
if (decomp[i] != 0xFF) {
printk(KERN_ERR "%s: Guard overwritten\n", name);
break;
}
}
}
int init_module(void)
{
test_bound("Index reference test", 256, 64);
test_bound("Short data test", 12, 8);
return -ECANCELED; // Do not leave this test module hanging around
}
void cleanup_module(void)
{
}
MODULE_LICENSE("GPL");
MODULE_SOFTDEP("pre: 842");
Can this test be added to the kernel source directly? It'd be nice to
add such a regression test.
I took a look and maybe it could go into the crypto self tests (in
crypto/testmgr.c)... but I'm not really sure if it fits there, since
this would be a regression test rather than the smoke tests that seem to
make most of that file, and this bug requires adding a custom method
testing whether the decompressor respects the output buffer size rather
than a simple test with just a simple input / output data test vector.
Were thinking of that, something else (e.g. Linux Test Project), or just
suggesting?
Signed-off-by: Joan Bruguera
---
lib/842/842_decompress.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/lib/842/842_decompress.c b/lib/842/842_decompress.c
index 582085ef8b4..c29fbfc9d08 100644
--- a/lib/842/842_decompress.c
+++ b/lib/842/842_decompress.c
@@ -202,6 +202,9 @@ static int __do_index(struct sw842_param *p, u8 size, u8
bits, u64 fsize)
(unsigned long)total,
(unsigned long)beN_to_cpu(>ostart[offset], size));
+ if (size > p->olen)
+ return -ENOSPC;
+
memcpy(p->out, >ostart[offset], size);
p->out += size;
p->olen -= size;
@@ -345,6 +348,9 @@ int sw842_decompress(const u8 *in, unsigned int ilen,
if (!bytes || bytes > SHORT_DATA_BITS_MAX)
return -EINVAL;
+ if (bytes > p.olen)
+ return -ENOSPC;
+
while (bytes-- > 0) {
ret = next_bits(, , 8);
if (ret)
Reviewed-by: Kees Cook
Re: [PATCH 1/2] KVM: LAPIC: Fix updating DFR missing apic map recalculation
ping, :)
On Wed, 19 Aug 2020 at 16:55, Wanpeng Li wrote:
>
> From: Wanpeng Li
>
> There is missing apic map recalculation after updating DFR, if it is
> INIT RESET, in x2apic mode, local apic is software enabled before.
> This patch fix it by introducing the function kvm_apic_set_dfr() to
> be called in INIT RESET handling path.
>
> Signed-off-by: Wanpeng Li
> ---
> arch/x86/kvm/lapic.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 5ccbee7..248095a 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -310,6 +310,12 @@ static inline void kvm_apic_set_ldr(struct kvm_lapic
> *apic, u32 id)
> atomic_set_release(>vcpu->kvm->arch.apic_map_dirty, DIRTY);
> }
>
> +static inline void kvm_apic_set_dfr(struct kvm_lapic *apic, u32 val)
> +{
> + kvm_lapic_set_reg(apic, APIC_DFR, val);
> + atomic_set_release(>vcpu->kvm->arch.apic_map_dirty, DIRTY);
> +}
> +
> static inline u32 kvm_apic_calc_x2apic_ldr(u32 id)
> {
> return ((id >> 4) << 16) | (1 << (id & 0xf));
> @@ -1984,10 +1990,9 @@ int kvm_lapic_reg_write(struct kvm_lapic *apic, u32
> reg, u32 val)
> break;
>
> case APIC_DFR:
> - if (!apic_x2apic_mode(apic)) {
> - kvm_lapic_set_reg(apic, APIC_DFR, val | 0x0FFF);
> -
> atomic_set_release(>vcpu->kvm->arch.apic_map_dirty, DIRTY);
> - } else
> + if (!apic_x2apic_mode(apic))
> + kvm_apic_set_dfr(apic, val | 0x0FFF);
> + else
> ret = 1;
> break;
>
> @@ -2303,7 +2308,7 @@ void kvm_lapic_reset(struct kvm_vcpu *vcpu, bool
> init_event)
> SET_APIC_DELIVERY_MODE(0, APIC_MODE_EXTINT));
> apic_manage_nmi_watchdog(apic, kvm_lapic_get_reg(apic, APIC_LVT0));
>
> - kvm_lapic_set_reg(apic, APIC_DFR, 0xU);
> + kvm_apic_set_dfr(apic, 0xU);
> apic_set_spiv(apic, 0xff);
> kvm_lapic_set_reg(apic, APIC_TASKPRI, 0);
> if (!apic_x2apic_mode(apic))
> --
> 2.7.4
>
[PATCH] mmc: sd: Use kobj_to_dev() instead of container_of()
Use kobj_to_dev() instead of container_of()
Signed-off-by: Tian Tao
---
drivers/mmc/core/sd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 5a2210c..a0d2c34 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -735,7 +735,7 @@ static struct attribute *sd_std_attrs[] = {
static umode_t sd_std_is_visible(struct kobject *kobj, struct attribute *attr,
int index)
{
- struct device *dev = container_of(kobj, struct device, kobj);
+ struct device *dev = kobj_to_dev(kobj);
struct mmc_card *card = mmc_dev_to_card(dev);
/* CIS vendor and device ids are available only for Combo cards */
--
2.7.4
答复: [PATCH] mmc: core: Initial support for SD express card/host
Hi Hansson:
If this patch will not be changed, I will post a patch for rtsx driver
according your patch.
>
> Rui,
>
> On Thu, 16 Jul 2020 at 16:16, Ulf Hansson wrote:
> >
> > In the SD specification v7.10 the SD express card has been added. This
> > new type of removable SD card, can be managed via a PCIe/NVMe based
> > interface, while also allowing backwards compatibility towards the
> > legacy SD interface.
> >
> > To keep the backwards compatibility, it's required to start the
> > initialization through the legacy SD interface. If it turns out that
> > the mmc host and the SD card, both supports the PCIe/NVMe interface,
> > then a switch should be allowed.
> >
> > Therefore, let's introduce some basic support for this type of SD
> > cards to the mmc core. The mmc host, should set MMC_CAP2_SD_EXP if it
> > supports this interface and MMC_CAP2_SD_EXP_1_2V, if also 1.2V is
> > supported, as to inform the core about it.
> >
> > To deal with the switch to the PCIe/NVMe interface, the mmc host is
> > required to implement a new host ops, ->init_sd_express(). Based on
> > the initial communication between the host and the card,
> > host->ios.timing is set to either MMC_TIMING_SD_EXP or
> > MMC_TIMING_SD_EXP_1_2V, depending on if 1.2V is supported or not. In
> > this way, the mmc host can check these values in its ->init_sd_express()
> > ops,
> to know how to proceed with the handover.
> >
> > Note that, to manage card insert/removal, the mmc core sticks with
> > using the ->get_cd() callback, which means it's the host's
> > responsibility to make sure it provides valid data, even if the card
> > may be managed by PCIe/NVMe at the moment. As long as the card seems
> > to be present, the mmc core keeps the card powered on.
> >
> > Cc: Greg Kroah-Hartman
> > Cc: Arnd Bergmann
> > Cc: Christoph Hellwig
> > Cc: Rui Feng
> > Signed-off-by: Ulf Hansson
>
> Rui, did you manage to get some time to look at $subject patch?
>
> If you need some help to understand what's needed to implement the
> corresponding support in drivers/mmc/host/rtsx_pci_sdmmc.c, then please
> just ask.
>
> I think it would make sense to queue changes for rtsx_pci at the same point as
> the mmc core changes. That's because I don't want to maintain code in the
> mmc core that's left unused.
>
> Kind regards
> Uffe
>
> > ---
> > drivers/mmc/core/core.c | 15 ++--
> > drivers/mmc/core/host.h | 6 +
> > drivers/mmc/core/sd_ops.c | 49
> > +--
> > drivers/mmc/core/sd_ops.h | 1 +
> > include/linux/mmc/host.h | 7 ++
> > 5 files changed, 74 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index
> > 8ccae6452b9c..6673c0f33cc7 100644
> > --- a/drivers/mmc/core/core.c
> > +++ b/drivers/mmc/core/core.c
> > @@ -2137,8 +2137,12 @@ static int mmc_rescan_try_freq(struct
> mmc_host
> > *host, unsigned freq)
> >
> > mmc_go_idle(host);
> >
> > - if (!(host->caps2 & MMC_CAP2_NO_SD))
> > - mmc_send_if_cond(host, host->ocr_avail);
> > + if (!(host->caps2 & MMC_CAP2_NO_SD)) {
> > + if (mmc_send_if_cond_pcie(host, host->ocr_avail))
> > + goto out;
> > + if (mmc_card_sd_express(host))
> > + return 0;
> > + }
> >
> > /* Order's important: probe SDIO, then SD, then MMC */
> > if (!(host->caps2 & MMC_CAP2_NO_SDIO)) @@ -2153,6 +2157,7
> @@
> > static int mmc_rescan_try_freq(struct mmc_host *host, unsigned freq)
> > if (!mmc_attach_mmc(host))
> > return 0;
> >
> > +out:
> > mmc_power_off(host);
> > return -EIO;
> > }
> > @@ -2280,6 +2285,12 @@ void mmc_rescan(struct work_struct *work)
> > goto out;
> > }
> >
> > + /* If an SD express card is present, then leave it as is. */
> > + if (mmc_card_sd_express(host)) {
> > + mmc_release_host(host);
> > + goto out;
> > + }
> > +
> > for (i = 0; i < ARRAY_SIZE(freqs); i++) {
> > unsigned int freq = freqs[i];
> > if (freq > host->f_max) { diff --git
> > a/drivers/mmc/core/host.h b/drivers/mmc/core/host.h index
> > 5e3b9534ffb2..ba407617ed23 100644
> > --- a/drivers/mmc/core/host.h
> > +++ b/drivers/mmc/core/host.h
> > @@ -77,5 +77,11 @@ static inline bool mmc_card_hs400es(struct
> mmc_card *card)
> > return card->host->ios.enhanced_strobe; }
> >
> > +static inline bool mmc_card_sd_express(struct mmc_host *host) {
> > + return host->ios.timing == MMC_TIMING_SD_EXP ||
> > + host->ios.timing == MMC_TIMING_SD_EXP_1_2V; }
> > +
> > #endif
> >
> > diff --git a/drivers/mmc/core/sd_ops.c b/drivers/mmc/core/sd_ops.c
> > index 22bf528294b9..d61ff811218c 100644
> > --- a/drivers/mmc/core/sd_ops.c
> > +++ b/drivers/mmc/core/sd_ops.c
> > @@ -158,7 +158,8 @@ int mmc_send_app_op_cond(struct mmc_host
Re: [PATCH v2] ARM: dts: imx7d-zii-rmu2: fix rgmii phy-mode for ksz9031 phy
Hi Chris,
On Sat, Aug 22, 2020 at 11:25 PM Chris Healy wrote:
>
> From: Chris Healy
>
> Since commit bcf3440c6dd7 ("net: phy: micrel: add phy-mode support for the
> KSZ9031 PHY") the networking is broken on the imx7d-zii-rmu2 board.
>
> The end result is that network receive behaviour is marginal with lots of
> RX CRC errors experienced and NFS frequently failing.
>
> Quoting the explanation from Andrew Lunn in commit 0672d22a19244
> ("ARM: dts: imx: Fix the AR803X phy-mode"):
>
> "The problem here is, all the DTs were broken since day 0. However,
> because the PHY driver was also broken, nobody noticed and it
> worked. Now that the PHY driver has been fixed, all the bugs in the
> DTs now become an issue"
>
> Fix it by switching to phy-mode = "rgmii-id".
>
> Fixes: bcf3440c6dd7 ("net: phy: micrel: add phy-mode support for the KSZ9031
> PHY")
> Signed-off-by: Chris Healy
Reviewed-by: Fabio Estevam
Re: [PATCH v2 2/2] KVM: LAPIC: Guarantee the timer is in tsc-deadline mode when setting
ping :)
On Wed, 12 Aug 2020 at 14:30, Wanpeng Li wrote:
>
> From: Wanpeng Li
>
> Check apic_lvtt_tscdeadline() mode directly instead of apic_lvtt_oneshot()
> and apic_lvtt_period() to guarantee the timer is in tsc-deadline mode when
> wrmsr MSR_IA32_TSCDEADLINE.
>
> Signed-off-by: Wanpeng Li
> ---
> v1 -> v2:
> * fix indentation
>
> arch/x86/kvm/lapic.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 79599af..abaf48e 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -2193,8 +2193,7 @@ void kvm_set_lapic_tscdeadline_msr(struct kvm_vcpu
> *vcpu, u64 data)
> {
> struct kvm_lapic *apic = vcpu->arch.apic;
>
> - if (!kvm_apic_present(vcpu) || apic_lvtt_oneshot(apic) ||
> - apic_lvtt_period(apic))
> + if (!kvm_apic_present(vcpu) || !apic_lvtt_tscdeadline(apic))
> return;
>
> hrtimer_cancel(>lapic_timer.timer);
> --
> 2.7.4
>
[PATCH v2] KVM: LAPIC: Narrow down the kick target vCPU
From: Wanpeng Li
The kick after setting KVM_REQ_PENDING_TIMER is used to handle the timer
fires on a different pCPU which vCPU is running on, this kick is expensive
since memory barrier, rcu, preemption disable/enable operations. We don't
need this kick when injecting already-expired timer, we also should call
out the VMX preemption timer case, which also passes from_timer_fn=false
but doesn't need a kick because kvm_lapic_expired_hv_timer() is called
from the target vCPU.
Signed-off-by: Wanpeng Li
---
v1 -> v2:
* update patch subject and changelog
* open code kvm_set_pending_timer()
arch/x86/kvm/lapic.c | 4 +++-
arch/x86/kvm/x86.c | 6 --
arch/x86/kvm/x86.h | 1 -
3 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 248095a..97f1dbf 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1642,7 +1642,9 @@ static void apic_timer_expired(struct kvm_lapic *apic,
bool from_timer_fn)
}
atomic_inc(>lapic_timer.pending);
- kvm_set_pending_timer(vcpu);
+ kvm_make_request(KVM_REQ_PENDING_TIMER, vcpu);
+ if (from_timer_fn)
+ kvm_vcpu_kick(vcpu);
}
static void start_sw_tscdeadline(struct kvm_lapic *apic)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 599d732..51b74d0 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1778,12 +1778,6 @@ static s64 get_kvmclock_base_ns(void)
}
#endif
-void kvm_set_pending_timer(struct kvm_vcpu *vcpu)
-{
- kvm_make_request(KVM_REQ_PENDING_TIMER, vcpu);
- kvm_vcpu_kick(vcpu);
-}
-
static void kvm_write_wall_clock(struct kvm *kvm, gpa_t wall_clock)
{
int version;
diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
index 995ab69..ea20b8b 100644
--- a/arch/x86/kvm/x86.h
+++ b/arch/x86/kvm/x86.h
@@ -246,7 +246,6 @@ static inline bool kvm_vcpu_latch_init(struct kvm_vcpu
*vcpu)
return is_smm(vcpu) || kvm_x86_ops.apic_init_signal_blocked(vcpu);
}
-void kvm_set_pending_timer(struct kvm_vcpu *vcpu);
void kvm_inject_realmode_interrupt(struct kvm_vcpu *vcpu, int irq, int
inc_eip);
void kvm_write_tsc(struct kvm_vcpu *vcpu, struct msr_data *msr);
--
2.7.4
Re: [PATCH v3 2/3] media: dt-bindings: media: xilinx: Add Xilinx UHD-SDI Receiver Subsystem
Hi Vishal, On Wed, Aug 19, 2020 at 07:40:16PM +0300, Laurent Pinchart wrote: > On Wed, Aug 19, 2020 at 01:45:34PM +, Vishal Sagar wrote: > > On Wednesday, July 15, 2020 9:59 PM, Laurent Pinchart wrote: > >> On Mon, Jul 13, 2020 at 12:54:47PM -0600, Rob Herring wrote: > >>> On Thu, Jun 18, 2020 at 11:03:03AM +0530, Vishal Sagar wrote: > Add bindings documentation for Xilinx UHD-SDI Receiver Subsystem. > > The Xilinx UHD-SDI Receiver Subsystem consists of SMPTE UHD-SDI (RX) IP > core, an SDI RX to Video Bridge IP core to convert SDI video to native > video and a Video In to AXI4-Stream IP core to convert native video to > AXI4-Stream. > > Signed-off-by: Vishal Sagar > --- > v3 > - bpc instead of bpp > - removed bpc as required property (default to 10 bpc) > - add dt-bindings/media/xilinx-sdi.h > - made line-rate as u32 instead of string > - fixed reg > - fixed s/upto/up to/ > > v2 > - Removed references to xlnx,video* > - Fixed as per Sakari Ailus and Rob Herring's comments > - Converted to yaml format > > .../bindings/media/xilinx/xlnx,sdirxss.yaml | 132 ++ > include/dt-bindings/media/xilinx-sdi.h| 20 +++ > 2 files changed, 152 insertions(+) > create mode 100644 > >> Documentation/devicetree/bindings/media/xilinx/xlnx,sdirxss.yaml > create mode 100644 include/dt-bindings/media/xilinx-sdi.h > > diff --git > >> a/Documentation/devicetree/bindings/media/xilinx/xlnx,sdirxss.yaml > >> b/Documentation/devicetree/bindings/media/xilinx/xlnx,sdirxss.yaml > new file mode 100644 > index ..6cfc18ca435f > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,sdirxss.yaml > @@ -0,0 +1,132 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/media/xilinx/xlnx,sdirxss.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > + > >> > >> I think a single blank line is enough. > > > > Ok I will remove extra empty line in next version. > > > +title: Xilinx SMPTE UHD-SDI Receiver Subsystem > + > +maintainers: > + - Vishal Sagar > + > +description: | > + The SMPTE UHD-SDI Receiver (RX) Subsystem allows you to quickly > create systems > + based on SMPTE SDI protocols. It receives unaligned native SDI > streams from > + the SDI GT PHY and outputs an AXI4-Stream video stream, native video, > or > + native SDI using Xilinx transceivers as the physical layer. > + > + The subsystem consists of > + 1 - SMPTE UHD-SDI Rx > + 2 - SDI Rx to Native Video Bridge > + 3 - Video In to AXI4-Stream Bridge > + > + The subsystem can capture SDI streams in up to 12G mode 8 data > streams and output > + a dual pixel per clock RGB/YUV444,422/420 10/12 bits per component > AXI4-Stream. > + > +properties: > + compatible: > +items: > + - enum: > +- xlnx,v-smpte-uhdsdi-rx-ss-2.0 > >>> > >>> Should be indented 2 more spaces. > >> > >> Or you could simply use > >> > >> properties: > >> compatible: > >> const: xlnx,v-smpte-uhdsdi-rx-ss-2.0 > > > > Ok I will fix this in the next version. > > > + > + reg: > +maxItems: 1 > + > + interrupts: > +maxItems: 1 > + > + clocks: > +description: List of clock specifiers > >>> > >>> Drop. That's every 'clocks' property. > > > > Ok I will drop the description in next version. > > > +items: > + - description: AXI4-Lite clock > + - description: SMPTE UHD-SDI Rx core clock > + - description: Video clock > + > + clock-names: > +items: > + - const: s_axi_aclk > + - const: sdi_rx_clk > + - const: video_out_clk > + > + xlnx,bpc: > +description: Bits per component supported. Can be 10 or 12 bits per > component only. > +allOf: > >>> > >>> You can drop the 'allOf' now. > > > > Ok will update this in next version. > > > + - $ref: "/schemas/types.yaml#/definitions/uint32" > + - enum: [10, 12] > >>> > >>> Seems like this should be a standard property? > >> > >> Rob, if my understanding is correct, this tells for how many bits per > >> component the IP core has been synthesized. I think it qualifies as a > >> vendor property, as how to express constraints on supported formats (for > >> IP cores that can be synthesized with different options) is highly > >> vendor-specific. > > > > Right Laurent. This is specific to Xilinx Video IP cores. > > > >> Vishal, I think the question I asked in the review of v2 fell through > >> the cracks. Is the documentation for the new IP core version
[tip:timers/core] BUILD SUCCESS e2d977c9f1abd1d199b412f8f83c1727808b794d
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core branch HEAD: e2d977c9f1abd1d199b412f8f83c1727808b794d timekeeping: Provide multi-timestamp accessor to NMI safe timekeeper elapsed time: 723m configs tested: 87 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig m68k m5475evb_defconfig m68k bvme6000_defconfig m68k sun3_defconfig archsdk_defconfig csky alldefconfig riscvnommu_virt_defconfig armneponset_defconfig h8300allyesconfig sh polaris_defconfig sh urquell_defconfig powerpc defconfig m68k apollo_defconfig mips malta_kvm_defconfig powerpc g5_defconfig x86_64 alldefconfig arm ep93xx_defconfig arm lpc32xx_defconfig sh shx3_defconfig powerpcamigaone_defconfig arm tango4_defconfig shshmin_defconfig arm tegra_defconfig armmps2_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a002-20200823 x86_64 randconfig-a003-20200823 x86_64 randconfig-a005-20200823 x86_64 randconfig-a001-20200823 x86_64 randconfig-a006-20200823 x86_64 randconfig-a004-20200823 i386 randconfig-a002-20200823 i386 randconfig-a004-20200823 i386 randconfig-a003-20200823 i386 randconfig-a005-20200823 i386 randconfig-a006-20200823 i386 randconfig-a001-20200823 i386 randconfig-a013-20200823 i386 randconfig-a012-20200823 i386 randconfig-a011-20200823 i386 randconfig-a016-20200823 i386 randconfig-a014-20200823 i386 randconfig-a015-20200823 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
linux-next: manual merge of the bpf-next tree with Linus' tree
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
tools/lib/bpf/libbpf.c
between commit:
1e891e513e16 ("libbpf: Fix map index used in error message")
from Linus' tree and commit:
88a82120282b ("libbpf: Factor out common ELF operations and improve logging")
from the bpf-next tree.
I fixed it up (the latter included the fix from the former) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgp8E2kQiBgLl.pgp
Description: OpenPGP digital signature
Re: [PATCH v8 1/4] power: supply: core: add quick charge type property
On Tue, Aug 18, 2020 at 2:07 PM Greg KH wrote: > > On Tue, Aug 18, 2020 at 09:56:28AM +0800, Qiwu Huang wrote: > > On Fri, Aug 14, 2020 at 2:09 PM Greg KH wrote: > > > > > > On Fri, Aug 14, 2020 at 11:46:54AM +0800, Qiwu Huang wrote: > > > > From: Qiwu Huang > > > > > > > > Reports the kind of quick charge type based on > > > > different adapter power. > > > > > > > > Signed-off-by: Qiwu Huang > > > > --- > > > > Documentation/ABI/testing/sysfs-class-power | 21 + > > > > drivers/power/supply/power_supply_sysfs.c | 1 + > > > > drivers/power/supply/qcom_smbb.c| 51 + > > > > include/linux/power_supply.h| 14 ++ > > > > 4 files changed, 87 insertions(+) > > > > > > You should also submit your driver that uses these new attributes at the > > > same time. What happened to that request? Otherwise no one really > > > knows how these are being used, or if they even are used by anyone. > > > > > > > I don't think I can submit the whole driver because our drivers are > > divided into three parts, the first part is in ADSP, the second part > > is in kernel and the third part is in Android Hal.This is the second > > part. > > WHat is "ADSP"? ADSP: advanced digital signal processor > > Just submit your kernel driver code, that's all we care about here. > Userspace code is not anything we can do anything with :) If we ported the full driver, we would break the existing driver structure because we would introduce more Qualcomm code. I think that's an unreasonable change. > > thanks, > > greg k-h -- Thanks Qiwu
Re: [PATCH v2] ARM: dts: r8a7742-iwg21d-q7: Add LCD support
Hi Prabhakar,
Thank you for the patch.
On Thu, Aug 13, 2020 at 03:00:41PM +0100, Lad Prabhakar wrote:
> The iwg21d comes with a 7" capacitive touch screen, therefore
> add support for it.
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Marian-Cristian Rotariu
>
Everything seems to match the schematics :-)
Reviewed-by: Laurent Pinchart
> ---
> v1->v2
> * This patch is part of series [1] (rest of the patches have be accepted
> by Geert [2]).
> * Added regulator for lvds
> * Added reset pin for touchpanel
> * This patch is based on series [3]
>
> [1] https://patchwork.kernel.org/project/linux-renesas-soc/list/
> ?series=330277
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/geert/
> renesas-devel.git/log/?h=renesas-arm-dt-for-v5.10
> [3] https://patchwork.kernel.org/project/linux-renesas-soc/list/
> ?series=330957
> ---
> arch/arm/boot/dts/r8a7742-iwg21d-q7.dts | 99 +
> 1 file changed, 99 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
> b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
> index b3461a61a4bf..9bf4fbd9c736 100644
> --- a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
> +++ b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
> @@ -30,6 +30,7 @@
>
> /dts-v1/;
> #include "r8a7742-iwg21m.dtsi"
> +#include
>
> / {
> model = "iWave Systems RainboW-G21D-Qseven board based on RZ/G1H";
> @@ -52,6 +53,51 @@
> clock-frequency = <2600>;
> };
>
> + lcd_backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = < 2 500 0>;
> + brightness-levels = <0 4 8 16 32 64 128 255>;
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> + default-brightness-level = <7>;
> + enable-gpios = < 11 GPIO_ACTIVE_HIGH>;
> + };
> +
> + lvds-receiver {
> + compatible = "ti,ds90cf384a", "lvds-decoder";
> + vcc-supply = <_3v3_tft1>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + lvds_receiver_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + lvds_receiver_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> + };
> +
> + panel {
> + compatible = "edt,etm0700g0dh6";
> + backlight = <_backlight>;
> + power-supply = <_3v3_tft1>;
> +
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <_receiver_out>;
> + };
> + };
> + };
> +
> reg_1p5v: 1p5v {
> compatible = "regulator-fixed";
> regulator-name = "1P5V";
> @@ -75,6 +121,17 @@
> };
> };
>
> + vcc_3v3_tft1: regulator-panel {
> + compatible = "regulator-fixed";
> +
> + regulator-name = "vcc-3v3-tft1";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + enable-active-high;
> + startup-delay-us = <500>;
> + gpio = < 28 GPIO_ACTIVE_HIGH>;
> + };
> +
> vcc_sdhi2: regulator-vcc-sdhi2 {
> compatible = "regulator-fixed";
>
> @@ -129,12 +186,34 @@
> VDDIO-supply = <_3p3v>;
> VDDD-supply = <_1p5v>;
> };
> +
> + touch: touchpanel@38 {
> + compatible = "edt,edt-ft5406";
> + reg = <0x38>;
> + interrupt-parent = <>;
> + interrupts = <24 IRQ_TYPE_EDGE_FALLING>;
> + /* GP1_29 is also shared with audio codec reset pin */
> + reset-gpios = < 29 GPIO_ACTIVE_LOW>;
> + vcc-supply = <_3v3_tft1>;
> + };
> };
>
> {
> status = "okay";
> };
>
> + {
> + status = "okay";
> +};
> +
> + {
> + touch-interrupt {
> + gpio-hog;
> + gpios = <24 GPIO_ACTIVE_LOW>;
> + input;
> + };
> +};
> +
> {
> pinctrl-0 = <_pins>;
> pinctrl-names = "default";
> @@ -165,6 +244,11 @@
> function = "avb";
> };
>
> + backlight_pins: backlight {
> + groups = "tpu0_to2";
> + function = "tpu0";
> + };
> +
> i2c2_pins: i2c2 {
> groups = "i2c2_b";
> function = "i2c2";
> @@ -208,6 +292,17 @@
> };
> };
>
> + {
> + status = "okay";
> + ports {
> + port@1 {
> + lvds0_out: endpoint {
> + remote-endpoint = <_receiver_in>;
> +
Re: ..and it built & boot without fuss!!Linux 5.9-rc2
On 14:23 Sun 23 Aug 2020, Linus Torvalds wrote: It's Sunday afternoon, which means it's time for another release candidate. Nothing in particular stands out, there's a random collection of fixes and updates in here. It is perhaps a bit filesystem-heavy, because the ext4 updates came in late, so a bit unusually we have 20+% of the patch being under fs/, and that's the biggest chunk in here after the usual driver updates (sound, gpu, networking, scsi, vfio). Other than that, it's mostly arch fixes and some tooling fixes, with a smattering elsewhere. The appended shortlog gives an overview of the details, it's all pretty small stuff. The diffstat shows the ext4 changes and a RISC-V timer chip standing out, and even those aren't really particularly big. Please test, Linus - Something for your eyes!! :) [3.197593] EXT4-fs (sda): mounted filesystem with ordered data mode. Opts: (null) [3.199024] ext4 filesystem being mounted at /root supports timestamps until 2038 (0x7fff) [3.199604] VFS: Mounted root (ext4 filesystem) on device 8:0. [3.205407] devtmpfs: mounted [3.218549] Freeing unused decrypted memory: 2040K [3.278265] Freeing unused kernel image (initmem) memory: 1608K [3.278973] Write protecting the kernel read-only data: 26624k [3.282717] Freeing unused kernel image (text/rodata gap) memory: 2040K [3.284312] Freeing unused kernel image (rodata/data gap) memory: 904K [3.285022] rodata_test: all tests were successful [3.285559] Run /sbin/init as init process [3.410069] tsc: Refined TSC clocksource calibration: 2194.918 MHz [3.410533] clocksource: tsc: mask: 0x max_cycles: 0x1fa37202099, max_idle_ns: 440795206796 ns [3.411227] clocksource: Switched to clocksource tsc [3.467617] EXT4-fs (sda): re-mounted. Opts: (null) [3.468312] ext4 filesystem being remounted at / supports timestamps until 2038 (0x7fff) Starting syslogd: OK Starting klogd: OK Running sysctl: OK Initializing random number generator: OK Saving random seed: [4.576470] random: dd: uninitialized urandom read (512 bytes read) OK Starting network: [4.659892] random: crng init done OK Welcome to Buildroot_Linux Bhaskar_Thinkpad_x250 login: root # uname -a Linux Bhaskar_Thinkpad_x250 5.9.0-rc2-Gentoo #1 SMP Mon Aug 24 04:28:02 IST 2020 x86_64 GNU/Linux ~Bhaskar Adrian Hunter (3): scsi: ufs-pci: Add quirk for broken auto-hibernate for Intel EHL scsi: ufs: Fix interrupt error message for shared interrupts scsi: ufs: Improve interrupt handling for shared interrupts Al Viro (1): do_epoll_ctl(): clean the failure exits up a bit Alaa Hleihel (1): net/sched: act_ct: Fix skb double-free in tcf_ct_handle_fragments() error flow Alain Volmat (1): spi: stm32: always perform registers configuration prior to transfer Alex Williamson (2): vfio-pci: Avoid recursive read-lock usage vfio/type1: Add proper error unwind for vfio_iommu_replay() Alex Zhuravlev (2): ext4: add prefetching for block allocation bitmaps ext4: skip non-loaded groups at cr=0/1 when scanning for good groups Alexander A. Klimov (1): ext4: replace HTTP links with HTTPS ones Alexander Tsoy (1): ALSA: usb-audio: Add capture support for Saffire 6 (USB 1.1) Alvin Šipraga (1): macvlan: validate setting of multiple remote source MAC addresses Amelie Delaunay (3): spi: stm32: fix fifo threshold level in case of short transfer spi: stm32: fix stm32_spi_prepare_mbr in case of odd clk_rate spi: stm32: fixes suspend/resume management Andrew Lunn (1): net: devlink: Remove overzealous WARN_ON with snapshots Andrii Nakryiko (13): bpf: Fix XDP FD-based attach/detach logic around XDP_FLAGS_UPDATE_IF_NOEXIST tools/bpftool: Make skeleton code C++17-friendly by dropping typeof() tools/bpftool: Fix compilation warnings in 32-bit mode selftest/bpf: Fix compilation warnings in 32-bit mode libbpf: Fix BTF-defined map-in-map initialization on 32-bit host arches libbpf: Handle BTF pointer sizes more carefully selftests/bpf: Fix btf_dump test cases on 32-bit arches libbpf: Enforce 64-bitness of BTF for BPF object files selftests/bpf: Correct various core_reloc 64-bit assumptions tools/bpftool: Generate data section struct with conservative alignment selftests/bpf: Make test_varlen work with 32-bit user-space arch libbpf: Fix build on ppc64le architecture bpf: xdp: Fix XDP mode when no mode flags specified Aneesh Kumar K.V (2): powerpc/pkeys: Fix build error with PPC_MEM_KEYS disabled mm/vunmap: add cond_resched() in vunmap_pmd_range Anju T Sudhakar (1): powerpc/perf: Add support for outputting extended regs in perf intr_regs Anthony Koo (2): drm/amd/display: Fix LFC multiplier changing erratically drm/amd/display: Switch to immediate mode for updating infopackets Antonio Borneo (1): spi:
Re: [PATCH v1 05/10] powerpc/pseries/iommu: Add iommu_pseries_alloc_table() helper
On 18/08/2020 09:40, Leonardo Bras wrote:
> Creates a helper to allow allocating a new iommu_table without the need
> to reallocate the iommu_group.
>
> This will be helpful for replacing the iommu_table for the new DMA window,
> after we remove the old one with iommu_tce_table_put().
>
> Signed-off-by: Leonardo Bras
> ---
> arch/powerpc/platforms/pseries/iommu.c | 25 ++---
> 1 file changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/iommu.c
> b/arch/powerpc/platforms/pseries/iommu.c
> index 8fe23b7dff3a..39617ce0ec83 100644
> --- a/arch/powerpc/platforms/pseries/iommu.c
> +++ b/arch/powerpc/platforms/pseries/iommu.c
> @@ -53,28 +53,31 @@ enum {
> DDW_EXT_QUERY_OUT_SIZE = 2
> };
>
> -static struct iommu_table_group *iommu_pseries_alloc_group(int node)
> +static struct iommu_table *iommu_pseries_alloc_table(int node)
> {
> - struct iommu_table_group *table_group;
> struct iommu_table *tbl;
>
> - table_group = kzalloc_node(sizeof(struct iommu_table_group), GFP_KERNEL,
> -node);
> - if (!table_group)
> - return NULL;
> -
> tbl = kzalloc_node(sizeof(struct iommu_table), GFP_KERNEL, node);
> if (!tbl)
> - goto free_group;
> + return NULL;
>
> INIT_LIST_HEAD_RCU(>it_group_list);
> kref_init(>it_kref);
> + return tbl;
> +}
>
> - table_group->tables[0] = tbl;
> +static struct iommu_table_group *iommu_pseries_alloc_group(int node)
> +{
> + struct iommu_table_group *table_group;
> +
> + table_group = kzalloc_node(sizeof(*table_group), GFP_KERNEL, node);
I'd prefer you did not make unrelated changes (sizeof(struct
iommu_table_group) -> sizeof(*table_group)) so the diff stays shorter
and easier to follow. You changed sizeof(struct iommu_table_group) but
not sizeof(struct iommu_table) and this confused me enough to spend more
time than this straight forward change deserves.
Not important in this case though so
Reviewed-by: Alexey Kardashevskiy
> + if (!table_group)
> + return NULL;
>
> - return table_group;
> + table_group->tables[0] = iommu_pseries_alloc_table(node);
> + if (table_group->tables[0])
> + return table_group;
>
> -free_group:
> kfree(table_group);
> return NULL;
> }
>
--
Alexey
[PATCH] Documentation: submit-checklist: add Documentation clean builds
From: Randy Dunlap Add to Documentation/process/submit-checklist.rst that patch submitters should run "make htmldocs" and verify that any Documentation/ changes (patches) are clean (no new warnings/errors). Signed-off-by: Randy Dunlap --- Documentation/process/submit-checklist.rst |4 1 file changed, 4 insertions(+) --- linux-next-20200821.orig/Documentation/process/submit-checklist.rst +++ linux-next-20200821/Documentation/process/submit-checklist.rst @@ -24,6 +24,10 @@ and elsewhere regarding submitting Linux c) Builds successfully when using ``O=builddir`` + d) Any Documentation/ changes build successfully without warnings/errors. + Use ``make htmldocs`` or ``make pdfdocs`` to check the build and + fix any issues. + 3) Builds on multiple CPU architectures by using local cross-compile tools or some other build farm.
[PATCH] Documentation/powerpc: fix malformed table in syscall64-abi
From: Randy Dunlap
Fix malformed table warning in powerpc/syscall64-abi.rst by making
two tables and moving the headings.
Documentation/powerpc/syscall64-abi.rst:53: WARNING: Malformed table.
Text in column margin in table line 2.
=== =
--- For the sc instruction, differences with the ELF ABI ---
r0 Volatile (System call number.)
r3 Volatile (Parameter 1, and return value.)
r4-r8 Volatile (Parameters 2-6.)
cr0 Volatile (cr0.SO is the return error condition.)
cr1, cr5-7 Nonvolatile
lr Nonvolatile
--- For the scv 0 instruction, differences with the ELF ABI ---
r0 Volatile (System call number.)
r3 Volatile (Parameter 1, and return value.)
r4-r8 Volatile (Parameters 2-6.)
=== =
Fixes: 7fa95f9adaee ("powerpc/64s: system call support for scv/rfscv
instructions")
Signed-off-by: Randy Dunlap
Cc: Nicholas Piggin
Cc: Michael Ellerman
---
Documentation/powerpc/syscall64-abi.rst |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- lnx-59-rc2.orig/Documentation/powerpc/syscall64-abi.rst
+++ lnx-59-rc2/Documentation/powerpc/syscall64-abi.rst
@@ -49,16 +49,18 @@ Register preservation rules
Register preservation rules match the ELF ABI calling sequence with the
following differences:
-=== =
--- For the sc instruction, differences with the ELF ABI ---
+=== =
r0 Volatile (System call number.)
r3 Volatile (Parameter 1, and return value.)
r4-r8 Volatile (Parameters 2-6.)
cr0 Volatile (cr0.SO is the return error condition.)
cr1, cr5-7 Nonvolatile
lr Nonvolatile
+=== =
--- For the scv 0 instruction, differences with the ELF ABI ---
+=== =
r0 Volatile (System call number.)
r3 Volatile (Parameter 1, and return value.)
r4-r8 Volatile (Parameters 2-6.)
linux-next: build failure after merge of the hwmon-staging tree
Hi all,
After merging the hwmon-staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/hwmon/pmbus/adm1266.c: In function 'adm1266_probe':
drivers/hwmon/pmbus/adm1266.c:478:31: error: passing argument 2 of
'pmbus_do_probe' from incompatible pointer type
[-Werror=incompatible-pointer-types]
478 | ret = pmbus_do_probe(client, id, >info);
| ^~
| |
| const struct i2c_device_id *
In file included from drivers/hwmon/pmbus/adm1266.c:20:
drivers/hwmon/pmbus/pmbus.h:492:73: note: expected 'struct pmbus_driver_info *'
but argument is of type 'const struct i2c_device_id *'
492 | int pmbus_do_probe(struct i2c_client *client, struct pmbus_driver_info
*info);
|
~~^~~~
drivers/hwmon/pmbus/adm1266.c:478:8: error: too many arguments to function
'pmbus_do_probe'
478 | ret = pmbus_do_probe(client, id, >info);
|^~
In file included from drivers/hwmon/pmbus/adm1266.c:20:
drivers/hwmon/pmbus/pmbus.h:492:5: note: declared here
492 | int pmbus_do_probe(struct i2c_client *client, struct pmbus_driver_info
*info);
| ^~
cc1: some warnings being treated as errors
Caused by commit
9832ecffd8f8 ("hwmon: (pmbus) Add support for ADM1266")
interacting with commit
d46dc459db38 ("hwmon (pmbus) use simple i2c probe function")
I have used the hwmon-staging tree from next-20200821 for today.
--
Cheers,
Stephen Rothwell
pgpWmje3l3Q1_.pgp
Description: OpenPGP digital signature
Re: [PATCH 4/4] mm: Add PGREUSE counter
On Sat, Aug 22, 2020 at 09:14:53AM -0700, Linus Torvalds wrote: > On Fri, Aug 21, 2020 at 4:50 PM Peter Xu wrote: > > > > This accounts for wp_page_reuse() case, where we reused a page for COW. > > If we do this, wouldn't it make more sense to also count the COW case > to see how they match up? Is wp_page_reuse() only used in cow? I saw that the callers of wp_page_reuse() are: (1) finish_mkwrite_fault (2) wp_pfn_shared (3) wp_page_shared (4) do_wp_page Since (1) is only called by either (2) or (3), while (2) and (3) apply only to shared memories, so I'm kind of sure the statistic is done via the changed path in do_wp_page() that is touched in patch 1 (my program was using private anonymous pages). Maybe I missed something, though.. > > Right now we count faults and major faults. So as a result you can can > calculate minor faults trivially. > > But if you count page reuse, you can't calculate any stats on it, > because most of the minor faults will presumably be for new pages > (either zero or cached file mappings). > > So the "pgreuse" seems to be a counter without any context to it. > > IOW, I get the feeling that either we should do this properly (and > maybe count "dirty faults" and "access" faults, at which point the > reuse case becomes a subcase of the dirty ones) or we shouldn't do it > at all. Creating a counter without any way to sanely compare it to > anything seems a bit pointless. Yeah I haven't thought deep about this statistic, imho it would be something nice to have (besides helping me to verify the tests) so I still posted it instead of keeping it in the local repo. If this statistic is not liked by anyone, then we can definitely drop it. Thanks, -- Peter Xu
Re: [PATCH] KVM: LAPIC: Don't kick vCPU which is injecting already-expired timer
On Sat, 22 Aug 2020 at 12:01, Sean Christopherson wrote: > > On Fri, Aug 21, 2020 at 05:17:34PM +0800, Wanpeng Li wrote: > > From: Wanpeng Li > > > > The kick after setting KVM_REQ_PENDING_TIMER is used to handle the timer > > fires on a different pCPU which vCPU is running on, we don't need this > > kick when injecting already-expired timer, this kick is expensive since > > memory barrier, rcu, preemption disable/enable operations. This patch > > reduces the overhead by don't kick vCPU which is injecting already-expired > > timer. > > This should also call out the VMX preemption timer case, which also passes > from_timer_fn=false but doesn't need a kick because > kvm_lapic_expired_hv_timer() > is called from the target vCPU. > > > Signed-off-by: Wanpeng Li > > --- > > arch/x86/kvm/lapic.c | 2 +- > > arch/x86/kvm/x86.c | 5 +++-- > > arch/x86/kvm/x86.h | 2 +- > > 3 files changed, 5 insertions(+), 4 deletions(-) > > > > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c > > index 248095a..5b5ae66 100644 > > --- a/arch/x86/kvm/lapic.c > > +++ b/arch/x86/kvm/lapic.c > > @@ -1642,7 +1642,7 @@ static void apic_timer_expired(struct kvm_lapic > > *apic, bool from_timer_fn) > > } > > > > atomic_inc(>lapic_timer.pending); > > - kvm_set_pending_timer(vcpu); > > + kvm_set_pending_timer(vcpu, from_timer_fn); > > My vote would be to open code kvm_set_pending_timer() here and drop the > helper, i.e. > > kvm_make_request(KVM_REQ_PENDING_TIMER, vcpu); > if (from_timer_fn) > kvm_vcpu_kick(vcpu); > > with that and an updated changelog: Agreed. > > Reviewed-by: Sean Christopherson Thanks. Wanpeng
Re: [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
Hi Logan/All,
I have added a check for the sg_dma_len == 0 :
"""
} __sgt_iter(struct scatterlist *sgl, bool dma) {
struct sgt_iter s = { .sgp = sgl };
+ if (sgl && sg_dma_len(sgl) == 0)
+ s.sgp = NULL;
if (s.sgp) {
.
"""
at location [1].
but it doens't fix the problem.
You're right though, this change does need to be made, this code
doesn't handle pages of sg_dma_len(sg) == 0 correctly
So my guess is that we have more bugs in other parts of the i915
driver (or there is a problem with my "sg_dma_len == 0" fix above).
I have been trying to spot where else the code might be buggy but I
haven't had any luck so far.
I'm doing a microconfernce (at LPC 2020) this wednesdays [1] on this
if you're interested in attending.
I'm hoping I can chat about it with a few people and find how can
reproduce and fix this issues. I don't have any more time I can give
to this unfortunately and it would be a shame for the work to go to
waste.
[0]
https://github.com/torvalds/linux/blob/d012a7190fc1fd72ed48911e77ca97ba4521bccd/drivers/gpu/drm/i915/i915_scatterlist.h#L28
[1] https://linuxplumbersconf.org/event/7/contributions/846/
On Fri, 29 May 2020 at 22:21, Logan Gunthorpe wrote:
>
>
>
> On 2020-05-29 3:11 p.m., Marek Szyprowski wrote:
> > Patches are pending:
> > https://lore.kernel.org/linux-iommu/20200513132114.6046-1-m.szyprow...@samsung.com/T/
>
> Cool, nice! Though, I still don't think that fixes the issue in
> i915_scatterlist.h given it still ignores sg_dma_len() and strictly
> relies on sg_next()/sg_is_last() to stop iterating -- and I suspect this
> is the bug that got in Tom's way.
>
> >> However, as Robin pointed out, there are other ugly tricks like stopping
> >> iterating through the SGL when sg_dma_len() is zero. For example, the
> >> AMD driver appears to use drm_prime_sg_to_page_addr_arrays() which does
> >> this trick and thus likely isn't buggy (otherwise, I'd expect someone to
> >> have complained by now seeing AMD has already switched to IOMMU-DMA.
> >
> > I'm not sure that this is a trick. Stopping at zero sg_dma_len() was
> > somewhere documented.
>
> Well whatever you want to call it, it is ugly to have some drivers doing
> one thing with the returned value and others assuming there's an extra
> zero at the end. It just causes confusion for people reading/copying the
> code. It would be better if they are all consistent. However, I concede
> stopping at zero should not be broken, presently.
>
> Logan
[PATCH] Documentation: sound/cards: fix heading underline lengths for https: changes
From: Randy Dunlap
Fix documentation build warnings for underline length too short,
caused by s/http/https/ and not changing the accompanying underlines.
Documentation/sound/cards/audigy-mixer.rst:335: WARNING: Title underline too
short.
US Patents (https://www.uspto.gov/)
--
Documentation/sound/cards/sb-live-mixer.rst:340: WARNING: Title underline too
short.
US Patents (https://www.uspto.gov/)
--
Fixes: 7ed33ea6b4fa ("ALSA: Replace HTTP links with HTTPS ones")
Signed-off-by: Randy Dunlap
Cc: Alexander A. Klimov
Cc: Takashi Iwai
---
Documentation/sound/cards/audigy-mixer.rst |2 +-
Documentation/sound/cards/sb-live-mixer.rst |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- lnx-59-rc2.orig/Documentation/sound/cards/audigy-mixer.rst
+++ lnx-59-rc2/Documentation/sound/cards/audigy-mixer.rst
@@ -332,7 +332,7 @@ WO 9901953 (A1)
US Patents (https://www.uspto.gov/)
---
+---
US 5925841
Digital Sampling Instrument employing cache memory (Jul. 20, 1999)
--- lnx-59-rc2.orig/Documentation/sound/cards/sb-live-mixer.rst
+++ lnx-59-rc2/Documentation/sound/cards/sb-live-mixer.rst
@@ -337,7 +337,7 @@ WO 9901953 (A1)
US Patents (https://www.uspto.gov/)
---
+---
US 5925841
Digital Sampling Instrument employing cache memory (Jul. 20, 1999)
Re: kernel BUG at kernel/fork.c:LINE!
On Sun, Aug 23, 2020 at 10:34 AM Randy Dunlap wrote: > > On 8/7/20 2:16 PM, syzbot wrote: > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit:fffe3ae0 Merge tag 'for-linus-hmm' of git://git.kernel.org.. > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=1194d90a90 > > kernel config: https://syzkaller.appspot.com/x/.config?x=18bb86f2e4ebfda2 > > dashboard link: https://syzkaller.appspot.com/bug?extid=3776ecd80aac504e6085 > > compiler: gcc (GCC) 10.1.0-syz 20200507 > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+3776ecd80aac504e6...@syzkaller.appspotmail.com > > Is this fixed by > > commit 991e7673859ed41e7ba83c8c4e57afe8cfebe314 > Author: Shakeel Butt > Date: Thu Aug 6 23:21:37 2020 -0700 > > mm: memcontrol: account kernel stack per node > > > since the BUG_ON() at line 390 is removed by this patch. > It's not really removed. The BUG_ON() has been moved to line 402. So, this issue might still occur. > > > [ cut here ] > > kernel BUG at kernel/fork.c:390! > > invalid opcode: [#1] PREEMPT SMP KASAN > > CPU: 0 PID: 5239 Comm: syz-executor.1 Not tainted 5.8.0-syzkaller #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google 01/01/2011 > > RIP: 0010:account_kernel_stack+0x297/0x320 kernel/fork.c:390 > > Code: 89 e2 be 23 00 00 00 48 89 ef c1 e2 05 e8 81 9e 75 00 48 83 c4 10 5b > > 5d 41 5c 41 5d 41 5e 41 5f e9 ae c9 2f 00 e8 a9 c9 2f 00 <0f> 0b e8 f2 50 > > 6f 00 e9 d2 fd ff ff e8 98 c9 2f 00 48 c7 c6 20 24 > > RSP: 0018:c90015e4f850 EFLAGS: 00010216 > > RAX: 01f4 RBX: RCX: c90017983000 > > RDX: 0004 RSI: 81445327 RDI: 0005 > > RBP: R08: 0001 R09: 8880a2ef9663 > > R10: 0008 R11: R12: > > R13: 8880001b2280 R14: 88809e4fa840 R15: > > FS: 7f7f035e5700() GS:8880ae60() knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: 001b2fd3 CR3: 9b747000 CR4: 001506f0 > > DR0: DR1: DR2: > > DR3: DR6: fffe0ff0 DR7: 0400 > > Call Trace: > > release_task_stack kernel/fork.c:447 [inline] > > put_task_stack+0xc4/0x230 kernel/fork.c:459 > > finish_task_switch+0x52a/0x750 kernel/sched/core.c:3649 > > context_switch kernel/sched/core.c:3781 [inline] > > __schedule+0x8ed/0x21e0 kernel/sched/core.c:4527 > > schedule+0xd0/0x2a0 kernel/sched/core.c:4602 > > freezable_schedule include/linux/freezer.h:172 [inline] > > futex_wait_queue_me+0x2a7/0x570 kernel/futex.c:2588 > > futex_wait+0x1df/0x560 kernel/futex.c:2690 > > do_futex+0x15b/0x1a60 kernel/futex.c:3749 > > __do_sys_futex kernel/futex.c:3810 [inline] > > __se_sys_futex kernel/futex.c:3778 [inline] > > __x64_sys_futex+0x378/0x4e0 kernel/futex.c:3778 > > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > RIP: 0033:0x45ccd9 > > Code: 2d b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 > > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff > > ff 0f 83 fb b5 fb ff c3 66 2e 0f 1f 84 00 00 00 00 > > RSP: 002b:7f7f035e4cf8 EFLAGS: 0246 ORIG_RAX: 00ca > > RAX: ffda RBX: 0078bfa8 RCX: 0045ccd9 > > RDX: RSI: 0080 RDI: 0078bfa8 > > RBP: 0078bfa0 R08: R09: > > R10: R11: 0246 R12: 0078bfac > > R13: 7fff896cb67f R14: 7f7f035e59c0 R15: 0078bfac > > Modules linked in: > > ---[ end trace ff14b6c5822b8142 ]--- > > RIP: 0010:account_kernel_stack+0x297/0x320 kernel/fork.c:390 > > Code: 89 e2 be 23 00 00 00 48 89 ef c1 e2 05 e8 81 9e 75 00 48 83 c4 10 5b > > 5d 41 5c 41 5d 41 5e 41 5f e9 ae c9 2f 00 e8 a9 c9 2f 00 <0f> 0b e8 f2 50 > > 6f 00 e9 d2 fd ff ff e8 98 c9 2f 00 48 c7 c6 20 24 > > RSP: 0018:c90015e4f850 EFLAGS: 00010216 > > RAX: 01f4 RBX: RCX: c90017983000 > > RDX: 0004 RSI: 81445327 RDI: 0005 > > RBP: R08: 0001 R09: 8880a2ef9663 > > R10: 0008 R11: R12: > > R13: 8880001b2280 R14: 88809e4fa840 R15: > > FS: 7f7f035e5700() GS:8880ae60() knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: 001b2fd3 CR3: 9b747000 CR4: 001506f0 > > DR0: DR1: DR2: > > DR3: DR6: fffe0ff0 DR7:
Re: [PATCH] ARM: dts: imx6sx-sdb: Add headphone detection for sound card
On Sun, Aug 23, 2020 at 11:12:08AM -0300, Fabio Estevam wrote: > Hi Wang Shengjiu and Shawn, > > On Sun, Aug 23, 2020 at 9:31 AM S.j. Wang wrote: > > > I would like to know your opinion, should I move headphone detect GPIO > > To audmux group? > > What about adding a dedicated pinctrl_hp for the headphone detect pin > like it is done at: > https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git/tree/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi?h=for-next=8f0216b006e5f553d28c4c1a991b5234693a49cb#n130 > > My point is that we should avoid adding a hog group when possible. I agree. Hog group should be used as the last sort, when there is no clear client device owning the pins. Shawn
Re: [PATCH 0/4] mm: Simplfy cow handling
On Sat, Aug 22, 2020 at 09:05:37AM -0700, Linus Torvalds wrote: > On Fri, Aug 21, 2020 at 4:50 PM Peter Xu wrote: > > > > - Run a busy loop dirty program [1] that uses 6G of memory, restrict to 1G > > RAM + 5G swap (cgroup). A few hours later, all things still look good. > > Make sure to observe (still massive) correct page reuses using the new > > counter using the last patch, probably when swapping in. > > > > - Run umapsort [2] to make sure uffd-wp will work again after applying > > this > > series upon master 5.9-rc1 (5.9-rc1 is broken). > > I obviously like the diffstat, am wondering if you saw any throughput > changes or similar for the busy-loop dirtying thing? I didn't compare the two in my previous testing. Firstly, although my program did output some dirty rate information in per second basis, the dirty rate is kind of fluctuating during the runs due to frequent swap in/out pages, and I cannot observe a stable dirty rate at least with the patch applied. I'm afraid I'll see similar thing even without applying the patch. Maybe it'll show some statistic pattern if I do it per 10sec or longer, but not sure. More importantly, I'm not sure whether that's the major case to compare either if we want to have some rough understanding about patch 1 on the performance impact. The thing is, my test program only dirtied some private allocated pages with itself as the only owner of the pages. IIUC the page reuse logic will trigger on either the old or new code because both the mapcount or refcount will be one. If we really want to compare the two, shouldn't we run some tests that will trigger the COW differently before/after the patch? E.g., when some pages are referenced by some GUP users and when COW happens with only one pte mapped to the page. I haven't thought deeper than this on such a test yet. So my previous testing was majorly for making sure the general cow and the swap path will at least still behave as expected. Thanks, -- Peter Xu
[PATGCH -next] LSM: SafeSetID: fix underline length warning
From: Randy Dunlap
Fix documentation build warning:
Documentation/admin-guide/LSM/SafeSetID.rst:110: WARNING: Title underline too
short.
Note on GID policies and setgroups()
==
Fixes: 02e316b088df ("LSM: SafeSetID: Add GID security policy handling")
Signed-off-by: Randy Dunlap
Cc: Thomas Cedeno
Cc: Micah Morton
---
Documentation/admin-guide/LSM/SafeSetID.rst |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20200821.orig/Documentation/admin-guide/LSM/SafeSetID.rst
+++ linux-next-20200821/Documentation/admin-guide/LSM/SafeSetID.rst
@@ -107,7 +107,7 @@ for a UID/GID will prevent that UID/GID
privileges, such as allowing a user to set up user namespace UID/GID mappings.
Note on GID policies and setgroups()
-==
+
In v5.9 we are adding support for limiting CAP_SETGID privileges as was done
previously for CAP_SETUID. However, for compatibility with common sandboxing
related code conventions in userspace, we currently allow arbitrary
Re: [PATCH] scsi: scsi_debug: Remove superfluous close zone in resp_open_zone()
On 2020/08/21 22:00, Niklas Cassel wrote: > resp_open_zone() always calls zbc_open_zone() with parameter explicit > set to true. > > If zbc_open_zone() is called with parameter explicit set to true, and > the current zone state is implicit open, it will call zbc_close_zone() > on the zone before proceeding. > > Therefore, there is no need for resp_open_zone() to call zbc_close_zone() > on an implicitly open zone before calling zbc_open_zone(). > > Remove superfluous close zone in resp_open_zone(). > > Signed-off-by: Niklas Cassel > --- > drivers/scsi/scsi_debug.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c > index 064ed680c0530..912d6f4878bae 100644 > --- a/drivers/scsi/scsi_debug.c > +++ b/drivers/scsi/scsi_debug.c > @@ -4482,8 +4482,6 @@ static int resp_open_zone(struct scsi_cmnd *scp, struct > sdebug_dev_info *devip) > goto fini; > } > > - if (zc == ZC2_IMPLICIT_OPEN) > - zbc_close_zone(devip, zsp); > zbc_open_zone(devip, zsp, true); > fini: > write_unlock(macc_lckp); > Looks good. Reviewed-by: Damien Le Moal -- Damien Le Moal Western Digital Research
[PATCH] Documentation: fix dma-buf.rst underline length warning
From: Randy Dunlap
/home/rdunlap/lnx/lnx-59-rc2/Documentation/driver-api/dma-buf.rst:182: WARNING:
Title underline too short.
Indefinite DMA Fences
Fixes: 72b6ede73623 ("dma-buf.rst: Document why indefinite fences are a bad
idea")
Signed-off-by: Randy Dunlap
Cc: Daniel Vetter
Cc: Daniel Vetter
Cc: Dave Airlie
---
Documentation/driver-api/dma-buf.rst |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- lnx-59-rc2.orig/Documentation/driver-api/dma-buf.rst
+++ lnx-59-rc2/Documentation/driver-api/dma-buf.rst
@@ -179,7 +179,7 @@ DMA Fence uABI/Sync File
:internal:
Indefinite DMA Fences
-
+~
At various times _fence with an indefinite time until dma_fence_wait()
finishes have been proposed. Examples include:
arch/powerpc/platforms/4xx/gpio.c:63:28: sparse: sparse: incorrect type in argument 1 (different base types)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: d012a7190fc1fd72ed48911e77ca97ba4521bccd commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to define address spaces date: 9 weeks ago config: powerpc64-randconfig-s032-20200824 (attached as .config) compiler: powerpc-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.2-191-g10164920-dirty git checkout 670d0a4b10704667765f7d18f7592993d02783aa # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> arch/powerpc/platforms/4xx/gpio.c:63:28: sparse: sparse: incorrect type in >> argument 1 (different base types) @@ expected unsigned int const >> volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 >> [noderef] __iomem * @@ >> arch/powerpc/platforms/4xx/gpio.c:63:28: sparse: expected unsigned int >> const volatile [noderef] [usertype] __iomem *addr >> arch/powerpc/platforms/4xx/gpio.c:63:28: sparse: got restricted __be32 >> [noderef] __iomem * >> arch/powerpc/platforms/4xx/gpio.c:103:9: sparse: sparse: incorrect type in >> argument 1 (different base types) @@ expected unsigned int volatile >> [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] >> __iomem * @@ >> arch/powerpc/platforms/4xx/gpio.c:103:9: sparse: expected unsigned int >> volatile [noderef] [usertype] __iomem *addr arch/powerpc/platforms/4xx/gpio.c:103:9: sparse: got restricted __be32 [noderef] __iomem * arch/powerpc/platforms/4xx/gpio.c:103:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int const volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] __iomem * @@ arch/powerpc/platforms/4xx/gpio.c:103:9: sparse: expected unsigned int const volatile [noderef] [usertype] __iomem *addr arch/powerpc/platforms/4xx/gpio.c:103:9: sparse: got restricted __be32 [noderef] __iomem * arch/powerpc/platforms/4xx/gpio.c:106:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] __iomem * @@ arch/powerpc/platforms/4xx/gpio.c:106:9: sparse: expected unsigned int volatile [noderef] [usertype] __iomem *addr arch/powerpc/platforms/4xx/gpio.c:106:9: sparse: got restricted __be32 [noderef] __iomem * arch/powerpc/platforms/4xx/gpio.c:106:9: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int const volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] __iomem * @@ arch/powerpc/platforms/4xx/gpio.c:106:9: sparse: expected unsigned int const volatile [noderef] [usertype] __iomem *addr arch/powerpc/platforms/4xx/gpio.c:106:9: sparse: got restricted __be32 [noderef] __iomem * arch/powerpc/platforms/4xx/gpio.c:110:17: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] __iomem * @@ arch/powerpc/platforms/4xx/gpio.c:110:17: sparse: expected unsigned int volatile [noderef] [usertype] __iomem *addr arch/powerpc/platforms/4xx/gpio.c:110:17: sparse: got restricted __be32 [noderef] __iomem * arch/powerpc/platforms/4xx/gpio.c:110:17: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int const volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] __iomem * @@ arch/powerpc/platforms/4xx/gpio.c:110:17: sparse: expected unsigned int const volatile [noderef] [usertype] __iomem *addr arch/powerpc/platforms/4xx/gpio.c:110:17: sparse: got restricted __be32 [noderef] __iomem * arch/powerpc/platforms/4xx/gpio.c:111:17: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32 [noderef] __iomem * @@ arch/powerpc/platforms/4xx/gpio.c:111:17: sparse: expected unsigned int volatile [noderef] [usertype] __iomem *addr arch/powerpc/platforms/4xx/gpio.c:111:17: sparse: got restricted __be32 [noderef] __iomem * arch/powerpc/platforms/4xx/gpio.c:111:17: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int const volatile [noderef] [usertype] __iomem *addr @@ got restricted __be32
Re: dt-bindings: display: xlnx: mixer: Inconsistent pixel format terminology in dt docs
Hello, On Thu, Aug 20, 2020 at 04:38:18PM -0700, Hyun Kwon wrote: > On Thursday, August 20, 2020 2:18 PM, Kenneth Sloat write: > > Hello, > > > > The Xilinx Video mixer IP uses the DRM fourcc string as a device tree > > binding in > > order to describe the format for a specific DRM layer/plane. Currently, in > > the > > device tree doc in > > "Documentation/devicetree/bindings/dma/xilinx/xilinx_frmbuf.txt" there is a > > list > > called "VIDEO FORMATS" with a table containing "Mixer IP Format" and > > associated "Driver supported Format String" (fourcc). In general, this > > table is not > > helpful, because "Mixer IP Format" does not match the Xilinx IP datasheet > > terminology for formats but rather some other commonly used nomenclature. > > This is also inconsistent from other Xilinx dts binding docs which specify > > the > > actual correct IP name and at times list other format nomenclature where > > helpful (i.e. xilinx_frmbuf.txt) > > > > My suggestion is to remove the current "Mixer IP Format" strings in the doc > > and > > replace them with the actual IP names in the datasheet (which also match > > those > > used in Xilinx's Vivado FPGA tool). Otherwise, the programmer must cross > > reference other dts documentation or the code in order to figure these out. > > I am > > happy to provide a patch for this but wanted to throw out the suggestion > > first. Are you talking about the "Video Format" column in table 2-8 of PG243 ? Those values seem good to me. Documentation/devicetree/bindings/media/xilinx/video.txt also defines a xlnx,video-format property that uses the values from UG934 for the AXI streaming interface. > I agree. The bindings should be in sync with datasheet and not rely on > software definitions. Since the driver is only in Xilinx vendor tree, > please send directly to g...@xilinx.com. -- Regards, Laurent Pinchart
Re: [GIT pull] x86/urgent for v5.9-rc2
On Sun, Aug 23, 2020 at 3:35 PM Linus Torvalds wrote: > > On Sun, Aug 23, 2020 at 3:27 PM Andy Lutomirski wrote: > > > > Every interrupt is going to load the CS and SS descriptor cache lines. > > Yeah, but this isn't even sharing the same GDT cache line. Those two > are at least in the same cacheline, and hey, that is forced upon us by > the architecture, so we don't have any choice. > > But I guess this lsl thing only triggers on the paranoid entry, so > it's just NMI, DB and MCE.. Or? Indeed. And also all the new virt garbage that keeps popping up. --Andy
Re: [PATCH v2 8/8] x86/debug: Remove the historical junk
On Fri, Aug 21, 2020 at 3:21 AM Peter Zijlstra wrote: > > Remove the historical junk and replace it with a WARN and a comment. > > The problem is that even though the kernel only uses TF single-step in > kprobes and KGDB, both of which consume the event before this, > QEMU/KVM has bugs in this area that can trigger this state so we have > to deal with it. Almost acked by me. If you make the change I suggested earlier, then the ->debugreg6 garbage can actually die. --Andy
Re: [PATCH v2 5/8] x86/debug: Simplify #DB signal code
On Fri, Aug 21, 2020 at 3:21 AM Peter Zijlstra wrote: > > Get rid of the two variables, avoid computing si_code when not needed > and be consistent about which dr6 value is used. > > - if (tsk->thread.debugreg6 & (DR_STEP | DR_TRAP_BITS) || user_icebp) > - send_sigtrap(regs, 0, si_code); > + /* > +* If dr6 has no reason to give us about the origin of this trap, > +* then it's very likely the result of an icebp/int01 trap. > +* User wants a sigtrap for that. > +*/ > + if (dr6 & (DR_STEP | DR_TRAP_BITS) || !dr6) > + send_sigtrap(regs, 0, get_si_code(dr6)); The old condition was ... || (actual DR6 value) and the new condition was ... || (stupid notifier-modified DR6 value). I think the old code was more correct. The right fix is to get rid of the notifier garbage. Want to pick up these two changes into your series: https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/entry=b695a5adfdd661a10eead1eebd4002d08400e7ef https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/entry=40ca016606bd39a465feaf5802a8dc3e937aaa06 And then there is no code left that modifies ->debugreg6 out from under you. --Andy
Re: [PATCH] mmc: mmc_spi: fix timeout calculation
Hi Uffe, > This looks good to me, but before applying just wanted to check that > you tested this on some HW, to make sure it doesn't break anything? yes, I should have mentioned that. I tested the change on a custom STM32H743 board with a microSD card connected to one of its SPIs. It does still work just fine with this patch applied. Tobias
[PATCH v8 3/3] mm: cma: use CMA_MAX_NAME to define the length of cma name array
CMA_MAX_NAME should be visible to CMA's users as they might need it to set
the name of CMA areas and avoid hardcoding the size locally.
So this patch moves CMA_MAX_NAME from local header file to include/linux
header file and removes the hardcode in both hugetlb.c and contiguous.c.
Cc: Mike Kravetz
Cc: Roman Gushchin
Cc: Christoph Hellwig
Cc: Marek Szyprowski
Cc: Will Deacon
Cc: Robin Murphy
Cc: Andrew Morton
Signed-off-by: Barry Song
---
this patch is fixing the magic number issue with respect to Will's comment
here:
https://lore.kernel.org/linux-iommu/4ab78767553f48a584217063f6f24...@hisilicon.com/
include/linux/cma.h | 2 ++
kernel/dma/contiguous.c | 2 +-
mm/cma.h| 2 --
mm/hugetlb.c| 4 ++--
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/linux/cma.h b/include/linux/cma.h
index 6ff79fefd01f..217999c8a762 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -18,6 +18,8 @@
#endif
+#define CMA_MAX_NAME 64
+
struct cma;
extern unsigned long totalcma_pages;
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index aa53384fd7dc..f4c150810fd2 100644
--- a/kernel/dma/contiguous.c
+++ b/kernel/dma/contiguous.c
@@ -119,7 +119,7 @@ void __init dma_pernuma_cma_reserve(void)
for_each_online_node(nid) {
int ret;
- char name[20];
+ char name[CMA_MAX_NAME];
struct cma **cma = _contiguous_pernuma_area[nid];
snprintf(name, sizeof(name), "pernuma%d", nid);
diff --git a/mm/cma.h b/mm/cma.h
index 20f6e24bc477..42ae082cb067 100644
--- a/mm/cma.h
+++ b/mm/cma.h
@@ -4,8 +4,6 @@
#include
-#define CMA_MAX_NAME 64
-
struct cma {
unsigned long base_pfn;
unsigned long count;
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index a301c2d672bf..9eec0ea9ba68 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -5683,12 +5683,12 @@ void __init hugetlb_cma_reserve(int order)
reserved = 0;
for_each_node_state(nid, N_ONLINE) {
int res;
- char name[20];
+ char name[CMA_MAX_NAME];
size = min(per_node, hugetlb_cma_size - reserved);
size = round_up(size, PAGE_SIZE << order);
- snprintf(name, 20, "hugetlb%d", nid);
+ snprintf(name, sizeof(name), "hugetlb%d", nid);
res = cma_declare_contiguous_nid(0, size, 0, PAGE_SIZE << order,
0, false, name,
_cma[nid], nid);
--
2.27.0
