Re: [RFC PATCH 01/10] DT bindings in plain text format
On Sun, 21 Jun 2020, Jonathan Neuschäfer wrote: > For reference, here are the devicetree bindings in plaintext format. > (Not for merge.) This would be better placed inside the relevant patch(es), rather than in a separate non-mergeable extra/superfluous patch. > Signed-off-by: Jonathan Neuschäfer > --- > .../bindings/mfd/netronix,ntxec.txt | 58 +++ > .../bindings/pwm/netronix,ntxec-pwm.txt | 27 + > .../bindings/rtc/netronix,ntxec-rtc.txt | 17 ++ > 3 files changed, 102 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/netronix,ntxec.txt > create mode 100644 > Documentation/devicetree/bindings/pwm/netronix,ntxec-pwm.txt > create mode 100644 > Documentation/devicetree/bindings/rtc/netronix,ntxec-rtc.txt -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 7/7] arm64: dts: mt8183: Add krane-sku176 board
On 19/06/2020 12:27, Enric Balletbo i Serra wrote:
> Also known as the Lenovo IdeaPad Duet Chromebook.
>
> There are different krane boards with shared resources, hence a
> mt8183-kukui-krane.dtsi was created for easily introduce future new
> boards. The same happens with the baseboard codenamed kukui where
> different variants, apart from kukui variant can take advantage of the
> shared resources.
>
> Signed-off-by: Ben Ho
> [originally created by Ben Ho but adapted and ported to mainline]
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> arch/arm64/boot/dts/mediatek/Makefile | 1 +
> .../mediatek/mt8183-kukui-krane-sku176.dts| 18 +
> .../boot/dts/mediatek/mt8183-kukui-krane.dtsi | 343
> .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 788 ++
> arch/arm64/boot/dts/mediatek/mt8183.dtsi | 1 +
> 5 files changed, 1151 insertions(+)
> create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-krane-sku176.dts
> create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi
> create mode 100644 arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
>
[...]
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> new file mode 100644
> index 0..f0a070535b340
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
[...]
> +
> + max98357a: codec0 {
> + compatible = "maxim,max98357a";
> + sdmode-gpios = <&pio 175 0>;
> + };
> +
> + btsco: codec1 {
bt_sco_codec:
is more clear, I think.
> + compatible = "linux,bt-sco";
> + };
> +
> + wifi_pwrseq: wifi-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + pinctrl-names = "default";
> + pinctrl-0 = <&wifi_pins_pwrseq>;
> +
> + /* Toggle WIFI_ENABLE to reset the chip. */
> + reset-gpios = <&pio 119 1>;
> + };
> +
[...]> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index a1576f1b5a447..689bce13e0165 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -719,6 +719,7 @@ u3phy: usb-phy@11f4 {
> compatible = "mediatek,mt8183-tphy",
>"mediatek,generic-tphy-v2";
> #address-cells = <1>;
> + #phy-cells = <1>;
Wrong patch?
> #size-cells = <1>;
> ranges = <0 0 0x11f4 0x1000>;
> status = "okay";
>
Regards,
Matthias
Re: [PATCH v13 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP
On Sun, Jun 21, 2020 at 10:09:25AM +0200, Sam Ravnborg wrote:
> Hi Xin.
>
>
> On Tue, Jun 09, 2020 at 03:19:50PM +0800, Xin Ji wrote:
> > The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> > for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.
> >
> > Signed-off-by: Xin Ji
>
> The bridge driver now implements the bridge functions for get_edid +
> detect which is good.
> But the bridge driver also needs to check the flags argument
> of anx7625_bridge_attach() so the connector creation is optional.
> This is required to prepare the bridge driver to fully support a
> chain of bridges and is mandatory for new bridge drivers.
>
> Futhermore the bridge driver needs to be converted to use the bridge
> panel. See what other bridge drivers do.
> In short - the drm_panel shall be replaced by a bridge in your
> platform data structure.
> Usual this end up in less code after the conversion.
>
> Sam
>
Hi Sam, thanks for your comments.
1. I'll add flags argument check in anx7625_bridge_attach().
2. Do you mean panel bridge, related interface is
"devm_drm_panel_bridge_add(...)"? If it is, do I still need call
drm_panel_prepare()/drm_panel_unprepare() to enable/disable panel power?
Thanks,
Xin
> > ---
> > drivers/gpu/drm/bridge/analogix/Kconfig |9 +
> > drivers/gpu/drm/bridge/analogix/Makefile |1 +
> > drivers/gpu/drm/bridge/analogix/anx7625.c | 1999
> > +
> > drivers/gpu/drm/bridge/analogix/anx7625.h | 397 ++
> > 4 files changed, 2406 insertions(+)
> > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
> > create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig
> > b/drivers/gpu/drm/bridge/analogix/Kconfig
> > index e1fa7d8..024ea2a 100644
> > --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> > +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> > @@ -25,3 +25,12 @@ config DRM_ANALOGIX_ANX78XX
> > config DRM_ANALOGIX_DP
> > tristate
> > depends on DRM
> > +
> > +config DRM_ANALOGIX_ANX7625
> > + tristate "Analogix Anx7625 MIPI to DP interface support"
> > + depends on DRM
> > + depends on OF
> > + help
> > + ANX7625 is an ultra-low power 4K mobile HD transmitter
> > + designed for portable devices. It converts MIPI/DPI to
> > + DisplayPort1.3 4K.
> > diff --git a/drivers/gpu/drm/bridge/analogix/Makefile
> > b/drivers/gpu/drm/bridge/analogix/Makefile
> > index 97669b3..44da392 100644
> > --- a/drivers/gpu/drm/bridge/analogix/Makefile
> > +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> > @@ -1,5 +1,6 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
> > analogix-i2c-dptx.o
> > obj-$(CONFIG_DRM_ANALOGIX_ANX6345) += analogix-anx6345.o
> > +obj-$(CONFIG_DRM_ANALOGIX_ANX7625) += anx7625.o
> > obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
> > obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
> > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > new file mode 100644
> > index 000..db37f68
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > @@ -0,0 +1,1999 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright(c) 2020, Analogix Semiconductor. All rights reserved.
> > + *
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +#include "anx7625.h"
> > +
> > +/*
> > + * There is a sync issue while access I2C register between AP(CPU) and
> > + * internal firmware(OCM), to avoid the race condition, AP should access
> > + * the reserved slave address before slave address occurs changes.
> > + */
> > +static int i2c_access_workaround(struct anx7625_data *ctx,
> > +struct i2c_client *client)
> > +{
> > + u8 offset;
> > + struct device *dev = &client->dev;
> > + int ret;
> > +
> > + if (client == ctx->last_client)
> > + return 0;
> > +
> > + ctx->last_client = client;
> > +
> > + if (client == ctx->i2c.tcpc_client)
> > + offset = RSVD_00_ADDR;
> > + else if (client == ctx->i2c.tx_p0_client)
> > + offset = RSVD_D1_ADDR;
> > + else if (client == ctx->i2c.tx_p1_client)
> > + offset = RSVD_60_ADDR;
> > + else if (client == ctx->i2c.rx_p0_client)
> > + offset = RSVD_39_ADDR;
> > + else if (client == ctx->i2c.rx_p1_client)
> > + offset = RSVD_7F_ADDR;
> > + else
> > + offset = RSVD_00_ADDR;
> > +
> > + ret = i2c_smbus_write_byte_data(client, offset, 0x00);
> > + if (ret < 0)
> > + DRM_DEV_ERROR(dev,
>
arch/mips/sgi-ip27/ip27-init.c:123:2: error: implicit declaration of function 'register_smp_ops'
Hi Thomas,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 625d3449788f85569096780592549d0340e9c0c7
commit: c823f416097879515a02f3d97aecc1204ffc0773 MIPS: SGI-IP27: move
registering of smp ops into IP27 specific code
date: 8 months ago
config: mips-randconfig-r021-20200622 (attached as .config)
compiler: mips64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout c823f416097879515a02f3d97aecc1204ffc0773
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
arch/mips/sgi-ip27/ip27-init.c:118:13: warning: no previous prototype for
'plat_mem_setup' [-Wmissing-prototypes]
118 | void __init plat_mem_setup(void)
| ^~
arch/mips/sgi-ip27/ip27-init.c: In function 'plat_mem_setup':
>> arch/mips/sgi-ip27/ip27-init.c:123:2: error: implicit declaration of
>> function 'register_smp_ops' [-Werror=implicit-function-declaration]
123 | register_smp_ops(&ip27_smp_ops);
| ^~~~
cc1: some warnings being treated as errors
vim +/register_smp_ops +123 arch/mips/sgi-ip27/ip27-init.c
117
118 void __init plat_mem_setup(void)
119 {
120 u64 p, e, n_mode;
121 nasid_t nid;
122
> 123 register_smp_ops(&ip27_smp_ops);
---
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] dt-bindings: backlight: Convert common backlight bindings to DT schema
On Fri, Jun 19, 2020 at 11:53:41PM +0200, Sam Ravnborg wrote: > Good to have these converted. A few comments in the following. One > comment is for the backlight people as you copied the original text. ... and I've sliced out everything except that in this reply. > On Thu, Jun 18, 2020 at 04:44:13PM -0600, Rob Herring wrote: > > diff --git > > a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml > > b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml > > new file mode 100644 > > index ..ae50945d2798 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml > > @@ -0,0 +1,58 @@ > > ... > > + > > + default-brightness-level: > > +description: The default brightness level (index into the array defined > > + by the "brightness-levels" property). > > This description does not match my understading. > The description says "index into", but in reality this is a value that > matches somewhere in the range specified by brightness-levels. > So it is not an index. > > Maybe I just read it wrong and the description is fine. But when I read > index the when it says 6 I would look for brightness-levels[6] equals > 128 in the example below. When the brightness-levels array is not present then backlight brightness and led brightness have a 1:1 mapping. In this case the meaning of "default brightness level" is (hopefully) obvious and the parenthetic text does not apply. When the array is present then we have two different scales of brightness and it is important to describe which scale we use for the default brightness. The language about "index into" was adopted to avoid having to introduce extra terminology whilst making it clear that setting the default brightness-level to 128 is invalid (because it is not an acceptable index) and that a value of 6 will result in the LED brightness being set to 128. > And this is not how it is coded. That had me worried for a moment but I think the code and bindings are in agreement. There is some code to map the LED scale (128) to the backlight scale (6) but this used to ensure we supply the correct brightness level to user space when an active backlight is handed over from bootloader to kernel. If a default-brightness-level is provided then the above logic is overridden and the value read from the DT gets placed directly into props.brightness where it will act as in index into the brightness table. Daniel.
[PATCH stable-4.19.y] Revert "dpaa_eth: fix usage as DSA master, try 3"
From: Vladimir Oltean
This reverts commit b145710b69388aa4034d32b4a937f18f66b5538e.
The patch is not wrong, but the Fixes: tag is. It should have been:
Fixes: 060ad66f9795 ("dpaa_eth: change DMA device")
which means that it's fixing a commit which was introduced in:
git describe --tags 060ad66f97954
v5.4-rc3-783-g060ad66f9795
which then means it should have not been backported to linux-4.19.y,
where things _were_ working and now they're not.
Reported-by: Joakim Tjernlund
Signed-off-by: Vladimir Oltean
---
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
index 6683409fbd4a..4b21ae27a9fd 100644
--- a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
+++ b/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
@@ -2796,7 +2796,7 @@ static int dpaa_eth_probe(struct platform_device *pdev)
}
/* Do this here, so we can be verbose early */
- SET_NETDEV_DEV(net_dev, dev->parent);
+ SET_NETDEV_DEV(net_dev, dev);
dev_set_drvdata(dev, net_dev);
priv = netdev_priv(net_dev);
--
2.25.1
Re: [PATCH RFC v8 02/11] vhost: use batched get_vq_desc version
On Mon, Jun 22, 2020 at 11:07 AM Jason Wang wrote: > > > On 2020/6/20 上午2:07, Eugenio Perez Martin wrote: > > On Mon, Jun 15, 2020 at 2:28 PM Eugenio Perez Martin > > wrote: > >> On Thu, Jun 11, 2020 at 5:22 PM Konrad Rzeszutek Wilk > >> wrote: > >>> On Thu, Jun 11, 2020 at 07:34:19AM -0400, Michael S. Tsirkin wrote: > As testing shows no performance change, switch to that now. > >>> What kind of testing? 100GiB? Low latency? > >>> > >> Hi Konrad. > >> > >> I tested this version of the patch: > >> https://lkml.org/lkml/2019/10/13/42 > >> > >> It was tested for throughput with DPDK's testpmd (as described in > >> http://doc.dpdk.org/guides/howto/virtio_user_as_exceptional_path.html) > >> and kernel pktgen. No latency tests were performed by me. Maybe it is > >> interesting to perform a latency test or just a different set of tests > >> over a recent version. > >> > >> Thanks! > > I have repeated the tests with v9, and results are a little bit different: > > * If I test opening it with testpmd, I see no change between versions > > * If I forward packets between two vhost-net interfaces in the guest > > using a linux bridge in the host: > >- netperf UDP_STREAM shows a performance increase of 1.8, almost > > doubling performance. This gets lower as frame size increase. > >- rests of the test goes noticeably worse: UDP_RR goes from ~6347 > > transactions/sec to 5830 > >- TCP_STREAM goes from ~10.7 gbps to ~7Gbps > > > Which direction did you mean here? Guest TX or RX? Hi Jason. For both I created a linux bridge in the host, attach two guest interfaces with vhost-net, and make the netperf run on them. > > > >- TCP_RR from 6223.64 transactions/sec to 5739.44 > > > Perf diff might help. I think we can start from the RR result which > should be easier. Maybe you can test it for each patch then you may see > which patch is the source of the regression. > Ok, I will look for differences. Thanks! > Thanks >
Re: [PATCH v3 1/2] media: tpg: Add function to return colors' order of test image
On 18/06/2020 21:05, Kaaira Gupta wrote:
> Currently there is no method to know the correct order of the colors for
> a test image generated by tpg. Write a function that returns a string of
> colors' order given a tpg. It returns a NULL pointer in case of test
> patterns which do not have a well defined colors' order. Hence add a
> NULL check for text in tpg_gen_text().
>
> Signed-off-by: Kaaira Gupta
> Reviewed-by: Kieran Bingham
> ---
> drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 32 +--
> include/media/tpg/v4l2-tpg.h | 1 +
> 2 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> index 50f1e0b28b25..31e6044a4104 100644
> --- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> +++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> @@ -1959,12 +1959,14 @@ void tpg_gen_text(const struct tpg_data *tpg, u8
> *basep[TPG_MAX_PLANES][2],
> unsigned step = V4L2_FIELD_HAS_T_OR_B(tpg->field) ? 2 : 1;
> unsigned div = step;
> unsigned first = 0;
> - unsigned len = strlen(text);
> + unsigned len;
> unsigned p;
>
> - if (font8x16 == NULL || basep == NULL)
> + if (font8x16 == NULL || basep == NULL || text == NULL)
> return;
>
> + len = strlen(text);
> +
> /* Checks if it is possible to show string */
> if (y + 16 >= tpg->compose.height || x + 8 >= tpg->compose.width)
> return;
> @@ -2006,6 +2008,32 @@ void tpg_gen_text(const struct tpg_data *tpg, u8
> *basep[TPG_MAX_PLANES][2],
> }
> EXPORT_SYMBOL_GPL(tpg_gen_text);
>
> +char *tpg_g_color_order(const struct tpg_data *tpg)
This returns a const char *.
> +{
> + #define COLORBAR(order) #order "white, yellow, cyan, green, magenta,
> red, blue, black"
> +
> + switch (tpg->pattern) {
> + case TPG_PAT_75_COLORBAR:
> + case TPG_PAT_100_COLORBAR:
> + case TPG_PAT_CSC_COLORBAR:
> + return COLORBAR(Left to right:);
> + case TPG_PAT_100_HCOLORBAR:
Just combine this with the other and just return the sequence:
return "White, Yellow, Cyan, Green, Magenta, Red, Blue, Black";
It's obvious from the pattern that three are from left to right and one is from
top to bottom. No need to mention that here.
Regards,
Hans
> + return COLORBAR(Top to bottom:);
> + case TPG_PAT_BLACK:
> + return "Black";
> + case TPG_PAT_WHITE:
> + return "White";
> + case TPG_PAT_RED:
> + return "Red";
> + case TPG_PAT_GREEN:
> + return "Green";
> + case TPG_PAT_BLUE:
> + return "Blue";
> + default:
> + return NULL;
> + }
> +}
> +
> void tpg_update_mv_step(struct tpg_data *tpg)
> {
> int factor = tpg->mv_hor_mode > TPG_MOVE_NONE ? -1 : 1;
> diff --git a/include/media/tpg/v4l2-tpg.h b/include/media/tpg/v4l2-tpg.h
> index eb191e85d363..4f79cac87b85 100644
> --- a/include/media/tpg/v4l2-tpg.h
> +++ b/include/media/tpg/v4l2-tpg.h
> @@ -252,6 +252,7 @@ void tpg_fillbuffer(struct tpg_data *tpg, v4l2_std_id std,
> bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc);
> void tpg_s_crop_compose(struct tpg_data *tpg, const struct v4l2_rect *crop,
> const struct v4l2_rect *compose);
> +char *tpg_g_color_order(const struct tpg_data *tpg);
>
> static inline void tpg_s_pattern(struct tpg_data *tpg, enum tpg_pattern
> pattern)
> {
>
Re: [PATCH v2 3/6] spi: dw: Add Microchip Sparx5 support
Mark Brown writes:
On Fri, Jun 19, 2020 at 01:31:18PM +0200, Lars Povlsen wrote:
>> +/*
>> + * The Designware SPI controller (referred to as master in the
>> + * documentation) automatically deasserts chip select when the tx fifo
>> + * is empty. The chip selects then needs to be driven by a CS override
>> + * register. enable is an active low signal.
>> + */
>> +static void dw_spi_sparx5_set_cs(struct spi_device *spi, bool nEnable)
>
>The value that is passed in here is the value that should be driven on
>the output pin, the driver should not be interpreting the value in any
>way here. Documenting it as nEnable adds a layer of confusion, and it
>may not be an active high signal depending on the system.
Ok, I will make the CS function more like the others.
>
>> +if (!nEnable) {
>> +/* Ensure CS toggles, so start off all disabled */
>> +regmap_write(dwsmscc->syscon, SPARX5_FORCE_VAL, ~0);
>> +/* CS override drive enable */
>> +regmap_write(dwsmscc->syscon, SPARX5_FORCE_ENA, 1);
>
>This should just be setting the value to whatever the core asked for it
>to be set to, the driver adding extra toggles is likely to disrupt
>things.
I will have a look at this again. But it was added for a reason. The
issue is that we have two different busses in front of the controller,
so we might need more settle time when switching interface.
Thank you for you comments,
Cheers
--
Lars Povlsen,
Microchip
Re: [PATCH v3] driver core: platform: expose numa_node to users in sysfs
On 19/06/2020 04:00, Barry Song wrote: Some platform devices like ARM SMMU are memory-mapped and populated by ACPI/IORT. In this case, NUMA topology of those platform devices are exported by firmware as well. Software might care about the numa_node of those devices in order to achieve NUMA locality. Is it generally the case that the SMMU will be in the same NUMA node as the endpoint device (which you're driving)? If so, we can get this info from sysfs already for the endpoint, and also have a link from the endpoint to the iommu for pci devices (which I assume you're interested in): root@(none)$ ls -l /sys/devices/pci:74/:74:02.0/ | grep iommu lrwxrwxrwx 1 root root 0 Jun 22 10:33 iommu -> ../../platform/arm-smmu-v3.2.auto/iommu/smmu3.0x00014000 lrwxrwxrwx 1 root root 0 Jun 22 10:33 iommu_group -> ../../../kernel/iommu_groups/0 root@(none)$ Thanks, John
Re: [PATCH v7 01/13] tools/libperf: introduce notion of static polled file descriptors
On 22.06.2020 13:21, Jiri Olsa wrote: > On Mon, Jun 22, 2020 at 12:47:19PM +0300, Alexey Budankov wrote: > > SNIP > fdarray__del(array, fdkey); >>> >>> I think there's solution without having filterable type, >>> I'm not sure why you think this is needed >>> >>> I'm busy with other things this week, but I think I can >>> come up with some patch early next week if needed >> >> Friendly reminder. > > hm? I believe we discussed this in here: > https://lore.kernel.org/lkml/20200609145611.GI1558310@krava/ Do you want it to be implemented like in the patch posted by the link? >>> >>> no idea.. looking for good solution ;-) >>> >>> how about switching completely to epoll? I tried and it >>> does not look that bad >> >> Well, epoll() is perhaps possible but why does it want switching to epoll()? >> What are the benefits and/or specific task being solved by this switch? > > epoll change fixes the same issues as the patch you took in v8 > > on top of it it's not a hack and wil make polling more user > friendly because of the clear interface Clear. The opposite thing is /proc/sys/fs/epoll/max_user_watches limit that will affect Perf tool usage additionally to the current process limit on a number of simultaneously open file descriptors (ulimit -n). So move to epoll() will impose one limit what can affect Perf tool scalability. > >> >>> >>> there might be some loose ends (interface change), but >>> I think this would solve our problems with fdarray >> >> Your first patch accomodated in v8 actually avoids fds typing >> and solves pos (=fdarray__add()) staleness issue with fdarray. > > yea, it was a change meant for discussion (which never happened), > and I considered it to be more a hack than a solution > > I suppose we can live with that for a while, but I'd like to > have clean solution for polling as well I wouldn't treat it as a hack but more as a fix because returned pos is now a part of interface that can be safely used in callers. Can we go with this fix for the patch set? Thanks, Alexey
[PATCH] mm/zswap: careful error path implementation in comp_prepare
Free the allocated memory and resource while an error occurs.
Cc: Herbert Xu
Cc: David S. Miller"
Cc: Seth Jennings
Cc: Dan Streetman
Cc: Vitaly Wool
Cc: Andrew Morton
Signed-off-by: Barry Song
---
-v1: an incremental patch againest linux-next to fix the issue pointed
out by Vitaly
mm/zswap.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/mm/zswap.c b/mm/zswap.c
index 0d914ba6b4a0..c0a85ef46610 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -428,28 +428,31 @@ static int zswap_cpu_comp_prepare(unsigned int cpu,
struct hlist_node *node)
struct crypto_acomp *acomp;
struct acomp_req *req;
struct crypto_acomp_ctx *acomp_ctx;
+ int ret;
if (WARN_ON(*per_cpu_ptr(pool->acomp_ctx, cpu)))
return 0;
acomp_ctx = kzalloc(sizeof(*acomp_ctx), GFP_KERNEL);
- if (IS_ERR_OR_NULL(acomp_ctx)) {
- pr_err("Could not initialize acomp_ctx\n");
+ if (!acomp_ctx) {
+ pr_err("Could not allocate acomp_ctx\n");
return -ENOMEM;
}
acomp = crypto_alloc_acomp(pool->tfm_name, 0, 0);
- if (IS_ERR_OR_NULL(acomp)) {
+ if (IS_ERR(acomp)) {
pr_err("could not alloc crypto acomp %s : %ld\n",
pool->tfm_name, PTR_ERR(acomp));
- return -ENOMEM;
+ ret = PTR_ERR(acomp);
+ goto free_ctx;
}
acomp_ctx->acomp = acomp;
req = acomp_request_alloc(acomp_ctx->acomp);
- if (IS_ERR_OR_NULL(req)) {
- pr_err("could not alloc crypto acomp %s : %ld\n",
- pool->tfm_name, PTR_ERR(acomp));
- return -ENOMEM;
+ if (!req) {
+ pr_err("could not alloc crypto acomp_request %s\n",
+ pool->tfm_name);
+ ret = -ENOMEM;
+ goto free_acomp;
}
acomp_ctx->req = req;
@@ -462,6 +465,12 @@ static int zswap_cpu_comp_prepare(unsigned int cpu, struct
hlist_node *node)
*per_cpu_ptr(pool->acomp_ctx, cpu) = acomp_ctx;
return 0;
+
+free_acomp:
+ crypto_free_acomp(acomp_ctx->acomp);
+free_ctx:
+ kfree(acomp_ctx);
+ return ret;
}
static int zswap_cpu_comp_dead(unsigned int cpu, struct hlist_node *node)
--
2.27.0
Congratulation!
Congratulation! Your Email Address was selected as a winner of £2000,000.00 on Euro-Mega DRAW
Re: [RFC PATCH 04/10] mfd: Add base driver for Netronix embedded controller
On Sun, 21 Jun 2020, Jonathan Neuschäfer wrote:
Description of the device here please.
> Third-party hardware documentation is available at
'\n'
> https://github.com/neuschaefer/linux/wiki/Netronix-MSP430-embedded-controller
Indent this with a couple of spaces.
> The EC supports interrupts, but the driver doesn't make use of them so
> far.
>
> Known problems:
> - The reboot handler is installed in such a way that it directly calls
> into the i2c subsystem to send the reboot command to the EC. This
> means that the reboot handler may sleep, which is not allowed.
>
> Signed-off-by: Jonathan Neuschäfer
> ---
> drivers/mfd/Kconfig | 7 ++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/ntxec.c | 188 ++
> include/linux/mfd/ntxec.h | 30 ++
> 4 files changed, 226 insertions(+)
> create mode 100644 drivers/mfd/ntxec.c
> create mode 100644 include/linux/mfd/ntxec.h
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index a37d7d1713820..78410b928648e 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -978,6 +978,13 @@ config MFD_VIPERBOARD
> You need to select the mfd cell drivers separately.
> The drivers do not support all features the board exposes.
>
> +config MFD_NTXEC
> + bool "Netronix Embedded Controller"
> + depends on I2C && OF
> + help
> + Say yes here if you want to support the embedded controller of
> + certain e-book readers designed by the ODM Netronix.
s/of certain/found in certain/.
> config MFD_RETU
> tristate "Nokia Retu and Tahvo multi-function device"
> select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 9367a92f795a6..19d9391ed6f32 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -218,6 +218,7 @@ obj-$(CONFIG_MFD_INTEL_MSIC) += intel_msic.o
> obj-$(CONFIG_MFD_INTEL_PMC_BXT) += intel_pmc_bxt.o
> obj-$(CONFIG_MFD_PALMAS) += palmas.o
> obj-$(CONFIG_MFD_VIPERBOARD)+= viperboard.o
> +obj-$(CONFIG_MFD_NTXEC) += ntxec.o
> obj-$(CONFIG_MFD_RC5T583)+= rc5t583.o rc5t583-irq.o
> obj-$(CONFIG_MFD_RK808) += rk808.o
> obj-$(CONFIG_MFD_RN5T618)+= rn5t618.o
> diff --git a/drivers/mfd/ntxec.c b/drivers/mfd/ntxec.c
> new file mode 100644
> index 0..82adea34ea746
> --- /dev/null
> +++ b/drivers/mfd/ntxec.c
> @@ -0,0 +1,188 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +// Copyright 2020 Jonathan Neuschäfer
> +//
> +// MFD driver for the usually MSP430-based embedded controller used in
> certain
> +// Netronix ebook reader board designs
Only the SPDX line should contain C++ style comments.
Description at the top, copyright after.
An "MFD driver" isn't really a thing. Please describe the device.
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +
No need for double line spacing.
> +#define NTXEC_VERSION0x00
> +#define NTXEC_POWEROFF 0x50
> +#define NTXEC_POWERKEEP 0x70
> +#define NTXEC_RESET 0x90
Are these registers? Might be worth pre/post-fixing with _REG.
> +/* Register access */
> +
> +int ntxec_read16(struct ntxec *ec, u8 addr)
> +{
> + u8 request[1] = { addr };
> + u8 response[2];
> + int res;
> +
> + struct i2c_msg msgs[] = {
> + {
> + .addr = ec->client->addr,
> + .flags = ec->client->flags,
> + .len = sizeof(request),
> + .buf = request
> + }, {
> + .addr = ec->client->addr,
> + .flags = ec->client->flags | I2C_M_RD,
> + .len = sizeof(response),
> + .buf = response
> + }
> + };
> +
> + res = i2c_transfer(ec->client->adapter, msgs, ARRAY_SIZE(msgs));
> + if (res < 0)
> + return res;
> + if (res != ARRAY_SIZE(msgs))
> + return -EIO;
> +
> + return get_unaligned_be16(response);
> +}
> +EXPORT_SYMBOL(ntxec_read16);
> +
> +int ntxec_write16(struct ntxec *ec, u8 addr, u16 value)
> +{
> + u8 request[3] = { addr, };
> + int res;
> +
> + put_unaligned_be16(value, request + 1);
> +
> + res = i2c_transfer_buffer_flags(ec->client, request, sizeof(request),
> + ec->client->flags);
> + if (res < 0)
> + return res;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(ntxec_write16);
> +
> +int ntxec_read8(struct ntxec *ec, u8 addr)
> +{
> + int res = ntxec_read16(ec, addr);
> +
> + if (res < 0)
> + return res;
> +
> + return (res >> 8) & 0xff;
> +}
> +EXPORT_SYMBOL(ntxec_read8);
> +
> +int ntxec_write8(struct ntxec *ec, u8 addr, u8 value)
> +{
> + return ntxec_write16(ec, addr, value << 8);
> +}
> +EXPORT_SYMBOL(ntxec_write8);
Why are you hand-rolling your own accessors?
Re: [PATCH 0/6] Add Microchip MCP25XXFD CAN driver
On 6/22/20 12:25 PM, Kurt Van Dijck wrote: > I got my board up with a 5.7, despite device-tree problems completely > unrelated to CAN. \o/ > It seems to work well with a fully-loaded CAN bus (cangen -g0 ...). > So that is a real improvement. Can I add your Tested-by? > I will need to add the listen-only mode soon. Patches are always welcome! regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH v3 2/2] media: vimc: Add a control to display info on test image
On 18/06/2020 21:05, Kaaira Gupta wrote:
> Add a control in VIMC to display information such as the correct oder of
odor -> order
> colors for a given test pattern, brightness, hue, saturation, contrast
> and, width and height at sensor over test image; and display that
> information.
and, width -> and width
'; and display that information': just drop this since you already mentioned
that in 'a control in VIMC to display information'.
It is also useful to show the sequence counter (i.e. the sequence field in
struct v4l2_buffer) since this always changes for every frame.
Perhaps base VIMC_CID_SHOW_INFO on VIVID_CID_OSD_TEXT_MODE?
Doing this as a menu control allows you to add other combinations in the future.
>
> Signed-off-by: Kaaira Gupta
> ---
> drivers/media/test-drivers/vimc/Kconfig | 2 +
> drivers/media/test-drivers/vimc/vimc-common.h | 1 +
> drivers/media/test-drivers/vimc/vimc-sensor.c | 47 ++-
> 3 files changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/test-drivers/vimc/Kconfig
> b/drivers/media/test-drivers/vimc/Kconfig
> index 4068a67585f9..da4b2ad6e40c 100644
> --- a/drivers/media/test-drivers/vimc/Kconfig
> +++ b/drivers/media/test-drivers/vimc/Kconfig
> @@ -2,6 +2,8 @@
> config VIDEO_VIMC
> tristate "Virtual Media Controller Driver (VIMC)"
> depends on VIDEO_DEV && VIDEO_V4L2
> + select FONT_SUPPORT
> + select FONT_8x16
> select MEDIA_CONTROLLER
> select VIDEO_V4L2_SUBDEV_API
> select VIDEOBUF2_VMALLOC
> diff --git a/drivers/media/test-drivers/vimc/vimc-common.h
> b/drivers/media/test-drivers/vimc/vimc-common.h
> index ae163dec2459..afda52253402 100644
> --- a/drivers/media/test-drivers/vimc/vimc-common.h
> +++ b/drivers/media/test-drivers/vimc/vimc-common.h
> @@ -20,6 +20,7 @@
> #define VIMC_CID_VIMC_CLASS (0x00f0 | 1)
> #define VIMC_CID_TEST_PATTERN(VIMC_CID_VIMC_BASE + 0)
> #define VIMC_CID_MEAN_WIN_SIZE (VIMC_CID_VIMC_BASE + 1)
> +#define VIMC_CID_SHOW_INFO (VIMC_CID_VIMC_BASE + 2)
>
> #define VIMC_FRAME_MAX_WIDTH 4096
> #define VIMC_FRAME_MAX_HEIGHT 2160
> diff --git a/drivers/media/test-drivers/vimc/vimc-sensor.c
> b/drivers/media/test-drivers/vimc/vimc-sensor.c
> index a2f09ac9a360..f5352b115aac 100644
> --- a/drivers/media/test-drivers/vimc/vimc-sensor.c
> +++ b/drivers/media/test-drivers/vimc/vimc-sensor.c
> @@ -5,6 +5,7 @@
> * Copyright (C) 2015-2017 Helen Koike
> */
>
> +#include
> #include
> #include
> #include
> @@ -19,6 +20,7 @@ struct vimc_sen_device {
> struct v4l2_subdev sd;
> struct tpg_data tpg;
> u8 *frame;
> + bool show_info;
> /* The active format */
> struct v4l2_mbus_framefmt mbus_format;
> struct v4l2_ctrl_handler hdl;
> @@ -185,10 +187,29 @@ static const struct v4l2_subdev_pad_ops
> vimc_sen_pad_ops = {
> static void *vimc_sen_process_frame(struct vimc_ent_device *ved,
> const void *sink_frame)
> {
> + u8 *basep[TPG_MAX_PLANES][2];
> + char *order;
> + char str[100];
> + int line = 1;
> struct vimc_sen_device *vsen = container_of(ved, struct vimc_sen_device,
> ved);
> -
> tpg_fill_plane_buffer(&vsen->tpg, 0, 0, vsen->frame);
> + if (vsen->show_info) {
> + tpg_calc_text_basep(&vsen->tpg, basep, 0, vsen->frame);
> + order = tpg_g_color_order(&vsen->tpg);
> + tpg_gen_text(&vsen->tpg, basep, line++ * 16, 16, order);
> + snprintf(str, sizeof(str), " brightness %3d, contrast %3d,
> saturation %3d, hue %d ",
The previous tpg_gen_text doesn't have a leading space, but this and the next
line
does. That should be consistent.
I can't quite remember why I added spaces before/after the text in the vivid
implementation.
I think it was because it looked weird without a space, probably because the
text color was
identical to the first colorbar in some of the patterns, making it hard to read
in some
cases.
> + vsen->tpg.brightness,
> + vsen->tpg.contrast,
> + vsen->tpg.saturation,
> + vsen->tpg.hue);
> + tpg_gen_text(&vsen->tpg, basep, line++ * 16, 16, str);
> +
> + snprintf(str, sizeof(str), " sensor size: %dx%d",
> + vsen->mbus_format.width, vsen->mbus_format.height);
> + tpg_gen_text(&vsen->tpg, basep, line++ * 16, 16, str);
> + }
> +
> return vsen->frame;
> }
>
> @@ -200,6 +221,14 @@ static int vimc_sen_s_stream(struct v4l2_subdev *sd, int
> enable)
> if (enable) {
> const struct vimc_pix_map *vpix;
> unsigned int frame_size;
> + const struct font_desc *font = find_font("VGA8x16");
> +
> + if (font == NULL) {
> + pr_err("vimc: could not find font\n");
> +
Re: selftests: kvm: Test results on x86_64
Naresh Kamboju writes: > FYI, > Linaro test farm selftests kvm test cases results. > * kvm_mmio_warning_test — SKIP > * kvm_svm_vmcall_test — SKIP > * kvm_clear_dirty_log_test — PASS > * kvm_cr4_cpuid_sync_test — PASS > * kvm_debug_regs — PASS > * kvm_demand_paging_test — PASS > * kvm_dirty_log_test — PASS > * kvm_evmcs_test — PASS > * kvm_hyperv_cpuid — PASS > * kvm_ * kvm_create_max_vcpus — PASS > * kvm_platform_info_test — PASS > * kvm_set_memory_region_test — PASS > * kvm_set_sregs_test — PASS > * kvm_smm_test — PASS > * kvm_state_test — PASS > * kvm_steal_time — PASS > * kvm_sync_regs_test — PASS > * kvm_vmx_close_while_nested_test — PASS > * kvm_vmx_dirty_log_test — PASS > * kvm_vmx_preemption_timer_test — PASS > * kvm_vmx_set_nested_state_test — PASS > * kvm_vmx_tsc_adjust_test — PASS > * kvm_xss_msr_test — PASS [...] Thanks you! It would be great to see which particular commit was tested here and how often you run these tests in general, which git/branch you follow. Also, you can improve your subject line by adding [PASS] or [FAIL] so we can see if there's a problem to deal with. -- Vitaly
Re: [PATCH v1 02/11] soc: mediatek: cmdq: add assign function
On 21/06/2020 16:18, Dennis YC Hsieh wrote:
> Add assign function in cmdq helper which assign constant value into
> internal register by index.
>
> Signed-off-by: Dennis YC Hsieh
Applied to v5.8-next/soc
Thanks
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 24 +++-
> include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
> include/linux/soc/mediatek/mtk-cmdq.h| 14 ++
> 3 files changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 98f23ba3ba47..bf32e3b2ca6c 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -12,6 +12,7 @@
> #define CMDQ_WRITE_ENABLE_MASK BIT(0)
> #define CMDQ_POLL_ENABLE_MASKBIT(0)
> #define CMDQ_EOC_IRQ_EN BIT(0)
> +#define CMDQ_REG_TYPE1
>
> struct cmdq_instruction {
> union {
> @@ -21,8 +22,17 @@ struct cmdq_instruction {
> union {
> u16 offset;
> u16 event;
> + u16 reg_dst;
> + };
> + union {
> + u8 subsys;
> + struct {
> + u8 sop:5;
> + u8 arg_c_t:1;
> + u8 src_t:1;
> + u8 dst_t:1;
> + };
> };
> - u8 subsys;
> u8 op;
> };
>
> @@ -277,6 +287,18 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
> }
> EXPORT_SYMBOL(cmdq_pkt_poll_mask);
>
> +int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value)
> +{
> + struct cmdq_instruction inst = {};
> +
> + inst.op = CMDQ_CODE_LOGIC;
> + inst.dst_t = CMDQ_REG_TYPE;
> + inst.reg_dst = reg_idx;
> + inst.value = value;
> + return cmdq_pkt_append_command(pkt, inst);
> +}
> +EXPORT_SYMBOL(cmdq_pkt_assign);
> +
> static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> {
> struct cmdq_instruction inst = { {0} };
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index dfe5b2eb85cc..121c3bb6d3de 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -59,6 +59,7 @@ enum cmdq_code {
> CMDQ_CODE_JUMP = 0x10,
> CMDQ_CODE_WFE = 0x20,
> CMDQ_CODE_EOC = 0x40,
> + CMDQ_CODE_LOGIC = 0xa0,
> };
>
> enum cmdq_cb_status {
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index a74c1d5acdf3..83340211e1d3 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -152,6 +152,20 @@ int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
> */
> int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
> u16 offset, u32 value, u32 mask);
> +
> +/**
> + * cmdq_pkt_assign() - Append logic assign command to the CMDQ packet, ask
> GCE
> + * to execute an instruction that set a constant value into
> + * internal register and use as value, mask or address in
> + * read/write instruction.
> + * @pkt: the CMDQ packet
> + * @reg_idx: the CMDQ internal register ID
> + * @value: the specified value
> + *
> + * Return: 0 for success; else the error code is returned
> + */
> +int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
> +
> /**
> * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
> * packet and call back at the end of done packet
>
[PATCH v4 1/4] spi: spi-fsl-dspi: Fix lockup if device is removed during SPI transfer
During device removal, the driver should unregister the SPI controller
and stop the hardware. Otherwise the dspi_transfer_one_message() could
wait on completion infinitely.
Additionally, calling spi_unregister_controller() first in device
removal reverse-matches the probe function, where SPI controller is
registered at the end.
Fixes: 05209f457069 ("spi: fsl-dspi: add missing clk_disable_unprepare() in
dspi_remove()")
Cc:
Reported-by: Vladimir Oltean
Signed-off-by: Krzysztof Kozlowski
---
Changes since v3:
1. New patch.
---
drivers/spi/spi-fsl-dspi.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 58190c94561f..ec0fd0d366eb 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -1434,9 +1434,18 @@ static int dspi_remove(struct platform_device *pdev)
struct fsl_dspi *dspi = spi_controller_get_devdata(ctlr);
/* Disconnect from the SPI framework */
+ spi_unregister_controller(dspi->ctlr);
+
+ /* Disable RX and TX */
+ regmap_update_bits(dspi->regmap, SPI_MCR,
+ SPI_MCR_DIS_TXF | SPI_MCR_DIS_RXF,
+ SPI_MCR_DIS_TXF | SPI_MCR_DIS_RXF);
+
+ /* Stop Running */
+ regmap_update_bits(dspi->regmap, SPI_MCR, SPI_MCR_HALT, SPI_MCR_HALT);
+
dspi_release_dma(dspi);
clk_disable_unprepare(dspi->clk);
- spi_unregister_controller(dspi->ctlr);
return 0;
}
--
2.17.1
[PATCH v4 3/4] spi: spi-fsl-dspi: Fix external abort on interrupt in resume or exit paths
If shared interrupt comes late, during probe error path or device remove
(could be triggered with CONFIG_DEBUG_SHIRQ), the interrupt handler
dspi_interrupt() will access registers with the clock being disabled.
This leads to external abort on non-linefetch on Toradex Colibri VF50
module (with Vybrid VF5xx):
$ echo 4002d000.spi >
/sys/devices/platform/soc/4000.bus/4002d000.spi/driver/unbind
Unhandled fault: external abort on non-linefetch (0x1008) at 0x8887f02c
Internal error: : 1008 [#1] ARM
Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
Backtrace:
(regmap_mmio_read32le)
(regmap_mmio_read)
(_regmap_bus_reg_read)
(_regmap_read)
(regmap_read)
(dspi_interrupt)
(free_irq)
(devm_irq_release)
(release_nodes)
(devres_release_all)
(device_release_driver_internal)
The resource-managed framework should not be used for shared interrupt
handling, because the interrupt handler might be called after releasing
other resources and disabling clocks.
Similar bug could happen during suspend - the shared interrupt handler
could be invoked after suspending the device. Each device sharing this
interrupt line should disable the IRQ during suspend so handler will be
invoked only in following cases:
1. None suspended,
2. All devices resumed.
Fixes: 349ad66c0ab0 ("spi:Add Freescale DSPI driver for Vybrid VF610 platform")
Cc:
Signed-off-by: Krzysztof Kozlowski
---
Changes since v3:
1. Use simpler if (dspi->irq).
Changes since v2:
1. Go back to v1 and use non-devm interface,
2. Fix also suspend/resume paths.
Changes since v1:
1. Disable the IRQ instead of using non-devm interface.
---
drivers/spi/spi-fsl-dspi.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index ec7919d9c0d9..e0b30e4b1b69 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -1109,6 +1109,8 @@ static int dspi_suspend(struct device *dev)
struct spi_controller *ctlr = dev_get_drvdata(dev);
struct fsl_dspi *dspi = spi_controller_get_devdata(ctlr);
+ if (dspi->irq)
+ disable_irq(dspi->irq);
spi_controller_suspend(ctlr);
clk_disable_unprepare(dspi->clk);
@@ -1129,6 +1131,8 @@ static int dspi_resume(struct device *dev)
if (ret)
return ret;
spi_controller_resume(ctlr);
+ if (dspi->irq)
+ enable_irq(dspi->irq);
return 0;
}
@@ -1385,8 +1389,8 @@ static int dspi_probe(struct platform_device *pdev)
goto poll_mode;
}
- ret = devm_request_irq(&pdev->dev, dspi->irq, dspi_interrupt,
- IRQF_SHARED, pdev->name, dspi);
+ ret = request_threaded_irq(dspi->irq, dspi_interrupt, NULL,
+ IRQF_SHARED, pdev->name, dspi);
if (ret < 0) {
dev_err(&pdev->dev, "Unable to attach DSPI interrupt\n");
goto out_clk_put;
@@ -1400,7 +1404,7 @@ static int dspi_probe(struct platform_device *pdev)
ret = dspi_request_dma(dspi, res->start);
if (ret < 0) {
dev_err(&pdev->dev, "can't get dma channels\n");
- goto out_clk_put;
+ goto out_free_irq;
}
}
@@ -1415,11 +1419,14 @@ static int dspi_probe(struct platform_device *pdev)
ret = spi_register_controller(ctlr);
if (ret != 0) {
dev_err(&pdev->dev, "Problem registering DSPI ctlr\n");
- goto out_clk_put;
+ goto out_free_irq;
}
return ret;
+out_free_irq:
+ if (dspi->irq)
+ free_irq(dspi->irq, dspi);
out_clk_put:
clk_disable_unprepare(dspi->clk);
out_ctlr_put:
@@ -1445,6 +1452,8 @@ static int dspi_remove(struct platform_device *pdev)
regmap_update_bits(dspi->regmap, SPI_MCR, SPI_MCR_HALT, SPI_MCR_HALT);
dspi_release_dma(dspi);
+ if (dspi->irq)
+ free_irq(dspi->irq, dspi);
clk_disable_unprepare(dspi->clk);
return 0;
--
2.17.1
[PATCH v4 4/4] spi: spi-fsl-dspi: Initialize completion before possible interrupt
The interrupt handler calls completion and is IRQ requested before the
completion is initialized. Logically it should be the other way.
Signed-off-by: Krzysztof Kozlowski
---
Changes since v2:
1. None
Changes since v1:
1. Rework the commit msg.
---
drivers/spi/spi-fsl-dspi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index e0b30e4b1b69..91c6affe139c 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -1389,6 +1389,8 @@ static int dspi_probe(struct platform_device *pdev)
goto poll_mode;
}
+ init_completion(&dspi->xfer_done);
+
ret = request_threaded_irq(dspi->irq, dspi_interrupt, NULL,
IRQF_SHARED, pdev->name, dspi);
if (ret < 0) {
@@ -1396,8 +1398,6 @@ static int dspi_probe(struct platform_device *pdev)
goto out_clk_put;
}
- init_completion(&dspi->xfer_done);
-
poll_mode:
if (dspi->devtype_data->trans_mode == DSPI_DMA_MODE) {
--
2.17.1
[PATCH v4 2/4] spi: spi-fsl-dspi: Fix lockup if device is shutdown during SPI transfer
During shutdown, the driver should unregister the SPI controller
and stop the hardware. Otherwise the dspi_transfer_one_message() could
wait on completion infinitely.
Additionally, calling spi_unregister_controller() first in device
shutdown reverse-matches the probe function, where SPI controller is
registered at the end.
Fixes: dc234825997e ("spi: spi-fsl-dspi: Adding shutdown hook")
Cc:
Reported-by: Vladimir Oltean
Signed-off-by: Krzysztof Kozlowski
---
kexec() not tested, only system shutdown.
Changes since v3:
1. New patch.
---
drivers/spi/spi-fsl-dspi.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index ec0fd0d366eb..ec7919d9c0d9 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -1452,20 +1452,7 @@ static int dspi_remove(struct platform_device *pdev)
static void dspi_shutdown(struct platform_device *pdev)
{
- struct spi_controller *ctlr = platform_get_drvdata(pdev);
- struct fsl_dspi *dspi = spi_controller_get_devdata(ctlr);
-
- /* Disable RX and TX */
- regmap_update_bits(dspi->regmap, SPI_MCR,
- SPI_MCR_DIS_TXF | SPI_MCR_DIS_RXF,
- SPI_MCR_DIS_TXF | SPI_MCR_DIS_RXF);
-
- /* Stop Running */
- regmap_update_bits(dspi->regmap, SPI_MCR, SPI_MCR_HALT, SPI_MCR_HALT);
-
- dspi_release_dma(dspi);
- clk_disable_unprepare(dspi->clk);
- spi_unregister_controller(dspi->ctlr);
+ dspi_remove(pdev);
}
static struct platform_driver fsl_dspi_driver = {
--
2.17.1
drivers/iommu/mtk_iommu.c:438:29: warning: comparison is always false due to limited range of data type
Hi Krzysztof,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 625d3449788f85569096780592549d0340e9c0c7
commit: e93a1695d7fb551376b1c1220a267d032b6ad159 iommu: Enable compile testing
for some of drivers
date: 4 months ago
config: i386-randconfig-r012-20200622 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
reproduce (this is a W=1 build):
git checkout e93a1695d7fb551376b1c1220a267d032b6ad159
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>, old ones prefixed by <<):
drivers/iommu/mtk_iommu.c: In function 'mtk_iommu_iova_to_phys':
>> drivers/iommu/mtk_iommu.c:438:29: warning: comparison is always false due to
>> limited range of data type [-Wtype-limits]
438 | if (data->enable_4GB && pa >= MTK_IOMMU_4GB_MODE_REMAP_BASE)
| ^~
vim +438 drivers/iommu/mtk_iommu.c
4d689b61944589 Robin Murphy 2017-09-28 429
0df4fabe208d95 Yong Wu 2016-02-23 430 static phys_addr_t
mtk_iommu_iova_to_phys(struct iommu_domain *domain,
0df4fabe208d95 Yong Wu 2016-02-23 431
dma_addr_t iova)
0df4fabe208d95 Yong Wu 2016-02-23 432 {
0df4fabe208d95 Yong Wu 2016-02-23 433 struct mtk_iommu_domain *dom =
to_mtk_domain(domain);
30e2fccf951238 Yong Wu 2017-08-21 434 struct mtk_iommu_data *data =
mtk_iommu_get_m4u_data();
0df4fabe208d95 Yong Wu 2016-02-23 435 phys_addr_t pa;
0df4fabe208d95 Yong Wu 2016-02-23 436
0df4fabe208d95 Yong Wu 2016-02-23 437 pa =
dom->iop->iova_to_phys(dom->iop, iova);
b4dad40e4f35bb Yong Wu 2019-08-24 @438 if (data->enable_4GB && pa >=
MTK_IOMMU_4GB_MODE_REMAP_BASE)
b4dad40e4f35bb Yong Wu 2019-08-24 439 pa &= ~BIT_ULL(32);
30e2fccf951238 Yong Wu 2017-08-21 440
0df4fabe208d95 Yong Wu 2016-02-23 441 return pa;
0df4fabe208d95 Yong Wu 2016-02-23 442 }
0df4fabe208d95 Yong Wu 2016-02-23 443
:: The code at line 438 was first introduced by commit
:: b4dad40e4f35bbf2393f35f4492acf799eb8136d iommu/mediatek: Adjust the PA
for the 4GB Mode
:: TO: Yong Wu
:: CC: Joerg Roedel
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: linux-next build error (9)
On Mon, 22 Jun 2020 at 11:49, Peter Zijlstra wrote: > > On Mon, Jun 22, 2020 at 02:37:12AM -0700, syzbot wrote: > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit:27f11fea Add linux-next specific files for 20200622 > > git tree: linux-next > > console output: https://syzkaller.appspot.com/x/log.txt?x=138dc74310 > > kernel config: https://syzkaller.appspot.com/x/.config?x=41c659db5cada6f4 > > dashboard link: https://syzkaller.appspot.com/bug?extid=dbf8cf3717c8ef4a90a0 > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+dbf8cf3717c8ef4a9...@syzkaller.appspotmail.com > > > > ./arch/x86/include/asm/kvm_para.h:99:29: error: inlining failed in call to > > always_inline 'kvm_handle_async_pf': function attribute mismatch > > ./arch/x86/include/asm/processor.h:824:29: error: inlining failed in call > > to always_inline 'prefetchw': function attribute mismatch > > ./arch/x86/include/asm/current.h:13:44: error: inlining failed in call to > > always_inline 'get_current': function attribute mismatch > > arch/x86/mm/fault.c:1353:1: error: inlining failed in call to always_inline > > 'handle_page_fault': function attribute mismatch > > ./arch/x86/include/asm/processor.h:576:29: error: inlining failed in call > > to always_inline 'native_swapgs': function attribute mismatch > > ./arch/x86/include/asm/fsgsbase.h:33:38: error: inlining failed in call to > > always_inline 'rdgsbase': function attribute mismatch > > ./arch/x86/include/asm/irq_stack.h:40:29: error: inlining failed in call to > > always_inline 'run_on_irqstack_cond': function attribute mismatch > > ./include/linux/debug_locks.h:15:28: error: inlining failed in call to > > always_inline '__debug_locks_off': function attribute mismatch > > ./include/asm-generic/atomic-instrumented.h:70:1: error: inlining failed in > > call to always_inline 'atomic_add_return': function attribute mismatch > > kernel/locking/lockdep.c:396:29: error: inlining failed in call to > > always_inline 'lockdep_recursion_finish': function attribute mismatch > > kernel/locking/lockdep.c:4725:5: error: inlining failed in call to > > always_inline '__lock_is_held': function attribute mismatch > > Hurmph, I though that was cured in GCC >= 8. Marco? Yeah, time to upgrade syzbot's compiler. This experimental gcc 9.0.0 still has the bug, but stable gcc 9 doesn't. For now, I think this requires no fixes on the kernel side. Thanks, -- Marco
Re: [PATCH v1 03/11] soc: mediatek: cmdq: add write_s function
On 21/06/2020 16:18, Dennis YC Hsieh wrote:
> add write_s function in cmdq helper functions which
> writes value contains in internal register to address
> with large dma access support.
>
> Signed-off-by: Dennis YC Hsieh
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 19 +++
> include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
> include/linux/soc/mediatek/mtk-cmdq.h| 19 +++
> 3 files changed, 39 insertions(+)
>
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index bf32e3b2ca6c..817a5a97dbe5 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -18,6 +18,10 @@ struct cmdq_instruction {
> union {
> u32 value;
> u32 mask;
> + struct {
> + u16 arg_c;
> + u16 src_reg;
> + };
> };
> union {
> u16 offset;
> @@ -222,6 +226,21 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
> }
> EXPORT_SYMBOL(cmdq_pkt_write_mask);
>
> +int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> + u16 addr_low, u16 src_reg_idx)
> +{
Do I understand correctly that we use CMDQ_ADDR_HIGH(addr) and
CMDQ_ADDR_LOW(addr) to calculate in the client high_addr_reg_idx and addr_low
respectively?
In that case I think a better interface would be to pass the address and do the
high/low calculation in the cmdq_pkt_write_s
Regards,
Matthias
> + struct cmdq_instruction inst = {};
> +
> + inst.op = CMDQ_CODE_WRITE_S;
> + inst.src_t = CMDQ_REG_TYPE;
> + inst.sop = high_addr_reg_idx;
> + inst.offset = addr_low;
> + inst.src_reg = src_reg_idx;
> +
> + return cmdq_pkt_append_command(pkt, inst);
> +}
> +EXPORT_SYMBOL(cmdq_pkt_write_s);
> +
> int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
> {
> struct cmdq_instruction inst = { {0} };
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index 121c3bb6d3de..ee67dd3b86f5 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -59,6 +59,7 @@ enum cmdq_code {
> CMDQ_CODE_JUMP = 0x10,
> CMDQ_CODE_WFE = 0x20,
> CMDQ_CODE_EOC = 0x40,
> + CMDQ_CODE_WRITE_S = 0x90,
> CMDQ_CODE_LOGIC = 0xa0,
> };
>
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 83340211e1d3..e1c5a7549b4f 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -12,6 +12,8 @@
> #include
>
> #define CMDQ_NO_TIMEOUT 0xu
> +#define CMDQ_ADDR_HIGH(addr) ((u32)(((addr) >> 16) & GENMASK(31, 0)))
> +#define CMDQ_ADDR_LOW(addr) ((u16)(addr) | BIT(1))
>
> struct cmdq_pkt;
>
> @@ -103,6 +105,23 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
> u16 offset, u32 value, u32 mask);
>
> /**
> + * cmdq_pkt_write_s() - append write_s command to the CMDQ packet
> + * @pkt: the CMDQ packet
> + * @high_addr_reg_idx: internal register ID which contains high
> address of pa
> + * @addr_low:low address of pa
> + * @src_reg_idx: the CMDQ internal register ID which cache source value
> + *
> + * Return: 0 for success; else the error code is returned
> + *
> + * Support write value to physical address without subsys. Use
> CMDQ_ADDR_HIGH()
> + * to get high address and call cmdq_pkt_assign() to assign value into
> internal
> + * reg. Also use CMDQ_ADDR_LOW() to get low address for addr_low parameter
> when
> + * call to this function.
> + */
> +int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
> + u16 addr_low, u16 src_reg_idx);
> +
> +/**
> * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
> * @pkt: the CMDQ packet
> * @event: the desired event type to "wait and CLEAR"
>
Re: [PATCH 1/3] crypto: permit users to specify numa node of acomp hardware
On Mon, 22 Jun 2020 11:24:23 +0100
"Song Bao Hua (Barry Song)" wrote:
> > -Original Message-
> > From: Jonathan Cameron
> > Sent: Monday, June 22, 2020 9:59 PM
> > To: Song Bao Hua (Barry Song)
> > Cc: herb...@gondor.apana.org.au; da...@davemloft.net; Seth Jennings
> > ; Linuxarm ;
> > linux-kernel@vger.kernel.org; linux...@kvack.org;
> > linux-cry...@vger.kernel.org; a...@linux-foundation.org; Dan Streetman
> > ; Vitaly Wool
> > Subject: Re: [PATCH 1/3] crypto: permit users to specify numa node of acomp
> > hardware
> >
> > On Mon, 22 Jun 2020 14:48:59 +1200
> > Barry Song wrote:
> >
> > > For a Linux server with NUMA, there are possibly multiple (de)compressors
> > > which are either local or remote to some NUMA node. Some drivers will
> > > automatically use the (de)compressor near the CPU calling acomp_alloc().
> > > However, it is not necessarily correct because users who send acomp_req
> > > could be from different NUMA node with the CPU which allocates acomp.
> > >
> > > Just like kernel has kmalloc() and kmalloc_node(), here crypto can have
> > > same support.
> > >
> > > Cc: Seth Jennings
> > > Cc: Dan Streetman
> > > Cc: Vitaly Wool
> > > Cc: Andrew Morton
> > > Signed-off-by: Barry Song
> >
> > Hi Barry,
> >
> > Seems sensible to me. A few trivial comments inline.
>
> Thanks for your review, Jonathan.
>
> >
> > Thanks,
> >
> > Jonathan
> >
> > > ---
> > > crypto/acompress.c | 8
> > > crypto/api.c | 22 ++
> > > crypto/internal.h | 23 +++
> > > include/crypto/acompress.h | 7 +++
> > > include/linux/crypto.h | 3 ++-
> > > 5 files changed, 50 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/crypto/acompress.c b/crypto/acompress.c
> > > index 84a76723e851..c32c72048a1c 100644
> > > --- a/crypto/acompress.c
> > > +++ b/crypto/acompress.c
> > > @@ -109,6 +109,14 @@ struct crypto_acomp *crypto_alloc_acomp(const
> > char *alg_name, u32 type,
> > > }
> > > EXPORT_SYMBOL_GPL(crypto_alloc_acomp);
> > >
> > > +struct crypto_acomp *crypto_alloc_acomp_node(const char *alg_name,
> > u32 type,
> > > + u32 mask, int node)
> > > +{
> > > + return crypto_alloc_tfm_node(alg_name, &crypto_acomp_type, type,
> > mask,
> > > + node);
> > > +}
> > > +EXPORT_SYMBOL_GPL(crypto_alloc_acomp_node);
> > > +
> > > struct acomp_req *acomp_request_alloc(struct crypto_acomp *acomp)
> > > {
> > > struct crypto_tfm *tfm = crypto_acomp_tfm(acomp);
> > > diff --git a/crypto/api.c b/crypto/api.c
> > > index edcf690800d4..4ecf712286af 100644
> > > --- a/crypto/api.c
> > > +++ b/crypto/api.c
> > > @@ -433,8 +433,9 @@ struct crypto_tfm *crypto_alloc_base(const char
> > *alg_name, u32 type, u32 mask)
> > > }
> > > EXPORT_SYMBOL_GPL(crypto_alloc_base);
> > >
> > > -void *crypto_create_tfm(struct crypto_alg *alg,
> > > - const struct crypto_type *frontend)
> > > +void *crypto_create_tfm_node(struct crypto_alg *alg,
> > > + const struct crypto_type *frontend,
> > > + int node)
> > > {
> > > char *mem;
> > > struct crypto_tfm *tfm = NULL;
> > > @@ -451,6 +452,7 @@ void *crypto_create_tfm(struct crypto_alg *alg,
> > >
> > > tfm = (struct crypto_tfm *)(mem + tfmsize);
> > > tfm->__crt_alg = alg;
> > > + tfm->node = node;
> > >
> > > err = frontend->init_tfm(tfm);
> > > if (err)
> > > @@ -472,7 +474,7 @@ void *crypto_create_tfm(struct crypto_alg *alg,
> > > out:
> > > return mem;
> > > }
> > > -EXPORT_SYMBOL_GPL(crypto_create_tfm);
> > > +EXPORT_SYMBOL_GPL(crypto_create_tfm_node);
> > >
> > > struct crypto_alg *crypto_find_alg(const char *alg_name,
> > > const struct crypto_type *frontend,
> > > @@ -490,11 +492,13 @@ struct crypto_alg *crypto_find_alg(const char
> > *alg_name,
> > > EXPORT_SYMBOL_GPL(crypto_find_alg);
> > >
> > > /*
> > > - * crypto_alloc_tfm - Locate algorithm and allocate transform
> > > + * crypto_alloc_tfm_node - Locate algorithm and allocate transform
> > > * @alg_name: Name of algorithm
> > > * @frontend: Frontend algorithm type
> > > * @type: Type of algorithm
> > > * @mask: Mask for type comparison
> > > + * @node: NUMA node in which users desire to put requests, if node
> > > is
> > > + * NUMA_NO_NODE, it means users have no special
> > > requirement.
> > > *
> > > * crypto_alloc_tfm() will first attempt to locate an already
> > > loaded
> > > * algorithm. If that fails and the kernel supports dynamically
> > loadable
> > > @@ -509,8 +513,10 @@ EXPORT_SYMBOL_GPL(crypto_find_alg);
> > > *
> > > * In case of error the return value is an error pointer.
> > > */
> > > -void *crypto_alloc_tfm(const char *alg_name,
> > > -const struct crypto_type *frontend, u32 type, u32 mask)
> > > +
> > > +void
[PATCH v2 0/3] ethernet: amd: Convert to generic power management
Linux Kernel Mentee: Remove Legacy Power Management. The purpose of this patch series is to remove legacy power management callbacks from amd ethernet drivers. The callbacks performing suspend() and resume() operations are still calling pci_save_state(), pci_set_power_state(), etc. and handling the power management themselves, which is not recommended. The conversion requires the removal of the those function calls and change the callback definition accordingly and make use of dev_pm_ops structure. All patches are compile-tested only. Vaibhav Gupta (3): pcnet32: Convert to generic power management amd8111e: Convert to generic power management amd-xgbe: Convert to generic power management drivers/net/ethernet/amd/amd8111e.c | 30 +--- drivers/net/ethernet/amd/pcnet32.c | 22 - drivers/net/ethernet/amd/xgbe/xgbe-pci.c | 19 +++ 3 files changed, 31 insertions(+), 40 deletions(-) -- 2.27.0
[PATCH v3] nbd: Fix memory leak in nbd_add_socket
When adding first socket to nbd, if nsock's allocation failed, the data
structure member "config->socks" was reallocated, but the data structure
member "config->num_connections" was not updated. A memory leak will occur
then because the function "nbd_config_put" will free "config->socks" only
when "config->num_connections" is not zero.
Fixes: 03bf73c315ed ("nbd: prevent memory leak")
Signed-off-by: Zheng Bin
---
v1->v2: improve change description
v2->v3: fix some code style issues, improve change description, thanks to
Markus for the review.
drivers/block/nbd.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 43cff01a5a67..ce7e9f223b20 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -1033,25 +1033,26 @@ static int nbd_add_socket(struct nbd_device *nbd,
unsigned long arg,
test_bit(NBD_RT_BOUND, &config->runtime_flags))) {
dev_err(disk_to_dev(nbd->disk),
"Device being setup by another task");
- sockfd_put(sock);
- return -EBUSY;
+ err = -EBUSY;
+ goto put_socket;
+ }
+
+ nsock = kzalloc(sizeof(*nsock), GFP_KERNEL);
+ if (!nsock) {
+ err = -ENOMEM;
+ goto put_socket;
}
socks = krealloc(config->socks, (config->num_connections + 1) *
sizeof(struct nbd_sock *), GFP_KERNEL);
if (!socks) {
- sockfd_put(sock);
- return -ENOMEM;
+ kfree(nsock);
+ err = -ENOMEM;
+ goto put_socket;
}
config->socks = socks;
- nsock = kzalloc(sizeof(struct nbd_sock), GFP_KERNEL);
- if (!nsock) {
- sockfd_put(sock);
- return -ENOMEM;
- }
-
nsock->fallback_index = -1;
nsock->dead = false;
mutex_init(&nsock->tx_lock);
@@ -1063,6 +1064,10 @@ static int nbd_add_socket(struct nbd_device *nbd,
unsigned long arg,
atomic_inc(&config->live_connections);
return 0;
+
+put_socket:
+ sockfd_put(sock);
+ return err;
}
static int nbd_reconnect_socket(struct nbd_device *nbd, unsigned long arg)
--
2.26.0.106.g9fadedd
Re: [PATCH v1 08/11] soc: mediatek: cmdq: export finalize function
On 21/06/2020 16:18, Dennis YC Hsieh wrote:
> Export finalize function to client which helps append eoc and jump
> command to pkt. Let client decide call finalize or not.
>
> Signed-off-by: Dennis YC Hsieh
> Reviewed-by: CK Hu
> Acked-by: Chun-Kuang Hu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c |1 +
> drivers/soc/mediatek/mtk-cmdq-helper.c |7 ++-
> include/linux/soc/mediatek/mtk-cmdq.h |8
> 3 files changed, 11 insertions(+), 5 deletions(-)
>
Applied to v5.8-next/soc
Thanks!
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 0dfcd1787e65..7daaabc26eb1 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -490,6 +490,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc
> *mtk_crtc)
> cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
> cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
> mtk_crtc_ddp_config(crtc, cmdq_handle);
> + cmdq_pkt_finalize(cmdq_handle);
> cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
> }
> #endif
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index e372ae065240..248945108a36 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -391,7 +391,7 @@ int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx,
> u32 value)
> }
> EXPORT_SYMBOL(cmdq_pkt_assign);
>
> -static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> +int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> {
> struct cmdq_instruction inst = { {0} };
> int err;
> @@ -411,6 +411,7 @@ static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
>
> return err;
> }
> +EXPORT_SYMBOL(cmdq_pkt_finalize);
>
> static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data data)
> {
> @@ -445,10 +446,6 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt,
> cmdq_async_flush_cb cb,
> unsigned long flags = 0;
> struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
>
> - err = cmdq_pkt_finalize(pkt);
> - if (err < 0)
> - return err;
> -
> pkt->cb.cb = cb;
> pkt->cb.data = data;
> pkt->async_cb.cb = cmdq_pkt_flush_async_cb;
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 6e8caacedc80..eac1405e4872 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -244,6 +244,14 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
> int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
>
> /**
> + * cmdq_pkt_finalize() - Append EOC and jump command to pkt.
> + * @pkt: the CMDQ packet
> + *
> + * Return: 0 for success; else the error code is returned
> + */
> +int cmdq_pkt_finalize(struct cmdq_pkt *pkt);
> +
> +/**
> * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
> * packet and call back at the end of done packet
> * @pkt: the CMDQ packet
>
[PATCH net 0/9] net: qed/qede: various stability fixes
This set addresses several near-critical issues that were observed and reproduced on different test and production configurations. Alexander Lobakin (9): net: qed: fix left elements count calculation net: qed: fix async event callbacks unregistering net: qede: stop adding events on an already destroyed workqueue net: qed: fix NVMe login fails over VFs net: qed: fix excessive QM ILT lines consumption net: qede: fix PTP initialization on recovery net: qede: fix use-after-free on recovery and AER handling net: qed: reset ILT block sizes before recomputing to fix crashes net: qed: fix "maybe uninitialized" warning drivers/net/ethernet/qlogic/qed/qed_cxt.c| 21 - drivers/net/ethernet/qlogic/qed/qed_dev.c| 11 +-- drivers/net/ethernet/qlogic/qed/qed_iwarp.c | 2 -- drivers/net/ethernet/qlogic/qed/qed_roce.c | 1 - drivers/net/ethernet/qlogic/qed/qed_vf.c | 23 +++ drivers/net/ethernet/qlogic/qede/qede_main.c | 3 +- drivers/net/ethernet/qlogic/qede/qede_ptp.c | 31 drivers/net/ethernet/qlogic/qede/qede_ptp.h | 2 +- drivers/net/ethernet/qlogic/qede/qede_rdma.c | 3 +- include/linux/qed/qed_chain.h| 26 +--- 10 files changed, 80 insertions(+), 43 deletions(-) -- 2.21.0
Re: [PATCH 1/3] mfd: ds1374: Introduce Dallas/Maxim DS1374 MFD core driver
On Mon, 22 Jun 2020, Johnson CH Chen (陳昭勳) wrote: > Dallas/Maxim DS1374 is a counter designed to continuously count > time in seconds. It provides an I2C interface to the host to > access RTC clock or Alarm/Watchdog timer. > > Add MFD Core driver, supporting the I2C communication to RTC and > Watchdog devices. > > Signed-off-by: Johnson Chen > --- > drivers/mfd/Kconfig | 11 + > drivers/mfd/Makefile | 2 + > drivers/mfd/ds1374.c | 101 +++ > 3 files changed, 114 insertions(+) > create mode 100644 drivers/mfd/ds1374.c Not sure I see the point of this driver. How/where is the device part registered? Is it DT only? If not, what else? Also where are the bindings? > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 687e9c848053w.d16031f4b487 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -1980,6 +1980,17 @@ config MFD_STM32_LPTIMER > To compile this driver as a module, choose M here: the > module will be called stm32-lptimer. > > +config MFD_DS1374 > + tristate "Support for Dallas/Maxim DS1374" > + depends on I2C > + select MFD_CORE > + help > + Say yes here to add support for Dallas/Maxim DS1374 Semiconductor. > + This driver provides RTC and watchdog. > + > + This driver can also be built as a module. If so, module will be > + called ds1374. > + > config MFD_STM32_TIMERS > tristate "Support for STM32 Timers" > depends on (ARCH_STM32 && OF) || COMPILE_TEST -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH net 9/9] net: qed: fix "maybe uninitialized" warning
Variable 'abs_ppfid' in qed_dev.c:qed_llh_add_mac_filter() always gets
printed, but is initialized only under 'ref_cnt == 1' condition. This
results in:
In file included from ./include/linux/kernel.h:15:0,
from ./include/asm-generic/bug.h:19,
from ./arch/x86/include/asm/bug.h:86,
from ./include/linux/bug.h:5,
from ./include/linux/io.h:11,
from drivers/net/ethernet/qlogic/qed/qed_dev.c:35:
drivers/net/ethernet/qlogic/qed/qed_dev.c: In function 'qed_llh_add_mac_filter':
./include/linux/printk.h:358:2: warning: 'abs_ppfid' may be used uninitialized
in this function [-Wmaybe-uninitialized]
printk(KERN_NOTICE pr_fmt(fmt), ##__VA_ARGS__)
^~
drivers/net/ethernet/qlogic/qed/qed_dev.c:983:17: note: 'abs_ppfid' was declared
here
u8 filter_idx, abs_ppfid;
^
...under W=1+.
Fix this by initializing it with zero.
Fixes: 79284adeb99e ("qed: Add llh ppfid interface and 100g support for
offload protocols")
Signed-off-by: Alexander Lobakin
Signed-off-by: Igor Russkikh
Signed-off-by: Michal Kalderon
---
drivers/net/ethernet/qlogic/qed/qed_dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c
b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index b41ada668948..3aa51374e727 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -980,7 +980,7 @@ int qed_llh_add_mac_filter(struct qed_dev *cdev,
struct qed_hwfn *p_hwfn = QED_LEADING_HWFN(cdev);
struct qed_ptt *p_ptt = qed_ptt_acquire(p_hwfn);
union qed_llh_filter filter = {};
- u8 filter_idx, abs_ppfid;
+ u8 filter_idx, abs_ppfid = 0;
u32 high, low, ref_cnt;
int rc = 0;
--
2.21.0
[PATCH net 5/9] net: qed: fix excessive QM ILT lines consumption
This is likely a copy'n'paste mistake. The amount of ILT lines to
reserve for a single VF was being multiplied by the total VFs count.
This led to a huge redundancy in reservation and potential lines
drainouts.
Fixes: 1408cc1fa48c ("qed: Introduce VFs")
Signed-off-by: Alexander Lobakin
Signed-off-by: Igor Russkikh
Signed-off-by: Michal Kalderon
---
drivers/net/ethernet/qlogic/qed/qed_cxt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_cxt.c
b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
index 7b76667acaba..c0a769b5358c 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_cxt.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
@@ -271,7 +271,7 @@ static void qed_cxt_qm_iids(struct qed_hwfn *p_hwfn,
vf_tids += segs[NUM_TASK_PF_SEGMENTS].count;
}
- iids->vf_cids += vf_cids * p_mngr->vf_count;
+ iids->vf_cids = vf_cids;
iids->tids += vf_tids * p_mngr->vf_count;
DP_VERBOSE(p_hwfn, QED_MSG_ILT,
--
2.21.0
[PATCH v2 2/3] amd8111e: Convert to generic power management
Drivers should not save device registers and/or change the power state of
the device. As per the generic PM approach, these are handled by PCI core.
The driver should support dev_pm_ops callbacks and bind them to pci_driver.
Compile-tested only.
Signed-off-by: Vaibhav Gupta
---
drivers/net/ethernet/amd/amd8111e.c | 30 +++--
1 file changed, 11 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/amd/amd8111e.c
b/drivers/net/ethernet/amd/amd8111e.c
index 7a1286f8e983..c6591b33abcc 100644
--- a/drivers/net/ethernet/amd/amd8111e.c
+++ b/drivers/net/ethernet/amd/amd8111e.c
@@ -1580,9 +1580,10 @@ static void amd8111e_tx_timeout(struct net_device *dev,
unsigned int txqueue)
if(!err)
netif_wake_queue(dev);
}
-static int amd8111e_suspend(struct pci_dev *pci_dev, pm_message_t state)
+
+static int amd8111e_suspend(struct device *dev_d)
{
- struct net_device *dev = pci_get_drvdata(pci_dev);
+ struct net_device *dev = dev_get_drvdata(dev_d);
struct amd8111e_priv *lp = netdev_priv(dev);
if (!netif_running(dev))
@@ -1609,34 +1610,24 @@ static int amd8111e_suspend(struct pci_dev *pci_dev,
pm_message_t state)
if(lp->options & OPTION_WAKE_PHY_ENABLE)
amd8111e_enable_link_change(lp);
- pci_enable_wake(pci_dev, PCI_D3hot, 1);
- pci_enable_wake(pci_dev, PCI_D3cold, 1);
+ device_set_wakeup_enable(dev_d, 1);
}
else{
- pci_enable_wake(pci_dev, PCI_D3hot, 0);
- pci_enable_wake(pci_dev, PCI_D3cold, 0);
+ device_set_wakeup_enable(dev_d, 0);
}
- pci_save_state(pci_dev);
- pci_set_power_state(pci_dev, PCI_D3hot);
-
return 0;
}
-static int amd8111e_resume(struct pci_dev *pci_dev)
+
+static int amd8111e_resume(struct device *dev_d)
{
- struct net_device *dev = pci_get_drvdata(pci_dev);
+ struct net_device *dev = dev_get_drvdata(dev_d);
struct amd8111e_priv *lp = netdev_priv(dev);
if (!netif_running(dev))
return 0;
- pci_set_power_state(pci_dev, PCI_D0);
- pci_restore_state(pci_dev);
-
- pci_enable_wake(pci_dev, PCI_D3hot, 0);
- pci_enable_wake(pci_dev, PCI_D3cold, 0); /* D3 cold */
-
netif_device_attach(dev);
spin_lock_irq(&lp->lock);
@@ -1918,13 +1909,14 @@ static const struct pci_device_id amd8111e_pci_tbl[] = {
};
MODULE_DEVICE_TABLE(pci, amd8111e_pci_tbl);
+static SIMPLE_DEV_PM_OPS(amd8111e_pm_ops, amd8111e_suspend, amd8111e_resume);
+
static struct pci_driver amd8111e_driver = {
.name = MODULE_NAME,
.id_table = amd8111e_pci_tbl,
.probe = amd8111e_probe_one,
.remove = amd8111e_remove_one,
- .suspend= amd8111e_suspend,
- .resume = amd8111e_resume
+ .driver.pm = &amd8111e_pm_ops
};
module_pci_driver(amd8111e_driver);
--
2.27.0
arch/mips/sgi-ip27/ip27-hubio.c:30:15: warning: no previous prototype for 'hub_pio_map'
Hi Thomas,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 625d3449788f85569096780592549d0340e9c0c7
commit: b78e9d63a3b6307b6b786e6ba189d3978b60ceb5 MIPS: SGI-IP27: use
asm/sn/agent.h for including HUB related stuff
date: 6 months ago
config: mips-randconfig-r021-20200622 (attached as .config)
compiler: mips64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout b78e9d63a3b6307b6b786e6ba189d3978b60ceb5
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>, old ones prefixed by <<):
>> arch/mips/sgi-ip27/ip27-hubio.c:30:15: warning: no previous prototype for
>> 'hub_pio_map' [-Wmissing-prototypes]
30 | unsigned long hub_pio_map(nasid_t nasid, xwidgetnum_t widget,
| ^~~
>> arch/mips/sgi-ip27/ip27-hubio.c:175:6: warning: no previous prototype for
>> 'hub_pio_init' [-Wmissing-prototypes]
175 | void hub_pio_init(nasid_t nasid)
| ^~~~
vim +/hub_pio_map +30 arch/mips/sgi-ip27/ip27-hubio.c
^1da177e4c3f41 Linus Torvalds 2005-04-16 20
^1da177e4c3f41 Linus Torvalds 2005-04-16 21 /**
^1da177e4c3f41 Linus Torvalds 2005-04-16 22 * hub_pio_map -
establish a HUB PIO mapping
^1da177e4c3f41 Linus Torvalds 2005-04-16 23 *
^1da177e4c3f41 Linus Torvalds 2005-04-16 24 * @hub:hub to perform
PIO mapping on
^1da177e4c3f41 Linus Torvalds 2005-04-16 25 * @widget: widget ID to
perform PIO mapping for
^1da177e4c3f41 Linus Torvalds 2005-04-16 26 * @xtalk_addr:
xtalk_address that needs to be mapped
^1da177e4c3f41 Linus Torvalds 2005-04-16 27 * @size: size of the PIO
mapping
^1da177e4c3f41 Linus Torvalds 2005-04-16 28 *
^1da177e4c3f41 Linus Torvalds 2005-04-16 29 **/
4bf841ebf17aaa Thomas Bogendoerfer 2019-10-03 @30 unsigned long
hub_pio_map(nasid_t nasid, xwidgetnum_t widget,
^1da177e4c3f41 Linus Torvalds 2005-04-16 31
unsigned long xtalk_addr, size_t size)
^1da177e4c3f41 Linus Torvalds 2005-04-16 32 {
^1da177e4c3f41 Linus Torvalds 2005-04-16 33 unsigned i;
^1da177e4c3f41 Linus Torvalds 2005-04-16 34
^1da177e4c3f41 Linus Torvalds 2005-04-16 35 /* use small-window
mapping if possible */
^1da177e4c3f41 Linus Torvalds 2005-04-16 36 if ((xtalk_addr %
SWIN_SIZE) + size <= SWIN_SIZE)
^1da177e4c3f41 Linus Torvalds 2005-04-16 37 return
NODE_SWIN_BASE(nasid, widget) + (xtalk_addr % SWIN_SIZE);
^1da177e4c3f41 Linus Torvalds 2005-04-16 38
^1da177e4c3f41 Linus Torvalds 2005-04-16 39 if ((xtalk_addr %
BWIN_SIZE) + size > BWIN_SIZE) {
^1da177e4c3f41 Linus Torvalds 2005-04-16 40
printk(KERN_WARNING "PIO mapping at hub %d widget %d addr 0x%lx"
^1da177e4c3f41 Linus Torvalds 2005-04-16 41
" too big (%ld)\n",
^1da177e4c3f41 Linus Torvalds 2005-04-16 42
nasid, widget, xtalk_addr, size);
^1da177e4c3f41 Linus Torvalds 2005-04-16 43 return 0;
^1da177e4c3f41 Linus Torvalds 2005-04-16 44 }
^1da177e4c3f41 Linus Torvalds 2005-04-16 45
^1da177e4c3f41 Linus Torvalds 2005-04-16 46 xtalk_addr &=
~(BWIN_SIZE-1);
^1da177e4c3f41 Linus Torvalds 2005-04-16 47 for (i = 0; i <
HUB_NUM_BIG_WINDOW; i++) {
4bf841ebf17aaa Thomas Bogendoerfer 2019-10-03 48 if
(test_and_set_bit(i, hub_data(nasid)->h_bigwin_used))
^1da177e4c3f41 Linus Torvalds 2005-04-16 49
continue;
^1da177e4c3f41 Linus Torvalds 2005-04-16 50
^1da177e4c3f41 Linus Torvalds 2005-04-16 51 /*
^1da177e4c3f41 Linus Torvalds 2005-04-16 52 * The code
below does a PIO write to setup an ITTE entry.
^1da177e4c3f41 Linus Torvalds 2005-04-16 53 *
^1da177e4c3f41 Linus Torvalds 2005-04-16 54 * We need to
prevent other CPUs from seeing our updated
^1da177e4c3f41 Linus Torvalds 2005-04-16 55 * memory
shadow of the ITTE (in the piomap) until the ITTE
^1da177e4c3f41 Linus Torvalds 2005-04-16 56 * entry is
actually set up; otherwise, another CPU might
^1da177e4c3f41 Linus Torvalds 2005-04-16 57 * attempt a
PIO prematurely.
^1da177e4c3f41 Linus Torvalds 2005-04-16 58 *
^1da177e4c3f41 Linus Torvalds 2005-04-16 59
[PATCH v2 0/3] ethernet: amd: Convert to generic power management
Linux Kernel Mentee: Remove Legacy Power Management. The purpose of this patch series is to remove legacy power management callbacks from amd ethernet drivers. The callbacks performing suspend() and resume() operations are still calling pci_save_state(), pci_set_power_state(), etc. and handling the power management themselves, which is not recommended. The conversion requires the removal of the those function calls and change the callback definition accordingly and make use of dev_pm_ops structure. All patches are compile-tested only. Vaibhav Gupta (3): pcnet32: Convert to generic power management amd8111e: Convert to generic power management amd-xgbe: Convert to generic power management drivers/net/ethernet/amd/amd8111e.c | 30 +--- drivers/net/ethernet/amd/pcnet32.c | 22 - drivers/net/ethernet/amd/xgbe/xgbe-pci.c | 19 +++ 3 files changed, 31 insertions(+), 40 deletions(-) -- 2.27.0
[PATCH v2 1/3] pcnet32: Convert to generic power management
Remove legacy PM callbacks and use generic operations. With legacy code,
drivers were responsible for handling PCI PM operations like
pci_save_state(). In generic code, all these are handled by PCI core.
The generic suspend() and resume() are called at the same point the legacy
ones were called. Thus, it does not affect the normal functioning of the
driver.
Compile-tested only.
Signed-off-by: Vaibhav Gupta
---
drivers/net/ethernet/amd/pcnet32.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/amd/pcnet32.c
b/drivers/net/ethernet/amd/pcnet32.c
index 07e8211eea51..d32f54d760e7 100644
--- a/drivers/net/ethernet/amd/pcnet32.c
+++ b/drivers/net/ethernet/amd/pcnet32.c
@@ -2913,30 +2913,27 @@ static void pcnet32_watchdog(struct timer_list *t)
mod_timer(&lp->watchdog_timer, round_jiffies(PCNET32_WATCHDOG_TIMEOUT));
}
-static int pcnet32_pm_suspend(struct pci_dev *pdev, pm_message_t state)
+static int pcnet32_pm_suspend(struct device *device_d)
{
- struct net_device *dev = pci_get_drvdata(pdev);
+ struct net_device *dev = dev_get_drvdata(device_d);
if (netif_running(dev)) {
netif_device_detach(dev);
pcnet32_close(dev);
}
- pci_save_state(pdev);
- pci_set_power_state(pdev, pci_choose_state(pdev, state));
+
return 0;
}
-static int pcnet32_pm_resume(struct pci_dev *pdev)
+static int pcnet32_pm_resume(struct device *device_d)
{
- struct net_device *dev = pci_get_drvdata(pdev);
-
- pci_set_power_state(pdev, PCI_D0);
- pci_restore_state(pdev);
+ struct net_device *dev = dev_get_drvdata(device_d);
if (netif_running(dev)) {
pcnet32_open(dev);
netif_device_attach(dev);
}
+
return 0;
}
@@ -2957,13 +2954,16 @@ static void pcnet32_remove_one(struct pci_dev *pdev)
}
}
+static SIMPLE_DEV_PM_OPS(pcnet32_pm_ops, pcnet32_pm_suspend,
pcnet32_pm_resume);
+
static struct pci_driver pcnet32_driver = {
.name = DRV_NAME,
.probe = pcnet32_probe_pci,
.remove = pcnet32_remove_one,
.id_table = pcnet32_pci_tbl,
- .suspend = pcnet32_pm_suspend,
- .resume = pcnet32_pm_resume,
+ .driver = {
+ .pm = &pcnet32_pm_ops,
+ },
};
/* An additional parameter that may be passed in... */
--
2.27.0
[PATCH v2 3/3] amd-xgbe: Convert to generic power management
Use dev_pm_ops structure to call generic suspend() and resume() callbacks.
Drivers should avoid saving device register and/or change power states
using PCI helper functions. With the generic approach, all these are handled
by PCI core.
Compile-tested only.
Signed-off-by: Vaibhav Gupta
---
drivers/net/ethernet/amd/xgbe/xgbe-pci.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-pci.c
b/drivers/net/ethernet/amd/xgbe/xgbe-pci.c
index 7b86240ecd5f..90cb55eb5466 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-pci.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-pci.c
@@ -421,10 +421,9 @@ static void xgbe_pci_remove(struct pci_dev *pdev)
xgbe_free_pdata(pdata);
}
-#ifdef CONFIG_PM
-static int xgbe_pci_suspend(struct pci_dev *pdev, pm_message_t state)
+static int __maybe_unused xgbe_pci_suspend(struct device *dev)
{
- struct xgbe_prv_data *pdata = pci_get_drvdata(pdev);
+ struct xgbe_prv_data *pdata = dev_get_drvdata(dev);
struct net_device *netdev = pdata->netdev;
int ret = 0;
@@ -438,9 +437,9 @@ static int xgbe_pci_suspend(struct pci_dev *pdev,
pm_message_t state)
return ret;
}
-static int xgbe_pci_resume(struct pci_dev *pdev)
+static int __maybe_unused xgbe_pci_resume(struct device *dev)
{
- struct xgbe_prv_data *pdata = pci_get_drvdata(pdev);
+ struct xgbe_prv_data *pdata = dev_get_drvdata(dev);
struct net_device *netdev = pdata->netdev;
int ret = 0;
@@ -460,7 +459,6 @@ static int xgbe_pci_resume(struct pci_dev *pdev)
return ret;
}
-#endif /* CONFIG_PM */
static const struct xgbe_version_data xgbe_v2a = {
.init_function_ptrs_phy_impl= xgbe_init_function_ptrs_phy_v2,
@@ -502,15 +500,16 @@ static const struct pci_device_id xgbe_pci_table[] = {
};
MODULE_DEVICE_TABLE(pci, xgbe_pci_table);
+static SIMPLE_DEV_PM_OPS(xgbe_pci_pm_ops, xgbe_pci_suspend, xgbe_pci_resume);
+
static struct pci_driver xgbe_driver = {
.name = XGBE_DRV_NAME,
.id_table = xgbe_pci_table,
.probe = xgbe_pci_probe,
.remove = xgbe_pci_remove,
-#ifdef CONFIG_PM
- .suspend = xgbe_pci_suspend,
- .resume = xgbe_pci_resume,
-#endif
+ .driver = {
+ .pm = &xgbe_pci_pm_ops,
+ }
};
int xgbe_pci_init(void)
--
2.27.0
Re: [PATCH v4 2/4] spi: spi-fsl-dspi: Fix lockup if device is shutdown during SPI transfer
On Mon, 22 Jun 2020 at 14:08, Krzysztof Kozlowski wrote:
>
> During shutdown, the driver should unregister the SPI controller
> and stop the hardware. Otherwise the dspi_transfer_one_message() could
> wait on completion infinitely.
>
> Additionally, calling spi_unregister_controller() first in device
> shutdown reverse-matches the probe function, where SPI controller is
> registered at the end.
>
> Fixes: dc234825997e ("spi: spi-fsl-dspi: Adding shutdown hook")
> Cc:
> Reported-by: Vladimir Oltean
> Signed-off-by: Krzysztof Kozlowski
>
> ---
Reviewed-by: Vladimir Oltean
Tested-by: Vladimir Oltean
>
> kexec() not tested, only system shutdown.
>
> Changes since v3:
> 1. New patch.
> ---
> drivers/spi/spi-fsl-dspi.c | 15 +--
> 1 file changed, 1 insertion(+), 14 deletions(-)
>
> diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> index ec0fd0d366eb..ec7919d9c0d9 100644
> --- a/drivers/spi/spi-fsl-dspi.c
> +++ b/drivers/spi/spi-fsl-dspi.c
> @@ -1452,20 +1452,7 @@ static int dspi_remove(struct platform_device *pdev)
>
> static void dspi_shutdown(struct platform_device *pdev)
> {
> - struct spi_controller *ctlr = platform_get_drvdata(pdev);
> - struct fsl_dspi *dspi = spi_controller_get_devdata(ctlr);
> -
> - /* Disable RX and TX */
> - regmap_update_bits(dspi->regmap, SPI_MCR,
> - SPI_MCR_DIS_TXF | SPI_MCR_DIS_RXF,
> - SPI_MCR_DIS_TXF | SPI_MCR_DIS_RXF);
> -
> - /* Stop Running */
> - regmap_update_bits(dspi->regmap, SPI_MCR, SPI_MCR_HALT, SPI_MCR_HALT);
> -
> - dspi_release_dma(dspi);
> - clk_disable_unprepare(dspi->clk);
> - spi_unregister_controller(dspi->ctlr);
> + dspi_remove(pdev);
> }
>
> static struct platform_driver fsl_dspi_driver = {
> --
> 2.17.1
>
Re: [PATCH v4 3/4] spi: spi-fsl-dspi: Fix external abort on interrupt in resume or exit paths
On Mon, 22 Jun 2020 at 14:07, Krzysztof Kozlowski wrote:
>
> If shared interrupt comes late, during probe error path or device remove
> (could be triggered with CONFIG_DEBUG_SHIRQ), the interrupt handler
> dspi_interrupt() will access registers with the clock being disabled.
> This leads to external abort on non-linefetch on Toradex Colibri VF50
> module (with Vybrid VF5xx):
>
> $ echo 4002d000.spi >
> /sys/devices/platform/soc/4000.bus/4002d000.spi/driver/unbind
>
> Unhandled fault: external abort on non-linefetch (0x1008) at 0x8887f02c
> Internal error: : 1008 [#1] ARM
> Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
> Backtrace:
> (regmap_mmio_read32le)
> (regmap_mmio_read)
> (_regmap_bus_reg_read)
> (_regmap_read)
> (regmap_read)
> (dspi_interrupt)
> (free_irq)
> (devm_irq_release)
> (release_nodes)
> (devres_release_all)
> (device_release_driver_internal)
>
> The resource-managed framework should not be used for shared interrupt
> handling, because the interrupt handler might be called after releasing
> other resources and disabling clocks.
>
> Similar bug could happen during suspend - the shared interrupt handler
> could be invoked after suspending the device. Each device sharing this
> interrupt line should disable the IRQ during suspend so handler will be
> invoked only in following cases:
> 1. None suspended,
> 2. All devices resumed.
>
> Fixes: 349ad66c0ab0 ("spi:Add Freescale DSPI driver for Vybrid VF610
> platform")
> Cc:
> Signed-off-by: Krzysztof Kozlowski
>
> ---
Reviewed-by: Vladimir Oltean
Tested-by: Vladimir Oltean
>
> Changes since v3:
> 1. Use simpler if (dspi->irq).
>
> Changes since v2:
> 1. Go back to v1 and use non-devm interface,
> 2. Fix also suspend/resume paths.
>
> Changes since v1:
> 1. Disable the IRQ instead of using non-devm interface.
> ---
> drivers/spi/spi-fsl-dspi.c | 17 +
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> index ec7919d9c0d9..e0b30e4b1b69 100644
> --- a/drivers/spi/spi-fsl-dspi.c
> +++ b/drivers/spi/spi-fsl-dspi.c
> @@ -1109,6 +1109,8 @@ static int dspi_suspend(struct device *dev)
> struct spi_controller *ctlr = dev_get_drvdata(dev);
> struct fsl_dspi *dspi = spi_controller_get_devdata(ctlr);
>
> + if (dspi->irq)
> + disable_irq(dspi->irq);
> spi_controller_suspend(ctlr);
> clk_disable_unprepare(dspi->clk);
>
> @@ -1129,6 +1131,8 @@ static int dspi_resume(struct device *dev)
> if (ret)
> return ret;
> spi_controller_resume(ctlr);
> + if (dspi->irq)
> + enable_irq(dspi->irq);
>
> return 0;
> }
> @@ -1385,8 +1389,8 @@ static int dspi_probe(struct platform_device *pdev)
> goto poll_mode;
> }
>
> - ret = devm_request_irq(&pdev->dev, dspi->irq, dspi_interrupt,
> - IRQF_SHARED, pdev->name, dspi);
> + ret = request_threaded_irq(dspi->irq, dspi_interrupt, NULL,
> + IRQF_SHARED, pdev->name, dspi);
> if (ret < 0) {
> dev_err(&pdev->dev, "Unable to attach DSPI interrupt\n");
> goto out_clk_put;
> @@ -1400,7 +1404,7 @@ static int dspi_probe(struct platform_device *pdev)
> ret = dspi_request_dma(dspi, res->start);
> if (ret < 0) {
> dev_err(&pdev->dev, "can't get dma channels\n");
> - goto out_clk_put;
> + goto out_free_irq;
> }
> }
>
> @@ -1415,11 +1419,14 @@ static int dspi_probe(struct platform_device *pdev)
> ret = spi_register_controller(ctlr);
> if (ret != 0) {
> dev_err(&pdev->dev, "Problem registering DSPI ctlr\n");
> - goto out_clk_put;
> + goto out_free_irq;
> }
>
> return ret;
>
> +out_free_irq:
> + if (dspi->irq)
> + free_irq(dspi->irq, dspi);
> out_clk_put:
> clk_disable_unprepare(dspi->clk);
> out_ctlr_put:
> @@ -1445,6 +1452,8 @@ static int dspi_remove(struct platform_device *pdev)
> regmap_update_bits(dspi->regmap, SPI_MCR, SPI_MCR_HALT, SPI_MCR_HALT);
>
> dspi_release_dma(dspi);
> + if (dspi->irq)
> + free_irq(dspi->irq, dspi);
> clk_disable_unprepare(dspi->clk);
>
> return 0;
> --
> 2.17.1
>
Re: [v3] coccinelle: misc: add array_size_dup script to detect missed overflow checks
> > +coccilib.report.print_report(p1[0],
> > +f"WARNING: array_size is used down the code (line {p2[0].line}) to compute
> > the same size")
>
> I get python failures for all of these messages.
This is interesting, isn't it?
> I know nothing about python.
You probably know more also about this programming language
than you express here.
> How is this supposed to work?
I suggest to take another look at information from the section
“2.4.3. Formatted string literals”.
https://docs.python.org/3/reference/lexical_analysis.html#f-strings
This software documentation provides the information “New in version 3.6”.
Will such a detail trigger any more software development consequences?
Regards,
Markus
Re: [PATCH v4 3/5] drm: panel: Add Xingbangda XBD599 panel (ST7703 controller)
Hello Sam, On Mon, Jun 22, 2020 at 10:08:02AM +0200, Sam Ravnborg wrote: > On Sun, Jun 21, 2020 at 12:30:10AM +0200, Ondřej Jirman wrote: > > On Sat, Jun 20, 2020 at 11:25:29PM +0200, Sam Ravnborg wrote: > > > Hi Ondrej et al. ... > > > Would it not be better to have one st7703 driver that suipports both > > > panels? > > > > > > The driver would need dedicated init functions depending on the panel. > > > But a lot could also be shared. > > > > I guess I can move the code there. > In the same process the river should then be renamed to follow other > sitronix based drivers. > So the next developer will recognize this and use the correct driver. Are driver/module names considered kernel ABI? Or is it possible to change them? regards, o.
Re: [PATCH v1 10/11] soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api
On 21/06/2020 16:18, Dennis YC Hsieh wrote:
> Add clear parameter to let client decide if
> event should be clear to 0 after GCE receive it.
>
> Signed-off-by: Dennis YC Hsieh
> Reviewed-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c |2 +-
> drivers/soc/mediatek/mtk-cmdq-helper.c |5 +++--
> include/linux/mailbox/mtk-cmdq-mailbox.h |3 +--
> include/linux/soc/mediatek/mtk-cmdq.h|5 +++--
> 4 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 7daaabc26eb1..a065b3a412cf 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -488,7 +488,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc
> *mtk_crtc)
> if (mtk_crtc->cmdq_client) {
> cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, PAGE_SIZE);
> cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
> - cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
> + cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false);
This does not set CMDQ_WFE_UPDATE while the old code did. Is this a bug fix or a
bug in the code?
If it's a fix, please provide a fixes tag.
Thanks,
Matthias
> mtk_crtc_ddp_config(crtc, cmdq_handle);
> cmdq_pkt_finalize(cmdq_handle);
> cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 009f86ae72c6..13f78c9b5901 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -315,15 +315,16 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt,
> u8 high_addr_reg_idx,
> }
> EXPORT_SYMBOL(cmdq_pkt_write_s_mask_value);
>
> -int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
> +int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear)
> {
> struct cmdq_instruction inst = { {0} };
> + u32 clear_option = clear ? CMDQ_WFE_UPDATE : 0;
>
> if (event >= CMDQ_MAX_EVENT)
> return -EINVAL;
>
> inst.op = CMDQ_CODE_WFE;
> - inst.value = CMDQ_WFE_OPTION;
> + inst.value = CMDQ_WFE_OPTION | clear_option;
> inst.event = event;
>
> return cmdq_pkt_append_command(pkt, inst);
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index 3f6bc0dfd5da..42d2a30e6a70 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -27,8 +27,7 @@
> * bit 16-27: update value
> * bit 31: 1 - update, 0 - no update
> */
> -#define CMDQ_WFE_OPTION (CMDQ_WFE_UPDATE |
> CMDQ_WFE_WAIT | \
> - CMDQ_WFE_WAIT_VALUE)
> +#define CMDQ_WFE_OPTION (CMDQ_WFE_WAIT |
> CMDQ_WFE_WAIT_VALUE)
>
> /** cmdq event maximum */
> #define CMDQ_MAX_EVENT 0x3ff
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 18364d81e8f7..4b5f5d154bad 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -182,11 +182,12 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt,
> u8 high_addr_reg_idx,
> /**
> * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
> * @pkt: the CMDQ packet
> - * @event: the desired event type to "wait and CLEAR"
> + * @event: the desired event type to wait
> + * @clear: clear event or not after event arrive
> *
> * Return: 0 for success; else the error code is returned
> */
> -int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
> +int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear);
>
> /**
> * cmdq_pkt_clear_event() - append clear event command to the CMDQ packet
>
Re: [PATCH v4 1/4] spi: spi-fsl-dspi: Fix lockup if device is removed during SPI transfer
On Mon, 22 Jun 2020 at 14:06, Krzysztof Kozlowski wrote:
>
> During device removal, the driver should unregister the SPI controller
> and stop the hardware. Otherwise the dspi_transfer_one_message() could
> wait on completion infinitely.
>
> Additionally, calling spi_unregister_controller() first in device
> removal reverse-matches the probe function, where SPI controller is
> registered at the end.
>
> Fixes: 05209f457069 ("spi: fsl-dspi: add missing clk_disable_unprepare() in
> dspi_remove()")
> Cc:
> Reported-by: Vladimir Oltean
> Signed-off-by: Krzysztof Kozlowski
>
> ---
Reviewed-by: Vladimir Oltean
Tested-by: Vladimir Oltean
>
> Changes since v3:
> 1. New patch.
> ---
> drivers/spi/spi-fsl-dspi.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> index 58190c94561f..ec0fd0d366eb 100644
> --- a/drivers/spi/spi-fsl-dspi.c
> +++ b/drivers/spi/spi-fsl-dspi.c
> @@ -1434,9 +1434,18 @@ static int dspi_remove(struct platform_device *pdev)
> struct fsl_dspi *dspi = spi_controller_get_devdata(ctlr);
>
> /* Disconnect from the SPI framework */
> + spi_unregister_controller(dspi->ctlr);
> +
> + /* Disable RX and TX */
> + regmap_update_bits(dspi->regmap, SPI_MCR,
> + SPI_MCR_DIS_TXF | SPI_MCR_DIS_RXF,
> + SPI_MCR_DIS_TXF | SPI_MCR_DIS_RXF);
> +
> + /* Stop Running */
> + regmap_update_bits(dspi->regmap, SPI_MCR, SPI_MCR_HALT, SPI_MCR_HALT);
> +
> dspi_release_dma(dspi);
> clk_disable_unprepare(dspi->clk);
> - spi_unregister_controller(dspi->ctlr);
>
> return 0;
> }
> --
> 2.17.1
>
Re: [PATCH v1 11/11] soc: mediatek: cmdq: add set event function
On 21/06/2020 16:18, Dennis YC Hsieh wrote:
> Add set event function in cmdq helper functions to set specific event.
>
> Signed-off-by: Dennis YC Hsieh
> ---
> drivers/soc/mediatek/mtk-cmdq-helper.c | 15 +++
> include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
> include/linux/soc/mediatek/mtk-cmdq.h|9 +
> 3 files changed, 25 insertions(+)
>
Applied to v5.8-next/soc
Thanks!
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index 13f78c9b5901..e6133a42d229 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -346,6 +346,21 @@ int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event)
> }
> EXPORT_SYMBOL(cmdq_pkt_clear_event);
>
> +int cmdq_pkt_set_event(struct cmdq_pkt *pkt, u16 event)
> +{
> + struct cmdq_instruction inst = {};
> +
> + if (event >= CMDQ_MAX_EVENT)
> + return -EINVAL;
> +
> + inst.op = CMDQ_CODE_WFE;
> + inst.value = CMDQ_WFE_UPDATE | CMDQ_WFE_UPDATE_VALUE;
> + inst.event = event;
> +
> + return cmdq_pkt_append_command(pkt, inst);
> +}
> +EXPORT_SYMBOL(cmdq_pkt_set_event);
> +
> int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
> u16 offset, u32 value)
> {
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index 42d2a30e6a70..ba2d811183a9 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -17,6 +17,7 @@
> #define CMDQ_JUMP_PASS CMDQ_INST_SIZE
>
> #define CMDQ_WFE_UPDATE BIT(31)
> +#define CMDQ_WFE_UPDATE_VALUEBIT(16)
> #define CMDQ_WFE_WAITBIT(15)
> #define CMDQ_WFE_WAIT_VALUE 0x1
>
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 4b5f5d154bad..960704d75994 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -199,6 +199,15 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8
> high_addr_reg_idx,
> int cmdq_pkt_clear_event(struct cmdq_pkt *pkt, u16 event);
>
> /**
> + * cmdq_pkt_set_event() - append set event command to the CMDQ packet
> + * @pkt: the CMDQ packet
> + * @event: the desired event to be set
> + *
> + * Return: 0 for success; else the error code is returned
> + */
> +int cmdq_pkt_set_event(struct cmdq_pkt *pkt, u16 event);
> +
> +/**
> * cmdq_pkt_poll() - Append polling command to the CMDQ packet, ask GCE to
> *execute an instruction that wait for a specified
> *hardware register to check for the value w/o mask.
>
Re: [PATCH AUTOSEL 5.7 004/388] ASoC: tegra: tegra_wm8903: Support nvidia, headset property
On Sun, Jun 21, 2020 at 07:33:52PM -0400, Sasha Levin wrote: > On Thu, Jun 18, 2020 at 03:39:30PM +0100, Mark Brown wrote: > > On Thu, Jun 18, 2020 at 10:30:46AM -0400, Sasha Levin wrote: > > > On Thu, Jun 18, 2020 at 12:00:23PM +0100, Mark Brown wrote: > > > > This is a new feature not a bugfix. > > > I saw this patch more as a hardware quirk. > > Pretty much any DT property is a hardware quirk :( > Which is why we're taking most of them :) That's concerning - please don't do this. It's not what stable is expected to be and there's no guarantee that you're getting all the changes required to actually make things work. signature.asc Description: PGP signature
Re: [v3] coccinelle: misc: add array_size_dup script to detect missed overflow checks
> I suggest to take another look at information from the section > “2.4.3. Formatted string literals”. > https://docs.python.org/3/reference/lexical_analysis.html#f-strings > > This software documentation provides the information “New in version 3.6”. > Will such a detail trigger any more software development consequences? Thanks foor this information. Denis, would it be possible to express the code in a more portable way? thanks, julia
RE: [PATCH v3] driver core: platform: expose numa_node to users in sysfs
> -Original Message-
> From: John Garry
> Sent: Monday, June 22, 2020 10:49 PM
> To: Song Bao Hua (Barry Song) ;
> gre...@linuxfoundation.org; raf...@kernel.org
> Cc: Robin Murphy ; linux-kernel@vger.kernel.org;
> Zengtao (B) ; Linuxarm
> Subject: Re: [PATCH v3] driver core: platform: expose numa_node to users in
> sysfs
>
> On 19/06/2020 04:00, Barry Song wrote:
> > Some platform devices like ARM SMMU are memory-mapped and populated
> by ACPI/IORT.
> > In this case, NUMA topology of those platform devices are exported by
> firmware as
> > well. Software might care about the numa_node of those devices in order to
> achieve
> > NUMA locality.
>
Thanks for your review, John.
> Is it generally the case that the SMMU will be in the same NUMA node as
> the endpoint device (which you're driving)? If so, we can get this info
This could be true, but I am not sure if it has to be true :-)
On the other hand, drivers/acpi/arm64/iort.c has some code to set numa node for
smmu.
It doesn't assume the numa_node is directly same with the pci devices.
static int __init arm_smmu_v3_set_proximity(struct device *dev,
struct acpi_iort_node *node)
{
struct acpi_iort_smmu_v3 *smmu;
smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
if (smmu->flags & ACPI_IORT_SMMU_V3_PXM_VALID) {
int dev_node = acpi_map_pxm_to_node(smmu->pxm);
if (dev_node != NUMA_NO_NODE && !node_online(dev_node))
return -EINVAL;
set_dev_node(dev, dev_node);
pr_info("SMMU-v3[%llx] Mapped to Proximity domain %d\n",
smmu->base_address,
smmu->pxm);
}
return 0;
}
numa_node may also extend to other platform devices once we provide a common
dev_set_proximity() callback to them.
iort_add_platform_device() will set node for them:
static int __init iort_add_platform_device(struct acpi_iort_node *node,
const struct iort_dev_config *ops)
{
struct fwnode_handle *fwnode;
struct platform_device *pdev;
struct resource *r;
int ret, count;
pdev = platform_device_alloc(ops->name, PLATFORM_DEVID_AUTO);
if (!pdev)
return -ENOMEM;
if (ops->dev_set_proximity) {
ret = ops->dev_set_proximity(&pdev->dev, node);
if (ret)
goto dev_put;
}
...
}
It is probably worth to make dev_set_proximity() common for all iort devices.
> from sysfs already for the endpoint, and also have a link from the
> endpoint to the iommu for pci devices (which I assume you're interested in):
>
> root@(none)$ ls -l /sys/devices/pci:74/:74:02.0/ | grep iommu
> lrwxrwxrwx 1 root root 0 Jun 22 10:33 iommu ->
> ../../platform/arm-smmu-v3.2.auto/iommu/smmu3.0x00014000
> lrwxrwxrwx 1 root root 0 Jun 22 10:33 iommu_group ->
> ../../../kernel/iommu_groups/0
> root@(none)$
Sure there is an implicit way to figure out the numa node of smmu by various
links between smmu
and devices which use the smmu if smmu and devices are luckily put in one same
numa node.
However, it is still much more clear and credible to users by exposing the data
directly from ACPI table.
>
> Thanks,
> John
Barry
[PATCH net 4/9] net: qed: fix NVMe login fails over VFs
25ms sleep cycles in waiting for PF response are excessive and may lead
to different timeout failures.
Start to wait with short udelays, and in most cases polling will end
here. If the time was not sufficient, switch to msleeps.
usleep_range() may go far beyond 100us depending on platform and tick
configuration, hence atomic udelays for consistency.
Also add explicit DMA barriers since 'done' always comes from a shared
request-response DMA pool, and note that in the comment nearby.
Fixes: 1408cc1fa48c ("qed: Introduce VFs")
Signed-off-by: Alexander Lobakin
Signed-off-by: Igor Russkikh
Signed-off-by: Michal Kalderon
---
drivers/net/ethernet/qlogic/qed/qed_vf.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_vf.c
b/drivers/net/ethernet/qlogic/qed/qed_vf.c
index 856051f50eb7..adc2c8f3d48e 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_vf.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_vf.c
@@ -81,12 +81,17 @@ static void qed_vf_pf_req_end(struct qed_hwfn *p_hwfn, int
req_status)
mutex_unlock(&(p_hwfn->vf_iov_info->mutex));
}
+#define QED_VF_CHANNEL_USLEEP_ITERATIONS 90
+#define QED_VF_CHANNEL_USLEEP_DELAY100
+#define QED_VF_CHANNEL_MSLEEP_ITERATIONS 10
+#define QED_VF_CHANNEL_MSLEEP_DELAY25
+
static int qed_send_msg2pf(struct qed_hwfn *p_hwfn, u8 *done, u32 resp_size)
{
union vfpf_tlvs *p_req = p_hwfn->vf_iov_info->vf2pf_request;
struct ustorm_trigger_vf_zone trigger;
struct ustorm_vf_zone *zone_data;
- int rc = 0, time = 100;
+ int iter, rc = 0;
zone_data = (struct ustorm_vf_zone *)PXP_VF_BAR0_START_USDM_ZONE_B;
@@ -126,11 +131,19 @@ static int qed_send_msg2pf(struct qed_hwfn *p_hwfn, u8
*done, u32 resp_size)
REG_WR(p_hwfn, (uintptr_t)&zone_data->trigger, *((u32 *)&trigger));
/* When PF would be done with the response, it would write back to the
-* `done' address. Poll until then.
+* `done' address from a coherent DMA zone. Poll until then.
*/
- while ((!*done) && time) {
- msleep(25);
- time--;
+
+ iter = QED_VF_CHANNEL_USLEEP_ITERATIONS;
+ while (!*done && iter--) {
+ udelay(QED_VF_CHANNEL_USLEEP_DELAY);
+ dma_rmb();
+ }
+
+ iter = QED_VF_CHANNEL_MSLEEP_ITERATIONS;
+ while (!*done && iter--) {
+ msleep(QED_VF_CHANNEL_MSLEEP_DELAY);
+ dma_rmb();
}
if (!*done) {
--
2.21.0
[PATCH net 6/9] net: qede: fix PTP initialization on recovery
Currently PTP cyclecounter and timecounter are initialized only on
the first probing and are cleaned up during removal. This means that
PTP becomes non-functional after device recovery.
Fix this by unconditional PTP initialization on probing and clearing
Tx pending bit on exiting.
Fixes: ccc67ef50b90 ("qede: Error recovery process")
Signed-off-by: Alexander Lobakin
Signed-off-by: Igor Russkikh
Signed-off-by: Michal Kalderon
---
drivers/net/ethernet/qlogic/qede/qede_main.c | 2 +-
drivers/net/ethernet/qlogic/qede/qede_ptp.c | 31
drivers/net/ethernet/qlogic/qede/qede_ptp.h | 2 +-
3 files changed, 15 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_main.c
b/drivers/net/ethernet/qlogic/qede/qede_main.c
index 756c05eb96f3..f6ff31e73ebe 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_main.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_main.c
@@ -1229,7 +1229,7 @@ static int __qede_probe(struct pci_dev *pdev, u32
dp_module, u8 dp_level,
/* PTP not supported on VFs */
if (!is_vf)
- qede_ptp_enable(edev, (mode == QEDE_PROBE_NORMAL));
+ qede_ptp_enable(edev);
edev->ops->register_ops(cdev, &qede_ll_ops, edev);
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ptp.c
b/drivers/net/ethernet/qlogic/qede/qede_ptp.c
index 4c7f7a7fc151..cd5841a9415e 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ptp.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ptp.c
@@ -412,6 +412,7 @@ void qede_ptp_disable(struct qede_dev *edev)
if (ptp->tx_skb) {
dev_kfree_skb_any(ptp->tx_skb);
ptp->tx_skb = NULL;
+ clear_bit_unlock(QEDE_FLAGS_PTP_TX_IN_PRORGESS, &edev->flags);
}
/* Disable PTP in HW */
@@ -423,7 +424,7 @@ void qede_ptp_disable(struct qede_dev *edev)
edev->ptp = NULL;
}
-static int qede_ptp_init(struct qede_dev *edev, bool init_tc)
+static int qede_ptp_init(struct qede_dev *edev)
{
struct qede_ptp *ptp;
int rc;
@@ -444,25 +445,19 @@ static int qede_ptp_init(struct qede_dev *edev, bool
init_tc)
/* Init work queue for Tx timestamping */
INIT_WORK(&ptp->work, qede_ptp_task);
- /* Init cyclecounter and timecounter. This is done only in the first
-* load. If done in every load, PTP application will fail when doing
-* unload / load (e.g. MTU change) while it is running.
-*/
- if (init_tc) {
- memset(&ptp->cc, 0, sizeof(ptp->cc));
- ptp->cc.read = qede_ptp_read_cc;
- ptp->cc.mask = CYCLECOUNTER_MASK(64);
- ptp->cc.shift = 0;
- ptp->cc.mult = 1;
-
- timecounter_init(&ptp->tc, &ptp->cc,
-ktime_to_ns(ktime_get_real()));
- }
+ /* Init cyclecounter and timecounter */
+ memset(&ptp->cc, 0, sizeof(ptp->cc));
+ ptp->cc.read = qede_ptp_read_cc;
+ ptp->cc.mask = CYCLECOUNTER_MASK(64);
+ ptp->cc.shift = 0;
+ ptp->cc.mult = 1;
- return rc;
+ timecounter_init(&ptp->tc, &ptp->cc, ktime_to_ns(ktime_get_real()));
+
+ return 0;
}
-int qede_ptp_enable(struct qede_dev *edev, bool init_tc)
+int qede_ptp_enable(struct qede_dev *edev)
{
struct qede_ptp *ptp;
int rc;
@@ -483,7 +478,7 @@ int qede_ptp_enable(struct qede_dev *edev, bool init_tc)
edev->ptp = ptp;
- rc = qede_ptp_init(edev, init_tc);
+ rc = qede_ptp_init(edev);
if (rc)
goto err1;
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ptp.h
b/drivers/net/ethernet/qlogic/qede/qede_ptp.h
index 691a14c4b2c5..89c7f3cf3ee2 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ptp.h
+++ b/drivers/net/ethernet/qlogic/qede/qede_ptp.h
@@ -41,7 +41,7 @@ void qede_ptp_rx_ts(struct qede_dev *edev, struct sk_buff
*skb);
void qede_ptp_tx_ts(struct qede_dev *edev, struct sk_buff *skb);
int qede_ptp_hw_ts(struct qede_dev *edev, struct ifreq *req);
void qede_ptp_disable(struct qede_dev *edev);
-int qede_ptp_enable(struct qede_dev *edev, bool init_tc);
+int qede_ptp_enable(struct qede_dev *edev);
int qede_ptp_get_ts_info(struct qede_dev *edev, struct ethtool_ts_info *ts);
static inline void qede_ptp_record_rx_ts(struct qede_dev *edev,
--
2.21.0
Re: [PATCH 0/3] Use MFD for Dallas/Maxim DS1374 driver series
Hi, On 22/06/2020 10:03:25+, Johnson CH Chen (陳昭勳) wrote: > Hello all, > > This patch set uses MFD structure for DS1374 so that RTC and Watchdog > functions can be separately. Therefore, we can add more Watchdog > subfunctions here. > > A DS1374 MFD core driver supports the I2C communication to RTC and > Watchdog devices. > > 1. Add DS1374 MFD core driver with I2C bus. > 2. Let DS1374 RTC driver has RTC and Alarm functions only. > 3. Add DS1374 Watchdog driver. > For reference, this was the last attempt: https://lore.kernel.org/linux-rtc/20170718092245.tc5oosbbb6lzvqpy@dell/ The main issue I see with your series is that there is no way to select which of the rtc or the watchdog driver has to be used as IIRC each function is mutually exclusive. I think you should work on the DT bindings, addressing the few remaining comments. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
[PATCH net 8/9] net: qed: reset ILT block sizes before recomputing to fix crashes
Sizes of all ILT blocks must be reset before ILT recomputing when
disabling clients, or memory allocation may exceed ILT shadow array
and provoke system crashes.
Fixes: 1408cc1fa48c ("qed: Introduce VFs")
Signed-off-by: Alexander Lobakin
Signed-off-by: Igor Russkikh
Signed-off-by: Michal Kalderon
---
drivers/net/ethernet/qlogic/qed/qed_cxt.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_cxt.c
b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
index c0a769b5358c..08ba9d54ab63 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_cxt.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
@@ -465,6 +465,20 @@ static struct qed_ilt_cli_blk *qed_cxt_set_blk(struct
qed_ilt_cli_blk *p_blk)
return p_blk;
}
+static void qed_cxt_ilt_blk_reset(struct qed_hwfn *p_hwfn)
+{
+ struct qed_ilt_client_cfg *clients = p_hwfn->p_cxt_mngr->clients;
+ u32 cli_idx, blk_idx;
+
+ for (cli_idx = 0; cli_idx < MAX_ILT_CLIENTS; cli_idx++) {
+ for (blk_idx = 0; blk_idx < ILT_CLI_PF_BLOCKS; blk_idx++)
+ clients[cli_idx].pf_blks[blk_idx].total_size = 0;
+
+ for (blk_idx = 0; blk_idx < ILT_CLI_VF_BLOCKS; blk_idx++)
+ clients[cli_idx].vf_blks[blk_idx].total_size = 0;
+ }
+}
+
int qed_cxt_cfg_ilt_compute(struct qed_hwfn *p_hwfn, u32 *line_count)
{
struct qed_cxt_mngr *p_mngr = p_hwfn->p_cxt_mngr;
@@ -484,6 +498,11 @@ int qed_cxt_cfg_ilt_compute(struct qed_hwfn *p_hwfn, u32
*line_count)
p_mngr->pf_start_line = RESC_START(p_hwfn, QED_ILT);
+ /* Reset all ILT blocks at the beginning of ILT computing in order
+* to prevent memory allocation for irrelevant blocks afterwards.
+*/
+ qed_cxt_ilt_blk_reset(p_hwfn);
+
DP_VERBOSE(p_hwfn, QED_MSG_ILT,
"hwfn [%d] - Set context manager starting line to be
0x%08x\n",
p_hwfn->my_id, p_hwfn->p_cxt_mngr->pf_start_line);
--
2.21.0
Re: [PATCH v5 6/6] arm64: dts: add dts nodes for MT6779
On 16/06/2020 15:34, Hanks Chen wrote:
> On Wed, 2020-03-25 at 17:39 +0100, Matthias Brugger wrote:
>>
>> On 25/03/2020 10:31, Hanks Chen wrote:
>>> this adds initial MT6779 dts settings fo board support,
>>
>> "for board support"
>>
>>> including cpu, gic, timer, ccf, pinctrl, uart...etc.
>>
>> The etc is PMU and PSCI and sysirq, correct? Let's list at least sysirq as
>> this
>> is something MediaTek specific.
>>
>>>
>>> Signed-off-by: Hanks Chen
>>> ---
>>> arch/arm64/boot/dts/mediatek/Makefile |1 +
>>> arch/arm64/boot/dts/mediatek/mt6779-evb.dts | 31
>>> arch/arm64/boot/dts/mediatek/mt6779.dtsi| 265
>>> +++
>>> 3 files changed, 297 insertions(+)
>>> create mode 100644 arch/arm64/boot/dts/mediatek/mt6779-evb.dts
>>> create mode 100644 arch/arm64/boot/dts/mediatek/mt6779.dtsi
>>>
>>> diff --git a/arch/arm64/boot/dts/mediatek/Makefile
>>> b/arch/arm64/boot/dts/mediatek/Makefile
>>> index 458bbc4..53f1c61 100644
>>> --- a/arch/arm64/boot/dts/mediatek/Makefile
>>> +++ b/arch/arm64/boot/dts/mediatek/Makefile
>>> @@ -1,6 +1,7 @@
>>> # SPDX-License-Identifier: GPL-2.0
>>> dtb-$(CONFIG_ARCH_MEDIATEK) += mt2712-evb.dtb
>>> dtb-$(CONFIG_ARCH_MEDIATEK) += mt6755-evb.dtb
>>> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt6779-evb.dtb
>>> dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
>>> dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
>>> dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-x20-dev.dtb
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt6779-evb.dts
>>> b/arch/arm64/boot/dts/mediatek/mt6779-evb.dts
>>> new file mode 100644
>>> index 000..164f5cb
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/mediatek/mt6779-evb.dts
>>> @@ -0,0 +1,31 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * Copyright (c) 2019 MediaTek Inc.
>>> + * Author: Mars.C
>>> + *
>>> + */
>>> +
>>> +/dts-v1/;
>>> +#include "mt6779.dtsi"
>>> +
>>> +/ {
>>> + model = "MediaTek MT6779 EVB";
>>> + compatible = "mediatek,mt6779-evb", "mediatek,mt6779";
>>> +
>>> + aliases {
>>> + serial0 = &uart0;
>>> + };
>>> +
>>> + memory@4000 {
>>> + device_type = "memory";
>>> + reg = <0 0x4000 0 0x1e80>;
>>> + };
>>> +
>>> + chosen {
>>> + stdout-path = "serial0:921600n8";
>>> + };
>>> +};
>>> +
>>> +&uart0 {
>>> + status = "okay";
>>> +};
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt6779.dtsi
>>> b/arch/arm64/boot/dts/mediatek/mt6779.dtsi
>>> new file mode 100644
>>> index 000..422ff5f
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/mediatek/mt6779.dtsi
>>> @@ -0,0 +1,265 @@
>> [...]
>>> +
>>> + uart_clk: dummy26m {
>>> + compatible = "fixed-clock";
>>> + clock-frequency = <2600>;
>>> + #clock-cells = <0>;
>>> + };
>>
>> No real clocks for uart? What about CLK_INFRA_UARTx?
>
> sorry, I miss the clocks for uart
> I'll add "baud" and "bus" in next version.
>
> clocks = <&clk26m>, <&infracfg_ao CLK_INFRA_UART0>;
> clock-names = "baud", "bus";
>
>
>>
>>> +
>>> + timer {
>>> + compatible = "arm,armv8-timer";
>>> + interrupt-parent = <&gic>;
>>> + interrupts = ,
>>> +,
>>> +,
>>> +;
>>> + };
>>> +
>>> + soc {
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> + compatible = "simple-bus";
>>> + ranges;
>>> +
>> [...]
>>> +
>>> + uart0: serial@11002000 {
>>> + compatible = "mediatek,mt6779-uart",
>>> +"mediatek,mt6577-uart";
>>> + reg = <0 0x11002000 0 0x400>;
>>> + interrupts = ;
>>> + clocks = <&uart_clk>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + uart1: serial@11003000 {
>>> + compatible = "mediatek,mt6779-uart",
>>> +"mediatek,mt6577-uart";
>>> + reg = <0 0x11003000 0 0x400>;
>>> + interrupts = ;
>>> + clocks = <&uart_clk>;
>>> + status = "disabled";
>>> + };
>>
>> SoC has only two UARTs but clock driver has three, how comes?
>>
>
> In mt6779 SoC, we have four UARTs.
> but we only use UART0 and UART1 as standard serial ports for APMCU.The
> others for modem side.
> so we add two UARTs in dts.
>
Sorry for the late reply.
DTS describes the HW, so we should add all four to the mt6779.dtsi but only
enable the one that can be used.
BTW I thought modem works through user space application, so why don't you want
to expose them?
Regards,
Matthias
>>> +
>>> + audio: clock-controller@1121 {
>>> + compatible = "mediatek,mt6779-audio", "syscon";
>>> + reg = <0 0x1121 0 0x1000>;
>>> + #clock-cells = <1>;
>>> + };
>>> +
>>> + mfgcfg: clock-controller@13fbf000 {
>>> +
[PATCH net 7/9] net: qede: fix use-after-free on recovery and AER handling
Set edev->cdev pointer to NULL after calling remove() callback to avoid
using of already freed object.
Fixes: ccc67ef50b90 ("qede: Error recovery process")
Signed-off-by: Alexander Lobakin
Signed-off-by: Igor Russkikh
Signed-off-by: Michal Kalderon
---
drivers/net/ethernet/qlogic/qede/qede_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_main.c
b/drivers/net/ethernet/qlogic/qede/qede_main.c
index f6ff31e73ebe..29e285430f99 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_main.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_main.c
@@ -1318,6 +1318,7 @@ static void __qede_remove(struct pci_dev *pdev, enum
qede_remove_mode mode)
if (system_state == SYSTEM_POWER_OFF)
return;
qed_ops->common->remove(cdev);
+ edev->cdev = NULL;
/* Since this can happen out-of-sync with other flows,
* don't release the netdevice until after slowpath stop
--
2.21.0
[PATCH net 3/9] net: qede: stop adding events on an already destroyed workqueue
Set rdma_wq pointer to NULL after destroying the workqueue and check
for it when adding new events to fix crashes on driver unload.
Fixes: cee9fbd8e2e9 ("qede: Add qedr framework")
Signed-off-by: Alexander Lobakin
Signed-off-by: Igor Russkikh
Signed-off-by: Michal Kalderon
---
drivers/net/ethernet/qlogic/qede/qede_rdma.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_rdma.c
b/drivers/net/ethernet/qlogic/qede/qede_rdma.c
index 2d873ae8a234..668ccc9d49f8 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_rdma.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_rdma.c
@@ -105,6 +105,7 @@ static void qede_rdma_destroy_wq(struct qede_dev *edev)
qede_rdma_cleanup_event(edev);
destroy_workqueue(edev->rdma_info.rdma_wq);
+ edev->rdma_info.rdma_wq = NULL;
}
int qede_rdma_dev_add(struct qede_dev *edev, bool recovery)
@@ -325,7 +326,7 @@ static void qede_rdma_add_event(struct qede_dev *edev,
if (edev->rdma_info.exp_recovery)
return;
- if (!edev->rdma_info.qedr_dev)
+ if (!edev->rdma_info.qedr_dev || !edev->rdma_info.rdma_wq)
return;
/* We don't want the cleanup flow to start while we're allocating and
--
2.21.0
[PATCH net 2/9] net: qed: fix async event callbacks unregistering
qed_spq_unregister_async_cb() should be called before
qed_rdma_info_free() to avoid crash-spawning uses-after-free.
Instead of calling it from each subsystem exit code, do it in one place
on PF down.
Fixes: 291d57f67d24 ("qed: Fix rdma_info structure allocation")
Signed-off-by: Alexander Lobakin
Signed-off-by: Igor Russkikh
Signed-off-by: Michal Kalderon
---
drivers/net/ethernet/qlogic/qed/qed_dev.c | 9 +++--
drivers/net/ethernet/qlogic/qed/qed_iwarp.c | 2 --
drivers/net/ethernet/qlogic/qed/qed_roce.c | 1 -
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c
b/drivers/net/ethernet/qlogic/qed/qed_dev.c
index 1eebf30fa798..b41ada668948 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_dev.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c
@@ -1368,6 +1368,8 @@ static void qed_dbg_user_data_free(struct qed_hwfn
*p_hwfn)
void qed_resc_free(struct qed_dev *cdev)
{
+ struct qed_rdma_info *rdma_info;
+ struct qed_hwfn *p_hwfn;
int i;
if (IS_VF(cdev)) {
@@ -1385,7 +1387,8 @@ void qed_resc_free(struct qed_dev *cdev)
qed_llh_free(cdev);
for_each_hwfn(cdev, i) {
- struct qed_hwfn *p_hwfn = &cdev->hwfns[i];
+ p_hwfn = cdev->hwfns + i;
+ rdma_info = p_hwfn->p_rdma_info;
qed_cxt_mngr_free(p_hwfn);
qed_qm_info_free(p_hwfn);
@@ -1404,8 +1407,10 @@ void qed_resc_free(struct qed_dev *cdev)
qed_ooo_free(p_hwfn);
}
- if (QED_IS_RDMA_PERSONALITY(p_hwfn))
+ if (QED_IS_RDMA_PERSONALITY(p_hwfn) && rdma_info) {
+ qed_spq_unregister_async_cb(p_hwfn, rdma_info->proto);
qed_rdma_info_free(p_hwfn);
+ }
qed_iov_free(p_hwfn);
qed_l2_free(p_hwfn);
diff --git a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
index d2fe61a5cf56..5409a2da6106 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_iwarp.c
@@ -2836,8 +2836,6 @@ int qed_iwarp_stop(struct qed_hwfn *p_hwfn)
if (rc)
return rc;
- qed_spq_unregister_async_cb(p_hwfn, PROTOCOLID_IWARP);
-
return qed_iwarp_ll2_stop(p_hwfn);
}
diff --git a/drivers/net/ethernet/qlogic/qed/qed_roce.c
b/drivers/net/ethernet/qlogic/qed/qed_roce.c
index 4566815f7b87..7271dd7166e5 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_roce.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_roce.c
@@ -113,7 +113,6 @@ void qed_roce_stop(struct qed_hwfn *p_hwfn)
break;
}
}
- qed_spq_unregister_async_cb(p_hwfn, PROTOCOLID_ROCE);
}
static void qed_rdma_copy_gids(struct qed_rdma_qp *qp, __le32 *src_gid,
--
2.21.0
[PATCH net 1/9] net: qed: fix left elements count calculation
qed_chain_get_element_left{,_u32} returned 0 when the difference
between producer and consumer page count was equal to the total
page count.
Fix this by conditional expanding of producer value (vs
unconditional). This allowed to eliminate normalizaton against
total page count, which was the cause of this bug.
Misc: replace open-coded constants with common defines.
Fixes: a91eb52abb50 ("qed: Revisit chain implementation")
Signed-off-by: Alexander Lobakin
Signed-off-by: Igor Russkikh
Signed-off-by: Michal Kalderon
---
include/linux/qed/qed_chain.h | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/include/linux/qed/qed_chain.h b/include/linux/qed/qed_chain.h
index 733fad7dfbed..6d15040c642c 100644
--- a/include/linux/qed/qed_chain.h
+++ b/include/linux/qed/qed_chain.h
@@ -207,28 +207,34 @@ static inline u32 qed_chain_get_cons_idx_u32(struct
qed_chain *p_chain)
static inline u16 qed_chain_get_elem_left(struct qed_chain *p_chain)
{
+ u16 elem_per_page = p_chain->elem_per_page;
+ u32 prod = p_chain->u.chain16.prod_idx;
+ u32 cons = p_chain->u.chain16.cons_idx;
u16 used;
- used = (u16) (((u32)0x1 +
- (u32)p_chain->u.chain16.prod_idx) -
- (u32)p_chain->u.chain16.cons_idx);
+ if (prod < cons)
+ prod += (u32)U16_MAX + 1;
+
+ used = (u16)(prod - cons);
if (p_chain->mode == QED_CHAIN_MODE_NEXT_PTR)
- used -= p_chain->u.chain16.prod_idx / p_chain->elem_per_page -
- p_chain->u.chain16.cons_idx / p_chain->elem_per_page;
+ used -= prod / elem_per_page - cons / elem_per_page;
return (u16)(p_chain->capacity - used);
}
static inline u32 qed_chain_get_elem_left_u32(struct qed_chain *p_chain)
{
+ u16 elem_per_page = p_chain->elem_per_page;
+ u64 prod = p_chain->u.chain32.prod_idx;
+ u64 cons = p_chain->u.chain32.cons_idx;
u32 used;
- used = (u32) (((u64)0x1ULL +
- (u64)p_chain->u.chain32.prod_idx) -
- (u64)p_chain->u.chain32.cons_idx);
+ if (prod < cons)
+ prod += (u64)U32_MAX + 1;
+
+ used = (u32)(prod - cons);
if (p_chain->mode == QED_CHAIN_MODE_NEXT_PTR)
- used -= p_chain->u.chain32.prod_idx / p_chain->elem_per_page -
- p_chain->u.chain32.cons_idx / p_chain->elem_per_page;
+ used -= (u32)(prod / elem_per_page - cons / elem_per_page);
return p_chain->capacity - used;
}
--
2.21.0
Re: [PATCH 1/2] exec: Don't set group_exit_task during a coredump
On 06/19, Eric W. Biederman wrote:
>
> --- a/fs/coredump.c
> +++ b/fs/coredump.c
> @@ -369,7 +369,6 @@ static int zap_threads(struct task_struct *tsk, struct
> mm_struct *mm,
> spin_lock_irq(&tsk->sighand->siglock);
> if (!signal_group_exit(tsk->signal)) {
> mm->core_state = core_state;
> - tsk->signal->group_exit_task = tsk;
> nr = zap_process(tsk, exit_code, 0);
> clear_tsk_thread_flag(tsk, TIF_SIGPENDING);
> }
> @@ -481,7 +480,6 @@ static void coredump_finish(struct mm_struct *mm, bool
> core_dumped)
> spin_lock_irq(¤t->sighand->siglock);
> if (core_dumped && !__fatal_signal_pending(current))
> current->signal->group_exit_code |= 0x80;
> - current->signal->group_exit_task = NULL;
> current->signal->flags = SIGNAL_GROUP_EXIT;
> spin_unlock_irq(¤t->sighand->siglock);
>
> diff --git a/include/linux/sched/signal.h b/include/linux/sched/signal.h
> index 0ee5e696c5d8..92c72f5db111 100644
> --- a/include/linux/sched/signal.h
> +++ b/include/linux/sched/signal.h
> @@ -265,7 +265,7 @@ static inline void signal_set_stop_flags(struct
> signal_struct *sig,
> /* If true, all threads except ->group_exit_task have pending SIGKILL */
> static inline int signal_group_exit(const struct signal_struct *sig)
> {
> - return (sig->flags & SIGNAL_GROUP_EXIT) ||
> + return (sig->flags & (SIGNAL_GROUP_EXIT | SIGNAL_GROUP_COREDUMP)) ||
> (sig->group_exit_task != NULL);
> }
Looks correct.
Oleg.
Re: [PATCH v6 7/7] arm64: dts: add dts nodes for MT6779
On 18/06/2020 13:33, Hanks Chen wrote:
> this adds initial MT6779 dts settings for board support,
> including cpu, gic, timer, ccf, pinctrl, uart, sysirq...etc.
>
> Signed-off-by: Hanks Chen
> ---
> arch/arm64/boot/dts/mediatek/Makefile |1 +
> arch/arm64/boot/dts/mediatek/mt6779-evb.dts | 31
> arch/arm64/boot/dts/mediatek/mt6779.dtsi| 261
> +++
> 3 files changed, 293 insertions(+)
> create mode 100644 arch/arm64/boot/dts/mediatek/mt6779-evb.dts
> create mode 100644 arch/arm64/boot/dts/mediatek/mt6779.dtsi
>
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile
> b/arch/arm64/boot/dts/mediatek/Makefile
> index a57af9d..4d1b0f9 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt2712-evb.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt6755-evb.dtb
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt6779-evb.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
> dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-x20-dev.dtb
> diff --git a/arch/arm64/boot/dts/mediatek/mt6779-evb.dts
> b/arch/arm64/boot/dts/mediatek/mt6779-evb.dts
> new file mode 100644
> index 000..164f5cb
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt6779-evb.dts
> @@ -0,0 +1,31 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2019 MediaTek Inc.
> + * Author: Mars.C
> + *
> + */
> +
> +/dts-v1/;
> +#include "mt6779.dtsi"
> +
> +/ {
> + model = "MediaTek MT6779 EVB";
> + compatible = "mediatek,mt6779-evb", "mediatek,mt6779";
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + memory@4000 {
> + device_type = "memory";
> + reg = <0 0x4000 0 0x1e80>;
> + };
> +
> + chosen {
> + stdout-path = "serial0:921600n8";
> + };
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt6779.dtsi
> b/arch/arm64/boot/dts/mediatek/mt6779.dtsi
> new file mode 100644
> index 000..64e5963
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt6779.dtsi
> @@ -0,0 +1,261 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2019 MediaTek Inc.
> + * Author: Mars.C
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +/ {
> + compatible = "mediatek,mt6779";
> + interrupt-parent = <&sysirq>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a55";
> + enable-method = "psci";
> + reg = <0x000>;
> + };
> +
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a55";
> + enable-method = "psci";
> + reg = <0x100>;
> + };
> +
> + cpu2: cpu@2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a55";
> + enable-method = "psci";
> + reg = <0x200>;
> + };
> +
> + cpu3: cpu@3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a55";
> + enable-method = "psci";
> + reg = <0x300>;
> + };
> +
> + cpu4: cpu@4 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a55";
> + enable-method = "psci";
> + reg = <0x400>;
> + };
> +
> + cpu5: cpu@5 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a55";
> + enable-method = "psci";
> + reg = <0x500>;
> + };
> +
> + cpu6: cpu@6 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a75";
> + enable-method = "psci";
> + reg = <0x600>;
> + };
> +
> + cpu7: cpu@7 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a75";
> + enable-method = "psci";
> + reg = <0x700>;
> + };
> + };
> +
> + pmu {
> + compatible = "arm,armv8-pmuv3";
> + interrupt-parent = <&gic>;
> + interrupts = ;
> + };
> +
> + clk26m: oscillator@0 {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <2600>;
>
Re: [PATCH] kernel/signal.c: Export symbol __lock_task_sighand
On 06/22, Dominique Martinet wrote: > > What about the possibility of sighand being null that the function does > check, is that impossible for current as well? It is only possible if "current" has already exited and passed exit_notify(), iow if it is already a zombie and can be (auto)reaped. Oleg.
Writing to a const pointer: is this supposed to happen?
In the file drivers/usb/core/quirks.c, I noticed a couple of odd things about
the function "quirks_param_set", and I'd like to check whether those are ok
according to the kernel programming practices. Here are the relevant lines from
the function (several lines omitted):
static int quirks_param_set(const char *val, const struct kernel_param
*kp) {
char *p, *field;
for (i = 0, p = (char *)val; p && *p;) {
field = strsep(&p, ":");
if (!field)
break;
In here a const pointer *val is cast into a non-const pointer and then written
to by the function strsep, which replaces the first occurrence of the ':' token
by a null-byte. Is this allowed?
On a minor side note, this function immediately checks whether the first call
to strsep(&p, ":") returned a nullpointer. From what I can learn from the
documentation, strsep always returns what *&p was when the strsep was called,
and p is verified to be nonzero in the loop condition right before the call to
strsep. Is this check actually necessary? Is it a good idea to add a
return-value check anyway even if it is not necessary, as an abundance of
caution?
Re: [PATCH] kernel/signal.c: Export symbol __lock_task_sighand
On Mon, Jun 22, 2020 at 12:24:01PM +0200, Dominique Martinet wrote: > Christian Brauner wrote on Mon, Jun 22, 2020: > > On Mon, Jun 22, 2020 at 08:25:28AM +0200, Oleg Nesterov wrote: > >> current->sighand is stable and can't go away. Unless "current" is exiting > >> and > >> has already passed exit_notify(). So I don't think net/9p needs this > >> helper. > > > > From what I can gather from the thread (cf. [1]) that is linked in the > > commit message the main motivation for all of this is sparse not being > > happy and not some bug. (Maybe I'm not seeing something though.) > > > > The patch itself linked here doesn't seem to buy anything. I agree with > > Oleg. Afaict, lock_task_sighand() would only be needed here if the task > > wouldn't be current. So maybe it should just be dropped from the series. > > Sure. I honestly have no idea on what guarantees we have from the task > being current here as opposed to any other task -- I guess that another > thread calling exit for exemple would have to wait? When a thread in a non-trivial thread-group (sorry for the math reference :)) execs it'll unshare its struct sighand. The new struct sighand will be assigned using rcu_assign_pointer() so afaik (Paul or Oleg can yell at me if I'm talking nonsense) any prior callers will see the prior sighand value. > What about the possibility of sighand being null that the function does > check, is that impossible for current as well? See above, I think that's impossible. > > > Honestly not a part of the code I'm much familiar with, this all > predates my involvement with 9p by a fair bit... We can't be experts in everything. :) Christian
Re: [PATCH] soundwire: bus: clock_stop: don't deal with UNATTACHED Slave devices
On 31-05-20, 23:18, Bard Liao wrote: > We don't need to do anything for the slave if it is unattached during > clock stop prepare and exit sequences. Applied, thanks -- ~Vinod
Re: Good idea to rename files in include/uapi/ ?
On Monday 2020-06-15 01:34, Alexander A. Klimov wrote: >> >> A header file rename is no problem. We even have dummy headers > Hmm.. if I understand all of you correctly, David, Stefano, Pablo and Al say > like no, not a good idea, but only you, Jan, say like should be no problem. > > Jan, do you have anything like commit messages in mainline or public emails > from maintainers confirming your opinion? I had already given the commit with the (email) message: >> Just look at xt_MARK.h, all it does is include xt_mark.h. Cf. >> 28b949885f80efb87d7cebdcf879c99db12c37bd .
[PATCH RESEND v2] dt-bindings: pinctrl: Convert ingenic,pinctrl.txt to YAML
Convert the ingenic,pinctrl.txt doc file to ingenic,pinctrl.yaml.
In the process, some compatible strings now require a fallback, as the
corresponding SoCs are pin-compatible with their fallback variant.
Signed-off-by: Paul Cercueil
---
Notes:
v2: - Use 'pinctrl' instead of 'pin-controller' as the node name
- remove 'additionalProperties: false' since we will have pin conf nodes
.../bindings/pinctrl/ingenic,pinctrl.txt | 81 ---
.../bindings/pinctrl/ingenic,pinctrl.yaml | 136 ++
2 files changed, 136 insertions(+), 81 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt
create mode 100644
Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
diff --git a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt
deleted file mode 100644
index d9b2100c98e8..
--- a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt
+++ /dev/null
@@ -1,81 +0,0 @@
-Ingenic XBurst pin controller
-
-Please refer to pinctrl-bindings.txt in this directory for details of the
-common pinctrl bindings used by client devices, including the meaning of the
-phrase "pin configuration node".
-
-For the XBurst SoCs, pin control is tightly bound with GPIO ports. All pins may
-be used as GPIOs, multiplexed device functions are configured within the
-GPIO port configuration registers and it is typical to refer to pins using the
-naming scheme "PxN" where x is a character identifying the GPIO port with
-which the pin is associated and N is an integer from 0 to 31 identifying the
-pin within that GPIO port. For example PA0 is the first pin in GPIO port A, and
-PB31 is the last pin in GPIO port B. The jz4740, the x1000 and the x1830
-contains 4 GPIO ports, PA to PD, for a total of 128 pins. The jz4760, the
-jz4770 and the jz4780 contains 6 GPIO ports, PA to PF, for a total of 192 pins.
-
-
-Required properties:
-
-
- - compatible: One of:
-- "ingenic,jz4740-pinctrl"
-- "ingenic,jz4725b-pinctrl"
-- "ingenic,jz4760-pinctrl"
-- "ingenic,jz4760b-pinctrl"
-- "ingenic,jz4770-pinctrl"
-- "ingenic,jz4780-pinctrl"
-- "ingenic,x1000-pinctrl"
-- "ingenic,x1000e-pinctrl"
-- "ingenic,x1500-pinctrl"
-- "ingenic,x1830-pinctrl"
- - reg: Address range of the pinctrl registers.
-
-
-Required properties for sub-nodes (GPIO chips):
-
- - compatible: Must contain one of:
-- "ingenic,jz4740-gpio"
-- "ingenic,jz4760-gpio"
-- "ingenic,jz4770-gpio"
-- "ingenic,jz4780-gpio"
-- "ingenic,x1000-gpio"
-- "ingenic,x1830-gpio"
- - reg: The GPIO bank number.
- - interrupt-controller: Marks the device node as an interrupt controller.
- - interrupts: Interrupt specifier for the controllers interrupt.
- - #interrupt-cells: Should be 2. Refer to
- ../interrupt-controller/interrupts.txt for more details.
- - gpio-controller: Marks the device node as a GPIO controller.
- - #gpio-cells: Should be 2. The first cell is the GPIO number and the second
-cell specifies GPIO flags, as defined in . Only
the
-GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
- - gpio-ranges: Range of pins managed by the GPIO controller. Refer to
- ../gpio/gpio.txt for more details.
-
-
-Example:
-
-
-pinctrl: pin-controller@1001 {
- compatible = "ingenic,jz4740-pinctrl";
- reg = <0x1001 0x400>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- gpa: gpio@0 {
- compatible = "ingenic,jz4740-gpio";
- reg = <0>;
-
- gpio-controller;
- gpio-ranges = <&pinctrl 0 0 32>;
- #gpio-cells = <2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
-
- interrupt-parent = <&intc>;
- interrupts = <28>;
- };
-};
diff --git a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
new file mode 100644
index ..5be2b1e95b36
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
@@ -0,0 +1,136 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/ingenic,pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ingenic SoCs pin controller devicetree bindings
+
+description: >
+ Please refer to pinctrl-bindings.txt in this directory for details of the
+ common pinctrl bindings used by client devices, including the meaning of the
+ phrase "pin configuration node".
+
+ For the Ingenic SoCs, pin control is tightly bound with GPIO ports. All pins
+ may be used as GPIOs, multiplexed device functions are configured within the
+ GPIO port configuration registers and it is typical to refer to pins using
the
+ namin
Re: [PATCH] soc: qcom: rpmh-rsc: Set suppress_bind_attrs flag
Hi, Thanks for the review Stephen. On 6/22/2020 2:33 PM, Stephen Boyd wrote: Quoting Maulik Shah (2020-06-21 23:53:25) rpmh-rsc driver is fairly core to system and should not be removable once its probed. However it allows to unbind driver from sysfs using below command which results into a crash on sc7180. What is the crash? The world falls apart because rpmh APIs start referencing pointers that point to freed memory? Yes. echo 1820.rsc > /sys/bus/platform/drivers/rpmh/unbind Lets prevent unbind at runtime by setting suppress_bind_attrs flag. Ok. But when the Android module brigade comes knocking they'll have to revert this change and solve this problem too. Have fun! No should not need to revert this change. Even if rpmh-rsc is planned to be loadable module for android, Once loaded it should be disallowed to be removed. same is the case for PDC irqchip as well. these drivers are core to the system and shouldn't be allowed to rmmod/unbind. Thanks, Maulik Signed-off-by: Maulik Shah --- Reviewed-by: Stephen Boyd -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[GIT PULL] regmap fixes for v5.8-rc2
The following changes since commit 93b929922dba3a42b0439ef13144c6032b7733c8: Merge series "regmap: provide simple bitops and use them in a driver" from Bartosz Golaszewski Bartosz Golaszewski : (2020-05-29 14:00:44 +0100) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git tags/regmap-fix-v5.8-rc2 for you to fetch changes up to 95b2c3ec4cb1689db2389c251d39f64490ba641c: regmap: Fix memory leak from regmap_register_patch (2020-06-17 17:12:11 +0100) regmap: Fixes for v5.8 A few small fixes, none of which are likely to have any substantial impact here - the most substantial one is a fix for a long standing memory leak on devices that use register patching which will only have an impact if the device is removed and re-added. Bartosz Golaszewski (1): regmap: fix the kerneldoc for regmap_test_bits() Charles Keepax (1): regmap: Fix memory leak from regmap_register_patch Jens Thoms Toerring (1): regmap: fix alignment issue drivers/base/regmap/regmap.c | 106 --- 1 file changed, 50 insertions(+), 56 deletions(-)
Re: [PATCH 2/2] Add Intel LGM soc DMA support.
Hi Amireddy,
url:
https://github.com/0day-ci/linux/commits/Amireddy-Mallikarjuna-reddy/Add-Intel-LGM-soc-DMA-support/20200610-202116
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: i386-randconfig-m021-20200621 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Reported-by: Dan Carpenter
smatch warnings:
drivers/dma/lgm/lgm-dma.c:1306 ldma_cfg_init() error: uninitialized symbol
'ret'.
#
https://github.com/0day-ci/linux/commit/23493bf02c8f7255c8ff22b02f42f0adccb8e8ad
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 23493bf02c8f7255c8ff22b02f42f0adccb8e8ad
vim +/ret +1306 drivers/dma/lgm/lgm-dma.c
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1198 static int
ldma_cfg_init(struct ldma_dev *d)
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1199 {
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1200 struct
fwnode_handle *fwnode = dev_fwnode(d->dev);
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1201 struct
fwnode_handle *fw_chans, *fw_chan;
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1202 struct
fwnode_handle *fw_ports, *fw_port;
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1203 struct
ldma_chan *c;
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1204 struct
ldma_port *p;
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1205 u32 txendi,
rxendi;
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1206 u32 prop, val;
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1207 int ret, i;
^^^
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1208
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1209 if
(fwnode_property_read_bool(fwnode, "intel,dma-chan-fc"))
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1210
d->flags |= DMA_CHAN_FLOW_CTL;
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1211
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1212 if
(fwnode_property_read_bool(fwnode, "intel,dma-desc-fod"))
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1213
d->flags |= DMA_DESC_FTOD;
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1214
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1215 if
(fwnode_property_read_bool(fwnode, "intel,dma-desc-in-sram"))
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1216
d->flags |= DMA_DESC_IN_SRAM;
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1217
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1218 if
(fwnode_property_read_bool(fwnode, "intel,dma-byte-en"))
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1219
d->flags |= DMA_EN_BYTE_EN;
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1220
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1221 if
(fwnode_property_read_bool(fwnode, "intel,dma-dfetch-ack"))
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1222
d->flags |= DMA_VLD_FETCH_ACK;
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1223
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1224 if
(fwnode_property_read_bool(fwnode, "intel,dma-dburst-wr"))
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1225
d->flags |= DMA_DBURST_WR;
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1226
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1227 if
(fwnode_property_read_bool(fwnode, "intel,dma-drb"))
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1228
d->flags |= DMA_DFT_DRB;
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1229
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1230 if
(fwnode_property_read_u32(fwnode, "intel,dma-polling-cnt",
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1231
&d->pollcnt))
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1232
d->pollcnt = DMA_DFT_POLL_CNT;
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1233
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1234 if
(!fwnode_property_read_u32(fwnode, "intel,dma-orrc", &val)) {
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1235 if (val
> DMA_ORRC_MAX_CNT)
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1236
return -EINVAL;
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1237 d->orrc
= val;
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1238 }
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1239
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1240 if (d->ver >
DMA_VER22) {
23493bf02c8f72 Amireddy Mallikarjuna reddy 2020-06-10 1241 if
[GIT PULL] regulator fixes for v5.8-rc2
The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407: Linux 5.8-rc1 (2020-06-14 12:45:04 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git tags/regulator-fix-v5.8-rc2 for you to fetch changes up to 1b3bcca2085865c1facfbea9baf2f5cde5dc15e4: regulator: mt6358: Remove BROKEN dependency (2020-06-17 13:01:19 +0100) regulator: Fixes for v5.8 This has a fix for the refactoring out of the pickable ranges functionality, plus the removal of a BROKEN dependency on mt6358 now that the dependencies were merged in -rc1 and a couple of device specific fixes. Axel Lin (1): regulator: mt6358: Remove BROKEN dependency Mark Brown (1): Merge tag 'v5.8-rc1' into regulator-5.8 Martin Fuzzey (1): regulator: da9063: fix LDO9 suspend and warning. Matti Vaittinen (1): regulator: Fix pickable ranges mapping Robin Gong (1): regualtor: pfuze100: correct sw1a/sw2 on pfuze3000 drivers/regulator/Kconfig | 2 +- drivers/regulator/da9063-regulator.c | 1 - drivers/regulator/helpers.c| 2 +- drivers/regulator/pfuze100-regulator.c | 60 ++ 4 files changed, 41 insertions(+), 24 deletions(-)
RE: [PATCH v2] dmabuf: use spinlock to access dmabuf->name
>-Original Message-
>From: charante=codeaurora@mg.codeaurora.org
> On Behalf Of Charan Teja
>Kalla
>Sent: Monday, June 22, 2020 5:26 AM
>To: Ruhl, Michael J ; Sumit Semwal
>; david.lai...@aculab.com; open list:DMA
>BUFFER SHARING FRAMEWORK ; DRI mailing
>list
>Cc: Linaro MM SIG ; LKML ker...@vger.kernel.org>
>Subject: Re: [PATCH v2] dmabuf: use spinlock to access dmabuf->name
>
>Hello Mike,
>
>On 6/19/2020 7:11 PM, Ruhl, Michael J wrote:
>>> -Original Message-
>>> From: charante=codeaurora@mg.codeaurora.org
>>> On Behalf Of Charan
>Teja
>>> Kalla
>>> Sent: Friday, June 19, 2020 7:57 AM
>>> To: Sumit Semwal ; Ruhl, Michael J
>>> ; david.lai...@aculab.com; open list:DMA
>>> BUFFER SHARING FRAMEWORK ; DRI
>mailing
>>> list
>>> Cc: Linaro MM SIG ; LKML >> ker...@vger.kernel.org>
>>> Subject: [PATCH v2] dmabuf: use spinlock to access dmabuf->name
>>>
>>> There exists a sleep-while-atomic bug while accessing the dmabuf->name
>>> under mutex in the dmabuffs_dname(). This is caused from the SELinux
>>> permissions checks on a process where it tries to validate the inherited
>>> files from fork() by traversing them through iterate_fd() (which
>>> traverse files under spin_lock) and call
>>> match_file(security/selinux/hooks.c) where the permission checks
>happen.
>>> This audit information is logged using dump_common_audit_data() where
>it
>>> calls d_path() to get the file path name. If the file check happen on
>>> the dmabuf's fd, then it ends up in ->dmabuffs_dname() and use mutex to
>>> access dmabuf->name. The flow will be like below:
>>> flush_unauthorized_files()
>>> iterate_fd()
>>>spin_lock() --> Start of the atomic section.
>>> match_file()
>>>file_has_perm()
>>> avc_has_perm()
>>>avc_audit()
>>> slow_avc_audit()
>>> common_lsm_audit()
>>> dump_common_audit_data()
>>> audit_log_d_path()
>>> d_path()
>>>dmabuffs_dname()
>>> mutex_lock()--> Sleep while atomic.
>>>
>>> Call trace captured (on 4.19 kernels) is below:
>>> ___might_sleep+0x204/0x208
>>> __might_sleep+0x50/0x88
>>> __mutex_lock_common+0x5c/0x1068
>>> __mutex_lock_common+0x5c/0x1068
>>> mutex_lock_nested+0x40/0x50
>>> dmabuffs_dname+0xa0/0x170
>>> d_path+0x84/0x290
>>> audit_log_d_path+0x74/0x130
>>> common_lsm_audit+0x334/0x6e8
>>> slow_avc_audit+0xb8/0xf8
>>> avc_has_perm+0x154/0x218
>>> file_has_perm+0x70/0x180
>>> match_file+0x60/0x78
>>> iterate_fd+0x128/0x168
>>> selinux_bprm_committing_creds+0x178/0x248
>>> security_bprm_committing_creds+0x30/0x48
>>> install_exec_creds+0x1c/0x68
>>> load_elf_binary+0x3a4/0x14e0
>>> search_binary_handler+0xb0/0x1e0
>>>
>>> So, use spinlock to access dmabuf->name to avoid sleep-while-atomic.
>>>
>>> Cc: [5.3+]
>>> Signed-off-by: Charan Teja Reddy
>>> ---
>>>
>>> Changes in V2: Addressed review comments from Ruhl, Michael J
>>>
>>> Changes in V1: https://lore.kernel.org/patchwork/patch/1255055/
>>>
>>> drivers/dma-buf/dma-buf.c | 11 +++
>>> include/linux/dma-buf.h | 1 +
>>> 2 files changed, 8 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>>> index 01ce125..d81d298 100644
>>> --- a/drivers/dma-buf/dma-buf.c
>>> +++ b/drivers/dma-buf/dma-buf.c
>>> @@ -45,10 +45,10 @@ static char *dmabuffs_dname(struct dentry
>*dentry,
>>> char *buffer, int buflen)
>>> size_t ret = 0;
>>>
>>> dmabuf = dentry->d_fsdata;
>>> - dma_resv_lock(dmabuf->resv, NULL);
>>> + spin_lock(&dmabuf->name_lock);
>>> if (dmabuf->name)
>>> ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN);
>>> - dma_resv_unlock(dmabuf->resv);
>>> + spin_unlock(&dmabuf->name_lock);
>>>
>>> return dynamic_dname(dentry, buffer, buflen, "/%s:%s",
>>> dentry->d_name.name, ret > 0 ? name : "");
>>> @@ -341,8 +341,10 @@ static long dma_buf_set_name(struct dma_buf
>>> *dmabuf, const char __user *buf)
>>> kfree(name);
>>> goto out_unlock;
>>> }
>>> + spin_lock(&dmabuf->name_lock);
>>> kfree(dmabuf->name);
>>> dmabuf->name = name;
>>> + spin_unlock(&dmabuf->name_lock);
>>
>> While this code path is ok, I would have separated the protection of the
>> attachment list and the name manipulation.
>>
>> dma_resv_lock(resv)
>> if (!list_empty(attachment)
>> ret = -EBUSY
>> dma_resv_unlock(resv)
>>
>> if (ret) {
>> kfree(name)
>> return ret;
>> }
>
>Is it that the name should be visible before importer attaches to the
>dmabuf,(using dma_buf_attach()), thus _buf_set_name() is under the
>_resv_lock() as well?
That is the name that was being freed in the error path of the lock block.
Alternatively:
dma_resv_lock(resv)
if (!list_empty(attachment) {
ret = -EBUSY
kfree(name)
}
dma_resv_unlock(resv)
if (ret)
return ret;
I was limiting what was happening in the lock block.
You have two dis
Re: [PATCH 0/6] Add Microchip MCP25XXFD CAN driver
On 6/18/20 2:06 PM, Manivannan Sadhasivam wrote: >> https://github.com/marckleinebudde/linux/commits/v5.6-rpi/mcp25xxfd-20200607-41 >> > > Tested this version on my board with MCP2518FD and it works fine. I'm okay > with > moving forward with your version and would like to contribute. Please let me > know how we can move forward. Can I add your Tested-by? Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH] fix annotation of io{read,write}{16,32}be()
These accessors must be used to read/write a big-endian bus.
The value returned or written is native-endian.
However, these accessors are defined using be{16,32}_to_cpu()
or cpu_to_be{16,32}() to make the endian conversion but these
expect a __be{16,32} when none is present. Keeping them would
need a force cast that would solve nothing at all.
So, do the conversion using swab{16,32}, like done in asm-generic
for similar situations.
Reported-by: kernel test robot
Signed-off-by: Luc Van Oostenryck
---
arch/alpha/include/asm/io.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/alpha/include/asm/io.h b/arch/alpha/include/asm/io.h
index a4d0c19f1e79..640e1a2f57b4 100644
--- a/arch/alpha/include/asm/io.h
+++ b/arch/alpha/include/asm/io.h
@@ -489,10 +489,10 @@ extern inline void writeq(u64 b, volatile void __iomem
*addr)
}
#endif
-#define ioread16be(p) be16_to_cpu(ioread16(p))
-#define ioread32be(p) be32_to_cpu(ioread32(p))
-#define iowrite16be(v,p) iowrite16(cpu_to_be16(v), (p))
-#define iowrite32be(v,p) iowrite32(cpu_to_be32(v), (p))
+#define ioread16be(p) swab16(ioread16(p))
+#define ioread32be(p) swab32(ioread32(p))
+#define iowrite16be(v,p) iowrite16(swab16(v), (p))
+#define iowrite32be(v,p) iowrite32(swab32(v), (p))
#define inb_p inb
#define inw_p inw
--
2.27.0
[PATCH v1 4/5] tulip: tulip_core: use generic power management
With the support of generic PM callbacks, drivers no longer need to use
legacy .suspend() and .resume() in which they had to maintain PCI
states changes and device's power state themselves.
Earlier, .suspend() and .resume() were invoking pci_disable_device()
and pci_enable_device() respectively to manage the device's power state.
driver also invoked pci_save/restore_state() and pci_set_power_sitate().
With generic PM, it is no longer needed. The driver is expected to just
implement driver-specific operations and leave power transitions to PCI
core.
Compile-tested only.
Signed-off-by: Vaibhav Gupta
---
drivers/net/ethernet/dec/tulip/tulip_core.c | 51 +
1 file changed, 12 insertions(+), 39 deletions(-)
diff --git a/drivers/net/ethernet/dec/tulip/tulip_core.c
b/drivers/net/ethernet/dec/tulip/tulip_core.c
index 15efc294f513..9db23527275a 100644
--- a/drivers/net/ethernet/dec/tulip/tulip_core.c
+++ b/drivers/net/ethernet/dec/tulip/tulip_core.c
@@ -1803,13 +1803,9 @@ static void tulip_set_wolopts (struct pci_dev *pdev, u32
wolopts)
}
}
-#ifdef CONFIG_PM
-
-
-static int tulip_suspend (struct pci_dev *pdev, pm_message_t state)
+static int __maybe_unused tulip_suspend(struct device *dev_d)
{
- pci_power_t pstate;
- struct net_device *dev = pci_get_drvdata(pdev);
+ struct net_device *dev = dev_get_drvdata(dev_d);
struct tulip_private *tp = netdev_priv(dev);
if (!dev)
@@ -1825,45 +1821,27 @@ static int tulip_suspend (struct pci_dev *pdev,
pm_message_t state)
free_irq(tp->pdev->irq, dev);
save_state:
- pci_save_state(pdev);
- pci_disable_device(pdev);
- pstate = pci_choose_state(pdev, state);
- if (state.event == PM_EVENT_SUSPEND && pstate != PCI_D0) {
- int rc;
-
- tulip_set_wolopts(pdev, tp->wolinfo.wolopts);
- rc = pci_enable_wake(pdev, pstate, tp->wolinfo.wolopts);
- if (rc)
- pr_err("pci_enable_wake failed (%d)\n", rc);
- }
- pci_set_power_state(pdev, pstate);
+ tulip_set_wolopts(to_pci_dev(dev_d), tp->wolinfo.wolopts);
+ device_set_wakeup_enable(dev_d, !!tp->wolinfo.wolopts);
return 0;
}
-
-static int tulip_resume(struct pci_dev *pdev)
+static int __maybe_unused tulip_resume(struct device *dev_d)
{
- struct net_device *dev = pci_get_drvdata(pdev);
+ struct pci_dev *pdev = to_pci_dev(dev_d);
+ struct net_device *dev = dev_get_drvdata(dev_d);
struct tulip_private *tp = netdev_priv(dev);
void __iomem *ioaddr = tp->base_addr;
- int retval;
unsigned int tmp;
+ int retval = 0;
if (!dev)
return -EINVAL;
- pci_set_power_state(pdev, PCI_D0);
- pci_restore_state(pdev);
-
if (!netif_running(dev))
return 0;
- if ((retval = pci_enable_device(pdev))) {
- pr_err("pci_enable_device failed in resume\n");
- return retval;
- }
-
retval = request_irq(pdev->irq, tulip_interrupt, IRQF_SHARED,
dev->name, dev);
if (retval) {
@@ -1872,8 +1850,7 @@ static int tulip_resume(struct pci_dev *pdev)
}
if (tp->flags & COMET_PM) {
- pci_enable_wake(pdev, PCI_D3hot, 0);
- pci_enable_wake(pdev, PCI_D3cold, 0);
+ device_set_wakeup_enable(dev_d, 0);
/* Clear the PMES flag */
tmp = ioread32(ioaddr + CSR20);
@@ -1891,9 +1868,6 @@ static int tulip_resume(struct pci_dev *pdev)
return 0;
}
-#endif /* CONFIG_PM */
-
-
static void tulip_remove_one(struct pci_dev *pdev)
{
struct net_device *dev = pci_get_drvdata (pdev);
@@ -1937,15 +1911,14 @@ static void poll_tulip (struct net_device *dev)
}
#endif
+static SIMPLE_DEV_PM_OPS(tulip_pm_ops, tulip_suspend, tulip_resume);
+
static struct pci_driver tulip_driver = {
.name = DRV_NAME,
.id_table = tulip_pci_tbl,
.probe = tulip_init_one,
.remove = tulip_remove_one,
-#ifdef CONFIG_PM
- .suspend= tulip_suspend,
- .resume = tulip_resume,
-#endif /* CONFIG_PM */
+ .driver.pm = &tulip_pm_ops,
};
--
2.27.0
[PATCH v1 0/5] ethernet: dec: tulip: use generic power management
Linux Kernel Mentee: Remove Legacy Power Management. The purpose of this patch series is to remove legacy power management callbacks and invocation of PCI helper functions, from tulip ethernet drivers. With legacy PM, drivers themselves are responsible for handling the device's power states. And they do this with the help of PCI helper functions like pci_enable/disable_device(), pci_set/restore_state(), pci_set_powr_state(), etc. which is not recommended. In generic PM, all the required tasks are handled by PCI core and drivers need to perform device-specific operations only. All patches are compile-tested only. Vaibhav Gupta (5): tulip: dmfe: use generic power management tulip: windbond-840: use generic power management tulip: de2104x: use generic power management tulip: tulip_core: use generic power management tulip: uli526x: use generic power management drivers/net/ethernet/dec/tulip/de2104x.c | 25 +++--- drivers/net/ethernet/dec/tulip/dmfe.c| 49 --- drivers/net/ethernet/dec/tulip/tulip_core.c | 51 +--- drivers/net/ethernet/dec/tulip/uli526x.c | 48 +++--- drivers/net/ethernet/dec/tulip/winbond-840.c | 26 +++--- 5 files changed, 45 insertions(+), 154 deletions(-) -- 2.27.0
[PATCH v1 2/5] tulip: windbond-840: use generic power management
With stable support of generic PM callbacks, drivers no longer need to use
legacy .suspend() and .resume() in which they had to maintain PCI states
changes and device's power state themselves.
Earlier, .resume() was invoking pci_enable_device(). Drivers should not
call PCI legacy helper functions, hence, it was removed. This should not
change the behavior of the device as this function is called by PCI core
if somehow pm_ops is not able to bind with the driver, else, required tasks
are managed by the core itself.
Compile-tested only.
Signed-off-by: Vaibhav Gupta
---
drivers/net/ethernet/dec/tulip/winbond-840.c | 26 ++--
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/dec/tulip/winbond-840.c
b/drivers/net/ethernet/dec/tulip/winbond-840.c
index 4d5e4fa53023..5dcc66f60144 100644
--- a/drivers/net/ethernet/dec/tulip/winbond-840.c
+++ b/drivers/net/ethernet/dec/tulip/winbond-840.c
@@ -1530,8 +1530,6 @@ static void w840_remove1(struct pci_dev *pdev)
}
}
-#ifdef CONFIG_PM
-
/*
* suspend/resume synchronization:
* - open, close, do_ioctl:
@@ -1555,9 +1553,9 @@ static void w840_remove1(struct pci_dev *pdev)
* Detach must occur under spin_unlock_irq(), interrupts from a detached
* device would cause an irq storm.
*/
-static int w840_suspend (struct pci_dev *pdev, pm_message_t state)
+static int __maybe_unused w840_suspend(struct device *dev_d)
{
- struct net_device *dev = pci_get_drvdata (pdev);
+ struct net_device *dev = dev_get_drvdata(dev_d);
struct netdev_private *np = netdev_priv(dev);
void __iomem *ioaddr = np->base_addr;
@@ -1590,21 +1588,15 @@ static int w840_suspend (struct pci_dev *pdev,
pm_message_t state)
return 0;
}
-static int w840_resume (struct pci_dev *pdev)
+static int __maybe_unused w840_resume(struct device *dev_d)
{
- struct net_device *dev = pci_get_drvdata (pdev);
+ struct net_device *dev = dev_get_drvdata(dev_d);
struct netdev_private *np = netdev_priv(dev);
- int retval = 0;
rtnl_lock();
if (netif_device_present(dev))
goto out; /* device not suspended */
if (netif_running(dev)) {
- if ((retval = pci_enable_device(pdev))) {
- dev_err(&dev->dev,
- "pci_enable_device failed in resume\n");
- goto out;
- }
spin_lock_irq(&np->lock);
iowrite32(1, np->base_addr+PCIBusCfg);
ioread32(np->base_addr+PCIBusCfg);
@@ -1622,19 +1614,17 @@ static int w840_resume (struct pci_dev *pdev)
}
out:
rtnl_unlock();
- return retval;
+ return 0;
}
-#endif
+
+static SIMPLE_DEV_PM_OPS(w840_pm_ops, w840_suspend, w840_resume);
static struct pci_driver w840_driver = {
.name = DRV_NAME,
.id_table = w840_pci_tbl,
.probe = w840_probe1,
.remove = w840_remove1,
-#ifdef CONFIG_PM
- .suspend= w840_suspend,
- .resume = w840_resume,
-#endif
+ .driver.pm = &w840_pm_ops,
};
static int __init w840_init(void)
--
2.27.0
[PATCH v1 1/5] tulip: dmfe: use generic power management
With legacy PM hooks, it was the responsibility of a driver to manage PCI
states and also the device's power state. The generic approach is to let the
PCI core handle the work.
The legacy suspend() and resume() were making use of
pci_read/write_config_dword() to enable/disable wol. Driver editing
configuration registers of a device is not recommended. Thus replace them
all with device_wakeup_enable/disable().
Compile-tested only.
Signed-off-by: Vaibhav Gupta
---
drivers/net/ethernet/dec/tulip/dmfe.c | 49 +--
1 file changed, 9 insertions(+), 40 deletions(-)
diff --git a/drivers/net/ethernet/dec/tulip/dmfe.c
b/drivers/net/ethernet/dec/tulip/dmfe.c
index c1884fc9ad32..c3b4abff48b5 100644
--- a/drivers/net/ethernet/dec/tulip/dmfe.c
+++ b/drivers/net/ethernet/dec/tulip/dmfe.c
@@ -2081,14 +2081,11 @@ static const struct pci_device_id dmfe_pci_tbl[] = {
};
MODULE_DEVICE_TABLE(pci, dmfe_pci_tbl);
-
-#ifdef CONFIG_PM
-static int dmfe_suspend(struct pci_dev *pci_dev, pm_message_t state)
+static int __maybe_unused dmfe_suspend(struct device *dev_d)
{
- struct net_device *dev = pci_get_drvdata(pci_dev);
+ struct net_device *dev = dev_get_drvdata(dev_d);
struct dmfe_board_info *db = netdev_priv(dev);
void __iomem *ioaddr = db->ioaddr;
- u32 tmp;
/* Disable upper layer interface */
netif_device_detach(dev);
@@ -2105,63 +2102,35 @@ static int dmfe_suspend(struct pci_dev *pci_dev,
pm_message_t state)
dmfe_free_rxbuffer(db);
/* Enable WOL */
- pci_read_config_dword(pci_dev, 0x40, &tmp);
- tmp &= ~(DMFE_WOL_LINKCHANGE|DMFE_WOL_MAGICPACKET);
-
- if (db->wol_mode & WAKE_PHY)
- tmp |= DMFE_WOL_LINKCHANGE;
- if (db->wol_mode & WAKE_MAGIC)
- tmp |= DMFE_WOL_MAGICPACKET;
-
- pci_write_config_dword(pci_dev, 0x40, tmp);
-
- pci_enable_wake(pci_dev, PCI_D3hot, 1);
- pci_enable_wake(pci_dev, PCI_D3cold, 1);
-
- /* Power down device*/
- pci_save_state(pci_dev);
- pci_set_power_state(pci_dev, pci_choose_state (pci_dev, state));
+ device_wakeup_enable(dev_d);
return 0;
}
-static int dmfe_resume(struct pci_dev *pci_dev)
+static int __maybe_unused dmfe_resume(struct device *dev_d)
{
- struct net_device *dev = pci_get_drvdata(pci_dev);
- u32 tmp;
-
- pci_set_power_state(pci_dev, PCI_D0);
- pci_restore_state(pci_dev);
+ struct net_device *dev = dev_get_drvdata(dev_d);
/* Re-initialize DM910X board */
dmfe_init_dm910x(dev);
/* Disable WOL */
- pci_read_config_dword(pci_dev, 0x40, &tmp);
-
- tmp &= ~(DMFE_WOL_LINKCHANGE | DMFE_WOL_MAGICPACKET);
- pci_write_config_dword(pci_dev, 0x40, tmp);
-
- pci_enable_wake(pci_dev, PCI_D3hot, 0);
- pci_enable_wake(pci_dev, PCI_D3cold, 0);
+ device_wakeup_disable(dev_d);
/* Restart upper layer interface */
netif_device_attach(dev);
return 0;
}
-#else
-#define dmfe_suspend NULL
-#define dmfe_resume NULL
-#endif
+
+static SIMPLE_DEV_PM_OPS(dmfe_pm_ops, dmfe_suspend, dmfe_resume);
static struct pci_driver dmfe_driver = {
.name = "dmfe",
.id_table = dmfe_pci_tbl,
.probe = dmfe_init_one,
.remove = dmfe_remove_one,
- .suspend= dmfe_suspend,
- .resume = dmfe_resume
+ .driver.pm = &dmfe_pm_ops,
};
MODULE_AUTHOR("Sten Wang, sten_w...@davicom.com.tw");
--
2.27.0
[PATCH v1 3/5] tulip: de2104x: use generic power management
With the support of generic PM callbacks, drivers no longer need to use
legacy .suspend() and .resume() in which they had to maintain PCI states
changes and device's power state themselves.
Earlier, .suspend() and .resume() were invoking pci_disable_device()
and pci_enable_device() respectively to manage the device's power state.
With generic PM, it is no longer needed. The driver is expected to just
implement driver-specific operations and leave power transitions to PCI
core.
Compile-tested only.
Signed-off-by: Vaibhav Gupta
---
drivers/net/ethernet/dec/tulip/de2104x.c | 25
1 file changed, 8 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/dec/tulip/de2104x.c
b/drivers/net/ethernet/dec/tulip/de2104x.c
index 592454f444ce..cb116b530f5e 100644
--- a/drivers/net/ethernet/dec/tulip/de2104x.c
+++ b/drivers/net/ethernet/dec/tulip/de2104x.c
@@ -2105,11 +2105,10 @@ static void de_remove_one(struct pci_dev *pdev)
free_netdev(dev);
}
-#ifdef CONFIG_PM
-
-static int de_suspend (struct pci_dev *pdev, pm_message_t state)
+static int __maybe_unused de_suspend(struct device *dev_d)
{
- struct net_device *dev = pci_get_drvdata (pdev);
+ struct pci_dev *pdev = to_pci_dev(dev_d);
+ struct net_device *dev = pci_get_drvdata(pdev);
struct de_private *de = netdev_priv(dev);
rtnl_lock();
@@ -2136,7 +2135,6 @@ static int de_suspend (struct pci_dev *pdev, pm_message_t
state)
de_clean_rings(de);
de_adapter_sleep(de);
- pci_disable_device(pdev);
} else {
netif_device_detach(dev);
}
@@ -2144,21 +2142,17 @@ static int de_suspend (struct pci_dev *pdev,
pm_message_t state)
return 0;
}
-static int de_resume (struct pci_dev *pdev)
+static int __maybe_unused de_resume(struct device *dev_d)
{
- struct net_device *dev = pci_get_drvdata (pdev);
+ struct pci_dev *pdev = to_pci_dev(dev_d);
+ struct net_device *dev = pci_get_drvdata(pdev);
struct de_private *de = netdev_priv(dev);
- int retval = 0;
rtnl_lock();
if (netif_device_present(dev))
goto out;
if (!netif_running(dev))
goto out_attach;
- if ((retval = pci_enable_device(pdev))) {
- netdev_err(dev, "pci_enable_device failed in resume\n");
- goto out;
- }
pci_set_master(pdev);
de_init_rings(de);
de_init_hw(de);
@@ -2169,17 +2163,14 @@ static int de_resume (struct pci_dev *pdev)
return 0;
}
-#endif /* CONFIG_PM */
+static SIMPLE_DEV_PM_OPS(de_pm_ops, de_suspend, de_resume);
static struct pci_driver de_driver = {
.name = DRV_NAME,
.id_table = de_pci_tbl,
.probe = de_init_one,
.remove = de_remove_one,
-#ifdef CONFIG_PM
- .suspend= de_suspend,
- .resume = de_resume,
-#endif
+ .driver.pm = &de_pm_ops,
};
static int __init de_init (void)
--
2.27.0
[PATCH v1 5/5] tulip: uli526x: use generic power management
With the support of generic PM callbacks, drivers no longer need to use
legacy .suspend() and .resume() in which they had to maintain PCI states
changes and device's power state themselves.
Legacy PM involves usage of PCI helper functions like pci_enable_wake()
which is no longer recommended.
Compile-tested only.
Signed-off-by: Vaibhav Gupta
---
drivers/net/ethernet/dec/tulip/uli526x.c | 48
1 file changed, 8 insertions(+), 40 deletions(-)
diff --git a/drivers/net/ethernet/dec/tulip/uli526x.c
b/drivers/net/ethernet/dec/tulip/uli526x.c
index f726436b1985..f942399f0f32 100644
--- a/drivers/net/ethernet/dec/tulip/uli526x.c
+++ b/drivers/net/ethernet/dec/tulip/uli526x.c
@@ -1163,65 +1163,41 @@ static void uli526x_dynamic_reset(struct net_device
*dev)
netif_wake_queue(dev);
}
-
-#ifdef CONFIG_PM
-
/*
* Suspend the interface.
*/
-static int uli526x_suspend(struct pci_dev *pdev, pm_message_t state)
+static int __maybe_unused uli526x_suspend(struct device *dev_d)
{
- struct net_device *dev = pci_get_drvdata(pdev);
- pci_power_t power_state;
- int err;
+ struct net_device *dev = dev_get_drvdata(dev_d);
ULI526X_DBUG(0, "uli526x_suspend", 0);
- pci_save_state(pdev);
-
if (!netif_running(dev))
return 0;
netif_device_detach(dev);
uli526x_reset_prepare(dev);
- power_state = pci_choose_state(pdev, state);
- pci_enable_wake(pdev, power_state, 0);
- err = pci_set_power_state(pdev, power_state);
- if (err) {
- netif_device_attach(dev);
- /* Re-initialize ULI526X board */
- uli526x_init(dev);
- /* Restart upper layer interface */
- netif_wake_queue(dev);
- }
+ device_set_wakeup_enable(dev_d, 0);
- return err;
+ return 0;
}
/*
* Resume the interface.
*/
-static int uli526x_resume(struct pci_dev *pdev)
+static int __maybe_unused uli526x_resume(struct device *dev_d)
{
- struct net_device *dev = pci_get_drvdata(pdev);
- int err;
+ struct net_device *dev = dev_get_drvdata(dev_d);
ULI526X_DBUG(0, "uli526x_resume", 0);
- pci_restore_state(pdev);
if (!netif_running(dev))
return 0;
- err = pci_set_power_state(pdev, PCI_D0);
- if (err) {
- netdev_warn(dev, "Could not put device into D0\n");
- return err;
- }
-
netif_device_attach(dev);
/* Re-initialize ULI526X board */
uli526x_init(dev);
@@ -1231,14 +1207,6 @@ static int uli526x_resume(struct pci_dev *pdev)
return 0;
}
-#else /* !CONFIG_PM */
-
-#define uli526x_suspendNULL
-#define uli526x_resume NULL
-
-#endif /* !CONFIG_PM */
-
-
/*
* free all allocated rx buffer
*/
@@ -1761,14 +1729,14 @@ static const struct pci_device_id uli526x_pci_tbl[] = {
};
MODULE_DEVICE_TABLE(pci, uli526x_pci_tbl);
+static SIMPLE_DEV_PM_OPS(uli526x_pm_ops, uli526x_suspend, uli526x_resume);
static struct pci_driver uli526x_driver = {
.name = "uli526x",
.id_table = uli526x_pci_tbl,
.probe = uli526x_init_one,
.remove = uli526x_remove_one,
- .suspend= uli526x_suspend,
- .resume = uli526x_resume,
+ .driver.pm = &uli526x_pm_ops,
};
MODULE_AUTHOR("Peer Chen, peer.c...@uli.com.tw");
--
2.27.0
Re: [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations
On Fri, Jun 19, 2020 at 04:31:47PM -0400, Jerome Glisse wrote: > Not doable as page refcount can change for things unrelated to GUP, with > John changes we can identify GUP and we could potentialy copy GUPed page > instead of COW but this can potentialy slow down fork() and i am not sure > how acceptable this would be. Also this does not solve GUP against page > that are already in fork tree ie page P0 is in process A which forks, > we now have page P0 in process A and B. Now we have process A which forks > again and we have page P0 in A, B, and C. Here B and C are two branches > with root in A. B and/or C can keep forking and grow the fork tree. For a long time now RDMA has broken COW pages when creating user DMA regions. The problem has been that fork re-COW's regions that had their COW broken. So, if you break the COW upon mapping and prevent fork (and others) from copying DMA pinned then you'd cover the cases. > Semantic was change with 17839856fd588f4ab6b789f482ed3ffd7c403e1f to some > what "fix" that but GUP fast is still succeptible to this. Ah, so everyone breaks the COW now, not just RDMA.. What do you mean 'GUP fast is still succeptible to this' ? Jason
[PATCH v2] media: cros-ec-cec: do not bail on device_init_wakeup failure
Do not fail probing when device_init_wakeup fails.
device_init_wakeup fails when the device is already enabled as wakeup
device. Hence, the driver fails to probe the device if:
- The device has already been enabled for wakeup (by e.g. sysfs)
- The driver has been unloaded and is being loaded again.
This goal of the patch is to fix the above cases.
Overwhelming majority of the drivers do not check device_init_wakeup
return code.
v2: add Fixes tags
Fixes: cd70de2d356ee ("media: platform: Add ChromeOS EC CEC driver")
Signed-off-by: Dariusz Marcinkiewicz
---
drivers/media/cec/platform/cros-ec/cros-ec-cec.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/media/cec/platform/cros-ec/cros-ec-cec.c
b/drivers/media/cec/platform/cros-ec/cros-ec-cec.c
index 0e7e2772f08f..2d95e16cd248 100644
--- a/drivers/media/cec/platform/cros-ec/cros-ec-cec.c
+++ b/drivers/media/cec/platform/cros-ec/cros-ec-cec.c
@@ -277,11 +277,7 @@ static int cros_ec_cec_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, cros_ec_cec);
cros_ec_cec->cros_ec = cros_ec;
- ret = device_init_wakeup(&pdev->dev, 1);
- if (ret) {
- dev_err(&pdev->dev, "failed to initialize wakeup\n");
- return ret;
- }
+ device_init_wakeup(&pdev->dev, 1);
cros_ec_cec->adap = cec_allocate_adapter(&cros_ec_cec_ops, cros_ec_cec,
DRV_NAME,
--
2.27.0.111.gc72c7da667-goog
[PATCH net v2] mptcp: drop sndr_key in mptcp_syn_options
In RFC 8684, we don't need to send sndr_key in SYN package anymore, so drop
it.
Fixes: cc7972ea1932 ("mptcp: parse and emit MP_CAPABLE option according to v1
spec")
Signed-off-by: Geliang Tang
---
net/mptcp/options.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/mptcp/options.c b/net/mptcp/options.c
index 490b92534afc..df9a51425c6f 100644
--- a/net/mptcp/options.c
+++ b/net/mptcp/options.c
@@ -336,9 +336,7 @@ bool mptcp_syn_options(struct sock *sk, const struct
sk_buff *skb,
*/
subflow->snd_isn = TCP_SKB_CB(skb)->end_seq;
if (subflow->request_mptcp) {
- pr_debug("local_key=%llu", subflow->local_key);
opts->suboptions = OPTION_MPTCP_MPC_SYN;
- opts->sndr_key = subflow->local_key;
*size = TCPOLEN_MPTCP_MPC_SYN;
return true;
} else if (subflow->request_join) {
--
2.17.1
Re: [PATCH 1/7] x86/entry: Fix #UD vs WARN more
On Thu, Jun 18, 2020 at 11:18:23PM +0200, Peter Zijlstra wrote:
> > So maybe also do an untraced cond_local_irq_enable()? After all, if
> > we’re trying to report a bug from IRQs on, it should be okay to have
> > IRQs on while reporting it. It might even work better than having IRQs
> > off.
>
> Yes, very good point. Now I want to go look at the old code... I'll frob
> something tomorrow, brain is pretty fried by now.
How's this then?
---
Subject: x86/entry: Fix #UD vs WARN more
From: Peter Zijlstra
Date: Tue Jun 16 13:28:36 CEST 2020
vmlinux.o: warning: objtool: exc_invalid_op()+0x47: call to probe_kernel_read()
leaves .noinstr.text section
Since we use UD2 as a short-cut for 'CALL __WARN', treat it as such.
Have the bare exception handler do the report_bug() thing.
Fixes: 15a416e8aaa7 ("x86/entry: Treat BUG/WARN as NMI-like entries")
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/kernel/traps.c | 72 +---
1 file changed, 38 insertions(+), 34 deletions(-)
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -86,15 +86,14 @@ static inline void cond_local_irq_disabl
int is_valid_bugaddr(unsigned long addr)
{
- unsigned short ud;
-
if (addr < TASK_SIZE_MAX)
return 0;
- if (probe_kernel_address((unsigned short *)addr, ud))
- return 0;
-
- return ud == INSN_UD0 || ud == INSN_UD2;
+ /*
+* We got #UD, if the text isn't readable we'd have gotten
+* a different exception.
+*/
+ return *(unsigned short)addr == INSN_UD2;
}
static nokprobe_inline int
@@ -216,40 +215,45 @@ static inline void handle_invalid_op(str
ILL_ILLOPN, error_get_trap_addr(regs));
}
-DEFINE_IDTENTRY_RAW(exc_invalid_op)
+static noinstr bool handle_bug(struct pt_regs *regs)
{
- bool rcu_exit;
+ bool handled = false;
+
+ if (!is_valid_bugaddr(regs->ip))
+ return handled;
/*
-* Handle BUG/WARN like NMIs instead of like normal idtentries:
-* if we bugged/warned in a bad RCU context, for example, the last
-* thing we want is to BUG/WARN again in the idtentry code, ad
-* infinitum.
+* All lies, just get the WARN/BUG out.
+*/
+ instrumentation_begin();
+ /*
+* Since we're emulating a CALL with exceptions, restore the interrupt
+* state to what it was at the exception site.
*/
- if (!user_mode(regs) && is_valid_bugaddr(regs->ip)) {
- enum bug_trap_type type;
+ if (regs->flags & X86_EFLAGS_IF)
+ raw_local_irq_enable();
+ if (report_bug(regs->ip, regs) == BUG_TRAP_TYPE_WARN) {
+ regs->ip += LEN_UD2;
+ handled = true;
+ }
+ if (regs->flags & X86_EFLAGS_IF)
+ raw_local_irq_disable();
+ instrumentation_end();
- nmi_enter();
- instrumentation_begin();
- trace_hardirqs_off_finish();
- type = report_bug(regs->ip, regs);
- if (regs->flags & X86_EFLAGS_IF)
- trace_hardirqs_on_prepare();
- instrumentation_end();
- nmi_exit();
-
- if (type == BUG_TRAP_TYPE_WARN) {
- /* Skip the ud2. */
- regs->ip += LEN_UD2;
- return;
- }
+ return handled;
+}
- /*
-* Else, if this was a BUG and report_bug returns or if this
-* was just a normal #UD, we want to continue onward and
-* crash.
-*/
- }
+DEFINE_IDTENTRY_RAW(exc_invalid_op)
+{
+ bool rcu_exit;
+
+ /*
+* We use UD2 as a short encoding for 'CALL __WARN', as such
+* handle it before exception entry to avoid recursive WARN
+* in case exception entry is the one triggering WARNs.
+*/
+ if (!user_mode(regs) && handle_bug(regs))
+ return;
rcu_exit = idtentry_enter_cond_rcu(regs);
instrumentation_begin();
Re: [PATCH 0/6] Add Microchip MCP25XXFD CAN driver
On 6/18/20 10:55 AM, Manivannan Sadhasivam wrote: > So how should we proceed from here? It is okay for me to work on adding some > features and also fixing the issues you've reported so far. But I want to > reach > a consensus before moving forward. > > If you think that it makes sense to go with your set of patches, then I need > an > estimate on when you'll post the first revision. Done, I've posted my current version, which is -41. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[PATCH] dt-bindings: reset: Convert UniPhier reset to json-schema
Convert the UniPhier reset controller binding to DT schema format.
I excluded the glue resets because their bindings are too different.
Signed-off-by: Masahiro Yamada
---
.../reset/socionext,uniphier-reset.yaml | 112
.../bindings/reset/uniphier-reset.txt | 121 +-
2 files changed, 113 insertions(+), 120 deletions(-)
create mode 100644
Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml
diff --git
a/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml
b/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml
new file mode 100644
index ..4c9b0ebf6869
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/socionext,uniphier-reset.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reset/socionext,uniphier-reset.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: UniPhier reset controller
+
+maintainers:
+ - Masahiro Yamada
+
+properties:
+ compatible:
+oneOf:
+ - description: System reset
+enum:
+ - socionext,uniphier-ld4-reset
+ - socionext,uniphier-pro4-reset
+ - socionext,uniphier-sld8-reset
+ - socionext,uniphier-pro5-reset
+ - socionext,uniphier-pxs2-reset
+ - socionext,uniphier-ld6b-reset
+ - socionext,uniphier-ld11-reset
+ - socionext,uniphier-ld20-reset
+ - socionext,uniphier-pxs3-reset
+ - description: Media I/O (MIO) reset, SD reset
+enum:
+ - socionext,uniphier-ld4-mio-reset
+ - socionext,uniphier-pro4-mio-reset
+ - socionext,uniphier-sld8-mio-reset
+ - socionext,uniphier-pro5-sd-reset
+ - socionext,uniphier-pxs2-sd-reset
+ - socionext,uniphier-ld11-mio-reset
+ - socionext,uniphier-ld11-sd-reset
+ - socionext,uniphier-ld20-sd-reset
+ - socionext,uniphier-pxs3-sd-reset
+ - description: Peripheral reset
+enum:
+ - socionext,uniphier-ld4-peri-reset
+ - socionext,uniphier-pro4-peri-reset
+ - socionext,uniphier-sld8-peri-reset
+ - socionext,uniphier-pro5-peri-reset
+ - socionext,uniphier-pxs2-peri-reset
+ - socionext,uniphier-ld11-peri-reset
+ - socionext,uniphier-ld20-peri-reset
+ - socionext,uniphier-pxs3-peri-reset
+ - description: Analog signal amplifier reset
+enum:
+ - socionext,uniphier-ld11-adamv-reset
+ - socionext,uniphier-ld20-adamv-reset
+
+ "#reset-cells":
+const: 1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - "#reset-cells"
+
+examples:
+ - |
+sysctrl@6184 {
+compatible = "socionext,uniphier-sysctrl", "simple-mfd", "syscon";
+reg = <0x6184 0x4000>;
+
+reset {
+compatible = "socionext,uniphier-ld11-reset";
+#reset-cells = <1>;
+};
+
+// other nodes ...
+};
+
+ - |
+mioctrl@5981 {
+compatible = "socionext,uniphier-mioctrl", "simple-mfd", "syscon";
+reg = <0x5981 0x800>;
+
+reset {
+compatible = "socionext,uniphier-ld11-mio-reset";
+#reset-cells = <1>;
+};
+
+// other nodes ...
+};
+
+ - |
+perictrl@5982 {
+compatible = "socionext,uniphier-perictrl", "simple-mfd", "syscon";
+reg = <0x5982 0x200>;
+
+reset {
+compatible = "socionext,uniphier-ld11-peri-reset";
+#reset-cells = <1>;
+};
+
+// other nodes ...
+};
+
+ - |
+adamv@5792 {
+compatible = "socionext,uniphier-ld11-adamv", "simple-mfd", "syscon";
+reg = <0x5792 0x1000>;
+
+reset {
+compatible = "socionext,uniphier-ld11-adamv-reset";
+#reset-cells = <1>;
+};
+
+// other nodes ...
+};
diff --git a/Documentation/devicetree/bindings/reset/uniphier-reset.txt
b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
index e320a8cc9e4d..88e06e5e8d23 100644
--- a/Documentation/devicetree/bindings/reset/uniphier-reset.txt
+++ b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
@@ -1,123 +1,4 @@
-UniPhier reset controller
-
-
-System reset
-
-
-Required properties:
-- compatible: should be one of the following:
-"socionext,uniphier-ld4-reset" - for LD4 SoC
-"socionext,uniphier-pro4-reset" - for Pro4 SoC
-"socionext,uniphier-sld8-reset" - for sLD8 SoC
-"socionext,uniphier-pro5-reset" - for Pro5 SoC
-"socionext,uniphier-pxs2-reset" - for PXs2/LD6b SoC
-"socionext,uniphier-ld11-reset" - for LD11 SoC
-"socionext,uniphier-ld20-reset" - for LD20 SoC
-"socionext,uniphier-pxs3-reset" - for PXs3 SoC
-- #reset-cells: should be 1.
-
-Example:
-
- sysctrl@6184 {
- compatible = "socionext,uniphier-ld11-sysctrl",
-
Re: [PATCH net v2] mptcp: drop sndr_key in mptcp_syn_options
Hi Geliang,
On 22/06/2020 13:45, Geliang Tang wrote:
In RFC 8684, we don't need to send sndr_key in SYN package anymore, so drop
Please next time try to have max 72 chars per line in your commit message ;)
it.
Fixes: cc7972ea1932 ("mptcp: parse and emit MP_CAPABLE option according to v1
spec")
Signed-off-by: Geliang Tang
Thank you for this v2. It looks good to me!
Reviewed-by: Matthieu Baerts
Cheers,
Matt
--
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net
Re: [RESEND v2 4/4] arm64: dts: mt6359: add PMIC MT6359 related nodes
Hi Matthias,
On Mon, 2020-06-22 at 12:12 +0200, Matthias Brugger wrote:
>
> On 22/06/2020 08:40, Wen Su wrote:
> > From: "Wen Su"
> >
> > add PMIC MT6359 related nodes which is for MT6779 platform
> >
> > Signed-off-by: Wen Su
> > ---
> > arch/arm64/boot/dts/mediatek/mt6359.dtsi | 306
> > +++
> > 1 file changed, 306 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/mediatek/mt6359.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt6359.dtsi
> > b/arch/arm64/boot/dts/mediatek/mt6359.dtsi
> > new file mode 100644
> > index 000..4cafe1f
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt6359.dtsi
> > @@ -0,0 +1,306 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2019 MediaTek Inc.
> > + */
> > +
> > +&pwrap {
> > + pmic: pmic {
> > + mt6359regulator: mt6359regulator {
>
> you are missing:
> compatible = "mediatek,mt6359";
> don't you?
I think this compatible string is for MFD driver.
And the MFD instantiate the regulator driver when it probes.
So this regulator patch set remove this compatible string.
Is it better to add this compatible string in this patch set ?
Thanks for your suggestion.
>
> Regards,
> Matthias
>
> > + compatible = "mediatek,mt6359-regulator";
> > + mt6359_vs1_buck_reg: buck_vs1 {
> > + regulator-name = "vs1";
> > + regulator-min-microvolt = <80>;
> > + regulator-max-microvolt = <220>;
> > + regulator-enable-ramp-delay = <0>;
> > + regulator-always-on;
> > + };
> > + mt6359_vgpu11_buck_reg: buck_vgpu11 {
> > + regulator-name = "vgpu11";
> > + regulator-min-microvolt = <40>;
> > + regulator-max-microvolt = <1193750>;
> > + regulator-ramp-delay = <5000>;
> > + regulator-enable-ramp-delay = <200>;
> > + regulator-always-on;
> > + regulator-allowed-modes = <0 1 2>;
> > + };
> > + mt6359_vmodem_buck_reg: buck_vmodem {
> > + regulator-name = "vmodem";
> > + regulator-min-microvolt = <40>;
> > + regulator-max-microvolt = <110>;
> > + regulator-ramp-delay = <10760>;
> > + regulator-enable-ramp-delay = <200>;
> > + regulator-always-on;
> > + };
> > + mt6359_vpu_buck_reg: buck_vpu {
> > + regulator-name = "vpu";
> > + regulator-min-microvolt = <40>;
> > + regulator-max-microvolt = <1193750>;
> > + regulator-ramp-delay = <5000>;
> > + regulator-enable-ramp-delay = <200>;
> > + regulator-allowed-modes = <0 1 2>;
> > + };
> > + mt6359_vcore_buck_reg: buck_vcore {
> > + regulator-name = "vcore";
> > + regulator-min-microvolt = <40>;
> > + regulator-max-microvolt = <1193750>;
> > + regulator-ramp-delay = <5000>;
> > + regulator-enable-ramp-delay = <200>;
> > + regulator-always-on;
> > + regulator-allowed-modes = <0 1 2>;
> > + };
> > + mt6359_vs2_buck_reg: buck_vs2 {
> > + regulator-name = "vs2";
> > + regulator-min-microvolt = <80>;
> > + regulator-max-microvolt = <160>;
> > + regulator-enable-ramp-delay = <0>;
> > + regulator-always-on;
> > + };
> > + mt6359_vpa_buck_reg: buck_vpa {
> > + regulator-name = "vpa";
> > + regulator-min-microvolt = <50>;
> > + regulator-max-microvolt = <365>;
> > + regulator-enable-ramp-delay = <300>;
> > + };
> > + mt6359_vproc2_buck_reg: buck_vproc2 {
> > + regulator-name = "vproc2";
> > + regulator-min-microvolt = <40>;
> > + regulator-max-microvolt = <1193750>;
> > + regulator-ramp-delay = <7500>;
> > + regulator-enable-ramp-delay = <200>;
> > + regulator-always-on;
> > + regulator-allowed-modes = <0 1 2>;
> > + };
> >
Re: [RFC PATCH] media: venus: Fix NULL pointer dereference in core selection
Hi Doug,
Thanks for the fix and sorry for the late reply.
On 6/2/20 6:39 AM, Doug Anderson wrote:
> Hi,
>
> On Mon, Jun 1, 2020 at 3:03 PM Douglas Anderson wrote:
>>
>> The newly-introduced function min_loaded_core() iterates over all of
>> the venus instances an tries to figure out how much load each instance
>> is putting on each core. Not all instances, however, might be fully
>> initialized. Specifically the "codec_freq_data" is initialized as
>> part of vdec_queue_setup(), but an instance may already be in the list
>> of all instances before that time.
>>
>> Let's band-aid this by checking to see if codec_freq_data is NULL
>> before dereferencing.
>>
>> NOTE: without this fix I was running into a crash. Specifically there
>> were two venus instances. One was doing start_streaming. The other
>> was midway through queue_setup but hadn't yet gotten to initting
>> "codec_freq_data".
>>
>> Fixes: eff82f79c562 ("media: venus: introduce core selection")
>> Signed-off-by: Douglas Anderson
>> ---
>> I'm not massively happy about this commit but it's the best I could
>> come up with without being much more of an expert in the venus codec.
>> If someone has a better patch then please just consider this one to be
>> a bug report and feel free to submit a better fix! :-)
>>
>> In general I wonder a little bit about whether it's safe to be peeking
>> at all the instances without grabbing the "inst->lock" on each one. I
>> guess it is since we do it both here and in load_scale_v4() but I
>> don't know why.
>>
>> One thought I had was that we could fully avoid accessing the other
>> instances, at least in min_loaded_core(), by just keeping track of
>> "core1_load" and "core2_load" in "struct venus_core". Whenever we add
>> a new instance we could add to the relevant variables and whenever we
>> release an instance we could remove. Such a change seems cleaner but
>> would require someone to test to make sure we didn't miss any case
>> (AKA we always properly added/removed our load from the globals).
Thanks for the suggestion (I also thought about something similar). I
will try to cook something.
>>
>> drivers/media/platform/qcom/venus/pm_helpers.c | 2 ++
>> 1 file changed, 2 insertions(+)
>
> This fixes the same crash as the patch:
>
> https://lore.kernel.org/r/1588314480-22409-1-git-send-email-man...@codeaurora.org
>
I'm going to take this approach because it takes into account the state
of the instance. The instance could be opened/created but the streaming
could not be started in near future, so it shouldn't be correct to take
its load when doing the calculations.
--
regards,
Stan
Re: Strange problem with SCTP+IPv6
On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
>
> I've stumbled upon a strange problem with SCTP and IPv6. If I create an
> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it,
> then I make a connection to it using ::1, the connection will drop after
> 2.5 seconds with an ECONNRESET error.
>
> It only happens on SCTP, it doesn't have the issue if you connect to a
> full IPv6 address instead of ::1, and it doesn't happen if you don't
> set IPV6_V6ONLY. I have verified current end of tree kernel.org.
> I tried on an ARM system and x86_64.
>
> I haven't dug into the kernel to see if I could find anything yet, but I
> thought I would go ahead and report it. I am attaching a reproducer.
> Basically, compile the following code:
The code only set IPV6_V6ONLY on server side, so the client side will
still bind all the local ipv4 addresses (as you didn't call bind() to
bind any specific addresses ). Then after the connection is created,
the client will send HB on the v4 paths to the server. The server
will abort the connection, as it can't support v4.
So you can work around it by either:
- set IPV6_V6ONLY on client side.
or
- bind to the specific v6 addresses on the client side.
I don't see RFC said something about this.
So it may not be a good idea to change the current behaviour
to not establish the connection in this case, which may cause regression.
>
> gcc -g -o sctptest -Wall sctptest.c
>
> and run it in one window as a server:
>
> ./sctptest a
>
> (Pass in any option to be the server) and run the following in another
> window as the client:
>
> ./sctptest
>
> It disconnects after about 2.5 seconds. If it works, it should just sit
> there forever.
>
> -corey
>
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> static int
> getaddr(const char *addr, const char *port, bool listen,
> struct addrinfo **rai)
> {
> struct addrinfo *ai, hints;
>
> memset(&hints, 0, sizeof(hints));
> hints.ai_flags = AI_ADDRCONFIG;
> if (listen)
> hints.ai_flags |= AI_PASSIVE;
> hints.ai_family = AF_UNSPEC;
> hints.ai_socktype = SOCK_STREAM;
> hints.ai_protocol = IPPROTO_SCTP;
> if (getaddrinfo(addr, port, &hints, &ai)) {
> perror("getaddrinfo");
> return -1;
> }
>
> *rai = ai;
> return 0;
> }
>
> static int
> waitread(int s)
> {
> char data[1];
> ssize_t rv;
>
> rv = read(s, data, sizeof(data));
> if (rv == -1) {
> perror("read");
> return -1;
> }
> printf("Read %d bytes\n", (int) rv);
> return 0;
> }
>
> static int
> do_server(void)
> {
> int err, ls, s, optval;
> struct addrinfo *ai;
>
> printf("Server\n");
>
> err = getaddr("::", "3023", true, &ai);
> if (err)
> return err;
>
> ls = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol);
> if (ls == -1) {
> perror("socket");
> return -1;
> }
>
> optval = 1;
> if (setsockopt(ls, SOL_SOCKET, SO_REUSEADDR,
>(void *)&optval, sizeof(optval)) == -1) {
> perror("setsockopt reuseaddr");
> return -1;
> }
>
> /* Comment this out and it will work. */
> if (setsockopt(ls, IPPROTO_IPV6, IPV6_V6ONLY, &optval,
>sizeof(optval)) == -1) {
> perror("setsockopt ipv6 only");
> return -1;
> }
>
> err = bind(ls, ai->ai_addr, ai->ai_addrlen);
> if (err == -1) {
> perror("bind");
> return -1;
> }
>
> err = listen(ls, 5);
> if (err == -1) {
> perror("listen");
> return -1;
> }
>
> s = accept(ls, NULL, NULL);
> if (s == -1) {
> perror("accept");
> return -1;
> }
>
> close(ls);
>
> err = waitread(s);
> close(s);
> return err;
> }
>
> static int
> do_client(void)
> {
> int err, s;
> struct addrinfo *ai;
>
> printf("Client\n");
>
> err = getaddr("::1", "3023", false, &ai);
> if (err)
> return err;
>
> s = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol);
> if (s == -1) {
> perror("socket");
> return -1;
> }
>
> err = connect(s, ai->ai_addr, ai->ai_addrlen);
> if (err == -1) {
> perror("connect");
> return -1;
> }
>
> err = waitread(s);
> close(s);
> return err;
> }
>
> int
> main(int argc, char *argv[])
> {
> int err;
>
> if (argc > 1)
> err = do_server();
> else
> err = do_client();
> return !!err;
> }
>
Re: [PATCH v2 0/6] soundwire: intel: transition to 3 steps initialization
On 01-06-20, 02:20, Bard Liao wrote: > This series is to split the original "soundwire: intel: transition to 3 > steps initialization" patch into different patches for better review. > It also address comments from Vinod. Applied all, thanks -- ~Vinod
Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU
On Mon, Jun 01, 2020 at 12:41:04PM -0500, Bjorn Helgaas wrote: > I found this [1] from Paul Menzel, which was a slowdown caused by > quirk_usb_early_handoff(). I think the real problem is individual > quirks that take a long time. > > The PCI_FIXUP_IOMMU things we're talking about should be fast, and of > course, they're only run for matching devices anyway. So I'd rather > keep them as PCI_FIXUP_FINAL than add a whole new phase. Okay, so if it is not a performance problem, then I am fine with using PCI_FIXUP_FINAL. But I dislike calling the fixups from IOMMU code, there must be a better solution. Regards, Joerg > [1] > https://lore.kernel.org/linux-pci/b1533fd5-1fae-7256-9597-36d3d5de9...@molgen.mpg.de/
Re: [v3] coccinelle: misc: add array_size_dup script to detect missed overflow checks
>> I suggest to take another look at information from the section >> “2.4.3. Formatted string literals”. >> https://docs.python.org/3/reference/lexical_analysis.html#f-strings >> >> This software documentation provides the information “New in version 3.6”. >> Will such a detail trigger any more software development consequences? > > Thanks foor this information. Denis, would it be possible to express the > code in a more portable way? Which is the last revision of the Python programming language that you would like to support so far? Regards, Markus
Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU
On Thu, Jun 04, 2020 at 09:33:07PM +0800, Zhangfei Gao wrote: > +++ b/drivers/iommu/iommu.c > @@ -2418,6 +2418,10 @@ int iommu_fwspec_init(struct device *dev, struct > fwnode_handle *iommu_fwnode, > fwspec->iommu_fwnode = iommu_fwnode; > fwspec->ops = ops; > dev_iommu_fwspec_set(dev, fwspec); > + > + if (dev_is_pci(dev)) > + pci_fixup_device(pci_fixup_final, to_pci_dev(dev)); > + That's not going to fly, I don't think we should run the fixups twice, and they should not be run from IOMMU code. Is the only reason for this second pass that iommu_fwspec is not yet allocated when it runs the first time? I ask because it might be easier to just allocate the struct earlier then. Regards, Joerg
Re: [PATCH -next] arch/x86: Return value from notify_die should to be checked.
On Mon, Jun 22, 2020 at 5:46 PM Peter Zijlstra wrote: > > On Mon, Jun 22, 2020 at 11:17:51AM +0200, Boris Petkov wrote: > > On June 22, 2020 10:52:23 AM GMT+02:00, Alexandre Chartre > > wrote: > > > So the appropriate change to make Coverity happy > > > > Or we can stop "fixing" the kernel in order to shut up tools and not do > > anything. > > Agreed, no change required here. Ok, thanks for everyone.
Re: [PATCH] soundwire: qcom: Constify static structs
On 10-06-20, 01:00, Rikard Falkeborn wrote:
> qcom_swrm_port_ops and qcom_swrm_ops are not modified and can be made
> const to allow the compiler to put them in read-only memory.
>
> Before:
>textdata bss dec hex filename
> 182663056 256 21578544a drivers/soundwire/qcom.o
>
> After:
>textdata bss dec hex filename
> 184262896 256 21578544a drivers/soundwire/qcom.o
Applied, thanks
>
> Signed-off-by: Rikard Falkeborn
> ---
> drivers/soundwire/qcom.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c
> index a1c2a44a3b4d..915c2cf0c274 100644
> --- a/drivers/soundwire/qcom.c
> +++ b/drivers/soundwire/qcom.c
> @@ -406,13 +406,13 @@ static int qcom_swrm_port_enable(struct sdw_bus *bus,
> return ctrl->reg_write(ctrl, reg, val);
> }
>
> -static struct sdw_master_port_ops qcom_swrm_port_ops = {
> +static const struct sdw_master_port_ops qcom_swrm_port_ops = {
> .dpn_set_port_params = qcom_swrm_port_params,
> .dpn_set_port_transport_params = qcom_swrm_transport_params,
> .dpn_port_enable_ch = qcom_swrm_port_enable,
> };
>
> -static struct sdw_master_ops qcom_swrm_ops = {
> +static const struct sdw_master_ops qcom_swrm_ops = {
> .xfer_msg = qcom_swrm_xfer_msg,
> .pre_bank_switch = qcom_swrm_pre_bank_switch,
> };
> --
> 2.27.0
--
~Vinod
Re: DMA Engine: Transfer From Userspace
> On 22 June 2020 at 06:47 Vinod Koul wrote:
>
> On 21-06-20, 22:36, Federico Vaga wrote:
> > On Sun, Jun 21, 2020 at 12:54:57PM +0530, Vinod Koul wrote:
> > > On 19-06-20, 16:31, Dave Jiang wrote:
> > > >
> > > >
> > > > On 6/19/2020 3:47 PM, Federico Vaga wrote:
> > > > > Hello,
> > > > >
> > > > > is there the possibility of using a DMA engine channel from userspace?
> > > > >
> > > > > Something like:
> > > > > - configure DMA using ioctl() (or whatever configuration mechanism)
> > > > > - read() or write() to trigger the transfer
> > > > >
> > > >
> > > > I may have supposedly promised Vinod to look into possibly providing
> > > > something like this in the future. But I have not gotten around to do
> > > > that
> > > > yet. Currently, no such support.
> > >
> > > And I do still have serious reservations about this topic :) Opening up
> > > userspace access to DMA does not sound very great from security point of
> > > view.
> >
> > I was thinking about a dedicated module, and not something that the DMA
> > engine
> > offers directly. You load the module only if you need it (like the test
> > module)
>
> But loading that module would expose dma to userspace.
> >
> > > Federico, what use case do you have in mind?
> >
> > Userspace drivers
>
> more the reason not do do so, why cant a kernel driver be added for your
> usage?
by chance i have written a driver allowing dma from user space using a memcpy
like interface ;-)
now i am trying to get this code upstream but was hit by the fact that DMA_SG
is gone since Aug 2017 :-(
just let me introduce myself and the project:
- coding in C since '91
- coding in C++ since '98
- a lot of stuff not relevant for this ;-)
- working as a freelancer since Nov '19
- implemented a "dma-sg-proxy" driver for my client in Mar/Apr '20 to copy
camera frames from uncached memory to cached memory using a second dma on a
Zynq platform
- last week we figured out that we can not upgrade from "Xilinx 2019.2" (kernel
4.19.x) to "2020.1" (kernel 5.4.x) because the DMA_SG interface is gone
- subscribed to dmaengine on friday, saw the start of this discussion on
saturday
- talked to my client today if it is ok to try to revive DMA_SG and get our
driver upstream to avoid such problems in future
here the struct for the ioctl:
typedef struct {
unsigned int struct_size;
const void *src_user_ptr;
void *dst_user_ptr;
unsigned long length;
unsigned int timeout_in_ms;
} dma_sg_proxy_arg_t;
best regards,
Thomas
[PATCH] dt-bindings: ASoC: Convert UniPhier AIO audio system to json-schema
Convert the UniPhier AIO audio system binding to DT schema format.
Signed-off-by: Masahiro Yamada
---
.../sound/socionext,uniphier-aio.yaml | 73 +++
.../bindings/sound/uniphier,aio.txt | 45
2 files changed, 73 insertions(+), 45 deletions(-)
create mode 100644
Documentation/devicetree/bindings/sound/socionext,uniphier-aio.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/uniphier,aio.txt
diff --git
a/Documentation/devicetree/bindings/sound/socionext,uniphier-aio.yaml
b/Documentation/devicetree/bindings/sound/socionext,uniphier-aio.yaml
new file mode 100644
index ..bea8b06ff1b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/socionext,uniphier-aio.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/socionext,uniphier-aio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: UniPhier AIO audio system
+
+maintainers:
+ -
+
+properties:
+ compatible:
+enum:
+ - socionext,uniphier-ld11-aio
+ - socionext,uniphier-ld20-aio
+ - socionext,uniphier-pxs2-aio
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clock-names:
+const: aio
+
+ clocks:
+maxItems: 1
+
+ reset-names:
+const: aio
+
+ resets:
+maxItems: 1
+
+ socionext,syscon:
+description: |
+ Specifies a phandle to soc-glue, which is used for changing mode of
S/PDIF
+ signal pin to output from Hi-Z. This property is optional if you use I2S
+ signal pins only.
+$ref: "/schemas/types.yaml#/definitions/phandle"
+
+ "#sound-dai-cells":
+const: 1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clock-names
+ - clocks
+ - reset-names
+ - resets
+ - "#sound-dai-cells"
+
+examples:
+ - |
+audio@5600 {
+compatible = "socionext,uniphier-ld20-aio";
+reg = <0x5600 0x8>;
+interrupts = <0 144 4>;
+pinctrl-names = "default";
+pinctrl-0 = <&pinctrl_aout>;
+clock-names = "aio";
+clocks = <&sys_clk 40>;
+reset-names = "aio";
+resets = <&sys_rst 40>;
+#sound-dai-cells = <1>;
+socionext,syscon = <&soc_glue>;
+};
diff --git a/Documentation/devicetree/bindings/sound/uniphier,aio.txt
b/Documentation/devicetree/bindings/sound/uniphier,aio.txt
deleted file mode 100644
index 4ce68ed6f2f2..
--- a/Documentation/devicetree/bindings/sound/uniphier,aio.txt
+++ /dev/null
@@ -1,45 +0,0 @@
-Socionext UniPhier SoC audio driver
-
-The Socionext UniPhier audio subsystem consists of I2S and S/PDIF blocks in
-the same register space.
-
-Required properties:
-- compatible : should be one of the following:
- "socionext,uniphier-ld11-aio"
- "socionext,uniphier-ld20-aio"
- "socionext,uniphier-pxs2-aio"
-- reg : offset and length of the register set for the device.
-- interrupts : should contain I2S or S/PDIF interrupt.
-- pinctrl-names : should be "default".
-- pinctrl-0 : defined I2S signal pins for an external codec chip.
-- clock-names : should include following entries:
-"aio"
-- clocks : a list of phandle, should contain an entry for each
-entry in clock-names.
-- reset-names : should include following entries:
-"aio"
-- resets : a list of phandle, should contain an entry for each
-entry in reset-names.
-- #sound-dai-cells: should be 1.
-
-Optional properties:
-- socionext,syscon: a phandle, should contain soc-glue.
-The soc-glue is used for changing mode of S/PDIF signal pin
-to Output from Hi-Z. This property is optional if you use
-I2S signal pins only.
-
-Example:
- audio {
- compatible = "socionext,uniphier-ld20-aio";
- reg = <0x5600 0x8>;
- interrupts = <0 144 4>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_aout>;
- clock-names = "aio";
- clocks = <&sys_clk 40>;
- reset-names = "aio";
- resets = <&sys_rst 40>;
- #sound-dai-cells = <1>;
-
- socionext,syscon = <&sg>;
- };
--
2.25.1
Re: [PATCH] kernel/signal.c: Export symbol __lock_task_sighand
On 06/22, Christian Brauner wrote: > > On Mon, Jun 22, 2020 at 12:24:01PM +0200, Dominique Martinet wrote: > > Christian Brauner wrote on Mon, Jun 22, 2020: > > > On Mon, Jun 22, 2020 at 08:25:28AM +0200, Oleg Nesterov wrote: > > >> current->sighand is stable and can't go away. Unless "current" is > > >> exiting and > > >> has already passed exit_notify(). So I don't think net/9p needs this > > >> helper. > > > > > > From what I can gather from the thread (cf. [1]) that is linked in the > > > commit message the main motivation for all of this is sparse not being > > > happy and not some bug. (Maybe I'm not seeing something though.) > > > > > > The patch itself linked here doesn't seem to buy anything. I agree with > > > Oleg. Afaict, lock_task_sighand() would only be needed here if the task > > > wouldn't be current. So maybe it should just be dropped from the series. > > > > Sure. I honestly have no idea on what guarantees we have from the task > > being current here as opposed to any other task -- I guess that another > > thread calling exit for exemple would have to wait? > > When a thread in a non-trivial thread-group (sorry for the math > reference :)) execs it'll unshare its struct sighand. Well, not really... The execing threads will kill other other threads, then it will check if ->sighand should be unshared. The latter is very unlikely, I don't think CLONE_SIGHAND without CLONE_THREAD is actually used today. But this doesn't really matter. I mean, even if you race with another thread doing exec/exit/whatever, current->sighand is stable. Unless, again, current has already exited (called exit_notify()). > The new struct > sighand will be assigned using rcu_assign_pointer() so afaik (Paul or > Oleg can yell at me if I'm talking nonsense) any prior callers will see > the prior sighand value. Yes, but see above. If tsk is not current, then (in general) it is not safe to use tsk->sighand directly. It can can be changed by exec (as you explained), or you can hit tsk->sighand == NULL if you race with exit. Oleg.
[PATCH] dt-bindings: ASoC: Convert UniPhier EVEA codec to json-schema
Convert the UniPhier EVEA sound codec binding to DT schema format.
Signed-off-by: Masahiro Yamada
---
.../sound/socionext,uniphier-evea.yaml| 62 +++
.../bindings/sound/uniphier,evea.txt | 26
2 files changed, 62 insertions(+), 26 deletions(-)
create mode 100644
Documentation/devicetree/bindings/sound/socionext,uniphier-evea.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/uniphier,evea.txt
diff --git
a/Documentation/devicetree/bindings/sound/socionext,uniphier-evea.yaml
b/Documentation/devicetree/bindings/sound/socionext,uniphier-evea.yaml
new file mode 100644
index ..7ac1c0140d5d
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/socionext,uniphier-evea.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/socionext,uniphier-evea.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: UniPhier EVEA SoC-internal sound codec
+
+maintainers:
+ -
+
+properties:
+ compatible:
+const: socionext,uniphier-evea
+
+ reg:
+maxItems: 1
+
+ clock-names:
+items:
+ - const: evea
+ - const: exiv
+
+ clocks:
+minItems: 2
+maxItems: 2
+
+ reset-names:
+items:
+ - const: evea
+ - const: exiv
+ - const: adamv
+
+ resets:
+minItems: 3
+maxItems: 3
+
+ "#sound-dai-cells":
+const: 1
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - clock-names
+ - clocks
+ - reset-names
+ - resets
+ - "#sound-dai-cells"
+
+examples:
+ - |
+codec@5790 {
+compatible = "socionext,uniphier-evea";
+reg = <0x5790 0x1000>;
+clock-names = "evea", "exiv";
+clocks = <&sys_clk 41>, <&sys_clk 42>;
+reset-names = "evea", "exiv", "adamv";
+resets = <&sys_rst 41>, <&sys_rst 42>, <&adamv_rst 0>;
+#sound-dai-cells = <1>;
+};
diff --git a/Documentation/devicetree/bindings/sound/uniphier,evea.txt
b/Documentation/devicetree/bindings/sound/uniphier,evea.txt
deleted file mode 100644
index 3f31b235f18b..
--- a/Documentation/devicetree/bindings/sound/uniphier,evea.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Socionext EVEA - UniPhier SoC internal codec driver
-
-Required properties:
-- compatible : should be "socionext,uniphier-evea".
-- reg : offset and length of the register set for the device.
-- clock-names : should include following entries:
-"evea", "exiv"
-- clocks : a list of phandle, should contain an entry for each
-entries in clock-names.
-- reset-names : should include following entries:
-"evea", "exiv", "adamv"
-- resets : a list of phandle, should contain reset entries of
-reset-names.
-- #sound-dai-cells: should be 1.
-
-Example:
-
- codec {
- compatible = "socionext,uniphier-evea";
- reg = <0x5790 0x1000>;
- clock-names = "evea", "exiv";
- clocks = <&sys_clk 41>, <&sys_clk 42>;
- reset-names = "evea", "exiv", "adamv";
- resets = <&sys_rst 41>, <&sys_rst 42>, <&adamv_rst 0>;
- #sound-dai-cells = <1>;
- };
--
2.25.1
[PATCH v1] [media] saa7134: use generic power management
With the support of generic PM callbacks, drivers no longer need to use
legacy .suspend() and .resume() in which they had to maintain PCI states
changes and device's power state themselves. The required operations are
done by PCI core.
Compile-tested only.
Signed-off-by: Vaibhav Gupta
---
drivers/media/pci/saa7134/saa7134-core.c | 25
1 file changed, 8 insertions(+), 17 deletions(-)
diff --git a/drivers/media/pci/saa7134/saa7134-core.c
b/drivers/media/pci/saa7134/saa7134-core.c
index e4623ed2f831..eb01109d4f98 100644
--- a/drivers/media/pci/saa7134/saa7134-core.c
+++ b/drivers/media/pci/saa7134/saa7134-core.c
@@ -1370,10 +1370,8 @@ static void saa7134_finidev(struct pci_dev *pci_dev)
kfree(dev);
}
-#ifdef CONFIG_PM
-
/* resends a current buffer in queue after resume */
-static int saa7134_buffer_requeue(struct saa7134_dev *dev,
+static int __maybe_unused saa7134_buffer_requeue(struct saa7134_dev *dev,
struct saa7134_dmaqueue *q)
{
struct saa7134_buf *buf, *next;
@@ -1397,8 +1395,9 @@ static int saa7134_buffer_requeue(struct saa7134_dev *dev,
return 0;
}
-static int saa7134_suspend(struct pci_dev *pci_dev , pm_message_t state)
+static int __maybe_unused saa7134_suspend(struct device *dev_d)
{
+ struct pci_dev *pci_dev = to_pci_dev(dev_d);
struct v4l2_device *v4l2_dev = pci_get_drvdata(pci_dev);
struct saa7134_dev *dev = container_of(v4l2_dev, struct saa7134_dev,
v4l2_dev);
@@ -1428,21 +1427,15 @@ static int saa7134_suspend(struct pci_dev *pci_dev ,
pm_message_t state)
if (dev->remote && dev->remote->dev->users)
saa7134_ir_close(dev->remote->dev);
- pci_save_state(pci_dev);
- pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state));
-
return 0;
}
-static int saa7134_resume(struct pci_dev *pci_dev)
+static int __maybe_unused saa7134_resume(struct device *dev_d)
{
- struct v4l2_device *v4l2_dev = pci_get_drvdata(pci_dev);
+ struct v4l2_device *v4l2_dev = dev_get_drvdata(dev_d);
struct saa7134_dev *dev = container_of(v4l2_dev, struct saa7134_dev,
v4l2_dev);
unsigned long flags;
- pci_set_power_state(pci_dev, PCI_D0);
- pci_restore_state(pci_dev);
-
/* Do things that are done in saa7134_initdev ,
except of initializing memory structures.*/
@@ -1490,7 +1483,6 @@ static int saa7134_resume(struct pci_dev *pci_dev)
return 0;
}
-#endif
/* --- */
@@ -1522,15 +1514,14 @@ EXPORT_SYMBOL(saa7134_ts_unregister);
/* --- */
+static SIMPLE_DEV_PM_OPS(saa7134_pm_ops, saa7134_suspend, saa7134_resume);
+
static struct pci_driver saa7134_pci_driver = {
.name = "saa7134",
.id_table = saa7134_pci_tbl,
.probe= saa7134_initdev,
.remove = saa7134_finidev,
-#ifdef CONFIG_PM
- .suspend = saa7134_suspend,
- .resume = saa7134_resume
-#endif
+ .driver.pm = &saa7134_pm_ops,
};
static int __init saa7134_init(void)
--
2.27.0
Re: Good idea to rename files in include/uapi/ ?
On Mon, Jun 22, 2020 at 01:37:09PM +0200, Jan Engelhardt wrote: > > On Monday 2020-06-15 01:34, Alexander A. Klimov wrote: > >> > >> A header file rename is no problem. We even have dummy headers > > Hmm.. if I understand all of you correctly, David, Stefano, Pablo and Al say > > like no, not a good idea, but only you, Jan, say like should be no problem. > > > > Jan, do you have anything like commit messages in mainline or public emails > > from maintainers confirming your opinion? > > I had already given the commit with the (email) message: > > >> Just look at xt_MARK.h, all it does is include xt_mark.h. Cf. > >> 28b949885f80efb87d7cebdcf879c99db12c37bd . Why rename this in 2020 ?
