Re: [PATCH v2 3/4] doc/vm: fix typo in the hugetlb admin documentation

[Baoquan He]

On 07/23/20 at 10:47am, Anshuman Khandual wrote:
> 
> 
> On 07/23/2020 08:52 AM, Baoquan He wrote:
> > Change 'pecify' to 'Specify'.
> > 
> > Signed-off-by: Baoquan He 
> > Reviewed-by: Mike Kravetz 
> > Reviewed-by: David Hildenbrand 
> > ---
> >  Documentation/admin-guide/mm/hugetlbpage.rst | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst 
> > b/Documentation/admin-guide/mm/hugetlbpage.rst
> > index 015a5f7d7854..f7b1c7462991 100644
> > --- a/Documentation/admin-guide/mm/hugetlbpage.rst
> > +++ b/Documentation/admin-guide/mm/hugetlbpage.rst
> > @@ -131,7 +131,7 @@ hugepages
> > parameter is preceded by an invalid hugepagesz parameter, it will
> > be ignored.
> >  default_hugepagesz
> > -   pecify the default huge page size.  This parameter can
> > +   Specify the default huge page size.  This parameter can
> > only be specified once on the command line.  default_hugepagesz can
> > optionally be followed by the hugepages parameter to preallocate a
> > specific number of huge pages of default size.  The number of default
> > 
> 
> This does not apply on 5.8-rc6 and the original typo seems to be missing
> there as well. This section was introduced recently with following commit.
> 
>  282f4214384e ("hugetlbfs: clean up command line processing")

Thanks a lot for reviewing. This patchset is based on the latest
next/master branch, seems below commit introduced the typo which is
later than commit 282f4214384e, it haven't been merged into mainline
tree.

commit 72a3e3e25a5142284c6bc76ecf170c2a18dcdf6e
Author: Mauro Carvalho Chehab 
Date:   Tue Jun 23 09:09:06 2020 +0200

docs: hugetlbpage.rst: fix some warnings

Re: [PATCH v4 bpf-next 2/4] bpf: fail PERF_EVENT_IOC_SET_BPF when bpf_get_[stack|stackid] cannot work

[Alexei Starovoitov]

On Wed, Jul 22, 2020 at 11:42:08AM -0700, Song Liu wrote:
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 856d98c36f562..f77d009fcce95 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -9544,6 +9544,24 @@ static int perf_event_set_bpf_handler(struct 
> perf_event *event, u32 prog_fd)
>   if (IS_ERR(prog))
>   return PTR_ERR(prog);
>  
> + if (event->attr.precise_ip &&
> + prog->call_get_stack &&
> + (!(event->attr.sample_type & __PERF_SAMPLE_CALLCHAIN_EARLY) ||
> +  event->attr.exclude_callchain_kernel ||
> +  event->attr.exclude_callchain_user)) {
> + /*
> +  * On perf_event with precise_ip, calling bpf_get_stack()
> +  * may trigger unwinder warnings and occasional crashes.
> +  * bpf_get_[stack|stackid] works around this issue by using
> +  * callchain attached to perf_sample_data. If the
> +  * perf_event does not full (kernel and user) callchain
> +  * attached to perf_sample_data, do not allow attaching BPF
> +  * program that calls bpf_get_[stack|stackid].
> +  */
> + bpf_prog_put(prog);
> + return -EINVAL;

I suspect this will be a common error. bpftrace and others will be hitting
this issue and would need to fix how they do perf_event_open.
But EINVAL is too ambiguous and sys_perf_event_open has no ability to
return a string.
So how about we pick some different errno here to make future debugging
a bit less painful?
May be EBADFD or EPROTO or EPROTOTYPE ?
I think anything would be better than EINVAL.

Re: linux-next: build failure after merge of the scsi-mkp tree

[Stephen Rothwell]

Hi all,

On Tue, 21 Jul 2020 16:30:45 +1000 Stephen Rothwell  
wrote:
>
> After merging the scsi-mkp tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> ERROR: modpost: "exynos_ufs_dump_info" [drivers/scsi/ufs/ufs-exynos.ko] 
> undefined!
> ERROR: modpost: "exynos_ufs_init_dbg" [drivers/scsi/ufs/ufs-exynos.ko] 
> undefined!
> ERROR: modpost: "exynos_ufs_cmd_log_start" [drivers/scsi/ufs/ufs-exynos.ko] 
> undefined!
> 
> Caused by commits
> 
>   c3b5e96ef515 ("scsi: ufs: exynos: Introduce command history")
>   957ee40d413b ("scsi: ufs: exynos: Implement dbg_register_dump")
> 
> I applied the following patch for now.
> 
> From 6535b25fb253c7f25bf924655edb2b22fdaeb545 Mon Sep 17 00:00:00 2001
> From: Stephen Rothwell 
> Date: Tue, 21 Jul 2020 16:26:05 +1000
> Subject: [PATCH] scsi: ufs: exynos: mark debugging as broken
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/scsi/ufs/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
> index 2c31b33f0adc..925f8de62f6d 100644
> --- a/drivers/scsi/ufs/Kconfig
> +++ b/drivers/scsi/ufs/Kconfig
> @@ -178,6 +178,7 @@ config SCSI_UFS_EXYNOS_DBG
>   bool "EXYNOS specific debug functions"
>   default n
>   depends on SCSI_UFS_EXYNOS
> + depends on BROKEN
>   help
> This selects EXYNOS specific functions to get and even print
> debug information to see what's happening at both command
> -- 
> 2.27.0

This build failure now applies to the scsi tree.
-- 
Cheers,
Stephen Rothwell


pgpVpM1shbijD.pgp
Description: OpenPGP digital signature

Re: [PATCH 2/4] i2c: mediatek: Support DMA mask range over 33-bits

[Qii Wang]

On Wed, 2020-07-22 at 17:38 +0200, Matthias Brugger wrote:
> 
> On 22/07/2020 14:31, Qii Wang wrote:
> > Replace 'support_33bits with 'dma_max_support' for DMA mask
> > operation, and replace 'mtk_i2c_set_4g_mode' with 'upper_32_bits'.
> 
> Please explain more in detail what you are doing and how this fits to the way 
> the HW works.
> 

As Yingjoe sir said, Newer MTK chip support more than 8GB of dram, and
the register TX/RX_4G_MODE of APDMA has added corresponding bit to
support.So we Replace support_33bits with more general dma_max_support.I
will modify the title and commit as :
i2c: mediatek: Add access to more than 8GB dram in i2c driver
Newer MTK chip support more than 8GB of dram. Replace support_33bits
with more general dma_max_support and remove mtk_i2c_set_4g_mode.

> > 
> > Signed-off-by: Qii Wang 
> > ---
> >   drivers/i2c/busses/i2c-mt65xx.c | 37 +
> >   1 file changed, 17 insertions(+), 20 deletions(-)
> > 
> > diff --git a/drivers/i2c/busses/i2c-mt65xx.c 
> > b/drivers/i2c/busses/i2c-mt65xx.c
> > index e6b984a..e475877 100644
> > --- a/drivers/i2c/busses/i2c-mt65xx.c
> > +++ b/drivers/i2c/busses/i2c-mt65xx.c
> > @@ -209,6 +209,7 @@ struct mtk_i2c_compatible {
> > unsigned char dma_sync: 1;
> > unsigned char ltiming_adjust: 1;
> > unsigned char apdma_sync: 1;
> > +   unsigned char max_dma_support;
> >   };
> >   
> >   struct mtk_i2c_ac_timing {
> > @@ -311,11 +312,11 @@ struct i2c_spec_values {
> > .dcm = 1,
> > .auto_restart = 1,
> > .aux_len_reg = 1,
> > -   .support_33bits = 1,
> > .timing_adjust = 1,
> > .dma_sync = 0,
> > .ltiming_adjust = 0,
> > .apdma_sync = 0,
> > +   .max_dma_support = 33,
> >   };
> >   
> >   static const struct mtk_i2c_compatible mt6577_compat = {
> > @@ -325,11 +326,11 @@ struct i2c_spec_values {
> > .dcm = 1,
> > .auto_restart = 0,
> > .aux_len_reg = 0,
> > -   .support_33bits = 0,
> > .timing_adjust = 0,
> > .dma_sync = 0,
> > .ltiming_adjust = 0,
> > .apdma_sync = 0,
> > +   .max_dma_support = 32,
> >   };
> >   
> >   static const struct mtk_i2c_compatible mt6589_compat = {
> > @@ -339,11 +340,11 @@ struct i2c_spec_values {
> > .dcm = 0,
> > .auto_restart = 0,
> > .aux_len_reg = 0,
> > -   .support_33bits = 0,
> > .timing_adjust = 0,
> > .dma_sync = 0,
> > .ltiming_adjust = 0,
> > .apdma_sync = 0,
> > +   .max_dma_support = 32,
> >   };
> >   
> >   static const struct mtk_i2c_compatible mt7622_compat = {
> > @@ -353,11 +354,11 @@ struct i2c_spec_values {
> > .dcm = 1,
> > .auto_restart = 1,
> > .aux_len_reg = 1,
> > -   .support_33bits = 0,
> > .timing_adjust = 0,
> > .dma_sync = 0,
> > .ltiming_adjust = 0,
> > .apdma_sync = 0,
> > +   .max_dma_support = 32,
> >   };
> >   
> >   static const struct mtk_i2c_compatible mt8173_compat = {
> > @@ -366,11 +367,11 @@ struct i2c_spec_values {
> > .dcm = 1,
> > .auto_restart = 1,
> > .aux_len_reg = 1,
> > -   .support_33bits = 1,
> > .timing_adjust = 0,
> > .dma_sync = 0,
> > .ltiming_adjust = 0,
> > .apdma_sync = 0,
> > +   .max_dma_support = 33,
> >   };
> >   
> >   static const struct mtk_i2c_compatible mt8183_compat = {
> > @@ -380,11 +381,11 @@ struct i2c_spec_values {
> > .dcm = 0,
> > .auto_restart = 1,
> > .aux_len_reg = 1,
> > -   .support_33bits = 1,
> > .timing_adjust = 1,
> > .dma_sync = 1,
> > .ltiming_adjust = 1,
> > .apdma_sync = 0,
> > +   .max_dma_support = 33,
> >   };
> >   
> >   static const struct of_device_id mtk_i2c_of_match[] = {
> > @@ -796,11 +797,6 @@ static int mtk_i2c_set_speed(struct mtk_i2c *i2c, 
> > unsigned int parent_clk)
> > return 0;
> >   }
> >   
> > -static inline u32 mtk_i2c_set_4g_mode(dma_addr_t addr)
> > -{
> > -   return (addr & BIT_ULL(32)) ? I2C_DMA_4G_MODE : I2C_DMA_CLR_FLAG;
> 
> I2C_DMA_4G_MODE define could now be deleted as well.
> 
> Regards,
> Matthias
> 
> > -}
> > -
> >   static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
> >int num, int left_num)
> >   {
> > @@ -885,8 +881,8 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, 
> > struct i2c_msg *msgs,
> > return -ENOMEM;
> > }
> >   
> > -   if (i2c->dev_comp->support_33bits) {
> > -   reg_4g_mode = mtk_i2c_set_4g_mode(rpaddr);
> > +   if (i2c->dev_comp->max_dma_support > 32) {
> > +   reg_4g_mode = upper_32_bits(rpaddr);
> > writel(reg_4g_mode, i2c->pdmabase + OFFSET_RX_4G_MODE);
> > }
> >   
> > @@ -908,8 +904,8 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, 
> > struct i2c_msg *msgs,
> > return -ENOMEM;
> > }
> >   
> > -   if (i2c->dev_comp->support_33bits) {
> > -   reg_4g_mode = mtk_i2c_set_4g_mode(wpaddr);
> > +   if (i2c->dev_comp->max_dma_support > 

[PATCH] ARM: dts: imx7d-sdb: Add notes for audio sound card

[Shengjiu Wang]

Configure the SAI device node, configure audio clock
and pinctrl.

Enable the audio sound card, which use the SAI1 and
wm8960, and enable headphone detection.

Signed-off-by: Shengjiu Wang 
---
 arch/arm/boot/dts/imx7d-sdb.dts | 81 +
 1 file changed, 81 insertions(+)

diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index 17cca8a9f77b..b50b19f2d0f1 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -146,6 +146,24 @@ panel_in: endpoint {
};
};
};
+
+   sound {
+   compatible = "fsl,imx7d-evk-wm8960",
+"fsl,imx-audio-wm8960";
+   model = "wm8960-audio";
+   audio-cpu = <>;
+   audio-codec = <>;
+   hp-det-gpio = < 28 GPIO_ACTIVE_HIGH>;
+   audio-routing =
+   "Headphone Jack", "HP_L",
+   "Headphone Jack", "HP_R",
+   "Ext Spk", "SPK_LP",
+   "Ext Spk", "SPK_LN",
+   "Ext Spk", "SPK_RP",
+   "Ext Spk", "SPK_RN",
+   "LINPUT1", "AMIC",
+   "AMIC", "MICB";
+   };
 };
 
  {
@@ -363,6 +381,13 @@ codec: wm8960@1a {
clocks = < IMX7D_AUDIO_MCLK_ROOT_CLK>;
clock-names = "mclk";
wlf,shared-lrclk;
+   wlf,hp-cfg = <2 2 3>;
+   wlf,gpio-cfg = <1 3>;
+   assigned-clocks = < IMX7D_AUDIO_MCLK_ROOT_SRC>,
+ < IMX7D_PLL_AUDIO_POST_DIV>,
+ < IMX7D_AUDIO_MCLK_ROOT_CLK>;
+   assigned-clock-parents = < IMX7D_PLL_AUDIO_POST_DIV>;
+   assigned-clock-rates = <0>, <884736000>, <12288000>;
};
 };
 
@@ -391,6 +416,28 @@ _1p2 {
vin-supply = <_reg>;
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_sai1>;
+   assigned-clocks = < IMX7D_SAI1_ROOT_SRC>,
+ < IMX7D_PLL_AUDIO_POST_DIV>,
+ < IMX7D_SAI1_ROOT_CLK>;
+   assigned-clock-parents = < IMX7D_PLL_AUDIO_POST_DIV>;
+   assigned-clock-rates = <0>, <884736000>, <36864000>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_sai3 _sai3_mclk>;
+   assigned-clocks = < IMX7D_SAI3_ROOT_SRC>,
+ < IMX7D_PLL_AUDIO_POST_DIV>,
+ < IMX7D_SAI3_ROOT_CLK>;
+   assigned-clock-parents = < IMX7D_PLL_AUDIO_POST_DIV>;
+   assigned-clock-rates = <0>, <884736000>, <36864000>;
+   status = "okay";
+};
+
 _pwrkey {
status = "okay";
 };
@@ -550,6 +597,7 @@ MX7D_PAD_SD2_WP__GPIO5_IO10 0x59
pinctrl_hog: hoggrp {
fsl,pins = <
MX7D_PAD_ECSPI2_SS0__GPIO4_IO23 0x34  
/* bt reg on */
+   MX7D_PAD_EPDC_BDR0__GPIO2_IO28  0x59  
/* headphone detect */
>;
};
 
@@ -615,6 +663,33 @@ MX7D_PAD_LCD_RESET__LCD_RESET  0x79
>;
};
 
+   pinctrl_sai1: sai1grp {
+   fsl,pins = <
+   MX7D_PAD_SAI1_MCLK__SAI1_MCLK   0x1f
+   MX7D_PAD_ENET1_RX_CLK__SAI1_TX_BCLK 0x1f
+   MX7D_PAD_ENET1_CRS__SAI1_TX_SYNC0x1f
+   MX7D_PAD_ENET1_COL__SAI1_TX_DATA0   0x30
+   MX7D_PAD_ENET1_TX_CLK__SAI1_RX_DATA00x1f
+   >;
+   };
+
+   pinctrl_sai2: sai2grp {
+   fsl,pins = <
+   MX7D_PAD_SAI2_TX_BCLK__SAI2_TX_BCLK 0x1f
+   MX7D_PAD_SAI2_TX_SYNC__SAI2_TX_SYNC 0x1f
+   MX7D_PAD_SAI2_TX_DATA__SAI2_TX_DATA00x30
+   MX7D_PAD_SAI2_RX_DATA__SAI2_RX_DATA00x1f
+   >;
+   };
+
+   pinctrl_sai3: sai3grp {
+   fsl,pins = <
+   MX7D_PAD_UART3_TX_DATA__SAI3_TX_BCLK   0x1f
+   MX7D_PAD_UART3_CTS_B__SAI3_TX_SYNC 0x1f
+   MX7D_PAD_UART3_RTS_B__SAI3_TX_DATA00x30
+   >;
+   };
+
pinctrl_spi4: spi4grp {
fsl,pins = <
MX7D_PAD_GPIO1_IO09__GPIO1_IO9  0x59
@@ -776,4 +851,10 @@ pinctrl_usb_otg2_vbus_reg: usbotg2vbusreggrp {
MX7D_PAD_LPSR_GPIO1_IO07__GPIO1_IO7   0x14
>;
};
+
+   pinctrl_sai3_mclk: sai3grp_mclk {
+   fsl,pins = <
+   MX7D_PAD_LPSR_GPIO1_IO03__SAI3_MCLK 

Re: [PATCH 0/4] ASoC: fsl_asrc: allow selecting arbitrary clocks

[Nicolin Chen]

On Fri, Jul 17, 2020 at 01:16:42PM +0200, Arnaud Ferraris wrote:
> Hi Nic,
> 
> Le 02/07/2020 à 20:42, Nicolin Chen a écrit :
> > Hi Arnaud,
> > 
> > On Thu, Jul 02, 2020 at 04:22:31PM +0200, Arnaud Ferraris wrote:
> >> The current ASRC driver hardcodes the input and output clocks used for
> >> sample rate conversions. In order to allow greater flexibility and to
> >> cover more use cases, it would be preferable to select the clocks using
> >> device-tree properties.
> > 
> > We recent just merged a new change that auto-selecting internal
> > clocks based on sample rates as the first option -- ideal ratio
> > mode is the fallback mode now. Please refer to:
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20200702=d0250cf4f2abfbea64ed247230f08f5ae23979f0
> 
> While working on fixing the automatic clock selection (see my v3), I
> came across another potential issue, which would be better explained
> with an example:
>   - Input has sample rate 8kHz and uses clock SSI1 with rate 512kHz
>   - Output has sample rate 16kHz and uses clock SSI2 with rate 1024kHz
> 
> Let's say my v3 patch is merged, then the selected input clock will be
> SSI1, while the selected output clock will be SSI2. In that case, it's
> all good, as the driver will calculate the dividers right.
> 
> Now, suppose a similar board has the input wired to SSI2 and output to
> SSI1, meaning we're now in the following case:
>   - Input has sample rate 8kHz and uses clock SSI2 with rate 512kHz
>   - Output has sample rate 16kHz and uses clock SSI1 with rate 1024kHz
> (the same result is achieved during capture with the initial example
> setup, as input and output properties are then swapped)
> 
> In that case, the selected clocks will still be SSI1 for input (just
> because it appears first in the clock table), and SSI2 for output,
> meaning the calculated dividers will be:
>   - input: 512 / 16 => 32 (should be 64)
>   - output: 1024 / 8 => 128 (should be 64 here too)

I don't get the 32, 128 and 64 parts. Would you please to elaborate
a bit? What you said sounds to me like the driver calculates wrong
dividers?

RE: [RESEND PATCH v5] mm/zswap: move to use crypto_acomp API for hardware acceleration

[Song Bao Hua (Barry Song)]

> -Original Message-
> From: Song Bao Hua (Barry Song)
> Sent: Friday, July 17, 2020 1:51 AM
> To: a...@linux-foundation.org; herb...@gondor.apana.org.au;
> da...@davemloft.net
> Cc: linux-cry...@vger.kernel.org; linux...@kvack.org;
> linux-kernel@vger.kernel.org; Linuxarm ; Song Bao
> Hua (Barry Song) ; Luis Claudio R . Goncalves
> ; Sebastian Andrzej Siewior ;
> Mahipal Challa ; Seth Jennings
> ; Dan Streetman ; Vitaly Wool
> ; Wangzhou (B) ;
> fanghao (A) ; Colin Ian King
> 
> Subject: [RESEND PATCH v5] mm/zswap: move to use crypto_acomp API for
> hardware acceleration
> 
> Right now, all new ZIP drivers are adapted to crypto_acomp APIs rather than
> legacy crypto_comp APIs. Tradiontal ZIP drivers like lz4,lzo etc have been 
> also
> wrapped into acomp via scomp backend. But zswap.c is still using the old APIs.
> That means zswap won't be able to work on any new ZIP drivers in kernel.
> 
> This patch moves to use cryto_acomp APIs to fix the disconnected bridge
> between new ZIP drivers and zswap. It is probably the first real user to use
> acomp but perhaps not a good example to demonstrate how multiple acomp
> requests can be executed in parallel in one acomp instance.
> frontswap is doing page load and store page by page synchronously.
> swap_writepage() depends on the completion of frontswap_store() to decide if
> it should call __swap_writepage() to swap to disk.
> 
> However this patch creates multiple acomp instances, so multiple threads
> running on multiple different cpus can actually do (de)compression parallelly,
> leveraging the power of multiple ZIP hardware queues. This is also consistent
> with frontswap's page management model.
> 
> The old zswap code uses atomic context and avoids the race conditions while
> shared resources like zswap_dstmem are accessed. Here since acomp can sleep,
> per-cpu mutex is used to replace preemption-disable.
> 
> While it is possible to make mm/page_io.c and mm/frontswap.c support async
> (de)compression in some way, the entire design requires careful thinking and
> performance evaluation. For the first step, the base with fixed connection
> between ZIP drivers and zswap should be built.
> 
> Cc: Luis Claudio R. Goncalves 
> Cc: Sebastian Andrzej Siewior 
> Cc: Andrew Morton 
> Cc: Herbert Xu 
> Cc: David S. Miller 
> Cc: Mahipal Challa 
> Cc: Seth Jennings 
> Cc: Dan Streetman 
> Cc: Vitaly Wool 
> Cc: Zhou Wang 
> Cc: Hao Fang 
> Cc: Colin Ian King 
> Signed-off-by: Barry Song 
> ---
>  v5: address two comments from Sebastian Andrzej Siewior, thanks!
>1. use pointer rather than pointer's pointer for acomp_ctx;
>2. fix the race while multiple zpool exist while dynamically switching
>   comprossor and zpool type

Hi All,
Any further comments?

> 
>  mm/zswap.c | 183 -
>  1 file changed, 138 insertions(+), 45 deletions(-)
> 
> diff --git a/mm/zswap.c b/mm/zswap.c
> index fbb782924ccc..8e9c18b6fdd9 100644
> --- a/mm/zswap.c
> +++ b/mm/zswap.c
> @@ -24,8 +24,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
> 
>  #include 
>  #include 
> @@ -127,9 +129,17 @@ module_param_named(same_filled_pages_enabled,
> zswap_same_filled_pages_enabled,
>  * data structures
>  **/
> 
> +struct crypto_acomp_ctx {
> + struct crypto_acomp *acomp;
> + struct acomp_req *req;
> + struct crypto_wait wait;
> + u8 *dstmem;
> + struct mutex *mutex;
> +};
> +
>  struct zswap_pool {
>   struct zpool *zpool;
> - struct crypto_comp * __percpu *tfm;
> + struct crypto_acomp_ctx __percpu *acomp_ctx;
>   struct kref kref;
>   struct list_head list;
>   struct work_struct release_work;
> @@ -388,23 +398,43 @@ static struct zswap_entry
> *zswap_entry_find_get(struct rb_root *root,
>  * per-cpu code
>  **/
>  static DEFINE_PER_CPU(u8 *, zswap_dstmem);
> +/*
> + * If users dynamically change the zpool type and compressor at runtime, i.e.
> + * zswap is running, zswap can have more than one zpool on one cpu, but
> +they
> + * are sharing dtsmem. So we need this mutex to be per-cpu.
> + */
> +static DEFINE_PER_CPU(struct mutex *, zswap_mutex);
> 
>  static int zswap_dstmem_prepare(unsigned int cpu)  {
> + struct mutex *mutex;
>   u8 *dst;
> 
>   dst = kmalloc_node(PAGE_SIZE * 2, GFP_KERNEL, cpu_to_node(cpu));
>   if (!dst)
>   return -ENOMEM;
> 
> + mutex = kmalloc_node(sizeof(*mutex), GFP_KERNEL, cpu_to_node(cpu));
> + if (!mutex) {
> + kfree(dst);
> + return -ENOMEM;
> + }
> +
> + mutex_init(mutex);
>   per_cpu(zswap_dstmem, cpu) = dst;
> + per_cpu(zswap_mutex, cpu) = mutex;
>   return 0;
>  }
> 
>  static int zswap_dstmem_dead(unsigned int cpu)  {
> + struct mutex *mutex;
>   u8 *dst;
> 
> + mutex = per_cpu(zswap_mutex, cpu);
> + kfree(mutex);
> + per_cpu(zswap_mutex, cpu) 

RE: [PATCH devicetree 3/4] powerpc: dts: t1040rdb: put SGMII PHY under label

[Madalin Bucur (OSS)]

> -Original Message-
> From: Vladimir Oltean 
> Sent: Wednesday, July 22, 2020 8:24 PM
> To: robh...@kernel.org; shawn...@kernel.org; m...@ellerman.id.au;
> devicet...@vger.kernel.org
> Cc: b...@kernel.crashing.org; pau...@samba.org; linuxppc-
> d...@lists.ozlabs.org; linux-kernel@vger.kernel.org;
> net...@vger.kernel.org; Madalin Bucur (OSS) ;
> Radu-andrei Bulie ; fido_...@inbox.ru
> Subject: [PATCH devicetree 3/4] powerpc: dts: t1040rdb: put SGMII PHY
> under  label
> 
> We're going to add 8 more PHYs in a future patch. It is easier to follow
> the hardware description if we don't need to fish for the path of the
> MDIO controllers inside the SoC and just use the labels.
> 

Please align to the existing structure, it may be easier to add something
without paying attention to that but it's better to keep things organized.
This structure is used across all the device trees of the platforms using
DPAA, let's not start diverging now.

> Signed-off-by: Vladimir Oltean 
> ---
>  arch/powerpc/boot/dts/fsl/t1040rdb.dts | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/powerpc/boot/dts/fsl/t1040rdb.dts
> b/arch/powerpc/boot/dts/fsl/t1040rdb.dts
> index 65ff34c49025..40d7126dbe90 100644
> --- a/arch/powerpc/boot/dts/fsl/t1040rdb.dts
> +++ b/arch/powerpc/boot/dts/fsl/t1040rdb.dts
> @@ -59,12 +59,6 @@ ethernet@e4000 {
>   phy-handle = <_sgmii_2>;
>   phy-connection-type = "sgmii";
>   };
> -
> - mdio@fc000 {
> - phy_sgmii_2: ethernet-phy@3 {
> - reg = <0x03>;
> - };
> - };
>   };
>   };
> 
> @@ -76,3 +70,9 @@ cpld@3,0 {
>  };
> 
>  #include "t1040si-post.dtsi"
> +
> + {
> + phy_sgmii_2: ethernet-phy@3 {
> + reg = <0x3>;
> + };
> +};
> --
> 2.25.1

Re: [RFC PATCH 11/16] sched: migration changes for core scheduling(Internet mail)

[Li, Aubrey]

On 2020/7/23 12:23, benbjiang(蒋彪) wrote:
> Hi,
>> On Jul 23, 2020, at 11:35 AM, Li, Aubrey  wrote:
>>
>> On 2020/7/23 10:42, benbjiang(蒋彪) wrote:
>>> Hi,
>>>
 On Jul 23, 2020, at 9:57 AM, Li, Aubrey  wrote:

 On 2020/7/22 22:32, benbjiang(蒋彪) wrote:
> Hi,
>
>> On Jul 22, 2020, at 8:13 PM, Li, Aubrey  
>> wrote:
>>
>> On 2020/7/22 16:54, benbjiang(蒋彪) wrote:
>>> Hi, Aubrey,
>>>
 On Jul 1, 2020, at 5:32 AM, Vineeth Remanan Pillai 
  wrote:

 From: Aubrey Li 

 - Don't migrate if there is a cookie mismatch
  Load balance tries to move task from busiest CPU to the
  destination CPU. When core scheduling is enabled, if the
  task's cookie does not match with the destination CPU's
  core cookie, this task will be skipped by this CPU. This
  mitigates the forced idle time on the destination CPU.

 - Select cookie matched idle CPU
  In the fast path of task wakeup, select the first cookie matched
  idle CPU instead of the first idle CPU.

 - Find cookie matched idlest CPU
  In the slow path of task wakeup, find the idlest CPU whose core
  cookie matches with task's cookie

 - Don't migrate task if cookie not match
  For the NUMA load balance, don't migrate task to the CPU whose
  core cookie does not match with task's cookie

 Signed-off-by: Aubrey Li 
 Signed-off-by: Tim Chen 
 Signed-off-by: Vineeth Remanan Pillai 
 ---
 kernel/sched/fair.c  | 64 
 kernel/sched/sched.h | 29 
 2 files changed, 88 insertions(+), 5 deletions(-)

 diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
 index d16939766361..33dc4bf01817 100644
 --- a/kernel/sched/fair.c
 +++ b/kernel/sched/fair.c
 @@ -2051,6 +2051,15 @@ static void task_numa_find_cpu(struct 
 task_numa_env *env,
if (!cpumask_test_cpu(cpu, env->p->cpus_ptr))
continue;

 +#ifdef CONFIG_SCHED_CORE
 +  /*
 +   * Skip this cpu if source task's cookie does not match
 +   * with CPU's core cookie.
 +   */
 +  if (!sched_core_cookie_match(cpu_rq(cpu), env->p))
 +  continue;
 +#endif
 +
env->dst_cpu = cpu;
if (task_numa_compare(env, taskimp, groupimp, maymove))
break;
 @@ -5963,11 +5972,17 @@ find_idlest_group_cpu(struct sched_group 
 *group, struct task_struct *p, int this

/* Traverse only the allowed CPUs */
for_each_cpu_and(i, sched_group_span(group), p->cpus_ptr) {
 +  struct rq *rq = cpu_rq(i);
 +
 +#ifdef CONFIG_SCHED_CORE
 +  if (!sched_core_cookie_match(rq, p))
 +  continue;
 +#endif
 +
if (sched_idle_cpu(i))
return i;

if (available_idle_cpu(i)) {
 -  struct rq *rq = cpu_rq(i);
struct cpuidle_state *idle = idle_get_state(rq);
if (idle && idle->exit_latency < 
 min_exit_latency) {
/*
 @@ -6224,8 +6239,18 @@ static int select_idle_cpu(struct task_struct 
 *p, struct sched_domain *sd, int t
for_each_cpu_wrap(cpu, cpus, target) {
if (!--nr)
return -1;
 -  if (available_idle_cpu(cpu) || sched_idle_cpu(cpu))
 -  break;
 +
 +  if (available_idle_cpu(cpu) || sched_idle_cpu(cpu)) {
 +#ifdef CONFIG_SCHED_CORE
 +  /*
 +   * If Core Scheduling is enabled, select this 
 cpu
 +   * only if the process cookie matches core 
 cookie.
 +   */
 +  if (sched_core_enabled(cpu_rq(cpu)) &&
 +  p->core_cookie == 
 cpu_rq(cpu)->core->core_cookie)
>>> Why not also add similar logic in select_idle_smt to reduce 
>>> forced-idle? :)
>> We hit select_idle_smt after we scaned the entire LLC domain for idle 
>> cores
>> and idle cpus and failed,so IMHO, an idle smt is probably a good choice 
>> under
>> this scenario.
>
> AFAIC, selecting idle sibling with unmatched cookie will cause 
> unnecessary fored-idle, unfairness and 

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

[Alex Ghiti]

Le 7/21/20 à 7:36 PM, Palmer Dabbelt a écrit :

On Tue, 21 Jul 2020 16:11:02 PDT (-0700), b...@kernel.crashing.org wrote:

On Tue, 2020-07-21 at 14:36 -0400, Alex Ghiti wrote:

> > I guess I don't understand why this is necessary at all.
> > Specifically: why
> > can't we just relocate the kernel within the linear map?  That would
> > let the
> > bootloader put the kernel wherever it wants, modulo the physical
> > memory size we
> > support.  We'd need to handle the regions that are coupled to the
> > kernel's
> > execution address, but we could just put them in an explicit memory
> > region
> > which is what we should probably be doing anyway.
>
> Virtual relocation in the linear mapping requires to move the kernel
> physically too. Zong implemented this physical move in its KASLR RFC
> patchset, which is cumbersome since finding an available physical spot
> is harder than just selecting a virtual range in the vmalloc range.
>
> In addition, having the kernel mapping in the linear mapping prevents
> the use of hugepage for the linear mapping resulting in performance 
loss

> (at least for the GB that encompasses the kernel).
>
> Why do you find this "ugly" ? The vmalloc region is just a bunch of
> available virtual addresses to whatever purpose we want, and as 
noted by

> Zong, arm64 uses the same scheme.


I don't get it :-)

At least on powerpc we move the kernel in the linear mapping and it
works fine with huge pages, what is your problem there ? You rely on
punching small-page size holes in there ?


That was my original suggestion, and I'm not actually sure it's 
invalid.  It
would mean that both the kernel's physical and virtual addresses are set 
by the
bootloader, which may or may not be workable if we want to have an 
sv48+sv39
kernel.  My initial approach to sv48+sv39 kernels would be to just throw 
away
the sv39 memory on sv48 kernels, which would preserve the linear map but 
mean

that there is no single physical address that's accessible for both.  That
would require some coordination between the bootloader and the kernel as to
where it should be loaded, but maybe there's a better way to design the 
linear
map.  Right now we have a bunch of unwritten rules about where things 
need to

be loaded, which is a recipe for disaster.

We could copy the kernel around, but I'm not sure I really like that 
idea.  We
do zero the BSS right now, so it's not like we entirely rely on the 
bootloader
to set up the kernel image, but with the hart race boot scheme we have 
right

now we'd at least need to leave a stub sitting around.  Maybe we just throw
away SBI v0.1, though, that's why we called it all legacy in the first 
place.


My bigger worry is that anything that involves running the kernel at 
arbitrary
virtual addresses means we need a PIC kernel, which means every global 
symbol
needs an indirection.  That's probably not so bad for shared libraries, 
but the
kernel has a lot of global symbols.  PLT references probably aren't so 
scary,
as we have an incoherent instruction cache so the virtual function 
predictor

isn't that hard to build, but making all global data accesses GOT-relative
seems like a disaster for performance.  This fixed-VA thing really just 
exists

so we don't have to be full-on PIC.

In theory I think we could just get away with pretending that medany is 
PIC,
which I believe works as long as the data and text offset stays 
constant, you

you don't have any symbols between 2GiB and -2GiB (as those may stay fixed,
even in medany), and you deal with GP accordingly (which should work 
itself out
in the current startup code).  We rely on this for some of the early 
boot code

(and will soon for kexec), but that's a very controlled code base and we've
already had some issues.  I'd be much more comfortable adding an explicit
semi-PIC code model, as I tend to miss something when doing these sorts of
things and then we could at least add it to the GCC test runs and 
guarantee it
actually works.  Not really sure I want to deal with that, though.  It 
would,

however, be the only way to get random virtual addresses during kernel
execution.


At least in the old days, there were a number of assumptions that
the kernel text/data/bss resides in the linear mapping.


Ya, it terrified me as well.  Alex says arm64 puts the kernel in the 
vmalloc

region, so assuming that's the case it must be possible.  I didn't get that
from reading the arm64 port (I guess it's no secret that pretty much all 
I do

is copy their code)


See https://elixir.bootlin.com/linux/latest/source/arch/arm64/mm/mmu.c#L615.




If you change that you need to ensure that it's still physically
contiguous and you'll have to tweak __va and __pa, which might induce
extra overhead.


I'm operating under the assumption that we don't want to add an 
additional load
to virt2phys conversions.  arm64 bends over backwards to avoid the load, 
and

I'm assuming they have a reason for doing so.  Of course, if we're PIC then
maybe 

Re: [PATCH 1/2] ASoC: fsl-asoc-card: Support configuring dai fmt from DT

[Nicolin Chen]

On Tue, Jul 21, 2020 at 11:41:49AM +0800, Shengjiu Wang wrote:
> Support same propeties as simple card for configuring fmt
> from DT.
> In order to make this change compatible with old DT, these
> properties are optional.
> 
> Signed-off-by: Shengjiu Wang 

For both changes:
Acked-by: Nicolin Chen 

Re: [PATCH] mailbox: pcc: Put the PCCT table for error path

[Markus Elfring]

…
> In acpi_pcc_probe(), the PCCT table entries will be used as private
> data for communication chan at runtime, but the table should be put
> for error path.

* An imperative wording can be preferred for the change description,
  can't it?

* Will the tag “Fixes” become helpful for the commit message?

Regards,
Markus

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

[Alex Ghiti]

Hi Palmer,

Le 7/21/20 à 3:05 PM, Palmer Dabbelt a écrit :

On Tue, 21 Jul 2020 11:36:10 PDT (-0700), a...@ghiti.fr wrote:

Let's try to make progress here: I add linux-mm in CC to get feedback on
this patch as it blocks sv48 support too.


Sorry for being slow here.  I haven't replied because I hadn't really 
fleshed


No problem :)

out the design yet, but just so everyone's on the same page my problems 
with

this are:

* We waste vmalloc space on 32-bit systems, where there isn't a lot of it.
* On 64-bit systems the VA space around the kernel is precious because 
it's the
  only place we can place text (modules, BPF, whatever).  If we start 
putting
  the kernel in the vmalloc space then we either have to pre-allocate a 
bunch

  of space around it (essentially making it a fixed mapping anyway) or it
  becomes likely that we won't be able to find space for modules as they're
  loaded into running systems.


Let's note that we already have this issue for BPF and modules right now.
But by keeping the kernel 'in the end' of the vmalloc region, that's 
quite mitigate this problem: if we exhaust the vmalloc region in 64bit 
and then start allocating here, I think the whole system will have other 
problem.


* Relying on a relocatable kernel for sv48 support introduces a fairly 
large

  performance hit.


I understand the performance penalty but I struggle to it "fairly 
large": can we benchmark this somehow ?




Roughly, my proposal would be to:

* Leave the 32-bit memory map alone.  On 32-bit systems we can load modules
  anywhere and we only have one VA width, so we're not really solving any
  problems with these changes.


Ok that's possible although a lot of ifdef will get involved :)

* Staticly allocate a 2GiB portion of the VA space for all our text, as 
its own
  region.  We'd link/relocate the kernel here instead of around 
PAGE_OFFSET,
  which would decouple the kernel from the physical memory layout of the 
system.
  This would have the side effect of sorting out a bunch of bootloader 
headaches

  that we currently have.


This amounts to doing the same as this patch but instead of using the 
vmalloc region, we'd use our own right ? I believe we'd then lose the 
vmalloc facilities to allocate modules around this zone.



* Sort out how to maintain a linear map as the canonical hole moves around
  between the VA widths without adding a bunch of overhead to the 
virt2phys and
  friends.  This is probably going to be the trickiest part, but I think 
if we

  just change the page table code to essentially lie about VAs when an sv39
  system runs an sv48+sv39 kernel we could make it work -- there'd be some
  logical complexity involved, but it would remain fast.


I have to think about that.



This doesn't solve the problem of virtually relocatable kernels, but it 
does
let us decouple that from the sv48 stuff.  It also lets us stop relying 
on a

fixed physical address the kernel is loaded into, which is another thing I
don't like.



Agreed on this one.


I know this may be a more complicated approach, but there aren't any sv48
systems around right now so I just don't see the rush to support them,
particularly when there's a cost to what already exists (for those who 
haven't

been watching, so far all the sv48 patch sets have imposed a significant
performance penalty on all systems).



Alex



Alex

Le 7/9/20 à 7:11 AM, Alex Ghiti a écrit :

Hi Palmer,

Le 7/9/20 à 1:05 AM, Palmer Dabbelt a écrit :

On Sun, 07 Jun 2020 00:59:46 PDT (-0700), a...@ghiti.fr wrote:

This is a preparatory patch for relocatable kernel.

The kernel used to be linked at PAGE_OFFSET address and used to be
loaded
physically at the beginning of the main memory. Therefore, we could 
use

the linear mapping for the kernel mapping.

But the relocated kernel base address will be different from 
PAGE_OFFSET
and since in the linear mapping, two different virtual addresses 
cannot

point to the same physical address, the kernel mapping needs to lie
outside
the linear mapping.


I know it's been a while, but I keep opening this up to review it and
just
can't get over how ugly it is to put the kernel's linear map in the
vmalloc
region.

I guess I don't understand why this is necessary at all.
Specifically: why
can't we just relocate the kernel within the linear map?  That would
let the
bootloader put the kernel wherever it wants, modulo the physical
memory size we
support.  We'd need to handle the regions that are coupled to the
kernel's
execution address, but we could just put them in an explicit memory
region
which is what we should probably be doing anyway.


Virtual relocation in the linear mapping requires to move the kernel
physically too. Zong implemented this physical move in its KASLR RFC
patchset, which is cumbersome since finding an available physical spot
is harder than just selecting a virtual range in the vmalloc range.

In addition, having the kernel mapping in the linear mapping prevents
the use of hugepage for 

Re: [PATCH] ASoC: fsl_esai: add IRQF_SHARED for devm_request_irq

[Nicolin Chen]

On Thu, Jul 23, 2020 at 12:00:08PM +0800, Shengjiu Wang wrote:
> ESAI interfaces may share same interrupt line with EDMA on
> some platforms (e.g. i.MX8QXP, i.MX8QM).
> Add IRQF_SHARED flag to allow sharing the irq among several
> devices
> 
> Signed-off-by: Shengjiu Wang 
> Signed-off-by: Viorel Suman 

Acked-by: Nicolin Chen 

Re: 答复: [PATCH] USB:Fix kernel NULL pointer when unbind UHCI form vfio-pci

[Greg KH]

On Thu, Jul 23, 2020 at 02:59:55AM +, Weitao Wang(BJ-RD) wrote:
> CONFIDENTIAL NOTE:
> This email contains confidential or legally privileged information and is for 
> the sole use of its intended recipient. Any unauthorized review, use, copying 
> or forwarding of this email or the content of this email is strictly 
> prohibited.


This footer is not compatible with Linux mailing lists, sorry, I am not
allowed to respond to it.

greg k-h

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

[Alex Ghiti]

Hi Benjamin,

Le 7/21/20 à 7:11 PM, Benjamin Herrenschmidt a écrit :

On Tue, 2020-07-21 at 14:36 -0400, Alex Ghiti wrote:

I guess I don't understand why this is necessary at all.
Specifically: why
can't we just relocate the kernel within the linear map?  That would
let the
bootloader put the kernel wherever it wants, modulo the physical
memory size we
support.  We'd need to handle the regions that are coupled to the
kernel's
execution address, but we could just put them in an explicit memory
region
which is what we should probably be doing anyway.


Virtual relocation in the linear mapping requires to move the kernel
physically too. Zong implemented this physical move in its KASLR RFC
patchset, which is cumbersome since finding an available physical spot
is harder than just selecting a virtual range in the vmalloc range.

In addition, having the kernel mapping in the linear mapping prevents
the use of hugepage for the linear mapping resulting in performance loss
(at least for the GB that encompasses the kernel).

Why do you find this "ugly" ? The vmalloc region is just a bunch of
available virtual addresses to whatever purpose we want, and as noted by
Zong, arm64 uses the same scheme.


I don't get it :-)

At least on powerpc we move the kernel in the linear mapping and it
works fine with huge pages, what is your problem there ? You rely on
punching small-page size holes in there ?



ARCH_HAS_STRICT_KERNEL_RWX prevents the use of a hugepage for the kernel 
mapping in the direct mapping as it sets different permissions to 
different part of the kernel (data, text..etc).




At least in the old days, there were a number of assumptions that
the kernel text/data/bss resides in the linear mapping.

If you change that you need to ensure that it's still physically
contiguous and you'll have to tweak __va and __pa, which might induce
extra overhead.



Yes that's done in this patch and indeed there is an overhead to those 
functions.



Cheers,
Ben.
  



Thanks,

Alex

Re: [PATCH] drm/amdkfd: Put ACPI table after using it

[Markus Elfring]

…
> and in kfd_create_vcrat_image_cpu(), the acpi_table is only used to
> get the OEM info, so those table mappings need to be release after
…

1. Please avoid a typo for this change description.

2. An imperative wording can be preferred here, can't it?

3. Will the tag “Fixes” become helpful for the commit message?

Regards,
Markus

Re: [PATCH bpf-next v5 5/7] bpf: Implement bpf_local_storage for inodes

[Alexei Starovoitov]

On Wed, Jul 22, 2020 at 5:22 PM kernel test robot  wrote:
>

> All warnings (new ones prefixed by >>):
>
>kernel/bpf/bpf_inode_storage.c: In function 'unlink_inode_storage':
> >> kernel/bpf/bpf_inode_storage.c:34:32: warning: variable 'smap' set but not 
> >> used [-Wunused-but-set-variable]

KP,

feel free to resubmit as soon as you fix the build.
People typically ignore the patches when buildbot complains,
since they know that maintainers are not going to apply a set with
known build issue.

Re: [PATCH v2 3/4] doc/vm: fix typo in the hugetlb admin documentation

[Anshuman Khandual]

On 07/23/2020 08:52 AM, Baoquan He wrote:
> Change 'pecify' to 'Specify'.
> 
> Signed-off-by: Baoquan He 
> Reviewed-by: Mike Kravetz 
> Reviewed-by: David Hildenbrand 
> ---
>  Documentation/admin-guide/mm/hugetlbpage.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst 
> b/Documentation/admin-guide/mm/hugetlbpage.rst
> index 015a5f7d7854..f7b1c7462991 100644
> --- a/Documentation/admin-guide/mm/hugetlbpage.rst
> +++ b/Documentation/admin-guide/mm/hugetlbpage.rst
> @@ -131,7 +131,7 @@ hugepages
>   parameter is preceded by an invalid hugepagesz parameter, it will
>   be ignored.
>  default_hugepagesz
> - pecify the default huge page size.  This parameter can
> + Specify the default huge page size.  This parameter can
>   only be specified once on the command line.  default_hugepagesz can
>   optionally be followed by the hugepages parameter to preallocate a
>   specific number of huge pages of default size.  The number of default
> 

This does not apply on 5.8-rc6 and the original typo seems to be missing
there as well. This section was introduced recently with following commit.

 282f4214384e ("hugetlbfs: clean up command line processing")

[PATCH] Update the obsolete comments of 'register_blkdev' func

[richard clark]

>From the code of 'register_blkdev(...)', the major number range

should be in [1..BLKDEV_MAJOR_HASH_SIZE-1] while not [1..BLKDEV_MAJOR_MAX]

in case of calling 'register_blkdev(...) with @major = 0, so correct

the wrong info of the function's comments


Signed-off-by: Richard Clark 

Cc: Jens Axboe 

Cc: xuesong chen 

---

 block/genhd.c | 2 +-

 1 file changed, 1 insertion(+), 1 deletion(-)


diff --git a/block/genhd.c b/block/genhd.c

index 8b1e9f48957c..db73aa852434 100644

--- a/block/genhd.c

+++ b/block/genhd.c

@@ -429,7 +429,7 @@ void blkdev_show(struct seq_file *seqf, off_t offset)

  *then the function returns zero on success, or a negative error code

  *  - if any unused major number was requested with @major = 0 parameter

  *then the return value is the allocated major number in range

- *[1..BLKDEV_MAJOR_MAX-1] or a negative error code otherwise

+ *[1..BLKDEV_MAJOR_HASH_SIZE-1] or a negative error code otherwise

  *

  * See Documentation/admin-guide/devices.txt for the list of allocated

  * major numbers.

--

2.17.1

Re: [PATCH] dma-pool: Do not allocate pool memory from CMA

[Amit Pundir]

Hi Nicolas,

Sorry I got stuck on other things yesterday.

On Tue, 21 Jul 2020 at 21:57, Nicolas Saenz Julienne
 wrote:
>
> On Tue, 2020-07-21 at 20:52 +0530, Amit Pundir wrote:
>
> [...]
>
> > > > > Can you try booting *without* my patch and this in the kernel
> > > > > command
> > > > > line: "cma=16M@0x1-0x2".
> > > >
> > > > It doesn't boot with this added kernel command line.
> > >
> > > For the record, this placed the CMA in the [4GB, 8GB] address space
> > > instead of you setup's default: [3GB, 4GB]. All atomic pools fall
> > > in
> > > that memory area without my patch, which makes me think some of the
> > > devices on your board might not like higher addresses.
> > >
> >
> > Thank you Nicolas for the details. Though we don't set the CMA
> > alloc-ranges explicitly in upstream sdm845 dts, but I dug around and
> > found that CMA alloc-ranges in the downstream kernel are indeed in
> > lower address space.
> > https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/dipper-q-oss/arch/arm64/boot/dts/qcom/sdm845.dtsi#L662
> >
> > /* global autoconfigured region for contiguous allocations */
> > linux,cma {
> > compatible = "shared-dma-pool";
> > alloc-ranges = <0 0x 0 0x>;
> > reusable;
> > alignment = <0 0x40>;
> > size = <0 0x200>;
> > linux,cma-default;
> > };
>
> Pretty standard, and similar to what it's being used upstream by
> default.
>
> >
> > > What happens if you boot with my troublesome patch with this in
> > > your
> > > device tree? (insert it at the bottom of sdm845-beryllium.dts)
> > >
> > >  {
> > > dma-ranges = <0 0 0 0 0x1 0>;
> > > };
> > >
> >
> > Device still doesn't boot up to adb shell.
>
> Let's get a bigger hammer, I'm just looking for clues here. Can you
> apply this and provide the dmesg output.
>
> diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
> index 6bc74a2d5127..2160676bf488 100644
> --- a/kernel/dma/pool.c
> +++ b/kernel/dma/pool.c
> @@ -268,6 +268,8 @@ void *dma_alloc_from_pool(struct device *dev, size_t size,
> schedule_work(_pool_work);
> }
>
> +   dev_info(dev, "%s: size %lx, phys addr %llx, flags 0x%x\n", __func__, 
> size, phys, flags);
> +
> return ptr;
>  }

I never made it to dma_alloc_from_pool() call from
dma_direct_alloc_pages(), dma_should_alloc_from_pool() returns False
from gfpflags_allow_blocking() block.


Regards,
Amit Pundir

>
>
> Regards,
> Nicolas
>

Re: [PATCH] soc: qcom-geni-se: Don't use relaxed writes when writing commands

[Akash Asthana]

On 7/23/2020 3:31 AM, Douglas Anderson wrote:

Writing the command is the final step in kicking off a transfer.
Let's use writel() to ensure that any other memory accesses are done
before the command kicks off.  It's expected that this is mostly
relevant if we're in DMA mode but since it doesn't appear to regress
performance in a measurable way [1] even in PIO mode and it's easier
to reason about then let's just always use it.

NOTE: this patch came about due to code inspection.  No actual
problems were observed that this patch fixes.

[1] Tested by timing "flashrom -p ec" on a Chromebook which stresses
GENI SPI a lot.

Suggested-by: Stephen Boyd 
Signed-off-by: Douglas Anderson 
---

Reviewed-by: Akash Asthana 

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na 
Linux Foundation Collaborative Project

Re: [RFC PATCH] makefile: add debug option to enable function aligned on 32 bytes

[Feng Tang]

Hi Andrew,

Thanks for the review.

On Wed, Jul 22, 2020 at 08:39:19PM -0700, Andrew Morton wrote:
> On Thu, 23 Jul 2020 11:30:01 +0800 Feng Tang  wrote:
> 
> > Recently 0day reported many strange performance changes (regression
> > or improvement), in which there was no obvious relation between
> > the culprit commit and the benchmark at the first look, and it causes
> > people to doubt the test itself is wrong.
> > 
> > Upon further check, many of these cases are caused by the change
> > to the alignment of kernel text or data, as whole text/data of kernel
> > are linked together, change in one domain may affect alignments of
> > other domains.
> > 
> > gcc has an option '-falign-functions=n' to force text aligned, and with
> > that option enabled, some of those performance changes will be gone,
> > like [1][2][3].
> > 
> > Add this option so that developers and 0day can easily find performance
> > bump caused by text alignment change,
> 
> Would they use it this way, or would they simply always enable the
> option to reduce the variability

We've had concerns about side effects, like increased kernel size won't be
accepted by embedded system, the possible i-cache usage/contention increase.

And I've only done limited benchmark test, so I thought it may be safer
to be off by default. Though my bold thought was it could be default on :)

> It makes sense, but is it actually known that this does reduce the
> variability?

Yes, at lease for the strange performance bumps reported by 0day, like
in [1][2][3].

> > as tracking these strange bump
> > is quite time consuming. Though it can't help in other cases like data
> > alignment changes like [4].
> > 
> > Following is some size data for v5.7 kernel built with a RHEL config
> > used in 0day:
> > 
> > text  data  bss  dec   filename
> >   19738771  13292906  5554236  38585913  vmlinux.noalign
> >   19758591  13297002  5529660  38585253  vmlinux.align32
> > 
> > Raw vmlinux size in bytes:
> > 
> > v5.7v5.7+align32
> > 253950832   254018000   +0.02%
> > 
> > Some benchmark data, most of them have no big change:
> > 
> >   * hackbench:  [ -1.8%,  +0.5%]
> > 
> >   * fsmark: [ -3.2%,  +3.4%]  # ext4/xfs/btrfs
> > 
> >   * kbuild: [ -2.0%,  +0.9%]
> > 
> >   * will-it-scale:  [ -0.5%,  +1.8%]  # mmap1/pagefault3
> > 
> >   * netperf:
> > - TCP_CRR   [+16.6%, +97.4%]
> > - TCP_RR[-18.5%,  -1.8%]
> > - TCP_STREAM[ -1.1%,  +1.9%]
> 
> What do the numbers in [] mean?  The TCP_CRR results look remarkable?
 
For each of the benchmark listed above, I took 2 or 3 test platforms
and run it with different parameters. So each of the benchmark will
have several cases run, and [] lists the lowest and highest result.

For the netperf/TCP_CRR case, the lowest is +16.6% on a Skylake server
with 16 testing threads, and highest is +97.4 on a Cascadelake server
with 96 testing threads.

Thanks,
Feng

> > [1] https://lore.kernel.org/lkml/20200114085637.GA29297@shao2-debian/
> > [2] https://lore.kernel.org/lkml/20200330011254.GA14393@feng-iot/
> > [3] 
> > https://lore.kernel.org/lkml/1d98d1f0-fe84-6df7-f5bd-f4cb2cdb7...@intel.com/
> > [4] https://lore.kernel.org/lkml/20200205123216.GO12867@shao2-debian/
> > 

Re: [PATCH v2 2/4] mm/hugetlb.c: Remove the unnecessary non_swap_entry()

[Anshuman Khandual]

On 07/23/2020 08:52 AM, Baoquan He wrote:
> The checking is_migration_entry() and is_hwpoison_entry() are stricter
> than non_swap_entry(), means they have covered the conditional check
> which non_swap_entry() is doing.

They are no stricter as such but implicitly contains non_swap_entry() in itself.
If a swap entry tests positive for either is_[migration|hwpoison]_entry(), then
its swap_type() is among SWP_MIGRATION_READ, SWP_MIGRATION_WRITE and 
SWP_HWPOISON.
All these types >= MAX_SWAPFILES, exactly what is asserted with 
non_swap_entry().

> 
> Hence remove the unnecessary non_swap_entry() in is_hugetlb_entry_migration()
> and is_hugetlb_entry_hwpoisoned() to simplify code.
> 
> Signed-off-by: Baoquan He 
> Reviewed-by: Mike Kravetz 
> Reviewed-by: David Hildenbrand 
> ---
>  mm/hugetlb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 3569e731e66b..c14837854392 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -3748,7 +3748,7 @@ bool is_hugetlb_entry_migration(pte_t pte)
>   if (huge_pte_none(pte) || pte_present(pte))
>   return false;
>   swp = pte_to_swp_entry(pte);
> - if (non_swap_entry(swp) && is_migration_entry(swp))
> + if (is_migration_entry(swp))
>   return true;
>   else
>   return false;
> @@ -3761,7 +3761,7 @@ static bool is_hugetlb_entry_hwpoisoned(pte_t pte)
>   if (huge_pte_none(pte) || pte_present(pte))
>   return false;
>   swp = pte_to_swp_entry(pte);
> - if (non_swap_entry(swp) && is_hwpoison_entry(swp))
> + if (is_hwpoison_entry(swp))
>   return true;
>   else
>   return false;
> 

It would be better if the commit message contains details about
the existing redundant check. But either way.

Reviewed-by: Anshuman Khandual 

Re: [PATCH v2 2/5] vfio/pci: Add device blocklist

[Alex Williamson]

On Tue, 14 Jul 2020 07:36:07 +0100
Giovanni Cabiddu  wrote:

> Add blocklist of devices that by default are not probed by vfio-pci.
> Devices in this list may be susceptible to untrusted application, even
> if the IOMMU is enabled. To be accessed via vfio-pci, the user has to
> explicitly disable the blocklist.
> 
> The blocklist can be disabled via the module parameter disable_blocklist.
> 
> Signed-off-by: Giovanni Cabiddu 
> ---
>  drivers/vfio/pci/vfio_pci.c | 33 +
>  1 file changed, 33 insertions(+)

Hi Giovanni,

I'm pretty satisfied with this series, except "blocklist" makes me
think of block devices, ie. storage, or block chains, or building block
types of things before I get to "block" as in a barrier.  The other
alternative listed as a suggestion currently in linux-next is denylist,
which is the counter to an allowlist.  I've already proposed changing
some other terminology in vfio.c to use the term "allowed", so
allow/deny would be my preference versus pass/block.

> 
> diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
> index 7c0779018b1b..ea5904ca6cbf 100644
> --- a/drivers/vfio/pci/vfio_pci.c
> +++ b/drivers/vfio/pci/vfio_pci.c
> @@ -60,6 +60,10 @@ module_param(enable_sriov, bool, 0644);
>  MODULE_PARM_DESC(enable_sriov, "Enable support for SR-IOV configuration.  
> Enabling SR-IOV on a PF typically requires support of the userspace PF 
> driver, enabling VFs without such support may result in non-functional VFs or 
> PF.");
>  #endif
>  
> +static bool disable_blocklist;
> +module_param(disable_blocklist, bool, 0444);
> +MODULE_PARM_DESC(disable_blocklist, "Disable device blocklist. If set, i.e. 
> blocklist disabled, then blocklisted devices are allowed to be probed by 
> vfio-pci.");

This seems a little obtuse, could we expand a bit to allow users to
understand why a device might be on the denylist?  Ex:

"Disable use of device denylist, which prevents binding to device with
known errata that may lead to exploitable stability or security issues
when accessed by untrusted users."

I think that more properly sets expectations when a device is denied
via this list and the admin looks to see how they might workaround it.

> +
>  static inline bool vfio_vga_disabled(void)
>  {
>  #ifdef CONFIG_VFIO_PCI_VGA
> @@ -69,6 +73,29 @@ static inline bool vfio_vga_disabled(void)
>  #endif
>  }
>  
> +static bool vfio_pci_dev_in_blocklist(struct pci_dev *pdev)
> +{
> + return false;
> +}
> +
> +static bool vfio_pci_is_blocklisted(struct pci_dev *pdev)
> +{
> + if (!vfio_pci_dev_in_blocklist(pdev))
> + return false;
> +
> + if (disable_blocklist) {
> + pci_warn(pdev,
> +  "device blocklist disabled - allowing device 
> %04x:%04x.\n",

Here we even use "allowing" to describe what happens when the blocklist
is disabled, "deny" is a more proper antonym of allow.

> +  pdev->vendor, pdev->device);
> + return false;
> + }
> +
> + pci_warn(pdev, "%04x:%04x is blocklisted - probe will fail.\n",

Perhaps "%04x:%04x exists in vfio-pci device denylist, driver probing
disallowed.\n",...

Thanks,
Alex

> +  pdev->vendor, pdev->device);
> +
> + return true;
> +}
> +
>  /*
>   * Our VGA arbiter participation is limited since we don't know anything
>   * about the device itself.  However, if the device is the only VGA device
> @@ -1847,6 +1874,9 @@ static int vfio_pci_probe(struct pci_dev *pdev, const 
> struct pci_device_id *id)
>   struct iommu_group *group;
>   int ret;
>  
> + if (vfio_pci_is_blocklisted(pdev))
> + return -EINVAL;
> +
>   if (pdev->hdr_type != PCI_HEADER_TYPE_NORMAL)
>   return -EINVAL;
>  
> @@ -2336,6 +2366,9 @@ static int __init vfio_pci_init(void)
>  
>   vfio_pci_fill_ids();
>  
> + if (disable_blocklist)
> + pr_warn("device blocklist disabled.\n");
> +
>   return 0;
>  
>  out_driver:

Re: [PATCH] arm64: vdso32: Fix '--prefix=' value for newer versions of clang

[Sedat Dilek]

On Thu, Jul 23, 2020 at 6:51 AM Nathan Chancellor
 wrote:
>
> On Thu, Jul 23, 2020 at 06:45:07AM +0200, Sedat Dilek wrote:
> > On Thu, Jul 23, 2020 at 6:15 AM Nathan Chancellor
> >  wrote:
> > >
> > > Newer versions of clang only look for $(COMPAT_GCC_TOOLCHAIN_DIR)as [1],
> > > rather than $(COMPAT_GCC_TOOLCHAIN_DIR)$(CROSS_COMPILE_COMPAT)as,
> > > resulting in the following build error:
> > >
> > > $ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
> > > CROSS_COMPILE_COMPAT=arm-linux-gnueabi- LLVM=1 O=out/aarch64 distclean \
> > > defconfig arch/arm64/kernel/vdso32/
> > > ...
> > > /home/nathan/cbl/toolchains/llvm-binutils/bin/as: unrecognized option 
> > > '-EL'
> > > clang-12: error: assembler command failed with exit code 1 (use -v to see 
> > > invocation)
> > > make[3]: *** [arch/arm64/kernel/vdso32/Makefile:181: 
> > > arch/arm64/kernel/vdso32/note.o] Error 1
> > > ...
> > >
> > > Adding the value of CROSS_COMPILE_COMPAT (adding notdir to account for a
> > > full path for CROSS_COMPILE_COMPAT) fixes this issue, which matches the
> > > solution done for the main Makefile [2].
> > >
> >
> > [ CC Masahiro ]
> >
> > Masahiro added a slightly adapted version of [2] in .
> > Shall this go through kbuild subsystem or folded into [1]?
> >
> > - Sedat -
> >
> > [1] 
> > https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=fixes=ca9b31f6bb9c6aa9b4e5f0792f39a97bbffb8c51
>
> Sorry, should have cc'd Masahiro, slipped my mind.
>
> Note, I kept this separate as the patches have to go back different
> distances; only 5.7 has working clang support for vdso32, see
> commit a5d442f50a41 ("arm64: vdso32: Enable Clang Compilation") in
> Linus' tree, which appeared in 5.7-rc1 so this only needs to go into
> linux-5.7.y. The main patch needs to back all the way to 4.4 so we would
> need to drop this hunk when backporting, which would be annoying, as the
> main patch backports cleanly to 4.9.
>

Clarify your patch by adding...?

Cc: sta...@vger.kernel.org # 5.7

> It could be routed via the kbuild tree but the arm64 maintainers are
> pretty good at getting these fixes into the hands of Linus so I see no
> reason to go around them.
>

As you and arm64 maintainers prefer.

- Sedat -

> Cheers,
> Nathan
>
> > > [1]: 
> > > https://github.com/llvm/llvm-project/commit/3452a0d8c17f7166f479706b293caf6ac76ffd90
> > > [2]: 
> > > https://lore.kernel.org/lkml/20200721173125.1273884-1-mask...@google.com/
> > >
> > > Cc: sta...@vger.kernel.org
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/1099
> > > Signed-off-by: Nathan Chancellor 
> > > ---
> > >  arch/arm64/kernel/vdso32/Makefile | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/kernel/vdso32/Makefile 
> > > b/arch/arm64/kernel/vdso32/Makefile
> > > index d88148bef6b0..5139a5f19256 100644
> > > --- a/arch/arm64/kernel/vdso32/Makefile
> > > +++ b/arch/arm64/kernel/vdso32/Makefile
> > > @@ -14,7 +14,7 @@ COMPAT_GCC_TOOLCHAIN_DIR := $(dir $(shell which 
> > > $(CROSS_COMPILE_COMPAT)elfedit))
> > >  COMPAT_GCC_TOOLCHAIN := $(realpath $(COMPAT_GCC_TOOLCHAIN_DIR)/..)
> > >
> > >  CC_COMPAT_CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE_COMPAT:%-=%))
> > > -CC_COMPAT_CLANG_FLAGS += --prefix=$(COMPAT_GCC_TOOLCHAIN_DIR)
> > > +CC_COMPAT_CLANG_FLAGS += --prefix=$(COMPAT_GCC_TOOLCHAIN_DIR)$(notdir 
> > > $(CROSS_COMPILE_COMPAT))
> > >  CC_COMPAT_CLANG_FLAGS += -no-integrated-as -Qunused-arguments
> > >  ifneq ($(COMPAT_GCC_TOOLCHAIN),)
> > >  CC_COMPAT_CLANG_FLAGS += --gcc-toolchain=$(COMPAT_GCC_TOOLCHAIN)
> > >
> > > base-commit: d15be546031cf65a0fc34879beca02fd90fe7ac7
> > > --
> > > 2.28.0.rc1
> > >
> > > --
> > > You received this message because you are subscribed to the Google Groups 
> > > "Clang Built Linux" group.
> > > To unsubscribe from this group and stop receiving emails from it, send an 
> > > email to clang-built-linux+unsubscr...@googlegroups.com.
> > > To view this discussion on the web visit 
> > > https://groups.google.com/d/msgid/clang-built-linux/20200723041509.400450-1-natechancellor%40gmail.com.

Re: [PATCH v4 2/2] phy: cadence-torrent: Use kernel PHY API to set PHY attributes

[Kishon Vijay Abraham I]

On 7/17/2020 12:20 PM, Swapnil Jakhade wrote:
> Use generic PHY framework function phy_set_attrs() to set number
> of lanes and maximum link rate supported by PHY.
> 
> Signed-off-by: Swapnil Jakhade 

Acked-by: Kishon Vijay Abraham I 

> ---
>  drivers/phy/cadence/phy-cadence-torrent.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/phy/cadence/phy-cadence-torrent.c 
> b/drivers/phy/cadence/phy-cadence-torrent.c
> index 7116127358ee..af81707ff0c6 100644
> --- a/drivers/phy/cadence/phy-cadence-torrent.c
> +++ b/drivers/phy/cadence/phy-cadence-torrent.c
> @@ -1710,6 +1710,7 @@ static int cdns_torrent_phy_probe(struct 
> platform_device *pdev)
>   struct cdns_torrent_phy *cdns_phy;
>   struct device *dev = >dev;
>   struct phy_provider *phy_provider;
> + struct phy_attrs torrent_attr;
>   const struct of_device_id *match;
>   struct cdns_torrent_data *data;
>   struct device_node *child;
> @@ -1852,6 +1853,12 @@ static int cdns_torrent_phy_probe(struct 
> platform_device *pdev)
>cdns_phy->phys[node].num_lanes,
>cdns_phy->max_bit_rate / 1000,
>cdns_phy->max_bit_rate % 1000);
> +
> + torrent_attr.bus_width = cdns_phy->phys[node].num_lanes;
> + torrent_attr.max_link_rate = cdns_phy->max_bit_rate;
> + torrent_attr.mode = PHY_MODE_DP;
> +
> + phy_set_attrs(gphy, torrent_attr);
>   } else {
>   dev_err(dev, "Driver supports only PHY_TYPE_DP\n");
>   ret = -ENOTSUPP;
> 

[PATCH V3] Softirq:avoid large sched delay from the pending softirqs

[qianjun . kernel]

From: jun qian 

When get the pending softirqs, it need to process all the pending
softirqs in the while loop. If the processing time of each pending
softirq is need more than 2 msec in this loop, or one of the softirq
will running a long time, according to the original code logic, it
will process all the pending softirqs without wakeuping ksoftirqd,
which will cause a relatively large scheduling delay on the
corresponding CPU, which we do not wish to see. The patch will check
the total time to process pending softirq, if the time exceeds 2 ms
we need to wakeup the ksofirqd to aviod large sched delay.

Signed-off-by: jun qian 
---
 kernel/softirq.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/kernel/softirq.c b/kernel/softirq.c
index c4201b7f..8f47554 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -200,17 +200,15 @@ void __local_bh_enable_ip(unsigned long ip, unsigned int 
cnt)
 /*
  * We restart softirq processing for at most MAX_SOFTIRQ_RESTART times,
  * but break the loop if need_resched() is set or after 2 ms.
- * The MAX_SOFTIRQ_TIME provides a nice upper bound in most cases, but in
- * certain cases, such as stop_machine(), jiffies may cease to
- * increment and so we need the MAX_SOFTIRQ_RESTART limit as
- * well to make sure we eventually return from this method.
+ * In the loop, if the processing time of the softirq has exceeded 2
+ * milliseconds, we also need to break the loop to wakeup the ksofirqd.
  *
  * These limits have been established via experimentation.
  * The two things to balance is latency against fairness -
  * we want to handle softirqs as soon as possible, but they
  * should not be able to lock up the box.
  */
-#define MAX_SOFTIRQ_TIME  msecs_to_jiffies(2)
+#define MAX_SOFTIRQ_TIME_NS 200
 #define MAX_SOFTIRQ_RESTART 10
 
 #ifdef CONFIG_TRACE_IRQFLAGS
@@ -248,7 +246,7 @@ static inline void lockdep_softirq_end(bool in_hardirq) { }
 
 asmlinkage __visible void __softirq_entry __do_softirq(void)
 {
-   unsigned long end = jiffies + MAX_SOFTIRQ_TIME;
+   ktime_t end = ktime_get() + MAX_SOFTIRQ_TIME_NS;
unsigned long old_flags = current->flags;
int max_restart = MAX_SOFTIRQ_RESTART;
struct softirq_action *h;
@@ -299,6 +297,13 @@ asmlinkage __visible void __softirq_entry 
__do_softirq(void)
}
h++;
pending >>= softirq_bit;
+
+   /*
+* the softirq's action has been running for too much time
+* so it may need to wakeup the ksoftirqd
+*/
+   if (need_resched() && ktime_get() > end)
+   break;
}
 
if (__this_cpu_read(ksoftirqd) == current)
@@ -307,8 +312,8 @@ asmlinkage __visible void __softirq_entry __do_softirq(void)
 
pending = local_softirq_pending();
if (pending) {
-   if (time_before(jiffies, end) && !need_resched() &&
-   --max_restart)
+   if (!need_resched() && --max_restart &&
+   ktime_get() <= end)
goto restart;
 
wakeup_softirqd();
-- 
1.8.3.1

Re: [PATCH v4 1/2] phy: Add new PHY attribute max_link_rate and APIs to get/set PHY attributes

[Kishon Vijay Abraham I]

On 7/17/2020 12:20 PM, Swapnil Jakhade wrote:
> Add new PHY attribute max_link_rate to struct phy_attrs.
> Add a pair of PHY APIs to get/set all the PHY attributes.
> Use phy_get_attrs() to get attribute values and phy_set_attrs()
> to set attribute values.
> 
> Signed-off-by: Yuti Amonkar 
> Signed-off-by: Swapnil Jakhade 

Acked-by: Kishon Vijay Abraham I 

> ---
>  include/linux/phy/phy.h | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index bcee8eba62b3..5d8ebb056c1d 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -115,10 +115,12 @@ struct phy_ops {
>  /**
>   * struct phy_attrs - represents phy attributes
>   * @bus_width: Data path width implemented by PHY
> + * @max_link_rate: Maximum link rate supported by PHY (in Mbps)
>   * @mode: PHY mode
>   */
>  struct phy_attrs {
>   u32 bus_width;
> + u32 max_link_rate;
>   enum phy_mode   mode;
>  };
>  
> @@ -231,6 +233,20 @@ static inline void phy_set_bus_width(struct phy *phy, 
> int bus_width)
>  {
>   phy->attrs.bus_width = bus_width;
>  }
> +
> +static inline void phy_get_attrs(struct phy *phy, struct phy_attrs *attrs)
> +{
> + mutex_lock(>mutex);
> + memcpy(attrs, >attrs, sizeof(struct phy_attrs));
> + mutex_unlock(>mutex);
> +}
> +
> +static inline void phy_set_attrs(struct phy *phy, struct phy_attrs attrs)
> +{
> + mutex_lock(>mutex);
> + memcpy(>attrs, , sizeof(struct phy_attrs));
> + mutex_unlock(>mutex);
> +}
>  struct phy *phy_get(struct device *dev, const char *string);
>  struct phy *phy_optional_get(struct device *dev, const char *string);
>  struct phy *devm_phy_get(struct device *dev, const char *string);
> @@ -389,6 +405,16 @@ static inline void phy_set_bus_width(struct phy *phy, 
> int bus_width)
>   return;
>  }
>  
> +static inline void phy_get_attrs(struct phy *phy, struct phy_attrs *attrs)
> +{
> + return;
> +}
> +
> +static inline void phy_set_attrs(struct phy *phy, struct phy_attrs attrs)
> +{
> + return;
> +}
> +
>  static inline struct phy *phy_get(struct device *dev, const char *string)
>  {
>   return ERR_PTR(-ENOSYS);
> 

Re: [PATCH] arm64: vdso32: Fix '--prefix=' value for newer versions of clang

[Nathan Chancellor]

On Thu, Jul 23, 2020 at 06:45:07AM +0200, Sedat Dilek wrote:
> On Thu, Jul 23, 2020 at 6:15 AM Nathan Chancellor
>  wrote:
> >
> > Newer versions of clang only look for $(COMPAT_GCC_TOOLCHAIN_DIR)as [1],
> > rather than $(COMPAT_GCC_TOOLCHAIN_DIR)$(CROSS_COMPILE_COMPAT)as,
> > resulting in the following build error:
> >
> > $ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
> > CROSS_COMPILE_COMPAT=arm-linux-gnueabi- LLVM=1 O=out/aarch64 distclean \
> > defconfig arch/arm64/kernel/vdso32/
> > ...
> > /home/nathan/cbl/toolchains/llvm-binutils/bin/as: unrecognized option '-EL'
> > clang-12: error: assembler command failed with exit code 1 (use -v to see 
> > invocation)
> > make[3]: *** [arch/arm64/kernel/vdso32/Makefile:181: 
> > arch/arm64/kernel/vdso32/note.o] Error 1
> > ...
> >
> > Adding the value of CROSS_COMPILE_COMPAT (adding notdir to account for a
> > full path for CROSS_COMPILE_COMPAT) fixes this issue, which matches the
> > solution done for the main Makefile [2].
> >
> 
> [ CC Masahiro ]
> 
> Masahiro added a slightly adapted version of [2] in .
> Shall this go through kbuild subsystem or folded into [1]?
> 
> - Sedat -
> 
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=fixes=ca9b31f6bb9c6aa9b4e5f0792f39a97bbffb8c51

Sorry, should have cc'd Masahiro, slipped my mind.

Note, I kept this separate as the patches have to go back different
distances; only 5.7 has working clang support for vdso32, see
commit a5d442f50a41 ("arm64: vdso32: Enable Clang Compilation") in
Linus' tree, which appeared in 5.7-rc1 so this only needs to go into
linux-5.7.y. The main patch needs to back all the way to 4.4 so we would
need to drop this hunk when backporting, which would be annoying, as the
main patch backports cleanly to 4.9.

It could be routed via the kbuild tree but the arm64 maintainers are
pretty good at getting these fixes into the hands of Linus so I see no
reason to go around them.

Cheers,
Nathan

> > [1]: 
> > https://github.com/llvm/llvm-project/commit/3452a0d8c17f7166f479706b293caf6ac76ffd90
> > [2]: 
> > https://lore.kernel.org/lkml/20200721173125.1273884-1-mask...@google.com/
> >
> > Cc: sta...@vger.kernel.org
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1099
> > Signed-off-by: Nathan Chancellor 
> > ---
> >  arch/arm64/kernel/vdso32/Makefile | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kernel/vdso32/Makefile 
> > b/arch/arm64/kernel/vdso32/Makefile
> > index d88148bef6b0..5139a5f19256 100644
> > --- a/arch/arm64/kernel/vdso32/Makefile
> > +++ b/arch/arm64/kernel/vdso32/Makefile
> > @@ -14,7 +14,7 @@ COMPAT_GCC_TOOLCHAIN_DIR := $(dir $(shell which 
> > $(CROSS_COMPILE_COMPAT)elfedit))
> >  COMPAT_GCC_TOOLCHAIN := $(realpath $(COMPAT_GCC_TOOLCHAIN_DIR)/..)
> >
> >  CC_COMPAT_CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE_COMPAT:%-=%))
> > -CC_COMPAT_CLANG_FLAGS += --prefix=$(COMPAT_GCC_TOOLCHAIN_DIR)
> > +CC_COMPAT_CLANG_FLAGS += --prefix=$(COMPAT_GCC_TOOLCHAIN_DIR)$(notdir 
> > $(CROSS_COMPILE_COMPAT))
> >  CC_COMPAT_CLANG_FLAGS += -no-integrated-as -Qunused-arguments
> >  ifneq ($(COMPAT_GCC_TOOLCHAIN),)
> >  CC_COMPAT_CLANG_FLAGS += --gcc-toolchain=$(COMPAT_GCC_TOOLCHAIN)
> >
> > base-commit: d15be546031cf65a0fc34879beca02fd90fe7ac7
> > --
> > 2.28.0.rc1
> >
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Clang Built Linux" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to clang-built-linux+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/clang-built-linux/20200723041509.400450-1-natechancellor%40gmail.com.

Re: [RFC PATCH v2] Softirq:avoid large sched delay from the pending softirqs

[jun qian]

On Thu, Jul 23, 2020 at 2:05 AM Thomas Gleixner  wrote:
>
> qianjun.ker...@gmail.com writes:
> > +
> > + end = ktime_get();
> > + delta = ktime_to_us(end - start);
>
> What's the point of this conversion? That's a division for no value
> because you can simply define the maximum time in nanoseconds with the
> same effect, i.e.
>
> ktime_t end = ktime_get() + MAX_SOFTIRQ_TIME_NS;
>
> if (need_resched() && ktime_get() > end)
> break;
>
> So you can spare all that start, delta and conversion dance and keep the
> code simple.
>
> Also notice that need_resched() wants to be evaluated first because
> there is no point to do the more expensive time read if need_resched()
> is false.
good suggestion，Thanks

I will make changes in the next version
>
> Thanks,
>
> tglx

Re: [RFC PATCH v2 2/6] ALSA: compress: add new ioctl for setting codec parameters

[Vinod Koul]

On 22-07-20, 10:36, Pierre-Louis Bossart wrote:
> 
> > > >    * and the stream properties
> > > > + * @set_codec_params: Sets the compressed stream codec
> > > > parameters, Optional
> > > > + * This can be called in during gapless next track codec change
> > > > only to set
> > > > + * codec params
> > > 
> > > Would it be clearer if this was called set_next_codec_params()? or
> > > set_next_track_codec_params()?
> > > 
> > > Having set_params() and set_codec_params() is a bit confusing since
> > > the semantic difference is not captured in the callback name.
> > 
> > set_next_track_codec_params seems more sensible as its next track params.
> > Will change this in next version!
> 
> maybe set_params() and set_next_track_params() are enough, not sure if the
> codec reference helps?

params typically refers to whole set of compress parameters which
includes buffer information and codec parameters, so codec reference
would help.

-- 
~Vinod

Re: [PATCH v2 1/4] mm/hugetlb.c: make is_hugetlb_entry_hwpoisoned return bool

[Anshuman Khandual]

On 07/23/2020 08:52 AM, Baoquan He wrote:
> Just like its neighbour is_hugetlb_entry_migration() has done.
> 
> Signed-off-by: Baoquan He 
> Reviewed-by: Mike Kravetz 
> Reviewed-by: David Hildenbrand 
> ---
>  mm/hugetlb.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index f24acb3af741..3569e731e66b 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -3754,17 +3754,17 @@ bool is_hugetlb_entry_migration(pte_t pte)
>   return false;
>  }
>  
> -static int is_hugetlb_entry_hwpoisoned(pte_t pte)
> +static bool is_hugetlb_entry_hwpoisoned(pte_t pte)
>  {
>   swp_entry_t swp;
>  
>   if (huge_pte_none(pte) || pte_present(pte))
> - return 0;
> + return false;
>   swp = pte_to_swp_entry(pte);
>   if (non_swap_entry(swp) && is_hwpoison_entry(swp))
> - return 1;
> + return true;
>   else
> - return 0;
> + return false;
>  }
>  
>  int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src,
> 

Reviewed-by: Anshuman Khandual 

Re: [PATCH 5.7 233/244] RISC-V: Acquire mmap lock before invoking walk_page_range

[Stafford Horne]

On Wed, Jul 22, 2020 at 03:11:35PM +, Atish Patra wrote:
> On Wed, 2020-07-22 at 14:48 +0200, Greg KH wrote:
> > On Tue, Jul 21, 2020 at 03:50:35PM -0700, Palmer Dabbelt wrote:
> > > On Mon, 20 Jul 2020 12:14:03 PDT (-0700), Greg KH wrote:
> > > > On Mon, Jul 20, 2020 at 06:50:10PM +, Atish Patra wrote:
> > > > > On Mon, 2020-07-20 at 23:11 +0530, Naresh Kamboju wrote:
> > > > > > RISC-V build breaks on stable-rc 5.7 branch.
> > > > > > build failed with gcc-8, gcc-9 and gcc-9.
> > > > > > 
> > > > > 
> > > > > Sorry for the compilation issue.
> > > > > 
> > > > > mmap_read_lock was intrdouced in the following commit.
> > > > > 
> > > > > commit 9740ca4e95b4
> > > > > Author: Michel Lespinasse 
> > > > > Date:   Mon Jun 8 21:33:14 2020 -0700
> > > > > 
> > > > > mmap locking API: initial implementation as rwsem wrappers
> > > > > 
> > > > > The following two commits replaced the usage of mmap_sem rwsem
> > > > > calls
> > > > > with mmap_lock.
> > > > > 
> > > > > d8ed45c5dcd4 (mmap locking API: use coccinelle to convert
> > > > > mmap_sem
> > > > > rwsem call sites)
> > > > > 89154dd5313f (mmap locking API: convert mmap_sem call sites
> > > > > missed by
> > > > > coccinelle)
> > > > > 
> > > > > The first commit is not present in stale 5.7-y for obvious
> > > > > reasons.
> > > > > 
> > > > > Do we need to send a separate patch only for stable branch with
> > > > > mmap_sem ? I am not sure if that will cause a conflict again in
> > > > > future.
> > > > 
> > > > I do not like taking odd backports, and would rather take the
> > > > real patch
> > > > that is upstream.
> > > 
> > > I guess I'm a bit new to stable backports so I'm not sure what's
> > > expected here.
> > > The failing patch fixes a bug by using a new interface.  The
> > > smallest diff fix
> > > for the stable kernels would be to construct a similar fix without
> > > the new
> > > interface, which in this case is very easy as the new interface
> > > just converted
> > > some generic locking calls to one-line functions.  It seems
> > > somewhat circuitous
> > > to land that in Linus' tree, though, as it would require breaking
> > > our port
> > > before fixing it to use the old interfaces and then cleaning it up
> > > to use the
> > > new interfaces.
> > > 
> > > Are we expected to pull the new interface onto stable in addition
> > > to this fix?
> > 
> > If it really does fix a big issue, yes, that is fine to do.
> > 
> 
> The original issue was manifests only for certain rootfs with
> CONFIG_DEBUG_VM enabled in kernel. I am not sure if that qualfies for a
> big issue :). But there was a similar fix for OpenRISC as well.
> 
> +stafford (who fixed the issue for OpenRISC)
> 
> @stafford Was there a request to backport the fix to stable ?

I have not requested  pulling my patch to stable.  Mine is this one:

  313a5257b84c2 ("openrisc: fix boot oops when DEBUG_VM is enabled")

If you cat request that would be great.

> I can combine all the git ids that needs to be pulled in.

Note, mine lists:

  Fixes: 42fc541404f2 ("mmap locking API: add mmap_assert_locked() and 
mmap_assert_write_locked()")

while your's lists:

  Fixes: 395a21ff859c(riscv: add ARCH_HAS_SET_DIRECT_MAP support)

That is when the code was introduced to the riscv port, but not the commit that
broke booting.

I think if you list the Fixes as I did when backporting to stable Greg, or his
tools, would also know that the patch depends on the the 42fc541404f2 commit.

Also, I guess there is no problem with listing 2 "Fixes" in the future.

Thanks Atish and Palmer.

-Stafford

> > > The new interface doesn't actually fix anything itself, but it
> > > would allow a
> > > functional kernel to be constructed that consisted of only
> > > backports from
> > > Linus' tree (which would also make further fixes easier).
> > 
> > That's fine.
> > 
> > > It seems safe to
> > > just pull in 9740ca4e95b4 ("mmap locking API: initial
> > > implementation as rwsem
> > > wrappers") before this failing patch, as in this case the new
> > > interface will
> > > function correctly with only a subset of callers having been
> > > converted.  Of
> > > course that's not a generally true statement so I don't know if
> > > future code
> > > will behave that way, but pulling in those conversion patches is
> > > definitely
> > > unnecessary diff right now.
> > 
> > If someone wants to send me a full set of the git ids that need to be
> > pulled in, I will be glad to do so.
> > 
> > thanks,
> > 
> > greg k-h
> 
> -- 
> Regards,
> Atish

Re: [PATCH] arm64: vdso32: Fix '--prefix=' value for newer versions of clang

[Sedat Dilek]

On Thu, Jul 23, 2020 at 6:15 AM Nathan Chancellor
 wrote:
>
> Newer versions of clang only look for $(COMPAT_GCC_TOOLCHAIN_DIR)as [1],
> rather than $(COMPAT_GCC_TOOLCHAIN_DIR)$(CROSS_COMPILE_COMPAT)as,
> resulting in the following build error:
>
> $ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
> CROSS_COMPILE_COMPAT=arm-linux-gnueabi- LLVM=1 O=out/aarch64 distclean \
> defconfig arch/arm64/kernel/vdso32/
> ...
> /home/nathan/cbl/toolchains/llvm-binutils/bin/as: unrecognized option '-EL'
> clang-12: error: assembler command failed with exit code 1 (use -v to see 
> invocation)
> make[3]: *** [arch/arm64/kernel/vdso32/Makefile:181: 
> arch/arm64/kernel/vdso32/note.o] Error 1
> ...
>
> Adding the value of CROSS_COMPILE_COMPAT (adding notdir to account for a
> full path for CROSS_COMPILE_COMPAT) fixes this issue, which matches the
> solution done for the main Makefile [2].
>

[ CC Masahiro ]

Masahiro added a slightly adapted version of [2] in .
Shall this go through kbuild subsystem or folded into [1]?

- Sedat -

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=fixes=ca9b31f6bb9c6aa9b4e5f0792f39a97bbffb8c51

> [1]: 
> https://github.com/llvm/llvm-project/commit/3452a0d8c17f7166f479706b293caf6ac76ffd90
> [2]: https://lore.kernel.org/lkml/20200721173125.1273884-1-mask...@google.com/
>
> Cc: sta...@vger.kernel.org
> Link: https://github.com/ClangBuiltLinux/linux/issues/1099
> Signed-off-by: Nathan Chancellor 
> ---
>  arch/arm64/kernel/vdso32/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/vdso32/Makefile 
> b/arch/arm64/kernel/vdso32/Makefile
> index d88148bef6b0..5139a5f19256 100644
> --- a/arch/arm64/kernel/vdso32/Makefile
> +++ b/arch/arm64/kernel/vdso32/Makefile
> @@ -14,7 +14,7 @@ COMPAT_GCC_TOOLCHAIN_DIR := $(dir $(shell which 
> $(CROSS_COMPILE_COMPAT)elfedit))
>  COMPAT_GCC_TOOLCHAIN := $(realpath $(COMPAT_GCC_TOOLCHAIN_DIR)/..)
>
>  CC_COMPAT_CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE_COMPAT:%-=%))
> -CC_COMPAT_CLANG_FLAGS += --prefix=$(COMPAT_GCC_TOOLCHAIN_DIR)
> +CC_COMPAT_CLANG_FLAGS += --prefix=$(COMPAT_GCC_TOOLCHAIN_DIR)$(notdir 
> $(CROSS_COMPILE_COMPAT))
>  CC_COMPAT_CLANG_FLAGS += -no-integrated-as -Qunused-arguments
>  ifneq ($(COMPAT_GCC_TOOLCHAIN),)
>  CC_COMPAT_CLANG_FLAGS += --gcc-toolchain=$(COMPAT_GCC_TOOLCHAIN)
>
> base-commit: d15be546031cf65a0fc34879beca02fd90fe7ac7
> --
> 2.28.0.rc1
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clang-built-linux+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/clang-built-linux/20200723041509.400450-1-natechancellor%40gmail.com.

Re: [RFC PATCH 11/16] sched: migration changes for core scheduling(Internet mail)

[蒋彪]

Hi,
> On Jul 23, 2020, at 11:35 AM, Li, Aubrey  wrote:
> 
> On 2020/7/23 10:42, benbjiang(蒋彪) wrote:
>> Hi,
>> 
>>> On Jul 23, 2020, at 9:57 AM, Li, Aubrey  wrote:
>>> 
>>> On 2020/7/22 22:32, benbjiang(蒋彪) wrote:
 Hi,
 
> On Jul 22, 2020, at 8:13 PM, Li, Aubrey  wrote:
> 
> On 2020/7/22 16:54, benbjiang(蒋彪) wrote:
>> Hi, Aubrey,
>> 
>>> On Jul 1, 2020, at 5:32 AM, Vineeth Remanan Pillai 
>>>  wrote:
>>> 
>>> From: Aubrey Li 
>>> 
>>> - Don't migrate if there is a cookie mismatch
>>>  Load balance tries to move task from busiest CPU to the
>>>  destination CPU. When core scheduling is enabled, if the
>>>  task's cookie does not match with the destination CPU's
>>>  core cookie, this task will be skipped by this CPU. This
>>>  mitigates the forced idle time on the destination CPU.
>>> 
>>> - Select cookie matched idle CPU
>>>  In the fast path of task wakeup, select the first cookie matched
>>>  idle CPU instead of the first idle CPU.
>>> 
>>> - Find cookie matched idlest CPU
>>>  In the slow path of task wakeup, find the idlest CPU whose core
>>>  cookie matches with task's cookie
>>> 
>>> - Don't migrate task if cookie not match
>>>  For the NUMA load balance, don't migrate task to the CPU whose
>>>  core cookie does not match with task's cookie
>>> 
>>> Signed-off-by: Aubrey Li 
>>> Signed-off-by: Tim Chen 
>>> Signed-off-by: Vineeth Remanan Pillai 
>>> ---
>>> kernel/sched/fair.c  | 64 
>>> kernel/sched/sched.h | 29 
>>> 2 files changed, 88 insertions(+), 5 deletions(-)
>>> 
>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>>> index d16939766361..33dc4bf01817 100644
>>> --- a/kernel/sched/fair.c
>>> +++ b/kernel/sched/fair.c
>>> @@ -2051,6 +2051,15 @@ static void task_numa_find_cpu(struct 
>>> task_numa_env *env,
>>> if (!cpumask_test_cpu(cpu, env->p->cpus_ptr))
>>> continue;
>>> 
>>> +#ifdef CONFIG_SCHED_CORE
>>> +   /*
>>> +* Skip this cpu if source task's cookie does not match
>>> +* with CPU's core cookie.
>>> +*/
>>> +   if (!sched_core_cookie_match(cpu_rq(cpu), env->p))
>>> +   continue;
>>> +#endif
>>> +
>>> env->dst_cpu = cpu;
>>> if (task_numa_compare(env, taskimp, groupimp, maymove))
>>> break;
>>> @@ -5963,11 +5972,17 @@ find_idlest_group_cpu(struct sched_group 
>>> *group, struct task_struct *p, int this
>>> 
>>> /* Traverse only the allowed CPUs */
>>> for_each_cpu_and(i, sched_group_span(group), p->cpus_ptr) {
>>> +   struct rq *rq = cpu_rq(i);
>>> +
>>> +#ifdef CONFIG_SCHED_CORE
>>> +   if (!sched_core_cookie_match(rq, p))
>>> +   continue;
>>> +#endif
>>> +
>>> if (sched_idle_cpu(i))
>>> return i;
>>> 
>>> if (available_idle_cpu(i)) {
>>> -   struct rq *rq = cpu_rq(i);
>>> struct cpuidle_state *idle = idle_get_state(rq);
>>> if (idle && idle->exit_latency < 
>>> min_exit_latency) {
>>> /*
>>> @@ -6224,8 +6239,18 @@ static int select_idle_cpu(struct task_struct 
>>> *p, struct sched_domain *sd, int t
>>> for_each_cpu_wrap(cpu, cpus, target) {
>>> if (!--nr)
>>> return -1;
>>> -   if (available_idle_cpu(cpu) || sched_idle_cpu(cpu))
>>> -   break;
>>> +
>>> +   if (available_idle_cpu(cpu) || sched_idle_cpu(cpu)) {
>>> +#ifdef CONFIG_SCHED_CORE
>>> +   /*
>>> +* If Core Scheduling is enabled, select this 
>>> cpu
>>> +* only if the process cookie matches core 
>>> cookie.
>>> +*/
>>> +   if (sched_core_enabled(cpu_rq(cpu)) &&
>>> +   p->core_cookie == 
>>> cpu_rq(cpu)->core->core_cookie)
>> Why not also add similar logic in select_idle_smt to reduce forced-idle? 
>> :)
> We hit select_idle_smt after we scaned the entire LLC domain for idle 
> cores
> and idle cpus and failed,so IMHO, an idle smt is probably a good choice 
> under
> this scenario.
 
 AFAIC, selecting idle sibling with unmatched cookie will cause unnecessary 
 fored-idle, unfairness and latency, compared to choosing *target* cpu.
>>> Choosing target cpu could increase the runnable task number on the 

Re: [PATCH] USB:Fix kernel NULL pointer when unbind UHCI form vfio-pci

[Alex Williamson]

On Thu, 23 Jul 2020 02:59:55 +
"Weitao Wang(BJ-RD)"  wrote:

> On , Jul 22, 2020 at 02:44:14PM +0200, Alan wrote:
> > On Wed, Jul 22, 2020 at 02:44:14PM +0200, Greg KH wrote:  
> > > On Wed, Jul 22, 2020 at 07:57:48PM +0800, WeitaoWangoc wrote:  
> > > > This bug is found in Zhaoxin platform, but it's a commom code bug.
> > > > Fail sequence:
> > > > step1: Unbind UHCI controller from native driver;
> > > > step2: Bind UHCI controller to vfio-pci, which will put UHCI controller 
> > > > in one  
> > vfio  
> > > >group's device list and set UHCI's dev->driver_data to struct  
> > vfio-pci(for UHCI)  
> > >
> > > Hah, that works?  How do you do that properly?  What code does that?  
> >
> > Yeah, that can't possibly work.  The USB core expects that any host
> > controller device (or at least, any PCI host controller device) has its
> > driver_data set to point to a struct usb_hcd.  It doesn't expect a host
> > controller to be bound to anything other than a host controller driver.
> >
> > Things could easily go very wrong here.  For example, suppose at this
> > point the ehci-hcd driver just happens to bind to the EHCI controller.
> > When this happens, the EHCI controller hardware takes over all the USB
> > connections that were routed to the UHCI controller.  How will vfio-pci
> > deal with that?  Pretty ungracefully, I imagine.

The issue I believe we're seeing here is not with vfio-pci trying to do
anything with the device, the IOMMU grouping would prevent a user from
opening any device within the group while other devices within the
group are bound to host drivers.  So it should be fine if the EHCI
device takes over the other ports, but it's not ok that ehci-hcd
assumes the driver private data for any other UHCI/OHCI/EHCI device in
the same slot is something that it's free to modify.  It really seems
there should be some sort of companion device registration/opt-in
rather than modifying unvalidated data.

> > The only way to make this work at all is to unbind both uhci-hcd and
> > ehci-hcd first.  Then after both are finished you can safely bind
> > vfio-pci to the EHCI controller and the UHCI controllers (in that
> > order).
> >  
> I'm agree with you, unbind both uhci-hcd and ehci-hcd first then bind to
> vfio-pci is a more reasonable sequence. Our experiments prove that this
> sequence is indeed good as expected.
> However, I did not find a formal document to prescribe this order.
> Unfortunately, some application software such as virt-manager/qemu assign
> UHCI/EHCI to guest OS has the same bind/unbind sequence as test “by hand”.
> Do we need to consider compatibility with this application scenario?

Unbinding all functions first, before binding any to vfio-pci should
indeed work, thanks to the for_each_companion() function at least
testing for null private data before going further.  I'd still argue
though that these hcd drivers are overstepping their authority by
walking the PCI bus and assuming any device in the same slot, matching
a set of class codes, is making use of a driver with a known data
structure that they're allowed to modify.  Even if we claim that the
user needs to know what they're doing when they change driver binding,
that's a pretty subtle interaction with no validation.  Thanks,

Alex

Re: [PATCH v4 2/2] Add PWM fan controller driver for LGM SoC

[Tanwar, Rahul]

Hi Uwe,

Thanks for the feedback.

On 14/7/2020 3:10 am, Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Jun 30, 2020 at 03:55:32PM +0800, Rahul Tanwar wrote:
>> Intel Lightning Mountain(LGM) SoC contains a PWM fan controller.
>> This PWM controller does not have any other consumer, it is a
>> dedicated PWM controller for fan attached to the system. Add
>> driver for this PWM fan controller.
>>
>> Signed-off-by: Rahul Tanwar 
>> ---
>>  drivers/pwm/Kconfig |  11 ++
>>  drivers/pwm/Makefile|   1 +
>>  drivers/pwm/pwm-intel-lgm.c | 266 
>> 
>>  3 files changed, 278 insertions(+)
>>  create mode 100644 drivers/pwm/pwm-intel-lgm.c

[...]

>> +
>> +static int lgm_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>> + const struct pwm_state *state)
>> +{
>> +struct lgm_pwm_chip *pc = to_lgm_pwm_chip(chip);
>> +u32 duty_cycle, val;
>> +unsigned int period;
>> +
>> +if (!state->enabled) {
>> +lgm_pwm_enable(chip, 0);
>> +return 0;
>> +}
>> +
>> +period = min_t(u64, state->period, pc->period);
>> +
>> +if (state->polarity != PWM_POLARITY_NORMAL ||
>> +period < pc->period)
>> +return -EINVAL;
> This check looks wrong. If you refuse period < pc->period there isn't
> much configuration possible.

I am kind of stuck here. I made this change of adding a check
period < pc->period based on your feedback on v2 patch.
In fact, you had specified this code in v2 review feedback
and i used the same exact code.

How should we handle it when the hardware supports fixed period.
We don't want user to change period and allow just changing
duty_cycle. With that intention, i had first added a strict check
which refused configuration if period != pc->period. Period is
intended to be a read only value.

How do you suggest we handle the fixed period hardware support?
Would you have any reference example of other drivers which also
supports fixed period? Thanks.

[...]
>> +static int lgm_pwm_remove(struct platform_device *pdev)
>> +{
>> +struct lgm_pwm_chip *pc = platform_get_drvdata(pdev);
>> +int ret;
>> +
>> +ret = pwmchip_remove(>chip);
>> +if (ret < 0)
>> +return ret;
>> +
>> +clk_disable_unprepare(pc->clk);
>> +reset_control_assert(pc->rst);
> Please swap the two previous lines to match the error patch of .probe.

Again, i had made this change based on your below review feedback
for v1. IMO, reverse of probe makes more sense.

"In .probe() you first release reset and then enable the clock. It's good
style to do it the other way round in .remove()."

Regards,
Rahul

[PATCH] arm64: vdso32: Fix '--prefix=' value for newer versions of clang

[Nathan Chancellor]

Newer versions of clang only look for $(COMPAT_GCC_TOOLCHAIN_DIR)as [1],
rather than $(COMPAT_GCC_TOOLCHAIN_DIR)$(CROSS_COMPILE_COMPAT)as,
resulting in the following build error:

$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \
CROSS_COMPILE_COMPAT=arm-linux-gnueabi- LLVM=1 O=out/aarch64 distclean \
defconfig arch/arm64/kernel/vdso32/
...
/home/nathan/cbl/toolchains/llvm-binutils/bin/as: unrecognized option '-EL'
clang-12: error: assembler command failed with exit code 1 (use -v to see 
invocation)
make[3]: *** [arch/arm64/kernel/vdso32/Makefile:181: 
arch/arm64/kernel/vdso32/note.o] Error 1
...

Adding the value of CROSS_COMPILE_COMPAT (adding notdir to account for a
full path for CROSS_COMPILE_COMPAT) fixes this issue, which matches the
solution done for the main Makefile [2].

[1]: 
https://github.com/llvm/llvm-project/commit/3452a0d8c17f7166f479706b293caf6ac76ffd90
[2]: https://lore.kernel.org/lkml/20200721173125.1273884-1-mask...@google.com/

Cc: sta...@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1099
Signed-off-by: Nathan Chancellor 
---
 arch/arm64/kernel/vdso32/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/vdso32/Makefile 
b/arch/arm64/kernel/vdso32/Makefile
index d88148bef6b0..5139a5f19256 100644
--- a/arch/arm64/kernel/vdso32/Makefile
+++ b/arch/arm64/kernel/vdso32/Makefile
@@ -14,7 +14,7 @@ COMPAT_GCC_TOOLCHAIN_DIR := $(dir $(shell which 
$(CROSS_COMPILE_COMPAT)elfedit))
 COMPAT_GCC_TOOLCHAIN := $(realpath $(COMPAT_GCC_TOOLCHAIN_DIR)/..)
 
 CC_COMPAT_CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE_COMPAT:%-=%))
-CC_COMPAT_CLANG_FLAGS += --prefix=$(COMPAT_GCC_TOOLCHAIN_DIR)
+CC_COMPAT_CLANG_FLAGS += --prefix=$(COMPAT_GCC_TOOLCHAIN_DIR)$(notdir 
$(CROSS_COMPILE_COMPAT))
 CC_COMPAT_CLANG_FLAGS += -no-integrated-as -Qunused-arguments
 ifneq ($(COMPAT_GCC_TOOLCHAIN),)
 CC_COMPAT_CLANG_FLAGS += --gcc-toolchain=$(COMPAT_GCC_TOOLCHAIN)

base-commit: d15be546031cf65a0fc34879beca02fd90fe7ac7
-- 
2.28.0.rc1

RE: [EXT] Re: [PATCH v3 2/2] net: dsa: ocelot: Add support for QinQ Operation

[Hongbo Wang]

> Instead of writing a long email, let me just say this.
> I ran your commands on 2 random network cards (not ocelot/felix ports).
> They don't produce the same results as you. In fact, no frame with VLAN
> 111 C-TAG is forwarded (or received) at all by the bridge, not to mention that
> no VLAN 1000 S-TAG is pushed on egress.
> 
> 
> Have you tried playing with these commands?
> 
> ip link add dev br0 type bridge vlan_filtering 1 vlan_protocol 802.1ad ip link
> set eth0 master br0 ip link set eth1 master br0 bridge vlan add dev eth0 vid
> 100 pvid bridge vlan add dev eth1 vid 100
> 
> They produce the same output as yours, but have the benefit of using the
> network stack's abstractions and not glue between the 802.1q and the bridge
> module, hidden in the network driver.
> 
> I am sending the following packet towards eth0:
> 
> 00:04:9f:05:f4:ad > 00:01:02:03:04:05, ethertype 802.1Q (0x8100), length
> 102: \
> vlan 111, p 0, ethertype IPv4, 10.0.111.1 > 10.0.111.3: \
> ICMP echo request, id 63493, seq 991, length 64
> 
> and collecting it on the partner of eth1 as follows:
> 
> 00:04:9f:05:f4:ad > 00:01:02:03:04:05, ethertype 802.1Q-QinQ (0x88a8),
> length 106: \
> vlan 100, p 0, ethertype 802.1Q, vlan 111, p 0, ethertype IPv4, \
> 10.0.111.1 > 10.0.111.3: ICMP echo request, id 63493, seq 991,
> length 64
> 
> Thanks,
> -Vladimir

Hi Vladimir,
  the command " ip link add dev br0 type bridge vlan_filtering 1 vlan_protocol 
802.1ad " will influence all ports within the bridge, it will enable all ports 
vlan_filtering
flag and 802.1ad mode, if ocelot port enable vlan_filtering, it will set 
VLAN_AWARE_ENA
and VLAN_POP_CNT(1), the code is in ocelot_port_vlan_filtering in ocelot.c. it 
will
pop one tag from ingress frame, it's not my need, so I don't set vlan_filtering.

  If enable vlan_filtering, it needs enable VCAP ES0 push double VLAN tag, the 
code
is in another patch, it's based on VCAP ES0 related code, I will post it after 
ES0 code
be accepted.

  In this case, I only want the egress port(swp1) in QinQ mode, the mode will 
change swp1's
REW_TAG value, don't need swp0 enter QinQ mode, another issue is that if use " 
ip link add dev 
br0 type bridge ...", it can't pass proto to port driver, in 
dsa_slave_vlan_rx_add_vid, it will walk
into here:
ret = br_vlan_get_info(dp->bridge_dev, vid, );
if (ret == 0)  // ret is 0
return -EBUSY;
so I use "ip link add link swp1 name swp1.111 type vlan protocol 802.1ad id 
111" to enable only
port swp1's QinQ mode.

Thanks,
hongbo

[PATCH] ASoC: fsl_esai: add IRQF_SHARED for devm_request_irq

[Shengjiu Wang]

ESAI interfaces may share same interrupt line with EDMA on
some platforms (e.g. i.MX8QXP, i.MX8QM).
Add IRQF_SHARED flag to allow sharing the irq among several
devices

Signed-off-by: Shengjiu Wang 
Signed-off-by: Viorel Suman 
---
 sound/soc/fsl/fsl_esai.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index b8fbd7ba94af..4ae36099ae82 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -1012,7 +1012,7 @@ static int fsl_esai_probe(struct platform_device *pdev)
if (irq < 0)
return irq;
 
-   ret = devm_request_irq(>dev, irq, esai_isr, 0,
+   ret = devm_request_irq(>dev, irq, esai_isr, IRQF_SHARED,
   esai_priv->name, esai_priv);
if (ret) {
dev_err(>dev, "failed to claim irq %u\n", irq);
-- 
2.27.0

[PATCH 0/4] net: dsa: mv88e6xxx: port mtu support

[Chris Packham]

This series connects up the mv88e6xxx switches to the dsa infrastructure for
configuring the port MTU. The first patch is also a bug fix which might be a
candiatate for stable.

Chris Packham (4):
  net: dsa: mv88e6xxx: MV88E6097 does not support jumbo configuration
  net: dsa: mv88e6xxx: Support jumbo configuration on 6190/6190X
  net: dsa: mv88e6xxx: Implement .port_change_mtu/.port_max_mtu
  net: dsa: mv88e6xxx: Use chip-wide max frame size for MTU

 drivers/net/dsa/mv88e6xxx/chip.c| 38 -
 drivers/net/dsa/mv88e6xxx/chip.h|  3 +++
 drivers/net/dsa/mv88e6xxx/global1.c | 17 +
 drivers/net/dsa/mv88e6xxx/global1.h |  2 ++
 4 files changed, 59 insertions(+), 1 deletion(-)

-- 
2.27.0

[PATCH 4/4] net: dsa: mv88e6xxx: Use chip-wide max frame size for MTU

[Chris Packham]

Some of the chips in the mv88e6xxx family don't support jumbo
configuration per port. But they do have a chip-wide max frame size that
can be used. Use this to approximate the behaviour of configuring a port
based MTU.

Signed-off-by: Chris Packham 
---

The only hardware I have access to uses a 88E6097. I've included the 6085, 6123
and 6185 based on reading the datasheets.

 drivers/net/dsa/mv88e6xxx/chip.c|  9 +
 drivers/net/dsa/mv88e6xxx/chip.h|  3 +++
 drivers/net/dsa/mv88e6xxx/global1.c | 17 +
 drivers/net/dsa/mv88e6xxx/global1.h |  2 ++
 4 files changed, 31 insertions(+)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 04e4a7291d14..836d7c894ef2 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2850,6 +2850,8 @@ static int mv88e6xxx_port_change_mtu(struct dsa_switch 
*ds, int port,
mv88e6xxx_reg_lock(chip);
if (chip->info->ops->port_set_jumbo_size)
err = chip->info->ops->port_set_jumbo_size(chip, port, new_mtu);
+   else if (chip->info->ops->set_max_frame_size)
+   err = chip->info->ops->set_max_frame_size(chip, new_mtu);
mv88e6xxx_reg_unlock(chip);
 
return err;
@@ -2861,6 +2863,8 @@ static int mv88e6xxx_port_max_mtu(struct dsa_switch *ds, 
int port)
 
if (chip->info->ops->port_set_jumbo_size)
return 10240;
+   else if (chip->info->ops->set_max_frame_size)
+   return 1632;
 
return 1518;
 }
@@ -3449,6 +3453,7 @@ static const struct mv88e6xxx_ops mv88e6085_ops = {
.vtu_getnext = mv88e6352_g1_vtu_getnext,
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
.phylink_validate = mv88e6185_phylink_validate,
+   .set_max_frame_size = mv88e6185_g1_set_max_frame_size,
 };
 
 static const struct mv88e6xxx_ops mv88e6095_ops = {
@@ -3477,6 +3482,7 @@ static const struct mv88e6xxx_ops mv88e6095_ops = {
.vtu_getnext = mv88e6185_g1_vtu_getnext,
.vtu_loadpurge = mv88e6185_g1_vtu_loadpurge,
.phylink_validate = mv88e6185_phylink_validate,
+   .set_max_frame_size = mv88e6185_g1_set_max_frame_size,
 };
 
 static const struct mv88e6xxx_ops mv88e6097_ops = {
@@ -3514,6 +3520,7 @@ static const struct mv88e6xxx_ops mv88e6097_ops = {
.vtu_getnext = mv88e6352_g1_vtu_getnext,
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
.phylink_validate = mv88e6185_phylink_validate,
+   .set_max_frame_size = mv88e6185_g1_set_max_frame_size,
 };
 
 static const struct mv88e6xxx_ops mv88e6123_ops = {
@@ -3548,6 +3555,7 @@ static const struct mv88e6xxx_ops mv88e6123_ops = {
.vtu_getnext = mv88e6352_g1_vtu_getnext,
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
.phylink_validate = mv88e6185_phylink_validate,
+   .set_max_frame_size = mv88e6185_g1_set_max_frame_size,
 };
 
 static const struct mv88e6xxx_ops mv88e6131_ops = {
@@ -3937,6 +3945,7 @@ static const struct mv88e6xxx_ops mv88e6185_ops = {
.vtu_getnext = mv88e6185_g1_vtu_getnext,
.vtu_loadpurge = mv88e6185_g1_vtu_loadpurge,
.phylink_validate = mv88e6185_phylink_validate,
+   .set_max_frame_size = mv88e6185_g1_set_max_frame_size,
 };
 
 static const struct mv88e6xxx_ops mv88e6190_ops = {
diff --git a/drivers/net/dsa/mv88e6xxx/chip.h b/drivers/net/dsa/mv88e6xxx/chip.h
index e5430cf2ad71..f9faf48139e0 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.h
+++ b/drivers/net/dsa/mv88e6xxx/chip.h
@@ -552,6 +552,9 @@ struct mv88e6xxx_ops {
void (*phylink_validate)(struct mv88e6xxx_chip *chip, int port,
 unsigned long *mask,
 struct phylink_link_state *state);
+
+   /* Max Frame Size */
+   int (*set_max_frame_size)(struct mv88e6xxx_chip *chip, int mtu);
 };
 
 struct mv88e6xxx_irq_ops {
diff --git a/drivers/net/dsa/mv88e6xxx/global1.c 
b/drivers/net/dsa/mv88e6xxx/global1.c
index ca3a7a7a73c3..f62aa83ca08d 100644
--- a/drivers/net/dsa/mv88e6xxx/global1.c
+++ b/drivers/net/dsa/mv88e6xxx/global1.c
@@ -196,6 +196,23 @@ int mv88e6185_g1_ppu_disable(struct mv88e6xxx_chip *chip)
return mv88e6185_g1_wait_ppu_disabled(chip);
 }
 
+int mv88e6185_g1_set_max_frame_size(struct mv88e6xxx_chip *chip, int mtu)
+{
+   u16 val;
+   int err;
+
+   err = mv88e6xxx_g1_read(chip, MV88E6XXX_G1_CTL1, );
+   if (err)
+   return err;
+
+   val &= ~MV88E6185_G1_CTL1_MAX_FRAME_1632;
+
+   if (mtu > 1518)
+   val |= MV88E6185_G1_CTL1_MAX_FRAME_1632;
+
+   return mv88e6xxx_g1_write(chip, MV88E6XXX_G1_CTL1, val);
+}
+
 /* Offset 0x10: IP-PRI Mapping Register 0
  * Offset 0x11: IP-PRI Mapping Register 1
  * Offset 0x12: IP-PRI Mapping Register 2
diff --git a/drivers/net/dsa/mv88e6xxx/global1.h 
b/drivers/net/dsa/mv88e6xxx/global1.h
index 5324c6f4ae90..1e3546f8b072 100644
--- a/drivers/net/dsa/mv88e6xxx/global1.h
+++ 

[PATCH 3/4] net: dsa: mv88e6xxx: Implement .port_change_mtu/.port_max_mtu

[Chris Packham]

Add implementations for the mv88e6xxx switches to connect with the
generic dsa operations for configuring the port MTU.

Signed-off-by: Chris Packham 
---
 drivers/net/dsa/mv88e6xxx/chip.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index c2a4ac99545d..04e4a7291d14 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2841,6 +2841,30 @@ static int mv88e6xxx_devlink_param_set(struct dsa_switch 
*ds, u32 id,
return err;
 }
 
+static int mv88e6xxx_port_change_mtu(struct dsa_switch *ds, int port,
+int new_mtu)
+{
+   struct mv88e6xxx_chip *chip = ds->priv;
+   int err = -EOPNOTSUPP;
+
+   mv88e6xxx_reg_lock(chip);
+   if (chip->info->ops->port_set_jumbo_size)
+   err = chip->info->ops->port_set_jumbo_size(chip, port, new_mtu);
+   mv88e6xxx_reg_unlock(chip);
+
+   return err;
+}
+
+static int mv88e6xxx_port_max_mtu(struct dsa_switch *ds, int port)
+{
+   struct mv88e6xxx_chip *chip = ds->priv;
+
+   if (chip->info->ops->port_set_jumbo_size)
+   return 10240;
+
+   return 1518;
+}
+
 static const struct devlink_param mv88e6xxx_devlink_params[] = {
DSA_DEVLINK_PARAM_DRIVER(MV88E6XXX_DEVLINK_PARAM_ID_ATU_HASH,
 "ATU_hash", DEVLINK_PARAM_TYPE_U8,
@@ -5562,6 +5586,8 @@ static const struct dsa_switch_ops mv88e6xxx_switch_ops = 
{
.get_ts_info= mv88e6xxx_get_ts_info,
.devlink_param_get  = mv88e6xxx_devlink_param_get,
.devlink_param_set  = mv88e6xxx_devlink_param_set,
+   .port_change_mtu= mv88e6xxx_port_change_mtu,
+   .port_max_mtu   = mv88e6xxx_port_max_mtu,
 };
 
 static int mv88e6xxx_register_switch(struct mv88e6xxx_chip *chip)
-- 
2.27.0

[PATCH 2/4] net: dsa: mv88e6xxx: Support jumbo configuration on 6190/6190X

[Chris Packham]

The MV88E6190 and MV88E6190X both support per port jumbo configuration
just like the other GE switches. Install the appropriate ops.

Signed-off-by: Chris Packham 
---

I'm including this change in my series for completeness. Looking at the
datasheets I think this is an unintentional omission but I don't have actual
hardware to test this change on so some testing from someone with access to the
right chip would be appreciated.

 drivers/net/dsa/mv88e6xxx/chip.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index fbfa4087eb7b..c2a4ac99545d 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -3933,6 +3933,7 @@ static const struct mv88e6xxx_ops mv88e6190_ops = {
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
.port_set_egress_floods = mv88e6352_port_set_egress_floods,
.port_set_ether_type = mv88e6351_port_set_ether_type,
+   .port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
.port_pause_limit = mv88e6390_port_pause_limit,
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
@@ -3991,6 +3992,7 @@ static const struct mv88e6xxx_ops mv88e6190x_ops = {
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
.port_set_egress_floods = mv88e6352_port_set_egress_floods,
.port_set_ether_type = mv88e6351_port_set_ether_type,
+   .port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
.port_pause_limit = mv88e6390_port_pause_limit,
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
.port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
-- 
2.27.0

[PATCH 1/4] net: dsa: mv88e6xxx: MV88E6097 does not support jumbo configuration

[Chris Packham]

The MV88E6097 chip does not support configuring jumbo frames. Prior to
commit 5f430d65 only the 6352, 6351, 6165 and 6320 chips configured
jumbo mode. The refactor accidentally added the function for the 6097.
Remove the erroneous function pointer assignment.

Fixes: 5f430d65 ("net: dsa: mv88e6xxx: Refactor setting of jumbo frames")
Signed-off-by: Chris Packham 
---
 drivers/net/dsa/mv88e6xxx/chip.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 7627ea61e0ea..fbfa4087eb7b 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -3469,7 +3469,6 @@ static const struct mv88e6xxx_ops mv88e6097_ops = {
.port_set_frame_mode = mv88e6351_port_set_frame_mode,
.port_set_egress_floods = mv88e6352_port_set_egress_floods,
.port_set_ether_type = mv88e6351_port_set_ether_type,
-   .port_set_jumbo_size = mv88e6165_port_set_jumbo_size,
.port_egress_rate_limiting = mv88e6095_port_egress_rate_limiting,
.port_pause_limit = mv88e6097_port_pause_limit,
.port_disable_learn_limit = mv88e6xxx_port_disable_learn_limit,
-- 
2.27.0

Re: [PATCH] USB:Fix kernel NULL pointer when unbind UHCI form vfio-pci

[Alex Williamson]

On Wed, 22 Jul 2020 19:57:48 +0800
WeitaoWangoc  wrote:

> This bug is found in Zhaoxin platform, but it's a commom code bug.
> Fail sequence:
> step1: Unbind UHCI controller from native driver;
> step2: Bind UHCI controller to vfio-pci, which will put UHCI controller in 
> one vfio
>group's device list and set UHCI's dev->driver_data to struct 
> vfio-pci(for UHCI)
> step3: Unbind EHCI controller from native driver, will try to tell UHCI 
> native driver
>that "I'm removed by set companion_hcd->self.hs_companion to NULL. 
> However,
>companion_hcd get from UHCI's dev->driver_data that has modified by 
> vfio-pci
>already.So, the vfio-pci structure will be damaged!
> step4: Bind EHCI controller to vfio-pci driver, which will put EHCI 
> controller in the
>same vfio group as UHCI controller;
>  ... ...
> step5: Unbind UHCI controller from vfio-pci, which will delete UHCI from vfio 
> group'
>device list that has been damaged in step 3. So,delete operation can 
> random
>result into a NULL pointer dereference with the below stack dump.
> step6: Bind UHCI controller to native driver;
> step7: Unbind EHCI controller from vfio-pci, which will try to remove EHCI 
> controller
>from the vfio group;
> step8: Bind EHCI controller to native driver;
> 
> [  929.114641] uhci_hcd :00:10.0: remove, state 1
> [  929.114652] usb usb1: USB disconnect, device number 1
> [  929.114655] usb 1-1: USB disconnect, device number 2
> [  929.270313] usb 1-2: USB disconnect, device number 3
> [  929.318404] uhci_hcd :00:10.0: USB bus 1 deregistered
> [  929.343029] uhci_hcd :00:10.1: remove, state 4
> [  929.343045] usb usb3: USB disconnect, device number 1
> [  929.343685] uhci_hcd :00:10.1: USB bus 3 deregistered
> [  929.369087] ehci-pci :00:10.7: remove, state 4
> [  929.369102] usb usb4: USB disconnect, device number 1
> [  929.370325] ehci-pci :00:10.7: USB bus 4 deregistered
> [  932.398494] BUG: unable to handle kernel NULL pointer dereference at 
> 
> [  932.398496] PGD 42a67d067 P4D 42a67d067 PUD 42a65f067 PMD 0
> [  932.398502] Oops: 0002 [#2] SMP NOPTI
> [  932.398505] CPU: 2 PID: 7824 Comm: vfio_unbind.sh Tainted: P   D  
> 4.19.65-2020051917-rainos #1
> [  932.398506] Hardware name: Shanghai Zhaoxin Semiconductor Co., Ltd. 
> HX002EH/HX002EH,
>BIOS HX002EH0_01_R480_R_200408 04/08/2020
> [  932.398513] RIP: 0010:vfio_device_put+0x31/0xa0 [vfio]
> [  932.398515] Code: 89 e5 41 54 53 4c 8b 67 18 48 89 fb 49 8d 74 24 30 e8 e3 
> 0e f3 de
> 84 c0 74 67 48 8b 53 20 48 8b 43 28 48 8b 7b 18 48 89 42 08 
> <48> 89 10
> 48 b8 00 01 00 00 00 00 ad de 48 89 43 20 48 b8 00 02 00
> [  932.398516] RSP: 0018:bbfd04cffc18 EFLAGS: 00010202
> [  932.398518] RAX:  RBX: 92c7ea717880 RCX: 
> 
> [  932.398519] RDX: 92c7ea713620 RSI: 92c7ea713630 RDI: 
> 92c7ea713600
> [  932.398521] RBP: bbfd04cffc28 R08: 92c7f02a8080 R09: 
> 92c7efc03980
> [  932.398522] R10: bbfd04cff9a8 R11:  R12: 
> 92c7ea713600
> [  932.398523] R13: 92c7ed8bb0a8 R14: 92c7ea717880 R15: 
> 
> [  932.398525] FS:  7f3031500740() GS:92c7f028() 
> knlGS:
> [  932.398526] CS:  0010 DS:  ES:  CR0: 80050033
> [  932.398527] CR2:  CR3: 000428626004 CR4: 
> 00160ee0
> [  932.398528] Call Trace:
> [  932.398534]  vfio_del_group_dev+0xe8/0x2a0 [vfio]
> [  932.398539]  ? __blocking_notifier_call_chain+0x52/0x60
> [  932.398542]  ? do_wait_intr_irq+0x90/0x90
> [  932.398546]  ? iommu_bus_notifier+0x75/0x100
> [  932.398551]  vfio_pci_remove+0x20/0xa0 [vfio_pci]
> [  932.398554]  pci_device_remove+0x3e/0xc0
> [  932.398557]  device_release_driver_internal+0x17a/0x240
> [  932.398560]  device_release_driver+0x12/0x20
> [  932.398561]  unbind_store+0xee/0x180
> [  932.398564]  drv_attr_store+0x27/0x40
> [  932.398567]  sysfs_kf_write+0x3c/0x50
> [  932.398568]  kernfs_fop_write+0x125/0x1a0
> [  932.398572]  __vfs_write+0x3a/0x190
> [  932.398575]  ? apparmor_file_permission+0x1a/0x20
> [  932.398577]  ? security_file_permission+0x3b/0xc0
> [  932.398581]  ? _cond_resched+0x1a/0x50
> [  932.398582]  vfs_write+0xb8/0x1b0
> [  932.398584]  ksys_write+0x5c/0xe0
> [  932.398586]  __x64_sys_write+0x1a/0x20
> [  932.398589]  do_syscall_64+0x5a/0x110
> [  932.398592]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> 
> Using virt-manager/qemu to boot guest os, we can see the same fail sequence!
> 
> Fix this by check for UHCI driver loaded or not before modifiy UHCI's 
> dev->driver_data,
> which will happen in ehci native driver probe/remove.
> 
> Signed-off-by: WeitaoWangoc 
> ---
>  drivers/usb/core/hcd-pci.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
> index 1547aa6..484f2a0 

[PATCH RESEND 0/3] Build ORC fast lookup table in scripts/sorttable tool

[Huaixin Chang]

Move building of fast lookup table from boot to sorttable tool. This saves us
6380us boot time on Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz with cores. It
adds a little more than 7ms to boot time when testing on the same CPU.

Kernel initialization unwind_init() cannot be removed because lookup_num_blocks
is still needed.

Huaixin Chang (3):
  scripts/sorttable: Change section type of orc_lookup to SHT_PROGBITS
  scripts/sorttable: Build orc fast lookup table via sorttable tool
  x86/unwind/orc: Simplify unwind_init() for x86 boot

 arch/x86/kernel/unwind_orc.c  | 41 +---
 include/asm-generic/vmlinux.lds.h |  2 +
 scripts/sorttable.h   | 99 ---
 3 files changed, 96 insertions(+), 46 deletions(-)

-- 
2.14.4.44.g2045bb6

[PATCH 2/3] scripts/sorttable: Build orc fast lookup table via sorttable tool

[Huaixin Chang]

Since orc tables are already sorted by sorttable tool, let us move
building of fast lookup table into sorttable tool too. This saves us
6380us from boot time under Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz
with 64 cores.

Signed-off-by: Huaixin Chang 
Signed-off-by: Shile Zhang 
---
 scripts/sorttable.h | 99 +
 1 file changed, 92 insertions(+), 7 deletions(-)

diff --git a/scripts/sorttable.h b/scripts/sorttable.h
index a2baa2fefb13..a36c76c17be4 100644
--- a/scripts/sorttable.h
+++ b/scripts/sorttable.h
@@ -93,12 +93,50 @@
 char g_err[ERRSTR_MAXSZ];
 int *g_orc_ip_table;
 struct orc_entry *g_orc_table;
+static unsigned long orc_ip_table_offset;
 
 pthread_t orc_sort_thread;
 
+struct orc_sort_param {
+   size_t  lookup_table_size;
+   unsigned int*orc_lookup_table;
+   unsigned long   start_ip;
+   size_t  text_size;
+   unsigned intorc_num_entries;
+};
+
 static inline unsigned long orc_ip(const int *ip)
 {
-   return (unsigned long)ip + *ip;
+   return (unsigned long)ip + *ip + orc_ip_table_offset;
+}
+
+static struct orc_entry *__orc_find(int *ip_table, struct orc_entry *u_table,
+   unsigned int num_entries, unsigned long ip)
+{
+   int *first = ip_table;
+   int *last = ip_table + num_entries - 1;
+   int *mid = first, *found = first;
+
+   if (!num_entries)
+   return NULL;
+
+   /*
+* Do a binary range search to find the rightmost duplicate of a given
+* starting address.  Some entries are section terminators which are
+* "weak" entries for ensuring there are no gaps.  They should be
+* ignored when they conflict with a real entry.
+*/
+   while (first <= last) {
+   mid = first + ((last - first) / 2);
+
+   if (orc_ip(mid) <= ip) {
+   found = mid;
+   first = mid + 1;
+   } else
+   last = mid - 1;
+   }
+
+   return u_table + (found - ip_table);
 }
 
 static int orc_sort_cmp(const void *_a, const void *_b)
@@ -130,18 +168,24 @@ static void *sort_orctable(void *arg)
int *idxs = NULL;
int *tmp_orc_ip_table = NULL;
struct orc_entry *tmp_orc_table = NULL;
-   unsigned int *orc_ip_size = (unsigned int *)arg;
-   unsigned int num_entries = *orc_ip_size / sizeof(int);
+   struct orc_sort_param *param = (struct orc_sort_param *)arg;
+   unsigned int num_entries = param->orc_num_entries;
+   unsigned int orc_ip_size = num_entries * sizeof(int);
unsigned int orc_size = num_entries * sizeof(struct orc_entry);
+   unsigned int lookup_num_blocks = param->lookup_table_size / sizeof(int);
+   unsigned int *orc_lookup = param->orc_lookup_table;
+   unsigned long lookup_start_ip = param->start_ip;
+   unsigned long lookup_stop_ip = param->start_ip + param->text_size;
+   struct orc_entry *orc;
 
-   idxs = (int *)malloc(*orc_ip_size);
+   idxs = (int *)malloc(orc_ip_size);
if (!idxs) {
snprintf(g_err, ERRSTR_MAXSZ, "malloc idxs: %s",
 strerror(errno));
pthread_exit(g_err);
}
 
-   tmp_orc_ip_table = (int *)malloc(*orc_ip_size);
+   tmp_orc_ip_table = (int *)malloc(orc_ip_size);
if (!tmp_orc_ip_table) {
snprintf(g_err, ERRSTR_MAXSZ, "malloc tmp_orc_ip_table: %s",
 strerror(errno));
@@ -173,6 +217,31 @@ static void *sort_orctable(void *arg)
g_orc_table[i] = tmp_orc_table[idxs[i]];
}
 
+#define LOOKUP_BLOCK_ORDER 8
+#define LOOKUP_BLOCK_SIZE  (1 << LOOKUP_BLOCK_ORDER)
+
+   for (i = 0; i < lookup_num_blocks-1; i++) {
+   orc = __orc_find(g_orc_ip_table, g_orc_table,
+num_entries,
+lookup_start_ip + (LOOKUP_BLOCK_SIZE * i));
+   if (!orc) {
+   snprintf(g_err, ERRSTR_MAXSZ,
+   "Corrupt .orc_unwind table\n");
+   pthread_exit(g_err);
+   }
+
+   orc_lookup[i] = orc - g_orc_table;
+   }
+
+   /* Initialize the ending block: */
+   orc = __orc_find(g_orc_ip_table, g_orc_table, num_entries,
+lookup_stop_ip);
+   if (!orc) {
+   snprintf(g_err, ERRSTR_MAXSZ, "Corrupt .orc_unwind table\n");
+   pthread_exit(g_err);
+   }
+   orc_lookup[lookup_num_blocks-1] = orc - g_orc_table;
+
free(idxs);
free(tmp_orc_ip_table);
free(tmp_orc_table);
@@ -221,6 +290,8 @@ static int do_sort(Elf_Ehdr *ehdr,
unsigned int orc_ip_size = 0;
unsigned int orc_size = 0;
unsigned int orc_num_entries = 0;
+   unsigned long orc_ip_addr = 0;
+   struct orc_sort_param param;
 #endif
 
   

[PATCH 1/3] scripts/sorttable: Change section type of orc_lookup to SHT_PROGBITS

[Huaixin Chang]

In order to edit orc_lookup table via sorttable, type of section
orc_lookup needs to be SHT_PROGBITS instead of SHT_NOBITS.

Linker script doesn't seem to allow manual specification of the section
type, so just write a byte into the section instead.

Signed-off-by: Josh Poimboeuf 
Signed-off-by: Huaixin Chang 
Signed-off-by: Shile Zhang 
---
 include/asm-generic/vmlinux.lds.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index db600ef218d7..49f4f5bc6165 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -826,6 +826,8 @@
. += (((SIZEOF(.text) + LOOKUP_BLOCK_SIZE - 1) /\
LOOKUP_BLOCK_SIZE) + 1) * 4;\
orc_lookup_end = .; \
+   /* HACK: force SHT_PROGBITS so sorttable can edit: */   \
+   BYTE(1);\
}
 #else
 #define ORC_UNWIND_TABLE
-- 
2.14.4.44.g2045bb6

[PATCH 3/3] x86/unwind/orc: Simplify unwind_init() for x86 boot

[Huaixin Chang]

The orc fast lookup table is built by scripts/sorttable tool. All that
is left is setting lookup_num_blocks.

Signed-off-by: Huaixin Chang 
Signed-off-by: Shile Zhang 
---
 arch/x86/kernel/unwind_orc.c | 41 ++---
 1 file changed, 2 insertions(+), 39 deletions(-)

diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
index 7f969b2d240f..0ca4d02d1a69 100644
--- a/arch/x86/kernel/unwind_orc.c
+++ b/arch/x86/kernel/unwind_orc.c
@@ -264,48 +264,11 @@ void unwind_module_init(struct module *mod, void 
*_orc_ip, size_t orc_ip_size,
 
 void __init unwind_init(void)
 {
-   size_t orc_ip_size = (void *)__stop_orc_unwind_ip - (void 
*)__start_orc_unwind_ip;
-   size_t orc_size = (void *)__stop_orc_unwind - (void 
*)__start_orc_unwind;
-   size_t num_entries = orc_ip_size / sizeof(int);
-   struct orc_entry *orc;
-   int i;
-
-   if (!num_entries || orc_ip_size % sizeof(int) != 0 ||
-   orc_size % sizeof(struct orc_entry) != 0 ||
-   num_entries != orc_size / sizeof(struct orc_entry)) {
-   orc_warn("WARNING: Bad or missing .orc_unwind table.  Disabling 
unwinder.\n");
-   return;
-   }
-
/*
-* Note, the orc_unwind and orc_unwind_ip tables were already
-* sorted at build time via the 'sorttable' tool.
-* It's ready for binary search straight away, no need to sort it.
+* All orc tables are sorted and built via sorttable tool. Initialize
+* lookup_num_blocks only.
 */
-
-   /* Initialize the fast lookup table: */
lookup_num_blocks = orc_lookup_end - orc_lookup;
-   for (i = 0; i < lookup_num_blocks-1; i++) {
-   orc = __orc_find(__start_orc_unwind_ip, __start_orc_unwind,
-num_entries,
-LOOKUP_START_IP + (LOOKUP_BLOCK_SIZE * i));
-   if (!orc) {
-   orc_warn("WARNING: Corrupt .orc_unwind table.  
Disabling unwinder.\n");
-   return;
-   }
-
-   orc_lookup[i] = orc - __start_orc_unwind;
-   }
-
-   /* Initialize the ending block: */
-   orc = __orc_find(__start_orc_unwind_ip, __start_orc_unwind, num_entries,
-LOOKUP_STOP_IP);
-   if (!orc) {
-   orc_warn("WARNING: Corrupt .orc_unwind table.  Disabling 
unwinder.\n");
-   return;
-   }
-   orc_lookup[lookup_num_blocks-1] = orc - __start_orc_unwind;
-
orc_init = true;
 }
 
-- 
2.14.4.44.g2045bb6

[PATCH v2 4/4] soc: mediatek: pwrap: add pwrap driver for MT6873/8192 SoCs

[Hsin-Hsiung Wang]

MT6873/8192 are highly integrated SoCs and use PMIC_MT6359 for
power management. This patch adds pwrap master driver to
access PMIC_MT6359.

Signed-off-by: Hsin-Hsiung Wang 
---
 drivers/soc/mediatek/mtk-pmic-wrap.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c 
b/drivers/soc/mediatek/mtk-pmic-wrap.c
index 8d76ed4..6ba0604 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -632,6 +632,17 @@ static int mt6797_regs[] = {
[PWRAP_DCM_DBC_PRD] =   0x1D4,
 };
 
+static int mt6873_regs[] = {
+   [PWRAP_INIT_DONE2] =0x0,
+   [PWRAP_TIMER_EN] =  0x3E0,
+   [PWRAP_INT_EN] =0x448,
+   [PWRAP_WACS2_CMD] = 0xC80,
+   [PWRAP_SWINF_2_WDATA_31_0] =0xC84,
+   [PWRAP_SWINF_2_RDATA_31_0] =0xC94,
+   [PWRAP_WACS2_VLDCLR] =  0xCA4,
+   [PWRAP_WACS2_RDATA] =   0xCA8,
+};
+
 static int mt7622_regs[] = {
[PWRAP_MUX_SEL] =   0x0,
[PWRAP_WRAP_EN] =   0x4,
@@ -1050,6 +1061,7 @@ enum pwrap_type {
PWRAP_MT6765,
PWRAP_MT6779,
PWRAP_MT6797,
+   PWRAP_MT6873,
PWRAP_MT7622,
PWRAP_MT8135,
PWRAP_MT8173,
@@ -1517,6 +1529,7 @@ static int pwrap_init_cipher(struct pmic_wrapper *wrp)
case PWRAP_MT7622:
pwrap_writel(wrp, 0, PWRAP_CIPHER_EN);
break;
+   case PWRAP_MT6873:
case PWRAP_MT8183:
break;
}
@@ -1953,6 +1966,19 @@ static const struct pmic_wrapper_type pwrap_mt6797 = {
.init_soc_specific = NULL,
 };
 
+static struct pmic_wrapper_type pwrap_mt6873 = {
+   .regs = mt6873_regs,
+   .type = PWRAP_MT6873,
+   .arb_en_all = 0x777f,
+   .int_en_all = BIT(4) | BIT(5),
+   .int1_en_all = 0,
+   .spi_w = PWRAP_MAN_CMD_SPI_WRITE,
+   .wdt_src = PWRAP_WDT_SRC_MASK_ALL,
+   .caps = PWRAP_CAP_ARB,
+   .init_reg_clock = pwrap_common_init_reg_clock,
+   .init_soc_specific = NULL,
+};
+
 static const struct pmic_wrapper_type pwrap_mt7622 = {
.regs = mt7622_regs,
.type = PWRAP_MT7622,
@@ -2031,6 +2057,9 @@ static const struct of_device_id of_pwrap_match_tbl[] = {
.compatible = "mediatek,mt6797-pwrap",
.data = _mt6797,
}, {
+   .compatible = "mediatek,mt6873-pwrap",
+   .data = _mt6873,
+   }, {
.compatible = "mediatek,mt7622-pwrap",
.data = _mt7622,
}, {
-- 
2.6.4

[PATCH v2 2/4] soc: mediatek: pwrap: add arbiter capability

[Hsin-Hsiung Wang]

Add arbiter capability for pwrap driver.
This patch is preparing for adding mt6873/8192 pwrap support.

Signed-off-by: Hsin-Hsiung Wang 
---
 drivers/soc/mediatek/mtk-pmic-wrap.c | 67 ++--
 1 file changed, 56 insertions(+), 11 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c 
b/drivers/soc/mediatek/mtk-pmic-wrap.c
index c897205..8d76ed4 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -24,11 +24,13 @@
 #define PWRAP_MT8135_BRIDGE_WDT_SRC_EN 0x54
 
 /* macro for wrapper status */
+#define PWRAP_GET_SWINF_2_FSM(x)   (((x) >> 1) & 0x0007)
 #define PWRAP_GET_WACS_RDATA(x)(((x) >> 0) & 0x)
 #define PWRAP_GET_WACS_FSM(x)  (((x) >> 16) & 0x0007)
 #define PWRAP_GET_WACS_REQ(x)  (((x) >> 19) & 0x0001)
 #define PWRAP_STATE_SYNC_IDLE0 BIT(20)
 #define PWRAP_STATE_INIT_DONE0 BIT(21)
+#define PWRAP_STATE_INIT_DONE1 BIT(15)
 
 /* macro for WACS FSM */
 #define PWRAP_WACS_FSM_IDLE0x00
@@ -74,6 +76,7 @@
 #define PWRAP_CAP_DCM  BIT(2)
 #define PWRAP_CAP_INT1_EN  BIT(3)
 #define PWRAP_CAP_WDT_SRC1 BIT(4)
+#define PWRAP_CAP_ARB  BIT(5)
 
 /* defines for slave device wrapper registers */
 enum dew_regs {
@@ -340,6 +343,8 @@ enum pwrap_regs {
PWRAP_DCM_DBC_PRD,
PWRAP_EINT_STA0_ADR,
PWRAP_EINT_STA1_ADR,
+   PWRAP_SWINF_2_WDATA_31_0,
+   PWRAP_SWINF_2_RDATA_31_0,
 
/* MT2701 only regs */
PWRAP_ADC_CMD_ADDR,
@@ -1108,16 +1113,30 @@ static void pwrap_writel(struct pmic_wrapper *wrp, u32 
val, enum pwrap_regs reg)
 
 static bool pwrap_is_fsm_idle(struct pmic_wrapper *wrp)
 {
-   u32 val = pwrap_readl(wrp, PWRAP_WACS2_RDATA);
+   u32 val;
+   bool ret;
+
+   val = pwrap_readl(wrp, PWRAP_WACS2_RDATA);
+   if (!HAS_CAP(wrp->master->caps, PWRAP_CAP_ARB))
+   ret = (PWRAP_GET_WACS_FSM(val) == PWRAP_WACS_FSM_IDLE);
+   else
+   ret = (PWRAP_GET_SWINF_2_FSM(val) == PWRAP_WACS_FSM_IDLE);
 
-   return PWRAP_GET_WACS_FSM(val) == PWRAP_WACS_FSM_IDLE;
+   return ret;
 }
 
 static bool pwrap_is_fsm_vldclr(struct pmic_wrapper *wrp)
 {
-   u32 val = pwrap_readl(wrp, PWRAP_WACS2_RDATA);
+   u32 val;
+   bool ret;
+
+   val = pwrap_readl(wrp, PWRAP_WACS2_RDATA);
+   if (!HAS_CAP(wrp->master->caps, PWRAP_CAP_ARB))
+   ret = (PWRAP_GET_WACS_FSM(val) == PWRAP_WACS_FSM_WFVLDCLR);
+   else
+   ret = (PWRAP_GET_SWINF_2_FSM(val) == PWRAP_WACS_FSM_WFVLDCLR);
 
-   return PWRAP_GET_WACS_FSM(val) == PWRAP_WACS_FSM_WFVLDCLR;
+   return ret;
 }
 
 /*
@@ -1172,13 +1191,21 @@ static int pwrap_read16(struct pmic_wrapper *wrp, u32 
adr, u32 *rdata)
return ret;
}
 
-   pwrap_writel(wrp, (adr >> 1) << 16, PWRAP_WACS2_CMD);
+   if (!HAS_CAP(wrp->master->caps, PWRAP_CAP_ARB))
+   pwrap_writel(wrp, (adr >> 1) << 16, PWRAP_WACS2_CMD);
+   else
+   pwrap_writel(wrp, adr, PWRAP_WACS2_CMD);
 
ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_vldclr);
if (ret)
return ret;
 
-   *rdata = PWRAP_GET_WACS_RDATA(pwrap_readl(wrp, PWRAP_WACS2_RDATA));
+   if (!HAS_CAP(wrp->master->caps, PWRAP_CAP_ARB))
+   *rdata = PWRAP_GET_WACS_RDATA(pwrap_readl(wrp,
+ PWRAP_WACS2_RDATA));
+   else
+   *rdata = PWRAP_GET_WACS_RDATA(pwrap_readl(wrp,
+ PWRAP_SWINF_2_RDATA_31_0));
 
pwrap_writel(wrp, 1, PWRAP_WACS2_VLDCLR);
 
@@ -1228,8 +1255,13 @@ static int pwrap_write16(struct pmic_wrapper *wrp, u32 
adr, u32 wdata)
return ret;
}
 
-   pwrap_writel(wrp, (1 << 31) | ((adr >> 1) << 16) | wdata,
-PWRAP_WACS2_CMD);
+   if (!HAS_CAP(wrp->master->caps, PWRAP_CAP_ARB)) {
+   pwrap_writel(wrp, BIT(31) | ((adr >> 1) << 16) | wdata,
+PWRAP_WACS2_CMD);
+   } else {
+   pwrap_writel(wrp, wdata, PWRAP_SWINF_2_WDATA_31_0);
+   pwrap_writel(wrp, BIT(29) | adr, PWRAP_WACS2_CMD);
+   }
 
return 0;
 }
@@ -2022,6 +2054,7 @@ MODULE_DEVICE_TABLE(of, of_pwrap_match_tbl);
 static int pwrap_probe(struct platform_device *pdev)
 {
int ret, irq;
+   u32 rdata;
struct pmic_wrapper *wrp;
struct device_node *np = pdev->dev.of_node;
const struct of_device_id *of_slave_id = NULL;
@@ -2116,14 +2149,22 @@ static int pwrap_probe(struct platform_device *pdev)
}
}
 
-   if (!(pwrap_readl(wrp, PWRAP_WACS2_RDATA) & PWRAP_STATE_INIT_DONE0)) {
+   if (!HAS_CAP(wrp->master->caps, PWRAP_CAP_ARB))
+   rdata = pwrap_readl(wrp, PWRAP_WACS2_RDATA) &
+   PWRAP_STATE_INIT_DONE0;
+   else
+   rdata = 

[PATCH v2 3/4] dt-bindings: mediatek: add compatible for MT6873/8192 pwrap

[Hsin-Hsiung Wang]

This adds dt-binding documentation of pwrap for Mediatek MT6873/8192
SoCs Platform.

Signed-off-by: Hsin-Hsiung Wang 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/soc/mediatek/pwrap.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt 
b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
index ecac2bb..8051c17 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
+++ b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
@@ -22,6 +22,7 @@ Required properties in pwrap device node.
"mediatek,mt6765-pwrap" for MT6765 SoCs
"mediatek,mt6779-pwrap" for MT6779 SoCs
"mediatek,mt6797-pwrap" for MT6797 SoCs
+   "mediatek,mt6873-pwrap" for MT6873/8192 SoCs
"mediatek,mt7622-pwrap" for MT7622 SoCs
"mediatek,mt8135-pwrap" for MT8135 SoCs
"mediatek,mt8173-pwrap" for MT8173 SoCs
-- 
2.6.4

[PATCH v2 0/4] Add PMIC wrapper support for Mediatek MT6873/8192 SoC IC

[Hsin-Hsiung Wang]

This series adds support for new SoC MT6873/8192 to the pmic-wrap driver.

changes since v1:
- separate PWRAP_CAP_ARB to a new patch.

Hsin-Hsiung Wang (4):
  soc: mediatek: pwrap: use BIT() macro
  soc: mediatek: pwrap: add arbiter capability
  dt-bindings: mediatek: add compatible for MT6873/8192 pwrap
  soc: mediatek: pwrap: add pwrap driver for MT6873/8192 SoCs

 .../devicetree/bindings/soc/mediatek/pwrap.txt |   1 +
 drivers/soc/mediatek/mtk-pmic-wrap.c   | 100 ++---
 2 files changed, 88 insertions(+), 13 deletions(-)

-- 
2.6.4

[PATCH v2 1/4] soc: mediatek: pwrap: use BIT() macro

[Hsin-Hsiung Wang]

Use a better BIT() marco for the bit definition.
No functional changes, cleanup only.

Signed-off-by: Hsin-Hsiung Wang 
---
 drivers/soc/mediatek/mtk-pmic-wrap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c 
b/drivers/soc/mediatek/mtk-pmic-wrap.c
index 5d34e8b..c897205 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -27,8 +27,8 @@
 #define PWRAP_GET_WACS_RDATA(x)(((x) >> 0) & 0x)
 #define PWRAP_GET_WACS_FSM(x)  (((x) >> 16) & 0x0007)
 #define PWRAP_GET_WACS_REQ(x)  (((x) >> 19) & 0x0001)
-#define PWRAP_STATE_SYNC_IDLE0 (1 << 20)
-#define PWRAP_STATE_INIT_DONE0 (1 << 21)
+#define PWRAP_STATE_SYNC_IDLE0 BIT(20)
+#define PWRAP_STATE_INIT_DONE0 BIT(21)
 
 /* macro for WACS FSM */
 #define PWRAP_WACS_FSM_IDLE0x00
-- 
2.6.4

Re: [RFC PATCH] makefile: add debug option to enable function aligned on 32 bytes

[Andrew Morton]

On Thu, 23 Jul 2020 11:30:01 +0800 Feng Tang  wrote:

> Recently 0day reported many strange performance changes (regression
> or improvement), in which there was no obvious relation between
> the culprit commit and the benchmark at the first look, and it causes
> people to doubt the test itself is wrong.
> 
> Upon further check, many of these cases are caused by the change
> to the alignment of kernel text or data, as whole text/data of kernel
> are linked together, change in one domain may affect alignments of
> other domains.
> 
> gcc has an option '-falign-functions=n' to force text aligned, and with
> that option enabled, some of those performance changes will be gone,
> like [1][2][3].
> 
> Add this option so that developers and 0day can easily find performance
> bump caused by text alignment change,

Would they use it this way, or would they simply always enable the
option to reduce the variability?

It makes sense, but is it actually known that this does reduce the
variability?

> as tracking these strange bump
> is quite time consuming. Though it can't help in other cases like data
> alignment changes like [4].
> 
> Following is some size data for v5.7 kernel built with a RHEL config
> used in 0day:
> 
> text  data  bssdec   filename
>   19738771  13292906  5554236  38585913vmlinux.noalign
>   19758591  13297002  5529660  38585253vmlinux.align32
> 
> Raw vmlinux size in bytes:
> 
>   v5.7v5.7+align32
>   253950832   254018000   +0.02%
> 
> Some benchmark data, most of them have no big change:
> 
>   * hackbench:[ -1.8%,  +0.5%]
> 
>   * fsmark:   [ -3.2%,  +3.4%]  # ext4/xfs/btrfs
> 
>   * kbuild:   [ -2.0%,  +0.9%]
> 
>   * will-it-scale:[ -0.5%,  +1.8%]  # mmap1/pagefault3
> 
>   * netperf:
> - TCP_CRR [+16.6%, +97.4%]
> - TCP_RR  [-18.5%,  -1.8%]
> - TCP_STREAM  [ -1.1%,  +1.9%]

What do the numbers in [] mean?  The TCP_CRR results look remarkable?

> [1] https://lore.kernel.org/lkml/20200114085637.GA29297@shao2-debian/
> [2] https://lore.kernel.org/lkml/20200330011254.GA14393@feng-iot/
> [3] 
> https://lore.kernel.org/lkml/1d98d1f0-fe84-6df7-f5bd-f4cb2cdb7...@intel.com/
> [4] https://lore.kernel.org/lkml/20200205123216.GO12867@shao2-debian/
> 

Re: [PATCH v5 3/9] ufs: ufs-qcom: Fix race conditions caused by func ufs_qcom_testbus_config

[hongwus]

On 2020-07-23 10:34, Can Guo wrote:

If ufs_qcom_dump_dbg_regs() calls ufs_qcom_testbus_config() from
ufshcd_suspend/resume and/or clk gate/ungate context, 
pm_runtime_get_sync()

and ufshcd_hold() will cause racing problems. Fix this by removing the
unnecessary calls of pm_runtime_get_sync() and ufshcd_hold().

Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/ufs-qcom.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 2e6ddb5..7da27ee 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1604,9 +1604,6 @@ int ufs_qcom_testbus_config(struct ufs_qcom_host 
*host)

 */
}
mask <<= offset;
-
-   pm_runtime_get_sync(host->hba->dev);
-   ufshcd_hold(host->hba, false);
ufshcd_rmwl(host->hba, TEST_BUS_SEL,
(u32)host->testbus.select_major << 19,
REG_UFS_CFG1);
@@ -1619,8 +1616,6 @@ int ufs_qcom_testbus_config(struct ufs_qcom_host 
*host)

 * committed before returning.
 */
mb();
-   ufshcd_release(host->hba);
-   pm_runtime_put_sync(host->hba->dev);

return 0;
 }



Reviewed-by: Hongwu Su 

Re: [PATCH v1] clk: Export __clk_lookup()

[elaine.zhang]

在 2020/7/23 上午2:26, Heiko Stuebner 写道:

Hi Elaine,

Am Mittwoch, 22. Juli 2020, 04:32:30 CEST schrieb Elaine Zhang:

Export __clk_lookup() to support user built as module.

ERROR:
drivers/clk/rockchip/clk.ko: In function
`rockchip_clk_protect_critical':
drivers/clk/rockchip/clk.c:741:
undefined reference to `__clk_lookup'

can you elaborate a bit more on why this would be needed?

Because right now the Rockchip clocks are of course built into
the main kernel image (especially due to them being needed during early
boot) and __clk_lookup actually is a pretty deep part of the clock-
framework itself, as probably also denoted by the "__" in the function
name.


Rockchip clocks are of course support to built as module(to support GKI),These 
changes will be pushed soon.
In drivers/clk/rockchip/clk.c and drivers/clk/rockchip/clk-cpu.c use the 
__clk_lookup.




Heiko


Signed-off-by: Elaine Zhang 
---
  drivers/clk/clk.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 3f588ed06ce3..600284fbb257 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -618,6 +618,7 @@ struct clk *__clk_lookup(const char *name)
  
  	return !core ? NULL : core->hw->clk;

  }
+EXPORT_SYMBOL_GPL(__clk_lookup);
  
  static void clk_core_get_boundaries(struct clk_core *core,

unsigned long *min_rate,

Re: [PATCH v2 2/2] KVM: PPC: Book3S HV: rework secure mem slot dropping

[Bharata B Rao]

On Tue, Jul 21, 2020 at 12:42:02PM +0200, Laurent Dufour wrote:
> When a secure memslot is dropped, all the pages backed in the secure device
> (aka really backed by secure memory by the Ultravisor) should be paged out
> to a normal page. Previously, this was achieved by triggering the page
> fault mechanism which is calling kvmppc_svm_page_out() on each pages.
> 
> This can't work when hot unplugging a memory slot because the memory slot
> is flagged as invalid and gfn_to_pfn() is then not trying to access the
> page, so the page fault mechanism is not triggered.
> 
> Since the final goal is to make a call to kvmppc_svm_page_out() it seems
> simpler to directly calling it instead of triggering such a mechanism. This
> way kvmppc_uvmem_drop_pages() can be called even when hot unplugging a
> memslot.
> 
> Since kvmppc_uvmem_drop_pages() is already holding kvm->arch.uvmem_lock,
> the call to __kvmppc_svm_page_out() is made.
> As __kvmppc_svm_page_out needs the vma pointer to migrate the pages, the
> VMA is fetched in a lazy way, to not trigger find_vma() all the time. In
> addition, the mmap_sem is help in read mode during that time, not in write
> mode since the virual memory layout is not impacted, and
> kvm->arch.uvmem_lock prevents concurrent operation on the secure device.
> 
> Cc: Ram Pai 
> Cc: Bharata B Rao 
> Cc: Paul Mackerras 
> Signed-off-by: Laurent Dufour 
> ---
>  arch/powerpc/kvm/book3s_hv_uvmem.c | 54 --
>  1 file changed, 37 insertions(+), 17 deletions(-)
> 
> diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c 
> b/arch/powerpc/kvm/book3s_hv_uvmem.c
> index 5a4b02d3f651..ba5c7c77cc3a 100644
> --- a/arch/powerpc/kvm/book3s_hv_uvmem.c
> +++ b/arch/powerpc/kvm/book3s_hv_uvmem.c
> @@ -624,35 +624,55 @@ static inline int kvmppc_svm_page_out(struct 
> vm_area_struct *vma,
>   * fault on them, do fault time migration to replace the device PTEs in
>   * QEMU page table with normal PTEs from newly allocated pages.
>   */
> -void kvmppc_uvmem_drop_pages(const struct kvm_memory_slot *free,
> +void kvmppc_uvmem_drop_pages(const struct kvm_memory_slot *slot,
>struct kvm *kvm, bool skip_page_out)
>  {
>   int i;
>   struct kvmppc_uvmem_page_pvt *pvt;
> - unsigned long pfn, uvmem_pfn;
> - unsigned long gfn = free->base_gfn;
> + struct page *uvmem_page;
> + struct vm_area_struct *vma = NULL;
> + unsigned long uvmem_pfn, gfn;
> + unsigned long addr, end;
> +
> + mmap_read_lock(kvm->mm);
> +
> + addr = slot->userspace_addr;

We typically use gfn_to_hva() for that, but that won't work for a
memslot that is already marked INVALID which is the case here.
I think it is ok to access slot->userspace_addr here of an INVALID
memslot, but just thought of explictly bringing this up.

> + end = addr + (slot->npages * PAGE_SIZE);
>  
> - for (i = free->npages; i; --i, ++gfn) {
> - struct page *uvmem_page;
> + gfn = slot->base_gfn;
> + for (i = slot->npages; i; --i, ++gfn, addr += PAGE_SIZE) {
> +
> + /* Fetch the VMA if addr is not in the latest fetched one */
> + if (!vma || (addr < vma->vm_start || addr >= vma->vm_end)) {
> + vma = find_vma_intersection(kvm->mm, addr, end);
> + if (!vma ||
> + vma->vm_start > addr || vma->vm_end < end) {
> + pr_err("Can't find VMA for gfn:0x%lx\n", gfn);
> + break;
> + }
> + }

In Ram's series, kvmppc_memslot_page_merge() also walks the VMAs spanning
the memslot, but it uses a different logic for the same. Why can't these
two cases use the same method to walk the VMAs? Is there anything subtly
different between the two cases?

Regards,
Bharata.

Re: [RFC PATCH 11/16] sched: migration changes for core scheduling(Internet mail)

[Li, Aubrey]

On 2020/7/23 10:42, benbjiang(蒋彪) wrote:
> Hi,
> 
>> On Jul 23, 2020, at 9:57 AM, Li, Aubrey  wrote:
>>
>> On 2020/7/22 22:32, benbjiang(蒋彪) wrote:
>>> Hi,
>>>
 On Jul 22, 2020, at 8:13 PM, Li, Aubrey  wrote:

 On 2020/7/22 16:54, benbjiang(蒋彪) wrote:
> Hi, Aubrey,
>
>> On Jul 1, 2020, at 5:32 AM, Vineeth Remanan Pillai 
>>  wrote:
>>
>> From: Aubrey Li 
>>
>> - Don't migrate if there is a cookie mismatch
>>   Load balance tries to move task from busiest CPU to the
>>   destination CPU. When core scheduling is enabled, if the
>>   task's cookie does not match with the destination CPU's
>>   core cookie, this task will be skipped by this CPU. This
>>   mitigates the forced idle time on the destination CPU.
>>
>> - Select cookie matched idle CPU
>>   In the fast path of task wakeup, select the first cookie matched
>>   idle CPU instead of the first idle CPU.
>>
>> - Find cookie matched idlest CPU
>>   In the slow path of task wakeup, find the idlest CPU whose core
>>   cookie matches with task's cookie
>>
>> - Don't migrate task if cookie not match
>>   For the NUMA load balance, don't migrate task to the CPU whose
>>   core cookie does not match with task's cookie
>>
>> Signed-off-by: Aubrey Li 
>> Signed-off-by: Tim Chen 
>> Signed-off-by: Vineeth Remanan Pillai 
>> ---
>> kernel/sched/fair.c  | 64 
>> kernel/sched/sched.h | 29 
>> 2 files changed, 88 insertions(+), 5 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index d16939766361..33dc4bf01817 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -2051,6 +2051,15 @@ static void task_numa_find_cpu(struct 
>> task_numa_env *env,
>>  if (!cpumask_test_cpu(cpu, env->p->cpus_ptr))
>>  continue;
>>
>> +#ifdef CONFIG_SCHED_CORE
>> +/*
>> + * Skip this cpu if source task's cookie does not match
>> + * with CPU's core cookie.
>> + */
>> +if (!sched_core_cookie_match(cpu_rq(cpu), env->p))
>> +continue;
>> +#endif
>> +
>>  env->dst_cpu = cpu;
>>  if (task_numa_compare(env, taskimp, groupimp, maymove))
>>  break;
>> @@ -5963,11 +5972,17 @@ find_idlest_group_cpu(struct sched_group *group, 
>> struct task_struct *p, int this
>>
>>  /* Traverse only the allowed CPUs */
>>  for_each_cpu_and(i, sched_group_span(group), p->cpus_ptr) {
>> +struct rq *rq = cpu_rq(i);
>> +
>> +#ifdef CONFIG_SCHED_CORE
>> +if (!sched_core_cookie_match(rq, p))
>> +continue;
>> +#endif
>> +
>>  if (sched_idle_cpu(i))
>>  return i;
>>
>>  if (available_idle_cpu(i)) {
>> -struct rq *rq = cpu_rq(i);
>>  struct cpuidle_state *idle = idle_get_state(rq);
>>  if (idle && idle->exit_latency < min_exit_latency) {
>>  /*
>> @@ -6224,8 +6239,18 @@ static int select_idle_cpu(struct task_struct *p, 
>> struct sched_domain *sd, int t
>>  for_each_cpu_wrap(cpu, cpus, target) {
>>  if (!--nr)
>>  return -1;
>> -if (available_idle_cpu(cpu) || sched_idle_cpu(cpu))
>> -break;
>> +
>> +if (available_idle_cpu(cpu) || sched_idle_cpu(cpu)) {
>> +#ifdef CONFIG_SCHED_CORE
>> +/*
>> + * If Core Scheduling is enabled, select this 
>> cpu
>> + * only if the process cookie matches core 
>> cookie.
>> + */
>> +if (sched_core_enabled(cpu_rq(cpu)) &&
>> +p->core_cookie == 
>> cpu_rq(cpu)->core->core_cookie)
> Why not also add similar logic in select_idle_smt to reduce forced-idle? 
> :)
 We hit select_idle_smt after we scaned the entire LLC domain for idle cores
 and idle cpus and failed,so IMHO, an idle smt is probably a good choice 
 under
 this scenario.
>>>
>>> AFAIC, selecting idle sibling with unmatched cookie will cause unnecessary 
>>> fored-idle, unfairness and latency, compared to choosing *target* cpu.
>> Choosing target cpu could increase the runnable task number on the target 
>> runqueue, this
>> could trigger busiest->nr_running > 1 logic and makes the idle sibling 
>> trying to pull but
>> not success(due to cookie not match). Putting task to the idle sibling is 
>> relatively stable IMHO.
> 
> I’m afraid that *unsuccessful* pullings between smts 

[RFC PATCH] makefile: add debug option to enable function aligned on 32 bytes

[Feng Tang]

Recently 0day reported many strange performance changes (regression
or improvement), in which there was no obvious relation between
the culprit commit and the benchmark at the first look, and it causes
people to doubt the test itself is wrong.

Upon further check, many of these cases are caused by the change
to the alignment of kernel text or data, as whole text/data of kernel
are linked together, change in one domain may affect alignments of
other domains.

gcc has an option '-falign-functions=n' to force text aligned, and with
that option enabled, some of those performance changes will be gone,
like [1][2][3].

Add this option so that developers and 0day can easily find performance
bump caused by text alignment change, as tracking these strange bump
is quite time consuming. Though it can't help in other cases like data
alignment changes like [4].

Following is some size data for v5.7 kernel built with a RHEL config
used in 0day:

text  data  bss  dec   filename
  19738771  13292906  5554236  38585913  vmlinux.noalign
  19758591  13297002  5529660  38585253  vmlinux.align32

Raw vmlinux size in bytes:

v5.7v5.7+align32
253950832   254018000   +0.02%

Some benchmark data, most of them have no big change:

  * hackbench:  [ -1.8%,  +0.5%]

  * fsmark: [ -3.2%,  +3.4%]  # ext4/xfs/btrfs

  * kbuild: [ -2.0%,  +0.9%]

  * will-it-scale:  [ -0.5%,  +1.8%]  # mmap1/pagefault3

  * netperf:
- TCP_CRR   [+16.6%, +97.4%]
- TCP_RR[-18.5%,  -1.8%]
- TCP_STREAM[ -1.1%,  +1.9%]

[1] https://lore.kernel.org/lkml/20200114085637.GA29297@shao2-debian/
[2] https://lore.kernel.org/lkml/20200330011254.GA14393@feng-iot/
[3] https://lore.kernel.org/lkml/1d98d1f0-fe84-6df7-f5bd-f4cb2cdb7...@intel.com/
[4] https://lore.kernel.org/lkml/20200205123216.GO12867@shao2-debian/

Signed-off-by: Feng Tang 
---
 Makefile  |  4 
 lib/Kconfig.debug | 11 +++
 2 files changed, 15 insertions(+)

diff --git a/Makefile b/Makefile
index 249a51d25c63..a59105e6f573 100644
--- a/Makefile
+++ b/Makefile
@@ -886,6 +886,10 @@ KBUILD_CFLAGS  += $(CC_FLAGS_SCS)
 export CC_FLAGS_SCS
 endif
 
+ifdef CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_32B
+KBUILD_CFLAGS += -falign-functions=32
+endif
+
 # arch Makefile may override CC so keep this after arch Makefile is included
 NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
 
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 9ad9210d70a1..c1d52c4f120f 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -365,6 +365,17 @@ config SECTION_MISMATCH_WARN_ONLY
 
  If unsure, say Y.
 
+config DEBUG_FORCE_FUNCTION_ALIGN_32B
+   bool "Force all function address 32B aligned" if EXPERT
+   help
+ There are cases that a commit from one domain changes the function
+ address alignment of other domains, and cause magic performance
+ bump (regression or improvement). Enable this option will help to
+ verify if the bump is caused by function alignment changes, while
+ it will slightly increase the kernel size and affect icache usage.
+
+ It is mainly for debug and performance tuning use.
+
 #
 # Select this config option from the architecture Kconfig, if it
 # is preferred to always offer frame pointers as a config
-- 
2.14.1

答复: [PATCH] arm64: mm: free unused memmap for sparse memory model that define VMEMMAP

[liwei (CM)]

-邮件原件-
发件人: Anshuman Khandual [mailto:anshuman.khand...@arm.com] 
发送时间: 2020年7月23日 10:33
收件人: liwei (CM) ; catalin.mari...@arm.com; w...@kernel.org
抄送: Song Bao Hua (Barry Song) ; sujunfei 
; Xiaqing (A) ; 
linux-arm-ker...@lists.infradead.org; steve.cap...@arm.com; Chenfeng (puck) 
; linux-kernel@vger.kernel.org; r...@linux.ibm.com; 
fengbaopeng ; nsaenzjulie...@suse.de; butao 

主题: Re: [PATCH] arm64: mm: free unused memmap for sparse memory model that 
define VMEMMAP



On 07/21/2020 01:02 PM, Wei Li wrote:
> For the memory hole, sparse memory model that define SPARSEMEM_VMEMMAP 
> do not free the reserved memory for the page map, this patch do it.
> 
> Signed-off-by: Wei Li 
> Signed-off-by: Chen Feng 
> Signed-off-by: Xia Qing 
> ---
>  arch/arm64/mm/init.c | 81 
> +---
>  1 file changed, 71 insertions(+), 10 deletions(-)

This patch does not compile on 5.8-rc6 with defconfig.

Hi,

We're working on patch v2 as soon as possible.

Thanks.

[PATCH -next 1/2] drm: Remove redundant NULL check

[Li Heng]

Fix below warnings reported by coccicheck:
./drivers/gpu/drm/drm_drv.c:819:2-7: WARNING: NULL check before some freeing 
functions is not needed.

Fixes: 5dad34f3c444 ("drm: Cleanups after drmm_add_final_kfree rollout")
Signed-off-by: Li Heng 
---
 drivers/gpu/drm/drm_drv.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index bc38322..13068fd 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -815,8 +815,7 @@ static void drm_dev_release(struct kref *ref)
 
drm_managed_release(dev);
 
-   if (dev->managed.final_kfree)
-   kfree(dev->managed.final_kfree);
+   kfree(dev->managed.final_kfree);
 }
 
 /**
-- 
2.7.4

[PATCH -next 2/2] drm: Remove redundant NULL check

[Li Heng]

Fix below warnings reported by coccicheck:
./drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c:557:2-7: 
WARNING: NULL check before some freeing functions is not needed.

Fixes: 4d55b0dd1cdd ("drm/amd/display: Add DCN3 CLK_MGR")
Signed-off-by: Li Heng 
---
 drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c 
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c
index d94fdc5..d8af56a 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c
@@ -553,8 +553,7 @@ void dcn3_clk_mgr_construct(
 
 void dcn3_clk_mgr_destroy(struct clk_mgr_internal *clk_mgr)
 {
-   if (clk_mgr->base.bw_params)
-   kfree(clk_mgr->base.bw_params);
+   kfree(clk_mgr->base.bw_params);
 
if (clk_mgr->wm_range_table)
dm_helpers_free_gpu_mem(clk_mgr->base.ctx, 
DC_MEM_ALLOC_TYPE_GART,
-- 
2.7.4

Re: [PATCH -next] io_uring: Remove redundant NULL check

[Jens Axboe]

On 7/22/20 9:19 PM, Li Heng wrote:
> Fix below warnings reported by coccicheck:
> ./fs/io_uring.c:1544:2-7: WARNING: NULL check before some freeing functions 
> is not needed.
> ./fs/io_uring.c:3095:2-7: WARNING: NULL check before some freeing functions 
> is not needed.
> ./fs/io_uring.c:3195:2-7: WARNING: NULL check before some freeing functions 
> is not needed.

Not needed, but it's faster that way. See recent discussions on the
io-uring list. Hence they are very much on purpose, and it'd be great if
someone would ensure that kfree() was an inline that checks for non-NULL
before calling __kfree() or whatever the real function would then be.

-- 
Jens Axboe

[PATCH v2 3/4] doc/vm: fix typo in the hugetlb admin documentation

[Baoquan He]

Change 'pecify' to 'Specify'.

Signed-off-by: Baoquan He 
Reviewed-by: Mike Kravetz 
Reviewed-by: David Hildenbrand 
---
 Documentation/admin-guide/mm/hugetlbpage.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst 
b/Documentation/admin-guide/mm/hugetlbpage.rst
index 015a5f7d7854..f7b1c7462991 100644
--- a/Documentation/admin-guide/mm/hugetlbpage.rst
+++ b/Documentation/admin-guide/mm/hugetlbpage.rst
@@ -131,7 +131,7 @@ hugepages
parameter is preceded by an invalid hugepagesz parameter, it will
be ignored.
 default_hugepagesz
-   pecify the default huge page size.  This parameter can
+   Specify the default huge page size.  This parameter can
only be specified once on the command line.  default_hugepagesz can
optionally be followed by the hugepages parameter to preallocate a
specific number of huge pages of default size.  The number of default
-- 
2.17.2

Re: [PATCH v12 00/18] Enable FSGSBASE instructions

[Jarkko Sakkinen]

On Sat, Jul 18, 2020 at 02:19:52PM -0400, Don Porter wrote:
> On 6/25/20 5:37 PM, Jarkko Sakkinen wrote:
> > 
> > Can unmodified Graphene-SGX used with these changes?
> > 
> 
> Yes.  I just double-checked that all of the needed changes have made it to
> master branch.
> 
> I also re-tested on 5.8-rc1 with v13 of the patch, and it looks good.

OK, cool, have to play with this once I'm back from vacation (away
WW31-WW32). Thanks for the info.

/Jarkko

[PATCH v2 2/4] mm/hugetlb.c: Remove the unnecessary non_swap_entry()

[Baoquan He]

The checking is_migration_entry() and is_hwpoison_entry() are stricter
than non_swap_entry(), means they have covered the conditional check
which non_swap_entry() is doing.

Hence remove the unnecessary non_swap_entry() in is_hugetlb_entry_migration()
and is_hugetlb_entry_hwpoisoned() to simplify code.

Signed-off-by: Baoquan He 
Reviewed-by: Mike Kravetz 
Reviewed-by: David Hildenbrand 
---
 mm/hugetlb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 3569e731e66b..c14837854392 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3748,7 +3748,7 @@ bool is_hugetlb_entry_migration(pte_t pte)
if (huge_pte_none(pte) || pte_present(pte))
return false;
swp = pte_to_swp_entry(pte);
-   if (non_swap_entry(swp) && is_migration_entry(swp))
+   if (is_migration_entry(swp))
return true;
else
return false;
@@ -3761,7 +3761,7 @@ static bool is_hugetlb_entry_hwpoisoned(pte_t pte)
if (huge_pte_none(pte) || pte_present(pte))
return false;
swp = pte_to_swp_entry(pte);
-   if (non_swap_entry(swp) && is_hwpoison_entry(swp))
+   if (is_hwpoison_entry(swp))
return true;
else
return false;
-- 
2.17.2

[PATCH v2 4/4] mm/hugetl.c: warn out if expected count of huge pages adjustment is not achieved

[Baoquan He]

A customer complained that no message is logged when the number of
persistent huge pages is not changed to the exact value written to
the sysfs or proc nr_hugepages file.

In the current code, a best effort is made to satisfy requests made
via the nr_hugepages file.  However, requests may be only partially
satisfied.

Log a message if the code was unsuccessful in fully satisfying a
request. This includes both increasing and decreasing the number
of persistent huge pages.

Signed-off-by: Baoquan He 
---
 mm/hugetlb.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index c14837854392..b5aa32a13569 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2661,7 +2661,7 @@ static int adjust_pool_surplus(struct hstate *h, 
nodemask_t *nodes_allowed,
 static int set_max_huge_pages(struct hstate *h, unsigned long count, int nid,
  nodemask_t *nodes_allowed)
 {
-   unsigned long min_count, ret;
+   unsigned long min_count, ret, old_max, new_max;
NODEMASK_ALLOC(nodemask_t, node_alloc_noretry, GFP_KERNEL);
 
/*
@@ -2723,6 +2723,7 @@ static int set_max_huge_pages(struct hstate *h, unsigned 
long count, int nid,
 * pool might be one hugepage larger than it needs to be, but
 * within all the constraints specified by the sysctls.
 */
+   old_max = persistent_huge_pages(h);
while (h->surplus_huge_pages && count > persistent_huge_pages(h)) {
if (!adjust_pool_surplus(h, nodes_allowed, -1))
break;
@@ -2779,8 +2780,20 @@ static int set_max_huge_pages(struct hstate *h, unsigned 
long count, int nid,
}
 out:
h->max_huge_pages = persistent_huge_pages(h);
+   new_max = h->max_huge_pages;
spin_unlock(_lock);
 
+   if (count != new_max) {
+   char buf[32];
+
+   string_get_size(huge_page_size(h), 1, STRING_UNITS_2, buf, 32);
+   pr_warn("HugeTLB: %s %lu of page size %s failed. Only %s %lu 
hugepages.\n",
+   count > old_max ? "increasing" : "decreasing",
+   abs(count - old_max), buf,
+   count > old_max ? "increased" : "decreased",
+   abs(old_max - new_max));
+   }
+
NODEMASK_FREE(node_alloc_noretry);
 
return 0;
-- 
2.17.2

[PATCH v2 0/4] mm/hugetlb: Small cleanup and improvement

[Baoquan He]

v1 is here:
https://lore.kernel.org/linux-mm/20200720062623.13135-1-...@redhat.com/

Patch 1~3 are small clean up.

Patch 4 is adding warning message when the number of persistent huge
pages is not changed to the exact value written to the sysfs or proc
nr_hugepages file.

v1->v2:
  Drop the old patch 1/5 in v1 post, which was thought as typo, while
  actually another kind of abbreviation.

  Updated patch log of patch 4 which is rephrased by Mike. And move the
  added message logging code after the hugetlb_lock dropping, this is
  suggested by Mike.


Baoquan He (4):
  mm/hugetlb.c: make is_hugetlb_entry_hwpoisoned return bool
  mm/hugetlb.c: Remove the unnecessary non_swap_entry()
  doc/vm: fix typo in the hugetlb admin documentation
  mm/hugetl.c: warn out if expected count of huge pages adjustment is
not achieved

 Documentation/admin-guide/mm/hugetlbpage.rst |  2 +-
 mm/hugetlb.c | 27 +++-
 2 files changed, 21 insertions(+), 8 deletions(-)

-- 
2.17.2

[PATCH v2 1/4] mm/hugetlb.c: make is_hugetlb_entry_hwpoisoned return bool

[Baoquan He]

Just like its neighbour is_hugetlb_entry_migration() has done.

Signed-off-by: Baoquan He 
Reviewed-by: Mike Kravetz 
Reviewed-by: David Hildenbrand 
---
 mm/hugetlb.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index f24acb3af741..3569e731e66b 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3754,17 +3754,17 @@ bool is_hugetlb_entry_migration(pte_t pte)
return false;
 }
 
-static int is_hugetlb_entry_hwpoisoned(pte_t pte)
+static bool is_hugetlb_entry_hwpoisoned(pte_t pte)
 {
swp_entry_t swp;
 
if (huge_pte_none(pte) || pte_present(pte))
-   return 0;
+   return false;
swp = pte_to_swp_entry(pte);
if (non_swap_entry(swp) && is_hwpoison_entry(swp))
-   return 1;
+   return true;
else
-   return 0;
+   return false;
 }
 
 int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src,
-- 
2.17.2

Re: [PATCH v5 2/9] scsi: ufs: Fix imbalanced scsi_block_reqs_cnt caused by ufshcd_hold()

[hongwus]

Hi Can,
On 2020-07-23 10:34, Can Guo wrote:

The scsi_block_reqs_cnt increased in ufshcd_hold() is supposed to be
decreased back in ufshcd_ungate_work() in a paired way. However, if
specific ufshcd_hold/release sequences are met, it is possible that
scsi_block_reqs_cnt is increased twice but only one ungate work is
queued. To make sure scsi_block_reqs_cnt is handled by ufshcd_hold() 
and

ufshcd_ungate_work() in a paired way, increase it only if queue_work()
returns true.

Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/ufshcd.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 99bd3e4..2907828 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1611,12 +1611,12 @@ int ufshcd_hold(struct ufs_hba *hba, bool 
async)

 */
/* fallthrough */
case CLKS_OFF:
-   ufshcd_scsi_block_requests(hba);
hba->clk_gating.state = REQ_CLKS_ON;
trace_ufshcd_clk_gating(dev_name(hba->dev),
hba->clk_gating.state);
-   queue_work(hba->clk_gating.clk_gating_workq,
-  >clk_gating.ungate_work);
+   if (queue_work(hba->clk_gating.clk_gating_workq,
+  >clk_gating.ungate_work))
+   ufshcd_scsi_block_requests(hba);
/*
 * fall through to check if we should wait for this
 * work to be done or not.


Yes, queue_work() may fail for some reasons. We should make sure 
scsi_block_reqs_cnt is balanced. Your change looks good to me since it 
touches scsi_block_reqs_cnt only when the condition is met.


Reviewed-by: Hongwu Su 

[PATCH -next] io_uring: Remove redundant NULL check

[Li Heng]

Fix below warnings reported by coccicheck:
./fs/io_uring.c:1544:2-7: WARNING: NULL check before some freeing functions is 
not needed.
./fs/io_uring.c:3095:2-7: WARNING: NULL check before some freeing functions is 
not needed.
./fs/io_uring.c:3195:2-7: WARNING: NULL check before some freeing functions is 
not needed.

Signed-off-by: Li Heng 
---
 fs/io_uring.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/fs/io_uring.c b/fs/io_uring.c
index 6587935..71ac3f7 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -1540,8 +1540,7 @@ static void io_dismantle_req(struct io_kiocb *req)
 {
io_clean_op(req);
 
-   if (req->io)
-   kfree(req->io);
+   kfree(req->io);
if (req->file)
io_put_file(req, req->file, (req->flags & REQ_F_FIXED_FILE));
io_req_clean_work(req);
@@ -3091,8 +3090,7 @@ static int io_read(struct io_kiocb *req, bool 
force_nonblock,
}
}
 out_free:
-   if (iovec)
-   kfree(iovec);
+   kfree(iovec);
return ret;
 }
 
@@ -3191,8 +3189,7 @@ static int io_write(struct io_kiocb *req, bool 
force_nonblock,
}
}
 out_free:
-   if (iovec)
-   kfree(iovec);
+   kfree(iovec);
return ret;
 }
 
-- 
2.7.4

Re: [PATCH] jffs2: move jffs2_init_inode_info() just after allocating inode

[Jubin Zhong]

On 2020/1/6 16:04, zhangyi (F) wrote:
> After commit 4fdcfab5b553 ("jffs2: fix use-after-free on symlink
> traversal"), it expose a freeing uninitialized memory problem due to
> this commit move the operaion of freeing f->target to
> jffs2_i_callback(), which may not be initialized in some error path of
> allocating jffs2 inode (eg: jffs2_iget()->iget_locked()->
> destroy_inode()->..->jffs2_i_callback()->kfree(f->target)).
> 
> Fix this by initialize the jffs2_inode_info just after allocating it.

We are having the same problem. After commit 4fdcfab5b553 ("jffs2: fix 
use-after-free on symlink
> traversal"), f->target is freed before it is initialized in the iget_locked() 
> path. This is dangerous and may trigger slub BUG_ON:

kernel BUG at mm/slub.c:3824!
Internal error: Oops - BUG: 0 [#1] SMP ARM
CPU: 2 PID: 9 Comm: rcuos/0 Tainted: P   O4.4.185 #1
task: cf4a3f68 task.stack: cf4ca000
PC is at kfree+0xfc/0x264
LR is at jffs2_i_callback+0x10/0x28 [jffs2]
pc : []lr : []psr: 400e0213
sp : cf4cbec8  ip :   fp : c0273df8
r10: ceb12848  r9 : 000c  r8 : cdd52000
r7 : bf0ab188  r6 : 000c  r5 : e7fddef0  r4 : c1121ba0
r3 : 0100  r2 : c0ac4010  r1 : 0002  r0 : e7fddef0
Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 32c5387d  Table: 0e315940  DAC: 
Process rcuos/0 (pid: 9, stack limit = 0xcf4ca190)
Stack: (0xcf4cbec8 to 0xcf4cc000)
bec0:   c086efa8 c032a3a8 0001 c0273e9c c0a29214 c3931db8
bee0:  000c e000 cdd52000 000c ceb12848 c0273df8 bf0ab188
bf00: c0adf980 c0273e9c c0adf980 0001  ff7c  cf4a3f68
bf20: c025bc18 cf4cbf24 cf4cbf24 c0a22448 c0adf980 cf4ca000 cf485ac0 
bf40: c0adf980 c02739b0    c02380bc  c0adf380
bf60: c0adf980    8001 cf4cbf74 cf4cbf74 
bf80:   8001 cf4cbf8c cf4cbf8c c0a22448 cf485ac0 c0237fb8
bfa0:    c0202db4    
bfc0:        
bfe0:     0013   
[] (kfree) from [] (jffs2_i_callback+0x10/0x28 [jffs2])
[] (jffs2_i_callback [jffs2]) from [] 
(rcu_nocb_kthread+0x4ec/0x504)
[] (rcu_nocb_kthread) from [] (kthread+0x104/0x118)
[] (kthread) from [] (ret_from_fork+0x14/0x20)
Code: 031a 143094e5 010013e3 001a (f201f0e7)

答复: [PATCH] USB:Fix kernel NULL pointer when unbind UHCI form vfio-pci

[Weitao Wang(BJ-RD)]

On , Jul 22, 2020 at 02:44:14PM +0200, Alan wrote:
> On Wed, Jul 22, 2020 at 02:44:14PM +0200, Greg KH wrote:
> > On Wed, Jul 22, 2020 at 07:57:48PM +0800, WeitaoWangoc wrote:
> > > This bug is found in Zhaoxin platform, but it's a commom code bug.
> > > Fail sequence:
> > > step1: Unbind UHCI controller from native driver;
> > > step2: Bind UHCI controller to vfio-pci, which will put UHCI controller 
> > > in one
> vfio
> > >group's device list and set UHCI's dev->driver_data to struct
> vfio-pci(for UHCI)
> >
> > Hah, that works?  How do you do that properly?  What code does that?
>
> Yeah, that can't possibly work.  The USB core expects that any host
> controller device (or at least, any PCI host controller device) has its
> driver_data set to point to a struct usb_hcd.  It doesn't expect a host
> controller to be bound to anything other than a host controller driver.
>
> Things could easily go very wrong here.  For example, suppose at this
> point the ehci-hcd driver just happens to bind to the EHCI controller.
> When this happens, the EHCI controller hardware takes over all the USB
> connections that were routed to the UHCI controller.  How will vfio-pci
> deal with that?  Pretty ungracefully, I imagine.
>
> The only way to make this work at all is to unbind both uhci-hcd and
> ehci-hcd first.  Then after both are finished you can safely bind
> vfio-pci to the EHCI controller and the UHCI controllers (in that
> order).
>
I'm agree with you, unbind both uhci-hcd and ehci-hcd first then bind to
vfio-pci is a more reasonable sequence. Our experiments prove that this
sequence is indeed good as expected.
However, I did not find a formal document to prescribe this order.
Unfortunately, some application software such as virt-manager/qemu assign
UHCI/EHCI to guest OS has the same bind/unbind sequence as test “by hand”.
Do we need to consider compatibility with this application scenario?

The following log is captured when starting then shutdown the
virtual machine.

/* starting virtual machine*/
[ 2785.250001] audit: type=1400 audit(1594375837.191:48): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="libvirt-fa674e73-67a2-4672-8524-e62dea8a3c6c" pid=2008 
comm="apparmor_parser"
[ 2785.467510] uhci_hcd :00:10.0: remove, state 4
[ 2785.472426] usb usb1: USB disconnect, device number 1
/*bind :00:10.0 to vfio-pci*/
[ 2785.478798] uhci_hcd :00:10.0: USB bus 1 deregistered
[ 2785.568741] uhci_hcd :00:10.1: remove, state 1
[ 2785.573562] usb usb2: USB disconnect, device number 1
[ 2785.578793] usb 2-2: USB disconnect, device number 3
[ 2785.758016] uhci_hcd :00:10.1: USB bus 2 deregistered
/*bind :00:10.1 to vfio-pci*/
[ 2786.037448] ehci-pci :00:10.7: remove, state 4
[ 2786.042460] usb usb3: USB disconnect, device number 1
[ 2786.048700] ehci-pci :00:10.7: USB bus 3 deregistered
/*bind :00:10.7 to vfio-pci*/
[ 2787.518041] audit: type=1400 audit(1594375839.459:49): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" 
name="libvirt-fa674e73-67a2-4672-8524-e62dea8a3c6c" pid=2034 
comm="apparmor_parser"
[ 2788.290706] audit: type=1400 audit(1594375840.231:50): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" 
name="libvirt-fa674e73-67a2-4672-8524-e62dea8a3c6c" pid=2037 
comm="apparmor_parser"
[ 2788.960070] audit: type=1400 audit(1594375840.899:51): apparmor="STATUS" 
operation="profile_replace" info="same as current profile, skipping" 
profile="unconfined" name="libvirt-fa674e73-67a2-4672-8524-e62dea8a3c6c" 
pid=2040 comm="apparmor_parser"
[ 2788.968821] virbr0: port 2(vnet0) entered blocking state
[ 2788.988159] virbr0: port 2(vnet0) entered disabled state
[ 2788.993711] device vnet0 entered promiscuous mode
[ 2788.999453] virbr0: port 2(vnet0) entered blocking state
[ 2789.005053] virbr0: port 2(vnet0) entered listening state
[ 2789.098717] systemd-journald[286]: Successfully sent stream file descriptor 
to service manager.
[ 2789.564241] audit: type=1400 audit(1594375841.507:52): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" 
name="libvirt-fa674e73-67a2-4672-8524-e62dea8a3c6c" pid=2065 
comm="apparmor_parser"
[ 2791.028028] virbr0: port 2(vnet0) entered learning state
[ 2793.047999] virbr0: port 2(vnet0) entered forwarding state
[ 2793.053449] virbr0: topology change detected, propagating
[ 2793.433604] vfio_cap_init: :00:10.7 hiding cap 0xa

/* shutdown virtual machine*/
[ 3838.772058] systemd-journald[286]: Successfully sent stream file descriptor 
to service manager.
[ 3838.815819] systemd-journald[286]: Successfully sent stream file descriptor 
to service manager.
[ 3838.871002] systemd-journald[286]: Successfully sent stream file descriptor 
to service manager.
[ 3838.884606] systemd-journald[286]: Successfully sent stream file descriptor 
to service manager.
[ 3838.894514] systemd-journald[286]: Successfully sent stream file descriptor 
to service manager.
[ 3838.896791] rfkill: 

答复: [PATCH] USB:Fix kernel NULL pointer when unbind UHCI form vfio-pci

[Weitao Wang(BJ-RD)]

　　
On Wed, Jul 22, 2020 at 02:44:14PM +0200, Greg KH wrote:
> On Wed, Jul 22, 2020 at 07:57:48PM +0800, WeitaoWangoc wrote:
> > This bug is found in Zhaoxin platform, but it's a commom code bug.
> > Fail sequence:
> > step1: Unbind UHCI controller from native driver;
> > step2: Bind UHCI controller to vfio-pci, which will put UHCI controller in 
> > one
> vfio
> >group's device list and set UHCI's dev->driver_data to struct
> vfio-pci(for UHCI)
>
> Hah, that works?  How do you do that properly?  What code does that?

Drivers/vfio/vfio.c
The function vfio_group_create_device will set UHCI dev->driver_data
to vfio-device struct.

> > step3: Unbind EHCI controller from native driver, will try to tell UHCI 
> > native
> driver
> >that "I'm removed by set companion_hcd->self.hs_companion to
> NULL. However,
> >companion_hcd get from UHCI's dev->driver_data that has modified
> by vfio-pci
> >already.So, the vfio-pci structure will be damaged!
>
> Because you are messing around with bind/unbind "by hand", which is
> never guaranteed to work properly.
>
> It's amazing any of that works at all...

If adjust the sequence of UHCI/EHCI unbind form native driver, that
can avoid Null Pointer dereference. Eg. Step3-->stet4-->step1-->step2.
Our experiments prove that this sequence is indeed good as expected.
However, some application software such as virt-manager/qemu assign
/EHCI to guest OS has the same bind/unbind sequence as test “by hand”.

> 4.19.65-2020051917-rainos #1
>
> 4.19 is a bit old, what about 5.7?

5.7.7 has the same issue.

> > +#define PCI_DEV_DRV_FLAG   2
>
> Why is the USB core allowed to touch a private PCI structure field?
>
> I do not think this is allowed.
>
> And why is this a USB host controller-specific issue, shouldn't this
> type of thing be fixed in the PCI core?

When ehci hcd_driver bind or unbind to ehci, it will touch/modify UHCI usb_hcd
that get from UHCI's dev->driver_data. However, UHCI maybe bind to a
another driver(vfio-pci) and it's driver_data will be rewritten. what we
should do is to prevent ehci_hcd to modify UHCI's dev->driver_data when UHCI
has already bound to vfio-pci.

Thanks
weitaowang



保密声明：
本邮件含有保密或专有信息，仅供指定收件人使用。严禁对本邮件或其内容做任何未经授权的查阅、使用、复制或转发。
CONFIDENTIAL NOTE:
This email contains confidential or legally privileged information and is for 
the sole use of its intended recipient. Any unauthorized review, use, copying 
or forwarding of this email or the content of this email is strictly prohibited.

[PATCH -next] um: Remove redundant NULL check

[Li Heng]

Fix below warnings reported by coccicheck:
./arch/um/drivers/vector_user.c:403:2-7: WARNING: NULL check before some 
freeing functions is not needed.

Fixes: bc8f8e4e6e7a ("um: Add a generic "fd" vector transport")
Signed-off-by: Li Heng 
---
 arch/um/drivers/vector_user.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/um/drivers/vector_user.c b/arch/um/drivers/vector_user.c
index c4a0f26..e836d49 100644
--- a/arch/um/drivers/vector_user.c
+++ b/arch/um/drivers/vector_user.c
@@ -399,8 +399,7 @@ static struct vector_fds *user_init_fd_fds(struct arglist 
*ifspec)
 fd_cleanup:
if (fd >= 0)
os_close_file(fd);
-   if (result != NULL)
-   kfree(result);
+   kfree(result);
return NULL;
 }
 
-- 
2.7.4

Re: [RFC 11/11] scsi: storvsc: Support PAGE_SIZE larger than 4K

[Boqun Feng]

On Thu, Jul 23, 2020 at 02:26:00AM +, Michael Kelley wrote:
> From: boqun.f...@gmail.com  Sent: Wednesday, July 22, 
> 2020 6:52 PM
> > 
> > On Thu, Jul 23, 2020 at 12:13:07AM +, Michael Kelley wrote:
> > > From: Boqun Feng  Sent: Monday, July 20, 2020 6:42 
> > > PM
> > > >
> > > > Hyper-V always use 4k page size (HV_HYP_PAGE_SIZE), so when
> > > > communicating with Hyper-V, a guest should always use HV_HYP_PAGE_SIZE
> > > > as the unit for page related data. For storvsc, the data is
> > > > vmbus_packet_mpb_array. And since in scsi_cmnd, sglist of pages (in unit
> > > > of PAGE_SIZE) is used, we need convert pages in the sglist of scsi_cmnd
> > > > into Hyper-V pages in vmbus_packet_mpb_array.
> > > >
> > > > This patch does the conversion by dividing pages in sglist into Hyper-V
> > > > pages, offset and indexes in vmbus_packet_mpb_array are recalculated
> > > > accordingly.
> > > >
> > > > Signed-off-by: Boqun Feng 
> > > > ---
> > > >  drivers/scsi/storvsc_drv.c | 27 +--
> > > >  1 file changed, 21 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> > > > index fb41636519ee..c54d25f279bc 100644
> > > > --- a/drivers/scsi/storvsc_drv.c
> > > > +++ b/drivers/scsi/storvsc_drv.c
> > > > @@ -1561,7 +1561,7 @@ static int storvsc_queuecommand(struct Scsi_Host 
> > > > *host,
> > struct
> > > > scsi_cmnd *scmnd)
> > > > struct hv_host_device *host_dev = shost_priv(host);
> > > > struct hv_device *dev = host_dev->dev;
> > > > struct storvsc_cmd_request *cmd_request = scsi_cmd_priv(scmnd);
> > > > -   int i;
> > > > +   int i, j, k;
> > > > struct scatterlist *sgl;
> > > > unsigned int sg_count = 0;
> > > > struct vmscsi_request *vm_srb;
> > > > @@ -1569,6 +1569,8 @@ static int storvsc_queuecommand(struct Scsi_Host 
> > > > *host,
> > struct
> > > > scsi_cmnd *scmnd)
> > > > struct vmbus_packet_mpb_array  *payload;
> > > > u32 payload_sz;
> > > > u32 length;
> > > > +   int subpage_idx = 0;
> > > > +   unsigned int hvpg_count = 0;
> > > >
> > > > if (vmstor_proto_version <= VMSTOR_PROTO_VERSION_WIN8) {
> > > > /*
> > > > @@ -1643,23 +1645,36 @@ static int storvsc_queuecommand(struct 
> > > > Scsi_Host *host,
> > struct
> > > > scsi_cmnd *scmnd)
> > > > payload_sz = sizeof(cmd_request->mpb);
> > > >
> > > > if (sg_count) {
> > > > -   if (sg_count > MAX_PAGE_BUFFER_COUNT) {
> > > > +   hvpg_count = sg_count * (PAGE_SIZE / HV_HYP_PAGE_SIZE);
> > >
> > > The above calculation doesn't take into account the offset in the
> > > first sglist or the overall length of the transfer, so the value of 
> > > hvpg_count
> > > could be quite a bit bigger than it needs to be.  For example, with a 64K
> > > page size and an 8 Kbyte transfer size that starts at offset 60K in the
> > > first page, hvpg_count will be 32 when it really only needs to be 2.
> > >
> > > The nested loops below that populate the pfn_array take the
> > > offset into account when starting, so that's good.  But it will 
> > > potentially
> > > leave allocated entries unused.  Furthermore, the nested loops could
> > > terminate early when enough Hyper-V size pages are mapped to PFNs
> > > based on the length of the transfer, even if all of the last guest size
> > > page has not been mapped to PFNs.  Like the offset at the beginning of
> > > first guest size page in the sglist, there's potentially an unused portion
> > > at the end of the last guest size page in the sglist.
> > >
> > 
> > Good point. I think we could calculate the exact hvpg_count as follow:
> > 
> > hvpg_count = 0;
> > cur_sgl = sgl;
> > 
> > for (i = 0; i < sg_count; i++) {
> > hvpg_count += HVPFN_UP(cur_sg->length)
> > cur_sgl = sg_next(cur_sgl);
> > }
> > 
> 
> The downside would be going around that loop a lot of times when
> the page size is 4K bytes and the I/O transfer size is something like
> 256K bytes.  I think this gives the right result in constant time:  the
> starting offset within a Hyper-V page, plus the transfer length,
> rounded up to a Hyper-V page size, and divided by the Hyper-V
> page size.
> 

Ok, then:

hvpg_offset = sgl->offset & ~HV_HYP_PAGE_MASK;
hvpg_count = HVPFN_UP(hv_offset + length);

?

Thanks!

Regards,
Boqun

> 
> > > > +   if (hvpg_count > MAX_PAGE_BUFFER_COUNT) {
> > > >
> > > > -   payload_sz = (sg_count * sizeof(u64) +
> > > > +   payload_sz = (hvpg_count * sizeof(u64) +
> > > >   sizeof(struct 
> > > > vmbus_packet_mpb_array));
> > > > payload = kzalloc(payload_sz, GFP_ATOMIC);
> > > > if (!payload)
> > > > return SCSI_MLQUEUE_DEVICE_BUSY;
> > > > }
> > > >
> > > > +

Re: [RESEND PATCH v13 00/11] Introduce support for guest CET feature

[Yang Weijiang]

On Wed, Jul 22, 2020 at 12:48:05PM -0700, Sean Christopherson wrote:
> On Thu, Jul 16, 2020 at 11:16:16AM +0800, Yang Weijiang wrote:
> > Control-flow Enforcement Technology (CET) provides protection against
> > Return/Jump-Oriented Programming (ROP/JOP) attack. There're two CET
> > sub-features: Shadow Stack (SHSTK) and Indirect Branch Tracking (IBT).
> > SHSTK is to prevent ROP programming and IBT is to prevent JOP programming.
> > 
> > Several parts in KVM have been updated to provide VM CET support, including:
> > CPUID/XSAVES config, MSR pass-through, user space MSR access interface, 
> > vmentry/vmexit config, nested VM etc. These patches have dependency on CET
> > kernel patches for xsaves support and CET definitions, e.g., MSR and related
> > feature flags.
> > 
> > CET kernel patches are here:
> > https://lkml.kernel.org/r/20200429220732.31602-1-yu-cheng...@intel.com
> > 
> > v13:
> > - Added CET definitions as a separate patch to facilitate KVM test.
> 
> What I actually want to do is pull in actual kernel patches themselves so
> that we can upstream KVM support without having to wait for the kernel to
> sort out the ABI, which seems like it's going to drag on.
That's an innovative idea and beyond my imagination, great!:-)
> 
> I was thinking that we'd only need the MSR/CR4/CPUID definitions, but forgot
> that KVM also needs XSAVES context switching, so it's not as simple as I was
> thinking.  It's still relatively simple, but it means there would be
> functional changes in the kernel.
> 
> I'll respond to the main SSP series to pose the question of taking the two
> small-ish kernel patches through the KVM tree.
> 
> >  arch/x86/include/asm/kvm_host.h  |   4 +-
> >  arch/x86/include/asm/vmx.h   |   8 +
> >  arch/x86/include/uapi/asm/kvm.h  |   1 +
> >  arch/x86/include/uapi/asm/kvm_para.h |   7 +-
> >  arch/x86/kvm/cpuid.c |  28 ++-
> >  arch/x86/kvm/vmx/capabilities.h  |   5 +
> >  arch/x86/kvm/vmx/nested.c|  34 
> >  arch/x86/kvm/vmx/vmcs12.c| 267 ---
> >  arch/x86/kvm/vmx/vmcs12.h|  14 +-
> >  arch/x86/kvm/vmx/vmx.c   | 262 +-
> >  arch/x86/kvm/x86.c   |  53 +-
> >  arch/x86/kvm/x86.h   |   2 +-
> >  include/linux/kvm_host.h |  32 
> >  13 files changed, 590 insertions(+), 127 deletions(-)
> 
> I have quite a few comments/changes (will respond to individual patches),
> but have done all the updates/rework and, assuming I haven't broken things,
> we're nearing the point where I can carry this and push it past the finish
> line, e.g. get acks from tip/x86 maintainers for the kernel patches and
> send a pull request to Paolo.
> 
> I pushed the result to:
> 
>   https://github.com/sean-jc/linux/releases/tag/kvm-cet-v14-rc1
> 
> can you please review and test?  If everything looks good, I'll post v14.
> If not, I'll work offline with you to get it into shape.
>
Thanks a lot for the efforts! I'll review and test the new patches and
let you know the status.

> Thanks!

[PATCH v10 00/28] Add support for mt2701 JPEG ENC support

[Xia Jiang]

This patchset add support for mt2701 JPEG ENC support.  

This is the compliance test result for jpeg dec and enc.

The JPEG dec log:   

v4l2-compliance -d /dev/video0
v4l2-compliance SHA: 697ae940b60a172ef31948dd74316fe9de365b7e, 32 bits, 32-bit 
time_t

Compliance test for mtk-jpeg-dec device /dev/video0:

Driver Info:
Driver name  : mtk-jpeg-dec
Card type: mtk-jpeg-dec
Bus info : platform:15004000.jpegdec
Driver version   : 5.8.0
Capabilities : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps  : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Detected JPEG Decoder

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second /dev/video0 open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

test invalid ioctls: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 0 Private Controls: 0

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK
test Scaling: OK (Not Supported)

Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK
test Requests: OK (Not Supported)

Total for mtk-jpeg-dec device /dev/video0: 45, Succeeded: 45, Failed: 0, 
Warnings: 0


The JPEG enc log:   


v4l2-compliance -d /dev/video1 
v4l2-compliance SHA: 697ae940b60a172ef31948dd74316fe9de365b7e, 32 bits, 32-bit 
time_t

Compliance test for mtk-jpeg-enc device /dev/video1:

Driver Info:
Driver name  : mtk-jpeg-enc
Card type: mtk-jpeg-enc
Bus info : platform:1500a000.jpegenc
Driver version   : 5.8.0
Capabilities : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps  : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Detected JPEG Encoder

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second /dev/video1 open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

test invalid ioctls: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
 

[PATCH v10 03/28] media: platform: Improve getting and requesting irq flow for bug fixing

[Xia Jiang]

Delete platform_get_resource operation for irq.
Return actual value rather than EINVAL when fail to get and request
irq.

Reviewed-by: Tomasz Figa 
Signed-off-by: Xia Jiang 
---
v10: no changes
---
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 67a022d04df7..2677580941b0 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -1103,12 +1103,10 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
return ret;
}
 
-   res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
dec_irq = platform_get_irq(pdev, 0);
-   if (!res || dec_irq < 0) {
+   if (dec_irq < 0) {
dev_err(>dev, "Failed to get dec_irq %d.\n", dec_irq);
-   ret = -EINVAL;
-   return ret;
+   return dec_irq;
}
 
ret = devm_request_irq(>dev, dec_irq, mtk_jpeg_dec_irq, 0,
@@ -1116,7 +1114,6 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
if (ret) {
dev_err(>dev, "Failed to request dec_irq %d (%d)\n",
dec_irq, ret);
-   ret = -EINVAL;
goto err_req_irq;
}
 
-- 
2.18.0

Re: [PATCH v3] cxgb4: add missing release on skb in uld_send()

[David Miller]

From: Navid Emamdoost 
Date: Wed, 22 Jul 2020 21:58:39 -0500

> In the implementation of uld_send(), the skb is consumed on all
> execution paths except one. Release skb when returning NET_XMIT_DROP.
> 
> Signed-off-by: Navid Emamdoost 

Applied, thank you.

[PATCH v10 13/28] media: platform: Change MTK_JPEG_COMP_MAX macro definition location

[Xia Jiang]

Move MTK_JPEG_COMP_MAX definition to mtk_jpeg_core.h file, because it
is used by mtk_jpeg_core.c file.

Reviewed-by: Tomasz Figa 
Signed-off-by: Xia Jiang 
---
v10: no changes
---
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h | 2 ++
 drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h  | 1 -
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
index c9f5162d2924..4d62438963c0 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
@@ -15,6 +15,8 @@
 
 #define MTK_JPEG_NAME  "mtk-jpeg"
 
+#define MTK_JPEG_COMP_MAX  3
+
 #define MTK_JPEG_FMT_FLAG_DEC_OUTPUT   BIT(0)
 #define MTK_JPEG_FMT_FLAG_DEC_CAPTURE  BIT(1)
 
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
index 2945da842dfa..21ec8f96797f 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
@@ -8,7 +8,6 @@
 #ifndef _MTK_JPEG_REG_H
 #define _MTK_JPEG_REG_H
 
-#define MTK_JPEG_COMP_MAX  3
 #define MTK_JPEG_BLOCK_MAX 10
 #define MTK_JPEG_DCTSIZE   8
 
-- 
2.18.0

[PATCH v10 11/28] media: platform: Stylistic changes for improving code quality

[Xia Jiang]

Change register offset hex numerals from uppercase to lowercase.
Change data type of max/min width/height from integer to unsigned
integer.

Reviewed-by: Tomasz Figa 
Signed-off-by: Xia Jiang 
---
v10: no changes
---
 .../media/platform/mtk-jpeg/mtk_jpeg_core.h|  8 
 drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h | 18 +-
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
index 320c4f8a014a..c9f5162d2924 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
@@ -21,10 +21,10 @@
 #define MTK_JPEG_FMT_TYPE_OUTPUT   1
 #define MTK_JPEG_FMT_TYPE_CAPTURE  2
 
-#define MTK_JPEG_MIN_WIDTH 32
-#define MTK_JPEG_MIN_HEIGHT32
-#define MTK_JPEG_MAX_WIDTH 8192
-#define MTK_JPEG_MAX_HEIGHT8192
+#define MTK_JPEG_MIN_WIDTH 32U
+#define MTK_JPEG_MIN_HEIGHT32U
+#define MTK_JPEG_MAX_WIDTH 8192U
+#define MTK_JPEG_MAX_HEIGHT8192U
 
 #define MTK_JPEG_DEFAULT_SIZEIMAGE (1 * 1024 * 1024)
 
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
index 94db04e9cdb6..2945da842dfa 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
@@ -20,29 +20,29 @@
 #define BIT_INQST_MASK_ALLIRQ  0x37
 
 #define JPGDEC_REG_RESET   0x0090
-#define JPGDEC_REG_BRZ_FACTOR  0x00F8
-#define JPGDEC_REG_DU_NUM  0x00FC
+#define JPGDEC_REG_BRZ_FACTOR  0x00f8
+#define JPGDEC_REG_DU_NUM  0x00fc
 #define JPGDEC_REG_DEST_ADDR0_Y0x0140
 #define JPGDEC_REG_DEST_ADDR0_U0x0144
 #define JPGDEC_REG_DEST_ADDR0_V0x0148
-#define JPGDEC_REG_DEST_ADDR1_Y0x014C
+#define JPGDEC_REG_DEST_ADDR1_Y0x014c
 #define JPGDEC_REG_DEST_ADDR1_U0x0150
 #define JPGDEC_REG_DEST_ADDR1_V0x0154
 #define JPGDEC_REG_STRIDE_Y0x0158
-#define JPGDEC_REG_STRIDE_UV   0x015C
+#define JPGDEC_REG_STRIDE_UV   0x015c
 #define JPGDEC_REG_IMG_STRIDE_Y0x0160
 #define JPGDEC_REG_IMG_STRIDE_UV   0x0164
-#define JPGDEC_REG_WDMA_CTRL   0x016C
+#define JPGDEC_REG_WDMA_CTRL   0x016c
 #define JPGDEC_REG_PAUSE_MCU_NUM   0x0170
-#define JPGDEC_REG_OPERATION_MODE  0x017C
+#define JPGDEC_REG_OPERATION_MODE  0x017c
 #define JPGDEC_REG_FILE_ADDR   0x0200
-#define JPGDEC_REG_COMP_ID 0x020C
+#define JPGDEC_REG_COMP_ID 0x020c
 #define JPGDEC_REG_TOTAL_MCU_NUM   0x0210
 #define JPGDEC_REG_COMP0_DATA_UNIT_NUM 0x0224
-#define JPGDEC_REG_DU_CTRL 0x023C
+#define JPGDEC_REG_DU_CTRL 0x023c
 #define JPGDEC_REG_TRIG0x0240
 #define JPGDEC_REG_FILE_BRP0x0248
-#define JPGDEC_REG_FILE_TOTAL_SIZE 0x024C
+#define JPGDEC_REG_FILE_TOTAL_SIZE 0x024c
 #define JPGDEC_REG_QT_ID   0x0270
 #define JPGDEC_REG_INTERRUPT_STATUS0x0274
 #define JPGDEC_REG_STATUS  0x0278
-- 
2.18.0

[PATCH v10 05/28] media: platform: Improve power on and power off flow

[Xia Jiang]

Call pm_runtime_get_sync() before starting a frame and then
pm_runtime_put() after completing it. This can save power for the time
between processing two frames.

Reviewed-by: Tomasz Figa 
Signed-off-by: Xia Jiang 
---
v10: no changes
---
 .../media/platform/mtk-jpeg/mtk_jpeg_core.c   | 27 +--
 1 file changed, 6 insertions(+), 21 deletions(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 12609ca46fd9..fb624385969e 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -710,23 +710,6 @@ static struct vb2_v4l2_buffer *mtk_jpeg_buf_remove(struct 
mtk_jpeg_ctx *ctx,
return v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
 }
 
-static int mtk_jpeg_start_streaming(struct vb2_queue *q, unsigned int count)
-{
-   struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(q);
-   struct vb2_v4l2_buffer *vb;
-   int ret = 0;
-
-   ret = pm_runtime_get_sync(ctx->jpeg->dev);
-   if (ret < 0)
-   goto err;
-
-   return 0;
-err:
-   while ((vb = mtk_jpeg_buf_remove(ctx, q->type)))
-   v4l2_m2m_buf_done(vb, VB2_BUF_STATE_QUEUED);
-   return ret;
-}
-
 static void mtk_jpeg_stop_streaming(struct vb2_queue *q)
 {
struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(q);
@@ -751,8 +734,6 @@ static void mtk_jpeg_stop_streaming(struct vb2_queue *q)
 
while ((vb = mtk_jpeg_buf_remove(ctx, q->type)))
v4l2_m2m_buf_done(vb, VB2_BUF_STATE_ERROR);
-
-   pm_runtime_put_sync(ctx->jpeg->dev);
 }
 
 static const struct vb2_ops mtk_jpeg_qops = {
@@ -761,7 +742,6 @@ static const struct vb2_ops mtk_jpeg_qops = {
.buf_queue  = mtk_jpeg_buf_queue,
.wait_prepare   = vb2_ops_wait_prepare,
.wait_finish= vb2_ops_wait_finish,
-   .start_streaming= mtk_jpeg_start_streaming,
.stop_streaming = mtk_jpeg_stop_streaming,
 };
 
@@ -812,7 +792,7 @@ static void mtk_jpeg_device_run(void *priv)
struct mtk_jpeg_src_buf *jpeg_src_buf;
struct mtk_jpeg_bs bs;
struct mtk_jpeg_fb fb;
-   int i;
+   int i, ret;
 
src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
@@ -832,6 +812,10 @@ static void mtk_jpeg_device_run(void *priv)
return;
}
 
+   ret = pm_runtime_get_sync(jpeg->dev);
+   if (ret < 0)
+   goto dec_end;
+
mtk_jpeg_set_dec_src(ctx, _buf->vb2_buf, );
if (mtk_jpeg_set_dec_dst(ctx, _src_buf->dec_param, 
_buf->vb2_buf, ))
goto dec_end;
@@ -957,6 +941,7 @@ static irqreturn_t mtk_jpeg_dec_irq(int irq, void *priv)
v4l2_m2m_buf_done(src_buf, buf_state);
v4l2_m2m_buf_done(dst_buf, buf_state);
v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
+   pm_runtime_put(ctx->jpeg->dev);
return IRQ_HANDLED;
 }
 
-- 
2.18.0

[PATCH v10 15/28] media: platform: Delete vidioc_s_selection ioctl of jpeg dec

[Xia Jiang]

JPEG dec does't support setting a compose rectangle, so remove
mtk_jpeg_dec_s_selection().

Signed-off-by: Xia Jiang 
---
v10: new add patch
---
 .../media/platform/mtk-jpeg/mtk_jpeg_core.c   | 22 ---
 1 file changed, 22 deletions(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index db3a8b22dccd..9d1935d0782b 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -439,27 +439,6 @@ static int mtk_jpeg_g_selection(struct file *file, void 
*priv,
return 0;
 }
 
-static int mtk_jpeg_s_selection(struct file *file, void *priv,
-   struct v4l2_selection *s)
-{
-   struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
-
-   if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
-   return -EINVAL;
-
-   switch (s->target) {
-   case V4L2_SEL_TGT_COMPOSE:
-   s->r.left = 0;
-   s->r.top = 0;
-   s->r.width = ctx->out_q.w;
-   s->r.height = ctx->out_q.h;
-   break;
-   default:
-   return -EINVAL;
-   }
-   return 0;
-}
-
 static const struct v4l2_ioctl_ops mtk_jpeg_ioctl_ops = {
.vidioc_querycap= mtk_jpeg_querycap,
.vidioc_enum_fmt_vid_cap= mtk_jpeg_enum_fmt_vid_cap,
@@ -473,7 +452,6 @@ static const struct v4l2_ioctl_ops mtk_jpeg_ioctl_ops = {
.vidioc_qbuf= v4l2_m2m_ioctl_qbuf,
.vidioc_subscribe_event = mtk_jpeg_subscribe_event,
.vidioc_g_selection = mtk_jpeg_g_selection,
-   .vidioc_s_selection = mtk_jpeg_s_selection,
 
.vidioc_create_bufs = v4l2_m2m_ioctl_create_bufs,
.vidioc_prepare_buf = v4l2_m2m_ioctl_prepare_buf,
-- 
2.18.0

[PATCH v10 20/28] media: platform: Change the colorspace of jpeg to the fixed value

[Xia Jiang]

Jpeg doesn't support colorspace conversion, so it shouldn't accept any
other colorspace in S_FMT.
Change the colorspace of jpeg to the fixed value.

Signed-off-by: Xia Jiang 
---
v10: new add patch
---
 .../media/platform/mtk-jpeg/mtk_jpeg_core.c   | 24 +--
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 01f4656fe2b3..0376bd3bdbbb 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -320,10 +320,10 @@ static int mtk_jpeg_s_fmt_mplane(struct mtk_jpeg_ctx *ctx,
   pix_mp->pixelformat, fmt_type);
q_data->pix_mp.width = pix_mp->width;
q_data->pix_mp.height = pix_mp->height;
-   q_data->pix_mp.colorspace = pix_mp->colorspace;
-   q_data->pix_mp.ycbcr_enc = pix_mp->ycbcr_enc;
-   q_data->pix_mp.xfer_func = pix_mp->xfer_func;
-   q_data->pix_mp.quantization = pix_mp->quantization;
+   q_data->pix_mp.colorspace = V4L2_COLORSPACE_SRGB;
+   q_data->pix_mp.ycbcr_enc = V4L2_YCBCR_ENC_601;
+   q_data->pix_mp.xfer_func = V4L2_XFER_FUNC_SRGB;
+   q_data->pix_mp.quantization = V4L2_QUANTIZATION_FULL_RANGE;
 
v4l2_dbg(1, debug, >v4l2_dev, "(%d) s_fmt:%c%c%c%c wxh:%ux%u\n",
 f->type,
@@ -846,10 +846,10 @@ static void mtk_jpeg_set_default_params(struct 
mtk_jpeg_ctx *ctx)
struct mtk_jpeg_q_data *q = >out_q;
int i;
 
-   q->pix_mp.colorspace = V4L2_COLORSPACE_JPEG,
-   q->pix_mp.ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;
-   q->pix_mp.quantization = V4L2_QUANTIZATION_DEFAULT;
-   q->pix_mp.xfer_func = V4L2_XFER_FUNC_DEFAULT;
+   q->pix_mp.colorspace = V4L2_COLORSPACE_SRGB;
+   q->pix_mp.ycbcr_enc = V4L2_YCBCR_ENC_601;
+   q->pix_mp.quantization = V4L2_QUANTIZATION_FULL_RANGE;
+   q->pix_mp.xfer_func = V4L2_XFER_FUNC_SRGB;
 
q->fmt = mtk_jpeg_find_format(mtk_jpeg_formats, MTK_JPEG_NUM_FORMATS,
  V4L2_PIX_FMT_JPEG,
@@ -863,10 +863,10 @@ static void mtk_jpeg_set_default_params(struct 
mtk_jpeg_ctx *ctx)
q->fmt = mtk_jpeg_find_format(mtk_jpeg_formats, MTK_JPEG_NUM_FORMATS,
  V4L2_PIX_FMT_YUV420M,
  MTK_JPEG_FMT_FLAG_DEC_CAPTURE);
-   q->pix_mp.colorspace = V4L2_COLORSPACE_JPEG,
-   q->pix_mp.ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;
-   q->pix_mp.quantization = V4L2_QUANTIZATION_DEFAULT;
-   q->pix_mp.xfer_func = V4L2_XFER_FUNC_DEFAULT;
+   q->pix_mp.colorspace = V4L2_COLORSPACE_SRGB;
+   q->pix_mp.ycbcr_enc = V4L2_YCBCR_ENC_601;
+   q->pix_mp.quantization = V4L2_QUANTIZATION_FULL_RANGE;
+   q->pix_mp.xfer_func = V4L2_XFER_FUNC_SRGB;
q->pix_mp.width = MTK_JPEG_MIN_WIDTH;
q->pix_mp.height = MTK_JPEG_MIN_HEIGHT;
 
-- 
2.18.0

[PATCH v10 04/28] media: platform: Change the fixed device node number to unfixed value

[Xia Jiang]

The driver can be instantiated multiple times, e.g. for a decoder and
an encoder. Moreover, other drivers could coexist on the same system.
This makes the static video node number assignment pointless, so switch
to automatic assignment instead.

Reviewed-by: Tomasz Figa 
Signed-off-by: Xia Jiang 
---
v10: no changes
---
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 2677580941b0..12609ca46fd9 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -1154,7 +1154,7 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
jpeg->dec_vdev->device_caps = V4L2_CAP_STREAMING |
  V4L2_CAP_VIDEO_M2M_MPLANE;
 
-   ret = video_register_device(jpeg->dec_vdev, VFL_TYPE_VIDEO, 3);
+   ret = video_register_device(jpeg->dec_vdev, VFL_TYPE_VIDEO, -1);
if (ret) {
v4l2_err(>v4l2_dev, "Failed to register video device\n");
goto err_dec_vdev_register;
-- 
2.18.0

[PATCH v10 12/28] media: platform: Use generic rounding helpers

[Xia Jiang]

Use clamp() to replace mtk_jpeg_bound_align_image() and round() to
replace mtk_jpeg_align().

Reviewed-by: Tomasz Figa 
Signed-off-by: Xia Jiang 
---
v10: no changes
---
 .../media/platform/mtk-jpeg/mtk_jpeg_core.c   | 41 +--
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c |  8 ++--
 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h |  5 ---
 3 files changed, 15 insertions(+), 39 deletions(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 0153d57af466..980500be027b 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -151,25 +151,6 @@ static struct mtk_jpeg_fmt *mtk_jpeg_find_format(struct 
mtk_jpeg_ctx *ctx,
return NULL;
 }
 
-static void mtk_jpeg_bound_align_image(u32 *w, unsigned int wmin,
-  unsigned int wmax, unsigned int walign,
-  u32 *h, unsigned int hmin,
-  unsigned int hmax, unsigned int halign)
-{
-   int width, height, w_step, h_step;
-
-   width = *w;
-   height = *h;
-   w_step = 1 << walign;
-   h_step = 1 << halign;
-
-   v4l_bound_align_image(w, wmin, wmax, walign, h, hmin, hmax, halign, 0);
-   if (*w < width && (*w + w_step) <= wmax)
-   *w += w_step;
-   if (*h < height && (*h + h_step) <= hmax)
-   *h += h_step;
-}
-
 static void mtk_jpeg_adjust_fmt_mplane(struct mtk_jpeg_ctx *ctx,
   struct v4l2_format *f)
 {
@@ -211,24 +192,24 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
if (q_type == MTK_JPEG_FMT_TYPE_OUTPUT) {
struct v4l2_plane_pix_format *pfmt = _mp->plane_fmt[0];
 
-   mtk_jpeg_bound_align_image(_mp->width, MTK_JPEG_MIN_WIDTH,
-  MTK_JPEG_MAX_WIDTH, 0,
-  _mp->height, MTK_JPEG_MIN_HEIGHT,
-  MTK_JPEG_MAX_HEIGHT, 0);
+   pix_mp->height = clamp(pix_mp->height, MTK_JPEG_MIN_HEIGHT,
+  MTK_JPEG_MAX_HEIGHT);
+   pix_mp->width = clamp(pix_mp->width, MTK_JPEG_MIN_WIDTH,
+ MTK_JPEG_MAX_WIDTH);
 
pfmt->bytesperline = 0;
/* Source size must be aligned to 128 */
-   pfmt->sizeimage = mtk_jpeg_align(pfmt->sizeimage, 128);
+   pfmt->sizeimage = round_up(pfmt->sizeimage, 128);
if (pfmt->sizeimage == 0)
pfmt->sizeimage = MTK_JPEG_DEFAULT_SIZEIMAGE;
goto end;
}
 
/* type is MTK_JPEG_FMT_TYPE_CAPTURE */
-   mtk_jpeg_bound_align_image(_mp->width, MTK_JPEG_MIN_WIDTH,
-  MTK_JPEG_MAX_WIDTH, fmt->h_align,
-  _mp->height, MTK_JPEG_MIN_HEIGHT,
-  MTK_JPEG_MAX_HEIGHT, fmt->v_align);
+   pix_mp->height = clamp(round_up(pix_mp->height, fmt->v_align),
+  MTK_JPEG_MIN_HEIGHT, MTK_JPEG_MAX_HEIGHT);
+   pix_mp->width = clamp(round_up(pix_mp->width, fmt->h_align),
+ MTK_JPEG_MIN_WIDTH, MTK_JPEG_MAX_WIDTH);
 
for (i = 0; i < fmt->colplanes; i++) {
struct v4l2_plane_pix_format *pfmt = _mp->plane_fmt[i];
@@ -711,8 +692,8 @@ static void mtk_jpeg_set_dec_src(struct mtk_jpeg_ctx *ctx,
 {
bs->str_addr = vb2_dma_contig_plane_dma_addr(src_buf, 0);
bs->end_addr = bs->str_addr +
-mtk_jpeg_align(vb2_get_plane_payload(src_buf, 0), 16);
-   bs->size = mtk_jpeg_align(vb2_plane_size(src_buf, 0), 128);
+  round_up(vb2_get_plane_payload(src_buf, 0), 16);
+   bs->size = round_up(vb2_plane_size(src_buf, 0), 128);
 }
 
 static int mtk_jpeg_set_dec_dst(struct mtk_jpeg_ctx *ctx,
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
index ddf0dfa78e20..68abcfd7494d 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
@@ -153,10 +153,10 @@ static int mtk_jpeg_calc_dst_size(struct 
mtk_jpeg_dec_param *param)
param->sampling_w[i];
/* output format is 420/422 */
param->comp_w[i] = padding_w >> brz_w[i];
-   param->comp_w[i] = mtk_jpeg_align(param->comp_w[i],
- MTK_JPEG_DCTSIZE);
-   param->img_stride[i] = i ? mtk_jpeg_align(param->comp_w[i], 16)
-   : mtk_jpeg_align(param->comp_w[i], 32);
+   param->comp_w[i] = round_up(param->comp_w[i],
+   MTK_JPEG_DCTSIZE);
+   param->img_stride[i] = i ? 

[PATCH v10 14/28] media: platform: Delete redundant code and add annotation for an enum

[Xia Jiang]

Delete unused member variables annotation.
Delete unused variable definition.
Delete redundant log print, because V4L2 debug logs already print it.
Add annotation for enum mtk_jpeg_ctx_state.

Reviewed-by: Tomasz Figa 
Signed-off-by: Xia Jiang 
---
v10: no changes
---
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 15 ++-
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h |  8 ++--
 2 files changed, 8 insertions(+), 15 deletions(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 980500be027b..db3a8b22dccd 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -176,14 +176,13 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
   struct mtk_jpeg_ctx *ctx, int q_type)
 {
struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
-   struct mtk_jpeg_dev *jpeg = ctx->jpeg;
int i;
 
pix_mp->field = V4L2_FIELD_NONE;
 
if (ctx->state != MTK_JPEG_INIT) {
mtk_jpeg_adjust_fmt_mplane(ctx, f);
-   goto end;
+   return 0;
}
 
pix_mp->num_planes = fmt->colplanes;
@@ -202,7 +201,7 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
pfmt->sizeimage = round_up(pfmt->sizeimage, 128);
if (pfmt->sizeimage == 0)
pfmt->sizeimage = MTK_JPEG_DEFAULT_SIZEIMAGE;
-   goto end;
+   return 0;
}
 
/* type is MTK_JPEG_FMT_TYPE_CAPTURE */
@@ -219,16 +218,6 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
pfmt->bytesperline = stride;
pfmt->sizeimage = stride * h;
}
-end:
-   v4l2_dbg(2, debug, >v4l2_dev, "wxh:%ux%u\n",
-pix_mp->width, pix_mp->height);
-   for (i = 0; i < pix_mp->num_planes; i++) {
-   v4l2_dbg(2, debug, >v4l2_dev,
-"plane[%d] bpl=%u, size=%u\n",
-i,
-pix_mp->plane_fmt[i].bytesperline,
-pix_mp->plane_fmt[i].sizeimage);
-   }
return 0;
 }
 
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
index 4d62438963c0..9b46b0507187 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
@@ -32,6 +32,12 @@
 
 #define MTK_JPEG_HW_TIMEOUT_MSEC 1000
 
+/**
+ * enum mtk_jpeg_ctx_state - states of the context state machine
+ * @MTK_JPEG_INIT: current state is initialized
+ * @MTK_JPEG_RUNNING:  current state is running
+ * @MTK_JPEG_SOURCE_CHANGE:current state is source resolution change
+ */
 enum mtk_jpeg_ctx_state {
MTK_JPEG_INIT = 0,
MTK_JPEG_RUNNING,
@@ -113,9 +119,7 @@ struct mtk_jpeg_q_data {
  * @out_q: source (output) queue information
  * @cap_q: destination (capture) queue queue information
  * @fh:V4L2 file handle
- * @dec_param  parameters for HW decoding
  * @state: state of the context
- * @header_valid:  set if header has been parsed and valid
  * @colorspace: enum v4l2_colorspace; supplemental to pixelformat
  * @ycbcr_enc: enum v4l2_ycbcr_encoding, Y'CbCr encoding
  * @quantization: enum v4l2_quantization, colorspace quantization
-- 
2.18.0

[PATCH v10 23/28] media: dt-bindings: Add jpeg enc device tree node document

[Xia Jiang]

Add jpeg enc device tree node document.

Reviewed-by: Rob Herring 
Signed-off-by: Xia Jiang 
---
v10: no changes
---
 .../bindings/media/mediatek-jpeg-encoder.txt  | 35 +++
 1 file changed, 35 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt

diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt 
b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
new file mode 100644
index ..736be7cad385
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
@@ -0,0 +1,35 @@
+* MediaTek JPEG Encoder
+
+MediaTek JPEG Encoder is the JPEG encode hardware present in MediaTek SoCs
+
+Required properties:
+- compatible : "mediatek,mt2701-jpgenc"
+  followed by "mediatek,mtk-jpgenc"
+- reg : physical base address of the JPEG encoder registers and length of
+  memory mapped region.
+- interrupts : interrupt number to the interrupt controller.
+- clocks: device clocks, see
+  Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
+- clock-names: must contain "jpgenc". It is the clock of JPEG encoder.
+- power-domains: a phandle to the power domain, see
+  Documentation/devicetree/bindings/power/power_domain.txt for details.
+- mediatek,larb: must contain the local arbiters in the current SoCs, see
+  Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
+  for details.
+- iommus: should point to the respective IOMMU block with master port as
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  for details.
+
+Example:
+   jpegenc: jpegenc@1500a000 {
+   compatible = "mediatek,mt2701-jpgenc",
+"mediatek,mtk-jpgenc";
+   reg = <0 0x1500a000 0 0x1000>;
+   interrupts = ;
+   clocks =  < CLK_IMG_VENC>;
+   clock-names = "jpgenc";
+   power-domains = < MT2701_POWER_DOMAIN_ISP>;
+   mediatek,larb = <>;
+   iommus = < MT2701_M4U_PORT_JPGENC_RDMA>,
+< MT2701_M4U_PORT_JPGENC_BSDMA>;
+   };
-- 
2.18.0

[PATCH v10 10/28] media: platform: Delete zeroing the reserved fields

[Xia Jiang]

Delete zeroing the reserved fields because that the core already
does it.

Reviewed-by: Tomasz Figa 
Signed-off-by: Xia Jiang 
---
v10: no changes
---
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index ffb486e537b6..0153d57af466 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -198,7 +198,6 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
struct mtk_jpeg_dev *jpeg = ctx->jpeg;
int i;
 
-   memset(pix_mp->reserved, 0, sizeof(pix_mp->reserved));
pix_mp->field = V4L2_FIELD_NONE;
 
if (ctx->state != MTK_JPEG_INIT) {
@@ -217,7 +216,6 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
   _mp->height, MTK_JPEG_MIN_HEIGHT,
   MTK_JPEG_MAX_HEIGHT, 0);
 
-   memset(pfmt->reserved, 0, sizeof(pfmt->reserved));
pfmt->bytesperline = 0;
/* Source size must be aligned to 128 */
pfmt->sizeimage = mtk_jpeg_align(pfmt->sizeimage, 128);
@@ -237,7 +235,6 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
u32 stride = pix_mp->width * fmt->h_sample[i] / 4;
u32 h = pix_mp->height * fmt->v_sample[i] / 4;
 
-   memset(pfmt->reserved, 0, sizeof(pfmt->reserved));
pfmt->bytesperline = stride;
pfmt->sizeimage = stride * h;
}
@@ -270,7 +267,6 @@ static int mtk_jpeg_g_fmt_vid_mplane(struct file *file, 
void *priv,
 
q_data = mtk_jpeg_get_q_data(ctx, f->type);
 
-   memset(pix_mp->reserved, 0, sizeof(pix_mp->reserved));
pix_mp->width = q_data->w;
pix_mp->height = q_data->h;
pix_mp->field = V4L2_FIELD_NONE;
@@ -294,7 +290,6 @@ static int mtk_jpeg_g_fmt_vid_mplane(struct file *file, 
void *priv,
 
pfmt->bytesperline = q_data->bytesperline[i];
pfmt->sizeimage = q_data->sizeimage[i];
-   memset(pfmt->reserved, 0, sizeof(pfmt->reserved));
 
v4l2_dbg(1, debug, >v4l2_dev,
 "plane[%d] bpl=%u, size=%u\n",
-- 
2.18.0

[PATCH v10 21/28] media: platform: Refactor mtk_jpeg_set_default_params()

[Xia Jiang]

Call mtk_jpeg_try_fmt_mplane() to replace the original computation of
sizeimage and bytesperline, because that mtk_jpeg_try_fmt_mplane()
already did it.

Signed-off-by: Xia Jiang 
---
v10: new add patch
---
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 0376bd3bdbbb..7881e9c93df7 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -844,7 +844,6 @@ static irqreturn_t mtk_jpeg_dec_irq(int irq, void *priv)
 static void mtk_jpeg_set_default_params(struct mtk_jpeg_ctx *ctx)
 {
struct mtk_jpeg_q_data *q = >out_q;
-   int i;
 
q->pix_mp.colorspace = V4L2_COLORSPACE_SRGB;
q->pix_mp.ycbcr_enc = V4L2_YCBCR_ENC_601;
@@ -856,8 +855,7 @@ static void mtk_jpeg_set_default_params(struct mtk_jpeg_ctx 
*ctx)
  MTK_JPEG_FMT_FLAG_DEC_OUTPUT);
q->pix_mp.width = MTK_JPEG_MIN_WIDTH;
q->pix_mp.height = MTK_JPEG_MIN_HEIGHT;
-   q->pix_mp.plane_fmt[0].bytesperline = 0;
-   q->pix_mp.plane_fmt[0].sizeimage = MTK_JPEG_DEFAULT_SIZEIMAGE;
+   mtk_jpeg_try_fmt_mplane(>pix_mp, q->fmt);
 
q = >cap_q;
q->fmt = mtk_jpeg_find_format(mtk_jpeg_formats, MTK_JPEG_NUM_FORMATS,
@@ -870,13 +868,7 @@ static void mtk_jpeg_set_default_params(struct 
mtk_jpeg_ctx *ctx)
q->pix_mp.width = MTK_JPEG_MIN_WIDTH;
q->pix_mp.height = MTK_JPEG_MIN_HEIGHT;
 
-   for (i = 0; i < q->fmt->colplanes; i++) {
-   u32 stride = q->pix_mp.width * q->fmt->h_sample[i] / 4;
-   u32 h = q->pix_mp.height * q->fmt->v_sample[i] / 4;
-
-   q->pix_mp.plane_fmt[i].bytesperline = stride;
-   q->pix_mp.plane_fmt[i].sizeimage = stride * h;
-   }
+   mtk_jpeg_try_fmt_mplane(>pix_mp, q->fmt);
 }
 
 static int mtk_jpeg_open(struct file *file)
-- 
2.18.0

[PATCH v10 27/28] media: platform: Using the variant structure to contain the varability between dec and enc

[Xia Jiang]

Add varability which would be used between jpeg dec and enc to a match
data structure, it will make the code linear.

Signed-off-by: Xia Jiang 
---
v10: new add patch
---
 .../media/platform/mtk-jpeg/mtk_jpeg_core.c   | 100 +++---
 .../media/platform/mtk-jpeg/mtk_jpeg_core.h   |  28 +
 2 files changed, 92 insertions(+), 36 deletions(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index e245bcdb6f1a..1eebbe726d4f 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -80,8 +80,8 @@ static int mtk_jpeg_querycap(struct file *file, void *priv,
 {
struct mtk_jpeg_dev *jpeg = video_drvdata(file);
 
-   strscpy(cap->driver, MTK_JPEG_NAME " decoder", sizeof(cap->driver));
-   strscpy(cap->card, MTK_JPEG_NAME " decoder", sizeof(cap->card));
+   strscpy(cap->driver, jpeg->variant->dev_name, sizeof(cap->driver));
+   strscpy(cap->card, jpeg->variant->dev_name, sizeof(cap->card));
snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:%s",
 dev_name(jpeg->dev));
 
@@ -112,15 +112,23 @@ static int mtk_jpeg_enum_fmt(struct mtk_jpeg_fmt 
*mtk_jpeg_formats, int n,
 static int mtk_jpeg_enum_fmt_vid_cap(struct file *file, void *priv,
 struct v4l2_fmtdesc *f)
 {
-   return mtk_jpeg_enum_fmt(mtk_jpeg_dec_formats, MTK_JPEG_DEC_NUM_FORMATS,
-f, MTK_JPEG_FMT_FLAG_CAPTURE);
+   struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
+   struct mtk_jpeg_dev *jpeg = ctx->jpeg;
+
+   return mtk_jpeg_enum_fmt(jpeg->variant->formats,
+jpeg->variant->num_formats, f,
+MTK_JPEG_FMT_FLAG_CAPTURE);
 }
 
 static int mtk_jpeg_enum_fmt_vid_out(struct file *file, void *priv,
 struct v4l2_fmtdesc *f)
 {
-   return mtk_jpeg_enum_fmt(mtk_jpeg_dec_formats, MTK_JPEG_DEC_NUM_FORMATS,
-f, MTK_JPEG_FMT_FLAG_OUTPUT);
+   struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
+   struct mtk_jpeg_dev *jpeg = ctx->jpeg;
+
+   return mtk_jpeg_enum_fmt(jpeg->variant->formats,
+jpeg->variant->num_formats, f,
+MTK_JPEG_FMT_FLAG_OUTPUT);
 }
 
 static struct mtk_jpeg_q_data *mtk_jpeg_get_q_data(struct mtk_jpeg_ctx *ctx,
@@ -244,10 +252,11 @@ static int mtk_jpeg_try_fmt_vid_cap_mplane(struct file 
*file, void *priv,
   struct v4l2_format *f)
 {
struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
+   struct mtk_jpeg_dev *jpeg = ctx->jpeg;
struct mtk_jpeg_fmt *fmt;
 
-   fmt = mtk_jpeg_find_format(mtk_jpeg_dec_formats,
-  MTK_JPEG_DEC_NUM_FORMATS,
+   fmt = mtk_jpeg_find_format(jpeg->variant->formats,
+  jpeg->variant->num_formats,
   f->fmt.pix_mp.pixelformat,
   MTK_JPEG_FMT_FLAG_CAPTURE);
if (!fmt)
@@ -272,10 +281,11 @@ static int mtk_jpeg_try_fmt_vid_out_mplane(struct file 
*file, void *priv,
   struct v4l2_format *f)
 {
struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
+   struct mtk_jpeg_dev *jpeg = ctx->jpeg;
struct mtk_jpeg_fmt *fmt;
 
-   fmt = mtk_jpeg_find_format(mtk_jpeg_dec_formats,
-  MTK_JPEG_DEC_NUM_FORMATS,
+   fmt = mtk_jpeg_find_format(jpeg->variant->formats,
+  jpeg->variant->num_formats,
   f->fmt.pix_mp.pixelformat,
   MTK_JPEG_FMT_FLAG_OUTPUT);
if (!fmt)
@@ -316,9 +326,8 @@ static int mtk_jpeg_s_fmt_mplane(struct mtk_jpeg_ctx *ctx,
return -EBUSY;
}
 
-
-   q_data->fmt = mtk_jpeg_find_format(mtk_jpeg_dec_formats,
-  MTK_JPEG_DEC_NUM_FORMATS,
+   q_data->fmt = mtk_jpeg_find_format(jpeg->variant->formats,
+  jpeg->variant->num_formats,
   pix_mp->pixelformat, fmt_type);
q_data->pix_mp.width = pix_mp->width;
q_data->pix_mp.height = pix_mp->height;
@@ -519,9 +528,10 @@ static bool mtk_jpeg_check_resolution_change(struct 
mtk_jpeg_ctx *ctx,
}
 
q_data = >cap_q;
-   if (q_data->fmt != mtk_jpeg_find_format(mtk_jpeg_dec_formats,
-   MTK_JPEG_DEC_NUM_FORMATS, param->dst_fourcc,
-   MTK_JPEG_FMT_FLAG_CAPTURE)) {
+   if (q_data->fmt !=
+   mtk_jpeg_find_format(jpeg->variant->formats,
+jpeg->variant->num_formats, param->dst_fourcc,
+MTK_JPEG_FMT_FLAG_CAPTURE)) {
   

[PATCH v10 28/28] media: platform: Add jpeg enc feature

[Xia Jiang]

Add mtk jpeg encode v4l2 driver based on jpeg decode, because that jpeg
decode and encode have great similarities with function operation.

Signed-off-by: Xia Jiang 
---
v10: cancel mtk_jpeg_enc_bs structure.
 refactor the setting hardware register functions in mtk_jpeg_enc_hw.c.
 remove mtk_jpeg_enc_job_ready().
 refactor mtk_jpeg_enc_irq().
 cancel setting up a control handler for jpeg dec.
 add the mechanism to ensure that the buffer is enough to hold the
 EXIF data in .buf_prepare callback.
---
 drivers/media/platform/mtk-jpeg/Makefile  |   5 +-
 .../media/platform/mtk-jpeg/mtk_jpeg_core.c   | 345 +-
 .../media/platform/mtk-jpeg/mtk_jpeg_core.h   |  17 +
 .../media/platform/mtk-jpeg/mtk_jpeg_enc_hw.c | 154 
 .../media/platform/mtk-jpeg/mtk_jpeg_enc_hw.h |  91 +
 5 files changed, 608 insertions(+), 4 deletions(-)
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_enc_hw.c
 create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_enc_hw.h

diff --git a/drivers/media/platform/mtk-jpeg/Makefile 
b/drivers/media/platform/mtk-jpeg/Makefile
index 48516dcf96e6..76c33aad0f3f 100644
--- a/drivers/media/platform/mtk-jpeg/Makefile
+++ b/drivers/media/platform/mtk-jpeg/Makefile
@@ -1,3 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0-only
-mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_dec_hw.o mtk_jpeg_dec_parse.o
+mtk_jpeg-objs := mtk_jpeg_core.o \
+mtk_jpeg_dec_hw.o \
+mtk_jpeg_dec_parse.o \
+mtk_jpeg_enc_hw.o
 obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk_jpeg.o
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 1eebbe726d4f..4c8d4b48713a 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -3,6 +3,7 @@
  * Copyright (c) 2016 MediaTek Inc.
  * Author: Ming Hsiu Tsai 
  * Rick Chang 
+ * Xia Jiang 
  */
 
 #include 
@@ -23,10 +24,59 @@
 #include 
 #include 
 
+#include "mtk_jpeg_enc_hw.h"
 #include "mtk_jpeg_dec_hw.h"
 #include "mtk_jpeg_core.h"
 #include "mtk_jpeg_dec_parse.h"
 
+static struct mtk_jpeg_fmt mtk_jpeg_enc_formats[] = {
+   {
+   .fourcc = V4L2_PIX_FMT_JPEG,
+   .colplanes  = 1,
+   .flags  = MTK_JPEG_FMT_FLAG_CAPTURE,
+   },
+   {
+   .fourcc = V4L2_PIX_FMT_NV12M,
+   .hw_format  = JPEG_ENC_YUV_FORMAT_NV12,
+   .h_sample   = {4, 4},
+   .v_sample   = {4, 2},
+   .colplanes  = 2,
+   .h_align= 4,
+   .v_align= 4,
+   .flags  = MTK_JPEG_FMT_FLAG_OUTPUT,
+   },
+   {
+   .fourcc = V4L2_PIX_FMT_NV21M,
+   .hw_format  = JEPG_ENC_YUV_FORMAT_NV21,
+   .h_sample   = {4, 4},
+   .v_sample   = {4, 2},
+   .colplanes  = 2,
+   .h_align= 4,
+   .v_align= 4,
+   .flags  = MTK_JPEG_FMT_FLAG_OUTPUT,
+   },
+   {
+   .fourcc = V4L2_PIX_FMT_YUYV,
+   .hw_format  = JPEG_ENC_YUV_FORMAT_YUYV,
+   .h_sample   = {8},
+   .v_sample   = {4},
+   .colplanes  = 1,
+   .h_align= 5,
+   .v_align= 3,
+   .flags  = MTK_JPEG_FMT_FLAG_OUTPUT,
+   },
+   {
+   .fourcc = V4L2_PIX_FMT_YVYU,
+   .hw_format  = JPEG_ENC_YUV_FORMAT_YVYU,
+   .h_sample   = {8},
+   .v_sample   = {4},
+   .colplanes  = 1,
+   .h_align= 5,
+   .v_align= 3,
+   .flags  = MTK_JPEG_FMT_FLAG_OUTPUT,
+   },
+};
+
 static struct mtk_jpeg_fmt mtk_jpeg_dec_formats[] = {
{
.fourcc = V4L2_PIX_FMT_JPEG,
@@ -53,6 +103,7 @@ static struct mtk_jpeg_fmt mtk_jpeg_dec_formats[] = {
},
 };
 
+#define MTK_JPEG_ENC_NUM_FORMATS ARRAY_SIZE(mtk_jpeg_enc_formats)
 #define MTK_JPEG_DEC_NUM_FORMATS ARRAY_SIZE(mtk_jpeg_dec_formats)
 
 struct mtk_jpeg_src_buf {
@@ -64,6 +115,11 @@ struct mtk_jpeg_src_buf {
 static int debug;
 module_param(debug, int, 0644);
 
+static inline struct mtk_jpeg_ctx *ctrl_to_ctx(struct v4l2_ctrl *ctrl)
+{
+   return container_of(ctrl->handler, struct mtk_jpeg_ctx, ctrl_hdl);
+}
+
 static inline struct mtk_jpeg_ctx *mtk_jpeg_fh_to_ctx(struct v4l2_fh *fh)
 {
return container_of(fh, struct mtk_jpeg_ctx, fh);
@@ -88,6 +144,53 @@ static int mtk_jpeg_querycap(struct file *file, void *priv,
return 0;
 }
 
+static int vidioc_jpeg_enc_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+   struct mtk_jpeg_ctx *ctx = ctrl_to_ctx(ctrl);
+
+   switch (ctrl->id) {
+   case V4L2_CID_JPEG_RESTART_INTERVAL:
+  

[PATCH v10 17/28] media: platform: Refactor mtk_jpeg_try_fmt_mplane()

[Xia Jiang]

The function of mtk_jpeg_adjust_fmt_mplane() equals
mtk_jpeg_g_fmt_vid_mplane(), so use mtk_jpeg_g_fmt_vid_mplane() to
replace it .
Delete the unused ctx parameter.
Using fourcc to distinguish between different formats is more generic,
because that jpeg enc will also use it.

Signed-off-by: Xia Jiang 
---
v10: new add patch
---
 .../media/platform/mtk-jpeg/mtk_jpeg_core.c   | 49 ++-
 1 file changed, 16 insertions(+), 33 deletions(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 9d1935d0782b..aba583f03ef1 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -151,44 +151,17 @@ static struct mtk_jpeg_fmt *mtk_jpeg_find_format(struct 
mtk_jpeg_ctx *ctx,
return NULL;
 }
 
-static void mtk_jpeg_adjust_fmt_mplane(struct mtk_jpeg_ctx *ctx,
-  struct v4l2_format *f)
+static int mtk_jpeg_try_fmt_mplane(struct v4l2_pix_format_mplane *pix_mp,
+  struct mtk_jpeg_fmt *fmt)
 {
-   struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
-   struct mtk_jpeg_q_data *q_data;
-   int i;
-
-   q_data = mtk_jpeg_get_q_data(ctx, f->type);
-
-   pix_mp->width = q_data->w;
-   pix_mp->height = q_data->h;
-   pix_mp->pixelformat = q_data->fmt->fourcc;
-   pix_mp->num_planes = q_data->fmt->colplanes;
-
-   for (i = 0; i < pix_mp->num_planes; i++) {
-   pix_mp->plane_fmt[i].bytesperline = q_data->bytesperline[i];
-   pix_mp->plane_fmt[i].sizeimage = q_data->sizeimage[i];
-   }
-}
-
-static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
-  struct mtk_jpeg_fmt *fmt,
-  struct mtk_jpeg_ctx *ctx, int q_type)
-{
-   struct v4l2_pix_format_mplane *pix_mp = >fmt.pix_mp;
int i;
 
pix_mp->field = V4L2_FIELD_NONE;
 
-   if (ctx->state != MTK_JPEG_INIT) {
-   mtk_jpeg_adjust_fmt_mplane(ctx, f);
-   return 0;
-   }
-
pix_mp->num_planes = fmt->colplanes;
pix_mp->pixelformat = fmt->fourcc;
 
-   if (q_type == MTK_JPEG_FMT_TYPE_OUTPUT) {
+   if (fmt->fourcc == V4L2_PIX_FMT_JPEG) {
struct v4l2_plane_pix_format *pfmt = _mp->plane_fmt[0];
 
pix_mp->height = clamp(pix_mp->height, MTK_JPEG_MIN_HEIGHT,
@@ -204,7 +177,7 @@ static int mtk_jpeg_try_fmt_mplane(struct v4l2_format *f,
return 0;
}
 
-   /* type is MTK_JPEG_FMT_TYPE_CAPTURE */
+   /* other fourcc */
pix_mp->height = clamp(round_up(pix_mp->height, fmt->v_align),
   MTK_JPEG_MIN_HEIGHT, MTK_JPEG_MAX_HEIGHT);
pix_mp->width = clamp(round_up(pix_mp->width, fmt->h_align),
@@ -288,7 +261,12 @@ static int mtk_jpeg_try_fmt_vid_cap_mplane(struct file 
*file, void *priv,
 (fmt->fourcc >> 16 & 0xff),
 (fmt->fourcc >> 24 & 0xff));
 
-   return mtk_jpeg_try_fmt_mplane(f, fmt, ctx, MTK_JPEG_FMT_TYPE_CAPTURE);
+   if (ctx->state != MTK_JPEG_INIT) {
+   mtk_jpeg_g_fmt_vid_mplane(file, priv, f);
+   return 0;
+   }
+
+   return mtk_jpeg_try_fmt_mplane(>fmt.pix_mp, fmt);
 }
 
 static int mtk_jpeg_try_fmt_vid_out_mplane(struct file *file, void *priv,
@@ -309,7 +287,12 @@ static int mtk_jpeg_try_fmt_vid_out_mplane(struct file 
*file, void *priv,
 (fmt->fourcc >> 16 & 0xff),
 (fmt->fourcc >> 24 & 0xff));
 
-   return mtk_jpeg_try_fmt_mplane(f, fmt, ctx, MTK_JPEG_FMT_TYPE_OUTPUT);
+   if (ctx->state != MTK_JPEG_INIT) {
+   mtk_jpeg_g_fmt_vid_mplane(file, priv, f);
+   return 0;
+   }
+
+   return mtk_jpeg_try_fmt_mplane(>fmt.pix_mp, fmt);
 }
 
 static int mtk_jpeg_s_fmt_mplane(struct mtk_jpeg_ctx *ctx,
-- 
2.18.0

[PATCH v10 19/28] media: platform: Redefinition of mtk_jpeg_q_data structure

[Xia Jiang]

The standard v4l2_pix_format_mplane structure contains width/height/
sizeimage/bytesperline, so use v4l2_pix_format_mplane to replace them.

Signed-off-by: Xia Jiang 
---
v10: new add patch
---
 .../media/platform/mtk-jpeg/mtk_jpeg_core.c   | 101 ++
 .../media/platform/mtk-jpeg/mtk_jpeg_core.h   |  20 +---
 2 files changed, 57 insertions(+), 64 deletions(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index b3e38ffd4e81..01f4656fe2b3 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -207,15 +207,15 @@ static int mtk_jpeg_g_fmt_vid_mplane(struct file *file, 
void *priv,
 
q_data = mtk_jpeg_get_q_data(ctx, f->type);
 
-   pix_mp->width = q_data->w;
-   pix_mp->height = q_data->h;
+   pix_mp->width = q_data->pix_mp.width;
+   pix_mp->height = q_data->pix_mp.height;
pix_mp->field = V4L2_FIELD_NONE;
pix_mp->pixelformat = q_data->fmt->fourcc;
pix_mp->num_planes = q_data->fmt->colplanes;
-   pix_mp->colorspace = ctx->colorspace;
-   pix_mp->ycbcr_enc = ctx->ycbcr_enc;
-   pix_mp->xfer_func = ctx->xfer_func;
-   pix_mp->quantization = ctx->quantization;
+   pix_mp->colorspace = q_data->pix_mp.colorspace;
+   pix_mp->ycbcr_enc = q_data->pix_mp.ycbcr_enc;
+   pix_mp->xfer_func = q_data->pix_mp.xfer_func;
+   pix_mp->quantization = q_data->pix_mp.quantization;
 
v4l2_dbg(1, debug, >v4l2_dev, "(%d) g_fmt:%c%c%c%c wxh:%ux%u\n",
 f->type,
@@ -228,8 +228,8 @@ static int mtk_jpeg_g_fmt_vid_mplane(struct file *file, 
void *priv,
for (i = 0; i < pix_mp->num_planes; i++) {
struct v4l2_plane_pix_format *pfmt = _mp->plane_fmt[i];
 
-   pfmt->bytesperline = q_data->bytesperline[i];
-   pfmt->sizeimage = q_data->sizeimage[i];
+   pfmt->bytesperline = q_data->pix_mp.plane_fmt[i].bytesperline;
+   pfmt->sizeimage = q_data->pix_mp.plane_fmt[i].sizeimage;
 
v4l2_dbg(1, debug, >v4l2_dev,
 "plane[%d] bpl=%u, size=%u\n",
@@ -318,12 +318,12 @@ static int mtk_jpeg_s_fmt_mplane(struct mtk_jpeg_ctx *ctx,
q_data->fmt = mtk_jpeg_find_format(mtk_jpeg_formats,
   MTK_JPEG_NUM_FORMATS,
   pix_mp->pixelformat, fmt_type);
-   q_data->w = pix_mp->width;
-   q_data->h = pix_mp->height;
-   ctx->colorspace = pix_mp->colorspace;
-   ctx->ycbcr_enc = pix_mp->ycbcr_enc;
-   ctx->xfer_func = pix_mp->xfer_func;
-   ctx->quantization = pix_mp->quantization;
+   q_data->pix_mp.width = pix_mp->width;
+   q_data->pix_mp.height = pix_mp->height;
+   q_data->pix_mp.colorspace = pix_mp->colorspace;
+   q_data->pix_mp.ycbcr_enc = pix_mp->ycbcr_enc;
+   q_data->pix_mp.xfer_func = pix_mp->xfer_func;
+   q_data->pix_mp.quantization = pix_mp->quantization;
 
v4l2_dbg(1, debug, >v4l2_dev, "(%d) s_fmt:%c%c%c%c wxh:%ux%u\n",
 f->type,
@@ -331,15 +331,18 @@ static int mtk_jpeg_s_fmt_mplane(struct mtk_jpeg_ctx *ctx,
 (q_data->fmt->fourcc >>  8 & 0xff),
 (q_data->fmt->fourcc >> 16 & 0xff),
 (q_data->fmt->fourcc >> 24 & 0xff),
-q_data->w, q_data->h);
+q_data->pix_mp.width, q_data->pix_mp.height);
 
for (i = 0; i < q_data->fmt->colplanes; i++) {
-   q_data->bytesperline[i] = pix_mp->plane_fmt[i].bytesperline;
-   q_data->sizeimage[i] = pix_mp->plane_fmt[i].sizeimage;
+   q_data->pix_mp.plane_fmt[i].bytesperline =
+   pix_mp->plane_fmt[i].bytesperline;
+   q_data->pix_mp.plane_fmt[i].sizeimage =
+   pix_mp->plane_fmt[i].sizeimage;
 
v4l2_dbg(1, debug, >v4l2_dev,
 "plane[%d] bpl=%u, size=%u\n",
-i, q_data->bytesperline[i], q_data->sizeimage[i]);
+i, q_data->pix_mp.plane_fmt[i].bytesperline,
+q_data->pix_mp.plane_fmt[i].sizeimage);
}
 
return 0;
@@ -404,15 +407,15 @@ static int mtk_jpeg_g_selection(struct file *file, void 
*priv,
switch (s->target) {
case V4L2_SEL_TGT_COMPOSE:
case V4L2_SEL_TGT_COMPOSE_DEFAULT:
-   s->r.width = ctx->out_q.w;
-   s->r.height = ctx->out_q.h;
+   s->r.width = ctx->out_q.pix_mp.width;
+   s->r.height = ctx->out_q.pix_mp.height;
s->r.left = 0;
s->r.top = 0;
break;
case V4L2_SEL_TGT_COMPOSE_BOUNDS:
case V4L2_SEL_TGT_COMPOSE_PADDED:
-   s->r.width = ctx->cap_q.w;
-   s->r.height = ctx->cap_q.h;
+   s->r.width = 

[PATCH v10 26/28] media: platform: Rename existing functions/defines/variables

[Xia Jiang]

Rename existing functions/defines/variables with a  _dec prefix and
without dec_ prefix to prepare for the addition of the jpeg encoder
feature.

Reviewed-by: Tomasz Figa 
Signed-off-by: Xia Jiang 
---
v10: no changes
---
 .../media/platform/mtk-jpeg/mtk_jpeg_core.c   | 172 +-
 .../media/platform/mtk-jpeg/mtk_jpeg_core.h   |  12 +-
 .../media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h |   5 +-
 3 files changed, 97 insertions(+), 92 deletions(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 605b4fb3d90b..e245bcdb6f1a 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -27,11 +27,11 @@
 #include "mtk_jpeg_core.h"
 #include "mtk_jpeg_dec_parse.h"
 
-static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
+static struct mtk_jpeg_fmt mtk_jpeg_dec_formats[] = {
{
.fourcc = V4L2_PIX_FMT_JPEG,
.colplanes  = 1,
-   .flags  = MTK_JPEG_FMT_FLAG_DEC_OUTPUT,
+   .flags  = MTK_JPEG_FMT_FLAG_OUTPUT,
},
{
.fourcc = V4L2_PIX_FMT_YUV420M,
@@ -40,7 +40,7 @@ static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
.colplanes  = 3,
.h_align= 5,
.v_align= 4,
-   .flags  = MTK_JPEG_FMT_FLAG_DEC_CAPTURE,
+   .flags  = MTK_JPEG_FMT_FLAG_CAPTURE,
},
{
.fourcc = V4L2_PIX_FMT_YUV422M,
@@ -49,11 +49,11 @@ static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
.colplanes  = 3,
.h_align= 5,
.v_align= 3,
-   .flags  = MTK_JPEG_FMT_FLAG_DEC_CAPTURE,
+   .flags  = MTK_JPEG_FMT_FLAG_CAPTURE,
},
 };
 
-#define MTK_JPEG_NUM_FORMATS ARRAY_SIZE(mtk_jpeg_formats)
+#define MTK_JPEG_DEC_NUM_FORMATS ARRAY_SIZE(mtk_jpeg_dec_formats)
 
 struct mtk_jpeg_src_buf {
struct vb2_v4l2_buffer b;
@@ -112,15 +112,15 @@ static int mtk_jpeg_enum_fmt(struct mtk_jpeg_fmt 
*mtk_jpeg_formats, int n,
 static int mtk_jpeg_enum_fmt_vid_cap(struct file *file, void *priv,
 struct v4l2_fmtdesc *f)
 {
-   return mtk_jpeg_enum_fmt(mtk_jpeg_formats, MTK_JPEG_NUM_FORMATS, f,
-MTK_JPEG_FMT_FLAG_DEC_CAPTURE);
+   return mtk_jpeg_enum_fmt(mtk_jpeg_dec_formats, MTK_JPEG_DEC_NUM_FORMATS,
+f, MTK_JPEG_FMT_FLAG_CAPTURE);
 }
 
 static int mtk_jpeg_enum_fmt_vid_out(struct file *file, void *priv,
 struct v4l2_fmtdesc *f)
 {
-   return mtk_jpeg_enum_fmt(mtk_jpeg_formats, MTK_JPEG_NUM_FORMATS, f,
-MTK_JPEG_FMT_FLAG_DEC_OUTPUT);
+   return mtk_jpeg_enum_fmt(mtk_jpeg_dec_formats, MTK_JPEG_DEC_NUM_FORMATS,
+f, MTK_JPEG_FMT_FLAG_OUTPUT);
 }
 
 static struct mtk_jpeg_q_data *mtk_jpeg_get_q_data(struct mtk_jpeg_ctx *ctx,
@@ -246,9 +246,10 @@ static int mtk_jpeg_try_fmt_vid_cap_mplane(struct file 
*file, void *priv,
struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
struct mtk_jpeg_fmt *fmt;
 
-   fmt = mtk_jpeg_find_format(mtk_jpeg_formats, MTK_JPEG_NUM_FORMATS,
+   fmt = mtk_jpeg_find_format(mtk_jpeg_dec_formats,
+  MTK_JPEG_DEC_NUM_FORMATS,
   f->fmt.pix_mp.pixelformat,
-  MTK_JPEG_FMT_FLAG_DEC_CAPTURE);
+  MTK_JPEG_FMT_FLAG_CAPTURE);
if (!fmt)
fmt = ctx->cap_q.fmt;
 
@@ -273,9 +274,10 @@ static int mtk_jpeg_try_fmt_vid_out_mplane(struct file 
*file, void *priv,
struct mtk_jpeg_ctx *ctx = mtk_jpeg_fh_to_ctx(priv);
struct mtk_jpeg_fmt *fmt;
 
-   fmt = mtk_jpeg_find_format(mtk_jpeg_formats, MTK_JPEG_NUM_FORMATS,
+   fmt = mtk_jpeg_find_format(mtk_jpeg_dec_formats,
+  MTK_JPEG_DEC_NUM_FORMATS,
   f->fmt.pix_mp.pixelformat,
-  MTK_JPEG_FMT_FLAG_DEC_OUTPUT);
+  MTK_JPEG_FMT_FLAG_OUTPUT);
if (!fmt)
fmt = ctx->out_q.fmt;
 
@@ -315,8 +317,8 @@ static int mtk_jpeg_s_fmt_mplane(struct mtk_jpeg_ctx *ctx,
}
 
 
-   q_data->fmt = mtk_jpeg_find_format(mtk_jpeg_formats,
-  MTK_JPEG_NUM_FORMATS,
+   q_data->fmt = mtk_jpeg_find_format(mtk_jpeg_dec_formats,
+  MTK_JPEG_DEC_NUM_FORMATS,
   pix_mp->pixelformat, fmt_type);
q_data->pix_mp.width = pix_mp->width;
q_data->pix_mp.height = pix_mp->height;
@@ -358,7 +360,7 @@ static int mtk_jpeg_s_fmt_vid_out_mplane(struct file *file, 

[PATCH v10 25/28] media: platform: Rename jpeg dec file name

[Xia Jiang]

Rename the files which are for decode feature. This is preparing
path since the jpeg enc patch will be added later.

Reviewed-by: Tomasz Figa 
Signed-off-by: Xia Jiang 
---
v10: no changes
---
 drivers/media/platform/mtk-jpeg/Makefile  | 2 +-
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c   | 4 ++--
 .../platform/mtk-jpeg/{mtk_jpeg_hw.c => mtk_jpeg_dec_hw.c}| 2 +-
 .../platform/mtk-jpeg/{mtk_jpeg_hw.h => mtk_jpeg_dec_hw.h}| 2 +-
 .../mtk-jpeg/{mtk_jpeg_parse.c => mtk_jpeg_dec_parse.c}   | 2 +-
 .../mtk-jpeg/{mtk_jpeg_parse.h => mtk_jpeg_dec_parse.h}   | 2 +-
 .../platform/mtk-jpeg/{mtk_jpeg_reg.h => mtk_jpeg_dec_reg.h}  | 0
 7 files changed, 7 insertions(+), 7 deletions(-)
 rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_hw.c => mtk_jpeg_dec_hw.c} 
(99%)
 rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_hw.h => mtk_jpeg_dec_hw.h} 
(98%)
 rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_parse.c => 
mtk_jpeg_dec_parse.c} (98%)
 rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_parse.h => 
mtk_jpeg_dec_parse.h} (92%)
 rename drivers/media/platform/mtk-jpeg/{mtk_jpeg_reg.h => mtk_jpeg_dec_reg.h} 
(100%)

diff --git a/drivers/media/platform/mtk-jpeg/Makefile 
b/drivers/media/platform/mtk-jpeg/Makefile
index 92a4fc046bfe..48516dcf96e6 100644
--- a/drivers/media/platform/mtk-jpeg/Makefile
+++ b/drivers/media/platform/mtk-jpeg/Makefile
@@ -1,3 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0-only
-mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_hw.o mtk_jpeg_parse.o
+mtk_jpeg-objs := mtk_jpeg_core.o mtk_jpeg_dec_hw.o mtk_jpeg_dec_parse.o
 obj-$(CONFIG_VIDEO_MEDIATEK_JPEG) += mtk_jpeg.o
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index 921ed21f7db3..605b4fb3d90b 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -23,9 +23,9 @@
 #include 
 #include 
 
-#include "mtk_jpeg_hw.h"
+#include "mtk_jpeg_dec_hw.h"
 #include "mtk_jpeg_core.h"
-#include "mtk_jpeg_parse.h"
+#include "mtk_jpeg_dec_parse.h"
 
 static struct mtk_jpeg_fmt mtk_jpeg_formats[] = {
{
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.c
similarity index 99%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.c
index 68abcfd7494d..afbbfd5d02bc 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.c
@@ -9,7 +9,7 @@
 #include 
 #include 
 
-#include "mtk_jpeg_hw.h"
+#include "mtk_jpeg_dec_hw.h"
 
 #define MTK_JPEG_DUNUM_MASK(val)   (((val) - 1) & 0x3)
 
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h
similarity index 98%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h
index 7b0687f8f4b6..1cc37dbfc8e7 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h
@@ -11,7 +11,7 @@
 #include 
 
 #include "mtk_jpeg_core.h"
-#include "mtk_jpeg_reg.h"
+#include "mtk_jpeg_dec_reg.h"
 
 enum {
MTK_JPEG_DEC_RESULT_EOF_DONE= 0,
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c
similarity index 98%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c
index f862d38f3af7..b95c45791c29 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.c
@@ -8,7 +8,7 @@
 #include 
 #include 
 
-#include "mtk_jpeg_parse.h"
+#include "mtk_jpeg_dec_parse.h"
 
 #define TEM0x01
 #define SOF0   0xc0
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.h
similarity index 92%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.h
index 0a48eeabaff2..2918f15811f8 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_parse.h
@@ -8,7 +8,7 @@
 #ifndef _MTK_JPEG_PARSE_H
 #define _MTK_JPEG_PARSE_H
 
-#include "mtk_jpeg_hw.h"
+#include "mtk_jpeg_dec_hw.h"
 
 bool mtk_jpeg_parse(struct mtk_jpeg_dec_param *param, u8 *src_addr_va,
u32 src_size);
diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_reg.h
similarity index 100%
rename from drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
rename to drivers/media/platform/mtk-jpeg/mtk_jpeg_dec_reg.h
-- 
2.18.0